* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Pádraig Brady @ 2009-01-15 12:59 UTC (permalink / raw)
To: Måns Rullgård; +Cc: linux-kernel, linux-embedded
In-Reply-To: <yw1x3ag2t2gd.fsf@thrashbarg.mansr.com>
Måns Rullgård wrote:
> Alejandro Mery <amery@opensde.org> writes:
>
>> I think the $(( ... )) bash-ism can be replaced with a simple .c helper toy.
>
> The $(( ... )) construct is standard POSIX shell syntax, see
> http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_06_04
>
> Bash supports $[ ... ] as an alternate syntax for the same thing.
> Perhaps you were thinking of that.
I think the misconception that $(( ... )) is a bashism is caused by
the wrong highlighting defaults chosen by vim. To fix this add this to ~/.vimrc
let g:is_posix = 1
That will also allow you to use the $(command) POSIX construct.
BTW, the vim syntax maintainers don't agree with changing this default:
http://groups.google.com/group/vim_dev/browse_thread/thread/41139a32772b2f5f
cheers,
Pádraig.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Pádraig Brady @ 2009-01-15 14:32 UTC (permalink / raw)
To: Rob Landley
Cc: H. Peter Anvin, Leon Woestenberg, Embedded Linux mailing list,
linux-kernel, Sam Ravnborg, austin-group-l
In-Reply-To: <200901040029.03396.rob@landley.net>
Rob Landley wrote:
> Implementing something by hand isn't _always_ a good alternative, sure. That
> would be the "thinking about the problem" part. In this instance, avoiding
> overflow is trivial. (If 1<<-1 didn't wrap around, it wouldn't even need the
> if statement.)
I don't think this affects your script but it's worth noting
that both bash and ksh use arithmetic rather than logical shift
for the >> operator.
Now arithmetic shift is not useful on 2's compliment machines,
and moreover it's compiler dependent as to whether arithmetic
or logical shift is done for >>. Therefore to increase usefulness
and decrease ambiguity, shells really should only shift unsigned
variables internally.
I know the opengroup spec says to use signed ints, but I think
that is intended to disambiguate input and output, rather than defining
internal operations. This is correct I think since the POSIX spec says
you can even use floating point internally if you like.
I asked the bash maintainer who said he would need clarification
from the austin group (CC'd) before changing anything.
cheers,
Pádraig.
^ permalink raw reply
* ramfs/tmpfs for application partition
From: Jacob Avraham @ 2009-01-15 16:43 UTC (permalink / raw)
To: linux-embedded@vger.kernel.org
Hi,
I have a system with 128M RAM and a flash partitioned so that 10M is dedicated to initramfs image,
6M to application partition. And another 6M for JFFS2.
As I have plenty of RAM, I'd like to have my application directory mounted on RAM, from a pre-populated
filesystem that resides in the 6M application partition.
So basically I want to use the same mechanism as initramfs, but mounted on /my/app/partition instead of root.
Does it make sense? How do I go about and do that?
Jacob Avraham
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
^ permalink raw reply
* RE: ramfs/tmpfs for application partition
From: Leisner, Martin @ 2009-01-15 16:55 UTC (permalink / raw)
To: Jacob Avraham, linux-embedded
In-Reply-To: <FF584854D6FFE547AB2F7515A798AC3A045716A1B4@venus.imagineil.tv>
Not sure I fully understand....
You basically want two blobs -- the initramfs and the application?
You can expand the initramfs by copying to it...so you mount the application and run a script to copy it to initramfs before running it.
marty
> -----Original Message-----
> From: linux-embedded-owner@vger.kernel.org [mailto:linux-embedded-
> owner@vger.kernel.org] On Behalf Of Jacob Avraham
> Sent: Thursday, January 15, 2009 11:43 AM
> To: linux-embedded@vger.kernel.org
> Subject: ramfs/tmpfs for application partition
>
>
> Hi,
>
> I have a system with 128M RAM and a flash partitioned so that 10M is
> dedicated to initramfs image,
> 6M to application partition. And another 6M for JFFS2.
> As I have plenty of RAM, I'd like to have my application directory
> mounted on RAM, from a pre-populated
> filesystem that resides in the 6M application partition.
> So basically I want to use the same mechanism as initramfs, but mounted
> on /my/app/partition instead of root.
> Does it make sense? How do I go about and do that?
>
>
> Jacob Avraham
>
>
>
>
>
> ************************************************************************
> ************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals &
> computer viruses.
> ************************************************************************
> ************
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ramfs/tmpfs for application partition
From: Mike Frysinger @ 2009-01-15 17:04 UTC (permalink / raw)
To: Jacob Avraham; +Cc: linux-embedded@vger.kernel.org
In-Reply-To: <FF584854D6FFE547AB2F7515A798AC3A045716A1B4@venus.imagineil.tv>
On Thu, Jan 15, 2009 at 11:43, Jacob Avraham wrote:
> I have a system with 128M RAM and a flash partitioned so that 10M is dedicated to initramfs image,
> 6M to application partition. And another 6M for JFFS2.
> As I have plenty of RAM, I'd like to have my application directory mounted on RAM, from a pre-populated
> filesystem that resides in the 6M application partition.
> So basically I want to use the same mechanism as initramfs, but mounted on /my/app/partition instead of root.
> Does it make sense? How do I go about and do that?
`mount -t tmpfs tmpfs /my/app/partition` ?
-mike
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Jamie Lokier @ 2009-01-15 18:52 UTC (permalink / raw)
To: Pádraig Brady; +Cc: Måns Rullgård, linux-kernel, linux-embedded
In-Reply-To: <496F3344.9060104@draigBrady.com>
Pádraig Brady wrote:
> > The $(( ... )) construct is standard POSIX shell syntax, see
> > http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_06_04
> >
> > Bash supports $[ ... ] as an alternate syntax for the same thing.
> > Perhaps you were thinking of that.
>
> I think the misconception that $(( ... )) is a bashism is caused by
> the wrong highlighting defaults chosen by vim.
I think the misconception is because traditional unix bourne shells
don't implement that construct. I just tried it on a few machines,
and it failed on 4 of them. Admittedly, the only up to date one is
running Solaris 10; the others are older unixes that you're unlikely
to build Linux on.
-- Jamie
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Måns Rullgård @ 2009-01-15 19:45 UTC (permalink / raw)
To: Jamie Lokier
Cc: Pádraig Brady, Måns Rullgård, linux-kernel,
linux-embedded
In-Reply-To: <20090115185224.GB5440@shareable.org>
Jamie Lokier <jamie@shareable.org> writes:
> Pádraig Brady wrote:
>> > The $(( ... )) construct is standard POSIX shell syntax, see
>> > http://www.opengroup.org/onlinepubs/000095399/utilities/xcu_chap02.html#tag_02_06_04
>> >
>> > Bash supports $[ ... ] as an alternate syntax for the same thing.
>> > Perhaps you were thinking of that.
>>
>> I think the misconception that $(( ... )) is a bashism is caused by
>> the wrong highlighting defaults chosen by vim.
>
> I think the misconception is because traditional unix bourne shells
> don't implement that construct. I just tried it on a few machines,
> and it failed on 4 of them. Admittedly, the only up to date one is
> running Solaris 10; the others are older unixes that you're unlikely
> to build Linux on.
On Solaris, /usr/xpg4/bin/sh is usually a POSIX-compliant shell. I
don't know how long it has been there.
--
Måns Rullgård
mans@mansr.com
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-16 6:11 UTC (permalink / raw)
To: Jamie Lokier
Cc: Paul Mundt, Sam Ravnborg, Mark A. Miller, Bernd Petrovitsch,
Leon Woestenberg, H. Peter Anvin, Embedded Linux mailing list,
linux-kernel, Andrew Morton
In-Reply-To: <20090114025115.GB22154@shareable.org>
On Tuesday 13 January 2009 20:51:16 Jamie Lokier wrote:
> Paul Mundt wrote:
> > This happens in a lot of places, like embedded gentoo ports, where almost
> > all of the work is sent across distcc to a cross-compilation machine. In
> > systems that use package management, it is done on the host through
> > emulation, or painfully cross-compiled.
>
> Ah yes, I remember using embedded Gentoo.
>
> 95% of the time in ./configure scripts, 5% in compilations.
With SMP becoming commonplace, expect this to become the norm everywhere.
Once you get to around quad processor, any C program with a ./configure step
is probably going to take longer to configure than to compile. (Of course C++
manages to remain slow enough that autoconf isn't so obvious a bottleneck.)
> And this is on x86! I dread to think how slow it gets on something
> slow.
My friend Mark's been experimenting with the amazon "cloud" thing, feeding in
an image with a qemu instance and distcc+cross-compiler, and running builds
under that. Renting an 8-way ~2.5 ghz server with 7 gigabytes of ram and 1.6
terabytes of disk is 80 cents/hour through them plus another few cents/day for
bandwidth and persistent storage and such. That's likely to get cheaper as
time goes on.
We're still planning to buy a build server of our own to have something in-
house, but for running nightly builds it's almost to the point where
depreciation on the hardware is more than buying time from a server farm.
Just _one_ of those 8-way servers is enough hardware to build an entire distro
in an hour or so.
What this really allows us to do is experiment with "how parallel can we get
our build"? Because renting ten 8-way servers in a cluster is $8/hour, and
distcc already scales trivially over that. Down the road what Firmware Linux
is working towards is multiple qemu instances running in parallel with a
central instance distributing builds to each one, so each can do its own
./configure in parallel, distribute compilation to the distccd instances as it
has stuff to compile, and then package up the resulting binary into one of
those portage tarballs and send it back to the central node to install on a
network mount that the lot of 'em can mount as build context, so the packages
can get their dependencies right. (You don't want your build taking place in
a network mount, but your OS being on one you never write to isn't so bad as
long as you have local storage to build in.)
We'll probably leverage the heck out of Portage for this, and might wind up
modifying it heavily. Dunno yet. (We can even force dependencies on portage
so it doesn't need to calculate 'em, the central node can do that and then say
"you have these packages, _build_"...)
But yeah, hobbyists with a laptop, network access, and a monthly budget of $20
can do cluster builds these days.
Rob
P.S. I still hope autoconf dies off and the world wakes up and moves away
from that. And from makefiles for that matter. But in the meantime, I can
work around it with enough effort.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Alexander Neundorf @ 2009-01-16 7:28 UTC (permalink / raw)
To: Embedded Linux mailing list
In-Reply-To: <200901160011.11679.rob@landley.net>
On Friday 16 January 2009 07:11:09 Rob Landley wrote:
...
> P.S. I still hope autoconf dies off and the world wakes up and moves away
> from that.
Parts of it did already :-)
In KDE we switched to CMake, getting rid of automake, autoconf, libtool and
m4, and many of those developers now bring CMake into other projects they are
working on.
Still, the configure (or cmake) step remains, and it remains non-parallel, it
is much harder to parallelize than the build itself.
Alex
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Valdis.Kletnieks @ 2009-01-16 14:54 UTC (permalink / raw)
To: Rob Landley
Cc: Jamie Lokier, Paul Mundt, Sam Ravnborg, Mark A. Miller,
Bernd Petrovitsch, Leon Woestenberg, H. Peter Anvin,
Embedded Linux mailing list, linux-kernel, Andrew Morton
In-Reply-To: <200901160011.11679.rob@landley.net>
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
On Fri, 16 Jan 2009 00:11:09 CST, Rob Landley said:
> P.S. I still hope autoconf dies off and the world wakes up and moves away
> from that. And from makefiles for that matter. But in the meantime, I can
> work around it with enough effort.
What do you propose autoconf and makefiles get replaced by?
% wc pidgin/configure*
34287 118303 1004074 pidgin/configure
2499 7684 81532 pidgin/configure.ac
Which you rather code, 2.5K lines of autoconf or 35K lines of configure
script? As long as there's enough diversity to require configure scripts,
there's going to be a demand for an autoconf-ish feature to ease writing them.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-16 21:54 UTC (permalink / raw)
To: Valdis.Kletnieks, Embedded Linux mailing list; +Cc: Sam Ravnborg, linux-kernel
In-Reply-To: <15458.1232117682@turing-police.cc.vt.edu>
On Friday 16 January 2009 08:54:42 Valdis.Kletnieks@vt.edu wrote:
> On Fri, 16 Jan 2009 00:11:09 CST, Rob Landley said:
> > P.S. I still hope autoconf dies off and the world wakes up and moves
> > away from that. And from makefiles for that matter. But in the
> > meantime, I can work around it with enough effort.
>
> What do you propose autoconf and makefiles get replaced by?
At a first guess, meaningful standards and an acknowledgement that Linux is a
platform in its own right? Between the two of them, that's 90% of your
problem right there.
Not a new issue, here's a link from 2002:
http://news.cnet.com/2100-1001-950180.html
And here's a multi-vendor effort at a standards group (the 86open project to
definite a Unix binary standard for x86 processors) dissolving itself way back
in 1999 with a declaration that the Linux binary format already was an open
standard and other unixes should just use things like lxrun to support that:
http://www.telly.org/86open/
Also, it would be nice if configure steps could stop entangling 1) users
providing preferences (command line options like --prefix or most of the --
enable and --disable flags) for which things like kconfig might make more
sense, 2) probe for installed packages like zlib and enabling optional support
if found, 3) questions like "does my build environment provide strlcpy()".
Turning that into a big hairball does not help keep things simple.
> % wc pidgin/configure*
> 34287 118303 1004074 pidgin/configure
> 2499 7684 81532 pidgin/configure.ac
>
> Which you rather code, 2.5K lines of autoconf or 35K lines of configure
> script?
I consider it a false dichotomy. I prefer "neither", and have seen it done
successfully many times.
I've never built pidgin from source, but I've got the output of the binutils
build in a log file. How many of these tests are actually necessary on any
Linux system:
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking for suffix of object files... o
checking whether gcc accepts -g... yes
checking for library containing strerror... none required
checking how to run the C preprocessor... gcc -E
checking whether build environment is sane... yes
checking whether gcc and cc understand -c and -o together... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline
It just goes on and on and on like this. Tests like "checking whether byte
ordering is bigendian... no" means "Either I didn't know endian.h existed, or
I don't trust it to be there". How about the long stretches checking for the
existence of header files specified by posix? Or this gem:
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
(If you can use awk, when is it _not_ there? Probable answer: there was some
broken version on irix back in 1992 with zero remaining seats today, and they
never went back to clean anything out of the makefile because "simplifying the
build" and "autoconf" do not go together, and because you can't sanely
regression test against build environments nobody has anymore.)
This argument is a can of worms, and the linux-kernel list probably isn't the
best place for it. However, "install mingw on windows instead of trying to
get your thing to build under Visual Studio" is a decent support strategy.
Tinycc and Intel's icc both implemented gcc extensions to build the kernel,
and the kernel's been removing such extensions where c99 versions are
available since then. Things like uClibc implement standards and copy glibc
extensions that are actually used.
In the era of open source, it's now a viable strategy to specify, document,
and require a standardized build environment. The way to make that build
environment portable is to keep it simple and standardized, not to create a
tower of #ifdefs testing the output of a huge environment probing shell
script.
Rob
^ permalink raw reply
* RE: ramfs/tmpfs for application partition
From: Jacob Avraham @ 2009-01-17 9:39 UTC (permalink / raw)
To: Leisner, Martin, linux-embedded@vger.kernel.org
In-Reply-To: <556445368AFA1C438794ABDA8901891C0A5A0C8E@USA0300MS03.na.xerox.net>
>
> Not sure I fully understand....
>
> You basically want two blobs -- the initramfs and the application?
>
Yes, I want to keep on the flash a stable, rarely changed, OS image, which is in initramfs
format, and another application image, which is changing frequently.
> You can expand the initramfs by copying to it...so you mount the
> application and run a script to copy it to initramfs before running it.
>
When you say 'you mount the application' it means that the application
image on the flash has to be in some filesystem format, right? Like cramfs?
On the other hand, if I want the application directory tree to reside
in memory (and handle application persistency needs via the JFFS2 partition),
maybe all I need is to keep a compressed tar image of the application on the flash,
and untar it into /my/application/partition, which will be in initramfs?
So I don't need to create another tmpfs filesystem as suggested in another post?
Is there a better way to handle this?
> marty
>
> >
> > Hi,
> >
> > I have a system with 128M RAM and a flash partitioned so that 10M
> is
> > dedicated to initramfs image,
> > 6M to application partition. And another 6M for JFFS2.
> > As I have plenty of RAM, I'd like to have my application directory
> > mounted on RAM, from a pre-populated
> > filesystem that resides in the 6M application partition.
> > So basically I want to use the same mechanism as initramfs, but
> mounted
> > on /my/app/partition instead of root.
> > Does it make sense? How do I go about and do that?
> >
> >
> > Jacob Avraham
> >
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Jamie Lokier @ 2009-01-17 9:51 UTC (permalink / raw)
To: Rob Landley
Cc: Valdis.Kletnieks, Embedded Linux mailing list, Sam Ravnborg,
linux-kernel
In-Reply-To: <200901161554.02054.rob@landley.net>
Rob Landley wrote:
> On Friday 16 January 2009 08:54:42 Valdis.Kletnieks@vt.edu wrote:
> > On Fri, 16 Jan 2009 00:11:09 CST, Rob Landley said:
> > > P.S. I still hope autoconf dies off and the world wakes up and moves
> > > away from that. And from makefiles for that matter. But in the
> > > meantime, I can work around it with enough effort.
> >
> > What do you propose autoconf and makefiles get replaced by?
>
> I've never built pidgin from source, but I've got the output of the binutils
> build in a log file.
> How many of these tests are actually necessary on an Linux system:
None, but then it's not a Linux-only program that you're compiling.
(Nor is it Linux-in-2009-only).
If you _know_ you're running on Linux from a particular era, you can
provide a config.cache file with the correct answers already filled in.
I agree that Autoconf sucks (I've written enough sucking Autoconf
macros myself, I hate it), but the tough part is providing a suitable
replacement when you still want portable source code.
> It just goes on and on and on like this. Tests like "checking
> whether byte ordering is bigendian... no" means "Either I didn't
> know endian.h existed, or I don't trust it to be there". How about
> the long stretches checking for the existence of header files
> specified by posix?
You seem to be arguing for "let's make all our programs Linux-specific
(and Glibc-specific in many cases)". Given all the problems you've
seen with cross-compiling, let alone compiling for different OS
platforms, that seems a little odd.
-- Jamie
^ permalink raw reply
* [RFC 2.6.28 1/2] gpiolib: add set/get batch v4
From: Jaya Kumar @ 2009-01-17 9:57 UTC (permalink / raw)
Cc: David Brownell, Eric Miao, Paulius Zaleckas, Geert Uytterhoeven,
Sam Ravnborg, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded, Jaya Kumar
Hi friends,
This is v4 of batch support for gpiolib. Thanks to David Brownell, Eric Miao,
David Hylands, Robin, Ben, Jamie and others for prior feedback. The post for
v3 summarized the previous discussion. Since then the changes I've made are:
- split the patches into generic and arch specific
- optimizing the empty mask case
- adjusting the API to add error returns
- documenting this optional API in gpio.txt
- cleanup of the commenting
Please let me know your thoughts and feedback.
Thanks,
jaya
Cc: David Brownell <david-b@pacbell.net>
Cc: Eric Miao <eric.miao@marvell.com>
Cc: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: linux-arm-kernel@lists.arm.linux.org.uk
Cc: linux-fbdev-devel@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
Cc: linux-embedded@vger.kernel.org
Signed-off-by: Jaya Kumar <jayakumar.lkml@gmail.com>
---
Documentation/gpio.txt | 60 ++++++++
drivers/gpio/Kconfig | 5 +
drivers/gpio/gpiolib.c | 323 ++++++++++++++++++++++++++++++++++++++++++++
include/asm-generic/gpio.h | 19 +++-
4 files changed, 406 insertions(+), 1 deletions(-)
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index b1b9887..d7e5fe9 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -185,6 +185,66 @@ and not to need spinlocks. Such optimized calls can make bitbanging
applications a lot more efficient (in both space and time) than spending
dozens of instructions on subroutine calls.
+[OPTIONAL] Spinlock-Safe GPIO Batch access
+------------------------------------------
+The original GPIO API implements single bit access to GPIO pins. Some
+drivers for devices that treat GPIO as a mechanism for bulk data transfer
+may find the performance of the single bit API to be inadequate. In this
+scenario, the user can consider enabling the batch access API. This API is
+as follows:
+
+ /* BATCH GPIO INPUT */
+int gpio_get_batch(unsigned gpio, u32 bitmask, int maskwidth, u32 *result);
+
+The following examples help explain how this function is to be used.
+ Q: How to get gpio pins 0 through 7? (8 bits)
+ A: gpio_get_batch(gpio=0, bitmask=0xFF, width=8, &result) result=0xnn
+ Q: How to get gpio pins 58 through 73? (16 bits)
+ A: gpio_get_batch(gpio=58, bitmask=0xFFFF, width=16, &result) result=0xnnnn
+ Q: How to get gpio pins 16 through 47? (32 bits)
+ A: gpio_get_batch(offset=16, bitmask=0xFFFFFFFF, width=32, &result)
+ A: result=0xnnnnnnnn
+
+ /* BATCH GPIO OUTPUT */
+int gpio_set_batch(unsigned gpio, u32 values, u32 bitmask, int maskwidth);
+
+The following examples help explain how this function is to be used.
+ Q: How to set gpio pins 0 through 7 to all 0? (8 bits)
+ A: gpio_set_batch(gpio=0, values=0x0, bitmask=0xFF, width=8);
+ Q: How to set gpio pins 58 through 73 to all 1? (16 bits)
+ A: gpio_set_batch(gpio=58, values=0xFFFF, bitmask=0xFFFF, width=16);
+ Q: How to set gpio pins 16 through 47 to 0xCAFEC001? (32 bits)
+ A: gpio_set_batch(gpio=16, values=0xCAFEC001, bitmask=0xFFFFFFFF, width=32);
+
+The following example shows the use of the batch API and a comparison with
+the original single bit API:
+
+Original input method which loops through a set of pins:
+- for (i = 0; i <= (DB15_GPIO_PIN - DB0_GPIO_PIN) ; i++)
+- res |= (gpio_get_value(DB0_GPIO_PIN + i)) ? (1 << i) : 0;
+
+Batch input method:
++ u16 val;
++ err = gpio_get_batch(DB0_GPIO_PIN, 0xFFFF, 16, &val);
+
+Original output method:
+- for (i = 0; i <= (DB15_GPIO_PIN - DB0_GPIO_PIN) ; i++)
+- gpio_set_value(DB0_GPIO_PIN + i, (data >> i) & 0x01);
+Batch output method:
++ int err;
++ err = gpio_set_batch(DB0_GPIO_PIN, data, 0xFFFF, 16);
+
+Using these calls for GPIOs that can't safely be accessed without sleeping
+(see below) is an error.
+
+Platform-specific implementations are encouraged to optimize the two
+calls by checking if the batch get/set requested can be achieved within the
+platform's fast path access to gpio registers. For example, if the starting
+gpio and width of bits to be written is contained within a single register
+then the platform specific implementation may choose to execute it. If the
+request is more complex, then the platform specific implementation can
+choose to call upon the platform independent __gpio_get/set_batch functions
+which are able to cross gpio_chip boundaries.
GPIO access that may sleep
--------------------------
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 3d25654..474070b 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -37,6 +37,11 @@ menuconfig GPIOLIB
if GPIOLIB
+config GPIOLIB_BATCH
+ bool "Batch GPIO support"
+ help
+ Say Y here to add the capability to batch set/get GPIOs.
+
config DEBUG_GPIO
bool "Debug GPIO calls"
depends on DEBUG_KERNEL
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 35e7aea..a9cf75e 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -643,6 +643,323 @@ static inline void gpiochip_unexport(struct gpio_chip *chip)
#endif /* CONFIG_GPIO_SYSFS */
+#ifdef CONFIG_GPIOLIB_BATCH
+/**
+ * __generic_gpio_set_batch() - Set batch of gpio pins in provided gpio_chip.
+ * @chip: gpio_chip containing this set of pins
+ * @offset: starting gpio pin
+ * @values: values to assign including masked bits
+ * @bitmask: the bitmask to be applied to values
+ * @width: the width of the bitmask
+ * Context: any
+ *
+ * This provides a generic platform independent set_batch capability.
+ * It invokes the associated gpio_chip.set() method to actually set the
+ * value. gpio_chip-s that don't implement their own optimized
+ * set_batch function are assigned this function as a default.
+ *
+ * The following examples help explain how this function works.
+ * Q: How to set gpio pins at offset 0 through 7 to all 0? (8 bits)
+ * A: offset=0, values=0x0, bitmask=0xFF, width=8
+ * Q: How to set gpio pins at offset 26 through 31 to all 1? (6 bits)
+ * A: offset=26, values=0x3F, bitmask=0x3F, width=6
+ * Q: How to set gpio pins at offset 16 through 31 to 0xCAFE? (16 bits)
+ * A: offset=16, values=0xCAFE, bitmask=0xFFFF, width=16
+ * Q: Why isn't width calculated from the mask here?
+ * A: This function is intended to be called repetitively and doing the
+ * bit shift looping to calculate the width here would be an undesirable
+ * penalty. Instead, the width is provided by the caller, thus avoiding
+ * the performance penalty since it is a fixed value known by the caller.
+ *
+ * Returns a negative errno if the caller supplied bad data, such as
+ * offset or width in excess of this chips gpio. Otherwise, we return zero
+ * as a success code.
+ */
+static int __generic_gpio_set_batch(struct gpio_chip *chip, unsigned offset,
+ u32 values, u32 bitmask, int width)
+{
+ int i;
+ int value;
+ u32 mask;
+
+ /*
+ * If the caller attempted to exceed the number of gpios that
+ * are in this chip, then we flag that as an invalid value for
+ * either the offset or the width supplied.
+ */
+ if (offset + width > chip->ngpio)
+ return -EINVAL;
+
+ /*
+ * We start the loop and continue till we reach the width
+ * of the bitmask that is provided to us.
+ */
+ for (i = 0; i < width; i++) {
+ /*
+ * If this bit is enabled by the bitmask then
+ * we perform the set. If it is disabled we leave
+ * it alone.
+ */
+ mask = 1 << i;
+ if (bitmask & mask) {
+ value = values & mask;
+ chip->set(chip, offset + i, value);
+ }
+ }
+
+ return 0;
+}
+
+/**
+ * __generic_gpio_get_batch() - Get batch of gpio pins in provided gpio_chip.
+ * @chip: gpio_chip containing this set of pins
+ * @offset: starting gpio pin
+ * @values: values to assign including masked bits
+ * @bitmask: the bitmask to be applied to values
+ * @width: the width of the bitmask
+ * @result: the result to be returned
+ * Context: any
+ *
+ * This provides a generic platform independent get_batch capability.
+ * It invokes the associated gpio_chip.get() method to actually set the
+ * value. gpio_chip-s that don't implement their own optimized
+ * get_batch function are assigned this function as a default.
+ *
+ * The following examples help explain how this function works.
+ * Q: How to get gpio pins at offset 0 through 7? (8 bits)
+ * A: offset=0, bitmask=0xFF, width=8, result=0xnn
+ * Q: How to get gpio pins at offset 26 through 31? (6 bits)
+ * A: offset=26, bitmask=0x3F, width=6, result=0xnn
+ * Q: How to get gpio pins at offset 16 through 31? (16 bits)
+ * A: offset=16, bitmask=0xFFFF, width=16, result=0xnnnn
+ * Q: Why isn't width calculated from the mask here?
+ * A: This function is intended to be called repetitively and doing the
+ * bit shift looping to calculate the width here would be an undesirable
+ * penalty. Instead, the width is provided by the caller, thus avoiding
+ * the performance penalty since it is a fixed value known by the caller.
+ *
+ * Returns a negative errno if the caller supplied bad data, such as
+ * offset or width in excess of this chips gpio. Otherwise, we return zero
+ * as a success code.
+ * Context: any
+ */
+static int __generic_gpio_get_batch(struct gpio_chip *chip, unsigned offset,
+ u32 bitmask, int width, u32 *result)
+{
+ int i;
+ u32 mask;
+ u32 values = 0;
+
+ /*
+ * If the caller attempted to exceed the number of gpios that
+ * are in this chip, then we flag that as an invalid value for
+ * either the offset or the width supplied.
+ */
+ if (offset + width > chip->ngpio)
+ return -EINVAL;
+
+ /*
+ * We start the loop and continue till we reach the width
+ * of the bitmask that is provided to us.
+ */
+ for (i = 0; i < width; i++) {
+ /*
+ * If this bit is enabled by the bitmask then
+ * we perform the get. If it is disabled we leave
+ * it alone thus leaving it as 0 because we initialized
+ * values.
+ */
+ mask = 1 << i;
+ if (bitmask & mask) {
+ if (chip->get(chip, offset + i))
+ values |= mask;
+ }
+ }
+
+ *result = values;
+ return 0;
+}
+
+/**
+ * __gpio_set_batch() - set batch of gpio pins across multiple gpio_chip-s
+ * @gpio: starting gpio pin
+ * @values: values to assign including masked bits
+ * @bitmask: the bitmask to be applied to values
+ * @bitwidth: the width of the bitmask
+ * Context: any
+ *
+ * This function is platform independent and uses the starting gpio and
+ * bitwidth information to iterate through the set of required gpio_chips
+ * to use their set_batch capability in order to set a batch of gpio pins.
+ * This function handles going across gpio_chip boundaries. It is intended
+ * to be called from arch/mach specific code if they detect that the caller
+ * requires functionality outside the fast-path.
+ *
+ * The following examples help explain how this function is to be used.
+ * Q: How to set gpio pins 0 through 7 to all 0? (8 bits)
+ * A: gpio=0, values=0x0, bitmask=0xFF, width=8
+ * Q: How to set gpio pins 58 through 73 to all 1? (16 bits)
+ * A: gpio=58, values=0xFFFF, bitmask=0xFFFF, width=16
+ * Q: How to set gpio pins 16 through 47 to 0xCAFEC001? (32 bits)
+ * A: offset=16, values=0xCAFEC001, bitmask=0xFFFFFFFF, width=32
+ * Q: Why isn't width calculated from the mask here?
+ * A: This function is intended to be called repetitively and doing the
+ * bit shift looping to calculate the width here would be an undesirable
+ * penalty. Instead, the width is provided by the caller, thus avoiding
+ * the performance penalty since it is a fixed value known by the caller.
+ *
+ * Returns a negative errno if the caller supplied bad data, such as
+ * gpio or width in excess of the platforms max gpio. Otherwise, we return
+ * zero as a success code.
+ *
+ */
+int __gpio_set_batch(unsigned gpio, u32 values, u32 bitmask, int bitwidth)
+{
+ struct gpio_chip *chip;
+ int i = 0;
+ int value, width, remwidth;
+ u32 mask;
+ int ret;
+
+ /*
+ * If the caller attempted to exceed the number of gpios that
+ * are available here, then we flag that as an invalid value for
+ * either the gpio or the width supplied.
+ */
+ if ((bitwidth > 32) || (gpio + bitwidth > ARCH_NR_GPIOS))
+ return -EINVAL;
+
+ do {
+ chip = gpio_to_chip(gpio + i);
+ WARN_ON(extra_checks && chip->can_sleep);
+
+ value = values >> i; /* shift off the used data bits */
+
+ /* Work out the remaining width in this chip. */
+ remwidth = ((chip->base + (int) chip->ngpio) -
+ ((int) gpio + i));
+
+ /*
+ * Check if the remaining bits to be handled are less than
+ * the remaining width in this chip.
+ */
+ width = min(bitwidth, remwidth);
+
+ /* Shift off the used mask bits. */
+ mask = bitmask >> i;
+
+ /* Now adjust mask by width of this set. */
+ mask &= ((1 << width) - 1);
+
+ /* If the mask is empty, then we can skip this chip. */
+ if (mask) {
+ ret = chip->set_batch(chip, gpio + i - chip->base,
+ value, mask, width);
+ if (ret)
+ return ret;
+ }
+
+ /* deduct the used bits from our todolist */
+ i += width;
+ bitwidth -= width;
+ } while (bitwidth);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(__gpio_set_batch);
+
+/**
+ * __gpio_get_batch() - get batch of gpio pins across multiple gpio_chip-s
+ * @gpio: starting gpio pin
+ * @bitmask: the bitmask to be applied to values
+ * @bitwidth: the width of the bitmask
+ * @result: returned values
+ * Context: any
+ *
+ * This function is platform independent and uses the starting gpio and
+ * bitwidth information to iterate through the set of required gpio_chips
+ * to use their get_batch capability in order to get a batch of gpio pins.
+ * This function handles going across gpio_chip boundaries. It is intended
+ * to be called from arch/mach specific code if they detect that the caller
+ * requires functionality outside the fast-path.
+ *
+ * The following examples help explain how this function is to be used.
+ * Q: How to get gpio pins 0 through 7? (8 bits)
+ * A: gpio=0, bitmask=0xFF, width=8, result=0xnn
+ * Q: How to get gpio pins 58 through 73? (16 bits)
+ * A: gpio=58, bitmask=0xFFFF, width=16, result=0xnnnn
+ * Q: How to get gpio pins 16 through 47? (32 bits)
+ * A: offset=16, bitmask=0xFFFFFFFF, width=32, result=0xnnnnnnnn
+ * Q: Why isn't width calculated from the mask here?
+ * A: This function is intended to be called repetitively and doing the
+ * bit shift looping to calculate the width here would be an undesirable
+ * penalty. Instead, the width is provided by the caller, thus avoiding
+ * the performance penalty since it is a fixed value known by the caller.
+ *
+ * Returns a negative errno if the caller supplied bad data, such as
+ * gpio or width in excess of the platforms max gpio. Otherwise, we return
+ * zero as a success code
+ *
+ */
+int __gpio_get_batch(unsigned gpio, u32 bitmask, int bitwidth, u32 *result)
+{
+ struct gpio_chip *chip;
+ int i = 0;
+ int width, remwidth;
+ u32 mask;
+ u32 values = 0;
+ u32 value;
+ int ret;
+
+ /*
+ * If the caller attempted to exceed the number of gpios that
+ * are available here, then we flag that as an invalid value for
+ * either the gpio or the width supplied.
+ */
+ if ((bitwidth > 32) || (gpio + bitwidth > ARCH_NR_GPIOS))
+ return -EINVAL;
+
+ do {
+ chip = gpio_to_chip(gpio + i);
+ WARN_ON(extra_checks && chip->can_sleep);
+
+ /* Work out the remaining width in this chip. */
+ remwidth = ((chip->base + (int) chip->ngpio) -
+ ((int) gpio + i));
+
+ /*
+ * Check if the remaining bits to be handled are less than
+ * the remaining width in this chip.
+ */
+ width = min(bitwidth, remwidth);
+
+ /* shift off the used mask bits */
+ mask = bitmask >> i;
+ /* now adjust mask by width of get */
+ mask &= ((1 << width) - 1);
+
+ /* If the mask is empty, then we can skip this chip. */
+ if (mask) {
+ ret = chip->get_batch(chip, gpio + i - chip->base,
+ mask, width, &value);
+ if (ret)
+ return ret;
+
+ /* shift result back into correct position */
+ values |= value << i;
+ }
+
+ /* deduct the used bits from our todolist */
+ i += width;
+ bitwidth -= width;
+ } while (bitwidth);
+
+ *result = values;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(__gpio_get_batch);
+#endif
+
/**
* gpiochip_add() - register a gpio_chip
* @chip: the chip to register, with chip->base initialized
@@ -683,6 +1000,12 @@ int gpiochip_add(struct gpio_chip *chip)
}
chip->base = base;
}
+#ifdef CONFIG_GPIOLIB_BATCH
+ if (!chip->set_batch)
+ chip->set_batch = __generic_gpio_set_batch;
+ if (!chip->get_batch)
+ chip->get_batch = __generic_gpio_get_batch;
+#endif
/* these GPIO numbers must not be managed by another gpio_chip */
for (id = base; id < base + chip->ngpio; id++) {
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 81797ec..29478d2 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -44,6 +44,10 @@ struct module;
* returns either the value actually sensed, or zero
* @direction_output: configures signal "offset" as output, or returns error
* @set: assigns output value for signal "offset"
+ * @set_batch: batch assigns output values for signals starting at
+ * "offset" with mask in "bitmask" all within this gpio_chip
+ * @get_batch: batch fetches values for consecutive signals starting at
+ * "offset" with mask in "bitmask" all within this gpio_chip
* @to_irq: optional hook supporting non-static gpio_to_irq() mappings;
* implementation may not sleep
* @dbg_show: optional routine to show contents in debugfs; default code
@@ -84,7 +88,14 @@ struct gpio_chip {
unsigned offset, int value);
void (*set)(struct gpio_chip *chip,
unsigned offset, int value);
-
+#ifdef CONFIG_GPIOLIB_BATCH
+ int (*set_batch)(struct gpio_chip *chip,
+ unsigned offset, u32 values,
+ u32 bitmask, int width);
+ int (*get_batch)(struct gpio_chip *chip,
+ unsigned offset, u32 bitmask,
+ int width, u32 *result);
+#endif
int (*to_irq)(struct gpio_chip *chip,
unsigned offset);
@@ -124,6 +135,12 @@ extern void gpio_set_value_cansleep(unsigned gpio, int value);
*/
extern int __gpio_get_value(unsigned gpio);
extern void __gpio_set_value(unsigned gpio, int value);
+#ifdef CONFIG_GPIOLIB_BATCH
+extern int __gpio_set_batch(unsigned gpio, u32 values, u32 bitmask,
+ int bitwidth);
+extern int __gpio_get_batch(unsigned gpio, u32 bitmask, int bitwidth,
+ u32 *result);
+#endif
extern int __gpio_cansleep(unsigned gpio);
--
1.5.2.3
^ permalink raw reply related
* [RFC 2.6.28 2/2] mach-pxa: add and use batch set/get gpio
From: Jaya Kumar @ 2009-01-17 9:57 UTC (permalink / raw)
Cc: David Brownell, Eric Miao, Paulius Zaleckas, Geert Uytterhoeven,
Sam Ravnborg, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded, Jaya Kumar
In-Reply-To: <12321862383405-git-send-email-jayakumar.lkml@gmail.com>
This patch adds support for pxa specific batch set/get of gpio. This
is exported to gpiolib via the gpio_chip interface and then used within
am300epd.c
Cc: David Brownell <david-b@pacbell.net>
Cc: Eric Miao <eric.miao@marvell.com>
Cc: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: linux-arm-kernel@lists.arm.linux.org.uk
Cc: linux-fbdev-devel@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
Cc: linux-embedded@vger.kernel.org
Signed-off-by: Jaya Kumar <jayakumar.lkml@gmail.com>
---
arch/arm/mach-pxa/Kconfig | 1 +
arch/arm/mach-pxa/am300epd.c | 23 ++++++------
arch/arm/mach-pxa/gpio.c | 63 +++++++++++++++++++++++++++++++++
arch/arm/mach-pxa/include/mach/gpio.h | 48 +++++++++++++++++++++++++
4 files changed, 124 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index f844425..1b3e631 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -41,6 +41,7 @@ config GUMSTIX_AM200EPD
bool "Enable AM200EPD board support"
config GUMSTIX_AM300EPD
+ select GPIOLIB_BATCH
bool "Enable AM300EPD board support"
endchoice
diff --git a/arch/arm/mach-pxa/am300epd.c b/arch/arm/mach-pxa/am300epd.c
index 4bd10a1..c065368 100644
--- a/arch/arm/mach-pxa/am300epd.c
+++ b/arch/arm/mach-pxa/am300epd.c
@@ -187,24 +187,25 @@ static void am300_cleanup(struct broadsheetfb_par *par)
static u16 am300_get_hdb(struct broadsheetfb_par *par)
{
- u16 res = 0;
- int i;
-
- for (i = 0; i <= (DB15_GPIO_PIN - DB0_GPIO_PIN) ; i++)
- res |= (gpio_get_value(DB0_GPIO_PIN + i)) ? (1 << i) : 0;
+ int err;
+ u32 val;
- return res;
+ err = gpio_get_batch(DB0_GPIO_PIN, 0xFFFF, 16, &val);
+ if (err) {
+ dev_err(&am300_device->dev, "get failed: %d\n", err);
+ return 0;
+ }
+ return (u16) val;
}
static void am300_set_hdb(struct broadsheetfb_par *par, u16 data)
{
- int i;
-
- for (i = 0; i <= (DB15_GPIO_PIN - DB0_GPIO_PIN) ; i++)
- gpio_set_value(DB0_GPIO_PIN + i, (data >> i) & 0x01);
+ int err;
+ err = gpio_set_batch(DB0_GPIO_PIN, data, 0xFFFF, 16);
+ if (err)
+ dev_err(&am300_device->dev, "set failed: %d\n", err);
}
-
static void am300_set_ctl(struct broadsheetfb_par *par, unsigned char bit,
u8 state)
{
diff --git a/arch/arm/mach-pxa/gpio.c b/arch/arm/mach-pxa/gpio.c
index 5fec1e4..46371a1 100644
--- a/arch/arm/mach-pxa/gpio.c
+++ b/arch/arm/mach-pxa/gpio.c
@@ -162,6 +162,67 @@ static void pxa_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
__raw_writel(mask, pxa->regbase + GPCR_OFFSET);
}
+#ifdef CONFIG_GPIOLIB_BATCH
+/*
+ * Set output GPIO level in batches
+ */
+static int pxa_gpio_set_batch(struct gpio_chip *chip, unsigned offset,
+ u32 values, u32 bitmask, int width)
+{
+ struct pxa_gpio_chip *pxa;
+
+ /* we're guaranteed by the caller that offset + bitmask remains
+ * in this chip.
+ */
+ pxa = container_of(chip, struct pxa_gpio_chip, chip);
+
+ /* bitmask is used twice in shifted form */
+ bitmask <<= offset;
+
+ values = (values << offset) & bitmask;
+ if (values)
+ __raw_writel(values, pxa->regbase + GPSR_OFFSET);
+
+ values = ~values & bitmask;
+ if (values)
+ __raw_writel(values, pxa->regbase + GPCR_OFFSET);
+
+ return 0;
+}
+
+/*
+ * Get output GPIO level in batches
+ */
+static int pxa_gpio_get_batch(struct gpio_chip *chip, unsigned offset,
+ u32 bitmask, int width, u32 *result)
+{
+ u32 values;
+ struct pxa_gpio_chip *pxa;
+
+ /* we're guaranteed by the caller that offset + bitmask remains
+ * in this chip.
+ */
+ pxa = container_of(chip, struct pxa_gpio_chip, chip);
+
+ values = __raw_readl(pxa->regbase + GPLR_OFFSET);
+
+ /* shift the result back into original position */
+ *result = (values >> offset) & bitmask;
+ return 0;
+}
+#endif
+
+/* this is done this way so that we can insert an ifdef-able value
+ * into the following GPIO_CHIP macro
+ */
+#ifdef CONFIG_GPIOLIB_BATCH
+#define SET_BATCH_MACRO .set_batch = pxa_gpio_set_batch,
+#define GET_BATCH_MACRO .get_batch = pxa_gpio_get_batch,
+#else
+#define SET_BATCH_MACRO
+#define GET_BATCH_MACRO
+#endif
+
#define GPIO_CHIP(_n) \
[_n] = { \
.regbase = GPIO##_n##_BASE, \
@@ -173,6 +234,8 @@ static void pxa_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
.set = pxa_gpio_set, \
.base = (_n) * 32, \
.ngpio = 32, \
+ SET_BATCH_MACRO \
+ GET_BATCH_MACRO \
}, \
}
diff --git a/arch/arm/mach-pxa/include/mach/gpio.h b/arch/arm/mach-pxa/include/mach/gpio.h
index 2c538d8..46d9022 100644
--- a/arch/arm/mach-pxa/include/mach/gpio.h
+++ b/arch/arm/mach-pxa/include/mach/gpio.h
@@ -56,6 +56,54 @@ static inline void gpio_set_value(unsigned gpio, int value)
}
}
+#ifdef CONFIG_GPIOLIB_BATCH
+static inline int gpio_set_batch(unsigned gpio, u32 values, u32 bitmask,
+ int bitwidth)
+{
+ int err = 0;
+ if (__builtin_constant_p(gpio) &&
+ (gpio + bitwidth < NR_BUILTIN_GPIO) &&
+ ((gpio + bitwidth) <= roundup(gpio+1, 32))) {
+ int shift;
+
+ shift = gpio % 32;
+ bitmask <<= shift;
+
+ values = (values << shift) & bitmask;
+ if (values)
+ GPSR(gpio) = values;
+
+ values = ~values & bitmask;
+ if (values)
+ GPCR(gpio) = values;
+ } else {
+ err = __gpio_set_batch(gpio, values, bitmask, bitwidth);
+ }
+ return err;
+}
+
+static inline int gpio_get_batch(unsigned gpio, u32 bitmask, int bitwidth,
+ u32 *result)
+{
+ int ret = 0;
+ if (__builtin_constant_p(gpio) &&
+ (gpio + bitwidth < NR_BUILTIN_GPIO) &&
+ ((gpio + bitwidth) <= roundup(gpio+1, 32))) {
+ int shift;
+ u32 values;
+
+ shift = gpio % 32;
+
+ values = GPLR(gpio);
+
+ *result = (values >> shift) & bitmask;
+ } else {
+ ret = __gpio_get_batch(gpio, bitmask, bitwidth, result);
+ }
+ return ret;
+}
+#endif
+
#define gpio_cansleep __gpio_cansleep
#define gpio_to_irq(gpio) IRQ_GPIO(gpio)
--
1.5.2.3
^ permalink raw reply related
* Re: ramfs/tmpfs for application partition
From: Marco @ 2009-01-17 15:55 UTC (permalink / raw)
To: Jacob Avraham; +Cc: Leisner, Martin, linux-embedded@vger.kernel.org
In-Reply-To: <FF584854D6FFE547AB2F7515A798AC3A045716A1F8@venus.imagineil.tv>
Hi Jacob,
only another idea, why do you think to use a persistant ram filesystem
(like pramfs) mounted on /my/application/partition? If you use a simple
ram you can repopulate after a power off/on the directory with a simple
untar of the archive. In this way you haven't to repopulate the
filesystem after each reboot. What do you think about it? Could it be a
solution?
Marco
Jacob Avraham ha scritto:
>> Not sure I fully understand....
>>
>> You basically want two blobs -- the initramfs and the application?
>>
> Yes, I want to keep on the flash a stable, rarely changed, OS image, which is in initramfs
> format, and another application image, which is changing frequently.
>
>> You can expand the initramfs by copying to it...so you mount the
>> application and run a script to copy it to initramfs before running it.
>>
> When you say 'you mount the application' it means that the application
> image on the flash has to be in some filesystem format, right? Like cramfs?
> On the other hand, if I want the application directory tree to reside
> in memory (and handle application persistency needs via the JFFS2 partition),
> maybe all I need is to keep a compressed tar image of the application on the flash,
> and untar it into /my/application/partition, which will be in initramfs?
> So I don't need to create another tmpfs filesystem as suggested in another post?
> Is there a better way to handle this?
>
>> marty
>>
>>> Hi,
>>>
>>> I have a system with 128M RAM and a flash partitioned so that 10M
>> is
>>> dedicated to initramfs image,
>>> 6M to application partition. And another 6M for JFFS2.
>>> As I have plenty of RAM, I'd like to have my application directory
>>> mounted on RAM, from a pre-populated
>>> filesystem that resides in the 6M application partition.
>>> So basically I want to use the same mechanism as initramfs, but
>> mounted
>>> on /my/app/partition instead of root.
>>> Does it make sense? How do I go about and do that?
>>>
>>>
>>> Jacob Avraham
>>>
>
>
>
>
>
> ************************************************************************************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
> ************************************************************************************
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Rob Landley @ 2009-01-18 1:44 UTC (permalink / raw)
To: Jamie Lokier
Cc: Valdis.Kletnieks, Embedded Linux mailing list, Sam Ravnborg,
linux-kernel
In-Reply-To: <20090117095143.GA20389@shareable.org>
On Saturday 17 January 2009 03:51:43 Jamie Lokier wrote:
> Rob Landley wrote:
> > On Friday 16 January 2009 08:54:42 Valdis.Kletnieks@vt.edu wrote:
> > > On Fri, 16 Jan 2009 00:11:09 CST, Rob Landley said:
> > > > P.S. I still hope autoconf dies off and the world wakes up and moves
> > > > away from that. And from makefiles for that matter. But in the
> > > > meantime, I can work around it with enough effort.
> > >
> > > What do you propose autoconf and makefiles get replaced by?
> >
> > I've never built pidgin from source, but I've got the output of the
> > binutils build in a log file.
> > How many of these tests are actually necessary on an Linux system:
>
> None, but then it's not a Linux-only program that you're compiling.
> (Nor is it Linux-in-2009-only).
Yeah, I noticed. It's not quite as bad as OpenSSL (where Linux support is
intentionally an afterthought), but things like "Libtool" are supposed to be a
NOP on ELF Linux and yet regularly screw up builds. (It's supposed to do
nothing, and can't manage to do it correctly. That's sad.)
> If you _know_ you're running on Linux from a particular era, you can
> provide a config.cache file with the correct answers already filled in.
And yet very few projects actually do.
As for "from a particular era", just for fun I fired up the Red Hat 9 qemu
image I keep around for this sort of thing, downloaded glibc 2.7 (the most
recent one they bothered to cut a tarball for on ftp.gnu.org and one of the
big autoconf offenders), and ran its ./configure. It died with:
configure: error:
*** These critical programs are missing or too old: gcc
*** Check the INSTALL file for required versions.
So you can't build a 2 year old version of glibc under a 6 year old version of
Linux (which was the most popular Linux version in the world when it shipped,
with about 50% market share among Linux seats). And yet glibc (one of the
FSF's flagship projects) bothers doing extensive autoconf probes. Why?
Autoconf isn't really _helping_ here...
The bottom line is that if your assumption is that you have an open source
application targeting an open source operating system, lots of the hoops you
used to have to jump through just aren't very interesting anymore.
> I agree that Autoconf sucks (I've written enough sucking Autoconf
> macros myself, I hate it), but the tough part is providing a suitable
> replacement when you still want portable source code.
Depends on your definition of "portable". The unix wars of the 80's are over;
they're pretty much all dead. Even the surviving legacy deployments of
Solaris and AIX provide Linux emulation environments. And of course FreeBSD's
done so for years:
http://www.onlamp.com/pub/a/bsd/2006/01/12/Big_Scary_Daemons.html
MacOS X and windows are still very much alive, but if you want to target those
you can either A) treat them as Posix/SUSv3 (which both _claim_ to support),
B) use cross platform libraries like SDL and opengl and program to their APIs,
C) bother to do a proper port of the thing ala
http://porting.openoffice.org/mac/ or http://www.kju-app.org/ or the way khtml
wound up in Safari.
For Windows there's Cygwin, running windows programs on Linux has Wine. Or
just qemu/kvm in either direction.
Basically, pick a standard to write to. If you want to write to posix and
SUSv4, do it. If you want to add in LSB and the Linux man pages, go for it.
But autoconf was designed for portability between Irix and HP-UX, which just
doesn't come up much anymore.
> > It just goes on and on and on like this. Tests like "checking
> > whether byte ordering is bigendian... no" means "Either I didn't
> > know endian.h existed, or I don't trust it to be there". How about
> > the long stretches checking for the existence of header files
> > specified by posix?
>
> You seem to be arguing for "let's make all our programs Linux-specific
> (and Glibc-specific in many cases)".
Checking for the existence of posix header files is Linux-specific?
I'm saying there are many standards, and you can choose to adhere to standards
like LP64 (which MacOSX, Linux, and the BSDs all support) and _say_ you do so
and achieve portability that way.
You also have "#if defined __linux__" and "#if defined __APPLE__" and so on,
so header files can do a lot of the tests that people wind up doing with
autoconf for some reason.
And there will always be platforms you're NOT portable to. (Game consoles
come to mind: your average autoconf recipe isn't going to make your program
run on a PS3, XBox 360, or Wii. Unless you load Linux on those systems first
and program for Linux.)
> Given all the problems you've
> seen with cross-compiling, let alone compiling for different OS
> platforms, that seems a little odd.
If I can't get Linux running on the hardware (which is seldom an interesting
case anymore; it's on everything from cell phones to the S390), and I can't
get a Linux emulation environment like Solaris' lxrun, aix5L, or cygwin, then
I probably want a rigidly posix environment. (Heck, even wince has celib and
gnuwince, not that I really care.)
The extra "portability" isn't even going to buy you 5% more seats these days.
It's really not that interesting. It's not that the world is homogenous now,
it's that between open source and open standards we don't need giant if/else
ladders with hundreds of tests to cover the interesting cases. And trying to
achieve portability by relying on standards is a superior approach to trying
to achieve portability via an infinite series of special case checks.
> -- Jamie
Rob
^ permalink raw reply
* Re: ramfs/tmpfs for application partition
From: Gilad Ben-Yossef @ 2009-01-18 13:55 UTC (permalink / raw)
To: Jacob Avraham; +Cc: Mike Frysinger, linux-embedded@vger.kernel.org
In-Reply-To: <FF584854D6FFE547AB2F7515A798AC3A045716A316@venus.imagineil.tv>
Jacob Avraham wrote:
> Gilad,
>
> Not out of the woods yet.
>
> I can’t just burn a tar ball straight into a raw mtd partition. When
> I’ll try to untar it, if I’ll do:
>
> tar zxf /dev/mtd6
>
> tar will read the whole mtd partition, and I don’t think it’s a good
> idea to use a raw device as tar file.
>
> So should I package the tar in a filesystem, like cramfs?
>
That's certainly possible - just make sure your tar file is smaller then
the 256Mb file limit of cramfs (if memory serves me right) - otherwise
just use squashfs.
I'll add that if you're already going to have a file system (and your
reasons seems to make sense to me) I would have just forgot about the
tar file and put the file in cramfs/squashfs to begin with and just copy
them over the initramfs during boot (something like cp -a /mnt/mtd6/* /).
> In that case, I don’t need to compress the tar file, as cramfs is
> compressed, right?
>
That is correct.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
Codefidence Ltd.
The code is free, your time isn't.(TM)
Web: http://codefidence.com
Email: gilad@codefidence.com
Office: +972-8-9316883 ext. 201
Fax: +972-8-9316885
Mobile: +972-52-8260388
The Doctor: Don't worry, Reinette, just a nightmare.
Everyone has nightmares. Even monsters from under the
bed have nightmares, don't you, monster?
Reinette: What do monsters have nightmares about?
The Doctor: Me!
^ permalink raw reply
* Re: [RFC 2.6.28 1/2] gpiolib: add set/get batch v4
From: Ryan Mallon @ 2009-01-18 20:05 UTC (permalink / raw)
To: Jaya Kumar
Cc: David Brownell, Eric Miao, Paulius Zaleckas, Geert Uytterhoeven,
Sam Ravnborg, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <12321862383405-git-send-email-jayakumar.lkml@gmail.com>
Jaya Kumar wrote:
> Hi friends,
>
> +
> + /* BATCH GPIO OUTPUT */
> +int gpio_set_batch(unsigned gpio, u32 values, u32 bitmask, int maskwidth);
> +
> +The following examples help explain how this function is to be used.
> + Q: How to set gpio pins 0 through 7 to all 0? (8 bits)
> + A: gpio_set_batch(gpio=0, values=0x0, bitmask=0xFF, width=8);
> + Q: How to set gpio pins 58 through 73 to all 1? (16 bits)
> + A: gpio_set_batch(gpio=58, values=0xFFFF, bitmask=0xFFFF, width=16);
> + Q: How to set gpio pins 16 through 47 to 0xCAFEC001? (32 bits)
> + A: gpio_set_batch(gpio=16, values=0xCAFEC001, bitmask=0xFFFFFFFF, width=32);
> +
Can the gpio_set_batch function be used to set non-consecutive gpios?
For example:
gpio_set_batch(0, 0x0, 0x88, 8);
To clear gpios 3 and 7? It looks like the pxa implementation will
support this, but can it be guaranteed for other architectures? If so,
can we put an example in the documentation. If not, can we make it clear
that you shouldn't do this in the documentation. Also , in the latter
case is it necessary to pass the bitmask, since it will just be ((1 <<
bitwidth) - 1)?
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon Unit 5, Amuri Park
Phone: +64 3 3779127 404 Barbadoes St
Fax: +64 3 3779135 PO Box 13 889
Email: ryan@bluewatersys.com Christchurch, 8013
Web: http://www.bluewatersys.com New Zealand
Freecall Australia 1800 148 751 USA 1800 261 2934
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
^ permalink raw reply
* Re: [RFC 2.6.28 1/2] gpiolib: add set/get batch v4
From: Jaya Kumar @ 2009-01-18 23:46 UTC (permalink / raw)
To: Ryan Mallon
Cc: David Brownell, Eric Miao, Paulius Zaleckas, Geert Uytterhoeven,
Sam Ravnborg, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <49738B8C.7020404@bluewatersys.com>
On Mon, Jan 19, 2009 at 4:05 AM, Ryan Mallon <ryan@bluewatersys.com> wrote:
> Jaya Kumar wrote:
>> Hi friends,
>>
>
>> +
>> + /* BATCH GPIO OUTPUT */
>> +int gpio_set_batch(unsigned gpio, u32 values, u32 bitmask, int maskwidth);
>> +
>> +The following examples help explain how this function is to be used.
>> + Q: How to set gpio pins 0 through 7 to all 0? (8 bits)
>> + A: gpio_set_batch(gpio=0, values=0x0, bitmask=0xFF, width=8);
>> + Q: How to set gpio pins 58 through 73 to all 1? (16 bits)
>> + A: gpio_set_batch(gpio=58, values=0xFFFF, bitmask=0xFFFF, width=16);
>> + Q: How to set gpio pins 16 through 47 to 0xCAFEC001? (32 bits)
>> + A: gpio_set_batch(gpio=16, values=0xCAFEC001, bitmask=0xFFFFFFFF, width=32);
>> +
>
> Can the gpio_set_batch function be used to set non-consecutive gpios?
> For example:
>
> gpio_set_batch(0, 0x0, 0x88, 8);
>
> To clear gpios 3 and 7? It looks like the pxa implementation will
Hi Ryan,
For the first part, yes, it can do non-consecutive gpios by using the
mask. Pins 3 and 7 are handled using a 5-bit mask. You'd do
gpio_set_batch(3 <- starting pin is gpio 3, 0x0 <- clear, 0x1F <-
mask, 5 <- bit width of mask);
> support this, but can it be guaranteed for other architectures? If so,
That's a tough question. My basic answer would be yes because I've
provided the generic set_batch handler that just uses single bit sets
to achieve it. See __generic_gpio_set_batch() in patch). But if your
question is deeper, ie: can it be optimized for other architectures? ;
then I think I have to handwave a bit. I believe it can, as most of
the CPUs I've seen expose gpio via a set register and clear register
with variation between a context register to select which bank/module
of gpios is being accessed versus just having a pool of set and clear
registers (like pxa). If a CPU didn't have this and just had a blanket
gpio register then the implementation would have to first read the
previous register value (or cache it) in order to support doing the
mask.
> can we put an example in the documentation. If not, can we make it clear
Good point. I'll put it in the docs.
> that you shouldn't do this in the documentation. Also , in the latter
> case is it necessary to pass the bitmask, since it will just be ((1 <<
> bitwidth) - 1)?
Yes, it is as you have non-consecutive bits. In the above case the
mask width is 5 bits, but 3 bits are masked off, so we need the mask
so that the caller can tell us which bits are masked off.
Thanks,
jaya
^ permalink raw reply
* Re: [RFC 2.6.28 1/2] gpiolib: add set/get batch v4
From: Jaya Kumar @ 2009-01-18 23:48 UTC (permalink / raw)
To: Ryan Mallon
Cc: David Brownell, Eric Miao, Paulius Zaleckas, Geert Uytterhoeven,
Sam Ravnborg, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <45a44e480901181546t140f7127hb2f2b5fbfdec8464@mail.gmail.com>
On Mon, Jan 19, 2009 at 7:46 AM, Jaya Kumar <jayakumar.lkml@gmail.com> wrote:
> On Mon, Jan 19, 2009 at 4:05 AM, Ryan Mallon <ryan@bluewatersys.com> wrote:
>> Jaya Kumar wrote:
>>> Hi friends,
>>>
>>
>>> +
>>> + /* BATCH GPIO OUTPUT */
>>> +int gpio_set_batch(unsigned gpio, u32 values, u32 bitmask, int maskwidth);
>>> +
>>> +The following examples help explain how this function is to be used.
>>> + Q: How to set gpio pins 0 through 7 to all 0? (8 bits)
>>> + A: gpio_set_batch(gpio=0, values=0x0, bitmask=0xFF, width=8);
>>> + Q: How to set gpio pins 58 through 73 to all 1? (16 bits)
>>> + A: gpio_set_batch(gpio=58, values=0xFFFF, bitmask=0xFFFF, width=16);
>>> + Q: How to set gpio pins 16 through 47 to 0xCAFEC001? (32 bits)
>>> + A: gpio_set_batch(gpio=16, values=0xCAFEC001, bitmask=0xFFFFFFFF, width=32);
>>> +
>>
>> Can the gpio_set_batch function be used to set non-consecutive gpios?
>> For example:
>>
>> gpio_set_batch(0, 0x0, 0x88, 8);
>>
>> To clear gpios 3 and 7? It looks like the pxa implementation will
>
> Hi Ryan,
>
> For the first part, yes, it can do non-consecutive gpios by using the
> mask. Pins 3 and 7 are handled using a 5-bit mask. You'd do
> gpio_set_batch(3 <- starting pin is gpio 3, 0x0 <- clear, 0x1F <-
> mask, 5 <- bit width of mask);
Correction: I meant to write 0x11 for the mask above (instead of 0x1F)
since you only want to clear the starting pin 3 and the ending pin 7
in the 5 bits. If we used 0x1F here, then we would clear all 5 bits
rather than just 3 and 7.
Thanks,
jaya
^ permalink raw reply
* Re: [RFC 2.6.28 1/2] gpiolib: add set/get batch v4
From: Ryan Mallon @ 2009-01-19 0:15 UTC (permalink / raw)
To: Jaya Kumar
Cc: David Brownell, Eric Miao, Paulius Zaleckas, Geert Uytterhoeven,
Sam Ravnborg, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <45a44e480901181546t140f7127hb2f2b5fbfdec8464@mail.gmail.com>
Jaya Kumar wrote:
> On Mon, Jan 19, 2009 at 4:05 AM, Ryan Mallon <ryan@bluewatersys.com> wrote:
>> Jaya Kumar wrote:
>>> Hi friends,
>>>
>>> +
>>> + /* BATCH GPIO OUTPUT */
>>> +int gpio_set_batch(unsigned gpio, u32 values, u32 bitmask, int maskwidth);
>>> +
>>> +The following examples help explain how this function is to be used.
>>> + Q: How to set gpio pins 0 through 7 to all 0? (8 bits)
>>> + A: gpio_set_batch(gpio=0, values=0x0, bitmask=0xFF, width=8);
>>> + Q: How to set gpio pins 58 through 73 to all 1? (16 bits)
>>> + A: gpio_set_batch(gpio=58, values=0xFFFF, bitmask=0xFFFF, width=16);
>>> + Q: How to set gpio pins 16 through 47 to 0xCAFEC001? (32 bits)
>>> + A: gpio_set_batch(gpio=16, values=0xCAFEC001, bitmask=0xFFFFFFFF, width=32);
>>> +
>> Can the gpio_set_batch function be used to set non-consecutive gpios?
>> For example:
>>
>> gpio_set_batch(0, 0x0, 0x88, 8);
>>
>> To clear gpios 3 and 7? It looks like the pxa implementation will
>
> Hi Ryan,
>
> For the first part, yes, it can do non-consecutive gpios by using the
> mask. Pins 3 and 7 are handled using a 5-bit mask. You'd do
> gpio_set_batch(3 <- starting pin is gpio 3, 0x0 <- clear, 0x1F <-
> mask, 5 <- bit width of mask);
>
>> support this, but can it be guaranteed for other architectures? If so,
>
> That's a tough question. My basic answer would be yes because I've
> provided the generic set_batch handler that just uses single bit sets
> to achieve it. See __generic_gpio_set_batch() in patch). But if your
> question is deeper, ie: can it be optimized for other architectures? ;
> then I think I have to handwave a bit. I believe it can, as most of
> the CPUs I've seen expose gpio via a set register and clear register
> with variation between a context register to select which bank/module
> of gpios is being accessed versus just having a pool of set and clear
> registers (like pxa). If a CPU didn't have this and just had a blanket
> gpio register then the implementation would have to first read the
> previous register value (or cache it) in order to support doing the
> mask.
The EP93xx has a single register for reading, set and clearing the
states of gpios, so it would have to be read, masked and written. I'm
not sure if that would be quicker than doing a for-loop over the 8-bits
in the register (the EP93xx has 8 register banks of 8 gpios, each with
their own reigster set). I guess that even if it cannot be optimised for
a given architecture, then the standard for-loop method can be used. As
long as it is documented that non-consecutive setting should work so
that arch implementers can get it correct.
>> can we put an example in the documentation. If not, can we make it clear
>
> Good point. I'll put it in the docs.
Cool, thanks.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon Unit 5, Amuri Park
Phone: +64 3 3779127 404 Barbadoes St
Fax: +64 3 3779135 PO Box 13 889
Email: ryan@bluewatersys.com Christchurch, 8013
Web: http://www.bluewatersys.com New Zealand
Freecall Australia 1800 148 751 USA 1800 261 2934
^ permalink raw reply
* Re: [RFC 2.6.28 1/2] gpiolib: add set/get batch v4
From: Uwe Kleine-König @ 2009-01-19 10:03 UTC (permalink / raw)
To: Jaya Kumar
Cc: David Brownell, Eric Miao, Paulius Zaleckas, Geert Uytterhoeven,
Sam Ravnborg, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <12321862383405-git-send-email-jayakumar.lkml@gmail.com>
Hi Jaya,
On Sat, Jan 17, 2009 at 05:57:17PM +0800, Jaya Kumar wrote:
> Hi friends,
>
> This is v4 of batch support for gpiolib. Thanks to David Brownell, Eric Miao,
> David Hylands, Robin, Ben, Jamie and others for prior feedback. The post for
> v3 summarized the previous discussion. Since then the changes I've made are:
> - split the patches into generic and arch specific
IMHO this should be three patches: "gpiolib", "pxa" and "am300epd".
Well, ...
> +[OPTIONAL] Spinlock-Safe GPIO Batch access
Is it really spinlock safe in general? Or only if gpio_cansleep(gpio)
if false for each gpio to get or set?
> +static int __generic_gpio_set_batch(struct gpio_chip *chip, unsigned offset,
> + u32 values, u32 bitmask, int width)
IMHO a better name is __gpio_set_batch_generic (or
__gpiolib_set_batch_generic?), YMMV.
> +int __gpio_set_batch(unsigned gpio, u32 values, u32 bitmask, int bitwidth)
Sometimes your width parameter is called bitwidth, sometimes width. I'd
like to have that consistant.
While talking about this parameter. I don't really like it, because you
can calculate it from bitmask. In an earlier mail you write:
bitwidth (needed to iterate and map to chip ngpios) could be
calculated from bitmask, but that involves iteratively counting
bits from the mask, so we would have to do 800*600 bit counts.
Unless, we do ugly things like cache the previous bitwidth/mask
and compare against the current caller arguments. Given that the
bitwidth would typically be a fixed value, I believe it is more
intuitive for the caller to provide it, ...
I think it's easier than that. bitwidth is just fls(bitmask) which
should be efficient enough not to bother the programmer. If bitmask is
constant it's even the compiler that does the work here.
BTW, I wonder why the argument to fls has type int and not unsigned.
Best regards,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [RFC 2.6.28 1/2] gpiolib: add set/get batch v4
From: Jaya Kumar @ 2009-01-19 14:19 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: David Brownell, Eric Miao, Paulius Zaleckas, Geert Uytterhoeven,
Sam Ravnborg, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <20090119100342.GA16400@pengutronix.de>
On Mon, Jan 19, 2009 at 6:03 PM, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> Hi Jaya,
>
> On Sat, Jan 17, 2009 at 05:57:17PM +0800, Jaya Kumar wrote:
>> Hi friends,
>>
>> This is v4 of batch support for gpiolib. Thanks to David Brownell, Eric Miao,
>> David Hylands, Robin, Ben, Jamie and others for prior feedback. The post for
>> v3 summarized the previous discussion. Since then the changes I've made are:
>> - split the patches into generic and arch specific
> IMHO this should be three patches: "gpiolib", "pxa" and "am300epd".
> Well, ...
Hi Uwe,
Ok, will do.
>
>> +[OPTIONAL] Spinlock-Safe GPIO Batch access
> Is it really spinlock safe in general? Or only if gpio_cansleep(gpio)
> if false for each gpio to get or set?
You are correct to raise this issue. It is only spinlock safe if
chip->cansleep is false. Initially, I wasn't sure what to do. The
original gpio set/get_value() just does;
WARN_ON(extra_checks && chip->can_sleep);
and it is documented as:
"
Spinlock-Safe GPIO access
-------------------------
<snip>
return zero. Also, using these calls for GPIOs that can't safely be accessed
without sleeping (see below) is an error.
"
I will change this in the batch code to return an error if can_sleep
is detected on any involved gpio_chip.
>
>> +static int __generic_gpio_set_batch(struct gpio_chip *chip, unsigned offset,
>> + u32 values, u32 bitmask, int width)
> IMHO a better name is __gpio_set_batch_generic (or
> __gpiolib_set_batch_generic?), YMMV.
Agreed. Will change.
>
>> +int __gpio_set_batch(unsigned gpio, u32 values, u32 bitmask, int bitwidth)
> Sometimes your width parameter is called bitwidth, sometimes width. I'd
> like to have that consistant.
Ok, you're right. I'll fix this.
>
> While talking about this parameter. I don't really like it, because you
> can calculate it from bitmask. In an earlier mail you write:
Agreed.
>
> bitwidth (needed to iterate and map to chip ngpios) could be
> calculated from bitmask, but that involves iteratively counting
> bits from the mask, so we would have to do 800*600 bit counts.
> Unless, we do ugly things like cache the previous bitwidth/mask
> and compare against the current caller arguments. Given that the
> bitwidth would typically be a fixed value, I believe it is more
> intuitive for the caller to provide it, ...
>
> I think it's easier than that. bitwidth is just fls(bitmask) which
> should be efficient enough not to bother the programmer. If bitmask is
> constant it's even the compiler that does the work here.
>
That is a good point. I agree that width is ugly in the main API. It
is just fls(mask) and I now realize that this is an inline so you're
right it would get taken care of by the compiler. fls is checked with
__constant_fls first. Beauty! Thanks Uwe! I'll make these changes.
Thanks,
jaya
^ permalink raw reply
* Re: [RFC 2.6.28 1/2] gpiolib: add set/get batch v4
From: Uwe Kleine-König @ 2009-01-19 17:25 UTC (permalink / raw)
To: Jaya Kumar
Cc: David Brownell, Eric Miao, Paulius Zaleckas, Geert Uytterhoeven,
Sam Ravnborg, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <45a44e480901190619i18749c75jaa2d4606da251921@mail.gmail.com>
Hi Jaya,
> >> +[OPTIONAL] Spinlock-Safe GPIO Batch access
> > Is it really spinlock safe in general? Or only if gpio_cansleep(gpio)
> > if false for each gpio to get or set?
>
> You are correct to raise this issue. It is only spinlock safe if
> chip->cansleep is false. Initially, I wasn't sure what to do. The
> original gpio set/get_value() just does;
> WARN_ON(extra_checks && chip->can_sleep);
> and it is documented as:
>
> "
> Spinlock-Safe GPIO access
> -------------------------
> <snip>
> return zero. Also, using these calls for GPIOs that can't safely be accessed
> without sleeping (see below) is an error.
> "
>
> I will change this in the batch code to return an error if can_sleep
> is detected on any involved gpio_chip.
Wait, I got it wrong. I thought gpio_set_value might sleep if
chip->cansleep is true, but there are extra API functions for
cansleep-chips. So I'd do it the same way as for the non-batch
functions and just WARN_ON(extra_checks && chip->cansleep) for each
involved chip.
Later it might make sense to add the _cansleep variants.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ 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