Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Arnd Bergmann writes: > On Thursday 05 April 2012, Trilok Soni wrote: >> >> Couple of suggestions: >> >> >> >> drivers/platform/omap/avs? >> >> drivers/misc/omap/avs? >> >> > > I would definitely prefer something under drivers/power, > drivers/regulators or a new top-level directory under > drivers. > >> >>> IIRC, David Brownell was referring to the rule of three for such case. >> >>> Meaning that it worth having a generic fmwk when at least three >> >>> different drivers are doing the same kind of things. >> > >> > Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-) >> > More seriously, the OMAP code for SmartReflex is far from complete in >> > mainline. There is a plan to provide the following features: >> > - OMAP v1 IP, >> > - OMAP v2 IP, >> > - class 1.5, >> > - class 3, >> > - class 3.5, >> > - and more support for the upcoming chipsets. >> >> I don't understand much of these versions right now, but hopefully after >> going through all these docs. My only contention point is to not create >> any directory into the drivers/power, unless it is generic fwk and then >> build up "client" drivers on top of it. Meanwhile we could move this >> driver into above options as I have suggested. > > I think creating the directory in the place where we want the files > to stay in the long run is ok, if the plan is to add more drivers and > make the base code more generic. We don't have to wait until it's too > late and we absolutely need a framework ;-) Completely agree, thanks. > The part I don't understand is how this relates to the regulator framework. > Is there any overlap between the functionality provided by the > smartreflex framework and the regulator framework? If so, would it be > better to extend the existing framework so it can do smartreflex as well? IMO, there isn't any overlap with the regulator framework, and AVS drivers/devices should be separate from the regulator framework. Think of AVS/SmartReflex as a way for hardware to do automatic micro-adjustments to the regulator. The regulator voltage (a.k.a nominal voltage) will stay same from the perspective of the regulator and regulator framework, but AVS allows the hardware to do micro voltage adjustments around the nominal voltage. We recently extended the regulator framework to have allow get/set voltage hooks which can query platform-specific voltage frameworks which do hardware voltage control (which in turn can control AVS sensors/devices.) Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Hi Arnd, On Thu, Apr 19, 2012 at 3:54 PM, Arnd Bergmann wrote: > On Thursday 05 April 2012, Trilok Soni wrote: >> >> Couple of suggestions: >> >> >> >> drivers/platform/omap/avs? >> >> drivers/misc/omap/avs? >> >> > > I would definitely prefer something under drivers/power, > drivers/regulators or a new top-level directory under > drivers. Can I take this as an OK for drivers/power/avs as suggested? > >> >>> IIRC, David Brownell was referring to the rule of three for such case. >> >>> Meaning that it worth having a generic fmwk when at least three >> >>> different drivers are doing the same kind of things. >> > >> > Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-) >> > More seriously, the OMAP code for SmartReflex is far from complete in >> > mainline. There is a plan to provide the following features: >> > - OMAP v1 IP, >> > - OMAP v2 IP, >> > - class 1.5, >> > - class 3, >> > - class 3.5, >> > - and more support for the upcoming chipsets. >> >> I don't understand much of these versions right now, but hopefully after >> going through all these docs. My only contention point is to not create >> any directory into the drivers/power, unless it is generic fwk and then >> build up "client" drivers on top of it. Meanwhile we could move this >> driver into above options as I have suggested. > > I think creating the directory in the place where we want the files > to stay in the long run is ok, if the plan is to add more drivers and > make the base code more generic. We don't have to wait until it's too > late and we absolutely need a framework ;-) Agree! That is the intention to provide a fwk. > The part I don't understand is how this relates to the regulator framework. > Is there any overlap between the functionality provided by the > smartreflex framework and the regulator framework? If so, would it be > better to extend the existing framework so it can do smartreflex as well? The link with regulator has indeed an impact on the target dir, this is still unknown and discussed internally. > > Arnd Thanks, Jean -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
On Thursday 05 April 2012, Trilok Soni wrote: > >> Couple of suggestions: > >> > >> drivers/platform/omap/avs? > >> drivers/misc/omap/avs? > >> I would definitely prefer something under drivers/power, drivers/regulators or a new top-level directory under drivers. > >>> IIRC, David Brownell was referring to the rule of three for such case. > >>> Meaning that it worth having a generic fmwk when at least three > >>> different drivers are doing the same kind of things. > > > > Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-) > > More seriously, the OMAP code for SmartReflex is far from complete in > > mainline. There is a plan to provide the following features: > > - OMAP v1 IP, > > - OMAP v2 IP, > > - class 1.5, > > - class 3, > > - class 3.5, > > - and more support for the upcoming chipsets. > > I don't understand much of these versions right now, but hopefully after > going through all these docs. My only contention point is to not create > any directory into the drivers/power, unless it is generic fwk and then > build up "client" drivers on top of it. Meanwhile we could move this > driver into above options as I have suggested. I think creating the directory in the place where we want the files to stay in the long run is ok, if the plan is to add more drivers and make the base code more generic. We don't have to wait until it's too late and we absolutely need a framework ;-) The part I don't understand is how this relates to the regulator framework. Is there any overlap between the functionality provided by the smartreflex framework and the regulator framework? If so, would it be better to extend the existing framework so it can do smartreflex as well? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Hi Jean, The initial motivation is to provide a generic framework for this type of drivers, by cleaning up the current OMAP code and by providing as much generic code as possible. Cf. the patch sets I submitted before this very one: - the SR code clean-up [1], which is needed to make the code ready for the integration of new features, - the SR class support [2], which is needed for new SR classes to be implemented. From the maintainer point of view it made more sense to move the code before cleaning it up and so it should happen before [1] and [2]. The result is that [1] and [2] will need to be rebased when the move is accepted and merged in. [1] http://marc.info/?l=linux-omap&m=133055488908132&w=2 [2] http://marc.info/?l=linux-omap&m=133163445926544&w=2 I am going through your patches and including some wiki pages. I understand the SR can be connected in two ways - intelligent and dumb :) For intelligent I mean you just configure SR and it will and program PMIC, whereas in dumb scenarios application processor gets the notification and then it goes and writes into PMIC based on some floor/ceiling values. In the first case not much of apps. s/w but in the later case whole lot. Where will you put that otherwise? Couple of suggestions: drivers/platform/omap/avs? drivers/misc/omap/avs? I prefer first one. Those paths are for OMAP specific code and not for a generic framework. IIRC, David Brownell was referring to the rule of three for such case. Meaning that it worth having a generic fmwk when at least three different drivers are doing the same kind of things. Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-) More seriously, the OMAP code for SmartReflex is far from complete in mainline. There is a plan to provide the following features: - OMAP v1 IP, - OMAP v2 IP, - class 1.5, - class 3, - class 3.5, - and more support for the upcoming chipsets. I don't understand much of these versions right now, but hopefully after going through all these docs. My only contention point is to not create any directory into the drivers/power, unless it is generic fwk and then build up "client" drivers on top of it. Meanwhile we could move this driver into above options as I have suggested. ---Trilok Soni -- -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Hi! On Thu, Apr 5, 2012 at 8:53 AM, Trilok Soni wrote: > Hi Benoit, > > >> >> The main motivation is that it's a driver and thus does not have >> anything to do inside mach-omap2. > > > Right, I understood that. mach-omap2 is not suitable for full fledged > drivers. The initial motivation is to provide a generic framework for this type of drivers, by cleaning up the current OMAP code and by providing as much generic code as possible. Cf. the patch sets I submitted before this very one: - the SR code clean-up [1], which is needed to make the code ready for the integration of new features, - the SR class support [2], which is needed for new SR classes to be implemented. >From the maintainer point of view it made more sense to move the code before cleaning it up and so it should happen before [1] and [2]. The result is that [1] and [2] will need to be rebased when the move is accepted and merged in. [1] http://marc.info/?l=linux-omap&m=133055488908132&w=2 [2] http://marc.info/?l=linux-omap&m=133163445926544&w=2 >> >> Where will you put that otherwise? > > > Couple of suggestions: > > drivers/platform/omap/avs? > drivers/misc/omap/avs? > > I prefer first one. Those paths are for OMAP specific code and not for a generic framework. >> >> IIRC, David Brownell was referring to the rule of three for such case. >> Meaning that it worth having a generic fmwk when at least three >> different drivers are doing the same kind of things. Do OMAP v1 and OMAP v2 implementations count as 2 drivers? ;-) More seriously, the OMAP code for SmartReflex is far from complete in mainline. There is a plan to provide the following features: - OMAP v1 IP, - OMAP v2 IP, - class 1.5, - class 3, - class 3.5, - and more support for the upcoming chipsets. Also I am sure that other vendors could step in and have their platform specific code converted to the new fwk as well. > > > Yes, I remember that rule, but that's not stopping us to create a fwk, may > be others will rise once they see the framework and contribute > if their h/w architecture requirements are not addressed? > Thanks, Jean > > ---Trilok Soni > > -- > -- > Sent by a consultant of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Hi Benoit, The main motivation is that it's a driver and thus does not have anything to do inside mach-omap2. Right, I understood that. mach-omap2 is not suitable for full fledged drivers. Where will you put that otherwise? Couple of suggestions: drivers/platform/omap/avs? drivers/misc/omap/avs? I prefer first one. IIRC, David Brownell was referring to the rule of three for such case. Meaning that it worth having a generic fmwk when at least three different drivers are doing the same kind of things. Yes, I remember that rule, but that's not stopping us to create a fwk, may be others will rise once they see the framework and contribute if their h/w architecture requirements are not addressed? ---Trilok Soni -- -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
On 4/4/2012 9:10 PM, Trilok Soni wrote: Hi Jean, On 3/19/2012 9:42 PM, jean.pi...@newoldbits.com wrote: From: Jean Pihet Move the driver specific macros from the smartreflex header file (arch/arm/mach-omap2/smartreflex.h) in a new header file include/linux/power/smartreflex.h. This change makes the SmartReflex implementation ready for the move to drivers/. I wonder why someone would need a new directory under drivers/power where the code is not about introducing new and generic AVS framework but it is all about OMAP specific code. The main motivation is that it's a driver and thus does not have anything to do inside mach-omap2. Where will you put that otherwise? What if tomorrow new generic AVS framework comes from different chip vendor? I am sure this kind of technology would be common in newer embedded chips. Probably, but this is hard to know with only one implementation so far in the kernel. I guess when someone else will start pushing some new AVS driver inside the AVS directory, we might realize that there is enough common part to create a frwmk. IIRC, David Brownell was referring to the rule of three for such case. Meaning that it worth having a generic fmwk when at least three different drivers are doing the same kind of things. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] ARM: OMAP2+: SmartReflex: move the driver specific macros in include/linux/power
Hi Jean, On 3/19/2012 9:42 PM, jean.pi...@newoldbits.com wrote: From: Jean Pihet Move the driver specific macros from the smartreflex header file (arch/arm/mach-omap2/smartreflex.h) in a new header file include/linux/power/smartreflex.h. This change makes the SmartReflex implementation ready for the move to drivers/. I wonder why someone would need a new directory under drivers/power where the code is not about introducing new and generic AVS framework but it is all about OMAP specific code. What if tomorrow new generic AVS framework comes from different chip vendor? I am sure this kind of technology would be common in newer embedded chips. ---Trilok Soni -- -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
