lt;https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/6988c812/attachment.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/39069dca/attachment.html>
On Fri, Mar 11, 2016 at 8:09 PM, Linus Torvalds
wrote:
> On Fri, Mar 11, 2016 at 4:49 PM, Andy Lutomirski
> wrote:
>>
>> FWIW, if I disable all the checks in pci_get_rom_size, I learn that my
>> video ROM consists entirely of 0xff bytes. Maybe there just isn't a
>> ROM shadow on my laptop.
>
>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/ffc6f2fb/attachment.html>
t was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/79fb80ad/attachment.html>
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/41e55567/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/1216fb1a/attachment.html>
Hi Linus,
Just two i915 regression fixes, that should be it from me.
Dave.
The following changes since commit 2a4fb270daa9c1f1d1b86a53d66ed86cc64ad232:
Merge tag 'armsoc-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2016-03-11 12:35:54
-0800)
are available in the gi
Nicolai Hähnle wrote:
> Lutz, could you please test whether the attached patch on top of 3.14.63
> fixes the problem?
I'd tend to say it does. I am running the patched 3.14.63 since I got
the patch and so far no oops occurred, whereas without the patch it
took less than 2 hours until it oopsed.
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/141ba871/attachment.html>
This updates MAINTEINERS file with information about maintainer of
ARC PGU display controller driver.
Signed-off-by: Alexey Brodkin
Cc: linux-snps-arc at lists.infradead.org
Cc: dri-devel at lists.freedesktop.org
---
No changes v2 -> v3.
No changes v1 -> v2.
MAINTAINERS | 6 ++
1 file cha
Synopsys DesignWare ARC SDP boards sport ARC SDP display
controller attached to ADV7511 HDMI encoder.
That change adds desctiption of both ARC PGU and ADV7511 in
ARC SDP'd base-board Device Tree.
Signed-off-by: Alexey Brodkin
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
C
This add DT bindings documentation for ARC PGU display controller.
Signed-off-by: Alexey Brodkin
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: devicetree at vger.kernel.org
Cc: linux-snps-arc at li
ARC PGU could be found on some development boards from Synopsys.
This is a simple byte streamer that reads data from a framebuffer
and sends data to the single encoder.
Signed-off-by: Alexey Brodkin
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: linux-snps-arc at lists.infradead.org
This series add support of ARC PGU display controller.
ARC PGU is a quite simple byte streamer that gets data from the framebuffer
and pushes it to hte connected encoder (DP or HDMI).
It was tested on ARC SDP boards (axs101 in particular).
Changes v2 -> v3:
* Improved failure path if arcpgu_conn
On Mon, Feb 22, 2016 at 7:13 PM, Andy Lutomirski wrote:
> On Wed, Feb 17, 2016 at 5:36 PM, Andy Lutomirski
> wrote:
>> On Wed, Feb 17, 2016 at 8:18 AM, Daniel Vetter wrote:
>>> On Tue, Feb 16, 2016 at 09:26:35AM -0800, Andy Lutomirski wrote:
On Tue, Feb 16, 2016 at 9:12 AM, Andy Lutomirski
https://bugzilla.kernel.org/show_bug.cgi?id=113341
--- Comment #9 from Bernd Steinhauser ---
I will try to build llvm, but it could require me a few days since it's not yet
provided by my distribution and I have to check the changes in the build
system.
BTW, I can usually ssh into the system. Is
;
> url:
> https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160311-153649
> config: x86_64-nfsroot (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All erro
On Fri, Mar 11, 2016 at 01:16:09PM -0800, Andy Lutomirski wrote:
> On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote:
> > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
> >> The purpose of this series is to:
> >>
> >> - Fix the "BAR 6: [??? 0x flags 0x2] has bogus align
When closing the DRM device while a vblank is pending, we access
file_priv after it has been free'd, which gives:
Unable to handle kernel NULL pointer dereference at virtual address
...
PC is at __list_add+0x5c/0xe8
LR is at send_vblank_event+0x54/0x1f0
...
[] (__list_add) fro
On Fri, Mar 11, 2016 at 4:49 PM, Andy Lutomirski wrote:
>
> FWIW, if I disable all the checks in pci_get_rom_size, I learn that my
> video ROM consists entirely of 0xff bytes. Maybe there just isn't a
> ROM shadow on my laptop.
I think most laptops end up having the graphics ROM be part of the
r
On Fri, Mar 11, 2016 at 9:29 AM, Christian König
wrote:
> From: Christian König
>
> With the updated MMU notifier we should also be able to
> handle the writeback case correctly.
>
> Signed-off-by: Christian König
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 8
On Fri, Mar 11, 2016 at 3:29 PM, Bjorn Helgaas wrote:
> On Fri, Mar 11, 2016 at 01:16:09PM -0800, Andy Lutomirski wrote:
>> On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote:
>> > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
>> >> The purpose of this series is to:
>> >>
>> >>
We have allowed migration for only LRU pages until now and it was
enough to make high-order pages. But recently, embedded system(e.g.,
webOS, android) uses lots of non-movable pages(e.g., zram, GPU memory)
so we have seen several reports about troubles of small high-order
allocation. For fixing the
On Fri, 11 Mar 2016, Ville Syrjälä wrote:
> [ text/plain ]
> On Fri, Mar 11, 2016 at 03:36:48PM +0200, Jani Nikula wrote:
>> On Wed, 09 Mar 2016, ville.syrjala at linux.intel.com wrote:
>> > From: Ville Syrjälä
>> >
>> > SADs may span multiple CEA audio data blocks in the EDID.
>> >
>> > CEA-
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/74485d71/attachment.html>
Hi Minchan,
[auto build test ERROR on v4.5-rc7]
[cannot apply to next-20160310]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Minchan-Kim/Support-non-lru-page-migration/20160311-153649
On Fri, Mar 11, 2016 at 03:36:48PM +0200, Jani Nikula wrote:
> On Wed, 09 Mar 2016, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > SADs may span multiple CEA audio data blocks in the EDID.
> >
> > CEA-861-E says:
> > "The order of the Data Blocks is not constrained. It i
Hi Dave -
I first thought I'd missed the train, and by now maybe I really
have. *sigh*. Both need to be backported to v4.5 through stable if these
miss the release.
BR,
Jani.
The following changes since commit f6cede5b49e822ebc41a099fe41ab4989f64e2cb:
Linux 4.5-rc7 (2016-03-06 14:48:03 -080
Am 11.03.2016 um 15:18 schrieb Josh Poimboeuf:
> Simplify the control flow of cik_tiling_mode_table_init() similar to how
> it was done in gfx_v7_0.c and gfx_v8_0.c.
>
> Signed-off-by: Josh Poimboeuf
I'm not so deep into the tilling config stuff, but briefly skimming over
it it clearly looks goo
From: Christian König
We somehow forgot the flags paramter in amdgpu_create_bo_from_user_mem(). Fix
that with a new function.
Signed-off-by: Christian König
---
amdgpu/amdgpu.h| 8
amdgpu/amdgpu_bo.c | 26 ++
2 files changed, 26 insertions(+), 8 deletion
On Wed, 09 Mar 2016, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä
>
> SADs may span multiple CEA audio data blocks in the EDID.
>
> CEA-861-E says:
> "The order of the Data Blocks is not constrained. It is also possible
> to have more than one of a specific type of data block if
From: Christian König
With the updated MMU notifier we should also be able to
handle the writeback case correctly.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/3df3cbd9/attachment.html>
On Friday, March 11, 2016 12:58:15 PM Mika Westerberg wrote:
> On Thu, Mar 10, 2016 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
> > > It doesn't seem to do any runtime PM,
> > > I do wonder if pcieport should be doing it's own runtime PM handling,
> > > but that is a
> > > larger task than I'm th
Hi Lionel Landwerlin,
The patch 562c5b4d8986: "drm: fix blob pointer check" from Mar 10,
2016, has a problem.
drivers/gpu/drm/drm_atomic_helper.c
2924 blob = drm_property_create_blob(dev,
2925 sizeof(struct drm_color_lut) *
size,
2926
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/f5a7d010/attachment.html>
On Thu, Mar 03, 2016 at 07:42:43PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Burn the old opcode to avoid any potential old userspace running the old
> API to get weird errors. Changing the opcodes will make them fail right
> away.
>
> This is just a precaution, there no upstream
On Fri, Mar 04, 2016 at 05:40:29PM +0100, Daniel Vetter wrote:
> On Thu, Mar 03, 2016 at 08:17:14AM -0800, Greg Kroah-Hartman wrote:
> > On Thu, Mar 03, 2016 at 11:37:17AM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Play safe and add flags member to all structs. So we do
On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote:
> On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
>> The purpose of this series is to:
>>
>> - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment"
>> messages reported by Linus [1], Andy [2], and others.
>>
>>
Hey
On Fri, Mar 11, 2016 at 12:52 PM, Lionel Landwerlin
wrote:
> Thanks a lot for pointing this out. I saw you previous comment but didn't
> realize the issue.
> I'll set the pointer to NULL.
>
> I don't if there is an agreement on this, but do you think the unref/free
> functions should check fo
On Thu, Mar 10, 2016 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
> > It doesn't seem to do any runtime PM,
> > I do wonder if pcieport should be doing it's own runtime PM handling,
> > but that is a
> > larger task than I'm thinking to tackle here.
>
> PCIe ports don't do PM - yet. Mika has pos
562c5b4d8986 didn't quite fix the issue of dealing with an error
pointer. We can't free/unref an error pointer so reset it to NULL.
Many thanks to Dan Carpenter for pointing this out again.
Signed-off-by: Lionel Landwerlin
Cc: Dan Carpenter
Cc: Daniel Stone
Cc: Daniel Vetter
Cc: Matt Roper
C
Hi Dan,
Thanks a lot for pointing this out. I saw you previous comment but
didn't realize the issue.
I'll set the pointer to NULL.
I don't if there is an agreement on this, but do you think the
unref/free functions should check for error pointers?
-
Lionel
On 11/03/16 11:39, Dan Carpenter wro
For whatever reason, I've found that some laptops aren't immediately
capable of doing aux transactions with their docks when they come out of
standby. While I'm still not entirely sure what the cause of this is,
sleeping for 30ms and then retrying drm_dp_mst_topology_mgr_resume()
should be a suffic
Since we need MST devices ready before we try to resume displays,
calling this after intel_display_resume() can result in some issues with
various laptop docks where the monitor won't turn back on after
suspending the system.
This order was originally changed in
commit e7d6f7d70829 ("drm/
This is a follow-up to the original patches I sent to try to fix the issue of
drm_dp_mst_topology_mgr_resume() not working due to aux transactions failing
temporarily after resuming the machine. Unfortunately I haven't been able to
figure out the actual cause of this issue; there don't seem to be a
At the end of the function we expect "status" to be zero, but it's
either -EINVAL or unitialized.
Fixes: 788bf83db301 ('drm/amdkfd: Add wave control operation to debugger')
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
b/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.
iving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/156c6d88/attachment.html>
tainly not the same problem. Please
stop mixing up the two issues.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/2016
ng this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/07e00621/attachment.html>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/0cda1e54/attachment.html>
Simplify the control flow of si_tiling_mode_table_init() similar to how
it was done in gfx_v7_0.c and gfx_v8_0.c.
Signed-off-by: Josh Poimboeuf
---
drivers/gpu/drm/radeon/si.c | 925 +---
1 file changed, 439 insertions(+), 486 deletions(-)
diff --git a/dr
Simplify the control flow of cik_tiling_mode_table_init() similar to how
it was done in gfx_v7_0.c and gfx_v8_0.c.
Signed-off-by: Josh Poimboeuf
---
drivers/gpu/drm/radeon/cik.c | 1691 +-
1 file changed, 666 insertions(+), 1025 deletions(-)
diff --git a/
attachments/20160311/3fd13723/attachment.html>
are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/e5eaaa18/attachment-0001.html>
ail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/8a06ec0a/attachment.html>
ubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/2caf8db7/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/2b28e748/attachment.html>
|blocker
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160311/f07d3cd3/attachment.html>
60 matches
Mail list logo
