Re: [PATCH V2 0/7] drm/tilcdc: bug fixes, mode selection improvements

[Darren Etheridge <detheridge@ti.com>]

Rob Clark <robdclark@gmail.com> wrote on Wed [2013-Jun-26 11:42:44 -0400]:
> On Fri, Jun 21, 2013 at 2:52 PM, Darren Etheridge <detheridge@ti.com> wrote:
> > The series of patches that follow are intended to address issues that
> > have been found in the tilcdc drm driver. The patchset enables support
> > for screen resolutions with horizontal resolutions greater than 1024
> > pixels.  The patchset also addresses a limitation where certain
> > monitor timings would overflow LCD controller timing registers causing
> > either no monitor signal or a very corrupted display.  This patchset
> > will stop monitor modes from being reported as valid if the lcd
> > controller cannot support them.
> >
> > V2:
> >         Fix typos in commit messages
> >         Add a patch that enables runtime modesetting to work correctly
> >         Fix an issue where the slave encoder can initialize before the i2c
> >                 subsystem, resulting in no displays being configured.
> >
> for the series:
> Acked-by: Rob Clark <robdclark@gmail.com>
> 
> the i2c/slave race thing.. well, isn't pretty.. but right now I don't
> see a better way.  I guess at some point we need to revisit how the
> encoder-slave stuff gets loaded in drm
> 
Thanks Rob.  
Yes I agree with your assessment,  I looked at using the
module list as a way to indicate if a given module is deferred or not
but this had its own difficulties.  This patch was the easiest way to
defer the probing at the earliest possible point for both the slave
module and the main tilcdc driver.  

Reordering the drivers/Makefile was the other suggestion that was
given. By moving the Makefile drm entry to a point after the i2c entry
the order that the initilization happens is changed. This certainly
appeared to work when I tried it. However I was really concerned that this
would have horrible side effects for drivers that I had no knowledge about
and no way of testing.  So my provided solution while not elegant its
impact is at least localized to the tilcdc driver.

Darren