Re: [PM-WIP-OPP][PATCH 3/4] omap: pm: opp: add ability to store data per opp

[Nishanth Menon <nm@ti.com>]

Gopinath, Thara had written, on 03/23/2010 12:06 AM, the following:
> 
>>> [...] [I am not about to repeat everything I stated in previous
>>> threads.. so  snipping the discussion down.]
>>>
>>>> Otherwise the primary idea to remove OPP ID is good, and the way to go.
>>> good. So lets NAK that SR series and see how else we can implement it
>>> without OPP ID. I am open to any clean mechanisms you may propose
>>> without using OPP ID referencing :).
> 
> Ok guys.. In the current V2 series , I have linked N targets with voltage..
 > Only it does not come from voltage layer but from smartreflex devices 
layer.
 > The smartreflex driver does not use opp ids at all.. Also whether you 
call
 >it by opp ids or by any other name, we need to know the number of 
different
 > voltages supported by VDD1 and VDD2 and form the table.. That is exactly
 >what I am doing in smartreflex device layer. I am just creating a 
table with
 >different voltages and N target values associated with those voltages.
 > To create this table I need to know there should be 5 voltages for VDD1
 > and 3 voltages for VDD2 which unfortunately coincides with the number of
 > different OPP's defined in OMAP3430 today..
SR patches should ideally be discussed in SR patch series context 
anyways, since we are looking at the fundamentals of OPP:
3430: VDD1: 5 voltages+frequencies, VDD2: 3 voltages and frequencies
3630: VDD1: 4 voltages+frequencies, VDD2: 2 voltages and frequencies
are there cases where the number of discrete voltage != number of 
supported frequencies?

Agreed that for a voltage the characteristic data is unique. but since a 
voltage is tied to a frequency, does'nt it make sense to tie it to an 
OPP (my initial point in the first place)?

look at the amount of redundant data:
  static void __init omap34xx_sr_volt_details(struct omap_smartreflex_data
                                                  *sr_data, int srid)
  {
          if (srid == SR1) {
                  sr_data->no_opp = opp_get_opp_count(OPP_MPU);
                  sr_data->sr_volt_data = 
kzalloc(sizeof(sr_data->sr_volt_data) *
                                  sr_data->no_opp , GFP_KERNEL);
                  WARN_ON(!sr_data->sr_volt_data);
                  sr_data->sr_volt_data[0].voltage = 975000;
                  sr_data->sr_volt_data[1].voltage = 1075000;
                  sr_data->sr_volt_data[2].voltage = 1200000;
                  sr_data->sr_volt_data[3].voltage = 1270000;
                  sr_data->sr_volt_data[4].voltage = 1350000;
          } else if (srid == SR2) {
                  sr_data->no_opp = 3;
                  sr_data->sr_volt_data = 
kzalloc(sizeof(sr_data->sr_volt_data) *
                                  sr_data->no_opp , GFP_KERNEL);
                  WARN_ON(!sr_data->sr_volt_data);
                  sr_data->sr_volt_data[0].voltage = 975000;
                  sr_data->sr_volt_data[1].voltage = 1050000;
                  sr_data->sr_volt_data[2].voltage = 1150000;
          }
  }

If you link sr_volt_data with OPP, you have a simple scalable soln 
without having to manage voltage in multiple places etc.

the implementation is definitely based on number of OPPs :). and it is 
not exactly the most scalable implementation currently present.
> I also think it is an excellent idea to NAK a series of 19 patches for
 > which everybody has been shouting for, for this reason.
NAK was for SRID usage and voltage indexing which makes scaling across 
silicon variants troublesome.

-- 
Regards,
Nishanth Menon