On 7/15/22 09:50, Christian König wrote:
> Am 15.07.22 um 02:52 schrieb Dmitry Osipenko:
>> Intel i915 GPU driver uses wait-wound mutex to lock multiple GEMs on the
>> attachment to the i915 dma-buf. In order to let all drivers utilize
>> shared
>> wait-wound context during attachment in a general
On 7/15/22 02:03, Daniel Latypov wrote:
> On Thu, Jul 14, 2022 at 4:51 PM Guenter Roeck wrote:
>>
>> On Fri, Jul 08, 2022 at 05:30:47PM -0300, Maíra Canal wrote:
>>> Considering the current adoption of the KUnit framework, convert the
>>> DRM format selftest to the KUnit API.
>>>
>>> Tested-by: Da
Am 15.07.22 um 02:52 schrieb Dmitry Osipenko:
Add _unlocked postfix to the dma-buf API function names in a preparation
to move all non-dynamic dma-buf users over to the dynamic locking
specification. This patch only renames API functions, preparing drivers
to the common locking convention. Later
Am 15.07.22 um 02:52 schrieb Dmitry Osipenko:
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update QXL and i915
drivers to use the locked functio
On 7/14/2022 9:13 PM, André Almeida wrote:
Às 12:06 de 14/07/22, Sebin Sebastian escreveu:
On Tue, Jul 12, 2022 at 12:14:27PM -0300, André Almeida wrote:
Hi Sebin,
Às 10:29 de 10/07/22, Sebin Sebastian escreveu:
Fix two coverity warning's double free and and an uninitialized pointer
read. Bo
memleak will happend that reload module due to ignore kfree when release
topology
Signed-off-by: ZhiJie.zhang
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
From: Chris Wilson
On Haswell, in particular, we see an issue where resets fails because
the engine resumes from an incorrect RING_HEAD. Since the RING_HEAD
doesn't point to the remaining requests to re-run, but may instead point
into the uninitialised portion of the ring, the GPU may be then fed
Il 15/07/22 08:49, Mingjia Zhang ha scritto:
In order to reduce decoder latency, enable VP9 inner racing mode.
Send lat trans buffer information to core when trigger lat to work,
need not to wait until lat decode done.
Signed-off-by: mingjia zhang
---
CTS/GTS test pass
CTS/GTS passing is a go
On 7/5/22 12:02, Javier Martinez Canillas wrote:
> Hello,
>
> Peter Robinson reported me a kernel bug in one of his aarch64 test boards
> and even though I was not able to reproduce it, I think that figured out
> what the problem was. It seems the cause is that a DRM driver doesn't set
> some of t
On Tue, 05 Jul 2022 14:52:01 PDT (-0700), m...@conchuod.ie wrote:
From: Conor Dooley
Hey all,
This series should rid us of dtbs_check errors for the RISC-V Canaan k210
based boards. To make keeping it that way a little easier, I changed the
Canaan devicetree Makefile so that it would build all
Hi Geert,
somehow this series slipped into my spam folder ... only saw it now.
Am 12.07.2022 um 03:50 schrieb Geert Uytterhoeven:
Hi all,
This patch series contains miscellaneous fixes and cleanups for the
Atari frame buffer device driver, which were identified while working on
the Ata
[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]
Hi, this is your Linux kernel regression tracker.
On 15.07.22 01:08, Dave Airlie wrote:
Hi,
Sorry, my email client removed every tab. I will send the v2 in a new
thread.
Thanks.
Matthieu
On Thu, Jul 14 2022 at 11:23:10 AM -0300, André Almeida
wrote:
Hi Matthieu,
Thanks for your patch.
Às 11:58 de 06/07/22, Matthieu CHARETTE escreveu:
Loading an EDID using drm.edid_firmwar
Loading an EDID using drm.edid_firmware parameter makes resume to fail
after firmware cache is being cleaned. This is because edid_load() use a
temporary device to request the firmware. This cause the EDID firmware
not to be cached from suspend. And, requesting the EDID firmware return
an error dur
On 7/15/22 10:19, Christian König wrote:
>> -struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment
>> *attach,
>> - enum dma_data_direction direction)
>> +struct sg_table *
>> +dma_buf_map_attachment_unlocked(struct dma_buf_attachment *attach,
>> + enum
Hi,
On Fri, Jul 15, 2022 at 05:22:56PM +0800, Liu Zixian wrote:
> On failure, these functions return errno, not NULL.
They don't return an errno but an error pointer
Maxime
On 15.07.2022 10:26, Mauro Carvalho Chehab wrote:
From: Chris Wilson
On Haswell, in particular, we see an issue where resets fails because
the engine resumes from an incorrect RING_HEAD. Since the RING_HEAD
doesn't point to the remaining requests to re-run, but may instead point
into the uninit
Hi all,
After merging the bitmap tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/gt/intel_sseu.c: In function 'intel_sseu_print_ss_info':
drivers/gpu/drm/i915/gt/intel_sseu.c:868:52: error: format '%u' expects
argument of type 'unsigned int', but argum
Am 15.07.22 um 11:31 schrieb Dmitry Osipenko:
On 7/15/22 10:19, Christian König wrote:
-struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment
*attach,
- enum dma_data_direction direction)
+struct sg_table *
+dma_buf_map_attachment_unlocked(struct dma_buf_attachment
On Thu, Jul 14, 2022 at 12:25:31PM +0100, Lee Jones wrote:
> Going forward, I'll be using my kernel.org for upstream work.
>
> Cc: Daniel Thompson
Acked-by: Daniel Thompson
> Cc: Jingoo Han
> Cc: Rob Herring
> Cc: Krzysztof Kozlowski
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-l...@vg
I've stumbled over this while reviewing patches for DMA-buf and it looks
like we completely messed the locking up here.
In general most TTM function should only be called while holding the
appropriate BO resv lock. Without this we could break the internal
buffer object state here.
Only compile te
Let's make sure nobody is calling those functions without holding the
appropriate locks.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 15309
From: ChiaEn Wu
This patch series add MediaTek MT6370 PMIC support. The MT6370 is a
highly-integrated smart power management IC, which includes a single
cell Li-Ion/Li-Polymer switching battery charger, a USB
Type-C & Power Delivery (PD) controller, dual Flash LED current sources,
a RGB LED drive
From: ChiYuan Huang
Add MediaTek MT6370 TCPC binding documentation.
Signed-off-by: ChiYuan Huang
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/usb/mediatek,mt6370-tcpc.yaml | 36 ++
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/
From: ChiaEn Wu
Add MediaTek MT6370 Charger binding documentation.
Signed-off-by: ChiaEn Wu
Reviewed-by: Krzysztof Kozlowski
---
.../power/supply/mediatek,mt6370-charger.yaml | 88 ++
1 file changed, 88 insertions(+)
create mode 100644
Documentation/devicetree/bindi
From: ChiYuan Huang
Add MediaTek MT6370 current sink type LED indicator binding documentation.
Signed-off-by: ChiYuan Huang
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/leds/mediatek,mt6370-indicator.yaml | 77 ++
1 file changed, 77 insertions(+)
create mode 100644
From: Alice Chen
Add MediaTek MT6370 flashlight binding documentation.
Signed-off-by: Alice Chen
Reviewed-by: Krzysztof Kozlowski
---
.../bindings/leds/mediatek,mt6370-flashlight.yaml | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devicetree/
From: ChiYuan Huang
Add MT6370 backlight binding documentation.
Signed-off-by: ChiYuan Huang
Reviewed-by: Rob Herring
---
.../leds/backlight/mediatek,mt6370-backlight.yaml | 92 ++
1 file changed, 92 insertions(+)
create mode 100644
Documentation/devicetree/bindings/led
From: ChiYuan Huang
Add MediaTek MT6370 binding documentation.
Signed-off-by: ChiYuan Huang
Reviewed-by: Krzysztof Kozlowski
---
.../devicetree/bindings/mfd/mediatek,mt6370.yaml | 280 +
include/dt-bindings/iio/adc/mediatek,mt6370_adc.h | 18 ++
2 files changed, 298 in
From: ChiYuan Huang
This adds support for the MediaTek MT6370 SubPMIC. MediaTek MT6370 is a
SubPMIC consisting of a single cell battery charger with ADC monitoring,
RGB LEDs, dual channel flashlight, WLED backlight driver, display bias
voltage supply, one general purpose LDO, and the USB Type-C &
From: ChiYuan Huang
The MT6370 is a highly-integrated smart power management IC, which
includes a single cell Li-Ion/Li-Polymer switching battery charger,
a USB Type-C & Power Delivery (PD) controller, dual Flash LED current
sources, a RGB LED driver, a backlight WLED driver, a display bias
drive
From: ChiaEn Wu
MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
driver, display bias voltage supply, one general purpose LDO, and the
USB Type-C & PD controller complies with the latest USB Type-C and
From: ChiaEn Wu
MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
driver, display bias voltage supply, one general purpose LDO, and the
USB Type-C & PD controller complies with the latest USB Type-C and
From: ChiYuan Huang
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual
Flash LED current sources, a RGB LED driver, a backlight WLED driver,
a display b
From: Alice Chen
The MediaTek MT6370 is a highly-integrated smart power management IC,
whichincludes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual Flash
LED current sources, a RGB LED driver, a backlight WLED driver,
a display bias
From: ChiaEn Wu
MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
driver, display bias voltage supply, one general purpose LDO, and the
USB Type-C & PD controller complies with the latest USB Type-C and
On 7/15/22 14:15, Christian König wrote:
> I've stumbled over this while reviewing patches for DMA-buf and it looks
> like we completely messed the locking up here.
>
> In general most TTM function should only be called while holding the
> appropriate BO resv lock. Without this we could break the
Am 15.07.22 um 13:31 schrieb Dmitry Osipenko:
On 7/15/22 14:15, Christian König wrote:
I've stumbled over this while reviewing patches for DMA-buf and it looks
like we completely messed the locking up here.
In general most TTM function should only be called while holding the
appropriate BO resv
On 7/15/22 03:59, Javier Martinez Canillas wrote:
> On 7/15/22 02:03, Daniel Latypov wrote:
>> On Thu, Jul 14, 2022 at 4:51 PM Guenter Roeck wrote:
>>>
>>> On Fri, Jul 08, 2022 at 05:30:47PM -0300, Maíra Canal wrote:
Considering the current adoption of the KUnit framework, convert the
DR
Hi
Am 11.07.22 um 13:01 schrieb Javier Martinez Canillas:
On 7/7/22 17:39, Thomas Zimmermann wrote:
Convert fbdev drivers from fbdev's remove_conflicting_framebuffers() to
the framework-independent aperture_remove_conflicting_devices(). Calling
this function will also remove conflicting DRM dri
Hi
Am 11.07.22 um 13:13 schrieb Javier Martinez Canillas:
On 7/7/22 17:39, Thomas Zimmermann wrote:
Remove firmware devices on the PCI bus, by calling
aperture_remove_conflicting_pci_devices() in the probe function of
each related fbdev driver. iSo far, most of these drivers did not
remove conf
Hello Thomas,
On 7/15/22 13:48, Thomas Zimmermann wrote:
[...]
>>> +
>>> + return aperture_remove_conflicting_devices(base, size, primary,
>>> "sm750_fb1");
>>
>> Do you know why this can't just use
>> aperture_remove_conflicting_pci_devices() ?
>
> I simply don't want change too much at on
Hi
Am 11.07.22 um 13:29 schrieb Javier Martinez Canillas:
On 7/7/22 17:39, Thomas Zimmermann wrote:
When registering a generic framebuffer, automatically acquire ownership
of the framebuffer's I/O range. The device will now be handled by the
aperture helpers. Fbdev-based conflict handling is no
Hi Daniel,
On 7/12/22 22:13, Daniel Dadap wrote:
> Thanks, Hans:
>
> On 7/12/22 14:38, Hans de Goede wrote:
>> On some new laptop designs a new Nvidia specific WMI interface is present
>> which gives info about panel brightness control and may allow controlling
>> the brightness through this inte
Hi,
On 7/12/22 22:24, Daniel Dadap wrote:
> I'll ask around to see if there's some DMI property we can match in order to
> detect whether a system is expected to use the EC backlight driver: if so,
> maybe we can avoid the WMI interactions in patch 16/29 of this series.
> Although I suppose eve
45 matches
Mail list logo
