Am 29.08.19 um 08:05 schrieb Kenny Ho:
> Allow DRM TTM memory manager to register a work_struct, such that, when
> a drmcgrp is under memory pressure, memory reclaiming can be triggered
> immediately.
>
> Change-Id: I25ac04e2db9c19ff12652b88ebff18b44b2706d8
> Signed-off-by: Kenny Ho
> ---
> driv
On 2019-08-27 13:35, Geert Uytterhoeven wrote:
> Hi Peter,
>
> On Tue, Aug 27, 2019 at 1:09 PM Peter Rosin wrote:
>> The variable is only ever used from fbcon.c which is linked into the
>> same module. Therefore, the export is not needed.
>>
>> Signed-off-by: Peter Rosin
>
> Reviewed-by: Geert
Hi,
On Wed, Aug 28, 2019 at 02:29:48PM +, Robert Chiras wrote:
> Hi Guido,
>
> I tested this on my setup and it works. My DSI panel is a little bit
> different and it doesn't work with this as-is, but I added some
> improvements on top of this, in order to be able to setup the clocks.
> The ch
Hi Fabrizio,
On Wed, Aug 28, 2019 at 8:36 PM Fabrizio Castro
wrote:
> Dual-LVDS connections need markers in the DT, this patch adds
> some common documentation to be referenced by both panels and
> bridges.
>
> Signed-off-by: Fabrizio Castro
Thanks for your patch!
> --- /dev/null
> +++ b/Docum
dcn20_resource.c:2636:9: error: missing braces around initializer
[-Werror=missing-braces]
struct _vcs_dpi_voltage_scaling_st calculated_states[MAX_CLOCK_LIMIT_STATES]
= {0};
^
Fixes: 7ed4e6352c16f ("drm/amd/display: Add DCN2 HW Sequencer and Resource")
Signed-off-by: Raul E Rangel
-
The driver does not support these sensors yet and there is no point in
creating sysfs attributes which will always return an error.
Signed-off-by: Jean Delvare
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
---
This works for me however I couldn't seen any other place in th
The following commit has been merged into the x86/vmware branch of tip:
Commit-ID: 6abe3778cf5abd59b23b9037796f3eab8b7f1d98
Gitweb:
https://git.kernel.org/tip/6abe3778cf5abd59b23b9037796f3eab8b7f1d98
Author:Thomas Hellstrom
AuthorDate:Wed, 28 Aug 2019 10:03:52 +02:00
Commi
> -Original Message-
> From: Michael Kelley
>
> From: Wei Hu Sent: Tuesday, August 27, 2019 4:25 AM
> >
> > Without deferred IO support, hyperv_fb driver informs the host to refresh
> > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
> > is screen update or
Comparing adev->family with CHIP constants is not correct.
adev->family can only be compared with AMDGPU_FAMILY constants and
adev->asic_type is the struct member to compare with CHIP constants.
They are separate identification spaces.
Signed-off-by: Jean Delvare
Fixes: 62a37553414a ("drm/amdgpu:
Hi Geert,
Thank you for your feedback!
> From: linux-kernel-ow...@vger.kernel.org
> On Behalf Of Geert Uytterhoeven
> Sent: 29 August 2019 08:58
> Subject: Re: [PATCH v3 1/8] dt-bindings: display: Add bindings for LVDS
> bus-timings
>
> Hi Fabrizio,
>
> On Wed, Aug 28, 2019 at 8:36 PM Fabriz
Hi Guido,
One more thing for you to add in v4, see inline.
On Jo, 2019-08-22 at 12:44 +0200, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found
> on
> i.MX8 SoCs.
>
> It adds support for the i.MX8MQ but the same IP can be found on
> e.g. the i.MX8QXP.
>
> On 2019-08-28 at 22:12:10 +0530, Ramalingam C wrote:
> > Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block
> > movement from DDI into transcoder.
> >
> > v12:
> > r-b and ack are collected.
> > few review comments are addressed.
>
> Tomas,
>
> Thanks for reviewing the patches a
On 2019-08-29 at 15:28:35 +0530, Winkler, Tomas wrote:
> > On 2019-08-28 at 22:12:10 +0530, Ramalingam C wrote:
> > > Enabling the HDCP1.4 and 2.2 on TGL by supporting the HW block
> > > movement from DDI into transcoder.
> > >
> > > v12:
> > > r-b and ack are collected.
> > > few review commen
On Mon, Aug 26, 2019 at 01:06:37PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/arm/display/komeda/komeda_dev.c
>
> between commit:
>
> 51a44a28eefd ("drm/komeda: Add missing of_node_get() call")
>
> from the d
Dear All,
the HiHope RZ/G2M is advertised as supporting panel idk-1110wr from
Advantech, but the panel doesn't come with the board, it has to purchased
separatey, therefore this series adds panel support to a new DT.
Thanks,
Fab
Fabrizio Castro (2):
dt-bindings: display: Add idk-1110wr binding
Add binding for the idk-1110wr LVDS panel from Advantech.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htm
Signed-off-by: Fabrizio Castro
---
.../display/panel/advantech,idk-1110wr.yaml|
The HiHope RZ/G2M is advertised as compatible with panel idk-1110wr
from Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
work the HiHope RZ/G2M, is the most convenient way to support the
HiHope RZ/G2M when it's connected
ttm increasingly gets into the way while hacking on virtio-gpu memory
management. It also overkill for what virtio-gpu needs. Lets get rid
of it.
v9:
- rebase to latest dem-misc-next, adapt to changes.
- fix issues found by Chia-I Wu.
v8:
- rebase to latest drm-misc-next, adapt to changes.
v7
No users left.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 1 -
drivers/gpu/drm/virtio/virtgpu_object.c | 13 -
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/vi
No users left.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 85f974a9837b..fb35831ed351 100644
--- a/drivers/gpu/dr
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
drivers/gpu/drm/virtio/virtgpu_gem.c | 24 +++-
drivers/gpu/drm/virtio/virtgpu_vq.c | 12
3 files changed, 21 insertions(+), 19 del
Thin wrapper around virtio_gpu_object_create(),
but calling that directly works equally well.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
drivers/gpu/drm/virtio/virtgpu_gem.c | 23 ---
drivers/gpu/drm/virtio/vi
Make sure we don't leak half-initialized fences outside the driver.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index a0514f5bd006.
Rework fencing workflow, starting with virtio_gpu_execbuffer_ioctl.
Stop using ttm helpers, use the virtio_gpu_array_* helpers (which work
on the reservation objects directly) instead.
Also store the object array in struct virtio_gpu_vbuffer, so we
explicitly keep a reference of all buffers used i
All callers pass no_wait = false.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 5 ++---
drivers/gpu/drm/virtio/virtgpu_gem.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
3 files changed, 6 insertions(+), 7 deletions(-)
dif
Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
This also makes the ioctl run lockless.
v9: fix return value.
v5: handle lookup failure.
v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/g
With this gem and ttm will use the same reservation object,
so mixing and matching ttm / gem reservation helpers should
work fine.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 +--
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 50 +++---
drivers/gpu/drm/virtio/virtgpu_plane.c | 21 ---
drivers/gpu/drm/virtio/virtgpu_vq.c
No users left.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 3e5b2d1db42d..85f974a9837b 100644
--- a/drivers/gpu/drm/virt
Rework fencing workflow. Stop using ttm helpers, use the
virtio_gpu_array_* helpers instead.
Due to using the gem reservation object it is initialized and ready for
use before calling ttm_bo_init. So we can simply use the standard
fencing workflow and drop the tricky logic which checks whenever
No users left.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 --
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 39 --
2 files changed, 42 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/
Call reservation_object_* directly instead
of using ttm_bo_{reserve,unreserve}.
v4: check for EINTR only.
v3: check for EINTR too.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 40 ++
drivers/gpu/drm/virtio/virtgpu_vq.c| 8 --
3 files changed, 23 insertions(+), 28 del
No need to do the reservation dance,
we can just wait on the fence directly.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane
virtio-gpu basically needs a sg_table for the bo, to tell the host where
the backing pages for the object are. So the gem shmem helpers are a
perfect fit. Some drm_gem_object_funcs need thin wrappers to update the
host state, but otherwise the helpers handle everything just fine.
Once the fencin
Some helper functions to manage an array of gem objects.
v9: use dma_resv_lock_interruptible.
v6:
- add ticket to struct virtio_gpu_object_array.
- add virtio_gpu_array_{lock,unlock}_resv helpers.
- add virtio_gpu_array_add_fence helper.
v5: some small optimizations (Chia-I Wu).
v4: make them v
Hi Fabrizio,
On Thu, Aug 29, 2019 at 12:22 PM Fabrizio Castro
wrote:
> The HiHope RZ/G2M is advertised as compatible with panel idk-1110wr
> from Advantech, however the panel isn't sold alongside the board.
> A new dts, adding everything that's required to get the panel to
> work the HiHope RZ/G2
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #29 from Martin ---
@Alex Deucher
Is there a fix for the graphical glitches I experience?
They seem to be similar to the glitches I get when I enable overclocking with
amdgpu.ppfeaturemask=0x
--
You are receiving this mail
Hi Geert,
Thank you for your feedback!
> From: Geert Uytterhoeven
> Sent: 29 August 2019 11:51
> Subject: Re: [PATCH 2/2] arm64: dts: renesas: Add HiHope RZ/G2M board with
> idk-1110wr display
>
> Hi Fabrizio,
>
> On Thu, Aug 29, 2019 at 12:22 PM Fabrizio Castro
> wrote:
> > The HiHope RZ/G2
Currently, the MXSFB DRM driver only supports a panel. But, its output
display signal can also be redirected to another encoder, like a DSI
controller. In this case, that DSI controller may act like a drm_bridge.
In order support this use-case too, this patch adds support for drm_bridge
in mxsfb.
From: Guido Günther
The bridge might have special requirmentes on the input bus. This
is e.g. used by the imx-nwl bridge.
Signed-off-by: Guido Günther
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drive
Because of stability issues, we may want to limit the maximum bandwidth
required by the MXSFB (eLCDIF) driver.
Signed-off-by: Robert Chiras
Tested-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 48 +++
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 ++
2 f
From: Mirela Rabulea
Add mxsfb_atomic_helper_check to signal mode changed when bpp changed.
This will trigger the execution of disable/enable on
a modeset with different bpp than the current one.
Signed-off-by: Mirela Rabulea
Signed-off-by: Robert Chiras
Tested-by: Guido Günther
---
drivers/
Since version 4 of eLCDIF, there are some registers that can do
transformations on the input data, like re-arranging the pixel
components. By doing that, we can support more pixel formats.
This patch adds support for X/ABGR and RGBX/A. Although, the local alpha
is not supported by eLCDIF, the alpha
Besides the eLCDIF block, there is another IP block, used in the past
for EPDC panels. Since the iMX.8mq doesn't have an EPDC connector, this
block is not documented, but we can use it to do additional operations
on the frame buffer.
In this case, we can use the pigeon registers from this IP block
Some of the existing registers in this controller are not defined, but
also not used. Add them to the register definitions, so that they can be
easily used in future improvements or fixes.
Signed-off-by: Robert Chiras
Tested-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 15
Add new optional property 'max-memory-bandwidth', to limit the maximum
bandwidth used by the MXSFB_DRM driver.
Signed-off-by: Robert Chiras
Tested-by: Guido Günther
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/display/mxsfb.txt | 5 +
1 file changed, 5 insertions(+)
diff
Use BIT(x) and GEN_MASK(h, l) for better representation the inside of
various registers.
Signed-off-by: Robert Chiras
Tested-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 151 ++---
1 file changed, 89 insertions(+), 62 deletions(-)
diff --git a/driv
Some of the registers, like LCDC_CTRL, CTRL2_OUTSTANDING_REQS and
CTRL1_RECOVERY_ON_UNDERFLOW needs to be properly cleared/initialized
for a better start and stop routine.
Signed-off-by: Robert Chiras
Tested-by: Guido Günther
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 12
1 file chan
Dear All,
the HiHope RZ/G2M is advertised as supporting panel idk-1110wr from
Advantech, but the panel doesn't come with the board, it has to purchased
separatey, therefore this series adds panel support to a new DT.
v1->v2
* fixed a space according to Geert's feedback.
Thanks,
Fab
Fabrizio Cas
Add binding for the idk-1110wr LVDS panel from Advantech.
Some panel-specific documentation can be found here:
https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htm
Signed-off-by: Fabrizio Castro
---
v1->v2:
* no change
.../display/panel/advantech,idk
The HiHope RZ/G2M is advertised as compatible with panel idk-1110wr
from Advantech, however the panel isn't sold alongside the board.
A new dts, adding everything that's required to get the panel to
work the HiHope RZ/G2M, is the most convenient way to support the
HiHope RZ/G2M when it's connected
DP_MAX_DOWNSTREAM_PORTS=0x10 is a vendor-independent constant.
Reviewed-by: Emil Velikov
Signed-off-by: Oleg Vasilev
Cc: Ville Syrjälä
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/display/intel_display_types.h | 2 --
include/drm/drm_dp_helper.h| 2 ++
2
The helper should always be used.
Reviewed-by: Emil Velikov
Signed-off-by: Oleg Vasilev
Cc: Ville Syrjälä
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/drm_dp_helper.c | 3 +--
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
d
Currently, downstream port type is only reported in debugfs. This
information should be considered important since it reflects the actual
physical connector type. Some userspace (e.g. window compositors)
may want to show this info to a user.
The 'subconnector' property is already utilized for DVI-
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself. Display
Core already has the subconnector information, we only need to
expose it through DRM property.
Signed-off-by: Oleg Vasilev
Tested-by: Oleg Vasilev
Cc: Alex Deu
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
v2: updates to match previous commit changes
Reviewed-by: Emil Velikov
Tested-by: Oleg Vasilev
Signed-off-by: Oleg Vasilev
Cc: Ville Syrjälä
Cc: intel-...@lists.fre
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
Reviewed-by: Emil Velikov
Signed-off-by: Oleg Vasilev
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: amd-...@lists.freedesktop.org
---
drivers/
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
Reviewed-by: Emil Velikov
Signed-off-by: Oleg Vasilev
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +
On Mon, Aug 26, 2019 at 9:22 AM Oleg Vasilev wrote:
>
> Since DP-specific information is stored in driver's structures, every
> driver needs to implement subconnector property by itself.
>
> Reviewed-by: Emil Velikov
> Signed-off-by: Oleg Vasilev
> Cc: Alex Deucher
> Cc: Christian König
> Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #50 from tempel.jul...@gmail.com ---
Are we already out of options for debug output? :)
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #51 from Nicholas Kazlauskas ---
(In reply to tempel.julian from comment #50)
> Are we already out of options for debug output? :)
Might help to see what IOCTLs are being specifically called by userspace. I
think you can enable that
On Tue, Aug 27, 2019 at 02:33:31PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> It attempted to avoid fps drops in the presence of cursor updates. But
> it is racing, and can result in hw updates after flush before vblank,
> which leads to underruns.
>
> Signed-off-by: Rob Clark
Reviewed-by:
On Tue, Aug 27, 2019 at 02:33:34PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> First step in re-working the atomic related internal API to prepare for
> async updates pending.. ->wait_flush() is intended to block until there
> is no in-progress flush.
>
> A crtc_mask is used, rather than an at
On Tue, Aug 27, 2019 at 02:33:32PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Just waiting for next vblank isn't ideal.. we should really be looking
> at the hw FLUSH register value to know if there is still an in-progress
> flush without stalling unnecessarily when there is no pending flush.
On Tue, Aug 27, 2019 at 02:33:33PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Previously the callback was called from whoever called wait_for_vblank(),
> but that isn't a great plan when wait_for_vblank() stops getting called,
> and results in frame_done_timer expiring.
>
> Signed-off-by: Rob
On Wed, Aug 28, 2019 at 10:27 AM Ville Syrjälä
wrote:
>
> On Mon, Aug 26, 2019 at 04:22:13PM +0300, Oleg Vasilev wrote:
> > Since DP-specific information is stored in driver's structures, every
> > driver needs to implement subconnector property by itself.
> >
> > v2: updates to match previous com
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #30 from Alex Deucher ---
(In reply to Martin from comment #29)
> @Alex Deucher
> Is there a fix for the graphical glitches I experience?
> They seem to be similar to the glitches I get when I enable overclocking
> with amdgpu.ppfea
On Wed, 2019-07-17 at 14:47 +0800, CK Hu wrote:
> Hi, Yongqiang:
>
> On Tue, 2019-07-09 at 06:34 +0800, yongqiang@mediatek.com wrote:
> > From: Yongqiang Niu
> >
> > This patch add ovl0/ovl_2l0 usecase
> > in ovl->ovl_2l0 direct link usecase:
> > 1. the crtc support layer number will 4+2
> >
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #52 from tempel.jul...@gmail.com ---
Created attachment 145207
--> https://bugs.freedesktop.org/attachment.cgi?id=145207&action=edit
dmesg ioctl log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #53 from tempel.jul...@gmail.com ---
Hm, it seems that maximum log size isn't enough for even one whole second?
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #54 from tempel.jul...@gmail.com ---
Not sure if it was helpful, but I tried setting log_buf_len=131072 and ran
sleep 5s && dmesg in background while I was provoking the issue in Oblivion
(dmesg-ioctl_2.log).
--
You are receiving th
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #55 from tempel.jul...@gmail.com ---
Created attachment 145208
--> https://bugs.freedesktop.org/attachment.cgi?id=145208&action=edit
hopefully extended dmesg ioctl log
--
You are receiving this mail because:
You are the assignee f
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #56 from Nicholas Kazlauskas ---
It seems to be the frequent calls to DRM_IOCTL_MODE_SETPROPERTY that's causing
the issue but I'm not entirely sure what specifically it's trying to set that's
doing this.
This probably isn't triggeri
Hi,
I will be traveling / busy with other things / without access to my
development setup till 23.09. Sorry for the inconvenience.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri
On Thu, Aug 29, 2019 at 6:38 AM Fabrizio Castro
wrote:
>
> Add binding for the idk-1110wr LVDS panel from Advantech.
>
> Some panel-specific documentation can be found here:
> https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-IDK-1110WR-55WSA1E.htm
>
> Signed-off-by: Fabriz
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #31 from Martin ---
well the flickering goes away, if I lock the clocks to "low" or "high"
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing l
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #32 from Alex Deucher ---
(In reply to Martin from comment #31)
> well the flickering goes away, if I lock the clocks to "low" or "high"
Exactly. In that case the mclk never changes so there is no flicker. The mclk
has to change d
On Wed, Aug 28, 2019 at 1:36 PM Fabrizio Castro
wrote:
>
> Dual-LVDS connections need markers in the DT, this patch adds
> some common documentation to be referenced by both panels and
> bridges.
>
> Signed-off-by: Fabrizio Castro
>
> ---
> v2->v3:
> * new patch
> ---
> .../bindings/display/bus-
On 28/08/2019 08:05, Andrzej Hajda wrote:
> On 27.08.2019 22:03, John Stultz wrote:
>> On Mon, Aug 19, 2019 at 3:27 PM John Stultz wrote:
>>> On Thu, Jun 27, 2019 at 8:18 AM Matt Redfearn
>>> wrote:
In contrast to all of the DSI panel drivers in drivers/gpu/drm/panel
which attach to
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #57 from tempel.jul...@gmail.com ---
Unfortunately unchanged :( . New log:
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lis
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #58 from tempel.jul...@gmail.com ---
Created attachment 145209
--> https://bugs.freedesktop.org/attachment.cgi?id=145209&action=edit
new ioctl log with patch applied
--
You are receiving this mail because:
You are the assignee for
Thanks for the feedback Christian. I am still digging into this one.
Daniel suggested leveraging the Shrinker API for the functionality of this
commit in RFC v3 but I am still trying to figure it out how/if ttm fit with
shrinker (though the idea behind the shrinker API seems fairly
straightforward
On Tue, Aug 27, 2019 at 10:44:59AM +0100, Lee Jones wrote:
> [...]
>
> > > IIUC the conclusion is that there is no need for a string attribute
> > > because we only need to distinguish between 'perceptual' and
> > > 'non-perceptual'. If that is correct, do you have any preference for
> > > the att
Yeah, that's also a really good idea as well.
The problem with the shrinker API is that it only applies to system memory
currently.
So you won't have a distinction which domain you need to evict stuff from.
Regards,
Christian.
Am 29.08.19 um 16:07 schrieb Kenny Ho:
Thanks for the feedback Chri
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #33 from Martin ---
thank you for the clarification.
Right now I switch manually between low and high when necessary, so I can work
around the glitches.
Do you think it will be possible to achieve feature parity with windows soon?
Hi everyone,
since upstreaming the full dynamic DMA-buf changes turned out more problematic
than previously thought I've reverted back to individual patches and separated
out only the locking changes.
So this patch does NOT contain any new callbacks for pinning/unpinning and move
notification,
This way we can even pipeline imported BO evictions.
v2: Limit this to only cases when the parent object uses a separate
reservation object as well. This fixes another OOM problem.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 16 +---
1 file changed, 9
This patch is a stripped down version of the locking changes
necessary to support dynamic DMA-buf handling.
For compatibility we cache the DMA-buf mapping as soon as
exporter/importer disagree on the dynamic handling.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 90 +++
Instead of relying on the DRM functions just implement our own import
functions. This prepares support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach
Add an DMA-buf export implementation independent of the DRM helpers.
This not only avoids the caching of DMA-buf mappings, but also
allows us to use the new dynamic locking approach.
This is also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugging leftover
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #34 from Alex Deucher ---
(In reply to Martin from comment #33)
> thank you for the clarification.
> Right now I switch manually between low and high when necessary, so I can
> work around the glitches.
> Do you think it will be po
Hi Fabrizio,
Thank you for the patch.
On Thu, Aug 29, 2019 at 12:38:32PM +0100, Fabrizio Castro wrote:
> Add binding for the idk-1110wr LVDS panel from Advantech.
>
> Some panel-specific documentation can be found here:
> https://buy.advantech.eu/Displays/Embedded-LCD-Kits-LCD-Kit-Modules/model-
Hi Rob,
Thank you for your feedback!
> From: Rob Herring
> Sent: 29 August 2019 15:03
> Subject: Re: [PATCH v3 1/8] dt-bindings: display: Add bindings for LVDS
> bus-timings
>
> On Wed, Aug 28, 2019 at 1:36 PM Fabrizio Castro
> wrote:
> >
> > Dual-LVDS connections need markers in the DT, this
Hi Fabrizio,
Thank you for the patch.
On Thu, Aug 29, 2019 at 12:38:33PM +0100, Fabrizio Castro wrote:
> The HiHope RZ/G2M is advertised as compatible with panel idk-1110wr
> from Advantech, however the panel isn't sold alongside the board.
> A new dts, adding everything that's required to get th
Yes, and I think it has quite a lot of coupling with mm's page and
pressure mechanisms. My current thought is to just copy the API but
have a separate implementation of "ttm_shrinker" and
"ttm_shrinker_control" or something like that. I am certainly happy
to listen to additional feedbacks and sug
Hi Paul,
On Thu, Aug 29, 2019 at 12:03:32PM +0200, Paul Cercueil wrote:
> Le mar. 27 août 2019 à 7:00, Sam Ravnborg a écrit :
> > On Fri, Aug 23, 2019 at 11:30:09PM +0200, Paul Cercueil wrote:
> >> Le ven. 23 août 2019 à 23:23, Laurent Pinchart a écrit :
> >>> The ingenic driver supports DPI pane
From: Yongqiang Niu
This patch add mutex description for mt8183 display
Signed-off-by: Yongqiang Niu
---
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.tx
From: Yongqiang Niu
This series are based on 5.3-rc1 and provid 32 patch
to support mediatek SOC MT8183
Change since v4
- fix reviewed issue in v4
Change since v3
- fix reviewed issue in v3
- fix type error in v3
- fix conflict with iommu patch
Change since v2
- fix reviewed issue in v2
- add
From: Yongqiang Niu
Update device tree binding documention for the display subsystem for
Mediatek MT8183 SOCs
Signed-off-by: Yongqiang Niu
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Doc
1 - 100 of 202 matches
Mail list logo
