* 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
* Re: [PATCH RESEND 1/4] video: asiliantfb: remove unnecessary pci_set_drvdata()
From: Tomi Valkeinen @ 2014-01-08 8:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <001901cf0c0a$cb48b5e0$61da21a0$%han@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
On 2014-01-08 02:44, Jingoo Han wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> drivers/video/asiliantfb.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/video/asiliantfb.c b/drivers/video/asiliantfb.c
> index d611f1a..7e8ddf0 100644
> --- a/drivers/video/asiliantfb.c
> +++ b/drivers/video/asiliantfb.c
> @@ -589,7 +589,6 @@ static void asiliantfb_remove(struct pci_dev *dp)
> fb_dealloc_cmap(&p->cmap);
> iounmap(p->screen_base);
> release_mem_region(pci_resource_start(dp, 0), pci_resource_len(dp, 0));
> - pci_set_drvdata(dp, NULL);
> framebuffer_release(p);
> }
>
>
Series queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mobile_lcdcfb: Don't use plain 0 as NULL pointer
From: Tomi Valkeinen @ 2014-01-08 8:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1385512723-11722-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
On 2014-01-07 17:17, Laurent Pinchart wrote:
> Hi Jean-Christophe and Tomi,
>
> Could you please pick this patch up for v3.14 ?
>
> On Wednesday 27 November 2013 01:38:43 Laurent Pinchart wrote:
>> This fixes a sparse warning.
>>
>> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
>> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> Cc: linux-fbdev@vger.kernel.org
>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>> ---
>> drivers/video/sh_mobile_lcdcfb.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/sh_mobile_lcdcfb.c
>> b/drivers/video/sh_mobile_lcdcfb.c index ab85ad6..2bcc84a 100644
>> --- a/drivers/video/sh_mobile_lcdcfb.c
>> +++ b/drivers/video/sh_mobile_lcdcfb.c
>> @@ -1227,7 +1227,7 @@ static void sh_mobile_lcdc_stop(struct
>> sh_mobile_lcdc_priv *priv) /* Free the MERAM cache. */
>> if (ch->cache) {
>> sh_mobile_meram_cache_free(priv->meram_dev, ch->cache);
>> - ch->cache = 0;
>> + ch->cache = NULL;
>> }
>>
>> }
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 13/15] fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
From: Tomi Valkeinen @ 2014-01-08 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1917257.yB7aZMXWdP@avalon>
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
On 2014-01-07 17:15, Laurent Pinchart wrote:
> On Wednesday 11 December 2013 13:51:18 Laurent Pinchart wrote:
>> Hi Jean-Christophe and Tomi,
>>
>> Could you please pick this patch up for v3.14 ?
>
> Ping ?
Queued for 3.14.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH RESEND 4/4] video: vmlfb: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2014-01-08 0:46 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/vermilion/vermilion.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/vermilion/vermilion.c b/drivers/video/vermilion/vermilion.c
index 09a1366..048a666 100644
--- a/drivers/video/vermilion/vermilion.c
+++ b/drivers/video/vermilion/vermilion.c
@@ -383,7 +383,6 @@ static void vmlfb_disable_mmio(struct vml_par *par)
static void vmlfb_release_devices(struct vml_par *par)
{
if (atomic_dec_and_test(&par->refcount)) {
- pci_set_drvdata(par->vdc, NULL);
pci_disable_device(par->gpu);
pci_disable_device(par->vdc);
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH RESEND 3/4] video: rivafb: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2014-01-08 0:45 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/riva/fbdev.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/riva/fbdev.c b/drivers/video/riva/fbdev.c
index a5514ac..8a8d7f0 100644
--- a/drivers/video/riva/fbdev.c
+++ b/drivers/video/riva/fbdev.c
@@ -2128,7 +2128,6 @@ static void rivafb_remove(struct pci_dev *pd)
pci_release_regions(pd);
kfree(info->pixmap.addr);
framebuffer_release(info);
- pci_set_drvdata(pd, NULL);
NVTRACE_LEAVE();
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH RESEND 2/4] video: nvidiafb: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2014-01-08 0:45 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/nvidia/nvidia.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/nvidia/nvidia.c b/drivers/video/nvidia/nvidia.c
index ff22871..def0412 100644
--- a/drivers/video/nvidia/nvidia.c
+++ b/drivers/video/nvidia/nvidia.c
@@ -1461,7 +1461,6 @@ static void nvidiafb_remove(struct pci_dev *pd)
pci_release_regions(pd);
kfree(info->pixmap.addr);
framebuffer_release(info);
- pci_set_drvdata(pd, NULL);
NVTRACE_LEAVE();
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH RESEND 1/4] video: asiliantfb: remove unnecessary pci_set_drvdata()
From: Jingoo Han @ 2014-01-08 0:44 UTC (permalink / raw)
To: linux-fbdev
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
drivers/video/asiliantfb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/asiliantfb.c b/drivers/video/asiliantfb.c
index d611f1a..7e8ddf0 100644
--- a/drivers/video/asiliantfb.c
+++ b/drivers/video/asiliantfb.c
@@ -589,7 +589,6 @@ static void asiliantfb_remove(struct pci_dev *dp)
fb_dealloc_cmap(&p->cmap);
iounmap(p->screen_base);
release_mem_region(pci_resource_start(dp, 0), pci_resource_len(dp, 0));
- pci_set_drvdata(dp, NULL);
framebuffer_release(p);
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Tony Lindgren @ 2014-01-07 23:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1388409550-10720-2-git-send-email-tomi.valkeinen@ti.com>
* 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>
^ permalink raw reply
* Re: [PATCH 1/2] drm/panel: Add support for Samsung LTN101NT05 panel
From: Thierry Reding @ 2014-01-07 16:00 UTC (permalink / raw)
To: Stephen Warren; +Cc: linux-fbdev, Thierry Reding, dri-devel, Marc Dietrich
In-Reply-To: <52CB0281.7060203@wwwdotorg.org>
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
On Mon, Jan 06, 2014 at 12:22:41PM -0700, Stephen Warren wrote:
> On 12/21/2013 01:40 PM, Marc Dietrich wrote:
> > The Samsung LNT101NT05 10.1" WXVGA panel can be supported by the simple panel
> > driver.
>
> Thierry, I assume you'll take patch 1/2 throught the appropriate DRM tree.
Yes, will do.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: sh_mobile_lcdcfb: Don't use plain 0 as NULL pointer
From: Laurent Pinchart @ 2014-01-07 15:17 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1385512723-11722-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Hi Jean-Christophe and Tomi,
Could you please pick this patch up for v3.14 ?
On Wednesday 27 November 2013 01:38:43 Laurent Pinchart wrote:
> This fixes a sparse warning.
>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/video/sh_mobile_lcdcfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/sh_mobile_lcdcfb.c
> b/drivers/video/sh_mobile_lcdcfb.c index ab85ad6..2bcc84a 100644
> --- a/drivers/video/sh_mobile_lcdcfb.c
> +++ b/drivers/video/sh_mobile_lcdcfb.c
> @@ -1227,7 +1227,7 @@ static void sh_mobile_lcdc_stop(struct
> sh_mobile_lcdc_priv *priv) /* Free the MERAM cache. */
> if (ch->cache) {
> sh_mobile_meram_cache_free(priv->meram_dev, ch->cache);
> - ch->cache = 0;
> + ch->cache = NULL;
> }
>
> }
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 13/15] fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
From: Laurent Pinchart @ 2014-01-07 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1542726.dq1lpTml5f@avalon>
On Wednesday 11 December 2013 13:51:18 Laurent Pinchart wrote:
> Hi Jean-Christophe and Tomi,
>
> Could you please pick this patch up for v3.14 ?
Ping ?
> On Wednesday 27 November 2013 02:18:35 Laurent Pinchart wrote:
> > This helps increasing build testing coverage.
> >
> > Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: linux-fbdev@vger.kernel.org
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > Acked-by: Simon Horman <horms@verge.net.au>
> > ---
> >
> > drivers/video/Kconfig | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index 4f2e1b3..2aceb08 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -10,7 +10,8 @@ config HAVE_FB_ATMEL
> >
> > config SH_MIPI_DSI
> > tristate
> > - depends on (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
> > + depends on HAVE_CLK
> > + depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
> >
> > config SH_LCD_MIPI_DSI
> > bool
> > @@ -1997,7 +1998,8 @@ config FB_W100
> >
> > config FB_SH_MOBILE_LCDC
> > tristate "SuperH Mobile LCDC framebuffer support"
> > - depends on FB && (SUPERH || ARCH_SHMOBILE) && HAVE_CLK
> > + depends on FB && HAVE_CLK
> > + depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
> > select FB_SYS_FILLRECT
> > select FB_SYS_COPYAREA
> > select FB_SYS_IMAGEBLIT
> > @@ -2484,7 +2486,7 @@ endif
> >
> > config FB_SH_MOBILE_MERAM
> > tristate "SuperH Mobile MERAM read ahead support"
> > - depends on (SUPERH || ARCH_SHMOBILE)
> > + depends on SUPERH || ARCH_SHMOBILE || COMPILE_TEST
> > select GENERIC_ALLOCATOR
> > ---help---
> > Enable MERAM support for the SuperH controller.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* fbdev patches for 3.14
From: Tomi Valkeinen @ 2014-01-07 12:53 UTC (permalink / raw)
To: linux-fbdev
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
Hi,
Jean-Christophe was supposed to be handling this merge window, but that
doesn't seem to happen. So I'll start collecting fbdev patches for 3.14.
We're obviously very late, so I'm trying to apply only relatively safe
patches, nothing controversial.
I'll start going through the patches, but if there's something urgent, I
don't mind if you re-post it already. Or, if it's not urgent, check
linux-next at the end of the week, and re-post if it's not there yet.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v2] allow xenfb initialization for hvm guests
From: Tomi Valkeinen @ 2014-01-07 12:49 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Stefano Stabellini
Cc: xen-devel, linux-kernel, boris.ostrovsky, plagnioj, linux-fbdev
In-Reply-To: <20140103203422.GA2668@phenom.dumpdata.com>
[-- Attachment #1: Type: text/plain, Size: 747 bytes --]
On 2014-01-03 22:34, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 03, 2014 at 07:02:09PM +0000, Stefano Stabellini wrote:
>
> The title needs 'xen/fb' prefixed but that is easy enough.
>
>> There is no reasons why an HVM guest shouldn't be allowed to use xenfb.
>> As a matter of fact ARM guests, HVM from Linux POV, can use xenfb.
>> Given that no Xen toolstacks configure a xenfb backend for x86 HVM
>> guests, they are not affected.
>>
>> Please note that at this time QEMU needs few outstanding fixes to
>> provide xenfb on ARM:
>>
>> http://marc.info/?l=qemu-devel&m=138739419700837&w=2
>
> Cool. Is the video maintainer OK with the Xen maintainers stashing it
> in the Xen tree for Linus?
Yep, fine for me.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] backlight: lcd: call put_device if device_register fails
From: Jingoo Han @ 2014-01-07 1:42 UTC (permalink / raw)
To: 'Levente Kurusa'
Cc: 'LKML', 'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', linux-fbdev, 'Jingoo Han',
'Andrew Morton'
In-Reply-To: <1386959996-7958-4-git-send-email-levex@linux.com>
On Saturday, December 14, 2013 3:40 AM, Levente Kurusa wrote:
>
> Currently we kfree the container of the device which failed to register.
> This is wrong as the last reference is not given up with a put_device
> call. Also, now that we have put_device() callen, we no longer need
> the kfree as the new_ld->dev.release function will take care of kfreeing
> the associated memory.
>
> Signed-off-by: Levente Kurusa <levex@linux.com>
> ---
> drivers/video/backlight/lcd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/lcd.c b/drivers/video/backlight/lcd.c
> index 93cf15e..7de847d 100644
> --- a/drivers/video/backlight/lcd.c
> +++ b/drivers/video/backlight/lcd.c
> @@ -228,7 +228,7 @@ struct lcd_device *lcd_device_register(const char *name, struct device *parent,
>
> rc = device_register(&new_ld->dev);
> if (rc) {
> - kfree(new_ld);
> + put_device(&new_ld->dev);
> return ERR_PTR(rc);
> }
(+cc Andrew Morton)
Hi Levente Kurusa,
Would you fix the same thing for 'backlight.c' file?
./drivers/video/backlight/backlight.c
struct backlight_device *backlight_device_register(const char *name,
.....
rc = device_register(&new_bd->dev);
if (rc) {
kfree(new_bd);
return ERR_PTR(rc);
}
Best regards,
Jingoo Han
^ permalink raw reply
* FOSDEM14: Graphics DevRoom: Deadline approaching fast.
From: Luc Verhaegen @ 2014-01-07 1:22 UTC (permalink / raw)
To: mesa-dev, xorg-devel, dri-devel, xorg, wayland-devel,
xorg-announce, mir-devel, directfb-dev, linux-fbdev, linux-media
Hi,
There are still 5 slots open for the FOSDEM graphics DevRoom, and the
deadline is this friday, the 10th. Get a move on.
If you have requested an account reset with me before, but if you then
haven't bothered filing a talk, you do NOT have a slot. Please file a
talk ASAP to still secure a place.
For more information on how to file for a devroom, read the email sent
back in october:
http://lists.x.org/archives/xorg-devel/2013-October/038185.html
Luc Verhaegen.
^ 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