* Re: Getting physical addresses of mmap'd pages from userspace
From: Robert Schwebel @ 2008-10-13 7:31 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Tom Cooksey, linux-embedded mailing list, Denis Olvier Kropp
In-Reply-To: <20081013092815.1792708d@surf>
On Mon, Oct 13, 2008 at 09:28:15AM +0200, Thomas Petazzoni wrote:
> > We are working on DirectFB [1] support for the PowerVR MBX & SGX
> > chips these days, so I know the problem :) Our hardware platform is
> > i.MX31 with the MBX, MPC5121e also with MBX (both freescale) and a
> > TI OMAP with the SGX.
>
> This is interesting. Is this work available somewhere? Is it
> open-source, or does it rely on proprietary drivers?
It will be available when we have something which is worth being
reviewed in public. As there is currently no possibility to get any
documentation about the cores without NDAs, an open *driver* is IMHO not
possible, so we'll have to rely on the proprietary drivers Freescale
deliver. Bad, but I don't see another chance by now.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: Getting physical addresses of mmap'd pages from userspace
From: Thomas Petazzoni @ 2008-10-13 7:28 UTC (permalink / raw)
To: Robert Schwebel
Cc: Tom Cooksey, linux-embedded mailing list, Denis Olvier Kropp
In-Reply-To: <20081013070017.GH9852@pengutronix.de>
Le Mon, 13 Oct 2008 09:00:17 +0200,
Robert Schwebel <r.schwebel@pengutronix.de> a écrit :
> We are working on DirectFB [1] support for the PowerVR MBX & SGX chips
> these days, so I know the problem :) Our hardware platform is i.MX31
> with the MBX, MPC5121e also with MBX (both freescale) and a TI OMAP
> with the SGX.
This is interesting. Is this work available somewhere ? Is it
open-source, or does it rely on proprietary drivers ?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: Getting physical addresses of mmap'd pages from userspace
From: Tom Cooksey @ 2008-10-13 7:20 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linux-embedded mailing list, Denis Olvier Kropp
In-Reply-To: <20081013070017.GH9852@pengutronix.de>
On Monday 13 October 2008 09:00:17 Robert Schwebel wrote:
> Tom,
>
> [Please configure your mail client to break likes @ column < 80]
Whoops - Sorry!
> On Mon, Oct 13, 2008 at 08:33:25AM +0200, Tom Cooksey wrote:
> > On Friday 10 October 2008 21:12:13 Robert Schwebel wrote:
> > > On Fri, Oct 10, 2008 at 06:15:05PM +0200, Tom Cooksey wrote:
> > > > Is there any way to get the physical address of mlock()'d memory
> > > > from userspace?
> > >
> > > What do you want to do? I don't really see a reason to do such
> > > strange things any more these days.
> >
> > It's quite an annoying problem actually. Basically I have binary
> > drivers for Imagination Technologies's PowerVR graphics drivers. We
> > have tried very hard to get the source code for these drivers and have
> > failed. Eventually ImgTec allowed us to sign an NDA to get the headers
> > for one of their user-space libraries. This library allows us to
> > direct the graphics hardware to render to a specific physical memory
> > region. The problem is that there's no way to find out what the
> > physical addresses are which we need pass to the graphics hardware
> > (via the user-space library). Allthough the library allows us to
> > allocate emory, what I want to do is then blit that memory in a
> > different process. So a client process renders into an off-screen
> > buffer and the server process blits that buffer to the framebuffer. By
> > allowing the server process to do the blit rather than the client
> > process, we can get semi-transparent GL windows.
> >
> > The synchronisation we can do, it's the memory allocation I'm
> > struggling with. If we ask the library to allocate the memory for us,
> > we don't get the physical address to pass to the server process.
> > Instead, we need to allocate memory ourselves and pass the physical
> > address to the library. But like I say, I can't find a way to get the
> > physical address from the kernel.
> >
> > I realise getting round closed-source drivers isn't exactly encoraged,
> > but sadly, we really have no choice. :-(
>
> We are working on DirectFB [1] support for the PowerVR MBX & SGX chips
> these days, so I know the problem :) Our hardware platform is i.MX31
> with the MBX, MPC5121e also with MBX (both freescale) and a TI OMAP with
> the SGX. The whole NDA and Licensing situation is annoying, but we have
> to live with it; if you ask me as a community person, I'd say "vote with
> your dollars". If manufacturers don't want to open their specs to allow
> people writing driver, it must mean that they don't want to sell chips.
> In reality, there are no real alternatives for accelerates chips.
ImgTec has had the market pretty much to itself for a long time and as you say,
there's pretty much no alternatives for the moment. Hopefully that is about to
change as there are, I beleive, about 3 other companies with competing products
about to come to market. I've no idea if the other companies will open up their
drivers either though. It also doesn't help the current situation. :-(
> Regarding the technical question, dok might have an idea. He's currently
> working on DirectFB drivers ontop of the proprietary drivers in one of
> our projects. Cc'ed him.
> [1] Sidenote: we have Gtk+ and TTFNAQ [2] running on top of DirectFB,
> with 2D acceleration.
>
> [2] The-Toolkit-Formerly-Known-As-Qtopia
Gulp - yeah, I'm kinda the maintainer for the Qt/Embedded DirectFB driver now.
(Since the guy who wrote it left a month ago) :-|
Cheers,
Tom
^ permalink raw reply
* Re: Getting physical addresses of mmap'd pages from userspace
From: Robert Schwebel @ 2008-10-13 7:00 UTC (permalink / raw)
To: Tom Cooksey; +Cc: linux-embedded mailing list, Denis Olvier Kropp
In-Reply-To: <200810130833.26399.thomas.cooksey@trolltech.com>
Tom,
[Please configure your mail client to break likes @ column < 80]
On Mon, Oct 13, 2008 at 08:33:25AM +0200, Tom Cooksey wrote:
> On Friday 10 October 2008 21:12:13 Robert Schwebel wrote:
> > On Fri, Oct 10, 2008 at 06:15:05PM +0200, Tom Cooksey wrote:
> > > Is there any way to get the physical address of mlock()'d memory
> > > from userspace?
> >
> > What do you want to do? I don't really see a reason to do such
> > strange things any more these days.
>
> It's quite an annoying problem actually. Basically I have binary
> drivers for Imagination Technologies's PowerVR graphics drivers. We
> have tried very hard to get the source code for these drivers and have
> failed. Eventually ImgTec allowed us to sign an NDA to get the headers
> for one of their user-space libraries. This library allows us to
> direct the graphics hardware to render to a specific physical memory
> region. The problem is that there's no way to find out what the
> physical addresses are which we need pass to the graphics hardware
> (via the user-space library). Allthough the library allows us to
> allocate emory, what I want to do is then blit that memory in a
> different process. So a client process renders into an off-screen
> buffer and the server process blits that buffer to the framebuffer. By
> allowing the server process to do the blit rather than the client
> process, we can get semi-transparent GL windows.
>
> The synchronisation we can do, it's the memory allocation I'm
> struggling with. If we ask the library to allocate the memory for us,
> we don't get the physical address to pass to the server process.
> Instead, we need to allocate memory ourselves and pass the physical
> address to the library. But like I say, I can't find a way to get the
> physical address from the kernel.
>
> I realise getting round closed-source drivers isn't exactly encoraged,
> but sadly, we really have no choice. :-(
We are working on DirectFB [1] support for the PowerVR MBX & SGX chips
these days, so I know the problem :) Our hardware platform is i.MX31
with the MBX, MPC5121e also with MBX (both freescale) and a TI OMAP with
the SGX. The whole NDA and Licensing situation is annoying, but we have
to live with it; if you ask me as a community person, I'd say "vote with
your dollars". If manufacturers don't want to open their specs to allow
people writing driver, it must mean that they don't want to sell chips.
In reality, there are no real alternatives for accelerates chips.
Regarding the technical question, dok might have an idea. He's currently
working on DirectFB drivers ontop of the proprietary drivers in one of
our projects. Cc'ed him.
rsc
[1] Sidenote: we have Gtk+ and TTFNAQ [2] running on top of DirectFB,
with 2D acceleration.
[2] The-Toolkit-Formerly-Known-As-Qtopia
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: Getting physical addresses of mmap'd pages from userspace
From: Tom Cooksey @ 2008-10-13 6:33 UTC (permalink / raw)
To: Robert Schwebel; +Cc: linux-embedded mailing list
In-Reply-To: <20081010191213.GC9852@pengutronix.de>
On Friday 10 October 2008 21:12:13 Robert Schwebel wrote:
> On Fri, Oct 10, 2008 at 06:15:05PM +0200, Tom Cooksey wrote:
> > Is there any way to get the physical address of mlock()'d memory from
> > userspace?
>
> What do you want to do? I don't really see a reason to do such strange
> things any more these days.
It's quite an annoying problem actually. Basically I have binary drivers for Imagination Technologies's PowerVR graphics drivers. We have tried very hard to get the source code for these drivers and have failed. Eventually ImgTec allowed us to sign an NDA to get the headers for one of their user-space libraries. This library allows us to direct the graphics hardware to render to a specific physical memory region. The problem is that there's no way to find out what the physical addresses are which we need pass to the graphics hardware (via the user-space library). Allthough the library allows us to allocate emory, what I want to do is then blit that memory in a different process. So a client process renders into an off-screen buffer and the server process blits that buffer to the framebuffe
r. By allowing the server process to do the blit rather than the client process, we can get semi-transparent GL windows.
The synchronisation we can do, it's the memory allocation I'm struggling with. If we ask the library to allocate the memory for us, we don't get the physical address to pass to the server process. Instead, we need to allocate memory ourselves and pass the physical address to the library. But like I say, I can't find a way to get the physical address from the kernel.
I realise getting round closed-source drivers isn't exactly encoraged, but sadly, we really have no choice. :-(
Cheers,
Tom
^ permalink raw reply
* Re: RFC - size tool for kernel build system
From: Robin Getz @ 2008-10-13 4:17 UTC (permalink / raw)
To: Tim Bird; +Cc: Adrian Bunk, linux-embedded, linux kernel
In-Reply-To: <48EE9A1C.8040301@am.sony.com>
On Thu 9 Oct 2008 19:56, Tim Bird pondered:
> 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.
>
> I took a stab at this with the attached two scripts. These are
> not quite ready for prime time, but show the basic idea.
> I only have a partial list of subsystems, and am skipping the
> runtime data collection, for now.
>
> I have only made the scripts, not any make targets for them.
>
> I record all data into a flat namespace, which makes it easier to compare
> later.
>
> > Everything else is IMHO overdesigned.
> One element of this design is the ability to configure
> the diff-size-report tool to watch only certain values, and to
> return a non-zero exit code under certain conditions. This makes
> it possible to use the tool with git-bisect to find the source of
> a size regression. I believe Linus asked for something like this
> at the last kernel summit.
>
> Without the use of the config file, diff-size-report is very
> to bloat-o-meter, but provides info about additional
> aggregate items (like subsystems and the full kernel).
>
> Feedback is welcome.
This seems to still only look at the text section (only uses nm)? not data or
other section sizes increasing?
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Bill Gatliff @ 2008-10-10 19:42 UTC (permalink / raw)
To: Paul Mundt; +Cc: Linux/PPC Development, linux-embedded
In-Reply-To: <20081010174003.GC10579@linux-sh.org>
Paul Mundt wrote:
>> Hasn't been a problem so far. I posted the first version of the code on l-a-k,
>> and got some feedback on the pwm_device API and a lot of feedback on the way
>> users wanted to use the API to realize applications. I incorporated all of it,
>> and in this "release" I broadened the exposure per recommendations received from
>> l-a-k.
>>
> This is precisely the problem. Stuff that gets "reviewed" on
> linux-arm-kernel gets reviewed for ARM only. There has been way too much
> crap that has been pushed into the kernel under the guise of being
> generic and "reviewed" that has broken _every_ architecture _except_ ARM.
> If you want to refute this, go look at the recent fiasco with musb, which
> still hasn't been solved properly, primarily because the ARM people
> couldn't be bothered using grep. This crap happens all the time, because
> stuff is reviewed and merged in private, and the only time anyone else
> notices is when their platform suddenly stops building.
I'll note for the record that I didn't post on linux-arm-kernel only.
Otherwise, we wouldn't be having this discussion. :)
> Your first version should have been to linux-embedded and linux-kernel.
> If you want to alert the linux-arm-kernel people to the fact that a
> discussion is going on in this area, then feel free to post a
> notification to the list with references to the relevant lists. There is
> no reason why public lists should have to dig in to private archives to
> try and play catch up.
I'm not asking anyone to do that. Just review the patches posted to the list of
your choice. Or, don't review them. Up to you.
My next update will be the one where I formally request a review with intent to
merge into mainline. That one will go to linux-embedded only, with
notifications sent elsewhere as indicated per community request. I don't have a
problem with that. I can't change history, but I'm doing what you are asking of
me otherwise.
> If you're trying to pitch a generic API and doing your review on a
> private list, you've already lost. If you're talking about things that
> only effect arch/arm, feel free to do whatever you want. As soon as you
> step outside of that structure, you have to follow common convention, or
> you risk breaking things all over the place. I can't remember the last
> time I saw a "generic" API reviewed on linux-arm-kernel that didn't end
> up breaking every other architecture in existence. This is true for
> drivers, also. Better yet, don't bother dropping the ARM depedency until
> you've posted to a public list.
Again, we wouldn't be having this exchange if I was pitching a generic API on a
private list because I sense that you aren't an l-a-k subscriber. :)
It's true that the early posts were on the ARM list, but you can see that I
didn't stop there. I started there because the platform that supports the API
right now is ARM, and so I wanted that part to be right before moving upstream.
That process worked: I received feedback on the ARM-specific bits which
improved the API as a whole. The diversity of ARM machines plus Blackfin, PPC,
MIPS, X, Y, Z and PDQ machines was more than I could deal with until now.
Right, enough of that. I really don't want to get distracted from the code.
I'll readily admit to not handing the mailing list submissions right, and I
resolve to do a better job effective immediately. But I think that's the last
that I need to say on the subject.
If it makes you feel any better, I'll stop responding to your replies unless
they come to me via linux-embedded. :)
> Some of us are pretty damn tired of cleaning up after the ARM people.
Sounds like the ARM people need you to drop by and help them do a better job.
Sounds like you could directly benefit from their doing a better job, too. Win-win.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Does the NAND-Flash MT29F4G08ABCWC-ET from Micron work with AT91SAM7SE and i.MX31?
From: Michelle Konzack @ 2008-10-10 19:30 UTC (permalink / raw)
To: Embedded, ARM
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
Hello,
Today I have gotten two NAND-Flash Chips from a friend and like to know,
whether the above chips are working with AT91SAM7SE and i.MX31?
Please note: I have studied Electronic for over 15 years, worked only
@army and this is my first experience building my OWN
computer. Mean I have to read 10.000th of Datasheet pages.
2nd Quest: Can someone recommend bigger NAND-Flash for the i.MX31? I
like to have 4 GByte to store the OS and important data but
since the i.MX support two (Micro)SD cards, I do not know,
whether it is better to use the (Micro)SD stuff.
Any suggestions welcome...
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Bill Gatliff @ 2008-10-10 19:15 UTC (permalink / raw)
To: Paul Mundt; +Cc: Geert Uytterhoeven, linux-embedded, Linux/PPC Development
In-Reply-To: <20081010172837.GB10579@linux-sh.org>
Paul Mundt wrote:
> On Fri, Oct 10, 2008 at 09:03:34AM -0500, Bill Gatliff wrote:
>> Paul Mundt wrote:
>>> This is likely because some of those lists are subscribers only, so cross
>>> posting is poor form. It makes sense to keep the discussion in one place,
>>> and to send notification messages with a pointer to the list archives to
>>> the other lists so folks can jump in if they really care. Splitting it
>>> out doesn't help matters in the least, but unfortunately this is what
>>> seems to happen the most when subscribers only lists are involved.
>> Alright, then maybe I can do this when I post the "final" changeset for review:
>> cross-post to lkml and linux-embedded, and then post one short note on l-a-k,
>> linuxppc-dev and elsewhere that refers those interested to the actual content.
>> I can live with that.
>>
> linux-arm-kernel is the only one that is subscribers only out of that
> list, according to MAINTAINERS. If rmk wants to mandate a broken policy,
> that's perfectly fine, just don't expect the rest of the kernel community
> to tolerate it.
Problem is, the rest of the kernel community is the one who takes it in the,
ahem, server when I cross-post. And since my reference platform is currently
ARM, I can't leave l-a-k out.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: Getting physical addresses of mmap'd pages from userspace
From: Robert Schwebel @ 2008-10-10 19:12 UTC (permalink / raw)
To: Tom Cooksey; +Cc: linux-embedded mailing list
In-Reply-To: <200810101815.06249.thomas.cooksey@trolltech.com>
On Fri, Oct 10, 2008 at 06:15:05PM +0200, Tom Cooksey wrote:
> Is there any way to get the physical address of mlock()'d memory from
> userspace?
What do you want to do? I don't really see a reason to do such strange
things any more these days.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Paul Mundt @ 2008-10-10 17:40 UTC (permalink / raw)
To: Bill Gatliff
Cc: Geert Uytterhoeven, Benjamin Herrenschmidt, Linux/PPC Development,
linux-embedded
In-Reply-To: <48EF5FAC.1060807@billgatliff.com>
On Fri, Oct 10, 2008 at 08:59:08AM -0500, Bill Gatliff wrote:
> There isn't a lot of traffic on linux-embedded, and I'm not sure how many people
> who read linux-arm-kernel also read linuxppc-dev. Lkml's topic coverage is
> huge, so I don't know how many hardcore embedded developers I would encounter
> there. I was hoping for a round of feedback at a lower level before pushing
> anything upstream like that.
>
This isn't your problem. If people are interested in general embedded
topics, they should be subscribed to the list. If they aren't, it's their
loss. Cross posting to every potentially relevant list is a complete
waste of time, and only helps to split out the discussion so nothing
actually gets accomplished in a centralized location.
> Hasn't been a problem so far. I posted the first version of the code on l-a-k,
> and got some feedback on the pwm_device API and a lot of feedback on the way
> users wanted to use the API to realize applications. I incorporated all of it,
> and in this "release" I broadened the exposure per recommendations received from
> l-a-k.
>
This is precisely the problem. Stuff that gets "reviewed" on
linux-arm-kernel gets reviewed for ARM only. There has been way too much
crap that has been pushed into the kernel under the guise of being
generic and "reviewed" that has broken _every_ architecture _except_ ARM.
If you want to refute this, go look at the recent fiasco with musb, which
still hasn't been solved properly, primarily because the ARM people
couldn't be bothered using grep. This crap happens all the time, because
stuff is reviewed and merged in private, and the only time anyone else
notices is when their platform suddenly stops building.
Your first version should have been to linux-embedded and linux-kernel.
If you want to alert the linux-arm-kernel people to the fact that a
discussion is going on in this area, then feel free to post a
notification to the list with references to the relevant lists. There is
no reason why public lists should have to dig in to private archives to
try and play catch up.
> So, you're saying the same thing as me, basically. But leaving out the lists
> with very high ratios of device-specific domain knowledge, which is important
> for the backend parts of what I'm proposing. Blackfin's PWM-capable peripherals
> work differently from those commonly found in ARM and PPC, for example. I
> haven't run anything by the MIPS or AVR guys, but I'm guessing they would have
> something to add, too.
>
> I'm beginning to appreciate what everyone must have had to deal with for GPIO. :)
>
The GPIO mess was broken in different ways, which we're still trying to
fix today. The GPIO discussion did happen out on public lists though, so
all of the discussion on that was visible, even if the end result left
something to be desired.
If you're trying to pitch a generic API and doing your review on a
private list, you've already lost. If you're talking about things that
only effect arch/arm, feel free to do whatever you want. As soon as you
step outside of that structure, you have to follow common convention, or
you risk breaking things all over the place. I can't remember the last
time I saw a "generic" API reviewed on linux-arm-kernel that didn't end
up breaking every other architecture in existence. This is true for
drivers, also. Better yet, don't bother dropping the ARM depedency until
you've posted to a public list.
Some of us are pretty damn tired of cleaning up after the ARM people.
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Paul Mundt @ 2008-10-10 17:28 UTC (permalink / raw)
To: Bill Gatliff; +Cc: Geert Uytterhoeven, Linux/PPC Development, linux-embedded
In-Reply-To: <48EF60B6.20409@billgatliff.com>
On Fri, Oct 10, 2008 at 09:03:34AM -0500, Bill Gatliff wrote:
> Paul Mundt wrote:
> > This is likely because some of those lists are subscribers only, so cross
> > posting is poor form. It makes sense to keep the discussion in one place,
> > and to send notification messages with a pointer to the list archives to
> > the other lists so folks can jump in if they really care. Splitting it
> > out doesn't help matters in the least, but unfortunately this is what
> > seems to happen the most when subscribers only lists are involved.
>
> Alright, then maybe I can do this when I post the "final" changeset for review:
> cross-post to lkml and linux-embedded, and then post one short note on l-a-k,
> linuxppc-dev and elsewhere that refers those interested to the actual content.
> I can live with that.
>
linux-arm-kernel is the only one that is subscribers only out of that
list, according to MAINTAINERS. If rmk wants to mandate a broken policy,
that's perfectly fine, just don't expect the rest of the kernel community
to tolerate it.
^ permalink raw reply
* Re: Getting physical addresses of mmap'd pages from userspace
From: Bart Van Assche @ 2008-10-10 16:37 UTC (permalink / raw)
To: Tom Cooksey; +Cc: linux-embedded mailing list
In-Reply-To: <200810101815.06249.thomas.cooksey@trolltech.com>
On Fri, Oct 10, 2008 at 6:15 PM, Tom Cooksey
<thomas.cooksey@trolltech.com> wrote:
> Is there any way to get the physical address of mlock()'d memory from userspace?
Why do you need this information ?
Bart.
^ permalink raw reply
* Getting physical addresses of mmap'd pages from userspace
From: Tom Cooksey @ 2008-10-10 16:15 UTC (permalink / raw)
To: linux-embedded mailing list
Is there any way to get the physical address of mlock()'d memory from userspace?
I want to avoid writing a kernel module to do it if possible, but I can't see any API which will give me the address? I'm not sure if doing mlock() will even pin the physical address (although I can't see why the physical location would change other than when the page is swapped out and back in again). Is there a syscall I've overlooked somewhere?
The only way I can see to do it would be to pass a kernel parameter in uBoot and tell the kernel not to use e.g. the top 2MB of physical memory. I think I could then mmap /dev/mem to access the physical memory from my application, but pass the physical address to my device which reads from the memory my application has written. Does anyone think this would work?
Cheers,
Tom
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Haavard Skinnemoen @ 2008-10-10 14:32 UTC (permalink / raw)
To: Bill Gatliff
Cc: Paul Mundt, Geert Uytterhoeven, linux-embedded,
Linux/PPC Development
In-Reply-To: <48EF60B6.20409@billgatliff.com>
Bill Gatliff <bgat@billgatliff.com> wrote:
> Paul Mundt wrote:
> > This is likely because some of those lists are subscribers only, so cross
> > posting is poor form. It makes sense to keep the discussion in one place,
> > and to send notification messages with a pointer to the list archives to
> > the other lists so folks can jump in if they really care. Splitting it
> > out doesn't help matters in the least, but unfortunately this is what
> > seems to happen the most when subscribers only lists are involved.
>
> Alright, then maybe I can do this when I post the "final" changeset for review:
> cross-post to lkml and linux-embedded, and then post one short note on l-a-k,
> linuxppc-dev and elsewhere that refers those interested to the actual content.
> I can live with that.
Feel free to cross-post to kernel@avr32linux.org. It's open for
non-subscribers, and there may be people interested in PWM there
(especially since you include a driver for the PWM hardware on AVR32
devices.)
Haavard
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Bill Gatliff @ 2008-10-10 14:03 UTC (permalink / raw)
To: Paul Mundt; +Cc: Geert Uytterhoeven, linux-embedded, Linux/PPC Development
In-Reply-To: <20081010093642.GA10579@linux-sh.org>
Paul Mundt wrote:
> This is likely because some of those lists are subscribers only, so cross
> posting is poor form. It makes sense to keep the discussion in one place,
> and to send notification messages with a pointer to the list archives to
> the other lists so folks can jump in if they really care. Splitting it
> out doesn't help matters in the least, but unfortunately this is what
> seems to happen the most when subscribers only lists are involved.
Alright, then maybe I can do this when I post the "final" changeset for review:
cross-post to lkml and linux-embedded, and then post one short note on l-a-k,
linuxppc-dev and elsewhere that refers those interested to the actual content.
I can live with that.
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-10 13:59 UTC (permalink / raw)
To: David Woodhouse
Cc: Paul Mundt, Geert Uytterhoeven, Benjamin Herrenschmidt,
Linux/PPC Development, linux-embedded
In-Reply-To: <1223632003.12547.65.camel@macbook.infradead.org>
David Woodhouse wrote:
> Subscriber-only lists are broken. Just don't use them.
You owe me a new keyboard! :)
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-10 13:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Benjamin Herrenschmidt, Linux/PPC Development, linux-embedded
In-Reply-To: <Pine.LNX.4.64.0810101054140.12257@vixen.sonytel.be>
Geert Uytterhoeven wrote:
>
> Were did you actually sent them to? Apparently you sent them to each mailing
> list (at least linux-embedded and linuxppc-dev) _separately_ (or using bcc).
I sent them separately to linux-embedded, linuxppc-dev, and linux-arm-kernel.
Those three groups seemed to have the developers who were most likely to provide
a motivated review and constructive response; unfortunately, some are
subscriber-only and so I couldn't just cross-post. I was expecting some
criticism for this, but I'm not sure there's a good alternative.
I don't like the idea of posting in so many places, but PWM is a pretty
expansive topic: just about every SoC under the sun has some ability to do PWM,
and people use the signals for all sorts of things. Both have to be taken into
consideration by the API, hence I need lots of review and feedback.
There isn't a lot of traffic on linux-embedded, and I'm not sure how many people
who read linux-arm-kernel also read linuxppc-dev. Lkml's topic coverage is
huge, so I don't know how many hardcore embedded developers I would encounter
there. I was hoping for a round of feedback at a lower level before pushing
anything upstream like that.
> Hence different people may give the same comments without knowing about each
> other, and you may have to explain everything multiple times.
Hasn't been a problem so far. I posted the first version of the code on l-a-k,
and got some feedback on the pwm_device API and a lot of feedback on the way
users wanted to use the API to realize applications. I incorporated all of it,
and in this "release" I broadened the exposure per recommendations received from
l-a-k.
> I would go for lkml and linux-embedded, _together_.
So, you're saying the same thing as me, basically. But leaving out the lists
with very high ratios of device-specific domain knowledge, which is important
for the backend parts of what I'm proposing. Blackfin's PWM-capable peripherals
work differently from those commonly found in ARM and PPC, for example. I
haven't run anything by the MIPS or AVR guys, but I'm guessing they would have
something to add, too.
I'm beginning to appreciate what everyone must have had to deal with for GPIO. :)
b.g.
--
Bill Gatliff
bgat@billgatliff.com
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: David Woodhouse @ 2008-10-10 9:46 UTC (permalink / raw)
To: Paul Mundt
Cc: Geert Uytterhoeven, Bill Gatliff, Benjamin Herrenschmidt,
Linux/PPC Development, linux-embedded
In-Reply-To: <20081010093642.GA10579@linux-sh.org>
On Fri, 2008-10-10 at 18:36 +0900, Paul Mundt wrote:
> This is likely because some of those lists are subscribers only, so cross
> posting is poor form. It makes sense to keep the discussion in one place,
> and to send notification messages with a pointer to the list archives to
> the other lists so folks can jump in if they really care. Splitting it
> out doesn't help matters in the least, but unfortunately this is what
> seems to happen the most when subscribers only lists are involved.
Subscriber-only lists are broken. Just don't use them.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: RFC - size tool for kernel build system
From: Geert Uytterhoeven @ 2008-10-10 9:42 UTC (permalink / raw)
To: Tim Bird; +Cc: Adrian Bunk, linux-embedded, linux kernel
In-Reply-To: <48EE9A1C.8040301@am.sony.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1224 bytes --]
On Thu, 9 Oct 2008, Tim Bird wrote:
> 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.
>
> I took a stab at this with the attached two scripts. These are
> not quite ready for prime time, but show the basic idea.
> I only have a partial list of subsystems, and am skipping the
> runtime data collection, for now.
>
> I have only made the scripts, not any make targets for them.
Seems to work fine, after I hacked my $CROSS_COMPILE prefix into the hardcoded
nm launch.
Thanks!
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Paul Mundt @ 2008-10-10 9:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bill Gatliff, Benjamin Herrenschmidt, Linux/PPC Development,
linux-embedded
In-Reply-To: <Pine.LNX.4.64.0810101054140.12257@vixen.sonytel.be>
On Fri, Oct 10, 2008 at 11:00:09AM +0200, Geert Uytterhoeven wrote:
> On Thu, 9 Oct 2008, Bill Gatliff wrote:
> > Benjamin Herrenschmidt wrote:
> > > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote:
> > >> This series proposes a "generic PWM" driver API.
> > >>
> > >> This proposed API is motivated by the author's need to support
> > >> pluggable devices; a secondary objective is to consolidate the
> > >> existing PWM implementations behind an agreeable, consistent,
> > >> redundancy-reducing interface.
> > >
> > > .../...
> > >
> > > You should send your patches to the main linux kernel list !
> >
> > Perhaps. But it seemed more relevant to this crowd, and the linux-embedded
> > crowd, and the linux-arm-kernel crowd.
>
> Were did you actually sent them to? Apparently you sent them to each mailing
> list (at least linux-embedded and linuxppc-dev) _separately_ (or using bcc).
>
> Hence different people may give the same comments without knowing about each
> other, and you may have to explain everything multiple times.
>
> I would go for lkml and linux-embedded, _together_.
>
This is likely because some of those lists are subscribers only, so cross
posting is poor form. It makes sense to keep the discussion in one place,
and to send notification messages with a pointer to the list archives to
the other lists so folks can jump in if they really care. Splitting it
out doesn't help matters in the least, but unfortunately this is what
seems to happen the most when subscribers only lists are involved.
^ permalink raw reply
* Re: [RFC 0/6] Proposal for a Generic PWM Device API
From: Geert Uytterhoeven @ 2008-10-10 9:00 UTC (permalink / raw)
To: Bill Gatliff
Cc: Benjamin Herrenschmidt, Linux/PPC Development, linux-embedded
In-Reply-To: <48EED4D1.2040506@billgatliff.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1410 bytes --]
On Thu, 9 Oct 2008, Bill Gatliff wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote:
> >> This series proposes a "generic PWM" driver API.
> >>
> >> This proposed API is motivated by the author's need to support
> >> pluggable devices; a secondary objective is to consolidate the
> >> existing PWM implementations behind an agreeable, consistent,
> >> redundancy-reducing interface.
> >
> > .../...
> >
> > You should send your patches to the main linux kernel list !
>
> Perhaps. But it seemed more relevant to this crowd, and the linux-embedded
> crowd, and the linux-arm-kernel crowd.
Were did you actually sent them to? Apparently you sent them to each mailing
list (at least linux-embedded and linuxppc-dev) _separately_ (or using bcc).
Hence different people may give the same comments without knowing about each
other, and you may have to explain everything multiple times.
I would go for lkml and linux-embedded, _together_.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* [PATCH v2] gpiolib: Add pin change notification
From: Ben Nizette @ 2008-10-10 6:17 UTC (permalink / raw)
To: David Brownell; +Cc: linux-kernel, linux-embedded
This adds pin change notification to the gpiolib sysfs interface. It
requires 16 extra bytes in gpio_desc iff CONFIG_GPIO_SYSFS which in turn
means, eg, 4k of .bss usage on AVR32. Due to limitations in sysfs, this
patch makes poll(2) and friends work as expected on the "value"
attribute, though reads on "value" will never block and there is no
facility for async reads and writes.
Signed-off-by: Ben Nizette <bn@niasdigital.com>
---
I forgot I'd been holding this stuff, v1 was posted some time back to no
reviews. Since then .bss usage has been more than halved, docco's been
added and IMO the user interface is nicer.
Documentation/gpio.txt | 48 +++++++++
drivers/gpio/gpiolib.c | 246 ++++++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 289 insertions(+), 5 deletions(-)
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index 18022e2..0a9e6ee 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -524,6 +524,21 @@ and have the following read/write attributes:
is configured as an output, this value may be written;
any nonzero value is treated as high.
+ "notify" ... Selects a method for the detection of pin change
+ events. This can be written or read as one of "none",
+ "irq" or a number. If "none", no detection will be
+ done, if "irq" then the change detection will be done
+ by registering an interrupt handler on the line given
+ by gpio_to_irq for that gpio. If a number is written,
+ the gpio will be polled for a state change every n
+ milliseconds where n is the number written. The
+ minimum interval is 10 milliseconds.
+
+ "notify_filter" ... This can be written and read as one of
+ "rising", "falling" or "both". If "rising", only
+ rising edges will be reported, similarly for "falling"
+ and "both".
+
GPIO controllers have paths like /sys/class/gpio/chipchip42/ (for the
controller implementing GPIOs starting at #42) and have the following
read-only attributes:
@@ -544,6 +559,39 @@ gpiochip nodes (possibly in conjunction with schematics) to determine
the correct GPIO number to use for a given signal.
+Pin Change Notification
+-----------------------
+The "value" attribute of a gpio is pollable. For this to work, you
+must have set up the notify attribute of that gpio to the type of
+detection suitable for the underlying hardware.
+
+If the hardware supports interrupts on both edges and the gpio to
+interrupt line mapping is unique, you should write "irq" to the notify
+attribute.
+
+If the hardware doesn't support this, or you're unsure, you can write
+a number to the notify attribute. This number is the delay between
+successive polls of the gpio state in milliseconds. You may not poll
+more often than 10ms intervals.
+
+You must use poll mode if communication with the gpio's chip requires
+sleeping. This is the case if, for example, the gpio is part of a
+I2C or SPI GPIO expander.
+
+By default, both rising and falling edges are reported. To filter
+this, you can write one of "rising" or "falling" to the notify_filter
+attribute. To go back to being notified of both edge changes, write
+"both" to this attribute.
+
+Once the notification has been set up, you may use poll(2) and friends
+on the "value" attribute. This attribute will register as having new
+data ready to be read if and only if there has been a state change
+since the last read(2) of the "value" attribute.
+
+Note that unlike a regular device file, a read on the "value" attribute
+will never block whether or not there's new data to be read.
+
+
Exporting from Kernel code
--------------------------
Kernel code can explicitly manage exports of GPIOs which have already been
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 8d29405..68b95a5 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1,6 +1,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/irq.h>
+#include <linux/interrupt.h>
#include <linux/spinlock.h>
#include <linux/device.h>
#include <linux/err.h>
@@ -49,13 +50,35 @@ struct gpio_desc {
#define FLAG_RESERVED 2
#define FLAG_EXPORT 3 /* protected by sysfs_lock */
#define FLAG_SYSFS 4 /* exported via /sys/class/gpio/control */
+#define ASYNC_MODE_IRQ 5 /* using interrupts for async notification */
+#define ASYNC_MODE_POLL 6 /* using polling for async notification */
+#define ASYNC_RISING 7 /* will notify on rising edges */
+#define ASYNC_FALLING 8 /* will notify on falling edges */
#ifdef CONFIG_DEBUG_FS
const char *label;
#endif
+
+#ifdef CONFIG_GPIO_SYSFS
+ struct device *dev;
+ struct poll_desc *poll;
+
+ /* Poll interval in jiffies, here (rather than in struct poll_desc
+ * so the user can change the value no matter what their current
+ * notification mode is */
+ long timeout;
+
+ /* Last known value */
+ int val;
+#endif
};
static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
+struct poll_desc {
+ struct delayed_work work;
+ unsigned gpio;
+};
+
static inline void desc_set_label(struct gpio_desc *d, const char *label)
{
#ifdef CONFIG_DEBUG_FS
@@ -173,12 +196,56 @@ static DEFINE_MUTEX(sysfs_lock);
* /value
* * always readable, subject to hardware behavior
* * may be writable, as zero/nonzero
- *
- * REVISIT there will likely be an attribute for configuring async
- * notifications, e.g. to specify polling interval or IRQ trigger type
- * that would for example trigger a poll() on the "value".
+ * /notify
+ * * read/write as "irq", numeric or "none"
+ * /notify_filter
+ * * read/write as "rising", "falling" or "both"
*/
+struct poll_desc *work_to_poll(struct work_struct *ws)
+{
+ return container_of((struct delayed_work *)ws, struct poll_desc, work);
+}
+
+void gpio_poll_work(struct work_struct *ws)
+{
+ struct poll_desc *poll = work_to_poll(ws);
+
+ unsigned gpio = poll->gpio;
+ struct gpio_desc *desc = &gpio_desc[gpio];
+
+ int new = gpio_get_value_cansleep(gpio);
+ int old = desc->val;
+
+ if ((new && !old && test_bit(ASYNC_RISING, &desc->flags)) ||
+ (!new && old && test_bit(ASYNC_FALLING, &desc->flags)))
+ sysfs_notify(&desc->dev->kobj, NULL, "value");
+
+ desc->val = new;
+ schedule_delayed_work(&poll->work, desc->timeout);
+}
+
+static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
+{
+ struct gpio_desc *desc = dev_id;
+ int gpio = desc - gpio_desc;
+ int new, old;
+
+ if (!gpio_is_valid(gpio))
+ return IRQ_NONE;
+
+ new = gpio_get_value(gpio);
+ old = desc->val;
+
+ if ((new && !old && test_bit(ASYNC_RISING, &desc->flags)) ||
+ (!new && old && test_bit(ASYNC_FALLING, &desc->flags)))
+ sysfs_notify(&desc->dev->kobj, NULL, "value");
+
+ desc->val = new;
+
+ return IRQ_HANDLED;
+}
+
static ssize_t gpio_direction_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -273,9 +340,162 @@ static ssize_t gpio_value_store(struct device *dev,
static /*const*/ DEVICE_ATTR(value, 0644,
gpio_value_show, gpio_value_store);
+static ssize_t gpio_notify_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ const struct gpio_desc *desc = dev_get_drvdata(dev);
+ ssize_t ret;
+
+ mutex_lock(&sysfs_lock);
+
+ if (test_bit(ASYNC_MODE_IRQ, &desc->flags))
+ ret = sprintf(buf, "irq\n");
+ else if (test_bit(ASYNC_MODE_POLL, &desc->flags))
+ ret = sprintf(buf, "%ld\n", desc->timeout * 1000 / HZ);
+ else
+ ret = sprintf(buf, "none\n");
+
+ mutex_unlock(&sysfs_lock);
+ return ret;
+}
+
+static ssize_t gpio_notify_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct gpio_desc *desc = dev_get_drvdata(dev);
+ unsigned gpio = desc - gpio_desc;
+ ssize_t status = 0;
+ int new;
+ long value;
+
+ mutex_lock(&sysfs_lock);
+
+ if (sysfs_streq(buf, "irq"))
+ new = ASYNC_MODE_IRQ;
+ else if (sysfs_streq(buf, "none"))
+ new = -1;
+ else {
+ status = strict_strtol(buf, 0, &value);
+
+ /* 10ms minimum interval to avoid DoS */
+ if (status || value < 10) {
+ status = -EINVAL;
+ goto out;
+ }
+
+ /* value will be in ms, convert to jiffies. */
+ desc->timeout = DIV_ROUND_UP(value * HZ, 1000);
+ new = ASYNC_MODE_POLL;
+ }
+
+ if (test_and_clear_bit(ASYNC_MODE_IRQ, &desc->flags))
+ free_irq(gpio_to_irq(gpio), desc);
+ else if (test_and_clear_bit(ASYNC_MODE_POLL, &desc->flags)) {
+ BUG_ON(!desc->poll);
+
+ cancel_delayed_work(&desc->poll->work);
+ kfree(desc->poll);
+ }
+
+ if (new == ASYNC_MODE_IRQ) {
+ if (desc->chip->can_sleep) {
+ /* -EINVAL probably isn't appropriate here,
+ * what's code for "not supported by
+ * underlying hardware"? */
+ status = -EINVAL;
+ goto out;
+ }
+
+ desc->val = gpio_get_value(gpio);
+
+ /* REVISIT: We always request both edges then filter in the
+ * irq handler. How many devices don't support this..?? */
+ status = request_irq(gpio_to_irq(gpio), gpio_irq_handler,
+ IRQF_SHARED | IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING,
+ "gpiolib", desc);
+ } else if (new == ASYNC_MODE_POLL) {
+
+ desc->poll = kmalloc(sizeof(struct poll_desc), GFP_KERNEL);
+ if (!desc->poll) {
+ status = -ENOMEM;
+ goto out;
+ }
+
+ desc->poll->gpio = gpio;
+
+ desc->val = gpio_get_value_cansleep(gpio);
+
+ INIT_DELAYED_WORK(&desc->poll->work, gpio_poll_work);
+ schedule_delayed_work(&desc->poll->work, desc->timeout);
+ }
+
+ if (new >= 0 && !status)
+ set_bit(new, &desc->flags);
+
+out:
+ if (status)
+ dev_dbg(dev, "gpio notification mode set fail, err %d\n",
+ (int)status);
+
+ mutex_unlock(&sysfs_lock);
+ return status ? : size;
+}
+
+static const DEVICE_ATTR(notify, 0644,
+ gpio_notify_show, gpio_notify_store);
+
+static ssize_t gpio_notify_filter_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct gpio_desc *desc = dev_get_drvdata(dev);
+ ssize_t status;
+
+ mutex_lock(&sysfs_lock);
+
+ if (test_bit(ASYNC_FALLING, &desc->flags) &&
+ test_bit(ASYNC_RISING, &desc->flags))
+ status = sprintf(buf, "both\n");
+ else if (test_bit(ASYNC_RISING, &desc->flags))
+ status = sprintf(buf, "rising\n");
+ else
+ status = sprintf(buf, "falling\n");
+
+ mutex_unlock(&sysfs_lock);
+ return status;
+}
+
+static ssize_t gpio_notify_filter_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct gpio_desc *desc = dev_get_drvdata(dev);
+ ssize_t status = 0;
+
+ mutex_lock(&sysfs_lock);
+
+ if (sysfs_streq(buf, "rising")) {
+ set_bit(ASYNC_RISING, &desc->flags);
+ clear_bit(ASYNC_FALLING, &desc->flags);
+ } else if (sysfs_streq(buf, "falling")) {
+ clear_bit(ASYNC_RISING, &desc->flags);
+ set_bit(ASYNC_FALLING, &desc->flags);
+ } else if (sysfs_streq(buf, "both")) {
+ set_bit(ASYNC_RISING, &desc->flags);
+ set_bit(ASYNC_FALLING, &desc->flags);
+ } else
+ status = -EINVAL;
+
+ mutex_unlock(&sysfs_lock);
+ return status ? : size;
+}
+
+static const DEVICE_ATTR(notify_filter, 0644,
+ gpio_notify_filter_show, gpio_notify_filter_store);
+
static const struct attribute *gpio_attrs[] = {
&dev_attr_direction.attr,
&dev_attr_value.attr,
+ &dev_attr_notify.attr,
+ &dev_attr_notify_filter.attr,
NULL,
};
@@ -387,6 +607,17 @@ static ssize_t unexport_store(struct class *class, const char *buf, size_t len)
status = 0;
gpio_free(gpio);
}
+
+ if (test_and_clear_bit(ASYNC_MODE_IRQ, &gpio_desc[gpio].flags))
+ free_irq(gpio_to_irq(gpio), &gpio_desc[gpio]);
+
+ if (test_and_clear_bit(ASYNC_MODE_POLL, &gpio_desc[gpio].flags)) {
+ BUG_ON(!gpio_desc[gpio].poll);
+
+ cancel_delayed_work(&gpio_desc[gpio].poll->work);
+ kfree(gpio_desc[gpio].poll);
+ }
+
done:
if (status)
pr_debug("%s: status %d\n", __func__, status);
@@ -468,6 +699,12 @@ int gpio_export(unsigned gpio, bool direction_may_change)
status = -ENODEV;
if (status == 0)
set_bit(FLAG_EXPORT, &desc->flags);
+
+ desc->dev = dev;
+ /* 100ms default poll interval */
+ desc->timeout = HZ / 10;
+ set_bit(ASYNC_RISING, &desc->flags);
+ set_bit(ASYNC_FALLING, &desc->flags);
}
mutex_unlock(&sysfs_lock);
@@ -615,7 +852,6 @@ static int __init gpiolib_sysfs_init(void)
}
spin_unlock_irqrestore(&gpio_lock, flags);
-
return status;
}
postcore_initcall(gpiolib_sysfs_init);
^ permalink raw reply related
* Re: RFC - size tool for kernel build system
From: Tim Bird @ 2008-10-09 23:56 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linux-embedded, linux kernel
In-Reply-To: <20081009152151.GB17013@cs181140183.pp.htv.fi>
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.
I took a stab at this with the attached two scripts. These are
not quite ready for prime time, but show the basic idea.
I only have a partial list of subsystems, and am skipping the
runtime data collection, for now.
I have only made the scripts, not any make targets for them.
I record all data into a flat namespace, which makes it easier to compare
later.
> Everything else is IMHO overdesigned.
One element of this design is the ability to configure
the diff-size-report tool to watch only certain values, and to
return a non-zero exit code under certain conditions. This makes
it possible to use the tool with git-bisect to find the source of
a size regression. I believe Linus asked for something like this
at the last kernel summit.
Without the use of the config file, diff-size-report is very
to bloat-o-meter, but provides info about additional
aggregate items (like subsystems and the full kernel).
Feedback is welcome.
-- Tim
commit d4c8434396cc9a06dbd682f4eea44e2cfb44950f
Author: Tim Bird <tim.bird@am.sony.com>
Date: Thu Oct 9 16:50:08 2008 -0700
Add size reporting and monitoring scripts to the Linux kernel
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
diff --git a/scripts/diff-size-report b/scripts/diff-size-report
new file mode 100755
index 0000000..40663cb
--- /dev/null
+++ b/scripts/diff-size-report
@@ -0,0 +1,237 @@
+#!/usr/bin/python
+#
+# diff-size-report - tool to show differences between two size reports
+#
+# Copyright 2008 Sony Corporation
+#
+# GPL version 2.0 applies
+#
+
+import sys, os
+
+conf_file="scripts/diff-size.conf"
+
+def usage():
+ print """Usage: %s file1 file2
+
+If a configuration file is present, then only show requested info.
+The default config file is: %s
+
+If any threshold specified in the config file is exceeded, the
+program returns a non-zero exit code. This should be useful with
+git-bisect, to find the commit which creates a size regression.
+
+A sample config file is:
+ watch kernel_total
+ threshold kernel_total 15%%
+ watch subsys_net_text changes
+ threshold subsys_drivers_char_total +20000
+ threshold symbol___log_buf 64000
+
+This always shows the value of kernel_total, and shows a warning if
+the kernel_total increases by more than 15%% from file1 to file2.
+It only shows subsys_net_text if it's value changes. It shows a warning
+if subsys_drivers_char_total increases more than 20000 bytes, and a
+warning if symbol___log_buf is bigger than 64000 bytes.
+""" % (os.path.basename(sys.argv[0]), conf_file)
+
+def read_report(filename):
+ lines = open(filename).readlines()
+ d = {}
+ in_block=0
+ for line in lines:
+ # accrete block, if still in one
+ if in_block:
+ if line.startswith(block_name+"_end"):
+ in_block=0
+ d[block_name] = block
+ continue
+ block += line
+ continue
+
+ # ignore empty lines and comments
+ if not line.strip() or line.startswith("#"):
+ continue
+
+ # get regular one-line value
+ if line.find("=") != -1:
+ name, value = line.split('=',1)
+ name = name.strip()
+ value = value.strip()
+ try:
+ value = int(value)
+ except:
+ pass
+ d[name] = value
+ continue
+
+ # check for start of block
+ if line.find("_start:") != -1 and not in_block:
+ in_block=1
+ block = ""
+ block_name=line.split("_start:")[0]
+ continue
+
+ sys.stderr.write("Unrecognized line in file %s\n" % filename)
+ sys.stderr.write("line=%s" % line)
+
+ if in_block:
+ sys.stderr.write("Error: Untermined block '%s' in file %s\n"\
+ % (block_name, filename))
+ return d
+
+
+def show_warning(msg, value, t_str, name, o, d):
+ print "WARNING: %s of %d exceeds threshold of %s for '%s'" % \
+ (msg, value, t_str, name)
+ pchange = (float(d)/float(o))* 100
+ print "Old value: %d, New value: %d, Change: %d (%.1f%%)" % \
+ (o, o+d, d, pchange)
+
+# allowed thresholds are:
+# +t - tree if delta > t
+# -t - tree if delta < t
+# t - true if new value > t
+# t% - true if delta > old value + t%
+def do_threshold(name, o, d, t_str):
+ rcode = 0
+ if t_str.startswith("+"):
+ t = int(t_str[1:])
+ if d > t:
+ show_warning("Change", d, t_str, name, o, d)
+ rcode = -1
+ return rcode
+
+ if t_str.startswith("-"):
+ t = int(t_str[1:])
+ if delta < t:
+ show_warning("Change", d, t_str, name, o, d)
+ rcode = -1
+ return rcode
+
+ if t_str.endswith("%"):
+ # handle percentage
+ t = o + (o*int(t_str[:-1]))/100
+ if o+d>t:
+ show_warning("Change", d, t_str, name, o, d)
+ rcode = -1
+ return rcode
+
+ t = int(t_str)
+ if o+d>t:
+ show_warning("Value", o+d, t_str, name, o, d)
+ rcode = -1
+ return rcode
+
+
+# returns non-zero on threshold exception
+def process_report_conf(conf_file, old, delta):
+ rcode = 0
+ conf_list = open(conf_file).readlines()
+
+ # convert delta list to map
+ dmap = {}
+ for (value, name) in delta:
+ dmap[name] = value
+
+ for c in conf_list:
+ if not c.strip or c.startswith("#"):
+ continue
+ cparts = c.split()
+ cmd = cparts[0]
+ if cmd=="watch":
+ name = cparts[1]
+ if not dmap.has_key(name):
+ sys.stderr.write("Error: could not find item '%s' to watch\n" % name)
+ continue
+ d = dmap[name]
+ o = old[name]
+
+ if len(cparts)>2 and cparts[2].startswith("change") \
+ and d==0:
+ # skip unchanged values
+ continue
+ if d==0:
+ print "%s stayed at %d bytes" % (name, o)
+ continue
+
+ p = (float(d)/float(o))* 100
+ print "%s changed by %d bytes (%.1f%%)" % (name, d, p)
+ continue
+
+ if cmd=="threshold":
+ name = cparts[1]
+ t_str = cparts[2]
+ if not dmap.has_key(name):
+ sys.stderr.write("Error: could not find item '%s' for threshold check\n" % name)
+ continue
+ o = old.get(name, 0)
+ d = dmap[name]
+ rcode |= do_threshold(name, o, d, t_str)
+
+ return rcode
+
+
+def main():
+ if len(sys.argv) != 3:
+ usage()
+ sys.exit(1)
+
+ old = read_report(sys.argv[1])
+ new = read_report(sys.argv[2])
+
+ # ignore kernel config (should do diffconfig eventually)
+ old_config = old["kernel_config"]
+ del(old["kernel_config"])
+ new_config = new["kernel_config"]
+ del(new["kernel_config"])
+
+ # delta generation copied from bloat-o-meter
+ up = 0
+ down = 0
+ delta = []
+ common = {}
+
+ for a in old:
+ if a in new:
+ common[a] = 1
+
+ for name in old:
+ if name not in common:
+ down += old[name]
+ delta.append((-old[name], name))
+
+ for name in new:
+ if name not in common:
+ up += new[name]
+ delta.append((new[name], name))
+
+ for name in common:
+ d = new.get(name, 0) - old.get(name, 0)
+ if d>0: up += d
+ if d<0: down -= d
+ delta.append((d, name))
+
+ delta.sort()
+ delta.reverse()
+
+ if os.path.isfile(conf_file):
+ rcode = process_report_conf(conf_file, old, delta)
+ sys.exit(rcode)
+ else:
+ print "up: %d, down %d, net change %d" % (up, -down, up-down)
+ fmt = "%-40s %7s %7s %+7s %8s"
+ print fmt % ("item", "old", "new", "change", "percent")
+ fmt = "%-40s %7s %7s %+7s (%4.1f%%)"
+ for d, n in delta:
+ if d:
+ o = old.get(n,0)
+ if o!=0:
+ p = (float(d)/float(o))*100
+ else:
+ p = 100
+ print fmt % (n, old.get(n,"-"),
+ new.get(n,"-"), d, p)
+ sys.exit(0)
+
+main()
diff --git a/scripts/gen-size-report b/scripts/gen-size-report
new file mode 100755
index 0000000..7566c30
--- /dev/null
+++ b/scripts/gen-size-report
@@ -0,0 +1,213 @@
+#!/usr/bin/python
+#
+# gen-size-report - create a size report for the current kernel
+# in a canonical format (human readable, and easily machine diff'able)
+#
+# Copyright 2008 Sony Corporation
+#
+# GPL version 2.0 applies
+#
+# Major report sections:
+# Image totals, Subsystems, Symbols, Runtime, Reference
+#
+# Statement syntax:
+# name=<value>
+# foo_start:
+# multi-line...
+# value
+# foo_end
+#
+
+import os, sys
+import commands
+import time
+
+MAJOR_VERSION=0
+MINOR_VERSION=9
+
+outfd = sys.stdout
+
+def usage():
+ print """Usage: gen-size-report [<options>]
+
+-V show program version
+-h show this usage help
+"""
+
+
+def title(msg):
+ global outfd
+ outfd.write("### %s\n" % msg)
+
+def close_section():
+ global outfd
+ outfd.write("\n")
+
+def write_line(keyword, value, max_keylen=30):
+ global outfd
+ # format default to: "%-20s %10s\n" % max_keylen
+ format="%%-%ds %%10s\n" % max_keylen
+ outfd.write(format % (keyword+'=', value))
+
+def write_block(keyword, block):
+ global outfd
+ outfd.write("%s_start:\n" % keyword)
+ outfd.write(block)
+ outfd.write("%s_end\n" % keyword)
+
+def get_sizes(filename):
+ global KBUILD_OUTPUT
+
+ # get image sizes using 'size'
+ cmd = "size %s/%s" % (KBUILD_OUTPUT, filename)
+ (rcode, result) = commands.getstatusoutput(cmd)
+ try:
+ sizes = result.split('\n')[1].split()
+ except:
+ sizes = []
+
+ return sizes
+
+def write_sizes(keyword, sizes):
+ if sizes:
+ write_line("%s_total" % keyword, sizes[3])
+ write_line("%s_text" % keyword, sizes[0])
+ write_line("%s_data" % keyword, sizes[1])
+ write_line("%s_bss" % keyword, sizes[2])
+
+# return a list of compressed images which are present
+def get_compressed_image_list():
+ global KBUILD_OUTPUT
+
+ possible_images = [
+ "arch/x86/boot/bzImage",
+ "arch/arm/boot/Image",
+ "arch/arm/boot/uImage",
+ "arch/arm/boot/zImage",
+ "arch/arm/boot/compressed/vmlinux",
+ ]
+ present_images = []
+ for file in possible_images:
+ if os.path.isfile(file):
+ present_images.append(file)
+ return present_images
+
+def gen_totals():
+ title("Kernel image totals")
+
+ sizes = get_sizes("vmlinux")
+ write_sizes("kernel", sizes)
+
+ # try to find compressed image size
+ # this is arch and target dependent
+ compressed_images = get_compressed_image_list()
+ for filename in compressed_images:
+ size = os.path.getsize(filename)
+ type = os.path.basename(filename)
+ write_line("total_compressed_%s" % type, size)
+
+ close_section()
+
+
+def gen_subsystems():
+ title("Subsystems")
+
+ subsys_list = [
+ ("net", "net/built-in.o"),
+ ("drivers_net", "drivers/net/built-in.o"),
+ ("ipc", "ipc/built-in.o"),
+ ("lib", "lib/built-in.o"),
+ ("security", "security/built-in.o"),
+ ("fs", "fs/built-in.o"),
+ ("sound", "sound/built-in.o"),
+ ("drivers_char", "drivers/char/built-in.o"),
+ ("drivers_video", "drivers/video/built-in.o"),
+ # could add more here
+ ]
+
+ for (name, file) in subsys_list:
+ sizes = get_sizes(file)
+ write_sizes("subsys_%s" % name, sizes)
+
+ close_section()
+
+def gen_symbols():
+ global KBUILD_OUTPUT
+
+ title("Symbols")
+
+ # read symbols from kernel image
+ # (some code stolen from bloat-o-meter)
+ filename = "%s/vmlinux" % KBUILD_OUTPUT
+ symlines = os.popen("nm --size-sort %s" % filename).readlines()
+
+ symbols = {}
+ for line in symlines:
+ size, type, name = line[:-1].split()
+ if type in "tTdDbB":
+ if "." in name:
+ name = "static_" + name.split(".")[0]
+ symbols[name] = symbols.get(name, 0) + int(size, 16)
+
+ symlist = symbols.keys()
+ max_sym_len = 0
+ for sym in symlist:
+ if max_sym_len<len(sym):
+ max_sym_len= len(sym)
+ symlist.sort()
+ for sym in symlist:
+ write_line("symbol_%s" % sym, symbols[sym], max_sym_len)
+
+ # FIXTHIS - should highlight symbols with largest size here?
+ # sort by size, and list top 20 (?) entries
+
+ close_section()
+
+
+def gen_reference():
+ global KBUILD_OUTPUT
+
+ title("Reference\n")
+
+ # FIXTHIS - show kernel version
+ # FIXTHIS - show compiler version
+
+ # save configuration with report
+ config_filename = "%s/.config" % KBUILD_OUTPUT
+ config = open(config_filename).read()
+ write_block("kernel_config", config)
+
+ close_section()
+
+def main():
+ global KBUILD_OUTPUT
+
+ if "-V" in sys.argv:
+ print "gen-size-report version %d.%d" % \
+ (MAJOR_VERSION, MINOR_VERSION)
+ sys.exit(0)
+ if "-h" in sys.argv:
+ usage()
+ sys.exit(0)
+
+ try:
+ KBUILD_OUTPUT=os.environ["KBUILD_OUTPUT"]
+ except:
+ KBUILD_OUTPUT="."
+
+ # make sure the kernel is built and ready for sizing
+ # check that vmlinux is present
+ kernel_file = "%s/vmlinux" % KBUILD_OUTPUT
+ if not os.path.isfile(kernel_file):
+ print "Error: Didn't find kernel file: %s" % kernel_file
+ print "Not continuing. Please build kernel and try again."
+ sys.exit(1)
+
+ # generate size information
+ gen_totals()
+ gen_subsystems()
+ gen_symbols()
+ #gen_runtime()
+ gen_reference()
+
+main()
^ permalink raw reply related
* 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
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