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

[Heiner Kallweit <hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Am 21.11.2015 um 14:49 schrieb Mark Brown:
> On Fri, Nov 20, 2015 at 01:56:13PM +0100, Martin Sperl wrote:
> 
>>> 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, ...)
> 
> Why would we want to force that assumption?  It massively reduces the
> utility for DMA controllers that don't have such limitations.
> 
>>>> 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.
> 
> You're conflating two unrelated design decisions here.  Yes, it's
> unfortunate that the SPI API was written to allow client drivers to see
> the master structure but that doesn't mean that converting data into
> code is a good idea, that's still a bad pattern independently of the
> visibility issue.
> 
Currently the only (?) way for a protocol driver like spi-nor to get
info about HW restrictions described in the controller driver
is via the master structure and its "constraint" members.

As you say this visibility of the master structure is unfortunate:
What could be a (maybe long-term) better way to propagate restrictions
that can't be handled transparently in the core like max message size
and SPI NOR to protocol drivers?

>> 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.
> 
> That's what I was saying?
> 

--
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