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 bindings for DSI host controllers that may
be configured in this mode. Add an
https://bugs.freedesktop.org/show_bug.cgi?id=106827
--- Comment #2 from Paul Fertser ---
As an additional datapoint, DRI (non-Gallium) driver from the same tree works
without problems.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=106533
--- Comment #12 from Marek Olšák ---
17.x branches are no longer supported (and 18.0 is uncertain). Users and
distros are encouraged to switch to Mesa 18.1 if they want to obtain future
fixes.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=106289
--- Comment #3 from Anthony Ciani ---
Check out bug 106533. It was also a SEGV in llvm_pipeline_generic. There is a
patch.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=106533
--- Comment #11 from Anthony Ciani ---
Thanks. That patch resolved the issue with clear_with_quad and Cinnamon as
well.
While I was looking at the source, I did notice that many of the functions
assumed that their inputs were valid. I was
Remove hand rolled msm property caching to handle DPU
custom properties. This change also cleans up all its
dependencies to cache and restore respective drm
states.
changs in v2:
- none
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/Makefile
remove unwanted dpu uapi headers exposing custom
payload layouts for custom properties
changs in v2:
- none
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 1 -
Enable drm core zpos normalization for planes.
changes in v2:
- none
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/msm_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index
Replace custom plane zpos property with drm core zpos
property. CRTC relies on the normalized zpos values
to configure blend stages of each plane.
changes in v2:
- Move out unrelated changes in plane init (Sean Paul)
Signed-off-by: Jeykumar Sankaran
---
Remove dpu crtc custom properties and its handlers.
changes in v2:
- none
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/Makefile | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 28 -
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
Cleanup residual connector property enumerations.
changs in v2:
- none
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/msm_drv.h | 27 ---
1 file changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h
Submitting a series of patches to further clean up DPU driver by stripping
down a list of custom properties supporting proprietary features. It
removes the property installers/handlers and cleans up relevant files of
of some of the advanced features. This series is based on the patch[1]
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
> atmel-hclcdc.
>
> drm-misc-next-2018-04-26:
> drm-misc-next
https://bugs.freedesktop.org/show_bug.cgi?id=106788
--- Comment #2 from Ming-Wei Shih ---
Created attachment 140041
--> https://bugs.freedesktop.org/attachment.cgi?id=140041=edit
dmesg ouput
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=106533
Marek Olšák changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #13 from udo ---
Thanks.
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
?
LLVM is at 6.0.0, it it the fedora 28 llvm.
I should switch to
Qualcomm Snapdragon chipsets uses compressed format
to optimize BW across multiple IP's. This change adds
needed modifier support in drm for a simple 4x4 tile
based compressed variants of base formats.
Signed-off-by: Jeykumar Sankaran
---
include/uapi/drm/drm_fourcc.h | 13 +
1 file
Quoting Daniel Rosenberg (2018-06-06 00:40:41)
> 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.
This is backwards though. You never care about the actual value
https://bugs.freedesktop.org/show_bug.cgi?id=106287
--- Comment #7 from Henrik Holst ---
BTW if there are any mesa devs out there with a Radeon RX and that is willing
to try and find how to fix this I'm willing to gift a copy of Dying Light.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=106287
--- Comment #6 from Henrik Holst ---
Sounds almost like a locking issue / racing condition then. Almost looks like
we have to try and compile mesa ourselves to figure out which patch to 18.0.1
that broke it and why 18.0.3 fixed it while 18.1.0
On Tue, Jun 05, 2018 at 11:10:15AM +0530, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
>
> This chip can be controlled via either i2c interface or
> dsi interface.
On Tue, Jun 05, 2018 at 04:47:15PM +0530, Vinod wrote:
> On 05-06-18, 11:10, Sandeep Panda wrote:
> > Add support for TI's sn65dsi86 dsi2edp bridge chip.
> > The chip converts DSI transmitted signal to eDP signal,
> > which is fed to the connected eDP panel.
> >
> > This chip can be controlled
On Tue, Jun 05, 2018 at 11:10:17AM +0530, Sandeep Panda wrote:
> Add support for Innolux TV123WAM, which is a 12.3" eDP
> display panel with 2160x1440 resolution.
>
> Changes in v1:
> - Add the compatibility string, display_mode and panel_desc
>structures in alphabetical order (Sean Paul).
>
https://bugs.freedesktop.org/show_bug.cgi?id=106827
--- Comment #1 from Paul Fertser ---
Ok, recompiling this file with -O makes the issue a bit clearer:
0x09de52ae in validate_program (i915=0xd402bb0, batch_space=0xbe9c8308)
at ../../../../../src/gallium/drivers/i915/i915_state_emit.c:431
Add support for the R-Car V3H (R8A77980) SoC to the LVDS encoder driver.
Signed-off-by: Sergei Shtylyov
---
drivers/gpu/drm/rcar-du/rcar_lvds.c |1 +
1 file changed, 1 insertion(+)
Index: drm/drivers/gpu/drm/rcar-du/rcar_lvds.c
Document the R-Car V3H (R8A77980) SoC in the R-Car LVDS bindings.
Signed-off-by: Sergei Shtylyov
---
Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt |1 +
1 file changed, 1 insertion(+)
Index: drm/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
Hello!
Here's the set of 2 patches against the 'drm-next' branch of the 'drm.git' repo.
The purpose of these patches is to add the R-Car V3H (R8A77980) support to the
R-Car LVDS driver.
[1/2] dt-bindings: display: renesas: lvds: document R8A77980 bindings
[2/2] drm: rcar-du: lvds: add R8A77980
Hi Sergei,
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 in the R-Car V3M (R8A77970).
> >>>
> >>> How about "the DU
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 in the R-Car V3M (R8A77970).
>>>
>>> How about "the DU hardware has the same topology as in the R-Car V3M
>>> (R8A77970)" ? "seems" sounds
On 2018-06-04 12:53, Sean Paul wrote:
On Wed, May 23, 2018 at 12:30:57PM -0700, Jeykumar Sankaran wrote:
This change removes all the dpu plane custom properties
and its handlers.
Signed-off-by: Jeykumar Sankaran
---
Makefile |2 +-
Hi Sergei,
On Tuesday, 5 June 2018 21:57:47 EEST Sergei Shtylyov wrote:
> On 06/05/2018 01:09 PM, Laurent Pinchart 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).
> >
> > How about "the DU hardware
On 2018-06-04 03:35 PM, Lyude Paul wrote:
> So, unfortunately I recently made the discovery that in the upstream
> kernel, the only reason that amdgpu is not currently suffering from
> issues with runtime PM putting the GPU into suspend while it's driving
> displays is due to the fact that on most
Since our seqno value comes from a counter associated with the GPU
ring, not the entity (aka client), they'll be completed out of order.
There's actually no need for this code at all, since we don't have
enable_signaling() and thus DMA_FENCE_SIGNALED_BIT will be set before
we could be called.
This isn't the first time I've had to argue to myself why the '++' was
safe.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_fence.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_fence.c b/drivers/gpu/drm/v3d/v3d_fence.c
index bfe31a89668b..6265e9ab4a13
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: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D
V3.x+")
---
ccing
On 06/05/2018 01:09 PM, Laurent Pinchart 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).
>
> How about "the DU hardware has the same topology as in the R-Car V3M
> (R8A77970)" ? "seems" sounds like we're
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 transactions inside of them.
>>
>> Signed-off-by:
Author: Nitin U. Yewale
Date: Mon Jun 4 23:28:41 2018 +0530
Changing comment for the list_empty routine.
---
Signed-off-by: Nitin U. Yewale
diff --git a/drivers/gpu/drm/nouveau/include/nvif/list.h
b/drivers/gpu/drm/nouveau/include/nvif/list.h
index 8af5d144ecb0..12bf7ee4 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=106827
Bug ID: 106827
Summary: Segmentation fault in i915_validate_state on
SolveSpace startup
Product: Mesa
Version: git
Hardware: x86 (IA32)
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=106287
--- Comment #5 from stu...@gmail.com ---
Adding more, barely useful information.
Sometimes, I can start the game and the issues aren't there. Sometimes I
start the game and they are there. It's apparent at the start (the menu screen
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #23 from fox...@ruin.net ---
(In reply to Michel Dänzer from comment #22)
> (In reply to foxbat from comment #21)
> > [ 75.701323] NIP [c0081748cd08] amdgpu_sa_bo_new+0x640/0x6c0 [amdgpu]
>
> What does
>
> scripts/faddr2line
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Dhinakaran Pandiyan
commit bdcc02cf1bb508fc700df7662f55058f651f2621 upstream.
Entry corresponding to 220 us setup time was missing. I am not aware of
any specific bug this fixes, but this
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()
Signed-off-by: Andrey Grodzovsky
Suggested-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
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.
Signed-off-by: Andrey Grodzovsky
Suggested-by: Christian
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #12 from Michel Dänzer ---
Per https://bugs.freedesktop.org/show_bug.cgi?id=105251#c9 , make sure you have
current microcode and LLVM
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105300
--- Comment #14 from tempel.jul...@gmail.com ---
73Hz + dynamic clocking work again with recent drm-next-4.19-wip build.
As a sidenote: On Windows (which is installed on the same system as a 2nd OS),
there has never been an issue with 75Hz
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #22 from Michel Dänzer ---
(In reply to foxbat from comment #21)
> [ 75.701323] NIP [c0081748cd08] amdgpu_sa_bo_new+0x640/0x6c0 [amdgpu]
What does
scripts/faddr2line drivers/gpu/drm/amd/amdgpu/amdgpu.ko
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #21 from fox...@ruin.net ---
I am still getting amdgpu crashes on POWER9 (ppc64le) using the latest AMD
firmware and on kernel 4.17 (release). My card is a WX5100 - Polaris 10. I can
reliably reproduce this by having spectacle
(cc: drm-misc maintainers)
Den 04.06.2018 03.21, skrev David Lechner:
On 6/3/18 5:00 PM, Noralf Trønnes wrote:
Den 25.05.2018 21.36, skrev David Lechner:
This series adds a new tinydrm driver for the Ilitek ILI9341
controller and
a 2.4" display panel that uses this controller.
David,
https://bugs.freedesktop.org/show_bug.cgi?id=106228
--- Comment #3 from Daniel Drake ---
Do you have any specific debugging suggestions?
Can we ship an affected laptop to you for diagnosis?
--
You are receiving this mail because:
You are the assignee for the
On Tue, 5 Jun 2018, Alexey Brodkin wrote:
> 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
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 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
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 missing dt-binding that are parsed
Thanks to all the hooks in drm structure, custom debugfs could be
removed of sti driver.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drv.c | 50 ---
1 file changed, 50 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_drv.c
Convert all sti encoders to atomic_print usage rather than use a
debugfs entry.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_tvout.c | 162
1 file changed, 63 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_tvout.c
Convert sti crtc to atomic_print_state usage rather than use a
debugfs entry.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_compositor.c | 16 ---
drivers/gpu/drm/sti/sti_compositor.h | 3 --
drivers/gpu/drm/sti/sti_crtc.c | 17 ---
drivers/gpu/drm/sti/sti_mixer.c
Convert all sti connectors to atomic_print_state usage rather than
use a debugfs entry.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_dvo.c | 60 +--
drivers/gpu/drm/sti/sti_hda.c | 75 +++
drivers/gpu/drm/sti/sti_hdmi.c | 132
Thanks to the various atomic_print_state hooks in drm structure all
custom debugfs code could be remove from sti driver (~ -330 lines).
This patchset does two addtion in drm core:
- printing normalized zpos of each plane
- add "atomic_print" hook in encoder structure to be able to dump encoders
Even if encoders don't have state it could be useful to get information
from them when dumping of the other elements state.
Add an optional hook in drm_encoder_funcs structure and call it after crtc
print state.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/drm_atomic.c | 15
When dumping plane state print normalized zpos value as done for
the other plane state fields.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/drm_atomic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index
Convert all sti planes to atomic_print_state usage rather than use a debugfs
entry.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_cursor.c | 65 +
drivers/gpu/drm/sti/sti_gdp.c| 196 +--
drivers/gpu/drm/sti/sti_hqvdp.c | 149
Hi,
Am Mittwoch, 23. Mai 2018, 09:42:29 CEST schrieb Lin Huang:
> From: Chris Zhong
>
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
>
> Signed-off-by: Chris Zhong
> Signed-off-by: Lin Huang
>
On Tue, Jun 05, 2018 at 03:51:28PM +0300, Laurent Pinchart wrote:
> The mode_valid_path() function validates the mode it receives without
> ever modifying it. Constify the mode pointer argument to make that
> explicit.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Ville Syrjälä
> ---
>
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 other Allwinner SOC's
> >> A83T/H3/H5.
> >>
> >> A64 behaviour
On Thu, May 31, 2018 at 2:11 PM, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used instead of open coded variant.
>
Reviewed-by: Andy Shevchenko
> Cc: David Airlie
> Cc: Yisheng Xie
> Cc: Daniel Vetter
> Cc: Arvind Yadav
> Cc:
On Thu, May 31, 2018 at 2:11 PM, Yisheng Xie wrote:
> match_string() returns the index of an array for a matching string,
> which can be used instead of open coded variant.
>
Reviewed-by: Andy Shevchenko
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> Cc:
The mode_valid_path() function validates the mode it receives without
ever modifying it. Constify the mode pointer argument to make that
explicit.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=105046
--- Comment #13 from Lothar Paltins ---
Created attachment 140032
--> https://bugs.freedesktop.org/attachment.cgi?id=140032=edit
dmesg output after amdgpu crash
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105046
--- Comment #12 from Lothar Paltins ---
I've got the same issue with an AMD Ryzen 5 2400G after a power cycle of the
monitor (Dell U3011 with a resolution of 2560x1600 connected via DisplayPort).
It happened not always, but very often. I
On 05-06-18, 11:10, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
>
> This chip can be controlled via either i2c interface or
> dsi interface. Currently in driver all
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 headers to ease license compliance
> >> management.
> >>
> >>
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 Serra
> ---
>
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 24
Hi Sergei,
Thank you for the patch.
On Monday, 4 June 2018 22:04:59 EEST 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).
How about "the DU hardware has the same topology as in the R-Car V3M
https://bugs.freedesktop.org/show_bug.cgi?id=106589
Michel Dänzer changed:
What|Removed |Added
Resolution|FIXED |INVALID
--
You are receiving this
On Mon, Jun 04, 2018 at 02:49:26PM +0100, Emil Velikov wrote:
> On 1 June 2018 at 13:41, Lowry Li wrote:
> > Pixel blend modes represent the alpha blending equation
> > selection, describing how the pixels from the current
> > plane are composited with the background.
> >
> > Add a
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #10 from Christian König ---
Hi everybody,
first of all please add logs as attachments and not inline into the bug report.
Then make sure that the firmware files are up to date. It looks like we
accidentally released corrupted
https://bugzilla.kernel.org/show_bug.cgi?id=199925
Martin (martin...@gmx.com) changed:
What|Removed |Added
CC||martin...@gmx.com
---
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 transactions inside of them.
>
> Signed-off-by: Eric Anholt
> Cc: Kevin
Changes in current patchset:
- Moved dsi register/attach function to bridge probe.
- Renames and added more description to lane-mapping dt property.
- Removed some unnecessary headers/macros from driver.
Sandeep Panda (4):
drm/bridge: add support for sn65dsi86 bridge driver
dt-bindings:
Changes in current patchset:
- Moved dsi register/attach function to bridge probe.
- Renames and added more description to lane-mapping dt property.
- Removed some unnecessary headers/macros from driver.
Sandeep Panda (4):
drm/bridge: add support for sn65dsi86 bridge driver
dt-bindings:
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 from buffers allocated with
> dma_alloc_xxx.
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> /* -- */
>
> +static int
> +dmabuf_imp_grant_foreign_access(struct page **pages, u32 *refs,
> + int count, int domid)
> +{
> + grant_ref_t
Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.
Changes in v1:
- Add the compatibility string, display_mode and panel_desc
structures in alphabetical order (Sean Paul).
Signed-off-by: Sandeep Panda
---
drivers/gpu/drm/panel/panel-simple.c |
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c
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 module.
Can you give an example of who'd be
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 GNTDEV_DMA_FLAG_XXX flags it can also be created
>
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 missing dt-binding that are parsed by corresponding driver
(Andrzej Hajda).
Changes in v2:
- Remove edp
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 buffer is similar to the one allocated
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 implementation. With this extension grant
>
Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.
Changes in v1:
- Make use of simple panel driver instead of creating
a new driver for this panel (Sean Paul).
- Combine dt-binding and driver changes into one patch
as
Am 04.06.2018 um 21:35 schrieb Lyude Paul:
So, unfortunately I recently made the discovery that in the upstream
kernel, the only reason that amdgpu is not currently suffering from
issues with runtime PM putting the GPU into suspend while it's driving
displays is due to the fact that on most
91 matches
Mail list logo
