Re: [PATCH 3/4] i2c: qup: Correct duty cycle for FM and FM+

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Austin,

On 4/13/2018 9:18 PM, Christ, Austin wrote:
> Hey Sricharan,
> 
> On 4/13/2018 12:14 AM, Sricharan R wrote:
>> Hi Austin,
>>
>> On 4/5/2018 1:14 AM, Austin Christ wrote:
>>> The I2C spec UM10204 Rev. 6 specifies the following timings.
>>>
>>>             Standard      Fast Mode     Fast Mode Plus
>>> SCL low    4.7us         1.3us         0.5us
>>> SCL high   4.0us         0.6us         0.26us
>>>
>>> This results in a 33%/66% duty cycle as opposed to the 50%/50% duty cycle
>>> used for Standard-mode.
>>>
>>> Add High Time Divider settings to correct duty cycle for FM(400kHz) and
>>> FM+(1MHz).
>>>
>>> Signed-off-by: Austin Christ <austinwc@xxxxxxxxxxxxxx>
>>> ---
>>>   drivers/i2c/busses/i2c-qup.c | 10 ++++++++--
>>>   1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
>>> index cb14687..2a88611 100644
>>> --- a/drivers/i2c/busses/i2c-qup.c
>>> +++ b/drivers/i2c/busses/i2c-qup.c
>>> @@ -1858,9 +1858,15 @@ static int qup_i2c_probe(struct platform_device *pdev)
>>>       size = QUP_INPUT_FIFO_SIZE(io_mode);
>>>       qup->in_fifo_sz = qup->in_blk_sz * (2 << size);
>>>   -    fs_div = ((src_clk_freq / clk_freq) / 2) - 3;
>>>       hs_div = 3;
>>> -    qup->clk_ctl = (hs_div << 8) | (fs_div & 0xff);
>>> +    if (clk_freq <= I2C_STANDARD_FREQ) {
>>> +        fs_div = ((src_clk_freq / clk_freq) / 2) - 3;
>>> +        qup->clk_ctl = (hs_div << 8) | (fs_div & 0xff);
>>> +    } else {
>>> +        /* 33%/66% duty cycle */
>>> +        fs_div = ((src_clk_freq / clk_freq) - 6) * 2 / 3;
>>> +        qup->clk_ctl = ((fs_div / 2) << 16) | (hs_div << 8) | (fs_div & 0xff);
>>> +    }
>>   while here, can we add a small comment for the above calculation. why the -3 above and -6 ?
>>
> Good question. This is the exact math recommended in the HPG for fs_div with and without the high time divider set. There is not explanation for the differences in the math in the hardware documentation that I've seen. What is the preferred way for documenting something like this in comments?

 ok, so you might have verified clk output with the new settings, right ?. That should be fine.

Regards,
 Sricharan 

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation



[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux