On 15/11/2022 15:19, Vladimir Oltean wrote: > On Tue, Nov 15, 2022 at 03:08:37PM +0100, Krzysztof Kozlowski wrote: >> On 15/11/2022 14:59, Vladimir Oltean wrote: >>> On Tue, Nov 15, 2022 at 02:46:21PM +0100, Krzysztof Kozlowski wrote: >>>>> +$id: http://devicetree.org/schemas/spi/fsl,spi-fsl-dspi.yaml >>>> >>>> Why second "fsl" in file name? It does not patch compatibles and >>>> duplicates the vendor. We do not have compatibles "nxp,imx6-nxp". >>> >>> Ok, which file name would be good then? There are 9 different (all SoC >>> specific) compatible strings, surely the convention of naming the file >>> after a compatible string has some limitations... >> >> If all DSPI blocks fit here, then maybe: fsl,dspi.yaml >> >> fsl,spi-dspi.yaml is also a bit redundant. > > Ok, fsl,dspi.yaml and fsl,dspi-peripheral-props.yaml, and MAINTAINERS > entry for fsl,dspi*.yaml? Yes. > >>>>> +properties: >>>>> + compatible: >>>>> + description: >>>>> + Some integrations can have a single compatible string containing their >>>>> + SoC name (LS1012A, LS1021A, ...). Others require their SoC compatible >>>>> + string, plus a fallback compatible string (either on LS1021A or on >>>>> + LS2085A). >>>> >>>> Why? The fsl,ls1012a-dspi device is either compatible with >>>> fsl,ls1021a-v1.0-dspi or not. It cannot be both - compatible and not >>>> compatible. >>> >>> LS1012A is compatible with LS1021A to the extent that it works when >>> treated like a LS1021A. LS1012A has a FIFO size of 8 SPI words, LS1021A >>> of just 4. Treating it like LS1021A means roughly half the performance, >>> but it still works. >>> >>> I didn't invent any of this. When I took over the driver, there were >>> device trees like this all over the place: >>> >>> dspi: spi@2100000 { >>> compatible = "fsl,ls1012a-dspi", "fsl,ls1021a-v1.0-dspi"; >> >> Which looks ok... >> >>> #address-cells = <1>; >>> #size-cells = <0>; >>> reg = <0x0 0x2100000 0x0 0x10000>; >>> interrupts = <0 64 IRQ_TYPE_LEVEL_HIGH>; >>> clock-names = "dspi"; >>> clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL >>> QORIQ_CLK_PLL_DIV(1)>; >>> spi-num-chipselects = <5>; >>> big-endian; >>> status = "disabled"; >>> }; >>> >>> but the Linux driver pre-~5.7 always relied on the fallback compatible >>> string (LS1021A in this case). I'm working with what's out in the field, >>> haven't changed a thing there. >> >> The driver matters less (except ABI), but anyway it confirms the case - >> fallback is expected always. Why the fallback should be removed if the >> devices are compatible (including halved performance)? > > I don't think I said the fallback should be removed? I think you're > talking about a typo/braino I made, which puts the LS1012A both in the > bucket of SoCs with a single compatible strings required, as well as in > that with fallback required. Obviously both can't be true... I didn't > mean LS1012A but VF610. To be clear: ls1012a, ls1028a and lx2160a should be either followed by compatible or not. Cannot be both. Best regards, Krzysztof
