On Fri, Nov 14, 2014 at 7:13 PM, Zubair Lutfullah Kakakhel <Zubair.Kakakhel@xxxxxxxxxx> wrote: > > > On 14/11/14 11:08, Andy Yan wrote: >> >> On 2014年11月14日 18:55, Zubair Lutfullah Kakakhel wrote: >>> >>> On 14/11/14 10:53, Andy Yan wrote: >>>> Hi ZubairLK: >>>> Thanks for your review. >>>> On 2014年11月14日 18:19, Zubair Lutfullah Kakakhel wrote: >>>>> Hi Andy, >>>>> >>>>> Nice work on this patch series. Its getting better and better :). >>>>> >>>>> On 14/11/14 03:27, Andy Yan wrote: >>>>>> hdmi phy clock symbol and transmission termination value >>>>>> can adjust platform specific to get the best SI >>>>> ^Is this signal integrity? >>>> yes , SI is signal integrity, such as eye diagram measurement >>>>> Are these two disjoint features in separate patches? >>>>> >>>>>> also add mode_valid interface for some platform may not support >>>>>> all the display mode >>>>> Sounds like another separate patch to me. :) >>>> they can seperate >>>>> Also, This series is becoming quite large. With major changes and fixes mixed together. >>>>> >>>>> Patch 3 splits imx-drm. >>>>> Patch 4 moves dw-drm out of imx-drm folder. >>>>> Patch 7 adds binding >>>>> Patch 9 converts to drm bridge. >>>>> >>>>> Can these be placed together easily? >>>>> And in the start. i.e. patch 1, 2, 3, 4, >>>>> >>>>> Then all fixes etc can come afterwards? >>>>> >>>>> It helps when checking histories later as to how a driver was made and how fixes happened. >>>>> >>>>> Especially when file moves happen.. >>>> Do you mean we can rearrange the patch series? >>>> put patch 3, 4 ,7, 9 together one bye one >>>> than followed by the fixes patches 5 ,6, 8, 11 ? >>> Yes. Rearrange so that the split imx-drm/imx-hdmi and conversion to drm-bridge is at the start of the series. >>> Then the rest are bug fixes and feature additions. >> Can I put patch#1(make checkpatch happy) and patch#2 (defer probe) as the first two patch. >> Daniel from Google chromium think it's better to put the two slightly changes in the front for easy review. Sorry, I didn't see this conversation before my earlier emails. I was suggesting to Andy to arrange his patches like this: (1) fixes that directly apply to imx-drm as it is today. (2) split out the "generic dw_hdmi" parts from imx-hdmi into dw_hdmi.c (3) convert dw_hdmi.c to a drm_bridge (4) move the dw_hdmi.c bridge implementation to drm/bridge (5) modifications to dw_hdmi.c required to support hdmi on rk3288 (5) add rk3288-hdmi.c to drm/rockchip (at least whenever drm/rockchip lands) The idea being that we can start landing the patches for (1) even while we are still debating / reviewing (2)+ upstream. > Sure. > > I am not the maintainer. They have to make the final decision. imx-drm is still in staging. I do not see anyone listed explicitly under MAINTAINERS for drivers/staging/imx-drm, so by default I guess it falls back to gregkh (drivers/staging/)? The "Commit" field in git log seems to back this up. Although, based on Author, I think we also want the opinions of Philipp Zabel and Russel King. Thanks, -djk > > ZubairLK _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
