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

On Thu, Oct 24, 2013 at 12:47:58PM +0100, David Woodhouse wrote:

quoted

On Thu, 2013-10-24 at 13:33 +0200, Maxime Bizon wrote:

quoted

ok then how do we solve that case:

 - Marvell SOC 1 is mainlined
 - Marvell SOC 2 is mainlined
 - Marvell SOC 'x' is mainlined
 - "PIO" hw crypto driver is written, working for all SOCs
 - [1 year]
 - SOCs bindings are marked as stable
 - [1 year]
 - someone rewrite the driver of hw crypto to use DMA, existing

binding

quoted

is not ok because clock 'foo' or interrupt 'bar', now required, are

not

quoted

present.

what is the process merge that driver ?

if the answer is that you need to keep PIO mode in driver so that
existing DTBs still works with it, then this is just plain *wrong*.

If you can automatically infer the correct clock/interrupt/etc in order
to do DMA correctly, despite the fact that it wasn't explicitly spelled
out in the old DT, then the property is *not* a "required" property.
It's optional, and you have a default behaviour for when it's not
present.

(And if you *can't* automatically infer that or otherwise get away
without it, then you're asking for the impossible, surely?)

The default behaviour in the absence of these properties may be
horrendously complex, and it may be defined only for SOC [1..x] and not
newer versions; it may be *mandatory* for SOC x+1.

But if you really want the new driver to do DMA on platforms even where
this information wasn't originally provided by the DT, what option do
you have?

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.

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

Right. All that was implicit when I said "If you are correct to insist
that DMA has to be supported..."

It doesn't entirely defeat the purpose. It may have been easy to infer the
answers for the first incarnations of the hardware, but later it gets more
complex and needs to be spelled out.

-- 
dwmw2