Re: [PATCH 1/1] Introduce Intel RAPL cooling device driver

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Apr 05, 2013 at 02:33:40PM -0700, Jacob Pan wrote:
> On Fri, 5 Apr 2013 13:23:09 -0700
> Greg KH <gregkh@linuxfoundation.org> wrote:
> 
> > On Wed, Apr 03, 2013 at 10:35:51AM -0700, Jacob Pan wrote:
> > > On Wed, 3 Apr 2013 09:35:09 -0700
> > > Greg KH <gregkh@linuxfoundation.org> wrote:
> > > 
> > > > On Tue, Apr 02, 2013 at 09:48:18PM -0700, Jacob Pan wrote:
> > > > > > Let's step back and start over, what exactly are you trying to
> > > > > > tell userspace?  What data do you have that you need to
> > > > > > express to it?  How do you want userspace to see/use it?
> > > > > 
> > > > > It is a good idea to step back and let me explain what I wanted
> > > > > to do here for userspace.
> > > > > 
> > > > > I have two kinds of applications that might use this driver.
> > > > > 1. simple use case where user sets a power limit for a RAPL
> > > > > domain. e.g. set graphics unit power limit to 7w
> > > > > 2. advanced use case where use can do fine tuning on top of
> > > > > simple power limit,e.g. the dynamic response parameters of
> > > > > power control logic, event notifications, etc.
> > > > > 
> > > > > For #1, this driver register with the abstract generic thermal
> > > > > layer (/sys/class/thermal) and presents itself as a set of
> > > > > cooling devices with a single knob per domain for power limits.
> > > > > root@chromoly:/sys/class/thermal/cooling_device15# echo 7000 >
> > > > > cur_state 
> > > > 
> > > > Great, how about submitting that functionality as patch 1 of your
> > > > series?  That seems like a very "normal" thermal driver, right?
> > > > 
> > > yes, that would be a normal thermal cooling device driver. I will do
> > > that first. Thanks for the suggestion.
> > 
> > Do that first, get it merged, and then let's work on the second part.
> > The patch for that will be much more obvious as to what you are
> > attempting to do.
> > 
> Sorry I was too busy to work on v2 before seeing this. I agree I need
> to simplify the interface, I just need to come up with a more
> intelligent way to abstract that and do the best guesses for the user.
> Hopefully, v2 will serve as a confirmation on the comments I got from
> v1. i.e. kobject->struct device, removed dependencies on sysfs internal
> data struct, etc.

I'm not going to review that part of the code, sorry, as it's about to
be ripped out anyway :)

> > > >  Perhaps the thermal interface could be expanded to provide
> > > > more functionality that you need?
> > > yes, some of them such as limits. But not all the data in the list
> > > above are suitable for thermal interface. That is why I am trying to
> > > balance between abstracted generic data and RAPL specific data while
> > > still allow linking between the two.
> > 
> > What is not in the existing interface?  And as this is a thermal
> > device, why can't you add them there?
> existing interface has only cur_state and max_state, I have been
> working with Rui (thermal maintainer) on adding more knobs for cooling
> devices, such as limit low, limit high, event control. I believe they
> can all be added.

Great, then you will not need any of the driver-specific sysfs files,
struct device usage, or kobject mess, so your code should be a lot
smaller.

greg k-h