* Jon Hunter <jon-hunter@xxxxxx> [130204 07:09]: > > On 02/02/2013 12:11 PM, Tony Lindgren wrote: > > * Jon Hunter <jon-hunter@xxxxxx> [130201 17:25]: > >> > >> On 02/01/2013 03:51 PM, Tony Lindgren wrote: > >>> > >>> How about let's fix this properly to start with so we don't add > >>> more blockers moving this code to drivers/bus? > >>> > >>> Looks like gpmc_mem_init() gets called from gpmc_probe() so > >>> we can pass that information in pdev. > >> > >> I wondered if you would suggest that ;-) > > > > :) > > > >> I definitely can and it is probably best. Things like this become > >> painful when we move to device-tree. We really need a generic way for > >> passing stuff like this to drivers for omap. Our options are auxdata or > >> bus notifiers. I am wondering whether we can plug pdata in the > >> omap_device bus notifier for device-tree. Let me know if you have any > >> thoughts. > > > > Hmm but in this case can't you just do it based on the compatible > > flag? For legacy systems we also need to pass it in pdata. > > This is a boot-time configuration. So really you need to read the > control status register at boot and then determine the mapping. We could > store the address of the control status read in the pdata, but I think > that is a bit of a hack. Ah right. Well once we have Haojian's generic pinconf patches merged for pinctrl-single, we can set up the CONTROL_STATUS register as a pinctrl-single,bits register and query the SYSBOOT_3 pin value directly from the driver. AFAIK SYSBOOT_n values reflect the boot time values of the actual SYSBOOT pins, so using generic pinconf there makes sense. But this of course should be checked. > > Regarding omap_device, we should find a way to keep the dependencies > > between drivers and the bus code down to minimum. So ideally things > > like this would be only done using just the compatible flag. But the > > pdata we cannot remove quite yet. > > Agree. However, there are several drivers today (gpio, dmtimer, mmc, > serial, dss, etc), that make use of a function pointer to > omap_pm_get_dev_context_loss_count() to determine when the peripheral's > state has been lost. When booting with DT this function pointer is not > populated and so with DT we currently have no way to determine this. I > see this as a blocker to migrating completely to DT. Ideally we would > find a way for RPM to handle this and remove the function pointer. > However, right now we still need a generic way to pass this type of > platform data to drivers. Yeah pinconf generic won't help us with the legacy boot. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
