Date: Mon, 20 Apr 2009 15:56:27 +0100
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Mike Rapoport <mike@compulab.co.il>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFD] voltage/current regulator consumer interface
Message-ID: <20090420145627.GA5281@rakim.wolfsonmicro.main>
References: <49EC8775.8060609@compulab.co.il>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49EC8775.8060609@compulab.co.il>
User-Agent: Mutt/1.5.18 (2008-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1964
Lines: 41

On Mon, Apr 20, 2009 at 05:32:21PM +0300, Mike Rapoport wrote:

> It is the most simple and straight forward solution. However, I have several
> questions and I cannot answer them myself:

Some initial thoughts:

>   Should the driver handle single or several supplies at once?

I'd expect that it should be able to cope with that - a lot of hardware
takes multiple supplies.

>   If the driver handles several supplies how to define attributes per-supply?
>   What attributes will be exposed? Would it be simple 'state' that can be
> enabled or disabled? Or the entire set of micorvolts/microamps etc?

I'd expect that if you're getting into much more than a simple enable
for the entire device it'd be getting to the point where it's worth
considering writing an actual driver for the device.  That said, it's a
fairly natural extension to support more fine grained stuff if someone
does actually end up wanting it.

> - Extend regulator framework so that regulator_consumer_supply entities will
> gain their own representation in sysfs. Depending on machine constraints the
> supply attributes can be either read-only or writable. I haven't dedicated much
> thought to it, so a cannot state any pros and cons.

I'd expect making them writable to be very fragile if there is an active
consumer driver - I'd expect reference counts to get lost with enable
and disable and I'd expect drivers managing voltages and currents to get
confused if their own configuration gets changed under them.  The core
already needs to arbitrate between multiple users so it seems to make
sense to have userspace represented as other users are to the core.

Being able to read back the consumer status doesn't seem unreasonable,
though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/