On 14 November 2017 at 09:12, Noralf Trønnes wrote:
> The introduction of: drm/framebuffer: Add framebuffer debugfs file
> broke vgem. That patch assumed that all drivers had initialized the
> dev->mode_config.fb_lock mutex which happens in drm_mode_config_init().
> vgem doesn't need to call drm_m
The code seems to assume that of_fdt_unflatten_tree() sets "overlay" to
NULL on error but actually it could be uninitialized.
Fixes: 4e7221580223 ("drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for
ti,tilcdc,slave binding support")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/tilcdc/tilc
We cap the upper bound of "fbnum" but we also need to check for
negatives or make the type unsigned.
Signed-off-by: Dan Carpenter
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
index 1d7c012f09db..e08e5664e330 100644
--- a/drivers/vi
On 26 October 2017 at 11:37, Inki Dae wrote:
> Hi Dave,
>
>Improving Exynos DRM HDMI and Mixer drivers and also adding
>HDMI audio support.
>
>Please kindly let me know if there is any problem.
>
>Ps. we are reviewing IPP v2 driver[1] which controls post processor devices
>
On 11/14/2017 02:33 AM, Eric Anholt wrote:
Lothar Waßmann writes:
Hi,
On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote:
Lothar Waßmann writes:
Hi,
drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
dysfunctional due to:
|commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
|Autho
Hi Liviu,
On Monday, 13 November 2017 13:53:14 EET Liviu Dudau wrote:
> On Mon, Nov 13, 2017 at 12:32:28PM +0200, Laurent Pinchart wrote:
> > When the DU sources its frames from a VSP, it performs no memory access
> > and thus has no requirements on imported dma-buf memory types. In
> > particular
On 2017年11月13日 17:54, Christian König wrote:
Deleted BOs with the same reservation object can be reaped even if they
can't be reserved.
v2: rebase and we still need to remove/add the BO from/to the LRU.
v3: fix remove/add one more time, cleanup the logic a bit
v4: we should still check if the
tree: git://people.freedesktop.org/~agd5f/linux.git
upstream-4.14-drm-next-amd-dc-staging-chrome
head: 4448b9a68413462529d018050cd246bc33957bd6
commit: a9aa2210cd8aadeea91c845a0a05510d2a91ffa6 [1/16] FORKLIFT: amd: copy amd
folder as is from dave airlie tree
config: arm64-allyesconfig (attach
https://bugs.freedesktop.org/show_bug.cgi?id=103726
Bug ID: 103726
Summary: GPU crashes freezing the system and weird rendering
issues on CAYMAN
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Stefan Schake writes:
> Synchronously disable the IRQ to make the following cancel_work_sync
> invocation effective.
>
> An interrupt in flight could enqueue further overflow mem work. As we
> free the binner BO immediately following vc4_irq_uninstall this caused
> a NULL pointer dereference in t
https://bugs.freedesktop.org/show_bug.cgi?id=101978
--- Comment #7 from higu...@gmx.net ---
>Also, there are amdgpu kernel driver changes lined up for 4.14 that might help.
Updates to 4.14 and i fail to see any improvement, sclk is still low,
performance is still very low for what this card is ca
tree: git://people.freedesktop.org/~agd5f/linux.git
upstream-4.14-drm-next-amd-dc-staging-chrome
head: 4448b9a68413462529d018050cd246bc33957bd6
commit: a9aa2210cd8aadeea91c845a0a05510d2a91ffa6 [1/16] FORKLIFT: amd: copy amd
folder as is from dave airlie tree
config: x86_64-randconfig-g0-11140
https://bugs.freedesktop.org/show_bug.cgi?id=99801
Matthew Treinish changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=99801
Matthew Treinish changed:
What|Removed |Added
Attachment #129571|0 |1
is obsolete|
Stefan Schake writes:
> The overflow mem work callback vc4_overflow_mem_work reenables its
> associated interrupt upon completion. To ensure all interrupts are disabled
> when we return from vc4_irq_uninstall, we need to disable it again if
> cancel_work_sync indicated pending work.
Is there a r
2017년 11월 13일 23:28에 Marek Szyprowski 이(가) 쓴 글:
> Hi Inki,
>
> On 2017-11-13 02:24, Inki Dae wrote:
>> Hi Marek,
>>
>> 2017년 11월 10일 16:35에 Marek Szyprowski 이(가) 쓴 글:
>>> Dear Inki,
>>>
>>> On 2017-11-10 04:04, Inki Dae wrote:
2017년 11월 01일 01:28에 Marek Szyprowski 이(가) 쓴 글:
> When no IO
https://bugs.freedesktop.org/show_bug.cgi?id=103700
--- Comment #2 from dwagner ---
This bug could be the same as
https://bugs.freedesktop.org/show_bug.cgi?id=103277 - but since I have only one
display connected to the GPU - which stays off after resume (and then the
system crashes so no other wa
The introduction of: drm/framebuffer: Add framebuffer debugfs file
broke vgem. That patch assumed that all drivers had initialized the
dev->mode_config.fb_lock mutex which happens in drm_mode_config_init().
vgem doesn't need to call drm_mode_config_init().
Fix this by only creating the framebuffer
On Mon, Nov 13, 2017 at 6:42 AM, Jyri Sarha wrote:
> This patch removes DRM_TILCDC_SLAVE_COMPAT option for supporting the
> obsolete "ti,tilcdc,slave" device tree binding. The new of_graph based
> binding - that is widely used in other drm driver too - has been
> supported since Linux v4.2. Mainta
https://bugs.freedesktop.org/show_bug.cgi?id=103630
--- Comment #3 from cosiek...@o2.pl ---
Computer Information:
Manufacturer: Unknown
Model: Unknown
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: GenuineIntel
CPU Brand: Intel(R) Core(
Den 13.11.2017 23.17, skrev Chris Wilson:
Quoting Noralf Trønnes (2017-11-13 22:12:06)
Den 13.11.2017 22.33, skrev Chris Wilson:
Quoting Noralf Trønnes (2017-11-13 19:54:43)
Den 11.11.2017 19.55, skrev Chris Wilson:
Quoting Noralf Trønnes (2017-11-07 19:13:40)
Add debugfs file that dumps in
tree: git://people.freedesktop.org/~agd5f/linux.git
upstream-4.14-drm-next-amd-dc-staging-chrome
head: 4448b9a68413462529d018050cd246bc33957bd6
commit: ed285b98008b667978d7faf348a22000b8a1c6b9 [4/16] drm/ttm: Add helper
functions to populate/map in one call (v2)
config: i386-randconfig-s0-201
Quoting Noralf Trønnes (2017-11-13 22:12:06)
>
> Den 13.11.2017 22.33, skrev Chris Wilson:
> > Quoting Noralf Trønnes (2017-11-13 19:54:43)
> >> Den 11.11.2017 19.55, skrev Chris Wilson:
> >>> Quoting Noralf Trønnes (2017-11-07 19:13:40)
> Add debugfs file that dumps info about the framebuffe
Den 13.11.2017 22.33, skrev Chris Wilson:
Quoting Noralf Trønnes (2017-11-13 19:54:43)
Den 11.11.2017 19.55, skrev Chris Wilson:
Quoting Noralf Trønnes (2017-11-07 19:13:40)
Add debugfs file that dumps info about the framebuffers and its planes.
Also dump info about any connected gem object(s
tree: git://people.freedesktop.org/~agd5f/linux.git
upstream-4.14-drm-next-amd-dc-staging-chrome
head: 4448b9a68413462529d018050cd246bc33957bd6
commit: 74667d0b87be12956d9266ae54757db7adf6d1e6 [3/16] drm: Pass struct
drm_file * to __drm_mode_object_find [v2]
config: i386-randconfig-s0-201746
Quoting Noralf Trønnes (2017-11-13 19:54:43)
>
> Den 11.11.2017 19.55, skrev Chris Wilson:
> > Quoting Noralf Trønnes (2017-11-07 19:13:40)
> >> Add debugfs file that dumps info about the framebuffers and its planes.
> >> Also dump info about any connected gem object(s).
> > This isn't too hot for
https://bugs.freedesktop.org/show_bug.cgi?id=101739
--- Comment #2 from jan@gmx.de ---
I also have this problem. Is there a way to force/override Z_ORDER to LATE_Z,
at best per application, so that I can try whether this has any effect?
If not: what other way is there to test it? I am willing
On Mon, Nov 13, 2017 at 09:56:19PM +0100, Thierry Reding wrote:
> On Mon, Nov 13, 2017 at 04:14:05PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > kerneldoc for drm_plane_create_zpos_property() says that the
Lothar Waßmann writes:
> Hi,
>
> On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote:
>> Lothar Waßmann writes:
>>
>> > Hi,
>> >
>> > drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
>> > dysfunctional due to:
>> > |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
>> > |Author: Eric An
https://bugs.freedesktop.org/show_bug.cgi?id=102800
--- Comment #12 from Alex Deucher ---
Can you verify that the Linux pci subsystem is properly calling the ACPI _PR3
method on your platform? The workaround just uses the legacy AMD ACPI
interface. It appears pci is not calling _PR3 properly fo
On Mon, Nov 13, 2017 at 04:14:05PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > kerneldoc for drm_plane_create_zpos_property() says that the DRM core
> > will automatically calculate the normalized zpos values, but
https://bugzilla.kernel.org/show_bug.cgi?id=197851
--- Comment #2 from Tyler McLean (sonarsoundapplicati...@gmail.com) ---
Created attachment 260643
--> https://bugzilla.kernel.org/attachment.cgi?id=260643&action=edit
Output from dmesg on a clean restart
Attached the dmesg output. Can't get Xor
https://bugs.freedesktop.org/show_bug.cgi?id=102800
--- Comment #11 from higu...@gmx.net ---
just tested kernel 4.14.0 (without the above patch) and it still fails
i will apply the patch again, as a workaround
--
You are receiving this mail because:
You are the assignee for the bug.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: eee12cc2150b932ee52ccf89de611a7ba030eb90
commit: 0bd599b1f523598c05f13a4a562884e82a378c2c [2749/2876] ASoC: AMD: enable
ACP3x drivers build
config: blackfin-allyesconfig (attached as .config)
compiler: bfin-uclinux-
Den 11.11.2017 19.55, skrev Chris Wilson:
Quoting Noralf Trønnes (2017-11-07 19:13:40)
Add debugfs file that dumps info about the framebuffers and its planes.
Also dump info about any connected gem object(s).
This isn't too hot for non-modesetting drm drivers.
And isn't this growing a midlaye
On 11/13/17 20:43, Frank Rowand wrote:
> Hi Jyri,
>
> On 11/13/17 07:40, Jyri Sarha wrote:
>> On 11/13/17 07:58, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> On Mon, 30 Oct 2017 20:37:56 + Mark Brown wrote:
Today's linux-next merge of the devicetree tree got a conflict in:
dri
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: dab91783338bd3dd42638f89b5f7e34c57773207
commit: dab91783338bd3dd42638f89b5f7e34c57773207 [6/6] drm/i915: expose command
stream timestamp frequency to userspace
config: i386-randconfig-s0-201746 (attached as .config)
com
Hi Dave,
Here's the previous PR plus the rockchip fix that snuck in.
drm-misc-fixes-2017-11-13:
Driver Changes:
- qxl: Use a shadow bo as primary and blit to it to fix flicker (Gerd)
- rockchip: Convert psr spinlock to mutex (Emil)
Cc: Emil Renner Berthing
Cc: Gerd Hoffmann
Cheers, Sean
Th
On Mon, Nov 13, 2017 at 9:40 AM, Chen, Horace wrote:
> Reivewed-by: Horace Chen
Applied. thanks!
Alex
>
> -Original Message-
> From: Liu, Monk
> Sent: Monday, November 13, 2017 11:43 AM
> To: Chen, Horace ; Colin King
> ; Deucher, Alexander ;
> Koenig, Christian ; David Airlie
> ;
On Mon, Nov 13, 2017 at 06:30:47PM +, Jose Abreu wrote:
>
>
> On 13-11-2017 17:04, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > If the user mode would specify an aspect ratio other than 4:3 or 16:9
> > we now silently ignore it. Maybe a better apporoach is to return an
> > error? Let
On Mon, Nov 13, 2017 at 06:13:37PM +, Jose Abreu wrote:
> Hi Ville,
>
> On 13-11-2017 17:04, Ville Syrjala wrote:
> >
> > + if (to_match->picture_aspect_ratio)
> > + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> > +
> >
>
> Maybe "if (to_match->picture_aspect_ratio !=
> HDMI_PIC
On 13-11-2017 17:04, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
> ratios. Return an error if the user asked for something different.
>
> Cc: Shashank Sharma
> Cc: "Lin, Jia"
> Cc: Akashdeep Sharma
> Cc: Jim Bride
> Cc: Jose A
On 13-11-2017 17:04, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> If the user mode would specify an aspect ratio other than 4:3 or 16:9
> we now silently ignore it. Maybe a better apporoach is to return an
> error? Let's try that.
>
> Also we must be careful that we don't try to send illegal p
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: dab91783338bd3dd42638f89b5f7e34c57773207
commit: dab91783338bd3dd42638f89b5f7e34c57773207 [6/6] drm/i915: expose command
stream timestamp frequency to userspace
config: i386-defconfig (attached as .config)
compiler: gcc-
Hi Ville,
On 13-11-2017 17:04, Ville Syrjala wrote:
>
> + if (to_match->picture_aspect_ratio)
> + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
> +
>
Maybe "if (to_match->picture_aspect_ratio !=
HDMI_PICTURE_ASPECT_NONE && to_match->picture_aspect_ratio !=
HDMI_PICTURE_ASPECT_RESE
On Monday, November 13, 2017 09:07:14 AM Tony Lindgren wrote:
> Hi,
Hi Tony,
> Looks like next-20171113 now has a NULL pointe dereference with commit
> 6c78935777d1 ("video: fbdev: Convert timers to use timer_setup()").
>
> See the error below, any ideas?
S
On Monday, November 13, 2017 10:45:46 AM Thierry Reding wrote:
> From: Thierry Reding
>
> During console takeover, which happens for all DRM/KMS setups using the
> fbdev helpers, fbcon_startup() is called before fbcon_init() and as a
> result con2fb_acquire_newinfo() will not be called (info->fbc
From: Ville Syrjälä
To make sure the infoframe unpack functions don't end up examining
stack garbage or oopsing, let's pass in the size of the buffer.
Cc: Thierry Reding
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/media/i2c/adv7511.c | 2 +-
dr
From: Ville Syrjälä
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma
Cc: "Lin, Jia"
Cc: Akashdeep Sharma
Cc: Jim Bride
Cc: Jose Abreu
Cc: Daniel Vetter
Cc: Emil Velikov
Cc: Thierry Reding
From: Ville Syrjälä
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of s
From: Ville Syrjälä
commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.
Let's handle this by considering the aspect
From: Ville Syrjälä
The unpack functions just read from the passed in buffer,
so make it const.
Cc: Thierry Reding
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c | 23 ---
include/linux/hdmi.h | 3 ++-
2 files chang
From: Ville Syrjälä
Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from
3D to 2D mode in a timely fashion if the source simply stops sending the
HDMI infoframe. The suggested workaround is to keep sending the
infoframe even when strictly not necessary (ie. no VIC and no S3D).
H
From: Ville Syrjälä
Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 134 ++--
include/drm/drm_modes.h | 9 +++
From: Ville Syrjälä
Fix up a bunch of bad indentation and insconsistent comments
in edid_cea_modes[].
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 84 +++---
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm
From: Ville Syrjälä
HDMI 2.0 Appendix F suggest that we should keep sending the infoframe
when switching from 3D to 2D mode, even if the infoframe isn't strictly
necessary (ie. not needed to transmit the VIC or stereo information).
This is a workaround against some sinks that fail to realize that
From: Ville Syrjälä
Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.
This doesn't actually change anything since the input mode
comes from detailed timings and we matc
From: Ville Syrjälä
This series tries to fix some issues with HDMI infoframes. In particular
we can currently send a bogus picture aspect ratio in the infoframe. I
included stuff to to make the infoframe unpakc more robust, evne though
we don't (yet) use it in drm. Additionally I included my earl
Allocates 1 TB of memory. Test is disabled by default
since it's triggers OOM killer.
v2:
FIx the test to only alloc the BO and assert if return value
not equal to -ENOMEM and remove test disable on start.
Signed-off-by: Andrey Grodzovsky
---
tests/amdgpu/bo_tests.c | 24 +++
On Mon, Nov 13, 2017 at 2:35 AM, Dmitry V. Levin wrote:
> Consistently use types provided by via
> to fix the following linux/kfd_ioctl.h userspace compilation errors:
>
> /usr/include/linux/kfd_ioctl.h:236:2: error: unknown type name 'uint64_t'
> uint64_t va_addr; /* to KFD */
> /usr/include/
On Sat, Nov 11, 2017 at 8:16 AM, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix GP fault caused by dev_info() reference to a struct device*
> after the device has been freed (use after free).
> kfd_chardev_exit() frees the device so 'kfd_device' should not
> be used after calling kfd_chardev_ex
On 11/13/2017 10:27 AM, Christian König wrote:
Am 13.11.2017 um 15:57 schrieb Andrey Grodzovsky:
On 11/13/2017 07:39 AM, Christian König wrote:
Am 13.11.2017 um 12:32 schrieb Michel Dänzer:
On 12/11/17 10:35 AM, Christian König wrote:
A few comments on the code:
+/* Validate bo size is b
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
To make things worse, the parent mfd node was also prematurely freed.
Note that the nodes returned from the two calls to of_parse_phandl
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
This would only cause trouble if the child node is missing while there
is an unrelated node named "backlight" elsewhere in the tree.
Fix
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
To make things worse, the parent display node was also prematurely
freed.
Note that the display and timings node references are never pu
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
To make things worse, the parent mfd node was also prematurely freed,
while the child backlight node was leaked.
Fixes: 47ec340cb8e2 ("m
On 07.11.2017 15:29, Mikko Perttunen wrote:
> On 05.11.2017 19:43, Dmitry Osipenko wrote:
>> On 05.11.2017 14:01, Mikko Perttunen wrote:
>>> In the traditional channel allocation model, a single hardware channel
>>> was allocated for each client. This is simple from an implementation
>>> perspectiv
On 11/13/17 07:58, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 30 Oct 2017 20:37:56 + Mark Brown wrote:
>>
>> Today's linux-next merge of the devicetree tree got a conflict in:
>>
>> drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
>>
>> between commit:
>>
>> 44cd3939c111b7 ("drm/tilcdc: Re
https://bugs.freedesktop.org/show_bug.cgi?id=103697
--- Comment #2 from O Heid ---
I checked back with AMD and they say that there is hardware support for 64kB
shared memory. This actually gets exposed in OpenCL and ROCm/HC.
The 2016 AMD GCN3 manual wrongly states it is only 32kB, but the AMD Veg
Am 13.11.2017 um 15:57 schrieb Andrey Grodzovsky:
On 11/13/2017 07:39 AM, Christian König wrote:
Am 13.11.2017 um 12:32 schrieb Michel Dänzer:
On 12/11/17 10:35 AM, Christian König wrote:
A few comments on the code:
+/* Validate bo size is bit bigger then the request domain */
+static inlin
On Mon, Nov 13, 2017 at 4:02 PM, Ville Syrjala
wrote:
> From: Ville Syrjälä
>
> We're currently calling ktime_to_timespec64() on stack garbage
> hence the debug output for vblank timestamps also contains garbage.
> Let's assing something to the ktime_t first before we go converting
> it to a time
https://bugzilla.kernel.org/show_bug.cgi?id=197851
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
From: Ville Syrjälä
We're currently calling ktime_to_timespec64() on stack garbage
hence the debug output for vblank timestamps also contains garbage.
Let's assing something to the ktime_t first before we go converting
it to a timespec.
While at it micro-optimize the ktime_to_timespec64() calls
https://bugzilla.kernel.org/show_bug.cgi?id=197841
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On 11/13/2017 07:39 AM, Christian König wrote:
Am 13.11.2017 um 12:32 schrieb Michel Dänzer:
On 12/11/17 10:35 AM, Christian König wrote:
A few comments on the code:
+/* Validate bo size is bit bigger then the request domain */
+static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_dev
Reivewed-by: Horace Chen
-Original Message-
From: Liu, Monk
Sent: Monday, November 13, 2017 11:43 AM
To: Chen, Horace ; Colin King ;
Deucher, Alexander ; Koenig, Christian
; David Airlie ; Yu, Xiangliang
; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Cc: kernel-jani
Hi Inki,
On 2017-11-13 02:24, Inki Dae wrote:
Hi Marek,
2017년 11월 10일 16:35에 Marek Szyprowski 이(가) 쓴 글:
Dear Inki,
On 2017-11-10 04:04, Inki Dae wrote:
2017년 11월 01일 01:28에 Marek Szyprowski 이(가) 쓴 글:
When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
are contiguous,
On 13/11/17 10:20, Johan Hovold wrote:
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
To make things worse, the parent mfd node was also prematurely freed.
Note that the nodes ret
On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> kerneldoc for drm_plane_create_zpos_property() says that the DRM core
> will automatically calculate the normalized zpos values, but it won't
> currently do so. Modify the atomic helpers to behave as docume
On 13/11/17 10:20, Johan Hovold wrote:
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
To make things worse, the parent mfd node was also prematurely freed,
while the child backligh
On 13/11/17 10:20, Johan Hovold wrote:
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at the parent rather than just matching
on its children.
This would only cause trouble if the child node is missing while there
is an unrelated node name
Hi Laurent,
On 13/11/17 10:32, Laurent Pinchart wrote:
> Hello everybody,
>
> This patch series fixes two issues related to dma-buf import for the Renesas
> R-Car DU when the imported buffer is either not physically contiguous or
> located in high memory.
>
> Both cases require the use of an IOM
From: Thierry Reding
kerneldoc for drm_plane_create_zpos_property() says that the DRM core
will automatically calculate the normalized zpos values, but it won't
currently do so. Modify the atomic helpers to behave as documented.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_atomic_help
https://bugs.freedesktop.org/show_bug.cgi?id=102358
Thomas Hellström changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Am 13.11.2017 um 12:32 schrieb Michel Dänzer:
On 12/11/17 10:35 AM, Christian König wrote:
A few comments on the code:
+/* Validate bo size is bit bigger then the request domain */
+static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device
*adev,
+ unsigned long s
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit 4226d9b127cf4758ba0e07931b3f0d59f1b1a50c upstream.
Thus this patch changes the EDID probing logic so that we
re-use the __adv7511_power_on/off() calls instead of duplciating
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit 3587c856675c45809010c2cee5b21096f6e8e938 upstream.
I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors on
Hi
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
commit 651e4769ba2a9f20c4b8a823ae2727bf7fa9c9f0 upstream.
In chasing down issues with EDID probing, I found some
duplicated but incomplete logic used to power the chip on and
off.
This patch removes DRM_TILCDC_SLAVE_COMPAT option for supporting the
obsolete "ti,tilcdc,slave" device tree binding. The new of_graph based
binding - that is widely used in other drm driver too - has been
supported since Linux v4.2. Maintaining the the backwards dts
conversion code in 0the DRM_TILC
On Mon, Nov 13, 2017 at 12:32:28PM +0200, Laurent Pinchart wrote:
> When the DU sources its frames from a VSP, it performs no memory access
> and thus has no requirements on imported dma-buf memory types. In
> particular the DU could import a physically non-contiguous buffer that
> would later be m
https://bugs.freedesktop.org/show_bug.cgi?id=103443
--- Comment #3 from Marta Löfstedt ---
here also:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3331/shard-glkb2/i...@testdisplay.html
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=103443
--- Comment #2 from Marta Löfstedt ---
Here is another test that produce WARN only where there a no modes available
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3335/shard-glkb2/igt@kms_sysfs_edid_timing.html
--
You are receiving this mail
On Mon, Nov 13, 2017 at 12:32:27PM +0200, Laurent Pinchart wrote:
> The DU DMA address space is limited to 32 bits, so the DMA coherent mask
> should be set accordingly. The DMA mapping implementation will
> transparently map high memory buffers to 32-bit addresses through an
> IOMMU when present (
On 12/11/17 10:35 AM, Christian König wrote:
> A few comments on the code:
>
>> +/* Validate bo size is bit bigger then the request domain */
>> +static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device
>> *adev,
>> + unsigned long size, u32 domain)
> Drop the inline
Hi Peter,
On 11/12/2017 01:31 PM, Peter Rosin wrote:
> On 2017-11-10 17:12, Philippe CORNU wrote:
>> Hi Peter,
>>
>> On 11/07/2017 05:34 PM, Peter Rosin wrote:
>>> On 2017-11-07 16:53, Philippe CORNU wrote:
+ Peter
Hi Peter,
CLUT support on STM32 has been removed thanks to
The DU DMA address space is limited to 32 bits, so the DMA coherent mask
should be set accordingly. The DMA mapping implementation will
transparently map high memory buffers to 32-bit addresses through an
IOMMU when present (or through bounce buffers otherwise, which isn't a
supported use case as p
Hello everybody,
This patch series fixes two issues related to dma-buf import for the Renesas
R-Car DU when the imported buffer is either not physically contiguous or
located in high memory.
Both cases require the use of an IOMMU to remap the buffers contiguously and
in 32-bit DMA space. On Gen2
When the DU sources its frames from a VSP, it performs no memory access
and thus has no requirements on imported dma-buf memory types. In
particular the DU could import a physically non-contiguous buffer that
would later be mapped contiguously through the VSP IOMMU.
This use case isn't supported a
Hi Uma,
On 10 November 2017 at 08:37, Shankar, Uma wrote:
>>This is missing documentation on how plane colour management interacts with
>>CRTC colour management. Is it a step before CRTC colour management is
>>applied, or does it bypass CRTC colour management, or ... ?
>>
>
> We can have color co
For personal reasons, Mark Yao will leave rockchip,
can not continue maintain drm/rockchip, Sandy Huang
will take over the drm/rockchip.
Cc: Sandy Huang
Cc: Heiko Stuebner
Signed-off-by: Mark Yao
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b
1 - 100 of 117 matches
Mail list logo
