Re: [PATCH 2/4] spi: gpio: Fix reading for 3WIRE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 6, 2018 at 11:05 AM Lorenzo Bianconi
<lorenzo.bianconi@xxxxxxxxxx> wrote:
> > On Tue, Sep 04, 2018 at 11:49:49PM +0200, Linus Walleij wrote:
> >
> > > So remains to add two new permutations:
> > > bitbang_txrx_be_3wire_cpha[0|1]() and double the
> > > code in spi-bitbang-txrx.h. Not good for maintenance.
> >
> > > So damned if I do, damned if I don't.
> >
> > > But I guess I go for the latter approach?
> >
> > Yes, I think so - there's obviously a lot of overhead from bitbanging
> > this stuff so it's worth it to try to minimize it.
>
> Hi Linus and Mark,
>
> maybe here we can move flags definition in spi_bitbang_bufs routine, e.g:
>
> -       return cs->txrx_bufs(spi, cs->txrx_word, nsecs, t, 0);
> +
> +       if (spi->master->flags & (SPI_MASTER_NO_TX | SPI_MASTER_NO_RX))
> +               return cs->txrx_bufs(spi, cs->txrx_word, nsecs, t,
> +                                    spi->master->flags);
> +       else
> +               return cs->txrx_bufs(spi, cs->txrx_word, nsecs, t, 0);
>
> in this way we can unify spi_gpio_txrx_word_mode{0-3}/spi_gpio_spec_txrx_word_mode{0-3} definitions
> in spi-gpio.c and other drivers in the future can use this optimization. What
> do you think? Are there any side affects with that approach?

I think it's not working because real half-duplex adapters, those
who *REALLY* cannot do RX or TX will attempt to do RX and TX
anyways if we do that. Not that I know if there are any.

AT lunch I've finally understood, maybe, what needs to be done
so I' working on some better solution.

Yours,
Linus Walleij



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux