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 a
>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 am not about to repeat everything I stated in previous
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 ho
>>
>>[...] [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
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 nTarge
>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
>>> }
>>
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 is
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)
>>> +
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 jus
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
> }
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 -EINVAL;
Would -ENODATA fit better ??
wondered later on if 0 is better h
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
---
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, resto
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
14 matches
Mail list logo