Re: (EXT) Re: (EXT) Re: [PATCH] spi-imx: remove num-cs support, set num_chipselect to 4

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

 



On Fri, 2020-09-04 at 10:57 -0300, Fabio Estevam wrote:
> On Fri, Sep 4, 2020 at 10:02 AM Matthias Schiffer
> <matthias.schiffer@xxxxxxxxxxxxxxx> wrote:
> 
> > This would make num_chipselect default to 1 again (set by
> > __spi_alloc_controller()), breaking every i.MX board that uses more
> > than 1 native CS.
> 
> Which boards are that? Are you referring to non-DT i.MX boards?
> 
> If so, I have sent a patch removing all non-DT i.MX boards.
> 
> > I'm aware that using cs-gpios instead of native CS is probably a
> > good
> > idea in any case, as the native CS of this SPI controller is kinda
> > flaky (and at a glance it looks like all in-tree DTs do this; not
> > sure
> > about board files that don't use DTs?), but I'm not convinced that
> > breaking native CS support completely is desirable either.
> 
> Initial i.MX chips with this SPI IP had issues in using chip-select
> in
> native mode and GPIO chip-select has been used since them.
> 
> Do we have i.MX dts that make use of native chip select?

As mentioned in my previous mail, all in-tree DTS use cs-gpios (unless
I've overlooked something - I grepped for CSPIn_SSm pinmuxings), so
removing support for native CS should not break anything we know of.

Nevertheless, I don't see why we should deliberately remove the native
CS support - my understanding was that we try to avoid breaking changes
to DT interpretation even for unknown/out-of-tree DTS.




[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