From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/5] ARM: dts: Add syscon handle in pmu node for exynos5250
Date: Fri, 25 Apr 2014 22:55:36 +0200 [thread overview]
Message-ID: <535ACBC8.5090703@gmail.com> (raw)
In-Reply-To: <1398426857-5097-2-git-send-email-pankaj.dubey@samsung.com>
Hi Pankaj,
On 25.04.2014 13:54, Pankaj Dubey wrote:
> Add "samsung,syscon-phandle" property pointing to PMU node
> to access PMU register via PMU regmap handle.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index 3742331..52801af 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -173,6 +173,7 @@
> pmu_system_controller: system-controller at 10040000 {
> compatible = "samsung,exynos5250-pmu", "syscon";
> reg = <0x10040000 0x5000>;
> + samsung,syscon-phandle = <&pmu_system_controller>;
> };
>
> watchdog at 101D0000 {
>
This looks strange. A node that refers back to itself. If I understand
correctly, you are relying on the fact that if you don't use
platform_driver model for the PMU driver, it won't bind to this node and
instead the generic syscon driver will. I'm afraid this is incorrect,
because the PMU driver should normally use the driver model.
I see two possible options to solve this problem:
1) Instead, the PMU driver should bind to this node and become a syscon
provider. This will require a small change in the syscon API, which
would be reasonable anyway:
a) instead of using driver_find_device() and dev_get_drvdata() in
syscon_node_to_regmap(), a local list of syscon structs should be kept
in this driver and then the look-up would just iterate over this list,
that could contain external syscon implementations as well,
b) syscon_register() function should be provided to register an
external syscon provider from other drivers, like Exynos PMU driver.
Another solution would be:
2) Register a static platform device from Exynos PMU driver, with
.of_node set to PMU node and .name to "syscon" to instantiate the syscon
device and create a syscon provider, even though the PMU driver would be
bound to the node.
The change mentioned in point 1.a) should be implemented regardless of
which solution is chosen, as iterating over all devices in the system
and relying on their driver_data is rather a poor practice. A local list
would be faster - all syscons to iterate over, instead of all devices in
the system, and more flexible - a single device could be a provider of
multiple resources.
As for the solution for Exynos PMU itself, I tend to prefer 2), as it
wouldn't require additional functions exported from the syscon driver.
Best regards,
Tomasz
next prev parent reply other threads:[~2014-04-25 20:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-02 8:02 [PATCH 0/3] Add PMU node for Exynos4210, Exynos4412, Exynos4212 Pankaj Dubey
2014-04-02 8:02 ` [PATCH 1/3] ARM: dts: Add PMU reg node to exynos4210 Pankaj Dubey
2014-04-24 11:59 ` Vikas Sajjan
2014-04-24 12:57 ` Pankaj Dubey
2014-04-24 13:26 ` Vikas Sajjan
2014-04-02 8:02 ` [PATCH 2/3] ARM: dts: Add PMU reg node to exynos4212 and exynos4412 Pankaj Dubey
2014-04-02 8:02 ` [PATCH 3/3] Documentation: update samsung pmu binding information for Exynos4210/4212/4412 Pankaj Dubey
2014-04-25 11:54 ` [PATCH v2 0/5] Add PMU node for Exynos SoCs Pankaj Dubey
2014-04-25 11:54 ` [PATCH v2 1/5] ARM: dts: Add syscon handle in pmu node for exynos5250 Pankaj Dubey
2014-04-25 20:55 ` Tomasz Figa [this message]
2014-04-28 11:22 ` Pankaj Dubey
2014-04-25 11:54 ` [PATCH v2 2/5] ARM: dts: Add PMU node to exynos4210 Pankaj Dubey
2014-04-25 11:54 ` [PATCH v2 3/5] ARM: dts: Add PMU node to exynos4212 and exynos4412 Pankaj Dubey
2014-04-25 11:54 ` [PATCH v2 4/5] arm: dts: Add syscon handle in pmu node for exynos5420 Pankaj Dubey
2014-04-25 11:54 ` [PATCH v2 5/5] Documentation: update samsung pmu binding information Pankaj Dubey
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=535ACBC8.5090703@gmail.com \
--to=tomasz.figa@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).