* Re: [PATCH 5/5] arm64: dts: Add device tree source for the Au-Zone Maivin Starter Kit
From: Krzysztof Kozlowski @ 2024-03-26 7:12 UTC (permalink / raw)
To: Laurent Pinchart, devicetree, imx, linux-arm-kernel
Cc: Trevor Zaharichuk, Greg Lytle, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20240325203245.31660-6-laurent.pinchart@ideasonboard.com>
On 25/03/2024 21:32, Laurent Pinchart wrote:
> The Maivin board is an AI vision starter kit sold by Au-Zone
> Technologies, developed in collaboration with Toradex and Vision
> Components. It is based on a Toradex Verdin i.MX8MP SoM.
>
> Add a device tree that covers the base set the peripherals found on the
> board:
Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.
And drop redundant parts.
arm64: dts: imx8mp-maivin: Add Au-Zone Maivin Starter Kit board
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: imx8mp: Add DT nodes for the two ISPs
From: Alexander Stein @ 2024-03-26 7:14 UTC (permalink / raw)
To: Laurent Pinchart
Cc: imx, linux-arm-kernel, Paul Elder, Adam Ford, Conor Dooley,
Fabio Estevam, Krzysztof Kozlowski, Marek Vasut,
Pengutronix Kernel Team, Rob Herring, Sascha Hauer, Shawn Guo,
devicetree, linux-media
In-Reply-To: <20240325204924.GY18799@pendragon.ideasonboard.com>
Hi Laurent,
Am Montag, 25. März 2024, 21:49:24 CET schrieb Laurent Pinchart:
> Hi Alexander,
>
> On Mon, Mar 25, 2024 at 04:52:21PM +0100, Alexander Stein wrote:
> > Am Montag, 25. März 2024, 16:13:39 CET schrieb Laurent Pinchart:
> > > From: Paul Elder <paul.elder@ideasonboard.com>
> > >
> > > The ISP supports both CSI and parallel interfaces, where port 0
> > > corresponds to the former and port 1 corresponds to the latter. Since
> > > the i.MX8MP's ISPs are connected by the parallel interface to the CSI
> > > receiver, set them both to port 1.
> > >
> > > Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > ---
> > > Changes since v1:
> > >
> > > - Fix clock ordering
> > > - Add #address-cells and #size-cells to ports nodes
> > > ---
> > > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 50 +++++++++++++++++++++++
> > > 1 file changed, 50 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > > index bfc5c81a5bd4..1d2670b91b53 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > > @@ -1616,6 +1616,56 @@ isi_in_1: endpoint {
> > > };
> > > };
> > >
> > > + isp_0: isp@32e10000 {
> > > + compatible = "fsl,imx8mp-isp";
> > > + reg = <0x32e10000 0x10000>;
> > > + interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clk IMX8MP_CLK_MEDIA_ISP_ROOT>,
> > > + <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>,
> > > + <&clk IMX8MP_CLK_MEDIA_APB_ROOT>;
> > > + clock-names = "isp", "aclk", "hclk";
> > > + assigned-clocks = <&clk IMX8MP_CLK_MEDIA_ISP>;
> > > + assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_500M>;
> > > + assigned-clock-rates = <500000000>;
> > > + power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_ISP>;
> > > + fsl,blk-ctrl = <&media_blk_ctrl 0>;
> > > + status = "disabled";
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@1 {
> > > + reg = <1>;
> > > + };
> > > + };
> > > + };
> > > +
> > > + isp_1: isp@32e20000 {
> > > + compatible = "fsl,imx8mp-isp";
> > > + reg = <0x32e20000 0x10000>;
> > > + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clk IMX8MP_CLK_MEDIA_ISP_ROOT>,
> > > + <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>,
> > > + <&clk IMX8MP_CLK_MEDIA_APB_ROOT>;
> > > + clock-names = "isp", "aclk", "hclk";
> > > + assigned-clocks = <&clk IMX8MP_CLK_MEDIA_ISP>;
> > > + assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_500M>;
> > > + assigned-clock-rates = <500000000>;
> > > + power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_ISP>;
> > > + fsl,blk-ctrl = <&media_blk_ctrl 1>;
> > > + status = "disabled";
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + port@1 {
> > > + reg = <1>;
> > > + };
> > > + };
> > > + };
> > > +
> >
> > The patch itself is okay. But you might not be able to
> > configure the parent of IMX8MP_CLK_MEDIA_ISP if dewarp is enabled before.
> > This is due to IMX8MP_CLK_MEDIA_ISP_ROOT being enabled in 'pgc_ispdwp'
> > power domain. Reparenting is not possible anymore in this case.
>
> Good point.
>
> > Something like
> > ---8<---
> > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > @@ -1837,11 +1837,13 @@ media_blk_ctrl: blk-ctrl@32ec0000 {
> > <&clk IMX8MP_CLK_MEDIA_APB>,
> > <&clk IMX8MP_CLK_MEDIA_DISP1_PIX>,
> > <&clk IMX8MP_CLK_MEDIA_DISP2_PIX>,
> > + <&clk IMX8MP_CLK_MEDIA_ISP>,
> > <&clk IMX8MP_VIDEO_PLL1>;
> > assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
> > <&clk IMX8MP_SYS_PLL1_800M>,
> > <&clk IMX8MP_VIDEO_PLL1_OUT>,
> > - <&clk IMX8MP_VIDEO_PLL1_OUT>;
> > + <&clk IMX8MP_VIDEO_PLL1_OUT>,
> > + <&clk IMX8MP_SYS_PLL2_500M>;
> > assigned-clock-rates = <500000000>, <200000000>,
> > <0>, <0>, <1039500000>;
>
> With an assigned clock rate here too then ?
You are right. This posted diff is what I was using for a while now though.
Apparently the clock frequency was still correct.
Best regards,
Alexander
> > #power-domain-cells = <1>;
> > ---8<---
> > is needed.
>
> Sascha, are you OK with this approach ?
>
> > > dewarp: dwe@32e30000 {
> > > compatible = "nxp,imx8mp-dw100";
> > > reg = <0x32e30000 0x10000>;
> > >
> > > base-commit: 4cece764965020c22cff7665b18a012006359095
>
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1] ARM: dts: aspeed: yosemite4: set bus13 frequency to 100k
From: Delphine CC Chiu @ 2024-03-26 7:17 UTC (permalink / raw)
To: patrick
Cc: Delphine CC Chiu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, devicetree, linux-arm-kernel,
linux-aspeed, linux-kernel
Since the ocp debug card only supports 100k, the bus is also set to 100k.
Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
index 64075cc41d92..98e58e3fea77 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
@@ -369,7 +369,7 @@ rtc@6f {
&i2c13 {
status = "okay";
- bus-frequency = <400000>;
+ bus-frequency = <100000>;
};
&i2c14 {
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/5] dt-bindings: iio: dac: ti,dac5571: Add DAC081C081 support
From: Jonathan Cameron @ 2024-03-25 22:32 UTC (permalink / raw)
To: Laurent Pinchart, Jonathan Cameron
Cc: 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: <20240325222308.GA31216@pendragon.ideasonboard.com>
On 25 March 2024 22:23:08 GMT, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>On Mon, Mar 25, 2024 at 10:56:44PM +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.
>
>And in that case, should I first introduce support in the bindings for
>"ti,dac121c081", "ti,dac7571" and deprecate usage of "ti,dac121c081"
>alone ?
Yes. Not sure if we need an explicit binding entry for deprecated version...
>
>> * 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.
>>
>> > > ---
>> > > 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:
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 07/64] i2c: bcm-iproc: reword according to newest specification
From: Andi Shyti @ 2024-03-26 7:29 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Ray Jui, Scott Branden,
Broadcom internal kernel review list, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240322132619.6389-8-wsa+renesas@sang-engineering.com>
Hi Wolfram,
On Fri, Mar 22, 2024 at 02:25:00PM +0100, Wolfram Sang wrote:
> Match the wording of this driver wrt. the newest I2C v7, SMBus 3.2, I3C
> specifications and replace "master/slave" with more appropriate terms.
> They are also more specific because we distinguish now between a remote
> entity ("client") and a local one ("target").
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: stm32: add heartbeat led for stm32mp157c-ed1
From: Patrice CHOTARD @ 2024-03-26 7:29 UTC (permalink / raw)
To: Krzysztof Kozlowski, robh+dt, Krzysztof Kozlowski,
alexandre.torgue
Cc: linux-stm32, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <dc4251d1-8cbb-4a0c-834c-26f16f3f9484@linaro.org>
On 3/25/24 19:29, Krzysztof Kozlowski wrote:
> On 25/03/2024 18:06, patrice.chotard@foss.st.com wrote:
>> From: Patrice Chotard <patrice.chotard@foss.st.com>
>>
>> Add heartbeat led for stm32mp157c-ed1.
>>
>> Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
>> ---
>> arch/arm/boot/dts/st/stm32mp157c-ed1.dts | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
>> index 66ed5f9921ba..bd727455a7e4 100644
>> --- a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
>> +++ b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
>> @@ -24,6 +24,15 @@ chosen {
>> stdout-path = "serial0:115200n8";
>> };
>>
>> + led {
>> + compatible = "gpio-leds";
>> + led-blue {
>> + gpios = <&gpiod 9 GPIO_ACTIVE_HIGH>;
>> + linux,default-trigger = "heartbeat";
>> + default-state = "off";
>
> Please add function and color properties.
Hi Krzysztof
OK i will send a v2
Thanks
Patrice
>
> Best regards,
> Krzysztof
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/4] dt-bindings: rtc: digicolor-rtc: move to trivial-rtc
From: Krzysztof Kozlowski @ 2024-03-26 7:31 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240325-rtc-yaml-v2-3-ff9f68f43dbc@gmail.com>
On 25/03/2024 22:10, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> This device meets the requirements to be moved to trivial-rtc
> (compatible, reg and a single interrupt).
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
> Documentation/devicetree/bindings/rtc/digicolor-rtc.txt | 17 -----------------
> Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
> 2 files changed, 2 insertions(+), 17 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: rtc: armada-380-rtc: convert to dtschema
From: Krzysztof Kozlowski @ 2024-03-26 7:32 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240325-rtc-yaml-v2-1-ff9f68f43dbc@gmail.com>
On 25/03/2024 22:10, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> This is a direct conversion with no additions.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: rtc: alphascale,asm9260-rtc: convert to dtschema
From: Krzysztof Kozlowski @ 2024-03-26 7:34 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240325-rtc-yaml-v2-2-ff9f68f43dbc@gmail.com>
On 25/03/2024 22:10, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> This is a direct conversion with no additions.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> +allOf:
> + - $ref: rtc.yaml#
> +
> +properties:
> + compatible:
> + const: alphascale,asm9260-rtc
> +
> + reg:
> + description:
> + Base address and length of the register region.
If there is going to be any resend, drop description. It is redundant
and obvious. reg cannot be anything else.
> + maxItems: 1
> +
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 4/4] dt-bindings: rtc: nxp,lpc1788-rtc: convert to dtschema
From: Krzysztof Kozlowski @ 2024-03-26 7:35 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Baruch Siach
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240325-rtc-yaml-v2-4-ff9f68f43dbc@gmail.com>
On 25/03/2024 22:10, Javier Carrasco wrote:
> Convert existing binding to dtschema to support validation.
>
> This is a direct conversion with no additions.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V8 00/12] soc: imx8mp: Add support for HDMI
From: Tommaso Merciai @ 2024-03-26 7:46 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Adam Ford, linux-arm-kernel, marex, alexander.stein,
frieder.schrempf, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Philipp Zabel, Vinod Koul, Kishon Vijay Abraham I,
Catalin Marinas, Will Deacon, Liu Ying, Ulf Hansson, Lucas Stach,
dri-devel, devicetree, linux-kernel, linux-phy, linux-pm
In-Reply-To: <20240325220338.GE23988@pendragon.ideasonboard.com>
Hi Laurent,
On Tue, Mar 26, 2024 at 12:03:38AM +0200, Laurent Pinchart wrote:
> Hi Tommaso,
>
> On Mon, Mar 25, 2024 at 10:48:56PM +0100, Tommaso Merciai wrote:
> > Hi Adam, Lucas,
> > Thanks for this series.
> >
> > This series make HDMI work on evk.
> > All is working properly on my side.
> >
> > Tested on: Linux imx8mp-lpddr4-evk 6.9.0-rc1.
> > Hope this help.
> >
> > Tested-by: Tommaso Merciai <tomm.merciai@gmail.com>
>
> The DRM side has been merged already. The only missing patches are for
> the PHY, and the latest version can be found in
> https://lore.kernel.org/linux-phy/20240227220444.77566-1-aford173@gmail.com/.
> You can test that series and send a Tested-by tag. I'm crossing my
> fingers and hoping it will be merged in v6.10.
(same here :) )
Thanks for sharing! :)
To be honest I test all this series rebasing my alvium next branch on top of media_stage/master (6.9.0-rc1)
All is working properly on my side.
I found v8 into the commit msg here: https://patches.linaro.org/project/linux-pm/patch/20240203165307.7806-9-aford173@gmail.com/
then I'm thinking this is the latest.
I'm going to switch to your suggestion that looks more recent :)
Thanks again,
Tommaso
>
> > On Sat, Feb 03, 2024 at 10:52:40AM -0600, Adam Ford wrote:
> > > The i.MX8M Plus has an HDMI controller, but it depends on two
> > > other systems, the Parallel Video Interface (PVI) and the
> > > HDMI PHY from Samsung. The LCDIF controller generates the display
> > > and routes it to the PVI which converts passes the parallel video
> > > to the HDMI bridge. The HDMI system has a corresponding power
> > > domain controller whose driver was partially written, but the
> > > device tree for it was never applied, so some changes to the
> > > power domain should be harmless because they've not really been
> > > used yet.
> > >
> > > This series is adapted from multiple series from Lucas Stach with
> > > edits and suggestions from feedback from various series, but it
> > > since it's difficult to use and test them independently,
> > > I merged them into on unified series. The version history is a
> > > bit ambiguous since different components were submitted at different
> > > times and had different amount of retries. In an effort to merge them
> > > I used the highest version attempt.
> > >
> > > Adam Ford (3):
> > > dt-bindings: soc: imx: add missing clock and power-domains to
> > > imx8mp-hdmi-blk-ctrl
> > > pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix
> > > domain
> > > arm64: defconfig: Enable DRM_IMX8MP_DW_HDMI_BRIDGE as module
> > >
> > > Lucas Stach (9):
> > > dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
> > > phy: freescale: add Samsung HDMI PHY
> > > arm64: dts: imx8mp: add HDMI power-domains
> > > arm64: dts: imx8mp: add HDMI irqsteer
> > > dt-bindings: display: imx: add binding for i.MX8MP HDMI PVI
> > > drm/bridge: imx: add driver for HDMI TX Parallel Video Interface
> > > dt-bindings: display: imx: add binding for i.MX8MP HDMI TX
> > > drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI
> > > arm64: dts: imx8mp: add HDMI display pipeline
> > >
> > > .../display/bridge/fsl,imx8mp-hdmi-tx.yaml | 102 ++
> > > .../display/imx/fsl,imx8mp-hdmi-pvi.yaml | 84 ++
> > > .../bindings/phy/fsl,imx8mp-hdmi-phy.yaml | 62 +
> > > .../soc/imx/fsl,imx8mp-hdmi-blk-ctrl.yaml | 22 +-
> > > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 145 +++
> > > arch/arm64/configs/defconfig | 1 +
> > > drivers/gpu/drm/bridge/imx/Kconfig | 18 +
> > > drivers/gpu/drm/bridge/imx/Makefile | 2 +
> > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c | 207 ++++
> > > drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 154 +++
> > > drivers/phy/freescale/Kconfig | 6 +
> > > drivers/phy/freescale/Makefile | 1 +
> > > drivers/phy/freescale/phy-fsl-samsung-hdmi.c | 1075 +++++++++++++++++
> > > drivers/pmdomain/imx/imx8mp-blk-ctrl.c | 10 +-
> > > 14 files changed, 1876 insertions(+), 13 deletions(-)
> > > create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml
> > > create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pvi.yaml
> > > create mode 100644 Documentation/devicetree/bindings/phy/fsl,imx8mp-hdmi-phy.yaml
> > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> > > create mode 100644 drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c
> > > create mode 100644 drivers/phy/freescale/phy-fsl-samsung-hdmi.c
>
> --
> Regards,
>
> Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] virtio_ring: Fix the stale index in available ring
From: Michael S. Tsirkin @ 2024-03-26 7:49 UTC (permalink / raw)
To: Gavin Shan
Cc: Will Deacon, virtualization, linux-kernel, jasowang, xuanzhuo,
yihyu, shan.gavin, linux-arm-kernel, Catalin Marinas, mochs
In-Reply-To: <1dcec730-ec26-46f4-ba4c-06101fcc599e@redhat.com>
On Mon, Mar 25, 2024 at 05:34:29PM +1000, Gavin Shan wrote:
>
> On 3/20/24 17:14, Michael S. Tsirkin wrote:
> > On Wed, Mar 20, 2024 at 03:24:16PM +1000, Gavin Shan wrote:
> > > On 3/20/24 10:49, Michael S. Tsirkin wrote:>
> > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > > > index 6f7e5010a673..79456706d0bd 100644
> > > > --- a/drivers/virtio/virtio_ring.c
> > > > +++ b/drivers/virtio/virtio_ring.c
> > > > @@ -685,7 +685,8 @@ static inline int virtqueue_add_split(struct virtqueue *_vq,
> > > > /* Put entry in available array (but don't update avail->idx until they
> > > > * do sync). */
> > > > avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1);
> > > > - vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, head);
> > > > + u16 headwithflag = head | (q->split.avail_idx_shadow & ~(vq->split.vring.num - 1));
> > > > + vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, headwithflag);
> > > > /* Descriptors and available array need to be set before we expose the
> > > > * new available array entries. */
> > > >
>
> Ok, Michael. I continued with my debugging code. It still looks like a
> hardware bug on NVidia's grace-hopper. I really think NVidia needs to be
> involved for the discussion, as suggested by you.
Do you have a support contact at Nvidia to report this?
> Firstly, I bind the vhost process and vCPU thread to CPU#71 and CPU#70.
> Note that I have only one vCPU in my configuration.
Interesting but is guest built with CONFIG_SMP set?
> Secondly, the debugging code is enhanced so that the available head for
> (last_avail_idx - 1) is read for twice and recorded. It means the available
> head for one specific available index is read for twice. I do see the
> available heads are different from the consecutive reads. More details
> are shared as below.
>
> From the guest side
> ===================
>
> virtio_net virtio0: output.0:id 86 is not a head!
> head to be released: 047 062 112
>
> avail_idx:
> 000 49665
> 001 49666 <--
> :
> 015 49664
what are these #s 49665 and so on?
and how large is the ring?
I am guessing 49664 is the index ring size is 16 and
49664 % 16 == 0
> avail_head:
is this the avail ring contents?
> 000 062
> 001 047 <--
> :
> 015 112
What are these arrows pointing at, btw?
> From the host side
> ==================
>
> avail_idx
> 000 49663
> 001 49666 <---
> :
>
> avail_head
> 000 062 (062)
> 001 047 (047) <---
> :
> 015 086 (112) // head 086 is returned from the first read,
> // but head 112 is returned from the second read
>
> vhost_get_vq_desc: Inconsistent head in two read (86 -> 112) for avail_idx 49664
>
> Thanks,
> Gavin
OK thanks so this proves it is actually the avail ring value.
--
MST
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] ARM: dts: stm32: add heartbeat led for stm32mp157c-ed1
From: patrice.chotard @ 2024-03-26 7:54 UTC (permalink / raw)
To: robh+dt, Krzysztof Kozlowski, alexandre.torgue
Cc: linux-stm32, linux-arm-kernel, linux-kernel, devicetree,
Patrice Chotard
From: Patrice Chotard <patrice.chotard@foss.st.com>
Add heartbeat led for stm32mp157c-ed1.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
---
V2 changes :
_ add color and function properties.
arch/arm/boot/dts/st/stm32mp157c-ed1.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
index 66ed5f9921ba..525d9ca7d576 100644
--- a/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
+++ b/arch/arm/boot/dts/st/stm32mp157c-ed1.dts
@@ -10,6 +10,7 @@
#include "stm32mp15-pinctrl.dtsi"
#include "stm32mp15xxaa-pinctrl.dtsi"
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/mfd/st,stpmic1.h>
/ {
@@ -24,6 +25,17 @@ chosen {
stdout-path = "serial0:115200n8";
};
+ led {
+ compatible = "gpio-leds";
+ led-blue {
+ gpios = <&gpiod 9 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ function = LED_FUNCTION_HEARTBEAT;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+
memory@c0000000 {
device_type = "memory";
reg = <0xC0000000 0x40000000>;
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 04/16] dt-bindings: net: wireless: qcom,ath11k: describe the ath11k on QCA6390
From: Johan Hovold @ 2024-03-26 8:11 UTC (permalink / raw)
To: Kalle Valo
Cc: Bartosz Golaszewski, 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: <87frwe8jiu.fsf@kernel.org>
On Mon, Mar 25, 2024 at 04:37:29PM +0200, Kalle Valo wrote:
> Bartosz Golaszewski <brgl@bgdev.pl> writes:
> > On Mon, Mar 25, 2024 at 2:57 PM Kalle Valo <kvalo@kernel.org> wrote:
> >> Bartosz Golaszewski <brgl@bgdev.pl> writes:
> >> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >> >
> >> > Add a PCI compatible for the ATH11K module on QCA6390 and describe the
> >> > power inputs from the PMU that it consumes.
> >> >
> >> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >>
> >> [...]
> >>
> >> > +allOf:
> >> > + - if:
> >> > + properties:
> >> > + compatible:
> >> > + contains:
> >> > + const: pci17cb,1101
> >> > + then:
> >> > + required:
> >> > + - vddrfacmn-supply
> >> > + - vddaon-supply
> >> > + - vddwlcx-supply
> >> > + - vddwlmx-supply
> >> > + - vddrfa0p8-supply
> >> > + - vddrfa1p2-supply
> >> > + - vddrfa1p7-supply
> >> > + - vddpcie0p9-supply
> >> > + - vddpcie1p8-supply
> >>
> >> I don't know DT well enough to know what the "required:" above means,
> >> but does this take into account that there are normal "plug&play" type
> >> of QCA6390 boards as well which don't need any DT settings?
> >
> > Do they require a DT node though for some reason?
>
> You can attach the device to any PCI slot, connect the WLAN antenna and
> it just works without DT nodes. I'm trying to make sure here that basic
> setup still works.
>
> 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?
In theory we could, but at least the WCN6855 in the X13s has a similar
set of supplies and enable gpios which are currently not fully described
in the devicetree as there has been no support for doing so thus far.
Instead we rely on the bootloader to enable the module.
I haven't had time to look at the latest attempt on adding support for
handling such resources, but eventually we'll need to address this in
some way.
Johan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND][PATCH v2 4/4] soc: samsung: exynos-asv: Update Energy Model after adjusting voltage
From: Lukasz Luba @ 2024-03-26 8:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: dietmar.eggemann, linux-arm-kernel, sboyd, nm, linux-samsung-soc,
daniel.lezcano, rafael, viresh.kumar, alim.akhtar, m.szyprowski,
mhiramat, linux-kernel, linux-pm
In-Reply-To: <637a6390-6e38-49a4-abf5-b0d2b2a31093@linaro.org>
On 3/25/24 19:17, Krzysztof Kozlowski wrote:
> On 22/03/2024 12:08, Lukasz Luba wrote:
>> When the voltage for OPPs is adjusted there is a need to also update
>> Energy Model framework. The EM data contains power values which depend
>> on voltage values. The EM structure is used for thermal (IPA governor)
>> and in scheduler task placement (EAS) so it should reflect the real HW
>> model as best as possible to operate properly.
>>
>> Based on data on Exynos5422 ASV tables the maximum power difference might
>> be ~29%. An Odroid-XU4 (with a random sample SoC in this chip lottery)
>> showed power difference for some OPPs ~20%. Therefore, it's worth to
>> update the EM.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>> ---
>> drivers/soc/samsung/exynos-asv.c | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> I assume there is dependency, even though cover letter did not mention
> it, so:
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Thanks Krzysztof for the review. Yes, it touches driver in your tree
indeed. Hopefully it can goes smoothly via Rafael's tree with your
tag.
Regards,
Lukasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND][PATCH v2 1/4] OPP: OF: Export dev_opp_pm_calc_power() for usage from EM
From: Lukasz Luba @ 2024-03-26 8:29 UTC (permalink / raw)
To: Viresh Kumar
Cc: linux-kernel, linux-pm, dietmar.eggemann, linux-arm-kernel, sboyd,
nm, linux-samsung-soc, daniel.lezcano, rafael,
krzysztof.kozlowski, alim.akhtar, m.szyprowski, mhiramat
In-Reply-To: <20240326025147.qgfl5buiobfqfghj@vireshk-i7>
On 3/26/24 02:51, Viresh Kumar wrote:
> On 22-03-24, 11:08, Lukasz Luba wrote:
>> There are device drivers which can modify voltage values for OPPs. It
>> could be due to the chip binning and those drivers have specific chip
>> knowledge about it. This adjustment can happen after Energy Model is
>> registered, thus EM can have stale data about power.
>>
>> Export dev_opp_pm_calc_power() which can be used by Energy Model to
>> calculate new power with the new voltage for OPPs.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>> ---
>> drivers/opp/of.c | 17 ++++++++++++-----
>> include/linux/pm_opp.h | 8 ++++++++
>> 2 files changed, 20 insertions(+), 5 deletions(-)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
Thanks Viresh for the ACK!
Regards,
Lukasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] KVM: arm64: Don't defer TLB invalidation when zapping table entries
From: Oliver Upton @ 2024-03-26 8:34 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, linux-arm-kernel, Catalin Marinas, Gavin Shan,
Marc Zyngier, Mostafa Saleh, Quentin Perret,
Raghavendra Rao Ananta, Ryan Roberts, Shaoqin Huang,
Suzuki K Poulose, Zenghui Yu
In-Reply-To: <20240325185158.8565-2-will@kernel.org>
Hey Will,
On Mon, Mar 25, 2024 at 06:51:56PM +0000, Will Deacon wrote:
> Commit 7657ea920c54 ("KVM: arm64: Use TLBI range-based instructions for
> unmap") introduced deferred TLB invalidation for the stage-2 page-table
> so that range-based invalidation can be used for the accumulated
> addresses. This works fine if the structure of the page-tables remains
> unchanged, but if entire tables are zapped and subsequently freed then
> we transiently leave the hardware page-table walker with a reference
> to freed memory thanks to the translation walk caches.
Yikes! Well spotted. This is rather unfortunate because the unmap path
has been found to be a massive pain w/o aggregating invalidations. But
sacrificing correctness in the name of performance... No thanks :)
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index 3fae5830f8d2..de0b667ba296 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -896,9 +896,11 @@ static void stage2_unmap_put_pte(const struct kvm_pgtable_visit_ctx *ctx,
> if (kvm_pte_valid(ctx->old)) {
> kvm_clear_pte(ctx->ptep);
>
> - if (!stage2_unmap_defer_tlb_flush(pgt))
> + if (!stage2_unmap_defer_tlb_flush(pgt) ||
> + kvm_pte_table(ctx->old, ctx->level)) {
> kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, mmu,
> ctx->addr, ctx->level);
> + }
I'm not sure this is correct, though. My understanding of TTL is that
we're telling hardware where the *leaf* entry we're invalidating is
found, however here we know that the addressed PTE is a table entry.
So maybe in the case of a table PTE this invalidation should
TLBI_TTL_UNKNOWN.
> }
>
> mm_ops->put_page(ctx->ptep);
At least for the 'normal' MMU where we use RCU, this could be changed to
->free_unlinked_table() which would defer the freeing of memory til
after the invalidation completes. But that still hoses pKVM's stage-2
MMU freeing in-place.
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] KVM: arm64: Don't pass a TLBI level hint when zapping table entries
From: Oliver Upton @ 2024-03-26 8:37 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, linux-arm-kernel, Catalin Marinas, Gavin Shan,
Marc Zyngier, Mostafa Saleh, Quentin Perret,
Raghavendra Rao Ananta, Ryan Roberts, Shaoqin Huang,
Suzuki K Poulose, Zenghui Yu
In-Reply-To: <20240325185158.8565-3-will@kernel.org>
On Mon, Mar 25, 2024 at 06:51:57PM +0000, Will Deacon wrote:
> The TLBI level hints are for leaf entries only, so take care not to pass
> them incorrectly after clearing a table entry.
>
> Cc: Gavin Shan <gshan@redhat.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Quentin Perret <qperret@google.com>
> Fixes: 82bb02445de5 ("KVM: arm64: Implement kvm_pgtable_hyp_unmap() at EL2")
> Fixes: 6d9d2115c480 ("KVM: arm64: Add support for stage-2 map()/unmap() in generic page-table")
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> arch/arm64/kvm/hyp/pgtable.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> index de0b667ba296..a40dafc43bb6 100644
> --- a/arch/arm64/kvm/hyp/pgtable.c
> +++ b/arch/arm64/kvm/hyp/pgtable.c
> @@ -528,7 +528,7 @@ static int hyp_unmap_walker(const struct kvm_pgtable_visit_ctx *ctx,
>
> kvm_clear_pte(ctx->ptep);
> dsb(ishst);
> - __tlbi_level(vae2is, __TLBI_VADDR(ctx->addr, 0), ctx->level);
> + __tlbi_level(vae2is, __TLBI_VADDR(ctx->addr, 0), TLBI_TTL_UNKNOWN);
> } else {
> if (ctx->end - ctx->addr < granule)
> return -EINVAL;
> @@ -896,10 +896,12 @@ static void stage2_unmap_put_pte(const struct kvm_pgtable_visit_ctx *ctx,
> if (kvm_pte_valid(ctx->old)) {
> kvm_clear_pte(ctx->ptep);
>
> - if (!stage2_unmap_defer_tlb_flush(pgt) ||
> - kvm_pte_table(ctx->old, ctx->level)) {
> - kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, mmu,
> - ctx->addr, ctx->level);
> + if (kvm_pte_table(ctx->old, ctx->level)) {
> + kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, mmu, ctx->addr,
> + TLBI_TTL_UNKNOWN);
Ah, here it is! Can you add this invalidation to patch #1? Otherwise the
fix will intermediately introduce another bug, AFAICT.
Rest of the diff looks good.
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] KVM: arm64: Allow only the specified FF-A calls to be forwarded to TZ
From: Oliver Upton @ 2024-03-26 8:42 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, james.morse, jean-philippe, maz, qperret,
qwandor, suzuki.poulose, tabba, will, yuzenghui, kvmarm,
linux-arm-kernel, linux-kernel, kernel-team
In-Reply-To: <ZgFgI0Ky2m4MUbw-@google.com>
On Mon, Mar 25, 2024 at 11:29:39AM +0000, Sebastian Ene wrote:
> On Fri, Mar 22, 2024 at 07:07:52PM -0700, Oliver Upton wrote:
> > On Fri, Mar 22, 2024 at 12:43:03PM +0000, Sebastian Ene wrote:
> > > The previous logic used a deny list to filter the FF-A calls. Because of
> > > this, some of the calls escaped the check and they were forwarded by
> > > default to Trustzone. (eg. FFA_MSG_SEND_DIRECT_REQ was denied but the 64
> > > bit version of the call was not).
> > > Modify the logic to use an allowlist and allow only the calls specified in
> > > the filter function to be proxied to TZ from the hypervisor.
>
> Hi Oliver,
>
> >
> > I had discussed this with Will back when the feature was upstreamed and
> > he said there's a lot of off-label calls that necessitate a denylist
> > implementation. Has anything changed to give us confidence that we can
> > be restrictive, at least on the FF-A range?
> >
>
> I remember your proposal for having an allowlist instead. The current change makes
> sense if we have https://lore.kernel.org/kvmarm/20240322124303.309423-1-sebastianene@google.com/
> which opens the window for more FF-A calls to be forwarded to TZ.
Got it. Last time I didn't catch the level of abuse we expect to endure
from vendors, but now it seems we will not support non-conforming calls
that appear in standardized SMC ranges.
Adding mention of this to the changelog might be a good idea then.
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net] net: dsa: mt7530: fix improper frames on all 25MHz and 40MHz XTAL MT7530
From: patchwork-bot+netdevbpf @ 2024-03-26 8:50 UTC (permalink / raw)
To: =?utf-8?b?QXLEsW7DpyDDnE5BTCB2aWEgQjQgUmVsYXkgPGRldm51bGwrYXJpbmMudW5hbC5h?=,
=?utf-8?b?cmluYzkuY29tQGtlcm5lbC5vcmc+?=
Cc: daniel, dqfext, sean.wang, andrew, f.fainelli, olteanv, davem,
edumazet, kuba, pabeni, matthias.bgg, angelogioacchino.delregno,
Landen.Chao, bartel.eerdekens, mithat.guner, erkin.bozoglu,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek,
arinc.unal
In-Reply-To: <20240320-for-net-mt7530-fix-25mhz-xtal-with-direct-phy-access-v1-1-d92f605f1160@arinc9.com>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Wed, 20 Mar 2024 23:45:30 +0300 you wrote:
> From: Arınç ÜNAL <arinc.unal@arinc9.com>
>
> The MT7530 switch after reset initialises with a core clock frequency that
> works with a 25MHz XTAL connected to it. For 40MHz XTAL, the core clock
> frequency must be set to 500MHz.
>
> The mt7530_pll_setup() function is responsible of setting the core clock
> frequency. Currently, it runs on MT7530 with 25MHz and 40MHz XTAL. This
> causes MT7530 switch with 25MHz XTAL to egress and ingress frames
> improperly.
>
> [...]
Here is the summary with links:
- [net] net: dsa: mt7530: fix improper frames on all 25MHz and 40MHz XTAL MT7530
https://git.kernel.org/netdev/net/c/5f563c31ff0c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/rockchip: vop2: Remove AR30 and AB30 format support
From: Heiko Stuebner @ 2024-03-26 8:53 UTC (permalink / raw)
To: Andy Yan
Cc: Heiko Stuebner, linux-rockchip, hjc, Andy Yan, linux-kernel,
s.hauer, dri-devel, linux-arm-kernel
In-Reply-To: <20240304100952.3592984-1-andyshrk@163.com>
On Mon, 4 Mar 2024 18:09:52 +0800, Andy Yan wrote:
> From: Andy Yan <andy.yan@rock-chips.com>
>
> The Alpha blending for 30 bit RGB/BGR are not
> functioning properly for rk3568/rk3588, so remove
> it from the format list.
>
>
> [...]
Applied, thanks!
[1/1] drm/rockchip: vop2: Remove AR30 and AB30 format support
commit: 905f7d53a1bc105b22d9ffd03dc11b6b42ec6ba6
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/3] clk: samsung: Implement manual PLL control for ARM64 SoCs
From: Krzysztof Kozlowski @ 2024-03-26 9:00 UTC (permalink / raw)
To: Sam Protsenko
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Michael Turquette,
Stephen Boyd, Rob Herring, Conor Dooley, Tomasz Figa,
linux-samsung-soc, linux-clk, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240301015118.30072-1-semen.protsenko@linaro.org>
On Thu, 29 Feb 2024 19:51:16 -0600, Sam Protsenko wrote:
> Some ARM64 Exynos chips are capable to control PLL clocks automatically.
> For those chips, whether the PLL is controlled automatically or manually
> is chosen in PLL_CON1 register with next bits:
>
> [28] ENABLE_AUTOMATIC_CLKGATING
> [1] MANUAL_PLL_CTRL
> [0] AUTO_PLL_CTRL
>
> [...]
Applied, thanks!
[1/3] clk: samsung: Implement manual PLL control for ARM64 SoCs
https://git.kernel.org/krzk/linux/c/7fa37084061fef80dab81bc062c6ec0fa8c26b2d
[2/3] clk: samsung: exynos850: Add CMU_CPUCL0 and CMU_CPUCL1
https://git.kernel.org/krzk/linux/c/dedf87341ad66fa6889fedcf610b6941d2d3bcb6
[3/3] arm64: dts: exynos: Add CPU clocks for Exynos850
https://git.kernel.org/krzk/linux/c/704094c5981287c85dfdb0bf53abdfcdcc1f8597
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] dt-bindings: memory-controllers: add Samsung S5Pv210 SoC DMC
From: Krzysztof Kozlowski @ 2024-03-26 9:00 UTC (permalink / raw)
To: Rob Herring, Conor Dooley, Alim Akhtar, linux-kernel, devicetree,
linux-arm-kernel, linux-samsung-soc, Krzysztof Kozlowski
In-Reply-To: <20240312190348.724361-1-krzysztof.kozlowski@linaro.org>
On Tue, 12 Mar 2024 20:03:48 +0100, Krzysztof Kozlowski wrote:
> Document bindings for the S5Pv210 SoC DMC memory controller, already
> used in DTS and Linux CPU frequency scaling driver. The binding looks
> quite empty and is most likely incomplete, but the platform is so old
> that no one expects any effort on this, except documenting what is in
> DTS.
>
>
> [...]
Applied, thanks!
[1/1] dt-bindings: memory-controllers: add Samsung S5Pv210 SoC DMC
https://git.kernel.org/krzk/linux-mem-ctrl/c/e23359d88a81679e7c55d221e7cb4c39abf5d760
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: iio: dac: ti,dac5571: Add DAC081C081 support
From: Sean Nyekjaer @ 2024-03-26 9:00 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, imx, linux-arm-kernel, Trevor Zaharichuk, Greg Lytle,
Jonathan Cameron, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-iio
In-Reply-To: <20240325203245.31660-2-laurent.pinchart@ideasonboard.com>
> On 25 Mar 2024, at 21.32, Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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>
Reviewed-by: Sean Nyekjaer <sean@geanix.com>
> ---
> 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
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/5] iio: dac: ti-dac5571: Add DAC081C081 support
From: Sean Nyekjaer @ 2024-03-26 9:00 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, imx, linux-arm-kernel, Trevor Zaharichuk, Greg Lytle,
Jonathan Cameron, Lars-Peter Clausen, linux-iio
In-Reply-To: <20240325203245.31660-3-laurent.pinchart@ideasonboard.com>
> On 25 Mar 2024, at 21.32, Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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 driver. Extends the driver to support this
> chip.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sean Nyekjaer <sean@geanix.com <mailto:sean@geanix.com>>
> ---
> drivers/iio/dac/ti-dac5571.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iio/dac/ti-dac5571.c b/drivers/iio/dac/ti-dac5571.c
> index efb1269a77c1..c5162b72951a 100644
> --- a/drivers/iio/dac/ti-dac5571.c
> +++ b/drivers/iio/dac/ti-dac5571.c
> @@ -13,6 +13,7 @@
> * https://www.ti.com/lit/ds/symlink/dac5573.pdf
> * https://www.ti.com/lit/ds/symlink/dac6573.pdf
> * https://www.ti.com/lit/ds/symlink/dac7573.pdf
> + * https://www.ti.com/lit/ds/symlink/dac081c081.pdf
> * https://www.ti.com/lit/ds/symlink/dac121c081.pdf
> */
>
> @@ -386,6 +387,7 @@ static void dac5571_remove(struct i2c_client *i2c)
> }
>
> static const struct of_device_id dac5571_of_id[] = {
> + {.compatible = "ti,dac081c081", .data = &dac5571_spec[single_8bit] },
> {.compatible = "ti,dac121c081", .data = &dac5571_spec[single_12bit] },
> {.compatible = "ti,dac5571", .data = &dac5571_spec[single_8bit] },
> {.compatible = "ti,dac6571", .data = &dac5571_spec[single_10bit] },
> @@ -401,6 +403,7 @@ static const struct of_device_id dac5571_of_id[] = {
> MODULE_DEVICE_TABLE(of, dac5571_of_id);
>
> static const struct i2c_device_id dac5571_id[] = {
> + {"dac081c081", (kernel_ulong_t)&dac5571_spec[single_8bit] },
> {"dac121c081", (kernel_ulong_t)&dac5571_spec[single_12bit] },
> {"dac5571", (kernel_ulong_t)&dac5571_spec[single_8bit] },
> {"dac6571", (kernel_ulong_t)&dac5571_spec[single_10bit] },
> --
> Regards,
>
> Laurent Pinchart
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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