[RFC PATCH 0/3] introduce: Multistate Switch Class

[RFC PATCH 0/3] introduce: Multistate Switch Class

[MyungJoo Ham]

For switch ports, which may have different types of cables
(USB, TA, HDMI, Analog A/V, and others), we often have seperated device
drivers that detect the state changes at the port and device drivers that
do something according to the state changes.

For example, when MAX8997-MUIC detects a Charger cable insertion, another
device driver (such as MAX8903 charger, MAX8997 charger, Charger Manager,
or board file) needs to set charger current limit accordingly and when
MAX8997-MUIC detects a HDMI cable insertion, multimedia device drivers
need to do some operations accordingly.

This patchset supports the usage of notifier for passing such information
between device drivers.

Another issue is that at a single switch port, there might be multiple
and heterogeneous cables attached at the same time. Besides, the state
(Attached or Detached) of each cable may alter independently.

In order to address such issues, Android kernel's "Switch" class seems to
be a good basis and we have implemented "Multistate Switch Class" based on
it. The "Switch" class code of Android kernel is GPL as well.

Donggeun Kim (1):
  Multistate Switch Class: add notifier block

MyungJoo Ham (2):
  Multistate Switch Class: import Android's switch class and modify.
  Multistate Switch Class: support multiple states at a device.

 drivers/Makefile            |    1 +
 drivers/misc/Kconfig        |   21 +++
 drivers/misc/Makefile       |    2 +
 drivers/misc/switch_class.c |  332 +++++++++++++++++++++++++++++++++++++++++++
 drivers/misc/switch_gpio.c  |  174 ++++++++++++++++++++++
 include/linux/switch.h      |  164 +++++++++++++++++++++
 6 files changed, 694 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/switch_class.c
 create mode 100644 drivers/misc/switch_gpio.c
 create mode 100644 include/linux/switch.h

-- 
1.7.4.1

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Arnd Bergmann]

On Thursday 24 November 2011, MyungJoo Ham wrote:
> For switch ports, which may have different types of cables
> (USB, TA, HDMI, Analog A/V, and others), we often have seperated device
> drivers that detect the state changes at the port and device drivers that
> do something according to the state changes.
> 
> For example, when MAX8997-MUIC detects a Charger cable insertion, another
> device driver (such as MAX8903 charger, MAX8997 charger, Charger Manager,
> or board file) needs to set charger current limit accordingly and when
> MAX8997-MUIC detects a HDMI cable insertion, multimedia device drivers
> need to do some operations accordingly.
> 
> This patchset supports the usage of notifier for passing such information
> between device drivers.
> 
> Another issue is that at a single switch port, there might be multiple
> and heterogeneous cables attached at the same time. Besides, the state
> (Attached or Detached) of each cable may alter independently.
> 
> In order to address such issues, Android kernel's "Switch" class seems to
> be a good basis and we have implemented "Multistate Switch Class" based on
> it. The "Switch" class code of Android kernel is GPL as well.

How does this relate to the new "pinmux" subsystem that Linus Walleij
maintains? Would it be useful to integrate your driver into pinmux
instead of starting a new subsystem?

	Arnd

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[MyungJoo Ham]

On Fri, Nov 25, 2011 at 11:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 24 November 2011, MyungJoo Ham wrote:
>> For switch ports, which may have different types of cables
>> (USB, TA, HDMI, Analog A/V, and others), we often have seperated device
>> drivers that detect the state changes at the port and device drivers that
>> do something according to the state changes.
>>
>> For example, when MAX8997-MUIC detects a Charger cable insertion, another
>> device driver (such as MAX8903 charger, MAX8997 charger, Charger Manager,
>> or board file) needs to set charger current limit accordingly and when
>> MAX8997-MUIC detects a HDMI cable insertion, multimedia device drivers
>> need to do some operations accordingly.
>>
>> This patchset supports the usage of notifier for passing such information
>> between device drivers.
>>
>> Another issue is that at a single switch port, there might be multiple
>> and heterogeneous cables attached at the same time. Besides, the state
>> (Attached or Detached) of each cable may alter independently.
>>
>> In order to address such issues, Android kernel's "Switch" class seems to
>> be a good basis and we have implemented "Multistate Switch Class" based on
>> it. The "Switch" class code of Android kernel is GPL as well.
>
> How does this relate to the new "pinmux" subsystem that Linus Walleij
> maintains? Would it be useful to integrate your driver into pinmux
> instead of starting a new subsystem?
>
>        Arnd
>

I haven't thought about pinmux subsystem and wasn't aware of it.
However the name, pinmux, suggests that it supports similar devices if
not same. I'll read pinmux subsystem first. Thamks a lot.

Cheers!
MyungJoo



-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Kyungmin Park]

On Fri, Nov 25, 2011 at 11:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 24 November 2011, MyungJoo Ham wrote:
>> For switch ports, which may have different types of cables
>> (USB, TA, HDMI, Analog A/V, and others), we often have seperated device
>> drivers that detect the state changes at the port and device drivers that
>> do something according to the state changes.
>>
>> For example, when MAX8997-MUIC detects a Charger cable insertion, another
>> device driver (such as MAX8903 charger, MAX8997 charger, Charger Manager,
>> or board file) needs to set charger current limit accordingly and when
>> MAX8997-MUIC detects a HDMI cable insertion, multimedia device drivers
>> need to do some operations accordingly.
>>
>> This patchset supports the usage of notifier for passing such information
>> between device drivers.
>>
>> Another issue is that at a single switch port, there might be multiple
>> and heterogeneous cables attached at the same time. Besides, the state
>> (Attached or Detached) of each cable may alter independently.
>>
>> In order to address such issues, Android kernel's "Switch" class seems to
>> be a good basis and we have implemented "Multistate Switch Class" based on
>> it. The "Switch" class code of Android kernel is GPL as well.
>
> How does this relate to the new "pinmux" subsystem that Linus Walleij
> maintains? Would it be useful to integrate your driver into pinmux
> instead of starting a new subsystem?

Hi Arnd,

As you know, the 'pinmux' is based on the GPIO based MUX and changes
the pin state by device driver want.
but multistate switch provides the mechanism which notify the state
change and each device drivers handles it properly.
As described at cover letter, if MHL (Mobile HTML Link) is connected
to the phone, it switch the circuit to use MHL chip and notify the MHL
& HDMI power up. and detached power down the HDMI related chips.

Moreover new 30 pin connector is used, it can support more devices. In
this case we don't need to switch the circuit. Of course some pins are
need to changed  to MUXing purpose. but notify proper information to
each devices.

I think the 'pinmux' is controlled by each device drivers as passive
framework, however multistate switch is active way to know/notify each
devices works properly when external connector is attached to device
(e.g., phone)

BTW does pinmux framework provide the notification mechanism to device?

Thank you,
Kyungmin Park

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Linus Walleij]

Hi MyungJoo, Arnd

On Fri, Nov 25, 2011 at 3:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 24 November 2011, MyungJoo Ham wrote:
>> For switch ports, which may have different types of cables
>> (USB, TA, HDMI, Analog A/V, and others), we often have seperated device
>> drivers that detect the state changes at the port and device drivers that
>> do something according to the state changes.
>>
>> For example, when MAX8997-MUIC detects a Charger cable insertion, another
>> device driver (such as MAX8903 charger, MAX8997 charger, Charger Manager,
>> or board file) needs to set charger current limit accordingly and when
>> MAX8997-MUIC detects a HDMI cable insertion, multimedia device drivers
>> need to do some operations accordingly.
>>
>> This patchset supports the usage of notifier for passing such information
>> between device drivers.
>>
>> Another issue is that at a single switch port, there might be multiple
>> and heterogeneous cables attached at the same time. Besides, the state
>> (Attached or Detached) of each cable may alter independently.
>>
>> In order to address such issues, Android kernel's "Switch" class seems to
>> be a good basis and we have implemented "Multistate Switch Class" based on
>> it. The "Switch" class code of Android kernel is GPL as well.
>
> How does this relate to the new "pinmux" subsystem that Linus Walleij
> maintains? Would it be useful to integrate your driver into pinmux
> instead of starting a new subsystem?

Looks unrelated to pinmux but very useful.

And the uevent scheme from Arve seems like it's doing the
right thing to me, but see below on relation to <linux/input.h>.

The GPIO part has to be reviewed by Grant though.

Our charger code also needs to
know when the USB cable is inserted, currently we have a simple
cross-call in a header file:
static void ab8500_charger_usb_state_changed(u8 bm_usb_state, u16 mA);

So there is certainly a growing need of subsystems that
need to notify each other about things that are happening,
the need comes naturally from mobile ICs I think, and
I also think they all have one or another custom mechanism
in place already.

But - and now we need Dmitry to check the concepts:

Some use this stuff from <linux/input.h> to talk to userspace
though the input subsystem:

/*
 * Switch events
 */

#define SW_LID                  0x00  /* set = lid shut */
#define SW_TABLET_MODE          0x01  /* set = tablet mode */
#define SW_HEADPHONE_INSERT     0x02  /* set = inserted */
#define SW_RFKILL_ALL           0x03  /* rfkill master switch, type "any"
                                         set = radio enabled */
#define SW_RADIO                SW_RFKILL_ALL   /* deprecated */
#define SW_MICROPHONE_INSERT    0x04  /* set = inserted */
#define SW_DOCK                 0x05  /* set = plugged into dock */
#define SW_LINEOUT_INSERT       0x06  /* set = inserted */
#define SW_JACK_PHYSICAL_INSERT 0x07  /* set = mechanical switch set */
#define SW_VIDEOOUT_INSERT      0x08  /* set = inserted */
#define SW_CAMERA_LENS_COVER    0x09  /* set = lens covered */
#define SW_KEYPAD_SLIDE         0x0a  /* set = keypad slide out */
#define SW_FRONT_PROXIMITY      0x0b  /* set = front proximity sensor active */
#define SW_ROTATE_LOCK          0x0c  /* set = rotate locked/disabled */
#define SW_LINEIN_INSERT        0x0d  /* set = inserted */
#define SW_MAX                  0x0f
#define SW_CNT                  (SW_MAX+1)

These are *also* switches. You could very well add USB
cable insertion to the list above.

So for the userspace part it seems to me that we need to make
up our mind about this stuff: is it going to be through input or
uevent like in this patch? Or ?both??

Incidentally I saw a similar problem the other day, we submitted
a HWMON driver that introduced an kernel-internal event
broadcast system for when the system gets overheated etc,
it serves a similar purpose as MyungJoo's second patch
(the kernel-internal notifications), albeit someplace else.

Yours,
Linus Walleij

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Greg KH]

On Sun, Nov 27, 2011 at 11:43:39PM +0100, Linus Walleij wrote:
> Hi MyungJoo, Arnd
> 
> On Fri, Nov 25, 2011 at 3:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 24 November 2011, MyungJoo Ham wrote:
> >> For switch ports, which may have different types of cables
> >> (USB, TA, HDMI, Analog A/V, and others), we often have seperated device
> >> drivers that detect the state changes at the port and device drivers that
> >> do something according to the state changes.
> >>
> >> For example, when MAX8997-MUIC detects a Charger cable insertion, another
> >> device driver (such as MAX8903 charger, MAX8997 charger, Charger Manager,
> >> or board file) needs to set charger current limit accordingly and when
> >> MAX8997-MUIC detects a HDMI cable insertion, multimedia device drivers
> >> need to do some operations accordingly.
> >>
> >> This patchset supports the usage of notifier for passing such information
> >> between device drivers.
> >>
> >> Another issue is that at a single switch port, there might be multiple
> >> and heterogeneous cables attached at the same time. Besides, the state
> >> (Attached or Detached) of each cable may alter independently.
> >>
> >> In order to address such issues, Android kernel's "Switch" class seems to
> >> be a good basis and we have implemented "Multistate Switch Class" based on
> >> it. The "Switch" class code of Android kernel is GPL as well.
> >
> > How does this relate to the new "pinmux" subsystem that Linus Walleij
> > maintains? Would it be useful to integrate your driver into pinmux
> > instead of starting a new subsystem?
> 
> Looks unrelated to pinmux but very useful.
> 
> And the uevent scheme from Arve seems like it's doing the
> right thing to me, but see below on relation to <linux/input.h>.
> 
> The GPIO part has to be reviewed by Grant though.
> 
> Our charger code also needs to
> know when the USB cable is inserted, currently we have a simple
> cross-call in a header file:
> static void ab8500_charger_usb_state_changed(u8 bm_usb_state, u16 mA);
> 
> So there is certainly a growing need of subsystems that
> need to notify each other about things that are happening,
> the need comes naturally from mobile ICs I think, and
> I also think they all have one or another custom mechanism
> in place already.
> 
> But - and now we need Dmitry to check the concepts:
> 
> Some use this stuff from <linux/input.h> to talk to userspace
> though the input subsystem:
> 
> /*
>  * Switch events
>  */
> 
> #define SW_LID                  0x00  /* set = lid shut */
> #define SW_TABLET_MODE          0x01  /* set = tablet mode */
> #define SW_HEADPHONE_INSERT     0x02  /* set = inserted */
> #define SW_RFKILL_ALL           0x03  /* rfkill master switch, type "any"
>                                          set = radio enabled */
> #define SW_RADIO                SW_RFKILL_ALL   /* deprecated */
> #define SW_MICROPHONE_INSERT    0x04  /* set = inserted */
> #define SW_DOCK                 0x05  /* set = plugged into dock */
> #define SW_LINEOUT_INSERT       0x06  /* set = inserted */
> #define SW_JACK_PHYSICAL_INSERT 0x07  /* set = mechanical switch set */
> #define SW_VIDEOOUT_INSERT      0x08  /* set = inserted */
> #define SW_CAMERA_LENS_COVER    0x09  /* set = lens covered */
> #define SW_KEYPAD_SLIDE         0x0a  /* set = keypad slide out */
> #define SW_FRONT_PROXIMITY      0x0b  /* set = front proximity sensor active */
> #define SW_ROTATE_LOCK          0x0c  /* set = rotate locked/disabled */
> #define SW_LINEIN_INSERT        0x0d  /* set = inserted */
> #define SW_MAX                  0x0f
> #define SW_CNT                  (SW_MAX+1)
> 
> These are *also* switches. You could very well add USB
> cable insertion to the list above.
> 
> So for the userspace part it seems to me that we need to make
> up our mind about this stuff: is it going to be through input or
> uevent like in this patch? Or ?both??

Input please, uevent is not for things like switches that are "common",
but for things that are "uncommon" and don't happen often.

thanks,

greg k-h

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Dmitry Torokhov]

Greg KH <gregkh@suse.de> wrote:

>On Sun, Nov 27, 2011 at 11:43:39PM +0100, Linus Walleij wrote:
>> Hi MyungJoo, Arnd
>> 
>> On Fri, Nov 25, 2011 at 3:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Thursday 24 November 2011, MyungJoo Ham wrote:
>> >> For switch ports, which may have different types of cables
>> >> (USB, TA, HDMI, Analog A/V, and others), we often have seperated
>device
>> >> drivers that detect the state changes at the port and device
>drivers that
>> >> do something according to the state changes.
>> >>
>> >> For example, when MAX8997-MUIC detects a Charger cable insertion,
>another
>> >> device driver (such as MAX8903 charger, MAX8997 charger, Charger
>Manager,
>> >> or board file) needs to set charger current limit accordingly and
>when
>> >> MAX8997-MUIC detects a HDMI cable insertion, multimedia device
>drivers
>> >> need to do some operations accordingly.
>> >>
>> >> This patchset supports the usage of notifier for passing such
>information
>> >> between device drivers.
>> >>
>> >> Another issue is that at a single switch port, there might be
>multiple
>> >> and heterogeneous cables attached at the same time. Besides, the
>state
>> >> (Attached or Detached) of each cable may alter independently.
>> >>
>> >> In order to address such issues, Android kernel's "Switch" class
>seems to
>> >> be a good basis and we have implemented "Multistate Switch Class"
>based on
>> >> it. The "Switch" class code of Android kernel is GPL as well.
>> >
>> > How does this relate to the new "pinmux" subsystem that Linus
>Walleij
>> > maintains? Would it be useful to integrate your driver into pinmux
>> > instead of starting a new subsystem?
>> 
>> Looks unrelated to pinmux but very useful.
>> 
>> And the uevent scheme from Arve seems like it's doing the
>> right thing to me, but see below on relation to <linux/input.h>.
>> 
>> The GPIO part has to be reviewed by Grant though.
>> 
>> Our charger code also needs to
>> know when the USB cable is inserted, currently we have a simple
>> cross-call in a header file:
>> static void ab8500_charger_usb_state_changed(u8 bm_usb_state, u16
>mA);
>> 
>> So there is certainly a growing need of subsystems that
>> need to notify each other about things that are happening,
>> the need comes naturally from mobile ICs I think, and
>> I also think they all have one or another custom mechanism
>> in place already.
>> 
>> But - and now we need Dmitry to check the concepts:
>> 
>> Some use this stuff from <linux/input.h> to talk to userspace
>> though the input subsystem:
>> 
>> /*
>>  * Switch events
>>  */
>> 
>> #define SW_LID                  0x00  /* set = lid shut */
>> #define SW_TABLET_MODE          0x01  /* set = tablet mode */
>> #define SW_HEADPHONE_INSERT     0x02  /* set = inserted */
>> #define SW_RFKILL_ALL           0x03  /* rfkill master switch, type
>"any"
>>                                          set = radio enabled */
>> #define SW_RADIO                SW_RFKILL_ALL   /* deprecated */
>> #define SW_MICROPHONE_INSERT    0x04  /* set = inserted */
>> #define SW_DOCK                 0x05  /* set = plugged into dock */
>> #define SW_LINEOUT_INSERT       0x06  /* set = inserted */
>> #define SW_JACK_PHYSICAL_INSERT 0x07  /* set = mechanical switch set
>*/
>> #define SW_VIDEOOUT_INSERT      0x08  /* set = inserted */
>> #define SW_CAMERA_LENS_COVER    0x09  /* set = lens covered */
>> #define SW_KEYPAD_SLIDE         0x0a  /* set = keypad slide out */
>> #define SW_FRONT_PROXIMITY      0x0b  /* set = front proximity sensor
>active */
>> #define SW_ROTATE_LOCK          0x0c  /* set = rotate locked/disabled
>*/
>> #define SW_LINEIN_INSERT        0x0d  /* set = inserted */
>> #define SW_MAX                  0x0f
>> #define SW_CNT                  (SW_MAX+1)
>> 
>> These are *also* switches. You could very well add USB
>> cable insertion to the list above.
>> 
>> So for the userspace part it seems to me that we need to make
>> up our mind about this stuff: is it going to be through input or
>> uevent like in this patch? Or ?both??
>
>Input please, uevent is not for things like switches that are "common",
>but for things that are "uncommon" and don't happen often.

Actually, please do not. I never liked audio-related switches added to input; ALSA guys just wore me down. These are usually not switches that user can flip, they are connections between components. Should we switch betide_carrier_*(), power supply state, etc, etc over to input? I think not.

I haven't looked at the patch yet, but a class that has an attribute that could be queried and emitting uneventful on state change seems like a good diluting for me.

Thanks.

-- 
Dmitry

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Greg KH]

On Sun, Nov 27, 2011 at 04:09:19PM -0800, Dmitry Torokhov wrote:
> >> So for the userspace part it seems to me that we need to make
> >> up our mind about this stuff: is it going to be through input or
> >> uevent like in this patch? Or ?both??
> >
> >Input please, uevent is not for things like switches that are "common",
> >but for things that are "uncommon" and don't happen often.
> 
> Actually, please do not. I never liked audio-related switches added to
> input; ALSA guys just wore me down. These are usually not switches
> that user can flip, they are connections between components. Should we
> switch betide_carrier_*(), power supply state, etc, etc over to input?
> I think not.

Yes, I think so :)

Well, not all of them, but when there is a hardware change of state,
that a user can make happen (plug in headphone, plug in usb port, etc.)
they should be input events, as there are a zillion different ways to
have these types of devices.

And as HID has already documented almost all of these already, odds are,
there's already a HID mapping for what is needed to be exported, and if
not, it's easy to get a new HID code added, right?

> I haven't looked at the patch yet, but a class that has an attribute
> that could be queried and emitting uneventful on state change seems
> like a good diluting for me.

For this one case, maybe.  But what about the next one, and the next
one, and so on.  I would think those would all map better to input than
one-off class devices with custom uevent messages.

Unless we want to start piping input events through uevents?  :)

Ok, if you really don't want this, then I suggest we create something
that encompasses all of these into something unified, much like IIO is
trying to be for those types of devices.

thanks,

greg k-h

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Dmitry Torokhov]

On Mon, Nov 28, 2011 at 09:19:41AM +0900, Greg KH wrote:
> On Sun, Nov 27, 2011 at 04:09:19PM -0800, Dmitry Torokhov wrote:
> > >> So for the userspace part it seems to me that we need to make
> > >> up our mind about this stuff: is it going to be through input or
> > >> uevent like in this patch? Or ?both??
> > >
> > >Input please, uevent is not for things like switches that are "common",
> > >but for things that are "uncommon" and don't happen often.
> > 
> > Actually, please do not. I never liked audio-related switches added to
> > input; ALSA guys just wore me down. These are usually not switches
> > that user can flip, they are connections between components. Should we
> > switch betide_carrier_*(), power supply state, etc, etc over to input?
> > I think not.
> 
> Yes, I think so :)

Then we disagree here.

> 
> Well, not all of them, but when there is a hardware change of state,
> that a user can make happen (plug in headphone, plug in usb port, etc.)
> they should be input events, as there are a zillion different ways to
> have these types of devices.

I do not agree. Basically everything that happens in the system is
caused by user action somehow, somewhere.

> 
> And as HID has already documented almost all of these already, odds are,
> there's already a HID mapping for what is needed to be exported, and if
> not, it's easy to get a new HID code added, right?

Adding a new HID code is easy but not necessarily right solution. For
example, HID has reports describing battery level, but it does not mean
they should be delivered through input subsystem.

Additionally, do you really want to have full input device for
something like this? The character device; whole sysfs shebang, all the
handlers installed, etc, etc? Way too heavy IMO.

> 
> > I haven't looked at the patch yet, but a class that has an attribute
> > that could be queried and emitting uneventful on state change seems
> > like a good diluting for me.
> 
> For this one case, maybe.  But what about the next one, and the next
> one, and so on.  I would think those would all map better to input than
> one-off class devices with custom uevent messages.

I did not say I was advocating an one-off device. I was advocating a new
"connection" or "link" class that could describe relationship between 2
objects in the system.

> 
> Unless we want to start piping input events through uevents?  :)
> 
> Ok, if you really don't want this, then I suggest we create something
> that encompasses all of these into something unified, much like IIO is
> trying to be for those types of devices.

Yes, exactly. Something lightweight, even lighter than IIO since we do
not expect rapid rate of events here, so single multiplexed delivery
channel (uevents) would work well as notifiers.

-- 
Dmitry

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 6624 bytes --]

On Mon, 28 Nov 2011 08:08:36 +0900 Greg KH <gregkh@suse.de> wrote:

> On Sun, Nov 27, 2011 at 11:43:39PM +0100, Linus Walleij wrote:
> > Hi MyungJoo, Arnd
> > 
> > On Fri, Nov 25, 2011 at 3:02 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Thursday 24 November 2011, MyungJoo Ham wrote:
> > >> For switch ports, which may have different types of cables
> > >> (USB, TA, HDMI, Analog A/V, and others), we often have seperated device
> > >> drivers that detect the state changes at the port and device drivers that
> > >> do something according to the state changes.
> > >>
> > >> For example, when MAX8997-MUIC detects a Charger cable insertion, another
> > >> device driver (such as MAX8903 charger, MAX8997 charger, Charger Manager,
> > >> or board file) needs to set charger current limit accordingly and when
> > >> MAX8997-MUIC detects a HDMI cable insertion, multimedia device drivers
> > >> need to do some operations accordingly.
> > >>
> > >> This patchset supports the usage of notifier for passing such information
> > >> between device drivers.
> > >>
> > >> Another issue is that at a single switch port, there might be multiple
> > >> and heterogeneous cables attached at the same time. Besides, the state
> > >> (Attached or Detached) of each cable may alter independently.
> > >>
> > >> In order to address such issues, Android kernel's "Switch" class seems to
> > >> be a good basis and we have implemented "Multistate Switch Class" based on
> > >> it. The "Switch" class code of Android kernel is GPL as well.
> > >
> > > How does this relate to the new "pinmux" subsystem that Linus Walleij
> > > maintains? Would it be useful to integrate your driver into pinmux
> > > instead of starting a new subsystem?
> > 
> > Looks unrelated to pinmux but very useful.
> > 
> > And the uevent scheme from Arve seems like it's doing the
> > right thing to me, but see below on relation to <linux/input.h>.
> > 
> > The GPIO part has to be reviewed by Grant though.
> > 
> > Our charger code also needs to
> > know when the USB cable is inserted, currently we have a simple
> > cross-call in a header file:
> > static void ab8500_charger_usb_state_changed(u8 bm_usb_state, u16 mA);
> > 
> > So there is certainly a growing need of subsystems that
> > need to notify each other about things that are happening,
> > the need comes naturally from mobile ICs I think, and
> > I also think they all have one or another custom mechanism
> > in place already.
> > 
> > But - and now we need Dmitry to check the concepts:
> > 
> > Some use this stuff from <linux/input.h> to talk to userspace
> > though the input subsystem:
> > 
> > /*
> >  * Switch events
> >  */
> > 
> > #define SW_LID                  0x00  /* set = lid shut */
> > #define SW_TABLET_MODE          0x01  /* set = tablet mode */
> > #define SW_HEADPHONE_INSERT     0x02  /* set = inserted */
> > #define SW_RFKILL_ALL           0x03  /* rfkill master switch, type "any"
> >                                          set = radio enabled */
> > #define SW_RADIO                SW_RFKILL_ALL   /* deprecated */
> > #define SW_MICROPHONE_INSERT    0x04  /* set = inserted */
> > #define SW_DOCK                 0x05  /* set = plugged into dock */
> > #define SW_LINEOUT_INSERT       0x06  /* set = inserted */
> > #define SW_JACK_PHYSICAL_INSERT 0x07  /* set = mechanical switch set */
> > #define SW_VIDEOOUT_INSERT      0x08  /* set = inserted */
> > #define SW_CAMERA_LENS_COVER    0x09  /* set = lens covered */
> > #define SW_KEYPAD_SLIDE         0x0a  /* set = keypad slide out */
> > #define SW_FRONT_PROXIMITY      0x0b  /* set = front proximity sensor active */
> > #define SW_ROTATE_LOCK          0x0c  /* set = rotate locked/disabled */
> > #define SW_LINEIN_INSERT        0x0d  /* set = inserted */
> > #define SW_MAX                  0x0f
> > #define SW_CNT                  (SW_MAX+1)
> > 
> > These are *also* switches. You could very well add USB
> > cable insertion to the list above.
> > 
> > So for the userspace part it seems to me that we need to make
> > up our mind about this stuff: is it going to be through input or
> > uevent like in this patch? Or ?both??
> 
> Input please, uevent is not for things like switches that are "common",
> but for things that are "uncommon" and don't happen often.

Hi Greg,

 I don't find that argument at all convincing.  "common" is not an objective
 measure that we can all see the same way, and I don't even think it is
 relevant.

 Consider the difference between plugging in a USB-headphone set and an
 analogue mini-phone headphone set.  To the user they are the same thing.
 They should be assumed to be as common as each other.  Yet plugging in the
 USB headphone set will create a new Audio device while and so generate a
 uevent, while plugging in the analogue headset (currently) won't and will
 just send an input event.

 So they are different, not because of expected usage but simply because of
 internal implementation details.

 I think you could make a case that plugging in an analogue headset is in
 fact adding a new audio device (or enabling one that was present but
 inactive) and so deserves a uevent.
 Similarly plugging in a USB-charge makes a significant capability-change to
 the usb-gadget device so an 'change' uevent seems appropriate.

 If a switch enables or disables a device, then the state-change of the
 switch itself doesn't deserve a uevent, but the device that it
 enables/disables/changes-capability-of does.

 How the signal gets from the switch to the device when they are separate
 things is less clear, and I think it is the main focus of the proposed patch.

 Input might be a suitable vehicle for switch signalling, but if it was I
 would argue against trying to list every possible switch with its own switch
 code.  Rather there should be a generic 'SW_SWITCH' and different input
 devices each had a single switch but each did different things.  So an
 action would not be guided by the name of the switch event, but by the name
 of the device that the switch event came from.

 My own thought is that this deserves a new device class which allows easy
 hook-up of in-kernel signalling using notifications and which can be
 exported as input devices in much the same way the 'gpio' devices can be
 exported via gpio_keys.  The switch could also optionally be exported through
 sysfs much like gpio can be exported through sysfs.

 So I think I agree with your conclusion, but not with your argument :-)

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Greg KH]

On Mon, Nov 28, 2011 at 12:31:14PM +1100, NeilBrown wrote:
> 
>  My own thought is that this deserves a new device class which allows easy
>  hook-up of in-kernel signalling using notifications and which can be
>  exported as input devices in much the same way the 'gpio' devices can be
>  exported via gpio_keys.  The switch could also optionally be exported through
>  sysfs much like gpio can be exported through sysfs.

That might also work, but again, odds are the HID spec already defines
this type of "switch", so why recreate it as a different type of device?

>  So I think I agree with your conclusion, but not with your argument :-)

Heh, nice :)

greg k-h

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Dmitry Torokhov]

On Mon, Nov 28, 2011 at 04:27:13PM +0900, Greg KH wrote:
> On Mon, Nov 28, 2011 at 12:31:14PM +1100, NeilBrown wrote:
> > 
> >  My own thought is that this deserves a new device class which allows easy
> >  hook-up of in-kernel signalling using notifications and which can be
> >  exported as input devices in much the same way the 'gpio' devices can be
> >  exported via gpio_keys.  The switch could also optionally be exported through
> >  sysfs much like gpio can be exported through sysfs.
> 
> That might also work, but again, odds are the HID spec already defines
> this type of "switch", so why recreate it as a different type of device?

HID does not map 1:1 on input. There are items in HID that are better
served by other subsystems.

-- 
Dmitry

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Greg KH]

On Mon, Nov 28, 2011 at 01:04:46AM -0800, Dmitry Torokhov wrote:
> On Mon, Nov 28, 2011 at 04:27:13PM +0900, Greg KH wrote:
> > On Mon, Nov 28, 2011 at 12:31:14PM +1100, NeilBrown wrote:
> > > 
> > >  My own thought is that this deserves a new device class which allows easy
> > >  hook-up of in-kernel signalling using notifications and which can be
> > >  exported as input devices in much the same way the 'gpio' devices can be
> > >  exported via gpio_keys.  The switch could also optionally be exported through
> > >  sysfs much like gpio can be exported through sysfs.
> > 
> > That might also work, but again, odds are the HID spec already defines
> > this type of "switch", so why recreate it as a different type of device?
> 
> HID does not map 1:1 on input. There are items in HID that are better
> served by other subsystems.

Ok fair enough.

So, how do you want this type of interface to look like, uevents only?

Or something like gpio?

Actually, why can't we just use gpio as-is here and just treat these
devices as "generic" i/o "pins"?

thanks,

greg k-h

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[MyungJoo Ham]

On Wed, Nov 30, 2011 at 3:35 PM, Greg KH <gregkh@suse.de> wrote:
> On Mon, Nov 28, 2011 at 01:04:46AM -0800, Dmitry Torokhov wrote:
>> On Mon, Nov 28, 2011 at 04:27:13PM +0900, Greg KH wrote:
>> > On Mon, Nov 28, 2011 at 12:31:14PM +1100, NeilBrown wrote:
>> > >
>> > >  My own thought is that this deserves a new device class which allows easy
>> > >  hook-up of in-kernel signalling using notifications and which can be
>> > >  exported as input devices in much the same way the 'gpio' devices can be
>> > >  exported via gpio_keys.  The switch could also optionally be exported through
>> > >  sysfs much like gpio can be exported through sysfs.
>> >
>> > That might also work, but again, odds are the HID spec already defines
>> > this type of "switch", so why recreate it as a different type of device?
>>
>> HID does not map 1:1 on input. There are items in HID that are better
>> served by other subsystems.
>
> Ok fair enough.
>
> So, how do you want this type of interface to look like, uevents only?
>
> Or something like gpio?
>
> Actually, why can't we just use gpio as-is here and just treat these
> devices as "generic" i/o "pins"?
>
> thanks,
>
> greg k-h

For userspace, GPIO should work.

For device drivers, I'm not sure.

In order to work for device drives, a GPIO event (GPIO Input goes L->H
or H->L) should trigger events in other device drivers. The GPIO value
can be set by the external-connector/multistate-switch driver
(notifier) based on its own interrupts.

Then, with a GPIO X representing the one status of many at a notifier,
a notifier device can set L/H value of GPIO X according to the cable
state based on the interrupts from the port. However, for a device
(charger, hdmi, sound, or anything) being connected to that cable, how
does it get the changed state without polling? Are we generating an
interrupt of GPIO X at the interrupt handler of the notifier?

Assuming that it is possible, this means that each cable status is fed
to only one callback via IRQ subsystem unlike the notifier chain that
allows multiple callbacks registered. Another concern is that this
method may create a lengthy interrupt handling context where we could
use simple notifier chains. The work struct at the interrupt handler
of switch device (notifier) will now invoking a series of interrupts
instead of calling notify.

- We need uevent + notify-chain.


Cheers!
MyungJoo
-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Mark Brown]

On Wed, Nov 30, 2011 at 03:58:54PM +0900, MyungJoo Ham wrote:
> On Wed, Nov 30, 2011 at 3:35 PM, Greg KH <gregkh@suse.de> wrote:

> > Actually, why can't we just use gpio as-is here and just treat these
> > devices as "generic" i/o "pins"?

> For userspace, GPIO should work.

> For device drivers, I'm not sure.

> In order to work for device drives, a GPIO event (GPIO Input goes L->H
> or H->L) should trigger events in other device drivers. The GPIO value
> can be set by the external-connector/multistate-switch driver
> (notifier) based on its own interrupts.

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

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Linus Walleij]

On Wed, Nov 30, 2011 at 7:35 AM, Greg KH <gregkh@suse.de> wrote:

> So, how do you want this type of interface to look like, uevents only?
>
> Or something like gpio?
>
> Actually, why can't we just use gpio as-is here and just treat these
> devices as "generic" i/o "pins"?

For device drivers we have the issue that the management of
the GPIO pin-space give me the creeps. It is simple when things
are simple and then ugly things have start to happen, such
as dynamically bumping the GPIO pin range and associated
IRQ range at compile time using unreadable nested macros.
You roof the space at some arbitrary number at compile-time
in ARCH_NR_GPIOS and if you don't define it,
<asm-generic/gpio.h> will helpfully define that your system
has 256 GPIO pins.

The effect of the above on unified cross-ARM-arch kernels is
confusing as the meaning of the GPIO pinspace will
shift at runtime depending on what system it's running on.

A new subsystem could allocate switch/pin/line assignments
dynamically which is way more viable. (And how we chose to
do in in pinctrl.)

For userspace several people, notably the GPIOlib subsystem
maintainer Grant, expressed concerns about the sysfs interface
to GPIO. So I would not shoehorn new stuff in there, solidifying
it even more.

So I would recommend doing this as a new subsystem to save
us from trouble. There is more to be gained from splitting things
apart than keeping them together in this case IMO.

Yours,
Linus Walleij

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2830 bytes --]

On Wed, 30 Nov 2011 14:28:36 +0100 Linus Walleij <linus.walleij@linaro.org>
wrote:

> On Wed, Nov 30, 2011 at 7:35 AM, Greg KH <gregkh@suse.de> wrote:
> 
> > So, how do you want this type of interface to look like, uevents only?
> >
> > Or something like gpio?
> >
> > Actually, why can't we just use gpio as-is here and just treat these
> > devices as "generic" i/o "pins"?
> 
> For device drivers we have the issue that the management of
> the GPIO pin-space give me the creeps. It is simple when things
> are simple and then ugly things have start to happen, such
> as dynamically bumping the GPIO pin range and associated
> IRQ range at compile time using unreadable nested macros.
> You roof the space at some arbitrary number at compile-time
> in ARCH_NR_GPIOS and if you don't define it,
> <asm-generic/gpio.h> will helpfully define that your system
> has 256 GPIO pins.
> 
> The effect of the above on unified cross-ARM-arch kernels is
> confusing as the meaning of the GPIO pinspace will
> shift at runtime depending on what system it's running on.
> 
> A new subsystem could allocate switch/pin/line assignments
> dynamically which is way more viable. (And how we chose to
> do in in pinctrl.)
> 
> For userspace several people, notably the GPIOlib subsystem
> maintainer Grant, expressed concerns about the sysfs interface
> to GPIO. So I would not shoehorn new stuff in there, solidifying
> it even more.
> 
> So I would recommend doing this as a new subsystem to save
> us from trouble. There is more to be gained from splitting things
> apart than keeping them together in this case IMO.

I certainly agree that if the GPIO interface causes problem we should be very
careful about extending the use of it.
However I think it would be wrong to simply make something that is different
just for the sake of being different. I will probably introduce a different
set of problems of its own.

Do you know what it is about the sysfs-gpio interface that is problematic?
If it is just one aspect, maybe that can be avoided and the rest still used.

For example, I note that most GPIO pins that are exported via sysfs are
exported by number.  This is problematic exactly as you have described
above.  Numbers change.
However it is quite possible to export GPIO pins by assigning a name.  Doing
this would remove the problem.  We don't need to assign a name to every gpio
pin, just the ones that we want to export to user-space.

If this was the only issue, we could require that when exporting 'switches'
through sysfs it was only done if a name was supplied.

So: do you know what specific concerns have been expressed concerning gpio
and userspace?  I think it best to address specific concern rather than throw
it all out and start again.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Linus Walleij]

On Thu, Dec 1, 2011 at 12:04 AM, NeilBrown <neilb@suse.de> wrote:

> So: do you know what specific concerns have been expressed concerning gpio
> and userspace?  I think it best to address specific concern rather than throw
> it all out and start again.

No but I have these generic statements from Grant, so it's a bit like the
Delphic oracle giving some advice of the type "don't go there":

[Grant Likely about pinctrl:]
>> https://lkml.org/lkml/2011/9/30/260
>> I'm not convinced that the sysfs approach is
>> actually the right interface here (I'm certainly not a fan of the gpio
>> sysfs i/f), and I'd rather not be putting in unneeded stuff until the
>> userspace i/f is hammered out.
(...)
>> https://lkml.org/lkml/2011/10/4/366
>> I don't want to be in the situation we are now with GPIO,
>> where every time I look at the sysfs interface I shudder.

I am sure he will be able to expand on this when he
gets back on monday.

Yours,
Linus Walleij

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Linus Walleij]

On Mon, Nov 28, 2011 at 8:27 AM, Greg KH <gregkh@suse.de> wrote:
> On Mon, Nov 28, 2011 at 12:31:14PM +1100, NeilBrown wrote:
>>
>>  My own thought is that this deserves a new device class which allows easy
>>  hook-up of in-kernel signalling using notifications and which can be
>>  exported as input devices in much the same way the 'gpio' devices can be
>>  exported via gpio_keys.  The switch could also optionally be exported through
>>  sysfs much like gpio can be exported through sysfs.
>
> That might also work, but again, odds are the HID spec already defines
> this type of "switch", so why recreate it as a different type of device?

I think both yes and no, but I will stand corrected.

When you plug it into a host, I guess your device will
negotiate power withdrawal from the host as anything else,
no matter what device or interface classes it presents.

However in the other case I am under the impression that
devices supporting EPS
http://en.wikipedia.org/wiki/Common_External_Power_Supply
Or the "battery charging specification"
http://www.usb.org/developers/devclass_docs/batt_charging_1_1.zip
do so in their Phy transceiver drivers, say e.g.
drivers/usb/otg/ab8500-usb.c in our case. This is sometime
called a "chinese charger" or "dedicated charger". It's just
appearing on the micro-USB port, it doesn't enumerate and
the OS driver does not talk to it. I think it notifies the transceiver
by short-circuiting D+ and D- and the transceiver/phy
driver may in many cases notify charging circuitry and
userspace that it's been plugged in (switch uevent,
cable insertion input event or whatever we come up with).

So no, I don't think HID defines this, it's defined in a
physical layer spec, and the interfaces to OS:es are
transciever/phy-custom.

I've CC:ed Morten who was part of writing the charging
spec so he can correct me if I'm saying the wrong thing.

Yours,
Linus Walleij

RE: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Morten CHRISTIANSEN]

Hello!

Linus is correct. However some more info might be useful? Feel free to drop off whenever in the more and more detailed explanations! This is a non-trivial issue that has had some effort spent on it already.

SUMMARY: Devices today charge at high current (1.5A) from a dedicated charger and 500mA max from a standard USB port, using the standard MaxPower parameter. It would have been great if devices could also charge at higher current from a host or hub port but that is not really practical due to HW issues, not SW issues. See below. A new USB Power Delivery spec is imminent that might be of interest?

SHORT VERSION OF PREVIOUS EFFORTS:
Using HID for managing USB battery charging current from the host is indeed the correct approach. And a work effort in USB Device Working Group went all the way to "ready for publication" state - and then died (for a number of reasons) some years ago. (Due to IPR reasons I cannot forward the un-released version of the spec.)

I see no reason to revisit the HID approach since it will not get any device support. Even if it was the correct approach.

USB POWER DELIVERY:
Currently there is an ongoing effort for USB power delivery, this might be relevant and useful even if it also allows much higher voltage than 5V. The industry review of the preliminary spec has happened and the spec should be public in a few months.  

http://www.usb.org/press/USB_Power_Delivery_Specification.pdf for press release 

and further details from IDF 2011:
https://intel.wingateweb.com/us11/scheduler/download/download.jsp?E4B2973BCDE53502BEFEB912D75B8DA8=A6B62020AAED1E8D4EDE0D1DA89C386D&B74A4263B8A60B9174A0CE5F9461219F=8BC9EC1D19D07830717163157D635C00


LONGER VERSION: 
The really simplified explanation of the battery charger spec states that a dedicated charger port has D+ and D- short-circuited. The device can detect this and charge at any current up to 1.5A. No enumeration, no traffic etc. And no USB host in the charger! As some originally proposed. Note that other versions of modifying D+/D- in a charger exists, notably in Apple chargers but this is out of scope for this discussion. And obviously all of this is handled in the lower level USB stack down at the physical driver level as there is no point in sending this info further "up" into the SW stack in the device since the charger app is already handling this. Regardless of device OS used.  

In order to charge at higher current from a host (or hub) port a different mechanism is used to detect charging capability without killing USB traffic - something that shorting D+/D- usually does! In practice the device sends a low level pulse on D+ and the host answers with a similar pulse on D-. Giving the device the indication that D+/D- are shorted. While still allowing USB traffic after the initial charger detection has taken place. 

However there are very few if any host ports that support this. And even if a few hub chips have been launched this has not caught on. One problem with the host port is that the user expects that all ports will allow higher current charging. The hub's problem is to ensure that a 7-8A power supply instead of the standard 2.5A power supply is connected. And why would people want to pay extra for this hub capability anyway? Same applies to the host; the host will have to upgrade the 3-4 USB ports from 500mA each to 1.5A each. Not nice! And it will also have to continue to supply 5-6A on the 5V Vbus power supply when in standby since once a port has been detected as a charger port the charger capability cannot be revoked unless Vbus is removed, killing the device etc. And not allowing the power supply to meet the standby current requirements that now apply at least in the European Union. 

So the approach with new commands (using HID) to allow the host to read battery status on each device and intelligently decide which port - if any - and at any time - has higher current capability than the standard 500mA - and even programmable 500 - 1500mA current - is indeed the right approach. But "dead" as briefly described above.

I can provide more information if needed. But would advise you to follow up on the USB power delivery specification effort first.

BR Morten Christiansen, Siv.Ing
Principal System Designer, Datacom USB
ST-Ericsson R&D Grimstad, Norway

-----Original Message-----
From: Linus Walleij [mailto:linus.walleij@linaro.org] 
Sent: 28. november 2011 14:04
To: Greg KH
Cc: NeilBrown; Arnd Bergmann; myungjoo.ham@gmail.com; linux-kernel@vger.kernel.org; Mike Lockwood; Arve Hjønnevåg; Kyungmin Park; Donggeun Kim; Grant Likely; Karl KOMIEROWSKI; Johan BJORNSTEDT; Daniel WILLERUD; Dmitry Torokhov; Mian Yousaf KAUKAB; Morten CHRISTIANSEN
Subject: Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

On Mon, Nov 28, 2011 at 8:27 AM, Greg KH <gregkh@suse.de> wrote:
> On Mon, Nov 28, 2011 at 12:31:14PM +1100, NeilBrown wrote:
>>
>>  My own thought is that this deserves a new device class which allows 
>> easy
>>  hook-up of in-kernel signalling using notifications and which can be
>>  exported as input devices in much the same way the 'gpio' devices 
>> can be
>>  exported via gpio_keys.  The switch could also optionally be 
>> exported through
>>  sysfs much like gpio can be exported through sysfs.
>
> That might also work, but again, odds are the HID spec already defines 
> this type of "switch", so why recreate it as a different type of device?

I think both yes and no, but I will stand corrected.

When you plug it into a host, I guess your device will negotiate power withdrawal from the host as anything else, no matter what device or interface classes it presents.

However in the other case I am under the impression that devices supporting EPS http://en.wikipedia.org/wiki/Common_External_Power_Supply
Or the "battery charging specification"
http://www.usb.org/developers/devclass_docs/batt_charging_1_1.zip
do so in their Phy transceiver drivers, say e.g.
drivers/usb/otg/ab8500-usb.c in our case. This is sometime called a "chinese charger" or "dedicated charger". It's just appearing on the micro-USB port, it doesn't enumerate and the OS driver does not talk to it. I think it notifies the transceiver by short-circuiting D+ and D- and the transceiver/phy driver may in many cases notify charging circuitry and userspace that it's been plugged in (switch uevent, cable insertion input event or whatever we come up with).

So no, I don't think HID defines this, it's defined in a physical layer spec, and the interfaces to OS:es are transciever/phy-custom.

I've CC:ed Morten who was part of writing the charging spec so he can correct me if I'm saying the wrong thing.

Yours,
Linus Walleij

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Greg KH]

On Mon, Nov 28, 2011 at 04:09:47PM +0100, Morten CHRISTIANSEN wrote:
> Hello!
> 
> Linus is correct. However some more info might be useful? Feel free to drop off whenever in the more and more detailed explanations! This is a non-trivial issue that has had some effort spent on it already.
> 
> SUMMARY: Devices today charge at high current (1.5A) from a dedicated charger and 500mA max from a standard USB port, using the standard MaxPower parameter. It would have been great if devices could also charge at higher current from a host or hub port but that is not really practical due to HW issues, not SW issues. See below. A new USB Power Delivery spec is imminent that might be of interest?
> 
> SHORT VERSION OF PREVIOUS EFFORTS:
> Using HID for managing USB battery charging current from the host is indeed the correct approach. And a work effort in USB Device Working Group went all the way to "ready for publication" state - and then died (for a number of reasons) some years ago. (Due to IPR reasons I cannot forward the un-released version of the spec.)
> 
> I see no reason to revisit the HID approach since it will not get any device support. Even if it was the correct approach.

<snip>

thanks a lot for the information, it was very helpful.

greg k-h

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Arnd Bergmann]

On Sunday 27 November 2011, Linus Walleij wrote:
> > How does this relate to the new "pinmux" subsystem that Linus Walleij
> > maintains? Would it be useful to integrate your driver into pinmux
> > instead of starting a new subsystem?
> 
> Looks unrelated to pinmux but very useful.

Ok, got it. So while pinmux controls the setting of some pins, this one
generates software events when the state is changed from the outside.

	Arnd

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[MyungJoo Ham]

On Tue, Nov 29, 2011 at 2:53 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 27 November 2011, Linus Walleij wrote:
>> > How does this relate to the new "pinmux" subsystem that Linus Walleij
>> > maintains? Would it be useful to integrate your driver into pinmux
>> > instead of starting a new subsystem?
>>
>> Looks unrelated to pinmux but very useful.
>
> Ok, got it. So while pinmux controls the setting of some pins, this one
> generates software events when the state is changed from the outside.

For pinmux:
Besides, pinmux does not support multistate-muxing (you cannot set a
gpio pin to have multiple states at the same time) and focusses on
setting pins (device drivers set the GPIO pin configurations). The
target devices of multistate switch class (MSC) do not (actually,
cannot) control the setting of the switch proactively; it is done by
the physical hands of users (plugging in or out external cables). The
target device drivers (MSClass device driver) update switch_dev
information only when the cable states are changed by users.

For USB:
MSC is not for USB only. USB is just one of example cables. This needs
to support HDMI, Analog A/V I/O, Dock, and any other that may be
connected to a computer. (simply a "string" to MSC anyway)

For HID:
MSC is a simple notifier chain provider to provide bridges between
external-port-drivers and other notifiee device drivers and uevent
generator for external-port-drivers.
I'm a bit confused on using HID for the purpose.
Anyway, doesn't this mean that every device driver that gets
notifications from the external-port-drivers also need to be an HID
device? That'd mean that USB(either host/slave) drivers, Charger
drivers, Sound drivers, Video drivers, HDMI drivers, and many others
need to support HID in order to get this simple "plugged-in"
notification.



The target devices include (supported cable lists are not complete):
MAX8997 MUIC: a multi-pin port that may inhabit multiple cables (some
may mutually exclusive) including USB-HOST, USB, Travel Adaptor, HDMI,
Analog Audio / Video x Input / Output, Dock, and others.
FSA9480 USB Switch: USB / Travel Adaptor / HDMI / ...
MAX77693 (base driver soon to be released): same with if not more than
MAX8997 MUIC

We are notifying the changes in the states from MSC to both device
drivers (Charger, USB, Sound, Video, ...) and user spaces
(applications monitoring the cable insertion/removal).



For the next iteration, I'm considering the followings. It'd be much
appreciated if I could get some comments about those beforehand.
1. ABI documentation
2. move the location from /drivers/misc to an independent location.
/drivers/switch? /drivers/multistate-switch? /drivers/msc?
/drivers/mswitch? ...
3. Allow the notifiee device drivers to register its specific
interest. The interface would look like:
int switch_register_interest(struct switch_dev *sdev, const char
*cable_name, struct notifier_block *b);
(the rationale is that the notifiee device does not need to know the
detail about the switch dev configuration but for the name of the
switch dev or notifier).
or even
int switch_register_interest(const char *switch_name, const char
*cable_name, struct notifier_block *b);
and allow notifee to forget about the sdev pointer as well. (and all
the other APIs are for implementing notifier, not notifiee)


Cheers!

MyungJoo

-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Linus Walleij]

On Tue, Nov 29, 2011 at 10:11 AM, MyungJoo Ham <myungjoo.ham@gmail.com> wrote:

> For the next iteration, I'm considering the followings. It'd be much
> appreciated if I could get some comments about those beforehand.
> 1. ABI documentation

Good!

> 2. move the location from /drivers/misc to an independent location.
> /drivers/switch? /drivers/multistate-switch? /drivers/msc?
> /drivers/mswitch? ...

drivers/switch if I have my say. It looks intuitive.

> 3. Allow the notifiee device drivers to register its specific
> interest. The interface would look like:
> int switch_register_interest(struct switch_dev *sdev, const char
> *cable_name, struct notifier_block *b);
> (the rationale is that the notifiee device does not need to know the
> detail about the switch dev configuration but for the name of the
> switch dev or notifier).
> or even
> int switch_register_interest(const char *switch_name, const char
> *cable_name, struct notifier_block *b);
> and allow notifee to forget about the sdev pointer as well. (and all
> the other APIs are for implementing notifier, not notifiee)

Good.

I will likely ack this once the code looks real nice, FWIW.

Yours,
Linus Walleij

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Arnd Bergmann]

On Tuesday 29 November 2011, MyungJoo Ham wrote:
> For the next iteration, I'm considering the followings. It'd be much
> appreciated if I could get some comments about those beforehand.
>
> 2. move the location from /drivers/misc to an independent location.
> /drivers/switch? /drivers/multistate-switch? /drivers/msc?
> /drivers/mswitch? ...

Moving out of drivers/misc is a good idea. I don't have a strong
preference for any of the alternatives, but would probably pick
drivers/mswitch. drivers/switch is too generic, since we have lots
of things that are called a switch already, and drivers/multistate-switch
is much longer than any of the other alternatives. "msc" in turn
seems a bit too short and is not a well-established acronym yet.

	Arnd

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Dmitry Torokhov]

On Tue, Nov 29, 2011 at 01:59:58PM +0000, Arnd Bergmann wrote:
> On Tuesday 29 November 2011, MyungJoo Ham wrote:
> > For the next iteration, I'm considering the followings. It'd be much
> > appreciated if I could get some comments about those beforehand.
> >
> > 2. move the location from /drivers/misc to an independent location.
> > /drivers/switch? /drivers/multistate-switch? /drivers/msc?
> > /drivers/mswitch? ...
> 
> Moving out of drivers/misc is a good idea. I don't have a strong
> preference for any of the alternatives, but would probably pick
> drivers/mswitch. drivers/switch is too generic, since we have lots
> of things that are called a switch already, and drivers/multistate-switch
> is much longer than any of the other alternatives. "msc" in turn
> seems a bit too short and is not a well-established acronym yet.

It does not really limited to switches I think. Plug? Interconnect
(connector is already taken)? Link?

Thanks.

-- 
Dmitry

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]

On Tue, 29 Nov 2011 18:11:02 +0900 MyungJoo Ham <myungjoo.ham@gmail.com>
wrote:

> 3. Allow the notifiee device drivers to register its specific
> interest. The interface would look like:
> int switch_register_interest(struct switch_dev *sdev, const char
> *cable_name, struct notifier_block *b);
> (the rationale is that the notifiee device does not need to know the
> detail about the switch dev configuration but for the name of the
> switch dev or notifier).
> or even
> int switch_register_interest(const char *switch_name, const char
> *cable_name, struct notifier_block *b);
> and allow notifee to forget about the sdev pointer as well. (and all
> the other APIs are for implementing notifier, not notifiee)

I'm surprised to find "cable_name" in there.  It is saying that multi-switch
is always used for cable-plug events.  If that is the case, then maybe the
name "multiswitch" is too generic.  Maybe this is a "cabledetect" function??

I'm wondering if a switch should be something much simpler - not even a
'device' necessarily.  Maybe it is more like a resource, like gpio or irq or
pwm or region or clock or ...

So each switch on a given board is identified by a number and any code that
wants to know about switch events needs to be given the magic number somehow
(in platform_data?) and does
  request_switch(switch_number)
  switch_register_interest(switch_number, notifier_block)

I don't know exactly how your "cable_name" would fit.  Does that just
identify the particular value that the switch has?  In that case
switch_callback could have an optional 'value' so the call back only happens
when the switch is set to that value (or set from that value).

If you need to make it appear in sysfs, write "switch_export" based on
"gpio_export".
If you want the switch to generate input events, write switch_keys based on
gpio_keys.

I guess my point is that a "switch" - even a "multiswitch" - is an extremely
generic concept and imposing too much semantics on all switches would be a
mistake.



On reflection... I think you said that a switch could have a bit-map of up to
32 bits with each bit representing a different cable type, and multiple
cables can be plugged in at the same time - is that correct?
If so, then why not just have multiple switches, one for each cable type.
The thing that detects the cables could then register a "switchchip" (like
gpiochip) that supports a number of switches all handled by the same code.  A
client would just register_interest with the individual switches that it
cares about - i.e. the individual cable(s).

Though I might have misunderstood something.

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[MyungJoo Ham]

On Wed, Nov 30, 2011 at 11:58 AM, NeilBrown <neilb@suse.de> wrote:
> On Tue, 29 Nov 2011 18:11:02 +0900 MyungJoo Ham <myungjoo.ham@gmail.com>
> wrote:
>
>> 3. Allow the notifiee device drivers to register its specific
>> interest. The interface would look like:
>> int switch_register_interest(struct switch_dev *sdev, const char
>> *cable_name, struct notifier_block *b);
>> (the rationale is that the notifiee device does not need to know the
>> detail about the switch dev configuration but for the name of the
>> switch dev or notifier).
>> or even
>> int switch_register_interest(const char *switch_name, const char
>> *cable_name, struct notifier_block *b);
>> and allow notifee to forget about the sdev pointer as well. (and all
>> the other APIs are for implementing notifier, not notifiee)
>
> I'm surprised to find "cable_name" in there.  It is saying that multi-switch
> is always used for cable-plug events.  If that is the case, then maybe the
> name "multiswitch" is too generic.  Maybe this is a "cabledetect" function??

Hmm.. then, would ("switch_name" and "node_name") or ("extcon_name"
and "cable_name") be better?
(extcon: external connect, which is the name I'm considering for now)

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.

>
> I'm wondering if a switch should be something much simpler - not even a
> 'device' necessarily.  Maybe it is more like a resource, like gpio or irq or
> pwm or region or clock or ...

If we take the approach of GPIO or IRQ, providing a unique number for
each possible cable, we need to define the numbers at a board file
(bsp), device tree, or with some other mechanisms and pass the numbers
to notifiers (extcon/switch devices) and notifiees (devices using the
cable).

However, unlike GPIO or IRQ, we have more information available at
each node. A "Samsung Slate Dock" notifiee device driver will always
get notified via "Dock" cable of a given
extcon/multistate-switch-class device (notifier, "PortX"). I'm not
sure whether we need to make "Samsung Slate Dock" device driver to use
node "15" and let some other part in kernel define "15" as a "Dock"
cable of a multistate switch device "PortX".

In other words, for GPIO or IRQ, for a device driver X in coding time,
we don't know whether X will be using which "node" of a GPIO-chip or
IRQ-chip. However, for extcon/multistate-switch, we generally know
which "cable/node" of a extcon/multistate-switch device although we
don't know which extcon/multistate-switch device will be used.

Anyway, having no standard naming convention for cables is a obstruct
for that purpose. E.g., every "Dock" device drivers need to use the
cable name "Dock" to be supported. Thus, adding a suggested name list
could be done in the next iteration.

>
> So each switch on a given board is identified by a number and any code that
> wants to know about switch events needs to be given the magic number somehow
> (in platform_data?) and does
>  request_switch(switch_number)
>  switch_register_interest(switch_number, notifier_block)
>
> I don't know exactly how your "cable_name" would fit.  Does that just
> identify the particular value that the switch has?  In that case
> switch_callback could have an optional 'value' so the call back only happens
> when the switch is set to that value (or set from that value).
>
> If you need to make it appear in sysfs, write "switch_export" based on
> "gpio_export".
> If you want the switch to generate input events, write switch_keys based on
> gpio_keys.
>
> I guess my point is that a "switch" - even a "multiswitch" - is an extremely
> generic concept and imposing too much semantics on all switches would be a
> mistake.
>
>
>
> On reflection... I think you said that a switch could have a bit-map of up to
> 32 bits with each bit representing a different cable type, and multiple
> cables can be plugged in at the same time - is that correct?

Yes, correct.

> If so, then why not just have multiple switches, one for each cable type.

Not one for each cable type, One for each cable type and port. We may
have the same cable type attached to multiple different external
ports.
(one external port = one "switch_dev" object = cable detector)

> The thing that detects the cables could then register a "switchchip" (like
> gpiochip) that supports a number of switches all handled by the same code.  A
> client would just register_interest with the individual switches that it
> cares about - i.e. the individual cable(s).
>
> Though I might have misunderstood something.
>
> NeilBrown


Because an instance of "Cable-X's IO" device shoudl be able to
distinguish whether it is attached to a "Cable-X" of switch (or
extcon) "MAX8997-MUIC.0" or "MAX8997-MUIC.1", it seems that providing
a unique name for each cable type may make things more complex for
device drivers. By seperating the names of switch/extcon and
cable/port/node, we can implement device drivers of notifiers
(representing switch/extcon) and notifiees (handling or using
cable/port/node) may keep "cable name" constantly in their device
driver code: "MHL" device driver will use cable "MHL", "USB Host"
device driver will use cable "USB Host", and so on. We only need to
configure which device is waiting to be connected to which
extcon/switch with platform data: e.g., a device "mhl.0" is being
connected to "max8997-muic.0", a device "charger-manager.0" is being
connected to "max8997-muic.1".

Although I'm implementing with devices that have only one "extcon" for
now, I guess it'd better to assume that I'll start working on devices
with two or more soon.


-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On Wed, 30 Nov 2011 15:40:48 +0900 MyungJoo Ham <myungjoo.ham@gmail.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.

Hi,
 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.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Mark Brown]

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@gmail.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.

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Dmitry Torokhov]

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@gmail.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.

-- 
Dmitry

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[MyungJoo Ham]

On Thu, Dec 1, 2011 at 8:25 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.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@gmail.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.
>

Yes, we can implement that way.

However, the "mux" device (e.g., MAX8997 MUIC / MAX77693 / FSA9480 /
... / and some multipurpose earphone jacks maybe? ) still needs to
have one device driver to represent the physical jack; it has one IRQ,
one set of power controls, and one set of registers for all of these
connectors.


Cheers!
MyungJoo

> --
> Dmitry



-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 6136 bytes --]

On Wed, 30 Nov 2011 15:25:29 -0800 Dmitry Torokhov
<dmitry.torokhov@gmail.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@gmail.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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Mark Brown]

On Thu, Dec 01, 2011 at 04:21:44PM +1100, NeilBrown wrote:
> On Wed, 30 Nov 2011 15:25:29 -0800 Dmitry Torokhov

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

It's useful to userspace to know that the grouping is there, and it's
also useful to be able to say that the overall object that was inserted
into the connector is whatever.  That could be done by grouping a bunch
of other objects together.

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

Being able to provide useful default behaviour is an important win in
itself, and in many embedded cases the end user has no access to this
sort of policy anyway (consider smartphones and tablets).  You can
probably do much better than you suggest above - for example, if the
device connected is an AV cable then it's more likely that you want to
treat it as a block to be routed together than if the device connected
is a docking station.  You might also choose to do things like
remembering the configurations used with particular cables and restoring
them when reconnected - for example, distinguishing between a car dock
and a desktop docking station.

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

This is the sort of device that MyungJoo is taking about in a lot of his
examples.

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

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.

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

I *think* so.

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

Common parents often don't exist - it's not unusual for multiple devices
to be involved in the detection of accessories.  Assuming a straight
tree structure is very dangerous in the embedded context.  Board
assigned naming does seem reasonable to me, though.

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

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.

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 13674 bytes --]

On Thu, 1 Dec 2011 11:34:50 +0000 Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:

> On Thu, Dec 01, 2011 at 04:21:44PM +1100, NeilBrown wrote:
> > On Wed, 30 Nov 2011 15:25:29 -0800 Dmitry Torokhov
> 
> > > 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?
> 
> It's useful to userspace to know that the grouping is there, and it's
> also useful to be able to say that the overall object that was inserted
> into the connector is whatever.  That could be done by grouping a bunch
> of other objects together.
> 
> > 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?
> 
> Being able to provide useful default behaviour is an important win in
> itself, and in many embedded cases the end user has no access to this
> sort of policy anyway (consider smartphones and tablets).  You can
> probably do much better than you suggest above - for example, if the
> device connected is an AV cable then it's more likely that you want to
> treat it as a block to be routed together than if the device connected
> is a docking station.  You might also choose to do things like
> remembering the configurations used with particular cables and restoring
> them when reconnected - for example, distinguishing between a car dock
> and a desktop docking station.
> 
> > 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.
> 
> This is the sort of device that MyungJoo is taking about in a lot of his
> examples.

I just came across another example which is conceptually similar but
different enough to be worth mentioning I think ... see below.

> > 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.
> 
> 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 :-)


> > 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.
> 
> Common parents often don't exist - it's not unusual for multiple devices
> to be involved in the detection of accessories.  Assuming a straight
> tree structure is very dangerous in the embedded context.  Board
> assigned naming does seem reasonable to me, though.

When I used the term "common-parent", I meant to mean that if there was no
obvious parent in a device-tree sense, then the "board" was the default
common parent.  I think we agree on this.


> 
> > 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).
> 
> 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) ???


Anyway, my other example.

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.

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.

So I create a pair, give one end to the mmc, the other to the rfkill.
Problem solved.

This is similar in some ways to the proposed 'switch' concept.  Where switch
uses a notifier chain, gpio-inout uses an IRQ to invoke code in a different
driver.

I don't think this is necessarily the "right" thing to do in all cases, but I
present it as providing a hopefully-useful perspective on the problem space.

A cable port could be given a set of gpios.  It responds to a plug event by
setting most of the gpios to indicate the type and function of the cable, and
the pulses another gpio to say 'new cable'.  Most client would listen for
interrupts on that gpio, but could listen on a specific function-gpio if
needed.

One particular problem with this approach is that allocating IRQ numbers is
even more painful than allocating gpio number.  However that could be fixed I
guess..

Anyway, food for thought for the interested.

NeilBrown


From: NeilBrown <neilb@suse.de>
Date: Fri, 2 Dec 2011 15:38:52 +1100
Subject: [PATCH] gpio-inout - virtual paired GPIO line.

A 'gpio-input' virtual chip provides pairs of GPIO lines.
The first of each pair (even offset) is an output which can be
set high or low.
The second is an input which reads the value of the paired output
and which generates an interrupt when the value transitions from
low to high.

This can be used to provide simple in-kernel signaling between
drivers, particular drivers that expect to get signals from GPIO
lines.

Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8482a23..1d82f5c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -489,4 +489,10 @@ config GPIO_TPS65910
 	help
 	  Select this option to enable GPIO driver for the TPS65910
 	  chip family.
+
+config GPIO_INOUT
+	bool "Virual InOut GPIO"
+	help
+	  Select this option for virtual gpios.
+
 endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index dbcb0bc..dcbe7e5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -62,3 +62,4 @@ obj-$(CONFIG_GPIO_WM831X)	+= gpio-wm831x.o
 obj-$(CONFIG_GPIO_WM8350)	+= gpio-wm8350.o
 obj-$(CONFIG_GPIO_WM8994)	+= gpio-wm8994.o
 obj-$(CONFIG_GPIO_XILINX)	+= gpio-xilinx.o
+obj-$(CONFIG_GPIO_INOUT)	+= gpio-inout.o
diff --git a/drivers/gpio/gpio-inout.c b/drivers/gpio/gpio-inout.c
new file mode 100644
index 0000000..ecae821
--- /dev/null
+++ b/drivers/gpio/gpio-inout.c
@@ -0,0 +1,170 @@
+/*
+ * in-out gpios.
+ *
+ * An in-out gpio is a signaling mechanism between drivers and to
+ * user-space.
+ * A gpio-inout chip provides pairs of gpio lines that are connected.
+ * The even offsets are outputs that can be driven high or low.  The
+ * odd offsets are input that read the value from the previous gpio and
+ * can generate an interrupt.
+ * By exporting to sysfs they can allocate signaling with user-space too.
+ *
+ */
+
+
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/gpio.h>
+#include <linux/irq.h>
+#include <linux/gpio-inout.h>
+
+#include <linux/delay.h>
+
+struct inout_chip {
+	struct gpio_chip	gpio;
+	int			irq_base;
+	int			values[];
+};
+
+#define IS_OUT(gpio) (((gpio) & 1) == 0)
+#define IS_IN(gpio) (((gpio) & 1) == 1)
+
+static int gpio_inout_direction_output(struct gpio_chip *gchip, unsigned gpio,
+				       int val)
+{
+	struct inout_chip *chip = container_of(gchip, struct inout_chip, gpio);
+
+	if (IS_IN(gpio))
+		return -EINVAL;
+
+	chip->values[gpio/2] = val;
+	return 0;
+}
+
+static int gpio_inout_direction_input(struct gpio_chip *gchip, unsigned gpio)
+{
+	if (IS_OUT(gpio))
+		return -EINVAL;
+
+	return 0;
+}
+
+static int gpio_inout_to_irq(struct gpio_chip *gchip, unsigned gpio)
+{
+	struct inout_chip *chip = container_of(gchip, struct inout_chip, gpio);
+
+	if (IS_OUT(gpio))
+		return -EINVAL;
+
+	return (gpio / 2) + chip->irq_base;
+}
+
+static void gpio_inout_set(struct gpio_chip *gchip, unsigned gpio, int val)
+{
+	struct inout_chip *chip = container_of(gchip, struct inout_chip, gpio);
+	int old;
+
+	if (IS_IN(gpio))
+		return;
+
+	old = chip->values[gpio/2];
+	chip->values[gpio/2] = val;
+	if (old != val)
+		handle_nested_irq(chip->irq_base + gpio / 2);
+}
+
+static int gpio_inout_get(struct gpio_chip *gchip, unsigned gpio)
+{
+	struct inout_chip *chip = container_of(gchip, struct inout_chip, gpio);
+	return chip->values[gpio/2];
+}
+
+
+static inline void activate_irq(int irq)
+{
+#ifdef CONFIG_ARM
+	/* ARM requires an extra step to clear IRQ_NOREQUEST, which it
+	 * sets on behalf of every irq_chip.  Also sets IRQ_NOPROBE.
+	 */
+	set_irq_flags(irq, IRQF_VALID);
+#else
+	/* same effect on other architectures */
+	irq_set_noprobe(irq);
+#endif
+}
+
+static int __devinit gpio_inout_probe(struct platform_device *pdev)
+{
+	struct gpio_inout_platform_data *pdata = pdev->dev.platform_data;
+	struct inout_chip *chip;
+	int err;
+	int i;
+
+	err = -ENOMEM;
+	chip = kzalloc(sizeof(*chip) + pdata->npairs * sizeof(int),
+		       GFP_KERNEL);
+	if (!chip)
+		goto exit;
+
+	chip->gpio.label = "gpio_inout";
+	chip->gpio.names = pdata->names;
+	chip->gpio.ngpio = 2 * pdata->npairs;
+	chip->gpio.base = pdata->gpio_base;
+	chip->gpio.owner = THIS_MODULE;
+	chip->gpio.direction_output = gpio_inout_direction_output;
+	chip->gpio.direction_input = gpio_inout_direction_input;
+	chip->gpio.to_irq = gpio_inout_to_irq;
+	chip->gpio.set = gpio_inout_set;
+	chip->gpio.get = gpio_inout_get;
+	chip->gpio.dev = &pdev->dev;
+	chip->irq_base = pdata->irq_base;
+
+	err = gpiochip_add(&chip->gpio);
+	if (err)
+		goto exit;
+
+	for (i = 0; i < pdata->npairs; i++) {
+		irq_set_chip_and_handler(chip->irq_base + i,
+					 &dummy_irq_chip,
+					 handle_simple_irq);
+		irq_set_nested_thread(chip->irq_base + i, 1);
+		activate_irq(i);
+	}
+
+	if (pdata->setup)
+		pdata->setup(chip->gpio.base);
+	return 0;
+
+exit:
+	kfree(chip);
+	return err;
+}
+
+static int __devexit gpio_inout_remove(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static struct platform_driver gpio_inout_driver = {
+	.probe		= gpio_inout_probe,
+	.remove		= __devexit_p(gpio_inout_remove),
+	.driver.name	= "gpio-inout",
+	.driver.owner	= THIS_MODULE,
+};
+
+static int __init gpio_inout_init(void)
+{
+	return platform_driver_register(&gpio_inout_driver);
+}
+module_init(gpio_inout_init);
+
+static void __exit gpio_inout_exit(void)
+{
+	platform_driver_unregister(&gpio_inout_driver);
+}
+module_exit(gpio_inout_exit);
+
+MODULE_AUTHOR("NeilBrown <neilb@suse.de>");
+MODULE_DESCRIPTION("Virtual gpio pairs");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/gpio-inout.h b/include/linux/gpio-inout.h
new file mode 100644
index 0000000..07c6222
--- /dev/null
+++ b/include/linux/gpio-inout.h
@@ -0,0 +1,9 @@
+
+
+struct gpio_inout_platform_data {
+	int	npairs;
+	int	gpio_base;
+	int	irq_base;
+	const char **	names;
+	void (*setup)(unsigned gpio_base);
+};

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Mark Brown]

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.

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

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 5244 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Mark Brown]

On Tue, Dec 06, 2011 at 06:38:34AM +1100, NeilBrown wrote:

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

Yes, that seems broadly sane for me.

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

Perhaps.

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

I suspect not.

>   3/ Does anything in the kernel care about the cable-name, or is that only
>      interesting to user-space?

I suspect not.

Other people may have other opinions, though.

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[MyungJoo Ham]

On Thu, Dec 1, 2011 at 7:56 AM, NeilBrown <neilb@suse.de> wrote:
> On Wed, 30 Nov 2011 15:40:48 +0900 MyungJoo Ham <myungjoo.ham@gmail.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.
>
> Hi,
>  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.

Hello,

I can't take/send picture at work, so, I'll write some examples.

1. Dock with multiple ports as Mark suggested.
2. a 30-pin cable with multiple cable sockets (basically, this is a
light-weight dock, too). A cable that connects to multiple other
devics from a computer (including any ARM midgets and full PCs). Plus,
there can be multiple different types of such cables for a single
model of port. For example, in Samsung Galaxy Tab series, there is a
30-pin port, which can be connected to Serial(UART), Dedicated
charger, USB (either as a host or client), Audio I/O, HDMI, Video I/O,
and others. And the cable does not need to be 1-to-1 (Tab-to-USB,
Tab-to-HDMI). There are cables that may connect Tab-to-USB-and-HDMI or
Tab-to-Charger-and-A/V. In fact, among these 30 pins, there are
independent pins for HDMI, pins for Audio, pins for charging, pins for
USB, and others sharing ground/power pins, and a "multi-socket" 30-pin
cable may simply open them up to other "standard" cables.

Cheers!
MyungJoo


-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Linus Walleij]

Hm, as we're speaking and debating where these switches should go,
it appears tasty drivers doing this or similar things are already actively
being merged into drivers/misc/fsa9480.c:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a1bb73d76bc814e9385390e6aa9880d884322e2e

Given both come from Samsung, is this driver intended to replace
that custom driver or is this another initiative altogether?

Minkyu, Donggeun, can you help us finding out where
these things belong? I guess you guys also have a strong interest
in a standard solution derived from Android.

Yours,
Linus Walleij

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Kyungmin Park]

On 12/7/11, Linus Walleij <linus.walleij@linaro.org> wrote:
> Hm, as we're speaking and debating where these switches should go,
> it appears tasty drivers doing this or similar things are already actively
> being merged into drivers/misc/fsa9480.c:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a1bb73d76bc814e9385390e6aa9880d884322e2e
>
> Given both come from Samsung, is this driver intended to replace
> that custom driver or is this another initiative altogether?
Previous time we used the fsa9480, micro usb IC, and now used the
similar IC, integrated at PMIC. With the restriction and no framework
for proper switching, at that time use the platform callback function,
but with the multistate switch class, we can improve and handle it
more precisely

>
> Minkyu, Donggeun, can you help us finding out where
> these things belong? I guess you guys also have a strong interest
> in a standard solution derived from Android.

Both are my team, and Donggeun is working on *similar IC* with
multistate switch framework.

Thank you,
Kyungmin Park
>
> Yours,
> Linus Walleij
> --
> 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/
>

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Greg KH]

On Thu, Nov 24, 2011 at 11:03:53AM +0900, MyungJoo Ham wrote:
> For switch ports, which may have different types of cables
> (USB, TA, HDMI, Analog A/V, and others), we often have seperated device
> drivers that detect the state changes at the port and device drivers that
> do something according to the state changes.
> 
> For example, when MAX8997-MUIC detects a Charger cable insertion, another
> device driver (such as MAX8903 charger, MAX8997 charger, Charger Manager,
> or board file) needs to set charger current limit accordingly and when
> MAX8997-MUIC detects a HDMI cable insertion, multimedia device drivers
> need to do some operations accordingly.
> 
> This patchset supports the usage of notifier for passing such information
> between device drivers.
> 
> Another issue is that at a single switch port, there might be multiple
> and heterogeneous cables attached at the same time. Besides, the state
> (Attached or Detached) of each cable may alter independently.
> 
> In order to address such issues, Android kernel's "Switch" class seems to
> be a good basis and we have implemented "Multistate Switch Class" based on
> it. The "Switch" class code of Android kernel is GPL as well.

I have the same objections to this patchset that Arnd does, as well as
the fact that there is no documentation of this new userspace api.

Please include a Documentation/ABI file that describes exactly what you
are adding here, and how this is to be used, so that we can properly
review it next time, if you end up sticking with this "new" interface
proposal.

thanks,

greg k-h

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[MyungJoo Ham]

On Sun, Nov 27, 2011 at 12:32 AM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Nov 24, 2011 at 11:03:53AM +0900, MyungJoo Ham wrote:
>> For switch ports, which may have different types of cables
>> (USB, TA, HDMI, Analog A/V, and others), we often have seperated device
>> drivers that detect the state changes at the port and device drivers that
>> do something according to the state changes.
>>
>> For example, when MAX8997-MUIC detects a Charger cable insertion, another
>> device driver (such as MAX8903 charger, MAX8997 charger, Charger Manager,
>> or board file) needs to set charger current limit accordingly and when
>> MAX8997-MUIC detects a HDMI cable insertion, multimedia device drivers
>> need to do some operations accordingly.
>>
>> This patchset supports the usage of notifier for passing such information
>> between device drivers.
>>
>> Another issue is that at a single switch port, there might be multiple
>> and heterogeneous cables attached at the same time. Besides, the state
>> (Attached or Detached) of each cable may alter independently.
>>
>> In order to address such issues, Android kernel's "Switch" class seems to
>> be a good basis and we have implemented "Multistate Switch Class" based on
>> it. The "Switch" class code of Android kernel is GPL as well.
>
> I have the same objections to this patchset that Arnd does, as well as
> the fact that there is no documentation of this new userspace api.
>
> Please include a Documentation/ABI file that describes exactly what you
> are adding here, and how this is to be used, so that we can properly
> review it next time, if you end up sticking with this "new" interface
> proposal.
>
> thanks,
>
> greg k-h
>

Although it only has read-only "state", "name" sysfs entries, sure,
I'll add them at Documentation/ABI with the next iteration.


Cheers!
MyungJoo
-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics

Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

[Mark Brown]

On Thu, Nov 24, 2011 at 11:03:53AM +0900, MyungJoo Ham wrote:
> For switch ports, which may have different types of cables
> (USB, TA, HDMI, Analog A/V, and others), we often have seperated device
> drivers that detect the state changes at the port and device drivers that
> do something according to the state changes.

I've no real comments right now beyond what people have already said but
please CC me on any futher revisions of this series.  It would be good
to see a patch in this series which extends the existing jack support in
ALSA (sound/core/jack.c) to make use of this.