Re: Debian kernel v2.6.38

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Michael,

On Sun, Apr 24, 2011 at 00:12, Michael Schmitz
<schmitzmic@xxxxxxxxxxxxxx> wrote:
On Sat, Apr 23, 2011 at 20:13, Thorsten Glaser <tg@xxxxxxxxx> wrote:
â Reserve ST RAM early

Yeah, that's a valid one,
My (and probably lkml's) main issue there is that it introduces yet
another custom
allocator. Can we avoid that?

Ideally it would not be an issue if we could properly flag ST-RAM only as
DMA memory. I've tried in the past but setting the max. DMA address to the
0x00ffffff did have unintended side effects elsewhere in the m68k mm code.

If there is a generic lowmem allocator, we might be able to use that
instead. It does not need to be available early on, but we need to be able
to reserve some lowmem early.

Reserving the pool using alloc_bootmem_low() is fine.
But the allocator for memory inside the pool could be changed to use e.g.
allocate_resource(), cfr. arch/m68k/amiga/chipram.c.
If I'm not mistaken, the main difference between Chip RAM on Amiga and ST-RAM
on Atari is that ST-RAM can be used as system memory, while Chip RAM cannot
(due to the lack of RMW bus support)?

Another possible hack would be to allocate lowmem early on for each
compiled-in user and store that in a platform device struct for use by the
driver once it initializes. Is there such a thing like early initcalls for
this specific purpose (do a minimum early setup such as allocate resources,
silence IRQs and the like)?.

That's a bit like we do on the ps3, cfr. arch/powerpc/platforms/ps3/setup.c.
The main disadvantage is that it's less flexible, esp. for modules.

If all that is not an option (and for the sake of modules needing ST-RAM), I
don't see another way to do it. Some parts of the hardware just need memory
below 0x00ffffff.

If you would just reserve 1 MiB (or a better tuned amount) of ST-RAM pool and
always use allocate_resource() to allocate ST-RAM, most of stram.c (e.g.
manageing the list of free blocks) can go?
As a bonus, you get freeing of memory from the pool.

I had a quick look into the ST-RAM users:
  - ataflop, atari_scsi, and atafb allocate ST-RAM only at driver
initialization,
  - dmasound_atari allocates/deallocates ST-RAM on sq_open()/close(),
so this will
    definitely break after a while if the ST-RAM pool doesn't support
freeing ST-RAM.

What do you think?

Gr{oetje,eeting}s,

            Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
             Â Â -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux