Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1622316

Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111

From Stephen Boyd <sboyd@codeaurora.org>
Newsgroups linux.kernel
Subject Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111
Date 2017-04-12 18:40 +0200
Message-ID <tvttf-6Mv-9@gated-at.bofh.it> (permalink)
References <tuSDn-ah-3@gated-at.bofh.it> <tv07V-50R-27@gated-at.bofh.it> <tvciJ-4wo-11@gated-at.bofh.it> <tvlcl-1Jg-11@gated-at.bofh.it> <tvsnw-680-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 04/12, Neil Armstrong wrote:
> On 04/12/2017 09:40 AM, Linus Walleij wrote:
> > On Wed, Apr 12, 2017 at 12:13 AM, Eric Anholt <eric@anholt.net> wrote:
> > 
> >> Oh, one last thing I think we need to figure out: I'm using TIM2_CLKSEL,
> >> which seems to be necessary on this platform.  My understanding is that
> >> this means that the pixel clock is divided from clcdclk instead of
> >> apb_pclk.  Do you agree?
> > 
> > Yes the pixed clock is always derived from clcdclk.
> > 
> > In most older ARM reference designs this is a VCO so that
> > is why there is a clk_set_rate() on this in the fbdev code.
> > (On some platforms that even has no effect I guess.)
> > 
> >> The fbdev driver is using
> >> clk_get(&fb->dev->dev, NULL) and not TIM2_CLKSEL, which I'm surprised by
> >> because I would have thought that would give us the first clock from the
> >> DT node (also clcdclk).
> > 
> > So that thing is a 1-bit line that can select one of two clocks
> > to be muxed into the PL111/CLCD.
> > 
> > I guess that up until now all platforms just left that line dangling in
> > the silicon. Congratulations, you came here first ;)
> > 
> > Though when I look at the Nomadik it seems that it might be muxing
> > the clock between 48 and 72 MHz, and I've been using 48MHz
> > all along ooopsie.
> > 
> > The current assumption in the bindings is that we have only
> > one clock and TIM2_CLKSEL is N/A.
> > 
> > If we want proper clcdclk handling with CLKSEL you should
> > probably add some code to implement a real mux clock for
> > this using <linux/clock-provider.h> and drivers/clk/clk-mux.c
> > with select COMMON_CLK
> > so that the driver still only sees clcdclk but that in turn is a
> > mux that can select one of two sources and will react to
> > the clk_set_rate() call by selecting the clock which is
> > closest in frequency to what you want.
> > 
> > This needs a small patch to alter the bindings too I guess.
> > A small clock node inside the CLCD, just like PCI bridges have
> > irqchips inside them etc:
> > 
> > clcd@10120000 {
> >         compatible = "arm,pl110", "arm,primecell";
> >         reg = <0x10120000 0x1000>;
> >         (...)
> >         clocks = <&clcdclk>, <&foo>;
> >         clock-names = "clcdclk", "apb_pclk";
> > 
> >         clcdclk: clock-controller@0 {
> >                 compatible = "arm,pl11x-clock-mux";
> >                 clocks = <&source_a>, <&source_b>;
> >         };
> > };
> > 
> > This can be set up easily in the OF probe path since that
> > is what we're doing: just look for this subnode, if it is there
> > create the clock controller.
> > 
> > I do not think the clk maintainers would mind a small mux
> > clock controller inside the CLCD driver to handle this mux
> > if we need it.
> 
> Hi Linus,
> 
> Indeed it's the way of handling this use case, but no need to add
> a clk node here, you can copy what we did in pwm-meson, meson-gx-mmc.c,
> or dwmac-meson8b.c (we went further by also adding clk dividers).
> 
> In the probe code, simply add a clock mux provider with the two parents
> clock names (these can and should be platform specific) and only call
> a clk_set_parent() with the clock specified in the node clocks cell.
> 

+1

Avoiding a binding update is nice.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Eric Anholt <eric@anholt.net> - 2017-04-11 03:20 +0200
  Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Linus Walleij <linus.walleij@linaro.org> - 2017-04-11 11:20 +0200
    Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Daniel Vetter <daniel@ffwll.ch> - 2017-04-11 11:30 +0200
    Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Eric Anholt <eric@anholt.net> - 2017-04-11 18:20 +0200
    Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Eric Anholt <eric@anholt.net> - 2017-04-12 00:20 +0200
      Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Linus Walleij <linus.walleij@linaro.org> - 2017-04-12 09:50 +0200
        Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Neil Armstrong <narmstrong@baylibre.com> - 2017-04-12 17:30 +0200
          Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Stephen Boyd <sboyd@codeaurora.org> - 2017-04-12 18:40 +0200
        Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-04-13 01:20 +0200
  Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-04-11 11:40 +0200
    Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Eric Anholt <eric@anholt.net> - 2017-04-11 18:10 +0200
      Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-04-11 20:20 +0200
        Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Eric Anholt <eric@anholt.net> - 2017-04-11 23:10 +0200
          Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-04-13 01:00 +0200
            Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111 Eric Anholt <eric@anholt.net> - 2017-04-20 21:50 +0200

csiph-web