* [PATCH 2/2] OMAPDSS: DISPC: Handle synclost errors in OMAP3
From: Chandrabhanu Mahapatra @ 2012-03-15 11:49 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In OMAP3 DISPC video overlays suffer from some undocumented horizontal position
and timing related limitations leading to SYNCLOST errors. Whenever the image
window is moved towards the right of the screen SYNCLOST errors become
frequent. Checks have been implemented to see that DISPC driver rejects
configuration exceeding above limitations.
This code was successfully tested on OMAP3. This code is written based on code
written by Ville Syrj채l채 <ville.syrjala@nokia.com> in Linux OMAP kernel. Ville
Syrj채l채 <ville.syrjala@nokia.com> had added checks for video overlay horizontal
timing and DISPC horizontal blanking length limitations.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dispc.c | 67 +++++++++++++++++++++++++++++++++++++--
1 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5a1963e..ebfa613 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1622,6 +1622,58 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
}
}
+static int check_horiz_timing(enum omap_channel channel, u16 pos_x,
+ u16 width, u16 height, u16 out_width, u16 out_height)
+{
+ int DS = DIV_ROUND_UP(height, out_height);
+ struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
+ struct omap_video_timings t = dssdev->panel.timings;
+ int pcd = REG_GET(DISPC_DIVISORo(channel), 7, 0);
+ unsigned long nonactive, val, blank;
+ static const u8 limits[3] = { 8, 10, 20 };
+ int i;
+
+ nonactive = t.x_res + t.hfp + t.hsw + t.hbp - out_width;
+
+ /*
+ * Atleast DS-2 lines must have already been fetched
+ * before the display active video period starts.
+ */
+ val = (nonactive - pos_x) * pcd;
+ DSSDBG("(nonactive - pos_x) * pcd = %lu,"
+ " max(0, DS - 2) * width = %d\n",
+ val, max(0, DS - 2) * width);
+ if (val < max(0, DS - 2) * width)
+ return -EINVAL;
+
+ /*
+ * Only one line can be fetched during the overlay active
+ * period, the rest have to be fetched during the inactive
+ * period.
+ */
+ val = nonactive * pcd;
+ DSSDBG("nonactive * pcd = %lu, max(0, DS - 1) * width = %d\n",
+ val, max(0, DS - 1) * width);
+ if (val < max(0, DS - 1) * width)
+ return -EINVAL;
+
+ /*
+ * Atleast Ceil(DS) lines should have been loaded during
+ * PPL (screen width) + blanking period.
+ */
+ i = 0;
+ if (out_height < height)
+ i++;
+ if (out_width < width)
+ i++;
+ blank = (t.hbp + t.hsw + t.hfp) * pcd;
+ DSSDBG("blanking period + ppl = %lu (limit = %u)\n", blank, limits[i]);
+ if (blank <= limits[i])
+ return -EINVAL;
+
+ return 0;
+}
+
static unsigned long calc_fclk_five_taps(enum omap_channel channel, u16 width,
u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode)
@@ -1702,7 +1754,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
enum omap_channel channel, u16 width, u16 height,
u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
- int *x_predecim, int *y_predecim)
+ int *x_predecim, int *y_predecim, u16 pos_x)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
@@ -1778,6 +1830,9 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
fclk = calc_fclk_five_taps(channel, in_width, in_height,
out_width, out_height, color_mode);
+ error = check_horiz_timing(channel, pos_x, in_width,
+ in_height, out_width, out_height);
+
if (in_width > maxsinglelinewidth)
if (in_height > out_height &&
in_height < out_height * 2)
@@ -1785,7 +1840,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
if (!*five_taps)
fclk = calc_fclk(channel, in_width, in_height,
out_width, out_height);
- error = (in_width > maxsinglelinewidth * 2 ||
+ error = (error || in_width > maxsinglelinewidth * 2 ||
(in_width > maxsinglelinewidth && *five_taps) ||
!fclk || fclk > dispc_fclk_rate());
if (error) {
@@ -1801,6 +1856,12 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
} while (decim_x <= *x_predecim && decim_y <= *y_predecim
&& error);
+ if (check_horiz_timing(channel, pos_x, width, height,
+ out_width, out_height)){
+ DSSERR("horizontal timing too tight\n");
+ return -EINVAL;
+ }
+
if (in_width > (maxsinglelinewidth * 2)) {
DSSERR("Cannot setup scaling");
DSSERR("width exceeds maximum width possible");
@@ -1901,7 +1962,7 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
r = dispc_ovl_calc_scaling(plane, channel, in_width, in_height,
out_width, out_height, oi->color_mode, &five_taps,
- &x_predecim, &y_predecim);
+ &x_predecim, &y_predecim, oi->pos_x);
if (r)
return r;
--
1.7.1
--
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 related
* [PATCH 1/2] OMAPDSS: DISPC: Enable predecimation
From: Chandrabhanu Mahapatra @ 2012-03-15 11:49 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times, and
up to 2 times in OMAP2. However, with predecimation, the image can be reduced
to 16 times by fetching only the necessary pixels in memory. Then this
predecimated image can be downscaled further by the DISPC scaler.
Based on the downscaling required, a prior calculation of predecimation values
for width and height of an image is done. Since, Predecimation reduces quality
of an image higher priorty is given to DISPC Scaler for downscaling.
This code was successfully tested on OMAP2, OMAP3 and OMAP4. Horizontal and
vertical predecimation worked fine except for some synclost errors due to
undocumented errata in OMAP3 which are fixed later and skewed images were seen
on OMAP2 and OMAP3 during horizontal predecimation which will be addressed in
the future patches.
This code is based on code written by Lajos Molnar <lajos@ti.com> who had added
predecimation support for NV12/YUV/rotated/SDMA buffers.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
---
drivers/video/omap2/dss/dispc.c | 262 +++++++++++++++++++++++++++------------
1 files changed, 181 insertions(+), 81 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e1626a1..5a1963e 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1389,7 +1389,7 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool mirror,
enum omap_color_mode color_mode, bool fieldmode,
unsigned int field_offset,
unsigned *offset0, unsigned *offset1,
- s32 *row_inc, s32 *pix_inc)
+ s32 *row_inc, s32 *pix_inc, int x_predecim, int y_predecim)
{
u8 ps;
@@ -1435,10 +1435,10 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool mirror,
else
*offset0 = 0;
- *row_inc = pixinc(1 + (screen_width - width) +
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 +
+ (y_predecim * screen_width - x_predecim * width) +
+ (fieldmode ? screen_width : 0), ps);
+ *pix_inc = pixinc(x_predecim, ps);
break;
case OMAP_DSS_ROT_0 + 4:
@@ -1456,10 +1456,10 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool mirror,
*offset0 = field_offset * screen_width * ps;
else
*offset0 = 0;
- *row_inc = pixinc(1 - (screen_width + width) -
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 -
+ (y_predecim * screen_width + x_predecim * width) -
+ (fieldmode ? screen_width : 0), ps);
+ *pix_inc = pixinc(x_predecim, ps);
break;
default:
@@ -1473,7 +1473,7 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
enum omap_color_mode color_mode, bool fieldmode,
unsigned int field_offset,
unsigned *offset0, unsigned *offset1,
- s32 *row_inc, s32 *pix_inc)
+ s32 *row_inc, s32 *pix_inc, int x_predecim, int y_predecim)
{
u8 ps;
u16 fbw, fbh;
@@ -1515,10 +1515,14 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 + field_offset * screen_width * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(1 + (screen_width - fbw) +
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 +
+ (y_predecim * screen_width - fbw * x_predecim) +
+ (fieldmode ? screen_width : 0), ps);
+ if (color_mode = OMAP_DSS_COLOR_YUV2 ||
+ color_mode = OMAP_DSS_COLOR_UYVY)
+ *pix_inc = pixinc(x_predecim, 2 * ps);
+ else
+ *pix_inc = pixinc(x_predecim, ps);
break;
case OMAP_DSS_ROT_90:
*offset1 = screen_width * (fbh - 1) * ps;
@@ -1526,9 +1530,9 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 + field_offset * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(screen_width * (fbh - 1) + 1 +
- (fieldmode ? 1 : 0), ps);
- *pix_inc = pixinc(-screen_width, ps);
+ *row_inc = pixinc(screen_width * (fbh * x_predecim - 1) +
+ y_predecim + (fieldmode ? 1 : 0), ps);
+ *pix_inc = pixinc(-x_predecim * screen_width, ps);
break;
case OMAP_DSS_ROT_180:
*offset1 = (screen_width * (fbh - 1) + fbw - 1) * ps;
@@ -1537,10 +1541,13 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
else
*offset0 = *offset1;
*row_inc = pixinc(-1 -
- (screen_width - fbw) -
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(-1, ps);
+ (y_predecim * screen_width - fbw * x_predecim) -
+ (fieldmode ? screen_width : 0), ps);
+ if (color_mode = OMAP_DSS_COLOR_YUV2 ||
+ color_mode = OMAP_DSS_COLOR_UYVY)
+ *pix_inc = pixinc(-x_predecim, 2 * ps);
+ else
+ *pix_inc = pixinc(-x_predecim, ps);
break;
case OMAP_DSS_ROT_270:
*offset1 = (fbw - 1) * ps;
@@ -1548,9 +1555,9 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 - field_offset * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(-screen_width * (fbh - 1) - 1 -
- (fieldmode ? 1 : 0), ps);
- *pix_inc = pixinc(screen_width, ps);
+ *row_inc = pixinc(-screen_width * (fbh * x_predecim - 1) -
+ y_predecim - (fieldmode ? 1 : 0), ps);
+ *pix_inc = pixinc(x_predecim * screen_width, ps);
break;
/* mirroring */
@@ -1560,10 +1567,14 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 + field_offset * screen_width * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(screen_width * 2 - 1 +
+ *row_inc = pixinc(y_predecim * screen_width * 2 - 1 +
(fieldmode ? screen_width : 0),
ps);
- *pix_inc = pixinc(-1, ps);
+ if (color_mode = OMAP_DSS_COLOR_YUV2 ||
+ color_mode = OMAP_DSS_COLOR_UYVY)
+ *pix_inc = pixinc(-x_predecim, 2 * ps);
+ else
+ *pix_inc = pixinc(-x_predecim, ps);
break;
case OMAP_DSS_ROT_90 + 4:
@@ -1572,10 +1583,10 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 + field_offset * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(-screen_width * (fbh - 1) + 1 +
- (fieldmode ? 1 : 0),
+ *row_inc = pixinc(-screen_width * (fbh * x_predecim - 1) +
+ y_predecim + (fieldmode ? 1 : 0),
ps);
- *pix_inc = pixinc(screen_width, ps);
+ *pix_inc = pixinc(x_predecim * screen_width, ps);
break;
case OMAP_DSS_ROT_180 + 4:
@@ -1584,10 +1595,14 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 - field_offset * screen_width * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(1 - screen_width * 2 -
+ *row_inc = pixinc(1 - y_predecim * screen_width * 2 -
(fieldmode ? screen_width : 0),
ps);
- *pix_inc = pixinc(1, ps);
+ if (color_mode = OMAP_DSS_COLOR_YUV2 ||
+ color_mode = OMAP_DSS_COLOR_UYVY)
+ *pix_inc = pixinc(x_predecim, 2 * ps);
+ else
+ *pix_inc = pixinc(x_predecim, ps);
break;
case OMAP_DSS_ROT_270 + 4:
@@ -1596,10 +1611,10 @@ static void calc_dma_rotation_offset(u8 rotation, bool mirror,
*offset0 = *offset1 - field_offset * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(screen_width * (fbh - 1) - 1 -
- (fieldmode ? 1 : 0),
+ *row_inc = pixinc(screen_width * (fbh * x_predecim - 1) -
+ y_predecim - (fieldmode ? 1 : 0),
ps);
- *pix_inc = pixinc(-screen_width, ps);
+ *pix_inc = pixinc(-x_predecim * screen_width, ps);
break;
default:
@@ -1686,13 +1701,17 @@ static unsigned long calc_fclk(enum omap_channel channel, u16 width,
static int dispc_ovl_calc_scaling(enum omap_plane plane,
enum omap_channel channel, u16 width, u16 height,
u16 out_width, u16 out_height,
- enum omap_color_mode color_mode, bool *five_taps)
+ enum omap_color_mode color_mode, bool *five_taps,
+ int *x_predecim, int *y_predecim)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
const int maxsinglelinewidth dss_feat_get_param_max(FEAT_PARAM_LINEWIDTH);
+ const int max_decim_limit = 16;
unsigned long fclk = 0;
+ int decim_x, decim_y, error, min_factor;
+ u16 in_width, in_height, in_width_max = 0;
if (width = out_width && height = out_height)
return 0;
@@ -1700,45 +1719,117 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) = 0)
return -EINVAL;
- if (out_width < width / maxdownscale ||
- out_width > width * 8)
+ *x_predecim = max_decim_limit;
+ *y_predecim = max_decim_limit;
+
+ if (color_mode = OMAP_DSS_COLOR_CLUT1 ||
+ color_mode = OMAP_DSS_COLOR_CLUT2 ||
+ color_mode = OMAP_DSS_COLOR_CLUT4 ||
+ color_mode = OMAP_DSS_COLOR_CLUT8) {
+ *x_predecim = 1;
+ *y_predecim = 1;
+ *five_taps = false;
+ return 0;
+ }
+
+ decim_x = DIV_ROUND_UP(DIV_ROUND_UP(width, out_width), maxdownscale);
+ decim_y = DIV_ROUND_UP(DIV_ROUND_UP(height, out_height), maxdownscale);
+
+ min_factor = min(decim_x, decim_y);
+
+ if (decim_x > *x_predecim || out_width > width * 8)
return -EINVAL;
- if (out_height < height / maxdownscale ||
- out_height > height * 8)
+ if (decim_y > *y_predecim || out_height > height * 8)
return -EINVAL;
if (cpu_is_omap24xx()) {
- if (width > maxsinglelinewidth)
- DSSERR("Cannot scale max input width exceeded");
*five_taps = false;
- fclk = calc_fclk(channel, width, height, out_width,
- out_height);
+
+ do {
+ in_height = DIV_ROUND_UP(height, decim_y);
+ in_width = DIV_ROUND_UP(width, decim_x);
+ fclk = calc_fclk(channel, in_width, in_height,
+ out_width, out_height);
+ error = (in_width > maxsinglelinewidth || !fclk ||
+ fclk > dispc_fclk_rate());
+ if (error) {
+ if (decim_x = decim_y) {
+ decim_x = min_factor;
+ decim_y++;
+ } else {
+ swap(decim_x, decim_y);
+ if (decim_x < decim_y)
+ decim_x++;
+ }
+ }
+ } while (decim_x <= *x_predecim && decim_y <= *y_predecim &&
+ error);
+
+ if (in_width > maxsinglelinewidth) {
+ DSSERR("Cannot scale max input width exceeded");
+ return -EINVAL;
+ }
} else if (cpu_is_omap34xx()) {
- if (width > (maxsinglelinewidth * 2)) {
+
+ do {
+ in_height = DIV_ROUND_UP(height, decim_y);
+ in_width = DIV_ROUND_UP(width, decim_x);
+ fclk = calc_fclk_five_taps(channel, in_width, in_height,
+ out_width, out_height, color_mode);
+
+ if (in_width > maxsinglelinewidth)
+ if (in_height > out_height &&
+ in_height < out_height * 2)
+ *five_taps = false;
+ if (!*five_taps)
+ fclk = calc_fclk(channel, in_width, in_height,
+ out_width, out_height);
+ error = (in_width > maxsinglelinewidth * 2 ||
+ (in_width > maxsinglelinewidth && *five_taps) ||
+ !fclk || fclk > dispc_fclk_rate());
+ if (error) {
+ if (decim_x = decim_y) {
+ decim_x = min_factor;
+ decim_y++;
+ } else {
+ swap(decim_x, decim_y);
+ if (decim_x < decim_y)
+ decim_x++;
+ }
+ }
+ } while (decim_x <= *x_predecim && decim_y <= *y_predecim
+ && error);
+
+ if (in_width > (maxsinglelinewidth * 2)) {
DSSERR("Cannot setup scaling");
DSSERR("width exceeds maximum width possible");
return -EINVAL;
}
- fclk = calc_fclk_five_taps(channel, width, height, out_width,
- out_height, color_mode);
- if (width > maxsinglelinewidth) {
- if (height > out_height && height < out_height * 2)
- *five_taps = false;
- else {
- DSSERR("cannot setup scaling with five taps");
- return -EINVAL;
- }
+
+ if (in_width > maxsinglelinewidth && *five_taps) {
+ DSSERR("cannot setup scaling with five taps");
+ return -EINVAL;
}
- if (!*five_taps)
- fclk = calc_fclk(channel, width, height, out_width,
- out_height);
} else {
- if (width > maxsinglelinewidth) {
+ in_height = DIV_ROUND_UP(height, decim_y);
+ in_width_max = dispc_fclk_rate() /
+ DIV_ROUND_UP(dispc_mgr_pclk_rate(channel),
+ out_width);
+ decim_x = DIV_ROUND_UP(width, in_width_max);
+ if (decim_x > *x_predecim)
+ return -EINVAL;
+ do {
+ in_width = DIV_ROUND_UP(width, decim_x);
+ } while (decim_x <= *x_predecim &&
+ in_width > maxsinglelinewidth && decim_x++);
+
+ if (in_width > maxsinglelinewidth) {
DSSERR("Cannot scale width exceeds max line width");
return -EINVAL;
}
- fclk = calc_fclk(channel, width, height, out_width,
+
+ fclk = calc_fclk(channel, in_width, in_height, out_width,
out_height);
}
@@ -1753,6 +1844,8 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
return -EINVAL;
}
+ *x_predecim = decim_x;
+ *y_predecim = decim_y;
return 0;
}
@@ -1768,8 +1861,11 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
s32 pix_inc;
u16 frame_height = oi->height;
unsigned int field_offset = 0;
- u16 outw, outh;
+ u16 in_height = oi->height;
+ u16 in_width = oi->width;
+ u16 out_width, out_height;
enum omap_channel channel;
+ int x_predecim = 1, y_predecim = 1;
channel = dispc_ovl_get_channel_out(plane);
@@ -1783,32 +1879,35 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
if (oi->paddr = 0)
return -EINVAL;
- outw = oi->out_width = 0 ? oi->width : oi->out_width;
- outh = oi->out_height = 0 ? oi->height : oi->out_height;
+ out_width = oi->out_width = 0 ? oi->width : oi->out_width;
+ out_height = oi->out_height = 0 ? oi->height : oi->out_height;
- if (ilace && oi->height = outh)
+ if (ilace && oi->height = out_height)
fieldmode = 1;
if (ilace) {
if (fieldmode)
- oi->height /= 2;
+ in_height /= 2;
oi->pos_y /= 2;
- outh /= 2;
+ out_height /= 2;
DSSDBG("adjusting for ilace: height %d, pos_y %d, "
"out_height %d\n",
- oi->height, oi->pos_y, outh);
+ in_height, oi->pos_y, out_height);
}
if (!dss_feat_color_mode_supported(plane, oi->color_mode))
return -EINVAL;
- r = dispc_ovl_calc_scaling(plane, channel, oi->width, oi->height,
- outw, outh, oi->color_mode,
- &five_taps);
+ r = dispc_ovl_calc_scaling(plane, channel, in_width, in_height,
+ out_width, out_height, oi->color_mode, &five_taps,
+ &x_predecim, &y_predecim);
if (r)
return r;
+ in_width = DIV_ROUND_UP(in_width, x_predecim);
+ in_height = DIV_ROUND_UP(in_height, y_predecim);
+
if (oi->color_mode = OMAP_DSS_COLOR_YUV2 ||
oi->color_mode = OMAP_DSS_COLOR_UYVY ||
oi->color_mode = OMAP_DSS_COLOR_NV12)
@@ -1822,10 +1921,10 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
* so the integer part must be added to the base address of the
* bottom field.
*/
- if (!oi->height || oi->height = outh)
+ if (!in_height || in_height = out_height)
field_offset = 0;
else
- field_offset = oi->height / outh / 2;
+ field_offset = in_height / out_height / 2;
}
/* Fields are independent but interleaved in memory. */
@@ -1834,14 +1933,16 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
if (oi->rotation_type = OMAP_DSS_ROT_DMA)
calc_dma_rotation_offset(oi->rotation, oi->mirror,
- oi->screen_width, oi->width, frame_height,
+ oi->screen_width, in_width, frame_height,
oi->color_mode, fieldmode, field_offset,
- &offset0, &offset1, &row_inc, &pix_inc);
+ &offset0, &offset1, &row_inc, &pix_inc,
+ x_predecim, y_predecim);
else
calc_vrfb_rotation_offset(oi->rotation, oi->mirror,
- oi->screen_width, oi->width, frame_height,
+ oi->screen_width, in_width, frame_height,
oi->color_mode, fieldmode, field_offset,
- &offset0, &offset1, &row_inc, &pix_inc);
+ &offset0, &offset1, &row_inc, &pix_inc,
+ x_predecim, y_predecim);
DSSDBG("offset0 %u, offset1 %u, row_inc %d, pix_inc %d\n",
offset0, offset1, row_inc, pix_inc);
@@ -1860,19 +1961,18 @@ int dispc_ovl_setup(enum omap_plane plane, struct omap_overlay_info *oi,
dispc_ovl_set_row_inc(plane, row_inc);
dispc_ovl_set_pix_inc(plane, pix_inc);
- DSSDBG("%d,%d %dx%d -> %dx%d\n", oi->pos_x, oi->pos_y, oi->width,
- oi->height, outw, outh);
+ DSSDBG("%d,%d %dx%d -> %dx%d\n", oi->pos_x, oi->pos_y, in_width,
+ in_height, out_width, out_height);
dispc_ovl_set_pos(plane, oi->pos_x, oi->pos_y);
- dispc_ovl_set_pic_size(plane, oi->width, oi->height);
+ dispc_ovl_set_pic_size(plane, in_width, in_height);
if (ovl->caps & OMAP_DSS_OVL_CAP_SCALE) {
- dispc_ovl_set_scaling(plane, oi->width, oi->height,
- outw, outh,
- ilace, five_taps, fieldmode,
+ dispc_ovl_set_scaling(plane, in_width, in_height, out_width,
+ out_height, ilace, five_taps, fieldmode,
oi->color_mode, oi->rotation);
- dispc_ovl_set_vid_size(plane, outw, outh);
+ dispc_ovl_set_vid_size(plane, out_width, out_height);
dispc_ovl_set_vid_color_conv(plane, cconv);
}
--
1.7.1
^ permalink raw reply related
* [PATCH 0/2] OMAPDSS: DISPC: Enable predecimation for DMA and VRFB
From: Chandrabhanu Mahapatra @ 2012-03-15 11:49 UTC (permalink / raw)
To: tomi.valkeinen; +Cc: linux-omap, linux-fbdev, Chandrabhanu Mahapatra
Hi everyone,
the following patch set directs to enable predecimation for DMA and VRFB
which consists of two pacthes.
The first patch is based on code written by Lajos Molnar <lajos@ti.com> in
Android Kernel, which updates the code with predecimation logic thereby
increasing the downscaling ability of the DISPC module.
The second patch is based on code written by Ville Syrjälä
<ville.syrjala@nokia.com> which aims to avoid synclost errors occurring
in OMAP3 due to some undocumented horizontal position and timing related
limitations which I faced during testing of the previous patch.
I have tested these patches successfully on OMAP2, OMAP3 AND OMAP4 on the
mainline kernel v3.3-rc5. Horizontal and vertical predecimation worked fine
but skewed images along with underflow errors were seen on OMAP2 and OMAP3
during horizontal predecimation which will be addressed in the future patches.
All your comments and suggestions are welcome.
Regards,
Chandrabhanu
Chandrabhanu Mahapatra (2):
OMAPDSS: DISPC: Enable predecimation
OMAPDSS: DISPC: Handle synclost errors in OMAP3
drivers/video/omap2/dss/dispc.c | 323 +++++++++++++++++++++++++++++----------
1 files changed, 242 insertions(+), 81 deletions(-)
^ permalink raw reply
* Re: [PATCH] [#7001] framebuffer: old image of last app would retain for a while after starting new app
From: Wu, Aaron @ 2012-03-15 9:23 UTC (permalink / raw)
To: Wu, Aaron,
linux-fbdev-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b@public.gmane.org
Cc: Zhang, Sonic
In-Reply-To: <1331628439-12719-1-git-send-email-Aaron.Wu-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
-----Original Message-----
From: Aaron Wu [mailto:Aaron.Wu-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org]
Sent: Tuesday, March 13, 2012 4:47 PM
To: linux-fbdev-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b@public.gmane.org; Wu, Aaron
Cc: Wu, Aaron
Subject: [PATCH] [#7001] framebuffer: old image of last app would retain for a while after starting new app
Old image of last application would retain for a while when starting a new application, this patch
clear the frambuffer before displaying every time the fb is opened.
Signed-off-by: Aaron Wu <Aaron.Wu-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>
---
drivers/video/bfin-lq035q1-fb.c | 1 +
drivers/video/bfin-t350mcqb-fb.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/bfin-lq035q1-fb.c b/drivers/video/bfin-lq035q1-fb.c
index c633068..676aa4e 100644
--- a/drivers/video/bfin-lq035q1-fb.c
+++ b/drivers/video/bfin-lq035q1-fb.c
@@ -399,6 +399,7 @@ static int bfin_lq035q1_fb_open(struct fb_info *info, int user)
bfin_lq035q1_config_dma(fbi);
bfin_lq035q1_config_ppi(fbi);
bfin_lq035q1_init_timers(fbi);
+ memset(fbi->fb_buffer, 0, info->fix.smem_len);
/* start dma */
enable_dma(CH_PPI);
diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c
index d5e1267..37f2df1 100644
--- a/drivers/video/bfin-t350mcqb-fb.c
+++ b/drivers/video/bfin-t350mcqb-fb.c
@@ -216,6 +216,7 @@ static int bfin_t350mcqb_fb_open(struct fb_info *info, int user)
bfin_t350mcqb_config_dma(fbi);
bfin_t350mcqb_config_ppi(fbi);
bfin_t350mcqb_init_timers();
+ memset(fbi->fb_buffer, 0, info->fix.smem_len);
/* start dma */
enable_dma(CH_PPI);
--
1.7.0.4
^ permalink raw reply related
* [PATCH] fbdev: bfin_adv7393fb: Drop needless include
From: Jean Delvare @ 2012-03-15 9:14 UTC (permalink / raw)
To: linux-fbdev
Kernel drivers don't need <linux/i2c-dev.h>.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
---
drivers/video/bfin_adv7393fb.c | 2 --
1 file changed, 2 deletions(-)
--- linux-3.3-rc7.orig/drivers/video/bfin_adv7393fb.c 2012-01-06 11:21:14.000000000 +0100
+++ linux-3.3-rc7/drivers/video/bfin_adv7393fb.c 2012-03-15 10:09:32.345820005 +0100
@@ -36,9 +36,7 @@
#include <linux/dma-mapping.h>
#include <linux/proc_fs.h>
#include <linux/platform_device.h>
-
#include <linux/i2c.h>
-#include <linux/i2c-dev.h>
#include "bfin_adv7393fb.h"
--
Jean Delvare
^ permalink raw reply
* RE: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Jingoo Han @ 2012-03-15 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEYLNCrprPE60ZS=_OWuck0JCJMhCxzVErZwuwGpEDYkQq-hXg@mail.gmail.com>
> -----Original Message-----
> From: Darius Augulis [mailto:augulis.darius@gmail.com]
> Sent: Thursday, March 15, 2012 5:27 PM
> To: Jingoo Han
> Cc: Thomas Abraham; linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-arm-
> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com; ben-
> linux@fluff.org; patches@linaro.org; Kyungmin Park; JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark
> Brown; Peter Korsgaard; Maurus Cuelenaere
> Subject: Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>
> On Thu, Mar 15, 2012 at 10:10 AM, Jingoo Han <jg1.han@samsung.com> wrote:
>
> >> There is single board - mini6410 (or real6410) and it's name doesn't
> >> depend on connected LCD size.
> >> We know, that this board is available with different sizes of LCD and
> >> currently we have in kernel support for both sizes.
> >> It might be so, that it's implemented not in perfect way, but it was
> >> accepted and at least it's working.
> >
> >
> > I don't think so.
> > You argues that the wrong code should not be removed because it was accepted and at least it's working.
> > It is just wrong usage, which can just work.
> > Moreover, your code will make the problem, when 2~5 windows of FIMD IP are used.
>
> Could please explain that? How does LCD feature selection for mini6410
> and real6410 break that?
> Timing for different sizes of LCD is located in two statically
> allocated structures which are used at board init time depending on
> kernel param line.
> Data from one of these structures is copied to s3c-fb platform data
> dynamically by board init code. Why it's a problem? What changes if
> platform data isn't rewritten dynamically?
>
> > So, your code can be removed.
>
> I don't think so. It does not break anything yet. One who make
> changes, should ensure backwards compatibility, at least talking about
> functionality and hardware (LCD) support, which was added few months
> ago. Remember, we talk about kernel parameters line - now it lets
> bootloader to select correct LCD size. After your changes, board with
> 7" LCD wont show anything.
OK, your code work, although the usage is wrong.
Thomas, can you keep backwards compatibility?
>
> Darius A.
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Darius Augulis @ 2012-03-15 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002a01cd0283$1f61b200$5e251600$%han@samsung.com>
On Thu, Mar 15, 2012 at 10:10 AM, Jingoo Han <jg1.han@samsung.com> wrote:
>> There is single board - mini6410 (or real6410) and it's name doesn't
>> depend on connected LCD size.
>> We know, that this board is available with different sizes of LCD and
>> currently we have in kernel support for both sizes.
>> It might be so, that it's implemented not in perfect way, but it was
>> accepted and at least it's working.
>
>
> I don't think so.
> You argues that the wrong code should not be removed because it was accepted and at least it's working.
> It is just wrong usage, which can just work.
> Moreover, your code will make the problem, when 2~5 windows of FIMD IP are used.
Could please explain that? How does LCD feature selection for mini6410
and real6410 break that?
Timing for different sizes of LCD is located in two statically
allocated structures which are used at board init time depending on
kernel param line.
Data from one of these structures is copied to s3c-fb platform data
dynamically by board init code. Why it's a problem? What changes if
platform data isn't rewritten dynamically?
> So, your code can be removed.
I don't think so. It does not break anything yet. One who make
changes, should ensure backwards compatibility, at least talking about
functionality and hardware (LCD) support, which was added few months
ago. Remember, we talk about kernel parameters line - now it lets
bootloader to select correct LCD size. After your changes, board with
7" LCD wont show anything.
Darius A.
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: provide default timings functions for panels
From: Tomi Valkeinen @ 2012-03-15 8:12 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <CANOLnOMAg-gdGPCuR1eR39GzNcK0rqFpfx6hiC2ULgPQ5v4qbA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]
On Wed, 2012-03-14 at 18:33 +0200, Grazvydas Ignotas wrote:
> On Wed, Mar 14, 2012 at 1:22 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > Hi,
> >
> > On Mon, 2012-03-12 at 13:27 +0200, Grazvydas Ignotas wrote:
> >> With this we can eliminate some duplicate code in panel drivers.
> >> Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
> >> tpo-td043mtea1 gain support of timings control over sysfs.
> >
> > I don't like this patch.
> >
> > Panels usually have a single, fixed timing configuration that should be
> > used, like the ones you mention above. There's no need to alter the
> > timings.
>
> But they often have a range of timings they can tolerate, and that can
> be used to alter refresh rate, for example. We do that on pandora to
> match graphics drawing rate (or multiples of it) to create a feeling
> smoothness.
True. And it's a valid operation anyway, so I guess there's no reason
why not to allow changing of the timings there.
> > But it's true that there's some duplicate code currently in the panel
> > drivers. However, adding just simple funcs like you did in this patch
> > doesn't work quite properly. There should be locking (for example to
> > prevent disabling the panel while timings are being set), and currently
> > the locking is panel driver specific.
Oh, and one more problem with the patch is that currently the panel
informs its inability to change timings by leaving set_timings and
check_timings as NULL, and this tells omapfb etc that the timings cannot
be changed, and the patch changes that behavior.
> ok, what about a version of this with .get_timings only then?
> This should not need a lock unless panel has a set function, but in
> that case panel will be expected to provide safe version of .get and
> .set itself.
I guess there's no harm in having default for get_timings(). It should
be present on all panel drivers anyway.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Jingoo Han @ 2012-03-15 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEYLNCp5e=86rpRi2C-5OJptTyEeXAn8JHhbWw_BqGzSaDD9wQ@mail.gmail.com>
> -----Original Message-----
> From: Darius Augulis [mailto:augulis.darius@gmail.com]
> Sent: Thursday, March 15, 2012 4:42 PM
> To: Jingoo Han
> Cc: Thomas Abraham; linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-arm-
> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com; ben-
> linux@fluff.org; patches@linaro.org; Kyungmin Park; JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark
> Brown; Peter Korsgaard; Maurus Cuelenaere
> Subject: Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>
> Hi,
>
> >
> > Yes, only single LCD resolution will be left.
> >
> >> I have mini6410 with both 4.3" and 7" LCDs and real6410 with 7" LCD. Now
> >> we have possibility to choose LCD size dynamically - leave it there.
> >> What you mean "default" 4.3" size LCD? The 7" size LCD is also provided
> >> by board sellers - I've bought it.
> >
> > OK, I see.
> > Both mini6410 and real6410 provide both 4.3" and 7" LCDs,
> > so you needs to select both LCDs.
> >
> > Um, usually, single LCD is provided on the single board.
> > Also, the daughter board with another kind LCD can be connected to the board.
>
> There is single board - mini6410 (or real6410) and it's name doesn't
> depend on connected LCD size.
> We know, that this board is available with different sizes of LCD and
> currently we have in kernel support for both sizes.
> It might be so, that it's implemented not in perfect way, but it was
> accepted and at least it's working.
I don't think so.
You argues that the wrong code should not be removed because it was accepted and at least it's working.
It is just wrong usage, which can just work.
Moreover, your code will make the problem, when 2~5 windows of FIMD IP are used.
So, your code can be removed.
> If you want to rework s3c-fb platform data and driver framework, you
> should not drop any functionality created by other people.
Augulis, Thomas Abraham wants to rework s3c-fb platform data and driver framework, not me. :)
I am just reviewing the Thomas's patchset.
>
> >
> > However, .win_mode is used not for LCD, but for windows of FIMD IP.
> > Actually, our current framework does not support to choose multi LCD,
> > so, I understand that you use .win_mode[1] as second LCD.
> > However, that's not accurate way to select multi LCD.
> >
> > Thomas, can you consider Augulis's opinion?
> > I think that the method to select multi LCDs is necessary.
> >
> > Ideal process is such as:
> > 1. add the patch to support to select multi LCDs
> > 2. apply above patch to make the mini6410 and real6410 to select multi LCDs.
> > 3. apply Thomas's patchset to remove timing value from .win_mode variable.
>
> Yes, this would be the right way to go.
However, skipping step 1 & 2 is also available, because your code is wrong.
As I'm mentioned above, your code will make the problem when 2~5 windows of FIMD IP are used.
>
> regards,
> Darius A.
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-15 8:05 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <CABNxG=D3y2GQqS1XN=+B0QRScXpufBkPQtP5-SSNEjSavhtW7g@mail.gmail.com>
Hi Pradeep,
於 三，2012-03-14 於 11:47 +0530，Pradeep Subrahmanion 提到：
> On Wed, Mar 14, 2012 at 11:21 AM, joeyli <jlee@suse.com> wrote:
> > 於 三，2012-03-14 於 08:13 +0530，Pradeep Subrahmanion 提到：
> >> Hi Joey ,
> >>
> >> > Per my understood, EC firmware should change brightness but didn't do
> >> > that, another
> >> > way is touch i915 register in _BCM.
> >>
> >> how do we do this ? you mean change the _BCM implementation ?
> >
> > "BIOS guy" should do something like this:
> >
> > Method (AINT, 2, NotSerialized)
> > {
> > ...
> > If (LEqual (Arg0, One))
> > {
> > Store (Divide (Multiply (Arg1, 0xFF), 0x64, ), BCLP)
> > Or (BCLP, 0x80000000, BCLP) <== touch BCLP register
> > Store (0x02, ASLC)
> > }
> >
> > Method (_BCM, 1, NotSerialized)
> > {
> > If (LAnd (LGreaterEqual (Arg0, Zero), LLessEqual (Arg0, 0x64)))
> > {
> > AINT (One, Arg0) <== call AINT method
> > Store (Arg0, BRTL)
> > }
> > }
> >
> >
> > Just for reference, they should do that when EC didn't wire to
> > backlight.
> >
> >> >
> >> > Acer machine provide a broken _BCM implementation and they didn't test
> >> > it.
> >> >
> >> > > > > By ' ACPI interface' , I mean 'acpi_video0' inside the
> >> > > > > /sys/class/backlight. I havn't tried the /sys/class/backlight interface
> >> > > > > directly . I will try that also.
> >> > > >
> >> > > > So writing values into /sys/class/backlight/acpi_video0/brightness does
> >> > > > nothing?
> >> > >
> >> > >
> >> > > No change in value when writing
> >> > > to /sys/class/backlight/acpi_video0/brightness.
> >> > >
> >> > > Another thing is that when i did boot with acpi_backlight = 'acer_wmi' ,
> >> > > in new kernel (3.3.0-rc7) , it shows following messages ,
> >> > >
> >> > > [ 8.350825] wmi: Mapper loaded
> >> > > [ 10.363975] acer_wmi: Acer Laptop ACPI-WMI Extras
> >> > > [ 10.396186] acer_wmi: Function bitmap for Communication Device: 0x91
> >> > > [ 10.396385] acer_wmi: Brightness must be controlled by generic video
> >> > > driver
> >> > >
> >> > > Also there was no interface inside /sys/class/backlight for acer_wmi.
> >> > >
> >> >
> >> > Yes, acer_wmi support backlight control with AMW0 interface, your
> >> > machine didn't have AMW0 interface.
> >> >
> >> > Normally, backlight should control by standard acpi interface.
> >> >
> >> > > I also tried writing directly to Embedded controller register .But no
> >> > > change.
> >> >
> >> > The machine has broken _BCM method, because EC should do something after
> >> > _BCM changed EC register.
> >>
> >> Thanks ,
> >>
> >> Pradeep Subrahmanion
> >
> > Why they didn't find _BCM not work?
> >
> > My guess is:
> >
> > Because the backlight control is through WDDM driver on Windows platform
> > but not through standard ACPI method _BCM. They only test Windows
> > platform, so, they didn't find _BCM broken.
> >
> > And, they also didn't really follow Microsoft WDDM spec:
> >
> > http://msdn.microsoft.com/en-us/windows/hardware/gg487382.aspx
> >
> > Per spec,
> > ODM should keep _BCM works fine for any other OS didn't support WDDM
> > driver, but they didn't.
> >
> > At last year, I told Acer PM one time for this issue, they said will
> > check but finally didn't response me.
> >
>
> >
> > Thanks
> > Joey Lee
> >
>
> So touching the PCI LBB register is the only feasible solution now
> (even though it may not be a clean method) ?
>
> Thanks,
> Pradeep Subrahmanion
That will be better leave LBB register only touched by i915 driver.
If 'acpi_backlight=vendor' works to you, maybe we can add a quirk to
video_detect.c.
You can try the following patch.
Thanks a lot!
Joey Lee
From 038bd3c4e53b7195f34e9d46c999b8dcb279da5e Mon Sep 17 00:00:00 2001
From: "Lee, Chun-Yi" <jlee@suse.com>
Date: Thu, 15 Mar 2012 16:03:45 +0800
Subject: [PATCH] acer-wmi: Add quirk table for video backlight vendor mode
Add quirk table for video backlight vendor mode
Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
---
drivers/acpi/video_detect.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index f3f0fe7..acb15d6 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -132,6 +132,32 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv)
return AE_OK;
}
+static int video_set_backlight_vendor(const struct dmi_system_id *d)
+{
+ acpi_video_support |= ACPI_VIDEO_BACKLIGHT_DMI_VENDOR;
+ return 0;
+}
+
+static const struct dmi_system_id video_vendor_dmi_table[] = {
+ {
+ .callback = video_set_backlight_vendor,
+ .ident = "Acer Aspire 4736",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 4736"),
+ },
+ },
+ {
+ .callback = video_set_backlight_vendor,
+ .ident = "Acer TravelMate 4750",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
+ },
+ },
+ {}
+};
+
/*
* Returns the video capabilities of a specific ACPI graphics device
*
@@ -164,6 +190,7 @@ long acpi_video_get_capabilities(acpi_handle graphics_handle)
* ACPI_VIDEO_BACKLIGHT_DMI_VENDOR;
*}
*/
+ dmi_check_system(video_vendor_dmi_table);
} else {
status = acpi_bus_get_device(graphics_handle, &tmp_dev);
if (ACPI_FAILURE(status)) {
--
1.7.7
^ permalink raw reply related
* Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Darius Augulis @ 2012-03-15 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001501cd0241$6bb53560$431fa020$%han@samsung.com>
Hi,
>
> Yes, only single LCD resolution will be left.
>
>> I have mini6410 with both 4.3" and 7" LCDs and real6410 with 7" LCD. Now
>> we have possibility to choose LCD size dynamically - leave it there.
>> What you mean "default" 4.3" size LCD? The 7" size LCD is also provided
>> by board sellers - I've bought it.
>
> OK, I see.
> Both mini6410 and real6410 provide both 4.3" and 7" LCDs,
> so you needs to select both LCDs.
>
> Um, usually, single LCD is provided on the single board.
> Also, the daughter board with another kind LCD can be connected to the board.
There is single board - mini6410 (or real6410) and it's name doesn't
depend on connected LCD size.
We know, that this board is available with different sizes of LCD and
currently we have in kernel support for both sizes.
It might be so, that it's implemented not in perfect way, but it was
accepted and at least it's working.
If you want to rework s3c-fb platform data and driver framework, you
should not drop any functionality created by other people.
>
> However, .win_mode is used not for LCD, but for windows of FIMD IP.
> Actually, our current framework does not support to choose multi LCD,
> so, I understand that you use .win_mode[1] as second LCD.
> However, that's not accurate way to select multi LCD.
>
> Thomas, can you consider Augulis's opinion?
> I think that the method to select multi LCDs is necessary.
>
> Ideal process is such as:
> 1. add the patch to support to select multi LCDs
> 2. apply above patch to make the mini6410 and real6410 to select multi LCDs.
> 3. apply Thomas's patchset to remove timing value from .win_mode variable.
Yes, this would be the right way to go.
regards,
Darius A.
^ permalink raw reply
* RE: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Jingoo Han @ 2012-03-15 0:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4F60E5C8.3040804@gmail.com>
> -----Original Message-----
> From: Darius Augulis [mailto:augulis.darius@gmail.com]
> Sent: Thursday, March 15, 2012 3:39 AM
> To: Jingoo Han
> Cc: 'Thomas Abraham'; linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-arm-
> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; kgene.kim@samsung.com; ben-
> linux@fluff.org; patches@linaro.org; 'Kyungmin Park'; 'JeongHyeon Kim'; 'Heiko Stuebner'; 'Kwangwoo Lee';
> 'Mark Brown'; 'Peter Korsgaard'; 'Maurus Cuelenaere'
> Subject: Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>
> On 03/14/2012 03:51 AM, Jingoo Han wrote:
> >> -----Original Message-----
> >> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> >> Sent: Tuesday, March 13, 2012 7:11 PM
> >> To: Jingoo Han
> >> Cc: linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org;
> linux-
> >> samsung-soc@vger.kernel.org; kgene.kim@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin
> >> Park; JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis;
> Maurus
> >> Cuelenaere
> >> Subject: Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
> >>
> >> On 13 March 2012 15:17, Jingoo Han<jg1.han@samsung.com> wrote:
> >>>> -----Original Message-----
> >>>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> >>>> Sent: Tuesday, March 13, 2012 6:00 AM
> >>>> To: linux-fbdev@vger.kernel.org
> >>>> Cc: FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-samsung-
> soc@vger.kernel.org;
> >>>> kgene.kim@samsung.com; jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin Park;
> >>>> JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
> >>>> Cuelenaere
> >>>> Subject: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
> >>>>
> >>>> For all the Samsung SoC based boards which have the platform data for
> >>>> s3c-fb driver, the 'default_win' element in the platform data is removed
> >>>> and the lcd panel video timing values are moved out of individual window
> >>>> configuration data.
> >>>>
> >>>> Cc: Jingoo Han<jg1.han@samsung.com>
> >>>> Cc: Kyungmin Park<kyungmin.park@samsung.com>
> >>>> Cc: JeongHyeon Kim<jhkim@insignal.co.kr>
> >>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
> >>>> Cc: Heiko Stuebner<heiko@sntech.de>
> >>>> Cc: Ben Dooks<ben-linux@fluff.org>
> >>>> Cc: Kwangwoo Lee<kwangwoo.lee@gmail.com>
> >>>> Cc: Mark Brown<broonie@opensource.wolfsonmicro.com>
> >>>> Cc: Peter Korsgaard<jacmet@sunsite.dk>
> >>>> Cc: Darius Augulis<augulis.darius@gmail.com>
> >>>> Cc: Maurus Cuelenaere<mcuelenaere@gmail.com>
> >>>> Signed-off-by: Thomas Abraham<thomas.abraham@linaro.org>
> >>>> ---
> >>>> arch/arm/mach-exynos/mach-nuri.c | 26 ++++++++++-------
> >>>> arch/arm/mach-exynos/mach-origen.c | 24 ++++++++++-------
> >>>> arch/arm/mach-exynos/mach-smdkv310.c | 28 +++++++++++--------
> >>>> arch/arm/mach-exynos/mach-universal_c210.c | 26 ++++++++++-------
> >>>> arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 ++++++++++--------
> >>>> arch/arm/mach-s3c64xx/mach-anw6410.c | 25 ++++++++++-------
> >>>> arch/arm/mach-s3c64xx/mach-crag6410.c | 25 ++++++++++-------
> >>>> arch/arm/mach-s3c64xx/mach-hmt.c | 24 ++++++++++-------
> >>>> arch/arm/mach-s3c64xx/mach-mini6410.c | 40 ++++++++++++---------------
> >>>> arch/arm/mach-s3c64xx/mach-real6410.c | 40 ++++++++++++---------------
> >>>> arch/arm/mach-s3c64xx/mach-smartq5.c | 26 ++++++++++-------
> >>>> arch/arm/mach-s3c64xx/mach-smartq7.c | 26 ++++++++++-------
> >>>> arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 ++++++++++-------
> >>>> arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 ++++++++++-------
> >>>> arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 ++++++++++-------
> >>>> arch/arm/mach-s5pc100/mach-smdkc100.c | 27 ++++++++++--------
> >>>> arch/arm/mach-s5pv210/mach-aquila.c | 36 +++++++++++--------------
> >>>> arch/arm/mach-s5pv210/mach-goni.c | 26 ++++++++++-------
> >>>> arch/arm/mach-s5pv210/mach-smdkv210.c | 24 ++++++++++-------
> >>>> 19 files changed, 285 insertions(+), 238 deletions(-)
> >>>>
> >>> [.....]
> >>>
> >>>> diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
> >>>> index c34c2ab..24dcdc9 100644
> >>>> --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
> >>>> +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
> >>>> @@ -153,36 +153,32 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
> >>>>
> >>>> static struct s3c_fb_pd_win mini6410_fb_win[] = {
> >>>> {
> >>>> - .win_mode = { /* 4.3" 480x272 */
> >>>> - .left_margin = 3,
> >>>> - .right_margin = 2,
> >>>> - .upper_margin = 1,
> >>>> - .lower_margin = 1,
> >>>> - .hsync_len = 40,
> >>>> - .vsync_len = 1,
> >>>> - .xres = 480,
> >>>> - .yres = 272,
> >>>> - },
> >>>> .max_bpp = 32,
> >>>> .default_bpp = 16,
> >>>> + .xres = 480,
> >>>> + .yres = 272,
> >>>> }, {
> >>>> - .win_mode = { /* 7.0" 800x480 */
> >>>> - .left_margin = 8,
> >>>> - .right_margin = 13,
> >>>> - .upper_margin = 7,
> >>>> - .lower_margin = 5,
> >>>> - .hsync_len = 3,
> >>>> - .vsync_len = 1,
> >>>> - .xres = 800,
> >>>> - .yres = 480,
> >>>> - },
> >>>> .max_bpp = 32,
> >>>> .default_bpp = 16,
> >>>> + .xres = 800,
> >>>> + .yres = 480,
> >>>> },
> >>>> };
> >>>>
> >>>> +static struct fb_videomode mini6410_lcd_timing = {
> >>>> + .left_margin = 8,
> >>>> + .right_margin = 13,
> >>>> + .upper_margin = 7,
> >>>> + .lower_margin = 5,
> >>>> + .hsync_len = 3,
> >>>> + .vsync_len = 1,
> >>>> + .xres = 800,
> >>>> + .yres = 480,
> >>>> +};
> >>>> +
> >>>> static struct s3c_fb_platdata mini6410_lcd_pdata __initdata = {
> >>>> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
> >>>> + .vtiming =&mini6410_lcd_timing,
> >>>> .win[0] =&mini6410_fb_win[0],
> >>>> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
> >>>> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> >>>> @@ -310,8 +306,8 @@ static void __init mini6410_machine_init(void)
> >>>> mini6410_lcd_pdata.win[0] =&mini6410_fb_win[features.lcd_index];
> >>>>
> >>>> printk(KERN_INFO "MINI6410: selected LCD display is %dx%d\n",
> >>>> - mini6410_lcd_pdata.win[0]->win_mode.xres,
> >>>> - mini6410_lcd_pdata.win[0]->win_mode.yres);
> >>>> + mini6410_lcd_pdata.win[0]->xres,
> >>>> + mini6410_lcd_pdata.win[0]->yres);
> >>>>
> >>>> s3c_nand_set_platdata(&mini6410_nand_info);
> >>>> s3c_fb_set_platdata(&mini6410_lcd_pdata);
> >>>> diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
> >>>> index be2a9a2..41e4f74 100644
> >>>> --- a/arch/arm/mach-s3c64xx/mach-real6410.c
> >>>> +++ b/arch/arm/mach-s3c64xx/mach-real6410.c
> >>>> @@ -119,36 +119,32 @@ static struct platform_device real6410_device_eth = {
> >>>>
> >>>> static struct s3c_fb_pd_win real6410_fb_win[] = {
> >>>> {
> >>>> - .win_mode = { /* 4.3" 480x272 */
> >>>> - .left_margin = 3,
> >>>> - .right_margin = 2,
> >>>> - .upper_margin = 1,
> >>>> - .lower_margin = 1,
> >>>> - .hsync_len = 40,
> >>>> - .vsync_len = 1,
> >>>> - .xres = 480,
> >>>> - .yres = 272,
> >>>> - },
> >>>> .max_bpp = 32,
> >>>> .default_bpp = 16,
> >>>> + .xres = 480,
> >>>> + .yres = 272,
> >>>> }, {
> >>>> - .win_mode = { /* 7.0" 800x480 */
> >>>> - .left_margin = 8,
> >>>> - .right_margin = 13,
> >>>> - .upper_margin = 7,
> >>>> - .lower_margin = 5,
> >>>> - .hsync_len = 3,
> >>>> - .vsync_len = 1,
> >>>> - .xres = 800,
> >>>> - .yres = 480,
> >>>> - },
> >>>> .max_bpp = 32,
> >>>> .default_bpp = 16,
> >>>> + .xres = 800,
> >>>> + .yres = 480,
> >>>> },
> >>>> };
> >>>>
> >>>> +static struct fb_videomode real6410_lcd_timing = {
> >>>> + .left_margin = 3,
> >>>> + .right_margin = 2,
> >>>> + .upper_margin = 1,
> >>>> + .lower_margin = 1,
> >>>> + .hsync_len = 40,
> >>>> + .vsync_len = 1,
> >>>> + .xres = 800,
> >>>> + .yres = 480,
> >>>> +};
> >>>
> >>> What is the difference between mini6410_lcd_timing and real6410_lcd_timing?
> >>> In my opinion, it would be good as follows:
> >>>
> >>> +static struct fb_videomode real6410_lcd_timing = {
> >>> + .left_margin = 8,
> >>> + .right_margin = 13,
> >>> + .upper_margin = 7,
> >>> + .lower_margin = 5,
> >>> + .hsync_len = 3,
> >>> + .vsync_len = 1,
> >>> + .xres = 800,
> >>> + .yres = 480,
> >>> +};
> >>>
> >>>
> >> Before this patch series, both real6410 and mini6410 had 'default_win'
> >> = 0 in the platform data. And, the s3c-fb driver selected the video
> >> timing from the window selected by the default_win parameter in s3c-fb
> >> platform data, i.e window 0 for both mini6440 and real6410. So, in
> >> this patch, while moving the timing values out of window data, the
> >> timing values for window 0 was selected.
> >>
> >> The timing value for window 1 was never used on mini6410 and real6410.
> >> So I would suggest to use timing value of window 0 in this patch.
> > OK, I see.
> > Then, as you mentioned above, the timing value of mini6410 and real6410 should be same.
> > Also, the mini6410 should use the timing value for window 0 as below.
> >
> > Also, this timing value is used for 4.3" 480x272 LCD.
> > So, xres and yres would be 480 and 272, respectively, instead of 800 and 480.
> >
> > The mini6410 seems to use 4.3" 480x272 LCD as default LCD.
> > Please refer to 'http://www.friendlyarm.net/products/mini6410'.
> >
> > Also, real6410 seems to use 4.3" 480x272 LCD as default LCD.
> > http://s3c6410kits.googlecode.com/files/overview_Real6410.pdf
> >
> > Therefore, given this, the timing value of mini6410 and real6410 would be as follows.
> >
> > +static struct fb_videomode mini6410_lcd_timing = {
> > + .left_margin = 8,
> > + .right_margin = 13,
> > + .upper_margin = 7,
> > + .lower_margin = 5,
> > + .hsync_len = 3,
> > + .vsync_len = 1,
> > + .xres = 480,
> > + .yres = 272,
> > +};
> >
> > +static struct fb_videomode real6410_lcd_timing = {
> > + .left_margin = 8,
> > + .right_margin = 13,
> > + .upper_margin = 7,
> > + .lower_margin = 5,
> > + .hsync_len = 3,
> > + .vsync_len = 1,
> > + .xres = 480,
> > + .yres = 272,
> > +};
> >
> > Darius Augulis, can you confirm it?
> > (Darius Augulis is a maintainer for real6410 and mini6410 boards.)
>
> Are you going to leave only single LCD resolution for every of two
> boards? If so, then my answer is no.
Yes, only single LCD resolution will be left.
> I have mini6410 with both 4.3" and 7" LCDs and real6410 with 7" LCD. Now
> we have possibility to choose LCD size dynamically - leave it there.
> What you mean "default" 4.3" size LCD? The 7" size LCD is also provided
> by board sellers - I've bought it.
OK, I see.
Both mini6410 and real6410 provide both 4.3" and 7" LCDs,
so you needs to select both LCDs.
Um, usually, single LCD is provided on the single board.
Also, the daughter board with another kind LCD can be connected to the board.
However, .win_mode is used not for LCD, but for windows of FIMD IP.
Actually, our current framework does not support to choose multi LCD,
so, I understand that you use .win_mode[1] as second LCD.
However, that's not accurate way to select multi LCD.
Thomas, can you consider Augulis's opinion?
I think that the method to select multi LCDs is necessary.
Ideal process is such as:
1. add the patch to support to select multi LCDs
2. apply above patch to make the mini6410 and real6410 to select multi LCDs.
3. apply Thomas's patchset to remove timing value from .win_mode variable.
Best regards,
Jingoo Han
>
> regards,
> Darius Augulis
>
> >
> > Best regards,
> > Jingoo Han
> >
> >> Thanks for your comments.
> >>
> >> Regards,
> >> Thomas.
> >
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Darius Augulis @ 2012-03-14 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwSUf-gsVesduMggSuues9OLOR6DUDAAMg_tL=e3=3c0tQ@mail.gmail.com>
On 03/13/2012 12:10 PM, Thomas Abraham wrote:
> On 13 March 2012 15:17, Jingoo Han<jg1.han@samsung.com> wrote:
>>> -----Original Message-----
>>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>>> Sent: Tuesday, March 13, 2012 6:00 AM
>>> To: linux-fbdev@vger.kernel.org
>>> Cc: FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
>>> kgene.kim@samsung.com; jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin Park;
>>> JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
>>> Cuelenaere
>>> Subject: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>>>
>>> For all the Samsung SoC based boards which have the platform data for
>>> s3c-fb driver, the 'default_win' element in the platform data is removed
>>> and the lcd panel video timing values are moved out of individual window
>>> configuration data.
>>>
>>> Cc: Jingoo Han<jg1.han@samsung.com>
>>> Cc: Kyungmin Park<kyungmin.park@samsung.com>
>>> Cc: JeongHyeon Kim<jhkim@insignal.co.kr>
>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>> Cc: Heiko Stuebner<heiko@sntech.de>
>>> Cc: Ben Dooks<ben-linux@fluff.org>
>>> Cc: Kwangwoo Lee<kwangwoo.lee@gmail.com>
>>> Cc: Mark Brown<broonie@opensource.wolfsonmicro.com>
>>> Cc: Peter Korsgaard<jacmet@sunsite.dk>
>>> Cc: Darius Augulis<augulis.darius@gmail.com>
>>> Cc: Maurus Cuelenaere<mcuelenaere@gmail.com>
>>> Signed-off-by: Thomas Abraham<thomas.abraham@linaro.org>
>>> ---
>>> arch/arm/mach-exynos/mach-nuri.c | 26 ++++++++++-------
>>> arch/arm/mach-exynos/mach-origen.c | 24 ++++++++++-------
>>> arch/arm/mach-exynos/mach-smdkv310.c | 28 +++++++++++--------
>>> arch/arm/mach-exynos/mach-universal_c210.c | 26 ++++++++++-------
>>> arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 ++++++++++--------
>>> arch/arm/mach-s3c64xx/mach-anw6410.c | 25 ++++++++++-------
>>> arch/arm/mach-s3c64xx/mach-crag6410.c | 25 ++++++++++-------
>>> arch/arm/mach-s3c64xx/mach-hmt.c | 24 ++++++++++-------
>>> arch/arm/mach-s3c64xx/mach-mini6410.c | 40 ++++++++++++---------------
>>> arch/arm/mach-s3c64xx/mach-real6410.c | 40 ++++++++++++---------------
>>> arch/arm/mach-s3c64xx/mach-smartq5.c | 26 ++++++++++-------
>>> arch/arm/mach-s3c64xx/mach-smartq7.c | 26 ++++++++++-------
>>> arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 ++++++++++-------
>>> arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 ++++++++++-------
>>> arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 ++++++++++-------
>>> arch/arm/mach-s5pc100/mach-smdkc100.c | 27 ++++++++++--------
>>> arch/arm/mach-s5pv210/mach-aquila.c | 36 +++++++++++--------------
>>> arch/arm/mach-s5pv210/mach-goni.c | 26 ++++++++++-------
>>> arch/arm/mach-s5pv210/mach-smdkv210.c | 24 ++++++++++-------
>>> 19 files changed, 285 insertions(+), 238 deletions(-)
>>>
>> [.....]
>>
>>> diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
>>> index c34c2ab..24dcdc9 100644
>>> --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
>>> +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
>>> @@ -153,36 +153,32 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
>>>
>>> static struct s3c_fb_pd_win mini6410_fb_win[] = {
>>> {
>>> - .win_mode = { /* 4.3" 480x272 */
>>> - .left_margin = 3,
>>> - .right_margin = 2,
>>> - .upper_margin = 1,
>>> - .lower_margin = 1,
>>> - .hsync_len = 40,
>>> - .vsync_len = 1,
>>> - .xres = 480,
>>> - .yres = 272,
>>> - },
>>> .max_bpp = 32,
>>> .default_bpp = 16,
>>> + .xres = 480,
>>> + .yres = 272,
>>> }, {
>>> - .win_mode = { /* 7.0" 800x480 */
>>> - .left_margin = 8,
>>> - .right_margin = 13,
>>> - .upper_margin = 7,
>>> - .lower_margin = 5,
>>> - .hsync_len = 3,
>>> - .vsync_len = 1,
>>> - .xres = 800,
>>> - .yres = 480,
>>> - },
>>> .max_bpp = 32,
>>> .default_bpp = 16,
>>> + .xres = 800,
>>> + .yres = 480,
>>> },
>>> };
>>>
>>> +static struct fb_videomode mini6410_lcd_timing = {
>>> + .left_margin = 8,
>>> + .right_margin = 13,
>>> + .upper_margin = 7,
>>> + .lower_margin = 5,
>>> + .hsync_len = 3,
>>> + .vsync_len = 1,
>>> + .xres = 800,
>>> + .yres = 480,
>>> +};
>>> +
>>> static struct s3c_fb_platdata mini6410_lcd_pdata __initdata = {
>>> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
>>> + .vtiming =&mini6410_lcd_timing,
>>> .win[0] =&mini6410_fb_win[0],
>>> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
>>> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
>>> @@ -310,8 +306,8 @@ static void __init mini6410_machine_init(void)
>>> mini6410_lcd_pdata.win[0] =&mini6410_fb_win[features.lcd_index];
>>>
>>> printk(KERN_INFO "MINI6410: selected LCD display is %dx%d\n",
>>> - mini6410_lcd_pdata.win[0]->win_mode.xres,
>>> - mini6410_lcd_pdata.win[0]->win_mode.yres);
>>> + mini6410_lcd_pdata.win[0]->xres,
>>> + mini6410_lcd_pdata.win[0]->yres);
>>>
>>> s3c_nand_set_platdata(&mini6410_nand_info);
>>> s3c_fb_set_platdata(&mini6410_lcd_pdata);
>>> diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
>>> index be2a9a2..41e4f74 100644
>>> --- a/arch/arm/mach-s3c64xx/mach-real6410.c
>>> +++ b/arch/arm/mach-s3c64xx/mach-real6410.c
>>> @@ -119,36 +119,32 @@ static struct platform_device real6410_device_eth = {
>>>
>>> static struct s3c_fb_pd_win real6410_fb_win[] = {
>>> {
>>> - .win_mode = { /* 4.3" 480x272 */
>>> - .left_margin = 3,
>>> - .right_margin = 2,
>>> - .upper_margin = 1,
>>> - .lower_margin = 1,
>>> - .hsync_len = 40,
>>> - .vsync_len = 1,
>>> - .xres = 480,
>>> - .yres = 272,
>>> - },
>>> .max_bpp = 32,
>>> .default_bpp = 16,
>>> + .xres = 480,
>>> + .yres = 272,
>>> }, {
>>> - .win_mode = { /* 7.0" 800x480 */
>>> - .left_margin = 8,
>>> - .right_margin = 13,
>>> - .upper_margin = 7,
>>> - .lower_margin = 5,
>>> - .hsync_len = 3,
>>> - .vsync_len = 1,
>>> - .xres = 800,
>>> - .yres = 480,
>>> - },
>>> .max_bpp = 32,
>>> .default_bpp = 16,
>>> + .xres = 800,
>>> + .yres = 480,
>>> },
>>> };
>>>
>>> +static struct fb_videomode real6410_lcd_timing = {
>>> + .left_margin = 3,
>>> + .right_margin = 2,
>>> + .upper_margin = 1,
>>> + .lower_margin = 1,
>>> + .hsync_len = 40,
>>> + .vsync_len = 1,
>>> + .xres = 800,
>>> + .yres = 480,
>>> +};
>>
>> What is the difference between mini6410_lcd_timing and real6410_lcd_timing?
>> In my opinion, it would be good as follows:
>>
>> +static struct fb_videomode real6410_lcd_timing = {
>> + .left_margin = 8,
>> + .right_margin = 13,
>> + .upper_margin = 7,
>> + .lower_margin = 5,
>> + .hsync_len = 3,
>> + .vsync_len = 1,
>> + .xres = 800,
>> + .yres = 480,
>> +};
>>
>>
> Before this patch series, both real6410 and mini6410 had 'default_win'
> = 0 in the platform data. And, the s3c-fb driver selected the video
> timing from the window selected by the default_win parameter in s3c-fb
> platform data, i.e window 0 for both mini6440 and real6410. So, in
> this patch, while moving the timing values out of window data, the
> timing values for window 0 was selected.
>
> The timing value for window 1 was never used on mini6410 and real6410.
> So I would suggest to use timing value of window 0 in this patch.
You are wrong. Please see mini6410_parse_features(). Please do not
remove second window because it could be selected via kernel parameters
dinamically. It's very useful and I spend my hours to create it.
>
> Thanks for your comments.
>
> Regards,
> Thomas.
>
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Darius Augulis @ 2012-03-14 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000501cd0184$f088cb20$d19a6160$%han@samsung.com>
On 03/14/2012 03:51 AM, Jingoo Han wrote:
>> -----Original Message-----
>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>> Sent: Tuesday, March 13, 2012 7:11 PM
>> To: Jingoo Han
>> Cc: linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-
>> samsung-soc@vger.kernel.org; kgene.kim@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin
>> Park; JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
>> Cuelenaere
>> Subject: Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>>
>> On 13 March 2012 15:17, Jingoo Han<jg1.han@samsung.com> wrote:
>>>> -----Original Message-----
>>>> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
>>>> Sent: Tuesday, March 13, 2012 6:00 AM
>>>> To: linux-fbdev@vger.kernel.org
>>>> Cc: FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
>>>> kgene.kim@samsung.com; jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin Park;
>>>> JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
>>>> Cuelenaere
>>>> Subject: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>>>>
>>>> For all the Samsung SoC based boards which have the platform data for
>>>> s3c-fb driver, the 'default_win' element in the platform data is removed
>>>> and the lcd panel video timing values are moved out of individual window
>>>> configuration data.
>>>>
>>>> Cc: Jingoo Han<jg1.han@samsung.com>
>>>> Cc: Kyungmin Park<kyungmin.park@samsung.com>
>>>> Cc: JeongHyeon Kim<jhkim@insignal.co.kr>
>>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>>> Cc: Heiko Stuebner<heiko@sntech.de>
>>>> Cc: Ben Dooks<ben-linux@fluff.org>
>>>> Cc: Kwangwoo Lee<kwangwoo.lee@gmail.com>
>>>> Cc: Mark Brown<broonie@opensource.wolfsonmicro.com>
>>>> Cc: Peter Korsgaard<jacmet@sunsite.dk>
>>>> Cc: Darius Augulis<augulis.darius@gmail.com>
>>>> Cc: Maurus Cuelenaere<mcuelenaere@gmail.com>
>>>> Signed-off-by: Thomas Abraham<thomas.abraham@linaro.org>
>>>> ---
>>>> arch/arm/mach-exynos/mach-nuri.c | 26 ++++++++++-------
>>>> arch/arm/mach-exynos/mach-origen.c | 24 ++++++++++-------
>>>> arch/arm/mach-exynos/mach-smdkv310.c | 28 +++++++++++--------
>>>> arch/arm/mach-exynos/mach-universal_c210.c | 26 ++++++++++-------
>>>> arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 ++++++++++--------
>>>> arch/arm/mach-s3c64xx/mach-anw6410.c | 25 ++++++++++-------
>>>> arch/arm/mach-s3c64xx/mach-crag6410.c | 25 ++++++++++-------
>>>> arch/arm/mach-s3c64xx/mach-hmt.c | 24 ++++++++++-------
>>>> arch/arm/mach-s3c64xx/mach-mini6410.c | 40 ++++++++++++---------------
>>>> arch/arm/mach-s3c64xx/mach-real6410.c | 40 ++++++++++++---------------
>>>> arch/arm/mach-s3c64xx/mach-smartq5.c | 26 ++++++++++-------
>>>> arch/arm/mach-s3c64xx/mach-smartq7.c | 26 ++++++++++-------
>>>> arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 ++++++++++-------
>>>> arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 ++++++++++-------
>>>> arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 ++++++++++-------
>>>> arch/arm/mach-s5pc100/mach-smdkc100.c | 27 ++++++++++--------
>>>> arch/arm/mach-s5pv210/mach-aquila.c | 36 +++++++++++--------------
>>>> arch/arm/mach-s5pv210/mach-goni.c | 26 ++++++++++-------
>>>> arch/arm/mach-s5pv210/mach-smdkv210.c | 24 ++++++++++-------
>>>> 19 files changed, 285 insertions(+), 238 deletions(-)
>>>>
>>> [.....]
>>>
>>>> diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
>>>> index c34c2ab..24dcdc9 100644
>>>> --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
>>>> +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
>>>> @@ -153,36 +153,32 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
>>>>
>>>> static struct s3c_fb_pd_win mini6410_fb_win[] = {
>>>> {
>>>> - .win_mode = { /* 4.3" 480x272 */
>>>> - .left_margin = 3,
>>>> - .right_margin = 2,
>>>> - .upper_margin = 1,
>>>> - .lower_margin = 1,
>>>> - .hsync_len = 40,
>>>> - .vsync_len = 1,
>>>> - .xres = 480,
>>>> - .yres = 272,
>>>> - },
>>>> .max_bpp = 32,
>>>> .default_bpp = 16,
>>>> + .xres = 480,
>>>> + .yres = 272,
>>>> }, {
>>>> - .win_mode = { /* 7.0" 800x480 */
>>>> - .left_margin = 8,
>>>> - .right_margin = 13,
>>>> - .upper_margin = 7,
>>>> - .lower_margin = 5,
>>>> - .hsync_len = 3,
>>>> - .vsync_len = 1,
>>>> - .xres = 800,
>>>> - .yres = 480,
>>>> - },
>>>> .max_bpp = 32,
>>>> .default_bpp = 16,
>>>> + .xres = 800,
>>>> + .yres = 480,
>>>> },
>>>> };
>>>>
>>>> +static struct fb_videomode mini6410_lcd_timing = {
>>>> + .left_margin = 8,
>>>> + .right_margin = 13,
>>>> + .upper_margin = 7,
>>>> + .lower_margin = 5,
>>>> + .hsync_len = 3,
>>>> + .vsync_len = 1,
>>>> + .xres = 800,
>>>> + .yres = 480,
>>>> +};
>>>> +
>>>> static struct s3c_fb_platdata mini6410_lcd_pdata __initdata = {
>>>> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
>>>> + .vtiming =&mini6410_lcd_timing,
>>>> .win[0] =&mini6410_fb_win[0],
>>>> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
>>>> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
>>>> @@ -310,8 +306,8 @@ static void __init mini6410_machine_init(void)
>>>> mini6410_lcd_pdata.win[0] =&mini6410_fb_win[features.lcd_index];
>>>>
>>>> printk(KERN_INFO "MINI6410: selected LCD display is %dx%d\n",
>>>> - mini6410_lcd_pdata.win[0]->win_mode.xres,
>>>> - mini6410_lcd_pdata.win[0]->win_mode.yres);
>>>> + mini6410_lcd_pdata.win[0]->xres,
>>>> + mini6410_lcd_pdata.win[0]->yres);
>>>>
>>>> s3c_nand_set_platdata(&mini6410_nand_info);
>>>> s3c_fb_set_platdata(&mini6410_lcd_pdata);
>>>> diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
>>>> index be2a9a2..41e4f74 100644
>>>> --- a/arch/arm/mach-s3c64xx/mach-real6410.c
>>>> +++ b/arch/arm/mach-s3c64xx/mach-real6410.c
>>>> @@ -119,36 +119,32 @@ static struct platform_device real6410_device_eth = {
>>>>
>>>> static struct s3c_fb_pd_win real6410_fb_win[] = {
>>>> {
>>>> - .win_mode = { /* 4.3" 480x272 */
>>>> - .left_margin = 3,
>>>> - .right_margin = 2,
>>>> - .upper_margin = 1,
>>>> - .lower_margin = 1,
>>>> - .hsync_len = 40,
>>>> - .vsync_len = 1,
>>>> - .xres = 480,
>>>> - .yres = 272,
>>>> - },
>>>> .max_bpp = 32,
>>>> .default_bpp = 16,
>>>> + .xres = 480,
>>>> + .yres = 272,
>>>> }, {
>>>> - .win_mode = { /* 7.0" 800x480 */
>>>> - .left_margin = 8,
>>>> - .right_margin = 13,
>>>> - .upper_margin = 7,
>>>> - .lower_margin = 5,
>>>> - .hsync_len = 3,
>>>> - .vsync_len = 1,
>>>> - .xres = 800,
>>>> - .yres = 480,
>>>> - },
>>>> .max_bpp = 32,
>>>> .default_bpp = 16,
>>>> + .xres = 800,
>>>> + .yres = 480,
>>>> },
>>>> };
>>>>
>>>> +static struct fb_videomode real6410_lcd_timing = {
>>>> + .left_margin = 3,
>>>> + .right_margin = 2,
>>>> + .upper_margin = 1,
>>>> + .lower_margin = 1,
>>>> + .hsync_len = 40,
>>>> + .vsync_len = 1,
>>>> + .xres = 800,
>>>> + .yres = 480,
>>>> +};
>>>
>>> What is the difference between mini6410_lcd_timing and real6410_lcd_timing?
>>> In my opinion, it would be good as follows:
>>>
>>> +static struct fb_videomode real6410_lcd_timing = {
>>> + .left_margin = 8,
>>> + .right_margin = 13,
>>> + .upper_margin = 7,
>>> + .lower_margin = 5,
>>> + .hsync_len = 3,
>>> + .vsync_len = 1,
>>> + .xres = 800,
>>> + .yres = 480,
>>> +};
>>>
>>>
>> Before this patch series, both real6410 and mini6410 had 'default_win'
>> = 0 in the platform data. And, the s3c-fb driver selected the video
>> timing from the window selected by the default_win parameter in s3c-fb
>> platform data, i.e window 0 for both mini6440 and real6410. So, in
>> this patch, while moving the timing values out of window data, the
>> timing values for window 0 was selected.
>>
>> The timing value for window 1 was never used on mini6410 and real6410.
>> So I would suggest to use timing value of window 0 in this patch.
> OK, I see.
> Then, as you mentioned above, the timing value of mini6410 and real6410 should be same.
> Also, the mini6410 should use the timing value for window 0 as below.
>
> Also, this timing value is used for 4.3" 480x272 LCD.
> So, xres and yres would be 480 and 272, respectively, instead of 800 and 480.
>
> The mini6410 seems to use 4.3" 480x272 LCD as default LCD.
> Please refer to 'http://www.friendlyarm.net/products/mini6410'.
>
> Also, real6410 seems to use 4.3" 480x272 LCD as default LCD.
> http://s3c6410kits.googlecode.com/files/overview_Real6410.pdf
>
> Therefore, given this, the timing value of mini6410 and real6410 would be as follows.
>
> +static struct fb_videomode mini6410_lcd_timing = {
> + .left_margin = 8,
> + .right_margin = 13,
> + .upper_margin = 7,
> + .lower_margin = 5,
> + .hsync_len = 3,
> + .vsync_len = 1,
> + .xres = 480,
> + .yres = 272,
> +};
>
> +static struct fb_videomode real6410_lcd_timing = {
> + .left_margin = 8,
> + .right_margin = 13,
> + .upper_margin = 7,
> + .lower_margin = 5,
> + .hsync_len = 3,
> + .vsync_len = 1,
> + .xres = 480,
> + .yres = 272,
> +};
>
> Darius Augulis, can you confirm it?
> (Darius Augulis is a maintainer for real6410 and mini6410 boards.)
Are you going to leave only single LCD resolution for every of two
boards? If so, then my answer is no.
I have mini6410 with both 4.3" and 7" LCDs and real6410 with 7" LCD. Now
we have possibility to choose LCD size dynamically - leave it there.
What you mean "default" 4.3" size LCD? The 7" size LCD is also provided
by board sellers - I've bought it.
regards,
Darius Augulis
>
> Best regards,
> Jingoo Han
>
>> Thanks for your comments.
>>
>> Regards,
>> Thomas.
>
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: provide default timings functions for panels
From: Grazvydas Ignotas @ 2012-03-14 16:33 UTC (permalink / raw)
To: Tomi Valkeinen; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1331724142.2386.25.camel@deskari>
On Wed, Mar 14, 2012 at 1:22 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Hi,
>
> On Mon, 2012-03-12 at 13:27 +0200, Grazvydas Ignotas wrote:
>> With this we can eliminate some duplicate code in panel drivers.
>> Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
>> tpo-td043mtea1 gain support of timings control over sysfs.
>
> I don't like this patch.
>
> Panels usually have a single, fixed timing configuration that should be
> used, like the ones you mention above. There's no need to alter the
> timings.
But they often have a range of timings they can tolerate, and that can
be used to alter refresh rate, for example. We do that on pandora to
match graphics drawing rate (or multiples of it) to create a feeling
smoothness.
> But it's true that there's some duplicate code currently in the panel
> drivers. However, adding just simple funcs like you did in this patch
> doesn't work quite properly. There should be locking (for example to
> prevent disabling the panel while timings are being set), and currently
> the locking is panel driver specific.
ok, what about a version of this with .get_timings only then?
This should not need a lock unless panel has a set function, but in
that case panel will be expected to provide safe version of .get and
.set itself.
--
Gražvydas
^ permalink raw reply
* Re: [PATCH v2] OMAPDSS: provide default timings functions for panels
From: Tomi Valkeinen @ 2012-03-14 11:22 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-fbdev, linux-omap, Archit Taneja
In-Reply-To: <1331551631-11420-1-git-send-email-notasas@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 777 bytes --]
Hi,
On Mon, 2012-03-12 at 13:27 +0200, Grazvydas Ignotas wrote:
> With this we can eliminate some duplicate code in panel drivers.
> Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
> tpo-td043mtea1 gain support of timings control over sysfs.
I don't like this patch.
Panels usually have a single, fixed timing configuration that should be
used, like the ones you mention above. There's no need to alter the
timings.
But it's true that there's some duplicate code currently in the panel
drivers. However, adding just simple funcs like you did in this patch
doesn't work quite properly. There should be locking (for example to
prevent disabling the panel while timings are being set), and currently
the locking is panel driver specific.
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] x86: export 'pcibios_enabled'
From: Alan Cox @ 2012-03-14 11:21 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: H. Peter Anvin, Randy Dunlap, Stephen Rothwell, linux-next, LKML,
Michal Januszewski, linux-fbdev, x86, Andrew Morton, Wang YanQing
In-Reply-To: <4F607A18.8080004@gmx.de>
> > uvesafb could look for any PCI vga class device - which I suspect is
> > what it *should* be doing ?
>
> Would this really change depending on whether the page is NX-protected
> or not?
> Your suggestion sounds like it is about detecting whether there is any
> graphic chip present or not while the patch is about fixing an oops
> caused by NX-protection of the BIOS.
Right yes.. I misunderstood what you are trying to do. I'd assumed you
wanted to find the ROM and thus set it to the right mapping mode.
You can use set_memory_x() to mark memory executable (and _nx to set it back).
If you really need to know if NX is being used then the check
if (__supported_pte_mask & PTE_NX)
will do the trick and the variable is exported.
I'd suggest however you wrap that in a cpu_has_nx() type macro somewhere
in the arch headers.
If you go poking around pcibios values you are going to get burned if
someone is ever bored enough to make NX and PCIBIOS work together
differently.
Alan
^ permalink raw reply
* Re: [PATCH] x86: export 'pcibios_enabled'
From: Florian Tobias Schandinat @ 2012-03-14 10:59 UTC (permalink / raw)
To: Alan Cox
Cc: H. Peter Anvin, Randy Dunlap, Stephen Rothwell, linux-next, LKML,
Michal Januszewski, linux-fbdev, x86, Andrew Morton, Wang YanQing
In-Reply-To: <20120314092955.2250a782@pyramind.ukuu.org.uk>
[CC'ing Wang YanQing, the author of the patch requiring it]
On 03/14/2012 09:29 AM, Alan Cox wrote:
>>>
>>> int pcibios_enabled;
>>> +EXPORT_SYMBOL(pcibios_enabled);
>>>
>>> /* According to the BIOS specification at:
>>> * http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
>>
>> I would think this should be EXPORT_SYMBOL_GPL()... this seems like a
>> symbol with a very high likelihood to be abused in strange ways.
>
> We don't need to expose it anyway
>
> uvesafb could look for any PCI vga class device - which I suspect is
> what it *should* be doing ?
Would this really change depending on whether the page is NX-protected
or not?
Your suggestion sounds like it is about detecting whether there is any
graphic chip present or not while the patch is about fixing an oops
caused by NX-protection of the BIOS.
Best regards,
Florian Tobias Schandinat
^ permalink raw reply
* Re: [PATCH] x86: export 'pcibios_enabled'
From: Alan Cox @ 2012-03-14 9:29 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML,
Michal Januszewski, Florian Tobias Schandinat, linux-fbdev, x86,
Andrew Morton
In-Reply-To: <4F5FE9AD.7000204@zytor.com>
> >
> > int pcibios_enabled;
> > +EXPORT_SYMBOL(pcibios_enabled);
> >
> > /* According to the BIOS specification at:
> > * http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
>
> I would think this should be EXPORT_SYMBOL_GPL()... this seems like a
> symbol with a very high likelihood to be abused in strange ways.
We don't need to expose it anyway
uvesafb could look for any PCI vga class device - which I suspect is
what it *should* be doing ?
Alan
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-14 6:29 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1331704278.10557.190.camel@linux-s257.site>
On Wed, Mar 14, 2012 at 11:21 AM, joeyli <jlee@suse.com> wrote:
> 於 三，2012-03-14 於 08:13 +0530，Pradeep Subrahmanion 提到：
>> Hi Joey ,
>>
>> > Per my understood, EC firmware should change brightness but didn't do
>> > that, another
>> > way is touch i915 register in _BCM.
>>
>> how do we do this ? you mean change the _BCM implementation ?
>
> "BIOS guy" should do something like this:
>
> Method (AINT, 2, NotSerialized)
> {
> ...
> If (LEqual (Arg0, One))
> {
> Store (Divide (Multiply (Arg1, 0xFF), 0x64, ), BCLP)
> Or (BCLP, 0x80000000, BCLP) <== touch BCLP register
> Store (0x02, ASLC)
> }
>
> Method (_BCM, 1, NotSerialized)
> {
> If (LAnd (LGreaterEqual (Arg0, Zero), LLessEqual (Arg0, 0x64)))
> {
> AINT (One, Arg0) <== call AINT method
> Store (Arg0, BRTL)
> }
> }
>
>
> Just for reference, they should do that when EC didn't wire to
> backlight.
>
>> >
>> > Acer machine provide a broken _BCM implementation and they didn't test
>> > it.
>> >
>> > > > > By ' ACPI interface' , I mean 'acpi_video0' inside the
>> > > > > /sys/class/backlight. I havn't tried the /sys/class/backlight interface
>> > > > > directly . I will try that also.
>> > > >
>> > > > So writing values into /sys/class/backlight/acpi_video0/brightness does
>> > > > nothing?
>> > >
>> > >
>> > > No change in value when writing
>> > > to /sys/class/backlight/acpi_video0/brightness.
>> > >
>> > > Another thing is that when i did boot with acpi_backlight = 'acer_wmi' ,
>> > > in new kernel (3.3.0-rc7) , it shows following messages ,
>> > >
>> > > [ 8.350825] wmi: Mapper loaded
>> > > [ 10.363975] acer_wmi: Acer Laptop ACPI-WMI Extras
>> > > [ 10.396186] acer_wmi: Function bitmap for Communication Device: 0x91
>> > > [ 10.396385] acer_wmi: Brightness must be controlled by generic video
>> > > driver
>> > >
>> > > Also there was no interface inside /sys/class/backlight for acer_wmi.
>> > >
>> >
>> > Yes, acer_wmi support backlight control with AMW0 interface, your
>> > machine didn't have AMW0 interface.
>> >
>> > Normally, backlight should control by standard acpi interface.
>> >
>> > > I also tried writing directly to Embedded controller register .But no
>> > > change.
>> >
>> > The machine has broken _BCM method, because EC should do something after
>> > _BCM changed EC register.
>>
>> Thanks ,
>>
>> Pradeep Subrahmanion
>
> Why they didn't find _BCM not work?
>
> My guess is:
>
> Because the backlight control is through WDDM driver on Windows platform
> but not through standard ACPI method _BCM. They only test Windows
> platform, so, they didn't find _BCM broken.
>
> And, they also didn't really follow Microsoft WDDM spec:
>
> http://msdn.microsoft.com/en-us/windows/hardware/gg487382.aspx
>
> Per spec,
> ODM should keep _BCM works fine for any other OS didn't support WDDM
> driver, but they didn't.
>
> At last year, I told Acer PM one time for this issue, they said will
> check but finally didn't response me.
>
>
> Thanks
> Joey Lee
>
So touching the PCI LBB register is the only feasible solution now
(even though it may not be a clean method) ?
Thanks,
Pradeep Subrahmanion
--
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
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-14 5:51 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1331692996.3052.8.camel@debian.Gayathri>
於 三，2012-03-14 於 08:13 +0530，Pradeep Subrahmanion 提到：
> Hi Joey ,
>
> > Per my understood, EC firmware should change brightness but didn't do
> > that, another
> > way is touch i915 register in _BCM.
>
> how do we do this ? you mean change the _BCM implementation ?
"BIOS guy" should do something like this:
Method (AINT, 2, NotSerialized)
{
...
If (LEqual (Arg0, One))
{
Store (Divide (Multiply (Arg1, 0xFF), 0x64, ), BCLP)
Or (BCLP, 0x80000000, BCLP) <== touch BCLP register
Store (0x02, ASLC)
}
Method (_BCM, 1, NotSerialized)
{
If (LAnd (LGreaterEqual (Arg0, Zero), LLessEqual (Arg0, 0x64)))
{
AINT (One, Arg0) <== call AINT method
Store (Arg0, BRTL)
}
}
Just for reference, they should do that when EC didn't wire to
backlight.
> >
> > Acer machine provide a broken _BCM implementation and they didn't test
> > it.
> >
> > > > > By ' ACPI interface' , I mean 'acpi_video0' inside the
> > > > > /sys/class/backlight. I havn't tried the /sys/class/backlight interface
> > > > > directly . I will try that also.
> > > >
> > > > So writing values into /sys/class/backlight/acpi_video0/brightness does
> > > > nothing?
> > >
> > >
> > > No change in value when writing
> > > to /sys/class/backlight/acpi_video0/brightness.
> > >
> > > Another thing is that when i did boot with acpi_backlight = 'acer_wmi' ,
> > > in new kernel (3.3.0-rc7) , it shows following messages ,
> > >
> > > [ 8.350825] wmi: Mapper loaded
> > > [ 10.363975] acer_wmi: Acer Laptop ACPI-WMI Extras
> > > [ 10.396186] acer_wmi: Function bitmap for Communication Device: 0x91
> > > [ 10.396385] acer_wmi: Brightness must be controlled by generic video
> > > driver
> > >
> > > Also there was no interface inside /sys/class/backlight for acer_wmi.
> > >
> >
> > Yes, acer_wmi support backlight control with AMW0 interface, your
> > machine didn't have AMW0 interface.
> >
> > Normally, backlight should control by standard acpi interface.
> >
> > > I also tried writing directly to Embedded controller register .But no
> > > change.
> >
> > The machine has broken _BCM method, because EC should do something after
> > _BCM changed EC register.
>
> Thanks ,
>
> Pradeep Subrahmanion
Why they didn't find _BCM not work?
My guess is:
Because the backlight control is through WDDM driver on Windows platform
but not through standard ACPI method _BCM. They only test Windows
platform, so, they didn't find _BCM broken.
And, they also didn't really follow Microsoft WDDM spec:
http://msdn.microsoft.com/en-us/windows/hardware/gg487382.aspx
Per spec,
ODM should keep _BCM works fine for any other OS didn't support WDDM
driver, but they didn't.
At last year, I told Acer PM one time for this issue, they said will
check but finally didn't response me.
Thanks
Joey Lee
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: Pradeep Subrahmanion @ 2012-03-14 2:55 UTC (permalink / raw)
To: joeyli
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1331680373.10557.169.camel@linux-s257.site>
Hi Joey ,
> Per my understood, EC firmware should change brightness but didn't do
> that, another
> way is touch i915 register in _BCM.
how do we do this ? you mean change the _BCM implementation ?
>
> Acer machine provide a broken _BCM implementation and they didn't test
> it.
>
> > > > By ' ACPI interface' , I mean 'acpi_video0' inside the
> > > > /sys/class/backlight. I havn't tried the /sys/class/backlight interface
> > > > directly . I will try that also.
> > >
> > > So writing values into /sys/class/backlight/acpi_video0/brightness does
> > > nothing?
> >
> >
> > No change in value when writing
> > to /sys/class/backlight/acpi_video0/brightness.
> >
> > Another thing is that when i did boot with acpi_backlight = 'acer_wmi' ,
> > in new kernel (3.3.0-rc7) , it shows following messages ,
> >
> > [ 8.350825] wmi: Mapper loaded
> > [ 10.363975] acer_wmi: Acer Laptop ACPI-WMI Extras
> > [ 10.396186] acer_wmi: Function bitmap for Communication Device: 0x91
> > [ 10.396385] acer_wmi: Brightness must be controlled by generic video
> > driver
> >
> > Also there was no interface inside /sys/class/backlight for acer_wmi.
> >
>
> Yes, acer_wmi support backlight control with AMW0 interface, your
> machine didn't have AMW0 interface.
>
> Normally, backlight should control by standard acpi interface.
>
> > I also tried writing directly to Embedded controller register .But no
> > change.
>
> The machine has broken _BCM method, because EC should do something after
> _BCM changed EC register.
Thanks ,
Pradeep Subrahmanion
^ permalink raw reply
* RE: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
From: Jingoo Han @ 2012-03-14 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwSUf-gsVesduMggSuues9OLOR6DUDAAMg_tL=e3=3c0tQ@mail.gmail.com>
> -----Original Message-----
> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> Sent: Tuesday, March 13, 2012 7:11 PM
> To: Jingoo Han
> Cc: linux-fbdev@vger.kernel.org; FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-
> samsung-soc@vger.kernel.org; kgene.kim@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin
> Park; JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
> Cuelenaere
> Subject: Re: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
>
> On 13 March 2012 15:17, Jingoo Han <jg1.han@samsung.com> wrote:
> >> -----Original Message-----
> >> From: Thomas Abraham [mailto:thomas.abraham@linaro.org]
> >> Sent: Tuesday, March 13, 2012 6:00 AM
> >> To: linux-fbdev@vger.kernel.org
> >> Cc: FlorianSchandinat@gmx.de; linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org;
> >> kgene.kim@samsung.com; jg1.han@samsung.com; ben-linux@fluff.org; patches@linaro.org; Kyungmin Park;
> >> JeongHyeon Kim; Heiko Stuebner; Kwangwoo Lee; Mark Brown; Peter Korsgaard; Darius Augulis; Maurus
> >> Cuelenaere
> >> Subject: [PATCH v2 3/3] ARM: Samsung: Rework platform data of s3c-fb driver
> >>
> >> For all the Samsung SoC based boards which have the platform data for
> >> s3c-fb driver, the 'default_win' element in the platform data is removed
> >> and the lcd panel video timing values are moved out of individual window
> >> configuration data.
> >>
> >> Cc: Jingoo Han <jg1.han@samsung.com>
> >> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> >> Cc: JeongHyeon Kim <jhkim@insignal.co.kr>
> >> Cc: Kukjin Kim <kgene.kim@samsung.com>
> >> Cc: Heiko Stuebner <heiko@sntech.de>
> >> Cc: Ben Dooks <ben-linux@fluff.org>
> >> Cc: Kwangwoo Lee <kwangwoo.lee@gmail.com>
> >> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> >> Cc: Peter Korsgaard <jacmet@sunsite.dk>
> >> Cc: Darius Augulis <augulis.darius@gmail.com>
> >> Cc: Maurus Cuelenaere <mcuelenaere@gmail.com>
> >> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> >> ---
> >> arch/arm/mach-exynos/mach-nuri.c | 26 ++++++++++-------
> >> arch/arm/mach-exynos/mach-origen.c | 24 ++++++++++-------
> >> arch/arm/mach-exynos/mach-smdkv310.c | 28 +++++++++++--------
> >> arch/arm/mach-exynos/mach-universal_c210.c | 26 ++++++++++-------
> >> arch/arm/mach-s3c24xx/mach-smdk2416.c | 27 ++++++++++--------
> >> arch/arm/mach-s3c64xx/mach-anw6410.c | 25 ++++++++++-------
> >> arch/arm/mach-s3c64xx/mach-crag6410.c | 25 ++++++++++-------
> >> arch/arm/mach-s3c64xx/mach-hmt.c | 24 ++++++++++-------
> >> arch/arm/mach-s3c64xx/mach-mini6410.c | 40 ++++++++++++---------------
> >> arch/arm/mach-s3c64xx/mach-real6410.c | 40 ++++++++++++---------------
> >> arch/arm/mach-s3c64xx/mach-smartq5.c | 26 ++++++++++-------
> >> arch/arm/mach-s3c64xx/mach-smartq7.c | 26 ++++++++++-------
> >> arch/arm/mach-s3c64xx/mach-smdk6410.c | 25 ++++++++++-------
> >> arch/arm/mach-s5p64x0/mach-smdk6440.c | 24 ++++++++++-------
> >> arch/arm/mach-s5p64x0/mach-smdk6450.c | 24 ++++++++++-------
> >> arch/arm/mach-s5pc100/mach-smdkc100.c | 27 ++++++++++--------
> >> arch/arm/mach-s5pv210/mach-aquila.c | 36 +++++++++++--------------
> >> arch/arm/mach-s5pv210/mach-goni.c | 26 ++++++++++-------
> >> arch/arm/mach-s5pv210/mach-smdkv210.c | 24 ++++++++++-------
> >> 19 files changed, 285 insertions(+), 238 deletions(-)
> >>
> >
> > [.....]
> >
> >> diff --git a/arch/arm/mach-s3c64xx/mach-mini6410.c b/arch/arm/mach-s3c64xx/mach-mini6410.c
> >> index c34c2ab..24dcdc9 100644
> >> --- a/arch/arm/mach-s3c64xx/mach-mini6410.c
> >> +++ b/arch/arm/mach-s3c64xx/mach-mini6410.c
> >> @@ -153,36 +153,32 @@ static struct s3c2410_platform_nand mini6410_nand_info = {
> >>
> >> static struct s3c_fb_pd_win mini6410_fb_win[] = {
> >> {
> >> - .win_mode = { /* 4.3" 480x272 */
> >> - .left_margin = 3,
> >> - .right_margin = 2,
> >> - .upper_margin = 1,
> >> - .lower_margin = 1,
> >> - .hsync_len = 40,
> >> - .vsync_len = 1,
> >> - .xres = 480,
> >> - .yres = 272,
> >> - },
> >> .max_bpp = 32,
> >> .default_bpp = 16,
> >> + .xres = 480,
> >> + .yres = 272,
> >> }, {
> >> - .win_mode = { /* 7.0" 800x480 */
> >> - .left_margin = 8,
> >> - .right_margin = 13,
> >> - .upper_margin = 7,
> >> - .lower_margin = 5,
> >> - .hsync_len = 3,
> >> - .vsync_len = 1,
> >> - .xres = 800,
> >> - .yres = 480,
> >> - },
> >> .max_bpp = 32,
> >> .default_bpp = 16,
> >> + .xres = 800,
> >> + .yres = 480,
> >> },
> >> };
> >>
> >> +static struct fb_videomode mini6410_lcd_timing = {
> >> + .left_margin = 8,
> >> + .right_margin = 13,
> >> + .upper_margin = 7,
> >> + .lower_margin = 5,
> >> + .hsync_len = 3,
> >> + .vsync_len = 1,
> >> + .xres = 800,
> >> + .yres = 480,
> >> +};
> >> +
> >> static struct s3c_fb_platdata mini6410_lcd_pdata __initdata = {
> >> .setup_gpio = s3c64xx_fb_gpio_setup_24bpp,
> >> + .vtiming = &mini6410_lcd_timing,
> >> .win[0] = &mini6410_fb_win[0],
> >> .vidcon0 = VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
> >> .vidcon1 = VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> >> @@ -310,8 +306,8 @@ static void __init mini6410_machine_init(void)
> >> mini6410_lcd_pdata.win[0] = &mini6410_fb_win[features.lcd_index];
> >>
> >> printk(KERN_INFO "MINI6410: selected LCD display is %dx%d\n",
> >> - mini6410_lcd_pdata.win[0]->win_mode.xres,
> >> - mini6410_lcd_pdata.win[0]->win_mode.yres);
> >> + mini6410_lcd_pdata.win[0]->xres,
> >> + mini6410_lcd_pdata.win[0]->yres);
> >>
> >> s3c_nand_set_platdata(&mini6410_nand_info);
> >> s3c_fb_set_platdata(&mini6410_lcd_pdata);
> >> diff --git a/arch/arm/mach-s3c64xx/mach-real6410.c b/arch/arm/mach-s3c64xx/mach-real6410.c
> >> index be2a9a2..41e4f74 100644
> >> --- a/arch/arm/mach-s3c64xx/mach-real6410.c
> >> +++ b/arch/arm/mach-s3c64xx/mach-real6410.c
> >> @@ -119,36 +119,32 @@ static struct platform_device real6410_device_eth = {
> >>
> >> static struct s3c_fb_pd_win real6410_fb_win[] = {
> >> {
> >> - .win_mode = { /* 4.3" 480x272 */
> >> - .left_margin = 3,
> >> - .right_margin = 2,
> >> - .upper_margin = 1,
> >> - .lower_margin = 1,
> >> - .hsync_len = 40,
> >> - .vsync_len = 1,
> >> - .xres = 480,
> >> - .yres = 272,
> >> - },
> >> .max_bpp = 32,
> >> .default_bpp = 16,
> >> + .xres = 480,
> >> + .yres = 272,
> >> }, {
> >> - .win_mode = { /* 7.0" 800x480 */
> >> - .left_margin = 8,
> >> - .right_margin = 13,
> >> - .upper_margin = 7,
> >> - .lower_margin = 5,
> >> - .hsync_len = 3,
> >> - .vsync_len = 1,
> >> - .xres = 800,
> >> - .yres = 480,
> >> - },
> >> .max_bpp = 32,
> >> .default_bpp = 16,
> >> + .xres = 800,
> >> + .yres = 480,
> >> },
> >> };
> >>
> >> +static struct fb_videomode real6410_lcd_timing = {
> >> + .left_margin = 3,
> >> + .right_margin = 2,
> >> + .upper_margin = 1,
> >> + .lower_margin = 1,
> >> + .hsync_len = 40,
> >> + .vsync_len = 1,
> >> + .xres = 800,
> >> + .yres = 480,
> >> +};
> >
> >
> > What is the difference between mini6410_lcd_timing and real6410_lcd_timing?
> > In my opinion, it would be good as follows:
> >
> > +static struct fb_videomode real6410_lcd_timing = {
> > + .left_margin = 8,
> > + .right_margin = 13,
> > + .upper_margin = 7,
> > + .lower_margin = 5,
> > + .hsync_len = 3,
> > + .vsync_len = 1,
> > + .xres = 800,
> > + .yres = 480,
> > +};
> >
> >
>
> Before this patch series, both real6410 and mini6410 had 'default_win'
> = 0 in the platform data. And, the s3c-fb driver selected the video
> timing from the window selected by the default_win parameter in s3c-fb
> platform data, i.e window 0 for both mini6440 and real6410. So, in
> this patch, while moving the timing values out of window data, the
> timing values for window 0 was selected.
>
> The timing value for window 1 was never used on mini6410 and real6410.
> So I would suggest to use timing value of window 0 in this patch.
OK, I see.
Then, as you mentioned above, the timing value of mini6410 and real6410 should be same.
Also, the mini6410 should use the timing value for window 0 as below.
Also, this timing value is used for 4.3" 480x272 LCD.
So, xres and yres would be 480 and 272, respectively, instead of 800 and 480.
The mini6410 seems to use 4.3" 480x272 LCD as default LCD.
Please refer to 'http://www.friendlyarm.net/products/mini6410'.
Also, real6410 seems to use 4.3" 480x272 LCD as default LCD.
http://s3c6410kits.googlecode.com/files/overview_Real6410.pdf
Therefore, given this, the timing value of mini6410 and real6410 would be as follows.
+static struct fb_videomode mini6410_lcd_timing = {
+ .left_margin = 8,
+ .right_margin = 13,
+ .upper_margin = 7,
+ .lower_margin = 5,
+ .hsync_len = 3,
+ .vsync_len = 1,
+ .xres = 480,
+ .yres = 272,
+};
+static struct fb_videomode real6410_lcd_timing = {
+ .left_margin = 8,
+ .right_margin = 13,
+ .upper_margin = 7,
+ .lower_margin = 5,
+ .hsync_len = 3,
+ .vsync_len = 1,
+ .xres = 480,
+ .yres = 272,
+};
Darius Augulis, can you confirm it?
(Darius Augulis is a maintainer for real6410 and mini6410 boards.)
Best regards,
Jingoo Han
>
> Thanks for your comments.
>
> Regards,
> Thomas.
^ permalink raw reply
* Re: [PATCH] x86: export 'pcibios_enabled'
From: H. Peter Anvin @ 2012-03-14 0:43 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, Michal Januszewski,
Florian Tobias Schandinat, linux-fbdev, x86, Andrew Morton
In-Reply-To: <4F5FAE63.3090908@xenotime.net>
On 03/13/2012 01:30 PM, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
>
> Export 'pcibios_enabled' so that when uvesafb is built as a
> loadable module (on X86_32), the build will succeed.
>
> ERROR: "pcibios_enabled" [drivers/video/uvesafb.ko] undefined!
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> Cc: Michal Januszewski <spock@gentoo.org>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: x86@kernel.org
> ---
> Applies to mainline; found in linux-next.
>
> arch/x86/pci/pcbios.c | 1 +
> 1 file changed, 1 insertion(+)
>
> --- linux-next-20120313.orig/arch/x86/pci/pcbios.c
> +++ linux-next-20120313/arch/x86/pci/pcbios.c
> @@ -27,6 +27,7 @@
> #define PCIBIOS_HW_TYPE2_SPEC 0x20
>
> int pcibios_enabled;
> +EXPORT_SYMBOL(pcibios_enabled);
>
> /* According to the BIOS specification at:
> * http://members.datafast.net.au/dft0802/specs/bios21.pdf, we could
I would think this should be EXPORT_SYMBOL_GPL()... this seems like a
symbol with a very high likelihood to be abused in strange ways.
-hpa
^ permalink raw reply
* Re: [PATCH] Added backlight driver for Acer Aspire 4736
From: joeyli @ 2012-03-13 23:12 UTC (permalink / raw)
To: Pradeep Subrahmanion
Cc: Matthew Garrett, rpurdie, FlorianSchandinat, akpm, linux-fbdev,
linux-kernel
In-Reply-To: <1331688294.2577.19.camel@debian.Gayathri>
Hi Pradeep,
於 二，2012-03-13 於 21:24 -0400，Pradeep Subrahmanion 提到：
> On Tue, 2012-03-13 at 13:34 +0000, Matthew Garrett wrote:
> > On Tue, Mar 13, 2012 at 06:56:16PM +0530, Pradeep Subrahmanion wrote:
> > > I tried giving acpi_backlight = vendor . In that case hot key for
> > > brightness control is working. But i think , it is not calculating the
> > > correct value for brightness because increasing brightness after maximum
> > > level gives blank screen .
> >
> > Which backlight device appears then?
> >
>
> 'intel_backlight' appears when i gave option acpi_backlight = vendor. Writing to /sys/class/backlight/intel_backlight/brightness
>
> does not cause any change in brightness.
>
The above command not work, that means EC didn't change backlight
value:
Method (_BCM, 1, NotSerialized)
{
Divide (Arg0, 0x0A, Local0, Local1)
Decrement (Local1)
Store (Local1, ^^^^LPC.EC0.BRTS) <== write backlight value to EC
register
}
Per my understood, EC firmware should change brightness but didn't do
that, another
way is touch i915 register in _BCM.
Acer machine provide a broken _BCM implementation and they didn't test
it.
> > > By ' ACPI interface' , I mean 'acpi_video0' inside the
> > > /sys/class/backlight. I havn't tried the /sys/class/backlight interface
> > > directly . I will try that also.
> >
> > So writing values into /sys/class/backlight/acpi_video0/brightness does
> > nothing?
>
>
> No change in value when writing
> to /sys/class/backlight/acpi_video0/brightness.
>
> Another thing is that when i did boot with acpi_backlight = 'acer_wmi' ,
> in new kernel (3.3.0-rc7) , it shows following messages ,
>
> [ 8.350825] wmi: Mapper loaded
> [ 10.363975] acer_wmi: Acer Laptop ACPI-WMI Extras
> [ 10.396186] acer_wmi: Function bitmap for Communication Device: 0x91
> [ 10.396385] acer_wmi: Brightness must be controlled by generic video
> driver
>
> Also there was no interface inside /sys/class/backlight for acer_wmi.
>
Yes, acer_wmi support backlight control with AMW0 interface, your
machine didn't have AMW0 interface.
Normally, backlight should control by standard acpi interface.
> I also tried writing directly to Embedded controller register .But no
> change.
The machine has broken _BCM method, because EC should do something after
_BCM changed EC register.
> ----
>
> Thanks ,
>
> Pradeep Subrahmanion
>
Thanks a lot!
Joey Lee
^ 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