[Bug 86351] HDMI audio garbled output on Radeon R9 280X
https://bugzilla.kernel.org/show_bug.cgi?id=86351 --- Comment #11 from Lorenzo Bona --- Created attachment 181801 --> https://bugzilla.kernel.org/attachment.cgi?id=181801=edit dmesg.log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 86351] HDMI audio garbled output on Radeon R9 280X
https://bugzilla.kernel.org/show_bug.cgi?id=86351 Lorenzo Bona changed: What|Removed |Added CC||lorenz.bona at gmail.com --- Comment #10 from Lorenzo Bona --- I'm experiencing the same issue with a R7-265 video card. HDMI sound is garbled until I put some load on CPUs. ie starting/running a game is enough. As soon as the load on CPUs drops audio becomes garbled again. Any hint or test I can do? running kernel from agd5f's git, branch drm-fixes-4.1. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 100871] radeon fails to initialize one DisplayPort monitor
https://bugzilla.kernel.org/show_bug.cgi?id=100871 --- Comment #2 from Charles R. Anderson --- I'll try radeon.audio=0. I never tried DisplayPort audio on the Dell U2410, but it apparently does support it: http://en.community.dell.com/support-forums/peripherals/f/3529/t/19311234 This problem happens on the text VC even before X is started. You can find the logs in the Red Hat bugzilla linked above. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 91202] output to DVI-I is blank
https://bugs.freedesktop.org/show_bug.cgi?id=91202 --- Comment #2 from Brian Paterni --- Up to now I haven't attempted this, but I just tried changing display modes with xrandr, and this does result in a working display on DVI-I. That is, if the mode is anything other than the preferred 1920x1080. If I try to switch back to 1920x1080, the display goes blank and returns to standby mode. Would anyone happen to know why preferred mode would have problems while other modes seem to display just fine? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150704/92121d13/attachment.html>
[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering
https://bugs.freedesktop.org/show_bug.cgi?id=73528 --- Comment #38 from MirceaKitsune --- Thank you very much for fixing this, that's great news! I will gladly compile MESA from GIT after some things are fixed. I'm sorry if anything that should have worked had to be disabled... that is however much better than this issue taking place. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150704/41878e74/attachment-0001.html>
[Bug 88043] Star Conflict locks up AMD BARTS
https://bugs.freedesktop.org/show_bug.cgi?id=88043 --- Comment #2 from EoD --- This is still the case with current mesa git 939dc2850645786b4ff76aa162e44eb9f77be805 . Is there any more information I can provide to help fixing this? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150704/0c1ad947/attachment.html>
[PULL] topic/drm-fixes
Hi Linus, Since Dave is enjoying vacation I figured I'll send you this drm core fix directly. Cheers, Daniel The following changes since commit 8b72ce158cf0dba443e36fc66e0bb29c2580e0b6: drm: Always enable atomic API (2015-06-24 11:21:35 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-fixes-2015-07-04 for you to fetch changes up to e24ff467e12e1560de753313976c46e84fa6306a: drm/crtc: Fix edid length computation (2015-07-04 00:52:34 +0200) Shixin Zeng (1): drm/crtc: Fix edid length computation drivers/gpu/drm/drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v2 3/5] drm/rockchip: vop: support plane scale
On Fri, Jul 3, 2015 at 7:22 PM, Mark yao wrote: > On 2015å¹´07æ03æ¥ 17:58, Tomasz Figa wrote: >>Aren't the scl_modes for CbCr planes always the same as for Y plane? >>> >>> > >>> > >>> >No, such as src(1920 x 1080) -> dst(1280x800), yuv format is NV12. >>> >so Y plane horizontal and vertical is scale down. >>> > >>> >but src_w = 1920 / 2 = 960 < 1280 >>> > src_h = 1080 / 2 = 540 < 800. >>> > >>> >So Cbcr horizontal and vertical is scale up. >> >> Sorry, I don't follow. >> >> If we scale down Y plane in NV12 from 1920x1080 to 1280x800, then >> original CbCr plane will be 960x540 and destination CbCr plane will be >> 640x400 (because CbCr plane of NV12 is subsampled 2x2, which is half >> the width and half the height of Y plane), so both planes are being >> scaled down. >> > destination CbCr plane is 1280x800, destination can't be subsample. Ah, I see, so internally it's always scalling to destination plane size. This means that calculation for both Y and CbCr must be done indeed, but even then you could use helper functions for that, since they differ only in parameters. Best regards, Tomasz
[PATCH] drm/tilcdc: Allocate register storage based on the actual number registers
Reviewed-By: Michael Bode
Jyri,
good idea to allocate the space for registers dynamically.
This eliminates the need of synchronizing driver and header file in an
elegant way.
Only thing I personally don't like, is potentially passing a NULL
pointer to kfree.
But I learned that this is valid kernel code.
Br,
Michael
On 07/03/2015 12:45 PM, Jyri Sarha wrote:
> Allocate suspend/resume register storage based on the actual number
> registers the driver is aware of. The static allocation for register
> storage had falen behind badly.
>
> Reported-by: Michael Bode
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 20 +++-
> drivers/gpu/drm/tilcdc/tilcdc_drv.h | 2 +-
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 4908c1f..2f87263 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -139,11 +139,14 @@ static int tilcdc_unload(struct drm_device *dev)
>
> pm_runtime_disable(dev->dev);
>
> + kfree(priv->saved_register);
> kfree(priv);
>
> return 0;
> }
>
> +static size_t tilcdc_num_regs(void);
> +
> static int tilcdc_load(struct drm_device *dev, unsigned long flags)
> {
> struct platform_device *pdev = dev->platformdev;
> @@ -155,7 +158,11 @@ static int tilcdc_load(struct drm_device *dev, unsigned
> long flags)
> int ret;
>
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> - if (!priv) {
> + if (priv)
> + priv->saved_register = kcalloc(sizeof(*priv->saved_register),
> +tilcdc_num_regs(), GFP_KERNEL);
> + if (!priv || !priv->saved_register) {
> + kfree(priv);
> dev_err(dev->dev, "failed to allocate private data\n");
> return -ENOMEM;
> }
> @@ -345,6 +352,7 @@ fail_free_wq:
>
> fail_free_priv:
> dev->dev_private = NULL;
> + kfree(priv->saved_register);
> kfree(priv);
> return ret;
> }
> @@ -467,6 +475,16 @@ static const struct {
> REG(2, true, LCDC_INT_ENABLE_SET_REG),
> #undef REG
> };
> +
> +static size_t tilcdc_num_regs(void)
> +{
> + return ARRAY_SIZE(registers);
> +}
> +#else
> +static size_t tilcdc_num_regs(void)
> +{
> + return 0;
> +}
> #endif
>
> #ifdef CONFIG_DEBUG_FS
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> index e863ad0..bc94835 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> @@ -67,7 +67,7 @@ struct tilcdc_drm_private {
> uint32_t max_width;
>
> /* register contents saved across suspend/resume: */
> - u32 saved_register[12];
> + u32 *saved_register;
>
> #ifdef CONFIG_CPU_FREQ
> struct notifier_block freq_transition;
-- next part --
An HTML attachment was scrubbed...
URL:
