* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [150126 02:42]: > On 24/01/15 23:51, Paul Walmsley wrote: > > + Tomi > > > > On Thu, 27 Nov 2014, Tero Kristo wrote: > > > >> Splits the clock provider init out of the PRM driver and moves it to > >> clock driver. This is needed so that once the PRCM drivers are separated, > >> they can logically just access the clock driver not needing to go through > >> common PRM code. This would be wrong in the case of control module for > >> example. > >> > >> Signed-off-by: Tero Kristo <t-kristo@xxxxxx> > > > > This patch moves things in the wrong direction (ie, rather than keeping > > the PRM register accesses in the PRM code, it moves PRM register accesses > > into the clock code). But I see that a subsequent patch in this series > > moves them back. So this change is temporary and that seems reasonable to > > me. > > > > However, as long as the clock code wants to do low-level register accesses > > to PRM/CM/SCM registers, there needs to be some way to keep register > > updates originating from the clock code from racing with register updates > > coming from other code (e.g. non-clock-related PRM/CM/SCM accesses). So > > I've changed this patch to use regmap (as below), and the followup patch > > later in the series will be changed too. Seems to work so far but let's > > see how things go with the rest of the series. > > I'm not sure if I miss something, but regmap_write does not protect from > problems if there are multiple users for the same registers. You need to > use regmap_update_bits() to get a protected read/write sequence, in > which you can change only the bits that you want to change. To me it seems that issue can be fixed by making all the code use regmap. AFAIK that should work for the legacy code too. Regards, Tony -- 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
