[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