On Sun, Feb 16, 2020 at 07:15:13PM +0100, Sam Ravnborg wrote:
> RFC only - not tested yet!
>
> The panel-dpi compatible is a fallback that
> allows the DT to specify the timing.
>
> When matching panel-dpi expect the device tree to include the
> timing information for the display-panel.
>
>
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset
Signed-off-by: Nirmoy Das
Reviewed-and-tested-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
drivers/gpu/drm/radeon/radeon_ttm.c
With this patch series I am trying to remove GPU address dependency in
TTM and moving GPU address calculation to individual drm drivers.
I tested this patch series on qxl, bochs and amdgpu. Christian tested it on
radeon HW.
It would be nice if someone test this for nouveau and vmgfx.
Nirmoy
Hi Andrey,
On Fri, Feb 14, 2020 at 11:32:31PM +0200, Andrey Lebedev wrote:
> On Fri, Feb 14, 2020 at 09:53:51AM +0100, Maxime Ripard wrote:
> > On Fri, Feb 14, 2020 at 10:43:58AM +0200, Andrey Lebedev wrote:
> > > On Fri, Feb 14, 2020 at 08:52:18AM +0100, Maxime Ripard wrote:
> > > > > > This
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
include/drm/ttm/ttm_bo_driver.h | 1 -
3 files changed, 10 deletions(-)
diff --git
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++--
GPU address handling is device specific and should be handle by its device
driver.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/ttm/ttm_bo.c| 7 ---
include/drm/ttm/ttm_bo_api.h| 2 --
include/drm/ttm/ttm_bo_driver.h | 1 -
3 files changed, 10 deletions(-)
diff --git
On Fri, Feb 14, 2020 at 05:49:53PM +0200, Laurent Pinchart wrote:
> On Fri, Feb 14, 2020 at 04:44:05PM +0100, Maxime Ripard wrote:
> > On Fri, Feb 14, 2020 at 03:10:25PM +0200, Laurent Pinchart wrote:
> > > On Fri, Feb 14, 2020 at 01:32:43PM +0100, Maxime Ripard wrote:
> > > > SoCs that have
Switch over to GEM VRAM's implementation to retrieve bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index
This patch also removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 6 ++
drivers/gpu/drm/qxl/qxl_kms.c| 5 ++---
This patch also removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/qxl/qxl_drv.h| 5 ++---
drivers/gpu/drm/qxl/qxl_kms.c| 5 ++---
drivers/gpu/drm/qxl/qxl_object.h | 5 -
Add nodes for IDP display. The display is Visionox RM69299.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Adding dependency patchwork series
- Removing suspend configuration
- Adding blank before space curly brace
Changes in v3:
- Updating status for mdp and
Calculate GPU offset within vram-helper without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
Christian König
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
On 2020-02-12 10:40, Rob Clark wrote:
On Tue, Feb 11, 2020 at 8:05 PM Jeffrey Hugo
wrote:
On Tue, Feb 11, 2020 at 5:28 PM Rob Clark wrote:
>
> On Tue, Feb 11, 2020 at 7:59 AM Jeffrey Hugo wrote:
> >
> > On Tue, Feb 11, 2020 at 8:44 AM Rob Clark wrote:
> > >
> > > On Mon, Feb 10, 2020 at
Instead of defining KVMGT per-device state in struct intel_vgpu
directly, add an indirection. This makes the GVT code oblivious of
what state KVMGT needs to keep.
The intention here is to eventually make it possible to build
hypervisor backends for the mediator, without having to touch the
The wait_for macro's for Broadcom VC4 and V3D drivers used msleep
which is inappropriate due to its inaccuracy at low values (minimum
wait time is about 30ms on the Raspberry Pi).
This patch replaces the macro with the one from the Intel i915 version
which uses usleep_range to provide more
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++--
With this patch series I am trying to remove GPU address dependency in
TTM and moving GPU address calculation to individual drm drivers.
I tested this patch series on qxl, bochs and amdgpu. Christian tested it on
radeon HW.
It would be nice if someone test this for nouveau and vmgfx.
Nirmoy Das
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +-
Calculate GPU offset within bochs driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/bochs/bochs_kms.c | 3 ++-
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv50/base507c.c |
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset
Signed-off-by: Nirmoy Das
Reviewed-and-tested-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
drivers/gpu/drm/radeon/radeon_ttm.c
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +-
Hi,
On Sun, Feb 16, 2020 at 11:02:17PM +0200, Laurent Pinchart wrote:
> This patch series is the sixth attempt to (nearly, see [1])
> complete the rework of the omapdrm driver to move to drm_bridge
> and drm_panel.
>
> Version 2, available at [2], explains in its long cover letter the
>
Hi, Bibby:
On Thu, 2020-02-13 at 12:06 +0800, CK Hu wrote:
> Hi, Bibby:
>
> On Thu, 2020-02-13 at 09:23 +0800, Bibby Hsieh wrote:
> > Besides x, y position, width and height,
> > fb also need updating in async update.
> >
>
> Reviewed-by: CK Hu
>
Applied to mediatek-drm-fixes-5.6 [1],
Hi, Bibby:
On Thu, 2020-02-13 at 11:54 +0800, CK Hu wrote:
> Hi, Bibby:
>
> On Thu, 2020-02-13 at 09:23 +0800, Bibby Hsieh wrote:
> > MTK do rotation checking and transferring in layer check function,
> > but we do not check that in atomic_check,
> > so add back in atomic_check function.
> >
>
On Tue, Feb 18, Ville Syrjälä wrote:
>On Tue, Feb 18, 2020 at 01:41:39AM +0800, Lee Shawn C wrote:
>> Test case HF1-13 for HDMI 2.0 compliance would ask DUT to downgrade
>> output resolution to 720x480 or 720x576 (lower than 3.4Gbps).
>> And check scrambling feature was disabled as well.
>>
>>
On Tue, Feb 18, 2020 at 2:21 AM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> On Mon, Feb 17, 2020 at 10:53:08AM +0100, Daniel Vetter wrote:
> > On Sun, Feb 16, 2020 at 11:02:21PM +0200, Laurent Pinchart wrote:
> > > To support implementation of DRM connectors on top of DRM bridges
> > > instead of
Hi Andrzej:
On Tue, Dec 17, 2019 at 03:49:50PM +0100, Andrzej Pietrasiewicz wrote:
> Extend the size-checking special function to handle afbc.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 49 +--
> include/drm/drm_framebuffer.h
On Tue, Dec 17, 2019 at 03:49:49PM +0100, Andrzej Pietrasiewicz wrote:
> The new version accepts a struct describing deviations from standard way of
> doing the size checks. The caller must provide the respective values.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
>
Hi Andrzej:
On Tue, Dec 17, 2019 at 03:49:48PM +0100, Andrzej Pietrasiewicz wrote:
> Prepare tools for drivers which need to allocate a struct drm_framebuffer
> (or a container of struct drm_framebuffer) explicitly, before calling
> helpers. In such a case we need new helpers which omit allocating
Hi Andrzej:
On Tue, Dec 17, 2019 at 03:49:47PM +0100, Andrzej Pietrasiewicz wrote:
> Add checking if a modifier is afbc and getting afbc block size.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/drm_fourcc.c | 53
>
Hi Daniel,
On Mon, Feb 17, 2020 at 10:53:08AM +0100, Daniel Vetter wrote:
> On Sun, Feb 16, 2020 at 11:02:21PM +0200, Laurent Pinchart wrote:
> > To support implementation of DRM connectors on top of DRM bridges
> > instead of by bridges, the drm_bridge needs to expose new operations and
> >
Hi Sebastian,
On Tue, Feb 18, 2020 at 12:00:13AM +0100, Sebastian Reichel wrote:
> Hi,
>
> On Sun, Feb 16, 2020 at 11:02:17PM +0200, Laurent Pinchart wrote:
> > This patch series is the sixth attempt to (nearly, see [1])
> > complete the rework of the omapdrm driver to move to drm_bridge
> > and
On Mon, Feb 17, 2020 at 11:15:37PM +0100, Noralf Trønnes wrote:
> Den 17.02.2020 22.39, skrev Mark Brown:
> > Out of interest why are 8 bit registers going to be a problem?
> I have written 3 drivers so far and they all have some registers that
> need to deal with values larger than 255. If I
Den 17.02.2020 22.39, skrev Mark Brown:
> On Mon, Feb 17, 2020 at 10:33:58PM +0100, Noralf Trønnes wrote:
>> Den 17.02.2020 13.11, skrev Mark Brown:
>
>>> This looks like you just don't support a straight write operation, if
>>> you need to do this emulation push it up the stack.
>
>> After
The patch
ASoC: hdmi-codec: set plugged_cb to NULL when component removing
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next
The patch
drm/mediatek: fix race condition for HDMI jack status reporting
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
On Mon, Feb 17, 2020 at 10:33:58PM +0100, Noralf Trønnes wrote:
> Den 17.02.2020 13.11, skrev Mark Brown:
> > This looks like you just don't support a straight write operation, if
> > you need to do this emulation push it up the stack.
> After going through the stack I realise that I have a
Den 17.02.2020 13.11, skrev Mark Brown:
> On Sun, Feb 16, 2020 at 06:21:09PM +0100, Noralf Trønnes wrote:
>
>> Add support for regmap over USB for use with the Multifunction USB Device.
>> Two endpoints IN/OUT are used. Up to 255 regmaps are supported on one USB
>> interface. The register
On Mon, Feb 17, 2020 at 7:58 PM Christian König
wrote:
>
> Am 17.02.20 um 18:55 schrieb Daniel Vetter:
> > On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
> >> Implement the importer side of unpinned DMA-buf handling.
> >>
> >> v2: update page tables immediately
> >>
> >>
https://bugzilla.kernel.org/show_bug.cgi?id=205915
--- Comment #13 from Alex Deucher (alexdeuc...@gmail.com) ---
Does this series help?
https://patchwork.freedesktop.org/patch/353367/
--
You are receiving this mail because:
You are watching the assignee of the bug.
Am 17.02.20 um 18:55 schrieb Daniel Vetter:
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
Implement the importer side of unpinned DMA-buf handling.
v2: update page tables immediately
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66
Hi Maxime,
On Mon, Feb 17, 2020 at 06:42:53PM +0100, Maxime Ripard wrote:
> On Fri, Feb 14, 2020 at 05:49:53PM +0200, Laurent Pinchart wrote:
> > On Fri, Feb 14, 2020 at 04:44:05PM +0100, Maxime Ripard wrote:
> > > On Fri, Feb 14, 2020 at 03:10:25PM +0200, Laurent Pinchart wrote:
> > > > On Fri,
https://bugzilla.kernel.org/show_bug.cgi?id=206577
Bug ID: 206577
Summary: Periodic screen blanking at a high refresh rate and
resolution
Product: Drivers
Version: 2.5
Kernel Version: 5.5
Hardware: All
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
> Implement the importer side of unpinned DMA-buf handling.
>
> v2: update page tables immediately
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66 -
>
https://bugzilla.kernel.org/show_bug.cgi?id=205915
Manuel Ullmann (la...@posteo.de) changed:
What|Removed |Added
Attachment #287449|0 |1
is patch|
https://bugzilla.kernel.org/show_bug.cgi?id=205915
--- Comment #12 from Manuel Ullmann (la...@posteo.de) ---
Created attachment 287449
--> https://bugzilla.kernel.org/attachment.cgi?id=287449=edit
Call optimize bandwidth again.
I pinned the issue down to the four lines, which call
Hi Tvrtko,
FYI, the error/warning still remains.
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: d194314da04eb965c651dcef6d692dc83821a414
commit: 1883a0a4658eaba354db2179b4d3395247d27582 [1/2] drm/i915: Track hw
reported context runtime
config: i386-defconfig
https://bugzilla.kernel.org/show_bug.cgi?id=206575
--- Comment #5 from Noel Maersk (veox+ker...@veox.pw) ---
I'm not able to bisect at current moment. Will try by end of workweek.
-
User `muncrief` has recently reported something similar in a different bug
report, here:
https://bugzilla.kernel.org/show_bug.cgi?id=206575
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=206575
--- Comment #3 from Noel Maersk (veox+ker...@veox.pw) ---
Created attachment 287447
--> https://bugzilla.kernel.org/attachment.cgi?id=287447=edit
lspci output
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=206575
Noel Maersk (veox+ker...@veox.pw) changed:
What|Removed |Added
Regression|No |Yes
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=206575
--- Comment #2 from Noel Maersk (veox+ker...@veox.pw) ---
Created attachment 287445
--> https://bugzilla.kernel.org/attachment.cgi?id=287445=edit
dmesg output for resume-from-hibernate, linux 5.5.4
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=206575
--- Comment #1 from Noel Maersk (veox+ker...@veox.pw) ---
Created attachment 287443
--> https://bugzilla.kernel.org/attachment.cgi?id=287443=edit
dmesg output for resume-from-suspend, linux 5.4.20
--
You are receiving this mail because:
You
https://bugzilla.kernel.org/show_bug.cgi?id=206575
Bug ID: 206575
Summary: [amdgpu] [drm] No video signal on resume from suspend,
R9 380
Product: Drivers
Version: 2.5
Kernel Version: 5.5
Hardware: x86-64
On 2/17/20 4:57 PM, Alex Deucher wrote:
On Mon, Feb 17, 2020 at 10:02 AM Nirmoy Das wrote:
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
Christian König
Missing Acked or Reviewed prefix for Christian.
:facepalm: Thanks Alex.
Nirmoy
Alex
---
On Mon, Feb 17, 2020 at 10:02 AM Nirmoy Das wrote:
>
> Store ttm bo->offset in struct nouveau_bo instead.
>
> Signed-off-by: Nirmoy Das
> Christian König
Missing Acked or Reviewed prefix for Christian.
Alex
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
>
Please ignore this one, I've send out the wrong version without Daniels
latest comment nit picks fixed.
The interesting one in this series is the last patch.
Regards,
Christian.
Am 17.02.20 um 16:45 schrieb Christian König:
On the exporter side we add optional explicit pinning callbacks.
This implements the exporter side of unpinned DMA-buf handling.
v2: fix minor coding style issues
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 53 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 ++
2 files changed, 51 insertions(+), 7
Avoid that we ping/pong the buffers when we stop to pin DMA-buf
exports by using the allowed domains for exported buffers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Implement the importer side of unpinned DMA-buf handling.
v2: update page tables immediately
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66 -
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
2 files changed, 71 insertions(+), 1
Pipeline removal of the BOs backing store when no placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index
Hi everyone,
hopefully the last iteration of those patches.
For now I've addressed the issue of unmapping imported BOs from the amdgpu page
tables immediately by locking the page tables in place.
For HMM handling we are getting the ability to invalidate BOs without locking
the VM anyway, so
On the exporter side we add optional explicit pinning callbacks. Which are
called when the importer doesn't implement dynamic handling, move notification
or need the DMA-buf locked in place for its use case.
On the importer side we add an optional move_notify callback. This callback is
used by
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
Switch over to GEM VRAM's implementation to retrieve bo->offset
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, Feb 18, 2020 at 01:41:39AM +0800, Lee Shawn C wrote:
> Test case HF1-13 for HDMI 2.0 compliance would ask DUT to downgrade
> output resolution to 720x480 or 720x576 (lower than 3.4Gbps).
> And check scrambling feature was disabled as well.
>
> But QD980 report it can support low rate
Den 17.02.2020 11.32, skrev Neil Armstrong:
> Hi,
>
> On 16/02/2020 18:21, Noralf Trønnes wrote:
>> Hi,
>>
>> A while back I had the idea to turn a Raspberry Pi Zero into a $5
>> USB to HDMI/SDTV/DSI/DPI display adapter.
>>
>> Thinking about how to represent the display to the driver I realised
https://bugzilla.kernel.org/show_bug.cgi?id=206475
Marco (rodomar...@protonmail.com) changed:
What|Removed |Added
Status|RESOLVED|REOPENED
On 2/17/20 1:41 PM, Gerd Hoffmann wrote:
On Mon, Feb 17, 2020 at 11:18:40AM +0100, Nirmoy Das wrote:
Calculate GPU offset within bochs driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/bochs/bochs_kms.c | 3 ++-
On Mon, Feb 17, 2020 at 11:18:40AM +0100, Nirmoy Das wrote:
> Calculate GPU offset within bochs driver itself without depending on
> bo->offset
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/bochs/bochs_kms.c | 3 ++-
> drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
> 2 files changed,
On Mon, Feb 17, 2020 at 11:18:39AM +0100, Nirmoy Das wrote:
> This patch also removes slot->gpu_offset which is not required as
> VRAM and PRIV slot are in separate PCI bar
Well, gpu_offset is still in struct qxlslot ...
Other than that the patch looks fine, and this is minor enough
that I'll
On Sun, Feb 16, 2020 at 06:21:14PM +0100, Noralf Trønnes wrote:
> When writing a 3MB buffer the unwritable check in _regmap_raw_write_impl()
> adds a ~20ms overhead on a Raspberry Pi 4.
> Amend this by avoiding the check if it's not necessary.
This is a generic optimization, why is it mixed in
Am 17.02.20 um 11:18 schrieb Nirmoy Das:
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
Acked-by: Christian König for this one and
patch #5 and #6 in this series.
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
On Sun, Feb 16, 2020 at 06:21:09PM +0100, Noralf Trønnes wrote:
> Add support for regmap over USB for use with the Multifunction USB Device.
> Two endpoints IN/OUT are used. Up to 255 regmaps are supported on one USB
> interface. The register index width is always 32-bit, but the register
> value
On Mon, Feb 17, 2020 at 11:55:50AM +0100, Andrzej Pietrasiewicz wrote:
> Hi James,
>
> Thank you for the review.
>
> Did you intentionally review patches from the v4 series or you simply
> didn't notice the v5? There are some differences, the most notable one
> is using proper way of subclassing
On 2/17/20 12:09 PM, Christian König wrote:
Am 17.02.20 um 11:18 schrieb Nirmoy Das:
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
Am 17.02.20 um 11:18 schrieb Nirmoy Das:
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
Am 17.02.20 um 11:18 schrieb Nirmoy Das:
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
Reviewed-by: Christian König
---
Hi Andrzej:
On Fri, Dec 13, 2019 at 04:58:36PM +0100, Andrzej Pietrasiewicz wrote:
> Extend the size-checking special function to handle afbc.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/drm_fourcc.c | 10 +++-
> drivers/gpu/drm/drm_framebuffer.c
Hi James,
Thank you for the review.
Did you intentionally review patches from the v4 series or you simply
didn't notice the v5? There are some differences, the most notable one
is using proper way of subclassing a drm_framebuffer.
The v5 series was sent on 17th December 2019.
Andrzej
W dniu
Hi,
On 16/02/2020 18:21, Noralf Trønnes wrote:
> Hi,
>
> A while back I had the idea to turn a Raspberry Pi Zero into a $5
> USB to HDMI/SDTV/DSI/DPI display adapter.
>
> Thinking about how to represent the display to the driver I realised
> that hardware use registers as API. And Linux does
On Sun, Feb 16, 2020 at 11:02:21PM +0200, Laurent Pinchart wrote:
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
>
> - Output detection, hot-plug notification, mode retrieval and EDID
>
Test case HF1-13 for HDMI 2.0 compliance would ask DUT to downgrade
output resolution to 720x480 or 720x576 (lower than 3.4Gbps).
And check scrambling feature was disabled as well.
But QD980 report it can support low rate scrambling. The vendor
specific data block byte[6] was 0x88. If driver
On Sun, Feb 16, 2020 at 11:02:19PM +0200, Laurent Pinchart wrote:
> drm_connector.c contains a map of connector types (DRM_MODE_CONNECTOR_*)
> to name strings, but doesn't expose it. This leads to drivers having to
> store a similar map.
Maybe also a todo if there's many of these?
-Daniel
>
>
On Sun, Feb 16, 2020 at 06:21:08PM +0100, Noralf Trønnes wrote:
> Hi,
>
> A while back I had the idea to turn a Raspberry Pi Zero into a $5
> USB to HDMI/SDTV/DSI/DPI display adapter.
>
> Thinking about how to represent the display to the driver I realised
> that hardware use registers as API.
On Sun, Feb 16, 2020 at 06:21:16PM +0100, Noralf Trønnes wrote:
> drm_client_init_from_id() provides a way for clients to add a client based
> on the minor. drm_client_modeset_set() provides a way to set the modeset
> for clients that handles connectors and display mode on their own.
>
>
On Sun, Feb 16, 2020 at 12:58:10PM -0300, Paul Cercueil wrote:
> The fbdev emulation is only ever used on Ingenic SoCs to run old SDL1
> based games at 16bpp (rgb565). Recent applications generally talk to
> DRM directly, and can request their favourite pixel format; so we can
> make everybody
On Sun, Feb 16, 2020 at 12:47:08PM +0100, Christophe JAILLET wrote:
> A 'h' ismissing in' syncronization'
>
> Signed-off-by: Christophe JAILLET
Applied, thanks for your patch.
-Daniel
> ---
> drivers/dma-buf/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Sat, Feb 15, 2020 at 07:09:11PM +0100, Emmanuel Vadot wrote:
> From: Emmanuel Vadot
>
> Contributors for this file are :
> Gerd Hoffmann
> Maxime Ripard
> Noralf Trønnes
>
> Signed-off-by: Emmanuel Vadot
Patch applied since we have all the acks we need. I think for the first
one we
On Fri, Feb 14, 2020 at 11:29:38AM +, Maya Rashish wrote:
> Signed-off-by: Maya Rashish
> Co-authored-by: Thomas Klausner
Also, we need a s-o-b from every co-author, because of the dco:
https://developercertificate.org/
Thanks, Daniel
> ---
> drivers/gpu/drm/amd/include/atombios.h |
On Fri, Feb 14, 2020 at 11:29:38AM +, Maya Rashish wrote:
> Signed-off-by: Maya Rashish
> Co-authored-by: Thomas Klausner
> ---
> drivers/gpu/drm/amd/include/atombios.h | 20 ++--
> drivers/gpu/drm/amd/include/atomfirmware.h | 4 ++--
> drivers/gpu/drm/radeon/atombios.h
According mtk hardware design, stream_done0 and stream_done1 are
generated by mutex, so we move gce event property to mutex device mode.
Signed-off-by: Bibby Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
In order to use GCE function, we need add some information
into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
Signed-off-by: Bibby Hsieh
Signed-off-by: Yongqiang Niu
---
This patch depends on ptach:
[RESEND,v6,02/17] arm64: dts: add display nodes for mt8183
Mediatek CMDQ driver removed atomic parameter and implementation
related to atomic. DRM driver need to make sure previous message
done or be aborted before we send next message.
If previous message is still waiting for event, it means the
setting hasn't been updated into display hardware
Hi
Am 15.02.20 um 19:09 schrieb Emmanuel Vadot:
> Hello all,
>
> We had a discussion a while back with Noralf where he said that he wouldn't
> mind dual licence his work under GPL-2 and MIT.
> Those files are a problem with BSDs as we cannot include them.
> For drm_client.c the main contributors
Hi!
Dne četrtek, 06. februar 2020 ob 20:18:25 CET je Neil Armstrong napisal(a):
> From: Jonas Karlman
>
> Add the max_bpc property to the dw-hdmi connector to prepare support
> for 10, 12 & 16bit output support.
>
> Signed-off-by: Jonas Karlman
> Signed-off-by: Neil Armstrong
> ---
>
Hi,
The Allwinner LVDS encoder allows to change the polarity of clocks and
data lanes, so let's add the needed bus flags to DRM, panel-lvds and
our encoder driver.
Let me know what you think,
Maxime
Maxime Ripard (4):
drm/connector: Add data polarity flags
dt-bindings: panel: lvds: Add
On Fri, Feb 14, 2020 at 08:52:18AM +0100, Maxime Ripard wrote:
> > > This will create a spurious warning message for TCON1, since we
> > > adjusted the driver to tell it supports LVDS, but there's no LVDS
> > > reset line, so we need to make it finer grained.
> >
> > Yes, I can attribute two of
1 - 100 of 156 matches
Mail list logo