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
On 20/09/12 20:36, Thomas Petazzoni wrote:
Dear Linus Walleij,
On Thu, 20 Sep 2012 21:28:20 +0200, Linus Walleij wrote:
So what I'm after is whether in this case statically encoding this
onto the .dtsi files is the right thing to do, or whether the boot loader
or kernel should runtime-modify
On 20/09/12 20:36, Thomas Petazzoni wrote:
Dear Linus Walleij,
On Thu, 20 Sep 2012 21:28:20 +0200, Linus Walleij wrote:
So what I'm after is whether in this case statically encoding this
onto the .dtsi files is the right thing to do, or whether the boot loader
or kernel should runtime-modify
On Thu, Sep 20, 2012 at 9:36 PM, Thomas Petazzoni
thomas.petazz...@free-electrons.com 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
> 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
Dear Linus Walleij,
On Thu, 20 Sep 2012 21:28:20 +0200, Linus Walleij wrote:
> So what I'm after is whether in this case statically encoding this
> onto the .dtsi files is the right thing to do, or whether the boot loader
> or kernel should runtime-modify the device tree, patching in
> the
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
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
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
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
mach/foo-id-probe.h is nominally done by passing the data
to the driver as platform data instead, and only using
these
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
mach/foo-id-probe.h is nominally done by passing the data
On Thu, Sep 20, 2012 at 5:30 PM, Arnd Bergmann a...@arndb.de 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
Dear Linus Walleij,
On Thu, 20 Sep 2012 21:28:20 +0200, Linus Walleij wrote:
So what I'm after is whether in this case statically encoding this
onto the .dtsi files is the right thing to do, or whether the boot loader
or kernel should runtime-modify the device tree, patching in
the
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 out
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:
> -
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
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
> 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
On 09/17/2012 03:55 AM, Nicolas Pitre wrote:
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
+
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 to
On Sun, Sep 16, 2012 at 11:09 AM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com 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
On 09/17/2012 03:55 AM, Nicolas Pitre wrote:
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
+
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
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 09/16/2012 09:46 AM, Andrew Lunn wrote:
+Required properties:
+- compatible: "marvell,88f6180-pinctrl",
+ "marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl",
+ "marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl"
+
+This driver supports all kirkwood variants, i.e.
> +++ 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:
> +-
+++ 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 09/16/2012 09:46 AM, Andrew Lunn wrote:
+Required properties:
+- compatible: marvell,88f6180-pinctrl,
+ marvell,88f6190-pinctrl, marvell,88f6192-pinctrl,
+ marvell,88f6281-pinctrl, marvell,88f6282-pinctrl
+
+This driver supports all kirkwood variants, i.e. 88f6180,
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
binding
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 to
30 matches
Mail list logo
