From: Tomasz Figa <tomasz.figa@gmail.com>
To: Mike Turquette <mturquette@linaro.org>
Cc: Padmavathi Venna <padma.v@samsung.com>,
linux-samsung-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
padma.kvr@gmail.com, broonie@kernel.org, kgene.kim@samsung.com,
abrestic@chromium.org
Subject: Re: [PATCH V2 2/4] clk: exynos-audss: set correct parent clocks
Date: Wed, 28 Aug 2013 03:02:36 +0200 [thread overview]
Message-ID: <7654693.FMY6qS63O6@flatron> (raw)
In-Reply-To: <20130828004341.8231.3654@quantum>
On Tuesday 27 of August 2013 17:43:41 Mike Turquette wrote:
> Quoting Padmavathi Venna (2013-08-16 00:49:36)
>
> > From: Andrew Bresticker <abrestic@chromium.org>
> >
> > Different Exynos SoCs have different names for certain input clocks
> > to the AudioSS block. Since the order in which clock providers are
> > probed is not guaranteed, we can't use the device-tree to pass the
> > correct input clocks.
>
> Why not? Could your audss binding include something like a "clocks"
> property with phandles to the input clocks? Then your audss clock driver
> could just use clk_get like a regular driver to get the parents.
AFAIR, the driver is currently probed using of_clk_init(), so the reason
was probably being unable to defer probing.
However this is not the core system clock controller, so I believe there
is no reason for it not to be a normal platform driver.
Best regards,
Tomasz
WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 2/4] clk: exynos-audss: set correct parent clocks
Date: Wed, 28 Aug 2013 03:02:36 +0200 [thread overview]
Message-ID: <7654693.FMY6qS63O6@flatron> (raw)
In-Reply-To: <20130828004341.8231.3654@quantum>
On Tuesday 27 of August 2013 17:43:41 Mike Turquette wrote:
> Quoting Padmavathi Venna (2013-08-16 00:49:36)
>
> > From: Andrew Bresticker <abrestic@chromium.org>
> >
> > Different Exynos SoCs have different names for certain input clocks
> > to the AudioSS block. Since the order in which clock providers are
> > probed is not guaranteed, we can't use the device-tree to pass the
> > correct input clocks.
>
> Why not? Could your audss binding include something like a "clocks"
> property with phandles to the input clocks? Then your audss clock driver
> could just use clk_get like a regular driver to get the parents.
AFAIR, the driver is currently probed using of_clk_init(), so the reason
was probably being unable to defer probing.
However this is not the core system clock controller, so I believe there
is no reason for it not to be a normal platform driver.
Best regards,
Tomasz
next prev parent reply other threads:[~2013-08-28 1:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 7:49 [PATCH V2 0/4] clk: Samsung: audss: Add support for Exynos5420 Padmavathi Venna
2013-08-16 7:49 ` Padmavathi Venna
2013-08-16 7:49 ` [PATCH V1 1/4] clk: exynos-audss: add support for Exynos 5420 Padmavathi Venna
2013-08-16 7:49 ` Padmavathi Venna
2013-08-16 7:49 ` [PATCH V2 2/4] clk: exynos-audss: set correct parent clocks Padmavathi Venna
2013-08-16 7:49 ` Padmavathi Venna
2013-08-28 0:43 ` Mike Turquette
2013-08-28 0:43 ` Mike Turquette
2013-08-28 1:02 ` Tomasz Figa [this message]
2013-08-28 1:02 ` Tomasz Figa
2013-08-16 7:49 ` [PATCH V2 3/4] ARM: dts: Correct the /include entry on exynos5420 dtsi file Padmavathi Venna
2013-08-16 7:49 ` Padmavathi Venna
2013-08-16 7:49 ` [PATCH V2 4/4] ARM: dts: exynos5420: add audio clock controller Padmavathi Venna
2013-08-16 7:49 ` Padmavathi Venna
2013-08-19 8:48 ` [PATCH V2 0/4] clk: Samsung: audss: Add support for Exynos5420 Padma Venkat
2013-08-19 8:48 ` Padma Venkat
2013-08-27 6:18 ` Padma Venkat
2013-08-27 6:18 ` Padma Venkat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7654693.FMY6qS63O6@flatron \
--to=tomasz.figa@gmail.com \
--cc=abrestic@chromium.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kgene.kim@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mturquette@linaro.org \
--cc=padma.kvr@gmail.com \
--cc=padma.v@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.