On Wed, Mar 6, 2013 at 4:53 PM, Felipe Balbi <balbi@xxxxxx> wrote: > On Wed, Mar 06, 2013 at 04:24:58PM +0800, Chao Xie wrote: >> On Wed, Mar 6, 2013 at 4:10 PM, Felipe Balbi <balbi@xxxxxx> wrote: >> > Hi, >> > >> > On Wed, Mar 06, 2013 at 10:11:41AM +0800, Chao Xie wrote: >> >> 3. For the revison register. It exists in some SOCes(pxa168), but for >> >> some SOCes, the register dispears(pxa910, armada610). These SOCes are >> >> developed by different desgin teams, and it need to be enhanced, but >> >> for current products i have to use the device_id to detect the PHY >> >> controller. >> > >> > fair enough, make sure to add a comment to the driver about this so >> > grumpy maintainers stop complaining ;-) >> > >> >> 4. For the mutex and refcount. The "USB controller" includes two >> >> blocks - the udc and ehci. In fact they will not be used at same time, >> >> but for some SOCes it duplicates the ehci block. It means that the >> >> SOCes have two or more ehci blocks. The added ehci blocks depend on >> >> the PHY to be initialized, and they can be used at same time as the >> >> "USB controller". That is the reason i add mutex and refcount for phy >> >> driver. >> > >> > alright, let's add refcounting to the generic PHY layer then. >> > >> >> 5. For the clock name. Can you describe it in details? For clkdev, if >> >> it want to find the clock, it still depends on the dev_name and >> >> con_id. >> > >> > right, the idea of clkdev is that you associate a clock provider with >> > its consumer by means of dev_name. Then you can fetch the clock from >> > driver with any name you want. Which means if you do you clkdev properly >> > you could: >> > >> > clk_get(dev, "clk1"); >> > clk_get(dev, "clk2"); >> > ... >> > >> > and so on. >> > >> >> It is same as what i think. >> The clock numbers and names are depent of SOCes, i do not want to fix > > no, they're not dependent on anything, not if you use clkdev correctly. > So 1. Does it mean that all SOCes clock driver should define same names such as "clk1", "clk2"? 2. Does it mean that if driver failed at clk_get, the probing will not stop because this SOC may define this clock? >> it in ther driver. So i use pdata to pass the clknum and clk names >> "clk1", "clk2" and so on. >> in the driver, i use >> devm_clk_get(&pdev->dev, pdata->clkname[i]); >> Do you think it is acceptable? > > no > >> When device tree for clock framework are supported, the things get >> easier, and it is my next step. > > not strong enough argument to accept passing clock names via > platform_data. > > -- > balbi -- 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
