linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miguel Aguilar <miguel.aguilar@ridgerun.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: davinci-linux-open-source@linux.davincidsp.com,
	nsnehaprabha@ti.com, linux-input@vger.kernel.org,
	todd.fischer@ridgerun.com, diego.dompe@ridgerun.com,
	clark.becker@ridgerun.com, santiago.nunez@ridgerun.com
Subject: Re: [PATCH v2 1/2] Input: Add device_enable handler to DaVinci	Keyscan platform data
Date: Thu, 19 Nov 2009 11:54:35 -0600	[thread overview]
Message-ID: <4B05865B.7060303@ridgerun.com> (raw)
In-Reply-To: <20091119165509.GA15647@core.coreip.homeip.net>

Dmitry Torokhov wrote:
> On Thu, Nov 19, 2009 at 10:32:21AM -0600, Miguel Aguilar wrote:
>> Hi Dmitry,
>>
>>>>  +	if (pdata->device_enable) {
>>>> +		error = pdata->device_enable(dev);
>>>> +		if (error < 0) {
>>>> +			dev_dbg(dev, "device enable function failed\n");
>>>> +			return error;
>>>> +		}
>>>> +	}
>>>> +
>>> Hi Miguel,
>>>
>>> Does this need to live in the driver? Why can't platform code do this
>>> for us?
>>>
>>> Thanks.
>>>
>> The reason to invoke the device_enable function in the driver is because 
>> in the testing process of the key scan driver a issue was found when the 
>> key scan is built as a module.
>>
>> There is a specific PINMUX configuration that only should be set if the 
>> key scan driver is loaded in the kernel to avoid pin conflicts. So when 
>> the key scan is built as a module the board file (or platform code) 
>> doesn't know if the key scan is loaded or not, so that's why the driver 
>> is the one who must invoke the device_enable function in the probe 
>> function.
>>
> 
> I see... What happens if PINMUX is set but there isn't a driver? Also,
> what happens when you unload the module? Don't you need a similar call
> to disable PINMUX configuration?
> 

Dmitry,

If PINMUX is set and there isn't the driver, the PINMUX configuration can 
overwrite the PINMUX configuration needed by other drivers which actually are 
loaded. This situation happens in the DM365 EVM, because the hardware design 
there are hardware modules that can't coexist, so handling the PINMUX 
configuration calling a function pointer is a safe way to ensure that the PINMUX 
is set only when the module is loaded.

Disable PINMUX configuration doesn't make sense, because there isn't a thing 
such disable PINMUX configuration, there are a lot of possible PINMUX 
combinations, and there is no combination that means disable, and also change 
the PINMUX configuration to a different state would be risky.

Is the responsibility of the platform code or of the driver in the 
initialization, like in the case of the key scan, to set the needed PINMUX 
configuration for running the module properly.

Thanks,
Miguel Aguilar


  reply	other threads:[~2009-11-19 17:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-13 19:43 [PATCH v2 1/2] Input: Add device_enable handler to DaVinci Keyscan platform data miguel.aguilar
2009-11-19  2:59 ` Dmitry Torokhov
2009-11-19 16:32   ` Miguel Aguilar
2009-11-19 16:55     ` Dmitry Torokhov
2009-11-19 17:54       ` Miguel Aguilar [this message]
2009-11-19 20:33         ` Dmitry Torokhov
2009-11-19 20:59           ` Miguel Aguilar
2009-11-19 21:33             ` Narnakaje, Snehaprabha
2009-11-24 16:49               ` Miguel Aguilar
2009-12-01 17:08               ` Steve Chen
2009-12-08  0:24 ` Kevin Hilman
2009-12-08  0:48   ` Dmitry Torokhov
2009-12-08  1:05     ` Kevin Hilman
     [not found]       ` <877hsy46o0.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2010-01-06  0:21         ` Kevin Hilman
2010-01-06  8:26           ` Dmitry Torokhov
2010-01-06 17:04             ` Kevin Hilman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B05865B.7060303@ridgerun.com \
    --to=miguel.aguilar@ridgerun.com \
    --cc=clark.becker@ridgerun.com \
    --cc=davinci-linux-open-source@linux.davincidsp.com \
    --cc=diego.dompe@ridgerun.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=nsnehaprabha@ti.com \
    --cc=santiago.nunez@ridgerun.com \
    --cc=todd.fischer@ridgerun.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).