Messages in this thread | | | From | Lars Povlsen <> | Subject | Re: [PATCH v2 3/6] spi: dw: Add Microchip Sparx5 support | Date | Tue, 23 Jun 2020 15:53:22 +0200 |
| |
Mark Brown writes:
On Mon, Jun 22, 2020 at 12:46:33PM +0200, Lars Povlsen wrote: >> On Fri, Jun 19, 2020 at 01:31:18PM +0200, Lars Povlsen wrote: > >> >> + if (!nEnable) { >> >> + /* Ensure CS toggles, so start off all disabled */ >> >> + regmap_write(dwsmscc->syscon, SPARX5_FORCE_VAL, ~0); >> >> + /* CS override drive enable */ >> >> + regmap_write(dwsmscc->syscon, SPARX5_FORCE_ENA, 1); > >> >This should just be setting the value to whatever the core asked for it >> >to be set to, the driver adding extra toggles is likely to disrupt >> >things. > >> I will have a look at this again. But it was added for a reason. The >> issue is that we have two different busses in front of the controller, >> so we might need more settle time when switching interface. > >If there's a mux that needs to be handled specially that mux should be >described in DT on the relevant boards, there shouldn't just be >something hard coded in the controller driver.
I have been able to change this into a straight setting - no toggling. Just needed a settle delay.
I looked at the spi-mux driver, but that is more for muxing the CS's, as I understand - not the actual bus segment. I could use it, but it would require encoding the bus segment into the CS (double the normal range). Also, selecting the bus interface is tightly coupled to the controller - its not an externally constructed board mux.
I feel the current implementation is more to the point, and easily understandable. It just adds the "microchip,spi-interface2" DT property.
It might be that a better way exists using the spi-mux framework, and if you have some ideas for that I'd be all ears.
> >BTW please do not CC subsystem patches to soc@kernel.org unless there's >a specific reason to do so - there's no need for it, these patches won't >get merged via there unless something is going wrong. Generally the >subsystem maintainers take patches for a given subsystem.
Ok, duly noted.
Thank you for the comments.
---Lars
-- Lars Povlsen, Microchip
| |