On 01/13/2017 12:51 PM, Ville Syrjälä wrote:
On Fri, Jan 13, 2017 at 12:34:54PM +0200, Jarkko Nikula wrote:
On 01/13/2017 11:26 AM, Ville Syrjälä wrote:
It also feels quite hand wavy since the punit could do whatever at
any time AFAIK. Eg. if there's some thermal event or something the
punit might kick into action. So trying to protect this from the OS
side might not be able to avoid these problems entirely. It feels like
there really should be some kind of shared hardware/firmware mutex
with the punit to arbitrate access to the i2c bus.
There is an HW semaphore for I2C access. It is implemented in
drivers/i2c/busses/i2c-designware-baytrail.c and another set from Hans
is adding support for Cherrytrail into it.
Then why do we need anything else?
From this patch: "The punit on baytrail / cherrytrail systems is not
only accessed through the iosf_mbi functions, but also by the i915 code."
--
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
