On 10/16/19 8:12 PM, Rob Herring wrote: > On Wed, Oct 16, 2019 at 11:18 AM Lorenzo Pieralisi > <lorenzo.pieralisi@xxxxxxx> wrote: >> >> [+RobH, Robin] >> >> On Wed, Oct 16, 2019 at 05:29:50PM +0200, Marek Vasut wrote: >> >> [...] >> >>>>> The firmware provides all the ranges which are available and usable, >>>>> that's the hardware description and that should be in the DT. >>>> >>>> If the HW (given that those dma-ranges are declared for the PCI host >>>> controller) can't be programmed to enable those DMA ranges - those >>>> ranges are neither available nor usable, ergo DT is broken. >>> >>> The hardware can be programmed to enable those DMA ranges, just not all >>> of them at the same time. >> >> Ok, we are down to DT bindings interpretation then. >> >>> It's not the job of the bootloader to guess which ranges might the next >>> stage like best. >> >> By the time this series: >> >> https://patchwork.ozlabs.org/user/todo/linux-pci/?series=132419 >> >> is merged, your policy will require the host controller driver to >> remove the DMA ranges that could not be programmed in the inbound >> address decoders from the dma_ranges list, otherwise things will >> fall apart. > > I don't think the above series has too much impact on this. It's my > other series dealing with dma masks that's relevant because for dma > masks we only ever look at the first dma-ranges entry. We either have > to support multiple addresses and sizes per device (the only way to > really support any possible dma-ranges), merge entries to single > offset/mask or have some way to select which range entry to use. > > So things are broken to some extent regardless unless MAX_NR_INBOUND_MAPS == 1. > >>>>> The firmware cannot decide the policy for the next stage (Linux in >>>>> this case) on which ranges are better to use for Linux and which are >>>>> less good. Linux can then decide which ranges are best suited for it >>>>> and ignore the other ones. >>>> >>>> dma-ranges is a property that is used by other kernel subsystems eg >>>> IOMMU other than the RCAR host controller driver. The policy, provided >>>> there is one should be shared across them. You can't leave a PCI >>>> host controller half-programmed and expect other subsystems (that >>>> *expect* those ranges to be DMA'ble) to work. >>>> >>>> I reiterate my point: if firmware is broken it is better to fail >>>> the probe rather than limp on hoping that things will keep on >>>> working. >>> >>> But the firmware is not broken ? >> >> See above, it depends on how the dma-ranges property is interpreted, >> hopefully we can reach consensus in this thread, I won't merge a patch >> that can backfire later unless we all agree that what it does is >> correct. > > Defining more dma-ranges entries than the h/w has inbound windows for > sounds like a broken DT to me. > > What exactly does dma-ranges contain in this case? I'm not really > visualizing how different clients would pick different dma-ranges > entries. You can have multiple non-continuous DRAM banks for example. And an entry for SRAM optionally. Each DRAM bank and/or the SRAM should have a separate dma-ranges entry, right ? -- Best regards, Marek Vasut
