linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Anatolij Gustschin <agust@denx.de>
Cc: linux-fbdev@vger.kernel.org, wd@denx.de, dzu@denx.de,
	jrigby@gmail.com,
	devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
	linuxppc-dev@ozlabs.org, yorksun@freescale.com
Subject: Re: [PATCH 1/3] video: add support for getting video mode from device tree
Date: Sat, 27 Feb 2010 23:30:33 -0700	[thread overview]
Message-ID: <fa686aa41002272230s7f900c0fv1aabf0e26ccbf84c@mail.gmail.com> (raw)
In-Reply-To: <1267307902-31939-2-git-send-email-agust@denx.de>

Hi Anatolij,

[added cc: to devicetree-discuss@lists.ozlabs.org]

On Sat, Feb 27, 2010 at 2:58 PM, Anatolij Gustschin <agust@denx.de> wrote:
> Framebuffer drivers may want to get panel timing info
> from the device tree. This patch adds appropriate support.
> Subsequent patch for FSL DIU frame buffer driver makes use
> of this functionality.

I think this is moving in the right direction, but there needs to
debate & review over the binding before committing to anything.
Please write a patch that documents the new binding in
Documentation/powerpc/dts-bindings.  All new bindings should be
documented and reviewed on devicetree-discuss before merging any
drivers that use them into mainline.

>From what I can tell by reading your code, I suspect that the binding
you've designed will solve your immediate problem, but won't be able
to handle anything slightly more complex, but it also looks like the
binding has been designed to be generic, usable by any display device.

First off, I did a tiny amount of research, and I didn't find any
existing OpenFirmware bindings for describing video displays.
Otherwise, I'd suggest considering that.

>From the little bit that I know, it seems that for most video devices
(ie. PCs) the video card discovers the capabilities of the screen by
reading the monitor's EDID data.  However, in your particular case
embedded case, a fixed flat panel is attached, and there isn't any
EDID data provided.  Therefore, you need an alternate method of
describing the display capabilities.  Rather than designing something
entirely new, you may want to consider using the EDID data format
directly; or at least cover the same things that EDID describes.  The
downside to using EDID directly is that it is a packed binary format
that isn't parseable by mere mortals; but the data contained in it
seems about right.  The upside is the kernel already knows what to do
with EDID data.

Otherwise you risk designing something that won't be useful for
anything much outside of your own use case.  For example, the binding
I see from the code cannot handle a display with multiple output
modes.

Also, since you're now in the realm of describing a video display,
which is separate from the display controller, you should consider
describing the display in a separate device tree node.  Maybe
something like this...

video {
        compatible =3D "fsl,mpc5121-diu";
        display {
                compatible =3D "<vendor>,<model>";
                edid =3D [edid-data];
        };
};

Cheers,
g.

>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> =A0drivers/video/Kconfig =A0| =A0 =A05 +++
> =A0drivers/video/Makefile | =A0 =A01 +
> =A0drivers/video/ofmode.c | =A0 95 ++++++++++++++++++++++++++++++++++++++=
++++++++++
> =A0drivers/video/ofmode.h | =A0 =A06 +++
> =A04 files changed, 107 insertions(+), 0 deletions(-)
> =A0create mode 100644 drivers/video/ofmode.c
> =A0create mode 100644 drivers/video/ofmode.h
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 5a5c303..dc1beb0 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -203,6 +203,11 @@ config FB_MACMODES
> =A0 =A0 =A0 =A0depends on FB
> =A0 =A0 =A0 =A0default n
>
> +config FB_OF_MODE
> + =A0 =A0 =A0 tristate
> + =A0 =A0 =A0 depends on FB && OF
> + =A0 =A0 =A0 default n
> +
> =A0config FB_BACKLIGHT
> =A0 =A0 =A0 =A0bool
> =A0 =A0 =A0 =A0depends on FB
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index 4ecb30c..c4a912b 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_FB_SVGALIB) =A0 =A0 =A0 +=3D svgalib.o
> =A0obj-$(CONFIG_FB_MACMODES) =A0 =A0 =A0+=3D macmodes.o
> =A0obj-$(CONFIG_FB_DDC) =A0 =A0 =A0 =A0 =A0 +=3D fb_ddc.o
> =A0obj-$(CONFIG_FB_DEFERRED_IO) =A0 +=3D fb_defio.o
> +obj-$(CONFIG_FB_OF_MODE) =A0 =A0 =A0 +=3D ofmode.o
>
> =A0# Hardware specific drivers go first
> =A0obj-$(CONFIG_FB_AMIGA) =A0 =A0 =A0 =A0 =A0 =A0+=3D amifb.o c2p_planar.=
o
> diff --git a/drivers/video/ofmode.c b/drivers/video/ofmode.c
> new file mode 100644
> index 0000000..78caad1
> --- /dev/null
> +++ b/drivers/video/ofmode.c
> @@ -0,0 +1,95 @@
> +/*
> + * Get video mode settings from Flattened Device Tree.
> + *
> + * Copyright (C) 2010 DENX Software Engineering.
> + * Anatolij Gustschin <agust@denx.de>
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License version 2. See the file COPYING in the main directory
> + * of this archive for more details.
> + */
> +
> +#include <linux/fb.h>
> +#include <linux/of.h>
> +
> +int __devinit of_get_video_mode(struct device_node *np,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct fb_i=
nfo *info)
> +{
> + =A0 =A0 =A0 struct fb_videomode dt_mode;
> + =A0 =A0 =A0 const u32 *prop;
> + =A0 =A0 =A0 unsigned int len;
> +
> + =A0 =A0 =A0 if (!np || !info)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "width", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 dt_mode.xres =3D *prop;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "height", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 dt_mode.yres =3D *prop;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "depth", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 info->var.bits_per_pixel =3D *prop;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "linebytes", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 info->fix.line_length =3D *prop;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "refresh", &len);
> + =A0 =A0 =A0 if (prop && len =3D=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dt_mode.refresh =3D *prop; /* optional */
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "pixclock", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 dt_mode.pixclock =3D *prop;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "left_margin", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 dt_mode.left_margin =3D *prop;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "right_margin", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 dt_mode.right_margin =3D *prop;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "upper_margin", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 dt_mode.upper_margin =3D *prop;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "lower_margin", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 dt_mode.lower_margin =3D *prop;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "hsync_len", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 dt_mode.hsync_len =3D *prop;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "vsync_len", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 dt_mode.vsync_len =3D *prop;
> +
> + =A0 =A0 =A0 prop =3D of_get_property(np, "sync", &len);
> + =A0 =A0 =A0 if (!prop || len !=3D sizeof(u32))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err;
> + =A0 =A0 =A0 dt_mode.sync =3D *prop;
> +
> + =A0 =A0 =A0 fb_videomode_to_var(&info->var, &dt_mode);
> +
> + =A0 =A0 =A0 return 0;
> +err:
> + =A0 =A0 =A0 pr_err("%s: Can't find expected mode entry\n", np->full_nam=
e);
> + =A0 =A0 =A0 return -EINVAL;
> +}
> diff --git a/drivers/video/ofmode.h b/drivers/video/ofmode.h
> new file mode 100644
> index 0000000..9a13bec
> --- /dev/null
> +++ b/drivers/video/ofmode.h
> @@ -0,0 +1,6 @@
> +#ifndef _OFMODE_H
> +#define _OFMODE_H
> +
> +extern int __devinit of_get_video_mode(struct device_node *np,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 struct fb_info *info);
> +#endif
> --
> 1.6.3.3
>
>



--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  reply	other threads:[~2010-02-28  6:30 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-05 13:42 [PATCH v3 00/11] Update support for MPC512x Anatolij Gustschin
2010-02-05 13:42 ` [PATCH v3 01/11] powerpc/mpc5121: avoid using arch_initcall for clock init Anatolij Gustschin
2010-02-05 13:42 ` [PATCH v3 02/11] powerpc/mpc5121: Add machine restart support Anatolij Gustschin
2010-02-09 23:24   ` Wolfram Sang
2010-02-15 16:38     ` Anatolij Gustschin
2010-02-10  2:32   ` Grant Likely
2010-02-15 16:51     ` [PATCH v4 " Anatolij Gustschin
2010-02-15 20:58       ` Wolfram Sang
2010-02-05 13:42 ` [PATCH v3 03/11] rtc: Add MPC5121 Real time clock driver Anatolij Gustschin
2010-02-10  2:39   ` Grant Likely
2010-02-10 18:25     ` [rtc-linux] " Alessandro Zummo
2010-02-05 13:42 ` [PATCH v3 04/11] mtd: Add MPC5121 NAND Flash Controller driver Anatolij Gustschin
2010-02-10  2:42   ` Grant Likely
2010-03-30 13:15     ` Artem Bityutskiy
2010-02-15 17:35   ` [PATCH v4 " Anatolij Gustschin
2010-02-16  8:11     ` Artem Bityutskiy
2010-02-23 15:54       ` Kári Davíðsson
2010-02-05 13:42 ` [PATCH v3 05/11] powerpc/mpc5121: create and register NFC device Anatolij Gustschin
2010-02-05 13:42 ` [PATCH v3 06/11] dma: Add MPC512x DMA driver Anatolij Gustschin
2010-02-10  2:44   ` Grant Likely
2010-03-01 13:46   ` Anatolij Gustschin
2010-03-02  6:00     ` Dan Williams
2010-02-05 13:42 ` [PATCH v3 07/11] powerpc/fsl_soc.c: prepare for addition of mpc5121 USB code Anatolij Gustschin
2010-02-05 13:42 ` [PATCH v3 08/11] powerpc/mpc5121: add USB host support Anatolij Gustschin
2010-02-05 13:42 ` [PATCH v3 09/11] powerpc/mpc5121: shared DIU framebuffer support Anatolij Gustschin
2010-02-16 18:06   ` Grant Likely
2010-02-18 16:15     ` York Sun
2010-02-27 21:58     ` [PATCH 0/3] Rework MPC5121 DIU support (for 2.6.34) Anatolij Gustschin
2010-02-28  7:04       ` Grant Likely
2010-02-27 21:58     ` [PATCH 1/3] video: add support for getting video mode from device tree Anatolij Gustschin
2010-02-28  6:30       ` Grant Likely [this message]
2010-02-28  8:44         ` Mitch Bradley
2010-02-28 14:47           ` Grant Likely
2010-03-01  3:45           ` Benjamin Herrenschmidt
2010-04-28 13:43             ` Anatolij Gustschin
2010-05-19 21:19               ` Grant Likely
2010-02-27 21:58     ` [PATCH 2/3] fbdev: fsl-diu-fb.c: allow setting panel video mode from DT Anatolij Gustschin
2010-02-28  6:52       ` Grant Likely
2010-02-27 21:58     ` [PATCH 3/3] powerpc/mpc5121: shared DIU framebuffer support Anatolij Gustschin
2010-02-28  6:50       ` Grant Likely
2010-04-28 20:28         ` Anatolij Gustschin
2010-02-27 22:09     ` [PATCH v3 09/11] " Anatolij Gustschin
2010-02-05 13:42 ` [PATCH v3 10/11] powerpc/mpc5121: update mpc5121ads DTS Anatolij Gustschin
2010-02-16 18:11   ` Grant Likely
2010-02-16 19:32     ` [PATCH] powerpc: mpc5121: correct DIU compatible property Anatolij Gustschin
2010-02-16 19:51       ` Grant Likely
2010-02-05 13:42 ` [PATCH v3 11/11] powerpc/mpc5121: Add default config for MPC5121 Anatolij Gustschin
2010-02-09  8:48 ` [PATCH v3 00/11] Update support for MPC512x Anatolij Gustschin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa686aa41002272230s7f900c0fv1aabf0e26ccbf84c@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=agust@denx.de \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=dzu@denx.de \
    --cc=jrigby@gmail.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=wd@denx.de \
    --cc=yorksun@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).