[PATCH 00/14] archosg9: add support for tablet

[vj]

On Wed, Oct 10, 2012 at 11:32 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> On Wed, Oct 10, 2012 at 10:57:12AM +0200, vj wrote:
>> On Wed, Oct 10, 2012 at 9:40 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
>> > On Tue, Oct 09, 2012 at 12:55:10AM +0200, Vicente wrote:
>> >> This patch series is the same as before except for:
>> >>  [PATCH 03/13] ARM: ensure irqs are disabled
>> >>     imported irq handling from linux
>> >>  [PATCH 07/13] uimage: improve transfer speed
>> >>     solved a compile warning
>> >
>> > I applied most of this series, please check the result in the -next
>> > branch.
>> >
>>
>> I'll check this week
>
> Thanks.

The -next branch works "out-of-the-box".
So exiting from barebox leaving the interrupts enabled is not critical.

>
>> > Of course haven't applied this one
>> >
>>
>> It wasn't meant to be applied
>
> I know, just thought I'd mention it anyway
>
>>
>> >>   omap4: add usb boot source
>> >>   bootm: close open files
>> >
>> >>   uimage: improve transfer speed
>> >
>> > Haven't applied this one as you haven't answered my question how
>> > much improvement (and on which media) we get.
>>
>> Yes, it's answered, see:
>> http://lists.infradead.org/pipermail/barebox/2012-October/010208.html
>
> Ups, missed that. That's really a huge speed gain. I wonder why this
> happens. Maybe the overhead of request/release sdram region is
> significant with MMU disabled. Could you play with the BUFSIZ parameter
> to see if there's a good compromise between speeding up your transfer
> and still sensible buffer sizes?

Here are the results:
13133*PAGE_SIZE: Transferred 53789775 bytes in 3.326 seconds at 15.419 MBps
   64*PAGE_SIZE: Transferred 53789775 bytes in 3.478 seconds at 14.748 MBps
   32*PAGE_SIZE: Transferred 53789775 bytes in 3.655 seconds at 14.031 MBps
   16*PAGE_SIZE: Transferred 53789775 bytes in 3.987 seconds at 12.865 MBps
    8*PAGE_SIZE: Transferred 53789775 bytes in 4.540 seconds at 11.297 MBps
    4*PAGE_SIZE: Transferred 53789775 bytes in 5.876 seconds at  8.729 MBps
    2*PAGE_SIZE: Transferred 53789775 bytes in 8.249 seconds at  6.218 MBps
Note: 13133 is reading the file at once.

>
> BTW I wonder if it would be possible to use the MMU in your setup. We
> have a 1:1 flat mapping which should be no problem for the ROM code.
> You probably would have to use dma_alloc_coherent to allocate the
> buffers which are used for USB transfers.

Tested with MMU enabled having the buffers on local stack: fail
with buffers allocated with xzalloc: fail
with dma_alloc_coherent: fail
all of them freezes when calling the ROM function
omap4_usbboot_pdata.io->write(...)
also tried this initcalls, all with same result:
core_initcall(omap4_usbboot_init);
postmmu_initcall(omap4_usbboot_init);

Why it doesn't work? I don't know. But if anybody wants to investigate attached
is the ROM code which is placed at offset 0x00030000. The entry points used by
barebox are:
omap4_usbboot_pdata.io->init  : 0x000340e3
omap4_usbboot_pdata.io->read  : 0x00034289
omap4_usbboot_pdata.io->write : 0x00034259
omap4_usbboot_pdata.io->close : 0x00034075
omap4_usbboot_pdata.io->config: 0x000342bb
which surely are wrong because aren't dword aligned! I'm lost.

>
> Sascha
>
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rom.bin.gz
Type: application/x-gzip
Size: 22953 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/barebox/attachments/20121012/1aea2d37/attachment-0001.gz>