- 19 Sep, 2013 3 commits
-
-
Daniel Vetter authored
I always get royally confused how a modeline with all zeros could possible pass the paranoid pipe config checker. Until I realize again that we only check the crtc timings. So dump the crtc timings for the adjusted mode. This will be even more important for 3D support where the crtc timings are markedly different from the input modeline if we have frame-by-frame 3d output enabled. Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Ville and I were wondering why his laptop was missing the intel_backlight sysfs interface. Turns out we never register it when CONFIG_BACKLIGHT_CLASS_DEVICE=m. This has been broken ever since the i915 native backlight interface was added. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Paulo Zanoni authored
You can't write it using the MCHBAR mirror, the write will just get dropped. This should make us BSpec-compliant, but there's no real bug I could reproduce that is fixed by this patch. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
- 17 Sep, 2013 14 commits
-
-
Paulo Zanoni authored
Sometimes I see the "non asle set request??" message on my Haswell machine, so I decided to get the spec and see if some bits are missing from the mask. We do have some bits missing from the mask, so this patch adds them, and the corresponding code to print "unsupported" messages just like we do with the other bits we don't support. But I still see the "non asle set request??" message on my machine :( Also use the proper ASLC name to indicate the registers we're talking about. v2: - Properly set the new FAILED bits - Rename the old FAILED bits - Print everything we don't support Signed-off-by: -
Jani Nikula authored
This reduces dmesg noise when there's a glitch on the hpd line, or there are more than one connectors on the same hpd line and only one of them changes. While at it, switch to use the friendly status names instead of numbers. Signed-off-by:
-
Paulo Zanoni authored
So far we control everything and nothing exceeds the current limits, but (i) we never think about these limits when reviewing patches, (ii) not all the callers check the return values and (iii) if we ever hit any of these messages, we'll have to fix the code that added the bad message. The current limit for these messages is 20 since we only have 5 data registers on all the current gens. The checks inside intel_dp_aux_native_{write,read} are to prevent buffer overflows. The check inside intel_dp_aux_ch is to prevent writing past our 5 data registers. Signed-off-by: -
Ville Syrjälä authored
Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Double wide mode is only available on pipe A, except on GDG where pipe B is also double wide capable. Signed-off-by:
-
Ville Syrjälä authored
Pipe horizontal source size must be even when either LVDS dual channel mode, DVO ganged mode, or pipe double wide mode is used. We must round it down since we can never increase the user specified viewport size. The actual error from an odd pipe source width looks like a diagonal shift, like you might get from a bad stride. v2: s/ganaged/ganged/ Signed-off-by:
-
Ville Syrjälä authored
We don't want to try to push the hardware beyond it's capabilities, so check the pixel clock against the display core clock limit. Do it for pre-gen4 for now since that's where we alread have the double wide pixel clock limit check. Let's assume that when double wide mode is enabled the max pixel clock limit is also doubled. FIXME: panel fitter downscaling probably affects the limit on non-pch platforms too, so we'd need another version of ilk_pipe_pixel_rate() to figure that out. FIXME: should check the limits on all platforms. Also sprites affect the max allowed pixel rate on some platforms, so we need to eventually tie all the planes and pipes into one check in the future. But we need plane state pre-compute before that can happen. Signed-off-by:
-
Ville Syrjälä authored
Read the double wide pipe information from hardware in i9xx_get_pipe_config(), and check it in intel_pipe_config_compare() For gen4+ double_wide is always false so the comparison can be done on all platforms. Signed-off-by:
-
Ville Syrjälä authored
Determine the need for double wide mode already in compute_config stage as we need that information to figure out if horizontal coordinates need to be adjusted. Signed-off-by:
-
Daniel Vetter authored
Simply inline the 100MHz default we're using. Having gunk around that has leftover LVDS support on a platform that just doesn't have this isn't of any use. Reviewed-by:
-
Ville Syrjälä authored
First of all we should not be looking at fb->{width,height} as those do not tell us what the actual pipe size is. Second of all we need to use >= for the comparison. So fix the comparison, and make use of the new pipe_src_{w,h} to determine the real pipe source dimensions. Reviewed-by:Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
When the cursor x coordinate is exactly -cursor_width, the cursor is invisible. And obviously the same holds for the y coordinate and cursor_height. Reviewed-by:
-
Ville Syrjälä authored
Try to clarify the purpose of requested_mode. Signed-off-by:
-
Daniel Vetter authored
Especially intel_gmch_panel_fitting was shifting way too much over the right edge and also was way too long. So extract two helpers, one for gen4+ and one for gen2/3. Now the entire thing is again almost readable ... Spurred by checkpatch freaking out about a Ville's pipeconfig rework in intel_panel.c Otherwise just two lines that needed appropriate breaking. Not functional change in this patch. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
- 16 Sep, 2013 17 commits
-
-
Ville Syrjälä authored
Rather that mess about with hdisplay/vdisplay from requested_mode, add explicit pipe src size information to pipe config. Now requested_mode is only really relevant for dvo/sdvo output timings. For everything else either adjusted_mode or pipe src size should be used. In many places where we end up using pipe source size, we should actually use the primary plane size, but we don't currently store that information explicitly. As long as we treat primaries as full screen only, we can get away with this. Eventually when we move primaries over to drm_plane, we need to fix it all up. v2: Add a comment to explain what pipe_src_{w,h} are Add a note about primary planes to commit message Signed-off-by: -
Ville Syrjälä authored
adjusted_mode contains our real timings, not requested_mode. Use the correct thing in DSI PLL code. Also constify adjusted_mode since we don't change it. Signed-off-by:
-
Ville Syrjälä authored
Rather than dig up the pipe source size from crtc->mode, use intel_crtc->config.requested_mode. Signed-off-by:
-
Ville Syrjälä authored
Move intel_crtc_active() to intel_display.c and make it available elsewhere as well. intel_edp_psr_match_conditions() already has one open coded copy, so replace that one with a call to intel_crtc_active(). v2: Copy paste a big comment from danvet's mail explaining when we can ditch the extra checks Signed-off-by: -
Ville Syrjälä authored
intel_edp_psr_match_conditions() currently looks at crtc->mode when it really needs to look at adjusted_mode. Fix it. Signed-off-by:
-
Ville Syrjälä authored
The clock in crtc->mode doesn't necessarily mean anything. Let's look at the clock in adjusted_mode instead. Signed-off-by:
-
Ville Syrjälä authored
Currently most of the watermark code looks at crtc->mode which is the user requested mode. The only piece of information there that is relevant is hdisplay, the rest must come from adjusted_mode. Convert all of the code to use requested_mode and adjusted_mode from pipe config appropriately. Signed-off-by:
-
Ville Syrjälä authored
Check the mode flags from the adjusted_mode, not user requested mode. The hdisplay/vdisplay check actually checkes the primary plane size, so those still need to come from the user requested mode. Extract both modes from pipe config instead of the drm_crtc. Signed-off-by:
-
Ville Syrjälä authored
The pixel clock should come from adjusted_mode not requested_mode. In this case the two should be the same as we don't currently overwrite the clock in the case of HDMI. But let's make the code safe against such things happening in the future. Signed-off-by:
-
Ville Syrjälä authored
lpt_program_iclkip() wants to know the pixel clock. It should get that information from adjusted_mode, not crtc->mode. Signed-off-by:
-
Ville Syrjälä authored
i9xx_set_pipeconf() attempts to get the current pixel clock from requested_mode. requested_mode.clock may be totally bogus, so the clock should come from adjusted_mode. v2: Dropped the intel_compute_config() hunk due to killing of the INTEL_FDI_FREQ check Signed-off-by: -
Ville Syrjälä authored
Check and dump for port_clock. v2: Also dump port_clock Reviewed-by:
-
Ville Syrjälä authored
Add a new pipe config check macro PIPE_CONF_CHECK_CLOCK_FUZZY() to make it trivial and error proof to compare clocks in a fuzzy manner. v2: Drop extra curly braces Reviewed-by:
-
Ville Syrjälä authored
Now that adjusted_mode.clock no longer contains the pixel_multiplier, we can kill the get_clock() callback and instead do the clock readout in get_pipe_config(). Also i9xx_crtc_clock_get() can now extract the frequency of the PCH DPLL, so use it to populate port_clock accurately for PCH encoders. For DP in port A the encoder is still responsible for filling in port_clock. The FDI adjusted_mode.clock extraction is kept in place for some extra sanity checking, but we no longer need to pretend it's also the port_clock. In the encoder get_config() functions fill out adjusted_mode.clock based on port_clock and other details such as the DP M/N values, HDMI 12bpc and SDVO pixel_multiplier. For PCH encoders we will then do an extra sanity check to make sure the dotclock we derived from the FDI configuratiuon matches the one we derive from port_clock. DVO doesn't exist on PCH platforms, so it doesn't need to anything but assign adjusted_mode.clock=port_clock. And DDI is HSW only, so none of the changes apply there. v2: Use hdmi_reg color format to detect 12bpc HDMI case v3: Set adjusted_mode.clock for LVDS too v4: Rename ironlake_crtc_clock_get to ironlake_pch_clock_get, eliminate the useless link_freq variable. Signed-off-by: -
Ville Syrjälä authored
Add the 120MHz refernce clock case for PCH DPLLs. Also determine the reference clock frequency more accurately by checking for the PLLB_REF_INPUT_SPREADSPECTRUMIN refclk input mode. The gen2 code already checked it, but it stil assumed a fixed 66MHz refclk. Instead we need to consult the VBT for the real value. v2: Fix refclk for SSC panel case Signed-off-by:
-
Ville Syrjälä authored
We already extract the DPLL state to pipe_config, so let's make use of it in i9xx_crtc_clock_get() and avoid the register reads. This will also make the function closer to being useable with PCH DPLL since the registers for those live in a different address. Also kill the useless adjusted_mode.clock zeroing. It's already zero at this point. v2: Read out DPLL state in intel_crtc_mode_get() Signed-off-by:
-
Ville Syrjälä authored
Extract the code to calculate the dotclock from the link clock and M/N values into a new function from ironlake_crtc_clock_get(). The new function can be used to calculate the dotclock for both FDI and DP cases. Also simplify the code a bit along the way. v2: Don't forget about non-pch encoders in ironlake_crtc_clock_get() Signed-off-by:
-
- 13 Sep, 2013 6 commits
-
-
Paulo Zanoni authored
We don't seem to be using the pointer after it's unmapped, so this patch doesn't fix any bug I can reproduce. Signed-off-by:
-
Jani Nikula authored
The cursor is supposed to be disabled during crtc mode set (disabled by ctrc disable). Assert this is the case. v2: move cursor disabled assert next to plane asserts (Ville) Suggested-by:
-
Ben Widawsky authored
The buf pointer used during l3_write is just char *, therefore it does not require the silly any addition of offset. v2: Also fix i915_l3_read with a suggested logic from Ville Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
Ben Widawsky authored
We always read a register for l3 parity reads, and we don't really want to ever let userspace trick us into giving back less than the dword. Writes are okay because we assume everything will be 0 filled, and as such, if a user really wants to write less than a dword, let them. Signed-off-by:
-
Ben Widawsky authored
Sadly, this isn't the first time we've done this: http://lists.freedesktop.org/archives/intel-gfx/2013-June/029065.htmlSigned-off-by:
-
Ville Syrjälä authored
We want to do fuzzy clock checks for other things besides adjusted_mode.clock, so just pass two two clocks to compare to intel_fuzzy_clock_check(). Reviewed-by:
-
