Re: fbcon on one of multiple displays
Hi Alex, On 12/4/23 07:40, Alex Deucher wrote: On Mon, Dec 4, 2023 at 8:52 AM Eric Nelson wrote: Thanks Javier, On 12/4/23 03:11, Javier Martinez Canillas wrote: Eric Nelson writes: Hello Eric, Hi all, Is there a way to configure a framebuffer console on a specific display on a machine with multiple displays? Have you looked at https://www.kernel.org/doc/Documentation/fb/fbcon.txt ? There is a sysfb interface to bind / unbind fbdev devices to fbcon's VT (/sys/class/vtconsole/vtcon1/bind) and also kernel command line parameter to choose which fbdev driver is mapped to which VT console (fbcon=map:n). I have seen this, but it's not clear how we can use this. In our case, we have a single driver for two displays. I hope to get a device on my desk this week to test it out. Are you referring to two devices that just both happen to use the same driver, or multiple displays driving by a single device? For the latter, drm drivers at least only expose a single "display" via the fbcon emulation. Alex A little of both. There are multiple displays through a single driver, but the fbcon emulation is only creating a single framebuffer device. What we're aiming for is pretty simple. We just want to get a splash screen (fb logo) to display on one of them and haven't found the right path.
Re: fbcon on one of multiple displays
Thanks Javier, On 12/4/23 03:11, Javier Martinez Canillas wrote: Eric Nelson writes: Hello Eric, Hi all, Is there a way to configure a framebuffer console on a specific display on a machine with multiple displays? Have you looked at https://www.kernel.org/doc/Documentation/fb/fbcon.txt ? There is a sysfb interface to bind / unbind fbdev devices to fbcon's VT (/sys/class/vtconsole/vtcon1/bind) and also kernel command line parameter to choose which fbdev driver is mapped to which VT console (fbcon=map:n). I have seen this, but it's not clear how we can use this. In our case, we have a single driver for two displays. I hope to get a device on my desk this week to test it out.
fbcon on one of multiple displays
Hi all, Is there a way to configure a framebuffer console on a specific display on a machine with multiple displays?
drm: imx: multi-display support questions
Thanks Fabio, On 06/29/2015 09:08 AM, Fabio Estevam wrote: > Hi Gary, > > On Mon, Jun 29, 2015 at 1:04 PM, Gary Bisson > wrote: > >> Thank you for your e-mail and sorry for the delay in my response. I >> confirm this patch, ported over to my dtsi file, makes the HDMI and >> LVDS work together. >> >> I'll check with Eric but we will most likely use the same >> configuration for our platforms. > > What do you mean by "use the same configuration for our platforms"? > > I was planning to send the two attached patches. > > Are you and Eric OK with them? > These look good to me. Gary, did you test one of these against either of our 1280x800 panels?
drm: imx: multi-display support questions
Hi Philipp, On 05/29/2015 02:30 AM, Philipp Zabel wrote: > Hi Eric, > > Am Donnerstag, den 28.05.2015, 12:30 -0700 schrieb Eric Nelson: >> Hi Philipp, >> >> On 05/28/2015 03:58 AM, Philipp Zabel wrote: >>> Hi Gary, >>> >>> Am Mittwoch, den 27.05.2015, 15:31 +0200 schrieb Gary Bisson: >>>>> According to the kerneldoc comment for drm_fb_helper_initial_config >>>>> (which is used by imx-drm via drm_fbdev_cma_init), it should set up a >>>>> single /dev/fb cloned over all connectors. This works here with LVDS and >>>>> HDMI. >>>> >>>> Does it require the two displays to have the exact same resolution? >>>> I'm wondering what is wrong with my setup but with a 1024x768 LVDS and >>>> a 1920x1080 HDMI display no image is shown on the HDMI (no signal). >>>> The CRTC settings show that both have the same origin (0,0) so I >>>> expected the LVDS to display a part of what the HDMI *should* display. >>> >>> No, but it does require the HDMI and LVDS display to use different clock >>> sources (unless LVDS serializer clock happens to be the same as the HDMI >>> pixel clock). >>> >>> I wonder what we should do about this for devices that have both LVDS >>> and HDMI output and can only use PLL5 for both. Register a clock >>> notifier that vetoes changes? >>> >> >> The LDB can be clocked from PLL2. >> >> Here's a snippet of the clock tree from our 3.10.53 (Android) kernel >> running both HDMI at 720P and the Hannstar hsd070pww1 panel: >> >>pll2_pfd0_352m 1 1500210526 > > What is the parent of gpu2d_core_sel? This looks like it would severely > overclock the vivante 2d core. > PLL3. Here's a full clock tree for a Nitrogen6x configured for 1280x800 LVDS and 720P HDMI. The GPU 2d core is running at 480MHz and the 3d core at 528MHz, so they're both under the limits of 532 and 540. Looking at the clock tree for 4.1, it appears that the gpu3d_core is being over-clocked at 594 MHz. Regards, Eric -- next part -- clockenable_cnt prepare_cnt rate - anaclk20 00 lvds2_in0 00 anaclk10 00 lvds1_in0 00 dummy 2 30 usbphy2_gate1 10 usbphy1_gate1 10 clk24m 0 02400 osc7 72400 cko2_sel1 12400 cko2_podf1 12400 cko2 1 12400 cko2 22400 gpt_3m 1 1300 pll4_sel0 02400 pll4_audio 0 01083801600 pll4_post_div 0 0541900800 pll4_audio_div 0 0541900800 esai_sel0 0541900800 esai_pred0 0270950400 esai_podf 0 033868800 esai_extal 0 033868800 ssi3_sel0 0541900800 ssi3_pred0 0135475200 ssi3_podf 0 067737600 ssi3 0 067737600 ssi2_sel0 0541900800 ssi2_pred0 0135475200 ssi2_podf 0 067737600 ssi2 0 067737600 ssi1_sel0 0541900800 ssi1_pred0 0135475200 ssi1_podf 0 067737600 ssi1 0 067737600 pll7_usb_host 1 148000 usbphy2 1 148000 pll6_enet 0 05000
drm: imx: multi-display support questions
Hi Philipp, On 05/28/2015 03:58 AM, Philipp Zabel wrote: > Hi Gary, > > Am Mittwoch, den 27.05.2015, 15:31 +0200 schrieb Gary Bisson: >>> According to the kerneldoc comment for drm_fb_helper_initial_config >>> (which is used by imx-drm via drm_fbdev_cma_init), it should set up a >>> single /dev/fb cloned over all connectors. This works here with LVDS and >>> HDMI. >> >> Does it require the two displays to have the exact same resolution? >> I'm wondering what is wrong with my setup but with a 1024x768 LVDS and >> a 1920x1080 HDMI display no image is shown on the HDMI (no signal). >> The CRTC settings show that both have the same origin (0,0) so I >> expected the LVDS to display a part of what the HDMI *should* display. > > No, but it does require the HDMI and LVDS display to use different clock > sources (unless LVDS serializer clock happens to be the same as the HDMI > pixel clock). > > I wonder what we should do about this for devices that have both LVDS > and HDMI output and can only use PLL5 for both. Register a clock > notifier that vetoes changes? > The LDB can be clocked from PLL2. Here's a snippet of the clock tree from our 3.10.53 (Android) kernel running both HDMI at 720P and the Hannstar hsd070pww1 panel: pll2_pfd0_352m 1 1500210526 ldb_di1_div_7 0 071458646 ldb_di1_div_sel0 071458646 ldb_di1 0 071458646 ldb_di1_div_3_5 0 0142917293 ldb_di0_div_7 1 171458646 ldb_di0_div_sel1 171458646 ldb_di0 1 171458646 ipu1_di1_sel 1 171458646 ipu1_di1 1 171458646 ipu1_pclk1_sel 1 171458646 ipu1_pclk1_div 1 1 71458646 ipu1_pclk_1 1 1 71458646 I believe that the Freescale kernels always clock the LVDS display bridge from PLL2 but perhaps not. I'll test a dual-channel (1080P) display and trace the code in this branch of our kernel tree: https://github.com/boundarydevices/linux-imx6/tree/boundary-imx-kk4.4.3_2.0.0-ga/ > [...] >>> For parallel and LVDS we'd either need to force the parallel panel to be >>> clocked by the IPU internal clock, or move one or the other external >>> clock source off of pll5_video. >> >> Do you have a preference for one solution over the other? > > That depends on the board. Is there an LVDS display that can be driven > by a PLL other than PLL5? Since there is no sane way to change the > LDB_DI parent in a running system, that should be configured in the > device tree. > That would certainly be best (to allow the use of the more accurate PLL5 in the normal case), but the PLL2 clock parent works well in the most common cases. Regards, Eric
[PATCH] drm/panel: Add display timing for HannStar HSD100PXN1
Add support for the Hannstar HSD100PXN1 to the DRM simple panel driver.
The HSD100PXN1 is an XGA (1024x768) panel with an 18-bit LVDS interface.
It supports pixel clocks in the range of 55-75 MHz.
This panel is offered for sale by Freescale as a companion part to its'
i.MX5x Quick Start board and i.MX6 SABRE platforms with under the name
MCIMX-LVDS1.
Signed-off-by: Eric Nelson
---
.../bindings/panel/hannstar,hsd100pxn1.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 26 ++
2 files changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/hannstar,hsd100pxn1.txt
diff --git a/Documentation/devicetree/bindings/panel/hannstar,hsd100pxn1.txt
b/Documentation/devicetree/bindings/panel/hannstar,hsd100pxn1.txt
new file mode 100644
index 000..8270319
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/hannstar,hsd100pxn1.txt
@@ -0,0 +1,7 @@
+HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel
+
+Required properties:
+- compatible: should be "hannstar,hsd100pxn1"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 30904a9..cc29ed3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -731,6 +731,29 @@ static const struct panel_desc hannstar_hsd070pww1 = {
},
};
+static const struct display_timing hannstar_hsd100pxn1_timing = {
+ .pixelclock = { 5500, 6500, 7500 },
+ .hactive = { 1024, 1024, 1024 },
+ .hfront_porch = { 40, 40, 40 },
+ .hback_porch = { 220, 220, 220 },
+ .hsync_len = { 20, 60, 100 },
+ .vactive = { 768, 768, 768 },
+ .vfront_porch = { 7, 7, 7 },
+ .vback_porch = { 21, 21, 21 },
+ .vsync_len = { 10, 10, 10 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc hannstar_hsd100pxn1 = {
+ .timings = &hannstar_hsd100pxn1_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 203,
+ .height = 152,
+ },
+};
+
static const struct drm_display_mode hitachi_tx23d38vm0caa_mode = {
.clock = 3,
.hdisplay = 800,
@@ -1038,6 +1061,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "hannstar,hsd070pww1",
.data = &hannstar_hsd070pww1,
}, {
+ .compatible = "hannstar,hsd100pxn1",
+ .data = &hannstar_hsd100pxn1,
+ }, {
.compatible = "hit,tx23d38vm0caa",
.data = &hitachi_tx23d38vm0caa
}, {
--
1.9.1
[PATCH RFC 27/46] imx-drm: convert to componentised device support
Hi Philipp, On 01/07/2014 04:29 AM, Philipp Zabel wrote: > Am Montag, den 06.01.2014, 19:31 -0700 schrieb Eric Nelson: >> Hi Russell, >> >> On 01/06/2014 10:46 AM, Russell King - ARM Linux wrote: >>> On Mon, Jan 06, 2014 at 06:41:28PM +0100, Philipp Zabel wrote: >>>> Hi Eric, >>>> >>>> Am Freitag, den 03.01.2014, 12:14 -0700 schrieb Eric Nelson: >>>>> This is an issue we've seen before. The SABRE Lite board has >>>>> a voltage divider on the HPD pins and some monitors (esp. DVI >>>>> monitors) either don't drive things high enough to assert HPD or >>>>> bounce with connect/disconnect. >>>> >>>> Yes, I used a DVI monitor. >>>> >>>>> We've instrumented our 3.0.35 kernels to use the RX_SENSE bits >>>>> instead. >>>> >>>> Reacting to RX_SENSE0 instead of HPD seems to work. >>> >>> However, it's non-compliant, because HPD can be lowered and raised by >>> the sink when it changes its EDID data (eg, because you're connected >>> through a switch and the routing has been changed.) >>> >>> So, reacting to RX_SENSE0 instead of HPD has to be a work-around enabled >>> only for those boards which are broken in this regard. >>> >> >> I understand. We'll need to carry some patches for a while though, >> since there are lots of these boards in the wild. > > Could you point me to your changes? Maybe this could be added to > mainline as a quirk enabled by a device tree property on sabrelite only. > We only have them for 3.0.35 at the moment. Here's the patch to use RXSENSE instead of HPD https://github.com/boundarydevices/linux-imx6/commit/c0439e262bb6c23887d96466b2ab7916aa0488d9 A follow-up patch disables the disconnect detection entirely unless requested: https://github.com/boundarydevices/linux-imx6/commit/d9cd79d11ff9f7a7f89cbc94b68757b67cdfe5fc Regards, Eric
[PATCH RFC 27/46] imx-drm: convert to componentised device support
Hi Russell, On 01/06/2014 10:46 AM, Russell King - ARM Linux wrote: > On Mon, Jan 06, 2014 at 06:41:28PM +0100, Philipp Zabel wrote: >> Hi Eric, >> >> Am Freitag, den 03.01.2014, 12:14 -0700 schrieb Eric Nelson: >>> This is an issue we've seen before. The SABRE Lite board has >>> a voltage divider on the HPD pins and some monitors (esp. DVI >>> monitors) either don't drive things high enough to assert HPD or >>> bounce with connect/disconnect. >> >> Yes, I used a DVI monitor. >> >>> We've instrumented our 3.0.35 kernels to use the RX_SENSE bits >>> instead. >> >> Reacting to RX_SENSE0 instead of HPD seems to work. > > However, it's non-compliant, because HPD can be lowered and raised by > the sink when it changes its EDID data (eg, because you're connected > through a switch and the routing has been changed.) > > So, reacting to RX_SENSE0 instead of HPD has to be a work-around enabled > only for those boards which are broken in this regard. > I understand. We'll need to carry some patches for a while though, since there are lots of these boards in the wild. Regards, Eric
[PATCH RFC 27/46] imx-drm: convert to componentised device support
Hi Philipp, On 01/03/2014 10:26 AM, Philipp Zabel wrote: > Am Freitag, den 03.01.2014, 17:07 + schrieb Russell King - ARM > Linux: >> On Fri, Jan 03, 2014 at 05:48:57PM +0100, Philipp Zabel wrote: >>> Hi Russell, >>> >>> I've tested this series on a BD-SL (SabreLite) with HDMI. Right now >>> the HPD signal doesn't seem to work, but after overwriting the >>> connection check, I got a stable and correct picture on the monitor: >> >> Hmm. Does this mean you're not getting any IRQs from the HDMI interface >> when you plug and unplug the monitor? >> >> 147:281 GIC 147 12.hdmi >> >> on turning the TV on: >> >> 147:282 GIC 147 12.hdmi >> >> on unplugging the HDMI cable: >> >> 147:283 GIC 147 12.hdmi >> >> on replugging the HDMI cable: >> >> 147:284 GIC 147 12.hdmi > > Exactly. And while the RX_SENSE bits of HDMI_IH_PHY_STAT0 change when I > (un)plug, the HPD bit stays zero. I'll check with other hardware. > This is an issue we've seen before. The SABRE Lite board has a voltage divider on the HPD pins and some monitors (esp. DVI monitors) either don't drive things high enough to assert HPD or bounce with connect/disconnect. We've instrumented our 3.0.35 kernels to use the RX_SENSE bits instead. Regards, Eric
Re: [PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support
On 09/22/2012 03:17 AM, Sascha Hauer wrote: Hi Eric, On Fri, Sep 21, 2012 at 09:24:19AM -0700, Eric Nelson wrote: Hi Sascha, But ipu_crtc->imx_crtc gets initialized in this call, and ipu_irq_handler() makes use of it. The U-Boot code doesn't enable interrupts, so it's not acking along the way, and leaves bits set in IPU1_INT_STAT_15. I found that I can get around this in U-Boot by disabling the LCD controller and acking all of the interrupts after disabling the controller, but I haven't yet figured out where to tap into cleanup_before_linux(). Passing over an enabled IPU from the bootloader to the kernel is (currently) not a supported usecase, so U-Boot should indeed disable it. That said, the kernel driver should make sure the IPU is sufficiently configured before the interrupts are enabled, so this seems to be a bug that deserves fixing. Thanks Sascha, Patches for U-Boot are in process. http://lists.denx.de/pipermail/u-boot/2012-September/134807.html Regards, Eric ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support
On 09/22/2012 03:17 AM, Sascha Hauer wrote: > Hi Eric, > > On Fri, Sep 21, 2012 at 09:24:19AM -0700, Eric Nelson wrote: >> Hi Sascha, >> >> >> But ipu_crtc->imx_crtc gets initialized in this call, and >> ipu_irq_handler() makes use of it. >> >> The U-Boot code doesn't enable interrupts, so it's not acking >> along the way, and leaves bits set in IPU1_INT_STAT_15. >> >> I found that I can get around this in U-Boot by disabling the >> LCD controller and acking all of the interrupts after disabling >> the controller, but I haven't yet figured out where to tap into >> cleanup_before_linux(). > > Passing over an enabled IPU from the bootloader to the kernel is > (currently) not a supported usecase, so U-Boot should indeed disable it. > That said, the kernel driver should make sure the IPU is sufficiently > configured before the interrupts are enabled, so this seems to be a bug > that deserves fixing. > Thanks Sascha, Patches for U-Boot are in process. http://lists.denx.de/pipermail/u-boot/2012-September/134807.html Regards, Eric
Re: [PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support
Hi Sascha,
While testing against a video-enabled U-Boot on i.MX6, I found the issue
below.
On 09/21/2012 01:07 AM, Sascha Hauer wrote:
This adds a i.MX51/53/6 IPU (Image Processing Unit) KMS driver. The
driver has been tested on the i.MX51 babbage board, the i.MX53 LOCO
board and the i.MX6q sabrelite board in different clone mode and dual
head setups.
Signed-off-by: Sascha Hauer
---
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -0,0 +1,579 @@
+/*
+ * i.MX IPUv3 Graphics driver
+ *
>
>
>
+static int ipu_get_resources(struct ipu_crtc *ipu_crtc,
+ struct ipu_client_platformdata *pdata)
+{
+
+ ipu_crtc->irq = ipu_idmac_channel_irq(ipu, ipu_crtc->ipu_ch,
+ IPU_IRQ_EOF);
Interrupts get enabled here
+ ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq, ipu_irq_handler, 0,
+ "imx_drm", ipu_crtc);
+ if (ret< 0) {
+ dev_err(ipu_crtc->dev, "irq request failed with %d.\n", ret);
+ goto err_out;
+ }
+
+
+static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
+ struct ipu_client_platformdata *pdata)
+{
+ int ret;
+
+ ret = ipu_get_resources(ipu_crtc, pdata);
+ if (ret) {
+ dev_err(ipu_crtc->dev, "getting resources failed with %d.\n",
+ ret);
+ return ret;
+ }
+
But ipu_crtc->imx_crtc gets initialized in this call, and
ipu_irq_handler() makes use of it.
The U-Boot code doesn't enable interrupts, so it's not acking
along the way, and leaves bits set in IPU1_INT_STAT_15.
I found that I can get around this in U-Boot by disabling the
LCD controller and acking all of the interrupts after disabling
the controller, but I haven't yet figured out where to tap into
cleanup_before_linux().
Regards,
Eric
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support
Hi Sascha,
While testing against a video-enabled U-Boot on i.MX6, I found the issue
below.
On 09/21/2012 01:07 AM, Sascha Hauer wrote:
> This adds a i.MX51/53/6 IPU (Image Processing Unit) KMS driver. The
> driver has been tested on the i.MX51 babbage board, the i.MX53 LOCO
> board and the i.MX6q sabrelite board in different clone mode and dual
> head setups.
>
> Signed-off-by: Sascha Hauer
> ---
> +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> @@ -0,0 +1,579 @@
> +/*
> + * i.MX IPUv3 Graphics driver
> + *
>
>
>
> +static int ipu_get_resources(struct ipu_crtc *ipu_crtc,
> + struct ipu_client_platformdata *pdata)
> +{
> +
> + ipu_crtc->irq = ipu_idmac_channel_irq(ipu, ipu_crtc->ipu_ch,
> + IPU_IRQ_EOF);
Interrupts get enabled here
> + ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq, ipu_irq_handler, 0,
> + "imx_drm", ipu_crtc);
> + if (ret< 0) {
> + dev_err(ipu_crtc->dev, "irq request failed with %d.\n", ret);
> + goto err_out;
> + }
> +
>
>
>
> +
> +static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
> + struct ipu_client_platformdata *pdata)
> +{
> + int ret;
> +
> + ret = ipu_get_resources(ipu_crtc, pdata);
> + if (ret) {
> + dev_err(ipu_crtc->dev, "getting resources failed with %d.\n",
> + ret);
> + return ret;
> + }
> +
But ipu_crtc->imx_crtc gets initialized in this call, and
ipu_irq_handler() makes use of it.
The U-Boot code doesn't enable interrupts, so it's not acking
along the way, and leaves bits set in IPU1_INT_STAT_15.
I found that I can get around this in U-Boot by disabling the
LCD controller and acking all of the interrupts after disabling
the controller, but I haven't yet figured out where to tap into
cleanup_before_linux().
Regards,
Eric
Re: [PATCH 5/6] staging: drm/imx: Add devicetree binding documentation
On 09/18/2012 11:52 PM, Sascha Hauer wrote:
On Tue, Sep 18, 2012 at 03:06:36PM -0700, Eric Nelson wrote:
Hi Sascha,
On 09/12/2012 03:31 AM, Sascha Hauer wrote:
From: Philipp Zabel
Signed-off-by: Philipp Zabel
Signed-off-by: Sascha Hauer
---
.../bindings/staging/imx-drm/fsl-imx-drm.txt | 41
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+
+example:
+
+display@di0 {
+ compatible = "fsl,imx-parallel-display";
+ edid = [edid-data];
+ crtc =<&ipu 0>;
+ interface-pix-fmt = "rgb24";
+};
Do you have a working sample of [edid-data] for a parallel/LVDS/HDMI
display or know a good way to produce one?
No, we are using the of videomode helper, see
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg18618.html
It is not included here to not add a dependency on it. We are trying to
mainline this separately.
Sascha
Thanks Sascha.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] staging: drm/imx: Add devicetree binding documentation
On 09/18/2012 11:52 PM, Sascha Hauer wrote:
> On Tue, Sep 18, 2012 at 03:06:36PM -0700, Eric Nelson wrote:
>> Hi Sascha,
>>
>> On 09/12/2012 03:31 AM, Sascha Hauer wrote:
>>> From: Philipp Zabel
>>>
>>> Signed-off-by: Philipp Zabel
>>> Signed-off-by: Sascha Hauer
>>> ---
>>> .../bindings/staging/imx-drm/fsl-imx-drm.txt | 41
>>>
>>> 1 file changed, 41 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
>>>
>>> +
>>> +example:
>>> +
>>> +display at di0 {
>>> + compatible = "fsl,imx-parallel-display";
>>> + edid = [edid-data];
>>> + crtc =<&ipu 0>;
>>> + interface-pix-fmt = "rgb24";
>>> +};
>>
>> Do you have a working sample of [edid-data] for a parallel/LVDS/HDMI
>> display or know a good way to produce one?
>
> No, we are using the of videomode helper, see
>
> http://www.mail-archive.com/devicetree-discuss at
> lists.ozlabs.org/msg18618.html
>
> It is not included here to not add a dependency on it. We are trying to
> mainline this separately.
>
> Sascha
>
Thanks Sascha.
Re: [PATCH 5/6] staging: drm/imx: Add devicetree binding documentation
Hi Sascha,
On 09/12/2012 03:31 AM, Sascha Hauer wrote:
From: Philipp Zabel
Signed-off-by: Philipp Zabel
Signed-off-by: Sascha Hauer
---
.../bindings/staging/imx-drm/fsl-imx-drm.txt | 41
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
new file mode 100644
index 000..07654f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -0,0 +1,41 @@
+Freescale i.MX IPUv3
+
+
+Required properties:
+- compatible: Should be "fsl,-ipu"
+- reg: should be register base and length as documented in the
+ datasheet
+- interrupts: Should contain sync interrupt and error interrupt,
+ in this order.
+- #crtc-cells: 1, See below
+
+example:
+
+ipu: ipu@1800 {
+ #crtc-cells =<1>;
+ compatible = "fsl,imx53-ipu";
+ reg =<0x1800 0x08000>;
+ interrupts =<11 10>;
+};
+
+Parallel display support
+
+
+Required properties:
+- compatible: Should be "fsl,imx-parallel-display"
+- crtc: the crtc this display is connected to, see below
+Optional properties:
+- interface_pix_fmt: How this display is connected to the
+ crtc. Currently supported types: "rgb24", "rgb565"
+- edid: verbatim EDID data block describing attached display.
+- ddc: phandle describing the i2c bus handling the display data
+ channel
+
+example:
+
+display@di0 {
+ compatible = "fsl,imx-parallel-display";
+ edid = [edid-data];
+ crtc =<&ipu 0>;
+ interface-pix-fmt = "rgb24";
+};
Do you have a working sample of [edid-data] for a parallel/LVDS/HDMI
display or know a good way to produce one?
Thanks in advance,
Eric
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] staging: drm/imx: Add devicetree binding documentation
Hi Sascha,
On 09/12/2012 03:31 AM, Sascha Hauer wrote:
> From: Philipp Zabel
>
> Signed-off-by: Philipp Zabel
> Signed-off-by: Sascha Hauer
> ---
> .../bindings/staging/imx-drm/fsl-imx-drm.txt | 41
>
> 1 file changed, 41 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
>
> diff --git
> a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
> b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
> new file mode 100644
> index 000..07654f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
> @@ -0,0 +1,41 @@
> +Freescale i.MX IPUv3
> +
> +
> +Required properties:
> +- compatible: Should be "fsl,-ipu"
> +- reg: should be register base and length as documented in the
> + datasheet
> +- interrupts: Should contain sync interrupt and error interrupt,
> + in this order.
> +- #crtc-cells: 1, See below
> +
> +example:
> +
> +ipu: ipu at 1800 {
> + #crtc-cells =<1>;
> + compatible = "fsl,imx53-ipu";
> + reg =<0x1800 0x08000>;
> + interrupts =<11 10>;
> +};
> +
> +Parallel display support
> +
> +
> +Required properties:
> +- compatible: Should be "fsl,imx-parallel-display"
> +- crtc: the crtc this display is connected to, see below
> +Optional properties:
> +- interface_pix_fmt: How this display is connected to the
> + crtc. Currently supported types: "rgb24", "rgb565"
> +- edid: verbatim EDID data block describing attached display.
> +- ddc: phandle describing the i2c bus handling the display data
> + channel
> +
> +example:
> +
> +display at di0 {
> + compatible = "fsl,imx-parallel-display";
> + edid = [edid-data];
> + crtc =<&ipu 0>;
> + interface-pix-fmt = "rgb24";
> +};
Do you have a working sample of [edid-data] for a parallel/LVDS/HDMI
display or know a good way to produce one?
Thanks in advance,
Eric
