Re: RfC: Handle SPI controller limitations like maximum message length

[Martin Sperl <martin-d5rIkyn9cnPYtjvyW6yDsg@public.gmane.org>]

> On 20.11.2015, at 13:05, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> 
> On Fri, Nov 20, 2015 at 11:18:42AM +0100, Martin Sperl wrote:
>>> On 19.11.2015, at 18:15, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> 
>>> Please don't do things this way, please make this more data driven -
>>> have the drivers declare their capabilities so the core can just do
>>> these things based on those flags rather than requiring active code in
>>> drivers.  This keeps the code central which in turn helps keep things
>>> maintainable.
> 
>> Well - I was thinking about starting with this approach for simplicity.
> 
>> Making it automatic/data-driven by just defining limits that the core
>> can then handle transparently is something that could come as a next
>> step.
> 
> It makes things more complicated in the long run, people start open
> coding things and then making any changes involves changing per-driver
> code and we can't use the information in any way other than the one
> specific way the transformation functions were written.

As said: lets see if it works and passes some logical tests
and then address those things we may want to define on top.

Still there may be different policies that we would need to run for
different spi masters when the transfers are not aligned,
so I wonder if it is really sane to parametrize all those in the
spi_master structure.

>> Also the bus master driver knows what its limitations are, so putting
>> them inside prepare_message seems reasonable to me - that is unless
>> you really have spi_device drivers that would handle those as separate
>> facts and not refuse to work.
> 
> Every line of code that's in a driver that could be in the core is a
> maintainence burden, people will want to start doing things like
> combining functions in fun ways and if we want to try to do things like
> figure out if we can coalesce adjacent transfers in the core (which we
> really ought to) it won't know what the limitations that exist are.
this “colaesce” of transfers into one could be one of those 
“transformation” I am talking about - and this one would be implemented
in core making certain assumptions (like starting on a page, ...)

The way I think of it it is actually very simple to implement that.

>>> You've got this back to front - drivers are responsible for initialising
>>> the master when they instantiate it.  There's nothing stopping them
>>> using the data if they have variants to handle but they shouldn't be
>>> speculatively looking at it on the off chance there's some limit.
> 
>> I wonder if such a variant-construct does not create more headaches in
>> the long run as each spi_driver wanting to do something “something”
>> special would then need to get updated for any additional constraint…
> 
> I'm sorry but I don't understand what you mean here.  However we
> implement things anything that wants to know about constraints is going
> to need to be updated to use them.

That is what I want to avoid if possible - the one thing that may come
handy (at least from my perspective) could be to give some hints to
make optimal use of the HW
Say:
* preferred alignment on X byte boundry
* preferred max spi_transfer.length

All the other possible constraints parameters should be opaque to 
a spi_device driver, so I would not want to include those inside the
spi_master structure, as _then_ these get used.

That is why I thought of putting those “policies” inside
prepare_message on the driver side.

Also the “restrictions” on the spi HW need to get defined inside the
driver, so there will not be a new “restriction” that applies to
an existing piece of HW just because we incorporate new options.



--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html