Hi Michael,
On Sun, Apr 24, 2011 at 00:12, Michael Schmitz
<schmitz...@googlemail.com> wrote:
>> On Sat, Apr 23, 2011 at 20:13, Thorsten Glaser <t...@mirbsd.de> 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 -- ge...@linux-m68k.org
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
