* [PATCH] fbcon: Clean up fbcon data in fb_info on FB_EVENT_FB_UNBIND with 0 fbs
From: Keith Packard @ 2014-01-20 21:31 UTC (permalink / raw)
To: linux-kernel, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-fbdev
Cc: Keith Packard
In-Reply-To: <1387498677-25653-1-git-send-email-keithp@keithp.com>
When FB_EVENT_FB_UNBIND is sent, fbcon has two paths, one path taken
when there is another frame buffer to switch any affected vcs to and
another path when there isn't.
In the case where there is another frame buffer to use,
fbcon_fb_unbind calls set_con2fb_map to remap all of the affected vcs
to the replacement frame buffer. set_con2fb_map will eventually call
con2fb_release_oldinfo when the last vcs gets unmapped from the old
frame buffer.
con2fb_release_oldinfo frees the fbcon data that is hooked off of the
fb_info structure, including the cursor timer.
In the case where there isn't another frame buffer to use,
fbcon_fb_unbind simply calls fbcon_unbind, which doesn't clear the
con2fb_map or free the fbcon data hooked from the fb_info
structure. In particular, it doesn't stop the cursor blink timer. When
the fb_info structure is then freed, we end up with a timer queue
pointing into freed memory and "bad things" start happening.
This patch first changes con2fb_release_oldinfo so that it can take a
NULL pointer for the new frame buffer, but still does all of the
deallocation and cursor timer cleanup.
Finally, the patch tries to replicate some of what set_con2fb_map does
by clearing the con2fb_map for the affected vcs and calling the
modified con2fb_release_info function to clean up the fb_info structure.
Signed-off-by: Keith Packard <keithp@keithp.com>
---
drivers/video/console/fbcon.c | 27 +++++++++++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index cd8a802..9297a9b 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -759,7 +759,7 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
newinfo in an undefined state. Thus, a call to
fb_set_par() may be needed for the newinfo.
*/
- if (newinfo->fbops->fb_set_par) {
+ if (newinfo && newinfo->fbops->fb_set_par) {
ret = newinfo->fbops->fb_set_par(newinfo);
if (ret)
@@ -3028,8 +3028,31 @@ static int fbcon_fb_unbind(int idx)
if (con2fb_map[i] = idx)
set_con2fb_map(i, new_idx, 0);
}
- } else
+ } else {
+ struct fb_info *info = registered_fb[idx];
+
+ /* This is sort of like set_con2fb_map, except it maps
+ * the consoles to no device and then releases the
+ * oldinfo to free memory and cancel the cursor blink
+ * timer. I can imagine this just becoming part of
+ * set_con2fb_map where new_idx is -1
+ */
+ for (i = first_fb_vc; i <= last_fb_vc; i++) {
+ if (con2fb_map[i] = idx) {
+ con2fb_map[i] = -1;
+ if (!search_fb_in_map(idx)) {
+ ret = con2fb_release_oldinfo(vc_cons[i].d,
+ info, NULL, i,
+ idx, 0);
+ if (ret) {
+ con2fb_map[i] = idx;
+ return ret;
+ }
+ }
+ }
+ }
ret = fbcon_unbind();
+ }
return ret;
}
--
1.8.5.2
^ permalink raw reply related
* Re: [PATCH 13/15] fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
From: Laurent Pinchart @ 2014-01-20 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DD06CB.8050606@ti.com>
[-- Attachment #1: Type: text/plain, Size: 913 bytes --]
Hi Tomi,
On Monday 20 January 2014 13:21:47 Tomi Valkeinen wrote:
> On 2014-01-19 23:01, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > The lcdc driver can be compiled without meram support. This is handled by
> > conditional compilation in include/video/sh_mobile_meram.h that defines
> > the
> > meram functions as stubs when meram support isn't selected.
> >
> > The problem comes from the combination of FB_SH_MOBILE_MERAM=m and
> > FB_SH_MOBILE_LCDC=y. The former makes the meram function non-stubs, while
> > the later makes the LCDC driver fail to link, as meram support is then
> > compiled as a module.
> >
> > How do you usually handle this ?
>
> I guess the easiest option is to make FB_SH_MOBILE_MERAM a bool, instead
> of tristate.
That's easy, but it would prevent meram support from being compiled as a
module when lcdc support is compiled as a module as well.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v2] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Shuah Khan @ 2014-01-20 15:27 UTC (permalink / raw)
To: Jingoo Han, 'Rafael J. Wysocki'
Cc: 'Richard Purdie', 'Florian Tobias Schandinat',
'Jean-Christophe PLAGNIOL-VILLARD',
'Tomi Valkeinen', 'Rafael J. Wysocki',
linux-fbdev, linux-kernel, 'Shuah Khan', Shuah Khan
In-Reply-To: <001f01cf157f$ca2e8530$5e8b8f90$%han@samsung.com>
On 01/19/2014 06:34 PM, Jingoo Han wrote:
> On Monday, January 20, 2014 12:37 AM, Rafael J. Wysocki wrote:
>> On Wednesday, November 14, 2040 04:27:17 AM Shuah Khan wrote:
>>> Convert drivers/video/backlight/class to use dev_pm_ops for power
>>> management and remove Legacy PM ops hooks. With this change, rtc class
>>> registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of
>>> Legacy class->suspend/resume. When __device_suspend() runs call-backs,
>>> it will find class->pm ops for the backlight class.
>>>
>>> Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
>>> Cc: Shuah Khan <shuahkhan@gmail.com>
>>
>> Can you please resend the patches that nobody took with CCs to
>> linux-pm@vger.kernel.org? If the original maintainers don't care, I'll be
>> able to pick those patches up then (if they look good).
>
> I already gave the comment, and am waiting v3 patch.
> However, Shuah Khan did not send the v3 patch yet.
>
> Currently, backlight subsystem patches go through mm-tree
> With my acked-by.
>
> Shuah Khan,
> Will you send the v3 patch? As I said, there is the typo in
> commit message. Please fix it.
> s/rtc class/backlight class
>
Rafael/Jingoo Han,
I did send the v3 patch with the typo fixed. Here is the link:
http://lkml.indiana.edu/hypermail/linux/kernel/1306.0/00219.html
This is a while back. I will rebase and res-test and send it.
thanks,
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658
^ permalink raw reply
* Re: [PATCH 13/15] fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
From: Tomi Valkeinen @ 2014-01-20 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22423852.GiH1NBjiii@avalon>
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
On 2014-01-19 23:01, Laurent Pinchart wrote:
> Hi Tomi,
> The lcdc driver can be compiled without meram support. This is handled by
> conditional compilation in include/video/sh_mobile_meram.h that defines the
> meram functions as stubs when meram support isn't selected.
>
> The problem comes from the combination of FB_SH_MOBILE_MERAM=m and
> FB_SH_MOBILE_LCDC=y. The former makes the meram function non-stubs, while the
> later makes the LCDC driver fail to link, as meram support is then compiled as
> a module.
>
> How do you usually handle this ?
I guess the easiest option is to make FB_SH_MOBILE_MERAM a bool, instead
of tristate.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH v2] backlight: turn backlight on/off when necessary
From: Liu Ying @ 2014-01-20 5:47 UTC (permalink / raw)
To: jg1.han; +Cc: linux-fbdev, linux-kernel, dri-devel, plagnioj, tomi.valkeinen
We don't have to turn backlight on/off everytime a blanking
or unblanking event comes because the backlight status may
have already been what we want. Another thought is that one
backlight device may be shared by multiple framebuffers. We
don't hope blanking one of the framebuffers may turn the
backlight off for all the other framebuffers, since they are
likely being active to display something. This patch adds
some logics to record each framebuffer's backlight usage to
determine the backlight device use count and whether the
backlight should be turned on or off. To be more specific,
only one unblank operation on a certain blanked framebuffer
may increase the backlight device's use count by one, while
one blank operation on a certain unblanked framebuffer may
decrease the use count by one, because the userspace is
likely to unblank a unblanked framebuffer or blank a blanked
framebuffer.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
v1 can be found at https://lkml.org/lkml/2013/5/30/139
v1->v2:
* Make the commit message be more specific about the condition
in which backlight device use count can be increased/decreased.
* Correct the setting for bd->props.fb_blank.
drivers/video/backlight/backlight.c | 28 +++++++++++++++++++++-------
include/linux/backlight.h | 6 ++++++
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 5d05555..42044be 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -34,13 +34,15 @@ static const char *const backlight_types[] = {
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
/* This callback gets called when something important happens inside a
* framebuffer driver. We're looking if that important event is blanking,
- * and if it is, we're switching backlight power as well ...
+ * and if it is and necessary, we're switching backlight power as well ...
*/
static int fb_notifier_callback(struct notifier_block *self,
unsigned long event, void *data)
{
struct backlight_device *bd;
struct fb_event *evdata = data;
+ int node = evdata->info->node;
+ int fb_blank = 0;
/* If we aren't interested in this event, skip it immediately ... */
if (event != FB_EVENT_BLANK && event != FB_EVENT_CONBLANK)
@@ -51,12 +53,24 @@ static int fb_notifier_callback(struct notifier_block *self,
if (bd->ops)
if (!bd->ops->check_fb ||
bd->ops->check_fb(bd, evdata->info)) {
- bd->props.fb_blank = *(int *)evdata->data;
- if (bd->props.fb_blank = FB_BLANK_UNBLANK)
- bd->props.state &= ~BL_CORE_FBBLANK;
- else
- bd->props.state |= BL_CORE_FBBLANK;
- backlight_update_status(bd);
+ fb_blank = *(int *)evdata->data;
+ if (fb_blank = FB_BLANK_UNBLANK &&
+ !bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = true;
+ if (!bd->use_count++) {
+ bd->props.state &= ~BL_CORE_FBBLANK;
+ bd->props.fb_blank = FB_BLANK_UNBLANK;
+ backlight_update_status(bd);
+ }
+ } else if (fb_blank != FB_BLANK_UNBLANK &&
+ bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = false;
+ if (!(--bd->use_count)) {
+ bd->props.state |= BL_CORE_FBBLANK;
+ bd->props.fb_blank = FB_BLANK_POWERDOWN;
+ backlight_update_status(bd);
+ }
+ }
}
mutex_unlock(&bd->ops_lock);
return 0;
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 5f9cd96..7264742 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -9,6 +9,7 @@
#define _LINUX_BACKLIGHT_H
#include <linux/device.h>
+#include <linux/fb.h>
#include <linux/mutex.h>
#include <linux/notifier.h>
@@ -104,6 +105,11 @@ struct backlight_device {
struct list_head entry;
struct device dev;
+
+ /* Multiple framebuffers may share one backlight device */
+ bool fb_bl_on[FB_MAX];
+
+ int use_count;
};
static inline void backlight_update_status(struct backlight_device *bd)
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2 0/4] video: mmp: add device tree suppport
From: Zhou Zhu @ 2014-01-20 1:58 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Zhou Zhu, linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Chao Xie, Guoqing Li
In-Reply-To: <1389698184-28761-1-git-send-email-zzhu3-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Hi, Tomi,
Looks there's no more comment now.
Would you please help to review this patch set and apply it also for
3.14 if possible?
Thank you very much!
On 01/14/2014 07:16 PM, Zhou Zhu wrote:
> This patch set is to add device tree support for mmp_disp.
> patch 1/2 are to remove clk_name configure in mach_info before.
> patch 3/4 are to add device tree support.
>
> change of v2:
> add patch to remove config of clk_name in mach_info
> use phandle to get path.
> runtime decision of dt usage.
> clean up to use node name directly.
>
> Zhou Zhu (4):
> arm: mmp: remove not used disp clk_name in ttc_dkb
> video: mmp: no need to get clk_name from mach_info
> video: mmp: add devm_mmp_get_path_by_phandle for DT
> video: mmp: add device tree support
>
> Documentation/devicetree/bindings/fb/mmp-disp.txt | 60 ++++++++
> arch/arm/mach-mmp/ttc_dkb.c | 1 -
> drivers/video/mmp/core.c | 35 +++++
> drivers/video/mmp/fb/mmpfb.c | 73 ++++++----
> drivers/video/mmp/hw/mmp_ctrl.c | 154 ++++++++++++++++-----
> include/video/mmp_disp.h | 3 +-
> 6 files changed, 268 insertions(+), 58 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/fb/mmp-disp.txt
>
--
Thanks, -Zhou
^ permalink raw reply
* Re: [PATCH v2] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Jingoo Han @ 2014-01-20 1:34 UTC (permalink / raw)
To: 'Rafael J. Wysocki', 'Shuah Khan'
Cc: 'Richard Purdie', 'Florian Tobias Schandinat',
'Jean-Christophe PLAGNIOL-VILLARD',
'Tomi Valkeinen', 'Rafael J. Wysocki',
linux-fbdev, linux-kernel, 'Shuah Khan',
'Jingoo Han'
In-Reply-To: <15798389.lgk83XnI1i@vostro.rjw.lan>
On Monday, January 20, 2014 12:37 AM, Rafael J. Wysocki wrote:
> On Wednesday, November 14, 2040 04:27:17 AM Shuah Khan wrote:
> > Convert drivers/video/backlight/class to use dev_pm_ops for power
> > management and remove Legacy PM ops hooks. With this change, rtc class
> > registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of
> > Legacy class->suspend/resume. When __device_suspend() runs call-backs,
> > it will find class->pm ops for the backlight class.
> >
> > Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
> > Cc: Shuah Khan <shuahkhan@gmail.com>
>
> Can you please resend the patches that nobody took with CCs to
> linux-pm@vger.kernel.org? If the original maintainers don't care, I'll be
> able to pick those patches up then (if they look good).
I already gave the comment, and am waiting v3 patch.
However, Shuah Khan did not send the v3 patch yet.
Currently, backlight subsystem patches go through mm-tree
With my acked-by.
Shuah Khan,
Will you send the v3 patch? As I said, there is the typo in
commit message. Please fix it.
s/rtc class/backlight class
Best regards,
Jingoo Han
> > ---
> >
> > v2: Updated changelog to correct device class.
> >
> > drivers/video/backlight/backlight.c | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> > index c74e7aa..0ffb251 100644
> > --- a/drivers/video/backlight/backlight.c
> > +++ b/drivers/video/backlight/backlight.c
> > @@ -208,7 +208,7 @@ static ssize_t backlight_show_actual_brightness(struct device *dev,
> >
> > static struct class *backlight_class;
> >
> > -static int backlight_suspend(struct device *dev, pm_message_t state)
> > +static int backlight_suspend(struct device *dev)
> > {
> > struct backlight_device *bd = to_backlight_device(dev);
> >
> > @@ -236,6 +236,9 @@ static int backlight_resume(struct device *dev)
> > return 0;
> > }
> >
> > +static SIMPLE_DEV_PM_OPS(backlight_class_dev_pm_ops, backlight_suspend,
> > + backlight_resume);
> > +
> > static void bl_device_release(struct device *dev)
> > {
> > struct backlight_device *bd = to_backlight_device(dev);
> > @@ -414,8 +417,7 @@ static int __init backlight_class_init(void)
> > }
> >
> > backlight_class->dev_attrs = bl_device_attributes;
> > - backlight_class->suspend = backlight_suspend;
> > - backlight_class->resume = backlight_resume;
> > + backlight_class->pm = &backlight_class_dev_pm_ops;
> > return 0;
> > }
> >
> >
^ permalink raw reply
* Re: [PATCH 13/15] fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
From: Laurent Pinchart @ 2014-01-19 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D8F14A.7030100@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]
Hi Tomi,
On Friday 17 January 2014 11:00:58 Tomi Valkeinen wrote:
> Hi,
>
> On 2014-01-08 10:30, Tomi Valkeinen wrote:
> > On 2014-01-07 17:15, Laurent Pinchart wrote:
> >> On Wednesday 11 December 2013 13:51:18 Laurent Pinchart wrote:
> >>> Hi Jean-Christophe and Tomi,
> >>>
> >>> Could you please pick this patch up for v3.14 ?
> >>
> >> Ping ?
> >
> > Queued for 3.14.
>
> I'll drop this patch, as it causes compile break (from kbuild test robot):
>
> All error/warnings:
>
> drivers/built-in.o: In function `sh_mobile_lcdc_pan':
> >> sh_mobile_lcdcfb.c:(.text+0x77373): undefined reference to
> `sh_mobile_meram_cache_update'
> drivers/built-in.o: In function `sh_mobile_lcdc_start':
> >> sh_mobile_lcdcfb.c:(.text+0x79320): undefined reference to
> `sh_mobile_meram_cache_free'
> >> sh_mobile_lcdcfb.c:(.text+0x79394): undefined reference to
> `sh_mobile_meram_cache_alloc'
> >> sh_mobile_lcdcfb.c:(.text+0x793d4): undefined reference to
> `sh_mobile_meram_cache_update'
> drivers/built-in.o: In function `sh_mobile_lcdc_stop':
> >> sh_mobile_lcdcfb.c:(.text+0x79616): undefined reference to
> `sh_mobile_meram_cache_free'
The lcdc driver can be compiled without meram support. This is handled by
conditional compilation in include/video/sh_mobile_meram.h that defines the
meram functions as stubs when meram support isn't selected.
The problem comes from the combination of FB_SH_MOBILE_MERAM=m and
FB_SH_MOBILE_LCDC=y. The former makes the meram function non-stubs, while the
later makes the LCDC driver fail to link, as meram support is then compiled as
a module.
How do you usually handle this ?
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v2] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Rafael J. Wysocki @ 2014-01-19 15:37 UTC (permalink / raw)
To: Shuah Khan
Cc: rpurdie, FlorianSchandinat, plagnioj, tomi.valkeinen,
rafael.j.wysocki, linux-fbdev, linux-kernel, shuahkhan
In-Reply-To: <2236505237-3336-1-git-send-email-shuah.kh@samsung.com>
On Wednesday, November 14, 2040 04:27:17 AM Shuah Khan wrote:
> Convert drivers/video/backlight/class to use dev_pm_ops for power
> management and remove Legacy PM ops hooks. With this change, rtc class
> registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of
> Legacy class->suspend/resume. When __device_suspend() runs call-backs,
> it will find class->pm ops for the backlight class.
>
> Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
> Cc: Shuah Khan <shuahkhan@gmail.com>
Can you please resend the patches that nobody took with CCs to
linux-pm@vger.kernel.org? If the original maintainers don't care, I'll be
able to pick those patches up then (if they look good).
Thanks!
> ---
>
> v2: Updated changelog to correct device class.
>
> drivers/video/backlight/backlight.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index c74e7aa..0ffb251 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -208,7 +208,7 @@ static ssize_t backlight_show_actual_brightness(struct device *dev,
>
> static struct class *backlight_class;
>
> -static int backlight_suspend(struct device *dev, pm_message_t state)
> +static int backlight_suspend(struct device *dev)
> {
> struct backlight_device *bd = to_backlight_device(dev);
>
> @@ -236,6 +236,9 @@ static int backlight_resume(struct device *dev)
> return 0;
> }
>
> +static SIMPLE_DEV_PM_OPS(backlight_class_dev_pm_ops, backlight_suspend,
> + backlight_resume);
> +
> static void bl_device_release(struct device *dev)
> {
> struct backlight_device *bd = to_backlight_device(dev);
> @@ -414,8 +417,7 @@ static int __init backlight_class_init(void)
> }
>
> backlight_class->dev_attrs = bl_device_attributes;
> - backlight_class->suspend = backlight_suspend;
> - backlight_class->resume = backlight_resume;
> + backlight_class->pm = &backlight_class_dev_pm_ops;
> return 0;
> }
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH 2/2] video: exynos: Fix S6E8AX0 LCD driver build error
From: Sachin Kamat @ 2014-01-17 11:13 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-2-git-send-email-sachin.kamat@linaro.org>
On 17 January 2014 15:52, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2014-01-17 06:32, Sachin Kamat wrote:
>> Enable S6E8AX0 LCD driver only if LCD_CLASS_DEVICE is a built-in driver.
>> Else we get the following errors due to missing symbols:
>> drivers/built-in.o: In function `s6e8ax0_probe':
>> :(.text+0x51aec): undefined reference to `lcd_device_register'
>> :(.text+0x51c44): undefined reference to `lcd_device_unregister'
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>> ---
>> drivers/video/exynos/Kconfig | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
>> index 976594d578a9..7e19b467b8f7 100644
>> --- a/drivers/video/exynos/Kconfig
>> +++ b/drivers/video/exynos/Kconfig
>> @@ -22,7 +22,8 @@ config EXYNOS_MIPI_DSI
>>
>> config EXYNOS_LCD_S6E8AX0
>> bool "S6E8AX0 MIPI AMOLED LCD Driver"
>> - depends on (EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE && LCD_CLASS_DEVICE)
>> + depends on EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE
>> + depends on (LCD_CLASS_DEVICE != m)
>
> Hmm, doesn't that say that LCD_CLASS_DEVICE can be y or n (i.e. != m),
> so it could be disabled also?
Yes you are right. Not sure how I got it right while testing. Thanks
for catching.
It should just be (LCD_CLASS_DEVICE = y).
Will resend.
--
With warm regards,
Sachin
^ permalink raw reply
* [PATCH v2] video: exynos: Fix S6E8AX0 LCD driver build error
From: Sachin Kamat @ 2014-01-17 11:12 UTC (permalink / raw)
To: linux-fbdev
Enable S6E8AX0 LCD driver only if LCD_CLASS_DEVICE is a built-in driver.
Else we get the following errors due to missing symbols:
drivers/built-in.o: In function `s6e8ax0_probe':
:(.text+0x51aec): undefined reference to `lcd_device_register'
:(.text+0x51c44): undefined reference to `lcd_device_unregister'
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/exynos/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
index 976594d578a9..eb6f2b059821 100644
--- a/drivers/video/exynos/Kconfig
+++ b/drivers/video/exynos/Kconfig
@@ -22,7 +22,8 @@ config EXYNOS_MIPI_DSI
config EXYNOS_LCD_S6E8AX0
bool "S6E8AX0 MIPI AMOLED LCD Driver"
- depends on (EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE && LCD_CLASS_DEVICE)
+ depends on EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE
+ depends on (LCD_CLASS_DEVICE = y)
default n
help
If you have an S6E8AX0 MIPI AMOLED LCD Panel, say Y to enable its
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/2] video: exynos: Fix S6E8AX0 LCD driver build error
From: Tomi Valkeinen @ 2014-01-17 10:22 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-2-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
On 2014-01-17 06:32, Sachin Kamat wrote:
> Enable S6E8AX0 LCD driver only if LCD_CLASS_DEVICE is a built-in driver.
> Else we get the following errors due to missing symbols:
> drivers/built-in.o: In function `s6e8ax0_probe':
> :(.text+0x51aec): undefined reference to `lcd_device_register'
> :(.text+0x51c44): undefined reference to `lcd_device_unregister'
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/video/exynos/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
> index 976594d578a9..7e19b467b8f7 100644
> --- a/drivers/video/exynos/Kconfig
> +++ b/drivers/video/exynos/Kconfig
> @@ -22,7 +22,8 @@ config EXYNOS_MIPI_DSI
>
> config EXYNOS_LCD_S6E8AX0
> bool "S6E8AX0 MIPI AMOLED LCD Driver"
> - depends on (EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE && LCD_CLASS_DEVICE)
> + depends on EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE
> + depends on (LCD_CLASS_DEVICE != m)
Hmm, doesn't that say that LCD_CLASS_DEVICE can be y or n (i.e. != m),
so it could be disabled also?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Sachin Kamat @ 2014-01-17 9:33 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-1-git-send-email-sachin.kamat@linaro.org>
On 17 January 2014 14:33, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2014-01-17 06:32, Sachin Kamat wrote:
>> Exynos is now a DT only platform. Hence there is no need
>> for an explicit OF dependency. Remove it.
>
> Is Exynos a DT-only platform in v3.13? Or only in v3.14?
It has been so since v3.11.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Tomi Valkeinen @ 2014-01-17 9:03 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-1-git-send-email-sachin.kamat@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
On 2014-01-17 06:32, Sachin Kamat wrote:
> Exynos is now a DT only platform. Hence there is no need
> for an explicit OF dependency. Remove it.
Is Exynos a DT-only platform in v3.13? Or only in v3.14?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 13/15] fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
From: Tomi Valkeinen @ 2014-01-17 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52CD0CBB.3070801@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]
Hi,
On 2014-01-08 10:30, Tomi Valkeinen wrote:
> On 2014-01-07 17:15, Laurent Pinchart wrote:
>> On Wednesday 11 December 2013 13:51:18 Laurent Pinchart wrote:
>>> Hi Jean-Christophe and Tomi,
>>>
>>> Could you please pick this patch up for v3.14 ?
>>
>> Ping ?
>
> Queued for 3.14.
I'll drop this patch, as it causes compile break (from kbuild test robot):
All error/warnings:
drivers/built-in.o: In function `sh_mobile_lcdc_pan':
>> sh_mobile_lcdcfb.c:(.text+0x77373): undefined reference to
`sh_mobile_meram_cache_update'
drivers/built-in.o: In function `sh_mobile_lcdc_start':
>> sh_mobile_lcdcfb.c:(.text+0x79320): undefined reference to
`sh_mobile_meram_cache_free'
>> sh_mobile_lcdcfb.c:(.text+0x79394): undefined reference to
`sh_mobile_meram_cache_alloc'
>> sh_mobile_lcdcfb.c:(.text+0x793d4): undefined reference to
`sh_mobile_meram_cache_update'
drivers/built-in.o: In function `sh_mobile_lcdc_stop':
>> sh_mobile_lcdcfb.c:(.text+0x79616): undefined reference to
`sh_mobile_meram_cache_free'
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Jingoo Han @ 2014-01-17 6:07 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-1-git-send-email-sachin.kamat@linaro.org>
On Friday, January 17, 2014 2:44 PM, Sachin Kamat wrote:
> On 17 January 2014 10:42, Jingoo Han <jg1.han@samsung.com> wrote:
> > On Friday, January 17, 2014 1:58 PM, Jingoo Han wrote:
> >> On 17 January 2014 10:17, Jingoo Han <jg1.han@samsung.com> wrote:
> >> > On Friday, January 17, 2014 1:33 PM, Sachin Kamat wrote:
> >> >>
> >> >> Exynos is now a DT only platform. Hence there is no need
> >> >> for an explicit OF dependency. Remove it.
> >> >>
> >> >> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> >> >
> >> > Acked-by: Jingoo Han <jg1.han@samsung.com>
> >>
> >> Thanks.
> >> >
> >> > Thank you for sending the patch. However, please CC me,
> >> > because I am a maintainer of Exynos DP driver.
> >>
> >> Sorry for missing you on the CC list. I think you probably need to
> >> update the MAINTAINER file
> >> entry to reflect this.
> >
> > Um, there is no problem in the MAINTAINER file about this.
> > Maybe, you are confused.
>
> No confusion from my side :)
> The entries below do not list maintainer for the Kconfig file since
> you have added specific filters.
> Please verify using get_maintainers script.
Ah, I see.
Right, there is no entries for 'drivers/video/exynos/Kconfig'.
Because, this Kconfig file is shared by both "EXYNOS DP DRIVER"
and "EXYNOS MIPI DISPLAY DRIVERS", I did not add it to "EXYNOS
DP DRIVER" entry.
>
> scripts/get_maintainer.pl -f drivers/video/exynos/Kconfig
>
> This is what it gives (and you are not listed as a maintainer in this case):
>
> Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> (maintainer:FRAMEBUFFER LAYER)
> Tomi Valkeinen <tomi.valkeinen@ti.com> (maintainer:FRAMEBUFFER
> LAYER,commit_signer:1/4%%)
> Kukjin Kim <kgene.kim@samsung.com> (maintainer:ARM/S5P EXYNOS AR...)
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> (commit_signer:2/4P%)
> Kishon Vijay Abraham I <kishon@ti.com> (commit_signer:2/4P%)
> Sachin Kamat <sachin.kamat@linaro.org>
> (commit_signer:2/4P%,authored:2/4P%,added_lines:3/5`%,removed_lines:2/3g%)
> Jingoo Han <jg1.han@samsung.com>
> (commit_signer:1/4%%,authored:1/4%%,added_lines:1/5 %,removed_lines:1/33%)
> Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
> (authored:1/4%%,added_lines:1/5 %)
> linux-fbdev@vger.kernel.org (open list:FRAMEBUFFER LAYER)
> linux-arm-kernel@lists.infradead.org (moderated list:ARM/S5P EXYNOS AR...)
> linux-samsung-soc@vger.kernel.org (moderated list:ARM/S5P EXYNOS AR...)
> linux-kernel@vger.kernel.org (open list)
If you have a good idea for get_maintainer.pl, please let me know.
Thank you.
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Sachin Kamat @ 2014-01-17 5:55 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-1-git-send-email-sachin.kamat@linaro.org>
On 17 January 2014 10:42, Jingoo Han <jg1.han@samsung.com> wrote:
> On Friday, January 17, 2014 1:58 PM, Jingoo Han wrote:
>> On 17 January 2014 10:17, Jingoo Han <jg1.han@samsung.com> wrote:
>> > On Friday, January 17, 2014 1:33 PM, Sachin Kamat wrote:
>> >>
>> >> Exynos is now a DT only platform. Hence there is no need
>> >> for an explicit OF dependency. Remove it.
>> >>
>> >> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>> >
>> > Acked-by: Jingoo Han <jg1.han@samsung.com>
>>
>> Thanks.
>> >
>> > Thank you for sending the patch. However, please CC me,
>> > because I am a maintainer of Exynos DP driver.
>>
>> Sorry for missing you on the CC list. I think you probably need to
>> update the MAINTAINER file
>> entry to reflect this.
>
> Um, there is no problem in the MAINTAINER file about this.
> Maybe, you are confused.
No confusion from my side :)
The entries below do not list maintainer for the Kconfig file since
you have added specific filters.
Please verify using get_maintainers script.
scripts/get_maintainer.pl -f drivers/video/exynos/Kconfig
This is what it gives (and you are not listed as a maintainer in this case):
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
(maintainer:FRAMEBUFFER LAYER)
Tomi Valkeinen <tomi.valkeinen@ti.com> (maintainer:FRAMEBUFFER
LAYER,commit_signer:1/4%%)
Kukjin Kim <kgene.kim@samsung.com> (maintainer:ARM/S5P EXYNOS AR...)
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (commit_signer:2/4P%)
Kishon Vijay Abraham I <kishon@ti.com> (commit_signer:2/4P%)
Sachin Kamat <sachin.kamat@linaro.org>
(commit_signer:2/4P%,authored:2/4P%,added_lines:3/5`%,removed_lines:2/3g%)
Jingoo Han <jg1.han@samsung.com>
(commit_signer:1/4%%,authored:1/4%%,added_lines:1/5 %,removed_lines:1/33%)
Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
(authored:1/4%%,added_lines:1/5 %)
linux-fbdev@vger.kernel.org (open list:FRAMEBUFFER LAYER)
linux-arm-kernel@lists.infradead.org (moderated list:ARM/S5P EXYNOS AR...)
linux-samsung-soc@vger.kernel.org (moderated list:ARM/S5P EXYNOS AR...)
linux-kernel@vger.kernel.org (open list)
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Jingoo Han @ 2014-01-17 5:12 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-1-git-send-email-sachin.kamat@linaro.org>
On Friday, January 17, 2014 1:58 PM, Jingoo Han wrote:
> On 17 January 2014 10:17, Jingoo Han <jg1.han@samsung.com> wrote:
> > On Friday, January 17, 2014 1:33 PM, Sachin Kamat wrote:
> >>
> >> Exynos is now a DT only platform. Hence there is no need
> >> for an explicit OF dependency. Remove it.
> >>
> >> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> >
> > Acked-by: Jingoo Han <jg1.han@samsung.com>
>
> Thanks.
> >
> > Thank you for sending the patch. However, please CC me,
> > because I am a maintainer of Exynos DP driver.
>
> Sorry for missing you on the CC list. I think you probably need to
> update the MAINTAINER file
> entry to reflect this.
Um, there is no problem in the MAINTAINER file about this.
Maybe, you are confused.
Now, Exynos "DP" and Exynos "MIPI" are separately maintained
as below:
EXYNOS DP DRIVER
M: Jingoo Han <jg1.han@samsung.com>
L: linux-fbdev@vger.kernel.org
S: Maintained
F: drivers/video/exynos/exynos_dp*
F: include/video/exynos_dp*
EXYNOS MIPI DISPLAY DRIVERS
M: Inki Dae <inki.dae@samsung.com>
M: Donghwa Lee <dh09.lee@samsung.com>
M: Kyungmin Park <kyungmin.park@samsung.com>
L: linux-fbdev@vger.kernel.org
S: Maintained
F: drivers/video/exynos/exynos_mipi*
F: include/video/exynos_mipi*
Thus, 2nd patch is related to "MIPI", thus, previous CC list is
right. However, 1st patch is related to only "DP". So, I should
be included to CC list.
Best regards,
Jingoo Han
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Sachin Kamat @ 2014-01-17 4:58 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-1-git-send-email-sachin.kamat@linaro.org>
On 17 January 2014 10:17, Jingoo Han <jg1.han@samsung.com> wrote:
> On Friday, January 17, 2014 1:33 PM, Sachin Kamat wrote:
>>
>> Exynos is now a DT only platform. Hence there is no need
>> for an explicit OF dependency. Remove it.
>>
>> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>
> Acked-by: Jingoo Han <jg1.han@samsung.com>
Thanks.
>
> Thank you for sending the patch. However, please CC me,
> because I am a maintainer of Exynos DP driver.
Sorry for missing you on the CC list. I think you probably need to
update the MAINTAINER file
entry to reflect this.
---
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Jingoo Han @ 2014-01-17 4:47 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1389933172-22991-1-git-send-email-sachin.kamat@linaro.org>
On Friday, January 17, 2014 1:33 PM, Sachin Kamat wrote:
>
> Exynos is now a DT only platform. Hence there is no need
> for an explicit OF dependency. Remove it.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Thank you for sending the patch. However, please CC me,
because I am a maintainer of Exynos DP driver.
Best regards,
Jingoo Han
> ---
> drivers/video/exynos/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
> index 1129d0e9e640..976594d578a9 100644
> --- a/drivers/video/exynos/Kconfig
> +++ b/drivers/video/exynos/Kconfig
> @@ -30,7 +30,7 @@ config EXYNOS_LCD_S6E8AX0
>
> config EXYNOS_DP
> bool "EXYNOS DP driver support"
> - depends on OF && ARCH_EXYNOS
> + depends on ARCH_EXYNOS
> default n
> help
> This enables support for DP device.
> --
> 1.7.9.5
^ permalink raw reply
* [PATCH 2/2] video: exynos: Fix S6E8AX0 LCD driver build error
From: Sachin Kamat @ 2014-01-17 4:44 UTC (permalink / raw)
To: linux-fbdev
Enable S6E8AX0 LCD driver only if LCD_CLASS_DEVICE is a built-in driver.
Else we get the following errors due to missing symbols:
drivers/built-in.o: In function `s6e8ax0_probe':
:(.text+0x51aec): undefined reference to `lcd_device_register'
:(.text+0x51c44): undefined reference to `lcd_device_unregister'
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/exynos/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
index 976594d578a9..7e19b467b8f7 100644
--- a/drivers/video/exynos/Kconfig
+++ b/drivers/video/exynos/Kconfig
@@ -22,7 +22,8 @@ config EXYNOS_MIPI_DSI
config EXYNOS_LCD_S6E8AX0
bool "S6E8AX0 MIPI AMOLED LCD Driver"
- depends on (EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE && LCD_CLASS_DEVICE)
+ depends on EXYNOS_MIPI_DSI && BACKLIGHT_CLASS_DEVICE
+ depends on (LCD_CLASS_DEVICE != m)
default n
help
If you have an S6E8AX0 MIPI AMOLED LCD Panel, say Y to enable its
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Sachin Kamat @ 2014-01-17 4:44 UTC (permalink / raw)
To: linux-fbdev
Exynos is now a DT only platform. Hence there is no need
for an explicit OF dependency. Remove it.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/video/exynos/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/exynos/Kconfig b/drivers/video/exynos/Kconfig
index 1129d0e9e640..976594d578a9 100644
--- a/drivers/video/exynos/Kconfig
+++ b/drivers/video/exynos/Kconfig
@@ -30,7 +30,7 @@ config EXYNOS_LCD_S6E8AX0
config EXYNOS_DP
bool "EXYNOS DP driver support"
- depends on OF && ARCH_EXYNOS
+ depends on ARCH_EXYNOS
default n
help
This enables support for DP device.
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 4/4] video: mmp: add device tree support
From: Zhou Zhu @ 2014-01-14 11:16 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Chao Xie, Guoqing Li, Zhou Zhu
In-Reply-To: <1389698184-28761-1-git-send-email-zzhu3-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
add device tree support for mmp fb/controller
the description of DT config is at
Documentation/devicetree/bindings/fb/mmp-disp.txt
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
---
Documentation/devicetree/bindings/fb/mmp-disp.txt | 60 ++++++++
drivers/video/mmp/fb/mmpfb.c | 73 ++++++----
drivers/video/mmp/hw/mmp_ctrl.c | 160 ++++++++++++++++-----
3 files changed, 235 insertions(+), 58 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fb/mmp-disp.txt
diff --git a/Documentation/devicetree/bindings/fb/mmp-disp.txt b/Documentation/devicetree/bindings/fb/mmp-disp.txt
new file mode 100644
index 0000000..80702f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/fb/mmp-disp.txt
@@ -0,0 +1,60 @@
+* Marvell MMP Display (MMP_DISP)
+
+To config mmp display, 3 parts are required to be set in dts:
+1. mmp fb
+Required properties:
+- compatible: Should be "marvell,<soc>-fb".
+- marvell,path: Should be the path this fb connecting to.
+- marvell,overlay-id: Should be the id of overlay this fb is on.
+- marvell,dmafetch-id: Should be the dma fetch id this fb using.
+- marvell,default-pixfmt: Should be the default pixel format when this fb is
+turned on.
+
+2. mmp controller
+Required properties:
+- compatible: Should be "marvell,<soc>-disp".
+- reg: Should be address and length of the register set for this controller.
+- interrupts: Should be interrupt of this controller.
+
+Required sub-node:
+- path:
+Required properties in this sub-node:
+-- marvell,overlay_num: Should be number of overlay this path has.
+-- marvell,output-type: Should be output-type settings
+-- marvell,path-config: Should be path-config settings
+-- marvell,link-config: Should be link-config settings
+-- marvell,rbswap: Should be rbswap settings
+
+3. panel
+Required properties:
+- marvell,path: Should be path that this panel connected to.
+- other properties each panel has.
+
+Examples:
+
+fb: mmp-fb {
+ compatible = "marvell,pxa988-fb";
+ marvell,path = <&path1>;
+ marvell,overlay-id = <0>;
+ marvell,dmafetch-id = <1>;
+ marvell,default-pixfmt = <0x108>;
+};
+
+disp: mmp-disp@d420b000 {
+ compatible = "marvell,pxa988-disp";
+ reg = <0xd420b000 0x1fc>;
+ interrupts = <0 41 0x4>;
+ path1: mmp-pnpath {
+ marvell,overlay-num = <2>;
+ marvell,output-type = <0>;
+ marvell,path-config = <0x20000000>;
+ marvell,link-config = <0x60000001>;
+ marvell,rbswap = <0>;
+ };
+};
+
+panel: <panel-name> {
+ ...
+ marvell,path = <&path1>;
+ ...
+};
diff --git a/drivers/video/mmp/fb/mmpfb.c b/drivers/video/mmp/fb/mmpfb.c
index 7ab31eb..f919d8e 100644
--- a/drivers/video/mmp/fb/mmpfb.c
+++ b/drivers/video/mmp/fb/mmpfb.c
@@ -22,6 +22,7 @@
#include <linux/module.h>
#include <linux/dma-mapping.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include "mmpfb.h"
static int var_to_pixfmt(struct fb_var_screeninfo *var)
@@ -551,56 +552,79 @@ static void fb_info_clear(struct fb_info *info)
fb_dealloc_cmap(&info->cmap);
}
+static const struct of_device_id mmp_fb_dt_match[] = {
+ { .compatible = "marvell,mmp-fb" },
+ { .compatible = "marvell,pxa910-fb" },
+ { .compatible = "marvell,pxa988-fb" },
+ {},
+};
+
static int mmpfb_probe(struct platform_device *pdev)
{
struct mmp_buffer_driver_mach_info *mi;
+ struct device_node *np;
struct fb_info *info = 0;
struct mmpfb_info *fbi = 0;
- int ret, modes_num;
-
- mi = pdev->dev.platform_data;
- if (mi = NULL) {
- dev_err(&pdev->dev, "no platform data defined\n");
- return -EINVAL;
- }
+ int ret = -EINVAL, modes_num;
+ int overlay_id = 0, dmafetch_id = 0;
/* initialize fb */
info = framebuffer_alloc(sizeof(struct mmpfb_info), &pdev->dev);
if (info = NULL)
return -ENOMEM;
fbi = info->par;
- if (!fbi) {
- ret = -EINVAL;
+ if (!fbi)
goto failed;
+
+ np = pdev->dev.of_node;
+ if (np) {
+ fbi->path = devm_mmp_get_path_by_phandle(&pdev->dev,
+ "marvell,path");
+ if (!fbi->path || of_property_read_u32(np,
+ "marvell,default-pixfmt", &fbi->pix_fmt)) {
+ dev_err(&pdev->dev, "unable to get fb setting from dt\n");
+ goto failed;
+ }
+ /* default setting if not set */
+ of_property_read_u32(np, "marvell,overlay-id", &overlay_id);
+ of_property_read_u32(np, "marvell,dmafetch-id", &dmafetch_id);
+ fbi->name = np->name;
+ } else {
+ mi = pdev->dev.platform_data;
+ if (mi = NULL) {
+ dev_err(&pdev->dev, "no platform data defined\n");
+ goto failed;
+ }
+
+ fbi->path = mmp_get_path(mi->path_name);
+ if (!fbi->path) {
+ dev_err(&pdev->dev, "can't get the path %s\n",
+ mi->path_name);
+ goto failed;
+ }
+
+ fbi->name = mi->name;
+ overlay_id = mi->overlay_id;
+ dmafetch_id = mi->dmafetch_id;
+ fbi->pix_fmt = mi->default_pixfmt;
}
/* init fb */
fbi->fb_info = info;
platform_set_drvdata(pdev, fbi);
fbi->dev = &pdev->dev;
- fbi->name = mi->name;
- fbi->pix_fmt = mi->default_pixfmt;
pixfmt_to_var(&info->var, fbi->pix_fmt);
mutex_init(&fbi->access_ok);
- /* get display path by name */
- fbi->path = mmp_get_path(mi->path_name);
- if (!fbi->path) {
- dev_err(&pdev->dev, "can't get the path %s\n", mi->path_name);
- ret = -EINVAL;
- goto failed_destroy_mutex;
- }
-
dev_info(fbi->dev, "path %s get\n", fbi->path->name);
/* get overlay */
- fbi->overlay = mmp_path_get_overlay(fbi->path, mi->overlay_id);
- if (!fbi->overlay) {
- ret = -EINVAL;
+ fbi->overlay = mmp_path_get_overlay(fbi->path, overlay_id);
+ if (!fbi->overlay)
goto failed_destroy_mutex;
- }
+
/* set fetch used */
- mmp_overlay_set_fetch(fbi->overlay, mi->dmafetch_id);
+ mmp_overlay_set_fetch(fbi->overlay, dmafetch_id);
modes_num = modes_setup(fbi);
if (modes_num < 0) {
@@ -679,6 +703,7 @@ static struct platform_driver mmpfb_driver = {
.driver = {
.name = "mmp-fb",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mmp_fb_dt_match),
},
.probe = mmpfb_probe,
};
diff --git a/drivers/video/mmp/hw/mmp_ctrl.c b/drivers/video/mmp/hw/mmp_ctrl.c
index b65913e..08b2ee7 100644
--- a/drivers/video/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/mmp/hw/mmp_ctrl.c
@@ -37,6 +37,7 @@
#include <linux/uaccess.h>
#include <linux/kthread.h>
#include <linux/io.h>
+#include <linux/of.h>
#include "mmp_ctrl.h"
@@ -396,26 +397,43 @@ static void path_set_default(struct mmp_path *path)
writel_relaxed(tmp, ctrl_regs(path) + dma_ctrl(0, path->id));
}
-static int path_init(struct mmphw_path_plat *path_plat,
- struct mmp_mach_path_config *config)
+static int of_path_init(struct mmphw_path_plat *path_plat,
+ struct device_node *path_np)
{
struct mmphw_ctrl *ctrl = path_plat->ctrl;
struct mmp_path_info *path_info;
struct mmp_path *path = NULL;
- dev_info(ctrl->dev, "%s: %s\n", __func__, config->name);
-
/* init driver data */
path_info = kzalloc(sizeof(struct mmp_path_info), GFP_KERNEL);
if (!path_info) {
- dev_err(ctrl->dev, "%s: unable to alloc path_info for %s\n",
- __func__, config->name);
- return 0;
+ dev_err(ctrl->dev, "%s: unable to alloc path_info\n",
+ __func__);
+ return -ENOMEM;
}
- path_info->name = config->name;
+
+ if (!path_np || of_property_read_u32(path_np, "marvell,overlay-num",
+ &path_info->output_type) ||
+ of_property_read_u32(path_np, "marvell,output-type",
+ &path_info->overlay_num)) {
+ dev_err(ctrl->dev, "%s: unable to get path setting from dt\n",
+ __func__);
+ kfree(path_info);
+ return -EINVAL;
+ }
+ /* allow these settings not set */
+ of_property_read_u32(path_np, "marvell,path-config",
+ &path_plat->path_config);
+ of_property_read_u32(path_np, "marvell,link-config",
+ &path_plat->link_config);
+ of_property_read_u32(path_np, "marvell,rbswap",
+ &path_plat->dsi_rbswap);
+ path_info->name = path_np->name;
+
+ dev_info(ctrl->dev, "%s: %s\n", __func__, path_info->name);
+
path_info->id = path_plat->id;
path_info->dev = ctrl->dev;
- path_info->overlay_num = config->overlay_num;
path_info->overlay_ops = &mmphw_overlay_ops;
path_info->set_mode = path_set_mode;
path_info->plat_data = path_plat;
@@ -424,16 +442,56 @@ static int path_init(struct mmphw_path_plat *path_plat,
path = mmp_register_path(path_info);
if (!path) {
kfree(path_info);
- return 0;
+ return -EINVAL;
}
path_plat->path = path;
+ path_set_default(path);
+
+ kfree(path_info);
+ return 0;
+}
+
+static int path_init(struct mmphw_path_plat *path_plat,
+ struct mmp_mach_path_config *config)
+{
+ struct mmphw_ctrl *ctrl = path_plat->ctrl;
+ struct mmp_path_info *path_info;
+ struct mmp_path *path = NULL;
+
+ /* init driver data */
+ path_info = kzalloc(sizeof(struct mmp_path_info), GFP_KERNEL);
+ if (!path_info) {
+ dev_err(ctrl->dev, "%s: unable to alloc path_info\n",
+ __func__);
+ return -ENOMEM;
+ }
+
+ path_info->name = config->name;
+ path_info->overlay_num = config->overlay_num;
+ path_info->output_type = config->output_type;
path_plat->path_config = config->path_config;
path_plat->link_config = config->link_config;
path_plat->dsi_rbswap = config->dsi_rbswap;
+
+ dev_info(ctrl->dev, "%s: %s\n", __func__, path_info->name);
+
+ path_info->id = path_plat->id;
+ path_info->dev = ctrl->dev;
+ path_info->overlay_ops = &mmphw_overlay_ops;
+ path_info->set_mode = path_set_mode;
+ path_info->plat_data = path_plat;
+
+ /* create/register platform device */
+ path = mmp_register_path(path_info);
+ if (!path) {
+ kfree(path_info);
+ return -EINVAL;
+ }
+ path_plat->path = path;
path_set_default(path);
kfree(path_info);
- return 1;
+ return 0;
}
static void path_deinit(struct mmphw_path_plat *path_plat)
@@ -445,13 +503,22 @@ static void path_deinit(struct mmphw_path_plat *path_plat)
mmp_unregister_path(path_plat->path);
}
+static const struct of_device_id mmp_disp_dt_match[] = {
+ { .compatible = "marvell,mmp-disp" },
+ { .compatible = "marvell,pxa910-disp" },
+ { .compatible = "marvell,pxa988-disp" },
+ {},
+};
+
static int mmphw_probe(struct platform_device *pdev)
{
- struct mmp_mach_plat_info *mi;
struct resource *res;
- int ret, i, size, irq;
+ int ret, i, size, irq, path_num;
+ const char *disp_name;
struct mmphw_path_plat *path_plat;
struct mmphw_ctrl *ctrl = NULL;
+ struct mmp_mach_plat_info *mi = pdev->dev.platform_data;
+ struct device_node *np, *path_np = NULL;
/* get resources from platform data */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -468,25 +535,38 @@ static int mmphw_probe(struct platform_device *pdev)
goto failed;
}
- /* get configs from platform data */
- mi = pdev->dev.platform_data;
- if (mi = NULL || !mi->path_num || !mi->paths) {
- dev_err(&pdev->dev, "%s: no platform data defined\n", __func__);
- ret = -EINVAL;
- goto failed;
+ np = pdev->dev.of_node;
+ if (np) {
+ path_num = of_get_child_count(np);
+ if (path_num <= 0) {
+ dev_err(&pdev->dev, "%s: failed to get settings from dt\n",
+ __func__);
+ ret = -EINVAL;
+ goto failed;
+ }
+ disp_name = np->name;
+ } else {
+ if (mi = NULL || !mi->path_num || !mi->paths) {
+ dev_err(&pdev->dev, "%s: no platform data defined\n",
+ __func__);
+ ret = -EINVAL;
+ goto failed;
+ }
+
+ disp_name = mi->name;
+ path_num = mi->path_num;
}
/* allocate */
size = sizeof(struct mmphw_ctrl) + sizeof(struct mmphw_path_plat) *
- mi->path_num;
+ path_num;
ctrl = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
if (!ctrl) {
ret = -ENOMEM;
goto failed;
}
-
- ctrl->name = mi->name;
- ctrl->path_num = mi->path_num;
+ ctrl->path_num = path_num;
+ ctrl->name = disp_name;
ctrl->dev = &pdev->dev;
ctrl->irq = irq;
platform_set_drvdata(pdev, ctrl);
@@ -532,20 +612,31 @@ static int mmphw_probe(struct platform_device *pdev)
/* init global regs */
ctrl_set_default(ctrl);
- /* init pathes from machine info and register them */
- for (i = 0; i < ctrl->path_num; i++) {
- /* get from config and machine info */
- path_plat = &ctrl->path_plats[i];
- path_plat->id = i;
- path_plat->ctrl = ctrl;
-
- /* path init */
- if (!path_init(path_plat, &mi->paths[i])) {
- ret = -EINVAL;
- goto failed_path_init;
+ if (np) {
+ i = 0;
+ for_each_child_of_node(np, path_np) {
+ path_plat = &ctrl->path_plats[i];
+ path_plat->id = i;
+ path_plat->ctrl = ctrl;
+ i++;
+
+ ret = of_path_init(path_plat, path_np);
+ if (ret)
+ goto failed_path_init;
+ }
+ } else {
+ for (i = 0; i < ctrl->path_num; i++) {
+ path_plat = &ctrl->path_plats[i];
+ path_plat->id = i;
+ path_plat->ctrl = ctrl;
+
+ ret = path_init(path_plat, &mi->paths[i]);
+ if (ret)
+ goto failed_path_init;
}
}
+
#ifdef CONFIG_MMP_DISP_SPI
ret = lcd_spi_register(ctrl);
if (ret < 0)
@@ -573,6 +664,7 @@ static struct platform_driver mmphw_driver = {
.driver = {
.name = "mmp-disp",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(mmp_disp_dt_match),
},
.probe = mmphw_probe,
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/4] video: mmp: add devm_mmp_get_path_by_phandle for DT
From: Zhou Zhu @ 2014-01-14 11:16 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Chao Xie, Guoqing Li, Zhou Zhu
In-Reply-To: <1389698184-28761-1-git-send-email-zzhu3-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
add devm_mmp_get_path_by_phandle to replace mmp_get_path
for DT usage
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
---
drivers/video/mmp/core.c | 35 +++++++++++++++++++++++++++++++++++
include/video/mmp_disp.h | 2 ++
2 files changed, 37 insertions(+)
diff --git a/drivers/video/mmp/core.c b/drivers/video/mmp/core.c
index b563b92..0538458 100644
--- a/drivers/video/mmp/core.c
+++ b/drivers/video/mmp/core.c
@@ -23,6 +23,7 @@
#include <linux/slab.h>
#include <linux/dma-mapping.h>
#include <linux/export.h>
+#include <linux/of.h>
#include <video/mmp_disp.h>
static struct mmp_overlay *path_get_overlay(struct mmp_path *path,
@@ -156,6 +157,40 @@ struct mmp_path *mmp_get_path(const char *name)
EXPORT_SYMBOL_GPL(mmp_get_path);
/*
+ * devm_mmp_get_path_by_phandle - get path by phandle
+ * @dev: device that want to get path
+ * @phandle: name of phandle in device node that want to get path
+ *
+ * this function gets path according to node pointed by phandle
+ * return NULL if no matching path
+ */
+struct mmp_path *devm_mmp_get_path_by_phandle(struct device *dev,
+ const char *phandle)
+{
+ struct mmp_path *path;
+ struct device_node *node;
+
+ if (!dev->of_node) {
+ dev_err(dev, "device does not have a device node entry\n");
+ return NULL;
+ }
+
+ node = of_parse_phandle(dev->of_node, phandle, 0);
+ if (!node) {
+ dev_err(dev, "failed to get %s phandle in %s node\n", phandle,
+ dev->of_node->name);
+ return NULL;
+ }
+
+ path = mmp_get_path(node->name);
+
+ of_node_put(node);
+
+ return path;
+}
+EXPORT_SYMBOL_GPL(devm_mmp_get_path_by_phandle);
+
+/*
* mmp_register_path - init and register path by path_info
* @p: path info provided by display controller
*
diff --git a/include/video/mmp_disp.h b/include/video/mmp_disp.h
index 05a3a60..63138b8 100644
--- a/include/video/mmp_disp.h
+++ b/include/video/mmp_disp.h
@@ -248,6 +248,8 @@ struct mmp_path {
};
extern struct mmp_path *mmp_get_path(const char *name);
+struct mmp_path *devm_mmp_get_path_by_phandle(struct device *dev,
+ const char *phandle);
static inline void mmp_path_set_mode(struct mmp_path *path,
struct mmp_mode *mode)
{
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/4] video: mmp: no need to get clk_name from mach_info
From: Zhou Zhu @ 2014-01-14 11:16 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Chao Xie, Guoqing Li, Zhou Zhu
In-Reply-To: <1389698184-28761-1-git-send-email-zzhu3-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
As the display controller has only one clock, no need to
get clk_name from mach_info
Signed-off-by: Zhou Zhu <zzhu3@marvell.com>
---
drivers/video/mmp/hw/mmp_ctrl.c | 4 ++--
include/video/mmp_disp.h | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/video/mmp/hw/mmp_ctrl.c b/drivers/video/mmp/hw/mmp_ctrl.c
index 8621a9f..b65913e 100644
--- a/drivers/video/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/mmp/hw/mmp_ctrl.c
@@ -521,9 +521,9 @@ static int mmphw_probe(struct platform_device *pdev)
}
/* get clock */
- ctrl->clk = devm_clk_get(ctrl->dev, mi->clk_name);
+ ctrl->clk = devm_clk_get(ctrl->dev, NULL);
if (IS_ERR(ctrl->clk)) {
- dev_err(ctrl->dev, "unable to get clk %s\n", mi->clk_name);
+ dev_err(ctrl->dev, "unable to get clk for %s\n", ctrl->name);
ret = -ENOENT;
goto failed;
}
diff --git a/include/video/mmp_disp.h b/include/video/mmp_disp.h
index 9fd9398..05a3a60 100644
--- a/include/video/mmp_disp.h
+++ b/include/video/mmp_disp.h
@@ -344,7 +344,6 @@ struct mmp_mach_path_config {
struct mmp_mach_plat_info {
const char *name;
- const char *clk_name;
int path_num;
struct mmp_mach_path_config *paths;
};
--
1.7.9.5
^ 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