On Mon, Aug 25, 2014 at 02:44:10PM +0200, Maxime Ripard wrote: > On Mon, Aug 25, 2014 at 02:12:30PM +0200, Thierry Reding wrote: > > On Wed, Aug 13, 2014 at 07:01:06PM +0200, Maxime Ripard wrote: > > > On Wed, Aug 13, 2014 at 10:38:09AM -0600, Stephen Warren wrote: > > [...] > > > > If not, perhaps the clock driver should force the clock to be > > > > enabled (perhaps only if the DRM/KMS driver isn't enabled?). > > > > > > I'm sorry, but I'm not going to take any code that will do that in our > > > clock driver. > > > > > > I'm not going to have a huge list of ifdef depending on configuration > > > options to know which clock to enable, especially when clk_get should > > > have the consumer device as an argument. > > > > Are you saying is that you want to solve a platform-specific problem by > > pushing code into simple, generic drivers so that your platform code can > > stay "clean"? > > Are you saying that this driver would become "dirty" with such a patch? Yes. Others have said the same and even provided alternative solutions on how to solve what's seemingly a platform-specific problem in a platform-specific way. > If so, we really have an issue in the kernel. Can you elaborate? Thierry
Attachment:
pgpWUgyai4rEB.pgp
Description: PGP signature
