[PATCH v2 1/2] [media] s5p-g2d: Add DT based discovery support

[Sachin Kamat]

On Thursday, 14 February 2013, Sylwester Nawrocki <
sylvester.nawrocki at gmail.com> wrote:
> On 02/12/2013 06:30 PM, Sachin Kamat wrote:
>>
>> Hi Sylwester,
>>
>> On Wednesday, 6 February 2013, Sachin Kamat <sachin.kamat at linaro.org>
wrote:
>>>
>>>  This patch adds device tree based discovery support to G2D driver
>>>
>>>  Signed-off-by: Sachin Kamat <sachin.kamat at linaro.org>
>>>  ---
>>>  Based on for_v3.9 branch of below tree:
>>>  git://linuxtv.org/snawrocki/samsung.git
>>>
>>>  Changes since v1:
>>>  * Addressed review comments from Sylwester <s.nawrocki at samsung.com>.
>>>  * Modified the compatible string as per the discussions at [1].
>>>  [1] https://patchwork1.kernel.org/patch/2045821/
>>>
>>
>> Does this patch look good?
>
> It looks OK to me. I've sent a pull request including it, but it may
> happen it ends up only in 3.10.

Thanks. Hope it gets picked for 3.9 itself.

>
> I tried to test this patch today and I had to correct some clock
> definitions in the common clock API driver [1]. And we already have
> quite a few fixes to that patch series.
>
> Shouldn't you also provide a patch adding related OF_DEV_AUXDATA entry ?
> How did you test this one ?

I tested this without the common clock patches, with the mainline tree. It
did not require any auxdata  entry.
>
> When the new clocks driver gets merged (I guess it happens only in 3.10)
> I'd like to have the media devices' clock names cleaned up, instead of
> names like: {"sclk_fimg2d", "fimg2d"}, {"sclk_fimc", "fimc"},
> {"sclk_fimd"/"fimd"}, in clock-names property we could have common names,
> e.g. { "sclk", "gate" }. This could simplify a bit subsystems like
devfreq.

Yes. That makes sense.

>
> Also I noticed there are some issues caused by splitting mux + div + gate
> clocks into 3 different clocks. One solution to this might be to use the
> new composite clock type.

Ok.

>
> [1] http://www.spinics.net/lists/arm-kernel/msg214149.html
>

-- 
With warm regards,
Sachin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20130214/446beb86/attachment-0001.html>