Date:	Thu, 20 Sep 2012 20:34:52 +0200
From:	Andrew Lunn <andrew@...n.ch>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Linus Walleij <linus.walleij@...aro.org>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Andrew Lunn <andrew@...n.ch>,
	Russell King <linux@....linux.org.uk>,
	Jason Cooper <jason@...edaemon.net>,
	Stephen Warren <swarren@...dotorg.org>,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Rob Herring <rob.herring@...xeda.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Lior Amsalem <alior@...vell.com>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	Rob Landley <rob@...dley.net>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>
Subject: Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver

On Thu, Sep 20, 2012 at 03:30:40PM +0000, 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
> > to the driver as platform data instead, and only using
> > these functions in the mach-foo folder when populating
> > platform data, and thus it can be made into a local
> > header, say mach-foo/foo-id-probe.h
> > 
> > So the machine/arch code reads these registers to
> > populate the platform data and device drivers only
> > look at the platform data, which has some enum or
> > bool indicating what hardware it's running on, cool.
> > 
> > But according to the other consolidation track, platform
> > data should go into device tree bindings.
> > 
> > So the conclusion is that the DT must contain the data
> > about the platform, so it's not auto-probed by the kernel.
> > (I.e. the kernel reads no registers to figure out what hardware
> > this is, that stuff comes from the device tree.)
> > 
> > DT purists will say that the boot loader should ask the chipset
> > what it is with the same register writes and populate the
> > DT accordingly, instead of loading a precompiled blob.
> > Some may even ponder the crazy concept of amending the
> > DT in the kernel at early boot.
> > 
> > But in practice someone will give up, encode the stuff in
> > the static device tree and autoprobing of the platform
> > goes out the window.
> 
> In general, I would prefer probing hardware by asking the hardware itself
> rather than duplicating the information in the device tree. We do this
> whenever we can, e.g. on PCI or USB, but we cannot normally do the same
> on embedded buses like AHB, I2C or SPI, so we have to use the device
> tree to provide some or all of the information.
> 
> 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 hardware (CPU core revision, or PCI device ID of
> the root complex).

Hi Arnd

Even if we did look at the PCIe device IDs, we would still have one
odd-ball case to deal with. We have had an initial port to a Marvell
98DX4122 contributed. This chip is a Marvell Ethernet chip, with an
embedded Kirkwood SoC. The SoC is missing SATA, RTC, SDIO, I2S, TDM,
and TS which other kirkwoods have. So it will need a different pinctrl
table. However, looking at the PCIe device ID, it identifies itself as
a normal MV88F6281. So we would have to deal with this in DT with a
different compatibility string.

	  Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists