Hi Anitha,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.10-rc2
next-20201103]
[If your patch is applied
https://bugzilla.kernel.org/show_bug.cgi?id=209939
--- Comment #5 from Janpieter Sollie (janpieter.sol...@edpnet.be) ---
Also tried (thanks to hint from Gentoo) netconsole
when using netconsole, no output is logged: while the kernel buffer from before
'radeontop' is printed correctly, no other
Hi Lyude,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.10-rc2 next-20201103]
[cannot apply to drm/drm-next
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
libdrm mostly for new hw and ame names.
Aaron Liu (7):
tests/amdgpu: expand secure param for exec_cs_helper (v2)
tests/amdgpu: add atomic_mem cp_packet to verify the secure buffer
tests/amdgpu: add test to submit a gfx command
Hi Maxime,
On 10/28/20 9:41 PM, Maxime Ripard wrote:
> The current HVS muxing code will consider the CRTCs in a given state to
> setup their muxing in the HVS, and disable the other CRTCs muxes.
>
> However, it's valid to only update a single CRTC with a state, and in this
> situation we would
Make the definition of struct drm_driver
a constant, to follow the latest developments
in the DRM layer.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 32 +
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 25 +--
2 files changed, 29
From: Alex Deucher
Use the per device drm driver feature flags rather than the
global one. This way we can make the drm driver struct const.
Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 +++-
1 file changed, 3 insertions(+), 1
Hi Daniel,
These two patches follow up your latest
DRM work to make definitions of struct drm_driver
in DRM low-level drivers, constant, in amdgpu.
This set doesn't descend from my previous patch
"drm/amdgpu: Convert to using devm_drm_dev_alloc() (v2)",
since our branch doesn't have it, and I
On Wed, Nov 04, 2020 at 09:37:05AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-intel-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'gen12_emit_fini_breadcrumb':
>
> -Original Message-
> From: Daniel Vetter
> Sent: Tuesday, November 03, 2020 12:43 PM
> To: Xiong, Jianxin
> Cc: Jason Gunthorpe ; linux-rdma ;
> dri-devel ; Leon
> Romanovsky ; Doug Ledford ; Vetter,
> Daniel ; Christian Koenig
>
> Subject: Re: [PATCH v6 1/4] RDMA/umem: Support
This patch adds bindings for Intel KeemBay MIPI DSI
v2: corrected description for port
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
Reviewed-by: Neil Armstrong
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Rob Herring
---
This is a basic KMS atomic modesetting display driver for KeemBay family of
SOCs. Driver has no 2D or 3D graphics. It calls into the ADV bridge
driver at the connector level.
Single CRTC with LCD controller->mipi DSI->ADV bridge
Only 1080p resolution and single plane is supported at this time.
This patch add bindings for Intel KeemBay MSSCAM syscon
v2: fixed compatible (Sam R.)
Signed-off-by: Anitha Chrisanthus
Cc: Sam Ravnborg
Cc: Neil Armstrong
Cc: Rob Herring
---
.../bindings/display/intel,keembay-msscam.yaml | 43 ++
1 file changed, 43 insertions(+)
Initializes Mipi DSI and sets up connects to ADV bridge
v2: removed license text
upclassed dev_private, removed HAVE_IRQ. (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
v7:
This is a new DRM driver for Intel's KeemBay SOC.
The SoC couples an ARM Cortex A53 CPU with an Intel
Movidius VPU.
This driver is tested with the KMB EVM board which is the reference baord
for Keem Bay SOC. The SOC's display pipeline is as follows
+--++-+
This patch adds bindings for Intel KeemBay Display
v2: review changes from Rob Herring
v3: review changes from Sam Ravnborg (removed mipi dsi entries, and
encoder entry, connect port to dsi)
MSSCAM is part of the display submodule and its used to reset LCD
and MIPI DSI clocks, so its
Register definitions for Keem Bay display driver
v2: removed license text (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
v7: removed redundant definitions
v8: removed redundant
v2: Added Maintainer entry
v3: Added one more Maintainer entry
v3: drop videomode_helpers
Cc: Sam Ravnborg
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
---
MAINTAINERS | 7 +++
drivers/gpu/drm/Kconfig | 2 ++
drivers/gpu/drm/Makefile | 1 +
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'gen12_emit_fini_breadcrumb':
drivers/gpu/drm/i915/gt/intel_lrc.c:4998:31: error: implicit declaration of
function
On Tue, Nov 3, 2020 at 5:15 PM Lyude Paul wrote:
>
> Noticed this when trying to compile with -Wall on a kernel fork. We
> potentially
> don't set width here, which causes the compiler to complain about width
> potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
>
> Changes
On Thu, Oct 15, 2020 at 11:33:08AM +1000, Dave Airlie wrote:
> drm/nouveau/kms: Search for encoders' connectors properly
This commit (09838c4efe9a) broke boot for me. These two hunks in
particular:
@ -2066,7 +2120,7 @@ nv50_disp_atomic_commit_tail(struct drm_atomic_state
*state)
On 2020-11-03 4:54 p.m., Alex Deucher wrote:
> Use the per device drm driver feature flags rather than the
> global one. This way we can make the drm driver struct const.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Luben Tuikov
Yeah, that's a good change.
Regards,
Luben
> ---
>
Noticed this when trying to compile with -Wall on a kernel fork. We potentially
don't set width here, which causes the compiler to complain about width
potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
Changes since v1:
* Don't emit an error as this code isn't reachable,
On Tue, Nov 3, 2020 at 1:28 PM Bjorn Helgaas wrote:
>
> On Fri, Oct 30, 2020 at 11:08:11AM +0100, Daniel Vetter wrote:
> > There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
> > files, and the old proc interface. Two check against
> > iomem_is_exclusive, proc never did. And
Use the per device drm driver feature flags rather than the
global one. This way we can make the drm driver struct const.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
On Fri, Oct 30, 2020 at 11:08:15AM +0100, Daniel Vetter wrote:
> Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> the region") /dev/kmem zaps ptes when the kernel requests exclusive
> acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
> the default for all
On Fri, Oct 30, 2020 at 11:08:11AM +0100, Daniel Vetter wrote:
> There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
> files, and the old proc interface. Two check against
> iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
> this starts to matter, since we
Hi Anitha.
On Tue, Nov 03, 2020 at 11:34:28AM -0800, Anitha Chrisanthus wrote:
> This patch add bindings for Intel KeemBay MSSCAM syscon
>
> Signed-off-by: Anitha Chrisanthus
> Cc: Sam Ravnborg
> Cc: Neil Armstrong
> Cc: Rob Herring
> ---
> .../bindings/display/intel,keembay-msscam.yaml
Hi folks.
I observed hard reproductible the set of bugs.
It always started as
1) kworker/u64:2: page allocation failure: order:5,
mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
nodemask=(null),cpuset=/,mems_allowed=0
Continious as:
2) WARNING: CPU: 21 PID: 806649 at
From: Daniel Vetter
commit f49a51bfdc8ea717c97ccd4cc98b7e6daaa5553a upstream.
When we forward an mmap to the dma_buf exporter, they get to own
everything. Unfortunately drm_gem_mmap_obj() overwrote
vma->vm_private_data after the driver callback, wreaking the
exporter complete. This was noticed
On Tue, Nov 3, 2020 at 6:36 PM Xiong, Jianxin wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: Friday, October 23, 2020 6:45 PM
> > To: Jason Gunthorpe
> > Cc: Xiong, Jianxin ; linux-rdma
> > ; dri-devel ;
> > Leon
> > Romanovsky ; Doug Ledford ; Vetter,
> > Daniel
On Tue, 2020-11-03 at 14:53 -0500, Ilia Mirkin wrote:
> On Tue, Nov 3, 2020 at 2:47 PM Lyude Paul wrote:
> >
> > Sorry! Thought I had responded to this but apparently not, comments down
> > below
> >
> > On Thu, 2020-10-22 at 14:04 -0400, Ilia Mirkin wrote:
> > > On Thu, Oct 22, 2020 at 12:55
On Tue, Nov 3, 2020 at 2:47 PM Lyude Paul wrote:
>
> Sorry! Thought I had responded to this but apparently not, comments down below
>
> On Thu, 2020-10-22 at 14:04 -0400, Ilia Mirkin wrote:
> > On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote:
> > >
> > > Noticed this when trying to compile
Rather than protecting the nouveau_drm clients list with the lock within
the "client" nouveau_cli, add a dedicated lock to serialize access to
the list. This is both clearer and necessary to avoid lockdep being
upset with us when we need to iterate through all the clients in the
list and
This series fixes a number of use-after-frees in nouveau's postclose()
handler. It was discovered by pointing IGT's core_hotunplug tests at a
nouveau device, but the steps to reproduce it are simple:
1. Open the device file
2. Unbind the driver or remove the device
3. Close the file opened in
Nouveau does not currently support hot-unplugging, but it still makes
sense to switch from drm_dev_unregister() to drm_dev_unplug().
drm_dev_unplug() calls drm_dev_unregister() after marking the device as
unplugged, but only after any device critical sections are finished.
Since nouveau isn't
The postclose handler can run after the device has been removed (or the
driver has been unbound) since userspace clients are free to hold the
file open the file as long as they want. Because the device removal
callback frees the entire nouveau_drm structure, any reference to it in
the postclose
Sorry! Thought I had responded to this but apparently not, comments down below
On Thu, 2020-10-22 at 14:04 -0400, Ilia Mirkin wrote:
> On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote:
> >
> > Noticed this when trying to compile with -Wall on a kernel fork. We
> > potentially
> > don't set
This is a basic KMS atomic modesetting display driver for KeemBay family of
SOCs. Driver has no 2D or 3D graphics. It calls into the ADV bridge
driver at the connector level.
Single CRTC with LCD controller->mipi DSI->ADV bridge
Only 1080p resolution and single plane is supported at this time.
Register definitions for Keem Bay display driver
v2: removed license text (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
v7: removed redundant definitions
v8: removed redundant
This patch add bindings for Intel KeemBay MSSCAM syscon
Signed-off-by: Anitha Chrisanthus
Cc: Sam Ravnborg
Cc: Neil Armstrong
Cc: Rob Herring
---
.../bindings/display/intel,keembay-msscam.yaml | 36 ++
1 file changed, 36 insertions(+)
create mode 100644
v2: Added Maintainer entry
v3: Added one more Maintainer entry
v3: drop videomode_helpers
Cc: Sam Ravnborg
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
---
MAINTAINERS | 7 +++
drivers/gpu/drm/Kconfig | 2 ++
drivers/gpu/drm/Makefile | 1 +
This patch adds bindings for Intel KeemBay MIPI DSI
v2: corrected description for port
Signed-off-by: Anitha Chrisanthus
Reviewed-by: Sam Ravnborg
Reviewed-by: Neil Armstrong
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Rob Herring
---
This is a new DRM driver for Intel's KeemBay SOC.
The SoC couples an ARM Cortex A53 CPU with an Intel
Movidius VPU.
This driver is tested with the KMB EVM board which is the reference baord
for Keem Bay SOC. The SOC's display pipeline is as follows
+--++-+
Initializes Mipi DSI and sets up connects to ADV bridge
v2: removed license text
upclassed dev_private, removed HAVE_IRQ. (Sam)
v3: Squashed all 59 commits to one
v4: review changes from Sam Ravnborg
renamed dev_p to kmb
v5: corrected spellings
v6: corrected checkpatch warnings
v7:
This patch adds bindings for Intel KeemBay Display
v2: review changes from Rob Herring
v3: review changes from Sam Ravnborg (removed mipi dsi entries, and
encoder entry, connect port to dsi)
MSSCAM is part of the display submodule and its used to reset LCD
and MIPI DSI clocks, so its
On 11/3/20, 11:28 AM, Krzysztof Kozlowski wrote:
>
> Milo Kim's email in TI bounces with permanent error (550: Invalid
> recipient). Last email from him on LKML was in 2017. Move Milo Kim to
> credits and add Dan Murphy from TI to look after:
> - TI LP855x backlight driver,
> - TI LP8727
On Tue, Nov 3, 2020 at 2:33 AM Thomas Gleixner wrote:
>
> +static inline void *kmap(struct page *page)
> +{
> + void *addr;
> +
> + might_sleep();
> + if (!PageHighMem(page))
> + addr = page_address(page);
> + else
> + addr = kmap_high(page);
>
> -Original Message-
> From: Daniel Vetter
> Sent: Friday, October 23, 2020 6:45 PM
> To: Jason Gunthorpe
> Cc: Xiong, Jianxin ; linux-rdma
> ; dri-devel ;
> Leon
> Romanovsky ; Doug Ledford ; Vetter,
> Daniel ; Christian Koenig
>
> Subject: Re: [PATCH v6 1/4] RDMA/umem: Support
On Tue, Nov 03, 2020 at 05:28:32PM +0100, Krzysztof Kozlowski wrote:
> Milo Kim's email in TI bounces with permanent error (550: Invalid
> recipient). Last email from him on LKML was in 2017. Move Milo Kim to
> credits and add Dan Murphy from TI to look after:
> - TI LP855x backlight driver,
>
On Mon, Nov 02, 2020 at 09:02:25PM +0100, Marijn Suijten wrote:
> nr_rings is reset to 1, but when this function is called for a second
> (and third!) time nr_rings > 1 is false, thus the else case is entered
> to set up a buffer for the RPTR shadow and consequently written to
> RB_RPTR_ADDR,
On 03.11.2020 15:12, Chanwoo Choi wrote:
>>> I have a question about exynos_icc_get_parent().
>>> As I checked, this function returns the only one icc_node
>>> as parent node. But, bus_display dt node in the exynos4412.dtsi
>>> specifies the two interconnect node as following with bus_leftbus,
Hi Neil,
>
> msscam is used to enable clocks both for the display driver and the
> mipi-dsi part.
> >>>
> >>> If just clocks, then the msscam should be a clock provider possibly.
> >>> If not, then the below looks right.
> >
> > I am feeling a little clueless here - sorry.
> >
>
On 03/11/2020 11:44, Jon Hunter wrote:
> Deferred probe is an expected return value for tegra_output_probe().
> Given that the driver deals with it properly, there's no need to output
> a warning that may potentially confuse users.
>
> Signed-off-by: Jon Hunter
> ---
>
On Tue, Nov 03, 2020 at 05:28:32PM +0100, Krzysztof Kozlowski wrote:
> Milo Kim's email in TI bounces with permanent error (550: Invalid
> recipient). Last email from him on LKML was in 2017. Move Milo Kim to
> credits and add Dan Murphy from TI to look after:
> - TI LP855x backlight driver,
>
Should be fixed by:
https://patchwork.freedesktop.org/patch/397039/?series=83038=1
On Mon, Nov 2, 2020 at 7:44 PM dev god wrote:
>
> Hi
>
> fix implicit declaration of function error.
>
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1229:7: error: implicit
> >> declaration of function
On Sun, Nov 1, 2020 at 5:01 AM Daniel Vetter wrote:
>
> On Sat, Oct 31, 2020 at 2:57 PM Daniel Vetter wrote:
> >
> > On Fri, Oct 30, 2020 at 7:47 PM Alex Deucher wrote:
> > >
> > > On Fri, Oct 30, 2020 at 6:11 AM Daniel Vetter
> > > wrote:
> > > >
> > > > Prep work to make drm_device->driver
On Tue, 2020-11-03 at 16:56 +0200, Sakari Ailus wrote:
> On Tue, Nov 03, 2020 at 04:47:47PM +0200, Andy Shevchenko wrote:
> > On Tue, Nov 03, 2020 at 03:34:00PM +0200, Sakari Ailus wrote:
> > > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > > pixel formats denoted by
On Mon, Nov 2, 2020 at 9:47 PM Viresh Kumar wrote:
>
> On 27-10-20, 17:05, Viresh Kumar wrote:
> > It isn't that straight forward unfortunately, we need to make sure the
> > table doesn't get allocated for the same device twice, so
> > find+allocate needs to happen within a locked region.
> >
> >
> -Original Message-
> From: Christian König
> Sent: Monday, November 02, 2020 11:57 PM
> To: Xiong, Jianxin ; dri-devel@lists.freedesktop.org
> Cc: Sumit Semwal ; Vetter, Daniel
>
> Subject: Re: [PATCH] dma-buf: Fix static checker warning
>
> Am 03.11.20 um 04:51 schrieb Jianxin
Milo Kim's email in TI bounces with permanent error (550: Invalid
recipient). Last email from him on LKML was in 2017. Move Milo Kim to
credits and add Dan Murphy from TI to look after:
- TI LP855x backlight driver,
- TI LP8727 charger driver,
- TI LP8788 MFD (ADC, LEDs, charger and
On Tue, Nov 03, 2020 at 05:15:51PM +0100, Maxime Ripard wrote:
> Hi Ville,
>
> On Mon, Nov 02, 2020 at 06:04:06PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 02, 2020 at 02:38:33PM +0100, Maxime Ripard wrote:
> > > Many drivers reference the crtc->pointer in order to get the current CRTC
> > >
On Tue, Nov 03, 2020 at 02:50:40PM +, Deucher, Alexander wrote:
> [AMD Public Use]
>
> > -Original Message-
> > From: Greg KH
> > Sent: Tuesday, November 3, 2020 1:53 AM
> > To: Koenig, Christian
> > Cc: Alex Deucher ; Deepak R Varma
> > ; David Airlie ; LKML >
Hi Andy,
On Tue, Nov 03, 2020 at 04:47:47PM +0200, Andy Shevchenko wrote:
> On Tue, Nov 03, 2020 at 03:34:00PM +0200, Sakari Ailus wrote:
> > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by fourccs. The fourcc encoding is the same for both
> >
[AMD Public Use]
> -Original Message-
> From: Greg KH
> Sent: Tuesday, November 3, 2020 1:53 AM
> To: Koenig, Christian
> Cc: Alex Deucher ; Deepak R Varma
> ; David Airlie ; LKML ker...@vger.kernel.org>; Maling list - DRI developers de...@lists.freedesktop.org>; Melissa Wen ;
>
This is a note to let you know that I've just added the patch titled
drm/shme-helpers: Fix dma_buf_mmap forwarding bug
to the 5.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
The ttm_operation_ctx structure has a mixture of flags and bools. Drop the
flags and replace them with bools as well.
v2: fix typos, improve comments
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +--
During eviction we do want to trigger the OOM killer.
Only while doing new allocations we should try to avoid that and
return -ENOMEM to the application.
v2: rename the flag to gfp_retry_mayfail.
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
Hi Sylwester,
On Tue, Nov 3, 2020 at 8:32 PM Sylwester Nawrocki
wrote:
>
> On 03.11.2020 10:37, Chanwoo Choi wrote:
> > On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
> >> This patch adds a generic interconnect driver for Exynos SoCs in order
> >> to provide interconnect functionality for each
Hi Sylwester,
On Tue, Nov 3, 2020 at 9:32 PM Sylwester Nawrocki
wrote:
>
> Hi Chanwoo,
>
> On 03.11.2020 11:45, Chanwoo Choi wrote:
> > On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
> >> This patch adds registration of a child platform device for the exynos
> >> interconnect driver. It is
Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
pixel formats denoted by fourccs. The fourcc encoding is the same for both
so the same implementation can be used.
Suggested-by: Mauro Carvalho Chehab
Signed-off-by: Sakari Ailus
---
Hi folks,
I believe I've addressed
Hi Rasmus,
Thanks for the review.
On Mon, Apr 27, 2020 at 05:44:00PM +0200, Rasmus Villemoes wrote:
> On 27/04/2020 16.53, Sakari Ailus wrote:
> > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and DRM
> > pixel formats denoted by fourccs. The fourcc encoding is the same for
On Tue, 3 Nov 2020 at 13:32, Sylwester Nawrocki wrote:
>
> Hi Chanwoo,
>
> On 03.11.2020 11:45, Chanwoo Choi wrote:
> > On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
> >> This patch adds registration of a child platform device for the exynos
> >> interconnect driver. It is assumed that the
For sinks that do not support audio, there is no need to notify
audio subsystem of the connection event.
This will make sure that audio routes only to the primary display
when connected to such sinks.
changes in v2:
- Added fixes tag
- Removed nested if condition and removed usage of global
On Tue, Nov 3, 2020 at 12:57 PM Paul Cercueil wrote:
>
> Hi Daniel,
>
> Le mar. 3 nov. 2020 à 11:17, Daniel Vetter a écrit :
> > On Mon, Nov 02, 2020 at 10:06:51PM +, Paul Cercueil wrote:
> >> With the module parameter ingenic-drm.cached_gem_buffers, it is
> >> possible
> >> to specify
On Tue, Nov 3, 2020 at 11:31 AM Simon Ser wrote:
>
> Other properties are documented with a colon character after the
> property name. Consistently using a colon character allows the docs to
> be machine-readable.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
Acked-by: Daniel Vetter
> ---
Hi Chanwoo,
On 03.11.2020 11:45, Chanwoo Choi wrote:
> On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
>> This patch adds registration of a child platform device for the exynos
>> interconnect driver. It is assumed that the interconnect provider will
>> only be needed when #interconnect-cells
16:43:57 -0400)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel
tags/drm-intel-next-queued-2020-11-03
for you to fetch changes up to 139caf7ca2866cd0a45814ff938cb0c33920a266:
drm/i915: Update DRIVER_DATE to 20201103 (2020-11-03
On Tue, Nov 3, 2020 at 10:27 AM Thomas Gleixner wrote:
>
> kmap_types.h is a misnomer because the old atomic MAP based array does not
> exist anymore and the whole indirection of architectures including
> kmap_types.h is inconinstent and does not allow to provide guard page
> debugging for this
Drop "uapi/" and rearrange alphabetically.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index
From: Jyri Sarha
Implement CTM color management property for OMAP CRTC using DSS
overlay manager's Color Phase Rotation matrix. The CPR matrix does not
exactly match the CTM property documentation. On DSS the CPR matrix is
applied after gamma table look up. However, it seems stupid to add a
Hi,
This is a resend of the v1, after adding Pekka's reviewed-by, rebasing
to latest drm-misc, and re-testing. The cover letter from v1:
This series is based on patches sent about a year ago:
https://lists.freedesktop.org/archives/dri-devel/2019-September/233966.html
From: Jyri Sarha
Adds support for COLOR_ENCODING and COLOR_RANGE properties to
omap_plane.c and dispc.c. The supported encodings and ranges are
presets are:
For COLOR_ENCODING:
- YCbCr BT.601 (default)
- YCbCr BT.709
For COLOR_RANGE:
- YCbCr limited range
- YCbCr full range (default)
omapdrm supports gamma via GAMMA_LUT property. However, the HW we have
is:
gamma -> ctm -> out
instead of what the model DRM framework uses:
ctm -> gamma -> out
As the following patches add CTM support for omapdrm, lets first fix the
gamma.
This patch changes the property from GAMMA_LUT to
We currently have drm_atomic_helper_legacy_gamma_set() helper which can
be used to handle legacy gamma-set ioctl.
drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
CTM and DEGAMMA_LUT. This works fine on HW where we have either:
degamma -> ctm -> gamma -> out
or
ctm -> gamma ->
On Tue, 3 Nov 2020 12:08:47 +0100
Daniel Vetter wrote:
> On Tue, Nov 03, 2020 at 12:03:26PM +0100, Boris Brezillon wrote:
> > On Tue, 3 Nov 2020 11:25:40 +0100
> > Daniel Vetter wrote:
> >
> > > On Tue, Nov 03, 2020 at 09:13:47AM +0100, Boris Brezillon wrote:
> > > > We've fixed many races
On Tue, Nov 03, 2020 at 12:25:06PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 03.11.20 um 11:55 schrieb Daniel Vetter:
> > On Tue, Nov 03, 2020 at 11:38:32AM +0100, Maxime Ripard wrote:
> >> On Tue, Nov 03, 2020 at 11:10:27AM +0100, Thomas Zimmermann wrote:
> >>> Hi
> >>>
> >>> Am 03.11.20 um
Hi,
On 11/3/20 12:30 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 03.11.20 um 12:09 schrieb Hans de Goede:
>> Hi,
>>
>> On 11/3/20 11:36 AM, Thomas Zimmermann wrote:
>>> The drivers gm12u320 and udl operate on USB devices. They leave the PCI
>>> device in struct drm_device empty and store the USB
Deferred probe is an expected return value for tegra_output_probe().
Given that the driver deals with it properly, there's no need to output
a warning that may potentially confuse users.
Signed-off-by: Jon Hunter
---
drivers/gpu/drm/tegra/sor.c | 2 +-
1 file changed, 1 insertion(+), 1
Drop the driver's udev field in favor of struct drm_device.dev. No
functional changes made.
v3:
* upcast dev with udl_to_usb_device()
v2:
* upcast dev with drm_dev_get_usb_device()
Signed-off-by: Thomas Zimmermann
Reviewed-by: Hans de Goede
Acked-by: Daniel Vetter
---
Drop the driver's udev field in favor of struct drm_device.dev. No
functional changes made.
v3:
* upcast dev with gm12u320_to_usb_device()
v2:
* upcast dev with drm_dev_get_usb_device()
Signed-off-by: Thomas Zimmermann
Reviewed-by: Hans de Goede
Acked-by: Daniel Vetter
---
The drivers gm12u320 and udl operate on USB devices. They leave the PCI
device in struct drm_device empty and store the USB device in their own
driver structure. It's expected that DRM core and helpers only touch the
PCI-device field for actual PCI devices.
Fix this special case by upcasting
On 03.11.2020 10:37, Chanwoo Choi wrote:
> On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
>> This patch adds a generic interconnect driver for Exynos SoCs in order
>> to provide interconnect functionality for each "samsung,exynos-bus"
>> compatible device.
>>
>> The SoC topology is a graph (or
Hi
Am 03.11.20 um 12:09 schrieb Hans de Goede:
> Hi,
>
> On 11/3/20 11:36 AM, Thomas Zimmermann wrote:
>> The drivers gm12u320 and udl operate on USB devices. They leave the PCI
>> device in struct drm_device empty and store the USB device in their own
>> driver structure. It's expected that DRM
Hi
Am 03.11.20 um 11:55 schrieb Daniel Vetter:
> On Tue, Nov 03, 2020 at 11:38:32AM +0100, Maxime Ripard wrote:
>> On Tue, Nov 03, 2020 at 11:10:27AM +0100, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 03.11.20 um 10:52 schrieb Maxime Ripard:
On Tue, Nov 03, 2020 at 10:10:41AM +0800, Tian Tao
From: Rajib Mahapatra
It is enabling the test for Stoney ASIC.
Signed-off-by: Rajib Mahapatra
---
tests/amdgpu/deadlock_tests.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/amdgpu/deadlock_tests.c b/tests/amdgpu/deadlock_tests.c
index 248cc339..c89e51d9 100644
On Tue, Nov 03, 2020 at 12:03:26PM +0100, Boris Brezillon wrote:
> On Tue, 3 Nov 2020 11:25:40 +0100
> Daniel Vetter wrote:
>
> > On Tue, Nov 03, 2020 at 09:13:47AM +0100, Boris Brezillon wrote:
> > > We've fixed many races in panfrost_job_timedout() but some remain.
> > > Instead of trying to
Hi,
On 11/3/20 11:36 AM, Thomas Zimmermann wrote:
> The drivers gm12u320 and udl operate on USB devices. They leave the PCI
> device in struct drm_device empty and store the USB device in their own
> driver structure. It's expected that DRM core and helpers only touch the
> PCI-device field for
On Tue, 3 Nov 2020 11:25:40 +0100
Daniel Vetter wrote:
> On Tue, Nov 03, 2020 at 09:13:47AM +0100, Boris Brezillon wrote:
> > We've fixed many races in panfrost_job_timedout() but some remain.
> > Instead of trying to fix it again, let's simplify the logic and move
> > the reset bits to a
On Tue, Nov 03, 2020 at 11:36:56AM +0100, Thomas Zimmermann wrote:
> Drop the driver's udev field in favor of struct drm_device.dev. No
> functional changes made.
>
> v2:
> * upcast dev with drm_dev_get_usb_device()
Again, witht that helper either moved to udl_drv.h or to usb code:
1 - 100 of 212 matches
Mail list logo
