All of lore.kernel.org
 help / color / mirror / Atom feed
From: viresh.kumar@st.com (viresh kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 1/3] drivers/pwm st_pwm: Add support for ST's Pulse Width Modulator
Date: Tue, 7 Jun 2011 15:40:17 +0530	[thread overview]
Message-ID: <4DEDF909.2000608@st.com> (raw)
In-Reply-To: <201106070928.53761.arnd@arndb.de>

On 06/07/2011 12:58 PM, Arnd Bergmann wrote:
> On Tuesday 07 June 2011 05:55:25 viresh kumar wrote:
>>>> +static int __devinit st_pwm_probe(struct platform_device *pdev)
>>>
>>> And here things get rather odd.
>>>
>>> Most of this file is a generic, non-device specific PWM layer, exported
>>> to other modules.  But then we get into driver bits which are specific
>>> to one paritular type of device.  Confused - this is like putting the
>>> e100 driver inside net/ipv4/tcp.c?
>>>
>>
>> Sorry but i couldn't get this one completely. :(
>> Driver is specific to pwm peripheral by ST. This driver can be used for
>> SPEAr or may be other SoC or Devices, and is not at all dependent on SPEAr.
> 
> 

Now i get the question correctly. :)

> It was my suggestion to start drivers/pwm/ with this driver. We currently
> have a number of pwm drivers spread over the entire tree, all using slight
> the same interface header. They all look like this one, and are each used
> on one SOC, so you have to choose at compile-time which one to use.
> 
> There are two problems with this of course:
> 1. the drivers that export the same interface should be in one directory
> 2. there should be a common abstraction layer to avoid duplicate code and
>    enable building a kernel with multiple PWM drivers builtin.
> 
> Moving this driver to drivers/pwm is the first step to address the
> problem 1, we will move the other drivers in the 3.1 or 3.2 timeframe.
> 
> There is independent by Sascha Hauer to work on the abstraction layer
> for all the drivers. Once that is in, we will change the individual drivers
> in drivers/pwm accordingly.
> 

Above was exactly the reason why i didn't separated framework from device
specific part. As soon as framework is pushed, i will update my driver to
work with it.

-- 
viresh

WARNING: multiple messages have this Message-ID (diff)
From: viresh kumar <viresh.kumar@st.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Armando VISCONTI <armando.visconti@st.com>,
	Shiraz HASHIM <shiraz.hashim@st.com>,
	Vipin KUMAR <vipin.kumar@st.com>,
	Rajeev KUMAR <rajeev-dlh.kumar@st.com>,
	Deepak SIKRI <deepak.sikri@st.com>,
	Vipul Kumar SAMAR <vipulkumar.samar@st.com>,
	Amit VIRDI <Amit.VIRDI@st.com>,
	Pratyush ANAND <pratyush.anand@st.com>,
	Bhupesh SHARMA <bhupesh.sharma@st.com>,
	"viresh.linux@gmail.com" <viresh.linux@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V2 1/3] drivers/pwm st_pwm: Add support for ST's Pulse Width Modulator
Date: Tue, 7 Jun 2011 15:40:17 +0530	[thread overview]
Message-ID: <4DEDF909.2000608@st.com> (raw)
In-Reply-To: <201106070928.53761.arnd@arndb.de>

On 06/07/2011 12:58 PM, Arnd Bergmann wrote:
> On Tuesday 07 June 2011 05:55:25 viresh kumar wrote:
>>>> +static int __devinit st_pwm_probe(struct platform_device *pdev)
>>>
>>> And here things get rather odd.
>>>
>>> Most of this file is a generic, non-device specific PWM layer, exported
>>> to other modules.  But then we get into driver bits which are specific
>>> to one paritular type of device.  Confused - this is like putting the
>>> e100 driver inside net/ipv4/tcp.c?
>>>
>>
>> Sorry but i couldn't get this one completely. :(
>> Driver is specific to pwm peripheral by ST. This driver can be used for
>> SPEAr or may be other SoC or Devices, and is not at all dependent on SPEAr.
> 
> 

Now i get the question correctly. :)

> It was my suggestion to start drivers/pwm/ with this driver. We currently
> have a number of pwm drivers spread over the entire tree, all using slight
> the same interface header. They all look like this one, and are each used
> on one SOC, so you have to choose at compile-time which one to use.
> 
> There are two problems with this of course:
> 1. the drivers that export the same interface should be in one directory
> 2. there should be a common abstraction layer to avoid duplicate code and
>    enable building a kernel with multiple PWM drivers builtin.
> 
> Moving this driver to drivers/pwm is the first step to address the
> problem 1, we will move the other drivers in the 3.1 or 3.2 timeframe.
> 
> There is independent by Sascha Hauer to work on the abstraction layer
> for all the drivers. Once that is in, we will change the individual drivers
> in drivers/pwm accordingly.
> 

Above was exactly the reason why i didn't separated framework from device
specific part. As soon as framework is pushed, i will update my driver to
work with it.

-- 
viresh

  reply	other threads:[~2011-06-07 10:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-31  8:51 [PATCH V2 0/3] Add drivers/pwm and drivers/pwm/st_pwm.c Viresh Kumar
2011-05-31  8:51 ` Viresh Kumar
2011-05-31  8:51 ` [PATCH V2 1/3] drivers/pwm st_pwm: Add support for ST's Pulse Width Modulator Viresh Kumar
2011-06-07 10:17   ` [PATCH V3 " Viresh Kumar
2011-06-07  0:33   ` [PATCH V2 " Andrew Morton
2011-06-07  0:33     ` Andrew Morton
2011-06-07  3:55     ` viresh kumar
2011-06-07  3:55       ` viresh kumar
2011-06-07  7:28       ` Arnd Bergmann
2011-06-07  7:28         ` Arnd Bergmann
2011-06-07 10:10         ` viresh kumar [this message]
2011-06-07 10:10           ` viresh kumar
2011-05-31  8:51 ` [PATCH V2 2/3] SPEAr3xx: Add machine support for ST's PWM IP Viresh Kumar
2011-05-31  8:51   ` Viresh Kumar
2011-05-31  8:51 ` [PATCH V2 3/3] SPEAr3xx: Update defconfig for ST's PWM Viresh Kumar
2011-05-31  8:51   ` Viresh Kumar
2011-06-27 11:12 ` [PATCH V2 0/3] Add drivers/pwm and drivers/pwm/st_pwm.c viresh kumar
2011-06-27 11:12   ` viresh kumar
2011-06-27 13:26   ` Arnd Bergmann
2011-06-27 13:26     ` Arnd Bergmann
2011-06-28 10:04     ` Sascha Hauer
2011-06-28 10:04       ` Sascha Hauer
2011-06-28 15:13       ` Arnd Bergmann
2011-06-28 15:13         ` Arnd Bergmann
2011-06-29  9:14         ` Sascha Hauer
2011-06-29  9:14           ` Sascha Hauer
2011-06-29  9:35           ` viresh kumar
2011-06-29  9:35             ` viresh kumar

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=4DEDF909.2000608@st.com \
    --to=viresh.kumar@st.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.