From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755512AbaHUOct (ORCPT ); Thu, 21 Aug 2014 10:32:49 -0400 Received: from top.free-electrons.com ([176.31.233.9]:43954 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751476AbaHUOcq (ORCPT ); Thu, 21 Aug 2014 10:32:46 -0400 Date: Thu, 21 Aug 2014 16:32:32 +0200 From: Boris BREZILLON To: Thierry Reding Cc: Ludovic Desroches , Nicolas Ferre , Jean-Christophe Plagniol-Villard , Alexandre Belloni , Andrew Victor , David Airlie , dri-devel@lists.freedesktop.org, linux-pwm@vger.kernel.org, Samuel Ortiz , Lee Jones , Rob Clark , Laurent Pinchart , Mark Rutland , devicetree@vger.kernel.org, Pawel Moll , Ian Campbell , linux-kernel@vger.kernel.org, Rob Herring , Bo Shen , Kumar Gala , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller Message-ID: <20140821163232.475c0ed8@bbrezillon> In-Reply-To: <20140821131552.GA19293@ulmo.nvidia.com> References: <1406034695-15534-1-git-send-email-boris.brezillon@free-electrons.com> <20140821081619.GZ2452@ldesroches-Latitude-E6320> <20140821103706.2349915d@bbrezillon> <20140821090406.GA13733@ulmo> <20140821114159.319e741b@bbrezillon> <20140821095202.GA21848@ulmo> <20140821150600.37788d82@bbrezillon> <20140821131552.GA19293@ulmo.nvidia.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Aug 2014 15:16:08 +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 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 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 wrote: > > > > > > > > > > > > > Hi Boris, > > > > > > > > > > > > > > You can add > > > > > > > > > > > > > > Tested-by: Ludovic Desroches > > > > > > > > > > > > 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? > > > > 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). > > > > Here [1] is a proposal for notification support in the drm_panel > > infrastructure (which is not that complicated), and here [2] is how > > I use it in my atmel-hlcdc driver to generate hotplug events. > > > > Let me know if you want me to submit a proper patch series... > > > > Best Regards, > > > > Boris > > > > [1]http://code.bulix.org/scq4g3-86804 > > [2]http://code.bulix.org/7dg501-86805 > > Those look interesting. Any chance you could look into how to do the > same without resorting to notifiers? A new version without notifiers usage: http://code.bulix.org/7urh8v-86806 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris BREZILLON Subject: Re: [PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller Date: Thu, 21 Aug 2014 16:32:32 +0200 Message-ID: <20140821163232.475c0ed8@bbrezillon> References: <1406034695-15534-1-git-send-email-boris.brezillon@free-electrons.com> <20140821081619.GZ2452@ldesroches-Latitude-E6320> <20140821103706.2349915d@bbrezillon> <20140821090406.GA13733@ulmo> <20140821114159.319e741b@bbrezillon> <20140821095202.GA21848@ulmo> <20140821150600.37788d82@bbrezillon> <20140821131552.GA19293@ulmo.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140821131552.GA19293@ulmo.nvidia.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Thierry Reding Cc: Mark Rutland , linux-pwm@vger.kernel.org, Samuel Ortiz , Pawel Moll , devicetree@vger.kernel.org, Lee Jones , Ian Campbell , Nicolas Ferre , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Rob Herring , Ludovic Desroches , Alexandre Belloni , Laurent Pinchart , Bo Shen , Kumar Gala , Jean-Christophe Plagniol-Villard , Andrew Victor , linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org On Thu, 21 Aug 2014 15:16:08 +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 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 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 wrote: > > > > > > > > > > > > > Hi Boris, > > > > > > > > > > > > > > You can add > > > > > > > > > > > > > > Tested-by: Ludovic Desroches > > > > > > > > > > > > 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? > > > > 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). > > > > Here [1] is a proposal for notification support in the drm_panel > > infrastructure (which is not that complicated), and here [2] is how > > I use it in my atmel-hlcdc driver to generate hotplug events. > > > > Let me know if you want me to submit a proper patch series... > > > > Best Regards, > > > > Boris > > > > [1]http://code.bulix.org/scq4g3-86804 > > [2]http://code.bulix.org/7dg501-86805 > > Those look interesting. Any chance you could look into how to do the > same without resorting to notifiers? A new version without notifiers usage: http://code.bulix.org/7urh8v-86806 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: boris.brezillon@free-electrons.com (Boris BREZILLON) Date: Thu, 21 Aug 2014 16:32:32 +0200 Subject: [PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller In-Reply-To: <20140821131552.GA19293@ulmo.nvidia.com> References: <1406034695-15534-1-git-send-email-boris.brezillon@free-electrons.com> <20140821081619.GZ2452@ldesroches-Latitude-E6320> <20140821103706.2349915d@bbrezillon> <20140821090406.GA13733@ulmo> <20140821114159.319e741b@bbrezillon> <20140821095202.GA21848@ulmo> <20140821150600.37788d82@bbrezillon> <20140821131552.GA19293@ulmo.nvidia.com> Message-ID: <20140821163232.475c0ed8@bbrezillon> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, 21 Aug 2014 15:16:08 +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 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 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 wrote: > > > > > > > > > > > > > Hi Boris, > > > > > > > > > > > > > > You can add > > > > > > > > > > > > > > Tested-by: Ludovic Desroches > > > > > > > > > > > > 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? > > > > 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). > > > > Here [1] is a proposal for notification support in the drm_panel > > infrastructure (which is not that complicated), and here [2] is how > > I use it in my atmel-hlcdc driver to generate hotplug events. > > > > Let me know if you want me to submit a proper patch series... > > > > Best Regards, > > > > Boris > > > > [1]http://code.bulix.org/scq4g3-86804 > > [2]http://code.bulix.org/7dg501-86805 > > Those look interesting. Any chance you could look into how to do the > same without resorting to notifiers? A new version without notifiers usage: http://code.bulix.org/7urh8v-86806 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com