Hi,
On Monday 27 May 2013 12:26 PM, Laxman Dewangan wrote:
On Monday 27 May 2013 12:11 PM, Kishon Vijay Abraham I wrote:
Hi,
On Monday 27 May 2013 12:06 PM, Laxman Dewangan wrote:
On Monday 27 May 2013 12:01 PM, Kishon Vijay Abraham I wrote:
Hi,
On Monday 27 May 2013 11:52 AM, Laxman Dewangan wrote:
On Monday 27 May 2013 11:38 AM, Chanwoo Choi wrote:
On 05/27/2013 02:54 PM, Kishon Vijay Abraham I wrote:
Hi,
On Monday 27 May 2013 11:04 AM, Chanwoo Choi wrote:
Hi Kishon,
I have some comment about this patch
and upload modified patch to following repository
(extcon-for-palmas).
-
http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-for-palmas&id=f2b7cb80699cbe1a5fd6c97ef2c600915f8d7f2c
This patchset include patch related to other module
,so I need your opinion to apply this patchset to git repository.
yeah.. Still there is some confusion with
palmas_set_switch_smps10().
I think we can remove it for now and add it separately later. By
this
at least we can have device mode fully functional in OMAP5. What do
you think?
I agree your opinion.
But, I propose some fixes about palmas_set_switch_smps10().
I dont' prefer to call global function in exton-palmas.c from
palmas-regulator.c.
So, Why don't you use regulator consumer instead of global function?
You can register specific regulator for enabling or disabling
SMPS10_SWITCH_EN
and then control SMPS10_SWITCH_EN bit through regulator framework in
extcon-palmas.c
without calling global function.
Along with this, I also like to make the VBUS regulator control to be
optional here. Currently it is mandatory.
But dint you just tell on my v4 of this patch that you don’t require
this.
http://www.spinics.net/lists/linux-doc/msg10638.html
In V4, I said remove this VBUS control and my mean was to remove all
regulator calls for VBUS enabled/disable.
I saw you just remove the platform data option to have this control and
made VBUS mandatory.
Probably some gap here.
Indeed..
I think then we should stick back to how it was with my v4 or else it
would break OMAP. The regulator calls can't be moved anywhere else as it
is specific to PALMAS.
I was thinking that extcon driver just detect the cable type and notify
to the client. After cable detection, the next level of configuration
should be done in the respective client.
On Tegra platform, for ID pin detection, Tegra SOC is capable of detect
the ID pin presence or Palma is capable. Depending on the board design,
how the ID pin routed from USB connector to PMIC or to Tegra, we enable
corresponding detection logic.
Once the USB driver got notification for ID pin presence (by any means),
the enabling of VBUS (as the Tegra will work as Host now and need to
supply VBUS), is done in USB driver.
Not sure about the OMAP here.
I think I got your point here. Will check and send a patch.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
