* Tero Kristo [181004 15:53]:
> On 04/10/18 18:07, Tony Lindgren wrote:
> > * Tero Kristo [181004 14:47]:
> > > On 04/10/18 17:25, Tony Lindgren wrote:
> > > > It seems we should just provide a generic interface for
> > > > clk_allow_autoidle() and clk_deny_autoidle()? Otherwise we'll
> > > > be
* Tero Kristo [181004 15:53]:
> On 04/10/18 18:07, Tony Lindgren wrote:
> > * Tero Kristo [181004 14:47]:
> > > On 04/10/18 17:25, Tony Lindgren wrote:
> > > > It seems we should just provide a generic interface for
> > > > clk_allow_autoidle() and clk_deny_autoidle()? Otherwise we'll
> > > > be
On 04/10/18 18:07, Tony Lindgren wrote:
* Tero Kristo [181004 14:47]:
On 04/10/18 17:25, Tony Lindgren wrote:
It seems we should just provide a generic interface for
clk_allow_autoidle() and clk_deny_autoidle()? Otherwise we'll
be forever stuck with pdata callbacks it seems.
The TI clock
On 04/10/18 18:07, Tony Lindgren wrote:
* Tero Kristo [181004 14:47]:
On 04/10/18 17:25, Tony Lindgren wrote:
It seems we should just provide a generic interface for
clk_allow_autoidle() and clk_deny_autoidle()? Otherwise we'll
be forever stuck with pdata callbacks it seems.
The TI clock
* Tero Kristo [181004 14:47]:
> On 04/10/18 17:25, Tony Lindgren wrote:
> > It seems we should just provide a generic interface for
> > clk_allow_autoidle() and clk_deny_autoidle()? Otherwise we'll
> > be forever stuck with pdata callbacks it seems.
>
> The TI clock driver is actually providing
* Tero Kristo [181004 14:47]:
> On 04/10/18 17:25, Tony Lindgren wrote:
> > It seems we should just provide a generic interface for
> > clk_allow_autoidle() and clk_deny_autoidle()? Otherwise we'll
> > be forever stuck with pdata callbacks it seems.
>
> The TI clock driver is actually providing
On 04/10/18 17:25, Tony Lindgren wrote:
* Andreas Kemnade [181004 05:56]:
On the gta04 with a dm3730 omap_hdq does not work properly when the
device enters lower power states. Idling uart1 and 2 is enough
to show up that problem, if there are no other things enabled.
Further research reveals
On 04/10/18 17:25, Tony Lindgren wrote:
* Andreas Kemnade [181004 05:56]:
On the gta04 with a dm3730 omap_hdq does not work properly when the
device enters lower power states. Idling uart1 and 2 is enough
to show up that problem, if there are no other things enabled.
Further research reveals
* Andreas Kemnade [181004 05:56]:
> On the gta04 with a dm3730 omap_hdq does not work properly when the
> device enters lower power states. Idling uart1 and 2 is enough
> to show up that problem, if there are no other things enabled.
> Further research reveals that hdq iclk must not be turned off
* Andreas Kemnade [181004 05:56]:
> On the gta04 with a dm3730 omap_hdq does not work properly when the
> device enters lower power states. Idling uart1 and 2 is enough
> to show up that problem, if there are no other things enabled.
> Further research reveals that hdq iclk must not be turned off
On the gta04 with a dm3730 omap_hdq does not work properly when the
device enters lower power states. Idling uart1 and 2 is enough
to show up that problem, if there are no other things enabled.
Further research reveals that hdq iclk must not be turned off during
transfers, also according to the
On the gta04 with a dm3730 omap_hdq does not work properly when the
device enters lower power states. Idling uart1 and 2 is enough
to show up that problem, if there are no other things enabled.
Further research reveals that hdq iclk must not be turned off during
transfers, also according to the
12 matches
Mail list logo
