On Fri, Jan 13, 2017 at 01:12:15PM +0200, Jarkko Nikula wrote: > 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." I don't see how that's relevant at all. Multiple things accessing the punit concurrently should be perfectly fine as long as they don't frob the same registers. -- Ville Syrjälä Intel OTC -- 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
