* Re: LZMA inclusion
From: Bernhard Reutner-Fischer @ 2008-12-03 20:45 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Tim Bird, lasse.collin, glp, linux-embedded
In-Reply-To: <20081203202009.GA6790@uranus.ravnborg.org>
On Wed, Dec 03, 2008 at 09:20:09PM +0100, Sam Ravnborg wrote:
>On Wed, Dec 03, 2008 at 08:58:52PM +0100, Bernhard Reutner-Fischer wrote:
>> On Wed, Dec 03, 2008 at 11:36:45AM -0800, Tim Bird wrote:
>> >Gregers Petersen wrote:
>> >> There was a small talk a few days ago involving a few of the OpenWrt
>> >> developers and David Woodhouse. One of the topics discussed, was a
>> >> question about the potential of including LZMA in the kernel.
>> >> Such an inclusion would be quite benefitial in terms of embedded
>> >> systems, but the major hurdle seems to be the code quality of LZMA itself.
>> >> This leads to the question I would like to raise; are there ongoing
>> >> plans (or considerations) to rewrite and merge LZMA, and has anyone
>> >> started working on it in practical terms?
>> >
>> >Did anyone answer this? CELF is currently considering funding
>> >a project to do this (add LZMA support to the kernel), and
>> >it would be good to get a feel for the current status...
>> > -- Tim
>>
>> AFAIK xz will be/is incompatible with this older LZMA, perhaps
>> larhzu wants to chime in on that.
>>
>> PS: A previous incarnation of that patch didn't work conventiently
>> for me, i had to do some small adjustments to the way it was put
>> into the kernel configury, like
>> http://repo.or.cz/w/buildroot.git?a=blob_plain;f=toolchain/kernel-headers/lzma/linux-2.6.22.1-002-lzma-vmlinuz.01.patch;hb=HEAD
>> http://repo.or.cz/w/buildroot.git?a=blob_plain;f=toolchain/kernel-headers/lzma/linux-2.6.22.1-003-lzma-vmlinuz.patch;hb=HEAD
>
>If these are required with latest kernel could I then ask you to
>properly submit them to: linux-kbuild@vger.kernel.org
AFAIK neither lzma nor xz support was accepted yet and i did not look
if those patchlets are still required for the currently proposed
xz or lzma support.
>
>No need to have good patches sitting at random places.
Of course not, agree. I certainly don't fancy accumulating random
patches for my own personal use, at any rate.
PS: Not sure if you, Sam, are the right person who cares for it, but
i think that the help-text and actual accepted arguments of
scripts/kconfig/lxdialog/check-lxdialog.sh are out of sync.
PPS: I did not verify if this is still the case, but I have this
comment as a reminder for a small issue with "archprepare" versus
headers_install, fwiw. It would be very handy if i could fuse those
two into a simple "make ... archprepare headers_install":
# some arches need archprepare
# FIXME: WTH! archprepare does not honour INSTALL_HDR_PATH
-(cd $(LINUX_HEADERS_UNPACK_DIR); \
$(MAKE) ARCH=$(KERNEL_ARCH) \
HOSTCC="$(HOSTCC)" HOSTCFLAGS="$(HOSTCFLAGS)" \
HOSTCXX="$(HOSTCXX)" \
KCONFIG_CONFIG="$(LINUX_HEADERS_DIR)/.config" \
INSTALL_HDR_PATH=$(LINUX_HEADERS_DIR) \
archprepare \
)
(cd $(LINUX_HEADERS_UNPACK_DIR); \
$(MAKE) ARCH=$(KERNEL_ARCH) \
HOSTCC="$(HOSTCC)" HOSTCFLAGS="$(HOSTCFLAGS)" \
HOSTCXX="$(HOSTCXX)" \
INSTALL_HDR_PATH=$(LINUX_HEADERS_DIR) \
headers_install \
)
^ permalink raw reply
* Re: LZMA inclusion
From: Sam Ravnborg @ 2008-12-03 20:20 UTC (permalink / raw)
To: Bernhard Reutner-Fischer; +Cc: Tim Bird, lasse.collin, glp, linux-embedded
In-Reply-To: <20081203195852.GB8563@mx.loc>
On Wed, Dec 03, 2008 at 08:58:52PM +0100, Bernhard Reutner-Fischer wrote:
> On Wed, Dec 03, 2008 at 11:36:45AM -0800, Tim Bird wrote:
> >Gregers Petersen wrote:
> >> There was a small talk a few days ago involving a few of the OpenWrt
> >> developers and David Woodhouse. One of the topics discussed, was a
> >> question about the potential of including LZMA in the kernel.
> >> Such an inclusion would be quite benefitial in terms of embedded
> >> systems, but the major hurdle seems to be the code quality of LZMA itself.
> >> This leads to the question I would like to raise; are there ongoing
> >> plans (or considerations) to rewrite and merge LZMA, and has anyone
> >> started working on it in practical terms?
> >
> >Did anyone answer this? CELF is currently considering funding
> >a project to do this (add LZMA support to the kernel), and
> >it would be good to get a feel for the current status...
> > -- Tim
>
> AFAIK xz will be/is incompatible with this older LZMA, perhaps
> larhzu wants to chime in on that.
>
> PS: A previous incarnation of that patch didn't work conventiently
> for me, i had to do some small adjustments to the way it was put
> into the kernel configury, like
> http://repo.or.cz/w/buildroot.git?a=blob_plain;f=toolchain/kernel-headers/lzma/linux-2.6.22.1-002-lzma-vmlinuz.01.patch;hb=HEAD
> http://repo.or.cz/w/buildroot.git?a=blob_plain;f=toolchain/kernel-headers/lzma/linux-2.6.22.1-003-lzma-vmlinuz.patch;hb=HEAD
If these are required with latest kernel could I then ask you to
properly submit them to: linux-kbuild@vger.kernel.org
No need to have good patches sitting at random places.
Sam
^ permalink raw reply
* Re: LZMA inclusion
From: Gregers Petersen @ 2008-12-03 20:09 UTC (permalink / raw)
To: Tim Bird, linux-embedded
In-Reply-To: <4936DFCD.2010204@am.sony.com>
Tim Bird wrote:
> Gregers Petersen wrote:
>> There was a small talk a few days ago involving a few of the OpenWrt
>> developers and David Woodhouse. One of the topics discussed, was a
>> question about the potential of including LZMA in the kernel.
>> Such an inclusion would be quite benefitial in terms of embedded
>> systems, but the major hurdle seems to be the code quality of LZMA itself.
>> This leads to the question I would like to raise; are there ongoing
>> plans (or considerations) to rewrite and merge LZMA, and has anyone
>> started working on it in practical terms?
>
> Did anyone answer this? CELF is currently considering funding
> a project to do this (add LZMA support to the kernel), and
> it would be good to get a feel for the current status...
> -- Tim
>
I actually had one direct reply, in relationship to this project:
http://tukaani.org/
The tukaani work seems to be quite work-in-progress/alpha, but there is
progress. If such a project is to be funded it would probably be a good
idea to several partners involved (also due to the fact that it would
benifit the community as a whole).
Chz
--
Gregers Petersen
People-stuff, layer 8 and anthropology
glp on irc
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
KAMIKAZE (bleeding edge) -----------------------
* 10 oz Vodka Shake well with ice and strain
* 10 oz Triple sec mixture into 10 shot glasses.
* 10 oz lime juice Salute!
---------------------------------------------------
^ permalink raw reply
* Re: LZMA inclusion
From: Bernhard Reutner-Fischer @ 2008-12-03 19:58 UTC (permalink / raw)
To: Tim Bird, lasse.collin; +Cc: glp, linux-embedded
In-Reply-To: <4936DFCD.2010204@am.sony.com>
On Wed, Dec 03, 2008 at 11:36:45AM -0800, Tim Bird wrote:
>Gregers Petersen wrote:
>> There was a small talk a few days ago involving a few of the OpenWrt
>> developers and David Woodhouse. One of the topics discussed, was a
>> question about the potential of including LZMA in the kernel.
>> Such an inclusion would be quite benefitial in terms of embedded
>> systems, but the major hurdle seems to be the code quality of LZMA itself.
>> This leads to the question I would like to raise; are there ongoing
>> plans (or considerations) to rewrite and merge LZMA, and has anyone
>> started working on it in practical terms?
>
>Did anyone answer this? CELF is currently considering funding
>a project to do this (add LZMA support to the kernel), and
>it would be good to get a feel for the current status...
> -- Tim
AFAIK xz will be/is incompatible with this older LZMA, perhaps
larhzu wants to chime in on that.
PS: A previous incarnation of that patch didn't work conventiently
for me, i had to do some small adjustments to the way it was put
into the kernel configury, like
http://repo.or.cz/w/buildroot.git?a=blob_plain;f=toolchain/kernel-headers/lzma/linux-2.6.22.1-002-lzma-vmlinuz.01.patch;hb=HEAD
http://repo.or.cz/w/buildroot.git?a=blob_plain;f=toolchain/kernel-headers/lzma/linux-2.6.22.1-003-lzma-vmlinuz.patch;hb=HEAD
^ permalink raw reply
* Re: LZMA inclusion
From: Florian Fainelli @ 2008-12-03 19:50 UTC (permalink / raw)
To: Tim Bird; +Cc: glp, linux-embedded
In-Reply-To: <4936DFCD.2010204@am.sony.com>
Hi Gregers, Tim,
Le Wednesday 03 December 2008 20:36:45 Tim Bird, vous avez écrit :
> Did anyone answer this? CELF is currently considering funding
> a project to do this (add LZMA support to the kernel), and
> it would be good to get a feel for the current status...
There has been an effort for x86 to have kernels compressed using bzip2 or
lzma [1]. The LZMA decompression code in lib/ and could be used by other
architectures as well.
[1] http://lkml.org/lkml/2008/9/6/165
--
Best regards, Florian Fainelli
Email : florian@openwrt.org
http://openwrt.org
-------------------------------
^ permalink raw reply
* Re: LZMA inclusion
From: Tim Bird @ 2008-12-03 19:36 UTC (permalink / raw)
To: glp; +Cc: linux-embedded
In-Reply-To: <492BA3FA.9010204@openwrt.org>
Gregers Petersen wrote:
> There was a small talk a few days ago involving a few of the OpenWrt
> developers and David Woodhouse. One of the topics discussed, was a
> question about the potential of including LZMA in the kernel.
> Such an inclusion would be quite benefitial in terms of embedded
> systems, but the major hurdle seems to be the code quality of LZMA itself.
> This leads to the question I would like to raise; are there ongoing
> plans (or considerations) to rewrite and merge LZMA, and has anyone
> started working on it in practical terms?
Did anyone answer this? CELF is currently considering funding
a project to do this (add LZMA support to the kernel), and
it would be good to get a feel for the current status...
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: Linux SBC recommendations
From: Marco Stornelli @ 2008-12-01 8:48 UTC (permalink / raw)
To: Greg Lee; +Cc: linux-embedded
In-Reply-To: <f7cd29ea0811301250r3070ed4fq9816ddcfcfe0cbaa@mail.gmail.com>
Hi Greg,
I suggest you this board:
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4102
It's very cheaper, sometimes ago I bought it for 65 Euro. However it
hasn't got an host USB port, but only a device one.
Regards,
Marco
Greg Lee ha scritto:
> I'm in the process of selecting a single-board computer (SBC) for a
> project and I'd like to hear what others are using sucessfully. My
> requirements for the SBC are:
>
> 1) Low cost (<$100)
> 2) Runs Linux
> 3) Has an Ethernet and USB host connection
> 4) Has sufficient storage capacity to run an small HTTP server such as
> mini httpd and a few MB left over for custom applications
> 5) Mechanical packaging suitable for a server room environment
> 6) Processing capacity requirement is not very large, low-power processor okay
>
> I previously assumed that I would use the Gumstix Vertex-Pro boards,
> but cost is a limiting factor on this project and precludes using
> these boards.
>
> What low-cost SBCs has the Linux Embedded community used with success?
>
> Greg
> --
> 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: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Jaya Kumar @ 2008-12-01 1:10 UTC (permalink / raw)
To: David Brownell
Cc: Eric Miao, Sam Ravnborg, Eric Miao, Haavard Skinnemoen,
Philipp Zabel, Russell King, Ben Gardner, Greg KH,
linux-arm-kernel, linux-fbdev-devel, linux-kernel, linux-embedded
In-Reply-To: <200811300955.30180.david-b@pacbell.net>
On Mon, Dec 1, 2008 at 1:55 AM, David Brownell <david-b@pacbell.net> wrote:
>
> They wouldn't want names so easily confused with the current set
> of GPIO calls, no.
>
Okay, how does gpio_set/get_values_batch() sound?
>
>> >
>> > Then separately two more things:
>> >
>> > - A gpio_* interface proposal for higher-level bitmask calls.
>> > This is worth some discussion; the calls should clearly
>> > be optional (not everything will implement them), and I
>> > can't help but suspect <linux/bitmap.h> interfaces should
>> > interoperate smoothly.
>
> ... including probably ganged request/free, and direction updates.
> When bitbanging a multiplexed parallel databus, you'll often need
> to change directions.
Okay, so I'll also add gpio_direction_output/input_batch and request/free_batch.
>
>
>> >
>> > - A gpiolib based implementation, using those new gpio_chip
>> > methods as accelerators if they're present. This should
>> > probably also be optional, even at the Kconfig level; many
>> > systems won't need to spend memory on these calls.
>>
>> Understood. I will make it optional. Does
>> CONFIG_GPIOLIB_MULTIBIT_ACCESS sound okay?
>
> Kind of verbose for my taste, and it's already "multibit" (one
> at a time, but still multiple) ... let's see some more mergeable
> proposals and code first. Different C file too, I suspect.
Ok, CONFIG_GPIOLIB_BATCH and I'll add this code in
drivers/gpio/gpiolib_batch.c. I hope I have understood that suggestion
correctly.
>
>
>> > Don't assume gpiolib when defining the interface.
>>
>> Ok, I didn't understand this part. I think you mentioned a higher
>> level interface before but I didn't fully understand, if not gpiolib,
>> then at what level do you recommend?
>
> The gpio_*() interfaces are how system glue code and drivers
> access GPIOs, unless they roll their own chip-specific calls.
>
> Whereas gpiolib (and gpio_chip) are an *optional* framework
> for implementing those calls. Platforms can (and do!) use
> other frameworks ... maybe they don't want to pay its costs,
> and don't need the various GPIO expander drivers.
>
> So to repeat: don't assume the interface is implemented in
> one particular way (using gpiolib). It has to make sense
> with other implementation strategies too. Standard split
> between interface and implementation, that's all. (Some folk
> have been heard to talk about "gpiolib" as the interface to
> drivers ... it's not, it's a provider-only interface library.)
>
Okay, I read above several times and I read Documentation/gpio.txt.
But... I'm not confident I've understood your meanings above in terms
of how it should change the code. What I know so far is:
a)
arch/arm/mach-pxa/include/mach/gpio.h is where the pxa GPIO api
interface is defined. So that's where I will put the
gpio_get/set_values_batch functions. This will match the existing
gpio_set/get_value code there.
b)
arch/arm/mach-pxa/gpio.c is where the implementation is.
So I'll put the pxa_gpio_direction_input/output_batch and
pxa_gpio_set/get_batch there.
c)
drivers/gpio/gpiolib_batch.c
This is where I'd put the generic platform independent implementations
of __gpio_set/get_values_batch
Does this sound consistent with your recommendation? If not, I need
more help to understand what changes you are recommending.
> Doesn't necessarily need to be *you* doing that, but if it only
> works on older gumstix boards it'd not be general enough. Which
> is part of why I say to get the lowest level proposal out there
> first. If done right, it'll be easy to support on other chips.
Yes, I completely agree that it must work on a wide range of
architectures. But I don't understand what you mean when you say get
the lowest level proposal out there first. I see the RFC code that I
posted as being the lowest level proposal (albeit needing better name
and bitmask support) and one that is sufficiently general that it can
be implemented on other architectures. If it can't, can you help me
understand by pointing to which portion would break on other archs?
Thanks,
jaya
^ permalink raw reply
* Re: Linux SBC recommendations
From: Aras Vaichas @ 2008-12-01 0:24 UTC (permalink / raw)
To: Greg Lee; +Cc: linux-embedded
In-Reply-To: <f7cd29ea0811301250r3070ed4fq9816ddcfcfe0cbaa@mail.gmail.com>
Greg Lee wrote:
> I'm in the process of selecting a single-board computer (SBC) for a
> project and I'd like to hear what others are using sucessfully. My
> requirements for the SBC are:
>
> 1) Low cost (<$100)
> 2) Runs Linux
> 3) Has an Ethernet and USB host connection
> 4) Has sufficient storage capacity to run an small HTTP server such as
> mini httpd and a few MB left over for custom applications
> 5) Mechanical packaging suitable for a server room environment
> 6) Processing capacity requirement is not very large, low-power processor okay
>
> I previously assumed that I would use the Gumstix Vertex-Pro boards,
> but cost is a limiting factor on this project and precludes using
> these boards.
>
> What low-cost SBCs has the Linux Embedded community used with success?
>
Might not be what you are looking for, but I've been buying up the first
generation of EEE PCs to use as a controller for some robots.
The EEE PC 4G model gives you Wifi, Ethernet, 3x USB host, SD card,
keyboard, webcam, LCD screen, audio in, audio out. Old models only cost
a couple hundred $ (depending on your currency).
There's nothing like having a screen and keyboard on an embedded Linux
machine to make your life that little bit easier.
Aras
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
^ permalink raw reply
* Re: Linux SBC recommendations
From: Ian Braithwaite @ 2008-11-30 21:55 UTC (permalink / raw)
To: linux-embedded
In-Reply-To: <f7cd29ea0811301250r3070ed4fq9816ddcfcfe0cbaa@mail.gmail.com>
"Greg Lee" <greg@gregandsarah.org> wrote:
> I'm in the process of selecting a single-board computer (SBC) for a
> project and I'd like to hear what others are using sucessfully. My
> requirements for the SBC are:
>
> 1) Low cost (<$100)
> 2) Runs Linux
> 3) Has an Ethernet and USB host connection
> 4) Has sufficient storage capacity to run an small HTTP server such as
> mini httpd and a few MB left over for custom applications
> 5) Mechanical packaging suitable for a server room environment
> 6) Processing capacity requirement is not very large, low-power processor okay
I'm not sure what you mean with (5), but
http://www.omnima.co.uk/store/catalog/Embedded-controller-p-16140.html
seems a good match otherwise, not least on price.
I'm using one as a USB printer/scanner network server, and a second as a
home gateway/firewall.
regards,
Ian
^ permalink raw reply
* Re: Linux SBC recommendations
From: Charles Manning @ 2008-11-30 21:38 UTC (permalink / raw)
To: Greg Lee; +Cc: linux-embedded
In-Reply-To: <f7cd29ea0811301250r3070ed4fq9816ddcfcfe0cbaa@mail.gmail.com>
On Monday 01 December 2008 09:50:49 Greg Lee wrote:
> I'm in the process of selecting a single-board computer (SBC) for a
> project and I'd like to hear what others are using sucessfully. My
> requirements for the SBC are:
>
> 1) Low cost (<$100)
> 2) Runs Linux
> 3) Has an Ethernet and USB host connection
> 4) Has sufficient storage capacity to run an small HTTP server such as
> mini httpd and a few MB left over for custom applications
> 5) Mechanical packaging suitable for a server room environment
> 6) Processing capacity requirement is not very large, low-power processor
> okay
>
> I previously assumed that I would use the Gumstix Vertex-Pro boards,
> but cost is a limiting factor on this project and precludes using
> these boards.
>
> What low-cost SBCs has the Linux Embedded community used with success?
It generally depends on other requirements too.
I would consider re-targeting a Linksys WRT54G or similar.
-- CHarles
^ permalink raw reply
* Re: Linux SBC recommendations
From: Belisko Marek @ 2008-11-30 21:37 UTC (permalink / raw)
To: Greg Lee; +Cc: linux-embedded
In-Reply-To: <f7cd29ea0811301250r3070ed4fq9816ddcfcfe0cbaa@mail.gmail.com>
Hi,
On Sun, Nov 30, 2008 at 9:50 PM, Greg Lee <greg@gregandsarah.org> wrote:
> I'm in the process of selecting a single-board computer (SBC) for a
> project and I'd like to hear what others are using sucessfully. My
> requirements for the SBC are:
>
> 1) Low cost (<$100)
> 2) Runs Linux
> 3) Has an Ethernet and USB host connection
> 4) Has sufficient storage capacity to run an small HTTP server such as
> mini httpd and a few MB left over for custom applications
> 5) Mechanical packaging suitable for a server room environment
> 6) Processing capacity requirement is not very large, low-power processor okay
>
> I previously assumed that I would use the Gumstix Vertex-Pro boards,
> but cost is a limiting factor on this project and precludes using
> these boards.
My favourite for low cost boards: http://glomationinc.com/
You can find many other at: http://elinux.org/Board_and_Chip_Vendors
>
> What low-cost SBCs has the Linux Embedded community used with success?
>
> Greg
> --
> 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
>
thanks,
Marek
--
as simple as primitive as possible
----------------------------------------------
Marek Beli코ko - open-nandra
Rusk치 Nov치 Ves 219
08005 Pre코ov
Slovakia
http://open-nandra.com
^ permalink raw reply
* Linux SBC recommendations
From: Greg Lee @ 2008-11-30 20:50 UTC (permalink / raw)
To: linux-embedded
I'm in the process of selecting a single-board computer (SBC) for a
project and I'd like to hear what others are using sucessfully. My
requirements for the SBC are:
1) Low cost (<$100)
2) Runs Linux
3) Has an Ethernet and USB host connection
4) Has sufficient storage capacity to run an small HTTP server such as
mini httpd and a few MB left over for custom applications
5) Mechanical packaging suitable for a server room environment
6) Processing capacity requirement is not very large, low-power processor okay
I previously assumed that I would use the Gumstix Vertex-Pro boards,
but cost is a limiting factor on this project and precludes using
these boards.
What low-cost SBCs has the Linux Embedded community used with success?
Greg
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: David Brownell @ 2008-11-30 17:55 UTC (permalink / raw)
To: Jaya Kumar
Cc: Eric Miao, Sam Ravnborg, Eric Miao, Haavard Skinnemoen,
Philipp Zabel, Russell King, Ben Gardner, Greg KH,
linux-arm-kernel, linux-fbdev-devel, linux-kernel, linux-embedded
In-Reply-To: <45a44e480811291552i77878bcdn5fe33f48fc4236eb@mail.gmail.com>
On Saturday 29 November 2008, Jaya Kumar wrote:
> On Sun, Nov 30, 2008 at 6:54 AM, David Brownell <david-b@pacbell.net> wrote:
> > If you want to pursue this, I'd like to get the gpio_chip
> > proposal in place first: bitmask read and write, without
> > forcing an "all bits are contiguous" policy. Lightweight.
>
> Yup, yup, I definitely want to pursue it. I want Linux e-paper
> displays to be zippy. :-) Agreed, I will do bitmask read and write.
> Hey, wait a sec, bitmask write definitely. but bitmask read is
> peculiar to me. I can understand the caller would want to do something
> like foo = gpio_get_values(gpio, bitwidth). But would they really want
> to do foo = gpio_get_values(gpio, bitwidth, bitmask) rather than deal
> with it appropriately themselves?
They wouldn't want names so easily confused with the current set
of GPIO calls, no.
But if they're using GPIOs as a low-bandwidth parallel bus they'd
most *certainly* need to be able to read, not just write. That's
what the "I" part of "GPIO" represents: "I"nput (vs "O"utput).
> > Maybe it should suffice to have a gpio_chip support the
> > bitmask ops, instead of just bit-at-a-time ones... so it'd
> > be practical to incorporate this by itself, given patches
> > to convert a couple gpio_chip implementations.
>
> Ok, you've scared me there. I only have a Gumstix board so I can do it
> for the pxa255 but will need help if more platforms are needed.
> Exploiting this opportunity for hardware whoring, if anyone wants to
> send me free hardware, I'll be ecstatic and will eagerly do support
> duty on said platforms. :-)
Doesn't necessarily need to be *you* doing that, but if it only
works on older gumstix boards it'd not be general enough. Which
is part of why I say to get the lowest level proposal out there
first. If done right, it'll be easy to support on other chips.
> >
> > Then separately two more things:
> >
> > - A gpio_* interface proposal for higher-level bitmask calls.
> > This is worth some discussion; the calls should clearly
> > be optional (not everything will implement them), and I
> > can't help but suspect <linux/bitmap.h> interfaces should
> > interoperate smoothly.
... including probably ganged request/free, and direction updates.
When bitbanging a multiplexed parallel databus, you'll often need
to change directions.
> >
> > - A gpiolib based implementation, using those new gpio_chip
> > methods as accelerators if they're present. This should
> > probably also be optional, even at the Kconfig level; many
> > systems won't need to spend memory on these calls.
>
> Understood. I will make it optional. Does
> CONFIG_GPIOLIB_MULTIBIT_ACCESS sound okay?
Kind of verbose for my taste, and it's already "multibit" (one
at a time, but still multiple) ... let's see some more mergeable
proposals and code first. Different C file too, I suspect.
> > Don't assume gpiolib when defining the interface.
>
> Ok, I didn't understand this part. I think you mentioned a higher
> level interface before but I didn't fully understand, if not gpiolib,
> then at what level do you recommend?
The gpio_*() interfaces are how system glue code and drivers
access GPIOs, unless they roll their own chip-specific calls.
Whereas gpiolib (and gpio_chip) are an *optional* framework
for implementing those calls. Platforms can (and do!) use
other frameworks ... maybe they don't want to pay its costs,
and don't need the various GPIO expander drivers.
So to repeat: don't assume the interface is implemented in
one particular way (using gpiolib). It has to make sense
with other implementation strategies too. Standard split
between interface and implementation, that's all. (Some folk
have been heard to talk about "gpiolib" as the interface to
drivers ... it's not, it's a provider-only interface library.)
- Dave
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Jaya Kumar @ 2008-11-29 23:52 UTC (permalink / raw)
To: David Brownell
Cc: Eric Miao, Sam Ravnborg, Eric Miao, Haavard Skinnemoen,
Philipp Zabel, Russell King, Ben Gardner, Greg KH,
linux-arm-kernel, linux-fbdev-devel, linux-kernel, linux-embedded
In-Reply-To: <200811291454.17110.david-b@pacbell.net>
On Sun, Nov 30, 2008 at 6:54 AM, David Brownell <david-b@pacbell.net> wrote:
> If you want to pursue this, I'd like to get the gpio_chip
> proposal in place first: bitmask read and write, without
> forcing an "all bits are contiguous" policy. Lightweight.
Yup, yup, I definitely want to pursue it. I want Linux e-paper
displays to be zippy. :-) Agreed, I will do bitmask read and write.
Hey, wait a sec, bitmask write definitely. but bitmask read is
peculiar to me. I can understand the caller would want to do something
like foo = gpio_get_values(gpio, bitwidth). But would they really want
to do foo = gpio_get_values(gpio, bitwidth, bitmask) rather than deal
with it appropriately themselves?
>
> Maybe it should suffice to have a gpio_chip support the
> bitmask ops, instead of just bit-at-a-time ones... so it'd
> be practical to incorporate this by itself, given patches
> to convert a couple gpio_chip implementations.
Ok, you've scared me there. I only have a Gumstix board so I can do it
for the pxa255 but will need help if more platforms are needed.
Exploiting this opportunity for hardware whoring, if anyone wants to
send me free hardware, I'll be ecstatic and will eagerly do support
duty on said platforms. :-)
>
> Then separately two more things:
>
> - A gpio_* interface proposal for higher-level bitmask calls.
> This is worth some discussion; the calls should clearly
> be optional (not everything will implement them), and I
> can't help but suspect <linux/bitmap.h> interfaces should
> interoperate smoothly.
>
> - A gpiolib based implementation, using those new gpio_chip
> methods as accelerators if they're present. This should
> probably also be optional, even at the Kconfig level; many
> systems won't need to spend memory on these calls.
Understood. I will make it optional. Does
CONFIG_GPIOLIB_MULTIBIT_ACCESS sound okay?
>
> Right now you seem to have smooshed together those three
> things, which probably helped get your sample driver going
> faster but isn't a very good way to move forward. Don't
Yes, my goal with this was to get started and get feedback early. :-)
> assume gpiolib when defining the interface.
Ok, I didn't understand this part. I think you mentioned a higher
level interface before but I didn't fully understand, if not gpiolib,
then at what level do you recommend?
Thanks,
jaya
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Jaya Kumar @ 2008-11-29 23:33 UTC (permalink / raw)
To: David Brownell
Cc: Sam Ravnborg, Eric Miao, Eric Miao, Haavard Skinnemoen,
Philipp Zabel, Russell King, Ben Gardner, Greg KH,
linux-arm-kernel, linux-fbdev-devel, linux-kernel, linux-embedded
In-Reply-To: <200811291448.52483.david-b@pacbell.net>
Jean emailed me saying he didn't want to be CCed.
On Sun, Nov 30, 2008 at 6:48 AM, David Brownell <david-b@pacbell.net> wrote:
> On Thursday 27 November 2008, Sam Ravnborg wrote:
>> > > So my "is it generic enough" question is more at the level of "Are
>> > > there enough Linux systems that need this sort of thing to justify
>> > > generic support?". I happen not to have come across the need for
>> > > such ganged access from Linux (yet). Whereas I've yet to use non-x86
>> > > Linux systems that don't need to manipulate individual GPIO pins...
>> >
>> > I have come across the following scenarios where a bus set of gpio is useful:
>> > - Broadsheet E-Ink controller (uses 16-bit data bus over GPIO)
>> > framebuffer device (this patch is for this)
>> > - Apollo/Hecuba E-Ink controller (uses 8-bit data bus over GPIO)
>> > framebuffer device
>> > - 8-bit parallel IO matrix LCD controllers, such as the Samsung KS108,
>> > also Hitachi, etc
>
> All of those can also be handled with traditional parallel data
> busses too, of course. Are you saying you've seen these used
> with Linux systems? Enough to justify generic support?
Assuming I've understood you correctly about generic support, yes. I
used the 3 above with Linux arm systems that were interfaced to them
via gpio. The matrix displays had just 128x64 so the 8x gpio_set_value
penalty wasn't a biggie. The E-Ink displays range from 800x600 to
1200x826 so the 16x gpio_set_value became a bottleneck. In terms of
generic support, the Broadsheet display controller is also used on
i.MX31 and SC2410/2440 boards so those platform drivers (assuming
those good folks submit them, (i've only written and submitted
am300epd.c)) should also benefit.
Thanks,
jaya
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: David Brownell @ 2008-11-29 22:54 UTC (permalink / raw)
To: Jaya Kumar
Cc: Eric Miao, linux-embedded, Haavard Skinnemoen, Greg KH,
linux-kernel, Ben Gardner, Eric Miao, Philipp Zabel, Jean Delvare,
linux-fbdev-devel, Sam Ravnborg, linux-arm-kernel, Russell King
In-Reply-To: <45a44e480811252151q54580e07xfa73d69596fbfaac@mail.gmail.com>
On Tuesday 25 November 2008, Jaya Kumar wrote:
> In the area of framebuffers for lower end display devices, I find this
> to be quite common.
I'd have said "display modules" myself, although I don't
currently have any Linux systems using them. Some of
those modules use SPI, since it tends support DMA for
downloading the image data ... although admittedly those
are not the very lowest end devices.
> I have also seen this in systems such as 8-bit A2D devices, also with
> various coprocessor solutions where a smaller CPU like a msp430 or
> HC05 would clock data to the host using 8-bit gpio data.
When I hear "coprocessor" I think more like Video DSPs. ;)
And for microcontrollers (msp430, avr8, etc) hooking up,
I've usually seen them use a serial bus (I2C, SPI, etc).
But it's also true that when data transfer rates matter,
it's faster to talk to microcontrollers using a parallel
bus than such a serial bus. The Linux SOC it's talking
to can probably clock SPI an order of magnitude faster
than the microcontroller tolerates. And the reason you
want a dedicated microcontroller is for predictable
(a.k.a. "realtime") monitoring tasks, which they can't
do if they're spending all their time talking to Linux.
Sounds like you're working with a bunch of semicustom
monitoring/control designs?
If you want to pursue this, I'd like to get the gpio_chip
proposal in place first: bitmask read and write, without
forcing an "all bits are contiguous" policy. Lightweight.
Maybe it should suffice to have a gpio_chip support the
bitmask ops, instead of just bit-at-a-time ones... so it'd
be practical to incorporate this by itself, given patches
to convert a couple gpio_chip implementations.
Then separately two more things:
- A gpio_* interface proposal for higher-level bitmask calls.
This is worth some discussion; the calls should clearly
be optional (not everything will implement them), and I
can't help but suspect <linux/bitmap.h> interfaces should
interoperate smoothly.
- A gpiolib based implementation, using those new gpio_chip
methods as accelerators if they're present. This should
probably also be optional, even at the Kconfig level; many
systems won't need to spend memory on these calls.
Right now you seem to have smooshed together those three
things, which probably helped get your sample driver going
faster but isn't a very good way to move forward. Don't
assume gpiolib when defining the interface.
- Dave
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: David Brownell @ 2008-11-29 22:48 UTC (permalink / raw)
To: Sam Ravnborg, Jaya Kumar
Cc: Eric Miao, Jean Delvare, Eric Miao, Haavard Skinnemoen,
Philipp Zabel, Russell King, Ben Gardner, Greg KH,
linux-arm-kernel, linux-fbdev-devel, linux-kernel, linux-embedded
In-Reply-To: <20081127200102.GB20443@uranus.ravnborg.org>
On Thursday 27 November 2008, Sam Ravnborg wrote:
> > > So my "is it generic enough" question is more at the level of "Are
> > > there enough Linux systems that need this sort of thing to justify
> > > generic support?". I happen not to have come across the need for
> > > such ganged access from Linux (yet). Whereas I've yet to use non-x86
> > > Linux systems that don't need to manipulate individual GPIO pins...
> >
> > I have come across the following scenarios where a bus set of gpio is useful:
> > - Broadsheet E-Ink controller (uses 16-bit data bus over GPIO)
> > framebuffer device (this patch is for this)
> > - Apollo/Hecuba E-Ink controller (uses 8-bit data bus over GPIO)
> > framebuffer device
> > - 8-bit parallel IO matrix LCD controllers, such as the Samsung KS108,
> > also Hitachi, etc
All of those can also be handled with traditional parallel data
busses too, of course. Are you saying you've seen these used
with Linux systems? Enough to justify generic support?
I've certainly seen how some of those LCD controllers, graphical
or character based, work with microcontrollers. They're very
widely available too ... so I can imagine various uClinux systems
have one hooked up. Most of the Linux system hookups I've happened
across use USB or serial links (e.g. the crystalfontz.com stuff)
since modern PCs are severely GPIO-deprived.
Another example where ganged access might help is keypad matrices.
> We have such a system at work. And we need fast acces to the gpio pins
> when updating the LCD.
> I have not written/looked to deep at the code I just recall it was
> a bit messy and not something I would be proud of submitting to any ML.
Often times such messiness is more because the code never got
cleaned up, because it's kind of a one-off to support particular
boards.
You could say that the gpiolib implementation framework got its
start, in part, as a way to unclutter some kernel trees that
had way too much one-off stuff like that. ;)
- Dave
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Sam Ravnborg @ 2008-11-28 5:47 UTC (permalink / raw)
To: Jaya Kumar
Cc: David Brownell, Eric Miao, Eric Miao, Haavard Skinnemoen,
Philipp Zabel, Russell King, Ben Gardner, Greg KH,
linux-arm-kernel, linux-fbdev-devel, linux-kernel, linux-embedded
In-Reply-To: <45a44e480811271543t1e564201k71e7697aa472618d@mail.gmail.com>
On Fri, Nov 28, 2008 at 07:43:31AM +0800, Jaya Kumar wrote:
> On Fri, Nov 28, 2008 at 4:01 AM, Sam Ravnborg <sam@ravnborg.org> wrote:
> > On Wed, Nov 26, 2008 at 12:51:27AM -0500, Jaya Kumar wrote:
> >> On Tue, Nov 25, 2008 at 11:15 PM, David Brownell <david-b@pacbell.net> wrote:
> >> > On Tuesday 25 November 2008, Eric Miao wrote:
> >> >> Using a bit mask will be more generic if the GPIOs are not contiguous.
> >> >> Yet I still doubt this will be generic enough to be added to gpiolib.
> >> >
> >> > My expectation for this kind of mechanism was that systems who need
> >> > to craft another parallel bus out of GPIO pins would be doing this
> >> > with some system-specific utility functions.
> >> >
> >> > So my "is it generic enough" question is more at the level of "Are
> >> > there enough Linux systems that need this sort of thing to justify
> >> > generic support?". I happen not to have come across the need for
> >> > such ganged access from Linux (yet). Whereas I've yet to use non-x86
> >> > Linux systems that don't need to manipulate individual GPIO pins...
> >>
> >> I have come across the following scenarios where a bus set of gpio is useful:
> >> - Broadsheet E-Ink controller (uses 16-bit data bus over GPIO)
> >> framebuffer device (this patch is for this)
> >> - Apollo/Hecuba E-Ink controller (uses 8-bit data bus over GPIO)
> >> framebuffer device
> >> - 8-bit parallel IO matrix LCD controllers, such as the Samsung KS108,
> >> also Hitachi, etc
> >
> > We have such a system at work. And we need fast acces to the gpio pins
> > when updating the LCD.
> > I have not written/looked to deep at the code I just recall it was
> > a bit messy and not something I would be proud of submitting to any ML.
> >
> > Sam
> >
>
> Okay. Please help me understand in case I misunderstood. Are you
> saying the code that I posted is too messy? To me, actually I am proud
> of it. :-) But if some parts look messy, I'm happy to work on
> improving it. I will need some advice though and please advise me on
> which parts look messy.
Nope - the code we use at work is too messy. What you posted looks
much better.
Sam
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Jaya Kumar @ 2008-11-27 23:43 UTC (permalink / raw)
To: Sam Ravnborg
Cc: David Brownell, Eric Miao, Eric Miao, Haavard Skinnemoen,
Philipp Zabel, Russell King, Ben Gardner, Greg KH,
linux-arm-kernel, linux-fbdev-devel, linux-kernel, linux-embedded
In-Reply-To: <20081127200102.GB20443@uranus.ravnborg.org>
On Fri, Nov 28, 2008 at 4:01 AM, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Wed, Nov 26, 2008 at 12:51:27AM -0500, Jaya Kumar wrote:
>> On Tue, Nov 25, 2008 at 11:15 PM, David Brownell <david-b@pacbell.net> wrote:
>> > On Tuesday 25 November 2008, Eric Miao wrote:
>> >> Using a bit mask will be more generic if the GPIOs are not contiguous.
>> >> Yet I still doubt this will be generic enough to be added to gpiolib.
>> >
>> > My expectation for this kind of mechanism was that systems who need
>> > to craft another parallel bus out of GPIO pins would be doing this
>> > with some system-specific utility functions.
>> >
>> > So my "is it generic enough" question is more at the level of "Are
>> > there enough Linux systems that need this sort of thing to justify
>> > generic support?". I happen not to have come across the need for
>> > such ganged access from Linux (yet). Whereas I've yet to use non-x86
>> > Linux systems that don't need to manipulate individual GPIO pins...
>>
>> I have come across the following scenarios where a bus set of gpio is useful:
>> - Broadsheet E-Ink controller (uses 16-bit data bus over GPIO)
>> framebuffer device (this patch is for this)
>> - Apollo/Hecuba E-Ink controller (uses 8-bit data bus over GPIO)
>> framebuffer device
>> - 8-bit parallel IO matrix LCD controllers, such as the Samsung KS108,
>> also Hitachi, etc
>
> We have such a system at work. And we need fast acces to the gpio pins
> when updating the LCD.
> I have not written/looked to deep at the code I just recall it was
> a bit messy and not something I would be proud of submitting to any ML.
>
> Sam
>
Okay. Please help me understand in case I misunderstood. Are you
saying the code that I posted is too messy? To me, actually I am proud
of it. :-) But if some parts look messy, I'm happy to work on
improving it. I will need some advice though and please advise me on
which parts look messy.
Thanks,
jaya
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Sam Ravnborg @ 2008-11-27 20:01 UTC (permalink / raw)
To: Jaya Kumar
Cc: David Brownell, Eric Miao, Jean Delvare, Eric Miao,
Haavard Skinnemoen, Philipp Zabel, Russell King, Ben Gardner,
Greg KH, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <45a44e480811252151q54580e07xfa73d69596fbfaac@mail.gmail.com>
On Wed, Nov 26, 2008 at 12:51:27AM -0500, Jaya Kumar wrote:
> On Tue, Nov 25, 2008 at 11:15 PM, David Brownell <david-b@pacbell.net> wrote:
> > On Tuesday 25 November 2008, Eric Miao wrote:
> >> Using a bit mask will be more generic if the GPIOs are not contiguous.
> >> Yet I still doubt this will be generic enough to be added to gpiolib.
> >
> > My expectation for this kind of mechanism was that systems who need
> > to craft another parallel bus out of GPIO pins would be doing this
> > with some system-specific utility functions.
> >
> > So my "is it generic enough" question is more at the level of "Are
> > there enough Linux systems that need this sort of thing to justify
> > generic support?". I happen not to have come across the need for
> > such ganged access from Linux (yet). Whereas I've yet to use non-x86
> > Linux systems that don't need to manipulate individual GPIO pins...
>
> I have come across the following scenarios where a bus set of gpio is useful:
> - Broadsheet E-Ink controller (uses 16-bit data bus over GPIO)
> framebuffer device (this patch is for this)
> - Apollo/Hecuba E-Ink controller (uses 8-bit data bus over GPIO)
> framebuffer device
> - 8-bit parallel IO matrix LCD controllers, such as the Samsung KS108,
> also Hitachi, etc
We have such a system at work. And we need fast acces to the gpio pins
when updating the LCD.
I have not written/looked to deep at the code I just recall it was
a bit messy and not something I would be proud of submitting to any ML.
Sam
^ permalink raw reply
* Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
From: Matt Sealey @ 2008-11-26 20:57 UTC (permalink / raw)
To: David Brownell
Cc: dvomlehn, Grant Erickson, Bill Gatliff, linuxppc-dev,
Stefan Roese, Wolfgang Denx, linux-embedded
In-Reply-To: <200811251345.11350.david-b@pacbell.net>
On Tue, Nov 25, 2008 at 3:45 PM, David Brownell <david-b@pacbell.net> wrote:
> No comment from me on $SUBJECT beyond "it seems plausible", but ...
>
> On Tuesday 25 November 2008, David VomLehn wrote:
>> The important point, though, is that device tree is the only
>> thing approaching a standard on any non-x86-based platform for passing
>> structured information from the bootloader to the kernel. The command
>> line is just not sufficient for this.
>
> Me, I'll be happier if I don't have to try using that device tree.
> Having board-specific code in the kernel is a more complete solution,
> and makes it a lot easier to cope with all the hardware goofage.
I disagree.
> Recall that the *original* notion behind OpenBoot (now "OpenFirmware")
> was to have tables for the stuff that was table-friendly, and call
> out to FORTH code (possibly not just at boot time) for the rest.
> (Given the choice of FORTH vs ACPI bytecodes, I'd go for FORTH; but
> the better option is "neither".)
The problem really is that Linux never really cared to run Forth code or even
keep the client interface for OF and 99% of the devices with real device
trees and real client interfaces, have really bad hardware support or methods
implemented that just don't work - not to mention the evil that happens on the
difference between Linux ABI and the OF ABI, the client interface context
switch, real-mode or virtual-mode firmwares.
The most useful thing is the representation of the devices in the device-tree.
I do however agree that sometimes FAR too much is being put into the
device trees,
the massive amount of overly verbose information about devices which do not need
the information there is just redundant. Reading processor registers out of the
device tree (such as the system version register on SoCs) is totally dumb, but
this was suggested at one time.
Once you match the driver with a compatible property, you're set; you know which
driver you're on. You can read out quirks and make inferences from
other parts of
the tree (this is something that most drivers do NOT do since people
think reading
outside the node just matched is some evil) where these are truly board-level
problems.
For instance where the ATA DMA lines are not connected on a 5200B board, this
must be described. Of course whether you decide this from the root
"model" property
and make a guess (all boards of fsl,broken5200 might have the bug) or
specifically
say in /soc/ata that "dma-is-broken" is the big question. In this
event, Grant came
up with a more fun solution which is to specify the maximum modes in
the device tree
therefore not bringing ANY board specific properties into it and
making sure you do not
clutter the driver with board specifics! This is exactly how device
trees should be designed.
Properties such as "fsl5200-clocking" in i2c nodes, is NOT. The
compatible property
of the node has fsl,mpc5200b-i2c, this implies 5200 clocking for the
i2c bus anyway. I
really don't get why this property even exists. It's not like there is
some alternative way
on the chip.. :D
> Right now I see an awful lot of work going into trying to force lots
> of stuff into table format. Even when it's the sort of one-off or
> board-specific quirkery that was an original motivation for having
> FORTH escapes (tasks that were not table-friendly).
What about drivers where there is no binding for OF or Forth and never was and
never would/will be? There is no Forth escape for that.
Forth - and the client interface - should be used where necessary to
bring the system
up. This be modifying the device tree, implementing methods to boot
(it makes some
sense that if the ATA methods in the client interface work, then Linux
could load it's
own initrd without the help of Yaboot or GRUB, for example, right in
the boot wrapper,
and to the location it sees best to load it, and not what Yaboot
decides for it, and there
would be no need to maintain 4 different filesystem codes in 3
alternative loaders and
the kernel).
But unfortunately most systems have crap CIF support (ours included)
which do not
come up to the task.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Jaya Kumar @ 2008-11-26 5:51 UTC (permalink / raw)
To: David Brownell
Cc: Eric Miao, Sam Ravnborg, Jean Delvare, Eric Miao,
Haavard Skinnemoen, Philipp Zabel, Russell King, Ben Gardner,
Greg KH, linux-arm-kernel, linux-fbdev-devel, linux-kernel,
linux-embedded
In-Reply-To: <200811252015.57870.david-b@pacbell.net>
On Tue, Nov 25, 2008 at 11:15 PM, David Brownell <david-b@pacbell.net> wrote:
> On Tuesday 25 November 2008, Eric Miao wrote:
>> Using a bit mask will be more generic if the GPIOs are not contiguous.
>> Yet I still doubt this will be generic enough to be added to gpiolib.
>
> My expectation for this kind of mechanism was that systems who need
> to craft another parallel bus out of GPIO pins would be doing this
> with some system-specific utility functions.
>
> So my "is it generic enough" question is more at the level of "Are
> there enough Linux systems that need this sort of thing to justify
> generic support?". I happen not to have come across the need for
> such ganged access from Linux (yet). Whereas I've yet to use non-x86
> Linux systems that don't need to manipulate individual GPIO pins...
I have come across the following scenarios where a bus set of gpio is useful:
- Broadsheet E-Ink controller (uses 16-bit data bus over GPIO)
framebuffer device (this patch is for this)
- Apollo/Hecuba E-Ink controller (uses 8-bit data bus over GPIO)
framebuffer device
- 8-bit parallel IO matrix LCD controllers, such as the Samsung KS108,
also Hitachi, etc
In the area of framebuffers for lower end display devices, I find this
to be quite common.
I have also seen this in systems such as 8-bit A2D devices, also with
various coprocessor solutions where a smaller CPU like a msp430 or
HC05 would clock data to the host using 8-bit gpio data.
>
>
>> The user of this gpio_set_value_bus() may assume too much about
>> the internal, e.g. how many GPIOs on the chip and whether these GPIOs
>> are contiguous or not, and whether this GPIO chip support bitwise
>> operations.
>
> Actually I would expect that to be addressed by the hardware designer.
I agree that the gpio's are always contiguous. It would be very
unusual (I've never seen it yet) where a hardware designer picked
non-consecutive pins to be used for a bus. In the case of AM300, the
board designer picked the xscale's 58 - 73 gpio pins.
>
> As in, if you're bitbanging a 16-bit parallel bus (plus several
> control signals -- chip select lines, address latch, r/w, etc) the
> board would be designed for efficient bitbanging, by taking care
> that the software bus ops aren't stupidly complex. So I guess I'm
> agreeing with Eric there: wanting this kind of stuff at all seems
> to imply being fairly low-down'n'dirty.
Yes, agreed, handling the contiguous bus case turned out to be quite
straightforward and the core is just about 30 lines of code.
+ do {
+ chip = gpio_to_chip(gpio + i);
+ WARN_ON(extra_checks && chip->can_sleep);
+
+ if (!chip->set_bus) {
+ while (((gpio + i) < (chip->base + chip->ngpio))
+ && bitwidth) {
+ value = values & (1 << i);
+ chip->set(chip, gpio + i - chip->base, value);
+ i++;
+ bitwidth--;
+ }
+ } else {
+ value = values >> i; /* shift off the used stuff */
+ remwidth = ((chip->base + (int) chip->ngpio) -
+ ((int) gpio + i));
+ width = min(bitwidth, remwidth);
+
+ chip->set_bus(chip, gpio + i - chip->base, value,
+ width);
+ i += width;
+ bitwidth -= width;
+ }
+ } while (bitwidth);
>
>
> Example, assuming a 32 bit GPIO bank, the data lines would probably
> be all adjacent and politely ordered by the board designer so that
A typical board designer will ensure that the selected pins are
consecutive. But I think given today's rapid development time, I'd be
hard pressed to ensure that they're also register consecutive. In the
case of AM300, the designer picked a pin sequence that spans 2 32-bit
registers since it starts at 58 and ends at 73. So it spans the 32-63
and 64-95 registers. The code handles that case fine.
>
> /* write a 16 bit value on the specfied data lines,
> * assuming the intermediate state doesn't matter...
> */
> writew(0xffff << N, &bank->clear_bits);
> writew(value << N, &bank->set_bits);
>
> instead of needing to compute some complex permutation of those
> bits ... and similarly
>
> /* read a 16 bit value from the specified data lines */
> value = 0xffff & (readw(&bank->read_bits) >> N);
>
> possibly after handshaking with the device on the other side
> about changing signal direction, again without permutation.
>
> But heck, maybe there just aren't that many adjacent GPIOs free,
> because of alternate functions that are used... ugh.
>
>
> Note also that this proposal only includes
>
>> > + void (*set_bus)(struct gpio_chip *chip,
>> > + unsigned offset, int values,
>> > + int bitwidth);
>
> not its sibling read operation.
>
Yes, I figured I'd start with the most basic approach. Also, the
costliest operation in am300epd is the the actual framebuffer transfer
to the device which is just a lot of writes. If people want me to do
it, I can also implement get_bus.
>
>> Let's have a concrete example: what if the user gives a bunch of GPIOs
>> that crosses the chip boundary, say, GPIO29 - GPIO35 (with each chip
>> covering 32 GPIOs).
>
> I'd care more about the upper level operation being performed ... like the
> control protocol for passing the address of a word being read or written
> and then switching the bus from address to data read (or write) mode to
> get the word, then yielding the bus access.
The upper level protocol in this case is from broadsheetfb (also
posted). Here's the relevant code:
+static void broadsheet_issue_data(struct broadsheetfb_par *par, u16 data)
+{
+ par->board->set_ctl(par, BS_WR, 0);
+ par->board->set_hdb(par, data);
+ par->board->set_ctl(par, BS_WR, 1);
+}
...
which is called to transfer the fb via:
+static void broadsheet_burst_write(struct broadsheetfb_par *par, int size,
+ u16 *data)
+{
...
+ for (i = 0; i < size; i++) {
...
+ par->board->set_hdb(par, tmp);
Thanks,
jaya
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: David Brownell @ 2008-11-26 4:15 UTC (permalink / raw)
To: Eric Miao, Jaya Kumar
Cc: Sam Ravnborg, Jean Delvare, Eric Miao, Haavard Skinnemoen,
Philipp Zabel, Russell King, Ben Gardner, Greg KH,
linux-arm-kernel, linux-fbdev-devel, linux-kernel, linux-embedded
In-Reply-To: <f17812d70811251720u47bec50dt3734f5b2bb0d339@mail.gmail.com>
On Tuesday 25 November 2008, Eric Miao wrote:
> Using a bit mask will be more generic if the GPIOs are not contiguous.
> Yet I still doubt this will be generic enough to be added to gpiolib.
My expectation for this kind of mechanism was that systems who need
to craft another parallel bus out of GPIO pins would be doing this
with some system-specific utility functions.
So my "is it generic enough" question is more at the level of "Are
there enough Linux systems that need this sort of thing to justify
generic support?". I happen not to have come across the need for
such ganged access from Linux (yet). Whereas I've yet to use non-x86
Linux systems that don't need to manipulate individual GPIO pins...
> The user of this gpio_set_value_bus() may assume too much about
> the internal, e.g. how many GPIOs on the chip and whether these GPIOs
> are contiguous or not, and whether this GPIO chip support bitwise
> operations.
Actually I would expect that to be addressed by the hardware designer.
As in, if you're bitbanging a 16-bit parallel bus (plus several
control signals -- chip select lines, address latch, r/w, etc) the
board would be designed for efficient bitbanging, by taking care
that the software bus ops aren't stupidly complex. So I guess I'm
agreeing with Eric there: wanting this kind of stuff at all seems
to imply being fairly low-down'n'dirty.
Example, assuming a 32 bit GPIO bank, the data lines would probably
be all adjacent and politely ordered by the board designer so that
/* write a 16 bit value on the specfied data lines,
* assuming the intermediate state doesn't matter...
*/
writew(0xffff << N, &bank->clear_bits);
writew(value << N, &bank->set_bits);
instead of needing to compute some complex permutation of those
bits ... and similarly
/* read a 16 bit value from the specified data lines */
value = 0xffff & (readw(&bank->read_bits) >> N);
possibly after handshaking with the device on the other side
about changing signal direction, again without permutation.
But heck, maybe there just aren't that many adjacent GPIOs free,
because of alternate functions that are used... ugh.
Note also that this proposal only includes
> > + void (*set_bus)(struct gpio_chip *chip,
> > + unsigned offset, int values,
> > + int bitwidth);
not its sibling read operation.
> Let's have a concrete example: what if the user gives a bunch of GPIOs
> that crosses the chip boundary, say, GPIO29 - GPIO35 (with each chip
> covering 32 GPIOs).
I'd care more about the upper level operation being performed ... like the
control protocol for passing the address of a word being read or written
and then switching the bus from address to data read (or write) mode to
get the word, then yielding the bus access.
- Dave
^ permalink raw reply
* Fwd: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: David Brownell @ 2008-11-26 3:23 UTC (permalink / raw)
To: linux-embedded; +Cc: Jaya Kumar
This forward tool drops the CC list ... it was everyone listed
on the patch itself as a CC.
---------- Forwarded Message ----------
Subject: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
Date: Tuesday 25 November 2008
From: Jaya Kumar <jayakumar.lkml@gmail.com>
To: jayakumar.lkml@gmail.com
Beloved friends,
I would like to request your feedback on the following idea. I hope I have
made sure to CC all the right people and the right lists! If not, PLEASE
let me know! I couldn't find a MAINTAINERS entry for gpiolib so I just
used what I saw in the git log and have also added people and lists that
I think may be interested.
This is just an RFC. If you all feel it is looking like the right approach
then I'll clean it up and make it a patch.
Thanks,
jaya
am300epd was doing 800*600*16*gpio_set_value for each framebuffer transfer
(it uses 16-pins of gpio as its data bus). I found this caused a wee
performance limitation. This patch adds an API for gpio_set_value_bus
which allows users to set batches of consecutive gpio together in a single
call. I have done a test implementation on gumstix (pxa255) with am300epd
and it provides a nice improvement in performance.
Signed-off-by: Jaya Kumar <jayakumar.lkml@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: David Brownell <david-b@pacbell.net>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Eric Miao <eric.miao@marvell.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Philipp Zabel <philipp.zabel@gmail.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ben Gardner <bgardner@wabtec.com>
CC: Greg KH <greg@kroah.com>
Cc: linux-arm-kernel@lists.arm.linux.org.uk
Cc: linux-fbdev-devel@lists.sourceforge.net
Cc: linux-kernel@vger.kernel.org
---
arch/arm/mach-pxa/am300epd.c | 9 ++++++
arch/arm/mach-pxa/gpio.c | 28 +++++++++++++++++++++
arch/arm/mach-pxa/include/mach/gpio.h | 24 ++++++++++++++++++
drivers/gpio/gpiolib.c | 44 +++++++++++++++++++++++++++++++++
include/asm-generic/gpio.h | 6 ++++
5 files changed, 111 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-pxa/am300epd.c b/arch/arm/mach-pxa/am300epd.c
index bb81564..f741a98 100644
--- a/arch/arm/mach-pxa/am300epd.c
+++ b/arch/arm/mach-pxa/am300epd.c
@@ -222,8 +222,17 @@ static void am300_set_hdb(struct broadsheetfb_par *par, u16 data)
{
int i;
+#if 1
+ gpio_set_value_bus(DB0_GPIO_PIN, data, 16);
+#endif
+#if 0
+ gpio_set_value_bus(DB0_GPIO_PIN, data, 6);
+ gpio_set_value_bus(DB0_GPIO_PIN + 6, data >> 6, 10);
+#endif
+#if 0 /* simple set */
for (i = 0; i <= (DB15_GPIO_PIN - DB0_GPIO_PIN) ; i++)
gpio_set_value(DB0_GPIO_PIN + i, (data >> i) & 0x01);
+#endif
}
diff --git a/arch/arm/mach-pxa/gpio.c b/arch/arm/mach-pxa/gpio.c
index 14930cf..80b0aa1 100644
--- a/arch/arm/mach-pxa/gpio.c
+++ b/arch/arm/mach-pxa/gpio.c
@@ -132,6 +132,33 @@ static void pxa_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
__raw_writel(mask, pxa->regbase + GPCR_OFFSET);
}
+/*
+ * Set output GPIO level in batches
+ */
+static void pxa_gpio_set_bus(struct gpio_chip *chip, unsigned offset,
+ int values, int bitwidth)
+{
+ struct pxa_gpio_chip *pxa;
+ int mask;
+
+ /* we're guaranteed by the caller that offset + bitwidth remains
+ * in this chip.
+ */
+ pxa = container_of(chip, struct pxa_gpio_chip, chip);
+
+ mask = ((1 << bitwidth) - 1) << offset;
+ values <<= offset;
+
+ values &= mask;
+ if (values)
+ __raw_writel(values, pxa->regbase + GPSR_OFFSET);
+
+ values = ~values;
+ values &= mask;
+ if (values)
+ __raw_writel(values, pxa->regbase + GPCR_OFFSET);
+}
+
#define GPIO_CHIP(_n) \
[_n] = { \
.regbase = GPIO##_n##_BASE, \
@@ -141,6 +168,7 @@ static void pxa_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
.direction_output = pxa_gpio_direction_output, \
.get = pxa_gpio_get, \
.set = pxa_gpio_set, \
+ .set_bus = pxa_gpio_set_bus, \
.base = (_n) * 32, \
.ngpio = 32, \
}, \
diff --git a/arch/arm/mach-pxa/include/mach/gpio.h b/arch/arm/mach-pxa/include/mach/gpio.h
index 2c538d8..6ee92d3 100644
--- a/arch/arm/mach-pxa/include/mach/gpio.h
+++ b/arch/arm/mach-pxa/include/mach/gpio.h
@@ -56,6 +56,30 @@ static inline void gpio_set_value(unsigned gpio, int value)
}
}
+static inline void gpio_set_value_bus(unsigned gpio, int values, int bitwidth)
+{
+ if (__builtin_constant_p(gpio) &&
+ (gpio + bitwidth < NR_BUILTIN_GPIO) &&
+ ((gpio + bitwidth) <= roundup(gpio+1, 32))) {
+ int shift, mask;
+
+ shift = gpio % 32;
+ mask = ((1 << bitwidth) - 1) << shift;
+ values <<= shift;
+
+ values &= mask;
+ if (values)
+ GPSR(gpio) = values;
+
+ values = ~values;
+ values &= mask;
+ if (values)
+ GPCR(gpio) = values;
+ } else {
+ __gpio_set_value_bus(gpio, values, bitwidth);
+ }
+}
+
#define gpio_cansleep __gpio_cansleep
#define gpio_to_irq(gpio) IRQ_GPIO(gpio)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 9112830..fddf3af 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1057,6 +1057,50 @@ void __gpio_set_value(unsigned gpio, int value)
EXPORT_SYMBOL_GPL(__gpio_set_value);
/**
+ * __gpio_set_value_bus() - assign a batch of consecutive gpio pins together
+ * @gpio: starting gpio pin
+ * @values: values to assign, sequential in host ordering
+ * @bitwidth: total width of bits to be assigned
+ * Context: any
+ *
+ * This is used directly or indirectly to implement gpio_set_value().
+ * It invokes the associated gpio_chip.set() method.
+ */
+void __gpio_set_value_bus(unsigned gpio, int values, int bitwidth)
+{
+ struct gpio_chip *chip;
+ int i = 0;
+ int value, width, remwidth;
+
+ do {
+ chip = gpio_to_chip(gpio + i);
+ WARN_ON(extra_checks && chip->can_sleep);
+
+ if (!chip->set_bus) {
+ while (((gpio + i) < (chip->base + chip->ngpio))
+ && bitwidth) {
+ value = values & (1 << i);
+ chip->set(chip, gpio + i - chip->base, value);
+ i++;
+ bitwidth--;
+ }
+ } else {
+ value = values >> i; /* shift off the used stuff */
+ remwidth = ((chip->base + (int) chip->ngpio) -
+ ((int) gpio + i));
+ width = min(bitwidth, remwidth);
+
+ chip->set_bus(chip, gpio + i - chip->base, value,
+ width);
+ i += width;
+ bitwidth -= width;
+ }
+ } while (bitwidth);
+}
+EXPORT_SYMBOL_GPL(__gpio_set_value_bus);
+
+
+/**
* __gpio_cansleep() - report whether gpio value access will sleep
* @gpio: gpio in question
* Context: any
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 81797ec..9747517 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -44,6 +44,8 @@ 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_bus: batch assigns output values for consecutive signals starting at
+ * "offset" with width in bits "bitwidth"
* @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,6 +86,9 @@ struct gpio_chip {
unsigned offset, int value);
void (*set)(struct gpio_chip *chip,
unsigned offset, int value);
+ void (*set_bus)(struct gpio_chip *chip,
+ unsigned offset, int values,
+ int bitwidth);
int (*to_irq)(struct gpio_chip *chip,
unsigned offset);
@@ -124,6 +129,7 @@ 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);
+extern void __gpio_set_value_bus(unsigned gpio, int values, int bitwidth);
extern int __gpio_cansleep(unsigned gpio);
--
1.5.2.3
-------------------------------------------------------
^ permalink raw reply related
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