* [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
* [PATCH 0/5] 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: <1343742860-16213-1-git-send-email-damien.cassou@lifl.fr>
These patches introduce devm_ functions in some video drivers. They have been
generated using Coccinelle (http://coccinelle.lip6.fr/) and the following
semantic patch:
virtual after_start
virtual returned
virtual returnedDup
virtual arg
virtual argDup
virtual all_args
virtual get
virtual nonull
virtual report
// ---------------------------------------------------------------------
// find functions
@plat depends on !after_start@
identifier i,pfn,rfn;
position p;
@@
struct platform_driver i@p = {
.probe = pfn,
.remove = (<+...rfn...+>),
};
// ---------------------------------------------------------------------
// set up iteration
@initialize:ocaml@
let reporting = ref false
type ret UseReturned | UseReturned2 of string | UseReturnedDup | UseReturnedNN
| UseArg | UseArgDup | UseArgNN | UseAllArgs | UseGet
let add pfn rfn alloc free devm_alloc file rule let it = new iteration() in
it#set_files [file];
it#add_virtual_rule After_start;
(match rule with
UseReturned -> it#add_virtual_rule Returned
| UseReturnedNN -> it#add_virtual_rule Returned; it#add_virtual_rule Nonull
| UseReturnedDup -> it#add_virtual_rule ReturnedDup
| UseReturned2(free) -> it#add_virtual_rule Returned;
it#add_virtual_identifier Second_free free
| UseArg -> it#add_virtual_rule Arg
| UseArgNN -> it#add_virtual_rule Arg; it#add_virtual_rule Nonull
| UseArgDup -> it#add_virtual_rule ArgDup
| UseAllArgs -> it#add_virtual_rule All_args
| UseGet -> it#add_virtual_rule Get);
if !reporting then it#add_virtual_rule Report;
if not (pfn="") then it#add_virtual_identifier Pfn pfn;
if not (rfn="") then it#add_virtual_identifier Rfn rfn;
if not (alloc="") then it#add_virtual_identifier Alloc alloc;
if not (free="") then it#add_virtual_identifier Free free;
if not (devm_alloc="") then it#add_virtual_identifier Devm_alloc devm_alloc;
it#register()
@script:ocaml depends on report && !after_start@
@@
reporting := true
@script:ocaml@
pfn << plat.pfn;
rfn << plat.rfn;
p << plat.p;
@@
let file = (List.hd p).file in
add pfn rfn "kmalloc" "kfree" "devm_kzalloc" file UseReturned;
add pfn rfn "kzalloc" "kfree" "devm_kzalloc" file UseReturned;
add pfn rfn "ioremap" "iounmap" "devm_ioremap" file UseReturned;
add pfn rfn "ioremap_nocache" "iounmap" "devm_ioremap_nocache" file
UseReturned;
add pfn rfn "clk_get" "clk_put" "devm_clk_get" file UseReturnedDup;
add pfn rfn "clk_get" "clk_put" "devm_clk_get_bad" file UseReturnedNN;
add pfn rfn "usb_get_phy" "usb_put_phy" "devm_usb_get_phy" file UseReturned;
add pfn rfn "pinctrl_get" "pinctrl_put" "devm_pinctrl_get" file UseReturned;
add pfn rfn "pinctrl_get_select_default" "pinctrl_put"
"devm_pinctrl_get_select_default" file UseReturned;
add pfn rfn "regulator_get" "regulator_put" "devm_regulator_get"
file UseReturned;
add pfn rfn "regulator_bulk_get" "regulator_bulk_free"
"devm_regulator_bulk_get" file UseAllArgs;
add pfn rfn "gpio_request" "gpio_free" "devm_gpio_request" file UseArg;
add pfn rfn "gpio_request_one" "gpio_free" "devm_gpio_request_one" file UseArg;
(*
add pfn rfn "request_irq" "free_irq" "devm_request_irq" file UseArg;
add pfn rfn "request_threaded_irq" "free_irq" "devm_request_threaded_irq" file
UseArg;
*)
add pfn rfn "dma_alloc_coherent" "dma_free_coherent" "dmam_alloc_coherent"
file UseReturnedDup;
add pfn rfn "dma_alloc_noncoherent" "dma_free_noncoherent"
"dmam_alloc_noncoherent" file UseReturnedDup;
add pfn rfn "dma_alloc_coherent" "dma_free_coherent" "dmam_alloc_coherent_bad"
file UseReturnedNN;
add pfn rfn "dma_alloc_noncoherent" "dma_free_noncoherent"
"dmam_alloc_noncoherent_bad" file UseReturnedNN;
(* several possibilities... *)
add pfn rfn "request_region" "release_region" "devm_request_region" file
UseGet;
add pfn rfn "request_mem_region" "release_mem_region"
"devm_request_mem_region" file UseGet;
add pfn rfn "request_region" "release_region" "devm_request_region" file
UseArg;
add pfn rfn "request_mem_region" "release_mem_region"
"devm_request_mem_region" file UseArg;
(* fix a bug at the same time *)
add pfn rfn "request_region" "release_resource" "devm_request_region" file
(UseReturned2("kfree"));
add pfn rfn "request_mem_region" "release_resource"
"devm_request_mem_region" file (UseReturned2("kfree"));
add pfn rfn "ioport_map" "ioport_unmap" "devm_ioport_map" file UseReturned
// ---------------------------------------------------------------------
// process the initial definition of the probe function
@preprobe@
identifier virtual.pfn;
position p;
@@
pfn@p(...) { ... }
@probe@
identifier pfn;
position preprobe.p;
@@
pfn@p(...) { ... }
@labelled_return@
identifier probe.pfn,l;
expression e;
@@
pfn(...) { <+... l: return e; ...+> }
// ---------------------------------------------------------------------
// transform functions where free uses the result
@prb depends on returned exists@
identifier probe.pfn,pdev,virtual.alloc,virtual.free,virtual.second_free;
expression x,y,e,a;
position p1,p2,p3;
type T1,T2,T3;
@@
pfn(struct platform_device *pdev) { ... when any
x = (T1)alloc@p1(a,...)
<... when strict
when any
when forall
(
y = x;
... when != y = e
when != &y
free@p2(...,(T2)y,...);
... when != x
when != y
second_free@p3(...,(T3)y,...);
|
y = x;
... when != y = e
when != &y
free@p2(...,(T2)y,...);
|
free@p2(...,(T2)x,...);
... when != x
second_free@p3(...,(T3)x,...);
|
free@p2(...,(T2)x,...);
)
...>
}
@script:ocaml@
a << prb.a;
@@
if a = "NULL" then Coccilib.include_match false
@reme exists@
identifier virtual.rfn,virtual.free;
expression prb.x,prb.y;
type T;
@@
rfn(...) { ... free(...,(T)\(x\|y\),...); ... }
@rem depends on reme@
identifier virtual.rfn,virtual.free,virtual.second_free;
expression prb.x,prb.y;
position p4,p5;
type T,T1;
@@
rfn(...) {
<... when strict
(
free@p4(...,(T)\(x\|y\),...);
... when != x
second_free@p5(...,(T1)\(x\|y\),...);
|
free@p4(...,(T)\(x\|y\),...);
)
...>
}
@bad@
identifier virtual.free;
expression prb.x,prb.y;
position p != {prb.p2,rem.p4};
type T;
@@
free@p(...,(T)\(x\|y\),...)
@modif depends on rem && !bad && !report@
expression x;
identifier prb.pdev,virtual.alloc,virtual.free,virtual.devm_alloc;
identifier virtual.second_free;
expression list args;
position prb.p1,prb.p2,prb.p3,rem.p4,rem.p5;
type T;
@@
(
- free@p2(...);
|
- second_free@p3(...);
|
- free@p4(...);
|
- second_free@p5(...);
|
x - alloc@p1(
+ devm_alloc(&pdev->dev,
args)
|
x - (T)alloc@p1(
+ (T)devm_alloc(&pdev->dev,
args)
)
@script:python depends on rem && !bad && report@
p1 << prb.p1;
alloc << virtual.devm_alloc;
@@
msg = "WARNING opportunity for %s" % (alloc)
coccilib.report.print_report(p1[0], msg)
// ---------------------------------------------------------------------
// transform functions where free uses the result
// special case for clk where don't add &pdev->dev
@prbdup depends on returnedDup exists@
identifier probe.pfn,pdev,virtual.alloc,virtual.free,virtual.second_free;
expression x,y,e;
expression list args;
position p1,p2,p3;
type T1,T2,T3;
@@
pfn(struct platform_device *pdev) { ... when any
x = (T1)alloc@p1(&pdev->dev,args)
<... when strict
when any
when forall
(
y = x;
... when != y = e
when != &y
free@p2(...,(T2)y,...);
... when != x
when != y
second_free@p3(...,(T3)y,...);
|
y = x;
... when != y = e
when != &y
free@p2(...,(T2)y,...);
|
free@p2(...,(T2)x,...);
... when != x
second_free@p3(...,(T3)x,...);
|
free@p2(...,(T2)x,...);
)
...>
}
@remdupe exists@
identifier virtual.rfn,virtual.free;
expression prbdup.x,prbdup.y;
type T;
@@
rfn(...) { ... free(...,(T)\(x\|y\),...); ... }
@remdup depends on remdupe@
identifier virtual.rfn,virtual.free,virtual.second_free;
expression prbdup.x,prbdup.y;
position p4,p5;
type T,T1;
@@
rfn(...) {
<... when strict
(
free@p4(...,(T)\(x\|y\),...);
... when != x
second_free@p5(...,(T1)\(x\|y\),...);
|
free@p4(...,(T)\(x\|y\),...);
)
...>
}
@baddup@
identifier virtual.free;
expression prbdup.x,prbdup.y;
position p != {prbdup.p2,remdup.p4};
type T;
@@
free@p(...,(T)\(x\|y\),...)
@modifdup depends on remdup && !baddup && !report@
expression x;
identifier virtual.alloc,virtual.free,virtual.devm_alloc;
identifier virtual.second_free;
expression list args;
position prbdup.p1,prbdup.p2,prbdup.p3,remdup.p4,remdup.p5;
type T;
@@
(
- free@p2(...);
|
- second_free@p3(...);
|
- free@p4(...);
|
- second_free@p5(...);
|
x - alloc@p1
+ devm_alloc
(args)
|
x - (T)alloc@p1
+ (T)devm_alloc
(args)
)
@script:python depends on remdup && !baddup && report@
p1 << prbdup.p1;
alloc << virtual.devm_alloc;
@@
msg = "WARNING opportunity for %s" % (alloc)
coccilib.report.print_report(p1[0], msg)
// ---------------------------------------------------------------------
// transform functions where free uses the first argument
@prbx depends on arg exists@
identifier probe.pfn,pdev,virtual.alloc,virtual.free;
expression x,y,e;
expression list args;
position p1,p2;
@@
pfn(struct platform_device *pdev) { ... when any
alloc@p1(x,args)
<... when strict
when any
when forall
(
y = x;
... when != y = e
when != &y
free@p2(y,...);
|
free@p2(x,...)
)
...>
}
@script:ocaml@
x << prbx.x;
@@
if x = "NULL" then Coccilib.include_match false
@remxe exists@
identifier virtual.rfn, virtual.free;
expression prbx.x,prbx.y;
@@
rfn(...) { ... free(\(x\|y\),...); ... }
@remx depends on remxe@
identifier virtual.rfn, virtual.free;
expression prbx.x,prbx.y;
position p3;
@@
rfn(...) {
<... when strict
free@p3(\(x\|y\),...)
...>
}
@badx@
identifier virtual.free;
expression prbx.x,prbx.y;
position p != {prbx.p2,remx.p3};
@@
free@p(\(x\|y\),...)
@modifx depends on remx && !badx && !report@
expression x;
identifier prbx.pdev,virtual.alloc,virtual.free,virtual.devm_alloc;
expression list args;
position prbx.p1,prbx.p2,remx.p3;
@@
(
- free@p2(...);
|
- free@p3(...);
|
- alloc@p1(
+ devm_alloc(&pdev->dev,
x,args)
)
@script:python depends on remx && !badx && report@
p1 << prbx.p1;
alloc << virtual.devm_alloc;
@@
msg = "WARNING opportunity for %s" % (alloc)
coccilib.report.print_report(p1[0], msg)
// ---------------------------------------------------------------------
// transform functions where free uses the first argument
@prbxdup depends on argDup exists@
identifier probe.pfn,pdev,virtual.alloc,virtual.free;
expression y,e;
expression list args;
position p1,p2;
@@
pfn(struct platform_device *pdev) { ... when any
alloc@p1(&pdev->dev,args)
<... when strict
when any
when forall
(
y = &pdev->dev;
... when != y = e
when != &y
free@p2(y,...);
|
free@p2(&pdev->dev,...)
)
...>
}
@remxedup exists@
identifier virtual.rfn, virtual.free, prbxdup.pdev;
expression prbxdup.y;
@@
rfn(...) { ... free(\(&pdev->dev\|y\),...); ... }
@remxdup depends on remxedup@
identifier virtual.rfn, virtual.free, prbxdup.pdev;
expression prbxdup.y;
position p3;
@@
rfn(...) {
<... when strict
free@p3(\(&pdev->dev\|y\),...)
...>
}
@badxdup@
identifier virtual.free,prbxdup.pdev;
expression prbxdup.y;
position p != {prbxdup.p2,remxdup.p3};
@@
free@p(\(&pdev->dev\|y\),...)
@modifxdup depends on remxdup && !badxdup && !report@
identifier virtual.alloc,virtual.free,virtual.devm_alloc;
expression list args;
position prbxdup.p1,prbxdup.p2,remxdup.p3;
@@
(
- free@p2(...);
|
- free@p3(...);
|
- alloc@p1
+ devm_alloc
(args)
)
@script:python depends on remxdup && !badxdup && report@
p1 << prbxdup.p1;
alloc << virtual.devm_alloc;
@@
msg = "WARNING opportunity for %s" % (alloc)
coccilib.report.print_report(p1[0], msg)
// ---------------------------------------------------------------------
// transform functions where free uses all arguments
@prbax depends on all_args exists@
identifier probe.pfn,pdev,virtual.alloc,virtual.free;
expression list x;
position p1,p2;
@@
pfn(struct platform_device *pdev) { ... when any
alloc@p1(x)
<... when strict
when any
when forall
free@p2(x)
...>
}
@remaxe exists@
identifier virtual.rfn, virtual.free;
expression list prbax.x;
@@
rfn(...) { ... free(x); ... }
@remax depends on remaxe@
identifier virtual.rfn, virtual.free;
expression list prbax.x;
position p3;
@@
rfn(...) {
<... when strict
free@p3(x)
...>
}
@badax@
identifier virtual.free;
expression list prbax.x;
position p != {prbax.p2,remax.p3};
@@
free@p(x)
@modifax depends on remax && !badax && !report@
identifier prbax.pdev,virtual.alloc,virtual.free,virtual.devm_alloc;
expression list x;
position prbax.p1,prbax.p2,remax.p3;
@@
(
- free@p2(...);
|
- free@p3(...);
|
- alloc@p1(
+ devm_alloc(&pdev->dev,
x)
)
@script:python depends on remax && !badax && report@
p1 << prbax.p1;
alloc << virtual.devm_alloc;
@@
msg = "WARNING opportunity for %s" % (alloc)
coccilib.report.print_report(p1[0], msg)
// ---------------------------------------------------------------------
// transform functions where free uses the result of platform_get_resource
@prbg depends on get exists@
identifier probe.pfn,pdev,virtual.alloc,virtual.free;
expression x,y,e;
expression list args;
position p1,p2;
@@
pfn(struct platform_device *pdev) { ... when any
alloc@p1(x,args)
<... when strict
when any
when forall
(
y = x;
... when != y = e
when != &y
free@p2(y,...);
|
free@p2(x,...)
)
...>
}
@remge exists@
identifier virtual.rfn, virtual.free;
identifier z;
identifier pdev;
expression e,n;
@@
rfn(struct platform_device *pdev) { ... when any
z = platform_get_resource(pdev, IORESOURCE_MEM, n)
... when != z = e
when != &z
free(z->start,...)
...
}
@remg depends on remge@
identifier virtual.rfn, virtual.free;
identifier z;
identifier pdev;
position p3;
expression e,n;
@@
rfn(struct platform_device *pdev) {
<... when strict
z = platform_get_resource(pdev, IORESOURCE_MEM, n)
... when strict
when != z = e
when != &z
free@p3(z->start,...)
...>
}
@badg@
identifier virtual.free;
position p != {prbg.p2,remg.p3};
@@
free@p(...)
@modifg depends on remg && !badg && !report@
expression x;
identifier prbg.pdev,virtual.alloc,virtual.free,virtual.devm_alloc;
expression list args;
position prbg.p1,prbg.p2,remg.p3;
@@
(
- free@p2(...);
|
- free@p3(...);
|
- alloc@p1(
+ devm_alloc(&pdev->dev,
x,args)
)
@script:python depends on remg && !badg && report@
p1 << prbg.p1;
alloc << virtual.devm_alloc;
@@
msg = "WARNING opportunity for %s" % (alloc)
coccilib.report.print_report(p1[0], msg)
// ---------------------------------------------------------------------
// cleanup, if the drvdata was only used to enable the free
// probably only relevant for kmalloc/kzalloc
@dclean depends on modif || modifdup || modifx || modifxdup || modifax || modifg@
identifier virtual.rfn, pdev, i;
type T;
@@
rfn(struct platform_device *pdev) { ...
(
- T i = platform_get_drvdata(pdev);
|
- T i = dev_get_drvdata(&pdev->drv);
|
- T i;
... when != i
(
- i = platform_get_drvdata(pdev);
|
- i = dev_get_drvdata(&pdev->drv);
)
)
... when != i
}
@rclean depends on modif || modifdup || modifx || modifxdup || modifax || modifg@
identifier virtual.rfn, pdev, i;
type T;
@@
rfn(struct platform_device *pdev) { ...
(
- T i = platform_get_resource(pdev,...);
|
- T i;
... when != i
- i = platform_get_resource(pdev,...);
)
... when != i
}
// ---------------------------------------------------------------------
// cleanup empty ifs, etc
@depends on modif || modifdup || modifx || modifxdup || modifax || modifg@
identifier probe.pfn;
@@
pfn(...) { <...
- if (...) {}
...> }
@depends on modif || modifdup || modifx || modifxdup || modifax || modifg@
identifier virtual.rfn;
@@
rfn(...) { <...
- if (...) {}
...> }
@depends on modif || modifdup || modifx || modifxdup || modifax || modifg@
identifier probe.pfn;
expression ret,e;
@@
pfn(...) { <...
+ return
- ret e;
- return ret;
...> }
@depends on modif || modifdup || modifx || modifxdup || modifax || modifg@
identifier virtual.rfn;
expression ret,e;
@@
rfn(...) { <...
+ return
- ret e;
- return ret;
...> }
// ---------------------------------------------------------------------
// this is likely to leave dead code, if l: is preceded by a return
// because we are control-flow based, there is no way to match on that
@depends on labelled_return && (modif || modifdup || modifx || modifxdup || modifax || modifg)@
identifier l,l1,l2;
expression e;
statement S;
identifier probe.pfn;
identifier i;
statement S1,S2;
@@
pfn(...) { <...
- goto l;
+ goto l2;
...
-l:
<... when != S
when any
l1:
...>
l2:
(
(<+...i...+>);
|
if (...) S1 else S2
|
while (...) S1
|
for (...;...;...) S1
|
return e;
)
...> }
@depends on !labelled_return && (modif || modifdup || modifx || modifxdup || modifax || modifg)@
identifier l,l1,l2;
expression e;
statement S;
identifier probe.pfn;
identifier i;
statement S1,S2;
@@
pfn(...) { <...
(
- goto l;
+ goto l2;
...
-l:
<... when != S
when any
l1:
...>
l2:
(
(<+...i...+>);
|
if (...) S1 else S2
|
while (...) S1
|
for (...;...;...) S1
)
|
- goto l;
+ return e;
...
-l:
<... when != S
when any
l1:
...>
return e;
)
...> }
@depends on !labelled_return && (modif || modifdup || modifx || modifxdup || modifax || modifg)@
expression e1,e2;
identifier probe.pfn;
@@
pfn(...) { <...
-e1 = e2;
-return e1;
+return e2;
...> }
^ permalink raw reply
* Re: [PATCH v2] of: Add videomode helper
From: Sascha Hauer @ 2012-08-03 7:38 UTC (permalink / raw)
To: Stephen Warren
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: <501AD68C.1000904-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
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
?
>
> This node appears to describe a video mode, not a display, hence the
> node name seems wrong.
>
> Many displays can support multiple different video modes. As mentioned
> elsewhere, properties like display width/height are properties of the
> display not the mode.
>
> So, I might expect something more like the following (various overhead
> properties like reg/#address-cells etc. elided for simplicity):
>
> disp: display {
> width-mm = <...>;
> height-mm = <...>;
> modes {
> mode@0 {
> /* 1920x1080p24 */
> clock = <52000000>;
> xres = <1920>;
> yres = <1080>;
> left-margin = <25>;
> right-margin = <25>;
> hsync-len = <25>;
> lower-margin = <2>;
> upper-margin = <2>;
> vsync-len = <2>;
> hsync-active-high;
> };
> mode@1 {
> };
> };
> };
Ok, we can do this.
>
> display-connector {
> display = <&disp>;
> // interface-specific properties such as pixel format here
> };
>
> Finally, have you considered just using an EDID instead of creating
> something custom? I know that creating an EDID is harder than writing a
> few simple properties into a DT, but EDIDs have the following advantages:
I have considered using EDID and I also tried it. It's painful. There
are no (open) tools available for creating EDID. That's something we
could change of course. Then when generating a devicetree there is
always an extra step involved creating the EDID blob. Once the EDID
blob is in devicetree it is not parsable anymore by mere humans, so
to see what we've got there is another tool involved to generate a
readable form again.
>
> 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.
>
> 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;
}
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: [RFC][PATCH v3 1/3] runtime interpreted power sequences
From: Alex Courbot @ 2012-08-03 1:15 UTC (permalink / raw)
To: Mark Brown
Cc: Stephen Warren, Stephen Warren, Simon Glass, Grant Likely,
Rob Herring, Greg Kroah-Hartman, 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,
Thierry Reding
In-Reply-To: <20120802181111.GM4537-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
> On Thu, Aug 02, 2012 at 10:21:57AM +0200, Thierry Reding wrote:
>> On Thu, Aug 02, 2012 at 05:00:13PM +0900, Alex Courbot wrote:
>
>>> The problem is, how do we turn these phandles into the resource of
>>> interest. The type of the resource can be infered by the name of the
>>> property. The hard part is resolving the resource from the phandle -
>>> it seems like the API just does not allow to do this. GPIO has
>>> of_get_named_gpio, but AFAIK there are no equivalent for regulator
>>> consumer and PWM: the only way to use the DT with them is through
>>> get_regulator and get_pwm which work at the device level.
>
>>> Or is there a way that I overlooked?
>
>> No, you are right. Perhaps we should add exported functions that do the
>> equivalent of of_pwm_request() or the regulator_dev_lookup() and
>> of_get_regulator() pair.
>
> 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.
Alex.
^ permalink raw reply
* Re: viafb on Clevo M5x0V laptop (+VT1631L)
From: Ondrej Zary @ 2012-08-02 21:13 UTC (permalink / raw)
To: Florian Tobias Schandinat; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <501AE71A.80903@gmx.de>
On Thursday 02 August 2012 22:46:18 Florian Tobias Schandinat wrote:
> Hi Ondrej,
>
> On 08/02/2012 06:03 PM, Ondrej Zary wrote:
> > Hello,
> > I've got a Clevo M5x0V laptop which has VIA PM800 chipset (1106:3118) and
> > 1280x768 LCD panel connected using VT1631L LVDS transmitter. There's a
> > schematic of this laptop available on the web which shows that VT1631L's
> > I2C port is not connected anywhere...
> >
> > viafb does not work properly - LCD panel (and backlight) is turned off
> > upon module load and there's 640x480 signal on VGA connector (even when
> > monitor was not connected during module load).
>
> Yes, that's the default (640x480-60 on the VGA output) that VIA selected
> when they wrote the module. I tried to add some auto detect mechanism,
> but I guess in your case it wouldn't help, even if it were complete. The
> traditional way to use viafb is via module parameters as described in
> Documentation/fb/viafb.txt
> In your case something like this might work:
> viafb_mode\x1280x768 viafb_lcd_panel_id=3 viafb_active_dev=LCD
Thank you very much, it works with these parameters! Looks like viafb can wake
up the chip from S3, only the colors are messed up (X<->VT switch fixes
that).
> Additionally it might be required to add viafb_lcd_port with any of
> DVP0, DVP1, DFP_HIGHLOW, DFP_HIGH, DFP_LOW.
>
> > Looking at the code, there's almost nothing for VT1631. What needs to be
> > done in order for the LCD to work? Xorg seems to work using openchrome
> > (but it is not able to restore the card on resume from S3):
> > (II) CHROME(0): Unable to get panel size from EDID. Return code: 0
> > (II) CHROME(0): ViaPanelGetNativeModeFromScratchPad
> > (II) CHROME(0): Native Panel Resolution is 1280x768
>
> Interesting that they get the panel resolution from the scratch pad. The
> official documentation does not contain any useful information about it
> (and openchrome didn't work on any of my LCD devices that I tested,
> hence I didn't care whether they did have any code in that area)
> Maybe the above module parameters will help you, otherwise more
> investigation will be required.
Looking at openchrome and viafb code - the code is already present in viafb in
fp_id_to_vindex() function in lcd.c. It even finds correct panel_id for me
(3). But it looks like that the result is not used.
--
Ondrej Zary
^ permalink raw reply
* Re: viafb on Clevo M5x0V laptop (+VT1631L)
From: Florian Tobias Schandinat @ 2012-08-02 20:46 UTC (permalink / raw)
To: Ondrej Zary; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <201208022003.28404.linux@rainbow-software.org>
Hi Ondrej,
On 08/02/2012 06:03 PM, Ondrej Zary wrote:
> Hello,
> I've got a Clevo M5x0V laptop which has VIA PM800 chipset (1106:3118) and
> 1280x768 LCD panel connected using VT1631L LVDS transmitter. There's a
> schematic of this laptop available on the web which shows that VT1631L's I2C
> port is not connected anywhere...
>
> viafb does not work properly - LCD panel (and backlight) is turned off upon
> module load and there's 640x480 signal on VGA connector (even when monitor
> was not connected during module load).
Yes, that's the default (640x480-60 on the VGA output) that VIA selected
when they wrote the module. I tried to add some auto detect mechanism,
but I guess in your case it wouldn't help, even if it were complete. The
traditional way to use viafb is via module parameters as described in
Documentation/fb/viafb.txt
In your case something like this might work:
viafb_mode\x1280x768 viafb_lcd_panel_id=3 viafb_active_dev=LCD
Additionally it might be required to add viafb_lcd_port with any of
DVP0, DVP1, DFP_HIGHLOW, DFP_HIGH, DFP_LOW.
> Looking at the code, there's almost nothing for VT1631. What needs to be done
> in order for the LCD to work? Xorg seems to work using openchrome (but it is
> not able to restore the card on resume from S3):
> (II) CHROME(0): Unable to get panel size from EDID. Return code: 0
> (II) CHROME(0): ViaPanelGetNativeModeFromScratchPad
> (II) CHROME(0): Native Panel Resolution is 1280x768
Interesting that they get the panel resolution from the scratch pad. The
official documentation does not contain any useful information about it
(and openchrome didn't work on any of my LCD devices that I tested,
hence I didn't care whether they did have any code in that area)
Maybe the above module parameters will help you, otherwise more
investigation will be required.
Best regards,
Florian Tobias Schandinat
>
>
> This is from kernel 3.5 with VIAFB_DEBUG and VIAFB_WARN enabled:
>
> [ 153.051061] VIA Graphics Integration Chipset framebuffer 2.4 initializing
> [ 153.051765] viafb 0000:01:00.0: power state changed by ACPI to D0
> [ 153.051773] viafb 0000:01:00.0: power state changed by ACPI to D0
> [ 153.053535] Device ID = 3259
> [ 153.053553] FB Size = 4000
> [ 153.059984] VIAFB PCI Probe!!
> [ 153.060044] viafb: Probing I2C bus 0x26
> [ 153.092761] viafb: Probing I2C bus 0x31
> [ 155.588019] viafb: Probing I2C bus 0x2C
> [ 155.619016] viafb: Finished I2C bus probing
> [ 155.619021] parse_lcd_port: viafb_lcd_port:,interface:0
> [ 155.619023] parse_dvi_port: viafb_dvi_port:,interface:0
> [ 155.713224] TMDS Chip = 0
> [ 155.713227] viafb_init_dvi_size()
> [ 155.713229] viafb_dvi_sense!!
> [ 155.714415] viafb_dvi_query_EDID!!
> [ 155.716820] viafb_dvi_query_EDID!!
> [ 155.719179] viafb_lvds_identify_vt1636.
> [ 155.812018] viafb_lvds_identify_vt1636.
> [ 155.814383] viafb_init_lcd_size()
> [ 155.814384] fp_get_panel_id()
> [ 155.814387] LVDS Chip = 0
> [ 155.814389] LVDS1 output_interface = 6
> [ 155.814391] LVDS2 output_interface = 6
> [ 155.814405] viafb_check_var!
> [ 155.815250] fbcon: Via (fb0) is primary device
> [ 155.815257] viafb_open!
> [ 155.818608] viafb_set_par!
> [ 155.818720] via_set_primary_pitch(0x00000A00)
> [ 155.818723] via_set_secondary_pitch(0x00000A00)
> [ 155.818727] via_set_primary_color_depth(24)
> [ 155.818730] via_set_secondary_color_depth(24)
> [ 155.818788] viafb_pan_display, address = 0
> [ 155.818789] via_set_primary_address(0x00000000)
> [ 155.818793] via_set_secondary_address(0x00000000)
> [ 155.819020] viafb_pan_display, address = 0
> [ 155.819021] via_set_primary_address(0x00000000)
> [ 155.819025] via_set_secondary_address(0x00000000)
> [ 155.819044] viafb 2D engine: imageblit
> ...many imageblits...
> [ 155.826516] Console: switching to colour frame buffer device 80x30
> [ 155.826522] viafb_pan_display, address = 0
> [ 155.826523] via_set_primary_address(0x00000000)
> [ 155.826527] via_set_secondary_address(0x00000000)
> ...many imageblits...
> [ 155.833889] fb0: Via frame buffer device 640x480-32bpp
>
>
^ 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