Re: [PATCH] dt-bindings: fpga: microchip,mpf-spi-fpga-mgr: document CPOL/CPHA support

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

 



On Thu, Feb 22, 2024 at 09:02:30PM +0100, Marco Felsch wrote:
> On 24-02-22, Conor Dooley wrote:
> > On Wed, Feb 21, 2024 at 08:12:47PM +0100, Marco Felsch wrote:
> > > Microchip FPGAs can communicate in different modes, so document them to
> > > avoid dt-validate warnings.
> > 
> > Are you sure it can "communicate in different modes"?
> 
> No I'm not but I didn't found an overview within the FPGA datasheet [1]
> which modes are supported. What I did found was an note which says:
> 
> """
> 1. Parameters are referenced to the active edge of SCK, which depends on
> the configured SPI protocol (for example, Motorola SPI mode uses rising
> edge as active edge if SPO = 0)
> """
> 
> Therefore I thought that this can be configured somehow differently.
> 
> [1] https://www.microsemi.com/document-portal/doc_view/136519-ds0141-polarfire-fpga-datasheet
> 
> > The documentation actually says "Motorla SPI Mode 3 is required to
> > communicate with M2S, M2GL, and MPF devices using dedicated system
> > controller SPI port" with mode 3 being SPO = SPH = 1:
> > https://www.microsemi.com/document-portal/doc_view/137543-spi-directc-sp1-v2-0-user-guide
> 
> Thanks for the Pointer, there are plenty documents for the Polarfire
> FPGA.
> 
> > I suspect the answer is that it can actually communicate in different
> > modes (because I don't recall setting those options), but the binding
> > should enforce the correct way of doing it IMO.
> 
> Sure, I will rephrase my commit message to:
> 
> """
> dt-bindings: fpga: microchip,mpf-spi-fpga-mgr: document CPOL/CPHA
> 
> Using the dedicated system controller SPI port requires Motorola SPI
> Mode 3 according the SPI-DirectC v2.0 User Guid [1]. So require the
> spi-cpol and spi-cpha to be set.
> 
> [1] https://www.microsemi.com/document-portal/doc_view/137543-spi-directc-sp1-v2-0-user-guide
> """

You say require here, but don't actually make them required.
I think we probably should actually make them required, since the docs
say they should be used, but I'd like to look at it a bit more though
before that, since it does work on the setup I had without them.

I'd say do s/require/allow/ and I'll try to do some testing as to
whether we should actually mark the properties as required.

Acked-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx>

Cheers,
Conor.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux