https://bugs.freedesktop.org/show_bug.cgi?id=69694
--- Comment #10 from Marco ---
Thinking on it twice and rebuilding new mesa from git I remember I had this
notification during build:
undefined symbol: _glapi_tls_Context
I will look into configure flags of both mesa and xserver (--enable-glx-tl
https://bugs.freedesktop.org/show_bug.cgi?id=69689
--- Comment #2 from Johannes Jordan ---
Thank you for your reply. The configure option --enable-texture-float is set.
See:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mesa
--
You are receiving this mail b
Please, ignore this patch. This patch has still some problems. I will post
it later.
Thanks,
Inki Dae
> -Original Message-
> From: Inki Dae [mailto:inki@samsung.com]
> Sent: Monday, September 23, 2013 7:43 PM
> To: airl...@linux.ie; dri-devel@lists.freedesktop.org
> Cc: Inki Dae; Kyun
Thanks for your comment.
> -Original Message-
> From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
> Sent: Monday, September 23, 2013 10:07 PM
> To: Inki Dae
> Cc: 'YoungJun Cho'; dri-devel@lists.freedesktop.org
> Subject: Re: [RFC] deadlock in "drm/exynos: fix wrong pointer
https://bugs.freedesktop.org/show_bug.cgi?id=69728
--- Comment #4 from pablow.1...@gmail.com ---
Created attachment 86426
--> https://bugs.freedesktop.org/attachment.cgi?id=86426&action=edit
This is another dmesg log
...but this one if from a lockup which I could recover from, switching to a tt
https://bugs.freedesktop.org/show_bug.cgi?id=69728
--- Comment #3 from pablow.1...@gmail.com ---
Already tried that. It doesn't help.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.f
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #14 from Paul Bodenbenner ---
Tried to undo commit e6e792092e816bea0797995c886fb057c91d4546 from version
3.11.1 and the result seems ok for me. To be sure I attached the resulting
file.
Unfortunately by using this file that didn't mak
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #13 from Paul Bodenbenner ---
Created attachment 86425
--> https://bugs.freedesktop.org/attachment.cgi?id=86425&action=edit
drm_edid.c
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=69723
--- Comment #1 from Alex Deucher ---
Created attachment 86424
--> https://bugs.freedesktop.org/attachment.cgi?id=86424&action=edit
disable various dpm features
Try this patch and see if you can narrow down which, if any, of these features
is p
On Wed, Aug 14, 2013 at 11:07 PM, David Herrmann wrote:
> There is no reason to keep the gem object separately allocated. nouveau is
> the last user of gem_obj->driver_private, so if we embed it, we can get
> rid of 8bytes per gem-object.
>
> The implementation follows the radeon driver. bo->gem i
https://bugs.freedesktop.org/show_bug.cgi?id=69721
Alexandre Demers changed:
What|Removed |Added
Summary|Can't reach maximum memory |Can't reach maximum memory
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #12 from Alex Deucher ---
Does reverting e6e792092e816bea0797995c886fb057c91d4546 fix the playback?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #11 from Paul Bodenbenner ---
Thank you very much for your fast answering (again).
I patched it against kernel 3.11.1 and now I can hear some sound. Unfortunately
it will be played very fast, so the voice is very "high".
I tried diffe
https://bugs.freedesktop.org/show_bug.cgi?id=69694
--- Comment #9 from Marco ---
But unfortunatly, commenting glx module doesn't solve my problem.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri
https://bugs.freedesktop.org/show_bug.cgi?id=69728
Alex Deucher changed:
What|Removed |Added
Product|DRI |Mesa
Version|XOrg CVS
https://bugs.freedesktop.org/show_bug.cgi?id=69728
--- Comment #2 from Alex Deucher ---
Does disabling hyperZ help? E.g., set env var:
R600_DEBUG=nohyperz
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing
https://bugzilla.kernel.org/show_bug.cgi?id=61941
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #3 from
https://bugs.freedesktop.org/show_bug.cgi?id=69694
--- Comment #8 from Marco ---
Looks terribly similar to:
https://bugs.freedesktop.org/show_bug.cgi?id=69682
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mail
https://bugzilla.kernel.org/show_bug.cgi?id=61941
--- Comment #1 from Ilya Tumaykin ---
Created attachment 109321
--> https://bugzilla.kernel.org/attachment.cgi?id=109321&action=edit
dmesg after lockup
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=61941
--- Comment #2 from Ilya Tumaykin ---
Created attachment 109331
--> https://bugzilla.kernel.org/attachment.cgi?id=109331&action=edit
another dmesg after lockup
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=61941
Bug ID: 61941
Summary: Random GPU lockups/resets on Mobility Radeon HD 3650
with radeon.dpm=1
Product: Drivers
Version: 2.5
Kernel Version: >=3.11.0
Hardware: All
> That looks quite strange. I guess the kernel should map the ROM at the
> address OpenBoot/OF assigned to it. ( 1002 ).
DaveM already explained about the phys/virt mapping.
> Are pci devices located beneatch pci@1f,0 not reserving resources
> correctly ? (Thus the reuse of addresses when the
> > That looks quite strange. I guess the kernel should map the ROM at the
> > address OpenBoot/OF assigned to it. ( 1002 ).
>
> The address you see is a raw physical I/O address, which is a concatenation
> of the I/O window physical address for that PCI controller and the
> PCI bus assigned a
https://bugs.freedesktop.org/show_bug.cgi?id=69694
--- Comment #7 from Marco ---
Created attachment 86423
--> https://bugs.freedesktop.org/attachment.cgi?id=86423&action=edit
Gdb trace whe uncommenting glamoregl
Uncommenting "glamoregl" in the working xorg.conf lead to crash described in
the g
https://bugs.freedesktop.org/show_bug.cgi?id=69694
--- Comment #6 from Marco ---
Created attachment 86422
--> https://bugs.freedesktop.org/attachment.cgi?id=86422&action=edit
xorg.conf working (lead to llvmpipe render)
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=69694
--- Comment #5 from Marco ---
Removing xorg.conf leads to the same crash (trace is very similar).
Then I tried with this little xorg.conf (to load glamoregl)
Section "Module"
Load "dri2"
Load "glamoregl"
Load "glx"
EndSection
bu
https://bugs.freedesktop.org/show_bug.cgi?id=69341
--- Comment #9 from darkbasic ---
It goes to 100% with native backend, at least on SI.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@li
On Sat, Sep 21, 2013 at 07:39:10AM +0400, Alex Ivanov wrote:
> 21.09.2013, в 1:27, Alex Deucher написал(а):
>
> > On Tue, Sep 17, 2013 at 3:33 PM, Alex Ivanov wrote:
> >> 17.09.2013, в 18:24, Alex Deucher написал(а):
> >>
> >>> On Tue, Sep 17, 2013 at 5:23 AM, Alex Ivanov wrote:
> Alex,
https://bugs.freedesktop.org/show_bug.cgi?id=69341
--- Comment #8 from Denis M. (Phr33d0m) ---
(In reply to comment #7)
> Yes that's the same corruption I have with the native backend. I suggest you
> to have a look at top: native isn't slow, but aftware a few minutes the X
> process starts eatin
When dpm was merged, I added a new asic struct for
rv6xx, but it never got properly updated when the
hdmi callbacks were added due to the two patch sets
being developed in parallel.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=69729
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
-
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #10 from Alex Deucher ---
Created attachment 86417
--> https://bugs.freedesktop.org/attachment.cgi?id=86417&action=edit
possible fix
This patch should fix it.
--
You are receiving this mail because:
You are the assignee for the b
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #8 from Paul Bodenbenner ---
I am not using any of those modes...
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freed
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #9 from Alex Deucher ---
Nevermind, I found the problem. Patch forthcoming.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #7 from Alex Deucher ---
Possibly a duplicate of bug 69675. Does reverting
e6e792092e816bea0797995c886fb057c91d4546 fix it?
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #6 from Paul Bodenbenner ---
Created attachment 86414
--> https://bugs.freedesktop.org/attachment.cgi?id=86414&action=edit
dmesg_3_11_1
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #5 from Paul Bodenbenner ---
Created attachment 86413
--> https://bugs.freedesktop.org/attachment.cgi?id=86413&action=edit
dmesg_3_10_10
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #4 from Paul Bodenbenner ---
Created attachment 86412
--> https://bugs.freedesktop.org/attachment.cgi?id=86412&action=edit
avivotool_regs_hdmi_3_11_1
--
You are receiving this mail because:
You are the assignee for the bug.
__
On Mon, Sep 23, 2013 at 03:57:40PM +0100, Damien Lespiau wrote:
> Some stereo modes, like frame packing, need a larger CRTC viewport than
> the "natural" underlying 2D mode and thus drm_crtc_check_viewport()
> needs to query the adjusted mode to use the correct h/vdisplay.
>
> Signed-off-by: Damie
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #3 from Paul Bodenbenner ---
Created attachment 86411
--> https://bugs.freedesktop.org/attachment.cgi?id=86411&action=edit
avivotool_regs_hdmi_3_10_10
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #2 from Paul Bodenbenner ---
Created attachment 86410
--> https://bugs.freedesktop.org/attachment.cgi?id=86410&action=edit
Xorg.0.log_3_11_1
--
You are receiving this mail because:
You are the assignee for the bug.
___
[+cc linux-pci, linux-kernel, dri-devel]
On Sat, Sep 21, 2013 at 11:39 AM, wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=61811
>
> Bug ID: 61811
>Summary: kms mode breaks and using radeon.agpmode=-1
>Product: Drivers
>Version: 2.5
> Kern
https://bugs.freedesktop.org/show_bug.cgi?id=69728
Priority: medium
Bug ID: 69728
Assignee: dri-devel@lists.freedesktop.org
Summary: Radeon Redwood (5670) GPU Lockup
Severity: normal
Classification: Unclassified
OS: Linux (Al
https://bugs.freedesktop.org/show_bug.cgi?id=69728
--- Comment #1 from pablow.1...@gmail.com ---
Created attachment 86405
--> https://bugs.freedesktop.org/attachment.cgi?id=86405&action=edit
another journalctl log
--
You are receiving this mail because:
You are the assignee for the bug.
__
On Thu, Sep 19, 2013 at 9:21 AM, Emil Velikov wrote:
> Documentation states that AC_*_IFELSE has to use AC_LANG_SOURCE or
> friends in order to generate the source code to compile.
> AC_LINK_IFELSE already handles this, thus convert AC_COMPILE_IFELSE
> to silence the final autoconf warnings.
>
> S
https://bugs.freedesktop.org/show_bug.cgi?id=69729
--- Comment #1 from Paul Bodenbenner ---
Created attachment 86409
--> https://bugs.freedesktop.org/attachment.cgi?id=86409&action=edit
Xorg.0.log_3_10_10
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=69729
Priority: medium
Bug ID: 69729
Assignee: dri-devel@lists.freedesktop.org
Summary: HDMI audio stopped working on HD 3470 (RV620/M82)
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=69721
--- Comment #1 from Alexandre Demers ---
That is with kernel 3.11.0 or 3.12-rc1 with the two patches proposed in bug
68235.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=68235
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
> On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
>> On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra
>> wrote:
>>> On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas Hellstrom wrote:
>> if (!bo_tryreserve()) {
>> up_read m
https://bugs.freedesktop.org/show_bug.cgi?id=69723
Priority: medium
Bug ID: 69723
Assignee: dri-devel@lists.freedesktop.org
Summary: Computer freezes with kernel 3.11.0 / 3.12-rc1 (with
bug 68235's patches applied) when dpm=1 on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=64810
--- Comment #29 from Rafael Castillo ---
I have a working memory saving patch but I am not authorised to publish it.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-d
https://bugs.freedesktop.org/show_bug.cgi?id=69721
Alexandre Demers changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=69721
Priority: medium
Bug ID: 69721
Assignee: dri-devel@lists.freedesktop.org
Summary: Can't reach maximum memory speed (or core speed) when
using dpm=1 on r600g
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=69341
--- Comment #7 from darkbasic ---
Yes that's the same corruption I have with the native backend. I suggest you to
have a look at top: native isn't slow, but aftware a few minutes the X process
starts eating the CPU ,that's the reason ;)
On the co
When using the frame packing and a single big framebuffer, some hardware
requires that we do everything like if we were scanning out the big
buffer itself. Let's instrument drm_mode_set_crtcinfo() to be able to do
this adjustement if the driver is asking for it.
v2: Use crtc_vtotal and multiply th
Some stereo modes, like frame packing, need a larger CRTC viewport than
the "natural" underlying 2D mode and thus drm_crtc_check_viewport()
needs to query the adjusted mode to use the correct h/vdisplay.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 8
1 file changed, 8
Both setcrtc and page_flip are checking that the framebuffer is big
enough for the defined crtc viewport (x, y, hdisplay, vdisplay). Factor
that code out in a single function.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc.c | 70 --
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=69341
--- Comment #6 from Denis M. (Phr33d0m) ---
Created attachment 86376
--> https://bugs.freedesktop.org/attachment.cgi?id=86376&action=edit
color-corruption.png
I also have this color corruption all over the place with Native/OpenGL backend
and
On Mon, Sep 23, 2013 at 7:59 AM, Alex Ivanov wrote:
> P.S.: don't run means don't allow to run, by either feeding radeon.test=X
> or radeon.benchmark=1
Good catch. I applied a slightly different variant of the same idea.
Thanks,
Alex
>
> 22.09.2013, в 5:18, Alex Ivanov написал(а):
>
>> 20.09
I've sent this 2 patches separately from the main stereo series so we can have
the usual rounds of review without having to resend the full 20+ patches. Once
that last bit has been reviewed as well, I'll send a consolidated series that
will be a serious candidate for merging.
--
Damien
_
On Mon, Sep 23, 2013 at 3:42 AM, Christian König
wrote:
> From: Christian König
>
> Starting with UVD3 message and feedback buffers have their
> own 256MB segment, so no need to force them into VRAM any more.
>
> Signed-off-by: Christian König
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/r
https://bugs.freedesktop.org/show_bug.cgi?id=69694
--- Comment #4 from Alex Deucher ---
Can you try removing your xorg.conf?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedeskt
https://bugs.freedesktop.org/show_bug.cgi?id=68235
--- Comment #50 from Alex Deucher ---
Go ahead and open new bugs for those issues.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.
https://bugs.freedesktop.org/show_bug.cgi?id=69689
--- Comment #1 from Alex Deucher ---
Make sure you set --enable-texture-float when configuring mesa.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing lis
Resurrecting an old thread...
> On Fri, Sep 7, 2012 at 4:18 AM, David Miller wrote:
> > From: Michel Dänzer
> > Date: Thu, 06 Sep 2012 18:55:51 +0200
> >
> >> On Don, 2012-09-06 at 17:41 +0300, Meelis Roos wrote:
> >>> This is with initialyy unmodified 3.6.0-rc4-00101-g0809095 kernel in
> >>> Ul
drm_helper_probe_single_connector_modes() can be used to implement
->fill_modes(), not ->probe().
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm
On Mon, Sep 23, 2013 at 04:49:30PM +0900, Inki Dae wrote:
> Hi,
>
> > -Original Message-
> > From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
> > Sent: Monday, September 23, 2013 6:29 AM
> > To: YoungJun Cho
> > Cc: dri-devel@lists.freedesktop.org; Inki Dae
> > Subject: [R
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
> On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> > register_platform_device_full() can setup the DMA mask provided the
> > appropriate member is set in struct platform_device_info. So lets
> > make that be the case. This
On Sat, Sep 21, 2013 at 09:00:00PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> > Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > > The DMA API requires drivers to call the appropriate dma_set_mask()
> > > functions
On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> register_platform_device_full() can setup the DMA mask provided the
> appropriate member is set in struct platform_device_info. So lets
> make that be the case. This avoids a direct reference to the DMA
> masks by this driver.
>
> S
On Thu, Sep 19, 2013 at 10:48:01PM +0100, Russell King wrote:
> The DMA API requires drivers to call the appropriate dma_set_mask()
> functions before doing any DMA mapping. Add this required call to
> the AMBA PL08x driver.
>
> Signed-off-by: Russell King
Acked-by: Vinod Koul
~Vinod
> ---
>
P.S.: don't run means don't allow to run, by either feeding radeon.test=X
or radeon.benchmark=1
22.09.2013, в 5:18, Alex Ivanov написал(а):
> 20.09.2013, в 22:33, Alex Deucher написал(а):
>
>> On Fri, Sep 20, 2013 at 9:36 AM, Alex Ivanov wrote:
>>> Prevent NULL pointer dereference in case whe
This patch fixes the deadlock issue when another process requested
mmap system call.
This issue can incur the deadlock if another process sharing the same
file called mmap system call between ->f_op pointer chaning and restoring.
So this patch calls down_write(&mm->mmap_sem) before do_mmap_pgoff
On Sat, Sep 21, 2013 at 12:07:36AM +0200, Mario Kleiner wrote:
> On 09/17/2013 10:55 PM, Daniel Vetter wrote:
> > On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley
> > wrote:
> >> On 09/11/2013 03:31 PM, Peter Hurley wrote:
> >>>
> >>> [+cc dri-devel]
> >>>
> >>> On 09/11/2013 11:38 AM, Steven Rosted
Ping?
On Mon, Sep 02, 2013 at 03:50:57PM +0100, Russell King - ARM Linux wrote:
> On Wed, Aug 14, 2013 at 09:43:30PM +0200, Sebastian Hesselbarth wrote:
> > From: Russell King
> >
> > This patch adds tda998x specific parameters to allow it to be configured
> > for different boards using it. Also
You have drm_dev->struct_mutex grabbed before ->mmap_sem in
exynos_drm_gem_mmap_ioctl() and after - in exynos_drm_gem_fault()
(since ->fault() is always called with ->mmap_sem held). Looks like
a garden-variety AB-BA deadlock...
Incidentally, what should happen if another process
On Mon, Aug 26, 2013 at 04:05:11PM +0300, Michael S. Tsirkin wrote:
> On Wed, Aug 21, 2013 at 11:22:58AM +0200, Sedat Dilek wrote:
> > [ Re: [Intel-gfx] i915 producing warnings with kernel 3.11-rc5 ]
> >
> > Hi,
> >
> > saw your posting in [1]... can you try the patches below?
> > Not sure if the
On Thu, 19 Sep 2013 22:47:01 +0100, Russell King
wrote:
> AMBA Primecell devices always treat streaming and coherent DMA exactly
> the same, so there's no point in having the masks separated.
>
> Signed-off-by: Russell King
for the drivers/of/platform.c portion:
Acked-by: Grant Likely
g.
___
On Sun, 2013-09-22 at 17:10 +0800, Aaron Lu wrote:
> On 09/18/2013 08:36 PM, Igor Gnatenko wrote:
> > On Wed, 2013-09-18 at 20:31 +0800, Aaron Lu wrote:
> >> On 09/18/2013 02:30 PM, Igor Gnatenko wrote:
> >>> On Wed, 2013-09-18 at 09:03 +0800, Aaron Lu wrote:
> On 09/17/2013 09:34 PM, Igor Gna
On 09/18/2013 08:36 PM, Igor Gnatenko wrote:
> On Wed, 2013-09-18 at 20:31 +0800, Aaron Lu wrote:
>> On 09/18/2013 02:30 PM, Igor Gnatenko wrote:
>>> On Wed, 2013-09-18 at 09:03 +0800, Aaron Lu wrote:
On 09/17/2013 09:34 PM, Igor Gnatenko wrote:
>
> Aaron, how about fix indicator on Th
On 09/20/2013 04:36 PM, Jani Nikula wrote:
> On Tue, 17 Sep 2013, Aaron Lu wrote:
>> According to Matthew Garrett, "Windows 8 leaves backlight control up
>> to individual graphics drivers rather than making ACPI calls itself.
>> There's plenty of evidence to suggest that the Intel driver for
>> Wi
On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > The DMA API requires drivers to call the appropriate dma_set_mask()
> > functions before doing any DMA mapping. Add this required call to
> > the AMBA PL08x driver
On 09/17/2013 10:55 PM, Daniel Vetter wrote:
On Tue, Sep 17, 2013 at 9:50 PM, Peter Hurley wrote:
On 09/11/2013 03:31 PM, Peter Hurley wrote:
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
The funny part is, there's a
Hey,
On Fri, Sep 20, 2013 at 03:00:18PM +0100, Russell King - ARM Linux wrote:
> Another would be if subsystem maintainers are happy that I carry them,
> I can add the acks, and then later on towards the end of the cycle,
> provide a branch subsystem maintainers could pull.
>
> Or... if you can t
On Thu, 2013-09-19 at 22:32 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
> !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
> pci_using_dac = 1;
> } else {
>
On Thu, 2013-09-19 at 22:31 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
> !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
> pci_using_dac = 1;
> } else {
>
On Thu, 2013-09-19 at 22:30 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
>
On Thu, 2013-09-19 at 22:29 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
>
On Thu, 2013-09-19 at 22:28 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
>
On Thu, 2013-09-19 at 22:27 +0100, Russell King wrote:
> The fallback to 32-bit DMA mask is rather odd:
> err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
> if (!err) {
> err = dma_set_coherent_mask(&pdev->dev,
> DMA_BIT_MASK(64));
> if (!err)
>
On Thu, 2013-09-19 at 22:37 +0100, Russell King wrote:
> Replace the following sequence:
>
> dma_set_mask(dev, mask);
> dma_set_coherent_mask(dev, mask);
>
> with a call to the new helper dma_set_mask_and_coherent().
>
> Signed-off-by: Russell King
> ---
> drivers/net/ethernet/
On Thu, Sep 19, 2013 at 10:53:02PM +0100, Russell King wrote:
> This code sequence is unsafe in modules:
>
> static u64 mask = DMA_BIT_MASK(something);
> ...
> if (!dev->dma_mask)
> dev->dma_mask = &mask;
Acked-by: Mark Brown
signature.asc
Description: Digital signature
___
Hi,
On Fri, Sep 20, 2013 at 02:49:38PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > > Use platform_device_register_full() for those drivers which can, to
> >
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King
---
arch/powerpc/kernel/vio.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --g
Replace the following sequence:
dma_set_mask(dev, mask);
dma_set_coherent_mask(dev, mask);
with a call to the new helper dma_set_mask_and_coherent().
Signed-off-by: Russell King
---
drivers/net/wireless/b43/dma.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
Signed-off-by: Russell King
---
drivers/dma/amba-pl08x.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/driv
Don't statically allocate struct device's in modules, and shut the
warning up with an empty release() function. There's a reason that
warning is there and that's not for people to hide in this way. It's
there to persuade people to use the correct APIs to allocate platform
devices.
Signed-off-by:
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
> On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> [...]
> > -dma_set_coherent_mask() will always be able to set the same or a
> > -smaller mask as dma_set_mask(). However for the rare case that a
> > +The coherent coherent mask
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only ar
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > Use platform_device_register_full() for those drivers which can, to
> > avoid messing directly with DMA masks. This can only be done when
> > the driver does n
1 - 100 of 158 matches
Mail list logo
