On Wed, Feb 23, 2022 at 3:47 PM Paul Menzel wrote:
>
> Dear Qiang,
>
>
> Am 22.02.22 um 03:46 schrieb Qiang Yu:
> > Workstation application ANSA/META v21.1.4 get this error dmesg when
> > running CI test suite provided by ANSA/META:
> > [drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update
On 18/02/2022 14:30, Vinod Polimera wrote:
- Some DPU versions support inline rot90. It is supported only for
limited amount of UBWC formats.
- There are two versions of inline rotators, v1 (present on sm8250 and
sm7250) and v2 (sc7280). These versions differ in the list of supported
formats and
Dear Qiang,
Am 22.02.22 um 03:46 schrieb Qiang Yu:
Workstation application ANSA/META v21.1.4 get this error dmesg when
running CI test suite provided by ANSA/META:
[drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA (-16)
This is caused by:
1. create a 256MB buffer in invisible
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 request? I'm going
to cherry-pick it over to drm-misc-next.
[AMD Official Use Only]
Hi Christian,
I noticed that and it has been fixed with the latest patch.
And I pushed it to amd-staging-drm-next already.
Best regards,
Jiawei
-Original Message-
From: Koenig, Christian
Sent: Wednesday, February 23, 2022 3:12 PM
To: kernel test robot ; Gu,
Hi Jiawei,
can you take a look at this? The kernel build robots screaming that this
breaks the V3D build. Probably just a typo or missing include.
I would rather like to push this sooner than later.
Thanks,
Christian.
Am 21.02.22 um 16:51 schrieb kernel test robot:
Hi Jiawei,
Thank you
Hey,
> The connector/encoder funcs you do have to pass to
> drm_writeback_connector_init() can't use any of the shared driver
> infrastructure that assume a certain inheritance.
>
> See also my reply to Laurent [1].
>
> > It well might be that we all misunderstand your design. Do you have a
> >
Use drm_clflush_virt_range instead of directly invoking clflush. This
will prevent compiler errors when building for non-x86 architectures.
v2(Michael Cheng): Remove extra clflush
v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range
takes care of it.
Replace all occurrence of cache_clflush_range with drm_clflush_virt_range.
This will prevent compile errors on non-x86 platforms.
Signed-off-by: Michael Cheng
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 12 ++--
Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.
v2(Michael Cheng): Use sizeof(*addr) instead of sizeof(addr) to get the
actual size of the page. Thanks to Matt Roper for
pointing
This patch series re-work a few i915 functions to use drm_clflush_virt_range
instead of calling clflush or clflushopt directly. This will prevent errors
when building for non-x86 architectures.
v2: s/PAGE_SIZE/sizeof(value) for Re-work intel_write_status_page and added
more patches to convert
Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
This allows for one less function call, and prevent complier errors when
building for non-x86 architectures.
v2(Michael Cheng): Drop invalidate_csb_entries function and directly
invoke drm_clflush_virt_range.
Re-work intel_write_status_page to use drm_clflush_virt_range. This
will prevent compiler errors when building for non-x86 architectures.
Signed-off-by: Michael Cheng
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine.h | 13 -
1 file changed, 4 insertions(+), 9
Add arm64 support for drm_clflush_virt_range. dcache_clean_inval_poc
performs a flush by first performing a clean, follow by an invalidation
operation.
v2 (Michael Cheng): Use correct macro for cleaning and invalidation the
dcache. Thanks Tvrtko for the suggestion.
v3
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 changes done
> > in ->probe(). Usually this means calling
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
> >>> macro is
On Tue, Feb 22, 2022 at 09:27:23AM +0100, Jan Kara wrote:
> On Thu 17-02-22 20:10:03, Byungchul Park wrote:
> > [7.009608] ===
> > [7.009613] DEPT: Circular dependency has been detected.
> > [7.009614] 5.17.0-rc1-00014-g8a599299c0cb-dirty
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
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 31
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 timeout
for compute capable engines was
From: Evan Quan
[ Upstream commit 0136f5844b006e2286f873457c3fcba8c45a3735 ]
Correct the UMD pstate profiling clocks for Dimgrey Cavefish and Beige
Goby.
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
From: Evan Quan
[ Upstream commit 0136f5844b006e2286f873457c3fcba8c45a3735 ]
Correct the UMD pstate profiling clocks for Dimgrey Cavefish and Beige
Goby.
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
/20220222-212043
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: mips-allmodconfig
(https://download.01.org/0day-ci/archive/20220223/202202231024.8sblrlyr-...@intel.com/config)
compiler: mips-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget
On 09 2月 22 14:53:19, Cai Huoqing wrote:
> The nouveau driver depends on include/linux/list.h instead of
> nvif/list.h, so remove the obstacle-nvif/list.h.
>
> Signed-off-by: Cai Huoqing
> ---
Ping :)
> drivers/gpu/drm/nouveau/include/nvif/list.h | 353
> 1 file changed,
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 prevent
unwanted resets. Instead, the hang
On 2/22/2022 16:52, Ceraolo Spurio, Daniele wrote:
On 2/18/2022 1:33 PM, 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 of 32bit
overflow. On current
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 of 32bit
overflow. On current platforms,
On 2/22/2022 17:39, Ceraolo Spurio, Daniele wrote:
On 2/11/2022 5:04 PM, john.c.harri...@intel.com wrote:
From: John Harrison
It is possible for reset notifications to arrive for a context that is
in the process of being banned. So don't flag these as an error, just
report it as informational
On Tue, Feb 22, 2022 at 09:27:23AM +0100, Jan Kara wrote:
> On Thu 17-02-22 20:10:03, Byungchul Park wrote:
> > [7.009608] ===
> > [7.009613] DEPT: Circular dependency has been detected.
> > [7.009614] 5.17.0-rc1-00014-g8a599299c0cb-dirty
On 2/11/2022 5:04 PM, john.c.harri...@intel.com wrote:
From: John Harrison
It is possible for reset notifications to arrive for a context that is
in the process of being banned. So don't flag these as an error, just
report it as informational (because it is still useful to know that
resets
On 2/17/2022 3:52 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Some G2H handlers were reading the context id field from the payload
before checking the payload met the minimum length required.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
While
On 2/17/2022 3:52 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The CTB registration process changed significantly a while back using
a single KLV based H2G. So drop the original and now obsolete H2G
definitions.
The GuC specs has those defines marked as deprecated since v63
On 2/17/2022 3:52 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The LRC descriptor pool is going away. So, stop naming context ids as
descriptor pool indecies.
While at it, add a bunch of missing line feeds to some error messages.
Signed-off-by: John Harrison
Reviewed-by:
Thanks for letting me know! I will try for a different solution.
On 2022-02-22 11:24 a.m., Thomas Hellström (Intel) wrote:
Hi, Michael,
On 2/22/22 18:26, Michael Cheng wrote:
This patch removes logic for wbinvd_on_all_cpus and brings in
drm_cache.h. This header has the logic that outputs a
On 2/17/2022 3:52 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The LRC descriptor was being initialised early on in the context
registration sequence. It could then be determined that the actual
registration needs to be delayed and the descriptor would be wiped
out. This is
On 2/17/2022 3:52 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The LRC descriptor pool is going away. Further, the function that was
populating it was also doing a bunch of logic about the context
registration sequence. So, split that code apart into separate state
setup and try
On 2/17/2022 3:52 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The LRC descriptor pool is going away. So, stop using it as the limit
for how many context ids are available.
I think this could be slightly reworded to make it clear that the
numbers are not changing. Maybe add
On Mon, Feb 21, 2022 at 6:41 AM Akhil P Oommen wrote:
>
> This series supercedes [1]. Major change in this series is that it is now
> optional to include a gpu name in the gpu-list. This helps to avoid the
> confusion when we have different SKUs with different gpu names. And also
> I am pretty
On Mon, Feb 21, 2022 at 6:41 AM Akhil P Oommen wrote:
>
> Use a gpu name which is sprintf'ed from the chipid for 7c3 gpu instead of
> hardcoding one. This helps to avoid code churn in case of a gpu rename.
>
> Signed-off-by: Akhil P Oommen
> ---
>
> drivers/gpu/drm/msm/adreno/adreno_device.c |
On 2/18/2022 1:33 PM, 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 of 32bit
overflow. On current platforms, worst case scenario is approximately
110
On 2/18/2022 6:48 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-02-17 13:36:25)
The “DP timing” requires the active region to be defined in the
bottom-right corner of the frame dimensions which is different
with DSI. Therefore both display_h_end and display_v_end need
to be adjusted
On Mon, Feb 21, 2022 at 5:23 PM Konrad Dybcio
wrote:
>
> Add support for the Adreno 619 GPU, as found in Snapdragon 690 (SM6350),
> 480 (SM4350) and 750G (SM7225).
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 11 ++--
>
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.
> > [9.008164] 5.17.0-rc1-00015-gb94f67143867-dirty
Widebus feature will transmit two pixel data per pixel clock to interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine register
setting to accommodate both widebus and non widebus application. Also
horizontal
The “DP timing” requires the active region to be defined in the
bottom-right corner of the frame dimensions which is different
with DSI. Therefore both display_h_end and display_v_end need
to be adjusted accordingly. However current implementation has
only display_h_end adjusted.
Signed-off-by:
Widebus feature will transmit two pixel data per pixel clock to interface.
This feature now is required to be enabled to easy migrant to higher
resolution applications in future. However since some legacy chipsets
does not support this feature, this feature is enabled base on chip's
hardware
To improve code readability, this patch replace BIT(x) with
correspond register bit define string
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 +---
1 file changed, 9 insertions(+), 3
revise widebus timing engine programming and enable widebus feature base on chip
Kuogee Hsieh (4):
drm/msm/dpu: adjust display_v_end for eDP and DP
drm/msm/dpu: replace BIT(x) with correspond marco define string
drm/msm/dpu: revise timing engine programming to support widebus
feature
On 2/18/2022 6:53 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-02-17 13:36:27)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0d315b4..0c22839 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++
Hi,
On Wed, Feb 16, 2022 at 1:36 AM Javier Martinez Canillas
wrote:
>
> On 2/16/22 10:25, Jani Nikula wrote:
>
> [snip]
>
> >>
> >> I actually wrote said follow-up patches and they were ready to go, but
> >> when I was trying to come up with the right "Fixes" tag I found commit
> >> b792e64021ec
Hi Michael,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm/drm-next drm-tip/drm-tip v5.17-rc5
next-20220217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Hi Michael,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm/drm-next drm-tip/drm-tip v5.17-rc5
next-20220217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Sun, Feb 20, 2022 at 10:55:52PM +0800, Sui Jingfeng wrote:
> From: suijingfeng
Follow the conventions of the subsystem for patch subjects. It should be
evident with 'git log --oneline Documentation/devicetree/bindings/display'.
Something like this:
dt-bindings: display: Add Loongson
Widebus feature will transmit two pixel data per pixel clock to interface.
This feature now is required to be enabled to easy migrant to higher
resolution applications in future. However since some legacy chipsets
does not support this feature, this feature is enabled base on chip's
hardware
Widebus feature will transmit two pixel data per pixel clock to interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine register
setting to accommodate both widebus and non widebus application. Also
horizontal
The “DP timing” requires the active region to be defined in the
bottom-right corner of the frame dimensions which is different
with DSI. Therefore both display_h_end and display_v_end need
to be adjusted accordingly. However current implementation has
only display_h_end adjusted.
Signed-off-by:
To improve code readability, this patch replace BIT(x) with
correspond register bit define string
Signed-off-by: Kuogee Hsieh
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git
revise widebus timing engine programming and enable widebus feature base on chip
Kuogee Hsieh (4):
drm/msm/dpu: adjust display_v_end for eDP and DP
drm/msm/dpu: replace BIT(x) with correspond marco define string
drm/msm/dpu: revise timing engine programming to support widebus
feature
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 changes done
> in ->probe(). Usually this means calling pm_runtime_disable(),
> pm_runtime_dont_use_autosuspend() etc.
>
> We weren't doing that
On Thu, Feb 10, 2022 at 10:36:36AM -0800, Michael Cheng wrote:
> Replace all occurrence of cache_clflush_range with drm_clflush_virt_range.
> This will prevent compile errors on non-x86 platforms.
>
> Signed-off-by: Michael Cheng
Reviewed-by: Matt Roper
> ---
>
On Thu, Feb 10, 2022 at 10:36:35AM -0800, Michael Cheng wrote:
> Use drm_clflush_virt_range instead of clflushopt and remove the memory
> barrier, since drm_clflush_virt_range takes care of that.
>
> Signed-off-by: Michael Cheng
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8
On Thu, Feb 10, 2022 at 10:36:34AM -0800, Michael Cheng wrote:
> Use drm_clflush_virt_range instead of directly invoking clflush. This
> will prevent compiler errors when building for non-x86 architectures.
>
> v2(Michael Cheng): Remove extra clflush
>
> v3(Michael Cheng): Remove memory barrier
On Thu, Feb 10, 2022 at 10:36:33AM -0800, Michael Cheng wrote:
> Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
> This allows for one less function call, and prevent complier errors when
> building for non-x86 architectures.
>
> v2(Michael Cheng): Drop
The PM Runtime docs say:
Drivers in ->remove() callback should undo the runtime PM changes done
in ->probe(). Usually this means calling pm_runtime_disable(),
pm_runtime_dont_use_autosuspend() etc.
We weren't doing that for autosuspend. Let's do it.
Fixes: 9bede63127c6 ("drm/bridge:
Hi,
On Thu, Feb 17, 2022 at 2:42 PM Brian Norris wrote:
>
> If the display is not enable()d, then we aren't holding a runtime PM
> reference here. Thus, it's easy to accidentally cause a hang, if user
> space is poking around at /dev/drm_dp_aux0 at the "wrong" time.
>
> Let's get a runtime PM
Hi,
On Thu, Feb 17, 2022 at 2:42 PM Brian Norris wrote:
>
> DP AUX transactions can consist of many short operations. There's no
> need to power things up/down in short intervals.
>
> I pick an arbitrary 100ms; for the systems I'm testing (Rockchip
> RK3399), runtime-PM transitions only take a
On Thu, Feb 10, 2022 at 10:36:32AM -0800, Michael Cheng wrote:
> Re-work intel_write_status_page to use drm_clflush_virt_range. This
> will prevent compiler errors when building for non-x86 architectures.
>
It looks like this will also cause old x86 cpu's that don't have clflush
to do an extra
On 23/02/2022 00:32, Doug Anderson wrote:
Hi,
On Tue, Feb 22, 2022 at 1:23 PM Dmitry Baryshkov
wrote:
On 22/02/2022 22:25, Doug Anderson wrote:
Hi,
On Mon, Feb 21, 2022 at 7:12 PM Dmitry Baryshkov
wrote:
+static int dp_link_psr_status(struct dp_link_private *link)
+{
+ u8
Hi,
On Tue, Feb 22, 2022 at 1:46 PM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2022-02-22 13:25:05)
> > Hi,
> >
> > On Tue, Feb 22, 2022 at 12:58 PM Stephen Boyd wrote:
> > >
> > > Quoting Vinod Polimera (2022-02-21 05:12:06)
> > > > Panels with higher refresh rate will need mdp clk above
On Thu, Feb 10, 2022 at 10:36:31AM -0800, Michael Cheng wrote:
> Add arm64 support for drm_clflush_virt_range. dcache_clean_inval_poc
> performs a flush by first performing a clean, follow by an invalidation
> operation.
>
> v2 (Michael Cheng): Use correct macro for cleaning and invalidation the
Quoting Doug Anderson (2022-02-22 13:25:05)
> Hi,
>
> On Tue, Feb 22, 2022 at 12:58 PM Stephen Boyd wrote:
> >
> > Quoting Vinod Polimera (2022-02-21 05:12:06)
> > > Panels with higher refresh rate will need mdp clk above 300Mhz.
> > > Select max frequency for mdp clock during bootup, dpu driver
On Tue, Feb 22, 2022 at 3:02 PM Maxime Ripard wrote:
>
> Hi,
>
> On Mon, Feb 21, 2022 at 05:42:36PM +0100, Karol Herbst wrote:
> > On Mon, Feb 21, 2022 at 11:00 AM Maxime Ripard wrote:
> > >
> > > The nouveau KMS driver will call drm_plane_create_zpos_property() with
> > > an init value
Hi,
On Tue, Feb 22, 2022 at 1:23 PM Dmitry Baryshkov
wrote:
>
> On 22/02/2022 22:25, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Feb 21, 2022 at 7:12 PM Dmitry Baryshkov
> > wrote:
> >>
> >>> +static int dp_link_psr_status(struct dp_link_private *link)
> >>> +{
> >>> + u8 status[2];
>
On 2022-02-22 16:21, Christoph Hellwig wrote:
On Fri, Feb 18, 2022 at 01:39:45PM +0200, Mikko Perttunen wrote:
The context bus is a "dummy" bus that contains struct devices that
correspond to IOMMU contexts assigned through Host1x to processes.
Even when host1x itself is built as a module, the
Quoting Vinod Polimera (2022-02-21 06:51:26)
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index e7c9fe1..ba3240c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -951,6 +952,14
Hi,
On Tue, Feb 22, 2022 at 12:58 PM Stephen Boyd wrote:
>
> Quoting Vinod Polimera (2022-02-21 05:12:06)
> > Panels with higher refresh rate will need mdp clk above 300Mhz.
> > Select max frequency for mdp clock during bootup, dpu driver will
> > scale down the clock as per usecase when first
On 22/02/2022 22:25, Doug Anderson wrote:
Hi,
On Mon, Feb 21, 2022 at 7:12 PM Dmitry Baryshkov
wrote:
+static int dp_link_psr_status(struct dp_link_private *link)
+{
+ u8 status[2];
+
+ drm_dp_dpcd_read(link->aux, DP_PSR_ERROR_STATUS, status, 2);
+
+ if (status[0] &
Quoting Vinod Polimera (2022-02-21 06:51:24)
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index b32295a..5c7dc82 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -102,30 +136,82 @@ static void panel_bridge_detach(struct
On Mon 21 Feb 06:51 PST 2022, Vinod Polimera wrote:
> Add support for basic panel self refresh (PSR) feature for eDP.
> Add a new interface to set PSR state in the sink from DPU.
> Program the eDP controller to issue PSR enter and exit SDP to
> the sink.
>
> Signed-off-by: Sankeerth Billakanti
Hi Michael,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm/drm-next drm-tip/drm-tip v5.17-rc5 next-20220217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Quoting José Expósito (2022-02-20 23:33:39)
> The function "drm_of_find_panel_or_bridge" has been deprecated in
> favor of "devm_drm_of_get_bridge".
>
> Switch to the new function and reduce boilerplate.
>
> Signed-off-by: José Expósito
> ---
Dmitry is rewriting this code in a larger series.
On Thu, 2022-02-17 at 23:07 +0100, Jocelyn Falempe wrote:
> On 17/02/2022 19:15, Lyude Paul wrote:
> > Hi! Sorry for the late reply, I had to take some time off work
> > unexpectedly.
> > This is normal (although not great TBH, I'm not sure we should be printing
> > an
> > error message for that),
Quoting Vinod Polimera (2022-02-21 05:12:06)
> Panels with higher refresh rate will need mdp clk above 300Mhz.
> Select max frequency for mdp clock during bootup, dpu driver will
> scale down the clock as per usecase when first update from the framework is
> received.
>
> Signed-off-by: Vinod
On Fri, Feb 18, 2022 at 9:51 AM Rob Clark wrote:
>
> On Fri, Feb 18, 2022 at 8:42 AM Chia-I Wu wrote:
> >
> > On Fri, Feb 18, 2022 at 7:57 AM Rob Clark wrote:
> > >
> > > From: Rob Clark
> > >
> > > With native userspace drivers in guest, a lot of GEM objects need to be
> > > neither shared
Reviewed-by: Lyude Paul
I assume you'll handle pushing this yourself? (JFYI - using drm-misc for
pushing this is fine by me)
On Mon, 2022-02-21 at 10:59 +0100, Maxime Ripard wrote:
> The nouveau KMS driver will call drm_plane_create_zpos_property() with
> an init value depending on the plane
On Sat, Feb 19, 2022 at 9:02 AM Rob Clark wrote:
>
> From: Rob Clark
>
> With native userspace drivers in guest, a lot of GEM objects need to be
> neither shared nor mappable. And in fact making everything mappable
> and/or sharable results in unreasonably high fd usage in host VMM.
>
>
Hi
Am 01.02.22 um 09:17 schrieb Maarten Lankhorst:
Op 01-02-2022 om 07:38 schreef Dave Airlie:
On Thu, 27 Jan 2022 at 21:57, Maarten Lankhorst
wrote:
Hi Dave & Daniel,
First pull for v5.18
I was trying to be all efficient and get this pulled in time for once.
However it broke building on
On Mon, Feb 21, 2022 at 11:21:35AM +0200, Jani Nikula wrote:
On Mon, 21 Feb 2022, Dave Airlie wrote:
On Thu, 17 Feb 2022 at 20:26, Joonas Lahtinen
wrote:
Hi Dave & Daniel,
Here is the first drm-intel-gt-next feature PR towards v5.18.
Am I missing some previous drm-intel pull?
Hi,
On Mon, Feb 21, 2022 at 7:12 PM Dmitry Baryshkov
wrote:
>
> > +static int dp_link_psr_status(struct dp_link_private *link)
> > +{
> > + u8 status[2];
> > +
> > + drm_dp_dpcd_read(link->aux, DP_PSR_ERROR_STATUS, status, 2);
> > +
> > + if (status[0] & DP_PSR_LINK_CRC_ERROR)
Hi, Michael,
On 2/22/22 18:26, Michael Cheng wrote:
This patch removes logic for wbinvd_on_all_cpus and brings in
drm_cache.h. This header has the logic that outputs a warning
when wbinvd_on_all_cpus when its being used on a non-x86 platform.
Signed-off-by: Michael Cheng
Linus has been
On Thu, Feb 03, 2022 at 12:54:16PM +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
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 rotate the console so that
it shows up-right instead of on
On Thu, Feb 17, 2022 at 2:06 PM Alex Deucher wrote:
>
> On Thu, Feb 17, 2022 at 2:04 PM Nick Desaulniers
> wrote:
> >
> >
> > Alex,
> > Has AMD been able to set up clang builds, yet?
>
> No. I think some individual teams do, but it's never been integrated
> into our larger CI systems as of yet
On 08/02/22 3:10 pm, Matthew Auld wrote:
> On 03/02/2022 13:32, Arunpravin wrote:
>> add a test to check the maximum allocation limit
>>
>> Signed-off-by: Arunpravin
>> ---
>> .../gpu/drm/selftests/drm_buddy_selftests.h | 1 +
>> drivers/gpu/drm/selftests/test-drm_buddy.c| 60
On Tue, Feb 22, 2022 at 12:03:23PM +, Colin Ian King wrote:
> 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
> ---
Hi
Am 22.02.22 um 14:01 schrieb Pekka Paalanen:
On Mon, 21 Feb 2022 20:54:09 +0100
Thomas Zimmermann wrote:
Improve the performance of sys_imageblit() by manually unrolling
sys?
the inner blitting loop and moving some invariants out. The compiler
failed to do this automatically. This
On 08/02/22 4:05 pm, Matthew Auld wrote:
> On 03/02/2022 13:32, Arunpravin wrote:
>> - move i915 buddy selftests into drm selftests folder
>> - add Makefile and Kconfig support
>> - add sanitycheck testcase
>>
>> Prerequisites
>> - These series of selftests patches are created on top of
>>
create a pot-sized mm, then allocate one of each possible
order within. This should leave the mm with exactly one
page left.
v2:
- removed unnecessary test succeeded print
- replace list_del()/list_add_tail() with list_move_tail()
Signed-off-by: Arunpravin
Reviewed-by: Matthew Auld
create a pot-sized mm, then allocate one of each possible
order within. This should leave the mm with exactly one
page left. Free the largest block, then whittle down again.
Eventually we will have a fully 50% fragmented mm.
v2(Matthew Auld):
- removed unnecessary test succeeded print
-
- add a test to ascertain that the critical functionalities
of the program is working fine
- add a timeout helper function
v2:
- removed unnecessary test succeeded print
- replace list_del()/list_add_tail() with list_move_tail()
Signed-off-by: Arunpravin
Reviewed-by: Matthew Auld
create a mm with one block of each order available, and
try to allocate them all.
v2(Matthew Auld):
- removed unnecessary test succeeded print
- replace list_del()/list_add_tail() with list_move_tail()
Signed-off-by: Arunpravin
Reviewed-by: Matthew Auld
Acked-by: Christian König
---
1 - 100 of 239 matches
Mail list logo
