Hi Laurent,
[fixing Stephen's email address]
On Mon, Nov 28, 2016 at 10:04 PM, Laurent Pinchart
wrote:
> Hi Mike,
>
> On Monday 28 Nov 2016 13:56:11 Michael Turquette wrote:
>> On Fri, Nov 25, 2016 at 7:22 AM, Laurent Pinchart wrote:
>> > On Friday 25 Nov 2016
ould accept the small overhead incurred in providing a
solution that works for everyone. This prevents hardware-specific
hacks in the driver.
Related: we really should model bus clocks whenever possible. I've
seen other attempts to merge functional/logic and bus clocks into a
single entity (e.g. a single struct clk_hw/clk_core that turns both
clocks on and off) and this defeats some fine-grained power management
scenarios that the hardware designers had in mind when creating
separate controls for the clocks.
Regards,
Mike
>
>> >> By the way while we're discussing DW HDMI bindings specific to iMX,
>> >> I would recommend to remove utterly hackish and iMX only "gpr"
>> >> property from the example in bindings/display/bridge/dw_hdmi.txt
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Michael Turquette
CEO
BayLibre - At the Heart of Embedded Linux
http://baylibre.com/
Quoting Maxime Ripard (2016-05-16 05:47:02)
> In the current multiplier base clock implementation, if the
> CLK_SET_RATE_PARENT flag isn't set, the code will not make sure that the
> multiplier computed remains within the boundaries of our clock.
>
> This means that if the clock we want to reach
Quoting Maxime Ripard (2016-06-20 01:54:58)
> On Fri, Jun 17, 2016 at 04:05:33PM -0700, Michael Turquette wrote:
> > Quoting Maxime Ripard (2016-05-16 05:47:01)
> > > A fixed factor clock, if it needs to change its rate, by definition do not
> > > have any choice bu
Quoting Maxime Ripard (2016-05-16 05:47:01)
> A fixed factor clock, if it needs to change its rate, by definition do not
> have any choice but to modify its parent rate.
Logically it makes sense to always propagate the rate-change request up
to the parent for a fixed-factor clock if we desire to
Quoting Philipp Zabel (2016-02-17 03:28:50)
> This mux is supposed to select a fitting divider after the PLL
> is already set to the correct rate.
>
> Signed-off-by: Philipp Zabel
> Acked-by: James Liao
Looks good to me.
Regards,
Mike
> ---
> Changes since v10:
> - Add comments about
Quoting Philipp Zabel (2016-02-03 11:25:59)
> This mux is supposed to select a fitting divider after the PLL
> is already set to the correct rate.
>
> Signed-off-by: Philipp Zabel
> Acked-by: James Liao
> ---
> drivers/clk/mediatek/clk-mt8173.c | 2 +-
> drivers/clk/mediatek/clk-mtk.h| 7
Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote:
> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
> >
> >> Well, I'm not quite sure why exactly everyone is so focused on probing
> >> here.
> >
> > Probe deferral is really
Quoting Sylwester Nawrocki (2015-10-20 04:17:35)
> On 20/10/15 12:34, Michael Turquette wrote:
> >> diff --git a/include/dt-bindings/clock/exynos5433.h
> >> b/include/dt-bindings/clock/exynos5433.h
> >> > index 5bd80d5..4f0d566 100644
> >> >
Quoting Andrzej Hajda (2015-10-20 02:22:32)
> HDMI driver must re-parent respective muxes during HDMI-PHY on/off
> to HDMI-PHY output clocks. To reference those clocks their
> definitions should be added.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/clk/samsung/clk-exynos5433.c | 6 --
10 matches
Mail list logo
