RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure
Hello Paul, > -Original Message- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Thursday, January 21, 2010 8:50 AM > To: Pagare, Abhijit > Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > Subject: RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure > > Hello Abhijit, > > On Wed, 20 Jan 2010, Pagare, Abhijit wrote: > > > I think the latest patch-set that I had posted has this change in it. > > You can refer to the patch in the link below > > > > http://marc.info/?l=linux-omap&m=126088474831309&w=2 > > Looks like this patch had somehow not made it into the for_2.6.34 branch; > this has now been fixed, which resolves the problem. But this part we > should discuss further: > > > I had used this flag earlier as there was nothing fixed as to name it as > > ES1 that time. > > Yep, I understand. > > > So now it can be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. > > I think CHIP_IS_OMAP4430 would be redundant in that case and should be > > removed. A patch would be essential to take care of that in the places > > where it is used. If you feel the same I can send a patch for fixing > > this. > > In the past, there have been some clock, clockdomain, powerdomain, IP > block, etc. changes going from ES1 to ES2 revisions. But most clocks, > etc. stay the same. So it seems best to keep the actual CHIP_IS_* bits > ES-level sensitive, then define a rollup macro like CHIP_IS_OMAP4430 for > what stays the same. Until ES2 details are available, this shouldn't > require any further changes to the codebase aside from id.c. Sounds okay. > > We don't currently define a rollup macro for CHIP_IS_OMAP3430, but it's > planned for 2.6.34 to include all of the individual CHIP_IS_OMAP* bits. > We'd do the same thing for OMAP2xxx but most of the 2xxx data in the > kernel tree has no ES-level information, so we'll probably leave those > as-is. We'll probably add in a Sitara CHIP_IS_* bit in there also. > > Anyway, there's no need for you to change your patch, now that it's > included in the for_2.6.34 branch. But keep in mind that we'll probably > post another id.c cleanup patch to change things around as described > above, unless you or others have some strong reason not to... Yes a patch will be essential for cleaning the id.c as we would have to also match up to the changes made by Tony for OMAP3 in his recently posted "OMAP3: Fix cpu detection" patch. I can send the patch when we need to push that change in for OMAP4. Thanks & Regards, Abhijit > > > - Paul -- 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] OMAP CPU ID: fix OMAP4 build failure
On Thu, 21 Jan 2010, Shilimkar, Santosh wrote: > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org > > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul > > Walmsley > > > > I guess the rollup should probably be CHIP_IS_OMAP44XX. Do you happen to > > know whether software will be able to discriminate between 4430 and 4440 > > chips at run-time, and if so, what mechanism to use? > ID_CODE would be different which can be used for this. Okay, great. - Paul -- 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] OMAP CPU ID: fix OMAP4 build failure
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Paul > Walmsley > Sent: Thursday, January 21, 2010 8:57 AM > To: Pagare, Abhijit > Cc: t...@atomide.com; linux-omap@vger.kernel.org; > linux-arm-ker...@lists.infradead.org > Subject: RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure > > Hello Abhijit, > > On Wed, 20 Jan 2010, Paul Walmsley wrote: > > > > So now it can be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. > > > I think CHIP_IS_OMAP4430 would be redundant in that case and should be > > > removed. A patch would be essential to take care of that in the places > > > where it is used. If you feel the same I can send a patch for fixing > > > this. > > > > In the past, there have been some clock, clockdomain, powerdomain, IP > > block, etc. changes going from ES1 to ES2 revisions. But most clocks, > > etc. stay the same. So it seems best to keep the actual CHIP_IS_* bits > > ES-level sensitive, then define a rollup macro like CHIP_IS_OMAP4430 for > > what stays the same. Until ES2 details are available, this shouldn't > > require any further changes to the codebase aside from id.c. > > I guess the rollup should probably be CHIP_IS_OMAP44XX. Do you happen to > know whether software will be able to discriminate between 4430 and 4440 > chips at run-time, and if so, what mechanism to use? ID_CODE would be different which can be used for this. -- 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] OMAP CPU ID: fix OMAP4 build failure
Hello Abhijit, On Wed, 20 Jan 2010, Paul Walmsley wrote: > > So now it can be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. > > I think CHIP_IS_OMAP4430 would be redundant in that case and should be > > removed. A patch would be essential to take care of that in the places > > where it is used. If you feel the same I can send a patch for fixing > > this. > > In the past, there have been some clock, clockdomain, powerdomain, IP > block, etc. changes going from ES1 to ES2 revisions. But most clocks, > etc. stay the same. So it seems best to keep the actual CHIP_IS_* bits > ES-level sensitive, then define a rollup macro like CHIP_IS_OMAP4430 for > what stays the same. Until ES2 details are available, this shouldn't > require any further changes to the codebase aside from id.c. I guess the rollup should probably be CHIP_IS_OMAP44XX. Do you happen to know whether software will be able to discriminate between 4430 and 4440 chips at run-time, and if so, what mechanism to use? - Paul -- 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] OMAP CPU ID: fix OMAP4 build failure
Hello Abhijit, On Wed, 20 Jan 2010, Pagare, Abhijit wrote: > I think the latest patch-set that I had posted has this change in it. > You can refer to the patch in the link below > > http://marc.info/?l=linux-omap&m=126088474831309&w=2 Looks like this patch had somehow not made it into the for_2.6.34 branch; this has now been fixed, which resolves the problem. But this part we should discuss further: > I had used this flag earlier as there was nothing fixed as to name it as > ES1 that time. Yep, I understand. > So now it can be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. > I think CHIP_IS_OMAP4430 would be redundant in that case and should be > removed. A patch would be essential to take care of that in the places > where it is used. If you feel the same I can send a patch for fixing > this. In the past, there have been some clock, clockdomain, powerdomain, IP block, etc. changes going from ES1 to ES2 revisions. But most clocks, etc. stay the same. So it seems best to keep the actual CHIP_IS_* bits ES-level sensitive, then define a rollup macro like CHIP_IS_OMAP4430 for what stays the same. Until ES2 details are available, this shouldn't require any further changes to the codebase aside from id.c. We don't currently define a rollup macro for CHIP_IS_OMAP3430, but it's planned for 2.6.34 to include all of the individual CHIP_IS_OMAP* bits. We'd do the same thing for OMAP2xxx but most of the 2xxx data in the kernel tree has no ES-level information, so we'll probably leave those as-is. We'll probably add in a Sitara CHIP_IS_* bit in there also. Anyway, there's no need for you to change your patch, now that it's included in the for_2.6.34 branch. But keep in mind that we'll probably post another id.c cleanup patch to change things around as described above, unless you or others have some strong reason not to... - Paul -- 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] OMAP CPU ID: fix OMAP4 build failure
> > -Original Message- > > From: Shilimkar, Santosh > > Sent: Wednesday, January 20, 2010 12:52 PM > > To: Pagare, Abhijit; Paul Walmsley; Pagare, Abhijit > > Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm- > > ker...@lists.infradead.org > > Subject: RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure > > > > Abhijit, > > > > > > > > > I had used this flag earlier as there was nothing fixed as to name it as > > ES1 that time. So now it can > > > be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. I think > > CHIP_IS_OMAP4430 would be redundant > > > in that case and should be removed. A patch would be essential to take > > care of that in the places > > > where it is used. If you feel the same I can send a patch for fixing > > this. > > > > > > > Tony has already created the patch. Please use that and test it on OMAP4. > > I will test it on OMAP4 but my point was as follows, > > The patch that is sent has both the definitions of CHIP_IS_OMAP4430 and > CHIP_IS_OMAP4430ES1 where the > later is initialized with the former's value. I was actually wondering why > the former is required > anyways. It is a redundant thing and can be replaced totally. I just rescanned the patch and now understand what you are saying. Tony's patch is fixing OMAP3 versions and Paul's patch for OMAP4. Just do the correction you mentioned for OMAP4 in Paul's patch and after testing post it. If you can test both these patches, that would be even better. Regards, Santosh -- 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] OMAP CPU ID: fix OMAP4 build failure
Santosh, > -Original Message- > From: Shilimkar, Santosh > Sent: Wednesday, January 20, 2010 12:52 PM > To: Pagare, Abhijit; Paul Walmsley; Pagare, Abhijit > Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > Subject: RE: [PATCH] OMAP CPU ID: fix OMAP4 build failure > > Abhijit, > > > > > I had used this flag earlier as there was nothing fixed as to name it as > ES1 that time. So now it can > > be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. I think > CHIP_IS_OMAP4430 would be redundant > > in that case and should be removed. A patch would be essential to take > care of that in the places > > where it is used. If you feel the same I can send a patch for fixing > this. > > > > Tony has already created the patch. Please use that and test it on OMAP4. I will test it on OMAP4 but my point was as follows, The patch that is sent has both the definitions of CHIP_IS_OMAP4430 and CHIP_IS_OMAP4430ES1 where the later is initialized with the former's value. I was actually wondering why the former is required anyways. It is a redundant thing and can be replaced totally. > > Regards, > Santosh -- 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] OMAP CPU ID: fix OMAP4 build failure
Abhijit, > I had used this flag earlier as there was nothing fixed as to name it as ES1 > that time. So now it can > be migrated from CHIP_IS_OMAP4430 to CHIP_IS_OMAP4430ES1. I think > CHIP_IS_OMAP4430 would be redundant > in that case and should be removed. A patch would be essential to take care > of that in the places > where it is used. If you feel the same I can send a patch for fixing this. > Tony has already created the patch. Please use that and test it on OMAP4. Regards, Santosh -- 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] OMAP CPU ID: fix OMAP4 build failure
Hello Paul,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Paul Walmsley
> Sent: Wednesday, January 20, 2010 2:44 AM
> To: abhijit.pag...@ti.com
> Cc: t...@atomide.com; linux-omap@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: [PATCH] OMAP CPU ID: fix OMAP4 build failure
>
>
> Hello Abhijit,
>
> it seems that my for_2.6.34 branch does not build unless the following
> patch, or one like it, is included. Any comments?
>
>
> - Paul
>
>
> From: Paul Walmsley
>
>
> omap_4430sdp_defconfig currently does not build due to some missing CPU
> IDs:
>
> In file included from arch/arm/mach-omap2/powerdomains.h:59,
> from arch/arm/mach-omap2/io.c:42:
> arch/arm/mach-omap2/powerdomains44xx.h:39: error: 'CHIP_IS_OMAP4430'
> undeclared here (not in a function)
>
> ... so add CHIP_IS_OMAP4430ES1. Note that this is not yet set by
> mach-omap2/id.c; this is for TI to fix.
>
> Signed-off-by: Paul Walmsley
> Cc: Tony Lindgren
> Cc: Abhijit Pagare
> ---
> arch/arm/plat-omap/include/plat/cpu.h |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-
> omap/include/plat/cpu.h
> index 9a028bd..8ada0ef 100644
> --- a/arch/arm/plat-omap/include/plat/cpu.h
> +++ b/arch/arm/plat-omap/include/plat/cpu.h
> @@ -44,7 +44,7 @@
> int omap_type(void);
>
> struct omap_chip_id {
> - u8 oc;
> + u16 oc;
I think the latest patch-set that I had posted has this change in it. You can
refer to the patch in the link below
http://marc.info/?l=linux-omap&m=126088474831309&w=2
> u8 type;
> };
>
> @@ -470,8 +470,10 @@ IS_OMAP_TYPE(3517, 0x3517)
> #define CHIP_IS_OMAP3430ES3_0(1 << 5)
> #define CHIP_IS_OMAP3430ES3_1(1 << 6)
> #define CHIP_IS_OMAP3630ES1 (1 << 7)
> +#define CHIP_IS_OMAP4430ES1 (1 << 8)
>
> #define CHIP_IS_OMAP24XX (CHIP_IS_OMAP2420 | CHIP_IS_OMAP2430)
> +#define CHIP_IS_OMAP4430 CHIP_IS_OMAP4430ES1
I had used this flag earlier as there was nothing fixed as to name it as ES1
that time. So now it can be migrated from CHIP_IS_OMAP4430 to
CHIP_IS_OMAP4430ES1. I think CHIP_IS_OMAP4430 would be redundant in that case
and should be removed. A patch would be essential to take care of that in the
places where it is used. If you feel the same I can send a patch for fixing
this.
Regards,
Abhijit
>
> /*
> * "GE" here represents "greater than or equal to" in terms of ES
> --
> 1.6.6.rc2.5.g49666
>
> --
> 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
--
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
