* Re: [PATCH] fbdev: sh_mobile_lcdc: Fix vertical panning step
From: Laurent Pinchart @ 2012-08-06 15:26 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1343306215-20868-1-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Morimoto-san,
On Sunday 29 July 2012 18:25:59 Kuninori Morimoto wrote:
> > diff --git a/drivers/video/sh_mobile_lcdcfb.c
> > b/drivers/video/sh_mobile_lcdcfb.c index 8cb653b..699487c 100644
> > --- a/drivers/video/sh_mobile_lcdcfb.c
> > +++ b/drivers/video/sh_mobile_lcdcfb.c
> > @@ -1716,11 +1716,11 @@ sh_mobile_lcdc_overlay_fb_init(struct
> > sh_mobile_lcdc_overlay *ovl)>
> > info->fix.visual = FB_VISUAL_TRUECOLOR;
> >
> > switch (ovl->format->fourcc) {
> >
> > - case V4L2_PIX_FMT_NV16:
> > - case V4L2_PIX_FMT_NV61:
> > - info->fix.ypanstep = 2;
> > case V4L2_PIX_FMT_NV12:
> > case V4L2_PIX_FMT_NV21:
> > + info->fix.ypanstep = 2;
> > + case V4L2_PIX_FMT_NV16:
> > + case V4L2_PIX_FMT_NV61:
> > info->fix.xpanstep = 2;
> > }
> >
> > @@ -2215,11 +2215,11 @@ sh_mobile_lcdc_channel_fb_init(struct
> > sh_mobile_lcdc_chan *ch,
> > info->fix.visual = FB_VISUAL_TRUECOLOR;
> >
> > switch (ch->format->fourcc) {
> > - case V4L2_PIX_FMT_NV16:
> > - case V4L2_PIX_FMT_NV61:
> > - info->fix.ypanstep = 2;
> > case V4L2_PIX_FMT_NV12:
> > case V4L2_PIX_FMT_NV21:
> > + info->fix.ypanstep = 2;
> > + case V4L2_PIX_FMT_NV16:
> > + case V4L2_PIX_FMT_NV61:
> > info->fix.xpanstep = 2;
> > }
>
> If possible, could you please add comment /* fall through */ ?
> current code is a little bit confusing
I'm afraid the code has already been pushed to v3.6-rc1 :-S
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] video: s3c-fb: Fix compile error/warning if CONFIG_OF is not selected
From: Dongjin Kim @ 2012-08-06 13:57 UTC (permalink / raw)
Cc: Dongjin Kim, Jingoo Han, Florian Tobias Schandinat, linux-fbdev,
linux-kernel
In-Reply-To: <1344261462-14183-1-git-send-email-dongjin.kim@agreeyamobility.net>
Change-Id: I5d7ff6f0070a10225d5b064b362d3d8f214787fd
Signed-off-by: Dongjin Kim <dongjin.kim@agreeyamobility.net>
---
drivers/video/s3c-fb.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 8c8adb5..268be0c 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -1527,13 +1527,11 @@ static int s3c_fb_dt_parse_gpios(struct device *dev, struct s3c_fb *sfb,
static void s3c_fb_dt_free_gpios(struct s3c_fb *sfb)
{
- return 0;
}
-static int s3c_fb_dt_parse_pdata(struct device *dev,
- struct s3c_fb_platdata **pdata)
+static struct s3c_fb_platdata *s3c_fb_dt_parse_pdata(struct device *dev)
{
- return 0;
+ return NULL;
}
#endif /* CONFIG_OF */
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] OMAPDSS: OMAPFB: fix framebuffer console colors
From: Igor Grinberg @ 2012-08-06 12:26 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Grazvydas Ignotas, linux-fbdev, linux-omap, Greg Kroah-Hartman
In-Reply-To: <1344252160.12136.13.camel@deskari>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/06/12 14:22, Tomi Valkeinen wrote:
> On Mon, 2012-08-06 at 13:15 +0300, Igor Grinberg wrote:
>> On 08/06/12 09:00, Tomi Valkeinen wrote:
>>> On Sat, 2012-08-04 at 19:19 +0300, Grazvydas Ignotas wrote:
>>>> omapfb does not currently set pseudo palette correctly for color depths
>>>> above 16bpp, making red text invisible, command like
>>>> echo -e '\e[0;31mRED' > /dev/tty1
>>>> will display nothing on framebuffer console in 24bpp mode.
>>>> This is because temporary variable is declared incorrectly, fix it.
>>>
>>> Thanks, applied to OMAP DSS tree.
>>
>> Is it also applicable to stable?
>> If yes, Tomi, can you please add the Cc tag?
>
> Yes, the bug has been there from the beginning.
>
> I can add the Cc tag. But I wonder is it enough just to have the tag, or
> should I also send the patch forward? And does it only get applied to
> the latest stable tree, not the earlier ones?
Well, the Documentation/stable_kernel_rules.txt says:
- To have the patch automatically included in the stable tree, add the tag
Cc: stable@vger.kernel.org
in the sign-off area. Once the patch is merged it will be applied to
the stable tree without anything else needing to be done by the author
or subsystem maintainer.
So I guess, you don't need to resend it.
Also, IIUC, if you can identify all the stable kernels it applies to,
you can specify them like:
Cc: <stable@vger.kernel.org> # 3.x, 2.6.x
This can save some work for those responsible for adding the patch to stable.
Now, if you say, it is applicable to all kernels since the omapfb support was
merged, I think, the above example it the right choice.
Anyway, Greg, please correct me if I've got anything wrong.
Thanks
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQH7gRAAoJEBDE8YO64EfakCAP/izNPA/HcFhxE3cRJJhlh5xw
Caf4h6gXjdTNekSfLEppyo+uf6F2ef8ojZFoim1x59phjC9N9TQWyqTgV6qTGWul
o8YtCo3CMXPTVnxgoYtIFNDIngiuZFVATEWdoHlxlpWwBXWcr6K101Rg+x0hlvzl
CAqquuwjO+GFmPn+6hLns3sFJcnD02e2Rb0tX29Yg/SdFCMPDIRA3NUANVqILcxN
do6mWpZ3tKOmPzobUDr1tswJxK94oc0pIjKMjxy71qAxpLMtY2bVNKavKuGsgaRr
Nl7Bml5e1vCvAJNtYTpiMKvjomTvS1gktBoAa43u81THDrvwzJNO/mUq88CuMOg0
D0k8ohKrv0/WyKr+LZe9W4l4I9lIvbutvF5oxcU+1gC01pMlr9qghO8J3Oz5/UTi
/Swd7Q5I6X29TtudIuAsZ8g5didNBTLYgih+DODviTRzaca7msF+VfNkcg2IeOuA
MvkMwiZSZX15ggriH07dEr+Z2XF7mMYVMgn492RokMzeXx31VXeHYv9pNGXcF+xn
xV55Z03RT2jcnIPJVSfnzXAXIhTdkM2MVBaS/iNKckPW1Q1quiY/7IeWJaX59LBl
bWUIFC02HJ+n8S2Tyqbr+7+0ue6v3xVocw/fcwx0PCLx0HltxhrAJJzTB+o4SDya
DpSx1+W2seaVbd7AgkmN
=qbs/
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] OMAPDSS: OMAPFB: fix framebuffer console colors
From: Tomi Valkeinen @ 2012-08-06 11:22 UTC (permalink / raw)
To: Igor Grinberg; +Cc: Grazvydas Ignotas, linux-fbdev, linux-omap
In-Reply-To: <501F9946.3030504@compulab.co.il>
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
On Mon, 2012-08-06 at 13:15 +0300, Igor Grinberg wrote:
> On 08/06/12 09:00, Tomi Valkeinen wrote:
> > On Sat, 2012-08-04 at 19:19 +0300, Grazvydas Ignotas wrote:
> >> omapfb does not currently set pseudo palette correctly for color depths
> >> above 16bpp, making red text invisible, command like
> >> echo -e '\e[0;31mRED' > /dev/tty1
> >> will display nothing on framebuffer console in 24bpp mode.
> >> This is because temporary variable is declared incorrectly, fix it.
> >
> > Thanks, applied to OMAP DSS tree.
>
> Is it also applicable to stable?
> If yes, Tomi, can you please add the Cc tag?
Yes, the bug has been there from the beginning.
I can add the Cc tag. But I wonder is it enough just to have the tag, or
should I also send the patch forward? And does it only get applied to
the latest stable tree, not the earlier ones?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] OMAPDSS: OMAPFB: fix framebuffer console colors
From: Igor Grinberg @ 2012-08-06 10:15 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: Grazvydas Ignotas, linux-fbdev, linux-omap
In-Reply-To: <1344232816.6227.0.camel@lappyti>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/06/12 09:00, Tomi Valkeinen wrote:
> On Sat, 2012-08-04 at 19:19 +0300, Grazvydas Ignotas wrote:
>> omapfb does not currently set pseudo palette correctly for color depths
>> above 16bpp, making red text invisible, command like
>> echo -e '\e[0;31mRED' > /dev/tty1
>> will display nothing on framebuffer console in 24bpp mode.
>> This is because temporary variable is declared incorrectly, fix it.
>
> Thanks, applied to OMAP DSS tree.
Is it also applicable to stable?
If yes, Tomi, can you please add the Cc tag?
Thanks
- --
Regards,
Igor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQH5lGAAoJEBDE8YO64Efak/YP/3APyqQ3d4TLB8sG7oHSF/Vn
zmwMl8kH2B70WIPWU1iIExodfrDd3Gms8UeGqjhj04kLHvqYUs3/lepTA6gkEnH0
U4vyO6WTMYtWBHUGXJhZk5GpOByn4aLdk4UGV22NNMmUI/xWqcVGSnntLjmRcUyu
Y1JRQqhlrXrYXH5A866J7yrwSwhhZ/sZXs4k1N5keCNaT8ieqn0HXvu02ma7bjF7
SvhWDPNOOWUuEOGsope8F2A8Mot4ToManqRHDTUSnq/cpWziGiy6/7I7ngVIMUgD
/nmiLISgU72wkoNDl0AxGQDVQ8HFUspzGe2e12VliG+ErmFkGfKr9XdI6fx7gKh2
ks7qL+uMBau9MpWYcRPhPvYrVn7tg6V9seN2/bG5gp2IgMFbu1wmibVMNyCGhQeX
1OhshGEKeR58s+R8KZ7+UzbjspDuSnlnFH2wVbbb3wr30Swc6VZA/rWlwNg3Bgz5
/h63a5SOwTF9nmV+3/O/ky4gyMORbbJyOBK/xWVmQkZ4lNNW02RnMaa6KP8fKlbb
Cc7x1P07jcMH83LKGyyhsvZrK/4JCloYEDTvuYHprf9Wb+WsXNCLsRiYMngUIwPc
eLrBVOlELQvS237eGAwMIfo4Lm3tI3WMyr8cjGy2aRqn8voDJW+qEN2NUNwkNDqS
kGYrOE0t5VRNx5egrv+J
=kydA
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH v3 4/4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent if available
From: Hideki EIRAKU @ 2012-08-06 9:55 UTC (permalink / raw)
To: Russell King, Pawel Osciak, Marek Szyprowski, Kyungmin Park,
Mauro Carvalho Chehab, Florian Tobias Schandinat, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-kernel, linux-kernel, linux-media, linux-fbdev,
alsa-devel, Katsuya MATSUBARA, Hideki EIRAKU
In-Reply-To: <1344246924-32620-1-git-send-email-hdk@igel.co.jp>
fb_mmap() implemented in fbmem.c uses smem_start as the physical
address of the frame buffer. In the sh_mobile_lcdc driver, the
smem_start is a dma_addr_t that is not a physical address when IOMMU is
enabled. dma_mmap_coherent() maps the address correctly. It is
available on ARM platforms.
Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
---
drivers/video/sh_mobile_lcdcfb.c | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 8cb653b..c8cba7a 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -1614,6 +1614,17 @@ static int sh_mobile_lcdc_overlay_blank(int blank, struct fb_info *info)
return 1;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+static int
+sh_mobile_lcdc_overlay_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct sh_mobile_lcdc_overlay *ovl = info->par;
+
+ return dma_mmap_coherent(ovl->channel->lcdc->dev, vma, ovl->fb_mem,
+ ovl->dma_handle, ovl->fb_size);
+}
+#endif
+
static struct fb_ops sh_mobile_lcdc_overlay_ops = {
.owner = THIS_MODULE,
.fb_read = fb_sys_read,
@@ -1626,6 +1637,9 @@ static struct fb_ops sh_mobile_lcdc_overlay_ops = {
.fb_ioctl = sh_mobile_lcdc_overlay_ioctl,
.fb_check_var = sh_mobile_lcdc_overlay_check_var,
.fb_set_par = sh_mobile_lcdc_overlay_set_par,
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ .fb_mmap = sh_mobile_lcdc_overlay_mmap,
+#endif
};
static void
@@ -2093,6 +2107,17 @@ static int sh_mobile_lcdc_blank(int blank, struct fb_info *info)
return 0;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+static int
+sh_mobile_lcdc_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct sh_mobile_lcdc_chan *ch = info->par;
+
+ return dma_mmap_coherent(ch->lcdc->dev, vma, ch->fb_mem,
+ ch->dma_handle, ch->fb_size);
+}
+#endif
+
static struct fb_ops sh_mobile_lcdc_ops = {
.owner = THIS_MODULE,
.fb_setcolreg = sh_mobile_lcdc_setcolreg,
@@ -2108,6 +2133,9 @@ static struct fb_ops sh_mobile_lcdc_ops = {
.fb_release = sh_mobile_lcdc_release,
.fb_check_var = sh_mobile_lcdc_check_var,
.fb_set_par = sh_mobile_lcdc_set_par,
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ .fb_mmap = sh_mobile_lcdc_mmap,
+#endif
};
static void
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available
From: Hideki EIRAKU @ 2012-08-06 9:55 UTC (permalink / raw)
To: Russell King, Pawel Osciak, Marek Szyprowski, Kyungmin Park,
Mauro Carvalho Chehab, Florian Tobias Schandinat, Jaroslav Kysela,
Takashi Iwai
Cc: Katsuya MATSUBARA, linux-fbdev, Hideki EIRAKU, alsa-devel,
linux-kernel, linux-arm-kernel, linux-media
In-Reply-To: <1344246924-32620-1-git-send-email-hdk@igel.co.jp>
Previously the vb2_dma_contig_mmap() function was using a dma_addr_t as a
physical address. The two addressses are not necessarily the same.
For example, when using the IOMMU funtion on certain platforms, dma_addr_t
addresses are not directly mappable physical address.
dma_mmap_coherent() maps the address correctly.
It is available on ARM platforms.
Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
---
drivers/media/video/videobuf2-dma-contig.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c b/drivers/media/video/videobuf2-dma-contig.c
index 4b71326..7eee9c5 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -101,14 +101,31 @@ static unsigned int vb2_dma_contig_num_users(void *buf_priv)
static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
{
struct vb2_dc_buf *buf = buf_priv;
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ int ret;
+#endif
if (!buf) {
printk(KERN_ERR "No buffer to map\n");
return -EINVAL;
}
+#ifdef ARCH_HAS_DMA_MMAP_COHERENT
+ ret = dma_mmap_coherent(buf->conf->dev, vma, buf->vaddr, buf->dma_addr,
+ buf->size);
+ if (ret) {
+ pr_err("Remapping memory failed, error: %d\n", ret);
+ return ret;
+ }
+ vma->vm_flags |= VM_DONTEXPAND | VM_RESERVED;
+ vma->vm_private_data = &buf->handler;
+ vma->vm_ops = &vb2_common_vm_ops;
+ vma->vm_ops->open(vma);
+ return 0;
+#else
return vb2_mmap_pfn_range(vma, buf->dma_addr, buf->size,
&vb2_common_vm_ops, &buf->handler);
+#endif
}
static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 2/4] ALSA: pcm - Don't define ARCH_HAS_DMA_MMAP_COHERENT privately for ARM
From: Hideki EIRAKU @ 2012-08-06 9:55 UTC (permalink / raw)
To: Russell King, Pawel Osciak, Marek Szyprowski, Kyungmin Park,
Mauro Carvalho Chehab, Florian Tobias Schandinat, Jaroslav Kysela,
Takashi Iwai
Cc: Katsuya MATSUBARA, linux-fbdev, alsa-devel, linux-kernel,
Laurent Pinchart, linux-arm-kernel, linux-media
In-Reply-To: <1344246924-32620-1-git-send-email-hdk@igel.co.jp>
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The ARM architecture now defines ARCH_HAS_DMA_MMAP_COHERENT, there's no
need to define it privately anymore.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
sound/core/pcm_native.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 53b5ada..84ead60 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3156,13 +3156,6 @@ static const struct vm_operations_struct snd_pcm_vm_ops_data_fault = {
.fault = snd_pcm_mmap_data_fault,
};
-#ifndef ARCH_HAS_DMA_MMAP_COHERENT
-/* This should be defined / handled globally! */
-#ifdef CONFIG_ARM
-#define ARCH_HAS_DMA_MMAP_COHERENT
-#endif
-#endif
-
/*
* mmap the DMA buffer on RAM
*/
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 1/4] ARM: dma-mapping: define ARCH_HAS_DMA_MMAP_COHERENT
From: Hideki EIRAKU @ 2012-08-06 9:55 UTC (permalink / raw)
To: Russell King, Pawel Osciak, Marek Szyprowski, Kyungmin Park,
Mauro Carvalho Chehab, Florian Tobias Schandinat, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-kernel, linux-kernel, linux-media, linux-fbdev,
alsa-devel, Katsuya MATSUBARA, Hideki EIRAKU
In-Reply-To: <1344246924-32620-1-git-send-email-hdk@igel.co.jp>
ARCH_HAS_DMA_MMAP_COHERENT indicates that there is dma_mmap_coherent() API
in this architecture. The name is already defined in PowerPC.
Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
---
arch/arm/include/asm/dma-mapping.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index bbef15d..f41cd30 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -187,6 +187,7 @@ extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
struct dma_attrs *attrs);
#define dma_mmap_coherent(d, v, c, h, s) dma_mmap_attrs(d, v, c, h, s, NULL)
+#define ARCH_HAS_DMA_MMAP_COHERENT
static inline int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr,
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 0/4] Use dma_mmap_coherent to support IOMMU mapper
From: Hideki EIRAKU @ 2012-08-06 9:55 UTC (permalink / raw)
To: Russell King, Pawel Osciak, Marek Szyprowski, Kyungmin Park,
Mauro Carvalho Chehab, Florian Tobias Schandinat, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-kernel, linux-kernel, linux-media, linux-fbdev,
alsa-devel, Katsuya MATSUBARA, Hideki EIRAKU
There is a dma_mmap_coherent() API in some architectures. This API
provides a mmap function for memory allocated by dma_alloc_coherent().
Some drivers mmap a dma_addr_t returned by dma_alloc_coherent() as a
physical address. But such drivers do not work correctly when IOMMU
mapper is used.
v3:
- Remove an unnecessary line which sets page protection bits.
v2:
- Rebase on fbdev-next branch of
git://github.com/schandinat/linux-2.6.git.
- Initialize .fb_mmap in both sh_mobile_lcdc_overlay_ops and
sh_mobile_lcdc_ops.
- Add Laurent's clean up patch.
Hideki EIRAKU (3):
ARM: dma-mapping: define ARCH_HAS_DMA_MMAP_COHERENT
media: videobuf2-dma-contig: use dma_mmap_coherent if available
fbdev: sh_mobile_lcdc: use dma_mmap_coherent if available
Laurent Pinchart (1):
ALSA: pcm - Don't define ARCH_HAS_DMA_MMAP_COHERENT privately for ARM
arch/arm/include/asm/dma-mapping.h | 1 +
drivers/media/video/videobuf2-dma-contig.c | 17 +++++++++++++++++
drivers/video/sh_mobile_lcdcfb.c | 28 ++++++++++++++++++++++++++++
sound/core/pcm_native.c | 7 -------
4 files changed, 46 insertions(+), 7 deletions(-)
^ permalink raw reply
* Re: [PATCH 5/5] drivers/video/msm/mddi_client_nt35399.c: use devm_ functions
From: Dan Carpenter @ 2012-08-06 9:06 UTC (permalink / raw)
To: Damien Cassou
Cc: David Brown, kernel-janitors, Daniel Walker, Bryan Huntsman,
Florian Tobias Schandinat, linux-arm-msm, linux-fbdev,
linux-kernel
In-Reply-To: <1344008414-2894-5-git-send-email-damien.cassou@lifl.fr>
On Fri, Aug 03, 2012 at 05:40:13PM +0200, Damien Cassou wrote:
> @@ -233,7 +234,6 @@ static int mddi_nt35399_remove(struct platform_device *pdev)
> struct panel_info *panel = platform_get_drvdata(pdev);
>
> setup_vsync(panel, 0);
> - kfree(panel);
> return 0;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
It's weird. This patch doesn't apply for me unless I add a blank
line between the "}" and the "--". I'm not sure if that line is
getting removed by your email client or by the kernel janitors email
list.
regards,
dan carpenter
^ permalink raw reply
* Re: Gethering power management/policy hw drivers under drivers/power/? (Re: [RFC][PATCH v3 1/3] runt
From: Pihet-XID, Jean @ 2012-08-06 8:45 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Alex Courbot, Greg Kroah-Hartman, David Woodhouse, Stephen Warren,
Thierry Reding, Simon Glass, Grant Likely, Rob Herring,
Mark Brown, Arnd Bergmann,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Liam Girdwood, MyungJoo Ham, Rafael J. Wysocki,
linux-pm-u79uwXL29TY76Z2rM5mHXA, KEERTHY J
In-Reply-To: <20120730024049.GA10442@lizard>
Hi Anton,
Sorry for the late reply. I was away and back now.
On Mon, Jul 30, 2012 at 4:40 AM, Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Mon, Jul 30, 2012 at 10:51:42AM +0900, Alex Courbot wrote:
> [...]
>> On the other hand I have just noticed that the apparently unrelated
>> Adaptive Voltage Scaling driver just appeared in drivers/power/avs.
>> So if Anton and David are ok with this, maybe I could put the power
>> sequences code in its own subdirectory within drivers/power.
>
> Well, currently drivers/power/ is indeed just for power supply class
> subsystem and drivers. But if the trend is to gather power management
> ("policy") stuff under one directory, i.e.
>
> drivers/
> power/
> supplies/ <- former "power supply class and drivers"
> regulators/
> idle/
> cpuidle/
> cpufreq/
> devfreq/
> avs/
> ...
>
> That would probably make sense, we could easily see the big picture.
> But if we're not going to do this long-term, I would suggest to stick
> to just a new directory under drivers (and move drivers/power/avs/ to
> drivers/avs).
>
> Cc'ing some more people...
>
> Thanks,
>
> p.s. Jean, why am I the last person who discovers drivers/power/avs/?
> Would be nice to Cc me on such patches; by moving AVS under
> drivers/power/ you effectively nominated me as its maintainer. :-)
Oops, I am really sorry about that ;-( . I wrongly assumed Rafael and
Greg KH were the contact persons for drivers/power and so I contacted
them before moving the code.
Thanks for letting me know. Are you ok with the changes? Let me know
if some more changes are needed.
Regards,
Jean
>
> --
> Anton Vorontsov
> Email: cbouatmailru@gmail.com
^ permalink raw reply
* Re: [PATCH] OMAPDSS: OMAPFB: fix framebuffer console colors
From: Tomi Valkeinen @ 2012-08-06 6:00 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-fbdev, linux-omap
In-Reply-To: <1344097153-13903-1-git-send-email-notasas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
On Sat, 2012-08-04 at 19:19 +0300, Grazvydas Ignotas wrote:
> omapfb does not currently set pseudo palette correctly for color depths
> above 16bpp, making red text invisible, command like
> echo -e '\e[0;31mRED' > /dev/tty1
> will display nothing on framebuffer console in 24bpp mode.
> This is because temporary variable is declared incorrectly, fix it.
Thanks, applied to OMAP DSS tree.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Alex Courbot @ 2012-08-06 2:27 UTC (permalink / raw)
To: Mark Brown
Cc: Stephen Warren, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Greg Kroah-Hartman, Arnd Bergmann,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fbdev@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
Thierry Reding
In-Reply-To: <20120804141155.GJ10523@opensource.wolfsonmicro.com>
On 08/04/2012 11:12 PM, Mark Brown wrote:
> On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
>> On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
>
>>> I missed some of the earlier bits of the thread here but why can't we do
>>> device based lookups?
>
>> That is because the phandles would not be properties of the device
>> node but rather of its sub-nodes:
>
>> backlight {
>> compatible = "pwm-backlight";
>> ...
>> power-on-sequence {
>> step@0 {
>> regulator = <&backlight_reg>;
>> enable;
>> };
>>
>
>> So here simply using regulator_get on the backlight device would not work.
>
> Ah, right. DT isn't being terribly helpful here... I think the thing
> I'd expect to work here is that you have a reference back to the supply
> property of the backlight device rather than direct to the regulator so
> you end up writing "enable supply X" rather than "enable regulator X".
>
> Not quite sure how exactly you'd accomplish that - I guess if
> regulator_get() would recursively follow phandles until it hits a node
> that'd do the trick?
Do you mean that regulator_get() would parse sub-nodes looking for a
match? That seems rather dangerous and error-prone, especially if one
has actual devices within the sub-nodes - their regulators could be
stolen by the parent device.
I think we only have two choices for this:
1) Stick to the scheme where resources are declared at the device level,
such as they can be referenced by name in the sub-nodes (basically what
I did in this patch):
backlight {
compatible = "pwm-backlight";
...
backlight-supply = <&backlight_reg>;
power-on-sequence {
step@0 {
regulator = "backlight";
enable;
};
This would translate by a get_regulator(dev, "backlight") in the code
which would be properly resolved.
2) Export a lower-level DT API for resolving phandles directly from a
property, similar to of_get_named_gpio. We would then have
of_get_named_regulator and of_get_named_pwm.
If 2) is deemed acceptable, then I think we should go for it as it would
provide the most compact and readable DT syntax. Otherwise 1) is still
acceptable IMHO, as it should at least make sense to people already
familiar with how the DT works.
Opinions from DT experts?
Alex.
^ permalink raw reply
* Re: [PATCH 5/6] drivers/video/backlight/da9052_bl.c: drop devm_kfree of devm_kzalloc'd data
From: Jingoo Han @ 2012-08-06 1:20 UTC (permalink / raw)
To: 'Julia Lawall', 'Richard Purdie'
Cc: kernel-janitors, 'Florian Tobias Schandinat', linux-fbdev,
linux-kernel, 'Jingoo Han'
In-Reply-To: <1344099049-15212-5-git-send-email-Julia.Lawall@lip6.fr>
On Sunday, August 05, 2012 1:51 AM Julia Lawall wrote:
>
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> devm_kfree should not have to be explicitly used.
>
> The semantic patch that fixes this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression x,d;
> @@
>
> x = devm_kzalloc(...)
> ...
> ?-devm_kfree(d,x);
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Jingoo Han <jg1.han@samsung.com>
It looks good.
Best regard,
Jingoo Han
>
> ---
> drivers/video/backlight/da9052_bl.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/backlight/da9052_bl.c b/drivers/video/backlight/da9052_bl.c
> index b628d68..7c8626a 100644
> --- a/drivers/video/backlight/da9052_bl.c
> +++ b/drivers/video/backlight/da9052_bl.c
> @@ -129,7 +129,6 @@ static int da9052_backlight_probe(struct platform_device *pdev)
> &da9052_backlight_ops, &props);
> if (IS_ERR(bl)) {
> dev_err(&pdev->dev, "Failed to register backlight\n");
> - devm_kfree(&pdev->dev, wleds);
> return PTR_ERR(bl);
> }
>
> @@ -149,7 +148,6 @@ static int da9052_backlight_remove(struct platform_device *pdev)
> wleds->state = DA9052_WLEDS_OFF;
> da9052_adjust_wled_brightness(wleds);
> backlight_device_unregister(bl);
> - devm_kfree(&pdev->dev, wleds);
>
> return 0;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 5/6] drivers/video/backlight/da9052_bl.c: drop devm_kfree of devm_kzalloc'd data
From: Julia Lawall @ 2012-08-04 16:50 UTC (permalink / raw)
To: Richard Purdie
Cc: kernel-janitors, Florian Tobias Schandinat, linux-fbdev,
linux-kernel
From: Julia Lawall <Julia.Lawall@lip6.fr>
devm_kfree should not have to be explicitly used.
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x,d;
@@
x = devm_kzalloc(...)
...
?-devm_kfree(d,x);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/video/backlight/da9052_bl.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/backlight/da9052_bl.c b/drivers/video/backlight/da9052_bl.c
index b628d68..7c8626a 100644
--- a/drivers/video/backlight/da9052_bl.c
+++ b/drivers/video/backlight/da9052_bl.c
@@ -129,7 +129,6 @@ static int da9052_backlight_probe(struct platform_device *pdev)
&da9052_backlight_ops, &props);
if (IS_ERR(bl)) {
dev_err(&pdev->dev, "Failed to register backlight\n");
- devm_kfree(&pdev->dev, wleds);
return PTR_ERR(bl);
}
@@ -149,7 +148,6 @@ static int da9052_backlight_remove(struct platform_device *pdev)
wleds->state = DA9052_WLEDS_OFF;
da9052_adjust_wled_brightness(wleds);
backlight_device_unregister(bl);
- devm_kfree(&pdev->dev, wleds);
return 0;
}
^ permalink raw reply related
* [PATCH] OMAPDSS: OMAPFB: fix framebuffer console colors
From: Grazvydas Ignotas @ 2012-08-04 16:19 UTC (permalink / raw)
To: linux-fbdev; +Cc: linux-omap, Tomi Valkeinen, Grazvydas Ignotas
omapfb does not currently set pseudo palette correctly for color depths
above 16bpp, making red text invisible, command like
echo -e '\e[0;31mRED' > /dev/tty1
will display nothing on framebuffer console in 24bpp mode.
This is because temporary variable is declared incorrectly, fix it.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 70aa47d..f7c1753 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1183,7 +1183,7 @@ static int _setcolreg(struct fb_info *fbi, u_int regno, u_int red, u_int green,
break;
if (regno < 16) {
- u16 pal;
+ u32 pal;
pal = ((red >> (16 - var->red.length)) <<
var->red.offset) |
((green >> (16 - var->green.length)) <<
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Mark Brown @ 2012-08-04 14:12 UTC (permalink / raw)
To: Alex Courbot
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Stephen Warren, Greg Kroah-Hartman,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <501B2642.4080805-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
> On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
> >I missed some of the earlier bits of the thread here but why can't we do
> >device based lookups?
> That is because the phandles would not be properties of the device
> node but rather of its sub-nodes:
> backlight {
> compatible = "pwm-backlight";
> ...
> power-on-sequence {
> step@0 {
> regulator = <&backlight_reg>;
> enable;
> };
>
> So here simply using regulator_get on the backlight device would not work.
Ah, right. DT isn't being terribly helpful here... I think the thing
I'd expect to work here is that you have a reference back to the supply
property of the backlight device rather than direct to the regulator so
you end up writing "enable supply X" rather than "enable regulator X".
Not quite sure how exactly you'd accomplish that - I guess if
regulator_get() would recursively follow phandles until it hits a node
that'd do the trick?
^ permalink raw reply
* [PATCH 1/3] drivers/video/auo_k190x.c: drop kfree of devm_kzalloc's data
From: Julia Lawall @ 2012-08-04 12:00 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: kernel-janitors, linux-fbdev, linux-kernel
From: Julia Lawall <Julia.Lawall@lip6.fr>
Using kfree to free data allocated with devm_kzalloc causes double frees.
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x;
@@
x = devm_kzalloc(...)
...
?-kfree(x);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/video/auo_k190x.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/auo_k190x.c b/drivers/video/auo_k190x.c
index 77da6a2..c03ecdd 100644
--- a/drivers/video/auo_k190x.c
+++ b/drivers/video/auo_k190x.c
@@ -987,7 +987,6 @@ err_regfb:
fb_dealloc_cmap(&info->cmap);
err_cmap:
fb_deferred_io_cleanup(info);
- kfree(info->fbdefio);
err_defio:
vfree((void *)info->screen_base);
err_irq:
@@ -1022,7 +1021,6 @@ int __devexit auok190x_common_remove(struct platform_device *pdev)
fb_dealloc_cmap(&info->cmap);
fb_deferred_io_cleanup(info);
- kfree(info->fbdefio);
vfree((void *)info->screen_base);
^ permalink raw reply related
* Re: [PATCH v2] of: Add videomode helper
From: Stephen Warren @ 2012-08-03 18:30 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Laurent Pinchart, kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org
In-Reply-To: <20120803073844.GK1451-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 08/03/2012 01:38 AM, Sascha Hauer wrote:
> Hi Stephen,
>
> On Thu, Aug 02, 2012 at 01:35:40PM -0600, Stephen Warren wrote:
>> On 07/04/2012 01:56 AM, Sascha Hauer wrote:
>>> This patch adds a helper function for parsing videomodes from the devicetree.
>>> The videomode can be either converted to a struct drm_display_mode or a
>>> struct fb_videomode.
>>
>>> diff --git a/Documentation/devicetree/bindings/video/displaymode b/Documentation/devicetree/bindings/video/displaymode
>>
>>> +Required properties:
>>> + - xres, yres: Display resolution
>>> + - left-margin, right-margin, hsync-len: Horizontal Display timing parameters
>>> + in pixels
>>> + upper-margin, lower-margin, vsync-len: Vertical display timing parameters in
>>> + lines
>>
>> Perhaps bike-shedding, but...
>>
>> For the margin property names, wouldn't it be better to use terminology
>> more commonly used for video timings rather than Linux FB naming. In
>> other words naming like:
>>
>> hactive, hsync-len, hfront-porch, hback-porch?
>
> Can do. Just to make sure:
>
> hactive = xres
> hsync-len = hsync-len
> hfront-porch = right-margin
> hback-porch = left-margin
I believe so yes.
>> a) They're already standardized and very common.
>
> Indeed, that's a big plus for EDID. I have no intention of removing EDID
> data from the devicetree. There are situations where EDID is handy, for
> example when you get EDID data provided by your vendor.
>
>>
>> b) They allow other information such as a display's HDMI audio
>> capabilities to be represented, which can then feed into an ALSA driver.
>>
>> c) The few LCD panel datasheets I've seen actually quote their
>> specification as an EDID already, so deriving the EDID may actually be easy.
>>
>> d) People familiar with displays are almost certainly familiar with
>> EDID's mode representation. There are many ways of representing display
>> modes (sync position vs. porch widths, htotal specified rather than
>> specifying all the components and hence htotal being calculated etc.).
>> Not everyone will be familiar with all representations. Conversion
>> errors are less likely if the target is EDID's familiar format.
>
> You seem to think about a different class of displays for which EDID
> indeed is a better way to handle. What I have to deal with here mostly
> are dumb displays which:
>
> - can only handle their native resolution
> - Have no audio capabilities at all
> - come with a datasheet which specify a min/typ/max triplet for
> xres,hsync,..., often enough they are scanned to pdf from some previously
> printed paper.
>
> These displays are very common on embedded devices, probably that's the
> reason I did not even think about the possibility that a single display
> might have different modes.
That's true, but as I mentioned, there are at least some dumb panels
(both I've seen recently) whose specification provides the EDID. I don't
know how common that is though, I must admit.
>> e) You'll end up with exactly the same data as if you have a DDC-based
>> external monitor rather than an internal panel, so you end up getting to
>> a common path in display handling code much more quickly.
>
> All we have in our display driver currently is:
>
> edidp = of_get_property(np, "edid", &imxpd->edid_len);
> if (edidp) {
> imxpd->edid = kmemdup(edidp, imxpd->edid_len, GFP_KERNEL);
> } else {
> ret = of_get_video_mode(np, &imxpd->mode, NULL);
> if (!ret)
> imxpd->mode_valid = 1;
> }
Presumably there's more to it though; something later checks
imxpd->mode_valid and if false, parses the EDID and sets up imxpd->mode,
etc.
^ permalink raw reply
* [PATCH 4/5] drivers/video/msm/mddi_client_dummy.c: use devm_ functions
From: Damien Cassou @ 2012-08-03 15:40 UTC (permalink / raw)
To: David Brown
Cc: kernel-janitors, Daniel Walker, Bryan Huntsman,
Florian Tobias Schandinat, linux-arm-msm, linux-fbdev,
linux-kernel
In-Reply-To: <1344008414-2894-1-git-send-email-damien.cassou@lifl.fr>
From: Damien Cassou <damien.cassou@lifl.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch replaces the use of kzalloc by devm_kzalloc.
Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
---
drivers/video/msm/mddi_client_dummy.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/video/msm/mddi_client_dummy.c b/drivers/video/msm/mddi_client_dummy.c
index d2a091c..4c31325 100644
--- a/drivers/video/msm/mddi_client_dummy.c
+++ b/drivers/video/msm/mddi_client_dummy.c
@@ -51,7 +51,7 @@ static int mddi_dummy_probe(struct platform_device *pdev)
{
struct msm_mddi_client_data *client_data = pdev->dev.platform_data;
struct panel_info *panel - kzalloc(sizeof(struct panel_info), GFP_KERNEL);
+ devm_kzalloc(&pdev->dev, sizeof(struct panel_info), GFP_KERNEL);
int ret;
if (!panel)
return -ENOMEM;
@@ -67,18 +67,11 @@ static int mddi_dummy_probe(struct platform_device *pdev)
client_data->fb_resource, 1);
panel->panel_data.fb_data = client_data->private_client_data;
panel->pdev.dev.platform_data = &panel->panel_data;
- ret = platform_device_register(&panel->pdev);
- if (ret) {
- kfree(panel);
- return ret;
- }
- return 0;
+ return platform_device_register(&panel->pdev);
}
static int mddi_dummy_remove(struct platform_device *pdev)
{
- struct panel_info *panel = platform_get_drvdata(pdev);
- kfree(panel);
return 0;
}
^ permalink raw reply related
* [PATCH 5/5] drivers/video/msm/mddi_client_nt35399.c: use devm_ functions
From: Damien Cassou @ 2012-08-03 15:40 UTC (permalink / raw)
To: David Brown
Cc: kernel-janitors, Daniel Walker, Bryan Huntsman,
Florian Tobias Schandinat, linux-arm-msm, linux-fbdev,
linux-kernel
In-Reply-To: <1344008414-2894-1-git-send-email-damien.cassou@lifl.fr>
From: Damien Cassou <damien.cassou@lifl.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch replaces the use of kzalloc by devm_kzalloc.
Additionally, this patch fixes a memory leak: some memory was allocated for
'panel' but not released when the subsequent call to setup_vsync fails.
Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
---
drivers/video/msm/mddi_client_nt35399.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/msm/mddi_client_nt35399.c b/drivers/video/msm/mddi_client_nt35399.c
index 7fcd67e..66b314e 100644
--- a/drivers/video/msm/mddi_client_nt35399.c
+++ b/drivers/video/msm/mddi_client_nt35399.c
@@ -189,8 +189,9 @@ static int mddi_nt35399_probe(struct platform_device *pdev)
int ret;
- struct panel_info *panel = kzalloc(sizeof(struct panel_info),
- GFP_KERNEL);
+ struct panel_info *panel = devm_kzalloc(&pdev->dev,
+ sizeof(struct panel_info),
+ GFP_KERNEL);
printk(KERN_DEBUG "%s: enter.\n", __func__);
@@ -233,7 +234,6 @@ static int mddi_nt35399_remove(struct platform_device *pdev)
struct panel_info *panel = platform_get_drvdata(pdev);
setup_vsync(panel, 0);
- kfree(panel);
return 0;
}
^ permalink raw reply related
* [PATCH 2/5] drivers/video/bf54x-lq043fb.c: use devm_ functions
From: Damien Cassou @ 2012-08-03 15:40 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1344008414-2894-1-git-send-email-damien.cassou@lifl.fr>
From: Damien Cassou <damien.cassou@lifl.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch replaces the use of kzalloc by devm_kzalloc.
Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
---
drivers/video/bf54x-lq043fb.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
index dc2f004..47702ee 100644
--- a/drivers/video/bf54x-lq043fb.c
+++ b/drivers/video/bf54x-lq043fb.c
@@ -601,7 +601,8 @@ static int __devinit bfin_bf54x_probe(struct platform_device *pdev)
fbinfo->fbops = &bfin_bf54x_fb_ops;
- fbinfo->pseudo_palette = kzalloc(sizeof(u32) * 16, GFP_KERNEL);
+ fbinfo->pseudo_palette = devm_kzalloc(&pdev->dev, sizeof(u32) * 16,
+ GFP_KERNEL);
if (!fbinfo->pseudo_palette) {
printk(KERN_ERR DRIVER_NAME
"Fail to allocate pseudo_palette\n");
@@ -616,7 +617,7 @@ static int __devinit bfin_bf54x_probe(struct platform_device *pdev)
"Fail to allocate colormap (%d entries)\n",
BFIN_LCD_NBR_PALETTE_ENTRIES);
ret = -EFAULT;
- goto out5;
+ goto out4;
}
if (request_ports(info)) {
@@ -671,8 +672,6 @@ out7:
free_ports(info);
out6:
fb_dealloc_cmap(&fbinfo->cmap);
-out5:
- kfree(fbinfo->pseudo_palette);
out4:
dma_free_coherent(NULL, fbinfo->fix.smem_len, info->fb_buffer,
info->dma_handle);
@@ -699,7 +698,6 @@ static int __devexit bfin_bf54x_remove(struct platform_device *pdev)
dma_free_coherent(NULL, fbinfo->fix.smem_len, info->fb_buffer,
info->dma_handle);
- kfree(fbinfo->pseudo_palette);
fb_dealloc_cmap(&fbinfo->cmap);
#ifndef NO_BL_SUPPORT
^ permalink raw reply related
* [PATCH 3/5] drivers/video/jz4740_fb.c: use devm_ functions
From: Damien Cassou @ 2012-08-03 15:40 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: kernel-janitors, linux-fbdev, linux-kernel
In-Reply-To: <1344008414-2894-1-git-send-email-damien.cassou@lifl.fr>
From: Damien Cassou <damien.cassou@lifl.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in the
probe function of a platform device and is only freed in the remove function.
Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
---
drivers/video/jz4740_fb.c | 22 ++++++----------------
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/video/jz4740_fb.c b/drivers/video/jz4740_fb.c
index de36693..7669770 100644
--- a/drivers/video/jz4740_fb.c
+++ b/drivers/video/jz4740_fb.c
@@ -659,25 +659,25 @@ static int __devinit jzfb_probe(struct platform_device *pdev)
jzfb->pdata = pdata;
jzfb->mem = mem;
- jzfb->ldclk = clk_get(&pdev->dev, "lcd");
+ jzfb->ldclk = devm_clk_get(&pdev->dev, "lcd");
if (IS_ERR(jzfb->ldclk)) {
ret = PTR_ERR(jzfb->ldclk);
dev_err(&pdev->dev, "Failed to get lcd clock: %d\n", ret);
goto err_framebuffer_release;
}
- jzfb->lpclk = clk_get(&pdev->dev, "lcd_pclk");
+ jzfb->lpclk = devm_clk_get(&pdev->dev, "lcd_pclk");
if (IS_ERR(jzfb->lpclk)) {
ret = PTR_ERR(jzfb->lpclk);
dev_err(&pdev->dev, "Failed to get lcd pixel clock: %d\n", ret);
- goto err_put_ldclk;
+ goto err_framebuffer_release;
}
- jzfb->base = ioremap(mem->start, resource_size(mem));
+ jzfb->base = devm_ioremap(&pdev->dev, mem->start, resource_size(mem));
if (!jzfb->base) {
dev_err(&pdev->dev, "Failed to ioremap register memory region\n");
ret = -EBUSY;
- goto err_put_lpclk;
+ goto err_framebuffer_release;
}
platform_set_drvdata(pdev, jzfb);
@@ -693,7 +693,7 @@ static int __devinit jzfb_probe(struct platform_device *pdev)
ret = jzfb_alloc_devmem(jzfb);
if (ret) {
dev_err(&pdev->dev, "Failed to allocate video memory\n");
- goto err_iounmap;
+ goto err_framebuffer_release;
}
fb->fix = jzfb_fix;
@@ -734,12 +734,6 @@ err_free_devmem:
fb_dealloc_cmap(&fb->cmap);
jzfb_free_devmem(jzfb);
-err_iounmap:
- iounmap(jzfb->base);
-err_put_lpclk:
- clk_put(jzfb->lpclk);
-err_put_ldclk:
- clk_put(jzfb->ldclk);
err_framebuffer_release:
framebuffer_release(fb);
err_release_mem_region:
@@ -756,7 +750,6 @@ static int __devexit jzfb_remove(struct platform_device *pdev)
jz_gpio_bulk_free(jz_lcd_ctrl_pins, jzfb_num_ctrl_pins(jzfb));
jz_gpio_bulk_free(jz_lcd_data_pins, jzfb_num_data_pins(jzfb));
- iounmap(jzfb->base);
release_mem_region(jzfb->mem->start, resource_size(jzfb->mem));
fb_dealloc_cmap(&jzfb->fb->cmap);
@@ -764,9 +757,6 @@ static int __devexit jzfb_remove(struct platform_device *pdev)
platform_set_drvdata(pdev, NULL);
- clk_put(jzfb->lpclk);
- clk_put(jzfb->ldclk);
-
framebuffer_release(jzfb->fb);
return 0;
^ permalink raw reply related
* [PATCH 1/5] drivers/video/epson1355fb.c: use devm_ functions
From: Damien Cassou @ 2012-08-03 15:40 UTC (permalink / raw)
To: Christopher Hoover
Cc: kernel-janitors, Florian Tobias Schandinat, linux-fbdev,
linux-kernel
In-Reply-To: <1344008414-2894-1-git-send-email-damien.cassou@lifl.fr>
From: Damien Cassou <damien.cassou@lifl.fr>
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in the
probe function of a platform device and is only freed in the remove function.
Signed-off-by: Damien Cassou <damien.cassou@lifl.fr>
---
drivers/video/epson1355fb.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/epson1355fb.c b/drivers/video/epson1355fb.c
index 68b9b51..246da1e 100644
--- a/drivers/video/epson1355fb.c
+++ b/drivers/video/epson1355fb.c
@@ -592,12 +592,8 @@ static int epson1355fb_remove(struct platform_device *dev)
if (info) {
fb_dealloc_cmap(&info->cmap);
- if (info->screen_base)
- iounmap(info->screen_base);
framebuffer_release(info);
}
- release_mem_region(EPSON1355FB_FB_PHYS, EPSON1355FB_FB_LEN);
- release_mem_region(EPSON1355FB_REGS_PHYS, EPSON1355FB_REGS_LEN);
return 0;
}
@@ -608,15 +604,18 @@ static int __devinit epson1355fb_probe(struct platform_device *dev)
u8 revision;
int rc = 0;
- if (!request_mem_region(EPSON1355FB_REGS_PHYS, EPSON1355FB_REGS_LEN, "S1D13505 registers")) {
+ if (!devm_request_mem_region(&dev->dev, EPSON1355FB_REGS_PHYS,
+ EPSON1355FB_REGS_LEN,
+ "S1D13505 registers")) {
printk(KERN_ERR "epson1355fb: unable to reserve "
"registers at 0x%0x\n", EPSON1355FB_REGS_PHYS);
rc = -EBUSY;
goto bail;
}
- if (!request_mem_region(EPSON1355FB_FB_PHYS, EPSON1355FB_FB_LEN,
- "S1D13505 framebuffer")) {
+ if (!devm_request_mem_region(&dev->dev, EPSON1355FB_FB_PHYS,
+ EPSON1355FB_FB_LEN,
+ "S1D13505 framebuffer")) {
printk(KERN_ERR "epson1355fb: unable to reserve "
"framebuffer at 0x%0x\n", EPSON1355FB_FB_PHYS);
rc = -EBUSY;
@@ -638,7 +637,8 @@ static int __devinit epson1355fb_probe(struct platform_device *dev)
}
info->pseudo_palette = default_par->pseudo_palette;
- info->screen_base = ioremap(EPSON1355FB_FB_PHYS, EPSON1355FB_FB_LEN);
+ info->screen_base = devm_ioremap(&dev->dev, EPSON1355FB_FB_PHYS,
+ EPSON1355FB_FB_LEN);
if (!info->screen_base) {
printk(KERN_ERR "epson1355fb: unable to map framebuffer\n");
rc = -ENOMEM;
^ permalink raw reply related
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