[Gta04-owner] Linux 3.7 for gta04.

[Dr. H. Nikolaus Schaller]

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

> 
> 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.

> 
>> 
>>> 
>>> 3/ touching display wakes it from suspend (this was already in some older 3.5 
>>> version)
>> 
>> Thanks for noting that - it shouldn't be hard to work out why and find a way
>> to turn in on/off.
> 
> Exactly the same bug as in 3.5.  Exactly the same patch fixed it.
> Maintainer said they had accepted the patch, but it didn't make it to Linus
> yet :-(
> 
> 
>> 
>>> 
>>> 4/ power management - i can see ~20mA in suspend, i even saw 18mA once. So 
>>> it's not worse and maybe improved against 3.5!
>> 
>> That's good.  I'm getting terrible power usage at the moment and don't really
>> know why.  Maybe I'm leaving something on which I shouldn't.  Glad to know it
>> isn't a core kernel problem.
>> 
>>> 
>>> 5/ no audio in calls, maybe some controls have changed:
>>> 
>>> root at neo:~# alsactl -f /opt/qtmoko/etc/alsa/gsmearpiece.state restore
>>> alsactl: set_control:1255: failed to obtain info for control #21 (No such file 
>>> or directory)
>> 
>> Is this that GTA04a4?  I don't think I have the patch to support
>> hardware-routing in there.  Software routing works for me.
>> 
>> I should look at the hardware-routing patch.  I seem to recall there was
>> something about the design that I thought could be improved - but never got
>> further.
>> 
> 
> I haven't looked at this yet but hope to soon.
> Meanwhile an "omap-twl4030.c" has appeared which might mean we can get rid of
> gta04-audio.c.  I'll look into that too.
> 
> All the fixes mentioned above have been merged into my 'mainline' branch.
> I've also got the PWM driver (which drives the backlight) nearly ready of
> acceptance upstream (the relevant upstream developers have been very helpful).
> 
> I'm now using 3.7 for day-to-day use (and have been doing so for at least 2
> whole hours!).

++

Nikolaus