On 07/31/2013 10:09 AM, Tero Kristo wrote:
On 07/30/2013 11:23 PM, Nishanth Menon wrote:
On 07/23/2013 02:20 AM, Tero Kristo wrote:
OMAP3 has interface clocks in addition to functional clocks, which
is it just OMAP3?
Yea, only omap3 is using this code. Basically because there is control
for the module specific interface clocks which is absent from omap4+.
Personally I think modelling the interface clocks in the first place in
kernel side was a bad idea, and should have just enabled all of them and
enable autoidles for them at the same point.
Not all autoidles work unfortunately, which is why they got modelled :D
some even have the weird tendency to hang up L3/L4 interconnect when the
OCP statemachines required inside the IP block for the autoidle PRCM
handshake has been, umm... "not well implemented" ;) forcing us to use
S/w supervised mode of operations.
require special handling for the autoidle and idle status register
offsets mainly.
Signed-off-by: Tero Kristo <t-kristo@xxxxxx>
---
drivers/clk/omap/Makefile | 2 +-
drivers/clk/omap/clk.c | 3 ++
drivers/clk/omap/interface.c | 110
++++++++++++++++++++++++++++++++++++++++++
should this be isolated off for omap3?
You mean within makefile or?
omap3-interface-clock.c or something more sensible and Makefile? I dont
really have any strong opinions on this anyways.. interface.c is fine
with me as well as the nodes are not probed unless compatible flags are
set..
just trying to save a few bits in code space by building only if OMAP3
is present.. /me shrugs..
--
Regards,
Nishanth Menon
--
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
