| Message ID | 1363087466-32444-2-git-send-email-rogerq@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 03/12/2013 12:24 PM, Roger Quadros wrote: > Add clk_rate parameter to platform data. If supplied, the > NOP phy driver will program the clock to that rate during probe. > > Also add 2 flags, needs_vcc and needs_reset. > If the flag is set and the regulator couldn't be found > then the driver will bail out with -EPROBE_DEFER. Is there a platform which fills out pdata.needs_vcc and pdata.needs_reset? IMHO it makes no sense to add features for the non DT case, if there isn't any user for it. Marc
On 03/12/2013 01:54 PM, Marc Kleine-Budde wrote: > On 03/12/2013 12:24 PM, Roger Quadros wrote: >> Add clk_rate parameter to platform data. If supplied, the >> NOP phy driver will program the clock to that rate during probe. >> >> Also add 2 flags, needs_vcc and needs_reset. >> If the flag is set and the regulator couldn't be found >> then the driver will bail out with -EPROBE_DEFER. > > Is there a platform which fills out pdata.needs_vcc and > pdata.needs_reset? IMHO it makes no sense to add features for the non DT > case, if there isn't any user for it. > There can be a user in the non DT case as well. Consider the following example: The power regulator that supplies VCC to the PHY device sits over the I2C bus. The NOP transceiver driver is built into the kernel but the regulator driver is built as a module. During boot, the NOP transceiver driver's probe is called before the regulator can be probed. So regulator_get() will fail and if the platform doesn't set the needs_vcc flag, the driver will continue as normal and the PHY device won't work. I know that beagleboard can benefit from this. The current workaround is to register the regulator before we register the PHY in the board file. With the needs_vcc flag, we don't need to have that limitation. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/12/2013 03:12 PM, Roger Quadros wrote: > On 03/12/2013 01:54 PM, Marc Kleine-Budde wrote: >> On 03/12/2013 12:24 PM, Roger Quadros wrote: >>> Add clk_rate parameter to platform data. If supplied, the >>> NOP phy driver will program the clock to that rate during probe. >>> >>> Also add 2 flags, needs_vcc and needs_reset. >>> If the flag is set and the regulator couldn't be found >>> then the driver will bail out with -EPROBE_DEFER. >> >> Is there a platform which fills out pdata.needs_vcc and >> pdata.needs_reset? IMHO it makes no sense to add features for the non DT >> case, if there isn't any user for it. >> > > There can be a user in the non DT case as well. Consider the following example: I'm just saying, let the implementation up to a real user for the non DT case. Beagleboard is ARM and there's no point of implementing non DT fall backs for ARM, IMHO. Marc
On 03/12/2013 04:17 PM, Marc Kleine-Budde wrote: > On 03/12/2013 03:12 PM, Roger Quadros wrote: >> On 03/12/2013 01:54 PM, Marc Kleine-Budde wrote: >>> On 03/12/2013 12:24 PM, Roger Quadros wrote: >>>> Add clk_rate parameter to platform data. If supplied, the >>>> NOP phy driver will program the clock to that rate during probe. >>>> >>>> Also add 2 flags, needs_vcc and needs_reset. >>>> If the flag is set and the regulator couldn't be found >>>> then the driver will bail out with -EPROBE_DEFER. >>> >>> Is there a platform which fills out pdata.needs_vcc and >>> pdata.needs_reset? IMHO it makes no sense to add features for the non DT >>> case, if there isn't any user for it. >>> >> >> There can be a user in the non DT case as well. Consider the following example: > > I'm just saying, let the implementation up to a real user for the non DT > case. Beagleboard is ARM and there's no point of implementing non DT > fall backs for ARM, IMHO. > Why do you say so? It doesn't depend on the CPU architecture. It depends on how the board designer wired the board. A non ARM platform could also face the same problem as beagle. It is not a non DT fallback. I believe many are still using non DT boot and it needs to work at least till we move all functionality to purely DT. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/12/2013 03:28 PM, Roger Quadros wrote: > On 03/12/2013 04:17 PM, Marc Kleine-Budde wrote: >> On 03/12/2013 03:12 PM, Roger Quadros wrote: >>> On 03/12/2013 01:54 PM, Marc Kleine-Budde wrote: >>>> On 03/12/2013 12:24 PM, Roger Quadros wrote: >>>>> Add clk_rate parameter to platform data. If supplied, the >>>>> NOP phy driver will program the clock to that rate during probe. >>>>> >>>>> Also add 2 flags, needs_vcc and needs_reset. >>>>> If the flag is set and the regulator couldn't be found >>>>> then the driver will bail out with -EPROBE_DEFER. >>>> >>>> Is there a platform which fills out pdata.needs_vcc and >>>> pdata.needs_reset? IMHO it makes no sense to add features for the non DT >>>> case, if there isn't any user for it. >>>> >>> >>> There can be a user in the non DT case as well. Consider the following example: >> >> I'm just saying, let the implementation up to a real user for the non DT >> case. Beagleboard is ARM and there's no point of implementing non DT >> fall backs for ARM, IMHO. >> > > Why do you say so? > > It doesn't depend on the CPU architecture. It depends on how the board designer > wired the board. A non ARM platform could also face the same problem as beagle. Using -EPROBE_DEFER ist the way to solve the problem. > It is not a non DT fallback. I believe many are still using non DT boot and it > needs to work at least till we move all functionality to purely DT. From my point of view, it makes no sense today to implement new features which have a fallback for the non-DT case, if there isn't a real user of this feature. So IMHO don't add needs_vcc and needs_reset flags to the pdata, just take the information from the DT. As soon as there is a non-DT user of this feature she/he can implement it or even better switch to DT. just my 2ยข, Marc
On 03/12/2013 04:42 PM, Marc Kleine-Budde wrote: > On 03/12/2013 03:28 PM, Roger Quadros wrote: >> On 03/12/2013 04:17 PM, Marc Kleine-Budde wrote: >>> On 03/12/2013 03:12 PM, Roger Quadros wrote: >>>> On 03/12/2013 01:54 PM, Marc Kleine-Budde wrote: >>>>> On 03/12/2013 12:24 PM, Roger Quadros wrote: >>>>>> Add clk_rate parameter to platform data. If supplied, the >>>>>> NOP phy driver will program the clock to that rate during probe. >>>>>> >>>>>> Also add 2 flags, needs_vcc and needs_reset. >>>>>> If the flag is set and the regulator couldn't be found >>>>>> then the driver will bail out with -EPROBE_DEFER. >>>>> >>>>> Is there a platform which fills out pdata.needs_vcc and >>>>> pdata.needs_reset? IMHO it makes no sense to add features for the non DT >>>>> case, if there isn't any user for it. >>>>> >>>> >>>> There can be a user in the non DT case as well. Consider the following example: >>> >>> I'm just saying, let the implementation up to a real user for the non DT >>> case. Beagleboard is ARM and there's no point of implementing non DT >>> fall backs for ARM, IMHO. >>> >> >> Why do you say so? >> >> It doesn't depend on the CPU architecture. It depends on how the board designer >> wired the board. A non ARM platform could also face the same problem as beagle. > > Using -EPROBE_DEFER ist the way to solve the problem. did you mean isn't? If you did then what is the other option? > >> It is not a non DT fallback. I believe many are still using non DT boot and it >> needs to work at least till we move all functionality to purely DT. > > From my point of view, it makes no sense today to implement new features > which have a fallback for the non-DT case, if there isn't a real user of > this feature. So IMHO don't add needs_vcc and needs_reset flags to the > pdata, just take the information from the DT. As soon as there is a > non-DT user of this feature she/he can implement it or even better > switch to DT. Adding Peter to the loop. I faintly remember him mentioning this issue before for beagle. We really need the deferred probe mechanism or we need to resort to device registering order. The first user for needs_vcc flag will be the beagleboard file. I just didn't implement it in this patch [1]. On second thoughts, since [1] does work on beagleboard without requiring the needs_vcc flag, I think we can just live without it. Felipe, Peter, what do you think? cheers, -roger [1] https://lkml.org/lkml/2013/3/12/244 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/12/2013 04:20 PM, Roger Quadros wrote: > On 03/12/2013 04:42 PM, Marc Kleine-Budde wrote: >> On 03/12/2013 03:28 PM, Roger Quadros wrote: >>> On 03/12/2013 04:17 PM, Marc Kleine-Budde wrote: >>>> On 03/12/2013 03:12 PM, Roger Quadros wrote: >>>>> On 03/12/2013 01:54 PM, Marc Kleine-Budde wrote: >>>>>> On 03/12/2013 12:24 PM, Roger Quadros wrote: >>>>>>> Add clk_rate parameter to platform data. If supplied, the >>>>>>> NOP phy driver will program the clock to that rate during probe. >>>>>>> >>>>>>> Also add 2 flags, needs_vcc and needs_reset. >>>>>>> If the flag is set and the regulator couldn't be found >>>>>>> then the driver will bail out with -EPROBE_DEFER. >>>>>> >>>>>> Is there a platform which fills out pdata.needs_vcc and >>>>>> pdata.needs_reset? IMHO it makes no sense to add features for the non DT >>>>>> case, if there isn't any user for it. >>>>>> >>>>> >>>>> There can be a user in the non DT case as well. Consider the following example: >>>> >>>> I'm just saying, let the implementation up to a real user for the non DT >>>> case. Beagleboard is ARM and there's no point of implementing non DT >>>> fall backs for ARM, IMHO. >>>> >>> >>> Why do you say so? >>> >>> It doesn't depend on the CPU architecture. It depends on how the board designer >>> wired the board. A non ARM platform could also face the same problem as beagle. >> >> Using -EPROBE_DEFER ist the way to solve the problem. > > did you mean isn't? If you did then what is the other option? You're using -EPROBE_DEFER, that's all perfectly fine. >>> It is not a non DT fallback. I believe many are still using non DT boot and it >>> needs to work at least till we move all functionality to purely DT. >> >> From my point of view, it makes no sense today to implement new features >> which have a fallback for the non-DT case, if there isn't a real user of >> this feature. So IMHO don't add needs_vcc and needs_reset flags to the >> pdata, just take the information from the DT. As soon as there is a >> non-DT user of this feature she/he can implement it or even better >> switch to DT. > > Adding Peter to the loop. I faintly remember him mentioning this issue before > for beagle. We really need the deferred probe mechanism or we need to resort > to device registering order. > The first user for needs_vcc flag will be the beagleboard file. I just didn't > implement it in this patch [1]. Okay, I wrongly assumed that there wouldn't be added any new features to the old non-DT board files. > On second thoughts, since [1] does work on beagleboard without requiring the > needs_vcc flag, I think we can just live without it. Marc
On 03/12/2013 04:20 PM, Roger Quadros wrote: > Adding Peter to the loop. I faintly remember him mentioning this issue before > for beagle. We really need the deferred probe mechanism or we need to resort > to device registering order. Yes, BeagleBoard is a good example. Long story short: we have external dependency and the correct way to handle that is via deferred probe. As of now we are not ready to kill the legacy support but over time we should move as much as we can to DT only mode. > The first user for needs_vcc flag will be the beagleboard file. I just didn't > implement it in this patch [1]. > > On second thoughts, since [1] does work on beagleboard without requiring the > needs_vcc flag, I think we can just live without it. The BeagleBoard works because the bootloader happen to enable the PWM generator which is used as a GPIO for the external HUB enable port. As soon as the bootloader stops doing this we are going to be in trouble. > > Felipe, Peter, what do you think? > > cheers, > -roger > > [1] https://lkml.org/lkml/2013/3/12/244 >
On 03/13/2013 05:17 PM, Peter Ujfalusi wrote: > On 03/12/2013 04:20 PM, Roger Quadros wrote: >> Adding Peter to the loop. I faintly remember him mentioning this issue before >> for beagle. We really need the deferred probe mechanism or we need to resort >> to device registering order. > > Yes, BeagleBoard is a good example. Long story short: we have external > dependency and the correct way to handle that is via deferred probe. > > As of now we are not ready to kill the legacy support but over time we should > move as much as we can to DT only mode. > >> The first user for needs_vcc flag will be the beagleboard file. I just didn't >> implement it in this patch [1]. >> >> On second thoughts, since [1] does work on beagleboard without requiring the >> needs_vcc flag, I think we can just live without it. > > The BeagleBoard works because the bootloader happen to enable the PWM > generator which is used as a GPIO for the external HUB enable port. As soon as > the bootloader stops doing this we are going to be in trouble. > Wasn't it the LED A out GPO from PMIC that is used to enable the HUB? Just cross checking so I haven't missed anything. I will resend the board support patch for beagle implementing needs_vcc flag for the deferred probe mechanism. Thanks. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/13/2013 04:17 PM, Peter Ujfalusi wrote: > On 03/12/2013 04:20 PM, Roger Quadros wrote: >> Adding Peter to the loop. I faintly remember him mentioning this issue before >> for beagle. We really need the deferred probe mechanism or we need to resort >> to device registering order. > > Yes, BeagleBoard is a good example. Long story short: we have external > dependency and the correct way to handle that is via deferred probe. Sure. > As of now we are not ready to kill the legacy support but over time we should > move as much as we can to DT only mode. I was assuming you're already on DT only :) Marc
diff --git a/include/linux/usb/nop-usb-xceiv.h b/include/linux/usb/nop-usb-xceiv.h index 28884c7..148d351 100644 --- a/include/linux/usb/nop-usb-xceiv.h +++ b/include/linux/usb/nop-usb-xceiv.h @@ -5,6 +5,11 @@ struct nop_usb_xceiv_platform_data { enum usb_phy_type type; + unsigned long clk_rate; + + /* if set fails with -EPROBE_DEFER if can't get regulator */ + unsigned int needs_vcc:1; + unsigned int needs_reset:1; }; #if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE) && defined(MODULE))