[PATCH] clkdev: add support to lookup for early platform device

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

early platform device may do not have a device name as the slab is not yet
available. So to search a clock base on the dev_id we need to search first the
device base name and then the id

we need this on AT91 to use the early device for the GPIO drivers and serial
at least, SH Mobile and SH could also use it for serial and other drivers

for this purpose this patch introduce two new API

clk_get_sys_id(dev_base_name, id, con_id)
and clk_get_pdev(pdev, con_id)

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Patrice Vilchez <patrice.vilchez@atmel.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
---
 drivers/clk/clkdev.c |   43 +++++++++++++++++++++++++++++++++++++------
 include/linux/clk.h  |   41 ++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 77 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index b9b949c2..8b50509 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -11,7 +11,7 @@
  */
 #include <linux/module.h>
 #include <linux/kernel.h>
-#include <linux/device.h>
+#include <linux/platform_device.h>
 #include <linux/list.h>
 #include <linux/errno.h>
 #include <linux/err.h>
@@ -33,8 +33,11 @@ static DEFINE_MUTEX(clocks_mutex);
  *  If an entry has a connection ID, it must match
  * Then we take the most specific entry - with the following
  * order of precedence: dev+con > dev only > con only.
+ *
+ * if id > 0 the dev_id will just contain the base name of the device
+ * it's need to search dev_id before slab is available
  */
-static struct clk *clk_find(const char *dev_id, const char *con_id)
+static struct clk *clk_find(const char *dev_id, int id, const char *con_id)
 {
 	struct clk_lookup *p;
 	struct clk *clk = NULL;
@@ -43,8 +46,19 @@ static struct clk *clk_find(const char *dev_id, const char *con_id)
 	list_for_each_entry(p, &clocks, node) {
 		match = 0;
 		if (p->dev_id) {
-			if (!dev_id || strcmp(p->dev_id, dev_id))
+			if (!dev_id) {
+				continue;
+			} else if (id < 0 && strcmp(p->dev_id, dev_id)) {
 				continue;
+			} else {
+				int len = strlen(dev_id);
+
+				if (strncmp(p->dev_id, dev_id, len))
+					continue;
+
+				if (simple_strtoul(p->dev_id + len + 1, NULL, 10) != id)
+					continue;
+			}
 			match += 2;
 		}
 		if (p->con_id) {
@@ -64,19 +78,36 @@ static struct clk *clk_find(const char *dev_id, const char *con_id)
 	return clk;
 }
 
-struct clk *clk_get_sys(const char *dev_id, const char *con_id)
+struct clk *clk_get_sys_id(const char *dev_id, int id, const char *con_id)
 {
 	struct clk *clk;
 
 	mutex_lock(&clocks_mutex);
-	clk = clk_find(dev_id, con_id);
+	clk = clk_find(dev_id, id, con_id);
 	if (clk && !__clk_get(clk))
 		clk = NULL;
 	mutex_unlock(&clocks_mutex);
 
 	return clk ? clk : ERR_PTR(-ENOENT);
 }
-EXPORT_SYMBOL(clk_get_sys);
+EXPORT_SYMBOL(clk_get_sys_id);
+
+struct clk *clk_get_pdev(struct platform_device *pdev, const char *con_id)
+{
+	const char *dev_id;
+
+	if (!pdev)
+		return clk_get_sys(NULL, con_id);
+
+	dev_id = dev_name(&pdev->dev);
+
+	/* if the slub is not available dev_id is NULL */
+	if (is_early_platform_device(pdev) && !dev_id)
+		return clk_get_sys_id(pdev->name, pdev->id, NULL);
+
+	return clk_get_sys(dev_id, con_id);
+}
+EXPORT_SYMBOL(clk_get_pdev);
 
 struct clk *clk_get(struct device *dev, const char *con_id)
 {
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 1d37f42..31d1341 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -127,6 +127,42 @@ struct clk *clk_get_parent(struct clk *clk);
 
 /**
  * clk_get_sys - get a clock based upon the device name
+ * @dev_id: device base name
+ * @id:     device id
+ * @con_id: connection ID
+ *
+ * Returns a struct clk corresponding to the clock producer, or
+ * valid IS_ERR() condition containing errno.  The implementation
+ * uses @dev_id and @con_id to determine the clock consumer, and
+ * thereby the clock producer. In contrast to clk_get() this function
+ * takes the device name instead of the device itself for identification.
+ *
+ * Drivers must assume that the clock source is not enabled.
+ *
+ * clk_get_sys should not be called from within interrupt context.
+ */
+struct clk *clk_get_sys_id(const char *dev_id, int id, const char *con_id);
+
+/**
+ * clk_get_pdev - lookup and obtain a reference to a clock producer.
+ * @pdev: platform device for clock "consumer"
+ * @id: clock comsumer ID
+ *
+ * Returns a struct clk corresponding to the clock producer, or
+ * valid IS_ERR() condition containing errno.  The implementation
+ * uses @dev and @id to determine the clock consumer, and thereby
+ * the clock producer.  (IOW, @id may be identical strings, but
+ * clk_get may return different clock producers depending on @dev.)
+ *
+ * Drivers must assume that the clock source is not enabled.
+ *
+ * clk_get_pdev should not be called from within interrupt context.
+ */
+struct platform_device;
+struct clk *clk_get_pdev(struct platform_device *pdev, const char *con_id);
+
+/**
+ * clk_get_sys - get a clock based upon the device name
  * @dev_id: device name
  * @con_id: connection ID
  *
@@ -140,7 +176,10 @@ struct clk *clk_get_parent(struct clk *clk);
  *
  * clk_get_sys should not be called from within interrupt context.
  */
-struct clk *clk_get_sys(const char *dev_id, const char *con_id);
+static inline  struct clk *clk_get_sys(const char *dev_id, const char *con_id)
+{
+	return clk_get_sys_id(dev_id, -1, con_id);
+}
 
 /**
  * clk_add_alias - add a new clock alias
-- 
1.7.4.1

[PATCH] clkdev: add support to lookup for early platform device

[Russell King - ARM Linux]

On Wed, Apr 20, 2011 at 04:05:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> early platform device may do not have a device name as the slab is not yet
> available. So to search a clock base on the dev_id we need to search first the
> device base name and then the id

I really don't like this.  IDs are platform device specific, and this is
a platform devince independent layer.

If you want to do this, then add a platform_device_clk_get() call, which
takes the platform device and connection id.  Uses the platform device
infrastructure to format the device name, and use clk_get_sys() to look
up the device/connection id from that.

Not only will that be more simple, but it'll also avoid putting bus-
specific code into bus-agnostic layers.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 09:42 Wed 27 Apr     , Russell King - ARM Linux wrote:
> On Wed, Apr 20, 2011 at 04:05:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > early platform device may do not have a device name as the slab is not yet
> > available. So to search a clock base on the dev_id we need to search first the
> > device base name and then the id
> 
> I really don't like this.  IDs are platform device specific, and this is
> a platform devince independent layer.
> 
> If you want to do this, then add a platform_device_clk_get() call, which
> takes the platform device and connection id.  Uses the platform device
> infrastructure to format the device name, and use clk_get_sys() to look
> up the device/connection id from that.
I do not want to alloc a string in the clkdev
but if you prefer

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:31 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 09:42 Wed 27 Apr     , Russell King - ARM Linux wrote:
> > On Wed, Apr 20, 2011 at 04:05:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > early platform device may do not have a device name as the slab is not yet
> > > available. So to search a clock base on the dev_id we need to search first the
> > > device base name and then the id
> > 
> > I really don't like this.  IDs are platform device specific, and this is
> > a platform devince independent layer.
> > 
> > If you want to do this, then add a platform_device_clk_get() call, which
> > takes the platform device and connection id.  Uses the platform device
> > infrastructure to format the device name, and use clk_get_sys() to look
> > up the device/connection id from that.
> I do not want to alloc a string in the clkdev
> but if you prefer
I check we can not do so
if slab is not available we can not use kmalloc

so we can not generate the dev.init_name

How do you want to procede to have a generic code?

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:47 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:31 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 09:42 Wed 27 Apr     , Russell King - ARM Linux wrote:
> > > On Wed, Apr 20, 2011 at 04:05:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > early platform device may do not have a device name as the slab is not yet
> > > > available. So to search a clock base on the dev_id we need to search first the
> > > > device base name and then the id
> > > 
> > > I really don't like this.  IDs are platform device specific, and this is
> > > a platform devince independent layer.
> > > 
> > > If you want to do this, then add a platform_device_clk_get() call, which
> > > takes the platform device and connection id.  Uses the platform device
> > > infrastructure to format the device name, and use clk_get_sys() to look
> > > up the device/connection id from that.
> > I do not want to alloc a string in the clkdev
> > but if you prefer
> I check we can not do so
> if slab is not available we can not use kmalloc
> 
> so we can not generate the dev.init_name
I check also we can not use the bootmem as it's too early in the init
so allocate the dev_id is not possible

use a satic buffer I'm not so happy about it
the only other solution is this one

which Greg or you prefer

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Greg KH]

On Wed, Apr 27, 2011 at 05:00:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:47 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 12:31 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 09:42 Wed 27 Apr     , Russell King - ARM Linux wrote:
> > > > On Wed, Apr 20, 2011 at 04:05:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > early platform device may do not have a device name as the slab is not yet
> > > > > available. So to search a clock base on the dev_id we need to search first the
> > > > > device base name and then the id
> > > > 
> > > > I really don't like this.  IDs are platform device specific, and this is
> > > > a platform devince independent layer.
> > > > 
> > > > If you want to do this, then add a platform_device_clk_get() call, which
> > > > takes the platform device and connection id.  Uses the platform device
> > > > infrastructure to format the device name, and use clk_get_sys() to look
> > > > up the device/connection id from that.
> > > I do not want to alloc a string in the clkdev
> > > but if you prefer
> > I check we can not do so
> > if slab is not available we can not use kmalloc
> > 
> > so we can not generate the dev.init_name
> I check also we can not use the bootmem as it's too early in the init
> so allocate the dev_id is not possible
> 
> use a satic buffer I'm not so happy about it
> the only other solution is this one
> 
> which Greg or you prefer

I have no idea what you are asking, please be more specific, hopefully
including a patch showing what you are referring to.

thanks,

greg k-h

[PATCH] clkdev: add support to lookup for early platform device

[Paul Mundt]

On Wed, Apr 27, 2011 at 05:00:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:47 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 12:31 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 09:42 Wed 27 Apr     , Russell King - ARM Linux wrote:
> > > > On Wed, Apr 20, 2011 at 04:05:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > early platform device may do not have a device name as the slab is not yet
> > > > > available. So to search a clock base on the dev_id we need to search first the
> > > > > device base name and then the id
> > > > 
> > > > I really don't like this.  IDs are platform device specific, and this is
> > > > a platform devince independent layer.
> > > > 
> > > > If you want to do this, then add a platform_device_clk_get() call, which
> > > > takes the platform device and connection id.  Uses the platform device
> > > > infrastructure to format the device name, and use clk_get_sys() to look
> > > > up the device/connection id from that.
> > > I do not want to alloc a string in the clkdev
> > > but if you prefer
> > I check we can not do so
> > if slab is not available we can not use kmalloc
> > 
> > so we can not generate the dev.init_name
> I check also we can not use the bootmem as it's too early in the init
> so allocate the dev_id is not possible
> 
> use a satic buffer I'm not so happy about it
> the only other solution is this one
> 
Are you willfully ignoring the init_name handling in
early_platform_driver_probe_id() or something?

See a636ee7fb35b731ba2b331f6294e809bb6be09c8 for example.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:09 Thu 28 Apr     , Paul Mundt wrote:
> On Wed, Apr 27, 2011 at 05:00:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 12:47 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 12:31 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > On 09:42 Wed 27 Apr     , Russell King - ARM Linux wrote:
> > > > > On Wed, Apr 20, 2011 at 04:05:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > > early platform device may do not have a device name as the slab is not yet
> > > > > > available. So to search a clock base on the dev_id we need to search first the
> > > > > > device base name and then the id
> > > > > 
> > > > > I really don't like this.  IDs are platform device specific, and this is
> > > > > a platform devince independent layer.
> > > > > 
> > > > > If you want to do this, then add a platform_device_clk_get() call, which
> > > > > takes the platform device and connection id.  Uses the platform device
> > > > > infrastructure to format the device name, and use clk_get_sys() to look
> > > > > up the device/connection id from that.
> > > > I do not want to alloc a string in the clkdev
> > > > but if you prefer
> > > I check we can not do so
> > > if slab is not available we can not use kmalloc
> > > 
> > > so we can not generate the dev.init_name
> > I check also we can not use the bootmem as it's too early in the init
> > so allocate the dev_id is not possible
> > 
> > use a satic buffer I'm not so happy about it
> > the only other solution is this one
> > 
> Are you willfully ignoring the init_name handling in
> early_platform_driver_probe_id() or something?
> 
> See a636ee7fb35b731ba2b331f6294e809bb6be09c8 for example.
excatly but the issue is that the slab is not availlable yet
see 06fe53beb636294587d8e94ef83c06cef07c21fd
so init_name is still NULL :(

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Paul Mundt]

On Thu, Apr 28, 2011 at 04:45:59AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 11:09 Thu 28 Apr     , Paul Mundt wrote:
> > On Wed, Apr 27, 2011 at 05:00:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 12:47 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > On 12:31 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > On 09:42 Wed 27 Apr     , Russell King - ARM Linux wrote:
> > > > > > On Wed, Apr 20, 2011 at 04:05:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > > > early platform device may do not have a device name as the slab is not yet
> > > > > > > available. So to search a clock base on the dev_id we need to search first the
> > > > > > > device base name and then the id
> > > > > > 
> > > > > > I really don't like this.  IDs are platform device specific, and this is
> > > > > > a platform devince independent layer.
> > > > > > 
> > > > > > If you want to do this, then add a platform_device_clk_get() call, which
> > > > > > takes the platform device and connection id.  Uses the platform device
> > > > > > infrastructure to format the device name, and use clk_get_sys() to look
> > > > > > up the device/connection id from that.
> > > > > I do not want to alloc a string in the clkdev
> > > > > but if you prefer
> > > > I check we can not do so
> > > > if slab is not available we can not use kmalloc
> > > > 
> > > > so we can not generate the dev.init_name
> > > I check also we can not use the bootmem as it's too early in the init
> > > so allocate the dev_id is not possible
> > > 
> > > use a satic buffer I'm not so happy about it
> > > the only other solution is this one
> > > 
> > Are you willfully ignoring the init_name handling in
> > early_platform_driver_probe_id() or something?
> > 
> > See a636ee7fb35b731ba2b331f6294e809bb6be09c8 for example.
> excatly but the issue is that the slab is not availlable yet
> see 06fe53beb636294587d8e94ef83c06cef07c21fd
> so init_name is still NULL :(
> 
This is a non-argument until you demonstrate a use case where we have a
reasonable expectation for the clock framework to be available and the
slab allocator not.

If you're thinking about the SH earlyprintk case then I suggest you look
at the sh-sci driver to see how we presently deal with the situation
there.

Please do not make up imaginary problems, we have enough real ones to
focus energies on.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:08 Thu 28 Apr     , Paul Mundt wrote:
> On Thu, Apr 28, 2011 at 04:45:59AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 11:09 Thu 28 Apr     , Paul Mundt wrote:
> > > On Wed, Apr 27, 2011 at 05:00:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > On 12:47 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > On 12:31 Wed 27 Apr     , Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > > On 09:42 Wed 27 Apr     , Russell King - ARM Linux wrote:
> > > > > > > On Wed, Apr 20, 2011 at 04:05:14PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > > > > early platform device may do not have a device name as the slab is not yet
> > > > > > > > available. So to search a clock base on the dev_id we need to search first the
> > > > > > > > device base name and then the id
> > > > > > > 
> > > > > > > I really don't like this.  IDs are platform device specific, and this is
> > > > > > > a platform devince independent layer.
> > > > > > > 
> > > > > > > If you want to do this, then add a platform_device_clk_get() call, which
> > > > > > > takes the platform device and connection id.  Uses the platform device
> > > > > > > infrastructure to format the device name, and use clk_get_sys() to look
> > > > > > > up the device/connection id from that.
> > > > > > I do not want to alloc a string in the clkdev
> > > > > > but if you prefer
> > > > > I check we can not do so
> > > > > if slab is not available we can not use kmalloc
> > > > > 
> > > > > so we can not generate the dev.init_name
> > > > I check also we can not use the bootmem as it's too early in the init
> > > > so allocate the dev_id is not possible
> > > > 
> > > > use a satic buffer I'm not so happy about it
> > > > the only other solution is this one
> > > > 
> > > Are you willfully ignoring the init_name handling in
> > > early_platform_driver_probe_id() or something?
> > > 
> > > See a636ee7fb35b731ba2b331f6294e809bb6be09c8 for example.
> > excatly but the issue is that the slab is not availlable yet
> > see 06fe53beb636294587d8e94ef83c06cef07c21fd
> > so init_name is still NULL :(
> > 
> This is a non-argument until you demonstrate a use case where we have a
> reasonable expectation for the clock framework to be available and the
> slab allocator not.
> 
> If you're thinking about the SH earlyprintk case then I suggest you look
> at the sh-sci driver to see how we presently deal with the situation
> there.
the sh-sci driver expect the clock will enable for him
which did IIRC Magnus on sh-mobile
I do not want to do so

I've unfortunatly on at91 I use the early device during the map_io

so the slab is available and bootmem either

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

> > > > > 
> > > > Are you willfully ignoring the init_name handling in
> > > > early_platform_driver_probe_id() or something?
> > > > 
> > > > See a636ee7fb35b731ba2b331f6294e809bb6be09c8 for example.
> > > excatly but the issue is that the slab is not availlable yet
> > > see 06fe53beb636294587d8e94ef83c06cef07c21fd
> > > so init_name is still NULL :(
> > > 
> > This is a non-argument until you demonstrate a use case where we have a
> > reasonable expectation for the clock framework to be available and the
> > slab allocator not.
> > 
> > If you're thinking about the SH earlyprintk case then I suggest you look
> > at the sh-sci driver to see how we presently deal with the situation
> > there.
> the sh-sci driver expect the clock will enable for him
> which did IIRC Magnus on sh-mobile
> I do not want to do so
> 
> I've unfortunatly on at91 I use the early device during the map_io
> 
> so the slab is available and bootmem either
sorry none of theem is available yet

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:35 Thu 28 Apr     , Magnus Damm wrote:
> On Thu, Apr 28, 2011 at 12:20 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> >> > > > >
> >> > > > Are you willfully ignoring the init_name handling in
> >> > > > early_platform_driver_probe_id() or something?
> >> > > >
> >> > > > See a636ee7fb35b731ba2b331f6294e809bb6be09c8 for example.
> >> > > excatly but the issue is that the slab is not availlable yet
> >> > > see 06fe53beb636294587d8e94ef83c06cef07c21fd
> >> > > so init_name is still NULL :(
> >> > >
> >> > This is a non-argument until you demonstrate a use case where we have a
> >> > reasonable expectation for the clock framework to be available and the
> >> > slab allocator not.
> >> >
> >> > If you're thinking about the SH earlyprintk case then I suggest you look
> >> > at the sh-sci driver to see how we presently deal with the situation
> >> > there.
> >> the sh-sci driver expect the clock will enable for him
> >> which did IIRC Magnus on sh-mobile
> >> I do not want to do so
> >>
> >> I've unfortunatly on at91 I use the early device during the map_io
> 
> But so do we on SH-Mobile ARM.
> 
> >> so the slab is available and bootmem either
> > sorry none of theem is available yet
> 
> Sounds like you are aiming to use earlyprintk a little bit too early,
> or perhaps your idea of using clocks that early on is what is causing
> you trouble?
> 
> Why don't you move down your earlyprintk setup to a time when you have
> slabs available? Or for clocks, in the sh-sci driver we don't deal
> with clocks in the earlyprintk case.
> 
> I understand you want output as early as possible, but there is always
> going to be a time when you need to hack up some static serial output
> code.
I use it for gpio drivers that are init during map_io

so not yet for earlyprintk

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Magnus Damm]

On Thu, Apr 28, 2011 at 12:20 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
>> > > > >
>> > > > Are you willfully ignoring the init_name handling in
>> > > > early_platform_driver_probe_id() or something?
>> > > >
>> > > > See a636ee7fb35b731ba2b331f6294e809bb6be09c8 for example.
>> > > excatly but the issue is that the slab is not availlable yet
>> > > see 06fe53beb636294587d8e94ef83c06cef07c21fd
>> > > so init_name is still NULL :(
>> > >
>> > This is a non-argument until you demonstrate a use case where we have a
>> > reasonable expectation for the clock framework to be available and the
>> > slab allocator not.
>> >
>> > If you're thinking about the SH earlyprintk case then I suggest you look
>> > at the sh-sci driver to see how we presently deal with the situation
>> > there.
>> the sh-sci driver expect the clock will enable for him
>> which did IIRC Magnus on sh-mobile
>> I do not want to do so
>>
>> I've unfortunatly on at91 I use the early device during the map_io

But so do we on SH-Mobile ARM.

>> so the slab is available and bootmem either
> sorry none of theem is available yet

Sounds like you are aiming to use earlyprintk a little bit too early,
or perhaps your idea of using clocks that early on is what is causing
you trouble?

Why don't you move down your earlyprintk setup to a time when you have
slabs available? Or for clocks, in the sh-sci driver we don't deal
with clocks in the earlyprintk case.

I understand you want output as early as possible, but there is always
going to be a time when you need to hack up some static serial output
code.

/ magnus

[PATCH] clkdev: add support to lookup for early platform device

[Paul Mundt]

On Thu, Apr 28, 2011 at 05:17:04AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:08 Thu 28 Apr     , Paul Mundt wrote:
> > This is a non-argument until you demonstrate a use case where we have a
> > reasonable expectation for the clock framework to be available and the
> > slab allocator not.
> > 
> > If you're thinking about the SH earlyprintk case then I suggest you look
> > at the sh-sci driver to see how we presently deal with the situation
> > there.
> the sh-sci driver expect the clock will enable for him
> which did IIRC Magnus on sh-mobile
> I do not want to do so
> 
> I've unfortunatly on at91 I use the early device during the map_io
> 
> so the slab is available and bootmem either
> 
Yes, on sh-sci we assume that the clock is supplied to the port that we
are using for earlyprintk and we simply take over management of it via
the clock framework when the rest of the driver core comes online.

Oddly enough, 100% of the time that we've wanted to have a serial console
it's been on the same port as the boot loader, which has to do the
initialization anyways. If you're using JTAG or something else for
loading, you've already got to do register writes for setting up bus
timings and the like, so it's not obvious why you can't set up some
sensible defaults for the clock registers supplying your serial port,
either.

On top of that, ARM also has its own earlyprintk and eartly uart debug
macros available to you. If you're trying to bring more driver core stuff
online before either of slab or bootmem are available to you outside of
the context of the existing functionality: too bad. It's not worth the
world of pain for a corner case of a corner case.

Again, until you explain concretely why you have this as a real use case
that needs to be solved generically instead of some pointless theoretical
wanking it's simply not possible to take this requirement seriously. This
was the conclusion we came to when modelling the earlytimer and
earlyprintk code for SH in the first place, and the burden of proof is on
you to demonstrate why any of these things are insufficient for your
platform.

[PATCH] clkdev: add support to lookup for early platform device

[Magnus Damm]

On Thu, Apr 28, 2011 at 12:29 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 12:35 Thu 28 Apr ? ? , Magnus Damm wrote:
>> On Thu, Apr 28, 2011 at 12:20 PM, Jean-Christophe PLAGNIOL-VILLARD
>> <plagnioj@jcrosoft.com> wrote:
>> >> > > > >
>> >> > > > Are you willfully ignoring the init_name handling in
>> >> > > > early_platform_driver_probe_id() or something?
>> >> > > >
>> >> > > > See a636ee7fb35b731ba2b331f6294e809bb6be09c8 for example.
>> >> > > excatly but the issue is that the slab is not availlable yet
>> >> > > see 06fe53beb636294587d8e94ef83c06cef07c21fd
>> >> > > so init_name is still NULL :(
>> >> > >
>> >> > This is a non-argument until you demonstrate a use case where we have a
>> >> > reasonable expectation for the clock framework to be available and the
>> >> > slab allocator not.
>> >> >
>> >> > If you're thinking about the SH earlyprintk case then I suggest you look
>> >> > at the sh-sci driver to see how we presently deal with the situation
>> >> > there.
>> >> the sh-sci driver expect the clock will enable for him
>> >> which did IIRC Magnus on sh-mobile
>> >> I do not want to do so
>> >>
>> >> I've unfortunatly on at91 I use the early device during the map_io
>>
>> But so do we on SH-Mobile ARM.
>>
>> >> so the slab is available and bootmem either
>> > sorry none of theem is available yet
>>
>> Sounds like you are aiming to use earlyprintk a little bit too early,
>> or perhaps your idea of using clocks that early on is what is causing
>> you trouble?
>>
>> Why don't you move down your earlyprintk setup to a time when you have
>> slabs available? Or for clocks, in the sh-sci driver we don't deal
>> with clocks in the earlyprintk case.
>>
>> I understand you want output as early as possible, but there is always
>> going to be a time when you need to hack up some static serial output
>> code.
> I use it for gpio drivers that are init during map_io
>
> so not yet for earlyprintk

You may have explained this before, but why do you need to deal with
that early on?

Can't you simply setup the clocks statically for the early case?

/ magnus

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:38 Thu 28 Apr     , Paul Mundt wrote:
> On Thu, Apr 28, 2011 at 05:17:04AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 12:08 Thu 28 Apr     , Paul Mundt wrote:
> > > This is a non-argument until you demonstrate a use case where we have a
> > > reasonable expectation for the clock framework to be available and the
> > > slab allocator not.
> > > 
> > > If you're thinking about the SH earlyprintk case then I suggest you look
> > > at the sh-sci driver to see how we presently deal with the situation
> > > there.
> > the sh-sci driver expect the clock will enable for him
> > which did IIRC Magnus on sh-mobile
> > I do not want to do so
> > 
> > I've unfortunatly on at91 I use the early device during the map_io
> > 
> > so the slab is available and bootmem either
> > 
> Yes, on sh-sci we assume that the clock is supplied to the port that we
> are using for earlyprintk and we simply take over management of it via
> the clock framework when the rest of the driver core comes online.
> 
> Oddly enough, 100% of the time that we've wanted to have a serial console
> it's been on the same port as the boot loader, which has to do the
> initialization anyways. If you're using JTAG or something else for
> loading, you've already got to do register writes for setting up bus
> timings and the like, so it's not obvious why you can't set up some
> sensible defaults for the clock registers supplying your serial port,
> either.
> 
> On top of that, ARM also has its own earlyprintk and eartly uart debug
> macros available to you. If you're trying to bring more driver core stuff
> online before either of slab or bootmem are available to you outside of
> the context of the existing functionality: too bad. It's not worth the
> world of pain for a corner case of a corner case.
> 
> Again, until you explain concretely why you have this as a real use case
> that needs to be solved generically instead of some pointless theoretical
> wanking it's simply not possible to take this requirement seriously. This
> was the conclusion we came to when modelling the earlytimer and
> earlyprintk code for SH in the first place, and the burden of proof is on
> you to demonstrate why any of these things are insufficient for your
> platform.
in the map_io  I need to init the gpio drivers
and on AT91 we have between 3 and 5 pio bank which have different clock
and the resource for the gpio driver is soc specifc
so I switch the gpio driver to early device
so as the init of the gpio drivers I need to get the clock for each bank

as example on 9263
at91_gpio.0 use clock pioA
at91_gpio.1 use clock pioB
at91_gpio.2 use clock pioCDE
at91_gpio.3 use clock pioCDE
at91_gpio.4 use clock pioCDE

on 9g45
at91_gpio.0 use clock pioA
at91_gpio.1 use clock pioB
at91_gpio.2 use clock pioC
at91_gpio.3 use clock pioDE
at91_gpio.4 use clock pioDE

so I need to known the clock early if I want to be able to use the gpio
driver early

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Saravana Kannan]

On 04/27/2011 09:31 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:38 Thu 28 Apr     , Paul Mundt wrote:
>> On Thu, Apr 28, 2011 at 05:17:04AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 12:08 Thu 28 Apr     , Paul Mundt wrote:
>>>> This is a non-argument until you demonstrate a use case where we have a
>>>> reasonable expectation for the clock framework to be available and the
>>>> slab allocator not.
>>>>
>>>> If you're thinking about the SH earlyprintk case then I suggest you look
>>>> at the sh-sci driver to see how we presently deal with the situation
>>>> there.
>>> the sh-sci driver expect the clock will enable for him
>>> which did IIRC Magnus on sh-mobile
>>> I do not want to do so
>>>
>>> I've unfortunatly on at91 I use the early device during the map_io
>>>
>>> so the slab is available and bootmem either
>>>
>> Yes, on sh-sci we assume that the clock is supplied to the port that we
>> are using for earlyprintk and we simply take over management of it via
>> the clock framework when the rest of the driver core comes online.
>>
>> Oddly enough, 100% of the time that we've wanted to have a serial console
>> it's been on the same port as the boot loader, which has to do the
>> initialization anyways. If you're using JTAG or something else for
>> loading, you've already got to do register writes for setting up bus
>> timings and the like, so it's not obvious why you can't set up some
>> sensible defaults for the clock registers supplying your serial port,
>> either.
>>
>> On top of that, ARM also has its own earlyprintk and eartly uart debug
>> macros available to you. If you're trying to bring more driver core stuff
>> online before either of slab or bootmem are available to you outside of
>> the context of the existing functionality: too bad. It's not worth the
>> world of pain for a corner case of a corner case.
>>
>> Again, until you explain concretely why you have this as a real use case
>> that needs to be solved generically instead of some pointless theoretical
>> wanking it's simply not possible to take this requirement seriously. This
>> was the conclusion we came to when modelling the earlytimer and
>> earlyprintk code for SH in the first place, and the burden of proof is on
>> you to demonstrate why any of these things are insufficient for your
>> platform.
> in the map_io  I need to init the gpio drivers

Why? Are you under the impression that GPIO is IO and hence needs to be 
mapped by map_io?

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 21:46 Wed 27 Apr     , Saravana Kannan wrote:
> On 04/27/2011 09:31 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >On 12:38 Thu 28 Apr     , Paul Mundt wrote:
> >>On Thu, Apr 28, 2011 at 05:17:04AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>On 12:08 Thu 28 Apr     , Paul Mundt wrote:
> >>>>This is a non-argument until you demonstrate a use case where we have a
> >>>>reasonable expectation for the clock framework to be available and the
> >>>>slab allocator not.
> >>>>
> >>>>If you're thinking about the SH earlyprintk case then I suggest you look
> >>>>at the sh-sci driver to see how we presently deal with the situation
> >>>>there.
> >>>the sh-sci driver expect the clock will enable for him
> >>>which did IIRC Magnus on sh-mobile
> >>>I do not want to do so
> >>>
> >>>I've unfortunatly on at91 I use the early device during the map_io
> >>>
> >>>so the slab is available and bootmem either
> >>>
> >>Yes, on sh-sci we assume that the clock is supplied to the port that we
> >>are using for earlyprintk and we simply take over management of it via
> >>the clock framework when the rest of the driver core comes online.
> >>
> >>Oddly enough, 100% of the time that we've wanted to have a serial console
> >>it's been on the same port as the boot loader, which has to do the
> >>initialization anyways. If you're using JTAG or something else for
> >>loading, you've already got to do register writes for setting up bus
> >>timings and the like, so it's not obvious why you can't set up some
> >>sensible defaults for the clock registers supplying your serial port,
> >>either.
> >>
> >>On top of that, ARM also has its own earlyprintk and eartly uart debug
> >>macros available to you. If you're trying to bring more driver core stuff
> >>online before either of slab or bootmem are available to you outside of
> >>the context of the existing functionality: too bad. It's not worth the
> >>world of pain for a corner case of a corner case.
> >>
> >>Again, until you explain concretely why you have this as a real use case
> >>that needs to be solved generically instead of some pointless theoretical
> >>wanking it's simply not possible to take this requirement seriously. This
> >>was the conclusion we came to when modelling the earlytimer and
> >>earlyprintk code for SH in the first place, and the burden of proof is on
> >>you to demonstrate why any of these things are insufficient for your
> >>platform.
> >in the map_io  I need to init the gpio drivers
> 
> Why? Are you under the impression that GPIO is IO and hence needs to
> be mapped by map_io?
because today the at91 configure the serials at that time

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:38 Thu 28 Apr     , Paul Mundt wrote:
> On Thu, Apr 28, 2011 at 05:17:04AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 12:08 Thu 28 Apr     , Paul Mundt wrote:
> > > This is a non-argument until you demonstrate a use case where we have a
> > > reasonable expectation for the clock framework to be available and the
> > > slab allocator not.
> > > 
> > > If you're thinking about the SH earlyprintk case then I suggest you look
> > > at the sh-sci driver to see how we presently deal with the situation
> > > there.
> > the sh-sci driver expect the clock will enable for him
> > which did IIRC Magnus on sh-mobile
> > I do not want to do so
> > 
> > I've unfortunatly on at91 I use the early device during the map_io
> > 
> > so the slab is available and bootmem either
> > 
> Yes, on sh-sci we assume that the clock is supplied to the port that we
> are using for earlyprintk and we simply take over management of it via
> the clock framework when the rest of the driver core comes online.
> 
> Oddly enough, 100% of the time that we've wanted to have a serial console
> it's been on the same port as the boot loader, which has to do the
> initialization anyways. If you're using JTAG or something else for
> loading, you've already got to do register writes for setting up bus
> timings and the like, so it's not obvious why you can't set up some
> sensible defaults for the clock registers supplying your serial port,
> either.
> 
> On top of that, ARM also has its own earlyprintk and eartly uart debug
> macros available to you. If you're trying to bring more driver core stuff
> online before either of slab or bootmem are available to you outside of
> the context of the existing functionality: too bad. It's not worth the
> world of pain for a corner case of a corner case.
> 
> Again, until you explain concretely why you have this as a real use case
> that needs to be solved generically instead of some pointless theoretical
> wanking it's simply not possible to take this requirement seriously. This
> was the conclusion we came to when modelling the earlytimer and
> earlyprintk code for SH in the first place, and the burden of proof is on
> you to demonstrate why any of these things are insufficient for your
> platform.
How did you manage to get the clock for the earlytimer?

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Magnus Damm]

On Thu, Apr 28, 2011 at 2:12 PM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 12:38 Thu 28 Apr ? ? , Paul Mundt wrote:
>> On Thu, Apr 28, 2011 at 05:17:04AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> > On 12:08 Thu 28 Apr ? ? , Paul Mundt wrote:
>> > > This is a non-argument until you demonstrate a use case where we have a
>> > > reasonable expectation for the clock framework to be available and the
>> > > slab allocator not.
>> > >
>> > > If you're thinking about the SH earlyprintk case then I suggest you look
>> > > at the sh-sci driver to see how we presently deal with the situation
>> > > there.
>> > the sh-sci driver expect the clock will enable for him
>> > which did IIRC Magnus on sh-mobile
>> > I do not want to do so
>> >
>> > I've unfortunatly on at91 I use the early device during the map_io
>> >
>> > so the slab is available and bootmem either
>> >
>> Yes, on sh-sci we assume that the clock is supplied to the port that we
>> are using for earlyprintk and we simply take over management of it via
>> the clock framework when the rest of the driver core comes online.
>>
>> Oddly enough, 100% of the time that we've wanted to have a serial console
>> it's been on the same port as the boot loader, which has to do the
>> initialization anyways. If you're using JTAG or something else for
>> loading, you've already got to do register writes for setting up bus
>> timings and the like, so it's not obvious why you can't set up some
>> sensible defaults for the clock registers supplying your serial port,
>> either.
>>
>> On top of that, ARM also has its own earlyprintk and eartly uart debug
>> macros available to you. If you're trying to bring more driver core stuff
>> online before either of slab or bootmem are available to you outside of
>> the context of the existing functionality: too bad. It's not worth the
>> world of pain for a corner case of a corner case.
>>
>> Again, until you explain concretely why you have this as a real use case
>> that needs to be solved generically instead of some pointless theoretical
>> wanking it's simply not possible to take this requirement seriously. This
>> was the conclusion we came to when modelling the earlytimer and
>> earlyprintk code for SH in the first place, and the burden of proof is on
>> you to demonstrate why any of these things are insufficient for your
>> platform.
> How did you manage to get the clock for the earlytimer?

As you can see in the upstream SH-Mobile ARM code, the timer setup is
happening after the clocks have been initialized in the ->timer
callback in MACHINE_START()/MACHINE_END.

/ magnus

[PATCH] clkdev: add support to lookup for early platform device

[Russell King - ARM Linux]

On Thu, Apr 28, 2011 at 05:29:06AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> I use it for gpio drivers that are init during map_io

Why are you initializing hardware during map_io?  That's totally crazy.
Don't do that - the new mappings won't be flushed out of the cache/tlb
at that point, so it's going to be hit and miss whether you can access
the device without locking up the kernel.

Instead, use the early initialization hook which I've recently added for
this stuff, and keep the map_io for _only_ doing what the name says.

[PATCH] clkdev: add support to lookup for early platform device

[Russell King - ARM Linux]

On Thu, Apr 28, 2011 at 07:12:03AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> How did you manage to get the clock for the earlytimer?

This is getting silly.  "Let's move all our devices to early" is insane.
I can see someone then wanting an early-early-device because early has
become just too late in the initialization.

Come on guys, keep it simple and stop trying to contort the interfaces
you're given into doing things they're not designed to do.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 09:35 Thu 28 Apr     , Russell King - ARM Linux wrote:
> On Thu, Apr 28, 2011 at 07:12:03AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > How did you manage to get the clock for the earlytimer?
> 
> This is getting silly.  "Let's move all our devices to early" is insane.
> I can see someone then wanting an early-early-device because early has
> become just too late in the initialization.
> 
> Come on guys, keep it simple and stop trying to contort the interfaces
> you're given into doing things they're not designed to do.
I agress but I need to pass resources to the timer so early devices make sense

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 09:33 Thu 28 Apr     , Russell King - ARM Linux wrote:
> On Thu, Apr 28, 2011 at 05:29:06AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > I use it for gpio drivers that are init during map_io
> 
> Why are you initializing hardware during map_io?  That's totally crazy.
> Don't do that - the new mappings won't be flushed out of the cache/tlb
> at that point, so it's going to be hit and miss whether you can access
> the device without locking up the kernel.
> 
> Instead, use the early initialization hook which I've recently added for
> this stuff, and keep the map_io for _only_ doing what the name says.
cool which one?

Best Regards,
J.

[PATCH] clkdev: add support to lookup for early platform device

[Russell King - ARM Linux]

On Thu, Apr 28, 2011 at 11:26:13AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 09:35 Thu 28 Apr     , Russell King - ARM Linux wrote:
> > On Thu, Apr 28, 2011 at 07:12:03AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > How did you manage to get the clock for the earlytimer?
> > 
> > This is getting silly.  "Let's move all our devices to early" is insane.
> > I can see someone then wanting an early-early-device because early has
> > become just too late in the initialization.
> > 
> > Come on guys, keep it simple and stop trying to contort the interfaces
> > you're given into doing things they're not designed to do.
> I agress but I need to pass resources to the timer so early devices make
> sense

Again, you shouldn't be setting up the timer at map_io time - the kernel
just isn't ready for it.

map_io is meant just for setting up IO mappings.  You can then use the
init_early callback to register tables, setting up sched_clock, getting
the timer running for sched_clock, etc.  At this point, memblock must not
be used, but bootmem is active, but normal page allocation is not.

The clocksource/clockevent initialization should happen after that when
the system_timer->init function is called.

[PATCH] clkdev: add support to lookup for early platform device

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:07 Thu 28 Apr     , Russell King - ARM Linux wrote:
> On Thu, Apr 28, 2011 at 11:26:13AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 09:35 Thu 28 Apr     , Russell King - ARM Linux wrote:
> > > On Thu, Apr 28, 2011 at 07:12:03AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > How did you manage to get the clock for the earlytimer?
> > > 
> > > This is getting silly.  "Let's move all our devices to early" is insane.
> > > I can see someone then wanting an early-early-device because early has
> > > become just too late in the initialization.
> > > 
> > > Come on guys, keep it simple and stop trying to contort the interfaces
> > > you're given into doing things they're not designed to do.
> > I agress but I need to pass resources to the timer so early devices make
> > sense
> 
> Again, you shouldn't be setting up the timer at map_io time - the kernel
> just isn't ready for it.
> 
> map_io is meant just for setting up IO mappings.  You can then use the
> init_early callback to register tables, setting up sched_clock, getting
> the timer running for sched_clock, etc.  At this point, memblock must not
> be used, but bootmem is active, but normal page allocation is not.
> 
> The clocksource/clockevent initialization should happen after that when
> the system_timer->init function is called.
no the timer is init in the right place in system_timer->init

Best Regards,
J.