Message-ID: <1371654898.3173.11.camel@hornet>
Date:	Wed, 19 Jun 2013 16:14:58 +0100
From:	Pawel Moll <pawel.moll@....com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Samuel Ortiz <sameo@...ux.intel.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Amit Kucheria <amit.kucheria@...aro.org>,
	Jon Medhurst <tixy@...aro.org>,
	Achin Gupta <Achin.Gupta@....com>,
	Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@....com>
Subject: Re: [RFC PATCH v3 0/2] drivers: mfd: Versatile Express SPC support

On Wed, 2013-06-19 at 16:03 +0100, Arnd Bergmann wrote:
> On Wednesday 19 June 2013, Pawel Moll wrote:
> > ... but sysreg does more than just that. In particular it provides a
> > pseudo-gpio controller (I don't think you want to hide this behind the
> > syscon) and it can act as a bridge to the configuration bus - see
> > below. In short - no, I don't think sysreg driver can disappear. It can
> > be reduced in size, yes.
> 
> As I said, the gpio part can be a separate driver that just handles
> gpio, 

I've already promised Samuel that.

> and I think the configuration bridge can be part of the
> vexpress-config driver, building on top of syscon. I'm not completely
> sure about the latter part.

I don't think so, no. I appreciate what you are trying to say, but I
object to mixing ideas for the sake of reducing number of files. The
config infrastructure is completely independent from the sysreg. Each of
them can exist on its own. The only common thing is a (slightly baroque)
communication interface between those two.

> > > > > 3. Move vexpress-config into drivers/bus as it is (however I see no one
> > > > > in MAINTAINERS for this directory)
> > > > ISTR that Arnd originally created that directory, so he may help here.
> > > > Arnd also had some concerns about implementing this code as a bus,
> > > > mostly about it not being a discoverable bus. IMHO that's a valid
> > > > concern, and this is why you ended up putting it under MFD which can be
> > > > seen as some sort of platform devices bus. But I still believe the bus
> > > > API would make this code look cleaner and easier to maintain.
> > > 
> > > Sorry, I don't see why it would be a bus. I assume that there is code
> > > missing somewhere that is not yet merged, right?
> > 
> > Well, different VE components (configuration microcontrollers on
> > motherboard and daughterboards in particular) talk to each other over a
> > bus (an SPI derivative, in case you were wondering). So there is a bus.
> > A non-discoverable one, but it does 42 (approximately ;-) different
> > things. We already have: clk, hwmon, regulator and reset drivers using
> > it.
> 
> Ah, got it. In this case I think what you are looking for is a custom
> 'regmap' interface that abstracts those devices. Regmap can already
> cover i2c, spi and mmio based sets of registers (syscon is one example
> for mmio), and IIRC there is a simple way of extending it to other
> register-level interfaces like this one.

This is an interesting idea. The thing that worries me the most is its
early (pre-slab) availability, but I will give it a try.

Paweł


--
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