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.
--

i915 backlight

[Josep Lladonosa]

"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".

Josep

On 2 August 2013 22:08, Felipe Contreras  wrote:
> 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



-- 
--
Salutacions...Josep
--

i915 backlight

[Josep Lladonosa]

Hi,

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.

Josep

On 2 August 2013 20:58, 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.
>
>> 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



-- 
--
Salutacions...Josep
--

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 

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

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

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

--- Comment #3 from t3st3r at 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.

[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] 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 67110] [radeonsi] Anomaly Warzone Earth games are segfaulting

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

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.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130802/8d5e56f4/attachment-0001.html>

[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);
> 

[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>

[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.

[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>

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

[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?

[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   = _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(_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 

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/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", , );
> -   if (err) {
> -   printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
> -   return err;
> -   }
> -
> -   obj = (union acpi_object *)output.pointer;
> -
> -  

[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=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/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/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 

[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>

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

[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=dffd4b65ca8989acb914da3c685c798ca5fcf99c

I also had to apply these two:

http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11=7d61d835824f73dc4097b51f800382467c8049c5
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11=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>

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: 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

[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

[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

[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

[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: 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   = _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(_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 drm_device *dev, 

[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. ;-)

[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);

[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

[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, >mode_config.encoder_list,
base.head) {
+   enum pipe pipe;
if (encoder->base.crtc != >base)
continue;
-   if (encoder->get_config)
+   if (encoder->get_config &&
+   encoder->get_hw_state(encoder, ))
encoder->get_config(encoder, _config);
}

-- 
1.8.1.5

-- 
Ville Syrj?l?
Intel OTC

[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

[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>

[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

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>

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.

[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

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.
--

[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/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 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]

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);

 

[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

[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

[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 = 

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/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/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

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/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
> +++ 

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
--

[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>

[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

[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 #70 from Sergey  ---
Works good for me:

Major:
5 of 5 boots after shutdown.
5 of 5 boots after reboot.
First boot after shutdown hanged though.

Suspend:
Works always for me 10 of 10. Checked different states.

Hibernate:
Works most of the time but sometimes hangs.
Have seen a lot hangs on 'battery' state. But last boot to confirm worked fine
2 times.
2 hangs in default 'balanced' mode. After this hangs got 2-3 hangs in a row
after shutdowns.

Minor:
If I run 'glxgear' hibernate resumes with slow Xorg, sometimes dies after
resume.
Same works with suspend.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[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 #69 from Hrvoje Senjan  ---
(In reply to comment #60)
> (In reply to comment #59)
> > please try this branch:
> > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11
> > after a cold shutdown.
> 
> This seems to have fixed the issues here :-)
> 

Works correctly only on cold boot. With reboots i get:

[   52.630102] radeon :01:00.0: GPU lockup CP stall for more than 27055msec
[   52.630115] radeon :01:00.0: GPU lockup (waiting for 0x0058
last fence id 0x0001)
[   52.993495] radeon :01:00.0: Saved 2809 dwords of commands on ring 0.
[   52.993508] radeon :01:00.0: GPU softreset: 0x0348
[   52.993511] radeon :01:00.0:   R_008010_GRBM_STATUS  = 0xA0003030
[   52.993514] radeon :01:00.0:   R_008014_GRBM_STATUS2 = 0x0003
[   52.993517] radeon :01:00.0:   R_000E50_SRBM_STATUS  = 0x200291C0
[   52.993520] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[   52.993523] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[   52.993526] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x0802
[   52.993528] radeon :01:00.0:   R_008680_CP_STAT  = 0x80C1
[   52.993531] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[   53.369474] radeon :01:00.0: Wait for MC idle timedout !
[   53.369478] radeon :01:00.0: R_008020_GRBM_SOFT_RESET=0x4001
[   53.369532] radeon :01:00.0: SRBM_SOFT_RESET=0x00022500
[   53.371674] radeon :01:00.0:   R_008010_GRBM_STATUS  = 0xA0003030
[   53.371677] radeon :01:00.0:   R_008014_GRBM_STATUS2 = 0x0003
[   53.371680] radeon :01:00.0:   R_000E50_SRBM_STATUS  = 0x200210C0
[   53.371683] radeon :01:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[   53.371685] radeon :01:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[   53.371688] radeon :01:00.0:   R_00867C_CP_BUSY_STAT = 0x
[   53.371691] radeon :01:00.0:   R_008680_CP_STAT  = 0x8010
[   53.371694] radeon :01:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[   53.371700] radeon :01:00.0: GPU reset succeeded, trying to resume
[   53.536342] [drm] PCIE GART of 512M enabled (table at 0x0004).
[   53.536389] radeon :01:00.0: WB enabled
[   53.536393] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x2c00 and cpu addr 0x880137055c00
[   53.536396] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x2c0c and cpu addr 0x880137055c0c
[   53.734069] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x8504)=0xCAFEDEAD)
[   53.734073] [drm:r600_resume] *ERROR* r600 startup failed on resume
[   53.736171] switching from power state:
[   53.736176]  ui class: none
[   53.736180]  internal class: boot 
[   53.736184]  caps: video 
[   53.736189]  uvdvclk: 0 dclk: 0
[   53.736193]  power level 0sclk: 6 mclk: 5 vddc: 1100
[   53.736196]  power level 1sclk: 6 mclk: 5 vddc: 1100
[   53.736199]  power level 2sclk: 6 mclk: 5 vddc: 1100
[   53.736201]  status: c b 
[   53.736206] switching to power state:
[   53.736208]  ui class: performance
[   53.736210]  internal class: none
[   53.736214]  caps: single_disp video 
[   53.736219]  uvdvclk: 0 dclk: 0
[   53.736223]  power level 0sclk: 11000 mclk: 4 vddc: 900
[   53.736226]  power level 1sclk: 3 mclk: 4 vddc: 900
[   53.736229]  power level 2sclk: 6 mclk: 5 vddc: 1100
[   53.736231]  status: r 
[   60.620870] SysRq : Keyboard mode set to system default

SysRQ + R,I brings back normal display

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[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 #13 from Tobias Droste  ---
The only active component is kwin with compositing. 
But even if I disable compositing and don't touch the mouse or keyboard for a
while the state doesn't change. 

I also doubt that's the problem because

# echo high > power_dpm_force_performance_level

gives 

bash: echo: write error: Invalid argument

with 2 monitors attached and works fine with 1 monitor.

Maybe a weird bug in the bios? But the card works fine with catalyst in
windows.

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

[PATCH] drm/radeon/dpm: implement force performance levels for rs780

[Anthoine Bourgeois]

2013/8/1 Deucher, Alexander 

> > -Original Message-
> > From: Anthoine Bourgeois [mailto:anthoine.bourgeois at gmail.com]
> > Sent: Wednesday, July 31, 2013 6:34 PM
> > To: Deucher, Alexander; Koenig, Christian; Jerome Glisse; Anthoine
> > Bourgeois
> > Cc: dri-devel at lists.freedesktop.org
> > Subject: [PATCH] drm/radeon/dpm: implement force performance levels for
> > rs780
> >
> > Allows you to limit the selected power levels via sysfs.
> >
> > Force the feedback divider to select a power level.
>
> Nice work.  A few comments below.
>
> Alex
>
> >
> > Signed-off-by: Anthoine Bourgeois 
> > ---
> >  drivers/gpu/drm/radeon/radeon_asic.c |  1 +
> >  drivers/gpu/drm/radeon/radeon_asic.h |  2 ++
> >  drivers/gpu/drm/radeon/rs780_dpm.c   | 67
> > ++--
> >  3 files changed, 59 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> > b/drivers/gpu/drm/radeon/radeon_asic.c
> > index f8f8b31..437d357 100644
> > --- a/drivers/gpu/drm/radeon/radeon_asic.c
> > +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> > @@ -1272,6 +1272,7 @@ static struct radeon_asic rs780_asic = {
> >   .get_mclk = _dpm_get_mclk,
> >   .print_power_state = _dpm_print_power_state,
> >   .debugfs_print_current_performance_level =
> > _dpm_debugfs_print_current_performance_level,
> > + .force_performance_level =
> > _dpm_force_performance_level,
> >   },
> >   .pflip = {
> >   .pre_page_flip = _pre_page_flip,
> > diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
> > b/drivers/gpu/drm/radeon/radeon_asic.h
> > index 902479f..09841fc 100644
> > --- a/drivers/gpu/drm/radeon/radeon_asic.h
> > +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> > @@ -437,6 +437,8 @@ void rs780_dpm_print_power_state(struct
> > radeon_device *rdev,
> >struct radeon_ps *ps);
> >  void rs780_dpm_debugfs_print_current_performance_level(struct
> > radeon_device *rdev,
> >  struct seq_file *m);
> > +int rs780_dpm_force_performance_level(struct radeon_device *rdev,
> > +   enum radeon_dpm_forced_level level);
> >
> >  /* uvd */
> >  int r600_uvd_init(struct radeon_device *rdev);
> > diff --git a/drivers/gpu/drm/radeon/rs780_dpm.c
> > b/drivers/gpu/drm/radeon/rs780_dpm.c
> > index d1a1ce7..df58e34 100644
> > --- a/drivers/gpu/drm/radeon/rs780_dpm.c
> > +++ b/drivers/gpu/drm/radeon/rs780_dpm.c
> > @@ -404,6 +404,27 @@ static void rs780_force_voltage_to_high(struct
> > radeon_device *rdev)
> >   WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> >  }
> >
> > +static void rs780_force_fbdiv(struct radeon_device *rdev, u32 fb_div)
> > +{
> > + struct igp_ps *current_state = rs780_get_ps(rdev-
> > >pm.dpm.current_ps);
> > +
> > + if ((current_state->sclk_low == fb_div) &&
> > + (current_state->sclk_high == fb_div))
> > + return;
>
> I'm not quite sure what you are checking here.
>

Oh yes, my mistake, fb_div shouldn't be in that condition. In my memory, I
just wanted to check that sclk_low is equal to sclk_high. In that case, no
need to force the fbdiv because there are the same.


>
> > +
> > + WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL,
> > ~SPLL_BYPASS_CNTL);
> > +
> > + WREG32_P(FVTHROT_FBDIV_REG2,
> > FORCED_FEEDBACK_DIV(fb_div),
> > +  ~FORCED_FEEDBACK_DIV_MASK);
> > + WREG32_P(FVTHROT_FBDIV_REG1,
> > STARTING_FEEDBACK_DIV(fb_div),
> > +  ~STARTING_FEEDBACK_DIV_MASK);
> > + WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV,
> > ~FORCE_FEEDBACK_DIV);
> > +
> > + udelay(100);
> > +
> > + WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> > +}
> > +
> >  static int rs780_set_engine_clock_scaling(struct radeon_device *rdev,
> > struct radeon_ps *new_ps,
> > struct radeon_ps *old_ps)
> > @@ -432,17 +453,7 @@ static int rs780_set_engine_clock_scaling(struct
> > radeon_device *rdev,
> >   if (ret)
> >   return ret;
> >
> > - WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL,
> > ~SPLL_BYPASS_CNTL);
> > -
> > - WREG32_P(FVTHROT_FBDIV_REG2,
> > FORCED_FEEDBACK_DIV(max_dividers.fb_div),
> > -  ~FORCED_FEEDBACK_DIV_MASK);
> > - WREG32_P(FVTHROT_FBDIV_REG1,
> > STARTING_FEEDBACK_DIV(max_dividers.fb_div),
> > -  ~STARTING_FEEDBACK_DIV_MASK);
> > - WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV,
> > ~FORCE_FEEDBACK_DIV);
> > -
> > - udelay(100);
> > -
> > - WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
> > + rs780_force_fbdiv(rdev, max_dividers.fb_div);
> >
> >   if (max_dividers.fb_div > min_dividers.fb_div) {
> >   WREG32_P(FVTHROT_FBDIV_REG0,
> > @@ -986,3 +997,37 @@ void
> > rs780_dpm_debugfs_print_current_performance_level(struct
> > radeon_device *rde
> >   

[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 #68 from Alex Deucher  ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm/i915: add fast boot support for Haswell

[Furquan Shaikh]

Enables getting correct mode clock when reading pipe config

Signed-off-by: Furquan Shaikh furq...@google.com
---
 drivers/gpu/drm/i915/intel_ddi.c | 8 
 drivers/gpu/drm/i915/intel_display.c | 9 -
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 931b4bb..fa0af9b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1269,6 +1269,7 @@ static void intel_ddi_get_config(struct intel_encoder 
*encoder,
struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder-base.crtc);
enum transcoder cpu_transcoder = intel_crtc-config.cpu_transcoder;
+   int port = intel_ddi_get_encoder_port(encoder);
u32 temp, flags = 0;
 
temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
@@ -1282,6 +1283,13 @@ static void intel_ddi_get_config(struct intel_encoder 
*encoder,
flags |= DRM_MODE_FLAG_NVSYNC;
 
pipe_config-adjusted_mode.flags |= flags;
+
+   if (port == PORT_A) {
+   if ((I915_READ(DP_A)  DP_PLL_FREQ_MASK) == DP_PLL_FREQ_160MHZ)
+   pipe_config-port_clock = 162000;
+   else
+   pipe_config-port_clock = 27;
+   }
 }
 
 static void intel_ddi_destroy(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3e66f05..681c99a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7176,6 +7176,8 @@ static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
pipe_config-pixel_multiplier;
 }
 
+#define div_ceil(A, B) ((A)/(B) + ((A)%(B) ? 1 : 0))
+
 static void ironlake_crtc_clock_get(struct intel_crtc *crtc,
struct intel_crtc_config *pipe_config)
 {
@@ -7218,7 +7220,11 @@ static void ironlake_crtc_clock_get(struct intel_crtc 
*crtc,
return;
 
clock = ((u64)link_m * (u64)link_freq * (u64)repeat);
-   do_div(clock, link_n);
+   /* This is required because the value comes out to be in fraction
+  (eg. 70699.54). Need to round it up since values are compared in
+  drm_mode_equal
+   */
+   clock = div_ceil(clock, link_n);
 
pipe_config-adjusted_mode.clock = clock;
 }
@@ -9588,6 +9594,7 @@ static void intel_init_display(struct drm_device *dev)
 
if (HAS_DDI(dev)) {
dev_priv-display.get_pipe_config = haswell_get_pipe_config;
+   dev_priv-display.get_clock = ironlake_crtc_clock_get;
dev_priv-display.crtc_mode_set = haswell_crtc_mode_set;
dev_priv-display.crtc_enable = haswell_crtc_enable;
dev_priv-display.crtc_disable = haswell_crtc_disable;
-- 
1.8.3

___
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 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 aaron...@intel.com
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 aaron...@intel.com
---
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 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 Tomasz,


On 2 August 2013 04:50, Tomasz Figa tomasz.f...@gmail.com 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 vikas.saj...@linaro.org
  Signed-off-by: Arun Kumar arun...@samsung.com
  ---
   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 drm/drm_crtc.h
   #include drm/drm_fb_helper.h
   #include drm/drm_crtc_helper.h
  +#include drm/exynos_drm.h
 
   #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
___
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

[Sachin Kamat]

Hi Vikas,

On 1 August 2013 16:49, Vikas Sajjan vikas.saj...@linaro.org 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 vikas.saj...@linaro.org
 Signed-off-by: Arun Kumar arun...@samsung.com
 ---
  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 drm/drm_crtc.h
  #include drm/drm_fb_helper.h
  #include drm/drm_crtc_helper.h
 +#include drm/exynos_drm.h

  #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
___
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

[Sachin Kamat]

Hi Vikas,

On 2 August 2013 09:23, Vikas Sajjan vikas.saj...@linaro.org wrote:
 Hi Tomasz,


 On 2 August 2013 04:50, Tomasz Figa tomasz.f...@gmail.com 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 vikas.saj...@linaro.org
  Signed-off-by: Arun Kumar arun...@samsung.com
  ---
   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 drm/drm_crtc.h
   #include drm/drm_fb_helper.h
   #include drm/drm_crtc_helper.h
  +#include drm/exynos_drm.h
 
   #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
___
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

[Dave Airlie]

On Fri, Aug 2, 2013 at 12:41 AM, Peter Wu lekenst...@gmail.com 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 lekenst...@gmail.com
 ---
  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;
 -
 -   if (obj-type == ACPI_TYPE_INTEGER)
 -   if 

Re: i915 backlight

[Felipe Contreras]

On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa jllad...@gmail.com 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
___
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

[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 robdcl...@gmail.com wrote:
  On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa tomasz.f...@gmail.com 
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 vikas.saj...@linaro.org
  Signed-off-by: Arun Kumar arun...@samsung.com
  ---
  
   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 vikas.saj...@linaro.org

 Hi Rob,

 On 2 August 2013 06:03, Rob Clark robdcl...@gmail.com wrote:
  On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa tomasz.f...@gmail.com
 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 vikas.saj...@linaro.org
  Signed-off-by: Arun Kumar arun...@samsung.com
  ---
   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 drm/drm_crtc.h
   #include drm/drm_fb_helper.h
   #include drm/drm_crtc_helper.h
  +#include drm/exynos_drm.h
 
   #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 zaj...@gmail.com
---
 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 zaj...@gmail.com
+ *
+ * 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 drm/drmP.h
+#include drm/radeon_drm.h
+#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 

[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 f.pinamart...@gmail.com ---
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 zaj...@gmail.com:
 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:
 [c1597bbb] dump_stack+0x41/0x56
 [c10392ca] warn_slowpath_common+0x7a/0xa0
 [c103936e] warn_slowpath_fmt+0x2e/0x30
 [c12dfbe8] intel_sdvo_get_config+0x158/0x160
 [c12c3220] check_crtc_state+0x1e0/0xb10
 [c12cdc7d] intel_modeset_check_state+0x29d/0x7c0
 [c12dfe5c] intel_sdvo_dpms+0x5c/0xa0
 [c12985de] drm_mode_obj_set_property_ioctl+0x40e/0x420
 [c1298625] drm_mode_connector_property_set_ioctl+0x35/0x40
 [c1289294] drm_ioctl+0x3e4/0x540
 [c10fc1a2] do_vfs_ioctl+0x72/0x570
 [c10fc72f] SyS_ioctl+0x8f/0xa0
 [c159b7fa] 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?= ville.syrj...@linux.intel.com
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 robdcl...@gmail.com
 ---
snip
 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 shawn.st...@rogers.com changed:

   What|Removed |Added

  Attachment #83469|0   |1
is obsolete||

--- Comment #72 from Shawn Starr shawn.st...@rogers.com ---
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 shawn.st...@rogers.com changed:

   What|Removed |Added

  Attachment #83470|0   |1
is obsolete||

--- Comment #73 from Shawn Starr shawn.st...@rogers.com ---
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 shawn.st...@rogers.com ---
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 zaj...@gmail.com 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 zaj...@gmail.com
 ---
  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 zaj...@gmail.com
 + *
 + * 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 drm/drmP.h
 +#include drm/radeon_drm.h
 +#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 
 

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

[Rafał Miłecki]

2013/8/2 Alex Deucher alexdeuc...@gmail.com:
 On Fri, Aug 2, 2013 at 4:11 AM, Rafał Miłecki zaj...@gmail.com 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 zaj...@gmail.com:
 2013/8/2 Alex Deucher alexdeuc...@gmail.com:
 On Fri, Aug 2, 2013 at 4:11 AM, Rafał Miłecki zaj...@gmail.com 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ä
ville.syrj...@linux.intel.com 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 robdcl...@gmail.com
 ---
 snip
 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 jllad...@gmail.com 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 zaj...@gmail.com wrote:
 2013/8/2 Alex Deucher alexdeuc...@gmail.com:
 On Fri, Aug 2, 2013 at 4:11 AM, Rafał Miłecki zaj...@gmail.com 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 shawn.st...@rogers.com ---
(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 aaron...@intel.com 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 aaron...@intel.com 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 aaron...@intel.com 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 aaron...@intel.com 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 robdcl...@gmail.com wrote:
 On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa tomasz.f...@gmail.com 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 vikas.saj...@linaro.org
 Signed-off-by: Arun Kumar arun...@samsung.com
 ---
  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 drm/drm_crtc.h
  #include drm/drm_fb_helper.h
  #include drm/drm_crtc_helper.h
 +#include drm/exynos_drm.h

  #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 lekenst...@gmail.com 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 lekenst...@gmail.com
  ---
  
   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;
  -   

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 inki@samsung.com wrote:


 2013/8/2 Vikas Sajjan vikas.saj...@linaro.org

 Hi Rob,

 On 2 August 2013 06:03, Rob Clark robdcl...@gmail.com wrote:
  On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa tomasz.f...@gmail.com
  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 vikas.saj...@linaro.org
  Signed-off-by: Arun Kumar arun...@samsung.com
  ---
   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 drm/drm_crtc.h
   #include drm/drm_fb_helper.h
   #include drm/drm_crtc_helper.h
  +#include drm/exynos_drm.h
 
   #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 *pdev = dev-platformdev;
unsigned long size;
int ret;

DRM_DEBUG_KMS(surface width(%d), height(%d) and bpp(%d\n,

[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 andriy.shevche...@linux.intel.com
---
 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 alexdeuc...@gmail.com:
 On Fri, Aug 2, 2013 at 9:40 AM, Rafał Miłecki zaj...@gmail.com wrote:
 2013/8/2 Alex Deucher alexdeuc...@gmail.com:
 On Fri, Aug 2, 2013 at 4:11 AM, Rafał Miłecki zaj...@gmail.com 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 pierre-bugzi...@ossman.eu ---
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.
 11id=dffd4b65ca8989acb914da3c685c798ca5fcf99c

I also had to apply these two:

http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11id=7d61d835824f73dc4097b51f800382467c8049c5
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11id=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
konrad.w...@oracle.com 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