Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
Hi Tony,
On 9/2/2011 10:09 AM, Tony Lindgren wrote:
Hi,
* Benoit Cousson [110901 19:52]:
Create an OMAP3 generic board to start the DT migration.
I don't think this needs to be SoC specific, we can add multiple
DT_MACHINE_START entries into a single file. So it should be
just board-omap-dt.c.
I do agree, it should not, I made that comment into the
board-omap4-dt.c, but for the moment we still have dedicated OMAP
specifics stuff at board level, like the map_io.
I have an other series that make the map_io DT aware to get rid of that,
but it still not finalized.
My goal was have a single DT_MACHINE_START for every OMAPs.
But, meanwhile, if you prefer one file with many board descriptors,
that's fine.
+#include "mux.h"
+#include "common-board-devices.h"
+#include "sdram-micron-mt46h32m32lf-6.h"
+
+
+static void __init omap3_init_early(void)
+{
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
+ mt46h32m32lf6_sdrc_params);
+}
This has changed, see the cleanup branch. Also, let's just leave
out the sdram timings for now as we can work with bootloader
timings until those come from DT too.
Yep, I know, but since that series is based on my previous series that
is based on mainline rc-3, I missed these.
Now, that kernel.org is back, I'll pull you branches :-).
Which one do you recommend in that case, master or cleanup?
+static void __init omap3_init(void)
+{
+ struct device_node *node;
+
+ node = of_find_matching_node(NULL, omap_dt_intc_match);
+ if (node)
+ irq_domain_add_simple(node, 0);
+
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_serial_init();
+
+ of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+}
+
+static const char *omap3_dt_match[] __initdata = {
+ "ti,omap3",
+ NULL
+};
Most likely we just need SoC specific init functions in this file
now until the mux data comes from DT also.
OK, I can get rid of mux stuff then.
+DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3_init_early,
+ .init_irq = omap3_init_irq,
+ .init_machine = omap3_init,
+ .timer =&omap3_timer,
+ .dt_compat = omap3_dt_match,
+MACHINE_END
Here omap3_init_early is now generic in the cleanup branch.
Cool, I'll update the whole series, including the OMAP4 ones.
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
* Benoit Cousson [110901 19:52]: > In order to avoid conflict with the new board-omap3-dt.c file, > remove the .dt_compat entry from the beagle regular board > file. > > Any DT work for OMAP3 will have to be done on the generic DT > board file to avoid breaking the legacy board support until > DT migration is done. In general we should not keep duplicate old non-DT data around now that we have the DT append support. Instead we should just require the .dts file appended to zImage for all mach-omap2 machines. Otherwise we'll end up with double bloat :) So it's OK to have the DT entries in board files so drivers that get converted will work with them. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
On 9/2/2011 10:12 AM, Tony Lindgren wrote: * Benoit Cousson [110901 19:52]: In order to avoid conflict with the new board-omap3-dt.c file, remove the .dt_compat entry from the beagle regular board file. Any DT work for OMAP3 will have to be done on the generic DT board file to avoid breaking the legacy board support until DT migration is done. In general we should not keep duplicate old non-DT data around now that we have the DT append support. Instead we should just require the .dts file appended to zImage for all mach-omap2 machines. Otherwise we'll end up with double bloat :) Mmm, I'm not sure to get your point. We are not duplicating, since a pure DT generic board will not have anything except a of_platform_populate(NULL, omap_dt_match_table, NULL, NULL); And the regular board files will keep initializing devices statically. The drivers will then for the moment support both pdata and DT method to get board parameters. So it's OK to have the DT entries in board files so drivers that get converted will work with them. Well, it will be a little bit more tricky, because having DT in current board files will be a mess with a bunch of #ifdef CONFIG_OF, and adding DT compatible inside each boards will prevent the pure generic DT one to work. In that case we will duplicate the DT migration in every legacy boards files... That's why the current strategy is to keep the current board files non-DT aware and add the DT support only to the generic DT board file. Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
Hi,
* Benoit Cousson [110901 19:52]:
> Create an OMAP3 generic board to start the DT migration.
I don't think this needs to be SoC specific, we can add multiple
DT_MACHINE_START entries into a single file. So it should be
just board-omap-dt.c.
> +#include "mux.h"
> +#include "common-board-devices.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +
> +
> +static void __init omap3_init_early(void)
> +{
> + omap2_init_common_infrastructure();
> + omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
> + mt46h32m32lf6_sdrc_params);
> +}
This has changed, see the cleanup branch. Also, let's just leave
out the sdram timings for now as we can work with bootloader
timings until those come from DT too.
> +static void __init omap3_init(void)
> +{
> + struct device_node *node;
> +
> + node = of_find_matching_node(NULL, omap_dt_intc_match);
> + if (node)
> + irq_domain_add_simple(node, 0);
> +
> + omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> + omap_serial_init();
> +
> + of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> +}
> +
> +static const char *omap3_dt_match[] __initdata = {
> + "ti,omap3",
> + NULL
> +};
Most likely we just need SoC specific init functions in this file
now until the mux data comes from DT also.
> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
> + .reserve= omap_reserve,
> + .map_io = omap3_map_io,
> + .init_early = omap3_init_early,
> + .init_irq = omap3_init_irq,
> + .init_machine = omap3_init,
> + .timer = &omap3_timer,
> + .dt_compat = omap3_dt_match,
> +MACHINE_END
Here omap3_init_early is now generic in the cleanup branch.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote: > Now, that kernel.org is back, I'll pull you branches :-). Umm. Are you sure? What are you checking - that some kernel.org servers are reachable or that master.kernel.org is reachable (it isn't.) ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote: On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote: Now, that kernel.org is back, I'll pull you branches :-). Umm. Are you sure? What are you checking - that some kernel.org servers are reachable or that master.kernel.org is reachable (it isn't.) I was not about to fetch git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git yesterday, but it works today. Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
On Fri, Sep 02, 2011 at 11:13:03AM +0200, Cousson, Benoit wrote: > On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote: >> On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote: >>> Now, that kernel.org is back, I'll pull you branches :-). >> >> Umm. Are you sure? What are you checking - that some kernel.org >> servers are reachable or that master.kernel.org is reachable (it >> isn't.) > > I was not about to fetch > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git > yesterday, but it works today. git.kernel.org != master.kernel.org. git.kernel.org is an alias for a set of servers which are selected depending on your geographical location, whereas master.kernel.org a single machine to which we upload our trees and which has been down since Wednesday. I don't believe master.kernel.org is part of the public serving infrastructure (it certainly never used to be.) So, I suspect your non-reachability of git.kernel.org yesterday was due to some other problem. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
On 9/2/2011 11:21 AM, Russell King - ARM Linux wrote: On Fri, Sep 02, 2011 at 11:13:03AM +0200, Cousson, Benoit wrote: On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote: On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote: Now, that kernel.org is back, I'll pull you branches :-). Umm. Are you sure? What are you checking - that some kernel.org servers are reachable or that master.kernel.org is reachable (it isn't.) I was not about to fetch git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git yesterday, but it works today. git.kernel.org != master.kernel.org. git.kernel.org is an alias for a set of servers which are selected depending on your geographical location, whereas master.kernel.org a single machine to which we upload our trees and which has been down since Wednesday. I don't believe master.kernel.org is part of the public serving infrastructure (it certainly never used to be.) Interesting, thanks for the explanations. So, I suspect your non-reachability of git.kernel.org yesterday was due to some other problem. OK, maybe. The good point is that now it works :-) The bad point is that Kevin cannot push his updated branches, so I still do not have the latest :-( Thanks, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
* Cousson, Benoit [110902 11:13]: > Hi Tony, > > On 9/2/2011 10:09 AM, Tony Lindgren wrote: > >Hi, > > > >* Benoit Cousson [110901 19:52]: > >>Create an OMAP3 generic board to start the DT migration. > > > >I don't think this needs to be SoC specific, we can add multiple > >DT_MACHINE_START entries into a single file. So it should be > >just board-omap-dt.c. > > I do agree, it should not, I made that comment into the > board-omap4-dt.c, but for the moment we still have dedicated OMAP > specifics stuff at board level, like the map_io. Well map_io can also be set in DT_MACHINE_START. For most part it already is generic like omap3_map_io and omap4_map_io. So that should not stop anything. > I have an other series that make the map_io DT aware to get rid of > that, but it still not finalized. Hmm maybe take a look again? We've already sorted out quite a bit of the init stuff over past few merge windows. If there's still something blocking that, let's clear it out ASAP. > My goal was have a single DT_MACHINE_START for every OMAPs. > But, meanwhile, if you prefer one file with many board descriptors, > that's fine. Yes that's better. We should only need a separate DT_MACHINE_START for major SoC variants. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
* Cousson, Benoit [110902 11:26]: > On 9/2/2011 10:12 AM, Tony Lindgren wrote: > >* Benoit Cousson [110901 19:52]: > >>In order to avoid conflict with the new board-omap3-dt.c file, > >>remove the .dt_compat entry from the beagle regular board > >>file. > >> > >>Any DT work for OMAP3 will have to be done on the generic DT > >>board file to avoid breaking the legacy board support until > >>DT migration is done. > > > >In general we should not keep duplicate old non-DT data around > >now that we have the DT append support. Instead we should just > >require the .dts file appended to zImage for all mach-omap2 > >machines. Otherwise we'll end up with double bloat :) > > Mmm, I'm not sure to get your point. We are not duplicating, since a > pure DT generic board will not have anything except a > of_platform_populate(NULL, omap_dt_match_table, NULL, NULL); > And the regular board files will keep initializing devices statically. > The drivers will then for the moment support both pdata and DT > method to get board parameters. Well when converting a driver to DT, we should just drop pdata support. No need to keep it around as it will just make it harder for us to clean up afterwards. > >So it's OK to have the DT entries in board files so drivers > >that get converted will work with them. > > Well, it will be a little bit more tricky, because having DT in > current board files will be a mess with a bunch of #ifdef CONFIG_OF, > and adding DT compatible inside each boards will prevent the pure > generic DT one to work. In that case we will duplicate the DT > migration in every legacy boards files... We should just select CONFIG_OF deal with it that way. > That's why the current strategy is to keep the current board files > non-DT aware and add the DT support only to the generic DT board > file. Well I don't like that, it will be a big mess. We'll end up with twice the amount of platform_data and init code. It's OK to require CONFIG_OF as it's known to work with the append support for older boards. It's easier just to require DT append for all the boards. In most cases it's just a trivial include of the common dts file for now. When we convert something to DT, there's no point going back. Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
On 9/2/2011 12:43 PM, Tony Lindgren wrote:
> * Cousson, Benoit [110902 11:13]:
>> Hi Tony,
>>
>> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
>>> Hi,
>>>
>>> * Benoit Cousson [110901 19:52]:
Create an OMAP3 generic board to start the DT migration.
>>>
>>> I don't think this needs to be SoC specific, we can add multiple
>>> DT_MACHINE_START entries into a single file. So it should be
>>> just board-omap-dt.c.
>>
>> I do agree, it should not, I made that comment into the
>> board-omap4-dt.c, but for the moment we still have dedicated OMAP
>> specifics stuff at board level, like the map_io.
>
> Well map_io can also be set in DT_MACHINE_START. For most part
> it already is generic like omap3_map_io and omap4_map_io.
> So that should not stop anything.
OK, I think I was trying to be a little bit more extreme, meaning only one
omap_map_io for every OMAPs.
Then, inside omap_map_io we can use the DT compatible information to retrieve
the proper OMAPs revision and thus use the proper init table.
Whereas in your case you are still relying on the various DT_MACHINE entries to
detect which OMAP revision is used.
It looks to me that relying on several DT_MACHINE_START to identify a SoC
version is a little bit more a hack.
I will let the device-tree experts answering that question :-)
For my point of view, using DT compatible in the various place where the OMAP
revision is important, might allow a finer granularity.
>> I have an other series that make the map_io DT aware to get rid of
>> that, but it still not finalized.
>
> Hmm maybe take a look again? We've already sorted out quite a bit
> of the init stuff over past few merge windows. If there's still
> something blocking that, let's clear it out ASAP.
Now that I understand your approach, it is fine. Please find below an example
of what I was trying to achieve, and why that point was an issue.
The clear advantage of your method is that not further effort will be require
for this part. At least for the moment.
>> My goal was have a single DT_MACHINE_START for every OMAPs.
>> But, meanwhile, if you prefer one file with many board descriptors,
>> that's fine.
>
> Yes that's better. We should only need a separate DT_MACHINE_START
> for major SoC variants.
OK, I'll try that.
Thanks,
Benoit
---
>From a8edcd113b6fa38620dae11bcbb55daa84dfb07c Mon Sep 17 00:00:00 2001
From: Benoit Cousson
Date: Mon, 22 Aug 2011 11:10:38 +0200
Subject: [PATCH] OMAP2+: Add a common method to init globals using DT compatible
Thanks to the DT root node compatible information, we can extract
the compatible SoC and use it to select the proper globals.
Create a common omap2_set_globals API that can be used by every
OMAP2+ platforms.
Signed-off-by: Benoit Cousson
Cc: Tony Lindgren
---
arch/arm/mach-omap2/common.c | 73 ++
arch/arm/plat-omap/include/plat/common.h |1 +
2 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 3f20cbb..ee5a225 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -140,3 +141,75 @@ void __init omap2_set_globals_443x(void)
}
#endif
+#ifdef CONFIG_OF
+/*
+ * DT method to get the proper globals configuration
+ */
+static const struct of_device_id omap_soc_match[] = {
+#if defined(CONFIG_ARCH_OMAP4)
+{
+.compatible = "ti,omap4",
+.data = &omap4_globals,
+},
+#endif
+#if defined(CONFIG_ARCH_OMAP3)
+{
+.compatible = "ti,omap3",
+.data = &omap3_globals,
+},
+#endif
+#if defined(CONFIG_SOC_OMAP2430)
+{
+.compatible = "ti,omap2430",
+.data = &omap243x_globals,
+},
+#endif
+#if defined(CONFIG_SOC_OMAP2420)
+{
+.compatible = "ti,omap2420",
+.data = &omap242x_globals,
+},
+#endif
+ {},
+};
+
+/* Helper to find the proper of_device_id from a FDT */
+static __init const struct of_device_id *_fdt_match_node(
+ const struct of_device_id *matches,
+ int fdt_node)
+{
+ unsigned int score = 0;
+
+ if (!matches)
+ return NULL;
+
+ while (matches->compatible[0]) {
+ score = of_flat_dt_is_compatible(fdt_node, matches->compatible);
+ if (score > 0)
+ return matches;
+ matches++;
+ }
+ return NULL;
+}
+
+void __init omap2_set_globals(void)
+{
+unsigned long fdt_root;
+ const struct of_device_id *match;
+
+ /* the DT is still flat at map_io time... */
+fdt_root = of_get_flat_dt_root();
+ match = _fdt_match_node(omap_soc_match, fdt_root);
+ if (!match) {
+ pr_err("%s(): Cannot initialize the platform global
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
* Cousson, Benoit [110902 14:10]: > On 9/2/2011 12:43 PM, Tony Lindgren wrote: > > * Cousson, Benoit [110902 11:13]: > >> Hi Tony, > >> > >> On 9/2/2011 10:09 AM, Tony Lindgren wrote: > >>> Hi, > >>> > >>> * Benoit Cousson [110901 19:52]: > Create an OMAP3 generic board to start the DT migration. > >>> > >>> I don't think this needs to be SoC specific, we can add multiple > >>> DT_MACHINE_START entries into a single file. So it should be > >>> just board-omap-dt.c. > >> > >> I do agree, it should not, I made that comment into the > >> board-omap4-dt.c, but for the moment we still have dedicated OMAP > >> specifics stuff at board level, like the map_io. > > > > Well map_io can also be set in DT_MACHINE_START. For most part > > it already is generic like omap3_map_io and omap4_map_io. > > So that should not stop anything. > > OK, I think I was trying to be a little bit more extreme, meaning only one > omap_map_io for every OMAPs. > Then, inside omap_map_io we can use the DT compatible information to retrieve > the proper OMAPs revision and thus use the proper init table. > > Whereas in your case you are still relying on the various DT_MACHINE entries > to detect which OMAP revision is used. Sure that can be changed. But why not get the whole data that's now in various structs from DT too? It's just something like: .class = OMAP243X_CLASS, .tap= OMAP2_L4_IO_ADDRESS(0x4900a000), .sdrc = OMAP243X_SDRC_BASE, .sms= OMAP243X_SMS_BASE, .ctrl = OMAP243X_CTRL_BASE, .prm= OMAP2430_PRM_BASE, .cm = OMAP2430_CM_BASE, And all these could be just defined in DT right? > It looks to me that relying on several DT_MACHINE_START to identify a SoC > version is a little bit more a hack. > I will let the device-tree experts answering that question :-) > For my point of view, using DT compatible in the various place where the OMAP > revision is important, might allow a finer granularity. Sure I agree. > >> I have an other series that make the map_io DT aware to get rid of > >> that, but it still not finalized. > > > > Hmm maybe take a look again? We've already sorted out quite a bit > > of the init stuff over past few merge windows. If there's still > > something blocking that, let's clear it out ASAP. > > Now that I understand your approach, it is fine. Please find below an example > of what I was trying to achieve, and why that point was an issue. > The clear advantage of your method is that not further effort will be require > for this part. At least for the moment. Well I guess the globals could come from device tree still :) In general, I'd like to get rid of the cpu_is_omap stuff and SoC detection early as that always requires DEBUG_LL to see any decent debug info when things go wrong. If we get the SoC major type from DT, then we only need to do SoC specific ES revision and GP/HS omap detection. And that's very simple code compared to the current cpu_is_omap stuff. Then we can boot with the DT information pretty far to map_io and initialize low-level serial console, and then set up things further while having a decent console ;) Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
On 9/2/2011 1:57 PM, Tony Lindgren wrote: * Cousson, Benoit [110902 14:10]: On 9/2/2011 12:43 PM, Tony Lindgren wrote: * Cousson, Benoit [110902 11:13]: Hi Tony, On 9/2/2011 10:09 AM, Tony Lindgren wrote: Hi, * Benoit Cousson[110901 19:52]: Create an OMAP3 generic board to start the DT migration. I don't think this needs to be SoC specific, we can add multiple DT_MACHINE_START entries into a single file. So it should be just board-omap-dt.c. I do agree, it should not, I made that comment into the board-omap4-dt.c, but for the moment we still have dedicated OMAP specifics stuff at board level, like the map_io. Well map_io can also be set in DT_MACHINE_START. For most part it already is generic like omap3_map_io and omap4_map_io. So that should not stop anything. OK, I think I was trying to be a little bit more extreme, meaning only one omap_map_io for every OMAPs. Then, inside omap_map_io we can use the DT compatible information to retrieve the proper OMAPs revision and thus use the proper init table. Whereas in your case you are still relying on the various DT_MACHINE entries to detect which OMAP revision is used. Sure that can be changed. But why not get the whole data that's now in various structs from DT too? It's just something like: .class = OMAP243X_CLASS, .tap= OMAP2_L4_IO_ADDRESS(0x4900a000), BTW, how can we get rid of that OMAP2_L4_IO_ADDRESS? .sdrc = OMAP243X_SDRC_BASE, .sms= OMAP243X_SMS_BASE, .ctrl = OMAP243X_CTRL_BASE, .prm= OMAP2430_PRM_BASE, .cm = OMAP2430_CM_BASE, And all these could be just defined in DT right? Hehe, it is just a phase-one-proof-of-concept... the phase two was supposed to move that to DT. But for the moment, I was trying to have a more conservative approach using the existing data like for hwmod. The other point is that we still have to deal with the FDT at that point, the DT is not yest available that why I didn't extract too many informations from the FDT. Moreover, in theory, these informations will not be mixed like today, but will be in their own relevant DT nodes, somewhere inside the tree. Bottomline... it was a little bit more tricky. It looks to me that relying on several DT_MACHINE_START to identify a SoC version is a little bit more a hack. I will let the device-tree experts answering that question :-) For my point of view, using DT compatible in the various place where the OMAP revision is important, might allow a finer granularity. Sure I agree. I have an other series that make the map_io DT aware to get rid of that, but it still not finalized. Hmm maybe take a look again? We've already sorted out quite a bit of the init stuff over past few merge windows. If there's still something blocking that, let's clear it out ASAP. Now that I understand your approach, it is fine. Please find below an example of what I was trying to achieve, and why that point was an issue. The clear advantage of your method is that not further effort will be require for this part. At least for the moment. Well I guess the globals could come from device tree still :) Fully agree. It just needs some more time :-) In general, I'd like to get rid of the cpu_is_omap stuff and SoC detection early as that always requires DEBUG_LL to see any decent debug info when things go wrong. If we get the SoC major type from DT, then we only need to do SoC specific ES revision and GP/HS omap detection. And that's very simple code compared to the current cpu_is_omap stuff. In fact only the tap should be required at map_io time to get the DEVICE_ID, I guess that the others entries could be retrieve later? .sdrc = OMAP243X_SDRC_BASE, .sms= OMAP243X_SMS_BASE, .ctrl = OMAP243X_CTRL_BASE, .prm= OMAP2430_PRM_BASE, .cm = OMAP2430_CM_BASE, If this is the case, we can then add a DEVICE_ID address entry in DT root to be retrieved easily with the FDT. Then we can boot with the DT information pretty far to map_io and initialize low-level serial console, and then set up things further while having a decent console ;) Yeah! The holy grail. Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
* Cousson, Benoit [110902 14:47]: > > .tap= OMAP2_L4_IO_ADDRESS(0x4900a000), > > BTW, how can we get rid of that OMAP2_L4_IO_ADDRESS? That needs to be mapped early for SoC detection to work for cpu_is_omap stuff :( > In fact only the tap should be required at map_io time to get the > DEVICE_ID, I guess that the others entries could be retrieve later? Yes well whatever needs to be mapped early for the SoC revision detection. It could be that we can map timers and serial port only early, then set up the mappings for the rest later on. That is if we can avoid SoC and revision detection early. Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
On 9/2/2011 12:48 PM, Tony Lindgren wrote: * Cousson, Benoit [110902 11:26]: On 9/2/2011 10:12 AM, Tony Lindgren wrote: * Benoit Cousson [110901 19:52]: In order to avoid conflict with the new board-omap3-dt.c file, remove the .dt_compat entry from the beagle regular board file. Any DT work for OMAP3 will have to be done on the generic DT board file to avoid breaking the legacy board support until DT migration is done. In general we should not keep duplicate old non-DT data around now that we have the DT append support. Instead we should just require the .dts file appended to zImage for all mach-omap2 machines. Otherwise we'll end up with double bloat :) Mmm, I'm not sure to get your point. We are not duplicating, since a pure DT generic board will not have anything except a of_platform_populate(NULL, omap_dt_match_table, NULL, NULL); And the regular board files will keep initializing devices statically. The drivers will then for the moment support both pdata and DT method to get board parameters. Well when converting a driver to DT, we should just drop pdata support. No need to keep it around as it will just make it harder for us to clean up afterwards. I'm not sure it is that simple. We have 20+ OMAP3+ boards supported so far. Dropping pdata when a driver is adapted means that all these boards should be properly adapted to DT and tested... (board-XXX.dts + board-XXX.c). That's a huge effort for my point of view. Whereas keeping the legacy pdata method will allow progressing on the boart-dt only without breaking any legacy boards. It will allow the board manufacturers to potentially do the DTS file for their own system using then the generic board-dt.c file. That being said, keeping the legacy pdata code in some driver along with the DT is a big pain as well:-( In some cases, DT can even provide some good way to encode HW information that we do not have today with hwmod/omap_device. So in that case we do not even have any alternative method yet. So it's OK to have the DT entries in board files so drivers that get converted will work with them. Well, it will be a little bit more tricky, because having DT in current board files will be a mess with a bunch of #ifdef CONFIG_OF, and adding DT compatible inside each boards will prevent the pure generic DT one to work. In that case we will duplicate the DT migration in every legacy boards files... We should just select CONFIG_OF deal with it that way. That's why the current strategy is to keep the current board files non-DT aware and add the DT support only to the generic DT board file. Well I don't like that, it will be a big mess. We'll end up with twice the amount of platform_data and init code. It's OK to require CONFIG_OF as it's known to work with the append support for older boards. It's easier just to require DT append for all the boards. In most cases it's just a trivial include of the common dts file for now. That part is easy indeed, this is hacking every board-XXX.c and testing them that will be tricky. This is as well the board specifics settings that are tricky not the generic OMAP stuff. We do have to set GPIOs, pin mux, regulator bindings, audio codec stuff... When we convert something to DT, there's no point going back. Agree on that, in theory, I'm just wondering how practical it will be to progress on every board at the same time. I guess we do need some advice from the DT gurus on that as well. It looks to me that both approaches are painful and will require some efforts. It is too bad that nobody did a devicetree-migration-o-matic-for-lazy-developer.py script to handle that... Regards, Benoit ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
* Cousson, Benoit [110902 15:02]: > On 9/2/2011 12:48 PM, Tony Lindgren wrote: > > I'm not sure it is that simple. We have 20+ OMAP3+ boards supported > so far. Dropping pdata when a driver is adapted means that all these > boards should be properly adapted to DT and tested... (board-XXX.dts > + board-XXX.c). > That's a huge effort for my point of view. Whereas keeping the > legacy pdata method will allow progressing on the boart-dt only > without breaking any legacy boards. It will allow the board > manufacturers to potentially do the DTS file for their own system > using then the generic board-dt.c file. Yeah but we've seen how badly "we'll clean it up later" approach works :( Unfortunately that path means nobody comes back to clean-up anything after the party is over and all that work falls on the maintainers. So the one driver at a time conversion approach is better. > That being said, keeping the legacy pdata code in some driver along > with the DT is a big pain as well:-( Yup and duplicate data will lead to nasty bugs and support issues. > >It's easier just to require DT append for all the boards. In most > >cases it's just a trivial include of the common dts file for now. > > That part is easy indeed, this is hacking every board-XXX.c and > testing them that will be tricky. This is as well the board > specifics settings that are tricky not the generic OMAP stuff. We do > have to set GPIOs, pin mux, regulator bindings, audio codec stuff... Right but for most part it's just removing the data. The board specific things are usually number of MMC data lines, number of USB transceiver data lines, GPIO to enable etc. Pretty trivial stuff that the board maintainers can test. > >When we convert something to DT, there's no point going back. > > Agree on that, in theory, I'm just wondering how practical it will > be to progress on every board at the same time. That should not be too bad for most part. For example, the board-*.c files all just call omap_register_i2c_bus with the controllers. So not much there to convert, just add the controllers to board .dts files and remove from board-*.c files. > I guess we do need some advice from the DT gurus on that as well. > > It looks to me that both approaches are painful and will require > some efforts. Yes, but if we don't drop the pdata then we'll be in half-converted state eternally. > It is too bad that nobody did a > devicetree-migration-o-matic-for-lazy-developer.py script to handle > that... The conversion for some drivers can be scripted for sure :) Regards, Tony ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 RESEND] gpio-vx855: add device tree binding
This is needed to enable the HDD LED on the OLPC XO-1.5 laptop, enabled through devicetree and the gpio-leds driver. Signed-off-by: Daniel Drake --- .../devicetree/bindings/gpio/gpio_vx855.txt| 20 drivers/gpio/gpio-vx855.c |5 + 2 files changed, 25 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio_vx855.txt v2: extended the documentation with information about the pin numbering scheme, which matches that of the driver. diff --git a/Documentation/devicetree/bindings/gpio/gpio_vx855.txt b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt new file mode 100644 index 000..17285a5 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio_vx855.txt @@ -0,0 +1,20 @@ +VIA VX855 GPIO controller + +Required properties: +- compatible : "via,vx855-gpio" +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted) +- gpio-controller : Marks the device node as a GPIO controller. + +As VIA differentiates between GPI, GPO and GPIO on its 42 available pins, +with each pin type restarting numbering at 0, the following numbering scheme +is used in the device tree for the pin number: + +PIN NO VIA NAME +0..13 GPI 0..13 +14..26 GPO 0..12 +27..41 GPIO 0..14 + +For example, GPIO 11 (VIA name) is referred to with pin number 38 in the +device tree. diff --git a/drivers/gpio/gpio-vx855.c b/drivers/gpio/gpio-vx855.c index ef5aabd..5b7e9ba 100644 --- a/drivers/gpio/gpio-vx855.c +++ b/drivers/gpio/gpio-vx855.c @@ -31,6 +31,7 @@ #include #include #include +#include #define MODULE_NAME "vx855_gpio" @@ -216,6 +217,10 @@ static void vx855gpio_gpio_setup(struct vx855_gpio *vg) c->ngpio = NR_VX855_GP; c->can_sleep = 0; c->names = vx855gpio_names; + +#ifdef CONFIG_OF_GPIO + c->of_node = of_find_compatible_node(NULL, NULL, "via,vx855-gpio"); +#endif } /* This platform device is ordinarily registered by the vx855 mfd driver */ -- 1.7.6 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2] powerpc/85xx: Adding DCSR node to dtsi device trees
From: Stephen George
Adding new device tree binding file for the DCSR node. Modifying device
tree dtsi files to add DCSR node for P2041, P3041, P3060, P4080, & P5020.
Signed-off-by: Stephen George
Signed-off-by: Kumar Gala
---
v2:
* include dscr.txt binding spec
* moved around dcsr nodes to keep sorted in addr order
.../devicetree/bindings/powerpc/fsl/dcsr.txt | 395
arch/powerpc/boot/dts/p2041rdb.dts |4 +
arch/powerpc/boot/dts/p2041si.dtsi | 71 -
arch/powerpc/boot/dts/p3041ds.dts |4 +
arch/powerpc/boot/dts/p3041si.dtsi | 71 -
arch/powerpc/boot/dts/p3060qds.dts |4 +
arch/powerpc/boot/dts/p3060si.dtsi | 81 -
arch/powerpc/boot/dts/p4080ds.dts |4 +
arch/powerpc/boot/dts/p4080si.dtsi | 98 +-
arch/powerpc/boot/dts/p5020ds.dts |4 +
arch/powerpc/boot/dts/p5020si.dtsi | 68 -
11 files changed, 797 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
new file mode 100644
index 000..5dc567c
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
@@ -0,0 +1,395 @@
+===
+Debug Control and Status Register (DCSR) Binding
+Copyright 2011 Freescale Semiconductor Inc.
+
+NOTE: The bindings described in this document are preliminary and subject
+to change. Some of the compatible strings that contain only generic names
+may turn out to be inappropriate, or need additional properties to describe
+the integration of the block with the rest of the chip.
+
+=
+Debug Control and Status Register Memory Map
+
+Description
+
+This node defines the base address and range for the
+defined DCSR Memory Map. Child nodes will describe the individual
+debug blocks defined within this memory space.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: Must include "fsl,dcsr" and "simple-bus".
+ The DCSR space exists in the memory-mapped bus.
+
+ - #address-cells
+ Usage: required
+ Value type:
+ Definition: A standard property. Defines the number of cells
+ or representing physical addresses in child nodes.
+
+ - #size-cells
+ Usage: required
+ Value type:
+ Definition: A standard property. Defines the number of cells
+ or representing the size of physical addresses in
+ child nodes.
+
+ - ranges
+ Usage: required
+ Value type:
+ Definition: A standard property. Specifies the physical address
+ range of the DCSR space.
+
+EXAMPLE
+ dcsr: dcsr@f {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,dcsr", "simple-bus";
+ ranges = <0x 0xf 0x 0x01008000>;
+ };
+
+=
+Event Processing Unit
+
+This node represents the region of DCSR space allocated to the EPU
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: Must include "fsl,dcsr-epu"
+
+ - interrupts
+ Usage: required
+ Value type:
+ Definition: Specifies the interrupts generated by the EPU.
+ The value of the interrupts property consists of three
+ interrupt specifiers. The format of the specifier is defined
+ by the binding document describing the node's interrupt parent.
+
+ The EPU counters can be configured to assert the performance
+ monitor interrupt signal based on either counter overflow or value
+ match. Which counter asserted the interrupt is captured in an EPU
+ Counter Interrupt Status Register (EPCPUISR).
+
+ The EPU unit can also be configured to assert either or both of
+ two interrupt signals based on debug event sources within the SoC.
+ The interrupt signals are epu_xt_int0 and epu_xt_int1.
+ Which event source asserted the interrupt is captured in an EPU
+ Interrupt Status Register (EPISR0,EPISR1).
+
+ Interrupt numbers are lised in order (perfmon, event0, event1).
+
+ - interrupt-parent
+ Usage: required
+ Value type:
+ Definition: A single value that points
+ to the interrupt parent to which the child domain
+ is being mapped. Value must be "&mpic"
+
+ - reg
+ Usage: required
+ Value type:
+ Definition: A standard property. Specifies the physical address
+ offset and length of the DCSR space registers of the device
+ configuration block.
+
+E
[PATCH] ahci: add DT binding for Calxeda AHCI controller
From: Rob Herring
Add devicetree match table to ahci platform driver for Calxeda Highbank
AHCI controller.
Signed-off-by: Rob Herring
Cc: Jeff Garzik
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
---
.../devicetree/bindings/ata/calxeda-sata.txt | 17 +
drivers/ata/ahci_platform.c|7 +++
2 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/calxeda-sata.txt
diff --git a/Documentation/devicetree/bindings/ata/calxeda-sata.txt
b/Documentation/devicetree/bindings/ata/calxeda-sata.txt
new file mode 100644
index 000..79caa56
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/calxeda-sata.txt
@@ -0,0 +1,17 @@
+* Calxeda SATA Controller
+
+SATA nodes are defined to describe on-chip Serial ATA controllers.
+Each SATA controller should have its own node.
+
+Required properties:
+- compatible: compatible list, contains "calxeda,hb-ahci"
+- interrupts:
+- reg :
+
+Example:
+sata@ffe08000 {
+ compatible = "calxeda,hb-ahci";
+reg = <0xffe08000 0x1000>;
+interrupts = <115>;
+};
+
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 6fef1fa..9bfc970 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -171,11 +171,18 @@ static int __devexit ahci_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id ahci_of_match[] = {
+ { .compatible = "calxeda,hb-ahci", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ahci_of_match);
+
static struct platform_driver ahci_driver = {
.remove = __devexit_p(ahci_remove),
.driver = {
.name = "ahci",
.owner = THIS_MODULE,
+ .of_match_table = ahci_of_match,
},
};
--
1.7.5.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/9] Add dtget utility to read property values from device tree
Hi David,
On Thu, Jul 28, 2011 at 5:22 AM, Simon Glass wrote:
> Hi David,
>
> On Tue, Jul 19, 2011 at 3:34 PM, David Gibson
> wrote:
>> On Tue, Jul 05, 2011 at 12:02:50PM -0700, Simon Glass wrote:
>>> This simply utility makes it easy for scripts to read values from the device
>>> tree.
[snip]
>>> +static int show_data_for_key(const void *blob, const char *format, int
>>> type,
>>> + char *key)
>>> +{
>>> + char *ptr, *prop;
>>> + int node, guess_node = 0;
>>> + const void *value;
>>> + int len;
>>> +
>>> + /* First extract the property from the end */
>>> + ptr = strrchr(key, '/');
>>> + if (!ptr) {
>>> + fprintf(stderr, "No node found in key '%s'\n", key);
>>> + return 5;
>>> + }
>>
>> This is wrong. properties do not have paths - they exist in a
>> separate namespace to nodes. The node path and property name should
>> be supplied as separate parameters. As well as being actually right,
>> it will greatly simplify this function's convoluted logic.
>
> Well yes, but I feel that it makes it harder to use also. My thinking
> with this was to try to make it easy to extract information. In my
> view:
>
> /lcd/width
>
> is better than
>
> /lcd width
>
> But this is the kind of discussion / feedback I was hoping to get as I
> am new to device trees. My thoughts:
>
> 1. / is not generally used in property names so there is no conflict
> 2. Neither is there any ambiguity
> 3. The 'complex' logic is there to make life easy for the poor
> hard-pressed user.
> 4. Creating the concept of a sort-of unified name space for a device
> tree property is probably not a bad idea.
I didn't hear back on this so I going to assume this is reasonable,
and submit another patch set with your other comments addressed. The
intent of the fdt seems clearly hierarchical to me. Hope this is ok.
Regards,
Simon
>
[more snip]
>> --
>> David Gibson | I'll have my music baroque, and my code
>> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
>> | _way_ _around_!
>> http://www.ozlabs.org/~dgibson
>>
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2] dtc: Add support for named integer constants
Stephen Warren wrote at Tuesday, August 30, 2011 3:30 PM: > You may define constants as follows: > > /define/ TWO 2; > /define/ FOUR 4; > /define/ OTHER FOUR; > > And properties may use these values as follows: > > foo = <1 TWO 3 FOUR 5>; > > Signed-off-by: Stephen Warren David, Jon, Does this seem reasonable? I think the syntax is simple enough it wouldn't interfere with any more advanced expression/function/... support in the future, and it could be easily extended to allow e.g.: /define/ FOO "BAR"; /define/ BAX [0af8dacb0]; ... And even arbitrary expressions on the RHS as/when/if support is added for those more generally: /define/ A (B | (C << 2)); -- nvpublic ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
