linux-kernel - Re: [PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140821114921.3a91eb1b@bbrezillon>
Date:	Thu, 21 Aug 2014 11:49:21 +0200
From:	Boris BREZILLON <boris.brezillon@...e-electrons.com>
To:	Boris BREZILLON <boris.brezillon@...e-electrons.com>
Cc:	Thierry Reding <thierry.reding@...il.com>,
	Ludovic Desroches <ludovic.desroches@...el.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Andrew Victor <linux@...im.org.za>,
	David Airlie <airlied@...ux.ie>,
	dri-devel@...ts.freedesktop.org, linux-pwm@...r.kernel.org,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Lee Jones <lee.jones@...aro.org>,
	Rob Clark <robdclark@...il.com>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Mark Rutland <mark.rutland@....com>,
	devicetree@...r.kernel.org, Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	linux-kernel@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
	Bo Shen <voice.shen@...el.com>,
	Kumar Gala <galak@...eaurora.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 00/11] drm: add support for Atmel HLCDC Display
 Controller

On Thu, 21 Aug 2014 11:41:59 +0200
Boris BREZILLON <boris.brezillon@...e-electrons.com> wrote:

> On Thu, 21 Aug 2014 11:04:07 +0200
> Thierry Reding <thierry.reding@...il.com> 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@...el.com> wrote:
> > > 
> > > > Hi Boris,
> > > > 
> > > > You can add
> > > > 
> > > > Tested-by: Ludovic Desroches <ludovic.desroches@...el.com>
> > > 
> > > 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.
> 
> > That
> > will still cause some delay before everything gets set up, but hopefully
> > less than what you're seeing now. There's also another thread where this
> > is being discussed because deferred probing is causing "unacceptable"
> > delays as well.
> 
> Could you point this thread out to me please ?

Sorry, I didn't check my emails before asking this :-).

> 
> 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/