From: Vaibhav Hiremath <hvaibhav@ti.com>
To: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Paul Walmsley <paul@pwsan.com>, Tony Lindgren <tony@atomide.com>,
Kevin Hilman <khilman@ti.com>, Benoit Cousson <b-cousson@ti.com>,
Rajendra Nayak <rnayak@ti.com>
Subject: omap_device: query on "fck" clk alias created
Date: Wed, 1 Aug 2012 17:50:16 +0530 [thread overview]
Message-ID: <50191F00.1040501@ti.com> (raw)
Hi,
In OMAP world, we have omap_device layer, which exports api's like
omap_device_build() to create and register platform_device to the
kernel. This layer understands hwmod infrastructure and parses all the
platform specific information from it.
Now with DT migration, the same thing is achieved using a notifier,
which in turn omap_device_build_from_dt(), which in turn does same thing.
One of the thing which is happening in both execution path is, creating
alias for functional clock (hwmod_data->main_clk) for each device
getting created with the con_id = "fck".
Now the problem with this is,
The clk_get() api will not work, unless we pass both the arguments (dev,
con_id) properly. Now expecting driver to always label con_id with "fck"
is undesirable, as the same driver can be reused on multiple platforms,
which can be non-omap and/or non-ti platforms.
Also we have multiple examples where driver simply calls (which is right)
clk = clk_get(&pdev->dev, NULL);
This would fail on OMAP platforms, unless you modify clockxxx_data.c
file with,
CLK("<device>", NULL, &xxx_fck, CK_34XX),
Devices specially with only one clock source always prefer not to
specify con_id.
And it seems wrong thing, as across platforms IP integration can be very
different and you can not expect to change the clock-tree table always.
So the option here we have is,
1. Instead of creating alias with "fck", create an alias only with dev
pointer, that means con_id = NULL.
I have already tested this and it works on AM33xx platform.
2. Add a new flag inside hwmod or omap_device, so that it can be read at
omap_device layer and based on that we can decide whether to add con_id
or not while invoking clkdev_alloc().
This may be required to support legacy drivers which are not migrated to
runtime_pm and still calls clk_get() for both "fck" and "ick", so here
we need "fck" clk alias.
Any comments or opinion on this? Based on the feedback I can create the
changes and submit it to the list.
Thanks,
Vaibhav
WARNING: multiple messages have this Message-ID (diff)
From: hvaibhav@ti.com (Vaibhav Hiremath)
To: linux-arm-kernel@lists.infradead.org
Subject: omap_device: query on "fck" clk alias created
Date: Wed, 1 Aug 2012 17:50:16 +0530 [thread overview]
Message-ID: <50191F00.1040501@ti.com> (raw)
Hi,
In OMAP world, we have omap_device layer, which exports api's like
omap_device_build() to create and register platform_device to the
kernel. This layer understands hwmod infrastructure and parses all the
platform specific information from it.
Now with DT migration, the same thing is achieved using a notifier,
which in turn omap_device_build_from_dt(), which in turn does same thing.
One of the thing which is happening in both execution path is, creating
alias for functional clock (hwmod_data->main_clk) for each device
getting created with the con_id = "fck".
Now the problem with this is,
The clk_get() api will not work, unless we pass both the arguments (dev,
con_id) properly. Now expecting driver to always label con_id with "fck"
is undesirable, as the same driver can be reused on multiple platforms,
which can be non-omap and/or non-ti platforms.
Also we have multiple examples where driver simply calls (which is right)
clk = clk_get(&pdev->dev, NULL);
This would fail on OMAP platforms, unless you modify clockxxx_data.c
file with,
CLK("<device>", NULL, &xxx_fck, CK_34XX),
Devices specially with only one clock source always prefer not to
specify con_id.
And it seems wrong thing, as across platforms IP integration can be very
different and you can not expect to change the clock-tree table always.
So the option here we have is,
1. Instead of creating alias with "fck", create an alias only with dev
pointer, that means con_id = NULL.
I have already tested this and it works on AM33xx platform.
2. Add a new flag inside hwmod or omap_device, so that it can be read at
omap_device layer and based on that we can decide whether to add con_id
or not while invoking clkdev_alloc().
This may be required to support legacy drivers which are not migrated to
runtime_pm and still calls clk_get() for both "fck" and "ick", so here
we need "fck" clk alias.
Any comments or opinion on this? Based on the feedback I can create the
changes and submit it to the list.
Thanks,
Vaibhav
next reply other threads:[~2012-08-01 12:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-01 12:20 Vaibhav Hiremath [this message]
2012-08-01 12:20 ` omap_device: query on "fck" clk alias created Vaibhav Hiremath
2012-08-01 13:42 ` Benoit Cousson
2012-08-01 13:42 ` Benoit Cousson
2012-08-02 12:55 ` Hiremath, Vaibhav
2012-08-02 12:55 ` Hiremath, Vaibhav
2012-08-02 13:09 ` Russell King - ARM Linux
2012-08-02 13:09 ` Russell King - ARM Linux
2012-08-01 14:14 ` Russell King - ARM Linux
2012-08-01 14:14 ` Russell King - ARM Linux
2012-08-02 13:04 ` Hiremath, Vaibhav
2012-08-02 13:04 ` Hiremath, Vaibhav
2012-08-02 13:12 ` Russell King - ARM Linux
2012-08-02 13:12 ` Russell King - ARM Linux
2012-08-03 6:26 ` Hiremath, Vaibhav
2012-08-03 6:26 ` Hiremath, Vaibhav
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=50191F00.1040501@ti.com \
--to=hvaibhav@ti.com \
--cc=b-cousson@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=rnayak@ti.com \
--cc=tony@atomide.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.