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 proprie
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
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 https://bugzilla.kernel.org/show_bug.c
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
> > +++ b/driv
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 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
--- a/drivers/gpu/drm/mxsfb/lcdif
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 found
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: Re
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 lo
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 th
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 blk-ctrl).
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 MEDIA_BU
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 intro
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
Rev
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 support.
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:
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
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 UT
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 initializa
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 fix
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 a/drivers/gpu
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 fi
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
Review
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 fb_io_fop
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 ++--
2
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 to
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 memset_io
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: https://bugzilla.redhat.com/
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 w
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 con
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
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, 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 ra
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.
>
> Signe
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 con
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 drivers/vi
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 may
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 file
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 a/drivers/gpu/drm
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 regu
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 read
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
[-Wmissing-include-d
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 befo
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
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: D
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 memory
>> 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 |= lm3630a_update(pchi
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 backligh
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 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
>> bot
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 driv
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:
https://lore.kernel.org/lkml/ca
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 ---
driver
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 forme
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 of
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 in
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 Weiga
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
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 preparat
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 cha
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 ini
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 i
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 wh
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 PXP
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
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
Reviewed-by:
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 non-priv
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:
1
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 ran
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
th
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
---
dri
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 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
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 propa
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 dynami
Fix the STI console to be able to execute either the 64-bit STI ROM code
or the 32-bit STI ROM code.
This is necessary on 64-bit only machines (e.g. C8000 workstation) which
otherwise won't show the STI text console with HP graphic cards like
Visualize-FX5/FX10/FXe.
When calling 32-bit code from
Fix the STI console to be able to execute either the 64-bit STI ROM code
or the 32-bit STI ROM code.
This is necessary on 64-bit only machines (e.g. C8000 workstation) which
otherwise won't show the STI text console with HP graphic cards like
Visualize-FX5/FX10/FXe.
When calling 32-bit code from
There is bug report on exteranl DP display does not work.
This patch add below two patches to fix the problem.
1) enable HDP plugin/unplugged interrupts to hpd_enable/disable
2) add mutex to protect internal_hpd against race condition between different
threads
Kuogee Hsieh (2):
drm/msm/dp:
The internal_hpd flag was introduced to handle external DP HPD derived from GPIO
pinmuxed into DP controller. HPD plug/unplug interrupts cannot be enabled until
internal_hpd flag is set to true.
At both bootup and resume time, the DP driver will enable external DP
plugin interrupts and handle plugi
Intrenal_hpd is referenced by event thread but set by drm bridge callback
context. Add mutex to protect internal_hpd to avoid conflicts between
threads.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git
On Wed, 2023-05-10 at 16:19 +0200, Thomas Hellström wrote:
> 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' li
From: John Harrison
A recent change bumped a 'notice' message up to 'error' level for
debug builds to help trap incorrect configurations in CI systems.
Unfortunaetly, tha error condition in question is triggered by the
error injection probe test. So change the message again to be 'probe
error' le
On 5/9/2023 11:33 PM, Marijn Suijten wrote:
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
On Sun, May 07, 2023 at 06:25:24PM +0200, 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
...fixing some Cc email addresses I somehow mangled.
On 2023-05-10 12:40:07, Souza, Jose wrote:
> On Mon, 2023-05-08 at 17:49 +, Teres Alexis, Alan Previn wrote:
> > On Fri, 2023-05-05 at 00:39 -0700, Justen, Jordan L wrote:
> > > On 2023-05-04 22:30:07, Teres Alexis, Alan Previn wrote:
> > >
On Sun, May 07, 2023 at 06:25:25PM +0200, 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
On Sun, May 07, 2023 at 06:25:26PM +0200, 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
alan:snip
> This is why I asked if it was it was "basically certain that in a
> production environment, then it will eventually return 1 meaning it's
> ready". Alan's response was a little ambiguous on this point.
alan: if we get a '2' and never transition to '1' - thats a kernel bug or
firmware
This series adds the DPU side changes to support DSC 1.2 encoder. This
was validated with both DSI DSC 1.2 panel and DP DSC 1.2 monitor.
The DSI and DP parts will be pushed later on top of this change.
This seriel is rebase on [1], [2] and catalog fixes from rev-4 of [3].
[1]: https://patchwork.fr
1 - 100 of 156 matches
Mail list logo
