lkml.org 
[lkml]   [2011]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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]
\
 
 \ /
  Last update: 2011-12-05 20:41    [W:0.071 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site