Yep.. I am still trying to pin this one down as it only happens with some devices and combinations. They seem to try and set twice the correct rate.

Does it behave if you force the mode on the boot command line ?

Also what system and what displays is it plugged into.

Thanks
Alan

Created attachment 63232 [details]
Photo of the problem

This is a photo of the problem. It's only a snapshot though, the image on screen isn't static because of the refresh rate or clock problem.

I checked on windows, and the native display resolution is indeed 1280x800. Passing video=1280x800 on the command line doesn't help.

The system is a netbook form-factor with the screen plugged as LVDS.

I'm not sure what you meant by "what system". It's a netbook with a D2500. So the graphics controller is logically:

00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller [8086:0be1] (rev 09)

Do you need more information ?

Created attachment 63233 [details] [review]
Patch for resetting dpll_md on lvds output

This is a real shot from the hip, but at a quick glance that dpll_md stuff looks wrong.

Try the patch I just attached.

I can't see any change with this patch applied.

Created attachment 63288 [details]
dmesg on N2800

I'm having the same problem on an N2800-based netbook with a 1366x768 display. This is the dmesg.

Nore you can force the refresh rate on the command line as well as the mode, which might be a useful experimental check

I tried passing video=1280x800@x where x varied between 40 and 100, and nothing changed on the D2500 hardware.

Created attachment 63520 [details] [review]
Patch to use SSC clock (proof of concept)

It seems the BIOS is lying to us… telling us not use the SSC external clock (100Mhz), while we should.
The attached patche makes the display work properly on both the N2800 and D2800 hardware.

It seems the patch I posted is wrong: lvds_ssc_freq should be 100, not 100000. The only side effect of this patch is to use a different refclk (100000 instead of 96000), which then gives better PLL calculation results, making the display work.

Looking at the reference kernel driver code it uses 96000 on the low end device (dplla_96mhz) and on the high end one uses 27, but uses 100 on pipeb in the presence of dp/edp (which isn't yet in the fully free driver)

I don't see any other deviations. We set up lvds_use_ssc from general-.>enable_ssc and we set dev_priv->lvds_ssc_freq from general->ssc_freq the same. We parse the bits the same way so I'm a bit baffled as to what is going on unless as you say the BIOS is lying (which would translate I think to 'windows is doing it differenmtly')

Can you check what lvds_use_ssc, and dplla_96mhz are reporting on your device.

What also bothers me is the code says /* 96/100mhz */ but there isn't anything deciding which of the two.

I wonder if we should actually be doing

  refclk = 96000;
  if(pipe == 1)
     refclk= 100000;

I'm not sure what you call the reference driver, but neither the driver integrated in MeeGo 1.2, nor the latest release integrated in this ubuntu ppa launchpad.net/~sarvatt/+archive/cedarview (using code from this dump: http://kernel.ubuntu.com/~sarvatt/cdv/drops/ ) succeed in setting the proper clock parameters.
I can only guess that they have the same bug, and your internal reference driver might also be buggy.


dplla_96mhz is 0 and lvds_use_ssc is 0.

If I set reflck = 96000, the display works correctly.
So it means that I was wrong, and that the refclk at 96MHz is indeed working. It's at 27MHz that it fails.

Sounds like it is misreporting the device version. Oh joy.

Can you get me the output of dmidecode and lspci -vvxxx and I'll add a hack for the moment, plus if the PPA driver version also fails I'll make sure the folks working on that know, so they can try and acquire and check whichever exact netbook you have.

Alan

Could it be that we mis-interpret the meaning of primary_lfp_id ? Which then sets dplla_96mhz to the wrong value ? (and not lvds_use_ssc as I first thought)

Created attachment 63573 [details]
lspci -vvxxx of D2800 netbook

Created attachment 63575 [details]
dmidecode of D2800 netbook

Created attachment 63801 [details]
Patch to fix the problem ?

Here is patch to test a new approach that could work. Commit message:

    gma500: fix display clock selection on some cdv devices

    Some ODM-made CDV netbooks exhibit modesetting problems, the display
    clock isn't set at a proper rate.

    The problem seems to be that the code chooses a refclk at 27 MHz, while
    it should be at 96MHz (or 100 with an SSC). Setting to 96 MHz or 100 MHz
    both work.

    We can see that the variable is named dplla_96MHz; but pipe is set to 1,
    which means we use DPLLB.
    Also, on the datasheet "Intel® Atom™ Processor D2000 and N2000 Series,
    Vol. 1", Doc ID 326136-002, Table 4-28, we can see that DPLL0 is for
    frequency 27, 96, and 100, non SSC. While DPLL1 is for 100 SSC. Of
    course, it also states that DPLL0 and DPLL1 can use each other's
    reference clock internally, but we'll ignore that for the purpose of
    this patch.

    The conclusion is that if we're using pipe B, we'll set the clock to
    96MHz, which we have tested to be identical to 100 MHz SSC. This should
    solve the problem in case the BIOS "forgot" to tell us to use SSC.

After testing a fedora 17 install image, I was surprised that display was setup properly. It was working with kernel 3.3. I soon tested a vanilla kernel and started bisecting, and found that the regression was introduced by:

acd7ef927e06510fbfeec8d307f4726a156b2733 is the first bad commit
commit acd7ef927e06510fbfeec8d307f4726a156b2733
Author: Alan Cox <alan@linux.intel.com>
Date:   Wed Apr 25 14:36:48 2012 +0100

    gma500: Update the Cedarview clock handling

    Signed-off-by: Dave Airlie <airlied@redhat.com>


This is a pretty big patch regarding clock handling. I think my patch on top could help. Adding Dave in copy of this bug to ask what he thinks.

String 1: This is the Intel CedarTrail CRB Platform

So this doesn't appear to be a production board ?

(note if there are elements of that question that get you into Intel NDA's or something you can also drop me an email as alan@linux.intel.com)

I was told it is a production version. Some ODMs/OEMs often "forget" to update the DMI strings, even on production hardware.
Don't forget that it works on windows, so the windows driver must be doing things differently.

Regarding the regression, I saw that Dave's patch was mostly a sync with the "reference" driver. It seems to have with the same issue, and my patch fixes the issue on Ubuntu.

I just received another netbook (different hardware, N2600-based) and it works on it without problem. So there might indeed be something different on this netbook. I don't know what yet.

(In reply to comment #21)
> I just received another netbook (different hardware, N2600-based) and it works
> on it without problem. So there might indeed be something different on this
> netbook. I don't know what yet.

It's simply that the BIOS declares enable_ssc = 1, which make us use SSC; it's also on pipe B. I could change the patch to do if pipe == B then use_SSC.

I moved on to another cedarview hardware, not having this bug. I think we can classify this as a BIOS bug and not care anymore.