* Re: [RESEND v7 26/37] dt-bindings: vendor-prefixes: Add iodata
From: Krzysztof Kozlowski @ 2024-04-04 6:57 UTC (permalink / raw)
To: Yoshinori Sato, linux-sh
Cc: Damien Le Moal, Niklas Cassel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
David Airlie, Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Thomas Gleixner, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Greg Kroah-Hartman,
Jiri Slaby, Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <4649938dc48da6e449ef6f1987c7739ba3a80b42.1712207606.git.ysato@users.sourceforge.jp>
On 04/04/2024 07:14, Yoshinori Sato wrote:
> Add IO DATA DEVICE INC.
> https://www.iodata.com/
>
> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state why and what changed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RESEND v7 27/37] dt-bindings: ata: ata-generic: Add new targets
From: Krzysztof Kozlowski @ 2024-04-04 6:57 UTC (permalink / raw)
To: Yoshinori Sato, linux-sh
Cc: Damien Le Moal, Niklas Cassel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
David Airlie, Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Thomas Gleixner, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Greg Kroah-Hartman,
Jiri Slaby, Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <53f85cc2e124d1c2e7394458b73293d797817d6d.1712207606.git.ysato@users.sourceforge.jp>
On 04/04/2024 07:14, Yoshinori Sato wrote:
> Added new ata-generic target.
> - iodata,usl-5p-ata
> - renesas,rts7751r2d-ata
>
> Each boards have simple IDE Interface. Use ATA generic driver.
>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state why and what changed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mfd: Add ROHM BD71879
From: Krzysztof Kozlowski @ 2024-04-04 6:59 UTC (permalink / raw)
To: Andreas Kemnade, lee, robh+dt, krzysztof.kozlowski+dt, conor+dt,
mazziesaccount, devicetree, linux-kernel
In-Reply-To: <20240402193515.513713-2-andreas@kemnade.info>
On 02/04/2024 21:35, Andreas Kemnade wrote:
> As this chip was seen in several devices in the wild, add it.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
> ---
> Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> index 0b62f854bf6b..e4df09e8961c 100644
> --- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> @@ -17,7 +17,9 @@ description: |
>
> properties:
> compatible:
> - const: rohm,bd71828
> + enum:
> + - rohm,bd71828
> + - rohm,bd71879
In your second commit you claim they are compatible, so why they are not
marked as such?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: iio: imu: add icm42688 inside inv_icm42600
From: Krzysztof Kozlowski @ 2024-04-04 7:03 UTC (permalink / raw)
To: inv.git-commit, jic23, robh, krzysztof.kozlowski+dt, conor+dt
Cc: lars, linux-iio, devicetree, Jean-Baptiste Maneyrol
In-Reply-To: <20240402090046.764572-2-inv.git-commit@tdk.com>
On 02/04/2024 11:00, inv.git-commit@tdk.com wrote:
> From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
>
> Add bindings for ICM-42688-P chip.
>
> Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
> ---
> .../devicetree/bindings/iio/imu/invensense,icm42600.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> index 7cd05bcbee31..5e0bed2c45de 100644
> --- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> +++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> @@ -32,6 +32,7 @@ properties:
> - invensense,icm42605
> - invensense,icm42622
> - invensense,icm42631
> + - invensense,icm42688
>
> reg:
> maxItems: 1
> --
> 2.34.1
>
> TDK-Micronas GmbH
> Company Headquarters / Sitz der Gesellschaft: Freiburg i. Br. - Municipal Court of / Amtsgericht: Freiburg i. Br. HRB 6108. VAT ID / USt-IdNr.: DE 812878184
> Management / Geschäftsführung: Sam Maddalena
>
> This e-mail and any files transmitted with it are confidential information of TDK-Micronas and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender by return e-mail and delete all copies of this e-mail message along with all attachments. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Don't send patches which are confidential. Community cannot take them.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: imu: inv_icm42600: add support of ICM-42688-P
From: Krzysztof Kozlowski @ 2024-04-04 7:04 UTC (permalink / raw)
To: inv.git-commit, jic23, robh, krzysztof.kozlowski+dt, conor+dt
Cc: lars, linux-iio, devicetree, Jean-Baptiste Maneyrol
In-Reply-To: <20240402090046.764572-3-inv.git-commit@tdk.com>
On 02/04/2024 11:00, inv.git-commit@tdk.com wrote:
> From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
>
Missing commit msg explaining why/what is happening.
> Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
> ---
> drivers/iio/imu/inv_icm42600/inv_icm42600.h | 2 ++
> drivers/iio/imu/inv_icm42600/inv_icm42600_core.c | 5 +++++
> drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c | 3 +++
> drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c | 3 +++
> 4 files changed, 13 insertions(+)
> 2.34.1
>
> TDK-Micronas GmbH
> Company Headquarters / Sitz der Gesellschaft: Freiburg i. Br. - Municipal Court of / Amtsgericht: Freiburg i. Br. HRB 6108. VAT ID / USt-IdNr.: DE 812878184
> Management / Geschäftsführung: Sam Maddalena
>
> This e-mail and any files transmitted with it are confidential information of TDK-Micronas and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender by return e-mail and delete all copies of this e-mail message along with all attachments. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Sorry, we cannot work with confidential IP. You also made public your
company confidential data, so it looks bad. Please double check it with
your company legal department.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v7 00/37] Device Tree support for SH7751 based board
From: Niklas Cassel @ 2024-04-04 7:06 UTC (permalink / raw)
To: Yoshinori Sato
Cc: linux-sh, Damien Le Moal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
David Airlie, Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Thomas Gleixner, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Greg Kroah-Hartman,
Jiri Slaby, Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <cover.1712205900.git.ysato@users.sourceforge.jp>
On Thu, Apr 04, 2024 at 01:59:25PM +0900, Yoshinori Sato wrote:
> This is an updated version of something I wrote about 7 years ago.
> Minimum support for R2D-plus and LANDISK.
> I think R2D-1 will work if you add AX88796 to dts.
> And board-specific functions and SCI's SPI functions are not supported.
>
> You can get it working with qemu found here.
> https://gitlab.com/yoshinori.sato/qemu/-/tree/landisk
Why send this as one huge series?
These are the mailing lists that you have on CC:
linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel,
linux-pci, linux-serial, linux-fbdev
I really think that you will be able to get all these changes accepted much
faster if you split this series in to one series per subsystem/mailing list.
Kind regards,
Niklas
^ permalink raw reply
* Re: [PATCH v3 23/25] drivers: media: i2c: imx258: Add support for powerdown gpio
From: Sakari Ailus @ 2024-04-04 7:07 UTC (permalink / raw)
To: Ondřej Jirman, git, linux-media, dave.stevenson,
jacopo.mondi, mchehab, robh, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, devicetree, imx,
linux-arm-kernel, linux-kernel, pavel, phone-devel
In-Reply-To: <wjlcde7yoooygj4hhdmiwrdloh6l4p6i2qbmjek5uwsifyzwgu@xjhutvmsdfou>
Hi Ondřej,
On Wed, Apr 03, 2024 at 06:57:56PM +0200, Ondřej Jirman wrote:
> Hi Sakari and Luis,
>
> On Wed, Apr 03, 2024 at 04:25:41PM GMT, Sakari Ailus wrote:
> > Hi Luis, Ondrej,
> >
> > On Wed, Apr 03, 2024 at 09:03:52AM -0600, git@luigi311.com wrote:
> > > From: Luis Garcia <git@luigi311.com>
> > >
> > > On some boards powerdown signal needs to be deasserted for this
> > > sensor to be enabled.
> > >
> > > Signed-off-by: Ondrej Jirman <megi@xff.cz>
> > > Signed-off-by: Luis Garcia <git@luigi311.com>
> > > ---
> > > drivers/media/i2c/imx258.c | 13 +++++++++++++
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> > > index 30352c33f63c..163f04f6f954 100644
> > > --- a/drivers/media/i2c/imx258.c
> > > +++ b/drivers/media/i2c/imx258.c
> > > @@ -679,6 +679,8 @@ struct imx258 {
> > > unsigned int lane_mode_idx;
> > > unsigned int csi2_flags;
> > >
> > > + struct gpio_desc *powerdown_gpio;
> > > +
> > > /*
> > > * Mutex for serialized access:
> > > * Protect sensor module set pad format and start/stop streaming safely.
> > > @@ -1213,6 +1215,8 @@ static int imx258_power_on(struct device *dev)
> > > struct imx258 *imx258 = to_imx258(sd);
> > > int ret;
> > >
> > > + gpiod_set_value_cansleep(imx258->powerdown_gpio, 0);
> >
> > What does the spec say? Should this really happen before switching on the
> > supplies below?
>
> There's no powerdown input in the IMX258 manual. The manual only mentions
> that XCLR (reset) should be held low during power on.
>
> https://megous.com/dl/tmp/15b0992a720ab82d.png
>
> https://megous.com/dl/tmp/f2cc991046d97641.png
>
> This sensor doesn’t have a built-in “Power ON Reset” function. The XCLR pin
> is set to “LOW” and the power supplies are brought up. Then the XCLR pin
> should be set to “High” after INCK supplied.
>
> So this input is some feature on camera module itself outside of the
> IMX258 chip, which I think is used to gate power to the module. Eg. on Pinephone
> Pro, there are two modules with shared power rails, so enabling supply to
> one module enables it to the other one, too. So this input becomes the only way
> to really enable/disable power to the chip when both are used at once at some
> point, because regulator_bulk_enable/disable becomes ineffective at that point.
The hardware designers sometimes do not consider the difficulty of
implementing software support for their choice of design. Maybe this could
be modelled as a GPIO regulator? But it'd depend on another regulator and
I'm not sure that is covered.
The camera sensor generally consume very little power in software standby
mode so the potential saving here are probably irrelevant.
>
> Luis, maybe you saw some other datasheet that mentions this input? IMO,
> it just gates the power rails via some mosfets on the module itself, since
> there's not power down input to the chip itself.
>
> kind regards,
> o.
>
> > > +
> > > ret = regulator_bulk_enable(IMX258_NUM_SUPPLIES,
> > > imx258->supplies);
> > > if (ret) {
> > > @@ -1224,6 +1228,7 @@ static int imx258_power_on(struct device *dev)
> > > ret = clk_prepare_enable(imx258->clk);
> > > if (ret) {
> > > dev_err(dev, "failed to enable clock\n");
> > > + gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
> > > regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
> > > }
> > >
> > > @@ -1238,6 +1243,8 @@ static int imx258_power_off(struct device *dev)
> > > clk_disable_unprepare(imx258->clk);
> > > regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
> > >
> > > + gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
> > > +
> > > return 0;
> > > }
> > >
> > > @@ -1541,6 +1548,12 @@ static int imx258_probe(struct i2c_client *client)
> > > if (!imx258->variant_cfg)
> > > imx258->variant_cfg = &imx258_cfg;
> > >
> > > + /* request optional power down pin */
> > > + imx258->powerdown_gpio = devm_gpiod_get_optional(&client->dev, "powerdown",
> > > + GPIOD_OUT_HIGH);
> > > + if (IS_ERR(imx258->powerdown_gpio))
> > > + return PTR_ERR(imx258->powerdown_gpio);
> > > +
> > > /* Initialize subdev */
> > > v4l2_i2c_subdev_init(&imx258->sd, client, &imx258_subdev_ops);
> > >
> >
> > --
> > Regards,
> >
> > Sakari Ailus
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v19 2/9] usb: dwc3: core: Access XHCI address space temporarily to read port info
From: Johan Hovold @ 2024-04-04 7:21 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp, Johan Hovold
In-Reply-To: <20240404051229.3082902-3-quic_kriskura@quicinc.com>
On Thu, Apr 04, 2024 at 10:42:22AM +0530, Krishna Kurapati wrote:
> +static int dwc3_get_num_ports(struct dwc3 *dwc)
> +{
> + void __iomem *base;
> + u8 major_revision;
> + u32 offset;
> + u32 val;
> +
> + /*
> + * Remap xHCI address space to access XHCI ext cap regs since it is
> + * needed to get information on number of ports present.
> + */
> + base = ioremap(dwc->xhci_resources[0].start,
> + resource_size(&dwc->xhci_resources[0]));
> + if (!base)
> + return PTR_ERR(base);
This is obviously still broken. You need to update the return value as
well.
Fix in v20.
Johan
^ permalink raw reply
* Re: [RFC PATCH 0/6] Support ROHM BD96801 scalable PMIC
From: Matti Vaittinen @ 2024-04-04 7:26 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Wim Van Sebroeck, Guenter Roeck,
devicetree, linux-kernel, linux-watchdog
In-Reply-To: <cover.1712058690.git.mazziesaccount@gmail.com>
On 4/2/24 16:07, Matti Vaittinen wrote:
> Another "oddity" is that the PMIC has two physical IRQ lines. When I
> last wrote this patch in 2021 I had some naming collison in debugfs for
> the IRQ domains. Back then I used:
> irq_domain_update_bus_token(intb_domain, DOMAIN_BUS_WIRED);
> to work-around the issue. Now, when rebasing to v6.9-rc1 the naming
> collision was gone and things seemed to work. However, it'd be great if
> the IRQ code in MFD driver was reviewed by greater minds :)
It appears my statement "things seemed to work" is a bit too optimistic.
I am afraid my approach of having two separate IRQ domains for one
device (and DT-node) is just somehow fundamentally wrong. It'd be great
to learn what's the correct "ideology" here.
It appears the naming collision is still there. My config just had the
CONFIG_GENERIC_IRQ_DEBUGFS disabled. Enabling it shows the same naming
collison:
debugfs: File
':ocp:interconnect@48000000:segment@100000:target-module@9c000:i2c@0:pmic@60'
in directory 'domains' already present!
If I'm not mistaken the debugfs file name is generated from the
device-tree node path+name. This is a subtle hint that it is not
expected there are more than 1 IRQ-domain / device. I guess this kind of
makes sense if we can have more than 1 HWIRQ handled by a single domain
(I don't recall having to ever write such domain/IRQ-controller before,
but I think it should be possible).
I have now 3 new questions =)
1. Should we be able to have more than 1 IRQ domain / device?
2. Should regmap_irq support having more than 1 HWIRQ
3. If answer to 1 is "no" - should we protect against this somehow? (see
why below).
When CONFIG_GENERIC_IRQ_DEBUGFS is disabled, adding the two IRQ
controllers with own IRQ domains (intb and errb here) to a single device
is seemingly successful. I see no complaints / errors. Also, most of the
IRQs seem to work - but not all. In my case trying to issue:
cat /proc/interrupts
will oops. Also, looking in the /sys/kernel/irq/ lists folders for all
the "intb" and "errb" IRQs - but reading the files contained in these
directories will cause an oops for all "errb" interrupts except for the
first 16.
Finally, if I use the
irq_domain_update_bus_token(intb_domain, DOMAIN_BUS_WIRED);
to add "-1" at the end of the "intb" - domain name resulting domains:
:ocp:interconnect@48000000:segment@100000:target-module@9c000:i2c@0:pmic@60
:ocp:interconnect@48000000:segment@100000:target-module@9c000:i2c@0:pmic@60-1
then it seems that reading the IRQ information from the /proc/interrupts
works as expected. Here I am making a wild guess that the name of the
domain is used as a key for some data-lookups, and having two domains
with a same name will either overwrite something or cause wrong domain
data to be fetched. (This is just guessing for now).
Any tips, hints or thoughts on this?
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* [PATCH] clk: rockchip: clk-rk3568.c: Add missing USB480M_PHY mux
From: Sascha Hauer @ 2024-04-04 7:27 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-clk, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, David Jander, Sascha Hauer
From: David Jander <david@protonic.nl>
The USB480M clock can source from a MUX that selects the clock to come
from either of the USB-phy internal 480MHz PLLs. These clocks are
provided by the USB phy driver.
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/clk/rockchip/clk-rk3568.c | 4 ++++
include/dt-bindings/clock/rk3568-cru.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3568.c b/drivers/clk/rockchip/clk-rk3568.c
index 8cb21d10beca2..2d44bcaef046b 100644
--- a/drivers/clk/rockchip/clk-rk3568.c
+++ b/drivers/clk/rockchip/clk-rk3568.c
@@ -215,6 +215,7 @@ static const struct rockchip_cpuclk_reg_data rk3568_cpuclk_data = {
PNAME(mux_pll_p) = { "xin24m" };
PNAME(mux_usb480m_p) = { "xin24m", "usb480m_phy", "clk_rtc_32k" };
+PNAME(mux_usb480m_phy_p) = { "clk_usbphy0_480m", "clk_usbphy1_480m"};
PNAME(mux_armclk_p) = { "apll", "gpll" };
PNAME(clk_i2s0_8ch_tx_p) = { "clk_i2s0_8ch_tx_src", "clk_i2s0_8ch_tx_frac", "i2s0_mclkin", "xin_osc0_half" };
PNAME(clk_i2s0_8ch_rx_p) = { "clk_i2s0_8ch_rx_src", "clk_i2s0_8ch_rx_frac", "i2s0_mclkin", "xin_osc0_half" };
@@ -485,6 +486,9 @@ static struct rockchip_clk_branch rk3568_clk_branches[] __initdata = {
MUX(USB480M, "usb480m", mux_usb480m_p, CLK_SET_RATE_PARENT,
RK3568_MODE_CON0, 14, 2, MFLAGS),
+ MUX(USB480M_PHY, "usb480m_phy", mux_usb480m_phy_p, CLK_SET_RATE_PARENT,
+ RK3568_MISC_CON2, 15, 1, MFLAGS),
+
/* PD_CORE */
COMPOSITE(0, "sclk_core_src", apll_gpll_npll_p, CLK_IGNORE_UNUSED,
RK3568_CLKSEL_CON(2), 8, 2, MFLAGS, 0, 4, DFLAGS | CLK_DIVIDER_READ_ONLY,
diff --git a/include/dt-bindings/clock/rk3568-cru.h b/include/dt-bindings/clock/rk3568-cru.h
index d29890865150d..5263085c5b238 100644
--- a/include/dt-bindings/clock/rk3568-cru.h
+++ b/include/dt-bindings/clock/rk3568-cru.h
@@ -78,6 +78,7 @@
#define CPLL_333M 9
#define ARMCLK 10
#define USB480M 11
+#define USB480M_PHY 12
#define ACLK_CORE_NIU2BUS 18
#define CLK_CORE_PVTM 19
#define CLK_CORE_PVTM_CORE 20
---
base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
change-id: 20240404-clk-rockchip-rk3568-add-usb480m-phy-mux-882e40565a26
Best regards,
--
Sascha Hauer <s.hauer@pengutronix.de>
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: debix-a: Disable i2c2 in base .dts
From: Marco Felsch @ 2024-04-04 7:42 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, imx, linux-arm-kernel, Rob Herring, Jacopo Mondi,
Pengutronix Kernel Team, Shawn Guo, Sascha Hauer, Conor Dooley,
Krzysztof Kozlowski, Jacopo Mondi, Fabio Estevam
In-Reply-To: <20240404002009.10052-1-laurent.pinchart@ideasonboard.com>
On 24-04-04, Laurent Pinchart wrote:
> From: Jacopo Mondi <jacopo@jmondi.org>
>
> The I2C2 bus is used for the CSI and DSI connectors only, no devices are
> connected to it on neither the Debix Model A nor its IO board. Disable
> the bus in the board's .dts and remove its clock frequency settings, as
> the value depends solely on the devices conncted to the CSI and DSI
> connectors. Display panel or camera sensor overlays will configure and
> enable the bus when necessary.
>
> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
^ permalink raw reply
* Re: [PATCH v4 0/8] cpufreq: sun50i: Add Allwinner H616 support
From: Ryan Walklin @ 2024-04-04 7:44 UTC (permalink / raw)
To: Viresh Kumar, Andre Przywara
Cc: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki, linux-pm,
devicetree, linux-sunxi, linux-arm-kernel, Brandon Cheo Fusi,
Martin Botka, Martin Botka, Chris Morgan, Mark Rutland,
Lorenzo Pieralisi, Sudeep Holla
In-Reply-To: <20240404064027.shjqvqih7s5rnv2i@vireshk-i7>
On Thu, 4 Apr 2024, at 7:40 PM, Viresh Kumar wrote:
> Is it okay to merge all the changes via the cpufreq tree ?
I have tested this series with an H700-based board, and have at least one speed-bin (1.032GHz) is not supported although the governor attempts to enable it based on the opp-supported-hw bitmask, and I am unable to reach the 1.5GHz bin at 1.16v (or higher) despite it working on the vendor BSP (kernel panic at boot if enabled), so this may need some slight rework.
I have reached out to Andre on IRC to debug.
Ryan
^ permalink raw reply
* RE: [PATCH v2 2/5] irqchip/renesas-rzg2l: Add support for RZ/Five SoC
From: Biju Das @ 2024-04-04 7:44 UTC (permalink / raw)
To: Prabhakar, Geert Uytterhoeven, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Paul Walmsley,
Palmer Dabbelt, Albert Ou
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org,
linux-riscv@lists.infradead.org, Prabhakar Mahadev Lad
In-Reply-To: <20240403203503.634465-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
Thanks for the patch.
> -----Original Message-----
> From: Prabhakar <prabhakar.csengg@gmail.com>
> Sent: Wednesday, April 3, 2024 9:35 PM
> Subject: [PATCH v2 2/5] irqchip/renesas-rzg2l: Add support for RZ/Five SoC
>
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> The IX45 block has additional mask registers (NMSK/IMSK/TMSK) as compared to the RZ/G2L (family)
> SoC.
>
> Introduce masking/unmasking support for IRQ and TINT interrupts in IRQC controller driver. Two new
> registers, IMSK and TMSK, are defined to handle masking on RZ/Five SoC. The implementation utilizes
> a new data structure, `struct rzg2l_irqc_data`, to determine mask support for a specific controller
> instance.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v1->v2
> - Added IRQCHIP_MATCH() for RZ/Five
> - Retaining a copy of OF data in priv
> - Rebased the changes
> ---
> drivers/irqchip/irq-renesas-rzg2l.c | 137 +++++++++++++++++++++++++++-
> 1 file changed, 132 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/irqchip/irq-renesas-rzg2l.c b/drivers/irqchip/irq-renesas-rzg2l.c
> index f6484bf15e0b..6fa8d65605dc 100644
> --- a/drivers/irqchip/irq-renesas-rzg2l.c
> +++ b/drivers/irqchip/irq-renesas-rzg2l.c
> @@ -37,6 +37,8 @@
> #define TSSEL_SHIFT(n) (8 * (n))
> #define TSSEL_MASK GENMASK(7, 0)
> #define IRQ_MASK 0x3
> +#define IMSK 0x10010
> +#define TMSK 0x10020
>
> #define TSSR_OFFSET(n) ((n) % 4)
> #define TSSR_INDEX(n) ((n) / 4)
> @@ -66,15 +68,25 @@ struct rzg2l_irqc_reg_cache {
> u32 titsr[2];
> };
>
> +/**
> + * struct rzg2l_irqc_of_data - OF data structure
> + * @mask_supported: Indicates if mask registers are available */
> +struct rzg2l_irqc_of_data {
> + bool mask_supported;
> +};
> +
> /**
> * struct rzg2l_irqc_priv - IRQ controller private data structure
> * @base: Controller's base address
> + * @data: OF data pointer
> * @fwspec: IRQ firmware specific data
> * @lock: Lock to serialize access to hardware registers
> * @cache: Registers cache for suspend/resume
> */
> static struct rzg2l_irqc_priv {
> void __iomem *base;
> + const struct rzg2l_irqc_of_data *data;
> struct irq_fwspec fwspec[IRQC_NUM_IRQ];
> raw_spinlock_t lock;
> struct rzg2l_irqc_reg_cache cache;
> @@ -138,18 +150,102 @@ static void rzg2l_irqc_eoi(struct irq_data *d)
> irq_chip_eoi_parent(d);
> }
>
> +static void rzg2l_irqc_mask_irq_interrupt(struct rzg2l_irqc_priv *priv,
> + unsigned int hwirq)
> +{
> + u32 imsk = readl_relaxed(priv->base + IMSK);
> + u32 bit = BIT(hwirq - IRQC_IRQ_START);
> +
> + writel_relaxed(imsk | bit, priv->base + IMSK); }
> +
> +static void rzg2l_irqc_unmask_irq_interrupt(struct rzg2l_irqc_priv *priv,
> + unsigned int hwirq)
> +{
> + u32 imsk = readl_relaxed(priv->base + IMSK);
> + u32 bit = BIT(hwirq - IRQC_IRQ_START);
> +
> + writel_relaxed(imsk & ~bit, priv->base + IMSK); }
> +
> +static void rzg2l_irqc_mask_tint_interrupt(struct rzg2l_irqc_priv *priv,
> + unsigned int hwirq)
> +{
> + u32 tmsk = readl_relaxed(priv->base + TMSK);
> + u32 bit = BIT(hwirq - IRQC_TINT_START);
> +
> + writel_relaxed(tmsk | bit, priv->base + TMSK); }
> +
> +static void rzg2l_irqc_unmask_tint_interrupt(struct rzg2l_irqc_priv *priv,
> + unsigned int hwirq)
> +{
> + u32 tmsk = readl_relaxed(priv->base + TMSK);
> + u32 bit = BIT(hwirq - IRQC_TINT_START);
> +
> + writel_relaxed(tmsk & ~bit, priv->base + TMSK); }
> +
> +/* Must be called while priv->lock is held */ static void
> +rzg2l_irqc_mask_once(struct rzg2l_irqc_priv *priv, unsigned int hwirq)
> +{
> + if (!priv->data->mask_supported)
> + return;
> +
> + if (hwirq >= IRQC_IRQ_START && hwirq <= IRQC_IRQ_COUNT)
> + rzg2l_irqc_mask_irq_interrupt(priv, hwirq);
> + else if (hwirq >= IRQC_TINT_START && hwirq < IRQC_NUM_IRQ)
> + rzg2l_irqc_mask_tint_interrupt(priv, hwirq); }
> +
> +static void rzg2l_irqc_mask(struct irq_data *d) {
> + struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
> +
> + raw_spin_lock(&priv->lock);
> + rzg2l_irqc_mask_once(priv, irqd_to_hwirq(d));
> + raw_spin_unlock(&priv->lock);
> + irq_chip_mask_parent(d);
> +}
> +
> +/* Must be called while priv->lock is held */ static void
> +rzg2l_irqc_unmask_once(struct rzg2l_irqc_priv *priv, unsigned int
> +hwirq) {
> + if (!priv->data->mask_supported)
> + return;
> +
> + if (hwirq >= IRQC_IRQ_START && hwirq <= IRQC_IRQ_COUNT)
> + rzg2l_irqc_unmask_irq_interrupt(priv, hwirq);
> + else if (hwirq >= IRQC_TINT_START && hwirq < IRQC_NUM_IRQ)
> + rzg2l_irqc_unmask_tint_interrupt(priv, hwirq); }
> +
> +static void rzg2l_irqc_unmask(struct irq_data *d) {
> + struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
> +
> + raw_spin_lock(&priv->lock);
> + rzg2l_irqc_unmask_once(priv, irqd_to_hwirq(d));
> + raw_spin_unlock(&priv->lock);
> + irq_chip_unmask_parent(d);
> +}
> +
> static void rzg2l_tint_irq_endisable(struct irq_data *d, bool enable) {
> + struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
> unsigned int hw_irq = irqd_to_hwirq(d);
>
> if (hw_irq >= IRQC_TINT_START && hw_irq < IRQC_NUM_IRQ) {
> - struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
> u32 offset = hw_irq - IRQC_TINT_START;
> u32 tssr_offset = TSSR_OFFSET(offset);
> u8 tssr_index = TSSR_INDEX(offset);
> u32 reg;
>
> raw_spin_lock(&priv->lock);
> + if (enable)
> + rzg2l_irqc_unmask_once(priv, hw_irq);
> + else
> + rzg2l_irqc_mask_once(priv, hw_irq);
> reg = readl_relaxed(priv->base + TSSR(tssr_index));
> if (enable)
> reg |= TIEN << TSSEL_SHIFT(tssr_offset); @@ -157,6 +253,13 @@ static void
> rzg2l_tint_irq_endisable(struct irq_data *d, bool enable)
> reg &= ~(TIEN << TSSEL_SHIFT(tssr_offset));
> writel_relaxed(reg, priv->base + TSSR(tssr_index));
> raw_spin_unlock(&priv->lock);
> + } else {
> + raw_spin_lock(&priv->lock);
> + if (enable)
> + rzg2l_irqc_unmask_once(priv, hw_irq);
> + else
> + rzg2l_irqc_mask_once(priv, hw_irq);
> + raw_spin_unlock(&priv->lock);
> }
> }
>
> @@ -324,8 +427,8 @@ static struct syscore_ops rzg2l_irqc_syscore_ops = { static const struct
> irq_chip irqc_chip = {
> .name = "rzg2l-irqc",
> .irq_eoi = rzg2l_irqc_eoi,
> - .irq_mask = irq_chip_mask_parent,
> - .irq_unmask = irq_chip_unmask_parent,
> + .irq_mask = rzg2l_irqc_mask,
> + .irq_unmask = rzg2l_irqc_unmask,
I feel this will be clean, if we have
static const struct irq_chip rzg2l_irqc_chip = {
.name = "rzg2l-irqc",
...
.irq_mask = irq_chip_mask_parent,
.irq_unmask = irq_chip_unmask_parent,
....
};
static const struct irq_chip rzfive_irqc_chip = {
.name = "rzfive-irqc",
...
.irq_mask = rzfive_irqc_mask,
.irq_unmask = rzfive_irqc_unmask,
....
};
And passing this in rzg2l_irqc_init() and rzfive_irqc_init(), see below
return rzg2l_irqc_init_helper(node, parent, & rzg2l_irqc_chip);
return rzg2l_irqc_init_helper(node, parent, & rzfive_irqc_chip);
> .irq_disable = rzg2l_irqc_irq_disable,
> .irq_enable = rzg2l_irqc_irq_enable,
> .irq_get_irqchip_state = irq_chip_get_parent_state,
> @@ -401,7 +504,16 @@ static int rzg2l_irqc_parse_interrupts(struct rzg2l_irqc_priv *priv,
> return 0;
> }
>
> -static int rzg2l_irqc_init(struct device_node *node, struct device_node *parent)
> +static const struct rzg2l_irqc_of_data rzg2l_irqc_mask_supported_data = {
> + .mask_supported = true,
> +};
> +
> +static const struct rzg2l_irqc_of_data rzg2l_irqc_default_data = {
> + .mask_supported = false,
> +};
> +
> +static int rzg2l_irqc_init(struct device_node *node, struct device_node *parent,
> + const struct rzg2l_irqc_of_data *of_data)
Maybe rename this as rzg2l_irqc_init_helper()
> {
> struct irq_domain *irq_domain, *parent_domain;
> struct platform_device *pdev;
> @@ -422,6 +534,8 @@ static int rzg2l_irqc_init(struct device_node *node, struct device_node
> *parent)
> if (!rzg2l_irqc_data)
> return -ENOMEM;
>
> + rzg2l_irqc_data->data = of_data;
> +
> rzg2l_irqc_data->base = devm_of_iomap(&pdev->dev, pdev->dev.of_node, 0, NULL);
> if (IS_ERR(rzg2l_irqc_data->base))
> return PTR_ERR(rzg2l_irqc_data->base); @@ -472,8 +586,21 @@ static int
> rzg2l_irqc_init(struct device_node *node, struct device_node *parent)
> return ret;
> }
>
> +static int __init rzg2l_irqc_default_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + return rzg2l_irqc_init(node, parent, &rzg2l_irqc_default_data); }
> +
> +static int __init rzg2l_irqc_mask_supported_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + return rzg2l_irqc_init(node, parent, &rzg2l_irqc_mask_supported_data);
> +}
> +
> IRQCHIP_PLATFORM_DRIVER_BEGIN(rzg2l_irqc)
> -IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_init)
Retain this name
> +IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_default_init)
> +IRQCHIP_MATCH("renesas,r9a07g043f-irqc",
> +rzg2l_irqc_mask_supported_init)
Maybe rename this as rzfive_irqc_init ??
Cheers,
Biju
> IRQCHIP_PLATFORM_DRIVER_END(rzg2l_irqc)
> MODULE_AUTHOR("Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>");
> MODULE_DESCRIPTION("Renesas RZ/G2L IRQC Driver");
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: ti: k3-j722s-evm: Enable eMMC support
From: Francesco Dolcini @ 2024-04-04 7:45 UTC (permalink / raw)
To: Michael Walle
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240403102302.3934932-1-mwalle@kernel.org>
Hello Michael,
On Wed, Apr 03, 2024 at 12:23:02PM +0200, Michael Walle wrote:
> The J722S EVM has an on-board eMMC. Enable the SDHC interface for it.
> There is no pinmuxing required because the interface has dedicated pins.
>
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
> v2:
> - move status="okay" last
> ---
> arch/arm64/boot/dts/ti/k3-j722s-evm.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
> index cee3a8661d5e..6b148da2bcdc 100644
> --- a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
> @@ -369,6 +369,13 @@ partition@3fc0000 {
>
> };
>
> +&sdhci0 {
> + ti,driver-strength-ohm = <50>;
According to the latest DTS coding style guidelines this needs to be
just before status.
https://docs.kernel.org/devicetree/bindings/dts-coding-style.html#order-of-properties-in-device-node
Yes, we would need a checker, I know and I agree. At least now we moved
out of the tribal knowledge way of working with every maintainer having
slightly different expectation on this topic ... one step at a time :-)
> + disable-wp;
> + bootph-all;
> + status = "okay";
> +};
Francesco
^ permalink raw reply
* Re: [RESEND v7 19/37] dt-bindings: interrupt-controller: renesas,sh7751-irl-ext: Add json-schema
From: Rob Herring @ 2024-04-04 7:45 UTC (permalink / raw)
To: Yoshinori Sato
Cc: Andrew Morton, Michael Turquette, Laurent Pinchart, linux-ide,
Bjorn Helgaas, Lee Jones, linux-kernel, Sam Ravnborg,
Stephen Boyd, linux-sh, linux-renesas-soc, Thomas Gleixner,
Sergey Shtylyov, Krzysztof Kozlowski, Linus Walleij,
Krzysztof Wilczyński, devicetree, Helge Deller, dri-devel,
Jonathan Corbet, Biju Das, Guenter Roeck, Daniel Lezcano,
Damien Le Moal, Hyeonggon Yoo, Anup Patel, Maxime Ripard,
Chris Morgan, Jiri Slaby, Uwe Kleine-König,
Thomas Zimmermann, Javier Martinez Canillas, David Rientjes,
Azeem Shaikh, Conor Dooley, Arnd Bergmann, Rich Felker,
linux-fbdev, Stephen Rothwell, John Paul Adrian Glaubitz,
Daniel Vetter, linux-serial, linux-pci, Niklas Cassel,
Sebastian Reichel, Max Filippov, Manikanta Guntupalli, Guo Ren,
Jacky Huang, linux-clk, David Airlie, Magnus Damm,
Geert Uytterhoeven, Maarten Lankhorst, Herve Codina,
Vlastimil Babka, Greg Kroah-Hartman, Shawn Guo, Heiko Stuebner,
Baoquan He, Kefeng Wang, Lorenzo Pieralisi
In-Reply-To: <8d8dec2d75890f3a14632c9606c332fb11d89a95.1712207606.git.ysato@users.sourceforge.jp>
On Thu, 04 Apr 2024 14:14:30 +0900, Yoshinori Sato wrote:
> Renesas SH7751 external interrupt encoder json-schema.
>
> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> ---
> .../renesas,sh7751-irl-ext.yaml | 57 +++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.example.dtb: interrupt-controller@a4000000: #interrupt-cells:0:0: 2 was expected
from schema $id: http://devicetree.org/schemas/interrupt-controller/renesas,sh7751-irl-ext.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/8d8dec2d75890f3a14632c9606c332fb11d89a95.1712207606.git.ysato@users.sourceforge.jp
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH 4/4] clk: en7523: add EN7581 support
From: Lorenzo Bianconi @ 2024-04-04 7:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-clk, mturquette, sboyd, linux-arm-kernel, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nbd, john, devicetree, dd,
catalin.marinas, will, upstream, lorenzo.bianconi83,
angelogioacchino.delregno
In-Reply-To: <95d194ed-86fe-45df-88f1-ae460eb36eaf@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]
> On 03/04/2024 18:20, Lorenzo Bianconi wrote:
> > Introduce EN7581 clock support to clk-en7523 driver.
> >
> > Tested-by: Zhengping Zhang <zhengping.zhang@airoha.com>
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
>
> > + return 0;
> > +}
> > +
> > static int en7523_clk_probe(struct platform_device *pdev)
> > {
> > struct device_node *node = pdev->dev.of_node;
> > @@ -306,6 +413,12 @@ static int en7523_clk_probe(struct platform_device *pdev)
> > if (IS_ERR(np_base))
> > return PTR_ERR(np_base);
> >
> > + if (of_device_is_compatible(node, "airoha,en7581-scu")) {
>
> Having matching and compatible comparisons inside various code is
> discouraged. Does not scale. Use driver/match data to store some sort of
> flags and check for the flag or some other parameter. The best if
> compatible appears once and only once: in of_device_id.
ack, I will fix it.
Regards,
Lorenzo
>
> > + r = en7581_clk_hw_init(pdev, base, np_base);
> > + if (r)
> > + return r;
> > + }
> > +
> > clk_data = devm_kzalloc(&pdev->dev,
> > struct_size(clk_data, hws, EN7523_NUM_CLOCKS),
> > GFP_KERNEL);
> > @@ -329,8 +442,15 @@ static const struct clk_ops en7523_pcie_ops = {
> > .unprepare = en7523_pci_unprepare,
> > };
> >
> > +static const struct clk_ops en7581_pcie_ops = {
> > + .is_enabled = en7581_pci_is_enabled,
> > + .prepare = en7581_pci_prepare,
> > + .unprepare = en7581_pci_unprepare,
> > +};
> > +
> > static const struct of_device_id of_match_clk_en7523[] = {
> > { .compatible = "airoha,en7523-scu", .data = &en7523_pcie_ops },
> > + { .compatible = "airoha,en7581-scu", .data = &en7581_pcie_ops },
> > { /* sentinel */ }
> > };
> >
>
> Best regards,
> Krzysztof
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 2/4] dt-bindings: arm: fsl: remove reduntant toradex,colibri-imx8x
From: Francesco Dolcini @ 2024-04-04 8:02 UTC (permalink / raw)
To: Rob Herring
Cc: Hiago De Franco, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Krzysztof Kozlowski, Conor Dooley, Hiago De Franco,
imx, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20240403165721.GA3980362-robh@kernel.org>
Hello Rob,
On Wed, Apr 03, 2024 at 11:57:21AM -0500, Rob Herring wrote:
> On Tue, Apr 02, 2024 at 04:35:10PM -0300, Hiago De Franco wrote:
> > From: Hiago De Franco <hiago.franco@toradex.com>
> >
> > 'toradex,colibri-imx8x' is already present as a constant value for
> > 'i.MX8QP Board with Toradex Colibri iMX8X Modules', so there is no need
> > to keep it twice as a enum value for 'i.MX8QXP based Boards'.
>
> If the module can operate on its own
For the records, it can't.
> Acked-by: Rob Herring <robh@kernel.org>
Thanks,
Francesco
^ permalink raw reply
* Re: [PATCH 08/23] media: i2c: imx258: Add support for 24MHz clock
From: Sakari Ailus @ 2024-04-04 8:03 UTC (permalink / raw)
To: Luigi311
Cc: git, linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <11f2e7d8-fd4c-4e14-81d8-cbc2cd2442fa@luigi311.com>
Hi Luigi311,
On Thu, Mar 28, 2024 at 11:55:24AM -0600, Luigi311 wrote:
> On 3/28/24 02:09, Sakari Ailus wrote:
> > Hi Luigi311,
> >
> > Thank you for the patchset.
> >
> > On Wed, Mar 27, 2024 at 05:16:54PM -0600, git@luigi311.com wrote:
> >> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
> >>
> >> There's no reason why only a clock of 19.2MHz is supported.
> >> Indeed this isn't even a frequency listed in the datasheet.
> >>
> >> Add support for 24MHz as well.
> >> The PLL settings result in slightly different link frequencies,
> >> so parameterise those.
> >>
> >> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> >> Signed-off-by: Luigi311 <git@luigi311.com>
> >
> > Is Luigi311 your real name? As per
> > Documentation/process/submitting-patches.rst, anonymous (or pseudonym I'd
> > say as well) contributions are not an option.
>
> Luigi311 is not my real name but it would be a lot easier to find me if
> it was. My real name is Luis Garcia which is a super common name so its
> actually way easier to find me and all my work using my online name of
> Luigi311. I can go ahead and swap over to Luis Garcia if required but a
> name like that would provide no value in contacting/finding me since I'm
> not famous like all the other Luis Garcia's that appear on google.
Thanks. E-mail addresses are still unique, presumably, so that helps.
>
> >
> >> ---
> >> drivers/media/i2c/imx258.c | 133 +++++++++++++++++++++++++++++--------
> >> 1 file changed, 107 insertions(+), 26 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> >> index 351add1bc5d5..6ee7de079454 100644
> >> --- a/drivers/media/i2c/imx258.c
> >> +++ b/drivers/media/i2c/imx258.c
> >> @@ -76,9 +76,6 @@
> >> #define REG_CONFIG_MIRROR_FLIP 0x03
> >> #define REG_CONFIG_FLIP_TEST_PATTERN 0x02
> >>
> >> -/* Input clock frequency in Hz */
> >> -#define IMX258_INPUT_CLOCK_FREQ 19200000
> >> -
> >> struct imx258_reg {
> >> u16 address;
> >> u8 val;
> >> @@ -115,7 +112,9 @@ struct imx258_mode {
> >> };
> >>
> >> /* 4208x3120 needs 1267Mbps/lane, 4 lanes */
> >> -static const struct imx258_reg mipi_data_rate_1267mbps[] = {
> >> +static const struct imx258_reg mipi_1267mbps_19_2mhz[] = {
> >> + { 0x0136, 0x13 },
> >> + { 0x0137, 0x33 },
> >> { 0x0301, 0x05 },
> >> { 0x0303, 0x02 },
> >> { 0x0305, 0x03 },
> >> @@ -133,7 +132,29 @@ static const struct imx258_reg mipi_data_rate_1267mbps[] = {
> >> { 0x0823, 0xCC },
> >> };
> >>
> >> -static const struct imx258_reg mipi_data_rate_640mbps[] = {
> >> +static const struct imx258_reg mipi_1272mbps_24mhz[] = {
> >> + { 0x0136, 0x18 },
> >> + { 0x0137, 0x00 },
> >> + { 0x0301, 0x05 },
> >> + { 0x0303, 0x02 },
> >> + { 0x0305, 0x04 },
> >> + { 0x0306, 0x00 },
> >> + { 0x0307, 0xD4 },
> >> + { 0x0309, 0x0A },
> >> + { 0x030B, 0x01 },
> >> + { 0x030D, 0x02 },
> >> + { 0x030E, 0x00 },
> >> + { 0x030F, 0xD8 },
> >> + { 0x0310, 0x00 },
> >> + { 0x0820, 0x13 },
> >> + { 0x0821, 0x4C },
> >> + { 0x0822, 0xCC },
> >> + { 0x0823, 0xCC },
> >> +};
> >> +
> >> +static const struct imx258_reg mipi_640mbps_19_2mhz[] = {
> >> + { 0x0136, 0x13 },
> >> + { 0x0137, 0x33 },
> >> { 0x0301, 0x05 },
> >> { 0x0303, 0x02 },
> >> { 0x0305, 0x03 },
> >> @@ -151,9 +172,27 @@ static const struct imx258_reg mipi_data_rate_640mbps[] = {
> >> { 0x0823, 0x00 },
> >> };
> >>
> >> +static const struct imx258_reg mipi_642mbps_24mhz[] = {
> >> + { 0x0136, 0x18 },
> >> + { 0x0137, 0x00 },
> >> + { 0x0301, 0x05 },
> >> + { 0x0303, 0x02 },
> >> + { 0x0305, 0x04 },
> >> + { 0x0306, 0x00 },
> >> + { 0x0307, 0x6B },
> >> + { 0x0309, 0x0A },
> >> + { 0x030B, 0x01 },
> >> + { 0x030D, 0x02 },
> >> + { 0x030E, 0x00 },
> >> + { 0x030F, 0xD8 },
> >> + { 0x0310, 0x00 },
> >> + { 0x0820, 0x0A },
> >> + { 0x0821, 0x00 },
> >> + { 0x0822, 0x00 },
> >> + { 0x0823, 0x00 },
> >> +};
> >> +
> >> static const struct imx258_reg mode_common_regs[] = {
> >> - { 0x0136, 0x13 },
> >> - { 0x0137, 0x33 },
> >> { 0x3051, 0x00 },
> >> { 0x3052, 0x00 },
> >> { 0x4E21, 0x14 },
> >> @@ -313,10 +352,6 @@ static const char * const imx258_supply_name[] = {
> >>
> >> #define IMX258_NUM_SUPPLIES ARRAY_SIZE(imx258_supply_name)
> >>
> >> -/* Configurations for supported link frequencies */
> >> -#define IMX258_LINK_FREQ_634MHZ 633600000ULL
> >> -#define IMX258_LINK_FREQ_320MHZ 320000000ULL
> >> -
> >> enum {
> >> IMX258_LINK_FREQ_1267MBPS,
> >> IMX258_LINK_FREQ_640MBPS,
> >> @@ -335,25 +370,55 @@ static u64 link_freq_to_pixel_rate(u64 f)
> >> }
> >>
> >> /* Menu items for LINK_FREQ V4L2 control */
> >> -static const s64 link_freq_menu_items[] = {
> >> +/* Configurations for supported link frequencies */
> >> +#define IMX258_LINK_FREQ_634MHZ 633600000ULL
> >> +#define IMX258_LINK_FREQ_320MHZ 320000000ULL
> >> +
> >> +static const s64 link_freq_menu_items_19_2[] = {
> >> IMX258_LINK_FREQ_634MHZ,
> >> IMX258_LINK_FREQ_320MHZ,
> >> };
> >>
> >> +/* Configurations for supported link frequencies */
> >> +#define IMX258_LINK_FREQ_636MHZ 636000000ULL
> >> +#define IMX258_LINK_FREQ_321MHZ 321000000ULL
> >
> > These values aren't used outside the array below and the macro names are
> > imprecise anyway. Could you put the numerical values to the array instead?
>
> Ok I've removed the defines and just threw the values into the array instead.
>
> >
> >> +
> >> +static const s64 link_freq_menu_items_24[] = {
> >> + IMX258_LINK_FREQ_636MHZ,
> >> + IMX258_LINK_FREQ_321MHZ,
> >> +};
> >> +
> >> /* Link frequency configs */
> >> -static const struct imx258_link_freq_config link_freq_configs[] = {
> >> +static const struct imx258_link_freq_config link_freq_configs_19_2[] = {
> >> [IMX258_LINK_FREQ_1267MBPS] = {
> >> .pixels_per_line = IMX258_PPL_DEFAULT,
> >> .reg_list = {
> >> - .num_of_regs = ARRAY_SIZE(mipi_data_rate_1267mbps),
> >> - .regs = mipi_data_rate_1267mbps,
> >> + .num_of_regs = ARRAY_SIZE(mipi_1267mbps_19_2mhz),
> >> + .regs = mipi_1267mbps_19_2mhz,
> >> }
> >> },
> >> [IMX258_LINK_FREQ_640MBPS] = {
> >> .pixels_per_line = IMX258_PPL_DEFAULT,
> >> .reg_list = {
> >> - .num_of_regs = ARRAY_SIZE(mipi_data_rate_640mbps),
> >> - .regs = mipi_data_rate_640mbps,
> >> + .num_of_regs = ARRAY_SIZE(mipi_640mbps_19_2mhz),
> >> + .regs = mipi_640mbps_19_2mhz,
> >> + }
> >> + },
> >> +};
> >> +
> >> +static const struct imx258_link_freq_config link_freq_configs_24[] = {
> >> + [IMX258_LINK_FREQ_1267MBPS] = {
> >> + .pixels_per_line = IMX258_PPL_DEFAULT,
> >> + .reg_list = {
> >> + .num_of_regs = ARRAY_SIZE(mipi_1272mbps_24mhz),
> >> + .regs = mipi_1272mbps_24mhz,
> >> + }
> >> + },
> >> + [IMX258_LINK_FREQ_640MBPS] = {
> >> + .pixels_per_line = IMX258_PPL_DEFAULT,
> >> + .reg_list = {
> >> + .num_of_regs = ARRAY_SIZE(mipi_642mbps_24mhz),
> >> + .regs = mipi_642mbps_24mhz,
> >> }
> >> },
> >> };
> >> @@ -410,6 +475,9 @@ struct imx258 {
> >> /* Current mode */
> >> const struct imx258_mode *cur_mode;
> >>
> >> + const struct imx258_link_freq_config *link_freq_configs;
> >> + const s64 *link_freq_menu_items;
> >> +
> >> /*
> >> * Mutex for serialized access:
> >> * Protect sensor module set pad format and start/stop streaming safely.
> >> @@ -713,7 +781,7 @@ static int imx258_set_pad_format(struct v4l2_subdev *sd,
> >> imx258->cur_mode = mode;
> >> __v4l2_ctrl_s_ctrl(imx258->link_freq, mode->link_freq_index);
> >>
> >> - link_freq = link_freq_menu_items[mode->link_freq_index];
> >> + link_freq = imx258->link_freq_menu_items[mode->link_freq_index];
> >> pixel_rate = link_freq_to_pixel_rate(link_freq);
> >> __v4l2_ctrl_s_ctrl_int64(imx258->pixel_rate, pixel_rate);
> >> /* Update limits and set FPS to default */
> >> @@ -727,7 +795,7 @@ static int imx258_set_pad_format(struct v4l2_subdev *sd,
> >> vblank_def);
> >> __v4l2_ctrl_s_ctrl(imx258->vblank, vblank_def);
> >> h_blank =
> >> - link_freq_configs[mode->link_freq_index].pixels_per_line
> >> + imx258->link_freq_configs[mode->link_freq_index].pixels_per_line
> >> - imx258->cur_mode->width;
> >> __v4l2_ctrl_modify_range(imx258->hblank, h_blank,
> >> h_blank, 1, h_blank);
> >> @@ -747,7 +815,7 @@ static int imx258_start_streaming(struct imx258 *imx258)
> >>
> >> /* Setup PLL */
> >> link_freq_index = imx258->cur_mode->link_freq_index;
> >> - reg_list = &link_freq_configs[link_freq_index].reg_list;
> >> + reg_list = &imx258->link_freq_configs[link_freq_index].reg_list;
> >> ret = imx258_write_regs(imx258, reg_list->regs, reg_list->num_of_regs);
> >> if (ret) {
> >> dev_err(&client->dev, "%s failed to set plls\n", __func__);
> >> @@ -946,9 +1014,9 @@ static int imx258_init_controls(struct imx258 *imx258)
> >> imx258->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr,
> >> &imx258_ctrl_ops,
> >> V4L2_CID_LINK_FREQ,
> >> - ARRAY_SIZE(link_freq_menu_items) - 1,
> >> + ARRAY_SIZE(link_freq_menu_items_19_2) - 1,
> >> 0,
> >> - link_freq_menu_items);
> >> + imx258->link_freq_menu_items);
> >>
> >> if (imx258->link_freq)
> >> imx258->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> >> @@ -964,8 +1032,10 @@ static int imx258_init_controls(struct imx258 *imx258)
> >> if (vflip)
> >> vflip->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> >>
> >> - pixel_rate_max = link_freq_to_pixel_rate(link_freq_menu_items[0]);
> >> - pixel_rate_min = link_freq_to_pixel_rate(link_freq_menu_items[1]);
> >> + pixel_rate_max =
> >> + link_freq_to_pixel_rate(imx258->link_freq_menu_items[0]);
> >> + pixel_rate_min =
> >> + link_freq_to_pixel_rate(imx258->link_freq_menu_items[1]);
> >
> > The arrays currently have two entries so this works but it'd nice to have a
> > bit more robust way to handle differences between the two arrays. Could you
> > maintain e.g. the number of entries in the array in a struct field perhaps?
>
> Would it make more sense to do something like default to index 0 and then use
> ARRAY_SIZE to iterate through the array and do a comparison to get the min and
> max size so it would always choose the correct value no matter how many entries
> there are?
I'll check that later patch you mentioned in the follow-up separately.
--
Kind regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v19 2/9] usb: dwc3: core: Access XHCI address space temporarily to read port info
From: Krzysztof Kozlowski @ 2024-04-04 8:07 UTC (permalink / raw)
To: Johan Hovold, Krishna Kurapati
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp, Johan Hovold
In-Reply-To: <Zg5VDnbaaBXJyRjV@hovoldconsulting.com>
On 04/04/2024 09:21, Johan Hovold wrote:
> On Thu, Apr 04, 2024 at 10:42:22AM +0530, Krishna Kurapati wrote:
>
>> +static int dwc3_get_num_ports(struct dwc3 *dwc)
>> +{
>> + void __iomem *base;
>> + u8 major_revision;
>> + u32 offset;
>> + u32 val;
>> +
>> + /*
>> + * Remap xHCI address space to access XHCI ext cap regs since it is
>> + * needed to get information on number of ports present.
>> + */
>> + base = ioremap(dwc->xhci_resources[0].start,
>> + resource_size(&dwc->xhci_resources[0]));
>> + if (!base)
>> + return PTR_ERR(base);
>
> This is obviously still broken. You need to update the return value as
> well.
>
> Fix in v20.
If one patchset reaches 20 versions, I think it is time to stop and
really think from the beginning, why issues keep appearing and reviewers
are still not happy.
Maybe you did not perform extensive internal review, which you are
encouraged to by your own internal policies, AFAIR. Before posting next
version, please really get some internal review first.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Shreeya Patel @ 2024-04-04 8:07 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Heiko Stübner, mchehab, hverkuil, hverkuil-cisco, robh,
krzysztof.kozlowski+dt, conor+dt, mturquette, sboyd, p.zabel,
shawn.wen, kernel, linux-kernel, linux-media, devicetree,
linux-arm-kernel, linux-rockchip, linux-clk, linux-arm
In-Reply-To: <c790c8ba-a9bd-4820-8084-1294e5e523d9@linaro.org>
On Thursday, April 04, 2024 11:45 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> On 04/04/2024 00:48, Heiko Stübner wrote:
> > Am Mittwoch, 3. April 2024, 13:24:05 CEST schrieb Krzysztof Kozlowski:
> >> On 03/04/2024 13:20, Shreeya Patel wrote:
> >>> On Wednesday, April 03, 2024 15:51 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> >>>
> >>>> On 03/04/2024 11:24, Shreeya Patel wrote:
> >>>>> On Thursday, March 28, 2024 04:20 IST, Shreeya Patel <shreeya.patel@collabora.com> wrote:
> >>>>>
> >>>>>> This series implements support for the Synopsys DesignWare
> >>>>>> HDMI RX Controller, being compliant with standard HDMI 1.4b
> >>>>>> and HDMI 2.0.
> >>>>>>
> >>>>>
> >>>>> Hi Mauro and Hans,
> >>>>>
> >>>>> I haven't received any reviews so far. Hence, this is just a gentle reminder to review this patch series.
> >>>>
> >>>> Why did you put clk changes here? These go via different subsystem. That
> >>>> might be one of obstacles for your patchset.
> >>>>
> >>>
> >>> I added clock changes in this patch series because HDMIRX driver depends on it.
> >>> I thought it is wrong to send the driver patches which don't even compile?
> >>
> >> Hm, why HDMIRX driver depends on clock? How? This sounds really wrong.
> >> Please get it reviewed internally first.
> >
> > For the change in question, the clock controller on the soc also handles
> > the reset controls (hence its name CRU, clock-and-reset-unit) .
> >
> > There are at least 660 reset lines in the unit and it seems the hdmi-rx one
> > was overlooked on the initial submission, hence patches 1+2 add the
> > reset-line.
> >
> > Of course, here only the "arm64: dts:" patch depends on the clock
> > change, is it references the new reset-id.
>
> Wait, that's expected, but it is not what was written. Claim was HDMIRX
> driver depends *build time* ("don't even compile").
>
For some context, when I was testing the downstream driver against the
device tree, I saw some failures because of the missing reset ( which I am trying
to add in the first two patches for this series )
...
hdmirx_dev->rst_biu = devm_reset_control_get(hdmirx_dev->dev, "rst_biu");
if (IS_ERR(hdmirx_dev->rst_biu)) {
dev_err(dev, "failed to get rst_biu control\n");
return PTR_ERR(hdmirx_dev->rst_biu);
}
shreeya@shreeya:~/collabora/rd/rockchip/linux$ make dtbs
DTC arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dtb
Error: arch/arm64/boot/dts/rockchip/rk3588.dtsi:187.23-24 syntax error
FATAL ERROR: Unable to parse input tree
make[3]: *** [scripts/Makefile.lib:419: arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dtb] Error 1
make[2]: *** [scripts/Makefile.build:481: arch/arm64/boot/dts/rockchip] Error 2
make[1]: *** [/home/shreeya/collabora/rd/rockchip/linux/Makefile:1392: dtbs] Error 2
make: *** [Makefile:240: __sub-make] Error 2
Sorry for referring this as a driver build failure but I am sure you would
also have not been okay with the above issues.
Ofcourse I can simply remove this dependency from the driver but maybe
that will affect the functionality and I didn't want to send a buggy patch series.
My intention here was just like Heiko said, to keep all the dependent patches
together. I didn't know that would be a trouble for Maintainers.
FWIW, HDMIRX patch series was reviewed multiple times and that is why you
see a Reviewed-by tag from a Collabora Engineer. Sometimes the things that look
problematic to one might not look the same to others and that is why I asked you
to provide some more details about the problem that you were seeing.
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/merge_requests/21
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/merge_requests/17
> >
> >
> > Am Mittwoch, 3. April 2024, 12:22:57 CEST schrieb Krzysztof Kozlowski:
> >> Please do not engage multiple subsystems in one patchset, if not
> >> necessary. Especially do not mix DTS into media or USB subsystems. And
> >> do not put DTS in the middle!
> >
> > picking up your reply from patch 4/6, there seem to be different "schools
> > of thought" for this. Some maintainers might want to really only see
> > patches that are explicitly for their subsystem - I guess networking
> > might be a prime example for that, who will essentially apply whole series'
> > if nobody protests in time (including dts patches)
>
> There is no school saying DTS is allowed to be in the middle.
>
> Other schools are indeed saying that seeing DTS is good and
> recommendation is to post it separate and provide a link. That's way you
> avoid DTS being pulled by Greg, media or networking.
>
This was my mistake and I simply forgot to remove the DTS when I was
testing the driver for the last time before sending the v3 upstream.
Adding it in the middle was incorrect, I should have added it as a separate
patch but honestly this has always been very confusing and the expectation
differs from maintainers to maintainers.
> >
> > On the other hand I also remember seeing requests for "the full picture"
> > and individual maintainers then just picking and applying the patches
> > meant for their subsystem.
> >
> > The series as it stands right now is nice in that it allows (random)
> > developers to just pick it up, apply it to a tree and test the actual driver
> > without needing to hunt for multiple dependant series.
> >
> >
> > Of course you're right, the "arm64: dts:" patch should be the last in the
> > series and not be in the middle of it.
>
I will make sure to correct this in my v4.
Thanks,
Shreeya Patel
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [PATCH v1 0/3] drm/mediatek: Add support for OF graphs
From: AngeloGioacchino Del Regno @ 2024-04-04 8:16 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
The display IPs in MediaTek SoCs are *VERY* flexible and those support
being interconnected with different instances of DDP IPs (for example,
merge0 or merge1) and/or with different DDP IPs (for example, rdma can
be connected with either color, dpi, dsi, merge, etc), forming a full
Display Data Path that ends with an actual display.
This series was born because of an issue that I've found while enabling
support for MT8195/MT8395 boards with DSI output as main display: the
current mtk_drm_route variations would not work as currently, the driver
hardcodes a display path for Chromebooks, which have a DisplayPort panel
with DSC support, instead of a DSI panel without DSC support.
There are other reasons for which I wrote this series, and I find that
hardcoding those paths - when a HW path is clearly board-specific - is
highly suboptimal. Also, let's not forget about keeping this driver from
becoming a huge list of paths for each combination of SoC->board->disp
and... this and that.
For more information, please look at the commit description for each of
the commits included in this series.
Please don't mind about the missing OVL_ADAPTOR support for OF graphs
in this series: that needs a bit more thinking and a bit more work, and
will come in a second series that will go on top of this a bit later,
as the OF graph support for *at least* the primary display is essential
*right now* to enable support for the MT8195/8395 EVK, Kontron SoM,
Radxa NIO-12L and all of the other non-Chromebook boards to co-exist
with Chromebooks.
Besides, this is also a valid option for MT8188 Chromebooks which might
have different DSI-or-eDP displays depending on the model (as far as I
can see from the mtk_drm_route attempt for this SoC that is already
present in this driver).
This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
NIO-12L with both hardcoded paths, OF graph support and partially
hardcoded paths (meaning main display through OF graph and external
display hardcoded, because of OVL_ADAPTOR).
AngeloGioacchino Del Regno (3):
dt-bindings: display: mediatek: Add OF graph support for board path
dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
drm/mediatek: Implement OF graphs support for display paths
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 ++
.../display/mediatek/mediatek,aal.yaml | 40 +++
.../display/mediatek/mediatek,ccorr.yaml | 21 ++
.../display/mediatek/mediatek,color.yaml | 22 ++
.../display/mediatek/mediatek,dither.yaml | 22 ++
.../display/mediatek/mediatek,dpi.yaml | 25 +-
.../display/mediatek/mediatek,dsc.yaml | 24 ++
.../display/mediatek/mediatek,dsi.yaml | 27 +-
.../display/mediatek/mediatek,ethdr.yaml | 22 ++
.../display/mediatek/mediatek,gamma.yaml | 19 ++
.../display/mediatek/mediatek,merge.yaml | 23 ++
.../display/mediatek/mediatek,od.yaml | 22 ++
.../display/mediatek/mediatek,ovl-2l.yaml | 22 ++
.../display/mediatek/mediatek,ovl.yaml | 22 ++
.../display/mediatek/mediatek,postmask.yaml | 21 ++
.../display/mediatek/mediatek,rdma.yaml | 22 ++
.../display/mediatek/mediatek,ufoe.yaml | 21 ++
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 255 ++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
21 files changed, 645 insertions(+), 36 deletions(-)
--
2.44.0
^ permalink raw reply
* [PATCH v1 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
From: AngeloGioacchino Del Regno @ 2024-04-04 8:16 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
In-Reply-To: <20240404081635.91412-1-angelogioacchino.delregno@collabora.com>
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual display.
The final display pipeline is effectively board specific, as it does
depend on the display that is attached to it, and eventually on the
sensors supported by the board (for example, Adaptive Ambient Light
would need an Ambient Light Sensor, otherwise it's pointless!), other
than the output type.
Add support for OF graphs to most of the MediaTek DDP (display) bindings
to add flexibility to build custom hardware paths, hence enabling board
specific configuration of the display pipeline and allowing to finally
migrate away from using hardcoded paths.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../display/mediatek/mediatek,aal.yaml | 40 +++++++++++++++++++
.../display/mediatek/mediatek,ccorr.yaml | 21 ++++++++++
.../display/mediatek/mediatek,color.yaml | 22 ++++++++++
.../display/mediatek/mediatek,dither.yaml | 22 ++++++++++
.../display/mediatek/mediatek,dpi.yaml | 25 +++++++++++-
.../display/mediatek/mediatek,dsc.yaml | 24 +++++++++++
.../display/mediatek/mediatek,dsi.yaml | 27 ++++++++++++-
.../display/mediatek/mediatek,ethdr.yaml | 22 ++++++++++
.../display/mediatek/mediatek,gamma.yaml | 19 +++++++++
.../display/mediatek/mediatek,merge.yaml | 23 +++++++++++
.../display/mediatek/mediatek,od.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ovl-2l.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ovl.yaml | 22 ++++++++++
.../display/mediatek/mediatek,postmask.yaml | 21 ++++++++++
.../display/mediatek/mediatek,rdma.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ufoe.yaml | 21 ++++++++++
16 files changed, 372 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index b4c28e96dd55..623cf7e37fe3 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -61,6 +61,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: AAL input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ AAL output to the next component's input, for example could be one
+ of many gamma, overdrive or other blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -88,5 +109,24 @@ examples:
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_AAL>;
mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ aal0_in: endpoint {
+ remote-endpoint = <&ccorr0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ aal0_out: endpoint {
+ remote-endpoint = <&gamma0_in>;
+ };
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 8c2a737237f2..71ea277a5d8e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -54,6 +54,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: CCORR input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ CCORR output to the input of the next desired component in the
+ display pipeline, usually only one of the available AAL blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
index b886ca0d89ea..61d040a10c08 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
@@ -64,6 +64,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: COLOR input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ COLOR output to the input of the next desired component in the
+ display pipeline, for example one of the available CCORR or AAL
+ blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
index 1588b3f7cec7..3d4ab3f86294 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
@@ -55,6 +55,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DITHER input, usually from a POSTMASK or GAMMA block.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ DITHER output to the input of the next desired component in the
+ display pipeline, for example one of the available DSC compressors,
+ DP_INTF, DSI, LVDS or others.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index 803c00f26206..6607cb1c6e0a 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -64,13 +64,34 @@ properties:
Output port node. This port should be connected to the input port of an
attached HDMI, LVDS or DisplayPort encoder chip.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DPI input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DPI output to an HDMI, LVDS or DisplayPort encoder input
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- - port
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
additionalProperties: false
@@ -79,7 +100,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/mt8173-clk.h>
- dpi0: dpi@1401d000 {
+ dpi: dpi@1401d000 {
compatible = "mediatek,mt8173-dpi";
reg = <0x1401d000 0x1000>;
interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
index 2cbdd9ee449d..846de6c17d93 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
@@ -49,6 +49,30 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Display Stream Compression input, usually from one of the DITHER
+ or MERGE blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Display Stream Compression output to the input of the next desired
+ component in the display pipeline, for example to MERGE, DP_INTF,
+ DPI or DSI.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
index 8611319bed2e..2e9d3d23cbc1 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
@@ -76,6 +76,26 @@ properties:
Output port node. This port should be connected to the input
port of an attached DSI panel or DSI-to-eDP encoder chip.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input ports can have multiple endpoints, each of those connects
+ to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DSI input port, usually from DITHER, DSC or MERGE
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ DSI output to an attached DSI panel, or a DSI-to-X encoder chip
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -85,7 +105,12 @@ required:
- clock-names
- phys
- phy-names
- - port
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
index 677882348ede..98db47894eeb 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
@@ -110,6 +110,28 @@ properties:
include/dt-bindings/gce/<chip>-gce.h, mapping to the register of display
function block.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: ETHDR input, usually from one of the MERGE blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ ETHDR output to the input of the next desired component in the
+ display pipeline, for example one of the available MERGE blocks,
+ or others.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
index c6641acd75d6..e24287ec364e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -59,6 +59,25 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GAMMA input, usually from one of the AAL blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ GAMMA output to the input of the next desired component in the
+ display pipeline, for example one of the available DITHER or
+ POSTMASK blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
index dae839279950..0de9f64f3f84 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
@@ -77,6 +77,29 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MERGE input port, usually from DITHER, DPI, DSC, DSI, MDP_RDMA,
+ ETHDR or even from a different MERGE block
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MERGE output to a DSC, DPI, DP_INTF, DSI, ETHDR, Write DMA, or
+ a different MERGE block, or others.
+
+ required:
+ - port@0
+ - port@1
+
resets:
description: reset controller
See Documentation/devicetree/bindings/reset/reset.txt for details.
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
index 831c653caffd..71534febd49c 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
@@ -38,6 +38,28 @@ properties:
items:
- description: OD Clock
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OD input port, usually from an AAL block
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OD output to the input of the next desired component in the
+ display pipeline, for example one of the available RDMA or
+ other blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
index c7dd0ef02dcf..bacdfe7d08a6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
@@ -57,6 +57,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OVL input port from MMSYS, VDOSYS or other OVLs
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OVL output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, RDMA
+ or WDMA blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index d53439b94847..0508212a61b4 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -75,6 +75,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OVL input port from MMSYS or one of multiple VDOSYS
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OVL output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, RDMA
+ or WDMA blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
index 11fe32e50a59..fb6fe4742624 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
@@ -52,6 +52,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: POSTMASK input port, usually from GAMMA
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ POSTMASK output to the input of the next desired component in the
+ display pipeline, for example one of the available DITHER blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
index 39dbb5c8bcf8..edb8d3b67025 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
@@ -86,6 +86,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: RDMA input port, usually from MMSYS, OD or OVL
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ RDMA output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, DPI,
+ DSI, MERGE or UFOE blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
index 39e3e2d4a0db..61a5e22effbf 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
@@ -43,6 +43,27 @@ properties:
items:
- description: UFOe Clock
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: UFOE input, usually from one of the RDMA blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ UFOE output to the input of the next desired component in the
+ display pipeline, usually one of the available DSI blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
--
2.44.0
^ permalink raw reply related
* [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
From: AngeloGioacchino Del Regno @ 2024-04-04 8:16 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
In-Reply-To: <20240404081635.91412-1-angelogioacchino.delregno@collabora.com>
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint defines the starting point for one of the (currently three)
possible hardware paths.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index b3c6888c1457..90758bb5bcb1 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -93,6 +93,29 @@ properties:
'#reset-cells':
const: 1
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output port node. This port connects the MMSYS/VDOSYS output to
+ the first component of one display pipeline, for example one of
+ the available OVL or RDMA blocks.
+ Some MediaTek SoCs support up to three display outputs per MMSYS.
+ properties:
+ endpoint@0:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the primary display pipeline
+
+ endpoint@1:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the secondary display pipeline
+
+ endpoint@2:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the tertiary display pipeline
+
+ required:
+ - endpoint@0
+
required:
- compatible
- reg
--
2.44.0
^ permalink raw reply related
* [PATCH v1 3/3] drm/mediatek: Implement OF graphs support for display paths
From: AngeloGioacchino Del Regno @ 2024-04-04 8:16 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
In-Reply-To: <20240404081635.91412-1-angelogioacchino.delregno@collabora.com>
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is anyway not enough for all final routes as the
DSI cannot be connected to MERGE if it's not a dual-DSI, or enabling
DSC preventively doesn't work if the display doesn't support it, or
others.
Since practically all display IPs in MediaTek SoCs support being
interconnected with different instances of other, or the same, IPs
or with different IPs and in different combinations, the final DDP
pipeline is effectively a board specific configuration.
Implement OF graphs support to the mediatek-drm drivers, allowing to
stop hardcoding the paths, and preventing this driver to get a huge
amount of arrays for each board and SoC combination, also paving the
way to share the same mtk_mmsys_driver_data between multiple SoCs,
making it more straightforward to add support for new chips.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 255 ++++++++++++++++++++++---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
4 files changed, 250 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index beb7d9d08e97..c47648d244fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -705,6 +705,15 @@ static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
{
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+ dpi->next_bridge = devm_drm_of_get_bridge(dpi->dev, dpi->dev->of_node, 1, -1);
+ if (IS_ERR(dpi->next_bridge)) {
+ /* Old devicetree has only one endpoint */
+ dpi->next_bridge = devm_drm_of_get_bridge(dpi->dev, dpi->dev->of_node, 0, 0);
+ if (IS_ERR(dpi->next_bridge))
+ return dev_err_probe(dpi->dev, PTR_ERR(dpi->next_bridge),
+ "Failed to get bridge\n");
+ }
+
return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
&dpi->bridge, flags);
}
@@ -1055,13 +1064,6 @@ static int mtk_dpi_probe(struct platform_device *pdev)
if (dpi->irq < 0)
return dpi->irq;
- dpi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
- if (IS_ERR(dpi->next_bridge))
- return dev_err_probe(dev, PTR_ERR(dpi->next_bridge),
- "Failed to get bridge\n");
-
- dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
-
platform_set_drvdata(pdev, dpi);
dpi->bridge.funcs = &mtk_dpi_bridge_funcs;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 2804bf0bc28d..7691aa7779c1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -810,12 +810,200 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ }
};
+static int mtk_drm_of_get_ddp_comp_type(struct device_node *node, enum mtk_ddp_comp_type *ctype)
+{
+ const struct of_device_id *of_id = of_match_node(mtk_ddp_comp_dt_ids, node);
+
+ if (!of_id)
+ return -EINVAL;
+
+ *ctype = (enum mtk_ddp_comp_type)((uintptr_t)of_id->data);
+
+ return 0;
+}
+
+static int mtk_drm_of_get_ddp_ep_cid(struct device_node *node,
+ int output_port, enum mtk_drm_crtc_path crtc_path,
+ struct device_node **next, unsigned int *cid)
+{
+ struct device_node *ep_dev_node, *ep_out;
+ enum mtk_ddp_comp_type comp_type;
+ int ret;
+
+ ep_out = of_graph_get_endpoint_by_regs(node, output_port, crtc_path);
+ if (!ep_out)
+ return -ENOENT;
+
+ ep_dev_node = of_graph_get_remote_port_parent(ep_out);
+ if (!ep_dev_node)
+ return -EINVAL;
+
+ /*
+ * Pass the next node pointer regardless of failures in the later code
+ * so that if this function is called in a loop it will walk through all
+ * of the subsequent endpoints anyway.
+ */
+ *next = ep_dev_node;
+
+ if (!of_device_is_available(ep_dev_node))
+ return -ENODEV;
+
+ ret = mtk_drm_of_get_ddp_comp_type(ep_dev_node, &comp_type);
+ if (ret)
+ return ret;
+
+ ret = mtk_ddp_comp_get_id(ep_dev_node, comp_type);
+ if (ret < 0)
+ return ret;
+
+ /* All ok! Pass the Component ID to the caller. */
+ *cid = (unsigned int)ret;
+
+ return 0;
+}
+
+/**
+ * mtk_drm_of_ddp_path_build_one - Build a Display HW Pipeline for a CRTC Path
+ * @dev: The mediatek-drm device
+ * @cpath: CRTC Path relative to a VDO or MMSYS
+ * @out_path: Pointer to an array that will contain the new pipeline
+ * @out_path_len: Number of entries in the pipeline array
+ *
+ * MediaTek SoCs can use different DDP hardware pipelines (or paths) depending
+ * on the board-specific desired display configuration; this function walks
+ * through all of the output endpoints starting from a VDO or MMSYS hardware
+ * instance and builds the right pipeline as specified in device trees.
+ *
+ * Return:
+ * * %0 - Display HW Pipeline successfully built and validated
+ * * %-ENOENT - Display pipeline was not specified in device tree
+ * * %-EINVAL - Display pipeline built but validation failed
+ * * %-ENOMEM - Failure to allocate pipeline array to pass to the caller
+ */
+static int mtk_drm_of_ddp_path_build_one(struct device *dev, enum mtk_drm_crtc_path cpath,
+ const unsigned int **out_path,
+ unsigned int *out_path_len)
+{
+ struct device_node *next, *prev, *vdo = dev->parent->of_node;
+ unsigned int temp_path[DDP_COMPONENT_DRM_ID_MAX] = { 0 };
+ unsigned int *final_ddp_path;
+ unsigned short int idx = 0;
+ int ret;
+
+ /* Get the first entry for the temp_path array */
+ ret = mtk_drm_of_get_ddp_ep_cid(vdo, 0, cpath, &next, &temp_path[idx++]);
+ if (ret) {
+ if (next)
+ dev_err(dev, "Invalid component %pOF\n", next);
+ else
+ dev_err(dev, "Cannot find first endpoint for path %d\n", cpath);
+
+ return ret;
+ }
+
+ /*
+ * Walk through port outputs until we reach the last valid mediatek-drm component.
+ * To be valid, this must end with an "invalid" component that is a display node.
+ */
+ do {
+ prev = next;
+ ret = mtk_drm_of_get_ddp_ep_cid(next, 1, cpath, &next, &temp_path[idx]);
+ of_node_put(prev);
+ if (ret) {
+ of_node_put(next);
+ break;
+ }
+ } while (++idx < DDP_COMPONENT_DRM_ID_MAX);
+
+ /* If the last entry is not a final display output, the configuration is wrong */
+ switch (temp_path[idx - 1]) {
+ case DDP_COMPONENT_DP_INTF0:
+ case DDP_COMPONENT_DP_INTF1:
+ case DDP_COMPONENT_DPI0:
+ case DDP_COMPONENT_DPI1:
+ case DDP_COMPONENT_DSI0:
+ case DDP_COMPONENT_DSI1:
+ case DDP_COMPONENT_DSI2:
+ case DDP_COMPONENT_DSI3:
+ break;
+ default:
+ dev_err(dev, "Invalid display hw pipeline. Last component: %d (ret=%d)\n",
+ temp_path[idx - 1], ret);
+ return -EINVAL;
+ }
+
+ final_ddp_path = devm_kmemdup(dev, temp_path, idx * sizeof(temp_path[0]), GFP_KERNEL);
+ if (!final_ddp_path)
+ return -ENOMEM;
+
+ dev_dbg(dev, "Display HW Pipeline built with %d components.\n", idx);
+
+ /* Pipeline built! */
+ *out_path = final_ddp_path;
+ *out_path_len = idx;
+
+ return 0;
+}
+
+static int mtk_drm_of_ddp_path_build(struct device *dev, struct device_node *node,
+ struct mtk_mmsys_driver_data *data)
+{
+ struct device_node *ep_node;
+ struct of_endpoint of_ep;
+ bool output_present[MAX_CRTC] = { false };
+ int ret;
+
+ for_each_endpoint_of_node(node, ep_node) {
+ ret = of_graph_parse_endpoint(ep_node, &of_ep);
+ of_node_put(ep_node);
+ if (ret) {
+ dev_err_probe(dev, ret, "Cannot parse endpoint\n");
+ break;
+ }
+
+ if (of_ep.port >= MAX_CRTC) {
+ ret = dev_err_probe(dev, -EINVAL,
+ "Invalid endpoint%u number\n", of_ep.port);
+ break;
+ }
+
+ output_present[of_ep.port] = true;
+ }
+
+ if (ret)
+ return ret;
+
+ if (output_present[CRTC_MAIN]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_MAIN,
+ &data->main_path, &data->main_len);
+ if (ret)
+ return ret;
+ }
+
+ if (output_present[CRTC_EXT]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_EXT,
+ &data->ext_path, &data->ext_len);
+ if (ret)
+ return ret;
+ }
+
+ if (output_present[CRTC_THIRD]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_THIRD,
+ &data->third_path, &data->third_len);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int mtk_drm_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *phandle = dev->parent->of_node;
const struct of_device_id *of_id;
struct mtk_drm_private *private;
+ struct mtk_mmsys_driver_data *mtk_drm_data;
struct device_node *node;
struct component_match *match = NULL;
struct platform_device *ovl_adaptor;
@@ -836,7 +1024,31 @@ static int mtk_drm_probe(struct platform_device *pdev)
if (!of_id)
return -ENODEV;
- private->data = of_id->data;
+ mtk_drm_data = (struct mtk_mmsys_driver_data *)of_id->data;
+ if (!mtk_drm_data)
+ return -EINVAL;
+
+ private->data = kmemdup(mtk_drm_data, sizeof(*mtk_drm_data), GFP_KERNEL);
+ if (!private->data)
+ return -ENOMEM;
+
+ /* Try to build the display pipeline from devicetree graphs */
+ if (of_graph_is_present(phandle)) {
+ dev_dbg(dev, "Building display pipeline for MMSYS %u\n",
+ mtk_drm_data->mmsys_id);
+ private->data = devm_kmemdup(dev, mtk_drm_data,
+ sizeof(*mtk_drm_data), GFP_KERNEL);
+ if (!private->data)
+ return -ENOMEM;
+
+ ret = mtk_drm_of_ddp_path_build(dev, phandle, private->data);
+ if (ret)
+ return ret;
+ } else {
+ /* No devicetree graphs support: go with hardcoded paths if present */
+ dev_dbg(dev, "Using hardcoded paths for MMSYS %u\n", mtk_drm_data->mmsys_id);
+ private->data = mtk_drm_data;
+ };
private->all_drm_private = devm_kmalloc_array(dev, private->data->mmsys_dev_num,
sizeof(*private->all_drm_private),
@@ -858,12 +1070,11 @@ static int mtk_drm_probe(struct platform_device *pdev)
/* Iterate over sibling DISP function blocks */
for_each_child_of_node(phandle->parent, node) {
- const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
- of_id = of_match_node(mtk_ddp_comp_dt_ids, node);
- if (!of_id)
+ ret = mtk_drm_of_get_ddp_comp_type(node, &comp_type);
+ if (ret)
continue;
if (!of_device_is_available(node)) {
@@ -872,8 +1083,6 @@ static int mtk_drm_probe(struct platform_device *pdev)
continue;
}
- comp_type = (enum mtk_ddp_comp_type)(uintptr_t)of_id->data;
-
if (comp_type == MTK_DISP_MUTEX) {
int id;
@@ -902,22 +1111,24 @@ static int mtk_drm_probe(struct platform_device *pdev)
* blocks have separate component platform drivers and initialize their own
* DDP component structure. The others are initialized here.
*/
- if (comp_type == MTK_DISP_AAL ||
- comp_type == MTK_DISP_CCORR ||
- comp_type == MTK_DISP_COLOR ||
- comp_type == MTK_DISP_GAMMA ||
- comp_type == MTK_DISP_MERGE ||
- comp_type == MTK_DISP_OVL ||
- comp_type == MTK_DISP_OVL_2L ||
- comp_type == MTK_DISP_OVL_ADAPTOR ||
- comp_type == MTK_DISP_RDMA ||
- comp_type == MTK_DP_INTF ||
- comp_type == MTK_DPI ||
- comp_type == MTK_DSI) {
- dev_info(dev, "Adding component match for %pOF\n",
- node);
- drm_of_component_match_add(dev, &match, component_compare_of,
- node);
+ switch (comp_type) {
+ default:
+ break;
+ case MTK_DISP_AAL:
+ case MTK_DISP_CCORR:
+ case MTK_DISP_COLOR:
+ case MTK_DISP_GAMMA:
+ case MTK_DISP_MERGE:
+ case MTK_DISP_OVL:
+ case MTK_DISP_OVL_2L:
+ case MTK_DISP_OVL_ADAPTOR:
+ case MTK_DISP_RDMA:
+ case MTK_DP_INTF:
+ case MTK_DPI:
+ case MTK_DSI:
+ dev_info(dev, "Adding component match for %pOF\n", node);
+ drm_of_component_match_add(dev, &match, component_compare_of, node);
+ break;
}
ret = mtk_ddp_comp_init(node, &private->ddp_comp[comp_id], comp_id);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 06bb12243e52..de36328503b9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -75,7 +75,7 @@ struct mtk_drm_private {
struct device *mmsys_dev;
struct device_node *comp_node[DDP_COMPONENT_DRM_ID_MAX];
struct mtk_ddp_comp ddp_comp[DDP_COMPONENT_DRM_ID_MAX];
- const struct mtk_mmsys_driver_data *data;
+ struct mtk_mmsys_driver_data *data;
struct drm_atomic_state *suspend_state;
unsigned int mbox_index;
struct mtk_drm_private **all_drm_private;
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 9501f4019199..1bdbe43e3888 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -903,9 +903,13 @@ static int mtk_dsi_host_attach(struct mipi_dsi_host *host,
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
- if (IS_ERR(dsi->next_bridge))
- return PTR_ERR(dsi->next_bridge);
+ dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
+ if (IS_ERR(dsi->next_bridge)) {
+ /* Old devicetree has only one endpoint */
+ dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
+ if (IS_ERR(dsi->next_bridge))
+ return PTR_ERR(dsi->next_bridge);
+ }
drm_bridge_add(&dsi->bridge);
--
2.44.0
^ permalink raw reply related
* Re: [PATCH v3 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Krzysztof Kozlowski @ 2024-04-04 8:17 UTC (permalink / raw)
To: Shreeya Patel
Cc: Heiko Stübner, mchehab, hverkuil, hverkuil-cisco, robh,
krzysztof.kozlowski+dt, conor+dt, mturquette, sboyd, p.zabel,
shawn.wen, kernel, linux-kernel, linux-media, devicetree,
linux-arm-kernel, linux-rockchip, linux-clk, linux-arm
In-Reply-To: <36bd27-660e6000-3-6c1c1e00@12777057>
On 04/04/2024 10:07, Shreeya Patel wrote:
> On Thursday, April 04, 2024 11:45 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>
>> On 04/04/2024 00:48, Heiko Stübner wrote:
>>> Am Mittwoch, 3. April 2024, 13:24:05 CEST schrieb Krzysztof Kozlowski:
>>>> On 03/04/2024 13:20, Shreeya Patel wrote:
>>>>> On Wednesday, April 03, 2024 15:51 IST, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>>>>>
>>>>>> On 03/04/2024 11:24, Shreeya Patel wrote:
>>>>>>> On Thursday, March 28, 2024 04:20 IST, Shreeya Patel <shreeya.patel@collabora.com> wrote:
>>>>>>>
>>>>>>>> This series implements support for the Synopsys DesignWare
>>>>>>>> HDMI RX Controller, being compliant with standard HDMI 1.4b
>>>>>>>> and HDMI 2.0.
>>>>>>>>
>>>>>>>
>>>>>>> Hi Mauro and Hans,
>>>>>>>
>>>>>>> I haven't received any reviews so far. Hence, this is just a gentle reminder to review this patch series.
>>>>>>
>>>>>> Why did you put clk changes here? These go via different subsystem. That
>>>>>> might be one of obstacles for your patchset.
>>>>>>
>>>>>
>>>>> I added clock changes in this patch series because HDMIRX driver depends on it.
>>>>> I thought it is wrong to send the driver patches which don't even compile?
>>>>
>>>> Hm, why HDMIRX driver depends on clock? How? This sounds really wrong.
>>>> Please get it reviewed internally first.
>>>
>>> For the change in question, the clock controller on the soc also handles
>>> the reset controls (hence its name CRU, clock-and-reset-unit) .
>>>
>>> There are at least 660 reset lines in the unit and it seems the hdmi-rx one
>>> was overlooked on the initial submission, hence patches 1+2 add the
>>> reset-line.
>>>
>>> Of course, here only the "arm64: dts:" patch depends on the clock
>>> change, is it references the new reset-id.
>>
>> Wait, that's expected, but it is not what was written. Claim was HDMIRX
>> driver depends *build time* ("don't even compile").
>>
>
> For some context, when I was testing the downstream driver against the
> device tree, I saw some failures because of the missing reset ( which I am trying
> to add in the first two patches for this series )
>
> ...
> hdmirx_dev->rst_biu = devm_reset_control_get(hdmirx_dev->dev, "rst_biu");
> if (IS_ERR(hdmirx_dev->rst_biu)) {
> dev_err(dev, "failed to get rst_biu control\n");
> return PTR_ERR(hdmirx_dev->rst_biu);
> }
That's a driver....
> shreeya@shreeya:~/collabora/rd/rockchip/linux$ make dtbs
> DTC arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dtb
and that's a DTS.
> Error: arch/arm64/boot/dts/rockchip/rk3588.dtsi:187.23-24 syntax error
> FATAL ERROR: Unable to parse input tree
> make[3]: *** [scripts/Makefile.lib:419: arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dtb] Error 1
> make[2]: *** [scripts/Makefile.build:481: arch/arm64/boot/dts/rockchip] Error 2
> make[1]: *** [/home/shreeya/collabora/rd/rockchip/linux/Makefile:1392: dtbs] Error 2
> make: *** [Makefile:240: __sub-make] Error 2
They are not related anyhow. Look above which Makefile target produced
error. Which file failed to build. This is a expressed in make[3] line.
Directory is expressed in other places.
>
> Sorry for referring this as a driver build failure but I am sure you would
> also have not been okay with the above issues.
> Ofcourse I can simply remove this dependency from the driver but maybe
> that will affect the functionality and I didn't want to send a buggy patch series.
What dependency?
It seems you did not understand anything from Heiko's message, so please
reach to your colleagues for explanation where is the dependency.
>
> My intention here was just like Heiko said, to keep all the dependent patches
> together. I didn't know that would be a trouble for Maintainers.
They are not dependent.
>
> FWIW, HDMIRX patch series was reviewed multiple times and that is why you
> see a Reviewed-by tag from a Collabora Engineer. Sometimes the things that look
> problematic to one might not look the same to others and that is why I asked you
> to provide some more details about the problem that you were seeing.
>
> https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/merge_requests/21
> https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/merge_requests/17
Sorry, that's some third party gitlab... I don't know what does it prove.
>
>
>>>
>>>
>>> Am Mittwoch, 3. April 2024, 12:22:57 CEST schrieb Krzysztof Kozlowski:
>>>> Please do not engage multiple subsystems in one patchset, if not
>>>> necessary. Especially do not mix DTS into media or USB subsystems. And
>>>> do not put DTS in the middle!
>>>
>>> picking up your reply from patch 4/6, there seem to be different "schools
>>> of thought" for this. Some maintainers might want to really only see
>>> patches that are explicitly for their subsystem - I guess networking
>>> might be a prime example for that, who will essentially apply whole series'
>>> if nobody protests in time (including dts patches)
>>
>> There is no school saying DTS is allowed to be in the middle.
>>
>> Other schools are indeed saying that seeing DTS is good and
>> recommendation is to post it separate and provide a link. That's way you
>> avoid DTS being pulled by Greg, media or networking.
>>
>
> This was my mistake and I simply forgot to remove the DTS when I was
> testing the driver for the last time before sending the v3 upstream.
> Adding it in the middle was incorrect, I should have added it as a separate
> patch but honestly this has always been very confusing and the expectation
> differs from maintainers to maintainers.
There were guidelines - presented in the conferences, mailing list and
even SoC maintainer profile explains how patches eventually end up. I
agree that it still might be confusing, but these are the basics of
submitting patches to anything touching SoC. Anyone working with SoC
will need to know them, so how about Collabora creates some internal
guideline explaining this, so such confusions could be avoided?
I know that such guidelines exist in other companies...
Best regards,
Krzysztof
^ 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