summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_dvo.c
AgeCommit message (Collapse)Author
2016-11-25drm/i915: Pass dev_priv to intel_setup_outputs()Ander Conselvan de Oliveira
Pass dev_priv to intel_setup_outputs() and functions called by it, since those are all intel i915 specific functions. Also, in the majority of the functions dev_priv is used more often than dev. In the rare cases where there are a few calls back into drm core, a local dev variable was added. v2: Don't convert dev to &dev_priv->drm in intel_dsi_init. (Ville) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479910904-11005-1-git-send-email-ander.conselvan.de.oliveira@intel.com
2016-11-01drm/i915: Pass dev_priv to intel_get_crtc_for_pipe()Ville Syrjälä
Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477946245-14134-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-11-01drm/i915: Store struct intel_crtc * in {pipe,plane}_to_crtc_mapping[]Ville Syrjälä
A lot of users of the {pipe,plane}_to_crtc_mapping[] will end up casting the result to intel_crtc, so let's just store the intel_crtc pointer in the first place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477946245-14134-7-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-09-21drm/i915: Store port enum in intel_encoderPandiyan, Dhinakaran
Storing the port enum in intel_encoder makes it convenient to know the port attached to an encoder. Moving the port information up from intel_digital_port to intel_encoder avoids unecessary intel_digital_port access and handles MST encoders cleanly without requiring conditional checks for them (thanks danvet). v2: Renamed the port enum member from 'attached_port' to 'port' (danvet) Fixed missing initialization of port in intel_sdvo.c (danvet) v3: Fixed missing initialization of port in intel_crt.c (Ville) v4: Storing port for DVO encoders too. Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Lyude <cpaul@redhat.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474334681-22690-3-git-send-email-dhinakaran.pandiyan@intel.com
2016-09-21drm/i915: Standardize port type for DVO encodersPandiyan, Dhinakaran
Changing the return type from 'char' to 'enum port' in intel_dvo_port_name() makes it easier to later move the port information to intel_encoder. In addition, the port type conforms to what we have elsewhere. Removing the last conditional that handles invalid port because dvo_reg is intialized to valid values for all DVO devices at definition. v2: Changed return type, for real (Jani) Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Lyude <cpaul@redhat.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474334681-22690-2-git-send-email-dhinakaran.pandiyan@intel.com
2016-08-24drm/i915/dvo: Remove dangling call to drm_encoder_cleanup()Chris Wilson
If we hit the error path, we have never called drm_encoder_init() and so have nothing to cleanup. Doing so hits a null dereference: [ 10.066261] BUG: unable to handle kernel NULL pointer dereference at 00000104 [ 10.066273] IP: [<c16054b4>] mutex_lock+0xa/0x15 [ 10.066287] *pde = 00000000 [ 10.066295] Oops: 0002 [#1] [ 10.066302] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm iTCO_wdt iTCO_vendor_support ppdev evdev snd_intel8x0 snd_ac97_codec ac97_bus psmouse snd_pcm snd_timer snd pcspkr uhci_hcd ehci_pci soundcore sr_mod ehci_hcd serio_raw i2c_i801 usbcore i2c_smbus cdrom lpc_ich mfd_core rng_core e100 mii floppy parport_pc parport acpi_cpufreq button processor usb_common eeprom lm85 hwmon_vid autofs4 [ 10.066378] CPU: 0 PID: 132 Comm: systemd-udevd Not tainted 4.8.0-rc3-00013-gef0e1ea #34 [ 10.066389] Hardware name: MicroLink /D865GLC , BIOS BF86510A.86A.0077.P25.0508040031 08/04/2005 [ 10.066401] task: f62db800 task.stack: f5970000 [ 10.066409] EIP: 0060:[<c16054b4>] EFLAGS: 00010286 CPU: 0 [ 10.066417] EIP is at mutex_lock+0xa/0x15 [ 10.066424] EAX: 00000104 EBX: 00000104 ECX: 00000000 EDX: 80000000 [ 10.066432] ESI: 00000000 EDI: 00000104 EBP: f5be8000 ESP: f5971b58 [ 10.066439] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 10.066446] CR0: 80050033 CR2: 00000104 CR3: 35945000 CR4: 000006d0 [ 10.066453] Stack: [ 10.066459] f503d740 f824dddf 00000000 f61170c0 f61170c0 f82371ae f850f40e 00000001 [ 10.066476] f61170c0 f5971bcc f5be8000 f9c2d401 00000001 f8236fcc 00000001 00000000 [ 10.066491] f5144014 f5be8104 00000008 f9c5267c 00000007 f61170c0 f5144400 f9c4ff00 [ 10.066507] Call Trace: [ 10.066526] [<f824dddf>] ? drm_modeset_lock_all+0x27/0xb3 [drm] [ 10.066545] [<f82371ae>] ? drm_encoder_cleanup+0x1a/0x132 [drm] [ 10.066559] [<f850f40e>] ? drm_atomic_helper_connector_reset+0x3f/0x5c [drm_kms_helper] [ 10.066644] [<f9c2d401>] ? intel_dvo_init+0x569/0x788 [i915] [ 10.066663] [<f8236fcc>] ? drm_encoder_init+0x43/0x20b [drm] [ 10.066734] [<f9bf1fce>] ? intel_modeset_init+0x1436/0x17dd [i915] [ 10.066791] [<f9b37636>] ? i915_driver_load+0x85a/0x15d3 [i915] [ 10.066846] [<f9b3603d>] ? i915_driver_open+0x5/0x5 [i915] [ 10.066857] [<c14af4d0>] ? firmware_map_add_entry.part.2+0xc/0xc [ 10.066868] [<c1343daf>] ? pci_device_probe+0x8e/0x11c [ 10.066878] [<c140cec8>] ? driver_probe_device+0x1db/0x62e [ 10.066888] [<c120c010>] ? kernfs_new_node+0x29/0x9c [ 10.066897] [<c13438e0>] ? pci_match_device+0xd9/0x161 [ 10.066905] [<c120c48b>] ? kernfs_create_dir_ns+0x42/0x88 [ 10.066914] [<c140d401>] ? __driver_attach+0xe6/0x11b [ 10.066924] [<c1303b13>] ? kobject_add_internal+0x1bb/0x44f [ 10.066933] [<c140d31b>] ? driver_probe_device+0x62e/0x62e [ 10.066941] [<c140a2d2>] ? bus_for_each_dev+0x46/0x7f [ 10.066950] [<c140c502>] ? driver_attach+0x1a/0x34 [ 10.066958] [<c140d31b>] ? driver_probe_device+0x62e/0x62e [ 10.066966] [<c140b758>] ? bus_add_driver+0x217/0x32a [ 10.066975] [<f8403000>] ? 0xf8403000 [ 10.066982] [<c140de27>] ? driver_register+0x5f/0x108 [ 10.066991] [<c1000493>] ? do_one_initcall+0x49/0x1f6 [ 10.067000] [<c1082299>] ? pick_next_task_fair+0x14b/0x2a3 [ 10.067008] [<c1603c8d>] ? __schedule+0x15c/0x4fe [ 10.067016] [<c1604104>] ? preempt_schedule_common+0x19/0x3c [ 10.067027] [<c11051de>] ? do_init_module+0x17/0x230 [ 10.067035] [<c1604139>] ? _cond_resched+0x12/0x1a [ 10.067044] [<c116f9aa>] ? kmem_cache_alloc+0x8f/0x11f [ 10.067052] [<c11051de>] ? do_init_module+0x17/0x230 [ 10.067060] [<c11703dd>] ? kfree+0x137/0x203 [ 10.067068] [<c110523d>] ? do_init_module+0x76/0x230 [ 10.067078] [<c10cadf3>] ? load_module+0x2a39/0x333f [ 10.067087] [<c10cb8b2>] ? SyS_finit_module+0x96/0xd5 [ 10.067096] [<c1132231>] ? vm_mmap_pgoff+0x79/0xa0 [ 10.067105] [<c1001e96>] ? do_fast_syscall_32+0xb5/0x1b0 [ 10.067114] [<c16086a6>] ? sysenter_past_esp+0x47/0x75 [ 10.067121] Code: c8 f7 76 c1 e8 8e cc d2 ff e9 45 fe ff ff 66 90 66 90 66 90 66 90 90 ff 00 7f 05 e8 4e 0c 00 00 c3 53 89 c3 e8 75 ec ff ff 89 d8 <ff> 08 79 05 e8 fa 0a 00 00 5b c3 53 89 c3 85 c0 74 1b 8b 03 83 [ 10.067180] EIP: [<c16054b4>] mutex_lock+0xa/0x15 SS:ESP 0068:f5971b58 [ 10.067190] CR2: 0000000000000104 [ 10.067222] ---[ end trace 049f1f09da45a856 ]--- Reported-by: Meelis Roos <mroos@linux.ee> Fixes: 580d8ed522e0 ("drm/i915: Give encoders useful names") Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160823092558.14931-1-chris@chris-wilson.co.uk
2016-08-23drm/i915: Convert intel_dvo to use atomic stateMaarten Lankhorst
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-10-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-23drm/i915: Make encoder->compute_config take the connector stateMaarten Lankhorst
Some places iterate over connector_state to find the right connector, pass it along as argument. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-7-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-23drm/i915: Pass crtc_state and connector_state to encoder functionsMaarten Lankhorst
This is mostly code churn, with exception of a few places: - intel_display.c has changes in intel_sanitize_encoder - intel_ddi.c has intel_ddi_fdi_disable calling intel_ddi_post_disable, and required a function change. Also affects intel_display.c - intel_dp_mst.c passes a NULL crtc_state and conn_state to intel_ddi_post_disable for shutting down the real encoder. If we would pass conn_state, then conn_state->connector != intel_dig_port->connector and conn_state->best_encoder != to_intel_encoder(intel_dig_port). We also shouldn't pass crtc_state, because in that case the disabling sequence may potentially be different depending on which crtc is disabled last. Nice way to introduce bugs. No other functional changes are done, diff stat is already huge. Each encoder type will need to be fixed to use the atomic states separately. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470755054-32699-6-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-07-04drm/i915: Mass convert dev->dev_private to to_i915(dev)Chris Wilson
Since we now subclass struct drm_device, we can save pointer dances by noting the equivalence of struct drm_device and struct drm_i915_private, i.e. by using to_i915(). text data bss dec hex filename 1073824 4562 416 1078802 107612 drivers/gpu/drm/i915/i915.ko 1068976 4562 416 1073954 106322 drivers/gpu/drm/i915/i915.ko Created by the coccinelle script: @@ expression E; identifier p; @@ - struct drm_i915_private *p = E->dev_private; + struct drm_i915_private *p = to_i915(E); Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467628477-25379-1-git-send-email-chris@chris-wilson.co.uk
2016-06-24drm/i915: Move connector registration to driver registrationChris Wilson
Defer connector registration from during construction to the driver registration phase. This is important for ordering the action correctly, e.g. not using debugfs before it is ready. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-4-git-send-email-chris@chris-wilson.co.uk
2016-06-24drm/i915: Move backlight registration to connector registrationChris Wilson
Currently the backlight is being registered in the load phase (before the display and its objects are registered). Move the backlight registration into the analogous phase by performing it from the connector registration, just after its creation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-3-git-send-email-chris@chris-wilson.co.uk
2016-06-19drm/i915: Move intel_connector->unregister to connector->early_unregisterChris Wilson
We now have a connector->func that serves the same purpose as our own intel_connector->unregister vfunc allowing us to unwrap ourselves and use drm_connector_register() (and friends) as the central function. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466160034-12173-2-git-send-email-chris@chris-wilson.co.uk
2016-06-10drm: i915: Rely on the default ->best_encoder() behavior where appropriateBoris Brezillon
For all outputs except dp_mst, we have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() implementation and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1465300095-16971-7-git-send-email-boris.brezillon@free-electrons.com
2016-05-30drm/i915: Give encoders useful namesVille Syrjälä
Rather than let the core generate usless encoder names, let's pass in something that actually identifies the piece of hardware we're dealing with. v2: Use 'DSI %c' instead of 'MIPI %c' for DSI encoders (Jani) v3: Use port_name() in DSI code since we have it Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464371966-15190-7-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2015-12-11drm: Pass 'name' to drm_encoder_init()Ville Syrjälä
Done with coccinelle for the most part. However, it thinks '...' is part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder in its place and got rid of it with sed afterwards. @@ identifier dev, encoder, funcs; @@ int drm_encoder_init(struct drm_device *dev, struct drm_encoder *encoder, const struct drm_encoder_funcs *funcs, int encoder_type + ,const char *name, int DOTDOTDOT ) { ... } @@ identifier dev, encoder, funcs; @@ int drm_encoder_init(struct drm_device *dev, struct drm_encoder *encoder, const struct drm_encoder_funcs *funcs, int encoder_type + ,const char *name, int DOTDOTDOT ); @@ expression E1, E2, E3, E4; @@ drm_encoder_init(E1, E2, E3, E4 + ,NULL ) v2: Add ', or NULL...' to @name kernel doc (Jani) Annotate the function with __printf() attribute (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449670818-2966-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18drm/i915: Type safe register read/writeVille Syrjälä
Make I915_READ and I915_WRITE more type safe by wrapping the register offset in a struct. This should eliminate most of the fumbles we've had with misplaced parens. This only takes care of normal mmio registers. We could extend the idea to other register types and define each with its own struct. That way you wouldn't be able to accidentally pass the wrong thing to a specific register access function. The gpio_reg setup is probably the ugliest thing left. But I figure I'd just leave it for now, and wait for some divine inspiration to strike before making it nice. As for the generated code, it's actually a bit better sometimes. Eg. looking at i915_irq_handler(), we can see the following change: lea 0x70024(%rdx,%rax,1),%r9d mov $0x1,%edx - movslq %r9d,%r9 - mov %r9,%rsi - mov %r9,-0x58(%rbp) - callq *0xd8(%rbx) + mov %r9d,%esi + mov %r9d,-0x48(%rbp) callq *0xd8(%rbx) So previously gcc thought the register offset might be signed and decided to sign extend it, just in case. The rest appears to be mostly just minor shuffling of instructions. v2: i915_mmio_reg_{offset,equal,valid}() helpers added s/_REG/_MMIO/ in the register defines mo more switch statements left to worry about ring_emit stuff got sorted in a prep patch cmd parser, lrc context and w/a batch buildup also in prep patch vgpu stuff cleaned up and moved to a prep patch all other unrelated changes split out v3: Rebased due to BXT DSI/BLC, MOCS, etc. v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18drm/i915: Store DVO SRCDIM register offset under intel_dvo_deviceVille Syrjälä
Store the DVO SRCDIM register offset alongside the DVO control register offset in intel_dvo_device. This gets rid of the switch statement whose case values are the DVO control register offsets. Such a construct would cause problems for register type safety. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-12-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2015-09-30drm/i915: Constify adjusted_modeVille Syrjälä
Make adjusted_mode const whereever we don't have to modify it. This only covers cases when we have a local adjusted_mode variable, and doesn't make any difference for cases where we just dereference pipe_config->adjusted_mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-30drm/i915: Always use crtc_ timings when dealing with adjustead_modeVille Syrjälä
The adjustead_mode crtc_ timings are what we will program into the hardware, so it's those timings we should be looking practically everywhere. The normal and crtc_ timings should differ only when stere doubling is used. In that case the normal timings are the orignal non-doubled timigns, and crtc_ timings are the doubled timings used by the hardware. The only case where we continue to look at the normal timings is when we pass the adjusted_mode to drm_match_{cea,hdmi}_mode() to find the VIC. drm_edid keeps the modes aronund in the non-double form only, so it needs the non-double timings to match against. Done with sed 's/adjusted_mode->\([vhVH]\)/adjusted_mode->crtc_\1/g' 's/adjusted_mode->clock/adjusted_mode->crtc_clock/g' with a manual s/VDisplay/vdisplay/ within the comment in intel_dvo.c v2: Update due to intel_dsi.c changes Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-30drm/i915: Use intel_panel for DVO fixed mode handlingVille Syrjälä
Replace intel_dvo->panel_fixed_mode with the appropriate intel_panel stuff. Now all connectors that have a fixed mode use intel_panel. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-26drm/i915: DVO pixel clock checkMika Kahola
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to DVO. V2: - removed computation for max pixel clock V3: - cleanup by removing unnecessary lines V4: - clock check against max dotclock moved inside 'if (fixed_mode)' V5: - dot clock check against fixed_mode clock when available Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-14drm/i915: Get rid of dpms handling.Maarten Lankhorst
This is now done completely atomically. Keep connectors_active for now, but make it mirror crtc_state->active. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-14drm/i915: Validate the state after an atomic modeset only, and pass the state.Maarten Lankhorst
First step in removing dpms and validating atomic state. There can still be a mismatch in the connector state because the dpms callbacks are still used, but this can not happen immediately after a modeset. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-27drm: Make the connector dpms callback return a value, v2.Maarten Lankhorst
This is required to properly handle failing dpms calls. When making a wait in i915 interruptible, I've noticed that the dpms sequence could fail with -ERESTARTSYS because it was waiting interruptibly for flips. So from now on allow drivers to fail in their connector dpms callback. Encoder and crtc dpms callbacks are unaffected. Changes since v1: - Update kerneldoc for the drm helper functions. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Resolve conflicts due to different merge order.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-29drm/i915: Silence compiler warning in dvoChris Wilson
drivers/gpu/drm/i915/intel_dvo.c: In function ‘intel_dvo_init’: drivers/gpu/drm/i915/intel_dvo.c:531:8: warning: array subscript is above array bounds [-Warray-bounds] gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix and gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.8/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-04-13drm/i915: Allocate connector state together with the connectorsAnder Conselvan de Oliveira
Connector states were being allocated in intel_setup_outputs() in loop over all connectors. That meant hot-added connectors would have a NULL state. Since the change to use a struct drm_atomic_state for the legacy modeset, connector states are necessary for the i915 driver to function properly, so that would lead to oopses. v2: Fix test for intel_connector_init() success in lvds and sdvo (PRTS) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reported-and-tested-by: Nicolas Kalkhof <nkalkhof@web.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-01drm/i915: base gmbus pin validity check on the gmbus pin map arrayJani Nikula
This will be helpful for adding future platforms. It is better to keep the information in the single point of truth (the table) instead of duplicating it into the validity function. While at it, add dev_priv parameter to the function, also to prepare for adding future platform support. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-01drm/i915: refer to pin instead of port in the intel_i2c.c interfacesJani Nikula
Rename intel_gmbus_is_port_valid to intel_gmbus_is_valid_pin, and rename port parameters to pin as well. This matches usage all around, as usually a pin is passed to the validity check function. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-01drm/i915: rename GMBUS_PORT_* macros as GMBUS_PIN_*Jani Nikula
The specs refer to pin pairs. Start moving towards using pin rather than port all around to avoid confusion. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-31drm/i915: Enable DVO 2x clock around DVO encoder initVille Syrjälä
ns2501 requires the DVO 2x clock before it will respond to i2c access, so make sure the clock is enabled when we try to initialize the encoder. Fixes the display getting lost on module reload on my Fujitsu/Siemens Lifebook S6010. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-26drm/i915: Implement connector state duplicationAnder Conselvan de Oliveira
So that we can add connector states to the drm_atomic_state used in the legacy modeset. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Add atomic_get_property entrypoint for connectors (v2)Matt Roper
Even though we only support atomic plane updates at the moment, we still need to add an .atomic_get_property() entrypoint for connectors before we allow the driver to flip on the DRIVER_ATOMIC bit. As soon as that bit gets set, the DRM core will start adding atomic connector properties (in addition to the plane properties we care about at the moment), so we need to be able to handle the new way the DRM core will interact with us. For simplicity, we just lookup driver-specific connector properties in the usual shadow array maintained by the core. Once we get real atomic modeset support for crtc's and planes, this code should be re-written to pull the data out of crtc/connector state structures. v2: Fix intel_dvo and intel_dsi that I missed on the first pass (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Setup dummy atomic state for connectors (v3)Matt Roper
We want to enable/test plane updates via the atomic interface, but as soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic codepaths to lookup properties during drmModeGetConnector() and some of those codepaths unconditionally dereference connector->state (specifically when looking up the CRTC ID property in drm_atomic_connector_get_property()). Create a dummy connector state for each connector at init time to ensure the DRM core doesn't try to dereference a NULL connector->state. The actual connector properties will never be updated or contain useful information, but since we're doing this specifically for testing/debug of the plane operations (and only when a specific kernel module option is given), that shouldn't really matter. Once we start creating connector states, the DRM core will want to be able to clean them up for us. We also need to hook up the destruction entrypoint to the core's helper. v2: Squash in the patch to set the state destruction hook (Ander & Bob) v3: Only create dummy connector states when we're actually faking atomic support. (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Make intel_crtc->config a pointerAnder Conselvan de Oliveira
To match the semantics of drm_crtc->state, which this will eventually become. The allocation of the memory for config will be fixed in a followup patch. By adding the extra _config field to intel_crtc it was possible to generate this entire patch with the cocci script below. @@ @@ struct intel_crtc { ... -struct intel_crtc_state config; +struct intel_crtc_state _config; +struct intel_crtc_state *config; ... } @@ struct intel_crtc *crtc; @@ -memset(&crtc->config, 0, sizeof(crtc->config)); +memset(crtc->config, 0, sizeof(*crtc->config)); @@ @@ __intel_set_mode(...) { <... -to_intel_crtc(crtc)->config = *pipe_config; +(*(to_intel_crtc(crtc)->config)) = *pipe_config; ...> } @@ @@ intel_crtc_init(...) { ... WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe); +intel_crtc->config = &intel_crtc->_config; return; ... } @@ struct intel_crtc *crtc; @@ -&crtc->config +crtc->config @@ struct intel_crtc *crtc; identifier member; @@ -crtc->config.member +crtc->config->member @@ expression E; @@ -&(to_intel_crtc(E)->config) +to_intel_crtc(E)->config @@ expression E; identifier member; @@ -to_intel_crtc(E)->config.member +to_intel_crtc(E)->config->member v2: Clarify manual changes by splitting them into another patch. (Matt) Improve cocci script to generate even more of the changes. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Embedded struct drm_crtc_state in intel_crtc_stateAnder Conselvan de Oliveira
And get rid of the duplicate mode structures. This patch was generated with the following semantic patch: @@ @@ struct intel_crtc_state { +struct drm_crtc_state base; + ... -struct drm_display_mode requested_mode; -struct drm_display_mode adjusted_mode; ... } @@ struct intel_crtc_state *state; @@ -state->adjusted_mode +state->base.adjusted_mode @@ struct intel_crtc_state *state; @@ -state->requested_mode +state->base.mode @@ struct intel_crtc_state state; @@ -state.adjusted_mode +state.base.adjusted_mode @@ struct intel_crtc_state state; @@ -state.requested_mode +state.base.mode @@ struct drm_crtc *crtc; @@ -to_intel_crtc(crtc)->config.adjusted_mode +to_intel_crtc(crtc)->config.base.adjusted_mode @@ identifier member; expression E; @@ -PIPE_CONF_CHECK_FLAGS(adjusted_mode.member, E); +PIPE_CONF_CHECK_FLAGS(base.adjusted_mode.member, E); @@ identifier member; @@ -PIPE_CONF_CHECK_I(adjusted_mode.member); +PIPE_CONF_CHECK_I(base.adjusted_mode.member); @@ identifier member; @@ -PIPE_CONF_CHECK_CLOCK_FUZZY(adjusted_mode.member); +PIPE_CONF_CHECK_CLOCK_FUZZY(base.adjusted_mode.member); v2: Completely generate the patch with cocci. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Rename struct intel_crtc_config to intel_crtc_stateAnder Conselvan de Oliveira
The objective is to make this structure usable with the atomic helpers, so let's start with the rename. Patch generated with coccinelle: @@ @@ -struct intel_crtc_config { +struct intel_crtc_state { ... } @@ @@ -struct intel_crtc_config +struct intel_crtc_state v2: Completely generate the patch with cocci. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-03drm/i915: Don't call DVO mode_set hook on DPMS changesVille Syrjälä
Calling the mode_set hook on DPMS changes doesn't seem to be necessary for ns2501. Just drop it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-03drm/i915: Enable DVO between mode_set and dpms hooksVille Syrjälä
To more closely match the IEGD ns2501 driver behaviour, call the mode_set hook while the DVO port is still disabled, then enable the DVO port, and finally call the dpms hook. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-09-03drm/i915: ns2501 is on DVOBVille Syrjälä
On Fujitsu-Siememens S6010 the ns2501 chip is hooked up to DVOB instead of DVOC. FIXME: Maybe need to dig out the correct DVO port from VBT Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-07-09Merge tag 'drm-intel-next-2014-06-20' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-next - Accurate frontbuffer tracking and frontbuffer rendering invalidate, flush and flip events. This is prep work for proper PSR support and should also be useful for DRRS&fbc. - Runtime suspend hardware on system suspend to support the new SOix sleep states, from Jesse. - PSR updates for broadwell (Rodrigo) - Universal plane support for cursors (Matt Roper), including core drm patches. - Prefault gtt mappings (Chris) - baytrail write-enable pte bit support (Akash Goel) - mmio based flips (Sourab Gupta) instead of blitter ring flips - interrupt handling race fixes (Oscar Mateo) And old, not yet merged features from the previous round: - rps/turbo support for chv (Deepak) - some other straggling chv patches (Ville) - proper universal plane conversion for the primary plane (Matt Roper) - ppgtt on vlv from Jesse - pile of cleanups, little fixes for insane corner cases and improved debug support all over * tag 'drm-intel-next-2014-06-20' of git://anongit.freedesktop.org/drm-intel: (99 commits) drm/i915: Update DRIVER_DATE to 20140620 drivers/i915: Fix unnoticed failure of init_ring_common() drm/i915: Track frontbuffer invalidation/flushing drm/i915: Use new frontbuffer bits to increase pll clock drm/i915: don't take runtime PM reference around freeze/thaw drm/i915: use runtime irq suspend/resume in freeze/thaw drm/i915: Properly track domain of the fbcon fb drm/i915: Print obj->frontbuffer_bits in debugfs output drm/i915: Introduce accurate frontbuffer tracking drm/i915: Drop schedule_back from psr_exit drm/i915: Ditch intel_edp_psr_update drm/i915: Drop unecessary complexity from psr_inactivate drm/i915: Remove ctx->last_ring drm/i915/chv: Ack interrupts before handling them (CHV) drm/i915/bdw: Ack interrupts before handling them (GEN8) drm/i915/vlv: Ack interrupts before handling them (VLV) drm/i915: Ack interrupts before handling them (GEN5 - GEN7) drm/i915: Don't BUG_ON in i915_gem_obj_offset drm/i915: Grab dev->struct_mutex in i915_gem_pageflip_info drm/i915: Add some L3 registers to the parser whitelist ... Conflicts: drivers/gpu/drm/i915/i915_drv.c
2014-06-19drm: add register and unregister functions for connectorsThomas Wood
Introduce generic functions to register and unregister connectors. This provides a common place to add and remove associated user space interfaces. Signed-off-by: Thomas Wood <thomas.wood@intel.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-13drm/i915: Don't get hw state from DVO chip unless DVO is enabledVille Syrjälä
Certain DVO chips (ns2501 for example) don't like to be accessed unless the PLL is running. Simply skip the DVO get_hw_state if the DVO port is disabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-06-04drm/i915: replace drm_get_connector_name() with direct name field useJani Nikula
Generated using semantic patches: @@ expression E; @@ - drm_get_connector_name(&E) + E.name @@ expression E; @@ - drm_get_connector_name(E) + E->name v2: Turn drm_get_connector_name(&E) into E.name instead of &(E)->name. Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-05-05drm/i915/dvo: Remove ->mode_set callbackDaniel Vetter
Currently for the i9xx crtc hooks there's nothing between the call to encoder->mode_set and encoder->pre_enable which touches the hardware. Therefore, since dvo is only used on gen2, we can just move the hook. Yay for easy cases! The only other important thing to check is that the new ->pre_enable hook is idempotent wrt the sw state since now it can be called multiple times (due to DPMS). It only reads crtc->config but otherwise leaves it as-is, so we're good. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-10drm/i915: Make encoder cloning more flexibleVille Syrjälä
Currently we allow encoders to indicate whether they can be part of a cloned set with just one flag. That's not flexible enough to describe the actual hardware capabilities. Instead make it a bitmask of encoder types with which the current encoder can be cloned. For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should match what the old boolean flag allowed. We will add some more cloning options in the future. Note that this patch also removes the encoder.possible_clones setting from encoder setup code - we compute this dynamically. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add Ville's explanation why removing the encoder possible_clones is save.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-02-14drm/i915: add unregister callback to connectorImre Deak
Since commit d9255d57147e1dbcebdf6670409c2fa0ac3609e6 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date:   Thu Sep 26 20:05:59 2013 -0300 it became clear that we need to separate the unload sequence into two parts: 1. remove all interfaces through which new operations on some object (crtc, encoder, connector) can be started and make sure all pending operations are completed 2. do the actual tear down of the internal representation of the above objects The above commit achieved this separation for connectors by splitting out the sysfs removal part from the connector's destroy callback and doing this removal before calling drm_mode_config_cleanup() which does the actual tear-down of all the drm objects. Since we'll have to customize the interface removal part for different types of connectors in the upcoming patches, add a new unregister callback and move the interface removal part to it. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-28drm/i915: Return a drm_mode_status enum in the mode_valid vfuncsDamien Lespiau
We had some mode_valid() vfuncs returning an int, others the enum. Let's use the latter everywhere. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-04drm/i915/dvo: call ->mode_set callback only when the port is runningDaniel Vetter
The ns2501 controller seems to need the dpll and dvo port to accept the timing update commands. Quick testing on my x30 here seems to indicate that other dvo controllers don't mind. So let's move the ->mode_set callback to a place where we have the port up and running already. Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Thomas Richter <thor@math.tu-berlin.de> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-01drm/i915: destroy connector sysfs files earlierPaulo Zanoni
For some reason, every single time I try to run module_reload something tries to read the connector sysfs files. This happens after we destroy the encoders and before we destroy the connectors, so when the sysfs read triggers the connector detect() function, intel_conector->encoder points to memory that was already freed. The bad backtrace is just: [<ffffffff8163ca9a>] dump_stack+0x54/0x74 [<ffffffffa00c2c8e>] intel_dp_detect+0x1e/0x4b0 [i915] [<ffffffffa001913d>] status_show+0x3d/0x80 [drm] [<ffffffff813d5340>] dev_attr_show+0x20/0x60 [<ffffffff81221f50>] ? sysfs_read_file+0x80/0x1b0 [<ffffffff81221f79>] sysfs_read_file+0xa9/0x1b0 [<ffffffff811aaf1e>] vfs_read+0x9e/0x170 [<ffffffff811aba4c>] SyS_read+0x4c/0xa0 [<ffffffff8164e392>] system_call_fastpath+0x16/0x1b But if you add tons of memory checking debug options to your Kernel you'll also see: - general protection fault: 0000 - BUG kmalloc-4096 (Tainted: G D W ): Poison overwritten - INFO: Allocated in intel_ddi_init+0x65/0x270 [i915] - INFO: Freed in intel_dp_encoder_destroy+0x69/0xb0 [i915] Among a bunch of other error messages. So this commit just destroys the sysfs files before both the encoder and connectors are freed. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit (git 2.34.1) at 2024-06-15 09:30:50 +0000