| Message ID | 20241126134529.936451-3-va@nvidia.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add spidev nodes for SPI controllers | expand |
On Tue, Nov 26, 2024 at 01:45:28PM +0000, Vishwaroop A wrote: > + # NVIDIA Tegra SPIDEV Controller device > + - nvidia,tegra-spidev All the issues with having spidev nodes directly in the DT also apply if you add a prefix onto it. Whatever is attached to the SPI controller needs to be described, not just a placeholder like this.
Hi Mark, Krzysztof, On 26/11/2024 13:56, Mark Brown wrote: > On Tue, Nov 26, 2024 at 01:45:28PM +0000, Vishwaroop A wrote: > >> + # NVIDIA Tegra SPIDEV Controller device >> + - nvidia,tegra-spidev > > All the issues with having spidev nodes directly in the DT also apply if > you add a prefix onto it. Whatever is attached to the SPI controller > needs to be described, not just a placeholder like this. Chatting with Vishwaroop, what he is trying to accomplish with this patchset it to have a pseudo SPI device that we can control from userspace. On the Tegra Jetson boards we have a 40-pin expansion header similar to what is found on boards like Raspberry Pi and allows users to connect various cards to. By having a pseudo device we can interact with different SPI devices. Yes by default nothing is connected and so there is nothing to talk to. However, this does enable us to do SPI loopback testing for example. So I am wondering if it would be acceptable to having some generic dummy device-tree compatible string for this? I guess it does not need to be Tegra specific. Thanks Jon
On Wed, Nov 27, 2024 at 03:54:52PM +0000, Jon Hunter wrote: > On the Tegra Jetson boards we have a 40-pin expansion header similar to what > is found on boards like Raspberry Pi and allows users to connect various > cards to. By having a pseudo device we can interact with different SPI > devices. > Yes by default nothing is connected and so there is nothing to talk to. > However, this does enable us to do SPI loopback testing for example. > So I am wondering if it would be acceptable to having some generic dummy > device-tree compatible string for this? I guess it does not need to be Tegra > specific. I understand what he's trying to accomplish, it's the same thing as what everyone who wants to put a raw spidev compatible in their DT is trying to do. The way to do this would be something like a DT overlay that describes whatever is actually connected, or just customise the DT locally.
On 27/11/2024 16:09, Mark Brown wrote: > On Wed, Nov 27, 2024 at 03:54:52PM +0000, Jon Hunter wrote: > >> On the Tegra Jetson boards we have a 40-pin expansion header similar to what >> is found on boards like Raspberry Pi and allows users to connect various >> cards to. By having a pseudo device we can interact with different SPI >> devices. > >> Yes by default nothing is connected and so there is nothing to talk to. >> However, this does enable us to do SPI loopback testing for example. > >> So I am wondering if it would be acceptable to having some generic dummy >> device-tree compatible string for this? I guess it does not need to be Tegra >> specific. > > I understand what he's trying to accomplish, it's the same thing as > what everyone who wants to put a raw spidev compatible in their DT is > trying to do. The way to do this would be something like a DT overlay > that describes whatever is actually connected, or just customise the DT > locally. We could certainly use an overlay, but how do we handle the kernel side? My understanding is that per patch 3/3 we need to reference a compatible string the kernel is aware of. I guess we could use an existing one, but feels like a massive hack. It would be nice if there is something generic we can use for this like 'linux,spidev'. I see that ACPI has something and it does print a warning that this should not be used in production systems. Jon
On Wed, Nov 27, 2024 at 05:24:01PM +0000, Jon Hunter wrote: > On 27/11/2024 16:09, Mark Brown wrote: > > I understand what he's trying to accomplish, it's the same thing as > > what everyone who wants to put a raw spidev compatible in their DT is > > trying to do. The way to do this would be something like a DT overlay > > that describes whatever is actually connected, or just customise the DT > > locally. > We could certainly use an overlay, but how do we handle the kernel side? My > understanding is that per patch 3/3 we need to reference a compatible string > the kernel is aware of. I guess we could use an existing one, but feels like > a massive hack. It would be nice if there is something generic we can use > for this like 'linux,spidev'. > I see that ACPI has something and it does print a warning that this should > not be used in production systems. You can put 'spidev' in as the compatible and get the warning, we don't require specific compatibles if the Linux device ID is good enough. If you genuinely just have bare wires you're probably able to cope with the warning. If something is actually connected you should use the compatible for whatever that is, if spidev makes sense for it then that'd be OK to add to spidev.
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 88abb5c174f3..c8b39a513fc5 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -293,6 +293,8 @@ properties: - national,lm85 # I2C ±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator - national,lm92 + # NVIDIA Tegra SPIDEV Controller device + - nvidia,tegra-spidev # Nuvoton Temperature Sensor - nuvoton,w83773g # OKI ML86V7667 video decoder
Add DeviceTree schema for NVIDIA'S SPIDEV controller. The schema supports both master and slave modes for data transfer purposes. Specifies required properties: "compatible", "reg", and "spi-max-frequency". Signed-off-by: Vishwaroop A <va@nvidia.com> --- Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ 1 file changed, 2 insertions(+)