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

[Laurent Pinchart]

Hi Boris,

On Thursday 28 August 2014 16:21:00 Boris BREZILLON wrote:
> On Thu, 28 Aug 2014 14:19:22 +0200 Laurent Pinchart wrote:
> > Hi Boris,
> 
> [...]
> 
> >> I don't have any VGA connector (or I'm missing something :-)),
> > 
> > My bad.
> 
> No problem.
> 
> >> but I have an LCD panel and an RGB to HDMI encoder connected on the same
> >> RGB connector.
> > 
> > There's no such thing as an RGB connector in DRM. Your SoC has a parallel
> > RGB video output (I assume it's a DPI bus). From a DRM point of view,
> > that bus corresponds to the output of the CRTC.
> 
> Okay, this mean I'll have to dispatch some of the code I've put in
> atmel_hlcdc_output.c into atmel_hlcdc_crtc.c (BTW, any chance you could
> take a look at this files ?).

Not in the very near future I'm afraid, I'm moving to a new flat in a couple 
of days, that will keep me pretty busy. If nobody has reviewed your patches in 
a week from now feel free to ping me.

> >>> As DRM hardcodes the pipeline model to CRTC -> encoder -> connector,
> >>> you will also need a DRM encoder in the VGA path. I suppose your board
> >>> has a VGA DAC, that's the component you should expose as a DRM encoder
> >>> (even if it can't be controlled and doesn't limit the valid modes).
> >> 
> >> Actually, my problem is that both devices are connected on the same RGB
> >> connector, and thus share the same display mode (resolution, HSYNC,
> >> VSYNC, RGB output mode, ...).
> >> This means that all remote devices have to agree on a specific mode if
> >> we want to mirror the display on several output devices, otherwise we
> >> must disable one of the output devices.
> > 
> > That's not really a problem. From a DRM perspective you need to model your
> > device as
> > 
> > ,--.   ,---.   ,-.
> > | CRTC | -+--> | Dummy Encoder | > | Panel Connector |
> > `--?  |`---?   `-?
> >   |,---.   ,-.
> >   \--> | HDMI Encoder  | > | HDMI Connector  |
> >`---?   `-?
> > 
> > The HDMI pipeline is pretty straightforward.
> > 
> > You have told me that the panel has a parallel RGB input without any
> > encoder in the panel pipeline (by the way, which panel model are you
> > using ?). However, DRM requires an encoder in every pipeline. You will
> > thus need to instantiate a dummy encoder. One option would be to set the
> > encoder and connector types to DRM_MODE_ENCODER_LVDS and
> > DRM_MODE_CONNECTOR_LVDS respectively, as that's what userspace usually
> > expects for panels. That doesn't reflect the reality in your case though,
> > so creating a new DRM_MODE_CONNECTOR_DPI type might be needed, possibly
> > to be used with DRM_MODE_ENCODER_NONE.
> > 
> > As neither encoder can modify the mode, the same mode will be output on
> > the two connectors.
> 
> There are still several things to I'd like to understand:
>  1) who's gonna configure the RGB bus output format (RGB444, RGB666,
> RGB888) which directly depends on the device connected on this bus:
> the CRTC or the dummy and HDMI encoders.

Your mileage my vary, but in general I believe this should be the 
responsibility of the CRTC driver (the HLCDC driver in your case), from 
information it gets from DT and/or queries dynamically from the encoders at 
runtime.

>  2) Where should the HDMI encoder/connector support be implemented:
> in drivers/gpu/drm/atmel-hlcdc, drivers/gpu/drm/bridge or somewhere
> else. My point is that I don't want to add specific support for the
> Sil902x transmitter chip in the hlcdc driver.

The HDMI encoder should definitely be handled by a standalone driver. We have 
two infrastructures for this at the moment, drm_bridge and drm_encoder_slave. 
I'd like to see them being merged. I need to implement support for an HDMI 
encoder as well, I'll see if I can give this a try.

> Sorry if these are silly questions, but I'm still trying to understand
> how my case should be modeled :-).

As I don't have straightforward answers I won't consider the questions as 
silly :-)

-- 
Regards,

Laurent Pinchart

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

[Boris BREZILLON]

Hi Laurent,

On Thu, 28 Aug 2014 14:19:22 +0200
Laurent Pinchart  wrote:

> Hi Boris,

[...]

> >
> > I don't have any VGA connector (or I'm missing something :-)),
> 
> My bad.

No problem.

> 
> > but I have an LCD panel and an RGB to HDMI encoder connected on the same RGB
> > connector.
> 
> There's no such thing as an RGB connector in DRM. Your SoC has a parallel RGB 
> video output (I assume it's a DPI bus). From a DRM point of view, that bus 
> corresponds to the output of the CRTC.

Okay, this mean I'll have to dispatch some of the code I've put in
atmel_hlcdc_output.c into atmel_hlcdc_crtc.c (BTW, any chance you could
take a look at this files ?).

> 
> > > As DRM hardcodes the pipeline model to CRTC -> encoder -> connector, you
> > > will also need a DRM encoder in the VGA path. I suppose your board has a
> > > VGA DAC, that's the component you should expose as a DRM encoder (even if
> > > it can't be controlled and doesn't limit the valid modes).
> > 
> > Actually, my problem is that both devices are connected on the same RGB
> > connector, and thus share the same display mode (resolution, HSYNC,
> > VSYNC, RGB output mode, ...).
> > This means that all remote devices have to agree on a specific mode if
> > we want to mirror the display on several output devices, otherwise we
> > must disable one of the output devices.
> 
> That's not really a problem. From a DRM perspective you need to model your 
> device as
> 
> ,--.   ,---.   ,-.
> | CRTC | -+--> | Dummy Encoder | > | Panel Connector |
> `--?  |`---?   `-?
>   |,---.   ,-.
>   \--> | HDMI Encoder  | > | HDMI Connector  |
>`---?   `-?
> 
> The HDMI pipeline is pretty straightforward.
> 
> You have told me that the panel has a parallel RGB input without any encoder 
> in the panel pipeline (by the way, which panel model are you using ?). 
> However, DRM requires an encoder in every pipeline. You will thus need to 
> instantiate a dummy encoder. One option would be to set the encoder and 
> connector types to DRM_MODE_ENCODER_LVDS and DRM_MODE_CONNECTOR_LVDS 
> respectively, as that's what userspace usually expects for panels. That 
> doesn't reflect the reality in your case though, so creating a new 
> DRM_MODE_CONNECTOR_DPI type might be needed, possibly to be used with 
> DRM_MODE_ENCODER_NONE.
> 
> As neither encoder can modify the mode, the same mode will be output on the 
> two connectors.

There are still several things to I'd like to understand:
 1) who's gonna configure the RGB bus output format (RGB444, RGB666,
RGB888) which directly depends on the device connected on this bus:
the CRTC or the dummy and HDMI encoders.
 2) Where should the HDMI encoder/connector support be implemented:
in drivers/gpu/drm/atmel-hlcdc, drivers/gpu/drm/bridge or somewhere
else. My point is that I don't want to add specific support for the
Sil902x transmitter chip in the hlcdc driver.

Sorry if these are silly questions, but I'm still trying to understand
how my case should be modeled :-).

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Laurent Pinchart]

Hi Boris,

On Wednesday 27 August 2014 09:52:35 Boris BREZILLON wrote:
> On Tue, 26 Aug 2014 01:39:21 +0200 Laurent Pinchart wrote:
> > On Thursday 21 August 2014 19:26:33 Boris BREZILLON wrote:
> >> On Thu, 21 Aug 2014 19:08:53 +0200
> >> Laurent Pinchart  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.
> > 
> > The DRM connector object was initially meant to model a physical user-
> > accessible connector on a board (VGA, DVI, HDMI, ...) and the properties
> > of the monitor plugged into it. It has then been (ab)used to represent
> > panels, as they're similar to monitors.
> > 
> > In your case the VGA and HDMI connectors should be modeled as DRM
> > connectors, the RGB to HDMI encoder as a DRM encoder, and the LCDC as a
> > DRM CRTC.
>
> I don't have any VGA connector (or I'm missing something :-)),

My bad.

> but I have an LCD panel and an RGB to HDMI encoder connected on the same RGB
> connector.

There's no such thing as an RGB connector in DRM. Your SoC has a parallel RGB 
video output (I assume it's a DPI bus). From a DRM point of view, that bus 
corresponds to the output of the CRTC.

> > As DRM hardcodes the pipeline model to CRTC -> encoder -> connector, you
> > will also need a DRM encoder in the VGA path. I suppose your board has a
> > VGA DAC, that's the component you should expose as a DRM encoder (even if
> > it can't be controlled and doesn't limit the valid modes).
> 
> Actually, my problem is that both devices are connected on the same RGB
> connector, and thus share the same display mode (resolution, HSYNC,
> VSYNC, RGB output mode, ...).
> This means that all remote devices have to agree on a specific mode if
> we want to mirror the display on several output devices, otherwise we
> must disable one of the output devices.

That's not really a problem. From a DRM perspective you need to model your 
device as

,--.   ,---.   ,-.
| CRTC | -+--> | Dummy Encoder | > | Panel Connector |
`--?  |`---?   `-?
  |,---.   ,-.
  \--> | HDMI Encoder  | > | HDMI Connector  |
   `---?   `-?

The HDMI pipeline is pretty straightforward.

You have told me that the panel has a parallel RGB input without any encoder 
in the panel pipeline (by the way, which panel model are you using ?). 
However, DRM requires an encoder in every pipeline. You will thus need to 
instantiate a dummy encoder. One option would be to set the encoder and 
connector types to DRM_MODE_ENCODER_LVDS and DRM_MODE_CONNECTOR_LVDS 
respectively, as that's what userspace usually expects for panels. That 
doesn't reflect the reality in your 

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

[Boris BREZILLON]

Hi Laurent,

On Tue, 26 Aug 2014 01:39:21 +0200
Laurent Pinchart  wrote:

> Hi Boris,
> 
> On Thursday 21 August 2014 19:26:33 Boris BREZILLON wrote:
> > On Thu, 21 Aug 2014 19:08:53 +0200
> > Laurent Pinchart  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.
> 
> The DRM connector object was initially meant to model a physical user-
> accessible connector on a board (VGA, DVI, HDMI, ...) and the properties of 
> the monitor plugged into it. It has then been (ab)used to represent panels, 
> as 
> they're similar to monitors.
> 
> In your case the VGA and HDMI connectors should be modeled as DRM connectors, 
> the RGB to HDMI encoder as a DRM encoder, and the LCDC as a DRM CRTC.

I don't have any VGA connector (or I'm missing something :-)), but I
have an LCD panel and an RGB to HDMI encoder connected on the same RGB
connector.

> 
> As DRM hardcodes the pipeline model to CRTC -> encoder -> connector, you will 
> also need a DRM encoder in the VGA path. I suppose your board has a VGA DAC, 
> that's the component you should expose as a DRM encoder (even if it can't be 
> controlled and doesn't limit the valid modes).

Actually, my problem is that both devices are connected on the same RGB
connector, and thus share the same display mode (resolution, HSYNC,
VSYNC, RGB output mode, ...).
This means that all remote devices have to agree on a specific mode if
we want to mirror the display on several output devices, otherwise we
must disable one of the output devices.

> 
> > >>> 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.
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Laurent Pinchart]

Hi Boris,

On Thursday 21 August 2014 19:26:33 Boris BREZILLON wrote:
> On Thu, 21 Aug 2014 19:08:53 +0200
> Laurent Pinchart  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.

The DRM connector object was initially meant to model a physical user-
accessible connector on a board (VGA, DVI, HDMI, ...) and the properties of 
the monitor plugged into it. It has then been (ab)used to represent panels, as 
they're similar to monitors.

In your case the VGA and HDMI connectors should be modeled as DRM connectors, 
the RGB to HDMI encoder as a DRM encoder, and the LCDC as a DRM CRTC.

As DRM hardcodes the pipeline model to CRTC -> encoder -> connector, you will 
also need a DRM encoder in the VGA path. I suppose your board has a VGA DAC, 
that's the component you should expose as a DRM encoder (even if it can't be 
controlled and doesn't limit the valid modes).

> >>> 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.

-- 
Regards,

Laurent Pinchart

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

[Daniel Vetter]

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  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?

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

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

[Boris BREZILLON]

Hi Laurent,

On Thu, 21 Aug 2014 19:08:53 +0200
Laurent Pinchart  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

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

[Laurent Pinchart]

Hi Boris,

On Thursday 21 August 2014 15:06:00 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:
>  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 ?

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.

> > 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.

> 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

-- 
Regards,

Laurent Pinchart

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

[Andrzej Hajda]

On 08/21/2014 05:30 PM, Boris BREZILLON wrote:
> On Thu, 21 Aug 2014 17:04:34 +0200
> Andrzej Hajda  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  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.
>
> 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 

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

[Boris BREZILLON]

On Thu, 21 Aug 2014 17:04:34 +0200
Andrzej Hajda  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  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.
> >>>
> >>> 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 

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

[Andrzej Hajda]

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  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.
>>>
>>> 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

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

[Boris BREZILLON]

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 

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

[Boris BREZILLON]

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?

I take the first valid one :D (which indeed is not really reliable when
you have several output devices). I guess marking one output as the
primary output in the DT is not an acceptable solution either because
it describes a configuration rather than an HW capability.

Still opened to any suggestions regarding this issue ;-).

> 
> > > 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 

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

[Thierry Reding]

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  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.
> > 
> > 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.

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.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

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

[Thierry Reding]

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?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

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

[Boris BREZILLON]

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 :-).

> 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

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Andrzej Hajda]

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  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.
> 
> 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.

Regards
Andrzej

> 
>>> 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 ?
> 
> I Cc'ed you on it.
> 
> Thierry
> 
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

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

[Andrzej Hajda]

On 08/21/2014 11:41 AM, 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.

I agree that deferring whole drm initialization due to panel not being
ready is not an optimal solution. Nice solution of this problem is with
DSI panels, DSI bus infrastructure provides callbacks for DRM encoder
which are called when DSI panel is ready. Simple panels are platform
devices so they do not have such callbacks. To solve this in a generic
way I have proposed framework for tracking interfaces[1], the series
contains also solution for the same problem with exynos display
controller[2].

Regards
Andrzej

[1]: https://lkml.org/lkml/2014/4/30/345
[2]: https://lkml.org/lkml/2014/4/30/653

> 
>> 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 ?
> 
> Best Regards,
> 
> Boris
> 

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

[Thierry Reding]

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.

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).

> > 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 ?

I Cc'ed you on it.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

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

[Boris BREZILLON]

On Thu, 21 Aug 2014 11:41:59 +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.
> 
> > 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

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

[Boris BREZILLON]

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.

> 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 ?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Thierry Reding]

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. 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.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 

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

[Boris BREZILLON]

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...

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Ludovic Desroches]

Hi Boris,

You can add

Tested-by: Ludovic Desroches 

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.

Regards

Ludovic

On Tue, Jul 22, 2014 at 03:11:24PM +0200, Boris BREZILLON wrote:
> Hello,
> 
> This patch series adds support for Atmel HLCDC (HLCD Controller) available
> on some Atmel SoCs (i.e. the sama5d3 family).
> 
> The HLCDC actually provides a Display Controller and a PWM device, hence I
> decided to declare an MFD device exposing 2 subdevices: a display
> controller and a PWM chip.
> This also solves a circular dependency issue preventing HLCDC driver from
> unloading.
> The HLCDC request a drm_panel device, which request a backlight device
> (a PWM backlight), which depends on a PWM which is provided by the HLCDC
> driver (hlcdc -> panel -> backlight -> hlcdc (pwm part)).
> 
> The current implementation only supports sama5d3 SoCs but other SoCs should
> be easily ported by defining new compatible strings and adding HLCDC
> description structures for these SoCs.
> 
> The drivers supports basic CRTC functionalities, several overlays and an
> hardware cursor.
> 
> At the moment, it only supports connection to LCD panels through an RGB
> connector (defined as an LVDS connector in my implementation), though
> connection to other kind of devices (like DRM bridges) could be added later.
> 
> It also supports several RGB formats on all planes and some YUV formats on
> the HEO overlay plane.
> 
> This series depends on 2 other series currently under review: [1] and [2].
> 
> Best Regards,
> 
> Boris
> 
> [1]http://lkml.iu.edu/hypermail/linux/kernel/1407.1/04171.html
> [2]http://www.spinics.net/lists/kernel/msg1791681.html
> 
> Changes since v3:
> - rework the layer code to simplify several parts (locking and layer
>   disabling)
> - make use of the drm_flip_work infrastructure
> - rely on default HW cursor implementation using on the cursor plane
> - rework the display controller DT bindings (based on OF graph
>   representation)
> - add rotation support
> - retrive RGB bus format from drm_display_info
> - drop the dynamic pinctrl state selection
> - rework HLCDC output handling (previously specialized to interface
>   with LCD panels)
> - drop ".module = THIS_MODULE" lines
> - change display controller compatible string
> 
> Changes since v2:
> - fix coding style issues (macro indentation)
> - make use of GENMASK in several places
> - declare regmap config as a static structure
> - rework hlcdc plane update API
> - rework cursor handling to make use of the new plane update API
> - fix backporch config
> - do not use devm_regmap_init_mmio_clk to avoid extra clk_enable
>   clk disable calls when accessing registers
> - explicitely include regmap and clk headers instead of relying on
>   atmel-hlcdc.h inclusions
> - make the atmel-hlcdc driver depends on CONFIG_OF
> - separate DT bindings documentation from driver implementation
> - support several pin muxing for HLCDC pins on sama5d3 SoCs
> 
> Changes since v1:
> - replace the backlight driver by a PWM driver
> - make use of drm_panel infrastructure
> - split driver code in several subsystem: MFD, PWM and DRM
> - add support for overlays
> - add support for hardware cursor
> 
> 
> Boris BREZILLON (11):
>   mfd: add atmel-hlcdc driver
>   mfd: add documentation for atmel-hlcdc DT bindings
>   pwm: add support for atmel-hlcdc-pwm device
>   pwm: add DT bindings documentation for atmel-hlcdc-pwm driver
>   drm: add Atmel HLCDC Display Controller support
>   drm: add DT bindings documentation for atmel-hlcdc-dc driver
>   ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode
> configs
>   ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins
>   ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs
>   ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi
>   ARM: at91/dt: enable the LCD panel on sama5d3xek boards
> 
>  .../devicetree/bindings/drm/atmel-hlcdc-dc.txt |  54 ++
>  .../devicetree/bindings/mfd/atmel-hlcdc.txt|  50 ++
>  .../devicetree/bindings/pwm/atmel-hlcdc-pwm.txt|  55 ++
>  arch/arm/boot/dts/sama5d31ek.dts   |  20 +
>  arch/arm/boot/dts/sama5d33ek.dts   |  20 +
>  arch/arm/boot/dts/sama5d34ek.dts   |  20 +
>  arch/arm/boot/dts/sama5d36ek.dts   |  20 +
>  arch/arm/boot/dts/sama5d3_lcd.dtsi | 205 +-
>  arch/arm/boot/dts/sama5d3xdm.dtsi  |  58 ++
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/atmel-hlcdc/Kconfig|  11 +
>  drivers/gpu/drm/atmel-hlcdc/Makefile   |   7 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 286 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 488 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   | 224 ++
>  

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

[Boris BREZILLON]

Hello,

This patch series adds support for Atmel HLCDC (HLCD Controller) available
on some Atmel SoCs (i.e. the sama5d3 family).

The HLCDC actually provides a Display Controller and a PWM device, hence I
decided to declare an MFD device exposing 2 subdevices: a display
controller and a PWM chip.
This also solves a circular dependency issue preventing HLCDC driver from
unloading.
The HLCDC request a drm_panel device, which request a backlight device
(a PWM backlight), which depends on a PWM which is provided by the HLCDC
driver (hlcdc -> panel -> backlight -> hlcdc (pwm part)).

The current implementation only supports sama5d3 SoCs but other SoCs should
be easily ported by defining new compatible strings and adding HLCDC
description structures for these SoCs.

The drivers supports basic CRTC functionalities, several overlays and an
hardware cursor.

At the moment, it only supports connection to LCD panels through an RGB
connector (defined as an LVDS connector in my implementation), though
connection to other kind of devices (like DRM bridges) could be added later.

It also supports several RGB formats on all planes and some YUV formats on
the HEO overlay plane.

This series depends on 2 other series currently under review: [1] and [2].

Best Regards,

Boris

[1]http://lkml.iu.edu/hypermail/linux/kernel/1407.1/04171.html
[2]http://www.spinics.net/lists/kernel/msg1791681.html

Changes since v3:
- rework the layer code to simplify several parts (locking and layer
  disabling)
- make use of the drm_flip_work infrastructure
- rely on default HW cursor implementation using on the cursor plane
- rework the display controller DT bindings (based on OF graph
  representation)
- add rotation support
- retrive RGB bus format from drm_display_info
- drop the dynamic pinctrl state selection
- rework HLCDC output handling (previously specialized to interface
  with LCD panels)
- drop ".module = THIS_MODULE" lines
- change display controller compatible string

Changes since v2:
- fix coding style issues (macro indentation)
- make use of GENMASK in several places
- declare regmap config as a static structure
- rework hlcdc plane update API
- rework cursor handling to make use of the new plane update API
- fix backporch config
- do not use devm_regmap_init_mmio_clk to avoid extra clk_enable
  clk disable calls when accessing registers
- explicitely include regmap and clk headers instead of relying on
  atmel-hlcdc.h inclusions
- make the atmel-hlcdc driver depends on CONFIG_OF
- separate DT bindings documentation from driver implementation
- support several pin muxing for HLCDC pins on sama5d3 SoCs

Changes since v1:
- replace the backlight driver by a PWM driver
- make use of drm_panel infrastructure
- split driver code in several subsystem: MFD, PWM and DRM
- add support for overlays
- add support for hardware cursor


Boris BREZILLON (11):
  mfd: add atmel-hlcdc driver
  mfd: add documentation for atmel-hlcdc DT bindings
  pwm: add support for atmel-hlcdc-pwm device
  pwm: add DT bindings documentation for atmel-hlcdc-pwm driver
  drm: add Atmel HLCDC Display Controller support
  drm: add DT bindings documentation for atmel-hlcdc-dc driver
  ARM: AT91/dt: split sama5d3 lcd pin definitions to match RGB mode
configs
  ARM: AT91/dt: add alternative pin muxing for sama5d3 lcd pins
  ARM: at91/dt: define the HLCDC node available on sama5d3 SoCs
  ARM: at91/dt: add LCD panel description to sama5d3xdm.dtsi
  ARM: at91/dt: enable the LCD panel on sama5d3xek boards

 .../devicetree/bindings/drm/atmel-hlcdc-dc.txt |  54 ++
 .../devicetree/bindings/mfd/atmel-hlcdc.txt|  50 ++
 .../devicetree/bindings/pwm/atmel-hlcdc-pwm.txt|  55 ++
 arch/arm/boot/dts/sama5d31ek.dts   |  20 +
 arch/arm/boot/dts/sama5d33ek.dts   |  20 +
 arch/arm/boot/dts/sama5d34ek.dts   |  20 +
 arch/arm/boot/dts/sama5d36ek.dts   |  20 +
 arch/arm/boot/dts/sama5d3_lcd.dtsi | 205 +-
 arch/arm/boot/dts/sama5d3xdm.dtsi  |  58 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/atmel-hlcdc/Kconfig|  11 +
 drivers/gpu/drm/atmel-hlcdc/Makefile   |   7 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 286 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 488 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   | 224 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c| 635 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h| 396 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c   | 478 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c| 804 +
 drivers/mfd/Kconfig|  12 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/atmel-hlcdc.c  | 118 +++