Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#9318 closed defect (fixed)

Why is vmalloc=256M required for viafb?

Reported by: cjb Owned by: laforge
Priority: normal Milestone:
Component: kernel Version: not specified
Keywords: Cc: HaraldWelte@…, dsd
Blocked By: Blocking:
Deployments affected: Action Needed: test in build
Verified: no

Description

From dmesg:

[    0.526890] viafb_setup!
[    0.529500] VIA Graphics Intergration Chipset framebuffer 2.4 initializing
[    0.536539] VIAFB PCI Probe!!
[    0.539633] parse_lcd_port: viafb_lcd_port:,interface:0
[    0.544954] parse_dvi_port: viafb_dvi_port:,interface:0
[    0.550710] I2C bus via_i2c registered.
[    3.909326] TMDS Chip = 0
[    3.912023] viafb_init_dvi_size()
[    3.915410] viaparinfo->tmds_setting_info->get_dvi_size_method 2
[    3.921512] dvi_get_panel_info! 
[    3.924811] viafb_dvi_sense!!
[    5.598984] viafb_dvi_query_EDID!!
[   10.637979] viafb_dvi_query_EDID!!
[   15.676967] dvi panel size is  0 
[   15.680355] viafb_lvds_identify_vt1636.
[   19.036292] viafb_lvds_identify_vt1636.
[   24.075283] viafb_init_lcd_size()
[   24.078677] viaparinfo->lvds_setting_info->get_lcd_size_method 2
[   24.084759] Get LCD Size method by VGA BIOS !!
[   24.089294] fp_get_panel_id()
[   24.092339] LCD Panel_ID = 2
[   24.095302] LCD Panel Size = 2
[   24.098430] LVDS Chip = 0
[   24.101123] LVDS1 output_interface = 6
[   24.104943] LVDS2 output_interface = 6
[   24.108882] Device ID = 3409
[   24.111837] FB Size = 6000
[   24.128168] vmap allocation for size 268439552 failed: use vmalloc=<size> to increase size.
[   24.136654] ioremap of fbmem failed
[   24.140759] viafb: probe of 0000:00:01.0 failed with error -5

Attachments (1)

via-fb-dmesg (37.5 KB) - added by cjb 5 years ago.

Download all attachments as: .zip

Change History (15)

Changed 5 years ago by cjb

comment:1 Changed 5 years ago by cjb

(This is with VGA->CRT only, and the EDID pins not hooked up on the VGA signal.)

comment:2 Changed 5 years ago by cjb

  • Cc HaraldWelte@… added

Hi Harald, looks like the new viafb patches have some problems. I just pulled out a VX800 laptop with panel to try on that too, and the screen fades to white when viafb loads there.

comment:3 Changed 5 years ago by cjb

from Harald:

mh, the problem must be related to that particular board, as I've tested the code on both VX800 and VX855 (including a VX800 based laptop with panel). But thanks for letting me know. viafb was working on the device before? What about the external VGA?

After loading viafb from your xo-1.5 branch on the XO1.5 or the VIA VX855 reference board, you should definitely get working output on the VGA out.

If even that doesn't work, something must have gone wrong while rebasing my patches against the XO1.5 kernel tree.

[I'm offline till tuesday, will look into that after I return]

comment:4 Changed 5 years ago by cjb

Current status is that it works via Phoenix, and works with OFW if you pass vmalloc=256M. It takes the module about twenty seconds to load, though, and I've only got CRT (rather than the panel) working at the moment.

comment:5 Changed 5 years ago by cjb

  • Summary changed from Via framebuffer failure on 1.5 to Why is vmalloc=256M required for viafb?

Renaming, since this works with the vmalloc= line.

comment:6 Changed 5 years ago by dsd

Do we have dmesg output from a phoenix boot?
The explanation must be that phoenix is requesting a smaller allocation. OFW seems to be specifying that we want 256mb video memory, which is big. What size do we want to be requesting?

comment:7 Changed 5 years ago by cjb

Actually, the output pasted above is from Phoenix. There is an option to select the fb size in Phoenix -- it was set to 256M by default, when that error was generated, and moving it to 64M got viafb working.

OFW seems to set 64M, not 256M, and yet the ioremap() failure still happens; you can see it by removing the vmalloc= boot param.

comment:8 Changed 5 years ago by laforge

  • Owner changed from dsaxena to laforge

I think we need to double-check the OFW setting. maybe something is wrong there, or it gets re-set at some later point. I'll investigate next week when I have physical access to a XO1.5 board

comment:9 Changed 5 years ago by cjb

  • Cc dsd added

Good news; vmalloc=256M isn't required anymore after:

  • installing dev.laptop.org:~wmb/q3a03n.rom , which builds OFW for virtual mode
  • building with CONFIG_VMSPLIT_3G_OPT=y

(I don't know which one of the two was responsible yet.)

comment:10 Changed 5 years ago by cjb

  • Action Needed changed from diagnose to test in build

comment:11 Changed 5 years ago by dsd

confirmed, vmalloc= isn't needed now. I too don't know which change was the solution, although I suspect virtual mode OFW.

comment:12 Changed 5 years ago by cjb

I'll close this, then, although I still want to figure out what was going on.

comment:13 Changed 5 years ago by cjb

  • Resolution set to fixed
  • Status changed from new to closed

comment:14 Changed 5 years ago by anonymous

  • Milestone 1.5-software deleted

Milestone 1.5-software deleted

Note: See TracTickets for help on using tickets.