> +++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
> @@ -0,0 +1,279 @@
> +* Marvell Kirkwood SoC pinctrl driver for mpp
> +
> +Please refer to marvell,mvebu-pinctrl.txt in this directory for common
> binding
> +part and usage.
> +
> +Required properties:
> +- compatible
On Sun, Sep 16, 2012 at 09:46:52AM +0200, Andrew Lunn wrote:
> > +++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
> > @@ -0,0 +1,279 @@
> > +* Marvell Kirkwood SoC pinctrl driver for mpp
> > +
> > +Please refer to marvell,mvebu-pinctrl.txt in this directory for common
>
On Sun, 16 Sep 2012, Jason Cooper wrote:
> On Sun, Sep 16, 2012 at 09:46:52AM +0200, Andrew Lunn wrote:
> > > +++
> > > b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
> > > @@ -0,0 +1,279 @@
> > > +* Marvell Kirkwood SoC pinctrl driver for mpp
> > > +
> > > +Please refer
> I had a closer look at how kirkwood probes its id. I mentionend kirkwood_id()
> earlier but in fact it is kirkwood_pcie_id(). I assume pcie registers are shut
> down with pcie clk gated? That would require to have pcie running at least at
> boot-time on all boards.
>
> While it is still possible
On Sun, Sep 16, 2012 at 11:09 AM, Sebastian Hesselbarth
wrote:
> On 09/16/2012 09:46 AM, Andrew Lunn wrote:
>> Here you are suggesting we have to put into the DT what chip we expect
>> to be on.
>>
>> What is the advantage of this, over getting the information from the
>> device itself?
>
> If th
On Thu, Sep 13, 2012 at 05:41:45PM +0200, Sebastian Hesselbarth wrote:
> This patch adds a SoC specific pinctrl driver for Marvell Kirkwood SoCs
> plus DT binding documentation. This driver will use the mvebu pinctrl
> driver core.
>
> Signed-off-by: Sebastian Hesselbarth
> ---
> v2:
> - restruct
On Monday 17 September 2012, Linus Walleij wrote:
> You found the weak spot between two consolidation tracks.
>
> Getting rid of a broadcast autodetect functions from say
> is nominally done by passing the data
> to the driver as platform data instead, and only using
> these functions in the mach
On Thu, Sep 20, 2012 at 03:30:40PM +, Arnd Bergmann wrote:
> On Monday 17 September 2012, Linus Walleij wrote:
> > You found the weak spot between two consolidation tracks.
> >
> > Getting rid of a broadcast autodetect functions from say
> > is nominally done by passing the data
> > to the dr
On Thu, Sep 20, 2012 at 5:30 PM, Arnd Bergmann wrote:
> A corner case is the one where you have different versions of the same
> IP block (e.g. the pinctrl) and the kernel cannot find out which one it
> is by looking at registers inside it or on the parent bus, but only
> by looking at other hard
> So, wouldn't we need a small, architecture-independent, infrastructure,
> through which architecture-specific code could "register" at boot
> time which SoC we are running on, and drivers could query this
> information from the common infrastructure?
>
> Of course, the major problem is to figure
On Thu, Sep 20, 2012 at 9:36 PM, Thomas Petazzoni
wrote:
> If I understand correctly, we would like drivers to be able to read
> some common "system" registers to figure out which SoC variant we are
> running on. Such feature should normally be provided by code in
> arch/arm/mach-*/ and called by
11 matches
Mail list logo
