* Re: [PATCH 1/5] dt-bindings: iio: dac: ti,dac5571: Add DAC081C081 support
From: Laurent Pinchart @ 2024-03-26 16:50 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Jonathan Cameron, devicetree, imx, linux-arm-kernel,
Trevor Zaharichuk, Greg Lytle, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Nyekjaer, linux-iio
In-Reply-To: <20240326152927.00006229@Huawei.com>
On Tue, Mar 26, 2024 at 03:29:27PM +0000, Jonathan Cameron wrote:
> On Mon, 25 Mar 2024 22:56:41 +0200 Laurent Pinchart wrote:
> > On Mon, Mar 25, 2024 at 08:48:57PM +0000, Jonathan Cameron wrote:
> > > On Mon, 25 Mar 2024 22:32:41 +0200 Laurent Pinchart wrote:
> > >
> > > > The DAC081C081 is a TI DAC whose software interface is compatible with
> > > > the DAC5571. It is the 8-bit version of the DAC121C081, already
> > > > supported by the DAC5571 bindings. Extends the bindings to support this
> > > > chip.
> > > >
> > > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > >
> > > Hi Laurent,
> > >
> > > Given it's a part number where no one is going to guess it is compatible
> > > with the DAC5571 and that we don't have a history of fallback compatibles
> > > I'm fine with this change, but just wanted to ask is a fallback compatible
> > > useful to you to run with older kernels?
> > >
> > > I should have noticed when Peter added the dac121c081. If we add a fallback
> > > should do that one as well.
> >
> > I've indeed noticed that there should have been a fallback for
> > dac121c081, but didn't stop to ponder why that wasn't the case, and just
> > went along with the flow :-) I agree a fallback could be useful, which
> > would then allow dropping patch 2/5 from this series (*). I can do so if
> > you prefer.
> >
> > * This is not entirely true. While the DAC1081C081 is largely compatible
> > with the DAC5573, they have different values for one of the power-down
> > resistors (2.5kΩ instead of 1kΩ if I recall correctly). To be completely
> > accurate, the driver should report that. We could still use the fallback
> > compatible, reporting the wrong power-down resistor value.
>
> Hmm - Would anyone really care about that value being wrong?
I don't have enough expertise with IIO to be sure, but my guess is that
nobody would.
> I think perhaps that's just about significant enough that maybe a fallback
> compatible doesn't make sense here.
Then let's keep it simple and just merge this patch as-is ? :-)
> > > > ---
> > > > Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> > > > index 79da0323c327..e59db861e2eb 100644
> > > > --- a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> > > > +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> > > > @@ -21,6 +21,7 @@ properties:
> > > > - ti,dac5573
> > > > - ti,dac6573
> > > > - ti,dac7573
> > > > + - ti,dac081c081
> > > > - ti,dac121c081
> > > >
> > > > reg:
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 1/4] arm64: defconfig: support Mali CSF-based GPUs
From: Sebastian Reichel @ 2024-03-26 16:52 UTC (permalink / raw)
To: Heiko Stuebner, linux-rockchip
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Boris Brezillon,
devicetree, linux-kernel, Sebastian Reichel, kernel
In-Reply-To: <20240326165232.73585-1-sebastian.reichel@collabora.com>
Enable support for Mali CSF-based GPUs, which is found on recent
ARM SoCs, such as Rockchip or Mediatek.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2c30d617e180..65e33174f813 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -907,6 +907,7 @@ CONFIG_DRM_MESON=m
CONFIG_DRM_PL111=m
CONFIG_DRM_LIMA=m
CONFIG_DRM_PANFROST=m
+CONFIG_DRM_PANTHOR=m
CONFIG_DRM_TIDSS=m
CONFIG_DRM_POWERVR=m
CONFIG_FB=y
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/4] RK3588 GPU support
From: Sebastian Reichel @ 2024-03-26 16:52 UTC (permalink / raw)
To: Heiko Stuebner, linux-rockchip
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Boris Brezillon,
devicetree, linux-kernel, Sebastian Reichel, kernel
Hi,
Panthor has landed in linux-next including the DT bindings, so it is
time to add the necessary DT changes to support the GPU on RK3588.
This adds support at SoC level and support for the EVB1 as well as
the Rock 5B, which covers both variants found in RK3588 boards:
1. Having dedicated regulators for GPU core and GPU memory. This
is handled by coupling both regulators.
2. Having a shared regulator for GPU core and GPU memory.
I prepared a branch with the GPU DT changes (and the panthor driver
changes for testing, consdering they do not clash) based on Heiko's
for-next branch:
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rk3588-gpu
Changes since PATCHv1:
- https://lore.kernel.org/all/20240325153850.189128-1-sebastian.reichel@collabora.com/
- remove always-on from the GPU regulator in the Rock 5B patch
- add comment to the always-on for the GPU regulators in the EVB1 patch
- add explanation for the always-on in the EVB1 commit description
Greetings,
-- Sebastian
Boris Brezillon (3):
arm64: dts: rockchip: rk3588: Add GPU nodes
arm64: dts: rockchip: rk3588-rock5b: Enable GPU
arm64: dts: rockchip: rk3588-evb1: Enable GPU
Sebastian Reichel (1):
arm64: defconfig: support Mali CSF-based GPUs
.../boot/dts/rockchip/rk3588-evb1-v10.dts | 14 +++++
.../boot/dts/rockchip/rk3588-rock-5b.dts | 5 ++
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 56 +++++++++++++++++++
arch/arm64/configs/defconfig | 1 +
4 files changed, 76 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH v2 2/4] arm64: dts: rockchip: rk3588: Add GPU nodes
From: Sebastian Reichel @ 2024-03-26 16:52 UTC (permalink / raw)
To: Heiko Stuebner, linux-rockchip
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Boris Brezillon,
devicetree, linux-kernel, kernel, Sebastian Reichel
In-Reply-To: <20240326165232.73585-1-sebastian.reichel@collabora.com>
From: Boris Brezillon <boris.brezillon@collabora.com>
Add Mali GPU Node to the RK3588 SoC DT including GPU clock
operating points
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 56 +++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
index 87b83c87bd55..89d40cff635f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
@@ -501,6 +501,62 @@ usb_host2_xhci: usb@fcd00000 {
status = "disabled";
};
+ gpu: gpu@fb000000 {
+ compatible = "rockchip,rk3588-mali", "arm,mali-valhall-csf";
+ reg = <0x0 0xfb000000 0x0 0x200000>;
+ #cooling-cells = <2>;
+ assigned-clocks = <&scmi_clk SCMI_CLK_GPU>;
+ assigned-clock-rates = <200000000>;
+ clocks = <&cru CLK_GPU>, <&cru CLK_GPU_COREGROUP>,
+ <&cru CLK_GPU_STACKS>;
+ clock-names = "core", "coregroup", "stacks";
+ dynamic-power-coefficient = <2982>;
+ interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "job", "mmu", "gpu";
+ operating-points-v2 = <&gpu_opp_table>;
+ power-domains = <&power RK3588_PD_GPU>;
+ status = "disabled";
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <675000 675000 850000>;
+ };
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <675000 675000 850000>;
+ };
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <675000 675000 850000>;
+ };
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <675000 675000 850000>;
+ };
+ opp-700000000 {
+ opp-hz = /bits/ 64 <700000000>;
+ opp-microvolt = <700000 700000 850000>;
+ };
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <750000 750000 850000>;
+ };
+ opp-900000000 {
+ opp-hz = /bits/ 64 <900000000>;
+ opp-microvolt = <800000 800000 850000>;
+ };
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <850000 850000 850000>;
+ };
+ };
+ };
+
pmu1grf: syscon@fd58a000 {
compatible = "rockchip,rk3588-pmugrf", "syscon", "simple-mfd";
reg = <0x0 0xfd58a000 0x0 0x10000>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/4] arm64: dts: rockchip: rk3588-rock5b: Enable GPU
From: Sebastian Reichel @ 2024-03-26 16:52 UTC (permalink / raw)
To: Heiko Stuebner, linux-rockchip
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Boris Brezillon,
devicetree, linux-kernel, kernel, Sebastian Reichel
In-Reply-To: <20240326165232.73585-1-sebastian.reichel@collabora.com>
From: Boris Brezillon <boris.brezillon@collabora.com>
Enable the Mali GPU in the Rock 5B.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
index 1fe8b2a0ed75..d6bf2ee07e87 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
@@ -180,6 +180,11 @@ &cpu_l3 {
cpu-supply = <&vdd_cpu_lit_s0>;
};
+&gpu {
+ mali-supply = <&vdd_gpu_s0>;
+ status = "okay";
+};
+
&i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0m2_xfer>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/4] arm64: dts: rockchip: rk3588-evb1: Enable GPU
From: Sebastian Reichel @ 2024-03-26 16:52 UTC (permalink / raw)
To: Heiko Stuebner, linux-rockchip
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Boris Brezillon,
devicetree, linux-kernel, kernel, Sebastian Reichel
In-Reply-To: <20240326165232.73585-1-sebastian.reichel@collabora.com>
From: Boris Brezillon <boris.brezillon@collabora.com>
Enable the Mali GPU in the RK3588 EVB1.
This marks the GPU regulators as always-on, because the generic
coupler regulator logic from the kernel can only handle them
when they are marked as always-on. Technically it's okay to
disable the regulators, when the GPU is not used.
Considering the RK3588 EVB1 is not battery powered, the slightly
increased power consumption for keeping the regulator always
enabled is not a big deal. Thus it's better to enable GPU support
than wait for a better solution.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
index de30c2632b8e..56c019b25fa8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts
@@ -281,6 +281,12 @@ &gmac0_rgmii_clk
status = "okay";
};
+&gpu {
+ mali-supply = <&vdd_gpu_s0>;
+ sram-supply = <&vdd_gpu_mem_s0>;
+ status = "okay";
+};
+
&i2c2 {
status = "okay";
@@ -484,12 +490,16 @@ rk806_dvs3_null: dvs3-null-pins {
regulators {
vdd_gpu_s0: dcdc-reg1 {
+ /* regulator coupling requires always-on */
+ regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <550000>;
regulator-max-microvolt = <950000>;
regulator-ramp-delay = <12500>;
regulator-name = "vdd_gpu_s0";
regulator-enable-ramp-delay = <400>;
+ regulator-coupled-with = <&vdd_gpu_mem_s0>;
+ regulator-coupled-max-spread = <10000>;
regulator-state-mem {
regulator-off-in-suspend;
};
@@ -534,12 +544,16 @@ regulator-state-mem {
};
vdd_gpu_mem_s0: dcdc-reg5 {
+ /* regulator coupling requires always-on */
+ regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <675000>;
regulator-max-microvolt = <950000>;
regulator-ramp-delay = <12500>;
regulator-enable-ramp-delay = <400>;
regulator-name = "vdd_gpu_mem_s0";
+ regulator-coupled-with = <&vdd_gpu_s0>;
+ regulator-coupled-max-spread = <10000>;
regulator-state-mem {
regulator-off-in-suspend;
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] ARM: dts: exynos4212-tab3: limit usable memory range
From: Krzysztof Kozlowski @ 2024-03-26 16:54 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alim Akhtar,
Artur Weber
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <20240217-tab3-limit-usable-memory-range-v1-1-49cc9c86a5cc@gmail.com>
On Sat, 17 Feb 2024 20:02:47 +0100, Artur Weber wrote:
> The stock bootloader on the Samsung Galaxy Tab 3 8.0 provides an
> incorrect available memory range over ATAG_MEM. Limit the usable
> memory in the DTS to prevent it from doing so, without having to
> disable ATAG support.
>
>
Applied, thanks!
[1/1] ARM: dts: exynos4212-tab3: limit usable memory range
https://git.kernel.org/krzk/linux/c/7bff1d35c1294c011b0269b8eaeb8f930df386fe
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
^ permalink raw reply
* Re: [PATCH v3 4/4] virt: vmgenid: add support for devicetree bindings
From: Krzysztof Kozlowski @ 2024-03-26 16:56 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Sudan Landge, tytso, robh+dt, krzysztof.kozlowski+dt, conor+dt,
sathyanarayanan.kuppuswamy, thomas.lendacky, dan.j.williams,
devicetree, linux-kernel, graf, dwmw, bchalios, xmarcalx
In-Reply-To: <ZgLXQ0P8aDl4Xh21@zx2c4.com>
On 26/03/2024 15:10, Jason A. Donenfeld wrote:
> On Mon, Mar 25, 2024 at 10:51:25PM +0100, Krzysztof Kozlowski wrote:
>>> .owner = THIS_MODULE,
>>
>> This is clearly some abandoned driver... sigh... I thought we get rid of
>> all this owner crap. Many years ago. How could it appear back if
>> automated tools report it?
>>
>> Considering how many failures LKP reported for your patchsets, I have
>> real doubts that anyone actually tests this code.
>
> Now you're commenting on the context rather than the patch.
>
> No, this isn't an abandoned driver, no it's not untested. Rather, it's
> code I maintain, care deeply about, and have a tree that receives quite
> a bit of testing (random.git) where I'll be taking these OF patches in
> the case that this patchset improves (and thanks very much for your
I apologize. I jumped too fast to conclusions and missed important point
- acpi drivers do need to set the owner. I am sorry.
(platform driver do not need, but that's a different thing)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 09/15] media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface
From: Dave Stevenson @ 2024-03-26 17:01 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Sakari Ailus, linux-media, David Plowman, Jean-Michel Hautbois,
Hans Verkuil, Naushir Patuck, kernel-list, linux-rpi-kernel,
Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Conor Dooley, Krzysztof Kozlowski,
Rob Herring, devicetree
In-Reply-To: <20240326164250.GA28895@pendragon.ideasonboard.com>
On Tue, 26 Mar 2024 at 16:42, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Dave,
>
> On Tue, Mar 26, 2024 at 03:23:42PM +0000, Dave Stevenson wrote:
> > On Tue, 26 Mar 2024 at 01:37, Laurent Pinchart wrote:
> > > On Mon, Mar 25, 2024 at 06:36:49PM +0000, Sakari Ailus wrote:
> > > > On Fri, Mar 01, 2024 at 11:32:24PM +0200, Laurent Pinchart wrote:
> > > > > From: Dave Stevenson <dave.stevenson@raspberrypi.com>
> > > > >
> > > > > Add a driver for the Unicam camera receiver block on BCM283x processors.
> > > > > It is represented as two video device nodes: unicam-image and
> > > > > unicam-embedded which are connected to an internal subdev (named
> > > > > unicam-subdev) in order to manage streams routing.
> > > > >
> > > > > Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> > > > > Co-developed-by: Naushir Patuck <naush@raspberrypi.com>
> > > > > Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
> > > > > Co-developed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
> > > > > Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
> > > > > Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > >
> > > > Thanks for submitting this, it's the cleanest and neatest Unicom driver
> > >
> > > Unicam, or if you insist Unicorn, but not Unicom :-)
> > >
> > > > I've ever seen!
> > > >
> > > > Some mostly unimportant comments below, however the bus-type issue needs to
> > > > be addressed.
> > > >
> > > > > ---
> > > > > Changes since v5:
> > > > >
> > > > > - Move to drivers/media/platform/broadcom/
> > > > > - Port to the upstream V4L2 streams API
> > > > > - Rebase on latest metadata API proposal
> > > > > - Add missing error message
> > > > > - Drop unneeded documentation block for unicam_isr()
> > > > > - Drop unneeded dev_dbg() and dev_err() messages
> > > > > - Drop unneeded streams_mask and fmt checks
> > > > > - Drop unused unicam_sd_pad_is_sink()
> > > > > - Drop unneeded includes
> > > > > - Drop v4l2_ctrl_subscribe_event() call
> > > > > - Use pm_runtime_resume_and_get()
> > > > > - Indentation and line wrap fixes
> > > > > - Let the framework set bus_info
> > > > > - Use v4l2_fwnode_endpoint_parse()
> > > > > - Fix media device cleanup
> > > > > - Drop lane reordering checks
> > > > > - Fix subdev state locking
> > > > > - Drop extra debug messages
> > > > > - Move clock handling to runtime PM handlers
> > > > > - Reorder functions
> > > > > - Rename init functions for more clarity
> > > > > - Initialize runtime PM earlier
> > > > > - Clarify error messages
> > > > > - Simplify subdev init with local variable
> > > > > - Fix subdev cleanup
> > > > > - Fix typos and indentation
> > > > > - Don't initialize local variables needlessly
> > > > > - Simplify num lanes check
> > > > > - Fix metadata handling in subdev set_fmt
> > > > > - Drop manual fallback to .s_stream()
> > > > > - Pass v4l2_pix_format to unicam_calc_format_size_bpl()
> > > > > - Simplify unicam_set_default_format()
> > > > > - Fix default format settings
> > > > > - Add busy check in unicam_s_fmt_meta()
> > > > > - Add missing \n at end of format strings
> > > > > - Fix metadata handling in subdev set_fmt
> > > > > - Fix locking when starting streaming
> > > > > - Return buffers from start streaming fails
> > > > > - Fix format validation for metadata node
> > > > > - Use video_device_pipeline_{start,stop}() helpers
> > > > > - Simplify format enumeration
> > > > > - Drop unset variable
> > > > > - Update MAINTAINERS entry
> > > > > - Update to the upstream v4l2_async_nf API
> > > > > - Update to the latest subdev routing API
> > > > > - Update to the latest subdev state API
> > > > > - Move from subdev .init_cfg() to .init_state()
> > > > > - Update to the latest videobuf2 API
> > > > > - Fix v4l2_subdev_enable_streams() error check
> > > > > - Use correct pad for the connected subdev
> > > > > - Return buffers to vb2 when start streaming fails
> > > > > - Improve debugging in start streaming handler
> > > > > - Simplify DMA address management
> > > > > - Drop comment about bcm2835-camera driver
> > > > > - Clarify comments that explain min/max sizes
> > > > > - Pass v4l2_pix_format to unicam_try_fmt()
> > > > > - Drop unneeded local variables
> > > > > - Rename image-related constants and functions
> > > > > - Turn unicam_fmt.metadata_fmt into bool
> > > > > - Rename unicam_fmt to unicam_format_info
> > > > > - Rename unicam_format_info variables to fmtinfo
> > > > > - Rename unicam_node.v_fmt to fmt
> > > > > - Add metadata formats for RAW10, RAW12 and RAW14
> > > > > - Make metadata formats line-based
> > > > > - Validate format on metadata video device
> > > > > - Add Co-devlopped-by tags
> > > > >
> > > > > Changes since v3:
> > > > >
> > > > > - Add the vendor prefix for DT name
> > > > > - Use the reg-names in DT parsing
> > > > > - Remove MAINTAINERS entry
> > > > >
> > > > > Changes since v2:
> > > > >
> > > > > - Change code organization
> > > > > - Remove unused variables
> > > > > - Correct the fmt_meta functions
> > > > > - Rewrite the start/stop streaming
> > > > > - You can now start the image node alone, but not the metadata one
> > > > > - The buffers are allocated per-node
> > > > > - only the required stream is started, if the route exists and is
> > > > > enabled
> > > > > - Prefix the macros with UNICAM_ to not have too generic names
> > > > > - Drop colorspace support
> > > > >
> > > > > Changes since v1:
> > > > >
> > > > > - Replace the unicam_{info,debug,error} macros with dev_*()
> > > > > ---
> > > > > MAINTAINERS | 1 +
> > > > > drivers/media/platform/Kconfig | 1 +
> > > > > drivers/media/platform/Makefile | 1 +
> > > > > drivers/media/platform/broadcom/Kconfig | 23 +
> > > > > drivers/media/platform/broadcom/Makefile | 3 +
> > > > > .../platform/broadcom/bcm2835-unicam-regs.h | 255 ++
> > > > > .../media/platform/broadcom/bcm2835-unicam.c | 2607 +++++++++++++++++
> > > > > 7 files changed, 2891 insertions(+)
> > > > > create mode 100644 drivers/media/platform/broadcom/Kconfig
> > > > > create mode 100644 drivers/media/platform/broadcom/Makefile
> > > > > create mode 100644 drivers/media/platform/broadcom/bcm2835-unicam-regs.h
> > > > > create mode 100644 drivers/media/platform/broadcom/bcm2835-unicam.c
> > > > >
> > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > index e50a59654e6e..cc350729f467 100644
> > > > > --- a/MAINTAINERS
> > > > > +++ b/MAINTAINERS
> > > > > @@ -4002,6 +4002,7 @@ M: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com>
> > > > > L: linux-media@vger.kernel.org
> > > > > S: Maintained
> > > > > F: Documentation/devicetree/bindings/media/brcm,bcm2835-unicam.yaml
> > > > > +F: drivers/media/platform/bcm2835/
> > > > >
> > > > > BROADCOM BCM47XX MIPS ARCHITECTURE
> > > > > M: Hauke Mehrtens <hauke@hauke-m.de>
> > > > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > > > > index 91e54215de3a..2d79bfc68c15 100644
> > > > > --- a/drivers/media/platform/Kconfig
> > > > > +++ b/drivers/media/platform/Kconfig
> > > > > @@ -67,6 +67,7 @@ source "drivers/media/platform/amlogic/Kconfig"
> > > > > source "drivers/media/platform/amphion/Kconfig"
> > > > > source "drivers/media/platform/aspeed/Kconfig"
> > > > > source "drivers/media/platform/atmel/Kconfig"
> > > > > +source "drivers/media/platform/broadcom/Kconfig"
> > > > > source "drivers/media/platform/cadence/Kconfig"
> > > > > source "drivers/media/platform/chips-media/Kconfig"
> > > > > source "drivers/media/platform/intel/Kconfig"
> > > > > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> > > > > index 3296ec1ebe16..da17301f7439 100644
> > > > > --- a/drivers/media/platform/Makefile
> > > > > +++ b/drivers/media/platform/Makefile
> > > > > @@ -10,6 +10,7 @@ obj-y += amlogic/
> > > > > obj-y += amphion/
> > > > > obj-y += aspeed/
> > > > > obj-y += atmel/
> > > > > +obj-y += broadcom/
> > > > > obj-y += cadence/
> > > > > obj-y += chips-media/
> > > > > obj-y += intel/
> > > > > diff --git a/drivers/media/platform/broadcom/Kconfig b/drivers/media/platform/broadcom/Kconfig
> > > > > new file mode 100644
> > > > > index 000000000000..cc2c9afcc948
> > > > > --- /dev/null
> > > > > +++ b/drivers/media/platform/broadcom/Kconfig
> > > > > @@ -0,0 +1,23 @@
> > > > > +# SPDX-License-Identifier: GPL-2.0
> > > > > +
> > > > > +config VIDEO_BCM2835_UNICAM
> > > > > + tristate "Broadcom BCM283x/BCM271x Unicam video capture driver"
> > > > > + depends on ARCH_BCM2835 || COMPILE_TEST
> > > > > + depends on PM
> > > > > + depends on VIDEO_DEV
> > > > > + select MEDIA_CONTROLLER
> > > > > + select V4L2_FWNODE
> > > > > + select VIDEO_V4L2_SUBDEV_API
> > > > > + select VIDEOBUF2_DMA_CONTIG
> > > > > + help
> > > > > + Say Y here to enable support for the BCM283x/BCM271x CSI-2 receiver.
> > > > > + This is a V4L2 driver that controls the CSI-2 receiver directly,
> > > > > + independently from the VC4 firmware.
> > > > > +
> > > > > + This driver is mutually exclusive with the use of bcm2835-camera. The
> > > > > + firmware will disable all access to the peripheral from within the
> > > > > + firmware if it finds a DT node using it, and bcm2835-camera will
> > > > > + therefore fail to probe.
> > > > > +
> > > > > + To compile this driver as a module, choose M here. The module will be
> > > > > + called bcm2835-unicam.
> > > > > diff --git a/drivers/media/platform/broadcom/Makefile b/drivers/media/platform/broadcom/Makefile
> > > > > new file mode 100644
> > > > > index 000000000000..03d2045aba2e
> > > > > --- /dev/null
> > > > > +++ b/drivers/media/platform/broadcom/Makefile
> > > > > @@ -0,0 +1,3 @@
> > > > > +# SPDX-License-Identifier: GPL-2.0
> > > > > +
> > > > > +obj-$(CONFIG_VIDEO_BCM2835_UNICAM) += bcm2835-unicam.o
> > > > > diff --git a/drivers/media/platform/broadcom/bcm2835-unicam-regs.h b/drivers/media/platform/broadcom/bcm2835-unicam-regs.h
> > > > > new file mode 100644
> > > > > index 000000000000..84775fd2fac5
> > > > > --- /dev/null
> > > > > +++ b/drivers/media/platform/broadcom/bcm2835-unicam-regs.h
> > > > > @@ -0,0 +1,255 @@
> > > > > +/* SPDX-License-Identifier: GPL-2.0-only */
> > > > > +
> > > > > +/*
> > > > > + * Copyright (C) 2017-2020 Raspberry Pi Trading.
> > > >
> > > > Anything up to 2024?
> > >
> > > Not really. The registers haven't really changed :-) I'll update the
> > > copyright in the .c file though.
> > >
> > > > > + * Dave Stevenson <dave.stevenson@raspberrypi.com>
> > > > > + */
> > >
> > > [snip]
> > >
> > > > > diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/media/platform/broadcom/bcm2835-unicam.c
> > > > > new file mode 100644
> > > > > index 000000000000..716c89b8a217
> > > > > --- /dev/null
> > > > > +++ b/drivers/media/platform/broadcom/bcm2835-unicam.c
> > > > > @@ -0,0 +1,2607 @@
> > >
> > > [snip]
> > >
> > > > > +static irqreturn_t unicam_isr(int irq, void *dev)
> > > > > +{
> > > > > + struct unicam_device *unicam = dev;
> > > > > + unsigned int lines_done = unicam_get_lines_done(dev);
> > > > > + unsigned int sequence = unicam->sequence;
> > > > > + unsigned int i;
> > > > > + u32 ista, sta;
> > > > > + bool fe;
> > > > > + u64 ts;
> > > > > +
> > > > > + sta = unicam_reg_read(unicam, UNICAM_STA);
> > > > > + /* Write value back to clear the interrupts */
> > > > > + unicam_reg_write(unicam, UNICAM_STA, sta);
> > > > > +
> > > > > + ista = unicam_reg_read(unicam, UNICAM_ISTA);
> > > > > + /* Write value back to clear the interrupts */
> > > > > + unicam_reg_write(unicam, UNICAM_ISTA, ista);
> > > > > +
> > > > > + dev_dbg(unicam->dev, "ISR: ISTA: 0x%X, STA: 0x%X, sequence %d, lines done %d\n",
> > > > > + ista, sta, sequence, lines_done);
> > > > > +
> > > > > + if (!(sta & (UNICAM_IS | UNICAM_PI0)))
> > > > > + return IRQ_HANDLED;
> > > > > +
> > > > > + /*
> > > > > + * Look for either the Frame End interrupt or the Packet Capture status
> > > > > + * to signal a frame end.
> > > > > + */
> > > > > + fe = ista & UNICAM_FEI || sta & UNICAM_PI0;
> > > > > +
> > > > > + /*
> > > > > + * We must run the frame end handler first. If we have a valid next_frm
> > > > > + * and we get a simultaneout FE + FS interrupt, running the FS handler
> > > > > + * first would null out the next_frm ptr and we would have lost the
> > > > > + * buffer forever.
> > > > > + */
> > > > > + if (fe) {
> > > > > + /*
> > > > > + * Ensure we have swapped buffers already as we can't
> > > > > + * stop the peripheral. If no buffer is available, use a
> > > > > + * dummy buffer to dump out frames until we get a new buffer
> > > > > + * to use.
> > > > > + */
> > > > > + for (i = 0; i < ARRAY_SIZE(unicam->node); i++) {
> > > > > + if (!unicam->node[i].streaming)
> > > > > + continue;
> > > > > +
> > > > > + /*
> > > > > + * If cur_frm == next_frm, it means we have not had
> > > > > + * a chance to swap buffers, likely due to having
> > > > > + * multiple interrupts occurring simultaneously (like FE
> > > > > + * + FS + LS). In this case, we cannot signal the buffer
> > > > > + * as complete, as the HW will reuse that buffer.
> > > > > + */
> > > > > + if (unicam->node[i].cur_frm &&
> > > > > + unicam->node[i].cur_frm != unicam->node[i].next_frm)
> > > > > + unicam_process_buffer_complete(&unicam->node[i],
> > > > > + sequence);
> > > > > + unicam->node[i].cur_frm = unicam->node[i].next_frm;
> > > > > + }
> > > > > + unicam->sequence++;
> > > >
> > > > Does access to this data need to be serialised somehow.
> > >
> > > Given that it's only accessed from the interrupt handler (beside
> > > start_streaming time, before starting the hardware), I don't think so.
> > >
> > > > > + }
> > > > > +
> > > > > + if (ista & UNICAM_FSI) {
> > > > > + /*
> > > > > + * Timestamp is to be when the first data byte was captured,
> > > > > + * aka frame start.
> > > > > + */
> > > > > + ts = ktime_get_ns();
> > > > > + for (i = 0; i < ARRAY_SIZE(unicam->node); i++) {
> > > > > + if (!unicam->node[i].streaming)
> > > > > + continue;
> > > > > +
> > > > > + if (unicam->node[i].cur_frm)
> > > > > + unicam->node[i].cur_frm->vb.vb2_buf.timestamp =
> > > > > + ts;
> > > > > + else
> > > > > + dev_dbg(unicam->v4l2_dev.dev,
> > > > > + "ISR: [%d] Dropping frame, buffer not available at FS\n",
> > > > > + i);
> > > > > + /*
> > > > > + * Set the next frame output to go to a dummy frame
> > > > > + * if we have not managed to obtain another frame
> > > > > + * from the queue.
> > > > > + */
> > > > > + unicam_schedule_dummy_buffer(&unicam->node[i]);
> > > > > + }
> > > > > +
> > > > > + unicam_queue_event_sof(unicam);
> > > > > + }
> > > > > +
> > > > > + /*
> > > > > + * Cannot swap buffer at frame end, there may be a race condition
> > > > > + * where the HW does not actually swap it if the new frame has
> > > > > + * already started.
> > > > > + */
> > > > > + if (ista & (UNICAM_FSI | UNICAM_LCI) && !fe) {
> > > > > + for (i = 0; i < ARRAY_SIZE(unicam->node); i++) {
> > > > > + if (!unicam->node[i].streaming)
> > > > > + continue;
> > > > > +
> > > > > + spin_lock(&unicam->node[i].dma_queue_lock);
> > > > > + if (!list_empty(&unicam->node[i].dma_queue) &&
> > > > > + !unicam->node[i].next_frm)
> > > > > + unicam_schedule_next_buffer(&unicam->node[i]);
> > > > > + spin_unlock(&unicam->node[i].dma_queue_lock);
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + if (unicam_reg_read(unicam, UNICAM_ICTL) & UNICAM_FCM) {
> > > > > + /* Switch out of trigger mode if selected */
> > > > > + unicam_reg_write_field(unicam, UNICAM_ICTL, 1, UNICAM_TFC);
> > > > > + unicam_reg_write_field(unicam, UNICAM_ICTL, 0, UNICAM_FCM);
> > > > > + }
> > > > > + return IRQ_HANDLED;
> > > > > +}
> > > > > +
> > > > > +static void unicam_set_packing_config(struct unicam_device *unicam)
> > > > > +{
> > > > > + struct unicam_node *node = &unicam->node[UNICAM_IMAGE_NODE];
> > > > > + u32 pack, unpack;
> > > > > + u32 val;
> > > > > +
> > > > > + if (node->fmt.fmt.pix.pixelformat == node->fmtinfo->fourcc) {
> > > > > + unpack = UNICAM_PUM_NONE;
> > > > > + pack = UNICAM_PPM_NONE;
> > > > > + } else {
> > > > > + switch (node->fmtinfo->depth) {
> > > > > + case 8:
> > > > > + unpack = UNICAM_PUM_UNPACK8;
> > > > > + break;
> > > > > + case 10:
> > > > > + unpack = UNICAM_PUM_UNPACK10;
> > > > > + break;
> > > > > + case 12:
> > > > > + unpack = UNICAM_PUM_UNPACK12;
> > > > > + break;
> > > > > + case 14:
> > > > > + unpack = UNICAM_PUM_UNPACK14;
> > > > > + break;
> > > > > + case 16:
> > > > > + unpack = UNICAM_PUM_UNPACK16;
> > > > > + break;
> > > > > + default:
> > > > > + unpack = UNICAM_PUM_NONE;
> > > > > + break;
> > > > > + }
> > > > > +
> > > > > + /* Repacking is always to 16bpp */
> > > > > + pack = UNICAM_PPM_PACK16;
> > > >
> > > > Also 8-bit data?
> > >
> > > Not that I know of. The 8-bit entries in unicam_image_formats have no
> > > .unpacked_fourcc field, so the condition in the if above will always be
> > > true for those as they can only be selected by setting the pixel format
> > > to fmtinfo->fourcc.
> >
> > Correct.
> > The unpacking / packing doesn't bit shift, hence 10P can be unpacked
> > to 10, 12P to 12, and 14P to 14, but there is no 8bit unpacked into
> > the LSBs of 16 bit words defined as a V4L2 format.
> >
> > You can configure packing to produce 10P, 12P, etc, but without the
> > bitshift it has no real use.
> >
> > MSBs get dropped if you try packing to a smaller bit depth than the
> > source, so packing to 8 bit from any other depth results in unusable
> > output.
> >
> > If being really critical, then there is no point in having the case 8
> > and case 16 in this switch as they will never be selected.
>
> As we have space to spare in the unicam_format_info structure due to
> padding, I'll move the unpack value there and drop the switch.
As it ends up being a 1:1 mapping, that would work.
Originally I believed unicam did the bit-shifting which made offering
the flexibility useful, but that proved to be wrong.
Dave
> > > > > + }
> >
> > <snip>
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v6 04/16] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390
From: Johan Hovold @ 2024-03-26 17:05 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kalle Valo, Marcel Holtmann, Luiz Augusto von Dentz,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Liam Girdwood, Mark Brown, Catalin Marinas,
Will Deacon, Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven,
Arnd Bergmann, Neil Armstrong, Marek Szyprowski, Alex Elder,
Srini Kandagatla, Greg Kroah-Hartman, Abel Vesa,
Manivannan Sadhasivam, Lukas Wunner, Dmitry Baryshkov,
linux-bluetooth, netdev, devicetree, linux-kernel, linux-wireless,
linux-arm-msm, linux-arm-kernel, linux-pci, linux-pm,
Bartosz Golaszewski, ath11k
In-Reply-To: <CAMRc=Me5ef_kFDz0SyGZb4S+2Ma4i=Fek_tzwj+bYD4DGSV4mA@mail.gmail.com>
On Tue, Mar 26, 2024 at 05:32:55PM +0100, Bartosz Golaszewski wrote:
> On Tue, Mar 26, 2024 at 4:12 PM Kalle Valo <kvalo@kernel.org> wrote:
> > >> Adding also Johan and ath11k list. For example, I don't know what's the
> > >> plan with Lenovo X13s, will it use this framework? I guess in theory we
> > >> could have devices which use qcom,ath11k-calibration-variant from DT but
> > >> not any of these supply properties?
> > >
> > > Good point. I will receive the X13s in a month from now. I do plan on
> > > upstreaming correct support for WLAN and BT for it as well.
> > >
> > > I guess we can always relax the requirements once a valid use-case appears?
> >
> > I think we have such cases already now:
> >
> > $ git grep ath11k-calibration-variant -- arch
> > arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts: qcom,ath11k-calibration-variant = "Fairphone_5";
> > arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts: qcom,ath11k-calibration-variant = "LE_X13S";
> >
> > But please do check that. I'm no DT expert :)
>
> You're thinking about making the required: field depend on the value
> of qcom,ath11k-calibration-variant? Am I getting this right?
No, I think Kalle is worried about requiring the supply properties for
certain PCI device ids, in case we have existing or future devicetrees
with those ids that did not specify them or that need not specify them
(e.g. any PC modules).
Currently we only have the X13s controller in mainline being described
by a PCIe endpoint node in DT, but it has a different id ("pci17cb,1103"
instead of "pci17cb,1101" which you are adding here).
The Fairphone controller is apparently not a PCI device at all.
Johan
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: iio: dac: ti,dac5571: Add DAC081C081 support
From: Jonathan Cameron @ 2024-03-26 17:13 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Jonathan Cameron, devicetree, imx, linux-arm-kernel,
Trevor Zaharichuk, Greg Lytle, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Nyekjaer, linux-iio
In-Reply-To: <20240326165043.GB28895@pendragon.ideasonboard.com>
On Tue, 26 Mar 2024 18:50:43 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> On Tue, Mar 26, 2024 at 03:29:27PM +0000, Jonathan Cameron wrote:
> > On Mon, 25 Mar 2024 22:56:41 +0200 Laurent Pinchart wrote:
> > > On Mon, Mar 25, 2024 at 08:48:57PM +0000, Jonathan Cameron wrote:
> > > > On Mon, 25 Mar 2024 22:32:41 +0200 Laurent Pinchart wrote:
> > > >
> > > > > The DAC081C081 is a TI DAC whose software interface is compatible with
> > > > > the DAC5571. It is the 8-bit version of the DAC121C081, already
> > > > > supported by the DAC5571 bindings. Extends the bindings to support this
> > > > > chip.
> > > > >
> > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > >
> > > > Hi Laurent,
> > > >
> > > > Given it's a part number where no one is going to guess it is compatible
> > > > with the DAC5571 and that we don't have a history of fallback compatibles
> > > > I'm fine with this change, but just wanted to ask is a fallback compatible
> > > > useful to you to run with older kernels?
> > > >
> > > > I should have noticed when Peter added the dac121c081. If we add a fallback
> > > > should do that one as well.
> > >
> > > I've indeed noticed that there should have been a fallback for
> > > dac121c081, but didn't stop to ponder why that wasn't the case, and just
> > > went along with the flow :-) I agree a fallback could be useful, which
> > > would then allow dropping patch 2/5 from this series (*). I can do so if
> > > you prefer.
> > >
> > > * This is not entirely true. While the DAC1081C081 is largely compatible
> > > with the DAC5573, they have different values for one of the power-down
> > > resistors (2.5kΩ instead of 1kΩ if I recall correctly). To be completely
> > > accurate, the driver should report that. We could still use the fallback
> > > compatible, reporting the wrong power-down resistor value.
> >
> > Hmm - Would anyone really care about that value being wrong?
>
> I don't have enough expertise with IIO to be sure, but my guess is that
> nobody would.
>
> > I think perhaps that's just about significant enough that maybe a fallback
> > compatible doesn't make sense here.
>
> Then let's keep it simple and just merge this patch as-is ? :-)
Makes sense. I'm on wrong computer at the moment but will pick it up at
weekend if not before.
Jonathan
>
> > > > > ---
> > > > > Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> > > > > index 79da0323c327..e59db861e2eb 100644
> > > > > --- a/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> > > > > +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac5571.yaml
> > > > > @@ -21,6 +21,7 @@ properties:
> > > > > - ti,dac5573
> > > > > - ti,dac6573
> > > > > - ti,dac7573
> > > > > + - ti,dac081c081
> > > > > - ti,dac121c081
> > > > >
> > > > > reg:
>
^ permalink raw reply
* Re: [PATCH 1/3] remoteproc: Add Arm remoteproc driver
From: Abdellatif El Khlifi @ 2024-03-26 17:14 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Abdellatif El Khlifi, Sudeep Holla, Bjorn Andersson, Rob Herring,
Liviu Dudau, Lorenzo Pieralisi, Krzysztof Kozlowski, Conor Dooley,
Drew.Reed, Adam.Johnston, linux-arm-kernel, devicetree,
linux-kernel, linux-remoteproc
In-Reply-To: <CANLsYkwOrtXxObL5MKf30OrUYB_uT=DnGEXUtfjH503r_LyMQA@mail.gmail.com>
Hi Mathieu,
> > > > > > > > > > This is an initial patchset for allowing to turn on and off the remote processor.
> > > > > > > > > > The FW is already loaded before the Corstone-1000 SoC is powered on and this
> > > > > > > > > > is done through the FPGA board bootloader in case of the FPGA target. Or by the Corstone-1000 FVP model
> > > > > > > > > > (emulator).
> > > > > > > > > >
> > > > > > > > > >From the above I take it that booting with a preloaded firmware is a
> > > > > > > > > scenario that needs to be supported and not just a temporary stage.
> > > > > > > >
> > > > > > > > The current status of the Corstone-1000 SoC requires that there is
> > > > > > > > a preloaded firmware for the external core. Preloading is done externally
> > > > > > > > either through the FPGA bootloader or the emulator (FVP) before powering
> > > > > > > > on the SoC.
> > > > > > > >
> > > > > > >
> > > > > > > Ok
> > > > > > >
> > > > > > > > Corstone-1000 will be upgraded in a way that the A core running Linux is able
> > > > > > > > to share memory with the remote core and also being able to access the remote
> > > > > > > > core memory so Linux can copy the firmware to. This HW changes are still
> > > > > > > > This is why this patchset is relying on a preloaded firmware. And it's the step 1
> > > > > > > > of adding remoteproc support for Corstone.
> > > > > > > >
> > > > > > >
> > > > > > > Ok, so there is a HW problem where A core and M core can't see each other's
> > > > > > > memory, preventing the A core from copying the firmware image to the proper
> > > > > > > location.
> > > > > > >
> > > > > > > When the HW is fixed, will there be a need to support scenarios where the
> > > > > > > firmware image has been preloaded into memory?
> > > > > >
> > > > > > No, this scenario won't apply when we get the HW upgrade. No need for an
> > > > > > external entity anymore. The firmware(s) will all be files in the linux filesystem.
> > > > > >
> > > > >
> > > > > Very well. I am willing to continue with this driver but it does so little that
> > > > > I wonder if it wouldn't simply be better to move forward with upstreaming when
> > > > > the HW is fixed. The choice is yours.
> > > > >
> > > >
> > > > I think Robin has raised few points that need clarification. I think it was
> > > > done as part of DT binding patch. I share those concerns and I wanted to
> > > > reaching to the same concerns by starting the questions I asked on corstone
> > > > device tree changes.
> > > >
> > >
> > > I also agree with Robin's point of view. Proceeding with an initial
> > > driver with minimal functionality doesn't preclude having complete
> > > bindings. But that said and as I pointed out, it might be better to
> > > wait for the HW to be fixed before moving forward.
> >
> > We checked with the HW teams. The missing features will be implemented but
> > this will take time.
> >
> > The foundation driver as it is right now is still valuable for people wanting to
> > know how to power control Corstone external systems in a future proof manner
> > (even in the incomplete state). We prefer to address all the review comments
> > made so it can be merged. This includes making the DT binding as complete as
> > possible as you advised. Then, once the HW is ready, I'll implement the comms
> > and the FW reload part. Is that OK please ?
> >
>
> I'm in agreement with that plan as long as we agree the current
> preloaded heuristic is temporary and is not a valid long term
> scenario.
Yes, that's the plan, no problem.
Cheers,
Abdellatif
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties
From: Laurent Pinchart @ 2024-03-26 17:18 UTC (permalink / raw)
To: Stefan Wahren
Cc: Krzysztof Kozlowski, devicetree, linux-rpi-kernel,
linux-arm-kernel, linux-gpio, Dave Stevenson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Linus Walleij, Bartosz Golaszewski
In-Reply-To: <45242028-edf7-49fc-80bf-be9eb242b4cd@gmx.net>
On Tue, Mar 26, 2024 at 12:47:34PM +0100, Stefan Wahren wrote:
> [add Dave since he's working on DMA for Raspberry Pi 4 and maybe have a
> opinion about this]
>
> [drop Emma Anholt old address since she is not involved anymore]
>
> Am 26.03.24 um 08:06 schrieb Krzysztof Kozlowski:
> > On 26/03/2024 01:49, Laurent Pinchart wrote:
> >> The raspberrypi,bcm2835-firmware devices requires a dma-ranges property,
> >> and, as a result, also needs to specify #address-cells and #size-cells.
> >> Those properties have been added to thebcm2835-rpi.dtsi in commits
> >> be08d278eb09 ("ARM: dts: bcm283x: Add cells encoding format to firmware
> >> bus") and 55c7c0621078 ("ARM: dts: bcm283x: Fix vc4's firmware bus DMA
> >> limitations"), but the DT bindings haven't been updated, resulting in
> >> validation errors:
> >>
> >> arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb: firmware: '#address-cells', '#size-cells', 'dma-ranges', 'gpio' do not match any of the regexes: 'pinctrl-[0-9]+'
> >> from schema $id: http://devicetree.org/schemas/arm/bcm/raspberrypi,bcm2835-firmware.yaml#
> >>
> >> Fix this by adding the properties to the bindings.
> >>
> >> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >
> > Children do not perform any IO on their own, because everything is
> > handled by parent. It is really odd to see dma-ranges without ranges.
> > Referenced commits might be also wrong.
Comunication with the firmware goes through a mailbox interface, which
uses DMA transfers. See for instance
rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
{
u32 message = MBOX_MSG(chan, data);
int ret;
WARN_ON(data & 0xf);
mutex_lock(&transaction_lock);
reinit_completion(&fw->c);
ret = mbox_send_message(fw->chan, &message);
if (ret >= 0) {
if (wait_for_completion_timeout(&fw->c, HZ)) {
ret = 0;
} else {
ret = -ETIMEDOUT;
WARN_ONCE(1, "Firmware transaction timeout");
}
} else {
dev_err(fw->cl.dev, "mbox_send_message returned %d\n", ret);
}
mutex_unlock(&transaction_lock);
return ret;
}
int rpi_firmware_property_list(struct rpi_firmware *fw,
void *data, size_t tag_size)
{
size_t size = tag_size + 12;
u32 *buf;
dma_addr_t bus_addr;
int ret;
/* Packets are processed a dword at a time. */
if (size & 3)
return -EINVAL;
buf = dma_alloc_coherent(fw->cl.dev, PAGE_ALIGN(size), &bus_addr,
GFP_ATOMIC);
if (!buf)
return -ENOMEM;
/* The firmware will error out without parsing in this case. */
WARN_ON(size >= 1024 * 1024);
buf[0] = size;
buf[1] = RPI_FIRMWARE_STATUS_REQUEST;
memcpy(&buf[2], data, tag_size);
buf[size / 4 - 1] = RPI_FIRMWARE_PROPERTY_END;
wmb();
ret = rpi_firmware_transaction(fw, MBOX_CHAN_PROPERTY, bus_addr);
rmb();
memcpy(data, &buf[2], tag_size);
if (ret == 0 && buf[1] != RPI_FIRMWARE_STATUS_SUCCESS) {
/*
* The tag name here might not be the one causing the
* error, if there were multiple tags in the request.
* But single-tag is the most common, so go with it.
*/
dev_err(fw->cl.dev, "Request 0x%08x returned status 0x%08x\n",
buf[2], buf[1]);
ret = -EINVAL;
}
dma_free_coherent(fw->cl.dev, PAGE_ALIGN(size), buf, bus_addr);
return ret;
}
fw->cl.dev is the device for the firmware child node. That may be where
the problem comes from, shouldn't we use the mailbox device for DMA
mapping ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 0/4] arm64: dts: rockchip: add wolfvision pf5 mainboard
From: Heiko Stuebner @ 2024-03-26 17:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Michael Riesch, Conor Dooley
Cc: Heiko Stuebner, linux-kernel, linux-arm-kernel, linux-rockchip,
devicetree
In-Reply-To: <20240325-feature-wolfvision-pf5-v1-0-5725445f792a@wolfvision.net>
On Mon, 25 Mar 2024 15:22:30 +0100, Michael Riesch wrote:
> Habidere,
>
> This series adds the device tree for the WolfVision PF5 mainboard, which
> serves as base for recent WolfVision products. It features the Rockchip
> RK3568 and can be extended with several different extension boards.
>
> The WolfVision PF5 IO Expander is one example of such an extension board.
> The corresponding device tree overlay is also included in this series.
>
> [...]
Applied, thanks!
[1/4] dt-bindings: add wolfvision vendor prefix
commit: 37a6d5864fb8226c97eefa59a79de57571e1fee8
[2/4] dt-bindings: arm: rockchip: add wolfvision pf5 mainboard
commit: 6be2ad17acb76c47e544864467680a7b738d7eb8
[3/4] arm64: dts: rockchip: add wolfvision pf5 mainboard
commit: 0be29f76633a447e15fc58066ea47688974e68d9
[4/4] arm64: dts: rockchip: add wolfvision pf5 io expander board
commit: 28799a7734a0e1a38d01b511ca08d33d8cf91b6c
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: (subset) [PATCH v4 0/7] Add support for the internal RK3308 audio codec
From: Heiko Stuebner @ 2024-03-26 17:25 UTC (permalink / raw)
To: Jaroslav Kysela, Krzysztof Kozlowski, Liam Girdwood,
Luca Ceresoli, Philipp Zabel, Nicolas Frattaroli, Conor Dooley,
Rob Herring, Mark Brown, Takashi Iwai
Cc: Heiko Stuebner, linux-arm-kernel, devicetree, Rob Herring,
linux-rockchip, linux-kernel, linux-sound, alsa-devel,
Thomas Petazzoni
In-Reply-To: <20240305-rk3308-audio-codec-v4-0-312acdbe628f@bootlin.com>
On Tue, 05 Mar 2024 15:36:27 +0100, Luca Ceresoli wrote:
> This series adds a driver for the internal audio codec of the Rockchip
> RK3308 SoC, along with some related patches. This codec is internally
> connected to the I2S peripherals on the same chip, and it has some
> peculiarities arising from that interconnection.
>
> For proper bidirectional operation with the internal codec at any possible
> combination of sampling rates, the I2S peripheral needs two clock sources
> (tx and rx), while connection with an external codec commonly needs only
> one.
>
> [...]
Applied, thanks!
[5/7] arm64: defconfig: enable Rockchip RK3308 internal audio codec driver
commit: 9fdd7b45da18b84d5e7d5a6b8b4b0167910f2d13
[6/7] arm64: dts: rockchip: add i2s_8ch_2 and i2s_8ch_3
commit: b5ffc424360eaced41f405f0e38bcabe61fecf39
[7/7] arm64: dts: rockchip: add the internal audio codec
commit: 30d72458624bb1ba7bab1c7a1d5f4c42f512010c
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH] dt-bindings: display: rockchip: add missing #sound-dai-cells to dw-hdmi
From: Heiko Stuebner @ 2024-03-26 17:28 UTC (permalink / raw)
To: hjc, andy.yan, robh, krzysztof.kozlowski+dt, conor+dt
Cc: dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Heiko Stuebner
The #sound-dai-cells DT property is required to describe link between
the HDMI IP block and the SoC's audio subsystem.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
.../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index af638b6c0d21..3768df80ca7a 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -124,6 +124,9 @@ properties:
description:
phandle to the GRF to mux vopl/vopb.
+ "#sound-dai-cells":
+ const: 0
+
required:
- compatible
- reg
--
2.39.2
^ permalink raw reply related
* Re: [PATCH 2/2] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add gpio child node
From: Laurent Pinchart @ 2024-03-26 17:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-gpio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Linus Walleij, Bartosz Golaszewski, Eric Anholt, Stefan Wahren
In-Reply-To: <8f4ef49a-74a1-4e05-a2fa-f6bc29e80c5c@linaro.org>
On Tue, Mar 26, 2024 at 08:09:46AM +0100, Krzysztof Kozlowski wrote:
> On 26/03/2024 01:49, Laurent Pinchart wrote:
> > Unlike the other child nodes of the raspberrypi,bcm2835-firmware device,
> > the gpio child is documented in a legacy text-based binding in
> > gpio/raspberrypi,firmware-gpio.txt. This causes DT validation failures:
>
> > + type: object
> > + additionalProperties: false
> > +
> > + properties:
> > + compatible:
> > + const: raspberrypi,firmware-gpio
> > +
> > + gpio-controller: true
> > +
> > + "#gpio-cells":
> > + const: 2
> > + description:
> > + The first cell is the pin number, and the second cell is used to
> > + specify the gpio polarity (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW).
> > +
> > + gpio-line-names: true
>
> You could provide here maxItems, if this is known, but it's fine as is
> as well.
The number of items seems to be always 8, so I'll use that value.
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties
From: Stefan Wahren @ 2024-03-26 17:40 UTC (permalink / raw)
To: Laurent Pinchart, Krzysztof Kozlowski
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-gpio,
Dave Stevenson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Linus Walleij, Bartosz Golaszewski
In-Reply-To: <20240326171837.GB17067@pendragon.ideasonboard.com>
Am 26.03.24 um 18:18 schrieb Laurent Pinchart:
> On Tue, Mar 26, 2024 at 12:47:34PM +0100, Stefan Wahren wrote:
>> [add Dave since he's working on DMA for Raspberry Pi 4 and maybe have a
>> opinion about this]
>>
>> [drop Emma Anholt old address since she is not involved anymore]
>>
>> Am 26.03.24 um 08:06 schrieb Krzysztof Kozlowski:
>>> On 26/03/2024 01:49, Laurent Pinchart wrote:
>>>> The raspberrypi,bcm2835-firmware devices requires a dma-ranges property,
>>>> and, as a result, also needs to specify #address-cells and #size-cells.
>>>> Those properties have been added to thebcm2835-rpi.dtsi in commits
>>>> be08d278eb09 ("ARM: dts: bcm283x: Add cells encoding format to firmware
>>>> bus") and 55c7c0621078 ("ARM: dts: bcm283x: Fix vc4's firmware bus DMA
>>>> limitations"), but the DT bindings haven't been updated, resulting in
>>>> validation errors:
>>>>
>>>> arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb: firmware: '#address-cells', '#size-cells', 'dma-ranges', 'gpio' do not match any of the regexes: 'pinctrl-[0-9]+'
>>>> from schema $id: http://devicetree.org/schemas/arm/bcm/raspberrypi,bcm2835-firmware.yaml#
>>>>
>>>> Fix this by adding the properties to the bindings.
>>>>
>>>> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>> Children do not perform any IO on their own, because everything is
>>> handled by parent. It is really odd to see dma-ranges without ranges.
>>> Referenced commits might be also wrong.
> Comunication with the firmware goes through a mailbox interface, which
> uses DMA transfers. See for instance
>
> rpi_firmware_transaction(struct rpi_firmware *fw, u32 chan, u32 data)
> {
> u32 message = MBOX_MSG(chan, data);
> int ret;
>
> WARN_ON(data & 0xf);
>
> mutex_lock(&transaction_lock);
> reinit_completion(&fw->c);
> ret = mbox_send_message(fw->chan, &message);
> if (ret >= 0) {
> if (wait_for_completion_timeout(&fw->c, HZ)) {
> ret = 0;
> } else {
> ret = -ETIMEDOUT;
> WARN_ONCE(1, "Firmware transaction timeout");
> }
> } else {
> dev_err(fw->cl.dev, "mbox_send_message returned %d\n", ret);
> }
> mutex_unlock(&transaction_lock);
>
> return ret;
> }
>
> int rpi_firmware_property_list(struct rpi_firmware *fw,
> void *data, size_t tag_size)
> {
> size_t size = tag_size + 12;
> u32 *buf;
> dma_addr_t bus_addr;
> int ret;
>
> /* Packets are processed a dword at a time. */
> if (size & 3)
> return -EINVAL;
>
> buf = dma_alloc_coherent(fw->cl.dev, PAGE_ALIGN(size), &bus_addr,
> GFP_ATOMIC);
> if (!buf)
> return -ENOMEM;
>
> /* The firmware will error out without parsing in this case. */
> WARN_ON(size >= 1024 * 1024);
>
> buf[0] = size;
> buf[1] = RPI_FIRMWARE_STATUS_REQUEST;
> memcpy(&buf[2], data, tag_size);
> buf[size / 4 - 1] = RPI_FIRMWARE_PROPERTY_END;
> wmb();
>
> ret = rpi_firmware_transaction(fw, MBOX_CHAN_PROPERTY, bus_addr);
>
> rmb();
> memcpy(data, &buf[2], tag_size);
> if (ret == 0 && buf[1] != RPI_FIRMWARE_STATUS_SUCCESS) {
> /*
> * The tag name here might not be the one causing the
> * error, if there were multiple tags in the request.
> * But single-tag is the most common, so go with it.
> */
> dev_err(fw->cl.dev, "Request 0x%08x returned status 0x%08x\n",
> buf[2], buf[1]);
> ret = -EINVAL;
> }
>
> dma_free_coherent(fw->cl.dev, PAGE_ALIGN(size), buf, bus_addr);
>
> return ret;
> }
>
> fw->cl.dev is the device for the firmware child node. That may be where
> the problem comes from, shouldn't we use the mailbox device for DMA
> mapping ?
>
From devicetree perspective this is the mailbox DT part [1] and this
the matching dt-binding [2].
[1] -
https://elixir.bootlin.com/linux/v6.9-rc1/source/arch/arm/boot/dts/broadcom/bcm283x.dtsi#L100
[2] -
https://elixir.bootlin.com/linux/v6.9-rc1/source/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.yaml
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
From: Marc Gonzalez @ 2024-03-26 17:45 UTC (permalink / raw)
To: Kalle Valo, Jeff Johnson
Cc: ath10k, wireless, DT, Pierre-Hugues Husson, Arnaud Vrac,
Jami Kettunen, Dmitry Baryshkov, Jeffrey Hugo, Bjorn Andersson,
Konrad Dybcio
In-Reply-To: <243a97b7-c298-4307-9f06-8b3a7c3e24fd@freebox.fr>
[ It has been pointed out to me that the previous message was unclear. ]
[ Below is my 2nd attempt at a clearer message. ]
Problem: firmware-5.bin has not been parsed yet when we have to handle
the ATH10K_QMI_EVENT_SERVER_ARRIVE case, so we can't rely on feature bits
to work around the lack of MSA_READY indicator.
On 26/03/2024 16:04, Marc Gonzalez wrote:
> QMI stuff happens much EARLIER than firmware-5.bin handling.
> (ar->running_fw is still NULL)
>
>
> [ 14.547563] ath10k_snoc 18800000.wifi: qmi wifi fw qmi service connected
> [ 14.555054] ath10k_snoc 18800000.wifi: qmi indication register request completed
> [ 14.561406] ath10k_snoc 18800000.wifi: qmi host capability request completed
> [ 14.568365] ath10k_snoc 18800000.wifi: qmi msa mem region 0 addr 0x0x0000000094400000 size 0x4000 flag 0x00000001
> [ 14.573775] ath10k_snoc 18800000.wifi: qmi msa mem region 1 addr 0x0x0000000094404000 size 0xfc000 flag 0x00000000
> [ 14.583896] ath10k_snoc 18800000.wifi: qmi msa mem info request completed
> [ 14.630179] ath10k_snoc 18800000.wifi: qmi msa mem ready request completed
> [ 14.681647] ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40010002
> [ 14.681726] ath10k_snoc 18800000.wifi: qmi fw_version 0x100204b2 fw_build_timestamp 2019-09-04 03:01 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.1.0-01202-QCAHLSWMTPLZ-1.221523.2
> *** ATH10K_QMI_EVENT_SERVER_ARRIVE is handled at this point
> [ 14.690657] ath10k_snoc 18800000.wifi: DT bdf variant name not set.
> [ 14.706423] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> [ 14.712587] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> [ 14.722309] ath10k_snoc 18800000.wifi: boot using board name 'bus=snoc,qmi-board-id=ff'
> [ 14.745634] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/board-2.bin': 0
> ... snip boards dump
> [ 15.560607] ath10k_snoc 18800000.wifi: boot found match for name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> [ 15.570590] ath10k_snoc 18800000.wifi: boot found board data for 'bus=snoc,qmi-board-id=ff,qmi-chip-id=30214'
> [ 15.580393] ath10k_snoc 18800000.wifi: using board api 2
> [ 15.591465] ath10k_snoc 18800000.wifi: qmi bdf download request completed
> [ 15.595786] ath10k_snoc 18800000.wifi: qmi cal report request completed
> [ 18.667441] ath10k_snoc 18800000.wifi: wifi fw ready event received
> [ 18.667519] ath10k_snoc 18800000.wifi: ath10k_snoc_hif_power_up:WCN3990 driver state = 0
> [ 18.672579] ath10k_snoc 18800000.wifi: soc power on
> [ 18.684550] ath10k_snoc 18800000.wifi: qmi mode 0 config 00000000313ae0ca
> [ 18.692591] ath10k_snoc 18800000.wifi: qmi config request completed
> [ 18.748262] ath10k_snoc 18800000.wifi: qmi wlan mode req completed: 0
> [ 18.748370] ath10k_snoc 18800000.wifi: boot init ce src ring id 0 entries 16 base_addr 00000000b9feff9c
> [ 18.753792] ath10k_snoc 18800000.wifi: boot ce dest ring id 1 entries 512 base_addr 000000005f850e88
> [ 18.762971] ath10k_snoc 18800000.wifi: boot ce dest ring id 2 entries 64 base_addr 000000002467084e
> [ 18.772375] ath10k_snoc 18800000.wifi: boot init ce src ring id 3 entries 32 base_addr 00000000ded78c3f
> [ 18.781122] ath10k_snoc 18800000.wifi: boot init ce src ring id 4 entries 2048 base_addr 00000000c9e8883a
> [ 18.790482] ath10k_snoc 18800000.wifi: boot ce dest ring id 5 entries 512 base_addr 00000000309e9375
> [ 18.800220] ath10k_snoc 18800000.wifi: boot init ce src ring id 7 entries 2 base_addr 00000000e5e3fb73
> [ 18.809395] ath10k_snoc 18800000.wifi: boot ce dest ring id 7 entries 2 base_addr 00000000c08890b2
> [ 18.818507] ath10k_snoc 18800000.wifi: boot ce dest ring id 8 entries 128 base_addr 000000006af0777e
> [ 18.827466] ath10k_snoc 18800000.wifi: boot ce dest ring id 9 entries 512 base_addr 00000000f2c0ce43
> [ 18.836770] ath10k_snoc 18800000.wifi: boot ce dest ring id 10 entries 512 base_addr 00000000269a2564
> [ 18.845863] ath10k_snoc 18800000.wifi: boot ce dest ring id 11 entries 512 base_addr 00000000f4a8c90e
> [ 18.855002] ath10k_snoc 18800000.wifi: Hardware name wcn3990 hw1.0 version 0x8
> [ 18.865605] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/pre-cal-snoc-18800000.wifi.bin': -2
> [ 18.871747] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/cal-snoc-18800000.wifi.bin': -2
> [ 18.880307] ath10k_snoc 18800000.wifi: trying fw api 6
> [ 18.889520] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-6.bin': -2
> [ 18.894020] ath10k_snoc 18800000.wifi: trying fw api 5
> *** firmware-5.bin is handled at this point
> [ 18.904176] ath10k_snoc 18800000.wifi: boot fw request 'ath10k/WCN3990/hw1.0/firmware-5.bin': 0
> [ 18.907802] ath10k_snoc 18800000.wifi: found fw timestamp 1539237028
> [ 18.916460] ath10k_snoc 18800000.wifi: found firmware features ie (3 B)
> [ 18.923027] ath10k_snoc 18800000.wifi: Enabling feature bit: 6
> [ 18.929373] ath10k_snoc 18800000.wifi: Enabling feature bit: 18
> [ 18.935279] ath10k_snoc 18800000.wifi: Enabling feature bit: 19
> [ 18.941085] ath10k_snoc 18800000.wifi: features
> [ 18.946975] ath10k_snoc 18800000.wifi: 00000000: 40 00 0c 00 00 00 00 00 @.......
> [ 18.951534] ath10k_snoc 18800000.wifi: found fw ie wmi op version 4
> [ 18.961235] ath10k_snoc 18800000.wifi: found fw ie htt op version 3
> [ 18.967390] ath10k_snoc 18800000.wifi: using fw api 5
>
>
>
> I don't know how to solve this problem.
> (If we just skip waiting for MSA_READY, there is no problem)
>
> Kalle, Jeff, do you see a way out of this conundrum?
Regards.
^ permalink raw reply
* [PATCH 1/3] dt-bindings: ufs: qcom: document SC8180X UFS
From: Krzysztof Kozlowski @ 2024-03-26 17:46 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam,
Alim Akhtar, Avri Altman, Bart Van Assche, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andy Gross, linux-arm-msm,
linux-scsi, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Document already upstreamed and used Qualcomm SC8180x UFS host
controller to fix dtbs_check warnings like:
sc8180x-primus.dtb: ufshc@1d84000: compatible:0: 'qcom,sc8180x-ufshc' is not one of ['qcom,msm8994-ufshc', ... ]
sc8180x-primus.dtb: ufshc@1d84000: Unevaluated properties are not allowed ('compatible' was unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Rob, considering limbo status of this binding, maybe you can take it
directly? Would be the fastest.
---
Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
index 10c146424baa..1ab3d16917ac 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
@@ -28,6 +28,7 @@ properties:
- qcom,msm8998-ufshc
- qcom,sa8775p-ufshc
- qcom,sc7280-ufshc
+ - qcom,sc8180x-ufshc
- qcom,sc8280xp-ufshc
- qcom,sdm845-ufshc
- qcom,sm6115-ufshc
@@ -120,6 +121,7 @@ allOf:
- qcom,msm8998-ufshc
- qcom,sa8775p-ufshc
- qcom,sc7280-ufshc
+ - qcom,sc8180x-ufshc
- qcom,sc8280xp-ufshc
- qcom,sm8250-ufshc
- qcom,sm8350-ufshc
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: ufs: qcom: document SC7180 UFS
From: Krzysztof Kozlowski @ 2024-03-26 17:46 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam,
Alim Akhtar, Avri Altman, Bart Van Assche, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andy Gross, linux-arm-msm,
linux-scsi, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240326174632.209745-1-krzysztof.kozlowski@linaro.org>
Document already upstreamed and used Qualcomm SC7180 UFS host controller
to fix dtbs_check warnings like:
sc7180-idp.dtb: ufshc@1d84000: compatible:0: 'qcom,sc7180-ufshc' is not one of ...
sc7180-idp.dtb: ufshc@1d84000: clocks: [[39, 99], [39, 7], [39, 98], [39, 107], [36, 0], [39, 106], [39, 105]] is too short
sc7180-idp.dtb: ufshc@1d84000: clock-names: ['core_clk', 'bus_aggr_clk', 'iface_clk', 'core_clk_unipro', ...] is too short
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
.../devicetree/bindings/ufs/qcom,ufs.yaml | 34 ++++++++++++++++---
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
index 1ab3d16917ac..7e6d442545ad 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
@@ -27,6 +27,7 @@ properties:
- qcom,msm8996-ufshc
- qcom,msm8998-ufshc
- qcom,sa8775p-ufshc
+ - qcom,sc7180-ufshc
- qcom,sc7280-ufshc
- qcom,sc8180x-ufshc
- qcom,sc8280xp-ufshc
@@ -43,11 +44,11 @@ properties:
- const: jedec,ufs-2.0
clocks:
- minItems: 8
+ minItems: 7
maxItems: 11
clock-names:
- minItems: 8
+ minItems: 7
maxItems: 11
dma-coherent: true
@@ -113,6 +114,31 @@ required:
allOf:
- $ref: ufs-common.yaml
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,sc7180-ufshc
+ then:
+ properties:
+ clocks:
+ minItems: 7
+ maxItems: 7
+ clock-names:
+ items:
+ - const: core_clk
+ - const: bus_aggr_clk
+ - const: iface_clk
+ - const: core_clk_unipro
+ - const: ref_clk
+ - const: tx_lane0_sync_clk
+ - const: rx_lane0_sync_clk
+ reg:
+ maxItems: 1
+ reg-names:
+ maxItems: 1
+
- if:
properties:
compatible:
@@ -250,7 +276,7 @@ allOf:
reg:
maxItems: 1
clocks:
- minItems: 8
+ minItems: 7
maxItems: 8
else:
properties:
@@ -258,7 +284,7 @@ allOf:
minItems: 1
maxItems: 2
clocks:
- minItems: 8
+ minItems: 7
maxItems: 11
unevaluatedProperties: false
--
2.34.1
^ permalink raw reply related
* [PATCH 3/3] dt-bindings: ufs: qcom: document SM6125 UFS
From: Krzysztof Kozlowski @ 2024-03-26 17:46 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Manivannan Sadhasivam,
Alim Akhtar, Avri Altman, Bart Van Assche, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andy Gross, linux-arm-msm,
linux-scsi, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20240326174632.209745-1-krzysztof.kozlowski@linaro.org>
Document already upstreamed and used Qualcomm SM6125 UFS host controller to fix
dtbs_check warnings like:
sm6125-xiaomi-laurel-sprout.dtb: ufs@4804000: compatible:0: 'qcom,sm6125-ufshc' is not one of ['qcom,msm8994-ufshc', ...
sm6125-xiaomi-laurel-sprout.dtb: ufs@4804000: Unevaluated properties are not allowed ('compatible' was unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
index 7e6d442545ad..cd3680dc002f 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml
@@ -33,6 +33,7 @@ properties:
- qcom,sc8280xp-ufshc
- qcom,sdm845-ufshc
- qcom,sm6115-ufshc
+ - qcom,sm6125-ufshc
- qcom,sm6350-ufshc
- qcom,sm8150-ufshc
- qcom,sm8250-ufshc
@@ -243,6 +244,7 @@ allOf:
contains:
enum:
- qcom,sm6115-ufshc
+ - qcom,sm6125-ufshc
then:
properties:
clocks:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: display: rockchip: add missing #sound-dai-cells to dw-hdmi
From: Krzysztof Kozlowski @ 2024-03-26 17:50 UTC (permalink / raw)
To: Heiko Stuebner, hjc, andy.yan, robh, krzysztof.kozlowski+dt,
conor+dt
Cc: dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20240326172801.1163200-1-heiko@sntech.de>
On 26/03/2024 18:28, Heiko Stuebner wrote:
> The #sound-dai-cells DT property is required to describe link between
> the HDMI IP block and the SoC's audio subsystem.
>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> index af638b6c0d21..3768df80ca7a 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
> @@ -124,6 +124,9 @@ properties:
> description:
> phandle to the GRF to mux vopl/vopb.
>
> + "#sound-dai-cells":
> + const: 0
> +
Then you miss $ref in allOf to /schemas/sound/dai-common.yaml
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: rockchip: add missing #sound-dai-cells to dw-hdmi
From: Krzysztof Kozlowski @ 2024-03-26 17:50 UTC (permalink / raw)
To: Heiko Stuebner, hjc, andy.yan, robh, krzysztof.kozlowski+dt,
conor+dt
Cc: dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <edc0bfa2-7984-4d9d-ba25-4805ee0be679@linaro.org>
On 26/03/2024 18:50, Krzysztof Kozlowski wrote:
> On 26/03/2024 18:28, Heiko Stuebner wrote:
>> The #sound-dai-cells DT property is required to describe link between
>> the HDMI IP block and the SoC's audio subsystem.
>>
>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>> ---
>> .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> index af638b6c0d21..3768df80ca7a 100644
>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> @@ -124,6 +124,9 @@ properties:
>> description:
>> phandle to the GRF to mux vopl/vopb.
>>
>> + "#sound-dai-cells":
>> + const: 0
>> +
>
> Then you miss $ref in allOf to /schemas/sound/dai-common.yaml
I meant, except your change you should add also above $ref.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: renesas: white-hawk: ethernet: Describe avb1 and avb2
From: Niklas Söderlund @ 2024-03-26 17:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-renesas-soc,
devicetree
In-Reply-To: <CAMuHMdXBhpbH2=21e26BeuknpW08eoX_yG4UQg-Ep5TijY3Vfw@mail.gmail.com>
Hi Geert,
Thanks for your report.
On 2024-03-26 16:54:49 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Sat, Mar 9, 2024 at 4:56 PM Niklas Söderlund
> <niklas.soderlund+renesas@ragnatech.se> wrote:
> > Describe the two Marvel 88Q2110/QFN40 PHYs available on the R-Car V4H
> > White Hawk RAVB/Ethernet(1000Base-T1) sub-board. The two PHYs are wired
> > up on the board by default, there is no need to move any resistors which
> > are needed to access other PHYs available on this sub-board.
> >
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>
> When accidentally booting a kernel without CONFIG_MARVELL_88Q2XXX_PHY=y,
> I am greeted with the following warning splat (same for the second PHY):
I can reproduce this, but I'm not really sure how to deal with it and
it's unrelated to Renesas AVB Ethernet driver.
What happens when when running without CONFIG_MARVELL_88Q2XXX_PHY=y is
that the core fallback to use the generic Generic Clause 45 PHY driver.
And the generic driver don't work correctly for the PHY on V4H (88Q2110).
The splat happens when the generic driver tries to enable auto
negotiation. This is known to be broken for 88Q2110 and the
CONFIG_MARVELL_88Q2XXX_PHY=y driver disables this. From
marvell-88q2xxx.c
/* The PHY signalizes it supports autonegotiation. Unfortunately, so
* far it was not possible to get a link even when following the init
* sequence provided by Marvell. Disable it for now until a proper
* workaround is found or a new PHY revision is released.
*/
if (phydev->drv->phy_id == MARVELL_PHY_ID_88Q2110)
linkmode_clear_bit(ETHTOOL_LINK_MODE_Autoneg_BIT,
phydev->supported);
If I hack the generic PHY to also not try auto negotiation the splat go
away and the PHY binds using the generic driver. I did not test using it
further.
I can't try to submit such a hack as that would break all other PHY
where auto negotiation works. So I'm not sure we can do anything about
this other than make sure we have the correct PHY drivers around, or use
PHYs that works with the Clause 45 specification.
>
> -mv88q2110 e6810000.ethernet-ffffffff:00: attached PHY driver
> (mii_bus:phy_addr=e6810000.ethernet-ffffffff:00, irq=POLL)
> +Generic Clause 45 PHY e6810000.ethernet-ffffffff:00: attached PHY
> driver (mii_bus:phy_addr=e6810000.ethernet-ffffffff:00, irq=POLL)
> +rcar-du feb00000.display: adding to PM domain always-on
> -mv88q2110 e6820000.ethernet-ffffffff:00: attached PHY driver
> (mii_bus:phy_addr=e6820000.ethernet-ffffffff:00, irq=POLL)
> +rcar-du feb00000.display: removing from PM domain always-on
> +------------[ cut here ]------------
> +_phy_start_aneg+0x0/0xa8: returned: -22
> +WARNING: CPU: 2 PID: 55 at drivers/net/phy/phy.c:1262
> _phy_state_machine+0x120/0x198
> +Modules linked in:
> +CPU: 2 PID: 55 Comm: kworker/2:1 Not tainted
> 6.9.0-rc1-white-hawk-02587-g577b6a49a6d4 #235
> +Hardware name: Renesas White Hawk CPU and Breakout boards based on
> r8a779g0 (DT)
> +Workqueue: events_power_efficient phy_state_machine
> +pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> +pc : _phy_state_machine+0x120/0x198
> +lr : _phy_state_machine+0x120/0x198
> +sp : ffffffc082dd3d10
> +x29: ffffffc082dd3d10 x28: ffffff8440089c05 x27: ffffffc081090000
> +x26: ffffffc080e03008 x25: 0000000000000000 x24: ffffffc0815603d0
> +x23: ffffffc080e03008 x22: ffffff86bef98100 x21: 0000000000000004
> +x20: 0000000000000001 x19: ffffff84435b3000 x18: 0000000000000000
> +x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007320732
> +x14: 072d0720073a0764 x13: 0720072007320732 x12: 072d0720073a0764
> +x11: 000000000000033a x10: ffffffc0810b9ac8 x9 : ffffffc081379ca8
> +x8 : ffffffc082dd3a18 x7 : ffffffc082dd3a20 x6 : 00000000ffff7fff
> +x5 : c0000000ffff7fff x4 : 0000000000000000 x3 : 0000000000000001
> +x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8440a98000
> +Call trace:
> + _phy_state_machine+0x120/0x198
> + phy_state_machine+0x2c/0x5c
> + process_scheduled_works+0x314/0x4d4
> + worker_thread+0x1b8/0x20c
> + kthread+0xd8/0xe8
> + ret_from_fork+0x10/0x20
> +irq event stamp: 16
> +hardirqs last enabled at (15): [<ffffffc080913144>]
> _raw_spin_unlock_irq+0x2c/0x40
> +hardirqs last disabled at (16): [<ffffffc08090d434>] __schedule+0x1cc/0x870
> +softirqs last enabled at (0): [<ffffffc0800800f8>] copy_process+0x698/0x1924
> +softirqs last disabled at (0): [<0000000000000000>] 0x0
> +---[ end trace 0000000000000000 ]---
>
> Is that expected behavior?
> Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox