On 2023-05-09 15:06:53, Jessica Zhang wrote:
> Use MSM and DRM DSC helper methods to configure DSC for DSI.
>
> Signed-off-by: Jessica Zhang
> Reviewed-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git
On 2023-05-09 15:06:54, Jessica Zhang wrote:
> hdisplay for compressed images should be calculated as bytes_per_slice *
> slice_count. Thus, use MSM DSC helper to calculate hdisplay for
For most intents and purposes, these values are the same when
bits_per_pixel=8.
We should find a place where
On Tue, May 09, 2023 at 09:56:33AM -0700, Lucas De Marchi wrote:
> On Tue, May 09, 2023 at 11:10:08AM -0400, Rodrigo Vivi wrote:
> > As documented in drivers/staging/Kconfig:
> >
> > STAGING means "that these drivers are under heavy development" and
> > "may contain userspace interfaces that most
On 2023-05-09 15:06:47, Jessica Zhang wrote:
> Add helpers to calculate det_thresh_flatness and initial_scale_value as
> these calculations are defined within the DSC spec.
>
> Signed-off-by: Dmitry Baryshkov
> Signed-off-by: Jessica Zhang
This ordering is odd: Jessica originally sent the
On 2023-05-09 15:06:48, Jessica Zhang wrote:
> From: Dmitry Baryshkov
>
> Add a helper setting config values which are typically constant across
> operating modes (table E-4 of the standard) and mux_word_size (which is
> a const according to 3.5.2).
>
> Signed-off-by: Dmitry Baryshkov
>
On 2023-05-09 15:06:50, Jessica Zhang wrote:
> Introduce MSM-specific DSC helper methods, as some calculations are
> common between DP and DSC.
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/msm/Makefile | 1 +
>
Title suggestion: Use **fixed** MSM DSC helper...
To make it clear that this is a bugfix without having to read the commit
description first.
- Marijn
On 2023-05-09 15:06:51, Jessica Zhang wrote:
> The current dpu_hw_dsc calculation for det_thresh_flatness does not
> match the downstream
On Tue, May 09, 2023 at 08:22:30PM +, Simon Ser wrote:
> On Tuesday, May 9th, 2023 at 21:53, Dave Airlie wrote:
>
> > There are also other vendor side effects to having this in userspace.
> >
> > Will the library have a loader?
> > Will it allow proprietary plugins?
> > Will it allow
On 5/10/23 16:51, Linux regression tracking (Thorsten Leemhuis) wrote:
> Bagas, thx for all your help with regression tracking, much appreciated
> (side note, as I'm curious for a while already: what is your motivation?
> Just want to help? But whatever, any help is great!).
>
I did this when I
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[cannot apply to deller-parisc/for-next arnd-asm-generic/master linus/master
davem-sparc/master v6.4-rc1 next-20230510]
[If your patch is applied to the wrong git tree, kindly
On Fri, 05 May 2023 07:21:10 +0200, Roman Beranek wrote:
> In DSI mode, TCON0's data clock is required to run at 1/4 the per-lane
> bit rate.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Fri, 05 May 2023 07:21:09 +0200, Roman Beranek wrote:
> While the rate of TCON0's DCLK matches dotclock for parallel and LVDS
> outputs, this doesn't hold for DSI. The 'D' in DCLK actually stands for
> 'Data' according to Allwinner's manuals. The clock is mostly referred to
> as dclk throughout
On Wed, May 10, 2023, at 16:03, kernel test robot wrote:
>
>cc1: warning: arch/sh/include/mach-hp6xx: No such file or directory
> [-Wmissing-include-dirs]
>cc1: warning: arch/sh/include/mach-hp6xx: No such file or directory
> [-Wmissing-include-dirs]
>In file included from
Hi Thomas,
On Wed, May 10, 2023 at 4:20 PM Thomas Zimmermann wrote:
> Am 10.05.23 um 14:34 schrieb Geert Uytterhoeven:
> > On Wed, May 10, 2023 at 1:06 PM Thomas Zimmermann
> > wrote:
> >> Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
> >> in the architecture's header
Hi Thomas,
On Wed, May 10, 2023 at 1:06 PM Thomas Zimmermann wrote:
> Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
> in the architecture's header file or the generic one.
>
> The common case has been the use of regular I/O functions, such as
> __raw_readb() or
When mgag200 switched from simple KMS to regular atomic helpers,
the initialization of the gamma settings was lost.
This leads to a black screen, if the bios/uefi doesn't use the same
pixel color depth.
v2: rebase on top of drm-misc-fixes, and add Cc stable tag.
Link:
From: Vitaly Prosyak
During an IGT GPU reset test we see again oops despite of
commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling
timeout handling).
It uses ready condition whether to call drm_sched_fault which unwind
the TDR leads to GPU reset.
However it looks the ready
On 2023-05-10 09:51, vitaly.pros...@amd.com wrote:
> From: Vitaly Prosyak
>
> During an IGT GPU reset test we see again oops despite of
> commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling
> timeout handling).
>
> It uses ready condition whether to call drm_sched_fault which
Each VM has two rebind lists, one protected by the VM resv, the other
one protected essentially by the VM notifier.list_lock. This series
intends to fix two points of illegal access.
Patch 1 fixes an access of VM rebind_lists' link without the VM resv held.
Patch 2 fixes an issue where the VMA
the vma::rebind_link is protected by the vm's resv, but we was
modifying it without. Fix this by use the vma::userptr_link instead
for the tmp_evict list. The vma::userptr_link is protected by the
vm lock.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/xe/xe_vm.c | 14 +++---
1
On 2023-05-10 10:24, vitaly prosyak wrote:
>
> On 2023-05-10 10:19, Luben Tuikov wrote:
>> On 2023-05-10 09:51, vitaly.pros...@amd.com wrote:
>>> From: Vitaly Prosyak
>>>
>>> During an IGT GPU reset test we see again oops despite of
>>> commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready
From: Vitaly Prosyak
During an IGT GPU reset test we see again oops despite of
commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling
timeout handling).
It uses ready condition whether to call drm_sched_fault which unwind
the TDR leads to GPU reset.
However it looks the ready
On 2023-05-10 10:19, Luben Tuikov wrote:
> On 2023-05-10 09:51, vitaly.pros...@amd.com wrote:
>> From: Vitaly Prosyak
>>
>> During an IGT GPU reset test we see again oops despite of
>> commit 0c8c901aaaebc9 (drm/sched: Check scheduler ready before calling
>> timeout handling).
>>
>> It uses
On Fri, May 05, 2023 at 07:21:07AM +0200, Roman Beranek wrote:
> TCON0's source clock can be fed from either PLL_MIPI, or PLL_VIDEO0(2X),
> however MIPI DSI output only seems to work when PLL_MIPI is selected and
> thus the choice must be hardcoded in.
>
> Currently, this driver can't propagate
On Fri, May 05, 2023 at 07:21:08AM +0200, Roman Beranek wrote:
> While the rate of TCON0's DCLK matches dotclock for parallel and LVDS
> outputs, this doesn't hold for DSI. According manuals from Allwinner,
> DCLK is an abbreviation of Data Clock, not dotclock, so go with that
> instead.
>
>
Hi Geert
Am 10.05.23 um 14:34 schrieb Geert Uytterhoeven:
Hi Thomas,
On Wed, May 10, 2023 at 1:06 PM Thomas Zimmermann wrote:
Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
in the architecture's header file or the generic one.
The common case has been the use of
If a vma was destroyed with the bo evicted, it might happen that we forget
to remove it from the notifer::rebind_list. Fix to make sure that really
happens.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/xe/xe_vm.c | 9 +
1 file changed, 9 insertions(+)
diff --git
Hi
Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
On Wed, May 10, 2023, at 16:03, kernel test robot wrote:
cc1: warning: arch/sh/include/mach-hp6xx: No such file or directory
[-Wmissing-include-dirs]
cc1: warning: arch/sh/include/mach-hp6xx: No such file or directory
With all previous preparations done to make it possible for the
single LCDIF embedded in i.MX93 SoC to drive multiple displays
simultaneously, add i.MX93 LCDIF compatible string as the last
step of adding i.MX93 LCDIF support.
Tested-by: Alexander Stein
Reviewed-by: Alexander Stein
Reviewed-by:
The single LCDIF embedded in i.MX93 SoC may drive multiple displays
simultaneously. Look at LCDIF output port's remote port parents to
find all enabled first bridges. Add an encoder for each found bridge
and attach the bridge to the encoder. This is a preparation for
adding i.MX93 LCDIF
On 10/05/2023 11:15, Thomas Zimmermann wrote:
Hi,
oh great! Thank you for fixing this bug. And sorry that I broke it.
Am 10.05.23 um 10:54 schrieb Jocelyn Falempe:
When mgag200 switched from simple KMS to regular atomic helpers,
the initialization of the gamma settings was lost.
This leads to
On Tue, May 9, 2023 at 10:14 AM Marek Vasut wrote:
>
> On 5/8/23 07:57, Liu Ying wrote:
>
> Hi,
Hi,
>
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > index 262bc43b1079..e54200a9fcb9 100644
> > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > +++
On Tue, May 9, 2023 at 10:14 AM Marek Vasut wrote:
>
> On 5/8/23 07:57, Liu Ying wrote:
> > The single LCDIF embedded in i.MX93 SoC may drive multiple displays
> > simultaneously. Look at LCDIF output port's remote port parents to
> > find all enabled first bridges. Add an encoder for each
On Tue, 09 May 2023 20:22:30 +
Simon Ser wrote:
> On Tuesday, May 9th, 2023 at 21:53, Dave Airlie wrote:
>
> > There are also other vendor side effects to having this in userspace.
> >
> > Will the library have a loader?
> > Will it allow proprietary plugins?
> > Will it allow proprietary
When mgag200 switched from simple KMS to regular atomic helpers,
the initialization of the gamma settings was lost.
This leads to a black screen, if the bios/uefi doesn't use the same
pixel color depth.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2171155
Fixes: 1baf9127c482 ("drm/mgag200:
Hi,
This patch set aims to add i.MX93 LCDIF display controller support
in the existing LCDIF DRM driver. The LCDIF embedded in i.MX93 SoC
is essentially the same to those embedded in i.MX8mp SoC. Through
internal bridges, i.MX93 LCDIF may drive a MIPI DSI display or a LVDS
display or a parallel
There is one LCDIF embedded in i.MX93 SoC to connect with
MIPI DSI controller through LCDIF cross line pattern(controlled
by mediamix blk-ctrl) or connect with LVDS display bridge(LDB)
directly or connect with a parallel display through parallel
display format(also controlled by mediamix
A valid bridge is already found in lcdif_attach_bridge() and set
to lcdif->bridge, so lcdif->bridge cannot be a NULL pointer. Drop
the unnecessary NULL pointer check in KMS stage.
Tested-by: Alexander Stein
Reviewed-by: Alexander Stein
Signed-off-by: Liu Ying
---
v5->v6:
* Keep default
The single LCDIF embedded in i.MX93 SoC may drive multiple displays
simultaneously. Check bus format and flags across first bridges in
->atomic_check() to ensure they are consistent. This is a preparation
for adding i.MX93 LCDIF support.
Acked-by: Alexander Stein
Tested-by: Alexander Stein
Instead of determining LCDIF output bus format and bus flags in
->atomic_enable(), do that in ->atomic_check(). This is a
preparation for the upcoming patch to check consistent bus format
and bus flags across all first downstream bridges in ->atomic_check().
New lcdif_crtc_state structure is
On 5/10/23 10:30, Ying Liu wrote:
On Tue, May 9, 2023 at 10:14 AM Marek Vasut wrote:
On 5/8/23 07:57, Liu Ying wrote:
Hi,
Hi,
Hi,
diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
b/drivers/gpu/drm/mxsfb/lcdif_kms.c
index 262bc43b1079..e54200a9fcb9 100644
---
Hi,
I noticed a regression report on Bugzilla ([1]). As many developers don't
have a look on it, I decided to forward it by email. See the report
for the full thread.
Quoting from the report:
> Azamat S. Kalimoulline 2021-04-06 15:45:08 UTC
>
> Same as in
Hi Nirmoy,
On 9.05.2023 16:03, Nirmoy Das wrote:
Document the unit of ttm_resource_manager.usage which was
missing before.
Cc: Thomas Hellström
Cc: Christian König
Cc: Anshuman Gupta
Signed-off-by: Nirmoy Das
---
include/drm/ttm/ttm_resource.h | 4 ++--
1 file changed, 2 insertions(+),
Hi!
On 10.05.23 10:26, Bagas Sanjaya wrote:
>
> I noticed a regression report on Bugzilla ([1]). As many developers don't
> have a look on it, I decided to forward it by email. See the report
> for the full thread.
>
> Quoting from the report:
>
>> Azamat S. Kalimoulline 2021-04-06 15:45:08
Replace include statements for with . Fixes
the coding style: if a header is available in asm/ and linux/, it
is preferable to include the header from linux/. This only affects
a few source files, most of which already include .
Suggested-by: Sam Ravnborg
Signed-off-by: Thomas Zimmermann
Update the names of the fb_mem*() helpers to be consistent with their
regular counterparts. Hence, fb_memset() now becomes fb_memset_io(),
fb_memcpy_fromfb() now becomes fb_memcpy_fromio() and fb_memcpy_tofb()
becomes fb_memcpy_toio(). No functional changes.
v6:
* update new file
Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
in the architecture's header file or the generic one.
The common case has been the use of regular I/O functions, such as
__raw_readb() or memset_io(). A few architectures used plain system-
memory reads and writes. Sparc used
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
Reviewed-by: Sam Ravnborg
Reviewed-by: Sui Jingfeng
Tested-by: Sui Jingfeng
---
drivers/video/fbdev/matrox/matroxfb_accel.c | 6 +++---
drivers/video/fbdev/matrox/matroxfb_base.h | 4 ++--
The code uses writel() and similar I/O-memory helpers. Include
the header file to get the declarations.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
Reviewed-by: Sam Ravnborg
Reviewed-by: Sui Jingfeng
---
drivers/video/fbdev/arcfb.c | 1 +
drivers/video/fbdev/aty/atyfb.h
Hi Lucas,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.4-rc1 next-20230510]
[cannot apply to drm-misc/drm-misc-next]
[If your patch is applied
ping ?
On 2023/5/4 16:04, Sui Jingfeng wrote:
Loongson display controller IP has been integrated in both Loongson north
bridge chipset(ls7a1000/ls7a2000) and Loongson SoCs(ls2k1000/ls2k2000), it
has been even included in Loongson self-made BMC products.
This display controller is a PCI device.
On Wed, 10 May 2023 09:59:21 +0200
Jonas Ådahl wrote:
> On Tue, May 09, 2023 at 08:22:30PM +, Simon Ser wrote:
> > On Tuesday, May 9th, 2023 at 21:53, Dave Airlie wrote:
> >
> > > There are also other vendor side effects to having this in userspace.
> > >
> > > Will the library have a
Hi,
oh great! Thank you for fixing this bug. And sorry that I broke it.
Am 10.05.23 um 10:54 schrieb Jocelyn Falempe:
When mgag200 switched from simple KMS to regular atomic helpers,
the initialization of the gamma settings was lost.
This leads to a black screen, if the bios/uefi doesn't use
Hi
Am 10.05.23 um 11:29 schrieb Jocelyn Falempe:
On 10/05/2023 11:15, Thomas Zimmermann wrote:
Hi,
oh great! Thank you for fixing this bug. And sorry that I broke it.
Am 10.05.23 um 10:54 schrieb Jocelyn Falempe:
When mgag200 switched from simple KMS to regular atomic helpers,
the
On 2023-05-09 17:43, vitaly.pros...@amd.com wrote:
> From: Vitaly Prosyak
>
> During an IGT GPU reset test we see again oops despite of
> commit 0c8c901aaaebc9bf8bf189ffc116e678f7a2dc16
> drm/sched: Check scheduler ready before calling timeout handling.
You can probably use the more succinct
The code uses readl() and writel(). Include the header file to
get the declarations.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
Reviewed-by: Sam Ravnborg
Reviewed-by: Sui Jingfeng
---
drivers/gpu/ipu-v3/ipu-prv.h | 1 +
1 file changed, 1 insertion(+)
diff --git
Fbdev provides helpers for framebuffer I/O, such as fb_readl(),
fb_writel() or fb_memcpy_to_fb(). The implementation of each helper
depends on the architecture, but they are all equivalent to regular
I/O functions of similar names. So use regular functions instead and
move all helpers into
The
Hey,
On 2023-05-05 21:50, Tejun Heo wrote:
Hello,
On Wed, May 03, 2023 at 10:34:56AM +0200, Maarten Lankhorst wrote:
RFC as I'm looking for comments.
For long running compute, it can be beneficial to partition the GPU memory
between cgroups, so each cgroup can use its maximum amount of
On 5/10/23 11:24, Liu Ying wrote:
A valid bridge is already found in lcdif_attach_bridge() and set
to lcdif->bridge, so lcdif->bridge cannot be a NULL pointer. Drop
the unnecessary NULL pointer check in KMS stage.
Tested-by: Alexander Stein
Reviewed-by: Alexander Stein
Signed-off-by: Liu Ying
Remove the pointless check. If an IOMMU is providing transparent DMA API
ops for any device(s) we care about, the DT code will have enforced the
appropriate probe ordering already.
Signed-off-by: Robin Murphy
---
v2: Rebase to 6.4-rc1
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4
1 file
On 5/3/2023 4:41 AM, Dan Carpenter wrote:
Smatch complains that these are not initialized if get_cntl_version()
fails but we still print them in the debug message. Not the end of
the world, but true enough. Let's just initialize them to a dummy value
to make the checker happy.
Signed-off-by:
On Wed, May 10, 2023, at 16:27, Thomas Zimmermann wrote:
> Am 10.05.23 um 16:15 schrieb Arnd Bergmann:
>> On Wed, May 10, 2023, at 16:03, kernel test robot wrote:
>> I think that's a preexisting bug and I have no idea what the
>> correct solution is. Looking for HD64461 shows it being used
>>
Let's move the logic of the former helper into module.c and use it from
an inline helper located under of_device.c. This way there is no change
for users while the logic gets moved to an OF-only file.
Signed-off-by: Miquel Raynal
---
drivers/of/device.c | 23 ---
There is apparently no reasons to open-code of_device_uevent() besides:
- The helper receives a struct device while we want to use the of_node
member of the struct device *parent*.
- of_device_uevent() could not be called by modules because of a missing
EXPORT_SYMBOL*().
In practice, the
Move the content of the helper providing printable modaliases in
module.c. Call this new function from an of_device.c inline helper.
There is no functional changes. However, as a side effect, we fix the
return value of the inline helper (in the !CONFIG_OF case) which should
be a ssize_t instead
Move the OF related logic inside of/module.c and use it from of_device.h
with an inline helper so there is no visible change from the users point
of view.
Signed-off-by: Miquel Raynal
---
drivers/of/device.c | 42 ---
drivers/of/module.c | 41
The content of of_uevent() is currently hardcoded in a driver that can
be compiled as a module. Nothing prevents of_uevent() to be exported to
modules, most of the other helpers in of_device.c actually are.The
reason why this helper was not exported is because it has been so far
only useful in
Hello,
As part of a previous series, Rob suggested that keeping too much logic
in of/device.c was backward and would benefit from a gradual cleanup
with the hope some day to move the remaining helpers into inline
functions wrapping the proper of_*() methods.
Link:
On 07/05/2023 17:25, 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
> and this typically results
On Wed, May 10, 2023 at 10:52:39AM +0200, Maximilian Weigand wrote:
> From: Maximilian Weigand
>
> Use backlight_is_blank() to determine if the led strings should be turned
> off in the update_status() functions of both strings.
>
> Reviewed-by: Daniel Thompson
> Signed-off-by: Maximilian
>> Use display_is_blank() to determine if the led strings should be turned
>
> Shouldn't this be backlight_is_blank()?
Yes, indeed. Thanks for pointing this out. Fixed in v2.
>> +if (backlight_is_blank(bl) || (bl->props.brightness < 0x4))
> You could replace bl->props.brightness with backlight_get_brightness(bl)
> to avoid direct access to the properties.
Thanks. Changed in v2.
>> +/* turn the string off */
>> ret |=
From: Maximilian Weigand
Use backlight_is_blank() to determine if the led strings should be turned
off in the update_status() functions of both strings.
Reviewed-by: Daniel Thompson
Signed-off-by: Maximilian Weigand
---
Changes in v2:
- fix description, replace display_is_black() with
Hi Geert
Am 10.05.23 um 16:34 schrieb Geert Uytterhoeven:
Hi Thomas,
On Wed, May 10, 2023 at 4:20 PM Thomas Zimmermann wrote:
Am 10.05.23 um 14:34 schrieb Geert Uytterhoeven:
On Wed, May 10, 2023 at 1:06 PM Thomas Zimmermann wrote:
Implement framebuffer I/O helpers, such as fb_read*() and
On 5/10/23 11:24, Liu Ying wrote:
The single LCDIF embedded in i.MX93 SoC may drive multiple displays
simultaneously. Look at LCDIF output port's remote port parents to
find all enabled first bridges. Add an encoder for each found bridge
and attach the bridge to the encoder. This is a
On Wed, May 10, 2023 at 08:57:03AM -0600, Jeffrey Hugo wrote:
> On 5/3/2023 4:41 AM, Dan Carpenter wrote:
> > Smatch complains that these are not initialized if get_cntl_version()
> > fails but we still print them in the debug message. Not the end of
> > the world, but true enough. Let's just
This series enables PXP on MTL. On ADL/TGL platforms, we rely on
the mei driver via the i915-mei PXP component interface to establish
a connection to the security firmware via the HECI device interface.
That interface is used to create and teardown the PXP ARB session.
PXP ARB session is created
Dne ponedeljek, 08. maj 2023 ob 16:08:32 CEST je Frank Oltmanns napisal(a):
> Hello again,
>
> On 2023-05-08 at 08:54:28 +0200, Frank Oltmanns wrote:
> > Hello Roman,
> >
> > On 2023-05-03 at 16:22:32 +0200, "Roman Beranek" wrote:
> >> Hello everyone,
> >>
> >> I apologize for my absence from
Thomas Zimmerman writes:
>
> I found this casting mess even more unreadable. I went back to v2, fixed
> the style issues and committed the patch as v4 (still under your name).
>
> https://cgit.freedesktop.org/drm/drm-tip/commit?id=1b617bc93178912fa36f87a957c15d1f1708c299
Will this patch make it
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the debugfs teardown timeouts to align with
new GSC-CS + firmware specs.
Now that we have 3 places that are selecting pxp timeouts
based on tee vs gsccs back-end, let's add a helper.
Signed-off-by: Alan Previn
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.
Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.
We use
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
Because of the additional firmware, component-driver and
initialization depedencies required on MTL platform before a
PXP context can be created, UMD calling for PXP creation as a
way to get-caps can take a long time. An actual real world
customer stack has seen this happen in the 4-to-8 second
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
While relooking at the ARB session creation flow in intel_pxp_start,
let's address missing UAPI documentation. Without actually changing
backward compatible behavior, update i915's drm-uapi comments
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.
Thus for MTL, we need
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.
Thus, immediately enable (or disable) KCR HW on PXP's init,
fini
Dne petek, 05. maj 2023 ob 07:21:07 CEST je Roman Beranek napisal(a):
> TCON0's source clock can be fed from either PLL_MIPI, or PLL_VIDEO0(2X),
> however MIPI DSI output only seems to work when PLL_MIPI is selected and
> thus the choice must be hardcoded in.
>
> Currently, this driver can't
Hi, Thomas
I love your patch, yet something to improve:
On 2023/5/10 19:05, Thomas Zimmermann wrote:
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
Reviewed-by: Sam Ravnborg
Reviewed-by: Sui Jingfeng
Tested-by: Sui Jingfeng
---
Loading i915 on UBSAN enabled kernels (CONFIG_UBSAN/CONFIG_UBSAN_BOOL)
causes the following warning:
UBSAN: invalid-load in drivers/gpu/drm/i915/gt/uc/intel_uc.c:558:2
load of value 255 is not a valid value for type '_Bool'
Call Trace:
dump_stack_lvl+0x57/0x7d
ubsan_epilogue+0x5/0x40
Dne petek, 05. maj 2023 ob 07:21:08 CEST je Roman Beranek napisal(a):
> While the rate of TCON0's DCLK matches dotclock for parallel and LVDS
> outputs, this doesn't hold for DSI. According manuals from Allwinner,
> DCLK is an abbreviation of Data Clock, not dotclock, so go with that
> instead.
>
Hello,
On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote:
> The misc controller is not granular enough. A single computer may have any
> number of
> graphics cards, some of them with multiple regions of vram inside a single
> card.
Extending the misc controller to support
On 4/13/2023 12:38 AM, Stanislaw Gruszka wrote:
Use DMA_RESV_USAGE_BOOKKEEP reservation for buffer objects, except for
command buffers for which we use DMA_RESV_USAGE_WRITE (since VPU can
write to command buffer context save area).
Fixes: 0ec8671837a6 ("accel/ivpu: Fix S3 system suspend when
On 11/05/2023 01:07, Kuogee Hsieh wrote:
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with the help of the flush mechanism.
Nit: was moved.
Add a DPU_PINGPONG_DSC feature bit to
On 11/05/2023 01:07, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but not
used at dpu_hw_dsc_config_1_2()
-- unrolling thresh loops
Changes
On 11/05/2023 07:38, Abhinav Kumar wrote:
On 5/10/2023 9:29 PM, Dmitry Baryshkov wrote:
On 11/05/2023 01:07, Kuogee Hsieh wrote:
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC setting up. Since DPU >= 7.0.0, enabling and starting the DSC
encoder engine moved to INTF with
On 11/05/2023 07:42, Abhinav Kumar wrote:
On 5/10/2023 9:39 PM, Dmitry Baryshkov wrote:
On 11/05/2023 07:38, Abhinav Kumar wrote:
On 5/10/2023 9:29 PM, Dmitry Baryshkov wrote:
On 11/05/2023 01:07, Kuogee Hsieh wrote:
DPU < 7.0.0 requires the PINGPONG block to be involved during
DSC
Hi Stephen
On 5/10/2023 4:19 PM, Kuogee Hsieh wrote:
internal_hpd is referenced at both plug and unplug handle.
The majority purpose of mutext is try to serialize internal_hpd between
dp_bridge_hpd_disable() and either plug or unplug handle.
On 5/10/2023 4:11 PM, Abhinav Kumar wrote:
internal_hpd is referenced at both plug and unplug handle.
The majority purpose of mutext is try to serialize internal_hpd between
dp_bridge_hpd_disable() and either plug or unplug handle.
On 5/10/2023 4:11 PM, Abhinav Kumar wrote:
On 5/10/2023 3:46 PM, Stephen Boyd wrote:
Quoting
On 5/10/2023 4:55 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2023-05-10 13:31:04)
The internal_hpd flag was introduced to handle external DP HPD derived from GPIO
pinmuxed into DP controller.
Was it? It looks more like it was done to differentiate between eDP and
DP, because
1 - 100 of 154 matches
Mail list logo
