* [PATCH v2 renesas/devel 10/13] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for iic nodes
From: Simon Horman @ 2016-12-13 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481629559-14187-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7790.dtsi | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 823ab536175d..ddf6a8cbe6c1 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -528,7 +528,8 @@
iic0: i2c at e6500000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe6500000 0 0x425>;
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7790_CLK_IIC0>;
@@ -542,7 +543,8 @@
iic1: i2c at e6510000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe6510000 0 0x425>;
interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7790_CLK_IIC1>;
@@ -556,7 +558,8 @@
iic2: i2c at e6520000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe6520000 0 0x425>;
interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7790_CLK_IIC2>;
@@ -570,7 +573,8 @@
iic3: i2c at e60b0000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe60b0000 0 0x425>;
interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7790_CLK_IICDVFS>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v2 renesas/devel 11/13] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for iic nodes
From: Simon Horman @ 2016-12-13 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481629559-14187-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7791 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7791 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7791.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 48662c13f79a..01599fe90fc0 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -518,7 +518,8 @@
/* doesn't need pinmux */
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7791", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe60b0000 0 0x425>;
interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7791_CLK_IICDVFS>;
@@ -532,7 +533,8 @@
i2c7: i2c at e6500000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7791", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe6500000 0 0x425>;
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7791_CLK_IIC0>;
@@ -546,7 +548,8 @@
i2c8: i2c at e6510000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7791", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe6510000 0 0x425>;
interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7791_CLK_IIC1>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v2 renesas/devel 12/13] ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for iic nodes
From: Simon Horman @ 2016-12-13 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481629559-14187-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7793 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7793 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7793.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index cbe9ac629693..d5114cac656d 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -485,7 +485,8 @@
/* doesn't need pinmux */
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7793", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe60b0000 0 0x425>;
interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7793_CLK_IICDVFS>;
@@ -499,7 +500,8 @@
i2c7: i2c at e6500000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7793", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe6500000 0 0x425>;
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7793_CLK_IIC0>;
@@ -513,7 +515,8 @@
i2c8: i2c at e6510000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7793", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe6510000 0 0x425>;
interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7793_CLK_IIC1>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v2 renesas/devel 13/13] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for iic nodes
From: Simon Horman @ 2016-12-13 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481629559-14187-1-git-send-email-horms+renesas@verge.net.au>
Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7794 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7794 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm/boot/dts/r8a7794.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 5fd382a5a7b2..e41f1c9b4a9c 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -683,7 +683,8 @@
};
i2c6: i2c at e6500000 {
- compatible = "renesas,iic-r8a7794", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7794", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe6500000 0 0x425>;
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7794_CLK_IIC0>;
@@ -697,7 +698,8 @@
};
i2c7: i2c at e6510000 {
- compatible = "renesas,iic-r8a7794", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7794", "renesas,rcar-gen2-iic",
+ "renesas,rmobile-iic";
reg = <0 0xe6510000 0 0x425>;
interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp3_clks R8A7794_CLK_IIC1>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory
From: Andrew Jeffery @ 2016-12-13 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213110710.GV3625@dell.home>
On Tue, 2016-12-13 at 11:07 +0000, Lee Jones wrote:
> On Tue, 13 Dec 2016, Andrew Jeffery wrote:
>
> > On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
> > > On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> > > > The use of syscons is growing, lets collate them in their own part of
> > > > the bindings tree.
> > > >
> > > > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > > >
> > > > ---
> > > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt?????????| 0
> > > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt?????????| 0
> > > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt???????| 0
> > > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt??????????| 0
> > > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt??????????| 0
> > > > ?Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt?????????????| 0
> > > > ?.../devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt??????????| 0
> > > > ?7 files changed, 0 insertions(+), 0 deletions(-)
> > > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt (100%)
> > > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt (100%)
> > > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt (100%)
> > > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt (100%)
> > > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt (100%)
> > > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
> > > > ?rename Documentation/devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt (100%)
> > >
> > > I'm not so sure this is the right direction. syscon usage is pretty much?
> > > spread throughout the tree.
> >
> > This patch was created based on my interpretation of Lee's feedback
> > here:
> >
> > https://lkml.org/lkml/2016/11/18/650
> >
> > Lee's next email in the chain poked Arnd for an opinion, but Arnd
> > didn't reply.
> >
> > I don't mind. I moved these bindings separately so we could just drop
> > the patch if there was push-back. If we drop the whole idea I'll need
> > to apply a small fix to patch 5/6 to avoid creating the syscon
> > subdirectory.
>
> The sub-directory is a good idea for drivers who are *solely* syscon
> based.
>
Yes, I wasn't saying otherwise, just commenting on my motivation and
approach.
As far as I can tell all of the bindings I move here describe solely
syscon-based devices.
Cheers,
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161213/d37749c2/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: vexpress: Support GICC_DIR operations
From: Sudeep Holla @ 2016-12-13 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9d9198a1-ba56-46e5-6226-89eb3825aac3@arm.com>
On 12/12/16 17:35, Marc Zyngier wrote:
> [+Sudeep]
>
> On 10/12/16 20:13, Christoffer Dall wrote:
>> The GICv2 CPU interface registers span across 8K, not 4K as indicated in
>> the DT. Only the GICC_DIR register is located after the initial 4K
>> boundary, leaving a functional system but without support for separately
>> EOI'ing and deactivating interrupts.
>>
>> After this change the system support split priority drop and interrupt
>> deactivation.
>>
>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>> ---
>> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
>> index 0205c97..2e0cf39 100644
>> --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
>> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
>> @@ -126,7 +126,7 @@
>> #address-cells = <0>;
>> interrupt-controller;
>> reg = <0 0x2c001000 0 0x1000>,
>> - <0 0x2c002000 0 0x1000>,
>> + <0 0x2c002000 0 0x2000>,
>> <0 0x2c004000 0 0x2000>,
>> <0 0x2c006000 0 0x2000>;
>> interrupts = <1 9 0xf04>;
>>
>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>
Thanks Marc, I see couple of other instances of this like tc2 and rtsm
model on arm64. Do they need to be fixed too ? I guess so. If so I will
fixup this to patch add tc1. And add another one for rtsm.
Also I see loads of gic-400 compatible dts(mainly rockchip and renasas)
having just 4k. Are they left like this intentionally ? I remember you
fixing most of the DTS when you found this issue initially.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory
From: Arnd Bergmann @ 2016-12-13 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481630734.3112.40.camel@aj.id.au>
On Tuesday, December 13, 2016 10:35:34 PM CET Andrew Jeffery wrote:
> On Tue, 2016-12-13 at 11:07 +0000, Lee Jones wrote:
> > On Tue, 13 Dec 2016, Andrew Jeffery wrote:
> > > On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
> > > > On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> > >
> > > Lee's next email in the chain poked Arnd for an opinion, but Arnd
> > > didn't reply.
> > >
> > > I don't mind. I moved these bindings separately so we could just drop
> > > the patch if there was push-back. If we drop the whole idea I'll need
> > > to apply a small fix to patch 5/6 to avoid creating the syscon
> > > subdirectory.
> >
> > The sub-directory is a good idea for drivers who are *solely* syscon
> > based.
> >
>
> Yes, I wasn't saying otherwise, just commenting on my motivation and
> approach.
>
> As far as I can tell all of the bindings I move here describe solely
> syscon-based devices.
>
But do we know which ones they are?
In principle, any syscon device node can have a specialized driver
exporting an interface, the bindings always allow it to be done
one way or the other, and we may change the driver or run a different
OS that has decided differently.
Arnd
^ permalink raw reply
* [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
From: Hans Verkuil @ 2016-12-13 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1462451666-17945-1-git-send-email-k.kozlowski@samsung.com>
Hi Krzysztof,
This still seems to be broken with the latest 4.9 kernel, right?
Has there been any progress on this? Do you have an updated patch series
for me to use?
Regards,
Hans
On 05/05/16 14:34, Krzysztof Kozlowski wrote:
> Hi,
>
> This is a different, second try to fix usb3503+lan on Odroid U3 board
> if it was initialized by bootloader (e.g. for TFTP boot).
>
> First version:
> http://www.spinics.net/lists/linux-usb/msg140042.html
>
>
> Problem
> =======
> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset
> is required, e.g. by suspend to RAM. The actual TFTP boot does
> not have to happen. Just "usb start" from U-Boot is sufficient.
>
^ permalink raw reply
* [PATCH V7 7/8] iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged'
From: Robin Murphy @ 2016-12-13 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481567927-14791-8-git-send-email-sricharan@codeaurora.org>
On 12/12/16 18:38, Sricharan R wrote:
> Currently the driver sets all the device transactions privileges
> to UNPRIVILEGED, but there are cases where the iommu masters wants
> to isolate privileged supervisor and unprivileged user.
> So don't override the privileged setting to unprivileged, instead
> set it to default as incoming and let it be controlled by the pagetable
> settings.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Since everything else has already got my tags on it:
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
I'd say the whole series looks good to go now, thanks for picking it up.
Robin.
> ---
> drivers/iommu/arm-smmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index eaa8f44..8bb0eea 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1213,7 +1213,7 @@ static int arm_smmu_domain_add_master(struct arm_smmu_domain *smmu_domain,
> continue;
>
> s2cr[idx].type = type;
> - s2cr[idx].privcfg = S2CR_PRIVCFG_UNPRIV;
> + s2cr[idx].privcfg = S2CR_PRIVCFG_DEFAULT;
> s2cr[idx].cbndx = cbndx;
> arm_smmu_write_s2cr(smmu, idx);
> }
>
^ permalink raw reply
* [PATCHv5 06/11] arm64: Use __pa_symbol for kernel symbols
From: Mark Rutland @ 2016-12-13 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481068257-6367-7-git-send-email-labbott@redhat.com>
On Tue, Dec 06, 2016 at 03:50:52PM -0800, Laura Abbott wrote:
>
> __pa_symbol is technically the marcro that should be used for kernel
> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL which
> will do bounds checking.
>
> Tested-by: James Morse <james.morse@arm.com>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
This looks good to me; I have a (very minor) nit below, but either way:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
> diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
> index a32b401..ca880ce 100644
> --- a/arch/arm64/kernel/acpi_parking_protocol.c
> +++ b/arch/arm64/kernel/acpi_parking_protocol.c
> @@ -18,6 +18,7 @@
> */
> #include <linux/acpi.h>
> #include <linux/types.h>
> +#include <linux/mm.h>
Nit: please keep includes alphabetically ordered, at least where they're
ordered today. Some files are already a mess, but it would be nice to
keep the well-ordered ones ordered.
Thanks,
Mark.
^ permalink raw reply
* [PATCHv5 09/11] mm/kasan: Switch to using __pa_symbol and lm_alias
From: Mark Rutland @ 2016-12-13 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481068257-6367-10-git-send-email-labbott@redhat.com>
On Tue, Dec 06, 2016 at 03:50:55PM -0800, Laura Abbott wrote:
>
> __pa_symbol is the correct API to find the physical address of symbols.
> Switch to it to allow for debugging APIs to work correctly. Other
> functions such as p*d_populate may call __pa internally. Ensure that the
> address passed is in the linear region by calling lm_alias.
>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v5: Add missing lm_alias call
> ---
> mm/kasan/kasan_init.c | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/mm/kasan/kasan_init.c b/mm/kasan/kasan_init.c
> index 3f9a41c..922f459 100644
> --- a/mm/kasan/kasan_init.c
> +++ b/mm/kasan/kasan_init.c
> @@ -16,6 +16,7 @@
> #include <linux/kernel.h>
> #include <linux/memblock.h>
> #include <linux/pfn.h>
> +#include <linux/mm.h>
Nit: include ordering.
Regardless, my tags above still stand!
Thanks,
Mark.
^ permalink raw reply
* [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
From: Hans Verkuil @ 2016-12-13 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c956e27e-7e01-2a2f-0e35-796c4a6556ae@xs4all.nl>
Try again, this time with Krzysztof's new email address...
On 13/12/16 13:20, Hans Verkuil wrote:
> Hi Krzysztof,
>
> This still seems to be broken with the latest 4.9 kernel, right?
>
> Has there been any progress on this? Do you have an updated patch series
> for me to use?
>
> Regards,
>
> Hans
>
> On 05/05/16 14:34, Krzysztof Kozlowski wrote:
>> Hi,
>>
>> This is a different, second try to fix usb3503+lan on Odroid U3 board
>> if it was initialized by bootloader (e.g. for TFTP boot).
>>
>> First version:
>> http://www.spinics.net/lists/linux-usb/msg140042.html
>>
>>
>> Problem
>> =======
>> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
>> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset
>> is required, e.g. by suspend to RAM. The actual TFTP boot does
>> not have to happen. Just "usb start" from U-Boot is sufficient.
>>
>
>
^ permalink raw reply
* [PATCH v6] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Ard Biesheuvel @ 2016-12-13 12:35 UTC (permalink / raw)
To: linux-arm-kernel
Currently, we allow kernel mode NEON in softirq or hardirq context by
stacking and unstacking a slice of the NEON register file for each call
to kernel_neon_begin() and kernel_neon_end(), respectively.
Given that
a) a CPU typically spends most of its time in userland, during which time
no kernel mode NEON in process context is in progress,
b) a CPU spends most of its time in the kernel doing other things than
kernel mode NEON when it gets interrupted to perform kernel mode NEON
in softirq context
the stacking and subsequent unstacking is only necessary if we are
interrupting a thread while it is performing kernel mode NEON in process
context, which means that in all other cases, we can simply preserve the
userland FPSIMD state once, and only restore it upon return to userland,
even if we are being invoked from softirq or hardirq context.
So instead of checking whether we are running in interrupt context, keep
track of the level of nested kernel mode NEON calls in progress, and only
perform the eager stack/unstack if the level exceeds 1.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
v6:
- use a spinlock instead of disabling interrupts
v5:
- perform the test-and-set and the fpsimd_save_state with interrupts disabled,
to prevent nested kernel_neon_begin()/_end() pairs to clobber the state
while it is being preserved
v4:
- use this_cpu_inc/dec, which give sufficient guarantees regarding
concurrency, but do not imply SMP barriers, which are not needed here
v3:
- avoid corruption by concurrent invocations of kernel_neon_begin()/_end()
v2:
- BUG() on unexpected values of the nesting level
- relax the BUG() on num_regs>32 to a WARN, given that nothing actually
breaks in that case
arch/arm64/include/asm/fpsimd.h | 3 +
arch/arm64/kernel/fpsimd.c | 77 ++++++++++++++------
2 files changed, 58 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index 50f559f574fe..ee09fe1c37b6 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -17,6 +17,7 @@
#define __ASM_FP_H
#include <asm/ptrace.h>
+#include <linux/spinlock.h>
#ifndef __ASSEMBLY__
@@ -37,6 +38,8 @@ struct fpsimd_state {
u32 fpcr;
};
};
+ /* lock protecting the preserved state while it is being saved */
+ spinlock_t lock;
/* the id of the last cpu to have restored this state */
unsigned int cpu;
};
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 394c61db5566..886eea2d4084 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -160,6 +160,7 @@ void fpsimd_flush_thread(void)
memset(¤t->thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
fpsimd_flush_task_state(current);
set_thread_flag(TIF_FOREIGN_FPSTATE);
+ spin_lock_init(¤t->thread.fpsimd_state.lock);
}
/*
@@ -220,45 +221,77 @@ void fpsimd_flush_task_state(struct task_struct *t)
#ifdef CONFIG_KERNEL_MODE_NEON
-static DEFINE_PER_CPU(struct fpsimd_partial_state, hardirq_fpsimdstate);
-static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
+/*
+ * Although unlikely, it is possible for three kernel mode NEON contexts to
+ * be live at the same time: process context, softirq context and hardirq
+ * context. So while the userland context is stashed in the thread's fpsimd
+ * state structure, we need two additional levels of storage.
+ */
+static DEFINE_PER_CPU(struct fpsimd_partial_state, nested_fpsimdstate[2]);
+static DEFINE_PER_CPU(int, kernel_neon_nesting_level);
/*
* Kernel-side NEON support functions
*/
void kernel_neon_begin_partial(u32 num_regs)
{
- if (in_interrupt()) {
- struct fpsimd_partial_state *s = this_cpu_ptr(
- in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
+ struct fpsimd_partial_state *s;
+ int level;
- BUG_ON(num_regs > 32);
- fpsimd_save_partial_state(s, roundup(num_regs, 2));
- } else {
+ preempt_disable();
+
+ /*
+ * Save the userland FPSIMD state if we have one and if we
+ * haven't done so already. Clear fpsimd_last_state to indicate
+ * that there is no longer userland FPSIMD state in the
+ * registers.
+ */
+ if (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE)) {
/*
- * Save the userland FPSIMD state if we have one and if we
- * haven't done so already. Clear fpsimd_last_state to indicate
- * that there is no longer userland FPSIMD state in the
+ * Whoever test-and-sets the TIF_FOREIGN_FPSTATE flag should
+ * preserve the userland FP/SIMD state without interruption by
+ * nested kernel_neon_begin()/_end() calls.
+ * The reason is that the FP/SIMD register file is shared with
+ * SVE on hardware that supports it, and nested kernel mode NEON
+ * calls do not restore the upper part of the shared SVE/SIMD
* registers.
*/
- preempt_disable();
- if (current->mm &&
- !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
- fpsimd_save_state(¤t->thread.fpsimd_state);
- this_cpu_write(fpsimd_last_state, NULL);
+ if (spin_trylock(¤t->thread.fpsimd_state.lock)) {
+ if (!test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
+ fpsimd_save_state(¤t->thread.fpsimd_state);
+ spin_unlock(¤t->thread.fpsimd_state.lock);
+ }
+ }
+ this_cpu_write(fpsimd_last_state, NULL);
+
+ level = this_cpu_inc_return(kernel_neon_nesting_level);
+ BUG_ON(level > 3);
+
+ if (level > 1) {
+ s = this_cpu_ptr(nested_fpsimdstate);
+
+ WARN_ON_ONCE(num_regs > 32);
+ num_regs = min(roundup(num_regs, 2), 32U);
+
+ fpsimd_save_partial_state(&s[level - 2], num_regs);
}
}
EXPORT_SYMBOL(kernel_neon_begin_partial);
void kernel_neon_end(void)
{
- if (in_interrupt()) {
- struct fpsimd_partial_state *s = this_cpu_ptr(
- in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
- fpsimd_load_partial_state(s);
- } else {
- preempt_enable();
+ struct fpsimd_partial_state *s;
+ int level;
+
+ level = this_cpu_read(kernel_neon_nesting_level);
+ BUG_ON(level < 1);
+
+ if (level > 1) {
+ s = this_cpu_ptr(nested_fpsimdstate);
+ fpsimd_load_partial_state(&s[level - 2]);
}
+ this_cpu_dec(kernel_neon_nesting_level);
+ preempt_enable();
}
EXPORT_SYMBOL(kernel_neon_end);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory
From: Andrew Jeffery @ 2016-12-13 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5094120.Y7DXfRGTEm@wuerfel>
On Tue, 2016-12-13 at 13:17 +0100, Arnd Bergmann wrote:
> On Tuesday, December 13, 2016 10:35:34 PM CET Andrew Jeffery wrote:
> > On Tue, 2016-12-13 at 11:07 +0000, Lee Jones wrote:
> > > On Tue, 13 Dec 2016, Andrew Jeffery wrote:
> > > > On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
> > > > > On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> > > >
> > > > Lee's next email in the chain poked Arnd for an opinion, but Arnd
> > > > didn't reply.
> > > >
> > > > I don't mind. I moved these bindings separately so we could just drop
> > > > the patch if there was push-back. If we drop the whole idea I'll need
> > > > to apply a small fix to patch 5/6 to avoid creating the syscon
> > > > subdirectory.
> > >
> > > The sub-directory is a good idea for drivers who are *solely* syscon
> > > based.
> > >
> >
> > Yes, I wasn't saying otherwise, just commenting on my motivation and
> > approach.
> >
> > As far as I can tell all of the bindings I move here describe solely
> > syscon-based devices.
> >
>
> But do we know which ones they are?
>
> In principle, any syscon device node can have a specialized driver
> exporting an interface, the bindings always allow it to be done
> one way or the other, and we may change the driver or run a different
> OS that has decided differently.
>
Right; for the Linux case there are currently no driver implementations
that match on the compatible strings in the documents I moved (save for
qcom,tcsr, except that it's the qcom,gsbi compatible driver parsing a
phandle to the qcom,tcsr syscon node).
However, I can't guarantee the solely-syscon property for other
operating systems. Given that, it now looks to me like we shouldn't
have such a directory at all.
Cheers,
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161213/b1925e8e/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/9] ARM: dts: dra72: Add separate dtsi for tps65917
From: Roger Quadros @ 2016-12-13 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-4-lokeshvutla@ti.com>
+Tomi, Kishon, Carlos
Hi,
On 21/10/16 13:38, Lokesh Vutla wrote:
> dra72-evm-common.dtsi consolidates dra72-evm.dts and dra72-evm-revc.dts
> which also include tps65917 pmic support as both the evms uses the same
> pmic. But, dra71-evm has mostly similar features with a different pmic.
> In order to exploit dra72-evm-common.dtsi, creating a separate dtsi
> for tps65915 support and including it in respective board files.
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> arch/arm/boot/dts/dra72-evm-common.dtsi | 128 ----------------------------
> arch/arm/boot/dts/dra72-evm-revc.dts | 21 +++--
> arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 134 ++++++++++++++++++++++++++++++
> arch/arm/boot/dts/dra72-evm.dts | 14 ++--
> 4 files changed, 154 insertions(+), 143 deletions(-)
> create mode 100644 arch/arm/boot/dts/dra72-evm-tps65917.dtsi
>
This patch breaks USB XHCI and boot on dra72-evm (both revC and non revC)
I'll explain why below.
[ 13.625167] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
[ 13.632557] pgd = ede10000
[ 13.635390] [00000000] *pgd=00000000
[ 13.639145] Internal error: : 1406 [#1] SMP ARM
[ 13.643893] Modules linked in: xhci_plat_hcd(+) xhci_hcd usbcore omapfb dwc3 cfbfillrect snd_soc_davinci_mcasp cfbimgblt cfbcopyarea udc_core connector_hdmi encoder_tpd12s015 snd_soc_edma m25p80 snd_soc_simpe
[ 13.695557] CPU: 0 PID: 440 Comm: modprobe Not tainted 4.9.0-rc1 #1050
[ 13.702399] Hardware name: Generic DRA72X (Flattened Device Tree)
[ 13.708786] task: edb5c040 task.stack: edd10000
[ 13.713540] PC is at _raw_spin_unlock_irqrestore+0x0/0x44
[ 13.719219] LR is at xhci_hub_control+0xc2c/0x15e0 [xhci_hcd]
[ 13.725242] pc : [<c07df718>] lr : [<bf486300>] psr: a0000093
[ 13.725242] sp : edd118c0 ip : c0e306b4 fp : 00000000
[ 13.737278] r10: 00000000 r9 : 60000013 r8 : edf28218
[ 13.742753] r7 : edf28000 r6 : 00000000 r5 : 00000000 r4 : edf2a000
[ 13.749593] r3 : 00000000 r2 : 00000000 r1 : 60000013 r0 : edf28218
> diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
> index 8537b6a..9903ac7 100644
> --- a/arch/arm/boot/dts/dra72-evm-common.dtsi
> +++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
> @@ -214,123 +214,6 @@
> status = "okay";
> clock-frequency = <400000>;
>
> - tps65917: tps65917 at 58 {
> - compatible = "ti,tps65917";
> - reg = <0x58>;
> -
> - interrupts = <GIC_SPI 2 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
> - interrupt-controller;
> - #interrupt-cells = <2>;
> -
> - ti,system-power-controller;
> -
> - tps65917_pmic {
> - compatible = "ti,tps65917-pmic";
> -
> - smps1-in-supply = <&vsys_3v3>;
> - smps2-in-supply = <&vsys_3v3>;
> - smps3-in-supply = <&vsys_3v3>;
> - smps4-in-supply = <&vsys_3v3>;
> - smps5-in-supply = <&vsys_3v3>;
> - ldo1-in-supply = <&vsys_3v3>;
> - ldo2-in-supply = <&vsys_3v3>;
> - ldo3-in-supply = <&vsys_3v3>;
> - ldo4-in-supply = <&evm_5v0>;
> - ldo5-in-supply = <&vsys_3v3>;
> -
> - tps65917_regulators: regulators {
> - smps1_reg: smps1 {
> - /* VDD_MPU */
> - regulator-name = "smps1";
> - regulator-min-microvolt = <850000>;
> - regulator-max-microvolt = <1250000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - smps2_reg: smps2 {
> - /* VDD_CORE */
> - regulator-name = "smps2";
> - regulator-min-microvolt = <850000>;
> - regulator-max-microvolt = <1150000>;
> - regulator-boot-on;
> - regulator-always-on;
> - };
> -
> - smps3_reg: smps3 {
> - /* VDD_GPU IVA DSPEVE */
> - regulator-name = "smps3";
> - regulator-min-microvolt = <850000>;
> - regulator-max-microvolt = <1250000>;
> - regulator-boot-on;
> - regulator-always-on;
> - };
> -
> - smps4_reg: smps4 {
> - /* VDDS1V8 */
> - regulator-name = "smps4";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - smps5_reg: smps5 {
> - /* VDD_DDR */
> - regulator-name = "smps5";
> - regulator-min-microvolt = <1350000>;
> - regulator-max-microvolt = <1350000>;
> - regulator-boot-on;
> - regulator-always-on;
> - };
> -
> - ldo1_reg: ldo1 {
> - /* LDO1_OUT --> SDIO */
> - regulator-name = "ldo1";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-allow-bypass;
> - };
> -
> - ldo3_reg: ldo3 {
> - /* VDDA_1V8_PHY */
> - regulator-name = "ldo3";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-boot-on;
> - regulator-always-on;
> - };
> -
> - ldo5_reg: ldo5 {
> - /* VDDA_1V8_PLL */
> - regulator-name = "ldo5";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - ldo4_reg: ldo4 {
> - /* VDDA_3V_USB: VDDA_USBHS33 */
> - regulator-name = "ldo4";
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-boot-on;
> - };
> - };
> - };
> -
> - tps65917_power_button {
> - compatible = "ti,palmas-pwrbutton";
> - interrupt-parent = <&tps65917>;
> - interrupts = <1 IRQ_TYPE_NONE>;
> - wakeup-source;
> - ti,palmas-long-press-seconds = <6>;
> - };
> - };
> -
> pcf_gpio_21: gpio at 21 {
> compatible = "ti,pcf8575", "nxp,pcf8575";
> reg = <0x21>;
> @@ -480,14 +363,6 @@
> };
> };
>
> -&usb2_phy1 {
> - phy-supply = <&ldo4_reg>;
> -};
> -
> -&usb2_phy2 {
> - phy-supply = <&ldo4_reg>;
> -};
> -
You remove this here but don't add them in the board dts files.
> &omap_dwc3_1 {
> extcon = <&extcon_usb1>;
> };
> @@ -509,7 +384,6 @@
> pinctrl-names = "default";
> pinctrl-0 = <&mmc1_pins_default>;
> vmmc-supply = <&evm_3v3_sd>;
> - vmmc_aux-supply = <&ldo1_reg>;
What about this?
> bus-width = <4>;
> /*
> * SDCD signal is not being used here - using the fact that GPIO mode
> @@ -606,8 +480,6 @@
>
> &dss {
> status = "ok";
> -
> - vdda_video-supply = <&ldo5_reg>;
and this?
> };
>
> &hdmi {
> diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
> index 064b322..4ea2a0c 100644
> --- a/arch/arm/boot/dts/dra72-evm-revc.dts
> +++ b/arch/arm/boot/dts/dra72-evm-revc.dts
> @@ -17,17 +17,22 @@
> };
> };
>
> -&tps65917_regulators {
> - ldo2_reg: ldo2 {
> - /* LDO2_OUT --> VDDA_1V8_PHY2 */
> - regulator-name = "ldo2";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-always-on;
> - regulator-boot-on;
> +&i2c1 {
> + tps65917: tps65917 at 58 {
> + reg = <0x58>;
> +
> + interrupts = <GIC_SPI 2 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
> };
> };
>
> +#include "dra72-evm-tps65917.dtsi"
> +
> +&ldo2_reg {
> + /* LDO2_OUT --> VDDA_1V8_PHY2 */
> + regulator-always-on;
> + regulator-boot-on;
> +};
> +
Here you need to add the usb2_phy1 & 2 supplies.
> &hdmi {
> vdda-supply = <&ldo2_reg>;
> };
> diff --git a/arch/arm/boot/dts/dra72-evm-tps65917.dtsi b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
> new file mode 100644
> index 0000000..ee6dac4
> --- /dev/null
> +++ b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
> @@ -0,0 +1,134 @@
> +/*
> + * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/*
> + * Integrated Power Management Chip
> + * http://www.ti.com/lit/ds/symlink/tps65917-q1.pdf
> + */
> +
> +&tps65917 {
> + compatible = "ti,tps65917";
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + ti,system-power-controller;
> +
> + tps65917_pmic {
> + compatible = "ti,tps65917-pmic";
> +
> + smps1-in-supply = <&vsys_3v3>;
> + smps2-in-supply = <&vsys_3v3>;
> + smps3-in-supply = <&vsys_3v3>;
> + smps4-in-supply = <&vsys_3v3>;
> + smps5-in-supply = <&vsys_3v3>;
> + ldo1-in-supply = <&vsys_3v3>;
> + ldo2-in-supply = <&vsys_3v3>;
> + ldo3-in-supply = <&vsys_3v3>;
> + ldo4-in-supply = <&evm_5v0>;
> + ldo5-in-supply = <&vsys_3v3>;
> +
> + tps65917_regulators: regulators {
> + smps1_reg: smps1 {
> + /* VDD_MPU */
> + regulator-name = "smps1";
> + regulator-min-microvolt = <850000>;
> + regulator-max-microvolt = <1250000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps2_reg: smps2 {
> + /* VDD_CORE */
> + regulator-name = "smps2";
> + regulator-min-microvolt = <850000>;
> + regulator-max-microvolt = <1150000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + smps3_reg: smps3 {
> + /* VDD_GPU IVA DSPEVE */
> + regulator-name = "smps3";
> + regulator-min-microvolt = <850000>;
> + regulator-max-microvolt = <1250000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + smps4_reg: smps4 {
> + /* VDDS1V8 */
> + regulator-name = "smps4";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + smps5_reg: smps5 {
> + /* VDD_DDR */
> + regulator-name = "smps5";
> + regulator-min-microvolt = <1350000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + ldo1_reg: ldo1 {
> + /* LDO1_OUT --> SDIO */
> + regulator-name = "ldo1";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-allow-bypass;
> + };
> +
> + ldo2_reg: ldo2 {
> + regulator-name = "ldo2";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-allow-bypass;
> + };
> +
> + ldo3_reg: ldo3 {
> + /* VDDA_1V8_PHY */
> + regulator-name = "ldo3";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + ldo5_reg: ldo5 {
> + /* VDDA_1V8_PLL */
> + regulator-name = "ldo5";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + ldo4_reg: ldo4 {
> + /* VDDA_3V_USB: VDDA_USBHS33 */
> + regulator-name = "ldo4";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + };
> + };
> + };
> +
> + tps65917_power_button {
> + compatible = "ti,palmas-pwrbutton";
> + interrupt-parent = <&tps65917>;
> + interrupts = <1 IRQ_TYPE_NONE>;
> + wakeup-source;
> + ti,palmas-long-press-seconds = <6>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
> index e3a9b69..cd9c4ff 100644
> --- a/arch/arm/boot/dts/dra72-evm.dts
> +++ b/arch/arm/boot/dts/dra72-evm.dts
> @@ -15,16 +15,16 @@
> };
> };
>
> -&tps65917_regulators {
> - ldo2_reg: ldo2 {
> - /* LDO2_OUT --> TP1017 (UNUSED) */
> - regulator-name = "ldo2";
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-allow-bypass;
> +&i2c1 {
> + tps65917: tps65917 at 58 {
> + reg = <0x58>;
> +
> + interrupts = <GIC_SPI 2 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
> };
> };
>
> +#include "dra72-evm-tps65917.dtsi"
> +
> &hdmi {
> vdda-supply = <&ldo3_reg>;
> };
>
Here as well you need to add the usb2_phy1 & 2 supplies.
We probably need to add dss and mmc supplies as well to both the board dts files?
cheers,
-roger
^ permalink raw reply
* [PATCH 0/3] arm64/clk: update Marvell Armada CP110 system controller driver
From: Thomas Petazzoni @ 2016-12-13 12:41 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This small set of commits updates the Marvell Armada CP110 system
controller driver, its Device Tree binding, and Device Tree
representation, to take into account two new things:
- The clock driver now handles clock n?9 (GOP) as a child of clock
n?18 (controls SD/MMC and GOP)
- The DT representation is adjusted to name clock n?18 "sd-mmc-gop"
instead of just "sd-mmc".
This set of commits is some preparation work to add networking support
for Marvell Armada 7K/8K.
I would expect patches 1 and 2 to be taken by the clock maintainers,
and patch 3 be taken by the Marvell EBU maintainers.
Thanks,
Thomas
Thomas Petazzoni (3):
dt-bindings: arm: update Armada CP110 system controller binding
clk: mvebu: adjust clock handling for the CP110 system controller
arm64: dts: marvell: adjust name of sd-mmc-gop clock in syscon
.../devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 6 +++---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 2 +-
drivers/clk/mvebu/cp110-system-controller.c | 6 ++++--
4 files changed, 9 insertions(+), 7 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] dt-bindings: arm: update Armada CP110 system controller binding
From: Thomas Petazzoni @ 2016-12-13 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481632880-9198-1-git-send-email-thomas.petazzoni@free-electrons.com>
It turns out that in the CP110 HW block present in Marvell Armada
7K/8K SoCs, gatable clock n?18 not only controls SD/MMC, but also the
GOP block. This commit updates the Device Tree binding for this piece
of hardware accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
.../devicetree/bindings/arm/marvell/cp110-system-controller0.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
index 30c5469..07dbb35 100644
--- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt
@@ -45,7 +45,7 @@ The following clocks are available:
- 1 15 SATA
- 1 16 SATA USB
- 1 17 Main
- - 1 18 SD/MMC
+ - 1 18 SD/MMC/GOP
- 1 21 Slow IO (SPI, NOR, BootROM, I2C, UART)
- 1 22 USB3H0
- 1 23 USB3H1
@@ -65,7 +65,7 @@ Required properties:
"cpm-audio", "cpm-communit", "cpm-nand", "cpm-ppv2", "cpm-sdio",
"cpm-mg-domain", "cpm-mg-core", "cpm-xor1", "cpm-xor0", "cpm-gop-dp", "none",
"cpm-pcie_x10", "cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor", "cpm-sata",
- "cpm-sata-usb", "cpm-main", "cpm-sd-mmc", "none", "none", "cpm-slow-io",
+ "cpm-sata-usb", "cpm-main", "cpm-sd-mmc-gop", "none", "none", "cpm-slow-io",
"cpm-usb3h0", "cpm-usb3h1", "cpm-usb3dev", "cpm-eip150", "cpm-eip197";
Example:
@@ -78,6 +78,6 @@ Example:
gate-clock-output-names = "cpm-audio", "cpm-communit", "cpm-nand", "cpm-ppv2", "cpm-sdio",
"cpm-mg-domain", "cpm-mg-core", "cpm-xor1", "cpm-xor0", "cpm-gop-dp", "none",
"cpm-pcie_x10", "cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor", "cpm-sata",
- "cpm-sata-usb", "cpm-main", "cpm-sd-mmc", "none", "none", "cpm-slow-io",
+ "cpm-sata-usb", "cpm-main", "cpm-sd-mmc-gop", "none", "none", "cpm-slow-io",
"cpm-usb3h0", "cpm-usb3h1", "cpm-usb3dev", "cpm-eip150", "cpm-eip197";
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] clk: mvebu: adjust clock handling for the CP110 system controller
From: Thomas Petazzoni @ 2016-12-13 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481632880-9198-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adds support for the GOP_DP gatable clock found in the
CP110 system controller. This clock is controlled by bit 9, and has
clock 18 as its parent. Therefore, clock 18 is in fact not only
controlling SD/MMC, but also GOP, but it is renamed as SD_MMC_GOP
accordingly.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
drivers/clk/mvebu/cp110-system-controller.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/mvebu/cp110-system-controller.c b/drivers/clk/mvebu/cp110-system-controller.c
index f2303da..3c91cab 100644
--- a/drivers/clk/mvebu/cp110-system-controller.c
+++ b/drivers/clk/mvebu/cp110-system-controller.c
@@ -66,6 +66,7 @@ enum {
#define CP110_GATE_SDIO 4
#define CP110_GATE_XOR1 7
#define CP110_GATE_XOR0 8
+#define CP110_GATE_GOP_DP 9
#define CP110_GATE_PCIE_X1_0 11
#define CP110_GATE_PCIE_X1_1 12
#define CP110_GATE_PCIE_X4 13
@@ -73,7 +74,7 @@ enum {
#define CP110_GATE_SATA 15
#define CP110_GATE_SATA_USB 16
#define CP110_GATE_MAIN 17
-#define CP110_GATE_SDMMC 18
+#define CP110_GATE_SDMMC_GOP 18
#define CP110_GATE_SLOW_IO 21
#define CP110_GATE_USB3H0 22
#define CP110_GATE_USB3H1 23
@@ -309,9 +310,10 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
parent = ppv2_name;
break;
case CP110_GATE_SDIO:
+ case CP110_GATE_GOP_DP:
of_property_read_string_index(np,
"gate-clock-output-names",
- CP110_GATE_SDMMC, &parent);
+ CP110_GATE_SDMMC_GOP, &parent);
break;
case CP110_GATE_XOR1:
case CP110_GATE_XOR0:
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: marvell: adjust name of sd-mmc-gop clock in syscon
From: Thomas Petazzoni @ 2016-12-13 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481632880-9198-1-git-send-email-thomas.petazzoni@free-electrons.com>
This commit adjusts the names of gatable clock #18 of the Marvell Armada
CP110 system controller. This clock not only controls SD/MMC, but also
the GOP (Group Of Ports) used for networking. So the clock is renamed to
{cpm,cps}-sd-mmc-gop instead of {cpm,cps}-sd-mmc.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index 602e2c2..895babc 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -74,7 +74,7 @@
"cpm-gop-dp", "none", "cpm-pcie_x10",
"cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor",
"cpm-sata", "cpm-sata-usb", "cpm-main",
- "cpm-sd-mmc", "none", "none",
+ "cpm-sd-mmc-gop", "none", "none",
"cpm-slow-io", "cpm-usb3h0", "cpm-usb3h1",
"cpm-usb3dev", "cpm-eip150", "cpm-eip197";
};
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 6bf9e24..db99646 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -74,7 +74,7 @@
"cps-gop-dp", "none", "cps-pcie_x10",
"cps-pcie_x11", "cps-pcie_x4", "cps-pcie-xor",
"cps-sata", "cps-sata-usb", "cps-main",
- "cps-sd-mmc", "none", "none",
+ "cps-sd-mmc-gop", "none", "none",
"cps-slow-io", "cps-usb3h0", "cps-usb3h1",
"cps-usb3dev", "cps-eip150", "cps-eip197";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v4 8/9] PM / Domains: Support IRQ safe PM domains
From: Geert Uytterhoeven @ 2016-12-13 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477347668-41901-9-git-send-email-lina.iyer@linaro.org>
Hi Lina,
On Tue, Oct 25, 2016 at 12:21 AM, Lina Iyer <lina.iyer@linaro.org> wrote:
> Generic Power Domains currently support turning on/off only in process
> context. This prevents the usage of PM domains for domains that could be
> powered on/off in a context where IRQs are disabled. Many such domains
> exist today and do not get powered off, when the IRQ safe devices in
> that domain are powered off, because of this limitation.
>
> However, not all domains can operate in IRQ safe contexts. Genpd
> therefore, has to support both cases where the domain may or may not
> operate in IRQ safe contexts. Configuring genpd to use an appropriate
> lock for that domain, would allow domains that have IRQ safe devices to
> runtime suspend and resume, in atomic context.
>
> To achieve domain specific locking, set the domain's ->flag to
> GENPD_FLAG_IRQ_SAFE while defining the domain. This indicates that genpd
> should use a spinlock instead of a mutex for locking the domain. Locking
> is abstracted through genpd_lock() and genpd_unlock() functions that use
> the flag to determine the appropriate lock to be used for that domain.
>
> Domains that have lower latency to suspend and resume and can operate
> with IRQs disabled may now be able to save power, when the component
> devices and sub-domains are idle at runtime.
>
> The restriction this imposes on the domain hierarchy is that non-IRQ
> safe domains may not have IRQ-safe subdomains, but IRQ safe domains may
> have IRQ safe and non-IRQ safe subdomains and devices.
>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Kevin Hilman <khilman@kernel.org>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/base/power/domain.c | 111 ++++++++++++++++++++++++++++++++++++++++----
> include/linux/pm_domain.h | 10 +++-
> 2 files changed, 110 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 1ad42f2..07ed835 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -74,11 +74,70 @@ static const struct genpd_lock_ops genpd_mtx_ops = {
> +static inline bool irq_safe_dev_in_no_sleep_domain(struct device *dev,
> + struct generic_pm_domain *genpd)
> +{
> + bool ret;
> +
> + ret = pm_runtime_is_irq_safe(dev) && !genpd_is_irq_safe(genpd);
> +
> + /* Warn once for each IRQ safe dev in no sleep domain */
This comment is not correct, as dev_warn_once() will print the warning once,
not once per device. Hence users will not be informed if there are multiple
IRQ safe devices.
> + if (ret)
> + dev_warn_once(dev, "PM domain %s will not be powered off\n",
> + genpd->name);
BTW, I'm seeing messages like:
sh_cmt ffca0000.timer: PM domain always-on will not be powered off
and
sh_cmt e6138000.timer: PM domain c5 will not be powered off
on various Renesas SoCs, and wanted to know if there was more than one
IRQ safe device preventing a PM domain power down (answer: there isn't).
Note that the above are OK, as both "always-on" and "c5" are always-on
PM domains.
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] ARM: dts: vexpress: Support GICC_DIR operations
From: Marc Zyngier @ 2016-12-13 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <903fb243-7ab1-211f-e29f-27ab00a4aa01@arm.com>
On 13/12/16 12:16, Sudeep Holla wrote:
>
>
> On 12/12/16 17:35, Marc Zyngier wrote:
>> [+Sudeep]
>>
>> On 10/12/16 20:13, Christoffer Dall wrote:
>>> The GICv2 CPU interface registers span across 8K, not 4K as indicated in
>>> the DT. Only the GICC_DIR register is located after the initial 4K
>>> boundary, leaving a functional system but without support for separately
>>> EOI'ing and deactivating interrupts.
>>>
>>> After this change the system support split priority drop and interrupt
>>> deactivation.
>>>
>>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>>> ---
>>> arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
>>> index 0205c97..2e0cf39 100644
>>> --- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
>>> +++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
>>> @@ -126,7 +126,7 @@
>>> #address-cells = <0>;
>>> interrupt-controller;
>>> reg = <0 0x2c001000 0 0x1000>,
>>> - <0 0x2c002000 0 0x1000>,
>>> + <0 0x2c002000 0 0x2000>,
>>> <0 0x2c004000 0 0x2000>,
>>> <0 0x2c006000 0 0x2000>;
>>> interrupts = <1 9 0xf04>;
>>>
>>
>> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
>>
>
> Thanks Marc, I see couple of other instances of this like tc2 and rtsm
> model on arm64. Do they need to be fixed too ? I guess so. If so I will
> fixup this to patch add tc1. And add another one for rtsm.
Yes, that'd be good.
> Also I see loads of gic-400 compatible dts(mainly rockchip and renasas)
> having just 4k. Are they left like this intentionally ? I remember you
> fixing most of the DTS when you found this issue initially.
I still have these patches stashed somewhere (I remember sunxi being one
of the offender as well). I also need to come up with a software
workaround enabling the 8kB region with the old DT (because it is likely
that KVM will stop working on them if we merge Christoffer's timer patches).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 3/9] ARM: dts: dra72: Add separate dtsi for tps65917
From: Lokesh Vutla @ 2016-12-13 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <045e8200-69bd-8590-1da4-96235444db4c@ti.com>
On Tuesday 13 December 2016 06:10 PM, Roger Quadros wrote:
> +Tomi, Kishon, Carlos
>
> Hi,
>
> On 21/10/16 13:38, Lokesh Vutla wrote:
>> dra72-evm-common.dtsi consolidates dra72-evm.dts and dra72-evm-revc.dts
>> which also include tps65917 pmic support as both the evms uses the same
>> pmic. But, dra71-evm has mostly similar features with a different pmic.
>> In order to exploit dra72-evm-common.dtsi, creating a separate dtsi
>> for tps65915 support and including it in respective board files.
>>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> ---
>> arch/arm/boot/dts/dra72-evm-common.dtsi | 128 ----------------------------
>> arch/arm/boot/dts/dra72-evm-revc.dts | 21 +++--
>> arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 134 ++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/dra72-evm.dts | 14 ++--
>> 4 files changed, 154 insertions(+), 143 deletions(-)
>> create mode 100644 arch/arm/boot/dts/dra72-evm-tps65917.dtsi
>>
>
> This patch breaks USB XHCI and boot on dra72-evm (both revC and non revC)
>
> I'll explain why below.
>
> [ 13.625167] Unhandled fault: imprecise external abort (0x1406) at 0x00000000
> [ 13.632557] pgd = ede10000
> [ 13.635390] [00000000] *pgd=00000000
> [ 13.639145] Internal error: : 1406 [#1] SMP ARM
> [ 13.643893] Modules linked in: xhci_plat_hcd(+) xhci_hcd usbcore omapfb dwc3 cfbfillrect snd_soc_davinci_mcasp cfbimgblt cfbcopyarea udc_core connector_hdmi encoder_tpd12s015 snd_soc_edma m25p80 snd_soc_simpe
> [ 13.695557] CPU: 0 PID: 440 Comm: modprobe Not tainted 4.9.0-rc1 #1050
> [ 13.702399] Hardware name: Generic DRA72X (Flattened Device Tree)
> [ 13.708786] task: edb5c040 task.stack: edd10000
> [ 13.713540] PC is at _raw_spin_unlock_irqrestore+0x0/0x44
> [ 13.719219] LR is at xhci_hub_control+0xc2c/0x15e0 [xhci_hcd]
> [ 13.725242] pc : [<c07df718>] lr : [<bf486300>] psr: a0000093
> [ 13.725242] sp : edd118c0 ip : c0e306b4 fp : 00000000
> [ 13.737278] r10: 00000000 r9 : 60000013 r8 : edf28218
> [ 13.742753] r7 : edf28000 r6 : 00000000 r5 : 00000000 r4 : edf2a000
> [ 13.749593] r3 : 00000000 r2 : 00000000 r1 : 60000013 r0 : edf28218
Hmm.. Thanks for catching it. I remember it was booting when I tested,
not sure how I missed this :(. usb2_phy1 & 2, mmc and dss supplies needs
to be added in dra72-evm-tps65917.dtsi file.
Tony,
Do you want me to resend this patch or fixup patch on top of this?
Thanks and regards,
Lokesh
^ permalink raw reply
* [PATCH 0/9] dmaengine: stm32-dma: Bug fixes and improvements series
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds bug fixes reported by devices using STM32 DMA and some
improvements mainly linked to dmaengine framework evolution.
M'boumba Cedric Madianga (9):
dmaengine: stm32-dma: Set correct args number for DMA request from DT
dmaengine: stm32-dma: Fix typo in Kconfig
dt-bindings: stm32-dma: Fix typo regarding DMA client binding
dmaengine: stm32-dma: Fix null pointer dereference in stm32_dma_tx_status
dmaengine: stm32-dma: Rework starting transfer management
dmaengine: stm32-dma: Fix residue computation issue in cyclic mode
dmaengine: stm32-dma: Add error messages if xlate fails
dmaengine: stm32-dma: Add synchronization support
dmaengine: stm32-dma: Add max_burst support
.../devicetree/bindings/dma/stm32-dma.txt | 5 +-
drivers/dma/Kconfig | 2 +-
drivers/dma/stm32-dma.c | 103 +++++++++++++--------
3 files changed, 66 insertions(+), 44 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/9] dmaengine: stm32-dma: Set correct args number for DMA request from DT
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-1-git-send-email-cedric.madianga@gmail.com>
This patch sets the right number of arguments to be used for DMA clients
which request channels from DT.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
---
drivers/dma/stm32-dma.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 3688d08..a884b85 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -972,21 +972,18 @@ static struct dma_chan *stm32_dma_of_xlate(struct of_phandle_args *dma_spec,
struct stm32_dma_chan *chan;
struct dma_chan *c;
- if (dma_spec->args_count < 3)
+ if (dma_spec->args_count < 4)
return NULL;
cfg.channel_id = dma_spec->args[0];
cfg.request_line = dma_spec->args[1];
cfg.stream_config = dma_spec->args[2];
- cfg.threshold = 0;
+ cfg.threshold = dma_spec->args[3];
if ((cfg.channel_id >= STM32_DMA_MAX_CHANNELS) || (cfg.request_line >=
STM32_DMA_MAX_REQUEST_ID))
return NULL;
- if (dma_spec->args_count > 3)
- cfg.threshold = dma_spec->args[3];
-
chan = &dmadev->chan[cfg.channel_id];
c = dma_get_slave_channel(&chan->vchan.chan);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/9] dmaengine: stm32-dma: Fix typo in Kconfig
From: M'boumba Cedric Madianga @ 2016-12-13 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481636451-27863-1-git-send-email-cedric.madianga@gmail.com>
As STM32 DMA driver is only used as buit-in driver, it couldn't be used as
module.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 263495d..96da57a 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -458,7 +458,7 @@ config STM32_DMA
help
Enable support for the on-chip DMA controller on STMicroelectronics
STM32 MCUs.
- If you have a board based on such a MCU and wish to use DMA say Y or M
+ If you have a board based on such a MCU and wish to use DMA say Y
here.
config S3C24XX_DMAC
--
1.9.1
^ permalink raw reply related
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