Thread (1 message) 1 message, 1 author, 2013-10-24

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

From: Maxime Bizon <hidden>
Date: 2013-10-24 13:00:55
Also in: linux-devicetree

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help