schemas: pci: Add W_DISABLE1# and VIO supply properties for M.2 slot

[Mani-Sadhasivam]

As per M.2 spec r4.0, add below PCI specific properties to describe a M.2 slot:

1. w-disable1-gpios: Specifies the GPIO controlled connection to W_DISABLE1# signal used for disabling the wireless radio on the M.2 card. When present, this signal is used to disable WLAN radio of the M.2 card. The spec defines one more signal, W_DISABLE2#, but that is applicable for Bluetooth only. Hence, not added here.

2. vio1v8-supply - Specifies the phandle to the VIO 1.8v regulator which supplies power to the Adapter I/O buffer circuitry operating at 1.8 V sideband signaling.

[stephan-gh]

Specifies the GPIO controlled connection to W_DISABLE1# signal used for disabling the wireless radio on the M.2 card. When present, this signal is used to disable WLAN radio of the M.2 card. The spec defines one more signal, W_DISABLE2#, but that is applicable for Bluetooth only.

This is not entirely correct. The spec says it is okay to have just a single W_DISABLE1# signal, in which case it should be used to disable all the radios on a chip. In that case, you would need some kind of reference counting for the GPIO (which is sort of what the pwrseq framework in Linux could do, I suppose).

An M.2 card is much more than just PCIe (or might not have PCIe at all), so I'm not sure it makes sense to model it separately as a PCIe slot. I've been recently playing with the idea of modelling an m2-connector in the device tree, similar to USB and display connectors. This would result in a unified resource description for all the functions provided by a M.2 card, e.g.:

m2-connector-wcn {
	compatible = "m2-connector";
	key = "e";
	3v3-supply = <&vreg_wcn_3p3>;
	vio-supply = <&vreg_l15b_1p8>;
	w-disable1-gpios = <&tlmm 117 GPIO_ACTIVE_LOW>;
	w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;

	ports {
		#address-cells = <1>;
		#size-cells = <0>;

		/* We would need to define these ports in the schema (per key maybe?) */
		port@0 {
			reg = <0>;
			m2_wcn_pcie_ep: endpoint {
				remote-endpoint = <&pcie4_port0_ep>;
			};
		};
		port@1 {
			reg = <1>;
			m2_wcn_uart_ep: endpoint {
				remote-endpoint = <&uart14_ep>;
			};
		};
		/* USB and any other supported standard ports would follow here */
	};
};

/* TBD: Where exactly do we attach the endpoint in the PCIe topology? */
&pci4_port0 {
	port {
		pcie4_port0_ep: endpoint {
			remote-endpoint = <&m2_wcn_pcie_ep>;
		};
	};
};

&uart14 {
	port {
		uart14_ep: endpoint {
			remote-endpoint = <&m2_wcn_uart_ep>;
		};
	};
};

The tricky part is that the M.2 specification leaves lots of room for vendor customization. Sometimes pins are abused for other functionality. We can't auto-discover all of the interfaces (e.g. UART).

I haven't come further than defining the idea yet :-)

[Mani-Sadhasivam]

This is not entirely correct. The spec says it is okay to have just a single W_DISABLE1# signal, in which case it should be used to disable all the radios on a chip.

Yes, I should've mentioned it as well.

In that case, you would need some kind of reference counting for the GPIO (which is sort of what the pwrseq framework in Linux could do, I suppose).

That's the job of the gpiolib subsystem in Linux. Right now, it doesn't have that capability, but work is in progress.

An M.2 card is much more than just PCIe (or might not have PCIe at all), so I'm not sure it makes sense to model it separately as a PCIe slot.

We are not modeling the M.2 card here, just the resources pertaining to the PCIe interface of the card. We discussed the M.2 DT connector binding recently internally, too, but to me, it looked wrong as it ties the whole card functionality to a single driver as if all the resources are shared. But in reality, each interface acts independently (AFAIK). So defining the resources in the relevant DT node (PCIe, USB, UART, etc...) seemed correct to me. Even if some of the resources are shared, the software drivers should be able to keep refcount on them.

But I'll defer to @robherring here on how we want to model it.

The tricky part is that the M.2 specification leaves lots of room for vendor customization. Sometimes pins are abused for other functionality. We can't auto-discover all of the interfaces (e.g. UART).

Right. Even, it allows the vendors to implement any interface of their need, not limited to the interfaces defined in the spec. In that case, the signal functionality will totally vary.

[stephan-gh]

We are not modeling the M.2 card here, just the resources pertaining to the PCIe interface of the card. We discussed the M.2 DT connector binding recently internally, too, but to me, it looked wrong as it ties the whole card functionality to a single driver as if all the resources are shared. But in reality, each interface acts independently (AFAIK).

This is the case for the Qualcomm WiFi/BT chips, but I don't think we can make any assumption about this for the general case. I don't see why a M.2 card couldn't, for example, use one firmware for all functionality on the chip (WiFi, BT, etc). In that case, the drivers would need to be aware of each other and coordinate with each other.

The M.2 card is one entity that is either fully plugged in or not. The fact that the PCIe/UART/USB/... interfaces belong to this one entity should be definitely visible in the device tree through some links, in my opinion.

There are also more complex power sequencing a M.2 may or may not need. For example, WWAN M.2 cards may also have a FULL_CARD_POWER_OFF# and RESET# signal that turns off/resets the entire adapter (including, presumably all interfaces used by the WWAN modem such as PCIe, USB etc). I don't think reimplementing all those signals separately in every subsystem is a good idea.

I definitely see value in describing the m2-connector in the device tree. What is still unclear to me, however, is how far we can get with a generic m2-connector. We may end up having to describe the actual plugged M.2 card/adapter (e.g. "WCN7850") due to the pain with auto-discovery and vendor-specific interfaces.

[Mani-Sadhasivam]

This is the case for the Qualcomm WiFi/BT chips, but I don't think we can make any assumption about this for the general case. I don't see why a M.2 card couldn't, for example, use one firmware for all functionality on the chip (WiFi, BT, etc). In that case, the drivers would need to be aware of each other and coordinate with each other.

Hmm, I don't disagree. Since there is a room for interpretation in the spec, we can't trust vendors.

I definitely see value in describing the m2-connector in the device tree. What is still unclear to me, however, is how far we can get with a generic m2-connector. We may end up having to describe the actual plugged M.2 card/adapter (e.g. "WCN7850") due to the pain with auto-discovery and vendor-specific interfaces.

We may see different forms of the same chip. For instance, WCN7850 may appear in a proper M.2 Key M and something else. So we might end up with a form factor specific compatible to handle these shenanigans.

If we get a go from @robherring, I can do a PoC, or if you have something, we can co-work.

[stephan-gh]

We may see different forms of the same chip. For instance, WCN7850 may appear in a proper M.2 Key M and something else. So we might end up with a form factor specific compatible to handle these shenanigans.

I would like to explore how far we can get without hardcoding the plugged M.2 card in the device tree. On some devices, M.2 cards are easily replaceable, so having some form of auto-detection would be useful to have. Plus, for things like NVMe M.2 cards, we obviously don't want to hardcode the actual SSD. Replacing the SSD is quite common.

For the WCN7850 case, a rough idea I had was to have the generic m2-connector description in DT like shown above. We power up the M.2 card with the power sequence defined in the M.2 specification. Then we can auto-discover the PCIe card. If the ath12k driver finds the m2-connector with a UART instance attached, it creates the qcom,wcn7850-bt serdev.

I don't have a POC for this yet and I'm not actively working on it right now. Feel free to draft something (with or without auto-discovery). The basic modelling in DT will be probably more or less the same.