tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: e2ea2db1734a0e38b89e4d706b5f9ad9f73b1543
commit: 72041f9847abb05b9d4d7dea17631b579191ca99 [7/8] RFC: debugobjects:
capture stack traces at _init() time
config: alpha-allyesconfig (attached as .config)
compiler:
From: Colin Ian King
The current use of result is or'ing in values and checking for
a non-zero result, however, result is not initialized to zero
so it potentially contains garbage to start with. Fix this by
initializing it to the first return from the call to
Just a gentle ping.
Daniel, Chris and all the other usual suspects for infrastructure stuff:
What do you think about that?
The cleanup patches are rather obvious correct, but #3 could result in
some fallout.
I really think it is the right thing in the long term.
Regards,
Christian.
Am
Am Dienstag, den 05.06.2018, 13:02 -0400 schrieb Andrey Grodzovsky:
> Everything in the flush code path (i.e. waiting for SW queue
> to become empty) names with *_flush()
> and everything in the release code path names *_fini()
>
> This patch also effect the amdgpu and etnaviv drivers which
> use
On 06/05/2018 01:07 AM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #15 from udo ---
Only the file from this commit
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/amdgpu/vega10_vce.bin?id=1fa9ce33895f3634398a360715331cc222d243d6
was different from the Fedora rpm
omap_dss_device instances have two ops structures, omap_dss_driver and
omap_dss_device_ops. The former is used for devices at the end of the
pipeline (a.k.a. display devices), and the latter for intermediate
devices.
Having two sets of operations isn't convenient as code that iterates
over
The .get_mirror() and .set_mirror() omap_dss_driver operations are
implemented by the panel-tpo-td043mtea1 driver but are never used.
Remove them.
Signed-off-by: Laurent Pinchart
---
.../drm/omapdrm/displays/panel-tpo-td043mtea1.c| 25 ++
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/connector-hdmi.c | 57 ---
1 file changed, 20 insertions(+), 37 deletions(-)
diff
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
The reset GPIO is mandatory, so drop conditional tests through the
driver. The qvga GPIO is unused, so drop it completely.
Signed-off-by: Laurent Pinchart
---
The .probe(), .remove(), .run_test(), .get_rotate() and .set_rotate()
omap_dss_driver operations are not used. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
Hello,
This patch series reworks all the HPD-related operations (detection, EDID
read, HPD callback (un)registration and HPD enable/disable) as a step toward
moving from omap_dss_device to drm_bridge.
All HPD-related operations are called by the omapdrm driver on the
omap_dss_device at the end
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
As the descriptor API handles the active-low flag internally we need to
invert the polarity of all GPIO operations in the driver.
Signed-off-by: Laurent Pinchart
---
On 06/06/18 13:18, Colin King wrote:
> From: Colin Ian King
>
> The current use of result is or'ing in values and checking for
> a non-zero result, however, result is not initialized to zero
> so it potentially contains garbage to start with. Fix this by
> initializing it to the first return
Am 06.06.2018 um 14:08 schrieb Gabriel C:
2018-06-06 13:33 GMT+02:00 Christian König :
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00 Gabriel C :
2018-04-11 6:00 GMT+02:00 Gabriel C :
2018-04-09 11:42 GMT+02:00 Christian König
:
Am 07.04.2018 um 00:00 schrieb Jean-Marc
On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:
Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
Add binding info for peripherals that support
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00 Gabriel C :
2018-04-11 6:00 GMT+02:00 Gabriel C :
2018-04-09 11:42 GMT+02:00 Christian König :
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
...
I can help testing code for 4.17/++ if you wish but that is *different*
The omap_dss_device .enable_hpd() and .disable_hpd() are used to enable
and disable hot-plug detection at omapdrm probe and remove time. This is
required to avoid reporting hot-plug detection events before the DRM
infrastructure is ready to accept them, as that could result in crashes
or other
Various functions that need to differentiate between omap_dss_device
instances corresponding to displays and to internal encoders use the
omap_dss_device.driver field, which is only set for display instances.
This gets in the way of the omap_dss_device operations refactoring.
Replace that with a
The HPD-related omap_dss_device operations are now only called when the
device supports HPD. There's no need to duplicate that check in the
omap_dss_device drivers. The .register_hpd_cb() operation can as a
result be turned into a void operation.
Signed-off-by: Laurent Pinchart
---
The drm_encoder implementation requires access to the omap_dss_device
corresponding to the display, which is passed to its initialization
function and stored internally. Clean up of the HDMI mode and infoframe
handling will require access to the output omap_dss_device. To prepare
for that, pass it
Instead of calling the hot-plug detection callback registration
operations (.register_hpd_cb() and .unregister_hpd_cb()) recursively
from the display device back to the first device that provides hot plug
detection support, iterate over the devices manually in the DRM
connector code. This moves
The CRTC mode set implementation needs to access the omap_dss_device for
the pipeline display. To do so, it iterates over all pipelines to find
the one that contains an encoder corresponding to the CRTC, and request
the display device from the encoder. That's a very complicated dance
when the CRTC
On HDMI outputs, CEC support requires notification of HPD signal
deassertion. The HPD signal can be handled by various omap_dss_device
instances in the pipeline, and all of them forward HPD events to the
OMAP4 internal HDMI encoder.
Knowledge of the DSS internals need to be removed from the
Instead of calling the .detect() operation recursively from the display
device back to the first device that provides hot plug detection
support, iterate over the devices manually in the DRM connector
.detect() implementation. This moves the complexity to a single central
location and simplifies
The driver doesn't use GPIOs and thus doesn't need to include the
linux/gpio.h header.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
Signed-off-by: Laurent Pinchart
---
.../drm/omapdrm/displays/panel-sony-acx565akm.c| 56 --
1 file changed, 21 insertions(+), 35 deletions(-)
diff
The GPIO descriptor API is favoured over the plain GPIO API for consumer
drivers. Using it simplifies the driver code.
As the descriptor API handles the active-low flag internally we need to
invert the polarity of all GPIO operations in the driver. Rename the
nreset_gpio field to reset_gpio to
The omapdrm driver checks at suspend and resume time whether the
displays it operates on have their driver operations set. This check is
unneeded, as all display drivers set the driver operations field at
probe time and never touch it afterwards. This is furthermore proven by
the dereferencing of
The HDMI mode (.set_hdmi_mode()) and infoframe (.set_infoframe())
operations are called recursively from the display device back to the
HDMI encoder. This isn't required, as all components other than the HDMI
encoder just forward the operation to the previous component in the
chain. Call the
Instead of calling the EDID read operation (.read_edid()) recursively
from the display device back to the first device that provides EDID read
support, iterate over the devices manually in the DRM connector code.
This moves the complexity to a single central location and simplifies
the logic in
When an omap_dss_device operation can be implemented in multiple places
in a chain of devices, it is important to find out which device to
address to perfom the operation. This is currently done by calling the
operation on the display device at the end of the chain, and recursively
delagating the
Am Dienstag, den 05.06.2018, 20:11 +0300 schrieb Leonard Crestez:
> With old bindings imx_gpc_onecell_data always sets num_domains to 2 so
> the DISPMIX domain can't actually be referenced. The pd is still defined
> and pm core shuts it down as "unused" so display can't work.
>
> Converting to
Hi Archit,
Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja:
> On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:
> > Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
> >> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
> >>> Am Donnerstag, 18. Januar
On 06/05/2018 01:28 AM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
/* -- */
+static int
+dmabuf_imp_grant_foreign_access(struct page **pages, u32 *refs,
+ int
On 06/05/2018 01:36 AM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Allow creating grant device context for use by kernel modules which
require functionality, provided by gntdev. Export symbols for dma-buf
API provided by the
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #14 from Michel Dänzer ---
(In reply to udo from comment #13)
> For my Ryzen 5 2400g that means all vega* files from
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> tree/amdgpu ?
Mostly the raven*
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #24 from Michel Dänzer ---
Created attachment 140046
--> https://bugs.freedesktop.org/attachment.cgi?id=140046=edit
Add some debugging output to amdgpu_sa_bo_new
This patch should tell us which of the WARN_ON_ONCE in
On 06/04/2018 07:37 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
diff --git a/include/xen/mem-reservation.h b/include/xen/mem-reservation.h
new file mode 100644
index ..a727d65a1e61
--- /dev/null
+++ b/include/xen/mem-reservation.h
@@ -0,0 +1,65
Op 06-06-18 om 05:37 schreef Dave Airlie:
> On 26 April 2018 at 20:53, Maarten Lankhorst
> wrote:
>> Hi Dave,
>>
>> This is my first pull request for v4.18. Only UAPI change is adding a
>> generic plane
>> alpha property, which replaces the driver specific ones in sun4i, rcar-du
>> and
On 06/04/2018 09:46 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #17 from Michel Dänzer ---
https://patchwork.freedesktop.org/patch/227925/ might provide inspiration for
how this could be solved.
--
You are receiving this mail because:
You are the assignee for the
Adopt the SPDX license identifier headers to ease license compliance
management.
Signed-off-by: Enric Balletbo i Serra
---
drivers/gpu/drm/bridge/analogix-anx78xx.c | 24 ---
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git
Hi Laurent,
On Tue, Jun 5, 2018 at 10:24 PM, Laurent Pinchart
wrote:
> On Tuesday, 5 June 2018 22:49:57 EEST Sergei Shtylyov wrote:
>> On 06/05/2018 10:16 PM, Laurent Pinchart wrote:
>> Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
>> hardware seems the same as
Hi Mikulas,
On Sun, 2018-06-03 at 16:40 +0200, Mikulas Patocka wrote:
> Hi
>
> Here I'm sending bug fixes and performance improvements for the USB
> DisplayLink framebuffer and modesetting drivers for this merge window.
For such a long series it would be very nice to post a link to your git
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.
Cc: Daniel Vetter
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Gustavo Padovan
On Mon, Jun 04, 2018 at 10:04:59PM +0300, Sergei Shtylyov wrote:
> Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
> hardware seems the same as in the R-Car V3M (R8A77970).
>
> Signed-off-by: Sergei Shtylyov
Reviewed-by: Simon Horman
>
> ---
> The patch is against the
On Tue, Jun 05, 2018 at 10:08:02AM +, Alexey Brodkin wrote:
> Hi Mikulas,
>
> On Sun, 2018-06-03 at 16:41 +0200, Mikulas Patocka wrote:
> > Modern processors can detect linear memory accesses and prefetch data
> > automatically, so there's no need to use prefetch.
>
> Not each and every CPU
On 2018-06-05 07:02 PM, Andrey Grodzovsky wrote:
> Everything in the flush code path (i.e. waiting for SW queue
> to become empty) names with *_flush()
> and everything in the release code path names *_fini()
>
> This patch also effect the amdgpu and etnaviv drivers which
> use those functions.
>
On Fri, May 18, 2018 at 3:29 PM, Maxime Ripard
wrote:
> On Fri, May 18, 2018 at 03:15:10PM +0530, Jagan Teki wrote:
>> Allwinner A64 has display engine pipeline like other Allwinner SOC's
>> A83T/H3/H5.
>>
>> A64 behaviour similar to Allwinner A83T where
>> Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
Hi Laurent,
On 05/06/18 12:11, Laurent Pinchart wrote:
> Hi Enric,
>
> Thank you for the patch.
>
> On Tuesday, 5 June 2018 13:00:50 EEST Enric Balletbo i Serra wrote:
>> Adopt the SPDX license identifier headers to ease license compliance
>> management.
>>
>> Signed-off-by: Enric Balletbo i
With old bindings imx_gpc_onecell_data always sets num_domains to 2 so
the DISPMIX domain can't actually be referenced. The pd is still defined
and pm core shuts it down as "unused" so display can't work.
Converting to new gpc bindings by adding pgc nodes, also reference
referencing the
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
Signed-off-by: Enric Balletbo i Serra
---
Changes in v6: None
Changes in v5: None
Changes in
Hi all,
On 05/06/18 12:33, Laurent Pinchart wrote:
> Hi Enric,
>
> On Tuesday, 5 June 2018 13:27:06 EEST Enric Balletbo i Serra wrote:
>> On 05/06/18 12:11, Laurent Pinchart wrote:
>>> On Tuesday, 5 June 2018 13:00:50 EEST Enric Balletbo i Serra wrote:
Adopt the SPDX license identifier
于 2018年6月5日 GMT+08:00 下午9:25:39, Maxime Ripard 写到:
>On Tue, Jun 05, 2018 at 06:23:57PM +0530, Jagan Teki wrote:
>> On Fri, May 18, 2018 at 3:29 PM, Maxime Ripard
>> wrote:
>> > On Fri, May 18, 2018 at 03:15:10PM +0530, Jagan Teki wrote:
>> >> Allwinner A64 has display engine pipeline like
Adding imx6sl/sx lcdif nodes in a power domain currently does work, it
results in black/corrupted screens or hangs. While the driver does
enable runtime pm it does not deal correctly with the block being
unpowered.
Fix by adding pm_runtime_get/put_sync to mxsfb_pipe_enable/disable.
The
The format specifier %p can leak kernel addresses
while not valuing the kptr_restrict system settings.
Use %pK instead of %p, which also evaluates whether
kptr_restrict is set.
Signed-off-by: Divya Ponnusamy
Signed-off-by: Daniel Rosenberg
Cc: stable
---
drivers/dma-buf/sync_debug.c | 2 +-
1
On 2018-06-05 20:50, Rob Herring wrote:
On Tue, Jun 05, 2018 at 11:10:16AM +0530, Sandeep Panda wrote:
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Changes in v1:
- Rephrase the dt-binding descriptions to be more inline with
existing
bindings (Andrzej Hajda).
- Add
Hi Mikulas,
On Sun, 2018-06-03 at 16:41 +0200, Mikulas Patocka wrote:
> Modern processors can detect linear memory accesses and prefetch data
> automatically, so there's no need to use prefetch.
Not each and every CPU that's capable of running Linux has prefetch
functionality :)
Still
On 06/04/2018 11:12 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Allow mappings for DMA backed buffers if grant table module
supports such: this extends grant device to not only map buffers
made of balloon pages, but also
https://bugs.freedesktop.org/show_bug.cgi?id=104770
--- Comment #2 from Thomas Rohloff ---
The problem still exist. Don't you guys want to mask GL_ARB_compute_shader? In
my eyes no OpenGL 4.3 would be better than being broken.
OpenGL renderer string: AMD CAYMAN (DRM 2.50.0 / 4.16.12, LLVM
On 05.06.2018 20:49, Eric Anholt wrote:
> Andrzej Hajda writes:
>
>> On 04.06.2018 21:44, Eric Anholt wrote:
>>> We want the DSI PHY to be enabled and the DSI module clocked before a
>>> panel or bridge's prepare() function, since most DSI panel drivers
>>> with a prepare() hook are doing DCS
Am 06.06.2018 um 09:03 schrieb Michel Dänzer:
On 2018-06-05 07:02 PM, Andrey Grodzovsky wrote:
Everything in the flush code path (i.e. waiting for SW queue
to become empty) names with *_flush()
and everything in the release code path names *_fini()
This patch also effect the amdgpu and etnaviv
Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
> > Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
> >> Add binding info for peripherals that support dual-channel DSI. Add
> >> corresponding optional
Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt:
> Between creation and queueing of a job, you need to prevent any other
> job from being created and queued. Otherwise the scheduler's fences
> may be signaled out of seqno order.
>
> > Signed-off-by: Eric Anholt
> Fixes:
Am 06.06.2018 um 10:46 schrieb Lucas Stach:
Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt:
Between creation and queueing of a job, you need to prevent any other
job from being created and queued. Otherwise the scheduler's fences
may be signaled out of seqno order.
https://bugzilla.kernel.org/show_bug.cgi?id=199925
--- Comment #2 from Martin (martin...@gmx.com) ---
After adding amdgpu.dc=0 to kernel command line the system hasn't experienced
any crashes and there were no error messages like the ones I mentioned earlier.
--
You are receiving this mail
On 06/04/2018 11:49 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf
The drm_connector_helper_funcs .mode_valid() operation should not modify
the mode it receives in any way. To make this explicit, constify the
mode pointer as done for all other .mode_valid() operations, and update
all drivers accordingly.
Signed-off-by: Laurent Pinchart
---
This patch touches
On Tue, Jun 05, 2018 at 04:40:41PM -0700, Daniel Rosenberg wrote:
> The format specifier %p can leak kernel addresses
> while not valuing the kptr_restrict system settings.
> Use %pK instead of %p, which also evaluates whether
> kptr_restrict is set.
>
> Signed-off-by: Divya Ponnusamy
>
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #1 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Just tested 4.15.15 and 4.16
On 4.15.15 suspend and resume works fine
On 4.16 the system freezes even with amdgpu.dc=0
Note that Arch has
CONFIG_DRM_AMD_DC=y
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #2 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Created attachment 276363
--> https://bugzilla.kernel.org/attachment.cgi?id=276363=edit
Failed resume - 4.16, amdgpu.dc=0
--
You are receiving this mail because:
You are
https://bugzilla.kernel.org/show_bug.cgi?id=199959
Alexander Mezin (mezin.alexan...@gmail.com) changed:
What|Removed |Added
Regression|No |Yes
--
https://bugzilla.kernel.org/show_bug.cgi?id=199959
Alexander Mezin (mezin.alexan...@gmail.com) changed:
What|Removed |Added
Kernel Version|4.17|4.16
--
https://bugs.freedesktop.org/show_bug.cgi?id=106446
--- Comment #5 from Mike Bendel ---
Created attachment 140058
--> https://bugs.freedesktop.org/attachment.cgi?id=140058=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the
On 2018-06-06 03:33 PM, Gabriel C wrote:
2018-06-06 14:19 GMT+02:00 Christian König :
Am 06.06.2018 um 14:08 schrieb Gabriel C:
2018-06-06 13:33 GMT+02:00 Christian König :
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00 Gabriel C :
[6.337838] [drm] PCIE GART of
On Wed, 6 Jun 2018, Alexey Brodkin wrote:
> Hi Mikulas,
>
> On Tue, 2018-06-05 at 11:30 -0400, Mikulas Patocka wrote:
> >
> > On Tue, 5 Jun 2018, Alexey Brodkin wrote:
> >
> > > Hi Mikulas,
> > >
> > > On Sun, 2018-06-03 at 16:41 +0200, Mikulas Patocka wrote:
> > > > Modern processors can
Am 06.06.2018 um 15:33 schrieb Gabriel C:
2018-06-06 14:19 GMT+02:00 Christian König :
Am 06.06.2018 um 14:08 schrieb Gabriel C:
[SNIP]
That has nothing TODO with the driver nor the original bug you reported. The
problem is that SME is active and that is currently not supported at all
with a
On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote:
Hi Archit,
Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja:
On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:
Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
On Monday 04 June 2018 05:47 PM,
On 2018-06-06 04:44 PM, Christian König wrote:
> Am 06.06.2018 um 16:12 schrieb Michel Dänzer:
>> On 2018-06-06 03:33 PM, Gabriel C wrote:
>>> 2018-06-06 14:19 GMT+02:00 Christian König :
Am 06.06.2018 um 14:08 schrieb Gabriel C:
> 2018-06-06 13:33 GMT+02:00 Christian König :
>> Am
Hi,
On 6 June 2018 at 04:50, Dave Airlie wrote:
> First up I've moved the drm tree to a new location on freedesktop.org. The
> main
> reason was to explore using Daniel's maintainer tools (dim-tools) to manage
> pull requests and possibly open the drm to having co-maintainers at the top
> level
This allows panels or bridges that need to send DSI commands during
pre_enable() to successfully send them. We delay DISP0 (aka the
actual display) enabling until after pre_enable so that pixels aren't
streaming before then.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 37
For DSI, we want to pre_enable once the DSI link is up but before
video packets are being sent, and similarly we want to be able to
post_disable while the link is still up but after video has stopped.
Given that with drm_panels we've had issues with drivers missing calls
to one of the hooks,
This makes it more likely that the docs stay updated with the code.
Signed-off-by: Eric Anholt
---
include/drm/drm_bridge.h | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index
Between creation and queueing of a job, you need to prevent any other
job from being created and queued. Otherwise the scheduler's fences
may be signaled out of seqno order.
v2: move mutex unlock to the error label.
Signed-off-by: Eric Anholt
Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM
Marco Felsch writes:
> From: Philipp Zabel
>
> This patch adds support for DLC DLC0700YZG-1 1024x600 LVDS panels
> to the simple-panel driver.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
dri-devel mailing list
https://bugzilla.kernel.org/show_bug.cgi?id=199407
--- Comment #7 from Cm (c...@mailinator.com) ---
I am now running 4.17 (stable), and flickering is far less than it was on any
version of 4.16, but it still happens on occasion.
--
You are receiving this mail because:
You are watching the
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #25 from fox...@ruin.net ---
(In reply to Michel Dänzer from comment #24)
> Created attachment 140046 [details] [review]
> Add some debugging output to amdgpu_sa_bo_new
>
> This patch should tell us which of the WARN_ON_ONCE in
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #26 from Ben Crocker ---
foxbat, thanks for posting this!
> [ 175.501965] [drm] size=167768376 > sa_manager->size=1048576
Well, isn't THAT interesting!
Requested size is ALMOST, but not quite, 160 MB, while what
the
On Wed, Jun 06, 2018 at 05:51:38PM -0400, Boris Ostrovsky wrote:
> On 06/06/2018 08:46 AM, Oleksandr Andrushchenko wrote:
> > On 06/05/2018 01:36 AM, Boris Ostrovsky wrote:
> >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> >>> From: Oleksandr Andrushchenko
> >>>
> >>> Allow creating
Am Mittwoch, 6. Juni 2018, 18:07:46 CEST schrieb Archit Taneja:
>
> On Wednesday 06 June 2018 04:16 PM, Heiko Stübner wrote:
> > Hi Archit,
> >
> > Am Mittwoch, 6. Juni 2018, 12:21:16 CEST schrieb Archit Taneja:
> >> On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:
> >>> Am Mittwoch, 6.
https://bugs.freedesktop.org/show_bug.cgi?id=106446
--- Comment #4 from Mike Bendel ---
tempel.julian:
Yeah I think the artifacts I'm getting 75 Hz are related. I tried creating a
custom resolution @ 70 Hz and the artifacts went away completely without having
to change the performance profile
https://bugzilla.kernel.org/show_bug.cgi?id=199959
Bug ID: 199959
Summary: amdgpu, regression?: system freezes after resume
Product: Drivers
Version: 2.5
Kernel Version: 4.17
Hardware: x86-64
OS: Linux
Tree:
Am 06.06.2018 um 16:12 schrieb Michel Dänzer:
On 2018-06-06 03:33 PM, Gabriel C wrote:
2018-06-06 14:19 GMT+02:00 Christian König :
Am 06.06.2018 um 14:08 schrieb Gabriel C:
2018-06-06 13:33 GMT+02:00 Christian König :
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00
On Tue, Jun 5, 2018 at 8:50 PM Dave Airlie wrote:
>
> First up I've moved the drm tree to a new location on freedesktop.org. The
> main
> reason was to explore using Daniel's maintainer tools (dim-tools) to manage
> pull requests and possibly open the drm to having co-maintainers at the top
>
On 06/07/2018 12:09 AM, Boris Ostrovsky wrote:
On 06/06/2018 03:24 AM, Oleksandr Andrushchenko wrote:
On 06/04/2018 07:37 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
diff --git a/include/xen/mem-reservation.h
b/include/xen/mem-reservation.h
new file mode
On 06.06.2018 21:04, Eric Anholt wrote:
> This makes it more likely that the docs stay updated with the code.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> include/drm/drm_bridge.h | 22 --
> 1 file changed, 12 insertions(+), 10
97 matches
Mail list logo
