On 2015/10/14 18:53, Vinod Koul wrote: > On Thu, Oct 08, 2015 at 10:31:18AM +0200, Lars-Peter Clausen wrote: >>> Basically I agree not to expose dma's quirk to slave controllers...But, the >>> fact I mentioned on cover letter explain the reasons why I have to let slave >>> controllers know that they are working with a broken dma. It's a dilemma >>> that if we don't want that to be exposed(let slave controllers' driver get >>> the info via a API), we have t add broken quirk for all of them ,here and >>> there, which seems to be a disaster:( >> >> The problem with this API is that it transports values with device specific >> meanings over a generic API. Which is generally speaking not a good idea >> because the consumer witch is supposed to be generic suddenly needs to know >> which provider it is talking to. >> >> A better solution in this case typically is either introduce a generic API >> with generic values or a custom API with custom values, but don't mix the two. >> >>> >>> I would appreciate it if you could give me some suggestions at your earliest >>> convenience. :) >> >> In this case I think the best way to handle this is not quirks, but rather >> expose the actual maximum burst size using the DMA capabilities API. Since >> supporting only a certain burst depth is not really a quirk. All hardware >> has a limit for this and for some it might be larger or smaller than for >> others and it might be the same IP core but the maximum size depends on some >> IP core parameters. So this should be discoverable. > > yes that makes more sense than adding quirks, exposing the right values > which should be a readable property for driver will ensure it works on > system with/without quirks Sorry for late response in this thread. Right, we can expose max-burst to clients by dma_slave_caps instead of quirks. I will try it and send v6 ASAP. Thanks Lars and Vinod. > -- Best Regards Shawn Lin
