* [v12, 0/8] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-10-19 2:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFoit0sTPpfi2=AHcdZsDwOJxbBX68O-1jBFL=5JN0m6_w@mail.gmail.com>
+ Greg
Hi Greg,
I submitted this patchset for a MMC bug fix, and introduce the below patch which needs your ACK.
> > Arnd Bergmann (1):
> > base: soc: introduce soc_device_match() interface
https://patchwork.kernel.org/patch/9342913/
Could you help to review it and give some comments or ACK.
Thank you very much.
Best regards,
Yangbo Lu
> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hansson at linaro.org]
> Sent: Tuesday, October 18, 2016 6:48 PM
> To: Y.B. Lu
> Cc: linux-mmc; Scott Wood; Arnd Bergmann; linuxppc-dev at lists.ozlabs.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; linux-clk; linux-i2c at vger.kernel.org;
> iommu at lists.linux-foundation.org; netdev at vger.kernel.org; Mark Rutland;
> Rob Herring; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B.
> Xie; M.H. Lian
> Subject: Re: [v12, 0/8] Fix eSDHC host version register bug
>
> On 21 September 2016 at 08:57, Yangbo Lu <yangbo.lu@nxp.com> wrote:
> > This patchset is used to fix a host version register bug in the
> > T4240-R1.0-R2.0 eSDHC controller. To match the SoC version and
> > revision, 10 previous version patchsets had tried many methods but all
> of them were rejected by reviewers.
> > Such as
> > - dts compatible method
> > - syscon method
> > - ifdef PPC method
> > - GUTS driver getting SVR method Anrd suggested a
> > soc_device_match method in v10, and this is the only available method
> > left now. This v11 patchset introduces the soc_device_match interface
> > in soc driver.
> >
> > The first six patches of Yangbo are to add the GUTS driver. This is
> > used to register a soc device which contain soc version and revision
> information.
> > The other two patches introduce the soc_device_match method in soc
> > driver and apply it on esdhc driver to fix this bug.
> >
> > Arnd Bergmann (1):
> > base: soc: introduce soc_device_match() interface
> >
> > Yangbo Lu (7):
> > dt: bindings: update Freescale DCFG compatible
> > ARM64: dts: ls2080a: add device configuration node
> > dt: bindings: move guts devicetree doc out of powerpc directory
> > powerpc/fsl: move mpc85xx.h to include/linux/fsl
> > soc: fsl: add GUTS driver for QorIQ platforms
> > MAINTAINERS: add entry for Freescale SoC drivers
> > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> >
> > Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > MAINTAINERS | 11 +-
> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> > arch/powerpc/sysdev/fsl_pci.c | 2 +-
> > drivers/base/Kconfig | 1 +
> > drivers/base/soc.c | 66 ++++++
> > drivers/clk/clk-qoriq.c | 3 +-
> > drivers/i2c/busses/i2c-mpc.c | 2 +-
> > drivers/iommu/fsl_pamu.c | 3 +-
> > drivers/mmc/host/Kconfig | 1 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> > drivers/net/ethernet/freescale/gianfar.c | 2 +-
> > drivers/soc/Kconfig | 2 +-
> > drivers/soc/fsl/Kconfig | 19 ++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/guts.c | 257
> +++++++++++++++++++++
> > include/linux/fsl/guts.h | 125 ++++++----
> > .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> > include/linux/sys_soc.h | 3 +
> > 21 files changed, 478 insertions(+), 61 deletions(-) rename
> > Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> > create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> > drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> > include/linux/fsl/svr.h (97%)
> >
> > --
> > 2.1.0.27.g96db324
> >
>
> This looks good to me! I am not sure which tree you want this to be
> picked up through, but unless no other volunteers I can take it through
> my mmc tree.
>
> Although, before considering to apply, I need an ack from Scott/Arnd for
> the guts driver in patch 5/8 and I need an ack from Greg for patch 7/8,
> where the soc_device_match() interface is added (seems like you didn't
> add him on cc/to).
>
> Kind regards
> Uffe
^ permalink raw reply
* [PATCH v2] arm64: kernel: numa: fix ACPI boot cpu numa node mapping
From: Leizhen (ThunderTown) @ 2016-10-19 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <728ef882-b1ee-9518-d291-ee475e9006eb@linaro.org>
On 2016/10/18 16:39, Hanjun Guo wrote:
> On 2016/10/17 22:56, Lorenzo Pieralisi wrote:
>> Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must
>> bind to node0") removed the numa cpu<->node mapping restriction whereby
>> logical cpu 0 always corresponds to numa node 0; removing the
>> restriction was correct, in that it does not really exist in practice
>> but the commit only updated the early mapping of logical cpu 0 to its
>> real numa node for the DT boot path, missing the ACPI one, leading to
>> boot failures on ACPI systems owing to missing cpu<->node map for
>> logical cpu 0.
>>
>> Fix the issue by updating the ACPI boot path with code that carries out
>> the early cpu<->node mapping also for the boot cpu (ie cpu 0), mirroring
>> what is currently done in the DT boot path.
>>
>> Fixes: 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Tested-by: Laszlo Ersek <lersek@redhat.com>
>> Reported-by: Laszlo Ersek <lersek@redhat.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Laszlo Ersek <lersek@redhat.com>
>> Cc: Hanjun Guo <hanjun.guo@linaro.org>
>
> Thanks for the quick response and fix,
>
> Acked-by: Hanjun Guo <hanjun.guo@linaro.org>
>
> By the way, I got another boot failure [1] when we have multi
> NUMA nodes system with some memory-less nodes (only one node
> have memory), we are looking into it now, this patch needs
> to be merged first.
You should apply my numa MEMORYLESS patches first, because the two patches have not been upstreamed yet.
I just tested it base on 4.9-rc1 for dt numa, it worked well. I will connect you to check what's wrong on ACPI numa.
>
> Thanks
> Hanjun
>
> [1]: boot failure log:
> [ 0.000000] NUMA: Adding memblock [0x0 - 0x3fffffff] on node 0
> [ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x3fffffff]
> [ 0.000000] NUMA: Adding memblock [0x1400000000 - 0x17ffffffff] on node 1
> [ 0.000000] ACPI: SRAT: Node 1 PXM 1 [mem 0x1400000000-0x17ffffffff]
> [ 0.000000] NUMA: Adding memblock [0x1000000000 - 0x13ffffffff] on node 0
> [ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x1000000000-0x13ffffffff]
> [ 0.000000] NUMA: Initmem setup node 0 [mem 0x00000000-0x13fbffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x13fbffe500-0x13fbffffff]
> [ 0.000000] NUMA: Initmem setup node 1 [mem 0x1400000000-0x17fbffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x17fbfec500-0x17fbfedfff]
> [ 0.000000] NUMA: Initmem setup node 2 [mem 0x00000000-0xffffffffffffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x17fbfeaa00-0x17fbfec4ff]
> [ 0.000000] NUMA: NODE_DATA(2) on node 1
> [ 0.000000] NUMA: Initmem setup node 3 [mem 0x00000000-0xffffffffffffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x17fbfe8f00-0x17fbfea9ff]
> [ 0.000000] NUMA: NODE_DATA(3) on node 1
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA [mem 0x0000000000000000-0x00000000ffffffff]
> [ 0.000000] Normal [mem 0x0000000100000000-0x00000017fbffffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000000024fff]
> [ 0.000000] node 0: [mem 0x0000000000026000-0x00000000319dffff]
> [ 0.000000] node 0: [mem 0x00000000319e0000-0x0000000031a4ffff]
> [ 0.000000] node 0: [mem 0x0000000031a50000-0x0000000031b2ffff]
> [ 0.000000] node 0: [mem 0x0000000031b30000-0x0000000031b3ffff]
> [ 0.000000] node 0: [mem 0x0000000031b40000-0x0000000039baffff]
> [ 0.000000] node 0: [mem 0x0000000039bb0000-0x000000003a143fff]
> [ 0.000000] node 0: [mem 0x000000003a144000-0x000000003f12ffff]
> [ 0.000000] node 0: [mem 0x000000003f130000-0x000000003f15ffff]
> [ 0.000000] node 0: [mem 0x000000003f160000-0x000000003fbfffff]
> [ 0.000000] node 0: [mem 0x0000001040000000-0x00000013fbffffff]
> [ 0.000000] node 1: [mem 0x0000001400000000-0x00000017fbffffff]
> [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000013fbffffff]
> [ 0.000000] Initmem setup node 1 [mem 0x0000001400000000-0x00000017fbffffff]
> [ 0.000000] Could not find start_pfn for node 2
> [ 0.000000] Initmem setup node 2 [mem 0x0000000000000000-0x0000000000000000]
> [ 0.000000] Could not find start_pfn for node 3
> [ 0.000000] Initmem setup node 3 [mem 0x0000000000000000-0x0000000000000000]
> [ 0.000000] psci: probing for conduit method from ACPI.
> [ 0.000000] ------------[ cut here ]------------
> [ 0.000000] kernel BUG at mm/percpu.c:1916!
> [ 0.000000] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc1-00083-g3dd62e5 #680
> [ 0.000000] Hardware name: Hisilicon Hi1616 Evaluation Board (DT)
> [ 0.000000] task: ffff000008d5e980 task.stack: ffff000008d50000
> [ 0.000000] PC is at pcpu_embed_first_chunk+0x464/0x754
> [ 0.000000] LR is at pcpu_embed_first_chunk+0x3f8/0x754
> [ 0.000000] pc : [<ffff000008c65af0>] lr : [<ffff000008c65a84>] pstate: 200000c5
> [ 0.000000] sp : ffff000008d53e90
> [ 0.000000] x29: ffff000008d53e90 [ 0.000000] x28: 0000000000000000
> [ 0.000000]
> [ 0.000000] x27: ffff000008d55e50 [ 0.000000] x26: 0000000000000042
> [ 0.000000]
> [ 0.000000] x25: ffff000008d55d28 [ 0.000000] x24: 0000000000000046
> [ 0.000000]
> [ 0.000000] x23: 0000000000000040 [ 0.000000] x22: ffff8017fbfcff00
> [ 0.000000]
> [ 0.000000] x21: ffff000008ca6e20 [ 0.000000] x20: ffff8017fbfd0518
> [ 0.000000]
> [ 0.000000] x19: 0000000000000042 [ 0.000000] x18: ffff000008e3fb60
> [ 0.000000]
> [ 0.000000] x17: 000000000000001b [ 0.000000] x16: 000000000000000b
> [ 0.000000]
> [ 0.000000] x15: 0000001400000000 [ 0.000000] x14: 0000000000000004
> [ 0.000000]
> [ 0.000000] x13: 0000000000000000 [ 0.000000] x12: 0000000000000069
> [ 0.000000]
> [ 0.000000] x11: 00000017fbffff00 [ 0.000000] x10: 0000000000000004
> [ 0.000000]
> [ 0.000000] x9 : 0000000000000000 [ 0.000000] x8 : ffff8017fbfd0f00
> [ 0.000000]
> [ 0.000000] x7 : 0000000000000000 [ 0.000000] x6 : 0000000000000000
> [ 0.000000]
> [ 0.000000] x5 : 0000000000000000 [ 0.000000] x4 : 000000000000003f
> [ 0.000000]
> [ 0.000000] x3 : 0000000000000040 [ 0.000000] x2 : 0000000000000040
> [ 0.000000]
> [ 0.000000] x1 : 0000000000000001 [ 0.000000] x0 : ffff000008ca7328
> [ 0.000000]
> [ 0.000000]
> [ 0.000000] Process swapper (pid: 0, stack limit = 0xffff000008d50020)
> [ 0.000000] Stack: (0xffff000008d53e90 to 0xffff000008d54000)
> [ 0.000000] 3e80: ffff000008d53f60 ffff000008c5616c
> [ 0.000000] 3ea0: ffff000008ca5a08 ffff000008e2a000 ffff000008e2a000 ffff000008d55000
> [ 0.000000] 3ec0: ffff000008ca5a08 ffff8017fbfffe80 0000000000000168 000000003c96a518
> [ 0.000000] 3ee0: 000000003c971b98 0000000000c50018 ffff000008d53f60 ffff000008c56078
> [ 0.000000] 3f00: ffff000008d1f000 ffff000008d14000 0000000000007480 0000000000002000
> [ 0.000000] 3f20: ffff000008c560b0 0000000000001000 ffff000008d55e50 ffff000008d55d28
> [ 0.000000] 3f40: ffff000008ca6000 0000000000000040 0000000000000001 0000000000000040
> [ 0.000000] 3f60: ffff000008d53fa0 ffff000008c508d4 ffff000008ca5a08 ffff000008e2a000
> [ 0.000000] 3f80: ffff000008e2a000 ffff000008d55000 ffff000008ca5a08 ffff000008c508d0
> [ 0.000000] 3fa0: ffff000008d53ff0 ffff000008c501d8 000000003c94fa98 000000001e400000
> [ 0.000000] 3fc0: 000000001e400000 000000025497ba19 0000000000000000 000000003f198a08
> [ 0.000000] 3fe0: 0000000000000000 ffff000008ca5a08 0000000000000000 00000000008a325c
> [ 0.000000] Call trace:
> [ 0.000000] Exception stack(0xffff000008d53cc0 to 0xffff000008d53df0)
> [ 0.000000] 3cc0: 0000000000000042 0001000000000000 ffff000008d53e90 ffff000008c65af0
> [ 0.000000] 3ce0: ffff000008d53d30 ffff0000081aa024 0000000000000001 0000000000001000
> [ 0.000000] 3d00: ffff000008d53d30 ffff0000081aa034 0000000000000001 0000000000001000
> [ 0.000000] 3d20: 00000017fbfcff00 0000000000000004 ffff000008d53d90 ffff0000081aa2c8
> [ 0.000000] 3d40: 00000017fbfcff00 0000000000001000 0000000000000000 0000000000000000
> [ 0.000000] 3d60: ffff000008ca7328 0000000000000001 0000000000000040 0000000000000040
> [ 0.000000] 3d80: 000000000000003f 0000000000000000 0000000000000000 0000000000000000
> [ 0.000000] 3da0: ffff8017fbfd0f00 0000000000000000 0000000000000004 00000017fbffff00
> [ 0.000000] 3dc0: 0000000000000069 0000000000000000 0000000000000004 0000001400000000
> [ 0.000000] 3de0: 000000000000000b 000000000000001b
> [ 0.000000] [<ffff000008c65af0>] pcpu_embed_first_chunk+0x464/0x754
> [ 0.000000] [<ffff000008c5616c>] setup_per_cpu_areas+0x3c/0xcc
> [ 0.000000] [<ffff000008c508d4>] start_kernel+0x10c/0x398
> [ 0.000000] [<ffff000008c501d8>] __primary_switched+0x5c/0x64
> [ 0.000000] Code: 0b000318 17ffffd8 6b17031f 54000080 (d4210000)
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task!
>
>
> .
>
^ permalink raw reply
* [PATCH] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Sebastian Reichel @ 2016-10-19 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005155112.13774-2-hdegoede@redhat.com>
Hi,
On Wed, Oct 05, 2016 at 05:51:12PM +0200, Hans de Goede wrote:
> The i2c subsys does not load modules by compatible, only by
> i2c-id, with e.g. a modalias of: "i2c:axp209".
>
> Populate the axp20x_i2c_id[] table with supported ids, so that
> module auto-loading will work.
>
> Reported-by: Dennis Gilmore <dennis@ausil.us>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/mfd/axp20x-i2c.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
> index b1b8658..d35a5fe 100644
> --- a/drivers/mfd/axp20x-i2c.c
> +++ b/drivers/mfd/axp20x-i2c.c
> @@ -69,10 +69,11 @@ static const struct of_device_id axp20x_i2c_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
>
> -/*
> - * This is useless for OF-enabled devices, but it is needed by I2C subsystem
> - */
> static const struct i2c_device_id axp20x_i2c_id[] = {
> + { "axp152", 0 },
> + { "axp202", 0 },
> + { "axp209", 0 },
> + { "axp221", 0 },
> { },
> };
> MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
Thanks, queued.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161019/fe135abd/attachment.sig>
^ permalink raw reply
* [PATCH] mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading
From: Sebastian Reichel @ 2016-10-19 2:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019025154.rmw56aoh27wbrene@earth>
Hi,
On Wed, Oct 19, 2016 at 04:51:55AM +0200, Sebastian Reichel wrote:
> > diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
> > index b1b8658..d35a5fe 100644
> > --- a/drivers/mfd/axp20x-i2c.c
> > +++ b/drivers/mfd/axp20x-i2c.c
> > @@ -69,10 +69,11 @@ static const struct of_device_id axp20x_i2c_of_match[] = {
> > };
> > MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
> >
> > -/*
> > - * This is useless for OF-enabled devices, but it is needed by I2C subsystem
> > - */
> > static const struct i2c_device_id axp20x_i2c_id[] = {
> > + { "axp152", 0 },
> > + { "axp202", 0 },
> > + { "axp209", 0 },
> > + { "axp221", 0 },
> > { },
> > };
> > MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
>
> Thanks, queued.
My mistake. It should obviously go through mfd. So take this instead:
Acked-By: Sebastian Reichel <sre@kernel.org>
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161019/aa748c19/attachment.sig>
^ permalink raw reply
* [PATCH v2 0/8] crypto: ARM/arm64 - big endian fixes
From: Herbert Xu @ 2016-10-19 3:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9wuXnrq77a3Zk0GnHgnkpURh=EegwgP+vAwMC=rdm3qA@mail.gmail.com>
On Tue, Oct 18, 2016 at 01:14:38PM +0100, Ard Biesheuvel wrote:
> On 18 October 2016 at 12:49, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Tue, Oct 11, 2016 at 07:15:12PM +0100, Ard Biesheuvel wrote:
> >> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> >> currently work, or have ever worked correctly when built for big endian. So this
> >> series fixes all of them. This v2 now includes a similar fix for 32-bit ARM as
> >> well, and an additional fix for XTS which escaped my attention before.
> >>
> >> Each of these patches carries a fixes tag, and could be backported to stable.
> >> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> >> fix is compatible with, not the patch that introduced the algorithm.
> >
> > I think for future reference, the Fixes tag should denote the commit
> > that introduced the issue. An explicit Cc: stable tag would state how
> > far back it should be applied.
> >
>
> OK, that sounds reasonable.
>
> >> Ard Biesheuvel (8):
> >> crypto: arm64/aes-ce - fix for big endian
> >> crypto: arm64/ghash-ce - fix for big endian
> >> crypto: arm64/sha1-ce - fix for big endian
> >> crypto: arm64/sha2-ce - fix for big endian
> >> crypto: arm64/aes-ccm-ce: fix for big endian
> >> crypto: arm64/aes-neon - fix for big endian
> >> crypto: arm64/aes-xts-ce: fix for big endian
> >> crypto: arm/aes-ce - fix for big endian
> >
> > The changes look fine to me but I can't claim I fully understand these
> > algorithms. FWIW:
> >
> > Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> >
> > (Will may pick them up for 4.9-rcX)
>
> Thanks, although I was kind of expecting Herbert to pick these up,
> given that #8 affects ARM not arm64.
>
> But if you (or Will) can pick up #1 to #7, that is also fine, then I
> can drop #8 into rmk's patch database.
I was planning merging these for 4.10. But I'm fine with them
going through the arm tree. Let me know what you guys want to
do.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [RFC PATCH] mtd: nand: Add OX820 NAND Support
From: Rob Herring @ 2016-10-19 3:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018090927.1990-1-narmstrong@baylibre.com>
On Tue, Oct 18, 2016 at 11:09:27AM +0200, Neil Armstrong wrote:
> Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
> This is a simple memory mapped NAND controller with single chip select and
> software ECC.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/mtd/oxnas-nand.txt | 24 ++++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/mtd/nand/Kconfig | 5 +
> drivers/mtd/nand/Makefile | 1 +
> drivers/mtd/nand/oxnas_nand.c | 144 +++++++++++++++++++++
> 4 files changed, 174 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/oxnas-nand.txt
> create mode 100644 drivers/mtd/nand/oxnas_nand.c
^ permalink raw reply
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Eric Anholt @ 2016-10-19 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPoCmYJC1TebBrspD_=mTETULSjg9or5a0Yda8p945y6ZWL99Q@mail.gmail.com>
Gottfried Haider <gottfried.haider@gmail.com> writes:
> Hi Eric, Linus,
>
> I'll hopefully find time to look at the more recent changes to the gpio
> subsystem (lsgpio?!), but since this patch is up for discussion now - what
> I was wondering: how does this change relate to /sys/class/gpio/gpio%d? Is
> this completely orthogonal - or would this change the sysfs interface as
> well?
>
> Regarding the proposed format using the header pin numbers: From what I've
> seen in terms of existing educational materials, it seems the overwhelming
> majority ends up using GPIO numbers instead of physical pin header
> numbering. (e.g. [1] [2])
> Would it be too confusing to try to pick GPIO 5 from an alphabetically
> sorted list like this "P11_GPIO17", "P12_GPIO18"? (I know, alphabetical
> sorting is an issue here already for a different reason. But applications
> might do it, I guess?)
I added the pin numbers because it was a consistent response to the
first version. I do think the GPIO numbers without pin numbers would be
the most clear.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161018/cae67ff7/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: dts: rockchip: temporarily remove emmc hs200 speed from rk3288-veyron-speedy.
From: Vagrant Cascadian @ 2016-10-19 3:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476824417.1031.9.camel@paulk.fr>
On 2016-10-18, Paul Kocialkowski wrote:
> Le mardi 18 octobre 2016 ? 11:21 +0200, Heiko St?bner a ?crit?:
>> Am Sonntag, 16. Oktober 2016, 21:49:43 schrieb Paul Kocialkowski:
>> > Le mardi 27 septembre 2016 ? 13:53 -0700, Vagrant Cascadian a ?crit :
>> > >
>> > > This essentially mimics what was done with rk3288-veyron-minnie in
>> > > commit 984926781122f034d5bc9962815d135b6c4a8e1d.
>> > >
>> > > The eMMC of the speedy Chromebook also appears to need the same tuning
>> > > workaround, as it frequently fails to recognize the eMMC without it.
>> >
>> > I have a device where (without this patch) eMMC sometimes fails, with:
>> > [????3.561010] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to
>> > 175 [????3.571742] mmc2: new HS200 MMC card at address 0001
>> > [????3.571943] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
>> > [????3.572026] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
>> > [????3.572107] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
>> > [????3.572181] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
>> > [????3.685647] mmcblk2: error -110 transferring data, sector 0, nr 8, cmd
>> > response 0x900, card status 0x0
>> > And sometimes works, with:
>> > [????3.451058] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to
>> > 176 [????3.491093] mmc2: new HS200 MMC card at address 0001
>> > [????3.491277] mmcblk2: mmc2:0001 HAG2e 14.7 GiB?
>> > [????3.491345] mmcblk2boot0: mmc2:0001 HAG2e partition 1 4.00 MiB
>> > [????3.491409] mmcblk2boot1: mmc2:0001 HAG2e partition 2 4.00 MiB
>> > [????3.491474] mmcblk2rpmb: mmc2:0001 HAG2e partition 3 4.00 MiB
>> > [????3.493548]??mmcblk2: p1 p2
This is similar behavior to my veyron-speedy. Here are several boot logs
>From running 4.8.0-rc7, with some failures and some successes:
https://cascadia.aikidev.net/~vagrant/veyron-speedy/
>> > However, with this change, it always fails, with:
>> > [????3.322129] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req
>> > 52000000Hz, actual 50000000HZ div = 0) [????3.333174] mmc2: error -110
>> > whilst initialising MMC card
>> >
>> > I don't have so much time to investigate this issue, but it's clear that
>> > this patch doesn't fix the issue (and actually worsens it) for my device.
Well, that makes things more complicated.
>> As discussed on IRC we now have varying reports of the emmc working or not?
>> working with and without that patch applied. So it's not really a bandaid fix?
>> and I've thus dropped this patch again.
>
> Thanks for dropping it! For the record, my eMMC shows up as:
> mmcblk2: mmc2:0001 HAG2e 14.7 GiB
Mine looks similar, although reporting as mmc0:
[ 3.166550] mmcblk0: mmc0:0001 HAG2e 14.7 GiB
> Maybe it could help to share what each tested device reports as eMMC model and
> associate that with the current behavior, in spite of getting a clearer idea of
> what issue affects what model.
FWIW, I'm using a veyron-speedy with 4GB of ram, not sure what other
information might be useful to distinguish between different models.
On the bottom of the case, it claims to be a C201P. Near the serial,
it's marked as C201PA-DS02-LG.
live well,
vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161018/643b245b/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC
From: Jiancheng Xue @ 2016-10-19 3:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqK18RHFhDSWA_j+v_pJL6vk+a=GD7oo6O3JJaV4hHHEBg@mail.gmail.com>
? 2016/10/19 10:45, Rob Herring ??:
> On Tue, Oct 18, 2016 at 9:38 PM, Jiancheng Xue
> <xuejiancheng@hisilicon.com> wrote:
>>
>>
>> ? 2016/10/18 23:58, Rob Herring ??:
>>> On Mon, Oct 17, 2016 at 08:07:04PM +0800, Pan Wen wrote:
>>>> Add CRG driver for Hi3516CV300 SoC. CRG(Clock and Reset
>>>> Generator) module generates clock and reset signals used
>>>> by other module blocks on SoC.
>>>>
>>>> Signed-off-by: Pan Wen <wenpan@hisilicon.com>
>>>> ---
>>>> .../devicetree/bindings/clock/hisi-crg.txt | 50 ++++
>>>> drivers/clk/hisilicon/Kconfig | 8 +
>>>> drivers/clk/hisilicon/Makefile | 1 +
>>>> drivers/clk/hisilicon/crg-hi3516cv300.c | 330 +++++++++++++++++++++
>>>> drivers/clk/hisilicon/crg.h | 34 +++
>>>> include/dt-bindings/clock/hi3516cv300-clock.h | 48 +++
>>>> 6 files changed, 471 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/clock/hisi-crg.txt
>>>> create mode 100644 drivers/clk/hisilicon/crg-hi3516cv300.c
>>>> create mode 100644 drivers/clk/hisilicon/crg.h
>>>> create mode 100644 include/dt-bindings/clock/hi3516cv300-clock.h
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/hisi-crg.txt b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>>>> new file mode 100644
>>>> index 0000000..cc60b3d
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/clock/hisi-crg.txt
>>>> @@ -0,0 +1,50 @@
>>>> +* HiSilicon Clock and Reset Generator(CRG)
>>>
>>> Seems kind of generic given there's already various HiSi clock bindings
>>> documented.
>>>
>>>> +
>>>> +The CRG module provides clock and reset signals to various
>>>> +modules within the SoC.
>>>> +
>>>> +This binding uses the following bindings:
>>>> + Documentation/devicetree/bindings/clock/clock-bindings.txt
>>>> + Documentation/devicetree/bindings/reset/reset.txt
>>>> +
>>>> +Required Properties:
>>>> +
>>>> +- compatible: should be one of the following.
>>>> + - "hisilicon,hi3516cv300-crg"
>>>> + - "hisilicon,hi3516cv300-sysctrl"
>>>> + - "hisilicon,hi3519-crg"
>>>
>>> There is already a binding for this. Please merge them.
>>>
>> Hi Rob,
>>
>> Pan Wen and I work together. There's really a same file included in the patch
>> https://lkml.org/lkml/2016/9/18/42 ([PATCH v2] clk: hisilicon: add CRG driver for Hi3798CV200 SoC).
>> But that patch has not been acked. This binding file will be merged if that
>> patch is accepted first. Could you give me more comments on that patch or
>> help me to ack it? Thank you very much.
>
> If I haven't commented, then likely it was not sent to the DT list.
Hi,
I'm pretty sure that the patch was sent to the DT list devicetree at vger.kernel.org.
You had asked a question about "hi3798cv200-sysctrl" and I replied (https://lkml.org/lkml/2016/10/10/517).
I'm waiting for your new comments. If there's some misunderstatnding, please let me know.
Thanks,
Jiancheng
>
> Rob
>
> .
>
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: enable qspi on the Cyclone5 devkit
From: dinguyen at opensource.altera.com @ 2016-10-19 4:11 UTC (permalink / raw)
To: linux-arm-kernel
From: Dinh Nguyen <dinguyen@opensource.altera.com>
Enable the qspi controller on the devkit and add the flash chip.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 32 ++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
index 15e43f4..a0868e9 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
@@ -87,6 +87,38 @@
status = "okay";
};
+&qspi {
+ status = "okay";
+
+ flash0: n25q00 at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q00";
+ reg = <0>; /* chip select */
+ spi-max-frequency = <100000000>;
+
+ cdns,page-size = <256>;
+ cdns,block-size = <16>;
+ cdns,read-delay = <4>;
+ cdns,tshsl-ns = <50>;
+ cdns,tsd2d-ns = <50>;
+ cdns,tchsh-ns = <4>;
+ cdns,tslch-ns = <4>;
+
+ partition at qspi-boot {
+ /* 8MB for raw data. */
+ label = "Flash 0 Raw Data";
+ reg = <0x0 0x800000>;
+ };
+
+ partition at qspi-rootfs {
+ /* 120MB for jffs2 data. */
+ label = "Flash 0 jffs2 Filesystem";
+ reg = <0x800000 0x7800000>;
+ };
+ };
+};
+
&usb1 {
status = "okay";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH] i2c: uniphier[-f]: fix bool logic calculation
From: Masahiro Yamada @ 2016-10-19 4:38 UTC (permalink / raw)
To: linux-arm-kernel
This code is working, but it should not depend on how "bool" is
typedef'ed, or the bit position of I2C_M_RD.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/i2c/busses/i2c-uniphier-f.c | 2 +-
drivers/i2c/busses/i2c-uniphier.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-uniphier-f.c b/drivers/i2c/busses/i2c-uniphier-f.c
index db9105e..b54448e 100644
--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -309,7 +309,7 @@ static int uniphier_fi2c_master_xfer_one(struct i2c_adapter *adap,
struct i2c_msg *msg, bool stop)
{
struct uniphier_fi2c_priv *priv = i2c_get_adapdata(adap);
- bool is_read = msg->flags & I2C_M_RD;
+ bool is_read = !!(msg->flags & I2C_M_RD);
unsigned long time_left;
dev_dbg(&adap->dev, "%s: addr=0x%02x, len=%d, stop=%d\n",
diff --git a/drivers/i2c/busses/i2c-uniphier.c b/drivers/i2c/busses/i2c-uniphier.c
index 56e92af..cc80bb2 100644
--- a/drivers/i2c/busses/i2c-uniphier.c
+++ b/drivers/i2c/busses/i2c-uniphier.c
@@ -177,7 +177,7 @@ static int uniphier_i2c_stop(struct i2c_adapter *adap)
static int uniphier_i2c_master_xfer_one(struct i2c_adapter *adap,
struct i2c_msg *msg, bool stop)
{
- bool is_read = msg->flags & I2C_M_RD;
+ bool is_read = !!(msg->flags & I2C_M_RD);
bool recovery = false;
int ret;
--
1.9.1
^ permalink raw reply related
* [PATCH 4/9] regulator: lp873x: Add support for populating input supply
From: Lokesh Vutla @ 2016-10-19 4:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018142743.xfgjuaw4wlssmoxq@rob-hp-laptop>
On Tuesday 18 October 2016 07:57 PM, Rob Herring wrote:
> On Fri, Oct 14, 2016 at 06:30:28PM +0530, Lokesh Vutla wrote:
>> In order to have a proper topology of regulators for a platform, each
>> registering regulator needs to populate supply_name field for identifying
>> its supply's name. Add supply_name field for lp873x regulators.
>>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> Cc: Keerthy <j-keerthy@ti.com>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> ---
>> Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
>> drivers/regulator/lp873x-regulator.c | 1 +
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
>> index 52766c2..936cba3 100644
>> --- a/Documentation/devicetree/bindings/mfd/lp873x.txt
>> +++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
>> @@ -7,6 +7,9 @@ Required properties:
>> - #gpio-cells: Should be two. The first cell is the pin number and
>> the second cell is used to specify flags.
>> See ../gpio/gpio.txt for more information.
>> + - xxx-supply: Phandle to parent supply node of each regulator
>> + populated under regulators node. xxx should match
>> + the supply_name populated in driver.
>
> xxx-in-supply?
Oops. Right. Ill update it and repost.
Thanks and regards,
Lokesh
^ permalink raw reply
* [PATCH 4/4] i2c: digicolor: Fix module autoload
From: Baruch Siach @ 2016-10-19 5:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476824508-4679-5-git-send-email-javier@osg.samsung.com>
Hi Javier Martinez Canillas,
On Tue, Oct 18, 2016 at 06:01:48PM -0300, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/i2c/busses/i2c-digicolor.ko | grep alias
> $
>
> After this patch:
>
> $ modinfo drivers/i2c/busses/i2c-digicolor.ko | grep alias
> alias: of:N*T*Ccnxt,cx92755-i2cC*
> alias: of:N*T*Ccnxt,cx92755-i2c
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Baruch Siach <baruch@tkos.co.il>
Thanks,
baruch
> drivers/i2c/busses/i2c-digicolor.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/i2c/busses/i2c-digicolor.c b/drivers/i2c/busses/i2c-digicolor.c
> index 9604024e0eb0..49f2084f7bb5 100644
> --- a/drivers/i2c/busses/i2c-digicolor.c
> +++ b/drivers/i2c/busses/i2c-digicolor.c
> @@ -368,6 +368,7 @@ static const struct of_device_id dc_i2c_match[] = {
> { .compatible = "cnxt,cx92755-i2c" },
> { },
> };
> +MODULE_DEVICE_TABLE(of, dc_i2c_match);
>
> static struct platform_driver dc_i2c_driver = {
> .probe = dc_i2c_probe,
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH 3/3] ARM: socfpga: defconfig: enable qspi
From: Steffen Trumtrar @ 2016-10-19 5:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1610181600570.27375@linux-builds1>
On Tue, Oct 18, 2016 at 04:03:01PM -0500, Dinh Nguyen wrote:
> On Tue, 18 Oct 2016, Steffen Trumtrar wrote:
>
> > Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> > ---
> > arch/arm/configs/socfpga_defconfig | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
> > index 9f84be5b3ac5..466050663c86 100644
> > --- a/arch/arm/configs/socfpga_defconfig
> > +++ b/arch/arm/configs/socfpga_defconfig
>
> Thanks Steffen, all patches applied. I'll fixup the commit header for the DTS
> patches. The arm-soc maintainers prefer the DTS patches to be:
>
> "ARM: dts: <platform>"
Oops.
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v9 2/2] ARM: dts: add TOPEET itop elite based board
From: Krzysztof Kozlowski @ 2016-10-19 5:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58DB0A67-6C74-409B-80B2-9F02492D3A55@soulik.info>
On Wed, Oct 19, 2016 at 4:15 AM, Ayaka <ayaka@soulik.info> wrote:
>
>
> ??? iPad ??
>
>> Krzysztof Kozlowski <krzk@kernel.org> ? 2016?10?19? ??1:37 ???
>>
>>> On Wed, Oct 19, 2016 at 01:18:49AM +0800, Randy Li wrote:
>>> The TOPEET itop exynos 4412 have three versions base board. The
>>> Elite version is the cheap one without too much peripheral devices
>>> on it.
>>>
>>> Currently supported are serial console, wired networking(USB),
>>> USB OTG in peripheral mode, USB host, SD storage, GPIO buttons,
>>> PWM beeper, ADC and LEDs. The WM8960 analog audio codec is also
>>> enabled.
>>>
>>> The FIMC is not used for camera currently, I enabled it just for a
>>> colorspace converter.
>>>
>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>>
>> Thanks, applied, with missing Rob's ack, minor changes in commit msg and
>> fix in pin function (you used macro for pull up/down instead of
>> function).
> The last time I saw the other dts have applied that, but they are not now. A header file is also missed reported by kbuild, but I didn't meet that.
I wonder why I didn't encounter the build error on my machine... This
needs a follow up fix.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: dts: am335x-baltos-ir5221: use both musb channels in host mode
From: yegorslists at googlemail.com @ 2016-10-19 7:09 UTC (permalink / raw)
To: linux-arm-kernel
From: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
arch/arm/boot/dts/am335x-baltos-ir5221.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-baltos-ir5221.dts b/arch/arm/boot/dts/am335x-baltos-ir5221.dts
index d0faa7b..f599350 100644
--- a/arch/arm/boot/dts/am335x-baltos-ir5221.dts
+++ b/arch/arm/boot/dts/am335x-baltos-ir5221.dts
@@ -114,7 +114,7 @@
&usb1 {
status = "okay";
- dr_mode = "otg";
+ dr_mode = "host";
};
&cpsw_emac0 {
--
2.1.4
^ permalink raw reply related
* [PATCH] Revert "gpio/mvebu: convert to use irq_domain_add_simple()"
From: Gregory CLEMENT @ 2016-10-19 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476831396-24359-1-git-send-email-jgunthorpe@obsidianresearch.com>
Hi Jason,
On mer., oct. 19 2016, Jason Gunthorpe <jgunthorpe@obsidianresearch.com> wrote:
> This reverts commit ce931f571b6dcf8534e8740e8cd16565cf362536.
>
> The only difference betwen _simple and _legacy is that _simple
> calls irq_alloc_descs, however mvebu_gpio_probe already called
> irq_alloc_descs a few lines above.
And what about removing the irq_alloc_descs ?
Going back to use the _legacy version seems wrong for me.
Gregory
>
> This fixes these kernel error messages from the double call
> to irq_alloc_descs:
>
> irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
> irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Fixes: ce931f571b6d ("gpio/mvebu: convert to use irq_domain_add_simple()")
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
> drivers/gpio/gpio-mvebu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
> index cd5dc27320a2..2e0c8d8b7792 100644
> --- a/drivers/gpio/gpio-mvebu.c
> +++ b/drivers/gpio/gpio-mvebu.c
> @@ -807,8 +807,8 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
> IRQ_NOREQUEST, IRQ_LEVEL | IRQ_NOPROBE);
>
> /* Setup irq domain on top of the generic chip. */
> - mvchip->domain = irq_domain_add_simple(np, mvchip->chip.ngpio,
> - mvchip->irqbase,
> + mvchip->domain = irq_domain_add_legacy(np, mvchip->chip.ngpio,
> + mvchip->irqbase, 0,
> &irq_domain_simple_ops,
> mvchip);
> if (!mvchip->domain) {
> --
> 2.1.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] iommu/mediatek: Convert M4Uv1 to iommu_fwspec
From: Honghui Zhang @ 2016-10-19 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a40dbcc1ff40bf09483316354d2fdcb2d432eb81.1476704508.git.robin.murphy@arm.com>
On Mon, 2016-10-17 at 12:49 +0100, Robin Murphy wrote:
> Our per-device data consists of the M4U instance and firmware-provided
> list of LARB IDs, which is a perfect fit for the generic iommu_fwspec
> machinery. Use that directly instead of the custom archdata code - while
> we can't rely on the of_xlate() mechanism to initialise things until the
> 32-bit ARM DMA code learns about groups and default domains, it still
> results in a reasonable simplification overall.
>
> CC: Honghui Zhang <honghui.zhang@mediatek.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Thanks Robin.
Tested-by: Honghui Zhang <honghui.zhang@mediatek.com>
> ---
> drivers/iommu/mtk_iommu.h | 6 ---
> drivers/iommu/mtk_iommu_v1.c | 95 +++++++++++++++++---------------------------
> 2 files changed, 36 insertions(+), 65 deletions(-)
>
^ permalink raw reply
* how to enable suspend to ram for arm-64 bits
From: yoma sophian @ 2016-10-19 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95484b8f-58de-3588-ac91-5ec21e66ab05@arm.com>
hi Sudeep:
2016-10-18 18:59 GMT+08:00 Sudeep Holla <sudeep.holla@arm.com>:
>
>
> On 18/10/16 11:45, Mark Rutland wrote:
>>
>> On Tue, Oct 18, 2016 at 12:00:02PM +0200, Pavel Machek wrote:
>>>>>
>>>>> b. in arm64, if some platform has its own suspend flow, couldn't it
>>>>> adopts arm/match-xxx to register its own global suspend method?
>>>>
>>>>
>>>> No, PSCI is highly recommended.
>>>
>>>
>>> Relying on firmware for suspend on x86 was a great disaster, lets not
>>> repeat
>>> that mistake. arm32 has better powermanagement than x86 ever will (see
>>> Nokia N900
>>> for example) -- feel free to copy that code from arm32.
>>
>>
>> Quite frankly, copying hundreds of lines of board-specific code
>> (including assembly that won't compile) is unlikely to help.
>>
>> So far arm64 requires well-defined, standard, reusable interfaces (e.g.
>> PSCI). That cleanly separates concerns (e.g. anyone can implement the
>> backend without mandatory changes to the kernel), and keeps things
>> maintainable.
>>
>> ARM publishes and maintains the ARM Trusted Firmware [1], which anyone
>> can use and build atop of. It's open source (three-clause BSD with DCO),
>> and accepts board ports. You can have a completely open stack,
>> regardless of whether part of that stack is firmware.
>>
>
> I think you missed to add the link[1]
> [1] https://github.com/ARM-software/arm-trusted-firmware
thanks for your kind information ^^
^ permalink raw reply
* [PATCH v4] MMC: meson: initial support for GX platforms
From: Ulf Hansson @ 2016-10-19 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018195605.21145-1-khilman@baylibre.com>
On 18 October 2016 at 21:56, Kevin Hilman <khilman@baylibre.com> wrote:
> Initial support for the SD/eMMC controller in the Amlogic S905/GX*
> family of SoCs.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> Changes from v3:
> - better handling of clock error paths
> - rename to meson-gx to reflect support for newer SoCs
> - has now been tested with SDIO
>
> .../devicetree/bindings/mmc/amlogic,meson-gxbb.txt | 33 +
Just realize this. You should split the DT doc into a separate patch,
such the DT maintainers can ack it.
Otherwise this looks good to me!
Kind regards
Uffe
> MAINTAINERS | 1 +
> drivers/mmc/host/Kconfig | 10 +
> drivers/mmc/host/Makefile | 1 +
> drivers/mmc/host/meson-gx.c | 853 +++++++++++++++++++++
> 5 files changed, 898 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt
> create mode 100644 drivers/mmc/host/meson-gx.c
>
> diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt b/Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt
> new file mode 100644
> index 000000000000..a2fa9a1c26ae
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt
> @@ -0,0 +1,33 @@
> +Amlogic SD / eMMC controller for S905/GXBB family SoCs
> +
> +The MMC 5.1 compliant host controller on Amlogic provides the
> +interface for SD, eMMC and SDIO devices.
> +
> +This file documents the properties in addition to those available in
> +the MMC core bindings, documented by mmc.txt.
> +
> +Required properties:
> +- compatible : contains one of:
> + - "amlogic,meson-gx-mmc"
> + - "amlogic,meson-gxbb-mmc"
> + - "amlogic,meson-gxl-mmc"
> + - "amlogic,meson-gxm-mmc"
> +- clocks : A list of phandle + clock-specifier pairs for the clocks listed in clock-names.
> +- clock-names: Should contain the following:
> + "core" - Main peripheral bus clock
> + "clkin0" - Parent clock of internal mux
> + "clkin1" - Other parent clock of internal mux
> + The driver has an interal mux clock which switches between clkin0 and clkin1 depending on the
> + clock rate requested by the MMC core.
> +
> +Example:
> +
> + sd_emmc_a: mmc at 70000 {
> + compatible = "amlogic,meson-gxbb-mmc";
> + reg = <0x0 0x70000 0x0 0x2000>;
> + interrupts = < GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc CLKID_SD_EMMC_A>, <&xtal>, <&clkc CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + pinctrl-0 = <&emmc_pins>;
> + };
> +
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1cd38a7e0064..73e8d64ec28c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1036,6 +1036,7 @@ F: arch/arm/mach-meson/
> F: arch/arm/boot/dts/meson*
> F: arch/arm64/boot/dts/amlogic/
> F: drivers/pinctrl/meson/
> +F: drivers/mmc/host/meson*
> N: meson
>
> ARM/Annapurna Labs ALPINE ARCHITECTURE
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 5274f503a39a..5cf7ebaf1e8b 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -322,6 +322,16 @@ config MMC_SDHCI_IPROC
>
> If unsure, say N.
>
> +config MMC_MESON_GX
> + tristate "Amlogic S905/GX* SD/MMC Host Controller support"
> + depends on ARCH_MESON && MMC
> + help
> + This selects support for the Amlogic SD/MMC Host Controller
> + found on the S905/GX* family of SoCs. This controller is
> + MMC 5.1 compliant and supports SD, eMMC and SDIO interfaces.
> +
> + If you have a controller with this interface, say Y here.
> +
> config MMC_MOXART
> tristate "MOXART SD/MMC Host Controller support"
> depends on ARCH_MOXART && MMC
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index e2bdaaf43184..1c4852999ae4 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -53,6 +53,7 @@ obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
> obj-$(CONFIG_MMC_VUB300) += vub300.o
> obj-$(CONFIG_MMC_USHC) += ushc.o
> obj-$(CONFIG_MMC_WMT) += wmt-sdmmc.o
> +obj-$(CONFIG_MMC_MESON_GX) += meson-gx.o
> obj-$(CONFIG_MMC_MOXART) += moxart-mmc.o
> obj-$(CONFIG_MMC_SUNXI) += sunxi-mmc.o
> obj-$(CONFIG_MMC_USDHI6ROL0) += usdhi6rol0.o
> diff --git a/drivers/mmc/host/meson-gx.c b/drivers/mmc/host/meson-gx.c
> new file mode 100644
> index 000000000000..fd3c40322b2d
> --- /dev/null
> +++ b/drivers/mmc/host/meson-gx.c
> @@ -0,0 +1,853 @@
> +/*
> + * Amlogic SD/eMMC driver for the GX/S905 family SoCs
> + *
> + * Copyright (c) 2016 BayLibre, SAS.
> + * Author: Kevin Hilman <khilman@baylibre.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see <http://www.gnu.org/licenses/>.
> + * The full GNU General Public License is included in this distribution
> + * in the file called COPYING.
> + */
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/device.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/ioport.h>
> +#include <linux/spinlock.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/mmc/host.h>
> +#include <linux/mmc/mmc.h>
> +#include <linux/mmc/sdio.h>
> +#include <linux/mmc/slot-gpio.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/clk-provider.h>
> +#include <linux/regulator/consumer.h>
> +
> +#define DRIVER_NAME "meson-gxbb-mmc"
> +
> +#define SD_EMMC_CLOCK 0x0
> +#define CLK_DIV_SHIFT 0
> +#define CLK_DIV_WIDTH 6
> +#define CLK_DIV_MASK 0x3f
> +#define CLK_DIV_MAX 63
> +#define CLK_SRC_SHIFT 6
> +#define CLK_SRC_WIDTH 2
> +#define CLK_SRC_MASK 0x3
> +#define CLK_SRC_XTAL 0 /* external crystal */
> +#define CLK_SRC_XTAL_RATE 24000000
> +#define CLK_SRC_PLL 1 /* FCLK_DIV2 */
> +#define CLK_SRC_PLL_RATE 1000000000
> +#define CLK_PHASE_SHIFT 8
> +#define CLK_PHASE_MASK 0x3
> +#define CLK_PHASE_0 0
> +#define CLK_PHASE_90 1
> +#define CLK_PHASE_180 2
> +#define CLK_PHASE_270 3
> +#define CLK_ALWAYS_ON BIT(24)
> +
> +#define SD_EMMC_DElAY 0x4
> +#define SD_EMMC_ADJUST 0x8
> +#define SD_EMMC_CALOUT 0x10
> +#define SD_EMMC_START 0x40
> +#define START_DESC_INIT BIT(0)
> +#define START_DESC_BUSY BIT(1)
> +#define START_DESC_ADDR_SHIFT 2
> +#define START_DESC_ADDR_MASK (~0x3)
> +
> +#define SD_EMMC_CFG 0x44
> +#define CFG_BUS_WIDTH_SHIFT 0
> +#define CFG_BUS_WIDTH_MASK 0x3
> +#define CFG_BUS_WIDTH_1 0x0
> +#define CFG_BUS_WIDTH_4 0x1
> +#define CFG_BUS_WIDTH_8 0x2
> +#define CFG_DDR BIT(2)
> +#define CFG_BLK_LEN_SHIFT 4
> +#define CFG_BLK_LEN_MASK 0xf
> +#define CFG_RESP_TIMEOUT_SHIFT 8
> +#define CFG_RESP_TIMEOUT_MASK 0xf
> +#define CFG_RC_CC_SHIFT 12
> +#define CFG_RC_CC_MASK 0xf
> +#define CFG_STOP_CLOCK BIT(22)
> +#define CFG_CLK_ALWAYS_ON BIT(18)
> +#define CFG_AUTO_CLK BIT(23)
> +
> +#define SD_EMMC_STATUS 0x48
> +#define STATUS_BUSY BIT(31)
> +
> +#define SD_EMMC_IRQ_EN 0x4c
> +#define IRQ_EN_MASK 0x3fff
> +#define IRQ_RXD_ERR_SHIFT 0
> +#define IRQ_RXD_ERR_MASK 0xff
> +#define IRQ_TXD_ERR BIT(8)
> +#define IRQ_DESC_ERR BIT(9)
> +#define IRQ_RESP_ERR BIT(10)
> +#define IRQ_RESP_TIMEOUT BIT(11)
> +#define IRQ_DESC_TIMEOUT BIT(12)
> +#define IRQ_END_OF_CHAIN BIT(13)
> +#define IRQ_RESP_STATUS BIT(14)
> +#define IRQ_SDIO BIT(15)
> +
> +#define SD_EMMC_CMD_CFG 0x50
> +#define SD_EMMC_CMD_ARG 0x54
> +#define SD_EMMC_CMD_DAT 0x58
> +#define SD_EMMC_CMD_RSP 0x5c
> +#define SD_EMMC_CMD_RSP1 0x60
> +#define SD_EMMC_CMD_RSP2 0x64
> +#define SD_EMMC_CMD_RSP3 0x68
> +
> +#define SD_EMMC_RXD 0x94
> +#define SD_EMMC_TXD 0x94
> +#define SD_EMMC_LAST_REG SD_EMMC_TXD
> +
> +#define SD_EMMC_CFG_BLK_SIZE 512 /* internal buffer max: 512 bytes */
> +#define SD_EMMC_CFG_RESP_TIMEOUT 256 /* in clock cycles */
> +#define SD_EMMC_CFG_CMD_GAP 16 /* in clock cycles */
> +#define MUX_CLK_NUM_PARENTS 2
> +
> +struct meson_host {
> + struct device *dev;
> + struct mmc_host *mmc;
> + struct mmc_request *mrq;
> + struct mmc_command *cmd;
> +
> + spinlock_t lock;
> + void __iomem *regs;
> + int irq;
> + u32 ocr_mask;
> + struct clk *core_clk;
> + struct clk_mux mux;
> + struct clk *mux_clk;
> + struct clk *mux_parent[MUX_CLK_NUM_PARENTS];
> + unsigned long mux_parent_rate[MUX_CLK_NUM_PARENTS];
> +
> + struct clk_divider cfg_div;
> + struct clk *cfg_div_clk;
> +
> + unsigned int bounce_buf_size;
> + void *bounce_buf;
> + dma_addr_t bounce_dma_addr;
> +
> + bool vqmmc_enabled;
> +};
> +
> +struct sd_emmc_desc {
> + u32 cmd_cfg;
> + u32 cmd_arg;
> + u32 cmd_data;
> + u32 cmd_resp;
> +};
> +#define CMD_CFG_LENGTH_SHIFT 0
> +#define CMD_CFG_LENGTH_MASK 0x1ff
> +#define CMD_CFG_BLOCK_MODE BIT(9)
> +#define CMD_CFG_R1B BIT(10)
> +#define CMD_CFG_END_OF_CHAIN BIT(11)
> +#define CMD_CFG_TIMEOUT_SHIFT 12
> +#define CMD_CFG_TIMEOUT_MASK 0xf
> +#define CMD_CFG_NO_RESP BIT(16)
> +#define CMD_CFG_NO_CMD BIT(17)
> +#define CMD_CFG_DATA_IO BIT(18)
> +#define CMD_CFG_DATA_WR BIT(19)
> +#define CMD_CFG_RESP_NOCRC BIT(20)
> +#define CMD_CFG_RESP_128 BIT(21)
> +#define CMD_CFG_RESP_NUM BIT(22)
> +#define CMD_CFG_DATA_NUM BIT(23)
> +#define CMD_CFG_CMD_INDEX_SHIFT 24
> +#define CMD_CFG_CMD_INDEX_MASK 0x3f
> +#define CMD_CFG_ERROR BIT(30)
> +#define CMD_CFG_OWNER BIT(31)
> +
> +#define CMD_DATA_MASK (~0x3)
> +#define CMD_DATA_BIG_ENDIAN BIT(1)
> +#define CMD_DATA_SRAM BIT(0)
> +#define CMD_RESP_MASK (~0x1)
> +#define CMD_RESP_SRAM BIT(0)
> +
> +static int meson_mmc_clk_set(struct meson_host *host, unsigned long clk_rate)
> +{
> + struct mmc_host *mmc = host->mmc;
> + int ret = 0;
> + u32 cfg;
> +
> + if (clk_rate) {
> + if (WARN_ON(clk_rate > mmc->f_max))
> + clk_rate = mmc->f_max;
> + else if (WARN_ON(clk_rate < mmc->f_min))
> + clk_rate = mmc->f_min;
> + }
> +
> + if (clk_rate == mmc->actual_clock)
> + return 0;
> +
> + /* stop clock */
> + cfg = readl(host->regs + SD_EMMC_CFG);
> + if (!(cfg & CFG_STOP_CLOCK)) {
> + cfg |= CFG_STOP_CLOCK;
> + writel(cfg, host->regs + SD_EMMC_CFG);
> + }
> +
> + dev_dbg(host->dev, "change clock rate %u -> %lu\n",
> + mmc->actual_clock, clk_rate);
> +
> + if (clk_rate == 0) {
> + mmc->actual_clock = 0;
> + return 0;
> + }
> +
> + ret = clk_set_rate(host->cfg_div_clk, clk_rate);
> + if (ret)
> + dev_warn(host->dev, "Unable to set cfg_div_clk to %lu. ret=%d\n",
> + clk_rate, ret);
> + else if (clk_rate && clk_rate != clk_get_rate(host->cfg_div_clk))
> + dev_warn(host->dev, "divider requested rate %lu != actual rate %lu: ret=%d\n",
> + clk_rate, clk_get_rate(host->cfg_div_clk), ret);
> + else
> + mmc->actual_clock = clk_rate;
> +
> + /* (re)start clock, if non-zero */
> + if (!ret && clk_rate) {
> + cfg = readl(host->regs + SD_EMMC_CFG);
> + cfg &= ~CFG_STOP_CLOCK;
> + writel(cfg, host->regs + SD_EMMC_CFG);
> + }
> +
> + return ret;
> +}
> +
> +/*
> + * The SD/eMMC IP block has an internal mux and divider used for
> + * generating the MMC clock. Use the clock framework to create and
> + * manage these clocks.
> + */
> +static int meson_mmc_clk_init(struct meson_host *host)
> +{
> + struct clk_init_data init;
> + char clk_name[32];
> + int i, ret = 0;
> + const char *mux_parent_names[MUX_CLK_NUM_PARENTS];
> + unsigned int mux_parent_count = 0;
> + const char *clk_div_parents[1];
> + unsigned int f_min = UINT_MAX;
> + u32 clk_reg, cfg;
> +
> + /* get the mux parents */
> + for (i = 0; i < MUX_CLK_NUM_PARENTS; i++) {
> + char name[16];
> +
> + snprintf(name, sizeof(name), "clkin%d", i);
> + host->mux_parent[i] = devm_clk_get(host->dev, name);
> + if (IS_ERR(host->mux_parent[i])) {
> + ret = PTR_ERR(host->mux_parent[i]);
> + if (PTR_ERR(host->mux_parent[i]) != -EPROBE_DEFER)
> + dev_err(host->dev, "Missing clock %s\n", name);
> + host->mux_parent[i] = NULL;
> + return ret;
> + }
> +
> + host->mux_parent_rate[i] = clk_get_rate(host->mux_parent[i]);
> + mux_parent_names[i] = __clk_get_name(host->mux_parent[i]);
> + mux_parent_count++;
> + if (host->mux_parent_rate[i] < f_min)
> + f_min = host->mux_parent_rate[i];
> + }
> +
> + /* cacluate f_min based on input clocks, and max divider value */
> + if (f_min != UINT_MAX)
> + f_min = DIV_ROUND_UP(CLK_SRC_XTAL_RATE, CLK_DIV_MAX);
> + else
> + f_min = 4000000; /* default min: 400 MHz */
> + host->mmc->f_min = f_min;
> +
> + /* create the mux */
> + snprintf(clk_name, sizeof(clk_name), "%s#mux", dev_name(host->dev));
> + init.name = clk_name;
> + init.ops = &clk_mux_ops;
> + init.flags = 0;
> + init.parent_names = mux_parent_names;
> + init.num_parents = mux_parent_count;
> +
> + host->mux.reg = host->regs + SD_EMMC_CLOCK;
> + host->mux.shift = CLK_SRC_SHIFT;
> + host->mux.mask = CLK_SRC_MASK;
> + host->mux.flags = 0;
> + host->mux.table = NULL;
> + host->mux.hw.init = &init;
> +
> + host->mux_clk = devm_clk_register(host->dev, &host->mux.hw);
> + if (WARN_ON(IS_ERR(host->mux_clk)))
> + return PTR_ERR(host->mux_clk);
> +
> + /* create the divider */
> + snprintf(clk_name, sizeof(clk_name), "%s#div", dev_name(host->dev));
> + init.name = devm_kstrdup(host->dev, clk_name, GFP_KERNEL);
> + init.ops = &clk_divider_ops;
> + init.flags = CLK_SET_RATE_PARENT;
> + clk_div_parents[0] = __clk_get_name(host->mux_clk);
> + init.parent_names = clk_div_parents;
> + init.num_parents = ARRAY_SIZE(clk_div_parents);
> +
> + host->cfg_div.reg = host->regs + SD_EMMC_CLOCK;
> + host->cfg_div.shift = CLK_DIV_SHIFT;
> + host->cfg_div.width = CLK_DIV_WIDTH;
> + host->cfg_div.hw.init = &init;
> + host->cfg_div.flags = CLK_DIVIDER_ONE_BASED |
> + CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ALLOW_ZERO;
> +
> + host->cfg_div_clk = devm_clk_register(host->dev, &host->cfg_div.hw);
> + if (WARN_ON(PTR_ERR_OR_ZERO(host->cfg_div_clk)))
> + return PTR_ERR(host->cfg_div_clk);
> +
> + /* init SD_EMMC_CLOCK to sane defaults w/min clock rate */
> + clk_reg = 0;
> + clk_reg |= CLK_PHASE_180 << CLK_PHASE_SHIFT;
> + clk_reg |= CLK_SRC_XTAL << CLK_SRC_SHIFT;
> + clk_reg |= CLK_DIV_MAX << CLK_DIV_SHIFT;
> + clk_reg &= ~CLK_ALWAYS_ON;
> + writel(clk_reg, host->regs + SD_EMMC_CLOCK);
> +
> + /* Ensure clock starts in "auto" mode, not "always on" */
> + cfg = readl(host->regs + SD_EMMC_CFG);
> + cfg &= ~CFG_CLK_ALWAYS_ON;
> + cfg |= CFG_AUTO_CLK;
> + writel(cfg, host->regs + SD_EMMC_CFG);
> +
> + ret = clk_prepare_enable(host->cfg_div_clk);
> + if (!ret)
> + ret = meson_mmc_clk_set(host, f_min);
> +
> + if (!ret)
> + clk_disable_unprepare(host->cfg_div_clk);
> +
> + return ret;
> +}
> +
> +static void meson_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> +{
> + struct meson_host *host = mmc_priv(mmc);
> + u32 bus_width;
> + u32 val, orig;
> +
> + /*
> + * GPIO regulator, only controls switching between 1v8 and
> + * 3v3, doesn't support MMC_POWER_OFF, MMC_POWER_ON.
> + */
> + switch (ios->power_mode) {
> + case MMC_POWER_OFF:
> + if (!IS_ERR(mmc->supply.vmmc))
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, 0);
> +
> + if (!IS_ERR(mmc->supply.vqmmc) && host->vqmmc_enabled) {
> + regulator_disable(mmc->supply.vqmmc);
> + host->vqmmc_enabled = false;
> + }
> +
> + break;
> +
> + case MMC_POWER_UP:
> + if (!IS_ERR(mmc->supply.vmmc))
> + mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, ios->vdd);
> + break;
> +
> + case MMC_POWER_ON:
> + if (!IS_ERR(mmc->supply.vqmmc) && !host->vqmmc_enabled) {
> + int ret = regulator_enable(mmc->supply.vqmmc);
> +
> + if (ret < 0)
> + dev_err(mmc_dev(mmc),
> + "failed to enable vqmmc regulator\n");
> + else
> + host->vqmmc_enabled = true;
> + }
> +
> + break;
> + }
> +
> +
> + meson_mmc_clk_set(host, ios->clock);
> +
> + /* Bus width */
> + val = readl(host->regs + SD_EMMC_CFG);
> + switch (ios->bus_width) {
> + case MMC_BUS_WIDTH_1:
> + bus_width = CFG_BUS_WIDTH_1;
> + break;
> + case MMC_BUS_WIDTH_4:
> + bus_width = CFG_BUS_WIDTH_4;
> + break;
> + case MMC_BUS_WIDTH_8:
> + bus_width = CFG_BUS_WIDTH_8;
> + break;
> + default:
> + dev_err(host->dev, "Invalid ios->bus_width: %u. Setting to 4.\n",
> + ios->bus_width);
> + bus_width = CFG_BUS_WIDTH_4;
> + return;
> + }
> +
> + val = readl(host->regs + SD_EMMC_CFG);
> + orig = val;
> +
> + val &= ~(CFG_BUS_WIDTH_MASK << CFG_BUS_WIDTH_SHIFT);
> + val |= bus_width << CFG_BUS_WIDTH_SHIFT;
> +
> + val &= ~(CFG_BLK_LEN_MASK << CFG_BLK_LEN_SHIFT);
> + val |= ilog2(SD_EMMC_CFG_BLK_SIZE) << CFG_BLK_LEN_SHIFT;
> +
> + val &= ~(CFG_RESP_TIMEOUT_MASK << CFG_RESP_TIMEOUT_SHIFT);
> + val |= ilog2(SD_EMMC_CFG_RESP_TIMEOUT) << CFG_RESP_TIMEOUT_SHIFT;
> +
> + val &= ~(CFG_RC_CC_MASK << CFG_RC_CC_SHIFT);
> + val |= ilog2(SD_EMMC_CFG_CMD_GAP) << CFG_RC_CC_SHIFT;
> +
> + writel(val, host->regs + SD_EMMC_CFG);
> +
> + if (val != orig)
> + dev_dbg(host->dev, "%s: SD_EMMC_CFG: 0x%08x -> 0x%08x\n",
> + __func__, orig, val);
> +}
> +
> +static int meson_mmc_request_done(struct mmc_host *mmc, struct mmc_request *mrq)
> +{
> + struct meson_host *host = mmc_priv(mmc);
> +
> + WARN_ON(host->mrq != mrq);
> +
> + host->mrq = NULL;
> + host->cmd = NULL;
> + mmc_request_done(host->mmc, mrq);
> +
> + return 0;
> +}
> +
> +static void meson_mmc_start_cmd(struct mmc_host *mmc, struct mmc_command *cmd)
> +{
> + struct meson_host *host = mmc_priv(mmc);
> + struct sd_emmc_desc *desc, desc_tmp;
> + u32 cfg;
> + u8 blk_len, cmd_cfg_timeout;
> + unsigned int xfer_bytes = 0;
> +
> + /* Setup descriptors */
> + dma_rmb();
> + desc = &desc_tmp;
> + memset(desc, 0, sizeof(struct sd_emmc_desc));
> +
> + desc->cmd_cfg |= (cmd->opcode & CMD_CFG_CMD_INDEX_MASK) <<
> + CMD_CFG_CMD_INDEX_SHIFT;
> + desc->cmd_cfg |= CMD_CFG_OWNER; /* owned by CPU */
> + desc->cmd_arg = cmd->arg;
> +
> + /* Response */
> + if (cmd->flags & MMC_RSP_PRESENT) {
> + desc->cmd_cfg &= ~CMD_CFG_NO_RESP;
> + if (cmd->flags & MMC_RSP_136)
> + desc->cmd_cfg |= CMD_CFG_RESP_128;
> + desc->cmd_cfg |= CMD_CFG_RESP_NUM;
> + desc->cmd_resp = 0;
> +
> + if (!(cmd->flags & MMC_RSP_CRC))
> + desc->cmd_cfg |= CMD_CFG_RESP_NOCRC;
> +
> + if (cmd->flags & MMC_RSP_BUSY)
> + desc->cmd_cfg |= CMD_CFG_R1B;
> + } else {
> + desc->cmd_cfg |= CMD_CFG_NO_RESP;
> + }
> +
> + /* data? */
> + if (cmd->data) {
> + desc->cmd_cfg |= CMD_CFG_DATA_IO;
> + if (cmd->data->blocks > 1) {
> + desc->cmd_cfg |= CMD_CFG_BLOCK_MODE;
> + desc->cmd_cfg |=
> + (cmd->data->blocks & CMD_CFG_LENGTH_MASK) <<
> + CMD_CFG_LENGTH_SHIFT;
> +
> + /* check if block-size matches, if not update */
> + cfg = readl(host->regs + SD_EMMC_CFG);
> + blk_len = cfg & (CFG_BLK_LEN_MASK << CFG_BLK_LEN_SHIFT);
> + blk_len >>= CFG_BLK_LEN_SHIFT;
> + if (blk_len != ilog2(cmd->data->blksz)) {
> + dev_warn(host->dev, "%s: update blk_len %d -> %d\n",
> + __func__, blk_len,
> + ilog2(cmd->data->blksz));
> + blk_len = ilog2(cmd->data->blksz);
> + cfg &= ~(CFG_BLK_LEN_MASK << CFG_BLK_LEN_SHIFT);
> + cfg |= blk_len << CFG_BLK_LEN_SHIFT;
> + writel(cfg, host->regs + SD_EMMC_CFG);
> + }
> + } else {
> + desc->cmd_cfg &= ~CMD_CFG_BLOCK_MODE;
> + desc->cmd_cfg |=
> + (cmd->data->blksz & CMD_CFG_LENGTH_MASK) <<
> + CMD_CFG_LENGTH_SHIFT;
> + }
> +
> + cmd->data->bytes_xfered = 0;
> + xfer_bytes = cmd->data->blksz * cmd->data->blocks;
> + if (cmd->data->flags & MMC_DATA_WRITE) {
> + desc->cmd_cfg |= CMD_CFG_DATA_WR;
> + WARN_ON(xfer_bytes > host->bounce_buf_size);
> + sg_copy_to_buffer(cmd->data->sg, cmd->data->sg_len,
> + host->bounce_buf, xfer_bytes);
> + cmd->data->bytes_xfered = xfer_bytes;
> + dma_wmb();
> + } else {
> + desc->cmd_cfg &= ~CMD_CFG_DATA_WR;
> + }
> +
> + if (xfer_bytes > 0) {
> + desc->cmd_cfg &= ~CMD_CFG_DATA_NUM;
> + desc->cmd_data = host->bounce_dma_addr & CMD_DATA_MASK;
> + } else {
> + /* write data to data_addr */
> + desc->cmd_cfg |= CMD_CFG_DATA_NUM;
> + desc->cmd_data = 0;
> + }
> +
> + cmd_cfg_timeout = 12;
> + } else {
> + desc->cmd_cfg &= ~CMD_CFG_DATA_IO;
> + cmd_cfg_timeout = 10;
> + }
> + desc->cmd_cfg |= (cmd_cfg_timeout & CMD_CFG_TIMEOUT_MASK) <<
> + CMD_CFG_TIMEOUT_SHIFT;
> +
> + host->cmd = cmd;
> +
> + /* Last descriptor */
> + desc->cmd_cfg |= CMD_CFG_END_OF_CHAIN;
> + writel(desc->cmd_cfg, host->regs + SD_EMMC_CMD_CFG);
> + writel(desc->cmd_data, host->regs + SD_EMMC_CMD_DAT);
> + writel(desc->cmd_resp, host->regs + SD_EMMC_CMD_RSP);
> + wmb(); /* ensure descriptor is written before kicked */
> + writel(desc->cmd_arg, host->regs + SD_EMMC_CMD_ARG);
> +}
> +
> +static void meson_mmc_request(struct mmc_host *mmc, struct mmc_request *mrq)
> +{
> + struct meson_host *host = mmc_priv(mmc);
> +
> + WARN_ON(host->mrq != NULL);
> +
> + /* Stop execution */
> + writel(0, host->regs + SD_EMMC_START);
> +
> + /* clear, ack, enable all interrupts */
> + writel(0, host->regs + SD_EMMC_IRQ_EN);
> + writel(IRQ_EN_MASK, host->regs + SD_EMMC_STATUS);
> + writel(IRQ_EN_MASK, host->regs + SD_EMMC_IRQ_EN);
> +
> + host->mrq = mrq;
> +
> + if (mrq->sbc)
> + meson_mmc_start_cmd(mmc, mrq->sbc);
> + else
> + meson_mmc_start_cmd(mmc, mrq->cmd);
> +}
> +
> +static int meson_mmc_read_resp(struct mmc_host *mmc, struct mmc_command *cmd)
> +{
> + struct meson_host *host = mmc_priv(mmc);
> +
> + if (cmd->flags & MMC_RSP_136) {
> + cmd->resp[0] = readl(host->regs + SD_EMMC_CMD_RSP3);
> + cmd->resp[1] = readl(host->regs + SD_EMMC_CMD_RSP2);
> + cmd->resp[2] = readl(host->regs + SD_EMMC_CMD_RSP1);
> + cmd->resp[3] = readl(host->regs + SD_EMMC_CMD_RSP);
> + } else if (cmd->flags & MMC_RSP_PRESENT) {
> + cmd->resp[0] = readl(host->regs + SD_EMMC_CMD_RSP);
> + }
> +
> + return 0;
> +}
> +
> +static irqreturn_t meson_mmc_irq(int irq, void *dev_id)
> +{
> + struct meson_host *host = dev_id;
> + struct mmc_request *mrq;
> + struct mmc_command *cmd = host->cmd;
> + u32 irq_en, status, raw_status;
> + irqreturn_t ret = IRQ_HANDLED;
> +
> + if (WARN_ON(!host))
> + return IRQ_NONE;
> +
> + mrq = host->mrq;
> +
> + if (WARN_ON(!mrq))
> + return IRQ_NONE;
> +
> + if (WARN_ON(!cmd))
> + return IRQ_NONE;
> +
> + spin_lock(&host->lock);
> + irq_en = readl(host->regs + SD_EMMC_IRQ_EN);
> + raw_status = readl(host->regs + SD_EMMC_STATUS);
> + status = raw_status & irq_en;
> +
> + if (!status) {
> + dev_warn(host->dev, "Spurious IRQ! status=0x%08x, irq_en=0x%08x\n",
> + raw_status, irq_en);
> + ret = IRQ_NONE;
> + goto out;
> + }
> +
> + cmd->error = 0;
> + if (status & IRQ_RXD_ERR_MASK) {
> + dev_dbg(host->dev, "Unhandled IRQ: RXD error\n");
> + cmd->error = -EILSEQ;
> + }
> + if (status & IRQ_TXD_ERR) {
> + dev_dbg(host->dev, "Unhandled IRQ: TXD error\n");
> + cmd->error = -EILSEQ;
> + }
> + if (status & IRQ_DESC_ERR)
> + dev_dbg(host->dev, "Unhandled IRQ: Descriptor error\n");
> + if (status & IRQ_RESP_ERR) {
> + dev_dbg(host->dev, "Unhandled IRQ: Response error\n");
> + cmd->error = -EILSEQ;
> + }
> + if (status & IRQ_RESP_TIMEOUT) {
> + dev_dbg(host->dev, "Unhandled IRQ: Response timeout\n");
> + cmd->error = -ETIMEDOUT;
> + }
> + if (status & IRQ_DESC_TIMEOUT) {
> + dev_dbg(host->dev, "Unhandled IRQ: Descriptor timeout\n");
> + cmd->error = -ETIMEDOUT;
> + }
> + if (status & IRQ_SDIO)
> + dev_dbg(host->dev, "Unhandled IRQ: SDIO.\n");
> +
> + if (status & (IRQ_END_OF_CHAIN | IRQ_RESP_STATUS))
> + ret = IRQ_WAKE_THREAD;
> + else {
> + dev_warn(host->dev, "Unknown IRQ! status=0x%04x: MMC CMD%u arg=0x%08x flags=0x%08x stop=%d\n",
> + status, cmd->opcode, cmd->arg,
> + cmd->flags, mrq->stop ? 1 : 0);
> + if (cmd->data) {
> + struct mmc_data *data = cmd->data;
> +
> + dev_warn(host->dev, "\tblksz %u blocks %u flags 0x%08x (%s%s)",
> + data->blksz, data->blocks, data->flags,
> + data->flags & MMC_DATA_WRITE ? "write" : "",
> + data->flags & MMC_DATA_READ ? "read" : "");
> + }
> + }
> +
> +out:
> + /* ack all (enabled) interrupts */
> + writel(status, host->regs + SD_EMMC_STATUS);
> +
> + if (ret == IRQ_HANDLED) {
> + meson_mmc_read_resp(host->mmc, cmd);
> + meson_mmc_request_done(host->mmc, cmd->mrq);
> + }
> +
> + spin_unlock(&host->lock);
> + return ret;
> +}
> +
> +static irqreturn_t meson_mmc_irq_thread(int irq, void *dev_id)
> +{
> + struct meson_host *host = dev_id;
> + struct mmc_request *mrq = host->mrq;
> + struct mmc_command *cmd = host->cmd;
> + struct mmc_data *data;
> + unsigned int xfer_bytes;
> + int ret = IRQ_HANDLED;
> +
> + if (WARN_ON(!mrq))
> + ret = IRQ_NONE;
> +
> + if (WARN_ON(!cmd))
> + ret = IRQ_NONE;
> +
> + data = cmd->data;
> + if (data) {
> + xfer_bytes = data->blksz * data->blocks;
> + if (data->flags & MMC_DATA_READ) {
> + WARN_ON(xfer_bytes > host->bounce_buf_size);
> + sg_copy_from_buffer(data->sg, data->sg_len,
> + host->bounce_buf, xfer_bytes);
> + data->bytes_xfered = xfer_bytes;
> + }
> + }
> +
> + meson_mmc_read_resp(host->mmc, cmd);
> + if (!data || !data->stop || mrq->sbc)
> + meson_mmc_request_done(host->mmc, mrq);
> + else
> + meson_mmc_start_cmd(host->mmc, data->stop);
> +
> + return ret;
> +}
> +
> +/*
> + * NOTE: we only need this until the GPIO/pinctrl driver can handle
> + * interrupts. For now, the MMC core will use this for polling.
> + */
> +static int meson_mmc_get_cd(struct mmc_host *mmc)
> +{
> + int status = mmc_gpio_get_cd(mmc);
> +
> + if (status == -ENOSYS)
> + return 1; /* assume present */
> +
> + return status;
> +}
> +
> +static const struct mmc_host_ops meson_mmc_ops = {
> + .request = meson_mmc_request,
> + .set_ios = meson_mmc_set_ios,
> + .get_cd = meson_mmc_get_cd,
> +};
> +
> +static int meson_mmc_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + struct meson_host *host;
> + struct mmc_host *mmc;
> + int ret;
> +
> + mmc = mmc_alloc_host(sizeof(struct meson_host), &pdev->dev);
> + if (!mmc)
> + return -ENOMEM;
> + host = mmc_priv(mmc);
> + host->mmc = mmc;
> + host->dev = &pdev->dev;
> + dev_set_drvdata(&pdev->dev, host);
> +
> + spin_lock_init(&host->lock);
> +
> + /* Get regulators and the supported OCR mask */
> + host->vqmmc_enabled = false;
> + ret = mmc_regulator_get_supply(mmc);
> + if (ret == -EPROBE_DEFER)
> + goto free_host;
> +
> + ret = mmc_of_parse(mmc);
> + if (ret) {
> + dev_warn(&pdev->dev, "error parsing DT: %d\n", ret);
> + goto free_host;
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + host->regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(host->regs)) {
> + ret = PTR_ERR(host->regs);
> + goto free_host;
> + }
> +
> + host->irq = platform_get_irq(pdev, 0);
> + if (host->irq == 0) {
> + dev_err(&pdev->dev, "failed to get interrupt resource.\n");
> + ret = -EINVAL;
> + goto free_host;
> + }
> +
> + host->core_clk = devm_clk_get(&pdev->dev, "core");
> + if (IS_ERR(host->core_clk)) {
> + ret = PTR_ERR(host->core_clk);
> + goto free_host;
> + }
> +
> + ret = clk_prepare_enable(host->core_clk);
> + if (ret)
> + goto free_host;
> +
> + ret = meson_mmc_clk_init(host);
> + if (ret)
> + goto free_host;
> +
> + /* Stop execution */
> + writel(0, host->regs + SD_EMMC_START);
> +
> + /* clear, ack, enable all interrupts */
> + writel(0, host->regs + SD_EMMC_IRQ_EN);
> + writel(IRQ_EN_MASK, host->regs + SD_EMMC_STATUS);
> +
> + ret = devm_request_threaded_irq(&pdev->dev, host->irq,
> + meson_mmc_irq, meson_mmc_irq_thread,
> + IRQF_SHARED, DRIVER_NAME, host);
> + if (ret)
> + goto free_host;
> +
> + /* data bounce buffer */
> + host->bounce_buf_size = SZ_512K;
> + host->bounce_buf =
> + dma_alloc_coherent(host->dev, host->bounce_buf_size,
> + &host->bounce_dma_addr, GFP_KERNEL);
> + if (host->bounce_buf == NULL) {
> + dev_err(host->dev, "Unable to map allocate DMA bounce buffer.\n");
> + ret = -ENOMEM;
> + goto free_host;
> + }
> +
> + mmc->ops = &meson_mmc_ops;
> + mmc_add_host(mmc);
> +
> + return 0;
> +
> +free_host:
> + clk_disable_unprepare(host->cfg_div_clk);
> + clk_disable_unprepare(host->core_clk);
> + mmc_free_host(mmc);
> + return ret;
> +}
> +
> +static int meson_mmc_remove(struct platform_device *pdev)
> +{
> + struct meson_host *host = dev_get_drvdata(&pdev->dev);
> +
> + if (WARN_ON(!host))
> + return 0;
> +
> + if (host->bounce_buf)
> + dma_free_coherent(host->dev, host->bounce_buf_size,
> + host->bounce_buf, host->bounce_dma_addr);
> +
> + clk_disable_unprepare(host->cfg_div_clk);
> + clk_disable_unprepare(host->core_clk);
> +
> + mmc_free_host(host->mmc);
> + return 0;
> +}
> +
> +static const struct of_device_id meson_mmc_of_match[] = {
> + { .compatible = "amlogic,meson-gx-mmc", },
> + { .compatible = "amlogic,meson-gxbb-mmc", },
> + { .compatible = "amlogic,meson-gxl-mmc", },
> + { .compatible = "amlogic,meson-gxm-mmc", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, meson_mmc_of_match);
> +
> +static struct platform_driver meson_mmc_driver = {
> + .probe = meson_mmc_probe,
> + .remove = meson_mmc_remove,
> + .driver = {
> + .name = DRIVER_NAME,
> + .of_match_table = of_match_ptr(meson_mmc_of_match),
> + },
> +};
> +
> +module_platform_driver(meson_mmc_driver);
> +
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> +MODULE_DESCRIPTION("Amlogic S905/GXBB SD/eMMC driver");
> +MODULE_AUTHOR("Kevin Hilman <khilman@baylibre.com>");
> +MODULE_LICENSE("GPL v2");
> +
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH] gpu: Remove depends on RESET_CONTROLLER when not a provider
From: Daniel Vetter @ 2016-10-19 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018205719.20575-1-stephen.boyd@linaro.org>
On Tue, Oct 18, 2016 at 01:57:19PM -0700, Stephen Boyd wrote:
> These GPU drivers only depend on the RESET_CONTROLLER config
> option to fix build issues that existed when there weren't stub
> reset APIs for reset controller consumers. Given that these
> drivers aren't providing any reset controllers themselves, they
> don't actually depend on the API to build (just to function) so
> they don't need to depend on it. Remove the dependency to fix
> recursive build errors like the following:
>
> drivers/usb/Kconfig:39:error: recursive dependency detected!
> drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
> drivers/input/mouse/Kconfig:187: symbol MOUSE_APPLETOUCH depends on INPUT
> drivers/input/Kconfig:8: symbol INPUT is selected by VT
> drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
> drivers/video/fbdev/Kconfig:674: symbol FB_STI depends on FB
> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:42: symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER
> drivers/gpu/drm/Kconfig:98: symbol DRM_KMS_CMA_HELPER is selected by DRM_IMX
> drivers/gpu/drm/imx/Kconfig:1: symbol DRM_IMX depends on IMX_IPUV3_CORE
> drivers/gpu/ipu-v3/Kconfig:1: symbol IMX_IPUV3_CORE depends on RESET_CONTROLLER
> drivers/reset/Kconfig:4: symbol RESET_CONTROLLER is selected by USB_CHIPIDEA
> drivers/usb/chipidea/Kconfig:1: symbol USB_CHIPIDEA depends on USB_EHCI_HCD
> drivers/usb/host/Kconfig:84: symbol USB_EHCI_HCD depends on USB
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: <dri-devel@lists.freedesktop.org>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Mark Yao <mark.yao@rock-chips.com>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Yay for proper stubbing! Applied to drm-misc, thanks.
-Daniel
> ---
>
> This has come out of some USB chipidea patches I've been working on. Please see
> http://lkml.kernel.org/r/20160907213519.27340-1-stephen.boyd at linaro.org for
> more details.
>
> I'm resending with the ack from Philipp picked up.
>
> drivers/gpu/drm/rockchip/Kconfig | 1 -
> drivers/gpu/drm/tegra/Kconfig | 1 -
> drivers/gpu/ipu-v3/Kconfig | 1 -
> 3 files changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
> index 3c58669a06ce..6f7f9c59f05b 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -1,7 +1,6 @@
> config DRM_ROCKCHIP
> tristate "DRM Support for Rockchip"
> depends on DRM && ROCKCHIP_IOMMU
> - depends on RESET_CONTROLLER
> select DRM_GEM_CMA_HELPER
> select DRM_KMS_HELPER
> select DRM_PANEL
> diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
> index 63ebb154b9b5..bbf5a4b7e0b6 100644
> --- a/drivers/gpu/drm/tegra/Kconfig
> +++ b/drivers/gpu/drm/tegra/Kconfig
> @@ -3,7 +3,6 @@ config DRM_TEGRA
> depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
> depends on COMMON_CLK
> depends on DRM
> - depends on RESET_CONTROLLER
> select DRM_KMS_HELPER
> select DRM_MIPI_DSI
> select DRM_PANEL
> diff --git a/drivers/gpu/ipu-v3/Kconfig b/drivers/gpu/ipu-v3/Kconfig
> index aefdff95356d..08766c6e7856 100644
> --- a/drivers/gpu/ipu-v3/Kconfig
> +++ b/drivers/gpu/ipu-v3/Kconfig
> @@ -1,7 +1,6 @@
> config IMX_IPUV3_CORE
> tristate "IPUv3 core support"
> depends on SOC_IMX5 || SOC_IMX6Q || ARCH_MULTIPLATFORM
> - depends on RESET_CONTROLLER
> select GENERIC_IRQ_CHIP
> help
> Choose this if you have a i.MX5/6 system and want to use the Image
> --
> 2.10.0.297.gf6727b0
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 04/10] mm: replace get_user_pages_locked() write/force parameters with gup_flags
From: Jan Kara @ 2016-10-19 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018135609.GA30025@lucifer>
On Tue 18-10-16 14:56:09, Lorenzo Stoakes wrote:
> On Tue, Oct 18, 2016 at 02:54:25PM +0200, Jan Kara wrote:
> > > @@ -1282,7 +1282,7 @@ long get_user_pages(unsigned long start, unsigned long nr_pages,
> > > int write, int force, struct page **pages,
> > > struct vm_area_struct **vmas);
> > > long get_user_pages_locked(unsigned long start, unsigned long nr_pages,
> > > - int write, int force, struct page **pages, int *locked);
> > > + unsigned int gup_flags, struct page **pages, int *locked);
> >
> > Hum, the prototype is inconsistent with e.g. __get_user_pages_unlocked()
> > where gup_flags come after **pages argument. Actually it makes more sense
> > to have it before **pages so that input arguments come first and output
> > arguments second but I don't care that much. But it definitely should be
> > consistent...
>
> It was difficult to decide quite how to arrange parameters as there was
> inconsitency with regards to parameter ordering already - for example
> __get_user_pages() places its flags argument before pages whereas, as you note,
> __get_user_pages_unlocked() puts them afterwards.
>
> I ended up compromising by trying to match the existing ordering of the function
> as much as I could by replacing write, force pairs with gup_flags in the same
> location (with the exception of get_user_pages_unlocked() which I felt should
> match __get_user_pages_unlocked() in signature) or if there was already a
> gup_flags parameter as in the case of __get_user_pages_unlocked() I simply
> removed the write, force pair and left the flags as the last parameter.
>
> I am happy to rearrange parameters as needed, however I am not sure if it'd be
> worthwhile for me to do so (I am keen to try to avoid adding too much noise here
> :)
>
> If we were to rearrange parameters for consistency I'd suggest adjusting
> __get_user_pages_unlocked() to put gup_flags before pages and do the same with
> get_user_pages_unlocked(), let me know what you think.
Yeah, ok. If the inconsistency is already there, just leave it for now.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH 04/10] mm: replace get_user_pages_locked() write/force parameters with gup_flags
From: Jan Kara @ 2016-10-19 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013002020.3062-5-lstoakes@gmail.com>
On Thu 13-10-16 01:20:14, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from get_user_pages_locked()
> and replaces them with a gup_flags parameter to make the use of FOLL_FORCE
> explicit in callers as use of this flag can result in surprising behaviour (and
> hence bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
After our discussion the patch looks good to me. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH 05/10] mm: replace get_vaddr_frames() write/force parameters with gup_flags
From: Jan Kara @ 2016-10-19 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013002020.3062-6-lstoakes@gmail.com>
On Thu 13-10-16 01:20:15, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from get_vaddr_frames() and
> replaces them with a gup_flags parameter to make the use of FOLL_FORCE explicit
> in callers as use of this flag can result in surprising behaviour (and hence
> bugs) within the mm subsystem.
>
> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Looks good. You can add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 ++-
> drivers/media/platform/omap/omap_vout.c | 2 +-
> drivers/media/v4l2-core/videobuf2-memops.c | 6 +++++-
> include/linux/mm.h | 2 +-
> mm/frame_vector.c | 13 ++-----------
> 5 files changed, 11 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index aa92dec..fbd13fa 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -488,7 +488,8 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct drm_device *drm_dev,
> goto err_free;
> }
>
> - ret = get_vaddr_frames(start, npages, true, true, g2d_userptr->vec);
> + ret = get_vaddr_frames(start, npages, FOLL_FORCE | FOLL_WRITE,
> + g2d_userptr->vec);
> if (ret != npages) {
> DRM_ERROR("failed to get user pages from userptr.\n");
> if (ret < 0)
> diff --git a/drivers/media/platform/omap/omap_vout.c b/drivers/media/platform/omap/omap_vout.c
> index e668dde..a31b95c 100644
> --- a/drivers/media/platform/omap/omap_vout.c
> +++ b/drivers/media/platform/omap/omap_vout.c
> @@ -214,7 +214,7 @@ static int omap_vout_get_userptr(struct videobuf_buffer *vb, u32 virtp,
> if (!vec)
> return -ENOMEM;
>
> - ret = get_vaddr_frames(virtp, 1, true, false, vec);
> + ret = get_vaddr_frames(virtp, 1, FOLL_WRITE, vec);
> if (ret != 1) {
> frame_vector_destroy(vec);
> return -EINVAL;
> diff --git a/drivers/media/v4l2-core/videobuf2-memops.c b/drivers/media/v4l2-core/videobuf2-memops.c
> index 3c3b517..1cd322e 100644
> --- a/drivers/media/v4l2-core/videobuf2-memops.c
> +++ b/drivers/media/v4l2-core/videobuf2-memops.c
> @@ -42,6 +42,10 @@ struct frame_vector *vb2_create_framevec(unsigned long start,
> unsigned long first, last;
> unsigned long nr;
> struct frame_vector *vec;
> + unsigned int flags = FOLL_FORCE;
> +
> + if (write)
> + flags |= FOLL_WRITE;
>
> first = start >> PAGE_SHIFT;
> last = (start + length - 1) >> PAGE_SHIFT;
> @@ -49,7 +53,7 @@ struct frame_vector *vb2_create_framevec(unsigned long start,
> vec = frame_vector_create(nr);
> if (!vec)
> return ERR_PTR(-ENOMEM);
> - ret = get_vaddr_frames(start & PAGE_MASK, nr, write, true, vec);
> + ret = get_vaddr_frames(start & PAGE_MASK, nr, flags, vec);
> if (ret < 0)
> goto out_destroy;
> /* We accept only complete set of PFNs */
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 27ab538..5ff084f6 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1305,7 +1305,7 @@ struct frame_vector {
> struct frame_vector *frame_vector_create(unsigned int nr_frames);
> void frame_vector_destroy(struct frame_vector *vec);
> int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
> - bool write, bool force, struct frame_vector *vec);
> + unsigned int gup_flags, struct frame_vector *vec);
> void put_vaddr_frames(struct frame_vector *vec);
> int frame_vector_to_pages(struct frame_vector *vec);
> void frame_vector_to_pfns(struct frame_vector *vec);
> diff --git a/mm/frame_vector.c b/mm/frame_vector.c
> index 81b6749..db77dcb 100644
> --- a/mm/frame_vector.c
> +++ b/mm/frame_vector.c
> @@ -11,10 +11,7 @@
> * get_vaddr_frames() - map virtual addresses to pfns
> * @start: starting user address
> * @nr_frames: number of pages / pfns from start to map
> - * @write: whether pages will be written to by the caller
> - * @force: whether to force write access even if user mapping is
> - * readonly. See description of the same argument of
> - get_user_pages().
> + * @gup_flags: flags modifying lookup behaviour
> * @vec: structure which receives pages / pfns of the addresses mapped.
> * It should have space for at least nr_frames entries.
> *
> @@ -34,23 +31,17 @@
> * This function takes care of grabbing mmap_sem as necessary.
> */
> int get_vaddr_frames(unsigned long start, unsigned int nr_frames,
> - bool write, bool force, struct frame_vector *vec)
> + unsigned int gup_flags, struct frame_vector *vec)
> {
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma;
> int ret = 0;
> int err;
> int locked;
> - unsigned int gup_flags = 0;
>
> if (nr_frames == 0)
> return 0;
>
> - if (write)
> - gup_flags |= FOLL_WRITE;
> - if (force)
> - gup_flags |= FOLL_FORCE;
> -
> if (WARN_ON_ONCE(nr_frames > vec->nr_allocated))
> nr_frames = vec->nr_allocated;
>
> --
> 2.10.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH] ARM: dt: sun8i-h3: Add sunxi-sid to dts for sun8i-h3
From: LABBE Corentin @ 2016-10-19 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161005122130.8cc229ff5d4990149956b49c@free.fr>
On Wed, Oct 05, 2016 at 12:21:30PM +0200, Jean-Francois Moine wrote:
> On Wed, 5 Oct 2016 11:48:24 +0200
> Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
>
> > This patch add support for the sunxi-sid driver to the device tree for sun8i-h3.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > arch/arm/boot/dts/sun8i-h3.dtsi | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> > index 9f58bb4..abfd29c 100644
> > --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> > @@ -211,6 +211,11 @@
> > #size-cells = <0>;
> > };
> >
> > + sid: eeprom at 01c14200 {
> > + compatible = "allwinner,sun7i-a20-sid";
> > + reg = <0x01c14200 0x200>;
>
> The datasheet says 1Kb starting at 0x01c14000.
> Is there any reason to reduce the area and to shift the offset?
>
According to http://linux-sunxi.org/SID_Register_Guide "For Allwinner A83T and H3 the SID address space starts at 0x01c14000, and the e-fuses are at offset 0x200".
So I use this offset, since the sunxi_sid driver need the base address of e-fuses.
The easiest solution is to use 0x01c14200 since the other part of sid is not used and not known (A83T/H3 user manual doesnt give any information on all sid space, worse for A64 which reference SID only in memory map).
So probably for H3/A64/A83T, there will never any usage of the rest of the SID address space.
Regards
Corentin Labbe
^ 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