* Re: [PATCH 4/10] atyfb: set FBINFO_READS_FAST
From: Mikulas Patocka @ 2014-01-23 20:03 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-fbdev@vger.kernel.org, Tomi Valkeinen,
Linux Kernel Mailing List
In-Reply-To: <CA+55aFxrZE6oxu5CxFo3mRwGdVcq3jvnn_ChoSJDFgQz45Lq_A@mail.gmail.com>
On Thu, 23 Jan 2014, Linus Torvalds wrote:
> On Thu, Jan 23, 2014 at 11:31 AM, Mikulas Patocka <mpatocka@redhat.com> wrote:
> >
> > Both mach64 and matrox have a hardware bitter that is faster than
> > rewriting the console - that's why FBINFO_READS_FAST improves performance
> > for them.
>
> My point is that I'd expect *anything* that has a hardware blitter to
> be faster than rewriting the screen.
>
> FBINFO_READS_FAST is documented to be about "soft-copy" being faster
> than re-rendering. Which I take to be about actually doing copying in
> *software*.
>
> In particular, updatescrollmode() seems to do this right. It sets
> p->scrollmode based on whether there's an accelerated copyarea. But
> then SCROLL_PAN/WRAP_MOVE ends up re-testing FBINFO_READS_FAST,
> ignoring any hw-accelerated copy-area, and I don't quite see why..
>
> Linus
I think the argument why not to use the blitter was this:
Some hardware have font expansion - you submit monochromatic bitwise image
of the character via writes to some register and the hardware expands it
to full color. Mach64 has this capability, matrox doesn't (maybe it does,
but the driver doesn't use it).
If you use font expansion, you actually generate less load on the videoram
than using the blitter (the expander only writes to the videoram; the
blitter reads data from the videoram and stores them back).
But the benchmarks that I performed show that the blitter is faster than
the font expander. Maybe on a different computer that has better
bufferring in the PCI chipset the font expander could be faster - who
knows?
Mikulas
^ permalink raw reply
* Re: [PATCH v2] backlight: turn backlight on/off when necessary
From: Jingoo Han @ 2014-01-24 2:25 UTC (permalink / raw)
To: 'Liu Ying'
Cc: 'Jani Nikula', linux-fbdev, tomi.valkeinen, plagnioj,
linux-kernel, dri-devel, 'Jingoo Han'
In-Reply-To: <52E0E093.1070803@freescale.com>
On Thursday, January 23, 2014 6:28 PM, Liu Ying wrote:
> On 01/23/2014 01:44 PM, Jingoo Han wrote:
> > On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote:
> >> On Mon, 20 Jan 2014, Liu Ying <Ying.Liu@freescale.com> wrote:
> >>> 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(-)
> >>>
> >
> > [.....]
> >>
> >> Anything backlight worries me a little, and there are actually three
> >> changes bundled into one patch here:
> >>
> >> 1. Changing bd->props.state and bd->props.fb_blank only when use_count
> >> changes from 0->1 or 1->0.
> >>
> >> 2. Calling backlight_update_status() only with the above change, and not
> >> on all notifier callbacks.
> >>
> >> 3. Setting bd->props.fb_blank always to either FB_BLANK_UNBLANK or
> >> FB_BLANK_POWERDOWN instead of *(int *)evdata->data.
>
> Since I have already post v3(https://lkml.org/lkml/2014/1/22/126)
> to change the setting for bd->props.fb_blank, the idea of the 3rd point
> is not very appropriate any more.
OK, I see.
>
> >>
> >> The rationale in the commit message seems plausible, and AFAICT the code
> >> does what it says on the box, so for that (and for that alone) you can
> >> have my
> >>
> >> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> >>
> >> *BUT* it would be laborous to figure out whether this change in
> >> behaviour might regress some drivers. I'm just punting on that. And that
> >> brings us back to the three changes above - in a bisect POV it might be
> >> helpful to split the patch up. Up to the maintainers.
> >
> > I agree with Jani Nikula's opinion.
> > Please split this patch into three patches as above mentioned.
> >
>
> I am open to split the patch up.
> However, IMHO, this patch is somewhat self-contained.
> For example, if we try to create 2 patches for the 1st point and
> the 2nd point Jani mentioned, one patch would invent the use_count
> and call backlight_update_status() on all notifier callbacks(just
> ignore the use_count).
> Do you think this is a good patch?
The calling backlight_update_status() regardless the use_count
Will make the critical side effect? I don't think so.
Also, these two patches will be merged at the same time.
Please, split the patch into two patches. It would be clearer.
One more thing, please keep the indent using "Enter", when
sending your reply mail.
Best regards,
Jingoo Han
^ permalink raw reply
* [PATCH v4 0/2] backlight: update bl status and some bd properties when necessary
From: Liu Ying @ 2014-01-24 6:04 UTC (permalink / raw)
To: jg1.han; +Cc: linux-fbdev, linux-kernel, tomi.valkeinen, dri-devel, plagnioj
We don't have to turn backlight on/off every time 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 set adds
some logics to record each framebuffer's backlight usage to
determine the backlight device use count and whether the
backlight status should be updated or not.
Liu Ying (2):
backlight: update bd state & fb_blank properties when necessary
backlight: update backlight status when necessary
v3->v4:
* Split v3 into 2 patches to separate the change for updating the
backlight device properties and backlight status, according to
the comments from Jani Nikula and Jingoo Han.
v2->v3:
* Set fb_blank(*(int *)evdata->data) to bd->props.fb_blank
when we turn off a blacklight.
* Correct some trivial typos in the commit message.
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(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v4 1/2] backlight: update bd state & fb_blank properties when necessary
From: Liu Ying @ 2014-01-24 6:04 UTC (permalink / raw)
To: jg1.han; +Cc: linux-fbdev, linux-kernel, tomi.valkeinen, dri-devel, plagnioj
In-Reply-To: <1390543476-13499-1-git-send-email-Ying.Liu@freescale.com>
We don't have to update the state and fb_blank properties of
a backlight device every time a blanking or unblanking event
comes because they may have already been what we want. Another
thought is that one backlight device may be shared by multiple
framebuffers. The backlight driver should take the backlight
device as a resource shared by all the associated framebuffers.
This patch adds some logics to record each framebuffer's backlight
usage to determine the backlight device use count and whether
the two properties should be updated or not. 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 an
unblanked framebuffer or blank a blanked framebuffer.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
drivers/video/backlight/backlight.c | 23 ++++++++++++++++++-----
include/linux/backlight.h | 6 ++++++
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index 5d05555..efc9a2d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -41,6 +41,8 @@ static int fb_notifier_callback(struct notifier_block *self,
{
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,11 +53,22 @@ 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;
+ 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;
+ }
+ } 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;
+ }
+ }
backlight_update_status(bd);
}
mutex_unlock(&bd->ops_lock);
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
* [PATCH v4 2/2] backlight: update backlight status when necessary
From: Liu Ying @ 2014-01-24 6:04 UTC (permalink / raw)
To: jg1.han; +Cc: linux-fbdev, linux-kernel, tomi.valkeinen, dri-devel, plagnioj
In-Reply-To: <1390543476-13499-1-git-send-email-Ying.Liu@freescale.com>
We don't have to update a backlight status every time 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 makes the backlight status be updated only when
the relevant backlight device's use count changes from zero
to one or from one to zero.
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
drivers/video/backlight/backlight.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
index efc9a2d..27d3cf2 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -34,7 +34,7 @@ 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)
@@ -60,6 +60,7 @@ static int fb_notifier_callback(struct notifier_block *self,
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]) {
@@ -67,9 +68,9 @@ static int fb_notifier_callback(struct notifier_block *self,
if (!(--bd->use_count)) {
bd->props.state |= BL_CORE_FBBLANK;
bd->props.fb_blank = fb_blank;
+ backlight_update_status(bd);
}
}
- backlight_update_status(bd);
}
mutex_unlock(&bd->ops_lock);
return 0;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v4 0/2] backlight: update bl status and some bd properties when necessary
From: Jingoo Han @ 2014-01-24 8:20 UTC (permalink / raw)
To: 'Liu Ying'
Cc: 'Jean-Christophe PLAGNIOL-VILLARD',
'Tomi Valkeinen', linux-fbdev, linux-kernel, dri-devel,
'Jani Nikula', 'Jingoo Han'
In-Reply-To: <1390543476-13499-1-git-send-email-Ying.Liu@freescale.com>
On Friday, January 24, 2014 3:05 PM, Liu Ying wrote:
>
> We don't have to turn backlight on/off every time 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 set adds
> some logics to record each framebuffer's backlight usage to
> determine the backlight device use count and whether the
> backlight status should be updated or not.
>
> Liu Ying (2):
> backlight: update bd state & fb_blank properties when necessary
> backlight: update backlight status when necessary
Thank you for sending the v4 patch.
I have no objection against this patch. However, I will wait
for other people's opinions. Then, if there is no objection,
I will ask Andrew Morton to merge this patch into mm-tree.
Thanks.
Best regards,
Jingoo Han
>
> v3->v4:
> * Split v3 into 2 patches to separate the change for updating the
> backlight device properties and backlight status, according to
> the comments from Jani Nikula and Jingoo Han.
>
> v2->v3:
> * Set fb_blank(*(int *)evdata->data) to bd->props.fb_blank
> when we turn off a blacklight.
> * Correct some trivial typos in the commit message.
>
> 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(-)
>
> --
> 1.7.9.5
^ permalink raw reply
* RE: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Hiremath, Vaibhav @ 2014-01-24 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0333F.4000400@gmail.com>
> -----Original Message-----
> From: Ivaylo Dimitrov [mailto:ivo.g.dimitrov.75@gmail.com]
> Sent: Thursday, January 23, 2014 2:38 AM
> To: Hiremath, Vaibhav; Ivaylo Dimitrov; Valkeinen, Tomi
> Cc: linux-omap@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> fbdev@vger.kernel.org
> Subject: Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
>
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
>
Link seems to be coming blank to me :)
Thanks,
Vaibhav
^ permalink raw reply
* Re: [PATCH 02/11] x86: sysfb: remove sysfb when probing real hw
From: Ingo Molnar @ 2014-01-24 10:16 UTC (permalink / raw)
To: David Herrmann
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
Dave Airlie, Daniel Vetter, Tomi Valkeinen, linux-kernel,
Tom Gundersen
In-Reply-To: <CANq1E4SyciabqonrFMRa8cMSDxkFuvfqexTBMxKPih+XreF_=A@mail.gmail.com>
* David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Thu, Jan 23, 2014 at 6:14 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * David Herrmann <dh.herrmann@gmail.com> wrote:
> >
> >> >> +#ifdef CONFIG_X86_SYSFB
> >> >> +# include <asm/sysfb.h>
> >> >> +#endif
> >> >
> >> > I guess a single space is sufficient?
> >> >
> >> > Better yet, I'd include sysfb.h unconditionally:
> >>
> >> Unconditionally won't work as only x86 has this header. [...]
> >
> > Well, in non-x86 code an #ifdef x86 looks ugly as well - but I guess
> > better than not building.
> >
> >> [...] If there's a way to place a dummy into asm-generic which is
> >> picked if arch/xy/include/asm/ doesn't have the header, let me know.
> >
> > Not that I know of.
> >
> >> But if I include it unconditionally without any fallback, this will
> >> fail on non-x86. And adding the header to all archs seems overkill.
> >
> > So why not drop the x86-ism and rename it to CONFIG_PLATFORM_SYSFB?
> > Some platforms configure it, some don't. Then the prototypes could
> > move into include/linux/sysfb.h or so and would be platform agnostic.
>
> This is almost exactly what patch #6 does. [...]
Indeed - I never got so far down into the series.
> [...] But it also adds ~400 lines of kernel-doc and ~400 lines of
> Documentation/. Given your remarks, I guess I will just split this
> patch into code and docs, so we can just pick it up for stable in
> case patch #1 does not fix all issues.
I have no objections to this form if it's fixed in a later patch and
this one is easier to backport. I just missed that aspect.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Tomi Valkeinen @ 2014-01-24 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E0333F.4000400@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 374 bytes --]
On 2014-01-22 23:08, Ivaylo Dimitrov wrote:
> Hmm, maybe this https://lkml.org/lkml/2014/1/22/386 will solve our issues
I don't know, it wasn't immediately clear to me if the reserved memory
was handled with CMA or not.
Also, we have this funniness that omapfb is not present in DT data, so
we can't give reserved memory to omapfb directly like that.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [GIT PULL] fbdev changes for 3.14
From: Tomi Valkeinen @ 2014-01-24 11:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, linux-fbdev, Jean-Christophe PLAGNIOL-VILLARD
[-- Attachment #1: Type: text/plain, Size: 6692 bytes --]
Hi Linus,
Please pull the fbdev changes for 3.14.
Tomi
The following changes since commit 802eee95bde72fd0cd0f3a5b2098375a487d1eda:
Linux 3.13-rc6 (2013-12-29 16:01:33 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-3.14
for you to fetch changes up to cb1fbad7ec250ac408a4682d38b205958a17a02b:
Merge branches '3.14/fbdev', '3.14/dss-misc' and '3.14/dss-fclk' into for-next (2014-01-20 10:57:01 +0200)
----------------------------------------------------------------
fbdev changes for 3.14
This is a rather boring pull request. There is one new fb driver, OpenCores
VGA/LCD, but other than that it's just minor cleanups and fixes.
----------------------------------------------------------------
Archit Taneja (2):
OMAPDSS: HDMI4: Accept non-standard timings
OMAPDSS: DISPC: Preload more data in pipeline DMAs for OMAP4+ SoCs
Dan Carpenter (3):
video: mmp: delete a stray mutex_unlock()
video: mmp: Using plain integer as NULL pointer
tgafb: potential NULL dereference in init
Geert Uytterhoeven (1):
video/logo: Remove MIPS-specific include section
Ivaylo Dimitrov (1):
OMAPDSS: DISPC: Fix 34xx overlay scaling calculation
Jingoo Han (4):
video: asiliantfb: remove unnecessary pci_set_drvdata()
video: nvidiafb: remove unnecessary pci_set_drvdata()
video: rivafb: remove unnecessary pci_set_drvdata()
video: vmlfb: remove unnecessary pci_set_drvdata()
Julia Lawall (1):
i810: delete useless variable
Laurent Pinchart (1):
fbdev: sh_mobile_lcdcfb: Don't use plain 0 as NULL pointer
Lothar Waßmann (2):
video: mxsfb: convert pr_debug()/dev_dbg() to pr_err()/dev_err() for error messages
video: mxsfb: fix broken videomode selection
Mark Brown (2):
video: vgacon: Don't build on arm64
video: amba-clcd: Make CLCD driver available on more platforms
Masami Ichikawa (1):
fbcon: Fix memory leak in fbcon_exit().
Olaf Hering (1):
fbmem: really support wildcard video=options for all fbdev drivers
Sachin Kamat (4):
video: ep93xx: Cleanup video-ep93xx.h header
video: msm: Cleanup video-msm_fb.h header
video: pxa: Cleanup video-pxafb.h header
video: pxa168fb: Cleanup pxa168fb.h file
Sascha Hauer (1):
video: mx3fb: Allow blocking during framebuffer allocation
Stefan Kristiansson (1):
video: add OpenCores VGA/LCD framebuffer driver
Tomi Valkeinen (25):
OMAPDSS: fix omap2 dss fck handling
OMAPDSS: remove struct dss_clock_info
OMAPDSS: simplify dss clk dump
OMAPDSS: rename parent clk variables
OMAPDSS: cleanup fck parent handling
OMAPDSS: pass pck to dss fck clock calc
OMAPDSS: add dedicated fck PLL support
OMAPDSS: fix missing EXPORT_SYMBOL()s
OMAPDSS: fix debug prints
OMAPDSS: apply fixes
OMAPDSS: DISPC: Add MFLAG defines
OMAPDSS: rename display-sysfs 'name' entry
OMAPDSS: DSI: fix fifosize
OMAPDSS: HDMI4: remove useless func calls
OMAPDSS: DISPC: fix context restore
OMAPDSS: HDMI: fix hdmi_wait_for_bit_change
OMAPDSS: HDMI: fix HDMI_WP_CLK name
OMAPDSS: HDMI: add missing core irq
OMAPDSS: DSI: split DSI memory map to smaller blocks
OMAPDSS: HDMI: rename resource names
OMAPFB: give informative print when probe succeeds
OMAPDSS: don't print errors on -EPROBE_DEFER
OMAPFB: disable overlays on driver removal
OMAPDSS: panel-acx565akm: clean-up locking
Merge branches '3.14/fbdev', '3.14/dss-misc' and '3.14/dss-fclk' into for-next
Wang YanQing (1):
fbcon: trivial optimization for fbcon_exit
Yijing Wang (1):
video: Replace local macro with PCI standard macro
drivers/video/Kconfig | 19 +-
drivers/video/Makefile | 1 +
drivers/video/asiliantfb.c | 1 -
drivers/video/console/Kconfig | 3 +-
drivers/video/console/fbcon.c | 5 +-
drivers/video/fbmem.c | 3 +
drivers/video/i810/i810_main.c | 4 +-
drivers/video/logo/logo.c | 4 -
drivers/video/mmp/core.c | 9 +-
drivers/video/mx3fb.c | 2 +-
drivers/video/mxsfb.c | 126 +++---
drivers/video/nvidia/nvidia.c | 1 -
drivers/video/ocfb.c | 440 +++++++++++++++++++++
.../omap2/displays-new/panel-sony-acx565akm.c | 44 ++-
drivers/video/omap2/dss/apply.c | 11 +-
drivers/video/omap2/dss/dispc.c | 55 ++-
drivers/video/omap2/dss/dispc.h | 20 +
drivers/video/omap2/dss/display-sysfs.c | 4 +-
drivers/video/omap2/dss/dpi.c | 18 +-
drivers/video/omap2/dss/dsi.c | 223 +++++++----
drivers/video/omap2/dss/dss.c | 163 +++-----
drivers/video/omap2/dss/dss.h | 17 +-
drivers/video/omap2/dss/dss_features.c | 1 +
drivers/video/omap2/dss/dss_features.h | 1 +
drivers/video/omap2/dss/hdmi.h | 16 +-
drivers/video/omap2/dss/hdmi4.c | 22 +-
drivers/video/omap2/dss/hdmi4_core.c | 18 +-
drivers/video/omap2/dss/hdmi_common.c | 2 +
drivers/video/omap2/dss/hdmi_phy.c | 2 +-
drivers/video/omap2/dss/hdmi_pll.c | 18 +-
drivers/video/omap2/dss/hdmi_wp.c | 16 +-
drivers/video/omap2/dss/overlay.c | 5 -
drivers/video/omap2/dss/sdi.c | 24 +-
drivers/video/omap2/dss/venc.c | 3 +-
drivers/video/omap2/omapfb/omapfb-main.c | 19 +
drivers/video/riva/fbdev.c | 1 -
drivers/video/sh_mobile_lcdcfb.c | 2 +-
drivers/video/tgafb.c | 21 +-
drivers/video/vermilion/vermilion.c | 1 -
include/linux/platform_data/video-ep93xx.h | 10 +-
include/linux/platform_data/video-msm_fb.h | 3 +-
include/linux/platform_data/video-pxafb.h | 2 -
include/video/pxa168fb.h | 2 -
43 files changed, 949 insertions(+), 413 deletions(-)
create mode 100644 drivers/video/ocfb.c
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCHv3 30/41] ARM: omap3-n900.dts: add display information
From: Tomi Valkeinen @ 2014-01-24 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121152605.GA5983@earth.universe>
[-- Attachment #1: Type: text/plain, Size: 487 bytes --]
On 2014-01-21 17:26, Sebastian Reichel wrote:
> On Tue, Jan 21, 2014 at 12:57:02PM +0200, Tomi Valkeinen wrote:
>> Add DT data for OMAP3 N900 board. The board has the following
>> displays:
>>
>> lcd: LCD panel connected to OMAP's SDI output
>> tv: analog svideo
>>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> Your dss-dt-review-3 branch boots on my N900 with working display.
>
> Tested-by: Sebastian Reichel <sre@debian.org>
Ok, thanks!
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* some divide by zero bugs in >fb_check_var() functions
From: Dan Carpenter @ 2014-01-24 22:35 UTC (permalink / raw)
To: linux-fbdev
My static checker find a number of divide by zero bugs in
->fb_check_var() functions. The call tree looks like this:
do_fb_ioctl() <- get var from the user.
-> fb_set_var()
-> info->fbops->fb_check_var(var, info); <- divide by zero bugs
I wonder if we could add some checking in fb_set_var() to prevent this.
drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
regards,
dan carpenter
^ permalink raw reply
* Kind Regards
From: Abdul Nasser @ 2014-01-26 21:30 UTC (permalink / raw)
To: linux-fbdev
Greetings,
My name is Abdul Nasser Sokariah and I am writing you from Syria, I choose to contact you directly as I need a reliable person to trust who can help me handle my huge deposit with a vault company in EUROPE, and based on my present situation in Syria, I need you urgently to take possession of everything and further modalities/directives will follow.Please reply to my private Email: nasserabdul190@yahoo.com
I wait for your response.
Yours truly,
Abdul Nasser Sokariah
^ permalink raw reply
* Kind Regards
From: Abdul Nasser @ 2014-01-26 21:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <SECEXCHANGE6DqaJY4k00003907@mail.standardelectronics.com>
Greetings,
My name is Abdul Nasser Sokariah and I am writing you from Syria, I choose to contact you directly as I need a reliable person to trust who can help me handle my huge deposit with a vault company in EUROPE, and based on my present situation in Syria, I need you urgently to take possession of everything and further modalities/directives will follow.Please reply to my private Email: nasserabdul190@yahoo.com
I wait for your response.
Yours truly,
Abdul Nasser Sokariah
^ permalink raw reply
* Kind Regards
From: Abdul Nasser @ 2014-01-26 22:31 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <SECEXCHANGE6DqaJY4k00003907@mail.standardelectronics.com>
Greetings,
My name is Abdul Nasser Sokariah and I am writing you from Syria, I choose to contact you directly as I need a reliable person to trust who can help me handle my huge deposit with a vault company in EUROPE, and based on my present situation in Syria, I need you urgently to take possession of everything and further modalities/directives will follow.Please reply to my private Email: nasserabdul190@yahoo.com
I wait for your response.
Yours truly,
Abdul Nasser Sokariah
^ permalink raw reply
* Re: [PATCHv3 00/41] OMAPDSS: DT support v3
From: Javier Martinez Canillas @ 2014-01-26 23:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com>
Hi Tomi,
On Tue, Jan 21, 2014 at 7:56 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> Here's version 3 of the DSS DT series.
>
> The previous version can be found from:
>
> v1: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108249
> v2: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108866
>
> The main changes to v2 are:
>
> - DT Binding documentation
> - OMAP2 DSS support
> - Split DSI register space
> - DSS nodes disabled by default
> - Hack to have generic DT bindings but OMAP specific drivers (for now)
>
> This series can also be found from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-review-3
>
I tested this branch on my DM3730 IGEPv2 and output display is working
correctly.
Tested-by: Javier Martinez Canillas <javier@dowhile0.org>
> Tomi
>
> Javier Martinez Canillas (1):
> ARM: omap3-igep0020.dts: add display information
>
> Sebastian Reichel (1):
> OMAPDSS: acx565akm: Add DT support
>
> Tomi Valkeinen (39):
> ARM: OMAP2+: add omapdss_init_of()
> ARM: OMAP2+: DT 'compatible' tweak for displays
> OMAPDSS: add 'label' support for DT
> OMAPDSS: get dssdev->alias from DT alias
> OMAPFB: clean up default display search
> OMAPFB: search for default display with DT alias
> OMAPDSS: add of helpers
> OMAPDSS: Improve regulator names for DT
> OMAPDSS: Add DT support to DSS
> OMAPDSS: Add DT support to DISPC
> OMAPDSS: Add DT support to HDMI
> OMAPDSS: Add DT support to VENC
> OMAPDSS: Add DT support to DSI
> OMAPDSS: panel-dsi-cm: Add DT support
> OMAPDSS: encoder-tfp410: Add DT support
> OMAPDSS: connector-dvi: Add DT support
> OMAPDSS: encoder-tpd12s015: Add DT support
> OMAPDSS: hdmi-connector: Add DT support
> OMAPDSS: panel-dpi: Add DT support
> OMAPDSS: connector-analog-tv: Add DT support
> ARM: omap2.dtsi: add omapdss information
> ARM: omap3.dtsi: add omapdss information
> ARM: omap4.dtsi: add omapdss information
> ARM: omap4-panda.dts: add display information
> ARM: omap4-sdp.dts: add display information
> ARM: omap3-beagle.dts: add display information
> ARM: omap3-beagle-xm.dts: add display information
> ARM: omap3-n900.dts: add display information
> OMAPDSS: remove DT hacks for regulators
> ARM: OMAP2+: remove pdata quirks for displays
> Doc/DT: Add OMAP DSS DT Bindings
> Doc/DT: Add DT binding documentation for Analog TV Connector
> Doc/DT: Add DT binding documentation for DVI Connector
> Doc/DT: Add DT binding documentation for HDMI Connector
> Doc/DT: Add DT binding documentation for MIPI DPI Panel
> Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
> Doc/DT: Add DT binding documentation for Sony acx565akm panel
> Doc/DT: Add DT binding documentation for TFP410 encoder
> Doc/DT: Add DT binding documentation for tpd12s015 encoder
>
> .../bindings/video/analog-tv-connector.txt | 23 +++
> .../devicetree/bindings/video/dvi-connector.txt | 26 +++
> .../devicetree/bindings/video/hdmi-connector.txt | 23 +++
> .../devicetree/bindings/video/panel-dpi.txt | 43 ++++
> .../devicetree/bindings/video/panel-dsi-cm.txt | 26 +++
> .../devicetree/bindings/video/sony,acx565akm.txt | 28 +++
> .../devicetree/bindings/video/ti,omap-dss.txt | 197 ++++++++++++++++++
> .../devicetree/bindings/video/ti,omap2-dss.txt | 54 +++++
> .../devicetree/bindings/video/ti,omap3-dss.txt | 73 +++++++
> .../devicetree/bindings/video/ti,omap4-dss.txt | 99 +++++++++
> .../devicetree/bindings/video/ti,tfp410.txt | 41 ++++
> .../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++++
> .../devicetree/bindings/video/video-ports.txt | 22 ++
> arch/arm/boot/dts/omap2.dtsi | 31 +++
> arch/arm/boot/dts/omap3-beagle-xm.dts | 119 +++++++++++
> arch/arm/boot/dts/omap3-beagle.dts | 116 +++++++++++
> arch/arm/boot/dts/omap3-igep0020.dts | 59 +++++-
> arch/arm/boot/dts/omap3-n900.dts | 70 ++++++-
> arch/arm/boot/dts/omap3.dtsi | 42 ++++
> arch/arm/boot/dts/omap4-panda-common.dtsi | 119 ++++++++++-
> arch/arm/boot/dts/omap4-sdp.dts | 107 +++++++++-
> arch/arm/boot/dts/omap4.dtsi | 65 ++++++
> arch/arm/mach-omap2/board-generic.c | 4 +
> arch/arm/mach-omap2/common.h | 3 +
> arch/arm/mach-omap2/display.c | 132 ++++++++++++
> arch/arm/mach-omap2/dss-common.c | 224 ---------------------
> arch/arm/mach-omap2/pdata-quirks.c | 3 -
> .../video/omap2/displays-new/connector-analog-tv.c | 43 +++-
> drivers/video/omap2/displays-new/connector-dvi.c | 43 ++++
> drivers/video/omap2/displays-new/connector-hdmi.c | 30 +++
> drivers/video/omap2/displays-new/encoder-tfp410.c | 43 +++-
> .../video/omap2/displays-new/encoder-tpd12s015.c | 56 ++++++
> drivers/video/omap2/displays-new/panel-dpi.c | 64 +++++-
> drivers/video/omap2/displays-new/panel-dsi-cm.c | 65 +++++-
> .../omap2/displays-new/panel-sony-acx565akm.c | 33 ++-
> drivers/video/omap2/dss/Makefile | 2 +-
> drivers/video/omap2/dss/dispc.c | 8 +
> drivers/video/omap2/dss/display.c | 28 ++-
> drivers/video/omap2/dss/dpi.c | 47 +++++
> drivers/video/omap2/dss/dsi.c | 147 +++++++++++++-
> drivers/video/omap2/dss/dss-of.c | 159 +++++++++++++++
> drivers/video/omap2/dss/dss.c | 64 ++++++
> drivers/video/omap2/dss/dss.h | 6 +
> drivers/video/omap2/dss/hdmi4.c | 14 +-
> drivers/video/omap2/dss/sdi.c | 45 +++++
> drivers/video/omap2/dss/venc.c | 66 +++++-
> drivers/video/omap2/omapfb/omapfb-main.c | 67 ++++--
> include/video/omapdss.h | 14 ++
> 48 files changed, 2550 insertions(+), 287 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
> create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
> create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
> create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
> create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
> create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
> create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
> create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
> create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
> create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
> create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
> create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
> create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
> create mode 100644 drivers/video/omap2/dss/dss-of.c
>
> --
> 1.8.3.2
>
Thanks a lot and best regards,
Javier
^ permalink raw reply
* Re: [PATCH 00/11] SimpleDRM & Sysfb
From: David Herrmann @ 2014-01-27 22:18 UTC (permalink / raw)
To: dri-devel@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org, Daniel Vetter, linux-kernel,
Tomi Valkeinen, Ingo Molnar
In-Reply-To: <1390486503-1504-1-git-send-email-dh.herrmann@gmail.com>
Hi
On Thu, Jan 23, 2014 at 3:14 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> Another round of SimpleDRM patches. I somehow lost track of the last ones and as
> this is a major rewrite, I'll just start at v1 again.
>
> Some comments up-front:
>
> - @Ingo: Patch #1 and #2 are unchanged from the previous ML discussions. I
> included them in this series as the other patches depend on them. Could you
> pick them up for the x86 tree? The other 9 patches won't make it in 3.14 so
> no reason to put them through the DRM tree.
> All mentioned issues should be addressed. If there's still sth missing,
> please let me know.
>
> - The DRM patches depend on my "DRM Anonymous Inode" patches. But it should be
> trivial to apply them on drm-next (I think only one line needs to be changed:
> i_mapping => dev_mapping).
>
> - I tested the SimpleDRM fbdev fallback with linux-console+Xorg and it works
> fine. The DRM backend is only tested with some DRM tests I have locally. I
> have no idea how to make Xorg pick up a specific /dev/dri/card0 card. It
> always tells me "no screens found" (as the underlying device is not marked as
> boot_vga..). If someone knows how to tell Xorg to use card0, I'd gladly test
> this. But I'm no longer used to writing xorg.confs..
For completeness, I tested this with Xorg+xf86-video-modesetting and
it works just fine. The xorg.conf I used can be found below. If this
driver gets upstreamed, I will try to make the X11 auto-loader detect
it just like any other platform-device.
Thanks
David
Section "ServerLayout"
Identifier "MyLayout"
Screen 0 "MyScreen" 0 0
EndSection
Section "Device"
Identifier "MyDevice"
Driver "modesetting"
BusID "platform:/sys/devices/platform/simple-framebuffer.0"
Screen 0
EndSection
Section "Screen"
Identifier "MyScreen"
Device "MyDevice"
EndSection
^ permalink raw reply
* Hi
From: i1ys69km86 @ 2014-01-28 8:18 UTC (permalink / raw)
To: linux-fbdev
Diploma?
http://bit.ly/1hHAuXZ
^ permalink raw reply
* Re: some divide by zero bugs in >fb_check_var() functions
From: Kees Cook @ 2014-01-28 21:28 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140124223503.GA4251@elgon.mountain>
On Fri, Jan 24, 2014 at 2:35 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> My static checker find a number of divide by zero bugs in
> ->fb_check_var() functions. The call tree looks like this:
>
> do_fb_ioctl() <- get var from the user.
> -> fb_set_var()
> -> info->fbops->fb_check_var(var, info); <- divide by zero bugs
>
> I wonder if we could add some checking in fb_set_var() to prevent this.
>
> drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
> drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
> drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
> drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
Is it ever valid to have pixclock, xres_virtual, or bits_per_pixel be
zero? Seems like it'd be trivial to check for those in fb_set_var()?
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* Re: some divide by zero bugs in >fb_check_var() functions
From: Dan Carpenter @ 2014-01-28 21:41 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20140124223503.GA4251@elgon.mountain>
On Tue, Jan 28, 2014 at 01:28:06PM -0800, Kees Cook wrote:
> On Fri, Jan 24, 2014 at 2:35 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > My static checker find a number of divide by zero bugs in
> > ->fb_check_var() functions. The call tree looks like this:
> >
> > do_fb_ioctl() <- get var from the user.
> > -> fb_set_var()
> > -> info->fbops->fb_check_var(var, info); <- divide by zero bugs
> >
> > I wonder if we could add some checking in fb_set_var() to prevent this.
> >
> > drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> > drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> > drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
> > drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
> > drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> > drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
> > drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
> > drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> > drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
> > drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
> > drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
> > drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
>
> Is it ever valid to have pixclock, xres_virtual, or bits_per_pixel be
> zero? Seems like it'd be trivial to check for those in fb_set_var()?
>
It's not so simple as testing for zero, you also have to consider the
maximum and integer overflows so "var->xres_virtual * var->bits_per_pixel"
isn't zero.
If I add another call to the call tree then there are more errors again.
regards,
dan carpenter
drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
drivers/video/savage/savagefb_driver.c:952 savagefb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
drivers/video/fbmon.c:1147 fb_get_hblank_by_hfreq() error: potential divide by zero bug '/ hfreq'.
drivers/video/fbmon.c:1147 fb_get_hblank_by_hfreq() error: potential divide by zero bug '/ hfreq'.
drivers/video/fbmon.c:1232 fb_timings_hfreq() error: potential divide by zero bug '/ timings->vtotal'.
drivers/video/fbmon.c:1232 fb_timings_hfreq() error: potential divide by zero bug '/ timings->vtotal'.
drivers/video/fbmon.c:1244 fb_timings_dclk() error: potential divide by zero bug '/ timings->htotal'.
drivers/video/fbmon.c:1244 fb_timings_dclk() error: potential divide by zero bug '/ timings->htotal'.
drivers/video/fbmon.c:1247 fb_timings_dclk() error: potential divide by zero bug '/ timings->vtotal'.
drivers/video/fbmon.c:1247 fb_timings_dclk() error: potential divide by zero bug '/ timings->vtotal'.
drivers/video/fbmon.c:1364 fb_get_mode() error: potential divide by zero bug '/ (timings->dclk / 1000)'.
drivers/video/fbmon.c:1364 fb_get_mode() error: potential divide by zero bug '/ (timings->dclk / 1000)'.
drivers/video/fbmon.c:1544 fb_validate_mode() error: potential divide by zero bug '/ htotal'.
drivers/video/fbmon.c:1544 fb_validate_mode() error: potential divide by zero bug '/ htotal'.
drivers/video/fbmon.c:1547 fb_validate_mode() error: potential divide by zero bug '/ vtotal'.
drivers/video/fbmon.c:1547 fb_validate_mode() error: potential divide by zero bug '/ vtotal'.
drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (htotal * vtotal)'.
drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (htotal * vtotal)'.
drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/via/viafbdev.c:196 get_var_refresh() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/pm3fb.c:338 pm3fb_init_engine() error: potential divide by zero bug '/ info->fix.line_length'.
drivers/video/pm3fb.c:338 pm3fb_init_engine() error: potential divide by zero bug '/ info->fix.line_length'.
drivers/video/pm3fb.c:834 pm3fb_write_mode() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/pm3fb.c:834 pm3fb_write_mode() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/pm3fb.c:1007 pm3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tdfxfb.c:518 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tdfxfb.c:519 tdfxfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tdfxfb.c:583 tdfxfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/tdfxfb.c:583 tdfxfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/sstfb.c:359 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/sstfb.c:361 sstfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/sstfb.c:491 sstfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/sstfb.c:491 sstfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
drivers/video/sm501fb.c:263 sm501fb_ps_to_hz() error: potential divide by zero bug '/ __base'.
drivers/video/sm501fb.c:593 sm501fb_pan_crt() error: potential divide by zero bug '/ bytes_pixel'.
drivers/video/sm501fb.c:593 sm501fb_pan_crt() error: potential divide by zero bug '/ bytes_pixel'.
drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
drivers/video/cyber2000fb.c:843 cyber2000fb_check_var() error: potential divide by zero bug '/ (var->bits_per_pixel * var->xres_virtual)'.
drivers/video/kyro/STG4000OverlayDevice.c:379 SetOverlayViewPort() error: potential divide by zero bug '/ ulFxScale'.
drivers/video/kyro/STG4000OverlayDevice.c:379 SetOverlayViewPort() error: potential divide by zero bug '/ ulFxScale'.
drivers/video/kyro/STG4000OverlayDevice.c:477 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
drivers/video/kyro/STG4000OverlayDevice.c:477 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
drivers/video/kyro/STG4000OverlayDevice.c:481 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
drivers/video/kyro/STG4000OverlayDevice.c:481 SetOverlayViewPort() error: potential divide by zero bug '/ (ulRight - ulLeft + 2)'.
drivers/video/kyro/fbdev.c:502 kyrofb_set_par() error: potential divide by zero bug '/ frameclock'.
drivers/video/kyro/fbdev.c:502 kyrofb_set_par() error: potential divide by zero bug '/ frameclock'.
drivers/video/kyro/fbdev.c:503 kyrofb_set_par() error: potential divide by zero bug '/ lineclock'.
drivers/video/kyro/fbdev.c:503 kyrofb_set_par() error: potential divide by zero bug '/ lineclock'.
drivers/video/kyro/fbdev.c:505 kyrofb_set_par() error: potential divide by zero bug '/ info->var.pixclock'.
drivers/video/kyro/fbdev.c:505 kyrofb_set_par() error: potential divide by zero bug '/ info->var.pixclock'.
drivers/video/modedb.c:809 fb_var_to_videomode() error: potential divide by zero bug '/ htotal'.
drivers/video/modedb.c:809 fb_var_to_videomode() error: potential divide by zero bug '/ htotal'.
drivers/video/modedb.c:810 fb_var_to_videomode() error: potential divide by zero bug '/ vtotal'.
drivers/video/modedb.c:810 fb_var_to_videomode() error: potential divide by zero bug '/ vtotal'.
drivers/video/mb862xx/mb862xxfbdrv.c:221 mb862xxfb_set_par() error: potential divide by zero bug '/ fbi->var.pixclock'.
drivers/video/mb862xx/mb862xxfbdrv.c:221 mb862xxfb_set_par() error: potential divide by zero bug '/ fbi->var.pixclock'.
drivers/video/smscufx.c:622 ufx_config_pix_clk() error: potential divide by zero bug '/ (pixclock)'.
drivers/video/smscufx.c:622 ufx_config_pix_clk() error: potential divide by zero bug '/ (pixclock)'.
drivers/video/s3fb.c:477 s3_set_pixclock() error: potential divide by zero bug '/ pixclock'.
drivers/video/s3fb.c:477 s3_set_pixclock() error: potential divide by zero bug '/ pixclock'.
drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/s3fb.c:601 s3fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
drivers/video/imsttfb.c:843 imsttfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
drivers/video/asiliantfb.c:113 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
drivers/video/asiliantfb.c:113 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
drivers/video/asiliantfb.c:123 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
drivers/video/asiliantfb.c:123 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
drivers/video/asiliantfb.c:124 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
drivers/video/asiliantfb.c:124 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
drivers/video/asiliantfb.c:125 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
drivers/video/asiliantfb.c:125 asiliant_calc_dclk2() error: potential divide by zero bug '/ pixclock'.
drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/asiliantfb.c:230 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/asiliantfb.c:231 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/asiliantfb.c:232 asiliantfb_check_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:435 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:435 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:437 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:437 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:444 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:444 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:446 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:446 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:453 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:453 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:455 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:455 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:461 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:461 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:463 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:463 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:655 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:655 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:662 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/i740fb.c:662 i740fb_decode_var() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/cirrusfb.c:482 cirrusfb_check_pixclock() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/cirrusfb.c:482 cirrusfb_check_pixclock() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
drivers/video/cirrusfb.c:535 cirrusfb_check_var() error: potential divide by zero bug '/ var->bits_per_pixel'.
drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
drivers/video/cirrusfb.c:581 cirrusfb_check_var() error: potential divide by zero bug '/ var->xres_virtual'.
drivers/video/cirrusfb.c:836 cirrusfb_set_par_foo() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/cirrusfb.c:836 cirrusfb_set_par_foo() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/riva/fbdev.c:722 riva_load_video_mode() error: potential divide by zero bug '/ info->var.pixclock'.
drivers/video/riva/fbdev.c:722 riva_load_video_mode() error: potential divide by zero bug '/ info->var.pixclock'.
drivers/video/geode/lxfb_ops.c:169 lx_set_clock() error: potential divide by zero bug '/ info->var.pixclock'.
drivers/video/geode/lxfb_ops.c:169 lx_set_clock() error: potential divide by zero bug '/ info->var.pixclock'.
drivers/video/sis/sis_main.c:1082 sisfb_calc_maxyres() error: potential divide by zero bug '/ (var->xres_virtual * (var->bits_per_pixel >> 3))'.
drivers/video/sis/sis_main.c:1082 sisfb_calc_maxyres() error: potential divide by zero bug '/ (var->xres_virtual * (var->bits_per_pixel >> 3))'.
drivers/video/nvidia/nvidia.c:424 nvidia_calc_regs() error: potential divide by zero bug '/ info->var.pixclock'.
drivers/video/nvidia/nvidia.c:424 nvidia_calc_regs() error: potential divide by zero bug '/ info->var.pixclock'.
drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
drivers/video/tridentfb.c:918 tridentfb_check_var() error: potential divide by zero bug '/ line_length'.
drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tridentfb.c:973 tridentfb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/tridentfb.c:1176 tridentfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/tridentfb.c:1176 tridentfb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/neofb.c:594 neofb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
drivers/video/neofb.c:702 neofb_check_var() error: potential divide by zero bug '/ (var->xres_virtual * var->bits_per_pixel)'.
drivers/video/neofb.c:952 neofb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/neofb.c:952 neofb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/arkfb.c:517 ark_set_pixclock() error: potential divide by zero bug '/ pixclock'.
drivers/video/arkfb.c:517 ark_set_pixclock() error: potential divide by zero bug '/ pixclock'.
drivers/video/udlfb.c:266 dlfb_set_vid_cmds() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/udlfb.c:266 dlfb_set_vid_cmds() error: potential divide by zero bug '/ var->pixclock'.
drivers/video/uvesafb.c:1270 uvesafb_set_par() error: potential divide by zero bug '/ (crtc->vert_total * crtc->horiz_total)'.
drivers/video/uvesafb.c:1270 uvesafb_set_par() error: potential divide by zero bug '/ (crtc->vert_total * crtc->horiz_total)'.
drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/pm2fb.c:624 pm2fb_check_var() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/pm2fb.c:716 pm2fb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/pm2fb.c:716 pm2fb_set_par() error: potential divide by zero bug '/ (info->var.pixclock)'.
drivers/video/vermilion/vermilion.c:609 vmlfb_check_var_locked() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/vermilion/vermilion.c:609 vmlfb_check_var_locked() error: potential divide by zero bug '/ (var->pixclock)'.
drivers/video/matrox/matroxfb_Ti3026.c:320 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
drivers/video/matrox/matroxfb_Ti3026.c:320 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
drivers/video/matrox/matroxfb_Ti3026.c:323 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
drivers/video/matrox/matroxfb_Ti3026.c:323 Ti3026_setpclk() error: potential divide by zero bug '/ Bpp'.
drivers/video/matrox/matroxfb_base.c:578 matroxfb_decode_var() error: potential divide by zero bug '/ (var->xres_virtual * bpp)'.
drivers/video/matrox/matroxfb_base.c:578 matroxfb_decode_var() error: potential divide by zero bug '/ (var->xres_virtual * bpp)'.
drivers/video/matrox/matroxfb_base.c:601 matroxfb_decode_var() error: potential divide by zero bug '/ m2'.
drivers/video/matrox/matroxfb_base.c:601 matroxfb_decode_var() error: potential divide by zero bug '/ m2'.
drivers/video/matrox/matroxfb_base.c:787 matroxfb_set_par() error: potential divide by zero bug '/ var->bits_per_pixel'.
drivers/video/matrox/matroxfb_base.c:787 matroxfb_set_par() error: potential divide by zero bug '/ var->bits_per_pixel'.
drivers/video/aty/radeon_base.c:1595 radeonfb_set_par() error: potential divide by zero bug '/ pixClock'.
drivers/video/aty/radeon_base.c:1595 radeonfb_set_par() error: potential divide by zero bug '/ pixClock'.
drivers/video/aty/radeon_base.c:1670 radeonfb_set_par() error: potential divide by zero bug '/ ((mode->bits_per_pixel + 1) / 8)'.
drivers/video/aty/radeon_base.c:1670 radeonfb_set_par() error: potential divide by zero bug '/ ((mode->bits_per_pixel + 1) / 8)'.
drivers/video/aty/atyfb_base.c:1575 set_off_pitch() error: potential divide by zero bug '/ bpp'.
drivers/video/aty/atyfb_base.c:1575 set_off_pitch() error: potential divide by zero bug '/ bpp'.
drivers/video/aty/mach64_accel.c:69 aty_init_engine() error: potential divide by zero bug '/ (info->var.bits_per_pixel / 8)'.
drivers/video/aty/mach64_accel.c:69 aty_init_engine() error: potential divide by zero bug '/ (info->var.bits_per_pixel / 8)'.
drivers/video/aty/aty128fb.c:1342 aty128_var_to_pll() error: potential divide by zero bug '/ period_in_ps'.
drivers/video/aty/aty128fb.c:1342 aty128_var_to_pll() error: potential divide by zero bug '/ period_in_ps'.
drivers/video/sysfillrect.c:267 sys_fillrect() error: potential divide by zero bug '/ bpp'.
drivers/video/sysfillrect.c:267 sys_fillrect() error: potential divide by zero bug '/ bpp'.
drivers/video/sysfillrect.c:321 sys_fillrect() error: potential divide by zero bug '/ bpp'.
drivers/video/sysfillrect.c:321 sys_fillrect() error: potential divide by zero bug '/ bpp'.
drivers/video/cfbfillrect.c:302 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
drivers/video/cfbfillrect.c:302 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
drivers/video/cfbfillrect.c:357 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
drivers/video/cfbfillrect.c:357 cfb_fillrect() error: potential divide by zero bug '/ bpp'.
drivers/video/vt8623fb.c:267 vt8623_set_pixclock() error: potential divide by zero bug '/ pixclock'.
drivers/video/vt8623fb.c:267 vt8623_set_pixclock() error: potential divide by zero bug '/ pixclock'.
^ permalink raw reply
* [PATCH Resend 1/2] video: exynos: Remove OF dependency for Exynos DP
From: Sachin Kamat @ 2014-02-03 8:45 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>
Acked-by: Jingoo Han <jg1.han@samsung.com>
---
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 Resend 2/2] video: exynos: Fix S6E8AX0 LCD driver build error
From: Sachin Kamat @ 2014-02-03 8:45 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
* [PATCH v2] RFC: framebuffer: provide generic get_fb_unmapped_area
From: Uwe Kleine-König @ 2014-02-03 17:14 UTC (permalink / raw)
To: linux-fbdev
This patch makes mmapping the simple-framebuffer device work on a no-MMU
ARM target. The code is mostly taken from
arch/blackfin/kernel/sys_bfin.c.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Hello,
note this is only tested on this no-MMU machine and I don't know enough
about framebuffers and mm to decide if this patch is sane. Also I'm
a bit unsure about the size check, I just believed Geert that
PAGE_ALIGN(info->fix.smem_len) is the right value to check against.
Best regards
Uwe
drivers/video/fbmem.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index 7309ac704e26..d0ccedafec8c 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1491,6 +1491,22 @@ __releases(&info->lock)
return 0;
}
+#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
+#define fb_get_unmapped_area get_fb_unmapped_area
+#else
+unsigned long fb_get_unmapped_area(struct file *filp, unsigned long orig_addr,
+ unsigned long len, unsigned long pgoff, unsigned long flags)
+{
+ struct fb_info * const info = filp->private_data;
+ unsigned long fb_size = PAGE_ALIGN(info->fix.smem_len);
+
+ if (pgoff > fb_size || len > fb_size - pgoff)
+ return -EINVAL;
+
+ return (unsigned long)info->screen_base + pgoff;
+}
+#endif
+
static const struct file_operations fb_fops = {
.owner = THIS_MODULE,
.read = fb_read,
@@ -1502,9 +1518,7 @@ static const struct file_operations fb_fops = {
.mmap = fb_mmap,
.open = fb_open,
.release = fb_release,
-#ifdef HAVE_ARCH_FB_UNMAPPED_AREA
- .get_unmapped_area = get_fb_unmapped_area,
-#endif
+ .get_unmapped_area = fb_get_unmapped_area,
#ifdef CONFIG_FB_DEFERRED_IO
.fsync = fb_deferred_io_fsync,
#endif
--
1.8.5.2
^ permalink raw reply related
* Re: [PATCH v2] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Shuah Khan @ 2014-02-04 17:55 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: <52DD4045.4050902@samsung.com>
On 01/20/2014 08:27 AM, Shuah Khan wrote:
> On 01/19/2014 06:34 PM, Jingoo Han wrote:
>> On Monday, January 20, 2014 12:37 AM, Rafael J. Wysocki wrote:
> 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.
>
Checked 3.14-rc1 and patch v3 is in there.
commit 3601792e7b68150420ea8dc129e26e167c0484d8
-- 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 v2] backlight: Convert from Legacy pm ops to dev_pm_ops
From: Jingoo Han @ 2014-02-05 0:17 UTC (permalink / raw)
To: 'Shuah Khan', 'Rafael J. Wysocki'
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: <52F1298F.1040903@samsung.com>
On Wednesday, February 05, 2014 2:55 AM, Shuah Khan wrote:
> On 01/20/2014 08:27 AM, Shuah Khan wrote:
> > On 01/19/2014 06:34 PM, Jingoo Han wrote:
> >> On Monday, January 20, 2014 12:37 AM, Rafael J. Wysocki wrote:
>
> > 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.
> >
>
> Checked 3.14-rc1 and patch v3 is in there.
>
> commit 3601792e7b68150420ea8dc129e26e167c0484d8
OK, I see. I checked that it was already merged to
mainline kernel. Thank you.
Best regards,
Jingoo Han
^ 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