Re: [PATCHv4 2/6] phy: improved lookup method
Hi, On Tuesday 18 November 2014 09:06 PM, Heikki Krogerus wrote: > On Tue, Nov 18, 2014 at 10:49:18AM +0530, Kishon Vijay Abraham I wrote: >> On Monday 17 November 2014 09:10 PM, Heikki Krogerus wrote: >>> On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: How about adding the change in attached patch [1] on top of this patch. Just introduced the phy pointer in "phy_lookup" structure, and modified phy_find() accordingly. >>> >>> I would be fine if we used the phy pointer to match, but if we have >>> the pointer to the phy in the lookup, then I would say we need to >>> remove the phy_name member. >>> >>> Otherwise we would have to support two ways of finding the lookups >>> (one for the "static" lookups where we match to the phy_name and other >>> where we match to the pointer). That means we will also not be able to >>> create "static" lookups, but those would be only needed if we wanted to >>> create them in board files. I don't think there will ever be need to >>> create the lookups in board files, so I'm more then happy to remove >>> the static way of creating the lookups. >> >> Just using the phy pointer sounds good. But interested to know where the phy >> pointer will be added to the lookup table. > > I'm making assumption that there will not be any (new) platforms where > the bindings are not provided in HW descriptions like dt or ACPI > tables. That leaves the lookups to be useful only in cases where a > driver has to, for whatever reason, pass it's phy's forward, like > dwc3 host. ULPI will be an other case where we will need to use them. right. > > Now the only user for the lookups is twl4030-usb, but since it's > actually just ULPI type PHY in cases where we have platform data to > deal with (please correct me if I'm wrong), I think we could later You mean passing the consumer info using platform data? > remove it's need for platform data completely with the help of the > ULPI bus I'm working with. Sure. I'll be closing my phy tree by friday, so would be great if you can send your patches before that with "Tested-by" from Vivek. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/6] phy: improved lookup method
Hi, On Tuesday 18 November 2014 09:06 PM, Heikki Krogerus wrote: > On Tue, Nov 18, 2014 at 10:49:18AM +0530, Kishon Vijay Abraham I wrote: >> On Monday 17 November 2014 09:10 PM, Heikki Krogerus wrote: >>> On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: How about adding the change in attached patch [1] on top of this patch. Just introduced the phy pointer in "phy_lookup" structure, and modified phy_find() accordingly. >>> >>> I would be fine if we used the phy pointer to match, but if we have >>> the pointer to the phy in the lookup, then I would say we need to >>> remove the phy_name member. >>> >>> Otherwise we would have to support two ways of finding the lookups >>> (one for the "static" lookups where we match to the phy_name and other >>> where we match to the pointer). That means we will also not be able to >>> create "static" lookups, but those would be only needed if we wanted to >>> create them in board files. I don't think there will ever be need to >>> create the lookups in board files, so I'm more then happy to remove >>> the static way of creating the lookups. >> >> Just using the phy pointer sounds good. But interested to know where the phy >> pointer will be added to the lookup table. > > I'm making assumption that there will not be any (new) platforms where > the bindings are not provided in HW descriptions like dt or ACPI > tables. That leaves the lookups to be useful only in cases where a > driver has to, for whatever reason, pass it's phy's forward, like > dwc3 host. ULPI will be an other case where we will need to use them. right. > > Now the only user for the lookups is twl4030-usb, but since it's > actually just ULPI type PHY in cases where we have platform data to > deal with (please correct me if I'm wrong), I think we could later you mean passing consumer information using platform data? > remove it's need for platform data completely with the help of the > ULPI bus I'm working with. Sure. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/6] phy: improved lookup method
On Tue, Nov 18, 2014 at 10:49:18AM +0530, Kishon Vijay Abraham I wrote: > On Monday 17 November 2014 09:10 PM, Heikki Krogerus wrote: > > On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: > >> How about adding the change in attached patch [1] on top of this patch. > >> Just introduced the phy pointer in "phy_lookup" structure, and > >> modified phy_find() accordingly. > > > > I would be fine if we used the phy pointer to match, but if we have > > the pointer to the phy in the lookup, then I would say we need to > > remove the phy_name member. > > > > Otherwise we would have to support two ways of finding the lookups > > (one for the "static" lookups where we match to the phy_name and other > > where we match to the pointer). That means we will also not be able to > > create "static" lookups, but those would be only needed if we wanted to > > create them in board files. I don't think there will ever be need to > > create the lookups in board files, so I'm more then happy to remove > > the static way of creating the lookups. > > Just using the phy pointer sounds good. But interested to know where the phy > pointer will be added to the lookup table. I'm making assumption that there will not be any (new) platforms where the bindings are not provided in HW descriptions like dt or ACPI tables. That leaves the lookups to be useful only in cases where a driver has to, for whatever reason, pass it's phy's forward, like dwc3 host. ULPI will be an other case where we will need to use them. Now the only user for the lookups is twl4030-usb, but since it's actually just ULPI type PHY in cases where we have platform data to deal with (please correct me if I'm wrong), I think we could later remove it's need for platform data completely with the help of the ULPI bus I'm working with. Cheers, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/6] phy: improved lookup method
Hi, On Monday 17 November 2014 09:10 PM, Heikki Krogerus wrote: > On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: >> How about adding the change in attached patch [1] on top of this patch. >> Just introduced the phy pointer in "phy_lookup" structure, and >> modified phy_find() accordingly. > > I would be fine if we used the phy pointer to match, but if we have > the pointer to the phy in the lookup, then I would say we need to > remove the phy_name member. > > Otherwise we would have to support two ways of finding the lookups > (one for the "static" lookups where we match to the phy_name and other > where we match to the pointer). That means we will also not be able to > create "static" lookups, but those would be only needed if we wanted to > create them in board files. I don't think there will ever be need to > create the lookups in board files, so I'm more then happy to remove > the static way of creating the lookups. Just using the phy pointer sounds good. But interested to know where the phy pointer will be added to the lookup table. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/6] phy: improved lookup method
On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: > How about adding the change in attached patch [1] on top of this patch. > Just introduced the phy pointer in "phy_lookup" structure, and > modified phy_find() accordingly. I would be fine if we used the phy pointer to match, but if we have the pointer to the phy in the lookup, then I would say we need to remove the phy_name member. Otherwise we would have to support two ways of finding the lookups (one for the "static" lookups where we match to the phy_name and other where we match to the pointer). That means we will also not be able to create "static" lookups, but those would be only needed if we wanted to create them in board files. I don't think there will ever be need to create the lookups in board files, so I'm more then happy to remove the static way of creating the lookups. Kishon, if you are OK with this change, I'll prepare new version of this set and use the idea. Vivek, you'll get the credit for it. Thanks! -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/6] phy: improved lookup method
On Fri, Nov 14, 2014 at 7:45 PM, Heikki Krogerus wrote: > Hi Vivek, > > On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: >> Hi Heikki, Kishon, >> >> How about adding the change in attached patch [1] on top of this patch. >> Just introduced the phy pointer in "phy_lookup" structure, and >> modified phy_find() accordingly. >> >> [1] Attachment: >> 0001-phy-core-Use-phy-pointer-with-phy_lookup_table.patch > > Just to let you know, I'm finally able to work on this again. Great !! > > I was actually thinking that we should just roll back to the previous > version where I didn't yet use the parent name, and rethink how to > solve the problem Kishon pointed out. > > But, I'll take a look at this properly on Monday. Cool, was just throwing some ideas, similar to clk driver, like Kishon suggested. -- Best Regards Vivek Gautam Samsung R&D Institute, Bangalore India -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/6] phy: improved lookup method
Hi Vivek, On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: > Hi Heikki, Kishon, > > How about adding the change in attached patch [1] on top of this patch. > Just introduced the phy pointer in "phy_lookup" structure, and > modified phy_find() accordingly. > > [1] Attachment: > 0001-phy-core-Use-phy-pointer-with-phy_lookup_table.patch Just to let you know, I'm finally able to work on this again. I was actually thinking that we should just roll back to the previous version where I didn't yet use the parent name, and rethink how to solve the problem Kishon pointed out. But, I'll take a look at this properly on Monday. Cheers, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/6] phy: improved lookup method
Hi Heikki, Kishon, On Tue, Nov 11, 2014 at 2:23 PM, Vivek Gautam wrote: > Hi Kishon, > > > On Tue, Nov 11, 2014 at 2:20 PM, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Tuesday 11 November 2014 02:07 PM, Vivek Gautam wrote: >>> On Tue, Nov 11, 2014 at 12:12 PM, Kishon Vijay Abraham I >>> wrote: Hi, On Friday 31 October 2014 06:03 PM, Vivek Gautam wrote: > Hi Heikki, > > > On Fri, Oct 17, 2014 at 8:09 PM, Heikki Krogerus > wrote: >> Removes the need for the phys to be aware of their users >> even when not using DT. The method is copied from clkdev.c. >> >> Signed-off-by: Heikki Krogerus >> Tested-by: Vivek Gautam >> --- >> Documentation/phy.txt | 66 --- >> drivers/phy/phy-core.c | 135 >> +++- >> include/linux/phy/phy.h | 27 ++ >> 3 files changed, 183 insertions(+), 45 deletions(-) >> >> diff --git a/Documentation/phy.txt b/Documentation/phy.txt >> index c6594af..8add515 100644 >> --- a/Documentation/phy.txt >> +++ b/Documentation/phy.txt >> @@ -54,18 +54,14 @@ The PHY driver should create the PHY in order for >> other peripheral controllers >> to make use of it. The PHY framework provides 2 APIs to create the PHY. >> >> struct phy *phy_create(struct device *dev, struct device_node *node, >> - const struct phy_ops *ops, >> - struct phy_init_data *init_data); >> + const struct phy_ops *ops); >> struct phy *devm_phy_create(struct device *dev, struct device_node >> *node, >> - const struct phy_ops *ops, >> - struct phy_init_data *init_data); >> + const struct phy_ops *ops); >> >> The PHY drivers can use one of the above 2 APIs to create the PHY by >> passing >> -the device pointer, phy ops and init_data. >> +the device pointer and phy ops. >> phy_ops is a set of function pointers for performing PHY operations >> such as >> -init, exit, power_on and power_off. *init_data* is mandatory to get a >> reference >> -to the PHY in the case of non-dt boot. See section *Board File >> Initialization* >> -on how init_data should be used. >> +init, exit, power_on and power_off. >> >> Inorder to dereference the private data (in phy_ops), the phy provider >> driver >> can use phy_set_drvdata() after creating the PHY and use >> phy_get_drvdata() in >> @@ -137,42 +133,24 @@ There are exported APIs like phy_pm_runtime_get, >> phy_pm_runtime_get_sync, >> phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and >> phy_pm_runtime_forbid for performing PM operations. >> >> -8. Board File Initialization >> - >> -Certain board file initialization is necessary in order to get a >> reference >> -to the PHY in the case of non-dt boot. >> -Say we have a single device that implements 3 PHYs that of USB, SATA >> and PCIe, >> -then in the board file the following initialization should be done. >> - >> -struct phy_consumer consumers[] = { >> - PHY_CONSUMER("dwc3.0", "usb"), >> - PHY_CONSUMER("pcie.0", "pcie"), >> - PHY_CONSUMER("sata.0", "sata"), >> -}; >> -PHY_CONSUMER takes 2 parameters, first is the device name of the >> controller >> -(PHY consumer) and second is the port name. >> - >> -struct phy_init_data init_data = { >> - .consumers = consumers, >> - .num_consumers = ARRAY_SIZE(consumers), >> -}; >> - >> -static const struct platform_device pipe3_phy_dev = { >> - .name = "pipe3-phy", >> - .id = -1, >> - .dev = { >> - .platform_data = { >> - .init_data = &init_data, >> - }, >> - }, >> -}; >> - >> -then, while doing phy_create, the PHY driver should pass this init_data >> - phy_create(dev, ops, pdata->init_data); >> - >> -and the controller driver (phy consumer) should pass the port name >> along with >> -the device to get a reference to the PHY >> - phy_get(dev, "pcie"); >> +8. PHY Mappings >> + >> +In order to get reference to a PHY without help from DeviceTree, the >> framework >> +offers lookups which can be compared to clkdev that allow clk >> structures to be >> +bound to devices. A lookup can be made statically by directly >> registering >> +phy_lookup structure which contains the name of the PHY device, the >> name of the >> +device which the PHY will be bind to and Connection ID string. >> Alternatively a >> +lookup can be made during runtime when a handle to the struct phy >> already >> +ex
Re: [PATCHv4 2/6] phy: improved lookup method
Hi Kishon, On Tue, Nov 11, 2014 at 2:20 PM, Kishon Vijay Abraham I wrote: > Hi, > > On Tuesday 11 November 2014 02:07 PM, Vivek Gautam wrote: >> On Tue, Nov 11, 2014 at 12:12 PM, Kishon Vijay Abraham I >> wrote: >>> Hi, >>> >>> On Friday 31 October 2014 06:03 PM, Vivek Gautam wrote: Hi Heikki, On Fri, Oct 17, 2014 at 8:09 PM, Heikki Krogerus wrote: > Removes the need for the phys to be aware of their users > even when not using DT. The method is copied from clkdev.c. > > Signed-off-by: Heikki Krogerus > Tested-by: Vivek Gautam > --- > Documentation/phy.txt | 66 --- > drivers/phy/phy-core.c | 135 > +++- > include/linux/phy/phy.h | 27 ++ > 3 files changed, 183 insertions(+), 45 deletions(-) > > diff --git a/Documentation/phy.txt b/Documentation/phy.txt > index c6594af..8add515 100644 > --- a/Documentation/phy.txt > +++ b/Documentation/phy.txt > @@ -54,18 +54,14 @@ The PHY driver should create the PHY in order for > other peripheral controllers > to make use of it. The PHY framework provides 2 APIs to create the PHY. > > struct phy *phy_create(struct device *dev, struct device_node *node, > - const struct phy_ops *ops, > - struct phy_init_data *init_data); > + const struct phy_ops *ops); > struct phy *devm_phy_create(struct device *dev, struct device_node *node, > - const struct phy_ops *ops, > - struct phy_init_data *init_data); > + const struct phy_ops *ops); > > The PHY drivers can use one of the above 2 APIs to create the PHY by > passing > -the device pointer, phy ops and init_data. > +the device pointer and phy ops. > phy_ops is a set of function pointers for performing PHY operations such > as > -init, exit, power_on and power_off. *init_data* is mandatory to get a > reference > -to the PHY in the case of non-dt boot. See section *Board File > Initialization* > -on how init_data should be used. > +init, exit, power_on and power_off. > > Inorder to dereference the private data (in phy_ops), the phy provider > driver > can use phy_set_drvdata() after creating the PHY and use > phy_get_drvdata() in > @@ -137,42 +133,24 @@ There are exported APIs like phy_pm_runtime_get, > phy_pm_runtime_get_sync, > phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and > phy_pm_runtime_forbid for performing PM operations. > > -8. Board File Initialization > - > -Certain board file initialization is necessary in order to get a > reference > -to the PHY in the case of non-dt boot. > -Say we have a single device that implements 3 PHYs that of USB, SATA and > PCIe, > -then in the board file the following initialization should be done. > - > -struct phy_consumer consumers[] = { > - PHY_CONSUMER("dwc3.0", "usb"), > - PHY_CONSUMER("pcie.0", "pcie"), > - PHY_CONSUMER("sata.0", "sata"), > -}; > -PHY_CONSUMER takes 2 parameters, first is the device name of the > controller > -(PHY consumer) and second is the port name. > - > -struct phy_init_data init_data = { > - .consumers = consumers, > - .num_consumers = ARRAY_SIZE(consumers), > -}; > - > -static const struct platform_device pipe3_phy_dev = { > - .name = "pipe3-phy", > - .id = -1, > - .dev = { > - .platform_data = { > - .init_data = &init_data, > - }, > - }, > -}; > - > -then, while doing phy_create, the PHY driver should pass this init_data > - phy_create(dev, ops, pdata->init_data); > - > -and the controller driver (phy consumer) should pass the port name along > with > -the device to get a reference to the PHY > - phy_get(dev, "pcie"); > +8. PHY Mappings > + > +In order to get reference to a PHY without help from DeviceTree, the > framework > +offers lookups which can be compared to clkdev that allow clk structures > to be > +bound to devices. A lookup can be made statically by directly registering > +phy_lookup structure which contains the name of the PHY device, the name > of the > +device which the PHY will be bind to and Connection ID string. > Alternatively a > +lookup can be made during runtime when a handle to the struct phy already > +exists. > + > +The framework offers the following APIs for registering and > unregistering the > +lookups. > + > +void phy_register_lookup(struct phy_lookup *pl); > +int phy_create_lookup(struct
Re: [PATCHv4 2/6] phy: improved lookup method
Hi, On Tuesday 11 November 2014 02:07 PM, Vivek Gautam wrote: > On Tue, Nov 11, 2014 at 12:12 PM, Kishon Vijay Abraham I > wrote: >> Hi, >> >> On Friday 31 October 2014 06:03 PM, Vivek Gautam wrote: >>> Hi Heikki, >>> >>> >>> On Fri, Oct 17, 2014 at 8:09 PM, Heikki Krogerus >>> wrote: Removes the need for the phys to be aware of their users even when not using DT. The method is copied from clkdev.c. Signed-off-by: Heikki Krogerus Tested-by: Vivek Gautam --- Documentation/phy.txt | 66 --- drivers/phy/phy-core.c | 135 +++- include/linux/phy/phy.h | 27 ++ 3 files changed, 183 insertions(+), 45 deletions(-) diff --git a/Documentation/phy.txt b/Documentation/phy.txt index c6594af..8add515 100644 --- a/Documentation/phy.txt +++ b/Documentation/phy.txt @@ -54,18 +54,14 @@ The PHY driver should create the PHY in order for other peripheral controllers to make use of it. The PHY framework provides 2 APIs to create the PHY. struct phy *phy_create(struct device *dev, struct device_node *node, - const struct phy_ops *ops, - struct phy_init_data *init_data); + const struct phy_ops *ops); struct phy *devm_phy_create(struct device *dev, struct device_node *node, - const struct phy_ops *ops, - struct phy_init_data *init_data); + const struct phy_ops *ops); The PHY drivers can use one of the above 2 APIs to create the PHY by passing -the device pointer, phy ops and init_data. +the device pointer and phy ops. phy_ops is a set of function pointers for performing PHY operations such as -init, exit, power_on and power_off. *init_data* is mandatory to get a reference -to the PHY in the case of non-dt boot. See section *Board File Initialization* -on how init_data should be used. +init, exit, power_on and power_off. Inorder to dereference the private data (in phy_ops), the phy provider driver can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in @@ -137,42 +133,24 @@ There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync, phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and phy_pm_runtime_forbid for performing PM operations. -8. Board File Initialization - -Certain board file initialization is necessary in order to get a reference -to the PHY in the case of non-dt boot. -Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe, -then in the board file the following initialization should be done. - -struct phy_consumer consumers[] = { - PHY_CONSUMER("dwc3.0", "usb"), - PHY_CONSUMER("pcie.0", "pcie"), - PHY_CONSUMER("sata.0", "sata"), -}; -PHY_CONSUMER takes 2 parameters, first is the device name of the controller -(PHY consumer) and second is the port name. - -struct phy_init_data init_data = { - .consumers = consumers, - .num_consumers = ARRAY_SIZE(consumers), -}; - -static const struct platform_device pipe3_phy_dev = { - .name = "pipe3-phy", - .id = -1, - .dev = { - .platform_data = { - .init_data = &init_data, - }, - }, -}; - -then, while doing phy_create, the PHY driver should pass this init_data - phy_create(dev, ops, pdata->init_data); - -and the controller driver (phy consumer) should pass the port name along with -the device to get a reference to the PHY - phy_get(dev, "pcie"); +8. PHY Mappings + +In order to get reference to a PHY without help from DeviceTree, the framework +offers lookups which can be compared to clkdev that allow clk structures to be +bound to devices. A lookup can be made statically by directly registering +phy_lookup structure which contains the name of the PHY device, the name of the +device which the PHY will be bind to and Connection ID string. Alternatively a +lookup can be made during runtime when a handle to the struct phy already +exists. + +The framework offers the following APIs for registering and unregistering the +lookups. + +void phy_register_lookup(struct phy_lookup *pl); +int phy_create_lookup(struct phy *phy, const char *con_id, const char *dev_id); + +void phy_unregister_lookup(struct phy_lookup *pl); +void phy_remove_lookup(struct phy *phy, const char *con_id, const char *dev_
Re: [PATCHv4 2/6] phy: improved lookup method
On Tue, Nov 11, 2014 at 12:12 PM, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 31 October 2014 06:03 PM, Vivek Gautam wrote: >> Hi Heikki, >> >> >> On Fri, Oct 17, 2014 at 8:09 PM, Heikki Krogerus >> wrote: >>> Removes the need for the phys to be aware of their users >>> even when not using DT. The method is copied from clkdev.c. >>> >>> Signed-off-by: Heikki Krogerus >>> Tested-by: Vivek Gautam >>> --- >>> Documentation/phy.txt | 66 --- >>> drivers/phy/phy-core.c | 135 >>> +++- >>> include/linux/phy/phy.h | 27 ++ >>> 3 files changed, 183 insertions(+), 45 deletions(-) >>> >>> diff --git a/Documentation/phy.txt b/Documentation/phy.txt >>> index c6594af..8add515 100644 >>> --- a/Documentation/phy.txt >>> +++ b/Documentation/phy.txt >>> @@ -54,18 +54,14 @@ The PHY driver should create the PHY in order for other >>> peripheral controllers >>> to make use of it. The PHY framework provides 2 APIs to create the PHY. >>> >>> struct phy *phy_create(struct device *dev, struct device_node *node, >>> - const struct phy_ops *ops, >>> - struct phy_init_data *init_data); >>> + const struct phy_ops *ops); >>> struct phy *devm_phy_create(struct device *dev, struct device_node *node, >>> - const struct phy_ops *ops, >>> - struct phy_init_data *init_data); >>> + const struct phy_ops *ops); >>> >>> The PHY drivers can use one of the above 2 APIs to create the PHY by >>> passing >>> -the device pointer, phy ops and init_data. >>> +the device pointer and phy ops. >>> phy_ops is a set of function pointers for performing PHY operations such as >>> -init, exit, power_on and power_off. *init_data* is mandatory to get a >>> reference >>> -to the PHY in the case of non-dt boot. See section *Board File >>> Initialization* >>> -on how init_data should be used. >>> +init, exit, power_on and power_off. >>> >>> Inorder to dereference the private data (in phy_ops), the phy provider >>> driver >>> can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() >>> in >>> @@ -137,42 +133,24 @@ There are exported APIs like phy_pm_runtime_get, >>> phy_pm_runtime_get_sync, >>> phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and >>> phy_pm_runtime_forbid for performing PM operations. >>> >>> -8. Board File Initialization >>> - >>> -Certain board file initialization is necessary in order to get a reference >>> -to the PHY in the case of non-dt boot. >>> -Say we have a single device that implements 3 PHYs that of USB, SATA and >>> PCIe, >>> -then in the board file the following initialization should be done. >>> - >>> -struct phy_consumer consumers[] = { >>> - PHY_CONSUMER("dwc3.0", "usb"), >>> - PHY_CONSUMER("pcie.0", "pcie"), >>> - PHY_CONSUMER("sata.0", "sata"), >>> -}; >>> -PHY_CONSUMER takes 2 parameters, first is the device name of the controller >>> -(PHY consumer) and second is the port name. >>> - >>> -struct phy_init_data init_data = { >>> - .consumers = consumers, >>> - .num_consumers = ARRAY_SIZE(consumers), >>> -}; >>> - >>> -static const struct platform_device pipe3_phy_dev = { >>> - .name = "pipe3-phy", >>> - .id = -1, >>> - .dev = { >>> - .platform_data = { >>> - .init_data = &init_data, >>> - }, >>> - }, >>> -}; >>> - >>> -then, while doing phy_create, the PHY driver should pass this init_data >>> - phy_create(dev, ops, pdata->init_data); >>> - >>> -and the controller driver (phy consumer) should pass the port name along >>> with >>> -the device to get a reference to the PHY >>> - phy_get(dev, "pcie"); >>> +8. PHY Mappings >>> + >>> +In order to get reference to a PHY without help from DeviceTree, the >>> framework >>> +offers lookups which can be compared to clkdev that allow clk structures >>> to be >>> +bound to devices. A lookup can be made statically by directly registering >>> +phy_lookup structure which contains the name of the PHY device, the name >>> of the >>> +device which the PHY will be bind to and Connection ID string. >>> Alternatively a >>> +lookup can be made during runtime when a handle to the struct phy already >>> +exists. >>> + >>> +The framework offers the following APIs for registering and unregistering >>> the >>> +lookups. >>> + >>> +void phy_register_lookup(struct phy_lookup *pl); >>> +int phy_create_lookup(struct phy *phy, const char *con_id, const char >>> *dev_id); >>> + >>> +void phy_unregister_lookup(struct phy_lookup *pl); >>> +void phy_remove_lookup(struct phy *phy, const char *con_id, const char >>> *dev_id); >>> >>> 9. DeviceTree Binding >>> >>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c >>> index ff5eec5..c8d0f66 100644 >>> --- a/drivers/phy/phy-core.c >>> +++ b/drivers/phy/phy-cor
Re: [PATCHv4 2/6] phy: improved lookup method
Hi, On Friday 31 October 2014 06:03 PM, Vivek Gautam wrote: > Hi Heikki, > > > On Fri, Oct 17, 2014 at 8:09 PM, Heikki Krogerus > wrote: >> Removes the need for the phys to be aware of their users >> even when not using DT. The method is copied from clkdev.c. >> >> Signed-off-by: Heikki Krogerus >> Tested-by: Vivek Gautam >> --- >> Documentation/phy.txt | 66 --- >> drivers/phy/phy-core.c | 135 >> +++- >> include/linux/phy/phy.h | 27 ++ >> 3 files changed, 183 insertions(+), 45 deletions(-) >> >> diff --git a/Documentation/phy.txt b/Documentation/phy.txt >> index c6594af..8add515 100644 >> --- a/Documentation/phy.txt >> +++ b/Documentation/phy.txt >> @@ -54,18 +54,14 @@ The PHY driver should create the PHY in order for other >> peripheral controllers >> to make use of it. The PHY framework provides 2 APIs to create the PHY. >> >> struct phy *phy_create(struct device *dev, struct device_node *node, >> - const struct phy_ops *ops, >> - struct phy_init_data *init_data); >> + const struct phy_ops *ops); >> struct phy *devm_phy_create(struct device *dev, struct device_node *node, >> - const struct phy_ops *ops, >> - struct phy_init_data *init_data); >> + const struct phy_ops *ops); >> >> The PHY drivers can use one of the above 2 APIs to create the PHY by passing >> -the device pointer, phy ops and init_data. >> +the device pointer and phy ops. >> phy_ops is a set of function pointers for performing PHY operations such as >> -init, exit, power_on and power_off. *init_data* is mandatory to get a >> reference >> -to the PHY in the case of non-dt boot. See section *Board File >> Initialization* >> -on how init_data should be used. >> +init, exit, power_on and power_off. >> >> Inorder to dereference the private data (in phy_ops), the phy provider >> driver >> can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() >> in >> @@ -137,42 +133,24 @@ There are exported APIs like phy_pm_runtime_get, >> phy_pm_runtime_get_sync, >> phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and >> phy_pm_runtime_forbid for performing PM operations. >> >> -8. Board File Initialization >> - >> -Certain board file initialization is necessary in order to get a reference >> -to the PHY in the case of non-dt boot. >> -Say we have a single device that implements 3 PHYs that of USB, SATA and >> PCIe, >> -then in the board file the following initialization should be done. >> - >> -struct phy_consumer consumers[] = { >> - PHY_CONSUMER("dwc3.0", "usb"), >> - PHY_CONSUMER("pcie.0", "pcie"), >> - PHY_CONSUMER("sata.0", "sata"), >> -}; >> -PHY_CONSUMER takes 2 parameters, first is the device name of the controller >> -(PHY consumer) and second is the port name. >> - >> -struct phy_init_data init_data = { >> - .consumers = consumers, >> - .num_consumers = ARRAY_SIZE(consumers), >> -}; >> - >> -static const struct platform_device pipe3_phy_dev = { >> - .name = "pipe3-phy", >> - .id = -1, >> - .dev = { >> - .platform_data = { >> - .init_data = &init_data, >> - }, >> - }, >> -}; >> - >> -then, while doing phy_create, the PHY driver should pass this init_data >> - phy_create(dev, ops, pdata->init_data); >> - >> -and the controller driver (phy consumer) should pass the port name along >> with >> -the device to get a reference to the PHY >> - phy_get(dev, "pcie"); >> +8. PHY Mappings >> + >> +In order to get reference to a PHY without help from DeviceTree, the >> framework >> +offers lookups which can be compared to clkdev that allow clk structures to >> be >> +bound to devices. A lookup can be made statically by directly registering >> +phy_lookup structure which contains the name of the PHY device, the name of >> the >> +device which the PHY will be bind to and Connection ID string. >> Alternatively a >> +lookup can be made during runtime when a handle to the struct phy already >> +exists. >> + >> +The framework offers the following APIs for registering and unregistering >> the >> +lookups. >> + >> +void phy_register_lookup(struct phy_lookup *pl); >> +int phy_create_lookup(struct phy *phy, const char *con_id, const char >> *dev_id); >> + >> +void phy_unregister_lookup(struct phy_lookup *pl); >> +void phy_remove_lookup(struct phy *phy, const char *con_id, const char >> *dev_id); >> >> 9. DeviceTree Binding >> >> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c >> index ff5eec5..c8d0f66 100644 >> --- a/drivers/phy/phy-core.c >> +++ b/drivers/phy/phy-core.c >> @@ -26,6 +26,7 @@ >> static struct class *phy_class; >> static DEFINE_MUTEX(phy_provider_mutex); >> static LIST_HEAD(phy_provider_list); >> +static LIST_HEAD(phys); >> static DEFINE_IDA(
Re: [PATCHv4 2/6] phy: improved lookup method
Hi Heikki, On Fri, Oct 17, 2014 at 8:09 PM, Heikki Krogerus wrote: > Removes the need for the phys to be aware of their users > even when not using DT. The method is copied from clkdev.c. > > Signed-off-by: Heikki Krogerus > Tested-by: Vivek Gautam > --- > Documentation/phy.txt | 66 --- > drivers/phy/phy-core.c | 135 > +++- > include/linux/phy/phy.h | 27 ++ > 3 files changed, 183 insertions(+), 45 deletions(-) > > diff --git a/Documentation/phy.txt b/Documentation/phy.txt > index c6594af..8add515 100644 > --- a/Documentation/phy.txt > +++ b/Documentation/phy.txt > @@ -54,18 +54,14 @@ The PHY driver should create the PHY in order for other > peripheral controllers > to make use of it. The PHY framework provides 2 APIs to create the PHY. > > struct phy *phy_create(struct device *dev, struct device_node *node, > - const struct phy_ops *ops, > - struct phy_init_data *init_data); > + const struct phy_ops *ops); > struct phy *devm_phy_create(struct device *dev, struct device_node *node, > - const struct phy_ops *ops, > - struct phy_init_data *init_data); > + const struct phy_ops *ops); > > The PHY drivers can use one of the above 2 APIs to create the PHY by passing > -the device pointer, phy ops and init_data. > +the device pointer and phy ops. > phy_ops is a set of function pointers for performing PHY operations such as > -init, exit, power_on and power_off. *init_data* is mandatory to get a > reference > -to the PHY in the case of non-dt boot. See section *Board File > Initialization* > -on how init_data should be used. > +init, exit, power_on and power_off. > > Inorder to dereference the private data (in phy_ops), the phy provider driver > can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in > @@ -137,42 +133,24 @@ There are exported APIs like phy_pm_runtime_get, > phy_pm_runtime_get_sync, > phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and > phy_pm_runtime_forbid for performing PM operations. > > -8. Board File Initialization > - > -Certain board file initialization is necessary in order to get a reference > -to the PHY in the case of non-dt boot. > -Say we have a single device that implements 3 PHYs that of USB, SATA and > PCIe, > -then in the board file the following initialization should be done. > - > -struct phy_consumer consumers[] = { > - PHY_CONSUMER("dwc3.0", "usb"), > - PHY_CONSUMER("pcie.0", "pcie"), > - PHY_CONSUMER("sata.0", "sata"), > -}; > -PHY_CONSUMER takes 2 parameters, first is the device name of the controller > -(PHY consumer) and second is the port name. > - > -struct phy_init_data init_data = { > - .consumers = consumers, > - .num_consumers = ARRAY_SIZE(consumers), > -}; > - > -static const struct platform_device pipe3_phy_dev = { > - .name = "pipe3-phy", > - .id = -1, > - .dev = { > - .platform_data = { > - .init_data = &init_data, > - }, > - }, > -}; > - > -then, while doing phy_create, the PHY driver should pass this init_data > - phy_create(dev, ops, pdata->init_data); > - > -and the controller driver (phy consumer) should pass the port name along with > -the device to get a reference to the PHY > - phy_get(dev, "pcie"); > +8. PHY Mappings > + > +In order to get reference to a PHY without help from DeviceTree, the > framework > +offers lookups which can be compared to clkdev that allow clk structures to > be > +bound to devices. A lookup can be made statically by directly registering > +phy_lookup structure which contains the name of the PHY device, the name of > the > +device which the PHY will be bind to and Connection ID string. Alternatively > a > +lookup can be made during runtime when a handle to the struct phy already > +exists. > + > +The framework offers the following APIs for registering and unregistering the > +lookups. > + > +void phy_register_lookup(struct phy_lookup *pl); > +int phy_create_lookup(struct phy *phy, const char *con_id, const char > *dev_id); > + > +void phy_unregister_lookup(struct phy_lookup *pl); > +void phy_remove_lookup(struct phy *phy, const char *con_id, const char > *dev_id); > > 9. DeviceTree Binding > > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c > index ff5eec5..c8d0f66 100644 > --- a/drivers/phy/phy-core.c > +++ b/drivers/phy/phy-core.c > @@ -26,6 +26,7 @@ > static struct class *phy_class; > static DEFINE_MUTEX(phy_provider_mutex); > static LIST_HEAD(phy_provider_list); > +static LIST_HEAD(phys); > static DEFINE_IDA(phy_ida); > > static void devm_phy_release(struct device *dev, void *res) > @@ -84,6 +85,138 @@ static struct phy *phy_lookup(struct device *device, > const char *port) > return ERR_PTR(-ENODEV); >
[PATCHv4 2/6] phy: improved lookup method
Removes the need for the phys to be aware of their users even when not using DT. The method is copied from clkdev.c. Signed-off-by: Heikki Krogerus Tested-by: Vivek Gautam --- Documentation/phy.txt | 66 --- drivers/phy/phy-core.c | 135 +++- include/linux/phy/phy.h | 27 ++ 3 files changed, 183 insertions(+), 45 deletions(-) diff --git a/Documentation/phy.txt b/Documentation/phy.txt index c6594af..8add515 100644 --- a/Documentation/phy.txt +++ b/Documentation/phy.txt @@ -54,18 +54,14 @@ The PHY driver should create the PHY in order for other peripheral controllers to make use of it. The PHY framework provides 2 APIs to create the PHY. struct phy *phy_create(struct device *dev, struct device_node *node, - const struct phy_ops *ops, - struct phy_init_data *init_data); + const struct phy_ops *ops); struct phy *devm_phy_create(struct device *dev, struct device_node *node, - const struct phy_ops *ops, - struct phy_init_data *init_data); + const struct phy_ops *ops); The PHY drivers can use one of the above 2 APIs to create the PHY by passing -the device pointer, phy ops and init_data. +the device pointer and phy ops. phy_ops is a set of function pointers for performing PHY operations such as -init, exit, power_on and power_off. *init_data* is mandatory to get a reference -to the PHY in the case of non-dt boot. See section *Board File Initialization* -on how init_data should be used. +init, exit, power_on and power_off. Inorder to dereference the private data (in phy_ops), the phy provider driver can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in @@ -137,42 +133,24 @@ There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync, phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and phy_pm_runtime_forbid for performing PM operations. -8. Board File Initialization - -Certain board file initialization is necessary in order to get a reference -to the PHY in the case of non-dt boot. -Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe, -then in the board file the following initialization should be done. - -struct phy_consumer consumers[] = { - PHY_CONSUMER("dwc3.0", "usb"), - PHY_CONSUMER("pcie.0", "pcie"), - PHY_CONSUMER("sata.0", "sata"), -}; -PHY_CONSUMER takes 2 parameters, first is the device name of the controller -(PHY consumer) and second is the port name. - -struct phy_init_data init_data = { - .consumers = consumers, - .num_consumers = ARRAY_SIZE(consumers), -}; - -static const struct platform_device pipe3_phy_dev = { - .name = "pipe3-phy", - .id = -1, - .dev = { - .platform_data = { - .init_data = &init_data, - }, - }, -}; - -then, while doing phy_create, the PHY driver should pass this init_data - phy_create(dev, ops, pdata->init_data); - -and the controller driver (phy consumer) should pass the port name along with -the device to get a reference to the PHY - phy_get(dev, "pcie"); +8. PHY Mappings + +In order to get reference to a PHY without help from DeviceTree, the framework +offers lookups which can be compared to clkdev that allow clk structures to be +bound to devices. A lookup can be made statically by directly registering +phy_lookup structure which contains the name of the PHY device, the name of the +device which the PHY will be bind to and Connection ID string. Alternatively a +lookup can be made during runtime when a handle to the struct phy already +exists. + +The framework offers the following APIs for registering and unregistering the +lookups. + +void phy_register_lookup(struct phy_lookup *pl); +int phy_create_lookup(struct phy *phy, const char *con_id, const char *dev_id); + +void phy_unregister_lookup(struct phy_lookup *pl); +void phy_remove_lookup(struct phy *phy, const char *con_id, const char *dev_id); 9. DeviceTree Binding diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c index ff5eec5..c8d0f66 100644 --- a/drivers/phy/phy-core.c +++ b/drivers/phy/phy-core.c @@ -26,6 +26,7 @@ static struct class *phy_class; static DEFINE_MUTEX(phy_provider_mutex); static LIST_HEAD(phy_provider_list); +static LIST_HEAD(phys); static DEFINE_IDA(phy_ida); static void devm_phy_release(struct device *dev, void *res) @@ -84,6 +85,138 @@ static struct phy *phy_lookup(struct device *device, const char *port) return ERR_PTR(-ENODEV); } +/** + * phy_register_lookup() - register PHY/device association + * @pl: association to register + */ +void phy_register_lookup(struct phy_lookup *pl) +{ + mutex_lock(&phy_provider_mutex); + list_add_tail(&pl->node, &phys); + mutex_unlock(&phy_provider_mutex); +} + +/** + * phy_unregister_loo