On Thu, 11 Nov 2021 21:58:35 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: Harry Wentland
> > Sent: Friday, November 12, 2021 2:41 AM
> > To: Shankar, Uma ; Ville Syrjälä
> >
> > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> > ppaala...@gmail.com
On Thu, 11 Nov 2021 13:21:03 -0800, Tim Harvey wrote:
> On Thu, Nov 11, 2021 at 2:19 AM Jagan Teki wrote:
> > On Wed, Nov 10, 2021 at 11:58 PM Jagan Teki
> > wrote:
> > > On Wed, Nov 10, 2021 at 2:24 AM Tim Harvey wrote:
> > > > On Tue, Nov 9, 2021 at 12:39 PM Marek Vasut wrote:
> > > > > On 1
On Mon, 8 Nov 2021 15:17:13 +0100
Thomas Zimmermann wrote:
> Hi
>
> Am 08.11.21 um 15:06 schrieb Javier Martinez Canillas:
> > There is a lot of historical baggage on this parameter. It is defined in
> > the vgacon driver as nomodeset, but its set function is called text_mode()
> > and the value
On Fri, Nov 12, 2021 at 2:12 PM Michael Tretter
wrote:
>
> On Thu, 11 Nov 2021 13:21:03 -0800, Tim Harvey wrote:
> > On Thu, Nov 11, 2021 at 2:19 AM Jagan Teki
> > wrote:
> > > On Wed, Nov 10, 2021 at 11:58 PM Jagan Teki
> > > wrote:
> > > > On Wed, Nov 10, 2021 at 2:24 AM Tim Harvey
> > > >
Hi Jernej,
On 10/11/2021 20:20, Jernej Škrabec wrote:
> Hi Neil,
>
> sorry for late response.
>
> Dne petek, 29. oktober 2021 ob 15:59:47 CET je Neil Armstrong napisal(a):
>> The current ELD handling takes the internal connector ELD buffer and
>> shares it to the I2S and AHB sub-driver.
>>
>> Bu
Hi Jens.
Same issue at my side.
Have posted a patch at
https://lore.kernel.org/linux-mm/camzfgtup6dkt4owzlhl8whqnnxabfvw5c6aqoghzy3bbm_k...@mail.gmail.com/T/#m2189d135b9293de9b4a11362f0179c17b254d5ab
Will be great to hear back if it fixes things at your side too.
Thanks and Regards,
Ajay
On T
Hi,
Running -git as of a day or two ago on my laptop, and I've hit this resume
crash a few times:
OOM killer enabled.
Restarting tasks ... done.
thermal thermal_zone7: failed to read out thermal zone (-61)
xfs filesystem being remounted at
/run/systemd/unit-root/var/cache/private/fwupdmgr suppor
Hi,
I tested Linux mainline kernel 5.15 (aarch64) with enabled VC4 on RPi 4B. I
notice UI freezes a while (about 10 seconds) some times.
The kernel shows the error message during the time:
[drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [
On 11.11.21 10:20, Javier Martinez Canillas wrote:
> The efifb and simplefb drivers just render to a pre-allocated frame buffer
> and rely on the display hardware being initialized before the kernel boots.
>
> But if another driver already probed correctly and registered a fbdev, the
> generic dri
On 11.11.21 11:00, Daniel Vetter wrote:
> On Thu, Nov 11, 2021 at 10:58:14AM +0100, Thorsten Leemhuis wrote:
>> On 11.11.21 10:20, Javier Martinez Canillas wrote:
>>> The efifb and simplefb drivers just render to a pre-allocated frame buffer
>>> and rely on the display hardware being initialized be
On Wed, 10 Nov 2021 21:19:53 -0800 Joe Perches wrote:
> On Wed, 2021-11-10 at 17:39 -0800, Jakub Kicinski wrote:
> > On Wed, 10 Nov 2021 12:09:06 -0800 Srivatsa S. Bhat wrote:
> > > DRM DRIVER FOR VMWARE VIRTUAL GPU
> > > -M: "VMware Graphics"
> > > M: Zack Rusin
> > > +R: V
On 11/11/21 10:03 AM, Ajay Garg wrote:
> Hi Jens.
>
> Same issue at my side.
>
> Have posted a patch at
> https://lore.kernel.org/linux-mm/camzfgtup6dkt4owzlhl8whqnnxabfvw5c6aqoghzy3bbm_k...@mail.gmail.com/T/#m2189d135b9293de9b4a11362f0179c17b254d5ab
>
> Will be great to hear back if it fixes th
On Thu, 11 Nov 2021, Matt Roper wrote:
> This workaround is documented a bit strangely in the bspec; it's listed
> as an A0 workaround, but the description clarifies that the workaround
> is implicitly handled by the hardware and what the driver really needs
> to do is program a chicken bit to ree
Hello Pekka,
On 11/12/21 09:56, Pekka Paalanen wrote:
[snip]
>
> Hi,
>
> these ideas make sense to me, so FWIW,
>
> Acked-by: Pekka Paalanen
>
Thanks.
> There is one nitpick I'd like to ask about:
>
> +bool drm_get_modeset(void)
> +{
> + return !drm_nomodeset;
> +}
> +EXPORT_SYMBOL(drm_ge
Hi
Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas:
Hello Pekka,
On 11/12/21 09:56, Pekka Paalanen wrote:
[snip]
Hi,
these ideas make sense to me, so FWIW,
Acked-by: Pekka Paalanen
Thanks.
There is one nitpick I'd like to ask about:
+bool drm_get_modeset(void)
+{
+ return
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #18 from Lang Yu (lang...@amd.com) ---
Hi all,
I reproduced the issue. Thanks for Erhard F.'s work!
The problem is the pinned BO of last call to
amdgpu_display_crtc_page_flip_target() was not unpinned properly.
int amdgpu_display_
On Fri, 12 Nov 2021 11:09:13 +0100
Thomas Zimmermann wrote:
> Hi
>
> Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas:
> > Hello Pekka,
> >
> > On 11/12/21 09:56, Pekka Paalanen wrote:
> >
> > [snip]
> >
> >>
> >> Hi,
> >>
> >> these ideas make sense to me, so FWIW,
> >>
> >> Acked-by:
On 11/12/21 11:22, Pekka Paalanen wrote:
[snip]
>>>
As this is just returning bool without changing anything, the usual
word to use is "is". Since this function is also used at most once per
driver, which is rarely, it could have a long and descriptive name.
For exampl
On Fri, 12 Nov 2021, Pekka Paalanen wrote:
> On Fri, 12 Nov 2021 11:09:13 +0100
> Thomas Zimmermann wrote:
>
>> Hi
>>
>> Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas:
>> > Hello Pekka,
>> >
>> > On 11/12/21 09:56, Pekka Paalanen wrote:
>> >
>> > [snip]
>> >
>> >>
>> >> Hi,
>> >>
>>
On Fri, Nov 05, 2021 at 09:59:24AM +0100, Thierry Reding wrote:
> On Fri, Oct 08, 2021 at 10:23:34PM +0200, Thierry Reding wrote:
> > Hi Dave, Daniel,
> >
> > The following changes since commit c3dbfb9c49eef7d07904e5fd5e158dd6688bbab3:
> >
> > gpu: host1x: Plug potential memory leak (2021-09-16
On Tue, Nov 09, 2021 at 05:39:02PM +0300, Dmitry Osipenko wrote:
> 09.11.2021 17:17, Dmitry Osipenko пишет:
> > 09.11.2021 17:08, Dmitry Osipenko пишет:
> >>> +static void host1x_drm_dev_deinit(struct host1x_device *dev)
> >>> +{
> >>> + struct drm_device *drm = dev_get_drvdata(&dev->dev);
> >> And
MediaTek IOMMU block diagram always like below:
M4U
|
smi-common
|
-
| | ...
| |
larb1 larb2
| |
vdec venc
All the consumer connect with smi-larb, then connect with smi-common.
When the consumer works, it should
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need this property.
And IOMMU also know which larb this consumer conne
When the iommu master device enters of_iommu_xlate, the ops may be
NULL(iommu dev is defered), then it will initialize the fwspec here:
[] (dev_iommu_fwspec_set) from []
(iommu_fwspec_init+0xbc/0xd4)
[] (iommu_fwspec_init) from []
(of_iommu_xlate+0x7c/0x12c)
[] (of_iommu_xlate) from []
(of_iommu_c
The platform device is created at:
of_platform_default_populate_init: arch_initcall_sync
->of_platform_populate
->of_platform_device_create_pdata
When entering our probe, all the devices should be already created.
if it is null, means NODEV. Currently we don't get the fail case.
It's a
Prepare for adding device_link.
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is ready,
then all the iommu consumers always are after the smi driver.
Whe
On Fri, Nov 12, 2021 at 02:28:30PM +0530, Jagan Teki wrote:
> On Fri, Nov 12, 2021 at 2:12 PM Michael Tretter wrote:
> > On Thu, 11 Nov 2021 13:21:03 -0800, Tim Harvey wrote:
> > > On Thu, Nov 11, 2021 at 2:19 AM Jagan Teki
> > > wrote:
> > > > On Wed, Nov 10, 2021 at 11:58 PM Jagan Teki
> > > >
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should enab
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
After removing the larb_get operations, then mtk_jpeg_clk_init is
also unnecessary. Remove it too.
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Reviewed-
From: Yongqiang Niu
Prepare for smi cleaning up "mediatek,larb".
Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device whose nodes has
"iommus" property, then display could help pm_runtime_get for smi via
ovl or rdma device.
CC:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Chun-
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec device call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by:
Hi
Am 12.11.21 um 11:22 schrieb Pekka Paalanen:
On Fri, 12 Nov 2021 11:09:13 +0100
Thomas Zimmermann wrote:
Hi
Am 12.11.21 um 10:39 schrieb Javier Martinez Canillas:
Hello Pekka,
On 11/12/21 09:56, Pekka Paalanen wrote:
[snip]
Hi,
these ideas make sense to me, so FWIW,
Acked-by: P
After this patchset, mtk_vcodec_release_dec_pm has only one line.
then remove that function. Use pm_runtime_disable directly instead.
For symmetry, move the pm_runtime_enable out from
mtk_vcodec_init_dec_pm, then mtk_vcodec_init_dec_pm only operate for
the clocks, rename it from the _pm to _clk.
After this patchset, mtk_vcodec_release_enc_pm has only one line.
then remove that function, use pm_runtime_disable instead.
meanwhile, mtk_vcodec_init_enc_pm only operate for the clocks,
rename it from the _pm to _clk.
No functional change.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Krzysztof Kozlowski
Acked-b
After adding device_link between the IOMMU consumer and smi, the
mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
arch/arm/boot/dts/mt2701.dtsi | 2 --
arch/arm/boot/dts/mt7623n.dtsi | 5
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 6 --
2 fil
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #19 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Lang Yu from comment #18)
> Hi all,
>
> I reproduced the issue. Thanks for Erhard F.'s work!
>
> The problem is the pinned BO of last call to
> amdgpu_display_crtc_page_flip
On Tue, Nov 02, 2021 at 03:25:10PM -0700, Matt Roper wrote:
> Bspec: 54077,68173,54833
> Cc: Anusha Srivatsa
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 278 +++-
> drivers/gpu/drm/i915/i915_reg.h | 94 +--
> drivers/gpu/drm/
On 11/12/21 11:57, Thomas Zimmermann wrote:
[snip]
>>>
>>> This is what HW-specific drivers want to query in their init/probing
>>> code. The actual semantics of this decision is hidden from the driver.
>>> It's also easier to read than the other name IMHO
>>
>> Ok, but what is a "native driver"?
Hi
Am 12.11.21 um 12:20 schrieb Javier Martinez Canillas:
On 11/12/21 11:57, Thomas Zimmermann wrote:
[snip]
This is what HW-specific drivers want to query in their init/probing
code. The actual semantics of this decision is hidden from the driver.
It's also easier to read than the other nam
edid_read() was assumed to return 0 on success. After
7f16d0f3b8e2("drm/bridge: anx7625: Propagate errors from sp_tx_rst_aux()"),
the function can return >= 0 for successful case. Fix the g_edid_break
condition in sp_tx_edid_read().
Fixes: 7f16d0f3b8e2("drm/bridge: anx7625: Propagate errors from
On Fri, Nov 12, 2021 at 01:26:54AM +0100, Marijn Suijten wrote:
> The strings passed in DT may possibly cause out-of-bounds register
> accesses and should be validated before use.
>
> Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
> Signed-off-by: Marijn Suijten
>
This issue was not catched by CI, because of series of unfortunate events.
Before, CI has rebooted without module blocklist, and CI catched boot-time
dmesg correctly and marked it as 'ci@boot' test with failure if there was a
taint.
I've been doing changes to make blocklisting i915 possible and
On Fri, Nov 12, 2021 at 01:26:57AM +0100, Marijn Suijten wrote:
> When not specifying num-strings in the DT the default is used, but +1 is
> added to it which turns WLED3 into 4 and WLED4/5 into 5 strings instead
> of 3 and 4 respectively, causing out-of-bounds reads and register
> read/writes. Th
On Fri, 12 Nov 2021 12:20:14 +0100
Javier Martinez Canillas wrote:
> On 11/12/21 11:57, Thomas Zimmermann wrote:
>
> [snip]
>
> >>>
> >>> This is what HW-specific drivers want to query in their init/probing
> >>> code. The actual semantics of this decision is hidden from the driver.
> >>> It's
On Fri, Nov 12, 2021 at 01:26:58AM +0100, Marijn Suijten wrote:
> The length of qcom,enabled-strings as property array is enough to
> determine the number of strings to be enabled, without needing to set
> qcom,num-strings to override the default number of strings when less
> than the default (whic
On Fri, Nov 12, 2021 at 01:27:02AM +0100, Marijn Suijten wrote:
> The hardware is capable of controlling any non-contiguous sequence of
> LEDs specified in the DT using qcom,enabled-strings as u32
> array, and this also follows from the DT-bindings documentation. The
> numbers specified in this ar
On 2021-11-12 12:08:39, Daniel Thompson wrote:
> On Fri, Nov 12, 2021 at 01:26:57AM +0100, Marijn Suijten wrote:
> > When not specifying num-strings in the DT the default is used, but +1 is
> > added to it which turns WLED3 into 4 and WLED4/5 into 5 strings instead
> > of 3 and 4 respectively, caus
https://bugzilla.kernel.org/show_bug.cgi?id=214621
--- Comment #20 from Christian König (christian.koe...@amd.com) ---
Nice work Lang, question is now only how to fix it?
We probably need to assign this bug to Harry and Nicholas.
--
You may reply to this email to add a comment.
You are receivi
On 2021-11-12 12:12:38, Daniel Thompson wrote:
> On Fri, Nov 12, 2021 at 01:26:58AM +0100, Marijn Suijten wrote:
> > The length of qcom,enabled-strings as property array is enough to
> > determine the number of strings to be enabled, without needing to set
> > qcom,num-strings to override the defau
Hi guys,
Am 10.11.21 um 14:26 schrieb Daniel Vetter:
[SNIP]
stack depot, not stuff it into a string. stack depot is a lot more
efficient and capturing backtraces, since it de-dupes and hashes and all
you need is a pointer iirc. linux/stackdepot.h for interface, I think we
recently gained a few m
Hi Pekka,
On Thu, Nov 11, 2021 at 11:37 AM Pekka Paalanen wrote:
>
> On Thu, 11 Nov 2021 11:07:21 -0300
> Igor Torrente wrote:
>
> > Hi Pekka,
> >
> > On Thu, Nov 11, 2021 at 6:33 AM Pekka Paalanen wrote:
> > >
> > > On Wed, 10 Nov 2021 13:56:54 -0300
> > > Igor Torrente wrote:
> > >
> > > > O
On Fri, Nov 12, 2021 at 01:35:01PM +0100, Marijn Suijten wrote:
> On 2021-11-12 12:08:39, Daniel Thompson wrote:
> > On Fri, Nov 12, 2021 at 01:26:57AM +0100, Marijn Suijten wrote:
> > > + if (string_len > 0) {
> > > + dev_warn(dev, "qcom,num-strings and
> > > qcom,enabled-
On Fri, Nov 12, 2021 at 01:45:22PM +0100, Marijn Suijten wrote:
> On 2021-11-12 12:12:38, Daniel Thompson wrote:
> > On Fri, Nov 12, 2021 at 01:26:58AM +0100, Marijn Suijten wrote:
> > > The length of qcom,enabled-strings as property array is enough to
> > > determine the number of strings to be en
On 20/10/2021 14:39, Neil Armstrong wrote:
> This serie finnally reworks the drm/meson driver by extracting the encoders
> in their own file and moves to bridge-only callbacks.
>
> This permits passing the ATTACH_NO_CONNECTOR bridge attach flag and finally
> use the CVBS & HDMI display-connector d
There is a lot of historical baggage on this parameter. It is defined in
the vgacon driver as nomodeset, but its set function is called text_mode()
and the value queried with a function named vgacon_text_force().
All this implies that it's about forcing text mode for VGA, yet it is not
used in nei
This relationship was only for historical reasons and the nomodeset option
should be available even on platforms that don't enable CONFIG_VGA_CONSOLE.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Acked-by: Thomas Zimmermann
Acked-by: Jani Nikula
Acked-by: Pekka Paala
It is already handled by the console.h macro since a stub inline function
is defined for vgacon_text_force() if CONFIG_VGA_CONSOLE is not set.
There's no need to have ifdefery in the driver when calling the function.
Signed-off-by: Javier Martinez Canillas
Acked-by: Thomas Zimmermann
Acked-by:
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers that are making use of it.
Let's move the vgacon_text_force() fu
The nomodeset kernel command line parameter is not documented. Its name
is quite vague and is not intuitive what's the behaviour when it is set.
Document in kernel-parameters.txt what actually happens when nomodeset
is used. That way, users could know if they want to enable this option.
Signed-of
The nomodeset kernel parameter handler already prints a message that the
DRM drivers will be disabled, so there's no need for drivers to do that.
Suggested-by: Thomas Zimmermann
Signed-off-by: Javier Martinez Canillas
Acked-by: Thomas Zimmermann
Acked-by: Jani Nikula
Acked-by: Pekka Paalanen
The message printed when nomodeset is present in the kernel command line
makes it look as if the parameter must never be used and it's a bad idea.
But there are valid reasons to use this parameter and the message should
not imply otherwise. Change the text to be more accurate and restrained.
Sugg
On 12/11/2021 00:53, Lu Baolu wrote:
On 11/11/21 11:06 PM, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi Tvrtk
On Fri, 12 Nov 2021, Javier Martinez Canillas wrote:
> This relationship was only for historical reasons and the nomodeset option
> should be available even on platforms that don't enable CONFIG_VGA_CONSOLE.
>
> Suggested-by: Thomas Zimmermann
> Signed-off-by: Javier Martinez Canillas
> Acked-by
On Wed, 15 Sep 2021, Colin King wrote:
> From: Colin Ian King
>
> Don't populate the read-only array states on the stack but instead it
> static. Also makes the object code smaller.
Finally pushed, sorry for the delay.
BR,
Jani.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/
On 12/11/2021 00:58, Lu Baolu wrote:
On 11/11/21 11:18 PM, Tvrtko Ursulin wrote:
On 10/11/2021 14:37, Robin Murphy wrote:
On 2021-11-10 14:11, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2
On 11/11/2021 16:49, Matthew Brost wrote:
On Mon, Nov 01, 2021 at 10:35:09AM +, Tvrtko Ursulin wrote:
On 27/10/2021 21:10, Matthew Brost wrote:
On Wed, Oct 27, 2021 at 01:04:49PM -0700, John Harrison wrote:
On 10/27/2021 12:17, Matthew Brost wrote:
On Tue, Oct 26, 2021 at 02:58:00PM -0
Fix a number of compiler warnings in the AGP drivers. No functional
changes.
Thomas Zimmermann (7):
agp: Remove trailing whitespaces
agp: Include "compat_ioctl.h" where necessary
agp: Documentation fixes
agp/ati: Return error from ati_create_page_map()
agp/nvidia: Ignore value returned b
Trivial coding-style fix.
Signed-off-by: Thomas Zimmermann
---
drivers/char/agp/ati-agp.c| 2 +-
drivers/char/agp/frontend.c | 2 +-
drivers/char/agp/sworks-agp.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/agp/ati-agp.c b/drivers/char/agp/ati-agp.c
Fix the compiler warning
drivers/char/agp/via-agp.c: In function 'via_configure_agp3':
drivers/char/agp/via-agp.c:131:35: warning: variable 'current_size' set but
not used [-Wunused-but-set-variable]
131 | struct aper_size_info_16 *current_size;
by removing the variable.
Signed-
Fix compiler warnings like
drivers/char/agp/frontend.c:46:20: warning: no previous prototype for
'agp_find_mem_by_key' [-Wmissing-prototypes]
46 | struct agp_memory *agp_find_mem_by_key(int key)
by including the compat_ioctl.h in the source file.
Signed-off-by: Thomas Zimmermann
---
dri
Fix the compiler warning
drivers/char/agp/nvidia-agp.c: In function 'nvidia_tlbflush':
drivers/char/agp/nvidia-agp.c:264:22: warning: variable 'temp' set but not
used [-Wunused-but-set-variable]
264 | u32 wbc_reg, temp;
by removing the unused variable. The affected readl() is onl
Fix the compiler warning
drivers/char/agp/sworks-agp.c: In function 'serverworks_configure':
drivers/char/agp/sworks-agp.c:265:37: warning: variable 'current_size' set
but not used [-Wunused-but-set-variable]
265 | struct aper_size_info_lvl2 *current_size;
by removing the variabl
Fix compiler warnings
drivers/char/agp/backend.c:68: warning: Function parameter or member 'pdev'
not described in 'agp_backend_acquire'
drivers/char/agp/backend.c:93: warning: Function parameter or member 'bridge'
not described in 'agp_backend_release'
by adding the necessary documentation
Fix the compiler warning
drivers/char/agp/ati-agp.c: In function 'ati_create_page_map':
drivers/char/agp/ati-agp.c:58:16: warning: variable 'err' set but not used
[-Wunused-but-set-variable]
58 | int i, err = 0;
by returing the error to the caller.
Signed-off-by: Thomas Zimmerma
On 2021-11-12 13:23:36, Daniel Thompson wrote:
> On Fri, Nov 12, 2021 at 01:45:22PM +0100, Marijn Suijten wrote:
> > On 2021-11-12 12:12:38, Daniel Thompson wrote:
> > > On Fri, Nov 12, 2021 at 01:26:58AM +0100, Marijn Suijten wrote:
> > > > The length of qcom,enabled-strings as property array is e
On 2021-11-12 13:47, Christian König wrote:
>
> Anyway this unfortunately turned out to be work for Harray and Nicholas. In
> detail it's about this bug report here:
> https://bugzilla.kernel.org/show_bug.cgi?id=214621
>
> Lang was able to reproduce the issue and narrow it down to the pin in
>
On 2021-11-12 15:29, Michel Dänzer wrote:
> On 2021-11-12 13:47, Christian König wrote:
>>
>> Anyway this unfortunately turned out to be work for Harray and Nicholas. In
>> detail it's about this bug report here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=214621
>>
>> Lang was able to reprodu
12.11.2021 13:52, Thierry Reding пишет:
> On Tue, Nov 09, 2021 at 05:39:02PM +0300, Dmitry Osipenko wrote:
>> 09.11.2021 17:17, Dmitry Osipenko пишет:
>>> 09.11.2021 17:08, Dmitry Osipenko пишет:
> +static void host1x_drm_dev_deinit(struct host1x_device *dev)
> +{
> + struct drm_device
On Thu, Nov 11, 2021 at 08:57:26AM -0600, Rob Herring wrote:
> On Wed, 10 Nov 2021 20:43:28 +0100, H. Nikolaus Schaller wrote:
> > From: Sam Ravnborg
> >
> > Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
> > Based on .txt binding from Zubair Lutfullah Kakakhel
> >
> > We also a
On Thu, Nov 11, 2021 at 04:10:41PM -0500, Harry Wentland wrote:
>
>
> On 2021-11-11 15:42, Shankar, Uma wrote:
> >
> >
> >> -Original Message-
> >> From: Ville Syrjälä
> >> Sent: Thursday, November 11, 2021 10:13 PM
> >> To: Harry Wentland
> >> Cc: Shankar, Uma ; intel-...@lists.freed
Am 12.11.21 um 15:30 schrieb Michel Dänzer:
On 2021-11-12 15:29, Michel Dänzer wrote:
On 2021-11-12 13:47, Christian König wrote:
Anyway this unfortunately turned out to be work for Harray and Nicholas. In
detail it's about this bug report here:
https://bugzilla.kernel.org/show_bug.cgi?id=
Ping for review.
Am 08.07.21 um 19:51 schrieb Thomas Zimmermann:
The GEM CMA helpers allocate non-coherent (i.e., cached) backing storage
with dma_alloc_noncoherent(), but release it with dma_free_wc(). Fix this
with a call to dma_free_noncoherent(). Writecombining storage is still
released with
On Fri, Nov 12, 2021 at 03:19:17PM +0100, Marijn Suijten wrote:
> On 2021-11-12 13:23:36, Daniel Thompson wrote:
> > On Fri, Nov 12, 2021 at 01:45:22PM +0100, Marijn Suijten wrote:
> > > On 2021-11-12 12:12:38, Daniel Thompson wrote:
> > > > On Fri, Nov 12, 2021 at 01:26:58AM +0100, Marijn Suijten
Hi Thomas,
I never received the original patch and I can't find it online either?
Anyway:
Acked-by: Paul Cercueil
Cheers,
-Paul
Le ven., nov. 12 2021 at 16:05:47 +0100, Thomas Zimmermann
a écrit :
Ping for review.
Am 08.07.21 um 19:51 schrieb Thomas Zimmermann:
The GEM CMA helpers alloca
From: Maarten Lankhorst
This allows us to finally get rid of all the assumptions that vma->obj
is NULL.
Changes since v1:
- Ensure the mock_ring vma is pinned to prevent a fault.
- Pin it high to avoid failure in evict_for_vma selftest.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Aul
From: Maarten Lankhorst
vma->obj and vma->resv are now never NULL, and some checks can be removed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c |
From: Maarten Lankhorst
We currently have to special case vma->obj being NULL because
of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon
be able to remove a few checks. As the object only exists as
a fake object pointing to ggtt, we have no backing storage,
so no real object is created
In intel_context_do_pin_ww, when calling into the pre_pin hook(which is
passed the ww context) it could in theory return -EDEADLK(which is very
likely with debug kernels), once we start adding more ww locking in there,
like in the next patch. If so then we need to be mindful of having to
restart th
From: Maarten Lankhorst
Lets be thorough here. Users of the TTM backend would likely expect this
behaviour.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/g
From: Maarten Lankhorst
It's just an alias to vma->obj->base.resv, no need to duplicate it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915_vma.c
Hi Paul
Am 12.11.21 um 16:26 schrieb Paul Cercueil:
Hi Thomas,
I never received the original patch and I can't find it online either?
It was posted a while ago [1] and got lost. I remember that you had a
problem with your email setup. Maybe that's why you didn't see it.
Anyway:
Acked-by:
On 11/11/2021 13:06, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Trying to capture uninitialised engines when we wedged on init ends in
tears. Skip that together with uC capture, since failure to initialise the
latter can actually be one of the reasons for wedging on init.
v2:
* Use i915_disa
On 11/12/21 6:49 AM, Vincent Whitchurch wrote:
> On Thu, Nov 11, 2021 at 03:02:04PM -0700, Jim Cromie wrote:
>> Sean Paul proposed, in:
>> https://urldefense.com/v3/__https://patchwork.freedesktop.org/series/78133/__;!!GjvTz_vk!HcKnMRByYkIdyF1apqQjlN5aBIomzJR1an3YWXM6KXs0EftVMQdrewRA8Dki4A$
>>
>>
Pre-HSW platforms don't use the gt SSEU structures; this means that
calling intel_sseu_get_subslices() on slice 0 for these platforms will
trip a GEM_BUG_ON(slice >= sseu->max_slices) warning.
Let's move the DSS lookup for a DG2 workaround into a helper function
that will only get called after we'
On Thu, Nov 11, 2021 at 12:36:47PM +0100, Christian König wrote:
> Am 01.11.21 um 10:41 schrieb Tvrtko Ursulin:
> >
> > On 28/10/2021 16:30, Daniel Vetter wrote:
> > > On Thu, Oct 28, 2021 at 10:41:38AM +0200, Christian König wrote:
> > > > Am 21.10.21 um 13:13 schrieb Tvrtko Ursulin:
> > > > >
>
On Thu, 11 Nov 2021 23:10:16 -0800, Vinay Belgaumkar wrote:
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> index 4e1d3cd29164..22c1c12369f2 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/
1 - 100 of 127 matches
Mail list logo
