Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes

[Krzysztof Kozlowski]

On 13/12/2022 13:27, Brian Masney wrote:
> + Mark Brown and linux-spi list
> 
> On Tue, Dec 13, 2022 at 12:46:18PM +0530, Shazad Hussain wrote:
>> On 12/12/2022 11:53 PM, Brian Masney wrote:
>>> Add the missing nodes for the spi buses that's present on this SoC.
>>>
>>> This work was derived from various patches that Qualcomm delivered
>>> to Red Hat in a downstream kernel.
>>>
>>> Signed-off-by: Brian Masney <bmasney@xxxxxxxxxx>
>>> ---
>>>   arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 384 +++++++++++++++++++++++++
>>>   1 file changed, 384 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> index 392a1509f0be..b50db09feae2 100644
>>> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
>>> @@ -829,6 +829,22 @@ qup2_i2c16: i2c@880000 {
>>>   				status = "disabled";
>>>   			};
>>> +			qup2_spi16: spi@880000 {
>>> +				compatible = "qcom,geni-spi";
>>> +				reg = <0 0x00880000 0 0x4000>;
>>> +				clocks = <&gcc GCC_QUPV3_WRAP2_S0_CLK>;
>>> +				clock-names = "se";
>>> +				interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
>>> +				#address-cells = <1>;
>>> +				#size-cells = <0>;
>>> +				interconnects = <&clk_virt MASTER_QUP_CORE_2 0 &clk_virt SLAVE_QUP_CORE_2 0>,
>>> +				                <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_QUP_2 0>,
>>> +				                <&aggre1_noc MASTER_QUP_2 0 &mc_virt SLAVE_EBI1 0>;
>>> +				interconnect-names = "qup-core", "qup-config", "qup-memory";
>>> +				spi-max-frequency = <50000000>;
>>
>> This is device property not host and same applicable for all below spi
>> nodes.
>> Also FYI let's enable below SPI for Qdrive usecases once spidev compatible
>> name is confirmed.
>> SE9  0x00A84000
>> SE22 0x00898000
> 
> I talked to Javier Martinez Canillas yesterday about the spidev driver
> and I think I now have a better understanding of what we need to do.
> Quick background for Mark. For this automotive program, Qualcomm will be
> delivering to Red Hat and our customers parts of the media stack in
> userspace. This will be closed source, proprietary code that parts of it
> will need to interface with SPI.
> 
> We can't add a generic qcom,spidev compatible to the spidev driver since
> this is just a software abstraction. Instead, each type of device will
> need to have it's own compatible that uniquely describes the type of
> device. So you might have a compatible like qcom,spi-video-codec. There
> will need to be a DT binding added that describes the hardware. I suspect
> that a SPI device can simply be added to trivial-devices.yaml. Once the
> DT binding is accepted, the compatible can be added to the spidev.c
> driver. If an in-kernel driver is written in the future, then the 
> compatible can be moved from spidev to the new driver.
> 
> Mark: Is my understanding above correct? If so, will it be a problem to
> get a compatible added to spidev.c if the corresponding userspace code is
> closed source and proprietary?

qcom,spi-video-codec is still not specific enough. You need to describe
real device behind spidev. To be clear - you do not describe userspace,
but the device.

Best regards,
Krzysztof