On 10/21/19 12:18 PM, Andrew Murray wrote: [...] >>>> In case the "dma-ranges" DT property contains either too many ranges >>>> or the range start address is unaligned in such a way that populating >>>> the range into the controller requires multiple entries, a situation >>>> may occur where all ranges cannot be loaded into the controller. >>>> >>>> Currently, the driver refuses to probe in such a situation. Relax this >>>> behavior, load as many ranges as possible and warn if some ranges do >>>> not fit anymore. >>> >>> What is the motivation for relaxing this? >> >> U-Boot can fill the ranges in properly now, the list would be longer in >> such a case and the driver would fail to probe (because the list is >> longer than what the hardware can support). > > Is this the U-Boot patch you refer to: > > https://patchwork.ozlabs.org/patch/1129436/ Yes. > As pci_set_region is called with the same address for PCI and CPU memory > this implies there is a 1:1 mapping - therefore I don't see a need for > multiple mappings for each DRAM bank. (Also if this controller has a > 32 bit limitation, shouldn't this code limit the addresses before calling > pci_set_region?). It would certainly be helpful to know about this dma-ranges detail earlier, this whole thing could've been avoided. Now all I can do is get that patch reverted for the next U-Boot release. But this still leaves me with one open question -- how do I figure out what to program into the PCI controller inbound windows, so that the controller correctly filters inbound transfers which are targetting nonexisting memory ? -- Best regards, Marek Vasut
