Re: [PATCH 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
Salut Paul, On 12/8/2010 7:47 AM, Paul Walmsley wrote: Salut Benoît, On Tue, 7 Dec 2010, Cousson, Benoit wrote: Salut Paul, On 12/7/2010 2:25 AM, Paul Walmsley wrote: Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files so they match their underlying OMAP hardware modules. Add clockdomain offset information. Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the SCRM, scrm44xx.h. SCRM register offsets still need to be added; TI should do this. And we did it :-) Even better :-) I sent it last week along with clock data series: https://patchwork.kernel.org/patch/373751/ OK, I've just realized that it was a little bit hidden in the clock data patch, and maybe we should have been sent two patches. Sorry for that. Do you want to take it in that series, or should I re-sent the clock data one? I guess it's better done in the clock series; that should avoid a branch dependency between the PRCM patchsets and the clock patch sets. One thing that would be nice on the scrm44xx.h file is to keep the _OFFSET macros. It would be nice in the long run to get rid of the absolute addressing macros in case someone decides to shuffle around the IP block addresses again... can you update your clock series with that change? OK, this is done. I've just posted it. Regards, Benoit -- 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 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
Paul Walmsley p...@pwsan.com writes: On Tue, 7 Dec 2010, Cousson, Benoit wrote: On 12/7/2010 2:25 AM, Paul Walmsley wrote: [...] + * + * XXX This file needs to be updated to align on one of OMAP4, OMAP44XX, + * or OMAP4430. Yep, I was thinking to change that as well. My first thought was OMAP4 to get a shorter name, but when we will introduce OMAP4440, we might have some new entries, that will looks ugly close to OMAP4. So at the end I will prefer OMAP44XX for the moment and we might renamed to OMAP4430 or OMAP4440 for the entries that will diverge. Do you want to change that for 2.6.38? It will require some sync with the various users of these defines, but that should be doable. I don't mind waiting until after 2.6.38, I think we'll have a pretty huge pile of patches on our hands to merge already for .38... maybe Tony or Kevin have some opinions though. I think this should wait 'til after 2.6.38, but be early in the next cycle so all dependencies can be handled early. Kevin -- 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 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
On 12/7/2010 2:25 AM, Paul Walmsley wrote: [...] + * + * XXX This file needs to be updated to align on one of OMAP4, OMAP44XX, + * or OMAP4430. Yep, I was thinking to change that as well. My first thought was OMAP4 to get a shorter name, but when we will introduce OMAP4440, we might have some new entries, that will looks ugly close to OMAP4. So at the end I will prefer OMAP44XX for the moment and we might renamed to OMAP4430 or OMAP4440 for the entries that will diverge. Do you want to change that for 2.6.38? It will require some sync with the various users of these defines, but that should be doable. Regards, Benoit -- 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 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
On Tue, 7 Dec 2010, Cousson, Benoit wrote: On 12/7/2010 2:25 AM, Paul Walmsley wrote: [...] + * + * XXX This file needs to be updated to align on one of OMAP4, OMAP44XX, + * or OMAP4430. Yep, I was thinking to change that as well. My first thought was OMAP4 to get a shorter name, but when we will introduce OMAP4440, we might have some new entries, that will looks ugly close to OMAP4. So at the end I will prefer OMAP44XX for the moment and we might renamed to OMAP4430 or OMAP4440 for the entries that will diverge. Do you want to change that for 2.6.38? It will require some sync with the various users of these defines, but that should be doable. I don't mind waiting until after 2.6.38, I think we'll have a pretty huge pile of patches on our hands to merge already for .38... maybe Tony or Kevin have some opinions though. - 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 11/14] OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
Salut Benoît, On Tue, 7 Dec 2010, Cousson, Benoit wrote: Salut Paul, On 12/7/2010 2:25 AM, Paul Walmsley wrote: Split the existing cm44xx.h file into cm1_44xx.h and cm2_44xx.h files so they match their underlying OMAP hardware modules. Add clockdomain offset information. Add header files for the MPU local PRCM, prcm_mpu44xx.h, and for the SCRM, scrm44xx.h. SCRM register offsets still need to be added; TI should do this. And we did it :-) Even better :-) I sent it last week along with clock data series: https://patchwork.kernel.org/patch/373751/ OK, I've just realized that it was a little bit hidden in the clock data patch, and maybe we should have been sent two patches. Sorry for that. Do you want to take it in that series, or should I re-sent the clock data one? I guess it's better done in the clock series; that should avoid a branch dependency between the PRCM patchsets and the clock patch sets. One thing that would be nice on the scrm44xx.h file is to keep the _OFFSET macros. It would be nice in the long run to get rid of the absolute addressing macros in case someone decides to shuffle around the IP block addresses again... can you update your clock series with that change? Getting the clock patchsets put together for 2.6.38 is one of the next big projects here. - Paul
