- 21 Sep, 2011 3 commits
-
-
Wu Fengguang authored
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake, SandyBridge/CougarPoint and IvyBridge/PantherPoint chips. ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio capabilities of the plugged monitor. It's built and passed to audio driver in 2 steps: (1) at get_modes time, parse EDID and save ELD to drm_connector.eld[] (2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP. Test scheme: plug in the HDMI/DP monitor, and run cat /proc/asound/card0/eld* to check if the monitor name, HDMI/DP type, etc. show up correctly. Minor imperfection: the GEN5_AUD_CNTL_ST/DIP_Port_Select field always reads 0 (reserved). Without knowing the port number, I worked it around by setting the ELD_valid bit for ALL the three ports. It's tested to not be a problem, because the audio driver will find invalid ELD data and hence rightfully abort, even when it sees the ELD_valid indicator. Thanks to Zhenyu and Pierre-Louis for a lot of valuable help and testing. CC: Zhao Yakui <yakui.zhao@intel.com> CC: Wang Zhenyu <zhenyu.z.wang@intel.com> CC: Jeremy Bush <contractfrombelow@gmail.com> CC: Christopher White <c.white@pulseforce.com> CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com> CC: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
-
Wu Fengguang authored
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio capabilities of the plugged monitor. This adds drm_edid_to_eld() for converting EDID to ELD. The converted ELD will be saved in a new drm_connector.eld[128] data field. This is necessary because the graphics driver will need to fixup some of the data fields (eg. HDMI/DP connection type, AV sync delay) before writing to the hardware ELD buffer. drm_av_sync_delay() will help the graphics drivers dynamically compute the AV sync delay for fixing-up the ELD. ELD selection policy: it's possible for one encoder to be associated with multiple connectors (ie. monitors), in which case the first found ELD will be returned by drm_select_eld(). This policy may not be suitable for all users, but let's start it simple first. The impact of ELD selection policy: assume there are two monitors, one supports stereo playback and the other has 8-channel output; cloned display mode is used, so that the two monitors are associated with the same internal encoder. If only the stereo playback capability is reported, the user won't be able to start 8-channel playback; if the 8-channel ELD is reported, then user space applications may send 8-channel samples down, however the user may actually be listening to the 2-channel monitor and not connecting speakers to the 8-channel monitor. According to James, many TVs will either refuse the display anything or pop-up an OSD warning whenever they receive hdmi audio which they cannot handle. Eventually we will require configurability and/or per-monitor audio control even when the video is cloned. CC: Zhao Yakui <yakui.zhao@intel.com> CC: Wang Zhenyu <zhenyu.z.wang@intel.com> CC: Jeremy Bush <contractfrombelow@gmail.com> CC: Christopher White <c.white@pulseforce.com> CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com> CC: Paul Menzel <paulepanter@users.sourceforge.net> CC: James Cloos <cloos@jhcloos.com> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
-
Keith Packard authored
We want to enable dithering on any pipe where the frame buffer has more color resolution than the output device. The previous code was incorrectly clamping the frame buffer bpc to the display bpc, effectively disabling dithering all of the time as the computed frame buffer bpc would never be larger than the display bpc. Signed-off-by: Keith Packard <keithp@keithp.com> Reported-by: Oliver Hartkopp <socketcan@hartkopp.net> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
-
- 20 Sep, 2011 37 commits
-
-
git://people.freedesktop.org/~keithp/linuxDave Airlie authored
* 'drm-intel-next' of git://people.freedesktop.org/~keithp/linux: Drivers: i915: Fix all space related issues.
-
git://git.freedesktop.org/git/nouveau/linux-2.6Dave Airlie authored
* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6: (353 commits) drm/nouveau: remove allocations from gart populate() hook drm/nvc0/fb: slightly improve PMFB intr handling, move out of nvc0_graph.c drm/nvc0/fifo: avoid touching missing subfifos drm/nvd9/disp: bail out of mode_set_base if no fb bound to crtc drm/nvd9/disp: stub some more api hooks so we don't oops on resume drm/nouveau: fix printk typo in ioremap failure path drm/nvc0/pm: minor clock readback fixes drm/nv40/pm: execute memory reset script from vbios drm/nv50/gr: refactor initialisation drm/nouveau: if requested, try harder at disabling sysmem pushbufs drm/nv50/gr: enable ctxprog xfer only when we need it to save power drm/nouveau/dp: add support for displayport table 0x30 drm/nouveau/dp: return master dp table pointer too when looking up encoder drm/nouveau/bios: simplify U/d table hash matching func to just match drm/nouveau/dp: preserve non-pattern bits in DP_TRAINING_PATTERN_SET drm/nvc0/gr: remove MODULE_FIRMWARE() lines drm/nouveau/dp: use alternate lane mask for nvaf drm/nouveau/dp: link rate scripts are selected with a comparison table drm/nv40/pm: write nv40-specific reclocking routines drm/nv40/pm: parse geometric delta clock from vbios ...
-
Ben Skeggs authored
Since some somewhat questionable changes a while back, TTM provides a completely empty array of struct dma_address that stays around for the entire lifetime of the TTM object. Lets use this array, *always*, rather than wasting yet more memory on another array who's purpose is identical, as well as yet another bool array of the same size saying *which* of the previous two arrays to use... This change will also solve the high order allocation failures seen by some people while using nouveau. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
I'm still not certain how to determine the number of SUBPs are present on a given board. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Marcin Slusarz authored
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
On >=nv50, userspace would still end up allocating pushbufs in GART. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Martin Peres authored
This patch adds instructions to ctxprog and by doing, impacts context switching performance. My testcase showed a 1% performance cost using glxgears that is a context-switch bound application. Please test and report bugs/performance/power/other. Many thanks to Maxim Levitsky for his dedicated work on lowering power consumption with nouveau. More patches are coming thanks to his work: https://bugs.freedesktop.org/show_bug.cgi?id=37922Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Written from observations of my NVD9's vbios, completely untested due to my NVD9 lacking actual DisplayPort connectors.. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Will need to be able to distinguish 2.0/2.1 from 3.0 soon. Also, move the vbios parsing to nouveau_dp where it belongs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
The caller is now responsible for parsing its own lists (or whatever) of possible encoders. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
We don't use these by default anymore, and there's been complaints from a number of places thinking that the firmware blobs are required still. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Naturally... Because Macs can't just be the same as everything else now can they? Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Not hardcoded as originally thought. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Not 100% perfect yet, but a good start towards what it'll look like in the end. Actually seems stable on a NV44 I have here, as much as running around OA for a fair amount of time constantly switching between performance levels can prove.. My NV49 isn't quite so happy, and semaphores mess up somehow (sometimes) as a result of the memory reclocking. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This changes the meaning of what we reported as "core" clock previously. The shader/rop units are allegedly supposed to be run at the base clock listed in the perf table, while the geometric clock can be bumped from this value on some boards. So that we can report both, we'll report the base clock as "shader" (since the shaders *do* run at it), and the geometric clock as "core". Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Not used currently, but it will be used in preference to pre-determined lane/bandwidth numbers at a later point. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Allows us to be lazy elsewhere... Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
I'm sure that out there somewhere, someone will need this. We currently haven't seen an example of LVDS being on a non-0 SOR so far though. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
The HW will only accept the DMA_FROM_MEMORY class for DMA_SEMAPHORE without asking the driver to intervene. It appears that semaphores will work correctly even without DMA_IN_MEMORY, so lets avoid the large amount of interrupts generated by x-chan sync. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
The clock_get() hook returns KHz, not Hz. Also fixed to use crystal freq from dev_priv. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
-