Use sysfs_emit() instead of snprintf().
Signed-off-by: Guo Zhengkui
---
drivers/video/fbdev/omap/omapfb_main.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/omap/omapfb_main.c
b/drivers/video/fbdev/omap/omapfb_main.c
index
Hi David, Daniel,
On Fri, 19 Nov 2021 at 06:54, Jeremy Kerr wrote:
>
> Hi Joel,
>
> > Before the drm driver had support for this file there was a driver
> > that exposed the contents of the vga password register to userspace.
> > It would present the entire register instead of interpreting it.
>
Hi Linus,
This week's fixes, pretty quiet, about right for rc2. amdgpu is the
bulk of them but the scheduler ones have been reported in a few places
I think.
Otherwise just some minor i915 fixes and a few other scattered around.
Dave.
drm-fixes-2021-11-19:
drm fixes for 5.16-rc2
scheduler:
-
As GPIO probe function "devm_gpiod_get_optional()" may return error
code, driver should identify GPIO desc as NULL to avoid crash.
Acked-by: Tzung-Bi Shih
Signed-off-by: Xin Ji
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 9 +
1 file changed, 9 insertions(+)
diff --git
On Fri, Nov 19, 2021 at 03:30:02AM +0800, Hsin-Yi Wang wrote:
> edid_read() was assumed to return 0 on success. After
> 7f16d0f3b8e2("drm/bridge: anx7625: Propagate errors from sp_tx_rst_aux()"),
> the function will return > 0 for successful case, representing the i2c
> read bytes. Otherwise -EIO
Hi Pekka,
Thanks for the thoughts and review. I've tried to respond below:
On Thu, Nov 18, 2021 at 12:39:28PM +0200, Pekka Paalanen wrote:
> On Wed, 17 Nov 2021 14:48:40 -0800
> Brian Norris wrote:
>
> > A variety of applications have found it useful to listen to
> > user-initiated input
Quoting Kuogee Hsieh (2021-11-09 13:38:13)
> From: Kuogee Hsieh
>
> Current DP drivers have regulators, clocks, irq and phy are grouped
> together within a function and executed not in a symmetric manner.
> This increase difficulty of code maintenance and limited code scalability.
> This patch
Hi, Jason:
jason-jh.lin 於 2021年11月17日 週三 下午2:42寫道：
>
> CMDQ driver will occupy GCE clock to execute the task in GCE thread.
>
> So call cmdq_mbox_flush to clear all task in GCE thread before
> CMDQ suspend.
>
> Signed-off-by: jason-jh.lin
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 9
On Thu, Nov 18, 2021 at 2:39 AM Pekka Paalanen wrote:
>
> On Wed, 17 Nov 2021 14:48:40 -0800
> Brian Norris wrote:
>
> > A variety of applications have found it useful to listen to
> > user-initiated input events to make decisions within a DRM driver, given
> > that input events are often the
On Tue, Nov 16, 2021 at 03:35:03PM +0100, Maxime Ripard wrote:
> Following the previous patch, let's introduce a generic panel-lvds
> binding that documents the panels that don't have any particular
> constraint documented.
>
> Signed-off-by: Maxime Ripard
> ---
>
On Tue, Nov 16, 2021 at 03:35:02PM +0100, Maxime Ripard wrote:
> The lvds.yaml file so far was both defining the generic LVDS properties
> (such as data-mapping) that could be used for any LVDS sink, but also
> the panel-lvds binding.
>
> That last binding was to describe LVDS panels simple
On Thu, 18 Nov 2021 at 21:13, Dan Carpenter wrote:
>
> The nvkm_acr_lsfw_add() function never returns NULL. It returns error
> pointers on error.
>
> Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace
> "secure boot"")
> Signed-off-by: Dan Carpenter
Reviewed-by: Ben Skeggs
Hi Dave and Daniel,
Here goes drm-intel-fixes-2021-11-18:
One quick fix for return error handling, one fix for ADL-P display
and one revert targeting stable 5.4, for TGL's DSI display clocks
Thanks,
Rodrigo.
The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:
Linux
Applied. Thanks!
Alex
On Thu, Nov 18, 2021 at 5:57 AM Jiapeng Chong
wrote:
>
> Eliminate the follow smatch warning:
>
> drivers/gpu/drm/amd/amdgpu/../pm/powerplay/amd_powerplay.c:1554
> pp_asic_reset_mode_2() warn: inconsistent indenting.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng
Hi Vinod,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v5.16-rc1 next-2028]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented
On Fri, Oct 22, 2021 at 4:35 AM Dmitry Baryshkov
wrote:
>
> Hi,
>
> On Fri, 22 Oct 2021 at 02:53, wrote:
> >
> > On 2021-09-30 07:00, Dmitry Baryshkov wrote:
> > > In preparations of virtualizing the dpu_plane rip out debugfs support
> > > from dpu_plane (as it is mostly used to expose plane's
Certain gen8 ppgtt/gtt functions are using _PAGE_RW and _PAGE_PRESENT to check
bits 0 and 1 for PTEs. These macros are defined per architectures, and some
architectures do not have these defined (like arm64). This patch replaces these
two macros with their i915 equivalent implementation.
Instead of using _PAGE_RW and _PAGE_PRESENT to check for 0 and 1 bits, this
series replaces them with GEN6_PTE_VALID and BYT_PTE_WRITEABLE. We should be
using
macros defined for i915 to check these bits, instead of macros defined by the
mmu.
Some arch does not have these macros defined, thus
On Thu, Nov 18, 2021 at 10:30 AM Dave Stevenson
wrote:
>
> On Thu, 18 Nov 2021 at 17:36, Tim Harvey wrote:
> >
> > On Thu, Nov 18, 2021 at 6:28 AM Dave Stevenson
> > wrote:
> > >
> > > Hi Tim
> > >
> > > On Thu, 18 Nov 2021 at 01:26, Tim Harvey wrote:
> > > >
> > > > Greetings,
> > > >
> > > >
On 10/29/2021 10:14 AM, Brian Starkey wrote:
Hi,
On Fri, Oct 29, 2021 at 09:15:28AM -0400, George Kennedy wrote:
Asking if you have any input on how to deal with hsub and vsub = zero?
That's just a straight mistake on those formats - they should
be 1. My bad for not spotting it in review.
Hi Daniel,
Thanks for the review. Lots to address elsewhere, but I can respond
here first:
On Thu, Nov 18, 2021 at 10:05:11AM +0100, Daniel Vetter wrote:
> On Wed, Nov 17, 2021 at 02:48:40PM -0800, Brian Norris wrote:
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@
edid_read() was assumed to return 0 on success. After
7f16d0f3b8e2("drm/bridge: anx7625: Propagate errors from sp_tx_rst_aux()"),
the function will return > 0 for successful case, representing the i2c
read bytes. Otherwise -EIO on failure cases. Update the g_edid_break
break condition accordingly.
On Fri, Nov 19, 2021 at 12:52 AM Guenter Roeck wrote:
>
> On Fri, Nov 12, 2021 at 07:24:33PM +0800, Hsin-Yi Wang wrote:
> > edid_read() was assumed to return 0 on success. After
> > 7f16d0f3b8e2("drm/bridge: anx7625: Propagate errors from sp_tx_rst_aux()"),
> > the function can return >= 0 for
Am 2021-11-18 um 1:53 a.m. schrieb Alistair Popple:
> On Tuesday, 16 November 2021 6:30:18 AM AEDT Alex Sierra wrote:
>> Device memory that is cache coherent from device and CPU point of view.
>> This is used on platforms that have an advanced system bus (like CAPI
>> or CXL). Any page of a
On Thu, 18 Nov 2021 at 17:44, Marek Vasut wrote:
>
> On 11/18/21 6:02 PM, Tim Harvey wrote:
> > On Thu, Nov 18, 2021 at 4:53 AM Marek Vasut wrote:
> >>
> >> On 11/18/21 2:25 AM, Tim Harvey wrote:
> >>> Greetings,
> >>>
> >>> I'm trying to get a RPI 7" touchscreen display working on an IMX8MM
>
On Thu, 18 Nov 2021 at 17:36, Tim Harvey wrote:
>
> On Thu, Nov 18, 2021 at 6:28 AM Dave Stevenson
> wrote:
> >
> > Hi Tim
> >
> > On Thu, 18 Nov 2021 at 01:26, Tim Harvey wrote:
> > >
> > > Greetings,
> > >
> > > I'm trying to get a RPI 7" touchscreen display working on an IMX8MM
> > > board
On 11/18/21 6:02 PM, Tim Harvey wrote:
On Thu, Nov 18, 2021 at 4:53 AM Marek Vasut wrote:
On 11/18/21 2:25 AM, Tim Harvey wrote:
Greetings,
I'm trying to get a RPI 7" touchscreen display working on an IMX8MM
board and while I've been able to get the MIPI DSI display and
backlight working I
On Thu, Nov 18, 2021 at 6:28 AM Dave Stevenson
wrote:
>
> Hi Tim
>
> On Thu, 18 Nov 2021 at 01:26, Tim Harvey wrote:
> >
> > Greetings,
> >
> > I'm trying to get a RPI 7" touchscreen display working on an IMX8MM
> > board and while I've been able to get the MIPI DSI display and
> > backlight
On Thu, Nov 18, 2021 at 4:53 AM Marek Vasut wrote:
>
> On 11/18/21 2:25 AM, Tim Harvey wrote:
> > Greetings,
> >
> > I'm trying to get a RPI 7" touchscreen display working on an IMX8MM
> > board and while I've been able to get the MIPI DSI display and
> > backlight working I still can't seem to
This is a revert of commits
d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as
irqsafe")
6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by
timeline->mutex")
The existing code leads to a different behaviour depending on whether
lockdep is
On Fri, Nov 12, 2021 at 07:24:33PM +0800, Hsin-Yi Wang wrote:
> edid_read() was assumed to return 0 on success. After
> 7f16d0f3b8e2("drm/bridge: anx7625: Propagate errors from sp_tx_rst_aux()"),
> the function can return >= 0 for successful case. Fix the g_edid_break
> condition in
Hi Akhil,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next v5.16-rc1 next-2028]
[If your patch is applied to the wrong git tree, kindly drop us
On Thu, 18 Nov 2021 09:29:27 -0500
Jason Baron wrote:
> On 11/16/21 3:46 AM, Pekka Paalanen wrote:
> > On Fri, 12 Nov 2021 10:08:41 -0500
> > Jason Baron wrote:
> >
> >> On 11/12/21 6:49 AM, Vincent Whitchurch wrote:
> >>> On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
>
Hello AngeloGioacchino Del Regno,
The patch a19125a28112: "drm/panel: Add BOE BF060Y8M-AJ0 5.99" AMOLED
panel driver" from Sep 1, 2021, leads to the following (unpublished)
Smatch static checker warning:
drivers/gpu/drm/panel/panel-boe-bf060y8m-aj0.c:317
boe_bf060y8m_aj0_init_vregs() info:
Hey Hsin-Yi,
Thanks for catching this.
checkpatch --strict is throwing an error for this patch. With that,
feel free to add my r-b.
Reviewed-by: Robert Foss
On Fri, 12 Nov 2021 at 12:24, Hsin-Yi Wang wrote:
>
> edid_read() was assumed to return 0 on success. After
> 7f16d0f3b8e2("drm/bridge:
+ Zhen & Vinay
This patch looks good in itself, but I would like to see a tested by
tag. At the very least testing for regression in single-link LVDS but
ideally some third party verification of this patch.
On Wed, 10 Nov 2021 at 23:01, Jiri Vanek wrote:
>
> Fixed wrong register shift for
On 11/16/21 3:46 AM, Pekka Paalanen wrote:
> On Fri, 12 Nov 2021 10:08:41 -0500
> Jason Baron wrote:
>
>> On 11/12/21 6:49 AM, Vincent Whitchurch wrote:
>>> On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
Sean Paul proposed, in:
On 18/11/2021 13:02, Thomas Hellström wrote:
With async migration, the shrinker may end up wanting to release the
pages of an object while the migration blit is still running, since
the GT migration code doesn't set up VMAs and the shrinker is thus
oblivious to the fact that the GPU is still
Hi Tim
On Thu, 18 Nov 2021 at 01:26, Tim Harvey wrote:
>
> Greetings,
>
> I'm trying to get a RPI 7" touchscreen display working on an IMX8MM
> board and while I've been able to get the MIPI DSI display and
> backlight working I still can't seem to figure out the touch
> controller.
>
> It's
On 18/11/2021 13:02, Thomas Hellström wrote:
There is an interesting refcounting loop:
struct intel_memory_region has a struct ttm_resource_manager,
ttm_resource_manager->move may hold a reference to i915_request,
i915_request may hold a reference to intel_context,
intel_context may hold a
On 18/11/2021 13:02, Thomas Hellström wrote:
From: Maarten Lankhorst
For now, we will only allow async migration when TTM is used,
so the paths we care about are related to TTM.
The mmap path is handled by having the fence in ttm_bo->moving,
when pinning, the binding only becomes available
Hi Daniel,
On Thu, Nov 18, 2021 at 01:02:11PM +, Daniel Stone wrote:
> Hi all,
> Thanks for this Laurent. Esaki-san, could you please CC dri-devel@ on
> discussions like this?
>
> On Thu, 18 Nov 2021 at 12:32, Laurent Pinchart wrote:
> > On Sat, May 11, 2019 at 09:10:27PM +0300, Laurent
Hi Andy,
On Thu, 18 Nov 2021 at 13:14, Andy Yan wrote:
> On 11/18/21 8:07 PM, Daniel Stone wrote:
> > Technically, the driver cannot be upstreamed as-is. It looks as if it
> > were a pre-atomic driver, that was half-converted to atomic, and then
> > has been half-converted to atomic helpers as
Hi Daniel:
On 11/18/21 8:07 PM, Daniel Stone wrote:
Hi Kever,
On Thu, 18 Nov 2021 at 10:50, Kever Yang wrote:
On 2021/11/18 下午5:53, Daniel Stone wrote:
Exactly what Heiko said. If you would like to upstream the driver then
that would be fantastic to see, but I'm afraid you do not get to
With async migration, the shrinker may end up wanting to release the
pages of an object while the migration blit is still running, since
the GT migration code doesn't set up VMAs and the shrinker is thus
oblivious to the fact that the GPU is still using the pages.
Add waiting for gpu in the
Update the copy function i915_gem_obj_copy_ttm() to be asynchronous for
future users and update the only current user to sync the objects
as needed after this function.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 40 ++--
There is an interesting refcounting loop:
struct intel_memory_region has a struct ttm_resource_manager,
ttm_resource_manager->move may hold a reference to i915_request,
i915_request may hold a reference to intel_context,
intel_context may hold a reference to drm_i915_gem_object,
Don't wait sync while migrating, but rather make the GPU blit await the
dependencies and add a moving fence to the object.
This also enables asynchronous VRAM management in that on eviction,
rather than waiting for the moving fence to expire before freeing VRAM,
it is freed immediately and the
Move the i915_gem_obj_copy_ttm() function to i915_gem_ttm_move.h.
This will help keep a number of functions static when introducing
async moves.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 47 ---
From: Maarten Lankhorst
For now, we will only allow async migration when TTM is used,
so the paths we care about are related to TTM.
The mmap path is handled by having the fence in ttm_bo->moving,
when pinning, the binding only becomes available after the moving
fence is signaled, and pinning a
This patch series deals with async migration and async vram management.
It still leaves an important part out, which is async unbinding which
will reduce latency further, at least when trying to migrate already active
objects.
Patches 1/6 deals with accessing and waiting for the TTM moving
fence
Hi all,
Thanks for this Laurent. Esaki-san, could you please CC dri-devel@ on
discussions like this?
On Thu, 18 Nov 2021 at 12:32, Laurent Pinchart
wrote:
> On Sat, May 11, 2019 at 09:10:27PM +0300, Laurent Pinchart wrote:
> > On Thu, May 09, 2019 at 06:25:19PM +0900, Esaki Tomohito wrote:
> > >
On 11/18/21 2:25 AM, Tim Harvey wrote:
Greetings,
I'm trying to get a RPI 7" touchscreen display working on an IMX8MM
board and while I've been able to get the MIPI DSI display and
backlight working I still can't seem to figure out the touch
controller.
It's supposed to have an FT5406
Hello Esaki-san,
(CC'ing dri-devel and Daniel Stone)
On Sat, May 11, 2019 at 09:10:27PM +0300, Laurent Pinchart wrote:
> On Thu, May 09, 2019 at 06:25:19PM +0900, Esaki Tomohito wrote:
> > Hi Laurent-san
> >
> > > What's the purpose of this, as it adds no new functionality to the
> > > driver ?
Hi Kever,
On Thu, 18 Nov 2021 at 10:50, Kever Yang wrote:
> On 2021/11/18 下午5:53, Daniel Stone wrote:
> > Exactly what Heiko said. If you would like to upstream the driver then
> > that would be fantastic to see, but I'm afraid you do not get to
> > prevent someone else from doing the work
Hi,
On 11/7/21 12:27, Yauhen Kharuzhy wrote:
> On Sun, Nov 07, 2021 at 11:12:56AM +0100, Sam Ravnborg wrote:
>> Hi Yauhen,
>> On Sun, Nov 07, 2021 at 12:59:11AM +0300, Yauhen Kharuzhy wrote:
>>> On Sat, Nov 06, 2021 at 02:02:27PM +0100, Hans de Goede wrote:
The Lenovo Yoga Book X91F/L uses a
Hi,
On 10/25/21 10:17, Jani Nikula wrote:
> On Sun, 24 Oct 2021, Hans de Goede wrote:
>> In intel_dsi_get_config() double the pclk returned by foo_dsi_get_pclk()
>> for dual-link panels. This fixes the following WARN triggering:
>>
>> i915 :00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch
Hi,
On 11/18/21 12:12, Dan Carpenter wrote:
> The devm_gen_pool_create() function never returns NULL, it returns
> error pointers.
>
> Fixes: 4cc9b565454b ("drm/vboxvideo: Use devm_gen_pool_create")
> Signed-off-by: Dan Carpenter
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
I
Hi,
Le lun., nov. 15 2021 at 14:19:21 +, Paul Cercueil
a écrit :
We can be certain that the input buffers will only be accessed by
userspace for reading, and output buffers will mostly be accessed by
userspace for writing.
Therefore, it makes more sense to use only fully cached input
The drm_gem_shmem_get_sg_table() function never returns NULL. It returns
error pointers on error.
Fixes: c66df701e783 ("drm/virtio: switch from ttm to gem shmem helpers")
Signed-off-by: Dan Carpenter
---
v2: I originally sent this patch on 19 Jun 2020 but it was somehow
not applied. As I
The ->gem_create_object() function pointers are supposed to return NULL
on error. This function returns an error pointer but none of the
callers expect that so it will lead to an Oops. See drm_gem_vram_create()
for example of it checks for NULL but an error pointer would lead to a
crash.
Fixes:
The ->gem_create_object() functions are supposed to return NULL if there
is an error. None of the callers expect error pointers so returing one
will lead to an Oops. See drm_gem_vram_create(), for example.
Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.")
Signed-off-by: Dan Carpenter
---
The nvkm_acr_lsfw_add() function never returns NULL. It returns error
pointers on error.
Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure
boot"")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/nouveau/nvkm/subdev/acr/gm200.c | 6 --
The devm_gen_pool_create() function never returns NULL, it returns
error pointers.
Fixes: 4cc9b565454b ("drm/vboxvideo: Use devm_gen_pool_create")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/vboxvideo/vbox_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hello Kever,
On 11/18/21 11:50 AM, Kever Yang wrote:
On 2021/11/18 下午5:53, Daniel Stone wrote:
Hi,
On Thu, 18 Nov 2021 at 09:26, Heiko Stübner wrote:
Am Donnerstag, 18. November 2021, 02:27:10 CET schrieb Kever Yang:
I don't agree with this, we do believe you have do some clean up to
meet
Eliminate the follow smatch warning:
drivers/gpu/drm/amd/amdgpu/../pm/powerplay/amd_powerplay.c:1554
pp_asic_reset_mode_2() warn: inconsistent indenting.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 2 +-
1 file changed, 1
On 2021/11/18 下午5:53, Daniel Stone wrote:
Hi,
On Thu, 18 Nov 2021 at 09:26, Heiko Stübner wrote:
Am Donnerstag, 18. November 2021, 02:27:10 CET schrieb Kever Yang:
I don't agree with this, we do believe you have do some clean up to meet
the requirement
of upstream, but all the framework
On Thu, Nov 18, 2021 at 02:42:58PM +0800, Jian-Hong Pan wrote:
> Maxime Ripard 於 2021年11月17日 週三 下午5:45寫道：
> > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert
> > to
> > atomic helpers") introduced a number of issues in corner cases, most of them
> > showing themselves
On Wed, 17 Nov 2021 14:48:40 -0800
Brian Norris wrote:
> A variety of applications have found it useful to listen to
> user-initiated input events to make decisions within a DRM driver, given
> that input events are often the first sign that we're going to start
> doing latency-sensitive
Our detect callback has a bunch of operations to perform depending on
the current and last status of the connector, such a setting the CEC
physical address or enabling the scrambling again.
This is currently dealt with a bunch of if / else statetements that make
it fairly difficult to read and
When we have the entire DRM state, retrieving the connector state only
requires the drm_connector pointer. Fortunately for us, we have
allocated it as a part of the vc4_hdmi structure, so we can retrieve get
a pointer by simply accessing our field in that structure.
Signed-off-by: Maxime Ripard
Enabling the scrambling on reconnection seems to work so far but breaks
the HDMI2.0 specification and has introduced some issues in the past
with i915.
Let's do a mode set on the connector instead to follow the
specification.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 11
Now that we have a generic helper to fill the scrambling status, let's
use it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 46 +++---
drivers/gpu/drm/vc4/vc4_hdmi.h | 6 +
2 files changed, 21 insertions(+), 31 deletions(-)
diff --git
We'll need the locking context in future patch, so let's convert .detect
to .detect_ctx.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
The hdmi_monitor flag in the vc4_hdmi_encoder structure is redundant
with the is_hdmi flag in the drm_display_info structure.
Let's convert all the users.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 16 ++--
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 -
2 files
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 16
drivers/gpu/drm/vc4/vc4_hdmi.h | 2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 053fbaf765ca..b00fedb5b880 100644
Even though vc4_hdmi_supports_scrambling takes a mode as an argument, it
never uses it. Let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c
We recently introduced a new mutex to protect concurrent execution of
ALSA and KMS hooks, and the concurrent access to some of vc4_hdmi
fields.
However, using it in the detect hook was creating a reentrency issue
with CEC code. Indeed, calling cec_s_phys_addr_from_edid from detect
might call the
All the drivers that implement the HDMI scrambling setup (dw-hdmi, i915,
tegra, vc4) duplicate the same logic to see if the TMDS ratio or the
scrambling state needs to be modified depending on the current connector
state and CRTC mode.
Since it's basically the same logic everywhere, let's put
There's some interactions between the SCDC setup and the disconnection /
reconnection of displays. Let's document it and a solution.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_scdc_helper.c | 13 +
1 file changed, 13 insertions(+)
diff --git
During a hotplug cycle (such as a TV going out of suspend, or when the
cable is disconnected and reconnected), the expectation is that the same
state used before the disconnection is reused until the next commit.
However, the HDMI scrambling requires that some flags are set in the
monitor, and
Most drivers supporting the HDMI scrambling seem to have the HDMI 1.4
maximum frequency open-coded, and a function to test whether a display
mode is above that threshold to control whether or not scrambling should
be enabled.
Let's create a common define and helper for drivers to reuse.
Hi,
This is a follow-up of the work to support the interactions between the hotplug
and the scrambling support for vc4:
https://lore.kernel.org/dri-devel/20210507150515.257424-11-max...@cerno.tech/
https://lore.kernel.org/dri-devel/20211025152903.1088803-10-max...@cerno.tech/
Ville feedback was
On 2021-11-08 17:00, Daniel Vetter wrote:
> On Mon, Nov 08, 2021 at 04:34:53PM +0100, Jocelyn Falempe wrote:
>> When using Xorg/Logind and an external monitor connected with an MST dock.
>> After disconnecting the external monitor, switching to VT may not work,
>> the (internal) monitor sill
Capture gmu log in coredump to enhance debugging.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 41 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 2 ++
3 files changed, 44
Avoid a possible uninitialized use of gpu_scid variable to fix the
below smatch warning:
drivers/gpu/drm/msm/adreno/a6xx_gpu.c:1480 a6xx_llc_activate()
error: uninitialized symbol 'gpu_scid'.
Reported-by: Dan Carpenter
Signed-off-by: Akhil P Oommen
---
Fix the below null pointer dereference in msm_ioctl_gem_submit():
26545.260705: Call trace:
26545.263223:kref_put+0x1c/0x60
26545.266452:msm_ioctl_gem_submit+0x254/0x744
26545.270937:drm_ioctl_kernel+0xa8/0x124
26545.274976:drm_ioctl+0x21c/0x33c
26545.278478:
Currently, we boost gpu freq after 25ms of inactivity. This regresses
some of the 30 fps usecases where the workload on gpu (at 33ms internval)
is very small which it can finish at the lowest OPP before the deadline.
Lets increase this inactivity threshold to 50ms (same as the current
devfreq
On Thu, Nov 18, 2021 at 10:26:29AM +0100, Heiko Stübner wrote:
> Hi Kever,
>
> Am Donnerstag, 18. November 2021, 02:27:10 CET schrieb Kever Yang:
> > Hi Sascha Hauer,
> >
> > On 2021/11/17 下午10:33, Sascha Hauer wrote:
> > > This series adds initial graphics support for the Rockchip RK356[68]
> >
On 18/11/2021 06:57, Thomas Hellström wrote:
On Wed, 2021-11-17 at 19:49 +0100, Thomas Hellström wrote:
On 11/17/21 15:20, Matthew Auld wrote:
In intel_context_do_pin_ww, when calling into the pre_pin
hook(which is
passed the ww context) it could in theory return -EDEADLK(which is
very
likely
Hi,
On Thu, 18 Nov 2021 at 09:26, Heiko Stübner wrote:
> Am Donnerstag, 18. November 2021, 02:27:10 CET schrieb Kever Yang:
> > I don't agree with this, we do believe you have do some clean up to meet
> > the requirement
> >
> > of upstream, but all the framework and feature implement are from
>
On Mon, 15 Nov 2021 15:17:45 +0530
Bhanuprakash Modem wrote:
> From the Plane Color Management feature design, userspace can
> take the smart blending decisions based on hardware supported
> plane color features to obtain an accurate color profile.
>
> These IGT patches extend the existing pipe
On Mon, 15 Nov 2021 15:17:57 +0530
Bhanuprakash Modem wrote:
> From: Mukunda Pramodh Kumar
>
> Add helper functions to support logarithmic gamma mode
>
> Cc: Harry Wentland
> Cc: Ville Syrjälä
> Cc: Juha-Pekka Heikkila
> Cc: Uma Shankar
> Signed-off-by: Mukunda Pramodh Kumar
>
On Mon, 15 Nov 2021 15:17:56 +0530
Bhanuprakash Modem wrote:
> From: Mukunda Pramodh Kumar
>
> Add support for Pipe color management properties.
The commit summary and message are misleading.
This patch makes igt recognise the CRTC GAMMA_MODE KMS property.
Thanks,
pq
>
> Cc: Harry
On Mon, 15 Nov 2021 15:17:53 +0530
Bhanuprakash Modem wrote:
> To verify Plane gamma, draw 3 gradient rectangles in red, green and blue,
> with a maxed out gamma LUT and verify we have the same frame dump as
> drawing solid color rectangles.
>
> Cc: Harry Wentland
> Cc: Ville Syrjälä
> Cc:
Hi Kever,
Am Donnerstag, 18. November 2021, 02:27:10 CET schrieb Kever Yang:
> Hi Sascha Hauer,
>
> On 2021/11/17 下午10:33, Sascha Hauer wrote:
> > This series adds initial graphics support for the Rockchip RK356[68]
> > SoCs. Graphics support is based around the VOP2 controller which
> >
From: Laurent Pinchart
The SN65DSI8x EN signal may be tied to VCC, or otherwise controlled by
means not available to the kernel. Make the GPIO optional.
Signed-off-by: Laurent Pinchart
Acked-by: Rob Herring
Signed-off-by: Alexander Stein
---
Add a VCC regulator which needs to be enabled before the EN pin is
released.
Reviewed-by: Sam Ravnborg
Acked-by: Rob Herring
Signed-off-by: Alexander Stein
---
.../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 4
1 file changed, 4 insertions(+)
diff --git
The enable signal may not be controllable by the kernel. Make it
optional.
This is a similar to commit bbda1704fc15 ("drm/bridge: ti-sn65dsi86: Make
enable GPIO optional")
Reviewed-by: Laurent Pinchart
Reviewed-by: Sam Ravnborg
Signed-off-by: Alexander Stein
---
VCC needs to be enabled before releasing the enable GPIO.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index
1 - 100 of 113 matches
Mail list logo
