Andrii, Sorry to nitpick further but this your replies look very non-standard. Typically a right chevron and a space is used to indent replies instead of a tab. Something like this: https://wiki.openstack.org/wiki/MailingListEtiquette#Reply_Level_Indication Quoting Andrii Tseglytskyi (2013-04-01 03:53:25) > In case if VC/VP use clock notifier to scale voltage, there is no guarantee of > order. > The only option which I see is to create ABB API and call it from OMAP > regulator during OPP change. > I doubt that is the only option. Do you mean it is the only option to quickly get it working right now? The VC & VP code should be converted to the regulator framework if not already. After that is done there are some options for how ABB is handled. The VC & VP regulator driver could directly call the api's you list below in their .set_voltage callback. Additionally if the regulator is reentrant then ABB could be modeled as a regulator itself and the VC or VP .set_voltage callback could perhaps call regulator_set_mode(abb_reg, FBB_MODE). Creating a regulator for each ABB instance may be overkill or may not be overkill... that IP has been around since 3630 so several chips use it. > omap_abb_pre_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); > omap_abb_post_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); > > Mike, do you agree to proceed in this way? Also I need you opinion about files > placement. Now it is placed in > The above code looks like a quick solution to me. The long-term upstream path for this code needs be decided first. If everything is going to get converted to the regulator framework then I do not agree to proceed that way. Let's figure out what is happening to the VC/VP code first and then figure out what to do about ABB. Regards, Mike > drivers/power/avs/abb.c > > And header will be added to > include/linux/power/abb.h > > Regards, > Andrii -- 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
