Re: [PATCH v6 0/8] Move device tree graph parsing helpers to drivers/of

[Sylwester Nawrocki <s.nawrocki@samsung.com>]

On 06/03/14 17:21, Philipp Zabel wrote:
> Am Donnerstag, den 06.03.2014, 16:47 +0100 schrieb Sylwester Nawrocki:
>> On 06/03/14 16:17, Mauro Carvalho Chehab wrote:
>>> Em Thu, 06 Mar 2014 14:16:57 +0000
>>> Russell King - ARM Linux <linux@arm.linux.org.uk> escreveu:
>>>>> On Wed, Mar 05, 2014 at 03:42:34PM +0100, Philipp Zabel wrote:
>>>>>>> Am Mittwoch, den 05.03.2014, 13:35 +0200 schrieb Tomi Valkeinen:
> [...]
>>>>>>>>> So, as I've pointed out, I don't agree with the API, as it's too limited
>>>>>>>>> and I can't use it, but as this series is (mostly) about moving the
>>>>>>>>> current API to a common place, it's fine for me.
>>>>>>>>>
>>>>>>>>> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>>>>>>
>>>>>>> Thanks. I'll be happy to help expanding the API to parse ports
>>>>>>> individually, once this gets accepted.
>>>>>>>
>>>>>>> Mauro, Guennadi, are you fine with how this turned out? I'd like to get
>>>>>>> your acks again, for the changed location.
>>>
>>> From my side, there's nothing on such code that is V4L2 specific.
>>> Moving it to drivers/of makes sense on my eyes.
>>>
>>> Acked-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
>>
>> I'm OK with patches 1...5, 8, so for these:
>>
>> Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>>
>> Regarding the simplified version of the binding, I thought we should
>> leave 'port' instead of 'endpoint' node. This could cover more hardware
>> configurations. Are there any users of this simplified binding queued
>> for v3.15 ? If not, perhaps we can postpone it and discuss it a bit more
>> (sorry, couldn't find time to comment on that earlier) ?
> 
> Since Tomi needs the separate port/endpoint iteration anyway, 
> postponing the simple bindings shouldn't hurt. I'll (re)submit them
> together in a second series.

Ok, thanks.

>>>>> I'll need those acks before I can even think about queuing up the
>>>>> imx-drm bits.
>>>>>
>>>>> Another way to deal with this is if this gets pulled into the V4L tree
>>>>> from Philipp's git tree, I can also pull that in myself.  What mustn't
>>>>> happen is for these to be committed independently as patches.
>>>
>>> If everyone agrees, I actually prefer have this patch applied on my tree,
>>> in order to avoid some potential merge conflicts at the merge window,
>>> as we might have other drivers and changes there touching on those API
>>> calls (I'm aware of a series of patches from Sylwester with some DT
>>> stuff on it. Not sure if it would be affected by such changes or not).
>>
>> Yes, it's going to conflict with my patch series. I thought it could be
>> put onto a stable a topic branch, e.g. at git://linuxtv.org/media_tree.git,
>> which could be then pulled into the media master branch and anywhere
>> else it is needed ?
> 
> Mauro, are you ok with handling the conflict in the merge, or should I
> rebase on top of the media tree after you merged Sylwester's changes?

I could rebase and resolve any conflicts before sending my pull request
to Mauro. I don't think it's a good idea to rebase this series onto the
media tree, since it is touching drivers/of.

--
Regards,
Sylwester