[PATCH v4 2/3] drm/i915/dp: Attach and set drm connector VRR property
From: Aditya Swarup
This function sets the VRR property for connector based
on the platform support, EDID monitor range and DP sink
DPCD capability of outputing video without msa
timing information.
v4:
* Rebase (Mansi)
v3:
* intel_dp_is_vrr_capable can be used for debugfs, make it
non static (Manasi)
v2:
* Just set this in intel_dp_get_modes instead of new hook (Jani)
Cc: Ville Syrjälä
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_dp.c | 24
drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d4fcc9583869..77ea25dba150 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6412,6 +6412,23 @@ intel_dp_force(struct drm_connector *connector)
intel_display_power_put(dev_priv, aux_domain, wakeref);
}
+bool intel_dp_is_vrr_capable(struct drm_connector *connector)
+{
+ struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
+ const struct drm_display_info *info = >display_info;
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ /*
+* DP Sink is capable of Variable refresh video timings if
+* Ignore MSA bit is set in DPCD.
+* EDID monitor range also should be atleast 10 for reasonable
+* Adaptive sync/ VRR end user experience.
+*/
+ return INTEL_GEN(dev_priv) >= 12 &&
+ drm_dp_sink_can_do_video_without_timing_msa(intel_dp->dpcd) &&
+ info->monitor_range.max_vfreq - info->monitor_range.min_vfreq >
10;
+}
+
static int intel_dp_get_modes(struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
@@ -6422,6 +6439,10 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
int ret = intel_connector_update_modes(connector, edid);
if (ret)
return ret;
+
+ if (intel_dp_is_vrr_capable(connector))
+ drm_connector_set_vrr_capable_property(connector,
+ true);
}
/* if eDP has no EDID, fall back to fixed mode */
@@ -7503,6 +7524,9 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
}
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ drm_connector_attach_vrr_capable_property(connector);
}
static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 6659ce15a693..aa7c1f530d5e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -14,6 +14,7 @@ enum pipe;
enum port;
struct drm_connector_state;
struct drm_encoder;
+struct drm_connector;
struct drm_i915_private;
struct drm_modeset_acquire_ctx;
struct intel_connector;
@@ -119,6 +120,7 @@ void intel_dp_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct drm_connector_state *conn_state);
bool intel_digital_port_connected(struct intel_encoder *encoder);
void intel_dp_process_phy_request(struct intel_dp *intel_dp);
+bool intel_dp_is_vrr_capable(struct drm_connector *connector);
static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
{
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] drm/dp: DRM DP helper for reading Ignore MSA from DPCD
DP sink device sets the Ignore MSA bit in its
DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to
ignore the MSA video timing parameters and its ability to support
seamless video timing change over a range of timing exposed by
DisplayID and EDID.
This is required for the sink to indicate that it is Adaptive sync
capable.
v3:
* Fi the typo in commit message (Manasi)
v2:
* Rename to describe what the function does (Jani Nikula)
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
Signed-off-by: Manasi Navare
Reviewed-by: Harry Wentland
---
include/drm/drm_dp_helper.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 3beb2aac8c4c..87264b561632 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1454,6 +1454,14 @@ drm_dp_alternate_scrambler_reset_cap(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
DP_ALTERNATE_SCRAMBLER_RESET_CAP;
}
+/* Ignore MSA timing for Adaptive Sync support on DP 1.4 */
+static inline bool
+drm_dp_sink_can_do_video_without_timing_msa(const u8
dpcd[DP_RECEIVER_CAP_SIZE])
+{
+ return dpcd[DP_DOWN_STREAM_PORT_COUNT] &
+ DP_MSA_TIMING_PAR_IGNORED;
+}
+
/*
* DisplayPort AUX channel
*/
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] drm/i915/dp: Expose connector VRR info via debugfs
From: Bhanuprakash Modem
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file
on the connector, "i915_vrr_info".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/i915_vrr_info
v3:
* Remove the unnecessary debug print (Manasi)
v2:
* Fix the typo in max_vfreq (Manasi)
* Change the name of node to i915_vrr_info so we can add
other vrr info for more debug info (Manasi)
* Change the VRR capable to display Yes or No (Manasi)
* Fix indentation checkpatch errors (Manasi)
Signed-off-by: Bhanuprakash Modem
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjälä
Tested-by: Manasi Navare
---
.../drm/i915/display/intel_display_debugfs.c | 22 ++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index bdeea2e02642..35b229ab4d19 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2096,6 +2096,21 @@ static const struct file_operations
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
};
+static int i915_vrr_info_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
+
+ seq_printf(m, "Vrr_capable: %s\n",
yesno(intel_dp_is_vrr_capable(connector)));
+ seq_printf(m, "Min: %u\n",
(u8)connector->display_info.monitor_range.min_vfreq);
+ seq_printf(m, "Max: %u\n",
(u8)connector->display_info.monitor_range.max_vfreq);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(i915_vrr_info);
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2130,9 +2145,14 @@ int intel_connector_debugfs_add(struct drm_connector
*connector)
if (INTEL_GEN(dev_priv) >= 10 &&
(connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
-connector->connector_type == DRM_MODE_CONNECTOR_eDP))
+connector->connector_type == DRM_MODE_CONNECTOR_eDP)) {
debugfs_create_file("i915_dsc_fec_support", S_IRUGO, root,
connector, _dsc_fec_support_fops);
+ if (INTEL_GEN(dev_priv) >= 12)
+ debugfs_create_file("i915_vrr_info", S_IRUGO,
+ root, connector,
_vrr_info_fops);
+ }
+
return 0;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-tip:drm-tip 6/8] drivers/rtc/rtc-cmos.c:655:16: error: redefinition of 'flags'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 636ab52e6d1d7aced9620f16da90d4c3c5fcadf5
commit: 213a0a26eba646607e88120c3fd27dc32b03e1f0 [6/8] Merge remote-tracking
branch 'drm-intel/topic/core-for-CI' into drm-tip
config: x86_64-defconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
8e2daa0c7f27b5d13b11bff68ae3cd42329abd6c)
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 213a0a26eba646607e88120c3fd27dc32b03e1f0
# save the attached .config to linux build tree
COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/rtc/rtc-cmos.c:655:16: error: redefinition of 'flags'
unsigned long flags;
^
drivers/rtc/rtc-cmos.c:652:16: note: previous definition is here
unsigned long flags;
^
1 error generated.
vim +/flags +655 drivers/rtc/rtc-cmos.c
7be2c7c96aff28 David Brownell 2007-02-10 649
7be2c7c96aff28 David Brownell 2007-02-10 650 static irqreturn_t
cmos_interrupt(int irq, void *p)
7be2c7c96aff28 David Brownell 2007-02-10 651 {
66e4f4a9cc389b Ville Syrjälä 2020-02-21 652 unsigned long flags;
7be2c7c96aff28 David Brownell 2007-02-10 653 u8 irqstat;
8a0bdfd7a05f5b David Brownell 2008-02-06 654 u8 rtc_control;
5b39064d452ac9 Chris Wilson 2020-03-02 @655 unsigned long flags;
7be2c7c96aff28 David Brownell 2007-02-10 656
66e4f4a9cc389b Ville Syrjälä 2020-02-21 657 spin_lock_irqsave(_lock,
flags);
35d3fdd5f304c0 David Brownell 2008-07-23 658
35d3fdd5f304c0 David Brownell 2008-07-23 659 /* When the HPET interrupt
handler calls us, the interrupt
35d3fdd5f304c0 David Brownell 2008-07-23 660* status is passed as arg1
instead of the irq number. But
35d3fdd5f304c0 David Brownell 2008-07-23 661* always clear irq status,
even when HPET is in the way.
35d3fdd5f304c0 David Brownell 2008-07-23 662*
35d3fdd5f304c0 David Brownell 2008-07-23 663* Note that HPET and RTC are
almost certainly out of phase,
35d3fdd5f304c0 David Brownell 2008-07-23 664* giving different IRQ status
...
9d8af78b07976d Bernhard Walle 2008-02-06 665*/
7be2c7c96aff28 David Brownell 2007-02-10 666 irqstat =
CMOS_READ(RTC_INTR_FLAGS);
8a0bdfd7a05f5b David Brownell 2008-02-06 667 rtc_control =
CMOS_READ(RTC_CONTROL);
311ee9c151ad7f Zhang Rui 2018-03-26 668 if (use_hpet_alarm())
35d3fdd5f304c0 David Brownell 2008-07-23 669 irqstat = (unsigned
long)irq & 0xF0;
998a06051afe6c Derek Basehore 2013-07-03 670
998a06051afe6c Derek Basehore 2013-07-03 671 /* If we were suspended,
RTC_CONTROL may not be accurate since the
998a06051afe6c Derek Basehore 2013-07-03 672* bios may have cleared it.
998a06051afe6c Derek Basehore 2013-07-03 673*/
998a06051afe6c Derek Basehore 2013-07-03 674 if (!cmos_rtc.suspend_ctrl)
8a0bdfd7a05f5b David Brownell 2008-02-06 675 irqstat &= (rtc_control
& RTC_IRQMASK) | RTC_IRQF;
998a06051afe6c Derek Basehore 2013-07-03 676 else
998a06051afe6c Derek Basehore 2013-07-03 677 irqstat &=
(cmos_rtc.suspend_ctrl & RTC_IRQMASK) | RTC_IRQF;
8a0bdfd7a05f5b David Brownell 2008-02-06 678
8a0bdfd7a05f5b David Brownell 2008-02-06 679 /* All Linux RTC alarms should
be treated as if they were oneshot.
8a0bdfd7a05f5b David Brownell 2008-02-06 680* Similar code may be needed
in system wakeup paths, in case the
8a0bdfd7a05f5b David Brownell 2008-02-06 681* alarm woke the system.
8a0bdfd7a05f5b David Brownell 2008-02-06 682*/
8a0bdfd7a05f5b David Brownell 2008-02-06 683 if (irqstat & RTC_AIE) {
998a06051afe6c Derek Basehore 2013-07-03 684 cmos_rtc.suspend_ctrl
&= ~RTC_AIE;
8a0bdfd7a05f5b David Brownell 2008-02-06 685 rtc_control &= ~RTC_AIE;
8a0bdfd7a05f5b David Brownell 2008-02-06 686 CMOS_WRITE(rtc_control,
RTC_CONTROL);
311ee9c151ad7f Zhang Rui 2018-03-26 687 if (use_hpet_alarm())
35d3fdd5f304c0 David Brownell 2008-07-23 688
hpet_mask_rtc_irq_bit(RTC_AIE);
8a0bdfd7a05f5b David Brownell 2008-02-06 689
CMOS_READ(RTC_INTR_FLAGS);
8a0bdfd7a05f5b David Brownell 2008-02-06 690 }
66e4f4a9cc389b Ville Syrjälä 2020-02-21 691
spin_unlock_irqrestore(_lock, flags);
7be2c7c96aff28 David Brownell 2007-02-10 692
bcd9b89c02295b David Brownell 2007-04-01 693 if (is_intr(irqstat)) {
7be2c7c96aff28 David Brownell 2007-02-10 694 rtc_update_irq(p, 1,
irqstat);
7be2c7c96aff28 David Brownell 2007-02-10 695 return IRQ_HANDLED;
7be2c7c96aff28 David Brownell 2007-02-10 696 } else
7be2c7c96aff28 David Brownell 2007-02-10 697 return IRQ_NONE;
Re: [PATCH] of_device: removed #include that caused a recursion in included headers
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on stm32/stm32-next]
[also build test ERROR on sunxi/sunxi/for-next tegra/for-next linus/master
v5.7-rc1 next-20200413]
[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/Hadar-Gat/of_device-removed-include-that-caused-a-recursion-in-included-headers/20200414-032638
base: https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
stm32-next
config: arm-multi_v5_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/bus/imx-weim.c: In function 'weim_parse_dt':
>> drivers/bus/imx-weim.c:227:9: error: implicit declaration of function
>> 'of_platform_default_populate' [-Werror=implicit-function-declaration]
227 | ret = of_platform_default_populate(pdev->dev.of_node,
| ^~~~
cc1: some warnings being treated as errors
--
drivers/pinctrl/freescale/pinctrl-imx1-core.c: In function
'imx1_pinctrl_core_probe':
>> drivers/pinctrl/freescale/pinctrl-imx1-core.c:639:8: error: implicit
>> declaration of function 'of_platform_populate'
>> [-Werror=implicit-function-declaration]
639 | ret = of_platform_populate(pdev->dev.of_node, NULL, NULL,
>dev);
|^~~~
cc1: some warnings being treated as errors
vim +/of_platform_default_populate +227 drivers/bus/imx-weim.c
85bf6d4e4b100e Huang Shijie 2013-05-28 189
4a92f07816ba30 Sascha Hauer 2019-08-14 190 static int
weim_parse_dt(struct platform_device *pdev, void __iomem *base)
85bf6d4e4b100e Huang Shijie 2013-05-28 191 {
3f98b6baad63b1 Alexander Shiyan 2013-06-29 192const struct
of_device_id *of_id = of_match_device(weim_id_table,
3f98b6baad63b1 Alexander Shiyan 2013-06-29 193
>dev);
3f98b6baad63b1 Alexander Shiyan 2013-06-29 194const struct
imx_weim_devtype *devtype = of_id->data;
85bf6d4e4b100e Huang Shijie 2013-05-28 195struct device_node
*child;
52c47b63412b09 Alison Chaiken2015-02-18 196int ret, have_child = 0;
c7995bcb36ef61 Sven Van Asbroeck 2018-12-17 197struct cs_timing_state
ts = {};
77266e722feabb Sven Van Asbroeck 2019-07-12 198u32 reg;
85bf6d4e4b100e Huang Shijie 2013-05-28 199
8d9ee21e98205e Shawn Guo 2014-02-11 200if (devtype ==
_weim_devtype) {
8d9ee21e98205e Shawn Guo 2014-02-11 201ret =
imx_weim_gpr_setup(pdev);
8d9ee21e98205e Shawn Guo 2014-02-11 202if (ret)
8d9ee21e98205e Shawn Guo 2014-02-11 203return
ret;
8d9ee21e98205e Shawn Guo 2014-02-11 204}
8d9ee21e98205e Shawn Guo 2014-02-11 205
77266e722feabb Sven Van Asbroeck 2019-07-12 206if
(of_property_read_bool(pdev->dev.of_node, "fsl,burst-clk-enable")) {
77266e722feabb Sven Van Asbroeck 2019-07-12 207if
(devtype->wcr_bcm) {
77266e722feabb Sven Van Asbroeck 2019-07-12 208reg =
readl(base + devtype->wcr_offset);
77266e722feabb Sven Van Asbroeck 2019-07-12 209
writel(reg | devtype->wcr_bcm,
77266e722feabb Sven Van Asbroeck 2019-07-12 210
base + devtype->wcr_offset);
77266e722feabb Sven Van Asbroeck 2019-07-12 211} else {
77266e722feabb Sven Van Asbroeck 2019-07-12 212
dev_err(>dev, "burst clk mode not supported.\n");
77266e722feabb Sven Van Asbroeck 2019-07-12 213return
-EINVAL;
77266e722feabb Sven Van Asbroeck 2019-07-12 214}
77266e722feabb Sven Van Asbroeck 2019-07-12 215}
77266e722feabb Sven Van Asbroeck 2019-07-12 216
33b96d2c957921 Fabio Estevam 2016-02-22 217
for_each_available_child_of_node(pdev->dev.of_node, child) {
c7995bcb36ef61 Sven Van Asbroeck 2018-12-17 218ret =
weim_timing_setup(>dev, child, base, devtype, );
52c47b63412b09 Alison Chaiken2015-02-18 219if (ret)
9c0982d809fd81 Rob Herring 2017-07-18 220
dev_warn(>dev, "%pOF set timing failed.\n",
9c0982d809fd81 Rob Herring
Re: [PATCH] of_device: removed #include that caused a recursion in included headers
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on stm32/stm32-next]
[also build test ERROR on linus/master v5.7-rc1 next-20200413]
[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/Hadar-Gat/of_device-removed-include-that-caused-a-recursion-in-included-headers/20200414-032638
base: https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
stm32-next
config: sparc-randconfig-a001-20200413 (attached as .config)
compiler: sparc-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=9.3.0 make.cross ARCH=sparc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
arch/sparc/mm/iommu.c: In function 'iommu_init':
>> arch/sparc/mm/iommu.c:139:32: error: implicit declaration of function
>> 'of_find_device_by_node'; did you mean 'bus_find_device_by_fwnode'?
>> [-Werror=implicit-function-declaration]
139 | struct platform_device *op = of_find_device_by_node(dp);
|^~
|bus_find_device_by_fwnode
>> arch/sparc/mm/iommu.c:139:32: error: initialization of 'struct
>> platform_device *' from 'int' makes pointer from integer without a cast
>> [-Werror=int-conversion]
cc1: all warnings being treated as errors
--
arch/sparc/mm/io-unit.c: In function 'iounit_init':
>> arch/sparc/mm/io-unit.c:81:32: error: implicit declaration of function
>> 'of_find_device_by_node'; did you mean 'bus_find_device_by_fwnode'?
>> [-Werror=implicit-function-declaration]
81 | struct platform_device *op = of_find_device_by_node(dp);
|^~
|bus_find_device_by_fwnode
>> arch/sparc/mm/io-unit.c:81:32: error: initialization of 'struct
>> platform_device *' from 'int' makes pointer from integer without a cast
>> [-Werror=int-conversion]
cc1: all warnings being treated as errors
vim +139 arch/sparc/mm/iommu.c
^1da177e4c3f41 Linus Torvalds 2005-04-16 133
046e26a8ba10b8 David S. Miller 2008-08-27 134 static int __init
iommu_init(void)
046e26a8ba10b8 David S. Miller 2008-08-27 135 {
046e26a8ba10b8 David S. Miller 2008-08-27 136 struct device_node *dp;
046e26a8ba10b8 David S. Miller 2008-08-27 137
046e26a8ba10b8 David S. Miller 2008-08-27 138
for_each_node_by_name(dp, "iommu") {
cd4cd7306a403f Grant Likely2010-07-22 @139 struct
platform_device *op = of_find_device_by_node(dp);
046e26a8ba10b8 David S. Miller 2008-08-27 140
046e26a8ba10b8 David S. Miller 2008-08-27 141
sbus_iommu_init(op);
046e26a8ba10b8 David S. Miller 2008-08-27 142
of_propagate_archdata(op);
046e26a8ba10b8 David S. Miller 2008-08-27 143 }
046e26a8ba10b8 David S. Miller 2008-08-27 144
046e26a8ba10b8 David S. Miller 2008-08-27 145 return 0;
046e26a8ba10b8 David S. Miller 2008-08-27 146 }
046e26a8ba10b8 David S. Miller 2008-08-27 147
:: The code at line 139 was first introduced by commit
:: cd4cd7306a403f62ef3ca783b9d1cf2a03e595ed sparc: remove references to
of_device and to_of_device
:: TO: Grant Likely
:: CC: Grant Likely
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] of_device: removed #include that caused a recursion in included headers
Hi Hadar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on stm32/stm32-next]
[also build test ERROR on sunxi/sunxi/for-next tegra/for-next linus/master
v5.7-rc1 next-20200413]
[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/Hadar-Gat/of_device-removed-include-that-caused-a-recursion-in-included-headers/20200414-032638
base: https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
stm32-next
config: x86_64-randconfig-h003-20200413 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
8e2daa0c7f27b5d13b11bff68ae3cd42329abd6c)
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/clk/mediatek/clk-mt7622-aud.c:153:6: error: implicit declaration of
>> function 'devm_of_platform_populate'
>> [-Werror,-Wimplicit-function-declaration]
r = devm_of_platform_populate(>dev);
^
1 error generated.
vim +/devm_of_platform_populate +153 drivers/clk/mediatek/clk-mt7622-aud.c
2fc0a509e4ee85 Sean Wang 2017-10-05 132
2fc0a509e4ee85 Sean Wang 2017-10-05 133 static int
clk_mt7622_audiosys_init(struct platform_device *pdev)
2fc0a509e4ee85 Sean Wang 2017-10-05 134 {
2fc0a509e4ee85 Sean Wang 2017-10-05 135struct clk_onecell_data
*clk_data;
2fc0a509e4ee85 Sean Wang 2017-10-05 136struct device_node *node =
pdev->dev.of_node;
2fc0a509e4ee85 Sean Wang 2017-10-05 137int r;
2fc0a509e4ee85 Sean Wang 2017-10-05 138
2fc0a509e4ee85 Sean Wang 2017-10-05 139clk_data =
mtk_alloc_clk_data(CLK_AUDIO_NR_CLK);
2fc0a509e4ee85 Sean Wang 2017-10-05 140
2fc0a509e4ee85 Sean Wang 2017-10-05 141mtk_clk_register_gates(node,
audio_clks, ARRAY_SIZE(audio_clks),
2fc0a509e4ee85 Sean Wang 2017-10-05 142
clk_data);
2fc0a509e4ee85 Sean Wang 2017-10-05 143
2fc0a509e4ee85 Sean Wang 2017-10-05 144r = of_clk_add_provider(node,
of_clk_src_onecell_get, clk_data);
037b21133e5367 Ryder Lee 2018-03-20 145if (r) {
2fc0a509e4ee85 Sean Wang 2017-10-05 146dev_err(>dev,
2fc0a509e4ee85 Sean Wang 2017-10-05 147"could not
register clock provider: %s: %d\n",
2fc0a509e4ee85 Sean Wang 2017-10-05 148pdev->name, r);
2fc0a509e4ee85 Sean Wang 2017-10-05 149
037b21133e5367 Ryder Lee 2018-03-20 150goto err_clk_provider;
037b21133e5367 Ryder Lee 2018-03-20 151}
037b21133e5367 Ryder Lee 2018-03-20 152
037b21133e5367 Ryder Lee 2018-03-20 @153r =
devm_of_platform_populate(>dev);
037b21133e5367 Ryder Lee 2018-03-20 154if (r)
037b21133e5367 Ryder Lee 2018-03-20 155goto err_plat_populate;
037b21133e5367 Ryder Lee 2018-03-20 156
037b21133e5367 Ryder Lee 2018-03-20 157return 0;
037b21133e5367 Ryder Lee 2018-03-20 158
037b21133e5367 Ryder Lee 2018-03-20 159 err_plat_populate:
037b21133e5367 Ryder Lee 2018-03-20 160of_clk_del_provider(node);
037b21133e5367 Ryder Lee 2018-03-20 161 err_clk_provider:
2fc0a509e4ee85 Sean Wang 2017-10-05 162return r;
2fc0a509e4ee85 Sean Wang 2017-10-05 163 }
2fc0a509e4ee85 Sean Wang 2017-10-05 164
:: The code at line 153 was first introduced by commit
:: 037b21133e5367c833908db0226d77138ba4c5eb clk: mediatek: add
devm_of_platform_populate() for MT7622 audsys
:: TO: Ryder Lee
:: CC: Stephen Boyd
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS enums and bitfields UAPI
Daniel Vetter, Ville, any thoughts about this? Thanks, Simon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/i915: Replace "Broadcast RGB" with "RGB quantization range" property
On Monday, April 13, 2020 11:40 PM, Yussuf Khalil wrote: > DRM now has a globally available "RGB quantization range" connector > property. i915's "Broadcast RGB" that fulfils the same purpose is now > considered deprecated, so drop it in favor of the DRM property. For a UAPI point-of-view, I'm not sure this is fine. Some user-space might depend on this property, dropping it would break such user-space. Can we make this property deprecated but still keep it for backwards compatibility? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm: Add "RGB quantization range" connector property
Can you also add docs for this property in "DOC: standard connector properties" in drm_connector.c? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/atomic-helper: Consider RGB quantization changes to be mode changes
Ensure RGB quantization range changes are applied immediately. Signed-off-by: Yussuf Khalil --- drivers/gpu/drm/drm_atomic_helper.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 85d163f16801..b74e90a2b214 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -686,6 +686,12 @@ drm_atomic_helper_check_modeset(struct drm_device *dev, if (old_connector_state->max_requested_bpc != new_connector_state->max_requested_bpc) new_crtc_state->connectors_changed = true; + + if (drm_connector_state_select_rgb_quantization_range( + old_connector_state, _crtc_state->mode) != + drm_connector_state_select_rgb_quantization_range( + new_connector_state, _crtc_state->mode)) + new_crtc_state->mode_changed = true; } if (funcs->atomic_check) -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/modes: Indicate CEA-861 CE modes to user-space
Add a new flag to mark modes that are considered a CE mode according to the
CEA-861 specification. Modes without this flag are implicitly considered to
be IT modes.
User-space applications may use this flag to determine possible
implications of using a CE mode (e.g., limited RGB range).
There is no use for this flag inside the kernel, so we set it only when
communicating a mode to user-space.
Signed-off-by: Yussuf Khalil
---
drivers/gpu/drm/drm_modes.c | 14 ++
include/uapi/drm/drm_mode.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index d4d64518e11b..0d8a032f437d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1973,6 +1973,14 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo
*out,
break;
}
+ if (drm_match_cea_mode(in) > 1) {
+ /*
+* All modes in CTA-861-G Table 1 are CE modes, except 640x480p
+* (VIC 1).
+*/
+ out->flags |= DRM_MODE_FLAG_CEA_861_CE_MODE;
+ }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
}
@@ -2045,6 +2053,12 @@ int drm_mode_convert_umode(struct drm_device *dev,
return -EINVAL;
}
+ /*
+* The CEA-861 CE mode flag is purely informational and intended for
+* userspace only.
+*/
+ out->flags &= ~DRM_MODE_FLAG_CEA_861_CE_MODE;
+
out->status = drm_mode_validate_driver(dev, out);
if (out->status != MODE_OK)
return -EINVAL;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 735c8cfdaaa1..5e78b350b2e2 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -124,6 +124,8 @@ extern "C" {
#define DRM_MODE_FLAG_PIC_AR_256_135 \
(DRM_MODE_PICTURE_ASPECT_256_135<<19)
+#define DRM_MODE_FLAG_CEA_861_CE_MODE (1<<23)
+
#define DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
DRM_MODE_FLAG_NHSYNC | \
DRM_MODE_FLAG_PVSYNC | \
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm: Add drm_connector_state_select_rgb_quantization_range() helper
This helper can be used to determine the appropriate RGB quantization range
based on a connector's "RGB quantization range" property and a mode.
Signed-off-by: Yussuf Khalil
---
drivers/gpu/drm/drm_connector.c | 31 +++
include/drm/drm_connector.h | 4
2 files changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e60d3b6e5e56..d5a46bbf284e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2187,6 +2187,37 @@ int drm_connector_set_panel_orientation_with_quirk(
}
EXPORT_SYMBOL(drm_connector_set_panel_orientation_with_quirk);
+/**
+ * drm_connector_state_select_rgb_quantization_range - find RGB quantization
+ * range appropriate for a connector's state and mode
+ *
+ * @state: state of the connector for which to determine the range
+ * @mode: mode for which to determine the range
+ *
+ * For a given connector state (i.e., RGB quantization range property) and a
+ * given mode, determine which RGB quantization range should be used.
+ *
+ * Returns:
+ * A constant from the HDMI quantization range enum.
+ */
+enum hdmi_quantization_range drm_connector_state_select_rgb_quantization_range(
+ const struct drm_connector_state *state,
+const struct drm_display_mode *mode)
+{
+ switch (state->rgb_quantization_range) {
+ default:
+ WARN_ON(1);
+ /* fallthrough */
+ case DRM_MODE_RGB_QUANTIZATION_RANGE_AUTOMATIC:
+ return drm_default_rgb_quant_range(mode);
+ case DRM_MODE_RGB_QUANTIZATION_RANGE_FULL:
+ return HDMI_QUANTIZATION_RANGE_FULL;
+ case DRM_MODE_RGB_QUANTIZATION_RANGE_LIMITED:
+ return HDMI_QUANTIZATION_RANGE_LIMITED;
+ }
+}
+EXPORT_SYMBOL(drm_connector_state_select_rgb_quantization_range);
+
int drm_connector_set_obj_prop(struct drm_mode_object *obj,
struct drm_property *property,
uint64_t value)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index f605e0fbcc0e..43ce305d882f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -42,6 +42,7 @@ struct drm_property_blob;
struct drm_printer;
struct edid;
struct i2c_adapter;
+struct drm_display_mode;
enum drm_connector_force {
DRM_FORCE_UNSPECIFIED,
@@ -1621,6 +1622,9 @@ int drm_connector_set_panel_orientation_with_quirk(
int width, int height);
int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
int min, int max);
+enum hdmi_quantization_range drm_connector_state_select_rgb_quantization_range(
+ const struct drm_connector_state *state,
+ const struct drm_display_mode *mode);
/**
* struct drm_tile_group - Tile group metadata
--
2.26.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm: Add "RGB quantization range" connector property
Add a new "RGB quantization range" property with three possible values:
Automatic, Limited, and Full. User-space may use this property to override
the automatic selection of the RGB range as specified by CTA-861. Drivers
should attach this property to all CTA-861 sinks.
Signed-off-by: Yussuf Khalil
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 35 +++
include/drm/drm_connector.h | 23
include/drm/drm_mode_config.h | 7 +++
4 files changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index a1e5e262bae2..f12b3a40c6cf 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -766,6 +766,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
fence_ptr);
} else if (property == connector->max_bpc_property) {
state->max_requested_bpc = val;
+ } else if (property == config->rgb_quantization_range_property) {
+ state->rgb_quantization_range = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -842,6 +844,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = 0;
} else if (property == connector->max_bpc_property) {
*val = state->max_requested_bpc;
+ } else if (property == config->rgb_quantization_range_property) {
+ *val = state->rgb_quantization_range;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 644f0ad10671..e60d3b6e5e56 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -929,6 +929,12 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
{ DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
};
+static const struct drm_prop_enum_list rgb_quantization_range_options[] = {
+ { DRM_MODE_RGB_QUANTIZATION_RANGE_AUTOMATIC, "Automatic" },
+ { DRM_MODE_RGB_QUANTIZATION_RANGE_LIMITED, "Limited" },
+ { DRM_MODE_RGB_QUANTIZATION_RANGE_FULL, "Full" },
+};
+
/**
* DOC: standard connector properties
*
@@ -1804,6 +1810,35 @@ int drm_mode_create_dp_colorspace_property(struct
drm_connector *connector)
}
EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
+/**
+ * drm_mode_create_rgb_quantization_range_property - create RGB quantization
+ * range property
+ * @dev: device to create the RGB quantization range property on.
+ *
+ * Called by a driver the first time it's needed, must be attached to
connectors
+ * of CEA-861-compliant sinks.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_create_rgb_quantization_range_property(struct drm_device *dev)
+{
+ if (dev->mode_config.rgb_quantization_range_property)
+ return 0;
+
+ dev->mode_config.rgb_quantization_range_property =
+ drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+"RGB quantization range",
+rgb_quantization_range_options,
+
ARRAY_SIZE(rgb_quantization_range_options));
+
+ if (!dev->mode_config.rgb_quantization_range_property)
+ return -ENOMEM;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_rgb_quantization_range_property);
+
/**
* drm_mode_create_content_type_property - create content type property
* @dev: DRM device
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 19ae6bb5c85b..f605e0fbcc0e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -303,6 +303,22 @@ struct drm_monitor_range_info {
#define DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT14
#define DRM_MODE_COLORIMETRY_BT601_YCC 15
+/**
+ * enum drm_rgb_quantization_range - rgb_quantization_range property value
+ *
+ * This enum lists the possible options for the rgb_quantization_range
property.
+ *
+ * @DRM_MODE_RGB_QUANTIZATION_RANGE_AUTOMATIC: Let the driver select the
+ * appropriate quantization range.
+ * @DRM_MODE_RGB_QUANTIZATION_RANGE_LIMITED: Force limited range RGB.
+ * @DRM_MODE_RGB_QUANTIZATION_RANGE_FULL: Force full range RGB.
+ */
+enum drm_rgb_quantization_range {
+ DRM_MODE_RGB_QUANTIZATION_RANGE_AUTOMATIC = 0,
+ DRM_MODE_RGB_QUANTIZATION_RANGE_LIMITED = 1,
+ DRM_MODE_RGB_QUANTIZATION_RANGE_FULL = 2,
+};
+
/**
* enum drm_bus_flags - bus_flags info for _display_info
*
@@ -661,6 +677,12
[PATCH 5/5] drm/i915: Replace "Broadcast RGB" with "RGB quantization range" property
DRM now has a globally available "RGB quantization range" connector
property. i915's "Broadcast RGB" that fulfils the same purpose is now
considered deprecated, so drop it in favor of the DRM property.
Signed-off-by: Yussuf Khalil
---
drivers/gpu/drm/i915/display/intel_atomic.c | 8
.../gpu/drm/i915/display/intel_connector.c| 39 ++-
.../gpu/drm/i915/display/intel_connector.h| 2 +-
.../drm/i915/display/intel_display_types.h| 8
drivers/gpu/drm/i915/display/intel_dp.c | 24
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 19 -
drivers/gpu/drm/i915/display/intel_sdvo.c | 18 -
drivers/gpu/drm/i915/i915_drv.h | 1 -
9 files changed, 34 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index d043057d2fa0..5dbbd8e8aa5d 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -63,8 +63,6 @@ int intel_digital_connector_atomic_get_property(struct
drm_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 {
drm_dbg_atomic(_priv->drm,
"Unknown property [PROP:%d:%s]\n",
@@ -99,11 +97,6 @@ int intel_digital_connector_atomic_set_property(struct
drm_connector *connector,
return 0;
}
- if (property == dev_priv->broadcast_rgb_property) {
- intel_conn_state->broadcast_rgb = val;
- return 0;
- }
-
drm_dbg_atomic(_priv->drm, "Unknown property [PROP:%d:%s]\n",
property->base.id, property->name);
return -EINVAL;
@@ -145,7 +138,6 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
* up in a modeset.
*/
if (new_conn_state->force_audio != old_conn_state->force_audio ||
- new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.colorspace != old_conn_state->base.colorspace
||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 903e49659f56..1b6439e3ccaf 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -238,34 +238,6 @@ intel_attach_force_audio_property(struct drm_connector
*connector)
drm_object_attach_property(>base, prop, 0);
}
-static const struct drm_prop_enum_list broadcast_rgb_names[] = {
- { INTEL_BROADCAST_RGB_AUTO, "Automatic" },
- { INTEL_BROADCAST_RGB_FULL, "Full" },
- { INTEL_BROADCAST_RGB_LIMITED, "Limited 16:235" },
-};
-
-void
-intel_attach_broadcast_rgb_property(struct drm_connector *connector)
-{
- struct drm_device *dev = connector->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct drm_property *prop;
-
- prop = dev_priv->broadcast_rgb_property;
- if (prop == NULL) {
- prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
- "Broadcast RGB",
- broadcast_rgb_names,
- ARRAY_SIZE(broadcast_rgb_names));
- if (prop == NULL)
- return;
-
- dev_priv->broadcast_rgb_property = prop;
- }
-
- drm_object_attach_property(>base, prop, 0);
-}
-
void
intel_attach_aspect_ratio_property(struct drm_connector *connector)
{
@@ -297,3 +269,14 @@ intel_attach_colorspace_property(struct drm_connector
*connector)
drm_object_attach_property(>base,
connector->colorspace_property, 0);
}
+
+void
+intel_attach_rgb_quantization_range_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+
+ if (!drm_mode_create_rgb_quantization_range_property(dev))
+ drm_object_attach_property(>base,
+ dev->mode_config.rgb_quantization_range_property,
+ DRM_MODE_RGB_QUANTIZATION_RANGE_AUTOMATIC);
+}
\ No newline at end of file
diff --git a/drivers/gpu/drm/i915/display/intel_connector.h
b/drivers/gpu/drm/i915/display/intel_connector.h
index 93a7375c8196..ece946915407 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.h
+++ b/drivers/gpu/drm/i915/display/intel_connector.h
@@ -28,8 +28,8 @@ int intel_connector_update_modes(struct drm_connector
*connector,
[PATCH 0/5] Improving the situation regarding RGB quantization ranges
The CTA-861 specification differentiates between IT and CE modes. For the latter, it requires sources to send "limited RGB quantization range", i.e., allowed RGB values are constrained to 16 - 235 (in the 8 bit case). A sink may indicate support for full range RGB (0 - 255) in CE modes through its EDID, allowing the source to override the recommendations set by CTA-861. For computer screens it is usually desirable to have full range RGB output. In reality, though, many displays set a CE mode as preferred in their EDID and leave the "Quantization Range Selectable" bit unset despite having no issues with full range output. Therefore, it makes sense to provide the user with a method of overriding the standards-compliant selection. The current situation in DRM regarding the RGB quantization range is somewhat messy. We have drivers that - behave standards-compliant and provide a custom override property (e.g., i915, gma500) - behave standards-compliant and provide no override (e.g., vc4) - behave standards-compliant and select full range for CE modes if the screen indicates support (e.g., tda998x) - probably don't care at all This series is an effort to fix the situation. It introduces a property for overriding the RGB quantization range that is defined in the DRM core and can be attached to connectors by all drivers, providing a driver-independent way of overriding the defaults to userspace. So far, I've wired up the new property in i915 only. Yussuf Khalil (5): drm/modes: Indicate CEA-861 CE modes to user-space drm: Add "RGB quantization range" connector property drm: Add drm_connector_state_select_rgb_quantization_range() helper drm/atomic-helper: Consider RGB quantization changes to be mode changes drm/i915: Replace "Broadcast RGB" with "RGB quantization range" property drivers/gpu/drm/drm_atomic_helper.c | 6 ++ drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_connector.c | 66 +++ drivers/gpu/drm/drm_modes.c | 14 drivers/gpu/drm/i915/display/intel_atomic.c | 8 --- .../gpu/drm/i915/display/intel_connector.c| 39 --- .../gpu/drm/i915/display/intel_connector.h| 2 +- .../drm/i915/display/intel_display_types.h| 8 --- drivers/gpu/drm/i915/display/intel_dp.c | 24 ++- drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 19 ++ drivers/gpu/drm/i915/display/intel_sdvo.c | 18 ++--- drivers/gpu/drm/i915/i915_drv.h | 1 - include/drm/drm_connector.h | 27 include/drm/drm_mode_config.h | 7 ++ include/uapi/drm/drm_mode.h | 2 + 16 files changed, 160 insertions(+), 87 deletions(-) -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206021] AMDGPU/DC: freesync disabled on the monitor side after the monitor sleeps and resumes
https://bugzilla.kernel.org/show_bug.cgi?id=206021 --- Comment #7 from Clément Guérin (li...@protonmail.com) --- No improvement on 5.7-rc1 -- 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 v2 00/11] new cgroup controller for gpu/drm subsystem
Hello, On Mon, Apr 13, 2020 at 05:40:32PM -0400, Kenny Ho wrote: > By lack of consense, do you mean Intel's assertion that a standard is > not a standard until Intel implements it? (That was in the context of > OpenCL language standard with the concept of SubDevice.) I thought > the discussion so far has established that the concept of a compute > unit, while named differently (AMD's CUs, ARM's SCs, Intel's EUs, > Nvidia's SMs, Qualcomm's SPs), is cross vendor. While an AMD CU is > not the same as an Intel EU or Nvidia SM, the same can be said for CPU > cores. If cpuset is acceptable for a diversity of CPU core designs > and arrangements, I don't understand why an interface derived from GPU > SubDevice is considered premature. CPUs are a lot more uniform across vendors than GPUs and have way higher user observability and awareness. And, even then, it's something which has limited usefulness because the configuration is inherently more complex involving topology details and the end result is not work-conserving. cpuset is there partly due to historical reasons and its features can often be trivially replicated with some scripting around taskset. If that's all you're trying to add, I don't see why it needs to be in cgroup at all. Just implement a tool similar to taskset and build sufficient tooling around it. Given how hardware specific it can become, that is likely the better direction anyway. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/dpcd_bl: Unbreak enable_dpcd_backlight modparam
Looks like I accidentally made it so you couldn't force DPCD backlight
support on, whoops. Fix that.
Signed-off-by: Lyude Paul
Fixes: 17f5d57915be ("drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen
4K AMOLED panel")
Cc: Adam Jackson
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: "Ville Syrjälä"
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 4b916468540f..0722540d64ad 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -358,6 +358,7 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *intel_connector)
*/
if (i915->vbt.backlight.type !=
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE &&
+ i915_modparams.enable_dpcd_backlight != 1 &&
!drm_dp_has_quirk(_dp->desc, intel_dp->edid_quirks,
DP_QUIRK_FORCE_DPCD_BACKLIGHT)) {
drm_info(>drm,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
Hi, On Mon, Apr 13, 2020 at 4:54 PM Tejun Heo wrote: > > Allocations definitely are acceptable and it's not a pre-requisite to have > work-conserving control first either. Here, given the lack of consensus in > terms of what even constitute resource units, I don't think it'd be a good > idea to commit to the proposed interface and believe it'd be beneficial to > work on interface-wise simpler work conserving controls. > ... > I hope the rationales are clear now. What I'm objecting is inclusion of > premature interface, which is a lot easier and more tempting to do for > hardware-specific limits and the proposals up until now have been showing > ample signs of that. I don't think my position has changed much since the > beginning - do the difficult-to-implement but easy-to-use weights first and > then you and everyone would have a better idea of what hard-limit or > allocation interfaces and mechanisms should look like, or even whether they're > needed. By lack of consense, do you mean Intel's assertion that a standard is not a standard until Intel implements it? (That was in the context of OpenCL language standard with the concept of SubDevice.) I thought the discussion so far has established that the concept of a compute unit, while named differently (AMD's CUs, ARM's SCs, Intel's EUs, Nvidia's SMs, Qualcomm's SPs), is cross vendor. While an AMD CU is not the same as an Intel EU or Nvidia SM, the same can be said for CPU cores. If cpuset is acceptable for a diversity of CPU core designs and arrangements, I don't understand why an interface derived from GPU SubDevice is considered premature. If a decade-old language standard is not considered a consenses, can you elaborate on what might consitute a consenses? Regards, Kenny ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm/vblank: Add vblank works
Hi Tejun > > And, thanks a lot for the vblank explanation. I really enjoyed readin it. :) You were not the only one who liked it :-) We ended up with an updated explanation in drm_vblank.c: https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_vblank.c Including some nice ascii art in the final version. It will hit upstream in next merge window. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
Hello, On Mon, Apr 13, 2020 at 04:17:14PM -0400, Kenny Ho wrote: > Perhaps we can even narrow things down to just > gpu.weight/gpu.compute.weight as a start? In this aspect, is the key That sounds great to me. > objection to the current implementation of gpu.compute.weight the > work-conserving bit? This work-conserving requirement is probably > what I have missed for the last two years (and hence going in circle.) > > If this is the case, can you clarify/confirm the followings? > > 1) Is resource scheduling goal of cgroup purely for the purpose of > throughput? (at the expense of other scheduling goals such as > latency.) It's not; however, work-conserving mechanisms are the easiest to use (cuz you don't lose anything) while usually challenging to implement. It tends to clarify how control mechanisms should be structured - even what resources are. > 2) If 1) is true, under what circumstances will the "Allocations" > resource distribution model (as defined in the cgroup-v2) be > acceptable? Allocations definitely are acceptable and it's not a pre-requisite to have work-conserving control first either. Here, given the lack of consensus in terms of what even constitute resource units, I don't think it'd be a good idea to commit to the proposed interface and believe it'd be beneficial to work on interface-wise simpler work conserving controls. > 3) If 1) is true, are things like cpuset from cgroup v1 no longer > acceptable going forward? Again, they're acceptable. > To be clear, while some have framed this (time sharing vs spatial > sharing) as a partisan issue, it is in fact a technical one. I have > implemented the gpu cgroup support this way because we have a class of > users that value low latency/low jitter/predictability/synchronicity. > For example, they would like 4 tasks to share a GPU and they would > like the tasks to start and finish at the same time. > > What is the rationale behind picking the Weight model over Allocations > as the first acceptable implementation? Can't we have both > work-conserving and non-work-conserving ways of distributing GPU > resources? If we can, why not allow non-work-conserving > implementation first, especially when we have users asking for such > functionality? I hope the rationales are clear now. What I'm objecting is inclusion of premature interface, which is a lot easier and more tempting to do for hardware-specific limits and the proposals up until now have been showing ample signs of that. I don't think my position has changed much since the beginning - do the difficult-to-implement but easy-to-use weights first and then you and everyone would have a better idea of what hard-limit or allocation interfaces and mechanisms should look like, or even whether they're needed. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm/vblank: Add vblank works
Hello, On Mon, Apr 13, 2020 at 04:18:57PM -0400, Lyude Paul wrote: > Hi Tejun! Sorry to bother you, but have you had a chance to look at any of > this yet? Would like to continue moving this forward Sorry, wasn't following this thread. Have you looked at kthread_worker? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/kthread.h#n71 And, thanks a lot for the vblank explanation. I really enjoyed readin it. :) -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] drm/vblank: Add vblank works
Hi Tejun! Sorry to bother you, but have you had a chance to look at any of this yet? Would like to continue moving this forward On Fri, 2020-03-27 at 16:38 -0400, Lyude Paul wrote: > Oops, completely forgot to link to the work_struct version of this patch: > > [1] > https://gitlab.freedesktop.org/lyudess/linux/-/commit/f57886aebbd9631f1ee6e61b516bf73afbfe74f4 > > On Fri, 2020-03-27 at 16:29 -0400, Lyude Paul wrote: > > Adding Tejun to this thread per-Daniel's suggestion on IRC. > > > > Hi Tejun! So, I don't know what your experience with modesetting related > > stuff > > is so I'll quickly explain some important concepts here regarding > > scanlines, > > vblanks, etc. If you already understand this, feel free to skip this next > > paragraph. > > > > From the perspective of a computer, every time a computer monitor displays > > a > > new frame it's done by "scanning out" the display image from top to > > bottom, > > one row of pixels at a time. which row of pixels we're on is referred to > > as > > the scanline. Additionally, there's usually a couple of extra scanlines > > which > > we scan out, but aren't actually displayed on the screen (these sometimes > > get > > used by HDMI audio and friends, but that's another story). The period > > where > > we're on these scanlines is referred to as the vblank, this is important. > > > > On a lot of display hardware, programming needs to take effect during the > > vertical blanking period so that settings like gamma, what frame we're > > scanning out, etc. can be safely changed without showing visual tearing on > > the > > screen. In some unforgiving hardware, some of this programming has to both > > start and end in the same vblank. This is apparently the case on the > > majority > > of Intel GPUs in the wild right now, most notably with gamma updates which > > involve mashing over 2KiB of registers during the vblank. Other drivers > > have > > very similar needs to this (nouveau in particular is why I'm here, we need > > it > > for CRC related stuff) so we figured it'd be a good idea to add a set of > > helpers for performing realtime hardware programming that's synchronized > > to > > vblank intervals. In particular, this is aimed at hardware programming > > that > > would be a bit too awkward to try to pull off entirely in interrupt > > context. > > We call these vblank workers. > > > > We first tried doing this using plain old kthreads, as you can see in the > > patch below, since we could schedule them as realtime. Additionally, the > > plan > > was to use this in i915 combined with pm_qos to get rid of cstate latency > > when > > handling the original vblank interrupt. Note, our time constraints are a > > bit > > more forgiving in nouveau so you won't see any pm_qos mentions in this > > series. > > > > In an effort to try to avoid reinventing parts of the kernel's worker > > infrastructure though, we tried to see if we could implement these with > > simple > > work_structs and workqueues with HIGH_PRI | UNBOUNDED,[1]. But, it would > > seem > > that this work_struct approach is quite unreliable and we still usually > > fail > > to start the register programming in time for Intel's vblank worker > > usecase. > > > > So, so far using plain old RT kthreads seems to make things about as > > reliable > > as I think we're going to get. Note - even using kthreads we _still_ > > sometimes > > miss the vblank period and end up tearing a bit on screen, but it happens > > significantly less often then with work_structs and is basically going to > > be > > as fast as we can get (in the future, Intel wants to try fixing this by > > doing > > this hardware programming outside of the CPU, but for now we're stuck with > > this). > > > > With all of this being said - we'd still like to avoid having to reinvent > > workers if possible, so we were wondering if there was any kind of > > realtime > > worker that could be used for this instead? I haven't been able to find > > any > > way of scheduling workers to be realtime, and I'm not sure if implementing > > this in Linux's workqueues would be realistic either. It'd be nice to > > avoid > > having to use plain old kthreads if possible :). What do you think Tejun? > > > > On Wed, 2020-03-18 at 14:46 +0100, Daniel Vetter wrote: > > > On Tue, Mar 17, 2020 at 08:40:58PM -0400, Lyude Paul wrote: > > > > From: Ville Syrjälä > > > > > > > > Add some kind of vblank workers. The interface is similar to regular > > > > delayed works, and also allows for re-scheduling. > > > > > > > > Whatever hardware programming we do in the work must be fast > > > > (must at least complete during the vblank, sometimes during > > > > the first few scanlines of vblank), so we'll fire up a per-crtc > > > > high priority thread for this. > > > > > > > > [based off patches from Ville Syrjälä , > > > > change below to signoff later] > > > > > > > > Cc: Ville Syrjälä > > > > Signed-off-by: Lyude Paul > > > > > > Hm not really sold on the
Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
(replying again in plain-text) Hi Tejun, Thanks for taking the time to reply. Perhaps we can even narrow things down to just gpu.weight/gpu.compute.weight as a start? In this aspect, is the key objection to the current implementation of gpu.compute.weight the work-conserving bit? This work-conserving requirement is probably what I have missed for the last two years (and hence going in circle.) If this is the case, can you clarify/confirm the followings? 1) Is resource scheduling goal of cgroup purely for the purpose of throughput? (at the expense of other scheduling goals such as latency.) 2) If 1) is true, under what circumstances will the "Allocations" resource distribution model (as defined in the cgroup-v2) be acceptable? 3) If 1) is true, are things like cpuset from cgroup v1 no longer acceptable going forward? To be clear, while some have framed this (time sharing vs spatial sharing) as a partisan issue, it is in fact a technical one. I have implemented the gpu cgroup support this way because we have a class of users that value low latency/low jitter/predictability/synchronicity. For example, they would like 4 tasks to share a GPU and they would like the tasks to start and finish at the same time. What is the rationale behind picking the Weight model over Allocations as the first acceptable implementation? Can't we have both work-conserving and non-work-conserving ways of distributing GPU resources? If we can, why not allow non-work-conserving implementation first, especially when we have users asking for such functionality? Regards, Kenny On Mon, Apr 13, 2020 at 3:11 PM Tejun Heo wrote: > > Hello, Kenny. > > On Tue, Mar 24, 2020 at 02:49:27PM -0400, Kenny Ho wrote: > > Can you elaborate more on what are the missing pieces? > > Sorry about the long delay, but I think we've been going in circles for quite > a while now. Let's try to make it really simple as the first step. How about > something like the following? > > * gpu.weight (should it be gpu.compute.weight? idk) - A single number > per-device weight similar to io.weight, which distributes computation > resources in work-conserving way. > > * gpu.memory.high - A single number per-device on-device memory limit. > > The above two, if works well, should already be plenty useful. And my guess is > that getting the above working well will be plenty challenging already even > though it's already excluding work-conserving memory distribution. So, let's > please do that as the first step and see what more would be needed from there. > > Thanks. > > -- > tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
[AMD Official Use Only - Internal Distribution Only] Hi Tejun, Thanks for taking the time to reply. Perhaps we can even narrow things down to just gpu.weight/gpu.compute.weight as a start? In this aspect, is the key objection to the current implementation of gpu.compute.weight the work-conserving bit? This work-conserving requirement is probably what I have missed for the last two years (and hence going in circle.) If this is the case, can you clarify/confirm the followings? 1) Is resource scheduling goal of cgroup purely for the purpose of throughput? (at the expense of other scheduling goals such as latency.) 2) If 1) is true, under what circumstances will the "Allocations" resource distribution model (as defined in the cgroup-v2) be acceptable? 3) If 1) is true, are things like cpuset from cgroup v1 no longer acceptable going forward? To be clear, while some have framed this (time sharing vs spatial sharing) as a partisan issue, it is in fact a technical one. I have implemented the gpu cgroup support this way because we have a class of users that value low latency/low jitter/predictability/synchronicity. For example, they would like 4 tasks to share a GPU and they would like the tasks to start and finish at the same time. What is the rationale behind picking the Weight model over Allocations as the first acceptable implementation? Can't we have both work-conserving and non-work-conserving ways of distributing GPU resources? If we can, why not allow non-work-conserving implementation first, especially when we have users asking for such functionality? Regards, Kenny From: Tejun Heo on behalf of Tejun Heo Sent: Monday, April 13, 2020 3:11 PM To: Kenny Ho Cc: Ho, Kenny ; cgro...@vger.kernel.org ; dri-devel ; amd-gfx list ; Deucher, Alexander ; Koenig, Christian ; Kuehling, Felix ; Greathouse, Joseph ; jspa...@cray.com Subject: Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem Hello, Kenny. On Tue, Mar 24, 2020 at 02:49:27PM -0400, Kenny Ho wrote: > Can you elaborate more on what are the missing pieces? Sorry about the long delay, but I think we've been going in circles for quite a while now. Let's try to make it really simple as the first step. How about something like the following? * gpu.weight (should it be gpu.compute.weight? idk) - A single number per-device weight similar to io.weight, which distributes computation resources in work-conserving way. * gpu.memory.high - A single number per-device on-device memory limit. The above two, if works well, should already be plenty useful. And my guess is that getting the above working well will be plenty challenging already even though it's already excluding work-conserving memory distribution. So, let's please do that as the first step and see what more would be needed from there. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/11] new cgroup controller for gpu/drm subsystem
Hello, Kenny. On Tue, Mar 24, 2020 at 02:49:27PM -0400, Kenny Ho wrote: > Can you elaborate more on what are the missing pieces? Sorry about the long delay, but I think we've been going in circles for quite a while now. Let's try to make it really simple as the first step. How about something like the following? * gpu.weight (should it be gpu.compute.weight? idk) - A single number per-device weight similar to io.weight, which distributes computation resources in work-conserving way. * gpu.memory.high - A single number per-device on-device memory limit. The above two, if works well, should already be plenty useful. And my guess is that getting the above working well will be plenty challenging already even though it's already excluding work-conserving memory distribution. So, let's please do that as the first step and see what more would be needed from there. Thanks. -- tejun ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: bridge: simple-bridge: Make connector creation optional
Hi Laurent. > > Some rambling below you can ignore. > > I tend not to split trivial cleanups like these in separate patches, > should I ? See my comment above, in other words no need to split. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: Use ARRAY_SIZE instead of hardcoded size
On Mon, 2020-04-13 at 22:32 +0800, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> drivers/gpu/drm/i915/gvt/vgpu.c:127:30-31: WARNING: Use ARRAY_SIZE
>
> Signed-off-by: Jason Yan
> ---
> drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
> index 1d5ff88078bd..7d361623ff67 100644
> --- a/drivers/gpu/drm/i915/gvt/vgpu.c
> +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
> @@ -124,7 +124,7 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
>*/
> low_avail = gvt_aperture_sz(gvt) - HOST_LOW_GM_SIZE;
> high_avail = gvt_hidden_sz(gvt) - HOST_HIGH_GM_SIZE;
> - num_types = sizeof(vgpu_types) / sizeof(vgpu_types[0]);
> + num_types = ARRAY_SIZE(vgpu_types);
>
> gvt->types = kcalloc(num_types, sizeof(struct intel_vgpu_type),
>GFP_KERNEL);
It's probably better to remove num_types altogether and just
use ARRAY_SIZE in both places num_types is used.
Perhaps refactoring the function a bit more is also better.
Perhaps:
o Use ARRAY_SIZE
o Make vgpu_types static const to reduce data size and
move the definition into the function where it's used
o Use temporaries to shorten the code indirections.
---
drivers/gpu/drm/i915/gvt/vgpu.c | 92 +
1 file changed, 47 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 1d5ff8..e56f59d 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -77,26 +77,6 @@ void populate_pvinfo_page(struct intel_vgpu *vgpu)
#define VGPU_WEIGHT(vgpu_num) \
(VGPU_MAX_WEIGHT / (vgpu_num))
-static struct {
- unsigned int low_mm;
- unsigned int high_mm;
- unsigned int fence;
-
- /* A vGPU with a weight of 8 will get twice as much GPU as a vGPU
-* with a weight of 4 on a contended host, different vGPU type has
-* different weight set. Legal weights range from 1 to 16.
-*/
- unsigned int weight;
- enum intel_vgpu_edid edid;
- char *name;
-} vgpu_types[] = {
-/* Fixed vGPU type table */
- { MB_TO_BYTES(64), MB_TO_BYTES(384), 4, VGPU_WEIGHT(8),
GVT_EDID_1024_768, "8" },
- { MB_TO_BYTES(128), MB_TO_BYTES(512), 4, VGPU_WEIGHT(4),
GVT_EDID_1920_1200, "4" },
- { MB_TO_BYTES(256), MB_TO_BYTES(1024), 4, VGPU_WEIGHT(2),
GVT_EDID_1920_1200, "2" },
- { MB_TO_BYTES(512), MB_TO_BYTES(2048), 4, VGPU_WEIGHT(1),
GVT_EDID_1920_1200, "1" },
-};
-
/**
* intel_gvt_init_vgpu_types - initialize vGPU type list
* @gvt : GVT device
@@ -106,9 +86,32 @@ static struct {
*/
int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
{
- unsigned int num_types;
unsigned int i, low_avail, high_avail;
unsigned int min_low;
+ static const struct vgpu_types {
+ unsigned int low_mm;
+ unsigned int high_mm;
+ unsigned int fence;
+
+ /* A vGPU with a weight of 8 will get twice as much GPU
+* as a vGPU with a weight of 4 on a contended host,
+* different vGPU type has different weight set.
+* Legal weights range from 1 to 16.
+*/
+ unsigned int weight;
+ enum intel_vgpu_edid edid;
+ char *name;
+ } vgpu_types[] = {
+ /* Fixed vGPU type table */
+ { MB_TO_BYTES(64), MB_TO_BYTES(384), 4,
+ VGPU_WEIGHT(8), GVT_EDID_1024_768, "8" },
+ { MB_TO_BYTES(128), MB_TO_BYTES(512), 4,
+ VGPU_WEIGHT(4), GVT_EDID_1920_1200, "4" },
+ { MB_TO_BYTES(256), MB_TO_BYTES(1024), 4,
+ VGPU_WEIGHT(2), GVT_EDID_1920_1200, "2" },
+ { MB_TO_BYTES(512), MB_TO_BYTES(2048), 4,
+ VGPU_WEIGHT(1), GVT_EDID_1920_1200, "1" },
+ };
/* vGPU type name is defined as GVTg_Vx_y which contains
* physical GPU generation type (e.g V4 as BDW server, V5 as
@@ -124,45 +127,44 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
*/
low_avail = gvt_aperture_sz(gvt) - HOST_LOW_GM_SIZE;
high_avail = gvt_hidden_sz(gvt) - HOST_HIGH_GM_SIZE;
- num_types = sizeof(vgpu_types) / sizeof(vgpu_types[0]);
- gvt->types = kcalloc(num_types, sizeof(struct intel_vgpu_type),
-GFP_KERNEL);
+ gvt->types = kcalloc(ARRAY_SIZE(vgpu_types),
+sizeof(struct intel_vgpu_type), GFP_KERNEL);
if (!gvt->types)
return -ENOMEM;
min_low = MB_TO_BYTES(32);
- for (i = 0; i < num_types; ++i) {
- if (low_avail / vgpu_types[i].low_mm == 0)
+ for (i = 0; i < ARRAY_SIZE(vgpu_types); i++) {
+ struct intel_vgpu_type *type = >types[i];
+ const struct vgpu_types
Re: [regression 5.7-rc1] System does not power off, just halts
On Mon, Apr 13, 2020 at 1:47 PM Paul Menzel wrote: > > Dear Prike, dear Alex, dear Linux folks, > > > Am 13.04.20 um 10:44 schrieb Paul Menzel: > > > A regression between causes a system with the AMD board MSI B350M MORTAR > > (MS-7A37) with an AMD Ryzen 3 2200G not to power off any more but just > > to halt. > > > > The regression is introduced in 9ebe5422ad6c..b032227c6293. I am in the > > process to bisect this, but maybe somebody already has an idea. > > I found the Easter egg: > > > commit 487eca11a321ef33bcf4ca5adb3c0c4954db1b58 > > Author: Prike Liang > > Date: Tue Apr 7 20:21:26 2020 +0800 > > > > drm/amdgpu: fix gfx hang during suspend with video playback (v2) > > > > The system will be hang up during S3 suspend because of SMU is pending > > for GC not respose the register CP_HQD_ACTIVE access request.This issue > > root cause of accessing the GC register under enter GFX CGGPG and can > > be fixed by disable GFX CGPG before perform suspend. > > > > v2: Use disable the GFX CGPG instead of RLC safe mode guard. > > > > Signed-off-by: Prike Liang > > Tested-by: Mengbing Wang > > Reviewed-by: Huang Rui > > Signed-off-by: Alex Deucher > > Cc: sta...@vger.kernel.org > > It reverts cleanly on top of 5.7-rc1, and this fixes the issue. > > Greg, please do not apply this to the stable series. The commit message > doesn’t even reference a issue/bug report, and doesn’t give a detailed > problem description. What system is it? > > Dave, Alex, how to proceed? Revert? I created issue 1094 [1]. Already fixed: https://patchwork.freedesktop.org/patch/361195/ Alex > > > Kind regards, > > Paul > > > [1]: https://gitlab.freedesktop.org/drm/amd/-/issues/1094 > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: bridge: simple-bridge: Make connector creation optional
Hi Sam,
On Mon, Apr 13, 2020 at 07:43:52AM +0200, Sam Ravnborg wrote:
> On Thu, Apr 09, 2020 at 03:36:36AM +0300, Laurent Pinchart wrote:
> > Make the connector creation optional to enable usage of the
> > simple-bridge with the DRM bridge connector helper.
> >
> > Signed-off-by: Laurent Pinchart
>
> Looks straightforward.
> Acked-by: Sam Ravnborg
>
> Some rambling below you can ignore.
>
> > ---
> > drivers/gpu/drm/bridge/simple-bridge.c | 11 ---
> > 1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
> > b/drivers/gpu/drm/bridge/simple-bridge.c
> > index bac223d0430d..bad638088029 100644
> > --- a/drivers/gpu/drm/bridge/simple-bridge.c
> > +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> > @@ -101,16 +101,14 @@ static int simple_bridge_attach(struct drm_bridge
> > *bridge,
> > struct simple_bridge *sbridge = drm_bridge_to_simple_bridge(bridge);
>
> The code below uses both sbridge-> and bridge->
> It confused me that we access via bridge-> when possilbe and only
> reverts to the "upper" sbridge when needed.
> This is unrelated to this patch - just an observation.
> It makes code shorter so I can see why it is done.
>
> > int ret;
> >
> > - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> > - DRM_ERROR("Fix bridge driver to make connector optional!");
> > - return -EINVAL;
> > - }
> > -
> > ret = drm_bridge_attach(bridge->encoder, sbridge->next_bridge, bridge,
> > DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> > if (ret < 0)
> > return ret;
> >
> > + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> > + return 0;
> > +
> > if (!bridge->encoder) {
> > DRM_ERROR("Missing encoder\n");
> > return -ENODEV;
> > @@ -127,8 +125,7 @@ static int simple_bridge_attach(struct drm_bridge
> > *bridge,
> > return ret;
> > }
> >
> > - drm_connector_attach_encoder(>connector,
> > - bridge->encoder);
> > + drm_connector_attach_encoder(>connector, bridge->encoder);
>
> Unrelated change, but patch is trivial...
I tend not to split trivial cleanups like these in separate patches,
should I ?
> >
> > return 0;
> > }
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: bridge: simple-bridge: Delegate operations to next bridge
Hi Sam,
On Mon, Apr 13, 2020 at 07:33:25AM +0200, Sam Ravnborg wrote:
> On Thu, Apr 09, 2020 at 03:36:35AM +0300, Laurent Pinchart wrote:
> > Instead of poking into the DT node of the next bridge for its DDC bus
> > and implementing the .get_modes() and .detect() connector operations
> > manually, retrieve the next bridge in the chain and delegate these
> > operations to it.
>
> I had the impression that we could have any number of bridges,
> and the approach was to request some info further down in the chain for
> info, without knowing if the next or the next->next was the bridge that
> could provide the information.
> But this seems not to be the case - here we assume ->next can get the
> edid - or if not we have a fallback.
>
> The relation that the next bridge was the one with i2c was present
> before this patch - so it is not directly related to this patch but
> a more general observation.
You're absolutely right, and this is just an interim measure. Delegating
operations to the next bridge in the chain is legacy code, only used
when DRM_BRIDGE_ATTACH_NO_CONNECTOR isn't set. It should eventually go
away when all users will be converted to the new model.
> A few nits below. With these nits considered the patch is:
> Acked-by: Sam Ravnborg
>
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/bridge/simple-bridge.c | 98 +-
> > 1 file changed, 33 insertions(+), 65 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
> > b/drivers/gpu/drm/bridge/simple-bridge.c
> > index a2dca7a3ef03..bac223d0430d 100644
> > --- a/drivers/gpu/drm/bridge/simple-bridge.c
> > +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> > @@ -29,7 +29,7 @@ struct simple_bridge {
> >
> > const struct simple_bridge_info *info;
> >
> > - struct i2c_adapter *ddc;
> > + struct drm_bridge *next_bridge;
> > struct regulator*vdd;
> > struct gpio_desc*enable;
> > };
> > @@ -52,29 +52,24 @@ static int simple_bridge_get_modes(struct drm_connector
> > *connector)
> > struct edid *edid;
> > int ret;
> >
> > - if (!sbridge->ddc)
> > - goto fallback;
> > -
> > - edid = drm_get_edid(connector, sbridge->ddc);
> > - if (!edid) {
> > - DRM_INFO("EDID readout failed, falling back to standard
> > modes\n");
> > - goto fallback;
> > + edid = drm_bridge_get_edid(sbridge->next_bridge, connector);
>
> drm_bridge_get_edid() is not documented to return NULL:
> "The retrieved EDID on success, or an error pointer otherwise."
> So IS_ERR() would do the trick here.
Except that drm_bridge_funcs.get_edid() is documented as returning NULL,
and drm_get_edid() returns NULL on errors. I'm thus tempted to just fix
the documentation of drm_bridge_get_edid() to return NULL on error.
There could be value in using error pointers through the whole EDID API,
but that's a subsystem-wide change that is out of scope for this series.
> > + if (IS_ERR_OR_NULL(edid)) {
> > + if (!edid)
> > + DRM_INFO("EDID readout failed, falling back to standard
> > modes\n");
> > +
> > + /*
> > +* In case we cannot retrieve the EDIDs (missing or broken DDC
> > +* bus from the next bridge), fallback on the XGA standards and
> > +* prefer a mode pretty much anyone can handle.
> > +*/
> > + ret = drm_add_modes_noedid(connector, 1920, 1200);
> > + drm_set_preferred_mode(connector, 1024, 768);
> > + return ret;
> > }
> >
> > drm_connector_update_edid_property(connector, edid);
> > ret = drm_add_edid_modes(connector, edid);
> > kfree(edid);
> > - return ret;
> > -
> > -fallback:
> > - /*
> > -* In case we cannot retrieve the EDIDs (broken or missing i2c
> > -* bus), fallback on the XGA standards
> > -*/
> > - ret = drm_add_modes_noedid(connector, 1920, 1200);
> > -
> > - /* And prefer a mode pretty much anyone can handle */
> > - drm_set_preferred_mode(connector, 1024, 768);
> >
> > return ret;
> > }
> > @@ -88,16 +83,7 @@ simple_bridge_connector_detect(struct drm_connector
> > *connector, bool force)
> > {
> > struct simple_bridge *sbridge =
> > drm_connector_to_simple_bridge(connector);
> >
> > - /*
> > -* Even if we have an I2C bus, we can't assume that the cable
> > -* is disconnected if drm_probe_ddc fails. Some cables don't
> > -* wire the DDC pins, or the I2C bus might not be working at
> > -* all.
> > -*/
> > - if (sbridge->ddc && drm_probe_ddc(sbridge->ddc))
> > - return connector_status_connected;
> > -
> > - return connector_status_unknown;
> > + return drm_bridge_detect(sbridge->next_bridge);
> > }
> >
> > static const struct drm_connector_funcs simple_bridge_con_funcs = {
> > @@ -120,6 +106,11 @@ static int simple_bridge_attach(struct drm_bridge
> > *bridge,
> > return -EINVAL;
> > }
> >
> > +
Re: [PATCH] drm/amd/display: remove redundant assignment to variable dp_ref_clk_khz
Applied. thanks!
Alex
On Fri, Apr 10, 2020 at 7:46 AM Colin King wrote:
>
> From: Colin Ian King
>
> The variable dp_ref_clk_khz is being initialized with a value that is
> never read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c
> index 26db1c5d4e4d..b210f8e9d592 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c
> @@ -131,7 +131,7 @@ int dce_get_dp_ref_freq_khz(struct clk_mgr *clk_mgr_base)
> struct clk_mgr_internal *clk_mgr = TO_CLK_MGR_INTERNAL(clk_mgr_base);
> int dprefclk_wdivider;
> int dprefclk_src_sel;
> - int dp_ref_clk_khz = 60;
> + int dp_ref_clk_khz;
> int target_div;
>
> /* ASSERT DP Reference Clock source is from DFS*/
> --
> 2.25.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panfrost: add devfreq regulator support
On 13/04/2020 15:31, Clément Péron wrote:
Hi,
On Mon, 13 Apr 2020 at 16:18, Clément Péron wrote:
Hi Steven,
On Mon, 13 Apr 2020 at 15:18, Steven Price wrote:
On 11/04/2020 21:06, Clément Péron wrote:
OPP table can defined both frequency and voltage.
Register the mali regulator if it exist.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 34 ++---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 62541f4edd81..2dc8e2355358 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -78,12 +78,26 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct device *dev = >pdev->dev;
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+ const char *mali = "mali";
+ struct opp_table *opp_table = NULL;
+
+ /* Regulator is optional */
+ opp_table = dev_pm_opp_set_regulators(dev, , 1);
This looks like it applies before 3e1399bccf51 ("drm/panfrost: Add
support for multiple regulators") which is currently in drm-misc-next
(and linux-next). You want something more like:
Thanks for you review, indeed I didn't see that multiple regulators
support has been added.
Will update in v2.
opp_table = dev_pm_opp_set_regulators(dev,
pfdev->comp->supply_names,
pfdev->comp->num_supplies);
Otherwise a platform with multiple regulators won't work correctly.
Also running on my firefly (RK3288) board I get the following warning:
debugfs: Directory 'ffa3.gpu-mali' with parent 'vdd_gpu' already
present!
This is due to the regulator debugfs entries getting created twice (once
in panfrost_regulator_init() and once here).
Is it a warning that should be consider as an error? Look's more an info no?
What should be the correct behavior if a device want to register two
times the same regulator?
Or we can change the name from vdd_XXX to opp_vdd_XXX ?
https://elixir.bootlin.com/linux/latest/source/drivers/opp/debugfs.c#L45
Yes, I'm not sure that it's actually a problem in practice. And it may
well be correct to change this in the generic code rather than try to
work around it in Panfrost. But we shouldn't spam the user with warnings
as that makes real issues harder to see.
Your suggestion to change the name seems reasonable to me, but I don't
fully understand the opp code, so we'd need some review from the OPP
maintainers. Hopefully Viresh, Nishanth or Stephen can provide some insight.
Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Break out the loops if need_resched in bo delayed delete worker
Can you make sure this lands in drm-misc?
Thanks,
Alex
On Fri, Apr 10, 2020 at 8:15 AM Koenig, Christian
wrote:
>
>
>
> Am 10.04.2020 12:58 schrieb "Pan, Xinhui" :
>
> The delayed delete list is per device which might be very huge. And in
> a heavy workload test, the list might always not be empty. That will
> trigger any RCU stall warnings or softlockups in non-preemptible kernels
> Lets do break out the loops in that case.
>
> Signed-off-by: xinhui pan
>
>
> Reviewed-by: Christian König
>
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 9e07c3f75156..c5b516fa4eae 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -518,7 +518,7 @@ static bool ttm_bo_delayed_delete(struct ttm_bo_device
> *bdev, bool remove_all)
> INIT_LIST_HEAD();
>
> spin_lock(>lru_lock);
> - while (!list_empty(>ddestroy)) {
> + while (!list_empty(>ddestroy) && !need_resched()) {
> struct ttm_buffer_object *bo;
>
> bo = list_first_entry(>ddestroy, struct
> ttm_buffer_object,
> --
> 2.17.1
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: remove defined but not used variables in ci_dpm.c
Applied. thanks!
Alex
On Mon, Apr 13, 2020 at 10:06 AM Jason Yan wrote:
>
> Fix the following gcc warning:
>
> drivers/gpu/drm/radeon/ci_dpm.c:82:36: warning: ‘defaults_saturn_pro’
> defined but not used [-Wunused-const-variable=]
> static const struct ci_pt_defaults defaults_saturn_pro =
> ^~~
> drivers/gpu/drm/radeon/ci_dpm.c:68:36: warning: ‘defaults_bonaire_pro’
> defined but not used [-Wunused-const-variable=]
> static const struct ci_pt_defaults defaults_bonaire_pro =
> ^~~~
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
> ---
> drivers/gpu/drm/radeon/ci_dpm.c | 14 --
> 1 file changed, 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
> index a9257bed3484..134aa2b01f90 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -65,13 +65,6 @@ static const struct ci_pt_defaults defaults_bonaire_xt =
> { 0x17C, 0x172, 0x180, 0x1BC, 0x1B3, 0x1BD, 0x206, 0x200, 0x203,
> 0x25D, 0x25A, 0x255, 0x2C3, 0x2C5, 0x2B4 }
> };
>
> -static const struct ci_pt_defaults defaults_bonaire_pro =
> -{
> - 1, 0xF, 0xFD, 0x19, 5, 45, 0, 0x65062,
> - { 0x8C, 0x23F, 0x244, 0xA6, 0x83, 0x85, 0x86, 0x86, 0x83,
> 0xDB, 0xDB, 0xDA, 0x67, 0x60, 0x5F },
> - { 0x187, 0x193, 0x193, 0x1C7, 0x1D1, 0x1D1, 0x210, 0x219, 0x219,
> 0x266, 0x26C, 0x26C, 0x2C9, 0x2CB, 0x2CB }
> -};
> -
> static const struct ci_pt_defaults defaults_saturn_xt =
> {
> 1, 0xF, 0xFD, 0x19, 5, 55, 0, 0x7,
> @@ -79,13 +72,6 @@ static const struct ci_pt_defaults defaults_saturn_xt =
> { 0x187, 0x187, 0x187, 0x1C7, 0x1C7, 0x1C7, 0x210, 0x210, 0x210,
> 0x266, 0x266, 0x266, 0x2C9, 0x2C9, 0x2C9 }
> };
>
> -static const struct ci_pt_defaults defaults_saturn_pro =
> -{
> - 1, 0xF, 0xFD, 0x19, 5, 55, 0, 0x3,
> - { 0x96, 0x21D, 0x23B, 0xA1, 0x85, 0x87, 0x83, 0x84, 0x81,
> 0xE6, 0xE6, 0xE6, 0x71, 0x6A, 0x6A },
> - { 0x193, 0x19E, 0x19E, 0x1D2, 0x1DC, 0x1DC, 0x21A, 0x223, 0x223,
> 0x26E, 0x27E, 0x274, 0x2CF, 0x2D2, 0x2D2 }
> -};
> -
> static const struct ci_pt_config_reg didt_config_ci[] =
> {
> { 0x10, 0x00ff, 0, 0x0, CISLANDS_CONFIGREG_DIDT_IND },
> --
> 2.21.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: remove defined but not used 'dte_data_tahiti_le'
Applied. thanks!
Alex
On Mon, Apr 13, 2020 at 10:06 AM Jason Yan wrote:
>
> Fix the following gcc warning:
>
> drivers/gpu/drm/radeon/si_dpm.c:255:33: warning: ‘dte_data_tahiti_le’
> defined but not used [-Wunused-const-variable=]
> static const struct si_dte_data dte_data_tahiti_le =
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
> ---
> drivers/gpu/drm/radeon/si_dpm.c | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
> index 2cb85dbe728f..a167e1c36d24 100644
> --- a/drivers/gpu/drm/radeon/si_dpm.c
> +++ b/drivers/gpu/drm/radeon/si_dpm.c
> @@ -252,24 +252,6 @@ static const struct si_dte_data dte_data_tahiti =
> false
> };
>
> -static const struct si_dte_data dte_data_tahiti_le =
> -{
> - { 0x1E8480, 0x7A1200, 0x2160EC0, 0x3938700, 0 },
> - { 0x7D, 0x7D, 0x4E4, 0xB00, 0 },
> - 0x5,
> - 0xAFC8,
> - 0x64,
> - 0x32,
> - 1,
> - 0,
> - 0x10,
> - { 0x78, 0x7C, 0x82, 0x88, 0x8E, 0x94, 0x9A, 0xA0, 0xA6, 0xAC, 0xB0,
> 0xB4, 0xB8, 0xBC, 0xC0, 0xC4 },
> - { 0x3938700, 0x3938700, 0x3938700, 0x3938700, 0x3938700, 0x3938700,
> 0x3938700, 0x3938700, 0x3938700, 0x3938700, 0x3938700, 0x3938700, 0x3938700,
> 0x3938700, 0x3938700, 0x3938700 },
> - { 0x2AF8, 0x2AF8, 0x29BB, 0x27F9, 0x2637, 0x2475, 0x22B3, 0x20F1,
> 0x1F2F, 0x1D6D, 0x1734, 0x1414, 0x10F4, 0xDD4, 0xAB4, 0x794 },
> - 85,
> - true
> -};
> -
> static const struct si_dte_data dte_data_tahiti_pro =
> {
> { 0x1E8480, 0x3D0900, 0x989680, 0x2625A00, 0x0 },
> --
> 2.21.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: remove dead code in si_dpm.c
Applied. Thanks!
On Mon, Apr 13, 2020 at 10:06 AM Jason Yan wrote:
>
> This code is dead, let's remove it.
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
> ---
> drivers/gpu/drm/amd/amdgpu/si_dpm.c | 20
> 1 file changed, 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> index 0860e85a2d35..c00ba4b23c9a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
> @@ -345,26 +345,6 @@ static const struct si_dte_data dte_data_tahiti =
> false
> };
>
> -#if 0
> -static const struct si_dte_data dte_data_tahiti_le =
> -{
> - { 0x1E8480, 0x7A1200, 0x2160EC0, 0x3938700, 0 },
> - { 0x7D, 0x7D, 0x4E4, 0xB00, 0 },
> - 0x5,
> - 0xAFC8,
> - 0x64,
> - 0x32,
> - 1,
> - 0,
> - 0x10,
> - { 0x78, 0x7C, 0x82, 0x88, 0x8E, 0x94, 0x9A, 0xA0, 0xA6, 0xAC, 0xB0,
> 0xB4, 0xB8, 0xBC, 0xC0, 0xC4 },
> - { 0x3938700, 0x3938700, 0x3938700, 0x3938700, 0x3938700, 0x3938700,
> 0x3938700, 0x3938700, 0x3938700, 0x3938700, 0x3938700, 0x3938700, 0x3938700,
> 0x3938700, 0x3938700, 0x3938700 },
> - { 0x2AF8, 0x2AF8, 0x29BB, 0x27F9, 0x2637, 0x2475, 0x22B3, 0x20F1,
> 0x1F2F, 0x1D6D, 0x1734, 0x1414, 0x10F4, 0xDD4, 0xAB4, 0x794 },
> - 85,
> - true
> -};
> -#endif
> -
> static const struct si_dte_data dte_data_tahiti_pro =
> {
> { 0x1E8480, 0x3D0900, 0x989680, 0x2625A00, 0x0 },
> --
> 2.21.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/amd/amdgpu: Add print format prefix
On Wed, Apr 8, 2020 at 9:42 PM Aurabindo Pillai wrote: > > Changes in v2 > > * Add dev_fmt format prefix > * Removed hardcoded module names in pr_* and dev_* prints > > Aurabindo Pillai (3): > drm/amd/amdgpu: add prefix for pr_* prints > drm/amd/amdgpu: add print prefix for dev_* variants > drm/amd/amdgpu: remove hardcoded module name in prints Applied. thanks! Alex > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 12 > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 +++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++-- > drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 2 +- > drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c| 2 +- > drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c| 2 +- > 7 files changed, 21 insertions(+), 9 deletions(-) > > -- > 2.26.0 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: code clean up in dce80_hw_sequencer.c
On Mon, Apr 13, 2020 at 5:29 AM Jason Yan wrote:
>
> Fix the following gcc warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_hw_sequencer.c:43:46:
> warning: ‘reg_offsets’ defined but not used [-Wunused-const-variable=]
> static const struct dce80_hw_seq_reg_offsets reg_offsets[] = {
> ^~~
>
> Reported-by: Hulk Robot
> Signed-off-by: Jason Yan
Applied. Thanks!
Alex
> ---
> .../amd/display/dc/dce80/dce80_hw_sequencer.c | 28 ---
> 1 file changed, 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_hw_sequencer.c
> b/drivers/gpu/drm/amd/display/dc/dce80/dce80_hw_sequencer.c
> index 893261c81854..d2ceebdbdf51 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_hw_sequencer.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_hw_sequencer.c
> @@ -36,34 +36,6 @@
> #include "dce/dce_8_0_d.h"
> #include "dce/dce_8_0_sh_mask.h"
>
> -struct dce80_hw_seq_reg_offsets {
> - uint32_t crtc;
> -};
> -
> -static const struct dce80_hw_seq_reg_offsets reg_offsets[] = {
> -{
> - .crtc = (mmCRTC0_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
> -},
> -{
> - .crtc = (mmCRTC1_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
> -},
> -{
> - .crtc = (mmCRTC2_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
> -},
> -{
> - .crtc = (mmCRTC3_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
> -},
> -{
> - .crtc = (mmCRTC4_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
> -},
> -{
> - .crtc = (mmCRTC5_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
> -}
> -};
> -
> -#define HW_REG_CRTC(reg, id)\
> - (reg + reg_offsets[id].crtc)
> -
>
> /***
> * Private definitions
>
> **/
> --
> 2.21.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: hdmi ddc clk: Fix size of m divider
On Mon, Apr 13, 2020 at 6:11 PM Chen-Yu Tsai wrote:
>
> On Mon, Apr 13, 2020 at 5:55 PM Jernej Skrabec
> wrote:
> >
> > m divider in DDC clock register is 4 bits wide. Fix that.
> >
> > Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> > Signed-off-by: Jernej Skrabec
>
> Reviewed-by: Chen-Yu Tsai
Cc stable?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: Fix drm_dp_mst_topology.c selftest compilation warning
On Mon, Apr 13, 2020 at 5:29 AM Tang Bin wrote:
>
> The struct drm_dp_desc contains struct drm_dp_dpcd_ident, and the struct
> drm_dp_dpcd_ident contains the array, so zero-initialization requires a
> more couple of braces. In the ARM compiler environment, the compile
> warning pointing it out:
> drivers/gpu/drm/drm_dp_mst_topology.c: In function
> 'drm_dp_mst_dsc_aux_for_port':
> drivers/gpu/drm/drm_dp_mst_topology.c:5494:9: warning: missing braces
> around initializer [-Wmissing-braces]
> struct drm_dp_desc desc = { 0 };
>
This seems to vary based on compilers. Maybe a memset would be better.
Alex
> Signed-off-by: Tang Bin
> Signed-off-by: Shengju Zhang
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 70c4b7a..4d8d1fd 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -5494,7 +5494,7 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
> drm_dp_mst_port *port)
> {
> struct drm_dp_mst_port *immediate_upstream_port;
> struct drm_dp_mst_port *fec_port;
> - struct drm_dp_desc desc = { 0 };
> + struct drm_dp_desc desc = { { { 0 } } };
> u8 endpoint_fec;
> u8 endpoint_dsc;
>
> --
> 2.7.4
>
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panfrost: add devfreq regulator support
On 11/04/2020 21:06, Clément Péron wrote:
OPP table can defined both frequency and voltage.
Register the mali regulator if it exist.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 34 ++---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 62541f4edd81..2dc8e2355358 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -78,12 +78,26 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct device *dev = >pdev->dev;
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+ const char *mali = "mali";
+ struct opp_table *opp_table = NULL;
+
+ /* Regulator is optional */
+ opp_table = dev_pm_opp_set_regulators(dev, , 1);
This looks like it applies before 3e1399bccf51 ("drm/panfrost: Add
support for multiple regulators") which is currently in drm-misc-next
(and linux-next). You want something more like:
opp_table = dev_pm_opp_set_regulators(dev,
pfdev->comp->supply_names,
pfdev->comp->num_supplies);
Otherwise a platform with multiple regulators won't work correctly.
Also running on my firefly (RK3288) board I get the following warning:
debugfs: Directory 'ffa3.gpu-mali' with parent 'vdd_gpu' already
present!
This is due to the regulator debugfs entries getting created twice (once
in panfrost_regulator_init() and once here).
I have been taking a look at doing the same thing (I picked up Martin
Blumenstingl's patch series[1]), but haven't had much time to focus on
this recently.
Thanks,
Steve
[1]
https://lore.kernel.org/dri-devel/20200112001623.2121227-1-martin.blumensti...@googlemail.com/
+ if (IS_ERR(opp_table)) {
+ ret = PTR_ERR(opp_table);
+ if (ret != -ENODEV) {
+ DRM_DEV_ERROR(dev, "Failed to set regulator: %d\n",
ret);
+ return ret;
+ }
+ }
+ pfdev->devfreq.opp_table = opp_table;
ret = dev_pm_opp_of_add_table(dev);
- if (ret == -ENODEV) /* Optional, continue without devfreq */
- return 0;
- else if (ret)
- return ret;
+ if (ret) {
+ if (ret == -ENODEV) /* Optional, continue without devfreq */
+ ret = 0;
+ goto err_opp_reg;
+ }
panfrost_devfreq_reset(pfdev);
@@ -119,6 +133,12 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
err_opp:
dev_pm_opp_of_remove_table(dev);
+err_opp_reg:
+ if (pfdev->devfreq.opp_table) {
+ dev_pm_opp_put_regulators(pfdev->devfreq.opp_table);
+ pfdev->devfreq.opp_table = NULL;
+ }
+
return ret;
}
@@ -126,7 +146,13 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
{
if (pfdev->devfreq.cooling)
devfreq_cooling_unregister(pfdev->devfreq.cooling);
+
dev_pm_opp_of_remove_table(>pdev->dev);
+
+ if (pfdev->devfreq.opp_table) {
+ dev_pm_opp_put_regulators(pfdev->devfreq.opp_table);
+ pfdev->devfreq.opp_table = NULL;
+ }
}
void panfrost_devfreq_resume(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 06713811b92c..f6b0c779dfe5 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -86,6 +86,7 @@ struct panfrost_device {
struct {
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+ struct opp_table *opp_table;
ktime_t busy_time;
ktime_t idle_time;
ktime_t time_last_update;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/panfrost: missing remove opp table in case of failure
On 11/04/2020 21:06, Clément Péron wrote:
In case of failure we need to remove OPP table.
Use Linux classic error handling with goto usage.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 413987038fbf..62541f4edd81 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -90,8 +90,11 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
cur_freq = clk_get_rate(pfdev->clock);
opp = devfreq_recommended_opp(dev, _freq, 0);
- if (IS_ERR(opp))
- return PTR_ERR(opp);
+ if (IS_ERR(opp)) {
+ DRM_DEV_ERROR(dev, "Failed to set recommended OPP\n");
+ ret = PTR_ERR(opp);
+ goto err_opp;
+ }
panfrost_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
@@ -100,8 +103,8 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
if (IS_ERR(devfreq)) {
DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
- dev_pm_opp_of_remove_table(dev);
- return PTR_ERR(devfreq);
+ ret = PTR_ERR(devfreq);
+ goto err_opp;
}
pfdev->devfreq.devfreq = devfreq;
@@ -112,6 +115,11 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
pfdev->devfreq.cooling = cooling;
return 0;
+
+err_opp:
+ dev_pm_opp_of_remove_table(dev);
+
+ return ret;
}
void panfrost_devfreq_fini(struct panfrost_device *pfdev)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: BUG: kernel NULL pointer dereference, address: 0000000000000026 after switching to 5.7 kernel
[AMD Official Use Only - Internal Distribution Only] You can add a Reviewed-By and Tested-By for me on this patch, unless you want me to send it out instead, then you can review it. Kent > -Original Message- > From: amd-gfx On Behalf Of > Christian König > Sent: Saturday, April 11, 2020 5:57 AM > To: Mikhail Gavrilov ; amd-gfx list > ; dri-devel > ; Linux List Kernel Mailing > ; Grodzovsky, Andrey > ; Russell, Kent > Subject: Re: BUG: kernel NULL pointer dereference, address: > 0026 after switching to 5.7 kernel > > Yeah, that is a known issue. > > You could try the attached patch, but please be aware that it is not > even compile tested because of the Easter holidays here. > > Thanks, > Christian. > > Am 10.04.20 um 21:51 schrieb Mikhail Gavrilov: > > Hi folks. > > After upgrade kernel to 5.7 I see every boot in kernel log following > > error messages: > > > > [2.569513] [drm] Found UVD firmware ENC: 1.2 DEC: .43 Family ID: 19 > > [2.569538] [drm] PSP loading UVD firmware > > [2.570038] BUG: kernel NULL pointer dereference, address: > 0026 > > [2.570045] #PF: supervisor read access in kernel mode > > [2.570050] #PF: error_code(0x) - not-present page > > [2.570055] PGD 0 P4D 0 > > [2.570060] Oops: [#1] SMP NOPTI > > [2.570065] CPU: 5 PID: 667 Comm: uvd_enc_1.1 Not tainted > > 5.7.0-0.rc0.git6.1.2.fc33.x86_64 #1 > > [2.570072] Hardware name: System manufacturer System Product > > Name/ROG STRIX X570-I GAMING, BIOS 1405 11/19/2019 > > [2.570085] RIP: 0010:__kthread_should_park+0x5/0x30 > > [2.570090] Code: 00 e9 fe fe ff ff e8 ca 3a 08 00 e9 49 fe ff ff > > 48 89 df e8 dd 38 08 00 84 c0 0f 84 6a ff ff ff e9 a6 fe ff ff 0f 1f > > 44 00 00 47 26 20 74 12 48 8b 87 88 09 00 00 48 8b 00 48 c1 e8 > > 02 > > 83 e0 > > [2.570103] RSP: 0018:ad8141723e50 EFLAGS: 00010246 > > [2.570107] RAX: 7fff RBX: 8a8d1d116ed8 RCX: > > > [2.570112] RDX: RSI: RDI: > > > [2.570116] RBP: 8a8d28c11300 R08: R09: > > > [2.570120] R10: R11: R12: > 8a8d1d152e40 > > [2.570125] R13: 8a8d1d117280 R14: 8a8d1d116ed8 R15: > 8a8d1ca68000 > > [2.570131] FS: () GS:8a8d3aa0() > > knlGS: > > [2.570137] CS: 0010 DS: ES: CR0: 80050033 > > [2.570142] CR2: 0026 CR3: 0007e3dc6000 CR4: > 003406e0 > > [2.570147] Call Trace: > > [2.570157] drm_sched_get_cleanup_job+0x42/0x130 [gpu_sched] > > [2.570166] drm_sched_main+0x6f/0x530 [gpu_sched] > > [2.570173] ? lockdep_hardirqs_on+0x11e/0x1b0 > > [2.570179] ? drm_sched_get_cleanup_job+0x130/0x130 [gpu_sched] > > [2.570185] kthread+0x131/0x150 > > [2.570189] ? __kthread_bind_mask+0x60/0x60 > > [2.570196] ret_from_fork+0x27/0x50 > > [2.570203] Modules linked in: fjes(-) amdgpu(+) amd_iommu_v2 > > gpu_sched ttm drm_kms_helper drm crc32c_intel igb nvme nvme_core dca > > i2c_algo_bit wmi pinctrl_amd br_netfilter bridge stp llc fuse > > [2.570223] CR2: 0026 > > [2.570228] ---[ end trace 80c25d326e1e0d7c ]--- > > [2.570233] RIP: 0010:__kthread_should_park+0x5/0x30 > > [2.570238] Code: 00 e9 fe fe ff ff e8 ca 3a 08 00 e9 49 fe ff ff > > 48 89 df e8 dd 38 08 00 84 c0 0f 84 6a ff ff ff e9 a6 fe ff ff 0f 1f > > 44 00 00 47 26 20 74 12 48 8b 87 88 09 00 00 48 8b 00 48 c1 e8 > > 02 > > 83 e0 > > [2.570250] RSP: 0018:ad8141723e50 EFLAGS: 00010246 > > [2.570255] RAX: 7fff RBX: 8a8d1d116ed8 RCX: > > > [2.570260] RDX: RSI: RDI: > > > [2.570265] RBP: 8a8d28c11300 R08: R09: > > > [2.570271] R10: R11: R12: > 8a8d1d152e40 > > [2.570276] R13: 8a8d1d117280 R14: 8a8d1d116ed8 R15: > 8a8d1ca68000 > > [2.570281] FS: () GS:8a8d3aa0() > > knlGS: > > [2.570287] CS: 0010 DS: ES: CR0: 80050033 > > [2.570292] CR2: 0026 CR3: 0007e3dc6000 CR4: > 003406e0 > > [2.570299] BUG: sleeping function called from invalid context at > > include/linux/percpu-rwsem.h:49 > > [2.570306] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: > > 667, name: uvd_enc_1.1 > > [2.570311] INFO: lockdep is turned off. > > [2.570315] irq event stamp: 14 > > [2.570319] hardirqs last enabled at (13): [] > > _raw_spin_unlock_irqrestore+0x46/0x60 > > [2.570330] hardirqs last disabled at (14): [] > > trace_hardirqs_off_thunk+0x1a/0x1c > > [2.570338] softirqs last enabled at (0): [] > > copy_process+0x706/0x1bc0 > > [2.570345] softirqs last disabled at (0):
Re: [PATCH] drm/sun4i: hdmi ddc clk: Fix size of m divider
On Mon, Apr 13, 2020 at 5:55 PM Jernej Skrabec wrote:
>
> m divider in DDC clock register is 4 bits wide. Fix that.
>
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> Signed-off-by: Jernej Skrabec
Reviewed-by: Chen-Yu Tsai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h:178 mdp5_bind
While booting stable-rc 4.14 branch kernel this warning was noticed on Qualcomm APQ 8016 SBC (DT) Dragonboard 410c device. [8.459580] clk: failed to reparent byte0_clk_src to dsi0pllbyte: -22 [8.459724] clk: failed to reparent pclk0_clk_src to dsi0pll: -22 [8.466474] msm 1a0.mdss: Using legacy clk name binding. Use \"iface\" instead of \"iface_clk\" [8.476753] msm 1a0.mdss: Using legacy clk name binding. Use \"bus\" instead of \"bus_clk\" [8.480055] msm 1a0.mdss: Using legacy clk name binding. Use \"vsync\" instead of \"vsync_clk\" [8.489023] msm 1a0.mdss: 1a0.mdss supply vdd not found, using dummy regulator [8.498450] msm_mdp 1a01000.mdp: Using legacy clk name binding. Use \"bus\" instead of \"bus_clk\" [8.505394] msm_mdp 1a01000.mdp: Using legacy clk name binding. Use \"iface\" instead of \"iface_clk\" [8.524724] msm_mdp 1a01000.mdp: Using legacy clk name binding. Use \"core\" instead of \"core_clk\" [8.524877] msm_mdp 1a01000.mdp: Using legacy clk name binding. Use \"vsync\" instead of \"vsync_clk\"[8.532846] [ cut here ] [8.541651] WARNING: CPU: 1 PID: 32 at /usr/src/kernel/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h:178 mdp5_bind+0x418/0x4e0 [msm] [8.546303] Modules linked in: crc32_ce adv7511 rfkill msm mdt_loader drm_kms_helper drm msm_rng rng_core fuse [8.557504] CPU: 1 PID: 32 Comm: kworker/1:1 Not tainted 4.14.176-rc1 #1 [8.567478] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [8.574344] Workqueue: events deferred_probe_work_func [8.581018] task: 80003d764680 task.stack: 0a4c [8.586178] PC is at mdp5_bind+0x418/0x4e0 [msm] [8.591989] LR is at mdp5_bind+0x1b4/0x4e0 [msm] [8.596644] pc : [] lr : [] pstate: 6145 [8.601246] sp : 0a4c39d0 [8.608617] x29: 0a4c39d0 x28: [8.611832] x27: 800037db4a00 x26: 00eec9e8 [8.617214] x25: 800037e28000 x24: 800037dc3810 [8.622509] x23: 800037ca7000 x22: 0a22e4b0 [8.627805] x21: 800037dc3800 x20: [8.633100] x19: 80003a8c2880 x18: 0010 [8.638395] x17: b6f9ba28 x16: 082fd6e0 [8.643691] x15: x14: [8.648986] x13: x12: e3d3f2dc [8.654280] x11: 80003d764eb0 x10: 0a20 [8.659576] x9 : fffe x8 : [8.664871] x7 : 087c908c x6 : [8.670167] x5 : 0040 x4 : 0004 [8.675461] x3 : feb0 x2 : 09d5f1a0 [8.680755] x1 : 80003d764680 x0 : [8.686052] Call trace: [8.691346] Exception stack(0x0a4c3890 to 0x0a4c39d0) [8.693521] 3880: 80003d764680 [8.700120] 38a0: 09d5f1a0 feb0 0004 0040 [8.707934] 38c0: 087c908c fffe [8.715746] 38e0: 0a20 80003d764eb0 e3d3f2dc [8.723558] 3900: 082fd6e0 b6f9ba28 [8.731372] 3920: 0010 80003a8c2880 800037dc3800 [8.739183] 3940: 0a22e4b0 800037ca7000 800037dc3810 800037e28000 [8.746997] 3960: 00eec9e8 800037db4a00 0a4c39d0 [8.754809] 3980: 00ebd494 0a4c39d0 00ebd6f8 6145 [8.762622] 39a0: 0a4c39d0 00ebd494 [8.770431] 39c0: 0a4c39d0 00ebd6f8 [8.778452] [] mdp5_bind+0x418/0x4e0 [msm] [8.782937] [] component_bind_all+0x104/0x298 [8.789040] [] msm_drm_bind+0x140/0x5f0 [msm] [8.794481] [] try_to_bring_up_master+0x180/0x1e0 [8.800380] [] component_add+0xa8/0x170 [8.806845] [] dsi_dev_probe+0x24/0x38 [msm] [8.812199] [] platform_drv_probe+0x60/0xc0 [8.817913] [] driver_probe_device+0x218/0x2e0 [8.823730] [] __device_attach_driver+0xa4/0xf0 [8.829810] [] bus_for_each_drv+0x5c/0xa8 [8.835797] [] __device_attach+0xd0/0x148 [8.841177] [] device_initial_probe+0x24/0x30 [8.846734] [] bus_probe_device+0xa0/0xa8 [8.852638] [] deferred_probe_work_func+0xac/0x158 [8.858195] [] process_one_work+0x278/0x790 [8.864800] [] worker_thread+0x50/0x480 [8.870441] [] kthread+0x138/0x140 [8.875823] [] ret_from_fork+0x10/0x1c [8.880846] ---[ end trace 73f4fbf7f1caf3f2 ]--- [8.886661] msm 1a0.mdss: bound 1a01000.mdp (ops mdp5_ops [msm]) [8.891128] msm_dsi 1a98000.dsi: 1a98000.dsi supply gdsc not found, using dummy regulator [8.897939] [ cut here ] [8.905384] WARNING: CPU: 1 PID: 2210 at /usr/src/kernel/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c:253 mdp5_disable+0xa0/0xb8 [msm] [
Re: [PATCH] drm: kirin: Revert change to add register connect helper functions
On Thu, 9 Apr 2020 at 08:43, John Stultz wrote:
>
> Daniel noted[1] that commit d606dc9a6323 ("drm: kirin: Add
> register connect helper functions in drm init") was unnecessary
> and incorrect, as drm_dev_register does register connectors for
> us.
>
> Thus, this patch reverts the change as suggested by Daniel.
>
> [1]:
> https://lore.kernel.org/lkml/CAKMK7uHr5U-pPsxdQ4MpfK5v8iLjphDFug_3VTiUAf06nhS=y...@mail.gmail.com/
>
> Cc: Xu YiPing
> Cc: Rongrong Zou
> Cc: Xinliang Liu
> Cc: Xinwei Kong
> Cc: Chen Feng
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: dri-devel
> Signed-off-by: John Stultz
Thanks John for the fix.
Acked-by: Xinliang Liu
Applied to drm-misc.
-Xinliang
> ---
> .../gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 1 -
> .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 43 ---
> .../gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 1 -
> 3 files changed, 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> index 86000127d4ee..c339e632522a 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -940,7 +940,6 @@ static struct drm_driver ade_driver = {
> };
>
> struct kirin_drm_data ade_driver_data = {
> - .register_connects = false,
> .num_planes = ADE_CH_NUM,
> .prim_plane = ADE_CH1,
> .channel_formats = channel_formats,
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index d3145ae877d7..4349da3e2379 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -219,40 +219,6 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
> return 0;
> }
>
> -static int kirin_drm_connectors_register(struct drm_device *dev)
> -{
> - struct drm_connector *connector;
> - struct drm_connector *failed_connector;
> - struct drm_connector_list_iter conn_iter;
> - int ret;
> -
> - mutex_lock(>mode_config.mutex);
> - drm_connector_list_iter_begin(dev, _iter);
> - drm_for_each_connector_iter(connector, _iter) {
> - ret = drm_connector_register(connector);
> - if (ret) {
> - failed_connector = connector;
> - goto err;
> - }
> - }
> - drm_connector_list_iter_end(_iter);
> - mutex_unlock(>mode_config.mutex);
> -
> - return 0;
> -
> -err:
> - drm_connector_list_iter_begin(dev, _iter);
> - drm_for_each_connector_iter(connector, _iter) {
> - if (failed_connector == connector)
> - break;
> - drm_connector_unregister(connector);
> - }
> - drm_connector_list_iter_end(_iter);
> - mutex_unlock(>mode_config.mutex);
> -
> - return ret;
> -}
> -
> static int kirin_drm_bind(struct device *dev)
> {
> struct kirin_drm_data *driver_data;
> @@ -279,17 +245,8 @@ static int kirin_drm_bind(struct device *dev)
>
> drm_fbdev_generic_setup(drm_dev, 32);
>
> - /* connectors should be registered after drm device register */
> - if (driver_data->register_connects) {
> - ret = kirin_drm_connectors_register(drm_dev);
> - if (ret)
> - goto err_drm_dev_unregister;
> - }
> -
> return 0;
>
> -err_drm_dev_unregister:
> - drm_dev_unregister(drm_dev);
> err_kms_cleanup:
> kirin_drm_kms_cleanup(drm_dev);
> err_drm_dev_put:
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> index 4d5c05a24065..dee8ec2f7f2e 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> @@ -37,7 +37,6 @@ struct kirin_drm_data {
> u32 channel_formats_cnt;
> int config_max_width;
> int config_max_height;
> - bool register_connects;
> u32 num_planes;
> u32 prim_plane;
>
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: code clean up in dce80_hw_sequencer.c
Fix the following gcc warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_hw_sequencer.c:43:46:
warning: ‘reg_offsets’ defined but not used [-Wunused-const-variable=]
static const struct dce80_hw_seq_reg_offsets reg_offsets[] = {
^~~
Reported-by: Hulk Robot
Signed-off-by: Jason Yan
---
.../amd/display/dc/dce80/dce80_hw_sequencer.c | 28 ---
1 file changed, 28 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_hw_sequencer.c
b/drivers/gpu/drm/amd/display/dc/dce80/dce80_hw_sequencer.c
index 893261c81854..d2ceebdbdf51 100644
--- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_hw_sequencer.c
@@ -36,34 +36,6 @@
#include "dce/dce_8_0_d.h"
#include "dce/dce_8_0_sh_mask.h"
-struct dce80_hw_seq_reg_offsets {
- uint32_t crtc;
-};
-
-static const struct dce80_hw_seq_reg_offsets reg_offsets[] = {
-{
- .crtc = (mmCRTC0_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
-},
-{
- .crtc = (mmCRTC1_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
-},
-{
- .crtc = (mmCRTC2_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
-},
-{
- .crtc = (mmCRTC3_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
-},
-{
- .crtc = (mmCRTC4_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
-},
-{
- .crtc = (mmCRTC5_CRTC_GSL_CONTROL - mmCRTC_GSL_CONTROL),
-}
-};
-
-#define HW_REG_CRTC(reg, id)\
- (reg + reg_offsets[id].crtc)
-
/***
* Private definitions
**/
--
2.21.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: make drm_file use keyed wakeups
Some processes, such as systemd, are only polling for EPOLLERR|EPOLLHUP. As drm_file uses unkeyed wakeups, such a poll receives many spurious wakeups from uninteresting events. Use keyed wakeups to allow the wakeup target to more efficiently discard these uninteresting events. Signed-off-by: Kenny Levinsen --- drivers/gpu/drm/drm_file.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c index c4c704e01961..ec25b3d979d9 100644 --- a/drivers/gpu/drm/drm_file.c +++ b/drivers/gpu/drm/drm_file.c @@ -608,7 +608,8 @@ ssize_t drm_read(struct file *filp, char __user *buffer, file_priv->event_space -= length; list_add(>link, _priv->event_list); spin_unlock_irq(>event_lock); - wake_up_interruptible(_priv->event_wait); + wake_up_interruptible_poll(_priv->event_wait, + EPOLLIN | EPOLLRDNORM); break; } @@ -804,7 +805,8 @@ void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e) list_del(>pending_link); list_add_tail(>link, >file_priv->event_list); - wake_up_interruptible(>file_priv->event_wait); + wake_up_interruptible_poll(>file_priv->event_wait, + EPOLLIN | EPOLLRDNORM); } EXPORT_SYMBOL(drm_send_event_locked); -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Fix typo
Duplicated 'we' Signed-off-by: Christophe JAILLET --- drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c index 998bef1190a3..b5fed67c4651 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c @@ -959,7 +959,7 @@ static int mdp5_crtc_cursor_set(struct drm_crtc *crtc, if (!ctl) return -EINVAL; - /* don't support LM cursors when we we have source split enabled */ + /* don't support LM cursors when we have source split enabled */ if (mdp5_cstate->pipeline.r_mixer) return -EINVAL; @@ -1030,7 +1030,7 @@ static int mdp5_crtc_cursor_move(struct drm_crtc *crtc, int x, int y) return -EINVAL; } - /* don't support LM cursors when we we have source split enabled */ + /* don't support LM cursors when we have source split enabled */ if (mdp5_cstate->pipeline.r_mixer) return -EINVAL; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RESEND 2/2] drm: bridge: adv7511: Extend list of audio sample rates
> > ADV7511 support sample rates up to 192kHz. CTS and N parameters should > > be computed accordingly so this commit extend the list up to maximum > > supported sample rate. > > > > Signed-off-by: Bogdan Togorean > > --- > > drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c > b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c > > index 1e9b128d229b..13e8cee6e827 100644 > > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c > > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c > > @@ -27,6 +27,18 @@ static void adv7511_calc_cts_n(unsigned int f_tmds, > unsigned int fs, > > case 48000: > > *n = 6144; > > break; > > + case 88200: > > + *n = 12544; > > + break; > > + case 96000: > > + *n = 12288; > > + break; > > + case 176400: > > + *n = 25088; > > + break; > > + case 192000: > > + *n = 24576; > > + break; > > > I would put: > > case 32000: > case 48000: > case 96000: > case 192000: > *n = fs * 128 / 1000; > break; > case 44100: > case 88200: > case 176400: > *n = fs * 128 / 900; > break; > > To uncover the magic. Up to you. Great solution Andrzej, Thank you for your suggestion. Regards, Bogdan > > Reviewed-by: Andrzej Hajda > > > Regards > Andrzej > > } > > > > *cts = ((f_tmds * *n) / (128 * fs)) * 1000; > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: point to display schemas in DRM DRIVERS FOR ALLWINNER A10
Commit f5a98bfe7b37 ("dt-bindings: display: Convert Allwinner display
pipeline to schemas") replaced sunxi/sun4i-drm.txt with
allwinner,sun*.yaml files in Documentation/devicetree/bindings/display/,
but did not adjust DRM DRIVERS FOR ALLWINNER A10.
Since then, ./scripts/get_maintainer.pl --self-test complains:
warning: no file matches \
F: Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
Point to allwinner display schemas in DRM DRIVERS FOR ALLWINNER A10.
Signed-off-by: Lukas Bulwahn
---
Maxime, please ack.
Rob, please pick this non-urgent minor clean-up patch.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db31497..1f6c9bec872a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5552,7 +5552,7 @@ M:Chen-Yu Tsai
L: dri-devel@lists.freedesktop.org
S: Supported
T: git git://anongit.freedesktop.org/drm/drm-misc
-F: Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+F: Documentation/devicetree/bindings/display/allwinner,sun*.yaml
F: drivers/gpu/drm/sun4i/
DRM DRIVERS FOR AMLOGIC SOCS
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] dt-bindings: gpu: mali-utgard: Add the #cooling-cells property
The GPU can be one of the big heat sources on a SoC. Allow the "#cooling-cells" property to be specified for ARM Mali Utgard GPUs so the GPU clock speeds (and voltages) can be reduced to prevent a SoC from overheating. Reviewed-by: Qiang Yu Signed-off-by: Martin Blumenstingl --- Changes since v4 at [0]: - Added Qiang's Reviewed-by (many thanks) - re-send because I missed the devicetree mailing list in v4 [0] https://patchwork.kernel.org/patch/11448013/ Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml index f5401cc8de4a..4869258daadb 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml @@ -107,6 +107,9 @@ properties: operating-points-v2: true + "#cooling-cells": +const: 2 + required: - compatible - reg @@ -164,6 +167,7 @@ examples: clocks = < 1>, < 2>; clock-names = "bus", "core"; resets = < 1>; + #cooling-cells = <2>; }; ... -- 2.26.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Add missing '\n' in log messages
Message logged by 'dev_xxx()' or 'pr_xxx()' should end with a '\n'.
While at it, split some long lines that where not that far.
Signed-off-by: Christophe JAILLET
---
Most of them have been added in commit bd607166af7f ("drm/amdgpu: Enable
reading FRU chip via I2C v3")
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 87f7c129c8ce..3d0a50e8c36b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3249,25 +3249,25 @@ int amdgpu_device_init(struct amdgpu_device *adev,
r = device_create_file(adev->dev, _attr_pcie_replay_count);
if (r) {
- dev_err(adev->dev, "Could not create pcie_replay_count");
+ dev_err(adev->dev, "Could not create pcie_replay_count\n");
return r;
}
r = device_create_file(adev->dev, _attr_product_name);
if (r) {
- dev_err(adev->dev, "Could not create product_name");
+ dev_err(adev->dev, "Could not create product_name\n");
return r;
}
r = device_create_file(adev->dev, _attr_product_number);
if (r) {
- dev_err(adev->dev, "Could not create product_number");
+ dev_err(adev->dev, "Could not create product_number\n");
return r;
}
r = device_create_file(adev->dev, _attr_serial_number);
if (r) {
- dev_err(adev->dev, "Could not create serial_number");
+ dev_err(adev->dev, "Could not create serial_number\n");
return r;
}
@@ -4270,7 +4270,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
job_signaled = true;
if (job_signaled) {
- dev_info(adev->dev, "Guilty job already signaled, skipping HW
reset");
+ dev_info(adev->dev, "Guilty job already signaled, skipping HW
reset\n");
goto skip_hw_reset;
}
@@ -4339,10 +4339,12 @@ int amdgpu_device_gpu_recover(struct amdgpu_device
*adev,
if (r) {
/* bad news, how to tell it to userspace ? */
- dev_info(tmp_adev->dev, "GPU reset(%d) failed\n",
atomic_read(_adev->gpu_reset_counter));
+ dev_info(tmp_adev->dev, "GPU reset(%d) failed\n",
+atomic_read(_adev->gpu_reset_counter));
amdgpu_vf_error_put(tmp_adev,
AMDGIM_ERROR_VF_GPU_RESET_FAIL, 0, r);
} else {
- dev_info(tmp_adev->dev, "GPU reset(%d) succeeded!\n",
atomic_read(_adev->gpu_reset_counter));
+ dev_info(tmp_adev->dev, "GPU reset(%d) succeeded!\n",
+atomic_read(_adev->gpu_reset_counter));
}
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/panfrost: missing remove opp table in case of failure
In case of failure we need to remove OPP table.
Use Linux classic error handling with goto usage.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 413987038fbf..62541f4edd81 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -90,8 +90,11 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
cur_freq = clk_get_rate(pfdev->clock);
opp = devfreq_recommended_opp(dev, _freq, 0);
- if (IS_ERR(opp))
- return PTR_ERR(opp);
+ if (IS_ERR(opp)) {
+ DRM_DEV_ERROR(dev, "Failed to set recommended OPP\n");
+ ret = PTR_ERR(opp);
+ goto err_opp;
+ }
panfrost_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
@@ -100,8 +103,8 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
if (IS_ERR(devfreq)) {
DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
- dev_pm_opp_of_remove_table(dev);
- return PTR_ERR(devfreq);
+ ret = PTR_ERR(devfreq);
+ goto err_opp;
}
pfdev->devfreq.devfreq = devfreq;
@@ -112,6 +115,11 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
pfdev->devfreq.cooling = cooling;
return 0;
+
+err_opp:
+ dev_pm_opp_of_remove_table(dev);
+
+ return ret;
}
void panfrost_devfreq_fini(struct panfrost_device *pfdev)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dp_mst: Fix drm_dp_mst_topology.c selftest compilation warning
The struct drm_dp_desc contains struct drm_dp_dpcd_ident, and the struct
drm_dp_dpcd_ident contains the array, so zero-initialization requires a
more couple of braces. In the ARM compiler environment, the compile
warning pointing it out:
drivers/gpu/drm/drm_dp_mst_topology.c: In function
'drm_dp_mst_dsc_aux_for_port':
drivers/gpu/drm/drm_dp_mst_topology.c:5494:9: warning: missing braces
around initializer [-Wmissing-braces]
struct drm_dp_desc desc = { 0 };
Signed-off-by: Tang Bin
Signed-off-by: Shengju Zhang
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 70c4b7a..4d8d1fd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -5494,7 +5494,7 @@ struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct
drm_dp_mst_port *port)
{
struct drm_dp_mst_port *immediate_upstream_port;
struct drm_dp_mst_port *fec_port;
- struct drm_dp_desc desc = { 0 };
+ struct drm_dp_desc desc = { { { 0 } } };
u8 endpoint_fec;
u8 endpoint_dsc;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/panfrost: add devfreq regulator support
OPP table can defined both frequency and voltage.
Register the mali regulator if it exist.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 34 ++---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
2 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 62541f4edd81..2dc8e2355358 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -78,12 +78,26 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct device *dev = >pdev->dev;
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+ const char *mali = "mali";
+ struct opp_table *opp_table = NULL;
+
+ /* Regulator is optional */
+ opp_table = dev_pm_opp_set_regulators(dev, , 1);
+ if (IS_ERR(opp_table)) {
+ ret = PTR_ERR(opp_table);
+ if (ret != -ENODEV) {
+ DRM_DEV_ERROR(dev, "Failed to set regulator: %d\n",
ret);
+ return ret;
+ }
+ }
+ pfdev->devfreq.opp_table = opp_table;
ret = dev_pm_opp_of_add_table(dev);
- if (ret == -ENODEV) /* Optional, continue without devfreq */
- return 0;
- else if (ret)
- return ret;
+ if (ret) {
+ if (ret == -ENODEV) /* Optional, continue without devfreq */
+ ret = 0;
+ goto err_opp_reg;
+ }
panfrost_devfreq_reset(pfdev);
@@ -119,6 +133,12 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
err_opp:
dev_pm_opp_of_remove_table(dev);
+err_opp_reg:
+ if (pfdev->devfreq.opp_table) {
+ dev_pm_opp_put_regulators(pfdev->devfreq.opp_table);
+ pfdev->devfreq.opp_table = NULL;
+ }
+
return ret;
}
@@ -126,7 +146,13 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
{
if (pfdev->devfreq.cooling)
devfreq_cooling_unregister(pfdev->devfreq.cooling);
+
dev_pm_opp_of_remove_table(>pdev->dev);
+
+ if (pfdev->devfreq.opp_table) {
+ dev_pm_opp_put_regulators(pfdev->devfreq.opp_table);
+ pfdev->devfreq.opp_table = NULL;
+ }
}
void panfrost_devfreq_resume(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 06713811b92c..f6b0c779dfe5 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -86,6 +86,7 @@ struct panfrost_device {
struct {
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+ struct opp_table *opp_table;
ktime_t busy_time;
ktime_t idle_time;
ktime_t time_last_update;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] PM: sleep: core: Rename DPM_FLAG_NEVER_SKIP
On Fri, Apr 10, 2020 at 9:03 AM Rafael J. Wysocki wrote: > > From: "Rafael J. Wysocki" > > Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which > matches its purpose more closely. > > No functional impact. > > Signed-off-by: Rafael J. Wysocki Acked-by: Jeff Kirsher For the driver changes to e1000e, igb and igc. > --- > Documentation/driver-api/pm/devices.rst| 6 +++--- > Documentation/power/pci.rst| 10 +- > drivers/base/power/main.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 2 +- > drivers/gpu/drm/i915/intel_runtime_pm.c| 2 +- > drivers/gpu/drm/radeon/radeon_kms.c| 2 +- > drivers/misc/mei/pci-me.c | 2 +- > drivers/misc/mei/pci-txe.c | 2 +- > drivers/net/ethernet/intel/e1000e/netdev.c | 2 +- > drivers/net/ethernet/intel/igb/igb_main.c | 2 +- > drivers/net/ethernet/intel/igc/igc_main.c | 2 +- > drivers/pci/pcie/portdrv_pci.c | 2 +- > include/linux/pm.h | 6 +++--- > 13 files changed, 21 insertions(+), 21 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm: bridge: adv7511: Make connector creation optional
On Thu, Apr 09, 2020 at 03:46:10AM +0300, Laurent Pinchart wrote:
> Now that the driver supports all the connector-related bridge
> operations, make the connector creation optional. This enables usage of
> the adv7511 with the DRM bridge connector helper.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Sam Ravnborg
Sam
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 723560b36ee0..60efd19fa4df 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -902,17 +902,14 @@ static int adv7511_bridge_attach(struct drm_bridge
> *bridge,
>enum drm_bridge_attach_flags flags)
> {
> struct adv7511 *adv = bridge_to_adv7511(bridge);
> - int ret;
> + int ret = 0;
>
> - if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> - DRM_ERROR("Fix bridge driver to make connector optional!");
> - return -EINVAL;
> + if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
> + ret = adv7511_connector_init(adv);
> + if (ret < 0)
> + return ret;
> }
>
> - ret = adv7511_connector_init(adv);
> - if (ret < 0)
> - return ret;
> -
> if (adv->type == ADV7533 || adv->type == ADV7535)
> ret = adv7533_attach_dsi(adv);
>
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
