On Wed, Mar 23, 2016 at 06:25:46PM +0100, Stefan Roese wrote: > On 23.03.2016 14:27, Mark Brown wrote: > >No, really - it's just unhelpful. Putting this in the ABI means that > >every single system integrator who cares about performance is going to > >need to go and manually figure out how to configure this in DT and > >manually select values. That's not doing a good job for users, it's > >making their lives harder for no gain. If there are no physical > >constraints then how we allocate space in the MBus should be a runtime > >thing, it shouldn't be part of the ABI. > Do I understand you correctly, that you want the complete MBus > allocation and configuration to be included in the SPI driver > instead of using the DT to describe the window (target, attribute, > area)? If yes, then the SPI driver would be the first driver > to do this "internally". All other drivers using MBus resources > parse these from the DT (AFAIK) as this is highly SoC specific. That seems pretty surprising, especially if there is a possibility that we might run out of resources on the MBus even if just in some unusual situation. Why would this be manually configured in DT if there's no hardware restriction? Based on what people are saying I'd expect the SPI controller to have a reference to the attached bus which it uses to find the bus and then ask the bus to allocate it whatever it needs from the space available. I mean, I guess if that's what you're forcing users to do that's what you're forcing users to do but it seems like it's making people do manual work that should be automated. It's possible I'm missing something about how this hardware works...
Attachment:
signature.asc
Description: PGP signature
