On Tue, Jan 05, 2010 at 04:21:11PM -0800, Kevin Hilman wrote: > Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> writes: > > > Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> writes: > > > >> On Mon, Dec 07, 2009 at 04:24:59PM -0800, Kevin Hilman wrote: > >>> <miguel.aguilar@xxxxxxxxxxxx> writes: > >>> > >>> > From: Miguel Aguilar <miguel.aguilar@xxxxxxxxxxxx> > >>> > > >>> > Add a function pointer in the platform data of the DaVinci Keyscan driver > >>> > called device_enabled, in order to perform board specific actions when > >>> > the device is initialized, like setup the PINMUX configuration. > >>> > > >>> > Signed-off-by: Miguel Aguilar <miguel.aguilar@xxxxxxxxxxxx> > >>> > >>> Signed-off-by: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> > >>> > >>> Dmitry, > >>> > >>> Will you be queueing this driver (and this patch) for 2.6.34? I > >>> thought you had accepted the original driver, but I don't see it in > >>> the master or next branch of your input tree at: > >>> > >>> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git > >> > >> The driver is there, commit bc09dcadc1a3da87d58aa70ebc8e9441205be75c on > >> 'next' branch (I don't really use master branch). It was committed back > >> in October, probably that's why you don't see it? > >> > >> As far as the patch goes - I got an impression from email sent by > >> Steve that there are ways to do automatic PINMUX detection and thus > >> this patch was not needed. Is this ture? > > > > The method Steve was referring to was done for MontaVista > > internal/product kernels but was rejected for upstream (by me) because > > of the way it was implemented (by tying mux settings to clock > > settings.) > > > >> If not I am stull unsure what happens if you unload the driver. How > >> do you restore the old configuration so that the device you took > >> over from can start working again? Maybe pinmux should be controlled > >> via sysfs attribute (in board code) so that user can switch on-fly > >> between the devices? > > > > The way we currently handle MUXing in davinci, you don't need to do > > anything after the driver unloads. Any other user of these pins will > > mux them as needed. > > > > If really necessary, we could do an equivalent 'device_disable' hook > > but there would be empty as it wouldn't be needed. > > > > So, speaking as maintainer of the DaVinci support, I'm in favor of this > > approach from Miguel. > > Dmitry, > > Unless there are further objectsions, could you please queue this > patch for 2.6.34 with my signoff? > Applied to for-linus, I do not see any reason in holding this patch till .34. Sorry for the delay. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
