On Fri, Mar 19, 2021 at 7:35 AM Viresh Kumar wrote:
>
> On 19-03-21, 14:29, Jie Deng wrote:
> > I also see example drivers/i2c/busses/i2c-xiic.c. Some people might think
> > this way is more clearer than
> >
> > updating each member in probe. Basically, I think it's just a matter of
> > personal p
On 2021/3/19 13:53, Viresh Kumar wrote:
On 16-03-21, 18:35, Jie Deng wrote:
+++ b/drivers/i2c/busses/i2c-virtio.c
+static int virtio_i2c_send_reqs(struct virtqueue *vq,
+ struct virtio_i2c_req *reqs,
+ struct i2c_msg *msgs, int nr)
+{
On 2021/3/19 14:35, Viresh Kumar wrote:
On 19-03-21, 14:29, Jie Deng wrote:
I also see example drivers/i2c/busses/i2c-xiic.c. Some people might think
this way is more clearer than
updating each member in probe. Basically, I think it's just a matter of
personal preference which doesn't
Memory
On 19-03-21, 14:29, Jie Deng wrote:
> I also see example drivers/i2c/busses/i2c-xiic.c. Some people might think
> this way is more clearer than
>
> updating each member in probe. Basically, I think it's just a matter of
> personal preference which doesn't
Memory used by one instance of struct i2c
On 2021/3/19 13:40, Viresh Kumar wrote:
On 19-03-21, 13:31, Jie Deng wrote:
On 2021/3/19 11:54, Viresh Kumar wrote:
On 18-03-21, 15:52, Arnd Bergmann wrote:
Allowing multiple virtio-i2c controllers in one system, and multiple i2c
devices attached to each controller is clearly something that
On 16-03-21, 18:35, Jie Deng wrote:
> +++ b/drivers/i2c/busses/i2c-virtio.c
> +static int virtio_i2c_send_reqs(struct virtqueue *vq,
> + struct virtio_i2c_req *reqs,
> + struct i2c_msg *msgs, int nr)
> +{
> + struct scatterlist *sgs[3], ou
On 19-03-21, 13:31, Jie Deng wrote:
>
> On 2021/3/19 11:54, Viresh Kumar wrote:
> > On 18-03-21, 15:52, Arnd Bergmann wrote:
> > > Allowing multiple virtio-i2c controllers in one system, and multiple i2c
> > > devices attached to each controller is clearly something that has to work.
> > Good.
> >
On 2021/3/19 11:54, Viresh Kumar wrote:
On 18-03-21, 15:52, Arnd Bergmann wrote:
Allowing multiple virtio-i2c controllers in one system, and multiple i2c
devices attached to each controller is clearly something that has to work.
Good.
I don't actually see a limitation though. Viresh, what i
On 18-03-21, 15:52, Arnd Bergmann wrote:
> Allowing multiple virtio-i2c controllers in one system, and multiple i2c
> devices attached to each controller is clearly something that has to work.
Good.
> I don't actually see a limitation though. Viresh, what is the problem
> you see for having multi
On Thu, Mar 18, 2021 at 3:42 PM Enrico Weigelt, metux IT consult
wrote:
>
> On 16.03.21 08:44, Viresh Kumar wrote:
>
> > FWIW, this limits this driver to support a single device ever. We
> > can't bind multiple devices to this driver now. Yeah, perhaps we will
> > never be required to do so, but w
On 16.03.21 08:44, Viresh Kumar wrote:
FWIW, this limits this driver to support a single device ever. We
can't bind multiple devices to this driver now. Yeah, perhaps we will
never be required to do so, but who knows.
Actually, I believe multiple devices really should be possible.
The major b
On 16-03-21, 18:35, Jie Deng wrote:
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> +struct virtio_i2c {
> + struct virtio_device *vdev;
> + struct completion completion;
> + struct i2c_adapter *adap;
> + struct mutex lock;
> + struct virtqueue
On 16-03-21, 18:35, Jie Deng wrote:
> +static struct i2c_adapter virtio_adapter = {
> + .owner = THIS_MODULE,
> + .name = "Virtio I2C Adapter",
> + .class = I2C_CLASS_DEPRECATED,
> + .algo = &virtio_algorithm,
> +};
> +
> +static int virtio_i2c_probe(struct virtio_device *vdev)
> +{
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
The device specification can be found on
https://lists.oasis-open.org/archives/virtio-comment/202101/msg8.html.
By followi
14 matches
Mail list logo
