Message-ID: <58d1487a-fd3b-4b31-a133-3181359e0c61@opensynergy.com>
Date: Tue, 5 Mar 2024 18:54:06 +0100
From: Harald Mommer <harald.mommer@...nsynergy.com>
To: Haixu Cui <quic_haixcui@...cinc.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,

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
>
>
-- 
Dipl.-Ing. Harald Mommer
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

Phone:  +49 (30) 60 98 540-0 <== Zentrale
Fax:    +49 (30) 60 98 540-99
E-Mail: harald.mommer@...nsynergy.com

www.opensynergy.com

Handelsregister: Amtsgericht Charlottenburg, HRB 108616B
Geschäftsführer/Managing Director: Regis Adjamah

Powered by blists - more mailing lists