From: Xiaoke Wang
kstrdup() is a memory allocation function which can return NULL when
some internaly memory errors happen. It is better to check the return
value of it to prevent further wrong memory access.
Signed-off-by: Xiaoke Wang
---
drivers/dma-buf/selftest.c | 3 +++
1 file changed, 3
Don't populate the read-only arrays on the stack but instead make
them static const. Also makes the object code a little smaller.
Reformat the statements to clear up checkpatch warning.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 16
1 file chan
From: Xiaoke Wang
kstrdup() is a memory allocation function which can return NULL when
some internaly memory errors happen. It is better to check the return
value of it to prevent further wrong memory access.
Signed-off-by: Xiaoke Wang
---
drivers/gpu/drm/i915/selftests/i915_selftest.c | 3 +++
On 2/22/22 18:24, Christoph Hellwig wrote:
On Fri, Feb 18, 2022 at 01:39:46PM +0200, Mikko Perttunen wrote:
+
+/*
+ * Due to an issue with T194 NVENC, only 38 bits can be used.
+ * Anyway, 256GiB of IOVA ought to be enough for anyone.
+ */
+static dma_addr_t context_device_dma_mask = DMA_BIT_MAS
when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Michael-Cheng/Use-drm_clflush-instead-of-clflush/20220223-140110
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
con
On 19/02/2022 22:39, Rob Clark wrote:
From: Rob Clark
Someone on IRC once asked an innocent enough sounding question: Why
with xf86-video-modesetting is es2gears limited at 120fps.
So I broke out the perfetto tracing mesa MR and took a look. It turns
out the problem was drm_atomic_helper_dir
On Tue, 25 Jan 2022 12:37:38 +
Liviu Dudau wrote:
Hi,
> On Mon, Jan 24, 2022 at 04:24:37PM +, carsten.haitz...@foss.arm.com wrote:
> > From: Carsten Haitzler
> >
> > Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
> >
> > Fixes: 09717af7d13d ("drm: Remove CON
Hi,
This is a follow-up of the discussion here:
https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
and here:
https://lore.kernel.org/all/20210914093515.260031-1-max...@cerno.tech/
While the initial proposal implemented a new API to temporarily raise and lower
clock rates
Let's test various parts of the rate-related clock API with the kunit
testing framework.
Cc: kunit-...@googlegroups.com
Suggested-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/.kunitconfig | 1 +
drivers/clk/Kconfig | 7 +
drivers/clk/Makefile | 1 +
drivers/clk/c
Any registered clk_core structure can have a NULL pointer in its dev
field. While never actually documented, this is evidenced by the wide
usage of clk_register and clk_hw_register with a NULL device pointer,
and the fact that the core of_clk_hw_register() function also passes a
NULL device pointer
If we were to have two users of the same clock, doing something like:
clk_set_rate_range(user1, 1000, 2000);
clk_set_rate_range(user2, 3000, 4000);
The second call would fail with -EINVAL, preventing from getting in a
situation where we end up with impossible limits.
However, this is never expli
The code in clk_set_rate_range() will, if the current rate is outside of
the new range, will force it to the minimum or maximum.
Since it's running under the condition that the rate is either lower
than the minimum, or higher than the maximum, this is equivalent to
using clamp, while being less re
The current core while setting the min and max rate properly in the
clk_request structure will not make sure that the requested rate is
within these boundaries, leaving it to each and every driver to make
sure it is.
It's not clear if this was on purpose or not, but this introduces some
inconsiste
In order to reset the range on a clock, we need to call
clk_set_rate_range with a minimum of 0 and a maximum of ULONG_MAX. Since
it's fairly inconvenient, let's introduce a clk_drop_range() function
that will do just this.
Suggested-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/
The core clock and M2MC clocks are shared between some devices (Unicam
controllers and the HVS, and the HDMI controllers, respectively) that
will have various, varying, requirements depending on their current work
load.
Since those loads can require a fairly high clock rate in extreme
conditions (
The HVS core clock isn't really obvious, so let's add a bunch more
comments and some logging for easier debugging.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/v
When we change a clock minimum or maximum using clk_set_rate_range(),
clk_set_min_rate() or clk_set_max_rate(), the current code will only
trigger a new rate change if the rate is outside of the new boundaries.
However, a clock driver might want to always keep the clock rate to
one of its boundary
Now that the clock driver makes sure we never end up with a rate of 0,
the HDMI driver doesn't need to care anymore.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/
The M2MC clock provides the state machine clock for both HDMI
controllers.
However, if no HDMI monitor is plugged in at boot, its clock rate will
be left at 0 by the firmware and will make any register access end up in
a CPU stall, even though the clock was enabled.
We had some code in the HDMI c
We only export a bunch of firmware clocks, and some of them require
special treatment.
This has been do so far using some tests on the clock id in various
places, but this is fairly hard to extend and doesn't scale very well.
Since we'll need some more cases in the next patches, let's switch to a
On 23.02.2022 10:02, Das, Nirmoy wrote:
>
> On 22/02/2022 15:51, Balasubramani Vivekanandan wrote:
> > drm_memcpy_from_wc() performs fast copy from WC memory type using
> > non-temporal instructions. Now there are two similar implementations of
> > this function. One exists in drm_cache.c as drm_m
Hi,
On 2/22/22 20:14, Thomas Zimmermann wrote:
> Hi
>
> Am 21.02.22 um 23:00 schrieb Hans de Goede:
>> Some devices use e.g. a portrait panel in a standard laptop casing made
>> for landscape panels. efifb calls drm_get_panel_orientation_quirk() and
>> sets fb_info.fbcon_rotate_hint to make fbcon
As per the specification of DPU_CTL_ACTIVE_CFG the configuration of
active blocks should be proactively specified, and the pingpong block is
no different.
The downstream display driver [1] confirms this by also calling
bind_pingpong_blk on CTL_ACTIVE_CFG. Note that this else-if is always
entered,
Make sure that pp3300 regulator and enable gpio are cleaned before
leave in error cases.
Fixes: 18c58153b8c62 ("drm/panel: boe-tv101wum-nl6: Support enabling a 3.3V
rail")
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 7 +--
1 file changed, 5 insertio
On Wed, 23 Feb 2022 at 14:40, Marijn Suijten
wrote:
>
> As per the specification of DPU_CTL_ACTIVE_CFG the configuration of
> active blocks should be proactively specified, and the pingpong block is
> no different.
>
> The downstream display driver [1] confirms this by also calling
> bind_pingpong
On 23/02/2022 02:22, John Harrison wrote:
On 2/22/2022 01:53, Tvrtko Ursulin wrote:
On 18/02/2022 21:33, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not pre-emptible on current hardware.
Thus the pre-emption timeout was disabled as a workaround to
Don't populate the read-only arrays on the stack but instead make
them static const and signed 8 bit ints. Also makes the object code a
little smaller. Reformat the statements to clear up checkpatch warning.
Signed-off-by: Colin Ian King
---
V2: Make arrays signed 8 bit integers as requested by
On 23/02/2022 02:11, John Harrison wrote:
On 2/22/2022 01:52, Tvrtko Ursulin wrote:
On 18/02/2022 21:33, john.c.harri...@intel.com wrote:
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point o
when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Michael-Cheng/Use-drm_clflush-instead-of-clflush/20220223-140110
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
co
21
(https://download.01.org/0day-ci/archive/20220223/202202231909.8x2nm3si-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
d271fc04d5b97b12e6b797c6067d3c96a8d7470e)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/m
Hi Dave,
After few missing, here's the final pull req for -next in v5.18
drm-misc-next-2022-02-23:
drm-misc-next for v5.18:
UAPI Changes:
Cross-subsystem Changes:
- Split out panel-lvds and lvds dt bindings .
- Put yes/no on/off disabled/enabled strings in linux/string_helpers.h
and use it in
On Thu, 3 Feb 2022 12:54:16 +0100, Maxime Ripard wrote:
> In order to fill the drm_display_info structure each time an EDID is
> read, the code currently will call drm_add_display_info with the parsed
> EDID.
>
> drm_add_display_info will then call drm_reset_display_info to reset all
> the fields
Hi,
On Tue, Feb 22, 2022 at 09:47:23AM +0100, Max Krummenacher wrote:
> Use the new property bus-format to set the enum bus_format and bpc.
> Completes: commit 4a1d0dbc8332 ("drm/panel: simple: add panel-dpi support")
>
> Signed-off-by: Max Krummenacher
>
> ---
>
> drivers/gpu/drm/panel/panel
On 2/23/22 14:41, Maxime Ripard wrote:
Hi,
On Tue, Feb 22, 2022 at 09:47:23AM +0100, Max Krummenacher wrote:
Use the new property bus-format to set the enum bus_format and bpc.
Completes: commit 4a1d0dbc8332 ("drm/panel: simple: add panel-dpi support")
Signed-off-by: Max Krummenacher
---
On Wed, Feb 23, 2022 at 02:45:30PM +0100, Marek Vasut wrote:
> On 2/23/22 14:41, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, Feb 22, 2022 at 09:47:23AM +0100, Max Krummenacher wrote:
> > > Use the new property bus-format to set the enum bus_format and bpc.
> > > Completes: commit 4a1d0dbc8332 ("d
Second version of the patch. I didn't fix the copyright (which ame up
in the previous version), as I feel the original author should send a
patch for that.
I've made the suballocator into its own module, and did a cleanup pass on it.
The suballocator is generic enough to be useful for any resource
Suballocating a buffer object is something that is not driver
generic, and is useful for other drivers as well.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/Kconfig| 4 +
drivers/gpu/drm/Makefile | 3 +
drivers/gpu/drm/drm_suballoc.c | 426 ++
Now that the suballocation helper is generic, we can use it in amdgpu.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/Kconfig| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 29 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 5 +-
drivers/gpu/drm/amd/amdgpu/amd
Use the generic suballocation helper lifted from amdgpu.
Note that the generic suballocator only allows a single alignment,
so we may waste a few more bytes for radeon_semaphore, shouldn't
be a big deal, could be re-added if needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/Kconfig
On 23/02/2022 12:08, Balasubramani Vivekanandan wrote:
On 23.02.2022 10:02, Das, Nirmoy wrote:
On 22/02/2022 15:51, Balasubramani Vivekanandan wrote:
drm_memcpy_from_wc() performs fast copy from WC memory type using
non-temporal instructions. Now there are two similar implementations of
this
On 22/02/2022 15:51, Balasubramani Vivekanandan wrote:
drm_memcpy_from_wc() performs fast copy from WC memory type using
non-temporal instructions. Now there are two similar implementations of
this function. One exists in drm_cache.c as drm_memcpy_from_wc() and
another implementation in i915/i9
Converts the variable vmw_pt_sys_placement to static to
fix the following Sparse warning:
warning: symbol 'vmw_pt_sys_placement' was not declared. Should it be static?
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
Remove ti,hwmods from required properties, since the
target-module approach is actually used.
Signed-off-by: Angelo Dureghello
---
Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,dra
On 23/02/2022 02:45, John Harrison wrote:
On 2/22/2022 03:19, Tvrtko Ursulin wrote:
On 18/02/2022 21:33, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherantly not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption tim
On 2022-02-21 06:31, Melissa Wen wrote:
Move parts of dcn20 code that uses FPU to dml folder. It aims to isolate
FPU operations as described by series:
drm/amd/display: Introduce FPU directory inside DC
https://patchwork.freedesktop.org/series/93042/
This patch moves the following functions
On 23/02/2022 04:35, Kasireddy, Vivek wrote:
Hi Tvrtko,
On 18/02/2022 03:47, Kasireddy, Vivek wrote:
Hi Tvrtko,
On 17/02/2022 07:50, Vivek Kasireddy wrote:
While looking for next holes suitable for an allocation, although,
it is highly unlikely, make sure that the DECLARE_NEXT_HOLE_ADDR
On 2/23/22 14:47, Maxime Ripard wrote:
On Wed, Feb 23, 2022 at 02:45:30PM +0100, Marek Vasut wrote:
On 2/23/22 14:41, Maxime Ripard wrote:
Hi,
On Tue, Feb 22, 2022 at 09:47:23AM +0100, Max Krummenacher wrote:
Use the new property bus-format to set the enum bus_format and bpc.
Completes: commi
On Wed, Feb 23, 2022 at 2:42 AM Christian König
wrote:
>
> Well that's bad. This should not be pushed to amd-staging-drm-next at all.
>
> This patch is touching multiple drivers and therefore needs to go
> upstream through drm-misc-next.
>
> Alex can you drop that one before you send out a pull re
On Wed, Feb 23, 2022 at 03:09:08PM +0100, Marek Vasut wrote:
> On 2/23/22 14:47, Maxime Ripard wrote:
> > On Wed, Feb 23, 2022 at 02:45:30PM +0100, Marek Vasut wrote:
> > > On 2/23/22 14:41, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > On Tue, Feb 22, 2022 at 09:47:23AM +0100, Max Krummenacher
On 2/23/22 15:37, Maxime Ripard wrote:
On Wed, Feb 23, 2022 at 03:09:08PM +0100, Marek Vasut wrote:
On 2/23/22 14:47, Maxime Ripard wrote:
On Wed, Feb 23, 2022 at 02:45:30PM +0100, Marek Vasut wrote:
On 2/23/22 14:41, Maxime Ripard wrote:
Hi,
On Tue, Feb 22, 2022 at 09:47:23AM +0100, Max Kru
On Tue, Feb 22, 2022 at 10:46:35PM +0800, Sui Jingfeng wrote:
>
> On 2022/2/22 16:27, Maxime Ripard wrote:
> > > + if (!of_device_is_available(output)) {
> > > + of_node_put(output);
> > > + drm_info(ddev, "connector%d is not available\n", index);
> > > + return NULL;
> > >
On Wed, Feb 23, 2022 at 11:25 AM Hans de Goede wrote:
>
> Hi,
>
> On 2/22/22 20:14, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 21.02.22 um 23:00 schrieb Hans de Goede:
> >> Some devices use e.g. a portrait panel in a standard laptop casing made
> >> for landscape panels. efifb calls drm_get_panel_
On Fri, Feb 18, 2022 at 11:29:34AM +0200, Mikko Perttunen wrote:
> On 2/17/22 21:19, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The Video Image Composer (VIC) 4.0 can be found on NVIDIA Tegra210 SoCs.
> > It uses a different class (B0B6) that is slightly incompatible with the
> > clas
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_bw.c
between commit:
ec663bca9128f ("drm/i915: Fix bw atomic check when switching between SAGV vs.
no SAGV")
from the drm-intel-fixes tree and commit:
6d8ebef53c2cc ("drm/i915:
On Wed 23-02-22 09:35:34, Byungchul Park wrote:
> On Mon, Feb 21, 2022 at 08:02:04PM +0100, Jan Kara wrote:
> > On Thu 17-02-22 20:10:04, Byungchul Park wrote:
> > > [9.008161] ===
> > > [9.008163] DEPT: Circular dependency has been detected.
On Wed, Feb 23, 2022 at 03:46:01PM +0100, Thierry Reding wrote:
> On Fri, Feb 18, 2022 at 11:29:34AM +0200, Mikko Perttunen wrote:
> > On 2/17/22 21:19, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > The Video Image Composer (VIC) 4.0 can be found on NVIDIA Tegra210 SoCs.
> > > It u
On Tue, Feb 22, 2022 at 10:41:05AM +0200, Mikko Perttunen wrote:
> On 2/21/22 22:29, Dmitry Osipenko wrote:
> > 18.02.2022 12:31, Mikko Perttunen пишет:
> > > On 2/17/22 21:16, Thierry Reding wrote:
> > > > ...
> > >
> > > Reviewed-by: Mikko Perttunen
> > >
> > > Left one cosmetic comment in the
Am 23.02.22 um 14:51 schrieb Maarten Lankhorst:
Second version of the patch. I didn't fix the copyright (which ame up
in the previous version), as I feel the original author should send a
patch for that.
I've made the suballocator into its own module, and did a cleanup pass on it.
The suballocat
On 2022/2/23 22:39, Maxime Ripard wrote:
On Tue, Feb 22, 2022 at 10:46:35PM +0800, Sui Jingfeng wrote:
On 2022/2/22 16:27, Maxime Ripard wrote:
+ if (!of_device_is_available(output)) {
+ of_node_put(output);
+ drm_info(ddev, "connector%d is not available\n",
The goal here is to set the element bus_format in the struct
panel_desc. This is an enum with the possible values defined in
include/uapi/linux/media-bus-format.h.
The enum values are not constructed in a way that you could calculate
the value from color channel width/shift/mapping/whatever. You r
On 2022/2/23 21:56, 隋景峰 wrote:
Something like this:
dt-bindings: display: Add Loongson display controller
Hi,
We are not a platform device driver, there is no
of_device_id defined in my driver. In other word,
my driver will not bind against devices whose compatible
is "loongson,ls7a1000-d
On 23/02/2022 14:56, 隋景峰 wrote:
>
>
>
> > -Original Messages-
> > From: "Rob Herring"
> > Sent Time: 2022-02-23 07:02:34 (Wednesday)
> > To: "Sui Jingfeng" <15330273...@189.cn>
> > Cc: "Maxime Ripard" , "Thomas Zimmermann"
> , "Roland Scheidegger" , "Zack
> Rusin" , "Christian Gmeiner
On Wed, Feb 23, 2022 at 11:14:12PM +0800, Sui Jingfeng wrote:
>
> On 2022/2/23 22:39, Maxime Ripard wrote:
> > On Tue, Feb 22, 2022 at 10:46:35PM +0800, Sui Jingfeng wrote:
> > > On 2022/2/22 16:27, Maxime Ripard wrote:
> > > > > + if (!of_device_is_available(output)) {
> > > > > +
Hi,
On Tue, Feb 22, 2022 at 9:08 PM Laurent Pinchart
wrote:
>
> On Tue, Feb 22, 2022 at 11:44:54PM +0100, Linus Walleij wrote:
> > On Tue, Feb 22, 2022 at 11:19 PM Douglas Anderson
> > wrote:
> > >
> > > The PM Runtime docs say:
> > > Drivers in ->remove() callback should undo the runtime PM
On 23/02/2022 16:35, Sui Jingfeng wrote:
>
> On 2022/2/23 21:56, 隋景峰 wrote:
>> Something like this:
>>
>> dt-bindings: display: Add Loongson display controller
>
> Hi,
Thanks for resending in a proper format. I already replied to your
original post, so let me paste it here as well.
>
> We a
On 2022/2/23 22:39, Maxime Ripard wrote:
On Tue, Feb 22, 2022 at 10:46:35PM +0800, Sui Jingfeng wrote:
On 2022/2/22 16:27, Maxime Ripard wrote:
+ if (!of_device_is_available(output)) {
+ of_node_put(output);
+ drm_info(ddev, "connector%d is not available\n",
On Tue, Feb 22, 2022 at 7:11 PM Dmitry Baryshkov
wrote:
>
> On 19/02/2022 21:33, Rob Clark wrote:
> > From: Rob Clark
> >
> > Avoid going down devfreq paths on devices where devfreq is not
> > initialized.
> >
> > Reported-by: Linux Kernel Functional Testing
> > Reported-by: Anders Roxell
> > S
On Thu, 17 Feb 2022 09:29:54 +0100, Sascha Hauer wrote:
> Current port description doesn't cover all possible cases. It currently
> expects one single port with two endpoints.
>
> When the HDMI connector is described in the device tree there can be two
> ports, first one going to the VOP and the s
Hi Doug,
On Wed, Feb 23, 2022 at 07:43:27AM -0800, Doug Anderson wrote:
> On Tue, Feb 22, 2022 at 9:08 PM Laurent Pinchart wrote:
> > On Tue, Feb 22, 2022 at 11:44:54PM +0100, Linus Walleij wrote:
> > > On Tue, Feb 22, 2022 at 11:19 PM Douglas Anderson wrote:
> > > >
> > > > The PM Runtime docs sa
Hi,
On Tue, Feb 22, 2022 at 1:31 AM Geert Uytterhoeven wrote:
>
> On Tue, Feb 8, 2022 at 10:39 AM Geert Uytterhoeven
> wrote:
> > On Mon, Feb 7, 2022 at 12:31 PM Thomas Zimmermann
> > wrote:
> > > As reported in [1], DRM_PANEL_EDP depends on DRM_DP_HELPER. Select
> > > the option to fix the b
Hi Laurent, Nikita,
Quoting Laurent Pinchart (2021-12-29 23:44:29)
> Hi Nikita,
>
> Thank you for the patch.
>
> On Sat, Dec 25, 2021 at 09:31:51AM +0300, Nikita Yushchenko wrote:
> > Hotplug events reported by bridge drivers over drm_bridge_hpd_notify()
> > get ignored unless somebody calls drm
On Wed, Feb 23, 2022 at 2:00 AM Dmitry Baryshkov
wrote:
>
> On 19/02/2022 22:39, Rob Clark wrote:
> > From: Rob Clark
> >
> > Someone on IRC once asked an innocent enough sounding question: Why
> > with xf86-video-modesetting is es2gears limited at 120fps.
> >
> > So I broke out the perfetto tra
Hi Dave, Daniel,
The following changes since commit e783362eb54cd99b2cac8b3a9aeac942e6f6ac07:
Linux 5.17-rc1 (2022-01-23 10:12:53 +0200)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/tegra.git tags/drm/tegra/for-5.17-rc6
for you to fetch changes up to 8913e1aea
Hello,
On Wed, Feb 23, 2022 at 04:17:22PM +, Kieran Bingham wrote:
> Quoting Laurent Pinchart (2021-12-29 23:44:29)
> > On Sat, Dec 25, 2021 at 09:31:51AM +0300, Nikita Yushchenko wrote:
> > > Hotplug events reported by bridge drivers over drm_bridge_hpd_notify()
> > > get ignored unless someb
Hello Michal,
On 2/18/22 17:04, Michal Suchanek wrote:
> Since switch to simplefb/simpledrm VESA graphic modes are no longer
> available with legacy BIOS.
>
Maybe you can mention that is the "vga=" kernel command line parameter
since that may be more evident to people reading the commit message ?
Hi,
On Wed, Feb 23, 2022 at 7:55 AM Laurent Pinchart
wrote:
>
> > How about a middle ground, though: we could add a devm function that
> > does all the magic. Somewhat recently devm_pm_runtime_enable() was
> > added. What if we add a variant for those that use autosuspend, like:
> >
> > devm_pm_r
On Wed, Feb 23, 2022 at 03:38:20PM +0100, Marek Vasut wrote:
> On 2/23/22 15:37, Maxime Ripard wrote:
> > On Wed, Feb 23, 2022 at 03:09:08PM +0100, Marek Vasut wrote:
> > > On 2/23/22 14:47, Maxime Ripard wrote:
> > > > On Wed, Feb 23, 2022 at 02:45:30PM +0100, Marek Vasut wrote:
> > > > > On 2/23/
On Wed, Feb 23, 2022 at 05:34:50PM +0100, Javier Martinez Canillas wrote:
> Hello Michal,
>
> On 2/18/22 17:04, Michal Suchanek wrote:
> > Since switch to simplefb/simpledrm VESA graphic modes are no longer
> > available with legacy BIOS.
>
> Maybe you can mention that is the "vga=" kernel comman
On 2/23/22 17:45, Michal Suchánek wrote:
[snip]
>>>
>>> To enable use of VESA modes with simplefb in legacy BIOS boot mode drop
>>
>> I think you meant "VESA modes with the sysfb driver" ? or something like
>> that since otherwise it seems that you meant to use it with the simplefb
>> (drivers/vi
On 2/23/22 17:39, Maxime Ripard wrote:
On Wed, Feb 23, 2022 at 03:38:20PM +0100, Marek Vasut wrote:
On 2/23/22 15:37, Maxime Ripard wrote:
On Wed, Feb 23, 2022 at 03:09:08PM +0100, Marek Vasut wrote:
On 2/23/22 14:47, Maxime Ripard wrote:
On Wed, Feb 23, 2022 at 02:45:30PM +0100, Marek Vasut
Quoting Laurent Pinchart (2022-02-23 16:25:28)
> Hello,
>
> On Wed, Feb 23, 2022 at 04:17:22PM +, Kieran Bingham wrote:
> > Quoting Laurent Pinchart (2021-12-29 23:44:29)
> > > On Sat, Dec 25, 2021 at 09:31:51AM +0300, Nikita Yushchenko wrote:
> > > > Hotplug events reported by bridge drivers
On 2/23/22 17:54, Javier Martinez Canillas wrote:
> On 2/23/22 17:45, Michal Suchánek wrote:
>
> [snip]
>
To enable use of VESA modes with simplefb in legacy BIOS boot mode drop
>>>
>>> I think you meant "VESA modes with the sysfb driver" ? or something like
>>> that since otherwise it
On Wed, Feb 23, 2022 at 05:54:54PM +0100, Javier Martinez Canillas wrote:
> On 2/23/22 17:45, Michal Suchánek wrote:
>
> [snip]
>
> >>>
> >>> To enable use of VESA modes with simplefb in legacy BIOS boot mode drop
> >>
> >> I think you meant "VESA modes with the sysfb driver" ? or something like
>
On 2/18/2022 6:22 PM, Dmitry Baryshkov wrote:
On Sat, 19 Feb 2022 at 03:55, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-02-18 14:32:53)
On 19/02/2022 00:31, Kuogee Hsieh wrote:
On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
There is little point in having both connector and root brid
Hi All,
I'm working to respin the remainder of these patches, now that I have
IRQ based HPD working on the SN65DSI86, and the (non-eDP) mode is used
for Renesas R-Car boards.
Quoting Doug Anderson (2021-06-24 00:51:12)
> Hi,
>
> On Wed, Jun 23, 2021 at 4:26 PM Laurent Pinchart
> wrote:
> >
> >
submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Michael-Cheng/Use-drm_clflush-instead-of-clflush/20220223-140110
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: arm64
On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
Currently DP driver will allocate panel bridge for eDP panels. This
supports only the following topology:
- eDP encoder ⇒ eDP panel (wrapped using panel-bridge)
Simplify this code to just check if there is any next bridge in the
chain (be it a pan
Hi Doug, Laurent,
Quoting Laurent Pinchart (2021-06-23 14:59:00)
> Hi Doug,
>
> On Wed, Mar 24, 2021 at 03:47:07PM -0700, Doug Anderson wrote:
> > On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote:
> > >
> > > Despite the SN65DSI86 being an eDP bridge, on some systems its output is
> > > rou
On 2/23/22 18:12, Michal Suchánek wrote:
> On Wed, Feb 23, 2022 at 05:54:54PM +0100, Javier Martinez Canillas wrote:
[snip]
>>
>> Yes, that's what I tried to say. But your commit message says "To enable
>> use of VESA modes with simplefb in legacy BIOS boot mode" and that isn't
>> accurate AFAIU
Hi,
On Wed, Feb 23, 2022 at 10:05 AM Kieran Bingham
wrote:
>
> > > > + /* For DisplayPort, disable scrambling mode. */
> > > > + if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort)
> > > > + regmap_update_bits(pdata->regmap,
> > > > SN_TRAINING_SETTING_REG,
> > >
On 23/02/2022 20:21, Kuogee Hsieh wrote:
On 2/18/2022 6:22 PM, Dmitry Baryshkov wrote:
On Sat, 19 Feb 2022 at 03:55, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-02-18 14:32:53)
On 19/02/2022 00:31, Kuogee Hsieh wrote:
On 2/11/2022 2:40 PM, Dmitry Baryshkov wrote:
There is little poi
On Wed, Feb 23, 2022 at 07:13:07PM +0100, Javier Martinez Canillas wrote:
> On 2/23/22 18:12, Michal Suchánek wrote:
> > On Wed, Feb 23, 2022 at 05:54:54PM +0100, Javier Martinez Canillas wrote:
>
> [snip]
>
> >>
> >> Yes, that's what I tried to say. But your commit message says "To enable
> >> u
Hi,
On Wed, Feb 23, 2022 at 9:43 AM Kieran Bingham
wrote:
>
> Hi All,
>
> I'm working to respin the remainder of these patches, now that I have
> IRQ based HPD working on the SN65DSI86, and the (non-eDP) mode is used
> for Renesas R-Car boards.
>
> Quoting Doug Anderson (2021-06-24 00:51:12)
> >
On 2/23/2022 10:22 AM, Dmitry Baryshkov wrote:
On 23/02/2022 20:21, Kuogee Hsieh wrote:
On 2/18/2022 6:22 PM, Dmitry Baryshkov wrote:
On Sat, 19 Feb 2022 at 03:55, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-02-18 14:32:53)
On 19/02/2022 00:31, Kuogee Hsieh wrote:
On 2/11/2022 2:4
On 2/23/22 19:23, Michal Suchánek wrote:
[snip]
>> My point about the subject line remains thought, I would use something like:
>>
>> firmware: sysfb: Enable boot time VESA graphic mode selection for simplefb
>
> I see where the confusion comes from.
>
Yeah. And just to clarify, the "simplefb"
On Wed, 23 Feb 2022 at 21:27, Kuogee Hsieh wrote:
>
>
> On 2/23/2022 10:22 AM, Dmitry Baryshkov wrote:
> > On 23/02/2022 20:21, Kuogee Hsieh wrote:
> >>
> >> On 2/18/2022 6:22 PM, Dmitry Baryshkov wrote:
> >>> On Sat, 19 Feb 2022 at 03:55, Stephen Boyd wrote:
> Quoting Dmitry Baryshkov (2022
On 2/23/2022 04:13, Tvrtko Ursulin wrote:
On 23/02/2022 02:11, John Harrison wrote:
On 2/22/2022 01:52, Tvrtko Ursulin wrote:
On 18/02/2022 21:33, john.c.harri...@intel.com wrote:
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internall
Hi
Am 23.02.22 um 17:11 schrieb Doug Anderson:
Hi,
On Tue, Feb 22, 2022 at 1:31 AM Geert Uytterhoeven wrote:
On Tue, Feb 8, 2022 at 10:39 AM Geert Uytterhoeven wrote:
On Mon, Feb 7, 2022 at 12:31 PM Thomas Zimmermann wrote:
As reported in [1], DRM_PANEL_EDP depends on DRM_DP_HELPER. Sele
From: Rob Clark
Someone on IRC once asked an innocent enough sounding question: Why
with xf86-video-modesetting is es2gears limited at 120fps.
So I broke out the perfetto tracing mesa MR and took a look. It turns
out the problem was drm_atomic_helper_dirtyfb(), which would end up
waiting for v
Hi Dave and Daniel,
here's drm-misc-fixes for this week.
Best regards
Thomas
drm-misc-fixes-2022-02-23:
* edid: Always set RGB444
* imx/dcss: Select GEM CMA helpers
* radeon: Fix some variables's type
* vc4: Fix codec cleanup; Fix PM reference counting
The following changes since commit 439c
1 - 100 of 140 matches
Mail list logo
