From: Grant Erickson <marathon96@gmail.com>
To: Kevin Hilman <khilman@deeprootsystems.com>
Cc: linux-omap@vger.kernel.org, Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers
Date: Tue, 16 Nov 2010 11:39:42 -0800 [thread overview]
Message-ID: <C9081DFE.1FEE7%marathon96@gmail.com> (raw)
In-Reply-To: <87mxp9f6sp.fsf@deeprootsystems.com>
On 11/16/10 10:43 AM, Kevin Hilman wrote:
> Grant Erickson <marathon96@gmail.com> writes:
>> On 11/16/10 9:01 AM, Kevin Hilman wrote:
>>> Grant Erickson <marathon96@gmail.com> writes:
>>>> This patch adds support to request and use one or more of the OMAP
>>>> dual-mode timers as a generic PWM device compatible with other generic
>>>> PWM drivers such as the PWM backlight or PWM beeper driver.
>>>
>>> How will this co-exist with the PWM on the twl6030 PMIC
>>> (drivers/mfd/twl6030-pwm.c.)? Both are exporting the same API.
>>
>> That's an excellent question. This driver started life in the 2.6.32 tree
>> where twl6030-pwm.c didn't exist. Thanks for the heads-up.
>>
>> The right short-term solution is to probably change the configuration from:
>>
>> config HAVE_PWM
>>
>> to:
>>
>> config OMAP_PWM
>> select HAVE_PWM
>>
>> and then have it conflict with TWL6030_PWM if that's enabled.
>
> And what happens when other PWM sources are added?
More conflicts, of course.
>> With the appropriate configuration change to avoid the conflict with
>> TWL6030-PWM, it's probably better to have this driver in-tree than not.
>
> Well, Tony will make the final call here, but I disagree that this
> should merge in its current form.
Understood.
> Before something like this can merge, I would rather see
>
> 1) generic PWM framework pushed along and merged
> 2) the dmtimer hwmod conversion finished
>
> Yes, I know it's a lot more work to fix the core/framework code before
> having a feature included, but having something more generic that can
> actually support multiple PWM sources is clearly needed.
No disagreement on the long-term architectural and design goals. All good
stuff.
However, patches have to be submitted against the repository and branch we
have today, not those we might have tomorrow.
When (1) is in place in the linux-omap GIT, I am happy to work on
refactoring the driver as necessary.
Thanks again for your feedback and input.
Best,
Grant
next prev parent reply other threads:[~2010-11-16 19:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-14 19:28 [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers Grant Erickson
2010-11-16 12:37 ` Hemanth V
2010-11-16 17:45 ` Grant Erickson
2010-11-17 9:58 ` Hemanth V
2010-11-16 12:42 ` Felipe Balbi
2010-11-16 18:00 ` Grant Erickson
2010-11-16 17:01 ` Kevin Hilman
2010-11-16 18:13 ` Grant Erickson
2010-11-16 18:43 ` Kevin Hilman
2010-11-16 19:39 ` Grant Erickson [this message]
2010-11-16 19:52 ` Kevin Hilman
2010-11-16 20:20 ` Tony Lindgren
2010-11-16 18:54 ` Premi, Sanjeev
2010-11-16 19:11 ` Grant Erickson
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=C9081DFE.1FEE7%marathon96@gmail.com \
--to=marathon96@gmail.com \
--cc=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.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).