Hi,
I am working with a custom/embedded device, which has the following device:
00:02.0 VGA compatible controller [0300]: Intel Corporation Atom
Processor E6xx Integrated Graphics Controller [8086:4108] (rev 05)
(prog-if 00 [VGA controller])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d0000000 (32-bit, non-prefetchable) [size=1M]
Region 1: I/O ports at f010 [size=8]
Region 2: Memory at c0000000 (32-bit, non-prefetchable) [size=256M]
Region 3: Memory at d04c0000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at <unassigned> [disabled]
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] Vendor Specific Information: Len=07 <?>
Kernel driver in use: gma500
Kernel modules: gma500_gfx
At the moment (kernel 3.2.20) I am using this device with the vesa
driver, but I tested 3.5-rc2+ on the
device with the gma500 driver.
[ 7.885054] gma500 0000:00:02.0: setting latency timer to 64
[ 7.885395] [drm:psb_intel_opregion_setup], Public ACPI methods supported
[ 7.885408] [drm:psb_intel_opregion_setup], ASLE supported
[ 7.885435] gma500 0000:00:02.0: Enabling MSI failed!
[ 7.885542] [drm] internal display is MIPI display
[ 7.885658] ioremap error for 0x3ddbd000-0x3ddbe000, requested 0x10, got 0x0
[ 7.885759] gma500 0000:00:02.0: Unable to read GCT!
[ 7.895613] hub 6-0:1.0: USB hub found
[ 7.895897] hub 6-0:1.0: 1 port detected
[ 7.896700] ohci_hcd 0000:02:08.1: setting latency timer to 64
[ 7.896721] ohci_hcd 0000:02:08.1: OHCI Host Controller
[ 7.896837] ohci_hcd 0000:02:08.1: new USB bus registered, assigned
bus number 7
[ 7.897221] ohci_hcd 0000:02:08.1: irq 16, io mem 0xd014e000
[ 7.914951] gma500 0000:00:02.0: VBT signature missing
[ 7.918090] usb 1-1: new high-speed USB device number 2 using ehci_hcd
[ 7.952691] hub 7-0:1.0: USB hub found
[ 7.952805] hub 7-0:1.0: 1 port detected
[ 7.953218] ohci_hcd 0000:02:08.2: setting latency timer to 64
[ 7.953238] ohci_hcd 0000:02:08.2: OHCI Host Controller
[ 7.953358] ohci_hcd 0000:02:08.2: new USB bus registered, assigned
bus number 8
[ 7.953520] ohci_hcd 0000:02:08.2: irq 16, io mem 0xd014d000
[ 8.008855] hub 8-0:1.0: USB hub found
[ 8.008969] hub 8-0:1.0: 1 port detected
[ 8.033279] hub 1-1:1.0: USB hub found
[ 8.033503] hub 1-1:1.0: 3 ports detected
[ 8.063001] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 8.063127] [drm] No driver support for vblank timestamp query.
[ 8.063369] gma500 0000:00:02.0: DSI is not supported
[ 8.113473] No connectors reported connected with modes
[ 8.113575] [drm:drm_setup_crtcs],
[ 8.113591] [drm:drm_setup_crtcs], picking CRTCs for 2048x2048 config
[ 8.113601] [drm] Cannot find any crtc or sizes - going 1024x768
[ 8.125973] fbcon: psbfb (fb0) is primary device
[ 8.127827] [drm:drm_crtc_helper_set_config],
[ 8.127835] [drm:drm_crtc_helper_set_config], [CRTC:3] [NOFB]
[ 8.168231] [drm:drm_crtc_helper_set_config],
[ 8.168238] [drm:drm_crtc_helper_set_config], [CRTC:4] [NOFB]
[ 8.231312] Console: switching to colour frame buffer device 128x48
[ 8.257610] fb0: psbfb frame buffer device
[ 8.257807] drm: registered panic notifier
[ 8.258049] [drm] Initialized gma500 1.0.0 2011-06-06 for
0000:00:02.0 on minor 0
[ 8.353090] usb 6-1: new full-speed USB device number 2 using ohci_hcd
[ 8.526496] usbcore: registered new interface driver usbhid
[ 8.526757] usbhid: USB HID core driver
[ 8.536574] input: DIALOGUE INC PenMount USB as
/devices/pci0000:00/0000:00:17.0/0000:01:00.0/0000:02:08.0/usb6/6-1/6-1:1.0/input/input0
[ 8.537561] hid-generic 0003:14E1:6000.0001: input: USB HID v1.01
Mouse [DIALOGUE INC PenMount USB] on usb-0000:02:08.0-1/input0
[ 8.770647] EXT3-fs (sda2): using internal journal
[ 9.043119] kjournald starting. Commit interval 5 seconds
An run into this problem - there may be some more:
Cannot find any crtc or sizes - going 1024x768
Depending on the connected display, there are two ways the panel is connected.
1) up to WVGA - LVDS
2) else SDVO
There is no EDID available.. it is only possible to read out the
defined display resolution
via an at24 eeprom found on the i2c bus of the device.
I tried my luck with following xorg.conf
Section "Monitor"
Identifier "OT display"
EndSection
Section "Device"
Identifier "OT graphic card"
Driver "fbdev"
EndSection
Section "Screen"
Identifier "OT screen"
Device "OT graphic card"
Monitor "OT display"
DefaultDepth 16
SubSection "Display"
Depth 16
Modes "640x480"
EndSubSection
EndSection
Section "ServerLayout"
Identifier "Base layout"
Screen "OT screen"
EndSection
Section "InputClass"
Identifier "keyboard layout"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "XkbLayout" "us"
EndSection
Section "ServerFlags"
Option "Xinerama" "Off"
EndSection
(**) FBDEV(0): claimed PCI slot 0@0:2:0
(II) FBDEV(0): using default device
(WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
(**) FBDEV(0): Depth 16, (--) framebuffer bpp 16
(==) FBDEV(0): RGB weight 565
(==) FBDEV(0): Default visual is TrueColor
(==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0)
(II) FBDEV(0): hardware: psbfb (video memory: 3072kB)
(II) FBDEV(0): checking modes against framebuffer device...
(EE) FBDEV(0): FBIOPUT_VSCREENINFO: Invalid argument
(II) FBDEV(0): mode "640x480" test failed
(II) FBDEV(0): checking modes against monitor...
(--) FBDEV(0): Virtual size is 1024x768 (pitch 1024)
(**) FBDEV(0): Built-in mode "current"
(==) FBDEV(0): DPI set to (96, 96)
(II) Loading sub module "fb"
So... what options do I have to fix my problems?
thanks
---
Christian Gmeiner, MSc
On Mon, Jun 11, 2012 at 4:16 PM, Christian Gmeiner
<[email protected]> wrote:
> Hi,
>
> I am working with a custom/embedded device, which has the following device:
>
-- Snip ---
>
> At the moment (kernel 3.2.20) I am using this device with the vesa
> driver, but I tested 3.5-rc2+ on the
> device with the gma500 driver.
>
>
> [ ? ?7.885054] gma500 0000:00:02.0: setting latency timer to 64
> [ ? ?7.885395] [drm:psb_intel_opregion_setup], Public ACPI methods supported
> [ ? ?7.885408] [drm:psb_intel_opregion_setup], ASLE supported
> [ ? ?7.885435] gma500 0000:00:02.0: Enabling MSI failed!
> [ ? ?7.885542] [drm] internal display is MIPI display
> [ ? ?7.885658] ioremap error for 0x3ddbd000-0x3ddbe000, requested 0x10, got 0x0
> [ ? ?7.885759] gma500 0000:00:02.0: Unable to read GCT!
--- Snip ---
> [ ? ?7.914951] gma500 0000:00:02.0: VBT signature missing
--- Snip ---
> [ ? ?8.063001] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [ ? ?8.063127] [drm] No driver support for vblank timestamp query.
> [ ? ?8.063369] gma500 0000:00:02.0: DSI is not supported
Indicates that oaktrail_lvds_init() is skipped
> [ ? ?8.113473] No connectors reported connected with modes
> [ ? ?8.113575] [drm:drm_setup_crtcs],
> [ ? ?8.113591] [drm:drm_setup_crtcs], picking CRTCs for 2048x2048 config
> [ ? ?8.113601] [drm] Cannot find any crtc or sizes - going 1024x768
> [ ? ?8.125973] fbcon: psbfb (fb0) is primary device
> [ ? ?8.127827] [drm:drm_crtc_helper_set_config],
> [ ? ?8.127835] [drm:drm_crtc_helper_set_config], [CRTC:3] [NOFB]
> [ ? ?8.168231] [drm:drm_crtc_helper_set_config],
> [ ? ?8.168238] [drm:drm_crtc_helper_set_config], [CRTC:4] [NOFB]
> [ ? ?8.231312] Console: switching to colour frame buffer device 128x48
> [ ? ?8.257610] fb0: psbfb frame buffer device
> [ ? ?8.257807] drm: registered panic notifier
> [ ? ?8.258049] [drm] Initialized gma500 1.0.0 2011-06-06 for
> 0000:00:02.0 on minor 0
--- Snip ---
> An run into this problem - there may be some more:
> Cannot find any crtc or sizes - going 1024x768
>
> Depending on the connected display, there are two ways the panel is connected.
>
> 1) up to WVGA - LVDS
> 2) else SDVO
>
> There is no EDID available.. it is only possible to read out the
> defined display resolution
> via an at24 eeprom found on the i2c bus of the device.
--- Snip ---
> So... what options do I have to fix my problems?
Your device seems to lack the pieces needed for auto-detection of the outputs.
I'd start by forcing oaktrail_lvds_init to run. Look at the first function in
oaktrail_device.c. You'll find that a fuse value is required and that you don't
have it.
We have no SDVO support for Oaktrail and I've never seen any hardware
that does LVDS over SDVO (though there is support for that on Poulsbo).
-Patrik
Hi Patrik
2012/6/12 Patrik Jakobsson <[email protected]>:
> On Mon, Jun 11, 2012 at 4:16 PM, Christian Gmeiner
> <[email protected]> wrote:
>> Hi,
>>
>> I am working with a custom/embedded device, which has the following device:
>>
> -- Snip ---
>>
>> At the moment (kernel 3.2.20) I am using this device with the vesa
>> driver, but I tested 3.5-rc2+ on the
>> device with the gma500 driver.
>>
>>
>> [ 7.885054] gma500 0000:00:02.0: setting latency timer to 64
>> [ 7.885395] [drm:psb_intel_opregion_setup], Public ACPI methods supported
>> [ 7.885408] [drm:psb_intel_opregion_setup], ASLE supported
>> [ 7.885435] gma500 0000:00:02.0: Enabling MSI failed!
>> [ 7.885542] [drm] internal display is MIPI display
>> [ 7.885658] ioremap error for 0x3ddbd000-0x3ddbe000, requested 0x10, got 0x0
>> [ 7.885759] gma500 0000:00:02.0: Unable to read GCT!
> --- Snip ---
>> [ 7.914951] gma500 0000:00:02.0: VBT signature missing
> --- Snip ---
>> [ 8.063001] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>> [ 8.063127] [drm] No driver support for vblank timestamp query.
>> [ 8.063369] gma500 0000:00:02.0: DSI is not supported
> Indicates that oaktrail_lvds_init() is skipped
>
>> [ 8.113473] No connectors reported connected with modes
>> [ 8.113575] [drm:drm_setup_crtcs],
>> [ 8.113591] [drm:drm_setup_crtcs], picking CRTCs for 2048x2048 config
>> [ 8.113601] [drm] Cannot find any crtc or sizes - going 1024x768
>> [ 8.125973] fbcon: psbfb (fb0) is primary device
>> [ 8.127827] [drm:drm_crtc_helper_set_config],
>> [ 8.127835] [drm:drm_crtc_helper_set_config], [CRTC:3] [NOFB]
>> [ 8.168231] [drm:drm_crtc_helper_set_config],
>> [ 8.168238] [drm:drm_crtc_helper_set_config], [CRTC:4] [NOFB]
>> [ 8.231312] Console: switching to colour frame buffer device 128x48
>> [ 8.257610] fb0: psbfb frame buffer device
>> [ 8.257807] drm: registered panic notifier
>> [ 8.258049] [drm] Initialized gma500 1.0.0 2011-06-06 for
>> 0000:00:02.0 on minor 0
> --- Snip ---
>> An run into this problem - there may be some more:
>> Cannot find any crtc or sizes - going 1024x768
>>
>> Depending on the connected display, there are two ways the panel is connected.
>>
>> 1) up to WVGA - LVDS
>> 2) else SDVO
>>
>> There is no EDID available.. it is only possible to read out the
>> defined display resolution
>> via an at24 eeprom found on the i2c bus of the device.
> --- Snip ---
>> So... what options do I have to fix my problems?
>
> Your device seems to lack the pieces needed for auto-detection of the outputs.
>
> I'd start by forcing oaktrail_lvds_init to run. Look at the first function in
> oaktrail_device.c. You'll find that a fuse value is required and that you don't
> have it.
>
Got a little bit further:
diff --git a/drivers/gpu/drm/gma500/mid_bios.c
b/drivers/gpu/drm/gma500/mid_bios.c
index b2a790b..9ee3122 100644
--- a/drivers/gpu/drm/gma500/mid_bios.c
+++ b/drivers/gpu/drm/gma500/mid_bios.c
@@ -55,8 +55,12 @@ static void mid_get_fuse_settings(struct drm_device *dev)
pci_read_config_dword(pci_root, 0xD4, &fuse_value);
/* FB_MIPI_DISABLE doesn't mean LVDS on with Medfield */
+#if 0
if (IS_MRST(dev))
dev_priv->iLVDS_enable = fuse_value & FB_MIPI_DISABLE;
+#else
+ dev_priv->iLVDS_enable = 1;
+#endif
DRM_INFO("internal display is %s\n",
dev_priv->iLVDS_enable ? "LVDS display" : "MIPI display");
diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
b/drivers/gpu/drm/gma500/psb_intel_lvds.c
index c83f5b5..5b49522 100644
--- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
@@ -530,11 +530,14 @@ static int psb_intel_lvds_get_modes(struct
drm_connector *connector)
struct psb_intel_lvds_priv *lvds_priv = psb_intel_encoder->dev_priv;
int ret = 0;
+ printk(KERN_INFO "test 1\n");
+#if 0
if (!IS_MRST(dev))
ret = psb_intel_ddc_get_modes(connector,
&lvds_priv->i2c_bus->adapter);
if (ret)
return ret;
+#endif
/* Didn't get an EDID, so
* Set wide sync ranges so we get all modes
[ 8.233858] [drm:drm_helper_probe_single_connector_modes],
[CONNECTOR:7:LVDS-1]
[ 8.233869] test 1
[ 8.233967] [drm:drm_helper_probe_single_connector_modes],
[CONNECTOR:7:LVDS-1] probed modes :
[ 8.233993] [drm:drm_mode_debug_printmodeline], Modeline
10:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
[ 8.234038] [drm:drm_setup_crtcs],
[ 8.234053] [drm:drm_enable_connectors], connector 7 enabled? yes
[ 8.234066] [drm:drm_target_preferred], looking for cmdline mode on
connector 7
[ 8.234077] [drm:drm_target_preferred], looking for preferred mode
on connector 7
[ 8.234088] [drm:drm_target_preferred], found mode 1024x600
[ 8.234101] [drm:drm_setup_crtcs], picking CRTCs for 2048x2048 config
[ 8.234116] [drm:drm_setup_crtcs], desired mode 1024x600 set on crtc 3
[ 8.242199] fbcon: psbfb (fb0) is primary device
[ 8.244065] [drm:drm_crtc_helper_set_config],
[ 8.244076] [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:12]
#connectors=1 (x y) (0 0)
[ 8.244099] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set
[ 8.244106] [drm:drm_crtc_helper_set_config], modes are different,
full mode set
[ 8.244120] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0
0 0 0 0 0 0 0 0x0 0x0
[ 8.244138] [drm:drm_mode_debug_printmodeline], Modeline
11:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
[ 8.244145] [drm:drm_crtc_helper_set_config], encoder changed, full
mode switch
[ 8.244151] [drm:drm_crtc_helper_set_config], crtc changed, full mode switch
[ 8.244161] [drm:drm_crtc_helper_set_config], [CONNECTOR:7:LVDS-1]
to [CRTC:3]
[ 8.244168] [drm:drm_crtc_helper_set_config], attempting to set
mode from userspace
[ 8.244184] [drm:drm_mode_debug_printmodeline], Modeline
11:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
[ 8.244195] Can't support LVDS on pipe A
[ 8.244201] [drm:drm_crtc_helper_set_mode], Encoder fixup failed
[ 8.244211] [drm:drm_crtc_helper_set_config] *ERROR* failed to set
mode on [CRTC:3]
[ 8.244222] fbcon_init: detected unhandled fb_set_par error, error code -22
[ 8.262085] Console: switching to colour frame buffer device 128x37
[ 8.293680] fb0: psbfb frame buffer device
[ 8.294817] drm: registered panic notifier
[ 8.295173] [drm] Initialized gma500 1.0.0 2011-06-06 for
0000:00:02.0 on minor 0
> We have no SDVO support for Oaktrail and I've never seen any hardware
> that does LVDS over SDVO (though there is support for that on Poulsbo).
>
Don't ask... my hardware guy has some ominous reasons that its done this way :)
---
Christian Gmeiner, MSc
On Tue, Jun 12, 2012 at 10:59 AM, Christian Gmeiner
<[email protected]> wrote:
> Got a little bit further:
>
> diff --git a/drivers/gpu/drm/gma500/mid_bios.c
> b/drivers/gpu/drm/gma500/mid_bios.c
> index b2a790b..9ee3122 100644
> --- a/drivers/gpu/drm/gma500/mid_bios.c
> +++ b/drivers/gpu/drm/gma500/mid_bios.c
> @@ -55,8 +55,12 @@ static void mid_get_fuse_settings(struct drm_device *dev)
> ? ? ? ?pci_read_config_dword(pci_root, 0xD4, &fuse_value);
>
> ? ? ? ?/* FB_MIPI_DISABLE doesn't mean LVDS on with Medfield */
> +#if 0
> ? ? ? ?if (IS_MRST(dev))
> ? ? ? ? ? ? ? ?dev_priv->iLVDS_enable = fuse_value & FB_MIPI_DISABLE;
> +#else
> + ? ? ? dev_priv->iLVDS_enable = 1;
> +#endif
>
> ? ? ? ?DRM_INFO("internal display is %s\n",
> ? ? ? ? ? ? ? ? dev_priv->iLVDS_enable ? "LVDS display" : "MIPI display");
> diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
> b/drivers/gpu/drm/gma500/psb_intel_lvds.c
> index c83f5b5..5b49522 100644
> --- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
> @@ -530,11 +530,14 @@ static int psb_intel_lvds_get_modes(struct
> drm_connector *connector)
> ? ? ? ?struct psb_intel_lvds_priv *lvds_priv = psb_intel_encoder->dev_priv;
> ? ? ? ?int ret = 0;
>
> + ? ? ? printk(KERN_INFO "test 1\n");
> +#if 0
> ? ? ? ?if (!IS_MRST(dev))
> ? ? ? ? ? ? ? ?ret = psb_intel_ddc_get_modes(connector,
> &lvds_priv->i2c_bus->adapter);
>
> ? ? ? ?if (ret)
> ? ? ? ? ? ? ? ?return ret;
> +#endif
>
> ? ? ? ?/* Didn't get an EDID, so
> ? ? ? ? * Set wide sync ranges so we get all modes
>
>
> [ ? ?8.233858] [drm:drm_helper_probe_single_connector_modes],
> [CONNECTOR:7:LVDS-1]
> [ ? ?8.233869] test 1
> [ ? ?8.233967] [drm:drm_helper_probe_single_connector_modes],
> [CONNECTOR:7:LVDS-1] probed modes :
> [ ? ?8.233993] [drm:drm_mode_debug_printmodeline], Modeline
> 10:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
> [ ? ?8.234038] [drm:drm_setup_crtcs],
> [ ? ?8.234053] [drm:drm_enable_connectors], connector 7 enabled? yes
> [ ? ?8.234066] [drm:drm_target_preferred], looking for cmdline mode on
> connector 7
> [ ? ?8.234077] [drm:drm_target_preferred], looking for preferred mode
> on connector 7
> [ ? ?8.234088] [drm:drm_target_preferred], found mode 1024x600
> [ ? ?8.234101] [drm:drm_setup_crtcs], picking CRTCs for 2048x2048 config
> [ ? ?8.234116] [drm:drm_setup_crtcs], desired mode 1024x600 set on crtc 3
> [ ? ?8.242199] fbcon: psbfb (fb0) is primary device
> [ ? ?8.244065] [drm:drm_crtc_helper_set_config],
> [ ? ?8.244076] [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:12]
> #connectors=1 (x y) (0 0)
> [ ? ?8.244099] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set
> [ ? ?8.244106] [drm:drm_crtc_helper_set_config], modes are different,
> full mode set
> [ ? ?8.244120] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0
> 0 0 0 0 0 0 0 0x0 0x0
> [ ? ?8.244138] [drm:drm_mode_debug_printmodeline], Modeline
> 11:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
> [ ? ?8.244145] [drm:drm_crtc_helper_set_config], encoder changed, full
> mode switch
> [ ? ?8.244151] [drm:drm_crtc_helper_set_config], crtc changed, full mode switch
> [ ? ?8.244161] [drm:drm_crtc_helper_set_config], [CONNECTOR:7:LVDS-1]
> to [CRTC:3]
> [ ? ?8.244168] [drm:drm_crtc_helper_set_config], attempting to set
> mode from userspace
> [ ? ?8.244184] [drm:drm_mode_debug_printmodeline], Modeline
> 11:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
> [ ? ?8.244195] Can't support LVDS on pipe A
> [ ? ?8.244201] [drm:drm_crtc_helper_set_mode], Encoder fixup failed
> [ ? ?8.244211] [drm:drm_crtc_helper_set_config] *ERROR* failed to set
> mode on [CRTC:3]
> [ ? ?8.244222] fbcon_init: detected unhandled fb_set_par error, error code -22
> [ ? ?8.262085] Console: switching to colour frame buffer device 128x37
> [ ? ?8.293680] fb0: psbfb frame buffer device
> [ ? ?8.294817] drm: registered panic notifier
> [ ? ?8.295173] [drm] Initialized gma500 1.0.0 2011-06-06 for
> 0000:00:02.0 on minor 0
You're hitting a bug in the IS_MRST macro. You might actually have the fuse
value but IS_MRST returns false for 0x4108. Try the following patch:
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 1bd115e..e8640ae 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -44,7 +44,7 @@ enum {
};
#define IS_PSB(dev) (((dev)->pci_device & 0xfffe) == 0x8108)
-#define IS_MRST(dev) (((dev)->pci_device & 0xfffc) == 0x4100)
+#define IS_MRST(dev) (((dev)->pci_device & 0xfff0) == 0x4100)
#define IS_MFLD(dev) (((dev)->pci_device & 0xfff8) == 0x0130)
/*
> You're hitting a bug in the IS_MRST macro. You might actually have the fuse
> value but IS_MRST returns false for 0x4108. Try the following patch:
If its an Oaktrail device then it should be using the PC BIOS data anyway
I would have thought. Only Moorestown should be using the other style of
data and Moorestown never became a real product.
However if the panel is on the SDVO port then the BIOS data would appear
to be correct as it isn't on the LVDS channel but bridged off the SDVO.
In that case it'll need SDVO support sorting out.
Alan
2012/6/12 Patrik Jakobsson <[email protected]>:
> On Tue, Jun 12, 2012 at 10:59 AM, Christian Gmeiner
> <[email protected]> wrote:
>> Got a little bit further:
>>
>> diff --git a/drivers/gpu/drm/gma500/mid_bios.c
>> b/drivers/gpu/drm/gma500/mid_bios.c
>> index b2a790b..9ee3122 100644
>> --- a/drivers/gpu/drm/gma500/mid_bios.c
>> +++ b/drivers/gpu/drm/gma500/mid_bios.c
>> @@ -55,8 +55,12 @@ static void mid_get_fuse_settings(struct drm_device *dev)
>> pci_read_config_dword(pci_root, 0xD4, &fuse_value);
>>
>> /* FB_MIPI_DISABLE doesn't mean LVDS on with Medfield */
>> +#if 0
>> if (IS_MRST(dev))
>> dev_priv->iLVDS_enable = fuse_value & FB_MIPI_DISABLE;
>> +#else
>> + dev_priv->iLVDS_enable = 1;
>> +#endif
>>
>> DRM_INFO("internal display is %s\n",
>> dev_priv->iLVDS_enable ? "LVDS display" : "MIPI display");
>> diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c
>> b/drivers/gpu/drm/gma500/psb_intel_lvds.c
>> index c83f5b5..5b49522 100644
>> --- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
>> +++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
>> @@ -530,11 +530,14 @@ static int psb_intel_lvds_get_modes(struct
>> drm_connector *connector)
>> struct psb_intel_lvds_priv *lvds_priv = psb_intel_encoder->dev_priv;
>> int ret = 0;
>>
>> + printk(KERN_INFO "test 1\n");
>> +#if 0
>> if (!IS_MRST(dev))
>> ret = psb_intel_ddc_get_modes(connector,
>> &lvds_priv->i2c_bus->adapter);
>>
>> if (ret)
>> return ret;
>> +#endif
>>
>> /* Didn't get an EDID, so
>> * Set wide sync ranges so we get all modes
>>
>>
>> [ 8.233858] [drm:drm_helper_probe_single_connector_modes],
>> [CONNECTOR:7:LVDS-1]
>> [ 8.233869] test 1
>> [ 8.233967] [drm:drm_helper_probe_single_connector_modes],
>> [CONNECTOR:7:LVDS-1] probed modes :
>> [ 8.233993] [drm:drm_mode_debug_printmodeline], Modeline
>> 10:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
>> [ 8.234038] [drm:drm_setup_crtcs],
>> [ 8.234053] [drm:drm_enable_connectors], connector 7 enabled? yes
>> [ 8.234066] [drm:drm_target_preferred], looking for cmdline mode on
>> connector 7
>> [ 8.234077] [drm:drm_target_preferred], looking for preferred mode
>> on connector 7
>> [ 8.234088] [drm:drm_target_preferred], found mode 1024x600
>> [ 8.234101] [drm:drm_setup_crtcs], picking CRTCs for 2048x2048 config
>> [ 8.234116] [drm:drm_setup_crtcs], desired mode 1024x600 set on crtc 3
>> [ 8.242199] fbcon: psbfb (fb0) is primary device
>> [ 8.244065] [drm:drm_crtc_helper_set_config],
>> [ 8.244076] [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:12]
>> #connectors=1 (x y) (0 0)
>> [ 8.244099] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set
>> [ 8.244106] [drm:drm_crtc_helper_set_config], modes are different,
>> full mode set
>> [ 8.244120] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0
>> 0 0 0 0 0 0 0 0x0 0x0
>> [ 8.244138] [drm:drm_mode_debug_printmodeline], Modeline
>> 11:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
>> [ 8.244145] [drm:drm_crtc_helper_set_config], encoder changed, full
>> mode switch
>> [ 8.244151] [drm:drm_crtc_helper_set_config], crtc changed, full mode switch
>> [ 8.244161] [drm:drm_crtc_helper_set_config], [CONNECTOR:7:LVDS-1]
>> to [CRTC:3]
>> [ 8.244168] [drm:drm_crtc_helper_set_config], attempting to set
>> mode from userspace
>> [ 8.244184] [drm:drm_mode_debug_printmodeline], Modeline
>> 11:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
>> [ 8.244195] Can't support LVDS on pipe A
>> [ 8.244201] [drm:drm_crtc_helper_set_mode], Encoder fixup failed
>> [ 8.244211] [drm:drm_crtc_helper_set_config] *ERROR* failed to set
>> mode on [CRTC:3]
>> [ 8.244222] fbcon_init: detected unhandled fb_set_par error, error code -22
>> [ 8.262085] Console: switching to colour frame buffer device 128x37
>> [ 8.293680] fb0: psbfb frame buffer device
>> [ 8.294817] drm: registered panic notifier
>> [ 8.295173] [drm] Initialized gma500 1.0.0 2011-06-06 for
>> 0000:00:02.0 on minor 0
>
> You're hitting a bug in the IS_MRST macro. You might actually have the fuse
> value but IS_MRST returns false for 0x4108. Try the following patch:
>
> diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
> index 1bd115e..e8640ae 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.h
> +++ b/drivers/gpu/drm/gma500/psb_drv.h
> @@ -44,7 +44,7 @@ enum {
> };
>
> #define IS_PSB(dev) (((dev)->pci_device & 0xfffe) == 0x8108)
> -#define IS_MRST(dev) (((dev)->pci_device & 0xfffc) == 0x4100)
> +#define IS_MRST(dev) (((dev)->pci_device & 0xfff0) == 0x4100)
> #define IS_MFLD(dev) (((dev)->pci_device & 0xfff8) == 0x0130)
>
> /*
Works much better with this patch applied - I see a linux desktop on
the panel :)
[ 17.907584] gma500 0000:00:02.0: setting latency timer to 64
[ 17.907908] [drm:psb_intel_opregion_setup], Public ACPI methods supported
[ 17.907921] [drm:psb_intel_opregion_setup], ASLE supported
[ 17.907945] gma500 0000:00:02.0: Enabling MSI failed!
[ 17.909051] [drm] internal display is LVDS display
[ 17.909183] ioremap error for 0x3ddbd000-0x3ddbe000, requested 0x10, got 0x0
[ 17.909294] gma500 0000:00:02.0: Unable to read GCT!
[ 17.917913] gma500 0000:00:02.0: VBT signature missing
[ 17.925659] hub 6-0:1.0: USB hub found
[ 17.925775] hub 6-0:1.0: 1 port detected
[ 17.926214] ohci_hcd 0000:02:08.1: setting latency timer to 64
[ 17.926233] ohci_hcd 0000:02:08.1: OHCI Host Controller
[ 17.926349] ohci_hcd 0000:02:08.1: new USB bus registered, assigned
bus number 7
[ 17.926520] ohci_hcd 0000:02:08.1: irq 16, io mem 0xd014e000
[ 17.966094] usb 1-1: new high-speed USB device number 2 using ehci_hcd
[ 17.982193] hub 7-0:1.0: USB hub found
[ 17.982308] hub 7-0:1.0: 1 port detected
[ 17.982684] ohci_hcd 0000:02:08.2: setting latency timer to 64
[ 17.982703] ohci_hcd 0000:02:08.2: OHCI Host Controller
[ 17.982818] ohci_hcd 0000:02:08.2: new USB bus registered, assigned
bus number 8
[ 17.982990] ohci_hcd 0000:02:08.2: irq 16, io mem 0xd014d000
[ 18.000555] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 18.000657] [drm] No driver support for vblank timestamp query.
[ 18.000901] gma500 0000:00:02.0: No ddc adapter available!
[ 18.041626] hub 8-0:1.0: USB hub found
[ 18.041740] hub 8-0:1.0: 1 port detected
[ 18.081160] hub 1-1:1.0: USB hub found
[ 18.081470] hub 1-1:1.0: 3 ports detected
[ 18.354785] [drm:drm_helper_probe_single_connector_modes],
[CONNECTOR:7:LVDS-1]
[ 18.354815] [drm:drm_helper_probe_single_connector_modes],
[CONNECTOR:7:LVDS-1] probed modes :
[ 18.354841] [drm:drm_mode_debug_printmodeline], Modeline
10:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
[ 18.354853] [drm:drm_setup_crtcs],
[ 18.354868] [drm:drm_enable_connectors], connector 7 enabled? yes
[ 18.354881] [drm:drm_target_preferred], looking for cmdline mode on
connector 7
[ 18.354894] [drm:drm_target_preferred], looking for preferred mode
on connector 7
[ 18.354906] [drm:drm_target_preferred], found mode 1024x600
[ 18.354918] [drm:drm_setup_crtcs], picking CRTCs for 2048x2048 config
[ 18.354933] [drm:drm_setup_crtcs], desired mode 1024x600 set on crtc 3
[ 18.367788] fbcon: psbfb (fb0) is primary device
[ 18.370608] [drm:drm_crtc_helper_set_config],
[ 18.370619] [drm:drm_crtc_helper_set_config], [CRTC:3] [FB:12]
#connectors=1 (x y) (0 0)
[ 18.370643] [drm:drm_crtc_helper_set_config], crtc has no fb, full mode set
[ 18.370649] [drm:drm_crtc_helper_set_config], modes are different,
full mode set
[ 18.370664] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0
0 0 0 0 0 0 0 0x0 0x0
[ 18.370681] [drm:drm_mode_debug_printmodeline], Modeline
11:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
[ 18.370689] [drm:drm_crtc_helper_set_config], encoder changed, full
mode switch
[ 18.370696] [drm:drm_crtc_helper_set_config], crtc changed, full mode switch
[ 18.370706] [drm:drm_crtc_helper_set_config], [CONNECTOR:7:LVDS-1]
to [CRTC:3]
[ 18.370713] [drm:drm_crtc_helper_set_config], attempting to set
mode from userspace
[ 18.370730] [drm:drm_mode_debug_printmodeline], Modeline
11:"1024x600" 75 53990 1024 1072 1104 1184 600 603 604 608 0x48 0x0
[ 18.370747] [drm:drm_crtc_helper_set_mode], [CRTC:3]
[ 18.401081] usb 6-1: new full-speed USB device number 2 using ohci_hcd
[ 18.440582] [drm:drm_crtc_helper_set_mode], [ENCODER:8:LVDS-8] set
[MODE:11:1024x600]
[ 18.477990] [drm:drm_crtc_helper_set_config], Setting connector
DPMS state to on
[ 18.478002] [drm:drm_crtc_helper_set_config],
[CONNECTOR:7:LVDS-1] set DPMS on
[ 18.505542] [drm:drm_crtc_helper_set_config],
[ 18.505550] [drm:drm_crtc_helper_set_config], [CRTC:4] [NOFB]
[ 18.603146] Console: switching to colour frame buffer device 128x37
[ 18.613253] usbcore: registered new interface driver usbhid
[ 18.613256] usbhid: USB HID core driver
[ 18.619328] fb0: psbfb frame buffer device
[ 18.619332] drm: registered panic notifier
[ 18.619857] [drm] Initialized gma500 1.0.0 2011-06-06 for
0000:00:02.0 on minor 0
Is there a way to overwrite the found modeline?
Thanks
---
Christian Gmeiner, MSc
> Works much better with this patch applied - I see a linux desktop on
> the panel :)
Yay..
> Is there a way to overwrite the found modeline?
You can set modelines via the video interfaces and also by passing it as
a boot parameter. The mode setting X server will also let you set modes.
video=640x400@60
or similar should work - you can set all kinds of bits this way.
If there is a way to identify the platform and that is needed to get it
right then we can also hardcode a DMI match or similar for the device
eventually.
Alan
On Tue, Jun 12, 2012 at 2:27 PM, Alan Cox <[email protected]> wrote:
>> Works much better with this patch applied - I see a linux desktop on
>> the panel :)
>
> Yay..
>
>> Is there a way to overwrite the found modeline?
>
> You can set modelines via the video interfaces and also by passing it as
> a boot parameter. The mode setting X server will also let you set modes.
>
>
> video=640x400@60
>
> or similar should work - you can set all kinds of bits this way.
>
>
> If there is a way to identify the platform and that is needed to get it
> right then we can also hardcode a DMI match or similar for the device
> eventually.
Was there a special reason for 0x4108 to be left out in the IS_MRST macro?
To me it looks like the bitmask should have been updated in commit:
gma500: Add the E6xx PCI identifier we are missing
56125db1eecf8d34d84f7925686110d90724edf0
If this is the case, I'll send a proper patch since this also applies to
stable 3.3.x and 3.4.x
Patrik
> Was there a special reason for 0x4108 to be left out in the IS_MRST macro?
> To me it looks like the bitmask should have been updated in commit:
>
> gma500: Add the E6xx PCI identifier we are missing
> 56125db1eecf8d34d84f7925686110d90724edf0
>
> If this is the case, I'll send a proper patch since this also applies to
> stable 3.3.x and 3.4.x
Firstly it should never matter - there are no Moorestown devices in
circulation. E600T is very similar to Oaktrail.
So the real question here seems to be why does the IS_MRST macro matter.
What weird firmware is involved here ?
Alan
On Tue, Jun 12, 2012 at 6:04 PM, Alan Cox <[email protected]> wrote:
>> Was there a special reason for 0x4108 to be left out in the IS_MRST macro?
>> To me it looks like the bitmask should have been updated in commit:
>>
>> gma500: Add the E6xx PCI identifier we are missing
>> 56125db1eecf8d34d84f7925686110d90724edf0
>>
>> If this is the case, I'll send a proper patch since this also applies to
>> stable 3.3.x and 3.4.x
>
> Firstly it should never matter - there are no Moorestown devices in
> circulation. E600T is very similar to Oaktrail.
>
> So the real question here seems to be why does the IS_MRST macro matter.
> What weird firmware is involved here ?
It matters because everything between 0x4100 - 0x4107 are Moorestown if you ask
the macro, but are assigned to oaktrail_chip_ops. That makes Oaktrail ==
Moorestown. IS_OAK might be a more appropriate name.
IS_MRST is primarily used for two things:
1) Take LVDS enable fuse value into account
2) Tell that LVDS must be on Pipe A
Those things where required for him to get the panel working,
so why not include the 0x4108 in the IS_MRST check?
-Patrik
> It matters because everything between 0x4100 - 0x4107 are Moorestown if you ask
> the macro, but are assigned to oaktrail_chip_ops. That makes Oaktrail ==
> Moorestown. IS_OAK might be a more appropriate name.
Oaktrail is sort of Moorestown, the divide is whether they have a PC like
set of I/O devices or not. It reflects the history of the driver
> IS_MRST is primarily used for two things:
> 1) Take LVDS enable fuse value into account
This like the non PC BIOS parsing should probably go. I've not taken it
out yet because I wanted to prove this. I'd be very surprised if it's the
right way to handle E600T but there's a bit of a lack of any public info
on that so who knows 8(.
> 2) Tell that LVDS must be on Pipe A
Which is true for Oaktrail and it seems E600T
> Those things where required for him to get the panel working,
> so why not include the 0x4108 in the IS_MRST check?
We probably want IS_GMA600() rather than IS_MRST.
Alan
2012/6/12 Alan Cox <[email protected]>:
>> Was there a special reason for 0x4108 to be left out in the IS_MRST macro?
>> To me it looks like the bitmask should have been updated in commit:
>>
>> gma500: Add the E6xx PCI identifier we are missing
>> 56125db1eecf8d34d84f7925686110d90724edf0
>>
>> If this is the case, I'll send a proper patch since this also applies to
>> stable 3.3.x and 3.4.x
>
> Firstly it should never matter - there are no Moorestown devices in
> circulation. E600T is very similar to Oaktrail.
>
> So the real question here seems to be why does the IS_MRST macro matter.
> What weird firmware is involved here ?
My company is using these cpu bords for our products:
http://www.congatec.com/en/products/qseven/dView/conga-qa6.html
With firmware you mean BIOS or VBios or ...? If you tell me what you need, I may
ask our supplier for more informations. I can tell you that the
following options can be
changed in the BIOS regarding gfx - see
https://www.dropbox.com/s/btlciurz0ih4fhu/IMG_20120612_143431.jpg
---
Christian Gmeiner, MSc
2012/6/12 Christian Gmeiner <[email protected]>:
> 2012/6/12 Alan Cox <[email protected]>:
>>> Was there a special reason for 0x4108 to be left out in the IS_MRST macro?
>>> To me it looks like the bitmask should have been updated in commit:
>>>
>>> gma500: Add the E6xx PCI identifier we are missing
>>> 56125db1eecf8d34d84f7925686110d90724edf0
>>>
>>> If this is the case, I'll send a proper patch since this also applies to
>>> stable 3.3.x and 3.4.x
>>
>> Firstly it should never matter - there are no Moorestown devices in
>> circulation. E600T is very similar to Oaktrail.
>>
>> So the real question here seems to be why does the IS_MRST macro matter.
>> What weird firmware is involved here ?
>
> My company is using these cpu bords for our products:
> http://www.congatec.com/en/products/qseven/dView/conga-qa6.html
>
> With firmware you mean BIOS or VBios or ...? If you tell me what you need, I may
> ask our supplier for more informations. I can tell you that the
> following options can be
> changed in the BIOS regarding gfx - see
> https://www.dropbox.com/s/btlciurz0ih4fhu/IMG_20120612_143431.jpg
>
Here are some more informations. There seems to be a scaling problem.
If i compare gma500 and the vesa framebuffer driver I see that gma500 shows
the desktop "scaled" up --> not the whole desktop is on the screen. It
gets better
if i remove the video="..." parameter from kernel cmdline, but it
still is too big for
the screen.
I really would love to get this beast up an running... so I will
provide as much informations
as needed - just ask :)
---
Christian Gmeiner, MSc
> Here are some more informations. There seems to be a scaling problem.
> If i compare gma500 and the vesa framebuffer driver I see that gma500 shows
> the desktop "scaled" up --> not the whole desktop is on the screen. It
> gets better
> if i remove the video="..." parameter from kernel cmdline, but it
> still is too big for
> the screen.
"scaled up" meaning what - pixel sizes. I don't really understand what
you are trying to describe ?
What size is the desktop reported at, what created the "desktop" ?
> My company is using these cpu bords for our products:
> http://www.congatec.com/en/products/qseven/dView/conga-qa6.html
>
> With firmware you mean BIOS or VBios or ...? If you tell me what you need, I may
> ask our supplier for more informations. I can tell you that the
> following options can be
> changed in the BIOS regarding gfx - see
> https://www.dropbox.com/s/btlciurz0ih4fhu/IMG_20120612_143431.jpg
The basic question is:
Does this device use the Intel BIOS way of reporting mode information,
or the embedded "GCT" style.
If you look in oaktrail_device.c you'll see it tries mid_chip_setup() and
then if that fails to find data it calls psb_intel_init_bios(). Which is
in use. Also if the mid style one is in use what happens if you change
mid_get_vbt_data in mid_bios.c so that it just does
vbt->size = 0;
return;
Alan
2012/6/13 Alan Cox <[email protected]>:
>> My company is using these cpu bords for our products:
>> http://www.congatec.com/en/products/qseven/dView/conga-qa6.html
>>
>> With firmware you mean BIOS or VBios or ...? If you tell me what you need, I may
>> ask our supplier for more informations. I can tell you that the
>> following options can be
>> changed in the BIOS regarding gfx - see
>> https://www.dropbox.com/s/btlciurz0ih4fhu/IMG_20120612_143431.jpg
>
> The basic question is:
>
> Does this device use the Intel BIOS way of reporting mode information,
> or the embedded "GCT" style.
>
As far as I can tell from the logs, it seems to use the Intel BIOS way.
[ 2.366174] [drm:psb_intel_opregion_setup], Public ACPI methods supported
[ 2.366183] [drm:psb_intel_opregion_setup], ASLE supported
[ 2.366200] gma500 0000:00:02.0: Enabling MSI failed!
[ 2.366287] [drm] internal display is LVDS display
[ 2.366363] gma500 0000:00:02.0: SKU values is 0x2a00000.
[ 2.366371] gma500 0000:00:02.0: LNC core clk is 200MHz.
[ 2.366389] gma500 0000:00:02.0: drm platform config address is 3ddbd010
[ 2.366403] ioremap error for 0x3ddbd000-0x3ddbe000, requested 0x10, got 0x0
[ 2.366484] gma500 0000:00:02.0: Unable to read GCT!
[ 2.366563] gma500 0000:00:02.0: platform_rev_id is 5
[ 2.368471] gma500 0000:00:02.0: VBT signature missing
I will ask my contact at congatec what they are really using. I hope
to get some feedback soon.
---
Christian Gmeiner, MSc
On Wed, Jun 13, 2012 at 2:26 PM, Christian Gmeiner
<[email protected]> wrote:
> 2012/6/13 Alan Cox <[email protected]>:
>> The basic question is:
>>
>> Does this device use the Intel BIOS way of reporting mode information,
>> or the embedded "GCT" style.
>>
>
> As far as I can tell from the logs, it seems to use the Intel BIOS way.
>
> [ ? ?2.366174] [drm:psb_intel_opregion_setup], Public ACPI methods supported
> [ ? ?2.366183] [drm:psb_intel_opregion_setup], ASLE supported
> [ ? ?2.366200] gma500 0000:00:02.0: Enabling MSI failed!
> [ ? ?2.366287] [drm] internal display is LVDS display
Do you still force lvds on as with your first modification or are the fuse
values being read? As Alan said, we might need to add a DMI quirk
for this particular board in order to pick LVDS instead of MIPI.
What do you get when running:
dmidecode -t 1
> [ ? ?2.366363] gma500 0000:00:02.0: SKU values is 0x2a00000.
> [ ? ?2.366371] gma500 0000:00:02.0: LNC core clk is 200MHz.
> [ ? ?2.366389] gma500 0000:00:02.0: drm platform config address is 3ddbd010
> [ ? ?2.366403] ioremap error for 0x3ddbd000-0x3ddbe000, requested 0x10, got 0x0
> [ ? ?2.366484] gma500 0000:00:02.0: Unable to read GCT!
> [ ? ?2.366563] gma500 0000:00:02.0: platform_rev_id is 5
> [ ? ?2.368471] gma500 0000:00:02.0: VBT signature missing
>
>
> I will ask my contact at congatec what they are really using. I hope
> to get some feedback soon.
As you said in your first post, modes are read from an at24 i2c eeprom,
so we need to add support for that unless you can live with supplying
your own modes as boot parameter or in your xorg.conf.
-Patrik
2012/6/13 Christian Gmeiner <[email protected]>:
> 2012/6/13 Alan Cox <[email protected]>:
>>> My company is using these cpu bords for our products:
>>> http://www.congatec.com/en/products/qseven/dView/conga-qa6.html
>>>
>>> With firmware you mean BIOS or VBios or ...? If you tell me what you need, I may
>>> ask our supplier for more informations. I can tell you that the
>>> following options can be
>>> changed in the BIOS regarding gfx - see
>>> https://www.dropbox.com/s/btlciurz0ih4fhu/IMG_20120612_143431.jpg
>>
>> The basic question is:
>>
>> Does this device use the Intel BIOS way of reporting mode information,
>> or the embedded "GCT" style.
>>
>
> As far as I can tell from the logs, it seems to use the Intel BIOS way.
>
> [ 2.366174] [drm:psb_intel_opregion_setup], Public ACPI methods supported
> [ 2.366183] [drm:psb_intel_opregion_setup], ASLE supported
> [ 2.366200] gma500 0000:00:02.0: Enabling MSI failed!
> [ 2.366287] [drm] internal display is LVDS display
> [ 2.366363] gma500 0000:00:02.0: SKU values is 0x2a00000.
> [ 2.366371] gma500 0000:00:02.0: LNC core clk is 200MHz.
> [ 2.366389] gma500 0000:00:02.0: drm platform config address is 3ddbd010
> [ 2.366403] ioremap error for 0x3ddbd000-0x3ddbe000, requested 0x10, got 0x0
> [ 2.366484] gma500 0000:00:02.0: Unable to read GCT!
> [ 2.366563] gma500 0000:00:02.0: platform_rev_id is 5
> [ 2.368471] gma500 0000:00:02.0: VBT signature missing
>
>
> I will ask my contact at congatec what they are really using. I hope
> to get some feedback soon.
So here is the feedback i got from congatec:
In general I should use the Intel Embedded Media and Graphic Driver as
this seems to work for other
customers. EMGD and VBIOS do not share any information's regarding
LVDS configuration.
So it looks like I need to generate the correct VBIOS and flash it
with a congatec utility onto the device.
And then the gma500 driver should find a VBIOS with VBT signature.
---
Christian Gmeiner, MSc
2012/6/13 Patrik Jakobsson <[email protected]>:
> On Wed, Jun 13, 2012 at 2:26 PM, Christian Gmeiner
> <[email protected]> wrote:
>> 2012/6/13 Alan Cox <[email protected]>:
>>> The basic question is:
>>>
>>> Does this device use the Intel BIOS way of reporting mode information,
>>> or the embedded "GCT" style.
>>>
>>
>> As far as I can tell from the logs, it seems to use the Intel BIOS way.
>>
>> [ 2.366174] [drm:psb_intel_opregion_setup], Public ACPI methods supported
>> [ 2.366183] [drm:psb_intel_opregion_setup], ASLE supported
>> [ 2.366200] gma500 0000:00:02.0: Enabling MSI failed!
>> [ 2.366287] [drm] internal display is LVDS display
> Do you still force lvds on as with your first modification or are the fuse
> values being read? As Alan said, we might need to add a DMI quirk
> for this particular board in order to pick LVDS instead of MIPI.
>
> What do you get when running:
> dmidecode -t 1
>
I see a lot "Need to filled by OEM" strings - an other thing to fix in the BIOS.
This should be doable also with the congatec utility.
>> [ 2.366363] gma500 0000:00:02.0: SKU values is 0x2a00000.
>> [ 2.366371] gma500 0000:00:02.0: LNC core clk is 200MHz.
>> [ 2.366389] gma500 0000:00:02.0: drm platform config address is 3ddbd010
>> [ 2.366403] ioremap error for 0x3ddbd000-0x3ddbe000, requested 0x10, got 0x0
>> [ 2.366484] gma500 0000:00:02.0: Unable to read GCT!
>> [ 2.366563] gma500 0000:00:02.0: platform_rev_id is 5
>> [ 2.368471] gma500 0000:00:02.0: VBT signature missing
>>
>>
>> I will ask my contact at congatec what they are really using. I hope
>> to get some feedback soon.
>
> As you said in your first post, modes are read from an at24 i2c eeprom,
> so we need to add support for that unless you can live with supplying
> your own modes as boot parameter or in your xorg.conf.
>
Thanks... I will try to generate a VBIOS and see what happens.
--
Christian Gmeiner, MSc
