On 29-06-20, 12:19, André Przywara wrote: > On 29/06/2020 10:54, Vinod Koul wrote: > >> 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. > > >> 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. > > >> 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
