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
Cousson, Benoit had written, on 03/23/2010 11:12 AM, the following:
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
Sent: Tuesday, March 23, 2010 2:00 PM
Gopinath, Thara had written, on 03/23/2010 12:06 AM, the following:
[...] [I
Cousson, Benoit had written, on 03/21/2010 04:50 PM, the following:
[...]
now in the approach I took,
you could have:
struct sr_ntarget_type{
unsigned long nTarget;
something else if needed
}
I'm still not convinced...
It appears that there is still some confusion with what OPP
From: Menon, Nishanth
Sent: Monday, March 22, 2010 2:30 PM
Cousson, Benoit had written, on 03/21/2010 04:50 PM, the following:
[...]
now in the approach I took,
you could have:
struct sr_ntarget_type{
unsigned long nTarget;
something else if needed
}
I'm still not
Cousson, Benoit had written, on 03/22/2010 12:46 PM, the following:
From: Menon, Nishanth
Sent: Monday, March 22, 2010 2:30 PM
Cousson, Benoit had written, on 03/21/2010 04:50 PM, the following:
[...]
now in the approach I took,
you could have:
struct sr_ntarget_type{
unsigned long
[...] [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
Hi Nishanth,
From: Menon, Nishanth
Sent: Friday, March 19, 2010 4:25 PM
Felipe Balbi had written, on 03/19/2010 09:43 AM, the following:
hi,
On Thu, Mar 18, 2010 at 07:44:50PM +0100, ext Nishanth Menon wrote:
+int opp_store_data(struct omap_opp *opp, char *name, void *data)
+{
+ return
Hi Nishanth,
From: Menon, Nishanth
Sent: Thursday, March 18, 2010 7:45 PM
Many modules seem to need some sort of flexible storage mechanism
which is corresponds to a specific opp. To cater to this need, we
provide store, restore and removal apis.
Do we really need that level of flexibility for
Cousson, Benoit had written, on 03/19/2010 05:14 AM, the following:
Hi Nishanth,
From: Menon, Nishanth
Sent: Thursday, March 18, 2010 7:45 PM
Many modules seem to need some sort of flexible storage mechanism
which is corresponds to a specific opp. To cater to this need, we
provide store,
hi,
On Thu, Mar 18, 2010 at 07:44:50PM +0100, ext Nishanth Menon wrote:
+int opp_store_data(struct omap_opp *opp, char *name, void *data)
+{
+ return -EINVAL;
Would -ENODATA fit better ??
diff --git a/arch/arm/plat-omap/opp.c b/arch/arm/plat-omap/opp.c
index bb8120e..15f6f7c 100644
Hi,
On Fri, Mar 19, 2010 at 10:25:18AM -0500, Nishanth Menon wrote:
Now, based on your proposal as I understand,
struct omap2_data {
blah_o21
blah_o22
};
struct omap3_data {
blah_o31
blah_o32
blah_o33
}
struct omap4_data {
blah_o41
blah_o42
blah_o31
blah_o32
}
and so on
Felipe Balbi had written, on 03/19/2010 12:47 PM, the following:
[...]
now in the approach I took,
you could have:
struct sr_ntarget_type{
unsigned long nTarget;
something else if needed
}
And in SR driver, the module doesnot need to care which silicon it is
running on.. it
12 matches
Mail list logo
