IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
GEN supports a fusing option which subtracts the PCH display (making the
CPU display also useless). In this configuration MMIO which gets decoded
to a certain range will hang the CPU.
For us, this is sort of the equivalent of having no pipes, and we can
easily modify some code to not do certain things with no pipes.
v2: Moved the num pipes check up in the call chain, and removed extra
checks noted by Daniel. For more details, see:
http://lists.freedesktop.org/archives/intel-gfx/2013-March/025746.html
v3: Drop the intel_setup_overlay check (Daniel)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise running igt will fill your dmesg with hang notices and it's
hard to judge from a quick look whether they're expected or not.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The behaviour around handling the eDP bpp value from vbt has been
slightly changed in
commit 3600836585e3fdef0a1410d63fe5ce4015007aac
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Mar 27 00:44:59 2013 +0100
drm/i915: convert DP autodither code to new infrastructure
The old behaviour was that we used the plane's bpp (usually 24bpp) for
computing the dp link bw, but set up the pipe with the bpp value from
vbt if available. This takes the vbt bpp override into account even
for the dp link bw configuration.
On Paulo's hsw machine this resulted in a slower link clock and a
black screen - but the mode actually /should/ fit even with the lower
clock. Until we've cleared up simply stay bug-for-bug compatible with
the old code.
While at it, also restore a debug message lost in:
commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Mar 27 00:44:58 2013 +0100
drm/i915: precompute pipe bpp before touching the hw
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit deb18211a110c102d32b3e9ed866bd7d25e0f8d5.
It completely breaks the logic, since when we fall through to the end
of the function we actually _have_ figured out the correct pipe.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV docs still list the the color range selection bit for the HDMI
ports, but for DP ports it has been repurposed.
I have no idea whether the HDMI color range selection bit still works
on VLV, but since we now have to use the PIPECONF color range bit for
DP, we might as well do the same for HDMI.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV has the color range selection bit in the PIPECONF register.
Configure it appropriately.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: fixup rebase issues due to slightly different baseline.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900
mini desktop PCs are probably misleading the LVDS detection
code in intel_lvds_supported. Nothing is connected to the
LVDS ports in these systems.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
Highlights:
- Imre's for_each_sg_pages rework (now also with the stolen mem backed
case fixed with a hack) plus the drm prime sg list coalescing patch from
Rahul Sharma. I have some follow-up cleanups pending, already acked by
Andrew Morton.
- Some prep-work for the crazy no-pch/display-less platform by Ben.
- Some vlv patches, by far not all (Jesse et al).
- Clean up the HDMI/SDVO #define confusion (Paulo)
- gen2-4 vblank fixes from Ville.
- Unclaimed register warning fixes for hsw (Paulo). More still to come ...
- Complete pageflips which have been stuck in a gpu hang, should prevent
stuck gl compositors (Ville).
- pm patches for vt-switchless resume (Jesse). Note that the i915 enabling
is not (yet) included, that took a bit longer to settle. PM patches are
acked by Rafael Wysocki.
- Minor fixlets all over from various people.
* tag 'drm-intel-next-2013-03-23' of git://people.freedesktop.org/~danvet/drm-intel: (79 commits)
drm/i915: Implement WaSwitchSolVfFArbitrationPriority
drm/i915: Set the VIC in AVI infoframe for SDVO
drm/i915: Kill a strange comment about DPMS functions
drm/i915: Correct sandybrige overclocking
drm/i915: Introduce GEN7_FEATURES for device info
drm/i915: Move num_pipes to intel info
drm/i915: fixup pd vs pt confusion in gen6 ppgtt code
style nit: Align function parameter continuation properly.
drm/i915: VLV doesn't have HDMI on port C
drm/i915: DSPFW and BLC regs are in the display offset range
drm/i915: set conservative clock gating values on VLV v2
drm/i915: fix WaDisablePSDDualDispatchEnable on VLV v2
drm/i915: add more VLV IDs
drm/i915: use VLV DIP routines on VLV v2
drm/i915: add media well to VLV force wake routines v2
drm/i915: don't use plane pipe select on VLV
drm: modify pages_to_sg prime helper to create optimized SG table
drm/i915: use for_each_sg_page for setting up the gtt ptes
drm/i915: create compact dma scatter lists for gem objects
drm/i915: handle walking compact dma scatter lists
...
By having 'drm' and 'fb' in the fb screeninfo id, pm-utils will leave us
alone. Otherwise we'll have quirks up to our ears and resume will break.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Clock computations and handling are highly encoder specific, both in
the optimal clock selection and also in which clocks to use and when
sharing of clocks is possible.
So the best place to do this is somewhere in the encoders, with a
generic fallback for those encoders without special needs. To facility
this, add a pipe_config->clocks_set boolean.
This patch here is only prep work, it simply sets the computed clock
values in pipe_config->dpll, and uses that data in the hw clock
setting functions.
Haswell code isn't touched, simply because Haswell clocks work much
different and need their own infrastructure (with probably a
Haswell-specific config->ddi_clock substruct).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now we can ditch the checks in the Haswell disable code.
v2: add support for Haswell
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to be able to read out the hw state code for a bunch
of reasons:
- Correctly disabling boot-up/resume state.
- Pure paranoia.
Since not all of the pipe configuration is e.g. relevant for
fastboot (or at least we can allow some wiggle room in some
parameters, like the clocks), we need to add a strict_checking
parameter to intel_pipe_config_compare for fastboot.
For now intel_pipe_config_compare should be fully paranoid and
check everything that the hw state readout code supports. Which
for this infrastructure code is nothing.
I've gone a bit overboard with adding 3 get_pipe_config functions:
The ilk version will differ with the next patch, so it's not too
onerous.
v2: Don't check the hw config if the pipe is off, since an enabled,
but dpms off crtc will obviously have tons of difference with the hw
state.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The only exception left is is_cpu_edp in the haswell modeset code.
We need that to assign the cpu transcoder, but we might want to
move that eventually into the encoder, too.
\o/-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jesse Barnes noticed in his review of my DP cleanup series that
intel_edp_target_clock is now unused. Checking related code I've
noticed that also intel_edp_link_config is long unused.
Kill them both.
Wrt leaky eDP functions used in the common crtc code, the only thing
still left is intel_encoder_is_pch_edp. That one is just due to the
massive confusion between eDP vs. DP and port A vs. port D. Crtc code
should at most concern itself with the later, never with the former.
But that's material for another patch series.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need it in the fdi m_n computation, which nicely kills almost
all ugly special cases in there.
It looks like we also need this to handle 12bpc hdmi correctly.
Eventually it might be better to switch things around and put the
target clock into adjusted_mode->clock and create a new pipe_config
parameter for the port link clock.
v2: Add a massive comment in the code to explain this mess.
v3: s/dp_target_clock/pixel_target_clock in anticipation of the hdmi
use-case.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need a flag to designate dp encoders and the dp link m_n parameters
in the pipe config for that. And now that the pipe bpp computations
have been moved up and stored in the pipe config, too, we can do this
without losing our sanity.
v2: Rebased on top of Takashi Iwai's fix to (again) fix the target
clock handling for eDP. Luckily the new code is sane enough and just
does the right thing!
v3: Move ->has_dp_encoder to this patch (Jesse).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's a rather decent confusion going on around transcoder m_n
values. So let's clarify:
- All dp encoders need this, either on the pch transcoder if it's a
pch port, or on the cpu transcoder/pipe if it's a cpu port.
- fdi links need to have the right m_n values for the fdi link set in
the cpu transcoder.
To handle the pch vs transcoder stuff a bit better, extract transcoder
set_m_n helpers. To make them simpler, set intel_crtc->cpu_transcoder
als in ironlake_crtc_mode_set, so that gen5+ (where the cpu m_n
registers are all at the same offset) can use it.
Haswell modeset is decently confused about dp vs. edp vs. fdi. dp vs.
edp works exactly the same as dp (since there's no pch dp any more),
so use that as a check. And only set up the fdi m_n values if we
really have a pch encoder present (which means we have a VGA encoder).
On ilk+ we've called ironlake_set_m_n both for cpu_edp and for pch
encoders. Now that dp_set_m_n handles all dp links (thanks to the
pch encoder check), we can ditch the cpu_edp stuff from the
fdi_set_m_n function.
Since the dp_m_n values are not readily available, we need to
carefully coax the edp values out of the encoder. Hence we can't (yet)
kill this superflous complexity.
v2: Rebase on top of the ivb fdi B/C check patch - we need to properly
clear intel_crtc->fdi_lane, otherwise those checks will misfire.
v3: Rebased on top of a s/IS_HASWELL/HAS_DDI/ patch from Paulo Zanoni.
v4: Drop the addition of has_dp_encoder, it's in the wrong patch (Jesse).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRWLTrAAoJEHm+PkMAQRiGe8oH/iMy48mecVWvxVZn74Tx3Cef
xmW/PnAIj28EhSPqK49N/Ow6AfQToFKf7AP0ge20KAf5teTq95AY+tH74DAANt8F
BjKXXTZiR5xwBvRkq7CR5wDcCvEcBAAz8fgTEd6SEDB2d2VXFf5eKdKUqt1avTCh
Z6Hup5kuwX+ddtwY2DCBXtp2n6fL0Rm5yLzY1A3OOBye1E7VyLTF7M5BR603Q44P
4kRLxn8+R7jy3hTuZIhAeoS8TKUoBwVk7DmKxEzrhTHZVOmvwE9lEHybRnIyOpd/
k1JnbRbiPsLsCVFOn10SQkGDAIk00lro3tuWP2C1ljERiD/OOh5Ui9nXYAhMkbI=
=q15K
-----END PGP SIGNATURE-----
Merge tag 'v3.9-rc5' into drm-intel-next-queued
Backmerge Linux 3.9-rc5 since I want to merge a few dp clock cleanups
for -next, but they will conflict all over the place with
commit 9d1a455b0ca1c2c956b4d9ab212864a8695270f1
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Mar 18 11:25:36 2013 +0100
drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n()
from -fixes.
Conflicts:
drivers/gpu/drm/i915/intel_dp.c: Simply adjacent lines changed.
drivers/gpu/drm/i915/intel_panel.c: A field rename in -next
conflicts with a bugfix in -fixes. Take the version from
-fixes and apply the rename.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The active output is only the currently selected one, which does not
imply that it's actually enabled. Since we don't use the sdvo encoder
side dpms support, we need to check whether the chip-side sdvo port is
enabled instead.
v2: Fix up Bugzilla links.
v3: Simplify logic a bit (Chris).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60138
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63031
Cc: Egbert Eich <eich@pdx.freedesktop.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Egbert Eich <eich@pdx.freedesktop.org> (v2)
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If first drm_open fails, the error-handling path will
incorrectly restore inode's mapping to NULL. This can
cause the crash later on. Fix by separately storing
away mapping pointers that drm_open can touch and
restore each from its own respective variable if the
call fails.
Fixes: https://bugzilla.novell.com/show_bug.cgi?id=807850
(thanks to Michal Hocko for investigating investigating and
finding the root cause of the bug)
Reference:
http://lists.freedesktop.org/archives/dri-devel/2013-March/036564.html
v2: Use one variable to store file and inode mapping
since they are the same at the function entry.
Fix spelling mistakes in commit message.
v3: Add reference to the original bug report.
Reported-by: Marco Munderloh <munderl@tnt.uni-hannover.de>
Tested-by: Marco Munderloh <munderl@tnt.uni-hannover.de>
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
One locking regression fix, and a couple of other i915 ones.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm: don't unlock in the addfb error paths
drm/i915: Fix build failure
drm/i915: Be sure to turn hsync/vsync back on at crt enable (v2)
drm/i915: duct-tape locking when eDP init fails
We don't need this until we start using the wait event commands.
v2: move to i915_irq.c (Jesse)
drop unneeded sprite flip done enables (Ville)
v3: drop the DPFLIPSTAT enables altogether (Ville)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Slightly different than other platforms.
v2 [Jani]: Fix IOSF_BYTE_ENABLES_SHIFT shift. Use common routine.
v3: drop turbo defines from this patch (Ville)
use PCI_DEVFN(2,0) instead of open coding (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Add checkpatch bikeshed about missing space.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Needed to handle pre/post enable/disable paths on VLV and avoid a few
fields that are marked reserved on VLV.
v2: don't set color range or DP PLL fields (Jani)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Need to make sure sprites are disabled before shutting off a pipe.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No constant alpha yet though, that needs a new ioctl and/or property to
get/set.
v2: use drm_plane_format_cpp (Ville)
fix up vlv_disable_plane, remove IVB bits (Ville)
remove error path rework (Ville)
fix component order confusion (Ville)
clean up platform init (Ville)
use compute_offset_xtiled (Ville)
v3: fix up more format confusion (Ville)
update to new page offset function (Ville)
v4: remove incorrect formats from framebuffer_init (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we couldn't find a pipe we shouldn't return true. This might be even
better as a WARN though, since it should be impossible to have the port
enabled without a pipe selected.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we couldn't find a pipe we shouldn't return true. This might be even
better as a WARN though, since it should be impossible to have the port
enabled without a pipe selected.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Modifying the clock sources (via the DREF control on the PCH) is a slow
multi-stage process as we need to let the clocks stabilise between each
stage. If we are not actually changing the clock sources, then we can
return early.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Appease checkpatch by deleting a space after a ~]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both VGA and HDMI connectors are available on my Asus EeePC X101CH.
This patch will cause output to be shown on either when plugged in.
For both, it shows the leftmost 800x600, of the 1024x600 on LVDS.
Signed-off-by: Kero van Gelder <kero@chello.nl>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Earlier code would leave both bits set, so any reset after the first
would only reset media.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Op 23-03-13 12:47, Peter Hurley schreef:
> On Tue, 2013-03-19 at 11:13 -0400, Peter Hurley wrote:
>> On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when
>> the user X session is coming up:
> Perhaps I wasn't clear that this happens on every boot and is a
> regression from 3.8
>
> I'd be happy to help resolve this but time is of the essence; it would
> be a shame to have to revert all of this for 3.9
Well it broke on my system too, so it was easy to fix.
I didn't even need gdm to trigger it!
>8----
This fixes regression caused by 1d7c71a3e2f7 (drm/nouveau/disp: port vblank handling to event interface),
which causes a oops in the following way:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
IP: [<0000000000000001>] 0x0
PGD 0
Oops: 0010 [#1] PREEMPT SMP
Modules linked in: ip6table_filter ip6_tables ebtable_nat ebtables ...<snip>...
CPU 3
Pid: 0, comm: swapper/3 Not tainted 3.9.0-rc3-xeon #rc3 Dell Inc. Precision WorkStation T5400 /0RW203
RIP: 0010:[<0000000000000001>] [<0000000000000001>] 0x0
RSP: 0018:ffff8802afcc3d80 EFLAGS: 00010087
RAX: ffff88029f6e5808 RBX: 0000000000000001 RCX: 0000000000000000
RDX: 0000000000000096 RSI: 0000000000000001 RDI: ffff88029f6e5808
RBP: ffff8802afcc3dc8 R08: 0000000000000000 R09: 0000000000000004
R10: 000000000000002c R11: ffff88029e559a98 R12: ffff8802a376cb78
R13: ffff88029f6e57e0 R14: ffff88029f6e57f8 R15: ffff88029f6e5808
FS: 0000000000000000(0000) GS:ffff8802afcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000001 CR3: 000000029fa67000 CR4: 00000000000007e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/3 (pid: 0, threadinfo ffff8802a355e000, task ffff8802a3535c40)
Stack:
ffffffffa0159d8a 0000000000000082 ffff88029f6e5820 0000000000000001
ffff88029f71aa00 0000000000000000 0000000000000000 0000000004000000
0000000004000000 ffff8802afcc3e38 ffffffffa01843b5 ffff8802afcc3df8
Call Trace:
<IRQ>
[<ffffffffa0159d8a>] ? nouveau_event_trigger+0xaa/0xe0 [nouveau]
[<ffffffffa01843b5>] nv50_disp_intr+0xc5/0x200 [nouveau]
[<ffffffff816fbacc>] ? _raw_spin_unlock_irqrestore+0x2c/0x50
[<ffffffff816ff98d>] ? notifier_call_chain+0x4d/0x70
[<ffffffffa017a105>] nouveau_mc_intr+0xb5/0x110 [nouveau]
[<ffffffffa01d45ff>] nouveau_irq_handler+0x6f/0x80 [nouveau]
[<ffffffff810eec95>] handle_irq_event_percpu+0x75/0x260
[<ffffffff810eeec8>] handle_irq_event+0x48/0x70
[<ffffffff810f205a>] handle_fasteoi_irq+0x5a/0x100
[<ffffffff810182f2>] handle_irq+0x22/0x40
[<ffffffff8170561a>] do_IRQ+0x5a/0xd0
[<ffffffff816fc2ad>] common_interrupt+0x6d/0x6d
<EOI>
[<ffffffff810449b6>] ? native_safe_halt+0x6/0x10
[<ffffffff8101ea1d>] default_idle+0x3d/0x170
[<ffffffff8101f736>] cpu_idle+0x116/0x130
[<ffffffff816e2a06>] start_secondary+0x251/0x258
Code: Bad RIP value.
RIP [<0000000000000001>] 0x0
RSP <ffff8802afcc3d80>
CR2: 0000000000000001
---[ end trace 907323cb8ce6f301 ]---
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
If there are no channels, chan would never end up being NULL,
and so the null pointer check would fail.
Solve this by initializing chan to NULL, and iterating over temp instead.
Fixes oops when running intel-gpu-tools/tests/kms_flip, which attempts to
do some intel ioctl's on a nouveau device.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: stable@vger.kernel.org [3.7+]
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Ville pointed out that my assumption that no unsupported pixel format
can get past the pipe config computation stage to the platform
update_plane callbacks is wrong. The reason is that this function
still checks the old fb->depth value instead of the new pixel_format.
While checking with all the other places that use this I've noticed
that intel_framebuffer_init already has all the platform checks we
need, so replace those checks with a WARN_ON.
Since fb->depth isn't set for YUV pixel formats and since we already
can't create an fb with an rgb layout not support on the running
platform I /think/ this patch doesn't fix any bug.
But it surely looks better!
v2: BGR formats are also only gen4+, so add the corresponding WARN_ON,
too (Ville).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We've mostly switched over to the new more flexible schema, but
there's one check left in the modeset code.
Motivated by a question from Ville whether there's really no way an
unsupported pixel_format can escape into our platform update_plane
callbacks.
v2: Ville noticed that the fb->depth check is redudant when we already
check fb->pixel_format.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As Thomas Gleixner spotted, it's rather horrible racy:
- We can miss almost a full tick, so need to compensate by 1 jiffy.
- We need to re-check the condition when having timed-out, since a
the last check could have been before the timeout expired. E.g. when
we've been preempted or a long irq happened.
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Jack Winter <jbh@alchemy.lu>
Cc: Jack Winter <jbh@alchemy.lu>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since
commit bcf9dcc1e6269fac674e41f25d007ff75f76e840
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sun Jul 15 09:42:38 2012 +0100
drm/i915: Workaround hang with BSD and forcewake on SandyBridge
and
commit 0cc2764cc4a4bd73df55f8893c871778cf7ddd0f
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Sat Sep 1 22:59:48 2012 -0700
drm/i915: use cpu_relax() in wait_for_atomic
these two macros are essentially the same, so unify them. We keep the
_us version since it's a nice documentation for smaller timeouts.
v2: Fixup time unit conversion, _wait_for takes ms (Ville).
Cc: Jack Winter <jbh@alchemy.lu>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- It's a static function
- I just added a few more users to it
- Its sister ironlake_enable_display_irq is not marked as inline
- The compiler will still inline if it thinks it should do
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- gen4 and earlier (save for g4x) only really have a 8bpc pipe, with
the possibility to dither to 6bpc using the panel fitter
- g4x has hdmi, but no 12 bpc pipe ... !? Clamp hdmi accordingly.
- TV/SDVO out are the only connectors available on platforms with
a pipe bpp != 8, add code to force the pipe to 8bpc unconditionally.
<rant>
The dither handling on gmch platforms is one giant disaster. I'm hoping
somewhat that vlv enabling will fix this up, but given that the 6bpc
handling for edp was simply added with another quick hack, I don't have
high hopes ...
</rant>
v2: Neither vlv nor g4x have 12bpc pipes. Still set pipe_bpp to 12*3,
but let the crtc code clamp things down to 10bpc on these platforms.
v3: Fix a bpc vs. bpp mixup in the gen4 and earlier pipe_bpp limiter
code.
v4: Drop the hunk in intel_hdmi.c about g4x/vlv 12bpc, it was wrong.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- There is no 16bpc linear color format in our hw. gen4+ has a 16 bpc
float layout, but we don't really support it.
- 10bpc is a gen4+ feature, fix up the support for it.
- Update_plane should never see a wrong fb bpp value, BUG in the
corresponding cases.
v2: Rebase on top of Ville's plane pixel layout changes.
v3: Actually drop the old gen4 check for 10bpc planes, spotted
by Ville Syrjälä.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The old code only handled either 6bpc or 8bpc. Since it's easy to do,
reorganize the code to be a bit more generic so that it can also handle
10bpc and 12bpc. Note that we still start with 8bpc, so there's no
functional change.
Also, since we no don't need to compute the 6BPC flag in the mode_valid
callback, we can consolidate things a bit. That requires though that
the link bw computation is moved up in the compute_config callback.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The procedure has now 3 steps:
1. Compute the bpp that the plane will output, this is done in
pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
this function clamps the pipe_bpp to whatever limit the EDID of any
connected output specifies.
2. Adjust the pipe_bpp in the encoder and crtc functions, according to
whatever constraints there are.
3. Decide whether to use dither by comparing the stored plane bpp with
computed pipe_bpp.
There are a few slight functional changes in this patch:
- LVDS connector are now also going through the EDID clamping. But in
a 2nd change we now unconditionally force the lvds bpc value - this
shouldn't matter in reality when the panel setup is consistent, but
better safe than sorry.
- HDMI now forces the pipe_bpp to the selected value - I think that's
what we actually want, since otherwise at least the pixelclock
computations are wrong (I'm not sure whether the port would accept
e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick
the next higher bpc value, since otherwise there's no way to make
use of the 12 bpc mode (since the next patch will remove the 12bpc
plane format, it doesn't exist).
Both of these changes are due to the removal of the
pipe_bpp = min(display_bpp, plane_bpp);
statement.
Another slight change is the reworking of the dp bpc code:
- For the mode_valid callback it's sufficient to only check whether
the mode would fit at the lowest bpc.
- The bandwidth computation code is a bit restructured: It now walks
all available bpp values in an outer loop and the codeblock that
computes derived values (once a good configuration is found) has been
moved out of the for loop maze. This is prep work to allow us to
successively fall back on bpc values, and also correctly support bpc
values != 8 or 6.
v2: Rebased on top of Paulo Zanoni's little refactoring to use more
drm dp helper functions.
v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color
range work.
v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed.
v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the
hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked
in a later patch though again.
v6: Fix spelling in a comment.
v7: Debug output improvements for the bpp computation.
v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different
things!
v9: Reinstate the fix to properly ignore the firmware edp bpp ... this
was lost in a rebase.
v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have
that. Still unsure whether this is the way to go, but at least 6bpc
for a 8bpc hdmi output seems to work.
v11: And g4x/vlv also lack 12bpc hdmi support, so only support high
depth on DP. Adjust the code.
v12: Rebased.
v13: Split out the introduction of pipe_config->dither|pipe_bpp, as
requested from Jesse Barnes.
v14: Split out the special 6BPC handling for DP, as requested by Jesse
Barnes.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to compute this earlier. To avoid a big complicated patch,
this patch here just does the big search&replace and still calls the
old functions at the same places.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we have a useful struct for this, let's use it. Some neat
pointer-chasing required, but it's all there already.
v2: Rebased on top of the added Haswell limited color range support.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
