[Ksummit-2013-discuss] ARM topic: Is DT on ARM the solution, or is there something better?

Maxime Bizon mbizon at freebox.fr
Thu Oct 24 09:00:55 EDT 2013


On Thu, 2013-10-24 at 14:23 +0200, Thierry Reding wrote:

> To me it sounds more like the sensible default would be to continue to
> run with PIO support if the optional properties needed for DMA support
> are not present.

huge leap backward

 - need to maintain & test two completely different code paths (might as
well fork the driver)

 - we can no longer claim: "upgrade to mainline, you get all new stuff
for free"

Today I can 'just' upgrade my kernel and get all improvements in
networking stack, fs scalability, ... Before DT, hardware support &
drivers improvement were part of that package, now we are proposing they
won't.

> Determining default values for the properties pretty much defeats the
> purpose of putting them in the DT in the first place, doesn't it?

my point

before DT scenario for my hw crypto driver example: 
  - edit socX.h to add the missing #define HW_CRYPTO_INTERRUPT
  - edit platform data to add IRQ resource
  - change driver code to use DMA
  - single bisectable merge
  - anyone with socX benefits by just upgrading kernel

DTS files are sometimes describing SOCs hardware properties that cannot
be changed in any way, these values would better be left in soc-foo.h
(where they were before).

-- 
Maxime





More information about the linux-arm-kernel mailing list