* Re: RFC - size tool for kernel build system
From: Robin Getz @ 2008-10-09 18:34 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Tim Bird, linux-embedded, linux kernel
In-Reply-To: <20081009152151.GB17013@cs181140183.pp.htv.fi>
On Thu 9 Oct 2008 11:21, Adrian Bunk pondered:
> On Tue, Oct 07, 2008 at 02:19:36PM -0700, Tim Bird wrote:
> > I've been thinking about a tool that might be useful
> > to track kernel size changes. I'm posting this
> > Request For Comments to get feedback, and determine
> > if this is something that would be worthwhile to
> > pursue.
> >
> > What I envision is some new kernel build targets, specifically
> > related to gathering size information and generating a size
> > comparison report. Some small helper scripts would be written
> > to gather the necessary information, and generate the report.
> >...
> > Any comments?
>
> The building blocks that would be useful are IMHO:
> - a make target that generates a report for one kernel
> (like the checkstack or export_report targets)
and the report includes sizes of more than just the text section? Which is my
biggest pet peeve with bloat-o-meter today, since it uses nm, not readelf -
and saving data is just as important as saving instruction.
> - a script that compares two such reports and outputs the
> size differences
>
> That's also easy to do, and if that's what's wanted I can send a patch
> that does it.
>
> Everything else is IMHO overdesigned.
I understand the desire though - make it easier to compare two setups.
capturing a make target into a file, (make size_report > config1.size) and
running a compare on two outputs seems like a more "standard" way of doing
things...
^ permalink raw reply
* Re: RFC - size tool for kernel build system
From: Jörn Engel @ 2008-10-09 16:03 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Tim Bird, linux-embedded, linux kernel
In-Reply-To: <20081009152151.GB17013@cs181140183.pp.htv.fi>
On Thu, 9 October 2008 18:21:51 +0300, Adrian Bunk wrote:
>
> The building blocks that would be useful are IMHO:
> - a make target that generates a report for one kernel
> (like the checkstack or export_report targets)
> - a script that compares two such reports and outputs the
> size differences
>
> That's also easy to do, and if that's what's wanted I can send a patch
> that does it.
>
> Everything else is IMHO overdesigned.
Please do.
> The real problem is that dumping some scripts into the kernel sources
> or publishing some data on a webpage doesn't make people use them.
>
> Like if you run "make checkstack" on the kernel today you can see that
> drivers allocate arrays > 1 kB on the stack despite checkstack being
> available...
Funny you should mention that. Yesterday I noticed that make checkstack
had been ported to five more architectures since my last look at the
code. It doesn't seem likely that those ports were required by some
pointy-haired boss for feature-completeness. Someone must actually be
using it.
The very beauty of make checkstack is that you don't even notice whether
it is being used or not. You point to some drivers that apparently
didn't use it, which is fine. But how many drivers _did_ use it? How
many problems have been solved before the patches have ever been posted
for review? Noone knows. And that is a good thing. We want the
problems to get solved and not become visible in the first place.
Bloatwatch imo has the design flaw that it is a central tool hosted on
some server somewhere and only documents the damage once it has
happened. It would be much better if every developer could run
something simple locally and clean up the mess before anyone else
notices.
I partially agree with you in one point. It would be even better if
checkstack, bloatcheck, etc. were run automatically on every kernel
compile and developers were forced to look at any problems that come up.
But that would increase compile time, which is bad. So there needs to
be an off button as well, as there is for sparse - where off is the
default.
Jörn
--
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens
^ permalink raw reply
* Re: RFC - size tool for kernel build system
From: Adrian Bunk @ 2008-10-09 15:21 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-embedded, linux kernel
In-Reply-To: <48EBD268.50208@am.sony.com>
On Tue, Oct 07, 2008 at 02:19:36PM -0700, Tim Bird wrote:
> I've been thinking about a tool that might be useful
> to track kernel size changes. I'm posting this
> Request For Comments to get feedback, and determine
> if this is something that would be worthwhile to
> pursue.
>
> What I envision is some new kernel build targets, specifically
> related to gathering size information and generating a size
> comparison report. Some small helper scripts would be written
> to gather the necessary information, and generate the report.
>...
> Any comments?
The building blocks that would be useful are IMHO:
- a make target that generates a report for one kernel
(like the checkstack or export_report targets)
- a script that compares two such reports and outputs the
size differences
That's also easy to do, and if that's what's wanted I can send a patch
that does it.
Everything else is IMHO overdesigned.
The real problem is that dumping some scripts into the kernel sources
or publishing some data on a webpage doesn't make people use them.
Like if you run "make checkstack" on the kernel today you can see that
drivers allocate arrays > 1 kB on the stack despite checkstack being
available...
> -- Tim
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: PRAMFS with XIP support
From: Marco Stornelli @ 2008-10-09 15:08 UTC (permalink / raw)
To: Daniel Walker; +Cc: Tim Bird, Mike Frysinger, Linux-Embedded
In-Reply-To: <1223564414.10283.108.camel@laptop-eth>
Ok, it's a good idea. Thanks.
Daniel Walker ha scritto:
> On Thu, 2008-10-09 at 09:05 +0200, Marco Stornelli wrote:
>> Thanks Tim and Daniel. Daniel the first thing to do to submit the
>> patches is check them to verify that they are compliant to the kernel
>> standard, if you'd like to help you are welcome.
>
> Since the feature was already submitted once (or twice even) I'd image
> there is a record of people comments in the list archives .. That should
> give a better idea of what needs to be changed ..
>
> I looked at the code on the sourceforge page, and I saw a few clean ups
> that could happen. Otherwise, it didn't look bad in terms of code
> quality.
>
> Daniel
>
>
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: PRAMFS with XIP support
From: Daniel Walker @ 2008-10-09 15:00 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Tim Bird, Mike Frysinger, Linux-Embedded
In-Reply-To: <48EDAD3D.3040508@coritel.it>
On Thu, 2008-10-09 at 09:05 +0200, Marco Stornelli wrote:
> Thanks Tim and Daniel. Daniel the first thing to do to submit the
> patches is check them to verify that they are compliant to the kernel
> standard, if you'd like to help you are welcome.
Since the feature was already submitted once (or twice even) I'd image
there is a record of people comments in the list archives .. That should
give a better idea of what needs to be changed ..
I looked at the code on the sourceforge page, and I saw a few clean ups
that could happen. Otherwise, it didn't look bad in terms of code
quality.
Daniel
^ permalink raw reply
* Re: [RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one
From: Bill Gatliff @ 2008-10-09 14:04 UTC (permalink / raw)
To: Hans-Christian Egtvedt; +Cc: Haavard Skinnemoen, linux-embedded
In-Reply-To: <20081009141756.0da223ca@hcegtvedt>
Hans-Christian Egtvedt wrote:
> On Thu, 9 Oct 2008 14:16:01 +0200
> Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote:
>
>> Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> wrote:
>>> You know that there are other users of ATMEL_PWM ?
>>>
>>> There is a atmel-pwm-bl driver in drivers/video/backlight which
>>> could probably be converted to pwm-bl using the new pwm framework.
>> There's already a pwm_bl driver there which I'm assuming is using the
>> generic pwm API. Hopefully, we can simply delete the atmel-pwm-bl
>> driver. Maybe some board code needs updating before that can happen
>> though.
Yes. I think atmel-pwm-bl goes away completely, and video/backlight/pwm_bl.c
gets modified (slightly) to use the new PWM API and becomes the general
backlight-via-PWM-peripheral solution. After that, anyone who wants to write a
backend pwm_device driver suddenly can use their peripheral for backlights (and
other stuff) out-of-the-box.
I just glanced over drivers/video/backlight, it looks like there are a couple
other implementations that could move over to Generic PWM as well.
> That would be the Favr-32 board, since the atmel-pwm-bl driver was
> developed for that board.
>
> Weird how this stuff almost was inserted almost in parallel.
Indeed. But also a bit tragic--- some wasted effort. :(
Not entirely weird, however, since I try to follow AVR32 as closely as I do ARM.
I have an NGW100 and an STK1000, in addition to about five different ARM
machines including ones based on the AT91SAM9263. These common frameworks help
me slide into insanity a little more slowly. :)
(I have some PPC and MIPS boards, too. Occupational hazard).
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one
From: Hans-Christian Egtvedt @ 2008-10-09 13:44 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded
In-Reply-To: <48EE09DF.7000206@billgatliff.com>
On Thu, 09 Oct 2008 08:40:47 -0500
Bill Gatliff <bgat@billgatliff.com> wrote:
> Hans-Christian Egtvedt wrote:
>
> > You know that there are other users of ATMEL_PWM ?
> >
> > There is a atmel-pwm-bl driver in drivers/video/backlight which
> > could probably be converted to pwm-bl using the new pwm framework.
>
> Yes, I'm aware of atmel-pwm-bl, and it's on my list--- along with
> adapting the led-pwm stuff I posted to use the led-blink API.
>
Great, let me know if you want me to test something, I have hardware
laying around here which I can test it on.
--
Best regards,
Hans-Christian Egtvedt
^ permalink raw reply
* Re: [RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one
From: Bill Gatliff @ 2008-10-09 13:40 UTC (permalink / raw)
To: Hans-Christian Egtvedt; +Cc: linux-embedded
In-Reply-To: <20081009072126.1dd3898d@hcegtvedt>
Hans-Christian Egtvedt wrote:
> You know that there are other users of ATMEL_PWM ?
>
> There is a atmel-pwm-bl driver in drivers/video/backlight which could
> probably be converted to pwm-bl using the new pwm framework.
Yes, I'm aware of atmel-pwm-bl, and it's on my list--- along with adapting the
led-pwm stuff I posted to use the led-blink API.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one
From: Hans-Christian Egtvedt @ 2008-10-09 12:17 UTC (permalink / raw)
To: Haavard Skinnemoen; +Cc: Bill Gatliff, linux-embedded
In-Reply-To: <20081009141601.6be979bc@hskinnemo-gx745.norway.atmel.com>
On Thu, 9 Oct 2008 14:16:01 +0200
Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote:
> Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> wrote:
> > You know that there are other users of ATMEL_PWM ?
> >
> > There is a atmel-pwm-bl driver in drivers/video/backlight which
> > could probably be converted to pwm-bl using the new pwm framework.
>
> There's already a pwm_bl driver there which I'm assuming is using the
> generic pwm API. Hopefully, we can simply delete the atmel-pwm-bl
> driver. Maybe some board code needs updating before that can happen
> though.
>
That would be the Favr-32 board, since the atmel-pwm-bl driver was
developed for that board.
Weird how this stuff almost was inserted almost in parallel.
--
Best regards,
Hans-Christian Egtvedt
^ permalink raw reply
* Re: [RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one
From: Haavard Skinnemoen @ 2008-10-09 12:16 UTC (permalink / raw)
To: Hans-Christian Egtvedt; +Cc: Bill Gatliff, linux-embedded
In-Reply-To: <20081009072126.1dd3898d@hcegtvedt>
Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com> wrote:
> You know that there are other users of ATMEL_PWM ?
>
> There is a atmel-pwm-bl driver in drivers/video/backlight which could
> probably be converted to pwm-bl using the new pwm framework.
There's already a pwm_bl driver there which I'm assuming is using the
generic pwm API. Hopefully, we can simply delete the atmel-pwm-bl
driver. Maybe some board code needs updating before that can happen
though.
Haavard
^ permalink raw reply
* Re: [RFC 1/6] [PWM] Generic PWM API implementation
From: Marc Pignat @ 2008-10-09 8:17 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded
In-Reply-To: <4b5c3aa2b1bc2b7efad834da49c2dec8c0a8726b.1223482372.git.bgat@billgatliff.com>
Cleanup implementation for __pwm_create_sysfs.
Signed-off-by: Marc Pignat <marc.pignat@hevs.ch>
---
Hi all!
Here is a missing piece in the generic pwm implementation.
Bill, the code is simpler that you was thinking ;)
In facts, attributes are deleted by device_unregister -> there is nothing to
worry about attributes (un-)successful creation.
Finding which device was created is also trivial (thanks to class_find_device).
Best regards
Marc
diff --git a/drivers/pwm/pwm.c b/drivers/pwm/pwm.c
index 2f28c20..391f820 100644
--- a/drivers/pwm/pwm.c
+++ b/drivers/pwm/pwm.c
@@ -626,15 +626,23 @@ static int __pwm_create_sysfs(struct pwm_device *pwm)
goto err_dev_create;
ret = sysfs_create_group(&dev->kobj, &pwm_device_attr_group);
if (ret)
- goto err_dev_group_create;
+ goto err_dev_create;
}
return ret;
-err_dev_group_create:
err_dev_create:
- /* TODO: undo all the successful device_create calls */
- return -ENODEV;
+ for (wchan = 0; wchan < pwm->nchan; wchan++) {
+ dev = class_find_device(&pwm_class, NULL,
+ &pwm->channels[wchan],
+ __match_device);
+ if (dev) {
+ put_device(dev);
+ device_unregister(dev);
+ }
+ }
+
+ return ret;
}
^ permalink raw reply related
* Re: PRAMFS with XIP support
From: Marco Stornelli @ 2008-10-09 7:05 UTC (permalink / raw)
To: Daniel Walker; +Cc: Tim Bird, Mike Frysinger, Linux-Embedded
In-Reply-To: <1223491907.10283.91.camel@laptop-eth>
Thanks Tim and Daniel. Daniel the first thing to do to submit the
patches is check them to verify that they are compliant to the kernel
standard, if you'd like to help you are welcome.
Daniel Walker ha scritto:
> On Wed, 2008-10-08 at 11:25 -0700, Tim Bird wrote:
>> Marco Stornelli wrote:
>>> Hi Mike,
>>>
>>> I am not the PRAMFS mantainer, and I think he is in charge to do that
>>> (right?), I sent an email to Steve Longerbeam and to MontaVista support,
>>> but I haven't received any response. However, if you think it could be
>>> useful to submit it to lkml I could do it.
>> If you don't hear anything within 2 weeks, just submit it.
>> I've worked with PRAMFS in the past, and I think it's not
>> a high enough profile project at MontaVista that they'd
>> be upset if it got mainlined by someone besides Steve.
>>
>> IRRC, Steve Johnson of Panasonic tried to mainline it a
>> few years ago, and no one from MV complained.
>
> /me looks up ..
>
> I'm not familiar with PRAMFS , but I'm sure any contribution or support
> is welcome.. I'd be happy to help if anyone wants it.
>
> Daniel
>
>
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: [RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one
From: Hans-Christian Egtvedt @ 2008-10-09 5:21 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded, Bill Gatliff
In-Reply-To: <475b4a5985463015fdfa943b9835ab8136dbc06a.1223482372.git.bgat@billgatliff.com>
On Wed, 8 Oct 2008 11:43:17 -0500
Bill Gatliff <bgat@billgatliff.com> wrote:
<snipp>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index a726f3b..cdea0bb 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -13,15 +13,6 @@ menuconfig MISC_DEVICES
>
> if MISC_DEVICES
>
> -config ATMEL_PWM
> - tristate "Atmel AT32/AT91 PWM support"
> - depends on AVR32 || ARCH_AT91
> - help
> - This option enables device driver support for the PWM
> channels
> - on certain Atmel prcoessors. Pulse Width Modulation is
> used for
> - purposes including software controlled power-efficent
> backlights
> - on LCD displays, motor control, and waveform generation.
> -
You know that there are other users of ATMEL_PWM ?
There is a atmel-pwm-bl driver in drivers/video/backlight which could
probably be converted to pwm-bl using the new pwm framework.
> config ATMEL_TCLIB
> bool "Atmel AT32/AT91 Timer/Counter Library"
> depends on (AVR32 || ARCH_AT91)
<snipp>
--
Best regards,
Hans-Christian Egtvedt
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Mike Frysinger @ 2008-10-09 4:33 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded
In-Reply-To: <48ED862D.8000601@billgatliff.com>
On Thu, Oct 9, 2008 at 00:18, Bill Gatliff wrote:
> Mike Frysinger wrote:
>> if you'd seriously play with a Blackfin board, i think we can arrange that
>
> I'd seriously *love* to play with one, but I'm pretty strapped for time for
> another couple of months. The only purpose it would serve near-term would be to
> prove out the input capabilities of a device that I probably wouldn't have time
> to write a driver for. :(
i'll probably look at the Blackfin-pwm core soonish ... we already
implemented a generic framework for it (look for "gptimers"), so it
shouldnt take too much time to transition code for it.
>> while true, hardware that can support PWM as both input/output would
>> suffer from two frameworks. if there's ambiguity in behavior (using
>> "get" in an output mode), then we can just stick it in the
>> documentation and move on. the GPIO framework already has this
>> behavior (set a pin to output and then try and read the data) and i
>> dont recall it ever being an issue there.
>
> Good point. I think I'm sold on the idea now.
>
> We'd need a PWM_CONFIG_<something> to tell the hardware to switch to
> "measurement mode" if such a mode is supported (suggestions for <something>
> welcomed). The config function would return an error if the measurement mode
> wasn't supported by the device. PWM_CONFIG_INPUT and PWM_CONFIG_OUTPUT, perhaps?
only part on Kconfig i think we'll need is each implementation
selecting "GENERIC_PWM_INPUT" and "GENERIC_PWM_OUTPUT". are we
looking towards having multiple master implementations being usable
simultaneously ?
otherwise, i dont think defining things in terms of "generating" and
"measuring" is really needed ... "input" and "output" seems
straightforward enough.
> In output mode, the pwm_get_*() methods would return the driven values if the
> device didn't support a (simultaneous) measurement mode, or cached values if the
> device's configuration registers were write-only. In measurement mode, they'd
> return the measured values.
the current generic core looks like it could handle this easily enough
since we're working with an array of function pointers.
-mike
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Bill Gatliff @ 2008-10-09 4:18 UTC (permalink / raw)
To: Mike Frysinger; +Cc: linux-embedded
In-Reply-To: <8bd0f97a0810082105mabededn54ffcc937674af3@mail.gmail.com>
Mike Frysinger wrote:
> if you'd seriously play with a Blackfin board, i think we can arrange that
I'd seriously *love* to play with one, but I'm pretty strapped for time for
another couple of months. The only purpose it would serve near-term would be to
prove out the input capabilities of a device that I probably wouldn't have time
to write a driver for. :(
> while true, hardware that can support PWM as both input/output would
> suffer from two frameworks. if there's ambiguity in behavior (using
> "get" in an output mode), then we can just stick it in the
> documentation and move on. the GPIO framework already has this
> behavior (set a pin to output and then try and read the data) and i
> dont recall it ever being an issue there.
Good point. I think I'm sold on the idea now.
We'd need a PWM_CONFIG_<something> to tell the hardware to switch to
"measurement mode" if such a mode is supported (suggestions for <something>
welcomed). The config function would return an error if the measurement mode
wasn't supported by the device. PWM_CONFIG_INPUT and PWM_CONFIG_OUTPUT, perhaps?
In output mode, the pwm_get_*() methods would return the driven values if the
device didn't support a (simultaneous) measurement mode, or cached values if the
device's configuration registers were write-only. In measurement mode, they'd
return the measured values.
I think this'll work.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Mike Frysinger @ 2008-10-09 4:05 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded
In-Reply-To: <48ED7E8E.3010504@billgatliff.com>
On Wed, Oct 8, 2008 at 23:46, Bill Gatliff wrote:
> Mike Frysinger wrote:
>>> Are you proposing that the API accommodate both input and output devices?
>>
>> i dont think we should preclude it from the outset.
>
> I don't think have a problem with that. At some point, I would need someone
> with input/output hardware to test the input-specific parts, however. Hint,
> hint. ;)
if you'd seriously play with a Blackfin board, i think we can arrange that
>> not really, but i see the existing code you've posted could already
>> utilize some of the "get" functions ...
>
> Which parts? I don't really like keeping the period_ticks and duty_ticks values
> around, but in my case I have no choice--- unless I were to read the CPRE, CPRD
> and CDTY values from the hardware directly. Which could be what your proposed
> "get" methods would do.
sorry, i misread the led driver. too many structures! :)
> But that still isn't PWM "input" the way you are describing, because my hardware
> wouldn't be _reading_ an incoming PWM: it would be just reporting back the
> values that it was using to produce its output signal. Huge difference.
>
> I dunno, I'm still not sure that measuring the characteristics of an incoming
> PWM signal isn't a different kind of device from one that produces PWM signals,
> at least conceptually. Which, in a way, makes it out of scope for the proposed
> API. Not saying I can't go along with the idea, I'm just not sure what a user
> would expect to happen if they called pwm_get_period_ns() on the SAM9263 PWMC
> device. They certainly aren't going to get a measured value in return!
while true, hardware that can support PWM as both input/output would
suffer from two frameworks. if there's ambiguity in behavior (using
"get" in an output mode), then we can just stick it in the
documentation and move on. the GPIO framework already has this
behavior (set a pin to output and then try and read the data) and i
dont recall it ever being an issue there.
-mike
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Bill Gatliff @ 2008-10-09 3:46 UTC (permalink / raw)
To: Mike Frysinger; +Cc: linux-embedded
In-Reply-To: <8bd0f97a0810081932t7e3ce7e4l785a3a841228aba2@mail.gmail.com>
Mike Frysinger wrote:
>
> the Blackfin timers/pwm's can flip between input and ouput based on
> the configuration register. everything else (pin/etc...) is
> unchanged.
Interesting!
>> Are you proposing that the API accommodate both input and output devices?
>
> i dont think we should preclude it from the outset.
I don't think have a problem with that. At some point, I would need someone
with input/output hardware to test the input-specific parts, however. Hint,
hint. ;)
> not really, but i see the existing code you've posted could already
> utilize some of the "get" functions ...
Which parts? I don't really like keeping the period_ticks and duty_ticks values
around, but in my case I have no choice--- unless I were to read the CPRE, CPRD
and CDTY values from the hardware directly. Which could be what your proposed
"get" methods would do.
But that still isn't PWM "input" the way you are describing, because my hardware
wouldn't be _reading_ an incoming PWM: it would be just reporting back the
values that it was using to produce its output signal. Huge difference.
I dunno, I'm still not sure that measuring the characteristics of an incoming
PWM signal isn't a different kind of device from one that produces PWM signals,
at least conceptually. Which, in a way, makes it out of scope for the proposed
API. Not saying I can't go along with the idea, I'm just not sure what a user
would expect to happen if they called pwm_get_period_ns() on the SAM9263 PWMC
device. They certainly aren't going to get a measured value in return!
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Mike Frysinger @ 2008-10-09 2:32 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded
In-Reply-To: <48ED6B38.7030001@billgatliff.com>
On Wed, Oct 8, 2008 at 22:23, Bill Gatliff wrote:
> Mike Frysinger wrote:
>> On Wed, Oct 8, 2008 at 12:43, Bill Gatliff wrote:
>>> This series proposes a "generic PWM" driver API.
>>
>> seems that the API is solely geared to handle PWM as an output signal.
>
> True. The peripherals I'm currently targeting are output-only devices, and the
> API reflects that.
>
>> what about input ?
>
> Well, the SAM9263 has timer/counters that could be used to measure PWM period
> and duty cycle. But they are a different peripheral entirely. I haven't done
> an exhaustive survey, but I'm not aware of any PWM-generating hardware that is
> simultaneously PWM-measuring hardware as well. Seems like they are either one
> or the other.
the Blackfin timers/pwm's can flip between input and ouput based on
the configuration register. everything else (pin/etc...) is
unchanged.
> Are you proposing that the API accommodate both input and output devices?
i dont think we should preclude it from the outset.
>> all the utility config functions lack "set" in their name. it's a
>> little confusing as to whether the function is a get or set at first
>> glance. rather than expecting drivers to poke directly into the
>> structure, a set of "get" functions would work better (even if they're
>> simply #define's that poke into the structure) and line up better with
>> how the GPIO framework operates.
>
> Good point.
>
> Originally, I was thinking along the lines of a set-and-forget use case. Do you
> use "get" functionality much when generating PWM signals in your applications?
not really, but i see the existing code you've posted could already
utilize some of the "get" functions ...
-mike
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Bill Gatliff @ 2008-10-09 2:29 UTC (permalink / raw)
To: Mike Frysinger; +Cc: linux-embedded
In-Reply-To: <48ED6B38.7030001@billgatliff.com>
Bill Gatliff wrote:
>
>> all the utility config functions lack "set" in their name. it's a
>> little confusing as to whether the function is a get or set at first
>> glance.
For the record, I can support adding a "set" to the function names.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Bill Gatliff @ 2008-10-09 2:23 UTC (permalink / raw)
To: Mike Frysinger; +Cc: linux-embedded
In-Reply-To: <8bd0f97a0810081227u15173a70ke6ab41ea8211e66c@mail.gmail.com>
Mike Frysinger wrote:
> On Wed, Oct 8, 2008 at 12:43, Bill Gatliff wrote:
>> This series proposes a "generic PWM" driver API.
>
> seems that the API is solely geared to handle PWM as an output signal.
True. The peripherals I'm currently targeting are output-only devices, and the
API reflects that.
> what about input ?
Well, the SAM9263 has timer/counters that could be used to measure PWM period
and duty cycle. But they are a different peripheral entirely. I haven't done
an exhaustive survey, but I'm not aware of any PWM-generating hardware that is
simultaneously PWM-measuring hardware as well. Seems like they are either one
or the other.
Are you proposing that the API accommodate both input and output devices?
> all the utility config functions lack "set" in their name. it's a
> little confusing as to whether the function is a get or set at first
> glance. rather than expecting drivers to poke directly into the
> structure, a set of "get" functions would work better (even if they're
> simply #define's that poke into the structure) and line up better with
> how the GPIO framework operates.
Good point.
Originally, I was thinking along the lines of a set-and-forget use case. Do you
use "get" functionality much when generating PWM signals in your applications?
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: RFC - size tool for kernel build system
From: Tim Bird @ 2008-10-08 19:32 UTC (permalink / raw)
To: Chris Snook; +Cc: linux-embedded, linux kernel
In-Reply-To: <48ED0575.4060005@redhat.com>
Chris Snook wrote:
> The kernel build system is supposed to be stateless, and integrating
> this with make would mess that up.
> If your goal is to get more people
> to use Bloatwatch
Not really. Bloatwatch is a means to an end. It's
only the end I care about, which is more visibility
into kernel size growth over time.
> so they don't make your job quite as difficult, it
> would probably be more appropriate to put a size analysis script in
> scripts/ (like checkpatch.pl) that looks at only the kernel you just
> built and generates thorough statistics in a format readable by both
> humans and Bloatwatch, preferably something easily diffed.
The intent would be to do as you describe (although I don't
really care if the format is readable by Bloatwatch). I'm a
Bloatwatch proponent (I'm not the author), but this suggestion
doesn't really have anything to do with Bloatwatch. Maybe I should
have avoided mentioning it in my initial post.
Having a make target to run the script is just
a method of making it as easy as possible to run it.
(Kind of like 'make checkstack' or 'make cscope')
checkpatch.pl is different in that it operates on something
not in the tree yet. It doesn't make sense as a make target
so I don't think it's comparable.
Maybe it would be simpler to omit the baseline comparison
capability at first, and just focus on a canonical size
report (script and report format) for the kernel.
> Then
> developers could use that output in mailing list discussions without
> having to use Bloatwatch, but embedded developers who care about this
> enough to use Bloatwatch can be confident that they're working with the
> same numbers that the rest of us are discussing with the plain text on
> the lists.
Discussing the number with the plain text on the lists is
the ultimate goal. My thinking is that I'd like it to
be used kind of like 'powertop' (except not as a runtime tool
but as a development-time tool). The main intent is just
to give developers more information about how their changes
affect the kernel size.
Thanks for the feedback.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Mike Frysinger @ 2008-10-08 19:27 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-embedded
In-Reply-To: <cover.1223482372.git.bgat@billgatliff.com>
On Wed, Oct 8, 2008 at 12:43, Bill Gatliff wrote:
> This series proposes a "generic PWM" driver API.
seems that the API is solely geared to handle PWM as an output signal.
what about input ?
all the utility config functions lack "set" in their name. it's a
little confusing as to whether the function is a get or set at first
glance. rather than expecting drivers to poke directly into the
structure, a set of "get" functions would work better (even if they're
simply #define's that poke into the structure) and line up better with
how the GPIO framework operates.
-mike
^ permalink raw reply
* Re: RFC - size tool for kernel build system
From: Chris Snook @ 2008-10-08 19:09 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-embedded, linux kernel
In-Reply-To: <48EBD268.50208@am.sony.com>
Tim Bird wrote:
> I've been thinking about a tool that might be useful
> to track kernel size changes. I'm posting this
> Request For Comments to get feedback, and determine
> if this is something that would be worthwhile to
> pursue.
>
> What I envision is some new kernel build targets, specifically
> related to gathering size information and generating a size
> comparison report. Some small helper scripts would be written
> to gather the necessary information, and generate the report.
>
> A kernel developer would type:
>
> 1) make size-baseline
>
> And kernel size information would be recorded for the
> current kernel (after a build, if needed).
> I envision this saving off the .config and System.map, the
> result of 'size vmlinux' and several of the 'size */builtin.o'
> results.
>
> Additionally (and optionally), a program could
> be run to acquire some size information from a running
> system (e.g. a newly booted system, or a system under
> a particular load), to include in the baseline report.
>
> All of the gathered information would be stored
> as the "size baseline".
>
> -------
>
> After making some modifications, either to the source
> or the configuration, the developer could type:
>
> 2) make size-report
>
> The kernel size information would be recorded again, and
> compared with the size-baseline results. A report of
> differences (e.g. from bloat-o-meter and other comparison
> tools) would be produced. Any differences exceeding some
> threshhold (specified in a size-watch config file?)
> could be highlighted. The git commit IDs would be recorded,
> as well as differences between the configs used
> (e.g. diffconfig output).
>
> If some designated size difference exceeds
> a threshold (specified in the size-watch configuration)
> then the make could return an error, while still producing
> the report. This would mean that this could be used
> for git bisection to find a size regression.
>
> Another way to look at this, would be that a developer
> could pick a specific size value to monitor (for example,
> the static size of the network sub-system, or the
> size of a particular slab in the dynamic memory of a
> newly booted kernel). They would specify that in the
> size-watch config, and could monitor that size over time
> and under various configurations.
>
> I envision a couple of usages:
> 1) A developer could use this to be able to see a
> report about the total size increases caused by a patch
> they are about to submit
>
> 2) A developer could compare kernel versions for overall
> size changes
>
> 3) A maintainer could examine the affect of a patch on the
> size of their subsystem.
>
> 4) A developer could compare different kernel configs to
> see the impact of configuration option choices.
>
> 5) An automated tool could generate size values to associate
> with different config option choices (at least, starting from
> a consistent config set).
>
> 6) An automated tool could generate size values for each
> kernel version (this is what Bloatwatch does now).
>
> Bloatwatch generates information on the static size information
> for various kernel versions. This would have a similar purpose,
> but the intent would be to integrate it into the kernel build
> system, to allow any developer to measure the size information,
> and highlight and track the information of their choice.
>
> Any comments?
> -- Tim
The kernel build system is supposed to be stateless, and integrating this with
make would mess that up. If your goal is to get more people to use Bloatwatch
so they don't make your job quite as difficult, it would probably be more
appropriate to put a size analysis script in scripts/ (like checkpatch.pl) that
looks at only the kernel you just built and generates thorough statistics in a
format readable by both humans and Bloatwatch, preferably something easily
diffed. Then developers could use that output in mailing list discussions
without having to use Bloatwatch, but embedded developers who care about this
enough to use Bloatwatch can be confident that they're working with the same
numbers that the rest of us are discussing with the plain text on the lists.
-- Chris
^ permalink raw reply
* Re: PRAMFS with XIP support
From: Daniel Walker @ 2008-10-08 18:51 UTC (permalink / raw)
To: Tim Bird; +Cc: Marco Stornelli, Mike Frysinger, Linux-Embedded
In-Reply-To: <48ECFB26.2090808@am.sony.com>
On Wed, 2008-10-08 at 11:25 -0700, Tim Bird wrote:
> Marco Stornelli wrote:
> > Hi Mike,
> >
> > I am not the PRAMFS mantainer, and I think he is in charge to do that
> > (right?), I sent an email to Steve Longerbeam and to MontaVista support,
> > but I haven't received any response. However, if you think it could be
> > useful to submit it to lkml I could do it.
>
> If you don't hear anything within 2 weeks, just submit it.
> I've worked with PRAMFS in the past, and I think it's not
> a high enough profile project at MontaVista that they'd
> be upset if it got mainlined by someone besides Steve.
>
> IRRC, Steve Johnson of Panasonic tried to mainline it a
> few years ago, and no one from MV complained.
/me looks up ..
I'm not familiar with PRAMFS , but I'm sure any contribution or support
is welcome.. I'd be happy to help if anyone wants it.
Daniel
^ permalink raw reply
* Re: PRAMFS with XIP support
From: Tim Bird @ 2008-10-08 18:25 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Mike Frysinger, Linux-Embedded
In-Reply-To: <48EC5EB9.2050001@coritel.it>
Marco Stornelli wrote:
> Hi Mike,
>
> I am not the PRAMFS mantainer, and I think he is in charge to do that
> (right?), I sent an email to Steve Longerbeam and to MontaVista support,
> but I haven't received any response. However, if you think it could be
> useful to submit it to lkml I could do it.
If you don't hear anything within 2 weeks, just submit it.
I've worked with PRAMFS in the past, and I think it's not
a high enough profile project at MontaVista that they'd
be upset if it got mainlined by someone besides Steve.
IRRC, Steve Johnson of Panasonic tried to mainline it a
few years ago, and no one from MV complained.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox