Re: [PATCH] matroxfb: add Matrox MGA-G200eW board support
On Sat, Jan 25, 2020 at 02:55:06PM -0500, Rich Felker wrote: > Signed-off-by: Rich Felker > -- I know I don't accept patches without any changelog text, don't know about other subsystem maintainers... greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206309] New: Experimental amdgpu w/ Dell E6540 with HD 8790M (MARS XTX), massive performance improvement after ACPI suspend
https://bugzilla.kernel.org/show_bug.cgi?id=206309 Bug ID: 206309 Summary: Experimental amdgpu w/ Dell E6540 with HD 8790M (MARS XTX), massive performance improvement after ACPI suspend Product: Drivers Version: 2.5 Kernel Version: 5.4.12-200.fc31.x86_64 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: changhaitra...@gmail.com Regression: No Hi, I have a Dell E6540 with HD 8790M (MARS XTX) I also have the `radeon.si_support=0 amdgpu.si_support=1` kernel flags set to enable experimental amdgpu support. I run games such as Insurgency, Tomb Raider (2013), Talos Principle, and Half-Life 2 Episode 1 from it with the `DRI_PRIME=1` env variable. On all of these games, they seem to perform underwhelmingly (under 30fps for most games), until I suspend the computer and wake it from suspension. (This even works while in game). Here are some things I've noticed: 1. setting the `amdgpu.dpm=0` kernel flag makes it so that suspending the computer and waking it up DOES NOT double/triple the gaming graphics performance like it usually does. 2. setting `/sys/class/drm/card1/device/power_dpm_force_performance_level` or `/sys/class/drm/card1/device/power_dpm_state` before having suspended the computer does not noticeably impact performance. 3. If I reboot the computer after having suspended it, instead of shutting down or hibernating, it seems to at least sometime hold on to its gaming graphics performance so that I don't need to suspend the computer once more while playing a game. 4. This suspend-wakeup performance improvement does not seem reproducible on RadeonSI (`radeon.si_support=1`), although I can't tell if it's lower performance or higher, since it'll perform well in Half-Life 2, but closer to the reduced (pre-suspend) performance state in many other games. 5. Wayland or X11 makes no difference. 6. Games using the Intel IGP are not affected by suspend + wake. In the below Log's dmesg, I suspend and wake up the computer at ~1588 LOG: [travis@Claes ~]$ dmesg | grep -E -i "dpm|amdgpu|radeon" [0.00] Command line: BOOT_IMAGE=(hd0,msdos2)/vmlinuz-5.4.12-200.fc31.x86_64 root=/dev/mapper/altarus-root ro resume=/dev/mapper/altarus-swap rd.lvm.lv=altarus/root rd.lvm.lv=altarus/swap rhgb quiet radeon.si_support=0 amdgpu.si_support=1 zswap.enabled=1 zswap.compressor=lz4 zswap.zpool=z3fold amdgpu.dpm=1 amdgpu.dc=1 [0.129882] Kernel command line: BOOT_IMAGE=(hd0,msdos2)/vmlinuz-5.4.12-200.fc31.x86_64 root=/dev/mapper/altarus-root ro resume=/dev/mapper/altarus-swap rd.lvm.lv=altarus/root rd.lvm.lv=altarus/swap rhgb quiet radeon.si_support=0 amdgpu.si_support=1 zswap.enabled=1 zswap.compressor=lz4 zswap.zpool=z3fold amdgpu.dpm=1 amdgpu.dc=1 [3.018497] [drm] radeon kernel modesetting enabled. [3.018785] radeon :01:00.0: SI support disabled by module param [3.271878] [drm] amdgpu kernel modesetting enabled. [3.272148] amdgpu :01:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xe000 -> 0xefff [3.272149] amdgpu :01:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xf7c0 -> 0xf7c3 [3.272158] amdgpu :01:00.0: enabling device ( -> 0003) [3.272841] [drm] add ip block number 5 [3.272843] amdgpu :01:00.0: kfd not supported on this ASIC [3.306053] amdgpu :01:00.0: VRAM: 2048M 0x00F4 - 0x00F47FFF (2048M used) [3.306054] amdgpu :01:00.0: GART: 1024M 0x00FF - 0x00FF3FFF [3.306399] [drm] amdgpu: 2048M of VRAM memory ready [3.306401] [drm] amdgpu: 3072M of GTT memory ready. [3.306899] amdgpu :01:00.0: PCIE GART of 1024M enabled (table at 0x00F4). [3.307310] [drm] amdgpu: dpm initialized [3.307352] [drm] AMDGPU Display Connectors [3.878634] [drm] Initialized amdgpu 3.35.0 20150101 for :01:00.0 on minor 1 [ 12.958605] amdgpu :01:00.0: PCIE GART of 1024M enabled (table at 0x00F4). [ 27.123524] amdgpu :01:00.0: PCIE GART of 1024M enabled (table at 0x00F4). [ 1588.479472] amdgpu :01:00.0: PCIE GART of 1024M enabled (table at 0x00F4). [ 1590.890634] amdgpu :01:00.0: PCIE GART of 1024M enabled (table at 0x00F4). [ 1676.994027] amdgpu :01:00.0: PCIE GART of 1024M enabled (table at 0x00F4). [travis@Claes ~]$ DRI_PRIME=1 glxinfo -B name of display: :1 display: :1 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD Radeon HD 8790M (OLAND, DRM 3.35.0, 5.4.12-200.fc31.x86_64, LLVM 9.0.0) (0x6606) Version: 19.2.8 Accelerated: yes Video memory: 2048MB Unified memory: no Preferr
[PATCH v2 0/3] dt-bindings: convert timing + panel-dpi to DT schema
This set of patches convert display-timing.txt to DT schema. To do that add a panel-timing.yaml file that include all the panel-timing properties and use this in panel-common and in display-timings. panel-dpi was also converted so we have no .txt users left of panel-timing in panel/ Everything passed dt_binding_check - and the trivial errors I tried in the examples was all catched during validation. This work was triggered by a patch-set from Oleksandr Suvorov aiming at updating panel-lvds to support panel-dpi too. This will make it simple to add additional properties to panel-dpi. Thanks for the quick responses on v2 and likewise the quick feedback on the request for the license change! Highlights from v2 - see individual patches for details. - Got acks for the license change - Simplfied panel-timings bindings - panel-dpi can now be used without a panel specific compatible So panel-dpi can be used as a generic binding for dumb panels Feedback welcome! Sam Sam Ravnborg (3): dt-bindings: display: add panel-timing.yaml dt-bindings: display: convert display-timings to DT schema dt-bindings: display: convert panel-dpi to DT schema .../bindings/display/panel/display-timing.txt | 124 +-- .../bindings/display/panel/display-timings.yaml| 68 ++ .../bindings/display/panel/panel-common.yaml | 7 +- .../bindings/display/panel/panel-dpi.txt | 50 - .../bindings/display/panel/panel-dpi.yaml | 71 +++ .../bindings/display/panel/panel-timing.yaml | 227 + 6 files changed, 370 insertions(+), 177 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] dt-bindings: display: convert panel-dpi to DT schema
With panel-timing converted, now convert the single
remaining .txt user in panel/ of panel-timing to DT schema.
v2:
- Drop Thierry as maintainer, as this is not a general panel binding
and I have no acks.
- Drop requirement for a panel- specific binding - "panel-dpi" is enough
- Updated example
Signed-off-by: Sam Ravnborg
Cc: Rob Herring
Cc: Thierry Reding
Cc: Laurent Pinchart
Cc: Maxime Ripard
---
.../bindings/display/panel/panel-dpi.txt | 50 -
.../bindings/display/panel/panel-dpi.yaml | 71 +++
2 files changed, 71 insertions(+), 50 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/panel-dpi.txt
create mode 100644
Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
deleted file mode 100644
index 6b203bc4d932..
--- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
+++ /dev/null
@@ -1,50 +0,0 @@
-Generic MIPI DPI Panel
-==
-
-Required properties:
-- compatible: "panel-dpi"
-
-Optional properties:
-- label: a symbolic name for the panel
-- enable-gpios: panel enable gpio
-- reset-gpios: GPIO to control the RESET pin
-- vcc-supply: phandle of regulator that will be used to enable power to the
display
-- backlight: phandle of the backlight device
-
-Required nodes:
-- "panel-timing" containing video timings
- (Documentation/devicetree/bindings/display/panel/display-timing.txt)
-- Video port for DPI input
-
-Example
-
-lcd0: display@0 {
-compatible = "samsung,lte430wq-f0c", "panel-dpi";
-label = "lcd";
-
-backlight = <&backlight>;
-
-port {
-lcd_in: endpoint {
-remote-endpoint = <&dpi_out>;
-};
-};
-
-panel-timing {
-clock-frequency = <920>;
-hactive = <480>;
-vactive = <272>;
-hfront-porch = <8>;
-hback-porch = <4>;
-hsync-len = <41>;
-vback-porch = <2>;
-vfront-porch = <4>;
-vsync-len = <10>;
-
-hsync-active = <0>;
-vsync-active = <0>;
-de-active = <1>;
-pixelclk-active = <1>;
-};
-};
diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
new file mode 100644
index ..a8e37318ec05
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic MIPI DPI Panel
+
+maintainers:
+ - Sam Ravnborg
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+contains:
+ const: panel-dpi
+description:
+ Shall contain "panel-dpi" in addition to an optional panel-specific
+ compatible string defined in individual panel bindings.
+ "panel-dpi" can be used alone, thus no dedicated binding file
+ is required for each and every panel.
+
+ vcc-supply:
+description: |
+ Regulator that will be used to enable power to the display
+
+ label: true
+ enable-gpios: true
+ reset-gpios: true
+ backlight: true
+ panel-timing: true
+ port: true
+
+required:
+ - panel-timing
+
+additionalProperties: false
+
+examples:
+ - |
+panel@0 {
+ compatible = "panel-dpi";
+ label = "lcd";
+ vcc-supply = <&vcc_supply>;
+
+ backlight = <&backlight>;
+
+ port {
+lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+};
+ };
+ panel-timing {
+clock-frequency = <920>;
+hactive = <800>;
+vactive = <480>;
+hfront-porch = <8>;
+hback-porch = <4>;
+hsync-len = <41>;
+vback-porch = <2>;
+vfront-porch = <4>;
+vsync-len = <10>;
+
+hsync-active = <0>;
+vsync-active = <0>;
+de-active = <1>;
+pixelclk-active = <1>;
+ };
+};
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] dt-bindings: display: convert display-timings to DT schema
Add display-timings.yaml - that references panel-timings.yaml. display-timings.yaml will be used for display bindings when they are converted to meta-schema format. For now the old display-timing.txt points to the new display-timings.yaml - and all users are left as-is. v2: - Updated native-mode description Signed-off-by: Sam Ravnborg Cc: Rob Herring Cc: Laurent Pinchart Cc: Thierry Reding Cc: Oleksandr Suvorov Cc: devicet...@vger.kernel.org --- .../bindings/display/panel/display-timing.txt | 124 +- .../display/panel/display-timings.yaml| 68 ++ 2 files changed, 69 insertions(+), 123 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/display-timings.yaml diff --git a/Documentation/devicetree/bindings/display/panel/display-timing.txt b/Documentation/devicetree/bindings/display/panel/display-timing.txt index 78222ced1874..7f55ad4a40c4 100644 --- a/Documentation/devicetree/bindings/display/panel/display-timing.txt +++ b/Documentation/devicetree/bindings/display/panel/display-timing.txt @@ -1,123 +1 @@ -display-timing bindings -=== - -display-timings node - - -required properties: - - none - -optional properties: - - native-mode: The native mode for the display, in case multiple modes are - provided. When omitted, assume the first node is the native. - -timing subnode --- - -required properties: - - hactive, vactive: display resolution - - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters - in pixels - vfront-porch, vback-porch, vsync-len: vertical display timing parameters in - lines - - clock-frequency: display clock in Hz - -optional properties: - - hsync-active: hsync pulse is active low/high/ignored - - vsync-active: vsync pulse is active low/high/ignored - - de-active: data-enable pulse is active low/high/ignored - - pixelclk-active: with - - active high = drive pixel data on rising edge/ - sample data on falling edge - - active low = drive pixel data on falling edge/ - sample data on rising edge - - ignored = ignored - - syncclk-active: with - - active high = drive sync on rising edge/ - sample sync on falling edge of pixel - clock - - active low = drive sync on falling edge/ - sample sync on rising edge of pixel - clock - - omitted = same configuration as pixelclk-active - - interlaced (bool): boolean to enable interlaced mode - - doublescan (bool): boolean to enable doublescan mode - - doubleclk (bool): boolean to enable doubleclock mode - -All the optional properties that are not bool follow the following logic: -<1>: high active -<0>: low active -omitted: not used on hardware - -There are different ways of describing the capabilities of a display. The -devicetree representation corresponds to the one commonly found in datasheets -for displays. If a display supports multiple signal timings, the native-mode -can be specified. - -The parameters are defined as: - - +--+-+--+---+ - | |^| | | - | ||vback_porch | | | - | |v| | | - +--###--+---+ - | #^# | | - | #|# | | - | hback #|# hfront | hsync | - | porch #| hactive # porch | len | - |<>#<---+--->#<>|<->| - | #|# | | - | #|vactive # | | - | #|# | | - | #v# | | - +--###--+---+ - | |^| | | - | ||vfront_porch| | | - | |v| | | - +--+-+--+---+ - | |^| | | - | ||vsync_len | | | - | |v| | | - +--+
[PATCH v2 1/3] dt-bindings: display: add panel-timing.yaml
Add meta-schema variant of panel-timing and
reference it from panel-common.yaml.
Part of this came form other files with other
licenses - original commits:
cc3f414cf2e4 ("video: add of helper for display timings/videomode")
86f46565dff3 ("dt-bindings: display: display-timing: Add property to configure
sync drive edge")
9cad9c95d7e8 ("Documentation: DocBook DRM framework documentation")
The original authors acked the license change to:
(GPL-2.0-only OR BSD-2-Clause)
v2:
- Got OK from original authors for re-license
Huge thanks for the quick replies!
- Typo fixes (Oleksandr)
- Drop -array variant when not needed (Maxime)
- Replace oneOf:... with enum (Maxime)
- Drop type from clock-frequency (Rob)
- Drop "|" when not needed (Rob)
Signed-off-by: Sam Ravnborg
Acked-by: Laurent Pinchart
Acked-by: Peter Ujfalusi
Acked-by: Steffen Trumtrar
Acked-by: Philipp Zabel
Cc: Rob Herring
Cc: Thierry Reding
Cc: Oleksandr Suvorov
Cc: Maxime Ripard
Cc: devicet...@vger.kernel.org
---
.../bindings/display/panel/panel-common.yaml | 7 +-
.../bindings/display/panel/panel-timing.yaml | 227 ++
2 files changed, 230 insertions(+), 4 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/panel/panel-timing.yaml
diff --git a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
index ef8d8cdfcede..8070c439adbd 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-common.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-common.yaml
@@ -54,13 +54,12 @@ properties:
# Display Timings
panel-timing:
-type: object
description:
Most display panels are restricted to a single resolution and
require specific display timings. The panel-timing subnode expresses
those
- timings as specified in the timing subnode section of the display timing
- bindings defined in
- Documentation/devicetree/bindings/display/panel/display-timing.txt.
+ timings.
+allOf:
+ - $ref: panel-timing.yaml#
# Connectivity
port:
diff --git a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml
b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml
new file mode 100644
index ..bdfb6d461529
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml
@@ -0,0 +1,227 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-timing.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: panel timing bindings
+
+maintainers:
+ - Thierry Reding
+ - Sam Ravnborg
+
+description: |
+ There are different ways of describing the timing data of a panel. The
+ devicetree representation corresponds to the one commonly found in datasheets
+ for panels. If a panel supports multiple signal timings, the native-mode
+ can be specified.
+
+ The parameters are defined as seen in the following illustration.
+
+ +--+-+--+---+
+ | |^| | |
+ | ||vback_porch | | |
+ | |v| | |
+ +--###--+---+
+ | #^# | |
+ | #|# | |
+ | hback #|# hfront | hsync |
+ | porch #| hactive # porch | len |
+ |<>#<---+--->#<>|<->|
+ | #|# | |
+ | #|vactive # | |
+ | #|# | |
+ | #v# | |
+ +--###--+---+
+ | |^| | |
+ | ||vfront_porch| | |
+ | |v| | |
+ +--+-+--+---+
+ | |^| | |
+ | ||vsync_len | | |
+ | |v| | |
+ +--+-+--+---+
+
+
+ The following is the panel timings shown with time on the x-axis.
+ This matches the timing diagrams often found in data sheets.
+
+ Active Front Sync Back
+ Region
[PATCH] drm/amd/powerplay: fix spelling mistake "Attemp" -> "Attempt"
From: Colin Ian King
There are several spelling mistakes in PP_ASSERT_WITH_CODE messages.
Fix these.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c | 12 ++--
drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c | 12 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c
index a3915bfcce81..275dbf65f1a0 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c
@@ -128,20 +128,20 @@ int vega12_enable_smc_features(struct pp_hwmgr *hwmgr,
if (enable) {
PP_ASSERT_WITH_CODE(smu9_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_EnableSmuFeaturesLow,
smu_features_low) == 0,
- "[EnableDisableSMCFeatures] Attemp to enable
SMU features Low failed!",
+ "[EnableDisableSMCFeatures] Attempt to enable
SMU features Low failed!",
return -EINVAL);
PP_ASSERT_WITH_CODE(smu9_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_EnableSmuFeaturesHigh,
smu_features_high) == 0,
- "[EnableDisableSMCFeatures] Attemp to enable
SMU features High failed!",
+ "[EnableDisableSMCFeatures] Attempt to enable
SMU features High failed!",
return -EINVAL);
} else {
PP_ASSERT_WITH_CODE(smu9_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_DisableSmuFeaturesLow,
smu_features_low) == 0,
- "[EnableDisableSMCFeatures] Attemp to disable
SMU features Low failed!",
+ "[EnableDisableSMCFeatures] Attempt to disable
SMU features Low failed!",
return -EINVAL);
PP_ASSERT_WITH_CODE(smu9_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_DisableSmuFeaturesHigh,
smu_features_high) == 0,
- "[EnableDisableSMCFeatures] Attemp to disable
SMU features High failed!",
+ "[EnableDisableSMCFeatures] Attempt to disable
SMU features High failed!",
return -EINVAL);
}
@@ -158,13 +158,13 @@ int vega12_get_enabled_smc_features(struct pp_hwmgr
*hwmgr,
PP_ASSERT_WITH_CODE(smu9_send_msg_to_smc(hwmgr,
PPSMC_MSG_GetEnabledSmuFeaturesLow) == 0,
- "[GetEnabledSMCFeatures] Attemp to get SMU features Low
failed!",
+ "[GetEnabledSMCFeatures] Attempt to get SMU features
Low failed!",
return -EINVAL);
smc_features_low = smu9_get_argument(hwmgr);
PP_ASSERT_WITH_CODE(smu9_send_msg_to_smc(hwmgr,
PPSMC_MSG_GetEnabledSmuFeaturesHigh) == 0,
- "[GetEnabledSMCFeatures] Attemp to get SMU features
High failed!",
+ "[GetEnabledSMCFeatures] Attempt to get SMU features
High failed!",
return -EINVAL);
smc_features_high = smu9_get_argument(hwmgr);
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c
index 0db57fb83d30..49e5ef3e3876 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c
@@ -316,20 +316,20 @@ int vega20_enable_smc_features(struct pp_hwmgr *hwmgr,
if (enable) {
PP_ASSERT_WITH_CODE((ret =
vega20_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_EnableSmuFeaturesLow,
smu_features_low)) == 0,
- "[EnableDisableSMCFeatures] Attemp to enable
SMU features Low failed!",
+ "[EnableDisableSMCFeatures] Attempt to enable
SMU features Low failed!",
return ret);
PP_ASSERT_WITH_CODE((ret =
vega20_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_EnableSmuFeaturesHigh,
smu_features_high)) == 0,
- "[EnableDisableSMCFeatures] Attemp to enable
SMU features High failed!",
+ "[EnableDisableSMCFeatures] Attempt to enable
SMU features High failed!",
return ret);
} else {
PP_ASSERT_WITH_CODE((ret =
vega20_send_msg_to_smc_with_parameter(hwmgr,
PPSMC_MSG_DisableSmuFeaturesLow,
smu_features_low)) == 0,
- "[EnableDisableSMCFeatures] Attemp to disable
SMU features Low failed!",
+ "[EnableDisableSMCFeatures] Attempt to disable
SM
Re: [PATCH v1 3/3] dt-bindings: display: convert panel-dpi to DT schema
Hi Rob.
On Tue, Jan 21, 2020 at 08:50:25AM -0600, Rob Herring wrote:
> On Mon, Jan 20, 2020 at 2:07 PM Sam Ravnborg wrote:
> >
> > With panel-timing converted, now convert the single
> > remaining .txt user in panel/ of panel-timing to DT schema.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Rob Herring
> > Cc: Thierry Reding
> > Cc: Laurent Pinchart
> > Cc: Maxime Ripard
> > ---
> > .../bindings/display/panel/panel-dpi.txt | 50 -
> > .../bindings/display/panel/panel-dpi.yaml | 71 +++
> > 2 files changed, 71 insertions(+), 50 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/display/panel/panel-dpi.txt
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
>
> [...]
>
> > diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> > b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> > new file mode 100644
> > index ..4e19c1fd52c3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> > @@ -0,0 +1,71 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/panel-dpi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Generic MIPI DPI Panel
> > +
> > +maintainers:
> > + - Sam Ravnborg
> > + - Thierry Reding
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +contains:
> > + const: panel-dpi
> > +description:
> > + Shall contain "panel-dpi" in addition to a mandatory panel-specific
> > + compatible string defined in individual panel bindings. The
> > "panel-dpi"
> > + value shall never be used on its own.
>
> Yet we have 3 cases where it is...
>
> A 'minItems: 2' should be enough to catch these. Or do:
The above was a verbatim copy from another binding.
Thinking more about this I went with this:
compatible:
contains:
const: panel-dpi
description:
Shall contain "panel-dpi" in addition to an optional panel-specific
compatible string defined in individual panel bindings.
"panel-dpi" can be used alone, thus no dedicated binding file
is required for each and every panel.
So a DT file with:
panel@0 {
compatible = "panel-dpi";
...
panel-timing {
...
};
Is in many cases enough - and then people do not have
to either cheat or wait until their panel is included in the kernel.
The panel market i big, and there are new panels each and every day.
With panel-dpi we can support the dumb panels that
do not require any special delays etc.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/3] dt-bindings: display: add panel-timing.yaml
Hi Oleksandr Thanks for the feedback on the typos. > > Anyway, those are minor issues, so > > Reviewed-by: Oleksandr Suvorov I did a number of other changes so I dropped this r-b, as you really did not review the v2 version. v2 coming later today. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/3] dt-bindings: display: add panel-timing.yaml
Hi Maxime. Thanks for your comments! > > > + - allOf: > > +- $ref: /schemas/types.yaml#/definitions/uint32-array > > +- minItems: 3 > > + maxItems: 3 > > + items: > > +description: min, typ, max number of pixels > > When minItems and maxitems are equal, you can just set one, the other > one will be filled by the DT schemas tools. I tried to drop minItems: 3 But it just did not work - I could not make it accept and . And the schema should, and does, reject and I do not know why - I just did a trial-and-error on this. > > + hsync-active: > > +description: | > > + Horizontal sync pulse. > > + If omitted then it is not used by the hardware > > +oneOf: > > + - const: 0 > > +description: active low > > + - const: 1 > > +description: active high > > You probably should use an enum here (and in other similar > places). oneOf / anyOf / allOF errors are pretty cryptic, while it > will it's really better with an enum. Yep - enum: [0, 1] is much nicer. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: add binding for Ilitek ili9486 based display panels
Den 25.01.2020 16.38, skrev Kamlesh Gurudasani:
> Signed-off-by: Kamlesh Gurudasani
> ---
> .../devicetree/bindings/display/ilitek,ili9486.txt | 27
> ++
For version 2, send the patchset to the devicetree mailinglist as well.
A DT maintainer has to review it. Send the whole set since he wants to
look at the driver as well.
See: Documentation/devicetree/bindings/submitting-patches.txt
Looks like bindings are in yaml format now.
> 1 file changed, 27 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/ilitek,ili9486.txt
>
> diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9486.txt
> b/Documentation/devicetree/bindings/display/ilitek,ili9486.txt
> new file mode 100644
> index 000..51c8196
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/ilitek,ili9486.txt
> @@ -0,0 +1,27 @@
> +Ilitek ILI9486 display panels
> +
> +This binding is for display panels using an Ilitek ILI9486 controller in SPI
> +mode.
> +
> +Required properties:
> +- compatible: "ozzmaker,piscreen", "waveshare,rpi-lcd-35", "ilitek,ili9486"
Drop the last entry since it doesn't make any sense since the controller
won't work without being initialized (it would make sense if we could
read out from the controller which panel is connected). And the driver
doesn't support this compatible either.
I assume that ozzmaker and waveshare needs to be added to
bindings/vendor-prefixes.yaml, and that would be as a separate patch.
> +- dc-gpios: D/C pin
> +- reset-gpios: Reset pin
Both these are optional in the driver.
> +
> +The node for this driver must be a child node of a SPI controller, hence
> +all mandatory properties described in ../spi/spi-bus.txt must be specified.
> +
> +Optional properties:
> +- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
> +- backlight:phandle of the backlight device attached to the panel
> +
> +Example:
> +display@0{
> +compatible = "ozzmaker,piscreen", "waveshare,rpi-lcd-35",
> "ilitek,ili9486";
Pick only one compatible for the example.
Noralf.
> +reg = <0>;
> +spi-max-frequency = <3200>;
> +dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
> +reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
> +rotation = <180>;
> +backlight = <&backlight>;
> +};
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/tinydrm: add support for ilitek,ili9486 based displays with regwidth=16
Hi Kamlesh,
Nice to see this driver, this means I can now drop the piscreen driver
from the out-of-tree tinydrm repo.
Den 25.01.2020 16.38, skrev Kamlesh Gurudasani:
> This adds support fot ilitek,ili9486 based display with shift register in
> front
s/fot/for/
> of controller, basically with regwidth=16
The last part of this sentence only makes sense for people that know
fbtft. Either add a reference to fbtft or just drop it.
>
> Signed-off-by: Kamlesh Gurudasani
> ---
> diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
> index a46ac28..fe135cd 100644
> --- a/drivers/gpu/drm/tiny/Kconfig
> +++ b/drivers/gpu/drm/tiny/Kconfig
> @@ -47,6 +47,20 @@ config TINYDRM_ILI9341
>
> If M is selected the module will be called ili9341.
>
> +config TINYDRM_ILI9486
> + tristate "DRM support for ILI9486 display panels"
> + depends on DRM && SPI
> + select DRM_KMS_HELPER
> + select DRM_KMS_CMA_HELPER
> + select DRM_MIPI_DBI
> + select BACKLIGHT_CLASS_DEVICE
> + help
> + DRM driver for the following Ilitek ILI486 panels:
s/ILI486/ILI9486/
> + * PISCREEN 3.5" 320x480 TFT (Ozzmaker 3.5")
> + * RPILCD 3.5" 320x480 TFT (Waveshare 3.5")
> +
> + If M is selected the module will be called ili9486.
> +
> config TINYDRM_MI0283QT
> tristate "DRM support for MI0283QT"
> depends on DRM && SPI
> diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
> index 896cf31..1f8a0f0 100644
> --- a/drivers/gpu/drm/tiny/Makefile
> +++ b/drivers/gpu/drm/tiny/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_TINYDRM_MI0283QT)+= mi0283qt.o
> obj-$(CONFIG_TINYDRM_REPAPER)+= repaper.o
> obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
> obj-$(CONFIG_TINYDRM_ST7735R)+= st7735r.o
> +obj-$(CONFIG_TINYDRM_ILI9486)+= ili9486.o
Please keep the entries sorted alphabetically.
> diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
> new file mode 100644
> index 000..bed83b0
> --- /dev/null
> +++ b/drivers/gpu/drm/tiny/ili9486.c
> @@ -0,0 +1,288 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * DRM driver for Ilitek ILI9486 panels
> + *
> + * Copyright 2018 Kamlesh Gurudasani
2020?
> + *
> + * Some code copied from mipi-dbi.c
> + * Copyright 2016 Noralf Tronnes
You can drop this last paragraph, I see that you've copied it from
ili9225, but these tiny drivers are just more or less boilerplate
drivers with very little special stuff.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define ILI9486_ITFCTR1 0xb0
> +#define ILI9486_PWCTRL1 0xc2
> +#define ILI9486_VMCTRL1 0xc5
> +#define ILI9486_PGAMCTRL0xe0
> +#define ILI9486_NGAMCTRL0xe1
> +#define ILI9486_DGAMCTRL0xe2
> +#define ILI9486_MADCTL_BGR BIT(3)
> +#define ILI9486_MADCTL_MV BIT(5)
> +#define ILI9486_MADCTL_MX BIT(6)
> +#define ILI9486_MADCTL_MY BIT(7)
> +
> +/*
> + * The PiScreen/waveshare rpi-lcd-35 has a SPI to 16-bit parallel bus
> converter
> + * in front of the display controller. This means that 8-bit values has to
> be
s/has/have/
> + * transferred as 16-bit.
> + */
> +static int ili9486_command(struct mipi_dbi *mipi, u8 *cmd, u8 *par, size_t
> num)
The function name here is misleading, the ili9486 can use the default in
drm_mipi_dbi when used in SPI mode, so you should name it
piscreen_command or waveshare_command since it's special for those displays.
> +{
> + struct spi_device *spi = mipi->spi;
> + void *data = par;
> + u32 speed_hz;
> + unsigned int bpw = 8;
> + int i, ret;
> + u16 *buf;
> +
> + buf = kmalloc(32 * sizeof(u16), GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + /*
> + * The Raspberry Pi supports only 8-bit on the DMA capable SPI
> + * controller and is little endian, so byte swapping is needed.
> + */
I found this comment a bit confusing at first, then I realised that I
wrote it myself in the piscreen driver. I think we should expand a
little here to make it clear that these displays are made for the Pi.
Maybe something like this:
The displays are Raspberry Pi HATs and connected to the 8-bit only SPI
controller so 16-bit command and parameters need byte swapping before
being transferred as 8-bit on the big endian SPI bus.
Pixel data bytes have already been swapped before this function is called.
> + buf[0] = cpu_to_be16(*cmd);
> + gpiod_set_value_cansleep(mipi->dc, 0);
> + speed_hz = mipi_dbi_spi_cmd_max_speed(spi, 2);
> + ret = mipi_dbi_spi_transfer(spi, speed_hz, bpw, buf, 2);
You don't change bpw, so you can drop the variable and use the value
directly.
> + if (ret || !num)
> + goto free;
> +
> + /* 8-bit configurati
Re: [PATCH 0/2] drm/i915/gem: conversion to new drm logging macros
Quoting Wambui Karuga (2020-01-22 12:57:48) > This series is a part of the conversion to the new struct drm_device > based logging macros in drm/i915. > This series focuses on the drm/i915/gem directory and converts all > straightforward instances of the printk based logging macros to the new > macros. Overall, I'm not keen on this as it perpetuates the mistake of putting client debug message in dmesg and now gives them even more an air of being device driver debug messages. We need a mechanism by which we report the details of what a client did wrong back to that client (tracefs + context/client getparam to return an isolated debug fd is my idea). > Wambui Karuga (2): > drm/i915/gem: initial conversion to new logging macros using > coccinelle. > drm/i915/gem: manual conversion to struct drm_device logging macros. Still this is a necessary evil for the current situation, Acked-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/4] drm/tiny/repaper: Make driver OF-independent
On Fri, Jan 24, 2020 at 05:42:33PM +0100, Sam Ravnborg wrote:
> On Wed, Jan 22, 2020 at 12:54:00PM +0200, Andy Shevchenko wrote:
> > There is one OF call in the driver that limits its area of use.
> > Replace it to generic device_get_match_data() and get rid of OF dependency.
> >
> > While here, cast SPI driver data to certain enumerator type.
> > enum repaper_model {
> > + ECSXXX = 0,
> > E1144CS021 = 1,
> > E1190CS021,
> > E2200CS021,
> The new enum value is not used in the following - is it necessary?
Yes. It explicitly prevents to use 0 for real device.
This is due to device_get_match_data() returns content of data pointer and thus
we may not distinguish 0 from NULL pointer.
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] uaccess: Tell user_access_begin() if it's for a write or not
On Thu, Jan 23, 2020 at 10:03 AM Linus Torvalds wrote: > We used to have a read/write argument to the old "verify_area()" and > "access_ok()" model, and it was a mistake. It was due to odd i386 user > access issues. We got rid of it. I'm not convinced this is any better > - it looks very similar and for odd ppc access issues. If the mode (read or write) were made visible to the trap handler, I'd find that useful for machine check recovery. If I'm in the middle of a copy_from_user() and I get a machine check reading poison from a user address ... then I could try to recover in the same way as for the user accessing the poison (offline the page, SIGBUS the task). But if the poison is in kernel memory and we are doing a copy_to_user(), then we are hosed (or would need some more complex recovery plan). [Note that we only get recoverable machine checks on loads... writes are posted, so if something goes wrong it isn't synchronous with the store instruction that initiated it] -Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] amdgpu: use dma-resv API instead of manual kmalloc
And of course I forgot this is an internal API, so this doesn't work
without some of other stuff which isn't ready.
Please ignore...
Regards,
Stephen
Le 25/01/2020 12:46, Stephen Kitt a écrit :
Instead of hand-coding the dma_resv_list allocation, use
dma_resv_list_alloc, which masks the shared_max handling. While we're
at it, since we only need shared_count fences, allocate shared_count
fences rather than shared_max.
(This is the only place in the kernel, outside of dma-resv.c, which
touches shared_max. This suggests we'd probably be better off without
it!)
Signed-off-by: Stephen Kitt
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 888209eb8cec..aec595752200 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -234,12 +234,11 @@ static int
amdgpu_amdkfd_remove_eviction_fence(struct amdgpu_bo *bo,
if (!old)
return 0;
- new = kmalloc(offsetof(typeof(*new), shared[old->shared_max]),
- GFP_KERNEL);
+ new = dma_resv_list_alloc(old->shared_count);
if (!new)
return -ENOMEM;
- /* Go through all the shared fences in the resevation object and sort
+ /* Go through all the shared fences in the reservation object and
sort
* the interesting ones to the end of the list.
*/
for (i = 0, j = old->shared_count, k = 0; i < old->shared_count; ++i)
{
@@ -253,7 +252,6 @@ static int
amdgpu_amdkfd_remove_eviction_fence(struct amdgpu_bo *bo,
else
RCU_INIT_POINTER(new->shared[k++], f);
}
- new->shared_max = old->shared_max;
new->shared_count = k;
/* Install the new fence list, seqcount provides the barriers */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/a6xx: Correct the highestbank configuration
Highest bank bit configuration is different for a618 gpu. Update
it with the correct configuration which is the reset value incidentally.
Signed-off-by: Akhil P Oommen
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index daf0780..536d196 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -470,10 +470,12 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
/* Select CP0 to always count cycles */
gpu_write(gpu, REG_A6XX_CP_PERFCTR_CP_SEL_0, PERF_CP_ALWAYS_COUNT);
- gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL, 2 << 1);
- gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, 2 << 1);
- gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL, 2 << 1);
- gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, 2 << 21);
+ if (adreno_is_a630(adreno_gpu)) {
+ gpu_write(gpu, REG_A6XX_RB_NC_MODE_CNTL, 2 << 1);
+ gpu_write(gpu, REG_A6XX_TPL1_NC_MODE_CNTL, 2 << 1);
+ gpu_write(gpu, REG_A6XX_SP_NC_MODE_CNTL, 2 << 1);
+ gpu_write(gpu, REG_A6XX_UCHE_MODE_CNTL, 2 << 21);
+ }
/* Enable fault detection */
gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] amdgpu: use dma-resv API instead of manual kmalloc
Instead of hand-coding the dma_resv_list allocation, use
dma_resv_list_alloc, which masks the shared_max handling. While we're
at it, since we only need shared_count fences, allocate shared_count
fences rather than shared_max.
(This is the only place in the kernel, outside of dma-resv.c, which
touches shared_max. This suggests we'd probably be better off without
it!)
Signed-off-by: Stephen Kitt
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 888209eb8cec..aec595752200 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -234,12 +234,11 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct
amdgpu_bo *bo,
if (!old)
return 0;
- new = kmalloc(offsetof(typeof(*new), shared[old->shared_max]),
- GFP_KERNEL);
+ new = dma_resv_list_alloc(old->shared_count);
if (!new)
return -ENOMEM;
- /* Go through all the shared fences in the resevation object and sort
+ /* Go through all the shared fences in the reservation object and sort
* the interesting ones to the end of the list.
*/
for (i = 0, j = old->shared_count, k = 0; i < old->shared_count; ++i) {
@@ -253,7 +252,6 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct
amdgpu_bo *bo,
else
RCU_INIT_POINTER(new->shared[k++], f);
}
- new->shared_max = old->shared_max;
new->shared_count = k;
/* Install the new fence list, seqcount provides the barriers */
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 5/7] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
Hi Artur,
On 1/24/20 13:22, Artur Świgoń wrote:
> Hi Georgi,
>
> On Wed, 2020-01-22 at 19:02 +0200, Georgi Djakov wrote:
>> Hi Artur,
>>
>> On 12/20/19 13:56, Artur Świgoń wrote:
>>> This patch adds interconnect functionality to the exynos-bus devfreq
>>> driver.
>>>
>>> The SoC topology is a graph (or, more specifically, a tree) and its
>>> edges are specified using the 'exynos,interconnect-parent-node' in the
>>> DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
>>> propagated to ensure that the parent is probed before its children.
>>>
>>> Each bus is now an interconnect provider and an interconnect node as well
>>> (cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers
>>> itself as a node. Node IDs are not hardcoded but rather assigned at
>>
>> Just to note that usually the provider consists of multiple nodes and each
>> node
>> represents a single master or slave port on the AXI bus for example. I am not
>> sure whether this represents correctly the Exynos hardware, so it's up to
>> you.
>>
>>> runtime, in probing order (subject to the above-mentioned exception
>>> regarding relative order). This approach allows for using this driver with
>>> various Exynos SoCs.
>>
>> This sounds good. I am wondering whether such dynamic probing would be useful
>> for other platforms too. Then maybe it would make sense to even have a
>> common DT
>> property, but we will see.
>>
>> Is this going to be used only together with devfreq?
>
> Yes, this functions solely as an extension to devfreq, hence the slightly
> unusual architecture (one icc_provider/icc_node per devfreq).
Ok, thanks for clarifying.
> (Compared to a singleton icc_provider, this approach yields less code with
> a very simple xlate()).
>
> With exactly one icc_node for every devfreq device, I think I will actually
> reuse the devfreq ID (as seen in the device name, e.g. the "3" in "devfreq3")
> for the node ID. The devfreq framework already does the dynamic numbering
> thing that I do in this patch using IDR.
>
Sounds good.
>>> Frequencies requested via the interconnect API for a given node are
>>> propagated to devfreq using dev_pm_qos_update_request(). Please note that
>>> it is not an error when CONFIG_INTERCONNECT is 'n', in which case all
>>> interconnect API functions are no-op.
>>
>> How about the case where CONFIG_INTERCONNECT=m. Looks like the build will
>> fail
>> if CONFIG_ARM_EXYNOS_BUS_DEVFREQ=y, so this dependency should be expressed in
>> Kconfig.
>
> I think adding:
> depends on INTERCONNECT || !INTERCONNECT
Yes, exactly.
> under ARM_EXYNOS_BUS_DEVFREQ does the trick.
>
>>>
>>> Signed-off-by: Artur Świgoń
>>> ---
>>> drivers/devfreq/exynos-bus.c | 144 +++
>>> 1 file changed, 144 insertions(+)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 9fdb188915e8..694a9581dcdb 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -14,14 +14,19 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>>
>>> #define DEFAULT_SATURATION_RATIO 40
>>>
>>> +#define kbps_to_khz(x) ((x) / 8)
>>> +
>>> struct exynos_bus {
>>> struct device *dev;
>>>
>>> @@ -35,6 +40,12 @@ struct exynos_bus {
>>> struct opp_table *opp_table;
>>> struct clk *clk;
>>> unsigned int ratio;
>>> +
>>> + /* One provider per bus, one node per provider */
>>> + struct icc_provider provider;
>>> + struct icc_node *node;
>>> +
>>> + struct dev_pm_qos_request qos_req;
>>> };
>>>
>>> /*
>>> @@ -205,6 +216,39 @@ static void exynos_bus_passive_exit(struct device *dev)
>>> clk_disable_unprepare(bus->clk);
>>> }
>>>
>>> +static int exynos_bus_icc_set(struct icc_node *src, struct icc_node *dst)
>>> +{
>>> + struct exynos_bus *src_bus = src->data, *dst_bus = dst->data;
>>> + s32 src_freq = kbps_to_khz(src->avg_bw);
>>> + s32 dst_freq = kbps_to_khz(dst->avg_bw);
>>> + int ret;
>>> +
>>> + ret = dev_pm_qos_update_request(&src_bus->qos_req, src_freq);
>>> + if (ret < 0) {
>>> + dev_err(src_bus->dev, "failed to update PM QoS request");
>>> + return ret;
>>> + }
>>> +
>>> + ret = dev_pm_qos_update_request(&dst_bus->qos_req, dst_freq);
>>> + if (ret < 0) {
>>> + dev_err(dst_bus->dev, "failed to update PM QoS request");
>>> + return ret;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static struct icc_node *exynos_bus_icc_xlate(struct of_phandle_args *spec,
>>> +void *data)
>>> +{
>>> + struct exynos_bus *bus = data;
>>> +
>>> + if (spec->np != bus->dev->of_node)
>>> + return ERR_PTR(-EINVAL);
>>> +
>>> + return bus->node;
>>> +}
>>> +
>>> static int exynos_bus_parent_parse_of(struct device_node *np,
>>> struct exynos_
Re: [PATCH v1 2/4] drm/tiny/repaper: No need to set ->owner for spi_register_driver()
On Fri, Jan 24, 2020 at 06:06:37PM +0100, Sam Ravnborg wrote: > Hi Andy. > > On Wed, Jan 22, 2020 at 12:54:01PM +0200, Andy Shevchenko wrote: > > The spi_register_driver() will set the ->owner member to THIS_MODULE. > > > > Signed-off-by: Andy Shevchenko > > Reviewed-by: Sam Ravnborg Thanks. > Any chance you will update the remaining 3 drivers in drm/tiny/ > that has the same unessesary assignment? Maybe. -- With Best Regards, Andy Shevchenko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 5/7] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
Hi Georgi,
On Wed, 2020-01-22 at 19:02 +0200, Georgi Djakov wrote:
> Hi Artur,
>
> On 12/20/19 13:56, Artur Świgoń wrote:
> > This patch adds interconnect functionality to the exynos-bus devfreq
> > driver.
> >
> > The SoC topology is a graph (or, more specifically, a tree) and its
> > edges are specified using the 'exynos,interconnect-parent-node' in the
> > DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
> > propagated to ensure that the parent is probed before its children.
> >
> > Each bus is now an interconnect provider and an interconnect node as well
> > (cf. Documentation/interconnect/interconnect.rst), i.e. every bus registers
> > itself as a node. Node IDs are not hardcoded but rather assigned at
>
> Just to note that usually the provider consists of multiple nodes and each
> node
> represents a single master or slave port on the AXI bus for example. I am not
> sure whether this represents correctly the Exynos hardware, so it's up to
> you.
>
> > runtime, in probing order (subject to the above-mentioned exception
> > regarding relative order). This approach allows for using this driver with
> > various Exynos SoCs.
>
> This sounds good. I am wondering whether such dynamic probing would be useful
> for other platforms too. Then maybe it would make sense to even have a common
> DT
> property, but we will see.
>
> Is this going to be used only together with devfreq?
Yes, this functions solely as an extension to devfreq, hence the slightly
unusual architecture (one icc_provider/icc_node per devfreq).
(Compared to a singleton icc_provider, this approach yields less code with
a very simple xlate()).
With exactly one icc_node for every devfreq device, I think I will actually
reuse the devfreq ID (as seen in the device name, e.g. the "3" in "devfreq3")
for the node ID. The devfreq framework already does the dynamic numbering
thing that I do in this patch using IDR.
> > Frequencies requested via the interconnect API for a given node are
> > propagated to devfreq using dev_pm_qos_update_request(). Please note that
> > it is not an error when CONFIG_INTERCONNECT is 'n', in which case all
> > interconnect API functions are no-op.
>
> How about the case where CONFIG_INTERCONNECT=m. Looks like the build will fail
> if CONFIG_ARM_EXYNOS_BUS_DEVFREQ=y, so this dependency should be expressed in
> Kconfig.
I think adding:
depends on INTERCONNECT || !INTERCONNECT
under ARM_EXYNOS_BUS_DEVFREQ does the trick.
> >
> > Signed-off-by: Artur Świgoń
> > ---
> > drivers/devfreq/exynos-bus.c | 144 +++
> > 1 file changed, 144 insertions(+)
> >
> > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > index 9fdb188915e8..694a9581dcdb 100644
> > --- a/drivers/devfreq/exynos-bus.c
> > +++ b/drivers/devfreq/exynos-bus.c
> > @@ -14,14 +14,19 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > #define DEFAULT_SATURATION_RATIO 40
> >
> > +#define kbps_to_khz(x) ((x) / 8)
> > +
> > struct exynos_bus {
> > struct device *dev;
> >
> > @@ -35,6 +40,12 @@ struct exynos_bus {
> > struct opp_table *opp_table;
> > struct clk *clk;
> > unsigned int ratio;
> > +
> > + /* One provider per bus, one node per provider */
> > + struct icc_provider provider;
> > + struct icc_node *node;
> > +
> > + struct dev_pm_qos_request qos_req;
> > };
> >
> > /*
> > @@ -205,6 +216,39 @@ static void exynos_bus_passive_exit(struct device *dev)
> > clk_disable_unprepare(bus->clk);
> > }
> >
> > +static int exynos_bus_icc_set(struct icc_node *src, struct icc_node *dst)
> > +{
> > + struct exynos_bus *src_bus = src->data, *dst_bus = dst->data;
> > + s32 src_freq = kbps_to_khz(src->avg_bw);
> > + s32 dst_freq = kbps_to_khz(dst->avg_bw);
> > + int ret;
> > +
> > + ret = dev_pm_qos_update_request(&src_bus->qos_req, src_freq);
> > + if (ret < 0) {
> > + dev_err(src_bus->dev, "failed to update PM QoS request");
> > + return ret;
> > + }
> > +
> > + ret = dev_pm_qos_update_request(&dst_bus->qos_req, dst_freq);
> > + if (ret < 0) {
> > + dev_err(dst_bus->dev, "failed to update PM QoS request");
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static struct icc_node *exynos_bus_icc_xlate(struct of_phandle_args *spec,
> > +void *data)
> > +{
> > + struct exynos_bus *bus = data;
> > +
> > + if (spec->np != bus->dev->of_node)
> > + return ERR_PTR(-EINVAL);
> > +
> > + return bus->node;
> > +}
> > +
> > static int exynos_bus_parent_parse_of(struct device_node *np,
> > struct exynos_bus *bus)
> > {
> > @@ -419,6 +463,96 @@ static int exynos_bus_profile_init_passive(struct
> > exynos_bus *bus,
> > return 0;
> > }
> >
> > +static s
Re: [v5,3/3] drm/i915: Add support for integrated privacy screens
On Fri, Dec 20, 2019 at 12:03:53PM -0800, Rajat Jain wrote:
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the intel_connector for the panel, that
> the userspace can then use to control and check the status.
>
> Identifying the presence of privacy screen, and controlling it, is done
> via ACPI _DSM methods.
>
> Currently, this is done only for the Intel display ports. But in future,
> this can be done for any other ports if the hardware becomes available
> (e.g. external monitors supporting integrated privacy screens?).
>
> Signed-off-by: Rajat Jain
> ---
> v5: fix a cosmetic checkpatch warning
> v4: Fix a typo in intel_privacy_screen.h
> v3: * Change license to GPL-2.0 OR MIT
> * Move privacy screen enum from UAPI to intel_display_types.h
> * Rename parameter name and some other minor changes.
> v2: Formed by splitting the original patch into multiple patches.
> - All code has been moved into i915 now.
> - Privacy screen is a i915 property
> - Have a local state variable to store the prvacy screen. Don't read
> it from hardware.
>
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/display/intel_atomic.c | 13 +++-
> .../gpu/drm/i915/display/intel_connector.c| 35 +
> .../gpu/drm/i915/display/intel_connector.h| 1 +
> .../drm/i915/display/intel_display_types.h| 18 +
> drivers/gpu/drm/i915/display/intel_dp.c | 6 ++
> .../drm/i915/display/intel_privacy_screen.c | 72 +++
> .../drm/i915/display/intel_privacy_screen.h | 27 +++
> 8 files changed, 171 insertions(+), 4 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_privacy_screen.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 90dcf09f52cc..f7067c8f0407 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -197,7 +197,8 @@ i915-y += \
> display/intel_vga.o
> i915-$(CONFIG_ACPI) += \
> display/intel_acpi.o \
> - display/intel_opregion.o
> + display/intel_opregion.o \
> + display/intel_privacy_screen.o
> i915-$(CONFIG_DRM_FBDEV_EMULATION) += \
> display/intel_fbdev.o
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index c2875b10adf9..c73b81c4c3f6 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -37,6 +37,7 @@
> #include "intel_atomic.h"
> #include "intel_display_types.h"
> #include "intel_hdcp.h"
> +#include "intel_privacy_screen.h"
> #include "intel_sprite.h"
>
> /**
> @@ -57,11 +58,14 @@ int intel_digital_connector_atomic_get_property(struct
> drm_connector *connector,
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_digital_connector_state *intel_conn_state =
> to_intel_digital_connector_state(state);
> + struct intel_connector *intel_connector = to_intel_connector(connector);
>
> if (property == dev_priv->force_audio_property)
> *val = intel_conn_state->force_audio;
> else if (property == dev_priv->broadcast_rgb_property)
> *val = intel_conn_state->broadcast_rgb;
> + else if (property == intel_connector->privacy_screen_property)
> + *val = intel_conn_state->privacy_screen_status;
> else {
> DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
>property->base.id, property->name);
> @@ -89,15 +93,18 @@ int intel_digital_connector_atomic_set_property(struct
> drm_connector *connector,
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_digital_connector_state *intel_conn_state =
> to_intel_digital_connector_state(state);
> + struct intel_connector *intel_connector = to_intel_connector(connector);
>
> if (property == dev_priv->force_audio_property) {
> intel_conn_state->force_audio = val;
> return 0;
> - }
> -
> - if (property == dev_priv->broadcast_rgb_property) {
> + } else if (property == dev_priv->broadcast_rgb_property) {
> intel_conn_state->broadcast_rgb = val;
> return 0;
> + } else if (property == intel_connector->privacy_screen_property) {
> + intel_privacy_screen_set_val(intel_connector, val);
> + intel_conn_state->privacy_screen_status = val;
> + return 0;
> }
>
> DRM_DEBUG_ATOMIC("Unknown property [PROP:%d:%s]\n",
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
> b/drivers/gpu/drm/i915/display/intel_connector.c
> index 1133c4e97bb4..f3e041c737de 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.c
> +++ b/drivers/gpu/drm/i91
[v3] arm64: dts: sc7180: add display dt nodes
Add display, DSI hardware DT nodes for sc7180.
Signed-off-by: Harigovindan P
---
Changes in v1:
-Added display DT nodes for sc7180
Changes in v2:
-Renamed node names
-Corrected code alignments
-Removed extra new line
-Added DISP AHB clock for register access
under display_subsystem node for global settings
Changes in v3:
-Modified node names
-Modified hard coded values
-Removed mdss reg entry
arch/arm64/boot/dts/qcom/sc7180-idp.dts | 58 +++
arch/arm64/boot/dts/qcom/sc7180.dtsi| 124
2 files changed, 182 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
index 388f50a..c77aab7 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
@@ -7,6 +7,7 @@
/dts-v1/;
+#include
#include
#include "sc7180.dtsi"
#include "pm6150.dtsi"
@@ -232,6 +233,50 @@
};
};
+&dsi_controller {
+ status = "okay";
+
+ vdda-supply = <&vreg_l3c_1p2>;
+
+ panel@0 {
+ compatible = "visionox,rm69299-1080p-display";
+ reg = <0>;
+
+ vdda-supply = <&vreg_l8c_1p8>;
+ vdd3p3-supply = <&vreg_l18a_2p8>;
+
+ pinctrl-names = "default", "suspend";
+ pinctrl-0 = <&disp_pins_default>;
+ pinctrl-1 = <&disp_pins_default>;
+
+ reset-gpios = <&pm6150l_gpio 3 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ panel0_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&panel0_in>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+&dsi_phy {
+ status = "okay";
+};
+
&qspi {
status = "okay";
pinctrl-names = "default";
@@ -289,6 +334,19 @@
/* PINCTRL - additions to nodes defined in sc7180.dtsi */
+&pm6150l_gpio {
+ disp_pins {
+ disp_pins_default: disp_pins_default{
+ pins = "gpio3";
+ function = "func1";
+ qcom,drive-strength = <2>;
+ power-source = <0>;
+ bias-disable;
+ output-low;
+ };
+ };
+};
+
&qspi_clk {
pinconf {
pins = "gpio63";
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 3bc3f64..3ebc45b 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1184,6 +1184,130 @@
#power-domain-cells = <1>;
};
+ mdss: display_subsystem@ae0 {
+ compatible = "qcom,sc7180-mdss";
+ reg = <0 0x0ae0 0 0x1000>;
+ reg-names = "mdss";
+
+ power-domains = <&dispcc MDSS_GDSC>;
+
+ clocks = <&gcc GCC_DISP_AHB_CLK>,
+<&gcc GCC_DISP_HF_AXI_CLK>,
+<&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_MDP_CLK>;
+ clock-names = "iface", "gcc_bus", "ahb", "core";
+
+ assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
+ assigned-clock-rates = <3>;
+
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ iommus = <&apps_smmu 0x800 0x2>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ mdp: display_controller@ae01000 {
+ compatible = "qcom,sc7180-dpu";
+ reg = <0 0x0ae01000 0 0x8f000>,
+ <0 0x0aeb 0 0x2008>,
+ <0 0x0af03000 0 0x16>;
+ reg-names = "mdp", "vbif", "disp_cc";
+
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+<&dispcc DISP_CC_MDSS_ROT_CLK>,
+<&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
+<&dispcc DISP_CC_MDSS_MDP_CLK>,
+<&dispcc DISP_CC_MDSS_VSYNC_CLK>;
+ clock-names = "iface", "rot"
Re: [PATCH] drm/amd/display: do not allocate display_mode_lib unnecessarily
On Fri, Jan 17, 2020 at 12:59 PM Dor Askayo wrote:
>
> On Sat, Jan 4, 2020 at 2:23 PM Dor Askayo wrote:
> >
> > This allocation isn't required and can fail when resuming from suspend.
> >
> > Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009
> > Signed-off-by: Dor Askayo
> > ---
> > drivers/gpu/drm/amd/display/dc/core/dc.c | 17 +
> > 1 file changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > index dd4731ab935c..83ebb716166b 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > @@ -2179,12 +2179,7 @@ void dc_set_power_state(
> > enum dc_acpi_cm_power_state power_state)
> > {
> > struct kref refcount;
> > - struct display_mode_lib *dml = kzalloc(sizeof(struct
> > display_mode_lib),
> > - GFP_KERNEL);
> > -
> > - ASSERT(dml);
> > - if (!dml)
> > - return;
> > + struct display_mode_lib *dml;
> >
> > switch (power_state) {
> > case DC_ACPI_CM_POWER_STATE_D0:
> > @@ -2206,6 +2201,12 @@ void dc_set_power_state(
> > * clean state, and dc hw programming optimizations will not
> > * cause any trouble.
> > */
> > + dml = kzalloc(sizeof(struct display_mode_lib),
> > + GFP_KERNEL);
> > +
> > + ASSERT(dml);
> > + if (!dml)
> > + return;
> >
> > /* Preserve refcount */
> > refcount = dc->current_state->refcount;
> > @@ -2219,10 +2220,10 @@ void dc_set_power_state(
> > dc->current_state->refcount = refcount;
> > dc->current_state->bw_ctx.dml = *dml;
> >
> > + kfree(dml);
> > +
> > break;
> > }
> > -
> > - kfree(dml);
> > }
> >
> > void dc_resume(struct dc *dc)
> > --
> > 2.24.1
> >
>
> I've been running with this fix applied on top of Fedora's
> 5.3.16-300.fc31.x86_64 kernel for the past two weeks, suspending
> and resuming often. This the first time since I bought my RX 580 8GB
> more than a year ago that I can suspend and resume reliably.
>
> I'd appreciate a quick review for the above, it really is a trivial change.
>
> Thanks,
> Dor
Bumping this up again. I've been running with this change for the past
20 days without issues.
Thanks,
Dor
On Fri, Jan 17, 2020 at 12:59 PM Dor Askayo wrote:
>
> On Sat, Jan 4, 2020 at 2:23 PM Dor Askayo wrote:
> >
> > This allocation isn't required and can fail when resuming from suspend.
> >
> > Bug: https://gitlab.freedesktop.org/drm/amd/issues/1009
> > Signed-off-by: Dor Askayo
> > ---
> > drivers/gpu/drm/amd/display/dc/core/dc.c | 17 +
> > 1 file changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > index dd4731ab935c..83ebb716166b 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > @@ -2179,12 +2179,7 @@ void dc_set_power_state(
> > enum dc_acpi_cm_power_state power_state)
> > {
> > struct kref refcount;
> > - struct display_mode_lib *dml = kzalloc(sizeof(struct
> > display_mode_lib),
> > - GFP_KERNEL);
> > -
> > - ASSERT(dml);
> > - if (!dml)
> > - return;
> > + struct display_mode_lib *dml;
> >
> > switch (power_state) {
> > case DC_ACPI_CM_POWER_STATE_D0:
> > @@ -2206,6 +2201,12 @@ void dc_set_power_state(
> > * clean state, and dc hw programming optimizations will not
> > * cause any trouble.
> > */
> > + dml = kzalloc(sizeof(struct display_mode_lib),
> > + GFP_KERNEL);
> > +
> > + ASSERT(dml);
> > + if (!dml)
> > + return;
> >
> > /* Preserve refcount */
> > refcount = dc->current_state->refcount;
> > @@ -2219,10 +2220,10 @@ void dc_set_power_state(
> > dc->current_state->refcount = refcount;
> > dc->current_state->bw_ctx.dml = *dml;
> >
> > + kfree(dml);
> > +
> > break;
> > }
> > -
> > - kfree(dml);
> > }
> >
> > void dc_resume(struct dc *dc)
> > --
> > 2.24.1
> >
>
> I've been running with this fix applied on top of Fedora's
> 5.3.16-300.fc31.x86_64 kernel for
> the past two weeks, suspending and resuming often. This the first time
> since I bought my
> RX 580 8GB more than a year ago that I can suspend and resume reliably.
>
> I'd appreciate a quick review for the above, it really is a trivial change.
>
> Thanks,
> Dor
___
dri-devel
Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
Hi,
On Wed, 2020-01-22 at 18:54 +0200, Georgi Djakov wrote:
> Hi Artur,
>
> Thank you for your continuous work on this.
>
> On 12/20/19 13:56, Artur Świgoń wrote:
> > This patch adds the following properties to the Exynos4412 DT:
> > - exynos,interconnect-parent-node: to declare connections between
> > nodes in order to guarantee PM QoS requirements between nodes;
>
> Is this DT property documented somewhere? I believe that there should be a
> patch
> to document it somewhere in Documentation/devicetree/bindings/ before using
> it.
It will be documented in
Documentation/devicetree/bindings/devfreq/exynos-bus.txt
in the next version.
> > - #interconnect-cells: required by the interconnect framework.
> >
> > Note that #interconnect-cells is always zero and node IDs are not
> > hardcoded anywhere.
> >
> > Signed-off-by: Artur Świgoń
> > ---
> > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > index 4ce3d77a6704..d9d70eacfcaf 100644
> > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > @@ -90,6 +90,7 @@
> > &bus_dmc {
> > exynos,ppmu-device = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> > vdd-supply = <&buck1_reg>;
> > + #interconnect-cells = <0>;
> > status = "okay";
> > };
> >
> > @@ -106,6 +107,8 @@
> > &bus_leftbus {
> > exynos,ppmu-device = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
> > vdd-supply = <&buck3_reg>;
> > + exynos,interconnect-parent-node = <&bus_dmc>;
> > + #interconnect-cells = <0>;
> > status = "okay";
> > };
> >
> > @@ -116,6 +119,8 @@
> >
> > &bus_display {
> > exynos,parent-bus = <&bus_leftbus>;
> > + exynos,interconnect-parent-node = <&bus_leftbus>;
> > + #interconnect-cells = <0>;
> > status = "okay";
> > };
--
Artur Świgoń
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v3] arm64: dts: sc7180: add display dt nodes
On Fri 24 Jan 04:06 PST 2020, Harigovindan P wrote:
> Add display, DSI hardware DT nodes for sc7180.
>
> Signed-off-by: Harigovindan P
Thanks for respinning this Harigovindan, just a few more small things
below.
Are the drivers ready for me to merge this?
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
[..]
> +&pm6150l_gpio {
> + disp_pins {
You can omit this subnode level, i.e. just put disp_pins_default
directly in &pm6150l_gpio.
> + disp_pins_default: disp_pins_default{
> + pins = "gpio3";
> + function = "func1";
> + qcom,drive-strength = <2>;
> + power-source = <0>;
> + bias-disable;
> + output-low;
> + };
> + };
> +};
> +
> &qspi_clk {
> pinconf {
> pins = "gpio63";
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index 3bc3f64..3ebc45b 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -1184,6 +1184,130 @@
> #power-domain-cells = <1>;
> };
>
> + mdss: display_subsystem@ae0 {
Whenever possible, use - and not _ in node names.
Regards,
Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3 0/4] drm: Introduce struct drm_device based WARN* and use them in i915
On Thu, 23 Jan 2020, Pankaj Bharadiya wrote: > changes since v2: > - rebase pending unmerged patches on drm-tip Alas, these conflict already... please rebase. :/ BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205497] Attempt to read amd gpu id causes a freeze
https://bugzilla.kernel.org/show_bug.cgi?id=205497 --- Comment #21 from albertogomezma...@gmail.com --- (In reply to Luya Tshimbalanga from comment #20) > I confirm the fix landed on kernel 5.4. Thanks Alex for a quick > investigation. Closing this report. For me It Is happening again, i dont know since what kernel. Ivhace an Asus with ryzen 5 3550H -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/7] uaccess: Tell user_access_begin() if it's for a write or not
Hi Christophe, Thank you for the patch! Yet something to improve: [auto build test ERROR on powerpc/next] [also build test ERROR on tip/x86/core drm-intel/for-linux-next v5.5-rc7] [cannot apply to linus/master next-20200124] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Christophe-Leroy/fs-readdir-Fix-filldir-and-filldir64-use-of-user_access_begin/20200125-070606 base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next config: x86_64-randconfig-s0-20200125 (attached as .config) compiler: gcc-7 (Debian 7.5.0-3) 7.5.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All error/warnings (new ones prefixed by >>): kernel/exit.c: In function '__do_sys_waitid': >> kernel/exit.c:1567:53: error: macro "user_access_begin" passed 3 arguments, >> but takes just 2 key = user_access_begin(infop, sizeof(*infop), true); ^ >> kernel/exit.c:1567:6: warning: assignment makes integer from pointer without >> a cast [-Wint-conversion] key = user_access_begin(infop, sizeof(*infop), true); ^ kernel/exit.c: In function '__do_compat_sys_waitid': kernel/exit.c:1697:53: error: macro "user_access_begin" passed 3 arguments, but takes just 2 key = user_access_begin(infop, sizeof(*infop), true); ^ kernel/exit.c:1697:6: warning: assignment makes integer from pointer without a cast [-Wint-conversion] key = user_access_begin(infop, sizeof(*infop), true); ^ -- kernel/compat.c: In function 'compat_get_bitmap': >> kernel/compat.c:267:55: error: macro "user_access_begin" passed 3 arguments, >> but takes just 2 key = user_access_begin(umask, bitmap_size / 8, false); ^ >> kernel/compat.c:267:6: warning: assignment makes integer from pointer >> without a cast [-Wint-conversion] key = user_access_begin(umask, bitmap_size / 8, false); ^ kernel/compat.c: In function 'compat_put_bitmap': kernel/compat.c:298:54: error: macro "user_access_begin" passed 3 arguments, but takes just 2 key = user_access_begin(umask, bitmap_size / 8, true); ^ kernel/compat.c:298:6: warning: assignment makes integer from pointer without a cast [-Wint-conversion] key = user_access_begin(umask, bitmap_size / 8, true); ^ -- fs/readdir.c: In function 'filldir': >> fs/readdir.c:242:58: error: macro "user_access_begin" passed 3 arguments, >> but takes just 2 key = user_access_begin(prev, reclen + prev_reclen, true); ^ >> fs/readdir.c:242:6: warning: assignment makes integer from pointer without a >> cast [-Wint-conversion] key = user_access_begin(prev, reclen + prev_reclen, true); ^ fs/readdir.c: In function 'filldir64': fs/readdir.c:329:58: error: macro "user_access_begin" passed 3 arguments, but takes just 2 key = user_access_begin(prev, reclen + prev_reclen, true); ^ fs/readdir.c:329:6: warning: assignment makes integer from pointer without a cast [-Wint-conversion] key = user_access_begin(prev, reclen + prev_reclen, true); ^ -- lib/usercopy.c: In function 'check_zeroed_user': >> lib/usercopy.c:62:43: error: macro "user_access_begin" passed 3 arguments, >> but takes just 2 key = user_access_begin(from, size, false); ^ >> lib/usercopy.c:62:6: warning: assignment makes integer from pointer without >> a cast [-Wint-conversion] key = user_access_begin(from, size, false); ^ -- lib/strncpy_from_user.c: In function 'strncpy_from_user': >> lib/strncpy_from_user.c:120:42: error: macro "user_access_begin" passed 3 >> arguments, but takes just 2 key = user_access_begin(src, max, false); ^ >> lib/strncpy_from_user.c:120:7: warning: assignment makes integer from >> pointer without a cast [-Wint-conversion] key = user_access_begin(src, max, false); ^ -- lib/strnlen_user.c: In function 'strnlen_user': >> lib/strnlen_user.c:113:42: error: macro &qu
Re: [PATCH v2 2/6] drm/i915/ddi: convert to struct drm_device log macros.
On Wed, 22 Jan 2020, Wambui Karuga wrote:
> This patch converts various instances of the printk based logging macros
> into the struct drm_device based macros. This was achieved using the
> following coccinelle script for matching existing struct
> drm_i915_private devices:
This one conflicts already, please rebase. Pushed the others to
drm-intel-next-queued, thanks for the patches.
BR,
Jani.
> @rule1@
> identifier fn, T;
> @@
>
> fn(...,struct drm_i915_private *T,...) {
> <+...
> (
> -DRM_INFO(
> +drm_info(&T->drm,
> ...)
> |
> -DRM_ERROR(
> +drm_err(&T->drm,
> ...)
> |
> -DRM_WARN(
> +drm_warn(&T->drm,
> ...)
> |
> -DRM_DEBUG(
> +drm_dbg(&T->drm,
> ...)
> |
> -DRM_DEBUG_DRIVER(
> +drm_dbg(&T->drm,
> ...)
> |
> -DRM_DEBUG_KMS(
> +drm_dbg_kms(&T->drm,
> ...)
> |
> -DRM_DEBUG_ATOMIC(
> +drm_dbg_atomic(&T->drm,
> ...)
> )
> ...+>
> }
>
> @rule2@
> identifier fn, T;
> @@
>
> fn(...) {
> ...
> struct drm_i915_private *T = ...;
> <+...
> (
> -DRM_INFO(
> +drm_info(&T->drm,
> ...)
> |
> -DRM_ERROR(
> +drm_err(&T->drm,
> ...)
> |
> -DRM_WARN(
> +drm_warn(&T->drm,
> ...)
> |
> -DRM_DEBUG(
> +drm_dbg(&T->drm,
> ...)
> |
> -DRM_DEBUG_KMS(
> +drm_dbg_kms(&T->drm,
> ...)
> |
> -DRM_DEBUG_DRIVER(
> +drm_dbg(&T->drm,
> ...)
> |
> -DRM_DEBUG_ATOMIC(
> +drm_dbg_atomic(&T->drm,
> ...)
> )
> ...+>
> }
>
> Checkpatch warnings were addressed manually.
>
> Signed-off-by: Wambui Karuga
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 98 +++-
> 1 file changed, 60 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index bbf1c0a243a2..9416d6950853 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1076,7 +1076,8 @@ static void intel_wait_ddi_buf_idle(struct
> drm_i915_private *dev_priv,
> if (I915_READ(reg) & DDI_BUF_IS_IDLE)
> return;
> }
> - DRM_ERROR("Timeout waiting for DDI BUF %c idle bit\n", port_name(port));
> + drm_err(&dev_priv->drm, "Timeout waiting for DDI BUF %c idle bit\n",
> + port_name(port));
> }
>
> static u32 hsw_pll_to_ddi_pll_sel(const struct intel_shared_dpll *pll)
> @@ -1229,7 +1230,8 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
>
> temp = I915_READ(DP_TP_STATUS(PORT_E));
> if (temp & DP_TP_STATUS_AUTOTRAIN_DONE) {
> - DRM_DEBUG_KMS("FDI link training done on step %d\n", i);
> + drm_dbg_kms(&dev_priv->drm,
> + "FDI link training done on step %d\n", i);
> break;
> }
>
> @@ -1238,7 +1240,7 @@ void hsw_fdi_link_train(struct intel_encoder *encoder,
>* Results in less fireworks from the state checker.
>*/
> if (i == ARRAY_SIZE(hsw_ddi_translations_fdi) * 2 - 1) {
> - DRM_ERROR("FDI link training failed!\n");
> + drm_err(&dev_priv->drm, "FDI link training failed!\n");
> break;
> }
>
> @@ -2005,7 +2007,8 @@ void intel_ddi_disable_transcoder_func(const struct
> intel_crtc_state *crtc_state
>
> if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME &&
> intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
> - DRM_DEBUG_KMS("Quirk Increase DDI disabled time\n");
> + drm_dbg_kms(&dev_priv->drm,
> + "Quirk Increase DDI disabled time\n");
> /* Quirk time at 100ms for reliable operation */
> msleep(100);
> }
> @@ -2183,20 +2186,23 @@ static void intel_ddi_get_encoder_pipes(struct
> intel_encoder *encoder,
> }
>
> if (!*pipe_mask)
> - DRM_DEBUG_KMS("No pipe for [ENCODER:%d:%s] found\n",
> - encoder->base.base.id, encoder->base.name);
> + drm_dbg_kms(&dev_priv->drm,
> + "No pipe for [ENCODER:%d:%s] found\n",
> + encoder->base.base.id, encoder->base.name);
>
> if (!mst_pipe_mask && hweight8(*pipe_mask) > 1) {
> - DRM_DEBUG_KMS("Multiple pipes for [ENCODER:%d:%s] (pipe_mask
> %02x)\n",
> - encoder->base.base.id, encoder->base.name,
> - *pipe_mask);
> + drm_dbg_kms(&dev_priv->drm,
> + "Multiple pipes for [ENCODER:%d:%s] (pipe_mask
> %02x)\n",
> + encoder->base.base.id, encoder->base.name,
> + *pipe_mask);
> *pipe_mask = BIT(ffs(*pipe_mask) - 1);
> }
>
> if (mst_pipe_mask && mst_pipe_mask != *pipe_mask)
> - DRM_DEBUG_KMS("Conflicting MST and non-MST state for
> [ENCODER:%d:%s] (pipe_mask %02x mst_pipe_mask %02x)\n",
> - encoder->base.base.id, encoder->base.name,
> -
Re: [PATCH v2] drm/i915/display: conversion to new struct drm_device logging macros.
On Wed, 22 Jan 2020, Wambui Karuga wrote:
> This patch converts various instances of the printk based logging macros
> in drm/i915/display/intel_display.c to the new struct drm_device based
> logging macros.
> In some instances, this involves extracting the struct drm_i915_private
> device from various intel types and using it in the macros.
>
> v2: use correct variable name in assignment over variable type.
>
> Signed-off-by: Wambui Karuga
Pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 1021 ++
> 1 file changed, 596 insertions(+), 425 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 427a2a4e4ce6..5012db151b0c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -235,7 +235,8 @@ static void intel_update_czclk(struct drm_i915_private
> *dev_priv)
> dev_priv->czclk_freq = vlv_get_cck_clock_hpll(dev_priv, "czclk",
> CCK_CZ_CLOCK_CONTROL);
>
> - DRM_DEBUG_DRIVER("CZ clock rate: %d kHz\n", dev_priv->czclk_freq);
> + drm_dbg(&dev_priv->drm, "CZ clock rate: %d kHz\n",
> + dev_priv->czclk_freq);
> }
>
> static inline u32 /* units of 100MHz */
> @@ -1063,8 +1064,9 @@ static void wait_for_pipe_scanline_moving(struct
> intel_crtc *crtc, bool state)
>
> /* Wait for the display line to settle/start moving */
> if (wait_for(pipe_scanline_is_moving(dev_priv, pipe) == state, 100))
> - DRM_ERROR("pipe %c scanline %s wait timed out\n",
> - pipe_name(pipe), onoff(state));
> + drm_err(&dev_priv->drm,
> + "pipe %c scanline %s wait timed out\n",
> + pipe_name(pipe), onoff(state));
> }
>
> static void intel_wait_for_pipe_scanline_stopped(struct intel_crtc *crtc)
> @@ -1397,7 +1399,7 @@ static void _vlv_enable_pll(struct intel_crtc *crtc,
> udelay(150);
>
> if (intel_de_wait_for_set(dev_priv, DPLL(pipe), DPLL_LOCK_VLV, 1))
> - DRM_ERROR("DPLL %d failed to lock\n", pipe);
> + drm_err(&dev_priv->drm, "DPLL %d failed to lock\n", pipe);
> }
>
> static void vlv_enable_pll(struct intel_crtc *crtc,
> @@ -1446,7 +1448,7 @@ static void _chv_enable_pll(struct intel_crtc *crtc,
>
> /* Check PLL is locked */
> if (intel_de_wait_for_set(dev_priv, DPLL(pipe), DPLL_LOCK_VLV, 1))
> - DRM_ERROR("PLL %d failed to lock\n", pipe);
> + drm_err(&dev_priv->drm, "PLL %d failed to lock\n", pipe);
> }
>
> static void chv_enable_pll(struct intel_crtc *crtc,
> @@ -1694,7 +1696,8 @@ static void ilk_enable_pch_transcoder(const struct
> intel_crtc_state *crtc_state)
>
> I915_WRITE(reg, val | TRANS_ENABLE);
> if (intel_de_wait_for_set(dev_priv, reg, TRANS_STATE_ENABLE, 100))
> - DRM_ERROR("failed to enable transcoder %c\n", pipe_name(pipe));
> + drm_err(&dev_priv->drm, "failed to enable transcoder %c\n",
> + pipe_name(pipe));
> }
>
> static void lpt_enable_pch_transcoder(struct drm_i915_private *dev_priv,
> @@ -1726,7 +1729,7 @@ static void lpt_enable_pch_transcoder(struct
> drm_i915_private *dev_priv,
> I915_WRITE(LPT_TRANSCONF, val);
> if (intel_de_wait_for_set(dev_priv, LPT_TRANSCONF,
> TRANS_STATE_ENABLE, 100))
> - DRM_ERROR("Failed to enable PCH transcoder\n");
> + drm_err(&dev_priv->drm, "Failed to enable PCH transcoder\n");
> }
>
> static void ilk_disable_pch_transcoder(struct drm_i915_private *dev_priv,
> @@ -1748,7 +1751,8 @@ static void ilk_disable_pch_transcoder(struct
> drm_i915_private *dev_priv,
> I915_WRITE(reg, val);
> /* wait for PCH transcoder off, transcoder state */
> if (intel_de_wait_for_clear(dev_priv, reg, TRANS_STATE_ENABLE, 50))
> - DRM_ERROR("failed to disable transcoder %c\n", pipe_name(pipe));
> + drm_err(&dev_priv->drm, "failed to disable transcoder %c\n",
> + pipe_name(pipe));
>
> if (HAS_PCH_CPT(dev_priv)) {
> /* Workaround: Clear the timing override chicken bit again. */
> @@ -1769,7 +1773,7 @@ void lpt_disable_pch_transcoder(struct drm_i915_private
> *dev_priv)
> /* wait for PCH transcoder off, transcoder state */
> if (intel_de_wait_for_clear(dev_priv, LPT_TRANSCONF,
> TRANS_STATE_ENABLE, 50))
> - DRM_ERROR("Failed to disable PCH transcoder\n");
> + drm_err(&dev_priv->drm, "Failed to disable PCH transcoder\n");
>
> /* Workaround: clear timing override bit. */
> val = I915_READ(TRANS_CHICKEN2(PIPE_A));
> @@ -1834,7 +1838,7 @@ static void intel_enable_pipe(const struct
> intel_crtc_state *new_crtc_state)
> i915_re
Re: [PATCH v4 2/2] drm/debugfs: also take per device driver features into account
On Thu, 23 Jan 2020, Thomas Zimmermann wrote:
> Am 23.01.20 um 13:48 schrieb Jani Nikula:
>> Use drm_core_check_all_features() to ensure both the driver features and
>> the per-device driver features are taken into account when registering
>> debugfs files.
>>
>> v3:
>> - files[i].driver_features == 0 actually means "don't care"
>>
>> v2:
>> - use drm_core_check_all_features()
>>
>> Cc: Ville Syrjälä
>> Cc: Thomas Zimmermann
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_debugfs.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
>> index eab0f2687cd6..4e673d318503 100644
>> --- a/drivers/gpu/drm/drm_debugfs.c
>> +++ b/drivers/gpu/drm/drm_debugfs.c
>> @@ -182,8 +182,7 @@ int drm_debugfs_create_files(const struct drm_info_list
>> *files, int count,
>> for (i = 0; i < count; i++) {
>> u32 features = files[i].driver_features;
>>
>> -if (features != 0 &&
>> -(dev->driver->driver_features & features) != features)
>> +if (features && !drm_core_check_all_features(dev, features))
>> continue;
>
> Reviewed-by: Thomas Zimmermann
Thanks for the review, both pushed to drm-misc-next.
BR,
Jani.
>
>>
>> tmp = kmalloc(sizeof(struct drm_info_node), GFP_KERNEL);
>>
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206299] [nouveau/xen] RTX 20XX instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=206299 --- Comment #2 from Frédéric Pierret (frederic.epi...@orange.fr) --- Created attachment 286967 --> https://bugzilla.kernel.org/attachment.cgi?id=286967&action=edit kernel log (dmesg) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206299] [nouveau/xen] RTX 20XX instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=206299 --- Comment #3 from Frédéric Pierret (frederic.epi...@orange.fr) --- Hi Ilia, Thank you for your answer. (In reply to Ilia Mirkin from comment #1) > Comment on attachment 286963 [details] > Kernel log > > badf5040 = bad mmio read. > > Could there be some PCI situation? Can you include a full boot log? You'll find dmesg.log attached. By PCI situation you mean hardware issue? If yes, the card is normally functional under Windows. For your information, the GPU remains attached to dom0, not pci-passthroughed on a domU. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
