Date:	Thu, 1 Dec 2011 16:21:44 +1100
From:	NeilBrown <neilb@...e.de>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	MyungJoo Ham <myungjoo.ham@...il.com>,
	linux-kernel@...r.kernel.org,
	Linus Walleij <linus.walleij@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Mike Lockwood <lockwood@...roid.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Donggeun Kim <dg77.kim@...sung.com>, Greg KH <gregkh@...e.de>,
	Grant Likely <grant.likely@...retlab.ca>,
	Kalle Komierowski <karl.komierowski@...ricsson.com>,
	Johan PALSSON <johan.palsson@...ricsson.com>,
	Daniel WILLERUD <daniel.willerud@...ricsson.com>
Subject: Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

On Wed, 30 Nov 2011 15:25:29 -0800 Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:

> On Wed, Nov 30, 2011 at 11:17:41PM +0000, Mark Brown wrote:
> > On Thu, Dec 01, 2011 at 09:56:33AM +1100, NeilBrown wrote:
> > > On Wed, 30 Nov 2011 15:40:48 +0900 MyungJoo Ham <myungjoo.ham@...il.com>
> > > wrote:
> > 
> > > > I'm focusing on an external connector or port that each physical port
> > > > may inhabit multiple cables at a time although it should support a
> > > > port that may inhabit a single cable only at a time. However, the
> > > > class could be used for other general "multistate mux" that connects
> > > > different device drivers.
> > 
> > >  maybe I'm just slow, but I'm having a lot of trouble imagining a single port
> > >  that could have multiple cables plugged in at the same time.  And this
> > >  blockage is stopping me from reflecting usefully on your other points.
> > 
> > >  Are you able to show me a picture or a diagram or something so I can
> > >  visualise what you are talking about?
> > >  To me: once you plug one cable into a port, it is full and there is no room
> > >  for any more cables.
> > 
> > One obvious example is the sort of big multi-way docking connector that
> > many mobile devices have (iPod and friends being one of the most
> > common).  These are essentially the same as docking station connections
> > on a laptop in terms of what they bring out - a variety of audio, video
> > and communication connections - which may go to a docking station or
> > some kind of breakout or adaptor cable and may have sub-ports hanging
> > off them (eg, it's common for tablets to have docking stations with HDMI
> > and audio sockets on them).
> > 
> > There are also lower pin count equivalents like the multiplexed "USB"
> > sockets on some phones which can also carry other functions with
> > adaptors, and even something like a headset is really a microphone and
> > headphones on a single jack.
> 
> Physical jack does not have to map 1:1 on logical jack. So 1 physical
> docking connector can be represented by 1 logical video connector, line
> in, line out, microphone and maybe else.
> 

That is just what I was thinking :-)


It seems that a "connector" could be modelled as a set of binary switches,
one for each service that is exported (or imported? ... "communicated" maybe)
through the connector.  When a cable (or dock) is plugged in, some number of
these switches are all switched on concurrently.  When it is unplugged they
are all switched off.

How strongly do we need this understanding of a "group" to be?

Mark says:

> We also need some way to group things together so that we can understand
> that we've got a single connector that can detect multiple things (eg,
> understanding that a cable hsa audio and video capability).

It isn't immediately obvious why this is the case.  There is no guarantee
that I want to route audio and video in the same direction.  The best you can
probably get is a heuristic that both should be routed to the most recently
available destination.
But again, maybe I'm missing something important.   I guess the helpful piece
of information is: How exactly would this knowledge of grouping be used?


As for naming of these switches, I think small numbers are nice as they are
consistent with similar abstractions inside Linux.  Pointers might be equally
suitable though.

The core idea is that a 'switch' is used to connect the driver which detects
the change to the driver (or drivers) which uses the change.
Some common parent of both drivers allocates the switch and passes it to both
devices, possibly through platform data.

In some cases the common parent might be the 'board' file.
One case I am thinking of is the twl4030 driver (a multi-function device for
power, usb, audio, battery charge etc).
The battery charger needs to know when the usb device gets a cable plugged in
so that it can start charging.
It currently creates a link essentially by using a global variable.

Using a 'switch', the twl-core module could allocate a switch and pass it to
the usb module for sending notification and to the bci module for receiving
them.  Whether it passes down a number which is later turned into a pointer,
or whether it sends down the raw pointer, is just an implementation detail.

Can the same be done for these cable ports that you have in mind?  Presumably
the common-parent could allocate several switches - maybe even an array of
switches - and pass the collection of switches to the port, and then pass
individual switches to individual component drivers.

If the switch needs to be exported to user-space then someone needs to
provide a name for it.  I suspect the common-parent would be the obvious
choice, or the board file.

Possible a standard naming scheme like the one that LEDs suggests would make
sense.  e.g. platform.port.cable

   MAX8997.MUIC-0.USB-Host
   MAX8997.MUIC-1.MHL

or whatever.
So naming scheme would need to be established for apps to negotiation
effectively with the kernel, but I don't think a naming scheme is needed
inside the kernel.


Just to be clear, the functionality that I see a 'switch' supporting is:


For the owner:
  - int switch_allocate(void)
  - void switch_export(int switchnum, char *name)
     This creates a device which appears in sysfs and has a 'state'
     attribute which responds to 'poll' requests so a process can find
     out about changes.

For the notifier:
  - void switch_set_state(int switchnum, bool value)
          This sets the state and notifies all notifiees (listeners).

For the notifiee (listener)
  - void swtch_add_listener(int switchnum, struct notifier_block *nblock)
  - bool switch_get_state(int switchnum)

If we needed clear grouping then maybe:

   int switch_allocate(int numswitches, int *switch_list)

to allocate a group, which gets a unique identifier and

   int switch_get_group(int switchnum)

to get that unique identifier ... assuming that was a useful thing - probably
not.



NeilBrown


Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)

Powered by blists - more mailing lists