* Re: [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
From: Alexandre Torgue @ 2020-05-14 12:52 UTC (permalink / raw)
To: Linus Walleij, dillon.minfei
Cc: Rob Herring, Maxime Coquelin, thierry.reding@gmail.com,
Sam Ravnborg, Dave Airlie, Daniel Vetter, Michael Turquette,
Stephen Boyd,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-stm32, Linux ARM, linux-kernel@vger.kernel.org,
open list:DRM PANEL DRIVERS, linux-clk
In-Reply-To: <CACRpkda5VjjBdbruXTi33QBNb=VU6vK2zDE8yyQXoWw7=NQFeg@mail.gmail.com>
On 5/14/20 10:24 AM, Linus Walleij wrote:
> On Tue, May 12, 2020 at 9:04 AM <dillon.minfei@gmail.com> wrote:
>
>> From: dillon min <dillon.minfei@gmail.com>
>>
>> Enable the ltdc & ili9341 on stm32429-disco board.
>>
>> Signed-off-by: dillon min <dillon.minfei@gmail.com>
>
> This mostly looks good but...
>
>> +&spi5 {
>> + status = "okay";
>> + pinctrl-0 = <&spi5_pins>;
>> + pinctrl-names = "default";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + cs-gpios = <&gpioc 2 GPIO_ACTIVE_LOW>;
>> + dmas = <&dma2 3 2 0x400 0x0>,
>> + <&dma2 4 2 0x400 0x0>;
>> + dma-names = "rx", "tx";
>
> These DMA assignments seem to be SoC things and should
> rather be in the DTS(I) file where &spi5 is defined, right?
> stm32f429.dtsi I suppose?
I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
doesn't want to use it, we use the "delete-property".
>
> It is likely the same no matter which device is using spi5.
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* Re: [PATCH v9 2/4] media: i2c: Add MAX9286 driver
From: Manivannan Sadhasivam @ 2020-05-14 12:54 UTC (permalink / raw)
To: Kieran Bingham, y
Cc: kieran.bingham+renesas, linux-renesas-soc, linux-media,
devicetree, linux-kernel, Mauro Carvalho Chehab, Laurent Pinchart,
Jacopo Mondi, Niklas Söderlund, sakari.ailus, Hans Verkuil,
Hyun Kwon, Rob Herring, Jacopo Mondi, Laurent Pinchart,
Niklas Söderlund
In-Reply-To: <d4d0e298-b863-8c6e-c9d7-ba861a98359e@ideasonboard.com>
On Thu, May 14, 2020 at 01:27:01PM +0100, Kieran Bingham wrote:
> Hi Mani,
>
> On 14/05/2020 12:47, Kieran Bingham wrote:
> > On 14/05/2020 11:13, Manivannan Sadhasivam wrote:
> >> Hi Kieran,
> <snip>
>
> >>>>> +static int max9286_parse_dt(struct max9286_priv *priv)
> >>>>> +{
> >>>>> + struct device *dev = &priv->client->dev;
> >>>>> + struct device_node *i2c_mux;
> >>>>> + struct device_node *node = NULL;
> >>>>> + unsigned int i2c_mux_mask = 0;
> >>>>> +
> >>>>> + of_node_get(dev->of_node);
> >>>>
> >>>> Why this is needed?
> >>>
> >>> Hrm .. I recall adding it to solve dt reference balancing.
> >>>
> >>> I wish I'd added a comment at the time ... as I can't recall the details
> >>> now.
> >>>
> >>
> >> I understand that it is for the refcount balancing but I certainly don't see
> >> a need for it.
> >
> > I'll go through and try to validate this again now.
>
> Aha, that's why:
>
> * of_find_node_by_name - Find a node by its "name" property
> * @from: The node to start searching from or NULL; the node
> * you pass will not be searched, only the next one
> * will. Typically, you pass what the previous call
> * returned. of_node_put() will be called on @from.
> * @name: The name string to match against
>
> I'll add a comment to state that it is to balance the of_node_put during
> of_find_node_by_name().
>
Ah, right. I mostly use of_find_node_by_name() with NULL, so didn't realize
this.
And yeah, a comment would be helpful.
Thanks,
Mani
> --
> Kieran
>
>
> >>>>> + i2c_mux = of_find_node_by_name(dev->of_node, "i2c-mux");
> >>>>> + if (!i2c_mux) {
> >>>>> + dev_err(dev, "Failed to find i2c-mux node\n");
> >>>>> + of_node_put(dev->of_node);
> >>>>> + return -EINVAL;
> >>>>> + }
> >>>>> +
> >> [...]
> >>>>
> --
> Regards
> --
> Kieran
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Rob Herring @ 2020-05-14 12:57 UTC (permalink / raw)
To: Ramuthevar,Vadivel MuruganX
Cc: masonccyang, linux-mtd, richard, boris.brezillon, brendanhiggins,
tglx, miquel.raynal, vigneshr, hauke.mehrtens, devicetree,
anders.roxell, arnd, robh+dt, andriy.shevchenko, linux-mips,
cheol.yong.kim, linux-kernel, qi-ming.wu
In-Reply-To: <20200513104615.7905-2-vadivel.muruganx.ramuthevar@linux.intel.com>
On Wed, 13 May 2020 18:46:14 +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>
> Add YAML file for dt-bindings to support NAND Flash Controller
> on Intel's Lightning Mountain SoC.
>
> Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> ---
> .../devicetree/bindings/mtd/intel,lgm-nand.yaml | 83 ++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/intel,lgm-nand.example.dt.yaml: nand-controller@e0f00000: 'dmas' is a dependency of 'dma-names'
See https://patchwork.ozlabs.org/patch/1289160
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH 11/17] spi: dw: Fix native CS being unset
From: Mark Brown @ 2020-05-14 13:03 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Linus Walleij, Serge Semin, Gregory Clement,
Charles Keepax, Georgy Vlasov, Ramil Zaripov, Alexey Malahov,
Thomas Bogendoerfer, Paul Burton, Ralf Baechle, Arnd Bergmann,
Allison Randal, Gareth Williams, Rob Herring, linux-mips,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Phil Edworthy, Thomas Gleixner, Alexios Zavras, Thor Thayer,
wuxu.wu, Xinwei Kong, Jarkko Nikula, linux-spi,
linux-kernel@vger.kernel.org
In-Reply-To: <20200514122214.GC185537@smile.fi.intel.com>
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]
On Thu, May 14, 2020 at 03:22:14PM +0300, Andy Shevchenko wrote:
> On Thu, May 14, 2020 at 02:55:58PM +0300, Serge Semin wrote:
> > BTW I experience a problem with vger.kernel.org. For some reason a few days ago
> > it started bouncing my emails back sent to the GPIO/MIPS/SPI/kernel mailing lists.
> > I've sent multiple backward messages to the postmaster (postmaster (dog) vger.kernel.org)
> > with the bounce text, but still with no response. Could you tell me who should I
> > bother with this problem to get a help with its solution?
> Perhaps, helpdesk@kernel.org ?
vger is completely separate to kernel.org in terms of admin. Usually
the bounce messages from vger say why things are being bounced, there's
a good chance that either mail to you is bouncing and Dave got annoyed
with you and is trying to get your attention or something you're doing
is looking like spam.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: mtd: Add Nand Flash Controller support for Intel LGM SoC
From: Rob Herring @ 2020-05-14 13:03 UTC (permalink / raw)
To: Ramuthevar,Vadivel MuruganX
Cc: linux-kernel, linux-mtd, devicetree, miquel.raynal, richard,
vigneshr, arnd, brendanhiggins, tglx, boris.brezillon,
anders.roxell, masonccyang, linux-mips, hauke.mehrtens,
andriy.shevchenko, qi-ming.wu, cheol.yong.kim
In-Reply-To: <20200513104615.7905-2-vadivel.muruganx.ramuthevar@linux.intel.com>
On Wed, May 13, 2020 at 06:46:14PM +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>
> Add YAML file for dt-bindings to support NAND Flash Controller
> on Intel's Lightning Mountain SoC.
>
> Signed-off-by: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> ---
> .../devicetree/bindings/mtd/intel,lgm-nand.yaml | 83 ++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
>
> diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
> new file mode 100644
> index 000000000000..d9e0df8553fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/intel,lgm-nand.yaml
> @@ -0,0 +1,83 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings please:
(GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/intel,lgm-nand.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Intel LGM SoC NAND Controller Device Tree Bindings
> +
> +allOf:
> + - $ref: "nand-controller.yaml"
> +
> +maintainers:
> + - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
> +
> +properties:
> + compatible:
> + const: intel,lgm-nand-controller
> +
> + reg:
> + maxItems: 1
Looks like you have 4 or 6 entries, not 1. Need to define what each one
is.
> +
> + clocks:
> + maxItems: 1
> +
> + dmas:
> + maxItems: 2
> +
> + dma-names:
> + enum:
> + - rx
> + - tx
This defines a single entry. I believe you want:
items:
- const: tx
- const: rx
> +
> + pinctrl-names: true
No need for this. Tools add pinctrl properties.
> +
> +patternProperties:
> + "^nand@[a-f0-9]+$":
> + type: object
> + properties:
> + reg:
> + minimum: 0
> + maximum: 7
> +
> + nand-ecc-mode: true
> +
> + nand-ecc-algo:
> + const: hw
> +
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - dmas
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + nand-controller@e0f00000 {
> + compatible = "intel,nand-controller";
Doesn't match the schema.
> + reg = <0xe0f00000 0x100>,
> + <0xe1000000 0x300>,
> + <0xe1400000 0x8000>,
> + <0xe1c00000 0x1000>;
Is it 4 or 6 entries?
> + reg-names = "ebunand", "hsnand", "nand_cs0", "nand_cs1",
> + "addr_sel0","addr_sel1";
Not documented.
> + clocks = <&cgu0 125>;
> + dma-names = "tx", "rx";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #clock-cells = <1>;
This is a clock provider too?
> +
> + nand@0 {
> + reg = <0>;
> + nand-on-flash-bbt;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> + };
> +
> +...
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mmc: Add Sparx5 SDHCI controller bindings
From: Rob Herring @ 2020-05-14 13:03 UTC (permalink / raw)
To: Lars Povlsen
Cc: Alexandre Belloni, linux-arm-kernel, SoC Team, linux-mmc,
Ulf Hansson, linux-kernel, Microchip Linux Driver Support,
devicetree, Adrian Hunter, Rob Herring
In-Reply-To: <20200513133122.25121-2-lars.povlsen@microchip.com>
On Wed, 13 May 2020 15:31:20 +0200, Lars Povlsen wrote:
> The Sparx5 SDHCI controller is based on the Designware controller IP.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> .../mmc/microchip,dw-sparx5-sdhci.yaml | 57 +++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.example.dts:20:18: fatal error: dt-bindings/clock/microchip,sparx5.h: No such file or directory
#include <dt-bindings/clock/microchip,sparx5.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
scripts/Makefile.lib:312: recipe for target 'Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.example.dt.yaml' failed
make[1]: *** [Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:1300: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1289290
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH 01/10] spi: dw: Add support for polled operation via no IRQ specified in DT
From: Serge Semin @ 2020-05-14 13:04 UTC (permalink / raw)
To: Mark Brown
Cc: Serge Semin, Lars Povlsen, SoC Team,
Microchip Linux Driver Support, linux-spi, devicetree,
linux-kernel, linux-arm-kernel, Alexandre Belloni,
Andy Shevchenko
In-Reply-To: <20200513142050.GH4803@sirena.org.uk>
Hi Mark
On Wed, May 13, 2020 at 03:20:50PM +0100, Mark Brown wrote:
> On Wed, May 13, 2020 at 04:00:22PM +0200, Lars Povlsen wrote:
> > With this change a SPI controller can be added without having a IRQ
> > associated, and causing all transfers to be polled. For SPI controllers
> > without DMA, this can significantly improve performance by less
> > interrupt handling overhead.
>
> This overlaps substantially with some work that Serge Semin (CCed) has
> in progress, please coordinate with him.
Thanks for copying me these mails. I haven't been Cc'ed in the series and
hasn't been subscribed to the SPI mailing list, so I would have definitely
missed that.
I would like to coordinate my efforts with Lars. I'll have the patchset reviewed
soon in addition providing my comments/suggestions of how to make it useful for
both mine and Lars solution.
One thing I can tell about the mem_ops he implemented, is that they aren't
mem_ops, but dirmap (as you remember it's also implemented in my code, but with
alignment specific), and the exec_mem_op partly consists of a code, which belong
to the supports_op() callback. The rest of my comments will be inlined in the
patches.
-Sergey
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: pinctrl: realtek: Add Realtek DHC SoC rtd1195 and rtd1295.
From: Rob Herring @ 2020-05-14 13:08 UTC (permalink / raw)
To: TY Chang
Cc: robh+dt, afaerber, devicetree, linux-kernel, linus.walleij,
linux-realtek-soc, linux-gpio
In-Reply-To: <20200514092125.6875-5-tychang@realtek.com>
On Thu, 14 May 2020 17:21:22 +0800, TY Chang wrote:
> Add compatible string for RTD1195 and RTD1295.
>
> Signed-off-by: TY Chang <tychang@realtek.com>
> ---
> .../bindings/pinctrl/realtek,rtd-pinctrl.yaml | 59 +++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/realtek,rtd-pinctrl.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
Error: Documentation/devicetree/bindings/pinctrl/realtek,rtd-pinctrl.example.dts:24.5-6 syntax error
FATAL ERROR: Unable to parse input tree
scripts/Makefile.lib:312: recipe for target 'Documentation/devicetree/bindings/pinctrl/realtek,rtd-pinctrl.example.dt.yaml' failed
make[1]: *** [Documentation/devicetree/bindings/pinctrl/realtek,rtd-pinctrl.example.dt.yaml] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:1300: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1290046
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH v3 3/5] ARM: dts: stm32: enable ltdc binding with ili9341 on stm32429-disco board
From: dillon min @ 2020-05-14 13:07 UTC (permalink / raw)
To: Alexandre Torgue
Cc: Linus Walleij, Rob Herring, Maxime Coquelin,
thierry.reding@gmail.com, Sam Ravnborg, Dave Airlie,
Daniel Vetter, Michael Turquette, Stephen Boyd,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-stm32, Linux ARM, linux-kernel@vger.kernel.org,
open list:DRM PANEL DRIVERS, linux-clk
In-Reply-To: <a4ebd7cd-5756-0683-135f-0f96be8a4a7b@st.com>
Hi Alexandre,
On Thu, May 14, 2020 at 8:53 PM Alexandre Torgue
<alexandre.torgue@st.com> wrote:
>
>
>
> On 5/14/20 10:24 AM, Linus Walleij wrote:
> > On Tue, May 12, 2020 at 9:04 AM <dillon.minfei@gmail.com> wrote:
> >
> >> From: dillon min <dillon.minfei@gmail.com>
> >>
> >> Enable the ltdc & ili9341 on stm32429-disco board.
> >>
> >> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> >
> > This mostly looks good but...
> >
> >> +&spi5 {
> >> + status = "okay";
> >> + pinctrl-0 = <&spi5_pins>;
> >> + pinctrl-names = "default";
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + cs-gpios = <&gpioc 2 GPIO_ACTIVE_LOW>;
> >> + dmas = <&dma2 3 2 0x400 0x0>,
> >> + <&dma2 4 2 0x400 0x0>;
> >> + dma-names = "rx", "tx";
> >
> > These DMA assignments seem to be SoC things and should
> > rather be in the DTS(I) file where &spi5 is defined, right?
> > stm32f429.dtsi I suppose?
>
> I agree with Linus, DMA have to be defined in SoC dtsi. And if a board
> doesn't want to use it, we use the "delete-property".
Yes, will move to Soc dtsi in next submits.
i'm working on write a v4l2-m2m driver for dma2d of stm32 to support
pixel conversion
alpha blending between foreground and background graphics.
as you know, some soc's engineer trying to add this function to drm system.
do you know st's planning about soc's hardware accelerator driver on stm32mp?
such as chrom-art, will add to drm subsystem via ioctl to access, or to v4l2,
thanks.
>
> >
> > It is likely the same no matter which device is using spi5.
> >
> > Yours,
> > Linus Walleij
> >
^ permalink raw reply
* Re: [PATCH v4 0/5] iommu: Add Allwinner H6 IOMMU driver
From: Maxime Ripard @ 2020-05-14 13:09 UTC (permalink / raw)
To: Joerg Roedel
Cc: Chen-Yu Tsai, Mark Rutland, Rob Herring, Frank Rowand, devicetree,
linux-arm-kernel, iommu
In-Reply-To: <20200514123855.GI18353@8bytes.org>
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]
On Thu, May 14, 2020 at 02:38:55PM +0200, Joerg Roedel wrote:
> On Wed, May 13, 2020 at 04:07:19PM +0200, Maxime Ripard wrote:
> > Maxime Ripard (5):
> > dt-bindings: iommu: Add Allwinner H6 IOMMU bindings
> > dt-bindings: display: sun8i-mixer: Allow for an iommu property
> > iommu: Add Allwinner H6 IOMMU driver
> > arm64: dts: allwinner: h6: Add IOMMU
> > drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
>
> Applied all to the IOMMU tree, thanks. The code lives in the
> arm/allwinner branch.
Did you also merge the DTS and DRM patches?
Ideally, they should be merged through other trees to avoid the conflicts as
much as possible (arm-soc and drm-misc respectively).
If it's an option, could you drop all of them but "dt-bindings: iommu: Add
Allwinner H6 IOMMU bindings" and "iommu: Add Allwinner H6 IOMMU driver"?
> Please use 'iommu/sun50i: <Capital Letter>...' as the pattern for your future
> subject lines when changing the driver.
I'll try to remember that, thanks! :)
> I also have two fixes on-top which I will send out shortly and add to
> that branch.
Ugh. I'm not sure how the first one slipped through.. Sorry for that, I'm fine
with both.
Thanks!
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2 1/2] MAINTAINERS: add maintainer for mediatek i2c controller driver
From: Qii Wang @ 2020-05-14 13:09 UTC (permalink / raw)
To: wsa
Cc: linux-i2c, devicetree, linux-arm-kernel, linux-kernel,
linux-mediatek, srv_heupstream, leilk.liu, qii.wang
In-Reply-To: <1589461844-15614-1-git-send-email-qii.wang@mediatek.com>
Add Qii Wang as maintainer for mediatek i2c controller driver.
Signed-off-by: Qii Wang <qii.wang@mediatek.com>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db..c0fdf11 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10658,6 +10658,13 @@ L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/mediatek/
+MEDIATEK I2C CONTROLLER DRIVER
+M: Qii Wang <qii.wang@mediatek.com>
+L: linux-i2c@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt
+F: drivers/i2c/busses/i2c-mt65xx.c
+
MEDIATEK JPEG DRIVER
M: Rick Chang <rick.chang@mediatek.com>
M: Bin Liu <bin.liu@mediatek.com>
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/2] Add i2c ac-timing adjust support
From: Qii Wang @ 2020-05-14 13:09 UTC (permalink / raw)
To: wsa
Cc: linux-i2c, devicetree, linux-arm-kernel, linux-kernel,
linux-mediatek, srv_heupstream, leilk.liu, qii.wang
This series are based on 5.7-rc1, we provide two patches to support i2c ac-timing.
Main changes compared to v1:
--add maintainer for mediatek i2c controller driver
--fix warning of self-assignment
Qii Wang (2):
MAINTAINERS: add maintainer for mediatek i2c controller driver
i2c: mediatek: Add i2c ac-timing adjust support
MAINTAINERS | 7 +
drivers/i2c/busses/i2c-mt65xx.c | 328 +++++++++++++++++++++++++++++++++-------
2 files changed, 284 insertions(+), 51 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2 2/2] i2c: mediatek: Add i2c ac-timing adjust support
From: Qii Wang @ 2020-05-14 13:09 UTC (permalink / raw)
To: wsa
Cc: linux-i2c, devicetree, linux-arm-kernel, linux-kernel,
linux-mediatek, srv_heupstream, leilk.liu, qii.wang
In-Reply-To: <1589461844-15614-1-git-send-email-qii.wang@mediatek.com>
This patch adds a algorithm to calculate some ac-timing parameters
which can fully meet I2C Spec.
Signed-off-by: Qii Wang <qii.wang@mediatek.com>
---
drivers/i2c/busses/i2c-mt65xx.c | 328 +++++++++++++++++++++++++++++++++-------
1 file changed, 277 insertions(+), 51 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 0ca6c38a..7020618 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -40,12 +40,11 @@
#define I2C_SOFT_RST 0x0001
#define I2C_FIFO_ADDR_CLR 0x0001
#define I2C_DELAY_LEN 0x0002
-#define I2C_ST_START_CON 0x8001
-#define I2C_FS_START_CON 0x1800
#define I2C_TIME_CLR_VALUE 0x0000
#define I2C_TIME_DEFAULT_VALUE 0x0003
#define I2C_WRRD_TRANAC_VALUE 0x0002
#define I2C_RD_TRANAC_VALUE 0x0001
+#define I2C_SCL_MIS_COMP_VALUE 0x0000
#define I2C_DMA_CON_TX 0x0000
#define I2C_DMA_CON_RX 0x0001
@@ -55,10 +54,13 @@
#define I2C_DMA_HARD_RST 0x0002
#define I2C_DMA_4G_MODE 0x0001
-#define I2C_DEFAULT_CLK_DIV 5
#define MAX_SAMPLE_CNT_DIV 8
#define MAX_STEP_CNT_DIV 64
+#define MAX_CLOCK_DIV 256
#define MAX_HS_STEP_CNT_DIV 8
+#define I2C_STANDARD_MODE_BUFFER (1000 / 2)
+#define I2C_FAST_MODE_BUFFER (300 / 2)
+#define I2C_FAST_MODE_PLUS_BUFFER (20 / 2)
#define I2C_CONTROL_RS (0x1 << 1)
#define I2C_CONTROL_DMA_EN (0x1 << 2)
@@ -123,6 +125,12 @@ enum I2C_REGS_OFFSET {
OFFSET_TRANSFER_LEN_AUX,
OFFSET_CLOCK_DIV,
OFFSET_LTIMING,
+ OFFSET_SCL_HIGH_LOW_RATIO,
+ OFFSET_HS_SCL_HIGH_LOW_RATIO,
+ OFFSET_SCL_MIS_COMP_POINT,
+ OFFSET_STA_STO_AC_TIMING,
+ OFFSET_HS_STA_STO_AC_TIMING,
+ OFFSET_SDA_TIMING,
};
static const u16 mt_i2c_regs_v1[] = {
@@ -150,6 +158,12 @@ enum I2C_REGS_OFFSET {
[OFFSET_DEBUGCTRL] = 0x68,
[OFFSET_TRANSFER_LEN_AUX] = 0x6c,
[OFFSET_CLOCK_DIV] = 0x70,
+ [OFFSET_SCL_HIGH_LOW_RATIO] = 0x74,
+ [OFFSET_HS_SCL_HIGH_LOW_RATIO] = 0x78,
+ [OFFSET_SCL_MIS_COMP_POINT] = 0x7C,
+ [OFFSET_STA_STO_AC_TIMING] = 0x80,
+ [OFFSET_HS_STA_STO_AC_TIMING] = 0x84,
+ [OFFSET_SDA_TIMING] = 0x88,
};
static const u16 mt_i2c_regs_v2[] = {
@@ -168,9 +182,11 @@ enum I2C_REGS_OFFSET {
[OFFSET_HS] = 0x30,
[OFFSET_IO_CONFIG] = 0x34,
[OFFSET_FIFO_ADDR_CLR] = 0x38,
+ [OFFSET_SDA_TIMING] = 0x3c,
[OFFSET_TRANSFER_LEN_AUX] = 0x44,
[OFFSET_CLOCK_DIV] = 0x48,
[OFFSET_SOFTRESET] = 0x50,
+ [OFFSET_SCL_MIS_COMP_POINT] = 0x90,
[OFFSET_DEBUGSTAT] = 0xe0,
[OFFSET_DEBUGCTRL] = 0xe8,
[OFFSET_FIFO_STAT] = 0xf4,
@@ -191,6 +207,19 @@ struct mtk_i2c_compatible {
unsigned char ltiming_adjust: 1;
};
+struct mtk_i2c_ac_timing {
+ u16 htiming;
+ u16 ltiming;
+ u16 hs;
+ u16 ext;
+ u16 inter_clk_div;
+ u16 scl_hl_ratio;
+ u16 hs_scl_hl_ratio;
+ u16 sta_stop;
+ u16 hs_sta_stop;
+ u16 sda_timing;
+};
+
struct mtk_i2c {
struct i2c_adapter adap; /* i2c host adapter */
struct device *dev;
@@ -215,9 +244,46 @@ struct mtk_i2c {
u16 ltiming_reg;
unsigned char auto_restart;
bool ignore_restart_irq;
+ struct mtk_i2c_ac_timing ac_timing;
const struct mtk_i2c_compatible *dev_comp;
};
+/**
+ * struct i2c_spec_values:
+ * min_low_ns: min LOW period of the SCL clock
+ * min_su_sta_ns: min set-up time for a repeated START condition
+ * max_hd_dat_ns: max data hold time
+ * min_su_dat_ns: min data set-up time
+ */
+struct i2c_spec_values {
+ unsigned int min_low_ns;
+ unsigned int min_high_ns;
+ unsigned int min_su_sta_ns;
+ unsigned int max_hd_dat_ns;
+ unsigned int min_su_dat_ns;
+};
+
+static const struct i2c_spec_values standard_mode_spec = {
+ .min_low_ns = 4700 + I2C_STANDARD_MODE_BUFFER,
+ .min_su_sta_ns = 4700 + I2C_STANDARD_MODE_BUFFER,
+ .max_hd_dat_ns = 3450 - I2C_STANDARD_MODE_BUFFER,
+ .min_su_dat_ns = 250 + I2C_STANDARD_MODE_BUFFER,
+};
+
+static const struct i2c_spec_values fast_mode_spec = {
+ .min_low_ns = 1300 + I2C_FAST_MODE_BUFFER,
+ .min_su_sta_ns = 600 + I2C_FAST_MODE_BUFFER,
+ .max_hd_dat_ns = 900 - I2C_FAST_MODE_BUFFER,
+ .min_su_dat_ns = 100 + I2C_FAST_MODE_BUFFER,
+};
+
+static const struct i2c_spec_values fast_mode_plus_spec = {
+ .min_low_ns = 500 + I2C_FAST_MODE_PLUS_BUFFER,
+ .min_su_sta_ns = 260 + I2C_FAST_MODE_PLUS_BUFFER,
+ .max_hd_dat_ns = 400 - I2C_FAST_MODE_PLUS_BUFFER,
+ .min_su_dat_ns = 50 + I2C_FAST_MODE_PLUS_BUFFER,
+};
+
static const struct i2c_adapter_quirks mt6577_i2c_quirks = {
.flags = I2C_AQ_COMB_WRITE_THEN_READ,
.max_num_msgs = 1,
@@ -397,14 +463,38 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
if (i2c->dev_comp->dcm)
mtk_i2c_writew(i2c, I2C_DCM_DISABLE, OFFSET_DCM_EN);
- if (i2c->dev_comp->timing_adjust)
- mtk_i2c_writew(i2c, I2C_DEFAULT_CLK_DIV - 1, OFFSET_CLOCK_DIV);
-
mtk_i2c_writew(i2c, i2c->timing_reg, OFFSET_TIMING);
mtk_i2c_writew(i2c, i2c->high_speed_reg, OFFSET_HS);
if (i2c->dev_comp->ltiming_adjust)
mtk_i2c_writew(i2c, i2c->ltiming_reg, OFFSET_LTIMING);
+ if (i2c->dev_comp->timing_adjust) {
+ mtk_i2c_writew(i2c, i2c->ac_timing.ext, OFFSET_EXT_CONF);
+ mtk_i2c_writew(i2c, i2c->ac_timing.inter_clk_div,
+ OFFSET_CLOCK_DIV);
+ mtk_i2c_writew(i2c, I2C_SCL_MIS_COMP_VALUE,
+ OFFSET_SCL_MIS_COMP_POINT);
+ mtk_i2c_writew(i2c, i2c->ac_timing.sda_timing,
+ OFFSET_SDA_TIMING);
+
+ if (i2c->dev_comp->ltiming_adjust) {
+ mtk_i2c_writew(i2c, i2c->ac_timing.htiming,
+ OFFSET_TIMING);
+ mtk_i2c_writew(i2c, i2c->ac_timing.hs, OFFSET_HS);
+ mtk_i2c_writew(i2c, i2c->ac_timing.ltiming,
+ OFFSET_LTIMING);
+ } else {
+ mtk_i2c_writew(i2c, i2c->ac_timing.scl_hl_ratio,
+ OFFSET_SCL_HIGH_LOW_RATIO);
+ mtk_i2c_writew(i2c, i2c->ac_timing.hs_scl_hl_ratio,
+ OFFSET_HS_SCL_HIGH_LOW_RATIO);
+ mtk_i2c_writew(i2c, i2c->ac_timing.sta_stop,
+ OFFSET_STA_STO_AC_TIMING);
+ mtk_i2c_writew(i2c, i2c->ac_timing.hs_sta_stop,
+ OFFSET_HS_STA_STO_AC_TIMING);
+ }
+ }
+
/* If use i2c pin from PMIC mt6397 side, need set PATH_DIR first */
if (i2c->have_pmic)
mtk_i2c_writew(i2c, I2C_CONTROL_WRAPPER, OFFSET_PATH_DIR);
@@ -422,6 +512,125 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
writel(I2C_DMA_CLR_FLAG, i2c->pdmabase + OFFSET_RST);
}
+static const struct i2c_spec_values *mtk_i2c_get_spec(unsigned int speed)
+{
+ if (speed <= I2C_MAX_STANDARD_MODE_FREQ)
+ return &standard_mode_spec;
+ else if (speed <= I2C_MAX_FAST_MODE_FREQ)
+ return &fast_mode_spec;
+ else
+ return &fast_mode_plus_spec;
+}
+
+static int mtk_i2c_max_step_cnt(unsigned int target_speed)
+{
+ if (target_speed > I2C_MAX_FAST_MODE_FREQ)
+ return MAX_HS_STEP_CNT_DIV;
+ else
+ return MAX_STEP_CNT_DIV;
+}
+
+/*
+ * Check and Calculate i2c ac-timing
+ *
+ * Hardware design:
+ * sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src
+ * xxx_cnt_div = spec->min_xxx_ns / sample_ns
+ *
+ * Sample_ns is rounded down for xxx_cnt_div would be greater
+ * than the smallest spec.
+ * The sda_timing is chosen as the middle value between
+ * the largest and smallest.
+ */
+static int mtk_i2c_check_ac_timing(struct mtk_i2c *i2c,
+ unsigned int clk_src,
+ unsigned int check_speed,
+ unsigned int step_cnt,
+ unsigned int sample_cnt)
+{
+ const struct i2c_spec_values *spec;
+ unsigned int su_sta_cnt, low_cnt, high_cnt, max_step_cnt;
+ unsigned int sda_max, sda_min, clk_ns, max_sta_cnt = 0x3f;
+ long long sample_ns = (1000000000 * (sample_cnt + 1)) / clk_src;
+
+ if (!i2c->dev_comp->timing_adjust)
+ return 0;
+
+ if (i2c->dev_comp->ltiming_adjust)
+ max_sta_cnt = 0x100;
+
+ spec = mtk_i2c_get_spec(check_speed);
+
+ if (i2c->dev_comp->ltiming_adjust)
+ clk_ns = 1000000000 / clk_src;
+ else
+ clk_ns = sample_ns / 2;
+
+ su_sta_cnt = DIV_ROUND_UP(spec->min_su_sta_ns, clk_ns);
+ if (su_sta_cnt > max_sta_cnt)
+ return -1;
+
+ low_cnt = DIV_ROUND_UP(spec->min_low_ns, sample_ns);
+ max_step_cnt = mtk_i2c_max_step_cnt(check_speed);
+ if ((2 * step_cnt) > low_cnt && low_cnt < max_step_cnt) {
+ if (low_cnt > step_cnt) {
+ high_cnt = 2 * step_cnt - low_cnt;
+ } else {
+ high_cnt = step_cnt;
+ low_cnt = step_cnt;
+ }
+ } else {
+ return -2;
+ }
+
+ sda_max = spec->max_hd_dat_ns / sample_ns;
+ if (sda_max > low_cnt)
+ sda_max = 0;
+
+ sda_min = DIV_ROUND_UP(spec->min_su_dat_ns, sample_ns);
+ if (sda_min < low_cnt)
+ sda_min = 0;
+
+ if (sda_min > sda_max)
+ return -3;
+
+ if (check_speed > I2C_MAX_FAST_MODE_FREQ) {
+ if (i2c->dev_comp->ltiming_adjust) {
+ i2c->ac_timing.hs = I2C_TIME_DEFAULT_VALUE |
+ (sample_cnt << 12) | (high_cnt << 8);
+ i2c->ac_timing.ltiming &= ~GENMASK(15, 9);
+ i2c->ac_timing.ltiming |= (sample_cnt << 12) |
+ (low_cnt << 9);
+ i2c->ac_timing.ext &= ~GENMASK(7, 1);
+ i2c->ac_timing.ext |= (su_sta_cnt << 1) | (1 << 0);
+ } else {
+ i2c->ac_timing.hs_scl_hl_ratio = (1 << 12) |
+ (high_cnt << 6) | low_cnt;
+ i2c->ac_timing.hs_sta_stop = (su_sta_cnt << 8) |
+ su_sta_cnt;
+ }
+ i2c->ac_timing.sda_timing &= ~GENMASK(11, 6);
+ i2c->ac_timing.sda_timing |= (1 << 12) |
+ ((sda_max + sda_min) / 2) << 6;
+ } else {
+ if (i2c->dev_comp->ltiming_adjust) {
+ i2c->ac_timing.htiming = (sample_cnt << 8) | (high_cnt);
+ i2c->ac_timing.ltiming = (sample_cnt << 6) | (low_cnt);
+ i2c->ac_timing.ext = (su_sta_cnt << 8) | (1 << 0);
+ } else {
+ i2c->ac_timing.scl_hl_ratio = (1 << 12) |
+ (high_cnt << 6) | low_cnt;
+ i2c->ac_timing.sta_stop = (su_sta_cnt << 8) |
+ su_sta_cnt;
+ }
+
+ i2c->ac_timing.sda_timing = (1 << 12) |
+ (sda_max + sda_min) / 2;
+ }
+
+ return 0;
+}
+
/*
* Calculate i2c port speed
*
@@ -446,15 +655,12 @@ static int mtk_i2c_calculate_speed(struct mtk_i2c *i2c, unsigned int clk_src,
unsigned int opt_div;
unsigned int best_mul;
unsigned int cnt_mul;
+ int ret = -EINVAL;
if (target_speed > I2C_MAX_FAST_MODE_PLUS_FREQ)
target_speed = I2C_MAX_FAST_MODE_PLUS_FREQ;
- if (target_speed > I2C_MAX_FAST_MODE_FREQ)
- max_step_cnt = MAX_HS_STEP_CNT_DIV;
- else
- max_step_cnt = MAX_STEP_CNT_DIV;
-
+ max_step_cnt = mtk_i2c_max_step_cnt(target_speed);
base_step_cnt = max_step_cnt;
/* Find the best combination */
opt_div = DIV_ROUND_UP(clk_src >> 1, target_speed);
@@ -473,6 +679,11 @@ static int mtk_i2c_calculate_speed(struct mtk_i2c *i2c, unsigned int clk_src,
continue;
if (cnt_mul < best_mul) {
+ ret = mtk_i2c_check_ac_timing(i2c, clk_src,
+ target_speed, step_cnt - 1, sample_cnt - 1);
+ if (ret)
+ continue;
+
best_mul = cnt_mul;
base_sample_cnt = sample_cnt;
base_step_cnt = step_cnt;
@@ -481,6 +692,9 @@ static int mtk_i2c_calculate_speed(struct mtk_i2c *i2c, unsigned int clk_src,
}
}
+ if (ret)
+ return -EINVAL;
+
sample_cnt = base_sample_cnt;
step_cnt = base_step_cnt;
@@ -506,47 +720,68 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk)
unsigned int l_step_cnt;
unsigned int l_sample_cnt;
unsigned int target_speed;
+ unsigned int clk_div;
+ unsigned int max_clk_div;
int ret;
- clk_src = parent_clk / i2c->clk_src_div;
target_speed = i2c->speed_hz;
+ parent_clk /= i2c->clk_src_div;
- if (target_speed > I2C_MAX_FAST_MODE_FREQ) {
- /* Set master code speed register */
- ret = mtk_i2c_calculate_speed(i2c, clk_src, I2C_MAX_FAST_MODE_FREQ,
- &l_step_cnt, &l_sample_cnt);
- if (ret < 0)
- return ret;
-
- i2c->timing_reg = (l_sample_cnt << 8) | l_step_cnt;
-
- /* Set the high speed mode register */
- ret = mtk_i2c_calculate_speed(i2c, clk_src, target_speed,
- &step_cnt, &sample_cnt);
- if (ret < 0)
- return ret;
-
- i2c->high_speed_reg = I2C_TIME_DEFAULT_VALUE |
- (sample_cnt << 12) | (step_cnt << 8);
+ if (i2c->dev_comp->timing_adjust)
+ max_clk_div = MAX_CLOCK_DIV;
+ else
+ max_clk_div = 1;
+
+ for (clk_div = 1; clk_div <= max_clk_div; clk_div++) {
+ clk_src = parent_clk / clk_div;
+
+ if (target_speed > I2C_MAX_FAST_MODE_FREQ) {
+ /* Set master code speed register */
+ ret = mtk_i2c_calculate_speed(i2c, clk_src,
+ I2C_MAX_FAST_MODE_FREQ,
+ &l_step_cnt,
+ &l_sample_cnt);
+ if (ret < 0)
+ continue;
+
+ i2c->timing_reg = (l_sample_cnt << 8) | l_step_cnt;
+
+ /* Set the high speed mode register */
+ ret = mtk_i2c_calculate_speed(i2c, clk_src,
+ target_speed, &step_cnt,
+ &sample_cnt);
+ if (ret < 0)
+ continue;
+
+ i2c->high_speed_reg = I2C_TIME_DEFAULT_VALUE |
+ (sample_cnt << 12) | (step_cnt << 8);
+
+ if (i2c->dev_comp->ltiming_adjust)
+ i2c->ltiming_reg =
+ (l_sample_cnt << 6) | l_step_cnt |
+ (sample_cnt << 12) | (step_cnt << 9);
+ } else {
+ ret = mtk_i2c_calculate_speed(i2c, clk_src,
+ target_speed, &l_step_cnt,
+ &l_sample_cnt);
+ if (ret < 0)
+ continue;
- if (i2c->dev_comp->ltiming_adjust)
- i2c->ltiming_reg = (l_sample_cnt << 6) | l_step_cnt |
- (sample_cnt << 12) | (step_cnt << 9);
- } else {
- ret = mtk_i2c_calculate_speed(i2c, clk_src, target_speed,
- &step_cnt, &sample_cnt);
- if (ret < 0)
- return ret;
+ i2c->timing_reg = (l_sample_cnt << 8) | l_step_cnt;
- i2c->timing_reg = (sample_cnt << 8) | step_cnt;
+ /* Disable the high speed transaction */
+ i2c->high_speed_reg = I2C_TIME_CLR_VALUE;
- /* Disable the high speed transaction */
- i2c->high_speed_reg = I2C_TIME_CLR_VALUE;
+ if (i2c->dev_comp->ltiming_adjust)
+ i2c->ltiming_reg =
+ (l_sample_cnt << 6) | l_step_cnt;
+ }
- if (i2c->dev_comp->ltiming_adjust)
- i2c->ltiming_reg = (sample_cnt << 6) | step_cnt;
+ break;
}
+ i2c->ac_timing.inter_clk_div = clk_div - 1;
+
return 0;
}
@@ -586,12 +821,6 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
mtk_i2c_writew(i2c, control_reg, OFFSET_CONTROL);
- /* set start condition */
- if (i2c->speed_hz <= I2C_MAX_STANDARD_MODE_FREQ)
- mtk_i2c_writew(i2c, I2C_ST_START_CON, OFFSET_EXT_CONF);
- else
- mtk_i2c_writew(i2c, I2C_FS_START_CON, OFFSET_EXT_CONF);
-
addr_reg = i2c_8bit_addr_from_msg(msgs);
mtk_i2c_writew(i2c, addr_reg, OFFSET_SLAVE_ADDR);
@@ -948,9 +1177,6 @@ static int mtk_i2c_probe(struct platform_device *pdev)
if (ret)
return -EINVAL;
- if (i2c->dev_comp->timing_adjust)
- i2c->clk_src_div *= I2C_DEFAULT_CLK_DIV;
-
if (i2c->have_pmic && !i2c->dev_comp->pmic_i2c)
return -EINVAL;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4 0/5] iommu: Add Allwinner H6 IOMMU driver
From: Joerg Roedel @ 2020-05-14 13:16 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Mark Rutland, Rob Herring, Frank Rowand, devicetree,
linux-arm-kernel, iommu
In-Reply-To: <20200514130900.k4gvr3zcajg3rouc@gilmour.lan>
On Thu, May 14, 2020 at 03:09:00PM +0200, Maxime Ripard wrote:
> On Thu, May 14, 2020 at 02:38:55PM +0200, Joerg Roedel wrote:
> > On Wed, May 13, 2020 at 04:07:19PM +0200, Maxime Ripard wrote:
> > > Maxime Ripard (5):
> > > dt-bindings: iommu: Add Allwinner H6 IOMMU bindings
> > > dt-bindings: display: sun8i-mixer: Allow for an iommu property
> > > iommu: Add Allwinner H6 IOMMU driver
> > > arm64: dts: allwinner: h6: Add IOMMU
> > > drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
> >
> > Applied all to the IOMMU tree, thanks. The code lives in the
> > arm/allwinner branch.
>
> Did you also merge the DTS and DRM patches?
>
> Ideally, they should be merged through other trees to avoid the conflicts as
> much as possible (arm-soc and drm-misc respectively).
>
> If it's an option, could you drop all of them but "dt-bindings: iommu: Add
> Allwinner H6 IOMMU bindings" and "iommu: Add Allwinner H6 IOMMU driver"?
Okay, just to be on the safe side, I am going to drop:
dt-bindings: display: sun8i-mixer: Allow for an iommu property
arm64: dts: allwinner: h6: Add IOMMU
drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU
from the iommu-tree?
I took them because you are also maintaining the DRM driver, which
counted as an implicit ACK for me :)
Joerg
^ permalink raw reply
* [PATCH v10 1/5] PCI: Don't disable decoding when mmio_always_on is set
From: Jiaxun Yang @ 2020-05-14 13:16 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Bjorn Helgaas, Bjorn Helgaas, Rob Herring,
Thomas Bogendoerfer, Huacai Chen, Lorenzo Pieralisi, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <20200427060551.1372591-1-jiaxun.yang@flygoat.com>
Don't disable MEM/IO decoding when a device have both non_compliant_bars
and mmio_always_on.
That would allow us quirk devices with junk in BARs but can't disable
their decoding.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Acked-by: Bjorn Helgaas <helgaas@kernel.org>
---
drivers/pci/probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 77b8a145c39b..d9c2c3301a8a 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1822,7 +1822,7 @@ int pci_setup_device(struct pci_dev *dev)
/* Device class may be changed after fixup */
class = dev->class >> 8;
- if (dev->non_compliant_bars) {
+ if (dev->non_compliant_bars && !dev->mmio_always_on) {
pci_read_config_word(dev, PCI_COMMAND, &cmd);
if (cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pci_info(dev, "device has non-compliant BARs; disabling IO/MEM decoding\n");
--
2.26.2
^ permalink raw reply related
* [PATCH v10 2/5] PCI: Add Loongson PCI Controller support
From: Jiaxun Yang @ 2020-05-14 13:16 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Rob Herring, Bjorn Helgaas, Rob Herring,
Thomas Bogendoerfer, Huacai Chen, Lorenzo Pieralisi, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <20200514131650.3587281-1-jiaxun.yang@flygoat.com>
This controller can be found on Loongson-2K SoC, Loongson-3
systems with RS780E/LS7A PCH.
The RS780E part of code was previously located at
arch/mips/pci/ops-loongson3.c and now it can use generic PCI
driver implementation.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Rob Herring <robh@kernel.org>
--
v2:
- Clean up according to rob's suggestions
- Claim that it can't work as a module
v3:
- Fix a typo
v4:
- More clean-ups: Drop flag check, use devfn
v7:
- Fix ordering according to huacai's suggestion
v8:
- Style clean and bugfix according to Bjorn's review
v9:
- Confirm with vendor about the details on system_bus BARs
- Further cleanups
- I think assume root_bus as 0 simplify our code a lot, as that's
always valid to the hardware, as we're not ecam or dwc, we can't
easily get host bus_nr via cfg, adding that will cause unnecessary
overhead.
v10:
- Enhance comments about system_bus quirk and host bus quirk.
---
drivers/pci/controller/Kconfig | 10 ++
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pci-loongson.c | 249 ++++++++++++++++++++++++++
3 files changed, 260 insertions(+)
create mode 100644 drivers/pci/controller/pci-loongson.c
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 91bfdb784829..ae36edb1d7db 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -258,6 +258,16 @@ config PCI_HYPERV_INTERFACE
The Hyper-V PCI Interface is a helper driver allows other drivers to
have a common interface with the Hyper-V PCI frontend driver.
+config PCI_LOONGSON
+ bool "LOONGSON PCI Controller"
+ depends on MACH_LOONGSON64 || COMPILE_TEST
+ depends on OF
+ depends on PCI_QUIRKS
+ default MACH_LOONGSON64
+ help
+ Say Y here if you want to enable PCI controller support on
+ Loongson systems.
+
source "drivers/pci/controller/dwc/Kconfig"
source "drivers/pci/controller/mobiveil/Kconfig"
source "drivers/pci/controller/cadence/Kconfig"
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index 158c59771824..fbac4b0190a0 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
+obj-$(CONFIG_PCI_LOONGSON) += pci-loongson.o
# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
obj-y += dwc/
obj-y += mobiveil/
diff --git a/drivers/pci/controller/pci-loongson.c b/drivers/pci/controller/pci-loongson.c
new file mode 100644
index 000000000000..4879377b86f3
--- /dev/null
+++ b/drivers/pci/controller/pci-loongson.c
@@ -0,0 +1,249 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Loongson PCI Host Controller Driver
+ *
+ * Copyright (C) 2020 Jiaxun Yang <jiaxun.yang@flygoat.com>
+ */
+
+#include <linux/of_device.h>
+#include <linux/of_pci.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+
+#include "../pci.h"
+
+/* Device IDs */
+#define DEV_PCIE_PORT_0 0x7a09
+#define DEV_PCIE_PORT_1 0x7a19
+#define DEV_PCIE_PORT_2 0x7a29
+
+#define DEV_LS2K_APB 0x7a02
+#define DEV_LS7A_CONF 0x7a10
+#define DEV_LS7A_LPC 0x7a0c
+
+#define FLAG_CFG0 BIT(0)
+#define FLAG_CFG1 BIT(1)
+#define FLAG_DEV_FIX BIT(2)
+
+struct loongson_pci {
+ void __iomem *cfg0_base;
+ void __iomem *cfg1_base;
+ struct platform_device *pdev;
+ u32 flags;
+};
+
+/* Fixup wrong class code in PCIe bridges */
+static void bridge_class_quirk(struct pci_dev *dev)
+{
+ dev->class = PCI_CLASS_BRIDGE_PCI << 8;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+ DEV_PCIE_PORT_0, bridge_class_quirk);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+ DEV_PCIE_PORT_1, bridge_class_quirk);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+ DEV_PCIE_PORT_2, bridge_class_quirk);
+
+static void system_bus_quirk(struct pci_dev *pdev)
+{
+ u16 tmp;
+
+ /*
+ * The address space consumed by these devices is outside the
+ * resources of the host bridge.
+ */
+ pdev->mmio_always_on = 1;
+ pdev->non_compliant_bars = 1;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
+ DEV_LS2K_APB, system_bus_quirk);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
+ DEV_LS7A_CONF, system_bus_quirk);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
+ DEV_LS7A_LPC, system_bus_quirk);
+
+static void loongson_mrrs_quirk(struct pci_dev *dev)
+{
+ struct pci_bus *bus = dev->bus;
+ struct pci_dev *bridge;
+ static const struct pci_device_id bridge_devids[] = {
+ { PCI_VDEVICE(LOONGSON, DEV_PCIE_PORT_0) },
+ { PCI_VDEVICE(LOONGSON, DEV_PCIE_PORT_1) },
+ { PCI_VDEVICE(LOONGSON, DEV_PCIE_PORT_2) },
+ { 0, },
+ };
+
+ /* look for the matching bridge */
+ while (!pci_is_root_bus(bus)) {
+ bridge = bus->self;
+ bus = bus->parent;
+ /*
+ * Some Loongson PCIe ports have a h/w limitation of
+ * 256 bytes maximum read request size. They can't handle
+ * anything larger than this. So force this limit on
+ * any devices attached under these ports.
+ */
+ if (pci_match_id(bridge_devids, bridge)) {
+ if (pcie_get_readrq(dev) > 256) {
+ pci_info(dev, "limiting MRRS to 256\n");
+ pcie_set_readrq(dev, 256);
+ }
+ break;
+ }
+ }
+}
+DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, loongson_mrrs_quirk);
+
+static void __iomem *cfg1_map(struct loongson_pci *priv, int bus,
+ unsigned int devfn, int where)
+{
+ unsigned long addroff = 0x0;
+
+ if (bus != 0)
+ addroff |= BIT(28); /* Type 1 Access */
+ addroff |= (where & 0xff) | ((where & 0xf00) << 16);
+ addroff |= (bus << 16) | (devfn << 8);
+ return priv->cfg1_base + addroff;
+}
+
+static void __iomem *cfg0_map(struct loongson_pci *priv, int bus,
+ unsigned int devfn, int where)
+{
+ unsigned long addroff = 0x0;
+
+ if (bus != 0)
+ addroff |= BIT(24); /* Type 1 Access */
+ addroff |= (bus << 16) | (devfn << 8) | where;
+ return priv->cfg0_base + addroff;
+}
+
+void __iomem *pci_loongson_map_bus(struct pci_bus *bus, unsigned int devfn,
+ int where)
+{
+ unsigned char busnum = bus->number;
+ struct pci_host_bridge *bridge = pci_find_host_bridge(bus);
+ struct loongson_pci *priv = pci_host_bridge_priv(bridge);
+
+ /*
+ * Do not read more than one device on the bus other than
+ * the host bus. For our hardware the root bus is always bus 0.
+ */
+ if (priv->flags & FLAG_DEV_FIX && busnum != 0 &&
+ PCI_SLOT(devfn) > 0)
+ return NULL;
+
+ /* CFG0 can only access standard space */
+ if (where < PCI_CFG_SPACE_SIZE && priv->cfg0_base)
+ return cfg0_map(priv, busnum, devfn, where);
+
+ /* CFG1 can access extended space */
+ if (where < PCI_CFG_SPACE_EXP_SIZE && priv->cfg1_base)
+ return cfg1_map(priv, busnum, devfn, where);
+
+ return NULL;
+}
+
+static int loongson_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+{
+ int irq;
+ u8 val;
+
+ irq = of_irq_parse_and_map_pci(dev, slot, pin);
+ if (irq > 0)
+ return irq;
+
+ /* Care i8259 legacy systems */
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &val);
+ /* i8259 only have 15 IRQs */
+ if (val > 15)
+ return 0;
+
+ return val;
+}
+
+/* H/w only accept 32-bit PCI operations */
+static struct pci_ops loongson_pci_ops = {
+ .map_bus = pci_loongson_map_bus,
+ .read = pci_generic_config_read32,
+ .write = pci_generic_config_write32,
+};
+
+static const struct of_device_id loongson_pci_of_match[] = {
+ { .compatible = "loongson,ls2k-pci",
+ .data = (void *)(FLAG_CFG0 | FLAG_CFG1 | FLAG_DEV_FIX), },
+ { .compatible = "loongson,ls7a-pci",
+ .data = (void *)(FLAG_CFG0 | FLAG_CFG1 | FLAG_DEV_FIX), },
+ { .compatible = "loongson,rs780e-pci",
+ .data = (void *)(FLAG_CFG0), },
+ {}
+};
+
+static int loongson_pci_probe(struct platform_device *pdev)
+{
+ struct loongson_pci *priv;
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+ struct pci_host_bridge *bridge;
+ struct resource *regs;
+ int err;
+
+ if (!node)
+ return -ENODEV;
+
+ bridge = devm_pci_alloc_host_bridge(dev, sizeof(*priv));
+ if (!bridge)
+ return -ENODEV;
+
+ priv = pci_host_bridge_priv(bridge);
+ priv->pdev = pdev;
+ priv->flags = (unsigned long)of_device_get_match_data(dev);
+
+ regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!regs) {
+ dev_err(dev, "missing mem resources for cfg0\n");
+ return -EINVAL;
+ }
+
+ priv->cfg0_base = devm_pci_remap_cfg_resource(dev, regs);
+ if (IS_ERR(priv->cfg0_base))
+ return PTR_ERR(priv->cfg0_base);
+
+ /* CFG1 is optional */
+ if (priv->flags & FLAG_CFG1) {
+ regs = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!regs)
+ dev_info(dev, "missing mem resource for cfg1\n");
+ else {
+ priv->cfg1_base = devm_pci_remap_cfg_resource(dev, regs);
+ if (IS_ERR(priv->cfg1_base))
+ priv->cfg1_base = NULL;
+ }
+ }
+
+ err = pci_parse_request_of_pci_ranges(dev, &bridge->windows,
+ &bridge->dma_ranges, NULL);
+ if (err) {
+ dev_err(dev, "failed to get bridge resources\n");
+ return err;
+ }
+
+ bridge->dev.parent = dev;
+ bridge->sysdata = priv;
+ bridge->ops = &loongson_pci_ops;
+ bridge->map_irq = loongson_map_irq;
+
+ err = pci_host_probe(bridge);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static struct platform_driver loongson_pci_driver = {
+ .driver = {
+ .name = "loongson-pci",
+ .of_match_table = loongson_pci_of_match,
+ },
+ .probe = loongson_pci_probe,
+};
+builtin_platform_driver(loongson_pci_driver);
--
2.26.2
^ permalink raw reply related
* [PATCH v10 3/5] dt-bindings: Document Loongson PCI Host Controller
From: Jiaxun Yang @ 2020-05-14 13:16 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Rob Herring, Bjorn Helgaas, Rob Herring,
Thomas Bogendoerfer, Huacai Chen, Lorenzo Pieralisi, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <20200514131650.3587281-1-jiaxun.yang@flygoat.com>
PCI host controller found on Loongson PCHs and SoCs.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/pci/loongson.yaml | 62 +++++++++++++++++++
1 file changed, 62 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/loongson.yaml
diff --git a/Documentation/devicetree/bindings/pci/loongson.yaml b/Documentation/devicetree/bindings/pci/loongson.yaml
new file mode 100644
index 000000000000..30e7cf1aeb87
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/loongson.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/loongson.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson PCI Host Controller
+
+maintainers:
+ - Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+description: |+
+ PCI host controller found on Loongson PCHs and SoCs.
+
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: loongson,ls2k-pci
+ - const: loongson,ls7a-pci
+ - const: loongson,rs780e-pci
+
+ reg:
+ minItems: 1
+ maxItems: 2
+ items:
+ - description: CFG0 standard config space register
+ - description: CFG1 extended config space register
+
+ ranges:
+ minItems: 1
+ maxItems: 3
+
+
+required:
+ - compatible
+ - reg
+ - ranges
+
+examples:
+ - |
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcie@1a000000 {
+ compatible = "loongson,rs780e-pci";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ // CPU_PHYSICAL(2) SIZE(2)
+ reg = <0x0 0x1a000000 0x0 0x2000000>;
+
+ // BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2)
+ ranges = <0x01000000 0x0 0x00004000 0x0 0x00004000 0x0 0x00004000>,
+ <0x02000000 0x0 0x40000000 0x0 0x40000000 0x0 0x40000000>;
+ };
+ };
+...
--
2.26.2
^ permalink raw reply related
* [PATCH v10 4/5] MIPS: DTS: Loongson64: Add PCI Controller Node
From: Jiaxun Yang @ 2020-05-14 13:16 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Bjorn Helgaas, Rob Herring, Thomas Bogendoerfer,
Huacai Chen, Lorenzo Pieralisi, Paul Burton, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20200514131650.3587281-1-jiaxun.yang@flygoat.com>
Add PCI Host controller node for Loongson64 with RS780E PCH dts.
Note that PCI interrupts are probed via legacy way, as different
machine have different interrupt arrangement, we can't cover all
of them in dt.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
arch/mips/boot/dts/loongson/rs780e-pch.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/mips/boot/dts/loongson/rs780e-pch.dtsi b/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
index 8687c4f7370a..d0d5d60a8697 100644
--- a/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
@@ -9,6 +9,18 @@ bus@10000000 {
0 0x40000000 0 0x40000000 0 0x40000000
0xfd 0xfe000000 0xfd 0xfe000000 0 0x2000000 /* PCI Config Space */>;
+ pci@1a000000 {
+ compatible = "loongson,rs780e-pci";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ reg = <0 0x1a000000 0 0x02000000>;
+
+ ranges = <0x01000000 0 0x00004000 0 0x18004000 0 0x00004000>,
+ <0x02000000 0 0x40000000 0 0x40000000 0 0x40000000>;
+ };
+
isa {
compatible = "isa";
#address-cells = <2>;
--
2.26.2
^ permalink raw reply related
* [PATCH v10 5/5] MIPS: Loongson64: Switch to generic PCI driver
From: Jiaxun Yang @ 2020-05-14 13:16 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Bjorn Helgaas, Rob Herring, Thomas Bogendoerfer,
Huacai Chen, Lorenzo Pieralisi, Paul Burton, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20200514131650.3587281-1-jiaxun.yang@flygoat.com>
We can now enable generic PCI driver in Kconfig, and remove legacy
PCI driver code.
Radeon vbios quirk is moved to the platform folder to fit the
new structure.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
--
v9: Fix licenses tag
---
arch/mips/Kconfig | 1 +
arch/mips/loongson64/Makefile | 2 +-
arch/mips/loongson64/vbios_quirk.c | 29 ++++++++
arch/mips/pci/Makefile | 1 -
arch/mips/pci/fixup-loongson3.c | 71 ------------------
arch/mips/pci/ops-loongson3.c | 116 -----------------------------
6 files changed, 31 insertions(+), 189 deletions(-)
create mode 100644 arch/mips/loongson64/vbios_quirk.c
delete mode 100644 arch/mips/pci/fixup-loongson3.c
delete mode 100644 arch/mips/pci/ops-loongson3.c
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 0519ca9f00f9..7a4fcc4ade1f 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -480,6 +480,7 @@ config MACH_LOONGSON64
select IRQ_MIPS_CPU
select NR_CPUS_DEFAULT_64
select USE_GENERIC_EARLY_PRINTK_8250
+ select PCI_DRIVERS_GENERIC
select SYS_HAS_CPU_LOONGSON64
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_SMP
diff --git a/arch/mips/loongson64/Makefile b/arch/mips/loongson64/Makefile
index 6f3c2b47f66f..6f81b822aeae 100644
--- a/arch/mips/loongson64/Makefile
+++ b/arch/mips/loongson64/Makefile
@@ -8,5 +8,5 @@ obj-$(CONFIG_MACH_LOONGSON64) += cop2-ex.o platform.o dma.o \
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_NUMA) += numa.o
obj-$(CONFIG_RS780_HPET) += hpet.o
-obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_SUSPEND) += pm.o
+obj-$(CONFIG_PCI_QUIRKS) += vbios_quirk.o
diff --git a/arch/mips/loongson64/vbios_quirk.c b/arch/mips/loongson64/vbios_quirk.c
new file mode 100644
index 000000000000..9a29e94d3db1
--- /dev/null
+++ b/arch/mips/loongson64/vbios_quirk.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/pci.h>
+#include <loongson.h>
+
+static void pci_fixup_radeon(struct pci_dev *pdev)
+{
+ struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];
+
+ if (res->start)
+ return;
+
+ if (!loongson_sysconf.vgabios_addr)
+ return;
+
+ pci_disable_rom(pdev);
+ if (res->parent)
+ release_resource(res);
+
+ res->start = virt_to_phys((void *) loongson_sysconf.vgabios_addr);
+ res->end = res->start + 256*1024 - 1;
+ res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW |
+ IORESOURCE_PCI_FIXED;
+
+ dev_info(&pdev->dev, "BAR %d: assigned %pR for Radeon ROM\n",
+ PCI_ROM_RESOURCE, res);
+}
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, 0x9615,
+ PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_radeon);
diff --git a/arch/mips/pci/Makefile b/arch/mips/pci/Makefile
index 342ce10ef593..438f10955d89 100644
--- a/arch/mips/pci/Makefile
+++ b/arch/mips/pci/Makefile
@@ -35,7 +35,6 @@ obj-$(CONFIG_LASAT) += pci-lasat.o
obj-$(CONFIG_MIPS_COBALT) += fixup-cobalt.o
obj-$(CONFIG_LEMOTE_FULOONG2E) += fixup-fuloong2e.o ops-loongson2.o
obj-$(CONFIG_LEMOTE_MACH2F) += fixup-lemote2f.o ops-loongson2.o
-obj-$(CONFIG_MACH_LOONGSON64) += fixup-loongson3.o ops-loongson3.o
obj-$(CONFIG_MIPS_MALTA) += fixup-malta.o pci-malta.o
obj-$(CONFIG_PMC_MSP7120_GW) += fixup-pmcmsp.o ops-pmcmsp.o
obj-$(CONFIG_PMC_MSP7120_EVAL) += fixup-pmcmsp.o ops-pmcmsp.o
diff --git a/arch/mips/pci/fixup-loongson3.c b/arch/mips/pci/fixup-loongson3.c
deleted file mode 100644
index 8a741c2c6685..000000000000
--- a/arch/mips/pci/fixup-loongson3.c
+++ /dev/null
@@ -1,71 +0,0 @@
-/*
- * fixup-loongson3.c
- *
- * Copyright (C) 2012 Lemote, Inc.
- * Author: Xiang Yu, xiangy@lemote.com
- * Chen Huacai, chenhc@lemote.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
- * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- */
-
-#include <linux/pci.h>
-#include <boot_param.h>
-
-static void print_fixup_info(const struct pci_dev *pdev)
-{
- dev_info(&pdev->dev, "Device %x:%x, irq %d\n",
- pdev->vendor, pdev->device, pdev->irq);
-}
-
-int pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
-{
- print_fixup_info(dev);
- return dev->irq;
-}
-
-static void pci_fixup_radeon(struct pci_dev *pdev)
-{
- struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];
-
- if (res->start)
- return;
-
- if (!loongson_sysconf.vgabios_addr)
- return;
-
- pci_disable_rom(pdev);
- if (res->parent)
- release_resource(res);
-
- res->start = virt_to_phys((void *) loongson_sysconf.vgabios_addr);
- res->end = res->start + 256*1024 - 1;
- res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW |
- IORESOURCE_PCI_FIXED;
-
- dev_info(&pdev->dev, "BAR %d: assigned %pR for Radeon ROM\n",
- PCI_ROM_RESOURCE, res);
-}
-
-DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
- PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_radeon);
-
-/* Do platform specific device initialization at pci_enable_device() time */
-int pcibios_plat_dev_init(struct pci_dev *dev)
-{
- return 0;
-}
diff --git a/arch/mips/pci/ops-loongson3.c b/arch/mips/pci/ops-loongson3.c
deleted file mode 100644
index 2f6ad36bdea6..000000000000
--- a/arch/mips/pci/ops-loongson3.c
+++ /dev/null
@@ -1,116 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include <linux/types.h>
-#include <linux/pci.h>
-#include <linux/kernel.h>
-
-#include <asm/mips-boards/bonito64.h>
-
-#include <loongson.h>
-
-#define PCI_ACCESS_READ 0
-#define PCI_ACCESS_WRITE 1
-
-#define HT1LO_PCICFG_BASE 0x1a000000
-#define HT1LO_PCICFG_BASE_TP1 0x1b000000
-
-static int loongson3_pci_config_access(unsigned char access_type,
- struct pci_bus *bus, unsigned int devfn,
- int where, u32 *data)
-{
- unsigned char busnum = bus->number;
- int function = PCI_FUNC(devfn);
- int device = PCI_SLOT(devfn);
- int reg = where & ~3;
- void *addrp;
- u64 addr;
-
- if (where < PCI_CFG_SPACE_SIZE) { /* standard config */
- addr = (busnum << 16) | (device << 11) | (function << 8) | reg;
- if (busnum == 0) {
- if (device > 31)
- return PCIBIOS_DEVICE_NOT_FOUND;
- addrp = (void *)TO_UNCAC(HT1LO_PCICFG_BASE | addr);
- } else {
- addrp = (void *)TO_UNCAC(HT1LO_PCICFG_BASE_TP1 | addr);
- }
- } else if (where < PCI_CFG_SPACE_EXP_SIZE) { /* extended config */
- struct pci_dev *rootdev;
-
- rootdev = pci_get_domain_bus_and_slot(0, 0, 0);
- if (!rootdev)
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- addr = pci_resource_start(rootdev, 3);
- if (!addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- addr |= busnum << 20 | device << 15 | function << 12 | reg;
- addrp = (void *)TO_UNCAC(addr);
- } else {
- return PCIBIOS_DEVICE_NOT_FOUND;
- }
-
- if (access_type == PCI_ACCESS_WRITE)
- writel(*data, addrp);
- else {
- *data = readl(addrp);
- if (*data == 0xffffffff) {
- *data = -1;
- return PCIBIOS_DEVICE_NOT_FOUND;
- }
- }
- return PCIBIOS_SUCCESSFUL;
-}
-
-static int loongson3_pci_pcibios_read(struct pci_bus *bus, unsigned int devfn,
- int where, int size, u32 *val)
-{
- u32 data = 0;
- int ret = loongson3_pci_config_access(PCI_ACCESS_READ,
- bus, devfn, where, &data);
-
- if (ret != PCIBIOS_SUCCESSFUL)
- return ret;
-
- if (size == 1)
- *val = (data >> ((where & 3) << 3)) & 0xff;
- else if (size == 2)
- *val = (data >> ((where & 3) << 3)) & 0xffff;
- else
- *val = data;
-
- return PCIBIOS_SUCCESSFUL;
-}
-
-static int loongson3_pci_pcibios_write(struct pci_bus *bus, unsigned int devfn,
- int where, int size, u32 val)
-{
- u32 data = 0;
- int ret;
-
- if (size == 4)
- data = val;
- else {
- ret = loongson3_pci_config_access(PCI_ACCESS_READ,
- bus, devfn, where, &data);
- if (ret != PCIBIOS_SUCCESSFUL)
- return ret;
-
- if (size == 1)
- data = (data & ~(0xff << ((where & 3) << 3))) |
- (val << ((where & 3) << 3));
- else if (size == 2)
- data = (data & ~(0xffff << ((where & 3) << 3))) |
- (val << ((where & 3) << 3));
- }
-
- ret = loongson3_pci_config_access(PCI_ACCESS_WRITE,
- bus, devfn, where, &data);
-
- return ret;
-}
-
-struct pci_ops loongson_pci_ops = {
- .read = loongson3_pci_pcibios_read,
- .write = loongson3_pci_pcibios_write
-};
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v2 3/3] ARM: dts: rockchip: add rk3288 ISP and DPHY
From: karthik poduval @ 2020-05-14 13:19 UTC (permalink / raw)
To: Johan Jonker
Cc: Linux Media Mailing List, heiko, linux-rockchip, Helen Koike,
Ezequiel Garcia, Rob Herring, devicetree
In-Reply-To: <9407b6c3-b932-5904-18ff-7c6cbf6bcc8b@gmail.com>
Ping, gentle reminder, do we have a recommendation on how to deal with
common driver supporting multiple SoC with different types and number
of clocks.
On Thu, Apr 23, 2020 at 4:12 AM Johan Jonker <jbx6244@gmail.com> wrote:
>
> Hi robh, Heiko, Karthik, Helen and others,
>
> See comments below.
> Should we change Helen's patch serie a little bit to accommodate other
> isp1 compatibles as well? Could you give advise here? Thanks!
>
> Johan
>
>
> On 4/23/20 7:10 AM, karthik poduval wrote:
> > Hi Johan/Helen,
> >
> > I was attempting to fix the yaml to work for both platforms rk3288 and
> > rk3399. I couldn't find any specific example in the existing yaml files
> > that deal with this exact scenario common driver but different clocks for
> > different chipsets. Could you point me to an appropriate example ?
> >
> > Meanwhile here is the patch I was trying out.
> > diff --git a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> > b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> > index af246b71eac6..4ca76a1bbb63 100644
> > --- a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> > +++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> > @@ -15,7 +15,11 @@ description: |
> >
> > properties:
> > compatible:
> > - const: rockchip,rk3399-cif-isp
> > + items:
> > + - enum:
> > + - rockchip,rk3288-cif-isp
> > + - rockchip,rk3399-cif-isp
> > + - const: rockchip,rk3399-cif-isp
> >
> > reg:
> > maxItems: 1
> > @@ -37,20 +41,38 @@ properties:
> > const: dphy
> >
>
> > clocks:
> > - items:
> > - - description: ISP clock
> > - - description: ISP AXI clock clock
> > - - description: ISP AXI clock wrapper clock
> > - - description: ISP AHB clock clock
> > - - description: ISP AHB wrapper clock
> > + oneOf:
> > + # rk3399 clocks
> > + - items:
> > + - description: ISP clock
> > + - description: ISP AXI clock clock
> > + - description: ISP AXI clock wrapper clock
> > + - description: ISP AHB clock clock
> > + - description: ISP AHB wrapper clock
> > + # rk3288 clocks
> > + - items:
> > + - description: ISP clock
> > + - description: ISP AXI clock clock
> > + - description: ISP AHB clock clock
> > + - description: ISP Pixel clock
> > + - description: ISP JPEG source clock
> >
>
> We can expect a few more clocks here, so just use:
>
> clocks:
> minItems: 4
> maxItems: 5
>
> or
>
> See question for Helen about 'pclk_isp_wrap':
>
> clocks:
> minItems: 4
> maxItems: 6
>
>
> From Rockchip tree:
>
> static const char * const rk1808_isp_clks[] = {
> "clk_isp",
> "aclk_isp",
> "hclk_isp",
> "pclk_isp",
> };
>
> static const char * const rk3288_isp_clks[] = {
> "clk_isp",
> "aclk_isp",
> "hclk_isp",
> "pclk_isp_in",
> "sclk_isp_jpe",
> };
>
> static const char * const rk3326_isp_clks[] = {
> "clk_isp",
> "aclk_isp",
> "hclk_isp",
> "pclk_isp",
> };
>
> static const char * const rk3368_isp_clks[] = {
> "clk_isp",
> "aclk_isp",
> "hclk_isp",
> "pclk_isp",
> };
>
> static const char * const rk3399_isp_clks[] = {
> "clk_isp",
> "aclk_isp",
> "hclk_isp",
> "aclk_isp_wrap",
> "hclk_isp_wrap",
> "pclk_isp_wrap"
> };
>
> Question for Helen:
>
> Where did 'pclk_isp_wrap' go in your patch serie?
>
> > clock-names:
> > - items:
> > - - const: clk_isp
> > - - const: aclk_isp
> > - - const: aclk_isp_wrap
> > - - const: hclk_isp
> > - - const: hclk_isp_wrap
> > + oneOf:
> > + # rk3399 clocks
>
> sort on SoC
>
> > + - items:
> > + - const: clk_isp
> > + - const: aclk_isp
> > + - const: aclk_isp_wrap
> > + - const: hclk_isp
> > + - const: hclk_isp_wrap
> > + # rk3288 clocks
>
> sort on SoC
>
> > + - items:
> > + - const: clk_isp
> > + - const: aclk_isp
> > + - const: hclk_isp
> > + - const: pclk_isp_in
> > + - const: sclk_isp_jpe
>
> clock-names:
> oneOf:
> # rk3288 clocks
> - items:
> - const: clk_isp
> description: ISP clock
> - const: aclk_isp
> description: ISP AXI clock clock
> - const: hclk_isp
> description: ISP AHB clock clock
> - const: pclk_isp_in
> description: ISP Pixel clock
> - const: sclk_isp_jpe
> description: ISP JPEG source clock
> # rk3399 clocks
> - items:
> - const: clk_isp
> description: ISP clock
> - const: aclk_isp
> description: ISP AXI clock clock
> - const: aclk_isp_wrap
> description: ISP AXI clock wrapper clock
> - const: hclk_isp
> description: ISP AHB clock clock
> - const: hclk_isp_wrap
> description: ISP AHB wrapper clock
>
> Question for robh:
> Is this a proper way to add description or is there a beter way?
>
> >
> > on running command.
> > make ARCH=arm dtbs_check
> > DT_SCHEMA_FILES=Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> >
> > I see following messages for dts nodes.
> > DTC arch/arm/boot/dts/rk3288-firefly-beta.dt.yaml
> > CHECK arch/arm/boot/dts/rk3288-firefly-beta.dt.yaml
> > /home/kpoduval/workspace/tinkerboard-yocto/build/tmp/work/tinker_board-poky-linux-gnueabi/linux-stable/5.5.7+gitAUTOINC+ceab3ac1e6-r0/linux-tinker_board-standard-build/arch/arm/boot/dts/rk3288-firefly-beta.dt.yaml:
> > isp@ff910000: clocks: [[7, 107], [7, 205], [7, 469], [7, 371], [7, 108]] is
> > valid under each of {'additionalItems': False, 'items': [{}, {}, {}, {},
> > {}], 'maxItems': 5, 'minItems': 5, 'type': 'array'}, {'additionalItems':
> > False, 'items': [{}, {}, {}, {}, {}], 'maxItems': 5, 'minItems': 5, 'type':
> > 'array'}
> > /home/kpoduval/workspace/tinkerboard-yocto/build/tmp/work/tinker_board-poky-linux-gnueabi/linux-stable/5.5.7+gitAUTOINC+ceab3ac1e6-r0/linux-tinker_board-standard-build/arch/arm/boot/dts/rk3288-firefly-beta.dt.yaml:
> > isp@ff910000: compatible: ['rockchip,rk3288-cif-isp'] is too short
> >
> > Are these cosidered as error messages ? The "too short" is being alerted
> > for the orgianl yaml for rk3399 without any of my chnages.
> > Kindly advise.
> >
> > --
> > Regards,
> > Karthik Poduval
> >
> > On Sat, Apr 11, 2020 at 10:13 PM karthik poduval <karthik.poduval@gmail.com>
> > wrote:
> >
> >> Thanks Johan for your valuable comments.
> >>
> >> On Wed, Apr 8, 2020 at 6:19 PM Johan Jonker <jbx6244@gmail.com> wrote:
> >>>
> >>> Hi Karthik and others,
> >>>
> >>> Include all mail lists found with:
> >>> ./scripts/get_maintainer.pl --nogit-fallback --nogit
> >>>
> >>> Helen is moving isp1 bindings out of staging.
> >>> Clocks and other things don't fit with her patch serie.
> >>> Maybe fix this while still in staging?
> >>>
> >>> arch/arm/boot/dts/rk3288-tinker.dt.yaml: isp@ff910000:
> >>> 'phys' is a required property
> >>> arch/arm/boot/dts/rk3288-tinker.dt.yaml: isp@ff910000:
> >>> 'phy-names' is a required property
> >>> arch/arm/boot/dts/rk3288-tinker.dt.yaml: isp@ff910000:
> >>> 'ports' is a required property
> >>>
> >>> arch/arm/boot/dts/rk3288-tinker.dt.yaml: isp@ff910000:
> >>> 'assigned-clock-rates', 'assigned-clocks'
> >>> do not match any of the regexes: 'pinctrl-[0-9]+'
> >>> arch/arm/boot/dts/rk3288-tinker.dt.yaml: isp@ff910000:
> >>> clock-names:2: 'aclk_isp_wrap' was expected
> >>> arch/arm/boot/dts/rk3288-tinker.dt.yaml: isp@ff910000:
> >>> clock-names:3: 'hclk_isp' was expected
> >>> arch/arm/boot/dts/rk3288-tinker.dt.yaml: isp@ff910000:
> >>> clock-names:4: 'hclk_isp_wrap' was expected
> >>>
> >>> arch/arm/boot/dts/rk3288-tinker.dt.yaml: mipi-phy-rx0: 'power-domains'
> >>> is a required property
> >>>
> >>> arch/arm/boot/dts/rk3288-tinker.dt.yaml: mipi-phy-rx0: clock-names:1:
> >>> 'dphy-cfg' was expected
> >>> arch/arm/boot/dts/rk3288-tinker.dt.yaml: mipi-phy-rx0: clock-names:
> >>> ['dphy-ref', 'pclk'] is too short
> >>> arch/arm/boot/dts/rk3288-tinker.dt.yaml: mipi-phy-rx0: clocks: [[7,
> >>> 126], [7, 358]] is too short
> >>>
> >>>
> >>> Inside yaml:
> >>> Use enum and sort.
> >>>>> properties:
> >>>>> compatible:
> >>>
> >>>>> const: rockchip,rk3399-cif-isp
> >>>>> + const: rockchip,rk3288-rkisp1
> >>>
> >>> enum:
> >>> - rockchip,rk3288-rkisp1
> >>> - rockchip,rk3399-cif-isp
> >>>
> >>>>> properties:
> >>>>> compatible:
> >>>>> const: rockchip,rk3399-mipi-dphy-rx0
> >>>>> + const: rockchip,rk3288-mipi-dphy-rx0
> >>>
> >>> enum:
> >>> - rockchip,rk3288-mipi-dphy-rx0
> >>> - rockchip,rk3399-mipi-dphy-rx0
> >>>
> >>>>
> >>>> Please, keep consistency, or rk3288-cif-isp, or we change
> >> rk3399-cif-isp to be rk3399-rkisp1.
> >>>
> >>>
> >>> On 4/6/20 9:30 AM, Karthik Poduval wrote:
> >>>> ISP and DPHY device entries missing so add them.
> >>>>
> >>>
> >>>> tested on tinkerbaord with ov5647 using command
> >>>> cam -c 1 -C -F cap
> >>>
> >>> Disclose dts node for ov5647 in cover letter, so people can reproduce
> >>> this experiment.
> >>>
> >>> Caution!
> >>> Without dts node this command doesn't work correct.
> >>>
> >>> make ARCH=arm dtbs_check
> >>>
> >> DT_SCHEMA_FILES=Documentation/devicetree/bindings/media/rockchip-isp1.yaml
> >>>
> >>> make ARCH=arm dtbs_check
> >>>
> >> DT_SCHEMA_FILES=Documentation/devicetree/bindings/phy/rockchip-mipi-dphy-rx0.yaml
> >>>
> >>> Needed to detect missing: phys, phy-names and ports ,etc.
> >>>
> >>> &isp {
> >>> status = "okay";
> >>> };
> >>>
> >> Makes sense, that's why my kernel compilation passed and I didn't
> >> these errors. Thanks for the command, I will verify dts for
> >> correctness in next patch series.
> >>
> >>> Needed to detect missing: power-domains, etc.
> >>>
> >>> &mipi_phy_rx0 {
> >>> status = "okay";
> >>> };
> >>>
> >>>>
> >>>> Reported-by: Karthik Poduval <karthik.poduval@gmail.com>
> >>>> Signed-off-by: Karthik Poduval <karthik.poduval@gmail.com>
> >>>> ---
> >>>> arch/arm/boot/dts/rk3288.dtsi | 25 +++++++++++++++++++++++++
> >>>> 1 file changed, 25 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/rk3288.dtsi
> >> b/arch/arm/boot/dts/rk3288.dtsi
> >>>> index 9beb662166aa..adea8189abd9 100644
> >>>> --- a/arch/arm/boot/dts/rk3288.dtsi
> >>>> +++ b/arch/arm/boot/dts/rk3288.dtsi
> >>>> @@ -247,6 +247,23 @@
> >>>> ports = <&vopl_out>, <&vopb_out>;
> >>>> };
> >>>>
> >>>
> >>>> + isp: isp@ff910000 {
> >>>
> >>> For nodes:
> >>> Sort things without reg alphabetical first,
> >>> then sort the rest by reg address.
> >>>
> >> Sure
> >>>> + compatible = "rockchip,rk3288-rkisp1";
> >>>> + reg = <0x0 0xff910000 0x0 0x4000>;
> >>>> + interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
> >>>> + clocks = <&cru SCLK_ISP>, <&cru ACLK_ISP>,
> >>>> + <&cru HCLK_ISP>, <&cru PCLK_ISP_IN>,
> >>>> + <&cru SCLK_ISP_JPE>;
> >>>> + clock-names = "clk_isp", "aclk_isp",
> >>>> + "hclk_isp", "pclk_isp_in",
> >>>> + "sclk_isp_jpe";
> >>>> + assigned-clocks = <&cru SCLK_ISP>, <&cru SCLK_ISP_JPE>;
> >>>> + assigned-clock-rates = <400000000>, <400000000>;
> >>>
> >>>> + power-domains = <&power RK3288_PD_VIO>;
> >>>> + iommus = <&isp_mmu>;
> >>>
> >>> sort
> >>>
> >>> Something missing?
> >>> Where are the ports and port nodes?
> >>
> >> I was assuming that this would be a part of the board specific dtsi or
> >> dts entry where the isp node would be overriden and the i2c camera
> >> port
> >> and the isp port remote-endpoints would be connected. I had this as a
> >> part of my first patch series. However I was advised by Helen to not
> >> include the ov5647
> >> dtsi as it isn't hardwired to the SoC and resides on an camera adapter
> >> board.
> >>
> >> Should this be defined without the remote-endpoint phandle since we
> >> don't know exactly which sensor gets connected in this dtsi file ?
> >>
> >>>
> >>>> + status = "disabled";
>
> Question for Heiko:
> Should we add status to Helen's serie as well?
>
> >>>> + };
> >>>> +
> >>>> sdmmc: mmc@ff0c0000 {
> >>>> compatible = "rockchip,rk3288-dw-mshc";
> >>>> max-frequency = <150000000>;
> >>>> @@ -891,6 +908,14 @@
> >>>> status = "disabled";
> >>>> };
> >>>>
> >>>
> >>>> + mipi_phy_rx0: mipi-phy-rx0 {
> >>>
> >>> Use separate patch.
> >>>
> >>> For nodes:
> >>> Sort things without reg alphabetical first,
> >>> then sort the rest by reg address.
> >>>
> >> Sure
> >>
> >>>> + compatible = "rockchip,rk3288-mipi-dphy-rx0";
> >>>> + clocks = <&cru SCLK_MIPIDSI_24M>, <&cru
> >> PCLK_MIPI_CSI>;
> >>>> + clock-names = "dphy-ref", "pclk";
> >>> Something missing?
> >>> Does this phy have a power domain?
> >> The tinkerboard debian kernel (where I referred to for this patch)
> >> didn't have it defined for the DPHY. I would guess that it would be
> >> the same as the ISP i.e. RK3288_PD_VIO,
> >> does anyone know the answer to this or do I have to reach out to
> >> Rockchip engineering ?
> >>>
> >>>> + #phy-cells = <0>;
> >>>> + status = "disabled";
> >>>> + };
> >>>> +
> >>>> io_domains: io-domains {
> >>>> compatible = "rockchip,rk3288-io-voltage-domain";
> >>>> status = "disabled";
> >>>>
> >>>
> >>
> >>
> >> --
> >> Regards,
> >> Karthik Poduval
> >>
> >
> >
>
--
Regards,
Karthik Poduval
^ permalink raw reply
* [PATCH 1/1] dt-bindings: rng: Convert OMAP RNG to schema
From: Tero Kristo @ 2020-05-14 13:19 UTC (permalink / raw)
To: robh+dt, devicetree; +Cc: linux-crypto, herbert, mpm
Convert TI OMAP Random number generator bindings to DT schema.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
.../devicetree/bindings/rng/omap_rng.txt | 38 ---------
.../devicetree/bindings/rng/ti,omap-rng.yaml | 77 +++++++++++++++++++
2 files changed, 77 insertions(+), 38 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rng/omap_rng.txt
create mode 100644 Documentation/devicetree/bindings/rng/ti,omap-rng.yaml
diff --git a/Documentation/devicetree/bindings/rng/omap_rng.txt b/Documentation/devicetree/bindings/rng/omap_rng.txt
deleted file mode 100644
index ea434ce50f36..000000000000
--- a/Documentation/devicetree/bindings/rng/omap_rng.txt
+++ /dev/null
@@ -1,38 +0,0 @@
-OMAP SoC and Inside-Secure HWRNG Module
-
-Required properties:
-
-- compatible : Should contain entries for this and backward compatible
- RNG versions:
- - "ti,omap2-rng" for OMAP2.
- - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
- - "inside-secure,safexcel-eip76" for SoCs with EIP76 IP block
- Note that these two versions are incompatible.
-- ti,hwmods: Name of the hwmod associated with the RNG module
-- reg : Offset and length of the register set for the module
-- interrupts : the interrupt number for the RNG module.
- Used for "ti,omap4-rng" and "inside-secure,safexcel-eip76"
-- clocks: the trng clock source. Only mandatory for the
- "inside-secure,safexcel-eip76" compatible, the second clock is
- needed for the Armada 7K/8K SoCs
-- clock-names: mandatory if there is a second clock, in this case the
- name must be "core" for the first clock and "reg" for the second
- one
-
-
-Example:
-/* AM335x */
-rng: rng@48310000 {
- compatible = "ti,omap4-rng";
- ti,hwmods = "rng";
- reg = <0x48310000 0x2000>;
- interrupts = <111>;
-};
-
-/* SafeXcel IP-76 */
-trng: rng@f2760000 {
- compatible = "inside-secure,safexcel-eip76";
- reg = <0xf2760000 0x7d>;
- interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpm_syscon0 1 25>;
-};
diff --git a/Documentation/devicetree/bindings/rng/ti,omap-rng.yaml b/Documentation/devicetree/bindings/rng/ti,omap-rng.yaml
new file mode 100644
index 000000000000..b37d73295e9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/ti,omap-rng.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/ti,omap-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP SoC and Inside-Secure HWRNG Module
+
+maintainers:
+ - Tero Kristo <t-kristo@ti.com>
+
+properties:
+ compatible:
+ enum:
+ - ti,omap2-rng
+ - ti,omap4-rng
+ - inside-secure,safexcel-eip76
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ description:
+ The TRNG clock source. Only mandatory for the
+ "inside-secure,safexcel-eip76" compatible, the second clock is needed
+ for the Armada 7K/8K SoCs
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: reg
+
+ ti,hwmods:
+ description: TI hwmod name
+ deprecated: true
+ $ref: /schemas/types.yaml#/definitions/string-array
+ items:
+ const: rng
+
+required:
+ - compatible
+ - reg
+
+if:
+ properties:
+ compatible:
+ enum:
+ - inside-secure,safexcel-eip76
+then:
+ required:
+ - clocks
+
+examples:
+ - |
+ /* AM335x */
+ rng: rng@48310000 {
+ compatible = "ti,omap4-rng";
+ ti,hwmods = "rng";
+ reg = <0x48310000 0x2000>;
+ interrupts = <111>;
+ };
+
+ - |+
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ /* SafeXcel IP-76 */
+ trng: rng@f2760000 {
+ compatible = "inside-secure,safexcel-eip76";
+ reg = <0xf2760000 0x7d>;
+ interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpm_syscon0 1 25>;
+ };
+...
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
* Re: [PATCH 4/7] dt-bindings: pinctrl: realtek: Add Realtek DHC SoC rtd1195 and rtd1295.
From: Rob Herring @ 2020-05-14 13:24 UTC (permalink / raw)
To: TY Chang
Cc: linux-realtek-soc, afaerber, linus.walleij, linux-gpio,
devicetree, linux-kernel
In-Reply-To: <20200514092125.6875-5-tychang@realtek.com>
On Thu, May 14, 2020 at 05:21:22PM +0800, TY Chang wrote:
> Add compatible string for RTD1195 and RTD1295.
>
> Signed-off-by: TY Chang <tychang@realtek.com>
> ---
> .../bindings/pinctrl/realtek,rtd-pinctrl.yaml | 59 +++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/realtek,rtd-pinctrl.yaml
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/realtek,rtd-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/realtek,rtd-pinctrl.yaml
> new file mode 100644
> index 000000000000..5af5fc8fe633
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/realtek,rtd-pinctrl.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/realtek,rtd-pinctrl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Realtek DHC pin control
> +
> +maintainers:
> + - Andreas Farber <afaerber@suse.de>
> +
> +properties:
> + compatible:
> + enum:
> + - realtek,rtd1195-iso-pinctrl
> + - realtek,rtd1195-crt-pinctrl
> + - realtek,rtd1295-iso-pinctrl
> + - realtek,rtd1295-sb2-pinctrl
> + - realtek,rtd1295-disp-pinctrl
> + - realtek,rtd1295-cr-pinctrl
> + reg:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> + iso_pinctrl: pinctrl@300 {
> + compatible = "realtek,rtd1195-iso-pinctrl";
> + reg = <0x300 0x14>;
Aren't there child nodes with pin settings? They need to be documented.
> + }
> + - |
> + crt_pinctrl: pinctrl@300 {
> + compatible = "realtek,rtd1195-crt-pinctrl";
> + reg = <0x300 0x78>;
> + }
> + - |
> + iso_pinctrl: pinctrl@300 {
> + compatible = "realtek,rtd1295-iso-pinctrl";
> + reg = <0x300 0x24>;
> + }
> + - |
> + sb2_pinctrl: pinctrl@900 {
> + compatible = "realtek,rtd1295-sb2-pinctrl";
> + reg = <0x900 0x100>;
> + }
> + - |
> + disp_pinctrl: pinctrl@4d000 {
> + compatible = "realtek,rtd1295-disp-pinctrl";
> + reg = <0x4d000 0x100>;
> + };
> + - |
> + cr_pinctrl: pinctrl@12600 {
> + compatible = "realtek,rtd1295-cr-pinctrl";
> + reg = <0x12600 0x100>;
> + };
> +
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: db820c: Fix invalid pm8994 supplies
From: Vinod Koul @ 2020-05-14 13:38 UTC (permalink / raw)
To: Bjorn Andersson; +Cc: Andy Gross, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20200417070712.1376355-1-bjorn.andersson@linaro.org>
On 17-04-20, 00:07, Bjorn Andersson wrote:
> It's uncertain where the "vreg_s8a_l3a_input" comes from, but the supply
> for VDD_L3_L11 on PM8994 should be VREG_S3A_1P3, so correct this - and
> drop the vreg_s8a_l3a_input.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: db820c: Add pmi8994 RPM regulators
From: Vinod Koul @ 2020-05-14 13:40 UTC (permalink / raw)
To: Bjorn Andersson; +Cc: Andy Gross, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20200417070303.1376290-1-bjorn.andersson@linaro.org>
On 17-04-20, 00:03, Bjorn Andersson wrote:
> The PMI8994 provides 3 SPMS regulators and one boost/bypass regulator.
> Define s1 and the boot/bypass and update pm8994 to appropriately
> describe the supply from PMI8994.
Reviewed-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH 00/15] Fix STM32 DT issues on v5.7-rc4
From: Alexandre Torgue @ 2020-05-14 13:42 UTC (permalink / raw)
To: Benjamin Gaignard, linus.walleij, robh+dt, mcoquelin.stm32,
gregkh
Cc: linux-gpio, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, linux-usb
In-Reply-To: <20200513145935.22493-1-benjamin.gaignard@st.com>
Hi Benjamin
On 5/13/20 4:59 PM, Benjamin Gaignard wrote:
> This series fixes issues hight lighted by dtbs_check on STM32 devicetrees.
> The patches has been developped on top of v5.7-rc4 tag.
>
> Benjamin Gaignard (15):
> ARM: dts: stm32: remove useless interrupt-names property on stm32f429
> ARM: dts: stm32: update pwm pinctrl node names for stm32f4
> ARM: dts: stm32: update led nodes names for stm32f249-disco
> ARM: dts: stm32: update led nodes names for stm32f469-disco
> ARM: dts: stm32: remove useless interrupt-names property on stm32f746
> ARM: dts: stm32: update led nodes names for stm32f429-eval
> ARM: dts: stm32: update led nodes names for stm32f769-disco
> ARM: dts: stm32: update led nodes names for stm32f746-eval
> ARM: dts: stm32: remove useless interrupt-names property on stm32f743
> ARM: dts: stm32: Update nodes names for stm32h743 pinctrl
> ARM: dts: stm32: Update nodes names for stm32mp15 pinctrl
> ARM: dts: stm32: Add missing #address and #size cells on spi node for
> stm32mp151
> ARM: dts: stm32: update led nodes names for stm32f746-eval
> dt-bindings: pinctrl: stm32: Add missing interrupts property
> dt-bindings: usb: dwc2: Fix issues for stm32mp15x SoC
For dts(i) part, it looks good to me. I let Rob to review before taking
the whole series.
thanks
alex
>
> .../devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml | 3 +++
> Documentation/devicetree/bindings/usb/dwc2.yaml | 6 ++++--
> arch/arm/boot/dts/stm32429i-eval.dts | 8 ++++----
> arch/arm/boot/dts/stm32746g-eval.dts | 8 ++++----
> arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 4 ++--
> arch/arm/boot/dts/stm32f429-disco.dts | 4 ++--
> arch/arm/boot/dts/stm32f429.dtsi | 1 -
> arch/arm/boot/dts/stm32f469-disco.dts | 8 ++++----
> arch/arm/boot/dts/stm32f746.dtsi | 1 -
> arch/arm/boot/dts/stm32f769-disco.dts | 4 ++--
> arch/arm/boot/dts/stm32h743-pinctrl.dtsi | 10 +++++-----
> arch/arm/boot/dts/stm32h743.dtsi | 1 -
> arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 6 +++---
> arch/arm/boot/dts/stm32mp151.dtsi | 2 ++
> arch/arm/boot/dts/stm32mp15xx-dkx.dtsi | 2 +-
> 15 files changed, 36 insertions(+), 32 deletions(-)
>
^ 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