Re: [PATCH v5 2/4] TI816X: Update common OMAP machine specific sources

2011-02-10 Thread Tony Lindgren 
* Pedanekar, Hemant hema...@ti.com [110209 20:42]:
 Tony Lindgren wrote on Thursday, February 10, 2011 7:18 AM:
 
  * Tony Lindgren t...@atomide.com [110209 17:45]:
  
  We should just have separate struct map_desc omapti816x_io_desc[] then.
  Maybe have a common struct map_desc omap3_io_desc[] and then separate
  omap3xxx_io_desc and omapti816x_io_desc?
  
  Oh and this will work just fine for map_io without having cpu_is_omap
  macros working yet because we call set_globals from the board
  file with
  the processor class data.
  
  Tony
 
 So probably I need to create another function (ti816x_map_common_io()) to
 map just the L4 slow region and call it from board file (after set globals)
 as distinguishing between OMAP3xxx and TI816X is not possible at that time
 inside omap34xx_map_common_io() as they both have same class.
 
 Does this approach look ok?

Yes that's the way to go if the io regions are different.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/4] TI816X: Update common OMAP machine specific sources

2011-02-09 Thread Tony Lindgren 
* Hemant Pedanekar hema...@ti.com [110209 08:54]:
 --- a/arch/arm/mach-omap2/io.c
 +++ b/arch/arm/mach-omap2/io.c
 @@ -121,6 +121,16 @@ static struct map_desc omap243x_io_desc[] __initdata = {
  #endif
  
  #ifdef   CONFIG_ARCH_OMAP3
 +#ifdef CONFIG_SOC_OMAPTI816X
 +static struct map_desc omap34xx_io_desc[] __initdata = {
 + {
 + .virtual= L4_34XX_VIRT,
 + .pfn= __phys_to_pfn(L4_34XX_PHYS),
 + .length = L4_34XX_SIZE,
 + .type   = MT_DEVICE
 + },
 +};
 +#else

Ah maybe you mean this else here? This would certainly break things for other
omap3 processors..

  static struct map_desc omap34xx_io_desc[] __initdata = {
   {
   .virtual= L3_34XX_VIRT,
 @@ -175,6 +185,7 @@ static struct map_desc omap34xx_io_desc[] __initdata = {
  #endif
  };
  #endif
 +#endif
  #ifdef   CONFIG_ARCH_OMAP4
  static struct map_desc omap44xx_io_desc[] __initdata = {
   {

..because the omap34xx_io_desc[] will be missing all the other entries.

We should just have separate struct map_desc omapti816x_io_desc[] then.
Maybe have a common struct map_desc omap3_io_desc[] and then separate
omap3xxx_io_desc and omapti816x_io_desc?

Let me know if you know of other places where compiling in ti816x
and other omap3 processors would cause issues, sounds like these should
be very easy to sort out considering we already support quite a few
omap variants.

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/4] TI816X: Update common OMAP machine specific sources

2011-02-09 Thread Tony Lindgren 
* Tony Lindgren t...@atomide.com [110209 17:45]:
 
 We should just have separate struct map_desc omapti816x_io_desc[] then.
 Maybe have a common struct map_desc omap3_io_desc[] and then separate
 omap3xxx_io_desc and omapti816x_io_desc?

Oh and this will work just fine for map_io without having cpu_is_omap
macros working yet because we call set_globals from the board file with
the processor class data.

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v5 2/4] TI816X: Update common OMAP machine specific sources

2011-02-09 Thread Pedanekar, Hemant 
Tony Lindgren wrote on Thursday, February 10, 2011 7:18 AM:

 * Tony Lindgren t...@atomide.com [110209 17:45]:
 
 We should just have separate struct map_desc omapti816x_io_desc[] then.
 Maybe have a common struct map_desc omap3_io_desc[] and then separate
 omap3xxx_io_desc and omapti816x_io_desc?
 
 Oh and this will work just fine for map_io without having cpu_is_omap
 macros working yet because we call set_globals from the board
 file with
 the processor class data.
 
 Tony

So probably I need to create another function (ti816x_map_common_io()) to
map just the L4 slow region and call it from board file (after set globals)
as distinguishing between OMAP3xxx and TI816X is not possible at that time
inside omap34xx_map_common_io() as they both have same class.

Does this approach look ok?
Thanks.
   Hemant--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html