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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux