[Bug 91545] [BONAIRE][ARK: Survival Evolved] Regression: radeonsi: flush if the memory usage for an IB is too high

2015-08-08 Thread bugzilla-dae...@freedesktop.org
-- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150808/56909b99/attachment.html>

[PATCH 2/4] drm/bridge: Add vendor prefixes

2015-08-08 Thread Krzysztof Kozlowski
W dniu 08.08.2015 o 01:27, Thierry Reding pisze: > From: Thierry Reding > > Use vendor prefixes for Kconfig symbols and filenames. This should make > it easier to identify the various bridge drivers and to organize the > directory. > > While at it, rename dw_hdmi.[ch] to dw-hdmi.[ch] for consist

[PATCH 3/4] drm/panel: Add Samsung prefix to panel drivers

2015-08-08 Thread Krzysztof Kozlowski
W dniu 08.08.2015 o 01:27, Thierry Reding pisze: > From: Thierry Reding > > The likelihood of getting a large number of panel drivers from different > vendors is quite high. Add a prefix to the two existing Samsung panel > drivers to set a guideline for future patch submissions. Using vendor > pr

[PATCH v2 4/8] drm: rockchip/dp: add rockchip platform dp driver

2015-08-08 Thread Heiko Stübner
Hi Yakir, I think this Rockchip portion is missing a devicetree binding. You have the ability to power down the actual edp phy by using grf_edp_iddq_en from GRF_SOC_CON12. This is similar to how the rk3288 usb-phy gets put into a deeper state. So maybe you could provide a phy driver (drivers/phy

[PATCH v2 4/8] drm: rockchip/dp: add rockchip platform dp driver

2015-08-08 Thread Yakir Yang
Hi Hekio, 在 2015/8/8 6:46, Heiko Stübner 写道: > Hi Yakir, > > > I think this Rockchip portion is missing a devicetree binding. Oh, thanks, I would complete it in next ;) > You have the ability to power down the actual edp phy by using > grf_edp_iddq_en from GRF_SOC_CON12. This is similar

[PATCH 1/2] drm: bridge/dw_hdmi: Cache edid data

2015-08-08 Thread Russell King - ARM Linux
On Fri, Aug 07, 2015 at 11:40:28PM +0100, Russell King - ARM Linux wrote: > However, if we do this, then we might as well just modify > dw_hdmi_connector_get_modes(), and arrange for a HPD de-assertion to > NULL and free hdmi->edid so the next get_modes() call triggers a re-read. Testing with the

[PATCH 1/2] drm: bridge/dw_hdmi: Cache edid data

2015-08-08 Thread Russell King - ARM Linux
On Sat, Aug 08, 2015 at 02:35:40PM +0100, Russell King - ARM Linux wrote: > I have a whole bunch of further patches for dw-hdmi, so if you don't > mind, I'll take your two, merge them on the front of my series, and > re-post them. I think we're getting close to the time where we can > see initial

[PATCH v5 4/6] drm: bridge/dw_hdmi-i2s-audio: add audio driver

2015-08-08 Thread Russell King - ARM Linux
On Sat, Jun 20, 2015 at 12:28:15AM +0800, Yakir Yang wrote: > Add ALSA based HDMI I2S audio driver for dw_hdmi. Sound card > driver could connect to this codec through the codec dai name > "dw-hdmi-i2s-audio". I'm applying this patch to my tree with some changes. I haven't seen anyone ack it, nor

[PATCH 00/12] dw-hdmi development

2015-08-08 Thread Russell King - ARM Linux
This sub-series is a mixture of development: * Removing the incorrect pixel repetition configuration code * Preventing pixel-doubled modes from being used * Adding interlaced video support * Implementing the sink_is_hdmi/sink_has_audio flags I suggested a few months ago * Only enabling audio sup

[PATCH 01/12] drm: bridge/dw_hdmi: remove pixel repetition setting for all VICs

2015-08-08 Thread Russell King
dw_hdmi sets a pixel repetition factor of 1 for VICs 10-15, 25-30 and 35-38. However, DRM uses their native resolutions in its timing information. For example, VIC 14 can be 1440x480 with no repetition, or 720x480 with one pixel repetition. As DRM uses 1440 pixels per line for this video mode, w

[PATCH 02/12] drm: bridge/dw_hdmi: don't support any pixel doubled modes

2015-08-08 Thread Russell King
As mentioned in the previous commit, the dw-hdmi driver does not support pixel doubled modes at present; it does not configure the PLL correctly for these modes. Therefore, filter out the double-clocked modes as we presently are unable to support them. Signed-off-by: Russell King --- drivers/gp

[PATCH 03/12] gpu: imx: simplify sync polarity setting

2015-08-08 Thread Russell King
Use a function to convert the sync pin to a bit mask for the DI_GENERAL register, and move this out of the interlace/non-interlace path to the common path. Signed-off-by: Russell King --- drivers/gpu/ipu-v3/ipu-di.c | 50 + 1 file changed, 28 insertion

[PATCH 04/12] gpu: imx: fix support for interlaced modes

2015-08-08 Thread Russell King
The support for interlaced video modes seems to be broken; we don't use anything other than the vtotal/htotal from the timing information to define the various sync counters. Freescale patches for interlaced video support contain an alternative sync counter setup, which we include here. This setu

[PATCH 05/12] drm: bridge/dw_hdmi: add support for interlaced video modes

2015-08-08 Thread Russell King
Add support for interlaced video modes to the dw_hdmi bridge. This mainly involves halving the vertical parameters to be programmed into the bridge registers, and setting the interlace_allowed connector flag. This brings working 1080i support. However, 480i and 576i fail to work due to the lack

[PATCH 06/12] drm: bridge/dw_hdmi: clean up HDMI vs DVI mode handling

2015-08-08 Thread Russell King
The FSL kernel detects the HDMI vendor id, and uses this to set hdmi->edid_cfg.hdmi_cap, which is then used to set mdvi appropriately, rather than detecting whether we are outputting a CEA mode. Update the dw_hdmi code to use this logic, but lets eliminate the mdvi variable, prefering the more ver

[PATCH 07/12] drm: bridge/dw_hdmi: enable audio only if sink supports audio

2015-08-08 Thread Russell King
Only enable audio support if the sink supports audio in some form, as defined via its EDID. We discover this capability using the generic drm_detect_monitor_audio() function. Signed-off-by: Russell King --- drivers/gpu/drm/bridge/dw_hdmi.c | 12 +--- 1 file changed, 9 insertions(+), 3 d

[PATCH 08/12] drm: bridge/dw_hdmi: avoid enabling interface in mode_set

2015-08-08 Thread Russell King
On a mode set, DRM makes the following sequence of calls: * for_each_encoder * bridge mode_fixup * encoder mode_fixup * crtc mode_fixup * for_each_encoder * bridge disable * encoder prepare * bridge post_disable * disable unused encoders * crtc pre

[PATCH 09/12] drm: bridge/dw_hdmi: rename dw_hdmi_phy_enable_power()

2015-08-08 Thread Russell King
dw_hdmi_phy_enable_power() is not about enabling and disabling power. It is about allowing or preventing power-down mode being entered - the register is documented as "Power-down enable (active low 0b)." This can be seen as the bit has no effect when the HDMI phy is operational on iMX6 hardware.

[PATCH 11/12] drm: bridge/dw_hdmi: add connector mode forcing

2015-08-08 Thread Russell King
When connected to HDMI sources, some DVI monitors de-assert their HPD signal and TDMS loads for one seconds every four seconds when there is no signal present on the connection. Unfortunately, this behaviour is indistinguishable from a proper HDMI setup with an AV receiver in the path to the displ

[PATCH 12/12] drm: bridge/dw_hdmi: improve HDMI enable/disable handling

2015-08-08 Thread Russell King
HDMI sinks are permitted to de-assert and re-assert the HPD signal to indicate that their EDID has been updated, which may not involve a change of video information. An example of where such a situation can arise is when an AV receiver is connected between the source and the display device. Event

[PATCH 0/9] dw-hdmi audio support

2015-08-08 Thread Russell King - ARM Linux
Following on from the previous sub-series, this sub-series adds audio support to dw-hdmi. The two different variants are now in this patch: AHB audio support found on iMX6 platforms, and I2S support found on Rockchip patches. Thanks to Yakir Yang for contributing the I2S support. I suspect that t

[PATCH 1/9] drm: bridge/dw_hdmi-ahb-audio: add audio driver

2015-08-08 Thread Russell King
Add ALSA based HDMI AHB audio driver for dw_hdmi. The only buffer format supported by the hardware is its own special IEC958 based format, which is not compatible with any ALSA format. To avoid doing too much data manipulation within the driver, we support only ALSAs IEC958 LE and 24-bit PCM form

[PATCH 2/9] drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver

2015-08-08 Thread Russell King
Parse the ELD (EDID like data) stored from the HDMI driver to restrict the sample rates and channels which are available to ALSA. This causes the ALSA device to reflect the capabilities of the overall audio path, not just what is supported at the HDMI source interface level. Signed-off-by: Russel

[PATCH 3/9] drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audio

2015-08-08 Thread Russell King
Add basic support for multi-channel PCM audio, with fixed speaker mappings. This has been tested with an AV receiver, and appears to work for low sample rates up to 8 channels. It should be noted that multi-channel mode using the IEC958 alsa-lib conversion plugin requires correct AES channel stat

[PATCH 4/9] drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizes

2015-08-08 Thread Russell King
With multichannel audio, we need to allow larger buffer sizes to avoid XRUNs during playback. Push the buffer size up to 1024K, but as we maintain two buffers, ensure that the vmalloc buffer does not exceed the userspace buffer size. Signed-off-by: Russell King --- drivers/gpu/drm/bridge/dw_hdm

[PATCH 5/9] drm: bridge/dw_hdmi: avoid being recursive in N calculation

2015-08-08 Thread Russell King
There's no need to be recursive when computing the N value for the ACR packet - we can instead calculate the multiplier prior to our switch() based lookup, and multiply the N value appropriately afterwards. Signed-off-by: Russell King --- drivers/gpu/drm/bridge/dw_hdmi.c | 25 +--

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

2015-08-08 Thread Russell King
Adjust the pixel clock values in the N calculation to match the more accurate clock values we're given by the DRM subsystem, which are the kHz pixel rate, with any fractional kHz rounded down in the case of the non-240, non-480 line modes, or rounded up for the others. So, 25.20 / 1.001

[PATCH 7/9] drm: bridge/dw_hdmi: remove ratio support from ACR code

2015-08-08 Thread Russell King
We never set the ratio for CTS/N calculation for the audio clock regenerator (ACR) to anything but 100, so this adds pointless complexity. Should we support pixel repetition, we should update the CTS/N calculation code to use those parameters or the actual TMDS clock rate instead of a ratio. Sign

[PATCH 8/9] drm: bridge/dw_hdmi: replace CTS calculation for the ACR

2015-08-08 Thread Russell King
Given the TDMS clock, audio sample rate, and the N parameter, we can calculate the CTS value for the audio clock regenerator (ACR) using the following calculation given in the HDMI specification: CTS = ftdms * N / (128 * fs) The specification says that the CTS value is an average value, w

[PATCH 9/9] drm: bridge/dw_hdmi-i2s-audio: add audio driver

2015-08-08 Thread Russell King
From: Yakir Yang To: linux-rockchip at lists.infradead.org,alsa-devel at alsa-project.org,dri-devel at lists.freedesktop.org,linux-kernel at vger.kernel.org,linux-arm-kernel at lists.infradead.org Add ALSA based HDMI I2S audio driver for dw_hdmi. Sound card driver could connect to this codec th

[PATCH 10/12] drm: bridge/dw_hdmi: fix phy enable/disable handling

2015-08-08 Thread Russell King
The dw_hdmi enable/disable handling is particularly weak in several regards: * The hotplug interrupt could call hdmi_poweron() or hdmi_poweroff() while DRM is setting a mode, which could race with a mode being set. * Hotplug will always re-enable the phy whenever it detects an active hotplug si

[PATCH 2/2] drm/nouveau: increase max pixel clock to 225 MHZ for HDMI

2015-08-08 Thread Hauke Mehrtens
The Nvidia blob allows a pixel clock up to 225 MHz in version 346.59, but only allowed 165MHz in version 295 for HDMI connections. This was tested with a GF114 (Nvidia GTX 560 TI) and a HDMI monitor which used 225 MHz pixel clock and a signal link DVI monitor with a pixel clock of less than 165 MHz

[PATCH] radeon: Add option to disable dpm quirks

2015-08-08 Thread Adel Gadllah
This allows to test whether a specific quirk is (still) need on a particular hardware combination. Adel Gadllah (1): radeon: Add option to disable dpm quirks drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_drv.c | 4 drivers/gpu/drm/radeon/radeon_pm.c | 2 +- dri

[PATCH] radeon: Add option to disable dpm quirks

2015-08-08 Thread Adel Gadllah
Allow users to disable hardware specific dpm quirks using a module parameter. This patch leaves quirks enabled by default. Signed-off-by: Adel Gadllah --- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_drv.c | 4 drivers/gpu/drm/radeon/radeon_pm.c | 2 +- drivers

[PATCH 0/2] drm/nouveau: add support for 2560x1440@56 over HDMI

2015-08-08 Thread Hauke Mehrtens
These patches are adding support for outputting 2560x1440 at 56 over HDMI. This needs a pixel clock of 225 MHz which was not supported before. This was tested in a dual monitor setup with a GF114 (GTX 560 TI) and one HDMI monitor running with 2560x1440 at 56 and one DVI monitor running with 192

[PATCH 1/2] drm/nouveau: activate dual link TMDS links only when possible

2015-08-08 Thread Hauke Mehrtens
Without this patch a pixel clock rate above 165 MHz on a TMDS link is assumed to be dual link. This is true for DVI, but not for HDMI. HDMI supports no dual link, but it supports pixel clock rates above 165 MHz. Only activate Dual Link mode when it is actual possible. Signed-off-by: Hauke Mehrtens

[PATCH] radeon: Add option to disable dpm quirks

2015-08-08 Thread Christian König
On 08.08.2015 17:09, Adel Gadllah wrote: > Allow users to disable hardware specific dpm quirks > using a module parameter. > > This patch leaves quirks enabled by default. You should read the code a bit more carefully, you can already override the kernel quirks by specifying radeon.dpm=1 on the k

Caching of EDID for X server to decrease startup time of X server

2015-08-08 Thread Paul Menzel
akes 450 ms. It seems to take 240 ms from loading the Radeon module to the message below. [ 231.481] (II) [KMS] Kernel modesetting enabled. Another 100 ms are used up, in the lines below. [ 231.481] (II) RADEON(0): SwapBuffers wait for vsync: enabled [ 231.504] (II) RADEON(0): Output VGA-0 has no monitor section [ 231.534] (II) RADEON(0): Output DVI-0 has no monitor section [ 231.556] (II) RADEON(0): EDID for output VGA-0 [ 231.586] (II) RADEON(0): EDID for output DVI-0 [ 231.586] (II) RADEON(0): Manufacturer: SAM Model: 194 Serial#: 1112092985 Is it correct, that EDID is probed for both outputs? Is that necessary? I assume during startup the Linux kernel for example already collected this information and if no change of monitor/output is detected, the EDID should be the same, right? Is that already implement and I just need to apply the correct configuration? Any suggestions on how to decrease the startup time for the X server are much appreciated. Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150808/e9c08481/attachment-0001.sig>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

2015-08-08 Thread bugzilla-dae...@freedesktop.org
are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150808/1f5345ff/attachment.html>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

2015-08-08 Thread bugzilla-dae...@freedesktop.org
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150808/53f24870/attachment.html>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

2015-08-08 Thread bugzilla-dae...@freedesktop.org
because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150808/7966d3da/attachment.html>

[PATCH] radeon: Add option to disable dpm quirks

2015-08-08 Thread Adel Gadllah
Am 08.08.2015 um 21:10 schrieb Christian König: > On 08.08.2015 17:09, Adel Gadllah wrote: >> Allow users to disable hardware specific dpm quirks >> using a module parameter. >> >> This patch leaves quirks enabled by default. > > You should read the code a bit more carefully, you can already overr