If devm_drm_of_get_bridge() can't find the connected bridge, it returns an
ERR_PTR(-EPROBE_DEFER) to indicate that the probe should be deferred.
But this path also prints an error message, which pollutes the kernel log
since is printed on every probe deferral, i.e:
$ dmesg | grep "failed to cre
Il 22/07/22 08:43, mingjia.zh...@mediatek.com ha scritto:
Hi Angelo,
Thanks for your reply and useful comments.
In addition to running cts/gts test, I ran the fluster test with
GStreamer locally. The test result is "Ran 240/303 tests successfully"
Just an advice: if you want to speed up the
This series is the DNN image processing accelerator driver for Toshiba's ARM
SoC, Visconti[0].
This provides DT binding documentation, device driver, MAINTAINER files and
documents.
Best regards,
Yuji
[0]:
https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-proces
This commit adds the Device Tree binding documentation that allows to describe
the DNN image processing accelerator found in Toshiba Visconti SoCs.
Signed-off-by: Yuji Ishikawa
Reviewed-by: Nobuhiro Iwamatsu
---
.../soc/visconti/toshiba,visconti-dnn.yaml| 54 +++
1 file chan
This commit adds common definitions shared among image processing accelerator
drivers
for Toshiba Visconti SoCs.
Signed-off-by: Yuji Ishikawa
Reviewed-by: Nobuhiro Iwamatsu
---
v1 -> v2:
- applied checkpatch.pl --strict
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile
Add support to DNN image processing accelerator on Toshiba Visconti ARM SoCs.
The accelerator is applicable to DNN inference tasks.
Signed-off-by: Yuji Ishikawa
Reviewed-by: Nobuhiro Iwamatsu
---
v1 -> v2:
- applied checkpatch.pl --strict
- removed unused code
---
drivers/soc/visconti/Kconf
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index dd36acc87..a2e2bd719 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2796,12 +2796,14 @@ F:
Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
F: Documentation/devicetree/
Signed-off-by: Yuji Ishikawa
---
v1 -> v2:
- newly added documents
---
Documentation/driver-api/visconti/common.rst | 115 ++
Documentation/driver-api/visconti/dnn.rst| 394 +++
2 files changed, 509 insertions(+)
create mode 100644 Documentation/driver-api/visconti/comm
On 22/07/2022 09:47, Javier Martinez Canillas wrote:
If devm_drm_of_get_bridge() can't find the connected bridge, it returns an
ERR_PTR(-EPROBE_DEFER) to indicate that the probe should be deferred.
But this path also prints an error message, which pollutes the kernel log
since is printed on ever
On 21/07/2022 18:43, Robert Beckett wrote:
Calling swiotlb functions directly is nowadays considered harmful. See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer
On 21/07/2022 18:43, Robert Beckett wrote:
Calling swiotlb functions directly is nowadays considered harmful. See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer
On Mon, Jul 11, 2022 at 09:52:02AM +0200, Johan Hovold wrote:
> Add an eDP panel entry for AUO B133UAN02.1.
>
> Due to lack of documentation, use the delay_200_500_e50 timings like
> some other AUO entries for now.
>
> Signed-off-by: Johan Hovold
Any comments to this one?
It looks like it hasn
On 22/07/2022 10:58, Christoph Hellwig wrote:
On Fri, Jul 22, 2022 at 10:45:54AM +0100, Tvrtko Ursulin wrote:
- unsigned int size = swiotlb_max_segment();
-
- if (size == 0)
- size = UINT_MAX;
On a more detailed look, there was a CI failure which makes me think thi
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
---
v6
- Add 'reg' property of led of multi-led to prevent checking error.
---
.../bindings/leds/mediatek,mt6370-indicator.yaml | 81
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 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: 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,
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
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 Fri, 8 Jul 2022 at 21:32, Maíra Canal wrote:
>
> From: Arthur Grillo
>
> Considering the current adoption of the KUnit framework, convert the
> DRM mm selftest to the KUnit API.
Is there a plan to convert the corresponding selftest IGT that was
responsible for running this (also drm_buddy) to
Il 22/07/22 12:24, ChiaEn Wu ha scritto:
From: Alice Chen
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 driv
Il 22/07/22 12:24, ChiaEn Wu ha scritto:
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 d
On 7/22/22 07:35, Matthew Auld wrote:
> On Fri, 8 Jul 2022 at 21:32, Maíra Canal wrote:
>>
>> From: Arthur Grillo
>>
>> Considering the current adoption of the KUnit framework, convert the
>> DRM mm selftest to the KUnit API.
>
> Is there a plan to convert the corresponding selftest IGT that was
Hi,
On 7/1/22 12:02, Dmitry Osipenko wrote:
> This patchset fixes two problems in the common GEM code. First fixed problem
> is the bogus lockdep splat that complicates debugging of DRM drivers. Second
> problem is the inconsistency in behaviour and improper handling of mapping
> the imported GEMs
Hi Mauro,
On Thu, Jul 14, 2022 at 01:06:06PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Check if the device is powered down prior to any engine activity,
> as, on such cases, all the TLBs were already invalidated, so an
> explicit TLB invalidation is not needed, thus reducing t
Hi Mauro and Chris,
On Thu, Jul 14, 2022 at 01:06:08PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Ensure that the TLB of the OA unit is also invalidated
> on gen12 HW, as just invalidating the TLB of an engine is not
> enough.
>
> Cc: sta...@vger.kernel.org
> Fixes: 7938d61591
Hi Mauro,
On Thu, Jul 14, 2022 at 01:06:09PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Don't flush TLBs when the buffer is only used in the GGTT under full
> control of the kernel, as there's no risk of concurrent access
> and stale access from prefetch.
>
> We only need to i
Hi Mauro,
On Thu, Jul 14, 2022 at 01:06:10PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Skip all further TLB invalidations once the device is wedged and
> had been reset, as, on such cases, it can no longer process instructions
> on the GPU and the user no longer has access to
Hi Mauro,
On Thu, Jul 14, 2022 at 01:06:13PM +0100, Mauro Carvalho Chehab wrote:
> From: Chris Wilson
>
> Prepare for supporting more TLB invalidation scenarios by moving
> the current MMIO invalidation to its own file.
>
> Signed-off-by: Chris Wilson
> Cc: Fei Yang
> Signed-off-by: Mauro Car
Komeda driver relies on the generic DRM atomic helper functions to handle
commits. It only implements an atomic_commit_tail hook for the
mode_config_helper_funcs and even that one is pretty close to the generic
implementation with the exception of additional dma_fence signalling.
What the generic
Hi Jani, Ville, Arun,
This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are different
issues.
Ive also dropped shutdown path, as it has slightly different requirements
i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler
called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst.
Since dp_mst is suspended after irq handler uninstall, a cleaner approach
is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk
use-after-free.
I
HPD event after fbdev unregistration can cause registration of deferred
fbdev which will not be unregistered later, causing use-after-free.
To avoid it HPD handling should be suspended before fbdev unregistration.
It should fix following GPF:
[272.634530] general protection fault, probably for non
In case of deferred FB setup core can try to create new
framebuffer. Disallow it if hpd_suspended flag is set.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drive
HPD events during driver removal can be generated by hardware and
software frameworks - drm_dp_mst, the former we can avoid by disabling
interrupts, the latter can be triggered by any drm_dp_mst transaction,
and this is too late. Introducing suspended flag allows to solve this
chicken-egg problem.
On 22.07.2022 09:47, Javier Martinez Canillas wrote:
If devm_drm_of_get_bridge() can't find the connected bridge, it returns an
ERR_PTR(-EPROBE_DEFER) to indicate that the probe should be deferred.
But this path also prints an error message, which pollutes the kernel log
since is printed on e
Yuji Ishikawa writes:
No changelog?
> Signed-off-by: Yuji Ishikawa
> ---
> v1 -> v2:
> - newly added documents
> ---
> Documentation/driver-api/visconti/common.rst | 115 ++
> Documentation/driver-api/visconti/dnn.rst| 394 +++
> 2 files changed, 509 insertions(+)
>
Hi,
On Fri, Jul 22, 2022 at 12:48 AM Javier Martinez Canillas
wrote:
>
> If devm_drm_of_get_bridge() can't find the connected bridge, it returns an
> ERR_PTR(-EPROBE_DEFER) to indicate that the probe should be deferred.
>
> But this path also prints an error message, which pollutes the kernel log
On 7/22/22 03:24, ChiaEn Wu wrote:
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,
In dss_init_ports() and __dss_uninit_ports(), we should call
of_node_put() for the reference returned by of_graph_get_port_by_id()
in fail path or when it is not used anymore.
Fixes: 09bffa6e5192 ("drm: omap: use common OF graph helpers")
Signed-off-by: Liang He
---
drivers/gpu/drm/omapdrm/dss/d
On 14/07/2022 09:45, Thomas Zimmermann wrote:
Hi
Am 08.07.22 um 11:30 schrieb Arunpravin Paneer Selvam:
This reverts commit 708d19d9f362766147cab79eccae60912c6d3068.
This commit is only present in drm-misc-next. Should the revert be
cherry-picked into drm-misc-next-fixes?
Seemed like an
Calling swiotlb functions directly is nowadays considered harmful. See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer consider max_segment
only if CONFIG_SWIOTLB is
On 22/07/2022 16:03, Christoph Hellwig wrote:
+ return max_t(size_t, UINT_MAX, dma_max_mapping_size(dev));
Shouldn't this be a min?
eugh! yes. Stand by for v3
Calling swiotlb functions directly is nowadays considered harmful. See
https://lore.kernel.org/intel-gfx/20220711082614.ga29...@lst.de/
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer consider max_segment
only if CONFIG_SWIOTLB is
On Thu, Jul 21, 2022 at 9:04 AM Akhil P Oommen wrote:
>
> On 7/20/2022 11:34 AM, Akhil P Oommen wrote:
> > On 7/19/2022 3:26 PM, Rajendra Nayak wrote:
> >>
> >>
> >> On 7/19/2022 12:49 PM, Stephen Boyd wrote:
> >>> Quoting Akhil P Oommen (2022-07-18 23:37:16)
> On 7/19/2022 11:19 AM, Stephen
On 20.07.2022 17:52, Jagan Teki wrote:
> Host transfer() in DSI master will invoke only when the DSI commands
> are sent from DSI devices like DSI Panel or DSI bridges and this
> host transfer wouldn't invoke for I2C-based-DSI bridge drivers.
>
> Handling DSI host initialization in transfer calls m
Hi Tvrtko,
scratching my head what exactly is going on here.
I've build tested drm-tip a couple of test in the last week and it
always worked flawlessly.
It looks like that some conflict resolution is sometimes not applied
correctly, but I have no idea why.
Regards,
Christian.
Am 22.07.22
Hi Jagan and Marek.
On Fri, 22 Jul 2022 at 16:35, Marek Szyprowski wrote:
>
> On 20.07.2022 17:52, Jagan Teki wrote:
> > Host transfer() in DSI master will invoke only when the DSI commands
> > are sent from DSI devices like DSI Panel or DSI bridges and this
> > host transfer wouldn't invoke for
On Fri, Jul 22, 2022 at 08:04:51AM -0300, Maíra Canal wrote:
> On 7/22/22 07:35, Matthew Auld wrote:
> > On Fri, 8 Jul 2022 at 21:32, Maíra Canal wrote:
> >>
> >> From: Arthur Grillo
> >>
> >> Considering the current adoption of the KUnit framework, convert the
> >> DRM mm selftest to the KUnit A
+ sankeerth
Hi Doug
On 7/21/2022 3:23 PM, Douglas Anderson wrote:
The Sharp LQ140M1JW46 panel is on the Qualcomm sc7280 CRD reference
board. This panel supports 144 Hz and 60 Hz. In the EDID, the 144 Hz
mode is listed first and thus is marked preferred. The EDID decode I
ran says:
First det
Hi,
On Fri, Jul 22, 2022 at 9:37 AM Abhinav Kumar wrote:
>
> + sankeerth
>
> Hi Doug
>
> On 7/21/2022 3:23 PM, Douglas Anderson wrote:
> > The Sharp LQ140M1JW46 panel is on the Qualcomm sc7280 CRD reference
> > board. This panel supports 144 Hz and 60 Hz. In the EDID, the 144 Hz
> > mode is liste
On 7/21/2022 2:08 AM, Akhil P Oommen wrote:
On 7/20/2022 11:36 PM, Rob Clark wrote:
On Tue, Jul 12, 2022 at 12:15 PM Akhil P Oommen
wrote:
On 7/12/2022 10:14 PM, Rob Clark wrote:
On Mon, Jul 11, 2022 at 10:05 PM Akhil P Oommen
wrote:
On 7/12/2022 4:52 AM, Doug Anderson wrote:
Hi,
On Fri,
On Fri, Jul 22, 2022 at 9:48 AM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Jul 22, 2022 at 9:37 AM Abhinav Kumar
> wrote:
> >
> > + sankeerth
> >
> > Hi Doug
> >
> > On 7/21/2022 3:23 PM, Douglas Anderson wrote:
> > > The Sharp LQ140M1JW46 panel is on the Qualcomm sc7280 CRD reference
> > > board.
On 21/07/2022 21:30, Rob Herring wrote:
> On Thu, Jul 21, 2022 at 05:31:50PM +0200, Krzysztof Kozlowski wrote:
>> The spi-cpha and spi-cpol properties are device specific and should be
>> accepted only if device really needs them. Explicitly list them in
>> device bindings in preparation of their
Applied. Thanks!
Alex
On Thu, Jul 21, 2022 at 3:26 AM Slark Xiao wrote:
>
> Replace 'the the' with 'the' in the comment.
>
> Signed-off-by: Slark Xiao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +-
> drivers/gpu/drm/amd/include/atombios.h| 4 ++--
> 2 files changed, 3 insertion
On 7/21/2022 02:24, Tvrtko Ursulin wrote:
On 21/07/2022 01:54, John Harrison wrote:
On 7/19/2022 02:42, Tvrtko Ursulin wrote:
On 19/07/2022 01:05, John Harrison wrote:
On 7/18/2022 05:15, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
Remov
Hi,
Rebased on Linus' master
Changes since v1
1. Rework patchset as Rob suggested, so there is only one patch - changing spi
and display/panel.
v1:
https://lore.kernel.org/all/20220721153155.245336-2-krzysztof.kozlow...@linaro.org/
Merging
===
I guess via DT or SPI tree.
The spi-cpha and spi-cpol properties are device specific and should be
accepted only if device really needs them. Drop them from common
spi-peripheral-props.yaml schema, mention in few panel drivers which use
them and include instead in the SPI controller bindings. The controller
bindings will pr
RZ/G2L LCD controller composed of Frame compression Processor(FCPVD),
Video signal processor (VSPD) and Display unit(DU). The output of LCDC is
connected to Display parallel interface and MIPI link video interface.
This patch series aims to add basic display support on RZ/G2L SMARC EVK
platform. T
The RZ/G2L LCD controller is composed of Frame Compression Processor
(FCPVD), Video Signal Processor (VSPD), and Display Unit (DU).
The DU module supports the following hardware features
− Display Parallel Interface (DPI) and MIPI LINK Video Interface
− Display timing master
− Generates video timi
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI/DSI interfaces and supports a maximum resolution of 1080p
along with 2 RPFs to support blending of two picture layers and
raster operations (ROPs).
The DU part i
This patch series aims to support the MIPI DSI encoder found in the RZ/G2L
SoC. It currently supports DSI mode only.
This unit supports MIPI Alliance Specification for Display Serial Interface
(DSI)
Specification. This unit provides a solution for transmitting MIPI DSI compliant
digital video and
The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's. It
can operate in DSI mode, with up to four data lanes.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
v3->v4:
* No change.
v2->v3:
* Added Rb tag from G
This driver supports the MIPI DSI encoder found in the RZ/G2L
SoC. It currently supports DSI mode only.
Signed-off-by: Biju Das
---
v3->v4:
* Updated error handling in rzg2l_mipi_dsi_startup() and
rzg2l_mipi_dsi_atomic_enable()
v2->v3:
* pass rzg2l_mipi_dsi pointer to {Link,Phy} register rd/wr
On 7/19/2022 02:56, Tvrtko Ursulin wrote:
On 19/07/2022 01:13, John Harrison wrote:
On 7/18/2022 05:35, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, john.c.harri...@intel.com wrote:
From: Matthew Brost
The GuC needs a copy of a golden context for implementing watchdog
resets (aka media resets
Hi Krzysztof
On Fri, Jul 22, 2022 at 09:15:39PM +0200, Krzysztof Kozlowski wrote:
> The spi-cpha and spi-cpol properties are device specific and should be
> accepted only if device really needs them. Drop them from common
> spi-peripheral-props.yaml schema, mention in few panel drivers which use
Hi Biju,
driver looks good - you can add my:
Acked-by: Sam Ravnborg
I have one general question - that is not related to this driver, but is
directed to the bridge people on this mail.
> +static void rzg2l_mipi_dsi_atomic_enable(struct drm_bridge *bridge,
> +
Hi Biju,
On Fri, Jul 22, 2022 at 08:19:23PM +0100, Biju Das wrote:
> The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's. It
> can operate in DSI mode, with up to four data lanes.
>
> Signed-off-by: Biju Das
> Reviewed-by: Rob Herring
> Reviewed-by: Laurent Pinchart
> Reviewe
On 7/12/2022 16:31, john.c.harri...@intel.com wrote:
From: Chris Wilson
Use a temporary page and mempy_from_wc to reduce the time it takes to
dump the guc log to debugfs.
Signed-off-by: Chris Wilson
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 24 +
The pull request you sent on Fri, 22 Jul 2022 14:15:37 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-07-22
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8e65afba6baaa1317efc4038cbced1268c6e2f6b
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
This series adds new logging features for GFXOFF available for vangogh
and documentation for it.
I've created a small userspace program to interact with this new debugfs
interface and it can be found at:
https://gitlab.freedesktop.org/andrealmeid/gfxoff_tool
André Almeida (4):
drm/amd: Add de
Add debugfs interface to log GFXOFF statistics:
- Read amdgpu_gfxoff_count to get the total GFXOFF entry count at the
time of query since system power-up
- Write 1 to amdgpu_gfxoff_residency to start logging, and 0 to stop.
Read it to get average GFXOFF residency % multiplied by 100
during
Implement functions to get and set GFXOFF's entry count and residency
for vangogh.
Signed-off-by: André Almeida
---
.../pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h| 5 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 5 +-
.../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 92 +++
Add documentation explaining those two new files.
Signed-off-by: André Almeida
---
Documentation/gpu/amdgpu/thermal.rst | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/gpu/amdgpu/thermal.rst
b/Documentation/gpu/amdgpu/thermal.rst
index 997231b6adcf..c31f94c6c68
Add comments to document gfx_off related members of struct amdgpu_gfx.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.h
b/drivers/gpu/drm/amd/amdgpu/a
On 7/20/22 11:32, Jim Cromie wrote:
> Add kernel_param_ops and callbacks to apply a class-map to a
> sysfs-node, which then can control classes defined in that class-map.
> This supports uses like:
>
> echo 0x3 > /sys/module/drm/parameters/debug
>
> IE add these:
>
> - int param_set_dyndbg
On 7/20/22 11:32, Jim Cromie wrote:
> DECLARE_DYNDBG_CLASSMAP lets modules declare a set of classnames, this
> opt-in authorizes dyndbg to allow enabling of prdbgs by their class:
>
>:#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
>
> This is just the setup; following commits de
On 2022-07-20 18:54, Melissa Wen wrote:
On 07/17, Tales Lelo da Aparecida wrote:
On 16/07/2022 19:25, Melissa Wen wrote:
AMDGPU DM maps DRM color management properties (degamma, ctm and gamma)
to DC color correction entities. Part of this mapping is already
documented as code comments and ca
Acquire vbl_lock before accessing vblank refcount in drm_vblank_put,
just like everywhere else that access the refcount.
Signed-off-by: Yunxiang Li
---
drivers/gpu/drm/drm_vblank.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/driv
drm_crtc_vblank_off increments the refcount to prevent vblank from
getting enabled during modeset, but this causes the refcount elsewhere
to be off if they call drm_vblank_get without checking the return and
do a drm_vblank_put later. This can be reproduced by toggling vrr mode
on amdgpu.
Since dr
On Fri, 8 Jul 2022 15:44:18 -0700
Nicolin Chen wrote:
> This is a preparatory series for IOMMUFD v2 patches. It prepares for
> replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
> with IOMMUFD version.
>
> There's a gap between these two versions: the vfio_iommu_type1 version
>
On Tue, 19 Jul 2022 21:02:47 -0300
Jason Gunthorpe wrote:
> This is the last notifier toward the drivers, replace it with a simple op
> callback in the vfio_device_ops.
>
> v4:
> - Rebase over the CCW series
> v3:
> https://lore.kernel.org/r/0-v3-7593f297c43f+56ce-vfio_unmap_notif_...@nvidia.c
On Fri, Jul 22, 2022 at 04:11:29PM -0600, Alex Williamson wrote:
> GVT-g explodes for me with this series on my Broadwell test system,
> continuously spewing the following:
Thank you for running additional tests.
> [ 47.348778] WARNING: CPU: 3 PID: 501 at
> drivers/vfio/vfio_iommu_type1.c:978
On Fri, Jul 22, 2022 at 2:23 PM Jason Baron wrote:
>
>
>
> On 7/20/22 11:32, Jim Cromie wrote:
> > DECLARE_DYNDBG_CLASSMAP lets modules declare a set of classnames, this
> > opt-in authorizes dyndbg to allow enabling of prdbgs by their class:
> >
> >:#> echo class DRM_UT_KMS +p > /proc/dynamic
On 7/22/22 15:35, Doug Anderson wrote:
> Hi,
>
> On Fri, Jul 22, 2022 at 12:48 AM Javier Martinez Canillas
> wrote:
>>
>> If devm_drm_of_get_bridge() can't find the connected bridge, it returns an
>> ERR_PTR(-EPROBE_DEFER) to indicate that the probe should be deferred.
>>
>> But this path also pr
On Fri, 22 Jul 2022 16:12:19 -0700
Nicolin Chen wrote:
> On Fri, Jul 22, 2022 at 04:11:29PM -0600, Alex Williamson wrote:
>
> > GVT-g explodes for me with this series on my Broadwell test system,
> > continuously spewing the following:
>
> Thank you for running additional tests.
>
> > [ 47
On Fri, Jul 22, 2022 at 06:18:00PM -0600, Alex Williamson wrote:
> External email: Use caution opening links or attachments
>
>
> On Fri, 22 Jul 2022 16:12:19 -0700
> Nicolin Chen wrote:
>
> > On Fri, Jul 22, 2022 at 04:11:29PM -0600, Alex Williamson wrote:
> >
> > > GVT-g explodes for me with
On Fri, 22 Jul 2022 17:38:25 -0700
Nicolin Chen wrote:
> On Fri, Jul 22, 2022 at 06:18:00PM -0600, Alex Williamson wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Fri, 22 Jul 2022 16:12:19 -0700
> > Nicolin Chen wrote:
> >
> > > On Fri, Jul 22, 2022 at 04:
This is a preparatory series for IOMMUFD v2 patches. It prepares for
replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
with IOMMUFD version.
There's a gap between these two versions: the vfio_iommu_type1 version
inputs a non-contiguous PFN list and outputs another PFN list for t
It's a bit redundant for the maths here using roundup.
Suggested-by: Jason Gunthorpe
Tested-by: Terrence Xu
Signed-off-by: Nicolin Chen
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu
The ap_aqic() is called by vfio_ap_irq_enable() where it passes in a
virt value that's casted from a physical address "h_nib". Inside the
ap_aqic(), it does virt_to_phys() again.
Since ap_aqic() needs a physical address, let's just pass in a pa of
ind directly. So change the "ind" to "pa_ind".
Re
There's only one caller that checks its return value with a WARN_ON_ONCE,
while all other callers don't check the return value at all. Above that,
an undo function should not fail. So, simplify the API to return void by
embedding similar WARN_ONs.
Also for users to pinpoint which condition fails,
1 - 100 of 108 matches
Mail list logo
