* [PATCH v17 4/7] fbmon: add videomode helpers
From: Steffen Trumtrar @ 2013-01-25 9:01 UTC (permalink / raw)
To: devicetree-discuss, Dave Airlie
Cc: Steffen Trumtrar, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren,
Florian Tobias Schandinat, Rob Clark, Leela Krishna Amudala,
Mohammed, Afzal, kernel
In-Reply-To: <1359104515-8907-1-git-send-email-s.trumtrar@pengutronix.de>
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Afzal Mohammed <Afzal@ti.com>
Tested-by: Rob Clark <robclark@gmail.com>
Tested-by: Leela Krishna Amudala <leelakrishna.a@gmail.com>
---
drivers/video/fbmon.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/fb.h | 4 ++++
2 files changed, 56 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..17ce135 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include <linux/pci.h>
#include <linux/slab.h>
#include <video/edid.h>
+#include <video/videomode.h>
#ifdef CONFIG_PPC_OF
#include <asm/prom.h>
#include <asm/pci-bridge.h>
@@ -1373,6 +1374,57 @@ int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var, struct fb_inf
kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ fbmode->xres = vm->hactive;
+ fbmode->left_margin = vm->hback_porch;
+ fbmode->right_margin = vm->hfront_porch;
+ fbmode->hsync_len = vm->hsync_len;
+
+ fbmode->yres = vm->vactive;
+ fbmode->upper_margin = vm->vback_porch;
+ fbmode->lower_margin = vm->vfront_porch;
+ fbmode->vsync_len = vm->vsync_len;
+
+ /* prevent division by zero in KHZ2PICOS macro */
+ fbmode->pixclock = vm->pixelclock ?
+ KHZ2PICOS(vm->pixelclock / 1000) : 0;
+
+ fbmode->sync = 0;
+ 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)
+ fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
+ fbmode->vmode |= FB_VMODE_INTERLACED;
+ if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
+ fbmode->vmode |= FB_VMODE_DOUBLE;
+ fbmode->flag = 0;
+
+ htotal = vm->hactive + vm->hfront_porch + vm->hback_porch +
+ vm->hsync_len;
+ vtotal = vm->vactive + vm->vfront_porch + vm->vback_porch +
+ vm->vsync_len;
+ /* prevent division by zero */
+ if (htotal && vtotal) {
+ fbmode->refresh = vm->pixelclock / (htotal * vtotal);
+ /* a mode must have htotal and vtotal != 0 or it is invalid */
+ } else {
+ fbmode->refresh = 0;
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..100a176 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
struct fb_info;
struct device;
struct file;
+struct videomode;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -714,6 +715,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode);
+
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 34
extern void fb_var_to_videomode(struct fb_videomode *mode,
--
1.7.10.4
^ permalink raw reply related
* [PATCH v17 5/7] fbmon: add of_videomode helpers
From: Steffen Trumtrar @ 2013-01-25 9:01 UTC (permalink / raw)
To: devicetree-discuss, Dave Airlie
Cc: Steffen Trumtrar, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren,
Florian Tobias Schandinat, Rob Clark, Leela Krishna Amudala,
Mohammed, Afzal, kernel
In-Reply-To: <1359104515-8907-1-git-send-email-s.trumtrar@pengutronix.de>
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Afzal Mohammed <Afzal@ti.com>
Tested-by: Rob Clark <robclark@gmail.com>
Tested-by: Leela Krishna Amudala <leelakrishna.a@gmail.com>
---
drivers/video/fbmon.c | 42 ++++++++++++++++++++++++++++++++++++++++++
include/linux/fb.h | 4 ++++
2 files changed, 46 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 17ce135..94ad0f7 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include <linux/pci.h>
#include <linux/slab.h>
#include <video/edid.h>
+#include <video/of_videomode.h>
#include <video/videomode.h>
#ifdef CONFIG_PPC_OF
#include <asm/prom.h>
@@ -1425,6 +1426,47 @@ int fb_videomode_from_videomode(const struct videomode *vm,
EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static inline void dump_fb_videomode(const struct fb_videomode *m)
+{
+ pr_debug("fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u %u\n",
+ m->xres, m->yres, m->refresh, m->pixclock, m->left_margin,
+ m->right_margin, m->upper_margin, m->lower_margin,
+ m->hsync_len, m->vsync_len, m->sync, m->vmode, m->flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+ int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, &vm, index);
+ if (ret)
+ return ret;
+
+ fb_videomode_from_videomode(&vm, fb);
+
+ pr_debug("%s: got %dx%d display mode from %s\n",
+ of_node_full_name(np), vm.hactive, vm.vactive, np->name);
+ dump_fb_videomode(fb);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
+#endif
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 100a176..58b9860 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -20,6 +20,7 @@ struct fb_info;
struct device;
struct file;
struct videomode;
+struct device_node;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -715,6 +716,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+extern int of_get_fb_videomode(struct device_node *np,
+ struct fb_videomode *fb,
+ int index);
extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v17 6/7] drm_modes: add videomode helpers
From: Steffen Trumtrar @ 2013-01-25 9:01 UTC (permalink / raw)
To: devicetree-discuss, Dave Airlie
Cc: Steffen Trumtrar, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren,
Florian Tobias Schandinat, Rob Clark, Leela Krishna Amudala,
Mohammed, Afzal, kernel
In-Reply-To: <1359104515-8907-1-git-send-email-s.trumtrar@pengutronix.de>
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Afzal Mohammed <Afzal@ti.com>
Tested-by: Rob Clark <robclark@gmail.com>
Tested-by: Leela Krishna Amudala <leelakrishna.a@gmail.com>
---
drivers/gpu/drm/drm_modes.c | 37 +++++++++++++++++++++++++++++++++++++
include/drm/drmP.h | 5 +++++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d8da30e..9f3f20b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
#include <linux/export.h>
#include <drm/drmP.h>
#include <drm/drm_crtc.h>
+#include <video/videomode.h>
/**
* drm_mode_debug_printmodeline - debug print a mode
@@ -504,6 +505,42 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int vdisplay, int vrefresh,
}
EXPORT_SYMBOL(drm_gtf_mode);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode)
+{
+ dmode->hdisplay = vm->hactive;
+ dmode->hsync_start = dmode->hdisplay + vm->hfront_porch;
+ dmode->hsync_end = dmode->hsync_start + vm->hsync_len;
+ dmode->htotal = dmode->hsync_end + vm->hback_porch;
+
+ dmode->vdisplay = vm->vactive;
+ dmode->vsync_start = dmode->vdisplay + vm->vfront_porch;
+ dmode->vsync_end = dmode->vsync_start + vm->vsync_len;
+ dmode->vtotal = dmode->vsync_end + vm->vback_porch;
+
+ dmode->clock = vm->pixelclock / 1000;
+
+ dmode->flags = 0;
+ if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
+ dmode->flags |= DRM_MODE_FLAG_PHSYNC;
+ else if (vm->dmt_flags & VESA_DMT_HSYNC_LOW)
+ dmode->flags |= DRM_MODE_FLAG_NHSYNC;
+ if (vm->dmt_flags & VESA_DMT_VSYNC_HIGH)
+ dmode->flags |= DRM_MODE_FLAG_PVSYNC;
+ else if (vm->dmt_flags & VESA_DMT_VSYNC_LOW)
+ dmode->flags |= DRM_MODE_FLAG_NVSYNC;
+ if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
+ dmode->flags |= DRM_MODE_FLAG_INTERLACE;
+ if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
+ dmode->flags |= DRM_MODE_FLAG_DBLSCAN;
+ drm_mode_set_name(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index fad21c9..d5c06ff 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,8 @@ struct module;
struct drm_file;
struct drm_device;
+struct videomode;
+
#include <drm/drm_os_linux.h>
#include <drm/drm_hashtab.h>
#include <drm/drm_mm.h>
@@ -1456,6 +1458,9 @@ extern struct drm_display_mode *
drm_mode_create_from_cmdline_mode(struct drm_device *dev,
struct drm_cmdline_mode *cmd);
+extern int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode);
+
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v17 7/7] drm_modes: add of_videomode helpers
From: Steffen Trumtrar @ 2013-01-25 9:01 UTC (permalink / raw)
To: devicetree-discuss, Dave Airlie
Cc: Steffen Trumtrar, Rob Herring, linux-fbdev, dri-devel,
Laurent Pinchart, Thierry Reding, Guennady Liakhovetski,
linux-media, Tomi Valkeinen, Stephen Warren,
Florian Tobias Schandinat, Rob Clark, Leela Krishna Amudala,
Mohammed, Afzal, kernel
In-Reply-To: <1359104515-8907-1-git-send-email-s.trumtrar@pengutronix.de>
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Afzal Mohammed <Afzal@ti.com>
Tested-by: Rob Clark <robclark@gmail.com>
Tested-by: Leela Krishna Amudala <leelakrishna.a@gmail.com>
---
drivers/gpu/drm/drm_modes.c | 33 +++++++++++++++++++++++++++++++++
include/drm/drmP.h | 4 ++++
2 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 9f3f20b..04fa6f1 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
#include <linux/export.h>
#include <drm/drmP.h>
#include <drm/drm_crtc.h>
+#include <video/of_videomode.h>
#include <video/videomode.h>
/**
@@ -541,6 +542,38 @@ int drm_display_mode_from_videomode(const struct videomode *vm,
EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode, int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, &vm, index);
+ if (ret)
+ return ret;
+
+ drm_display_mode_from_videomode(&vm, dmode);
+
+ pr_debug("%s: got %dx%d display mode from %s\n",
+ of_node_full_name(np), vm.hactive, vm.vactive, np->name);
+ drm_mode_debug_printmodeline(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d5c06ff..fcc9d23 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,7 @@ struct module;
struct drm_file;
struct drm_device;
+struct device_node;
struct videomode;
#include <drm/drm_os_linux.h>
@@ -1460,6 +1461,9 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
extern int drm_display_mode_from_videomode(const struct videomode *vm,
struct drm_display_mode *dmode);
+extern int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
+ int index);
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
--
1.7.10.4
^ permalink raw reply related
* RE: RE: [PATCH v4 12/12] video: da8xx-fb: CCF clock divider handling
From: Mohammed, Afzal @ 2013-01-25 12:05 UTC (permalink / raw)
To: Mike Turquette, linux-fbdev@vger.kernel.org,
linux-omap@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Florian Tobias Schandinat, Valkeinen, Tomi, Grant Likely,
Rob Herring, Rob Landley
In-Reply-To: <20130124170044.10623.45314@quantum>
SGkgTWlrZSwNCg0KT24gVGh1LCBKYW4gMjQsIDIwMTMgYXQgMjI6MzA6NDQsIE1pa2UgVHVycXVl
dHRlIHdyb3RlOg0KPiBRdW90aW5nIE1vaGFtbWVkLCBBZnphbCAoMjAxMy0wMS0yNCAwMzozNjow
MikNCg0KPiA+IFNvIHRoZXJlIGFyZSAzIC0gTElERCBpcyBhY3R1YWxseSBub3QgZm9yIHByZXNl
bnQgdXNlIGNhc2UsIENPUkUgY291bGQNCj4gPiBiZSBjbHViYmVkIHdpdGggdGhlIGRpdmlkZXIg
dG8gaGF2ZSBhIGNvbXBvc2l0ZSBjbG9jay4gQW5kIENPUkUgaXMNCj4gPiBpbiBmdW5jdGlvbmFs
IGNsb2NrIHBhdGggYW5kIGxvZ2ljYWxseSBpdCdzIHBlcmZlY3RseSBhbHJpZ2h0IHRvIGhhdmUN
Cj4gPiB0aGUgY29tcG9zaXRlIGNsb2NrLg0KDQo+IFNvbWUgb2YgdGhlIGNsb2NrIG5hbWVzIGFy
ZSBhIGJpdCBnZW5lcmljLCBzbyBhIHF1ZXN0aW9uIHRoYXQgSSdtIGdvaW5nDQo+IHRvIHJlcGVh
dCB0aHJvdWdob3V0IG15IHJlc3BvbnNlOiAiaXMgdGhpcyBjbG9jayBvbmx5IGluc2lkZSBvZiB5
b3VyDQo+IHZpZGVvIElQID8iDQoNClllcyB0aGVzZSB0aHJlZSBjbG9ja3MgYXJlIGluc2lkZSBM
Q0RDIElQLg0KDQo+IFJlZ2FyZGluZyB0aGUgQ09SRSBjbG9jaywgaXMgdGhpcyBvbmx5IGluc2lk
ZSBvZiB5b3VyIElQIG9yIGFyZSB5b3UNCj4gcmVmZXJyaW5nIHRvIHRoZSBTb0MgQ09SRSBjbG9j
ayB3aGljaCBpcyBkcml2ZW4gYnkgYSBEUExMIGFuZCBjbG9ja3MNCj4gRERSIGFuZCBtYW55IG90
aGVyIHBlcmlwaGVyYWxzIChvZnRlbiBNTUMsIFVBUlQsIGV0Yyk/DQoNClNvcnJ5IGZvciB0aGUg
Y29uZnVzaW9uLCBoZXJlIENPUkUgcmVmZXJzIHRvIGNsb2NrIGluc2lkZSBMQ0RDIElQLiBUaGlz
DQpDT1JFIHNob3VsZCBub3QgYmUgY29uZnVzZWQgd2l0aCBDT1JFIFBMTC4gQWN0dWFsbHkgSSB1
c2VkIENPUkUgc28gdGhhdA0KaXQgY29ycmVzcG9uZHMgdG8gdGhlIG5vbWVuY2xhdHVyZSBpbiBM
Q0RDIHNlY3Rpb24gb2YgVFJNLg0KDQo+IE5vdGUgdGhhdCB0aGlzIGlzIGZyb20gbXkgcGFzdCBl
eHBlcmllbmNlIHdpdGggT01BUCwgYW5kIEknbSBtYWtpbmcgYW4NCj4gYXNzdW1wdGlvbiB0aGF0
IHRoZSBjbG9jayBzY2hlbWUgYmV0d2VlbiBPTUFQIGFuZCBEYSBWaW5jaS9BTTMzNXggcGFydHMN
Cj4gaXNuJ3QgdmVyeSBkaWZmZXJlbnQuDQoNCkFkZGl0aW9uYWwgZGV0YWlsOiBEYVZpbmNpIGRv
ZXNuJ3QgaGF2ZSB0aGVzZSAzIGNsb2NrcyBjb250cm9scyBhdmFpbGFibGUsDQpzbyB0aGVzZSB0
aHJlZSBhcmUgcmVxdWlyZWQgb25seSBvbiBBTTMzNXggKHdoaWNoIGhhcyBJUCB2ZXJzaW9uIDIg
KQ0KDQo+IElzIHRoZXJlIGEgcHVibGljIFRSTSBJIGNhbiBsb29rIGF0PyAgSXQgd291bGQgaGVs
cCBtZSB1bmRlcnN0YW5kIHRoaXMNCj4gd2l0aG91dCBoYXZpbmcgdG8gYXNrIHlvdSBzbyBtYW55
IGFubm95aW5nIHF1ZXN0aW9ucyA7KQ0KDQpObyBwcm9ibGVtLCBodHRwOi8vd3d3LnRpLmNvbS9w
cm9kdWN0L2FtMzM1OQ0KDQoNCj4gPiBBbmQgbm93IHdlIGFyZSBsZWZ0IHdpdGggRE1BLCB0aGlz
IGlzIGFjdHVhbGx5IGluIHRoZSBpbnRlcmZhY2UgY2xvY2sNCj4gPiBwYXRoIHdoaWNoIGRyaXZl
ciBpbiB1bmF3YXJlLiBBbiBvcHRpb24gd291bGQgYmUgdG8gaGF2ZSBETUEgY2xvY2sNCj4gPiBh
cyBjaGlsZCBvZiBDT1JFIHBsdXMgZGl2aWRlciBjb21wb3NpdGUgY2xvY2ssIGV2ZW4gdGhvdWdo
IGxvZ2ljYWxseQ0KPiA+IERNQSBjYW4ndCBiZSBjb25zaWRlcmVkIGluIHRoZSBzYW1lIHBhdGgu
DQoNCj4gV2h5IGlzIHRoZSBkcml2ZXIgdW5hd2FyZSBvZiB0aGUgaW50ZXJmYWNlIGNsaz8gIEZv
ciBpbnN0YW5jZSBPTUFQMyBoYWQNCj4gc2VwYXJhdGUgZmNsayBhbmQgaWNsayBmb3IgSVBzIGFu
ZCBkcml2ZXJzIHdvdWxkIGNhbGwgY2xrX2VuYWJsZSBvbg0KPiBib3RoLiAgT3IgYW0gSSBtaXN1
bmRlcnN0YW5kaW5nIHNvbWV0aGluZz8NCg0KSFdNT0QgaGFuZGxlcyBlbmFibGluZyB0aG9zZSB1
cG9uIHBtX3J1bnRpbWUgY2FsbHMsIEhXTU9EIG1ha2VzIGFuIGFsaWFzDQpmb3IgbWFpbiBjbG9j
ayB3aXRoICJmY2siLCBidXQgbm90IGZvciAiaWNrIiwgc28gY3VycmVudGx5ICJpY2siIGlzDQp1
bmF2YWlsYWJsZSBmb3IgdGhlIGRyaXZlciwgY29udGludWVkIGJlbG93IC4uDQoNCj4gSW4gZ2Vu
ZXJhbCBJIGRvbid0IHRoaW5rIHRoZSBjbG9jayBzdWJ0cmVlIHNob3VsZCBiZSBtb2RlbGVkIGlu
IGEgd2F5DQo+IHRoYXQgaXMgY29udmVuaWVudCBmb3Igc29mdHdhcmUsIGJ1dCBpbnN0ZWFkIG1v
ZGVsIHRoZSBhY3R1YWwgaGFyZHdhcmUuDQo+IFRydXN0IG1lLCBpZiB5b3UgZG9uJ3QgbW9kZWwg
dGhlIGFjdHVhbCBoYXJkd2FyZSB0aGVuIHlvdSB3aWxsIGJlIHZlcnkNCj4gY29uZnVzZWQgd2hl
biB5b3UgY29tZSBiYWNrIGFuZCByZXZpc2l0IHRoaXMgY29kZSBpbiA2IG1vbnRocyBhbmQgY2Fu
J3QNCj4gcmVtZW1iZXIgd2h5IHRoaW5ncyBhcmUgc28gd2VpcmQgbG9va2luZy4NCg0KT2ssIHRo
ZW4gaXQgc2VlbXMgYW4gb21hcCBjbG9jayBlbnRyeSBmb3IgY29uLWlkICJpY2siIHNob3VsZCBi
ZSBjcmVhdGVkDQphcyBmb2xsb3dzIChkcGxsX2NvcmVfbTRfY2sgc3VwcGxpZXMgaW50ZXJmYWNl
IGNsb2NrKSwNCg0KQ0xLKCI0ODMwZTAwMC5sY2RjIiwgICAgImljayIsICAgICAgICAgICZkcGxs
X2NvcmVfbTRfY2ssICAgICAgIENLX0FNMzNYWCkNCg0KQW5kIHRoZW4gaW4gdGhlIGRyaXZlciwg
RE1BIGdhdGUgY2xvY2sgc2hvdWxkIGJlIG1hZGUgYSBjaGlsZCBvZiB0aGlzIGNsb2NrDQoob2J0
YWluZWQgd2l0aCBjb24taWQgImljayIpLg0KDQpMZXQgbWUga25vdyB5b3VyIG9waW5pb24gb24g
dGhpcy4NCg0KUmVnYXJkcw0KQWZ6YWwNCg0KDQoNCg=
^ permalink raw reply
* RE: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Mohammed, Afzal @ 2013-01-25 13:19 UTC (permalink / raw)
To: Rob Clark, dri-devel@lists.freedesktop.org
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
patches@linaro.org, linux-fbdev@vger.kernel.org, Mike Turquette
In-Reply-To: <1358894185-21617-2-git-send-email-robdclark@gmail.com>
SGkgUm9iLA0KDQpPbiBXZWQsIEphbiAyMywgMjAxMyBhdCAwNDowNjoyMiwgUm9iIENsYXJrIHdy
b3RlOg0KDQo+IEEgc2ltcGxlIERSTS9LTVMgZHJpdmVyIGZvciB0aGUgVEkgTENEIENvbnRyb2xs
ZXIgZm91bmQgaW4gdmFyaW91cw0KPiBzbWFsbGVyIFRJIHBhcnRzIChBTTMzeHgsIE9NQVBMMTM4
LCBldGMpLiAgVGhpcyBkcml2ZXIgdXNlcyB0aGUNCg0KPiArdm9pZCB0aWxjZGNfY3J0Y191cGRh
dGVfY2xrKHN0cnVjdCBkcm1fY3J0YyAqY3J0YykNCg0KPiArCS8qIGluIHJhc3RlciBtb2RlLCBt
aW5pbXVtIGRpdmlzb3IgaXMgMjogKi8NCj4gKwlyZXQgPSBjbGtfc2V0X3JhdGUocHJpdi0+ZGlz
cF9jbGssIGNydGMtPm1vZGUuY2xvY2sgKiAxMDAwICogMik7DQoNClRoZXNlIHRoaW5ncyBjYW4g
YmV0dGVyIGJlIGhhbmRsZWQgd2l0aCBkaXZpZGVyIGNsb2NrIGhhdmluZyBhDQptaW5pbXVtIHZh
bHVlIChiZWluZyBkaXNjdXNzZWQgd2l0aCBNaWtlIG9uIGhvdyBleGFjdGx5IGl0IHNob3VsZA0K
YmUpIGFuZCBpbnN0ZWFkIG9mIHNldHRpbmcgcmF0ZSBvdmVyIGEgcGxhdGZvcm0gc3BlY2lmaWMg
Y2xvY2ssDQp5b3UgY2FuIHNldCByYXRlIG92ZXIgbGNkIGNsb2NrIHVzaW5nIFNFVF9SQVRFX1BB
UkVOVCBhdCBwbGF0Zm9ybQ0KbGV2ZWwsIG1vcmUgYmVsb3csDQoNCj4gKwkvKiBDb25maWd1cmUg
dGhlIExDRCBjbG9jayBkaXZpc29yLiAqLw0KPiArCXRpbGNkY193cml0ZShkZXYsIExDRENfQ1RS
TF9SRUcsIExDRENfQ0xLX0RJVklTT1IoZGl2KSB8DQo+ICsJCQlMQ0RDX1JBU1RFUl9NT0RFKTsN
Cj4gKw0KPiArCWlmIChwcml2LT5yZXYgPT0gMikNCj4gKwkJdGlsY2RjX3NldChkZXYsIExDRENf
Q0xLX0VOQUJMRV9SRUcsDQo+ICsJCQkJTENEQ19WMl9ETUFfQ0xLX0VOIHwgTENEQ19WMl9MSURE
X0NMS19FTiB8DQo+ICsJCQkJTENEQ19WMl9DT1JFX0NMS19FTik7DQoNCk1pa2Ugd2FzIHN1Z2dl
c3RpbmcgdG8gbW9kZWwgdGhlIGFib3ZlIHVzaW5nIGdhdGUvZGl2aWRlci9jb21wb3NpdGUNCmNs
b2NrcyBvZiBDQ0YgaW4gdGhlIEZCIGRyaXZlci4NCg0KPiArCXByaXYtPmNsayA9IGNsa19nZXQo
ZGV2LT5kZXYsICJmY2siKTsNCj4gKwlpZiAoSVNfRVJSKHByaXYtPmNsaykpIHsNCj4gKwkJZGV2
X2VycihkZXYtPmRldiwgImZhaWxlZCB0byBnZXQgZnVuY3Rpb25hbCBjbG9ja1xuIik7DQo+ICsJ
CXJldCA9IC1FTk9ERVY7DQo+ICsJCWdvdG8gZmFpbDsNCj4gKwl9DQo+ICsNCj4gKwlwcml2LT5k
aXNwX2NsayA9IGNsa19nZXQoZGV2LT5kZXYsICJkcGxsX2Rpc3BfY2siKTsNCj4gKwlpZiAoSVNf
RVJSKHByaXYtPmNsaykpIHsNCj4gKwkJZGV2X2VycihkZXYtPmRldiwgImZhaWxlZCB0byBnZXQg
ZGlzcGxheSBjbG9ja1xuIik7DQo+ICsJCXJldCA9IC1FTk9ERVY7DQo+ICsJCWdvdG8gZmFpbDsN
Cj4gKwl9DQoNCiJkcGxsX2Rpc3BfY2siIGlzIGEgcGxhdGZvcm0gc3BlY2lmaWMgbWF0dGVyLCBk
cml2ZXIgc2hvdWxkIG5vdA0KYmUgaGFuZGxpbmcgcGxhdGZvcm0gc3BlY2lmaWNzLiBBbmQgdGhp
cyB3b24ndCB3b3JrIG9uIERhVmluY2ksDQp5b3UgY2FuIHByb2JhYmx5IG1ha2UgdXNlIG9mDQoN
Cm15IHNlcmllcyAiW1BBVENIIHYyIDAvNF0gQVJNOiBBTTMzNXg6IExDREMgcGxhdGZvcm0gc3Vw
cG9ydCINCg0Kb3Igc29tZXRoaW5nIHNpbWlsYXIgdG8gb3ZlcmNvbWUgdGhpcy4NCg0KUmVnYXJk
cw0KQWZ6YWwNCg0KDQo
^ permalink raw reply
* Re: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Rob Clark @ 2013-01-25 13:59 UTC (permalink / raw)
To: Mohammed, Afzal
Cc: dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, patches@linaro.org,
linux-fbdev@vger.kernel.org, Mike Turquette
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA939BB@DBDE01.ent.ti.com>
On Fri, Jan 25, 2013 at 7:19 AM, Mohammed, Afzal <afzal@ti.com> wrote:
> Hi Rob,
>
> On Wed, Jan 23, 2013 at 04:06:22, Rob Clark wrote:
>
>> A simple DRM/KMS driver for the TI LCD Controller found in various
>> smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
>
>> +void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
>
>> + /* in raster mode, minimum divisor is 2: */
>> + ret = clk_set_rate(priv->disp_clk, crtc->mode.clock * 1000 * 2);
>
> These things can better be handled with divider clock having a
> minimum value (being discussed with Mike on how exactly it should
> be) and instead of setting rate over a platform specific clock,
> you can set rate over lcd clock using SET_RATE_PARENT at platform
> level, more below,
I looked at that patch you were proposing for da8xx-fb.. to be
honest, it did not seem simpler to me, so I was sort of failing to see
the benefit..
>> + /* Configure the LCD clock divisor. */
>> + tilcdc_write(dev, LCDC_CTRL_REG, LCDC_CLK_DIVISOR(div) |
>> + LCDC_RASTER_MODE);
>> +
>> + if (priv->rev = 2)
>> + tilcdc_set(dev, LCDC_CLK_ENABLE_REG,
>> + LCDC_V2_DMA_CLK_EN | LCDC_V2_LIDD_CLK_EN |
>> + LCDC_V2_CORE_CLK_EN);
>
> Mike was suggesting to model the above using gate/divider/composite
> clocks of CCF in the FB driver.
>
>> + priv->clk = clk_get(dev->dev, "fck");
>> + if (IS_ERR(priv->clk)) {
>> + dev_err(dev->dev, "failed to get functional clock\n");
>> + ret = -ENODEV;
>> + goto fail;
>> + }
>> +
>> + priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck");
>> + if (IS_ERR(priv->clk)) {
>> + dev_err(dev->dev, "failed to get display clock\n");
>> + ret = -ENODEV;
>> + goto fail;
>> + }
>
> "dpll_disp_ck" is a platform specific matter, driver should not
> be handling platform specifics. And this won't work on DaVinci,
> you can probably make use of
meaning the clock has a different name on davinci, or? Presumably
there must be some clock generating the pixel clock for the display,
but I confess to not being too familiar with the details on davinci..
BR,
-R
> my series "[PATCH v2 0/4] ARM: AM335x: LCDC platform support"
>
> or something similar to overcome this.
>
> Regards
> Afzal
>
>
^ permalink raw reply
* Re: [PATCH] fbcon: fix locking harder
From: Josh Boyer @ 2013-01-25 14:08 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <1359078224-3327-1-git-send-email-airlied@gmail.com>
On Thu, Jan 24, 2013 at 8:43 PM, Dave Airlie <airlied@gmail.com> wrote:
> Okay so Alan's patch handled the case where there was no registered fbcon,
> however the other path entered in set_con2fb_map pit.
>
> In there we called fbcon_takeover, but we also took the console lock in a couple
> of places. So push the console lock out to the callers of set_con2fb_map,
>
> this means fbmem and switcheroo needed to take the lock around the fb notifier
> entry points that lead to this.
>
> This should fix the efifb regression seen by Maarten.
>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
Linus might not be taking this for 3.8 because of lack of testing, but
that doesn't mean the problems don't exist in 3.8 (and older). Maybe
throw a CC for stable on the patch? That way it works its way back when
it does get merged.
josh
^ permalink raw reply
* RE: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Mohammed, Afzal @ 2013-01-25 14:15 UTC (permalink / raw)
To: Rob Clark
Cc: dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, patches@linaro.org,
linux-fbdev@vger.kernel.org, Mike Turquette, Nori, Sekhar
In-Reply-To: <CAF6AEGsqkUr0R3eYa4P371tUPq_NLSJLhH=N_MkyJF31s068+g@mail.gmail.com>
SGkgUm9iLA0KDQpPbiBGcmksIEphbiAyNSwgMjAxMyBhdCAxOToyOTo0MCwgUm9iIENsYXJrIHdy
b3RlOg0KPiBPbiBGcmksIEphbiAyNSwgMjAxMyBhdCA3OjE5IEFNLCBNb2hhbW1lZCwgQWZ6YWwg
PGFmemFsQHRpLmNvbT4gd3JvdGU6DQo+ID4gT24gV2VkLCBKYW4gMjMsIDIwMTMgYXQgMDQ6MDY6
MjIsIFJvYiBDbGFyayB3cm90ZToNCg0KPiA+PiBBIHNpbXBsZSBEUk0vS01TIGRyaXZlciBmb3Ig
dGhlIFRJIExDRCBDb250cm9sbGVyIGZvdW5kIGluIHZhcmlvdXMNCj4gPj4gc21hbGxlciBUSSBw
YXJ0cyAoQU0zM3h4LCBPTUFQTDEzOCwgZXRjKS4gIFRoaXMgZHJpdmVyIHVzZXMgdGhlDQoNCj4g
Pj4gK3ZvaWQgdGlsY2RjX2NydGNfdXBkYXRlX2NsayhzdHJ1Y3QgZHJtX2NydGMgKmNydGMpDQo+
ID4NCj4gPj4gKyAgICAgLyogaW4gcmFzdGVyIG1vZGUsIG1pbmltdW0gZGl2aXNvciBpcyAyOiAq
Lw0KPiA+PiArICAgICByZXQgPSBjbGtfc2V0X3JhdGUocHJpdi0+ZGlzcF9jbGssIGNydGMtPm1v
ZGUuY2xvY2sgKiAxMDAwICogMik7DQoNCj4gPiBUaGVzZSB0aGluZ3MgY2FuIGJldHRlciBiZSBo
YW5kbGVkIHdpdGggZGl2aWRlciBjbG9jayBoYXZpbmcgYQ0KPiA+IG1pbmltdW0gdmFsdWUgKGJl
aW5nIGRpc2N1c3NlZCB3aXRoIE1pa2Ugb24gaG93IGV4YWN0bHkgaXQgc2hvdWxkDQo+ID4gYmUp
IGFuZCBpbnN0ZWFkIG9mIHNldHRpbmcgcmF0ZSBvdmVyIGEgcGxhdGZvcm0gc3BlY2lmaWMgY2xv
Y2ssDQo+ID4geW91IGNhbiBzZXQgcmF0ZSBvdmVyIGxjZCBjbG9jayB1c2luZyBTRVRfUkFURV9Q
QVJFTlQgYXQgcGxhdGZvcm0NCj4gPiBsZXZlbCwgbW9yZSBiZWxvdywNCg0KPiBJIGxvb2tlZCBh
dCB0aGF0IHBhdGNoIHlvdSB3ZXJlIHByb3Bvc2luZyBmb3IgZGE4eHgtZmIuLiAgdG8gYmUNCj4g
aG9uZXN0LCBpdCBkaWQgbm90IHNlZW0gc2ltcGxlciB0byBtZSwgc28gSSB3YXMgc29ydCBvZiBm
YWlsaW5nIHRvIHNlZQ0KPiB0aGUgYmVuZWZpdC4uDQoNCkl0J3Mgbm90IGFib3V0IGJlaW5nIHNp
bXBsZSwgYnV0IG5vdCBkb2luZyB0aGUgd3Jvbmcgd2F5LCBoZXJlIHlvdSBhcmUNCnJlbHlpbmcg
b24gYSBwbGF0Zm9ybSBzcGVjaWZpYyBjbG9jayBpbiBhIGRyaXZlciwgdGhpbmsgYWJvdXQgdGhl
IGNhc2UNCndoZXJlIHNhbWUgSVAgaXMgdXNlZCBvbiBhbm90aGVyIHBsYXRmb3JtLiBFaXRoZXIg
d2F5IGl0IGlzIG5vdCBhIGdvb2QNCnRoaW5nIHRvIGhhbmRsZSBwbGF0Zm9ybSBzcGVjaWZpYyBk
ZXRhaWxzIChhYm91dCBkaXNwX2NsaykgaW4gZHJpdmVyLg0KDQpBbmQgTWlrZSBtZW50aW9uZWQg
dGhhdCBvbmUgb2YgZGVzaWduIGdvYWxzIG9mIENDRiBpcyB0byBtb2RlbCB0aGVzZQ0Ka2luZHMg
b2YgY2xvY2tzIGluIElQJ3MuDQoNCj4gPj4gKyAgICAgLyogQ29uZmlndXJlIHRoZSBMQ0QgY2xv
Y2sgZGl2aXNvci4gKi8NCj4gPj4gKyAgICAgdGlsY2RjX3dyaXRlKGRldiwgTENEQ19DVFJMX1JF
RywgTENEQ19DTEtfRElWSVNPUihkaXYpIHwNCj4gPj4gKyAgICAgICAgICAgICAgICAgICAgIExD
RENfUkFTVEVSX01PREUpOw0KPiA+PiArDQo+ID4+ICsgICAgIGlmIChwcml2LT5yZXYgPT0gMikN
Cj4gPj4gKyAgICAgICAgICAgICB0aWxjZGNfc2V0KGRldiwgTENEQ19DTEtfRU5BQkxFX1JFRywN
Cj4gPj4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTENEQ19WMl9ETUFfQ0xLX0VOIHwg
TENEQ19WMl9MSUREX0NMS19FTiB8DQo+ID4+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IExDRENfVjJfQ09SRV9DTEtfRU4pOw0KPiA+DQo+ID4gTWlrZSB3YXMgc3VnZ2VzdGluZyB0byBt
b2RlbCB0aGUgYWJvdmUgdXNpbmcgZ2F0ZS9kaXZpZGVyL2NvbXBvc2l0ZQ0KPiA+IGNsb2NrcyBv
ZiBDQ0YgaW4gdGhlIEZCIGRyaXZlci4NCg0KPiA+PiArICAgICBwcml2LT5jbGsgPSBjbGtfZ2V0
KGRldi0+ZGV2LCAiZmNrIik7DQo+ID4+ICsgICAgIGlmIChJU19FUlIocHJpdi0+Y2xrKSkgew0K
PiA+PiArICAgICAgICAgICAgIGRldl9lcnIoZGV2LT5kZXYsICJmYWlsZWQgdG8gZ2V0IGZ1bmN0
aW9uYWwgY2xvY2tcbiIpOw0KPiA+PiArICAgICAgICAgICAgIHJldCA9IC1FTk9ERVY7DQo+ID4+
ICsgICAgICAgICAgICAgZ290byBmYWlsOw0KPiA+PiArICAgICB9DQo+ID4+ICsNCj4gPj4gKyAg
ICAgcHJpdi0+ZGlzcF9jbGsgPSBjbGtfZ2V0KGRldi0+ZGV2LCAiZHBsbF9kaXNwX2NrIik7DQo+
ID4+ICsgICAgIGlmIChJU19FUlIocHJpdi0+Y2xrKSkgew0KPiA+PiArICAgICAgICAgICAgIGRl
dl9lcnIoZGV2LT5kZXYsICJmYWlsZWQgdG8gZ2V0IGRpc3BsYXkgY2xvY2tcbiIpOw0KPiA+PiAr
ICAgICAgICAgICAgIHJldCA9IC1FTk9ERVY7DQo+ID4+ICsgICAgICAgICAgICAgZ290byBmYWls
Ow0KPiA+PiArICAgICB9DQo+ID4NCj4gPiAiZHBsbF9kaXNwX2NrIiBpcyBhIHBsYXRmb3JtIHNw
ZWNpZmljIG1hdHRlciwgZHJpdmVyIHNob3VsZCBub3QNCj4gPiBiZSBoYW5kbGluZyBwbGF0Zm9y
bSBzcGVjaWZpY3MuIEFuZCB0aGlzIHdvbid0IHdvcmsgb24gRGFWaW5jaSwNCj4gPiB5b3UgY2Fu
IHByb2JhYmx5IG1ha2UgdXNlIG9mDQo+IA0KPiBtZWFuaW5nIHRoZSBjbG9jayBoYXMgYSBkaWZm
ZXJlbnQgbmFtZSBvbiBkYXZpbmNpLCBvcj8gIFByZXN1bWFibHkNCj4gdGhlcmUgbXVzdCBiZSBz
b21lIGNsb2NrIGdlbmVyYXRpbmcgdGhlIHBpeGVsIGNsb2NrIGZvciB0aGUgZGlzcGxheSwNCj4g
YnV0IEkgY29uZmVzcyB0byBub3QgYmVpbmcgdG9vIGZhbWlsaWFyIHdpdGggdGhlIGRldGFpbHMg
b24gZGF2aW5jaS4uDQoNClRoZSBvbmx5IG9wdGlvbiBmb3IgdGhlIGRyaXZlciBpbiBEYVZpbmNp
IGlzIHRvIGNvbmZpZ3VyZSBjbG9jayByYXRlDQp1c2luZyB0aGUgZGl2aWRlciBvZiBMQ0RDIElQ
LCBpdCBoYXMgImZjayIsIHdoaWNoIGdpdmVzIGEgcmF0ZQ0KZGVjaWRlZCBieSBpdHMgYW5jZXN0
b3JzLg0KDQpSZWdhcmRzDQpBZnphbA0K
^ permalink raw reply
* Re: [PATCH 1/4] drm/tilcdc: add TI LCD Controller DRM driver (v3)
From: Rob Clark @ 2013-01-25 14:52 UTC (permalink / raw)
To: Mohammed, Afzal
Cc: dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, patches@linaro.org,
linux-fbdev@vger.kernel.org, Mike Turquette, Nori, Sekhar
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA93A7D@DBDE01.ent.ti.com>
On Fri, Jan 25, 2013 at 8:15 AM, Mohammed, Afzal <afzal@ti.com> wrote:
> Hi Rob,
>
> On Fri, Jan 25, 2013 at 19:29:40, Rob Clark wrote:
>> On Fri, Jan 25, 2013 at 7:19 AM, Mohammed, Afzal <afzal@ti.com> wrote:
>> > On Wed, Jan 23, 2013 at 04:06:22, Rob Clark wrote:
>
>> >> A simple DRM/KMS driver for the TI LCD Controller found in various
>> >> smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
>
>> >> +void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
>> >
>> >> + /* in raster mode, minimum divisor is 2: */
>> >> + ret = clk_set_rate(priv->disp_clk, crtc->mode.clock * 1000 * 2);
>
>> > These things can better be handled with divider clock having a
>> > minimum value (being discussed with Mike on how exactly it should
>> > be) and instead of setting rate over a platform specific clock,
>> > you can set rate over lcd clock using SET_RATE_PARENT at platform
>> > level, more below,
>
>> I looked at that patch you were proposing for da8xx-fb.. to be
>> honest, it did not seem simpler to me, so I was sort of failing to see
>> the benefit..
>
> It's not about being simple, but not doing the wrong way, here you are
> relying on a platform specific clock in a driver, think about the case
> where same IP is used on another platform. Either way it is not a good
> thing to handle platform specific details (about disp_clk) in driver.
Right, but I was trying to understand what was the benefit that the
added complexity is. I didn't realize on davinci that you are limited
to just setting divider values (which is going to drastically limit
the timings you can generate, although maybe not an issue if all you
support is a fixed lcd panel).
> And Mike mentioned that one of design goals of CCF is to model these
> kinds of clocks in IP's.
>
>> >> + /* Configure the LCD clock divisor. */
>> >> + tilcdc_write(dev, LCDC_CTRL_REG, LCDC_CLK_DIVISOR(div) |
>> >> + LCDC_RASTER_MODE);
>> >> +
>> >> + if (priv->rev = 2)
>> >> + tilcdc_set(dev, LCDC_CLK_ENABLE_REG,
>> >> + LCDC_V2_DMA_CLK_EN | LCDC_V2_LIDD_CLK_EN |
>> >> + LCDC_V2_CORE_CLK_EN);
>> >
>> > Mike was suggesting to model the above using gate/divider/composite
>> > clocks of CCF in the FB driver.
>
>> >> + priv->clk = clk_get(dev->dev, "fck");
>> >> + if (IS_ERR(priv->clk)) {
>> >> + dev_err(dev->dev, "failed to get functional clock\n");
>> >> + ret = -ENODEV;
>> >> + goto fail;
>> >> + }
>> >> +
>> >> + priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck");
>> >> + if (IS_ERR(priv->clk)) {
>> >> + dev_err(dev->dev, "failed to get display clock\n");
>> >> + ret = -ENODEV;
>> >> + goto fail;
>> >> + }
>> >
>> > "dpll_disp_ck" is a platform specific matter, driver should not
>> > be handling platform specifics. And this won't work on DaVinci,
>> > you can probably make use of
>>
>> meaning the clock has a different name on davinci, or? Presumably
>> there must be some clock generating the pixel clock for the display,
>> but I confess to not being too familiar with the details on davinci..
>
> The only option for the driver in DaVinci is to configure clock rate
> using the divider of LCDC IP, it has "fck", which gives a rate
> decided by its ancestors.
Well, from looking at the other patch series it seems CCF doesn't
support minimum divider yet. And davinci doesn't support CCF yet. So
at the moment all this discussion is a bit moot. I'd propose leaving
the driver as it is for now, because that at least makes it useful on
am33xx. And when CCF and davinci have the needed support in place,
then send a patch to change the clock handling in tilcdc. I don't
actually have any davinci hw to test on, but I can easily test on
am33xx.
BR,
-R
> Regards
> Afzal
^ permalink raw reply
* [PATCH] goldfish: framebuffer
From: Alan Cox @ 2013-01-25 15:31 UTC (permalink / raw)
To: linux-fbdev
From: Arve Hjønnevåg <arve@google.com>
Framebuffer support for the Goldfish emulator. This takes the Google emulator
and applies the x86 cleanups as well as moving the blank methods to the usual
Linux place and dropping the Android early suspend logic (for now at least, that
can be looked at as Android and upstream converge). Dropped various oddities
like setting MTRRs on a virtual frame buffer emulation...
With the drivers so far you can now boot a Linux initrd and have fun.
Signed-off-by: Mike A. Chan <mikechan@google.com>
Signed-off-by: Arve Hjønnevåg <arve@android.com>
[cleaned up to handle x86]
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>
Signed-off-by: Xiaohui Xin <xiaohui.xin@intel.com>
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
[ported to 3.4]
Signed-off-by: Tom Keel <thomas.keel@intel.com>
[cleaned up for style and 3.7, moved blank methods]
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/video/Kconfig | 9 +
drivers/video/Makefile | 1
drivers/video/goldfishfb.c | 316 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 326 insertions(+)
create mode 100644 drivers/video/goldfishfb.c
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index e4e1765..59889fc 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -2183,6 +2183,15 @@ config FB_XILINX
framebuffer. ML300 carries a 640*480 LCD display on the board,
ML403 uses a standard DB15 VGA connector.
+config FB_GOLDFISH
+ tristate "Goldfish Framebuffer"
+ depends on FB
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ ---help---
+ Framebuffer driver for Goldfish Virtual Platform
+
config FB_COBALT
tristate "Cobalt server LCD frame buffer support"
depends on FB && (MIPS_COBALT || MIPS_SEAD3)
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 768a137..3363f67 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -98,6 +98,7 @@ obj-$(CONFIG_FB_ATMEL) += atmel_lcdfb.o
obj-$(CONFIG_FB_PVR2) += pvr2fb.o
obj-$(CONFIG_FB_VOODOO1) += sstfb.o
obj-$(CONFIG_FB_ARMCLCD) += amba-clcd.o
+obj-$(CONFIG_FB_GOLDFISH) += goldfishfb.o
obj-$(CONFIG_FB_68328) += 68328fb.o
obj-$(CONFIG_FB_GBE) += gbefb.o
obj-$(CONFIG_FB_CIRRUS) += cirrusfb.o
diff --git a/drivers/video/goldfishfb.c b/drivers/video/goldfishfb.c
new file mode 100644
index 0000000..f7f5c29
--- /dev/null
+++ b/drivers/video/goldfishfb.c
@@ -0,0 +1,316 @@
+/*
+ * Copyright (C) 2007 Google, Inc.
+ * Copyright (C) 2012 Intel, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/dma-mapping.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/mm.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/ioport.h>
+#include <linux/platform_device.h>
+
+enum {
+ FB_GET_WIDTH = 0x00,
+ FB_GET_HEIGHT = 0x04,
+ FB_INT_STATUS = 0x08,
+ FB_INT_ENABLE = 0x0c,
+ FB_SET_BASE = 0x10,
+ FB_SET_ROTATION = 0x14,
+ FB_SET_BLANK = 0x18,
+ FB_GET_PHYS_WIDTH = 0x1c,
+ FB_GET_PHYS_HEIGHT = 0x20,
+
+ FB_INT_VSYNC = 1U << 0,
+ FB_INT_BASE_UPDATE_DONE = 1U << 1
+};
+
+struct goldfish_fb {
+ void __iomem *reg_base;
+ int irq;
+ spinlock_t lock;
+ wait_queue_head_t wait;
+ int base_update_count;
+ int rotation;
+ struct fb_info fb;
+ u32 cmap[16];
+};
+
+static irqreturn_t goldfish_fb_interrupt(int irq, void *dev_id)
+{
+ unsigned long irq_flags;
+ struct goldfish_fb *fb = dev_id;
+ u32 status;
+
+ spin_lock_irqsave(&fb->lock, irq_flags);
+ status = readl(fb->reg_base + FB_INT_STATUS);
+ if (status & FB_INT_BASE_UPDATE_DONE) {
+ fb->base_update_count++;
+ wake_up(&fb->wait);
+ }
+ spin_unlock_irqrestore(&fb->lock, irq_flags);
+ return status ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static inline u32 convert_bitfield(int val, struct fb_bitfield *bf)
+{
+ unsigned int mask = (1 << bf->length) - 1;
+
+ return (val >> (16 - bf->length) & mask) << bf->offset;
+}
+
+static int
+goldfish_fb_setcolreg(unsigned int regno, unsigned int red, unsigned int green,
+ unsigned int blue, unsigned int transp, struct fb_info *info)
+{
+ struct goldfish_fb *fb = container_of(info, struct goldfish_fb, fb);
+
+ if (regno < 16) {
+ fb->cmap[regno] = convert_bitfield(transp, &fb->fb.var.transp) |
+ convert_bitfield(blue, &fb->fb.var.blue) |
+ convert_bitfield(green, &fb->fb.var.green) |
+ convert_bitfield(red, &fb->fb.var.red);
+ return 0;
+ } else {
+ return 1;
+ }
+}
+
+static int goldfish_fb_check_var(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ if ((var->rotate & 1) != (info->var.rotate & 1)) {
+ if ((var->xres != info->var.yres) ||
+ (var->yres != info->var.xres) ||
+ (var->xres_virtual != info->var.yres) ||
+ (var->yres_virtual > info->var.xres * 2) ||
+ (var->yres_virtual < info->var.xres)) {
+ return -EINVAL;
+ }
+ } else {
+ if ((var->xres != info->var.xres) ||
+ (var->yres != info->var.yres) ||
+ (var->xres_virtual != info->var.xres) ||
+ (var->yres_virtual > info->var.yres * 2) ||
+ (var->yres_virtual < info->var.yres)) {
+ return -EINVAL;
+ }
+ }
+ if ((var->xoffset != info->var.xoffset) ||
+ (var->bits_per_pixel != info->var.bits_per_pixel) ||
+ (var->grayscale != info->var.grayscale)) {
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int goldfish_fb_set_par(struct fb_info *info)
+{
+ struct goldfish_fb *fb = container_of(info, struct goldfish_fb, fb);
+ if (fb->rotation != fb->fb.var.rotate) {
+ info->fix.line_length = info->var.xres * 2;
+ fb->rotation = fb->fb.var.rotate;
+ writel(fb->rotation, fb->reg_base + FB_SET_ROTATION);
+ }
+ return 0;
+}
+
+
+static int goldfish_fb_pan_display(struct fb_var_screeninfo *var,
+ struct fb_info *info)
+{
+ unsigned long irq_flags;
+ int base_update_count;
+ struct goldfish_fb *fb = container_of(info, struct goldfish_fb, fb);
+
+ spin_lock_irqsave(&fb->lock, irq_flags);
+ base_update_count = fb->base_update_count;
+ writel(fb->fb.fix.smem_start + fb->fb.var.xres * 2 * var->yoffset,
+ fb->reg_base + FB_SET_BASE);
+ spin_unlock_irqrestore(&fb->lock, irq_flags);
+ wait_event_timeout(fb->wait,
+ fb->base_update_count != base_update_count, HZ / 15);
+ if (fb->base_update_count = base_update_count)
+ pr_err("goldfish_fb_pan_display: timeout wating for base update\n");
+ return 0;
+}
+
+static int goldfish_fb_blank(int blank, struct fb_info *info)
+{
+ struct goldfish_fb *fb = container_of(info, struct goldfish_fb, fb);
+ switch (blank) {
+ case FB_BLANK_NORMAL:
+ writel(1, fb->reg_base + FB_SET_BLANK);
+ break;
+ case FB_BLANK_UNBLANK:
+ writel(0, fb->reg_base + FB_SET_BLANK);
+ break;
+ }
+ return 0;
+}
+
+static struct fb_ops goldfish_fb_ops = {
+ .owner = THIS_MODULE,
+ .fb_check_var = goldfish_fb_check_var,
+ .fb_set_par = goldfish_fb_set_par,
+ .fb_setcolreg = goldfish_fb_setcolreg,
+ .fb_pan_display = goldfish_fb_pan_display,
+ .fb_blank = goldfish_fb_blank,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
+
+static int goldfish_fb_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct resource *r;
+ struct goldfish_fb *fb;
+ size_t framesize;
+ u32 width, height;
+ dma_addr_t fbpaddr;
+
+ fb = kzalloc(sizeof(*fb), GFP_KERNEL);
+ if (fb = NULL) {
+ ret = -ENOMEM;
+ goto err_fb_alloc_failed;
+ }
+ spin_lock_init(&fb->lock);
+ init_waitqueue_head(&fb->wait);
+ platform_set_drvdata(pdev, fb);
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (r = NULL) {
+ ret = -ENODEV;
+ goto err_no_io_base;
+ }
+ fb->reg_base = ioremap(r->start, PAGE_SIZE);
+ if (fb->reg_base = NULL) {
+ ret = -ENOMEM;
+ goto err_no_io_base;
+ }
+
+ fb->irq = platform_get_irq(pdev, 0);
+ if (fb->irq <= 0) {
+ ret = -ENODEV;
+ goto err_no_irq;
+ }
+
+ width = readl(fb->reg_base + FB_GET_WIDTH);
+ height = readl(fb->reg_base + FB_GET_HEIGHT);
+
+ fb->fb.fbops = &goldfish_fb_ops;
+ fb->fb.flags = FBINFO_FLAG_DEFAULT;
+ fb->fb.pseudo_palette = fb->cmap;
+ fb->fb.fix.type = FB_TYPE_PACKED_PIXELS;
+ fb->fb.fix.visual = FB_VISUAL_TRUECOLOR;
+ fb->fb.fix.line_length = width * 2;
+ fb->fb.fix.accel = FB_ACCEL_NONE;
+ fb->fb.fix.ypanstep = 1;
+
+ fb->fb.var.xres = width;
+ fb->fb.var.yres = height;
+ fb->fb.var.xres_virtual = width;
+ fb->fb.var.yres_virtual = height * 2;
+ fb->fb.var.bits_per_pixel = 16;
+ fb->fb.var.activate = FB_ACTIVATE_NOW;
+ fb->fb.var.height = readl(fb->reg_base + FB_GET_PHYS_HEIGHT);
+ fb->fb.var.width = readl(fb->reg_base + FB_GET_PHYS_WIDTH);
+ fb->fb.var.pixclock = 10000;
+
+ fb->fb.var.red.offset = 11;
+ fb->fb.var.red.length = 5;
+ fb->fb.var.green.offset = 5;
+ fb->fb.var.green.length = 6;
+ fb->fb.var.blue.offset = 0;
+ fb->fb.var.blue.length = 5;
+
+ framesize = width * height * 2 * 2;
+ fb->fb.screen_base = dma_alloc_coherent(&pdev->dev, framesize,
+ &fbpaddr, GFP_KERNEL);
+ pr_debug("allocating frame buffer %d * %d, got %p\n",
+ width, height, fb->fb.screen_base);
+ if (fb->fb.screen_base = 0) {
+ ret = -ENOMEM;
+ goto err_alloc_screen_base_failed;
+ }
+ fb->fb.fix.smem_start = fbpaddr;
+ fb->fb.fix.smem_len = framesize;
+
+ ret = fb_set_var(&fb->fb, &fb->fb.var);
+ if (ret)
+ goto err_fb_set_var_failed;
+
+ ret = request_irq(fb->irq, goldfish_fb_interrupt, IRQF_SHARED,
+ pdev->name, fb);
+ if (ret)
+ goto err_request_irq_failed;
+
+ writel(FB_INT_BASE_UPDATE_DONE, fb->reg_base + FB_INT_ENABLE);
+ goldfish_fb_pan_display(&fb->fb.var, &fb->fb); /* updates base */
+
+ ret = register_framebuffer(&fb->fb);
+ if (ret)
+ goto err_register_framebuffer_failed;
+ return 0;
+
+err_register_framebuffer_failed:
+ free_irq(fb->irq, fb);
+err_request_irq_failed:
+err_fb_set_var_failed:
+ dma_free_coherent(&pdev->dev, framesize,
+ fb->fb.screen_base, fb->fb.fix.smem_start);
+err_alloc_screen_base_failed:
+err_no_irq:
+ iounmap(fb->reg_base);
+err_no_io_base:
+ kfree(fb);
+err_fb_alloc_failed:
+ return ret;
+}
+
+static int goldfish_fb_remove(struct platform_device *pdev)
+{
+ size_t framesize;
+ struct goldfish_fb *fb = platform_get_drvdata(pdev);
+
+ framesize = fb->fb.var.xres_virtual * fb->fb.var.yres_virtual * 2;
+ unregister_framebuffer(&fb->fb);
+ free_irq(fb->irq, fb);
+
+ dma_free_coherent(&pdev->dev, framesize, fb->fb.screen_base,
+ fb->fb.fix.smem_start);
+ iounmap(fb->reg_base);
+ return 0;
+}
+
+
+static struct platform_driver goldfish_fb_driver = {
+ .probe = goldfish_fb_probe,
+ .remove = goldfish_fb_remove,
+ .driver = {
+ .name = "goldfish_fb"
+ }
+};
+
+module_platform_driver(goldfish_fb_driver);
+
+MODULE_LICENSE("GPL v2");
^ permalink raw reply related
* Re: [PATCH] fbcon: fix locking harder
From: Daniel Vetter @ 2013-01-25 15:55 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-fbdev, linux-kernel, dri-devel
In-Reply-To: <1359078224-3327-1-git-send-email-airlied@gmail.com>
On Fri, Jan 25, 2013 at 2:43 AM, Dave Airlie <airlied@gmail.com> wrote:
> Okay so Alan's patch handled the case where there was no registered fbcon,
> however the other path entered in set_con2fb_map pit.
>
> In there we called fbcon_takeover, but we also took the console lock in a couple
> of places. So push the console lock out to the callers of set_con2fb_map,
>
> this means fbmem and switcheroo needed to take the lock around the fb notifier
> entry points that lead to this.
>
> This should fix the efifb regression seen by Maarten.
>
> Signed-off-by: Dave Airlie <airlied@redhat.com>
> ---
> drivers/gpu/vga/vga_switcheroo.c | 3 +++
> drivers/video/console/fbcon.c | 11 ++++++++---
> drivers/video/fbmem.c | 2 ++
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
[cut]
> ret = vgasr_priv.handler->switchto(new_client->id);
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index 2aef9ca..2e2d959 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -842,6 +842,8 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
> *
> * Maps a virtual console @unit to a frame buffer device
> * @newidx.
> + *
> + * This should be called with the console lock held.
> */
> static int set_con2fb_map(int unit, int newidx, int user)
> {
What about throwing a WARN_CONSOLE_UNLOCKED(); in here to make sure
this new rule is obeyed?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 1/3] semaphore: introduce down_timeout_killable()
From: Alexander Holler @ 2013-01-25 18:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-fbdev, Florian Tobias Schandinat, Bernie Thompson,
Steve Glendinning, Alexander Holler
In-Reply-To: <50F2A310.5010006@ahsoftware.de>
The name says it all, it's like down_timeout() but returns on fatal signals
too.
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
include/linux/semaphore.h | 2 ++
kernel/semaphore.c | 37 +++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+)
diff --git a/include/linux/semaphore.h b/include/linux/semaphore.h
index dc368b8..b508d4d 100644
--- a/include/linux/semaphore.h
+++ b/include/linux/semaphore.h
@@ -41,6 +41,8 @@ extern int __must_check down_interruptible(struct semaphore *sem);
extern int __must_check down_killable(struct semaphore *sem);
extern int __must_check down_trylock(struct semaphore *sem);
extern int __must_check down_timeout(struct semaphore *sem, long jiffies);
+extern int __must_check down_timeout_killable(struct semaphore *sem,
+ long jiffies);
extern void up(struct semaphore *sem);
#endif /* __LINUX_SEMAPHORE_H */
diff --git a/kernel/semaphore.c b/kernel/semaphore.c
index 4567fc0..4a5e823 100644
--- a/kernel/semaphore.c
+++ b/kernel/semaphore.c
@@ -37,6 +37,8 @@ static noinline void __down(struct semaphore *sem);
static noinline int __down_interruptible(struct semaphore *sem);
static noinline int __down_killable(struct semaphore *sem);
static noinline int __down_timeout(struct semaphore *sem, long jiffies);
+static noinline int __down_timeout_killable(struct semaphore *sem,
+ long jiffies);
static noinline void __up(struct semaphore *sem);
/**
@@ -169,6 +171,35 @@ int down_timeout(struct semaphore *sem, long jiffies)
EXPORT_SYMBOL(down_timeout);
/**
+ * down_timeout_killable - acquire the semaphore within a specified time or
+ * until a fatal signal arrives.
+ * @sem: the semaphore to be acquired
+ * @jiffies: how long to wait before failing
+ *
+ * Attempts to acquire the semaphore. If no more tasks are allowed to
+ * acquire the semaphore, calling this function will put the task to sleep.
+ * If the semaphore is not released within the specified number of jiffies,
+ * this function returns -ETIME. If the sleep is interrupted by a fatal signal,
+ * this function will return -EINTR. If the semaphore is successfully acquired,
+ * this function returns 0.
+ */
+int down_timeout_killable(struct semaphore *sem, long jiffies)
+{
+ unsigned long flags;
+ int result = 0;
+
+ raw_spin_lock_irqsave(&sem->lock, flags);
+ if (likely(sem->count > 0))
+ sem->count--;
+ else
+ result = __down_timeout_killable(sem, jiffies);
+ raw_spin_unlock_irqrestore(&sem->lock, flags);
+
+ return result;
+}
+EXPORT_SYMBOL(down_timeout_killable);
+
+/**
* up - release the semaphore
* @sem: the semaphore to release
*
@@ -253,6 +284,12 @@ static noinline int __sched __down_timeout(struct semaphore *sem, long jiffies)
return __down_common(sem, TASK_UNINTERRUPTIBLE, jiffies);
}
+static noinline int __sched __down_timeout_killable(struct semaphore *sem,
+ long jiffies)
+{
+ return __down_common(sem, TASK_KILLABLE, jiffies);
+}
+
static noinline void __sched __up(struct semaphore *sem)
{
struct semaphore_waiter *waiter = list_first_entry(&sem->wait_list,
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect
From: Alexander Holler @ 2013-01-25 18:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-fbdev, Florian Tobias Schandinat, Bernie Thompson,
Steve Glendinning, Alexander Holler, stable
In-Reply-To: <1359139768-32294-1-git-send-email-holler@ahsoftware.de>
When a device was disconnected the driver may hang at waiting for urbs it never
will get. Fix this by using a timeout while waiting for the used semaphore.
There is still a memory leak if a timeout happens, but at least the driver
now continues his disconnect routine.
Cc: <stable@vger.kernel.org>
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
drivers/video/udlfb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c
index 86d449e..db6cc66 100644
--- a/drivers/video/udlfb.c
+++ b/drivers/video/udlfb.c
@@ -1832,8 +1832,9 @@ static void dlfb_free_urb_list(struct dlfb_data *dev)
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
- /* Getting interrupted means a leak, but ok at disconnect */
- ret = down_interruptible(&dev->urbs.limit_sem);
+ /* Timeout likely occurs at disconnect (resulting in a leak) */
+ ret = down_timeout_killable(&dev->urbs.limit_sem,
+ FREE_URB_TIMEOUT);
if (ret)
break;
--
1.7.11.7
^ permalink raw reply related
* [PATCH 3/3] fb: smscufx: fix hang at disconnect
From: Alexander Holler @ 2013-01-25 18:49 UTC (permalink / raw)
To: linux-kernel
Cc: linux-fbdev, Florian Tobias Schandinat, Bernie Thompson,
Steve Glendinning, Alexander Holler, stable
In-Reply-To: <1359139768-32294-1-git-send-email-holler@ahsoftware.de>
When a device was disconnected the driver may hang at waiting for urbs it never
will get. Fix this by using a timeout while waiting for the used semaphore.
There is still a memory leak if a timeout happens, but at least the driver
now continues his disconnect routine.
Cc: <stable@vger.kernel.org>
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
drivers/video/smscufx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/smscufx.c b/drivers/video/smscufx.c
index 97bd662..f26fa4f 100644
--- a/drivers/video/smscufx.c
+++ b/drivers/video/smscufx.c
@@ -1838,8 +1838,9 @@ static void ufx_free_urb_list(struct ufx_data *dev)
/* keep waiting and freeing, until we've got 'em all */
while (count--) {
- /* Getting interrupted means a leak, but ok at shutdown*/
- ret = down_interruptible(&dev->urbs.limit_sem);
+ /* Timeout likely occurs at disconnect (resulting in a leak) */
+ ret = down_timeout_killable(&dev->urbs.limit_sem,
+ FREE_URB_TIMEOUT);
if (ret)
break;
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] goldfish: framebuffer
From: Andrew Morton @ 2013-01-25 22:44 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20130125153100.7317.23971.stgit@bob.linux.org.uk>
On Fri, 25 Jan 2013 15:31:17 +0000
Alan Cox <alan@linux.intel.com> wrote:
> Framebuffer support for the Goldfish emulator. This takes the Google emulator
> and applies the x86 cleanups as well as moving the blank methods to the usual
> Linux place and dropping the Android early suspend logic (for now at least, that
> can be looked at as Android and upstream converge). Dropped various oddities
> like setting MTRRs on a virtual frame buffer emulation...
>
> With the drivers so far you can now boot a Linux initrd and have fun.
That looks nice and clean. I'll grab it; hopefully for Florian to take
off my hands when he returns.
> Signed-off-by: Mike A. Chan <mikechan@google.com>
> Signed-off-by: Arve Hj__nnev__g <arve@android.com>
> [cleaned up to handle x86]
> Signed-off-by: Sheng Yang <sheng@linux.intel.com>
> Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>
> Signed-off-by: Xiaohui Xin <xiaohui.xin@intel.com>
> Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
> Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
> [ported to 3.4]
> Signed-off-by: Tom Keel <thomas.keel@intel.com>
> [cleaned up for style and 3.7, moved blank methods]
> Signed-off-by: Alan Cox <alan@linux.intel.com>
hm, it's unclear whether the [] comments apply to the line above or to
the line below. I converted it to my usual form. I hope I got it right!
[arve@android.com: cleaned up to handle x86]
[bruce.j.beare@intel.com: ported to 3.4]
[thomas.keel@intel.com: cleaned up for style and 3.7, moved blank methods]
Signed-off-by: Mike A. Chan <mikechan@google.com>
Signed-off-by: Arve Hj_nnev_g <arve@android.com>
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>
Signed-off-by: Xiaohui Xin <xiaohui.xin@intel.com>
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Tom Keel <thomas.keel@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
^ permalink raw reply
* Re: RE: RE: [PATCH v4 12/12] video: da8xx-fb: CCF clock divider handling
From: Mike Turquette @ 2013-01-25 22:44 UTC (permalink / raw)
To: Mohammed, Afzal, linux-fbdev@vger.kernel.org,
linux-omap@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Florian Tobias Schandinat, Tomi Valkeinen, Grant Likely,
Rob Herring, Rob Landley, paul, rnayak, b-cousson
In-Reply-To: <C8443D0743D26F4388EA172BF4E2A7A93EA9383E@DBDE01.ent.ti.com>
Quoting Mohammed, Afzal (2013-01-25 04:05:44)
> Hi Mike,
>
> On Thu, Jan 24, 2013 at 22:30:44, Mike Turquette wrote:
> > Quoting Mohammed, Afzal (2013-01-24 03:36:02)
>
> > > So there are 3 - LIDD is actually not for present use case, CORE could
> > > be clubbed with the divider to have a composite clock. And CORE is
> > > in functional clock path and logically it's perfectly alright to have
> > > the composite clock.
>
> > Some of the clock names are a bit generic, so a question that I'm going
> > to repeat throughout my response: "is this clock only inside of your
> > video IP ?"
>
> Yes these three clocks are inside LCDC IP.
>
> > Regarding the CORE clock, is this only inside of your IP or are you
> > referring to the SoC CORE clock which is driven by a DPLL and clocks
> > DDR and many other peripherals (often MMC, UART, etc)?
>
> Sorry for the confusion, here CORE refers to clock inside LCDC IP. This
> CORE should not be confused with CORE PLL. Actually I used CORE so that
> it corresponds to the nomenclature in LCDC section of TRM.
>
> > Note that this is from my past experience with OMAP, and I'm making an
> > assumption that the clock scheme between OMAP and Da Vinci/AM335x parts
> > isn't very different.
>
> Additional detail: DaVinci doesn't have these 3 clocks controls available,
> so these three are required only on AM335x (which has IP version 2 )
>
> > Is there a public TRM I can look at? It would help me understand this
> > without having to ask you so many annoying questions ;)
>
> No problem, http://www.ti.com/product/am3359
>
>
> > > And now we are left with DMA, this is actually in the interface clock
> > > path which driver in unaware. An option would be to have DMA clock
> > > as child of CORE plus divider composite clock, even though logically
> > > DMA can't be considered in the same path.
>
> > Why is the driver unaware of the interface clk? For instance OMAP3 had
> > separate fclk and iclk for IPs and drivers would call clk_enable on
> > both. Or am I misunderstanding something?
>
> HWMOD handles enabling those upon pm_runtime calls, HWMOD makes an alias
> for main clock with "fck", but not for "ick", so currently "ick" is
> unavailable for the driver, continued below ..
>
> > In general I don't think the clock subtree should be modeled in a way
> > that is convenient for software, but instead model the actual hardware.
> > Trust me, if you don't model the actual hardware then you will be very
> > confused when you come back and revisit this code in 6 months and can't
> > remember why things are so weird looking.
>
> Ok, then it seems an omap clock entry for con-id "ick" should be created
> as follows (dpll_core_m4_ck supplies interface clock),
>
> CLK("4830e000.lcdc", "ick", &dpll_core_m4_ck, CK_AM33XX)
>
> And then in the driver, DMA gate clock should be made a child of this clock
> (obtained with con-id "ick").
>
> Let me know your opinion on this.
>
I think Paul W. or someone on the TI side should weigh in on your clkdev
entries. My main point is that the actual tree should be modeled and
clocks shouldn't be globbed together unnecessarily. As mentioned in the
other mail thread you might be better off making a divider for your LCDC
IP block and modeling each node individually.
Regards,
Mike
> Regards
> Afzal
^ permalink raw reply
* Re: [PATCH] goldfish: framebuffer
From: Andrew Morton @ 2013-01-26 0:12 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20130125153100.7317.23971.stgit@bob.linux.org.uk>
On Sat, 26 Jan 2013 00:27:45 +0000
Alan Cox <alan@linux.intel.com> wrote:
> > hm, it's unclear whether the [] comments apply to the line above or to
> > the line below. I converted it to my usual form. I hope I got it
> > right!
>
> Below so you got them all one out 8)
>
o dwat.
[sheng@linux.intel.com: cleaned up to handle x86]
[thomas.keel@intel.com: ported to 3.4]
[alan@linux.intel.com: cleaned up for style and 3.7, moved blank methods]
Signed-off-by: Mike A. Chan <mikechan@google.com>
Signed-off-by: Arve Hj_nnev_g <arve@android.com>
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com>
Signed-off-by: Xiaohui Xin <xiaohui.xin@intel.com>
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>
Signed-off-by: Tom Keel <thomas.keel@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
^ permalink raw reply
* Re: [PATCH] goldfish: framebuffer
From: Alan Cox @ 2013-01-26 0:27 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20130125153100.7317.23971.stgit@bob.linux.org.uk>
> hm, it's unclear whether the [] comments apply to the line above or to
> the line below. I converted it to my usual form. I hope I got it
> right!
Below so you got them all one out 8)
Alan
^ permalink raw reply
* Re: [PATCH 0/3] atmel_lcdfb: fix 16-bpp regression
From: Johan Hovold @ 2013-01-26 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-1-git-send-email-jhovold@gmail.com>
On Mon, Dec 10, 2012 at 01:28:47PM +0100, Johan Hovold wrote:
> These patches fix a regression in 16-bpp support for older SOCs which use
> IBGR:555 rather than BGR:565 pixel layout. Use SOC-type to determine if the
> controller uses the intensity-bit and restore the old layout in that case.
I understand the maintainer's been busy lately, but could someone pick
these regression fixes up so we can get them into v3.8-rc and the stable
trees?
Thanks,
Johan
^ permalink raw reply
* [PATCH]video:uvesafb: Fix dereference NULL pointer code path
From: Wang YanQing @ 2013-01-27 6:13 UTC (permalink / raw)
To: FlorianSchandinat; +Cc: spock, linux-fbdev, 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: [git pull] fbcon locking fixes.
From: Daniel Vetter @ 2013-01-27 22:53 UTC (permalink / raw)
To: Andrew Morton
Cc: Maarten Lankhorst, linux-fbdev, linux-kernel, DRI mailing list,
torvalds
In-Reply-To: <20130124165055.0bceb033.akpm@linux-foundation.org>
On Fri, Jan 25, 2013 at 1:50 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Fri, 25 Jan 2013 00:42:37 +0000 (GMT)
> Dave Airlie <airlied@linux.ie> wrote:
>
>> These patches have been sailing around long enough, waiting for a maintainer
>> to reappear, so I've decided enough is enough, lockdep is kinda useful to have.
>>
>> Thanks to Daniel for annoying me enough :-)
>
> Me too, but the patches broke Maarten's EFI driver setup:
> https://lkml.org/lkml/2013/1/15/203.
Oops, didn't know that there are open issues, otherwise I'd have
worked on fixes instead of annoying you guys. To make due I've crawled
through fbcon code a bit to hunt for ways we could solve this mess
better than just flinging duct-tape. All the patches extend the
console_lock'ed area quite a bit, and I don't really like big kernel
looks with creeping coverage. More so if they come with funny
semantics like console_lock attached.
Looking at the fb notifier there are three use-cases for it:
- Special blank/unblank handling, used by the backlight and lcd
drivers in the fbdev subsystem. Could easily be extracted to another
notifier chain, and seems to have no need for the console lock. Also,
for kms drivers I don't care about this one bit.
- suspend/resume handling for the same fbdev lcd drivers. Same applies
(besides that it probably should get converted to proper device model
suspend/resume stuff).
- Runtime dependency injection between fbdev (and vga_switcheroor) for
fbcon. This allows you to load fbcon.ko and fbdev drives in any order,
and end up with an fbcon on each fbdev. Or not load fbcon.ko at all,
and only use the underlying fbdev. On a quick look it also racy as
hell.
The last one is the tricky one. If we could just add a hard
(compile-time) dependency between fbdevs and fbcon, we could rip out
all the fb notifier madness which also involves the console_lock in
some way and should be able to straighten out the locking. Users could
still opt out of using the fbcon at runtime, but ofc this might break
a really obscure setup somewhere. Quick survey of distros shows though
that all use the sane option of built-in fbcon support.
My proposal is to change the fbcon tristate to a bool and see what
happens. If it works out for a few kernel releases, garbage-collect
the fb_notifier for fbcon and use direct function calls instead
(stubbed it out properly if fbcon is disabeld ofc). Or is that too
much bending of the "thou shalt not break stuff" rule?
Plan B would be to simply mash-up a console on top of kms drivers
directly (since that's what I care about). Which has the downside that
we'd still need to keep the drm fbdev emulation helper code around,
since quite a few people use that to run older userspace (and even
report some bugs, e.g. mplayer on the linux console played some tricks
we needed to catch). And so end up with two pieces of code who's main
job is to paint console output onto the screen.
Ideas?
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH] backlight: add an AS3711 PMIC backlight driver
From: Jingoo Han @ 2013-01-28 0:53 UTC (permalink / raw)
To: 'Guennadi Liakhovetski'
Cc: 'Andrew Morton', linux-kernel, linux-fbdev, linux-sh,
'Magnus Damm', 'Richard Purdie'
In-Reply-To: <Pine.LNX.4.64.1301250836280.17518@axis700.grange>
On Friday, January 25, 2013 4:49 PM, Guennadi Liakhovetski wrote
>
> Hi Jingoo Han
>
> On Fri, 25 Jan 2013, Jingoo Han wrote:
>
> > On Wednesday, January 09, 2013 2:55 AM, Guennadi Liakhovetski wrote
> > >
> > > This is an initial commit of a backlight driver, using step-up DCDC power
> > > supplies on AS3711 PMIC. Only one mode has actually been tested, several
> > > further modes have been implemented "dry," but disabled to avoid accidental
> > > hardware damage. Anyone wishing to use any of those modes will have to
> > > modify the driver.
> > >
> > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> >
> > CC'ed Andrew Morton.
> >
> > Hi Guennadi Liakhovetski,
> >
> > I have reviewed this patch with AS3711 datasheet.
> > I cannot find any problems. It looks good.
>
> Thanks for the review.
>
> > However, some hardcoded numbers need to be changed
> > to the bit definitions.
>
> Which specific hardcoded values do you mean? A while ago in a discussion
> on one of kernel mailing lists a conclusion has been made, that macros do
> not always improve code readability. E.g. in a statement like this
>
> + case AS3711_SU2_CURR_AUTO:
> + if (pdata->su2_auto_curr1)
> + ctl = 2;
> + if (pdata->su2_auto_curr2)
> + ctl |= 8;
> + if (pdata->su2_auto_curr3)
> + ctl |= 0x20;
>
> making it
>
> + case AS3711_SU2_CURR_AUTO:
> + if (pdata->su2_auto_curr1)
> + ctl = SU2_AUTO_CURR1;
>
> would hardly make it more readable. IMHO it is already pretty clear, that
> bit 1 enables the current-1 sink. As long as these fields are only used at
> one location in the driver (and they are), using a macro and defining it
> elsewhere only makes it harder to see actual values. Speaking of this, a
> comment like
I don't think so. Some people feel that it is not clear a bit.
Of course, I know what you mean.
Also, your comment is reasonable.
However, personally, I prefer the latter.
Because, I think that the meaning of bits is more important than
actual bits. In the latter case, we can notice the meaning of bits
more easily.
Best regards,
Jingoo Han
>
> /*
> * Select, which current sinks shall be used for automatic
> * feedback selection
> */
>
> would help much more than any macro names. But as it stands, I think the
> current version is also possible to understand :-) If desired, however,
> comments can be added in an incremental patch
>
> Thanks
> Guennadi
>
> > Acked-by: Jingoo Han <jg1.han@samsung.com>
> >
> >
> > Best regards,
> > Jingoo Han
> >
> > > ---
> > >
> > > Tested on sh73a0-based kzm9g board. As the commit message says, only one
> > > mode has been tested and is enabled. That mode copies the sample code from
> > > the manufacturer. Deviations from that code proved to be fatal for the
> > > hardware...
> > >
> > > drivers/video/backlight/Kconfig | 7 +
> > > drivers/video/backlight/Makefile | 1 +
> > > drivers/video/backlight/as3711_bl.c | 379 +++++++++++++++++++++++++++++++++++
> > > 3 files changed, 387 insertions(+), 0 deletions(-)
> > > create mode 100644 drivers/video/backlight/as3711_bl.c
> > >
> > > diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> > > index 765a945..6ef0ede 100644
> > > --- a/drivers/video/backlight/Kconfig
> > > +++ b/drivers/video/backlight/Kconfig
> > > @@ -390,6 +390,13 @@ config BACKLIGHT_TPS65217
> > > If you have a Texas Instruments TPS65217 say Y to enable the
> > > backlight driver.
> > >
> > > +config BACKLIGHT_AS3711
> > > + tristate "AS3711 Backlight"
> > > + depends on BACKLIGHT_CLASS_DEVICE && MFD_AS3711
> > > + help
> > > + If you have an Austrian Microsystems AS3711 say Y to enable the
> > > + backlight driver.
> > > +
> > > endif # BACKLIGHT_CLASS_DEVICE
> > >
> > > endif # BACKLIGHT_LCD_SUPPORT
> > > diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
> > > index e7ce729..d3e188f 100644
> > > --- a/drivers/video/backlight/Makefile
> > > +++ b/drivers/video/backlight/Makefile
> > > @@ -45,3 +45,4 @@ obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
> > > obj-$(CONFIG_BACKLIGHT_AAT2870) += aat2870_bl.o
> > > obj-$(CONFIG_BACKLIGHT_OT200) += ot200_bl.o
> > > obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
> > > +obj-$(CONFIG_BACKLIGHT_AS3711) += as3711_bl.o
> > > diff --git a/drivers/video/backlight/as3711_bl.c b/drivers/video/backlight/as3711_bl.c
> > > new file mode 100644
> > > index 0000000..c6bc65d
> > > --- /dev/null
> > > +++ b/drivers/video/backlight/as3711_bl.c
> > > @@ -0,0 +1,379 @@
> > > +/*
> > > + * AS3711 PMIC backlight driver, using DCDC Step Up Converters
> > > + *
> > > + * Copyright (C) 2012 Renesas Electronics Corporation
> > > + * Author: Guennadi Liakhovetski, <g.liakhovetski@gmx.de>
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the version 2 of the GNU General Public License as
> > > + * published by the Free Software Foundation
> > > + */
> > > +
> > > +#include <linux/backlight.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/device.h>
> > > +#include <linux/err.h>
> > > +#include <linux/fb.h>
> > > +#include <linux/kernel.h>
> > > +#include <linux/mfd/as3711.h>
> > > +#include <linux/module.h>
> > > +#include <linux/regmap.h>
> > > +#include <linux/slab.h>
> > > +
> > > +enum as3711_bl_type {
> > > + AS3711_BL_SU1,
> > > + AS3711_BL_SU2,
> > > +};
> > > +
> > > +struct as3711_bl_data {
> > > + bool powered;
> > > + const char *fb_name;
> > > + struct device *fb_dev;
> > > + enum as3711_bl_type type;
> > > + int brightness;
> > > + struct backlight_device *bl;
> > > +};
> > > +
> > > +struct as3711_bl_supply {
> > > + struct as3711_bl_data su1;
> > > + struct as3711_bl_data su2;
> > > + const struct as3711_bl_pdata *pdata;
> > > + struct as3711 *as3711;
> > > +};
> > > +
> > > +static struct as3711_bl_supply *to_supply(struct as3711_bl_data *su)
> > > +{
> > > + switch (su->type) {
> > > + case AS3711_BL_SU1:
> > > + return container_of(su, struct as3711_bl_supply, su1);
> > > + case AS3711_BL_SU2:
> > > + return container_of(su, struct as3711_bl_supply, su2);
> > > + }
> > > + return NULL;
> > > +}
> > > +
> > > +static int as3711_set_brightness_auto_i(struct as3711_bl_data *data,
> > > + unsigned int brightness)
> > > +{
> > > + struct as3711_bl_supply *supply = to_supply(data);
> > > + struct as3711 *as3711 = supply->as3711;
> > > + const struct as3711_bl_pdata *pdata = supply->pdata;
> > > + int ret = 0;
> > > +
> > > + /* Only all equal current values are supported */
> > > + if (pdata->su2_auto_curr1)
> > > + ret = regmap_write(as3711->regmap, AS3711_CURR1_VALUE,
> > > + brightness);
> > > + if (!ret && pdata->su2_auto_curr2)
> > > + ret = regmap_write(as3711->regmap, AS3711_CURR2_VALUE,
> > > + brightness);
> > > + if (!ret && pdata->su2_auto_curr3)
> > > + ret = regmap_write(as3711->regmap, AS3711_CURR3_VALUE,
> > > + brightness);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int as3711_set_brightness_v(struct as3711 *as3711,
> > > + unsigned int brightness,
> > > + unsigned int reg)
> > > +{
> > > + if (brightness > 31)
> > > + return -EINVAL;
> > > +
> > > + return regmap_update_bits(as3711->regmap, reg, 0xf0,
> > > + brightness << 4);
> > > +}
> > > +
> > > +static int as3711_bl_su2_reset(struct as3711_bl_supply *supply)
> > > +{
> > > + struct as3711 *as3711 = supply->as3711;
> > > + int ret = regmap_update_bits(as3711->regmap, AS3711_STEPUP_CONTROL_5,
> > > + 3, supply->pdata->su2_fbprot);
> > > + if (!ret)
> > > + ret = regmap_update_bits(as3711->regmap,
> > > + AS3711_STEPUP_CONTROL_2, 1, 0);
> > > + if (!ret)
> > > + ret = regmap_update_bits(as3711->regmap,
> > > + AS3711_STEPUP_CONTROL_2, 1, 1);
> > > + return ret;
> > > +}
> > > +
> > > +/*
> > > + * Someone with less fragile or less expensive hardware could try to simplify
> > > + * the brightness adjustment procedure.
> > > + */
> > > +static int as3711_bl_update_status(struct backlight_device *bl)
> > > +{
> > > + struct as3711_bl_data *data = bl_get_data(bl);
> > > + struct as3711_bl_supply *supply = to_supply(data);
> > > + struct as3711 *as3711 = supply->as3711;
> > > + int brightness = bl->props.brightness;
> > > + int ret = 0;
> > > +
> > > + dev_dbg(&bl->dev, "%s(): brightness %u, pwr %x, blank %x, state %x\n",
> > > + __func__, bl->props.brightness, bl->props.power,
> > > + bl->props.fb_blank, bl->props.state);
> > > +
> > > + if (bl->props.power != FB_BLANK_UNBLANK ||
> > > + bl->props.fb_blank != FB_BLANK_UNBLANK ||
> > > + bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> > > + brightness = 0;
> > > +
> > > + if (data->type = AS3711_BL_SU1) {
> > > + ret = as3711_set_brightness_v(as3711, brightness,
> > > + AS3711_STEPUP_CONTROL_1);
> > > + } else {
> > > + const struct as3711_bl_pdata *pdata = supply->pdata;
> > > +
> > > + switch (pdata->su2_feedback) {
> > > + case AS3711_SU2_VOLTAGE:
> > > + ret = as3711_set_brightness_v(as3711, brightness,
> > > + AS3711_STEPUP_CONTROL_2);
> > > + break;
> > > + case AS3711_SU2_CURR_AUTO:
> > > + ret = as3711_set_brightness_auto_i(data, brightness / 4);
> > > + if (ret < 0)
> > > + return ret;
> > > + if (brightness) {
> > > + ret = as3711_bl_su2_reset(supply);
> > > + if (ret < 0)
> > > + return ret;
> > > + udelay(500);
> > > + ret = as3711_set_brightness_auto_i(data, brightness);
> > > + } else {
> > > + ret = regmap_update_bits(as3711->regmap,
> > > + AS3711_STEPUP_CONTROL_2, 1, 0);
> > > + }
> > > + break;
> > > + /* Manual one current feedback pin below */
> > > + case AS3711_SU2_CURR1:
> > > + ret = regmap_write(as3711->regmap, AS3711_CURR1_VALUE,
> > > + brightness);
> > > + break;
> > > + case AS3711_SU2_CURR2:
> > > + ret = regmap_write(as3711->regmap, AS3711_CURR2_VALUE,
> > > + brightness);
> > > + break;
> > > + case AS3711_SU2_CURR3:
> > > + ret = regmap_write(as3711->regmap, AS3711_CURR3_VALUE,
> > > + brightness);
> > > + break;
> > > + default:
> > > + ret = -EINVAL;
> > > + }
> > > + }
> > > + if (!ret)
> > > + data->brightness = brightness;
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int as3711_bl_get_brightness(struct backlight_device *bl)
> > > +{
> > > + struct as3711_bl_data *data = bl_get_data(bl);
> > > +
> > > + return data->brightness;
> > > +}
> > > +
> > > +static const struct backlight_ops as3711_bl_ops = {
> > > + .update_status = as3711_bl_update_status,
> > > + .get_brightness = as3711_bl_get_brightness,
> > > +};
> > > +
> > > +static int as3711_bl_init_su2(struct as3711_bl_supply *supply)
> > > +{
> > > + struct as3711 *as3711 = supply->as3711;
> > > + const struct as3711_bl_pdata *pdata = supply->pdata;
> > > + u8 ctl = 0;
> > > + int ret;
> > > +
> > > + dev_dbg(as3711->dev, "%s(): use %u\n", __func__, pdata->su2_feedback);
> > > +
> > > + /* Turn SU2 off */
> > > + ret = regmap_write(as3711->regmap, AS3711_STEPUP_CONTROL_2, 0);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + switch (pdata->su2_feedback) {
> > > + case AS3711_SU2_VOLTAGE:
> > > + ret = regmap_update_bits(as3711->regmap, AS3711_STEPUP_CONTROL_4, 3, 0);
> > > + break;
> > > + case AS3711_SU2_CURR1:
> > > + ctl = 1;
> > > + ret = regmap_update_bits(as3711->regmap, AS3711_STEPUP_CONTROL_4, 3, 1);
> > > + break;
> > > + case AS3711_SU2_CURR2:
> > > + ctl = 4;
> > > + ret = regmap_update_bits(as3711->regmap, AS3711_STEPUP_CONTROL_4, 3, 2);
> > > + break;
> > > + case AS3711_SU2_CURR3:
> > > + ctl = 0x10;
> > > + ret = regmap_update_bits(as3711->regmap, AS3711_STEPUP_CONTROL_4, 3, 3);
> > > + break;
> > > + case AS3711_SU2_CURR_AUTO:
> > > + if (pdata->su2_auto_curr1)
> > > + ctl = 2;
> > > + if (pdata->su2_auto_curr2)
> > > + ctl |= 8;
> > > + if (pdata->su2_auto_curr3)
> > > + ctl |= 0x20;
> > > + ret = 0;
> > > + break;
> > > + default:
> > > + return -EINVAL;
> > > + }
> > > +
> > > + if (!ret)
> > > + ret = regmap_write(as3711->regmap, AS3711_CURR_CONTROL, ctl);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int as3711_bl_register(struct platform_device *pdev,
> > > + unsigned int max_brightness, struct as3711_bl_data *su)
> > > +{
> > > + struct backlight_properties props = {.type = BACKLIGHT_RAW,};
> > > + struct backlight_device *bl;
> > > +
> > > + /* max tuning I = 31uA for voltage- and 38250uA for current-feedback */
> > > + props.max_brightness = max_brightness;
> > > +
> > > + bl = backlight_device_register(su->type = AS3711_BL_SU1 ?
> > > + "as3711-su1" : "as3711-su2",
> > > + &pdev->dev, su,
> > > + &as3711_bl_ops, &props);
> > > + if (IS_ERR(bl)) {
> > > + dev_err(&pdev->dev, "failed to register backlight\n");
> > > + return PTR_ERR(bl);
> > > + }
> > > +
> > > + bl->props.brightness = props.max_brightness;
> > > +
> > > + backlight_update_status(bl);
> > > +
> > > + su->bl = bl;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int as3711_backlight_probe(struct platform_device *pdev)
> > > +{
> > > + struct as3711_bl_pdata *pdata = dev_get_platdata(&pdev->dev);
> > > + struct as3711 *as3711 = dev_get_drvdata(pdev->dev.parent);
> > > + struct as3711_bl_supply *supply;
> > > + struct as3711_bl_data *su;
> > > + unsigned int max_brightness;
> > > + int ret;
> > > +
> > > + if (!pdata || (!pdata->su1_fb && !pdata->su2_fb)) {
> > > + dev_err(&pdev->dev, "No platform data, exiting...\n");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + /*
> > > + * Due to possible hardware damage I chose to block all modes,
> > > + * unsupported on my hardware. Anyone, wishing to use any of those modes
> > > + * will have to first review the code, then activate and test it.
> > > + */
> > > + if (pdata->su1_fb ||
> > > + pdata->su2_fbprot != AS3711_SU2_GPIO4 ||
> > > + pdata->su2_feedback != AS3711_SU2_CURR_AUTO) {
> > > + dev_warn(&pdev->dev,
> > > + "Attention! An untested mode has been chosen!\n"
> > > + "Please, review the code, enable, test, and report success:-)\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + supply = devm_kzalloc(&pdev->dev, sizeof(*supply), GFP_KERNEL);
> > > + if (!supply)
> > > + return -ENOMEM;
> > > +
> > > + supply->as3711 = as3711;
> > > + supply->pdata = pdata;
> > > +
> > > + if (pdata->su1_fb) {
> > > + su = &supply->su1;
> > > + su->fb_name = pdata->su1_fb;
> > > + su->type = AS3711_BL_SU1;
> > > +
> > > + max_brightness = min(pdata->su1_max_uA, 31);
> > > + ret = as3711_bl_register(pdev, max_brightness, su);
> > > + if (ret < 0)
> > > + return ret;
> > > + }
> > > +
> > > + if (pdata->su2_fb) {
> > > + su = &supply->su2;
> > > + su->fb_name = pdata->su2_fb;
> > > + su->type = AS3711_BL_SU2;
> > > +
> > > + switch (pdata->su2_fbprot) {
> > > + case AS3711_SU2_GPIO2:
> > > + case AS3711_SU2_GPIO3:
> > > + case AS3711_SU2_GPIO4:
> > > + case AS3711_SU2_LX_SD4:
> > > + break;
> > > + default:
> > > + ret = -EINVAL;
> > > + goto esu2;
> > > + }
> > > +
> > > + switch (pdata->su2_feedback) {
> > > + case AS3711_SU2_VOLTAGE:
> > > + max_brightness = min(pdata->su2_max_uA, 31);
> > > + break;
> > > + case AS3711_SU2_CURR1:
> > > + case AS3711_SU2_CURR2:
> > > + case AS3711_SU2_CURR3:
> > > + case AS3711_SU2_CURR_AUTO:
> > > + max_brightness = min(pdata->su2_max_uA / 150, 255);
> > > + break;
> > > + default:
> > > + ret = -EINVAL;
> > > + goto esu2;
> > > + }
> > > +
> > > + ret = as3711_bl_init_su2(supply);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + ret = as3711_bl_register(pdev, max_brightness, su);
> > > + if (ret < 0)
> > > + goto esu2;
> > > + }
> > > +
> > > + platform_set_drvdata(pdev, supply);
> > > +
> > > + return 0;
> > > +
> > > +esu2:
> > > + backlight_device_unregister(supply->su1.bl);
> > > + return ret;
> > > +}
> > > +
> > > +static int as3711_backlight_remove(struct platform_device *pdev)
> > > +{
> > > + struct as3711_bl_supply *supply = platform_get_drvdata(pdev);
> > > +
> > > + backlight_device_unregister(supply->su1.bl);
> > > + backlight_device_unregister(supply->su2.bl);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static struct platform_driver as3711_backlight_driver = {
> > > + .driver = {
> > > + .name = "as3711-backlight",
> > > + .owner = THIS_MODULE,
> > > + },
> > > + .probe = as3711_backlight_probe,
> > > + .remove = as3711_backlight_remove,
> > > +};
> > > +
> > > +module_platform_driver(as3711_backlight_driver);
> > > +
> > > +MODULE_DESCRIPTION("Backlight Driver for AS3711 PMICs");
> > > +MODULE_AUTHOR("Guennadi Liakhovetski <g.liakhovetski@gmx.de");
> > > +MODULE_LICENSE("GPL");
> > > +MODULE_ALIAS("platform:as3711-backlight");
> > > --
> > > 1.7.2.5
> > >
> > > --
> > > 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
> >
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
^ permalink raw reply
* RE: RE: RE: [PATCH v4 12/12] video: da8xx-fb: CCF clock divider handling
From: Mohammed, Afzal @ 2013-01-28 9:17 UTC (permalink / raw)
To: Mike Turquette,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Florian Tobias Schandinat, Rob Herring, Valkeinen, Tomi
In-Reply-To: <20130125224453.10623.74434@quantum>
SGkgTWlrZSwNCg0KT24gU2F0LCBKYW4gMjYsIDIwMTMgYXQgMDQ6MTQ6NTMsIE1pa2UgVHVycXVl
dHRlIHdyb3RlOg0KDQo+IEkgdGhpbmsgUGF1bCBXLiBvciBzb21lb25lIG9uIHRoZSBUSSBzaWRl
IHNob3VsZCB3ZWlnaCBpbiBvbiB5b3VyIGNsa2Rldg0KPiBlbnRyaWVzLiAgTXkgbWFpbiBwb2lu
dCBpcyB0aGF0IHRoZSBhY3R1YWwgdHJlZSBzaG91bGQgYmUgbW9kZWxlZCBhbmQNCj4gY2xvY2tz
IHNob3VsZG4ndCBiZSBnbG9iYmVkIHRvZ2V0aGVyIHVubmVjZXNzYXJpbHkuICBBcyBtZW50aW9u
ZWQgaW4gdGhlDQo+IG90aGVyIG1haWwgdGhyZWFkIHlvdSBtaWdodCBiZSBiZXR0ZXIgb2ZmIG1h
a2luZyBhIGRpdmlkZXIgZm9yIHlvdXIgTENEQw0KPiBJUCBibG9jayBhbmQgbW9kZWxpbmcgZWFj
aCBub2RlIGluZGl2aWR1YWxseS4NCg0KSXQgc2VlbXMgY29tcGxleGl0eSBvZiBkcml2ZXIgd291
bGQgaW5jcmVhc2UgYnkgY3JlYXRpbmcgYSBuZXcgaW5oZXJpdGVkDQpkaXZpZGVyIGNsb2NrIGFu
ZCBoYXZpbmcgYSB0b3RhbCAzLTQgY2xvY2sgbm9kZXMuIFRoZSBhZHZhbnRhZ2UgZ29pbmcNCndp
dGggaXQgd291bGQgYmUgaGlnaGVyIGNvbmZpZ3VyYWJsZSByZXNvbHV0aW9uIGZvciBwaXhlbCBj
bG9jay4NCkN1cnJlbnQgdXNlIGNhc2VzIHdvcmsgd2l0aG91dCBoaWdoZXIgcGl4ZWwgY2xvY2sg
cmVzb2x1dGlvbi4NCg0KQW5kIGRybSBkcml2ZXIgcG9zdGVkIGZvciB0aGUgc2FtZSBJUCBpcyB3
aXRob3V0IENDRiBtb2RlbGluZy4NCg0KU28gSSB3aWxsIHByZXNlbnRseSBub3QgbW9kZWwgY2xv
Y2sgbm9kZXMgaW4gTENEQyBJUCwgbGF0ZXIgaWYgdXNlIGNhc2VzDQpiYWRseSByZXF1aXJlLCB0
aGlzIGNhbiBiZSBkb25lIChhbmQgaWYgaXQgaGFwcGVucywgaG9wZWZ1bGx5IGJ5IHRoYXQNCkRh
VmluY2kgd291bGQgYmUgQ0NGJ2VkIGFuZCBpdCB3b3VsZCBiZSBtb3JlIGNsZWFuIHRvIGltcGxl
bWVudCBpdCkuDQoNClRoYW5rcyBmb3Igc2hhcmluZyB5b3VyIGlkZWFzLg0KDQpSZWdhcmRzDQpB
ZnphbA0K
^ permalink raw reply
* [PATCH v5 00/12] video: da8xx-fb: am335x DT support
From: Afzal Mohammed @ 2013-01-28 9:32 UTC (permalink / raw)
To: linux-fbdev, linux-omap, devicetree-discuss, linux-doc,
linux-kernel
Cc: Florian Tobias Schandinat, Tomi Valkeinen, Grant Likely,
Rob Herring, Rob Landley, Mike Turquette
Hi,
This series adds DT support to da8xx-fb driver (device found on
DaVinci and AM335x SoC's). It does certain cleanup's in the process.
This series as compared to previous version goes back to v2 way of
configuring pixel clock rate. i.e. set divider if rate is within
the range that is configurable with existing input clock rate, else
change input clock rate as required instead of modeling CCF clock
nodes in the driver (more details in 12/12)
This makes use of Steffen Trumtrar's v17 of display timing DT support.
Testing has been done on AM335x SoC based boards like AM335x EVM. It
has also been verified that display on DA850 EVM (non-DT boot) works
as earlier.
This series is based on v3.8-rc3,
and is dependent on,
1. Series v17 "of: add display helper" by,
Steffen Trumtrar <s.trumtrar@pengutronix.de>
2. Patch "da8xx: Allow use by am33xx based devices" by,
Pantelis Antoniou <panto@antoniou-consulting.com>
3. Series v3 "video: da8xx-fb: runtime timing configuration" by,
me (Afzal Mohammed <afzal@ti.com>)
To test this series on AM335x based boards,
1. Series "HWMOD fixes for AM33xx PWM submodules and device tree nodes" by,
Philip, Avinash <avinashphilip@ti.com>
as well as following,
2. Series v2 "ARM: dts: AM33XX: lcdc support",
3. Patch v2 "ARM: OMAP2+: dpll: am335x - avoid freqsel",
4. Patch v2 "ARM: OMAP2+: clock: DEFINE_STRUCT_CLK_FLAGS helper",
5. Patch v2 "ARM: AM33XX: clock: SET_RATE_PARENT in lcd path" by,
me (Afzal Mohammed <afzal@ti.com>)
would be needed.
All above dependencies along with those required for testing is available
@ git://gitorious.org/x0148406-public/linux-kernel.git tags/da8xx-fb-dt-v5
Regards
Afzal
v5: use v2 method of configuring pixel clock rate instead of modeling
CCF clock nodes in driver, i.e. set divider if rate is within
the range that is configurable with existing input clock rate,
else change input clock rate as required.
v4: use new registration for clock divider having minimum divider
requirement and have ifdef'ery in a better way
v3: model CCF clock divider with parent propogation if CCF selected
v2: 2 new patches - one to configure clock rate properly (12/12)and
other to make io operations safe (1/12)
Afzal Mohammed (11):
video: da8xx-fb: make io operations safe
video: da8xx-fb: enable sync lost intr for v2 ip
video: da8xx-fb: use devres
video: da8xx-fb: ensure non-null cfg in pdata
video: da8xx-fb: reorganize panel detection
video: da8xx-fb: minimal dt support
video: da8xx-fb: invoke platform callback safely
video: da8xx-fb: obtain fb_videomode info from dt
video: da8xx-fb: ensure pdata only for non-dt
video: da8xx-fb: setup struct lcd_ctrl_config for dt
video: da8xx-fb: set upstream clock rate (if reqd)
Manjunathappa, Prakash (1):
video: da8xx-fb: fix 24bpp raster configuration
.../devicetree/bindings/video/fb-da8xx.txt | 37 ++++
drivers/video/da8xx-fb.c | 226 ++++++++++++++-------
2 files changed, 194 insertions(+), 69 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/fb-da8xx.txt
--
1.7.12
^ 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