Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 24 Mar 2021 11:39:07 +0530
From:   Viresh Kumar <viresh.kumar@linaro.org>
To:     Jie Deng <jie.deng@intel.com>
Cc:     linux-i2c@vger.kernel.org,
        virtualization@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org, mst@redhat.com, wsa@kernel.org,
        jasowang@redhat.com, wsa+renesas@sang-engineering.com,
        andriy.shevchenko@linux.intel.com, conghui.chen@intel.com,
        arnd@arndb.de, kblaiech@mellanox.com,
        jarkko.nikula@linux.intel.com, Sergey.Semin@baikalelectronics.ru,
        rppt@kernel.org, loic.poulain@linaro.org, tali.perry1@gmail.com,
        u.kleine-koenig@pengutronix.de, bjorn.andersson@linaro.org,
        yu1.wang@intel.com, shuo.a.liu@intel.com, stefanha@redhat.com,
        pbonzini@redhat.com
Subject: Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver
Message-ID: <20210324060907.nwilmghg2xcdz7nv@vireshk-i7>
References: <226a8d5663b7bb6f5d06ede7701eedb18d1bafa1.1616493817.git.jie.deng@intel.com>
 <20210324042046.idkctj2t7cxi53jf@vireshk-i7>
 <70908366-c270-848e-0be3-c85fec7958ec@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <70908366-c270-848e-0be3-c85fec7958ec@intel.com>
User-Agent: NeoMutt/20180716-391-311a52
Precedence: bulk

On 24-03-21, 14:05, Jie Deng wrote:
> For simplicity, the original patch sent only 1 message to vq each time . I
> changed the way to send

I missed those earlier discussions :)

> a batch of requests in one time in order to improve efficiency according to
> Jason' suggestion.

I agree.

> As we discussed in the previous emails, the device can raise interrupt when
> some requests are still not completed
> 
> though this is not a good operation.? In this case, the remaining requests
> in the vq will be ignored and
> 
> the i2c_algorithm. master_xfer will return 1 for your example. I will
> clarify this in the specs.

Right, this needs to be clarified that the receiver shall generate the interrupt
only once the virtqueue is empty, not in the middle of it.

Or, now that I think about it a bit more, another thing we can do here is see if
virtqueue_get_buf() returns NULL, if it does then we should keep expecting more
messages as it may be early interrupt. What do you say ?


-- 
viresh