[Gta04-owner] Linux 3.7 for gta04.

NeilBrown neilb at suse.de
Sat Dec 15 11:51:53 CET 2012 

On Sat, 15 Dec 2012 09:11:53 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

> 
> Am 15.12.2012 um 05:30 schrieb NeilBrown:
> 
> > On Wed, 12 Dec 2012 06:29:50 +1100 NeilBrown <neilb at suse.de> wrote:
> > 
> >> On Tue, 11 Dec 2012 18:56:04 +0100 Radek Polak <psonek2 at seznam.cz> wrote:
> >> 
> >>> On Tuesday, December 11, 2012 05:52:17 AM NeilBrown wrote:
> >>> 
> >>>> Bug reports, success report, patches etc etc always welcome.
> >>> 
> >>> Hi Neil,
> >>> i have compiled it and got it running for first few minutes now. Here is what 
> >>> i have noticed until now:
> >>> 
> >>> 1/ battery charging: for a few first minutes it worked fine. I have unplugged 
> >>> it and tried a few suspend/resume. Then it showed "Discharging" even when on 
> >>> USB. After reboot it charges again.
> >> 
> >> Thanks for the confirmation.  I had a quick look at the 'git log' of the
> >> relevant files and didn't see anything obvious.  When I get a chance I add
> >> some debugging and see what is happening.
> > 
> > Someone broke the notification from the USB driver to the charger driver so
> > that the charger doesn't know when the USB gets plugged in so it doesn't know
> > to turn on charging.
> > 
> > commit c9721438c009adf8e81d376839ed037c53b9b8d9 causes the breakage.
> > I've sent a suggested fix.
> > In any case, it works now.
> > 
> >> 
> >>> 
> >>> 2/ strange greenish colors. Maybe it has to do something with:
> >>> 
> >>> omapdss DPI: Could not find exact pixel clock. Requested 22000 kHz, got 22153 
> >>> kHz
> >> 
> >> Again - thanks for confirming :-)  I thought I noticed that too but wasn't
> >> really sure and forgot to mention it.
> >> The earlier kernel show that same message so I don't think it is directly
> >> related.  There were a number of changes in the DPI code which I didn't
> >> understand, so I just copied the corresponding changes from other panel
> >> devices.  I guess I need to look at those more carefully.
> > 
> > I looked but I could find anything.
> > 
> > The only relevant change seems to be that we remove things like:
> > 
> > -       dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_ONOFF | OMAP_DSS_LCD_IPC | OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
> > 
> > 
> > with equally meaningful things like:
> > 
> > +
> > +.vsync_level   = OMAPDSS_SIG_ACTIVE_LOW,
> > +.hsync_level   = OMAPDSS_SIG_ACTIVE_LOW,
> > +
> > +.data_pclk_edge        = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
> > +.de_level      = OMAPDSS_SIG_ACTIVE_HIGH,
> > +.sync_pclk_edge        = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
> > 
> > to 
> > 
> > static struct omap_video_timings td028ttec1_panel_timings = {
> > 
> > Maybe I've messed up the conversion, but I have little idea what any of them
> > mean and just tried to copy from similar drivers.
> > 
> > But maybe the problem is something else altogether.
> 
> Wrong settings here can make the data transmission from the DSS to the display
> instable - depending on the specific parameters of the display module.
> 
> > -       dssdev->panel.config = OMAP_DSS_LCD_TFT | OMAP_DSS_LCD_ONOFF | OMAP_DSS_LCD_IPC | OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
> 
> These bits control bits 12..17 of the OMAP DISPC_POL_FREQ registers [1]:
> 
> OMAP_DSS_LCD_ONOFF:	1: HSYNC and VSYNC are driven according to bit 16 (OMAP_DSS_LCD_RF ) which is 0, i.e. HSYNC and VSYNC are driven on falling edge of pixel clock
> OMAP_DSS_LCD_IPC:		1: Data is driven on the LCD data lines on the falling-edge of the pixel clock
> OMAP_DSS_LCD_IVS:		1: Frame clock (HSYNC) pin is active low and inactive high
> OMAP_DSS_LCD_IHS:		1: Line clock (VSYNC) pin is active low and inactive high
> 
> OMAP_DSS_LCD_TFT:		has influence deep in the guts of the DSS drivers - if not set, it is assumed to be a STN display
> 
> not set are:
> 
> OMAP_DSS_LCD_IEO:		0: Invert output enable: Ac-bias is active high (active display mode)
> OMAP_DSS_LCD_RF:		0: HSYNC and VSYNC are driven on falling edge of pixel clock (if bit 17 set to 1)
> 
> [1]: https://github.com/goldelico/gta04-kernel/blob/hw-validation/arch/arm/plat-omap/include/plat/display.h
> 
> > +.vsync_level   = OMAPDSS_SIG_ACTIVE_LOW,
> > +.hsync_level   = OMAPDSS_SIG_ACTIVE_LOW,
> both appear to be ok (IVS/IHS set)
> > +
> > +.data_pclk_edge        = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
> appears to be ok (IPC set)
> > +.de_level      = OMAPDSS_SIG_ACTIVE_HIGH,
> 
> appears to be ok (OMAP_DSS_LCD_IEO no set).
> 
> > +.sync_pclk_edge        = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
> 
> 
> this is questionable. It appears to represent a missing OMAP_DSS_LCD_ONOFF.
> 
> So I suggest to experiment a little with the values [2].
> 
> [2]: http://lxr.free-electrons.com/source/include/video/omapdss.h

I did try fiddling with some values and they had no effect on the colour at
all.

So I decided to do a git-bisect (when I should have been writing Christmas
cards!!).

The offending commit is 

commit 195e672a76056478cc79f5c48343164c9237852e
Author: Chandrabhanu Mahapatra <cmahapatra at ti.com>
Date:   Wed Aug 22 11:44:06 2012 +0530

    OMAPDSS: DPI: Remove cpu_is_xxxx checks


which looks obviously correct, unless you happen to have recently looked at 

commit f65e384bec59ef35dfa77455181af2ecf7a7ef44
Author: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
Date:   Thu Oct 25 20:42:10 2012 +0200

    omapdss: dss: Fix clocks on OMAP363x


which contains

        if (cpu_is_omap24xx())
                src = &omap24xx_dss_feats;
-       else if (cpu_is_omap34xx())
-               src = &omap34xx_dss_feats;
        else if (cpu_is_omap3630())
                src = &omap3630_dss_feats;
+       else if (cpu_is_omap34xx())
+               src = &omap34xx_dss_feats;
        else if (cpu_is_omap44xx())
                src = &omap44xx_dss_feats;
        else if (soc_is_omap54xx())


which makes it clear that cpu_is_omap3630() and cpu_is_omap34xx()
are not mutually exclusive and that the former implies the latter.

On the GTA04 cpu_is_3630 and cpu_is_34xx are both true.

So the fix is simple:

diff --git a/drivers/video/omap2/dss/dss_features.c b/drivers/video/omap2/dss/dss_features.c
index acbc1e1..aaf3c3f 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -546,6 +546,7 @@ static const enum dss_feat_id omap3630_dss_feat_list[] = {
        FEAT_ALPHA_FIXED_ZORDER,
        FEAT_FIFO_MERGE,
        FEAT_OMAP3_DSI_FIFO_BUG,
+       FEAT_DPI_USES_VDDS_DSI,
 };
 
 static const enum dss_feat_id omap4430_es1_0_dss_feat_list[] = {


and applying that to my 'mainline' kernel makes the green go away.


> 
> > 
> > While I was there I made this change
> > 
> > -.pixel_clock   = 22000,
> > +.pixel_clock   = 22153,
> > 
> > to avoid the warning.
> 
> this is still within spec (allows 22-25 MHz - higher frequencies are creating more noise and may draw some more uA).
> If possible we should avoid 25 MHz because it may interfere with GPS reception.
> 

Good to know, thanks.

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20121215/530b961a/attachment.bin>

More information about the Gta04-owner mailing list