Rob Clark <robdclark@xxxxxxxxx> wrote on Wed [2013-Jun-26 11:42:44 -0400]: > On Fri, Jun 21, 2013 at 2:52 PM, Darren Etheridge <detheridge@xxxxxx> 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@xxxxxxxxx> > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
