>From: Philipp Zabel [mailto:p.za...@pengutronix.de]
>Sent: Dienstag, 10. Oktober 2017 15:28
>
>The IDMAC_LOCK_EN registers on i.MX51 have a different layout, and on
>i.MX53 enabling the lock feature causes bursts to get lost. Restrict
>enabling the burst lock feature to i.MX6.
>
>Reported-by: Patr
Hi Marek,
Currently, IPP v2 and gsc do not seem to have any code to
check for hardware limits. How can I check the hardware limits
of device(gsc, rotator, ...) at IPP v2?
Best regards,
Hoegeun
On 09/29/2017 04:32 PM, Marek Szyprowski wrote:
This patch adds Exynos IPP v2 subsystem and userspace
These ioctls replace drmWaitVBlank and add ns time resolution and
64-bit sequence numbers to comply with the Vulkan API specifications.
The tests were derived from the existing kms_vblank tests with the
'wait' variant elided as the new API doesn't provide a mechanism for
blocking in the kernel.
v
Validate that the leasing API creates leases that allow access to a
subset of the available resources and that lease revocation works.
v2: from Dave Airlie
* Update ioctl numbers to latest proposed values.
* Fix commit message
* Add tests for get_lease and list_lessees
Signed-off-by: Keith P
Changes since last version:
* Add local definitions of new ioctls to avoid dependency on proposed
libdrm bits.
* Remove FIRST_PIXEL_OUT as that has been removed from the proposed
kernel interface
* Add tests for get_lease and list_lessees
* Fix commit message on the lease test patch
New since last time:
* Fix vboxvideo driver in staging
* Fixed some formatting and whitespace errors (Dave Airlie)
* Explain the odd use of the idr interface for leases (Dave Airlie)
* Disallow negative object_id in lease creation (Dave Airlie)
It's also been rebased on top of the drm-sequenc
This will allow __drm_mode_object_file to be extended to perform
access control checks based on the file in use.
v2: Also fix up vboxvideo driver in staging
Suggested-by: Daniel Vetter
Signed-off-by: Keith Packard
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16
driv
Attempts to modify un-leased objects are rejected with an error.
Information returned about unleased objects is modified to make them
appear unusable and/or disconnected.
Changes for v2 as suggested by Daniel Vetter :
With the change in the __drm_mode_object_find API to pass the
file_priv along,
This allows an application to discover what display resources are
available before requesting a lease from the X server.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_ioctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioc
This provides new data structures to hold "lease" information about
drm mode setting objects, and provides for creating new drm_masters
which have access to a subset of the available drm resources.
An 'owner' is a drm_master which is not leasing the objects from
another drm_master, and hence 'owns
drm_mode_create_lease
Creates a lease for a list of drm mode objects, returning an
fd for the new drm_master and a 64-bit identifier for the lessee
drm_mode_list_lesees
List the identifiers of the lessees for a master file
drm_mode_get_lease
List the leased obje
Separate out lease debugging from the core.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_drv.c | 3 ++-
include/drm/drmP.h| 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index c0292e5d7281..a934fd5e7e55
Place drm_event_vblank in a new union that includes that and a bare
drm_event structure. This will allow new members of that union to be
added in the future without changing code related to the existing vbl
event type.
Assignments to the crtc_id field are now done when the event is
allocated, rath
This version removes the FIRST_PIXEL_OUT flag as the existing code
already conforms to that requirement. It has also been rebased to
drm-next.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-d
This modifies the datatypes used by the vblank code to provide both 64
bits of vblank count and switch to using ktime_t for timestamps to
increase resolution from microseconds to nanoseconds.
The driver interfaces have been left using 32 bits of vblank count;
all of the code necessary to widen tha
These provide crtc-id based functions instead of pipe-number, while
also offering higher resolution time (ns) and wider frame count (64)
as required by the Vulkan API.
v2:
* Check for DRIVER_MODESET in new crtc-based vblank ioctls
Failing to check this will oops the driver.
* Ensure v
https://bugs.freedesktop.org/show_bug.cgi?id=102800
--- Comment #9 from higu...@gmx.net ---
Yes, applying the patch, i can use the radeon card without the runpm=0. Also,
turning OFF and ON the dedicated GPU now works fine
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=102955
Elliot Thomas changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
On Tue, Oct 10, 2017 at 4:53 AM, Christian König
wrote:
> From: Christian König
>
> Add a new huge page pool and try to allocate from it when it makes sense.
>
> v2: avoid compound pages for now
>
> Signed-off-by: Christian König
> Acked-by: Alex Deucher
Series is:
Acked-by: Alex Deucher
> -
https://bugs.freedesktop.org/show_bug.cgi?id=103138
--- Comment #5 from Vedran Miletić ---
I can confirm both that the issue is still present in
2c7cb03ed2bb119f146ad0b9d9ab0a9ebb04b5a1 (current tip of amd-staging-drm-next)
and that the patch fixes it.
--
You are receiving this mail because:
Yo
On Tue, Oct 10, 2017 at 2:39 PM, Frank Rowand wrote:
> On 10/10/17 11:40, Rob Herring wrote:
>> On Wed, Oct 04, 2017 at 08:29:59PM -0700, Frank Rowand wrote:
>>> On 10/04/17 08:19, Rob Herring wrote:
On Mon, Oct 2, 2017 at 10:53 PM, wrote:
> From: Frank Rowand
>
> The process o
https://bugs.freedesktop.org/show_bug.cgi?id=97942
--- Comment #8 from Elizabeth ---
(In reply to Humberto Israel Perez Rodriguez from comment #6)
> The following test cases failure on BXT with latest configuration
>
> igt@gem_mmap@swap-bo
> igt@gem_mmap_gtt@coherency
> igt@gem_mmap_gtt@swap-cop
On Wed, Oct 04, 2017 at 08:29:59PM -0700, Frank Rowand wrote:
> On 10/04/17 08:19, Rob Herring wrote:
> > On Mon, Oct 2, 2017 at 10:53 PM, wrote:
> >> From: Frank Rowand
> >>
> >> The process of applying an overlay consists of:
> >> - unflatten an overlay FDT (flattened device tree) into an
>
On Mon, Oct 09, 2017 at 12:29:57PM +0300, Jani Nikula wrote:
> Falling back to the lowest value is likely the only thing we can do, but
> doing it silently seems like a bad thing to do. Catch it early and make
> loud noises.
>
> Cc: Alex Deucher
> Cc: Thierry Reding
> Cc: Rob Clark
> Cc: Sean P
Dave Airlie writes:
>> +*/
>> + ret = idr_alloc(&leases, &drm_lease_idr_object , object_id,
>> object_id + 1, GFP_KERNEL);
>
> In current kernels, the idr_alloc warns if start < 0, so if object_id
> is a negative signed integer, which your
> igt tests actually make
On 10/10/17 15:35, Joonas Lahtinen wrote:
> On Tue, 2017-10-10 at 14:47 +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> There is a previous check to on has_aliasing_ppgtt that returns
>> 0 if it is false, so it is impossible for has_aliasing_ppgtt to
>> be false on the final return of funct
On Tue, 2017-10-10 at 14:47 +0100, Colin King wrote:
> From: Colin Ian King
>
> There is a previous check to on has_aliasing_ppgtt that returns
> 0 if it is false, so it is impossible for has_aliasing_ppgtt to
> be false on the final return of function intel_sanitize_enable_ppgtt,
> so final retu
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 10/10/17 15:09, Kevin Hao wrote:
> The check for vrefresh has been removed by commit 11abbc9f39e0
> ("drm/tilcdc: Set framebuffer DMA address to HW only if CRTC is
>
From: Colin Ian King
There is a previous check to on has_aliasing_ppgtt that returns
0 if it is false, so it is impossible for has_aliasing_ppgtt to
be false on the final return of function intel_sanitize_enable_ppgtt,
so final return in the function always will return 1. Hence the
redundant ter
From: Ville Syrjälä
On machines where the vblank interrupt fires some time after the start
of vblank (or we just manage to race with the vblank interrupt handler)
we will currently stuff a stale vblank counter value into the flip event,
and thus we'll prematurely complete the flip.
Switch over t
https://bugs.freedesktop.org/show_bug.cgi?id=101483
--- Comment #17 from FFAB ---
Upstream kernel test - kernel 4.14-rc4
boot-time +/- 40sec (message sound),
black screen
no net connection - neither cable nor wlan.
n o remote-login possible
-> no dmesg
--
You are receiving this mail because:
The IDMAC_LOCK_EN registers on i.MX51 have a different layout, and on
i.MX53 enabling the lock feature causes bursts to get lost. Restrict
enabling the burst lock feature to i.MX6.
Reported-by: Patrick Brünn
Fixes: 790cb4c7c954 ("drm/imx: lock scanout transfers for consecutive bursts")
Signed-off
Hi Patrick,
On Tue, 2017-10-10 at 10:24 +, Patrick Brünn wrote:
> Hi Philipp,
>
> since commit 790cb4c7c9545953d22d3d425e49b36a711bae5b my display on CX9020 (a
> i.MX53 based machine) stopped working:
>
> # dmesg | grep -i drm
> [0.141829] [drm] Supports vblank timestamp caching Rev 2
https://bugs.freedesktop.org/show_bug.cgi?id=102800
--- Comment #8 from Alex Deucher ---
Created attachment 134779
--> https://bugs.freedesktop.org/attachment.cgi?id=134779&action=edit
workaround to test
Does this patch fix the issue?
--
You are receiving this mail because:
You are the assig
https://bugs.freedesktop.org/show_bug.cgi?id=102800
Alex Deucher changed:
What|Removed |Added
Attachment #134265|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=103192
Bug ID: 103192
Summary: adytm404
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
On Tue, Oct 10, 2017 at 4:59 AM, Daniel Vetter wrote:
> On Tue, Oct 10, 2017 at 08:58:03AM +0530, Archit Taneja wrote:
>>
>>
>> On 10/06/2017 07:32 PM, Daniel Vetter wrote:
>> > On Fri, Oct 06, 2017 at 04:27:06PM +0530, Archit Taneja wrote:
>> > > The DSI runtime PM suspend/resume callbacks check
https://bugs.freedesktop.org/show_bug.cgi?id=102809
--- Comment #10 from Nicolai Hähnle ---
I can confirm similar weird color flashes as shown in the video when playing
the trace on RX Vega 64. So oddly enough, this seems Vega-specific, as I didn't
observe it on Raven. I'm going to take a closer
https://bugs.freedesktop.org/show_bug.cgi?id=102581
--- Comment #4 from Nicolai Hähnle ---
Maybe an SI-specific bug? Looks like the bottom part of the screenshot
comparison for me on both Carrizo and Tonga (VI) with Git master.
--
You are receiving this mail because:
You are the assignee for th
Hi Philipp,
since commit 790cb4c7c9545953d22d3d425e49b36a711bae5b my display on CX9020 (a
i.MX53 based machine) stopped working:
# dmesg | grep -i drm
[0.141829] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[0.141838] [drm] No driver support for vblank timestamp query.
[
On Tuesday, 2017-10-10 10:12:52 +, Tobias Jakobi wrote:
> Both drmModeAddFB2() and drmModeAddFB2WithModifiers() have some
> arguments that are just pointers to uint32_t in disguise. These
> are not modified (just copied) in the function, so we can add a
> const qualifier here.
>
> Signed-off-b
https://bugs.freedesktop.org/show_bug.cgi?id=103142
--- Comment #4 from Gert Wollny ---
The bug can be triggered on BARTS (6850 HD) by using the Unreal Engine 4.17.1
or 4.18.0-pre3 with this patch applied [1] to fix a shader that otherwise would
use too many registers.
(Note that in mesa-debug m
https://bugs.freedesktop.org/show_bug.cgi?id=103142
--- Comment #3 from Gert Wollny ---
Created attachment 134771
--> https://bugs.freedesktop.org/attachment.cgi?id=134771&action=edit
Patch to fix shader in UE4 (added for completeness)
--
You are receiving this mail because:
You are the assig
Both drmModeAddFB2() and drmModeAddFB2WithModifiers() have some
arguments that are just pointers to uint32_t in disguise. These
are not modified (just copied) in the function, so we can add a
const qualifier here.
Signed-off-by: Tobias Jakobi
---
xf86drmMode.c | 10 +-
xf86drmMode.h | 11
2017-10-10 5:36 GMT+02:00 Archit Taneja :
>
>
> On 10/02/2017 03:02 PM, Benjamin Gaignard wrote:
>>
>> The goal of this series is to simplify driver code when they need to clean
>> up
>> a previously allocated panel bridge.
>> Few drivers have "is_panel_bridge" flag to be able to distinguish a
>> d
https://bugs.freedesktop.org/show_bug.cgi?id=102926
Andy Furniss changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi Marek,
On 09/29/2017 04:32 PM, Marek Szyprowski wrote:
This patch adapts Exynos DRM rotator driver to new IPP v2 core API.
The side effect of this conversion is a switch to driver component API
to register properly in the Exynos DRM core.
Signed-off-by: Marek Szyprowski
Tested-by: Hoegeun K
On Mon, Oct 09, 2017 at 05:10:37PM -0700, Laura Abbott wrote:
> On 10/09/2017 03:08 PM, Mark Brown wrote:
> > On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
> >> Anyway, to move this forward I think we need to see a proof of concept
> >> of using selinux to protect access to specifi
On Mon, Oct 09, 2017 at 05:18:57PM -0600, Haneen Mohammed wrote:
> On Wed, Sep 27, 2017 at 04:06:21PM -0400, Sean Paul wrote:
> > On Wed, Sep 27, 2017 at 12:23:17PM -0600, Haneen Mohammed wrote:
> > > Since the output has 1:1 relationship between connectors and encoders,
> > > and the driver is rel
https://bugs.freedesktop.org/show_bug.cgi?id=103175
--- Comment #5 from Andy Furniss ---
I had that fix and a couple of others on the first 4.15-wip I tried. They are
in now AFAICT. I see Alex updated again since yesterday so I'll try that one
later.
I did notice but forgot to highlight the GPU
On Tue, Oct 10, 2017 at 08:58:03AM +0530, Archit Taneja wrote:
>
>
> On 10/06/2017 07:32 PM, Daniel Vetter wrote:
> > On Fri, Oct 06, 2017 at 04:27:06PM +0530, Archit Taneja wrote:
> > > The DSI runtime PM suspend/resume callbacks check whether
> > > msm_host->cfg_hnd is non-NULL before trying to
On Mon, Oct 09, 2017 at 10:18:30AM -0700, Keith Packard wrote:
> Daniel Vetter writes:
>
> > I just figured that -modesetting would be the simplest domenstration
> > vehicle, since the vulkan patches don't look ready yet. I need fully
> > reviewed&tested userspace before we can land any kernel st
From: Christian König
Add a new huge page pool and try to allocate from it when it makes sense.
v2: avoid compound pages for now
Signed-off-by: Christian König
Acked-by: Alex Deucher
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 136 ---
1 file changed, 109 inser
From: Christian König
Try to allocate huge pages when it makes sense.
v2: avoid compound pages for now
Signed-off-by: Christian König
Acked-by: Felix Kuehling
Acked-by: Alex Deucher
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 50 ++--
1 file changed, 42 insert
From: Christian König
We need to figure out first how to correctly map them into the CPU page tables.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=103138
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
From: Christian König
Make it easier to add huge page pool.
Signed-off-by: Christian König
Acked-by: Alex Deucher
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 98 +++-
1 file changed, 52 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_al
https://bugs.freedesktop.org/show_bug.cgi?id=103175
--- Comment #4 from Michel Dänzer ---
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=e5f6a57e350a7921e4edc30874679bdff11b13f4
might help.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=103175
--- Comment #3 from Michel Dänzer ---
According to the HUD, the GPU load is actually higher in the bad cases. Have
you checked what clocks the GPU runs at in each case?
--
You are receiving this mail because:
You are the assignee for the bug._
On 09.10.2017 12:30, Jani Nikula wrote:
> On Tue, 03 Oct 2017, Jani Nikula wrote:
>> I merged this last week with Daniel's IRC ack. We'll need to give people
>> a little bit of time before updating nightly.conf. Sorry for the
>> inconvenience in the mean time.
> Andrzej, all the bits and pieces fo
> +*/
> + ret = idr_alloc(&leases, &drm_lease_idr_object , object_id,
> object_id + 1, GFP_KERNEL);
In current kernels, the idr_alloc warns if start < 0, so if object_id
is a negative signed integer, which your
igt tests actually make it.
So we get an ugly debug spl
Replace instances of drm_framebuffer_reference/unreference() with
*_get/put() suffixes and drm_dev_unref with *_put() suffix
because get/put is shorter and consistent with the
kernel use of *_get/put suffixes.
Done with following coccinelle semantic patch
@@
expression ex;
@@
(
-drm_framebuffer_u
On Wed, Sep 27, 2017 at 04:06:21PM -0400, Sean Paul wrote:
> On Wed, Sep 27, 2017 at 12:23:17PM -0600, Haneen Mohammed wrote:
> > Since the output has 1:1 relationship between connectors and encoders,
> > and the driver is relying on the atomic helpers, remove the custom
> > best_encoder() and let
On Mon, Oct 9, 2017 at 7:18 PM, Bjorn Helgaas wrote:
> On Mon, Oct 09, 2017 at 12:15:17PM -0500, Bjorn Helgaas wrote:
>> [+cc Rafael, linux-pm]
>>
>> Hi Jia-Ju,
>>
>> On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote:
>> > The drivers vt6655 and gma500 call pci_set_power_state under a spi
Oh, sorry, I will send the patches for each driver.
Thanks,
Jia-Ju Bai
On 2017/10/9 16:17, Greg KH wrote:
On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote:
The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, which
may sleep.
The function call paths are:
gma_pow
On Mon, Oct 09, 2017 at 12:15:17PM -0500, Bjorn Helgaas wrote:
> [+cc Rafael, linux-pm]
>
> Hi Jia-Ju,
>
> On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote:
> > The drivers vt6655 and gma500 call pci_set_power_state under a spinlock,
> > which may sleep.
> > The function call paths are
Hi,
On Thu, Sep 21, 2017 at 12:46:04PM +0100, Sean Young wrote:
> On Mon, Sep 18, 2017 at 04:37:52PM +0200, Hans Verkuil wrote:
> > On 09/18/2017 04:15 PM, Maciej Purski wrote:
> > > Hi Hans,
> > > some time ago in reply to your email I described what messages does
> > > the MHL driver receive and
Thanks for the quick pointer!!
-brad w.
On Mon, Oct 9, 2017 at 3:58 AM, Daniel Vetter wrote:
> On Fri, Oct 06, 2017 at 01:44:48PM -0500, Brad Walker wrote:
> > I noticed this email address is listed as the relevant area for the
> > Documentation/devicetree/bindings/video/ directory in the Linux
[+cc Rafael, linux-pm]
Hi Jia-Ju,
On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote:
> The drivers vt6655 and gma500 call pci_set_power_state under a spinlock,
> which may sleep.
> The function call paths are:
> gma_power_begin (acquire the spinlock) (drivers/gpu/drm/gma500/power.c)
>
The driver may sleep under a spinlock, and the function call paths are:
gma_power_begin (acquire the spinlock) (drivers/gpu/drm/gma500/power.c)
gma_resume_pci
pci_set_power_state
__pci_start_power_transition (drivers/pci/pci.c)
msleep --> may sleep
gma_power_begin (acquire
The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, which
may sleep.
The function call paths are:
gma_power_begin (acquire the spinlock) (drivers/gpu/drm/gma500/power.c)
gma_resume_pci
pci_set_power_state
__pci_start_power_transition (drivers/pci/pci.c)
msl
70 matches
Mail list logo
