Messages in this thread | | | Date | Tue, 16 Jul 2013 12:33:03 -0700 | From | Srinivas Pandruvada <> | Subject | Re: driver model, duplicate names question |
| |
On 07/16/2013 12:04 PM, Greg KH wrote: > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top Glad to learn something new today. > > On Tue, Jul 16, 2013 at 11:54:31AM -0700, Srinivas Pandruvada wrote: >> Hi, >> >> I am assigned to do add a powercap class. There are several >> technologies, which will allow to add a power budget to an individual >> device. For example, you can set a power budget to a individual >> physical cpu package, each core and uncore devices, GPUs, DRAM etc. > "classes" all reference a "device" in the system, I don't see that in > your tree below, where does that come in? How do I, as someone who > created a device in the system know to create a your new powercap class > for it? > > In other words, are you _sure_ you want a class here and not something > else (i.e. a bus?) > >> +The Power Capping framework organizes power capping devices under a tree structure. >> +At the root level, each device is under some "controller", which is the enabler >> +of technology. For example this can be "RAPL". >> +Under each controllers, there are multiple power zones, which can be independently >> +monitored and controlled. >> +Each power zone can be organized as a tree with parent, children and siblings. >> +Each power zone defines attributes to enable power monitoring and constraints. > Ah, this sounds like you want to be a bus, as you have a controller, and > then devices attached to it. > >> +Example Sys-FS Interface >> + >> +/sys/class/power_cap/intel-rapl >> +├── package-0 >> +│ ├── constraint-0 >> +│ │ ├── name >> +│ │ ├── power_limit_uw >> +│ │ └── time_window_us >> +│ ├── constraint-1 >> +│ │ ├── name >> +│ │ ├── power_limit_uw >> +│ │ └── time_window_us >> +│ ├── core >> +│ │ ├── constraint-0 >> +│ │ │ ├── name >> +│ │ │ ├── power_limit_uw >> +│ │ │ └── time_window_us >> +│ │ ├── energy_uj >> +│ │ └── max_energy_range_uj >> +│ ├── dram >> +│ │ ├── constraint-0 >> +│ │ │ ├── name >> +│ │ │ ├── power_limit_uw >> +│ │ │ └── time_window_us >> +│ │ ├── energy_uj >> +│ │ └── max_energy_range_uj >> +│ ├── energy_uj >> +│ ├── max_energy_range_uj >> +│ └── max_power_range_uw >> +├── package-1 >> +│ ├── constraint-0 >> +│ │ ├── name >> +│ │ ├── power_limit_uw >> +│ │ └── time_window_us >> +│ ├── constraint-1 >> +│ │ ├── name >> +│ │ ├── power_limit_uw >> +│ │ └── time_window_us >> +│ ├── core >> +│ │ ├── constraint-0 >> +│ │ │ ├── name >> +│ │ │ ├── power_limit_uw >> +│ │ │ └── time_window_us >> +│ │ ├── energy_uj >> +│ │ └── max_energy_range_uj >> +│ ├── dram >> +│ │ ├── constraint-0 >> +│ │ │ ├── name >> +│ │ │ ├── power_limit_uw >> +│ │ │ └── time_window_us >> +│ │ ├── energy_uj >> +│ │ └── max_energy_range_uj >> +│ ├── energy_uj >> +│ ├── max_energy_range_uj >> +│ └── max_power_range_uw >> +├── power >> +│ ├── async >> +│ ├── autosuspend_delay_ms >> +│ ├── control >> +│ ├── runtime_active_kids >> +│ ├── runtime_active_time >> +│ ├── runtime_enabled >> +│ ├── runtime_status >> +│ ├── runtime_suspended_time >> +│ └── runtime_usage >> +├── subsystem -> ../../../../class/power_cap >> +└── uevent > Ick. Rewrite this to use a bus and you should be fine, right? Don't > use a class, a class is only to be used if you have a device that is a > specific "type of thing". Like a tty device, it is a class, as lots of > different "real" devices can have tty ports on them (usb, pci, pcmcia, > platform, etc.) > > Rethink this using a bus and see if that solves your issues. You get a > hierarchy with that. And you can have different "types" of devices on > your bus, making it easy to tell the difference between a "package" and > a "constraint". > > Does that help? I will experiment your suggestion. I see this class analogous to "/sys/class/thermal", , where the thermal class provides a set of consistent interface for all thermal devices. > greg k-h > Thanks, Srinivas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |