On Thu, Aug 21, 2014 at 03:16:08PM +0200, Thierry Reding wrote: > On Thu, Aug 21, 2014 at 03:06:00PM +0200, Boris BREZILLON wrote: > > On Thu, 21 Aug 2014 11:52:03 +0200 > > Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > > > > On Thu, Aug 21, 2014 at 11:41:59AM +0200, Boris BREZILLON wrote: > > > > On Thu, 21 Aug 2014 11:04:07 +0200 > > > > Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > > > > > > > > On Thu, Aug 21, 2014 at 10:37:06AM +0200, Boris BREZILLON wrote: > > > > > > Hi Ludovic, > > > > > > > > > > > > On Thu, 21 Aug 2014 10:16:19 +0200 > > > > > > Ludovic Desroches <ludovic.desroches@xxxxxxxxx> wrote: > > > > > > > > > > > > > Hi Boris, > > > > > > > > > > > > > > You can add > > > > > > > > > > > > > > Tested-by: Ludovic Desroches <ludovic.desroches@xxxxxxxxx> > > > > > > > > > > > > Thanks for testing this driver. > > > > > > > > > > > > > > > > > > > > Only one issue but not related to your patches, you can't display > > > > > > > quickly the bootup logo since the panel detection takes too much > > > > > > > time. > > > > > > > > > > > > Yes, actually this is related to the device probe order: the > > > > > > hlcdc-display-controller device is probed before the simple-panel, thus > > > > > > nothing is detected on the RGB connector (I use of_drm_find_panel to > > > > > > check for panel availability) when the display controller is > > > > > > instantiated. I rely on the default polling infrastructure provided by > > > > > > the DRM/KMS framework which polls for a new connector every 10s, and > > > > > > this is far more than you kernel boot time. > > > > > > > > > > > > Do anyone see a solution to reduce this delay (without changing the > > > > > > polling interval). I thought we could add a notifier infrastructure to > > > > > > the DRM panel framework, but I'm not sure this is how you want things > > > > > > done... > > > > > > > > > > Other drivers return -EPROBE_DEFER when a panel hasn't been registered > > > > > yet. This will automatically take care of ordering things in a way that > > > > > DRM/KMS will only be initialized after the panel has been probed. > > > > > > > > Actually I'd like to avoid doing this with a deferred probe, because, > > > > AFAIU, the remote endpoint is not tightly linked with the display > > > > controller driver (I mean the display controller can still be > > > > initialized without having a display connected on it). > > > > Moreover the atmel dev kit I'm using has an HDMI bridge connected on > > > > the same RGB connector and I'd like to use it in a near future. > > > > Returning -EPROBE_DEFER in case of several devices connected on the > > > > same connector implies that I'll have to wait for all the remote > > > > end-points to be available before my display controller could be > > > > instantiated. > > > > > > > > While this could be acceptable when all drivers are statically linked > > > > in the kernel, it might be problematic when you're using modules, > > > > meaning that you won't be able to display anything on your LCD panel > > > > until your HDMI bridge module has been loaded. > > > > > > No. HDMI should be using proper hotplugging anyway, hence it should be > > > always be loaded anyway. You're in for a world of pain if you think you > > > can run DRM with a driver that's composed of separate kernel modules. > > > > I was talking about the external RGB to HDMI encoder, should the driver > > for this encoder (which is not on On Chip block) be compiled > > statically too ? > > > > > > > > Also if you don't want to use deferred probe, then you're in for the > > > full hotplugging panel dance and that implies that you need to fix a > > > bunch of things in DRM (one being the framebuffer console instantiation > > > that I referred to in the other thread). > > > > For now, I wait until there is a device connected on the RGB connector > > (connector status set to connector_status_connected) before creating an > > fbdev. It might not be the cleanest way to solve this issue, but it > > works :-). > > Yeah, I guess that's one way to do it. But it's tricky to get right when > you have several outputs. Which one should be considered the primary and > trigger fbdev creation? We could just reallocate the fbdev backing storage (probably only increase it for safety since fbdev is bonghits) when new outputs show up. There has been (and maybe still is) some provisions in the fbdev helper library to do just that. Mostly it would mean to split out drm_fb_helper_single_fb_probe so that drivers could call it from their hotplug work. And then adjust the ->fb_probe callback of drivers which do this to reallocate the fbdev buffer if it's only a resize. Overall this shouldn't be too much fuzz to get going. Of course only as an opt-in, but imo that's the only sane way to do this anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
