[meta-intel] Next Gen Intel BSPs (GMA600 on TunnelCreek)

[Patrik Jakobsson]

On Wed, Mar 5, 2014 at 6:27 AM, Tom Zanussi <tom.zanussi at intel.com> wrote:
> On Tue, 2014-03-04 at 21:09 -0800, Darren Hart wrote:
>> On 3/4/14, 18:25, "Tom Zanussi" <tom.zanussi at intel.com> wrote:
>>
>> >On Tue, 2014-03-04 at 16:08 -0800, Darren Hart wrote:
>> >> On 2/25/14, 12:36, "Patrik Jakobsson" <patrik.r.jakobsson at gmail.com>
>> >>wrote:
>> >>
>> >> >On Tue, Feb 25, 2014 at 9:07 PM, Scott Garman
>> >><scott.a.garman at intel.com>
>> >> >wrote:
>> >> >> On 02/25/2014 08:32 PM, Tom Zanussi wrote:
>> >> >>>
>> >> >>> On Tue, 2014-02-25 at 15:26 +0100, Scott Garman wrote:
>> >> >>>>
>> >> >>>> On 02/25/2014 03:20 PM, Hart, Darren wrote:
>> >> >>>>>
>> >> >>>>> Scott, question for you below...
>> >> >>>>
>> >> >>>>
>> >> >>>> <snip>
>> >> >>>>
>> >> >>>>>>>> So the problem here is some kind of interference with the
>> >> >>>>>>>
>> >> >>>>>>> CONFIG_GMA600,
>> >> >>>>>>>>
>> >> >>>>>>>> which is now turned on by default - I'll have to either dig
>> >>into
>> >> >>>>>>>>find
>> >> >>>>>>>> the actual problem or just turn it off for _crownbay-noegd...
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> Oh... Hrm... We should actually be able to use that driver now
>> >>on
>> >> >>>>>>>the
>> >> >>>>>>> Tunnel Creek systems as of 3.10-LTSI and 3.13+. Scott Garman
>> >> >>>>>>>tested it
>> >> >>>>>>> on
>> >> >>>>>>> the MinnowBoard, I haven't done so myself unfortunately. Do we
>> >> >>>>>>>specify
>> >> >>>>>>> another driver in the xorg.conf or something that is causing
>> >>some
>> >> >>>>>>> confusion about which driver to use?
>> >> >>>>>>>
>> >> >>>>>>
>> >> >>>>>> No, there's no special xorg.conf for crownbay-noemgd...
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> Scott, did you have to do something special to get the gma600
>> >>driver
>> >> >>>>> working on the MinnowBoard? Did it require you to write an
>> >>xorg.conf?
>> >> >>>>
>> >> >>>>
>> >> >>>> Yes, you need to include the xf86-modesetting driver and set the
>> >> >>>> following in your xorg.conf:
>> >> >>>>
>> >> >>>> Section "Device"
>> >> >>>>           Identifier      "gma500"
>> >> >>>>           Driver                "modesetting"
>> >> >>>> EndSection
>> >> >>>>
>> >> >>>> Section "Screen"
>> >> >>>>           Identifier      "gma500 Screen"
>> >> >>>>           Device          "gma500"
>> >> >>>> EndSection
>> >> >>>>
>> >> >>>> I think that should be all you need. Let me know if you run into
>> >> >>>> problems with that.
>> >> >>>>
>> >> >>>
>> >> >>> That's a little better but still getting:
>> >> >>>
>> >> >>> [1782396.836] (==) AIGLX enabled
>> >> >>> [1782396.836] Loading extension GLX
>> >> >>> [1782396.836] (II) LoadModule: "modesetting"
>> >> >>> [1782396.845] (II) Loading
>> >> >>> /usr/lib/xorg/modules/drivers/modesetting_drv.so
>> >> >>> [1782396.850] (II) Module modesetting: vendor="X.Org Foundation"
>> >> >>> [1782396.851]   compiled for 1.15.0, module version = 0.8.1
>> >> >>> [1782396.851]   Module class: X.Org Video Driver
>> >> >>> [1782396.851]   ABI class: X.Org Video Driver, version 15.0
>> >> >>> [1782396.851] (II) modesetting: Driver for Modesetting Kernel
>> >>Drivers:
>> >> >>>kms
>> >> >>> [1782396.851] (--) using VT number 3
>> >> >>>
>> >> >>> [1782397.299] (WW) Falling back to old probe method for modesetting
>> >> >>> [1782397.380] (EE) Screen 0 deleted because of no matching config
>> >> >>>section.
>> >> >>> [1782397.380] (II) UnloadModule: "modesetting"
>> >> >>> [1782397.380] (EE) Device(s) detected, but none match those in the
>> >> >>>config
>> >> >>> file.
>> >> >>> [1782397.380] (EE)
>> >> >>> Fatal server error:
>> >> >>> [1782397.380] (EE) no screens found(EE)
>> >> >>
>> >> >>
>> >> >> Hmmm...I'm not sure what to suggest. I'd like to re-create the setup
>> >> >>but I
>> >> >> can't do it out here. I've added Patrik Jakobsson to the cc: list -
>> >>he
>> >> >>might
>> >> >> have some suggestions.
>> >> >>
>> >> >> Scott
>> >> >
>> >> >Hi all,
>> >> >
>> >> >Does the gma500_gfx driver detect the output and the modes properly?
>> >> >Can you send a dmesg with drm.debug=0xfe
>> >>
>> >>
>> >> Has anyone had a chance to try this? If not, I can give it a shot
>> >>probably
>> >> next week.
>> >>
>> >
>> >Yeah, I tried this and sent the output to Patrik - basically the driver
>> >doesn't support LVDS yet, which is what I have...
>> >
>> >Basically it doesn't make sense to have a BSP default to something that
>> >doesn't work out of the box for reasonable hardware...
>>
>> Yes, agreed. I will work to document this in meta-intel so others can
>> choose to use it if they would like. Patrik did a lot of work for us on
>> this in support of the Minnowboard "pro-bono", so I want to make sure we
>> make use of his work. For now, that will have to be documentation.
>>
>
> Yes, it's definitely appreciated, and it will be nice to make it the
> default eventually..
>
> Tom

Hi Tom,

Did you get it working by specifying a mode as a kernel boot
parameter? I think the default way of giving the LVDS modes to the
driver has been to insert them into the VBIOS with a special BIOS
utility (Windows only). And if that failed we did a fallback to a mode
common to most LVDS panels. I believe this is what EMGD is doing as
well. I removed the fallback in gma500_gfx so it didn't get in the way
of SDVO on the Minnowboard but perhaps I can add it back if we detect
that no SDVO chip is available at all.

Cheers
Patrik