The code was making a copy of a struct ttm_resource. However,
recently the struct ttm_resources were allowed to be subclassed and
also were allowed to be malloced, hence the driver could end up assuming
the copy we handed it was subclassed and worse, the original could have
been freed at this point
Sorry for the noise, rebasing on top of drm-misc-next. Please ignore the
v9 series.
Hi,
I updated the patch set with some suggestions by Daniel Vetter, and
dropped the patches after patch 4 so that we can stick the landing for
avoiding races with modesetting rights before dealing with the tricky
drm_master_release can be called on a drm_file without a master, which
results in a null ptr dereference of file_priv->master->magic_map. The
three cases are:
1. Error path in drm_open_helper
drm_open():
drm_open_helper():
drm_master_open():
drm_new_set_master(); <--- returns -
drm_device.master_mutex currently protects the following:
- drm_device.master
- drm_file.master
- drm_file.was_master
- drm_file.is_master
- drm_master.unique
- drm_master.unique_len
- drm_master.magic_map
There is a clear separation between functions that read or change
these attributes. Hence, c
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this inverts the lock hierarchy of
drm_global_mutex --> master_rwsem.
To avoid this, we do some prep work to grab the drm_global_mutex
before checking for ioctl p
In drm_client_modeset.c and drm_fb_helper.c,
drm_master_internal_{acquire,release} are used to avoid races with DRM
userspace. These functions hold onto drm_device.master_rwsem while
committing, and bail if there's already a master.
However, there are other places where modesetting rights can race
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/tiny/arcpgu.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/dr
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/arm/hdlcd_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/a
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 4 +---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +---
drivers/gpu/drm/exynos/
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/panfrost/panfrost_device.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfr
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 +---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 4 +---
2 files changed, 2 insertions(+), 6 del
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/tve200/tve200_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tve200/tve20
On Mon, 30 Aug 2021, Ville Syrjälä wrote:
> On Mon, Aug 30, 2021 at 01:29:01PM +0300, Jani Nikula wrote:
>> The VESA Organization Vendor-Specific Data Block, defined in VESA
>> DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
>> stream count and segment pixel overlap.
>>
>> Di
On 30/08/2021 09:26, Daniel Vetter wrote:
On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote:
On 27/08/2021 15:39, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
when rendering is done on Intel dgfx and scanout
Op 13-08-2021 om 22:30 schreef Daniel Vetter:
> We don't need the absolute speed of rcu for this. And
> i915_address_space in general dont need rcu protection anywhere else,
> after we've made gem contexts and engines a lot more immutable.
>
> Note that this semantically reverts
>
> commit aabbe344
On Tue, 17 Aug 2021, Anisse Astier wrote:
> The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
> used for the embedded display. Add support for using it via by adding
> the EDID to the list of available modes on the connector, and use it for
> eDP when available.
>
> If a panel'
On Tue, 17 Aug 2021, Anisse Astier wrote:
> This patch series is for making the GPD Win Max display usable with
> Linux.
>
> The GPD Win Max is a small laptop, and its eDP panel does not send an
> EDID over DPCD; the EDID is instead available in the intel opregion, in
> mailbox #5 [1]
>
> The firs
Op 14-08-2021 om 12:43 schreef Daniel Vetter:
> The only reason for this really is the i915_gem_engines->fence
> callback engines_notify(), which exists purely as a fairly funky
> reference counting scheme for that. Otherwise all other callers are
> from process context, and generally fairly benign
https://bugzilla.kernel.org/show_bug.cgi?id=214029
xiehuanjun (xiehuan...@uniontech.com) changed:
What|Removed |Added
CC||xiehuan...@unionte
Op 26-08-2021 om 09:24 schreef Thomas Hellström:
> Using the I915_MMAP_TYPE_FIXED mmap type requires the TTM backend, so
> for that mmap type, use __i915_gem_object_create_user() instead of
> i915_gem_object_create_internal(), as we really want to tests objects
> mmap-able by user-space.
>
> This a
On Tue, Aug 31, 2021 at 11:33 AM Jani Nikula wrote:
>
> On Tue, 17 Aug 2021, Anisse Astier wrote:
> > This patch series is for making the GPD Win Max display usable with
> > Linux.
> >
> > The GPD Win Max is a small laptop, and its eDP panel does not send an
> > EDID over DPCD; the EDID is instea
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #7 from Erhard F. (erhar...@mailbox.org) ---
(In reply to xiehuanjun from comment #6)
> hi
>
> use your .config (with CONFIG_DEBUG_KMEMLEAK=y) to make a kernel image and
> install this image ,then reboot the system, the issue will be
issue:
in cleanup_job the cancle_delayed_work will cancel a TO timer
even the its corresponding job is still running.
fix:
do not cancel the timer in cleanup_job, instead do the cancelling
only when the heading job is signaled, and if there is a "next" job
we start_timeout again.
v2:
further clea
tested-by: jingwen chen
Signed-off-by: Monk Liu
Signed-off-by: jingwen chen
---
drivers/gpu/drm/scheduler/sched_main.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
i
Hi Matthias,
Just ping for this patchset.
Thanks.
On Fri, 2021-07-30 at 10:52 +0800, Yong Wu wrote:
> MediaTek IOMMU block diagram always like below:
>
> M4U
> |
> smi-common
> |
> -
> | | ...
> | |
> larb1 larb2
> |
On 8/31/21 11:45 AM, Maarten Lankhorst wrote:
Op 26-08-2021 om 09:24 schreef Thomas Hellström:
Using the I915_MMAP_TYPE_FIXED mmap type requires the TTM backend, so
for that mmap type, use __i915_gem_object_create_user() instead of
i915_gem_object_create_internal(), as we really want to tests
Move that function into the resource handling and remove an unused parameter.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 48 +
drivers/gpu/drm/ttm/ttm_resource.c | 49 ++
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 15
Drivers can now use the flags for this.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 7 --
drivers/gpu/drm/drm_gem_vram_helper.c | 2 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 4 --
drivers/gpu/drm
More flexible than the busy placements.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 8 +++-
include/drm/ttm/ttm_placement.h | 6 ++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0a
Instead of the busy placement.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/a
This simplifies the handling quite a bit, but needs extensive testing.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 61 ++--
drivers/gpu/drm/nouveau/nouveau_bo.h | 1 -
2 files changed, 22 insertions(+), 40 deletions(-)
diff --git a/drivers/
From: Chi Minghao
Fix the following coccicheck REVIEW:
./drivers/gpu/drm/msm/edp/edp_ctrl.c:1245:5-8 Unneeded variable
Reported-by: Zeal Robot
Signed-off-by: Chi Minghao
---
drivers/gpu/drm/msm/edp/edp_ctrl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/d
We don't need the absolute speed of rcu for this. And
i915_address_space in general dont need rcu protection anywhere else,
after we've made gem contexts and engines a lot more immutable.
Note that this semantically reverts
commit aabbe344dc3ca5f7d8263a02608ba6179e8a4499
Author: Chris Wilson
Dat
On Tue, Aug 31, 2021 at 11:38:27AM +0200, Maarten Lankhorst wrote:
> Op 14-08-2021 om 12:43 schreef Daniel Vetter:
> > The only reason for this really is the i915_gem_engines->fence
> > callback engines_notify(), which exists purely as a fairly funky
> > reference counting scheme for that. Otherwis
On Mon, Aug 30, 2021 at 02:08:14PM +0200, Noralf Trønnes wrote:
>
>
> Den 17.08.2021 15.56, skrev Daniel Vetter:
> > On Tue, Aug 17, 2021 at 02:29:12PM +0200, Noralf Trønnes wrote:
> >> Add XRGB emulation support for devices that can only do RGB332.
> >>
> >> Cc: Thomas Zimmermann
> >> Signe
On Tue, Aug 31, 2021 at 02:02:39PM +0800, Desmond Cheong Zhi Xi wrote:
> On 26/8/21 9:21 pm, Daniel Vetter wrote:
> > On Thu, Aug 26, 2021 at 10:01:22AM +0800, Desmond Cheong Zhi Xi wrote:
> > > Previously, master_lookup_lock was introduced in
> > > commit 0b0860a3cf5e ("drm: serialize drm_file.mas
Using the I915_MMAP_TYPE_FIXED mmap type requires the TTM backend, so
for that mmap type, use __i915_gem_object_create_user() instead of
i915_gem_object_create_internal(), as we really want to tests objects
mmap-able by user-space.
This also means that the out-of-space error happens at object crea
On Mon, Aug 30, 2021 at 08:28:49AM +0200, Christian König wrote:
> Am 27.08.21 um 22:23 schrieb Daniel Vetter:
> > On Fri, Aug 27, 2021 at 11:07:58AM +0200, Christian König wrote:
> > > Am 26.08.21 um 10:55 schrieb Daniel Vetter:
> > > > On Tue, Aug 24, 2021 at 10:12:24AM +0200, Christian König wro
On Sat, Aug 28, 2021 at 12:02:21AM +0200, Javier Martinez Canillas wrote:
> Hello Daniel and Thomas,
>
> On 8/27/21 10:20 PM, Daniel Vetter wrote:
> > On Fri, Aug 27, 2021 at 07:50:23PM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 27.08.21 um 12:00 schrieb Javier Martinez Canillas:
> >>> T
Am 31.08.21 um 14:30 schrieb Daniel Vetter:
On Mon, Aug 30, 2021 at 08:28:49AM +0200, Christian König wrote:
Am 27.08.21 um 22:23 schrieb Daniel Vetter:
On Fri, Aug 27, 2021 at 11:07:58AM +0200, Christian König wrote:
Am 26.08.21 um 10:55 schrieb Daniel Vetter:
On Tue, Aug 24, 2021 at 10:12:2
On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote:
>
> On 30/08/2021 09:26, Daniel Vetter wrote:
> > On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 27/08/2021 15:39, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
> > > >
> > > > In short this mak
On Wed, Aug 18, 2021 at 12:54:42PM +0200, Christian König wrote:
> Only the DRM GPU scheduler, radeon and amdgpu where using them and they depend
> on a non existing config option to actually emit some code.
>
> v2: keep the signal path as is for now
>
> Signed-off-by: Christian König
Acked-by:
On Mon, Aug 30, 2021 at 10:39:11AM +0800, guangming@mediatek.com wrote:
> From: Guangming Cao
>
> When mapping the memory represented by a dma-buf into a device's
> address space, it might be desireable to map the memory with
> certain DMA attributes. Thus, introduce the dma_mapping_attrs
> f
On Mon, Aug 30, 2021 at 10:56:59AM +0200, Christian König wrote:
> It makes sense to have this in the common manager for debugging and
> accounting of how much resources are used.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_resource.c | 8
> include/drm/ttm/ttm_r
On Mon, Aug 30, 2021 at 12:38:51PM -0700, Umesh Nerlige Ramappa wrote:
> i915 used to support time based sampling mode which is good for overall
> system monitoring, but is not enough for query mode used to measure a
> single draw call or dispatch. Gen9-Gen11 are using current i915 perf
> implement
Am 31.08.21 um 14:52 schrieb Daniel Vetter:
On Mon, Aug 30, 2021 at 10:56:59AM +0200, Christian König wrote:
It makes sense to have this in the common manager for debugging and
accounting of how much resources are used.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_resource.c |
Can we please have some actual commit message here, with detailed
explanation of the race/bug/whatever, how you fix it and why this is the
best option?
On Tue, Aug 31, 2021 at 06:35:39PM +0800, Monk Liu wrote:
> tested-by: jingwen chen
> Signed-off-by: Monk Liu
> Signed-off-by: jingwen chen
> -
On Tue, Aug 31, 2021 at 02:59:02PM +0200, Daniel Vetter wrote:
> Can we please have some actual commit message here, with detailed
> explanation of the race/bug/whatever, how you fix it and why this is the
> best option?
>
> On Tue, Aug 31, 2021 at 06:35:39PM +0800, Monk Liu wrote:
> > tested-by:
On Fri, Aug 27, 2021 at 08:30:32PM +0200, Christian König wrote:
> Yeah, that's what I meant with that the start of processing a job is a bit
> swampy defined.
>
> Jobs overload, but we simply don't have another good indicator that a job
> started except that the previous one completed.
>
> It's
On Thu, Aug 26, 2021 at 11:04:14AM +0200, Daniel Vetter wrote:
> On Thu, Aug 19, 2021 at 11:25:09AM -0400, Andrey Grodzovsky wrote:
> >
> > On 2021-08-19 5:30 a.m., Daniel Vetter wrote:
> > > On Wed, Aug 18, 2021 at 10:51:00AM -0400, Andrey Grodzovsky wrote:
> > > > On 2021-08-18 10:42 a.m., Danie
On Tue, Aug 31, 2021 at 02:57:05PM +0200, Christian König wrote:
> Am 31.08.21 um 14:52 schrieb Daniel Vetter:
> > On Mon, Aug 30, 2021 at 10:56:59AM +0200, Christian König wrote:
> > > It makes sense to have this in the common manager for debugging and
> > > accounting of how much resources are us
On 31/08/2021 13:43, Daniel Vetter wrote:
On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote:
On 30/08/2021 09:26, Daniel Vetter wrote:
On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote:
On 27/08/2021 15:39, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In short th
On Tue, Aug 31, 2021 at 01:21:07PM +0200, Christian König wrote:
> More flexible than the busy placements.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 8 +++-
> include/drm/ttm/ttm_placement.h | 6 ++
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
From: Tvrtko Ursulin
It is not very useful to have code which tries to report a rapidly
transient state which will not report anything majority of the time,
especially since it is currently only used from
/i915_gem_framebuffers.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/
From: Tvrtko Ursulin
In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
when rendering is done on Intel dgfx and scanout/composition on Intel
igfx.
Before this patch the driver was not quite ready for that setup, mainly
because it was able to emit a semaphore wait between th
The labels are misleading. Even though they are all prefixed with 'fail_'
the success case also takes that path, and we should definitely not
cleanup the job if it's been queued. While at it, let's rename those
labels so we don't do the same mistake again.
Fixes: 53516280cc38 ("drm/panfrost: use s
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/bridge/cdns-dsi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/cdns-ds
It's says patch [2/2] but i can't find patch 1
On 2021-08-31 6:35 a.m., Monk Liu wrote:
tested-by: jingwen chen
Signed-off-by: Monk Liu
Signed-off-by: jingwen chen
---
drivers/gpu/drm/scheduler/sched_main.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
di
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dc
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/imx/imx-tve.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/dr
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/mcde/mcde_drv.c | 4 +---
drivers/gpu/drm/mcde/mcde_dsi.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
d
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/mediatek/mtk_cec.c| 4 +---
drivers/gpu/drm/mediatek/mtk_disp_aal.c | 4 +---
drivers/gpu/drm/mediatek/mtk_di
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoq
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_dr
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoq
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 +---
drivers/gpu/drm/rockchip/inno_hdmi.c | 4 +---
drivers/gpu/drm/rockchip/rockchip
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/shmobil
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 4 +---
drivers/gpu/drm/sun4i/sun4i_frontend.c | 4 +---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/tegra/dpaux.c | 4 +---
drivers/gpu/drm/tegra/dsi.c | 4 +---
drivers/gpu/drm/tegra/hdmi.c | 4 +---
drivers/gpu/drm
W dniu 31.08.2021 o 15:50, Cai Huoqing pisze:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Reviewed-by: Andrzej Hajda
Regards
Andrzej
Use the devm_platform_ioremap_resource() helper instead of
calling platform_get_resource() and devm_ioremap_resource()
separately
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/vc4/vc4_drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b
On Sat, Aug 28, 2021 at 12:26:39PM +0100, Paul Cercueil wrote:
> Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
> interface.
>
> Signed-off-by: Paul Cercueil
> ---
> .../bindings/display/panel/auo,a030jtn01
On Tue, Aug 31, 2021 at 09:53:36AM -0400, Andrey Grodzovsky wrote:
> It's says patch [2/2] but i can't find patch 1
>
> On 2021-08-31 6:35 a.m., Monk Liu wrote:
> > tested-by: jingwen chen
> > Signed-off-by: Monk Liu
> > Signed-off-by: jingwen chen
> > ---
> > drivers/gpu/drm/scheduler/sched_
On Tue, Aug 31, 2021 at 03:35:56PM +0200, Boris Brezillon wrote:
> The labels are misleading. Even though they are all prefixed with 'fail_'
> the success case also takes that path, and we should definitely not
> cleanup the job if it's been queued. While at it, let's rename those
> labels so we do
On Thu, 19 Aug 2021 at 08:01, Xin Ji wrote:
>
> Enable DSI EOTP feature for fixing some panel screen constant shift issue.
> Removing MIPI flag MIPI_DSI_MODE_NO_EOT_PACKET to enable DSI EOTP.
>
> Reviewed-by: Robert Foss
> Signed-off-by: Xin Ji
> ---
> drivers/gpu/drm/bridge/analogix/anx7625.c
v2 of https://patchwork.freedesktop.org/series/94161/ with the VESA OUI
check and an OUI helper patch added.
Jani Nikula (6):
drm/displayid: re-align data block macros
drm/displayid: add DisplayID v2.0 data blocks and primary use cases
drm/edid: abstract OUI conversion to 24-bit int
drm/ed
Make the values easier to read. Also add DisplayID Structure version and
revision information (this is different from the spec version).
Signed-off-by: Jani Nikula
---
include/drm/drm_displayid.h | 57 +++--
1 file changed, 29 insertions(+), 28 deletions(-)
diff
DisplayID v2.0 changes the data block identifiers and product types (now
called primary use cases).
Signed-off-by: Jani Nikula
---
include/drm/drm_displayid.h | 29 +
1 file changed, 29 insertions(+)
diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayi
Replace the open coded OUI conversion from three bytes to a 24-bit int,
as we'll be adding one more user shortly. No functional changes.
Side note: CTA-861 format has the OUI bytes in reverse order.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 17 +++--
1 file changed
The VESA Organization Vendor-Specific Data Block, defined in VESA
DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO)
stream count and segment pixel overlap.
DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension,
describing how DisplayID sections may be embedded in EDID ex
MSO will require segment pixel overlap information from the
EDID. Postpone MSO init until after we've read and cached the EDID.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/dis
Now that we have MSO pixel overlap in display info, use it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index
On Tue, 31 Aug 2021, Jani Nikula wrote:
> On Mon, 30 Aug 2021, Ville Syrjälä wrote:
>> Don't we need to check the OUI to make sure the block is the right
>> type? I don't have the v2 spec at hand atm, but I presume a vendor
>> specific block could contain all kinds of different things?
>
> You're
On 2021-08-31 10:03 a.m., Daniel Vetter wrote:
On Tue, Aug 31, 2021 at 09:53:36AM -0400, Andrey Grodzovsky wrote:
It's says patch [2/2] but i can't find patch 1
On 2021-08-31 6:35 a.m., Monk Liu wrote:
tested-by: jingwen chen
Signed-off-by: Monk Liu
Signed-off-by: jingwen chen
---
driv
On Mon, 30 Aug 2021 at 11:40, Neil Armstrong wrote:
>
> On 27/08/2021 18:39, Paul Cercueil wrote:
> > These two arrays are populated with data read from the I2C device
> > through regmap_read(), and the data is then compared with hardcoded
> > vendor/product ID values of supported chips.
> >
> > H
On Tue, 31 Aug 2021 at 15:58, Andrzej Hajda wrote:
>
>
> W dniu 31.08.2021 o 15:50, Cai Huoqing pisze:
> > Use the devm_platform_ioremap_resource() helper instead of
> > calling platform_get_resource() and devm_ioremap_resource()
> > separately
> >
> > Signed-off-by: Cai Huoqing
> Reviewed-by: An
On Sun, 22 Aug 2021 at 15:25, Laurent Pinchart
wrote:
>
> Hi Cai,
>
> Thank you for the patch.
>
> On Sun, Aug 22, 2021 at 03:21:11PM +0800, Cai Huoqing wrote:
> > use SPDX-License-Identifier instead of a verbose license text
> >
> > Signed-off-by: Cai Huoqing
>
> Reviewed-by: Laurent Pinchart
On 31/08/2021 15:56, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource_byname() helper instead of
> calling platform_get_resource_byname() and devm_ioremap_resource()
> separately
>
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_io
On Tue, Aug 31, 2021 at 10:20:40AM -0400, Andrey Grodzovsky wrote:
>
> On 2021-08-31 10:03 a.m., Daniel Vetter wrote:
> > On Tue, Aug 31, 2021 at 09:53:36AM -0400, Andrey Grodzovsky wrote:
> > > It's says patch [2/2] but i can't find patch 1
> > >
> > > On 2021-08-31 6:35 a.m., Monk Liu wrote:
>
On 2021-08-31 08:59, Daniel Vetter wrote:
> Can we please have some actual commit message here, with detailed
> explanation of the race/bug/whatever, how you fix it and why this is the
> best option?
I agree with Daniel--a narrative form of a commit message is so much easier
for humans to digest.
On Tue, Aug 31, 2021 at 02:16:56PM +0200, Daniel Vetter wrote:
> On Tue, Aug 31, 2021 at 11:38:27AM +0200, Maarten Lankhorst wrote:
> > Op 14-08-2021 om 12:43 schreef Daniel Vetter:
> > > The only reason for this really is the i915_gem_engines->fence
> > > callback engines_notify(), which exists pu
On Tue, 31 Aug 2021 11:49:24 +0800, Zenghui Yu wrote:
> The zte zx platform was removed in commit 89d4f98ae90d ("ARM: remove zte
> zx platform") and the zxdrm driver is going to be removed in v5.15 via
> drm tree. Let's remove the now obsolete binding doc.
>
> Cc: Arnd Bergmann
> Cc: Jun Nie
> C
On 2021-08-31 10:38 a.m., Daniel Vetter wrote:
On Tue, Aug 31, 2021 at 10:20:40AM -0400, Andrey Grodzovsky wrote:
On 2021-08-31 10:03 a.m., Daniel Vetter wrote:
On Tue, Aug 31, 2021 at 09:53:36AM -0400, Andrey Grodzovsky wrote:
It's says patch [2/2] but i can't find patch 1
On 2021-08-31 6:
On 2021/08/31 15:48, Geert Uytterhoeven wrote:
> Furthermore, this restricts the virtual frame buffer size on 64-bit,
> too, while graphics cards can have much more than 4 GiB of RAM.
Excuse me, but do you mean that some hardware allows allocating more than
UINT_MAX bytes of memory for kernel fram
On 2021-08-31 11:23, Andrey Grodzovsky wrote:
> On 2021-08-31 10:38 a.m., Daniel Vetter wrote:
>> On Tue, Aug 31, 2021 at 10:20:40AM -0400, Andrey Grodzovsky wrote:
>>> On 2021-08-31 10:03 a.m., Daniel Vetter wrote:
On Tue, Aug 31, 2021 at 09:53:36AM -0400, Andrey Grodzovsky wrote:
> It's
On Tue, Aug 31, 2021 at 5:24 PM Tetsuo Handa
wrote:
> On 2021/08/31 15:48, Geert Uytterhoeven wrote:
> > Furthermore, this restricts the virtual frame buffer size on 64-bit,
> > too, while graphics cards can have much more than 4 GiB of RAM.
>
> Excuse me, but do you mean that some hardware allows
Hi Roman!
Dne petek, 27. avgust 2021 ob 15:16:03 CEST je Roman Stratiienko napisal(a):
> +CC: jernej.skra...@gmail.com
>
> пт, 27 авг. 2021 г. в 16:12, Roman Stratiienko :
> >
> > Hello Jernej,
> >
> > During local testing I faced an issue where YV12 buffers are displayed
> > all in blue.
> >
> >
Hi!
Dne petek, 27. avgust 2021 ob 15:16:03 CEST je Roman Stratiienko napisal(a):
> +CC: jernej.skra...@gmail.com
>
> пт, 27 авг. 2021 г. в 16:12, Roman Stratiienko :
> >
> > Hello Jernej,
> >
> > During local testing I faced an issue where YV12 buffers are displayed
> > all in blue.
> >
> > Issue
Hi Jernej,
вт, 31 авг. 2021 г. в 19:52, Jernej Škrabec :
>
> Hi!
>
> Dne petek, 27. avgust 2021 ob 15:16:03 CEST je Roman Stratiienko napisal(a):
> > +CC: jernej.skra...@gmail.com
> >
> > пт, 27 авг. 2021 г. в 16:12, Roman Stratiienko :
> > >
> > > Hello Jernej,
> > >
> > > During local testing I
1 - 100 of 164 matches
Mail list logo
