Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Tomasz Figa]

Hi Vikas,

On Friday 02 of August 2013 12:08:52 Vikas Sajjan wrote:
> Hi Rob,
> 
> On 2 August 2013 06:03, Rob Clark  wrote:
> > On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa  
wrote:
> >> Hi Vikas,
> >> 
> >> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
> >>> While trying to get boot-logo up on exynos5420 SMDK which has eDP
> >>> panel
> >>> connected with resolution 2560x1600, following error occured even
> >>> with
> >>> IOMMU enabled:
> >>> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
> >>> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor
> >>> 0
> >>> 
> >>> This patch fixes the issue by adding a check for IOMMU.
> >>> 
> >>> Signed-off-by: Vikas Sajjan 
> >>> Signed-off-by: Arun Kumar 
> >>> ---
> >>> 
> >>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
> >>>  1 file changed, 8 insertions(+), 1 deletion(-)
[snip]
> >>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
> >>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
> >>> 
> >>>   /* 0 means to allocate physically continuous memory */
> >>> 
> >>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> >>> + if (!is_drm_iommu_supported(dev))
> >>> + flag = 0;
> >>> + else
> >>> + flag = EXYNOS_BO_NONCONTIG;
> >> 
> >> While noncontig memory might be used for devices that support IOMMU,
> >> there should be no problem with using contig memory for them, so
> >> this seems more like masking the original problem rather than
> >> tracking it down.> 
> > it is probably a good idea to not require contig memory when it is not
> > needed for performance or functionality (and if it is only
> > performance, then fallback gracefully to non-contig).. but yeah, would
> > be good to know if this is masking another issue all the same
> 
> Whats happening with CONTIG flag and with IOMMU,  is
> 
>  __iommu_alloc_buffer() ---> dma_alloc_from_contiguous() and in this
> function it fails at
> this condition check  if (pageno >= cma->count)
> 
> So I tried increasing the CONFIG_CMA_SIZE_MBYTES to 24,  this check
> succeeds and it works well without my patch.
> 
> But what about the case where CONFIG_CMA is disabled , yet i want
> bigger memory for a device.
>  I think using IOMMU we can achieve this.
>
>  correct me, if i am wrong.

This is probably fine. I'm not sure about performance aspects of using 
noncontig memory as framebuffer, though. This needs to be checked and if 
there is some performance penalty, I would make noncontig allocation a 
fallback case, if contig fails, as Rob has suggested.

Also I think you should adjust the commit message to say that non-
contiguous memory can be used when IOMMU is supported, so there is no need 
to force contiguous allocations, since this is not a bug fix, but rather a 
feature this patch is adding.

Best regards,
Tomasz
 
> > BR,
> > -R
> > 
> >> Could you check why the allocation fails when requesting contiguous
> >> memory?
> >> 
> >> Best regards,
> >> Tomasz
> >> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-media" in the body of a message to majord...@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Inki Dae]

2013/8/2 Vikas Sajjan 

> Hi Rob,
>
> On 2 August 2013 06:03, Rob Clark  wrote:
> > On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa 
> wrote:
> >> Hi Vikas,
> >>
> >> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
> >>> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> >>> connected with resolution 2560x1600, following error occured even with
> >>> IOMMU enabled:
> >>> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
> >>> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> >>>
> >>> This patch fixes the issue by adding a check for IOMMU.
> >>>
> >>> Signed-off-by: Vikas Sajjan 
> >>> Signed-off-by: Arun Kumar 
> >>> ---
> >>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
> >>>  1 file changed, 8 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> >>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
> >>> 100644
> >>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> >>> @@ -16,6 +16,7 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>
> >>>  #include "exynos_drm_drv.h"
> >>>  #include "exynos_drm_fb.h"
> >>> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
> >>> drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
> >>>   unsigned long size;
> >>>   int ret;
> >>> + unsigned int flag;
> >>>
> >>>   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
> >>>   sizes->surface_width, sizes->surface_height,
> >>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
> >>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
> >>>
> >>>   /* 0 means to allocate physically continuous memory */
> >>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> >>> + if (!is_drm_iommu_supported(dev))
> >>> + flag = 0;
> >>> + else
> >>> + flag = EXYNOS_BO_NONCONTIG;
> >>
> >> While noncontig memory might be used for devices that support IOMMU,
> there
> >> should be no problem with using contig memory for them, so this seems
> more
> >> like masking the original problem rather than tracking it down.
> >
> > it is probably a good idea to not require contig memory when it is not
> > needed for performance or functionality (and if it is only
> > performance, then fallback gracefully to non-contig).. but yeah, would
> > be good to know if this is masking another issue all the same
> >
>
> Whats happening with CONTIG flag and with IOMMU,  is
>
>  __iommu_alloc_buffer() ---> dma_alloc_from_contiguous() and in this
> function it fails at
> this condition check  if (pageno >= cma->count)
>
> So I tried increasing the CONFIG_CMA_SIZE_MBYTES to 24,  this check
> succeeds and it works well without my patch.
>
> But what about the case where CONFIG_CMA is disabled , yet i want
> bigger memory for a device.
>  I think using IOMMU we can achieve this.
>
>  correct me, if i am wrong.
>
>
I'm on summer vacation so I'm afraid that I cannot test and look into it
but I guess you guy didn't declare CMA region for Exynos drm. And in this
case, the size of CMA declared region is 16MB as default. That is why works
well after increasing default size, CONFIG_CMA_SIZE_MBYTES, to 24MB. And I
mentioned long time ago, we are required to use physically contiguous
memory in case that bootloader uses physically contiguous memory for its
own framebuffer, and kernel wants to share the bootloader's framebuffer
region to resolve flickering issue while booted; that is required for
product. And one question, is there any reason that you guy should use
non-contiguous memory for framebuffer with iommu?

Thanks,
Inki Dae


>
> > BR,
> > -R
> >
> >> Could you check why the allocation fails when requesting contiguous
> >> memory?
> >>
> >> Best regards,
> >> Tomasz
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Thanks and Regards
>  Vikas Sajjan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon: add very basic support for audio block on DCE6

[Rafał Miłecki]

It doesn't allow playing anything yet, but was the most tricky part to
RE (it's indirect access, so couldn't trace it by dumping registers).
Now we just need to implement support for HDMI blocks.

Signed-off-by: Rafał Miłecki 
---
 drivers/gpu/drm/radeon/Makefile  |2 +-
 drivers/gpu/drm/radeon/dce6_afmt.c   |   88 ++
 drivers/gpu/drm/radeon/radeon_asic.h |2 +
 drivers/gpu/drm/radeon/si.c  |7 +++
 drivers/gpu/drm/radeon/sid.h |5 ++
 5 files changed, 103 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/radeon/dce6_afmt.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index c3df52c..6510fc4 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -79,7 +79,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
si_blit_shaders.o radeon_prime.o radeon_uvd.o cik.o cik_blit_shaders.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
\
-   trinity_smc.o ni_dpm.o si_smc.o si_dpm.o
+   trinity_smc.o ni_dpm.o si_smc.o si_dpm.o dce6_afmt.o
 
 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
 radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
b/drivers/gpu/drm/radeon/dce6_afmt.c
new file mode 100644
index 000..0d98143
--- /dev/null
+++ b/drivers/gpu/drm/radeon/dce6_afmt.c
@@ -0,0 +1,88 @@
+/*
+ * Copyright © 2013 Rafał Miłecki 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Rafał Miłecki
+ */
+#include 
+#include 
+#include "radeon.h"
+#include "radeon_asic.h"
+#include "sid.h"
+
+static u32 dce6_audio_read(struct radeon_device *rdev, u32 reg)
+{
+   WREG32(SI_AUDIO_ADDR, reg);
+   return RREG32(SI_AUDIO_DATA);
+}
+
+static void dce6_audio_write(struct radeon_device *rdev, u32 reg, u32 v)
+{
+   reg |= SI_AUDIO_ADDR_WRITE;
+   WREG32(SI_AUDIO_ADDR, reg);
+   WREG32(SI_AUDIO_DATA, v);
+}
+
+static void dce6_audio_maskset(struct radeon_device *rdev, u32 reg, u32 mask,
+  u32 set)
+{
+   u32 tmp = dce6_audio_read(rdev, reg);
+   tmp &= mask;
+   tmp |= set & ~mask;
+   dce6_audio_write(rdev, reg, tmp);
+}
+
+static void dce6_audio_enable(struct radeon_device *rdev, bool enable)
+{
+   DRM_INFO("%s audio support\n", enable ? "Enabling" : "Disabling");
+
+   if (enable) {
+   dce6_audio_maskset(rdev, 0x54, ~0x8000, 0x8000);
+   } else {
+   dce6_audio_maskset(rdev, 0x54, ~0x8000, 0);
+   /* TODO: clear some bit(s) in reg 0x36 */
+   }
+
+   rdev->audio_enabled = enable;
+}
+
+int dce6_audio_init(struct radeon_device *rdev)
+{
+   if (!radeon_audio)
+   return 0;
+
+   dce6_audio_enable(rdev, true);
+
+   rdev->audio_status.channels = -1;
+   rdev->audio_status.rate = -1;
+   rdev->audio_status.bits_per_sample = -1;
+   rdev->audio_status.status_bits = 0;
+   rdev->audio_status.category_code = 0;
+
+   return 0;
+}
+
+void dce6_audio_fini(struct radeon_device *rdev)
+{
+   if (!rdev->audio_enabled)
+   return;
+
+   dce6_audio_enable(rdev, false);
+}
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index ca18957..48674ca 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -698,6 +698,8 @@ void si_dpm_debugfs_print_current_performance_level(struct 
radeon_device *rdev,
struct seq_file *m);
 int si_dpm_force_performance_level(struct radeon_device *rdev,
   enum radeon_dpm_forced_level level);
+int dce6_audio_init(struct radeon_device *rdev);
+void dce6_audio_fini(struct radeon_device *rdev);
 

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #71 from Francisco Pina Martins  ---
Confirming that the latest drm-fixes-3.11 also works fine for me. (4/4)
successful boots.
System boots OK, suspend works fine too. (5/5)
I cannot try hibernate as my swap partition is too small for that.
Thank you for all your hard work Alex!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Borislav Petkov]

On Fri, Aug 02, 2013 at 02:00:42PM +0800, Aaron Lu wrote:
> Assume you have specified to use intel_backlight in xorg.conf

Right, I have:

Section "Device"
Option "Backlight"  "intel_backlight"
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

in there currently.

> does booting with video.brightness_switch_enabled=0 help?

Nope.

Kernel command line is like this:

[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.0-rc3+ 
root=/dev/sdb2 ro root=/dev/sdb2 ignore_loglevel log_buf_len=10M 
resume=/dev/sdb1 acpi_backlight=vendor video.brightness_switch_enabled=0 
i915.i915_enable_rc6=4 i915.i915_enable_fbc=1 i915.lvds_downclock=1 
i915.powersave=1

and acpi_backlight=vendor doesn't make any difference. It still works
over sysfs though.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: add very basic support for audio block on DCE6

[Rafał Miłecki]

2013/8/2 Rafał Miłecki :
> It doesn't allow playing anything yet, but was the most tricky part to
> RE (it's indirect access, so couldn't trace it by dumping registers).
> Now we just need to implement support for HDMI blocks.

In case someone wonders, there is how I figured out that registers
offset and meaning:

WREG32(0x5e00, 0x0025);
RREG32(0x5e04); -> 0x00c0

WREG32(0x5e00, 0x0125);
WREG32(0x5e04, 0x00c1005f);

RREG32(0x00012c5c); -> 0x   AFMT_AUDIO_PACKET_CONTROL2
WREG32(0x00012c5c, 0xff00); AFMT_AUDIO_PACKET_CONTROL2

WREG32(0x5e00, 0x0027);
RREG32(0x5e04); -> 0x

WREG32(0x5e00, 0x0127); 0x5f80?
WREG32(0x5e04, 0x0040); 0x5f80?

WREG32(0x5e00, 0x000c3128); DESCRIPTOR0
WREG32(0x5e04, 0x7f077f07); DESCRIPTOR0

WREG32(0x5e00, 0x0129); DESCRIPTOR1
WREG32(0x5e04, 0x00500705); DESCRIPTOR1

WREG32(0x5e00, 0x012a); DESCRIPTOR2
WREG32(0x5e04, 0x); DESCRIPTOR2

One thing I don't understand yet is why writing to register 0x28
requires that extra 0x000c3000. It doesn't happen with any other one.

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Borislav Petkov]

On Fri, Aug 02, 2013 at 09:16:03AM +0800, Aaron Lu wrote:
> Since the sysfs interface works on your system, I think your problem
> should be different. Can you please file a bug for this? I can provide
> you with a debug patch and then see what happened. Please attach
> acpidump when filing the bug.
>
> https://bugzilla.kernel.org, ACPI/Power-Video.

Done: https://bugzilla.kernel.org/show_bug.cgi?id=60680

I did acpidump by hand but it should be ok.

Thanks for looking into this Aaron! :)

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378

[Ville Syrjälä]

On Thu, Aug 01, 2013 at 05:51:31PM -0700, Linus Torvalds wrote:
> This one may have been going on for some time - I haven't updated the
> old Intel Mac Mini in a while.
> 
> And by "not updated" I also mean that it's some really old user-space:
> the machine is running F14, and cannot be updated to anything newer
> without having to reinstall everything because of a stupid small /boot
> partition. So it's not going to happen. But maybe somebody cares about
> the i915 warning anyway?
> 
> Linus
> 
> ---
>WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378
> intel_sdvo_get_config+0x158/0x160()
>SDVO pixel multiplier mismatch, port: 0, encoder: 1
>Modules linked in: snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep
>CPU: 1 PID: 2846 Comm: Xorg Not tainted 3.11.0-rc3-00208-gbe1e8d7-dirty #19
>Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS
>   MM11.88Z.0055.B03.0604071521 04/07/06
>   ef0afa54 c1597bbb c1737ea4 ef0afa84 c10392ca c1737e6c
> ef0afab0 0b1e c1737ea4 0562 c12dfbe8 c12dfbe8 ef0afb14 
> f697ec00 ef0afa9c c103936e 0009 ef0afa94 c1737e6c ef0afab0 ef0afadc
>Call Trace:
> [] dump_stack+0x41/0x56
> [] warn_slowpath_common+0x7a/0xa0
> [] warn_slowpath_fmt+0x2e/0x30
> [] intel_sdvo_get_config+0x158/0x160
> [] check_crtc_state+0x1e0/0xb10
> [] intel_modeset_check_state+0x29d/0x7c0
> [] intel_sdvo_dpms+0x5c/0xa0
> [] drm_mode_obj_set_property_ioctl+0x40e/0x420
> [] drm_mode_connector_property_set_ioctl+0x35/0x40
> [] drm_ioctl+0x3e4/0x540
> [] do_vfs_ioctl+0x72/0x570
> [] SyS_ioctl+0x8f/0xa0
> [] sysenter_do_call+0x12/0x22
>---[ end trace 7ce940aff1366d60 ]---

Looks like this could happen when you go to DPMS_OFF. After we've turned
off the the pipe, get_pipe_config() gives a mostly zeroed pipe_config
(including pixel_multiplier), and then in the case of SDVO, we go and
check it against the encoder's idea of pixel_multiplier anyway.

I'm thinking perhaps we shouldn't call get_config for inactive
encoders. How about the following patch?

>From 16c4048bfb54e338ce23a7e98af96af2f58b0e0d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= 
Date: Fri, 2 Aug 2013 12:06:47 +0300
Subject: [PATCH] drm/i915: Don't call encoder's get_config unless encoder is
 active

---
 drivers/gpu/drm/i915/intel_display.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e1e50df..6396bca 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8549,9 +8549,11 @@ check_crtc_state(struct drm_device *dev)
 
list_for_each_entry(encoder, &dev->mode_config.encoder_list,
base.head) {
+   enum pipe pipe;
if (encoder->base.crtc != &crtc->base)
continue;
-   if (encoder->get_config)
+   if (encoder->get_config &&
+   encoder->get_hw_state(encoder, &pipe))
encoder->get_config(encoder, &pipe_config);
}
 
-- 
1.8.1.5

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: const'ify ioctls table

[Ville Syrjälä]

On Thu, Aug 01, 2013 at 02:25:27PM -0400, Rob Clark wrote:
> Because, there is no reason for it not to be const.
> 
> Signed-off-by: Rob Clark 
> ---

> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 78e2164..eaf86e0 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -124,7 +124,7 @@
>   * Ioctl definitions.
>   */
>  
> -static struct drm_ioctl_desc vmw_ioctls[] = {
> +static const struct drm_ioctl_desc vmw_ioctls[] = {
>   VMW_IOCTL_DEF(VMW_GET_PARAM, vmw_getparam_ioctl,
> DRM_AUTH | DRM_UNLOCKED),
>   VMW_IOCTL_DEF(VMW_ALLOC_DMABUF, vmw_dmabuf_alloc_ioctl,

You forgot to fix vmw_unlocked_ioctl().

Also if you're poking around this stuff, exynos and nouveau appear to
set .num_ioctls from the probe/init funcs even though the ioctls array
is right there in the same compilation unit.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Sylwester Nawrocki]

Hi Vikas,

On 08/02/2013 12:10 PM, Vikas Sajjan wrote:
> yeah, we could not allocate CMA region for FIMD, because the function
> dma_declare_contiguous() needs "dev" as the first argument and we have
> access to "dev" node only if it is NON-DT way of probing like the way
> it is done in arch/arm/mach-davinci/devices-da8xx.c
> But now, since the probing is through DT way, there is NO way ( Let me
> know if something is newly added ) to call dma_declare_contiguous()
> and reserve CMA region .

See this patch series [1]. We have have been using this kind of bindings
for assigning physically contiguous memory regions to the Exynos 
multimedia devices, instead of what's currently in mainline where same
physical addresses are repeated in dts for various boards without much
thought. And where custom device specific parsing code is required at 
arch side.

$ git grep mfc\-[lr] arch/arm/boot/dts

arch/arm/boot/dts/exynos4210-origen.dts: samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos4210-origen.dts: samsung,mfc-l = <0x5100 
0x80>;
arch/arm/boot/dts/exynos4210-smdkv310.dts:   samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos4210-smdkv310.dts:   samsung,mfc-l = <0x5100 
0x80>;
arch/arm/boot/dts/exynos4412-origen.dts: samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos4412-origen.dts: samsung,mfc-l = <0x5100 
0x80>;
arch/arm/boot/dts/exynos4412-smdk4412.dts:   samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos4412-smdk4412.dts:   samsung,mfc-l = <0x5100 
0x80>;
arch/arm/boot/dts/exynos5250-arndale.dts:samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos5250-arndale.dts:samsung,mfc-l = <0x5100 
0x80>;
arch/arm/boot/dts/exynos5250-smdk5250.dts:   samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos5250-smdk5250.dts:   samsung,mfc-l = <0x5100 
0x80>;


[1] http://www.spinics.net/lists/arm-kernel/msg263130.html

Regards,
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

Shawn Starr  changed:

   What|Removed |Added

  Attachment #83469|0   |1
is obsolete||

--- Comment #72 from Shawn Starr  ---
Comment on attachment 83469
  --> https://bugs.freedesktop.org/attachment.cgi?id=83469
Corrupt screen 'frosting' after DPM enabled #1

This is due to missing some of the firmware.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

Shawn Starr  changed:

   What|Removed |Added

  Attachment #83470|0   |1
is obsolete||

--- Comment #73 from Shawn Starr  ---
Comment on attachment 83470
  --> https://bugs.freedesktop.org/attachment.cgi?id=83470
Corrupt screen 'frosting' after DPM enabled #2 both screens

This is due to missing some of the firmware.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #74 from Shawn Starr  ---
RV635 works for me. 

Make sure you have all of the firmware if you compile this kernel make sure
kernel firmware is installed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: add very basic support for audio block on DCE6

[Alex Deucher]

On Fri, Aug 2, 2013 at 4:11 AM, Rafał Miłecki  wrote:
> It doesn't allow playing anything yet, but was the most tricky part to
> RE (it's indirect access, so couldn't trace it by dumping registers).
> Now we just need to implement support for HDMI blocks.

We actually have code implemented internally for DCE6/8 that we are
hoping to release for 3.12.

Alex

>
> Signed-off-by: Rafał Miłecki 
> ---
>  drivers/gpu/drm/radeon/Makefile  |2 +-
>  drivers/gpu/drm/radeon/dce6_afmt.c   |   88 
> ++
>  drivers/gpu/drm/radeon/radeon_asic.h |2 +
>  drivers/gpu/drm/radeon/si.c  |7 +++
>  drivers/gpu/drm/radeon/sid.h |5 ++
>  5 files changed, 103 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/radeon/dce6_afmt.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index c3df52c..6510fc4 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -79,7 +79,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> si_blit_shaders.o radeon_prime.o radeon_uvd.o cik.o 
> cik_blit_shaders.o \
> r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o 
> rv740_dpm.o \
> rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
> trinity_dpm.o \
> -   trinity_smc.o ni_dpm.o si_smc.o si_dpm.o
> +   trinity_smc.o ni_dpm.o si_smc.o si_dpm.o dce6_afmt.o
>
>  radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
>  radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
> diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
> b/drivers/gpu/drm/radeon/dce6_afmt.c
> new file mode 100644
> index 000..0d98143
> --- /dev/null
> +++ b/drivers/gpu/drm/radeon/dce6_afmt.c
> @@ -0,0 +1,88 @@
> +/*
> + * Copyright © 2013 Rafał Miłecki 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors: Rafał Miłecki
> + */
> +#include 
> +#include 
> +#include "radeon.h"
> +#include "radeon_asic.h"
> +#include "sid.h"
> +
> +static u32 dce6_audio_read(struct radeon_device *rdev, u32 reg)
> +{
> +   WREG32(SI_AUDIO_ADDR, reg);
> +   return RREG32(SI_AUDIO_DATA);
> +}
> +
> +static void dce6_audio_write(struct radeon_device *rdev, u32 reg, u32 v)
> +{
> +   reg |= SI_AUDIO_ADDR_WRITE;
> +   WREG32(SI_AUDIO_ADDR, reg);
> +   WREG32(SI_AUDIO_DATA, v);
> +}
> +
> +static void dce6_audio_maskset(struct radeon_device *rdev, u32 reg, u32 mask,
> +  u32 set)
> +{
> +   u32 tmp = dce6_audio_read(rdev, reg);
> +   tmp &= mask;
> +   tmp |= set & ~mask;
> +   dce6_audio_write(rdev, reg, tmp);
> +}
> +
> +static void dce6_audio_enable(struct radeon_device *rdev, bool enable)
> +{
> +   DRM_INFO("%s audio support\n", enable ? "Enabling" : "Disabling");
> +
> +   if (enable) {
> +   dce6_audio_maskset(rdev, 0x54, ~0x8000, 0x8000);
> +   } else {
> +   dce6_audio_maskset(rdev, 0x54, ~0x8000, 0);
> +   /* TODO: clear some bit(s) in reg 0x36 */
> +   }
> +
> +   rdev->audio_enabled = enable;
> +}
> +
> +int dce6_audio_init(struct radeon_device *rdev)
> +{
> +   if (!radeon_audio)
> +   return 0;
> +
> +   dce6_audio_enable(rdev, true);
> +
> +   rdev->audio_status.channels = -1;
> +   rdev->audio_status.rate = -1;
> +   rdev->audio_status.bits_per_sample = -1;
> +   rdev->audio_status.status_bits = 0;
> +   rdev->audio_status.category_code = 0;
> +
> +   return 0;
> +}
> +
> +void dce6_audio_fini(struct radeon_device *rdev)
> +{
> +   if (!rdev->audio_enabled)
> +   return;
> +
> +   dce6_audio_enable(rdev, false);
> +}
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
> b/drivers/gpu/drm/radeon/radeon_asic.h
> index ca18957..48674ca 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> +++ b/drivers/gpu/drm/radeon/radeon_

Re: [PATCH] drm/radeon: add very basic support for audio block on DCE6

[Rafał Miłecki]

2013/8/2 Alex Deucher :
> On Fri, Aug 2, 2013 at 4:11 AM, Rafał Miłecki  wrote:
>> It doesn't allow playing anything yet, but was the most tricky part to
>> RE (it's indirect access, so couldn't trace it by dumping registers).
>> Now we just need to implement support for HDMI blocks.
>
> We actually have code implemented internally for DCE6/8 that we are
> hoping to release for 3.12.

Can you rebase it on my patches, please?

We already got few cases of just-to-be-released code, that couldn't be
release so fast.

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: add very basic support for audio block on DCE6

[Rafał Miłecki]

2013/8/2 Rafał Miłecki :
> 2013/8/2 Alex Deucher :
>> On Fri, Aug 2, 2013 at 4:11 AM, Rafał Miłecki  wrote:
>>> It doesn't allow playing anything yet, but was the most tricky part to
>>> RE (it's indirect access, so couldn't trace it by dumping registers).
>>> Now we just need to implement support for HDMI blocks.
>>
>> We actually have code implemented internally for DCE6/8 that we are
>> hoping to release for 3.12.
>
> Can you rebase it on my patches, please?
>
> We already got few cases of just-to-be-released code, that couldn't be
> release so fast.

P.S.
I've code for HDMI working as well, I'm planning to release it on
Monday. So that hopefully will make your changes minimal for DCE6.

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: const'ify ioctls table

[Rob Clark]

On Fri, Aug 2, 2013 at 6:51 AM, Ville Syrjälä
 wrote:
> On Thu, Aug 01, 2013 at 02:25:27PM -0400, Rob Clark wrote:
>> Because, there is no reason for it not to be const.
>>
>> Signed-off-by: Rob Clark 
>> ---
> 
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> index 78e2164..eaf86e0 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> @@ -124,7 +124,7 @@
>>   * Ioctl definitions.
>>   */
>>
>> -static struct drm_ioctl_desc vmw_ioctls[] = {
>> +static const struct drm_ioctl_desc vmw_ioctls[] = {
>>   VMW_IOCTL_DEF(VMW_GET_PARAM, vmw_getparam_ioctl,
>> DRM_AUTH | DRM_UNLOCKED),
>>   VMW_IOCTL_DEF(VMW_ALLOC_DMABUF, vmw_dmabuf_alloc_ioctl,
>
> You forgot to fix vmw_unlocked_ioctl().

yeah, kbuild robot caught that too.. somehow I didn't have vmwgfx
enabled in my config (opps!).. fixed now

> Also if you're poking around this stuff, exynos and nouveau appear to
> set .num_ioctls from the probe/init funcs even though the ioctls array
> is right there in the same compilation unit.

good idea, I've squashed that in, so will be part of v2

BR,
-R

> --
> Ville Syrjälä
> Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Rafael J. Wysocki]

On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa  wrote:
> > Hello,
> >
> > I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
> > change to this parameter to the kernel boot:
> >
> >
> > GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\""
> 
> I think it's pretty obvious that for the time being we need to
> blacklist a ton of machines so they boot without this OSI. In fact, in
> might make sense to simply remove the OSI completely for all machines
> (for now).

That would have made sense 6 months ago, but not today.

The reason is that you don't really know what's affected by that and I'm
pretty sure it's not only backlight.

So no, we won't do that.

We *might* blacklist machines that shipped with Windows 7, but whose BIOSes
call the Windows 8 OSI, because there's a good chance they weren't really
tested with Windows 8.

Thanks,
Rafael

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: add very basic support for audio block on DCE6

[Alex Deucher]

On Fri, Aug 2, 2013 at 9:40 AM, Rafał Miłecki  wrote:
> 2013/8/2 Alex Deucher :
>> On Fri, Aug 2, 2013 at 4:11 AM, Rafał Miłecki  wrote:
>>> It doesn't allow playing anything yet, but was the most tricky part to
>>> RE (it's indirect access, so couldn't trace it by dumping registers).
>>> Now we just need to implement support for HDMI blocks.
>>
>> We actually have code implemented internally for DCE6/8 that we are
>> hoping to release for 3.12.
>
> Can you rebase it on my patches, please?
>
> We already got few cases of just-to-be-released code, that couldn't be
> release so fast.

Maybe.  It depends how divergent it is.  There are actually a fair
amount of structural changes needed support the hw changes properly.
I guess I'll wait and see what your code looks like.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #75 from Shawn Starr  ---
(In reply to comment #74)
> RV635 works for me. 
> 
> Make sure you have all of the firmware if you compile this kernel make sure
> kernel firmware is installed.

Well, it works but the clocking isn't adjusting properly. Working on IRC with
Alex, but no crashes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Josep Lladonosa]

Hello,

I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
change to this parameter to the kernel boot:


GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\""


instead of previous

GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"

to be able to change brightness. In some kernel versions before, it
worked, but with 15 levels, but in graphical system brightness bar was
not moving.


Now I have, though, 8 possible values for brightness and brightness
bar shows its correct position.

Josep

On 2 August 2013 08:00, Aaron Lu  wrote:
> On 08/01/2013 04:07 PM, Borislav Petkov wrote:
>> On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
>>> Does reverting efaa14c help?
>>
>> Nope.
>>
>> But see my other reply to Aaron.
>
> Assume you have specified to use intel_backlight in xorg.conf, does
> booting with video.brightness_switch_enabled=0 help?
>
> Thanks,
> Aaron
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
--
Salutacions...Josep
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Josep Lladonosa]

Hello,

Yes, it works! I get now 11 levels from all black to the brightest.

acpi_listen shows messages

Josep

On 2 August 2013 08:36, Aaron Lu  wrote:
> On 08/02/2013 02:25 PM, Josep Lladonosa wrote:
>> Hello,
>>
>> I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
>> change to this parameter to the kernel boot:
>>
>>
>> GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\""
>
> What if you remove the above from kernel command line, and add
> video.brightness_switch_enabled=0 to kernel command line, then set the
> following in xorg.conf:
> $ cat /etc/X11/xorg.conf
> Section "Device"
> Option "Backlight"  "intel_backlight"
> Identifier  "Card0"
> Driver  "intel"
> BusID   "PCI:0:2:0"
> EndSection
>
> Does everything work?
>
> If not, please test if manually change brightness level through sysfs
> works:
> # cd /sys/calss/backlight/intel_backlight
> # echo xxx > brightness
>
> And also test if hotkey event is sent out or not by running acpi_listen
> and then press the hotkey.
>
> Thanks,
> Aaron
>
>>
>>
>> instead of previous
>>
>> GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
>>
>> to be able to change brightness. In some kernel versions before, it
>> worked, but with 15 levels, but in graphical system brightness bar was
>> not moving.
>>
>>
>> Now I have, though, 8 possible values for brightness and brightness
>> bar shows its correct position.
>>
>> Josep
>>
>> On 2 August 2013 08:00, Aaron Lu  wrote:
>>> On 08/01/2013 04:07 PM, Borislav Petkov wrote:
 On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
> Does reverting efaa14c help?

 Nope.

 But see my other reply to Aaron.
>>>
>>> Assume you have specified to use intel_backlight in xorg.conf, does
>>> booting with video.brightness_switch_enabled=0 help?
>>>
>>> Thanks,
>>> Aaron
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>>
>>
>



-- 
--
Salutacions...Josep
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Aaron Lu]

On 08/01/2013 04:07 PM, Borislav Petkov wrote:
> On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
>> Does reverting efaa14c help?
> 
> Nope.
> 
> But see my other reply to Aaron.

Assume you have specified to use intel_backlight in xorg.conf, does
booting with video.brightness_switch_enabled=0 help?

Thanks,
Aaron
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Aaron Lu]

On 08/02/2013 02:25 PM, Josep Lladonosa wrote:
> Hello,
> 
> I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
> change to this parameter to the kernel boot:
> 
> 
> GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\""

What if you remove the above from kernel command line, and add
video.brightness_switch_enabled=0 to kernel command line, then set the
following in xorg.conf:
$ cat /etc/X11/xorg.conf
Section "Device"
Option "Backlight"  "intel_backlight"
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

Does everything work?

If not, please test if manually change brightness level through sysfs
works:
# cd /sys/calss/backlight/intel_backlight
# echo xxx > brightness

And also test if hotkey event is sent out or not by running acpi_listen
and then press the hotkey.

Thanks,
Aaron

> 
> 
> instead of previous
> 
> GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
> 
> to be able to change brightness. In some kernel versions before, it
> worked, but with 15 levels, but in graphical system brightness bar was
> not moving.
> 
> 
> Now I have, though, 8 possible values for brightness and brightness
> bar shows its correct position.
> 
> Josep
> 
> On 2 August 2013 08:00, Aaron Lu  wrote:
>> On 08/01/2013 04:07 PM, Borislav Petkov wrote:
>>> On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
 Does reverting efaa14c help?
>>>
>>> Nope.
>>>
>>> But see my other reply to Aaron.
>>
>> Assume you have specified to use intel_backlight in xorg.conf, does
>> booting with video.brightness_switch_enabled=0 help?
>>
>> Thanks,
>> Aaron
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Vikas Sajjan]

Hi Rob,

On 2 August 2013 06:03, Rob Clark  wrote:
> On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa  wrote:
>> Hi Vikas,
>>
>> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
>>> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
>>> connected with resolution 2560x1600, following error occured even with
>>> IOMMU enabled:
>>> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
>>> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>>
>>> This patch fixes the issue by adding a check for IOMMU.
>>>
>>> Signed-off-by: Vikas Sajjan 
>>> Signed-off-by: Arun Kumar 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
>>> 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> @@ -16,6 +16,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  #include "exynos_drm_drv.h"
>>>  #include "exynos_drm_fb.h"
>>> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
>>> drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
>>>   unsigned long size;
>>>   int ret;
>>> + unsigned int flag;
>>>
>>>   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
>>>   sizes->surface_width, sizes->surface_height,
>>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
>>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>>>
>>>   /* 0 means to allocate physically continuous memory */
>>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
>>> + if (!is_drm_iommu_supported(dev))
>>> + flag = 0;
>>> + else
>>> + flag = EXYNOS_BO_NONCONTIG;
>>
>> While noncontig memory might be used for devices that support IOMMU, there
>> should be no problem with using contig memory for them, so this seems more
>> like masking the original problem rather than tracking it down.
>
> it is probably a good idea to not require contig memory when it is not
> needed for performance or functionality (and if it is only
> performance, then fallback gracefully to non-contig).. but yeah, would
> be good to know if this is masking another issue all the same
>

Whats happening with CONTIG flag and with IOMMU,  is

 __iommu_alloc_buffer() ---> dma_alloc_from_contiguous() and in this
function it fails at
this condition check  if (pageno >= cma->count)

So I tried increasing the CONFIG_CMA_SIZE_MBYTES to 24,  this check
succeeds and it works well without my patch.

But what about the case where CONFIG_CMA is disabled , yet i want
bigger memory for a device.
 I think using IOMMU we can achieve this.

 correct me, if i am wrong.


> BR,
> -R
>
>> Could you check why the allocation fails when requesting contiguous
>> memory?
>>
>> Best regards,
>> Tomasz
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks and Regards
 Vikas Sajjan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau/acpi: de-dup use of DSM methods

[Peter Wu]

On Friday 02 August 2013 15:58:38 Dave Airlie wrote:
> On Fri, Aug 2, 2013 at 12:41 AM, Peter Wu  wrote:
> > Observe that nouveau_optimus_dsm and nouveau_dsm are equal except for
> > the parameters handling (UUID, revision ID and function arguments). The
> > function arguments are passed as Buffer in the "optimus dsm" and Integer
> > in "nvidia dsm". As buffers are implicitly converted to integers, merge
> > both functions.
> > 
> > The ACPI spec defines the fourth parameter (Arg3 a.k.a. "function
> > arguments") as Package, but many BIOSes expect a Buffer instead. For
> > instance, for the "nvidia DSM", the Lenovo T410s uses CreateByteField on
> > Arg3 which does not work with a package. The Clevo B7130 does something
> > similar for the "Optimus DSM". Unfortunately, this means that the
> > following ACPI warning (introduced with 29a241c) cannot be fixed (when
> 
> > toggling power or muxing):
> By cannot be fixed, why is it there then? maybe ask the ACPI folks to
> drop this error, since as far as I can see all optimus dsm want a
> buffer here.

It helps tracking violations of the ACPI spec which can be used as debugging 
tool, as a result there is also a patch for i915 (which was based on this 
nouveau code). Of course, if real world only uses Buffers, then this warning 
should be dropped/changed, but there are more users of _DSM besides the 
graphics subsystem.

Regards,
Peter

> > ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found
> > [Buffer], ACPI requires [Package] (20130517/nsarguments-95) ACPI
> > Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found
> > [Buffer], ACPI requires [Package] (20130517/nsarguments-95) ACPI
> > Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
> > [Buffer], ACPI requires [Package] (20130517/nsarguments-95) ACPI
> > Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
> > [Buffer], ACPI requires [Package] (20130517/nsarguments-95)> 
> > Signed-off-by: Peter Wu 
> > ---
> > 
> >  drivers/gpu/drm/nouveau/nouveau_acpi.c | 67
> >  ++ 1 file changed, 20 insertions(+), 47
> >  deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> > b/drivers/gpu/drm/nouveau/nouveau_acpi.c index d97f200..a75684f 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> > @@ -46,6 +46,9 @@ bool nouveau_is_v1_dsm(void) {
> > 
> >  #define NOUVEAU_DSM_HAS_MUX 0x1
> >  #define NOUVEAU_DSM_HAS_OPT 0x2
> > 
> > +#define NOUVEAU_DSM_REVID_NVIDIA 0x102
> > +#define NOUVEAU_DSM_REVID_OPTIMUS 0x100
> > +
> > 
> >  static const char nouveau_dsm_muid[] = {
> >  
> > 0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
> > 0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4,
> > 
> > @@ -56,7 +59,8 @@ static const char nouveau_op_dsm_muid[] = {
> > 
> > 0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
> >  
> >  };
> > 
> > -static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg,
> > uint32_t *result) +static int nouveau_call_dsm(acpi_handle handle, const
> > char *uuid, int revid, +   int func, int arg, uint32_t *result)
> > 
> >  {
> >  
> > struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> > struct acpi_object_list input;
> > 
> > @@ -68,12 +72,15 @@ static int nouveau_optimus_dsm(acpi_handle handle, int
> > func, int arg, uint32_t *> 
> > input.count = 4;
> > input.pointer = params;
> > params[0].type = ACPI_TYPE_BUFFER;
> > 
> > -   params[0].buffer.length = sizeof(nouveau_op_dsm_muid);
> > -   params[0].buffer.pointer = (char *)nouveau_op_dsm_muid;
> > +   params[0].buffer.length = 16;
> > +   params[0].buffer.pointer = (char *)uuid;
> > 
> > params[1].type = ACPI_TYPE_INTEGER;
> > 
> > -   params[1].integer.value = 0x0100;
> > +   params[1].integer.value = revid;
> > 
> > params[2].type = ACPI_TYPE_INTEGER;
> > params[2].integer.value = func;
> > 
> > +   /* Although the ACPI spec defines Arg3 as a Package, in practise
> > +* implementations expect a Buffer (CreateWordField and Index
> > functions +* are applied to it). */
> > 
> > params[3].type = ACPI_TYPE_BUFFER;
> > params[3].buffer.length = 4;
> > /* ACPI is little endian, AABBCCDD becomes {DD,CC,BB,AA} */
> > 
> > @@ -108,50 +115,16 @@ static int nouveau_optimus_dsm(acpi_handle handle,
> > int func, int arg, uint32_t *> 
> > return 0;
> >  
> >  }
> > 
> > -static int nouveau_dsm(acpi_handle handle, int func, int arg, uint32_t
> > *result) -{
> > -   struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> > -   struct acpi_object_list input;
> > -   union acpi_object params[4];
> > -   union acpi_object *obj;
> > -   int err;
> > -
> > -   input.count = 4;
> > -   input.pointer = params;
> > -   params[0].type = ACPI_TYPE_BU

Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Vikas Sajjan]

Hi Inki Dae,

On 2 August 2013 12:58, Inki Dae  wrote:
>
>
> 2013/8/2 Vikas Sajjan 
>>
>> Hi Rob,
>>
>> On 2 August 2013 06:03, Rob Clark  wrote:
>> > On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa 
>> > wrote:
>> >> Hi Vikas,
>> >>
>> >> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
>> >>> While trying to get boot-logo up on exynos5420 SMDK which has eDP
>> >>> panel
>> >>> connected with resolution 2560x1600, following error occured even with
>> >>> IOMMU enabled:
>> >>> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
>> >>> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>> >>>
>> >>> This patch fixes the issue by adding a check for IOMMU.
>> >>>
>> >>> Signed-off-by: Vikas Sajjan 
>> >>> Signed-off-by: Arun Kumar 
>> >>> ---
>> >>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>> >>>  1 file changed, 8 insertions(+), 1 deletion(-)
>> >>>
>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> >>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
>> >>> 100644
>> >>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> >>> @@ -16,6 +16,7 @@
>> >>>  #include 
>> >>>  #include 
>> >>>  #include 
>> >>> +#include 
>> >>>
>> >>>  #include "exynos_drm_drv.h"
>> >>>  #include "exynos_drm_fb.h"
>> >>> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
>> >>> drm_fb_helper *helper, struct platform_device *pdev =
>> >>> dev->platformdev;
>> >>>   unsigned long size;
>> >>>   int ret;
>> >>> + unsigned int flag;
>> >>>
>> >>>   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
>> >>>   sizes->surface_width, sizes->surface_height,
>> >>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
>> >>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>> >>>
>> >>>   /* 0 means to allocate physically continuous memory */
>> >>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
>> >>> + if (!is_drm_iommu_supported(dev))
>> >>> + flag = 0;
>> >>> + else
>> >>> + flag = EXYNOS_BO_NONCONTIG;
>> >>
>> >> While noncontig memory might be used for devices that support IOMMU,
>> >> there
>> >> should be no problem with using contig memory for them, so this seems
>> >> more
>> >> like masking the original problem rather than tracking it down.
>> >
>> > it is probably a good idea to not require contig memory when it is not
>> > needed for performance or functionality (and if it is only
>> > performance, then fallback gracefully to non-contig).. but yeah, would
>> > be good to know if this is masking another issue all the same
>> >
>>
>> Whats happening with CONTIG flag and with IOMMU,  is
>>
>>  __iommu_alloc_buffer() ---> dma_alloc_from_contiguous() and in this
>> function it fails at
>> this condition check  if (pageno >= cma->count)
>>
>> So I tried increasing the CONFIG_CMA_SIZE_MBYTES to 24,  this check
>> succeeds and it works well without my patch.
>>
>> But what about the case where CONFIG_CMA is disabled , yet i want
>> bigger memory for a device.
>>  I think using IOMMU we can achieve this.
>>
>>  correct me, if i am wrong.
>>
>
> I'm on summer vacation so I'm afraid that I cannot test and look into it but
> I guess you guy didn't declare CMA region for Exynos drm. And in this case,
> the size of CMA declared region is 16MB as default. That is why works well
> after increasing default size, CONFIG_CMA_SIZE_MBYTES, to 24MB. And I
> mentioned long time ago, we are required to use physically contiguous memory
> in case that bootloader uses physically contiguous memory for its own
> framebuffer, and kernel wants to share the bootloader's framebuffer region
> to resolve flickering issue while booted; that is required for product. And
> one question, is there any reason that you guy should use non-contiguous
> memory for framebuffer with iommu?
>

yeah, we could not allocate CMA region for FIMD, because the function
dma_declare_contiguous() needs "dev" as the first argument and we have
access to "dev" node only if it is NON-DT way of probing like the way
it is done in arch/arm/mach-davinci/devices-da8xx.c
But now, since the probing is through DT way, there is NO way ( Let me
know if something is newly added ) to call dma_declare_contiguous()
and reserve CMA region .

we don't have any specific requirement for NON_CONTIG or CONTIG
memory, but only requirement was to allocate a bigger memory like (
2560 * 1600 * 4 ) for FB.

But as Rob suggested, we should have fall-back case if CONTIG memory
allocation fails, as below

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index df43fa9..15de626 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -144,7 +144,6 @@ static int exynos_drm_fbdev_create(struct
drm_fb_helper *helper,
struct platform_device *

[PATCH] drm: don't push static constants on stack for %*ph

[Andy Shevchenko]

There is no need to pass constants via stack. The width may be explicitly
specified in the format.

Signed-off-by: Andy Shevchenko 
---
 drivers/gpu/drm/nouveau/core/engine/disp/dport.c | 2 +-
 drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
 drivers/gpu/drm/udl/udl_main.c   | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
index 31cc8fe..054d9cf 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
@@ -150,7 +150,7 @@ dp_link_train_update(struct dp_state *dp, u32 delay)
if (ret)
return ret;
 
-   DBG("status %*ph\n", 6, dp->stat);
+   DBG("status %6ph\n", dp->stat);
return 0;
 }
 
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 32501f6..3569d89 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -585,7 +585,7 @@ static bool radeon_dp_get_link_status(struct 
radeon_connector *radeon_connector,
return false;
}
 
-   DRM_DEBUG_KMS("link status %*ph\n", 6, link_status);
+   DRM_DEBUG_KMS("link status %6ph\n", link_status);
return true;
 }
 
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 0ce2d71..f5ae574 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -41,8 +41,8 @@ static int udl_parse_vendor_descriptor(struct drm_device *dev,
total_len = usb_get_descriptor(usbdev, 0x5f, /* vendor specific */
0, desc, MAX_VENDOR_DESCRIPTOR_SIZE);
if (total_len > 5) {
-   DRM_INFO("vendor descriptor length:%x data:%*ph\n",
-   total_len, 11, desc);
+   DRM_INFO("vendor descriptor length:%x data:%11ph\n",
+   total_len, desc);
 
if ((desc[0] != total_len) || /* descriptor length */
(desc[1] != 0x5f) ||   /* vendor descriptor type */
-- 
1.8.4.rc0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/radeon: add very basic support for audio block on DCE6

[Rafał Miłecki]

2013/8/2 Alex Deucher :
> On Fri, Aug 2, 2013 at 9:40 AM, Rafał Miłecki  wrote:
>> 2013/8/2 Alex Deucher :
>>> On Fri, Aug 2, 2013 at 4:11 AM, Rafał Miłecki  wrote:
 It doesn't allow playing anything yet, but was the most tricky part to
 RE (it's indirect access, so couldn't trace it by dumping registers).
 Now we just need to implement support for HDMI blocks.
>>>
>>> We actually have code implemented internally for DCE6/8 that we are
>>> hoping to release for 3.12.
>>
>> Can you rebase it on my patches, please?
>>
>> We already got few cases of just-to-be-released code, that couldn't be
>> release so fast.
>
> Maybe.  It depends how divergent it is.  There are actually a fair
> amount of structural changes needed support the hw changes properly.
> I guess I'll wait and see what your code looks like.

OK. It's similar to the current DCE2/3/4 support and register
operations are based on fglrx MMIO dump, so they should be pretty much
correct. It's not programming based on regs dumps only anymore :)

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64503] audio glitches when running at 24hz/24p

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #20 from Pierre Ossman  ---
First off, I've upgraded to Fedora 19 and kernel-3.10.3-300.fc19.x86_64. That
in itself had no effect on the bug, good or bad.

(In reply to comment #19)
> does this patch help:
> http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.
> 11&id=dffd4b65ca8989acb914da3c685c798ca5fcf99c

I also had to apply these two:

http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=7d61d835824f73dc4097b51f800382467c8049c5
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=9509f9a174b39db215edf7752de4847eaaca2775

Unfortunately the problem remains. =/

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Regression introduced by 31f731a drm/radeon/dpm: fix calculations in si_calculate_leakage_for_v_and_t_formula

[Konrad Rzeszutek Wilk]

Hey Alex,

Your recent patch "31f731a drm/radeon/dpm: fix calculations in
si_calculate_leakage_for_v_and_t_formula" causes a build regression:

drivers/built-in.o: In function `si_calculate_leakage_for_v_and_t_formula':
/home/build/linux-linus/drivers/gpu/drm/radeon/si_dpm.c:1770: undefined
reference to `__divdi3'

Which I think is due to the misplace parentheses.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Regression introduced by 31f731a drm/radeon/dpm: fix calculations in si_calculate_leakage_for_v_and_t_formula

[Alex Deucher]

On Fri, Aug 2, 2013 at 11:16 AM, Konrad Rzeszutek Wilk
 wrote:
> Hey Alex,
>
> Your recent patch "31f731a drm/radeon/dpm: fix calculations in
> si_calculate_leakage_for_v_and_t_formula" causes a build regression:
>
> drivers/built-in.o: In function `si_calculate_leakage_for_v_and_t_formula':
> /home/build/linux-linus/drivers/gpu/drm/radeon/si_dpm.c:1770: undefined
> reference to `__divdi3'
>
> Which I think is due to the misplace parentheses.

Fixed with this patch:
http://lists.freedesktop.org/archives/dri-devel/2013-August/042668.html

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64503] audio glitches when running at 24hz/24p

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #21 from Pierre Ossman  ---
Just to confirm this is a driver problem, I tried two things:

 - Hooked up a Windows machine (also with a radeon card, although a different
one)

 - Installed fglrx on my Linux machine.

In both cases the playback was glitch free in 24 Hz.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66384] VDPAU playback hangs when moving window between xrandr monitors

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66384

--- Comment #2 from Michel Dänzer  ---
Created attachment 83546
  --> https://bugs.freedesktop.org/attachment.cgi?id=83546&action=edit
Attempt at making DRI2 MSC counter consistent between CRTCs

Here's an attempt at making the DRI2 MSC counter per-window instead of
per-CRTC. I couldn't quite make it work, but maybe someone can run with this
and finish it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: don't push static constants on stack for %*ph

[David Herrmann]

Hi

On Fri, Aug 2, 2013 at 1:09 PM, Andy Shevchenko
 wrote:
> There is no need to pass constants via stack. The width may be explicitly
> specified in the format.

Yupp, all 3 make sense and actually speed up "format_decode()".
  Reviewed-by: David Herrmann 

Regards
David

> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/gpu/drm/nouveau/core/engine/disp/dport.c | 2 +-
>  drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
>  drivers/gpu/drm/udl/udl_main.c   | 4 ++--
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c 
> b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
> index 31cc8fe..054d9cf 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
> @@ -150,7 +150,7 @@ dp_link_train_update(struct dp_state *dp, u32 delay)
> if (ret)
> return ret;
>
> -   DBG("status %*ph\n", 6, dp->stat);
> +   DBG("status %6ph\n", dp->stat);
> return 0;
>  }
>
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index 32501f6..3569d89 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -585,7 +585,7 @@ static bool radeon_dp_get_link_status(struct 
> radeon_connector *radeon_connector,
> return false;
> }
>
> -   DRM_DEBUG_KMS("link status %*ph\n", 6, link_status);
> +   DRM_DEBUG_KMS("link status %6ph\n", link_status);
> return true;
>  }
>
> diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
> index 0ce2d71..f5ae574 100644
> --- a/drivers/gpu/drm/udl/udl_main.c
> +++ b/drivers/gpu/drm/udl/udl_main.c
> @@ -41,8 +41,8 @@ static int udl_parse_vendor_descriptor(struct drm_device 
> *dev,
> total_len = usb_get_descriptor(usbdev, 0x5f, /* vendor specific */
> 0, desc, MAX_VENDOR_DESCRIPTOR_SIZE);
> if (total_len > 5) {
> -   DRM_INFO("vendor descriptor length:%x data:%*ph\n",
> -   total_len, 11, desc);
> +   DRM_INFO("vendor descriptor length:%x data:%11ph\n",
> +   total_len, desc);
>
> if ((desc[0] != total_len) || /* descriptor length */
> (desc[1] != 0x5f) ||   /* vendor descriptor type */
> --
> 1.8.4.rc0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64503] audio glitches when running at 24hz/24p

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #22 from Pierre Ossman  ---
Argh! Problem found...

It was actually the mode that was incorrect. xrandr rounds things off, so it
looked like it was the same as the working case, but actually wasn't.

Proper modeline:

Modeline "1920x1080"x24.0   74.25  1920 2558 2602 2750  1080 1084 1089 1125
+hsync +vsync (27.0 kHz e)

Horrible evil modeline:

ModeLine "1920x1080@23.976" 74.175 1920 2558 2602 2750 1080 1084 1089 1125
+hsync +vsync


The reason I had that was from back in ancient times when the radeon driver
didn't properly grok the 24p mode from EDID for some reason. But it seems I got
the NTSC I-can't-believe-it's-not-real-24p mode instead of the proper film one.


So with that hack removed it seems like the audio glitch is gone. Sorry for all
the noise. :/

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm: Remove drm_mode_validate_clocks

[David Herrmann]

Hi

On Wed, Jul 31, 2013 at 2:23 AM, Stéphane Marchesin
 wrote:
> Signed-off-by: Stéphane Marchesin 

Something like "unused" in the commit message makes "git log
[--oneline]" much more verbose without the need to read the patch.
Apart from that:
  Reviewed-by: David Herrmann 

I also did a short "grep MODE_CLOCK_RANGE" and radeon/i915 tv-helpers
are the last users. All others use MODE_BAD. But I guess
MODE_CLOCK_RANGE is more verbose so there is no need to remove it.

Regards
David

> ---
>  drivers/gpu/drm/drm_modes.c | 37 -
>  include/drm/drm_crtc.h  |  3 ---
>  2 files changed, 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index a6729bf..504a602 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -923,43 +923,6 @@ void drm_mode_validate_size(struct drm_device *dev,
>  EXPORT_SYMBOL(drm_mode_validate_size);
>
>  /**
> - * drm_mode_validate_clocks - validate modes against clock limits
> - * @dev: DRM device
> - * @mode_list: list of modes to check
> - * @min: minimum clock rate array
> - * @max: maximum clock rate array
> - * @n_ranges: number of clock ranges (size of arrays)
> - *
> - * LOCKING:
> - * Caller must hold a lock protecting @mode_list.
> - *
> - * Some code may need to check a mode list against the clock limits of the
> - * device in question.  This function walks the mode list, testing to make
> - * sure each mode falls within a given range (defined by @min and @max
> - * arrays) and sets @mode->status as needed.
> - */
> -void drm_mode_validate_clocks(struct drm_device *dev,
> - struct list_head *mode_list,
> - int *min, int *max, int n_ranges)
> -{
> -   struct drm_display_mode *mode;
> -   int i;
> -
> -   list_for_each_entry(mode, mode_list, head) {
> -   bool good = false;
> -   for (i = 0; i < n_ranges; i++) {
> -   if (mode->clock >= min[i] && mode->clock <= max[i]) {
> -   good = true;
> -   break;
> -   }
> -   }
> -   if (!good)
> -   mode->status = MODE_CLOCK_RANGE;
> -   }
> -}
> -EXPORT_SYMBOL(drm_mode_validate_clocks);
> -
> -/**
>   * drm_mode_prune_invalid - remove invalid modes from mode list
>   * @dev: DRM device
>   * @mode_list: list of modes to check
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index fa12a2f..32e0820 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -930,9 +930,6 @@ extern void drm_mode_list_concat(struct list_head *head,
>  extern void drm_mode_validate_size(struct drm_device *dev,
>struct list_head *mode_list,
>int maxX, int maxY, int maxPitch);
> -extern void drm_mode_validate_clocks(struct drm_device *dev,
> -struct list_head *mode_list,
> -int *min, int *max, int n_ranges);
>  extern void drm_mode_prune_invalid(struct drm_device *dev,
>struct list_head *mode_list, bool verbose);
>  extern void drm_mode_sort(struct list_head *mode_list);
> --
> 1.8.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60523] Lockup with radeon DPM on Radeon HD5770 (Juniper)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=60523

--- Comment #14 from Tobias Droste  ---
I changed rv770_smc.c to this: http://pastebin.com/eMzfrAaZ, but there aren't
any message in dmesg after booting.

'echo low > power_dpm_force_performance_level' fails, but is also not printing
something to dmesg. 
Changing from 1 monitor to 2 and back is also not printing something to dmesg.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] radeon: si_dpm.c: avoid a signed 64-bit divide

[Deucher, Alexander]

The fix is already queued in my tree:
http://lists.freedesktop.org/archives/dri-devel/2013-August/042668.html


> -Original Message-
> From: Kyle McMartin [mailto:kmcma...@redhat.com]
> Sent: Friday, August 02, 2013 1:13 PM
> To: jgli...@redhat.com
> Cc: Deucher, Alexander; airl...@redhat.com; dri-
> de...@lists.freedesktop.org; jwbo...@redhat.com
> Subject: [PATCH] radeon: si_dpm.c: avoid a signed 64-bit divide
> 
> Hit a compile failure here referencing divdi3 on i686.
> 
> Signed-off-by: Kyle McMartin 
> 
> --- a/drivers/gpu/drm/radeon/si_dpm.c
> +++ b/drivers/gpu/drm/radeon/si_dpm.c
> @@ -1767,7 +1767,7 @@ static void
> si_calculate_leakage_for_v_and_t_formula(const struct ni_leakage_coe
>   s64 temperature, t_slope, t_intercept, av, bv, t_ref;
>   s64 tmp;
> 
> - i_leakage = drm_int2fixp(ileakage) / 100;
> + i_leakage = div64_s64(drm_int2fixp(ileakage), 100);
>   vddc = div64_s64(drm_int2fixp(v), 1000);
>   temperature = div64_s64(drm_int2fixp(t), 1000);
> 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] radeon: si_dpm.c: avoid a signed 64-bit divide

[Kyle McMartin]

Hit a compile failure here referencing divdi3 on i686.

Signed-off-by: Kyle McMartin 

--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -1767,7 +1767,7 @@ static void 
si_calculate_leakage_for_v_and_t_formula(const struct ni_leakage_coe
s64 temperature, t_slope, t_intercept, av, bv, t_ref;
s64 tmp;
 
-   i_leakage = drm_int2fixp(ileakage) / 100;
+   i_leakage = div64_s64(drm_int2fixp(ileakage), 100);
vddc = div64_s64(drm_int2fixp(v), 1000);
temperature = div64_s64(drm_int2fixp(t), 1000);
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] radeon: si_dpm.c: avoid a signed 64-bit divide

[Kyle McMartin]

On Fri, Aug 02, 2013 at 05:14:52PM +, Deucher, Alexander wrote:
> The fix is already queued in my tree:
> http://lists.freedesktop.org/archives/dri-devel/2013-August/042668.html
> 

thanks. ;-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67110] [radeonsi] Anomaly Warzone Earth games are segfaulting

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67110

--- Comment #1 from Michel Dänzer  ---
Can you attach a backtrace for a segfault, preferably with all relevant
binaries having debugging symbols?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: const'ify ioctls table (v2)

[Rob Clark]

Because, there is no reason for it not to be const.

v1: original
v2: fix compile break in vmwgfx, and couple related cleanups suggested
by Ville Syrjälä

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 ++--
 drivers/gpu/drm/gma500/psb_drv.c| 2 +-
 drivers/gpu/drm/i810/i810_dma.c | 2 +-
 drivers/gpu/drm/i810/i810_drv.h | 2 +-
 drivers/gpu/drm/i915/i915_dma.c | 2 +-
 drivers/gpu/drm/i915/i915_drv.h | 2 +-
 drivers/gpu/drm/mga/mga_drv.h   | 2 +-
 drivers/gpu/drm/mga/mga_state.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 5 ++---
 drivers/gpu/drm/omapdrm/omap_drv.c  | 2 +-
 drivers/gpu/drm/qxl/qxl_drv.h   | 2 +-
 drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
 drivers/gpu/drm/r128/r128_drv.h | 2 +-
 drivers/gpu/drm/r128/r128_state.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
 drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
 drivers/gpu/drm/savage/savage_bci.c | 2 +-
 drivers/gpu/drm/savage/savage_drv.h | 2 +-
 drivers/gpu/drm/sis/sis_drv.h   | 2 +-
 drivers/gpu/drm/sis/sis_mm.c| 2 +-
 drivers/gpu/drm/via/via_dma.c   | 2 +-
 drivers/gpu/drm/via/via_drv.h   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++--
 drivers/gpu/host1x/drm/drm.c| 2 +-
 drivers/staging/imx-drm/imx-drm-core.c  | 2 +-
 include/drm/drmP.h  | 2 +-
 26 files changed, 29 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index ca2729a..7b9c879 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -213,7 +213,7 @@ static const struct vm_operations_struct 
exynos_drm_gem_vm_ops = {
.close = drm_gem_vm_close,
 };
 
-static struct drm_ioctl_desc exynos_ioctls[] = {
+static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP_OFFSET,
@@ -277,6 +277,7 @@ static struct drm_driver exynos_drm_driver = {
.gem_prime_export   = exynos_dmabuf_prime_export,
.gem_prime_import   = exynos_dmabuf_prime_import,
.ioctls = exynos_ioctls,
+   .num_ioctls = ARRAY_SIZE(exynos_ioctls),
.fops   = &exynos_drm_driver_fops,
.name   = DRIVER_NAME,
.desc   = DRIVER_DESC,
@@ -288,7 +289,6 @@ static struct drm_driver exynos_drm_driver = {
 static int exynos_drm_platform_probe(struct platform_device *pdev)
 {
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-   exynos_drm_driver.num_ioctls = DRM_ARRAY_SIZE(exynos_ioctls);
 
return drm_platform_init(&exynos_drm_driver, pdev);
 }
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index bddea58..ffc9e25 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -131,7 +131,7 @@ static int psb_gamma_ioctl(struct drm_device *dev, void 
*data,
 static int psb_dpst_bl_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
 
-static struct drm_ioctl_desc psb_ioctls[] = {
+static const struct drm_ioctl_desc psb_ioctls[] = {
DRM_IOCTL_DEF_DRV(GMA_ADB, psb_adb_ioctl, DRM_AUTH),
DRM_IOCTL_DEF_DRV(GMA_MODE_OPERATION, psb_mode_operation_ioctl,
  DRM_AUTH),
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index ada49ed..eac755b 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -1241,7 +1241,7 @@ int i810_driver_dma_quiescent(struct drm_device *dev)
return 0;
 }
 
-struct drm_ioctl_desc i810_ioctls[] = {
+const struct drm_ioctl_desc i810_ioctls[] = {
DRM_IOCTL_DEF_DRV(I810_INIT, i810_dma_init, 
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I810_VERTEX, i810_dma_vertex, DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I810_CLEAR, i810_clear_bufs, DRM_AUTH|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/i810/i810_drv.h b/drivers/gpu/drm/i810/i810_drv.h
index 6e0acad..d4d16ed 100644
--- a/drivers/gpu/drm/i810/i810_drv.h
+++ b/drivers/gpu/drm/i810/i810_drv.h
@@ -125,7 +125,7 @@ extern void i810_driver_preclose(struct drm_device *dev,
 extern int i810_driver_device_is_agp(struct drm_device *dev);
 
 extern long i810_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
-extern struct drm_ioctl_desc i810_ioctls[];
+extern const struct drm_ioctl_desc i810_ioctls[];
 extern int i810_max_ioctl;
 
 #define I810_BASE(reg) ((unsigned long) \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 6ce9033..78ad4dc 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1834,7 +1834,7 @@ void i915_driver_postclose(struct 

[Bug 59761] Kernel fails to reset AMD HD5770 GPU properly and encounters OOPS. GPU reset fails - system remains in unusable state.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=59761

--- Comment #3 from t3s...@mail.ru ---
Btw, looks like in MESA 9.2 GPU lockup bug which provokes this problem has gone
(congrats to MESA people on killing it!). Though I can still re-test kernel
handling of GPU reset by using older MESA :).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Felipe Contreras]

On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki  wrote:
> On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
>> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa  wrote:
>> > Hello,
>> >
>> > I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
>> > change to this parameter to the kernel boot:
>> >
>> >
>> > GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\""
>>
>> I think it's pretty obvious that for the time being we need to
>> blacklist a ton of machines so they boot without this OSI. In fact, in
>> might make sense to simply remove the OSI completely for all machines
>> (for now).
>
> That would have made sense 6 months ago, but not today.

Today, like 6 months ago these machines remain broken, and it will be
the same tomorrow, presumably on v3.11, and at least v3.12 as well.

> The reason is that you don't really know what's affected by that and I'm
> pretty sure it's not only backlight.

I haven't heard a single comment that says acpi_osi="!Windows 2012"
breaks other things. OTOH everybody is saying it fixes the backlight
problem (if indeed it's the same problem).

Are you claiming that those users are wrong?

> So no, we won't do that.

Yeah, because that would fix the backlight problems, not tomorrow, or
several months from now, *today*. Geez, who would want that?

Here is the patch to fix the problem, *today*.

https://bugzilla.kernel.org/show_bug.cgi?id=60682

This is what we should do:

1) Improve that blacklist list
2) Fix the Intel driver issues
3) Enable your patch that uses the Intel driver instead
4) Remove that patch

Anything else is not be good for the users.

-- 
Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Felipe Contreras]

On Fri, Aug 2, 2013 at 3:03 PM, Josep Lladonosa  wrote:
> With this setup, something has happened: in xorg, when screen goes to
> screensaver and after, enters into Standby mode, when I press a key,
> it keeps black and, to recover screen, I have to adjust brightness
> manually (by increasing), as if it didn't remember previous value to
> standby mode.
>
> This was something that before didn't happen.

You mean with acpi_osi="!Windows 2012"? And when you say "before",
what do you mean?

-- 
Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Borislav Petkov]

On Fri, Aug 02, 2013 at 10:11:27PM +0200, Josep Lladonosa wrote:
> "Before" means with previous kernels that worked with
> 
> GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
> 
> I have not checked this issue with acpi_osi="!Windows 2012".

Hey Josep,

would you please not top-post when you reply?

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: const'ify ioctls table (v2)

[Alex Deucher]

On Fri, Aug 2, 2013 at 1:27 PM, Rob Clark  wrote:
> Because, there is no reason for it not to be const.
>
> v1: original
> v2: fix compile break in vmwgfx, and couple related cleanups suggested
> by Ville Syrjälä
>
> Signed-off-by: Rob Clark 

Seems reasonable to me.

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 ++--
>  drivers/gpu/drm/gma500/psb_drv.c| 2 +-
>  drivers/gpu/drm/i810/i810_dma.c | 2 +-
>  drivers/gpu/drm/i810/i810_drv.h | 2 +-
>  drivers/gpu/drm/i915/i915_dma.c | 2 +-
>  drivers/gpu/drm/i915/i915_drv.h | 2 +-
>  drivers/gpu/drm/mga/mga_drv.h   | 2 +-
>  drivers/gpu/drm/mga/mga_state.c | 2 +-
>  drivers/gpu/drm/nouveau/nouveau_drm.c   | 5 ++---
>  drivers/gpu/drm/omapdrm/omap_drv.c  | 2 +-
>  drivers/gpu/drm/qxl/qxl_drv.h   | 2 +-
>  drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
>  drivers/gpu/drm/r128/r128_drv.h | 2 +-
>  drivers/gpu/drm/r128/r128_state.c   | 2 +-
>  drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
>  drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
>  drivers/gpu/drm/savage/savage_bci.c | 2 +-
>  drivers/gpu/drm/savage/savage_drv.h | 2 +-
>  drivers/gpu/drm/sis/sis_drv.h   | 2 +-
>  drivers/gpu/drm/sis/sis_mm.c| 2 +-
>  drivers/gpu/drm/via/via_dma.c   | 2 +-
>  drivers/gpu/drm/via/via_drv.h   | 2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++--
>  drivers/gpu/host1x/drm/drm.c| 2 +-
>  drivers/staging/imx-drm/imx-drm-core.c  | 2 +-
>  include/drm/drmP.h  | 2 +-
>  26 files changed, 29 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index ca2729a..7b9c879 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -213,7 +213,7 @@ static const struct vm_operations_struct 
> exynos_drm_gem_vm_ops = {
> .close = drm_gem_vm_close,
>  };
>
> -static struct drm_ioctl_desc exynos_ioctls[] = {
> +static const struct drm_ioctl_desc exynos_ioctls[] = {
> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
> DRM_UNLOCKED | DRM_AUTH),
> DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP_OFFSET,
> @@ -277,6 +277,7 @@ static struct drm_driver exynos_drm_driver = {
> .gem_prime_export   = exynos_dmabuf_prime_export,
> .gem_prime_import   = exynos_dmabuf_prime_import,
> .ioctls = exynos_ioctls,
> +   .num_ioctls = ARRAY_SIZE(exynos_ioctls),
> .fops   = &exynos_drm_driver_fops,
> .name   = DRIVER_NAME,
> .desc   = DRIVER_DESC,
> @@ -288,7 +289,6 @@ static struct drm_driver exynos_drm_driver = {
>  static int exynos_drm_platform_probe(struct platform_device *pdev)
>  {
> pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> -   exynos_drm_driver.num_ioctls = DRM_ARRAY_SIZE(exynos_ioctls);
>
> return drm_platform_init(&exynos_drm_driver, pdev);
>  }
> diff --git a/drivers/gpu/drm/gma500/psb_drv.c 
> b/drivers/gpu/drm/gma500/psb_drv.c
> index bddea58..ffc9e25 100644
> --- a/drivers/gpu/drm/gma500/psb_drv.c
> +++ b/drivers/gpu/drm/gma500/psb_drv.c
> @@ -131,7 +131,7 @@ static int psb_gamma_ioctl(struct drm_device *dev, void 
> *data,
>  static int psb_dpst_bl_ioctl(struct drm_device *dev, void *data,
>  struct drm_file *file_priv);
>
> -static struct drm_ioctl_desc psb_ioctls[] = {
> +static const struct drm_ioctl_desc psb_ioctls[] = {
> DRM_IOCTL_DEF_DRV(GMA_ADB, psb_adb_ioctl, DRM_AUTH),
> DRM_IOCTL_DEF_DRV(GMA_MODE_OPERATION, psb_mode_operation_ioctl,
>   DRM_AUTH),
> diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
> index ada49ed..eac755b 100644
> --- a/drivers/gpu/drm/i810/i810_dma.c
> +++ b/drivers/gpu/drm/i810/i810_dma.c
> @@ -1241,7 +1241,7 @@ int i810_driver_dma_quiescent(struct drm_device *dev)
> return 0;
>  }
>
> -struct drm_ioctl_desc i810_ioctls[] = {
> +const struct drm_ioctl_desc i810_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I810_INIT, i810_dma_init, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(I810_VERTEX, i810_dma_vertex, 
> DRM_AUTH|DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(I810_CLEAR, i810_clear_bufs, DRM_AUTH|DRM_UNLOCKED),
> diff --git a/drivers/gpu/drm/i810/i810_drv.h b/drivers/gpu/drm/i810/i810_drv.h
> index 6e0acad..d4d16ed 100644
> --- a/drivers/gpu/drm/i810/i810_drv.h
> +++ b/drivers/gpu/drm/i810/i810_drv.h
> @@ -125,7 +125,7 @@ extern void i810_driver_preclose(struct drm_device *dev,
>  extern int i810_driver_device_is_agp(struct drm_device *dev);
>
>  extern long i810_ioctl(struct file *file, unsigned int cmd, unsigned long 
> arg);
> -extern struct drm_ioctl_desc i810_ioctls[];
> +extern const struct drm_ioctl_desc i810_ioctls[];
>  extern in

Re: i915 backlight

[Felipe Contreras]

On Fri, Aug 2, 2013 at 3:11 PM, Josep Lladonosa  wrote:
> "Before" means with previous kernels that worked with
>
> GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"

That's probably a different issue. You would need to bisect the problem.

> I have not checked this issue with acpi_osi="!Windows 2012".

Please do.

-- 
Felipe Contreras
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Rafael J. Wysocki]

On Friday, August 02, 2013 01:58:55 PM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki  wrote:
> > On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
> >> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa  wrote:
> >> > Hello,
> >> >
> >> > I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
> >> > change to this parameter to the kernel boot:
> >> >
> >> >
> >> > GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\""
> >>
> >> I think it's pretty obvious that for the time being we need to
> >> blacklist a ton of machines so they boot without this OSI. In fact, in
> >> might make sense to simply remove the OSI completely for all machines
> >> (for now).
> >
> > That would have made sense 6 months ago, but not today.
> 
> Today, like 6 months ago these machines remain broken, and it will be
> the same tomorrow, presumably on v3.11, and at least v3.12 as well.

Can you possibly look at things from a bit broader perspective than just the
broken backlight?

[I'm talking about "simply removing the OSI completely for all machines" if
that's not clear.]

The problem is that for the last 6 months the kernel has responded to
OSI(Windows 2012) with a "yes" and now, after that time, you want it to
make a U turn and start saying "no" even though that may cause problems to
happen on other people's machines.  That's simply irresponsible.

> > The reason is that you don't really know what's affected by that and I'm
> > pretty sure it's not only backlight.
> 
> I haven't heard a single comment that says acpi_osi="!Windows 2012"
> breaks other things. OTOH everybody is saying it fixes the backlight
> problem (if indeed it's the same problem).
> 
> Are you claiming that those users are wrong?

No, they are saying what they see and they are the people having the backlight
problem in the first place.  You have no data from people for whom things work
now.

> > So no, we won't do that.
> 
> Yeah, because that would fix the backlight problems, not tomorrow, or
> several months from now, *today*. Geez, who would want that?
> 
> Here is the patch to fix the problem, *today*.

It doesn't "fix" anything.  It just creates a blacklist of systems where
acpi_osi="!Windows 2012" happens to help with the backlight control problem.

You don't even know why exactly it happens to work on those machines in the
first place and you don't know what is affected by that apart from backlight
(you can't be sure that nothing is affected in particular).

> https://bugzilla.kernel.org/show_bug.cgi?id=60682
> 
> This is what we should do:
> 
> 1) Improve that blacklist list
> 2) Fix the Intel driver issues
> 3) Enable your patch that uses the Intel driver instead
> 4) Remove that patch
> 
> Anything else is not be good for the users.

Actually, the users can easily put the acpi_osi="!Windows 2012" into the
kernel command line (which is what they have been doing already for some
time I suppose).  However, if we add the blacklist to the kernel, that will
mean we kind of give up fixing the backlight control for them (because they
won't have any incentive to test anything else then).

That said this is a controverisal matter and we evidently don't agree with
each other.  I have my reasons, you have your arguments and it doesn't look
like any of us is likely to change his mind, so why don't we do what's
normally done in such cases: Why don't we ask others?

Matthew, Aaron, Rui, what do you think about this?  Should we create an
acpi_osi="!Windows 2012" blacklist of systems where this workaround is known
to help with backlight control issues?  Is this a good idea in your opinion?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915 backlight

[Felipe Contreras]

On Fri, Aug 2, 2013 at 6:35 PM, Rafael J. Wysocki  wrote:
> On Friday, August 02, 2013 01:58:55 PM Felipe Contreras wrote:
>> On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki  wrote:
>> > On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:

>> >> I think it's pretty obvious that for the time being we need to
>> >> blacklist a ton of machines so they boot without this OSI. In fact, in
>> >> might make sense to simply remove the OSI completely for all machines
>> >> (for now).
>> >
>> > That would have made sense 6 months ago, but not today.
>>
>> Today, like 6 months ago these machines remain broken, and it will be
>> the same tomorrow, presumably on v3.11, and at least v3.12 as well.
>
> Can you possibly look at things from a bit broader perspective than just the
> broken backlight?
>
> [I'm talking about "simply removing the OSI completely for all machines" if
> that's not clear.]
>
> The problem is that for the last 6 months the kernel has responded to
> OSI(Windows 2012) with a "yes" and now, after that time, you want it to
> make a U turn and start saying "no" even though that may cause problems to
> happen on other people's machines.  That's simply irresponsible.

The difference is we *know* *for sure* responding "Windows 2012" with
a yes causes problems, on the other hand you *think* responding with a
no, *might* cause problems.

The only reason it would make sense to remain in the current situation
is that if *knew* that switching to no would cause problems, but to my
knowledge such problems are not real, merely theoretical.

We have had proven brokedness for four releases (almost five now), if
you disable it for v3.12 and it turns out it causes even more
problems, then you enable it back again for v3.13, or even v3.12.1.
The only way to know for certain is to go ahead and try it.

But we know it's going to be all right, because v3.6 was all right.

>> > The reason is that you don't really know what's affected by that and I'm
>> > pretty sure it's not only backlight.
>>
>> I haven't heard a single comment that says acpi_osi="!Windows 2012"
>> breaks other things. OTOH everybody is saying it fixes the backlight
>> problem (if indeed it's the same problem).
>>
>> Are you claiming that those users are wrong?
>
> No, they are saying what they see and they are the people having the backlight
> problem in the first place.  You have no data from people for whom things work
> now.

The data comes from v3.6, who complained? Anyway, it's easy to find
out; just disable it for *one release*.

>> > So no, we won't do that.
>>
>> Yeah, because that would fix the backlight problems, not tomorrow, or
>> several months from now, *today*. Geez, who would want that?
>>
>> Here is the patch to fix the problem, *today*.
>
> It doesn't "fix" anything.  It just creates a blacklist of systems where
> acpi_osi="!Windows 2012" happens to help with the backlight control problem.

>From the user's point of view; right now it doesn't work, after the
patch it does. That is a fix.

> You don't even know why exactly it happens to work on those machines in the
> first place and you don't know what is affected by that apart from backlight
> (you can't be sure that nothing is affected in particular).

I have a fairly good idea of the *real* problems involved with the backlight.

The other problems you speak of are hypothetical, and yes, I don't
know if there will be more problems, but neither do you. This is an
argument from ignorance fallacy, and it's easy to solve; let's try it
for one release and see how it goes. Then we would *know*.

>> https://bugzilla.kernel.org/show_bug.cgi?id=60682
>>
>> This is what we should do:
>>
>> 1) Improve that blacklist list
>> 2) Fix the Intel driver issues
>> 3) Enable your patch that uses the Intel driver instead
>> 4) Remove that patch
>>
>> Anything else is not be good for the users.
>
> Actually, the users can easily put the acpi_osi="!Windows 2012" into the
> kernel command line (which is what they have been doing already for some
> time I suppose).

The kernel should just work out-of-the-box. You can't expect every
user out there to put all sorts of quirks into their boot command,
that's why we have quirks in the kernel in the first place.

> However, if we add the blacklist to the kernel, that will
> mean we kind of give up fixing the backlight control for them (because they
> won't have any incentive to test anything else then).

No, it doesn't mean that.

You should not break systems willingly and knowingly only to create
incentives to the developers.

When things are ready, you enable the fix again, if they break, you
disable it again. At no point in time does it make sense to retain
code that we know breaks user-experience.

> That said this is a controverisal matter and we evidently don't agree with
> each other.  I have my reasons, you have your arguments and it doesn't look
> like any of us is likely to change his mind, so why don't we do what's
> normally done in such ca

[Bug 67690] New: Segfault when starting Xorg with radeonsi

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67690

  Priority: medium
Bug ID: 67690
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Segfault when starting Xorg with radeonsi
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: mth...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/radeonsi
   Product: Mesa

Created attachment 83559
  --> https://bugs.freedesktop.org/attachment.cgi?id=83559&action=edit
Xorg log

Hit this problem with the latest version of radeonsi in Mesa with Fedora 19.
Pulled the latest from git and built myself, and still hit the same issue.
Removing radeonsi_dri.so and using radeon_dri.so allows me to work around the
problem.

Relevant lspci:
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Device 9900 (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 1527
Flags: bus master, fast devsel, latency 0, IRQ 52
Memory at b000 (32-bit, prefetchable) [size=256M]
I/O ports at f000 [size=256]
Memory at feb0 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at  [disabled]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Chelsea LP [Radeon HD 7730M] (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 1527
Physical Slot: 0
Flags: bus master, fast devsel, latency 0, IRQ 53
Memory at c000 (64-bit, prefetchable) [size=256M]
Memory at fea0 (64-bit, non-prefetchable) [size=256K]
I/O ports at e000 [size=256]
Expansion ROM at fea4 [disabled] [size=128K]
Capabilities: [50] Power Management version 3
Capabilities: [58] Express Legacy Endpoint, MSI 00
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+


The stack trace:

[ 72427.843] (EE) Backtrace:
[ 72427.843] (EE) 0: /usr/bin/Xorg (OsLookupColor+0x129) [0x46edb9]
[ 72427.844] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x34e180ef9f]
[ 72427.844] (EE) 2: /usr/lib64/dri/radeonsi_dri.so
(radeon_drm_winsys_create+0xb9) [0x7fbab6804019]
[ 72427.845] (EE) 3: /usr/lib64/dri/radeonsi_dri.so (create_screen+0x9)
[0x7fbab652b3d9]
[ 72427.846] (EE) 4: /usr/lib64/dri/radeonsi_dri.so (dri2_init_screen+0x45)
[0x7fbab67fff75]
[ 72427.846] (EE) 5: /usr/lib64/dri/swrast_dri.so (driIndexConfigAttrib+0x57d)
[0x7fbab3f9a7cd]
[ 72427.847] (EE) 6: /usr/lib64/xorg/modules/extensions/libglx.so
(_glthread_GetID+0x71d1) [0x7fbab8162cb1]
[ 72427.848] (EE) 7: /usr/lib64/xorg/modules/extensions/libglx.so
(_glthread_GetID+0x679a) [0x7fbab816180a]
[ 72427.848] (EE) 8: /usr/bin/Xorg (InitExtensions+0x41) [0x4ba101]
[ 72427.848] (EE) 9: /usr/bin/Xorg (_init+0x38e0) [0x429980]
[ 72427.848] (EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x34e1021b75]
[ 72427.849] (EE) 11: /usr/bin/Xorg (_start+0x29) [0x4267b1]
[ 72427.849] (EE) 12: ? (?+0x29) [0x29]
[ 72427.849] (EE) 
[ 72427.849] (EE) Segmentation fault at address 0x0

Full Xorg log including the stack trace attached.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67110] [radeonsi] Anomaly Warzone Earth games are segfaulting

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=67110

--- Comment #2 from Vladimir Ysikov  ---
I rebuild mesa, libdrm and libtxc_dxtn with debugging symbols.

#0  0x08112d87 in ?? ()
#1  0x080d7457 in ?? ()
#2  0x080d836b in ?? ()
#3  0x080ca74b in ?? ()
#4  0x08092f40 in ?? ()
#5  0x0815929f in ?? ()
#6  0x080c1832 in ?? ()
#7  0x081c5a64 in ?? ()
#8  0x080c2ce7 in ?? ()
#9  0x081c5458 in ?? ()
#10 0xb71becf0 in start_thread () from /usr/lib/libpthread.so.0
#11 0xb72be41e in clone () from /usr/lib/libc.so.6

As I understand it a little? What library I must rebuild with debugging
symbols?

behem0th@ArchLinux ~/Steam/SteamApps/common/Anomaly Warzone Earth $ ldd
AnomalyWarzoneEarth 
linux-gate.so.1 (0xb77ae000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb763f000)
libGL.so.1 => /usr/lib/libGL.so.1 (0xb75e3000)
libopenal.so.1 => /home/behem0th/Steam/SteamApps/common/Anomaly Warzone
Earth/libopenal.so.1 (0xb754b000)
libsteam_api.so => /home/behem0th/Steam/SteamApps/common/Anomaly
Warzone Earth/libsteam_api.so (0xb7539000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb744f000)
libm.so.6 => /usr/lib/libm.so.6 (0xb740c000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb73f)
libc.so.6 => /usr/lib/libc.so.6 (0xb7242000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb7227000)
librt.so.1 => /usr/lib/librt.so.1 (0xb721e000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb71fb000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb71f6000)
libglapi.so.0 => /usr/lib/libglapi.so.0 (0xb71df000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb71cc000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb71c8000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb71c1000)
libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xb71be000)
libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xb71a5000)
libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0 (0xb719f000)
libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb7199000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb718b000)
/lib/ld-linux.so.2 (0xb77af000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7186000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x45ff7000)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #76 from 720  ---
(In reply to comment #68)
> In the short term until we sort out why the battery state causes resume
> problems, you can select balanced or performance state in your suspend
> script.

A bit of a git noob question: How do you check out only the -next, or the
-fixes branch?

Another question regarding this workaround-fix: Will you fix and re-enable the
feature later on? (In a foreseeable future, that is?)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Tomasz Figa]

Hi Vikas,

On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> connected with resolution 2560x1600, following error occured even with
> IOMMU enabled:
> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> 
> This patch fixes the issue by adding a check for IOMMU.
> 
> Signed-off-by: Vikas Sajjan 
> Signed-off-by: Arun Kumar 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
> drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
>   unsigned long size;
>   int ret;
> + unsigned int flag;
> 
>   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
>   sizes->surface_width, sizes->surface_height,
> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
> 
>   /* 0 means to allocate physically continuous memory */
> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> + if (!is_drm_iommu_supported(dev))
> + flag = 0;
> + else
> + flag = EXYNOS_BO_NONCONTIG;

While noncontig memory might be used for devices that support IOMMU, there 
should be no problem with using contig memory for them, so this seems more 
like masking the original problem rather than tracking it down.

Could you check why the allocation fails when requesting contiguous 
memory?

Best regards,
Tomasz

i915 backlight

[Aaron Lu]

On 08/01/2013 05:07 PM, Aaron Lu wrote:
> On 08/01/2013 04:12 PM, Borislav Petkov wrote:
>> On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote:
>>> Can you please run acpi_listen and then press the Fn-Fx key, see if the
>>> events are correctly sent out?
>>
>> Like this?
>>
>> # acpi_listen
>> video/brightnessdown BRTDN 0087 
>> video/brightnessup BRTUP 0086 
>> video/brightnessdown BRTDN 0087 
>> video/brightnessup BRTUP 0086 
>> video/brightnessdown BRTDN 0087 
>> video/brightnessup BRTUP 0086 
>> video/brightnessdown BRTDN 0087 
>> video/brightnessup BRTUP 0086 
>> video/brightnessdown BRTDN 0087 
>> ^C
> 
> Yes, so the event is correctly sent out.
> 
>>
>>> From the bug page:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=51231#c80
>>> I got the impression that both the acpi_video interface and the vendor
>>> interface thinkpad_screen are broken. So adding this cmdline here works
>>> suggests that either thinkpad_screen works or thinkpad vendor driver
>>> doesn't get loaded or doesn't create that interface for some reason.
>>>
>>> Alternatively, if the intel_backlight interface works(highly possible),
>>> you can use xorg.conf to specify the that backlight interface for X.
>>>
>>> Section "Device"
>>> Option "Backlight"  "intel_backlight"
>>> Identifier  "Card0"
>>> Driver  "intel"
>>> BusID   "PCI:0:2:0"
>>> EndSection
>>
>> Yeah, that didn't work *but* manually writing to both:
>>
>> /sys/class/backlight/acpi_video0/brightness
>>
>> and
>>
>> /sys/class/backlight/intel_backlight/brightness
>>
>> works.
> 
> Err...we have the event sent out on hotkey press and the interface also
> works, but still, using hotkey to adjust brightness level is broken...
> 
> I just found an old acer laptop that has similar issue(or even worse: on
> X starts, an almost black screen is shown and hotkey adjust doesn't
> work), I'll look into this.

Hi Jani & Daniel,

It turned out there is an integer overflow problem, and the below patch
fixed this problem on Acer Aspire 4732Z and thinkpad R61i.

From: Aaron Lu 
Subject: [PATCH] drm/i915: avoid brightness overflow when doing scale

Some card's max brightness level is pretty large, e.g. on Acer Aspire
4732Z, the max level is 989910. If user space set a large enough level
then the current scale done in intel_panel_set_backlight will cause an
integer overflow and the scaled level will be mistakenly small, leaving
user with an almost black screen. This patch fixes this problem.

Signed-off-by: Aaron Lu 
---
Since the only external user of intel_panel_set_backlight is operation
region code where the max will be a constant of 255, this patch fixes
the problem by comparing freq and max and then do things accordingly
instead of converting to 64 bits.

 drivers/gpu/drm/i915/intel_panel.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 67e2c1f..7c674f0 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -498,7 +498,10 @@ void intel_panel_set_backlight(struct drm_device *dev, u32 
level, u32 max)
}

/* scale to hardware */
-   level = level * freq / max;
+   if (freq < max)
+   level = level * freq / max;
+   else
+   level = freq / max * level;

dev_priv->backlight.level = level;
if (dev_priv->backlight.device)
-- 
1.8.3.1


Hi Boris,

Since the sysfs interface works on your system, I think your problem
should be different. Can you please file a bug for this? I can provide
you with a debug patch and then see what happened. Please attach
acpidump when filing the bug.

https://bugzilla.kernel.org, ACPI/Power-Video.

Thanks,
Aaron

> 
>>
>> The ranges are different, though:
>>
>> intel_backlight/actual_brightness:1000
>> intel_backlight/bl_power:0
>> intel_backlight/brightness:1000
>> intel_backlight/max_brightness:4437
>> intel_backlight/type:raw
>>
>> acpi_video0/actual_brightness:41
>> acpi_video0/bl_power:0
>> acpi_video0/brightness:41
>> acpi_video0/max_brightness:100
>> acpi_video0/type:firmware
> 
> Yes, different interface has different brightness ranges and a value in
> one range may turn out to be the same actual brightness level of another
> value in another range.
> 
>>
>> I guess I need to write me a dirty script for now ... :-)
> 
> :-)
> 
>>
>> Thanks guys.
>>
> Thanks,
> Aaron
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Sachin Kamat]

Hi Vikas,

On 2 August 2013 09:23, Vikas Sajjan  wrote:
> Hi Tomasz,
>
>
> On 2 August 2013 04:50, Tomasz Figa  wrote:
>>
>> Hi Vikas,
>>
>> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
>> > While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
>> > connected with resolution 2560x1600, following error occured even with
>> > IOMMU enabled:
>> > [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
>> > buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>> >
>> > This patch fixes the issue by adding a check for IOMMU.
>> >
>> > Signed-off-by: Vikas Sajjan 
>> > Signed-off-by: Arun Kumar 
>> > ---
>> >  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>> >  1 file changed, 8 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
>> > 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> > @@ -16,6 +16,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >
>> >  #include "exynos_drm_drv.h"
>> >  #include "exynos_drm_fb.h"
>> > @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
>> > drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
>> >   unsigned long size;
>> >   int ret;
>> > + unsigned int flag;
>> >
>> >   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
>> >   sizes->surface_width, sizes->surface_height,
>> > @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
>> > drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>> >
>> >   /* 0 means to allocate physically continuous memory */
>> > - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
>> > + if (!is_drm_iommu_supported(dev))
>> > + flag = 0;
>> > + else
>> > + flag = EXYNOS_BO_NONCONTIG;
>>
>> While noncontig memory might be used for devices that support IOMMU, there
>> should be no problem with using contig memory for them, so this seems more
>> like masking the original problem rather than tracking it down.
>>
>> Could you check why the allocation fails when requesting contiguous
>> memory?
>>
>
> It is failing if i am giving bigger resolution like 2560x1600, but if
> i try for 1280x780 resolution, it   works fine.
> Looks like arm_dma_alloc() is NOT able to allocate bigger buffer of
> size 2560 * 1600 * 4.

You may need to increase the zoneorder (from current default 11 to say
13) if you need large physically contiguous pages.
However I am not sure if it is recommended.

-- 
With warm regards,
Sachin

[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Sachin Kamat]

Hi Vikas,

On 1 August 2013 16:49, Vikas Sajjan  wrote:
> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> connected with resolution 2560x1600, following error occured even with
> IOMMU enabled:
> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
> [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>
> This patch fixes the issue by adding a check for IOMMU.
>
> Signed-off-by: Vikas Sajjan 
> Signed-off-by: Arun Kumar 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 8e60bd6..2a8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_fb.h"
> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
> *helper,
> struct platform_device *pdev = dev->platformdev;
> unsigned long size;
> int ret;
> +   unsigned int flag;
>
> DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
> sizes->surface_width, sizes->surface_height,
> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper 
> *helper,
> size = mode_cmd.pitches[0] * mode_cmd.height;
>
> /* 0 means to allocate physically continuous memory */

This comment is now wrongly placed. Please use EXYNOS_BO_CONTIG instead of 0
and get rid of this comment altogether.

> -   exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> +   if (!is_drm_iommu_supported(dev))
> +   flag = 0;
> +   else
> +   flag = EXYNOS_BO_NONCONTIG;
> +
> +   exynos_gem_obj = exynos_drm_gem_create(dev, flag, size);
> if (IS_ERR(exynos_gem_obj)) {
> ret = PTR_ERR(exynos_gem_obj);
> goto err_release_framebuffer;

-- 
With warm regards,
Sachin

[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Vikas Sajjan]

Hi Tomasz,


On 2 August 2013 04:50, Tomasz Figa  wrote:
>
> Hi Vikas,
>
> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
> > While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> > connected with resolution 2560x1600, following error occured even with
> > IOMMU enabled:
> > [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
> > buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> >
> > This patch fixes the issue by adding a check for IOMMU.
> >
> > Signed-off-by: Vikas Sajjan 
> > Signed-off-by: Arun Kumar 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
> > 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > @@ -16,6 +16,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "exynos_drm_drv.h"
> >  #include "exynos_drm_fb.h"
> > @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
> > drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
> >   unsigned long size;
> >   int ret;
> > + unsigned int flag;
> >
> >   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
> >   sizes->surface_width, sizes->surface_height,
> > @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
> > drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
> >
> >   /* 0 means to allocate physically continuous memory */
> > - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> > + if (!is_drm_iommu_supported(dev))
> > + flag = 0;
> > + else
> > + flag = EXYNOS_BO_NONCONTIG;
>
> While noncontig memory might be used for devices that support IOMMU, there
> should be no problem with using contig memory for them, so this seems more
> like masking the original problem rather than tracking it down.
>
> Could you check why the allocation fails when requesting contiguous
> memory?
>

It is failing if i am giving bigger resolution like 2560x1600, but if
i try for 1280x780 resolution, it   works fine.
Looks like arm_dma_alloc() is NOT able to allocate bigger buffer of
size 2560 * 1600 * 4.
Hence i used flag = EXYNOS_BO_NONCONTIG;


>
> Best regards,
> Tomasz
>



-- 
Thanks and Regards
 Vikas Sajjan

[PATCH] drm/nouveau/acpi: de-dup use of DSM methods

[Dave Airlie]

On Fri, Aug 2, 2013 at 12:41 AM, Peter Wu  wrote:
> Observe that nouveau_optimus_dsm and nouveau_dsm are equal except for
> the parameters handling (UUID, revision ID and function arguments). The
> function arguments are passed as Buffer in the "optimus dsm" and Integer
> in "nvidia dsm". As buffers are implicitly converted to integers, merge
> both functions.
>
> The ACPI spec defines the fourth parameter (Arg3 a.k.a. "function
> arguments") as Package, but many BIOSes expect a Buffer instead. For
> instance, for the "nvidia DSM", the Lenovo T410s uses CreateByteField on
> Arg3 which does not work with a package. The Clevo B7130 does something
> similar for the "Optimus DSM". Unfortunately, this means that the
> following ACPI warning (introduced with 29a241c) cannot be fixed (when
> toggling power or muxing):

By cannot be fixed, why is it there then? maybe ask the ACPI folks to
drop this error, since as far as I can see all optimus dsm want a
buffer here.

Dave.


>
> ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found 
> [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
> ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found 
> [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
> ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - 
> Found [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
> ACPI Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - 
> Found [Buffer], ACPI requires [Package] (20130517/nsarguments-95)
>
> Signed-off-by: Peter Wu 
> ---
>  drivers/gpu/drm/nouveau/nouveau_acpi.c | 67 
> ++
>  1 file changed, 20 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index d97f200..a75684f 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -46,6 +46,9 @@ bool nouveau_is_v1_dsm(void) {
>  #define NOUVEAU_DSM_HAS_MUX 0x1
>  #define NOUVEAU_DSM_HAS_OPT 0x2
>
> +#define NOUVEAU_DSM_REVID_NVIDIA 0x102
> +#define NOUVEAU_DSM_REVID_OPTIMUS 0x100
> +
>  static const char nouveau_dsm_muid[] = {
> 0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
> 0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4,
> @@ -56,7 +59,8 @@ static const char nouveau_op_dsm_muid[] = {
> 0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
>  };
>
> -static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, 
> uint32_t *result)
> +static int nouveau_call_dsm(acpi_handle handle, const char *uuid, int revid,
> +   int func, int arg, uint32_t *result)
>  {
> struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> struct acpi_object_list input;
> @@ -68,12 +72,15 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
> func, int arg, uint32_t *
> input.count = 4;
> input.pointer = params;
> params[0].type = ACPI_TYPE_BUFFER;
> -   params[0].buffer.length = sizeof(nouveau_op_dsm_muid);
> -   params[0].buffer.pointer = (char *)nouveau_op_dsm_muid;
> +   params[0].buffer.length = 16;
> +   params[0].buffer.pointer = (char *)uuid;
> params[1].type = ACPI_TYPE_INTEGER;
> -   params[1].integer.value = 0x0100;
> +   params[1].integer.value = revid;
> params[2].type = ACPI_TYPE_INTEGER;
> params[2].integer.value = func;
> +   /* Although the ACPI spec defines Arg3 as a Package, in practise
> +* implementations expect a Buffer (CreateWordField and Index 
> functions
> +* are applied to it). */
> params[3].type = ACPI_TYPE_BUFFER;
> params[3].buffer.length = 4;
> /* ACPI is little endian, AABBCCDD becomes {DD,CC,BB,AA} */
> @@ -108,50 +115,16 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
> func, int arg, uint32_t *
> return 0;
>  }
>
> -static int nouveau_dsm(acpi_handle handle, int func, int arg, uint32_t 
> *result)
> -{
> -   struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> -   struct acpi_object_list input;
> -   union acpi_object params[4];
> -   union acpi_object *obj;
> -   int err;
> -
> -   input.count = 4;
> -   input.pointer = params;
> -   params[0].type = ACPI_TYPE_BUFFER;
> -   params[0].buffer.length = sizeof(nouveau_dsm_muid);
> -   params[0].buffer.pointer = (char *)nouveau_dsm_muid;
> -   params[1].type = ACPI_TYPE_INTEGER;
> -   params[1].integer.value = 0x0102;
> -   params[2].type = ACPI_TYPE_INTEGER;
> -   params[2].integer.value = func;
> -   params[3].type = ACPI_TYPE_INTEGER;
> -   params[3].integer.value = arg;
> -
> -   err = acpi_evaluate_object(handle, "_DSM", &input, &output);
> -   if (err) {
> -   printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
> -   return err;
> -   }
> -
> -   obj = (union acpi_object *)output.pointer;

i915 backlight

[Felipe Contreras]

On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa  wrote:
> Hello,
>
> I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
> change to this parameter to the kernel boot:
>
>
> GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\""

I think it's pretty obvious that for the time being we need to
blacklist a ton of machines so they boot without this OSI. In fact, in
might make sense to simply remove the OSI completely for all machines
(for now).

-- 
Felipe Contreras

[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Tomasz Figa]

Hi Vikas,

On Friday 02 of August 2013 12:08:52 Vikas Sajjan wrote:
> Hi Rob,
> 
> On 2 August 2013 06:03, Rob Clark  wrote:
> > On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa  
wrote:
> >> Hi Vikas,
> >> 
> >> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
> >>> While trying to get boot-logo up on exynos5420 SMDK which has eDP
> >>> panel
> >>> connected with resolution 2560x1600, following error occured even
> >>> with
> >>> IOMMU enabled:
> >>> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
> >>> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor
> >>> 0
> >>> 
> >>> This patch fixes the issue by adding a check for IOMMU.
> >>> 
> >>> Signed-off-by: Vikas Sajjan 
> >>> Signed-off-by: Arun Kumar 
> >>> ---
> >>> 
> >>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
> >>>  1 file changed, 8 insertions(+), 1 deletion(-)
[snip]
> >>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
> >>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
> >>> 
> >>>   /* 0 means to allocate physically continuous memory */
> >>> 
> >>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> >>> + if (!is_drm_iommu_supported(dev))
> >>> + flag = 0;
> >>> + else
> >>> + flag = EXYNOS_BO_NONCONTIG;
> >> 
> >> While noncontig memory might be used for devices that support IOMMU,
> >> there should be no problem with using contig memory for them, so
> >> this seems more like masking the original problem rather than
> >> tracking it down.> 
> > it is probably a good idea to not require contig memory when it is not
> > needed for performance or functionality (and if it is only
> > performance, then fallback gracefully to non-contig).. but yeah, would
> > be good to know if this is masking another issue all the same
> 
> Whats happening with CONTIG flag and with IOMMU,  is
> 
>  __iommu_alloc_buffer() ---> dma_alloc_from_contiguous() and in this
> function it fails at
> this condition check  if (pageno >= cma->count)
> 
> So I tried increasing the CONFIG_CMA_SIZE_MBYTES to 24,  this check
> succeeds and it works well without my patch.
> 
> But what about the case where CONFIG_CMA is disabled , yet i want
> bigger memory for a device.
>  I think using IOMMU we can achieve this.
>
>  correct me, if i am wrong.

This is probably fine. I'm not sure about performance aspects of using 
noncontig memory as framebuffer, though. This needs to be checked and if 
there is some performance penalty, I would make noncontig allocation a 
fallback case, if contig fails, as Rob has suggested.

Also I think you should adjust the commit message to say that non-
contiguous memory can be used when IOMMU is supported, so there is no need 
to force contiguous allocations, since this is not a bug fix, but rather a 
feature this patch is adding.

Best regards,
Tomasz

> > BR,
> > -R
> > 
> >> Could you check why the allocation fails when requesting contiguous
> >> memory?
> >> 
> >> Best regards,
> >> Tomasz
> >> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-media" in the body of a message to majordomo at vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Inki Dae]

2013/8/2 Vikas Sajjan 

> Hi Rob,
>
> On 2 August 2013 06:03, Rob Clark  wrote:
> > On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa 
> wrote:
> >> Hi Vikas,
> >>
> >> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
> >>> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> >>> connected with resolution 2560x1600, following error occured even with
> >>> IOMMU enabled:
> >>> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
> >>> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> >>>
> >>> This patch fixes the issue by adding a check for IOMMU.
> >>>
> >>> Signed-off-by: Vikas Sajjan 
> >>> Signed-off-by: Arun Kumar 
> >>> ---
> >>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
> >>>  1 file changed, 8 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> >>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
> >>> 100644
> >>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> >>> @@ -16,6 +16,7 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>>
> >>>  #include "exynos_drm_drv.h"
> >>>  #include "exynos_drm_fb.h"
> >>> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
> >>> drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
> >>>   unsigned long size;
> >>>   int ret;
> >>> + unsigned int flag;
> >>>
> >>>   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
> >>>   sizes->surface_width, sizes->surface_height,
> >>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
> >>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
> >>>
> >>>   /* 0 means to allocate physically continuous memory */
> >>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> >>> + if (!is_drm_iommu_supported(dev))
> >>> + flag = 0;
> >>> + else
> >>> + flag = EXYNOS_BO_NONCONTIG;
> >>
> >> While noncontig memory might be used for devices that support IOMMU,
> there
> >> should be no problem with using contig memory for them, so this seems
> more
> >> like masking the original problem rather than tracking it down.
> >
> > it is probably a good idea to not require contig memory when it is not
> > needed for performance or functionality (and if it is only
> > performance, then fallback gracefully to non-contig).. but yeah, would
> > be good to know if this is masking another issue all the same
> >
>
> Whats happening with CONTIG flag and with IOMMU,  is
>
>  __iommu_alloc_buffer() ---> dma_alloc_from_contiguous() and in this
> function it fails at
> this condition check  if (pageno >= cma->count)
>
> So I tried increasing the CONFIG_CMA_SIZE_MBYTES to 24,  this check
> succeeds and it works well without my patch.
>
> But what about the case where CONFIG_CMA is disabled , yet i want
> bigger memory for a device.
>  I think using IOMMU we can achieve this.
>
>  correct me, if i am wrong.
>
>
I'm on summer vacation so I'm afraid that I cannot test and look into it
but I guess you guy didn't declare CMA region for Exynos drm. And in this
case, the size of CMA declared region is 16MB as default. That is why works
well after increasing default size, CONFIG_CMA_SIZE_MBYTES, to 24MB. And I
mentioned long time ago, we are required to use physically contiguous
memory in case that bootloader uses physically contiguous memory for its
own framebuffer, and kernel wants to share the bootloader's framebuffer
region to resolve flickering issue while booted; that is required for
product. And one question, is there any reason that you guy should use
non-contiguous memory for framebuffer with iommu?

Thanks,
Inki Dae


>
> > BR,
> > -R
> >
> >> Could you check why the allocation fails when requesting contiguous
> >> memory?
> >>
> >> Best regards,
> >> Tomasz
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-media"
> in
> >> the body of a message to majordomo at vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Thanks and Regards
>  Vikas Sajjan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130802/546d6403/attachment.html>

[PATCH] drm/radeon: add very basic support for audio block on DCE6

[Rafał Miłecki]

It doesn't allow playing anything yet, but was the most tricky part to
RE (it's indirect access, so couldn't trace it by dumping registers).
Now we just need to implement support for HDMI blocks.

Signed-off-by: Rafa? Mi?ecki 
---
 drivers/gpu/drm/radeon/Makefile  |2 +-
 drivers/gpu/drm/radeon/dce6_afmt.c   |   88 ++
 drivers/gpu/drm/radeon/radeon_asic.h |2 +
 drivers/gpu/drm/radeon/si.c  |7 +++
 drivers/gpu/drm/radeon/sid.h |5 ++
 5 files changed, 103 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/radeon/dce6_afmt.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index c3df52c..6510fc4 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -79,7 +79,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
si_blit_shaders.o radeon_prime.o radeon_uvd.o cik.o cik_blit_shaders.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
\
-   trinity_smc.o ni_dpm.o si_smc.o si_dpm.o
+   trinity_smc.o ni_dpm.o si_smc.o si_dpm.o dce6_afmt.o

 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
 radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
b/drivers/gpu/drm/radeon/dce6_afmt.c
new file mode 100644
index 000..0d98143
--- /dev/null
+++ b/drivers/gpu/drm/radeon/dce6_afmt.c
@@ -0,0 +1,88 @@
+/*
+ * Copyright ? 2013 Rafa? Mi?ecki 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Rafa? Mi?ecki
+ */
+#include 
+#include 
+#include "radeon.h"
+#include "radeon_asic.h"
+#include "sid.h"
+
+static u32 dce6_audio_read(struct radeon_device *rdev, u32 reg)
+{
+   WREG32(SI_AUDIO_ADDR, reg);
+   return RREG32(SI_AUDIO_DATA);
+}
+
+static void dce6_audio_write(struct radeon_device *rdev, u32 reg, u32 v)
+{
+   reg |= SI_AUDIO_ADDR_WRITE;
+   WREG32(SI_AUDIO_ADDR, reg);
+   WREG32(SI_AUDIO_DATA, v);
+}
+
+static void dce6_audio_maskset(struct radeon_device *rdev, u32 reg, u32 mask,
+  u32 set)
+{
+   u32 tmp = dce6_audio_read(rdev, reg);
+   tmp &= mask;
+   tmp |= set & ~mask;
+   dce6_audio_write(rdev, reg, tmp);
+}
+
+static void dce6_audio_enable(struct radeon_device *rdev, bool enable)
+{
+   DRM_INFO("%s audio support\n", enable ? "Enabling" : "Disabling");
+
+   if (enable) {
+   dce6_audio_maskset(rdev, 0x54, ~0x8000, 0x8000);
+   } else {
+   dce6_audio_maskset(rdev, 0x54, ~0x8000, 0);
+   /* TODO: clear some bit(s) in reg 0x36 */
+   }
+
+   rdev->audio_enabled = enable;
+}
+
+int dce6_audio_init(struct radeon_device *rdev)
+{
+   if (!radeon_audio)
+   return 0;
+
+   dce6_audio_enable(rdev, true);
+
+   rdev->audio_status.channels = -1;
+   rdev->audio_status.rate = -1;
+   rdev->audio_status.bits_per_sample = -1;
+   rdev->audio_status.status_bits = 0;
+   rdev->audio_status.category_code = 0;
+
+   return 0;
+}
+
+void dce6_audio_fini(struct radeon_device *rdev)
+{
+   if (!rdev->audio_enabled)
+   return;
+
+   dce6_audio_enable(rdev, false);
+}
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
b/drivers/gpu/drm/radeon/radeon_asic.h
index ca18957..48674ca 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -698,6 +698,8 @@ void si_dpm_debugfs_print_current_performance_level(struct 
radeon_device *rdev,
struct seq_file *m);
 int si_dpm_force_performance_level(struct radeon_device *rdev,
   enum radeon_dpm_forced_level level);
+int dce6_audio_init(struct radeon_device *rdev);
+void dce6_audio_fini(struct radeon_device *rdev);

 

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #71 from Francisco Pina Martins  ---
Confirming that the latest drm-fixes-3.11 also works fine for me. (4/4)
successful boots.
System boots OK, suspend works fine too. (5/5)
I cannot try hibernate as my swap partition is too small for that.
Thank you for all your hard work Alex!

-- 
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/20130802/f93a3411/attachment.html>

i915 backlight

[Borislav Petkov]

On Fri, Aug 02, 2013 at 02:00:42PM +0800, Aaron Lu wrote:
> Assume you have specified to use intel_backlight in xorg.conf

Right, I have:

Section "Device"
Option "Backlight"  "intel_backlight"
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

in there currently.

> does booting with video.brightness_switch_enabled=0 help?

Nope.

Kernel command line is like this:

[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.0-rc3+ 
root=/dev/sdb2 ro root=/dev/sdb2 ignore_loglevel log_buf_len=10M 
resume=/dev/sdb1 acpi_backlight=vendor video.brightness_switch_enabled=0 
i915.i915_enable_rc6=4 i915.i915_enable_fbc=1 i915.lvds_downclock=1 
i915.powersave=1

and acpi_backlight=vendor doesn't make any difference. It still works
over sysfs though.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[PATCH] drm/radeon: add very basic support for audio block on DCE6

[Rafał Miłecki]

2013/8/2 Rafa? Mi?ecki :
> It doesn't allow playing anything yet, but was the most tricky part to
> RE (it's indirect access, so couldn't trace it by dumping registers).
> Now we just need to implement support for HDMI blocks.

In case someone wonders, there is how I figured out that registers
offset and meaning:

WREG32(0x5e00, 0x0025);
RREG32(0x5e04); -> 0x00c0

WREG32(0x5e00, 0x0125);
WREG32(0x5e04, 0x00c1005f);

RREG32(0x00012c5c); -> 0x   AFMT_AUDIO_PACKET_CONTROL2
WREG32(0x00012c5c, 0xff00); AFMT_AUDIO_PACKET_CONTROL2

WREG32(0x5e00, 0x0027);
RREG32(0x5e04); -> 0x

WREG32(0x5e00, 0x0127); 0x5f80?
WREG32(0x5e04, 0x0040); 0x5f80?

WREG32(0x5e00, 0x000c3128); DESCRIPTOR0
WREG32(0x5e04, 0x7f077f07); DESCRIPTOR0

WREG32(0x5e00, 0x0129); DESCRIPTOR1
WREG32(0x5e04, 0x00500705); DESCRIPTOR1

WREG32(0x5e00, 0x012a); DESCRIPTOR2
WREG32(0x5e04, 0x); DESCRIPTOR2

One thing I don't understand yet is why writing to register 0x28
requires that extra 0x000c3000. It doesn't happen with any other one.

-- 
Rafa?

i915 backlight

[Borislav Petkov]

On Fri, Aug 02, 2013 at 09:16:03AM +0800, Aaron Lu wrote:
> Since the sysfs interface works on your system, I think your problem
> should be different. Can you please file a bug for this? I can provide
> you with a debug patch and then see what happened. Please attach
> acpidump when filing the bug.
>
> https://bugzilla.kernel.org, ACPI/Power-Video.

Done: https://bugzilla.kernel.org/show_bug.cgi?id=60680

I did acpidump by hand but it should be ok.

Thanks for looking into this Aaron! :)

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[Intel-gfx] WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378

[Ville Syrjälä]

On Thu, Aug 01, 2013 at 05:51:31PM -0700, Linus Torvalds wrote:
> This one may have been going on for some time - I haven't updated the
> old Intel Mac Mini in a while.
> 
> And by "not updated" I also mean that it's some really old user-space:
> the machine is running F14, and cannot be updated to anything newer
> without having to reinstall everything because of a stupid small /boot
> partition. So it's not going to happen. But maybe somebody cares about
> the i915 warning anyway?
> 
> Linus
> 
> ---
>WARNING: CPU: 1 PID: 2846 at drivers/gpu/drm/i915/intel_sdvo.c:1378
> intel_sdvo_get_config+0x158/0x160()
>SDVO pixel multiplier mismatch, port: 0, encoder: 1
>Modules linked in: snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep
>CPU: 1 PID: 2846 Comm: Xorg Not tainted 3.11.0-rc3-00208-gbe1e8d7-dirty #19
>Hardware name: Apple Computer, Inc. Macmini1,1/Mac-F4208EC8, BIOS
>   MM11.88Z.0055.B03.0604071521 04/07/06
>   ef0afa54 c1597bbb c1737ea4 ef0afa84 c10392ca c1737e6c
> ef0afab0 0b1e c1737ea4 0562 c12dfbe8 c12dfbe8 ef0afb14 
> f697ec00 ef0afa9c c103936e 0009 ef0afa94 c1737e6c ef0afab0 ef0afadc
>Call Trace:
> [] dump_stack+0x41/0x56
> [] warn_slowpath_common+0x7a/0xa0
> [] warn_slowpath_fmt+0x2e/0x30
> [] intel_sdvo_get_config+0x158/0x160
> [] check_crtc_state+0x1e0/0xb10
> [] intel_modeset_check_state+0x29d/0x7c0
> [] intel_sdvo_dpms+0x5c/0xa0
> [] drm_mode_obj_set_property_ioctl+0x40e/0x420
> [] drm_mode_connector_property_set_ioctl+0x35/0x40
> [] drm_ioctl+0x3e4/0x540
> [] do_vfs_ioctl+0x72/0x570
> [] SyS_ioctl+0x8f/0xa0
> [] sysenter_do_call+0x12/0x22
>---[ end trace 7ce940aff1366d60 ]---

Looks like this could happen when you go to DPMS_OFF. After we've turned
off the the pipe, get_pipe_config() gives a mostly zeroed pipe_config
(including pixel_multiplier), and then in the case of SDVO, we go and
check it against the encoder's idea of pixel_multiplier anyway.

I'm thinking perhaps we shouldn't call get_config for inactive
encoders. How about the following patch?

>From 16c4048bfb54e338ce23a7e98af96af2f58b0e0d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= 
Date: Fri, 2 Aug 2013 12:06:47 +0300
Subject: [PATCH] drm/i915: Don't call encoder's get_config unless encoder is
 active

---
 drivers/gpu/drm/i915/intel_display.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e1e50df..6396bca 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8549,9 +8549,11 @@ check_crtc_state(struct drm_device *dev)

list_for_each_entry(encoder, &dev->mode_config.encoder_list,
base.head) {
+   enum pipe pipe;
if (encoder->base.crtc != &crtc->base)
continue;
-   if (encoder->get_config)
+   if (encoder->get_config &&
+   encoder->get_hw_state(encoder, &pipe))
encoder->get_config(encoder, &pipe_config);
}

-- 
1.8.1.5

-- 
Ville Syrj?l?
Intel OTC

[PATCH] drm: const'ify ioctls table

[Ville Syrjälä]

On Thu, Aug 01, 2013 at 02:25:27PM -0400, Rob Clark wrote:
> Because, there is no reason for it not to be const.
> 
> Signed-off-by: Rob Clark 
> ---

> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 78e2164..eaf86e0 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -124,7 +124,7 @@
>   * Ioctl definitions.
>   */
>  
> -static struct drm_ioctl_desc vmw_ioctls[] = {
> +static const struct drm_ioctl_desc vmw_ioctls[] = {
>   VMW_IOCTL_DEF(VMW_GET_PARAM, vmw_getparam_ioctl,
> DRM_AUTH | DRM_UNLOCKED),
>   VMW_IOCTL_DEF(VMW_ALLOC_DMABUF, vmw_dmabuf_alloc_ioctl,

You forgot to fix vmw_unlocked_ioctl().

Also if you're poking around this stuff, exynos and nouveau appear to
set .num_ioctls from the probe/init funcs even though the ioctls array
is right there in the same compilation unit.

-- 
Ville Syrj?l?
Intel OTC

[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Sylwester Nawrocki]

Hi Vikas,

On 08/02/2013 12:10 PM, Vikas Sajjan wrote:
> yeah, we could not allocate CMA region for FIMD, because the function
> dma_declare_contiguous() needs "dev" as the first argument and we have
> access to "dev" node only if it is NON-DT way of probing like the way
> it is done in arch/arm/mach-davinci/devices-da8xx.c
> But now, since the probing is through DT way, there is NO way ( Let me
> know if something is newly added ) to call dma_declare_contiguous()
> and reserve CMA region .

See this patch series [1]. We have have been using this kind of bindings
for assigning physically contiguous memory regions to the Exynos 
multimedia devices, instead of what's currently in mainline where same
physical addresses are repeated in dts for various boards without much
thought. And where custom device specific parsing code is required at 
arch side.

$ git grep mfc\-[lr] arch/arm/boot/dts

arch/arm/boot/dts/exynos4210-origen.dts: samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos4210-origen.dts: samsung,mfc-l = <0x5100 
0x80>;
arch/arm/boot/dts/exynos4210-smdkv310.dts:   samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos4210-smdkv310.dts:   samsung,mfc-l = <0x5100 
0x80>;
arch/arm/boot/dts/exynos4412-origen.dts: samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos4412-origen.dts: samsung,mfc-l = <0x5100 
0x80>;
arch/arm/boot/dts/exynos4412-smdk4412.dts:   samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos4412-smdk4412.dts:   samsung,mfc-l = <0x5100 
0x80>;
arch/arm/boot/dts/exynos5250-arndale.dts:samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos5250-arndale.dts:samsung,mfc-l = <0x5100 
0x80>;
arch/arm/boot/dts/exynos5250-smdk5250.dts:   samsung,mfc-r = <0x4300 
0x80>;
arch/arm/boot/dts/exynos5250-smdk5250.dts:   samsung,mfc-l = <0x5100 
0x80>;


[1] http://www.spinics.net/lists/arm-kernel/msg263130.html

Regards,
Sylwester

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

Shawn Starr  changed:

   What|Removed |Added

  Attachment #83469|0   |1
is obsolete||

--- Comment #72 from Shawn Starr  ---
Comment on attachment 83469
  --> https://bugs.freedesktop.org/attachment.cgi?id=83469
Corrupt screen 'frosting' after DPM enabled #1

This is due to missing some of the firmware.

-- 
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/20130802/52a00631/attachment-0001.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

Shawn Starr  changed:

   What|Removed |Added

  Attachment #83470|0   |1
is obsolete||

--- Comment #73 from Shawn Starr  ---
Comment on attachment 83470
  --> https://bugs.freedesktop.org/attachment.cgi?id=83470
Corrupt screen 'frosting' after DPM enabled #2 both screens

This is due to missing some of the firmware.

-- 
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/20130802/5b4ae49e/attachment.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #74 from Shawn Starr  ---
RV635 works for me. 

Make sure you have all of the firmware if you compile this kernel make sure
kernel firmware is installed.

-- 
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/20130802/74e51f88/attachment.html>

[PATCH] drm/radeon: add very basic support for audio block on DCE6

[Alex Deucher]

On Fri, Aug 2, 2013 at 4:11 AM, Rafa? Mi?ecki  wrote:
> It doesn't allow playing anything yet, but was the most tricky part to
> RE (it's indirect access, so couldn't trace it by dumping registers).
> Now we just need to implement support for HDMI blocks.

We actually have code implemented internally for DCE6/8 that we are
hoping to release for 3.12.

Alex

>
> Signed-off-by: Rafa? Mi?ecki 
> ---
>  drivers/gpu/drm/radeon/Makefile  |2 +-
>  drivers/gpu/drm/radeon/dce6_afmt.c   |   88 
> ++
>  drivers/gpu/drm/radeon/radeon_asic.h |2 +
>  drivers/gpu/drm/radeon/si.c  |7 +++
>  drivers/gpu/drm/radeon/sid.h |5 ++
>  5 files changed, 103 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/radeon/dce6_afmt.c
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index c3df52c..6510fc4 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -79,7 +79,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> si_blit_shaders.o radeon_prime.o radeon_uvd.o cik.o 
> cik_blit_shaders.o \
> r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o 
> rv740_dpm.o \
> rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
> trinity_dpm.o \
> -   trinity_smc.o ni_dpm.o si_smc.o si_dpm.o
> +   trinity_smc.o ni_dpm.o si_smc.o si_dpm.o dce6_afmt.o
>
>  radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
>  radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
> diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c 
> b/drivers/gpu/drm/radeon/dce6_afmt.c
> new file mode 100644
> index 000..0d98143
> --- /dev/null
> +++ b/drivers/gpu/drm/radeon/dce6_afmt.c
> @@ -0,0 +1,88 @@
> +/*
> + * Copyright ? 2013 Rafa? Mi?ecki 
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + * Authors: Rafa? Mi?ecki
> + */
> +#include 
> +#include 
> +#include "radeon.h"
> +#include "radeon_asic.h"
> +#include "sid.h"
> +
> +static u32 dce6_audio_read(struct radeon_device *rdev, u32 reg)
> +{
> +   WREG32(SI_AUDIO_ADDR, reg);
> +   return RREG32(SI_AUDIO_DATA);
> +}
> +
> +static void dce6_audio_write(struct radeon_device *rdev, u32 reg, u32 v)
> +{
> +   reg |= SI_AUDIO_ADDR_WRITE;
> +   WREG32(SI_AUDIO_ADDR, reg);
> +   WREG32(SI_AUDIO_DATA, v);
> +}
> +
> +static void dce6_audio_maskset(struct radeon_device *rdev, u32 reg, u32 mask,
> +  u32 set)
> +{
> +   u32 tmp = dce6_audio_read(rdev, reg);
> +   tmp &= mask;
> +   tmp |= set & ~mask;
> +   dce6_audio_write(rdev, reg, tmp);
> +}
> +
> +static void dce6_audio_enable(struct radeon_device *rdev, bool enable)
> +{
> +   DRM_INFO("%s audio support\n", enable ? "Enabling" : "Disabling");
> +
> +   if (enable) {
> +   dce6_audio_maskset(rdev, 0x54, ~0x8000, 0x8000);
> +   } else {
> +   dce6_audio_maskset(rdev, 0x54, ~0x8000, 0);
> +   /* TODO: clear some bit(s) in reg 0x36 */
> +   }
> +
> +   rdev->audio_enabled = enable;
> +}
> +
> +int dce6_audio_init(struct radeon_device *rdev)
> +{
> +   if (!radeon_audio)
> +   return 0;
> +
> +   dce6_audio_enable(rdev, true);
> +
> +   rdev->audio_status.channels = -1;
> +   rdev->audio_status.rate = -1;
> +   rdev->audio_status.bits_per_sample = -1;
> +   rdev->audio_status.status_bits = 0;
> +   rdev->audio_status.category_code = 0;
> +
> +   return 0;
> +}
> +
> +void dce6_audio_fini(struct radeon_device *rdev)
> +{
> +   if (!rdev->audio_enabled)
> +   return;
> +
> +   dce6_audio_enable(rdev, false);
> +}
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h 
> b/drivers/gpu/drm/radeon/radeon_asic.h
> index ca18957..48674ca 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> +++ b/drivers/gpu/drm/radeon/radeon_

[PATCH] drm/radeon: add very basic support for audio block on DCE6

[Rafał Miłecki]

2013/8/2 Alex Deucher :
> On Fri, Aug 2, 2013 at 4:11 AM, Rafa? Mi?ecki  wrote:
>> It doesn't allow playing anything yet, but was the most tricky part to
>> RE (it's indirect access, so couldn't trace it by dumping registers).
>> Now we just need to implement support for HDMI blocks.
>
> We actually have code implemented internally for DCE6/8 that we are
> hoping to release for 3.12.

Can you rebase it on my patches, please?

We already got few cases of just-to-be-released code, that couldn't be
release so fast.

-- 
Rafa?

[PATCH] drm/radeon: add very basic support for audio block on DCE6

[Rafał Miłecki]

2013/8/2 Rafa? Mi?ecki :
> 2013/8/2 Alex Deucher :
>> On Fri, Aug 2, 2013 at 4:11 AM, Rafa? Mi?ecki  wrote:
>>> It doesn't allow playing anything yet, but was the most tricky part to
>>> RE (it's indirect access, so couldn't trace it by dumping registers).
>>> Now we just need to implement support for HDMI blocks.
>>
>> We actually have code implemented internally for DCE6/8 that we are
>> hoping to release for 3.12.
>
> Can you rebase it on my patches, please?
>
> We already got few cases of just-to-be-released code, that couldn't be
> release so fast.

P.S.
I've code for HDMI working as well, I'm planning to release it on
Monday. So that hopefully will make your changes minimal for DCE6.

-- 
Rafa?

[PATCH] drm: const'ify ioctls table

[Rob Clark]

On Fri, Aug 2, 2013 at 6:51 AM, Ville Syrj?l?
 wrote:
> On Thu, Aug 01, 2013 at 02:25:27PM -0400, Rob Clark wrote:
>> Because, there is no reason for it not to be const.
>>
>> Signed-off-by: Rob Clark 
>> ---
> 
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> index 78e2164..eaf86e0 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
>> @@ -124,7 +124,7 @@
>>   * Ioctl definitions.
>>   */
>>
>> -static struct drm_ioctl_desc vmw_ioctls[] = {
>> +static const struct drm_ioctl_desc vmw_ioctls[] = {
>>   VMW_IOCTL_DEF(VMW_GET_PARAM, vmw_getparam_ioctl,
>> DRM_AUTH | DRM_UNLOCKED),
>>   VMW_IOCTL_DEF(VMW_ALLOC_DMABUF, vmw_dmabuf_alloc_ioctl,
>
> You forgot to fix vmw_unlocked_ioctl().

yeah, kbuild robot caught that too.. somehow I didn't have vmwgfx
enabled in my config (opps!).. fixed now

> Also if you're poking around this stuff, exynos and nouveau appear to
> set .num_ioctls from the probe/init funcs even though the ioctls array
> is right there in the same compilation unit.

good idea, I've squashed that in, so will be part of v2

BR,
-R

> --
> Ville Syrj?l?
> Intel OTC

i915 backlight

[Rafael J. Wysocki]

On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa  wrote:
> > Hello,
> >
> > I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
> > change to this parameter to the kernel boot:
> >
> >
> > GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\""
> 
> I think it's pretty obvious that for the time being we need to
> blacklist a ton of machines so they boot without this OSI. In fact, in
> might make sense to simply remove the OSI completely for all machines
> (for now).

That would have made sense 6 months ago, but not today.

The reason is that you don't really know what's affected by that and I'm
pretty sure it's not only backlight.

So no, we won't do that.

We *might* blacklist machines that shipped with Windows 7, but whose BIOSes
call the Windows 8 OSI, because there's a good chance they weren't really
tested with Windows 8.

Thanks,
Rafael

[PATCH] drm/radeon: add very basic support for audio block on DCE6

[Alex Deucher]

On Fri, Aug 2, 2013 at 9:40 AM, Rafa? Mi?ecki  wrote:
> 2013/8/2 Alex Deucher :
>> On Fri, Aug 2, 2013 at 4:11 AM, Rafa? Mi?ecki  wrote:
>>> It doesn't allow playing anything yet, but was the most tricky part to
>>> RE (it's indirect access, so couldn't trace it by dumping registers).
>>> Now we just need to implement support for HDMI blocks.
>>
>> We actually have code implemented internally for DCE6/8 that we are
>> hoping to release for 3.12.
>
> Can you rebase it on my patches, please?
>
> We already got few cases of just-to-be-released code, that couldn't be
> release so fast.

Maybe.  It depends how divergent it is.  There are actually a fair
amount of structural changes needed support the hw changes properly.
I guess I'll wait and see what your code looks like.

Alex

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66963

--- Comment #75 from Shawn Starr  ---
(In reply to comment #74)
> RV635 works for me. 
> 
> Make sure you have all of the firmware if you compile this kernel make sure
> kernel firmware is installed.

Well, it works but the clocking isn't adjusting properly. Working on IRC with
Alex, but no crashes.

-- 
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/20130802/311f8a5f/attachment.html>

i915 backlight

[Josep Lladonosa]

Hello,

I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
change to this parameter to the kernel boot:


GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\""


instead of previous

GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"

to be able to change brightness. In some kernel versions before, it
worked, but with 15 levels, but in graphical system brightness bar was
not moving.


Now I have, though, 8 possible values for brightness and brightness
bar shows its correct position.

Josep

On 2 August 2013 08:00, Aaron Lu  wrote:
> On 08/01/2013 04:07 PM, Borislav Petkov wrote:
>> On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
>>> Does reverting efaa14c help?
>>
>> Nope.
>>
>> But see my other reply to Aaron.
>
> Assume you have specified to use intel_backlight in xorg.conf, does
> booting with video.brightness_switch_enabled=0 help?
>
> Thanks,
> Aaron
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
--
Salutacions...Josep
--

i915 backlight

[Aaron Lu]

On 08/01/2013 04:07 PM, Borislav Petkov wrote:
> On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
>> Does reverting efaa14c help?
> 
> Nope.
> 
> But see my other reply to Aaron.

Assume you have specified to use intel_backlight in xorg.conf, does
booting with video.brightness_switch_enabled=0 help?

Thanks,
Aaron

i915 backlight

[Aaron Lu]

On 08/02/2013 02:25 PM, Josep Lladonosa wrote:
> Hello,
> 
> I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
> change to this parameter to the kernel boot:
> 
> 
> GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\""

What if you remove the above from kernel command line, and add
video.brightness_switch_enabled=0 to kernel command line, then set the
following in xorg.conf:
$ cat /etc/X11/xorg.conf
Section "Device"
Option "Backlight"  "intel_backlight"
Identifier  "Card0"
Driver  "intel"
BusID   "PCI:0:2:0"
EndSection

Does everything work?

If not, please test if manually change brightness level through sysfs
works:
# cd /sys/calss/backlight/intel_backlight
# echo xxx > brightness

And also test if hotkey event is sent out or not by running acpi_listen
and then press the hotkey.

Thanks,
Aaron

> 
> 
> instead of previous
> 
> GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
> 
> to be able to change brightness. In some kernel versions before, it
> worked, but with 15 levels, but in graphical system brightness bar was
> not moving.
> 
> 
> Now I have, though, 8 possible values for brightness and brightness
> bar shows its correct position.
> 
> Josep
> 
> On 2 August 2013 08:00, Aaron Lu  wrote:
>> On 08/01/2013 04:07 PM, Borislav Petkov wrote:
>>> On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
 Does reverting efaa14c help?
>>>
>>> Nope.
>>>
>>> But see my other reply to Aaron.
>>
>> Assume you have specified to use intel_backlight in xorg.conf, does
>> booting with video.brightness_switch_enabled=0 help?
>>
>> Thanks,
>> Aaron
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 

[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Vikas Sajjan]

Hi Rob,

On 2 August 2013 06:03, Rob Clark  wrote:
> On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa  wrote:
>> Hi Vikas,
>>
>> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
>>> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
>>> connected with resolution 2560x1600, following error occured even with
>>> IOMMU enabled:
>>> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
>>> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>>
>>> This patch fixes the issue by adding a check for IOMMU.
>>>
>>> Signed-off-by: Vikas Sajjan 
>>> Signed-off-by: Arun Kumar 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
>>> 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> @@ -16,6 +16,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  #include "exynos_drm_drv.h"
>>>  #include "exynos_drm_fb.h"
>>> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
>>> drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
>>>   unsigned long size;
>>>   int ret;
>>> + unsigned int flag;
>>>
>>>   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
>>>   sizes->surface_width, sizes->surface_height,
>>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
>>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>>>
>>>   /* 0 means to allocate physically continuous memory */
>>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
>>> + if (!is_drm_iommu_supported(dev))
>>> + flag = 0;
>>> + else
>>> + flag = EXYNOS_BO_NONCONTIG;
>>
>> While noncontig memory might be used for devices that support IOMMU, there
>> should be no problem with using contig memory for them, so this seems more
>> like masking the original problem rather than tracking it down.
>
> it is probably a good idea to not require contig memory when it is not
> needed for performance or functionality (and if it is only
> performance, then fallback gracefully to non-contig).. but yeah, would
> be good to know if this is masking another issue all the same
>

Whats happening with CONTIG flag and with IOMMU,  is

 __iommu_alloc_buffer() ---> dma_alloc_from_contiguous() and in this
function it fails at
this condition check  if (pageno >= cma->count)

So I tried increasing the CONFIG_CMA_SIZE_MBYTES to 24,  this check
succeeds and it works well without my patch.

But what about the case where CONFIG_CMA is disabled , yet i want
bigger memory for a device.
 I think using IOMMU we can achieve this.

 correct me, if i am wrong.


> BR,
> -R
>
>> Could you check why the allocation fails when requesting contiguous
>> memory?
>>
>> Best regards,
>> Tomasz
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks and Regards
 Vikas Sajjan

i915 backlight

[Josep Lladonosa]

Hello,

Yes, it works! I get now 11 levels from all black to the brightest.

acpi_listen shows messages

Josep

On 2 August 2013 08:36, Aaron Lu  wrote:
> On 08/02/2013 02:25 PM, Josep Lladonosa wrote:
>> Hello,
>>
>> I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
>> change to this parameter to the kernel boot:
>>
>>
>> GRUB_CMDLINE_LINUX="acpi_osi=\"!Windows 2012\""
>
> What if you remove the above from kernel command line, and add
> video.brightness_switch_enabled=0 to kernel command line, then set the
> following in xorg.conf:
> $ cat /etc/X11/xorg.conf
> Section "Device"
> Option "Backlight"  "intel_backlight"
> Identifier  "Card0"
> Driver  "intel"
> BusID   "PCI:0:2:0"
> EndSection
>
> Does everything work?
>
> If not, please test if manually change brightness level through sysfs
> works:
> # cd /sys/calss/backlight/intel_backlight
> # echo xxx > brightness
>
> And also test if hotkey event is sent out or not by running acpi_listen
> and then press the hotkey.
>
> Thanks,
> Aaron
>
>>
>>
>> instead of previous
>>
>> GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
>>
>> to be able to change brightness. In some kernel versions before, it
>> worked, but with 15 levels, but in graphical system brightness bar was
>> not moving.
>>
>>
>> Now I have, though, 8 possible values for brightness and brightness
>> bar shows its correct position.
>>
>> Josep
>>
>> On 2 August 2013 08:00, Aaron Lu  wrote:
>>> On 08/01/2013 04:07 PM, Borislav Petkov wrote:
 On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
> Does reverting efaa14c help?

 Nope.

 But see my other reply to Aaron.
>>>
>>> Assume you have specified to use intel_backlight in xorg.conf, does
>>> booting with video.brightness_switch_enabled=0 help?
>>>
>>> Thanks,
>>> Aaron
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>>
>>
>



-- 
--
Salutacions...Josep
--

[PATCH] drm/nouveau/acpi: de-dup use of DSM methods

[Peter Wu]

On Friday 02 August 2013 15:58:38 Dave Airlie wrote:
> On Fri, Aug 2, 2013 at 12:41 AM, Peter Wu  wrote:
> > Observe that nouveau_optimus_dsm and nouveau_dsm are equal except for
> > the parameters handling (UUID, revision ID and function arguments). The
> > function arguments are passed as Buffer in the "optimus dsm" and Integer
> > in "nvidia dsm". As buffers are implicitly converted to integers, merge
> > both functions.
> > 
> > The ACPI spec defines the fourth parameter (Arg3 a.k.a. "function
> > arguments") as Package, but many BIOSes expect a Buffer instead. For
> > instance, for the "nvidia DSM", the Lenovo T410s uses CreateByteField on
> > Arg3 which does not work with a package. The Clevo B7130 does something
> > similar for the "Optimus DSM". Unfortunately, this means that the
> > following ACPI warning (introduced with 29a241c) cannot be fixed (when
> 
> > toggling power or muxing):
> By cannot be fixed, why is it there then? maybe ask the ACPI folks to
> drop this error, since as far as I can see all optimus dsm want a
> buffer here.

It helps tracking violations of the ACPI spec which can be used as debugging 
tool, as a result there is also a patch for i915 (which was based on this 
nouveau code). Of course, if real world only uses Buffers, then this warning 
should be dropped/changed, but there are more users of _DSM besides the 
graphics subsystem.

Regards,
Peter

> > ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found
> > [Buffer], ACPI requires [Package] (20130517/nsarguments-95) ACPI
> > Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found
> > [Buffer], ACPI requires [Package] (20130517/nsarguments-95) ACPI
> > Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
> > [Buffer], ACPI requires [Package] (20130517/nsarguments-95) ACPI
> > Warning: \_SB_.PCI0.P0P2.PEGP._DSM: Argument #4 type mismatch - Found
> > [Buffer], ACPI requires [Package] (20130517/nsarguments-95)> 
> > Signed-off-by: Peter Wu 
> > ---
> > 
> >  drivers/gpu/drm/nouveau/nouveau_acpi.c | 67
> >  ++ 1 file changed, 20 insertions(+), 47
> >  deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> > b/drivers/gpu/drm/nouveau/nouveau_acpi.c index d97f200..a75684f 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> > @@ -46,6 +46,9 @@ bool nouveau_is_v1_dsm(void) {
> > 
> >  #define NOUVEAU_DSM_HAS_MUX 0x1
> >  #define NOUVEAU_DSM_HAS_OPT 0x2
> > 
> > +#define NOUVEAU_DSM_REVID_NVIDIA 0x102
> > +#define NOUVEAU_DSM_REVID_OPTIMUS 0x100
> > +
> > 
> >  static const char nouveau_dsm_muid[] = {
> >  
> > 0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
> > 0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4,
> > 
> > @@ -56,7 +59,8 @@ static const char nouveau_op_dsm_muid[] = {
> > 
> > 0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0,
> >  
> >  };
> > 
> > -static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg,
> > uint32_t *result) +static int nouveau_call_dsm(acpi_handle handle, const
> > char *uuid, int revid, +   int func, int arg, uint32_t *result)
> > 
> >  {
> >  
> > struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> > struct acpi_object_list input;
> > 
> > @@ -68,12 +72,15 @@ static int nouveau_optimus_dsm(acpi_handle handle, int
> > func, int arg, uint32_t *> 
> > input.count = 4;
> > input.pointer = params;
> > params[0].type = ACPI_TYPE_BUFFER;
> > 
> > -   params[0].buffer.length = sizeof(nouveau_op_dsm_muid);
> > -   params[0].buffer.pointer = (char *)nouveau_op_dsm_muid;
> > +   params[0].buffer.length = 16;
> > +   params[0].buffer.pointer = (char *)uuid;
> > 
> > params[1].type = ACPI_TYPE_INTEGER;
> > 
> > -   params[1].integer.value = 0x0100;
> > +   params[1].integer.value = revid;
> > 
> > params[2].type = ACPI_TYPE_INTEGER;
> > params[2].integer.value = func;
> > 
> > +   /* Although the ACPI spec defines Arg3 as a Package, in practise
> > +* implementations expect a Buffer (CreateWordField and Index
> > functions +* are applied to it). */
> > 
> > params[3].type = ACPI_TYPE_BUFFER;
> > params[3].buffer.length = 4;
> > /* ACPI is little endian, AABBCCDD becomes {DD,CC,BB,AA} */
> > 
> > @@ -108,50 +115,16 @@ static int nouveau_optimus_dsm(acpi_handle handle,
> > int func, int arg, uint32_t *> 
> > return 0;
> >  
> >  }
> > 
> > -static int nouveau_dsm(acpi_handle handle, int func, int arg, uint32_t
> > *result) -{
> > -   struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
> > -   struct acpi_object_list input;
> > -   union acpi_object params[4];
> > -   union acpi_object *obj;
> > -   int err;
> > -
> > -   input.count = 4;
> > -   input.pointer = params;
> > -   params[0].type = ACPI_TYPE_BU

[PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag

[Vikas Sajjan]

Hi Inki Dae,

On 2 August 2013 12:58, Inki Dae  wrote:
>
>
> 2013/8/2 Vikas Sajjan 
>>
>> Hi Rob,
>>
>> On 2 August 2013 06:03, Rob Clark  wrote:
>> > On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa 
>> > wrote:
>> >> Hi Vikas,
>> >>
>> >> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
>> >>> While trying to get boot-logo up on exynos5420 SMDK which has eDP
>> >>> panel
>> >>> connected with resolution 2560x1600, following error occured even with
>> >>> IOMMU enabled:
>> >>> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
>> >>> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>> >>>
>> >>> This patch fixes the issue by adding a check for IOMMU.
>> >>>
>> >>> Signed-off-by: Vikas Sajjan 
>> >>> Signed-off-by: Arun Kumar 
>> >>> ---
>> >>>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>> >>>  1 file changed, 8 insertions(+), 1 deletion(-)
>> >>>
>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> >>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
>> >>> 100644
>> >>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> >>> @@ -16,6 +16,7 @@
>> >>>  #include 
>> >>>  #include 
>> >>>  #include 
>> >>> +#include 
>> >>>
>> >>>  #include "exynos_drm_drv.h"
>> >>>  #include "exynos_drm_fb.h"
>> >>> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
>> >>> drm_fb_helper *helper, struct platform_device *pdev =
>> >>> dev->platformdev;
>> >>>   unsigned long size;
>> >>>   int ret;
>> >>> + unsigned int flag;
>> >>>
>> >>>   DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
>> >>>   sizes->surface_width, sizes->surface_height,
>> >>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
>> >>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>> >>>
>> >>>   /* 0 means to allocate physically continuous memory */
>> >>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
>> >>> + if (!is_drm_iommu_supported(dev))
>> >>> + flag = 0;
>> >>> + else
>> >>> + flag = EXYNOS_BO_NONCONTIG;
>> >>
>> >> While noncontig memory might be used for devices that support IOMMU,
>> >> there
>> >> should be no problem with using contig memory for them, so this seems
>> >> more
>> >> like masking the original problem rather than tracking it down.
>> >
>> > it is probably a good idea to not require contig memory when it is not
>> > needed for performance or functionality (and if it is only
>> > performance, then fallback gracefully to non-contig).. but yeah, would
>> > be good to know if this is masking another issue all the same
>> >
>>
>> Whats happening with CONTIG flag and with IOMMU,  is
>>
>>  __iommu_alloc_buffer() ---> dma_alloc_from_contiguous() and in this
>> function it fails at
>> this condition check  if (pageno >= cma->count)
>>
>> So I tried increasing the CONFIG_CMA_SIZE_MBYTES to 24,  this check
>> succeeds and it works well without my patch.
>>
>> But what about the case where CONFIG_CMA is disabled , yet i want
>> bigger memory for a device.
>>  I think using IOMMU we can achieve this.
>>
>>  correct me, if i am wrong.
>>
>
> I'm on summer vacation so I'm afraid that I cannot test and look into it but
> I guess you guy didn't declare CMA region for Exynos drm. And in this case,
> the size of CMA declared region is 16MB as default. That is why works well
> after increasing default size, CONFIG_CMA_SIZE_MBYTES, to 24MB. And I
> mentioned long time ago, we are required to use physically contiguous memory
> in case that bootloader uses physically contiguous memory for its own
> framebuffer, and kernel wants to share the bootloader's framebuffer region
> to resolve flickering issue while booted; that is required for product. And
> one question, is there any reason that you guy should use non-contiguous
> memory for framebuffer with iommu?
>

yeah, we could not allocate CMA region for FIMD, because the function
dma_declare_contiguous() needs "dev" as the first argument and we have
access to "dev" node only if it is NON-DT way of probing like the way
it is done in arch/arm/mach-davinci/devices-da8xx.c
But now, since the probing is through DT way, there is NO way ( Let me
know if something is newly added ) to call dma_declare_contiguous()
and reserve CMA region .

we don't have any specific requirement for NON_CONTIG or CONTIG
memory, but only requirement was to allocate a bigger memory like (
2560 * 1600 * 4 ) for FB.

But as Rob suggested, we should have fall-back case if CONTIG memory
allocation fails, as below

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index df43fa9..15de626 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -144,7 +144,6 @@ static int exynos_drm_fbdev_create(struct
drm_fb_helper *helper,
struct platform_device *

[PATCH] drm: don't push static constants on stack for %*ph

[Andy Shevchenko]

There is no need to pass constants via stack. The width may be explicitly
specified in the format.

Signed-off-by: Andy Shevchenko 
---
 drivers/gpu/drm/nouveau/core/engine/disp/dport.c | 2 +-
 drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
 drivers/gpu/drm/udl/udl_main.c   | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c 
b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
index 31cc8fe..054d9cf 100644
--- a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
+++ b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
@@ -150,7 +150,7 @@ dp_link_train_update(struct dp_state *dp, u32 delay)
if (ret)
return ret;

-   DBG("status %*ph\n", 6, dp->stat);
+   DBG("status %6ph\n", dp->stat);
return 0;
 }

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 32501f6..3569d89 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -585,7 +585,7 @@ static bool radeon_dp_get_link_status(struct 
radeon_connector *radeon_connector,
return false;
}

-   DRM_DEBUG_KMS("link status %*ph\n", 6, link_status);
+   DRM_DEBUG_KMS("link status %6ph\n", link_status);
return true;
 }

diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 0ce2d71..f5ae574 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -41,8 +41,8 @@ static int udl_parse_vendor_descriptor(struct drm_device *dev,
total_len = usb_get_descriptor(usbdev, 0x5f, /* vendor specific */
0, desc, MAX_VENDOR_DESCRIPTOR_SIZE);
if (total_len > 5) {
-   DRM_INFO("vendor descriptor length:%x data:%*ph\n",
-   total_len, 11, desc);
+   DRM_INFO("vendor descriptor length:%x data:%11ph\n",
+   total_len, desc);

if ((desc[0] != total_len) || /* descriptor length */
(desc[1] != 0x5f) ||   /* vendor descriptor type */
-- 
1.8.4.rc0

[PATCH] drm/radeon: add very basic support for audio block on DCE6

[Rafał Miłecki]

2013/8/2 Alex Deucher :
> On Fri, Aug 2, 2013 at 9:40 AM, Rafa? Mi?ecki  wrote:
>> 2013/8/2 Alex Deucher :
>>> On Fri, Aug 2, 2013 at 4:11 AM, Rafa? Mi?ecki  wrote:
 It doesn't allow playing anything yet, but was the most tricky part to
 RE (it's indirect access, so couldn't trace it by dumping registers).
 Now we just need to implement support for HDMI blocks.
>>>
>>> We actually have code implemented internally for DCE6/8 that we are
>>> hoping to release for 3.12.
>>
>> Can you rebase it on my patches, please?
>>
>> We already got few cases of just-to-be-released code, that couldn't be
>> release so fast.
>
> Maybe.  It depends how divergent it is.  There are actually a fair
> amount of structural changes needed support the hw changes properly.
> I guess I'll wait and see what your code looks like.

OK. It's similar to the current DCE2/3/4 support and register
operations are based on fglrx MMIO dump, so they should be pretty much
correct. It's not programming based on regs dumps only anymore :)

-- 
Rafa?

[Bug 64503] audio glitches when running at 24hz/24p

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #20 from Pierre Ossman  ---
First off, I've upgraded to Fedora 19 and kernel-3.10.3-300.fc19.x86_64. That
in itself had no effect on the bug, good or bad.

(In reply to comment #19)
> does this patch help:
> http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.
> 11&id=dffd4b65ca8989acb914da3c685c798ca5fcf99c

I also had to apply these two:

http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=7d61d835824f73dc4097b51f800382467c8049c5
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11&id=9509f9a174b39db215edf7752de4847eaaca2775

Unfortunately the problem remains. =/

-- 
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/20130802/eedcc860/attachment.html>

Regression introduced by 31f731a drm/radeon/dpm: fix calculations in si_calculate_leakage_for_v_and_t_formula

[Konrad Rzeszutek Wilk]

Hey Alex,

Your recent patch "31f731a drm/radeon/dpm: fix calculations in
si_calculate_leakage_for_v_and_t_formula" causes a build regression:

drivers/built-in.o: In function `si_calculate_leakage_for_v_and_t_formula':
/home/build/linux-linus/drivers/gpu/drm/radeon/si_dpm.c:1770: undefined
reference to `__divdi3'

Which I think is due to the misplace parentheses.

Regression introduced by 31f731a drm/radeon/dpm: fix calculations in si_calculate_leakage_for_v_and_t_formula

[Alex Deucher]

On Fri, Aug 2, 2013 at 11:16 AM, Konrad Rzeszutek Wilk
 wrote:
> Hey Alex,
>
> Your recent patch "31f731a drm/radeon/dpm: fix calculations in
> si_calculate_leakage_for_v_and_t_formula" causes a build regression:
>
> drivers/built-in.o: In function `si_calculate_leakage_for_v_and_t_formula':
> /home/build/linux-linus/drivers/gpu/drm/radeon/si_dpm.c:1770: undefined
> reference to `__divdi3'
>
> Which I think is due to the misplace parentheses.

Fixed with this patch:
http://lists.freedesktop.org/archives/dri-devel/2013-August/042668.html

Alex

[Bug 64503] audio glitches when running at 24hz/24p

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #21 from Pierre Ossman  ---
Just to confirm this is a driver problem, I tried two things:

 - Hooked up a Windows machine (also with a radeon card, although a different
one)

 - Installed fglrx on my Linux machine.

In both cases the playback was glitch free in 24 Hz.

-- 
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/20130802/dc3c0da0/attachment-0001.html>

[Bug 66384] VDPAU playback hangs when moving window between xrandr monitors

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66384

--- Comment #2 from Michel D?nzer  ---
Created attachment 83546
  --> https://bugs.freedesktop.org/attachment.cgi?id=83546&action=edit
Attempt at making DRI2 MSC counter consistent between CRTCs

Here's an attempt at making the DRI2 MSC counter per-window instead of
per-CRTC. I couldn't quite make it work, but maybe someone can run with this
and finish it.

-- 
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/20130802/f3b15ccd/attachment.html>

[PATCH] drm: don't push static constants on stack for %*ph

[David Herrmann]

Hi

On Fri, Aug 2, 2013 at 1:09 PM, Andy Shevchenko
 wrote:
> There is no need to pass constants via stack. The width may be explicitly
> specified in the format.

Yupp, all 3 make sense and actually speed up "format_decode()".
  Reviewed-by: David Herrmann 

Regards
David

> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/gpu/drm/nouveau/core/engine/disp/dport.c | 2 +-
>  drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
>  drivers/gpu/drm/udl/udl_main.c   | 4 ++--
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c 
> b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
> index 31cc8fe..054d9cf 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/disp/dport.c
> @@ -150,7 +150,7 @@ dp_link_train_update(struct dp_state *dp, u32 delay)
> if (ret)
> return ret;
>
> -   DBG("status %*ph\n", 6, dp->stat);
> +   DBG("status %6ph\n", dp->stat);
> return 0;
>  }
>
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index 32501f6..3569d89 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -585,7 +585,7 @@ static bool radeon_dp_get_link_status(struct 
> radeon_connector *radeon_connector,
> return false;
> }
>
> -   DRM_DEBUG_KMS("link status %*ph\n", 6, link_status);
> +   DRM_DEBUG_KMS("link status %6ph\n", link_status);
> return true;
>  }
>
> diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
> index 0ce2d71..f5ae574 100644
> --- a/drivers/gpu/drm/udl/udl_main.c
> +++ b/drivers/gpu/drm/udl/udl_main.c
> @@ -41,8 +41,8 @@ static int udl_parse_vendor_descriptor(struct drm_device 
> *dev,
> total_len = usb_get_descriptor(usbdev, 0x5f, /* vendor specific */
> 0, desc, MAX_VENDOR_DESCRIPTOR_SIZE);
> if (total_len > 5) {
> -   DRM_INFO("vendor descriptor length:%x data:%*ph\n",
> -   total_len, 11, desc);
> +   DRM_INFO("vendor descriptor length:%x data:%11ph\n",
> +   total_len, desc);
>
> if ((desc[0] != total_len) || /* descriptor length */
> (desc[1] != 0x5f) ||   /* vendor descriptor type */
> --
> 1.8.4.rc0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 60523] Lockup with radeon DPM on Radeon HD5770 (Juniper)

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=60523

--- Comment #14 from Tobias Droste  ---
I changed rv770_smc.c to this: http://pastebin.com/eMzfrAaZ, but there aren't
any message in dmesg after booting.

'echo low > power_dpm_force_performance_level' fails, but is also not printing
something to dmesg. 
Changing from 1 monitor to 2 and back is also not printing something to dmesg.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 64503] audio glitches when running at 24hz/24p

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=64503

--- Comment #22 from Pierre Ossman  ---
Argh! Problem found...

It was actually the mode that was incorrect. xrandr rounds things off, so it
looked like it was the same as the working case, but actually wasn't.

Proper modeline:

Modeline "1920x1080"x24.0   74.25  1920 2558 2602 2750  1080 1084 1089 1125
+hsync +vsync (27.0 kHz e)

Horrible evil modeline:

ModeLine "1920x1080 at 23.976" 74.175 1920 2558 2602 2750 1080 1084 1089 1125
+hsync +vsync


The reason I had that was from back in ancient times when the radeon driver
didn't properly grok the 24p mode from EDID for some reason. But it seems I got
the NTSC I-can't-believe-it's-not-real-24p mode instead of the proper film one.


So with that hack removed it seems like the audio glitch is gone. Sorry for all
the noise. :/

-- 
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/20130802/93a28fd6/attachment.html>

[PATCH 3/3] drm: Remove drm_mode_validate_clocks

[David Herrmann]

Hi

On Wed, Jul 31, 2013 at 2:23 AM, St?phane Marchesin
 wrote:
> Signed-off-by: St?phane Marchesin 

Something like "unused" in the commit message makes "git log
[--oneline]" much more verbose without the need to read the patch.
Apart from that:
  Reviewed-by: David Herrmann 

I also did a short "grep MODE_CLOCK_RANGE" and radeon/i915 tv-helpers
are the last users. All others use MODE_BAD. But I guess
MODE_CLOCK_RANGE is more verbose so there is no need to remove it.

Regards
David

> ---
>  drivers/gpu/drm/drm_modes.c | 37 -
>  include/drm/drm_crtc.h  |  3 ---
>  2 files changed, 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index a6729bf..504a602 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -923,43 +923,6 @@ void drm_mode_validate_size(struct drm_device *dev,
>  EXPORT_SYMBOL(drm_mode_validate_size);
>
>  /**
> - * drm_mode_validate_clocks - validate modes against clock limits
> - * @dev: DRM device
> - * @mode_list: list of modes to check
> - * @min: minimum clock rate array
> - * @max: maximum clock rate array
> - * @n_ranges: number of clock ranges (size of arrays)
> - *
> - * LOCKING:
> - * Caller must hold a lock protecting @mode_list.
> - *
> - * Some code may need to check a mode list against the clock limits of the
> - * device in question.  This function walks the mode list, testing to make
> - * sure each mode falls within a given range (defined by @min and @max
> - * arrays) and sets @mode->status as needed.
> - */
> -void drm_mode_validate_clocks(struct drm_device *dev,
> - struct list_head *mode_list,
> - int *min, int *max, int n_ranges)
> -{
> -   struct drm_display_mode *mode;
> -   int i;
> -
> -   list_for_each_entry(mode, mode_list, head) {
> -   bool good = false;
> -   for (i = 0; i < n_ranges; i++) {
> -   if (mode->clock >= min[i] && mode->clock <= max[i]) {
> -   good = true;
> -   break;
> -   }
> -   }
> -   if (!good)
> -   mode->status = MODE_CLOCK_RANGE;
> -   }
> -}
> -EXPORT_SYMBOL(drm_mode_validate_clocks);
> -
> -/**
>   * drm_mode_prune_invalid - remove invalid modes from mode list
>   * @dev: DRM device
>   * @mode_list: list of modes to check
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index fa12a2f..32e0820 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -930,9 +930,6 @@ extern void drm_mode_list_concat(struct list_head *head,
>  extern void drm_mode_validate_size(struct drm_device *dev,
>struct list_head *mode_list,
>int maxX, int maxY, int maxPitch);
> -extern void drm_mode_validate_clocks(struct drm_device *dev,
> -struct list_head *mode_list,
> -int *min, int *max, int n_ranges);
>  extern void drm_mode_prune_invalid(struct drm_device *dev,
>struct list_head *mode_list, bool verbose);
>  extern void drm_mode_sort(struct list_head *mode_list);
> --
> 1.8.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] radeon: si_dpm.c: avoid a signed 64-bit divide

[Deucher, Alexander]

The fix is already queued in my tree:
http://lists.freedesktop.org/archives/dri-devel/2013-August/042668.html


> -Original Message-
> From: Kyle McMartin [mailto:kmcmarti at redhat.com]
> Sent: Friday, August 02, 2013 1:13 PM
> To: jglisse at redhat.com
> Cc: Deucher, Alexander; airlied at redhat.com; dri-
> devel at lists.freedesktop.org; jwboyer at redhat.com
> Subject: [PATCH] radeon: si_dpm.c: avoid a signed 64-bit divide
> 
> Hit a compile failure here referencing divdi3 on i686.
> 
> Signed-off-by: Kyle McMartin 
> 
> --- a/drivers/gpu/drm/radeon/si_dpm.c
> +++ b/drivers/gpu/drm/radeon/si_dpm.c
> @@ -1767,7 +1767,7 @@ static void
> si_calculate_leakage_for_v_and_t_formula(const struct ni_leakage_coe
>   s64 temperature, t_slope, t_intercept, av, bv, t_ref;
>   s64 tmp;
> 
> - i_leakage = drm_int2fixp(ileakage) / 100;
> + i_leakage = div64_s64(drm_int2fixp(ileakage), 100);
>   vddc = div64_s64(drm_int2fixp(v), 1000);
>   temperature = div64_s64(drm_int2fixp(t), 1000);
>