Messages in this thread | | | Date | Tue, 6 Dec 2011 06:38:34 +1100 | From | NeilBrown <> | Subject | Re: [RFC PATCH 0/3] introduce: Multistate Switch Class |
| |
On Mon, 5 Dec 2011 12:06:08 +0000 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, Dec 05, 2011 at 02:04:13PM +1100, NeilBrown wrote: > > On Thu, 1 Dec 2011 11:34:50 +0000 Mark Brown > > > > We really want something a bit more involved in the USB frameworks for > > > the specific example of USB stuff (which is being worked on) - ideally > > > we should be communicating information about how much current the host > > > allows to be drawn throughout the system. > > > Sounds like a job for the 'regulator' framework - but that is a guess based > > on not looking very deeply, so I'm probably wrong :-) > > The regulator framework might be used to implement the current limits > but it understands nothing about the sematics of what it's doing, it > just understands things at the level of setting values. Something would > need to sit above it to plug into USB. > > > > I think we do want something which lets us say "this is a cable of > > > type X" so that we can report the difference between otherwise identical > > > cables as in the car/desktop dock example I mentioned above. > > > I think you are saying that you might have two "cables" which connect up the > > same sets of signals but are "different" somehow. One connects to a car, > > the other to a desk-top dock. > > How is that difference detected by the hardware? Presumably some switch? > > So this is just one more binary switch to export to who-ever needs to know > > (presumably user-space) ??? > > Implementations vary - it may involve something like reading an ID chip > over some bus, for example. It's definitely not a binary switch, it > needs to have more values than that.
Ahh.. So to try to restate the requirements:
A "cable-port" can detect when a "cable" in inserted (or removed) and can determine the "cable-type" which comprises: - a "cable-name" which is an arbitrary label interpreted in the context of the particular port - 1 or more "cable-function" flags which indicate what functions the cable support. A given port has a fixed set of "cable-functions" and for any given cable it will report true/false (present/absent, on/off) for each cable-function.
This full "cable-type" needs to be presented to user-space, and individual cable-functions may need to be communicated to specific drivers to trigger a 'probe' function.
Questions: 1/ Do we need to communicate anything to drivers apart from "cable-detect"? i.e. are they quite cable of probing and identifying, or do they need to be told what to look for? 2/ Does it hurt to simply wake up all drivers that might be listening on the cable or do we need individual wake-ups (notifiers) for each cable-function? 3/ Does anything in the kernel care about the cable-name, or is that only interesting to user-space?
I think that the "cable-functions" might still be best represented by virtual GPIOs, but the cable-name is certainly more than that.
To me this does sound like it might want a 'cable-port' device and it should generate 'change' uevents when a new cable appears. The change from no-cable to cable-X does seem quite a significant change affecting possible multiple subsystems so a uevent seems to me to be justified.
> > > My GTA04 has a wifi chip connected to an mmc port. The wifi chip has a > > separate regulator that can be powered up/down independently of everything > > else. > > So when I apply power I need a way to tell the mmc driver to scan the bus. > > It expects this information to come via a GPIO which has an associated IRQ. > > But I don't have a physical gpio to give it. > > > So this is a case where one driver (the rfkill driver) needs to signal > > another driver (the mmc driver) to tell it that a new device has become > > available. It hasn't been plugged in via a cable, it has be turned-on via a > > regulator, but it is conceptually very similar. > > This is a very common situation. The solution we've mostly been going > for for soldered down components is actually rather different, though - > in general it's much nicer for userspace if the device is presented as > always there rather than doing the hotplug thing and we just power it up > as needed. > > Due to the existing rfkill implementations I guess the network stack is > already happy with the probe/remove model but that's not universally > true. Even with userspace understanding things this would for example > also mean that we'd be able to keep the WiFi powered down when we just > happen not to be using it without having to use the rfkill switch. > > > I wrote a virtual gpio chip which I call gpio-inout because it provides pairs > > of gpios, an output paired with an input. When the output is changed it > > triggers an interrupt associated with the input, and the output is always > > readable by the input. > > For the implementation I suggest above (which the core can't really cope > with yet but anyway) I'd be using a regulator.
Brilliant! That might solve another related problem I've been having. Time to learn even more about regulators.
Thanks, NeilBrown [unhandled content-type:application/pgp-signature] | |