Fix several issues with the DP and eDP bindings on the Qualcomm
platforms. While we are at it, fix several small issues with platform
files declaring these controllers.
Changes since v1:
- Reordered patches to cleanup dts first, to remove warnings from DP
schema
- Split DP register blocks in
Follow the schema for the DP controller and declare 5 register regions
instead of using a single region for all the registers. Note, this
extends the dts by adding p1 region to the DP node (to be used for DP
MST).
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 +
Follow the schema for the DP controller and declare 5 register regions
instead of using a single region for all the registers. Note, this
extends the dts by adding p1 region to the DP node (to be used for DP
MST).
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 6 +
Drop #clock-cells from DP device node. It is a leftover from the times
before splitting the deviice into controller and PHY devices. Now the
clocks are provided by the PHY, while the controller doesn't provide any
clocks.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/
The eDP node includes two clocks which are used by the eDP PHY rather
than eDP controller itself. Drop these clocks to remove extra difference
between eDP and DP controllers.
Suggested-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 8 ++--
1 file
The commit fa384dd8b9b8 ("drm/msm/dp: delete vdda regulator related
functions from eDP/DP controller") removed support for VDDA supplies
from the DP controller driver. These supplies are now handled by the eDP
or QMP PHYs. Mark these properties as deprecated and drop them from the
example.
Signed-
Drop #clock-cells from DP device node. It is a leftover from the times
before splitting the device into controller and PHY devices. Now the
clocks are provided by the PHY, while the controller doesn't provide any
clocks.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/b
Drop #address/#size-cells from eDP device node. For eDP the panels are
not described directly under the controller node. They are either
present under aux-bus child node, or they are declared separately (e.g.
in a /soc node).
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
arch/ar
The #sound-dai-cells property should be used only for DP controllers. It
doesn't make sense for eDP, there is no support for audio output. The
aux-bus should not be used for DP controllers. Also p1 MMIO region
should be used only for DP controllers.
Take care of these differences.
Signed-off-by:
Document missing definitions for opp-table (DP controller OPPs), aux-bus
(DP AUX BUS) and data-lanes (DP/eDP lanes mapping) properties.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/dp-controller.yaml | 12
1 file changed, 12 insert
We have an upcoming openchrome driver for VIA where some
of the files conflicts with the existing via driver.
It is not acceptable to just delete the existing DRI1
based driver as there are most likely users out there,
so a different approach was required.
It was disccussed what to do and the lea
The via driver implements the DRI1 interface, and we have a new
implementation of the via driver coming that supports atomic
modesetting.
It is not acceptable just to replace the existing driver so
this is first step to make it a single-file implementation allowing
it to stay without interfering w
Moved the copyright notices so all copyrights are kept.
A few variables was made static as there are no more users outside this
file.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/via/Makefile | 2 +-
drivers/gpu/drm/via/via_dma.c | 744 -
drivers/gpu/drm/v
All functions was made static as there are no external users.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/via/Makefile | 2 +-
drivers/gpu/drm/via/via_dri1.c | 208
drivers/gpu/drm/via/via_drv.h | 9 --
drivers/gpu/drm/via/via_mm.c | 241
A few functions has no external use and are made static.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/via/Makefile | 2 +-
drivers/gpu/drm/via/via_dri1.c | 102 +
drivers/gpu/drm/via/via_drv.h | 4 -
drivers/gpu/drm/via/via_map.c | 132 -
All functions are made static as there are no more external users.
The file had new copyrights that are kept.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/via/Makefile | 2 +-
drivers/gpu/drm/via/via_dri1.c | 347 +
drivers/gpu/drm/via/via_drv.h | 9 -
drive
All functions are made static as there are no more external users.
The file had a new copyright that is kept.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/via/Makefile| 2 +-
drivers/gpu/drm/via/via_dri1.c | 66 ++-
drivers/gpu/drm/via/via_drv.h | 4 --
drivers/gp
Embed some of the header file in via_drv.h and
the rest in via_dri1.c
While embedding deleted extra empty lines and functions that
has no external users are made static.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/via/Makefile | 2 +-
drivers/gpu/drm/via/via_dmablit.c | 807 --
With this change the driver is now a signle file driver.
The only remaning heder file describes the HW and can be shared with the
new openchrome driver.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/via/via_dri1.c | 229 +++-
drivers/gpu/drm/via/via_drv.h | 265 ---
Embed the header file in via_drv.h and the code in via_dri1.
All functions are made static as there are no more external users.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/via/Makefile |2 +-
drivers/gpu/drm/via/via_dri1.c | 1071 +++
drivers/gpu/drm/via
The via driver is a dri1 driver.
Make this obvious in the name of the driver.
This also make the diver name "via" free for the upcoming openchrome
driver.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/via/Makefile | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/
Updated the 3d_reg header file to match what is used by the openchrome
driver.
This verifies that the two drivers can use the same header file.
Signed-off-by: Sam Ravnborg
---
drivers/gpu/drm/via/via_3d_reg.h | 395 ---
1 file changed, 304 insertions(+), 91 deletions(
Create separate YAML schema for MDSS devicesd$ (both for MDP5 and DPU
devices). Cleanup DPU schema files, so that they do not contain schema
for both MDSS and DPU nodes. Apply misc small fixes to the DPU schema
afterwards.
Changes since v1:
- Renamed DPU device nodes from mdp@ to display-controll
Rename DPU device node to display-controller@ae01000 to follow the
DPU schema.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
Rename DPU device node to display-controller@ae01000 to follow the
DPU schema.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
Move schema for qcom,qcm2290-mdss from dpu-qcm2290.yaml to mdss.yaml so
that the dpu file describes only the DPU schema.
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/dpu-qcm2290.yaml | 140 +-
.../devicetree/bindings/display/msm/mdss.yaml | 24 +++
2 files ch
Move schema for qcom,sdm845-mdss from dpu-sdm845.yaml to mdss.yaml so
that the dpu file describes only the DPU schema.
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/dpu-sdm845.yaml | 135 ---
.../devicetree/bindings/display/msm/mdss.yaml | 156 ++
Move schema for qcom,sc7180-mdss from dpu-sc7180.yaml to mdss.yaml so
that the dpu file describes only the DPU schema.
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/dpu-sc7180.yaml | 149 +-
.../devicetree/bindings/display/msm/mdss.yaml | 45 +-
2 files c
Move schema for qcom,sc7280-mdss from dpu-sc7280.yaml to mdss.yaml so
that the dpu file describes only the DPU schema.
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/dpu-sc7280.yaml | 148 +-
.../devicetree/bindings/display/msm/mdss.yaml | 19 +++
2 files chan
Move schema for qcom,msm8998-mdss from dpu-msm8998.yaml to mdss.yaml so
that the dpu file describes only the DPU schema.
Signed-off-by: Dmitry Baryshkov
---
.../bindings/display/msm/dpu-msm8998.yaml | 142 +-
.../devicetree/bindings/display/msm/mdss.yaml | 24 +++
2 files ch
Split Mobile Display SubSystem (MDSS) root node bindings to the separate
yaml file. Changes to the existing (txt) schema:
- Added optional "vbif_nrt_phys" region used by msm8996
- Made "bus" and "vsync" clocks optional (they are not used by some
platforms)
- Added (optional) "core" clock adde
Move properties common to all DPU DT nodes to the dpu-common.yaml.
Note, this removes description of individual DPU port@ nodes. However
such definitions add no additional value. The reg values do not
correspond to hardware INTF indices. The driver discovers and binds
these ports not paying any ca
Rename DPU device node to display-controller@ae01000 to follow the
DPU schema.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
Add gcc-bus clock required for the SDM845 DPU device tree node. This
change was made in the commit 111c52854102 ("arm64: dts: qcom: sdm845:
move bus clock to mdp node for sdm845 target"), but was not reflected in
the schema.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm
Hi Molly,
On Sun, Jul 10, 2022 at 02:19:41PM +0800, Molly Sophia wrote:
> Hi Sam,
>
> Thanks for your suggestions.
>
> Sam Ravnborg 于 2022年7月10日周日 上午4:47写道：
>
> > Hi Molly,
> >
> > thanks for the quick response to the review comments.
> >
> > On Sat, Jul 09, 2022 at 10:11:35PM +0800, MollySoph
Hi Geert,
On Fri, Jul 08, 2022 at 08:21:31PM +0200, Geert Uytterhoeven wrote:
> Fill in the LSB when converting color components from 8-bit to 16-bit.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> v2:
> - New.
> ---
> tests/util/pattern.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 delet
Hi Geert,
On Fri, Jul 08, 2022 at 08:21:30PM +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> A long outstanding issue with the DRM subsystem has been the lack of
> support for low-color displays, as used typically on older desktop
> systems, and on small embedded displays.
>
> This patch se
https://bugzilla.kernel.org/show_bug.cgi?id=216143
--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Tried
https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-fixes&id=925b6e59138cefa47275c67891c65d48d3266d57
suggested in https://gitlab.freedesktop.org/drm/amd/-/issues/2050#note_14
Hi Sam,
On Sun, Jul 10, 2022 at 12:31 PM Sam Ravnborg wrote:
> On Fri, Jul 08, 2022 at 08:21:31PM +0200, Geert Uytterhoeven wrote:
> > Fill in the LSB when converting color components from 8-bit to 16-bit.
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > v2:
> > - New.
> > ---
> > tests/
Hi Sam,
Thank you again for your support. I forgot that point, which is really
important to know.
Molly
Sam Ravnborg 于2022年7月10日周日 18:13写道：
> Hi Molly,
>
> On Sun, Jul 10, 2022 at 02:19:41PM +0800, Molly Sophia wrote:
> > Hi Sam,
> >
> > Thanks for your suggestions.
> >
> > Sam Ravnborg 于
Hi Geert,
On Sun, Jul 10, 2022 at 01:04:23PM +0200, Geert Uytterhoeven wrote:
> Hi Sam,
>
> On Sun, Jul 10, 2022 at 12:31 PM Sam Ravnborg wrote:
> > On Fri, Jul 08, 2022 at 08:21:31PM +0200, Geert Uytterhoeven wrote:
> > > Fill in the LSB when converting color components from 8-bit to 16-bit.
>
Hi Sam,
On Sun, Jul 10, 2022 at 12:40 PM Sam Ravnborg wrote:
> On Fri, Jul 08, 2022 at 08:21:30PM +0200, Geert Uytterhoeven wrote:
> > A long outstanding issue with the DRM subsystem has been the lack of
> > support for low-color displays, as used typically on older desktop
> > systems, and on sm
On Sat, Jul 09, 2022 at 12:30:51PM +0200, Greg KH wrote:
> On Sat, Jul 09, 2022 at 01:06:56PM +0300, Christos Kollintzas wrote:
> > Adhere to Linux kernel coding style.
> >
> > Reported by checkpatch:
> >
> > CHECK: usleep_range is preferred over udelay
> >
> > Signed-off-by: Christos Kollintzas
On 08/07/2022 22:54, Paul Cercueil wrote:
> Add compatible strings for the LCD controllers found in the JZ4760 and
> JZ4760B SoCs from Ingenic.
>
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
Hi Dave & Daniel,
Here is main drm/msm pull for v5.20, description below and in tag
The following changes since commit b13baccc3850ca8b8cccbf8ed9912dbaa0fdf7f3:
Linux 5.19-rc2 (2022-06-12 16:11:37 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.git tag
Fix two coverity warning's double free and and an uninitialized pointer
read. Both tmp and new are pointing at same address and both are freed
which leads to double free. Freeing tmp in the condition after new is
assigned with new address fixes the double free issue. new is not
initialized to null
Hi Developers,
I am seeing thrashing of errors print once Android kernel trying to enable
SurfaceFlinger (swiftshader) stuff.
[drm:drm_calc_timestamping_constants] *ERROR* crtc 32: Can't calculate
constants, dotclock = 0!
[ 19.985323][C0] vkms_vblank_simulate: vblank timer overrun
[ 19.991
On Sat, 09 Jul 2022 22:11:35 +0800, MollySophia wrote:
> Add documentation for "novatek,nt35596s" panel.
>
> Signed-off-by: MollySophia
> ---
> .../display/panel/novatek,nt35596s.yaml | 83 +++
> 1 file changed, 83 insertions(+)
> create mode 100644
> Documentation/device
On Sun, 10 Jul 2022 12:00:33 +0300, Dmitry Baryshkov wrote:
> Split Mobile Display SubSystem (MDSS) root node bindings to the separate
> yaml file. Changes to the existing (txt) schema:
> - Added optional "vbif_nrt_phys" region used by msm8996
> - Made "bus" and "vsync" clocks optional (they are
On 10/07/2022 19:54, Rob Herring wrote:
On Sun, 10 Jul 2022 12:00:33 +0300, Dmitry Baryshkov wrote:
Split Mobile Display SubSystem (MDSS) root node bindings to the separate
yaml file. Changes to the existing (txt) schema:
- Added optional "vbif_nrt_phys" region used by msm8996
- Made "bus" a
> Wiadomość napisana przez Piotr Oniszczuk w dniu
> 25.06.2022, o godz. 17:31:
>
>
>
>> Wiadomość napisana przez Peter Geis w dniu 25.06.2022,
>> o godz. 16:00:
>>
>>
>> The first issue you have is the TV isn't responding until the absolute
>> end.
>
> I suspect this is because lack on
An RFC (or rather RFT, Request-for-Testing) series adding support for
DRM_BRIDGE_ATTACH_NO_CONNECTOR. Note, it was compile-tested only. This
bridge is the last one used on the Qualcomm platforms (in
upstream-supported devices) and thus it is the only bridge that prevents
us from removing support f
Make ti-sn65dsi86 use atomic_enable / atomic_disable / atomic_pre_enable
/ atomic_post_disable rather than their non-atomic versions.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git
Rather than reading the pdata->connector directly, fetch the connector
using drm_atomic_state. This allows us to make pdata->connector optional
(and thus supporting DRM_BRIDGE_ATTACH_NO_CONNECTOR).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 20 ++-
Now as the driver does not depend on pdata->connector, add support for
attaching the bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/
Hi Dmitry,
On Sun, Jul 10, 2022 at 09:45:34PM +0300, Dmitry Baryshkov wrote:
> Make ti-sn65dsi86 use atomic_enable / atomic_disable / atomic_pre_enable
> / atomic_post_disable rather than their non-atomic versions.
>
> Signed-off-by: Dmitry Baryshkov
a more or less identical patch was applied t
Hi Dmitry,
On Sun, Jul 10, 2022 at 09:45:35PM +0300, Dmitry Baryshkov wrote:
> Rather than reading the pdata->connector directly, fetch the connector
> using drm_atomic_state. This allows us to make pdata->connector optional
> (and thus supporting DRM_BRIDGE_ATTACH_NO_CONNECTOR).
>
> Signed-off-b
Hi Dmitry,
On Sun, Jul 10, 2022 at 09:45:36PM +0300, Dmitry Baryshkov wrote:
> Now as the driver does not depend on pdata->connector, add support for
> attaching the bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> Signed-off-by: Dmitry Baryshkov
Looks good,
Reviewed-by: Sam Ravnborg
The ST7701(S) is capable of DSI burst mode, which is more energy
efficient than the non-burst modes. Make use of it.
The ST7701(S) is capable of DSI non-continuous clock, since it
sources the TFT matrix driver clock from internal clock source.
The DSI non-continuous clock further reduce power util
The gamma correction values are specific to the TFT which is attached to
the ST7701 TFT matrix driver, move the gamma correction values from what
incorrectly looks like common init sequence into TFT matrix specific
settings.
While doing so, add macros which defined fields within the gamma register
Define DSI_CMD2_BK0_PORCTRL_VBP_MASK and DSI_CMD2_BK0_PORCTRL_VFP_MASK
and move the vertical back and front porch calculation from macros into
the st7701_init_sequence() function, so it is clear what this does.
No functional change.
Signed-off-by: Marek Vasut
Cc: Guido Günther
Cc: Jagan Teki
C
The horizontal pixel count is a property of the TFT matrix. Currently the
driver hard-codes content of this register to specific value which is
only compatible with one TFT matrix, likely the TS8550B one.
Calculate the horizontal pixel count from the mode instead.
Signed-off-by: Marek Vasut
Cc:
The ST7701 and ST7701S are TFT matrix drivers with integrated multi
protocol decoder capable of DSI/DPI/SPI input and 480x360...864 line
TFT matrix output. Currently the only supported input is DSI.
The protocol decoder is separate from the TFT matrix driver and is
always capable of handling all o
The vertical line count is a property of the TFT matrix. Currently the
driver hard-codes content of this register to specific value which is
only compatible with one TFT matrix, likely the TS8550B one.
Calculate the vertical line count from the mode instead.
Signed-off-by: Marek Vasut
Cc: Guido
The ST7701 and ST7701S all have two voltage supplies, one for internal
logic and one for the TFT matrix driver. The supplies are not property
of the TFT matrix driver, so move them to common ST7701 code.
Signed-off-by: Marek Vasut
Cc: Guido Günther
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus
Instead of hard-coding TFT matrix voltage and timing settings, which can
even lead to permanent TFT matrix damage, parametrize them in TFT matrix
descriptor.
Signed-off-by: Marek Vasut
Cc: Guido Günther
Cc: Jagan Teki
Cc: Laurent Pinchart
Cc: Linus Walleij
Cc: Sam Ravnborg
Cc: Thierry Reding
The ST7701 initialization sequence is well parametrized, split the GIP
programming sequence, which is fully custom completely undocumented
TFT matrix specific magic register programming sequence into separate
callback so other TFT matrix definitions can add their own GIP sequence.
Signed-off-by: M
Hi All,
I've been rebasing my backlight refactor on top of drm-tip to submit
a new version upstream and I noticed that drm-tip does not compile.
This is caused by a mismerge of:
commit 925b6e59138cefa47275c67891c65d48d3266d57 (drm-misc/for-linux-next-fixes,
drm-misc/drm-misc-fixes, drm-misc-fix
Hi Dmitry,
Thank you for the patch.
On Sun, Jul 10, 2022 at 09:45:36PM +0300, Dmitry Baryshkov wrote:
> Now as the driver does not depend on pdata->connector, add support for
> attaching the bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm
Hi Dmitry,
Thank you for the patch.
On Sun, Jul 10, 2022 at 09:45:35PM +0300, Dmitry Baryshkov wrote:
> Rather than reading the pdata->connector directly, fetch the connector
> using drm_atomic_state. This allows us to make pdata->connector optional
> (and thus supporting DRM_BRIDGE_ATTACH_NO_CON
On 7/11/22 04:39, conor.doo...@microchip.com wrote:
> Damien, Krzysztof,
>
> I know this particular version has not been posted for all that
> long, but this binding is (functionally) unchanged for a few
> versions now. Are you happy with this approach Damien?
> U-Boot only cares about the compati
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
between commit:
925b6e59138c ("Revert "drm/amdgpu: add drm buddy support to amdgpu"")
from the drm-misc-fixes tree and commit:
5e3f1e7729ec ("drm/amdgpu: fix start calculatio
On 2022.05.21 13:10:59 +0200, Julia Lawall wrote:
> Spelling mistake (triple letters) in comment.
> Detected with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/gpu/drm/i915/gvt/gtt.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers
On 2022.05.24 16:37:33 +0800, Jiapeng Chong wrote:
> Fix the following W=1 kernel warnings:
>
> drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype
> for intel_t_default_mmio_write(). Prototype was for
> intel_vgpu_default_mmio_write() instead.
>
> Reported-by: Abaci Robot
> S
On 2022.05.24 16:37:32 +0800, Jiapeng Chong wrote:
> Fix the following W=1 kernel warnings:
>
> drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting
> prototype for intel_gvt_switch_render_mmio(). Prototype was for
> intel_gvt_switch_mmio() instead.
>
> Reported-by: Abaci Robot
> Sign
On 2022.06.02 15:35:19 +0800, Jiapeng Chong wrote:
> Fix the following W=1 kernel warnings:
>
> drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting prototype
> for inte_gvt_free_vgpu_resource(). Prototype was for
> intel_vgpu_free_resource() instead.
>
> drivers/gpu/drm/i915/gvt/apertu
Hi Samuel,
On Sun, Jul 3, 2022 at 1:17 PM Samuel Holland wrote:
> On 6/15/22 4:38 AM, Suniel Mahesh wrote:
> > Add a binding for the RenewWorldOutReach R16-Vista-E board based on
> > allwinner R16.
> >
> > Signed-off-by: Christopher Vollo
> > Signed-off-by: Jagan Teki
> > Signed-off-by: Suniel
Hi Samuel,
On Sun, Jul 3, 2022 at 1:12 PM Samuel Holland wrote:
> On 6/15/22 4:39 AM, Suniel Mahesh wrote:
> > The R16-Vista-E board from RenewWorldOutreach based on allwinner
> > R16(A33).
> >
> > General features:
> > - 1GB RAM
> > - microSD slot
> > - Realtek Wifi
> > - 1 x USB 2.0
> > - HDMI
i915 selftest hangcheck is causing the i915 driver timeouts, as reported
by Intel CI bot:
http://gfx-ci.fi.intel.com/cibuglog-ng/issuefilterassoc/24297?query_key=42a999f48fa6ecce068bc8126c069be7c31153b4
When such test runs, the only output is:
[ 68.811639] i915: Performing live selftes
From: Chris Wilson
Avoid trying to invalidate the TLB in the middle of performing an
engine reset, as this may result in the reset timing out. Currently,
the TLB invalidate is only serialised by its own mutex, forgoing the
uncore lock, but we can take the uncore->lock as well to serialise
the mmi
From: Chris Wilson
Don't allow two engines to be reset in parallel, as they would both
try to select a reset bit (and send requests to common registers)
and wait on that register, at the same time. Serialize control of
the reset requests/acks using the uncore->lock, which will also ensure
that no
81 matches
Mail list logo
