[PATCH] introduce-usb-host-power-control.patch

Felipe Balbi me at felipebalbi.com
Wed Mar 12 10:34:35 CET 2008


Hi,

On Wed, 12 Mar 2008 08:21:51 +0000, Andy Green <andy at openmoko.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Somebody in the thread at some point said:
>> On Tue, Mar 11, 2008 at 09:25:41PM +0000, Andy Green wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hm... I didn't find any support for this in the kernel... I didn't see
>>> it in U-Boot...  either I missed the point badly or we don't seem to
>>> have tested this?  It seems to work fine anyway.
>>
>> Actually this should be done automatically, again based on id_pin
>> status.
> 
> We still need a /sys node for the "automatic" thread to assert the
> state, well at least if it is a usermode daemon.

gotcha

> Hum however ohci-s3c does not know about pcm50633 -- btw there is a big
> problem there as you said for 50606.c as far as upstream goes, it has
> all kinds of illegal knowledge about GTA02 in there.  So we need to
> stitch it through platform if that is the way, well, okay.
> 
>>> +static struct platform_device gta02_pm_usbhost_dev = {
>>> +	.name		= "neo1973-pm-host",
>>> +};
>>> +
>>
>> I don't really like this approach. You should just have something
>> sampling id pin and when it goes grounded then you switch charge pump
>> on.
> 
> Hum.  Right now it seems nobody ever tested the USB host pump or indeed
> USB host on GTA02 -- I wired up a cable last night and it detected a USB
> memory stick ok so it seems to work.  So this approach as of today at
> least lets us control the EN_USBHOST net that configures the hardware to
> host.  Being able to control EN_USBHOST separate from anything else may
> have value for test too.
> 
> Also this just follows a trend of having broken out power management
> "devices" as for bt and gsm.
> 
> Lastly we discussed what that "something" should be monitoring the ID
> pin analogue level and the answer came back a daemon IIRC.  Therefore
> the daemon needs a way to actually change the hardware configuration,
> and a /sys node like this will do that in a clean way.  If we make it a
> kernel thread, then no need, but we lose the ability to control it from
> userspace which can be good.
> 
>>> + * Bluetooth PM code for the FIC Neo1973 GSM Phone
>>
>> Err... USB ??
> 
> Yeah it was late.

I do that sometimes as well :-p

> 
>>> +	pcf50633_gpio_set(pcf50633_global, PCF50633_GPO, on);
>>
>> ahaa... so it's gpio-based.
>> How about puting a gpio_request() call in ohci (or maybe board files)
>> module for this device ?
> 
> Hm well no it is not CPU GPIO but GPIO on the PMU device, which is not
> related directly to s3c*.  So yes it means stitching it through platform
> to get it in s3c ohci, but we can do that.

Take a look at gpiolib, is a library for gpioexpanders. It'd be nice
to use it for pcf.

Actually there's already support for pcf857x devices, it should be piece
of cake to add pcf50606.

>>> +	dev_info(&pdev->dev, "starting\n");
>>
>> this could be dev_dbg(), this message is only useful on debugging
>> purposes, also something more explanatory would be cool :-)
>>
>> something like:
>>
>> dev_dbg(&pdev->dev, "Neo1973 USB PM\n");
> 
> dev_* prepends it with the device name, so it's clear enough who is
> talking I think.

Ugh, that's true, my mistake. although i still think you say what is
starting ;-)

> 
>> how about:
>> if (machine_is_neo1973_gta01())
>> 	return -EINVAL;
> 
> Yeah.
> 
>> If you don't mind, I'd really like to redesign this. Tomorrow I
>> scheduled to start coding linux-moko-2.6 as off now I just did the
>> Makefile changes.
> 
> Generally if someone started on a patch, they should own subsequent
> revisions.  However in this case, we already had you owning this region,
> I jumped in on it because of another thread about USB host on another
> list and that I realized nobody tested USB host power on GTA02.  So if
> you want to redo along the lines you mention, go ahead.  In the
> meanwhile I'll keep this patch in my git tree until it is replaced by
> your implementation.

That's ok for me ;-)

> 
>> I'll start putting together some board-files and the basic support,
>> after that I'll start fixing up mokopatches to make them acceptable on
>> mailine :-)
> 
> Heroic action, sir.

eheh, let's see if they'll get accepted soon ;-)
I think we can schedule to 2.6.27, still 3 ~ 4 months to go until there.

-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me at felipebalbi.com





More information about the openmoko-kernel mailing list