diff mbox

[v7,5/9] ARM: OMAP: USB: Add phy binding information

Message ID 1371113039-5784-6-git-send-email-kishon@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Kishon Vijay Abraham I June 13, 2013, 8:43 a.m. UTC
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy device name) should be added in the platform
data of the controller.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
---
 arch/arm/mach-omap2/usb-musb.c |    6 +++++-
 include/linux/usb/musb.h       |    3 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

Comments

Felipe Balbi June 18, 2013, 9:44 a.m. UTC | #1
On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote:
> In order for controllers to get PHY in case of non dt boot, the phy
> binding information (phy device name) should be added in the platform
> data of the controller.
> 
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>

I would rather not pass strings around, any other way to handle this ?
Why do you need to pass this string ?
Kishon Vijay Abraham I June 18, 2013, 10:04 a.m. UTC | #2
Hi,

On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote:
> On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote:
>> In order for controllers to get PHY in case of non dt boot, the phy
>> binding information (phy device name) should be added in the platform
>> data of the controller.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> I would rather not pass strings around, any other way to handle this ?
> Why do you need to pass this string ?

Our old way of binding the controller and the phy using device name 
started creating problems after the devices are created using 
PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for OMAP3 
platforms for which I have posted a RFC series 
http://www.serverphorums.com/read.php?12,708632 which also uses strings.
I'm not sure of any other way to deal with this.

Thanks
Kishon
Felipe Balbi June 18, 2013, 10:27 a.m. UTC | #3
Hi,

On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I wrote:
> On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote:
> >On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote:
> >>In order for controllers to get PHY in case of non dt boot, the phy
> >>binding information (phy device name) should be added in the platform
> >>data of the controller.
> >>
> >>Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >
> >I would rather not pass strings around, any other way to handle this ?
> >Why do you need to pass this string ?
> 
> Our old way of binding the controller and the phy using device name
> started creating problems after the devices are created using
> PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for
> OMAP3 platforms for which I have posted a RFC series
> http://www.serverphorums.com/read.php?12,708632 which also uses
> strings.
> I'm not sure of any other way to deal with this.

have you checked how other frameworks handle it ? Regulator has some
sort of binding in board-files, but I guess it passes the regulator
name?
Kishon Vijay Abraham I June 18, 2013, 11:13 a.m. UTC | #4
Hi,

On Tuesday 18 June 2013 03:57 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I wrote:
>> On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote:
>>> On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote:
>>>> In order for controllers to get PHY in case of non dt boot, the phy
>>>> binding information (phy device name) should be added in the platform
>>>> data of the controller.
>>>>
>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>
>>> I would rather not pass strings around, any other way to handle this ?
>>> Why do you need to pass this string ?
>>
>> Our old way of binding the controller and the phy using device name
>> started creating problems after the devices are created using
>> PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for
>> OMAP3 platforms for which I have posted a RFC series
>> http://www.serverphorums.com/read.php?12,708632 which also uses
>> strings.
>> I'm not sure of any other way to deal with this.
>
> have you checked how other frameworks handle it ? Regulator has some
> sort of binding in board-files, but I guess it passes the regulator
> name?

 From whatever I could make of, regulator has 3 ways to get the 
regulator one of which is using the binding in board-files (but it also 
uses device name which could create the same problem that we are facing).

1.) from dt data
2.) from _supply_ name
3.) from binding in board file

(referred regulator_dev_lookup() in regulator/core.c)

Thanks
Kishon
Felipe Balbi June 18, 2013, 12:35 p.m. UTC | #5
Hi,

On Tue, Jun 18, 2013 at 04:43:44PM +0530, Kishon Vijay Abraham I wrote:
> >On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I wrote:
> >>On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote:
> >>>On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote:
> >>>>In order for controllers to get PHY in case of non dt boot, the phy
> >>>>binding information (phy device name) should be added in the platform
> >>>>data of the controller.
> >>>>
> >>>>Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >>>
> >>>I would rather not pass strings around, any other way to handle this ?
> >>>Why do you need to pass this string ?
> >>
> >>Our old way of binding the controller and the phy using device name
> >>started creating problems after the devices are created using
> >>PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for
> >>OMAP3 platforms for which I have posted a RFC series
> >>http://www.serverphorums.com/read.php?12,708632 which also uses
> >>strings.
> >>I'm not sure of any other way to deal with this.
> >
> >have you checked how other frameworks handle it ? Regulator has some
> >sort of binding in board-files, but I guess it passes the regulator
> >name?
> 
> From whatever I could make of, regulator has 3 ways to get the
> regulator one of which is using the binding in board-files (but it
> also uses device name which could create the same problem that we are
> facing).
> 
> 1.) from dt data
> 2.) from _supply_ name
> 3.) from binding in board file
> 
> (referred regulator_dev_lookup() in regulator/core.c)

right, spot on. Which means we don't have a better, more elegant
solution now. Let's go ahead with this.
Kishon Vijay Abraham I June 18, 2013, 2:55 p.m. UTC | #6
Hi,

On Tuesday 18 June 2013 06:05 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jun 18, 2013 at 04:43:44PM +0530, Kishon Vijay Abraham I wrote:
>>> On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I wrote:
>>>> On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote:
>>>>> On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote:
>>>>>> In order for controllers to get PHY in case of non dt boot, the phy
>>>>>> binding information (phy device name) should be added in the platform
>>>>>> data of the controller.
>>>>>>
>>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>>>
>>>>> I would rather not pass strings around, any other way to handle this ?
>>>>> Why do you need to pass this string ?
>>>>
>>>> Our old way of binding the controller and the phy using device name
>>>> started creating problems after the devices are created using
>>>> PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for
>>>> OMAP3 platforms for which I have posted a RFC series
>>>> http://www.serverphorums.com/read.php?12,708632 which also uses
>>>> strings.
>>>> I'm not sure of any other way to deal with this.
>>>
>>> have you checked how other frameworks handle it ? Regulator has some
>>> sort of binding in board-files, but I guess it passes the regulator
>>> name?
>>
>>  From whatever I could make of, regulator has 3 ways to get the
>> regulator one of which is using the binding in board-files (but it
>> also uses device name which could create the same problem that we are
>> facing).
>>
>> 1.) from dt data
>> 2.) from _supply_ name
>> 3.) from binding in board file
>>
>> (referred regulator_dev_lookup() in regulator/core.c)
>
> right, spot on. Which means we don't have a better, more elegant
> solution now. Let's go ahead with this.

Ok. So I'll drop RFC and resend this patch series
http://www.serverphorums.com/read.php?12,708632

Thanks
Kishon
Felipe Balbi June 18, 2013, 2:57 p.m. UTC | #7
Hi,

On Tue, Jun 18, 2013 at 08:25:00PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Tuesday 18 June 2013 06:05 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Tue, Jun 18, 2013 at 04:43:44PM +0530, Kishon Vijay Abraham I wrote:
> >>>On Tue, Jun 18, 2013 at 03:34:36PM +0530, Kishon Vijay Abraham I wrote:
> >>>>On Tuesday 18 June 2013 03:14 PM, Felipe Balbi wrote:
> >>>>>On Thu, Jun 13, 2013 at 02:13:55PM +0530, Kishon Vijay Abraham I wrote:
> >>>>>>In order for controllers to get PHY in case of non dt boot, the phy
> >>>>>>binding information (phy device name) should be added in the platform
> >>>>>>data of the controller.
> >>>>>>
> >>>>>>Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >>>>>
> >>>>>I would rather not pass strings around, any other way to handle this ?
> >>>>>Why do you need to pass this string ?
> >>>>
> >>>>Our old way of binding the controller and the phy using device name
> >>>>started creating problems after the devices are created using
> >>>>PLATFORM_DEVID_AUTO. Infact non-dt boot is broken in mainline for
> >>>>OMAP3 platforms for which I have posted a RFC series
> >>>>http://www.serverphorums.com/read.php?12,708632 which also uses
> >>>>strings.
> >>>>I'm not sure of any other way to deal with this.
> >>>
> >>>have you checked how other frameworks handle it ? Regulator has some
> >>>sort of binding in board-files, but I guess it passes the regulator
> >>>name?
> >>
> >> From whatever I could make of, regulator has 3 ways to get the
> >>regulator one of which is using the binding in board-files (but it
> >>also uses device name which could create the same problem that we are
> >>facing).
> >>
> >>1.) from dt data
> >>2.) from _supply_ name
> >>3.) from binding in board file
> >>
> >>(referred regulator_dev_lookup() in regulator/core.c)
> >
> >right, spot on. Which means we don't have a better, more elegant
> >solution now. Let's go ahead with this.
> 
> Ok. So I'll drop RFC and resend this patch series
> http://www.serverphorums.com/read.php?12,708632

please do :-)
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..284ba51 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,8 +85,12 @@  void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
 	musb_plat.mode = board_data->mode;
 	musb_plat.extvbus = board_data->extvbus;
 
-	if (cpu_is_omap44xx())
+	if (cpu_is_omap44xx()) {
 		musb_plat.has_mailbox = true;
+		musb_plat.phy_label = "omap-usb2";
+	} else if (cpu_is_omap34xx()) {
+		musb_plat.phy_label = "twl4030";
+	}
 
 	if (soc_is_am35xx()) {
 		oh_name = "am35x_otg_hs";
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..596f8c8 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -104,6 +104,9 @@  struct musb_hdrc_platform_data {
 	/* for clk_get() */
 	const char	*clock;
 
+	/* phy label */
+	const char	*phy_label;
+
 	/* (HOST or OTG) switch VBUS on/off */
 	int		(*set_vbus)(struct device *dev, int is_on);