lkml.org 
[lkml]   [2020]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711
    From
    Date
    On Fri, 2020-10-09 at 09:37 +0200, Ard Biesheuvel wrote:
    > On Fri, 9 Oct 2020 at 09:11, Christoph Hellwig <hch@lst.de> wrote:
    > > On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
    > > > Sadly I just realised that the series is incomplete, we have RPi4 users that
    > > > want to boot unsing ACPI, and this series would break things for them. I'll
    > > > have a word with them to see what we can do for their use-case.
    > >
    > > Stupid question: why do these users insist on a totally unsuitable
    > > interface? And why would we as Linux developers care to support such
    > > a aims?
    >
    > The point is really whether we want to revert changes in Linux that
    > made both DT and ACPI boot work without quirks on RPi4.

    Well, and broke a big amount of devices that were otherwise fine.

    > Having to check the RPi4 compatible string or OEM id in core init code is
    > awful, regardless of whether you boot via ACPI or via DT.
    >
    > The problem with this hardware is that it uses a DMA mask which is
    > narrower than 32, and the arm64 kernel is simply not set up to deal
    > with that at all. On DT, we have DMA ranges properties and the likes
    > to describe such limitations, on ACPI we have _DMA methods as well as
    > DMA range attributes in the IORT, both of which are now handled
    > correctly. So all the information is there, we just have to figure out
    > how to consume it early on.

    Is it worth the effort just for a single board? I don't know about ACPI but
    parsing dma-ranges that early at boot time is not trivial. My intuition tells
    me that it'd be even harder for ACPI, being a more complex data structure.

    > Interestingly, this limitation always existed in the SoC, but it
    > wasn't until they started shipping it with more than 1 GB of DRAM that
    > it became a problem. This means issues like this could resurface in
    > the future with existing SoCs when they get shipped with more memory,
    > and so I would prefer fixing this in a generic way.

    Actually what I proposed here is pretty generic. Specially from arm64's
    perspective. We call early_init_dt_scan(), which sets up zone_dma_bits based on
    whatever it finds in DT. Both those operations are architecture independent.
    arm64 arch code doesn't care about the logic involved in ascertaining
    zone_dma_bits. I get that the last step isn't generic. But it's all setup so as
    to make it as such whenever it's worth the effort.

    > Also, I assume papering over the issue like this does not fix the
    > kdump issue fundamentally, it just works around it, and so we might
    > run into this again in the future.

    Any ideas? The way I understand it the kdump issue is just a shortcoming of
    the memory zones design.

    Regards,
    Nicolas

    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2020-10-09 10:36    [W:7.017 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site