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

[Andrii Tseglytskyi <andrii.tseglytskyi@xxxxxxxxxxxxxxx>]

Hi Jan,

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.

>> 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.

Regards,
Andrii


-- 

Andrii Tseglytskyi | Embedded Dev
GlobalLogic
www.globallogic.com

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