lkml.org 
[lkml]   [2020]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 11/17] spi: dw: Fix native CS being unset
    On Thu, May 14, 2020 at 02:55:58PM +0300, Serge Semin wrote:
    > On Thu, May 14, 2020 at 10:31:13AM +0200, Linus Walleij wrote:

    > > We had some related discussion what to do with this case
    > > when a controller can support active high CS if and only if
    > > it is using a GPIO instead of the native CS. We didn't really
    > > figure it out, I suppose ideally we should use two flags in the
    > > master but that exercise is for another day.

    > Even though it might be painful, but as I see it the best way to generically fix
    > this problem would be to change the controller->set_cs() callback
    > semantics. SPI core should pass a CS activation flag to the set_cs()
    > callback instead of the CS pin logical level (just propagate the enable argument
    > passed to the spi_set_cs() SPI core method). So if an SPI controller supports
    > the Active-high native CS, during the set_cs() callback invocation it would
    > analyze the spi_device flags state to figure out whether the slave needs the

    The idea with set_cs() is to support controllers that allow the chip
    select to be directly managed. If the controller is interpreting or
    automatically managing chip select at all then set_cs() is not likely to
    be a good fit, if the controller does support unfiltered management then
    anything else is going to result in there being a bunch of duplicate
    code between drivers.
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2020-05-14 16:36    [W:5.676 / U:0.180 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site