On 29-06-20, 12:19, André Przywara wrote:

On 29/06/2020 10:54, Vinod Koul wrote:

quoted

quoted

What newer SoCs? I don't think we should try to guess the future here.

In a patch for adding new SoC, quite ironical I would say!

S700 is not a new SoC, it's just this driver didn't support it yet. What
I meant is that I don't even know about the existence of upcoming SoCs
(Google seems clueless), not to speak of documentation to assess which
DMA controller they use.

quoted

quoted

We can always introduce further abstractions later, once we actually
*know* what we are looking at.

Rather if we know we are adding abstractions, why not add in a way that
makes it scale better rather than rework again

I appreciate the effort, but this really tapping around in the dark,
since we don't know which direction any new DMA controller is taking. I
might not even be similar.

quoted

quoted

Besides, I don't understand what you are after. The max frame length is
1MB in both cases, it's just a matter of where to put FCNT_VAL, either
in FLEN or in CTRLB. And having an extra flag for that in driver data
sounds a bit over the top at the moment.

Maybe, maybe not. I would rather make it support N SoC when adding
support for second one rather than keep adding everytime a new SoC is
added...

Well, what do you suggest, specifically? At the moment we have two
*slightly* different DMA controllers, so we differentiate between the
two based on the model. Do you want to introduce an extra flag like
FRAME_CNT_IN_CTRLB? That seems to be a bit over the top here, since we
don't know if a future DMA controller is still compatible, or introduces
completely new differences.

Fair enough, okay let us go with compatible for now

-- 
~Vinod

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel