SPI MPFS add second CS for polarfire SoC to use Fabric chip select

[RossWilliamson]

The current hard core SPI driver only allows a single CS line. When you want to pass the CS line through the fabric then that line is actually CS 1 not CS0. This change allows you to use the hard core SPI driver with a fabric CS line with the required change to the device tree to use the second spi CS line.

Tested on polarfire SoC only

[ConchuOD]

How is your MSS configurator set up? Do you have "Data I/Os..." set to an MSS I/O Bank, and "Target Select 1" set to "Fabric I/O"?

[RossWilliamson]

How is your MSS configurator set up? Do you have "Data I/Os..." set to an MSS I/O Bank, and "Target Select 1" set to "Fabric I/O"?

It's setup as below with all the lines directed through the fabric

Also note that in the smartdesign block only SS1 is passed out of the MSS, there is no SS0. Maybe this is a MSS block bug but it would be great to have 2 chip selects availble

[ConchuOD]

When you say "tested on polarfire soc", what did you actually test with? Do you have a pseudo devicetree that you can share with me (you can of course just hide compatibles or anything like that if you cannot share that info, I just need to see the nodes and their reg properties)?

[ConchuOD]

How these chip selects came up internally about two years ago, so I went to find the bug report that I got.

Unfortunately, the submitter never really followed up with the ticket, so I could never confirm that my findings solved their problem, but the conclusion pretty much was that there is actually only a single chip select (so register bit 0) and that when you set the first dropdown to Fabric I/Os, it gives you the impression that you're routing chip select 0 to the fabric, but actually it means that what it calls "Target Select 0" gets routed nowhere. What it calls "Target Select 1" is routed to a Fabric I/O, but is controlled by register bit 0, so you need to use reg = <0> in your devicetree despite what your screenshot would imply.

I think putting Fabric I/O in the first dropdown and Unused in the third produces no viable chip select - this you can probably confirm fairly easily from the smartdesign.

I do not recall if I tested having an MSS I/O in the first dropdown and Fabric I/O in the third one, but I was told that this does not actually produce two independant chip selects. This is why the number of chip selects is limited to 1. I originally interpreted your comment about "Tested on polarfire SoC only" as you hooked up two devices, with MSS I/O in the first dropdown and Fabric I/O in the third, with a dts like:

&spi0 {
  dev1@0 {
    ret = <0>;
  };
  dev2@1 {
    ret = <1>;
  };
};

and were able to access both devices. This could work, even though I was told that it doesn't (and the MSS Configurator warns if you try this mixture, although not about the chip select just about splitting I/O banks). As your screenshot shows, there's only one port marked "SS" per controller in the smartdesign, and you had both dropdowns set to Fabric I/O so this couldn't have been what you did.

it would be great to have 2 chip selects availble

You're using Fabric I/O, so you should be able to route a GPIO to that pin and use GPIO CS?

[RossWilliamson]

So for my use-case the I needed both the options set to fabric. I can double check but I think you are right in that If you don't set the target select 1 to fabric you don't actually get a SS out of the MSS block. I was not trying to talk to two devices with two CS just one device with one CS.

Logbook

• The SPI was connected up to actual hardware on a board (ADC).
• I checked the testpin that the fabric SS1 was constrained to and there was no activity.
• I then noticed the MSS block stated SS1 (not SS0) so changed the device tree (see below) to reg <1> not reg <0> which then gave me the error regarding only one CS allowed (due to the kernel driver).
• I hacked the driver to allow 2 chip selects and then with reg<1> I saw the correct activity on the CS line

Device Tree snippit

&spi1 {
	status = "okay";
	spidev1: spidev@1 {
		status = "okay";
		compatible = "linux,spidev", "rohm,bh2228fv";
		spi-max-frequency = <500000>;
		reg = <1>;
     };
};

Oh and yeah I forgot you can use GPIOs as the CS so thanks for reminder me

[ConchuOD]

I hacked the driver to allow 2 chip selects and then with reg<1> I saw the correct activity on the CS line

Right, I'll have to reexamine this then. I must have made a mistake in my testing. This makes me think that doing the split bank thing I mentioned gives you two different chip selects.

FWIW, I think your driver hack isn't needed, you can just set num-cs to 2 in your dts for the same result. It'll produce a dtbs_check warning though. Dunno if that makes any difference to you though.

I'm not sure what the "correct" fix for this is, that still tries to produce warnings if people do things that are invalid.