Re: [PATCH 1/4] exynos4-is: Clear isp-i2c adapter power.ignore_children flag

Linus Walleij
2016-09-07T20:38:44Z

On Thu, Sep 1, 2016 at 1:47 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Thu, Sep 01, 2016 at 01:39:16PM +0200, Sylwester Nawrocki wrote:

>> Since commit 04f59143b571161d25315dd52d7a2ecc022cb71a
>> ("i2c: let I2C masters ignore their children for PM")
>> the power.ignore_children flag is set when registering an I2C
>> adapter. Since I2C transfers are not managed by the fimc-isp-i2c
>> driver its clients use pm_runtime_* calls directly to communicate
>> required power state of the bus controller.
>> However when the power.ignore_children flag is set that doesn't
>> work, so clear that flag back after registering the adapter.
>> While at it drop pm_runtime_enable() call on the i2c_adapter
>> as it is already done by the I2C subsystem when registering
>> I2C adapter.
>>
>> Cc: <stable@vger.kernel.org> # 4.7+
>> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>

I understand what the patch is doing but not this commit message.

What does it mean when you say "Since I2C transfers are not
managed by the fimc-isp-i2c driver its clients use pm_runtime_*
calls directly to communicate required power state of the bus
controller."?

I find it very hard to understand.

The intent of the commit is to decouple I2C slave devices'
runtime PM state from their parents, so say a gyroscope on an
I2C bus does not have to bring up it's host controller to be
active, for example it usually has an IRQ line to wake up
the driver and that will talk using I2C and the I2C traffic will
wake up the I2C master.

When I look at the driver it appears it is not even used for
I2C traffic, just to take the clocks up and down and make it
possible to manage a clock using runtime PM and interface
with the DT logic... so I guess since it's likely and odd one-off
and the driver is sufficiently weird anyways, it's fine to merge
this patch making it even weirder.

Maybe a sort of mock adapter type should actually be
created in the I2C core for these things so it can be handled
there but who am I to say.

Yours,
Linus Walleij