On 04/25/2018 08:16 PM, Dongwon Kim wrote:
On Wed, Apr 25, 2018 at 08:34:55AM +0200, Daniel Vetter wrote:
On Wed, Apr 25, 2018 at 09:07:07AM +0300, Oleksandr Andrushchenko wrote:
On 04/24/2018 11:35 PM, Dongwon Kim wrote:
Had a meeting with Daniel and talked about bringing out generic
part of
https://bugs.freedesktop.org/show_bug.cgi?id=91808
--- Comment #13 from Dave Airlie ---
Just adding some things I've tried to fix this to no avail.
use RECIP_FF/CLAMPED instead of RECIP_IEEE
use RECIPSQRT_FF/CLAMPED instead of RECIPSQRT_IEEE
use MUL/MULADD/DOT4 instead of IEEE
Split constants i
dma_fence_default_wait is the default now.
Signed-off-by: Daniel Vetter
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fenc
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Also remove the ->signaled callback, vgem can't peek ahead with a
fastpath, returning false is the default implementation.
Signed-off-by: Daniel Vetter
Cc: Kees Cook
Cc: Cihangir Akturk
Cc: Sean Pa
- Intro section that links to how this is exposed to userspace.
- Lots more hyperlinks.
- Minor clarifications and style polish
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
Documentation/driver-api/dma-
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 7 ---
1 file changed, 7 deletions(-)
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Colin Ian King
Cc: Daniel Vetter
Cc: Mika Kuoppala
Cc: intel-...@lists
It's a copy of dma_fence_default_wait, written slightly differently.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/radeon/radeon_fence.c | 63 ---
1 file changed, 63
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
---
drivers/gpu/drm/msm/msm_fence.c | 7 ---
1 file changed, 7 deletions(-)
diff
When this was introduced in
commit a519435a96597d8cd96123246fea4ae5a6c90b02
Author: Christian König
Date: Tue Oct 20 16:34:16 2015 +0200
dma-buf/fence: add fence_wait_any_timeout function v2
there was a restriction added that this only works if the dma-fence
uses the dma_fence_default_wai
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_fence.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_fence.c b/drivers/gpu/drm/vc4/vc4_f
Many drivers have a trivial implementation for ->enable_signaling.
Let's make it optional by assuming that signalling is already
available when the callback isn't present.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.l
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
---
drivers/gpu/drm/qxl/qxl_release.c | 7 ---
1 file changed, 7 deletions(-)
diff
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
Cc: etna...@lists.freedesktop.org
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 ---
1 file changed, 7 delet
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Signed-off-by: Daniel Vetter
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
---
drivers/gpu/drm/drm_crtc.c | 7 ---
drivers/gpu/drm/drm_syncobj.c
dma_fence_default_wait is the default now.
Signed-off-by: Daniel Vetter
Cc: Alex Deucher
Cc: "Christian König"
Cc: Monk Liu
Cc: pding
Cc: Andrey Grodzovsky
Cc: Evan Quan
Cc: Daniel Vetter
Cc: Kees Cook
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 2 --
drivers/gpu/drm/amd/amdgp
Hi all,
Somewhat motivated by me looking at the v3d patch I went and dug around
in the dma-fence code a bit. Result was a bit of doc polish and making a
bunch of callbacks optional for cases where most implementations wanted
the same default behaviour.
Comments, testing, feedback very much welcom
- Switch to inline member docs for dma_fence_ops.
- Mild polish all around.
- hyperlink all the things!
v2: - Remove the various [in] annotations, they seem really uncommon
in kerneldoc and look funny.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-.
Noticed while I was typing docs. Entirely unused.
Signed-off-by: Daniel Vetter
---
include/linux/dma-fence.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 9d6f39bf2111..f9a6848f8558 100644
--- a/include/linux/dma-fence.
Almost everyone uses dma_fence_default_wait.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-fence-array.c | 1 -
drivers/dma-buf/dma-fence.c | 5 -
drivers/dma-buf/sw_sync.
Hi Linus,
Pretty run of the mill for this stage in the cycle.
i915:
- Black screen fixes
- Display w/a fix
- HDA codec interop fix
sun4i:
- tbsa711 tablet regression fix
qxl:
- Regression fixes due to changes in TTM
virtio:
- Fix wait event condition
msm:
- DSI display fixes
amdgpu:
- fix hang on
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
commit: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6 [9/9] RFC: debugobjects:
capture stack traces at _init() time
config: m68k-allyesconfig (attached as .config)
compiler: m68k-linux-gnu
On Wed, Apr 25, 2018 at 08:46:13PM -0400, Rob Clark wrote:
> On Wed, Apr 25, 2018 at 7:45 PM, Stephen Boyd wrote:
> > Quoting Sandeep Panda (2018-04-19 10:56:06)
> >> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
> >>
> >> Changes in v1:
> >> - Rephrase the dt-binding descriptio
On 2018年04月26日 23:06, Michel Dänzer wrote:
From: Michel Dänzer
When it's set, TTM tries to allocate huge pages if possible.
Do you mean original driver doesn't do this?
From the code, driver always try huge pages if
CONFIG_TRANSPARENT_HUGEPAGE is enabled.
Regards,
David Zhou
Drivers
wh
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: a11008ca87d737a3b1ffbe7f32af7d74d78a9aa8
commit: c4d9e2ed68bb9380ebd75916b28addcbc460c24f [31/33] drm/amd/powerplay: add
smumgr support for VEGAM (v2)
reproduce:
# apt-get install sparse
git checkout
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: a11008ca87d737a3b1ffbe7f32af7d74d78a9aa8
commit: 2493ccc491879761baffb7a66a7bbb86b3cff7ad [29/33] drm/amd/powerplay:
update ppatomctrl.c (v2)
reproduce:
# apt-get install sparse
git checkout 2493ccc4
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6
commit: 1bb5f7fce1fe95fb9a9a9a23845b286ca47c9ed6 [9/9] RFC: debugobjects:
capture stack traces at _init() time
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gnu
Hi Luc,
Thank you for the patch.
On Tuesday, 24 April 2018 16:14:52 EEST Luc Van Oostenryck wrote:
> The method struct drm_connector_helper_funcs::mode_valid is defined
> as returning an 'enum drm_mode_status' but the driver implementation
> for this method uses an 'int' for it.
>
> Fix this by
Hi Peter,
On Friday, 27 April 2018 02:09:14 EEST Peter Rosin wrote:
> On 2018-04-27 00:40, Laurent Pinchart wrote:
> > On Friday, 27 April 2018 01:31:15 EEST Peter Rosin wrote:
> >> Hi!
> >>
> >> It was noted by Russel King [1] that bridges (not using components)
> >> might disappear unexpectedly
https://bugs.freedesktop.org/show_bug.cgi?id=106263
--- Comment #1 from erhar...@mailbox.org ---
Created attachment 139157
--> https://bugs.freedesktop.org/attachment.cgi?id=139157&action=edit
journalctl -k (kernel 4.16.5)
--
You are receiving this mail because:
You are the assignee for the bu
https://bugs.freedesktop.org/show_bug.cgi?id=106263
erhar...@mailbox.org changed:
What|Removed |Added
Version|XOrg git|unspecified
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=106263
Bug ID: 106263
Summary: amdgpu produces several stracktraces (Fiji, Bonaire)
at boot since kernel 4.16.4
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #5 from Francisco Pina Martins ---
Created attachment 139154
--> https://bugs.freedesktop.org/attachment.cgi?id=139154&action=edit
journaltcl log file with KASAN enabled in kernel
I have compiled a new kernel with KASAN module ena
Hi Geert,
Thank you for the patch.
On Wednesday, 25 April 2018 10:49:38 EEST Geert Uytterhoeven wrote:
> Fixes: 14da3ed8dd08c581 ("devicetree/bindings: display: Document common
> panel properties")
> Signed-off-by: Geert Uytterhoeven
Reviewed-by: Laurent Pinchart
> ---
> Documentation/device
https://bugs.freedesktop.org/show_bug.cgi?id=106260
--- Comment #3 from ojab ---
DVI monitor is connected to HDMI port via HDMI->DVI adapter, if it matters.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
Hi Peter,
Thank you for the patches.
On Friday, 27 April 2018 01:31:15 EEST Peter Rosin wrote:
> Hi!
>
> It was noted by Russel King [1] that bridges (not using components)
> might disappear unexpectedly if the owner of the bridge was unbound.
> Jyri Sarha had previously noted the same thing wit
https://bugs.freedesktop.org/show_bug.cgi?id=106260
--- Comment #2 from ojab ---
Created attachment 139151
--> https://bugs.freedesktop.org/attachment.cgi?id=139151&action=edit
Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=106260
--- Comment #1 from ojab ---
Created attachment 139150
--> https://bugs.freedesktop.org/attachment.cgi?id=139150&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=106260
Bug ID: 106260
Summary: raven ridge (2400g) shows artifacts instead in xorg
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: norm
Hi Jia-Ju,
Thank you for the patch.
On Wednesday, 11 April 2018 11:33:42 EEST Jia-Ju Bai wrote:
> adv7511_probe() is never called in atomic context.
> This function is only set as ".probe" in struct i2c_driver.
>
> Despite never getting called from atomic context, adv7511_probe()
> calls mdelay(
Hi Peter,
Thank you for the patch.
On Friday, 27 April 2018 00:36:44 EEST Peter Rosin wrote:
> Could perhaps prevent some confusion.
>
> Signed-off-by: Peter Rosin
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/adv7511/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deleti
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #4 from Matt Corallo ---
Oops, looks like we got our wires crossed on what has and hasn't been tested.
It only *may* be PAGE_SIZE related, but seems relevant 3d stuff was never
tested on PPC64LE with 4K pages, only 64K.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #3 from Timothy Pearson ---
(In reply to Timothy Pearson from comment #1)
> This also affects the WX7100, same symptoms. Shows up as soon as an OpenGL
> application tries to use the accelerated graphics. Kernel 4.16.
On our end Ur
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #2 from Matt Corallo ---
Oops, forgot to specify this is on a WX4100.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.f
https://bugs.freedesktop.org/show_bug.cgi?id=106259
Bug ID: 106259
Summary: [bisected] UVD hangs system on Vega10 linux-4.17
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=106258
--- Comment #1 from Timothy Pearson ---
This also affects the WX7100, same symptoms. Shows up as soon as an OpenGL
application tries to use the accelerated graphics. Kernel 4.16.
--
You are receiving this mail because:
You are the assignee f
https://bugs.freedesktop.org/show_bug.cgi?id=106258
Bug ID: 106258
Summary: AMD Xorg start failes with non-4K page sizes
Product: DRI
Version: unspecified
Hardware: PowerPC
OS: All
Status: NEW
Severity: no
/commits/Thierry-Reding/drm-nouveau-tegra-Detach-from-ARM-DMA-IOMMU-mapping/20180426-140854
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
Hi Kieran,
Thank you for the patch.
On Thursday, 26 April 2018 19:53:36 EEST Kieran Bingham wrote:
> The R8A77965 (M3-N) SoC provides VGA, HDMI and LVDS output.
>
> This platform is unusual in that the VGA is connected to DU3 leaving DU2
> unpopulated. This is reflected by the channel_mask accor
Hi Kieran,
Thank you for the patch.
On Thursday, 26 April 2018 19:53:35 EEST Kieran Bingham wrote:
> The group objects assume linear indexing, and more so always assume that
> channel 0 of any active group is used.
>
> Now that the CRTC objects support non-linear indexing, adapt the groups
> to
Hi Kieran,
Thank you for the patch.
On Thursday, 26 April 2018 19:53:34 EEST Kieran Bingham wrote:
> The DU CRTC driver does not support distinguishing between a hardware
> index, and a software (CRTC) index in the event that a DU channel might
> not be populated by the hardware.
>
> Support thi
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #55 from i...@yahoo.com ---
(In reply to MirceaKitsune from comment #54)
> But there's a bizarre twist this time: When playing back the trace generated
> by Blender, my system will freeze at various points during the replay!
> Sometim
Hi Kieran,
Thank you for the patch.
On Thursday, 26 April 2018 19:53:33 EEST Kieran Bingham wrote:
> The naming of the fields for the ODPM signals in the DU extensional
> function control register 6 (DEFR6) is incorrect against the data sheets
> for both R-Car Gen2 and R-Car Gen3.
>
> Rename the
Hi Kieran,
Thank you for the patch.
On Thursday, 26 April 2018 19:57:32 EEST Kieran Bingham wrote:
> Ahem - this one seems to have lost it's commit message.
>
> Apologies :)
Apart from that, this looks good to me.
Reviewed-by: Laurent Pinchart
and applied to my tree with the commit message
Hi Kieran,
Thank you for the patch.
On Thursday, 26 April 2018 19:53:30 EEST Kieran Bingham wrote:
> The DU output table lists the port combinations for each supported DU
> type. Newer models of R-Car Gen3 platforms have an increased string
> length.
>
> Increase the table indentation in prepar
https://bugs.freedesktop.org/show_bug.cgi?id=106199
Konrad Wojtoń changed:
What|Removed |Added
CC||kondzi...@gmail.com
--- Comment #3 from
Hi Jacopo,
On Thursday, 26 April 2018 21:40:56 EEST jacopo mondi wrote:
> On Mon, Apr 23, 2018 at 12:27:39PM +0300, Laurent Pinchart wrote:
> > On Thursday, 19 April 2018 12:31:02 EEST Jacopo Mondi wrote:
> >> Add support for storing image format information in DRM bridges with
> >> associated hel
Add support for Three Five displays TFC S9700RTWV43TR-01B 800x480
panel with resistive touch found on TI's AM335X-EVM.
Signed-off-by: Jyri Sarha
Reviewed-by: Tomi Valkeinen
cc: Thierry Reding
---
Thanks Thierry, for reminding me about this!
Changes since v4:
- Add tfc to vendor-prefixes.txt
https://bugs.freedesktop.org/show_bug.cgi?id=105284
--- Comment #10 from Harry Wentland ---
No worries. Don't hesitate to open a new ticket if your warning/error log seems
to indicate amdgpu. I'd be happy to take a brief look.
Even if I won't have time to provide an immediate fix it will still a
This patch is:
Acked-by: Robert Foss
On 04/26/2018 09:05 PM, John Stultz wrote:
The drm_hwcomposer has its own GL pre-compositor which is used
to squish layers when there are more layers then planes on the
display hardware. In many ways this duplicates the client-side
GL compositing that is do
https://bugs.freedesktop.org/show_bug.cgi?id=105284
--- Comment #9 from Jon ---
(In reply to Harry Wentland from comment #8)
> (In reply to Jon from comment #7)
> > (In reply to Harry Wentland from comment #6)
> > > Marking resolved as no longer an issue on recent mainline.
> >
> > Which commit
This patch is:
Acked-by: Robert Foss
On 04/26/2018 09:05 PM, John Stultz wrote:
When enabling Treble, Android builds are complaining about using
cutils/log.h so instead use log/log.h
Cc: Marissa Wall
Cc: Sean Paul
Cc: Dmitry Shmidt
Cc: Robert Foss
Cc: Matt Szczesiak
Cc: Liviu Dudau
Cc:
This patch is:
Acked-by: Robert Foss
On 04/26/2018 09:05 PM, John Stultz wrote:
From: Sumit Semwal
To allow drm_hwcomposer to build with Treble, set
the libdrmhwc_utils library as a vendor module.
Cc: Marissa Wall
Cc: Sean Paul
Cc: Dmitry Shmidt
Cc: Robert Foss
Cc: Matt Szczesiak
Cc: Li
No functional changes in this patch.
The SDP Header is a generic header for secondary data packets for
both eDP and DP so call it dp_sdp_header. This header gets used for
different SDP types already defined.
Also header bytes 2 and 3 are secondary data packet specific header bytes.
So change the c
When enabling Treble, Android builds are complaining about using
cutils/log.h so instead use log/log.h
Cc: Marissa Wall
Cc: Sean Paul
Cc: Dmitry Shmidt
Cc: Robert Foss
Cc: Matt Szczesiak
Cc: Liviu Dudau
Cc: David Hanna
Cc: Rob Herring
Cc: Alexandru-Cosmin Gheorghe
Cc: Alistair Strachan
S
If the gl precompositor isn't being used, we cannot accept
every layer as a device composited layer.
Thus this patch adds some extra logic in the validate function
to fall back to client side compositing if the gl precompositor
did not initialize properly.
This does force everything to a single p
From: Sumit Semwal
To allow drm_hwcomposer to build with Treble, set
the libdrmhwc_utils library as a vendor module.
Cc: Marissa Wall
Cc: Sean Paul
Cc: Dmitry Shmidt
Cc: Robert Foss
Cc: Matt Szczesiak
Cc: Liviu Dudau
Cc: David Hanna
Cc: Rob Herring
Cc: Alexandru-Cosmin Gheorghe
Cc: Alis
The drm_hwcomposer has its own GL pre-compositor which is used
to squish layers when there are more layers then planes on the
display hardware. In many ways this duplicates the client-side
GL compositing that is done in SurfaceFlinger, but in theory can
be more highly optimized for the hardware.
U
Hi Peter,
On Sun, Apr 22, 2018 at 10:02:23PM +0200, Peter Rosin wrote:
> On 2018-04-19 11:31, Jacopo Mondi wrote:
> > Add support for storing image format information in DRM bridges with
> > associated helper function.
> >
> > This patch replicates for bridges what 'drm_display_info_set_bus_format
Hi Laurent,
On Mon, Apr 23, 2018 at 12:27:39PM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Thursday, 19 April 2018 12:31:02 EEST Jacopo Mondi wrote:
> > Add support for storing image format information in DRM bridges with
> > associated helper function.
> >
> >
On 2018-04-26 10:46 AM, sunpeng...@amd.com wrote:
> From: "Leo (Sunpeng) Li"
>
> The lines were removed as part of the original change. They may have
> been missed during merge.
>
> This is a fixup to:
>
> committ 265083076187e619aa9176aeb05ad630013429b4
> Author: Leo (Sunpeng) Li
>
https://bugs.freedesktop.org/show_bug.cgi?id=106193
--- Comment #10 from Harry Wentland ---
Thanks for reporting, testing, and quick feedback. It's greatly appreciated.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-d
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head: 92fb37464bd2b759d74f33c3b90a27575601745d
commit: b5f9f0f4bd3b061c10899d66a9d8d7d8e7e6bbd0 [259/261] drm/amd/powerplay:
add smumgr support for VEGAM (v2)
config: i386-randconfig-a0-201816 (attached as .config)
compiler:
Ahem - this one seems to have lost it's commit message.
Apologies :)
--
Kieran
On 26/04/18 17:53, Kieran Bingham wrote:
> Signed-off-by: Kieran Bingham
> ---
> Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/de
Signed-off-by: Kieran Bingham
---
Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
b/Documentation/devicetree/bindings/display/renesas,du.txt
index a36a6e7ee54f..7c6854bd0a04 10
The group objects assume linear indexing, and more so always assume that
channel 0 of any active group is used.
Now that the CRTC objects support non-linear indexing, adapt the groups
to remove assumptions that channel 0 is utilised in each group by using
the channel mask provided in the device st
The R8A77965 (M3-N) SoC provides VGA, HDMI and LVDS output.
This platform is unusual in that the VGA is connected to DU3 leaving DU2
unpopulated. This is reflected by the channel_mask accordingly.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 29 +
The naming of the fields for the ODPM signals in the DU extensional
function control register 6 (DEFR6) is incorrect against the data sheets
for both R-Car Gen2 and R-Car Gen3.
Rename the fields to match the datasheet.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_group.c |
The DU CRTC driver does not support distinguishing between a hardware
index, and a software (CRTC) index in the event that a DU channel might
not be populated by the hardware.
Support this by adapting the rcar_du_device_info structure to store a
bitmask of available channels rather than a count of
The DU output table lists the port combinations for each supported DU
type. Newer models of R-Car Gen3 platforms have an increased string
length.
Increase the table indentation in preparation for supporting new target
types.
Signed-off-by: Kieran Bingham
---
.../bindings/display/renesas,du.txt
https://bugs.freedesktop.org/show_bug.cgi?id=106193
Joel Sass changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.18-wip
head: 92fb37464bd2b759d74f33c3b90a27575601745d
commit: 414643871e4c144d7a7a41d14d889fe32089f0e0 [257/261] drm/amd/powerplay:
update ppatomctrl.c (v2)
config: i386-randconfig-a0-201816 (attached as .config)
compiler: gcc-4.9
Hi,
On Thu, Apr 26, 2018 at 5:05 AM, Thierry Reding
wrote:
> If you've got an EDID you should be relying on the EDID to provide the
> timings. No need to have any timings in the DT in that case.
The problem that's specifically trying to be solved by Sean's series
is when we have to use timings o
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #54 from MirceaKitsune ---
I have some very interesting results from today: As instructed, I used the
latest version of apitrace. I cloned it straight from its Github repository and
compiled it myself, then ran Xonotic through it.
h
On Thu, Apr 26, 2018 at 04:21:04PM +0200, Daniel Vetter wrote:
> On Thu, Apr 26, 2018 at 03:58:53PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Building the driver in a configuration with !PM currently causes a
> > warning about these operations being unused. Mark them as such t
On Wed, Apr 04, 2018 at 11:57:14AM +0200, Maxime Ripard wrote:
> The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is
> based on the Ilitek ILI9881c Controller. Add a driver for it, modelled
> after the other Ilitek controller drivers.
>
> Signed-off-by: Maxime Ripard
> ---
From: Michel Dänzer
When it's set, TTM tries to allocate huge pages if possible. Drivers
which can take advantage of huge pages should set it.
Drivers not setting this flag no longer incur any overhead related to
allocating or freeing huge pages.
Cc: sta...@vger.kernel.org
Signed-off-by: Michel
From: Michel Dänzer
GFP_TRANSHUGE tries very hard to allocate huge pages, which can result
in long delays with high memory pressure. I have observed firefox
freezing for up to around a minute due to this while restic was taking
a full system backup.
Since we don't really need huge pages, use GFP
On Tue, Apr 03, 2018 at 01:30:01PM +0300, Robert Chiras wrote:
> From: Mirela Rabulea
>
> Do not hardcode pixel_format to 0x77 but calculate it from dsi->format.
> Report all the supported bus formats in get_modes:
> MEDIA_BUS_FMT_RGB888_1X24
> MEDIA_BUS_FMT_RGB666_1X18
>
On Thu, Apr 26, 2018 at 04:25:57PM +0200, Daniel Vetter wrote:
> This is the exact same text as proposed&merged for igt:
>
> https://patchwork.kernel.org/patch/10339739/
>
> With one minor change: Both regular contributions to the kernel
> overall and to userspace graphics counts. We've gained a
On Tue, Apr 03, 2018 at 01:30:00PM +0300, Robert Chiras wrote:
> Add support for the OLED display based on MIPI-DSI protocol from Raydium:
> RM67191.
>
> Signed-off-by: Robert Chiras
> ---
> .../bindings/display/panel/raydium,rm67191.txt | 55 ++
> drivers/gpu/drm/panel/Kconfig
From: "Leo (Sunpeng) Li"
The lines were removed as part of the original change. They may have
been missed during merge.
This is a fixup to:
committ 265083076187e619aa9176aeb05ad630013429b4
Author: Leo (Sunpeng) Li
Date: Fri Feb 2 10:18:56 2018 -0500
drm/amd/display: Hook
On Thu, Apr 26, 2018 at 4:25 PM, Daniel Vetter wrote:
> This is the exact same text as proposed&merged for igt:
>
> https://patchwork.kernel.org/patch/10339739/
>
> With one minor change: Both regular contributions to the kernel
> overall and to userspace graphics counts. We've gained a few
> comm
This is the exact same text as proposed&merged for igt:
https://patchwork.kernel.org/patch/10339739/
With one minor change: Both regular contributions to the kernel
overall and to userspace graphics counts. We've gained a few
committers in the past who are coming from arm-soc platform work and
si
On Mon, Apr 23, 2018 at 01:11:25PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 23, 2018 at 10:43:47AM +0530, Nautiyal, Ankit K wrote:
> >
> >
> > On 4/20/2018 7:37 PM, Ville Syrjälä wrote:
> > > On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote:
> > >> From: Ankit Nautiyal
> > >>
>
On Thu, Apr 26, 2018 at 03:58:53PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Building the driver in a configuration with !PM currently causes a
> warning about these operations being unused. Mark them as such to shut
> up the compiler.
>
> Signed-off-by: Thierry Reding
I'd so lov
From: Ville Syrjälä
An overeager sed has corrupted the drm_rect_rotation_inv()
documentation. Fix it up.
Looks like it wasn't entirely correct before the sed fail
either. We were missing _rect_ from the function names, which
also explains why the sed hit these by accident.
Signed-off-by: Ville
On Mon, Mar 12, 2018 at 11:33:45PM +0200, Jyri Sarha wrote:
> Add support for Three Five displays TFC S9700RTWV43TR-01B 800x480
> panel with resistive touch found on TI's AM335X-EVM.
>
> Signed-off-by: Jyri Sarha
> Reviewed-by: Tomi Valkeinen
> cc: Thierry Reding
> ---
> .../display/panel/tfc,
On Mon, Mar 12, 2018 at 11:33:45PM +0200, Jyri Sarha wrote:
> Add support for Three Five displays TFC S9700RTWV43TR-01B 800x480
> panel with resistive touch found on TI's AM335X-EVM.
>
> Signed-off-by: Jyri Sarha
> Reviewed-by: Tomi Valkeinen
> cc: Thierry Reding
> ---
> .../display/panel/tfc,
On Wed, Mar 14, 2018 at 05:12:14PM +0800, Lin Huang wrote:
> From: huang lin
>
> Refactor Innolux P079ZCA panel driver, let it support
> multi panel.
>
> Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
When you send out a revised set of these patches, please drop the
Change-Id: line from t
1 - 100 of 184 matches
Mail list logo
