Re: [RFC PATCH 1/5] drivers : introduce device_path api

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 10, 2012 at 3:18 PM, Roger Quadros <rogerq@xxxxxx> wrote:
> On 12/06/2012 04:34 PM, Jassi Brar wrote:
>>>
>>> Yes, this is where we can think of a generic PHY driver to make sure thy
>>> PHY has necessary resources enabled. In the Panda case it would be the
>>> PHY clock and RESET gpio.
>>>
>> I wonder if ehci-omap should assume, besides regulator, a clock might
>> also be need to setup for the transceiver chip.
>> Maybe "usbhs_bdata" in board-omap4panda.c should have
>> .reset_gpio_port[0]  = GPIO_HUB_NRESET ?
>>
>
> Just like the regulator, reset_gpio_port has nothing to do with OMAP
> EHCI. So we would want to get rid of that too from the OMAP USB driver.
>
Looking at the code I realized we already book resources only for
populated ports. Saving power from LAN9514 chip would come from a
separate solution. So, for now when our transceiver, USB3320, has
simple hardwired configuration probably just platform_data/DT would
do. When we come across some programmable transceiver (like USB3503
over i2c), that might warrant a separate PHY driver. Still I don't
think we could have a 'generic' phy driver.

>>
>>> The LAN95xx chip still needs to be powered up and the PHY driver isn't
>>> the right place for that (though it could be done there as a hack). The
>>> closest we can get to emulating right USB behavior is to map the
>>> SET/CLEAR PORT_FEATURE of the root hub port to the regulator that powers
>>> the LAN95xx.
>>>
>>> This way, we still don't fall in the dynamically probed space, so we
>>> could still provide the regulator information to the ehci hub via
>>> platform data and handle the regulator in ehci_hub_control
>>> (Set/ClearPortFeature). I'm looking at this as a software workaround for
>>> all platforms not implementing the EHCI set port power feature
>>> correctly. The same could be repeated for other HCDs as well if required.
>>>
>> IMHO it's not a matter of platforms not implementing EHCI set port
>> power feature correctly, we should think about onboard devices
>> connected to onboard non-root hubs. Setups like LAN9514 on Panda (HSIC
>> too ?) that don't run on VBUS of USB, would like their local supply to
>> be treated as if it came from the parent hub's port  i.e, tie together
>> the USB's set port power control with their OOB regulated power supply
>> (U9 on PandaBoard).
>>
>
> On Pandaboards we are still talking about root hub ports.
>
> Do you know any of such platforms which power their USB devices out of
> band for _non_ root hub ports?
>
I don't know of any. But I do believe we shouldn't discount that scenario.
IIANW lan9514 doesn't take in VBUS because it wants to avoid 5V->3.3V
regulating. What if someone designs an omap4 platform with 3
high-speed devices and the same concern in mind ?

> Assuming they do exist, the only solution is to match platform data for
> dynamically probed devices and deal with the regulators in the hub/port
> driver. Something like Andy already proposed.
>
Yes, but I doubt if that is the only implementation.
One USB specific solution could be to abstract out OOB port power
control in, say, port-power.c which constructs a regulator topology
mapped directly onto onboard devices', from a generic DT binding,
platform_data, ACPI whatever. And then catch any
set/clear_port_feature(POWER) call to enable/disable the regulator
corresponding to that port. Where each regulator could be a
board-specific virtual one, that does all that is necessary (like
clock/reg hierarchy setup) to power up the device.

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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux