* Re: [PATCH] ARM: dts: Add basic devices for AM3517-craneboard
From: Nishanth Menon @ 2014-01-29 13:30 UTC (permalink / raw)
To: Benoit Cousson, Tony Lindgren; +Cc: devicetree, linux-omap, linux-arm-kernel
In-Reply-To: <52DD522E.1070607@ti.com>
On 01/20/2014 10:43 AM, Nishanth Menon wrote:
> Benoit,
>
> On 12/18/2013 11:16 AM, Benoit Cousson wrote:
>> On 18/12/2013 18:02, Nishanth Menon wrote:
>>> On 12/18/2013 10:57 AM, Benoit Cousson wrote:
>>>> On 17/12/2013 20:45, Nishanth Menon wrote:
>>>>> On 12/09/2013 03:55 PM, Nishanth Menon wrote:
>>>>>> Craneboard is a hardware development platform based on the Sitara
>>>>>> AM3517 ARM Cortex - A8 microprocessor device - see [1] for more
>>>>>> details. Add basic devices for craneboard as replacement for the board
>>>>>> file scheduled for removal as part of device tree conversion
>>>>>>
>>>>>> [1] http://craneboard.org
>>>>>>
>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>> ---
>>>>>
>>>>> gentle ping.. had'nt seen a response on this patch. Could we queue
>>>>> this up for v3.14-rc1?
>>>>
>>>> Yep, it looks good to me.
>>> Thanks benoit.
>>>
>>>> But if you don't mind I'll start pushing my branch after Xmas :-).
>>>
>>> As long as Tony is ok with it, I have no issues either - will be great
>>> to have dt only boot in .14-rc1 though.
>>
>> Good point, it is already -rc4.
>>
>> OK, I'll just queued it and pushed it to for_3.14/dts.
>
> I dont see this in next-20140120 yet - wondering if Tony or you have
> plans for one of .14 rcs OR if this is queued for .15.
gentle ping yet again :(
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH REPOST] of: Add vendor prefix for Xen hypervisor
From: Ian Campbell @ 2014-01-29 13:01 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: xen-devel-GuqFBffKawuEi8DpZVb4nw, Ian Campbell, Rob Herring,
Pawel Moll, Mark Rutland, Kumar Gala, Stephen Warren,
devicetree-u79uwXL29TY76Z2rM5mHXA
I suppose vendors of virtual hardware ought to be listed here as well.
Signed-off-by: Ian Campbell <ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Acked-by: Stefano Stabellini <Stefano.Stabellini-mvvWK6WmYclDPfheJLI6IQ@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Acked-by: Stephen Warren <swarren@nvidia>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
v2: rebased for repost.
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 3f900cd..a30e3b7 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -90,4 +90,5 @@ via VIA Technologies, Inc.
winbond Winbond Electronics corp.
wlf Wolfson Microelectronics
wm Wondermedia Technologies, Inc.
+xen Xen Hypervisor
xlnx Xilinx
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Lorenzo Pieralisi @ 2014-01-29 12:42 UTC (permalink / raw)
To: Vincent Guittot
Cc: devicetree@vger.kernel.org, LAK, linux-pm@vger.kernel.org,
Dave P Martin, Mark Rutland, Sudeep Holla, Charles Garcia-Tobin,
Nicolas Pitre, Rob Herring, Peter De Schrijver,
grant.likely@linaro.org, Kumar Gala, Santosh Shilimkar,
Mark Hambleton, Hanjun Guo, Daniel Lezcano, Amit Kucheria,
Antti Miettinen, Stephen Boyd, Tomasz Figa, Kevin Hilman
In-Reply-To: <CAKfTPtAEekg_KHhLikJK=njC-b5F=MOmAmSP8P96+j_23-iu3Q@mail.gmail.com>
On Tue, Jan 28, 2014 at 08:24:54AM +0000, Vincent Guittot wrote:
> On 24 January 2014 18:58, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
[...]
> >> Please look below, i have modified the rest of your example accordingly
> >>
> >> >
> >> > }:
> >> >
> >> > and then
> >> >
> >> > state0 {
> >> > index = <2>;
> >> > compatible = "arm,cpu-power-state";
> >> > latency = <...>;
> >> > /*
> >> > * This means that when the state is entered, the power
> >> > * controller should use register index 0 and state 0,
> >> > * whose meaning is power controller specific. Since we
> >> > * know all components affected (for every component
> >> > * we declare its power domain(s) and states so we
> >> > * know what components are affected by the state entry.
> >> > * Given the cache node above and this phandle, the state
> >> > * implies that the cache is retained, register index == 0 state == 0
> >> > /*
> >> > power-domain =<&foo_power_controller 0 0>;
> >>
> >> for retention state we need to set the power domain in state 1
> >> power-domain =<&foo_power_controller 0 1>;
> >>
> >> > };
> >> >
> >> > state1 {
> >> > index = <3>;
> >> > compatible = "arm,cpu-power-state";
> >> > latency = <...>;
> >> > /*
> >> > * This means that when the state is entered, the power
> >> > * controller should use register index 0 and state 1,
> >> > * whose meaning is power controller specific. Since we
> >> > * know all components affected (for every component
> >> > * we declare its power domain(s) and states so we
> >> > * know what components are affected by the state entry.
> >> > * Given the cache node above and this phandle, the state
> >> > * implies that the cache is lost, register index == 0 state == 1
> >> > /*
> >> > power-domain =<&foo_power_controller 0 1>;
> >>
> >> for power down mode, we need to set thge power domain in state 2
> >> power-domain =<&foo_power_controller 0 2>;
> >
> > Ok, what I meant was not what you got, but your approach looks sensible
> > too. What I do not like is that the power-domain specifier is power
>
> sorry for the misconception of your example
>
> > controller specific (that was true even for my example). In theory
> > we can achieve something identical by forcing every component in a power
> > domain to specify the max C-state index that allows it to retain its
>
> I'm not sure that we should force a component to set an opaque (for
> the component) max c-state. The device should describe its power
> domain requirements and the correlation of the latter with the
> description of the c-state binding should be enough to deduct the max
> c-state.
I agree, that was an option, I just loathe the idea of implementing it.
Using power domain specifiers is ways cleaner IMHO, the only drawback is
that, it is up to the power domain documentation to define what a state
means in terms of save/restore and cache behavior. I think that makes
perfect sense, at least for me.
> > state (through a specific property). Same logic to your example applies.
> > Nice thing is that we do not change the power domain specifiers, bad thing
> > is that it adds two properties to each device (c-state index and
> > power-domain-specifier - but we can make it hierarchical so that device
> > nodes can inherit the maximum operating C-state by inheriting the value
> > from a parent node providing a common value).
> >
> > In my example the third parameter was just a number that the power
> > controller would decode (eg 0 = cache retained, 1 = cache lost)
> > according to its implementation, it was not a "state index". The
> > power controller would know what to do with eg a cache component (that
> > declares to be in that power domain) when a C-state with that power
> > domain specifier was entered.
> >
> > Not very different from what you are saying, let's get to the nub:
> >
> > - Either we define it in a platform specific way through the power
> > domain specifier
> > - Or we force a max-c-state-supported property for every device,
> > possibly hierarchical
>
> As explained above, adding a max-cstate property for a device that
> only know the power-domain is not a good thing IMHO.
I agree, if nobody complains that's the way I will define the bindings.
Thank you,
Lorenzo
^ permalink raw reply
* Re: [PATCH] phy-rcar-usb-gen2: add device tree support
From: Simon Horman @ 2014-01-29 12:35 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Valentine Barshak, Ben Dooks,
linux-kernel-81qHHgoATdFT9dQujB1mzip2UmYkHbXO,
linux-usb-u79uwXL29TY76Z2rM5mHXA, linux-sh-u79uwXL29TY76Z2rM5mHXA,
Magnus Damm, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <52E8F38F.9030609-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On Wed, Jan 29, 2014 at 04:26:55PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 29-01-2014 16:22, Simon Horman wrote:
>
> >>>>[snip]
>
> >>>>>>+static struct of_device_id rcar_gen2_usb_phy_ofmatch[] = {
> >>>>>>+ { .compatible = "renesas,usb-phy-r8a7790", },
> >>>>>>+ { .compatible = "renesas,rcar-gen2-usb-phy", },
>
> >>>>> Frankly speaking, I don't understand the need for the clearly
> >>>>>duplicate entries.
>
> >>>>Thanks, will look into remove it.
> >>>>Anyone else have any comments on this?
>
> >>>I would like you to leave it there.
>
> >>>As we know the r8a7790 is an R-Car Gen2 SoC. But there are other R-Car
> >>>Gen2 SoCs, such as the r8a7791, they it could plausibly make use of
> >>>rcar-gen2-usb-phy until the driver is updated with a usb-phy-r8a7791 entry.
>
> >> Why not just "update" the driver this way now, may I ask?
>
> >Because I don't believe that Ben has access to r8a7791 hardware
> >to test the change and thus it makes sense to handle it separately.
>
> I believe Valentine has already tested the driver with both SoCs.
Oh, great. Then I guess the compat string for r8a7791 can be added
as you suggest.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC v2 2/2] Documentation: arm: define DT C-states bindings
From: Lorenzo Pieralisi @ 2014-01-29 12:33 UTC (permalink / raw)
To: Dave Martin
Cc: Vincent Guittot, Mark Rutland, devicetree@vger.kernel.org,
Daniel Lezcano, Kevin Hilman, linux-pm@vger.kernel.org,
Peter De Schrijver, Nicolas Pitre, Stephen Boyd, Antti Miettinen,
Amit Kucheria, Tomasz Figa, Rob Herring, Santosh Shilimkar,
Hanjun Guo, Mark Hambleton, Sudeep Holla, grant.likely@linaro.org,
Kumar Gala, LAK, Charles Garcia-Tobin <Charles.Garcia-Tobin@
In-Reply-To: <20140127155924.GA2178@e103592.cambridge.arm.com>
On Mon, Jan 27, 2014 at 03:59:37PM +0000, Dave Martin wrote:
> On Fri, Jan 24, 2014 at 05:58:07PM +0000, Lorenzo Pieralisi wrote:
[...]
> > > > state0 {
> > > > index = <2>;
> > > > compatible = "arm,cpu-power-state";
> > > > latency = <...>;
> > > > /*
> > > > * This means that when the state is entered, the power
> > > > * controller should use register index 0 and state 0,
> > > > * whose meaning is power controller specific. Since we
> > > > * know all components affected (for every component
> > > > * we declare its power domain(s) and states so we
> > > > * know what components are affected by the state entry.
> > > > * Given the cache node above and this phandle, the state
> > > > * implies that the cache is retained, register index == 0 state == 0
> > > > /*
> > > > power-domain =<&foo_power_controller 0 0>;
> > >
> > > for retention state we need to set the power domain in state 1
> > > power-domain =<&foo_power_controller 0 1>;
>
> The name "power-domain" probably needs changing if the specifier contains
> state information too.
>
> Instead, we could call it "power-state" or similar.
>
>
> Key issues I see:
>
> 1) How to describe platforms where there is no "power controller" as such,
> just a bunch of clocks and regulators that Linux has to poke directly.
>
> 2) Two devices might have the same power controller (in terms of IP and
> revision), but integrated in different ways. So, maybe thinking of
> the referenced thing as a power controller is not correct. We can
> thing in terms of referring to individual power domains, or maybe
> to a "power model" for the SoC.
The example was misleading. There is no link to a power controller as
such, the phandle is to a power domain, which fits with what you are
saying, basically the C-state does not care about how the power domain
is implemented, it just defines that that specific power domain is
affected. I am not sure we should change the naming either, a C-state
defines a power-domain specifier, which implies a certain behaviour
for a power domain. It is platform specific, so for certain platforms
the cells represent a state for others they do not.
> The power domain or model becomes a container for power (domains and)
> states, and refers to the IP blocks (power controllers, regulators,
> clocks, clamps, whatever) required to implement it.
>
> This change of abstraction might map more naturally onto "bunch
> of clocks and regulators" situations: the power model or domain
> binding can make symbolic references to clocks and regulators etc.,
> so that the binding becomes less dependent on the exact content of
> the rest of the DT.
Exactly, I agree, the complexity is in the power-domain (how states are
handled, what components should be programmed, etc) the C-state just
defines what power-domain it affects, with power domain specifier cells
providing additional, power domain specific, semantics (ie retention vs.
shutdown).
> 3) We need to be very clear that the power state specifier needs to be
> defined in terms of the actual hardware effects in the relevant SoC-
> specific binding -- at the "what" level, rather than "how".
>
> There's a fair chance of people getting lazy: they'll just stuff
> indices in the DT which map to random LUTs in the Linux driver. In
> that case, the DT would be describing the Linux driver, not the
> hardware -- that's not what we want.
>
> Delegating the job of defining power states to the SoC documentation
> seems acceptable, though.
I agree, and I think we are pretty close to a general agreement on this
specific subject.
Thank you,
Lorenzo
^ permalink raw reply
* Re: [PATCH] phy-rcar-usb-gen2: add device tree support
From: Sergei Shtylyov @ 2014-01-29 12:26 UTC (permalink / raw)
To: Simon Horman, Valentine Barshak
Cc: Ben Dooks, linux-kernel-81qHHgoATdFT9dQujB1mzip2UmYkHbXO,
linux-usb-u79uwXL29TY76Z2rM5mHXA, linux-sh-u79uwXL29TY76Z2rM5mHXA,
Magnus Damm, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140129122202.GB26253-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Hello.
On 29-01-2014 16:22, Simon Horman wrote:
>>>> [snip]
>>>>>> +static struct of_device_id rcar_gen2_usb_phy_ofmatch[] = {
>>>>>> + { .compatible = "renesas,usb-phy-r8a7790", },
>>>>>> + { .compatible = "renesas,rcar-gen2-usb-phy", },
>>>>> Frankly speaking, I don't understand the need for the clearly
>>>>> duplicate entries.
>>>> Thanks, will look into remove it.
>>>> Anyone else have any comments on this?
>>> I would like you to leave it there.
>>> As we know the r8a7790 is an R-Car Gen2 SoC. But there are other R-Car
>>> Gen2 SoCs, such as the r8a7791, they it could plausibly make use of
>>> rcar-gen2-usb-phy until the driver is updated with a usb-phy-r8a7791 entry.
>> Why not just "update" the driver this way now, may I ask?
> Because I don't believe that Ben has access to r8a7791 hardware
> to test the change and thus it makes sense to handle it separately.
I believe Valentine has already tested the driver with both SoCs.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Mark Brown @ 2014-01-29 12:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mike Turquette, Emilio Lopez, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w,
sunny-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
shuge-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
zhuzhenhua-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf
In-Reply-To: <1390993850-9054-4-git-send-email-maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
On Wed, Jan 29, 2014 at 12:10:48PM +0100, Maxime Ripard wrote:
> +config SPI_SUN6I
> + tristate "Allwinner A31 SPI controller"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + select PM_RUNTIME
> + help
> + This enables using the SPI controller on the Allwinner A31 SoCs.
> +
A select of PM_RUNTIME is both surprising and odd - why is that there?
The usual idiom is that the device starts out powered up (flagged using
pm_runtime_set_active()) and then runtime PM then suspends it when it's
compiled in. That way if for some reason people want to avoid runtime
PM they can still use the device.
> +static void sun6i_spi_set_cs(struct spi_device *spi, bool enable)
> +{
> + struct sun6i_spi *sspi = spi_master_get_devdata(spi->master);
> + u32 reg;
> +
> + if (!enable)
> + return;
> +
> + reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
> + reg &= ~SUN6I_TFR_CTL_CS_MASK;
> + reg |= SUN6I_TFR_CTL_CS(spi->chip_select);
> + sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
> +}
The !enable means that it'll only ever be able to go one way. Also note
that the documentation was clarified here to make the enable flag be the
absolute logic level, not if chip select was asserted.
> + timeout = wait_for_completion_timeout(&sspi->done,
> + msecs_to_jiffies(1000));
> + if (!timeout) {
> + ret = -ETIMEDOUT;
> + goto out;
> + }
> +
> + sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
This means we can only transfer a single FIFO of data? I didn't see a
check on the transfer length.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] phy-rcar-usb-gen2: add device tree support
From: Simon Horman @ 2014-01-29 12:22 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Ben Dooks, linux-kernel, linux-usb, linux-sh, Magnus Damm,
devicetree
In-Reply-To: <52E8DAF6.5090105@cogentembedded.com>
On Wed, Jan 29, 2014 at 02:41:58PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 29-01-2014 10:22, Simon Horman wrote:
>
> >>[snip]
>
> >>>>+static struct of_device_id rcar_gen2_usb_phy_ofmatch[] = {
> >>>>+ { .compatible = "renesas,usb-phy-r8a7790", },
> >>>>+ { .compatible = "renesas,rcar-gen2-usb-phy", },
>
> >>> Frankly speaking, I don't understand the need for the clearly
> >>>duplicate entries.
>
> >>Thanks, will look into remove it.
> >>Anyone else have any comments on this?
>
> >I would like you to leave it there.
>
> >As we know the r8a7790 is an R-Car Gen2 SoC. But there are other R-Car
> >Gen2 SoCs, such as the r8a7791, they it could plausibly make use of
> >rcar-gen2-usb-phy until the driver is updated with a usb-phy-r8a7791 entry.
>
> Why not just "update" the driver this way now, may I ask?
Because I don't believe that Ben has access to r8a7791 hardware
to test the change and thus it makes sense to handle it separately.
^ permalink raw reply
* Re: [PATCH 1/8] pci-rcar-gen2: add of match table
From: Simon Horman @ 2014-01-29 12:20 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ben Dooks, Sergei Shtylyov, linux-kernel, Bjorn Helgaas,
linux-pci, Linux-sh list, devicetree@vger.kernel.org
In-Reply-To: <CAMuHMdVSWM5wYeA1OarFEv_yYCJR1FSm5Ercjyc5qtcVameSsw@mail.gmail.com>
On Wed, Jan 29, 2014 at 11:06:42AM +0100, Geert Uytterhoeven wrote:
> On Wed, Jan 29, 2014 at 7:17 AM, Simon Horman <horms@verge.net.au> wrote:
> >> >>+static struct of_device_id rcar_pci_of_match[] = {
> >> >>+ { .compatible = "renesas,pci-r8a7790", },
> >> >
> >> > Why only H2 SoC, if the driver is for both Gen2 SoCs?
> >>
> >> I can add a "renesas,pci-rcar-gen2" as a fallback match however
> >> I've not got anything other than an r8a7790 to test on. Also the
> >> compatible properties are preferably named after the soc.
> >
> > I'm not sure what the "best practice" is here but I propose that
> > you add both "renesas,pci-rcar-gen2" and "renesas,pci-r8a7790" now.
>
> To the driver or to the '90 DTS?
>
> If the DTS says
>
> compatible = "renesas,pci-r8a7790", "renesas,pci-rcar-gen2"
>
> then the driver can just live with "renesas,pci-rcar-gen2" for now.
>
> > And that "renesas,pci-r8a7791" can be added once the code has been
> > integrated and tested on that platform.
>
> And later we can add
>
> compatible = "renesas,pci-r8a7791", "renesas,pci-rcar-gen2"
>
> to the '91 DTS if it turns out to be compatible.
>
> If the '91 turns out to be incompatible, or partially compatible, the driver
> can be updated later to handle both "renesas,pci-r8a7790" and
> "renesas,pci-r8a7791" and differentiate between them.
>
> (That's what I was instructed to do with SPI ;-)
Thanks, that is more or less how I thought things work :)
^ permalink raw reply
* [PATCH v2 5/5] ARM: sunxi: Enable A31 SPI and SID in the defconfig
From: Maxime Ripard @ 2014-01-29 11:10 UTC (permalink / raw)
To: Mark Brown, Mike Turquette, Emilio Lopez
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w,
sunny-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
shuge-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
zhuzhenhua-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf, Maxime Ripard
In-Reply-To: <1390993850-9054-1-git-send-email-maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/configs/sunxi_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3e2259b..b5df4a5 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -24,6 +24,7 @@ CONFIG_IP_PNP_BOOTP=y
# CONFIG_WIRELESS is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_EEPROM_SUNXI_SID=y
CONFIG_NETDEVICES=y
CONFIG_SUN4I_EMAC=y
# CONFIG_NET_CADENCE is not set
@@ -48,6 +49,8 @@ CONFIG_I2C=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MV64XXX=y
+CONFIG_SPI=y
+CONFIG_SPI_SUN6I=y
CONFIG_GPIO_SYSFS=y
# CONFIG_HWMON is not set
CONFIG_WATCHDOG=y
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 4/5] ARM: sun6i: dt: Add SPI controllers to the A31 DTSI
From: Maxime Ripard @ 2014-01-29 11:10 UTC (permalink / raw)
To: Mark Brown, Mike Turquette, Emilio Lopez
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w,
sunny-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
shuge-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
zhuzhenhua-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf, Maxime Ripard
In-Reply-To: <1390993850-9054-1-git-send-email-maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The A31 has 4 SPI controllers. Add them in the DTSI.
Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 0eea325..57af66f 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -340,6 +340,46 @@
status = "disabled";
};
+ spi0: spi@01c68000 {
+ compatible = "allwinner,sun6i-a31-spi";
+ reg = <0x01c68000 0x1000>;
+ interrupts = <0 65 4>;
+ clocks = <&ahb1_gates 20>, <&spi0_clk>;
+ clock-names = "ahb", "mod";
+ resets = <&ahb1_rst 20>;
+ status = "disabled";
+ };
+
+ spi1: spi@01c69000 {
+ compatible = "allwinner,sun6i-a31-spi";
+ reg = <0x01c69000 0x1000>;
+ interrupts = <0 66 4>;
+ clocks = <&ahb1_gates 21>, <&spi1_clk>;
+ clock-names = "ahb", "mod";
+ resets = <&ahb1_rst 21>;
+ status = "disabled";
+ };
+
+ spi2: spi@01c6a000 {
+ compatible = "allwinner,sun6i-a31-spi";
+ reg = <0x01c6a000 0x1000>;
+ interrupts = <0 67 4>;
+ clocks = <&ahb1_gates 22>, <&spi2_clk>;
+ clock-names = "ahb", "mod";
+ resets = <&ahb1_rst 22>;
+ status = "disabled";
+ };
+
+ spi3: spi@01c6b000 {
+ compatible = "allwinner,sun6i-a31-spi";
+ reg = <0x01c6b000 0x1000>;
+ interrupts = <0 68 4>;
+ clocks = <&ahb1_gates 23>, <&spi3_clk>;
+ clock-names = "ahb", "mod";
+ resets = <&ahb1_rst 23>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@01c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Maxime Ripard @ 2014-01-29 11:10 UTC (permalink / raw)
To: Mark Brown, Mike Turquette, Emilio Lopez
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w,
sunny-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
shuge-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
zhuzhenhua-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf, Maxime Ripard
In-Reply-To: <1390993850-9054-1-git-send-email-maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Allwinner A31 has a new SPI controller IP compared to the older Allwinner
SoCs.
It supports DMA, but the driver only does PIO for now, and DMA will be
supported eventually.
Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
.../devicetree/bindings/spi/spi-sun6i.txt | 24 ++
drivers/spi/Kconfig | 7 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-sun6i.c | 478 +++++++++++++++++++++
4 files changed, 510 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-sun6i.txt
create mode 100644 drivers/spi/spi-sun6i.c
diff --git a/Documentation/devicetree/bindings/spi/spi-sun6i.txt b/Documentation/devicetree/bindings/spi/spi-sun6i.txt
new file mode 100644
index 0000000..21de73d
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-sun6i.txt
@@ -0,0 +1,24 @@
+Allwinner A31 SPI controller
+
+Required properties:
+- compatible: Should be "allwinner,sun6i-a31-spi".
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks: phandle to the clocks feeding the SPI controller. Two are
+ needed:
+ - "ahb": the gated AHB parent clock
+ - "mod": the parent module clock
+- clock-names: Must contain the clock names described just above
+- resets: phandle to the reset controller asserting this device in
+ reset
+
+Example:
+
+spi1: spi@01c69000 {
+ compatible = "allwinner,sun6i-a31-spi";
+ reg = <0x01c69000 0x1000>;
+ interrupts = <0 66 4>;
+ clocks = <&ahb1_gates 21>, <&spi1_clk>;
+ clock-names = "ahb", "mod";
+ resets = <&ahb1_rst 21>;
+};
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index eb1f1ef..004e3b0 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -438,6 +438,13 @@ config SPI_SIRF
help
SPI driver for CSR SiRFprimaII SoCs
+config SPI_SUN6I
+ tristate "Allwinner A31 SPI controller"
+ depends on ARCH_SUNXI || COMPILE_TEST
+ select PM_RUNTIME
+ help
+ This enables using the SPI controller on the Allwinner A31 SoCs.
+
config SPI_MXS
tristate "Freescale MXS SPI controller"
depends on ARCH_MXS
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index ab8d864..658ec64 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_SPI_SH_HSPI) += spi-sh-hspi.o
obj-$(CONFIG_SPI_SH_MSIOF) += spi-sh-msiof.o
obj-$(CONFIG_SPI_SH_SCI) += spi-sh-sci.o
obj-$(CONFIG_SPI_SIRF) += spi-sirf.o
+obj-$(CONFIG_SPI_SUN6I) += spi-sun6i.o
obj-$(CONFIG_SPI_TEGRA114) += spi-tegra114.o
obj-$(CONFIG_SPI_TEGRA20_SFLASH) += spi-tegra20-sflash.o
obj-$(CONFIG_SPI_TEGRA20_SLINK) += spi-tegra20-slink.o
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
new file mode 100644
index 0000000..32f3fc7
--- /dev/null
+++ b/drivers/spi/spi-sun6i.c
@@ -0,0 +1,478 @@
+/*
+ * Copyright (C) 2012 - 2014 Allwinner Tech
+ * Pan Nan <pannan-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf@public.gmane.org>
+ *
+ * Copyright (C) 2014 Maxime Ripard
+ * Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/reset.h>
+#include <linux/workqueue.h>
+
+#include <linux/spi/spi.h>
+
+#define SUN6I_FIFO_DEPTH 128
+
+#define SUN6I_GBL_CTL_REG 0x04
+#define SUN6I_GBL_CTL_BUS_ENABLE BIT(0)
+#define SUN6I_GBL_CTL_MASTER BIT(1)
+#define SUN6I_GBL_CTL_TP BIT(7)
+#define SUN6I_GBL_CTL_RST BIT(31)
+
+#define SUN6I_TFR_CTL_REG 0x08
+#define SUN6I_TFR_CTL_CPHA BIT(0)
+#define SUN6I_TFR_CTL_CPOL BIT(1)
+#define SUN6I_TFR_CTL_SPOL BIT(2)
+#define SUN6I_TFR_CTL_CS_MASK 0x3
+#define SUN6I_TFR_CTL_CS(cs) (((cs) & SUN6I_TFR_CTL_CS_MASK) << 4)
+#define SUN6I_TFR_CTL_DHB BIT(8)
+#define SUN6I_TFR_CTL_FBS BIT(12)
+#define SUN6I_TFR_CTL_XCH BIT(31)
+
+#define SUN6I_INT_CTL_REG 0x10
+#define SUN6I_INT_CTL_RF_OVF BIT(8)
+#define SUN6I_INT_CTL_TC BIT(12)
+
+#define SUN6I_INT_STA_REG 0x14
+
+#define SUN6I_FIFO_CTL_REG 0x18
+#define SUN6I_FIFO_CTL_RF_RST BIT(15)
+#define SUN6I_FIFO_CTL_TF_RST BIT(31)
+
+#define SUN6I_FIFO_STA_REG 0x1c
+#define SUN6I_FIFO_STA_RF_CNT_MASK 0x7f
+#define SUN6I_FIFO_STA_RF_CNT_BITS 0
+#define SUN6I_FIFO_STA_TF_CNT_MASK 0x7f
+#define SUN6I_FIFO_STA_TF_CNT_BITS 16
+
+#define SUN6I_CLK_CTL_REG 0x24
+#define SUN6I_CLK_CTL_CDR2_MASK 0xff
+#define SUN6I_CLK_CTL_CDR2(div) (((div) & SUN6I_CLK_CTL_CDR2_MASK) << 0)
+#define SUN6I_CLK_CTL_CDR1_MASK 0xf
+#define SUN6I_CLK_CTL_CDR1(div) (((div) & SUN6I_CLK_CTL_CDR1_MASK) << 8)
+#define SUN6I_CLK_CTL_DRS BIT(12)
+
+#define SUN6I_BURST_CNT_REG 0x30
+#define SUN6I_BURST_CNT(cnt) ((cnt) & 0xffffff)
+
+#define SUN6I_XMIT_CNT_REG 0x34
+#define SUN6I_XMIT_CNT(cnt) ((cnt) & 0xffffff)
+
+#define SUN6I_BURST_CTL_CNT_REG 0x38
+#define SUN6I_BURST_CTL_CNT_STC(cnt) ((cnt) & 0xffffff)
+
+#define SUN6I_TXDATA_REG 0x200
+#define SUN6I_RXDATA_REG 0x300
+
+struct sun6i_spi {
+ struct spi_master *master;
+ void __iomem *base_addr;
+ struct clk *hclk;
+ struct clk *mclk;
+ struct reset_control *rstc;
+
+ struct completion done;
+
+ const u8 *tx_buf;
+ u8 *rx_buf;
+ int len;
+};
+
+static inline u32 sun6i_spi_read(struct sun6i_spi *sspi, u32 reg)
+{
+ return readl(sspi->base_addr + reg);
+}
+
+static inline void sun6i_spi_write(struct sun6i_spi *sspi, u32 reg, u32 value)
+{
+ writel(value, sspi->base_addr + reg);
+}
+
+static inline void sun6i_spi_drain_fifo(struct sun6i_spi *sspi, int len)
+{
+ u32 reg, cnt;
+ u8 byte;
+
+ /* See how much data is available */
+ reg = sun6i_spi_read(sspi, SUN6I_FIFO_STA_REG);
+ reg &= SUN6I_FIFO_STA_RF_CNT_MASK;
+ cnt = reg >> SUN6I_FIFO_STA_RF_CNT_BITS;
+
+ if (len > cnt)
+ len = cnt;
+
+ while (len--) {
+ byte = readb(sspi->base_addr + SUN6I_RXDATA_REG);
+ if (sspi->rx_buf)
+ *sspi->rx_buf++ = byte;
+ }
+}
+
+static inline void sun6i_spi_fill_fifo(struct sun6i_spi *sspi, int len)
+{
+ u8 byte;
+
+ if (len > sspi->len)
+ len = sspi->len;
+
+ while (len--) {
+ byte = sspi->tx_buf ? *sspi->tx_buf++ : 0;
+ writeb(byte, sspi->base_addr + SUN6I_TXDATA_REG);
+ sspi->len--;
+ }
+}
+
+static void sun6i_spi_set_cs(struct spi_device *spi, bool enable)
+{
+ struct sun6i_spi *sspi = spi_master_get_devdata(spi->master);
+ u32 reg;
+
+ if (!enable)
+ return;
+
+ reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+ reg &= ~SUN6I_TFR_CTL_CS_MASK;
+ reg |= SUN6I_TFR_CTL_CS(spi->chip_select);
+ sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
+}
+
+
+static int sun6i_spi_transfer_one(struct spi_master *master,
+ struct spi_device *spi,
+ struct spi_transfer *tfr)
+{
+ struct sun6i_spi *sspi = spi_master_get_devdata(master);
+ unsigned int mclk_rate, div, timeout;
+ unsigned int tx_len = 0;
+ int ret = 0;
+ u32 reg;
+
+ /* We don't support transfer larger than the FIFO */
+ if (tfr->len > SUN6I_FIFO_DEPTH)
+ return -EINVAL;
+
+ reinit_completion(&sspi->done);
+ sspi->tx_buf = tfr->tx_buf;
+ sspi->rx_buf = tfr->rx_buf;
+ sspi->len = tfr->len;
+
+ /* Clear pending interrupts */
+ sun6i_spi_write(sspi, SUN6I_INT_STA_REG, ~0);
+
+ /* Reset FIFO */
+ sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG,
+ SUN6I_FIFO_CTL_RF_RST | SUN6I_FIFO_CTL_TF_RST);
+
+ /*
+ * Setup the transfer control register: Chip Select,
+ * polarities, etc.
+ */
+ reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+
+ if (spi->mode & SPI_CPOL)
+ reg |= SUN6I_TFR_CTL_CPOL;
+ else
+ reg &= ~SUN6I_TFR_CTL_CPOL;
+
+ if (spi->mode & SPI_CPHA)
+ reg |= SUN6I_TFR_CTL_CPHA;
+ else
+ reg &= ~SUN6I_TFR_CTL_CPHA;
+
+ if (spi->mode & SPI_CS_HIGH)
+ reg &= ~SUN6I_TFR_CTL_SPOL;
+ else
+ reg |= SUN6I_TFR_CTL_SPOL;
+
+ if (spi->mode & SPI_LSB_FIRST)
+ reg |= SUN6I_TFR_CTL_FBS;
+ else
+ reg &= ~SUN6I_TFR_CTL_FBS;
+
+ /*
+ * If it's a TX only transfer, we don't want to fill the RX
+ * FIFO with bogus data
+ */
+ if (sspi->rx_buf)
+ reg &= ~SUN6I_TFR_CTL_DHB;
+ else
+ reg |= SUN6I_TFR_CTL_DHB;
+
+ sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
+
+ /* Ensure that we have a parent clock fast enough */
+ mclk_rate = clk_get_rate(sspi->mclk);
+ if (mclk_rate < (2 * spi->max_speed_hz)) {
+ clk_set_rate(sspi->mclk, 2 * spi->max_speed_hz);
+ mclk_rate = clk_get_rate(sspi->mclk);
+ }
+
+ /*
+ * Setup clock divider.
+ *
+ * We have two choices there. Either we can use the clock
+ * divide rate 1, which is calculated thanks to this formula:
+ * SPI_CLK = MOD_CLK / (2 ^ cdr)
+ * Or we can use CDR2, which is calculated with the formula:
+ * SPI_CLK = MOD_CLK / (2 * (cdr + 1))
+ * Wether we use the former or the latter is set through the
+ * DRS bit.
+ *
+ * First try CDR2, and if we can't reach the expected
+ * frequency, fall back to CDR1.
+ */
+ div = mclk_rate / (2 * spi->max_speed_hz);
+ if (div <= (SUN6I_CLK_CTL_CDR2_MASK + 1)) {
+ if (div > 0)
+ div--;
+
+ reg = SUN6I_CLK_CTL_CDR2(div) | SUN6I_CLK_CTL_DRS;
+ } else {
+ div = ilog2(mclk_rate) - ilog2(spi->max_speed_hz);
+ reg = SUN6I_CLK_CTL_CDR1(div);
+ }
+
+ sun6i_spi_write(sspi, SUN6I_CLK_CTL_REG, reg);
+
+ /* Setup the transfer now... */
+ if (sspi->tx_buf)
+ tx_len = tfr->len;
+
+ /* Setup the counters */
+ sun6i_spi_write(sspi, SUN6I_BURST_CNT_REG, SUN6I_BURST_CNT(tfr->len));
+ sun6i_spi_write(sspi, SUN6I_XMIT_CNT_REG, SUN6I_XMIT_CNT(tx_len));
+ sun6i_spi_write(sspi, SUN6I_BURST_CTL_CNT_REG,
+ SUN6I_BURST_CTL_CNT_STC(tx_len));
+
+ /* Fill the TX FIFO */
+ sun6i_spi_fill_fifo(sspi, SUN6I_FIFO_DEPTH);
+
+ /* Enable the interrupts */
+ sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, SUN6I_INT_CTL_TC);
+
+ /* Start the transfer */
+ reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+ sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
+
+ timeout = wait_for_completion_timeout(&sspi->done,
+ msecs_to_jiffies(1000));
+ if (!timeout) {
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
+ sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
+
+out:
+ sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, 0);
+
+ return ret;
+}
+
+static irqreturn_t sun6i_spi_handler(int irq, void *dev_id)
+{
+ struct sun6i_spi *sspi = dev_id;
+ u32 status = sun6i_spi_read(sspi, SUN6I_INT_STA_REG);
+
+ /* Transfer complete */
+ if (status & SUN6I_INT_CTL_TC) {
+ sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_TC);
+ complete(&sspi->done);
+ return IRQ_HANDLED;
+ }
+
+ return IRQ_NONE;
+}
+
+static int sun6i_spi_runtime_resume(struct device *dev)
+{
+ struct spi_master *master = dev_get_drvdata(dev);
+ struct sun6i_spi *sspi = spi_master_get_devdata(master);
+ int ret;
+
+ ret = clk_prepare_enable(sspi->hclk);
+ if (ret) {
+ dev_err(dev, "Couldn't enable clock 'ahb spi'\n");
+ goto out;
+ }
+
+ ret = clk_prepare_enable(sspi->mclk);
+ if (ret) {
+ dev_err(dev, "Couldn't enable clock 'ahb spi'\n");
+ goto err;
+ }
+
+ ret = reset_control_deassert(sspi->rstc);
+ if (ret) {
+ dev_err(dev, "Couldn't deassert the device from reset\n");
+ goto err2;
+ }
+
+ sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG,
+ SUN6I_GBL_CTL_BUS_ENABLE | SUN6I_GBL_CTL_MASTER | SUN6I_GBL_CTL_TP);
+
+ return 0;
+
+err2:
+ clk_disable_unprepare(sspi->mclk);
+err:
+ clk_disable_unprepare(sspi->hclk);
+out:
+ return ret;
+}
+
+static int sun6i_spi_runtime_suspend(struct device *dev)
+{
+ struct spi_master *master = dev_get_drvdata(dev);
+ struct sun6i_spi *sspi = spi_master_get_devdata(master);
+
+ reset_control_assert(sspi->rstc);
+ clk_disable_unprepare(sspi->mclk);
+ clk_disable_unprepare(sspi->hclk);
+
+ return 0;
+}
+
+static int sun6i_spi_probe(struct platform_device *pdev)
+{
+ struct spi_master *master;
+ struct sun6i_spi *sspi;
+ struct resource *res;
+ int ret = 0, irq;
+
+ master = spi_alloc_master(&pdev->dev, sizeof(struct sun6i_spi));
+ if (!master) {
+ dev_err(&pdev->dev, "Unable to allocate SPI Master\n");
+ return -ENOMEM;
+ }
+
+ platform_set_drvdata(pdev, master);
+ sspi = spi_master_get_devdata(master);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ sspi->base_addr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(sspi->base_addr)) {
+ ret = PTR_ERR(sspi->base_addr);
+ goto err;
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "No spi IRQ specified\n");
+ ret = -ENXIO;
+ goto err;
+ }
+
+ ret = devm_request_irq(&pdev->dev, irq, sun6i_spi_handler,
+ 0, "sun6i-spi", sspi);
+ if (ret) {
+ dev_err(&pdev->dev, "Cannot request IRQ\n");
+ goto err;
+ }
+
+ sspi->master = master;
+ master->bus_num = -1;
+ master->set_cs = sun6i_spi_set_cs;
+ master->transfer_one = sun6i_spi_transfer_one;
+ master->num_chipselect = 4;
+ master->mode_bits = SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LSB_FIRST;
+ master->dev.of_node = pdev->dev.of_node;
+ master->auto_runtime_pm = true;
+
+ /* Setup clocks */
+ sspi->hclk = devm_clk_get(&pdev->dev, "ahb");
+ if (IS_ERR(sspi->hclk)) {
+ dev_err(&pdev->dev, "Unable to acquire AHB clock\n");
+ ret = PTR_ERR(sspi->hclk);
+ goto err;
+ }
+
+ sspi->mclk = devm_clk_get(&pdev->dev, "mod");
+ if (IS_ERR(sspi->mclk)) {
+ dev_err(&pdev->dev, "Unable to acquire module clock\n");
+ ret = PTR_ERR(sspi->mclk);
+ goto err2;
+ }
+
+ init_completion(&sspi->done);
+
+ sspi->rstc = devm_reset_control_get(&pdev->dev, NULL);
+ if (IS_ERR(sspi->rstc)) {
+ dev_err(&pdev->dev, "Couldn't get reset controller\n");
+ ret = PTR_ERR(sspi->rstc);
+ goto err3;
+ }
+
+ pm_runtime_enable(&pdev->dev);
+
+ ret = spi_register_master(master);
+ if (ret) {
+ dev_err(&pdev->dev, "cannot register SPI master\n");
+ goto err4;
+ }
+
+ return 0;
+
+err4:
+ pm_runtime_disable(&pdev->dev);
+err3:
+ clk_disable_unprepare(sspi->mclk);
+err2:
+ clk_disable_unprepare(sspi->hclk);
+err:
+ spi_master_put(master);
+
+ return ret;
+}
+
+static int sun6i_spi_remove(struct platform_device *pdev)
+{
+ struct spi_master *master = spi_master_get(platform_get_drvdata(pdev));
+
+ spi_unregister_master(master);
+ pm_runtime_disable(&pdev->dev);
+ spi_master_put(master);
+
+ return 0;
+}
+
+static const struct of_device_id sun6i_spi_match[] = {
+ { .compatible = "allwinner,sun6i-a31-spi", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, sun6i_spi_match);
+
+static const struct dev_pm_ops sun6i_spi_pm_ops = {
+ .runtime_resume = sun6i_spi_runtime_resume,
+ .runtime_suspend = sun6i_spi_runtime_suspend,
+};
+
+static struct platform_driver sun6i_spi_driver = {
+ .probe = sun6i_spi_probe,
+ .remove = sun6i_spi_remove,
+ .driver = {
+ .name = "sun6i-spi",
+ .owner = THIS_MODULE,
+ .of_match_table = sun6i_spi_match,
+ .pm = &sun6i_spi_pm_ops,
+ },
+};
+module_platform_driver(sun6i_spi_driver);
+
+MODULE_AUTHOR("Pan Nan <pannan-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf@public.gmane.org>");
+MODULE_AUTHOR("Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>");
+MODULE_DESCRIPTION("Allwinner A31 SPI controller driver");
+MODULE_LICENSE("GPL");
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 2/5] ARM: sun6i: dt: Add PLL6 and SPI module clocks
From: Maxime Ripard @ 2014-01-29 11:10 UTC (permalink / raw)
To: Mark Brown, Mike Turquette, Emilio Lopez
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w,
sunny-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
shuge-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
zhuzhenhua-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf, Maxime Ripard
In-Reply-To: <1390993850-9054-1-git-send-email-maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The module clocks in the A31 are still compatible with the A10 one. Add the SPI
module clocks and the PLL6 in the device tree to allow their use by the SPI
controllers.
Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 46 ++++++++++++++++++++++++++++++++--------
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 5256ad9..0eea325 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -73,16 +73,12 @@
clocks = <&osc24M>;
};
- /*
- * This is a dummy clock, to be used as placeholder on
- * other mux clocks when a specific parent clock is not
- * yet implemented. It should be dropped when the driver
- * is complete.
- */
- pll6: pll6 {
+ pll6: clk@01c20028 {
#clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <0>;
+ compatible = "allwinner,sun6i-a31-pll6-clk";
+ reg = <0x01c20028 0x4>;
+ clocks = <&osc24M>;
+ clock-output-names = "pll6";
};
cpu: cpu@01c20050 {
@@ -182,6 +178,38 @@
"apb2_uart1", "apb2_uart2", "apb2_uart3",
"apb2_uart4", "apb2_uart5";
};
+
+ spi0_clk: clk@01c200a0 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun4i-mod0-clk";
+ reg = <0x01c200a0 0x4>;
+ clocks = <&osc24M>, <&pll6>;
+ clock-output-names = "spi0";
+ };
+
+ spi1_clk: clk@01c200a4 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun4i-mod0-clk";
+ reg = <0x01c200a4 0x4>;
+ clocks = <&osc24M>, <&pll6>;
+ clock-output-names = "spi1";
+ };
+
+ spi2_clk: clk@01c200a8 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun4i-mod0-clk";
+ reg = <0x01c200a8 0x4>;
+ clocks = <&osc24M>, <&pll6>;
+ clock-output-names = "spi2";
+ };
+
+ spi3_clk: clk@01c200ac {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun4i-mod0-clk";
+ reg = <0x01c200ac 0x4>;
+ clocks = <&osc24M>, <&pll6>;
+ clock-output-names = "spi3";
+ };
};
soc@01c00000 {
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 1/5] clk: sunxi: Add support for PLL6 on the A31
From: Maxime Ripard @ 2014-01-29 11:10 UTC (permalink / raw)
To: Mark Brown, Mike Turquette, Emilio Lopez
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w,
sunny-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
shuge-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
zhuzhenhua-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf, Maxime Ripard
In-Reply-To: <1390993850-9054-1-git-send-email-maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The A31 has a slightly different PLL6 clock. Add support for this new clock in
our driver.
Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/clk-sunxi.c | 45 +++++++++++++++++++++++
2 files changed, 46 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index c2cb762..954845c 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -11,6 +11,7 @@ Required properties:
"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
"allwinner,sun4i-pll5-clk" - for the PLL5 clock
"allwinner,sun4i-pll6-clk" - for the PLL6 clock
+ "allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
"allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
"allwinner,sun4i-axi-clk" - for the AXI clock
"allwinner,sun4i-axi-gates-clk" - for the AXI gates
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 659e4ea..990ad5d 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -249,7 +249,38 @@ static void sun4i_get_pll5_factors(u32 *freq, u32 parent_rate,
*n = DIV_ROUND_UP(div, (*k+1));
}
+/**
+ * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6
+ * PLL6 rate is calculated as follows
+ * rate = parent_rate * n * (k + 1) / 2
+ * parent_rate is always 24Mhz
+ */
+
+static void sun6i_a31_get_pll6_factors(u32 *freq, u32 parent_rate,
+ u8 *n, u8 *k, u8 *m, u8 *p)
+{
+ u8 div;
+
+ /*
+ * We always have 24MHz / 2, so we can just say that our
+ * parent clock is 12MHz.
+ */
+ parent_rate = parent_rate / 2;
+
+ /* Normalize value to a parent_rate multiple (24M / 2) */
+ div = *freq / parent_rate;
+ *freq = parent_rate * div;
+
+ /* we were called to round the frequency, we can now return */
+ if (n == NULL)
+ return;
+
+ *k = div / 32;
+ if (*k > 3)
+ *k = 3;
+ *n = DIV_ROUND_UP(div, (*k+1));
+}
/**
* sun4i_get_apb1_factors() - calculates m, p factors for APB1
@@ -416,6 +447,13 @@ static struct clk_factors_config sun4i_pll5_config = {
.kwidth = 2,
};
+static struct clk_factors_config sun6i_a31_pll6_config = {
+ .nshift = 8,
+ .nwidth = 5,
+ .kshift = 4,
+ .kwidth = 2,
+};
+
static struct clk_factors_config sun4i_apb1_config = {
.mshift = 0,
.mwidth = 5,
@@ -457,6 +495,12 @@ static const struct factors_data sun4i_pll5_data __initconst = {
.getter = sun4i_get_pll5_factors,
};
+static const struct factors_data sun6i_a31_pll6_data __initconst = {
+ .enable = 31,
+ .table = &sun6i_a31_pll6_config,
+ .getter = sun6i_a31_get_pll6_factors,
+};
+
static const struct factors_data sun4i_apb1_data __initconst = {
.table = &sun4i_apb1_config,
.getter = sun4i_get_apb1_factors,
@@ -972,6 +1016,7 @@ free_clkdata:
static const struct of_device_id clk_factors_match[] __initconst = {
{.compatible = "allwinner,sun4i-pll1-clk", .data = &sun4i_pll1_data,},
{.compatible = "allwinner,sun6i-a31-pll1-clk", .data = &sun6i_a31_pll1_data,},
+ {.compatible = "allwinner,sun6i-a31-pll6-clk", .data = &sun6i_a31_pll6_data,},
{.compatible = "allwinner,sun4i-apb1-clk", .data = &sun4i_apb1_data,},
{.compatible = "allwinner,sun4i-mod0-clk", .data = &sun4i_mod0_data,},
{.compatible = "allwinner,sun7i-a20-out-clk", .data = &sun7i_a20_out_data,},
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 0/5] Add Allwinner A31 SPI controller support
From: Maxime Ripard @ 2014-01-29 11:10 UTC (permalink / raw)
To: Mark Brown, Mike Turquette, Emilio Lopez
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-spi-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kevin.z.m.zh-Re5JQEeQqe8AvxtiuMwx3w,
sunny-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
shuge-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf,
zhuzhenhua-0TFLnhJekD6UEPyfVivIlAC/G2K4zDHf, Maxime Ripard
Hi everyone,
This patchset brings support for the SPI controller found in the
Allwinner A31 SoC.
Even though the controller supports DMA, the driver only supports PIO
mode for now. This driver will be used to bring up and test DMA on the
SoC, so support for the DMA will come eventually.
It doesn't support transfer larger than the FIFO size (128 bytes) for
now, I expect it to be fixed in the future.
Thanks!
Maxime
Changes from v1:
- Switched to using the transfer_one and set_cs callbacks
- Switched to using runtime_pm
- Report an error when we try to do a transfer larger than the FIFO
size, instead of silently timeouting.
- Added a Kconfig symbol
- Move the clock ratio change at transfer time
- Fixed the PLL6 cell size in the DTSI
- A few fixes here and there: typos, etc.
Maxime Ripard (5):
clk: sunxi: Add support for PLL6 on the A31
ARM: sun6i: dt: Add PLL6 and SPI module clocks
spi: sunxi: Add Allwinner A31 SPI controller driver
ARM: sun6i: dt: Add SPI controllers to the A31 DTSI
ARM: sunxi: Enable A31 SPI and SID in the defconfig
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
.../devicetree/bindings/spi/spi-sun6i.txt | 24 ++
arch/arm/boot/dts/sun6i-a31.dtsi | 86 +++-
arch/arm/configs/sunxi_defconfig | 3 +
drivers/clk/sunxi/clk-sunxi.c | 45 ++
drivers/spi/Kconfig | 7 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-sun6i.c | 478 +++++++++++++++++++++
8 files changed, 636 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi-sun6i.txt
create mode 100644 drivers/spi/spi-sun6i.c
--
1.8.4.2
^ permalink raw reply
* Re: [RFC] Documentation: devicetree: bindings: drm: Xylon binding
From: Davor Joja @ 2014-01-29 11:00 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Hi,
Can I get some comments on below mails?
I want to create devicetree node for Xylon logiCVC DRM device driver, and get
comments and suggestions from community.
At the end I would send driver and devicetree binding to mainline.
Thank you,
Davor
> Hi Mark,
>
> > On Mon, Jan 27, 2014 at 03:47:42PM +0000, Davor Joja wrote:
> > > Hi,
> >
> > Hi,
> >
> > >
> > > Can I please get comments about adding new vendor prefix "xylon", and on
> > > following devicetree binding for Xylon configurable video controller (logiCVC).
> > > Shown node is prepared for Xilinx Linux kernel dts file.
> >
> > Does this device have any publicly-accessible documentation?
>
> Yes it has, but it does not explain the details mentioned in binding.
> http://www.logicbricks.com/Documentation/Datasheets/IP/logiCVC-ML_hds.pdf
>
> >
> > It would be helpful if you could Cc this to some graphics related
> > mailing lists. Not everyone on devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org is a graphics
> > expert, and you'll get much better feedback with the relevant people on
> > Cc.
> >
>
> Ok, CC'ed.
>
> > It would also be nice to see some code with the binding, and for both
> > the code and binding to be sent as patches. That makes it _far_ easier
> > to review as it's far easier to compare with existing bindings if in a
> > standard format.
> >
>
> Currently I do not have it. I only have some old binding which I want to get
> rid off. That is why I want to change binding (officially) and then rewrite the
> driver code for that exact binding.
>
> > >
> > >
> > > logicvc_0: logicvc@40030000 {
> > > compatible = "xylon,logicvc-4.00.a";
> > > reg = <0x40030000 0x6000>;
> > > interrupt-parent = <&ps7_scugic_0>;
> > > interrupts = <0 59 4>;
> > > background-layer-bits-per-pixel = <32>;
> > > display-interface = <0>;
> > > display-color-space = <1>;
> > > is-readable-regs = <1>;
> > > is-size-position = <1>;
> > > layer-width = <2048>;
> > > num-layers = <4>;
> > > layer_0 {
> > > address = <0>;
> > > alpha-mode = <0>;
> > > data-width = <16>;
> > > type = <0>;
> > > } ;
> > > layer_1 {
> > > address = <0>;
> > > alpha-mode = <0>;
> > > data-width = <32>;
> > > type = <0>;
> > > } ;
> > > layer_2 {
> > > address = <0>;
> > > alpha-mode = <1>;
> > > data-width = <32>;
> > > type = <0>;
> > > } ;
> > > layer_3 {
> > > address = <0>;
> > > alpha-mode = <0>;
> > > data-width = <16>;
> > > type = <1>;
> > > } ;
> > > } ;
> > >
> > >
> > > Required properties for configuring logiCVC device:
> > > - compatible: value must be "xylon,logicvc-4.00.a"
> > > - reg: base address and size of the logiCVC IP
> >
> > Presumably the address and size of the MMIO region the IP has?
>
> Yes, MMIO region address where IP resides and size of IP registers area.
>
> >
> > Does it only have a single bank of registers?
> >
>
> Yes.
>
> > > - interrupts-parent: the phandle for interrupt controller
> > > - interrupts: the interrupt number
> >
> > Does the device have only a single interrupt?
>
> Yes, in this case connected to ARM GIC.
>
> >
> > > - background-layer-bits-per-pixel: background layer color format (0, 16, 32)
> > > if "0" last available layer is standard layer
> >
> > Why is 0 quoted, and what is a "standard layer"?
>
> Thought that this is simple way for saying "not used".
> Maybe have / not to have property?
>
> >
> > > if 16 or 32, last available layer is background layer implemented in
> > > hw register and containing specified bits per pixel color value
> > > - display-interface: logiCVC to display physical interface
> > > (0=Parallel, 1=ITU656)
> > > - display-color-space: logiCVC to display physical color space
> > > (0=RGB, 1=YCbCr 4:2:2, 2=YCbCr 4:4:4)
> >
> > These sound like they should be properties of the display this unit is
> > attached to.
>
> To be more exact, this is output interface to whatever (LCD, encoder,
> converter, ...), but it is IP property selectable when configuring.
> Maybe better name for property should be "interface" and "color-space".
>
> >
> > > - is-readable-regs: all hw registers are readable by sw
> >
> > Which registers aren't always accessible?
>
> IP core can be configured to disable read registers access to all except
> interrupt status power control and interupt status.
>
> >
> > > - is-size-position: hw changing of layer size and position
> >
> > These look like booleans, but have values above.
>
> Yes, it is boolean.
> Should it be
> "readable-regs;" instead "is-readable-regs = <1>;"
> "size-position;" instead "is-size-position = <1>;"
>
> >
> > > - layer-width: layer width in pixels, common for all layers
> > > - num-layers: supported number of layers (1-5)
> >
> > If you require a node for each layer, you don't need this proeprty --
> > you can simply count the layer nodes.
>
> True, I do not know what is practice in this case.
>
> >
> > > if "background-layer-bits-per-pixel != 0", "num-layers" property value is
> > > decreased by 1
> >
> > Does that mean the author of the dt subtracts one, or this is done by
> > the kernel?
> >
>
> In given example it is substracted by author, and I would like to have it like
> that.
> This comment should be just info for user, and maybe it is confusing.
>
> > Why?
> >
> > > - layer_N
> >
> > Where N is?
>
> 0-4
>
> >
> > > - address: layer address hardcoded in hw (0=Unused, 0x...)
> >
> > The example gives all layers 0 / unused. What exactly is this address
> > space?
>
> This property is set while configuring IP, and if it is set to "0" then driver
> knows that there is no dedicated address for video memory and uses its own.
>
> >
> > > - alpha-mode: layer transparency mode (0=Layer, 1=Pixel)
> > > layer alpha mode contains single alpha value for all layer pixels
> > > pixel alpha mode contains alpha value per pixel in video memory
> > > pixel alpha mode can increase physical size of pixel in memory
> > > (8 bits per pixel in pixel alpha mode uses 16 bits per pixel in
> > > memory)
> >
> > This looks like a runtime decision rather than a property of the device.
> >
> > > - data-width: layer bits per pixel color format (16, 32)
> > > - type: layer type (0=RGB, 1=YCbCr)
> >
> > Likewise why is this static?
>
> What exactly do you mean with "runtime decision"?
> All layer properties are configured in IP, and driver needs to know what they
> are to properly handle pixel memory access on specific layer.
>
> Thank you,
> Davor
>
> >
> > Thanks,
> > Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/9] ARM: dts: imx6sl: remove the use of pingrp macros
From: Heiko Stübner @ 2014-01-29 10:42 UTC (permalink / raw)
To: Shawn Guo, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Stephen Warren, Ian Campbell, Rob Herring
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
Russell King - ARM Linux, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
mark.rutland-5wv7dgnIgG8
In-Reply-To: <20140128112047.GC20583-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
On Tuesday, 28. January 2014 19:20:49 Shawn Guo wrote:
> On Tue, Jan 28, 2014 at 11:17:22AM +0100, Heiko Stübner wrote:
> > [... and so on for the other groups ... ]
> >
> > I'm confused now :-) . Current linux-next [0] shows the pin-settings as
> > part of imx6sl.dtsi - a way a lot of other architectures organize their
> > pingroups too, with the board file only referencing the relevant
> > pingroups from the predefined ones of the soc.
> >
> > So I guess your move to the pingrp-header moved them out of the
> > imx6sl.dtsi to the .h and is not part of linux-next;
>
> Yes, my for-next branch was excluded from linux-next temporarily for
> some reason. I will ask Stephen to add it back once v3.14-rc1 is out.
> That said, you can see nothing we developed in this cycle on linux-next
> for now.
>
> > but this patch (and the others in this
> > series) now moves the definitions into the individual board files. Can't
> > you just move them back to the soc-dtsi files to prevent each board
> > duplicating them?
>
> No. That will bring back the problem we try to solve from the
> beginning [1].
>
> [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/275912/
Thanks for the pointer, I think I understand the issue now :-) .
So for the short term, I should probably also define the pingroups in my board-
dts then.
But as an insane idea that I just had, because the issue will probably affect
more architectures at some point when their pingroups or other common-nodes
grow, how about introducing something like a "/delete-if-unreferenced/" prefix
in dtc?
As I could see in [0], adding something to dtc is not as far off as I thought.
In essence one would add the pingroups to the soc dtsi, like
ecspi1 {
/delete-if-unreferenced/ pinctrl_ecspi1_1: ecspi1grp-1 {
fsl,pins = <
MX6SL_PAD_ECSPI1_MISO__ECSPI1_MISO 0x100b1
MX6SL_PAD_ECSPI1_MOSI__ECSPI1_MOSI 0x100b1
MX6SL_PAD_ECSPI1_SCLK__ECSPI1_SCLK 0x100b1
>;
};
};
and dtc would then be tasked with checking if the node gets referenced in a
phandle somewhere in the dts and if not removing it.
I don't know if this is at all sane to think about or doable in dtc.
Heiko
[0] http://www.spinics.net/lists/arm-kernel/msg300936.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] phy-rcar-usb-gen2: add device tree support
From: Sergei Shtylyov @ 2014-01-29 10:41 UTC (permalink / raw)
To: Simon Horman, Ben Dooks
Cc: linux-kernel-81qHHgoATdFT9dQujB1mzip2UmYkHbXO,
linux-usb-u79uwXL29TY76Z2rM5mHXA, linux-sh-u79uwXL29TY76Z2rM5mHXA,
Magnus Damm, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140129062212.GD23833-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Hello.
On 29-01-2014 10:22, Simon Horman wrote:
>> [snip]
>>>> +static struct of_device_id rcar_gen2_usb_phy_ofmatch[] = {
>>>> + { .compatible = "renesas,usb-phy-r8a7790", },
>>>> + { .compatible = "renesas,rcar-gen2-usb-phy", },
>>> Frankly speaking, I don't understand the need for the clearly
>>> duplicate entries.
>> Thanks, will look into remove it.
>> Anyone else have any comments on this?
> I would like you to leave it there.
> As we know the r8a7790 is an R-Car Gen2 SoC. But there are other R-Car
> Gen2 SoCs, such as the r8a7791, they it could plausibly make use of
> rcar-gen2-usb-phy until the driver is updated with a usb-phy-r8a7791 entry.
Why not just "update" the driver this way now, may I ask?
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 1/9] mtd: nand: retrieve ECC requirements from Hynix READ ID byte 4
From: boris brezillon @ 2014-01-29 10:29 UTC (permalink / raw)
To: Brian Norris
Cc: Maxime Ripard, Rob Landley, Russell King, David Woodhouse,
Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, dev-3kdeTeqwOZ9EV1b7eY7vFQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Huang Shijie
In-Reply-To: <20140123014906.GY8919@ld-irv-0074>
Hello Brian,
On 23/01/2014 02:49, Brian Norris wrote:
> + Huang
>
> Hi Boris,
>
> On Wed, Jan 08, 2014 at 03:21:56PM +0100, Boris BREZILLON wrote:
>> The Hynix nand flashes store their ECC requirements in byte 4 of its id
>> (returned on READ ID command).
>>
>> Signed-off-by: Boris BREZILLON <b.brezillon-ZNYIgs0QAGpBDgjK7y7TUQ@public.gmane.org>
> I haven't verified yet (perhaps Huang can confirm?), but this may be
> similar to a patch Huang submitted recently. In his case, we found that
> this table is actually quite unreliable and is likely hard to maintain.
You mean these bytes are not reliable within the whole Hynix LP (Large Page)
NAND product line ?
>
> Why do you need this ECC information, for my reference?
Because the NAND flash available on the cubietruck board does not
support the
ONFI standard, and I thought this could be a option to retrieve the ECC
strength
requirements.
Anyway, I added a new helper function to retrieve ecc informations from
device
tree (I'll post it in the 2nd version of this series). We'll see if this
approach is
accepted...
>
> Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 0/9] mtd: nand: add sunxi NAND Flash Controller support
From: boris brezillon @ 2014-01-29 10:20 UTC (permalink / raw)
To: Rob Herring
Cc: Maxime Ripard, Rob Landley, Russell King, David Woodhouse,
Grant Likely, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dev-3kdeTeqwOZ9EV1b7eY7vFQ
In-Reply-To: <CAL_JsqJNd_gtn-cCLbZxT=s5NkkXp0DZkJkZrBhWiaL6Js=woQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello Rob,
On 23/01/2014 16:22, Rob Herring wrote:
> On Sat, Jan 11, 2014 at 7:38 AM, boris brezillon
> <b.brezillon-ZNYIgs0QAGpBDgjK7y7TUQ@public.gmane.org> wrote:
>> On 08/01/2014 15:21, Boris BREZILLON wrote:
>>> Hello,
>>>
>>> This series add the sunxi NFC support with up to 8 NAND chip connected.
>>> I'm still in the early stages drivers development and some key features
>>> are
>>> missing, but it's usable (I tested it on the cubietruck board).
>>>
>>> Here's what's missing:
>>> - HW ECC support
>>> - DMA support
>>> - HW randomization support
>>> - many more improvements
>>>
>>> This series depends on Emilio's patch series implementing mod0 clks
>>>
>>> (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185478.html)
>>> + an other patch not yet posted
>>>
>>> (http://git.elopez.com.ar/linux/commits/5b4eb3ac406b9c98965714d40e8dd6da943d1ab0)
>>
>> During my reasearch regarding the HW ECC and HW randomizer of the Allwinner
>> NAND flash controller I found this document describing the Altera NAND flash
>> controller
>> (which is in turn based on a cadence IP):
> Which may be similar to drivers/mtd/nand/denali.c as Cadence bought Denali?
Actually I was wrong, the sunxi and the cadence IP have nothing in common.
This was pointed out by Henrik (see this thread :
https://groups.google.com/forum/#!searchin/linux-sunxi/nand/linux-sunxi/x69tFBi95Zk/bNyJlWWOV8oJ
<https://groups.google.com/forum/#%21searchin/linux-sunxi/nand/linux-sunxi/x69tFBi95Zk/bNyJlWWOV8oJ>).
Sorry for the false hopes.
Best Regards,
Boris
>
> Rob
^ permalink raw reply
* Re: [PATCH 1/8] pci-rcar-gen2: add of match table
From: Geert Uytterhoeven @ 2014-01-29 10:06 UTC (permalink / raw)
To: Simon Horman
Cc: Ben Dooks, Sergei Shtylyov, linux-kernel, Bjorn Helgaas,
linux-pci, Linux-sh list, devicetree@vger.kernel.org
In-Reply-To: <20140129061722.GB23833@verge.net.au>
On Wed, Jan 29, 2014 at 7:17 AM, Simon Horman <horms@verge.net.au> wrote:
>> >>+static struct of_device_id rcar_pci_of_match[] = {
>> >>+ { .compatible = "renesas,pci-r8a7790", },
>> >
>> > Why only H2 SoC, if the driver is for both Gen2 SoCs?
>>
>> I can add a "renesas,pci-rcar-gen2" as a fallback match however
>> I've not got anything other than an r8a7790 to test on. Also the
>> compatible properties are preferably named after the soc.
>
> I'm not sure what the "best practice" is here but I propose that
> you add both "renesas,pci-rcar-gen2" and "renesas,pci-r8a7790" now.
To the driver or to the '90 DTS?
If the DTS says
compatible = "renesas,pci-r8a7790", "renesas,pci-rcar-gen2"
then the driver can just live with "renesas,pci-rcar-gen2" for now.
> And that "renesas,pci-r8a7791" can be added once the code has been
> integrated and tested on that platform.
And later we can add
compatible = "renesas,pci-r8a7791", "renesas,pci-rcar-gen2"
to the '91 DTS if it turns out to be compatible.
If the '91 turns out to be incompatible, or partially compatible, the driver
can be updated later to handle both "renesas,pci-r8a7790" and
"renesas,pci-r8a7791" and differentiate between them.
(That's what I was instructed to do with SPI ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 9/9 v5] crypto:s5p-sss: Look for the next request in the queue
From: Naveen Krishna Chatradhi @ 2014-01-29 9:27 UTC (permalink / raw)
To: linux-crypto, linux-samsung-soc
Cc: linux-kernel, vzapolskiy, herbert, naveenkrishna.ch, cpgs,
devicetree, Naveen Krishna Ch
From: Naveen Krishna Ch <ch.naveen@samsung.com>
Currently, the driver enqueues a request only if the busy bit is
false. And every request initiates a dequeue. If 2 requests arrive
simultaneously, only one of them will be dequeued.
To avoid this senario, we will enqueue the next request irrespective
of the system condition (that is what queue is here for). Also
schedule at a tasklet immediatly after the current request is done.
The tasklet will dequeue the next request in the queue, giving
continuous loop. tasklet will exit if there are no requests in the
queue.
Signed-off-by: Naveen Krishna Ch <ch.naveen@samsung.com>
---
This is a new fix in this patchset, tested with dm-crypt/ecryptfs
drivers/crypto/s5p-sss.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 5bd3bd9..d37cbfc 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -330,8 +330,12 @@ static void s5p_aes_tx(struct s5p_aes_dev *dev)
}
s5p_set_dma_outdata(dev, dev->sg_dst);
- } else
+ } else {
s5p_aes_complete(dev, err);
+
+ dev->busy = true;
+ tasklet_schedule(&dev->tasklet);
+ }
}
static void s5p_aes_rx(struct s5p_aes_dev *dev)
@@ -469,10 +473,13 @@ static void s5p_tasklet_cb(unsigned long data)
spin_lock_irqsave(&dev->lock, flags);
backlog = crypto_get_backlog(&dev->queue);
async_req = crypto_dequeue_request(&dev->queue);
- spin_unlock_irqrestore(&dev->lock, flags);
- if (!async_req)
+ if (!async_req) {
+ dev->busy = false;
+ spin_unlock_irqrestore(&dev->lock, flags);
return;
+ }
+ spin_unlock_irqrestore(&dev->lock, flags);
if (backlog)
backlog->complete(backlog, -EINPROGRESS);
@@ -491,14 +498,13 @@ static int s5p_aes_handle_req(struct s5p_aes_dev *dev,
int err;
spin_lock_irqsave(&dev->lock, flags);
+ err = ablkcipher_enqueue_request(&dev->queue, req);
if (dev->busy) {
- err = -EAGAIN;
spin_unlock_irqrestore(&dev->lock, flags);
goto exit;
}
dev->busy = true;
- err = ablkcipher_enqueue_request(&dev->queue, req);
spin_unlock_irqrestore(&dev->lock, flags);
tasklet_schedule(&dev->tasklet);
@@ -688,6 +694,7 @@ static int s5p_aes_probe(struct platform_device *pdev)
}
}
+ pdata->busy = false;
pdata->variant = variant;
pdata->dev = dev;
platform_set_drvdata(pdev, pdata);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 8/9 v5] crypto:s5p-sss: Use clk_prepare/clk_unprepare
From: Naveen Krishna Chatradhi @ 2014-01-29 9:26 UTC (permalink / raw)
To: linux-crypto, linux-samsung-soc
Cc: linux-kernel, vzapolskiy, herbert, naveenkrishna.ch, cpgs,
devicetree
In-Reply-To: <1389354331-32142-1-git-send-email-ch.naveen@samsung.com>
This patch set adds use of clk_prepare/clk_unprepare as
required by generic clock framework.
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
---
Changes since v4:
Handle return value of clk_prepare_enable
Changes since v3:
None
drivers/crypto/s5p-sss.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index a890273..5bd3bd9 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -648,7 +648,11 @@ static int s5p_aes_probe(struct platform_device *pdev)
return -ENOENT;
}
- clk_enable(pdata->clk);
+ err = clk_prepare_enable(pdata->clk);
+ if (err < 0) {
+ dev_err(dev, "Enabling SSS clk failed, err %d\n", err);
+ return err;
+ }
spin_lock_init(&pdata->lock);
pdata->ioaddr = devm_ioremap(dev, res->start,
@@ -711,7 +715,7 @@ static int s5p_aes_probe(struct platform_device *pdev)
tasklet_kill(&pdata->tasklet);
err_irq:
- clk_disable(pdata->clk);
+ clk_disable_unprepare(pdata->clk);
s5p_dev = NULL;
@@ -731,7 +735,7 @@ static int s5p_aes_remove(struct platform_device *pdev)
tasklet_kill(&pdata->tasklet);
- clk_disable(pdata->clk);
+ clk_disable_unprepare(pdata->clk);
s5p_dev = NULL;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 7/9 v5] crypto:s5p-sss: validate iv before memcpy
From: Naveen Krishna Chatradhi @ 2014-01-29 9:25 UTC (permalink / raw)
To: linux-crypto, linux-samsung-soc
Cc: linux-kernel, vzapolskiy, herbert, naveenkrishna.ch, cpgs,
devicetree
In-Reply-To: <1389243640-13282-1-git-send-email-ch.naveen@samsung.com>
This patch adds code to validate "iv" buffer before trying to
memcpy the contents
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
---
Changes since v4:
None
Changes since v3:
None
drivers/crypto/s5p-sss.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index da1c8943..a890273 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -380,7 +380,8 @@ static void s5p_set_aes(struct s5p_aes_dev *dev,
{
void __iomem *keystart;
- memcpy(dev->aes_ioaddr + SSS_REG_AES_IV_DATA (0), iv, 0x10);
+ if (iv)
+ memcpy(dev->aes_ioaddr + SSS_REG_AES_IV_DATA (0), iv, 0x10);
if (keylen == AES_KEYSIZE_256)
keystart = dev->aes_ioaddr + SSS_REG_AES_KEY_DATA(0);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 6/9 v5] ARM: dts: exynos5250/5420: add dt node for sss module
From: Naveen Krishna Chatradhi @ 2014-01-29 9:24 UTC (permalink / raw)
To: linux-crypto, linux-samsung-soc
Cc: linux-kernel, vzapolskiy, herbert, naveenkrishna.ch, cpgs,
devicetree, Kukjin Kim
In-Reply-To: <1389777397-15193-1-git-send-email-ch.naveen@samsung.com>
This patch adds the device tree node for SSS module
found on Exynos5420 and Exynos5250
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
TO: <linux-samsung-soc@vger.kernel.org>
CC: Kukjin Kim <kgene.kim@samsung.com>
CC: <linux-crypto@vger.kernel.org>
---
Changes since v4:
None
Changes since v3:
1. Modified the SSS clock ID as per dt-bindings for Exynos5250 in
samsung-clk.git tree.
arch/arm/boot/dts/exynos5250.dtsi | 8 ++++++++
arch/arm/boot/dts/exynos5420.dtsi | 10 ++++++++++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index c341e55..1d249df 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -704,4 +704,12 @@
io-channel-ranges;
status = "disabled";
};
+
+ sss@10830000 {
+ compatible = "samsung,exynos4210-secss";
+ reg = <0x10830000 0x10000>;
+ interrupts = <0 112 0>;
+ clocks = <&clock 348>;
+ clock-names = "secss";
+ };
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 11dd202..56a3f3e 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -652,4 +652,14 @@
clocks = <&clock 319>, <&clock 318>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
};
+
+ sss@10830000 {
+ compatible = "samsung,exynos4210-secss";
+ reg = <0x10830000 0x10000>;
+ interrupts = <0 112 0>;
+ clocks = <&clock 471>;
+ clock-names = "secss";
+ samsung,power-domain = <&g2d_pd>;
+ };
+
};
--
1.7.9.5
^ 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