From: Boris BREZILLON <boris.brezillon@free-electrons.com> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Thierry Reding <thierry.reding@gmail.com>, Ludovic Desroches <ludovic.desroches@atmel.com>, Nicolas Ferre <nicolas.ferre@atmel.com>, Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>, Alexandre Belloni <alexandre.belloni@free-electrons.com>, Andrew Victor <linux@maxim.org.za>, David Airlie <airlied@linux.ie>, dri-devel@lists.freedesktop.org, linux-pwm@vger.kernel.org, Samuel Ortiz <sameo@linux.intel.com>, Lee Jones <lee.jones@linaro.org>, Rob Clark <robdclark@gmail.com>, Mark Rutland <mark.rutland@arm.com>, devicetree@vger.kernel.org, Pawel Moll <pawel.moll@arm.com>, Ian Campbell <ijc+devicetree@hellion.org.uk>, linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>, Bo Shen <voice.shen@atmel.com>, Kumar Gala <galak@codeaurora.org>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller Date: Thu, 21 Aug 2014 19:26:33 +0200 [thread overview] Message-ID: <20140821192633.69f6b21b@bbrezillon> (raw) In-Reply-To: <2138720.5GSxsvjVxS@avalon> Hi Laurent, On Thu, 21 Aug 2014 19:08:53 +0200 Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: [...] > > >> > > >> 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 ? > > Given the move to multiplatform kernels we need to aim for as few modules > compiled in as possible. I'd say this includes HDMI encoders, panels and > display controllers. > > > > 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 :-). > > Do you create a new drm_encoder at runtime for the HDMI encoder when it > appears ? I thought the DRM core and API were not able to correctly cope with > that. I haven't started to work on the HDMI encoder yet, and ATM I only have a single connector (which is true from an HW POV), which is then bound to an LCD panel (the only type of remote endpoint I currently support). BTW, I wonder how my use case should be represented in the DRM subsystem. As I said, from an HW POV I only have one RGB (or whatever name you choose for it) connector. But on such kind of connectors you can connect several output devices (panels, encoders, ...). And in my case I have 2 devices on the same RGB connector: a panel and an RGB to HDMI converter. > > > > 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. > > Is there a way we could use the component framework for that ? I know that > partial notification isn't supported at the moment, but Russell agreed it was > a real use case that should be implemented at some point. I'll give it a try. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: boris.brezillon@free-electrons.com (Boris BREZILLON) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller Date: Thu, 21 Aug 2014 19:26:33 +0200 [thread overview] Message-ID: <20140821192633.69f6b21b@bbrezillon> (raw) In-Reply-To: <2138720.5GSxsvjVxS@avalon> Hi Laurent, On Thu, 21 Aug 2014 19:08:53 +0200 Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: [...] > > >> > > >> 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 ? > > Given the move to multiplatform kernels we need to aim for as few modules > compiled in as possible. I'd say this includes HDMI encoders, panels and > display controllers. > > > > 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 :-). > > Do you create a new drm_encoder at runtime for the HDMI encoder when it > appears ? I thought the DRM core and API were not able to correctly cope with > that. I haven't started to work on the HDMI encoder yet, and ATM I only have a single connector (which is true from an HW POV), which is then bound to an LCD panel (the only type of remote endpoint I currently support). BTW, I wonder how my use case should be represented in the DRM subsystem. As I said, from an HW POV I only have one RGB (or whatever name you choose for it) connector. But on such kind of connectors you can connect several output devices (panels, encoders, ...). And in my case I have 2 devices on the same RGB connector: a panel and an RGB to HDMI converter. > > > > 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. > > Is there a way we could use the component framework for that ? I know that > partial notification isn't supported at the moment, but Russell agreed it was > a real use case that should be implemented at some point. I'll give it a try. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
next prev parent reply other threads:[~2014-08-21 17:26 UTC|newest] Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-07-22 13:11 [PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` [PATCH v4 01/11] mfd: add atmel-hlcdc driver Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` [PATCH v4 02/11] mfd: add documentation for atmel-hlcdc DT bindings Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 14:32 ` Varka Bhadram 2014-07-22 14:32 ` Varka Bhadram 2014-07-22 13:11 ` [PATCH v4 03/11] pwm: add support for atmel-hlcdc-pwm device Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` [PATCH v4 04/11] pwm: add DT bindings documentation for atmel-hlcdc-pwm driver Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 14:36 ` Varka Bhadram 2014-07-22 14:36 ` Varka Bhadram 2014-07-22 13:11 ` [PATCH v4 05/11] drm: add Atmel HLCDC Display Controller support Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` [PATCH v4 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` [PATCH v4 07/11] ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode configs Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` [PATCH v4 08/11] ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` [PATCH v4 09/11] ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` [PATCH v4 10/11] ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` [PATCH v4 11/11] ARM: at91/dt: enable the LCD panel on sama5d3xek boards Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-07-22 13:11 ` Boris BREZILLON 2014-08-21 8:16 ` [PATCH v4 00/11] drm: add support for Atmel HLCDC Display Controller Ludovic Desroches 2014-08-21 8:16 ` Ludovic Desroches 2014-08-21 8:16 ` Ludovic Desroches 2014-08-21 8:37 ` Boris BREZILLON 2014-08-21 8:37 ` Boris BREZILLON 2014-08-21 8:37 ` Boris BREZILLON 2014-08-21 9:04 ` Thierry Reding 2014-08-21 9:04 ` Thierry Reding 2014-08-21 9:04 ` Thierry Reding 2014-08-21 9:41 ` Boris BREZILLON 2014-08-21 9:41 ` Boris BREZILLON 2014-08-21 9:41 ` Boris BREZILLON 2014-08-21 9:49 ` Boris BREZILLON 2014-08-21 9:49 ` Boris BREZILLON 2014-08-21 9:49 ` Boris BREZILLON 2014-08-21 9:52 ` Thierry Reding 2014-08-21 9:52 ` Thierry Reding 2014-08-21 9:52 ` Thierry Reding 2014-08-21 10:32 ` Andrzej Hajda 2014-08-21 10:32 ` Andrzej Hajda 2014-08-21 13:21 ` Thierry Reding 2014-08-21 13:21 ` Thierry Reding 2014-08-21 15:04 ` Andrzej Hajda 2014-08-21 15:04 ` Andrzej Hajda 2014-08-21 15:30 ` Boris BREZILLON 2014-08-21 15:30 ` Boris BREZILLON 2014-08-21 15:30 ` Boris BREZILLON 2014-08-21 16:10 ` Andrzej Hajda 2014-08-21 16:10 ` Andrzej Hajda 2014-08-21 16:10 ` Andrzej Hajda 2014-08-21 13:06 ` Boris BREZILLON 2014-08-21 13:06 ` Boris BREZILLON 2014-08-21 13:16 ` Thierry Reding 2014-08-21 13:16 ` Thierry Reding 2014-08-21 13:16 ` Thierry Reding 2014-08-21 13:30 ` Boris BREZILLON 2014-08-21 13:30 ` Boris BREZILLON 2014-08-21 14:32 ` Boris BREZILLON 2014-08-21 14:32 ` Boris BREZILLON 2014-08-21 14:32 ` Boris BREZILLON 2014-08-25 12:45 ` Daniel Vetter 2014-08-25 12:45 ` Daniel Vetter 2014-08-25 12:45 ` Daniel Vetter 2014-08-21 17:08 ` Laurent Pinchart 2014-08-21 17:08 ` Laurent Pinchart 2014-08-21 17:08 ` Laurent Pinchart 2014-08-21 17:26 ` Boris BREZILLON [this message] 2014-08-21 17:26 ` Boris BREZILLON 2014-08-25 23:39 ` Laurent Pinchart 2014-08-25 23:39 ` Laurent Pinchart 2014-08-27 7:52 ` Boris BREZILLON 2014-08-27 7:52 ` Boris BREZILLON 2014-08-28 12:19 ` Laurent Pinchart 2014-08-28 12:19 ` Laurent Pinchart 2014-08-28 12:19 ` Laurent Pinchart 2014-08-28 14:21 ` Boris BREZILLON 2014-08-28 14:21 ` Boris BREZILLON 2014-08-28 14:21 ` Boris BREZILLON 2014-08-28 22:52 ` Laurent Pinchart 2014-08-28 22:52 ` Laurent Pinchart 2014-08-21 10:16 ` Andrzej Hajda 2014-08-21 10:16 ` Andrzej Hajda 2014-08-21 10:16 ` Andrzej Hajda
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20140821192633.69f6b21b@bbrezillon \ --to=boris.brezillon@free-electrons.com \ --cc=airlied@linux.ie \ --cc=alexandre.belloni@free-electrons.com \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=galak@codeaurora.org \ --cc=ijc+devicetree@hellion.org.uk \ --cc=laurent.pinchart@ideasonboard.com \ --cc=lee.jones@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pwm@vger.kernel.org \ --cc=linux@maxim.org.za \ --cc=ludovic.desroches@atmel.com \ --cc=mark.rutland@arm.com \ --cc=nicolas.ferre@atmel.com \ --cc=pawel.moll@arm.com \ --cc=plagnioj@jcrosoft.com \ --cc=robdclark@gmail.com \ --cc=robh+dt@kernel.org \ --cc=sameo@linux.intel.com \ --cc=thierry.reding@gmail.com \ --cc=voice.shen@atmel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.