[Qemu-devel] Trying to write a new device / virtio-i2c ?

[Qemu-devel] Trying to write a new device / virtio-i2c ?

[Alex David]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

Hello,

I'm new to QEMU and kinda new to driver & QEMU programming in general, so
please excuse my questions...

I want to develop a new QEMU i2c device (qemu x86), that would get/send
data to an application running on the guest. Thing is : I need these data
onto the host, as a daemon will send/get the same kind of data to the guest.

After reading code, documentation and available things, I've been trying to
write something like a "virtio-i2c" : I wrote a virtio-i2c module for my
kernel (I used some examples from virtio-pci and virtio-console), it seems
that it created a "i2c-1" device in /dev,

My device that I launch with QEMU (-chardev
socket,path=/tmp/test0,server,nowait,id=bob -device virtio-i2c,chardev=bob)
doesn't seem to be recognized by the kernel driver : my probe function
doesn't run.

I might have missed something : how does a kernel driver uses the "probe"
function with a QEMU device ?

Hoping that it doesn't look too confused...

[-- Attachment #2: Type: text/html, Size: 1187 bytes --]

Re: [Qemu-devel] Trying to write a new device / virtio-i2c ?

[Stefan Hajnoczi]

On Thu, Feb 13, 2014 at 02:26:16PM +0100, Alex David wrote:
> I'm new to QEMU and kinda new to driver & QEMU programming in general, so
> please excuse my questions...
> 
> I want to develop a new QEMU i2c device (qemu x86), that would get/send
> data to an application running on the guest. Thing is : I need these data
> onto the host, as a daemon will send/get the same kind of data to the guest.
> 
> After reading code, documentation and available things, I've been trying to
> write something like a "virtio-i2c" : I wrote a virtio-i2c module for my
> kernel (I used some examples from virtio-pci and virtio-console), it seems
> that it created a "i2c-1" device in /dev,
> 
> My device that I launch with QEMU (-chardev
> socket,path=/tmp/test0,server,nowait,id=bob -device virtio-i2c,chardev=bob)
> doesn't seem to be recognized by the kernel driver : my probe function
> doesn't run.
> 
> I might have missed something : how does a kernel driver uses the "probe"
> function with a QEMU device ?

Virtio devices have a device ID which the Linux guest virtio bus code
uses to probe the right driver.

For example:
$ grep virt /lib/modules/3.12.9-301.fc20.x86_64/modules.alias
alias virtio:d00000004v* virtio_rng
alias virtio:d00000003v* virtio_console
alias virtio:d00000002v* virtio_blk
alias virtio:d00000008v* virtio_scsi
alias virtio:d00000001v* virtio_net

This is how udev knows to load the right kernel modules.  If you
compiled and installed your kernel modules correctly then it should be
automatically loaded.

If you want to dig deeper into how Linux driver loading works, see
drivers/virtio/virtio.c:virtio_bus.

> Hoping that it doesn't look too confused...

I'm confused about what you're trying to achieve.  If you want
host<->guest communication then the starting point is virtio-serial.
Maybe even the QEMU Guest Agent which can use virtio-serial.

If you want "real" I2C you should probably not use virtio.

Stefan

Re: [Qemu-devel] Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 13/02/2014 14:26, Alex David ha scritto:
> After reading code, documentation and available things, I've been trying
> to write something like a "virtio-i2c" : I wrote a virtio-i2c module for
> my kernel (I used some examples from virtio-pci and virtio-console), it
> seems that it created a "i2c-1" device in /dev,
>
> My device that I launch with QEMU (-chardev
> socket,path=/tmp/test0,server,nowait,id=bob -device
> virtio-i2c,chardev=bob) doesn't seem to be recognized by the kernel
> driver : my probe function doesn't run.

i2c is a bus, not directly a device.  Do you want to pass an entire 
adapter down to the guest?  Or just a slave?

QEMU has i2c emulation but it is bus-based, so you need one device per 
slave + 1 for the adapter. x86 already has an I2C bus (actually it's 
SMBus) that you may be able to use.  So you probably want something like

     -object i2c-linux,file=/dev/i2c-1,id=i2c-backend
     -device i2c-host,backend=i2c-backend,hostaddr=0x40,address=0x40
     -device i2c-host,backend=i2c-backend,hostaddr=0x50,address=0x50

and so on.  i2c-linux would be the object issuing ioctls to /dev/i2c-1, 
multiplexing access to the device for all the i2c-host devices.

If the default I2C bus is not good, I suggest that you write QEMU code 
to emulate an USB-I2C bridge, rather than write a virtio one.  It is not 
a performance-intensive path in all likelihood, and you won't have to 
write driver code for the guest.

Another alternative is to support the kernel's I2C-over-parallel 
interface.  You can then write a character device backend that maps 
/dev/i2c-1 read/write/ioctl to the parallel port interface that the 
kernel expects use it with a parallel port device.  It would be used 
like this:

     -chardev i2c-linux,file=/dev/i2c-1,id=i2c-backend
     -device parallel,chrdev=i2c-backend

Paolo

Re: [Qemu-devel] Trying to write a new device / virtio-i2c ?

[Andreas Färber]

Am 14.02.2014 16:58, schrieb Paolo Bonzini:
> Il 13/02/2014 14:26, Alex David ha scritto:
>> After reading code, documentation and available things, I've been trying
>> to write something like a "virtio-i2c" : I wrote a virtio-i2c module for
>> my kernel (I used some examples from virtio-pci and virtio-console), it
>> seems that it created a "i2c-1" device in /dev,
>>
>> My device that I launch with QEMU (-chardev
>> socket,path=/tmp/test0,server,nowait,id=bob -device
>> virtio-i2c,chardev=bob) doesn't seem to be recognized by the kernel
>> driver : my probe function doesn't run.
> 
> i2c is a bus, not directly a device.  Do you want to pass an entire
> adapter down to the guest?  Or just a slave?
> 
> QEMU has i2c emulation but it is bus-based, so you need one device per
> slave + 1 for the adapter. x86 already has an I2C bus (actually it's
> SMBus) that you may be able to use.  So you probably want something like
> 
>     -object i2c-linux,file=/dev/i2c-1,id=i2c-backend
>     -device i2c-host,backend=i2c-backend,hostaddr=0x40,address=0x40
>     -device i2c-host,backend=i2c-backend,hostaddr=0x50,address=0x50
> 
> and so on.  i2c-linux would be the object issuing ioctls to /dev/i2c-1,
> multiplexing access to the device for all the i2c-host devices.

While that is certainly possible in case host passthrough was desired,
maybe virtio was mixed up with VFIO? For now I believe it is PCI-only
and there was work on platform devices at KVM Forum 2013; for s390x a
ccw backend may be needed, so maybe it's possible to extend vfio for I2C?

If however it's just about QEMU reading data from a daemon on the host,
a simple slave device might do and is then independent of host I2C devices.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 14/02/2014 17:31, Andreas Färber ha scritto:
> While that is certainly possible in case host passthrough was desired,
> maybe virtio was mixed up with VFIO?

I don't think so, VFIO is mostly about IOMMUs and protecting from DMA.

Paolo

Re: [Qemu-devel] Trying to write a new device / virtio-i2c ?

[Alex David]

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

Thanks for all your answers.

I understand that what I want to achieve seemed pretty confused. I will try
to clarify :

On real hardware, I have an I2C device used to get temperatures, pressure
etc... and it works on x86 and there were no QEMU virtualized hardware
corresponding.

I don't really need to simulate the I2C hardware in QEMU. Indeed, there are
few of them just sending regular i2c data. For some tests, I want to be
able to send/receive these ones from my daemon on the host. After some
researches, what I was thinking about was :

1) Use virtio-serial and write an I2C driver (guest kernel) that would
give/take data to/from i2c-1 and read/write to vportp0... Seemed a bit
ugly, so I wanted to try something else.

2) Write virtio-i2c (using i2c-driver and virtio kernel basics) that would
register, for example, i2c-1 and get/send data from my guest app, and use
virtio to send these data to host.

What I have done for now : I used virtio-serial / virtio-console in linux
kernel and inspired from virtio-pci to try to registers these "vport0pX" as
i2c-1, i2c-2 etc... and as i2c devices. I also wrote a virtio-i2c QEMU-side
to register as this hardware using virtio-i2c drivers. I think my
understanding of the architecture is probably not complete, as it seems
that this QEMU device doesn't automatically registers as a "virtio-i2c"
hardware that would launch my guest kernel driver.
My printk's in the "probe" are not printed. My driver is then never used.

My questions were then :
- My solution might be a bit complicated assuming I don't have that much
knowledge in the architecture (however I'm interested into learning...)
- Are there solutions that seems more adapted to my case ? Like using
USB-I2C bridge ?


2014-02-14 17:45 GMT+01:00 Paolo Bonzini <pbonzini@redhat.com>:

> Il 14/02/2014 17:31, Andreas Färber ha scritto:
>
>  While that is certainly possible in case host passthrough was desired,
>> maybe virtio was mixed up with VFIO?
>>
>
> I don't think so, VFIO is mostly about IOMMUs and protecting from DMA.
>
> Paolo
>

[-- Attachment #2: Type: text/html, Size: 2773 bytes --]

Re: [Qemu-devel] Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 17/02/2014 09:35, Alex David ha scritto:
> - Are there solutions that seems more adapted to my case ? Like using
> USB-I2C bridge ?

 From an upstream point of view, a host passthrough device pair (one 
object talking to /dev/i2c-N on the host, and one device per sensor 
talking to the other object) would be the best.

But if you can make I2C-over-parallel work, that would also be 
interesting.  And not much new code to write: all you need to parse the 
bitbanging I2C protocol is already in hw/i2c/bitbang_i2c.c.

Paolo

[Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

2014-02-17 10:19 GMT+01:00 Paolo Bonzini <pbonzini@redhat.com>:

> Il 17/02/2014 09:35, Alex David ha scritto:
>
>  - Are there solutions that seems more adapted to my case ? Like using
>> USB-I2C bridge ?
>>
>
> From an upstream point of view, a host passthrough device pair (one object
> talking to /dev/i2c-N on the host, and one device per sensor talking to the
> other object) would be the best.
>

i2c-N is on the guest, that's why I want to virtualize an i2c hardware on
QEMU. My idea was getting the data on a socket on the host => read these
data from my daemon. That's why virtio-serial seemed like a good thing to
use / adapt as i2c.

I'll look on the parallel solution, I don't think there's a
virtio-parallel, right ?

[-- Attachment #2: Type: text/html, Size: 1349 bytes --]

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 17/02/2014 10:38, Alex David ha scritto:
>
>     From an upstream point of view, a host passthrough device pair (one
>     object talking to /dev/i2c-N on the host, and one device per sensor
>     talking to the other object) would be the best.
>
>
> i2c-N is on the guest, that's why I want to virtualize an i2c hardware
> on QEMU. My idea was getting the data on a socket on the host => read
> these data from my daemon. That's why virtio-serial seemed like a good
> thing to use / adapt as i2c.
>
> I'll look on the parallel solution, I don't think there's a
> virtio-parallel, right ?

You do not need to use virtio at all costs.  Paravirtualization is just 
where existing hardware doesn't have the required performance or feature 
set.  If you don't use paravirtualization, you have the big advantage of 
not having to write a guest driver!

You have not answered my question.  Are you emulating a bunch of 
sensors/actuators?  Or do the sensors/actuators physically exist in the 
host?  So far I assumed the latter.

If that is not correct, and you just need to emulate a temperature 
sensor or something like that, there is already an I2C bus in the guest. 
  If you do "modprobe i2c-dev" in the guest you'll see it.  Just use 
"-device" and QEMU will attach the emulated sensor to that bus.

Something like USB-I2C is only needed if you need more than one I2C bus 
(e.g. because of two devices with the same address).  And parallel port 
I2C is probably useless for anything except passing through a host 
/dev/i2c-N to the guest.

Paolo

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 17/02/2014 11:01, Alex David ha scritto:
> I indeed don't use paravirtualization.

Virtio _is_ paravirtualization. :)

> I'm emulating a bunch of sensors/actuators.
>
> If I virtualize my sensors and attach them to the i2c-dev with -device,
> how do I get those data on the host then ?

It depends on your use case.

It could be that you can make them return a constant value.

Otherwise, you may want to use a chardev for that purpose, or finally a 
QOM (QEMU Object Model) property.  For example, add

CONFIG_TMP105=y

to default-configs/x86_64-softmmu.mak before building QEMU, then do the 
following (indented = in the guest):

$ x86_64-softmmu/qemu-system-x86_64 --enable-kvm ~/test2.img  -m 256 \
    -device tmp105,id=sensor,address=0x50 \
    -qmp unix:$HOME/qmp.sock,server,nowait
$ qmp/qom-list -s ~/qmp.sock /machine/peripheral/sensor
temperature
@parent_bus/
address
hotpluggable
realized
type
$ scripts/qmp/qmp-shell ~/qmp.sock
(QEMU) qom-get path=/machine/peripheral/sensor property=temperature
{u'return': 0}
(QEMU) qom-get path=sensor property=address
{u'return': 80}

     # modprobe i2c-dev
     # i2cget -y 0 0x50 0 w
     0x0000

(QEMU) qom-set path=sensor property=temperature value=20000
{u'return': {}}

     # i2cget -y 0 0x50 0 w
     0x0014

For this particular sensor, you have to swap the two bytes and the 
result is 8.8 fixed-point.

Paolo

> Thanks for your help. As you may see, I'm not that experienced in
> QEMU/Linux kernel.

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

2014-02-17 11:38 GMT+01:00 Paolo Bonzini <pbonzini@redhat.com>:

> Il 17/02/2014 11:01, Alex David ha scritto:
>
>  I indeed don't use paravirtualization.
>>
>
> Virtio _is_ paravirtualization. :)
>
>
Ok, now that seems much more understandable... I missed that point ha.



>
>  I'm emulating a bunch of sensors/actuators.
>>
>> If I virtualize my sensors and attach them to the i2c-dev with -device,
>> how do I get those data on the host then ?
>>
>
> It depends on your use case.
>
> It could be that you can make them return a constant value.
>
> Otherwise, you may want to use a chardev for that purpose, or finally a
> QOM (QEMU Object Model) property.  For example, add
>
> CONFIG_TMP105=y
>
> to default-configs/x86_64-softmmu.mak before building QEMU, then do the
> following (indented = in the guest):
>
> $ x86_64-softmmu/qemu-system-x86_64 --enable-kvm ~/test2.img  -m 256 \
>    -device tmp105,id=sensor,address=0x50 \
>    -qmp unix:$HOME/qmp.sock,server,nowait
> $ qmp/qom-list -s ~/qmp.sock /machine/peripheral/sensor
> temperature
> @parent_bus/
> address
> hotpluggable
> realized
> type
> $ scripts/qmp/qmp-shell ~/qmp.sock
> (QEMU) qom-get path=/machine/peripheral/sensor property=temperature
> {u'return': 0}
> (QEMU) qom-get path=sensor property=address
> {u'return': 80}
>
>     # modprobe i2c-dev
>     # i2cget -y 0 0x50 0 w
>     0x0000
>
> (QEMU) qom-set path=sensor property=temperature value=20000
> {u'return': {}}
>
>     # i2cget -y 0 0x50 0 w
>     0x0014
>
> For this particular sensor, you have to swap the two bytes and the result
> is 8.8 fixed-point.
>
> Paolo
>
>
>  Thanks for your help. As you may see, I'm not that experienced in
>> QEMU/Linux kernel.
>>
>
>
Ok, I'm gonna try these things. I might try to use a chardev also. Thanks
for your help !

[-- Attachment #2: Type: text/html, Size: 3012 bytes --]

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

[-- Attachment #1: Type: text/plain, Size: 3042 bytes --]

>
>
>
>>
>>  I'm emulating a bunch of sensors/actuators.
>>>
>>> If I virtualize my sensors and attach them to the i2c-dev with -device,
>>> how do I get those data on the host then ?
>>>
>>
>> It depends on your use case.
>>
>> It could be that you can make them return a constant value.
>>
>> Otherwise, you may want to use a chardev for that purpose, or finally a
>> QOM (QEMU Object Model) property.  For example, add
>>
>> CONFIG_TMP105=y
>>
>> to default-configs/x86_64-softmmu.mak before building QEMU, then do the
>> following (indented = in the guest):
>>
>> $ x86_64-softmmu/qemu-system-x86_64 --enable-kvm ~/test2.img  -m 256 \
>>    -device tmp105,id=sensor,address=0x50 \
>>    -qmp unix:$HOME/qmp.sock,server,nowait
>> $ qmp/qom-list -s ~/qmp.sock /machine/peripheral/sensor
>> temperature
>> @parent_bus/
>> address
>> hotpluggable
>> realized
>> type
>> $ scripts/qmp/qmp-shell ~/qmp.sock
>> (QEMU) qom-get path=/machine/peripheral/sensor property=temperature
>> {u'return': 0}
>> (QEMU) qom-get path=sensor property=address
>> {u'return': 80}
>>
>>     # modprobe i2c-dev
>>     # i2cget -y 0 0x50 0 w
>>     0x0000
>>
>> (QEMU) qom-set path=sensor property=temperature value=20000
>> {u'return': {}}
>>
>>     # i2cget -y 0 0x50 0 w
>>     0x0014
>>
>> For this particular sensor, you have to swap the two bytes and the result
>> is 8.8 fixed-point.
>>
>> Paolo
>>
>>
>>  Thanks for your help. As you may see, I'm not that experienced in
>>> QEMU/Linux kernel.
>>>
>>
>>
> Ok, I'm gonna try these things. I might try to use a chardev also. Thanks
> for your help !
>


I've tried using tmp105. As my linux isn't 64bits, i'm using
qemu-system-i386... It crashes my computer when I use it with my linux
image (it's a debian .qcow2..., easy to do some tests...).

I will most probably need a chardev anyways, I will need to read/write data
when I want to. I'm gonna be annoying and ask another basic question : I
wrote this in my i2c_device_test.c (QEMU device) :

static const TypeInfo mydevice_i2c_type_info = {
    .name            = TYPE_MYDEVICE_I2C,
    .parent            = TYPE_I2C_SLAVE,
    .instance_size    = sizeof(MYDEVICEI2CState),
    .instance_init    = MYDEVICE_i2c_init,
    .class_init        = mydevice_i2c_class_init,
};

I will be able to add a chardev using the properties, right ?

static void mydevice_i2c_class_init(ObjectClass *klass, void *data)
{
    printf("Test init2\n");

    I2CSlaveClass *sc = I2C_SLAVE_CLASS(klass);
    DeviceClass *dc = DEVICE_CLASS(klass);

    sc->init = mydevice_i2c_init;
    sc->event = mydevice_i2c_event;
    sc->recv = mydevice_i2c_recv;
    sc->send = mydevice_i2c_send;

    dc->vmsd = &mydevice_i2c_vmstate;
    dc->props = mydevice_i2c_properties;
    dc->realize = mydevice_i2c_realize;
}

Does this seems ok for you ? So far, I understood the "props" are needed
for when I'm gonna declare the device at QEMU launch.
I am not sure if it's needed (my i2c-0 should be created anyways), but in
that case, how do I "plug" it on my socket on the host ?

Thanks !

[-- Attachment #2: Type: text/html, Size: 4454 bytes --]

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 17/02/2014 14:11, Alex David ha scritto:
> I've tried using tmp105. As my linux isn't 64bits, i'm using
> qemu-system-i386... It crashes my computer when I use it with my linux
> image (it's a debian .qcow2..., easy to do some tests...).

You mean crashes your host?

> I will most probably need a chardev anyways, I will need to read/write
> data when I want to.

Depends on how much data.  If it's just one or two ints, like tmp105, 
QOM would work too.  qmp-shell talks to QEMU via a simple JSON protocol, 
and it has simple Python bindings too.

> static const TypeInfo mydevice_i2c_type_info = {
>     .name            = TYPE_MYDEVICE_I2C,
>     .parent            = TYPE_I2C_SLAVE,
>     .instance_size    = sizeof(MYDEVICEI2CState),
>     .instance_init    = MYDEVICE_i2c_init,
>     .class_init        = mydevice_i2c_class_init,
> };
>
> I will be able to add a chardev using the properties, right ?

Yes, using dc->props.

> Does this seems ok for you ? So far, I understood the "props" are needed
> for when I'm gonna declare the device at QEMU launch.
> I am not sure if it's needed (my i2c-0 should be created anyways), but
> in that case, how do I "plug" it on my socket on the host ?

Your device is not i2c-0.  i2c-0 is provided by the PC board.  Your 
device will get one address, e.g. 0x42, on the i2c bus.  You'll be able 
to access it with i2cget and i2cset using "0" as the bus address (for 
i2c-0) and 0x42 as the device address on bus 0.

So you'll indeed have to do something like "-chardev socket,id=foo 
-device myi2c,address=0x42,chr=foo" if you go for sockets, or just 
"-device myi2c,address=0x42" if you go for QOM.  The "chr" property 
should go into dc->props, while "address" is provided by the abstract 
class TYPE_I2C_SLAVE.

Paolo

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]

2014-02-17 14:19 GMT+01:00 Paolo Bonzini <pbonzini@redhat.com>:

> Il 17/02/2014 14:11, Alex David ha scritto:
>
>  I've tried using tmp105. As my linux isn't 64bits, i'm using
>> qemu-system-i386... It crashes my computer when I use it with my linux
>> image (it's a debian .qcow2..., easy to do some tests...).
>>
>
> You mean crashes your host?
>

Yes, my host crashes... I need to hard-reboot my computer.


>
>  I will most probably need a chardev anyways, I will need to read/write
>> data when I want to.
>>
>
> Depends on how much data.  If it's just one or two ints, like tmp105, QOM
> would work too.  qmp-shell talks to QEMU via a simple JSON protocol, and it
> has simple Python bindings too.
>
>
>  static const TypeInfo mydevice_i2c_type_info = {
>>     .name            = TYPE_MYDEVICE_I2C,
>>     .parent            = TYPE_I2C_SLAVE,
>>     .instance_size    = sizeof(MYDEVICEI2CState),
>>     .instance_init    = MYDEVICE_i2c_init,
>>     .class_init        = mydevice_i2c_class_init,
>> };
>>
>> I will be able to add a chardev using the properties, right ?
>>
>
> Yes, using dc->props.
>
>
>  Does this seems ok for you ? So far, I understood the "props" are needed
>> for when I'm gonna declare the device at QEMU launch.
>> I am not sure if it's needed (my i2c-0 should be created anyways), but
>> in that case, how do I "plug" it on my socket on the host ?
>>
>
> Your device is not i2c-0.  i2c-0 is provided by the PC board.  Your device
> will get one address, e.g. 0x42, on the i2c bus.  You'll be able to access
> it with i2cget and i2cset using "0" as the bus address (for i2c-0) and 0x42
> as the device address on bus 0.
>
> So you'll indeed have to do something like "-chardev socket,id=foo -device
> myi2c,address=0x42,chr=foo" if you go for sockets, or just "-device
> myi2c,address=0x42" if you go for QOM.  The "chr" property should go into
> dc->props, while "address" is provided by the abstract class TYPE_I2C_SLAVE.
>
> Paolo
>


That seems fairly easy.

But that leaves me with another problem as I now understand how I2C works
on linux... I, in fact, need at least 3 busses (for my at least 3 devices)
- so i2c-0, i2c-1, i2c-2 ... There are applications I can't change on the
guest and opening / writing / reading on i2c-0, i2c-1 etc...

Can I just declare these busses using i2c-dev ?

[-- Attachment #2: Type: text/html, Size: 3677 bytes --]

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 17/02/2014 14:32, Alex David ha scritto:
>
> But that leaves me with another problem as I now understand how I2C
> works on linux... I, in fact, need at least 3 busses (for my at least 3
> devices) - so i2c-0, i2c-1, i2c-2

So you cannot configure the three devices on the same bus, with three 
different addresses?

> ... There are applications I can't
> change on the guest and opening / writing / reading on i2c-0, i2c-1 etc...
>
> Can I just declare these busses using i2c-dev ?

If you need more than one bus, you need a new device exposing the I2C 
bus, besides the new sensor devices.  USB-I2C could be one such device.

Paolo

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

2014-02-17 15:30 GMT+01:00 Paolo Bonzini <pbonzini@redhat.com>:

> So you cannot configure the three devices on the same bus, with three
> different addresses?


Each sensor is different on the original hardware, they are connected on
different busses. As my guest apps are calling i2c-1, i2c-2, .... ,i2c-N
(and I can't change them), I will need to create those busses...


> If you need more than one bus, you need a new device exposing the I2C bus,
> besides the new sensor devices.  USB-I2C could be one such device.
>

So let me see if I understood well. USB-I2C (host QEMU device) seems a good
idea, I could normally do : qemu-system-i386 -device usb-I2c,chardev=foo
-device usb-i2c,chardev=bar -chardev
socket,path=/tmp/test0,server,nowait,id=foo -chardev
socket,path=/tmp/test1,server,nowait,id=bar.

I need a "USB-I2C guest kernel driver" that would register a bus (i2c-1 for
chardev foo, i2c-2 for chardev bar etc...), I guess ?

[-- Attachment #2: Type: text/html, Size: 1559 bytes --]

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 17/02/2014 16:33, Alex David ha scritto:
>     If you need more than one bus, you need a new device exposing the
>     I2C bus, besides the new sensor devices.  USB-I2C could be one such
>     device.
>
> So let me see if I understood well. USB-I2C (host QEMU device) seems a
> good idea, I could normally do : qemu-system-i386 -device
> usb-I2c,chardev=foo -device usb-i2c,chardev=bar -chardev
> socket,path=/tmp/test0,server,nowait,id=foo -chardev
> socket,path=/tmp/test1,server,nowait,id=bar.

Almost. For QOM:

     -device usb-i2c,id=usb-i2c-0
     -device i2c-my-sensor,address=0x48,bus=usb-i2c-0.0

For chardev:

     -device usb-i2c,id=usb-i2c-0
     -chardev socket,path=/tmp/test0,server,nowait,id=chr-foo-0
     -device i2c-my-sensor,address=0x48,bus=usb-i2c-0.0,chardev=chr-foo-0

Repeat for the other buses, replacing -0 with -1 and -2.

> I need a "USB-I2C guest kernel driver" that would register a bus (i2c-1
> for chardev foo, i2c-2 for chardev bar etc...), I guess ?

It exists already, drivers/i2c/busses/i2c-tiny-usb.c.

Paolo

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]

2014-02-17 17:11 GMT+01:00 Paolo Bonzini <pbonzini@redhat.com>:

> Il 17/02/2014 16:33, Alex David ha scritto:
>
>      If you need more than one bus, you need a new device exposing the
>>     I2C bus, besides the new sensor devices.  USB-I2C could be one such
>>     device.
>>
>> So let me see if I understood well. USB-I2C (host QEMU device) seems a
>> good idea, I could normally do : qemu-system-i386 -device
>> usb-I2c,chardev=foo -device usb-i2c,chardev=bar -chardev
>> socket,path=/tmp/test0,server,nowait,id=foo -chardev
>> socket,path=/tmp/test1,server,nowait,id=bar.
>>
>
> Almost. For QOM:
>
>     -device usb-i2c,id=usb-i2c-0
>     -device i2c-my-sensor,address=0x48,bus=usb-i2c-0.0
>
> For chardev:
>
>     -device usb-i2c,id=usb-i2c-0
>     -chardev socket,path=/tmp/test0,server,nowait,id=chr-foo-0
>     -device i2c-my-sensor,address=0x48,bus=usb-i2c-0.0,chardev=chr-foo-0
>
> Repeat for the other buses, replacing -0 with -1 and -2.
>
>
>  I need a "USB-I2C guest kernel driver" that would register a bus (i2c-1
>> for chardev foo, i2c-2 for chardev bar etc...), I guess ?
>>
>
> It exists already, drivers/i2c/busses/i2c-tiny-usb.c.
>

I'm now trying to write this new USB-I2C device, I look through some of the
code (dev-serial, dev-...), I used dev-serial code and removed the code
that wanted to declare a chardev (I don't need one to create my bus, right
?).

Now I'm wondering, how will be i2c-tiny-usb launched and declare a new
/dev/i2c-N, with my device. I found :

static struct usb_device_id i2c_tiny_usb_table [] = {
    { USB_DEVICE(0x0403, 0xc631) },   /* FTDI */
    { USB_DEVICE(0x1c40, 0x0534) },   /* EZPrototypes */
    { }                               /* Terminating entry */
};

So I figured my USB-I2C should register using these numbers ?

static const USBDesc desc_i2c = {
    .id = {
        .idVendor          = 0x0403,
        .idProduct         = 0xc631,
        .bcdDevice         = 0x0400,
        .iManufacturer     = STR_MANUFACTURER,
        .iProduct          = STR_PRODUCT_I2C,
        .iSerialNumber     = STR_SERIALNUMBER,
    },
    .full = &desc_device,
    .str  = desc_strings,
};

However, this doesn't work, after a $ qemu-system-i386
debian_wheezy_i386_standard.qcow2 -usb -device USB-I2C,id=usb-i2c-0, the
driver doesn't seem to be used (/sys/class/i2c-dev/i2c-0/name isn't for
it...), even if I modprobe i2c-tiny-usb...
The dmesg shows it doesn't go into the "probe" function.

What did I miss ?

[-- Attachment #2: Type: text/html, Size: 3591 bytes --]

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 18/02/2014 13:48, Alex David ha scritto:
>
> 2014-02-17 17:11 GMT+01:00 Paolo Bonzini <pbonzini@redhat.com
> <mailto:pbonzini@redhat.com>>:
>
>     Il 17/02/2014 16:33, Alex David ha scritto:
>
>             If you need more than one bus, you need a new device
>         exposing the
>             I2C bus, besides the new sensor devices.  USB-I2C could be
>         one such
>             device.
>
>         So let me see if I understood well. USB-I2C (host QEMU device)
>         seems a
>         good idea, I could normally do : qemu-system-i386 -device
>         usb-I2c,chardev=foo -device usb-i2c,chardev=bar -chardev
>         socket,path=/tmp/test0,server,__nowait,id=foo -chardev
>         socket,path=/tmp/test1,server,__nowait,id=bar.
>
>
>     Almost. For QOM:
>
>         -device usb-i2c,id=usb-i2c-0
>         -device i2c-my-sensor,address=0x48,__bus=usb-i2c-0.0
>
>     For chardev:
>
>         -device usb-i2c,id=usb-i2c-0
>         -chardev socket,path=/tmp/test0,server,__nowait,id=chr-foo-0
>         -device
>     i2c-my-sensor,address=0x48,__bus=usb-i2c-0.0,chardev=chr-__foo-0
>
>     Repeat for the other buses, replacing -0 with -1 and -2.
>
>
>         I need a "USB-I2C guest kernel driver" that would register a bus
>         (i2c-1
>         for chardev foo, i2c-2 for chardev bar etc...), I guess ?
>
>
>     It exists already, drivers/i2c/busses/i2c-tiny-usb.c.
>
>
> I'm now trying to write this new USB-I2C device, I look through some of
> the code (dev-serial, dev-...), I used dev-serial code and removed the
> code that wanted to declare a chardev (I don't need one to create my
> bus, right ?).
>
> Now I'm wondering, how will be i2c-tiny-usb launched and declare a new
> /dev/i2c-N, with my device. I found :
>
> static struct usb_device_id i2c_tiny_usb_table [] = {
>     { USB_DEVICE(0x0403, 0xc631) },   /* FTDI */
>     { USB_DEVICE(0x1c40, 0x0534) },   /* EZPrototypes */
>     { }                               /* Terminating entry */
> };
>
> So I figured my USB-I2C should register using these numbers ?
>
> static const USBDesc desc_i2c = {
>     .id = {
>         .idVendor          = 0x0403,
>         .idProduct         = 0xc631,
>         .bcdDevice         = 0x0400,
>         .iManufacturer     = STR_MANUFACTURER,
>         .iProduct          = STR_PRODUCT_I2C,
>         .iSerialNumber     = STR_SERIALNUMBER,
>     },
>     .full = &desc_device,
>     .str  = desc_strings,
> };
>
> However, this doesn't work, after a $ qemu-system-i386
> debian_wheezy_i386_standard.qcow2 -usb -device USB-I2C,id=usb-i2c-0, the
> driver doesn't seem to be used (/sys/class/i2c-dev/i2c-0/name isn't for
> it...), even if I modprobe i2c-tiny-usb...
> The dmesg shows it doesn't go into the "probe" function.
>
> What did I miss ?

I honestly don't know, you'll have to debug it.

Paolo

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Alex David]

[-- Attachment #1: Type: text/plain, Size: 3160 bytes --]

Ok, thank you very much for your help then. I'm gonna spend some time on
this.

If qemu-dev / you are interested in what I've done later, I'll send a new
mail.



2014-02-18 14:05 GMT+01:00 Paolo Bonzini <pbonzini@redhat.com>:

> Il 18/02/2014 13:48, Alex David ha scritto:
>
>>
>> 2014-02-17 17:11 GMT+01:00 Paolo Bonzini <pbonzini@redhat.com
>> <mailto:pbonzini@redhat.com>>:
>>
>>
>>     Il 17/02/2014 16:33, Alex David ha scritto:
>>
>>             If you need more than one bus, you need a new device
>>         exposing the
>>             I2C bus, besides the new sensor devices.  USB-I2C could be
>>         one such
>>             device.
>>
>>         So let me see if I understood well. USB-I2C (host QEMU device)
>>         seems a
>>         good idea, I could normally do : qemu-system-i386 -device
>>         usb-I2c,chardev=foo -device usb-i2c,chardev=bar -chardev
>>         socket,path=/tmp/test0,server,__nowait,id=foo -chardev
>>         socket,path=/tmp/test1,server,__nowait,id=bar.
>>
>>
>>
>>     Almost. For QOM:
>>
>>         -device usb-i2c,id=usb-i2c-0
>>         -device i2c-my-sensor,address=0x48,__bus=usb-i2c-0.0
>>
>>     For chardev:
>>
>>         -device usb-i2c,id=usb-i2c-0
>>         -chardev socket,path=/tmp/test0,server,__nowait,id=chr-foo-0
>>         -device
>>     i2c-my-sensor,address=0x48,__bus=usb-i2c-0.0,chardev=chr-__foo-0
>>
>>
>>     Repeat for the other buses, replacing -0 with -1 and -2.
>>
>>
>>         I need a "USB-I2C guest kernel driver" that would register a bus
>>         (i2c-1
>>         for chardev foo, i2c-2 for chardev bar etc...), I guess ?
>>
>>
>>     It exists already, drivers/i2c/busses/i2c-tiny-usb.c.
>>
>>
>> I'm now trying to write this new USB-I2C device, I look through some of
>> the code (dev-serial, dev-...), I used dev-serial code and removed the
>> code that wanted to declare a chardev (I don't need one to create my
>> bus, right ?).
>>
>> Now I'm wondering, how will be i2c-tiny-usb launched and declare a new
>> /dev/i2c-N, with my device. I found :
>>
>> static struct usb_device_id i2c_tiny_usb_table [] = {
>>     { USB_DEVICE(0x0403, 0xc631) },   /* FTDI */
>>     { USB_DEVICE(0x1c40, 0x0534) },   /* EZPrototypes */
>>     { }                               /* Terminating entry */
>> };
>>
>> So I figured my USB-I2C should register using these numbers ?
>>
>> static const USBDesc desc_i2c = {
>>     .id = {
>>         .idVendor          = 0x0403,
>>         .idProduct         = 0xc631,
>>         .bcdDevice         = 0x0400,
>>         .iManufacturer     = STR_MANUFACTURER,
>>         .iProduct          = STR_PRODUCT_I2C,
>>         .iSerialNumber     = STR_SERIALNUMBER,
>>     },
>>     .full = &desc_device,
>>     .str  = desc_strings,
>> };
>>
>> However, this doesn't work, after a $ qemu-system-i386
>> debian_wheezy_i386_standard.qcow2 -usb -device USB-I2C,id=usb-i2c-0, the
>> driver doesn't seem to be used (/sys/class/i2c-dev/i2c-0/name isn't for
>> it...), even if I modprobe i2c-tiny-usb...
>> The dmesg shows it doesn't go into the "probe" function.
>>
>> What did I miss ?
>>
>
> I honestly don't know, you'll have to debug it.
>
> Paolo
>

[-- Attachment #2: Type: text/html, Size: 4211 bytes --]

Re: [Qemu-devel] Fwd: Trying to write a new device / virtio-i2c ?

[Paolo Bonzini]

Il 18/02/2014 14:44, Alex David ha scritto:
> Ok, thank you very much for your help then. I'm gonna spend some time on
> this.
>
> If qemu-dev / you are interested in what I've done later, I'll send a
> new mail.

Yes, if you get the USB-I2C bridge to work, we'd be interested in 
including it in QEMU!

Paolo