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

Re: [PATCH v3 0/4] Atari kernel-in-FastRAM patches v3



Hi Michael,

On Wed, May 28, 2014 at 2:18 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
> When deciding whether a ST-RAM DMA buffer needs to be allocated, the
> Atari SCSI driver checks whether there's more than a single chunk of
> RAM (there's always ST-RAM, so the second one indicates FastRAM).
> That's no longer a good test now with the kernel capable of running
> from FastRAM (and the ST-RAM chunk being dropped in MM init).
>
> Maybe we need another variable to hold the number of memory chunks
> before adjustment. Or look at size or physical base address of the
> first chunk...

That's why DMA masks have been invented. The one in atari_scsi.c seems
to have the bits inverted, compared to all other places in the kernel.

But indeed, that doesn't help for the initial check:

        if (MACH_IS_ATARI && ATARIHW_PRESENT(ST_SCSI) &&
            !ATARIHW_PRESENT(EXTD_DMA) && m68k_num_memory > 1) {
                atari_dma_buffer = atari_stram_alloc(STRAM_BUFFER_SIZE, "SCSI");
                if (!atari_dma_buffer) {
                        printk(KERN_ERR "atari_scsi_detect: can't
allocate ST-RAM "
                                        "double buffer\n");
                        return 0;
                }
                atari_dma_phys_buffer = virt_to_phys(atari_dma_buffer);
                atari_dma_orig_addr = 0;
        }

You can loop over m68k_memory[], and check if any chunk lies outside
the first 16 MiB?

If everything fails, you can allocate it unconditionally (it's just
one 4 KiB page).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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


Reply to: