* Re: [PATCH v4 2/6] dt-bindings: interrupt-controller: Add Loongson HTVEC
From: Marc Zyngier @ 2020-05-25 10:12 UTC (permalink / raw)
To: Jiaxun Yang, Rob Herring
Cc: Thomas Gleixner, Jason Cooper, Huacai Chen, linux-kernel,
devicetree, linux-mips
In-Reply-To: <20200516082912.3673033-2-jiaxun.yang@flygoat.com>
On Sat, 16 May 2020 09:29:02 +0100,
Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
> Add binding for Loongson-3 HyperTransport Interrupt Vector Controller.
>
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> --
> v4: Drop ref, '|', add additionalProperties, fix example
Rob, do you have any input on this?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node
From: Jonathan Marek @ 2020-05-25 10:09 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
devicetree, linux-kernel, linux-arm-msm-owner
In-Reply-To: <42f39eeb2af9c82a551a417c62ea21d7@codeaurora.org>
Hi,
On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
> Hi Jonathan,
>
> On 2020-05-24 08:08, Jonathan Marek wrote:
>> Add the apps_smmu node for sm8250. Note that adding the iommus field for
>> UFS is required because initializing the iommu removes the bypass mapping
>> that created by the bootloader.
>>
>
> This statement doesn't seem right, you can just say since the bypass is
> disabled
> by default now, we need to add this property to enable translation and
> avoid global faults.
>
If I use this patch [1] then the UFS iommu property isn't needed. In
downstream, the identity (bypass?) stream mapping is inherited from the
bootloader, and UFS is used without any iommu property. Setting
ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its own
(without the UFS iommu property), so there's more to it than just
"bypass is disabled by default now".
https://patchwork.kernel.org/patch/11310757/
>> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
>> ---
>> arch/arm64/boot/dts/qcom/sm8250.dtsi | 107 +++++++++++++++++++++++++++
>> 1 file changed, 107 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> index 2f99c350c287..43c5e48c15e2 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> @@ -323,6 +323,8 @@ ufs_mem_hc: ufshc@1d84000 {
>>
>> power-domains = <&gcc UFS_PHY_GDSC>;
>>
>> + iommus = <&apps_smmu 0x0e0 0>, <&apps_smmu 0x4e0 0>;
>> +
>> clock-names =
>> "core_clk",
>> "bus_aggr_clk",
>> @@ -428,6 +430,111 @@ tlmm: pinctrl@f100000 {
>> wakeup-parent = <&pdc>;
>> };
>>
>> + apps_smmu: iommu@15000000 {
>> + compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
>
> This should be qcom,sm8250-smmu-500 and also you need to update the
> arm-smmu
> binding with this compatible in a separate patch.
>
> -Sai
>
^ permalink raw reply
* Re: [PATCH 4/8] dt-bindings: dmaengine: renesas,usb-dmac: Add binding for r8a7742
From: Geert Uytterhoeven @ 2020-05-25 10:05 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-5-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:40 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: usb: renesas,usbhs: Add support for r8a7742
From: Geert Uytterhoeven @ 2020-05-25 10:04 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-4-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:39 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Document support for RZ/G1H (R8A7742) SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/8] dt-bindings: PCI: pci-rcar-gen2: Add device tree support for r8a7742
From: Geert Uytterhoeven @ 2020-05-25 10:03 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-3-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:39 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add internal PCI bridge support for r8a7742 SoC. The Renesas RZ/G1H
> (R8A7742) internal PCI bridge is identical to the R-Car Gen2 family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/8] dt-bindings: phy: rcar-gen2: Add r8a7742 support
From: Geert Uytterhoeven @ 2020-05-25 10:01 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Vinod Koul, Rob Herring, Bjorn Helgaas, Kishon Vijay Abraham I,
Greg Kroah-Hartman, Magnus Damm, dmaengine, linux-pci, USB list,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux Kernel Mailing List, Prabhakar
In-Reply-To: <1590356277-19993-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, May 24, 2020 at 11:38 PM Lad Prabhakar
<prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> Add USB PHY support for r8a7742 SoC. Renesas RZ/G1H (R8A7742)
> USB PHY is identical to the R-Car Gen2 family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node
From: Sai Prakash Ranjan @ 2020-05-25 9:42 UTC (permalink / raw)
To: Jonathan Marek
Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
devicetree, linux-kernel, linux-arm-msm-owner
In-Reply-To: <20200524023815.21789-3-jonathan@marek.ca>
Hi Jonathan,
On 2020-05-24 08:08, Jonathan Marek wrote:
> Add the apps_smmu node for sm8250. Note that adding the iommus field
> for
> UFS is required because initializing the iommu removes the bypass
> mapping
> that created by the bootloader.
>
This statement doesn't seem right, you can just say since the bypass is
disabled
by default now, we need to add this property to enable translation and
avoid global faults.
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
> arch/arm64/boot/dts/qcom/sm8250.dtsi | 107 +++++++++++++++++++++++++++
> 1 file changed, 107 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index 2f99c350c287..43c5e48c15e2 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -323,6 +323,8 @@ ufs_mem_hc: ufshc@1d84000 {
>
> power-domains = <&gcc UFS_PHY_GDSC>;
>
> + iommus = <&apps_smmu 0x0e0 0>, <&apps_smmu 0x4e0 0>;
> +
> clock-names =
> "core_clk",
> "bus_aggr_clk",
> @@ -428,6 +430,111 @@ tlmm: pinctrl@f100000 {
> wakeup-parent = <&pdc>;
> };
>
> + apps_smmu: iommu@15000000 {
> + compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
This should be qcom,sm8250-smmu-500 and also you need to update the
arm-smmu
binding with this compatible in a separate patch.
-Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node
From: Sai Prakash Ranjan @ 2020-05-25 9:37 UTC (permalink / raw)
To: Jonathan Marek
Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, Rob Herring,
devicetree, linux-kernel, devicetree-owner
In-Reply-To: <20200524023815.21789-2-jonathan@marek.ca>
Hi Jonathan,
On 2020-05-24 08:08, Jonathan Marek wrote:
> Add the apps_smmu node for sm8150. Note that adding the iommus field
> for
> UFS is required because initializing the iommu removes the bypass
> mapping
> that created by the bootloader.
>
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
> arch/arm64/boot/dts/qcom/sm8150.dtsi | 91 ++++++++++++++++++++++++++++
> 1 file changed, 91 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> index a36512d1f6a1..acb839427b12 100644
> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> @@ -442,6 +442,8 @@ ufs_mem_hc: ufshc@1d84000 {
> resets = <&gcc GCC_UFS_PHY_BCR>;
> reset-names = "rst";
>
> + iommus = <&apps_smmu 0x300 0>;
> +
> clock-names =
> "core_clk",
> "bus_aggr_clk",
> @@ -706,6 +708,7 @@ usb_1_dwc3: dwc3@a600000 {
> compatible = "snps,dwc3";
> reg = <0 0x0a600000 0 0xcd00>;
> interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
> + iommus = <&apps_smmu 0x140 0>;
> snps,dis_u2_susphy_quirk;
> snps,dis_enblslpm_quirk;
> phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
> @@ -742,6 +745,94 @@ spmi_bus: spmi@c440000 {
> cell-index = <0>;
> };
>
> + apps_smmu: iommu@15000000 {
> + compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
This should be qcom,sm8150-smmu-500 and also you need to update the
arm-smmu
binding with this compatible in a separate patch.
-Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH] arm: dts: am33xx-bone-common: add gpio-line-names
From: Linus Walleij @ 2020-05-25 9:23 UTC (permalink / raw)
To: Drew Fustini
Cc: Grygorii Strashko, Benoît Cousson, Tony Lindgren,
Rob Herring, Linux-OMAP,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, Jason Kridner, Robert Nelson
In-Reply-To: <20200520220203.GA363398@x1>
On Thu, May 21, 2020 at 12:02 AM Drew Fustini <drew@beagleboard.org> wrote:
> I've posted a v2 which I hope improves the intent of the line names. [0]
>
> I'm happy to integrate any feedback and create a v3 - especially if it
> is prefered for me to list the specific peripherial signals instead of
> an abstract term like "[ethernet]" or "[emmc]". This is for lines that
> can not be used because they are not routed to the expansion headers.
>
> [0] https://lore.kernel.org/linux-omap/20200520214757.GA362547@x1/T/#u
This looks good to me. FWIW
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] dt-bindings: gpio: Add renesas,em-gio bindings
From: Linus Walleij @ 2020-05-25 9:14 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bartosz Golaszewski, Rob Herring, Magnus Damm,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Linux-Renesas
In-Reply-To: <20200519081157.29095-1-geert+renesas@glider.be>
On Tue, May 19, 2020 at 10:11 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Document Device Tree bindings for the Renesas EMMA Mobile General
> Purpose I/O Interface.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Pretty uncontroversial patch and you know what you're doing so
patch applied with Niklas' review tag.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: net: meson-dwmac: Add the amlogic,rx-delay-ns property
From: Pavel Machek @ 2020-05-25 9:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: Martin Blumenstingl, robh+dt, andrew, linux-amlogic, devicetree,
jianxin.pan, davem, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <d3f596d7-fb7f-5da7-4406-b5c0e9e9dc3f@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]
Hi!
> > On Tue 2020-05-12 23:10:56, Martin Blumenstingl wrote:
> >> The PRG_ETHERNET registers on Meson8b and newer SoCs can add an RX
> >> delay. Add a property with the known supported values so it can be
> >> configured according to the board layout.
> >>
> >> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> >> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> >> ---
> >> .../bindings/net/amlogic,meson-dwmac.yaml | 13 +++++++++++++
> >> 1 file changed, 13 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> >> index ae91aa9d8616..66074314e57a 100644
> >> --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> >> +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> >> @@ -67,6 +67,19 @@ allOf:
> >> PHY and MAC are adding a delay).
> >> Any configuration is ignored when the phy-mode is set to "rmii".
> >>
> >> + amlogic,rx-delay-ns:
> >> + enum:
> >
> > Is it likely other MACs will need rx-delay property, too? Should we get rid of the amlogic,
> > prefix?
>
> Yes, there are several MAC bindings that already define a delay property:
>
> Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml:
> allwinner,rx-delay-ps:
> Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml:
> allwinner,rx-delay-ps:
> Documentation/devicetree/bindings/net/apm-xgene-enet.txt:- rx-delay:
> Delay value for RGMII bridge RX clock.
> Documentation/devicetree/bindings/net/apm-xgene-enet.txt: rx-delay
> = <2>;
> Documentation/devicetree/bindings/net/cavium-pip.txt:- rx-delay: Delay
> value for RGMII receive clock. Optional. Disabled if 0.
> Documentation/devicetree/bindings/net/mediatek-dwmac.txt:-
> mediatek,rx-delay-ps: RX clock delay macro value. Default is 0.
> Documentation/devicetree/bindings/net/mediatek-dwmac.txt:
> mediatek,rx-delay-ps = <1530>;
>
> standardizing on rx-delay-ps and tx-delay-ps would make sense since that
> is the lowest resolution and the property would be correctly named with
> an unit in the name.
Seems like similar patch is already being reviewed from Dan Murphy (?)
from TI.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH v3 10/16] gpio: add a reusable generic gpio_chip using regmap
From: Bartosz Golaszewski @ 2020-05-25 9:05 UTC (permalink / raw)
To: Michael Walle
Cc: Andy Shevchenko, linux-gpio, linux-devicetree, LKML, linux-hwmon,
linux-pwm, LINUXWATCHDOG, arm-soc, Linus Walleij, Rob Herring,
Jean Delvare, Guenter Roeck, Lee Jones, Thierry Reding,
Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Mark Brown,
Greg Kroah-Hartman
In-Reply-To: <75bff2917be1badd36af9f980cf59d2c@walle.cc>
wt., 12 maj 2020 o 16:41 Michael Walle <michael@walle.cc> napisał(a):
>
> >> +
> >> +MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
> >> +MODULE_DESCRIPTION("GPIO generic regmap driver core");
> >> +MODULE_LICENSE("GPL");
> >> diff --git a/include/linux/gpio-regmap.h b/include/linux/gpio-regmap.h
> >> new file mode 100644
> >> index 000000000000..a868cbcde6e9
> >> --- /dev/null
> >> +++ b/include/linux/gpio-regmap.h
> >> @@ -0,0 +1,69 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only */
> >> +
> >> +#ifndef _LINUX_GPIO_REGMAP_H
> >> +#define _LINUX_GPIO_REGMAP_H
> >> +
> >> +struct gpio_regmap;
> >> +
> >> +#define GPIO_REGMAP_ADDR_ZERO ((unsigned long)(-1))
> >> +#define GPIO_REGMAP_ADDR(addr) ((addr) ? : GPIO_REGMAP_ADDR_ZERO)
> >> +
> >
> > What if the addr is actually 0?
>
> Then the driver has to set GPIO_REGMAP_ADDR_ZERO or use the convenience
> macro GPIO_REGMAP_ADDR.
>
> So you can have
>
> struct gpio_regmap_config config = { 0 };
> config.reg_dat_base = 0x10;
> config.reg_dir_out_base = 0x20;
>
> or
>
> config.reg_dat_base = GPIO_REGMAP_ADDR_ZERO;
>
> or if you can't be sure if the RHS value might be zero:
>
> config.reg_dat_base = GPIO_REGMAP_ADDR(reg);
>
>
> > Maybe drop GPIO_REGMAP_ADDR and require users to set unused registers
> > to GPIO_REGMAP_ADDR_ZERO?
>
> Thats bad because:
> * you'd have to set plenty of unused base registers for a simple driver
> * if there will be additional properties in the future, you have to
> touch
> all other drivers, because they are initialized as 0 (ie. valid reg
> 0).
>
> >> +/**
> >> + * struct gpio_regmap_config - Description of a generic regmap
> >> gpio_chip.
> >> + *
> >> + * @parent: The parent device
> >> + * @regmap: The regmap used to access the registers
> >> + * given, the name of the device is used
> >> + * @label: (Optional) Descriptive name for GPIO
> >> controller.
> >> + * If not given, the name of the device is used.
> >> + * @ngpio: Number of GPIOs
> >> + * @reg_dat_base: (Optional) (in) register base address
> >> + * @reg_set_base: (Optional) set register base address
> >> + * @reg_clr_base: (Optional) clear register base address
> >> + * @reg_dir_in_base: (Optional) out setting register base address
> >> + * @reg_dir_out_base: (Optional) in setting register base address
> >
> > The two above are inverted I think?
> good catch.
>
> > Also: why the limitation of only supporting one at a time?
>
> they should be exclusive, either you have a register where you set the
> output bits to one, or the input bits. Maybe this need a bit more
> context
> above. in gpio-mmio.c you can set both and both are used in
> set_direction(), but only one is read in get_direction().
>
> That being said, I have no strong opinion wether they should be
> exclusive
> or not, besides the symmetry of set_/get_direction().
>
> -michael
>
Sorry for the late response, your comments make sense to me. Are you
going to submit a v4 before the v5.8 merge window?
Bart
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pinctrl: Add bindings for mscc,ocelot-sgpio
From: Linus Walleij @ 2020-05-25 8:50 UTC (permalink / raw)
To: Lars Povlsen
Cc: SoC Team, Rob Herring, Microchip Linux Driver Support,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Linux ARM, linux-kernel@vger.kernel.org,
Alexandre Belloni
In-Reply-To: <87pnb1nf2j.fsf@soft-dev15.microsemi.net>
On Mon, May 18, 2020 at 10:50 PM Lars Povlsen
<lars.povlsen@microchip.com> wrote:
> Linus Walleij writes:
>
> > On Wed, May 13, 2020 at 4:11 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
> >
> >> This adds DT bindings for the Microsemi SGPIO controller, bindings
> >> mscc,ocelot-sgpio and mscc,luton-sgpio.
> >>
> >> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> >> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> >
> >> + microchip,sgpio-ports:
> >> + description: This is a 32-bit bitmask, configuring whether a
> >> + particular port in the controller is enabled or not. This allows
> >> + unused ports to be removed from the bitstream and reduce latency.
> >> + $ref: "/schemas/types.yaml#/definitions/uint32"
> >
> > I don't know about this.
> >
> > You are saying this pin controller can have up to 32 GPIO "ports"
> > (also known as banks).
> >
> > Why can't you just represent each such port as a separate GPIO
> > node:
> >
> > pinctrl@nnn {
> > gpio@0 {
> > ....
> > };
> > gpio@1 {
> > ....
> > };
> > ....
> > gpio@31 {
> > ....
> > };
> > };
> >
> > Then if some of them are unused just set it to status = "disabled";
> >
> > This also makes your Linux driver simpler because each GPIO port
> > just becomes a set of 32bit registers and you can use
> > select GPIO_GENERIC and bgpio_init() and save a whole
> > slew of standard stock code.
> >
>
> Linus, thank you for your input.
>
> The controller handles an array of 32*n signals, where n >= 1 && n <=
> 4.
>
> The problem with the above approach is that the ports are disabled
> *port*-wise - so they remove all (upto) 4 bits. That would be across the
> banks.
>
> You could of course have the "implied" semantics that a disabled port at
> any bit position disabled all (bit positions for the same port).
I don't understand this, you would have to elaborate...
In any case microchip,sgpio-ports is probably not the right thing,
use ngpios which is documented and just divide by 32 to get the
number of ports I think? But that is just in case they get
enabled strictly in sequence, otherwise you'd need a custom
property.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
From: Martin Kepplinger @ 2020-05-25 8:47 UTC (permalink / raw)
To: robh, kernel, shawnguo, s.hauer, kernel, festevam, linux-imx,
mchehab, Anson.Huang, agx, angus
Cc: linux-kernel, devicetree, linux-arm-kernel
In-Reply-To: <20200514155737.12160-1-martin.kepplinger@puri.sm>
On 14.05.20 17:57, Martin Kepplinger wrote:
> From: "Angus Ainslie (Purism)" <angus@akkea.ca>
>
> Add a devicetree description for the Librem 5 phone. The early batches
> that have been sold are supported as well as the mass-produced device
> available later this year, see https://puri.sm/products/librem-5/
>
> This boots to a working console with working WWAN modem, wifi usdhc,
> IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm>
> Signed-off-by: Angus Ainslie (Purism) <angus@akkea.ca>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 1 +
> .../boot/dts/freescale/imx8mq-librem5.dts | 1174 +++++++++++++++++
> 2 files changed, 1175 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx8mq-librem5.dts
>
hi,
I highly appreciate it in case you can take time to review. It's not the
smallest board, but this "base" support isn't huge either. For
devicetree people this is certainly easy to read and I'll be happy for
any opinions, objections or Acks you might have.
thanks,
martin
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
From: Linus Walleij @ 2020-05-25 8:43 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel@vger.kernel.org, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jonathan Cameron,
Lars-Peter Clausen, open list:IIO SUBSYSTEM AND DRIVERS,
Peter Meerwald-Stadler, Steve Winslow, Thomas Gleixner,
Jonathan Cameron, Rob Herring
In-Reply-To: <20200518133645.19127-3-jonathan.albrieux@gmail.com>
On Mon, May 18, 2020 at 3:37 PM Jonathan Albrieux
<jonathan.albrieux@gmail.com> wrote:
> + reset-gpio:
> + description: an optional pin needed for AK09911 to set the reset state
This kind of properties should always be plural, so
reset-gpios please.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 09/13] soc: mediatek: cmdq: add write_s value function
From: Matthias Brugger @ 2020-05-25 8:39 UTC (permalink / raw)
To: Dennis-YC Hsieh
Cc: Rob Herring, Mark Rutland, Jassi Brar, Philipp Zabel,
David Airlie, Daniel Vetter, linux-kernel, linux-mediatek,
devicetree, wsd_upstream, dri-devel, Bibby Hsieh, CK Hu,
Houlong Wei, linux-arm-kernel, HS Liao
In-Reply-To: <1590373621.31522.7.camel@mtkswgap22>
On 25/05/2020 04:27, Dennis-YC Hsieh wrote:
>
> On Sun, 2020-05-24 at 20:13 +0200, Matthias Brugger wrote:
>>
>> On 24/05/2020 19:31, Dennis-YC Hsieh wrote:
>>> Hi Matthias,
>>>
>>> Thanks for your comment.
>>>
>>> On Sat, 2020-05-16 at 20:20 +0200, Matthias Brugger wrote:
>>>>
>>>> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
>>>>> add write_s function in cmdq helper functions which
>>>>> writes a constant value to address with large dma
>>>>> access support.
>>>>>
>>>>> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
>>>>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
>>>>> ---
>>>>> drivers/soc/mediatek/mtk-cmdq-helper.c | 26 ++++++++++++++++++++++++++
>>>>> include/linux/soc/mediatek/mtk-cmdq.h | 14 ++++++++++++++
>>>>> 2 files changed, 40 insertions(+)
>>>>>
>>>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>>>> index 03c129230cd7..a9ebbabb7439 100644
>>>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
>>>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>>>> @@ -269,6 +269,32 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> }
>>>>> EXPORT_SYMBOL(cmdq_pkt_write_s);
>>>>>
>>>>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> + u16 addr_low, u32 value, u32 mask)
>>>>> +{
>>>>> + struct cmdq_instruction inst = { {0} };
>>>>> + int err;
>>>>> +
>>>>> + if (mask != U32_MAX) {
>>>>> + inst.op = CMDQ_CODE_MASK;
>>>>> + inst.mask = ~mask;
>>>>> + err = cmdq_pkt_append_command(pkt, inst);
>>>>> + if (err < 0)
>>>>> + return err;
>>>>> +
>>>>> + inst.op = CMDQ_CODE_WRITE_S_MASK;
>>>>> + } else {
>>>>> + inst.op = CMDQ_CODE_WRITE_S;
>>>>> + }
>>>>> +
>>>>> + inst.sop = high_addr_reg_idx;
>>>>
>>>> Writing u16 value in a 5 bit wide variable?
>>>
>>> We need only 5 bits in this case. I'll change high_addr_reg_idx
>>> parameter to u8.
>>>
>>
>> Ok, please make sure to mask the value, so that it's explicit in the code that
>> we only use the lowest 5 bits of high_addr_reg_idx.
>
> Is it necessary to mask the value?
> Since sop already defined as "u8 sop:5;", I thought it is explicit that
> only use 5 bits and compiler should do the rest jobs.
Yes but it makes the code more explicit if we have a
inst.sop = high_addr_reg_idx & 0x1f;
What do you think?
Regards,
Matthias
>
>
> Regards,
> Dennis
>
>>
>> Regards,
>> Matthias
>>
>>>>
>>>>> + inst.offset = addr_low;
>>>>> + inst.value = value;
>>>>> +
>>>>> + return cmdq_pkt_append_command(pkt, inst);
>>>>> +}
>>>>> +EXPORT_SYMBOL(cmdq_pkt_write_s_value);
>>>>> +
>>>>> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
>>>>> {
>>>>> struct cmdq_instruction inst = { {0} };
>>>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
>>>>> index 01b4184af310..fec292aac83c 100644
>>>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
>>>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
>>>>> @@ -135,6 +135,20 @@ int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
>>>>> int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> u16 addr_low, u16 src_reg_idx, u32 mask);
>>>>>
>>>>> +/**
>>>>> + * cmdq_pkt_write_s_value() - append write_s command with mask to the CMDQ
>>>>> + * packet which write value to a physical address
>>>>> + * @pkt: the CMDQ packet
>>>>> + * @high_addr_reg_idx: internal regisger ID which contains high address of pa
>>>>
>>>> register
>>>
>>> will fix
>>>
>>>
>>> Regards,
>>> Dennis
>>>
>>>>
>>>>> + * @addr_low: low address of pa
>>>>> + * @value: the specified target value
>>>>> + * @mask: the specified target mask
>>>>> + *
>>>>> + * Return: 0 for success; else the error code is returned
>>>>> + */
>>>>> +int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
>>>>> + u16 addr_low, u32 value, u32 mask);
>>>>> +
>>>>> /**
>>>>> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
>>>>> * @pkt: the CMDQ packet
>>>>>
>>>
>
^ permalink raw reply
* Re: [PATCH 4/4] arm64: allwinner: A100: add support for Allwinner Perf1 board
From: Maxime Ripard @ 2020-05-22 15:31 UTC (permalink / raw)
To: Frank Lee
Cc: wens, robh+dt, mturquette, sboyd, linus.walleij, p.zabel,
huangshuosheng, tiny.windzz, linux-arm-kernel, devicetree,
linux-kernel, linux-clk, linux-gpio
In-Reply-To: <20200522030743.10204-5-frank@allwinnertech.com>
[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]
Hi,
On Fri, May 22, 2020 at 11:07:43AM +0800, Frank Lee wrote:
> A100 perf1 is an Allwinner A100-based SBC, with the following features:
>
> - 1GiB DDR3 DRAM
> - AXP803 PMIC
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - on-board Nand flash
> - ···
>
> Adds initial support for it, including the UART.
>
> Signed-off-by: Frank Lee <frank@allwinnertech.com>
Which bootloader have you used to test this?
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../allwinner/sun50i-a100-allwinner-perf1.dts | 27 +++++++++++++++++++
> 2 files changed, 28 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index e4d3cd0ac5bb..ab780dbdd17b 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -14,6 +14,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-bananapi-m2-plus-v1.2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-emlid-neutis-n5-devboard.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> new file mode 100644
> index 000000000000..32c9986920ed
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (c) 2020 Frank Lee <frank@allwinner.com>
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a100.dtsi"
> +
> +/{
> + model = "A100 perf1";
Having the same casing and the "brand" would be great here, so something like
"Allwinner A100 Perf1", or just Perf1 if that name is only ever going to be used
on the A100
> + compatible = "allwinner,a100-perf1", "allwinner,sun50i-a100";
This binding needs to be documented
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] pinctrl: sunxi: add support for the Allwinner A100 pin controller
From: Maxime Ripard @ 2020-05-22 15:28 UTC (permalink / raw)
To: Frank Lee
Cc: wens, robh+dt, mturquette, sboyd, linus.walleij, p.zabel,
huangshuosheng, tiny.windzz, linux-arm-kernel, devicetree,
linux-kernel, linux-clk, linux-gpio
In-Reply-To: <20200522030743.10204-3-frank@allwinnertech.com>
[-- Attachment #1: Type: text/plain, Size: 35314 bytes --]
Hi,
On Fri, May 22, 2020 at 11:07:41AM +0800, Frank Lee wrote:
> This commit introduces support for the pin controller on A100.
>
> Signed-off-by: Frank Lee <frank@allwinnertech.com>
> ---
> drivers/pinctrl/sunxi/Kconfig | 10 +
> drivers/pinctrl/sunxi/Makefile | 2 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c | 105 +++
> drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c | 710 ++++++++++++++++++
This will need a DT binding too, and please make sure to run checkpatch with
--strict, you have a bunch of misaligned parenthesis.
> 4 files changed, 827 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
>
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index f7aae200ee15..593293584ecc 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -94,6 +94,16 @@ config PINCTRL_SUN50I_A64_R
> default ARM64 && ARCH_SUNXI
> select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_A100
> + bool "Support for the Allwinner A100 PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> +config PINCTRL_SUN50I_A100_R
> + bool "Support for the Allwinner A100 R-PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> config PINCTRL_SUN50I_H5
> bool "Support for the Allwinner H5 PIO"
> default ARM64 && ARCH_SUNXI
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index fafcdae8134f..8b7ff0dc3bdf 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -13,6 +13,8 @@ obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_A33) += pinctrl-sun8i-a33.o
> obj-$(CONFIG_PINCTRL_SUN50I_A64) += pinctrl-sun50i-a64.o
> obj-$(CONFIG_PINCTRL_SUN50I_A64_R) += pinctrl-sun50i-a64-r.o
> +obj-$(CONFIG_PINCTRL_SUN50I_A100) += pinctrl-sun50i-a100.o
> +obj-$(CONFIG_PINCTRL_SUN50I_A100_R) += pinctrl-sun50i-a100-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
> obj-$(CONFIG_PINCTRL_SUN8I_A83T_R) += pinctrl-sun8i-a83t-r.o
> obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
> new file mode 100644
> index 000000000000..d38d8770c9da
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100-r.c
> @@ -0,0 +1,105 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Frank Lee <frank@allwinner.com>
> + *
> + * Based on:
> + * huangshuosheng <huangshuosheng@allwinnertech.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/pinctrl.h>
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin a100_r_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c0"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c0"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_uart0"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_uart0"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* MS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* CK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* DO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_jtag"), /* DI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c1"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_i2c1"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_pwm"),
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "s_cpu"), /* CUR_W */
> + SUNXI_FUNCTION(0x3, "s_cir"), /* IN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)),
> +};
> +
> +static const struct sunxi_pinctrl_desc a100_r_pinctrl_data = {
> + .pins = a100_r_pins,
> + .npins = ARRAY_SIZE(a100_r_pins),
> + .pin_base = PL_BASE,
> + .irq_banks = 1,
> +};
> +
> +static int a100_r_pinctrl_probe(struct platform_device *pdev)
> +{
> + return sunxi_pinctrl_init(pdev, &a100_r_pinctrl_data);
> +}
> +
> +static const struct of_device_id a100_r_pinctrl_match[] = {
> + { .compatible = "allwinner,sun50i-a100-r-pinctrl", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, a100_r_pinctrl_match);
> +
> +static struct platform_driver a100_r_pinctrl_driver = {
> + .probe = a100_r_pinctrl_probe,
> + .driver = {
> + .name = "sun50iw10p1-r-pinctrl",
> + .of_match_table = a100_r_pinctrl_match,
> + },
> +};
> +module_platform_driver(a100_r_pinctrl_driver);
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
> new file mode 100644
> index 000000000000..b9591009f0a4
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-a100.c
> @@ -0,0 +1,710 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Frank Lee <frank@allwinner.com>
> + *
> + * Based on:
> + * huangshuosheng <huangshuosheng@allwinnertech.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/pinctrl.h>
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin a100_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* TX */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CS */
> + SUNXI_FUNCTION(0x4, "jtag"), /* MS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* RX */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CLK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* CK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* RTS */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MOSI */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* CTS */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MISO */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SCK */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* MCLK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* MS_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SDA */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* BCLK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* CK_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s0"), /* LRCK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DO_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spdif"), /* DIN */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* DOUT0 */
> + SUNXI_FUNCTION(0x4, "i2s0"), /* DIN1 */
I guess the second one would be i2s1?
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spdif"), /* DOUT */
> + SUNXI_FUNCTION(0x3, "i2s0"), /* DIN0 */
> + SUNXI_FUNCTION(0x4, "i2s0"), /* DOUT1 */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart0"), /* TX */
> + SUNXI_FUNCTION(0x3, "i2c0"), /* SCK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DI_GPU */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart0"), /* RX */
> + SUNXI_FUNCTION(0x3, "i2c0"), /* SDA */
> + SUNXI_FUNCTION(0x4, "pwm1"),
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* WE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* DS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* ALE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* RST */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CLE */
> + SUNXI_FUNCTION(0x4, "spi0"), /* MOSI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CE1 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CS0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CE0 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* MISO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RB0 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* CMD */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RB1 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CS1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ7 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ6 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D4 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ5 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ4 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D5 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQS */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ3 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 13)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ2 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D6 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 14)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ1 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D2 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* WP */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 15)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ0 */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* D7 */
> + SUNXI_FUNCTION(0x4, "spi0"), /* HOLD */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 16)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D2 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D0P */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D3 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D0N */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D4 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D1P */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D5 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D1N */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D6 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D2P */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* CKP */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D7 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* D2N */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* CKM */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D10 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* CKP */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D11 */
> + SUNXI_FUNCTION(0x3, "lvds0"), /* CKN */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D12 */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DP3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D13 */
> + SUNXI_FUNCTION(0x4, "dsi0"), /* DM3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D14 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* CS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D15 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D18 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* MOSI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D19 */
> + SUNXI_FUNCTION(0x4, "spi1"), /* MISO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 13)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D20 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 14)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D21 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 15)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D22 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 16)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 17),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* D23 */
> + SUNXI_FUNCTION(0x4, "uart3"), /* CTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 17)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 18),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* CLK */
> + SUNXI_FUNCTION(0x4, "uart4"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 18)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 19),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* DE */
> + SUNXI_FUNCTION(0x4, "uart4"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 19)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 20),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* HSYNC */
> + SUNXI_FUNCTION(0x3, "pwm2"),
> + SUNXI_FUNCTION(0x4, "uart4"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 20)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 21),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "lcd0"), /* VSYNC */
> + SUNXI_FUNCTION(0x3, "pwm3"),
> + SUNXI_FUNCTION(0x4, "uart4"), /* CTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 21)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 22),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "pwm1"),
> + SUNXI_FUNCTION(0x4, "i2c0"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 22)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 23),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "pwm0"),
> + SUNXI_FUNCTION(0x4, "i2c0"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 2, 23)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* MCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c2"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c2"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c3"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c3"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* MCLK */
> + SUNXI_FUNCTION(0x3, "pll"), /* LOCK_DBG */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* MCLK */
> + SUNXI_FUNCTION(0x5, "ledc"), /* LEDC */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT0 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* BCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* SM_VS */
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT1 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* LRCK */
> + SUNXI_FUNCTION(0x5, "tcon0"), /* TRIG */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT2 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DOUT0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "bist0"), /* RESULT3 */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DIN0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 3, 9)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D1 */
> + SUNXI_FUNCTION(0x3, "jtag"), /* MS1 */
> + SUNXI_FUNCTION(0x4, "jtag"), /* MS_GPU */
We should use another name here, since the code will just pick the first one and
ignore the second. What about jtag-gpu?
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D0 */
> + SUNXI_FUNCTION(0x3, "jtag"), /* DI1 */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DI_GPU */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* CLK */
> + SUNXI_FUNCTION(0x3, "uart0"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* CMD */
> + SUNXI_FUNCTION(0x3, "jtag"), /* DO */
> + SUNXI_FUNCTION(0x4, "jtag"), /* DO_GPU */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D3 */
> + SUNXI_FUNCTION(0x3, "uart0"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D2 */
> + SUNXI_FUNCTION(0x3, "jtag"), /* CK */
> + SUNXI_FUNCTION(0x4, "jtag"), /* CK_GPU */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 6)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* CMD */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* CTS */
> + SUNXI_FUNCTION(0x3, "i2s1"), /* MCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* BCLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* LRCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* DOUT0 */
> + SUNXI_FUNCTION(0x4, "i2s1"), /* DIN1 */
This is suspicious too
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s1"), /* DIN0 */
> + SUNXI_FUNCTION(0x4, "i2s1"), /* DOUT1 */
Here too
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 5, 13)),
> + /* HOLE */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0"), /* SCK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 0)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0"), /* SDA */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 1)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SCK */
> + SUNXI_FUNCTION(0x3, "cpu"), /* CUR_W */
What is "cpu" supposed to be?
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXCTL */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 2)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c1"), /* SDA */
> + SUNXI_FUNCTION(0x3, "cir0"), /* OUT */
> + SUNXI_FUNCTION(0x5, "emac0"), /* CLKIN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 3)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* TX */
> + SUNXI_FUNCTION(0x3, "spi1"), /* CS */
> + SUNXI_FUNCTION(0x4, "cpu"), /* CUR_W */
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 4)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* RX */
> + SUNXI_FUNCTION(0x3, "spi1"), /* CLK */
> + SUNXI_FUNCTION(0x4, "ledc"),
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 5)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* RTS */
> + SUNXI_FUNCTION(0x3, "spi1"), /* MOSI */
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 6)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart3"), /* CTS */
> + SUNXI_FUNCTION(0x3, "spi1"), /* MISO */
> + SUNXI_FUNCTION(0x4, "spdif"), /* OUT */
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXCTL */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 7)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* CLK */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CS */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* MCLK */
> + SUNXI_FUNCTION(0x5, "i2s2"), /* DIN2 */
Same issue than previously
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 8)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA0 */
> + SUNXI_FUNCTION(0x3, "spi2"), /* CLK */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* BCLK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* MDC */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 9)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA1 */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MOSI */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* LRCK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* MDIO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 10)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA2 */
> + SUNXI_FUNCTION(0x3, "spi2"), /* MISO */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DOUT0 */
> + SUNXI_FUNCTION(0x5, "i2s2"), /* DIN1 */
Here as well
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 11)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "dmic"), /* DATA3 */
> + SUNXI_FUNCTION(0x3, "i2c3"), /* SCK */
> + SUNXI_FUNCTION(0x4, "i2s2"), /* DIN0 */
> + SUNXI_FUNCTION(0x5, "i2s2"), /* DOUT1 */
Ditto
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 12)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2c3"), /* SCK */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* MCLK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* EPHY */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 13)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x4, "i2s3"), /* BCLK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 14)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x4, "i2s3"), /* LRCK */
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXD2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 15)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT0 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN1 */
Ditto
> + SUNXI_FUNCTION(0x5, "emac0"), /* RXCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 16)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 17),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT1 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN0 */
Ditto
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 17)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 18),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "cir0"), /* OUT */
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT2 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN2 */
Ditto
> + SUNXI_FUNCTION(0x5, "emac0"), /* TXD2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 18)),
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 19),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "cir0"), /* IN */
> + SUNXI_FUNCTION(0x3, "i2s3"), /* DOUT3 */
> + SUNXI_FUNCTION(0x4, "i2s3"), /* DIN3 */
Ditto
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 10/13] soc: mediatek: cmdq: export finalize function
From: Matthias Brugger @ 2020-05-25 8:38 UTC (permalink / raw)
To: Chun-Kuang Hu
Cc: Dennis YC Hsieh, Rob Herring, Mark Rutland, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter, devicetree,
wsd_upstream, linux-kernel, DRI Development, HS Liao,
moderated list:ARM/Mediatek SoC support, Houlong Wei, Linux ARM
In-Reply-To: <CAAOTY___HNcRPr8Jq-wNPO_G9pLVjf2D7ezbpPcGbXVNYy1_nA@mail.gmail.com>
On 25/05/2020 02:23, Chun-Kuang Hu wrote:
> Hi, Matthias:
>
> Matthias Brugger <matthias.bgg@gmail.com> 於 2020年5月17日 週日 上午2:22寫道：
>>
>>
>>
>> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
>>> Export finalize function to client which helps append eoc and jump
>>> command to pkt. Let client decide call finalize or not.
>>>
>>> Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
>>> Reviewed-by: CK Hu <ck.hu@mediatek.com>
>>> ---
>>> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
>>> drivers/soc/mediatek/mtk-cmdq-helper.c | 7 ++-----
>>> include/linux/soc/mediatek/mtk-cmdq.h | 8 ++++++++
>>> 3 files changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> index 0dfcd1787e65..7daaabc26eb1 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>>> @@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
>>> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
>>> cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
>>> mtk_crtc_ddp_config(crtc, cmdq_handle);
>>> + cmdq_pkt_finalize(cmdq_handle);
>>> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
>>> }
>>> #endif
>>
>> This should be a independent patch.
>> Other then that patch looks good.
>
> Apply only drm part or only cmdq helpr part, it would be abnormal.
Right it would break DRM driver (if only applied to cmdq) or compilation if only
applied to DRM.
> Shall we seperate this patch?
After thinking twice, I think we can leave it as it is. If you provide your
Acked-by I can take it thorugh my tree, if that's OK for you.
Regards,
Matthias
> Or seperate it but make sure these two patches be in the same tree?
>
> Regards,
> Chun-Kuang.
>
>>
>>> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> index a9ebbabb7439..59bc1164b411 100644
>>> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
>>> @@ -372,7 +372,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
>>> }
>>> EXPORT_SYMBOL(cmdq_pkt_assign);
>>>
>>> -static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>>> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>>> {
>>> struct cmdq_instruction inst = { {0} };
>>> int err;
>>> @@ -392,6 +392,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>>>
>>> return err;
>>> }
>>> +EXPORT_SYMBOL(cmdq_pkt_finalize);
>>>
>>> static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
>>> {
>>> @@ -426,10 +427,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
>>> unsigned long flags = 0;
>>> struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
>>>
>>> - err = cmdq_pkt_finalize(pkt);
>>> - if (err < 0)
>>> - return err;
>>> -
>>> pkt->cb.cb = cb;
>>> pkt->cb.data = data;
>>> pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
>>> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
>>> index fec292aac83c..99e77155f967 100644
>>> --- a/include/linux/soc/mediatek/mtk-cmdq.h
>>> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
>>> @@ -213,6 +213,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
>>> */
>>> int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
>>>
>>> +/**
>>> + * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
>>> + * @pkt: the CMDQ packet
>>> + *
>>> + * Return: 0 for success; else the error code is returned
>>> + */
>>> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
>>> +
>>> /**
>>> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
>>> * packet and call back at the end of done packet
>>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: qcom: apq8016-sbc-d3: Add Qualcomm APQ8016 SBC + D3Camera mezzanine
From: Robert Foss @ 2020-05-25 8:35 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Manivannan Sadhasivam, Vinod Koul, Rob Herring, linux-arm-msm,
devicetree, linux-kernel, Nicolas Dechesne
In-Reply-To: <20200519232442.GE2165@builder.lan>
Hi Bjorn,
Thanks for the review. I'll incorporate the changes if we decide to
that this DT should live upstream.
On Wed, 20 May 2020 at 01:26, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Tue 19 May 03:22 PDT 2020, Manivannan Sadhasivam wrote:
>
> > Hi Robert,
> >
> > On Mon, May 18, 2020 at 10:21:29AM +0200, Robert Foss wrote:
> > > Add device treee support for the Qualcomm APQ8016 SBC, otherwise known as
> > > the Dragonboard 410c with the D3Camera mezzanine expansion board.
> > >
> > > The D3Camera mezzanine ships in a kit with a OmniVision 5640 sensor module,
> > > which is what this DT targets.
> > >
> >
> > What is the motivation behind adding this new dts? We have been using the
> > userspace tool [1] for applying this as an overlay for some time. But if we
> > start adding dts for mezzanines then for sure we'll end up with some good
> > numbers which will flood arch/{..}/qcom directory.
> >
> > I could understand that one of the motivation is to provide nice user experience
> > to users but that's also taken care by the dt-update tool IMO.
> >
>
> The motivation for posting this was to provoke a response like yours.
>
> I knew about [1], but not that it included the overlays. I'm okay with
> using overlays and the dt-update tool. But I would have preferred that
> the dts files didn't live out of tree, given that this approach breaks
> if I change the name of a node you depend on upstream.
I wasn't aware of the dt-update tool, and it seems pretty neat.
However, a thought I had is that using it to enable a dt-node or a
board variant is not very different from applying a patch the the
upstream tree. The work it takes to do it is about the same, and the
maintenance burden of using a patch is about the same as using
dt-tool.
> > [1] https://github.com/96boards/dt-update
^ permalink raw reply
* Re: [PATCH 03/17] ARM: dts: r8a7742: Add I2C and IIC support
From: Geert Uytterhoeven @ 2020-05-25 8:23 UTC (permalink / raw)
To: Wolfram Sang
Cc: Lad, Prabhakar, Lad Prabhakar, Jens Axboe, Rob Herring,
Ulf Hansson, Sergei Shtylyov, David S. Miller, Wim Van Sebroeck,
Guenter Roeck, linux-ide,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Linux I2C, Linux MMC List, netdev, Linux-Renesas,
Linux Watchdog Mailing List
In-Reply-To: <20200522201727.GA21376@ninjato>
Hi Wolfram,
On Fri, May 22, 2020 at 10:17 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > > According to the Hardware User's Manual Rev. 1.00, the registers do exist
> > > on all RZ/G1, except for RZ/G1E (see below).
> > >
> > > "(automatic transmission can be used as a hardware function, but this is
> > > not meaningful for actual use cases)."
> > >
> > > (whatever that comment may mean?)
>
> Strange comment, in deed. Given the paragraph before, I would guess Gen1
> maybe had a "fitting" PMIC where SoC/PMIC handled DVFS kind of magically
> with this automatic transfer feature? And Gen2 has not.
>
> > > On R-Car E3 and RZ/G2E, which have a single IIC instance, we
> > > handled that by:
> > >
> > > The r8a77990 (R-Car E3) and r8a774c0 (RZ/G2E)
> > > controllers are not considered compatible with
> > > "renesas,rcar-gen3-iic" or "renesas,rmobile-iic"
> > > due to the absence of automatic transmission registers.
>
> From a "describe the HW" point of view, this still makes sense to me.
> Although, it is unlikely we will add support for the automatic
> transmission feature (maybe famous last words).
;-)
> > > On R-Car E2 and RZ/G1E, we forgot, and used both SoC-specific and
> > > family-specific compatible values.
>
> Okay, but we can fix DTs when they have bugs, or?
We can. But we also have to consider DT backwards compatibility: i.e.
using an old DTB with a future kernel implementing the automatic
transmission feature.
Fortunately R-Car E2 and RZ/G1E have SoC-specific compatible values,
so we can easily blacklist it in the driver based on that.
Blacklisting the last instance on the other SoCs is uglier, as it needs a
quirk that checks both the SoC-compatible value and the absence of the
generic compatible value. But it can still be done.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v5.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 1/4] dt-bindings: iio: magnetometer: ak8975: convert format to yaml, add maintainer
From: Jonathan Albrieux @ 2020-05-25 8:00 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-kernel, ~postmarketos/upstreaming, Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Greg Kroah-Hartman, Hartmut Knaack, Jilayne Lovejoy,
Jonathan Cameron, Kate Stewart, Lars-Peter Clausen, Linus Walleij,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Steve Winslow, Thomas Gleixner, Rob Herring
In-Reply-To: <20200524155745.3b9320db@archlinux>
On Sun, May 24, 2020 at 03:57:45PM +0100, Jonathan Cameron wrote:
> On Wed, 20 May 2020 18:34:06 +0200
> Jonathan Albrieux <jonathan.albrieux@gmail.com> wrote:
>
> > Converts documentation from txt format to yaml.
> >
> > Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
>
> An additional request inline. Doesn't effect this patch 'as such'.
>
> Also the file name thing just below here.
>
> > ---
> > .../bindings/iio/magnetometer/ak8975.txt | 30 --------
> > .../bindings/iio/magnetometer/ak8975.yaml | 71 +++++++++++++++++++
> File naming should match the compatible.
>
> ashahi-kasei,ak8975.yaml
>
Ok, I'll take this as general rule then :-)
> > 2 files changed, 71 insertions(+), 30 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> > create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> > deleted file mode 100644
> > index aa67ceb0d4e0..000000000000
> > --- a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
> > +++ /dev/null
> > @@ -1,30 +0,0 @@
> > -* AsahiKASEI AK8975 magnetometer sensor
> > -
> > -Required properties:
> > -
> > - - compatible : should be "asahi-kasei,ak8975"
> > - - reg : the I2C address of the magnetometer
> > -
> > -Optional properties:
> > -
> > - - gpios : should be device tree identifier of the magnetometer DRDY pin
> > - - vdd-supply: an optional regulator that needs to be on to provide VDD
> > - - mount-matrix: an optional 3x3 mounting rotation matrix
> > -
> > -Example:
> > -
> > -ak8975@c {
> > - compatible = "asahi-kasei,ak8975";
> > - reg = <0x0c>;
> > - gpios = <&gpj0 7 0>;
> > - vdd-supply = <&ldo_3v3_gnss>;
> > - mount-matrix = "-0.984807753012208", /* x0 */
> > - "0", /* y0 */
> > - "-0.173648177666930", /* z0 */
> > - "0", /* x1 */
> > - "-1", /* y1 */
> > - "0", /* z1 */
> > - "-0.173648177666930", /* x2 */
> > - "0", /* y2 */
> > - "0.984807753012208"; /* z2 */
> > -};
> > diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> > new file mode 100644
> > index 000000000000..8bde423a2ffa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.yaml
> > @@ -0,0 +1,71 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/magnetometer/ak8975.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: AsahiKASEI AK8975 magnetometer sensor
> > +
> > +maintainers:
> > + - Jonathan Albrieux <jonathan.albrieux@gmail.com>
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - const: asahi-kasei,ak8975
> > + - const: asahi-kasei,ak8963
> > + - const: asahi-kasei,ak09911
> > + - const: asahi-kasei,ak09912
> > + - const: ak8975
> > + deprecated: true
> > + - const: ak8963
> > + deprecated: true
> > + - const: ak09911
> > + deprecated: true
> > + - const: ak09912
> > + deprecated: true
> > +
> > + reg:
> > + maxItems: 1
> > + description: the I2C address of the magnetometer
> > +
> > + gpios:
> > + description: should be device tree identifier of the magnetometer DRDY pin
>
> Nothing to do with your patch obviously but this is horrible...
> + the driver will quite happily take an interrupt instead.
>
> Do you mind documenting the interrupt here as well?
>
> Should be a separate patch though. So a follow up one to
> this one. The
> arch/arm/boot/dts/motorola-mapphone-common.dtsi
> does it that way, unlike the samsung s3 which uses the gpio
> binding (I think it's the only one against quite a few
> using interrupts).
>
> Also switch the example to an interrupts one so we don't
> encourage anyone to go the gpios route.
>
> Note can be a follow up if this series is otherwise ready to go.
>
Oh ok, will add a new patch for that in this series if you don't
mind. It may even be better to split this series in two given
the amount of changes to the documentation outnumbered the changes
related to the driver itself, the first one regarding just the
conversion to yaml and clean-up-related changes to documentation
and the second one, depending on the first one, with the
reset-related changes.
Do you have advices on which of the two should be the best strategy?
I'll prepare both the versions today in order to choose the right
one once the path to follow has been decided,
Thank you,
Best regards,
Jonathan Albrieux
>
> > +
> > + vdd-supply:
> > + maxItems: 1
> > + description: |
> > + an optional regulator that needs to be on to provide VDD power to
> > + the sensor.
> > +
> > + mount-matrix:
> > + description: an optional 3x3 mounting rotation matrix
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > + i2c@78b7000 {
> > + reg = <0x78b6000 0x600>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + magnetometer@c {
> > + compatible = "asahi-kasei,ak8975";
> > + reg = <0x0c>;
> > + gpios = <&gpj0 7 GPIO_ACTIVE_HIGH>;
> > + vdd-supply = <&ldo_3v3_gnss>;
> > + mount-matrix = "-0.984807753012208", /* x0 */
> > + "0", /* y0 */
> > + "-0.173648177666930", /* z0 */
> > + "0", /* x1 */
> > + "-1", /* y1 */
> > + "0", /* z1 */
> > + "-0.173648177666930", /* x2 */
> > + "0", /* y2 */
> > + "0.984807753012208"; /* z2 */
> > + };
> > + };
>
^ permalink raw reply
* [PATCH] arm64: dts: ls1028a: add one more thermal zone support
From: Yuantian Tang @ 2020-05-25 7:38 UTC (permalink / raw)
To: shawnguo, robh+dt, mark.rutland, catalin.marinas, will.deacon
Cc: devicetree, linux-arm-kernel, linux-kernel, Yuantian Tang
There are 2 thermal zones in ls1028a soc. Current dts only
includes one. This patch adds the other thermal zone node
in dts to enable it.
Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
---
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 22 ++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 055f114cf848..bc6f0c0f85da 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -129,11 +129,31 @@
};
thermal-zones {
- core-cluster {
+ ddr-controller {
polling-delay-passive = <1000>;
polling-delay = <5000>;
thermal-sensors = <&tmu 0>;
+ trips {
+ ddr-ctrler-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ ddr-ctrler-crit {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ core-cluster {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+ thermal-sensors = <&tmu 1>;
+
trips {
core_cluster_alert: core-cluster-alert {
temperature = <85000>;
--
2.17.1
^ permalink raw reply related
* Re: [PATCHv8 0/6] n_gsm serdev support and GNSS driver for droid4
From: Johan Hovold @ 2020-05-25 7:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tony Lindgren, Johan Hovold, Rob Herring, Alan Cox, Lee Jones,
Jiri Slaby, Merlijn Wajer, Pavel Machek, Peter Hurley,
Sebastian Reichel, linux-serial, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20200522091731.GA1203588@kroah.com>
On Fri, May 22, 2020 at 11:17:31AM +0200, Greg Kroah-Hartman wrote:
> On Tue, May 12, 2020 at 02:47:07PM -0700, Tony Lindgren wrote:
> > Hi all,
> >
> > Here's the updated set of these patches fixed up for Johan's and
> > Pavel's earlier comments.
> >
> > This series does the following:
> >
> > 1. Adds functions to n_gsm.c for serdev-ngsm.c driver to use
> >
> > 2. Adds a generic serdev-ngsm.c driver that brings up the TS 27.010
> > TTY ports configured in devicetree with help of n_gsm.c
> >
> > 3. Allows the use of standard Linux device drivers for dedicated
> > TS 27.010 channels for devices like GNSS and ALSA found on some
> > modems for example
> >
> > 4. Adds a gnss-motmdm consumer driver for the GNSS device found on
> > the Motorola Mapphone MDM6600 modem on devices like droid4
> >
> > I've placed the serdev-ngsm.c under drivers/tty/serdev as it still
> > seems to make most sense with no better places available. It's no
> > longer an MFD driver as it really does not need to care what channel
> > specific consumer drivers might be configured for the generic driver.
> > Now serdev-ngsm just uses of_platform_populate() to probe whatever
> > child nodes it might find.
> >
> > I'm not attached having the driver in drivers/tty/serdev. I just
> > don't have any better locations in mind. So using Johan's earlier
> > i2c example, the drivers/tty/serdev/serdev-ngsm.c driver is now a
> > generic protocol and bus driver, so it's getting closer to the
> > the drivers/i2c/busses analogy maybe :) Please do suggest better
> > locations other than MFD and misc if you have better ideas.
> >
> > Now without the chardev support, the /dev/gsmtty* using apps need
> > to use "U1234AT+CFUN?" format for the packets. The advantage is
> > less kernel code, and we keep the existing /dev/gsmtty* interface.
> >
> > If we still really need the custom chardev support, that can now
> > be added as needed with the channel specific consumer driver(s),
> > but looks like this won't be needed based on Pavel's ofono work.
>
> Johan and Rob, any objection/review of this series?
Yeah, sorry I haven't had time to review this yet. I should be able to
look at it today.
Johan
^ permalink raw reply
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Ricardo Cañuelo @ 2020-05-25 7:43 UTC (permalink / raw)
To: Laurent Pinchart
Cc: kernel, devicetree, linux-arm-kernel, geert+renesas, robh+dt,
xuwei5
In-Reply-To: <20200514152239.GG5955@pendragon.ideasonboard.com>
Hi Laurent,
On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > If we want to be more strict and require the definition of all the
> > supplies, there will be many more DTs changes in the series, and I'm not
> > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > at them and it's not always clear which regulators to use or if they are
> > even defined.
>
> We can decouple the two though (I think). The bindings should reflect
> what we consider right, and the dts files could be fixed on top.
Do you have a suggestion on how to do this? If we decouple the two
tasks most of the work would be searching for DTs to fix and finding a
way to fix each one of them, and unless I do this _before_ the binding
conversion I'll get a lot of dtbs_check errors.
The binding conversion itself is done, if we go this route the only
additional change would be to make the supplies required.
Cheers,
Ricardo
^ 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