Re: [PATCH 1/8] OMAP: convert I2C driver to PM QoS for latency constraints

[Kevin Hilman <khilman@ti.com>]

Jean Pihet <jean.pihet@newoldbits.com> writes:

> Kevin,
>
> On Fri, Sep 16, 2011 at 12:46 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Hi Jean,
>>
>> Jean Pihet <jean.pihet@newoldbits.com> writes:
>>
>>> Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
>>> API to the new PM QoS API.
>>> Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY
>>> class of PM QoS. The resulting MPU constraints are used by cpuidle to
>>> decide the next power state of the MPU subsystem.
>>>
>>> Currently only OMAP3 is placing constraints on the MPU.
>>>
>>> Signed-off-by: Jean Pihet <j-pihet@ti.com>
>>
>> [...]
>>
>>> @@ -648,8 +648,16 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
>>>       if (r < 0)
>>>               goto out;
>>>
>>> -     if (dev->set_mpu_wkup_lat != NULL)
>>> -             dev->set_mpu_wkup_lat(dev->dev, dev->latency);
>>> +     /*
>>> +      * When waiting for completion of a i2c transfer, we need to
>>> +      * set a wake up latency constraint for the MPU. This is to
>>> +      * ensure quick enough wakeup from idle, when transfer
>>> +      * completes.
>>> +      * Used on OMAP3 Only
>>> +      */
>>> +     if (cpu_is_omap34xx())
>>
>> We don't want any cpu_is_* checking  in drivers.
>>
>> If this is only done on certain SoCs, then a flag should be passed from
>> device init code via pdata.
>>
>> That being said, I don't see why this shouldn't be set for all SoCs
>> since it's using the FIFO size to determine the latency.
> I am OK to have the constraints active for all OMAPs. Side question:
> what if different SOCs need different values for the constraint?

This latency calculation is based on FIFO size and drain rate, so it
should be completely SoC independent.

However, if for some reason there are SoC dependencies, the SoC specific
parts need to be passed in to the driver.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html