* [PATCH 3/6] arm: dts: Change PCIe INTx mapping for Cygnus
From: Ray Jui @ 2018-06-12 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f5aa804e-3174-affd-1117-31b0a5b59fc5@gmail.com>
On 6/11/2018 3:36 PM, Florian Fainelli wrote:
> On 05/29/2018 02:58 PM, Ray Jui wrote:
>> Change the PCIe INTx mapping to model the 4 INTx interrupts in the
>> IRQ domain of the iProc PCIe controller itself
>>
>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>> ---
>> arch/arm/boot/dts/bcm-cygnus.dtsi | 18 ++++++++++++++----
>> 1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> index 699fdf9..6de21ef 100644
>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>> @@ -254,9 +254,14 @@
>> compatible = "brcm,iproc-pcie";
>> reg = <0x18012000 0x1000>;
>>
>> + interrupt-controller;
>> #interrupt-cells = <1>;
>> - interrupt-map-mask = <0 0 0 0>;
>> - interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &pcie0 1>,
>> + <0 0 0 2 &pcie0 2>,
>> + <0 0 0 3 &pcie0 3>,
>> + <0 0 0 4 &pcie0 4>;
>> + interrupts = <GIC_SPI 100 IRQ_TYPE_NONE>;
>
> You would want to fix those IRQ_TYPE_NONE values as well because since
> commit 83a86fbb5b56b5eed8a476cc3fe214077d7c4f49 ("irqchip/gic: Loudly
> complain about the use of IRQ_TYPE_NONE") this is going to create some
> nice warnings on boot.
>
> I am about to send fixes for NSP and HR2 since that's what I have access
> to at the moment, but it would be good if you could send updates to the
> Cygnus and NS2 DTS files?
>
> Thanks
>
Okay. Thanks for letting me know. How do you want this to be done for
Cygnus and NS2?
I guess I should have the fix patches to DTS done and sent out first,
and then rebase this INTx patch series against the patches with the fix.
Does that make sense to you?
Thanks,
Ray
>>
>> linux,pci-domain = <0>;
>>
>> @@ -289,9 +294,14 @@
>> compatible = "brcm,iproc-pcie";
>> reg = <0x18013000 0x1000>;
>>
>> + interrupt-controller;
>> #interrupt-cells = <1>;
>> - interrupt-map-mask = <0 0 0 0>;
>> - interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>;
>> + interrupt-map-mask = <0 0 0 7>;
>> + interrupt-map = <0 0 0 1 &pcie1 1>,
>> + <0 0 0 2 &pcie1 2>,
>> + <0 0 0 3 &pcie1 3>,
>> + <0 0 0 4 &pcie1 4>;
>> + interrupts = <GIC_SPI 106 IRQ_TYPE_NONE>;
>>
>> linux,pci-domain = <1>;
>>
>>
>
>
^ permalink raw reply
* [PATCH 3/6] arm: dts: Change PCIe INTx mapping for Cygnus
From: Florian Fainelli @ 2018-06-12 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <522816f9-c33f-ee58-619e-84ee86dba418@broadcom.com>
On June 11, 2018 5:27:20 PM PDT, Ray Jui <ray.jui@broadcom.com> wrote:
>
>
>On 6/11/2018 3:36 PM, Florian Fainelli wrote:
>> On 05/29/2018 02:58 PM, Ray Jui wrote:
>>> Change the PCIe INTx mapping to model the 4 INTx interrupts in the
>>> IRQ domain of the iProc PCIe controller itself
>>>
>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>> ---
>>> arch/arm/boot/dts/bcm-cygnus.dtsi | 18 ++++++++++++++----
>>> 1 file changed, 14 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>b/arch/arm/boot/dts/bcm-cygnus.dtsi
>>> index 699fdf9..6de21ef 100644
>>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>>> @@ -254,9 +254,14 @@
>>> compatible = "brcm,iproc-pcie";
>>> reg = <0x18012000 0x1000>;
>>>
>>> + interrupt-controller;
>>> #interrupt-cells = <1>;
>>> - interrupt-map-mask = <0 0 0 0>;
>>> - interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
>>> + interrupt-map-mask = <0 0 0 7>;
>>> + interrupt-map = <0 0 0 1 &pcie0 1>,
>>> + <0 0 0 2 &pcie0 2>,
>>> + <0 0 0 3 &pcie0 3>,
>>> + <0 0 0 4 &pcie0 4>;
>>> + interrupts = <GIC_SPI 100 IRQ_TYPE_NONE>;
>>
>> You would want to fix those IRQ_TYPE_NONE values as well because
>since
>> commit 83a86fbb5b56b5eed8a476cc3fe214077d7c4f49 ("irqchip/gic: Loudly
>> complain about the use of IRQ_TYPE_NONE") this is going to create
>some
>> nice warnings on boot.
>>
>> I am about to send fixes for NSP and HR2 since that's what I have
>access
>> to at the moment, but it would be good if you could send updates to
>the
>> Cygnus and NS2 DTS files?
>>
>> Thanks
>>
>
>Okay. Thanks for letting me know. How do you want this to be done for
>Cygnus and NS2?
>
>I guess I should have the fix patches to DTS done and sent out first,
>and then rebase this INTx patch series against the patches with the
>fix.
>
>Does that make sense to you?
Yes it does. As soon as v4.18-rc1 is tagged I will send the Device Tree fixes pull request, if I can have yours for Cygnus and NS2 in the next few days I could lump those together. Then we can either base your changes off v4.18-rc2 or a later tag that already has the DTS fixes.
--
Florian
^ permalink raw reply
* [PATCH 3/6] arm: dts: Change PCIe INTx mapping for Cygnus
From: Ray Jui @ 2018-06-12 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <D95617BA-7C31-4737-9514-BA3F7B09DCE2@gmail.com>
On 6/11/2018 5:55 PM, Florian Fainelli wrote:
> On June 11, 2018 5:27:20 PM PDT, Ray Jui <ray.jui@broadcom.com> wrote:
>>
>>
>> On 6/11/2018 3:36 PM, Florian Fainelli wrote:
>>> On 05/29/2018 02:58 PM, Ray Jui wrote:
>>>> Change the PCIe INTx mapping to model the 4 INTx interrupts in the
>>>> IRQ domain of the iProc PCIe controller itself
>>>>
>>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>>> ---
>>>> arch/arm/boot/dts/bcm-cygnus.dtsi | 18 ++++++++++++++----
>>>> 1 file changed, 14 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
>> b/arch/arm/boot/dts/bcm-cygnus.dtsi
>>>> index 699fdf9..6de21ef 100644
>>>> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
>>>> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
>>>> @@ -254,9 +254,14 @@
>>>> compatible = "brcm,iproc-pcie";
>>>> reg = <0x18012000 0x1000>;
>>>>
>>>> + interrupt-controller;
>>>> #interrupt-cells = <1>;
>>>> - interrupt-map-mask = <0 0 0 0>;
>>>> - interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>;
>>>> + interrupt-map-mask = <0 0 0 7>;
>>>> + interrupt-map = <0 0 0 1 &pcie0 1>,
>>>> + <0 0 0 2 &pcie0 2>,
>>>> + <0 0 0 3 &pcie0 3>,
>>>> + <0 0 0 4 &pcie0 4>;
>>>> + interrupts = <GIC_SPI 100 IRQ_TYPE_NONE>;
>>>
>>> You would want to fix those IRQ_TYPE_NONE values as well because
>> since
>>> commit 83a86fbb5b56b5eed8a476cc3fe214077d7c4f49 ("irqchip/gic: Loudly
>>> complain about the use of IRQ_TYPE_NONE") this is going to create
>> some
>>> nice warnings on boot.
>>>
>>> I am about to send fixes for NSP and HR2 since that's what I have
>> access
>>> to at the moment, but it would be good if you could send updates to
>> the
>>> Cygnus and NS2 DTS files?
>>>
>>> Thanks
>>>
>>
>> Okay. Thanks for letting me know. How do you want this to be done for
>> Cygnus and NS2?
>>
>> I guess I should have the fix patches to DTS done and sent out first,
>> and then rebase this INTx patch series against the patches with the
>> fix.
>>
>> Does that make sense to you?
>
> Yes it does. As soon as v4.18-rc1 is tagged I will send the Device Tree fixes pull request, if I can have yours for Cygnus and NS2 in the next few days I could lump those together. Then we can either base your changes off v4.18-rc2 or a later tag that already has the DTS fixes.
>
Okay that sounds good. I'll try to get those fixes out for you within
the next few days.
Thanks!
Ray
^ permalink raw reply
* [GIT PULL 2/4] ARM: Device-tree updates
From: Linus Torvalds @ 2018-06-12 1:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612000142.28883-3-olof@lixom.net>
On Mon, Jun 11, 2018 at 5:02 PM Olof Johansson <olof@lixom.net> wrote:
>
> - Qualcomm:
> + SDM845, a.k.a Snapdragon 845, an 4+4-core Kryo 385/845
> (Cortex-A75/A55 derivative) SoC that's one of the current high-end
> mobile SoCs.
>
> It's great to see mainline support for it. So far, you
> can't do much with it, since a lot of peripherals are not yet in the
> DTs but driver support for USB, GPU and other pieces are starting to
> trickle in. This might end up being a well-supported SoC upstream if
> the momentum keeps up.
Isn't the Qualcomm 845 also the SoC in some of the new WARM laptops?
I asked one person that had an older one (ASUS NovaGo - Qualcomm 835),
and apparently you can actually disable secure boot on that thing and
boot from USB.
In other words, it might _actually_ act like a normal laptop.
I'd love to have something that is actually a real honest-to-goodness
ARM laptop finally. Are we getting at all close to that?
Linus
^ permalink raw reply
* [PATCH 0/5] arm64: numa/topology/smp: fix the cpumasks for CPU hotplug
From: Hanjun Guo @ 2018-06-12 1:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528108797-13743-1-git-send-email-sudeep.holla@arm.com>
Hi Sudeep,
On 2018/6/4 18:39, Sudeep Holla wrote:
> Hi Will, Catalin, Jeremy, Morten,
>
> This is the fix I could come up for the issues we are seeing with arm64
> for-next branch, in particular with commit 37c3ec2d810f ("arm64: topology:
> divorce MC scheduling domain from core_siblings").
>
> The solution is to update the CPU topology during CPU hotplug operations
> similar to other architectures like x86 and PPC. This is also inline
> with the expection from the scheduler.
>
> I have cc-ed few Cavium and Huawei guys as they seem to have added or
> modified the numa related code in the past.
Sorry for the late response, I can test on ARM64 NUMA systems
with PPTT enabled, before I'm doing that, could you give some
suggestion of the testing? what specific test case should I
test? doing CPU offline/online when PPTT is enabled?
Thanks
Hanjun
^ permalink raw reply
* [RESEND v2] dmaengine: pxa: add a default requestor policy
From: Vinod Koul @ 2018-06-12 4:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8736xtrtej.fsf@belgarion.home>
On 11-06-18, 21:54, Robert Jarzmik wrote:
> Vinod Koul <vinod.koul@linaro.org> writes:
>
> > On 09-06-18, 14:43, Robert Jarzmik wrote:
> >> Robert Jarzmik <robert.jarzmik@free.fr> writes:
> >>
> >> > As what former drcmr -1 value meant, add a this as a default to each
> >> > channel, ie. that by default no requestor line is used.
> >> >
> >> > This is specifically used for network drivers smc91x and smc911x, and
> >> > needed for their port to slave maps.
> >> >
> >> > Cc: Arnd Bergmann <arnd@arndb.de>
> >> > Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> >> > ---
> >> > Since v1: changed -1 to U32_MAX
> >> Hi Vinod,
> >>
> >> Could I have your ack on this so that I add this one to the dma slave map serie
> >> after the merge window is closed please ?
> >
> > Sorry I was thinking it would go thru dmaengine tree, please do
> > indicate if that is not the case. Nevertheless
> >
> > Acked-by: Vinod Koul <vkoul@kernel.org>
> Thanks.
>
> As this is a dependency to the serie, I'd rather take it, unless you insist, in
> which case I'll rely on the fact that it will hit 4.19 cycle.
It fine if you take, just that it helps to indicate the route to take
for a patch :)
--
~Vinod
^ permalink raw reply
* [PATCH] usb/gadget: aspeed-vhub: add USB_LIBCOMPOSITE dependency
From: Benjamin Herrenschmidt @ 2018-06-12 4:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87o9gxcono.fsf@linux.intel.com>
On Wed, 2018-05-30 at 15:29 +0300, Felipe Balbi wrote:
> Hi,
>
> Arnd Bergmann <arnd@arndb.de> writes:
> > Without that option, we run into a link failure:
> >
> > drivers/usb/gadget/udc/aspeed-vhub/hub.o: In function `ast_vhub_std_hub_request':
> > hub.c:(.text+0x5b0): undefined reference to `usb_gadget_get_string'
> >
> > Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Greg, can you send this to Linus asap ? Some people are hitting build
breakages upstream because of this.
Thanks !
Cheers,
Ben,
^ permalink raw reply
* [PATCH 1/2] arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
From: Bjorn Andersson @ 2018-06-12 5:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607204608.27688-1-dianders@chromium.org>
On Thu 07 Jun 13:46 PDT 2018, Douglas Anderson wrote:
> This adds nodes to SDM845-dtsi for all the I2C ports, all the SPI
> ports, and UART9. Note that I2C / SPI / UART are a bit strange on
> sdm845 because each "serial engine" has 4 pins associated with it and
> depending on which firmware has been loaded into the serial engine
> (loaded by the BIOS) the serial engine can behave like an I2C port, a
> SPI port, or a UART. As per the landed bindings that means that we
> need to create one node for each possible mode that the port could be
> in. With 16 serial engines that means 16 x 3 = 48 nodes.
>
> We get away with only creating 33 nodes for now because it seems very
> likely that SDM845-based boards will actually all use the same UART
> (UART 9) for debug purposes. While another UART could be used for
> something like Bluetooth communication we can cross that path when we
> come to it. Some documentation that I saw implied that using a UART
> for "high speed" communications actually needs yet another different
> serial engine firmware anyway.
>
> Note that quick measurements adding all these nodes adds ~10k of extra
> space per dtb that they're included with. If this becomes a problem
> we may need to think of a different way to structure this so that
> boards only get the nodes they need (or figure out how to get dtc to
> strip 'disabled' nodes). For now it seems OK.
>
> These nodes were programmatically generated with a fairly dumb python
> script. See http://crosreview.com/1091631 for the source.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 1013 ++++++++++++++++++++++++++
> 1 file changed, 1013 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index cdaabeb3c995..2dc5c7dcc9aa 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -5,6 +5,7 @@
> * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> */
>
> +#include <dt-bindings/clock/qcom,gcc-sdm845.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
>
> / {
> @@ -13,6 +14,41 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> + aliases {
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + i2c2 = &i2c2;
> + i2c3 = &i2c3;
> + i2c4 = &i2c4;
> + i2c5 = &i2c5;
> + i2c6 = &i2c6;
> + i2c7 = &i2c7;
> + i2c8 = &i2c8;
> + i2c9 = &i2c9;
> + i2c10 = &i2c10;
> + i2c11 = &i2c11;
> + i2c12 = &i2c12;
> + i2c13 = &i2c13;
> + i2c14 = &i2c14;
> + i2c15 = &i2c15;
> + spi0 = &spi0;
> + spi1 = &spi1;
> + spi2 = &spi2;
> + spi3 = &spi3;
> + spi4 = &spi4;
> + spi5 = &spi5;
> + spi6 = &spi6;
> + spi7 = &spi7;
> + spi8 = &spi8;
> + spi9 = &spi9;
> + spi10 = &spi10;
> + spi11 = &spi11;
> + spi12 = &spi12;
> + spi13 = &spi13;
> + spi14 = &spi14;
> + spi15 = &spi15;
> + };
> +
> chosen { };
>
> memory at 80000000 {
> @@ -206,6 +242,489 @@
> #power-domain-cells = <1>;
> };
>
> + qupv3_id_0: geniqup at 8c0000 {
> + compatible = "qcom,geni-se-qup";
> + reg = <0x8c0000 0x6000>;
> + clock-names = "m-ahb", "s-ahb";
> + clocks = <&gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
> + <&gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + i2c0: i2c at 880000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0x880000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c0_default>;
> + pinctrl-1 = <&qup_i2c0_sleep>;
> + interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi0: spi at 880000 {
> + compatible = "qcom,geni-spi";
> + reg = <0x880000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi0_default>;
> + pinctrl-1 = <&qup_spi0_sleep>;
> + interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c1: i2c at 884000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0x884000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c1_default>;
> + pinctrl-1 = <&qup_i2c1_sleep>;
> + interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi1: spi at 884000 {
> + compatible = "qcom,geni-spi";
> + reg = <0x884000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi1_default>;
> + pinctrl-1 = <&qup_spi1_sleep>;
> + interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c2: i2c at 888000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0x888000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c2_default>;
> + pinctrl-1 = <&qup_i2c2_sleep>;
> + interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi2: spi at 888000 {
> + compatible = "qcom,geni-spi";
> + reg = <0x888000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi2_default>;
> + pinctrl-1 = <&qup_spi2_sleep>;
> + interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c3: i2c at 88c000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0x88c000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c3_default>;
> + pinctrl-1 = <&qup_i2c3_sleep>;
> + interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi3: spi at 88c000 {
> + compatible = "qcom,geni-spi";
> + reg = <0x88c000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi3_default>;
> + pinctrl-1 = <&qup_spi3_sleep>;
> + interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c4: i2c at 890000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0x890000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c4_default>;
> + pinctrl-1 = <&qup_i2c4_sleep>;
> + interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi4: spi at 890000 {
> + compatible = "qcom,geni-spi";
> + reg = <0x890000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi4_default>;
> + pinctrl-1 = <&qup_spi4_sleep>;
> + interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c5: i2c at 894000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0x894000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c5_default>;
> + pinctrl-1 = <&qup_i2c5_sleep>;
> + interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi5: spi at 894000 {
> + compatible = "qcom,geni-spi";
> + reg = <0x894000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi5_default>;
> + pinctrl-1 = <&qup_spi5_sleep>;
> + interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c6: i2c at 898000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0x898000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S6_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c6_default>;
> + pinctrl-1 = <&qup_i2c6_sleep>;
> + interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi6: spi at 898000 {
> + compatible = "qcom,geni-spi";
> + reg = <0x898000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S6_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi6_default>;
> + pinctrl-1 = <&qup_spi6_sleep>;
> + interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c7: i2c at 89c000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0x89c000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S7_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c7_default>;
> + pinctrl-1 = <&qup_i2c7_sleep>;
> + interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi7: spi at 89c000 {
> + compatible = "qcom,geni-spi";
> + reg = <0x89c000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S7_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi7_default>;
> + pinctrl-1 = <&qup_spi7_sleep>;
> + interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> + };
> +
> + qupv3_id_1: geniqup at ac0000 {
> + compatible = "qcom,geni-se-qup";
> + reg = <0xac0000 0x6000>;
> + clock-names = "m-ahb", "s-ahb";
> + clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
> + <&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + status = "disabled";
> +
> + i2c8: i2c at a80000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0xa80000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c8_default>;
> + pinctrl-1 = <&qup_i2c8_sleep>;
> + interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi8: spi at a80000 {
> + compatible = "qcom,geni-spi";
> + reg = <0xa80000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi8_default>;
> + pinctrl-1 = <&qup_spi8_sleep>;
> + interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c9: i2c at a84000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0xa84000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c9_default>;
> + pinctrl-1 = <&qup_i2c9_sleep>;
> + interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi9: spi at a84000 {
> + compatible = "qcom,geni-spi";
> + reg = <0xa84000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi9_default>;
> + pinctrl-1 = <&qup_spi9_sleep>;
> + interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + uart9: serial at a84000 {
> + compatible = "qcom,geni-debug-uart";
> + reg = <0xa84000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_uart9_default>;
> + pinctrl-1 = <&qup_uart9_sleep>;
> + interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + i2c10: i2c at a88000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0xa88000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c10_default>;
> + pinctrl-1 = <&qup_i2c10_sleep>;
> + interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi10: spi at a88000 {
> + compatible = "qcom,geni-spi";
> + reg = <0xa88000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi10_default>;
> + pinctrl-1 = <&qup_spi10_sleep>;
> + interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c11: i2c at a8c000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0xa8c000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c11_default>;
> + pinctrl-1 = <&qup_i2c11_sleep>;
> + interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi11: spi at a8c000 {
> + compatible = "qcom,geni-spi";
> + reg = <0xa8c000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi11_default>;
> + pinctrl-1 = <&qup_spi11_sleep>;
> + interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c12: i2c at a90000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0xa90000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c12_default>;
> + pinctrl-1 = <&qup_i2c12_sleep>;
> + interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi12: spi at a90000 {
> + compatible = "qcom,geni-spi";
> + reg = <0xa90000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi12_default>;
> + pinctrl-1 = <&qup_spi12_sleep>;
> + interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c13: i2c at a94000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0xa94000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S5_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c13_default>;
> + pinctrl-1 = <&qup_i2c13_sleep>;
> + interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi13: spi at a94000 {
> + compatible = "qcom,geni-spi";
> + reg = <0xa94000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S5_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi13_default>;
> + pinctrl-1 = <&qup_spi13_sleep>;
> + interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c14: i2c at a98000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0xa98000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S6_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c14_default>;
> + pinctrl-1 = <&qup_i2c14_sleep>;
> + interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi14: spi at a98000 {
> + compatible = "qcom,geni-spi";
> + reg = <0xa98000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S6_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi14_default>;
> + pinctrl-1 = <&qup_spi14_sleep>;
> + interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + i2c15: i2c at a9c000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0xa9c000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S7_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c15_default>;
> + pinctrl-1 = <&qup_i2c15_sleep>;
> + interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi15: spi at a9c000 {
> + compatible = "qcom,geni-spi";
> + reg = <0xa9c000 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP1_S7_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi15_default>;
> + pinctrl-1 = <&qup_spi15_sleep>;
> + interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> + };
> +
> tcsr_mutex_regs: syscon at 1f40000 {
> compatible = "syscon";
> reg = <0x1f40000 0x40000>;
> @@ -219,6 +738,500 @@
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
> +
> + qup_i2c0_default: qup-i2c0-default {
> + pinmux {
> + pins = "gpio0", "gpio1";
> + function = "qup0";
> + };
> + };
> +
> + qup_i2c0_sleep: qup-i2c0-sleep {
> + pinmux {
> + pins = "gpio0", "gpio1";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c1_default: qup-i2c1-default {
> + pinmux {
> + pins = "gpio17", "gpio18";
> + function = "qup1";
> + };
> + };
> +
> + qup_i2c1_sleep: qup-i2c1-sleep {
> + pinmux {
> + pins = "gpio17", "gpio18";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c2_default: qup-i2c2-default {
> + pinmux {
> + pins = "gpio27", "gpio28";
> + function = "qup2";
> + };
> + };
> +
> + qup_i2c2_sleep: qup-i2c2-sleep {
> + pinmux {
> + pins = "gpio27", "gpio28";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c3_default: qup-i2c3-default {
> + pinmux {
> + pins = "gpio41", "gpio42";
> + function = "qup3";
> + };
> + };
> +
> + qup_i2c3_sleep: qup-i2c3-sleep {
> + pinmux {
> + pins = "gpio41", "gpio42";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c4_default: qup-i2c4-default {
> + pinmux {
> + pins = "gpio89", "gpio90";
> + function = "qup4";
> + };
> + };
> +
> + qup_i2c4_sleep: qup-i2c4-sleep {
> + pinmux {
> + pins = "gpio89", "gpio90";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c5_default: qup-i2c5-default {
> + pinmux {
> + pins = "gpio85", "gpio86";
> + function = "qup5";
> + };
> + };
> +
> + qup_i2c5_sleep: qup-i2c5-sleep {
> + pinmux {
> + pins = "gpio85", "gpio86";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c6_default: qup-i2c6-default {
> + pinmux {
> + pins = "gpio45", "gpio46";
> + function = "qup6";
> + };
> + };
> +
> + qup_i2c6_sleep: qup-i2c6-sleep {
> + pinmux {
> + pins = "gpio45", "gpio46";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c7_default: qup-i2c7-default {
> + pinmux {
> + pins = "gpio93", "gpio94";
> + function = "qup7";
> + };
> + };
> +
> + qup_i2c7_sleep: qup-i2c7-sleep {
> + pinmux {
> + pins = "gpio93", "gpio94";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c8_default: qup-i2c8-default {
> + pinmux {
> + pins = "gpio65", "gpio66";
> + function = "qup8";
> + };
> + };
> +
> + qup_i2c8_sleep: qup-i2c8-sleep {
> + pinmux {
> + pins = "gpio65", "gpio66";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c9_default: qup-i2c9-default {
> + pinmux {
> + pins = "gpio6", "gpio7";
> + function = "qup9";
> + };
> + };
> +
> + qup_i2c9_sleep: qup-i2c9-sleep {
> + pinmux {
> + pins = "gpio6", "gpio7";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c10_default: qup-i2c10-default {
> + pinmux {
> + pins = "gpio55", "gpio56";
> + function = "qup10";
> + };
> + };
> +
> + qup_i2c10_sleep: qup-i2c10-sleep {
> + pinmux {
> + pins = "gpio55", "gpio56";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c11_default: qup-i2c11-default {
> + pinmux {
> + pins = "gpio31", "gpio32";
> + function = "qup11";
> + };
> + };
> +
> + qup_i2c11_sleep: qup-i2c11-sleep {
> + pinmux {
> + pins = "gpio31", "gpio32";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c12_default: qup-i2c12-default {
> + pinmux {
> + pins = "gpio49", "gpio50";
> + function = "qup12";
> + };
> + };
> +
> + qup_i2c12_sleep: qup-i2c12-sleep {
> + pinmux {
> + pins = "gpio49", "gpio50";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c13_default: qup-i2c13-default {
> + pinmux {
> + pins = "gpio105", "gpio106";
> + function = "qup13";
> + };
> + };
> +
> + qup_i2c13_sleep: qup-i2c13-sleep {
> + pinmux {
> + pins = "gpio105", "gpio106";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c14_default: qup-i2c14-default {
> + pinmux {
> + pins = "gpio33", "gpio34";
> + function = "qup14";
> + };
> + };
> +
> + qup_i2c14_sleep: qup-i2c14-sleep {
> + pinmux {
> + pins = "gpio33", "gpio34";
> + function = "gpio";
> + };
> + };
> +
> + qup_i2c15_default: qup-i2c15-default {
> + pinmux {
> + pins = "gpio81", "gpio82";
> + function = "qup15";
> + };
> + };
> +
> + qup_i2c15_sleep: qup-i2c15-sleep {
> + pinmux {
> + pins = "gpio81", "gpio82";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi0_default: qup-spi0-default {
> + pinmux {
> + pins = "gpio0", "gpio1",
> + "gpio2", "gpio3";
> + function = "qup0";
> + };
> + };
> +
> + qup_spi0_sleep: qup-spi0-sleep {
> + pinmux {
> + pins = "gpio0", "gpio1",
> + "gpio2", "gpio3";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi1_default: qup-spi1-default {
> + pinmux {
> + pins = "gpio17", "gpio18",
> + "gpio19", "gpio20";
> + function = "qup1";
> + };
> + };
> +
> + qup_spi1_sleep: qup-spi1-sleep {
> + pinmux {
> + pins = "gpio17", "gpio18",
> + "gpio19", "gpio20";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi2_default: qup-spi2-default {
> + pinmux {
> + pins = "gpio27", "gpio28",
> + "gpio29", "gpio30";
> + function = "qup2";
> + };
> + };
> +
> + qup_spi2_sleep: qup-spi2-sleep {
> + pinmux {
> + pins = "gpio27", "gpio28",
> + "gpio29", "gpio30";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi3_default: qup-spi3-default {
> + pinmux {
> + pins = "gpio41", "gpio42",
> + "gpio43", "gpio44";
> + function = "qup3";
> + };
> + };
> +
> + qup_spi3_sleep: qup-spi3-sleep {
> + pinmux {
> + pins = "gpio41", "gpio42",
> + "gpio43", "gpio44";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi4_default: qup-spi4-default {
> + pinmux {
> + pins = "gpio89", "gpio90",
> + "gpio91", "gpio92";
> + function = "qup4";
> + };
> + };
> +
> + qup_spi4_sleep: qup-spi4-sleep {
> + pinmux {
> + pins = "gpio89", "gpio90",
> + "gpio91", "gpio92";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi5_default: qup-spi5-default {
> + pinmux {
> + pins = "gpio85", "gpio86",
> + "gpio87", "gpio88";
> + function = "qup5";
> + };
> + };
> +
> + qup_spi5_sleep: qup-spi5-sleep {
> + pinmux {
> + pins = "gpio85", "gpio86",
> + "gpio87", "gpio88";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi6_default: qup-spi6-default {
> + pinmux {
> + pins = "gpio45", "gpio46",
> + "gpio47", "gpio48";
> + function = "qup6";
> + };
> + };
> +
> + qup_spi6_sleep: qup-spi6-sleep {
> + pinmux {
> + pins = "gpio45", "gpio46",
> + "gpio47", "gpio48";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi7_default: qup-spi7-default {
> + pinmux {
> + pins = "gpio93", "gpio94",
> + "gpio95", "gpio96";
> + function = "qup7";
> + };
> + };
> +
> + qup_spi7_sleep: qup-spi7-sleep {
> + pinmux {
> + pins = "gpio93", "gpio94",
> + "gpio95", "gpio96";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi8_default: qup-spi8-default {
> + pinmux {
> + pins = "gpio65", "gpio66",
> + "gpio67", "gpio68";
> + function = "qup8";
> + };
> + };
> +
> + qup_spi8_sleep: qup-spi8-sleep {
> + pinmux {
> + pins = "gpio65", "gpio66",
> + "gpio67", "gpio68";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi9_default: qup-spi9-default {
> + pinmux {
> + pins = "gpio6", "gpio7",
> + "gpio4", "gpio5";
> + function = "qup9";
> + };
> + };
> +
> + qup_spi9_sleep: qup-spi9-sleep {
> + pinmux {
> + pins = "gpio6", "gpio7",
> + "gpio4", "gpio5";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi10_default: qup-spi10-default {
> + pinmux {
> + pins = "gpio55", "gpio56",
> + "gpio53", "gpio54";
> + function = "qup10";
> + };
> + };
> +
> + qup_spi10_sleep: qup-spi10-sleep {
> + pinmux {
> + pins = "gpio55", "gpio56",
> + "gpio53", "gpio54";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi11_default: qup-spi11-default {
> + pinmux {
> + pins = "gpio31", "gpio32",
> + "gpio33", "gpio34";
> + function = "qup11";
> + };
> + };
> +
> + qup_spi11_sleep: qup-spi11-sleep {
> + pinmux {
> + pins = "gpio31", "gpio32",
> + "gpio33", "gpio34";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi12_default: qup-spi12-default {
> + pinmux {
> + pins = "gpio49", "gpio50",
> + "gpio51", "gpio52";
> + function = "qup12";
> + };
> + };
> +
> + qup_spi12_sleep: qup-spi12-sleep {
> + pinmux {
> + pins = "gpio49", "gpio50",
> + "gpio51", "gpio52";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi13_default: qup-spi13-default {
> + pinmux {
> + pins = "gpio105", "gpio106",
> + "gpio107", "gpio108";
> + function = "qup13";
> + };
> + };
> +
> + qup_spi13_sleep: qup-spi13-sleep {
> + pinmux {
> + pins = "gpio105", "gpio106",
> + "gpio107", "gpio108";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi14_default: qup-spi14-default {
> + pinmux {
> + pins = "gpio33", "gpio34",
> + "gpio31", "gpio32";
> + function = "qup14";
> + };
> + };
> +
> + qup_spi14_sleep: qup-spi14-sleep {
> + pinmux {
> + pins = "gpio33", "gpio34",
> + "gpio31", "gpio32";
> + function = "gpio";
> + };
> + };
> +
> + qup_spi15_default: qup-spi15-default {
> + pinmux {
> + pins = "gpio81", "gpio82",
> + "gpio83", "gpio84";
> + function = "qup15";
> + };
> + };
> +
> + qup_spi15_sleep: qup-spi15-sleep {
> + pinmux {
> + pins = "gpio81", "gpio82",
> + "gpio83", "gpio84";
> + function = "gpio";
> + };
> + };
> +
> + qup_uart9_default: qup-uart9-default {
> + pinmux {
> + pins = "gpio4", "gpio5";
> + function = "qup9";
> + };
> + };
> +
> + qup_uart9_sleep: qup-uart9-sleep {
> + pinmux {
> + pins = "gpio4", "gpio5";
> + function = "gpio";
> + };
> + };
> };
>
> spmi_bus: spmi at c440000 {
> --
> 2.17.1.1185.g55be947832-goog
>
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: sdm845: Enable debug UART and I2C10 on sdm845-mtp
From: Bjorn Andersson @ 2018-06-12 5:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607204608.27688-2-dianders@chromium.org>
On Thu 07 Jun 13:46 PDT 2018, Douglas Anderson wrote:
> The debug UART is very useful to have. I2C10 is enabled as an example
> of a I2C port we can talk on for now. Eventually we'll want to put
> peripherals under it.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
>
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 52 +++++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> index 979ab49913f1..e1eda143a725 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> @@ -12,4 +12,56 @@
> / {
> model = "Qualcomm Technologies, Inc. SDM845 MTP";
> compatible = "qcom,sdm845-mtp";
> +
> + aliases {
> + serial0 = &uart9;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&i2c10 {
> + status = "okay";
> + clock-frequency = <400000>;
> +};
> +
> +&qupv3_id_1 {
> + status = "okay";
> +};
> +
> +&uart9 {
> + status = "okay";
> +};
> +
> +/* PINCTRL - additions to nodes defined in sdm845.dtsi */
> +
> +&qup_i2c10_default {
> + pinconf {
> + pins = "gpio55", "gpio56";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
> +&qup_uart9_default {
> + pinconf-tx {
> + pins = "gpio4";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + pinconf-rx {
> + pins = "gpio5";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> +};
> +
> +&qup_uart9_sleep {
> + pinconf {
> + pins = "gpio4", "gpio5";
> + bias-pull-down;
> + };
> };
> --
> 2.17.1.1185.g55be947832-goog
>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
From: Doug Anderson @ 2018-06-12 5:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612050108.GU510@tuxbook-pro>
Hi,
On Mon, Jun 11, 2018 at 10:01 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Thu 07 Jun 13:46 PDT 2018, Douglas Anderson wrote:
>
>> This adds nodes to SDM845-dtsi for all the I2C ports, all the SPI
>> ports, and UART9. Note that I2C / SPI / UART are a bit strange on
>> sdm845 because each "serial engine" has 4 pins associated with it and
>> depending on which firmware has been loaded into the serial engine
>> (loaded by the BIOS) the serial engine can behave like an I2C port, a
>> SPI port, or a UART. As per the landed bindings that means that we
>> need to create one node for each possible mode that the port could be
>> in. With 16 serial engines that means 16 x 3 = 48 nodes.
>>
>> We get away with only creating 33 nodes for now because it seems very
>> likely that SDM845-based boards will actually all use the same UART
>> (UART 9) for debug purposes. While another UART could be used for
>> something like Bluetooth communication we can cross that path when we
>> come to it. Some documentation that I saw implied that using a UART
>> for "high speed" communications actually needs yet another different
>> serial engine firmware anyway.
>>
>> Note that quick measurements adding all these nodes adds ~10k of extra
>> space per dtb that they're included with. If this becomes a problem
>> we may need to think of a different way to structure this so that
>> boards only get the nodes they need (or figure out how to get dtc to
>> strip 'disabled' nodes). For now it seems OK.
>>
>> These nodes were programmatically generated with a fairly dumb python
>> script. See http://crosreview.com/1091631 for the source.
>>
>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Thanks for the review!
One note is that I have since come to find that it might not be so
wise to define the sleep pinctrl state here. For the SPI driver at
least I dug in and I saw the the sleep state is selected when we're
runtime PMed. ...and with the currently posted SPI driver that can
happen in some cases even when the chip select is supposed to be kept
low. For now it's more prudent to keep the "sleep" state out of the
device tree and we can always add it in later.
I'll plan to re-spin the patch on Wednesday (I'm unavailable tomorrow).
For other's reference: I chatted offline with Bjorn offline and this
sounded fine to him.
-Doug
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-12 6:36 UTC (permalink / raw)
To: linux-arm-kernel
The start of the linear region map on a KASLR enabled ARM64 machine -
which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
support), is no longer correctly represented by the PAGE_OFFSET macro,
since it is defined as:
(UL(1) << (VA_BITS - 1)) + 1)
So taking an example of a platform with VA_BITS=48, this gives a static
value of:
PAGE_OFFSET = 0xffff800000000000
However, for the KASLR case, we use the 'memstart_offset_seed'
to randomize the linear region - since 'memstart_addr' indicates the
start of physical RAM, we randomize the same on basis
of 'memstart_offset_seed' value.
As the PAGE_OFFSET value is used presently by several user space
tools (for e.g. makedumpfile and crash tools) to determine the start
of linear region and hence to read addresses (like PT_NOTE fields) from
'/proc/kcore' for the non-KASLR boot cases, so it would be better to
use 'memblock_start_of_DRAM()' value (converted to virtual) as
the start of linear region for the KASLR cases and default to
the PAGE_OFFSET value for non-KASLR cases to indicate the start of
linear region.
I tested this on my qualcomm (which supports EFI_RNG_PROTOCOL)
and apm mustang (which does not support EFI_RNG_PROTOCOL) arm64 boards
and was able to use a modified user space utility (like kexec-tools and
makedumpfile) to determine the start of linear region correctly for
both the KASLR and non-KASLR boot cases.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: James Morse <james.morse@arm.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
---
arch/arm64/include/asm/memory.h | 3 +++
arch/arm64/kernel/arm64ksyms.c | 1 +
arch/arm64/mm/init.c | 3 +++
3 files changed, 7 insertions(+)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 49d99214f43c..bfd0915ecaf8 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -178,6 +178,9 @@ extern s64 memstart_addr;
/* PHYS_OFFSET - the physical address of the start of memory. */
#define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
+/* the virtual base of the linear region. */
+extern s64 linear_reg_start_addr;
+
/* the virtual base of the kernel image (minus TEXT_OFFSET) */
extern u64 kimage_vaddr;
diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
index d894a20b70b2..a92238ea45ff 100644
--- a/arch/arm64/kernel/arm64ksyms.c
+++ b/arch/arm64/kernel/arm64ksyms.c
@@ -42,6 +42,7 @@ EXPORT_SYMBOL(__arch_copy_in_user);
/* physical memory */
EXPORT_SYMBOL(memstart_addr);
+EXPORT_SYMBOL(linear_reg_start_addr);
/* string / mem functions */
EXPORT_SYMBOL(strchr);
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 325cfb3b858a..29447adb0eef 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -60,6 +60,7 @@
* that cannot be mistaken for a real physical address.
*/
s64 memstart_addr __ro_after_init = -1;
+s64 linear_reg_start_addr __ro_after_init = PAGE_OFFSET;
phys_addr_t arm64_dma_phys_limit __ro_after_init;
#ifdef CONFIG_BLK_DEV_INITRD
@@ -452,6 +453,8 @@ void __init arm64_memblock_init(void)
}
}
+ linear_reg_start_addr = __phys_to_virt(memblock_start_of_DRAM());
+
/*
* Register the kernel text, kernel data, initrd, and initial
* pagetables with memblock.
--
2.7.4
^ permalink raw reply related
* [PATCH v13 0/3] Fix issues with huge mapping in ioremap for ARM64
From: Chintan Pandya @ 2018-06-12 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606154520.GM6631@arm.com>
Hi Andrew,
On 6/6/2018 9:15 PM, Will Deacon wrote:
[...]
> On Wed, Jun 06, 2018 at 12:31:18PM +0530, Chintan Pandya wrote:
>> This series of patches re-bring huge vmap back for arm64.
>>
>> Patch 1/3 has been taken by Toshi in his series of patches
>> by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86"
>> to avoid merge conflict with this series.
>>
[...]
>
>> arch/arm64/include/asm/tlbflush.h | 7 ++++++
>> arch/arm64/mm/mmu.c | 48 +++++++++++++++++++++++++++++++++++----
>> arch/x86/mm/pgtable.c | 8 ++++---
>> include/asm-generic/pgtable.h | 8 +++----
>> lib/ioremap.c | 4 ++--
>
> If you get an ack from the x86 folks, then I could take all of this via
> arm64. Alternatively, now that I've reviewed the series this could happily
> go via another tree (e.g. akpm).
>
Would you be able to take a look at this series ?
- 1/3 has been reviewed by Will and Toshi (as it touches arm64 and x86).
- 2/3 & 3/3 are arm64 specific changes.
If you think to take these patches, great ! Otherwise, I will try to
reach-out to x86 folks for their ack.
> Thanks,
>
> Will
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Ard Biesheuvel @ 2018-06-12 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528785361-24477-1-git-send-email-bhsharma@redhat.com>
On 12 June 2018 at 08:36, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> The start of the linear region map on a KASLR enabled ARM64 machine -
> which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
> support), is no longer correctly represented by the PAGE_OFFSET macro,
> since it is defined as:
>
> (UL(1) << (VA_BITS - 1)) + 1)
>
PAGE_OFFSET is the VA of the start of the linear map. The linear map
can be sparsely populated with actual memory, regardless of whether
KASLR is in effect or not. The only difference in the presence of
KASLR is that there may be such a hole at the beginning, but that does
not mean the linear map has moved, or that the value of PAGE_OFFSET is
now wrong.
> So taking an example of a platform with VA_BITS=48, this gives a static
> value of:
> PAGE_OFFSET = 0xffff800000000000
>
> However, for the KASLR case, we use the 'memstart_offset_seed'
> to randomize the linear region - since 'memstart_addr' indicates the
> start of physical RAM, we randomize the same on basis
> of 'memstart_offset_seed' value.
>
> As the PAGE_OFFSET value is used presently by several user space
> tools (for e.g. makedumpfile and crash tools) to determine the start
> of linear region and hence to read addresses (like PT_NOTE fields) from
> '/proc/kcore' for the non-KASLR boot cases, so it would be better to
> use 'memblock_start_of_DRAM()' value (converted to virtual) as
> the start of linear region for the KASLR cases and default to
> the PAGE_OFFSET value for non-KASLR cases to indicate the start of
> linear region.
>
Userland code that assumes that the linear map cannot have a hole at
the beginning should be fixed.
> I tested this on my qualcomm (which supports EFI_RNG_PROTOCOL)
> and apm mustang (which does not support EFI_RNG_PROTOCOL) arm64 boards
> and was able to use a modified user space utility (like kexec-tools and
> makedumpfile) to determine the start of linear region correctly for
> both the KASLR and non-KASLR boot cases.
>
Can you explain the nature of the changes to the userland code?
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: James Morse <james.morse@arm.com>
> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
> ---
> arch/arm64/include/asm/memory.h | 3 +++
> arch/arm64/kernel/arm64ksyms.c | 1 +
> arch/arm64/mm/init.c | 3 +++
> 3 files changed, 7 insertions(+)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 49d99214f43c..bfd0915ecaf8 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -178,6 +178,9 @@ extern s64 memstart_addr;
> /* PHYS_OFFSET - the physical address of the start of memory. */
> #define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
>
> +/* the virtual base of the linear region. */
> +extern s64 linear_reg_start_addr;
> +
> /* the virtual base of the kernel image (minus TEXT_OFFSET) */
> extern u64 kimage_vaddr;
>
> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
> index d894a20b70b2..a92238ea45ff 100644
> --- a/arch/arm64/kernel/arm64ksyms.c
> +++ b/arch/arm64/kernel/arm64ksyms.c
> @@ -42,6 +42,7 @@ EXPORT_SYMBOL(__arch_copy_in_user);
>
> /* physical memory */
> EXPORT_SYMBOL(memstart_addr);
> +EXPORT_SYMBOL(linear_reg_start_addr);
>
> /* string / mem functions */
> EXPORT_SYMBOL(strchr);
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 325cfb3b858a..29447adb0eef 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -60,6 +60,7 @@
> * that cannot be mistaken for a real physical address.
> */
> s64 memstart_addr __ro_after_init = -1;
> +s64 linear_reg_start_addr __ro_after_init = PAGE_OFFSET;
> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>
> #ifdef CONFIG_BLK_DEV_INITRD
> @@ -452,6 +453,8 @@ void __init arm64_memblock_init(void)
> }
> }
>
> + linear_reg_start_addr = __phys_to_virt(memblock_start_of_DRAM());
> +
> /*
> * Register the kernel text, kernel data, initrd, and initial
> * pagetables with memblock.
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] pwm: stm32: fix build warning with CONFIG_DMA_ENGINE disabled
From: Geert Uytterhoeven @ 2018-06-12 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180525210843.1821071-1-arnd@arndb.de>
Hi Arnd,
On Fri, May 25, 2018 at 11:09 PM Arnd Bergmann <arnd@arndb.de> wrote:
> Without dmaengine support, we get a harmless warning about an
> unused function:
>
> drivers/pwm/pwm-stm32.c:166:12: error: 'stm32_pwm_capture' defined but not used [-Werror=unused-function]
>
> Changing the #ifdef to an IS_ENABLED() check shuts up that warning
> and is slightly nicer to read.
>
> Fixes: 53e38fe73f94 ("pwm: stm32: Add capture support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks!
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> --- a/drivers/pwm/pwm-stm32.c
> +++ b/drivers/pwm/pwm-stm32.c
> @@ -484,9 +484,7 @@ static int stm32_pwm_apply_locked(struct pwm_chip *chip, struct pwm_device *pwm,
> static const struct pwm_ops stm32pwm_ops = {
> .owner = THIS_MODULE,
> .apply = stm32_pwm_apply_locked,
> -#if IS_ENABLED(CONFIG_DMA_ENGINE)
> - .capture = stm32_pwm_capture,
> -#endif
> + .capture = IS_ENABLED(CONFIG_DMA_ENGINE) ? stm32_pwm_capture : NULL,
Cool, I didn't know IS_ENABLED() can be used in static initializers.
I guess it's too late/much work to use this trick in e.g. SET_*_PM_OPS(),
as there are lots of places protecting the functions by #ifdefs?
> };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [PATCH] arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag
From: Marek Szyprowski @ 2018-06-12 7:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611123104.GD1050@arm.com>
On 2018-06-11 14:31, Will Deacon wrote:
> On Mon, Jun 11, 2018 at 09:55:54AM +0200, Geert Uytterhoeven wrote:
>> Hi Marek,
>>
>> Thanks for your patch!
>>
>> On Mon, Jun 11, 2018 at 7:14 AM Marek Szyprowski
>> <m.szyprowski@samsung.com> wrote:
>>> dma_alloc_*() buffers might be exposed to userspace via mmap() call, so
>>> they should be cleared on allocation. In case of IOMMU-based dma-mapping
>>> implementation such buffer clearing was missing in the code path for
>>> DMA_ATTR_FORCE_CONTIGUOUS flag handling. This patch fixes this issue. For
>> Is it? The memory is allocated using dma_alloc_from_contiguous(..., gfp),
>> and __iommu_alloc_attrs() has
>>
>> /*
>> * Some drivers rely on this, and we probably don't want the
>> * possibility of stale kernel data being read by devices anyway.
>> */
>> gfp |= __GFP_ZERO;
>>
>> at the top, before the allocation.
>>
>> If cma_alloc() (called from dma_alloc_from_contiguous()) doesn't honor
>> __GFP_ZERO, I think cma_alloc() should be fixed instead.
> Agreed. We tried to fix this in 7132813c3845 ("arm64: Honor __GFP_ZERO in
> dma allocations"). Has something broken that?
The code for handling DMA_ATTR_FORCE_CONTIGUOUS flag in arm64
dma-mapping/iommu
implementation has been added later and assumed that __GFP_ZERO flag is
handled by dma_alloc_from_contiguous(). This is sadly not true, so the
buffer
allocated this way is not cleared.
In case of ARM (32bit) the newly allocated buffer is always cleared directly
after calling dma_alloc_from_contiguous() function.
I agree that adding handling of __GFP_ZERO flag to
dma_alloc_from_contiguous()
or rather cma_alloc() is a better idea, but might have some side effects, so
such change is not a good candidate for -rc cycle. I will prepare such
patch,
but for now this one is imho a bit less invasive approach.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag
From: Geert Uytterhoeven @ 2018-06-12 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612073124eucas1p18fd911ee122fea0939df7ef1c88b127c~3WTVvPusx0398003980eucas1p1H@eucas1p1.samsung.com>
Hi Marek,
On Tue, Jun 12, 2018 at 9:31 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> On 2018-06-11 14:31, Will Deacon wrote:
> > On Mon, Jun 11, 2018 at 09:55:54AM +0200, Geert Uytterhoeven wrote:
> >> On Mon, Jun 11, 2018 at 7:14 AM Marek Szyprowski
> >> <m.szyprowski@samsung.com> wrote:
> >>> dma_alloc_*() buffers might be exposed to userspace via mmap() call, so
> >>> they should be cleared on allocation. In case of IOMMU-based dma-mapping
> >>> implementation such buffer clearing was missing in the code path for
> >>> DMA_ATTR_FORCE_CONTIGUOUS flag handling. This patch fixes this issue. For
> >> Is it? The memory is allocated using dma_alloc_from_contiguous(..., gfp),
> >> and __iommu_alloc_attrs() has
> >>
> >> /*
> >> * Some drivers rely on this, and we probably don't want the
> >> * possibility of stale kernel data being read by devices anyway.
> >> */
> >> gfp |= __GFP_ZERO;
> >>
> >> at the top, before the allocation.
> >>
> >> If cma_alloc() (called from dma_alloc_from_contiguous()) doesn't honor
> >> __GFP_ZERO, I think cma_alloc() should be fixed instead.
> > Agreed. We tried to fix this in 7132813c3845 ("arm64: Honor __GFP_ZERO in
> > dma allocations"). Has something broken that?
>
> The code for handling DMA_ATTR_FORCE_CONTIGUOUS flag in arm64
> dma-mapping/iommu
> implementation has been added later and assumed that __GFP_ZERO flag is
> handled by dma_alloc_from_contiguous(). This is sadly not true, so the
> buffer
> allocated this way is not cleared.
>
> In case of ARM (32bit) the newly allocated buffer is always cleared directly
> after calling dma_alloc_from_contiguous() function.
JFTR, mips and generic dma_direct_alloc() also do that, extensa does not.
> I agree that adding handling of __GFP_ZERO flag to
> dma_alloc_from_contiguous()
> or rather cma_alloc() is a better idea, but might have some side effects, so
> such change is not a good candidate for -rc cycle. I will prepare such
> patch,
> but for now this one is imho a bit less invasive approach.
OK, fine for me.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [GIT PULL] Allwinner clock changes for 4.18
From: Stephen Boyd @ 2018-06-12 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67DOgnW=gesPxgmxZJWieZkzjPJm5mt7eW15HgUP3_SZg@mail.gmail.com>
Quoting Chen-Yu Tsai (2018-06-11 00:53:41)
> Hi,
>
> On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
> > Hi Maxime,
> >
> >
> > 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
> >> Hi Mike, Stephen,
> >>
> >> Please merge the following changes for the next merge window, thanks!
> >>
> >> Maxime
> >>
> >> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
> >>
> >> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
> >>
> >> are available in the Git repository at:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
> >>
> >> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
> >>
> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
> >>
> >> ----------------------------------------------------------------
> >> Allwinner clock changes for 4.18
> >>
> >> Not a lot of changes for this release, but two quite important features
> >> were added: the H6 PRCM clock support, and the needed changes to the R40
> >> clock driver to allow for the EMAC to operate.
> >>
> >> ----------------------------------------------------------------
> >> Icenowy Zheng (3):
> >> clk: sunxi-ng: add support for H6 PRCM CCU
> >> clk: sunxi-ng: r40: rewrite init code to a platform driver
> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register
> >>
> >
> >
> >
> > Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
> > not included in the pull request?
> >
> >
> > You said "I've picked it up"
> > https://patchwork.kernel.org/patch/10348031/
>
> It looks like it was accidentally dropped after a rebase.
> Not quite sure what happened there. Maxime?
>
I can directly pick and send as fix for clk-fixes targeting rc2.
^ permalink raw reply
* [PATCH v4 1/7] dt-bindings: clk: at91: add an I2S mux clock
From: Stephen Boyd @ 2018-06-12 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18f6871e-794d-3ea2-487e-32399a8b89b4@microchip.com>
Quoting Codrin Ciubotariu (2018-06-07 03:30:14)
> >
> > Seems to me that clock additions could use a new binding and we start
> > with a new driver that handles these few clocks initially. But I
> > haven't looked whether both can coexist.
>
> Mark already applied to broonie/sound.git the I2S bindings that have a
> phandle to this clock. If I am to change #clock-cells to 1, I will have
> to change the bindings to include the clock-id.
> Which approach should I take now?
>
You're talking about changing the example in the binding doc? That
doesn't really matter. Consumer side of the provider has to match the
cell count from the provider so it doesn't really need to be 'fixed' in
the example at all.
^ permalink raw reply
* [PATCH v6 3/5] dt-bindings: timer: add i.MX EPIT timer binding
From: Clément Péron @ 2018-06-12 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611181042.GA30888@rob-hp-laptop>
Hi Rob,
On Mon, 11 Jun 2018 at 20:10, Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Jun 07, 2018 at 04:05:42PM +0200, Cl?ment P?ron wrote:
> > From: Cl?ment Peron <clement.peron@devialet.com>
> >
> > Add devicetree binding document for NXP's i.MX SoC specific
> > EPIT timer driver.
> >
> > Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> > ---
> > .../devicetree/bindings/timer/fsl,imxepit.txt | 21 +++++++++++++++++++
> > 1 file changed, 21 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/timer/fsl,imxepit.txt
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Thanks, I posted the v7 yesterday, could you add your tag to the new release ?
Regards,
Clement
^ permalink raw reply
* [clk:clk-bcm-stingray 1/2] drivers/clk/bcm/clk-sr.c:217:3: error: 'BCM_SR_LCPLL0_SATA_REF_CLK' undeclared here (not in a function); did you mean 'BCM_SR_LCPLL0_SATA_REFN_CLK'?
From: Stephen Boyd @ 2018-06-12 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <016e740bcf20db8fa753c6686812ce76@mail.gmail.com>
Quoting Ray Jui (2018-06-06 14:00:06)
> Hi Stephen,
>
> I'd like to confirm this kbuild error is caused by changing of the defines
> in the header.
>
> That is, kbuild test should pass with 2/2 patch.
>
> If my understanding is incorrect and this requires any further action,
> please let me know.
Don't think so. Linus merged clk-next over the weekend. Either I applied
the patches in the wrong order, or you sent them in the wrong order. In
the future, please compile test each patch in isolation. I do that
sometimes, but not always as it's still a manual process for me. I need
to update my scripts to make that better, which I'll do shortly.
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Bhupesh Sharma @ 2018-06-12 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8Hs+CArdkAWoBPbr_p-nq5+0oPwOPg0NsJDRMkE_bM9A@mail.gmail.com>
Hi Ard,
On Tue, Jun 12, 2018 at 12:23 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 12 June 2018 at 08:36, Bhupesh Sharma <bhsharma@redhat.com> wrote:
>> The start of the linear region map on a KASLR enabled ARM64 machine -
>> which supports a compatible EFI firmware (with EFI_RNG_PROTOCOL
>> support), is no longer correctly represented by the PAGE_OFFSET macro,
>> since it is defined as:
>>
>> (UL(1) << (VA_BITS - 1)) + 1)
>>
>
> PAGE_OFFSET is the VA of the start of the linear map. The linear map
> can be sparsely populated with actual memory, regardless of whether
> KASLR is in effect or not. The only difference in the presence of
> KASLR is that there may be such a hole at the beginning, but that does
> not mean the linear map has moved, or that the value of PAGE_OFFSET is
> now wrong.
>
>> So taking an example of a platform with VA_BITS=48, this gives a static
>> value of:
>> PAGE_OFFSET = 0xffff800000000000
>>
>> However, for the KASLR case, we use the 'memstart_offset_seed'
>> to randomize the linear region - since 'memstart_addr' indicates the
>> start of physical RAM, we randomize the same on basis
>> of 'memstart_offset_seed' value.
>>
>> As the PAGE_OFFSET value is used presently by several user space
>> tools (for e.g. makedumpfile and crash tools) to determine the start
>> of linear region and hence to read addresses (like PT_NOTE fields) from
>> '/proc/kcore' for the non-KASLR boot cases, so it would be better to
>> use 'memblock_start_of_DRAM()' value (converted to virtual) as
>> the start of linear region for the KASLR cases and default to
>> the PAGE_OFFSET value for non-KASLR cases to indicate the start of
>> linear region.
>>
>
> Userland code that assumes that the linear map cannot have a hole at
> the beginning should be fixed.
That is a separate case (although that needs fixing as well via a
kernel patch probably as the user-space tools rely on '/proc/iomem'
contents to determine the first System RAM/reserved range).
1. In that particular case (see [1]) the EFI firmware sets the first
EFI block as EfiReservedMemType:
Region1: 0x000000000000-0x000000200000 [EfiReservedMemType]
Region2: 0x000000200000-0x00000021fffff [EfiRuntimeServiceData]
Since EFI firmware won't return the "EfiReservedMemType" memory to
Linux kernel, so the kernel can't get any info about the first mem
block, and kernel can only see region2 as below:
efi: Processing EFI memory map:
efi: 0x000000200000-0x00000021ffff [Runtime Data |RUN| | |
| | | | |WB|WT|WC|UC]
# head -1 /proc/iomem
00200000-0021ffff : reserved
2a. If we add debug prints to 'arch/arm64/mm/init.c' to print the
kernel Virtual map we can see that the memory node is set to:
# dmesg | grep memory
..........
memory : 0xffff800000200000 - 0xffff801800000000
2b. Now if we use kexec-tools to obtain a crash vmcore we can see that
if we use 'readelf' to get the last program Header from vmcore (logs
below are for the non-kaslr case):
# readelf -l vmcore
ELF Header:
........................
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
..............................................................................................................................................................
LOAD 0x0000000076d40000 0xffff80017fe00000 0x0000000180000000
0x0000001680000000 0x0000001680000000 RWE 0
3. So if we do a simple calculation:
(VirtAddr + MemSiz) = 0xffff80017fe00000 + 0x0000001680000000 =
0xFFFF8017FFE00000 != 0xffff801800000000.
which indicates that the end virtual memory nodes are not the same
between vmlinux and vmcore.
This happens because the kexec-tools rely on 'proc/iomem' contents
while 'memstart_addr' is computed as 0 by kernel (as value of
memblock_start_of_DRAM() < ARM64_MEMSTART_ALIGN).
Returning back to this patch, this is a generic requirement where we
need the linear region start/base addresses in user-space applications
which is used to read addresses which lie in the linear region (for
e.g. when we read /proc/kcore contents).
>> I tested this on my qualcomm (which supports EFI_RNG_PROTOCOL)
>> and apm mustang (which does not support EFI_RNG_PROTOCOL) arm64 boards
>> and was able to use a modified user space utility (like kexec-tools and
>> makedumpfile) to determine the start of linear region correctly for
>> both the KASLR and non-KASLR boot cases.
>>
>
> Can you explain the nature of the changes to the userland code?
The changes are not to rely on the fixed PAGE_OFFSET macro value for
determining the base address of the linear region, but rather read the
' linear_reg_start_addr' symbol from kernel and use the same both in
case of KASLR and non-KASLR boots to determine the base of the linear
region (in [2], I have implemented a test change to kexec-tools to
read the 'linear_reg_start_addr' symbol which is available on my
public github tree, I have a similar change available in makedumpfile
which I have not yet pushed to github, as it implements other features
as well)
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-June/582407.html
[2] https://github.com/bhupesh-sharma/kexec-tools/commit/ae511833e948ccf864fae142ccd903f9c7b3461d
Regards,
Bhupesh
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> Cc: James Morse <james.morse@arm.com>
>> Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
>> ---
>> arch/arm64/include/asm/memory.h | 3 +++
>> arch/arm64/kernel/arm64ksyms.c | 1 +
>> arch/arm64/mm/init.c | 3 +++
>> 3 files changed, 7 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index 49d99214f43c..bfd0915ecaf8 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -178,6 +178,9 @@ extern s64 memstart_addr;
>> /* PHYS_OFFSET - the physical address of the start of memory. */
>> #define PHYS_OFFSET ({ VM_BUG_ON(memstart_addr & 1); memstart_addr; })
>>
>> +/* the virtual base of the linear region. */
>> +extern s64 linear_reg_start_addr;
>> +
>> /* the virtual base of the kernel image (minus TEXT_OFFSET) */
>> extern u64 kimage_vaddr;
>>
>> diff --git a/arch/arm64/kernel/arm64ksyms.c b/arch/arm64/kernel/arm64ksyms.c
>> index d894a20b70b2..a92238ea45ff 100644
>> --- a/arch/arm64/kernel/arm64ksyms.c
>> +++ b/arch/arm64/kernel/arm64ksyms.c
>> @@ -42,6 +42,7 @@ EXPORT_SYMBOL(__arch_copy_in_user);
>>
>> /* physical memory */
>> EXPORT_SYMBOL(memstart_addr);
>> +EXPORT_SYMBOL(linear_reg_start_addr);
>>
>> /* string / mem functions */
>> EXPORT_SYMBOL(strchr);
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 325cfb3b858a..29447adb0eef 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -60,6 +60,7 @@
>> * that cannot be mistaken for a real physical address.
>> */
>> s64 memstart_addr __ro_after_init = -1;
>> +s64 linear_reg_start_addr __ro_after_init = PAGE_OFFSET;
>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>
>> #ifdef CONFIG_BLK_DEV_INITRD
>> @@ -452,6 +453,8 @@ void __init arm64_memblock_init(void)
>> }
>> }
>>
>> + linear_reg_start_addr = __phys_to_virt(memblock_start_of_DRAM());
>> +
>> /*
>> * Register the kernel text, kernel data, initrd, and initial
>> * pagetables with memblock.
>> --
>> 2.7.4
>>
^ permalink raw reply
* [PATCH 3/3] pinctrl: actions: Add interrupt support for OWL S900 SoC
From: Linus Walleij @ 2018-06-12 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180602165415.30956-4-manivannan.sadhasivam@linaro.org>
On Sat, Jun 2, 2018 at 6:54 PM, Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
> Add interrupt support for Actions Semi OWL S900 SoC.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
(...)
> +++ b/drivers/pinctrl/actions/Kconfig
> @@ -5,6 +5,7 @@ config PINCTRL_OWL
> select PINCONF
> select GENERIC_PINCONF
> select GPIOLIB
> + select GPIOLIB_IRQCHIP
I don't think you're really using that (certain sign: you're implementing
.to_irq().)
GPIOLIB_IRQCHIP is nice, but can only be used when there is
a 1-1 correspondence betweem GPIO line offsets and
IRQ lines and they are numbered 0..n.
However I think you can use it! Look below for my reference
to the tegra186 and how you can probably cut out the custom
irqdomain with some manouvers.
> + struct owl_pinctrl *pctrl = irq_data_get_irq_chip_data(data);
> + const struct owl_gpio_port *port;
(...)
> + unsigned int gpio = data->hwirq;
> +
> + port = owl_gpio_get_port(pctrl, &gpio);
> +
> + gpio_base = pctrl->base + port->offset;
It is all about this calculation really.
> +static int owl_gpio_irq_set_type(struct irq_data *data, unsigned int type)
> +{
> + struct owl_pinctrl *pctrl = irq_data_get_irq_chip_data(data);
> + const struct owl_gpio_port *port;
> + void __iomem *gpio_base;
> + unsigned long flags;
> + unsigned int gpio = data->hwirq;
> + unsigned int offset, value, irq_type = 0;
> +
> + port = owl_gpio_get_port(pctrl, &gpio);
> + if (WARN_ON(port == NULL))
> + return -ENODEV;
> +
> + gpio_base = pctrl->base + port->offset;
> +
> + switch (type) {
> + case IRQ_TYPE_EDGE_RISING:
> + irq_type = OWL_GPIO_INT_EDGE_RISING;
> + break;
> +
> + case IRQ_TYPE_EDGE_FALLING:
> + irq_type = OWL_GPIO_INT_EDGE_FALLING;
> + break;
Very often things such as keys will request trigger on
both edges. This means IRQ_TYPE_EDGE_RISING
and IRQ_TYPE_EDGE_FALLING are both set, which
will cause you problems here, since it is unhandled.
I guess it is fine to set both?
> + offset = gpio < 16 ? 4 : 0;
I think even the compiler should suggest putting he (gpio < 16)
expression in paranthesis.
> + value = readl_relaxed(gpio_base + port->intc_type + offset);
> + value &= ~(OWL_GPIO_INT_MASK << ((gpio % 16) * 2));
> + value |= irq_type << ((gpio % 16) * 2);
> + writel_relaxed(value, gpio_base + port->intc_type + offset);
> +
> + raw_spin_unlock_irqrestore(&pctrl->lock, flags);
> +
> + if (type & IRQ_TYPE_EDGE_BOTH)
> + irq_set_handler_locked(data, handle_edge_irq);
> + else
> + irq_set_handler_locked(data, handle_level_irq);
Here you handle both edges, but not in the switch clause.
> +static void owl_gpio_irq_handler(struct irq_desc *desc)
This looks fine.
> +static struct irq_chip owl_gpio_irq_chip = {
> + .name = "owlgpio",
> + .irq_mask = owl_gpio_irq_mask,
> + .irq_unmask = owl_gpio_irq_unmask,
> + .irq_ack = owl_gpio_irq_ack,
> + .irq_set_type = owl_gpio_irq_set_type,
> +};
If you implement your own irqchip you need to implement
.irq_request_resources and .irq_free_resources locking the GPIO
lines for interrupt, see other drivers that do this or the
gpiolib core code in gpiolib.c.
It would be really neat if you could instead use the
GPIOLIB_IRQCHIP though, but I know it will be a bit tricky
and maybe not possible.
> + for (i = 0; i < pctrl->soc->nports; i++) {
> + irq_set_chained_handler_and_data(pctrl->irq[i],
> + owl_gpio_irq_handler,
> + pctrl);
> + }
If you use GPIOLIB_IRQCHIP with several parent IRQs.
See Thierry's work in drivers/gpio/gpio-tegra186.c for the
only example.
I think that is what you want to do here.
We do want to add helpers in gpiolib to do this in a more
organized and easy-to-use fashion. Patches welcome ;)
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] Allwinner clock changes for 4.18
From: Chen-Yu Tsai @ 2018-06-12 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152879040155.16708.9862482085365718831@swboyd.mtv.corp.google.com>
On Tue, Jun 12, 2018 at 4:00 PM, Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Chen-Yu Tsai (2018-06-11 00:53:41)
>> Hi,
>>
>> On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
>> <yamada.masahiro@socionext.com> wrote:
>> > Hi Maxime,
>> >
>> >
>> > 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
>> >> Hi Mike, Stephen,
>> >>
>> >> Please merge the following changes for the next merge window, thanks!
>> >>
>> >> Maxime
>> >>
>> >> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>> >>
>> >> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>> >>
>> >> are available in the Git repository at:
>> >>
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
>> >>
>> >> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
>> >>
>> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
>> >>
>> >> ----------------------------------------------------------------
>> >> Allwinner clock changes for 4.18
>> >>
>> >> Not a lot of changes for this release, but two quite important features
>> >> were added: the H6 PRCM clock support, and the needed changes to the R40
>> >> clock driver to allow for the EMAC to operate.
>> >>
>> >> ----------------------------------------------------------------
>> >> Icenowy Zheng (3):
>> >> clk: sunxi-ng: add support for H6 PRCM CCU
>> >> clk: sunxi-ng: r40: rewrite init code to a platform driver
>> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register
>> >>
>> >
>> >
>> >
>> > Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
>> > not included in the pull request?
>> >
>> >
>> > You said "I've picked it up"
>> > https://patchwork.kernel.org/patch/10348031/
>>
>> It looks like it was accidentally dropped after a rebase.
>> Not quite sure what happened there. Maxime?
>>
>
> I can directly pick and send as fix for clk-fixes targeting rc2.
The patch can still be found in the sunxi/for-next branch of the
sunxi repo on kernel.org:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/for-next&id=d4a1496286b0c29fcace4e10c0047cca7cc79b25
Or the original on patchwork:
https://patchwork.kernel.org/patch/10348027/
Thanks
ChenYu
^ permalink raw reply
* [PATCH 2/6] PCI: iproc: Add INTx support with better modeling
From: poza at codeaurora.org @ 2018-06-12 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527631130-20045-3-git-send-email-ray.jui@broadcom.com>
On 2018-05-30 03:28, Ray Jui wrote:
> Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
> modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
> INTD share the same interrupt line connected to the GIC in the system,
> while the status of each INTx can be obtained through the INTX CSR
> register
>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> ---
> drivers/pci/host/pcie-iproc-platform.c | 2 +
> drivers/pci/host/pcie-iproc.c | 95
> +++++++++++++++++++++++++++++++++-
> drivers/pci/host/pcie-iproc.h | 6 +++
> 3 files changed, 101 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-iproc-platform.c
> b/drivers/pci/host/pcie-iproc-platform.c
> index e764a2a..7a51e6c 100644
> --- a/drivers/pci/host/pcie-iproc-platform.c
> +++ b/drivers/pci/host/pcie-iproc-platform.c
> @@ -70,6 +70,8 @@ static int iproc_pcie_pltfm_probe(struct
> platform_device *pdev)
> }
> pcie->base_addr = reg.start;
>
> + pcie->irq = platform_get_irq(pdev, 0);
> +
> if (of_property_read_bool(np, "brcm,pcie-ob")) {
> u32 val;
>
> diff --git a/drivers/pci/host/pcie-iproc.c
> b/drivers/pci/host/pcie-iproc.c
> index 14f374d..0bd2c14 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -14,6 +14,7 @@
> #include <linux/delay.h>
> #include <linux/interrupt.h>
> #include <linux/irqchip/arm-gic-v3.h>
> +#include <linux/irqchip/chained_irq.h>
> #include <linux/platform_device.h>
> #include <linux/of_address.h>
> #include <linux/of_pci.h>
> @@ -264,6 +265,7 @@ enum iproc_pcie_reg {
>
> /* enable INTx */
> IPROC_PCIE_INTX_EN,
> + IPROC_PCIE_INTX_CSR,
>
> /* outbound address mapping */
> IPROC_PCIE_OARR0,
> @@ -305,6 +307,7 @@ static const u16 iproc_pcie_reg_paxb_bcma[] = {
> [IPROC_PCIE_CFG_ADDR] = 0x1f8,
> [IPROC_PCIE_CFG_DATA] = 0x1fc,
> [IPROC_PCIE_INTX_EN] = 0x330,
> + [IPROC_PCIE_INTX_CSR] = 0x334,
> [IPROC_PCIE_LINK_STATUS] = 0xf0c,
> };
>
> @@ -316,6 +319,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
> [IPROC_PCIE_CFG_ADDR] = 0x1f8,
> [IPROC_PCIE_CFG_DATA] = 0x1fc,
> [IPROC_PCIE_INTX_EN] = 0x330,
> + [IPROC_PCIE_INTX_CSR] = 0x334,
> [IPROC_PCIE_OARR0] = 0xd20,
> [IPROC_PCIE_OMAP0] = 0xd40,
> [IPROC_PCIE_OARR1] = 0xd28,
> @@ -332,6 +336,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
> [IPROC_PCIE_CFG_ADDR] = 0x1f8,
> [IPROC_PCIE_CFG_DATA] = 0x1fc,
> [IPROC_PCIE_INTX_EN] = 0x330,
> + [IPROC_PCIE_INTX_CSR] = 0x334,
> [IPROC_PCIE_OARR0] = 0xd20,
> [IPROC_PCIE_OMAP0] = 0xd40,
> [IPROC_PCIE_OARR1] = 0xd28,
> @@ -782,9 +787,90 @@ static int iproc_pcie_check_link(struct iproc_pcie
> *pcie)
> return link_is_active ? 0 : -ENODEV;
> }
>
> -static void iproc_pcie_enable(struct iproc_pcie *pcie)
> +static int iproc_pcie_intx_map(struct irq_domain *domain, unsigned int
> irq,
> + irq_hw_number_t hwirq)
> {
> + irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_simple_irq);
> + irq_set_chip_data(irq, domain->host_data);
> +
> + return 0;
> +}
> +
> +static const struct irq_domain_ops intx_domain_ops = {
> + .map = iproc_pcie_intx_map,
> +};
> +
> +static void iproc_pcie_isr(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct iproc_pcie *pcie;
> + struct device *dev;
> + unsigned long status;
> + u32 bit, virq;
> +
> + chained_irq_enter(chip, desc);
> + pcie = irq_desc_get_handler_data(desc);
> + dev = pcie->dev;
> +
> + /* go through INTx A, B, C, D until all interrupts are handled */
> + while ((status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR) &
> + SYS_RC_INTX_MASK) != 0) {
> + for_each_set_bit(bit, &status, PCI_NUM_INTX) {
> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err(dev, "unexpected INTx%u\n", bit);
> + }
> + }
> +
Are these level or edge interrupts ? although I see DT says:
IRQ_TYPE_NONE
do you not need to clear interrupt status bits in IPROC_PCIE_INTX_CSR ?
> + chained_irq_exit(chip, desc);
> +}
> +
> +static int iproc_pcie_intx_enable(struct iproc_pcie *pcie)
> +{
> + struct device *dev = pcie->dev;
> + struct device_node *node = dev->of_node;
> + int ret;
> +
> iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, SYS_RC_INTX_MASK);
> +
> + /*
> + * BCMA devices do not map INTx the same way as platform devices. All
> + * BCMA needs is the above code to enable INTx
> + */
> + if (pcie->irq <= 0)
> + return 0;
> +
> + /* set IRQ handler */
> + irq_set_chained_handler_and_data(pcie->irq, iproc_pcie_isr, pcie);
> +
> + /* add IRQ domain for INTx */
> + pcie->irq_domain = irq_domain_add_linear(node, PCI_NUM_INTX + 1,
> + &intx_domain_ops, pcie);
> + if (!pcie->irq_domain) {
> + dev_err(dev, "failed to add INTx IRQ domain\n");
> + ret = -ENOMEM;
> + goto err_rm_handler_data;
> + }
> +
> + return 0;
> +
> +err_rm_handler_data:
> + irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
> +
> + return ret;
> +}
> +
> +static void iproc_pcie_intx_disable(struct iproc_pcie *pcie)
> +{
> + iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, 0x0);
> +
> + if (pcie->irq <= 0)
> + return;
> +
> + irq_domain_remove(pcie->irq_domain);
> + irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
> }
>
> static inline bool iproc_pcie_ob_is_valid(struct iproc_pcie *pcie,
> @@ -1410,7 +1496,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie,
> struct list_head *res)
> goto err_power_off_phy;
> }
>
> - iproc_pcie_enable(pcie);
> + ret = iproc_pcie_intx_enable(pcie);
> + if (ret) {
> + dev_err(dev, "failed to enable INTx\n");
> + goto err_power_off_phy;
> + }
>
> if (IS_ENABLED(CONFIG_PCI_MSI))
> if (iproc_pcie_msi_enable(pcie))
> @@ -1455,6 +1545,7 @@ int iproc_pcie_remove(struct iproc_pcie *pcie)
> pci_remove_root_bus(pcie->root_bus);
>
> iproc_pcie_msi_disable(pcie);
> + iproc_pcie_intx_disable(pcie);
>
> phy_power_off(pcie->phy);
> phy_exit(pcie->phy);
> diff --git a/drivers/pci/host/pcie-iproc.h
> b/drivers/pci/host/pcie-iproc.h
> index 67081cb..cbcaf9d 100644
> --- a/drivers/pci/host/pcie-iproc.h
> +++ b/drivers/pci/host/pcie-iproc.h
> @@ -72,6 +72,9 @@ struct iproc_msi;
> * @ib: inbound mapping related parameters
> * @ib_map: outbound mapping region related parameters
> *
> + * @irq: interrupt line wired to the generic GIC for INTx
> + * @irq_domain: IRQ domain for INTx
> + *
> * @need_msi_steer: indicates additional configuration of the iProc
> PCIe
> * controller is required to steer MSI writes to external interrupt
> controller
> * @msi: MSI data
> @@ -99,6 +102,9 @@ struct iproc_pcie {
> struct iproc_pcie_ib ib;
> const struct iproc_pcie_ib_map *ib_map;
>
> + int irq;
> + struct irq_domain *irq_domain;
> +
> bool need_msi_steer;
> struct iproc_msi *msi;
> };
^ permalink raw reply
* [PATCH v3 0/6] add virt-dma support for imx-sdma
From: Robin Gong @ 2018-06-12 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528714877.2842.3.camel@pengutronix.de>
Hi Lucas,
Is the below DEAD LOCK issue same as your side? If yes, then
I'm afraid that we have to make another patch for uart to split dma
functions in uart driver out of the code area which protected by
port.lock. The warning make sense since allocate sdma bd memory
dynamically in virt-dma instead of static allocated as before. I'll
make another uart patch into my next version patchset.
[???46.155406] =====================================================
[???46.161503] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order
detected
[???46.168122] 4.17.0-rc6-00008-g7caafa3-dirty #48 Not tainted
[???46.173696] -----------------------------------------------------
[???46.179795] mxc_uart_stress/419 [HC0[0]:SC0[0]:HE0:SE1] is trying to
acquire:
[???46.186934] fa7c1440 (fs_reclaim){+.+.}, at:
fs_reclaim_acquire.part.3+0x0/0x48
[???46.194270]
[???46.194270] and this task is already holding:
[???46.200106] 09a17fda (&port_lock_key){-.-.}, at:
uart_write+0x84/0x190
[???46.206658] which would create a new lock dependency:
[???46.211710]??(&port_lock_key){-.-.} -> (fs_reclaim){+.+.}
[???46.217132]
[???46.217132] but this new dependency connects a HARDIRQ-irq-safe
lock:
[???46.225051]??(&port_lock_key){-.-.}
[???46.225062]
[???46.225062] ... which became HARDIRQ-irq-safe at:
[???46.234740]???lock_acquire+0x70/0x90
[???46.238326]???_raw_spin_lock_irqsave+0x40/0x54
[???46.242777]???imx_uart_console_write+0x1bc/0x1e0
[???46.247402]???console_unlock+0x320/0x5f0
[???46.251329]???vprintk_emit+0x22c/0x3fc
[???46.255082]???vprintk_default+0x28/0x30
[???46.258923]???vprintk_func+0x78/0xcc
[???46.262503]???printk+0x34/0x54
[???46.265566]???crng_fast_load+0xf8/0x138
[???46.269407]???add_interrupt_randomness+0x21c/0x24c
[???46.274204]???handle_irq_event_percpu+0x40/0x84
[???46.278739]???handle_irq_event+0x40/0x64
[???46.282667]???handle_fasteoi_irq+0xbc/0x178
[???46.286854]???generic_handle_irq+0x28/0x3c
[???46.290954]???__handle_domain_irq+0x6c/0xe8
[???46.295148]???gic_handle_irq+0x64/0xc4
[???46.298904]???__irq_svc+0x70/0x98
[???46.302225]???_raw_spin_unlock_irq+0x30/0x34
[???46.306505]???finish_task_switch+0xc0/0x27c
[???46.310693]???__schedule+0x2c0/0x79c
[???46.314272]???schedule_idle+0x40/0x84
[???46.317941]???do_idle+0x178/0x2b4
[???46.321259]???cpu_startup_entry+0x20/0x24
[???46.325278]???rest_init+0x214/0x264
[???46.328775]???start_kernel+0x39c/0x424
[???46.332527]?????(null)
[???46.334891]
[???46.334891] to a HARDIRQ-irq-unsafe lock:
[???46.340379]??(fs_reclaim){+.+.}
[???46.340391]
[???46.340391] ... which became HARDIRQ-irq-unsafe at:
[???46.349885] ...
[???46.349895]???lock_acquire+0x70/0x90
[???46.355225]???fs_reclaim_acquire.part.3+0x38/0x48
[???46.359933]???fs_reclaim_acquire+0x1c/0x20
[???46.364036]???kmem_cache_alloc+0x2c/0x174
[???46.368051]???alloc_worker.constprop.10+0x1c/0x58
[???46.372759]???init_rescuer.part.4+0x18/0xa4
[???46.376952]???workqueue_init+0xc0/0x210
[???46.380793]???kernel_init_freeable+0x58/0x1d8
[???46.385156]???kernel_init+0x10/0x11c
[???46.388736]???ret_from_fork+0x14/0x20
[???46.392399]?????(null)
[???46.394762]
[???46.394762] other info that might help us debug this:
[???46.394762]
[???46.402769]??Possible interrupt unsafe locking scenario:
[???46.402769]
[???46.409560]????????CPU0????????????????????CPU1
[???46.414092]????????----????????????????????----
[???46.418622]???lock(fs_reclaim);
[???46.421772]????????????????????????????????local_irq_disable();
[???46.427693]????????????????????????????????lock(&port_lock_key);
[???46.433707]????????????????????????????????lock(fs_reclaim);
[???46.439372]???<Interrupt>
[???46.441993]?????lock(&port_lock_key);
[???46.445661]
[???46.445661]??*** DEADLOCK ***
[???46.445661]
On ?, 2018-06-11 at 13:01 +0200, Lucas Stach wrote:
> Hi Robin,
>
> this series breaks serial DMA for me. I wasn't able to dig in deeper
> yet. Please let me know if you can test/reproduce at your side, if
> not
> I'll try to find some time to collect some more debug info.
>
> Regards,
> Lucas
>
> Am Montag, den 11.06.2018, 22:59 +0800 schrieb Robin Gong:
> >
> > The legacy sdma driver has below limitations or drawbacks:
> > ? 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and
> > alloc
> > ?????one page size for one channel regardless of only few BDs
> > needed
> > ?????most time. But in few cases, the max PAGE_SIZE maybe not
> > enough.
> > ? 2. One SDMA channel can't stop immediatley once channel disabled
> > which
> > ?????means SDMA interrupt may come in after this channel
> > terminated.There
> > ?????are some patches for this corner case such as commit
> > "2746e2c389f9",
> > ?????but not cover non-cyclic.
> >
> > The common virt-dma overcomes the above limitations. It can alloc
> > bd
> > dynamically and free bd once this tx transfer done. No memory
> > wasted or
> > maximum limititation here, only depends on how many memory can be
> > requested
> > from kernel. For No.2, such issue can be workaround by checking if
> > there
> > is available descript("sdmac->desc") now once the unwanted
> > interrupt
> > coming. At last the common virt-dma is easier for sdma driver
> > maintain.
> >
> > Change from v2:
> > ? 1. include Sascha's patch to make the main patch easier to
> > review.
> > ?????Thanks Sacha.
> > ? 2. remove useless 'desc'/'chan' in struct sdma_channe.
> >
> > Change from v1:
> > ? 1. split v1 patch into 5 patches.
> > ? 2. remove some unnecessary condition check.
> > ? 3. remove unnecessary 'pending' list.
> >
> > Robin Gong (5):
> > ? dmaengine: imx-sdma: add virt-dma support
> > ? Revert "dmaengine: imx-sdma: fix pagefault when channel is
> > disabled
> > ????during interrupt"
> > ? dmaengine: imx-sdma: remove usless lock
> > ? dmaengine: imx-sdma: remove the maximum limation for bd numbers
> > ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code
> > overlap
> >
> > ?drivers/dma/Kconfig????|???1 +
> > ?drivers/dma/imx-sdma.c | 392 ++++++++++++++++++++++++++++---------
> > ------------
> > ?2 files changed, 227 insertions(+), 166 deletions(-)
> >
> > --?
> > 2.7.4
> >
> > Robin Gong (5):
> > ? dmaengine: imx-sdma: add virt-dma support
> > ? Revert "dmaengine: imx-sdma: fix pagefault when channel is
> > disabled
> > ????during interrupt"
> > ? dmaengine: imx-sdma: remove usless lock
> > ? dmaengine: imx-sdma: remove the maximum limation for bd numbers
> > ? dmaengine: imx-sdma: add sdma_transfer_init to decrease code
> > overlap
> >
> > Sascha Hauer (1):
> > ? dmaengine: imx-sdma: factor out a struct sdma_desc from struct
> > ????sdma_channel
> >
> > ?drivers/dma/Kconfig????|???1 +
> > ?drivers/dma/imx-sdma.c | 391 ++++++++++++++++++++++++++++---------
> > ------------
> > ?2 files changed, 226 insertions(+), 166 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