* Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
From: Grant Erickson @ 2009-01-07 2:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Stefan Roese, Wolfgang Denx, linux-embedded
In-Reply-To: <1231286642.14860.35.camel@pasglop>
On 1/6/09 4:04 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2008-11-25 at 10:34 -0800, Grant Erickson wrote:
>> This merges support for the previously DENX-only kernel feature of
>> specifying an alternative, "external" buffer for kernel printk
>> messages and their associated metadata. In addition, this ports
>> architecture support for this feature from arch/ppc to arch/powerpc.
>>
>> Signed-off-by: Grant Erickson <gerickson@nuovations.com>
>
> Considering the extensive changes to generic code, this patch will
> have to be submitted via the linux-kernel mailing list.
>
> I suggest you split the generic core change from the powerpc specific
> implementation.
>
> I'm not sure whether I like the idea myself or not there, so you'll have
> to convince the powers that be to take it.
Ben:
Thanks for the feedback. Matt Sealey had some good feedback
<http://ozlabs.org/pipermail/linuxppc-dev/2008-November/065594.html> which I
have on my to-do list to evaluate.
In the interim, I'll hold off on pushing up to linux-kernel until I've done
that.
Regards,
Grant
^ permalink raw reply
* Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
From: Grant Erickson @ 2009-01-07 2:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Stefan Roese, Wolfgang Denx, linux-embedded
In-Reply-To: <1231286642.14860.35.camel@pasglop>
On 1/6/09 4:04 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2008-11-25 at 10:34 -0800, Grant Erickson wrote:
>> This merges support for the previously DENX-only kernel feature of
>> specifying an alternative, "external" buffer for kernel printk
>> messages and their associated metadata. In addition, this ports
>> architecture support for this feature from arch/ppc to arch/powerpc.
>>
>> Signed-off-by: Grant Erickson <gerickson@nuovations.com>
>
> Considering the extensive changes to generic code, this patch will
> have to be submitted via the linux-kernel mailing list.
>
> I suggest you split the generic core change from the powerpc specific
> implementation.
>
> I'm not sure whether I like the idea myself or not there, so you'll have
> to convince the powers that be to take it.
Ben:
Thanks for the feedback. Matt Sealey had some good feedback
<http://ozlabs.org/pipermail/linuxppc-dev/2008-November/065594.html> which I
have on my to-do list to evaluate.
In the interim, I'll hold off on pushing up to linux-kernel until I've done
that.
Regards,
Grant
^ permalink raw reply
* Re: [PATCH V3 10/17] Squashfs: cache operations
From: Geert Uytterhoeven @ 2009-01-07 16:17 UTC (permalink / raw)
To: Phillip Lougher
Cc: akpm, linux-embedded, linux-fsdevel, linux-kernel, tim.bird, sfr
In-Reply-To: <E1LJnJn-0002Lm-Va@dylan.lougher.demon.co.uk>
On Mon, 5 Jan 2009, Phillip Lougher wrote:
> diff --git a/fs/squashfs/cache.c b/fs/squashfs/cache.c
> new file mode 100644
> index 0000000..f29eda1
> --- /dev/null
> +++ b/fs/squashfs/cache.c
> +/*
> + * Copy upto length bytes from cache entry to buffer starting at offset bytes
> + * into the cache entry. If there's not length bytes then copy the number of
> + * bytes available. In all cases return the number of bytes copied.
> + */
> +int squashfs_copy_data(void *buffer, struct squashfs_cache_entry *entry,
^
const?
It also makes it clear from the prototype in which direction is copied.
> + int offset, int length)
^^^ ^^^
> +{
> + int remaining = length;
^^^
Shouldn't all of these be unsigned int?
> +
> + if (length == 0)
> + return 0;
> + else if (buffer == NULL)
> + return min(length, entry->length - offset);
> +
> + while (offset < entry->length) {
> + void *buff = entry->data[offset / PAGE_CACHE_SIZE]
> + + (offset % PAGE_CACHE_SIZE);
> + int bytes = min_t(int, entry->length - offset,
> + PAGE_CACHE_SIZE - (offset % PAGE_CACHE_SIZE));
> +
> + if (bytes >= remaining) {
> + memcpy(buffer, buff, remaining);
> + remaining = 0;
> + break;
> + }
> +
> + memcpy(buffer, buff, bytes);
> + buffer += bytes;
> + remaining -= bytes;
> + offset += bytes;
> + }
> +
> + return length - remaining;
> +}
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH V3 01/17] Squashfs: inode operations
From: Geert Uytterhoeven @ 2009-01-07 18:00 UTC (permalink / raw)
To: Phillip Lougher
Cc: Andrew Morton, linux-embedded, linux-fsdevel,
Linux Kernel Development, Tim Bird, sfr, Linux/PPC Development
In-Reply-To: <E1LJnJn-0002L2-GZ@dylan.lougher.demon.co.uk>
On Mon, 5 Jan 2009, Phillip Lougher wrote:
> diff --git a/fs/squashfs/inode.c b/fs/squashfs/inode.c
> new file mode 100644
> index 0000000..7a63398
> --- /dev/null
> +++ b/fs/squashfs/inode.c
> @@ -0,0 +1,346 @@
> +int squashfs_read_inode(struct inode *inode, long long ino)
> +{
> + struct super_block *sb = inode->i_sb;
> + struct squashfs_sb_info *msblk = sb->s_fs_info;
> + u64 block = SQUASHFS_INODE_BLK(ino) + msblk->inode_table;
^^^
> + TRACE("File inode %x:%x, start_block %llx, block_list_start "
^^^^
> + "%llx, offset %x\n", SQUASHFS_INODE_BLK(ino),
^^^^
> + offset, squashfs_i(inode)->start, block, offset);
Note that I get lots of
| warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'u64'
on ppc64, since you switched from `unsigned long long' to 'u64', as `u64' is
(still -- this is being changed) `unsigned long' on pp64.
I guess no action has to be taken, for now?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH V3 01/17] Squashfs: inode operations
From: Stephen Rothwell @ 2009-01-07 21:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Phillip Lougher, Andrew Morton, linux-embedded, linux-fsdevel,
Linux Kernel Development, Tim Bird, Linux/PPC Development
In-Reply-To: <Pine.LNX.4.64.0901071854210.32034@vixen.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
Hi Geert,
On Wed, 7 Jan 2009 19:00:24 +0100 (CET) Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
>
> Note that I get lots of
>
> | warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'u64'
>
> on ppc64, since you switched from `unsigned long long' to 'u64', as `u64' is
> (still -- this is being changed) `unsigned long' on pp64.
>
> I guess no action has to be taken, for now?
Correct, as we are in the process of changing u64 to unsigned long long for
powerpc.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: klaasjan gm @ 2009-01-08 13:13 UTC (permalink / raw)
To: Rob Landley
Cc: Sam Ravnborg, Embedded Linux mailing list, Paul Mundt,
Andrew Morton, H. Peter Anvin
In-Reply-To: <200901031348.46847.rob@landley.net>
Rob and to whom it may concern,
> I didn't discover this topic independently. Somebody pinged me about it on
> freenode back in February, and several other people sent me private email
> about it, and it's been previously raised on several other mailing lists (such
> as busybox and uclibc ones).
>
> Unfortunately, most of the embedded developers I know aren't subscribed to
> linux-kernel.
FWIW,
> Hopefully the cc: to linux-embedded is helping get more embedded guys involved
> in the discussion than just me. :)
Having some experience with cross-compiling the kernel, and some of the basic
toolsets:
I'm with you on this one (and testing the waters at linux-embedded
while I'm at it)
Regards,
Klaasjan
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mike Frysinger @ 2009-01-08 13:29 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Paul Mundt, Rob Landley, H. Peter Anvin,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <c384c5ea0901040223l6e53f041s9f7cdea20c9d1d8d@mail.gmail.com>
On Sun, Jan 4, 2009 at 05:23, Leon Woestenberg wrote:
> On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt <lethal@linux-sh.org> wrote:
>> Let's look at the rationale presented so far in this thread:
>>
>> 2 - Cross-compiling perl is hard.
>
> 2 is not hard.
i dont know where you're getting this mythical version of perl, but
anything beyond micro-perl is a pita. and micro-perl is practically
worthless. maybe for kernel/
-mike
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Christian Gagneraud @ 2009-01-08 15:04 UTC (permalink / raw)
To: klaasjan gm
Cc: Rob Landley, Sam Ravnborg, Embedded Linux mailing list,
Paul Mundt, Andrew Morton, H. Peter Anvin
In-Reply-To: <33cac1200901080513k4df78751uc752c38e71486164@mail.gmail.com>
klaasjan gm wrote:
> Rob and to whom it may concern,
>
>> I didn't discover this topic independently. Somebody pinged me about it on
>> freenode back in February, and several other people sent me private email
>> about it, and it's been previously raised on several other mailing lists (such
>> as busybox and uclibc ones).
>>
>> Unfortunately, most of the embedded developers I know aren't subscribed to
>> linux-kernel.
>
> FWIW,
>
>> Hopefully the cc: to linux-embedded is helping get more embedded guys involved
>> in the discussion than just me. :)
>
> Having some experience with cross-compiling the kernel, and some of the basic
> toolsets:
> I'm with you on this one (and testing the waters at linux-embedded
> while I'm at it)
+1
Chris
>
> Regards,
> Klaasjan
> --
> 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: FPGA programming driver architecture
From: Hugo Villeneuve @ 2009-01-08 20:18 UTC (permalink / raw)
To: Florian Fainelli; +Cc: linux-kernel, linux-embedded
In-Reply-To: <200812131358.03010.florian@openwrt.org>
On Sat, 13 Dec 2008 13:58:01 +0100
Florian Fainelli <florian@openwrt.org> wrote:
> (CC'ing linux-embedded)
>
> Salut Hugo,
>
> Le Friday 12 December 2008 21:03:14 Hugo Villeneuve, vous avez écrit :
> > Hi,
> > I have written some code to program a FPGA in Linux, for two
> > different types of boards: one uses a serial interface (SPI) and
> > the second a parallel interface. I have been able to sucessfully
> > program both boards. I'm now trying to clean my code and make it
> > more generic, as well as better in line with the Linux driver
> > model. I would also like to include it in the mainline kernel if
> > there is interest.
> ...
> What about something like that :
>
> - fpgaload-core which contains all the code that can be shared
> between the drivers like requesting firmware, providing sysfs
> attributes,
> - fpgaload-spi would handle the low-level SPI connection
> - fpgaload-par would handle the low-level parallel connection
>
> fpgaload-ser and par would register with fpgaload-core and they could
> register a fpga loading callback which is low-level specific for
> instance. Platform code would instantiate the core driver. That way,
> adding support for other loading protocols like slave serial or
> master serial can be done easily.
Yes, but how I actually implement fpgaload_core, fpgaload_ser and
fpgaload_par?
Bus driver?
class driver?
platform driver?
I am not sure how I should implement things and how each low-level
specific driver should register with the fpgaload_core driver...
Hugo V.
---------------
Hugo Villeneuve
www.hugovil.com
---------------
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Thiago Galesi @ 2009-01-08 22:14 UTC (permalink / raw)
To: Hugo Villeneuve; +Cc: Florian Fainelli, linux-kernel, linux-embedded
In-Reply-To: <20090108151827.72f50cee.hugo@hugovil.com>
> > > Hi,
> > > I have written some code to program a FPGA in Linux, for two
> > > different types of boards: one uses a serial interface (SPI) and
> > > the second a parallel interface. I have been able to sucessfully
> > > program both boards. I'm now trying to clean my code and make it
> > > more generic, as well as better in line with the Linux driver
> > > model.
Considering the several FPGA models available and ways to program it,
I guess the important thing to consider is what can be made generic.
(that is what will become fpgaload)
Also, there may be cases where after FPGA is programmed it "becomes a
device" (PCI or whatever)
> >
> > - fpgaload-core which contains all the code that can be shared
> > between the drivers like requesting firmware, providing sysfs
> > attributes,
> > - fpgaload-spi would handle the low-level SPI connection
> > - fpgaload-par would handle the low-level parallel connection
I think this maybe split into three layers (maybe)
1 - low level connection: paralell / spi / i2c / whatever
2 - vendor: xylinx, altera, etc
3 - generic stuff
Take a look at the MTD and SPI drivers and how they split things
--
-
Thiago Galesi
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Leon Woestenberg @ 2009-01-08 22:47 UTC (permalink / raw)
To: Thiago Galesi
Cc: Hugo Villeneuve, Florian Fainelli, linux-kernel, linux-embedded
In-Reply-To: <82ecf08e0901081414u15af3c2dy9c88a242db024dc7@mail.gmail.com>
Hello,
On Thu, Jan 8, 2009 at 11:14 PM, Thiago Galesi <thiagogalesi@gmail.com> wrote:
>> > > Hi,
>> > > I have written some code to program a FPGA in Linux, for two
>> > > different types of boards: one uses a serial interface (SPI) and
>> > > the second a parallel interface. I have been able to sucessfully
>> > > program both boards. I'm now trying to clean my code and make it
>> > > more generic, as well as better in line with the Linux driver
>> > > model.
>
> Considering the several FPGA models available and ways to program it,
> I guess the important thing to consider is what can be made generic.
Indeed.
The programming back end should be generic enough so that it can use
other subsystems.
The FPGA configuration interface could be on the memory bus (and in
many cases the DMA helpers can be used) or behind a PCI bus, or can
even have SPI etc front-ends.
In general the programming API should accept a blob of data,
preferably in one chunk (pointer plus length) or at least 4kB chunks
or so, so that configuration is not severy overheaded by a callback
per byte (or even bit).
Regards,
--
Leon
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Florian Fainelli @ 2009-01-08 22:57 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Thiago Galesi, Hugo Villeneuve, linux-kernel, linux-embedded
In-Reply-To: <c384c5ea0901081447i5ad807b3yb0ec3adebeaa46a0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
Hello,
Le Thursday 08 January 2009 23:47:58 Leon Woestenberg, vous avez écrit :
> Indeed.
>
> The programming back end should be generic enough so that it can use
> other subsystems.
>
> The FPGA configuration interface could be on the memory bus (and in
> many cases the DMA helpers can be used) or behind a PCI bus, or can
> even have SPI etc front-ends.
>
> In general the programming API should accept a blob of data,
> preferably in one chunk (pointer plus length) or at least 4kB chunks
> or so, so that configuration is not severy overheaded by a callback
> per byte (or even bit).
That's the idea behind using request_firmware, which provides you with both a
pointer to the data and the size of the blob.
--
Best regards, Florian Fainelli
Email : florian@openwrt.org
http://openwrt.org
-------------------------------
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Leon Woestenberg @ 2009-01-08 23:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: Thiago Galesi, Hugo Villeneuve, linux-kernel, linux-embedded
In-Reply-To: <200901082357.24432.florian@openwrt.org>
Hello,
On Thu, Jan 8, 2009 at 11:57 PM, Florian Fainelli <florian@openwrt.org> wrote:
> Le Thursday 08 January 2009 23:47:58 Leon Woestenberg, vous avez écrit :
>> The programming back end should be generic enough so that it can use
>> other subsystems.
>>
> That's the idea behind using request_firmware, which provides you with both a
> pointer to the data and the size of the blob.
I know, that's what I would call the front-end (near userspace).
I meant the low-level back-end (towards hardware):
> - fpgaload-core which contains all the code that can be shared
> between the drivers like requesting firmware, providing sysfs
> attributes,
> - fpgaload-spi would handle the low-level SPI connection
> - fpgaload-par would handle the low-level parallel connection
>
> fpgaload-ser and par would register with fpgaload-core and they could
> register a fpga loading callback which is low-level specific for
> instance.
My $0.02 was:
Those callbacks should also be able to accept chunks of data
(preferably in the same way using ptr/len).
Regards,
--
Leon
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Duane Ellis @ 2009-01-09 3:14 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Florian Fainelli, Thiago Galesi, Hugo Villeneuve, linux-kernel,
linux-embedded
In-Reply-To: <c384c5ea0901081507v5d186eai5ec71d56b4c7a972@mail.gmail.com>
>> [various FPGA config methods]
Don't forget JTAG, and playing back an SVF files, or BIT files.
-Duane.
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Alexander Clouter @ 2009-01-09 12:24 UTC (permalink / raw)
To: linux-embedded; +Cc: linux-kernel
In-Reply-To: <4966C125.10604@duaneellis.com>
Duane Ellis <duane@duaneellis.com> wrote:
> >> [various FPGA config methods]
>
> Don't forget JTAG, and playing back an SVF files, or BIT files.
>
On the board we have, the FPGA is programmable over JTAG which is
conveniently strapped to the GPIO pins of the CPU.
http://www.embeddedarm.com/products/board-detail.php?product=TS-7800
Cheers
Alex
--
Alexander Clouter
.sigmonster says: This screen intentionally left blank.
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Hugo Villeneuve @ 2009-01-09 15:07 UTC (permalink / raw)
To: Thiago Galesi; +Cc: Florian Fainelli, linux-kernel, linux-embedded
In-Reply-To: <82ecf08e0901081414u15af3c2dy9c88a242db024dc7@mail.gmail.com>
On Thu, 8 Jan 2009 20:14:36 -0200
"Thiago Galesi" <thiagogalesi@gmail.com> wrote:
> > > > Hi,
> > > > I have written some code to program a FPGA in Linux, for two
> > > > different types of boards: one uses a serial interface (SPI) and
> > > > the second a parallel interface. I have been able to sucessfully
> > > > program both boards. I'm now trying to clean my code and make it
> > > > more generic, as well as better in line with the Linux driver
> > > > model.
>
> Considering the several FPGA models available and ways to program it,
> I guess the important thing to consider is what can be made generic.
> (that is what will become fpgaload)
I have a pretty good idea of what goes into the core and
what goes into the specific interface modules (spi, parallel, etc).
> Also, there may be cases where after FPGA is programmed it "becomes a
> device" (PCI or whatever)
This is exactly the case for my board, but it doesn´t change anything
to the programming side of things, apart for the fact that the FPGA
must be configured before using any in-FPGA PCI bus for example.
> > > - fpgaload-core which contains all the code that can be shared
> > > between the drivers like requesting firmware, providing sysfs
> > > attributes,
> > > - fpgaload-spi would handle the low-level SPI connection
> > > - fpgaload-par would handle the low-level parallel connection
>
> I think this maybe split into three layers (maybe)
>
> 1 - low level connection: paralell / spi / i2c / whatever
> 2 - vendor: xylinx, altera, etc
> 3 - generic stuff
>
> Take a look at the MTD and SPI drivers and how they split things
I think that for the moment, I will focus on implementing the core
module and the parallel/SPI interfaces only. Later we may want to add
more fonctionality (vendors, JTAG, etc).
But for now, my main problem is that I need to have some insight on how
I actually implement the different modules:
Bus driver?
class driver?
platform driver?
Can anybody give some advice on that?
Thank-you, Hugo.
---------------
Hugo Villeneuve
www.hugovil.com
---------------
^ permalink raw reply
* Re: FPGA programming driver architecture
From: Hans J. Koch @ 2009-01-09 23:40 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Thiago Galesi, Florian Fainelli, linux-kernel, linux-embedded
In-Reply-To: <20090109100725.77a07e74.hugo@hugovil.com>
On Fri, Jan 09, 2009 at 10:07:25AM -0500, Hugo Villeneuve wrote:
>
> I think that for the moment, I will focus on implementing the core
> module and the parallel/SPI interfaces only. Later we may want to add
> more fonctionality (vendors, JTAG, etc).
That's a good plan, but you'll have to make sure different FPGA programming
drivers can be added easily to some fpga-core no matter which interface they
use.
>
> But for now, my main problem is that I need to have some insight on how
> I actually implement the different modules:
>
> Bus driver?
> class driver?
> platform driver?
Those are not mutually exclusive. If you register an spi driver, it'll appear
on that bus. It would be a good idea to also create a class "fpga". And an
FPGA will likely be a platform device unless you create a complete subsystem
that offers something like register_fpga_device(). The latter would be a nice
thing to have, I had to write FPGA programming drivers and had to implement
them as some char device in drivers/misc because there was no place where
they could go...
IMHO, the ideal solution would be to have an FPGA programming subsystem.
Somewhere in my board support I'd setup some struct fpga_device that
contains an element "bus_type" which can be set to FPGA_BUS_PARALLEL or
FPGA_BUS_SPI or whatever. A "name" element declares which driver I'd like
to use for my chip. A call to some fpga_register_device() with a
pointer to that struct would make the fpga subsystem remember that device and
look for an apropriate driver. Drivers register themselves by a call to some
register_fpga_driver() function. The fpga core would then make sure the
drivers probe function is called with pointers to the struct fpga_device of
the registered devices. That's how other subsystems work.
Such a subsystem would solve any FPGA programming problems (and your "main
problem" mentioned above) once and for all.
Thanks,
Hans
^ permalink raw reply
* Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins
From: Jaya Kumar @ 2009-01-10 7:37 UTC (permalink / raw)
To: Robin Getz
Cc: David Brownell, 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: <200901061741.12410.rgetz@blackfin.uclinux.org>
On Wed, Jan 7, 2009 at 6:41 AM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> On Wed 31 Dec 2008 13:05, Jaya Kumar pondered:
>> On Thu, Jan 1, 2009 at 1:38 AM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
>> > On Tue 30 Dec 2008 23:58, Jaya Kumar pondered:
>> >> On Tue, Dec 30, 2008 at 11:55 PM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
>> >> > Yeah, I hadn't thought about spanning more than one gpio_chip. That's a good
>> >> > point.
>> >>
>> >> The currently posted code already supports spanning more than one gpio_chip.
>> >>
>> >
>> > But doesn't do all the other things that David suggested/requested.
>>
>> Hi Robin,
>>
>> Yes, you are right. My implementation does not support a driver that
>> needs to set/get more than 32-bits of gpio in a single call. I'm okay
>> with that restriction as I don't see a concrete use case for that.
>
> It's not the more than 32-bits that I'm concerned about - it is spanning
> more than one register. (if all the GPIOs that are left on the board are
> 2, 64, and 128, where 2, and 64 are part of the SOC's GPIO, and 128 is on
> a GPIO expander - which is a common use case - is this handled?)
>
Hi Robin,
You are correct in that the 2, 64, 128 case would not be accelarated
by my current implementation. The reason is that those 3 numbers can't
fit into a 32 bit bitmask (the mask is for consecutive bits). The user
would need to use the pre-existing single bit API for that scenario,
ie: gpio_set_value(2, val); (64, val), (128, val);
In my current patch, I'm trying to address the performance issue seen
by am300epd.c because of the use of gpio as a 16-bit data bus to
transfer framebuffer data using the current single bit gpio API. I
want to make my implementation more generic than just that which is
why I've added the bitmask and support up to 32-bits. I want to expand
on that to the extent that that can be done without diluting the
performance and without losing the simplicity of the current gpiolib
API.
After reading your points, I think I understand that you would prefer
a higher level API. I am thinking along the lines of:
array_of_gpio_numbers[] = [ 2 , 64, 128 ];
cookie = gpio_register_bundle(array_of_gpio_numbers, sizeof(array));
error = gpio_set_bundle(cookie, values[]);
error = gpio_get_bundle(cookie, values[]);
gpio_unregister_bundle(cookie);
I think that's elegant and I agree that it is feasible but it is a
level higher than what I'm trying to achieve. Would you agree with me
that the above API could be implemented on top of the lower level API
that I have proposed? To be specific, I imagine something along the
lines of:
int gpio_set_bundle(int cookie, u32 *values)
{
offsets = retrieve_offsets_from_cookie(cookie);
err = generate_chips_from_offsets(offsets, &chips);
err = merge_consecutive_chips(chips, &merged_chips)
foreach chip (merged_chips) {
values = generate_values(chip, offset);
mask = generate_mask(chip, offset);
masklength = calculate_length(mask);
gpio_set_batch(chip, offset, values, mask, masklength);
}
}
forgive the naming, I'm just hurrying to illustrate what I mean.
So my goal is to get the lower level batch API working and solid. It
would solve the am300epd.c problem and put into place a framework for
others[1]. Once we've gotten to that level of support, I believe we
could start implementing the higher level API that you've described on
top of that. Does this sound like a reasonable plan that would address
your concerns?
Thanks,
jaya
[1] The same underlying display controller that I seek to support,
broadsheet, will be used across more than just am300epd.c's pxa255. I
know with certainty that it has been used on iMX31L. Several other
SoCs including the S3C6410 are likely. So if we've got this lower
level batch API done, I hope to see it commonly implemented across
those other SoCs too in order to ensure all of those use cases are
accelerated. I am happy to work on that, especially if I can get
hardware. :-)
ps: I noticed you said the above 2, 64, 128 is a common use case. I
don't dispute that, but is that a case where acceleration is
essential? It would also help if I could look through an example of
this use case in the tree or elsewhere so that I can improve my
understanding.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Bernd Petrovitsch @ 2009-01-11 12:45 UTC (permalink / raw)
To: Leon Woestenberg
Cc: Paul Mundt, Rob Landley, H. Peter Anvin,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <c384c5ea0901040223l6e53f041s9f7cdea20c9d1d8d@mail.gmail.com>
On Son, 2009-01-04 at 11:23 +0100, Leon Woestenberg wrote:
[...]
> On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt <lethal@linux-sh.org> wrote:
[...]
I'm ignoring the "cross-compile perl" issue - haven't tried it for
years.
> 5. Tool *version* dependency is hard to get right. When cross-building
> 30 software packages all requiring native perl, we probably need to
> build a few versions of perl (native), one for each set of packages.
perl is IMHO special (and quite different to others - including
especially autotools): perl5 is used widely enough so that "one somewhat
recent version" should cover all of 30 software packages.
The hard part are the CPAN modules and their versions which are really a
PITA.
As long as you don't use modules from CPAN, "perl5" should be specific
enough.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mark A. Miller @ 2009-01-12 3:36 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Leon Woestenberg, Paul Mundt, Rob Landley, H. Peter Anvin,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <1231677939.3517.5.camel@gimli.at.home>
On Sun, Jan 11, 2009 at 6:45 AM, Bernd Petrovitsch <bernd@firmix.at> wrote:
>
> On Son, 2009-01-04 at 11:23 +0100, Leon Woestenberg wrote:
> [...]
> > On Sun, Jan 4, 2009 at 4:06 AM, Paul Mundt <lethal@linux-sh.org> wrote:
> [...]
>
> I'm ignoring the "cross-compile perl" issue - haven't tried it for
> years.
>
> > 5. Tool *version* dependency is hard to get right. When cross-building
> > 30 software packages all requiring native perl, we probably need to
> > build a few versions of perl (native), one for each set of packages.
>
> perl is IMHO special (and quite different to others - including
> especially autotools): perl5 is used widely enough so that "one somewhat
> recent version" should cover all of 30 software packages.
> The hard part are the CPAN modules and their versions which are really a
> PITA.
> As long as you don't use modules from CPAN, "perl5" should be specific
> enough.
>
> Bernd
> --
> Firmix Software GmbH http://www.firmix.at/
> mobil: +43 664 4416156 fax: +43 1 7890849-55
> Embedded Linux Development and Services
Actually, something that has amused me during this discussion, is that
right now, the latest stable Perl (5.8.8) does not compile correctly
on a uclibc host, which is typically what you want for embedded
systems, which is why you'd bother to cross compile. (Albeit I was
doing this natively under QEMU with a gcc/uclibc toolchain).
I'll have a patch submitted upstream shortly, but basically the
hints/linux.sh assumes *obviously* you're linking to glibc. I've made
that less libc dependent, looking for either glibc or uclibc.
So without patching Perl, by adding it to the kernel configuration,
it's broken being able to compile the kernel on most embedded
architectures.
And for H. Peter Anvin, before you refer to such uses as compiling the
kernel under a native environment as a "piece of art", please be aware
that the mainstream embedded development environment, buildroot, is
also attempting to utilize QEMU for a "sanity check" on the
environment.
There are several other packages which are broken for embedded
architectures, which I will hopefully attempt to fix by submitting
patches upstream. But this is why we should be cautious about
including new tools for compiling the kernel. Sam Ravnborg was correct
in that a C program to do the work would be the proper way. But by not
addressing a currently existing problem with an adequate replacement
with something that does not exist currently, seems faulty.
--
Mark A. Miller
mark@mirell.org
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: H. Peter Anvin @ 2009-01-12 5:11 UTC (permalink / raw)
To: Mark A. Miller
Cc: Bernd Petrovitsch, Leon Woestenberg, Paul Mundt, Rob Landley,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <31014a580901111936q41486efagcb90af2b6880a470@mail.gmail.com>
Mark A. Miller wrote:
>
> Actually, something that has amused me during this discussion, is that
> right now, the latest stable Perl (5.8.8) does not compile correctly
> on a uclibc host...
>
The latest stable Perl is 5.10.0, and the latest of the 5.8 series is 5.8.9.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mark A. Miller @ 2009-01-12 5:23 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Bernd Petrovitsch, Leon Woestenberg, Paul Mundt, Rob Landley,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <496AD0E9.2020909@zytor.com>
On Sun, Jan 11, 2009 at 11:11 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> Mark A. Miller wrote:
>>
>> Actually, something that has amused me during this discussion, is that
>> right now, the latest stable Perl (5.8.8) does not compile correctly
>> on a uclibc host...
>>
>
> The latest stable Perl is 5.10.0, and the latest of the 5.8 series is 5.8.9.
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
My mistake. However,
http://perl5.git.perl.org/perl.git/blob_plain/HEAD:/hints/linux.sh
still has the issue, specifically:
if test -L /lib/libc.so.6; then
libc=`ls -l /lib/libc.so.6 | awk '{print $NF}'`
libc=/lib/$libc
fi
So, my version was incorrect, yet the problem still exists. I've got a
patch, need to submit it, yet Perl *does not compile* on a uclibc
target *as is*.
And this is why we should avoid adding new tools to build the kernel,
because they introduce yet more break points, as such.
Thanks.
--
Mark A. Miller
mark@mirell.org
"My greatest strength, I guess it would be my humility. My greatest
weakness, it's possible that I'm a little too awesome" - Barack Obama
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Sam Ravnborg @ 2009-01-12 5:35 UTC (permalink / raw)
To: Mark A. Miller
Cc: Bernd Petrovitsch, Leon Woestenberg, Paul Mundt, Rob Landley,
H. Peter Anvin, Embedded Linux mailing list, linux-kernel,
Andrew Morton
In-Reply-To: <31014a580901111928u586e2246uccf370ff941c8a01@mail.gmail.com>
> There are several other packages which are broken for embedded
> architectures, which I will hopefully attempt to fix by submitting patches
> upstream. But this is why we should be cautious about including new tools
> for compiling the kernel. Sam Ravnborg was correct in that a C program to do
> the work would be the proper way. But by not addressing a currently existing
> problem with an adequate replacement with something that does not exist
> currently, seems faulty.
Why are "make headers_install" such a crucial thing for your
embedded environmnet?
I would assume that if this of such improtance then there is also
someone to step up and contribute a C version of it.
Sam
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Mark A. Miller @ 2009-01-12 5:50 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Bernd Petrovitsch, Leon Woestenberg, Paul Mundt, Rob Landley,
H. Peter Anvin, Embedded Linux mailing list, linux-kernel,
Andrew Morton
In-Reply-To: <20090112053552.GA9061@uranus.ravnborg.org>
On Sun, Jan 11, 2009 at 11:35 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
>> There are several other packages which are broken for embedded
>> architectures, which I will hopefully attempt to fix by submitting patches
>> upstream. But this is why we should be cautious about including new tools
>> for compiling the kernel. Sam Ravnborg was correct in that a C program to do
>> the work would be the proper way. But by not addressing a currently existing
>> problem with an adequate replacement with something that does not exist
>> currently, seems faulty.
>
> Why are "make headers_install" such a crucial thing for your
> embedded environmnet?
Sanity check. If the environment cannot replicate itself, then
something has been faulty in the cross-compiling stage, that was used
to propagate a native environment for the target architecture.
> I would assume that if this of such improtance then there is also
> someone to step up and contribute a C version of it.
You've already dismissed a shell version to correct the issue, in
hopes of a "possible" C version. It would be nice, I'm not capable of
doing it personally, but a solution already exists to "unbreak" the
kernel build. If you're unwilling to merge the current patches, then
feel free to claim that this doesn't break anything on current
architectures, but it's incorrect, due to Perl not even compiling as
is currently on a native uclibc environment.
I look forward to what other tools will be introduced to break yet
more architectures until the kernel cannot be compiled unless on an
i686+glibc architecture.
> Sam
--
Mark A. Miller
mark@mirell.org
^ permalink raw reply
* Re: PATCH [0/3]: Simplify the kernel build by removing perl.
From: Paul Mundt @ 2009-01-12 8:20 UTC (permalink / raw)
To: Mark A. Miller
Cc: Bernd Petrovitsch, Leon Woestenberg, Rob Landley, H. Peter Anvin,
Embedded Linux mailing list, linux-kernel, Andrew Morton,
Sam Ravnborg
In-Reply-To: <31014a580901111936q41486efagcb90af2b6880a470@mail.gmail.com>
On Sun, Jan 11, 2009 at 09:36:58PM -0600, Mark A. Miller wrote:
> Actually, something that has amused me during this discussion, is that
> right now, the latest stable Perl (5.8.8) does not compile correctly
> on a uclibc host, which is typically what you want for embedded
> systems, which is why you'd bother to cross compile. (Albeit I was
> doing this natively under QEMU with a gcc/uclibc toolchain).
>
> I'll have a patch submitted upstream shortly, but basically the
> hints/linux.sh assumes *obviously* you're linking to glibc. I've made
> that less libc dependent, looking for either glibc or uclibc.
>
There are plenty that ship with glibc, too. What you "want" for embedded
systems depends entirely on the application for the device, not general
hand-wavy assertions. We (Renesas) ship BSPs on both precisely because of
this reason, and eglibc will probably factor in at some point later on
too.
> So without patching Perl, by adding it to the kernel configuration,
> it's broken being able to compile the kernel on most embedded
> architectures.
>
This again has nothing to do with the kernel and everything to do with
your distribution. I use perl on uclibc natively just fine, it is
possible there are patches that have not been merged upstream, but this
is again an entirely separate issue.
You seem to be confusing the fact that people who build distributions and
people who use them are one and the same, whereas "most" embedded
developers are going to be using pre-built distributions provided with
their reference hardware, and locking it down during productization. The
fact you are doing a distribution aimed at embedded devices is nice, but
do not try to push off problems you run in to that have a reasonable
expectation of working everywhere else on to the kernel community as
something we ought to care about.
If you need to use a different libc on your platform, yes, you will have
to update packages for this. This used to be true for gcc and other
packages as well, but those were all fixed over time. The fact perl still
stands out despite there being patches available is simply an indicator
that folks working in that area haven't been very proactive in getting
their changes merged upstream. Tough.
This is now entirely off-topic and has nothing to do with the kernel any
more. Please take this to the uclibc or perl lists instead.
^ 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