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

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

 



On 12/06/2012 04:34 PM, Jassi Brar wrote:
> On Wed, Dec 5, 2012 at 7:39 PM, Roger Quadros <rogerq@xxxxxx> wrote:
>> Hi Jassi,
>>
>> On 12/01/2012 09:49 AM, Jassi Brar wrote:
>>> On Tue, Nov 27, 2012 at 10:32 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>>>> On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote:
>>>>>
>>>>> We should have a more generic solution in a more central location, like
>>>>> the device core.
>>>>>
>>>>> For example, each struct platform_device could have a list of resources
>>>>> to be enabled when the device is bound to a driver and disabled when
>>>>> the device is unbound.  Such a list could include regulators, clocks,
>>>>> and whatever else people can invent.
>>>>>
>>>>> In this case, when it is created the ehci-omap.0 platform device could
>>>>> get an entry pointing to the LAN95xx's regulator.  Then the regulator
>>>>> would automatically be turned on when the platform device is bound to
>>>>> the ehci-omap driver.
>>>>>
>>>>> How does this sound?
>>>>
>>>> That sounds much better, and it might come in handy for other types of
>>>> devices than platform devices, so feel free to put this on the core
>>>> 'struct device' instead if needed.
>>>>
>>> Isn't enabling/disabling of clocks and regulators what
>>> dev.probe()/remove() of any driver already does?
>>> If we mean only board specific setup/teardown, still it would mean
>>> having the device core to do an extra 'probe' call when the current
>>> probe() is already meant to do whatever it takes to bring the device
>>> up. To my untrained eyes, it seem like messing with the
>>> probe()/remove()'s semantics.
>>>  IMHO, if we really must implement something like that, may be we
>>> should employ some 'broadcast mechanism' so that anything anywhere in
>>> kernel knows which new device has been probed()/removed()
>>> successfully. I haven't thought exactly how because I am not sure even
>>> that would be the right way to approach PandaBoard's problem.
>>>
>>> Looking at "Figure 15 – Panda USBB1 Interface Block Diagram" of
>>> http://pandaboard.org/sites/default/files/board_reference/pandaboard-es-b/panda-es-b-manual.pdf
>>> gives me visions ...
>>>
>>>  1) OMAP doesn't provide the USB root-hub, but only ULPIPHY. It is
>>> USB3320C chip that employs OMAP's ULPIPHY to provide the root-hub. So
>>> we should have a platform device for USB3320C, the probe() of which
>>> should simply
>>
>> Actually the EHCI controller within OMAP provides the root hub with 3
>> ports but no PHY. One of them is connected to the USB3320 which is just
>> a ULPI PHY.
>>
>>>    a) Enable REFCLK (FREF_CLK3_OUT)
>>>    b) Reset itself by cycling RESETB (GPIO_62)
>>>    c) Create one "ehci-omap" platform device
>>
>> c) is not appropriate. ehci-omap must be created before usb3320.
>>
>>>  (or in appropriate order if the above isn't)
>>> That way insmod/rmmod'ing the USB3320C driver would power-up/down the
>>> whole subsystem.
>>
>> 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.

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

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.

regards,
-roger
--
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