Re: [Xen-devel] [RFC PATCH 11/13] cpufreq: add xen-cpufreq driver

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.10.14 at 15:38, <andrii.tseglytskyi@xxxxxxxxxxxxxxx> wrote:
> On Mon, Oct 13, 2014 at 3:28 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 13.10.14 at 13:59, <oleksandr.dmytryshyn@xxxxxxxxxxxxxxx> wrote:
>>> There are few reasons to not implement PV I2C in Xen:
>>> 1. It is difficult to implement concurrent access to I2C controller
>>
>> I already outlined how I think this could be made work.
>>
> 
> It should be noticed that sometimes I2C transactions require platform
> specific IPs.
> For example OMAP3+ platforms contain HW spinlock IP (which is a real
> HW module with its own clocks).
> Each i2c_send call must acquire this HW spinlock. And this is
> something we can't implement in Xen hypervisor.

Do you really mean "can't", or rather "don't want to"? It's very
hard for me to imagine something that absolutely can't be done
in the hypervisor.

>>> 2. I2C code is closely integrated to the Linux kernel code and
>>> I2C driver has lots of levels of abstraction. It is very difficult to cut
>>> I2C code from kernel and make kernel working without it. Kernel folks
>>> will not take this solution to the mainline.
>>> 3. Implementation of the  I2C driver in Xen will rather be more complex
>>> than simple.
>>
>> Others seem to be of different opinion.
>>
>>> 4. There will be overhead to do all steps above.
>>
>> Not sure what you mean here.
>>
> 
> I see the following concern here:
> 
> It should be noticed that almost all peripheral uses I2C bus.
> For example on our platform touchscreen uses I2C (jacinto6 evm board).
> Each scroll produces about 50 I2C commands.
> It means 50 hypercalls in the line to hypervisor, and 100 context
> switches between hypervisor and dom0.
> 
> Taking in account all the above - we should think twice about even
> simple I2C driver which may control voltage regulator.

Leaving aside that there are no real context switches between a
domain and the hypervisor (only domains, or more precisely vCPU-s,
get context switched), I'm not sure we need to be worried by these
numbers. Whether they're problematic depends significantly on the
time a full I2C command takes to issue (and perhaps complete). And
then I'm sure you're aware that hypercalls can be batched, so as
long as not every of these 50 commands depends on results from
the immediately preceding one, the hypercall cost can certainly be
amortized to a certain degree.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel