From: Thierry Reding <thierry.red...@gmail.com> Date: Sep/25/2019, 23:46:20 (UTC+00:00)
> On Wed, Sep 25, 2019 at 10:31:13AM -0700, Florian Fainelli wrote: > > The way I would approach it (as done in bcmgenet.c) is that if the > > platform both has CONFIG_PHYS_ADDR_T_64BIT=y and supports > 32-bits > > addresses, then you write the upper 32-bits otherwise, you do not. Given > > you indicate that the registers are safe to write regardless, then maybe > > just the check on CONFIG_PHYS_ADDR_T_64BIT is enough for your case. The > > rationale in my case is that register writes to on-chip descriptors are > > fairly expensive (~200ns per operation) and get in the hot-path. > > > > The CONFIG_PHYS_ADDR_T_64BIT check addresses both native 64-bit > > platforms (e.g.: ARM64) and those that do support LPAE (ARM LPAE for > > instance). > > I think we actually want CONFIG_DMA_ADDR_T_64BIT here because we're > dealing with addresses returned from the DMA API here. > > I can add an additional condition for the upper 32-bit register writes, > something like: > > if (IS_ENABLED(CONFIG_DMA_ADDR_T_64BIT) && priv->dma_cfg->eame) > ... > > The compiler should be able to eliminate that as dead code on platforms > that don't support 64-bit DMA addresses, but the code should still be > compiler regardless of the setting, thus increasing the compile > coverage. I'm fine with this. Some notes: a) Do not try to enable dma_cfg->eame if CONFIG_DMA_ADDR_T_64BIT is not enabled; b) You can even add a likely() around priv->dma_cfg->eame check because if a given SoC supports 64 bit addressing then its highly probable that the IP will also support EAME. --- Thanks, Jose Miguel Abreu
