Hello Ajay, On Thu, Jul 31, 2014 at 12:58 PM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Wed, Jul 30, 2014 at 09:33:28PM +0530, Ajay kumar wrote: >> On Wed, Jul 30, 2014 at 8:38 PM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > [...] >> > I think it should even be possible to do this in more separate steps. >> > For example you could add the new bridge infrastructure without touching >> > any of the existing drivers (so that they are completely unaffected by >> > the changes) and then start converting one by one. >> > >> > For some of the changes this may be difficult (such as the dev -> >> > drm_dev rename to make room for the new struct device *dev). But that >> > could for example be done in a preparatory patch that first renames the >> > field, so that the "infrastructure" patch can add the new field without >> > renaming any fields and therefore needing changes to drivers directly. >> > >> > The goal of that whole exercise is to allow display drivers to keep >> > working with the existing API (ptn3460_init()) while we convert the >> > bridge drivers to register with the new framework. Then we can more >> > safely convert each display driver individually to make use of the new >> > framework and once all drivers have been converted the old API can >> > simply be removed. >> > >> > That way there should be no impact on existing functionality at any >> > point. >> As of now only exynos_dp uses ptn3460_init. >> And, also only 2 drivers use drm_bridge_init. >> It should be really easy to bisect if something goes wrong. >> Still, I will try to divide it so that each patch contains minimal change. > > Thanks. > Do you plan to address Thierry's concerns and re-spin this patch? Same question for patches: "drm/bridge: Add i2c based driver for ptn3460 bridge" "drm/bridge: Add i2c based driver for ps8622/ps8625 bridge" Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
