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

From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Brian Masney <bmasney@redhat.com>,
	Shazad Hussain <quic_shazhuss@quicinc.com>,
	Mark Brown <broonie@kernel.org>
Cc: andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	konrad.dybcio@linaro.org, robh+dt@kernel.org,
	johan+linaro@kernel.org, linux-arm-msm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	ahalaney@redhat.com, echanude@redhat.com,
	linux-spi@vger.kernel.org,
	Javier Martinez Canillas <fmartine@redhat.com>
Subject: Re: [PATCH 4/4] arm64: dts: qcom: sc8280xp: add missing spi nodes
Date: Tue, 13 Dec 2022 14:02:10 +0100	[thread overview]
Message-ID: <77c29d8c-34b3-f508-26bf-22520ccc1f2a@linaro.org> (raw)
In-Reply-To: <Y5hvlX35nr8xQKEd@x1>

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@redhat.com>
>>> ---
>>>   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