Message-ID: <a8e5463f-787b-44c3-842f-c2d7f703d26e@quicinc.com>
Date: Wed, 6 Mar 2024 15:48:14 +0800
From: Haixu Cui <quic_haixcui@...cinc.com>
To: Harald Mommer <harald.mommer@...nsynergy.com>
CC: <quic_ztu@...cinc.com>, Matti Moell <Matti.Moell@...nsynergy.com>,
        "Mikhail Golubev" <Mikhail.Golubev@...nsynergy.com>,
        <linux-kernel@...r.kernel.org>, <linux-spi@...r.kernel.org>,
        Viresh Kumar
	<viresh.kumar@...aro.org>,
        "Mark Brown" <broonie@...nel.org>
Subject: Re: [virtio-dev] Re: [RFC PATCH v3 3/3] SPI: Add virtio SPI driver. -
 Correction

Hello Harald,

     In current driver, spi_new_device is used to instantiate the virtio 
SPI device, spidevX.Y is created manually, this way seems not flexible 
enough. Besides it's not easy to set the spi_board_info properly.

     Viresh Kumar has standardized the device tree node format for 
virtio-i2c and virtio-gpio:

 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/gpio/gpio-virtio.yaml

     In this way, the driver is unified, board customization only 
depends on the device-tree node. It's easy to bring up spidev automatically.

     Look forward to your opinions. Thanks a lot.

Haixu Cui


On 3/6/2024 1:54 AM, Harald Mommer wrote:
> Hello,
> 
> looked again at my tinny setup and I've to add a small correction.
> 
> It's not the way that I've no udev at all there. What is in place there 
> is busybox mdev.
> 
> Relevant part of /etc/init.d/rcS:
> 
> #!/bin/sh
> mount -t proc none /proc
> mount -t sysfs none /sys
> depmod
> modprobe spi-virtio
> mdev -s
> mdev -d
> 
> If I kill the "mdev -d" process my small script below does not make the 
> /dev/spidev0.0 device node appear any more. Of course not, there must be 
> some user mode process which does the job in the device directory.
> 
> Regards
> Harald Mommer
> 
> On 05.03.24 11:57, Harald Mommer wrote:
>> Hello,
>>
>> I took next/stable as base giving the exact tag/sha of the current 
>> next/stable so that it's known what was used as base version even when 
>> next/stable moves. The ordinary next tags are currently not of best 
>> quality, gets better, therefore next/stable now. We were on v6.8-rc7 
>> yesterday with next/stable.
>>
>> VMM is qemu for the driver you have. But it's a specially modified 
>> qemu which allows that we use our proprietary virtio SPI device as 
>> backend.
>>
>> Proprietary virtio SPI device is started first, this is an own user 
>> process in our architecture. Subsequently the special internal qemu 
>> version is started. The virtio SPI driver is compiled as a module and 
>> inserted manually by a startup script by "modprobe spi-virtio". The 
>> driver goes live immediately.
>>
>> In this simple setup I do not have udev rules (no service supporting 
>> udev => no rules) so no /dev/spidevX.Y automatically after the driver 
>> went live. What I'm using to test the latest driver before sending it 
>> to the mailing lists is really a naked kernel + a busybox running in a 
>> ramdisk. The udev rule I've sent are used on some more complete setup 
>> on real hardware.
>>
>> So without udev I have to bring this device up manually:
>>
>> In /etc/spidev-up.sh there is a script tp bring up /dev/spidev0.0 
>> manually:
>>
>> #!/bin/sh
>> SPIDEV=spi0.0
>> echo spidev > /sys/bus/spi/devices/$SPIDEV/driver_override
>> echo $SPIDEV > /sys/bus/spi/drivers/spidev/bind
>>
>> Afterwards there is /dev/spidev0.0.
>>
>> In linux/tools/spi there are spidev_test.c and spidev_fdx.c. Those 
>> (somewhat hacked locally, and I mean "hacked" to be able to test 
>> somewhat more) are used to play around with /dev/spidev0.0.
>>
>> I can do this on my Laptop which has no underlying SPI hardware which 
>> could be used as a backend for the virtio SPI device. The proprietary 
>> virtio SPI device has a test mode to support this. Using this test 
>> mode the driver does not communicate with a real backend SPI device 
>> but does an internal simulation. For example, if I do a half duplex 
>> read it always gives back the sequence 01 02 03 ...
>>
>> For full duplex it gives back what has been read but with letter case 
>> changed, in loopback mode it gives back exactly what was sent. With 
>> this test mode I could develop a driver and parts of the device 
>> (device - real backend communication to an actual SPI device) on a 
>> board which had no user space /dev/spiX.Y available which could have 
>> served as backend for the virtio SPI device on the host.
>>
>> Slightly different module version is tested on real hardware with the 
>> virtio SPI device not in test mode. "Tested on hardware" means that 
>> device + module work for our special use case (some hardware device 
>> using 8 bit word size) and the project team for which device and 
>> driver have been made did until now not complain.
>>
>> Regards
>> Harald Mommer
>>
>> On 05.03.24 08:46, Haixu Cui wrote:
>>> Hello Harald,
>>>
>>> Thank you for your detailed expatiation. To my knowledge, you took 
>>> Vanilla as the front-end, and VMM is QEMU. Can you please explain 
>>> further how do you test the SPI transfer without the Vanilla 
>>> userspace interface? Thanks again.
>>>
>>> Haixu Cui
>>
>>

Powered by blists - more mailing lists