On Tue, Dec 11, 2012 at 12:01:57PM +0200, Roger Quadros wrote:
> On 12/11/2012 11:12 AM, Jassi Brar wrote:
> > On Mon, Dec 10, 2012 at 3:18 PM, Roger Quadros 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
On 12/11/2012 11:12 AM, Jassi Brar wrote:
> On Mon, Dec 10, 2012 at 3:18 PM, Roger Quadros 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
On Mon, Dec 10, 2012 at 3:18 PM, Roger Quadros 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 wonde
Hi,
On Mon, Dec 10, 2012 at 11:48:51AM +0200, Roger Quadros wrote:
> >>> (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 t
On 12/06/2012 04:34 PM, Jassi Brar wrote:
> On Wed, Dec 5, 2012 at 7:39 PM, Roger Quadros wrote:
>> Hi Jassi,
>>
>> On 12/01/2012 09:49 AM, Jassi Brar wrote:
>>> On Tue, Nov 27, 2012 at 10:32 PM, Greg KH
>>> wrote:
On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote:
>
> We s
On Wed, Dec 5, 2012 at 7:39 PM, Roger Quadros wrote:
> Hi Jassi,
>
> On 12/01/2012 09:49 AM, Jassi Brar wrote:
>> On Tue, Nov 27, 2012 at 10:32 PM, Greg KH 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 loc
Hi Jassi,
On 12/01/2012 09:49 AM, Jassi Brar wrote:
> On Tue, Nov 27, 2012 at 10:32 PM, Greg KH 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 stru
On Sat, Dec 1, 2012 at 2:07 PM, Andy Green wrote:
> On 12/01/2012 03:49 PM, the mail apparently from Jassi Brar included:
>
>> On Tue, Nov 27, 2012 at 10:32 PM, Greg KH
>> wrote:
>>>
>>> On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote:
We should have a more generic solut
On 12/01/2012 03:49 PM, the mail apparently from Jassi Brar included:
On Tue, Nov 27, 2012 at 10:32 PM, Greg KH 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
On Tue, Nov 27, 2012 at 10:32 PM, Greg KH 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 en
On Thu, 29 Nov 2012, Ming Lei wrote:
> If we want to set up the association between usb port and power domain,
> usb knowledge is required, at least bus info and port topology are needed.
>
> One difficulty is the fact that the device(such as usb port) is independent
> with the 'power domain', fo
On Thu, Nov 29, 2012 at 12:43 AM, Alan Stern wrote:
> On Wed, 28 Nov 2012, Roger Quadros wrote:
>
>> > board file:
>> >
>> > static struct regulator myreg = {
>> > .name = "mydevice-regulator",
>> > };
>> >
>> > static struct device_asset mydevice_assets[] = {
>> > {
>>
On Wed, 28 Nov 2012, Roger Quadros wrote:
> > board file:
> >
> > static struct regulator myreg = {
> > .name = "mydevice-regulator",
> > };
> >
> > static struct device_asset mydevice_assets[] = {
> > {
> > .name = "mydevice-regulator",
> > .h
On 11/28/2012 01:47 PM, Andy Green wrote:
> On 11/28/2012 07:13 PM, the mail apparently from Roger Quadros included:
>> On 11/27/2012 09:22 PM, Andy Green wrote:
>>> On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
>> Greg's
On 11/28/2012 07:13 PM, the mail apparently from Roger Quadros included:
On 11/27/2012 09:22 PM, Andy Green wrote:
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply not to rely on pathnames in sysfs because th
On 11/27/2012 09:22 PM, Andy Green wrote:
> On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
>> On Wed, 28 Nov 2012, Andy Green wrote:
>>
Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone. That leaves plenty of other ways t
On 11/28/2012 04:10 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
OK. So I try to sketch it out iteractively to try to get in sync:
device.h:
enum asset_event {
AE_PROBED,
AE_REMOVED
};
struct
On Wed, Nov 28, 2012 at 7:06 AM, Ming Lei wrote:
>>> Also from my intuition, power domain should be involved in the problem,
>>> because these hard-wired and self-powered USB devices should have
>>> its own power domains, and the ehci-omap driver may enable/disable
>>> these power domains before a
On Wed, Nov 28, 2012 at 1:55 AM, Andy Green wrote:
> On 11/28/2012 01:22 AM, the mail apparently from Ming Lei included:
>
>> On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern
>> wrote:
>>>
>>> On Tue, 27 Nov 2012, Ming Lei wrote:
>>>
IMO, all matches mean the devices are inside the ehci-omap bus
On Wed, 28 Nov 2012, Andy Green wrote:
> OK. So I try to sketch it out iteractively to try to get in sync:
>
> device.h:
>
> enum asset_event {
> AE_PROBED,
> AE_REMOVED
> };
>
> struct device_asset {
> char *name; /* name of regulato
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone. That leaves plenty of other ways to approach
this problem.
It's sage advice, but there i
On Wed, 28 Nov 2012, Andy Green wrote:
> > Greg's advice was simply not to rely on pathnames in sysfs because they
> > aren't fixed in stone. That leaves plenty of other ways to approach
> > this problem.
>
> It's sage advice, but there is zero code provided in my patches that
> "relies on path
On 11/28/2012 01:22 AM, the mail apparently from Ming Lei included:
On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern wrote:
On Tue, 27 Nov 2012, Ming Lei wrote:
IMO, all matches mean the devices are inside the ehci-omap bus, so
the direct/simple way is to enable/disable the regulators in the prob
On 11/28/2012 12:37 AM, the mail apparently from Alan Stern included:
On Tue, 27 Nov 2012, Andy Green wrote:
I don't know if such an approach would be sufficiently general for
future requirements, but it would solve the problem at hand.
We can get a notification about device creation and do t
On Wed, Nov 28, 2012 at 12:30 AM, Alan Stern wrote:
> On Tue, 27 Nov 2012, Ming Lei wrote:
>
>> IMO, all matches mean the devices are inside the ehci-omap bus, so
>> the direct/simple way is to enable/disable the regulators in the probe() and
>> remove() of ehci-omap controller driver.
>
> When th
On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote:
> On Tue, 27 Nov 2012, Ming Lei wrote:
>
> > IMO, all matches mean the devices are inside the ehci-omap bus, so
> > the direct/simple way is to enable/disable the regulators in the probe() and
> > remove() of ehci-omap controller driver.
On Tue, 27 Nov 2012, Andy Green wrote:
> > I don't know if such an approach would be sufficiently general for
> > future requirements, but it would solve the problem at hand.
>
> We can get a notification about device creation and do things there.
> But the cost of that is like the tuple suggest
On Tue, 27 Nov 2012, Ming Lei wrote:
> IMO, all matches mean the devices are inside the ehci-omap bus, so
> the direct/simple way is to enable/disable the regulators in the probe() and
> remove() of ehci-omap controller driver.
When this discussion started, Felipe argued against such an approach.
On Tue, Nov 27, 2012 at 5:07 AM, Alan Stern wrote:
> On Mon, 26 Nov 2012, Greg KH wrote:
>
>> Ah, here's the root of your problem, right? You need a way for your
>> hardware to tell the kernel that you have a regulator attached to a
>> specific device? Using the device path and hard-coding it in
On 11/27/2012 05:07 AM, the mail apparently from Alan Stern included:
On Mon, 26 Nov 2012, Greg KH wrote:
Ah, here's the root of your problem, right? You need a way for your
hardware to tell the kernel that you have a regulator attached to a
specific device? Using the device path and hard-cod
On 11/27/2012 03:22 AM, the mail apparently from Greg KH included:
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
This adds a small optional API into drivers/base which deals with generating,
matching and registration of wildcard device paths.
>From a struct device * you can genera
On 11/27/2012 03:16 AM, the mail apparently from Greg KH included:
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
+struct device_path list;
+DEFINE_MUTEX(lock);
Those are some very descriptive global variables you just created :(
I guess I can add the "static" if that will heal
On 11/27/2012 03:12 AM, the mail apparently from Alan Stern included:
On Mon, 26 Nov 2012, Andy Green wrote:
This adds a small optional API into drivers/base which deals with generating,
matching and registration of wildcard device paths.
>From a struct device * you can generate a string like
On Mon, Nov 26, 2012 at 04:07:38PM -0500, Alan Stern wrote:
> On Mon, 26 Nov 2012, Greg KH wrote:
>
> > Ah, here's the root of your problem, right? You need a way for your
> > hardware to tell the kernel that you have a regulator attached to a
> > specific device? Using the device path and hard-
On Mon, 26 Nov 2012, Greg KH wrote:
> Ah, here's the root of your problem, right? You need a way for your
> hardware to tell the kernel that you have a regulator attached to a
> specific device? Using the device path and hard-coding it into the
> kernel is not the proper way to solve this, sorry
On Mon, Nov 26, 2012 at 11:22:06AM -0800, Greg KH wrote:
> On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
> > This adds a small optional API into drivers/base which deals with
> > generating,
> > matching and registration of wildcard device paths.
> >
> > >From a struct device * you
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
> This adds a small optional API into drivers/base which deals with generating,
> matching and registration of wildcard device paths.
>
> >From a struct device * you can generate a string like
>
> /platform/usbhs_omap/ehci-omap.0/usb1/1
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
> +struct device_path list;
> +DEFINE_MUTEX(lock);
Those are some very descriptive global variables you just created :(
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.ke
On Mon, 26 Nov 2012, Andy Green wrote:
> This adds a small optional API into drivers/base which deals with generating,
> matching and registration of wildcard device paths.
>
> >From a struct device * you can generate a string like
>
> /platform/usbhs_omap/ehci-omap.0/usb1/1-1
>
> which enapsu
This adds a small optional API into drivers/base which deals with generating,
matching and registration of wildcard device paths.
>From a struct device * you can generate a string like
/platform/usbhs_omap/ehci-omap.0/usb1/1-1
which enapsulates the path of the device's connection to the board.
40 matches
Mail list logo
