Add KUnit test cases for control read/write.
Tests cases cover general reading and writing of controls:
1) Read/write at offset position in control.
2) Read/write of various lengths less than length of the control.
3) Rejecting illegal arguments.
The test cases are run for ADSP2 with 16-bit registers, ADSP2
with 32-bit registers and Halo Core with 32-bit registers. The
ADSP2 cases are further divided into runs for V1 and V2 format
WMFW files, because there are differences in how V1 and V2
defines controls.
The obsolete V0 format does not have controls, so no testing of
that format is needed.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-10-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add KUnit test cases for the caching of control content.
The test cases can be divided into four groups:
1) The cache is correctly initialized when the firmware is first
downloaded.
2) Reads return the correct data.
3) Writes update the registers and cache.
4) If a value has been written to the control it is retained in
the cache and written out to the registers when the firmware
is started.
There are multiple test suites to cover:
- V1 and V2 format files on 16-bit and 32-bit ADSP2.
- V3 format files on Halo Core DSPs.
V1 format files, and some V2 format files, didn't provide access
flags for the controls. There are a couple of test cases for
unspecified flags to ensure backwards compatibility with the
original implementation of these older firmware versions.
The obsolete V0 format does not have controls, so no testing of
that format is needed.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-9-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add KUnit test cases for parsing of firmware controls out of the
wmfw. These test cases are only testing that the data in the wmfw
is correctly interpreted and entered into the list of controls.
The test cases can be roughly divided into three types:
1) The correct values are extracted from the wmfw.
2) Variable-length strings are handled correctly.
3) Controls are correctly identified as unique or identical.
There are multiple test suites to cover:
- V1 and V2 format files on 16-bit and 32-bit ADSP2.
- V3 format files on Halo Core DSPs.
V1 format does not have named controls, and the strings in the
coefficient descriptor are fixed-length fields. On V2 and V3 format
the controls are named and all strings are variable-length.
The obsolete V0 format does not have controls, so no testing of
that format is needed.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-8-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds a KUnit test suite to test downloading wmfw files.
The general technique is
1. Create mock wmfw file content
2. Tell cs_dsp to download the wmfw file
3. Check in the emulated regmap registers that the correct values have
been written to DSP memory
4. Drop the regmap cache for the expected written registers and then do a
regcache_sync() to check for unexpected writes to other registers.
The test covers ADSP2 v1 and v2, and HALO Core DSPs. (ADSP1 is very
obsolete so isn't tested).
There is a large number of test cases and parameterized variants of tests
because of the many different addressing schemes supported by the Cirrus
devices. The DSP has 2 or 3 memory spaces: XM, YM and ZM. The DSP sees
these using its native addressing, which is word-addressed (not
byte-addressed). The host sees these through one of several register
mappings (depending on the DSP type and parent codec family). The
registers have three different addressing schemes: 16-bit registers
addressed by register number, 32-bit registers addressed by register
number, or 32-bit registers addressed by byte (with a stride of 4). In
addition to these multiple addressing schemes, the Halo Core DSPs have a
"packed" register mapping that maps 4 DSP words into 3 registers. In
addition to this there are 4 versions of the wmfw file format to be
tested.
The test cases intentionally have relatively little factoring-out of
similar code. This makes it much easier to visually verify that a test
case is testing correctly, and what exactly it is testing. Factoring out
large amounts of code into helper functions tends to obscure what the
actual test procedure is, so increasing the chance of hidden errors where
test cases don't actually test as intended.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-7-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This adds a KUnit test suite to test downloading bin files.
The general technique is
1. Create mock bin file content
2. Tell cs_dsp to download the bin file
3. Check in the emulated regmap registers that the correct values have
been written to DSP memory
4. Drop the regmap cache for the expected written registers and then do a
regcache_sync() to check for unexpected writes to other registers.
The test covers ADSP2 v1 and v2, and HALO Core DSPs. (ADSP1 is very
obsolete so isn't tested).
There is a large number of test cases and parameterized variants of tests
because of the many different addressing schemes supported by the Cirrus
devices. The DSP has 2 or 3 memory spaces: XM, YM and ZM. The DSP sees
these using its native addressing, which is word-addressed (not
byte-addressed). The host sees these through one of several register
mappings (depending on the DSP type and parent codec family). The
registers have three different addressing schemes: 16-bit registers
addressed by register number, 32-bit registers addressed by register
number, or 32-bit registers addressed by byte (with a stride of 4). In
addition to these multiple addressing schemes, the Halo Core DSPs have a
"packed" register mapping that maps 4 DSP words into 3 registers. The bin
file addresses the data blob relative to the base address of an algorithm,
which has to be calculated in both DSP words (for the DSP to access) and
register addresses (for the host).
This results in many different addressing schemes used in parallel, hence
the complexity of the address and size manipulation in the test cases:
word addresses in DSP memory, byte offsets, word offsets, register
addresses (either byte-addressed 32-bit or index-addressed 16-bit), and
packed register addresses.
The test cases intentionally have relatively little factoring-out of
similar code. This makes it much easier to visually verify that a test
case is testing correctly, and what exactly it is testing. Factoring out
large amounts of code into helper functions tends to obscure what the
actual test procedure is, so increasing the chance of hidden errors where
test cases don't actually test as intended.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-6-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a mock firmware file that emulates what the firmware build tools
would normally create. This will be used by KUnit tests to generate a
test bin file.
The data payload in a bin is an opaque blob, so the mock bin only needs
to generate the appropriate file header and description block for each
payload blob.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a mock firmware file that emulates what the firmware build tools
would normally create. This will be used by KUnit tests to generate a
test wmfw file.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add helper functions to implement an emulation of the DSP memory map.
There are three main groups of functionality:
1. Define a mock cs_dsp_region table.
2. Calculate the addresses of memory and algorithms from the firmware
header in XM.
3. Build a mock XM header in emulated XM.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a mock regmap implementation to act as a simulated DSP for KUnit
testing. This is built as a utility module so that it could be used by
clients of cs_dsp to create a mock "DSP" for their own testing.
cs_dsp interacts with the DSP only through registers. Most of the
register space of the DSP is RAM. ADSP cores have a small set of control
registers. HALO Core DSPs have a much larger set of control registers but
only a small subset are used.
Most writes are "blind" in the sense that cs_dsp does not expect to
receive any sort of response from the DSP. So there isn't any need to
emulate a "DSP", only a set of registers that can be written and read
back.
The idea of the mock regmap is to use the cache to accumulate writes
which can then be tested against the values that are expected to be in
the registers.
Stray writes can be detected by dropping the cache entries for all
addresses that should have been written and then issuing a regcache_sync().
If this causes bus writes it means there were writes to unexpected
registers.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20241212143725.1381013-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If the stream's pause_supported flag is false then mask out the PAUSE
support, so user space will be prevented to use it.
Introduce a module parameter to ignore the pause_supported flag, named as
force_pause_support to allow testing of the PAUSE feature.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20241213101123.27318-3-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
New tokens are added to topology:
1202: SOF_TKN_STREAM_PLAYBACK_PAUSE_SUPPORTED
1203: SOF_TKN_STREAM_CAPTURE_PAUSE_SUPPORTED
The new tokens are used to advertise support for PAUSE/RESUME operation on
a PCM device depending on firmware product, use case, pipeline topology.
The snd_sof_pcm_stream.pause_supported is updated to reflect the advertised
value for the PCM device.
If the token does not exist then the pause_supported is set to false.
Note: it is up to the platform code to use this flag to decide to advertise
the PAUSE support for user space or not.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://patch.msgid.link/20241213101123.27318-2-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Regular development in this period. Main changes are listed:
rtl8xxxu:
* add more USB devices IDs
rtlwifi:
* refine error path
rtw88:
* add more USB devices IDs
* enable USB RX aggregation and USB 3 to improve performance
rtw89:
* implement more stuffs including PS flow for MLO
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuyEnvMdOsBl1WjpdjlvZYmhshd8FAmdaZsoACgkQjlvZYmhs
hd88Zg/+MPmzjZEGt6Fut7Zb0TacDkMjE8uALP8hSu1Xj0No95cDeQecbMrjCXFD
g6Y3cKJb2xn9SPPO3dNdzDBUFsAOdotErNqa2oAuz/7JB3oJgencgt1oaR5kAlWf
dMGxDsqc97fvKvOpDU8jsnuDMvLSleOnkNpsxxE5ozWAQdobGzH6hhz934pARBte
G4FdFlkmLXXcdiBmTalcaaI7iZrneOPuuwysd71jablZGAwyjTPJRGU3bpBNGhf7
egXpPNNFf5Z94vvVVvRbPI/9KHkP3ZmQrcaDqTZPogCWFLjmNTc/y9w60OlGVDW6
yU+vvzX+4ffLkxOYWVl+eAgmWE+g9FHX8JYxw9mcXh4tcS3QOFm1jRBLhOYb+boJ
Y9N6hadIIo4oYjg+UhiGqEhFv0CF/iJksy5yxsYHrYeQ/fBAGFUOVSFrjiJPiogP
yCQ/bZd3A+9GsCj57P9IPAmUuyF6HrZcNy+rdnlFx2opL0NSZkGEqXdDwY/jUfE4
7mwTwsg+ESkYnqa8ScCJI/it+7DRQLYvHccUyR4xTftENEdECY7MJ+ZH/FECNxxA
nWT7+z1ApGXJiXrArN+tebCzNcdnTSlxWKOPxzBNTVBTvC2HPMR7VTzIdF52dy2L
lWaLCYIl3pakLfcPRjzNQxI6tdZDlare5nT/3QmWNKEdcTN3shc=
=Lt77
-----END PGP SIGNATURE-----
Merge tag 'rtw-next-2024-12-12' of https://github.com/pkshih/rtw
rtw-next patches for v6.14
Regular development in this period. Main changes are listed:
rtl8xxxu:
* add more USB devices IDs
rtlwifi:
* refine error path
rtw88:
* add more USB devices IDs
* enable USB RX aggregation and USB 3 to improve performance
rtw89:
* implement more stuffs including PS flow for MLO
Including the fwil.h header file can lead to a build error:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h: \
In function ‘brcmf_fil_cmd_int_set’:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h:90:9: error: implicit \
declaration of function ‘brcmf_dbg’ [-Werror=implicit-function-declaration]
90 | brcmf_dbg(FIL, "ifidx=%d, cmd=%d, value=%d\n", ifp->ifidx, cmd, data);
| ^~~~~~~~~
The error is often avoided because the debug.h header file is included
before the fwil.h header file.
This makes sure the header include order is irrelevant by explicitly adding the
debug.h header.
Fixes: 31343230ab ("wifi: brcmfmac: export firmware interface functions")
Signed-off-by: Marcel Hamer <marcel.hamer@windriver.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241211133618.2014083-1-marcel.hamer@windriver.com
In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN()
instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access.
Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241210070441.836362-1-dmantipov@yandex.ru
The "ATHEROS ATH GENERIC UTILITIES" entry shares the same git tree as
the ATH10K, ATH11K, and ATH12K entries which I already maintain, so
add me to that entry as well.
Signed-off-by: Jeff Johnson <jjohnson@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://patch.msgid.link/20241212-ath-maintainer-v1-1-7ea5e86780a8@kernel.org
Commit 1fa08aece4 ("nsfs: convert to path_from_stashed() helper") reused
nsfs dentry's d_fsdata, which no longer contains a pointer to
proc_ns_operations.
Fix the remaining use in is_mnt_ns_file().
Fixes: 1fa08aece4 ("nsfs: convert to path_from_stashed() helper")
Cc: stable@vger.kernel.org # v6.9
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Link: https://lore.kernel.org/r/20241211121118.85268-1-mszeredi@redhat.com
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
dlserver time is accounted when:
- dlserver is active and the dlserver proxies the cfs task.
- dlserver is active but deferred and cfs task runs after being picked
through the normal fair class pick.
dl_server_update is called in two places to make sure that both the
above times are accounted for. But it doesn't check if dlserver is
active or not. Now that we have this dl_server_active flag, we can
consolidate dl_server_update into one place and all we need to check is
whether dlserver is active or not. When dlserver is active there is only
two possible conditions:
- dlserver is deferred.
- cfs task is running on behalf of dlserver.
Fixes: a110a81c52 ("sched/deadline: Deferrable dl server")
Signed-off-by: "Vineeth Pillai (Google)" <vineeth@bitbyteword.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Marcel Ziswiler <marcel.ziswiler@codethink.co.uk> # ROCK 5B
Link: https://lore.kernel.org/r/20241213032244.877029-2-vineeth@bitbyteword.org
dlserver can get dequeued during a dlserver pick_task due to the delayed
deueue feature and this can lead to issues with dlserver logic as it
still thinks that dlserver is on the runqueue. The dlserver throttling
and replenish logic gets confused and can lead to double enqueue of
dlserver.
Double enqueue of dlserver could happend due to couple of reasons:
Case 1
------
Delayed dequeue feature[1] can cause dlserver being stopped during a
pick initiated by dlserver:
__pick_next_task
pick_task_dl -> server_pick_task
pick_task_fair
pick_next_entity (if (sched_delayed))
dequeue_entities
dl_server_stop
server_pick_task goes ahead with update_curr_dl_se without knowing that
dlserver is dequeued and this confuses the logic and may lead to
unintended enqueue while the server is stopped.
Case 2
------
A race condition between a task dequeue on one cpu and same task's enqueue
on this cpu by a remote cpu while the lock is released causing dlserver
double enqueue.
One cpu would be in the schedule() and releasing RQ-lock:
current->state = TASK_INTERRUPTIBLE();
schedule();
deactivate_task()
dl_stop_server();
pick_next_task()
pick_next_task_fair()
sched_balance_newidle()
rq_unlock(this_rq)
at which point another CPU can take our RQ-lock and do:
try_to_wake_up()
ttwu_queue()
rq_lock()
...
activate_task()
dl_server_start() --> first enqueue
wakeup_preempt() := check_preempt_wakeup_fair()
update_curr()
update_curr_task()
if (current->dl_server)
dl_server_update()
enqueue_dl_entity() --> second enqueue
This bug was not apparent as the enqueue in dl_server_start doesn't
usually happen because of the defer logic. But as a side effect of the
first case(dequeue during dlserver pick), dl_throttled and dl_yield will
be set and this causes the time accounting of dlserver to messup and
then leading to a enqueue in dl_server_start.
Have an explicit flag representing the status of dlserver to avoid the
confusion. This is set in dl_server_start and reset in dlserver_stop.
Fixes: 63ba8422f8 ("sched/deadline: Introduce deadline servers")
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: "Vineeth Pillai (Google)" <vineeth@bitbyteword.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Marcel Ziswiler <marcel.ziswiler@codethink.co.uk> # ROCK 5B
Link: https://lkml.kernel.org/r/20241213032244.877029-1-vineeth@bitbyteword.org
Since the new funnel device supports multi-port output scenarios,
there may be more than one TPDM connected to one TPDA. In this
way, when reading the element size of the TPDM, TPDA driver needs
to find the expected TPDM corresponding to the filter source.
When TPDA finds a TPDM or a filter source from a input connection,
it will read the Devicetree to get the expected TPDM's element
size.
Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20241213100731.25914-5-quic_taozha@quicinc.com
Some replicators have hard coded filtering of "trace" data, based on the
source device. This is different from the trace filtering based on
TraceID, available in the standard programmable replicators. e.g.,
Qualcomm replicators have filtering based on custom trace protocol
format and is not programmable.
The source device could be connected to the replicator via intermediate
components (e.g., a funnel). Thus we need platform information from
the firmware tables to decide the source device corresponding to a
given output port from the replicator. Given this affects "trace
path building" and traversing the path back from the sink to source,
add the concept of "filtering by source" to the generic coresight
connection.
The specified source will be marked like below in the Devicetree.
test-replicator {
... ... ... ...
out-ports {
... ... ... ...
port@0 {
reg = <0>;
xyz: endpoint {
remote-endpoint = <&zyx>;
filter-source = <&source_1>; <-- To specify the source to
}; be filtered out here.
};
port@1 {
reg = <1>;
abc: endpoint {
remote-endpoint = <&cba>;
filter-source = <&source_2>; <-- To specify the source to
}; be filtered out here.
};
};
};
Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20241213100731.25914-4-quic_taozha@quicinc.com
Since there are a lot of places in the code to check whether the
device is source, add a helper to check it.
Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20241213100731.25914-3-quic_taozha@quicinc.com
The is some "magic" hard coded filtering in the replicators,
which only passes through trace from a particular "source". Add
a new property "filter-source" to label a phandle to the coresight
trace source device matching the hard coded filtering for the port.
Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20241213100731.25914-2-quic_taozha@quicinc.com
Add sound card with SSI3 as CPU DAI and DA7212 as codec DAI.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/20241210170953.2936724-25-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add the da7212 audio codec node. Along with it regulators nodes were
reworked to be able to re-use them on da7212.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/20241210170953.2936724-23-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add DT nodes for the SSI IPs available on the Renesas RZ/G3S SoC. Along
with it external audio clocks were added. Board device tree could use it
and update the frequencies.
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20241210170953.2936724-21-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add the device tree node for the ADC IP available on the Renesas RZ/G3S
SoC.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20241206111337.726244-15-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add initial support for the RZ/G3E SMARC SoM with 4GB memory,
audio_extal, qextal and rtxin clks.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20241203105005.103927-12-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add the initial DTSI for the RZ/G3E SoC.
The files in this commit have the following meaning:
- r9a09g047.dtsi: RZ/G3E family SoC common parts
- r9a09g047e57.dtsi: RZ/G3E R0A09G047E{4,5}{7,8} SoC specific parts
- r9a09g047e37.dtsi: RZ/G3E R0A09G047E{2,3}{7,8} SoC specific parts
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20241203105005.103927-10-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
DT bindings and binding definitions for the Renesas RZ/G3E (R9A09G047)
SoC, shared by driver and DT source files.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCZ1wIdAAKCRCKwlD9ZEnx
cOEoAQCwqQx+/KkB++5y6zBQRmUf6vQaQJ65UgfVUG50xj7ojQEAm7Vx6rYhTnv0
L7a+yWQCdjvpbUNwiFa3sz5KU0jPrwA=
=Jx4b
-----END PGP SIGNATURE-----
Merge tag 'renesas-r9a09g047-dt-binding-defs-tag1' into renesas-dts-for-v6.14
Renesas RZ/G3E DT Binding Definitions
DT bindings and binding definitions for the Renesas RZ/G3E (R9A09G047)
SoC, shared by driver and DT source files.
When describing the PHYs on the Falcon Ethernet breakout board mdio
nodes will be needed to describe the connections, and each mdio node
will need to contain these two properties instead. This will make the
address-cells and size-cells described in the base SoC include file
redundant and they will produce warnings, remove them.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20241023154643.4025941-2-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Enable support for the Renesas RZ/G3E (R9A09G047) SoC in the ARM64
defconfig.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20241203105005.103927-14-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Document the device tree bindings for the Renesas RZ/G3E SoC
Clock Pulse Generator (CPG).
Also define constants for the core clocks of the RZ/G3E SoC.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20241203105005.103927-5-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Document the Renesas RZ/G3E SMARC Carrier-II EVK board which is based
on the Renesas RZ/G3E SMARC SoM. The RZ/G3E SMARC Carrier-II EVK
consists of an RZ/G3E SoM module and a SMARC Carrier-II carrier board.
The SoM module sits on top of the carrier board.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20241203105005.103927-4-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
The shutdown function can be called when the display is already
unprepared. For example during reboot this trigger a kernel
backlog. Calling the drm_panel_unprepare, allow us to avoid
to trigger the kernel warning.
Fixes: 2e87bad7cd ("drm/panel: Add Synaptics R63353 panel driver")
Tested-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Link: https://lore.kernel.org/r/20241205163002.1804784-1-dario.binacchi@amarulasolutions.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241205163002.1804784-1-dario.binacchi@amarulasolutions.com
Amlogic GX reference boards shipped with Broadcom SDIO modules and
this is described in device-tree files. These boards are rare, but
their device-trees are commonly used to boot no-name Android STB's
that closely follow the vendor reference design. For cost reasons
these boxes often use non-Broadcom RTL8189ES/FS and QCA9377 SDIO
modules, and for availability reasons the chipset/module used can
change between batches of the same device.
Testing shows the only requirement for WiFi driver probe and load
is presence of the correct 'reg' value, and all Amlogic boards use
the same <1> value. Removing the 'brcm,bcm4329-fmac' compatible
allows a wider range of Android STB boards to boot from reference
design device-trees and have working WiFi. Also convert the 'brcmf'
node name to a more generic 'sdio' to reflect we are not always
using the Broadcom brcmfmac driver now.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Link: https://lore.kernel.org/r/20241127043358.3799737-1-christianshewitt@gmail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
