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?
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
