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
--
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
