On Thu, 21 Aug 2014 17:04:34 +0200 Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote: > On 08/21/2014 03:21 PM, Thierry Reding wrote: > > On Thu, Aug 21, 2014 at 12:32:43PM +0200, Andrzej Hajda wrote: > >> On 08/21/2014 11:52 AM, Thierry Reding 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. > >>> > >>> 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). You also can't be using the > >>> current device tree bindings because they all assume a dependency from > >>> the display controller/output to the panel. For hotplugging you'd need > >>> the dependency the other way around (the panel needs to refer to the > >>> output by phandle). > >> I have tested panel as a module in exynos-dsi + panel-s6e8aa0 > >> configuration, everything works. There is a workaround for fb console > >> not being reconfigurable, but it does not make thing worse than before. > >> And I do not see a problem with phandles, ie in DT they point both ways, > >> according to binding advices at the time, but in the code it is display > >> controller/encoder which is looking for the panel. > > That works because it's DSI. And we have attach/detach callbacks for > > DSI. We don't have those for regular panels, so we'd need to find a way > > to add that. > > Maybe I have misread your answer, but you showed it as very > difficult/painful > process: "hotplugging panel dance", "fix a bunch of things in DRM". In fact > we are missing here only good notifications about panel appearance. > > > > > The way that this currently works is that an encoder/connector driver > > looks up the panel and attaches it to itself. If you allow panels to be > > hotpluggable, then they have no knowledge about what they are connected > > to, so there needs to be a way to inject that knowledge so that they can > > attach to a connector. > > I do not understand that. Currently it is the connector who looks for > the panel > and attaches it. > So the scenario, after adding panel tracking, could be: > - encoder parses its phandle to panel, and start tracking appearance of > the panel > identified by this phandle, > - when panel appears encoder callback is called, and encoder attaches > the panel, > - when panel wants to disappear encoder callback is called, encoder > detaches the panel. > > All this I have already presented together with generic interface > tracker [1]. Well, your attempt at doing a generic tracker framework sounds interesting, but given the answer you've got from greg-kh and Russel, I'd say this patch series is in a dead-end (unless there are other versions I haven't seen yet). How about implementing a specific notifier interface for the drm_panel framework first, and move to your generic implementation if it gets accepted. These are the two proposal I sent to Thierry: http://code.bulix.org/scq4g3-86804 (v1) and http://code.bulix.org/7urh8v-86806 (v2) Feel free to propose any alternative to those implementations. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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
