Hi Peter,
On Saturday 11 July 2015 03:31 AM, Peter Hurley wrote:
> On 07/09/2015 10:15 AM, Sekhar Nori wrote:
>> On Thursday 09 July 2015 07:03 AM, Peter Hurley wrote:
>
> [...]
>
>>>> @@ -1307,6 +1320,36 @@ static int omap8250_runtime_suspend(struct device
>>>> *dev)
>>>> return -EBUSY;
>>>> }
>>>>
>>>> + if (priv->habit & UART_ERRATA_CLOCK_DISABLE) {
>>>> + int sysc;
>>>> + int syss;
>>>> + int timeout = 100;
>>>> +
>>>> + sysc = serial_in(up, UART_OMAP_SYSC);
>>>> +
>>>> + /* softreset the UART */
>>>> + sysc |= OMAP_UART_SYSC_SOFTRESET;
>>>> + serial_out(up, UART_OMAP_SYSC, sysc);
>>>> +
>>>> + /* By experiments, 1us enough for reset complete on AM335x */
>>>> + do {
>>>> + udelay(1);
>>>> + syss = serial_in(up, UART_OMAP_SYSS);
>>>> + } while (--timeout && !(syss & OMAP_UART_SYSS_RESETDONE));
>>>
>>>
>>> If there is not a omap helper function to reset modules, there should be.
>>> Open-coding the module reset is not appropriate.
>>
>> There is work planned to have something implemented for OMAP as part of
>> drivers/reset/ API. AFAIK, this depends on some PRCM code clean-up
>> affecting multiple OMAP platforms and is couple of merge windows away
>> from taking shape.
>>
>> Meanwhile, I think this is the best we can do. Other drivers like
>> i2c-omap have done something similar (see omap_i2c_reset()).
>
> Ok, then please make the reset a separate local function
> (returning success/failure?). omap_8250_reset()?
>
> A TODO or FIXME above it explaining
> the temporary nature of the function would be appreciated :)
Okay, will do.
>
>>>
>>>> + if (!timeout) {
>>>> + dev_err(dev, "timed out waiting for reset done\n");
>>>> + return -ETIMEDOUT;
>>>> + }
>>>> +
>>>> + /*
>>>> + * For UART module wake-up to work, MDR1.MODESELECT should
>>>> + * not be set to "Disable", so update it.
>>>> + */
>>>> + if (device_may_wakeup(dev))
>>>> + omap8250_update_mdr1(up, priv);
>>>
>>> Should this be unconditional?
>>
>> I do not see it doing any harm if done unconditionally. But it will be
>> unnecessary. Unless the UART is being used for wakeup, we don't need
>> MDR1 restored at this stage. And omap8250_restore_regs() will eventually
>> restore the register anyway.
>
> Yeah, I understand that, but special-casing it isn't adding any value;
> it's not as if you actually want the module to not be in UART mode.
>
> And the comment could be single-line:
>
> /* Restore to UART mode after reset (for wakeup) */
Alright, will change this as well.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
