* [PATCH 1/4] compat-drivers: backport fb_info->skip_vt_switch using ifdefs
From: Luis R. Rodriguez @ 2013-03-28 12:04 UTC (permalink / raw)
To: FlorianSchandinat
Cc: linux-fbdev, dri-devel, jbarnes, backports, cocci, linux-kernel,
julia.lawall, rodrigo.vivi, daniel.vetter, rafael.j.wysocki,
Luis R. Rodriguez
In-Reply-To: <1364472270-9297-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Commit 3cf2667 as of next-20130301 extended the struct fb_info
with a skip_vt_switch to allow drivers to skip the VT switch
at suspend/resume time. For older kernels we can skip this
as all this switch does is call pm_vt_switch_required() with true
or false depending on this new flag and later
pm_vt_switch_unregister() would not have been made.
This patch cannot be broken down further so I'm pegging
this as the first one with 4 digits under the DRM folder
for collateral evolutions. This reflects its as atomic as
is possible. As we'll see on the next commit, these type
of collateral evolutions can best be backported not by
keeping ifdef's as below but instead by using a wrapper
caller, to help reduce with the amount of lines of code
we need. If a static inline is added upstream for these
changes, then no code is required for backporting, at all,
we'd just implement the static inline later upstream as
a no-op.
The tradeoffs to consider for this is if we can live with
these practices upstream, we may be able to support full
subsystems only with a compat module, and no need for
patches. This also means less code and likely less bugs
on the distribution front when backporting is required.
At least IMHO this may be worthy to consider at least to
support kernels listed as supported on kernel.org. We could
just leave the ifdef hell to older unsupported kernels.
Relevant commits below, starting with the first one that
added this new collateral evolution.
commit 3cf2667b9f8b2c2fe298a427deb399e52321da6b
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Mon Feb 4 13:37:21 2013 +0000
fb: add support for drivers not needing VT switch at suspend/resume time
Use the new PM routines to indicate whether we need to VT switch at suspend
and resume time. When a new driver is bound, set its flag accordingly,
and when unbound, remove it from the PM's console tracking list.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Tue Mar 26 09:25:45 2013 -0700
drm/i915: enable VT switchless resume v3
With the other bits in place, we can do this safely.
v2: disable backlight on suspend to prevent premature enablement on resume
v3: disable CRTCs on suspend to allow RTD3 (Kristen)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: cocci@systeme.lip6.fr
Cc: backports@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
.../drm/0001-fb-info-vt_switch.patch | 73 ++++++++++++++++++++
1 file changed, 73 insertions(+)
create mode 100644 patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
diff --git a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
new file mode 100644
index 0000000..cdced87
--- /dev/null
+++ b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
@@ -0,0 +1,73 @@
+Commit 3cf2667 as of next-20130301 extended the struct fb_info
+with a skip_vt_switch to allow drivers to skip the VT switch
+at suspend/resume time. For older kernels we can skip this
+as all this switch does is call pm_vt_switch_required() with true
+or false depending on this new flag and later
+pm_vt_switch_unregister() would not have been made.
+
+This patch cannot be broken down further so I'm pegging
+this as the first one with 4 digits under the DRM folder
+for collateral evolutions. This reflects its as atomic as
+is possible. As we'll see on the next commit, these type
+of collateral evolutions can best be backported not by
+keeping ifdef's as below but instead by using a wrapper
+caller, to help reduce with the amount of lines of code
+we need. If a static inline is added upstream for these
+changes, then no code is required for backporting, at all,
+we'd just implement the static inline later upstream as
+a no-op.
+
+The tradeoffs to consider for this is if we can live with
+these practices upstream, we may be able to support full
+subsystems only with a compat module, and no need for
+patches. This also means less code and likely less bugs
+on the distribution front when backporting is required.
+At least IMHO this may be worthy to consider at least to
+support kernels listed as supported on kernel.org. We could
+just leave the ifdef hell to older unsupported kernels.
+
+Relevant commits below, starting with the first one that
+added this new collateral evolution.
+
+commit 3cf2667b9f8b2c2fe298a427deb399e52321da6b
+Author: Jesse Barnes <jbarnes@virtuousgeek.org>
+Date: Mon Feb 4 13:37:21 2013 +0000
+
+ fb: add support for drivers not needing VT switch at suspend/resume time
+
+ Use the new PM routines to indicate whether we need to VT switch at suspend
+ and resume time. When a new driver is bound, set its flag accordingly,
+ and when unbound, remove it from the PM's console tracking list.
+
+ Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+ Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+ Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+commit 24576d23976746cb52e7700c4cadbf4bc1bc3472
+Author: Jesse Barnes <jbarnes@virtuousgeek.org>
+Date: Tue Mar 26 09:25:45 2013 -0700
+
+ drm/i915: enable VT switchless resume v3
+
+ With the other bits in place, we can do this safely.
+
+ v2: disable backlight on suspend to prevent premature enablement on resume
+ v3: disable CRTCs on suspend to allow RTD3 (Kristen)
+
+ Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+ Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
+ Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+--- a/drivers/gpu/drm/i915/intel_fb.c
++++ b/drivers/gpu/drm/i915/intel_fb.c
+@@ -150,8 +150,10 @@ static int intelfb_create(struct drm_fb_
+ }
+ info->screen_size = size;
+
++#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,10,0))
+ /* This driver doesn't need a VT switch to restore the mode on resume */
+ info->skip_vt_switch = true;
++#endif
+
+ drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
+ drm_fb_helper_fill_var(info, &ifbdev->helper, sizes->fb_width, sizes->fb_height);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/4] compat: backport fb_info->skip_vt_switch using a static inline
From: Luis R. Rodriguez @ 2013-03-28 12:04 UTC (permalink / raw)
To: FlorianSchandinat
Cc: linux-fbdev, dri-devel, jbarnes, backports, cocci, linux-kernel,
julia.lawall, rodrigo.vivi, daniel.vetter, rafael.j.wysocki,
Luis R. Rodriguez
In-Reply-To: <1364472270-9297-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Commit 3cf2667 as of next-20130301 extended the struct fb_info
with a skip_vt_switch to allow drivers to skip the VT switch
at suspend/resume time. For older kernels we can skip this
as all this switch does is call pm_vt_switch_required() with true
or false depending on this new flag and later
pm_vt_switch_unregister() would not have been made.
compat-drivers was backporting this using #ifdef's but by
integrating a static inline we'd reduce the number of lines
to backport to just 1 line replacement. This would be something
like:
- info->skip_vt_switch = true;
+ fb_enable_skip_vt_switch(info);
For kernels >= 3.10 we'd set the attribute as we do upstream,
for older kernels this would be a no-op.
If this static inline would have been added upstream it would
have meant this collateral evolution would require just adding
a no-op static inline to backport, and no changes as the above
example hunk for every driver that requires the change.
If this static inline ends up upstream *now* it means we do *not*
require the type of hunk above for every driver that requires
the change.
All the code would be left intact !
This is a linux-next 'data structure element collateral evolution'.
Cc: cocci@systeme.lip6.fr
Cc: backports@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
include/linux/compat-3.10.h | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/include/linux/compat-3.10.h b/include/linux/compat-3.10.h
index 69ddc11..9abfc4b 100644
--- a/include/linux/compat-3.10.h
+++ b/include/linux/compat-3.10.h
@@ -7,6 +7,7 @@
#include <linux/scatterlist.h>
#include <linux/mm.h>
+#include <linux/fb.h>
#define sg_page_iter_page LINUX_BACKPORT(sg_page_iter_page)
/**
@@ -29,6 +30,46 @@ static inline dma_addr_t sg_page_iter_dma_address(struct sg_page_iter *piter)
return sg_dma_address(piter->sg) + (piter->sg_pgoffset << PAGE_SHIFT);
}
+/*
+ * This is a linux-next data structure element collateral evolution,
+ * we use a wrapper to avoid #ifdef hell to backport it. This allows
+ * us to use a simple fb_info_skip_vt_switch() replacement for when
+ * the new data structure element is used. If coccinelle SmPL grammar
+ * could be used to express the transformation for us on compat-drivers
+ * it means we'd need to express it only once. If the structure element
+ * collateral evolution were to be used *at development* time and we'd
+ * have a way to express the inverse through SmPL we'd be able to
+ * backport this collateral evolution automatically for any new driver
+ * that used it. We'd use coccinelle to look for it and do the
+ * transformations for us based on the original commit (maybe SmPL
+ * would be listed on the commit log.
+ *
+ * We may need the LINUX_BACKPORT() call that adds the backport_
+ * prefix for older kernels than 3.10 if distros decide to
+ * add this same static inline themselves (although unlikely).
+ */
+#define fb_enable_skip_vt_switch LINUX_BACKPORT(fb_enable_skip_vt_switch)
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+}
+
+#else /* kernel is >= 3.10 */
+/*
+ * We'd delete this upstream ever got this, we use our
+ * backport_ prefix with LINUX_BACKPORT() so that if this
+ * does get upstream we would not have to add another ifdef
+ * here for the kernels in between v3.10.. up to the point
+ * the routine would have gotten added, we'd just delete this
+ * #else condition completely. If we didn't have this and
+ * say 3.12 added the static inline upstream, we'd have a
+ * clash on the backport for 3.12 as the routine would
+ * already be defined *but* we'd need it for 3.11.
+ */
+#define fb_enable_skip_vt_switch LINUX_BACKPORT(fb_enable_skip_vt_switch)
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+ info->skip_vt_switch = true;
+}
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(3,10,0)) */
#endif /* LINUX_3_10_COMPAT_H */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/4] compat-drivers: simplify backport fb_info->skip_vt_switch CE
From: Luis R. Rodriguez @ 2013-03-28 12:04 UTC (permalink / raw)
To: FlorianSchandinat
Cc: linux-fbdev, dri-devel, jbarnes, backports, cocci, linux-kernel,
julia.lawall, rodrigo.vivi, daniel.vetter, rafael.j.wysocki,
Luis R. Rodriguez
In-Reply-To: <1364472270-9297-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
The collateral evolution (CE) on the fb_info data structure
that added the skip_vt_switch element can be simplified
further by replacing the #ifdef hell with a static inline.
Furthermore, if the static inline is added upstream it'd mean
we can get rid of all these static inline replacements for
this data structure element CE.
Cc: cocci@systeme.lip6.fr
Cc: backports@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
.../drm/0001-fb-info-vt_switch.patch | 25 ++++----------------
1 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
index cdced87..39b13d1 100644
--- a/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
+++ b/patches/collateral-evolutions/drm/0001-fb-info-vt_switch.patch
@@ -8,23 +8,7 @@ pm_vt_switch_unregister() would not have been made.
This patch cannot be broken down further so I'm pegging
this as the first one with 4 digits under the DRM folder
for collateral evolutions. This reflects its as atomic as
-is possible. As we'll see on the next commit, these type
-of collateral evolutions can best be backported not by
-keeping ifdef's as below but instead by using a wrapper
-caller, to help reduce with the amount of lines of code
-we need. If a static inline is added upstream for these
-changes, then no code is required for backporting, at all,
-we'd just implement the static inline later upstream as
-a no-op.
-
-The tradeoffs to consider for this is if we can live with
-these practices upstream, we may be able to support full
-subsystems only with a compat module, and no need for
-patches. This also means less code and likely less bugs
-on the distribution front when backporting is required.
-At least IMHO this may be worthy to consider at least to
-support kernels listed as supported on kernel.org. We could
-just leave the ifdef hell to older unsupported kernels.
+is possible.
Relevant commits below, starting with the first one that
added this new collateral evolution.
@@ -60,14 +44,13 @@ Date: Tue Mar 26 09:25:45 2013 -0700
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
-@@ -150,8 +150,10 @@ static int intelfb_create(struct drm_fb_
+@@ -150,8 +150,8 @@ static int intelfb_create(struct drm_fb_
}
info->screen_size = size;
-+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3,10,0))
/* This driver doesn't need a VT switch to restore the mode on resume */
- info->skip_vt_switch = true;
-+#endif
+- info->skip_vt_switch = true;
++ fb_enable_skip_vt_switch(info);
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
drm_fb_helper_fill_var(info, &ifbdev->helper, sizes->fb_width, sizes->fb_height);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/4] fb: add helpers to enable and test for the skip_vt_switch
From: Luis R. Rodriguez @ 2013-03-28 12:04 UTC (permalink / raw)
To: FlorianSchandinat
Cc: linux-fbdev, dri-devel, jbarnes, backports, cocci, linux-kernel,
julia.lawall, rodrigo.vivi, daniel.vetter, rafael.j.wysocki,
Luis R. Rodriguez
In-Reply-To: <1364472270-9297-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This adds helpers to enable and test for the skip_vt_switch.
This gets us two things:
1) It allows us to require less collateral evolutions
should we need changes on the fb_info data structure
later (perhaps a bitmap flag).
2) Allows this feature to be backported with 0 delta
required on the upstream drivers, we'd just require
the static inline to do a no-op.
1) may be worth while considering, 2) is a new consideration
I'm trying to get others to evaluate to help with automatically
backporting the Linux kernel. This is the first time I am
aware someone argues for it.
Cc: cocci@systeme.lip6.fr
Cc: backports@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
drivers/gpu/drm/i915/intel_fb.c | 2 +-
drivers/video/fbmem.c | 2 +-
include/linux/fb.h | 10 ++++++++++
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 8d81c929..c0f306c 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -151,7 +151,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
info->screen_size = size;
/* This driver doesn't need a VT switch to restore the mode on resume */
- info->skip_vt_switch = true;
+ fb_enable_skip_vt_switch(info);
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
drm_fb_helper_fill_var(info, &ifbdev->helper, sizes->fb_width, sizes->fb_height);
diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index ccd44b0..daffadc 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1645,7 +1645,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
if (!fb_info->modelist.prev || !fb_info->modelist.next)
INIT_LIST_HEAD(&fb_info->modelist);
- if (fb_info->skip_vt_switch)
+ if (fb_skip_vt_switch_isset(fb_info))
pm_vt_switch_required(fb_info->dev, false);
else
pm_vt_switch_required(fb_info->dev, true);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index d49c60f..d534966 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -505,6 +505,16 @@ struct fb_info {
bool skip_vt_switch; /* no VT switch on suspend/resume required */
};
+static inline void fb_enable_skip_vt_switch(struct fb_info *info)
+{
+ info->skip_vt_switch = true;
+}
+
+static inline bool fb_skip_vt_switch_isset(struct fb_info *info)
+{
+ return info->skip_vt_switch;
+}
+
static inline struct apertures_struct *alloc_apertures(unsigned int max_num) {
struct apertures_struct *a = kzalloc(sizeof(struct apertures_struct)
+ max_num * sizeof(struct aperture), GFP_KERNEL);
--
1.7.10.4
^ permalink raw reply related
* [GIT PULL] fbdev fixes for 3.9
From: Tomi Valkeinen @ 2013-03-28 12:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: Florian Tobias Schandinat, linux-fbdev, linux-omap, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]
Hi Linus,
Since Florian is still away/inactive, I volunteered to collect fbdev fixes for
3.9 and changes for 3.10. I didn't receive any other fbdev fixes than OMAP yet,
but I didn't want to delay this further as there's a compilation fix for OMAP1.
So there could be still some fbdev fixes on the way a bit later.
Tomi
The following changes since commit a937536b868b8369b98967929045f1df54234323:
Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git tags/fbdev-fixes-3.9-rc4
for you to fetch changes up to ff588d83bf12fe05521a64e85dd4e2b848c0b20d:
omapdss: features: fix supported outputs for OMAP4 (2013-03-22 10:14:32 +0200)
----------------------------------------------------------------
* Fix OMAP1 compilation
* OMAP display fixes
----------------------------------------------------------------
Aaro Koskinen (1):
omapfb: fix broken build on OMAP1
Archit Taneja (1):
omapdss: features: fix supported outputs for OMAP4
Grazvydas Ignotas (1):
OMAPDSS: tpo-td043 panel: fix data passing between SPI/DSS parts
drivers/video/omap/omapfb_main.c | 2 ++
drivers/video/omap2/displays/panel-tpo-td043mtea1.c | 13 +++++++++++--
drivers/video/omap2/dss/dss_features.c | 6 ++----
3 files changed, 15 insertions(+), 6 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Jesse Barnes @ 2013-03-28 15:39 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-fbdev, backports, FlorianSchandinat, daniel.vetter,
rafael.j.wysocki, linux-kernel, dri-devel, rodrigo.vivi, cocci
In-Reply-To: <1364472270-9297-1-git-send-email-mcgrof@do-not-panic.com>
On Thu, 28 Mar 2013 05:04:26 -0700
"Luis R. Rodriguez" <mcgrof@do-not-panic.com> wrote:
> The new commit by Jesse that extended the fb_info with a skip_vt_switch
> element is the simplest example of a data structure expansion. We'd backport
> this by adding a static inline to compat so that new kernels muck with the
> new element and for older kernels this would be a no-op. This reduces the
> size of the backport and unclutters the required patch with #idefs, and
> insteads leaves only a replacement of the usage of the new elements with
> a static inline, this however would still be required on our end:
>
> - info->skip_vt_switch = true;
> + fb_enable_skip_vt_switch(info);
>
> So we'd then have to just add this static inline change for each new driver...
> There may be a way to get SmPL to do this for us...
Yeah I'm not attached to the direct structure reference; a couple of
inlines are just as easy to read. So no argument from me.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Julia Lawall @ 2013-03-28 16:19 UTC (permalink / raw)
To: Jesse Barnes
Cc: Luis R. Rodriguez, FlorianSchandinat, linux-fbdev, dri-devel,
backports, cocci, linux-kernel, julia.lawall, rodrigo.vivi,
daniel.vetter, rafael.j.wysocki
In-Reply-To: <20130328083943.01e61b4b@jbarnes-desktop>
On Thu, 28 Mar 2013, Jesse Barnes wrote:
> On Thu, 28 Mar 2013 05:04:26 -0700
> "Luis R. Rodriguez" <mcgrof@do-not-panic.com> wrote:
>
> > The new commit by Jesse that extended the fb_info with a skip_vt_switch
> > element is the simplest example of a data structure expansion. We'd backport
> > this by adding a static inline to compat so that new kernels muck with the
> > new element and for older kernels this would be a no-op. This reduces the
> > size of the backport and unclutters the required patch with #idefs, and
> > insteads leaves only a replacement of the usage of the new elements with
> > a static inline, this however would still be required on our end:
> >
> > - info->skip_vt_switch = true;
> > + fb_enable_skip_vt_switch(info);
> >
> > So we'd then have to just add this static inline change for each new driver...
> > There may be a way to get SmPL to do this for us...
@@
type of info *info;
@@
- info->skip_vt_switch = true;
+ fb_enable_skip_vt_switch(info);
for whatever the type of info is.
Then I guess there would be a similar rule for the false case?
julia
>
> Yeah I'm not attached to the direct structure reference; a couple of
> inlines are just as easy to read. So no argument from me.
>
> Thanks,
> --
> Jesse Barnes, Intel Open Source Technology Center
>
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Luis R. Rodriguez @ 2013-03-28 18:05 UTC (permalink / raw)
To: Julia Lawall
Cc: Jesse Barnes, FlorianSchandinat, linux-fbdev, dri-devel,
backports@vger.kernel.org, cocci, linux-kernel@vger.kernel.org,
rodrigo.vivi, Daniel Vetter, rafael.j.wysocki
In-Reply-To: <alpine.DEB.2.02.1303281718490.1928@hadrien>
On Thu, Mar 28, 2013 at 9:19 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> On Thu, 28 Mar 2013, Jesse Barnes wrote:
>> > - info->skip_vt_switch = true;
>> > + fb_enable_skip_vt_switch(info);
>> >
>> > So we'd then have to just add this static inline change for each new driver...
>> > There may be a way to get SmPL to do this for us...
>
> @@
> type of info *info;
> @@
>
> - info->skip_vt_switch = true;
> + fb_enable_skip_vt_switch(info);
>
> for whatever the type of info is.
Thanks Julia! I'll be sure to try to add this to compat-drivers if the
upstream fb patch is not accepted. If it is accepted we would not need
this at all!
> Then I guess there would be a similar rule for the false case?
Nope, see that's the proactive strategy taken by the static inline and
hence the patch. compat would have a static inline for both cases, and
for the false case it'd be a no-op. If accepted upstream though then
we would not need any changes for this collateral evolution. However
*spotting* these collateral evolutions and giving you SmPL for them as
a proactive strategy might be good given that if these type of patches
are indeed welcomed upstream we'd then be able to address these as
secondary steps. If they are not accepted then indeed we'd use them to
backport that collateral evolution through both compat (adds the
static inlines) and compat-drivers (the SmPL).
Luis
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Julia Lawall @ 2013-03-28 18:10 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Julia Lawall, Jesse Barnes, FlorianSchandinat, linux-fbdev,
dri-devel, backports@vger.kernel.org, cocci,
linux-kernel@vger.kernel.org, rodrigo.vivi, Daniel Vetter,
rafael.j.wysocki
In-Reply-To: <CAB=NE6WbNwPqEPYsASAPaECe4qbAWdd4=eJ402ib+CzZbT69=g@mail.gmail.com>
On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
> On Thu, Mar 28, 2013 at 9:19 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> > On Thu, 28 Mar 2013, Jesse Barnes wrote:
> >> > - info->skip_vt_switch = true;
> >> > + fb_enable_skip_vt_switch(info);
> >> >
> >> > So we'd then have to just add this static inline change for each new driver...
> >> > There may be a way to get SmPL to do this for us...
> >
> > @@
> > type of info *info;
> > @@
> >
> > - info->skip_vt_switch = true;
> > + fb_enable_skip_vt_switch(info);
> >
> > for whatever the type of info is.
>
> Thanks Julia! I'll be sure to try to add this to compat-drivers if the
> upstream fb patch is not accepted. If it is accepted we would not need
> this at all!
>
> > Then I guess there would be a similar rule for the false case?
>
> Nope, see that's the proactive strategy taken by the static inline and
> hence the patch. compat would have a static inline for both cases, and
> for the false case it'd be a no-op. If accepted upstream though then
> we would not need any changes for this collateral evolution. However
> *spotting* these collateral evolutions and giving you SmPL for them as
> a proactive strategy might be good given that if these type of patches
> are indeed welcomed upstream we'd then be able to address these as
> secondary steps. If they are not accepted then indeed we'd use them to
> backport that collateral evolution through both compat (adds the
> static inlines) and compat-drivers (the SmPL).
Probably I am missing something, since I haven't looked at the code in
detail, bu wouldn't it be nicer to have a function call for the false
case, if there is a function call for the true case? In looking at the
code, one could wonder why things are not done in a parallel way.
julia
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Luis R. Rodriguez @ 2013-03-28 18:25 UTC (permalink / raw)
To: Julia Lawall
Cc: Jesse Barnes, florianschandinat, linux-fbdev, dri-devel,
backports@vger.kernel.org, cocci, linux-kernel@vger.kernel.org,
rodrigo.vivi, Daniel Vetter, rafael.j.wysocki
In-Reply-To: <alpine.DEB.2.02.1303281909570.1928@hadrien>
On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
>>
>> Thanks Julia! I'll be sure to try to add this to compat-drivers if the
>> upstream fb patch is not accepted. If it is accepted we would not need
>> this at all!
>>
>> > Then I guess there would be a similar rule for the false case?
>>
>> Nope, see that's the proactive strategy taken by the static inline and
>> hence the patch. compat would have a static inline for both cases, and
>> for the false case it'd be a no-op. If accepted upstream though then
>> we would not need any changes for this collateral evolution. However
>> *spotting* these collateral evolutions and giving you SmPL for them as
>> a proactive strategy might be good given that if these type of patches
>> are indeed welcomed upstream we'd then be able to address these as
>> secondary steps. If they are not accepted then indeed we'd use them to
>> backport that collateral evolution through both compat (adds the
>> static inlines) and compat-drivers (the SmPL).
>
> Probably I am missing something, since I haven't looked at the code in
> detail, bu wouldn't it be nicer to have a function call for the false
> case, if there is a function call for the true case?
Yes, and indeed we have that, its the same function call, in the
negative case its a no-op, in the newer kernels it wraps to modifying
the element as in the original code.
> In looking at the
> code, one could wonder why things are not done in a parallel way.
Not sure I get this.
Luis
^ permalink raw reply
* [PATCH 1/1] video: fbomn: fix type VESA_DMT_VSYNC_HIGH
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-03-28 21:03 UTC (permalink / raw)
To: linux-arm-kernel
it's VESA_DMT_VSYNC_HIGH not VESA_DMT_HSYNC_HIGH
to check to enable the FB_SYNC_VERT_HIGH_ACT
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/fbmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 94ad0f7..7f67099 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -1400,7 +1400,7 @@ int fb_videomode_from_videomode(const struct videomode *vm,
fbmode->vmode = 0;
if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
- if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+ if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
fbmode->vmode |= FB_VMODE_INTERLACED;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Julia Lawall @ 2013-03-28 22:29 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Julia Lawall, Jesse Barnes, florianschandinat, linux-fbdev,
dri-devel, backports@vger.kernel.org, cocci,
linux-kernel@vger.kernel.org, rodrigo.vivi, Daniel Vetter,
rafael.j.wysocki
In-Reply-To: <CAB=NE6VPRu8DvneVdwd=pXF0ngi5OifNTpZtX3pLi50i116_OA@mail.gmail.com>
On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
> On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
> >>
> >> Thanks Julia! I'll be sure to try to add this to compat-drivers if the
> >> upstream fb patch is not accepted. If it is accepted we would not need
> >> this at all!
> >>
> >> > Then I guess there would be a similar rule for the false case?
> >>
> >> Nope, see that's the proactive strategy taken by the static inline and
> >> hence the patch. compat would have a static inline for both cases, and
> >> for the false case it'd be a no-op. If accepted upstream though then
> >> we would not need any changes for this collateral evolution. However
> >> *spotting* these collateral evolutions and giving you SmPL for them as
> >> a proactive strategy might be good given that if these type of patches
> >> are indeed welcomed upstream we'd then be able to address these as
> >> secondary steps. If they are not accepted then indeed we'd use them to
> >> backport that collateral evolution through both compat (adds the
> >> static inlines) and compat-drivers (the SmPL).
> >
> > Probably I am missing something, since I haven't looked at the code in
> > detail, bu wouldn't it be nicer to have a function call for the false
> > case, if there is a function call for the true case?
>
> Yes, and indeed we have that, its the same function call, in the
> negative case its a no-op, in the newer kernels it wraps to modifying
> the element as in the original code.
>
> > In looking at the
> > code, one could wonder why things are not done in a parallel way.
>
> Not sure I get this.
I looked in today's linux-next, and there seems to be only one
initialization of this field, to true, and one test of this field. So
perhaps the case for setting the field to false just isn't needed.
julia
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Luis R. Rodriguez @ 2013-03-28 23:25 UTC (permalink / raw)
To: Julia Lawall
Cc: Jesse Barnes, florianschandinat, linux-fbdev, dri-devel,
backports@vger.kernel.org, cocci, linux-kernel@vger.kernel.org,
rodrigo.vivi, Daniel Vetter, rafael.j.wysocki
In-Reply-To: <alpine.DEB.2.02.1303282328200.2022@localhost6.localdomain6>
On Thu, Mar 28, 2013 at 3:29 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
> On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
>
>> On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>> > On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
>> >>
>> >> Thanks Julia! I'll be sure to try to add this to compat-drivers if the
>> >> upstream fb patch is not accepted. If it is accepted we would not need
>> >> this at all!
>> >>
>> >> > Then I guess there would be a similar rule for the false case?
>> >>
>> >> Nope, see that's the proactive strategy taken by the static inline and
>> >> hence the patch. compat would have a static inline for both cases, and
>> >> for the false case it'd be a no-op. If accepted upstream though then
>> >> we would not need any changes for this collateral evolution. However
>> >> *spotting* these collateral evolutions and giving you SmPL for them as
>> >> a proactive strategy might be good given that if these type of patches
>> >> are indeed welcomed upstream we'd then be able to address these as
>> >> secondary steps. If they are not accepted then indeed we'd use them to
>> >> backport that collateral evolution through both compat (adds the
>> >> static inlines) and compat-drivers (the SmPL).
>> >
>> > Probably I am missing something, since I haven't looked at the code in
>> > detail, bu wouldn't it be nicer to have a function call for the false
>> > case, if there is a function call for the true case?
>>
>> Yes, and indeed we have that, its the same function call, in the
>> negative case its a no-op, in the newer kernels it wraps to modifying
>> the element as in the original code.
>>
>> > In looking at the
>> > code, one could wonder why things are not done in a parallel way.
>>
>> Not sure I get this.
>
> I looked in today's linux-next, and there seems to be only one
> initialization of this field, to true, and one test of this field. So
> perhaps the case for setting the field to false just isn't needed.
Oh sorry now I get what you mean! I thought about this -- and yes I
decided to not add a bool false setting for the structure field given
that the assumption is this would not be something dynamic, and data
structure would be kzalloc()'d so by default they are 0.
Luis
^ permalink raw reply
* Re: [PATCH 1/1] video: fbomn: fix type VESA_DMT_VSYNC_HIGH
From: Jingoo Han @ 2013-03-29 1:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364504606-2087-1-git-send-email-plagnioj@jcrosoft.com>
On Friday, March 29, 2013 6:03 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
> it's VESA_DMT_VSYNC_HIGH not VESA_DMT_HSYNC_HIGH
> to check to enable the FB_SYNC_VERT_HIGH_ACT
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: linux-fbdev@vger.kernel.org
CC'ed Steffen Trumtrar.
The same patch was already submitted as below:
(https://patchwork.kernel.org/patch/2183811/)
I will resend this patch, soon.
Best regards,
Jingoo Han
> ---
> drivers/video/fbmon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
> index 94ad0f7..7f67099 100644
> --- a/drivers/video/fbmon.c
> +++ b/drivers/video/fbmon.c
> @@ -1400,7 +1400,7 @@ int fb_videomode_from_videomode(const struct videomode *vm,
> fbmode->vmode = 0;
> if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> - if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> + if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
> fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
> if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
> fbmode->vmode |= FB_VMODE_INTERLACED;
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH RESEND] fbmon: use VESA_DMT_VSYNC_HIGH to fix typo
From: Jingoo Han @ 2013-03-29 1:40 UTC (permalink / raw)
To: akpm
Cc: linux-kernel, linux-fbdev, tomi.valkeinen, FlorianSchandinat,
s.trumtrar, plagnioj, jg1.han
VkVTQV9ETVRfVlNZTkNfSElHSCBzaG91bGQgYmUgdXNlZCBpbnN0ZWFkIG9mIFZFU0FfRE1UX0hT
WU5DX0hJR0gsDQpiZWNhdXNlIEZCX1NZTkNfVkVSVF9ISUdIX0FDVCBpcyByZWxhdGVkIHRvIHZz
eW5jLCBub3QgdG8gaHN5bmMuDQoNClNpZ25lZC1vZmYtYnk6IEppbmdvbyBIYW4gPGpnMS5oYW5A
c2Ftc3VuZy5jb20+DQpDYzogU3RlZmZlbiBUcnVtdHJhciA8cy50cnVtdHJhckBwZW5ndXRyb25p
eC5kZT4NCkNjOiBUb21pIFZhbGtlaW5lbiA8dG9taS52YWxrZWluZW5AdGkuY29tPg0KLS0tDQog
ZHJpdmVycy92aWRlby9mYm1vbi5jIHwgICAgMiArLQ0KIDEgZmlsZXMgY2hhbmdlZCwgMSBpbnNl
cnRpb25zKCspLCAxIGRlbGV0aW9ucygtKQ0KDQpkaWZmIC0tZ2l0IGEvZHJpdmVycy92aWRlby9m
Ym1vbi5jIGIvZHJpdmVycy92aWRlby9mYm1vbi5jDQppbmRleCA5NGFkMGY3Li43ZjY3MDk5IDEw
MDY0NA0KLS0tIGEvZHJpdmVycy92aWRlby9mYm1vbi5jDQorKysgYi9kcml2ZXJzL3ZpZGVvL2Zi
bW9uLmMNCkBAIC0xNDAwLDcgKzE0MDAsNyBAQCBpbnQgZmJfdmlkZW9tb2RlX2Zyb21fdmlkZW9t
b2RlKGNvbnN0IHN0cnVjdCB2aWRlb21vZGUgKnZtLA0KIAlmYm1vZGUtPnZtb2RlID0gMDsNCiAJ
aWYgKHZtLT5kbXRfZmxhZ3MgJiBWRVNBX0RNVF9IU1lOQ19ISUdIKQ0KIAkJZmJtb2RlLT5zeW5j
IHw9IEZCX1NZTkNfSE9SX0hJR0hfQUNUOw0KLQlpZiAodm0tPmRtdF9mbGFncyAmIFZFU0FfRE1U
X0hTWU5DX0hJR0gpDQorCWlmICh2bS0+ZG10X2ZsYWdzICYgVkVTQV9ETVRfVlNZTkNfSElHSCkN
CiAJCWZibW9kZS0+c3luYyB8PSBGQl9TWU5DX1ZFUlRfSElHSF9BQ1Q7DQogCWlmICh2bS0+ZGF0
YV9mbGFncyAmIERJU1BMQVlfRkxBR1NfSU5URVJMQUNFRCkNCiAJCWZibW9kZS0+dm1vZGUgfD0g
RkJfVk1PREVfSU5URVJMQUNFRDsNCi0tIA0KMS43LjIuNQ0K
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Julia Lawall @ 2013-03-29 6:21 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Julia Lawall, Jesse Barnes, florianschandinat, linux-fbdev,
dri-devel, backports@vger.kernel.org, cocci,
linux-kernel@vger.kernel.org, rodrigo.vivi, Daniel Vetter,
rafael.j.wysocki
In-Reply-To: <CAB=NE6WX5Dv9p2jrNwe9GxfH=EUm596uvSspsLQ5-Uuonc6Fqg@mail.gmail.com>
> > I looked in today's linux-next, and there seems to be only one
> > initialization of this field, to true, and one test of this field. So
> > perhaps the case for setting the field to false just isn't needed.
>
> Oh sorry now I get what you mean! I thought about this -- and yes I
> decided to not add a bool false setting for the structure field given
> that the assumption is this would not be something dynamic, and data
> structure would be kzalloc()'d so by default they are 0.
What do you do about the test, though?
julia
^ permalink raw reply
* Re: [PATCH] compat/compat-drivers/linux-next: fb skip_vt_switch
From: Luis R. Rodriguez @ 2013-03-29 7:29 UTC (permalink / raw)
To: Julia Lawall
Cc: Jesse Barnes, florianschandinat, linux-fbdev, dri-devel,
backports@vger.kernel.org, cocci, linux-kernel@vger.kernel.org,
rodrigo.vivi, Daniel Vetter, rafael.j.wysocki
In-Reply-To: <alpine.DEB.2.02.1303290720350.2023@localhost6.localdomain6>
On Thu, Mar 28, 2013 at 11:21 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>> > I looked in today's linux-next, and there seems to be only one
>> > initialization of this field, to true, and one test of this field. So
>> > perhaps the case for setting the field to false just isn't needed.
>>
>> Oh sorry now I get what you mean! I thought about this -- and yes I
>> decided to not add a bool false setting for the structure field given
>> that the assumption is this would not be something dynamic, and data
>> structure would be kzalloc()'d so by default they are 0.
>
> What do you do about the test, though?
Return the value.
Luis
^ permalink raw reply
* Re: [PATCH RESEND] fbmon: use VESA_DMT_VSYNC_HIGH to fix typo
From: Steffen Trumtrar @ 2013-03-29 8:41 UTC (permalink / raw)
To: Jingoo Han
Cc: akpm, linux-kernel, linux-fbdev, tomi.valkeinen,
FlorianSchandinat, plagnioj
In-Reply-To: <8984685.165951364521249756.JavaMail.weblogic@epml18>
On Fri, Mar 29, 2013 at 01:40:52AM +0000, Jingoo Han wrote:
> VESA_DMT_VSYNC_HIGH should be used instead of VESA_DMT_HSYNC_HIGH,
> because FB_SYNC_VERT_HIGH_ACT is related to vsync, not to hsync.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/fbmon.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
> index 94ad0f7..7f67099 100644
> --- a/drivers/video/fbmon.c
> +++ b/drivers/video/fbmon.c
> @@ -1400,7 +1400,7 @@ int fb_videomode_from_videomode(const struct videomode *vm,
> fbmode->vmode = 0;
> if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> - if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> + if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
> fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
> if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
> fbmode->vmode |= FB_VMODE_INTERLACED;
> --
> 1.7.2.5
Hi,
I already implied this on the original mail, but to be clear:
Acked-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/1] video: fbomn: fix type VESA_DMT_VSYNC_HIGH
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-03-29 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002801ce2c1c$e93564a0$bba02de0$%han@samsung.com>
On 10:29 Fri 29 Mar , Jingoo Han wrote:
> On Friday, March 29, 2013 6:03 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >
> > it's VESA_DMT_VSYNC_HIGH not VESA_DMT_HSYNC_HIGH
> > to check to enable the FB_SYNC_VERT_HIGH_ACT
> >
> > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: linux-fbdev@vger.kernel.org
>
> CC'ed Steffen Trumtrar.
>
> The same patch was already submitted as below:
> (https://patchwork.kernel.org/patch/2183811/)
>
> I will resend this patch, soon.
did not see ok
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
so
Best Regards,
J.
^ permalink raw reply
* Re: [PATCH 1/2] video: ssd1307fb: Add support for SSD1306 OLED controller
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-03-29 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1362588251-1824-2-git-send-email-maxime.ripard@free-electrons.com>
On 17:44 Wed 06 Mar , Maxime Ripard wrote:
> The Solomon SSD1306 OLED controller is very similar to the SSD1307,
> except for the fact that the power is given through an external PWM for
> the 1307, and while the 1306 can generate its own power without any PWM.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> .../devicetree/bindings/video/ssd1307fb.txt | 10 +-
> drivers/video/ssd1307fb.c | 267 ++++++++++++++------
> 2 files changed, 203 insertions(+), 74 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
> index 3d0060c..7a12542 100644
> --- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
> +++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
> @@ -1,13 +1,17 @@
> * Solomon SSD1307 Framebuffer Driver
>
> Required properties:
> - - compatible: Should be "solomon,ssd1307fb-<bus>". The only supported bus for
> - now is i2c.
> + - compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for
> + now is i2c, and the supported chips are ssd1306 and ssd1307.
> - reg: Should contain address of the controller on the I2C bus. Most likely
> 0x3c or 0x3d
> - pwm: Should contain the pwm to use according to the OF device tree PWM
> - specification [0]
> + specification [0]. Only required for the ssd1307.
> - reset-gpios: Should contain the GPIO used to reset the OLED display
> + - solomon,height: Height in pixel of the screen driven by the controller
> + - solomon,width: Width in pixel of the screen driven by the controller
> + - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is
> + mapped to.
>
> Optional properties:
> - reset-active-low: Is the reset gpio is active on physical low?
> diff --git a/drivers/video/ssd1307fb.c b/drivers/video/ssd1307fb.c
> index 395cb6a..95f76e2 100644
> --- a/drivers/video/ssd1307fb.c
> +++ b/drivers/video/ssd1307fb.c
> @@ -16,24 +16,39 @@
> #include <linux/pwm.h>
> #include <linux/delay.h>
>
> -#define SSD1307FB_WIDTH 96
> -#define SSD1307FB_HEIGHT 16
> -
> #define SSD1307FB_DATA 0x40
> #define SSD1307FB_COMMAND 0x80
>
> #define SSD1307FB_CONTRAST 0x81
> +#define SSD1307FB_CHARGE_PUMP 0x8d
> #define SSD1307FB_SEG_REMAP_ON 0xa1
> #define SSD1307FB_DISPLAY_OFF 0xae
> +#define SSD1307FB_SET_MULTIPLEX_RATIO 0xa8
> #define SSD1307FB_DISPLAY_ON 0xaf
> #define SSD1307FB_START_PAGE_ADDRESS 0xb0
> +#define SSD1307FB_SET_DISPLAY_OFFSET 0xd3
> +#define SSD1307FB_SET_CLOCK_FREQ 0xd5
> +#define SSD1307FB_SET_PRECHARGE_PERIOD 0xd9
> +#define SSD1307FB_SET_COM_PINS_CONFIG 0xda
> +#define SSD1307FB_SET_VCOMH 0xdb
> +
> +struct ssd1307fb_par;
> +
> +struct ssd1307fb_ops {
> + int (*init)(struct ssd1307fb_par *);
> + int (*remove)(struct ssd1307fb_par *);
> +};
>
> struct ssd1307fb_par {
> struct i2c_client *client;
> + u32 height;
> struct fb_info *info;
> + struct ssd1307fb_ops *ops;
> + u32 page_offset;
> struct pwm_device *pwm;
> u32 pwm_period;
> int reset;
> + u32 width;
> };
>
> static struct fb_fix_screeninfo ssd1307fb_fix = {
> @@ -43,15 +58,10 @@ static struct fb_fix_screeninfo ssd1307fb_fix = {
> .xpanstep = 0,
> .ypanstep = 0,
> .ywrapstep = 0,
> - .line_length = SSD1307FB_WIDTH / 8,
> .accel = FB_ACCEL_NONE,
> };
>
> static struct fb_var_screeninfo ssd1307fb_var = {
> - .xres = SSD1307FB_WIDTH,
> - .yres = SSD1307FB_HEIGHT,
> - .xres_virtual = SSD1307FB_WIDTH,
> - .yres_virtual = SSD1307FB_HEIGHT,
> .bits_per_pixel = 1,
> };
>
> @@ -134,16 +144,16 @@ static void ssd1307fb_update_display(struct ssd1307fb_par *par)
> * (5) A4 B4 C4 D4 E4 F4 G4 H4
> */
>
> - for (i = 0; i < (SSD1307FB_HEIGHT / 8); i++) {
> - ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS + (i + 1));
> + for (i = 0; i < (par->height / 8); i++) {
> + ssd1307fb_write_cmd(par->client, SSD1307FB_START_PAGE_ADDRESS + i + par->page_offset);
> ssd1307fb_write_cmd(par->client, 0x00);
> ssd1307fb_write_cmd(par->client, 0x10);
>
> - for (j = 0; j < SSD1307FB_WIDTH; j++) {
> + for (j = 0; j < par->width; j++) {
> u8 buf = 0;
> for (k = 0; k < 8; k++) {
> - u32 page_length = SSD1307FB_WIDTH * i;
> - u32 index = page_length + (SSD1307FB_WIDTH * k + j) / 8;
> + u32 page_length = par->width * i;
> + u32 index = page_length + (par->width * k + j) / 8;
> u8 byte = *(vmem + index);
> u8 bit = byte & (1 << (j % 8));
> bit = bit >> (j % 8);
> @@ -227,16 +237,137 @@ static struct fb_deferred_io ssd1307fb_defio = {
> .deferred_io = ssd1307fb_deferred_io,
> };
>
> +static int ssd1307fb_ssd1307_init(struct ssd1307fb_par *par) {
> + int ret;
> +
> + par->pwm = pwm_get(&par->client->dev, NULL);
> + if (IS_ERR(par->pwm)) {
> + dev_err(&par->client->dev, "Could not get PWM from device tree!\n");
> + return PTR_ERR(par->pwm);
> + }
> +
> + par->pwm_period = pwm_get_period(par->pwm);
> + /* Enable the PWM */
> + pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
> + pwm_enable(par->pwm);
> +
> + dev_dbg(&par->client->dev, "Using PWM%d with a %dns period.\n", par->pwm->pwm, par->pwm_period);
> +
> + /* Map column 127 of the OLED to segment 0 */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
> + if (ret < 0)
> + return ret;
> +
> + /* Turn on the display */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int ssd1307fb_ssd1307_remove(struct ssd1307fb_par *par) {
> + pwm_disable(par->pwm);
> + pwm_put(par->pwm);
> + return 0;
> +}
> +
> +static struct ssd1307fb_ops ssd1307fb_ssd1307_ops = {
> + .init = ssd1307fb_ssd1307_init,
> + .remove = ssd1307fb_ssd1307_remove,
> +};
> +
> +static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par) {
> + int ret;
> +
> + /* Set initial contrast */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CONTRAST);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0x7f);
> + if (ret < 0)
> + return ret;
> +
> + /* Set COM direction */
> + ret = ssd1307fb_write_cmd(par->client, 0xc8);
> + if (ret < 0)
> + return ret;
> +
> + /* Set segment re-map */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
> + if (ret < 0)
> + return ret;
> +
> + /* Set multiplex ratio value */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_MULTIPLEX_RATIO);
> + ret = ret & ssd1307fb_write_cmd(par->client, par->height - 1);
> + if (ret < 0)
> + return ret;
> +
> + /* set display offset value */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_DISPLAY_OFFSET);
> + ret = ssd1307fb_write_cmd(par->client, 0x20);
> + if (ret < 0)
> + return ret;
> +
> + /* Set clock frequency */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_CLOCK_FREQ);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0xf0);
> + if (ret < 0)
> + return ret;
> +
> + /* Set precharge period in number of ticks from the internal clock */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_PRECHARGE_PERIOD);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0x22);
> + if (ret < 0)
> + return ret;
> +
> + /* Set COM pins configuration */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COM_PINS_CONFIG);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0x22);
> + if (ret < 0)
> + return ret;
> +
> + /* Set VCOMH */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_VCOMH);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0x49);
> + if (ret < 0)
> + return ret;
> +
> + /* Turn on the DC-DC Charge Pump */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CHARGE_PUMP);
> + ret = ret & ssd1307fb_write_cmd(par->client, 0x14);
> + if (ret < 0)
> + return ret;
> +
> + /* Turn on the display */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static struct ssd1307fb_ops ssd1307fb_ssd1306_ops = {
> + .init = ssd1307fb_ssd1306_init,
> +};
> +
> +static const struct of_device_id ssd1307fb_of_match[] = {
> + { .compatible = "solomon,ssd1306fb-i2c", .data = (void*)&ssd1307fb_ssd1306_ops },
> + { .compatible = "solomon,ssd1307fb-i2c", .data = (void*)&ssd1307fb_ssd1307_ops },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
> +
> static int ssd1307fb_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> struct fb_info *info;
> - u32 vmem_size = SSD1307FB_WIDTH * SSD1307FB_HEIGHT / 8;
> + struct device_node *node = client->dev.of_node;
> + u32 vmem_size;
> struct ssd1307fb_par *par;
> u8 *vmem;
> int ret;
>
> - if (!client->dev.of_node) {
> + if (!node) {
why this will be DT only?
a platform or ARN that does not support DT can not use this driver
this looks not right
> dev_err(&client->dev, "No device tree data found!\n");
> return -EINVAL;
> }
> @@ -247,6 +378,36 @@ static int ssd1307fb_probe(struct i2c_client *client,
> return -ENOMEM;
> }
>
> + par = info->par;
> + par->info = info;
> + par->client = client;
> +
> + par->ops = (struct ssd1307fb_ops*)of_match_device(ssd1307fb_of_match, &client->dev)->data;
> +
> + par->reset = of_get_named_gpio(client->dev.of_node,
> + "reset-gpios", 0);
> + if (!gpio_is_valid(par->reset)) {
> + ret = -EINVAL;
> + goto fb_alloc_error;
> + }
> +
> + if (of_property_read_u32(node, "solomon,width", &par->width))
> + par->width = 96;
> +
> + printk("Width\t%u\n", par->width);
> +
> + if (of_property_read_u32(node, "solomon,height", &par->height))
> + par->width = 16;
> +
> + printk("Height\t%u\n", par->height);
> +
> + if (of_property_read_u32(node, "solomon,page-offset", &par->page_offset))
> + par->page_offset = 1;
> +
> + printk("Offset\t%u\n", par->page_offset);
> +
> + vmem_size = par->width * par->height / 8;
> +
> vmem = devm_kzalloc(&client->dev, vmem_size, GFP_KERNEL);
> if (!vmem) {
> dev_err(&client->dev, "Couldn't allocate graphical memory.\n");
> @@ -256,9 +417,15 @@ static int ssd1307fb_probe(struct i2c_client *client,
>
> info->fbops = &ssd1307fb_ops;
> info->fix = ssd1307fb_fix;
> + info->fix.line_length = par->width / 8;
> info->fbdefio = &ssd1307fb_defio;
>
> info->var = ssd1307fb_var;
> + info->var.xres = par->width;
> + info->var.xres_virtual = par->width;
> + info->var.yres = par->height;
> + info->var.yres_virtual = par->height;
> +
> info->var.red.length = 1;
> info->var.red.offset = 0;
> info->var.green.length = 1;
> @@ -272,17 +439,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
>
> fb_deferred_io_init(info);
>
> - par = info->par;
> - par->info = info;
> - par->client = client;
> -
> - par->reset = of_get_named_gpio(client->dev.of_node,
> - "reset-gpios", 0);
> - if (!gpio_is_valid(par->reset)) {
> - ret = -EINVAL;
> - goto reset_oled_error;
> - }
> -
> ret = devm_gpio_request_one(&client->dev, par->reset,
> GPIOF_OUT_INIT_HIGH,
> "oled-reset");
> @@ -293,23 +449,6 @@ static int ssd1307fb_probe(struct i2c_client *client,
> goto reset_oled_error;
> }
>
> - par->pwm = pwm_get(&client->dev, NULL);
> - if (IS_ERR(par->pwm)) {
> - dev_err(&client->dev, "Could not get PWM from device tree!\n");
> - ret = PTR_ERR(par->pwm);
> - goto pwm_error;
> - }
> -
> - par->pwm_period = pwm_get_period(par->pwm);
> -
> - dev_dbg(&client->dev, "Using PWM%d with a %dns period.\n", par->pwm->pwm, par->pwm_period);
> -
> - ret = register_framebuffer(info);
> - if (ret) {
> - dev_err(&client->dev, "Couldn't register the framebuffer\n");
> - goto fbreg_error;
> - }
> -
> i2c_set_clientdata(client, info);
>
> /* Reset the screen */
> @@ -318,34 +457,25 @@ static int ssd1307fb_probe(struct i2c_client *client,
> gpio_set_value(par->reset, 1);
> udelay(4);
>
> - /* Enable the PWM */
> - pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
> - pwm_enable(par->pwm);
> -
> - /* Map column 127 of the OLED to segment 0 */
> - ret = ssd1307fb_write_cmd(client, SSD1307FB_SEG_REMAP_ON);
> - if (ret < 0) {
> - dev_err(&client->dev, "Couldn't remap the screen.\n");
> - goto remap_error;
> + if (par->ops->init) {
> + ret = par->ops->init(par);
> + if (ret)
> + goto reset_oled_error;
> }
>
> - /* Turn on the display */
> - ret = ssd1307fb_write_cmd(client, SSD1307FB_DISPLAY_ON);
> - if (ret < 0) {
> - dev_err(&client->dev, "Couldn't turn the display on.\n");
> - goto remap_error;
> + ret = register_framebuffer(info);
> + if (ret) {
> + dev_err(&client->dev, "Couldn't register the framebuffer\n");
> + goto panel_init_error;
> }
>
> dev_info(&client->dev, "fb%d: %s framebuffer device registered, using %d bytes of video memory\n", info->node, info->fix.id, vmem_size);
>
> return 0;
>
> -remap_error:
> - unregister_framebuffer(info);
> - pwm_disable(par->pwm);
> -fbreg_error:
> - pwm_put(par->pwm);
> -pwm_error:
> +panel_init_error:
> + if (par->ops->remove)
> + par->ops->remove(par);
> reset_oled_error:
> fb_deferred_io_cleanup(info);
> fb_alloc_error:
> @@ -359,8 +489,8 @@ static int ssd1307fb_remove(struct i2c_client *client)
> struct ssd1307fb_par *par = info->par;
>
> unregister_framebuffer(info);
> - pwm_disable(par->pwm);
> - pwm_put(par->pwm);
> + if (par->ops->remove)
> + par->ops->remove(par);
> fb_deferred_io_cleanup(info);
> framebuffer_release(info);
>
> @@ -368,17 +498,12 @@ static int ssd1307fb_remove(struct i2c_client *client)
> }
>
> static const struct i2c_device_id ssd1307fb_i2c_id[] = {
> + { "ssd1306fb", 0 },
> { "ssd1307fb", 0 },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, ssd1307fb_i2c_id);
>
> -static const struct of_device_id ssd1307fb_of_match[] = {
> - { .compatible = "solomon,ssd1307fb-i2c" },
> - {},
> -};
> -MODULE_DEVICE_TABLE(of, ssd1307fb_of_match);
> -
> static struct i2c_driver ssd1307fb_driver = {
> .probe = ssd1307fb_probe,
> .remove = ssd1307fb_remove,
> --
> 1.7.10.4
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: [PATCH 0/5] video: vt8500 patches for 3.10
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-03-29 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1364021193-19835-1-git-send-email-linux@prisktech.co.nz>
On 19:46 Sat 23 Mar , Tony Prisk wrote:
> Hi Florian,
>
> These patches were posted for 3.9, but I didn't recieve any reply back at the
> time. Reposting for 3.10 - based on 3.9-rc2
>
> Regards
> Tony P
look ok
Best Regards,
J.
>
> Julia Lawall (1):
> drivers/video/wm8505fb.c: use devm_ functions
>
> Tony Prisk (4):
> video: vt8500: Make wmt_ge_rops optional
> video: vt8500: Remove unused platform_data/video-vt8500lcdfb.h
> video: vt8500: Correct descriptions in video/Kconfig
> video: vt8500: Adjust contrast in wm8505 framebuffer driver.
>
> drivers/video/Kconfig | 31 ++++----
> drivers/video/vt8500lcdfb.c | 17 +++-
> drivers/video/wm8505fb.c | 96 ++++++++---------------
> include/linux/platform_data/video-vt8500lcdfb.h | 31 --------
> 4 files changed, 66 insertions(+), 109 deletions(-)
> delete mode 100644 include/linux/platform_data/video-vt8500lcdfb.h
>
> --
> 1.7.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] video: ssd1307fb: Add support for SSD1306 OLED controller
From: Maxime Ripard @ 2013-03-29 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130329183842.GH20693@game.jcrosoft.org>
Hi Jean Christophe,
Le 29/03/2013 19:38, Jean-Christophe PLAGNIOL-VILLARD a écrit :
> On 17:44 Wed 06 Mar , Maxime Ripard wrote:
[snip]
>> static int ssd1307fb_probe(struct i2c_client *client,
>> const struct i2c_device_id *id)
>> {
>> struct fb_info *info;
>> - u32 vmem_size = SSD1307FB_WIDTH * SSD1307FB_HEIGHT / 8;
>> + struct device_node *node = client->dev.of_node;
>> + u32 vmem_size;
>> struct ssd1307fb_par *par;
>> u8 *vmem;
>> int ret;
>>
>> - if (!client->dev.of_node) {
>> + if (!node) {
> why this will be DT only?
>
> a platform or ARN that does not support DT can not use this driver
>
> this looks not right
Because the platform I was developing that for was DT-only, and I guess
if someone wants to use this driver on a non-DT platform, that
hypothetical someone can always send a patch to enable the "old-style"
probing in this driver.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] drivers/video: fsl-diu-fb: add hardware cursor support
From: Timur Tabi @ 2013-03-30 0:36 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1358281046-31552-1-git-send-email-timur@tabi.org>
The Freescale DIU supports a 32x32 color hardware cursor. Framebuffer
cursors are monochrome, so the driver converts the image data to the
format that the DIU expects and then programs to hardware accordingly.
The support cursor enabling/disabling, we provide two cursor image buffers.
One is always blank (all zeroes), and the other contains the real cursor
image data. To disable the cursor (used typically for cursor blinking),
we just tell the hardware to use the blank cursor data.
Signed-off-by: Timur Tabi <timur@tabi.org>
---
drivers/video/fsl-diu-fb.c | 157 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 155 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index 41fbd94..6c27805 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -375,7 +375,10 @@ struct fsl_diu_data {
struct diu_ad dummy_ad __aligned(8);
struct diu_ad ad[NUM_AOIS] __aligned(8);
u8 gamma[256 * 3] __aligned(32);
- u8 cursor[MAX_CURS * MAX_CURS * 2] __aligned(32);
+ /* It's easier to parse the cursor data as little-endian */
+ __le16 cursor[MAX_CURS * MAX_CURS] __aligned(32);
+ /* Blank cursor data -- used to hide the cursor */
+ __le16 blank_cursor[MAX_CURS * MAX_CURS] __aligned(32);
uint8_t edid_data[EDID_LENGTH];
bool has_edid;
} __aligned(32);
@@ -824,7 +827,6 @@ static void update_lcdc(struct fb_info *info)
/* Program DIU registers */
out_be32(&hw->gamma, DMA_ADDR(data, gamma));
- out_be32(&hw->cursor, DMA_ADDR(data, cursor));
out_be32(&hw->bgnd, 0x007F7F7F); /* Set background to grey */
out_be32(&hw->disp_size, (var->yres << 16) | var->xres);
@@ -968,6 +970,156 @@ static u32 fsl_diu_get_pixel_format(unsigned int bits_per_pixel)
}
/*
+ * Copies a cursor image from user space to the proper place in driver
+ * memory so that the hardware can display the cursor image.
+ *
+ * Cursor data is represented as a sequence of 'width' bits packed into bytes.
+ * That is, the first 8 bits are in the first byte, the second 8 bits in the
+ * second byte, and so on. Therefore, the each row of the cursor is (width +
+ * 7) / 8 bytes of 'data'
+ *
+ * The DIU only supports cursors up to 32x32 (MAX_CURS). We reject cursors
+ * larger than this, so we already know that 'width' <= 32. Therefore, we can
+ * simplify our code by using a 32-bit big-endian integer ("line") to read in
+ * a single line of pixels, and only look at the top 'width' bits of that
+ * integer.
+ *
+ * This could result in an unaligned 32-bit read. For example, if the cursor
+ * is 24x24, then the first three bytes of 'image' contain the pixel data for
+ * the top line of the cursor. We do a 32-bit read of 'image', but we look
+ * only at the top 24 bits. Then we increment 'image' by 3 bytes. The next
+ * read is unaligned. The only problem is that we might read past the end of
+ * 'image' by 1-3 bytes, but that should not cause any problems.
+ */
+static void fsl_diu_load_cursor_image(struct fb_info *info,
+ const void *image, uint16_t bg, uint16_t fg,
+ unsigned int width, unsigned int height)
+{
+ struct mfb_info *mfbi = info->par;
+ struct fsl_diu_data *data = mfbi->parent;
+ __le16 *cursor = data->cursor;
+ __le16 _fg = cpu_to_le16(fg);
+ __le16 _bg = cpu_to_le16(bg);
+ unsigned int h, w;
+
+ for (h = 0; h < height; h++) {
+ uint32_t mask = 1 << 31;
+ uint32_t line = be32_to_cpup(image);
+
+ for (w = 0; w < width; w++) {
+ cursor[w] = (line & mask) ? _fg : _bg;
+ mask >>= 1;
+ }
+
+ cursor += MAX_CURS;
+ image += DIV_ROUND_UP(width, 8);
+ }
+}
+
+/*
+ * Set a hardware cursor. The image data for the cursor is passed via the
+ * fb_cursor object.
+ */
+static int fsl_diu_cursor(struct fb_info *info, struct fb_cursor *cursor)
+{
+ struct mfb_info *mfbi = info->par;
+ struct fsl_diu_data *data = mfbi->parent;
+ struct diu __iomem *hw = data->diu_reg;
+
+ if (cursor->image.width > MAX_CURS || cursor->image.height > MAX_CURS)
+ return -EINVAL;
+
+ /* The cursor size has changed */
+ if (cursor->set & FB_CUR_SETSIZE) {
+ /*
+ * The DIU cursor is a fixed size, so when we get this
+ * message, instead of resizing the cursor, we just clear
+ * all the image data, in expectation of new data. However,
+ * in tests this control does not appear to be normally
+ * called.
+ */
+ memset(data->cursor, 0, sizeof(data->cursor));
+ }
+
+ /* The cursor position has changed (cursor->image.dx|dy) */
+ if (cursor->set & FB_CUR_SETPOS) {
+ uint32_t xx, yy;
+
+ yy = (cursor->image.dy - info->var.yoffset) & 0x7ff;
+ xx = (cursor->image.dx - info->var.xoffset) & 0x7ff;
+
+ out_be32(&hw->curs_pos, yy << 16 | xx);
+ }
+
+ /*
+ * FB_CUR_SETIMAGE - the cursor image has changed
+ * FB_CUR_SETCMAP - the cursor colors has changed
+ * FB_CUR_SETSHAPE - the cursor bitmask has changed
+ */
+ if (cursor->set & (FB_CUR_SETSHAPE | FB_CUR_SETCMAP | FB_CUR_SETIMAGE)) {
+ unsigned int image_size + DIV_ROUND_UP(cursor->image.width, 8) * cursor->image.height;
+ unsigned int image_words + DIV_ROUND_UP(image_size, sizeof(uint32_t));
+ unsigned int bg_idx = cursor->image.bg_color;
+ unsigned int fg_idx = cursor->image.fg_color;
+ uint8_t buffer[image_size];
+ uint32_t *image, *source, *mask;
+ uint16_t fg, bg;
+ unsigned int i;
+
+ if (info->state != FBINFO_STATE_RUNNING)
+ return 0;
+
+ /*
+ * Determine the size of the cursor image data. Normally,
+ * it's 8x16.
+ */
+ image_size = DIV_ROUND_UP(cursor->image.width, 8) *
+ cursor->image.height;
+
+ bg = ((info->cmap.red[bg_idx] & 0xf8) << 7) |
+ ((info->cmap.green[bg_idx] & 0xf8) << 2) |
+ ((info->cmap.blue[bg_idx] & 0xf8) >> 3) |
+ 1 << 15;
+
+ fg = ((info->cmap.red[fg_idx] & 0xf8) << 7) |
+ ((info->cmap.green[fg_idx] & 0xf8) << 2) |
+ ((info->cmap.blue[fg_idx] & 0xf8) >> 3) |
+ 1 << 15;
+
+ /* Use 32-bit operations on the data to improve performance */
+ image = (uint32_t *)buffer;
+ source = (uint32_t *)cursor->image.data;
+ mask = (uint32_t *)cursor->mask;
+
+ if (cursor->rop = ROP_XOR)
+ for (i = 0; i < image_words; i++)
+ image[i] = source[i] ^ mask[i];
+ else
+ for (i = 0; i < image_words; i++)
+ image[i] = source[i] & mask[i];
+
+ fsl_diu_load_cursor_image(info, image, bg, fg,
+ cursor->image.width, cursor->image.height);
+ };
+
+ /*
+ * Show or hide the cursor. The cursor data is always stored in the
+ * 'cursor' memory block, and the actual cursor position is always in
+ * the DIU's CURS_POS register. To hide the cursor, we redirect the
+ * CURSOR register to a blank cursor. The show the cursor, we
+ * redirect the CURSOR register to the real cursor data.
+ */
+ if (cursor->enable)
+ out_be32(&hw->cursor, DMA_ADDR(data, cursor));
+ else
+ out_be32(&hw->cursor, DMA_ADDR(data, blank_cursor));
+
+ return 0;
+}
+
+/*
* Using the fb_var_screeninfo in fb_info we set the resolution of this
* particular framebuffer. This function alters the fb_fix_screeninfo stored
* in fb_info. It does not alter var in fb_info since we are using that
@@ -1312,6 +1464,7 @@ static struct fb_ops fsl_diu_ops = {
.fb_ioctl = fsl_diu_ioctl,
.fb_open = fsl_diu_open,
.fb_release = fsl_diu_release,
+ .fb_cursor = fsl_diu_cursor,
};
static int install_fb(struct fb_info *info)
--
1.7.11.7
^ permalink raw reply related
* [PATCH]video:uvesafb: Fix dereference NULL pointer code path
From: Wang YanQing @ 2013-03-30 2:53 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: spock, linux-fbdev, FlorianSchandinat, linux-kernel
platform_device_alloc could failed and return NULL,
we should check this before call platform_device_put.
Signed-off-by: Wang YanQing <udknight@gmail.com>
---
drivers/video/uvesafb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 2f8f82d..230bd45 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -1975,7 +1975,8 @@ static int __devinit uvesafb_init(void)
err = -ENOMEM;
if (err) {
- platform_device_put(uvesafb_device);
+ if (uvesafb_device)
+ platform_device_put(uvesafb_device);
platform_driver_unregister(&uvesafb_driver);
cn_del_callback(&uvesafb_cn_id);
return err;
--
1.7.11.1.116.g8228a23
^ permalink raw reply related
* Re: [PATCH 0/5] video: vt8500 patches for 3.10
From: Tony Prisk @ 2013-03-30 21:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130329184413.GJ20693@game.jcrosoft.org>
On 30/03/13 07:44, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 19:46 Sat 23 Mar , Tony Prisk wrote:
>> Hi Florian,
>>
>> These patches were posted for 3.9, but I didn't recieve any reply back at the
>> time. Reposting for 3.10 - based on 3.9-rc2
>>
>> Regards
>> Tony P
> look ok
>
> Best Regards,
> J.
>
Jean-Christope,
Can I add a reviewed-by for these patches?
Regards
Tony P
^ 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