From: Lars-Peter Clausen <lars@metafoo.de>
To: Arun MURTHY <arun.murthy@stericsson.com>
Cc: "eric.y.miao@gmail.com" <eric.y.miao@gmail.com>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"grinberg@compulab.co.il" <grinberg@compulab.co.il>,
"mike@compulab.co.il" <mike@compulab.co.il>,
"robert.jarzmik@free.fr" <robert.jarzmik@free.fr>,
"marek.vasut@gmail.com" <marek.vasut@gmail.com>,
"drwyrm@gmail.com" <drwyrm@gmail.com>,
"stefan@openezx.org" <stefan@openezx.org>,
"laforge@openezx.org" <laforge@openezx.org>,
"ospite@studenti.unina.it" <ospite@studenti.unina.it>,
"philipp.zabel@gmail.com" <philipp.zabel@gmail.com>,
"mad_soft@inbox.ru" <mad_soft@inbox.ru>,
"maz@misterjones.org" <maz@misterjones.org>,
"daniel@caiaq.de" <daniel@caiaq.de>,
"haojian.zhuang@marvell.com" <haojian.zhuang@marvell.com>,
"timur@freescale.com" <timur@freescale.com>,
"ben-linux@fluff.org" <ben-linux@fluff.org>,
"support@simtec.co.uk" <support@simtec.co.uk>,
"arnaud.patard@rtp-net.org" <arnaud.patard@rtp-net.org>,
"dgreenday@gmail.com" <dgreenday@gmail.com>,
"anarsoul@gmail.com" <anarsoul@gmail.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"mcuelenaere@gmail.com" <mcuelenaere@gmail.com>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"andre.goddard@gmail.com" <andre.goddard@gmail.com>,
"jkosina@suse.cz" <jkosina@suse.cz>,
"tj@kernel.org" <tj@kernel.org>,
"hsweeten@visionengravers.com" <hsweeten@visionengravers.com>,
"u.kleine-koenig@pengutronix.de" <u.kleine-koenig@pengutronix.de>,
"kgene.kim@samsung.com" <kgene.kim@samsung.com>,
"ralf@linux-mips.org" <ralf@linux-mips.org>,
"dilinger@collabora.co.uk" <dilinger@collabora.co.uk>,
"mroth@nessie.de" <mroth@nessie.de>,
"randy.dunlap@oracle.com" <randy.dunlap@oracle.com>,
"lethal@linux-sh.org" <lethal@linux-sh.org>,
"rusty@rustcorp.com.au" <rusty@rustcorp.com.au>,
"damm@opensource.se" <damm@opensource.se>,
"mst@redhat.com" <mst@redhat.com>,
"rpurdie@rpsys.net" <rpurdie@rpsys.net>,
"sguinot@lacie.co" <sguinot@lacie.co>,
"sameo@linux.intel.com" <sameo@linux.intel.com>,
"broonie@opensource.wolfsonmicro.com"
<broonie@opensource.wolfsonmicro.com>,
"balajitk@ti.com" <balajitk@ti.com>,
"rnayak@ti.com" <rnayak@ti.com>,
"santosh.shilimkar@ti.com" <santosh.shilimkar@ti.com>,
"hemanthv@ti.com" <hemanthv@ti.com>,
"michael.hennerich@analog.com" <michael.hennerich@analog.com>,
"vapier@gentoo.org" <vapier@gentoo.org>,
"jic23@cam.ac.uk" <jic23@cam.ac.uk>,
"re.emese@gmail.com" <re.emese@gmail.com>,
"linux@simtec.co.uk" <linux@simtec.co.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
Linus WALLEIJ <linus.walleij@stericsson.com>,
Mattias WALLIN <mattias.wallin@stericsson.com>
Subject: Re: [PATCH 1/7] pwm: Add pwm core driver
Date: Tue, 28 Sep 2010 11:57:42 +0200 [thread overview]
Message-ID: <4CA1BC16.3020702@metafoo.de> (raw)
In-Reply-To: <F45880696056844FA6A73F415B568C69532DC2FB6B@EXDCVYMBSTM006.EQ1STM.local>
Arun MURTHY wrote:
>>> +menuconfig PWM_DEVICES
>>> + bool "PWM devices"
>>> + default y
>>> + ---help---
>>> + Say Y here to get to see options for device drivers from
>> various
>>> + different categories. This option alone does not add any kernel
>> code.
>>> +
>>> + If you say N, all options in this submenu will be skipped and
>> disabled.
>>> +
>> Shouldn't PWM_DEVICES select HAVE_PWM?
>
>
> No not required, the entire concept is to remove HAVE_PWM and use PWM_CORE.
Well in patch 4 you say that PWM_CORE is currently limited to ARM. Furthermore you
change the pwm-backlight and pwm-led Kconfig entries to depend on HAVE_PWM ||
PWM_CORE. Adding a select HAVE_PWM here would make those changes unnecessary.
HAVE_PWM should be set, when pwm_* functions are available. When your pwm-core driver
is selected they are available.
>
>>> +struct pwm_dev_info {
>>> + struct pwm_device *pwm_dev;
>>> + struct list_head list;
>>> +};
>>> +static struct pwm_dev_info *di;
>> Why not embed the list head into pwm_device. That would certainly make
>> pwm_device_unregister much simpler.
> pwm_device will be passed to each and every pwm driver that are registered as client with pwm core.
> The list consists of the registered pwm drivers and is to be handled by pwm core.
> Why should each and every pwm driver get to know about the entire pwm driver list?
Declare the list field to be private, by saying that it should only be touched by the
core. Right now you allocate a rather small additional structure for each registered
device. This could be easily be avoided by embedding the list field into the
pwm_device struct.
> And also since the pwm_request/register/unregister are the one which require this list having this list inst in local/static device information structure seems to be right.
>
>>> + }
>>> + pwm->pwm_dev = pwm_dev;
>>> + list_add_tail(&pwm->list, &di->list);
>>> + up_write(&pwm_list_lock);
>>> +
>> I guess you only need to lock the list when accessing the list and
>> adding the new
>> pwm_dev.
>
> Oops, thanks for pointing out, will implement this in the v2 patch.
>>> +struct pwm_ops {
>>> + int (*pwm_config)(struct pwm_device *pwm, int duty_ns, int
>> period_ns);
>>> + int (*pwm_enable)(struct pwm_device *pwm);
>>> + int (*pwm_disable)(struct pwm_device *pwm);
>>> + char *name;
>>> +};
>>> +
>> Shouldn't name be part of the pwm_device? That would allow the ops to
>> be shared
>> between different devices.
> Good catch, the reason being that 2 or more devices can share the same ops and get registered to pwm core.
> But the catch lies while identifying the pwm device while the clients are requesting for.
> The pwm backlight will request the pwm driver by name. This is parameter that distinguishes among different pwm devices irrespective of same ops or not.
Yes. And thats why it should go into the pwm_device struct itself.
If an additional ops struct is allocated for each device anyway we would be better of
embedding it directly into the device struct instead of just holding a pointer to it.
>
>>> +int pwm_device_register(struct pwm_device *pwm_dev);
>>> +int pwm_device_unregister(struct pwm_device *pwm_dev);
>>> +
>>> #endif /* __LINUX_PWM_H */
>> It might be also a good idea to add a device class for pwm devices.
> Sure, but can you please explain with an example the use case.
>
Well, for one it helps to keep data structured.
And there would be functions to traverse all devices of a class, so you could get rid
of your "di" list.
> Thanks and Regards,
> Arun R Murthy
> -------------
>
- Lars
WARNING: multiple messages have this Message-ID (diff)
From: lars@metafoo.de (Lars-Peter Clausen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/7] pwm: Add pwm core driver
Date: Tue, 28 Sep 2010 11:57:42 +0200 [thread overview]
Message-ID: <4CA1BC16.3020702@metafoo.de> (raw)
In-Reply-To: <F45880696056844FA6A73F415B568C69532DC2FB6B@EXDCVYMBSTM006.EQ1STM.local>
Arun MURTHY wrote:
>>> +menuconfig PWM_DEVICES
>>> + bool "PWM devices"
>>> + default y
>>> + ---help---
>>> + Say Y here to get to see options for device drivers from
>> various
>>> + different categories. This option alone does not add any kernel
>> code.
>>> +
>>> + If you say N, all options in this submenu will be skipped and
>> disabled.
>>> +
>> Shouldn't PWM_DEVICES select HAVE_PWM?
>
>
> No not required, the entire concept is to remove HAVE_PWM and use PWM_CORE.
Well in patch 4 you say that PWM_CORE is currently limited to ARM. Furthermore you
change the pwm-backlight and pwm-led Kconfig entries to depend on HAVE_PWM ||
PWM_CORE. Adding a select HAVE_PWM here would make those changes unnecessary.
HAVE_PWM should be set, when pwm_* functions are available. When your pwm-core driver
is selected they are available.
>
>>> +struct pwm_dev_info {
>>> + struct pwm_device *pwm_dev;
>>> + struct list_head list;
>>> +};
>>> +static struct pwm_dev_info *di;
>> Why not embed the list head into pwm_device. That would certainly make
>> pwm_device_unregister much simpler.
> pwm_device will be passed to each and every pwm driver that are registered as client with pwm core.
> The list consists of the registered pwm drivers and is to be handled by pwm core.
> Why should each and every pwm driver get to know about the entire pwm driver list?
Declare the list field to be private, by saying that it should only be touched by the
core. Right now you allocate a rather small additional structure for each registered
device. This could be easily be avoided by embedding the list field into the
pwm_device struct.
> And also since the pwm_request/register/unregister are the one which require this list having this list inst in local/static device information structure seems to be right.
>
>>> + }
>>> + pwm->pwm_dev = pwm_dev;
>>> + list_add_tail(&pwm->list, &di->list);
>>> + up_write(&pwm_list_lock);
>>> +
>> I guess you only need to lock the list when accessing the list and
>> adding the new
>> pwm_dev.
>
> Oops, thanks for pointing out, will implement this in the v2 patch.
>>> +struct pwm_ops {
>>> + int (*pwm_config)(struct pwm_device *pwm, int duty_ns, int
>> period_ns);
>>> + int (*pwm_enable)(struct pwm_device *pwm);
>>> + int (*pwm_disable)(struct pwm_device *pwm);
>>> + char *name;
>>> +};
>>> +
>> Shouldn't name be part of the pwm_device? That would allow the ops to
>> be shared
>> between different devices.
> Good catch, the reason being that 2 or more devices can share the same ops and get registered to pwm core.
> But the catch lies while identifying the pwm device while the clients are requesting for.
> The pwm backlight will request the pwm driver by name. This is parameter that distinguishes among different pwm devices irrespective of same ops or not.
Yes. And thats why it should go into the pwm_device struct itself.
If an additional ops struct is allocated for each device anyway we would be better of
embedding it directly into the device struct instead of just holding a pointer to it.
>
>>> +int pwm_device_register(struct pwm_device *pwm_dev);
>>> +int pwm_device_unregister(struct pwm_device *pwm_dev);
>>> +
>>> #endif /* __LINUX_PWM_H */
>> It might be also a good idea to add a device class for pwm devices.
> Sure, but can you please explain with an example the use case.
>
Well, for one it helps to keep data structured.
And there would be functions to traverse all devices of a class, so you could get rid
of your "di" list.
> Thanks and Regards,
> Arun R Murthy
> -------------
>
- Lars
next prev parent reply other threads:[~2010-09-28 9:58 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-28 7:40 [PATCHv2 0/7] PWM core driver for pwm based led and backlight driver Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 7:40 ` [PATCH 1/7] pwm: Add pwm core driver Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 8:14 ` Vasily Khoruzhick
2010-09-28 8:14 ` Vasily Khoruzhick
2010-09-28 8:38 ` Arun MURTHY
2010-09-28 8:47 ` Vasily Khoruzhick
2010-09-28 8:47 ` Vasily Khoruzhick
2010-09-28 8:57 ` Arun MURTHY
[not found] ` <F45880696056844FA6A73F415B568C69532DC2FA8F@EXDCVYMBSTM006.EQ1STM.loca l>
2010-09-28 8:50 ` Hemanth V
2010-09-28 8:50 ` Hemanth V
2010-09-28 9:03 ` Arun MURTHY
[not found] ` <F45880696056844FA6A73F415B568C69532DC2FB21@EXDCVYMBSTM006.EQ1STM.loca l>
2010-09-28 9:34 ` Hemanth V
2010-09-28 9:34 ` Hemanth V
2010-09-28 9:34 ` Hemanth V
2010-09-28 9:49 ` Arun MURTHY
2010-09-28 9:49 ` Arun MURTHY
[not found] ` <F45880696056844FA6A73F415B568C69532DC2FBF9@EXDCVYMBSTM006.EQ1STM.loca l>
2010-09-28 10:41 ` Hemanth V
2010-09-28 10:41 ` Hemanth V
2010-09-28 10:41 ` Hemanth V
2010-09-28 10:53 ` Arun MURTHY
2010-09-28 8:54 ` Lars-Peter Clausen
2010-09-28 8:54 ` Lars-Peter Clausen
2010-09-28 9:18 ` Arun MURTHY
2010-09-28 9:57 ` Lars-Peter Clausen [this message]
2010-09-28 9:57 ` Lars-Peter Clausen
2010-09-28 10:28 ` Arun MURTHY
2010-09-28 21:04 ` Lars-Peter Clausen
2010-09-28 21:04 ` Lars-Peter Clausen
2010-09-28 21:04 ` Lars-Peter Clausen
2010-09-28 21:04 ` Lars-Peter Clausen
2010-09-29 4:49 ` Arun MURTHY
2010-09-29 4:49 ` Arun MURTHY
2010-09-29 4:49 ` Arun MURTHY
2010-09-29 12:12 ` Trilok Soni
2010-09-29 12:12 ` Trilok Soni
2010-09-29 12:12 ` Trilok Soni
2010-10-01 3:25 ` Arun MURTHY
2010-10-01 3:25 ` Arun MURTHY
2010-10-01 3:25 ` Arun MURTHY
2010-10-01 6:47 ` Trilok Soni
2010-10-01 6:47 ` Trilok Soni
2010-10-01 6:47 ` Trilok Soni
2010-10-01 7:25 ` Arun MURTHY
2010-10-01 7:25 ` Arun MURTHY
2010-10-01 7:25 ` Arun MURTHY
2010-10-01 7:42 ` Jassi Brar
2010-10-01 7:42 ` Jassi Brar
2010-10-01 7:42 ` Jassi Brar
2010-10-01 8:46 ` Arun MURTHY
2010-10-01 8:46 ` Arun MURTHY
2010-10-01 8:46 ` Arun MURTHY
2010-10-01 10:39 ` Jassi Brar
2010-10-01 10:39 ` Jassi Brar
2010-10-01 10:39 ` Jassi Brar
2010-10-01 18:00 ` Mark Brown
2010-10-01 18:00 ` Mark Brown
2010-10-01 18:00 ` Mark Brown
2010-10-04 4:22 ` Arun MURTHY
2010-10-04 4:22 ` Arun MURTHY
2010-10-04 4:22 ` Arun MURTHY
2010-09-28 17:46 ` Mark Brown
2010-09-28 17:46 ` Mark Brown
2010-09-28 19:42 ` Ryan Mallon
2010-09-28 19:42 ` Ryan Mallon
2010-09-28 7:40 ` [PATCH 2/7] backlight:pwm: add an element 'name' to platform data Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 17:47 ` Mark Brown
2010-09-28 17:47 ` Mark Brown
2010-09-28 7:40 ` [PATCH 3/7] leds: pwm: add a new " Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 8:01 ` Eric Miao
2010-09-28 8:01 ` Eric Miao
2010-09-28 8:36 ` Arun MURTHY
2010-09-28 8:36 ` Arun MURTHY
2010-09-28 7:40 ` [PATCH 4/7] pwm: Align existing pwm drivers with pwm-core driver Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 8:58 ` Lars-Peter Clausen
2010-09-28 8:58 ` Lars-Peter Clausen
2010-09-28 9:26 ` Arun MURTHY
2010-09-28 10:10 ` Lars-Peter Clausen
2010-09-28 10:10 ` Lars-Peter Clausen
2010-09-28 10:33 ` Arun MURTHY
2010-09-28 7:40 ` [PATCH 5/7] platform: Update the pwm based led and backlight platform data Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 7:40 ` [PATCH 6/7] pwm: move existing pwm driver to drivers/pwm Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 8:02 ` Eric Miao
2010-09-28 7:40 ` [PATCH 7/7] pwm: Modify backlight and led Kconfig aligning to pwm core Arun Murthy
2010-09-28 7:40 ` Arun Murthy
2010-09-28 7:40 ` Arun Murthy
-- strict thread matches above, loose matches on Subject: below --
2010-09-28 10:35 [PATCH 0/7] PWM core driver for pwm based led and backlight driver Arun Murthy
2010-09-28 10:35 ` [PATCH 1/7] pwm: Add pwm core driver Arun Murthy
2010-09-28 10:35 ` Arun Murthy
2010-09-28 10:35 ` Arun Murthy
2010-09-28 12:53 ` Hemanth V
2010-09-28 12:53 ` Hemanth V
2010-09-28 12:53 ` Hemanth V
2010-09-28 13:06 ` Samuel Ortiz
2010-09-28 13:06 ` Samuel Ortiz
2010-09-28 13:35 ` Felipe Balbi
2010-09-28 13:35 ` Felipe Balbi
2010-09-28 13:35 ` Felipe Balbi
2010-09-28 10:35 ` Arun Murthy
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=4CA1BC16.3020702@metafoo.de \
--to=lars@metafoo.de \
--cc=akpm@linux-foundation.org \
--cc=anarsoul@gmail.com \
--cc=andre.goddard@gmail.com \
--cc=arnaud.patard@rtp-net.org \
--cc=arun.murthy@stericsson.com \
--cc=balajitk@ti.com \
--cc=ben-linux@fluff.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=damm@opensource.se \
--cc=daniel@caiaq.de \
--cc=dgreenday@gmail.com \
--cc=dilinger@collabora.co.uk \
--cc=drwyrm@gmail.com \
--cc=eric.y.miao@gmail.com \
--cc=grinberg@compulab.co.il \
--cc=haojian.zhuang@marvell.com \
--cc=hemanthv@ti.com \
--cc=hsweeten@visionengravers.com \
--cc=jic23@cam.ac.uk \
--cc=jkosina@suse.cz \
--cc=kernel@pengutronix.de \
--cc=kgene.kim@samsung.com \
--cc=laforge@openezx.org \
--cc=lethal@linux-sh.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux@arm.linux.org.uk \
--cc=linux@simtec.co.uk \
--cc=mad_soft@inbox.ru \
--cc=marek.vasut@gmail.com \
--cc=mattias.wallin@stericsson.com \
--cc=maz@misterjones.org \
--cc=mcuelenaere@gmail.com \
--cc=michael.hennerich@analog.com \
--cc=mike@compulab.co.il \
--cc=mroth@nessie.de \
--cc=mst@redhat.com \
--cc=ospite@studenti.unina.it \
--cc=philipp.zabel@gmail.com \
--cc=ralf@linux-mips.org \
--cc=randy.dunlap@oracle.com \
--cc=re.emese@gmail.com \
--cc=rnayak@ti.com \
--cc=robert.jarzmik@free.fr \
--cc=rpurdie@rpsys.net \
--cc=rusty@rustcorp.com.au \
--cc=sameo@linux.intel.com \
--cc=santosh.shilimkar@ti.com \
--cc=sguinot@lacie.co \
--cc=stefan@openezx.org \
--cc=support@simtec.co.uk \
--cc=timur@freescale.com \
--cc=tj@kernel.org \
--cc=u.kleine-koenig@pengutronix.de \
--cc=vapier@gentoo.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.