On Thu, 12 Jan 2012, Cousson, Benoit wrote:
> On 1/11/2012 4:22 PM, Paul Walmsley wrote:
> > On Wed, 11 Jan 2012, Cousson, Benoit wrote:
> >
> > > Something that puzzle me on that point is most architecture does not use
> > > plateform_device and thus does not have any pdata to hack some custom
>
On 1/11/2012 4:22 PM, Paul Walmsley wrote:
On Wed, 11 Jan 2012, Cousson, Benoit wrote:
Something that puzzle me on that point is most architecture does not use
plateform_device and thus does not have any pdata to hack some custom function
pointers here an there.
It means that there is probably
On Wed, 11 Jan 2012, Cousson, Benoit wrote:
> Something that puzzle me on that point is most architecture does not use
> plateform_device and thus does not have any pdata to hack some custom function
> pointers here an there.
> It means that there is probably some better solution to handle that.
On Wed, 11 Jan 2012, Shubhrajyoti wrote:
> On Wednesday 11 January 2012 06:59 PM, Paul Walmsley wrote:
>
> > The real question is how you plan to handle the device reset function,
> > given that the driver should compile on a non-OMAP build (meaning that you
> > can't call omap_device*() functio
On 1/11/2012 2:29 PM, Paul Walmsley wrote:
On Wed, 11 Jan 2012, Shubhrajyoti wrote:
On Tuesday 10 January 2012 08:56 PM, Kevin Hilman wrote:
"Datta, Shubhrajyoti" writes:
On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti
wrote:
On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti wrote:
On Wednesday 11 January 2012 06:59 PM, Paul Walmsley wrote:
> On Wed, 11 Jan 2012, Shubhrajyoti wrote:
>
>> On Tuesday 10 January 2012 08:56 PM, Kevin Hilman wrote:
>>> "Datta, Shubhrajyoti" writes:
>>>
On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti
wrote:
> On Fri, Dec 16, 2
On Wed, 11 Jan 2012, Shubhrajyoti wrote:
> On Tuesday 10 January 2012 08:56 PM, Kevin Hilman wrote:
> > "Datta, Shubhrajyoti" writes:
> >
> >> On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti
> >> wrote:
> >>>
> >>> On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti wrote:
> On Friday 16 D
On Tuesday 10 January 2012 08:56 PM, Kevin Hilman wrote:
> "Datta, Shubhrajyoti" writes:
>
>> On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti
>> wrote:
>>>
>>>
>>> On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti wrote:
Ben,
On Friday 16 December 2011 02:10 PM, Paul Walmsley wr
"Datta, Shubhrajyoti" writes:
> On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti
> wrote:
>>
>>
>>
>> On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti wrote:
>>>
>>> Ben,
>>>
>>> On Friday 16 December 2011 02:10 PM, Paul Walmsley wrote:
>>> > Hi
>>> >
>>> > On Tue, 13 Dec 2011, Shubhrajyoti D
On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti
wrote:
>
>
>
> On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti wrote:
>>
>> Ben,
>>
>> On Friday 16 December 2011 02:10 PM, Paul Walmsley wrote:
>> > Hi
>> >
>> > On Tue, 13 Dec 2011, Shubhrajyoti D wrote:
>> >
>> >> - The reset in the driver a
Ben,
On Friday 16 December 2011 02:10 PM, Paul Walmsley wrote:
> Hi
>
> On Tue, 13 Dec 2011, Shubhrajyoti D wrote:
>
>> - The reset in the driver at init is not needed anymore as the
>>hwmod framework takes care of reseting it.
>> - Reset is removed from omap_i2c_init, which was called
>>
Hi
On Tue, 13 Dec 2011, Shubhrajyoti D wrote:
> - The reset in the driver at init is not needed anymore as the
>hwmod framework takes care of reseting it.
> - Reset is removed from omap_i2c_init, which was called
>not only during probe, but also after time out and error handling.
>d
- The reset in the driver at init is not needed anymore as the
hwmod framework takes care of reseting it.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time out and error handling.
device_reset were added in those places to effect the reset
13 matches
Mail list logo
