On Thu, Nov 2, 2023 at 10:26 PM AngeloGioacchino Del Regno
wrote:
>
> Currently, the GPU is being internally powered off for runtime suspend
> and turned back on for runtime resume through commands sent to it, but
> note that the GPU doesn't need to be clocked during the poweroff state,
> hence
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Friday, October 13, 2023 6:44 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/4] drm/i915: s/clamp()/min()/ in
> i965_lut_11p6_max_pack()
>
> From:
> -Original Message-
> From: Christian König
> Sent: Thursday, November 2, 2023 9:24 AM
> To: Zeng, Oak ; dri-devel@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org
> Cc: thomas.hellst...@linux.intel.com; felix.kuehl...@amd.com;
> airl...@gmail.com; Welty, Brian
> Subject:
On Fri, 3 Nov 2023 at 12:41, Danilo Krummrich wrote:
>
> Do not return from gf100_gr_chan_new() with fecs mutex held when failing
> to create the golden context image.
Reviewed-by: Dave Airlie
>
> Cc: # v6.2+
> Fixes: ca081fff6ecc ("drm/nouveau/gr/gf100-: generate golden context during
>
> -Original Message-
> From: Christian König
> Sent: Thursday, November 2, 2023 8:53 AM
> To: Zeng, Oak ; dri-devel@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org
> Cc: thomas.hellst...@linux.intel.com; felix.kuehl...@amd.com;
> airl...@gmail.com; Welty, Brian
> Subject:
Hi Linus,
As I mentioned in my main pullreq I had a chancy optional nouveau one
that is delayed after Ben's departure, but I'd really like to land
support for the NVIDIA Ada chips and this is the only way that can
happen. This new firmware supports Turing/Ampere/Ada, but it's off by
default to
Do not return from gf100_gr_chan_new() with fecs mutex held when failing
to create the golden context image.
Cc: # v6.2+
Fixes: ca081fff6ecc ("drm/nouveau/gr/gf100-: generate golden context during
first object alloc")
Signed-off-by: Danilo Krummrich
---
Fix smatch warning:
drivers/gpu/drm/i915/gem/i915_gem_context.c:847 set_proto_ctx_sseu()
warn: potential spectre issue 'pc->user_engines' [r] (local cap)
Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create
parameters (v5)")
Cc: # v5.15+
Signed-off-by: Kunwu Chan
Hi Tvrtko,
Thank you very much for your kind suggestion, I have modified it in
accordance with your suggestion.
On 2023/11/2 19:32, Tvrtko Ursulin wrote:
On 02/11/2023 10:16, chentao wrote:
Fix smatch warning:
drivers/gpu/drm/i915/gem/i915_gem_context.c:847 set_proto_ctx_sseu()
warn:
For the series:
Reviewed-by: Danilo Krummrich
On 10/31/23 06:18, Dave Airlie wrote:
This moves Ben's work to the latest GSP stable firmware 535.113.01.
We will be stuck on this for a while.
There is also a fix for a message signature, and additions of two
registry entries, which seem to help
Hi,
On Thu, Nov 02, 2023 at 11:32:43AM +, Tvrtko Ursulin wrote:
> On 02/11/2023 10:16, chentao wrote:
> > Fix smatch warning:
> > drivers/gpu/drm/i915/gem/i915_gem_context.c:847 set_proto_ctx_sseu()
> > warn: potential spectre issue 'pc->user_engines' [r] (local cap)
> >
> > Signed-off-by:
On 2023-11-02 07:13, Tvrtko Ursulin wrote:
>
> On 31/10/2023 03:24, Matthew Brost wrote:
>> Rather than call free_job and run_job in same work item have a dedicated
>> work item for each. This aligns with the design and intended use of work
>> queues.
>>
>> v2:
>> - Test for
On Thu, Nov 2, 2023 at 1:07 PM Sudip Mukherjee
wrote:
>
> On Thu, 2 Nov 2023 at 16:52, Alex Deucher wrote:
> >
> > On Thu, Nov 2, 2023 at 5:32 AM Sudip Mukherjee (Codethink)
> > wrote:
> > >
> > > Hi All,
> > >
> > > The latest mainline kernel branch fails to build x86_64 allmodconfig
> > >
Eliminate drm_sched_run_job_queue_if_ready() and instead just call
drm_sched_run_job_queue() in drm_sched_free_job_work(). The problem is that
the former function uses drm_sched_select_entity() to determine if the
scheduler had an entity ready in one of its run-queues, and in the case of the
Add a function to clear the preferred bit of a connector's existing modes.
This is useful for edp panel to unset the preferred modes read from edid
if the panel has hard-coded modes.
Signed-off-by: Hsin-Yi Wang
---
v1->v2:
- fix doc string (reported by kernel test robot).
- split mode and panel
If a non generic edp-panel is under aux-bus, the mode read from edid would
still be selected as preferred and results in multiple preferred modes,
which is ambiguous.
If a hard-coded mode is present, unset the preferred bit of the modes read
from edid.
Signed-off-by: Hsin-Yi Wang
---
v1->v2:
Generic edp gets mode from edid. However, some panels report incorrect
mode in this way, resulting in glitches on panel. Introduce a new quirk
additional_mode to the generic edid to pick a correct hardcoded mode.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Douglas Anderson
---
v1->v2: no change
Add a few generic edp panels used by mt8186 chromebooks.
Besides, modify the following panel:
- AUO 0x235c B116XTN02 renamed to B116XTN02.3.
- AUO 0x405c B116XAK01 adjust the timing of auo_b116xak01. According
to the datasheet: T3=200, T12=500, T7_max = 50.
Signed-off-by: Hsin-Yi Wang
---
This series contains 4 patches:
1. Add a few new generic edp panels.
2. Support a new quirk to override the mode read from edid
3-4. Unset preferred mode from edid if hard-coded mode presents.
v1:
https://patchwork.kernel.org/project/dri-devel/cover/20231101212604.1636517-1-hsi...@chromium.org/
On Thu, Nov 2, 2023 at 9:54 AM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Nov 1, 2023 at 2:26 PM Hsin-Yi Wang wrote:
> >
> > Add a few generic edp panels used by mt8186 chromebooks.
> > Besides, modify the following panel:
> > - AUO 0x235c B116XTN02 renamed to B116XTN02.3.
> > - AUO 0x405c
On Fri, Oct 27, 2023 at 02:18:14PM -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> These w/a's can have signficant performance implications for any
> workload which uses both RCS and CCS. On the other hand, the hang
> itself is only seen in one or two very specific workloads.
viafbdev.c utilizes memdup_user() to copy an array from userspace.
There is a new wrapper, specifically designed for copying arrays. Use
this one instead.
Suggested-by: Dave Airlie
Signed-off-by: Philipp Stanner
---
drivers/video/fbdev/via/viafbdev.c | 2 +-
1 file changed, 1 insertion(+), 1
On Thu, Nov 2, 2023 at 3:00 PM Hamza Mahfooz wrote:
>
> On 11/1/23 17:36, Alex Deucher wrote:
> > On Wed, Nov 1, 2023 at 5:01 PM Hamza Mahfooz wrote:
> >>
> >> Without this fix the 5120x1440@240 timing of these monitors
> >> leads to screen flickering.
> >>
> >> Cc: sta...@vger.kernel.org # 6.1+
On 11/1/23 17:36, Alex Deucher wrote:
On Wed, Nov 1, 2023 at 5:01 PM Hamza Mahfooz wrote:
Without this fix the 5120x1440@240 timing of these monitors
leads to screen flickering.
Cc: sta...@vger.kernel.org # 6.1+
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1442
Co-developed-by:
Names of the MIPI sequence steps are sequential and defined, no
need to check for the gaps. However in seq_name the MIPI_SEQ_END
is missing. Add it there, and drop unneeded NULL check in
sequence_name().
Reviewed-by: Andi Shyti
Signed-off-by: Andy Shevchenko
---
This panel is found on laptops e.g., variants of the Thinkpad X13s.
Configuration was collected from the panel's EDID.
Signed-off-by: Clayton Craft
---
V2: renamed to "*_mode" since there is only 1 mode listed
drivers/gpu/drm/panel/panel-edp.c | 27 +++
1 file changed,
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
On Mon, 30 Oct 2023 13:58:31 -0700 Jessica Zhang
wrote:
>
>
> On 10/27/2023 7:19 PM, Clayton Craft wrote:
> > This panel is found on laptops e.g., variants of the Thinkpad X13s.
> > Configuration was collected from the panel's EDID.
>
> Hi Clayton,
>
> Thanks for the patch -- it looks good
ml2/Makefile
@@ -60,8 +60,12 @@ endif
endif
ifneq ($(CONFIG_FRAME_WARN),0)
+ifeq ($(CONFIG_CC_IS_CLANG)$(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),yy)
+frame_warn_flag := -Wframe-larger-than=3072
+else
frame_warn_flag := -Wframe-larger-than=2048
endif
+endif
CFLAGS_$(AMDDALPATH)/dc/dml2/disp
On Thu, 2023-11-02 at 00:31 +0100, Danilo Krummrich wrote:
> Implement reference counting for struct drm_gpuvm.
>
> Signed-off-by: Danilo Krummrich
> ---
> drivers/gpu/drm/drm_gpuvm.c | 44 +++-
> --
> drivers/gpu/drm/nouveau/nouveau_uvmm.c | 20 +---
>
fault for
> not sending this sooner.
Applied. Thanks! Will send out a PR this week.
Alex
>
> Changes in v2:
> - Adjust workaround to check for either CONFIG_KASAN=y or
> CONFIG_KCSAN=y, as the same problem has been reported with older
> versions of GCC (Hamza, Alex)
>
On Thu, 2023-11-02 at 18:32 +0100, Danilo Krummrich wrote:
> Hi Thomas,
>
> thanks for your timely response on that!
>
> On 11/2/23 18:09, Thomas Hellström wrote:
> > On Thu, 2023-11-02 at 00:31 +0100, Danilo Krummrich wrote:
> > > Implement reference counting for struct drm_gpuvm.
> > >
> > >
Hi Thomas,
thanks for your timely response on that!
On 11/2/23 18:09, Thomas Hellström wrote:
On Thu, 2023-11-02 at 00:31 +0100, Danilo Krummrich wrote:
Implement reference counting for struct drm_gpuvm.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_gpuvm.c | 44
On Thu, Nov 02, 2023 at 05:12:14PM +0200, Andy Shevchenko wrote:
> From: Jani Nikula
>
> Purely a guess. Drop the nop function.
>
> Cc: Andy Shevchenko
> Cc: Hans de Goede
> Signed-off-by: Jani Nikula
> Signed-off-by: Andy Shevchenko
> ---
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c |
On Thu, 2 Nov 2023 at 16:52, Alex Deucher wrote:
>
> On Thu, Nov 2, 2023 at 5:32 AM Sudip Mukherjee (Codethink)
> wrote:
> >
> > Hi All,
> >
> > The latest mainline kernel branch fails to build x86_64 allmodconfig
> > with the error:
> >
> >
On Thu, Nov 02, 2023 at 07:10:09PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 02, 2023 at 05:12:14PM +0200, Andy Shevchenko wrote:
...
> > if (native)
> > icl_native_gpio_set_value(dev_priv, gpio_number, value);
> > else if (DISPLAY_VER(dev_priv) >= 11)
> > -
by this. If not, no worries, as it was my fault for
not sending this sooner.
Changes in v2:
- Adjust workaround to check for either CONFIG_KASAN=y or
CONFIG_KCSAN=y, as the same problem has been reported with older
versions of GCC (Hamza, Alex)
- Link to v1:
https://lore.kernel.org/r/20231102-amdgpu-dml2-increase
Hello,
On Thu, Nov 02, 2023 at 05:56:48PM +0100, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
On Thu, 2023-11-02 at 00:31 +0100, Danilo Krummrich wrote:
> Add an abstraction layer between the drm_gpuva mappings of a
> particular
> drm_gem_object and this GEM object itself. The abstraction represents
> a
> combination of a drm_gem_object and drm_gpuvm. The drm_gem_object
> holds
> a list of
Hi,
On Wed, Nov 1, 2023 at 2:26 PM Hsin-Yi Wang wrote:
>
> Add a few generic edp panels used by mt8186 chromebooks.
> Besides, modify the following panel:
> - AUO 0x235c B116XTN02 renamed to B116XTN02.3.
> - AUO 0x405c B116XAK01 adjust the timing to delay_200_500_e50. According
> to the
change-id:
20231102-amdgpu-dml2-increase-frame-size-warning-for-clang-c93bd2d6a871
Best regards,
--
Hamza
--
Hamza
amd/display/dc/dml2/Makefile
> @@ -60,8 +60,12 @@ endif
> endif
>
> ifneq ($(CONFIG_FRAME_WARN),0)
> +ifeq ($(CONFIG_CC_IS_CLANG)$(filter y,$(CONFIG_KASAN)$(CONFIG_KCSAN)),yy)
> +frame_warn_flag := -Wframe-larger-than=3072
> +else
> frame_warn_flag := -Wframe-larger-than=2048
> endif
> +endif
>
> CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags)
> $(frame_warn_flag)
> CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_util.o := $(dml2_ccflags)
>
> > > endif
> > > CFLAGS_$(AMDDALPATH)/dc/dml2/display_mode_core.o := $(dml2_ccflags)
> > > $(frame_warn_flag)
> > >
> > > ---
> > > base-commit: 21e80f3841c01aeaf32d7aee7bbc87b3db1aa0c6
> > > change-id:
> > > 20231102-amdgpu-dml2-increase-frame-size-warning-for-clang-c93bd2d6a871
> > >
> > > Best regards,
> > --
> > Hamza
> >
Hello,
this series converts all platform drivers below drivers/gpu/drm to use
.remove_new(). It starts with a fix for a problem that potentially might
crash the kernel that I stumbled over while implementing the conversion.
Some of the conversion patches following this fix were already send in
Replace the generic error message issued by the driver core when the remove
callback returns non-zero ("remove callback returned a non-zero value. This
will be ignored.") by a message that tells the actual problem.
Also simplify a bit by checking the return value of wait_event_timeout a
bit
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
On Thu, Nov 2, 2023 at 5:32 AM Sudip Mukherjee (Codethink)
wrote:
>
> Hi All,
>
> The latest mainline kernel branch fails to build x86_64 allmodconfig
> with the error:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c: In
> function 'dml_prefetch_check':
>
: 21e80f3841c01aeaf32d7aee7bbc87b3db1aa0c6
change-id:
20231102-amdgpu-dml2-increase-frame-size-warning-for-clang-c93bd2d6a871
Best regards,
--
Hamza
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
Hi,
On Wed, Nov 1, 2023 at 2:26 PM Hsin-Yi Wang wrote:
>
> Generic edp gets mode from edid. However, some panels report incorrect
> mode in this way, resulting in glitches on panel. Introduce a new quirk
> additional_mode to the generic edid to pick a correct hardcoded mode.
>
> Signed-off-by:
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
With tpd12s015_remove() marked with __exit this function is discarded
when the driver is compiled as a built-in. The result is that when the
driver unbinds there is no cleanup done which results in resource
leakage or worse.
Fixes: cff5e6f7e83f ("drm/bridge: Add driver for the TI TPD12S015 HDMI
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
On Thu, Nov 02, 2023 at 04:47:41PM +0100, Hans de Goede wrote:
> On 11/2/23 16:12, Andy Shevchenko wrote:
...
> > + soc_exec_opaque_gpio(connector, gpio_index,
> > "INT33FF:03", "Panel SE",
> > +gpio_index -
> > CHV_GPIO_IDX_START_SW,
From: Jani Nikula
Purely a guess. Drop the nop function.
Cc: Andy Shevchenko
Cc: Hans de Goede
Signed-off-by: Jani Nikula
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git
:= $(dml2_ccflags)
$(frame_warn_flag)
---
base-commit: 21e80f3841c01aeaf32d7aee7bbc87b3db1aa0c6
change-id:
20231102-amdgpu-dml2-increase-frame-size-warning-for-clang-c93bd2d6a871
Best regards,
--
Nathan Chancellor
Hi,
On 11/2/23 16:12, Andy Shevchenko wrote:
> It's a dirty hack in the driver that pokes GPIO registers behind
> the driver's back. Moreoever it might be problematic as simultaneous
> I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl:
> cherryview: prevent concurrent access to GPIO
On Thu, 02 Nov 2023, Andy Shevchenko wrote:
> DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
> talking to GPIO IP behind the actual driver's back. A second attempt
> to fix that is here.
>
> If I understood correctly, my approach should work in the similar way as
> the
Add my self as maintainer for RZ DU drivers.
While at it, update the entries for common parts, rcar-du and shmobile.
Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
---
v11->v12:
* No change.
v10->v11:
* No change.
v9->v10:
* No change.
v8->v9:
* Added Rb tag from Laurent.
* Updated
Drop unused vlv_iosf_sb_read() and vlv_iosf_sb_write().
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/vlv_sideband.c | 17 -
drivers/gpu/drm/i915/vlv_sideband.h | 3 ---
2 files changed, 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/vlv_sideband.c
Document DU found in RZ/V2L SoC. The DU block is identical to RZ/G2L
SoC and therefore use RZ/G2L fallback to avoid any driver changes.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
v11->v12:
* No change.
v10->v11:
* No
Move existing condition to while(), so it will be clear on what
circumstances the loop is successfully finishing.
Reviewed-by: Andi Shyti
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git
On Thu, Nov 02, 2023 at 05:12:23PM +0200, Andy Shevchenko wrote:
> From: Hans de Goede
>
> Fix wrong initial value for GPIOs in bxt_exec_gpio().
Oh, and forgot to update the function name in this patch.
In any case I would wait for Hans to confirm it works (and probably he may give
a formal
From: Hans de Goede
Fix wrong initial value for GPIOs in bxt_exec_gpio().
Signed-off-by: Hans de Goede
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
From: Jani Nikula
The lowest level functions are about setting GPIO values, not about
executing any sequences anymore.
Cc: Andy Shevchenko
Cc: Hans de Goede
Signed-off-by: Jani Nikula
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++--
In the snippets like the following
if (...)
return / goto / break / continue ...;
else
...
the 'else' is redundant. Get rid of it.
Reviewed-by: Andi Shyti
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 58
On Thu, Nov 02, 2023 at 05:12:13PM +0200, Andy Shevchenko wrote:
> DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
> talking to GPIO IP behind the actual driver's back. A second attempt
> to fix that is here.
>
> If I understood correctly, my approach should work in the
It's a dirty hack in the driver that pokes GPIO registers behind
the driver's back. Moreoever it might be problematic as simultaneous
I/O may hang the system, see the commit 40ecab551232 ("pinctrl:
baytrail: Really serialize all register accesses") for the details.
Taking all this into
From: Hans de Goede
To properly deal with GPIOs used in MIPI panel sequences a temporary
GPIO lookup will be used. Since there can only be 1 GPIO lookup table
for the ":00:02.0" device this will not work if the GPIO lookup
table used by intel_dsi_vbt_gpio_init() is still registered.
After
From: Jani Nikula
Drop the unused parameter.
Cc: Andy Shevchenko
Cc: Hans de Goede
Signed-off-by: Jani Nikula
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
From: Jani Nikula
With the various sequence versions and pointer increments interleaved,
it's a bit hard to decipher what's going on. Add separate paths for
different sequence versions.
Cc: Andy Shevchenko
Cc: Hans de Goede
Signed-off-by: Jani Nikula
Signed-off-by: Andy Shevchenko
---
From: Jani Nikula
Follow the contemporary conventions.
Cc: Andy Shevchenko
Cc: Hans de Goede
Signed-off-by: Jani Nikula
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
The RZ/G2L LCD controller is composed of Frame Compression Processor
(FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
The DU module supports the following hardware features
− Display Parallel Interface (DPI) and MIPI LINK Video Interface
− Display timing master
− Generates video
On Wed, Nov 01, 2023 at 11:17:47AM +0200, Tomi Valkeinen wrote:
> tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not,
> returns immediately as there's no reason to do any register changes.
>
> However, the code checks for 'crtc->state->enable', which does not
> reflect the actual
DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
talking to GPIO IP behind the actual driver's back. A second attempt
to fix that is here.
If I understood correctly, my approach should work in the similar way as
the current IOSF GPIO.
Hans, I believe you have some devices
Currently soc_gpio_set_value() supports only a single indexing for GPIO pin.
For CHV case, for example, we will need to distinguish community based index
from the one that VBT is using. Introduce an additional parameter to
soc_gpio_set_value() and its callers.
Signed-off-by: Andy Shevchenko
---
It's a dirty hack in the driver that pokes GPIO registers behind
the driver's back. Moreoever it might be problematic as simultaneous
I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl:
cherryview: prevent concurrent access to GPIO controllers") for
the details. Taking all this into
Extract a common soc_gpio_set_value() helper that may be used by a few SoCs.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 46 +++-
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI/DSI interfaces and supports a maximum resolution of 1080p
along with 2 RPFs to support the blending of two picture layers and
raster operations (ROPs).
The DU
This path series aims to add support for RZ/G2L DU DRM driver.
RZ/G2L LCD controller composed of Frame compression Processor(FCPVD), Video
signal processor (VSPD) and Display unit(DU). The output of LCDC is
connected to Display parallel interface and MIPI link video interface.
The output from
Hello,
There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The
penguins are not displayed at boot time)
Error message: [ 0.889302] virtio-pci :00:02.0: [drm] *ERROR*
fbdev: Failed to setup generic emulation (ret=-2)
The kernel 6.6 final doesn't have this issue.
Please
On Wed, Nov 01, 2023 at 11:17:44AM +0200, Tomi Valkeinen wrote:
> The probe function calls dispc_softreset() before runtime PM is enabled
> and without enabling any of the DSS clocks. This happens to work by
> luck, and we need to make sure the DSS HW is active and the fclk is
> enabled.
Not sure
Currently, the GPU is being internally powered off for runtime suspend
and turned back on for runtime resume through commands sent to it, but
note that the GPU doesn't need to be clocked during the poweroff state,
hence it is possible to save some power on selected platforms.
Add suspend and
All of the MediaTek SoCs supported by Panfrost can switch the clocks
off and on during system sleep to save some power without any user
experience penalty.
Measurements taken on multiple MediaTek SoCs show that adding this
will not prolong the time that is required to resume the system in
any
Hi,
On Wed, Nov 1, 2023 at 11:31 PM Dmitry Baryshkov
wrote:
>
> On Wed, 1 Nov 2023 at 23:26, Hsin-Yi Wang wrote:
> >
> > If a non generic edp-panel is under aux-bus, the mode read from edid would
> > still be selected as preferred and results in multiple preferred modes,
> > which is ambiguous.
Even though soft reset should ideally never fail, during development of
some power management features I managed to get some bits wrong: this
resulted in GPU soft reset failures, where the GPU was never able to
recover, not even after suspend/resume cycles, meaning that the only
way to get
Hi,
On 11/2/23 15:19, Andy Shevchenko wrote:
> On Wed, Nov 01, 2023 at 11:20:23AM +0100, Hans de Goede wrote:
>> On 11/1/23 10:32, Andy Shevchenko wrote:
>>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
On 10/31/23 17:07, Hans de Goede wrote:
> On 10/24/23 18:11, Andy
In many cases, soft reset takes more than 1 microsecond, but definitely
less than 10; moreover in the poweron flow, tilers, shaders and l2 will
become ready (each) in less than 10 microseconds as well.
Even in the cases (at least on my platforms, rarely) in which those take
more than 10
All of the MediaTek SoCs supported by Panfrost can completely cut power
to the GPU during full system sleep without any user-noticeable delay
in the resume operation, as shown by measurements taken on multiple
MediaTek SoCs.
As an example, for MT8195 - a "before" with only runtime PM operations
Some platforms/SoCs can power off the GPU entirely by completely cutting
off power, greatly enhancing battery time during system suspend: add a
new pm_feature GPU_PM_VREG_OFF to allow turning off the GPU regulators
during full suspend only on selected platforms.
Signed-off-by: AngeloGioacchino
Changes in v2:
- Added hard reset GPU recovery
- Tightened polling time for soft reset and power on
- New execution time measurements after poweroff fix (see [1])
[1]:
https://lore.kernel.org/all/20231102141507.73481-1-angelogioacchino.delre...@collabora.com/
At least MediaTek platforms are
For detection of the new explicit sync functionality without having to try
the ioctl.
Signed-off-by: Tatsuyuki Ishi
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
1 - 100 of 179 matches
Mail list logo
