[PATCHv8 4/5] OMAP: I2C: Remove the reset in the init path

[Shubhrajyoti]

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" <shubhrajyoti at ti.com> writes:
>>>
>>>> On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti
>>>> <shubhrajyoti at ti.com> wrote:
>>>>> On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti <shubhrajyoti at ti.com> wrote:
>>>>>> On Friday 16 December 2011 02:10 PM, Paul Walmsley wrote:
>>>>>>
>>>>>>> This patch either needs to be acked by Ben with a note that it's okay for
>>>>>>> us to merge through the OMAP tree, or needs to be merged by Ben during the
>>>>>>> 3.4 merge window, after patches 1-3 have reached the mainline tree.
>>>>>> I agree.
>>>>>> Ben do you have any comments .
>>>> If there are no further comments can this be merged also ?
>>> As Benoit mentioned earlier, the addition of new pdata fields will cause
>>> problems with the DT support already queued for v3.3.
>>>
>>> This series should be reworked on top of the DT support which Ben has
>>> now queued for v3.3 (my branch: for_3.3/i2c/misc)
>> Yes will rework it.
> Depending on what you plan to do, you'll probably need to coordinate this 
> with Tony also.  He's already pulled some of the patches from this series 
> into his i2c branch.
>
> 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*() functions from the driver directly), nor should 
> the driver touch the SYSCONFIG register directly.


Paul I thought through it myself not very clear.
- One way is to find some way for the dt to pass function pointer. Or maybe
a flag that  activates a static function / hwmod func.
 
Will give this a little more thought and get back. I have not any answer
right now.

>
> - Paul