28 Apr, 2011

2 commits

  • In the absence of configuration data for providing the fixed mode for
    a panel, I would like to be able to pass such modes along a separate
    module paramenter. To do so, I then need to parse a modeline from a
    string, which drm is already capable of. Export that capability to the
    drivers.

    Signed-off-by: Chris Wilson
    Signed-off-by: Dave Airlie

    Chris Wilson
     
  • We need to hold the dev->mode_config.mutex whilst detecting the output
    status. But we also need to drop it for the call into
    drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
    attaching the fbcon.

    Failure to do so exposes a race with normal output probing. Detected by
    adding some warnings that the mutex is held to the backend detect routines:

    [ 17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
    [ 17.772458] Hardware name: Latitude E6400
    [ 17.772460] Modules linked in: ....
    [ 17.772582] Pid: 11, comm: kworker/0:1 Tainted: G W 2.6.38.4-custom.2 #8
    [ 17.772584] Call Trace:
    [ 17.772591] [] ? warn_slowpath_common+0x78/0x8c
    [ 17.772603] [] ? intel_crt_detect+0x3e/0x373 [i915]
    [ 17.772612] [] ? drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
    [ 17.772619] [] ? drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
    [ 17.772625] [] ? drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
    [ 17.772633] [] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
    [ 17.772638] [] ? cfq_init_queue+0x247/0x345
    [ 17.772644] [] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
    [ 17.772648] [] ? process_one_work+0x193/0x28e
    [ 17.772652] [] ? worker_thread+0xef/0x172
    [ 17.772655] [] ? worker_thread+0x0/0x172
    [ 17.772658] [] ? worker_thread+0x0/0x172
    [ 17.772663] [] ? kthread+0x7a/0x82
    [ 17.772668] [] ? kernel_thread_helper+0x4/0x10
    [ 17.772671] [] ? kthread+0x0/0x82
    [ 17.772674] [] ? kernel_thread_helper+0x0/0x10

    Reported-by: Frederik Himpe
    References: https://bugs.freedesktop.org/show_bug.cgi?id=36394
    Signed-off-by: Chris Wilson
    Signed-off-by: Dave Airlie

    Chris Wilson
     

27 Apr, 2011

1 commit

  • i915 calls the panic handler function on last close to reset the modes,
    however this is a really bad idea for multi-gpu machines, esp shareable
    gpus machines. So add a new entry point for the driver to just restore
    its own fbcon mode.

    v2: move code into fb helper, fix panic code to block mode change on
    powered off GPUs.

    [airlied: this hits drm core and I wrote it and it was reviewed on intel-gfx
    so really I signed it off twice ;-).]
    Signed-off-by: Chris Wilson
    Signed-off-by: Dave Airlie

    Dave Airlie
     

15 Jan, 2011

1 commit

  • This reverts commit dfe63bb0ad9810db13aab0058caba97866e0a681.

    This commit was causing nouveau not to work properly, for -rc1 I'd
    prefer it worked and we can look if this is useful for 2.6.39.

    Cc: James Simmons
    Signed-off-by: Dave Airlie
    Signed-off-by: Linus Torvalds

    Dave Airlie
     

07 Jan, 2011

1 commit

  • If you change the color depth via fbset or some other framebuffer aware
    userland application struct fb_fix_screeninfo is not updated to this new
    information. This patch fixes this issue. Also the function is changed to
    just pass in struct drm_framebuffer so in the future we could use more
    fields. I'm hoping some day fix->smem* could be set here :-)

    Signed-off-by: James Simmons
    Signed-off-by: Dave Airlie

    James Simmons
     

05 Aug, 2010

1 commit


18 May, 2010

1 commit

  • After thinking it over a lot it made more sense for the core to deal with
    the output polling especially so it can notify X.

    v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings.

    v3: add config lock take inside polling, add intel/nouveau poll init/fini calls

    v4: config lock was a bit agressive, only needed around connector list reading.
    otherwise it could re-enter.

    glisse: discard drm_helper_hpd_irq_event

    v3: Reviewed-by: Michel Dänzer
    Signed-off-by: Dave Airlie

    Dave Airlie
     

07 Apr, 2010

5 commits

  • a) slow work is always used now for any fbcon hotplug, as its not
    a fast task and is more suited to being ran under slow work.

    b) attempt to not do any fbdev changes when X is running as we'll
    just mess it up. This hooks set_par to hopefully do the changes
    once X hands control to fbdev.

    This also adds the nouveau/intel hotplug support.

    Signed-off-by: Dave Airlie

    Dave Airlie
     
  • When we are running in a headless environment we have no idea what
    output the user might plug in later, we only have hotplug detect
    from the digital outputs. So if we detect no connected outputs at
    initialisation, start a slow work operation to poll every 5 seconds
    for an output.

    this is only hooked up for radeon so far, on hw where we have full
    hotplug detection there is no need for this.

    Signed-off-by: Dave Airlie

    Dave Airlie
     
  • This breaks the connection between the core drm connector list
    and the fbdev connector usage, and allows them to become disjoint
    in the future. It also removes the untype void* that was in the
    connector struct to support this.

    All connectors are added to the fbdev now but this could be
    changed in the future.

    Signed-off-by: Dave Airlie

    Dave Airlie
     
  • This move to using the list of crtcs in the fb helper and cleans up the
    whole picking code, now we store the crtc/connectors we want directly
    into the modeset and we use the modeset directly to set the mode.

    Fixes from James Simmons and Ben Skeggs.

    Signed-off-by: Dave Airlie

    Dave Airlie
     
  • The fbdev layer in the kms code should act like a consumer of the kms services and avoid having relying on information being store in the kms core structures in order for it to work.

    This patch

    a) removes the info pointer/psuedo palette from the core drm_framebuffer structure and moves it to the fbdev helper layer, it also removes the core drm keeping a list of kernel kms fbdevs.
    b) migrated all the fb helper functions out of the crtc helper file into the fb helper file.
    c) pushed the fb probing/hotplug control into the driver
    d) makes the surface sizes into a structure for ease of passing
    This changes the intel/radeon/nouveau drivers to use the new helper.

    Signed-off-by: Dave Airlie

    Dave Airlie
     

06 Oct, 2009

1 commit

  • The previous patches had some unwanted side effects, I've fixed
    the lack of 32bpp working, and fixed up 16bpp so it should also work.

    this also adds the interface to allow the driver to set a preferred
    console depth so for example low memory rn50 can set it to 8bpp.
    It also catches 24bpp on cards that can't do it and forces 32bpp.

    Tested on r100/r600/i945.

    Signed-off-by: Dave Airlie

    Dave Airlie
     

05 Oct, 2009

1 commit


25 Sep, 2009

1 commit

  • [note this requires an fb patch posted to linux-fbdev-devel already]

    This uses the normal video= command line option to control the kms
    output setup at boot time. It is used to override the autodetection
    done by kms.

    video= normally takes a framebuffer as the first parameter, in kms
    it will take a connector name, DVI-I-1, or LVDS-1 etc. If no output
    connector is specified the mode string will apply to all connectors.

    The mode specification used will match down the probed modes, and if
    no mode is found it will add a CVT mode that matches.

    video=1024x768 - all connectors match a 1024x768 mode or add a CVT on
    video=VGA-1:1024x768, VGA-1 connector gets mode only.

    The same strings as used in current fb modedb.c are used, except I've
    added three more letters, e, D, d, e = enable, D = enable Digital,
    d = disable, which allow a connector to be forced into a certain state.

    Signed-off-by: Dave Airlie

    Dave Airlie
     

31 Aug, 2009

1 commit

  • Initially I always meant this code to be shared, but things
    ran away from me before I got to it.

    This refactors the i915 and radeon kms fbdev interaction layers
    out into generic helpers + driver specific pieces.

    It moves all the panic/sysrq enhancements to the core file,
    and stores a linked list of kernel fbs. This could possibly be
    improved to only store the fb which has fbcon on it for panics
    etc.

    radeon retains some specific codes used for a big endian
    workaround.

    changes:
    fix oops in v1
    fix freeing path for crtc_info

    Reviewed-by: Jesse Barnes
    Signed-off-by: Dave Airlie

    Dave Airlie