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-l
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
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/rad
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
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"
EndSe
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
offs
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
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
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/
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/ma
https://bugs.freedesktop.org/show_bug.cgi?id=66963
Shawn Starr changed:
What|Removed |Added
Attachment #83469|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=66963
Shawn Starr changed:
What|Removed |Added
Attachment #83470|0 |1
is obsolete|
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.
_
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 internal
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 actuall
2013/8/2 Rafał Miłecki :
> 2013/8/2 Alex Deucher :
>> On Fri, Aug 2, 2013 at 4:11 AM, Rafał Miłecki wrote:
>>> It doesn't allow playing anything yet, but was the most tricky part to
>>> RE (it's indirect access, so couldn't trace it by dumping registers).
>>> Now we just need to implement support
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
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=\
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 ju
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 adjustin
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 kerne
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
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_swi
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
vid
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,
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
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:
>> >
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
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 dum
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
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
referen
On Fri, Aug 2, 2013 at 11:16 AM, Konrad Rzeszutek Wilk
wrote:
> Hey Alex,
>
> Your recent patch "31f731a drm/radeon/dpm: fix calculations in
> si_calculate_leakage_for_v_and_t_formula" causes a build regression:
>
> drivers/built-in.o: In function `si_calculate_leakage_for_v_and_t_formula':
> /hom
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 p
https://bugs.freedesktop.org/show_bug.cgi?id=66384
--- Comment #2 from Michel Dänzer ---
Created attachment 83546
--> https://bugs.freedesktop.org/attachment.cgi?id=83546&action=edit
Attempt at making DRI2 MSC counter consistent between CRTCs
Here's an attempt at making the DRI2 MSC counter pe
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 Sh
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 "1920x10
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 "
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 d
The fix is already queued in my tree:
http://lists.freedesktop.org/archives/dri-devel/2013-August/042668.html
> -Original Message-
> From: Kyle McMartin [mailto:kmcma...@redhat.com]
> Sent: Friday, August 02, 2013 1:13 PM
> To: jgli...@redhat.com
> Cc: Deucher, Alexander; airl...@redhat.c
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
On Fri, Aug 02, 2013 at 05:14:52PM +, Deucher, Alexander wrote:
> The fix is already queued in my tree:
> http://lists.freedesktop.org/archives/dri-devel/2013-August/042668.html
>
thanks. ;-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.or
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.
_
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
https://bugzilla.kernel.org/show_bug.cgi?id=59761
--- Comment #3 from t3s...@mail.ru ---
Btw, looks like in MESA 9.2 GPU lockup bug which provokes this problem has gone
(congrats to MESA people on killing it!). Though I can still re-test kernel
handling of GPU reset by using older MESA :).
--
Yo
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 paramet
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
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 y
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
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="!Wi
On Friday, August 02, 2013 01:58:55 PM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki wrote:
> > On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
> >> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa wrote:
> >> > Hello,
> >> >
> >> > I am using a Lenovo
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
https://bugs.freedesktop.org/show_bug.cgi?id=67690
Priority: medium
Bug ID: 67690
Assignee: dri-devel@lists.freedesktop.org
Summary: Segfault when starting Xorg with radeonsi
Severity: major
Classification: Unclassified
OS: L
https://bugs.freedesktop.org/show_bug.cgi?id=67110
--- Comment #2 from Vladimir Ysikov ---
I rebuild mesa, libdrm and libtxc_dxtn with debugging symbols.
#0 0x08112d87 in ?? ()
#1 0x080d7457 in ?? ()
#2 0x080d836b in ?? ()
#3 0x080ca74b in ?? ()
#4 0x08092f40 in ?? ()
#5 0x0815929f in ?? (
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #76 from 720 ---
(In reply to comment #68)
> In the short term until we sort out why the battery state causes resume
> problems, you can select balanced or performance state in your suspend
> script.
A bit of a git noob question: How
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 all
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
>
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 re
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.
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 enab
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 buffer
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
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-l
uy 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>
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/rad
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>
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"
EndSe
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
offs
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
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
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/
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/ma
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130802/52a00631/attachment-0001.html>
:
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>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130802/74e51f88/attachment.html>
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 internal
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 actuall
2013/8/2 Rafa? Mi?ecki :
> 2013/8/2 Alex Deucher :
>> On Fri, Aug 2, 2013 at 4:11 AM, Rafa? Mi?ecki wrote:
>>> It doesn't allow playing anything yet, but was the most tricky part to
>>> RE (it's indirect access, so couldn't trace it by dumping registers).
>>> Now we just need to implement support
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
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=\
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 ju
ocking 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/attachmen
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 kerne
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_swi
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
vid
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,
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
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
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:
>> >
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
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 dum
rchives/dri-devel/attachments/20130802/eedcc860/attachment.html>
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
referen
On Fri, Aug 2, 2013 at 11:16 AM, Konrad Rzeszutek Wilk
wrote:
> Hey Alex,
>
> Your recent patch "31f731a drm/radeon/dpm: fix calculations in
> si_calculate_leakage_for_v_and_t_formula" causes a build regression:
>
> drivers/built-in.o: In function `si_calculate_leakage_for_v_and_t_formula':
> /hom
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>
ists.freedesktop.org/archives/dri-devel/attachments/20130802/f3b15ccd/attachment.html>
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 Sh
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 d
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>
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 "
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
1 - 100 of 113 matches
Mail list logo
