Re: [PATCH 09/21] drm/omap: handle mismatching color format and buffer width
Hi, On 2 March 2015 at 09:50, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 27/02/15 16:40, Daniel Stone wrote: On 27 February 2015 at 13:01, Daniel Vetter dan...@ffwll.ch wrote: On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote: omapdrm doesn't check if the width of the framebuffer and the color s/width/pitch/ format's bits-per-pixel match. s/match/are compatible/ For example, using a display with a width of 1280, and a buffer allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with Might be clearer to say 'i.e. byte stride of ...', and also s/with using/for/. Above you said pitch, here you say stride. They are the same thing, right? Yeah, they're interchangeable. In theory, I think it's supposed to be that pitch is in pixels and stride in bpp, but they're so often interchanged that they've lost that distinction. Still, using one consistently is always good - and since KMS uses pitch exclusively, that might be a good one to settle on. stride_bpp is very misnamed: it is the bits per pixel for that plane, and not stride at all. I think the check should in fact be be (pitch % I don't know why Rob named it like that. The bpp of the stride? Shrug. It's just the bpp of the pixel format; it's not at all associated with the stride? This isn't that check. At some stages, OMAP IIRC requires pitch to be specified in pixels rather than bytes, so this makes sure that's possible to express. Right, that's what this patch was trying to achieve. However... After thinking about this and going through some of the DISPC code, I think that's not a strict requirement. We do calculate all the configs using pixels as units, so at the moment the stride has to be an integer number of pixels. But the hardware actually takes the row-inc and pix-inc as bytes. That said, the HW supports features like rotation and whatnot, and it was not clear with a quick study if there are corner cases where the hardware also requires the stride to be an integer number of pixels. Also, the HW documentation only talks about pixels in this context, even if the final value written to the registers is in bytes. I don't know if that's just to make the documentation simpler, or if there's some reasoning to only use pixel units. Indeed that was my impression from a quick look, but my OMAP is extremely rusty these days, so wasn't quite sure ... :) Specifying pixel units isn't totally unheard of, but bytes is definitely more common. Cheers, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/21] drm/omap: handle mismatching color format and buffer width
Hi,
On 27 February 2015 at 13:01, Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Feb 26, 2015 at 03:20:17PM +0200, Tomi Valkeinen wrote:
omapdrm doesn't check if the width of the framebuffer and the color
s/width/pitch/
format's bits-per-pixel match.
s/match/are compatible/
For example, using a display with a width of 1280, and a buffer
allocated with using 32 bits per pixel (i.e. 1280*4 = 5120 bytes), with
Might be clearer to say 'i.e. byte stride of ...', and also s/with using/for/.
a 24 bits per pixel color format, leads to the following mismatch:
5120/3 = 1706.666... bytes. This causes bad colors and a tilt on the
s/bytes/pixels/
screen.
Add a check into omapdrm to return an error if the user tries to use
such a combination.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/gpu/drm/omapdrm/omap_fb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 2975096abdf5..bf98580223d0 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -463,6 +463,14 @@ struct drm_framebuffer *omap_framebuffer_init(struct
drm_device *dev,
goto fail;
}
+ if (mode_cmd-width % format-planes[i].stride_bpp != 0) {
width is in pixels. No idea what you're trying to check here, but this
probably isn't it.
stride_bpp is very misnamed: it is the bits per pixel for that plane,
and not stride at all. I think the check should in fact be be (pitch %
format-planes[i].stride_bpp), which would achieve the desired result,
i.e. that the stride can be expressed as an integer number of pixels.
Also drm checks that things fit into the specified pitch (which is in
bytes), see the pichtes[i] width * cpp check in framebuffer_check.
This isn't that check. At some stages, OMAP IIRC requires pitch to be
specified in pixels rather than bytes, so this makes sure that's
possible to express.
Cheers,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] FB: OMAP: Blizzard: Properly disable zoom when necessary
From: Siarhei Siamashka [EMAIL PROTECTED]
The problem is related to the following notice in the documentation:
Once a destructive window with up-scaling is created, it can only be
disabled by creating a background window.. With the current omapfb
driver code, if you try to do a partial screen update (show menu or
dialog) after a scaled screen update (video overlay), scaling setting
are not reset properly and you see this magnifying glass effect if a
part of new update overlaps previously scaled area.
Signed-off-by: Siarhei Siamashka [EMAIL PROTECTED]
Signed-off-by: Daniel Stone [EMAIL PROTECTED]
---
drivers/video/omap/blizzard.c | 56 ++---
1 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap/blizzard.c b/drivers/video/omap/blizzard.c
index 6031b89..f60a233 100644
--- a/drivers/video/omap/blizzard.c
+++ b/drivers/video/omap/blizzard.c
@@ -163,6 +163,10 @@ struct blizzard_struct {
int vid_scaled;
int last_color_mode;
int zoom_on;
+ int zoom_area_gx1;
+ int zoom_area_gx2;
+ int zoom_area_gy1;
+ int zoom_area_gy2;
int screen_width;
int screen_height;
unsignedte_connected:1;
@@ -514,6 +518,12 @@ static int do_full_screen_update(struct blizzard_request
*req)
return REQ_PENDING;
}
+static int check_1d_intersect(int a1, int a2, int b1, int b2)
+{
+if (a2 = b1 || b2 = a1) return 0;
+return 1;
+}
+
/* Setup all planes with an overlapping area with the update window. */
static int do_partial_update(struct blizzard_request *req, int plane,
int x, int y, int w, int h,
@@ -526,6 +536,7 @@ static int do_partial_update(struct blizzard_request *req,
int plane,
int color_mode;
int flags;
int zoom_off;
+ int have_zoom_for_this_update = 0;
/* Global coordinates, relative to pixel 0,0 of the LCD */
gx1 = x + blizzard.plane[plane].pos_x;
@@ -545,10 +556,6 @@ static int do_partial_update(struct blizzard_request *req,
int plane,
gx2_out = gx1_out + w_out;
gy2_out = gy1_out + h_out;
}
- zoom_off = blizzard.zoom_on gx1 == 0 gy1 == 0
- w == blizzard.screen_width h == blizzard.screen_height;
- blizzard.zoom_on = (!zoom_off blizzard.zoom_on) ||
- (w w_out || h h_out);
for (i = 0; i OMAPFB_PLANE_NUM; i++) {
struct plane_info *p = blizzard.plane[i];
@@ -654,8 +661,49 @@ static int do_partial_update(struct blizzard_request *req,
int plane,
else
disable_tearsync();
+ if ((gx2_out - gx1_out) != (gx2 - gx1) ||
+ (gy2_out - gy1_out) != (gy2 - gy1))
+ have_zoom_for_this_update = 1;
+
+ /* 'background' type of screen update (as opposed to 'destructive')
+ can be used to disable scaling if scaling is active */
+ zoom_off = blizzard.zoom_on !have_zoom_for_this_update
+ (gx1_out == 0) (gx2_out == blizzard.screen_width)
+ (gy1_out == 0) (gy2_out == blizzard.screen_height)
+ (gx1 == 0) (gy1 == 0);
+
+ if (blizzard.zoom_on !have_zoom_for_this_update !zoom_off
+ check_1d_intersect(blizzard.zoom_area_gx1, blizzard.zoom_area_gx2,
+ gx1_out, gx2_out)
+ check_1d_intersect(blizzard.zoom_area_gy1, blizzard.zoom_area_gy2,
+ gy1_out, gy2_out)) {
+ /* Previous screen update was using scaling, current update
+* is not using it. Additionally, current screen update is
+* going to overlap with the scaled area. Scaling needs to be
+* disabled in order to avoid 'magnifying glass' effect.
+* Dummy setup of background window can be used for this.
+*/
+ set_window_regs(0, 0, blizzard.screen_width,
+ blizzard.screen_height,
+ 0, 0, blizzard.screen_width,
+ blizzard.screen_height,
+ BLIZZARD_COLOR_RGB565, 1, flags);
+ blizzard.zoom_on = 0;
+ }
+
+ /* remember scaling settings if we have scaled update */
+ if (have_zoom_for_this_update) {
+ blizzard.zoom_on = 1;
+ blizzard.zoom_area_gx1 = gx1_out;
+ blizzard.zoom_area_gx2 = gx2_out;
+ blizzard.zoom_area_gy1 = gy1_out;
+ blizzard.zoom_area_gy2 = gy2_out;
+ }
+
set_window_regs(gx1, gy1, gx2, gy2, gx1_out, gy1_out, gx2_out, gy2_out,
color_mode, zoom_off, flags);
+ if (zoom_off
[PATCH 1/2] Input: Touchscreen: Make TSC2005 depend on SPI
Make Kconfig reflect reality. Signed-off-by: Daniel Stone [EMAIL PROTECTED] --- drivers/input/touchscreen/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index d33f450..84ba956 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -219,6 +219,7 @@ config TOUCHSCREEN_ATMEL_TSADCC config TOUCHSCREEN_TSC2005 tristate TSC2005 touchscreen support + depends on SPI_MASTER help Say Y here for if you are using the touchscreen features of TSC2005. -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] omapfb bugfixes
On Thu, Oct 09, 2008 at 12:58:55PM +0300, ext Tony Lindgren wrote: * Daniel Stone [EMAIL PROTECTED] [081009 12:39]: Hi, These should be fine for merging, one bugfix from Siarhei and one tiny Kconfig dependency update. OK. Can you also refresh your FB: OMAP: DISPC: Allow multiple external IRQ handlers patch? Sure, no problem. Sent now. We really should get all the fb stuff to fbdevel list, but let's wait a bit on that, too many other things to deal with right now. Yeah, good point, sorry. :) Cheers, Daniel signature.asc Description: Digital signature
[PATCH 0/2] omapfb bugfixes
Hi, These should be fine for merging, one bugfix from Siarhei and one tiny Kconfig dependency update. Cheers, Daniel signature.asc Description: Digital signature
[PATCH] FB: OMAP: DISPC: Allow multiple external IRQ handlers
Previously, the only external (to dispc.c) IRQ handler was RFBI's
frame done handler. dispc's IRQ framework was very dumb: you could only
have one handler, and the semantics of {request,free}_irq were odd, to
say the least.
The new framework allows multiple consumers to register arbitrary IRQ
masks.
Signed-off-by: Daniel Stone [EMAIL PROTECTED]
---
drivers/video/omap/dispc.c | 94 ++-
drivers/video/omap/dispc.h |7 ++-
drivers/video/omap/rfbi.c |6 ++-
3 files changed, 65 insertions(+), 42 deletions(-)
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index ce4c4de..beda40b 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -155,6 +155,8 @@ struct resmap {
unsigned long *map;
};
+#define MAX_IRQ_HANDLERS4
+
static struct {
void __iomem*base;
@@ -167,9 +169,11 @@ static struct {
int ext_mode;
- unsigned long enabled_irqs;
- void(*irq_callback)(void *);
- void*irq_callback_data;
+ struct {
+ u32 irq_mask;
+ void(*callback)(void *);
+ void*data;
+ } irq_handlers[MAX_IRQ_HANDLERS];
struct completion frame_done;
int fir_hinc[OMAPFB_PLANE_NUM];
@@ -808,56 +812,70 @@ static void set_lcd_timings(void)
panel-pixel_clock = fck / lck_div / pck_div / 1000;
}
-int omap_dispc_request_irq(void (*callback)(void *data), void *data)
+static void recalc_irq_mask(void)
{
- int r = 0;
+ int i;
+ unsigned long irq_mask = DISPC_IRQ_MASK_ERROR;
- BUG_ON(callback == NULL);
+ for (i = 0; i MAX_IRQ_HANDLERS; i++) {
+ if (!dispc.irq_handlers[i].callback)
+ continue;
- if (dispc.irq_callback)
- r = -EBUSY;
- else {
- dispc.irq_callback = callback;
- dispc.irq_callback_data = data;
+ irq_mask |= dispc.irq_handlers[i].irq_mask;
}
- return r;
-}
-EXPORT_SYMBOL(omap_dispc_request_irq);
-
-void omap_dispc_enable_irqs(int irq_mask)
-{
enable_lcd_clocks(1);
- dispc.enabled_irqs = irq_mask;
- irq_mask |= DISPC_IRQ_MASK_ERROR;
MOD_REG_FLD(DISPC_IRQENABLE, 0x7fff, irq_mask);
enable_lcd_clocks(0);
}
-EXPORT_SYMBOL(omap_dispc_enable_irqs);
-void omap_dispc_disable_irqs(int irq_mask)
+int omap_dispc_request_irq(unsigned long irq_mask, void (*callback)(void
*data),
+ void *data)
{
- enable_lcd_clocks(1);
- dispc.enabled_irqs = ~irq_mask;
- irq_mask = ~DISPC_IRQ_MASK_ERROR;
- MOD_REG_FLD(DISPC_IRQENABLE, 0x7fff, irq_mask);
- enable_lcd_clocks(0);
+ int i;
+
+ BUG_ON(callback == NULL);
+
+ for (i = 0; i MAX_IRQ_HANDLERS; i++) {
+ if (dispc.irq_handlers[i].callback)
+ continue;
+
+ dispc.irq_handlers[i].irq_mask = irq_mask;
+ dispc.irq_handlers[i].callback = callback;
+ dispc.irq_handlers[i].data = data;
+ recalc_irq_mask();
+
+ return 0;
+ }
+
+ return -EBUSY;
}
-EXPORT_SYMBOL(omap_dispc_disable_irqs);
+EXPORT_SYMBOL(omap_dispc_request_irq);
-void omap_dispc_free_irq(void)
+void omap_dispc_free_irq(unsigned long irq_mask, void (*callback)(void *data),
+void *data)
{
- enable_lcd_clocks(1);
- omap_dispc_disable_irqs(DISPC_IRQ_MASK_ALL);
- dispc.irq_callback = NULL;
- dispc.irq_callback_data = NULL;
- enable_lcd_clocks(0);
+ int i;
+
+ for (i = 0; i MAX_IRQ_HANDLERS; i++) {
+ if (dispc.irq_handlers[i].callback == callback
+ dispc.irq_handlers[i].data == data) {
+ dispc.irq_handlers[i].irq_mask = 0;
+ dispc.irq_handlers[i].callback = NULL;
+ dispc.irq_handlers[i].data = NULL;
+ recalc_irq_mask();
+ return;
+ }
+ }
+
+ BUG();
}
EXPORT_SYMBOL(omap_dispc_free_irq);
static irqreturn_t omap_dispc_irq_handler(int irq, void *dev)
{
u32 stat;
+ int i = 0;
enable_lcd_clocks(1);
@@ -872,8 +890,11 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*dev)
}
}
- if ((stat dispc.enabled_irqs) dispc.irq_callback)
- dispc.irq_callback(dispc.irq_callback_data);
+ for (i = 0; i MAX_IRQ_HANDLERS; i++) {
+ if (unlikely(dispc.irq_handlers[i].callback
+(stat dispc.irq_handlers[i].irq_mask)))
+ dispc.irq_handlers[i].callback(dispc.irq_handlers[i].data);
+ }
dispc_write_reg(DISPC_IRQSTATUS, stat);
@@ -1411,8 +1432,7 @@ static int omap_dispc_init(struct omapfb_device *fbdev
Re: [PATCH] kill warnings in gpmc
On Tue, Oct 07, 2008 at 06:43:41PM +0530, ext Pakaravoor, Jagadeesh wrote: I had sent that fix for the same, though not merged in yet. :) Oops.. I forgot about V2 patch. :( ==Cut here== From: Jagadeesh Bhaskar Pakaravoor [EMAIL PROTECTED] Return type of gpmc_init() function is void. Also, the error values returned by the function is not used by the caller. Hence it should not be returning any value. Signed-off-by: Anand Gadiyar [EMAIL PROTECTED] Signed-off-by: Jagadeesh Bhaskar Pakaravoor [EMAIL PROTECTED] Signed-off-by: Daniel Stone [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [PATCH 1/3] i2c: lp5521: remove dead code
On Mon, Oct 06, 2008 at 12:11:29PM +0300, ext Felipe Balbi wrote: That LED_CONNECTED_WRONG was never defined so removing. If someone needs those hooks, add back via proper platform_data instead of nasty ifdefery. Signed-off-by: Felipe Balbi [EMAIL PROTECTED] Signed-off-by: Daniel Stone [EMAIL PROTECTED] IIRC, LED_CONNECTED_WRONG was only for early hardware builds of the N810. Cheers, Daniel signature.asc Description: Digital signature
Re: [PATCH] gpmc: Remove compilation warning
On Mon, Sep 29, 2008 at 06:40:43PM +0530, ext Pakaravoor, Jagadeesh wrote:
From: Jagadeesh Bhaskar Pakaravoor [EMAIL PROTECTED]
Return type of gpmc_init() function is void. Also, the error values
returned by the function is not used by the caller. Hence it should
not be returning any value.
Signed-off-by: Anand Gadiyar [EMAIL PROTECTED]
Signed-off-by: Jagadeesh Bhaskar Pakaravoor [EMAIL PROTECTED]
--
Index: linux-omap-git/arch/arm/mach-omap2/gpmc.c
===
--- linux-omap-git.orig/arch/arm/mach-omap2/gpmc.c2008-09-25
17:30:24.0 +0530
+++ linux-omap-git/arch/arm/mach-omap2/gpmc.c 2008-09-29 18:26:40.845433948
+0530
@@ -427,16 +427,13 @@ void __init gpmc_init(void)
}
gpmc_l3_clk = clk_get(NULL, ck);
- if (IS_ERR(gpmc_l3_clk)) {
+ if (IS_ERR(gpmc_l3_clk))
printk(KERN_ERR Could not get GPMC clock %s\n, ck);
- return -ENODEV;
- }
Surely you'd be better off making this one 'return;', instead of
blithely continuing.
gpmc_base = ioremap(l, SZ_4K);
if (!gpmc_base) {
clk_put(gpmc_l3_clk);
printk(KERN_ERR Could not get GPMC register memory\n);
- return -ENOMEM;
}
Ditto.
BUG_ON(IS_ERR(gpmc_l3_clk));
You have to decide if you're going to printk and return, or assume this
can never happen and call BUG_ON _instead_.
Cheers,
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2: Fix definition of SGX clock register bits
On Wed, Sep 10, 2008 at 05:13:03PM -0700, ext Tony Lindgren wrote:
* Daniel Stone [EMAIL PROTECTED] [080827 02:47]:
On Wed, Aug 27, 2008 at 12:50:37AM -0600, ext Paul Walmsley wrote:
Hello Daniel,
On Wed, 27 Aug 2008, Daniel Stone wrote:
Yep, looks fine to me: just wasn't really sure what to put. Should I
resend, or?
yes, please resend - that will make it convenient for Tony to apply the
patches.
Hi,
I'll do that. Thanks a lot for the review.
ping, any news on the updated patch?
Sorry, my bad. Inlined below.
Cheers,
Daniel
From d8f04561d17adc8c52f8c2d6091bc9897904feb7 Mon Sep 17 00:00:00 2001
From: Daniel Stone [EMAIL PROTECTED]
Date: Wed, 27 Aug 2008 04:31:59 +0300
Subject: [PATCH] ARM: OMAP2: Fix definition of SGX clock register bits
The GFX/SGX functional and interface clocks have different masks, for
some unknown reason, so split EN_SGX_SHIFT into one each for fclk and
iclk.
Correct according to the TRM and the far more important 'does this
actually work at all?' metric.
Signed-off-by: Daniel Stone [EMAIL PROTECTED]
---
arch/arm/mach-omap2/clock34xx.h |4 ++--
arch/arm/mach-omap2/cm-regbits-34xx.h |8 ++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/clock34xx.h b/arch/arm/mach-omap2/clock34xx.h
index d7d6ffd..ce96270 100644
--- a/arch/arm/mach-omap2/clock34xx.h
+++ b/arch/arm/mach-omap2/clock34xx.h
@@ -1323,7 +1323,7 @@ static struct clk sgx_fck = {
.name = sgx_fck,
.init = omap2_init_clksel_parent,
.enable_reg = _OMAP34XX_CM_REGADDR(OMAP3430ES2_SGX_MOD, CM_FCLKEN),
- .enable_bit = OMAP3430ES2_EN_SGX_SHIFT,
+ .enable_bit = OMAP3430ES2_CM_FCLKEN_SGX_EN_SGX_SHIFT,
.clksel_reg = _OMAP34XX_CM_REGADDR(OMAP3430ES2_SGX_MOD, CM_CLKSEL),
.clksel_mask= OMAP3430ES2_CLKSEL_SGX_MASK,
.clksel = sgx_clksel,
@@ -1337,7 +1337,7 @@ static struct clk sgx_ick = {
.parent = l3_ick,
.init = omap2_init_clk_clkdm,
.enable_reg = _OMAP34XX_CM_REGADDR(OMAP3430ES2_SGX_MOD, CM_ICLKEN),
- .enable_bit = OMAP3430ES2_EN_SGX_SHIFT,
+ .enable_bit = OMAP3430ES2_CM_ICLKEN_SGX_EN_SGX_SHIFT,
.flags = CLOCK_IN_OMAP3430ES2,
.clkdm = { .name = sgx_clkdm },
.recalc = followparent_recalc,
diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h
b/arch/arm/mach-omap2/cm-regbits-34xx.h
index ffb695b..fe8e9ef 100644
--- a/arch/arm/mach-omap2/cm-regbits-34xx.h
+++ b/arch/arm/mach-omap2/cm-regbits-34xx.h
@@ -340,8 +340,12 @@
#define OMAP3430ES1_CLKACTIVITY_GFX_MASK (1 0)
/* CM_FCLKEN_SGX */
-#define OMAP3430ES2_EN_SGX_SHIFT 1
-#define OMAP3430ES2_EN_SGX_MASK(1 1)
+#define OMAP3430ES2_CM_FCLKEN_SGX_EN_SGX_SHIFT 1
+#define OMAP3430ES2_CM_FCLKEN_SGX_EN_SGX_MASK (1 1)
+
+/* CM_ICLKEN_SGX */
+#define OMAP3430ES2_CM_ICLKEN_SGX_EN_SGX_SHIFT 0
+#define OMAP3430ES2_CM_ICLKEN_SGX_EN_SGX_MASK (1 0)
/* CM_CLKSEL_SGX */
#define OMAP3430ES2_CLKSEL_SGX_SHIFT 0
--
1.5.6.3
signature.asc
Description: Digital signature
Re: [PATCH 15/29] OMAP3: PM: Move serial console check from omap3_can_sleep to idle loop
On Thu, Sep 11, 2008 at 03:33:59PM +0300, ext Kevin Hilman wrote: Signed-off-by: Git administrator [EMAIL PROTECTED] Oops. :) Cheers, Daniel signature.asc Description: Digital signature
Re: [PATCH] omapfb: setting GOLCD bit for shadow registers to make effect
On Mon, Sep 08, 2008 at 09:02:56PM +0100, ext Måns Rullgård wrote: arun c [EMAIL PROTECTED] writes: + while (dispc_read_reg(DISPC_CONTROL) (1 5)) + continue; + MOD_REG_FLD(DISPC_CONTROL, 1 5, 1 5); + return height * screen_width * bpp / 8; } This looks good. However, the same thing is needed in omap_dispc_enable_plane() as well. Placing the loop+set in a function (go_lcd()?) would make sense. Preferably something with a slightly more generic name, so it could also fire GODIGITAL for digital out, when support for that exists. Cheers, Daniel signature.asc Description: Digital signature
Re: [PATCH 12/33] Add tsc2005 touchscreen driver
On Mon, Sep 01, 2008 at 03:01:43AM +0200, ext andrzej zaborowski wrote:
2008/8/30 Felipe Balbi [EMAIL PROTECTED]:
[roughly 470 irrelevant lines discarded]
+ /* discard the event if it still is within the previous rect -
unless
+* if the pressure is harder, but then use previous x,y position */
+ inside_rect = (ts-sample_sent
+ x (int)ts-x - TS_RECT_SIZE
+ x (int)ts-x + TS_RECT_SIZE
+ y (int)ts-y - TS_RECT_SIZE
+ y (int)ts-y + TS_RECT_SIZE);
+ if (inside_rect)
+ x = ts-x, y = ts-y;
+
+ if (!inside_rect || pressure ts-p) {
+ tsc2005_ts_update_pen_state(ts, x, y, pressure);
+ ts-sample_sent = 1;
+ ts-x = x;
+ ts-y = y;
+ ts-p = pressure;
+ }
Minor nit: will this not break ts_calibrate from tslib? ts_calibrate
tries to read 5 samples for every touch, so the user will need to be
moving the pen. I hit this in emulators where noise needs to be added
artifically because userspace (tslib) relies on it.
Also curious why report if pressure becomes harder but not when softer.
Works fine for us, but of course that depends on your tslib
configuration. We decided to remove the filtering and whathaveyou from
tslib and in a novel move, actually receive useful and correct events
from evdev, instead of something that needs to be subjected to further
arbitrary filtering to be usable.
Cheers,
Daniel
signature.asc
Description: Digital signature
[PATCH 0/2] Minor display fixes
Hi, The following two patches fix two minor display issues. One is that sgx_fck was useless, and didn't work (at least on ES2.0 and above; haven't checked the TRM for pre-ES2.0). The other is that the dispc IRQ handling was rather odd and inflexible, so due to the needs of ... an external consumer ... I made it a bit more sensible. Tested on 3430. Cheers, Daniel signature.asc Description: Digital signature
Re: [PATCH 1/2] ARM: OMAP2: Fix definition of SGX clock register bits
On Tue, Aug 26, 2008 at 11:05:42PM -0600, ext Paul Walmsley wrote: Hello Daniel, Hi, On Wed, 27 Aug 2008, Daniel Stone wrote: The GFX/SGX functional and interface clocks have different masks, for some unknown reason, so split EN_SGX_SHIFT into one each for fclk and iclk. thanks for the fix, this looks mostly good - one comment: diff --git a/arch/arm/mach-omap2/cm-regbits-34xx.h b/arch/arm/mach-omap2/cm-regbits-34xx.h index ffb695b..06a78a7 100644 --- a/arch/arm/mach-omap2/cm-regbits-34xx.h +++ b/arch/arm/mach-omap2/cm-regbits-34xx.h @@ -339,9 +339,11 @@ #define OMAP3430ES1_CLKACTIVITY_GFX_SHIFT 0 #define OMAP3430ES1_CLKACTIVITY_GFX_MASK (1 0) -/* CM_FCLKEN_SGX */ -#define OMAP3430ES2_EN_SGX_SHIFT 1 -#define OMAP3430ES2_EN_SGX_MASK(1 1) +/* CM_FCLKEN_SGX/CM_ICLKEN_SGX */ +#define OMAP3430ES2_EN_SGX_FSHIFT 1 +#define OMAP3430ES2_EN_SGX_FMASK (1 1) +#define OMAP3430ES2_EN_SGX_ISHIFT 0 +#define OMAP3430ES2_EN_SGX_IMASK (1 0) To keep these consistent with prior practice in prm-regbits-34xx.h for name collisions, could you change the above to look something like: /* CM_FCLKEN_SGX */ #define OMAP3430ES2_CM_FCLKEN_SGX_EN_SGX_SHIFT 1 #define OMAP3430ES2_CM_FCLKEN_SGX_EN_SGX_MASK(1 1) /* CM_ICLKEN_SGX */ #define OMAP3430ES2_CM_ICLKEN_SGX_EN_SGX_SHIFT 0 #define OMAP3430ES2_CM_ICLKEN_SGX_EN_SGX_MASK(1 0) Ugly, but unambiguous. Yep, looks fine to me: just wasn't really sure what to put. Should I resend, or? Cheers, Daniel signature.asc Description: Digital signature
Re: USB driver issue
On Sat, Aug 02, 2008 at 01:51:59AM -0700, ext Emanoil Kotsev wrote: Kernel developers should fix bugs in minor kernel versions as they are meant for this purpous and do major changes only in major version. A bunch of bugfixes I see (not only usb related) are just not in place in minor kernel versions. That's my opinion at first place. Minor (2.6.x.y) releases happen with only bugfixes every few weeks. Perhaps you should use them. But realize that they are only supported for about 3-4 months, then you are expected to move to the next major release. This is the issue 3-4 months are enough for ATI or NVidia to bring a new driver Either change the policy or find a solution! The policy is 'we do not support proprietary drivers' (both in X.Org and in the kernel). The solution is for vendors not to produce proprietary drivers. Intel, AMD/ATI, and others have already got the message and already work with us to provide high-quality open source drivers. If this bothers you, please tell NVIDIA that you're a customer who's purchased their product, and that you wish to have acceptable (i.e., open source) Linux kernel + X.Org support. That's the only way it will ever get fixed, full stop. (Well, either that or through Nouveau.) Given the rate of change in the Linux kernel (faster than any other software project known to man), how do you really expect us to do that? It's pretty impossible. The question is - what are you doing this for? What's your goal I think the primary motivation for most people could be summed up by the title of Linus Torvalds's autobiography: 'Just for Fun'. As soon as it's no longer fun (hint: attempting to force people to do things they don't think are good ideas usually drains some amount of the fun), people will begin to walk away. I'm going to give up linux soon if it goes this way I've never met you before, so you'll have to understand if myself and most others on this list aren't dropping everything to ensure you don't carry out this threat. No, we expect that you would use hardware that works with, and contributes toward the advancement of Linux. Not hardware that requires closed source modules. I spent a lot of time reading about hardware and linu support when IO bought my dell notebook, that's why I choose one with intel video vard inside ... and what happened - I don't have 3D when using dual screen - GREAT! Upgrade to Xorg 7.3 or above. Anything with xorg-server 1.3.0 or above and xf86-video-intel 2.x.x supports dual screen with 3D just fine, via XRandR 1.2. As an added bonus, you get to drop the static configuration in xorg.conf, and you can have hotplug monitor support, on-the-fly reconfiguration, etc. See http://www.intellinuxgraphics.org for more details. The Radeon driver also supports this in 6.8.x and above. Again, if you are stuck with such hardware, there is _nothing_ that I or any other kernel developer can do about it. It is physically impossible. The problem is, that ATI, NVidia and a lot of other hardware producers are willing to support linux, but can not afford it to bring up drivers for the latest stable kernel in the terms you consider it as stable - and this was my original point. AMD/ATI already support it in this model, except for fglrx, which is not actually for home consumers and game players at all, but for people like Pixar with huge renderfarms, or heavy CAD users. Hence the extreme focus on absolute GL spec compliance, et al. NVIDIA have chosen not to support that model. Their loss. Then fix the hfs modem for my dell notebook (oh ... it is closed driver by connexant - but they are willing to help me and oh, they suggest I use the 2.6.24 kernel) That's not much help then, is it? What happens when NVIDIA have a bug that forces you to downgrade to 2.6.22, which hfs doesn't support in that version? Incidentally, Ubuntu are now having to ship four NVIDIA drivers, because they keep deprecating support, and the old drivers don't always keep up with new kernel versions (even stable ones: they receive literally zero updates once your card is deemed too old). I assume this is the kind of 'help' and 'support' you keep talking about. We change because the world changes. In order to survive, we also need to change. If we stop, we die. This is true, but out of scope - see above. There is no sence to install a new kernel that does not support my hardware and also is outaged when I have the drivers for this kernel version. No-one can do anything about third-party drivers. If the driver for your NVIDIA chipset, which is written and shipped by NVIDIA, does not support the newest kernel version, then complain to NVIDIA, not the people working on the kernel. As everyone in this discussion has repeatedly said, there's nothing anyone can do about third-party drivers. Incidentally, a senior NVIDIA manager said a while ago that
Re: USB driver issue
On Thu, Jul 31, 2008 at 01:38:59PM -0700, ext Emanoil Kotsev wrote: Kernel developers should fix bugs in minor kernel versions as they are meant for this purpous and do major changes only in major version. A bunch of bugfixes I see (not only usb related) are just not in place in minor kernel versions. That's my opinion at first place. Except that the code has often changed as a result of these major changes, and not everyone wants to track everything that happens in two branches. You said it yourself: you don't want to go to the effort of tracking one major branch. So why are you trying to force developers to track two? Second if you want to have me as happy linux user developers should agree to support older versions to help embeded and other developers working further on their projects. That's unbelievably selfish and insulting. 'This free operating system you gave me is shit! You need to change the entire way you develop for my benefit!' No, sorry. If you want to support older versions, then no-one's stopping you. Hell, there's still a 2.0 maintainer. No-one's forcing them to move up to new versions. Closed source drivers have issues, film at 11. Bah, take it up with them, there is NOTHING that us developers can do about that, sorry. You are neglecting the point and kind of insulting me! So you think I should spent my time convincing about 20 people from different companies to recompile their software because I was told by you to upgrade to fix a usb issue or a kind that is not related to their software and when they finally do it there is a already a new kernel version ... sorry I can not agree with any of you on this point. You want me to spent my time contacting people and not working on my projects ;-) You said it yourself -- you object to kernel developers, who have given you a free kernel, telling you how to spend your time. Yet you have the right to tell the kernel developers how to spend _their_ time, including supporting closed-source drivers, which basically amounts to reverse engineering? Have you any idea how unbelievably rude this is? Why just not be able to patch my old kernel without breaking the ability to use the software I already have installed and is working with the version I use? If you want, you can follow the development tree and backport the patches to the last stable version. No-one's trying to stop you. I think this is the question no body wants to answer and I think there is a problem with you guys. What are you doing this development if some people are not happy with it and have reasonable arguments. I think there's a problem with your attitude, and a pretty serious one at that. Open source development generally happens because people enjoy doing it. If you think they're doing it wrong, do it your way. I was up until 5:30am last night writing code, and was rewarded with a splitting headache. If you think you have a better way to do it and the others disagree, well, it's up to you to just put in and do it. Think that's hard? Have other things to do? Well yes, it is hard, and yes, we all have other things to do. Now you understand why you attempting to force people to change the way they work is disrespectful and insulting, I hope. May be the patches should be split into smaller files related to bugs - just an idea! They are. You experience a bug and patch - the bug is gone you are happy. May be there should be some longer period to support at least the latest stable releases ... but something should be done. I know the Linus policy conserning 2.6. tree has changed for the reason to let us improve faster, but since 1-2 years I have the feeling 1) that it is getting too fast and 2) that I'm not the only one saying this Okay, so put your money where your mouth is. Contribute. Until I see patches (instead of mails telling us how hard your life is because you don't have the time to test one kernel version, but kernel developers should all spend the time to test two or more) from you, I have nothing more to say to you. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB driver issue
On Wed, Jul 30, 2008 at 07:21:53AM -0700, ext Emanoil Kotsev wrote: Dear Felipe, I just want to tell, that while still developing kernels in the 2.6.2X series a kernel 2.6.22 can not be labeled as old. Actually, it can, as it was released quite a long time ago. Besides it comes along with few distros as default kernel. Yes, and these distros have to heavily patch it. A lot of people like me need some kind of a stable version that we can relay on for more than playing at home, which is the case with 2.4.X tree. Personally, experiments with 2.6.24 brought me into a big trouble and it took many hours to migrate back to 2.6.20, so please keep in mind that if we say something like this, there is a good reason to do so. I'd strongly suggest trying 2.6.26. Cheers, Daniel signature.asc Description: Digital signature
Re: USB driver issue
On Wed, Jul 30, 2008 at 09:53:43PM +0530, ext Gadiyar, Anand wrote: Grr. Saying one needs to upgrade to the latest kernel before one can expect support is a bit like certain proprietary OS vendors - and even they do a better job than this. If you want to support people running 2.6.22, good for you. You seem to be happy with a codebase that doesn't change as much, so I'm sure you'll have fun supporting it. I'm getting the feeling that we need a new Godwin's law: as a thread involving a complaint about open source grows longer, the probability of a comparison involving Microsoft approaches one. So yes, some people don't want to support old code on their own time. So what? Who are you to tell them that they can't do this? What was the point of the Microsoft comparison, except to reinforce stereotypes that free software developers are a bunch of freaks with unhealthy obsessions on Microsoft and LOL BILL GATES IS THE SUCK? (Bearing in mind that one of the main tenets of open source development is 'release early and release often', you could say that having everyone use very old code until you one day drop a huge chunk of rewritten new code on them is also OMG MICROSOFT. But that'd be equally stupid.) signature.asc Description: Digital signature
Re: [PATCH] This patch adds the driver to turn on the TFP410 framer to get DVI output working on the beagleboard
On Fri, May 16, 2008 at 11:12:35AM +0200, ext Koen Kooi wrote:
+static int omap3beagle_panel_init(struct lcd_panel *panel,
+ struct omapfb_device *fbdev)
+{
+ omap_request_gpio(LCD_PANEL_ENABLE_GPIO);
+X
... ?
+
+ return 0;
+}
signature.asc
Description: Digital signature
Re: [PATCH 0/2] Make N810 keyboard work with console
On Wed, May 14, 2008 at 09:01:17PM -0700, ext Tony Lindgren wrote: Here are few fun patches for N810 hackers to make the integrated keyboard work with console :) This should be done in a generic way and the old behaviour is preserved if optional sticky keys are not passed from platform_data. Uhm. If you're going to implement latching/locking keys, surely it'd be better to do this in the generic input layer than the keyboard driver? NAK from myself (for what little that means) simply due to the sheer horror of seeing what should, by all rights, be a tiny driver, explode into non-triviality. :) Cheers, Daniel signature.asc Description: Digital signature
Re: [PATCH 1/5] I2C: LM8323: Introduce lm8323 keypad driver
On Wed, Apr 09, 2008 at 09:05:58PM +0300, ext Felipe Balbi wrote: On Wed, Apr 09, 2008 at 07:26:31PM +0200, andrzej zaborowski wrote: Question not really related to this patchset, but in the TSC2005 driver some averaging and limit checks are done to the ADC values. Shouldn't that be done in userspace instead? (The ADS784x and TSC2301 drivers do the same evidently.) Now that's not really up to me, but if we move it now it probably won't provide the feature n810 needs. I mean, n810 is designed on top of the features provided by driver, the application probably expects the driver to do the averaging and limit checks so at least for tsc2005 I think it's not a good idea to change due to application requirements. It's specific to the device (and device _build_): the actual touchscreen, and how it's working in the device, so a combination of LCD driver and board files sounds best to me. Cheers, Daniel signature.asc Description: Digital signature
Re: [PATCH 1/5] I2C: LM8323: Introduce lm8323 keypad driver
On Thu, Apr 10, 2008 at 01:58:51AM +0200, ext andrzej zaborowski wrote: On 09/04/2008, Lauri Leukkunen [EMAIL PROTECTED] wrote: In my opinion kernel should provide correct data to user-space, not some pseudo-random interference from the LCD. I think this is discutible. There's a number of userspace libraries written to talk tightly to the kernel and make that data more correct, one of them is tslib. Distros that come with tslib often have a set of device-specific config files for tslib which load tslib plugins for things like averaging, smoothing, checking bounds on the values. One of the arguments for doing that in userspace is that of avoiding every touchscreen driver redoing the same averaging and/or limit checking code. I agree thought that it may be better to sacrifice that for performance. If everyone's doing the same thing, move it to drivers/input/, not to userspace. Why should we be forced to have _two_ drivers and essentially maintain a stable kernel/userspace ABI between them? Surely it's better to only have _one_ hardware-specific driver, rather than half in the kernel, and half hidden behind an abstraction layer that is meant to let you just deal with input events without knowing stupid details about the hardware? I don't see any coherent argument for it being in tslib. Cheers, Daniel signature.asc Description: Digital signature
