* RE: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Hiremath, Vaibhav @ 2014-01-09 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52CE5123.9050702@gmail.com>
> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Ivaylo Dimitrov
> Sent: Thursday, January 09, 2014 1:05 PM
> To: Hiremath, Vaibhav; Valkeinen, Tomi; Tony Lindgren; Ivaylo Dimitrov
> Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> fbdev@vger.kernel.org
> Subject: Re: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
>
>
> On 09.01.2014 07:06, Hiremath, Vaibhav wrote:
> > Tomi,
> >
> > I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> > Did you see this on OMAP?
> >
> > I am using "omapfb_vram\x10M@0xA0000000", and I believe it is correct way
> of usage.
> >
> > Thanks,
> > Vaibhav
> >
>
> AFAIK underflow interrupts could come from badly calculated DSS core clock or
> bad HW resizer setup and should be unrelated to the memory allocation. It
> might be something similar to the problem I have on N900
> - see https://lkml.org/lkml/2014/1/6/173
>
I can see the difference when I really "omapfb_vram" command line argument.
Without omapfb_vram in bootargs
-------------------------------------------
bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem\x128M
consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb.debug=y omapdss.debug=y
I do not get UNDERFLOW during boot.
With omapfb_vram in the bootargs
---------------------------------------------
bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait mem\x128M
consoleblank=0 clocksource=gp_timer consoleblank=0 earlyprintk omapfb_vram\x10M@0xA0000000
omapfb.debug=y omapdss.debug=y
I always get UNDERFLOW during boot itself.
> Is it possible to upload the video you have problems with, so me to test it on
> N900? So far I didn't see any underflow issues on it (N900 is OMAP3, in case
> you're not aware), no matter the resolution of the videos I played(up to 720p),
> however I didn't test the part that allocates the memory on a pre-defined
> address. Though I don't think that should matter.
No, that's what is causing issue to me. Can you try predefined address flow?
Just to highlight, I get UNDERFLOW during boot itself, immediately when it gets mapped to userspace.
Boot LOG:
[ 1.443021] OMAPFB: omapfb_probe
[ 1.446137] OMAPFB: create 3 framebuffers
[ 1.446178] OMAPFB: fb_infos allocated
[ 1.446198] OMAPFB: allocating 1536000 bytes for fb 0
[ 1.451044] OMAPFB: allocated VRAM paddr a0000000, vaddr ca000000
[ 1.451069] OMAPFB: region0 phys a0000000 virt ca000000 size\x1536000
[ 1.451086] OMAPFB: region1 phys 00000000 virt (null) size=0
[ 1.451100] OMAPFB: region2 phys 00000000 virt (null) size=0
[ 1.451109] OMAPFB: fbmems allocated
[ 1.451363] OMAPFB: check_fb_var 0
[ 1.451386] OMAPFB: max frame size 1536000, line size 3200
[ 1.451401] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480
[ 1.451414] OMAPFB: set_fb_fix
[ 1.460278] OMAPFB: fb_infos initialized
[ 1.465325] OMAPFB: set_par(0)
[ 1.465384] OMAPFB: set_fb_fix
[ 1.465393] OMAPFB: apply_changes, fb 0, ovl 0
[ 1.465443] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[ 1.465450] OMAPFB: paddr a0000000
[ 1.465592] OMAPFB: pan_display(0)
[ 1.465600] OMAPFB: setcmap
[ 1.465607] OMAPFB: setcmap
[ 1.474504] Console: switching to colour frame buffer device 100x30
[ 1.474528] OMAPFB: pan_display(0)
[ 1.474534] OMAPFB: setcmap
[ 1.482185] OMAPFB: setcmap
[ 1.484808] OMAPFB: framebuffers registered
[ 1.484839] OMAPFB: apply_changes, fb 0, ovl 0
[ 1.484857] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[ 1.484870] OMAPFB: paddr a0000000
[ 1.484919] OMAPFB: apply_changes, fb 1, ovl 1
[ 1.485010] OMAPFB: apply_changes, fb 2, ovl 2
[ 1.485111] OMAPFB: create_framebuffers done
[ 1.485128] OMAPFB: mgr->apply'ed
[ 1.489793] OMAPFB: create sysfs for fbs
[ 1.489816] OMAPFB: create sysfs for fbs
....
[ 4.822549] Freeing unused kernel memory: 440K (c0919000 - c0987000)
[ 5.276615] OMAPFB: pan_display(0)
[ 5.276625] OMAPFB: setcmap
[ 5.276635] OMAPFB: setcmap
[ 5.293518] OMAPFB: user mmap region start a0000000, len 1536000, off 0
[ 5.300171] omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
...
[ 20.499076] OMAPFB: pan_display(0)
[ 20.499085] OMAPFB: setcmap
[ 20.499093] OMAPFB: setcmap
[ 20.544419] OMAPFB: check_var(0)
[ 20.544631] OMAPFB: check_fb_var 0
[ 20.544644] OMAPFB: max frame size 1536000, line size 3200
[ 20.544651] OMAPFB: xres = 800, yres = 480, vxres = 800, vyres = 480
[ 20.544699] OMAPFB: set_par(0)
[ 20.544706] OMAPFB: set_fb_fix
[ 20.544712] OMAPFB: apply_changes, fb 0, ovl 0
[ 20.544762] OMAPFB: setup_overlay 0, posx 0, posy 0, outw 800, outh 480
[ 20.544767] OMAPFB: paddr a0000000
[ 20.544798] OMAPFB: pan_display(0)
[ 20.544802] OMAPFB: setcmap
[ 20.544859] OMAPFB: pan_display(0)
[ 20.544865] OMAPFB: setcmap
[ 20.544872] OMAPFB: setcmap
[ 20.553841] OMAPFB: setcmap
[ 23.002160] OMAPFB: user mmap region start a0000000, len 1536000, off 0
Thanks,
Vaibhav
^ permalink raw reply
* Re: [PATCH] video: mmp: add device tree support
From: Jingoo Han @ 2014-01-09 7:43 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389244394-10779-1-git-send-email-zzhu3@marvell.com>
On Thursday, January 09, 2014 4:32 PM, Sascha Hauer wrote:
> On Thu, Jan 09, 2014 at 01:13:14PM +0800, Zhou Zhu wrote:
> > add device tree support for mmp fb/controller
> > the description at Documentation/devicetree/bindings/fb/mmp-disp.txt
> >
> > Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
> > ---
> > Documentation/devicetree/bindings/fb/mmp-disp.txt | 71 ++++++++++++
> > drivers/video/mmp/fb/mmpfb.c | 71 ++++++++----
> > drivers/video/mmp/hw/mmp_ctrl.c | 120 ++++++++++++++++-----
> > 3 files changed, 217 insertions(+), 45 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/fb/mmp-disp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/fb/mmp-disp.txt
> b/Documentation/devicetree/bindings/fb/mmp-disp.txt
> > new file mode 100644
> > index 0000000..3cf2903
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fb/mmp-disp.txt
[.....]
>
> > +#ifdef CONFIG_OF
> > + struct device_node *np;
> > +#else
> > struct mmp_buffer_driver_mach_info *mi;
> > +#endif
> > struct fb_info *info = 0;
> > struct mmpfb_info *fbi = 0;
> > - int ret, modes_num;
> > -
> > - mi = pdev->dev.platform_data;
> > - if (mi = NULL) {
> > - dev_err(&pdev->dev, "no platform data defined\n");
> > - return -EINVAL;
> > - }
> > + int ret = -EINVAL, modes_num;
> > + int overlay_id, dmafetch_id;
> > + const char *path_name;
> >
> > /* initialize fb */
> > info = framebuffer_alloc(sizeof(struct mmpfb_info), &pdev->dev);
> > if (info = NULL)
> > return -ENOMEM;
> > fbi = info->par;
> > - if (!fbi) {
> > - ret = -EINVAL;
> > + if (!fbi)
> > + goto failed;
> > +
> > +#ifdef CONFIG_OF
>
> Just because your kernel build does have CONFIG_OF enabled doesn't mean
> it's actually started with a devicetree. You need to make a runtime
> decision, not compile time.
Yes, right.
As Sascha Hauer said, you need to make a runtime decision,
instead of compile time. Please keep the same binary for
both cases (CONFIG_OF is 'enabled' and 'disabled').
For example,
if (pdev->dev.of_node) {
// DT code
} else {
// Non-DT code
}
Best regards,
Jingoo Han
^ permalink raw reply
* Re: RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Ivaylo Dimitrov @ 2014-01-09 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EDB11F5@DBDE04.ent.ti.com>
On 09.01.2014 07:06, Hiremath, Vaibhav wrote:
> Tomi,
>
> I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
> Did you see this on OMAP?
>
> I am using "omapfb_vram\x10M@0xA0000000", and I believe it is correct way of usage.
>
> Thanks,
> Vaibhav
>
AFAIK underflow interrupts could come from badly calculated DSS core
clock or bad HW resizer setup and should be unrelated to the memory
allocation. It might be something similar to the problem I have on N900
- see https://lkml.org/lkml/2014/1/6/173
Is it possible to upload the video you have problems with, so me to test
it on N900? So far I didn't see any underflow issues on it (N900 is
OMAP3, in case you're not aware), no matter the resolution of the videos
I played(up to 720p), however I didn't test the part that allocates the
memory on a pre-defined address. Though I don't think that should matter.
Ivo
^ permalink raw reply
* Re: [PATCH] video: mmp: add device tree support
From: Sascha Hauer @ 2014-01-09 7:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389244394-10779-1-git-send-email-zzhu3@marvell.com>
On Thu, Jan 09, 2014 at 01:13:14PM +0800, Zhou Zhu wrote:
> add device tree support for mmp fb/controller
> the description at Documentation/devicetree/bindings/fb/mmp-disp.txt
>
> Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
> ---
> Documentation/devicetree/bindings/fb/mmp-disp.txt | 71 ++++++++++++
> drivers/video/mmp/fb/mmpfb.c | 71 ++++++++----
> drivers/video/mmp/hw/mmp_ctrl.c | 120 ++++++++++++++++-----
> 3 files changed, 217 insertions(+), 45 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/fb/mmp-disp.txt
>
> diff --git a/Documentation/devicetree/bindings/fb/mmp-disp.txt b/Documentation/devicetree/bindings/fb/mmp-disp.txt
> new file mode 100644
> index 0000000..3cf2903
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fb/mmp-disp.txt
> @@ -0,0 +1,71 @@
> +* Marvell MMP Display (MMP_DISP)
> +
> +To config mmp display, 3 parts are required to be set in dts:
> +1. mmp fb
> +Required properties:
> +- compatible: Should be "marvell,mmp-fb".
> +- marvell,fb-name: Should be the name of this fb.
> +- marvell,path-name: Should be the name of path this fb connecting to.
> +- marvell,overlay-id: Should be the id of overlay this fb is on.
> +- marvell,dmafetch-id: Should be the dma fetch id this fb using.
> +- marvell,default-pixfmt: Should be the default pixel format when this fb is
> +turned on.
> +
> +2. mmp controller
> +Required properties:
> +- compatible: Should be "marvell,mmp-disp".
> +- reg: Should be address and length of the register set for this controller.
> +- interrupts: Should be interrupt of this controller.
> +- marvell,disp-name: Should be name of this controller
> +- marvell,path-num: Should be path number exists in this controller.
> +- marvell,clk-name: Should be name of clock this controller using.
> +
> +Required sub-node:
> +- path:
> +Required properties in this sub-node:
> +-- marvell,path-name: Should be name of this path, fb/panel uses this name to
> +connect to this path.
> +-- marvell,overlay_num: Should be number of overlay this path has.
> +-- marvell,output-type: Should be output-type settings
> +-- marvell,path-config: Should be path-config settings
> +-- marvell,link-config: Should be link-config settings
> +-- marvell,rbswap: Should be rbswap settings
> +
> +3. panel
> +Required properties:
> +- marvell,path-name: Should be path name that this panel connected to.
> +- other properties each panel has.
> +
> +Examples:
> +
> +fb: fb {
> + compatible = "marvell,mmp-fb";
This compatible should have the specific SoC name in it, not just
'mmp'. Otherwise you can't properly distinguish between this version and
future versions of the mmp core.
> + marvell,fb-name = "mmp_fb";
> + marvell,path-name = "mmp_pnpath";
You're not going to use this string to reference to another node, do
you? We have phandles for this.
> + marvell,overlay-id = <0>;
> + marvell,dmafetch-id = <1>;
> + marvell,default-pixfmt = <0x108>;
> +};
> +
> +disp: disp@d420b000 {
> + compatible = "marvell,mmp-disp";
> + reg = <0xd420b000 0x1fc>;
> + interrupts = <0 41 0x4>;
> + marvell,disp-name = "mmp_disp";
> + marvell,path-num = <1>;
> + marvell,clk-name = "LCDCIHCLK";
Don't pass clk names like this. We have a documented clock binding, use
it.
> +#ifdef CONFIG_OF
> + struct device_node *np;
> +#else
> struct mmp_buffer_driver_mach_info *mi;
> +#endif
> struct fb_info *info = 0;
> struct mmpfb_info *fbi = 0;
> - int ret, modes_num;
> -
> - mi = pdev->dev.platform_data;
> - if (mi = NULL) {
> - dev_err(&pdev->dev, "no platform data defined\n");
> - return -EINVAL;
> - }
> + int ret = -EINVAL, modes_num;
> + int overlay_id, dmafetch_id;
> + const char *path_name;
>
> /* initialize fb */
> info = framebuffer_alloc(sizeof(struct mmpfb_info), &pdev->dev);
> if (info = NULL)
> return -ENOMEM;
> fbi = info->par;
> - if (!fbi) {
> - ret = -EINVAL;
> + if (!fbi)
> + goto failed;
> +
> +#ifdef CONFIG_OF
Just because your kernel build does have CONFIG_OF enabled doesn't mean
it's actually started with a devicetree. You need to make a runtime
decision, not compile time.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH] video: mmp: add device tree support
From: Zhou Zhu @ 2014-01-09 6:05 UTC (permalink / raw)
To: Zhou Zhu, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Tomi Valkeinen, Jean-Christophe Plagniol-Villard, Haojian Zhuang,
Chao Xie, Guoqing Li
In-Reply-To: <1389244394-10779-1-git-send-email-zzhu3-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Add devicetree mail list.
On 01/09/2014 01:13 PM, Zhou Zhu wrote:
> add device tree support for mmp fb/controller
> the description at Documentation/devicetree/bindings/fb/mmp-disp.txt
>
> Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
> ---
> Documentation/devicetree/bindings/fb/mmp-disp.txt | 71 ++++++++++++
> drivers/video/mmp/fb/mmpfb.c | 71 ++++++++----
> drivers/video/mmp/hw/mmp_ctrl.c | 120 ++++++++++++++++-----
> 3 files changed, 217 insertions(+), 45 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/fb/mmp-disp.txt
>
> diff --git a/Documentation/devicetree/bindings/fb/mmp-disp.txt b/Documentation/devicetree/bindings/fb/mmp-disp.txt
> new file mode 100644
> index 0000000..3cf2903
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fb/mmp-disp.txt
> @@ -0,0 +1,71 @@
> +* Marvell MMP Display (MMP_DISP)
> +
> +To config mmp display, 3 parts are required to be set in dts:
> +1. mmp fb
> +Required properties:
> +- compatible: Should be "marvell,mmp-fb".
> +- marvell,fb-name: Should be the name of this fb.
> +- marvell,path-name: Should be the name of path this fb connecting to.
> +- marvell,overlay-id: Should be the id of overlay this fb is on.
> +- marvell,dmafetch-id: Should be the dma fetch id this fb using.
> +- marvell,default-pixfmt: Should be the default pixel format when this fb is
> +turned on.
> +
> +2. mmp controller
> +Required properties:
> +- compatible: Should be "marvell,mmp-disp".
> +- reg: Should be address and length of the register set for this controller.
> +- interrupts: Should be interrupt of this controller.
> +- marvell,disp-name: Should be name of this controller
> +- marvell,path-num: Should be path number exists in this controller.
> +- marvell,clk-name: Should be name of clock this controller using.
> +
> +Required sub-node:
> +- path:
> +Required properties in this sub-node:
> +-- marvell,path-name: Should be name of this path, fb/panel uses this name to
> +connect to this path.
> +-- marvell,overlay_num: Should be number of overlay this path has.
> +-- marvell,output-type: Should be output-type settings
> +-- marvell,path-config: Should be path-config settings
> +-- marvell,link-config: Should be link-config settings
> +-- marvell,rbswap: Should be rbswap settings
> +
> +3. panel
> +Required properties:
> +- marvell,path-name: Should be path name that this panel connected to.
> +- other properties each panel has.
> +
> +Examples:
> +
> +fb: fb {
> + compatible = "marvell,mmp-fb";
> + marvell,fb-name = "mmp_fb";
> + marvell,path-name = "mmp_pnpath";
> + marvell,overlay-id = <0>;
> + marvell,dmafetch-id = <1>;
> + marvell,default-pixfmt = <0x108>;
> +};
> +
> +disp: disp@d420b000 {
> + compatible = "marvell,mmp-disp";
> + reg = <0xd420b000 0x1fc>;
> + interrupts = <0 41 0x4>;
> + marvell,disp-name = "mmp_disp";
> + marvell,path-num = <1>;
> + marvell,clk-name = "LCDCIHCLK";
> + path1 {
> + marvell,path-name = "mmp_pnpath";
> + marvell,overlay-num = <2>;
> + marvell,output-type = <0>;
> + marvell,path-config = <0x20000000>;
> + marvell,link-config = <0x60000001>;
> + marvell,rbswap = <0>;
> + };
> +};
> +
> +panel: <panel-name> {
> + ...
> + marvell,path-name = "mmp_pnpath";
> + ...
> +};
> diff --git a/drivers/video/mmp/fb/mmpfb.c b/drivers/video/mmp/fb/mmpfb.c
> index 7ab31eb..e84a411 100644
> --- a/drivers/video/mmp/fb/mmpfb.c
> +++ b/drivers/video/mmp/fb/mmpfb.c
> @@ -22,6 +22,8 @@
> #include <linux/module.h>
> #include <linux/dma-mapping.h>
> #include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> #include "mmpfb.h"
>
> static int var_to_pixfmt(struct fb_var_screeninfo *var)
> @@ -551,56 +553,86 @@ static void fb_info_clear(struct fb_info *info)
> fb_dealloc_cmap(&info->cmap);
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id mmp_fb_dt_match[] = {
> + { .compatible = "marvell,mmp-fb" },
> + {},
> +};
> +#endif
> +
> static int mmpfb_probe(struct platform_device *pdev)
> {
> +#ifdef CONFIG_OF
> + struct device_node *np;
> +#else
> struct mmp_buffer_driver_mach_info *mi;
> +#endif
> struct fb_info *info = 0;
> struct mmpfb_info *fbi = 0;
> - int ret, modes_num;
> -
> - mi = pdev->dev.platform_data;
> - if (mi = NULL) {
> - dev_err(&pdev->dev, "no platform data defined\n");
> - return -EINVAL;
> - }
> + int ret = -EINVAL, modes_num;
> + int overlay_id, dmafetch_id;
> + const char *path_name;
>
> /* initialize fb */
> info = framebuffer_alloc(sizeof(struct mmpfb_info), &pdev->dev);
> if (info = NULL)
> return -ENOMEM;
> fbi = info->par;
> - if (!fbi) {
> - ret = -EINVAL;
> + if (!fbi)
> + goto failed;
> +
> +#ifdef CONFIG_OF
> + np = pdev->dev.of_node;
> +
> + if (!np || of_property_read_string(np,
> + "marvell,fb-name", &fbi->name) ||
> + of_property_read_string(np,
> + "marvell,path-name", &path_name) ||
> + of_property_read_u32(np,
> + "marvell,overlay-id", &overlay_id) ||
> + of_property_read_u32(np,
> + "marvell,dmafetch-id", &dmafetch_id) ||
> + of_property_read_u32(np,
> + "marvell,default-pixfmt", &fbi->pix_fmt)) {
> + dev_err(&pdev->dev, "unable to get fb setting from dt\n");
> goto failed;
> }
> +#else
> + mi = pdev->dev.platform_data;
> + if (mi = NULL) {
> + dev_err(&pdev->dev, "no platform data defined\n");
> + goto failed;
> + }
> + fbi->name = mi->name;
> + path_name = mi->path_name;
> + overlay_id = mi->overlay_id;
> + dmafetch_id = mi->dmafetch_id;
> + fbi->pix_fmt = mi->default_pixfmt;
> +#endif
>
> /* init fb */
> fbi->fb_info = info;
> platform_set_drvdata(pdev, fbi);
> fbi->dev = &pdev->dev;
> - fbi->name = mi->name;
> - fbi->pix_fmt = mi->default_pixfmt;
> pixfmt_to_var(&info->var, fbi->pix_fmt);
> mutex_init(&fbi->access_ok);
>
> /* get display path by name */
> - fbi->path = mmp_get_path(mi->path_name);
> + fbi->path = mmp_get_path(path_name);
> if (!fbi->path) {
> - dev_err(&pdev->dev, "can't get the path %s\n", mi->path_name);
> - ret = -EINVAL;
> + dev_err(&pdev->dev, "can't get the path %s\n", path_name);
> goto failed_destroy_mutex;
> }
>
> dev_info(fbi->dev, "path %s get\n", fbi->path->name);
>
> /* get overlay */
> - fbi->overlay = mmp_path_get_overlay(fbi->path, mi->overlay_id);
> - if (!fbi->overlay) {
> - ret = -EINVAL;
> + fbi->overlay = mmp_path_get_overlay(fbi->path, overlay_id);
> + if (!fbi->overlay)
> goto failed_destroy_mutex;
> - }
> +
> /* set fetch used */
> - mmp_overlay_set_fetch(fbi->overlay, mi->dmafetch_id);
> + mmp_overlay_set_fetch(fbi->overlay, dmafetch_id);
>
> modes_num = modes_setup(fbi);
> if (modes_num < 0) {
> @@ -679,6 +711,7 @@ static struct platform_driver mmpfb_driver = {
> .driver = {
> .name = "mmp-fb",
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(mmp_fb_dt_match),
> },
> .probe = mmpfb_probe,
> };
> diff --git a/drivers/video/mmp/hw/mmp_ctrl.c b/drivers/video/mmp/hw/mmp_ctrl.c
> index 8621a9f..19d68bc 100644
> --- a/drivers/video/mmp/hw/mmp_ctrl.c
> +++ b/drivers/video/mmp/hw/mmp_ctrl.c
> @@ -37,6 +37,8 @@
> #include <linux/uaccess.h>
> #include <linux/kthread.h>
> #include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
>
> #include "mmp_ctrl.h"
>
> @@ -396,26 +398,57 @@ static void path_set_default(struct mmp_path *path)
> writel_relaxed(tmp, ctrl_regs(path) + dma_ctrl(0, path->id));
> }
>
> -static int path_init(struct mmphw_path_plat *path_plat,
> - struct mmp_mach_path_config *config)
> +static int path_init(struct mmphw_path_plat *path_plat, void *arg)
> {
> struct mmphw_ctrl *ctrl = path_plat->ctrl;
> struct mmp_path_info *path_info;
> struct mmp_path *path = NULL;
> -
> - dev_info(ctrl->dev, "%s: %s\n", __func__, config->name);
> +#ifdef CONFIG_OF
> + struct device_node *path_np = arg;
> +#else
> + struct mmp_mach_path_config *config = arg;
> +#endif
>
> /* init driver data */
> path_info = kzalloc(sizeof(struct mmp_path_info), GFP_KERNEL);
> if (!path_info) {
> - dev_err(ctrl->dev, "%s: unable to alloc path_info for %s\n",
> - __func__, config->name);
> - return 0;
> + dev_err(ctrl->dev, "%s: unable to alloc path_info\n",
> + __func__);
> + return -ENOMEM;
> + }
> +
> +#ifdef CONFIG_OF
> + if (!path_np || of_property_read_string(path_np, "marvell,path-name",
> + &path_info->name) ||
> + of_property_read_u32(path_np, "marvell,overlay-num",
> + &path_info->output_type) ||
> + of_property_read_u32(path_np, "marvell,output-type",
> + &path_info->overlay_num)) {
> + dev_err(ctrl->dev, "%s: unable to get path setting from dt\n",
> + __func__);
> + kfree(path_info);
> + return -EINVAL;
> }
> + /* allow these settings not set */
> + of_property_read_u32(path_np, "marvell,path-config",
> + &path_plat->path_config);
> + of_property_read_u32(path_np, "marvell,link-config",
> + &path_plat->link_config);
> + of_property_read_u32(path_np, "marvell,rbswap",
> + &path_plat->dsi_rbswap);
> +#else
> path_info->name = config->name;
> + path_info->overlay_num = config->overlay_num;
> + path_info->output_type = config->output_type;
> + path_plat->path_config = config->path_config;
> + path_plat->link_config = config->link_config;
> + path_plat->dsi_rbswap = config->dsi_rbswap;
> +#endif
> +
> + dev_info(ctrl->dev, "%s: %s\n", __func__, path_info->name);
> +
> path_info->id = path_plat->id;
> path_info->dev = ctrl->dev;
> - path_info->overlay_num = config->overlay_num;
> path_info->overlay_ops = &mmphw_overlay_ops;
> path_info->set_mode = path_set_mode;
> path_info->plat_data = path_plat;
> @@ -424,16 +457,13 @@ static int path_init(struct mmphw_path_plat *path_plat,
> path = mmp_register_path(path_info);
> if (!path) {
> kfree(path_info);
> - return 0;
> + return -EINVAL;
> }
> path_plat->path = path;
> - path_plat->path_config = config->path_config;
> - path_plat->link_config = config->link_config;
> - path_plat->dsi_rbswap = config->dsi_rbswap;
> path_set_default(path);
>
> kfree(path_info);
> - return 1;
> + return 0;
> }
>
> static void path_deinit(struct mmphw_path_plat *path_plat)
> @@ -445,13 +475,25 @@ static void path_deinit(struct mmphw_path_plat *path_plat)
> mmp_unregister_path(path_plat->path);
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id mmp_disp_dt_match[] = {
> + { .compatible = "marvell,mmp-disp" },
> + {},
> +};
> +#endif
> +
> static int mmphw_probe(struct platform_device *pdev)
> {
> - struct mmp_mach_plat_info *mi;
> struct resource *res;
> - int ret, i, size, irq;
> + int ret, i, size, irq, path_num;
> + const char *clk_name, *disp_name;
> struct mmphw_path_plat *path_plat;
> struct mmphw_ctrl *ctrl = NULL;
> +#ifdef CONFIG_OF
> + struct device_node *np, *path_np = NULL;
> +#else
> + struct mmp_mach_plat_info *mi;
> +#endif
>
> /* get resources from platform data */
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -468,6 +510,22 @@ static int mmphw_probe(struct platform_device *pdev)
> goto failed;
> }
>
> +#ifdef CONFIG_OF
> + np = pdev->dev.of_node;
> +
> + if (!np || of_property_read_u32(np,
> + "marvell,path-num", &path_num) ||
> + of_property_read_string(np,
> + "marvell,disp-name", &disp_name) ||
> + of_property_read_string(np,
> + "marvell,clk-name", &clk_name) ||
> + of_get_child_count(np) != ctrl->path_num) {
> + dev_err(&pdev->dev, "%s: failed to get settings from dt\n",
> + __func__);
> + ret = -EINVAL;
> + goto failed;
> + }
> +#else
> /* get configs from platform data */
> mi = pdev->dev.platform_data;
> if (mi = NULL || !mi->path_num || !mi->paths) {
> @@ -476,17 +534,21 @@ static int mmphw_probe(struct platform_device *pdev)
> goto failed;
> }
>
> - /* allocate */
> + disp_name = mi->name;
> + path_num = mi->path_num;
> + clk_name = mi->clk_name;
> +#endif
> +
> + /* allocate ctrl */
> size = sizeof(struct mmphw_ctrl) + sizeof(struct mmphw_path_plat) *
> - mi->path_num;
> + path_num;
> ctrl = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
> if (!ctrl) {
> ret = -ENOMEM;
> goto failed;
> }
> -
> - ctrl->name = mi->name;
> - ctrl->path_num = mi->path_num;
> + ctrl->path_num = path_num;
> + ctrl->name = disp_name;
> ctrl->dev = &pdev->dev;
> ctrl->irq = irq;
> platform_set_drvdata(pdev, ctrl);
> @@ -521,9 +583,9 @@ static int mmphw_probe(struct platform_device *pdev)
> }
>
> /* get clock */
> - ctrl->clk = devm_clk_get(ctrl->dev, mi->clk_name);
> + ctrl->clk = devm_clk_get(ctrl->dev, clk_name);
> if (IS_ERR(ctrl->clk)) {
> - dev_err(ctrl->dev, "unable to get clk %s\n", mi->clk_name);
> + dev_err(ctrl->dev, "unable to get clk %s\n", clk_name);
> ret = -ENOENT;
> goto failed;
> }
> @@ -539,11 +601,16 @@ static int mmphw_probe(struct platform_device *pdev)
> path_plat->id = i;
> path_plat->ctrl = ctrl;
>
> - /* path init */
> - if (!path_init(path_plat, &mi->paths[i])) {
> - ret = -EINVAL;
> + /* path init from mach info or dt */
> +#ifdef CONFIG_OF
> + path_np = of_get_next_child(np, path_np);
> + ret = path_init(path_plat, path_np);
> +#else
> + ret = path_init(path_plat, &mi->paths[i]);
> +#endif
> +
> + if (ret)
> goto failed_path_init;
> - }
> }
>
> #ifdef CONFIG_MMP_DISP_SPI
> @@ -573,6 +640,7 @@ static struct platform_driver mmphw_driver = {
> .driver = {
> .name = "mmp-disp",
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(mmp_disp_dt_match),
> },
> .probe = mmphw_probe,
> };
>
--
Thanks, -Zhou
^ permalink raw reply
* [PATCH] video: mmp: add device tree support
From: Zhou Zhu @ 2014-01-09 5:13 UTC (permalink / raw)
To: linux-fbdev
add device tree support for mmp fb/controller
the description at Documentation/devicetree/bindings/fb/mmp-disp.txt
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
---
Documentation/devicetree/bindings/fb/mmp-disp.txt | 71 ++++++++++++
drivers/video/mmp/fb/mmpfb.c | 71 ++++++++----
drivers/video/mmp/hw/mmp_ctrl.c | 120 ++++++++++++++++-----
3 files changed, 217 insertions(+), 45 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fb/mmp-disp.txt
diff --git a/Documentation/devicetree/bindings/fb/mmp-disp.txt b/Documentation/devicetree/bindings/fb/mmp-disp.txt
new file mode 100644
index 0000000..3cf2903
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/mmp-disp.txt
@@ -0,0 +1,71 @@
+* Marvell MMP Display (MMP_DISP)
+
+To config mmp display, 3 parts are required to be set in dts:
+1. mmp fb
+Required properties:
+- compatible: Should be "marvell,mmp-fb".
+- marvell,fb-name: Should be the name of this fb.
+- marvell,path-name: Should be the name of path this fb connecting to.
+- marvell,overlay-id: Should be the id of overlay this fb is on.
+- marvell,dmafetch-id: Should be the dma fetch id this fb using.
+- marvell,default-pixfmt: Should be the default pixel format when this fb is
+turned on.
+
+2. mmp controller
+Required properties:
+- compatible: Should be "marvell,mmp-disp".
+- reg: Should be address and length of the register set for this controller.
+- interrupts: Should be interrupt of this controller.
+- marvell,disp-name: Should be name of this controller
+- marvell,path-num: Should be path number exists in this controller.
+- marvell,clk-name: Should be name of clock this controller using.
+
+Required sub-node:
+- path:
+Required properties in this sub-node:
+-- marvell,path-name: Should be name of this path, fb/panel uses this name to
+connect to this path.
+-- marvell,overlay_num: Should be number of overlay this path has.
+-- marvell,output-type: Should be output-type settings
+-- marvell,path-config: Should be path-config settings
+-- marvell,link-config: Should be link-config settings
+-- marvell,rbswap: Should be rbswap settings
+
+3. panel
+Required properties:
+- marvell,path-name: Should be path name that this panel connected to.
+- other properties each panel has.
+
+Examples:
+
+fb: fb {
+ compatible = "marvell,mmp-fb";
+ marvell,fb-name = "mmp_fb";
+ marvell,path-name = "mmp_pnpath";
+ marvell,overlay-id = <0>;
+ marvell,dmafetch-id = <1>;
+ marvell,default-pixfmt = <0x108>;
+};
+
+disp: disp@d420b000 {
+ compatible = "marvell,mmp-disp";
+ reg = <0xd420b000 0x1fc>;
+ interrupts = <0 41 0x4>;
+ marvell,disp-name = "mmp_disp";
+ marvell,path-num = <1>;
+ marvell,clk-name = "LCDCIHCLK";
+ path1 {
+ marvell,path-name = "mmp_pnpath";
+ marvell,overlay-num = <2>;
+ marvell,output-type = <0>;
+ marvell,path-config = <0x20000000>;
+ marvell,link-config = <0x60000001>;
+ marvell,rbswap = <0>;
+ };
+};
+
+panel: <panel-name> {
+ ...
+ marvell,path-name = "mmp_pnpath";
+ ...
+};
diff --git a/drivers/video/mmp/fb/mmpfb.c b/drivers/video/mmp/fb/mmpfb.c
index 7ab31eb..e84a411 100644
--- a/drivers/video/mmp/fb/mmpfb.c
+++ b/drivers/video/mmp/fb/mmpfb.c
@@ -22,6 +22,8 @@
#include <linux/module.h>
#include <linux/dma-mapping.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include "mmpfb.h"
static int var_to_pixfmt(struct fb_var_screeninfo *var)
@@ -551,56 +553,86 @@ static void fb_info_clear(struct fb_info *info)
fb_dealloc_cmap(&info->cmap);
}
+#ifdef CONFIG_OF
+static const struct of_device_id mmp_fb_dt_match[] = {
+ { .compatible = "marvell,mmp-fb" },
+ {},
+};
+#endif
+
static int mmpfb_probe(struct platform_device *pdev)
{
+#ifdef CONFIG_OF
+ struct device_node *np;
+#else
struct mmp_buffer_driver_mach_info *mi;
+#endif
struct fb_info *info = 0;
struct mmpfb_info *fbi = 0;
- int ret, modes_num;
-
- mi = pdev->dev.platform_data;
- if (mi = NULL) {
- dev_err(&pdev->dev, "no platform data defined\n");
- return -EINVAL;
- }
+ int ret = -EINVAL, modes_num;
+ int overlay_id, dmafetch_id;
+ const char *path_name;
/* initialize fb */
info = framebuffer_alloc(sizeof(struct mmpfb_info), &pdev->dev);
if (info = NULL)
return -ENOMEM;
fbi = info->par;
- if (!fbi) {
- ret = -EINVAL;
+ if (!fbi)
+ goto failed;
+
+#ifdef CONFIG_OF
+ np = pdev->dev.of_node;
+
+ if (!np || of_property_read_string(np,
+ "marvell,fb-name", &fbi->name) ||
+ of_property_read_string(np,
+ "marvell,path-name", &path_name) ||
+ of_property_read_u32(np,
+ "marvell,overlay-id", &overlay_id) ||
+ of_property_read_u32(np,
+ "marvell,dmafetch-id", &dmafetch_id) ||
+ of_property_read_u32(np,
+ "marvell,default-pixfmt", &fbi->pix_fmt)) {
+ dev_err(&pdev->dev, "unable to get fb setting from dt\n");
goto failed;
}
+#else
+ mi = pdev->dev.platform_data;
+ if (mi = NULL) {
+ dev_err(&pdev->dev, "no platform data defined\n");
+ goto failed;
+ }
+ fbi->name = mi->name;
+ path_name = mi->path_name;
+ overlay_id = mi->overlay_id;
+ dmafetch_id = mi->dmafetch_id;
+ fbi->pix_fmt = mi->default_pixfmt;
+#endif
/* init fb */
fbi->fb_info = info;
platform_set_drvdata(pdev, fbi);
fbi->dev = &pdev->dev;
- fbi->name = mi->name;
- fbi->pix_fmt = mi->default_pixfmt;
pixfmt_to_var(&info->var, fbi->pix_fmt);
mutex_init(&fbi->access_ok);
/* get display path by name */
- fbi->path = mmp_get_path(mi->path_name);
+ fbi->path = mmp_get_path(path_name);
if (!fbi->path) {
- dev_err(&pdev->dev, "can't get the path %s\n", mi->path_name);
- ret = -EINVAL;
+ dev_err(&pdev->dev, "can't get the path %s\n", path_name);
goto failed_destroy_mutex;
}
dev_info(fbi->dev, "path %s get\n", fbi->path->name);
/* get overlay */
- fbi->overlay = mmp_path_get_overlay(fbi->path, mi->overlay_id);
- if (!fbi->overlay) {
- ret = -EINVAL;
+ fbi->overlay = mmp_path_get_overlay(fbi->path, overlay_id);
+ if (!fbi->overlay)
goto failed_destroy_mutex;
- }
+
/* set fetch used */
- mmp_overlay_set_fetch(fbi->overlay, mi->dmafetch_id);
+ mmp_overlay_set_fetch(fbi->overlay, dmafetch_id);
modes_num = modes_setup(fbi);
if (modes_num < 0) {
@@ -679,6 +711,7 @@ static struct platform_driver mmpfb_driver = {
.driver = {
.name = "mmp-fb",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mmp_fb_dt_match),
},
.probe = mmpfb_probe,
};
diff --git a/drivers/video/mmp/hw/mmp_ctrl.c b/drivers/video/mmp/hw/mmp_ctrl.c
index 8621a9f..19d68bc 100644
--- a/drivers/video/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/mmp/hw/mmp_ctrl.c
@@ -37,6 +37,8 @@
#include <linux/uaccess.h>
#include <linux/kthread.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include "mmp_ctrl.h"
@@ -396,26 +398,57 @@ static void path_set_default(struct mmp_path *path)
writel_relaxed(tmp, ctrl_regs(path) + dma_ctrl(0, path->id));
}
-static int path_init(struct mmphw_path_plat *path_plat,
- struct mmp_mach_path_config *config)
+static int path_init(struct mmphw_path_plat *path_plat, void *arg)
{
struct mmphw_ctrl *ctrl = path_plat->ctrl;
struct mmp_path_info *path_info;
struct mmp_path *path = NULL;
-
- dev_info(ctrl->dev, "%s: %s\n", __func__, config->name);
+#ifdef CONFIG_OF
+ struct device_node *path_np = arg;
+#else
+ struct mmp_mach_path_config *config = arg;
+#endif
/* init driver data */
path_info = kzalloc(sizeof(struct mmp_path_info), GFP_KERNEL);
if (!path_info) {
- dev_err(ctrl->dev, "%s: unable to alloc path_info for %s\n",
- __func__, config->name);
- return 0;
+ dev_err(ctrl->dev, "%s: unable to alloc path_info\n",
+ __func__);
+ return -ENOMEM;
+ }
+
+#ifdef CONFIG_OF
+ if (!path_np || of_property_read_string(path_np, "marvell,path-name",
+ &path_info->name) ||
+ of_property_read_u32(path_np, "marvell,overlay-num",
+ &path_info->output_type) ||
+ of_property_read_u32(path_np, "marvell,output-type",
+ &path_info->overlay_num)) {
+ dev_err(ctrl->dev, "%s: unable to get path setting from dt\n",
+ __func__);
+ kfree(path_info);
+ return -EINVAL;
}
+ /* allow these settings not set */
+ of_property_read_u32(path_np, "marvell,path-config",
+ &path_plat->path_config);
+ of_property_read_u32(path_np, "marvell,link-config",
+ &path_plat->link_config);
+ of_property_read_u32(path_np, "marvell,rbswap",
+ &path_plat->dsi_rbswap);
+#else
path_info->name = config->name;
+ path_info->overlay_num = config->overlay_num;
+ path_info->output_type = config->output_type;
+ path_plat->path_config = config->path_config;
+ path_plat->link_config = config->link_config;
+ path_plat->dsi_rbswap = config->dsi_rbswap;
+#endif
+
+ dev_info(ctrl->dev, "%s: %s\n", __func__, path_info->name);
+
path_info->id = path_plat->id;
path_info->dev = ctrl->dev;
- path_info->overlay_num = config->overlay_num;
path_info->overlay_ops = &mmphw_overlay_ops;
path_info->set_mode = path_set_mode;
path_info->plat_data = path_plat;
@@ -424,16 +457,13 @@ static int path_init(struct mmphw_path_plat *path_plat,
path = mmp_register_path(path_info);
if (!path) {
kfree(path_info);
- return 0;
+ return -EINVAL;
}
path_plat->path = path;
- path_plat->path_config = config->path_config;
- path_plat->link_config = config->link_config;
- path_plat->dsi_rbswap = config->dsi_rbswap;
path_set_default(path);
kfree(path_info);
- return 1;
+ return 0;
}
static void path_deinit(struct mmphw_path_plat *path_plat)
@@ -445,13 +475,25 @@ static void path_deinit(struct mmphw_path_plat *path_plat)
mmp_unregister_path(path_plat->path);
}
+#ifdef CONFIG_OF
+static const struct of_device_id mmp_disp_dt_match[] = {
+ { .compatible = "marvell,mmp-disp" },
+ {},
+};
+#endif
+
static int mmphw_probe(struct platform_device *pdev)
{
- struct mmp_mach_plat_info *mi;
struct resource *res;
- int ret, i, size, irq;
+ int ret, i, size, irq, path_num;
+ const char *clk_name, *disp_name;
struct mmphw_path_plat *path_plat;
struct mmphw_ctrl *ctrl = NULL;
+#ifdef CONFIG_OF
+ struct device_node *np, *path_np = NULL;
+#else
+ struct mmp_mach_plat_info *mi;
+#endif
/* get resources from platform data */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -468,6 +510,22 @@ static int mmphw_probe(struct platform_device *pdev)
goto failed;
}
+#ifdef CONFIG_OF
+ np = pdev->dev.of_node;
+
+ if (!np || of_property_read_u32(np,
+ "marvell,path-num", &path_num) ||
+ of_property_read_string(np,
+ "marvell,disp-name", &disp_name) ||
+ of_property_read_string(np,
+ "marvell,clk-name", &clk_name) ||
+ of_get_child_count(np) != ctrl->path_num) {
+ dev_err(&pdev->dev, "%s: failed to get settings from dt\n",
+ __func__);
+ ret = -EINVAL;
+ goto failed;
+ }
+#else
/* get configs from platform data */
mi = pdev->dev.platform_data;
if (mi = NULL || !mi->path_num || !mi->paths) {
@@ -476,17 +534,21 @@ static int mmphw_probe(struct platform_device *pdev)
goto failed;
}
- /* allocate */
+ disp_name = mi->name;
+ path_num = mi->path_num;
+ clk_name = mi->clk_name;
+#endif
+
+ /* allocate ctrl */
size = sizeof(struct mmphw_ctrl) + sizeof(struct mmphw_path_plat) *
- mi->path_num;
+ path_num;
ctrl = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
if (!ctrl) {
ret = -ENOMEM;
goto failed;
}
-
- ctrl->name = mi->name;
- ctrl->path_num = mi->path_num;
+ ctrl->path_num = path_num;
+ ctrl->name = disp_name;
ctrl->dev = &pdev->dev;
ctrl->irq = irq;
platform_set_drvdata(pdev, ctrl);
@@ -521,9 +583,9 @@ static int mmphw_probe(struct platform_device *pdev)
}
/* get clock */
- ctrl->clk = devm_clk_get(ctrl->dev, mi->clk_name);
+ ctrl->clk = devm_clk_get(ctrl->dev, clk_name);
if (IS_ERR(ctrl->clk)) {
- dev_err(ctrl->dev, "unable to get clk %s\n", mi->clk_name);
+ dev_err(ctrl->dev, "unable to get clk %s\n", clk_name);
ret = -ENOENT;
goto failed;
}
@@ -539,11 +601,16 @@ static int mmphw_probe(struct platform_device *pdev)
path_plat->id = i;
path_plat->ctrl = ctrl;
- /* path init */
- if (!path_init(path_plat, &mi->paths[i])) {
- ret = -EINVAL;
+ /* path init from mach info or dt */
+#ifdef CONFIG_OF
+ path_np = of_get_next_child(np, path_np);
+ ret = path_init(path_plat, path_np);
+#else
+ ret = path_init(path_plat, &mi->paths[i]);
+#endif
+
+ if (ret)
goto failed_path_init;
- }
}
#ifdef CONFIG_MMP_DISP_SPI
@@ -573,6 +640,7 @@ static struct platform_driver mmphw_driver = {
.driver = {
.name = "mmp-disp",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mmp_disp_dt_match),
},
.probe = mmphw_probe,
};
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Hiremath, Vaibhav @ 2014-01-09 5:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52CD5D13.9090806@ti.com>
> -----Original Message-----
> From: Valkeinen, Tomi
> Sent: Wednesday, January 08, 2014 7:44 PM
> To: Tony Lindgren; Ivaylo Dimitrov
> Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-fbdev@vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
>
> On 2014-01-08 01:59, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
> >> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
> >> However, on some use cases, even when CMA is in use, it's quite
> >> probable that omapfb fails to allocate the fb, either due to not
> >> enough free dma memory, fragmented dma memory, or CMA failing to make
> >> enough contiguous space.
> >>
> >> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
> >> used to give the size of a memory area reserved exclusively for
> >> omapfb, and optionally a physical address where the memory area is
> reserved.
> >>
> >> The memory area is reserved with memblock, and assigned to omapfb
> >> with dma_declare_coherent_memory. The dma_alloc function will first
> >> try to allocate the fb from the coherent memory area, and if that
> >> fails, it'll use the normal method of allocation.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> >> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
> >
> > Feel free to queue this along with the DSS patches:
> >
> > Acked-by: Tony Lindgren <tony@atomide.com>
>
> Thanks.
>
> This introduces new kernel boot parameter, and I haven't really had time to test
> and think about this. If Ivaylo doesn't insist on this to be merged for 3.14, I'd
> rather leave this for 3.15 as adding new parameter that we need to support
> "forever" should be thought a bit more.
>
Tomi,
I am seeing underflow issue on AM43x device if I use omapfb_vram argument.
Did you see this on OMAP?
I am using "omapfb_vram\x10M@0xA0000000", and I believe it is correct way of usage.
Thanks,
Vaibhav
> Tomi
>
^ permalink raw reply
* Re: [PATCH 1/2] drm/panel: Add support for Samsung LTN101NT05 panel
From: Thierry Reding @ 2014-01-08 15:24 UTC (permalink / raw)
To: Marc Dietrich
Cc: linux-fbdev, dri-devel, linux-tegra, Thierry Reding,
linux-arm-kernel
In-Reply-To: <f03a644deb858f10affb7b039f9982bac81b02c9.1387656959.git.marvin24@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 818 bytes --]
On Sat, Dec 21, 2013 at 09:38:12PM +0100, Marc Dietrich wrote:
> The Samsung LNT101NT05 10.1" WXVGA panel can be supported by the simple panel
> driver.
>
> Cc: linux-fbdev@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: David Airlie <airlied@linux.ie>
> Signed-off-by: Marc Dietrich <marvin24@gmx.de>
> ---
> This isn't strickly required to get the panel up, but Thierry suggested on IRC to
> include it anyway, in case someone else has some use for it.
For the record: the reason this isn't strictly needed is because there's
an EDID that can be probed to get the video timings. But the panel still
can be supported using the timings from the datasheet. One example where
this would be useful is when the EDID isn't connected or simply broken.
That said: applied, thanks!
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] video: vgacon: Don't build on arm64
From: Geert Uytterhoeven @ 2014-01-08 15:05 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1387323421-26126-1-git-send-email-broonie@kernel.org>
On Wed, Jan 8, 2014 at 3:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 08 January 2014, Geert Uytterhoeven wrote:
>> VGA is special, in that it uses "ISA memory space". This is not a subset of
>> "PCI memory space", but something different. Some PCI host bridges
>> (IIRC, e.g. on Mac) do not allow access to this space.
>> Most other "PC I/O" use ISA I/O space, which is a subset of PCI I/O space.
>
> Right, but they often go together, and I think vgacon actually requires
> both, doesn't it? I'm not aware of anything else requiring access to the
Yes, VGA uses both.
> 0xa0000-0xfffff or the 0xf00000-0xffffff ISA memory windows except VGA,
> but I could be missing some less common devices. These are often not
> available on non-x86 systems, which prevents VGA from working even if
> low I/O space addresses are routed to PCI.
And MDA, for mdacon.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] video: vgacon: Don't build on arm64
From: Arnd Bergmann @ 2014-01-08 14:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1387323421-26126-1-git-send-email-broonie@kernel.org>
On Wednesday 08 January 2014, Geert Uytterhoeven wrote:
> VGA is special, in that it uses "ISA memory space". This is not a subset of
> "PCI memory space", but something different. Some PCI host bridges
> (IIRC, e.g. on Mac) do not allow access to this space.
> Most other "PC I/O" use ISA I/O space, which is a subset of PCI I/O space.
Right, but they often go together, and I think vgacon actually requires
both, doesn't it? I'm not aware of anything else requiring access to the
0xa0000-0xfffff or the 0xf00000-0xffffff ISA memory windows except VGA,
but I could be missing some less common devices. These are often not
available on non-x86 systems, which prevents VGA from working even if
low I/O space addresses are routed to PCI.
The CONFIG_PC_IO symbol would mostly be used for stuff like PC-style
floppy, dma, rtc, pic, parport, uart, etc. I think it does make sense
to include VGA in that list, but we may want to add a few machines
that explicitly support VGA on PCI without supporting other PC-style
components.
Arnd
^ permalink raw reply
* Re: [PATCH] video: imxfb: Use regulator API with LCD class for powering
From: Shawn Guo @ 2014-01-08 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52CD5361.50205@ti.com>
On Wed, Jan 08, 2014 at 03:32:17PM +0200, Tomi Valkeinen wrote:
> On 2013-12-23 10:28, Shawn Guo wrote:
> > On Mon, Dec 23, 2013 at 12:24:13PM +0400, Alexander Shiyan wrote:
> >>> On Sat, Dec 21, 2013 at 03:08:00PM +0400, Alexander Shiyan wrote:
> >>>> This patch replaces custom lcd_power() callback with
> >>>> regulator API over LCD class.
> >>>
> >>> FYI. Denis' effort on this already goes to v13.
> >>>
> >>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/285326
> >>
> >> Hmm, OK, but having LCD class could resolve our problems with contrast control.
> >> https://www.mail-archive.com/devicetree@vger.kernel.org/msg07660.html
> >
> > I just want to make sure you two are aware of each other's work.
>
> So, should I ignore this patch, or...?
No, no, that's not what I meant. Please go ahead to review the patch
and merge it if it looks good to you.
Shawn
^ permalink raw reply
* Re: [PATCH] video: vgacon: Don't build on arm64
From: Geert Uytterhoeven @ 2014-01-08 14:34 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1387323421-26126-1-git-send-email-broonie@kernel.org>
On Wed, Jan 8, 2014 at 2:48 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 08 January 2014 15:43:20 Tomi Valkeinen wrote:
>> On 2013-12-18 01:37, Mark Brown wrote:
>> > From: Mark Brown <broonie@linaro.org>
>> >
>> > arm64 is unlikely to have a VGA console and does not export screen_info
>> > causing build failures if the driver is build, for example in all*config.
>> > Add a dependency on !ARM64 to prevent this.
>> >
>> > This list is getting quite long, it may be easier to depend on a symbol
>> > which architectures that do support the driver can select.
>>
>> I agree, that depends on looks horrible =).
>
> I've suggested creating a "CONFIG_PC_IO" symbol before that could used
> to simplify this one and a couple of other similar Kconfig statements.
> It is unfortunately a bit tricky because out of the dozen drivers that
> are similar to this one, each one has a slightly different list of
> architectures, and it's not clear which of the differences are intentional
> rather than mistakes.
VGA is special, in that it uses "ISA memory space". This is not a subset of
"PCI memory space", but something different. Some PCI host bridges
(IIRC, e.g. on Mac) do not allow access to this space.
Most other "PC I/O" use ISA I/O space, which is a subset of PCI I/O space.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Tomi Valkeinen @ 2014-01-08 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140107235951.GH5074@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]
On 2014-01-08 01:59, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131230 05:21]:
>> The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
>> However, on some use cases, even when CMA is in use, it's quite probable
>> that omapfb fails to allocate the fb, either due to not enough free dma
>> memory, fragmented dma memory, or CMA failing to make enough contiguous
>> space.
>>
>> This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
>> used to give the size of a memory area reserved exclusively for omapfb,
>> and optionally a physical address where the memory area is reserved.
>>
>> The memory area is reserved with memblock, and assigned to omapfb with
>> dma_declare_coherent_memory. The dma_alloc function will first try to
>> allocate the fb from the coherent memory area, and if that fails, it'll
>> use the normal method of allocation.
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
>
> Feel free to queue this along with the DSS patches:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Thanks.
This introduces new kernel boot parameter, and I haven't really had time
to test and think about this. If Ivaylo doesn't insist on this to be
merged for 3.14, I'd rather leave this for 3.15 as adding new parameter
that we need to support "forever" should be thought a bit more.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] fbmem: really support wildcard video=options for all fbdev drivers
From: Tomi Valkeinen @ 2014-01-08 13:55 UTC (permalink / raw)
To: Olaf Hering; +Cc: plagnioj, linux-fbdev, linux-kernel
In-Reply-To: <1387140035-12234-1-git-send-email-olaf@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]
On 2013-12-15 22:40, Olaf Hering wrote:
> Documentation/fb/modedb.txt states that video=option should be
> considered a global option. But video_setup and fb_get_options are not
> coded that way. Instead its required to boot with video=driver:option to
> set a given option in drvier. This is cumbersome because it requires to
> know in advance which driver will be active for a given board/kernel.
>
> The following patch implements the documented catchall for the fbdev
> drivers. It is now possible to boot with video=XxY without the need to
> know the active driver in advance. The specific case it tries to fix is
> syslinux in the SUSE installer which offers a menu to set a display
> resolution. Right now this just appends the vga= option the kernel. But
> in addition to vga= it should be possible to pass a generic video=XxY
> for all framebuffer/drm drivers. With this change forcing a certain
> window size of VM displays is now much easier.
>
> Today the video= option is stored in a global fb_mode_option. But
> unfortunately only drm uses it.
>
> Note: this change introduces a small memleak if video=option is actually
> used because fb_mode_option is const. Most drivers use strsep to get to
> individual options. This could be fixed in a followup patch which always
> releases the option string in every caller of fb_get_options.
>
> Signed-off-by: Olaf Hering <olaf@aepfle.de>
> ---
> drivers/video/fbmem.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
> index 010d191..cde4619 100644
> --- a/drivers/video/fbmem.c
> +++ b/drivers/video/fbmem.c
> @@ -1930,6 +1930,9 @@ int fb_get_options(const char *name, char **option)
> options = opt + name_len + 1;
> }
> }
> + /* No match, pass global option */
> + if (!options && option && fb_mode_option)
> + options = kstrdup(fb_mode_option, GFP_KERNEL);
> if (options && !strncmp(options, "off", 3))
> retval = 1;
>
>
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] omapdss: dispc: Preload more data in pipeline DMAs for OMAP4+ SoCs
From: Tomi Valkeinen @ 2014-01-08 13:52 UTC (permalink / raw)
To: Archit Taneja; +Cc: linux-omap, linux-fbdev
In-Reply-To: <1387278621-10966-1-git-send-email-archit@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]
On 2013-12-17 13:10, Archit Taneja wrote:
> DISPC pipeline DMAs preload some bytes of pixel data in the vertical blanking
> region before the start of each frame. The preload ensures the pipeline doesn't
> underflow when the active region of the display starts.
>
> DISPC_GFX/VIDp_PRELOAD registers allow us to program how many bytes of data
> should be preloaded for each pipeline. Calculating a precise preload value
> would be a complex function of the pixel clock of the connected display, the
> vertical blanking duration and the interconnect traffic at that instance. If
> the register is left untouched, a default value is preloaded.
>
> We observe underflows for OMAP4+ SoCs for certain bandwidth intensive use cases
> with many other initiators active, and in situations where memory access isn't
> very efficient(like accessing Tiler mapped buffers and EMIF configured in
> non-interleaved more). The cause of the underflow is because the default preload
> value isn't sufficient for the DMA to reach a steady state. We configure the
> PRELOAD register such that the pipelines preload data up to the high threshold
> of the FIFO.
>
> Preloading lot of data for older SoCs can have a negative impact. Due to slower
> interconnects, it's possible that the DISPC DMA cannot preload up to the high
> threshold within the vertical blanking region of the panel. We leave the PRELOAD
> registers to their reset values since we haven't faced underflows with these
> SoCs because of low value of PRELOAD.
>
> Signed-off-by: Archit Taneja <archit@ti.com>
> ---
> drivers/video/omap2/dss/dispc.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
> index 6578540..ace179e 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -90,6 +90,8 @@ struct dispc_features {
>
> /* revert to the OMAP4 mechanism of DISPC Smart Standby operation */
> bool mstandby_workaround:1;
> +
> + bool set_max_preload:1;
> };
>
> #define DISPC_MAX_NR_FIFOS 5
> @@ -1200,6 +1202,15 @@ void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
> dispc_write_reg(DISPC_OVL_FIFO_THRESHOLD(plane),
> FLD_VAL(high, hi_start, hi_end) |
> FLD_VAL(low, lo_start, lo_end));
> +
> + /*
> + * configure the preload to the pipeline's high threhold, if HT it's too
> + * large for the preload field, set the threshold to the maximum value
> + * that can be held by the preload register
> + */
> + if (dss_has_feature(FEAT_PRELOAD) && dispc.feat->set_max_preload &&
> + plane != OMAP_DSS_WB)
> + dispc_write_reg(DISPC_OVL_PRELOAD(plane), min(high, 0xfff));
This causes compile warning:
drivers/video/omap2/dss/dispc.c: In function ‘dispc_ovl_set_fifo_threshold’:
drivers/video/omap2/dss/dispc.c:1213:152: warning: comparison of
distinct pointer types lacks a cast
I fixed it by changing 0xfff to 0xfffu
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: vgacon: Don't build on arm64
From: Arnd Bergmann @ 2014-01-08 13:48 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1387323421-26126-1-git-send-email-broonie@kernel.org>
On Wednesday 08 January 2014 15:43:20 Tomi Valkeinen wrote:
> On 2013-12-18 01:37, Mark Brown wrote:
> > From: Mark Brown <broonie@linaro.org>
> >
> > arm64 is unlikely to have a VGA console and does not export screen_info
> > causing build failures if the driver is build, for example in all*config.
> > Add a dependency on !ARM64 to prevent this.
> >
> > This list is getting quite long, it may be easier to depend on a symbol
> > which architectures that do support the driver can select.
>
> I agree, that depends on looks horrible =).
I've suggested creating a "CONFIG_PC_IO" symbol before that could used
to simplify this one and a couple of other similar Kconfig statements.
It is unfortunately a bit tricky because out of the dozen drivers that
are similar to this one, each one has a slightly different list of
architectures, and it's not clear which of the differences are intentional
rather than mistakes.
Arnd
^ permalink raw reply
* Re: [PATCH] video: vgacon: Don't build on arm64
From: Tomi Valkeinen @ 2014-01-08 13:43 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1387323421-26126-1-git-send-email-broonie@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
On 2013-12-18 01:37, Mark Brown wrote:
> From: Mark Brown <broonie@linaro.org>
>
> arm64 is unlikely to have a VGA console and does not export screen_info
> causing build failures if the driver is build, for example in all*config.
> Add a dependency on !ARM64 to prevent this.
>
> This list is getting quite long, it may be easier to depend on a symbol
> which architectures that do support the driver can select.
I agree, that depends on looks horrible =).
> Signed-off-by: Mark Brown <broonie@linaro.org>
> ---
> drivers/video/console/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
> index 846caab75a46..c39d6c42c3ef 100644
> --- a/drivers/video/console/Kconfig
> +++ b/drivers/video/console/Kconfig
> @@ -8,7 +8,8 @@ config VGA_CONSOLE
> bool "VGA text console" if EXPERT || !X86
> depends on !4xx && !8xx && !SPARC && !M68K && !PARISC && !FRV && \
> !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && !CRIS && \
> - (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER)
> + (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) \
> + && !ARM64
> default y
> help
> Saying Y here will allow you to use Linux in text mode through a
I moved the && to the previous line as is the custom. Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: mx3fb: Allow blocking during framebuffer allocation
From: Tomi Valkeinen @ 2014-01-08 13:37 UTC (permalink / raw)
To: Sascha Hauer; +Cc: linux-fbdev, Jean-Christophe Plagniol-Villard, linux-kernel
In-Reply-To: <1387441388-10962-1-git-send-email-s.hauer@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]
On 2013-12-19 10:23, Sascha Hauer wrote:
> No need to allocate the framebuffer from the atomic pool, we are not
> in interrupt context. Adding GFP_KERNEL to the framebuffer allocation
> allows to use the much bigger CMA pool to allocate the framebuffer.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/video/mx3fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
> index cfdb380..c882bec 100644
> --- a/drivers/video/mx3fb.c
> +++ b/drivers/video/mx3fb.c
> @@ -1263,7 +1263,7 @@ static int mx3fb_map_video_memory(struct fb_info *fbi, unsigned int mem_len,
>
> fbi->screen_base = dma_alloc_writecombine(fbi->device,
> mem_len,
> - &addr, GFP_DMA);
> + &addr, GFP_DMA | GFP_KERNEL);
>
> if (!fbi->screen_base) {
> dev_err(fbi->device, "Cannot allocate %u bytes framebuffer memory\n",
>
Thanks, queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] video: imxfb: Use regulator API with LCD class for powering
From: Tomi Valkeinen @ 2014-01-08 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131223082842.GI26070@S2101-09.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On 2013-12-23 10:28, Shawn Guo wrote:
> On Mon, Dec 23, 2013 at 12:24:13PM +0400, Alexander Shiyan wrote:
>>> On Sat, Dec 21, 2013 at 03:08:00PM +0400, Alexander Shiyan wrote:
>>>> This patch replaces custom lcd_power() callback with
>>>> regulator API over LCD class.
>>>
>>> FYI. Denis' effort on this already goes to v13.
>>>
>>> http://thread.gmane.org/gmane.linux.ports.arm.kernel/285326
>>
>> Hmm, OK, but having LCD class could resolve our problems with contrast control.
>> https://www.mail-archive.com/devicetree@vger.kernel.org/msg07660.html
>
> I just want to make sure you two are aware of each other's work.
So, should I ignore this patch, or...?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] video: ep93xx: Cleanup video-ep93xx.h header
From: Sachin Kamat @ 2014-01-08 10:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1388384533-20458-1-git-send-email-sachin.kamat@linaro.org>
On 8 January 2014 15:12, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2014-01-08 11:09, Sachin Kamat wrote:
>> Hi Tomi,
>>
>> On 30 December 2013 11:52, Sachin Kamat <sachin.kamat@linaro.org> wrote:
>>> Commit a3b2924547a7 ("ARM: ep93xx: move platform_data definitions")
>>> moved the file to the current location but forgot to remove the pointer
>>> to its previous location. Clean it up. While at it also change the header
>>> file protection macros appropriately.
>>>
>>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>
> Thanks, queued the series for 3.14.
Thanks Tomi.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH] fbcon: Fix memory leak in fbcon_exit().
From: Tomi Valkeinen @ 2014-01-08 9:53 UTC (permalink / raw)
To: Masami Ichikawa
Cc: plagnioj, linux-fbdev, airlied, udknight, gregkh, akpm, tiwai,
linux-kernel
In-Reply-To: <1387982857-14500-1-git-send-email-masami256@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2140 bytes --]
On 2013-12-25 16:47, Masami Ichikawa wrote:
> kmemleak reported a memory leak as below.
>
> unreferenced object 0xffff880036ca84c0 (size 16):
> comm "swapper/0", pid 1, jiffies 4294877407 (age 4434.633s)
> hex dump (first 16 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
> backtrace:
> [<ffffffff814ed01e>] kmemleak_alloc+0x4e/0xb0
> [<ffffffff8118913c>] __kmalloc+0x1fc/0x290
> [<ffffffff81302c9e>] bit_cursor+0x24e/0x6c0
> [<ffffffff812ff2f4>] fbcon_cursor+0x154/0x1d0
> [<ffffffff813675d8>] hide_cursor+0x28/0xa0
> [<ffffffff81368acf>] update_region+0x6f/0x90
> [<ffffffff81300268>] fbcon_switch+0x518/0x550
> [<ffffffff813695b9>] redraw_screen+0x189/0x240
> [<ffffffff8136a0e0>] do_bind_con_driver+0x360/0x380
> [<ffffffff8136a6e4>] do_take_over_console+0x114/0x1c0
> [<ffffffff812fdc83>] do_fbcon_takeover+0x63/0xd0
> [<ffffffff813023e5>] fbcon_event_notify+0x605/0x720
> [<ffffffff81501dcc>] notifier_call_chain+0x4c/0x70
> [<ffffffff81087f8d>] __blocking_notifier_call_chain+0x4d/0x70
> [<ffffffff81087fc6>] blocking_notifier_call_chain+0x16/0x20
> [<ffffffff812f201b>] fb_notifier_call_chain+0x1b/0x20
>
> In this case ops->cursor_state.mask is allocated in bit_cursor() but
> not freed in fbcon_exit(). So, fbcon_exit() needs to free buffer in its
> process.
> In the case, fbcon_exit() was called from fbcon_deinit() when driver
> called remove_conflicting_framebuffers().
>
> Signed-off-by: Masami Ichikawa <masami256@gmail.com>
> ---
> drivers/video/console/fbcon.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index cd8a802..4f02375 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -3561,6 +3561,7 @@ static void fbcon_exit(void)
>
> fbcon_del_cursor_timer(info);
> kfree(ops->cursor_src);
> + kfree(ops->cursor_state.mask);
> kfree(info->fbcon_par);
> info->fbcon_par = NULL;
> }
>
Thanks, queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] fbcon: trivial optimization for fbcon_exit
From: Tomi Valkeinen @ 2014-01-08 9:48 UTC (permalink / raw)
To: Wang YanQing
Cc: plagnioj, airlied, gregkh, akpm, kamal, linux-fbdev, linux-kernel
In-Reply-To: <20131227023917.GA3908@udknight>
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
On 2013-12-27 04:39, Wang YanQing wrote:
> Break out as soon as we find a mapped entry con2fb_map.
>
> Signed-off-by: Wang YanQing <udknight@gmail.com>
> ---
> drivers/video/console/fbcon.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index cd8a802..f39931f 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -3547,8 +3547,10 @@ static void fbcon_exit(void)
> "no"));
>
> for (j = first_fb_vc; j <= last_fb_vc; j++) {
> - if (con2fb_map[j] == i)
> + if (con2fb_map[j] == i) {
> mapped = 1;
> + break;
> + }
> }
>
> if (mapped) {
>
Thanks, queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] video: ep93xx: Cleanup video-ep93xx.h header
From: Tomi Valkeinen @ 2014-01-08 9:42 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1388384533-20458-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]
On 2014-01-08 11:09, Sachin Kamat wrote:
> Hi Tomi,
>
> On 30 December 2013 11:52, Sachin Kamat <sachin.kamat@linaro.org> wrote:
>> Commit a3b2924547a7 ("ARM: ep93xx: move platform_data definitions")
>> moved the file to the current location but forgot to remove the pointer
>> to its previous location. Clean it up. While at it also change the header
>> file protection macros appropriately.
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>> ---
>> include/linux/platform_data/video-ep93xx.h | 10 +++-------
>> 1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/linux/platform_data/video-ep93xx.h b/include/linux/platform_data/video-ep93xx.h
>> index d5ae11d7c453..92fc2b2232e7 100644
>> --- a/include/linux/platform_data/video-ep93xx.h
>> +++ b/include/linux/platform_data/video-ep93xx.h
>> @@ -1,9 +1,5 @@
>> -/*
>> - * arch/arm/mach-ep93xx/include/mach/fb.h
>> - */
>> -
>> -#ifndef __ASM_ARCH_EP93XXFB_H
>> -#define __ASM_ARCH_EP93XXFB_H
>> +#ifndef __VIDEO_EP93XX_H
>> +#define __VIDEO_EP93XX_H
>>
>> struct platform_device;
>> struct fb_videomode;
>> @@ -53,4 +49,4 @@ struct ep93xxfb_mach_info {
>> void (*blank)(int blank_mode, struct fb_info *info);
>> };
>>
>> -#endif /* __ASM_ARCH_EP93XXFB_H */
>> +#endif /* __VIDEO_EP93XX_H */
>> --
>> 1.7.9.5
>>
>
> Gentle ping on this series..
Thanks, queued the series for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] video: ep93xx: Cleanup video-ep93xx.h header
From: Sachin Kamat @ 2014-01-08 9:21 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1388384533-20458-1-git-send-email-sachin.kamat@linaro.org>
Hi Tomi,
On 30 December 2013 11:52, Sachin Kamat <sachin.kamat@linaro.org> wrote:
> Commit a3b2924547a7 ("ARM: ep93xx: move platform_data definitions")
> moved the file to the current location but forgot to remove the pointer
> to its previous location. Clean it up. While at it also change the header
> file protection macros appropriately.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> include/linux/platform_data/video-ep93xx.h | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/platform_data/video-ep93xx.h b/include/linux/platform_data/video-ep93xx.h
> index d5ae11d7c453..92fc2b2232e7 100644
> --- a/include/linux/platform_data/video-ep93xx.h
> +++ b/include/linux/platform_data/video-ep93xx.h
> @@ -1,9 +1,5 @@
> -/*
> - * arch/arm/mach-ep93xx/include/mach/fb.h
> - */
> -
> -#ifndef __ASM_ARCH_EP93XXFB_H
> -#define __ASM_ARCH_EP93XXFB_H
> +#ifndef __VIDEO_EP93XX_H
> +#define __VIDEO_EP93XX_H
>
> struct platform_device;
> struct fb_videomode;
> @@ -53,4 +49,4 @@ struct ep93xxfb_mach_info {
> void (*blank)(int blank_mode, struct fb_info *info);
> };
>
> -#endif /* __ASM_ARCH_EP93XXFB_H */
> +#endif /* __VIDEO_EP93XX_H */
> --
> 1.7.9.5
>
Gentle ping on this series..
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH 0/2] video: mxsfb: fix broken videomode selection
From: Tomi Valkeinen @ 2014-01-08 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389014278-4903-1-git-send-email-LW@KARO-electronics.de>
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
On 2014-01-06 15:17, Lothar Waßmann wrote:
> The first patch in this set converts some messages that are printed
> in case of errors to be error messages rather than debug messages.
>
> The second patch fixes a bug in the video selection code that
> incorrectly OR's together the 'pixelclk-active' and 'de-active'
> flags from all possible video modes specified in DT into one flag.
>
> The current code does not allow selecting one specific mode from a
> list of video modes, but always uses the last one of the video modes
> listed in the DT.
>
>
> Since all current dts files only have one entry in their
> 'display-timings' node, this bug was not apparent and the fix does not
> change the driver's behaviour for the current users.
>
> b/drivers/video/mxsfb.c | 6 +--
> drivers/video/mxsfb.c | 120 +++++++++++++++++++++++++++++-----------------------------------------
> 2 files changed, 53 insertions(+), 73 deletions(-)
>
Thanks, queued for 3.14.
Your diffstat above looks a bit funny. Where did that "b/" come from?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox