On Monday 13 April 2009, Kevin Hilman wrote: > David Brownell <davi...@pacbell.net> writes: > > > On Tuesday 07 April 2009, Mark A. Greer wrote: > > > > >> Its unfortunate that the hook name in the drivers ATM is clk_enable(). > > > > I really *do not understand* where you're coming from at all. > > > > I think what Mark is getting at is that it's unfortunate that the > drivers only have a single hook to do device-specific stuff, and it's > directly tied to clocks.
I'd say that differently: they have few post-init hooks for anything except clock-specific stuff. And for that matter, most drivers leave clocks on all the time too... And when all you have is a hammer, everything starts to look like a nail! > We have run into this in OMAP as well for PM reasons and have been > tossing around some ideas to have a device_enable(), device_idle() > device_off() type of model instead of clk_enable/clk_disable. Inside > these functions, not only clocks could be managed but also other power > resources like regulators etc. and the saving of device conext may be > handled here too in case the powerdomain is going into off mode. That gets into interesting territory, since it expects devices fit into certain boxes ... "enabled", "idle", "off" for example. It's not uncommon for devices to have a hard time fitting into such small boxes: parts of them might be in one state, others might be in another one. It may be possible to analyse things so each part fits into such a box ... but not the whole device. If a device is a pure slave to the CPU, the models are likely to be simple: it can be in some low power mode -- maybe even completely off! -- whenever it's not being used. But when there is some ongoing responsibility in terms of external communications, there can be lots of nuances to what "enabled" or maybe "idle" means: active enough to be able to respond before a deadline, which may constraint a few other devices too. With USB, hosts can be suspended but with remote wakeup capability active: the differential D+/D- signal changes state. (This oddly seems to need a multi-MHz clock on most systems.) Ethernet links need to receive packets; etc. > It's possible that some muxing for some devices would be handled here > for runtime flexibility as well. Including "off-mode" handling for the balls, I could imagine. > How about this as a compromise: > > Until such a model exists, one could easily extend the current > situation by using platform_data hooks. Add 'device_enable' and > 'device_disable' hooks to the platform_data which can be created for > some of these problematic drivers. Experimenting with models is important ... it's hard to see what works, otherwise! :) That could be a good way to start. In terms of Mark's issues, those hooks would be where runtime resource conflicts would get resolved, like re-muxing. > Then, the drive does > > > clk_enable(); > if (pdata->device_enable) > device_enable(); This still seems to couple clocks and devices though. If there are multiple clocks, maybe they aren't all needed for the current bit of work. And maybe only a subset of other resources are needed too. Or to generalize ... there are lots of resources, and the ones that need to be activated are task-specific. - Dave > /* do work */ > > if (pdata->device_disable) > device_disable(); > clk_disable(); > > > Eventually, when the clk enable/disable itself would be moved into the > platform-specific enable/disable function when a modle is agreed upon > down the road. > > > Kevin > > > > > _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
