* [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
From: Y.B. Lu @ 2016-10-31 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2723366.1bJeJ7SKI6@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, October 28, 2016 6:53 PM
> To: linuxppc-dev at lists.ozlabs.org
> Cc: Y.B. Lu; linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i2c at vger.kernel.org; linux-clk at vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Claudiu Manoil; devicetree at vger.kernel.org;
> Rob Herring; Santosh Shilimkar; linux-arm-kernel at lists.infradead.org;
> netdev at vger.kernel.org; linux-kernel at vger.kernel.org; Leo Li;
> iommu at lists.linux-foundation.org; Kumar Gala
> Subject: Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
>
> On Friday, October 28, 2016 2:50:14 PM CEST Yangbo Lu wrote:
> > Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
> > header file. This SVR numberspace is used on some ARM chips as well
> > as PPC, and even to check for a PPC SVR multi-arch drivers would
> > otherwise need to ifdef the header inclusion and all references to the
> SVR symbols.
> >
> >
>
> I don't see any of the contents of this header referenced by the soc
> driver any more. I think you can just drop this patch.
>
[Lu Yangbo-B47093] This header file was included by guts.c.
The guts driver used macro SVR_MAJ/SVR_MIN for calculation.
This header file was for powerpc arch before. And this patch is to made it as common header file for both ARM and PPC.
Sooner or later this is needed.
> Arnd
^ permalink raw reply
* [v15, 0/7] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-10-31 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3386858.dvuMhvkN3m@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Friday, October 28, 2016 6:54 PM
> To: linux-arm-kernel at lists.infradead.org
> Cc: Y.B. Lu; linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i2c at vger.kernel.org; linux-clk at vger.kernel.org; Qiang Zhao; Russell King;
> Bhupesh Sharma; Joerg Roedel; Jochen Friedrich; Claudiu Manoil;
> devicetree at vger.kernel.org; Rob Herring; Santosh Shilimkar;
> netdev at vger.kernel.org; linux-kernel at vger.kernel.org; Leo Li;
> iommu at lists.linux-foundation.org; Kumar Gala; linuxppc-
> dev at lists.ozlabs.org
> Subject: Re: [v15, 0/7] Fix eSDHC host version register bug
>
> On Friday, October 28, 2016 2:50:11 PM CEST Yangbo Lu 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 five 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.
> >
>
> Looks good overall. With patch 3 dropped (or an explanation why it's
> still needed), everything
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
[Lu Yangbo-B47093] Thank you very much:) See my explaination in patch 3 email.
> Arnd
^ permalink raw reply
* [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Bartosz Golaszewski @ 2016-10-31 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031043015.74ppaship5nqfaqt@rob-hp-laptop>
2016-10-31 5:30 GMT+01:00 Rob Herring <robh@kernel.org>:
> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>> Create the driver for the da8xx master peripheral priority
>> configuration and implement support for writing to the three
>> Master Priority registers on da850 SoCs.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
>> drivers/bus/Kconfig | 9 +
>> drivers/bus/Makefile | 2 +
>> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
>> 4 files changed, 297 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>> create mode 100644 drivers/bus/da8xx-mstpri.c
>>
>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>> new file mode 100644
>> index 0000000..225af09
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>> @@ -0,0 +1,20 @@
>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>> + priority driver
>> +
>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>> +peripherals classified as masters.
>> +
>> +Documentation:
>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>> +
>> +Required properties:
>> +
>> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
>
> Drop syscon. Doesn't look like it is needed and the example doesn't
> match.
Hi Rob,
it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
fixed the example instead.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Neil Armstrong @ 2016-10-31 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ5VG2NGRh5CmYcYzwCp0LYSsgxHogCFa+6W7BDDBXOYg@mail.gmail.com>
On 10/24/2016 03:03 AM, Linus Walleij wrote:
> On Fri, Oct 21, 2016 at 4:40 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>
>> Add support for the Amlogic Meson GXL SoC, this is a partially complete
>> definition only based on the Amlogic Vendor tree.
>>
>> This definition differs a lot from the GXBB and needs a separate entry.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>
> Looks good to me. Tell me when I may apply it, it looks orthogonal
> to the rest of the patches.
>
> Yours,
> Linus Walleij
>
Hi Linus,
I'm ok to have it applied as soon as possible, but I can send a clean non-rfc patch if needed.
Thanks,
Neil
^ permalink raw reply
* [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Sekhar Nori @ 2016-10-31 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJW85TQObLdoGW2ApnkM8OiM4d1ZDd=9eyGmeVXXwqByPQ@mail.gmail.com>
Hi Bartosz,
On Monday 31 October 2016 03:10 PM, Bartosz Golaszewski wrote:
> 2016-10-31 5:30 GMT+01:00 Rob Herring <robh@kernel.org>:
>> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>>> Create the driver for the da8xx master peripheral priority
>>> configuration and implement support for writing to the three
>>> Master Priority registers on da850 SoCs.
>>>
>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>> ---
>>> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
>>> drivers/bus/Kconfig | 9 +
>>> drivers/bus/Makefile | 2 +
>>> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
>>> 4 files changed, 297 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>> create mode 100644 drivers/bus/da8xx-mstpri.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>> new file mode 100644
>>> index 0000000..225af09
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>> @@ -0,0 +1,20 @@
>>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>>> + priority driver
>>> +
>>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>>> +peripherals classified as masters.
>>> +
>>> +Documentation:
>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>>> +
>>> +Required properties:
>>> +
>>> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
>>
>> Drop syscon. Doesn't look like it is needed and the example doesn't
>> match.
>
> Hi Rob,
>
> it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
> fixed the example instead.
Why are master priority registers under syscon? This driver should be
the only entity touching them. So do we need an MFD driver?
Thanks,
Sekhar
^ permalink raw reply
* [GIT PULL] ARM: OXNAS SoC updates for 4.10
From: Neil Armstrong @ 2016-10-31 9:52 UTC (permalink / raw)
To: linux-arm-kernel
Dear arm-soc maintainers,
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/OXNAS/linux.git tags/oxnas-arm-soc-for-4.10
for you to fetch changes up to b3cdb3c5ef514687891f03442f2677850340bcfa:
ARM: oxnas: Add OX820 config and makefile entry (2016-10-31 10:41:33 +0100)
----------------------------------------------------------------
- Add SMP support for the Oxford Semiconductor OX820 SoC
from http://lkml.kernel.org/r/20161021085848.1754-1-narmstrong at baylibre.com
----------------------------------------------------------------
Neil Armstrong (2):
ARM: oxnas: Add OX820 SMP support
ARM: oxnas: Add OX820 config and makefile entry
arch/arm/Makefile | 1 +
arch/arm/mach-oxnas/Kconfig | 30 +++++++++++++++++++---------
arch/arm/mach-oxnas/Makefile | 2 ++
arch/arm/mach-oxnas/headsmp.S | 28 ++++++++++++++++++++++++++
arch/arm/mach-oxnas/hotplug.c | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-oxnas/platsmp.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 267 insertions(+), 9 deletions(-)
create mode 100644 arch/arm/mach-oxnas/Makefile
create mode 100644 arch/arm/mach-oxnas/headsmp.S
create mode 100644 arch/arm/mach-oxnas/hotplug.c
create mode 100644 arch/arm/mach-oxnas/platsmp.c
Thanks,
Neil
^ permalink raw reply
* [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver
From: Bartosz Golaszewski @ 2016-10-31 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0cac724d-1aee-dfa7-9b78-8366fd6fceff@ti.com>
2016-10-31 10:52 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> Hi Bartosz,
>
> On Monday 31 October 2016 03:10 PM, Bartosz Golaszewski wrote:
>> 2016-10-31 5:30 GMT+01:00 Rob Herring <robh@kernel.org>:
>>> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>>>> Create the driver for the da8xx master peripheral priority
>>>> configuration and implement support for writing to the three
>>>> Master Priority registers on da850 SoCs.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>> ---
>>>> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
>>>> drivers/bus/Kconfig | 9 +
>>>> drivers/bus/Makefile | 2 +
>>>> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
>>>> 4 files changed, 297 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>> create mode 100644 drivers/bus/da8xx-mstpri.c
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>> new file mode 100644
>>>> index 0000000..225af09
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>> @@ -0,0 +1,20 @@
>>>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>>>> + priority driver
>>>> +
>>>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>>>> +peripherals classified as masters.
>>>> +
>>>> +Documentation:
>>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>>>> +
>>>> +Required properties:
>>>> +
>>>> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
>>>
>>> Drop syscon. Doesn't look like it is needed and the example doesn't
>>> match.
>>
>> Hi Rob,
>>
>> it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
>> fixed the example instead.
>
> Why are master priority registers under syscon? This driver should be
> the only entity touching them. So do we need an MFD driver?
>
It should, but syscfg0 registers are mapped all over the place. I
thought it would be safer to put them under syscon and Kevin agreed.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH] net: stmmac: Add OXNAS Glue Driver
From: Neil Armstrong @ 2016-10-31 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161030204110.otvjlanmi7dv7fox@rob-hp-laptop>
On 10/30/2016 09:41 PM, Rob Herring wrote:
> On Fri, Oct 21, 2016 at 10:44:45AM +0200, Neil Armstrong wrote:
>> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 +++++
>
> It's preferred that bindings are a separate patch.
OK
>
>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
>> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
>> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 219 +++++++++++++++++++++
>> 4 files changed, 275 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
>>
>> Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
>> - Drop init/exit callbacks
>> - Implement proper remove and PM callback
>> - Call init from probe
>> - Disable/Unprepare clock if stmmac probe fails
>>
>> diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>> new file mode 100644
>> index 0000000..5d2696c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>> @@ -0,0 +1,44 @@
>> +* Oxford Semiconductor OXNAS DWMAC Ethernet controller
>> +
>> +The device inherits all the properties of the dwmac/stmmac devices
>> +described in the file stmmac.txt in the current directory with the
>> +following changes.
>> +
>> +Required properties on all platforms:
>> +
>> +- compatible: Depending on the platform this should be one of:
>> + - "oxsemi,ox820-dwmac"
>> + Additionally "snps,dwmac" and any applicable more
>> + detailed version number described in net/stmmac.txt
>> + should be used.
>
> You should be explicit what version applies to ox820. "snps,dwmac"
> should probably be deprecated IMO. There are so many variations of DW
> h/w.
Well, to be honest I have absolutely no idea ! But I will try to find out...
>
>> +
>> +- reg: The first register range should be the one of the DWMAC
>> + controller.
>
> This is worded like there's a 2nd range?
OK, will rephrase.
>
>> +
>> +- clocks: Should contain phandles to the following clocks
>> +- clock-names: Should contain the following:
>> + - "stmmaceth" - see stmmac.txt
>> + - "gmac" - peripheral gate clock
>> +
>> +- oxsemi,sys-ctrl: a phandle to the system controller syscon node
>> +
>> +Example :
>> +
>> +etha: ethernet at 40400000 {
>> + compatible = "oxsemi,ox820-dwmac", "snps,dwmac";
>> + reg = <0x40400000 0x2000>;
>> + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "macirq", "eth_wake_irq";
>> + mac-address = [000000000000]; /* Filled in by U-Boot */
>> + phy-mode = "rgmii";
>> +
>> + clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
>> + clock-names = "gmac", "stmmaceth";
>> + resets = <&reset RESET_MAC>;
>> +
>> + /* Regmap for sys registers */
>> + oxsemi,sys-ctrl = <&sys>;
>> +
>> + status = "disabled";
>> +};
^ permalink raw reply
* [PATCH 0/3] ARM: dts: oxnas: Update support for OX820 and use dt-bindings
From: Neil Armstrong @ 2016-10-31 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021151037.20112-1-narmstrong@baylibre.com>
On 10/21/2016 05:10 PM, Neil Armstrong wrote:
> This patchset updates the ARM DTS for the Oxnas platform by :
> - Add support for the Oxford Semicondutor OX820 and the PogoPlug V3
> - Update the OX810SE to use the dt-bindings includes files introduced in [1] and [2]
> - Fix the MAINTAINERS entry and add the PogoPlug V3 file maintainance
>
> This patchset depends on dt-bindings include headers posted at [1] and [2],
> that were accepted/merged in the subsystem trees.
>
> How could I manage this dependency for 4.10 ?
>
> [1] https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg00008.html
> [2] https://listengine.tuxfamily.org/lists.tuxfamily.org/linux-oxnas/2016/10/msg00007.html
>
> Neil Armstrong (3):
> ARM: dts: Add support for OX820 and Pogoplug V3
> ARM: dts: OX810: Update with dt-bindings includes
> MAINTAINERS: oxnas: Add new files definitions
>
> Documentation/devicetree/bindings/arm/oxnas.txt | 5 +
> MAINTAINERS | 3 +-
> arch/arm/boot/dts/Makefile | 3 +-
> .../boot/dts/cloudengines-pogoplug-series-3.dts | 94 +++++++
> arch/arm/boot/dts/ox810se.dtsi | 10 +-
> arch/arm/boot/dts/ox820.dtsi | 298 +++++++++++++++++++++
> 6 files changed, 407 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
> create mode 100644 arch/arm/boot/dts/ox820.dtsi
>
Hi,
I'm ready to send a pull request for arm-soc-dt, but I need to understand how this dependency
should be worked out.
Should this be sent as a late pull request ?
Thanks,
Neil
^ permalink raw reply
* [PATCH V4 10/10] arm64: KVM: add guest SEA support
From: Russell King - ARM Linux @ 2016-10-31 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477071013-29563-11-git-send-email-tbaicar@codeaurora.org>
The subject line on this patch is misleading - it's not only ARM64
specific...
On Fri, Oct 21, 2016 at 11:30:13AM -0600, Tyler Baicar wrote:
> diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
> index a3d61ad..86e1faa 100644
> --- a/arch/arm/include/asm/system_misc.h
> +++ b/arch/arm/include/asm/system_misc.h
> @@ -24,4 +24,9 @@ extern unsigned int user_debug;
>
> #endif /* !__ASSEMBLY__ */
>
> +inline int handle_guest_sea(unsigned long addr, unsigned int esr)
This needs to be static.
> +{
> + return -1;
> +}
> +
> #endif /* __ASM_ARM_SYSTEM_MISC_H */
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: davinci: da850: Fix pwm name matching
From: Sekhar Nori @ 2016-10-31 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477418044-24603-1-git-send-email-david@lechnology.com>
On Tuesday 25 October 2016 11:24 PM, David Lechner wrote:
> This fixes pwm name matching for DA850 familiy devices. When using device
> tree, the da850_auxdata_lookup[] table caused pwm devices to have the exact
> same name, which caused errors when trying to register the devices.
>
> The names for clock matching in da850_clks[] also have to be updated to
> to exactly match in order for the clock lookup to work correctly.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>
> Tested working on LEGO MINDSTORMS EV3.
>
>
> arch/arm/mach-davinci/da850.c | 10 +++++++---
> arch/arm/mach-davinci/da8xx-dt.c | 10 +++++-----
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index ed3d0e9..6b78a8f 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -510,9 +510,13 @@ static struct clk_lookup da850_clks[] = {
> CLK("vpif", NULL, &vpif_clk),
> CLK("ahci_da850", NULL, &sata_clk),
> CLK("davinci-rproc.0", NULL, &dsp_clk),
> - CLK("ehrpwm", "fck", &ehrpwm_clk),
> - CLK("ehrpwm", "tbclk", &ehrpwm_tbclk),
> - CLK("ecap", "fck", &ecap_clk),
> + CLK("ehrpwm.0", "fck", &ehrpwm_clk),
> + CLK("ehrpwm.0", "tbclk", &ehrpwm_tbclk),
> + CLK("ehrpwm.1", "fck", &ehrpwm_clk),
> + CLK("ehrpwm.1", "tbclk", &ehrpwm_tbclk),
> + CLK("ecap.0", "fck", &ecap_clk),
> + CLK("ecap.1", "fck", &ecap_clk),
> + CLK("ecap.2", "fck", &ecap_clk),
This has exposed a limitation of DaVinci clock framework. The struct clk
are stored as a linked list themselves. So a node repeating in the table
above will create a loop in the linked list. This is easily seen on the
LCDK board. davinci_clk_disable_unused() never returns. PWMs are unused
on that board.
There is no "simple" solution to this AFAICS. One solution is to
separate the iterator from the clock hardware structure and use struct
clk_hw available in struct clk_lookup.
Or move DaVinci to common clock framework. This is of course preferred
but much more involved as all 6 supported SoCs have to be moved together.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] net: stmmac: Add OXNAS Glue Driver
From: Joachim Eastwood @ 2016-10-31 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04b8ed79-8efa-cc10-a9a3-fdee10e0723c@baylibre.com>
Hi Neil,
On 31 October 2016 at 10:55, Neil Armstrong <narmstrong@baylibre.com> wrote:
> On 10/30/2016 09:41 PM, Rob Herring wrote:
>> On Fri, Oct 21, 2016 at 10:44:45AM +0200, Neil Armstrong wrote:
>>> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>>>
>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>> ---
>>> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 +++++
>>
>> It's preferred that bindings are a separate patch.
>
> OK
>
>>
>>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
>>> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
>>> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 219 +++++++++++++++++++++
>>> 4 files changed, 275 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
>>>
>>> Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
>>> - Drop init/exit callbacks
>>> - Implement proper remove and PM callback
>>> - Call init from probe
>>> - Disable/Unprepare clock if stmmac probe fails
>>>
>>> diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>> new file mode 100644
>>> index 0000000..5d2696c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>> @@ -0,0 +1,44 @@
>>> +* Oxford Semiconductor OXNAS DWMAC Ethernet controller
>>> +
>>> +The device inherits all the properties of the dwmac/stmmac devices
>>> +described in the file stmmac.txt in the current directory with the
>>> +following changes.
>>> +
>>> +Required properties on all platforms:
>>> +
>>> +- compatible: Depending on the platform this should be one of:
>>> + - "oxsemi,ox820-dwmac"
>>> + Additionally "snps,dwmac" and any applicable more
>>> + detailed version number described in net/stmmac.txt
>>> + should be used.
>>
>> You should be explicit what version applies to ox820. "snps,dwmac"
>> should probably be deprecated IMO. There are so many variations of DW
>> h/w.
>
> Well, to be honest I have absolutely no idea ! But I will try to find out...
You can see in the boot log:
>From lpc18xx boot:
[ 3.242253] stmmac - user ID: 0x11, Synopsys ID: 0x36
[ 3.247653] Ring mode enabled
[ 3.251491] DMA HW capability register supported
[ 3.256336] Enhanced/Alternate descriptors
[ 3.261537] Enabled extended descriptors
[ 3.265968] RX Checksum Offload Engine supported (type 2)
[ 3.272249] TX Checksum insertion supported
[ 3.276874] Wake-Up On Lan supported
[ 3.283743] Enable RX Mitigation via HW Watchdog Timer
[ 3.326701] libphy: stmmac: probed
Synopsys ID: 0x36 and user UD: 0x11, gives us DWMAC version 3.611
regards,
Joachim Eastwood
^ permalink raw reply
* [PATCH] net: stmmac: Add OXNAS Glue Driver
From: Neil Armstrong @ 2016-10-31 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9Vxy+boEPV3pvRCAWAWh-Tie31oS0PG7F6ix5_Wf=JHxgg@mail.gmail.com>
On 10/31/2016 11:20 AM, Joachim Eastwood wrote:
> Hi Neil,
>
> On 31 October 2016 at 10:55, Neil Armstrong <narmstrong@baylibre.com> wrote:
>> On 10/30/2016 09:41 PM, Rob Herring wrote:
>>> On Fri, Oct 21, 2016 at 10:44:45AM +0200, Neil Armstrong wrote:
>>>> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 +++++
>>>
>>> It's preferred that bindings are a separate patch.
>>
>> OK
>>
>>>
>>>> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
>>>> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
>>>> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 219 +++++++++++++++++++++
>>>> 4 files changed, 275 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>>> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
>>>>
>>>> Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
>>>> - Drop init/exit callbacks
>>>> - Implement proper remove and PM callback
>>>> - Call init from probe
>>>> - Disable/Unprepare clock if stmmac probe fails
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>>> new file mode 100644
>>>> index 0000000..5d2696c
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
>>>> @@ -0,0 +1,44 @@
>>>> +* Oxford Semiconductor OXNAS DWMAC Ethernet controller
>>>> +
>>>> +The device inherits all the properties of the dwmac/stmmac devices
>>>> +described in the file stmmac.txt in the current directory with the
>>>> +following changes.
>>>> +
>>>> +Required properties on all platforms:
>>>> +
>>>> +- compatible: Depending on the platform this should be one of:
>>>> + - "oxsemi,ox820-dwmac"
>>>> + Additionally "snps,dwmac" and any applicable more
>>>> + detailed version number described in net/stmmac.txt
>>>> + should be used.
>>>
>>> You should be explicit what version applies to ox820. "snps,dwmac"
>>> should probably be deprecated IMO. There are so many variations of DW
>>> h/w.
>>
>> Well, to be honest I have absolutely no idea ! But I will try to find out...
>
> You can see in the boot log:
>
> From lpc18xx boot:
> [ 3.242253] stmmac - user ID: 0x11, Synopsys ID: 0x36
> [ 3.247653] Ring mode enabled
> [ 3.251491] DMA HW capability register supported
> [ 3.256336] Enhanced/Alternate descriptors
> [ 3.261537] Enabled extended descriptors
> [ 3.265968] RX Checksum Offload Engine supported (type 2)
> [ 3.272249] TX Checksum insertion supported
> [ 3.276874] Wake-Up On Lan supported
> [ 3.283743] Enable RX Mitigation via HW Watchdog Timer
> [ 3.326701] libphy: stmmac: probed
>
> Synopsys ID: 0x36 and user UD: 0x11, gives us DWMAC version 3.611
>
>
> regards,
> Joachim Eastwood
>
OK, thanks !
stmmac - user ID: 0x12, Synopsys ID: 0x35
Neil
^ permalink raw reply
* [PATCH] ARM: DT: stm32: move dma translation to board files
From: Bruno Herrera @ 2016-10-31 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFvLkMQGVygLb9SQ8o+2Q=bg7vvRjpHypmSyjRyLkdcHypoFHw@mail.gmail.com>
On Fri, Oct 28, 2016 at 5:09 AM, Rados?aw Pietrzyk
<radoslaw.pietrzyk@gmail.com> wrote:
> Have you defined your sdio node within soc node ?
It is in the SOC node of the DSTI file.
>
> 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com>:
>>
>> Hi Alex,
>>
>> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
>> <alexandre.torgue@st.com> wrote:
>> > Hi Bruno,
>> >
>> >
>> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
>> >>
>> >> Hi Alex,
>> >>
>> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
>> >> <alexandre.torgue@st.com> wrote:
>> >>>
>> >>> Hi Bruno,
>> >>>
>> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
>> >>>>
>> >>>>
>> >>>> Hi Alexandre,
>> >>>>
>> >>>>>
>> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM start address
>> >>>>> remapping
>> >>>>> (to @0) to boost performances. A DMA translation through
>> >>>>> "dma-ranges"
>> >>>>> property was needed for other masters than the M4 CPU.
>> >>>>> stm32f429-disco doesn't use remapping so doesn't need this DMA
>> >>>>> translation.
>> >>>>> This patches moves this DMA translation definition from stm32f429
>> >>>>> soc
>> >>>>> file
>> >>>>> to board files.
>> >>>>>
>> >>>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>> >>>>>
>> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>>> index 13c7cd2..a763c15 100644
>> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>>> @@ -82,6 +82,10 @@
>> >>>>> };
>> >>>>> };
>> >>>>>
>> >>>>> + soc {
>> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >>>>> + };
>> >>>>> +
>> >>>>> usbotg_hs_phy: usbphy {
>> >>>>> #phy-cells = <0>;
>> >>>>> compatible = "usb-nop-xceiv";
>> >>>>
>> >>>>
>> >>>>
>> >>>> Shouldn't also the peripheral dma-ranges property move to board
>> >>>> specific
>> >>>> too?
>> >>>> I had this patch for while but I didn't had the time to submit:
>> >>>
>> >>>
>> >>>
>> >>> Well spot I forgot it. Actually, discussing with Arnd ysterday on
>> >>> IIRC,
>> >>> empty dma-ranges is not needed. Can you test on your side by removing
>> >>> dma-ranges in usb node please ?
>> >>
>> >> Unfortunately will take a time for me to set up this environment on
>> >> the STM32F4-EVAL board.
>> >> And on the discovery boards we dont have this scenario. That was the
>> >> main reason I did not submit the patch right away.
>> >> My conclusion and I might be wrong but is based on the my tests with
>> >> SDIO device at STM32F469I-DISCO board.
>> >>
>> >> I started this issue as discussion at ST Forum but Maxime gave me the
>> >> hint.
>> >>
>> >>
>> >>
>> >> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44
>> >>
>> >>> I will push a v2 by removing empty dma-ranges if tests are ok in your
>> >>> side.
>> >>
>> >>
>> >> From my understating/conclusion is: when empty property(dma-ranges) is
>> >> the device node, the mapping will be taken in consideration when using
>> >> DMA otherwise the mapping is ignored.
>> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
>> >> MEM(SDRAM)->DEV. If it is not the case for the devices in question so
>> >> I suppose it can work without the property.
>> >
>> >
>> > For sure translation has to be done but I'm not sure that an empty
>> > "dma-ranges" is needed in device node to activate it. For Ethernet empty
>> > "dma-ranges" is not needed. I will try with usb.
>>
>> In the case of SDIO it is needed. As example this is my working SDIO node:
>>
>> sdio: sdio at 40012c00 {
>> compatible = "arm,pl18x", "arm,primecell";
>> arm,primecell-periphid = <0x00480181>;
>> reg = <0x40012c00 0x400>;
>> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
>> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
>> dma-names = "rx", "tx";
>> clocks = <&rcc 0 171>;
>> clock-names = "apb_pclk";
>> interrupts = <49>;
>> status = "disabled";
>> };
>>
>> &sdio {
>> status = "okay";
>> vmmc-supply = <&wlan_en>;
>> bus-width = <4>;
>> max-frequency = <24000000>;
>> pinctrl-names = "default";
>> pinctrl-0 = <&sdio_pins>;
>> ti,non-removable;
>> ti,needs-special-hs-handling;
>> dma-ranges;
>> cap-power-off-card;
>> keep-power-in-suspend;
>>
>> #address-cells = <1>;
>> #size-cells = <0>;
>> wlcore: wlcore at 0 {
>> compatible = "ti,wl1835";
>> reg = <2>;
>> interrupt-parent = <&gpioa>;
>> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
>> };
>> };
>>
>> >
>> > alex
>> >
>> >
>> >>
>> >>>
>> >>> Thanks in advance
>> >>> Alex
>> >>>
>> >>>
>> >>>>
>> >>>> Author: Bruno Herrera <bruherrera@gmail.com>
>> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
>> >>>>
>> >>>> ARM: DT: STM32: Use dma-ranges property per board not at dtsi
>> >>>> file
>> >>>>
>> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>> index 6bfc595..2a22a82 100644
>> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >>>> @@ -52,6 +52,10 @@
>> >>>> model = "STMicroelectronics STM32429i-EVAL board";
>> >>>> compatible = "st,stm32429i-eval", "st,stm32f429";
>> >>>>
>> >>>> + soc {
>> >>>> + dma-ranges = <0xC0000000 0x0 0x10000000>;
>> >>>> + };
>> >>>> +
>> >>>> chosen {
>> >>>> bootargs = "root=/dev/ram rdinit=/linuxrc";
>> >>>> stdout-path = "serial0:115200n8";
>> >>>> @@ -96,6 +100,7 @@
>> >>>>
>> >>>> ðernet0 {
>> >>>> status = "okay";
>> >>>> + dma-ranges;
>> >>>> pinctrl-0 = <ðernet0_mii>;
>> >>>> pinctrl-names = "default";
>> >>>> phy-mode = "mii-id";
>> >>>> @@ -116,6 +121,7 @@
>> >>>> };
>> >>>>
>> >>>> &usbotg_hs {
>> >>>> + dma-ranges;
>> >>>> dr_mode = "host";
>> >>>> phys = <&usbotg_hs_phy>;
>> >>>> phy-names = "usb2-phy";
>> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >>>> index 7d624a2..697a133 100644
>> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >>>> @@ -59,7 +59,6 @@
>> >>>> };
>> >>>>
>> >>>> soc {
>> >>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >>>>
>> >>>> timer2: timer at 40000000 {
>> >>>> compatible = "st,stm32-timer";
>> >>>> @@ -472,13 +471,11 @@
>> >>>> st,syscon = <&syscfg 0x4>;
>> >>>> snps,pbl = <8>;
>> >>>> snps,mixed-burst;
>> >>>> - dma-ranges;
>> >>>> status = "disabled";
>> >>>> };
>> >>>>
>> >>>> usbotg_hs: usb at 40040000 {
>> >>>> compatible = "snps,dwc2";
>> >>>> - dma-ranges;
>> >>>> reg = <0x40040000 0x40000>;
>> >>>> interrupts = <77>;
>> >>>> clocks = <&rcc 0 29>;
>> >>>>
>> >>>>
>> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >>>>> index 0596d60..3a1cfdd 100644
>> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >>>>> @@ -59,8 +59,6 @@
>> >>>>> };
>> >>>>>
>> >>>>> soc {
>> >>>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >>>>> -
>> >>>>> timer2: timer at 40000000 {
>> >>>>> compatible = "st,stm32-timer";
>> >>>>> reg = <0x40000000 0x400>;
>> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>> >>>>> index 9e73656..c2213c0 100644
>> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>> >>>>> @@ -64,6 +64,10 @@
>> >>>>> aliases {
>> >>>>> serial0 = &usart3;
>> >>>>> };
>> >>>>> +
>> >>>>> + soc {
>> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >>>>> + };
>> >>>>> };
>> >>>>>
>> >>>>> &clk_hse {
>> >>>>> --
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> Br.,
>> >>>> Bruno
>> >>>>
>> >>>
>> >
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
^ permalink raw reply
* [PATCH/RFC 4/4] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-10-31 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7122001.MSFYYEpnBs@wuerfel>
Hi Arnd,
On Sat, Oct 29, 2016 at 11:27 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Saturday, October 22, 2016 9:44:11 AM CEST Geert Uytterhoeven wrote:
>> On Fri, Oct 21, 2016 at 11:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday, October 21, 2016 8:16:00 PM CEST Geert Uytterhoeven wrote:
>> >> On Wed, Oct 19, 2016 at 12:59 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> > On Wednesday, October 19, 2016 10:02:57 AM CEST Geert Uytterhoeven wrote:
>> >> >> On Mon, Oct 10, 2016 at 4:23 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> > I'd prefer seeing a separate soc driver for that one.
>> >> >> Some SoCs have only CCCR, others have only PRR, some have both.
>> >> >> On some SoCs one of them can be accessed from the RealTime CPU
>> >> >> core (SH) only.
>> >> >> On some SoCs the register is not documented, but present.
>> >> >> If the PRR exists, it's a better choice, as it contains additional information
>> >> >> in the high order bits (representing the presence of each big (CA15/CA57),
>> >> >> little (CA7/CA53), and RT (CR7) CPU core). Currently we don't use that
>> >> >> information, though.
>> >> >>
>> >> >> Grouping them in some other way means we would loose the family name,
>> >> >> which is exposed through soc_dev_attr->family.
>> >> >> The usefulness of family names is debatable though, as this is more an
>> >> >> issue of marketing business.
>> >> >
>> >> > How about having a table to look up the family name by the value
>> >> > of the PRR or CCCR then?
>> >>
>> >> Unfortunately there exist SoCs from different families using the same
>> >> product ID.
>> >>
>> >> And different SoCs from the same family may have a revision register
>> >> or not (e.g. R-Car H1 has, M1A hasn't).
>> >
>> > Is this something we expect to see more of in the future, or can
>> > we expect future chips to handle this more consistently?
>>
>> I expect to see more of these in the future.
>>
>> Perhaps I just should forget about the product IDs and (marketing) families,
>> and just stick the CCCR/PRR addresses in the of_device_ids?
>> Then we'll have SoC names (e.g. "r8a7791") and (optional) revisions
>> (e.g. "ES1.0") to match on.
>
> I don't think listing the marketing names is a problem if we need a
> full list of all chips in of_device_ids anyway.
I'm removing the marketing names. We don't match them anyway (and probably
shouldn't, as we don't control them anyway, cfr.
https://www.renesas.com/en-us/solutions/automotive/products.html).
> I'm still hoping to be able to limit the need for specifying the
> register addresses in the driver instead.
Adding DT binding...
>> >> > How about this:
>> >> >
>> >> > The driver could report the hardcoded strings for the SoCs it already
>> >> > knows about (you have the table anyway) and not report the revision
>> >> > unless there is a regmap containing the CCCR or the PRR, in which
>> >> > case you use that. Future SoCs will provide the PRR (I assume
>> >> > CCCR is only used on the older ones) through a syscon regmap
>> >> > that we can use to find out the exact revision as well.
>> >> >
>> >> > The existing DT files can gain the syscon device so you can report
>> >> > the revision on those machines as well, unless you use an old DTB.
>> >>
>> >> Hmm... That means that if we have to add a driver quirk to distinguish
>> >> between different revisions of the same SoC, we have to update the
>> >> DTB anyway, to add the CCCR/PRR device node.
>> >> We might as well just change the compatible value in that DTB for the
>> >> device that needs the quirk. Which is what we'd like to avoid in the
>> >> first place.
>> >
>> > Do you have a specific example in mind? If this is only a theoretical
>> > problem, we can worry about it when we get there, and then decide
>> > if we add a hardcoded register after all.
>>
>> For R-Car H3, there are small differences between ES1.0 and ES1.1,
>> and more and larger differences between ES1.x and ES2.0, which
>> need different handling (patches already floating around).
>>
>> For (old) R-Car H1, the SATA driver already handles "renesas,sata-r8a7790-es1",
>> but so far there didn't exist an established process to specify how that
>> compatible value would end up in the DTB (the in-kernel DTS doesn't have it).
>>
>> There may be more differences I'm not aware of.
>
> Ok, so for R-Car H1, I assume we don't need the driver, it would just
> be a way to replace the current workaround with a different one, right?
>
> For R-Car H3, do we just require driver changes to work with ES2.0,
> or also DT changes? If the new chip version already implies a new DT,
> we can require the presence of a device node that has the correct
> register number.
H3 also needs DT changes for some features (e.g. different number of USB
channels, different topology for graphics).
soc_device_match() would mostly (only?) be used to handle limitations and
quirks in early revisions. These are intended to be removed once production
has been ramped up, and there's no longer a need to support them.
However, that also means soc_device_match() would be used to match against
early revisions, not against late revisions. I.e. the early SoCs need the chip
ID registers declared, not the new ones.
Stay tuned for v2...
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 2/2] ARM: bus: da8xx-mstpri: new driver
From: Sekhar Nori @ 2016-10-31 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJX7SjE1zs926Fn-=jsZhPsOK6ey0hHM8LBhNS1nuSuFFQ@mail.gmail.com>
On Monday 31 October 2016 03:24 PM, Bartosz Golaszewski wrote:
> 2016-10-31 10:52 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
>> Hi Bartosz,
>>
>> On Monday 31 October 2016 03:10 PM, Bartosz Golaszewski wrote:
>>> 2016-10-31 5:30 GMT+01:00 Rob Herring <robh@kernel.org>:
>>>> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>>>>> Create the driver for the da8xx master peripheral priority
>>>>> configuration and implement support for writing to the three
>>>>> Master Priority registers on da850 SoCs.
>>>>>
>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>>> ---
>>>>> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
>>>>> drivers/bus/Kconfig | 9 +
>>>>> drivers/bus/Makefile | 2 +
>>>>> drivers/bus/da8xx-mstpri.c | 266 +++++++++++++++++++++
>>>>> 4 files changed, 297 insertions(+)
>>>>> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>> create mode 100644 drivers/bus/da8xx-mstpri.c
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>> new file mode 100644
>>>>> index 0000000..225af09
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>> @@ -0,0 +1,20 @@
>>>>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>>>>> + priority driver
>>>>> +
>>>>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>>>>> +peripherals classified as masters.
>>>>> +
>>>>> +Documentation:
>>>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>>>>> +
>>>>> +Required properties:
>>>>> +
>>>>> +- compatible: "ti,da850-mstpri", "syscon" - for da850 based boards
>>>>
>>>> Drop syscon. Doesn't look like it is needed and the example doesn't
>>>> match.
>>>
>>> Hi Rob,
>>>
>>> it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
>>> fixed the example instead.
>>
>> Why are master priority registers under syscon? This driver should be
>> the only entity touching them. So do we need an MFD driver?
>>
>
> It should, but syscfg0 registers are mapped all over the place. I
Not sure what you mean by this. Yes, the sysconfig module has many
functionalities. But the registers for a given functionality are all
grouped together AFAICS (except CHIPCFGn, see below).
Pinmux registers are part of syscfg module, but don't use syscon.
In the work going on for OHCI support, chipcfg registers are being put
under a syscon node. But that makes sense, I think, because chipcfg
registers are catering to really diverse functionality like PLL and EDMA
related stuff being placed in the same register - CHIPCFG0.
> thought it would be safer to put them under syscon and Kevin agreed.
Before using syscon for the whole syscfg space, I think we need some
analysis as to where the likely races are going to be.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 0/2] net: stmmac: Add OXNAS DWMAC Glue
From: Neil Armstrong @ 2016-10-31 10:53 UTC (permalink / raw)
To: linux-arm-kernel
This patchset add support for the Sysnopsys DWMAC Gigabit Ethernet
controller Glue layer of the Oxford Semiconductor OX820 SoC.
Changes since v1 at https://patchwork.kernel.org/patch/9388231/ :
- Split dt-bindings in a separate patch
- Add IP version in the dt-bindings compatible
- Check return of clk_prepare_enable()
- use get_stmmac_bsp_priv() helper
- hardwire setup values in oxnas_dwmac_init()
Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
- Drop init/exit callbacks
- Implement proper remove and PM callback
- Call init from probe
- Disable/Unprepare clock if stmmac probe fails
Neil Armstrong (2):
net: stmmac: Add OXNAS Glue Driver
dt-bindings: net: Add OXNAS DWMAC Bindings
.../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 215 +++++++++++++++++++++
4 files changed, 266 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
--
2.7.0
^ permalink raw reply
* [PATCH v2 2/2] dt-bindings: net: Add OXNAS DWMAC Bindings
From: Neil Armstrong @ 2016-10-31 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031105345.16711-1-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/net/oxnas-dwmac.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
new file mode 100644
index 0000000..df0534e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt
@@ -0,0 +1,39 @@
+* Oxford Semiconductor OXNAS DWMAC Ethernet controller
+
+The device inherits all the properties of the dwmac/stmmac devices
+described in the file stmmac.txt in the current directory with the
+following changes.
+
+Required properties on all platforms:
+
+- compatible: For the OX820 SoC, it should be :
+ - "oxsemi,ox820-dwmac" to select glue
+ - "snps,dwmac-3.512" to select IP version.
+
+- clocks: Should contain phandles to the following clocks
+- clock-names: Should contain the following:
+ - "stmmaceth" for the host clock - see stmmac.txt
+ - "gmac" for the peripheral gate clock
+
+- oxsemi,sys-ctrl: a phandle to the system controller syscon node
+
+Example :
+
+etha: ethernet at 40400000 {
+ compatible = "oxsemi,ox820-dwmac", "snps,dwmac-3.512";
+ reg = <0x40400000 0x2000>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq", "eth_wake_irq";
+ mac-address = [000000000000]; /* Filled in by U-Boot */
+ phy-mode = "rgmii";
+
+ clocks = <&stdclk CLK_820_ETHA>, <&gmacclk>;
+ clock-names = "gmac", "stmmaceth";
+ resets = <&reset RESET_MAC>;
+
+ /* Regmap for sys registers */
+ oxsemi,sys-ctrl = <&sys>;
+
+ status = "disabled";
+};
--
2.7.0
^ permalink raw reply related
* [PATCH v2 1/2] net: stmmac: Add OXNAS Glue Driver
From: Neil Armstrong @ 2016-10-31 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031105345.16711-1-narmstrong@baylibre.com>
Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
Acked-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 215 ++++++++++++++++++++++
3 files changed, 227 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 3818c5e..6e9fcc3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -69,6 +69,17 @@ config DWMAC_MESON
the stmmac device driver. This driver is used for Meson6,
Meson8, Meson8b and GXBB SoCs.
+config DWMAC_OXNAS
+ tristate "Oxford Semiconductor OXNAS dwmac support"
+ default ARCH_OXNAS
+ depends on OF && COMMON_CLK && (ARCH_OXNAS || COMPILE_TEST)
+ select MFD_SYSCON
+ help
+ Support for Ethernet controller on Oxford Semiconductor OXNAS SoCs.
+
+ This selects the Oxford Semiconductor OXNASSoC glue layer support for
+ the stmmac device driver. This driver is used for OX820.
+
config DWMAC_ROCKCHIP
tristate "Rockchip dwmac support"
default ARCH_ROCKCHIP
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 5d6ece5..8f83a86 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
obj-$(CONFIG_DWMAC_IPQ806X) += dwmac-ipq806x.o
obj-$(CONFIG_DWMAC_LPC18XX) += dwmac-lpc18xx.o
obj-$(CONFIG_DWMAC_MESON) += dwmac-meson.o dwmac-meson8b.o
+obj-$(CONFIG_DWMAC_OXNAS) += dwmac-oxnas.o
obj-$(CONFIG_DWMAC_ROCKCHIP) += dwmac-rk.o
obj-$(CONFIG_DWMAC_SOCFPGA) += dwmac-altr-socfpga.o
obj-$(CONFIG_DWMAC_STI) += dwmac-sti.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
new file mode 100644
index 0000000..de3c36a
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
@@ -0,0 +1,215 @@
+/*
+ * Oxford Semiconductor OXNAS DWMAC glue layer
+ *
+ * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
+ * Copyright (C) 2014 Daniel Golle <daniel@makrotopia.org>
+ * Copyright (C) 2013 Ma Haijun <mahaijuns@gmail.com>
+ * Copyright (C) 2012 John Crispin <blogic@openwrt.org>
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
+#include <linux/stmmac.h>
+
+#include "stmmac_platform.h"
+
+/* System Control regmap offsets */
+#define OXNAS_DWMAC_CTRL_REGOFFSET 0x78
+#define OXNAS_DWMAC_DELAY_REGOFFSET 0x100
+
+/* Control Register */
+#define DWMAC_CKEN_RX_IN 14
+#define DWMAC_CKEN_RXN_OUT 13
+#define DWMAC_CKEN_RX_OUT 12
+#define DWMAC_CKEN_TX_IN 10
+#define DWMAC_CKEN_TXN_OUT 9
+#define DWMAC_CKEN_TX_OUT 8
+#define DWMAC_RX_SOURCE 7
+#define DWMAC_TX_SOURCE 6
+#define DWMAC_LOW_TX_SOURCE 4
+#define DWMAC_AUTO_TX_SOURCE 3
+#define DWMAC_RGMII 2
+#define DWMAC_SIMPLE_MUX 1
+#define DWMAC_CKEN_GTX 0
+
+/* Delay register */
+#define DWMAC_TX_VARDELAY_SHIFT 0
+#define DWMAC_TXN_VARDELAY_SHIFT 8
+#define DWMAC_RX_VARDELAY_SHIFT 16
+#define DWMAC_RXN_VARDELAY_SHIFT 24
+#define DWMAC_TX_VARDELAY(d) ((d) << DWMAC_TX_VARDELAY_SHIFT)
+#define DWMAC_TXN_VARDELAY(d) ((d) << DWMAC_TXN_VARDELAY_SHIFT)
+#define DWMAC_RX_VARDELAY(d) ((d) << DWMAC_RX_VARDELAY_SHIFT)
+#define DWMAC_RXN_VARDELAY(d) ((d) << DWMAC_RXN_VARDELAY_SHIFT)
+
+struct oxnas_dwmac {
+ struct device *dev;
+ struct clk *clk;
+ struct regmap *regmap;
+};
+
+static int oxnas_dwmac_init(struct oxnas_dwmac *dwmac)
+{
+ unsigned int value;
+ int ret;
+
+ /* Reset HW here before changing the glue configuration */
+ ret = device_reset(dwmac->dev);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(dwmac->clk);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, &value);
+ if (ret < 0)
+ return ret;
+
+ /* Enable GMII_GTXCLK to follow GMII_REFCLK, required for gigabit PHY */
+ value |= BIT(DWMAC_CKEN_GTX) |
+ /* Use simple mux for 25/125 Mhz clock switching */
+ BIT(DWMAC_SIMPLE_MUX) |
+ /* set auto switch tx clock source */
+ BIT(DWMAC_AUTO_TX_SOURCE) |
+ /* enable tx & rx vardelay */
+ BIT(DWMAC_CKEN_TX_OUT) |
+ BIT(DWMAC_CKEN_TXN_OUT) |
+ BIT(DWMAC_CKEN_TX_IN) |
+ BIT(DWMAC_CKEN_RX_OUT) |
+ BIT(DWMAC_CKEN_RXN_OUT) |
+ BIT(DWMAC_CKEN_RX_IN);
+ regmap_write(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, value);
+
+ /* set tx & rx vardelay */
+ value = DWMAC_TX_VARDELAY(4) |
+ DWMAC_TXN_VARDELAY(2) |
+ DWMAC_RX_VARDELAY(10) |
+ DWMAC_RXN_VARDELAY(8);
+ regmap_write(dwmac->regmap, OXNAS_DWMAC_DELAY_REGOFFSET, value);
+
+ return 0;
+}
+
+static int oxnas_dwmac_probe(struct platform_device *pdev)
+{
+ struct plat_stmmacenet_data *plat_dat;
+ struct stmmac_resources stmmac_res;
+ struct device_node *sysctrl;
+ struct oxnas_dwmac *dwmac;
+ int ret;
+
+ sysctrl = of_parse_phandle(pdev->dev.of_node, "oxsemi,sys-ctrl", 0);
+ if (!sysctrl) {
+ dev_err(&pdev->dev, "failed to get sys-ctrl node\n");
+ return -EINVAL;
+ }
+
+ ret = stmmac_get_platform_resources(pdev, &stmmac_res);
+ if (ret)
+ return ret;
+
+ plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
+ if (IS_ERR(plat_dat))
+ return PTR_ERR(plat_dat);
+
+ dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
+ if (!dwmac)
+ return -ENOMEM;
+
+ dwmac->dev = &pdev->dev;
+ plat_dat->bsp_priv = dwmac;
+
+ dwmac->regmap = syscon_node_to_regmap(sysctrl);
+ if (IS_ERR(dwmac->regmap)) {
+ dev_err(&pdev->dev, "failed to have sysctrl regmap\n");
+ return PTR_ERR(dwmac->regmap);
+ }
+
+ dwmac->clk = devm_clk_get(&pdev->dev, "gmac");
+ if (IS_ERR(dwmac->clk))
+ return PTR_ERR(dwmac->clk);
+
+ ret = oxnas_dwmac_init(dwmac);
+ if (ret)
+ return ret;
+
+ ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
+ if (ret)
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+static int oxnas_dwmac_remove(struct platform_device *pdev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(&pdev->dev);
+ int ret = stmmac_dvr_remove(&pdev->dev);
+
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int oxnas_dwmac_suspend(struct device *dev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(dev);
+ int ret;
+
+ ret = stmmac_suspend(dev);
+ clk_disable_unprepare(dwmac->clk);
+
+ return ret;
+}
+
+static int oxnas_dwmac_resume(struct device *dev)
+{
+ struct oxnas_dwmac *dwmac = get_stmmac_bsp_priv(dev);
+ int ret;
+
+ ret = oxnas_dwmac_init(dwmac);
+ if (ret)
+ return ret;
+
+ ret = stmmac_resume(dev);
+
+ return ret;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static SIMPLE_DEV_PM_OPS(oxnas_dwmac_pm_ops,
+ oxnas_dwmac_suspend, oxnas_dwmac_resume);
+
+static const struct of_device_id oxnas_dwmac_match[] = {
+ { .compatible = "oxsemi,ox820-dwmac" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, oxnas_dwmac_match);
+
+static struct platform_driver oxnas_dwmac_driver = {
+ .probe = oxnas_dwmac_probe,
+ .remove = oxnas_dwmac_remove,
+ .driver = {
+ .name = "oxnas-dwmac",
+ .pm = &oxnas_dwmac_pm_ops,
+ .of_match_table = oxnas_dwmac_match,
+ },
+};
+module_platform_driver(oxnas_dwmac_driver);
+
+MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
+MODULE_DESCRIPTION("Oxford Semiconductor OXNAS DWMAC glue layer");
+MODULE_LICENSE("GPL v2");
--
2.7.0
^ permalink raw reply related
* [PATCH 0/10] mmc: Add support to Marvell Xenon SD Host Controller
From: Gregory CLEMENT @ 2016-10-31 11:09 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This the second version of the series adding support for the SDHCI
Xenon controller. It can be currently found on the Armada 37xx and the
Armada 7K/8K but will be also used in more Marvell SoC (and not only
the mvebu ones actually).
Some of the remarks had been taking into account since the first
version, according to Ziji Hu, here are the following chcanges:
"Changes in V2:
rebase on v4.9-rc2.
Re-write Xenon bindings. Ajust Xenon DT property naming.
Add a new DT property to indicate eMMC card type, instead of using
variable card_candidate.
Clear quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 in Xenon platform data
Add support to HS400 retuning."
I think the main open point which remains is about issuing commands
from the ->set_ios() callback (in patch 7).
Ulf, could you comment about it?
Thanks,
Gregory
Gregory CLEMENT (3):
arm64: dts: marvell: add eMMC support for Armada 37xx
arm64: dts: marvell: add sdhci support for Armada 7K/8K
arm64: configs: enable SDHCI driver for Xenon
Ziji Hu (7):
mmc: sdhci: Export sdhci_set_ios() from sdhci.c
mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
mmc: sdhci: Export sdhci_execute_tuning() in sdhci.c
MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers
dt: bindings: Add bindings for Marvell Xenon SD Host Controller
mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 +-
MAINTAINERS | 7 +-
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 8 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 11 +-
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 8 +-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 9 +-
arch/arm64/configs/defconfig | 1 +-
drivers/mmc/host/Kconfig | 9 +-
drivers/mmc/host/Makefile | 3 +-
drivers/mmc/host/sdhci-xenon-phy.c | 1181 +++++++-
drivers/mmc/host/sdhci-xenon-phy.h | 157 +-
drivers/mmc/host/sdhci-xenon.c | 598 ++++-
drivers/mmc/host/sdhci-xenon.h | 159 +-
drivers/mmc/host/sdhci.c | 11 +-
drivers/mmc/host/sdhci.h | 4 +-
15 files changed, 2323 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
create mode 100644 drivers/mmc/host/sdhci-xenon-phy.c
create mode 100644 drivers/mmc/host/sdhci-xenon-phy.h
create mode 100644 drivers/mmc/host/sdhci-xenon.c
create mode 100644 drivers/mmc/host/sdhci-xenon.h
base-commit: 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942
--
git-series 0.8.10
^ permalink raw reply
* [PATCH 1/10] mmc: sdhci: Export sdhci_set_ios() from sdhci.c
From: Gregory CLEMENT @ 2016-10-31 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.86006f271b60cf7c0b4c5a51762a9dacca4c4718.1477911954.git-series.gregory.clement@free-electrons.com>
From: Ziji Hu <huziji@marvell.com>
Export sdhci_set_ios() in sdhci.c.
Thus vendor sdhci driver can implement its own set_ios() routine.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 71654b90227f..ea06faf8a437 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1563,7 +1563,7 @@ void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
}
EXPORT_SYMBOL_GPL(sdhci_set_uhs_signaling);
-static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
+void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct sdhci_host *host = mmc_priv(mmc);
unsigned long flags;
@@ -1723,6 +1723,7 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
mmiowb();
spin_unlock_irqrestore(&host->lock, flags);
}
+EXPORT_SYMBOL_GPL(sdhci_set_ios);
static int sdhci_get_cd(struct mmc_host *mmc)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 766df17fb7eb..37771de4cafa 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -688,6 +688,7 @@ void sdhci_set_power_noreg(struct sdhci_host *host, unsigned char mode,
void sdhci_set_bus_width(struct sdhci_host *host, int width);
void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
+void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 2/10] mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
From: Gregory CLEMENT @ 2016-10-31 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.86006f271b60cf7c0b4c5a51762a9dacca4c4718.1477911954.git-series.gregory.clement@free-electrons.com>
From: Ziji Hu <huziji@marvell.com>
Export sdhci_start_signal_voltage_switch() from sdhci.c.
Thus vendor sdhci driver can implement its own signal voltage
switch routine.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 5 +++--
drivers/mmc/host/sdhci.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ea06faf8a437..8e6e4e37e3b4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1832,8 +1832,8 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
spin_unlock_irqrestore(&host->lock, flags);
}
-static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
- struct mmc_ios *ios)
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
{
struct sdhci_host *host = mmc_priv(mmc);
u16 ctrl;
@@ -1925,6 +1925,7 @@ static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
return 0;
}
}
+EXPORT_SYMBOL_GPL(sdhci_start_signal_voltage_switch);
static int sdhci_card_busy(struct mmc_host *mmc)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 37771de4cafa..cd18b6f19c3b 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -689,6 +689,8 @@ void sdhci_set_bus_width(struct sdhci_host *host, int width);
void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 3/10] mmc: sdhci: Export sdhci_execute_tuning() in sdhci.c
From: Gregory CLEMENT @ 2016-10-31 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.86006f271b60cf7c0b4c5a51762a9dacca4c4718.1477911954.git-series.gregory.clement@free-electrons.com>
From: Ziji Hu <huziji@marvell.com>
Export sdhci_execute_tuning() from sdhci.c.
Thus vendor sdhci driver can execute its own tuning process.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 8e6e4e37e3b4..e971abb1368f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1950,7 +1950,7 @@ static int sdhci_prepare_hs400_tuning(struct mmc_host *mmc, struct mmc_ios *ios)
return 0;
}
-static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
+int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
{
struct sdhci_host *host = mmc_priv(mmc);
u16 ctrl;
@@ -2139,6 +2139,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
spin_unlock_irqrestore(&host->lock, flags);
return err;
}
+EXPORT_SYMBOL_GPL(sdhci_execute_tuning);
static int sdhci_select_drive_strength(struct mmc_card *card,
unsigned int max_dtr, int host_drv,
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index cd18b6f19c3b..95beadc66849 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -691,6 +691,7 @@ void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios);
+int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 4/10] MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers
From: Gregory CLEMENT @ 2016-10-31 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.86006f271b60cf7c0b4c5a51762a9dacca4c4718.1477911954.git-series.gregory.clement@free-electrons.com>
From: Ziji Hu <huziji@marvell.com>
Add maintainer entry for Marvell Xenon eMMC/SD/SDIO Host
Controller drivers.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c44795306342..1a5c4c30ea24 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7604,6 +7604,11 @@ M: Nicolas Pitre <nico@fluxnic.net>
S: Odd Fixes
F: drivers/mmc/host/mvsdio.*
+MARVELL XENON MMC/SD/SDIO HOST CONTROLLER DRIVER
+M: Ziji Hu <huziji@marvell.com>
+L: linux-mmc at vger.kernel.org
+S: Supported
+
MATROX FRAMEBUFFER DRIVER
L: linux-fbdev at vger.kernel.org
S: Orphan
--
git-series 0.8.10
^ permalink raw reply related
* [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Gregory CLEMENT @ 2016-10-31 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.86006f271b60cf7c0b4c5a51762a9dacca4c4718.1477911954.git-series.gregory.clement@free-electrons.com>
From: Ziji Hu <huziji@marvell.com>
Marvell Xenon SDHC can support eMMC/SD/SDIO.
Add Xenon-specific properties.
Also add properties for Xenon PHY setting.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 +++++++-
MAINTAINERS | 1 +-
2 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
new file mode 100644
index 000000000000..0d2d139494d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
@@ -0,0 +1,161 @@
+Marvell's Xenon SDHCI Controller device tree bindings
+This file documents differences between the core mmc properties
+described by mmc.txt and the properties used by the Xenon implementation.
+
+A single Xenon IP can support multiple slots.
+Each slot acts as an independent SDHC. It owns independent resources, such
+as register sets clock and PHY.
+Each slot should have an independent device tree node.
+
+Required Properties:
+- compatible: should be one of the following
+ - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SOC.
+ Must provide a second register area and marvell,pad-type.
+ - "marvell,xenon-sdhci": For controllers on all the SOCs, other than
+ Armada-3700.
+
+- clocks:
+ Array of clocks required for SDHCI.
+ Requires at least one for Xenon IP core.
+ Some SOCs require additional clock for AXI bus.
+
+- clock-names:
+ Array of names corresponding to clocks property.
+ The input clock for Xenon IP core should be named as "core".
+ The optional AXI clock should be named as "axi".
+
+- reg:
+ * For "marvell,xenon-sdhci", one register area for Xenon IP.
+
+ * For "marvell,armada-3700-sdhci", two register areas.
+ The first one for Xenon IP register. The second one for the Armada 3700 SOC
+ PHY PAD Voltage Control register.
+ Please follow the examples with compatible "marvell,armada-3700-sdhci"
+ in below.
+ Please also check property marvell,pad-type in below.
+
+Optional Properties:
+- marvell,xenon-slotno:
+ Indicate the corresponding bit index of current Xenon SDHC slot in
+ SDHC System Operation Control Register Bit[7:0].
+ Set/clear the corresponding bit to enable/disable current Xenon SDHC
+ slot.
+ If this property is not provided, Xenon IP should contain only one
+ slot.
+
+- marvell,xenon-phy-type:
+ Xenon support mutilple types of PHYs.
+ To select eMMC 5.1 PHY, set:
+ marvell,xenon-phy-type = "emmc 5.1 phy"
+ eMMC 5.1 PHY is the default choice if this property is not provided.
+ To select eMMC 5.0 PHY, set:
+ marvell,xenon-phy-type = "emmc 5.0 phy"
+ To select SDH PHY, set:
+ marvell,xenon-phy-type = "sdh phy"
+ Please note that eMMC PHY is a general PHY for eMMC/SD/SDIO, other than for
+ eMMC only.
+
+- marvell,xenon-phy-znr:
+ Set PHY ZNR value.
+ Only available for eMMC PHY 5.1 and eMMC PHY 5.0.
+ valid range = [0:0x1F].
+ ZNR is set as 0xF by default if this property is not provided.
+
+- marvell,xenon-phy-zpr:
+ Set PHY ZPR value.
+ Only available for eMMC PHY 5.1 and eMMC PHY 5.0.
+ valid range = [0:0x1F].
+ ZPR is set as 0xF by default if this property is not provided.
+
+- marvell,xenon-phy-nr-success-tun:
+ Set the number of required consecutive successful sampling points used to
+ identify a valid sampling window, in tuning process.
+ Valid range = [1:7]. Set as 0x4 by default if this property is not provided.
+
+- marvell,xenon-phy-tun-step-divider:
+ Set the divider for calculating TUN_STEP.
+ Set as 64 by default if this property is not provided.
+
+- marvell,xenon-phy-slow-mode:
+ Force PHY into slow mode.
+ Only available when bus frequency lower than 50MHz in SDR mde.
+ Disabled by default. Please do not enable it unless it is necessary.
+
+- marvell,xenon-mask-conflict-err:
+ Mask Conflict Error alert on some SOC. Disabled by default.
+
+- marvell,xenon-tun-count:
+ Xenon SDHC SOC usually doesn't provide re-tuning counter in
+ Capabilities Register 3 Bit[11:8].
+ This property provides the re-tuning counter.
+ If this property is not set, default re-tuning counter will
+ be set as 0x9 in driver.
+
+- marvell,pad-type:
+ Type of Armada 3700 SOC PHY PAD Voltiage Controller register.
+ Only valid when "marvell,armada-3700-sdhci" is selected.
+ Two types: "sd" and "fixed-1-8v".
+ If "sd" is slected, SOC PHY PAD is set as 3.3V at the beginning and is
+ switched to 1.8V when SD in UHS-I.
+ If "fixed-1-8v" is slected, SOC PHY PAD is fixed 1.8V, such as for eMMC.
+ Please follow the examples with compatible "marvell,armada-3700-sdhci"
+ in below.
+
+Example:
+- For eMMC slot:
+
+ sdhci at aa0000 {
+ compatible = "marvell,xenon-sdhci";
+ reg = <0xaa0000 0x1000>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>
+ clocks = <&emmc_clk>, <&axi_clock>;
+ clock-names = "core", "axi";
+ bus-width = <8>;
+ marvell,xenon-emmc;
+ marvell,xenon-slotno = <0>;
+ marvell,xenon-phy-type = "emmc 5.1 phy";
+ marvell,xenon-tun-count = <11>;
+ };
+
+- For SD/SDIO slot:
+
+ sdhci at ab0000 {
+ compatible = "marvell,xenon-sdhci";
+ reg = <0xab0000 0x1000>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>
+ vqmmc-supply = <&sd_regulator>;
+ clocks = <&sdclk>;
+ clock-names = "core";
+ bus-width = <4>;
+ marvell,xenon-tun-count = <9>;
+ };
+
+- For eMMC slot with compatible "marvell,armada-3700-sdhci":
+
+ sdhci at aa0000 {
+ compatible = "marvell,armada-3700-sdhci";
+ reg = <0xaa0000 0x1000>,
+ <phy_addr 0x4>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>
+ clocks = <&emmcclk>;
+ clock-names = "core";
+ bus-width = <8>;
+ marvell,xenon-emmc;
+
+ marvell,pad-type = "fixed-1-8v";
+ };
+
+- For SD/SDIO slot with compatible "marvell,armada-3700-sdhci":
+
+ sdhci at ab0000 {
+ compatible = "marvell,armada-3700-sdhci";
+ reg = <0xab0000 0x1000>,
+ <phy_addr 0x4>;
+ interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>
+ vqmmc-supply = <&sd_regulator>;
+ clocks = <&sdclk>;
+ clock-names = "core";
+ bus-width = <4>;
+
+ marvell,pad-type = "sd";
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 1a5c4c30ea24..850a0afb0c8d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7608,6 +7608,7 @@ MARVELL XENON MMC/SD/SDIO HOST CONTROLLER DRIVER
M: Ziji Hu <huziji@marvell.com>
L: linux-mmc at vger.kernel.org
S: Supported
+F: Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
MATROX FRAMEBUFFER DRIVER
L: linux-fbdev at vger.kernel.org
--
git-series 0.8.10
^ 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