[PATCH v3 04/12] dm: Introduce xxx_get_dma_range()

Nicolas Saenz Julienne nsaenzjulienne at suse.de
Mon Dec 21 14:03:04 CET 2020


Hi Simon, thanks for the review.

On Fri, 2020-12-18 at 19:28 -0700, Simon Glass wrote:
> Hi Nicolas,
> 
> On Tue, 15 Dec 2020 at 10:23, Nicolas Saenz Julienne
> <nsaenzjulienne at suse.de> wrote:
> > 
> > Add the following functions to get a specific device's DMA ranges:
> >  - dev_get_dma_range()
> >  - ofnode_get_dma_range()
> >  - of_get_dma_range()
> >  - fdt_get_dma_range()
> > They are specially useful in oder to be able validate a physical address
> > space range into a bus's and to convert addresses from and to address
> > spaces.
> > 
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne at suse.de>
> > 
> > ---
> > Changes since v2:
> >  - Return ENOENT instead of ENODEV
> >  - Refcount OF nodes
> > 
> > Changes since v1:
> >  - Fix wrong arguments in of_get_dma_range()'s call to of_translate_dma_address()
> >  - Fix build in SPL/TPL and no LIBFDT supprt
> >  - Add missing declaration in 'core/read.c'
> >  - Address Matthias' comments
> > 
> >  common/fdt_support.c   | 73 +++++++++++++++++++++++++++++++++++++++
> >  drivers/core/of_addr.c | 78 ++++++++++++++++++++++++++++++++++++++++++
> >  drivers/core/ofnode.c  |  9 +++++
> >  drivers/core/read.c    |  6 ++++
> >  include/dm/of_addr.h   | 17 +++++++++
> >  include/dm/ofnode.h    | 16 +++++++++
> >  include/dm/read.h      | 21 ++++++++++++
> >  include/fdt_support.h  | 14 ++++++++
> >  8 files changed, 234 insertions(+)
> 
> Reviewed-by: Simon Glass <sjg at chromium.org>
> 
> I don't suppose it is worth writing a version that uses the ofnode API
> and thus reduce code size? Probably not since if livetree is enabled,
> I doubt we would ever call the flattree one. Also it is nice to have
> the same livetree code as Linux, where possible.

As far as the logic is concerned we'd be able to mimic what linux does so it
shouldn't be a problem.

But I'd be forced to port low level DT code to ofnode. Notably 'of_match_bus()'
and 'struct of_bus', which IMO have no place in ofnode: it seems to me that
ofnode is an abstraction geared towards simplifying DT consumers. This wouldn't
provide much benefit to them, with the downside of divering from upstream
Linux's implementation.

Regards,
Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20201221/038bbee0/attachment.sig>


More information about the U-Boot mailing list