On 15.06.21 02:41, Marek Vasut wrote: > On 6/15/21 2:28 AM, Peng Fan (OSS) wrote: >> >> >> On 2021/6/7 20:38, Marek Vasut wrote: >>> On 6/7/21 2:05 PM, Frieder Schrempf wrote: >>>> From: Frieder Schrempf <frieder.schre...@kontron.de> >>>> >>>> Some IPs have their accessible address space restricted by the >>>> interconnect. Let's make sure U-Boot only ever uses the space below >>>> the 4G address boundary (which is 3GiB big), even when the effective >>>> available memory is bigger. >>>> >>>> We implement board_get_usable_ram_top() for all i.MX8M SoCs, as the >>>> whole family is affected by this. >>> >>> Shouldn't only those specific IP drivers handle buffers in the 64bit space >>> somehow ? E.g. using a bounce buffer ? >> >> That could cause extra mem copy. > > If you want to avoid the extra memcopy, then make sure the buffers are not > allocated above 4 GiB boundary. Then the bounce buffer does no copy. > > This board_get_usable_ram_top() is just a temporary workaround for platforms > with broken drivers which are not fixed yet, so please fix the drivers > instead. > >> Bounce buffer would be good for systems >> that take U-Boot as UEFI firmware, because U-Boot would be located at >> high end, but in the middle just top of 4GB. > > The bounce buffer is a necessity for IPs which cannot address more than the 4 > GiB of memory. In fact, it would be even better to handle DT dma-ranges, but > that is the next step. > >> I not object this patch, but it also be good if bounce buffer be added >> for improvement. >> >> Reviewed-by: Peng Fan <peng....@nxp.com> > > I do object to this, since it increases the proliferation of this broken > board_get_usable_ram_top() workaround instead of fixing the drivers properly.
I generally agree with Marek's objections and if anyone comes up with a proper fix this will be highly appreciated. For now I just dropped this patch from my v2 patchset, but Stefano has already pulled it into u-boot-imx. I guess it's up to him to decide if this intermediate fix should be merged or not.
