Rajendra Nayak <rnayak@xxxxxx> writes: > [..] >>> First some general comments: >>> >>> At first glance, it seems like there could be much more reuse with OMAP4 >>> code here. From what I see, AM33x has only one partition compared to >>> several on OMAP4, but that doesn't mean you couldn't reuse the OMAP4 >>> functions and just use a single partition. >> Kevin, >> >> Indeed it looks close to OMAP4, but it becomes difficult and ugly once you >> Start getting into implementation details, for example, >> >> - All PRM offsets don't match, you will end up with >> cpu_is_xxx check and handle this. Applicable to all power domains. >> >> OMAP4430_PRM_MPU_INST 0x0300 >> Vs >> AM33XX_PRM_MPU_MOD 0x0E00 >> >> OMAP4430_PRM_WKUP_INST 0x1700 >> Vs >> AM33XX_PRM_WKUP_MOD 0x0D00 > > The above prcm offsets being different on am33xx doesn't really > seem to be the issue since its already part of the powerdomain > struct. See how omap2 and omap3 have different offsets and still end > up using common code. You won't need any cpu_is_* checks for those. > > The real problem however seems to be with the completely different > PWSTCTRL and PWSTST offsets. They seem to be so messed up that they are > not even consistent across all powerdomains in the same SoC. > The only solution I could think of to handle these was if we had > a provision to specify the offsets on a per powerdomain level by > adding them to the powerdomain struct. It could be populated only > on SoC's which have these weirdly different offsets and for the rest > it could just get initialized with fixed values for all powerdomains > at init. > > Kevin/Paul/Benoit any thoughts? > Something tells me that AM33x is not the last device we're going to see where there clearly wansn't a unified design around PRCM integration. So I suspect adding this to the powerdomain struct is the best way to go, but Paul/Benoit should make the final call. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
