On Sat, Nov 15, 2014 at 06:07:50PM +0800, Daniel Kurtz wrote: > 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. Once the wranglings on the patch series are complete, I do intend to test it on the platforms I have - and remember that I do have the ALSA based audio and CEC bits as well, some of which will probably need a little bit of re-work. All in all, I welcome the renaming of this to include a reference to DesignWare - I've always thought it's a mistake that the HDMI interface in iMX6 was not named with a "dw" prefix as the docs contain references to it being a DesignWare IP module. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
