Skip to contentSkip to conversation

clkdev: add support to lookup for early platform device

PATCH New Jean-Christophe PLAGNIOL-VILLARD 6 participants 26 messages Apr 20, 2011 – Apr 28, 2011

Subsystems (2)
Clk API Arm/clkdev support
lore
Share & tools
lore

Jean-Christophe PLAGNIOL-VILLARD

author
#0 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

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 <[email protected]>
Cc Nicolas Ferre <[email protected]>
Cc Patrice Vilchez <[email protected]>
Cc Paul Mundt <[email protected]>
Cc Magnus Damm <[email protected]>
---
 drivers/clk/clkdev.c |   43 +++++++++++++++++++++++++++++++++++++------
 include/linux/clk.h  |   41 ++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 77 insertions(+), 7 deletions(-)
drivers/clk/clkdev.c +37 -6
index b9b949c2..8b50509 100644
@@ -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)
 {
include/linux/clk.h +40 -1

53 lines not on this page · raw message

Signature · 1 line
1.7.4.1
#1 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 3 lines · 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

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.

author
#2 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 5 lines · Russell King - ARM Linux
Quoted 3 lines · 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

Quoted 7 lines

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.

author
#3 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 9 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 8 lines · Russell King - ARM Linux
Quoted 3 lines · 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

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

Quoted 6 lines
Quoted 4 lines

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.

author
#4 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 14 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 13 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 12 lines · Russell King - ARM Linux
Quoted 3 lines · 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

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.

Quoted 6 lines
Quoted 2 lines

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.

#5 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 20 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 19 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 9 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 8 lines · Russell King - ARM Linux
Quoted 3 lines · 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

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

Quoted 6 lines
Quoted 4 lines

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

Quoted 8 lines
Quoted 1 line

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

#6 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

In reply to Jean-Christophe PLAGNIOL-VILLARD
Quoted 20 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 19 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 9 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 8 lines · Russell King - ARM Linux
Quoted 3 lines · 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

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

Quoted 6 lines
Quoted 4 lines

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

Quoted 7 lines
Quoted 1 line

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.

author
#7 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 25 lines · Paul Mundt
Quoted 24 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 14 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 13 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 12 lines · Russell King - ARM Linux
Quoted 3 lines · 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

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.

Quoted 6 lines
Quoted 2 lines

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

Quoted 7 lines
Quoted 3 lines

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.

#8 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 29 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 28 lines · Paul Mundt
Quoted 27 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 14 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 13 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 12 lines · Russell King - ARM Linux
Quoted 3 lines · 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

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.

Quoted 6 lines
Quoted 2 lines

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

Quoted 8 lines
Quoted 4 lines

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.

author
#9 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 38 lines · Paul Mundt
Quoted 29 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 28 lines · Paul Mundt
Quoted 27 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 14 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 13 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 12 lines · Russell King - ARM Linux
Quoted 3 lines · 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

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.

Quoted 6 lines
Quoted 2 lines

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

Quoted 8 lines
Quoted 4 lines

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 :(

Quoted 7 lines

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.

author
#10 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 16 lines
Quoted 9 lines
Quoted 9 lines
Quoted 5 lines
Quoted 1 line

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 :(

Quoted 7 lines

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.

Quoted 7 lines

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.

#11 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 13 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 13 lines
Quoted 13 lines
Quoted 9 lines
Quoted 5 lines
Quoted 1 line

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.

Quoted 8 lines
Quoted 8 lines
Quoted 3 lines

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.

Quoted 2 lines
Quoted 1 line

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

author
#12 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 33 lines · Magnus Damm
Quoted 13 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 13 lines
Quoted 13 lines
Quoted 9 lines
Quoted 5 lines
Quoted 1 line

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.

Quoted 8 lines
Quoted 8 lines
Quoted 3 lines

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.

Quoted 2 lines
Quoted 1 line

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?

Quoted 7 lines

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.

#13 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 38 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 37 lines · Magnus Damm
Quoted 13 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 13 lines
Quoted 13 lines
Quoted 9 lines
Quoted 5 lines
Quoted 1 line

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.

Quoted 8 lines
Quoted 8 lines
Quoted 3 lines

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.

Quoted 2 lines
Quoted 1 line

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.

Quoted 6 lines
Quoted 3 lines

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

#14 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

In reply to Jean-Christophe PLAGNIOL-VILLARD
Quoted 1 line · Jean-Christophe PLAGNIOL-VILLARD

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.

author
#15 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 10 lines · Russell King - ARM Linux
Quoted 1 line · Jean-Christophe PLAGNIOL-VILLARD

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.

#16 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

In reply to Jean-Christophe PLAGNIOL-VILLARD
Quoted 8 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 7 lines · Paul Mundt

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.

Quoted 8 lines

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.

author
#17 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 35 lines · Paul Mundt
Quoted 8 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 7 lines · Paul Mundt

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.

Quoted 8 lines

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.

Quoted 7 lines

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.

#18 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 36 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 35 lines · Paul Mundt
Quoted 8 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 7 lines · Paul Mundt

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.

Quoted 8 lines

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.

Quoted 8 lines
Quoted 7 lines

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

Signature · 2 lines
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
author
#19 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 44 lines · Saravana Kannan
Quoted 43 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 42 lines · Paul Mundt
Quoted 8 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 7 lines · Paul Mundt

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.

Quoted 8 lines

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.

Quoted 4 lines
Quoted 1 line

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.

author
#20 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

In reply to Paul Mundt
Quoted 35 lines · Paul Mundt
Quoted 8 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 7 lines · Paul Mundt

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.

Quoted 8 lines

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.

Quoted 7 lines

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.

#21 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 36 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 35 lines · Paul Mundt
Quoted 8 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 7 lines · Paul Mundt

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.

Quoted 8 lines

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.

Quoted 8 lines
Quoted 7 lines

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

#22 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

In reply to Jean-Christophe PLAGNIOL-VILLARD
Quoted 1 line · Jean-Christophe PLAGNIOL-VILLARD

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.

author
#23 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 9 lines · Russell King - ARM Linux
Quoted 1 line · Jean-Christophe PLAGNIOL-VILLARD

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.

#24 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 4 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 3 lines · Russell King - ARM Linux
Quoted 1 line · Jean-Christophe PLAGNIOL-VILLARD

How did you manage to get the clock for the earlytimer?

Quoted 8 lines
Quoted 6 lines

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.

author
#25 lore raw

PATCH 1/1 clkdev: add support to lookup for early platform device

Quoted 17 lines · Russell King - ARM Linux
Quoted 4 lines · Jean-Christophe PLAGNIOL-VILLARD
Quoted 3 lines · Russell King - ARM Linux
Quoted 1 line · Jean-Christophe PLAGNIOL-VILLARD

How did you manage to get the clock for the earlytimer?

Quoted 8 lines
Quoted 6 lines

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.

Quoted 7 lines

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.