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@xxxxxx> writes: >>> >>>> On Tue, Jan 10, 2012 at 11:53 AM, Datta, Shubhrajyoti >>>> <shubhrajyoti@xxxxxx> wrote: >>>>> On Fri, Dec 16, 2011 at 2:29 PM, Shubhrajyoti <shubhrajyoti@xxxxxx> 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 -- 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
