[PATCH v3 4/5] clk/exynos5420: add hdmi mux to change parents in hdmi driver
Tomasz Figa
t.figa at samsung.com
Wed Aug 28 07:55:36 EDT 2013
On Tuesday 27 of August 2013 10:14:01 Rahul Sharma wrote:
> On 27 August 2013 05:16, Tomasz Figa <tomasz.figa at gmail.com> wrote:
> > Hi Rahul,
> >
> > On Monday 26 of August 2013 14:43:02 Rahul Sharma wrote:
> >> hdmi driver needs to change the parent of hdmi clock
> >> to pixel clock or hdmiphy clock, based on the stability
> >> of hdmiphy. This patch is exposing the mux for changing
> >> the parent.
> >>
> >> Signed-off-by: Rahul Sharma <rahul.sharma at samsung.com>
> >> ---
> >>
> >> Documentation/devicetree/bindings/clock/exynos5420-clock.txt | 5
> >>
> >> +++++ drivers/clk/samsung/clk-exynos5420.c |
> >> 5 ++++- 2 files changed, 9 insertions(+), 1 deletion(-)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> >> b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt index
> >> 5758a69..6f16aa8 100644
> >> --- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> >> +++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
> >> @@ -182,6 +182,11 @@ clock which they consume.
> >>
> >> g3d 501
> >> smmu_mixer 502
> >>
> >> + Mux ID
> >> + ----------------------------
> >> +
> >> + mout_hdmi 1024
> >
> > Is there a need for such big hole between smm_mixer and this clock? I
> > believe that based on the documentation, the total amount of clocks
> > that
> > can be defined may be approximated and some extra margin added, so you
> > don't waste so much of numbering space and memory used for lookup
> > array.
>
> Total number of Gates are coming upto the enum value 540. I can leave gap
> of 64 in between for first mux. Similarly, total muxes in system are
> 118. Optimum gab would be between 128~150. What you say about these
> values?
OK, so let's say that muxes should start at 640 and dividers at 768.
Anyway, ideally, we should break from this idea of grouping and convert
this way of definition to normal preprocessor macros that could be used
inside dts files as well. Then we could detach ourselves from referring to
clocks by numbers, because those macros would do that for us, without the
need to group clocks together for better readability. See clock driver for
S3C64xx [1].
This is an idea for further work, though. For now the values I proposed
should be more than enough.
[1] http://thread.gmane.org/gmane.linux.usb.general/90493/focus=21090
Best regards,
Tomasz
More information about the linux-arm-kernel
mailing list