The Rockchip PX30 SoC has three I2S controllers, i2s1 and i2s2 are
2-channel I2S/PCM controllers handled by the same controller driver, and
i2s0 a 8-channel I2S/PCM/TDM controller handled by another controller
driver.
This adds the device tree node required to enable I2S0 on PX30.
This was tested in a 2-channel I2S with TX BCLK/LRCK for both TX and RX
(rockchip,trcm-sync-tx-only) setup on a soon-to-be-released board.
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20220916091746.35108-1-foss+kernel@0leil.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Gru-Scarlet family includes a variety of SKU identifiers, using
parts of a 3-bit space {0..7}. SKU2 and SKU4 devices (under a few
different manufacturer names) also use the Innolux display.
Without this, a SKU2 device may non-deterministically (depending on the
matching order of DTBs and bootloader behavior) select either one of the
INX DTBs (rk3399-gru-scarlet-dumo.dtb or rk3399-gru-scarlet-inx.dtb) or
the KingDisplay DTB (rk3399-gru-scarlet-kd.dtb), to ill effect.
For reference, the original vendor tree source:
CHROMIUM: arm64: dts: rockchip: add sku{0,2,4} compatibility
f6ed665c9e
CHROMIUM: arm64: dts: rockchip: scarlet: add SKU0 device tree
9987c8776f
Signed-off-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20220817123350.2.I5f4fd0808a927b08e267c189712fb4a85931fd3b@changeid
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
We discoverd that the state of BCLK on, LRCLK off and SD_MODE on
may cause the speaker melting issue. Removing LRCLK while BCLK
is present can cause unexpected output behavior including a large
DC output voltage as described in the Max98357a datasheet.
In order to:
1. prevent BCLK from turning on by other component.
2. keep BCLK and LRCLK being present at the same time
This patch adjusts the device tree to allow BCLK to switch
to GPIO func before LRCLK output, and switch back during
LRCLK is output.
Signed-off-by: Judy Hsiao <judyhsiao@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20220708080726.4170711-1-judyhsiao@chromium.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Anbernic RG353P and RG503 are both RK3566 based handheld gaming devices
from Anbernic.
Both devices have:
- 2 SDMMC slots.
- A Realtek rtl8821cs WiFi/Bluetooth adapter.
- A mini HDMI port.
- A USB C host port and a USB C otg port (currently only working as
device).
- Multiple GPIO buttons and a single ADC button.
- Dual analog joysticks controlled via a GPIO mux.
- A headphone jack with amplified stereo speakers via a SGM4865 amp.
- A PWM based vibrator for force feedback.
The RG353P has:
- 2GB LPDDR4 RAM.
- A 32GB eMMC.
- A 3.5 inch 640x480 4-lane DSI panel of unknown origin with an i2c
controlled touchscreen (touchscreen is a Hynitron CST340).
The RG503 has:
- 1GB LPDDR4 RAM.
- A 5 inch 960x544 AMOLED 2-lane DSI/DBI panel manufactured by Samsung
with part number ams495qa04. Data for this panel is provided via the
DSI interface, however commands are sent via a 9-bit 3-wire SPI
interface. The MISO pin of SPI3 of the SOC is wired to the input of
the panel, so it must be bitbanged.
This devicetree enables the following hardware:
- HDMI (plus audio).
- Analog audio, including speakers.
- All buttons.
- All SDMMC/eMMC/SDIO controllers.
- The ADC joysticks (note a pending patch is required to use them).
- WiFi/Bluetooth (note out of tree drivers are required).
- The PWM based vibrator motor.
The following hardware is not enabled:
- The display panels (drivers are being written and there are issues
with the upstream DSI and VOP2 subsystems).
- Battery (driver pending).
- Touchscreen on the RG353P (note the i2c2 bus is enabled for it).
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20220906210324.28986-4-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Voltage constraints on vccio_sd are invalid. They don't match the voltages
that LDO9 can generate, and this causes rk808-regulator driver to fail
to probe with -EINVAL when it tries to apply the constraints during boot.
Fix the constraints to something that LDO9 can be actually configured for.
Fixes: 78a21c7d59 ("arm64: dts: rockchip: Add initial support for Pine64 PinePhone Pro")
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Reviewed-by: Caleb Connolly <kc@postmarketos.org>
Reviewed-by: Tom Fitzhenry <tom@tom-fitzhenry.me.uk>
Tested-by: Tom Fitzhenry <tom@tom-fitzhenry.me.uk>
Link: https://lore.kernel.org/r/20220904233652.3197885-1-megi@xff.cz
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Document the dt-bindings for Radxa ROCK 4C+ SBC.
Key differences of 4C+ compared to previous ROCK Pi 4.
- Rockchip RK3399-T SoC
- DP from 4C replaced with micro HDMI 2K@60fps
- 4-lane MIPI DSI with 1920*1080
- RK817 Audio codec
Also, an official naming convention from Radxa mention to remove
Pi from board name, so this 4C+ is named as Radxa ROCK 4C+ not
Radxa ROCK Pi 4C+.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Link: https://lore.kernel.org/r/20220902065057.97425-1-jagan@amarulasolutions.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
EAIDK-610 is from OPEN AI LAB and popularly used by university
students.
Specification:
- Rockchip RK3399
- LPDDR3 4GB
- TF sd scard slot
- eMMC
- AP6255 for WiFi + BT
- Gigabit ethernet
- HDMI out
- 40 pin header
- USB 2.0 x 2
- USB 3.0 x 1
- USB 3.0 Type-C x 1
- 12V DC Power supply
This patch is test on Armbain and Glodroid with
HDMI/GPU/USB HOST/Type-C ADB/WIFI/BT.
Signed-off-by: Andy Yan <andyshrk@163.com>
Link: https://lore.kernel.org/r/20220709103016.2754044-1-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
EAIDK-610 is a rk3399 based board from OPEN AI LAB
and popularly used by university students.
Specification:
- Rockchip RK3399
- LPDDR3 4GB
- TF sd scard slot
- eMMC
- AP6255 for WiFi + BT
- Gigabit ethernet
- HDMI out
- 40 pin header
- USB 2.0 x 2
- USB 3.0 x 1
- USB 3.0 Type-C x 1
- 12V DC Power supply
Signed-off-by: Andy Yan <andyshrk@163.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220709103001.2753992-1-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This adds the necessary device tree changes to enable analog
audio output on the PINE64 Quartz64 Model B with its RK809
codec.
The headphone detection pin is left out for now because I couldn't
get it to work and am not sure if it even matters, but for future
reference: It's pin GPIO4 RK_PC4, named HP_DET_L_GPIO4_C4 in the
schematic.
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Link: https://lore.kernel.org/r/20220721083301.3711-1-frattaroli.nicolas@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Pull x86 kprobes fix from Ingo Molnar:
"Fix a kprobes bug in JNG/JNLE emulation when a kprobe is installed at
such instructions, possibly resulting in incorrect execution (the
wrong branch taken)"
* tag 'perf-urgent-2022-08-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/kprobes: Fix JNG/JNLE emulation
Pull tracing fixes from Steven Rostedt:
"Various fixes for tracing:
- Fix a return value of traceprobe_parse_event_name()
- Fix NULL pointer dereference from failed ftrace enabling
- Fix NULL pointer dereference when asking for registers from eprobes
- Make eprobes consistent with kprobes/uprobes, filters and
histograms"
* tag 'trace-v6.0-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Have filter accept "common_cpu" to be consistent
tracing/probes: Have kprobes and uprobes use $COMM too
tracing/eprobes: Have event probes be consistent with kprobes and uprobes
tracing/eprobes: Fix reading of string fields
tracing/eprobes: Do not hardcode $comm as a string
tracing/eprobes: Do not allow eprobes to use $stack, or % for regs
ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead
tracing/perf: Fix double put of trace event when init fails
tracing: React to error return from traceprobe_parse_event_name()
Currently, if a symbol "@" is attempted to be used with an event probe
(eprobes), it will cause a NULL pointer dereference crash.
Both kprobes and uprobes can reference data other than the main registers.
Such as immediate address, symbols and the current task name. Have eprobes
do the same thing.
For "comm", if "comm" is used and the event being attached to does not
have the "comm" field, then make it the "$comm" that kprobes has. This is
consistent to the way histograms and filters work.
Link: https://lkml.kernel.org/r/20220820134401.136924220@goodmis.org
Cc: stable@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
Cc: Tom Zanussi <zanussi@kernel.org>
Fixes: 7491e2c442 ("tracing: Add a probe that attaches to trace events")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
If in perf_trace_event_init(), the perf_trace_event_open() fails, then it
will call perf_trace_event_unreg() which will not only unregister the perf
trace event, but will also call the put() function of the tp_event.
The problem here is that the trace_event_try_get_ref() is called by the
caller of perf_trace_event_init() and if perf_trace_event_init() returns a
failure, it will then call trace_event_put(). But since the
perf_trace_event_unreg() already called the trace_event_put() function, it
triggers a WARN_ON().
WARNING: CPU: 1 PID: 30309 at kernel/trace/trace_dynevent.c:46 trace_event_dyn_put_ref+0x15/0x20
If perf_trace_event_reg() does not call the trace_event_try_get_ref() then
the perf_trace_event_unreg() should not be calling trace_event_put(). This
breaks symmetry and causes bugs like these.
Pull out the trace_event_put() from perf_trace_event_unreg() and call it
in the locations that perf_trace_event_unreg() is called. This not only
fixes this bug, but also brings back the proper symmetry of the reg/unreg
vs get/put logic.
Link: https://lore.kernel.org/all/cover.1660347763.git.kjlx@templeofstupid.com/
Link: https://lkml.kernel.org/r/20220816192817.43d5e17f@gandalf.local.home
Cc: stable@vger.kernel.org
Fixes: 1d18538e6a ("tracing: Have dynamic events have a ref counter")
Reported-by: Krister Johansen <kjlx@templeofstupid.com>
Reviewed-by: Krister Johansen <kjlx@templeofstupid.com>
Tested-by: Krister Johansen <kjlx@templeofstupid.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
The function traceprobe_parse_event_name() may set the first two function
arguments to a non-null value and still return -EINVAL to indicate an
unsuccessful completion of the function. Hence, it is not sufficient to
just check the result of the two function arguments for being not null,
but the return value also needs to be checked.
Commit 95c104c378 ("tracing: Auto generate event name when creating a
group of events") changed the error-return-value checking of the second
traceprobe_parse_event_name() invocation in __trace_eprobe_create() and
removed checking the return value to jump to the error handling case.
Reinstate using the return value in the error-return-value checking.
Link: https://lkml.kernel.org/r/20220811071734.20700-1-lukas.bulwahn@gmail.com
Fixes: 95c104c378 ("tracing: Auto generate event name when creating a group of events")
Acked-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
