* Tero Kristo <t-kristo@xxxxxx> [140922 06:18]: > On 09/19/2014 07:30 PM, Paul Walmsley wrote: > >On Thu, 18 Sep 2014, Tony Lindgren wrote: > > > >>* Tero Kristo <t-kristo@xxxxxx> [140901 11:09]: > >>>Hi, > >>> > >>>This set contains PRCM related cleanups meant for 3.18 merge window. > >>>These are based on top of 3.17-rc1 + the PRM set from Nishanth Menon > >>>(http://article.gmane.org/gmane.linux.ports.arm.kernel/350305.) Nishanth's > >>>set is used as basis to avoid merge issues. > >>> > >>>Purpose of this work is to eventually convert the PRCM code into a > >>>separate driver, but this is done in incremental parts as the amount > >>>of changes is substantial. Expected conclusion of this work is 3.19 > >>>if everything goes fine. > >>> > >>>This part of the work mostly moves some of the SoC specific PRCM driver > >>>calls under generic version of the same, and adds SoC-ops to support > >>>these on the driver level. > >>> > >>>Working branch posted here: > >>> > >>>tree: https://github.com/t-kristo/linux-pm.git > >>>branch: for-v3.18/prcm-cleanup > > Hi, > > I pushed v2 of this set as 'for-v3.18/prcm-cleanup-v2' to my tree. Basically > to address the below comments, and additionally I changed a few public cm_* > api names to omap_cm_* + add the tested-by/acked-by statuses. Tony/Paul, do > you want me to repost the series, or are you ok with a local diff / pull > only? If the changes were minor, at least I'm fine without reposting. But let's wait to hear from Paul in case he has further comments. Regards, Tony > >> > >>Paul, any comments on this series? > > > >Patches 1, 3, 5, 8, 10, 13, 17, 18, 20, 21, 22, 23, 24 are: > > > >Acked-by: Paul Walmsley <paul@xxxxxxxxx> > > Thanks, added acks to v2 patches. > > > > >Here are some specific comments on a few other patches: > > > >Regarding patch 7: The kerneldoc-nano function comments are good, but > >should begin with "/**" rather than "/*". When that's fixed, it can be > >considered acked by me. > > Yea, this was a typo, thanks for noticing. > > > > >Regarding patches 14, 15, 16: Non-static prm_* functions really should > >start with omap*_ to avoid potential naming conflicts with other drivers > >when these are moved to drivers/. (Obviously the same would apply for any > >CM function names in other, future patches.) When that's fixed, it can be > >considered acked by me. > > Ok, changed. Additionally I changed some cm_* prototypes in patches #6, #7 > and #9 to be of form omap_cm_*. > > >Regarding patch 25: What are "I/O wakeup gaes" -- gates? When that's > >fixed, an acked-by for me can be added. > > Yes, gates. Fixed. > > >Regarding patch 26: It seems wise to ensure that omap_prm_reset_system() > >ends with a 'while(1) { cpu_relax(); }' or something similar, to ensure > >that execution flow does not proceed past that point. At that point, it > >should be possible to remove the "while(1) {}"s from omap44xx_restart(), > >omap2xxx_restart(), etc. When that's fixed, an acked-by for me can be > >added. > > Ok, changed this also. Added the while(1) cpu_relax(); part to the public > API, and removed the loops from everywhere else. > > > > >... > > > >And some general comments: none of which should probably block this > >series, but seemed worth noting: > > > >Regarding patches 6 and 19: Tero, could you please share the DT node data > >that you're planning to submit for the PRM, CM1, and CM2 on the OMAP4* > >platforms? According to the TRM, these are separate IP blocks, with > >separate OCP header register areas. So these should probably have > >separate DT nodes, regs, etc. if the DTS files are to match the hardware. > >The planned DTS data may impact the way these patches are written, at > >least, if more patches are to be avoided later. > > We already have the nodes for these. Check out omap4.dtsi for example, we > have nodes for prm/cm1/cm2/scrm there already. These were already defined > when the clock DT data was introduced, and I don't foresee any changes to > the nodes as of now. The nodes only contain register space info as of now, > and Nishanth is adding the interrupt property for PRM interrupt purposes, > but rest of the features are probably going to be hardcoded within the PRCM > drivers themselves. > > If you are interested, feel free to look at for-3.19/prcm-cleanup branch in > my git tree, this contains the remaining patches I have for PRCM cleanup > after this set available as of now. > > -Tero > > > > >As far as patches 2, 4, 9, 11, and 12 go, I'll let those go without > >comment. > > > > > >- Paul > > > -- 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
