Re: [PATCH v2 00/13] ARM: OMAP2+: AM43x PRCM support
Hi Paul, Benoit, On Wednesday 21 August 2013 05:14 PM, Rajendra Nayak wrote: On Friday 02 August 2013 07:05 PM, Afzal Mohammed wrote: Hwmod database of AM335x is reused by moving common elements to a new array (most of AM335x IP's are present in AM43x) and keeping separate arrays for elements that are specific only to either one of AM335x or AM43x. And in the cases where relevant IP is present in both that has difference in details like CLKCTRL register offsets, it is being updated at runtime based on the SoC detected. I feel the reuse part is good but we need to structure them such that we don't compromise too much on readability of the data. So what I suggest is 1. Create something like omap_hwmod_am43_am33_interconnect_data.c and have all common interconnect ocp_if structs 2. Create something like omap_hwmod_am43_am33_ipblock_data.c and have all common hwmod structs. 3. Since most PRCM register offsets are different, have them all inited in *one* place (even for the ones which are common), instead of common ones being statically defined and others dynamically inited. 4. For instances like clkdm being different or clock topology has changed (which is in rare cases) have seperate structures for am33xx and am43xx. Once we move some of the clocks etc to DT we can then move them into common files if needed. Paul/Benoit, does the above make sense? I plan to proceed as per the above 4 points mentioned by Rajendra (that includes his comments on patches 2,3 13), is that okay ? Regards Afzal -- 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 v2 00/13] ARM: OMAP2+: AM43x PRCM support
Hi Paul, On Wednesday 21 August 2013 08:23 AM, Paul Walmsley wrote: Currently there is no public TRM available for AM43x. Can you think of any way that the data can be doublechecked against some reference or against the reality of the chip? This series has been tested on a pre-silicon platform, and boots to prompt (along with DT clocks from Tero). Can development boards be made available to the OMAP maintainers so we can ensure that the code, once merged, continues to work? Silicon boards are not yet ready. I checked internally about your request, I had been told that once boards are ready, it can be made available to the maintainers. Powerdomain Clockdomain data has been added separately as it was not giving much advantage reusing AM335x ones (runtime updates required was getting too ugly). But as AM43x PRCM functionality is similar to OMAP4, power domain, clock domain hwmod operations are reused from OMAP4. Is the AM43xx PRCM design and IP derived from AM33xx, or from OMAP4, or from something else? PRCM is derived from AM335x, but modified such that it is more aligned with OMAP4 (especially w.r.t register offsets) Regards Afzal -- 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 v2 00/13] ARM: OMAP2+: AM43x PRCM support
Hi Benoit, On Tuesday 20 August 2013 02:48 PM, Benoit Cousson wrote: Otherwise, I guess that most of these patches should be non-intrusive for other OMAPs beside that one (ARM: OMAP2+: CM: reintroduce SW_SLEEP for OMAP4). And for the moment, that's maybe the most important point. Have you checked that it will not generate any regression for OMAP4 in term of PM features: suspend, cpuidle at least? As noted by Rajendra, there could problem where clockdomain doesn't have SW_SLEEP and only have HW_AUTO. I have to rework the relevant patch to handle it properly. Regards Afzal -- 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 v2 00/13] ARM: OMAP2+: AM43x PRCM support
On Friday 02 August 2013 07:05 PM, Afzal Mohammed wrote: Hwmod database of AM335x is reused by moving common elements to a new array (most of AM335x IP's are present in AM43x) and keeping separate arrays for elements that are specific only to either one of AM335x or AM43x. And in the cases where relevant IP is present in both that has difference in details like CLKCTRL register offsets, it is being updated at runtime based on the SoC detected. I feel the reuse part is good but we need to structure them such that we don't compromise too much on readability of the data. So what I suggest is 1. Create something like omap_hwmod_am43_am33_interconnect_data.c and have all common interconnect ocp_if structs 2. Create something like omap_hwmod_am43_am33_ipblock_data.c and have all common hwmod structs. 3. Since most PRCM register offsets are different, have them all inited in *one* place (even for the ones which are common), instead of common ones being statically defined and others dynamically inited. 4. For instances like clkdm being different or clock topology has changed (which is in rare cases) have seperate structures for am33xx and am43xx. Once we move some of the clocks etc to DT we can then move them into common files if needed. Paul/Benoit, does the above make sense? -- 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 v2 00/13] ARM: OMAP2+: AM43x PRCM support
+ Rajendra and Tero, Hi Afzal, On 19/08/2013 08:36, Afzal Mohammed wrote: Hi Tony, On Tuesday 13 August 2013 01:31 PM, Tony Lindgren wrote: Hi Paul Benoit, Does this series look OK to you guys to queue or ack? Can you please consider queuing this series for the coming merge window as we are getting closer to the merge window. If Paul or Benoit has any comments on this, we can have patches to fix it up on top of this as required or these patches be reverted in the worst case. That series is pretty big and I will not have the time to review it properly. Moreover, without any public documentation, it will be really hard to do a correct review anyway. That series must be reviewed and acked by people inside TI who does have the knowledge and the skill to do that. I strongly recommend you to ask Rajendra and Tero to review it and ack it ASAP. Otherwise, I guess that most of these patches should be non-intrusive for other OMAPs beside that one (ARM: OMAP2+: CM: reintroduce SW_SLEEP for OMAP4). And for the moment, that's maybe the most important point. Have you checked that it will not generate any regression for OMAP4 in term of PM features: suspend, cpuidle at least? Regards, Benoit Regards Afzal * Afzal Mohammed af...@ti.com [130802 06:42]: Hi, AM43x PRCM support (excluding clock tree) is being added with this series. AM43x reuses most of the IP's from AM335x, as that is the case, much of the AM335x hwmod data is reused. I am aware that this series adds around +1K lines to platform. We in TI, here are making efforts to clean platform code gradually and keep to minumum the code being added to support new SoC's. Please note that this SoC support series has positive diffstat of just above 1K only. This compared to last SoC that was supported in OMAP family during last merge window is way less (this is only around 1/8th postive diffstat of it). Clock data is not added in this series, instead directly clock tree in DT with driver would be used, this is a work in progress. And as seen from recent OMAP clock tree DT conversion series, there are serious efforts ongoing to that end. Also we will start working on moving hwmod away from platform folders. In addition, recently there was a PRCM cleanup by Rajendra Nayak that removed near to 11K lines. Considering the above facts, I request the maintainers to consider this series for the next merge window. Currently there is no public TRM available for AM43x. Hwmod database of AM335x is reused by moving common elements to a new array (most of AM335x IP's are present in AM43x) and keeping separate arrays for elements that are specific only to either one of AM335x or AM43x. And in the cases where relevant IP is present in both that has difference in details like CLKCTRL register offsets, it is being updated at runtime based on the SoC detected. Powerdomain Clockdomain data has been added separately as it was not giving much advantage reusing AM335x ones (runtime updates required was getting too ugly). But as AM43x PRCM functionality is similar to OMAP4, power domain, clock domain hwmod operations are reused from OMAP4. A single header file has been added to provide all AM43x PRCM defines. Here sequencewise, initially AM335x hwmod is modified to have it's fields get updated at runtime (wherever element is shared and has some difference with AM43x). Then power domain, clock domain for AM43x is added and finally AM335x hwmod database is updated with AM43x specifics. This series is being developed with additional clock tree changes that are being DT'fied. Additional DTS changes (posted separate from this series) are also required for hwmod to get register target address space as most of AM335x hwmod address space details has been recently cleaned up and moved to DTS. Regards Afzal Afzal Mohammed (8): ARM: OMAP2+: hwmod: AM335x: prepare for AM43x reuse ARM: OMAP2+: hwmod: AMx3: runtime AM335x handling ARM: OMAP2+: hwmod: AMx3: remove common static fields ARM: OMAP2+: PRCM: AM43x definitions ARM: OMAP2+: hwmod: AMx3: runtime AM43x handling ARM: OMAP2+: hwmod: AM43x operations ARM: OMAP2+: AM43x: PRCM kbuild ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x Ambresh K (3): ARM: OMAP2+: PM: AM43x powerdomain data ARM: OMAP2+: CM: AM43x clockdomain data ARM: OMAP2+: AM43x PRCM init Ankur Kishore (1): ARM: OMAP2+: CM: cm_inst offset s16-u16 Vaibhav Bedia (1): ARM: OMAP2+: CM: reintroduce SW_SLEEP for OMAP4 arch/arm/mach-omap2/Makefile|5 +- arch/arm/mach-omap2/clockdomain.h |4 +- arch/arm/mach-omap2/clockdomains43xx_data.c | 199 arch/arm/mach-omap2/cm33xx.c| 30 +- arch/arm/mach-omap2/cm33xx.h| 28 +- arch/arm/mach-omap2/cminst44xx.c| 58 ++- arch/arm/mach-omap2/cminst44xx.h| 25 +- arch/arm/mach-omap2/io.c|6 + arch/arm/mach-omap2/omap_hwmod.c|
Re: [PATCH v2 00/13] ARM: OMAP2+: AM43x PRCM support
Hi On Fri, 2 Aug 2013, Afzal Mohammed wrote: AM43x PRCM support (excluding clock tree) is being added with this series. AM43x reuses most of the IP's from AM335x, as that is the case, much of the AM335x hwmod data is reused. ... Currently there is no public TRM available for AM43x. Can you think of any way that the data can be doublechecked against some reference or against the reality of the chip? Can development boards be made available to the OMAP maintainers so we can ensure that the code, once merged, continues to work? Powerdomain Clockdomain data has been added separately as it was not giving much advantage reusing AM335x ones (runtime updates required was getting too ugly). But as AM43x PRCM functionality is similar to OMAP4, power domain, clock domain hwmod operations are reused from OMAP4. Is the AM43xx PRCM design and IP derived from AM33xx, or from OMAP4, or from something else? - 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 v2 00/13] ARM: OMAP2+: AM43x PRCM support
Hi Tony, On Tuesday 13 August 2013 01:31 PM, Tony Lindgren wrote: Hi Paul Benoit, Does this series look OK to you guys to queue or ack? Can you please consider queuing this series for the coming merge window as we are getting closer to the merge window. If Paul or Benoit has any comments on this, we can have patches to fix it up on top of this as required or these patches be reverted in the worst case. Regards Afzal * Afzal Mohammed af...@ti.com [130802 06:42]: Hi, AM43x PRCM support (excluding clock tree) is being added with this series. AM43x reuses most of the IP's from AM335x, as that is the case, much of the AM335x hwmod data is reused. I am aware that this series adds around +1K lines to platform. We in TI, here are making efforts to clean platform code gradually and keep to minumum the code being added to support new SoC's. Please note that this SoC support series has positive diffstat of just above 1K only. This compared to last SoC that was supported in OMAP family during last merge window is way less (this is only around 1/8th postive diffstat of it). Clock data is not added in this series, instead directly clock tree in DT with driver would be used, this is a work in progress. And as seen from recent OMAP clock tree DT conversion series, there are serious efforts ongoing to that end. Also we will start working on moving hwmod away from platform folders. In addition, recently there was a PRCM cleanup by Rajendra Nayak that removed near to 11K lines. Considering the above facts, I request the maintainers to consider this series for the next merge window. Currently there is no public TRM available for AM43x. Hwmod database of AM335x is reused by moving common elements to a new array (most of AM335x IP's are present in AM43x) and keeping separate arrays for elements that are specific only to either one of AM335x or AM43x. And in the cases where relevant IP is present in both that has difference in details like CLKCTRL register offsets, it is being updated at runtime based on the SoC detected. Powerdomain Clockdomain data has been added separately as it was not giving much advantage reusing AM335x ones (runtime updates required was getting too ugly). But as AM43x PRCM functionality is similar to OMAP4, power domain, clock domain hwmod operations are reused from OMAP4. A single header file has been added to provide all AM43x PRCM defines. Here sequencewise, initially AM335x hwmod is modified to have it's fields get updated at runtime (wherever element is shared and has some difference with AM43x). Then power domain, clock domain for AM43x is added and finally AM335x hwmod database is updated with AM43x specifics. This series is being developed with additional clock tree changes that are being DT'fied. Additional DTS changes (posted separate from this series) are also required for hwmod to get register target address space as most of AM335x hwmod address space details has been recently cleaned up and moved to DTS. Regards Afzal Afzal Mohammed (8): ARM: OMAP2+: hwmod: AM335x: prepare for AM43x reuse ARM: OMAP2+: hwmod: AMx3: runtime AM335x handling ARM: OMAP2+: hwmod: AMx3: remove common static fields ARM: OMAP2+: PRCM: AM43x definitions ARM: OMAP2+: hwmod: AMx3: runtime AM43x handling ARM: OMAP2+: hwmod: AM43x operations ARM: OMAP2+: AM43x: PRCM kbuild ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x Ambresh K (3): ARM: OMAP2+: PM: AM43x powerdomain data ARM: OMAP2+: CM: AM43x clockdomain data ARM: OMAP2+: AM43x PRCM init Ankur Kishore (1): ARM: OMAP2+: CM: cm_inst offset s16-u16 Vaibhav Bedia (1): ARM: OMAP2+: CM: reintroduce SW_SLEEP for OMAP4 arch/arm/mach-omap2/Makefile|5 +- arch/arm/mach-omap2/clockdomain.h |4 +- arch/arm/mach-omap2/clockdomains43xx_data.c | 199 arch/arm/mach-omap2/cm33xx.c| 30 +- arch/arm/mach-omap2/cm33xx.h| 28 +- arch/arm/mach-omap2/cminst44xx.c| 58 ++- arch/arm/mach-omap2/cminst44xx.h| 25 +- arch/arm/mach-omap2/io.c|6 + arch/arm/mach-omap2/omap_hwmod.c|8 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 691 +++ arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains43xx_data.c | 145 ++ arch/arm/mach-omap2/prcm43xx.h | 141 ++ 13 files changed, 1198 insertions(+), 143 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/prcm43xx.h -- 1.7.9.5 -- 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 v2 00/13] ARM: OMAP2+: AM43x PRCM support
Hi Paul Benoit, Does this series look OK to you guys to queue or ack? * Afzal Mohammed af...@ti.com [130802 06:42]: Hi, AM43x PRCM support (excluding clock tree) is being added with this series. AM43x reuses most of the IP's from AM335x, as that is the case, much of the AM335x hwmod data is reused. I am aware that this series adds around +1K lines to platform. We in TI, here are making efforts to clean platform code gradually and keep to minumum the code being added to support new SoC's. Please note that this SoC support series has positive diffstat of just above 1K only. This compared to last SoC that was supported in OMAP family during last merge window is way less (this is only around 1/8th postive diffstat of it). Clock data is not added in this series, instead directly clock tree in DT with driver would be used, this is a work in progress. And as seen from recent OMAP clock tree DT conversion series, there are serious efforts ongoing to that end. Also we will start working on moving hwmod away from platform folders. In addition, recently there was a PRCM cleanup by Rajendra Nayak that removed near to 11K lines. Considering the above facts, I request the maintainers to consider this series for the next merge window. Currently there is no public TRM available for AM43x. Hwmod database of AM335x is reused by moving common elements to a new array (most of AM335x IP's are present in AM43x) and keeping separate arrays for elements that are specific only to either one of AM335x or AM43x. And in the cases where relevant IP is present in both that has difference in details like CLKCTRL register offsets, it is being updated at runtime based on the SoC detected. Powerdomain Clockdomain data has been added separately as it was not giving much advantage reusing AM335x ones (runtime updates required was getting too ugly). But as AM43x PRCM functionality is similar to OMAP4, power domain, clock domain hwmod operations are reused from OMAP4. A single header file has been added to provide all AM43x PRCM defines. Here sequencewise, initially AM335x hwmod is modified to have it's fields get updated at runtime (wherever element is shared and has some difference with AM43x). Then power domain, clock domain for AM43x is added and finally AM335x hwmod database is updated with AM43x specifics. This series is being developed with additional clock tree changes that are being DT'fied. Additional DTS changes (posted separate from this series) are also required for hwmod to get register target address space as most of AM335x hwmod address space details has been recently cleaned up and moved to DTS. Regards Afzal Afzal Mohammed (8): ARM: OMAP2+: hwmod: AM335x: prepare for AM43x reuse ARM: OMAP2+: hwmod: AMx3: runtime AM335x handling ARM: OMAP2+: hwmod: AMx3: remove common static fields ARM: OMAP2+: PRCM: AM43x definitions ARM: OMAP2+: hwmod: AMx3: runtime AM43x handling ARM: OMAP2+: hwmod: AM43x operations ARM: OMAP2+: AM43x: PRCM kbuild ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x Ambresh K (3): ARM: OMAP2+: PM: AM43x powerdomain data ARM: OMAP2+: CM: AM43x clockdomain data ARM: OMAP2+: AM43x PRCM init Ankur Kishore (1): ARM: OMAP2+: CM: cm_inst offset s16-u16 Vaibhav Bedia (1): ARM: OMAP2+: CM: reintroduce SW_SLEEP for OMAP4 arch/arm/mach-omap2/Makefile|5 +- arch/arm/mach-omap2/clockdomain.h |4 +- arch/arm/mach-omap2/clockdomains43xx_data.c | 199 arch/arm/mach-omap2/cm33xx.c| 30 +- arch/arm/mach-omap2/cm33xx.h| 28 +- arch/arm/mach-omap2/cminst44xx.c| 58 ++- arch/arm/mach-omap2/cminst44xx.h| 25 +- arch/arm/mach-omap2/io.c|6 + arch/arm/mach-omap2/omap_hwmod.c|8 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 691 +++ arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains43xx_data.c | 145 ++ arch/arm/mach-omap2/prcm43xx.h | 141 ++ 13 files changed, 1198 insertions(+), 143 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/prcm43xx.h -- 1.7.9.5 -- 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
[PATCH v2 00/13] ARM: OMAP2+: AM43x PRCM support
Hi, AM43x PRCM support (excluding clock tree) is being added with this series. AM43x reuses most of the IP's from AM335x, as that is the case, much of the AM335x hwmod data is reused. I am aware that this series adds around +1K lines to platform. We in TI, here are making efforts to clean platform code gradually and keep to minumum the code being added to support new SoC's. Please note that this SoC support series has positive diffstat of just above 1K only. This compared to last SoC that was supported in OMAP family during last merge window is way less (this is only around 1/8th postive diffstat of it). Clock data is not added in this series, instead directly clock tree in DT with driver would be used, this is a work in progress. And as seen from recent OMAP clock tree DT conversion series, there are serious efforts ongoing to that end. Also we will start working on moving hwmod away from platform folders. In addition, recently there was a PRCM cleanup by Rajendra Nayak that removed near to 11K lines. Considering the above facts, I request the maintainers to consider this series for the next merge window. Currently there is no public TRM available for AM43x. Hwmod database of AM335x is reused by moving common elements to a new array (most of AM335x IP's are present in AM43x) and keeping separate arrays for elements that are specific only to either one of AM335x or AM43x. And in the cases where relevant IP is present in both that has difference in details like CLKCTRL register offsets, it is being updated at runtime based on the SoC detected. Powerdomain Clockdomain data has been added separately as it was not giving much advantage reusing AM335x ones (runtime updates required was getting too ugly). But as AM43x PRCM functionality is similar to OMAP4, power domain, clock domain hwmod operations are reused from OMAP4. A single header file has been added to provide all AM43x PRCM defines. Here sequencewise, initially AM335x hwmod is modified to have it's fields get updated at runtime (wherever element is shared and has some difference with AM43x). Then power domain, clock domain for AM43x is added and finally AM335x hwmod database is updated with AM43x specifics. This series is being developed with additional clock tree changes that are being DT'fied. Additional DTS changes (posted separate from this series) are also required for hwmod to get register target address space as most of AM335x hwmod address space details has been recently cleaned up and moved to DTS. Regards Afzal Afzal Mohammed (8): ARM: OMAP2+: hwmod: AM335x: prepare for AM43x reuse ARM: OMAP2+: hwmod: AMx3: runtime AM335x handling ARM: OMAP2+: hwmod: AMx3: remove common static fields ARM: OMAP2+: PRCM: AM43x definitions ARM: OMAP2+: hwmod: AMx3: runtime AM43x handling ARM: OMAP2+: hwmod: AM43x operations ARM: OMAP2+: AM43x: PRCM kbuild ARM: OMAP2+: hwmod: AM43x: new w.r.t AM335x Ambresh K (3): ARM: OMAP2+: PM: AM43x powerdomain data ARM: OMAP2+: CM: AM43x clockdomain data ARM: OMAP2+: AM43x PRCM init Ankur Kishore (1): ARM: OMAP2+: CM: cm_inst offset s16-u16 Vaibhav Bedia (1): ARM: OMAP2+: CM: reintroduce SW_SLEEP for OMAP4 arch/arm/mach-omap2/Makefile|5 +- arch/arm/mach-omap2/clockdomain.h |4 +- arch/arm/mach-omap2/clockdomains43xx_data.c | 199 arch/arm/mach-omap2/cm33xx.c| 30 +- arch/arm/mach-omap2/cm33xx.h| 28 +- arch/arm/mach-omap2/cminst44xx.c| 58 ++- arch/arm/mach-omap2/cminst44xx.h| 25 +- arch/arm/mach-omap2/io.c|6 + arch/arm/mach-omap2/omap_hwmod.c|8 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 691 +++ arch/arm/mach-omap2/powerdomain.h |1 + arch/arm/mach-omap2/powerdomains43xx_data.c | 145 ++ arch/arm/mach-omap2/prcm43xx.h | 141 ++ 13 files changed, 1198 insertions(+), 143 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c create mode 100644 arch/arm/mach-omap2/prcm43xx.h -- 1.7.9.5 -- 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
