lkml.org 
[lkml]   [2022]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS
    Hi Michael,

    On Tue, Jun 28, 2022 at 5:26 AM Michael Schmitz <schmitzmic@gmail.com> wrote:
    > Am 28.06.2022 um 09:12 schrieb Michael Schmitz:
    > > On 27/06/22 20:26, Geert Uytterhoeven wrote:
    > >> On Sat, Jun 18, 2022 at 3:06 AM Michael Schmitz <schmitzmic@gmail.com>
    > >> wrote:
    > >>> Am 18.06.2022 um 00:57 schrieb Arnd Bergmann:
    > >>>> From: Arnd Bergmann <arnd@arndb.de>
    > >>>>
    > >>>> All architecture-independent users of virt_to_bus() and bus_to_virt()
    > >>>> have been fixed to use the dma mapping interfaces or have been
    > >>>> removed now. This means the definitions on most architectures, and the
    > >>>> CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed.
    > >>>>
    > >>>> The only exceptions to this are a few network and scsi drivers for m68k
    > >>>> Amiga and VME machines and ppc32 Macintosh. These drivers work
    > >>>> correctly
    > >>>> with the old interfaces and are probably not worth changing.
    > >>> The Amiga SCSI drivers are all old WD33C93 ones, and replacing
    > >>> virt_to_bus by virt_to_phys in the dma_setup() function there would
    > >>> cause no functional change at all.
    > >> FTR, the sgiwd93 driver use dma_map_single().
    > >
    > > Thanks! From what I see, it doesn't have to deal with bounce buffers
    > > though?
    >
    > Leaving the bounce buffer handling in place, and taking a few other
    > liberties - this is what converting the easiest case (a3000 SCSI) might
    > look like. Any obvious mistakes? The mvme147 driver would be very
    > similar to handle (after conversion to a platform device).

    Thanks, looks reasonable.

    > The driver allocates bounce buffers using kmalloc if it hits an
    > unaligned data buffer - can such buffers still even happen these days?

    No idea.

    > If I understand dma_map_single() correctly, the resulting dma handle
    > would be equally misaligned?
    >
    > To allocate a bounce buffer, would it be OK to use dma_alloc_coherent()
    > even though AFAIU memory used for DMA buffers generally isn't consistent
    > on m68k?
    >
    > Thinking ahead to the other two Amiga drivers - I wonder whether
    > allocating a static bounce buffer or a DMA pool at driver init is likely
    > to succeed if the kernel runs from the low 16 MB RAM chunk? It certainly
    > won't succeed if the kernel runs from a higher memory address, so the
    > present bounce buffer logic around amiga_chip_alloc() might still need
    > to be used here.
    >
    > Leaves the question whether converting the gvp11 and a2091 drivers is
    > actually worth it, if bounce buffers still have to be handled explicitly.

    A2091 should be straight-forward, as A3000 is basically A2091 on the
    motherboard (comparing the two drivers, looks like someone's been
    sprinkling mb()s over the A3000 driver).

    I don't have any of these SCSI host adapters (not counting the A590
    (~A2091) expansion of the old A500, which is not Linux-capable, and
    hasn't been powered on for 20 years).

    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

    \
     
     \ /
      Last update: 2022-06-28 09:13    [W:5.961 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site