> On Oct 18, 2018, at 3:03 AM, jacopo mondi <jacopo@xxxxxxxxxx> wrote: > >> On Thu, Oct 18, 2018 at 11:31:52AM +0200, Maxime Ripard wrote: >>> On Wed, Oct 17, 2018 at 09:51:43PM +0200, jacopo mondi wrote: >>> Hello Sam and Maxime (and other ov5640-ers :) >>> >>>> On Wed, Oct 17, 2018 at 10:54:01AM -0700, Sam Bobrowicz wrote: >>>> Hello Maxime and Jacopo (and other ov5640-ers), >>>> >>>> I just submitted my version of this patch to the mailing list as RFC. >>>> It is working on my MIPI platform. Please try it if you have time. >>>> Hopefully we can merge these two into a single patch that doesn't >>>> break any platforms. >>> >>> Thanks, I have seen your patch but it seems to contain a lot of things >>> already part of Maxime's series. Was this intentional? >>> >>> Now the un-pleaseant part: I have just sent out my re-implementation >>> of the MIPI clock tree configuration, based on top of Maxime's series. >>> Both you and me have spent a looot of time on this I'm sure, and now >>> we have two competing implementations. >>> >>> I had a quick look at yours, and for sure there are things I am not >>> taking care of (I'm thinking about the 0x4837 register that seems to >>> be important for your platform), so I think both our implementations >>> can benefits from a comparison. What is important to me is that both >>> you and me don't feel like our work has been wasted, so let's try to >>> find out a way to get the better of the two put together, and possibly >>> applied on top of Maxime's series, so that a v5 of this will work for >>> both MIPI and DVP interfaces. How to do that I'm not sure atm, I think >>> other reviewers might help in that if they want to have a look at both >>> our series :) >> >> IIRC, Sam's system has never worked with the ov5640 driver, and his >> patches now make it work. >> >> Your patches on the other hand make sure that the current series >> doesn't break existing users. So I guess we could merge your current >> patches into the v5 of my rework, and have Sam send his work on top of >> that. >> >> Does that make sense? > > It does for me, but it puts the burden on Sam to re-apply his work > on top of [yours+mine] (which is something he would have had to do > anyhow to have his patches accepted, as he would have had to rebase on > top of your series). > Don’t worry about it :) > I hope to find some more time to look into his series and find out how > hard it would be to add his changes on top of mine, and hopefully help > with this. > Also, testing my patches with DVP would be nice (it should not be > affected at all, but still...) > > Thanks > j > >> >> Maxime >> >> -- >> Maxime Ripard, Bootlin >> Embedded Linux and Kernel engineering >> https://bootlin.com > > I’m fine with this approach, but it takes my ability to easily test your changes on my MIPI platform off the table. I will be around to run some manual tests on your algorithms and answer tech details about my experiments with the sensor, but it will fall on Jacobi to ensure that whatever patch you land on doesn’t introduce a regression for MIPI platforms. I can then submit a PCLK period patch on top of what you end up with, which will then put my platform in the game. Sam
