Re: [PATCH v6, 12/15] media: mtk-vcodec: Support 34bits dma address for vdec
Hi Benjiamin, On Thu, 2021-10-07 at 13:37 +0200, Benjamin Gaignard wrote: > Le 01/09/2021 à 10:32, Yunfei Dong a écrit : > > Use the dma_set_mask_and_coherent helper to set vdec > > DMA bit mask to support 34bits iova space(16GB) that > > the mt8192 iommu HW support. > > > > Whole the iova range separate to 0~4G/4G~8G/8G~12G/12G~16G, > > regarding which iova range VDEC actually locate, it > > depends on the dma-ranges property of vdec dtsi node. > > > > Signed-off-by: Yunfei Dong > > --- > > drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c > > b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c > > index 002352fcf8de..1a8d9308327d 100644 > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c > > @@ -417,6 +417,9 @@ static int mtk_vcodec_probe(struct > > platform_device *pdev) > > } > > } > > > > + if (of_get_property(pdev->dev.of_node, "dma-ranges", NULL)) > > + dma_set_mask_and_coherent(>dev, > > DMA_BIT_MASK(34)); > > + > > Hi Yunfei, > > Does all SoC support 34bits iova space ? > If not you need to also check SoC version before setting dma mask. > Not all SoC support 34bits. Will add dma-ranges property in dtsi if the SoC support 34bits. like this: dma-ranges = <>; Thanks, Yunfei Dong > Regards, > Benjamin > > > for (i = 0; i < MTK_VDEC_HW_MAX; i++) > > mutex_init(>dec_mutex[i]); > > spin_lock_init(>irqlock);
Re: [PATCH] drm: of: Add drm_of_lvds_get_data_mapping
Hi Marek,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master airlied/drm-next v5.15-rc5
next-20211008]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Marek-Vasut/drm-of-Add-drm_of_lvds_get_data_mapping/20211011-092451
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-m021-20211010 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/d9a4ed21a0ee9b11df5d862e54876002751fbd45
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Marek-Vasut/drm-of-Add-drm_of_lvds_get_data_mapping/20211011-092451
git checkout d9a4ed21a0ee9b11df5d862e54876002751fbd45
# save the attached .config to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/bridge/panel.c:12:
>> include/drm/drm_of.h:105:1: error: expected identifier or '(' before '{'
>> token
105 | {
| ^
include/drm/drm_of.h:104:1: warning: 'drm_of_lvds_get_data_mapping' declared
'static' but never defined [-Wunused-function]
104 | drm_of_lvds_get_data_mapping(const struct device_node *port);
| ^~~~
vim +105 include/drm/drm_of.h
102
103 static inline int
104 drm_of_lvds_get_data_mapping(const struct device_node *port);
> 105 {
106 return -EINVAL;
107 }
108 #endif
109
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] drm: of: Add drm_of_lvds_get_data_mapping
Add helper function to convert DT "data-mapping" property string value
into media bus format value, and deduplicate the code in panel-lvds.c
and lvds-codec.c .
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Sam Ravnborg
To: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/bridge/lvds-codec.c | 21 ++
drivers/gpu/drm/drm_of.c| 33 +
drivers/gpu/drm/panel/panel-lvds.c | 18
include/drm/drm_of.h| 7 ++
4 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
index ad460b96c0a3..f991842a161f 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
struct lvds_codec {
@@ -118,7 +119,6 @@ static int lvds_codec_probe(struct platform_device *pdev)
struct device_node *bus_node;
struct drm_panel *panel;
struct lvds_codec *lvds_codec;
- const char *mapping;
int ret;
lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
@@ -174,22 +174,15 @@ static int lvds_codec_probe(struct platform_device *pdev)
return -ENXIO;
}
- ret = of_property_read_string(bus_node, "data-mapping",
- );
+ ret = drm_of_lvds_get_data_mapping(bus_node);
of_node_put(bus_node);
- if (ret < 0) {
+ if (ret == -ENODEV) {
dev_warn(dev, "missing 'data-mapping' DT property\n");
+ } else if (ret) {
+ dev_err(dev, "invalid 'data-mapping' DT property\n");
+ return ret;
} else {
- if (!strcmp(mapping, "jeida-18")) {
- lvds_codec->bus_format =
MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
- } else if (!strcmp(mapping, "jeida-24")) {
- lvds_codec->bus_format =
MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
- } else if (!strcmp(mapping, "vesa-24")) {
- lvds_codec->bus_format =
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
- } else {
- dev_err(dev, "invalid 'data-mapping' DT
property\n");
- return -EINVAL;
- }
+ lvds_codec->bus_format = ret;
lvds_codec->bridge.funcs = _decoder;
}
}
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 37c34146eea8..a9217bc18e8f 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -402,3 +402,36 @@ int drm_of_lvds_get_dual_link_pixel_order(const struct
device_node *port1,
DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS;
}
EXPORT_SYMBOL_GPL(drm_of_lvds_get_dual_link_pixel_order);
+
+/**
+ * drm_of_lvds_get_data_mapping - Get LVDS data mapping
+ * @port: DT port node of the LVDS source or sink
+ *
+ * Convert DT "data-mapping" property string value into media bus format value.
+ *
+ * Return:
+ * MEDIA_BUS_FMT_RGB666_1X7X3_SPWG - data-mapping is "jeida-18"
+ * MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA - data-mapping is "jeida-24"
+ * MEDIA_BUS_FMT_RGB888_1X7X4_SPWG - data-mapping is "vesa-24"
+ * -EINVAL - the "data-mapping" property is unsupported
+ * -ENODEV - the "data-mapping" property is missing
+ */
+int drm_of_lvds_get_data_mapping(const struct device_node *port)
+{
+ const char *mapping;
+ int ret;
+
+ ret = of_property_read_string(port, "data-mapping", );
+ if (ret < 0)
+ return -ENODEV;
+
+ if (!strcmp(mapping, "jeida-18"))
+ return MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
+ if (!strcmp(mapping, "jeida-24"))
+ return MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
+ if (!strcmp(mapping, "vesa-24"))
+ return MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(drm_of_lvds_get_data_mapping);
diff --git a/drivers/gpu/drm/panel/panel-lvds.c
b/drivers/gpu/drm/panel/panel-lvds.c
index 59a8d99e777d..27a1c9923b09 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -20,6 +20,7 @@
#include
#include
+#include
#include
struct panel_lvds {
@@ -116,7 +117,6 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
{
struct device_node *np = lvds->dev->of_node;
struct display_timing timing;
- const char *mapping;
int ret;
ret = of_drm_get_panel_orientation(np, >orientation);
@@ -149,24 +149,14 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
of_property_read_string(np, "label", >label);
- ret = of_property_read_string(np, "data-mapping", );
+ ret = drm_of_lvds_get_data_mapping(np);
linux-next: manual merge of the drm tree with Linus' tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/include/dal_asic_id.h
between commit:
7ab0965079bb ("drm/amd/display: USB4 bring up set correct address")
from Linus' tree and commit:
13900e6fde3f ("drm/amd/display: Fix for null pointer access for ddc pin and
aux engine.")
from the drm tree.
I fixed it up (I used the former) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
pgpGPcpaFf_zx.pgp
Description: OpenPGP digital signature
Re: imx_ldb: lockdep warning on 5.14.x
On Sun, Oct 10, 2021 at 12:39 PM Fabio Estevam wrote: > > Hi, > > I am getting the lockdep warning below on a imx6q-sabred running 5.14.9. > > Haven't debugged this yet, but just wanted to report in case someone > has any suggestions. git bisect shows that the guilty commit is: commit f4b34faa08428d813fc3629f882c503487f94a12 Author: Daniel Vetter Date: Thu Jan 21 16:29:55 2021 +0100 drm/imx: Annotate dma-fence critical section in commit path drm_atomic_helper_commit_hw_done() is the last thing (no plane cleanup apparrently), so it's the entire function. And a nice comment explaining why the wait_for_flip_done is ahead, unlike the usual sequence. Aside, I think since the atomic helpers do track plane disabling now separately this might no longer be a real problem since: commit 21a01abbe32a3cbeb903378a24e504bfd9fe0648 Author: Maarten Lankhorst Date: Mon Sep 4 12:48:37 2017 +0200 drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3. Plus the subsequent bugfixes of course, this was tricky to get right. Signed-off-by: Daniel Vetter Cc: Philipp Zabel Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: linux-arm-ker...@lists.infradead.org Signed-off-by: Philipp Zabel If I revert this commit on top of 5.14, the lockdep warning is gone. Daniel, How do we fix this? Thanks
[PATCH -next v2] drm/connector: fix all kernel-doc warnings
Clean up all of the kernel-doc issues in drm_connector.c:
drivers/gpu/drm/drm_connector.c:2611: warning: Excess function parameter
'connector' description in 'drm_connector_oob_hotplug_event'
drivers/gpu/drm/drm_connector.c:2611: warning: Function parameter or member
'connector_fwnode' not described in 'drm_connector_oob_hotplug_event'
drm_connector.c:630: warning: No description found for return value of
'drm_get_connector_status_name'
drm_connector.c:715: warning: No description found for return value of
'drm_connector_list_iter_next'
drm_connector.c:785: warning: No description found for return value of
'drm_get_subpixel_order_name'
drm_connector.c:816: warning: No description found for return value of
'drm_display_info_set_bus_formats'
drm_connector.c:1331: warning: No description found for return value of
'drm_mode_create_dvi_i_properties'
drm_connector.c:1412: warning: No description found for return value of
'drm_connector_attach_content_type_property'
drm_connector.c:1492: warning: No description found for return value of
'drm_mode_create_tv_margin_properties'
drm_connector.c:1534: warning: No description found for return value of
'drm_mode_create_tv_properties'
drm_connector.c:1627: warning: No description found for return value of
'drm_mode_create_scaling_mode_property'
drm_connector.c:1944: warning: No description found for return value of
'drm_mode_create_suggested_offset_properties'
drm_connector.c:2315: warning: missing initial short description on line:
* drm_connector_set_panel_orientation_with_quirk -
[The last warning listed is probably a quirk/bug in scripts/kernel-doc.]
Fixes: 613051dac40d ("drm: locking iterators for connector_list")
Fixes: 522171951761 ("drm: Extract drm_connector.[hc]")
Fixes: b3c6c8bfe378 ("drm: document drm_display_info")
Fixes: 50525c332b55 ("drm: content-type property for HDMI connector")
Fixes: 6c4f52dca36f ("drm/connector: Allow creation of margin props alone")
Fixes: 69654c632d80 ("drm/connector: Split out orientation quirk detection
(v2)")
Fixes: 72ad49682dde ("drm/connector: Add support for out-of-band hotplug
notification (v3)")
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Stanislav Lisovskiy
Cc: Ville Syrjälä
Cc: Derek Basehore
Cc: Hans de Goede
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Sam Ravnborg
---
v2: drop Cc: Boris Brezillon [bounced]
Address Sam's comment on Returns:
72ad49682dde ("drm/connector: Add support for out-of-band hotplug notification
(v3)")
is only in linux-next. The others are in mainline.
drivers/gpu/drm/drm_connector.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
--- linux-next-20211007.orig/drivers/gpu/drm/drm_connector.c
+++ linux-next-20211007/drivers/gpu/drm/drm_connector.c
@@ -625,6 +625,8 @@ int drm_connector_register_all(struct dr
*
* In contrast to the other drm_get_*_name functions this one here returns a
* const pointer and hence is threadsafe.
+ *
+ * Returns: connector status string
*/
const char *drm_get_connector_status_name(enum drm_connector_status status)
{
@@ -707,7 +709,7 @@ __drm_connector_put_safe(struct drm_conn
* drm_connector_list_iter_next - return next connector
* @iter: connector_list iterator
*
- * Returns the next connector for @iter, or NULL when the list walk has
+ * Returns: the next connector for @iter, or NULL when the list walk has
* completed.
*/
struct drm_connector *
@@ -780,6 +782,8 @@ static const struct drm_prop_enum_list d
*
* Note you could abuse this and return something out of bounds, but that
* would be a caller error. No unscrubbed user data should make it here.
+ *
+ * Returns: string describing an enumerated subpixel property
*/
const char *drm_get_subpixel_order_name(enum subpixel_order order)
{
@@ -809,6 +813,9 @@ static const struct drm_prop_enum_list d
* Store the supported bus formats in display info structure.
* See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for
* a full list of available formats.
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
*/
int drm_display_info_set_bus_formats(struct drm_display_info *info,
const u32 *formats,
@@ -1326,6 +1333,8 @@ int drm_connector_create_standard_proper
* @dev: DRM device
*
* Called by a driver the first time a DVI-I connector is made.
+ *
+ * Returns: %0
*/
int drm_mode_create_dvi_i_properties(struct drm_device *dev)
{
@@ -1407,6 +1416,8 @@ EXPORT_SYMBOL(drm_connector_attach_dp_su
* @connector: connector to attach content type property on.
*
* Called by a driver the first time a HDMI connector is made.
+ *
+ * Returns: %0
*/
int drm_connector_attach_content_type_property(struct drm_connector *connector)
{
@@ -1487,6 +1498,9 @@ EXPORT_SYMBOL(drm_connector_attach_tv_ma
* creates the TV margin properties for a given device. No
Re: [PATCH v5 0/2] Add support for Sharp LS060T1SX01 panel
On Sun, 10 Oct 2021 at 20:33, Sam Ravnborg wrote: > > Hi Dmitry, > > On Sat, Oct 09, 2021 at 11:38:04PM +0300, Dmitry Baryshkov wrote: > > Add driver to support Sharp LS06T1SX01 6.0" FullHD panel found e.g. in > > the kwaek.ca Dragonboard Display Adapter Bundle. > > > > Changes since v4: > > - Use MIPI_DSI_MODE_NO_EOT_PACKET instead of the old name > > > > Changes since v3: > > - Replaced small msleeps with usleep_range > > > > Changes since v2: > > - Add missing power supplies used by the panel according to the > >datasheet > > > > Changes since v1: > > - Fix the id in the schema file > > > > > > Dmitry Baryshkov (2): > > dt-bindings: add bindings for the Sharp LS060T1SX01 panel > > drm/panel: Add support for Sharp LS060T1SX01 panel > > Applied to drm-misc-next and this time on purpose. > Thanks for the quick fixes. Thank you and sorry for the confusion/mess during the merge. -- With best wishes Dmitry
Re: [PATCH -next] drm/connector: fix all kernel-doc warnings
Hi Sam,
On 10/10/21 1:04 PM, Sam Ravnborg wrote:
Hi Randy,
I noticed a few things that in my opinion could be improved.
See below.
Sam
On Wed, Oct 06, 2021 at 05:53:05PM -0700, Randy Dunlap wrote:
Clean up all of the kernel-doc issues in drm_connector.c:
drivers/gpu/drm/drm_connector.c:2611: warning: Excess function parameter
'connector' description in 'drm_connector_oob_hotplug_event'
drivers/gpu/drm/drm_connector.c:2611: warning: Function parameter or member
'connector_fwnode' not described in 'drm_connector_oob_hotplug_event'
drm_connector.c:630: warning: No description found for return value of
'drm_get_connector_status_name'
drm_connector.c:715: warning: No description found for return value of
'drm_connector_list_iter_next'
drm_connector.c:785: warning: No description found for return value of
'drm_get_subpixel_order_name'
drm_connector.c:816: warning: No description found for return value of
'drm_display_info_set_bus_formats'
drm_connector.c:1331: warning: No description found for return value of
'drm_mode_create_dvi_i_properties'
drm_connector.c:1412: warning: No description found for return value of
'drm_connector_attach_content_type_property'
drm_connector.c:1492: warning: No description found for return value of
'drm_mode_create_tv_margin_properties'
drm_connector.c:1534: warning: No description found for return value of
'drm_mode_create_tv_properties'
drm_connector.c:1627: warning: No description found for return value of
'drm_mode_create_scaling_mode_property'
drm_connector.c:1944: warning: No description found for return value of
'drm_mode_create_suggested_offset_properties'
drm_connector.c:2315: warning: missing initial short description on line:
* drm_connector_set_panel_orientation_with_quirk -
[The last warning listed is probably a quirk/bug in scripts/kernel-doc.]
Fixes: 613051dac40d ("drm: locking iterators for connector_list")
Fixes: 522171951761 ("drm: Extract drm_connector.[hc]")
Fixes: b3c6c8bfe378 ("drm: document drm_display_info")
Fixes: 50525c332b55 ("drm: content-type property for HDMI connector")
Fixes: 6c4f52dca36f ("drm/connector: Allow creation of margin props alone")
Fixes: 69654c632d80 ("drm/connector: Split out orientation quirk detection
(v2)")
Fixes: 72ad49682dde ("drm/connector: Add support for out-of-band hotplug
notification (v3)")
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Stanislav Lisovskiy
Cc: Ville Syrjälä
Cc: Boris Brezillon
Cc: Derek Basehore
Cc: Hans de Goede
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
---
72ad49682dde ("drm/connector: Add support for out-of-band hotplug notification
(v3)")
is only in linux-next. The others are in mainline.
drivers/gpu/drm/drm_connector.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
--- linux-next-20211006.orig/drivers/gpu/drm/drm_connector.c
+++ linux-next-20211006/drivers/gpu/drm/drm_connector.c
@@ -625,6 +625,8 @@ int drm_connector_register_all(struct dr
*
* In contrast to the other drm_get_*_name functions this one here returns a
* const pointer and hence is threadsafe.
+ *
+ * Returns: connector status string
*/
const char *drm_get_connector_status_name(enum drm_connector_status status)
{
@@ -707,7 +709,7 @@ __drm_connector_put_safe(struct drm_conn
* drm_connector_list_iter_next - return next connector
* @iter: connector_list iterator
*
- * Returns the next connector for @iter, or NULL when the list walk has
+ * Returns: the next connector for @iter, or NULL when the list walk has
* completed.
*/
struct drm_connector *
@@ -780,6 +782,8 @@ static const struct drm_prop_enum_list d
*
* Note you could abuse this and return something out of bounds, but that
* would be a caller error. No unscrubbed user data should make it here.
+ *
+ * Returns: string describing an enumerated subpixel property
*/
const char *drm_get_subpixel_order_name(enum subpixel_order order)
{
@@ -809,6 +813,9 @@ static const struct drm_prop_enum_list d
* Store the supported bus formats in display info structure.
* See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h
for
* a full list of available formats.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
I prefer the following variant:
"0 on success or a negative error code on failure."
Then we do not use the overloaded "errno" name.
At least in include/drm/* my preferred variant is the most popular for
what it is worth.
OK, I'll change it to that.
*/
int drm_display_info_set_bus_formats(struct drm_display_info *info,
const u32 *formats,
@@ -1326,6 +1333,8 @@ int drm_connector_create_standard_proper
* @dev: DRM device
*
* Called by a driver the first time a DVI-I connector is made.
+ *
+ * Returns: %0
Looks like some macro gone wrong - but I looked it up.
It is kernel-doc
Re: [PATCH v2] drm/r128: fix build for UML
On 10/10/21 12:49 PM, Sam Ravnborg wrote:
Hi Randy,
On Sun, Oct 10, 2021 at 10:29:55AM -0700, Randy Dunlap wrote:
Fix a build error on CONFIG_UML, which does not support (provide)
wbinvd(). UML can use the generic mb() instead.
../drivers/gpu/drm/r128/ati_pcigart.c: In function ‘drm_ati_pcigart_init’:
../drivers/gpu/drm/r128/ati_pcigart.c:218:2: error: implicit declaration of
function ‘wbinvd’ [-Werror=implicit-function-declaration]
wbinvd();
^~
Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Jeff Dike
Cc: Richard Weinberger
Cc: Anton Ivanov
Cc: linux...@lists.infradead.org
---
v2: update Fixes: tag (thanks, Johannes)
drivers/gpu/drm/r128/ati_pcigart.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20211007.orig/drivers/gpu/drm/r128/ati_pcigart.c
+++ linux-next-20211007/drivers/gpu/drm/r128/ati_pcigart.c
@@ -215,7 +215,7 @@ int drm_ati_pcigart_init(struct drm_devi
}
ret = 0;
-#if defined(__i386__) || defined(__x86_64__)
+#if (defined(__i386__) || defined(__x86_64__)) && !defined(CONFIG_UML)
wbinvd();
#else
mb();
If we look at drivers/video/fbdev/i810/i810_main.h
then it looks like we can replace the above with a simple:
#ifdef CONFIG_X86
wbinvd();
#else
mb();
#endif
If you think this would work could you try it out.
It would be nicer with the simpler variant.
Hi Sam,
Good idea, thanks.
OK, I tested it, it works fine.
Will resend the patch later...
Note: I have no clue what wbinvd() does - seems like some x86 assembler
specific thingy.
--
~Randy
Re: [PATCH v6 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
On 10/10/21 7:12 PM, Sam Ravnborg wrote: On Sun, Oct 10, 2021 at 06:02:44PM +0200, Sam Ravnborg wrote: Hi Marek, On Sun, Oct 10, 2021 at 04:49:19PM +0200, Marek Vasut wrote: Decoder input LVDS format is a property of the decoder chip or even its strapping. Handle data-mapping the same way lvds-panel does. In case data-mapping is not present, do nothing, since there are still legacy bindings which do not specify this property. Reviewed-by: Laurent Pinchart Signed-off-by: Marek Vasut Cc: Laurent Pinchart Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg To: dri-devel@lists.freedesktop.org --- V2: - Move the data-mapping to endpoint V3: - Rebase on V2 submitted a while ago, reinstate changelog - Use .atomic_get_input_bus_fmts for the decoder, separate funcs for encoder V4: - No change V5: - Move the data-mapping property to port@0 , decoder LVDS input - Add RB from Laurent V6: - Turn missing data-mapping into warning, since the driver does continue in legacy probing mode without it. I assume you will apply the patches. I did not find your name in https://people.freedesktop.org/~seanpaul/whomisc.html so I went ahead and applied the patches. Thank you
Re: [Intel-gfx] [PATCH v3 3/5] drm/i915/panelreplay: Initializaton and compute config for panel replay
Hi Animesh,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20211008]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master airlied/drm-next v5.15-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Animesh-Manna/Panel-replay-phase1-implementation/20211010-203447
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-r014-20211010 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
903b30fea21f99d8f48fde4defcc838970e30ee1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/474a8190321f2836a1fe989326736d19dc9a732b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Animesh-Manna/Panel-replay-phase1-implementation/20211010-203447
git checkout 474a8190321f2836a1fe989326736d19dc9a732b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_dp.c:2780:27: error: overlapping
>> comparisons always evaluate to true [-Werror,-Wtautological-overlap-compare]
if (vsc->revision != 0x5 || vsc->revision != 0x7)
~^~~
1 error generated.
vim +2780 drivers/gpu/drm/i915/display/intel_dp.c
2756
2757 static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
2758 struct dp_sdp *sdp, size_t size)
2759 {
2760 size_t length = sizeof(struct dp_sdp);
2761
2762 if (size < length)
2763 return -ENOSPC;
2764
2765 memset(sdp, 0, size);
2766
2767 /*
2768 * Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
2769 * VSC SDP Header Bytes
2770 */
2771 sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
2772 sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet
Type */
2773 sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
2774 sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data
Bytes */
2775
2776 /*
2777 * Revision 0x5 and 0x7 supports Pixel Encoding/Colorimetry
Format as
2778 * per DP 1.4a spec and DP 2.0 spec respectively.
2779 */
> 2780 if (vsc->revision != 0x5 || vsc->revision != 0x7)
2781 goto out;
2782
2783 /* VSC SDP Payload for DB16 through DB18 */
2784 /* Pixel Encoding and Colorimetry Formats */
2785 sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
2786 sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
2787
2788 switch (vsc->bpc) {
2789 case 6:
2790 /* 6bpc: 0x0 */
2791 break;
2792 case 8:
2793 sdp->db[17] = 0x1; /* DB17[3:0] */
2794 break;
2795 case 10:
2796 sdp->db[17] = 0x2;
2797 break;
2798 case 12:
2799 sdp->db[17] = 0x3;
2800 break;
2801 case 16:
2802 sdp->db[17] = 0x4;
2803 break;
2804 default:
2805 MISSING_CASE(vsc->bpc);
2806 break;
2807 }
2808 /* Dynamic Range and Component Bit Depth */
2809 if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
2810 sdp->db[17] |= 0x80; /* DB17[7] */
2811
2812 /* Content Type */
2813 sdp->db[18] = vsc->content_type & 0x7;
2814
2815 out:
2816 return length;
2817 }
2818
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH -next] drm/connector: fix all kernel-doc warnings
Hi Randy,
I noticed a few things that in my opinion could be improved.
See below.
Sam
On Wed, Oct 06, 2021 at 05:53:05PM -0700, Randy Dunlap wrote:
> Clean up all of the kernel-doc issues in drm_connector.c:
>
> drivers/gpu/drm/drm_connector.c:2611: warning: Excess function parameter
> 'connector' description in 'drm_connector_oob_hotplug_event'
> drivers/gpu/drm/drm_connector.c:2611: warning: Function parameter or member
> 'connector_fwnode' not described in 'drm_connector_oob_hotplug_event'
>
> drm_connector.c:630: warning: No description found for return value of
> 'drm_get_connector_status_name'
> drm_connector.c:715: warning: No description found for return value of
> 'drm_connector_list_iter_next'
> drm_connector.c:785: warning: No description found for return value of
> 'drm_get_subpixel_order_name'
> drm_connector.c:816: warning: No description found for return value of
> 'drm_display_info_set_bus_formats'
> drm_connector.c:1331: warning: No description found for return value of
> 'drm_mode_create_dvi_i_properties'
> drm_connector.c:1412: warning: No description found for return value of
> 'drm_connector_attach_content_type_property'
> drm_connector.c:1492: warning: No description found for return value of
> 'drm_mode_create_tv_margin_properties'
> drm_connector.c:1534: warning: No description found for return value of
> 'drm_mode_create_tv_properties'
> drm_connector.c:1627: warning: No description found for return value of
> 'drm_mode_create_scaling_mode_property'
> drm_connector.c:1944: warning: No description found for return value of
> 'drm_mode_create_suggested_offset_properties'
>
> drm_connector.c:2315: warning: missing initial short description on line:
> * drm_connector_set_panel_orientation_with_quirk -
>
> [The last warning listed is probably a quirk/bug in scripts/kernel-doc.]
>
> Fixes: 613051dac40d ("drm: locking iterators for connector_list")
> Fixes: 522171951761 ("drm: Extract drm_connector.[hc]")
> Fixes: b3c6c8bfe378 ("drm: document drm_display_info")
> Fixes: 50525c332b55 ("drm: content-type property for HDMI connector")
> Fixes: 6c4f52dca36f ("drm/connector: Allow creation of margin props alone")
> Fixes: 69654c632d80 ("drm/connector: Split out orientation quirk detection
> (v2)")
> Fixes: 72ad49682dde ("drm/connector: Add support for out-of-band hotplug
> notification (v3)")
> Signed-off-by: Randy Dunlap
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: Stanislav Lisovskiy
> Cc: Ville Syrjälä
> Cc: Boris Brezillon
> Cc: Derek Basehore
> Cc: Hans de Goede
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> ---
> 72ad49682dde ("drm/connector: Add support for out-of-band hotplug
> notification (v3)")
> is only in linux-next. The others are in mainline.
>
> drivers/gpu/drm/drm_connector.c | 30 ++
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> --- linux-next-20211006.orig/drivers/gpu/drm/drm_connector.c
> +++ linux-next-20211006/drivers/gpu/drm/drm_connector.c
> @@ -625,6 +625,8 @@ int drm_connector_register_all(struct dr
> *
> * In contrast to the other drm_get_*_name functions this one here returns a
> * const pointer and hence is threadsafe.
> + *
> + * Returns: connector status string
> */
> const char *drm_get_connector_status_name(enum drm_connector_status status)
> {
> @@ -707,7 +709,7 @@ __drm_connector_put_safe(struct drm_conn
> * drm_connector_list_iter_next - return next connector
> * @iter: connector_list iterator
> *
> - * Returns the next connector for @iter, or NULL when the list walk has
> + * Returns: the next connector for @iter, or NULL when the list walk has
> * completed.
> */
> struct drm_connector *
> @@ -780,6 +782,8 @@ static const struct drm_prop_enum_list d
> *
> * Note you could abuse this and return something out of bounds, but that
> * would be a caller error. No unscrubbed user data should make it here.
> + *
> + * Returns: string describing an enumerated subpixel property
> */
> const char *drm_get_subpixel_order_name(enum subpixel_order order)
> {
> @@ -809,6 +813,9 @@ static const struct drm_prop_enum_list d
> * Store the supported bus formats in display info structure.
> * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h
> for
> * a full list of available formats.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
I prefer the following variant:
"0 on success or a negative error code on failure."
Then we do not use the overloaded "errno" name.
At least in include/drm/* my preferred variant is the most popular for
what it is worth.
> */
> int drm_display_info_set_bus_formats(struct drm_display_info *info,
>const u32 *formats,
> @@ -1326,6 +1333,8 @@ int drm_connector_create_standard_proper
> * @dev: DRM device
> *
> * Called by a driver the first time a DVI-I connector is made.
> +
Re: [PATCH v2] drm/r128: fix build for UML
Hi Randy,
On Sun, Oct 10, 2021 at 10:29:55AM -0700, Randy Dunlap wrote:
> Fix a build error on CONFIG_UML, which does not support (provide)
> wbinvd(). UML can use the generic mb() instead.
>
> ../drivers/gpu/drm/r128/ati_pcigart.c: In function ‘drm_ati_pcigart_init’:
> ../drivers/gpu/drm/r128/ati_pcigart.c:218:2: error: implicit declaration of
> function ‘wbinvd’ [-Werror=implicit-function-declaration]
> wbinvd();
> ^~
>
> Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
> Signed-off-by: Randy Dunlap
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jeff Dike
> Cc: Richard Weinberger
> Cc: Anton Ivanov
> Cc: linux...@lists.infradead.org
> ---
> v2: update Fixes: tag (thanks, Johannes)
>
> drivers/gpu/drm/r128/ati_pcigart.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-next-20211007.orig/drivers/gpu/drm/r128/ati_pcigart.c
> +++ linux-next-20211007/drivers/gpu/drm/r128/ati_pcigart.c
> @@ -215,7 +215,7 @@ int drm_ati_pcigart_init(struct drm_devi
> }
> ret = 0;
>
> -#if defined(__i386__) || defined(__x86_64__)
> +#if (defined(__i386__) || defined(__x86_64__)) && !defined(CONFIG_UML)
> wbinvd();
> #else
> mb();
If we look at drivers/video/fbdev/i810/i810_main.h
then it looks like we can replace the above with a simple:
#ifdef CONFIG_X86
wbinvd();
#else
mb();
#endif
If you think this would work could you try it out.
It would be nicer with the simpler variant.
Note: I have no clue what wbinvd() does - seems like some x86 assembler
specific thingy.
Sam
Re: 572994bf18ff prevents system boot
> On Oct 8, 2021, at 4:49 AM, Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.10.21 um 16:11 schrieb Chuck Lever III:
>>> On Oct 4, 2021, at 10:07 AM, Thomas Zimmermann wrote:
>>>
>>> Hi
>>>
>>> Am 04.10.21 um 15:34 schrieb Chuck Lever III:
> On Oct 4, 2021, at 3:07 AM, Thomas Zimmermann wrote:
>
> (cc: ainux.w...@gmail.com)
>
> Hi
>
> Am 03.10.21 um 20:09 schrieb Chuck Lever III:
>> Hi-
>> After updating one of my test systems to v5.15-rc, I found that it
>> becomes unresponsive during the later part of the boot process. A
>> power-on reset is necessary to recover.
>> I bisected to this commit:
>> 572994bf18ff ("drm/ast: Zero is missing in detect function")
>
> You don't have a monitor connected, I guess?
Correct, my lab systems use IPMI and a browser-attached console.
> In that case, we now trigger the helpers that poll for connected
> monitors. However, the overhead seems rather extreme.
>
> I'll have to try to reproduce this, or otherwise we can revert the commit.
It's strange, only that system in my lab seems to have a problem.
The others work fine.
Thanks for having a look!
>>>
>>> Is it a HW or FW problem? Maybe a different revision?
>> It's possible. I don't know how to further diagnose the issue,
>> though. Any guidance appreciated!
>
> v5.15-rc3 works well on my test machine.
>
> For getting the firmware revisions, run
>
> sudo dmidecode
>
> on the machine. It will print a long list of devices with related
> information. Running
>
> sudo lspci -v
>
> will give information about the PCI devices. There's an entry for the VGA
> device somewhere. Maybe you can find some difference between the different
> systems
Fwiw, here's a working system:
DMI: Supermicro X10SRA-F/X10SRA-F, BIOS 2.0b 06/12/2017
Handle 0x0054, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Aspeed Video AST2400
Type: Video
Status: Enabled
Type Instance: 1
Bus Address: :08:00.0
08:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics
Family (rev 30) (prog-if 00 [VGA controller])
DeviceName: Aspeed Video AST2400
Subsystem: Super Micro Computer Inc Device 0857
The system that hangs reports:
DMI: Supermicro Super Server/X10SRL-F, BIOS 3.3 10/28/2020
Handle 0x0027, DMI type 41, 11 bytes
Onboard Device
Reference Designation: ASPEED Video AST2400
Type: Video
Status: Enabled
Type Instance: 1
Bus Address: :0b:00.0
0b:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics
Family (rev 30) (prog-if 00 [VGA controller])
DeviceName: ASPEED Video AST2400
Subsystem: Super Micro Computer Inc X10SRL-F
> If you think the machine got stuck, try to plug-in the VGA cable during the
> boot and see if it makes the machine come up.
I will try to make time to give this a shot.
> Best regards
> Thomas
>
>>> I'm asking because the problematic commit does the correct thing. If there
>>> is no VGA cable connected, the driver should poll until it detects one. The
>>> overhead should be minimal.
>>>
>>> But I'll try to reproduce anyway.
>>>
>>> Best regards
>>> Thomas
>>>
> Best regards
> Thomas
>
>> Checking out v5.15-rc3 and reverting this commit enables the system
>> to boot again.
>> 0b:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED
>> Graphics Family (rev 30) (prog-if 00 [VGA controller])
>> DeviceName: ASPEED Video AST2400
>> Subsystem: Super Micro Computer Inc X10SRL-F
>> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
>> ParErr- Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>> SERR- > Interrupt: pin A routed to IRQ 18
>> Region 0: Memory at fa00 (32-bit, non-prefetchable)
>> [size=16M]
>> Region 1: Memory at fb00 (32-bit, non-prefetchable)
>> [size=128K]
>> Region 2: I/O ports at c000 [size=128]
>> Expansion ROM at 000c [virtual] [disabled] [size=128K]
>> Capabilities: [40] Power Management version 3
>> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
>> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>> Capabilities: [50] MSI: Enable- Count=1/4 Maskable- 64bit+
>> Address: Data:
>> Kernel driver in use: ast
>> Kernel modules: ast
>> --
>> Chuck Lever
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
--
Chuck Lever
>>>
>>> --
>>>
Re: DSI Bridge switching
Hi Dave, On Fri, Oct 8, 2021 at 9:32 PM Dave Stevenson wrote: > > On Fri, 8 Oct 2021 at 14:37, Laurent Pinchart > wrote: > > > > Hello, > > > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote: > > > Hi, > > > > > > Removed my invalid email (I will update files next week). > > > > > > On 08.10.2021 13:14, Jagan Teki wrote: > > > > Hi, > > > > > > > > I think this seems to be a known use case for industrial these days > > > > with i.mx8m. > > > > > > > > The host DSI would configure with two bridges one for DSI to LVDS > > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we > > > > can use only one bridge at a time as host DSI support single out port. > > > > So we can have two separate device tree files for LVDS and HDMI and > > > > load them static. > > > > > > > > But, one of the use cases is to support both of them in single dts, and > > > > - Turn On LVDS (default) > > > > - Turn Off LVDS then Turn On HDMI when cable plug-in > > > > > > Are you sure it will work from hardware PoV? Do you have some demuxer? > > > isolation of pins? > > > > It may be in the category of "you shouldn't do this, but it actually > > works". I've seen the same being done with two CSI-2 camera sensors > > connected to the same receiver, with one of them being held in reset at > > all times. > > Surely the correct way to do this would be with a D-PHY mux chip such > as OnSemi FSA642 [1] or those from Diodes Incorporated [2]. > How you'd integrate such a mux into DRM is a totally different question. > With V4L2 and CSI2 it'd be relatively simple via Media Controller. > > Just wiring them together isn't going to work very well for DSI > reverse direction communication, but neither of the chips Jagan lists > support this. Sorry to mention it before, we have two 2:1 MIPI D-PHY Switch [1] on the design which take 2 data-lanes and clock from Host and produce 4 data-lane and 1 clock to connect to ADV7535 and SN65DSI84 bridges. The switch has OE, SEL pins to select the desired to MUXed lanes/clock routing to an appropriate bridge. I think supporting the switch in the pipeline or logic that handle the bridge switching might help. [1] https://www.diodes.com/assets/Datasheets/PI3WVR626.pdf Jagan.
Re: DSI Bridge switching
Hi Andrzej, On Fri, Oct 8, 2021 at 6:57 PM Andrzej Hajda wrote: > > Hi, > > Removed my invalid email (I will update files next week). > > > On 08.10.2021 13:14, Jagan Teki wrote: > > Hi, > > > > I think this seems to be a known use case for industrial these days with > > i.mx8m. > > > > The host DSI would configure with two bridges one for DSI to LVDS > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we > > can use only one bridge at a time as host DSI support single out port. > > So we can have two separate device tree files for LVDS and HDMI and > > load them static. > > > > But, one of the use cases is to support both of them in single dts, and > > - Turn On LVDS (default) > > - Turn Off LVDS then Turn On HDMI when cable plug-in > > Are you sure it will work from hardware PoV? Do you have some demuxer? > isolation of pins? Correct. I have noticed after you mentioned this. Design has two 2:1 MIPI Switch PI3WVR626 [1] which take 2 data-lanes and clock from Host and produce 4 data-lane and 1 clock to connect to ADV7535 and SN65DSI84 bridges. The switch has OE, SEL pins to select the desired to MUXed lanes/clock routing to an appropriate bridge. > > > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design. > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on > > port 2 in the DSI host node, and trying to attach the respective > > bridge based on HDMI-INT like repeating the bridge attachment cycle > > based on the HDMI-INT. > > I think more appropriate would be to share the same port, but provide > two endpoints inside this port - we have two hardware sharing the same > physical port. Make sense to me. I think we can in-corporate the MIPI Switch on the pipeline as input data and clock lanes are muxing. not sure how it can be done. > > > > > Can it be possible to do bridge attachment at runtime? something like > > a bridge hotplug event? or any other possible solutions? > > > > Any suggestions? > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi + > some toshiba bridge - panel and bridge are dynamically 'plugged' and > 'unplugged' from exynos_drm, but they do not use bridge chain for this > and some other reasons. (un|re|)plugging should be performed of course > when pipeline is off (connector disconnected). I am not sure about > bridges added to bridge chain - you need to inspect all opses to ensure > it can be done safely. I will check with this. However i did tried of hot-plug mechanism for bridge in exiting DSI host sun6i_mipi_dsi.c [2] look like it surely not possible with bridge-chain as hot-plug require drm pointer where the same pointer is not available during attach call. > > And the main issue: Daniel does not like it :) [1] https://www.diodes.com/assets/Datasheets/PI3WVR626.pdf [2] https://elixir.bootlin.com/linux/v5.15-rc4/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L976 Jagan.
Re: [Intel-gfx] [PATCH v3 3/5] drm/i915/panelreplay: Initializaton and compute config for panel replay
Hi Animesh,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20211008]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master airlied/drm-next v5.15-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Animesh-Manna/Panel-replay-phase1-implementation/20211010-203447
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-a014-20211010 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
903b30fea21f99d8f48fde4defcc838970e30ee1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/474a8190321f2836a1fe989326736d19dc9a732b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Animesh-Manna/Panel-replay-phase1-implementation/20211010-203447
git checkout 474a8190321f2836a1fe989326736d19dc9a732b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_dp.c:2780:27: warning: overlapping
>> comparisons always evaluate to true [-Wtautological-overlap-compare]
if (vsc->revision != 0x5 || vsc->revision != 0x7)
~^~~
1 warning generated.
vim +2780 drivers/gpu/drm/i915/display/intel_dp.c
2756
2757 static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
2758 struct dp_sdp *sdp, size_t size)
2759 {
2760 size_t length = sizeof(struct dp_sdp);
2761
2762 if (size < length)
2763 return -ENOSPC;
2764
2765 memset(sdp, 0, size);
2766
2767 /*
2768 * Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
2769 * VSC SDP Header Bytes
2770 */
2771 sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
2772 sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet
Type */
2773 sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
2774 sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data
Bytes */
2775
2776 /*
2777 * Revision 0x5 and 0x7 supports Pixel Encoding/Colorimetry
Format as
2778 * per DP 1.4a spec and DP 2.0 spec respectively.
2779 */
> 2780 if (vsc->revision != 0x5 || vsc->revision != 0x7)
2781 goto out;
2782
2783 /* VSC SDP Payload for DB16 through DB18 */
2784 /* Pixel Encoding and Colorimetry Formats */
2785 sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
2786 sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
2787
2788 switch (vsc->bpc) {
2789 case 6:
2790 /* 6bpc: 0x0 */
2791 break;
2792 case 8:
2793 sdp->db[17] = 0x1; /* DB17[3:0] */
2794 break;
2795 case 10:
2796 sdp->db[17] = 0x2;
2797 break;
2798 case 12:
2799 sdp->db[17] = 0x3;
2800 break;
2801 case 16:
2802 sdp->db[17] = 0x4;
2803 break;
2804 default:
2805 MISSING_CASE(vsc->bpc);
2806 break;
2807 }
2808 /* Dynamic Range and Component Bit Depth */
2809 if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
2810 sdp->db[17] |= 0x80; /* DB17[7] */
2811
2812 /* Content Type */
2813 sdp->db[18] = vsc->content_type & 0x7;
2814
2815 out:
2816 return length;
2817 }
2818
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [v2] drm/panel: panel-simple: Add delay for LG LP120UP1
Hi Rex-BC
On Thu, Oct 07, 2021 at 07:05:47PM +0800, Rex-BC Chen wrote:
> Add power sequence for LG LP120UP1.
>
> Signed-off-by: Rex-BC Chen
Patch failed to apply to drm-misc-next.
Please fix and resend.
Sam
> ---
> drivers/gpu/drm/panel/panel-simple.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 9b6c4e6c38a1..9f6544450b56 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3045,6 +3045,11 @@ static const struct panel_desc lg_lp120up1 = {
> .width = 267,
> .height = 183,
> },
> + .delay = {
> + .prepare = 200,
> + .enable = 50,
> + .unprepare = 500,
> + },
> .connector_type = DRM_MODE_CONNECTOR_eDP,
> };
>
> --
> 2.18.0
Re: [PATCH v5 0/2] Add support for Sharp LS060T1SX01 panel
Hi Dmitry, On Sat, Oct 09, 2021 at 11:38:04PM +0300, Dmitry Baryshkov wrote: > Add driver to support Sharp LS06T1SX01 6.0" FullHD panel found e.g. in > the kwaek.ca Dragonboard Display Adapter Bundle. > > Changes since v4: > - Use MIPI_DSI_MODE_NO_EOT_PACKET instead of the old name > > Changes since v3: > - Replaced small msleeps with usleep_range > > Changes since v2: > - Add missing power supplies used by the panel according to the >datasheet > > Changes since v1: > - Fix the id in the schema file > > > Dmitry Baryshkov (2): > dt-bindings: add bindings for the Sharp LS060T1SX01 panel > drm/panel: Add support for Sharp LS060T1SX01 panel Applied to drm-misc-next and this time on purpose. Thanks for the quick fixes. Sam
[PATCH v2] drm/r128: fix build for UML
Fix a build error on CONFIG_UML, which does not support (provide)
wbinvd(). UML can use the generic mb() instead.
../drivers/gpu/drm/r128/ati_pcigart.c: In function ‘drm_ati_pcigart_init’:
../drivers/gpu/drm/r128/ati_pcigart.c:218:2: error: implicit declaration of
function ‘wbinvd’ [-Werror=implicit-function-declaration]
wbinvd();
^~
Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Jeff Dike
Cc: Richard Weinberger
Cc: Anton Ivanov
Cc: linux...@lists.infradead.org
---
v2: update Fixes: tag (thanks, Johannes)
drivers/gpu/drm/r128/ati_pcigart.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20211007.orig/drivers/gpu/drm/r128/ati_pcigart.c
+++ linux-next-20211007/drivers/gpu/drm/r128/ati_pcigart.c
@@ -215,7 +215,7 @@ int drm_ati_pcigart_init(struct drm_devi
}
ret = 0;
-#if defined(__i386__) || defined(__x86_64__)
+#if (defined(__i386__) || defined(__x86_64__)) && !defined(CONFIG_UML)
wbinvd();
#else
mb();
Re: [PATCH v6 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
On 10/10/21 6:02 PM, Sam Ravnborg wrote: Hi Marek, On Sun, Oct 10, 2021 at 04:49:19PM +0200, Marek Vasut wrote: Decoder input LVDS format is a property of the decoder chip or even its strapping. Handle data-mapping the same way lvds-panel does. In case data-mapping is not present, do nothing, since there are still legacy bindings which do not specify this property. Reviewed-by: Laurent Pinchart Signed-off-by: Marek Vasut Cc: Laurent Pinchart Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg To: dri-devel@lists.freedesktop.org --- V2: - Move the data-mapping to endpoint V3: - Rebase on V2 submitted a while ago, reinstate changelog - Use .atomic_get_input_bus_fmts for the decoder, separate funcs for encoder V4: - No change V5: - Move the data-mapping property to port@0 , decoder LVDS input - Add RB from Laurent V6: - Turn missing data-mapping into warning, since the driver does continue in legacy probing mode without it. I assume you will apply the patches. I can't, I'm still waiting for my drm-misc access.
Re: [PATCH v6 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
On Sun, Oct 10, 2021 at 06:02:44PM +0200, Sam Ravnborg wrote: > Hi Marek, > On Sun, Oct 10, 2021 at 04:49:19PM +0200, Marek Vasut wrote: > > Decoder input LVDS format is a property of the decoder chip or even > > its strapping. Handle data-mapping the same way lvds-panel does. In > > case data-mapping is not present, do nothing, since there are still > > legacy bindings which do not specify this property. > > > > Reviewed-by: Laurent Pinchart > > Signed-off-by: Marek Vasut > > Cc: Laurent Pinchart > > Cc: Sam Ravnborg > Reviewed-by: Sam Ravnborg > > To: dri-devel@lists.freedesktop.org > > --- > > V2: - Move the data-mapping to endpoint > > V3: - Rebase on V2 submitted a while ago, reinstate changelog > > - Use .atomic_get_input_bus_fmts for the decoder, separate funcs for > > encoder > > V4: - No change > > V5: - Move the data-mapping property to port@0 , decoder LVDS input > > - Add RB from Laurent > > V6: - Turn missing data-mapping into warning, since the driver does > > continue in legacy probing mode without it. > > I assume you will apply the patches. I did not find your name in https://people.freedesktop.org/~seanpaul/whomisc.html so I went ahead and applied the patches. Sam
Re: [PATCH v6 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
Hi Marek, On Sun, Oct 10, 2021 at 04:49:19PM +0200, Marek Vasut wrote: > Decoder input LVDS format is a property of the decoder chip or even > its strapping. Handle data-mapping the same way lvds-panel does. In > case data-mapping is not present, do nothing, since there are still > legacy bindings which do not specify this property. > > Reviewed-by: Laurent Pinchart > Signed-off-by: Marek Vasut > Cc: Laurent Pinchart > Cc: Sam Ravnborg Reviewed-by: Sam Ravnborg > To: dri-devel@lists.freedesktop.org > --- > V2: - Move the data-mapping to endpoint > V3: - Rebase on V2 submitted a while ago, reinstate changelog > - Use .atomic_get_input_bus_fmts for the decoder, separate funcs for > encoder > V4: - No change > V5: - Move the data-mapping property to port@0 , decoder LVDS input > - Add RB from Laurent > V6: - Turn missing data-mapping into warning, since the driver does > continue in legacy probing mode without it. I assume you will apply the patches. Sam
imx_ldb: lockdep warning on 5.14.x
Hi,
I am getting the lockdep warning below on a imx6q-sabred running 5.14.9.
Haven't debugged this yet, but just wanted to report in case someone
has any suggestions.
Thanks,
Fabio Estevam
[4.913294] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops
ipu_crtc_ops)
[4.921640] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops
ipu_crtc_ops)
[4.929798] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops
ipu_crtc_ops)
[4.937977] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops
ipu_crtc_ops)
[4.946850] imx-drm display-subsystem: bound 12.hdmi (ops
dw_hdmi_imx_ops)
[4.954685] imx-drm display-subsystem: bound ldb (ops imx_ldb_ops)
[4.966943] [drm] Initialized imx-drm 1.0.0 20120507 for
display-subsystem on minor 0
[5.001801]
[5.001811] ==
[5.001817] WARNING: possible circular locking dependency detected
[5.001824] 5.14.9-01225-g45da36cc6fcc-dirty #1 Tainted: GW
[5.001833] --
[5.001838] kworker/u8:0/7 is trying to acquire lock:
[5.001848] c1752080 (regulator_list_mutex){+.+.}-{3:3}, at:
regulator_lock_dependent+0x40/0x294
[5.001903]
[5.001903] but task is already holding lock:
[5.001909] c176df78 (dma_fence_map){}-{0:0}, at:
imx_drm_atomic_commit_tail+0x10/0x160
[5.001957]
[5.001957] which lock already depends on the new lock.
[5.001957]
[5.001963]
[5.001963] the existing dependency chain (in reverse order) is:
[5.001968]
[5.001968] -> #3 (dma_fence_map){}-{0:0}:
[5.001993]dma_resv_lockdep+0x1c4/0x2b8
[5.002010]do_one_initcall+0x84/0x3b8
[5.002026]kernel_init_freeable+0x198/0x22c
[5.002040]kernel_init+0x10/0x128
[5.002061]ret_from_fork+0x14/0x38
[5.002072]0x0
[5.002081]
[5.002081] -> #2 (fs_reclaim){+.+.}-{0:0}:
[5.002105]kmem_cache_alloc+0x28/0x38c
[5.002125]__d_alloc+0x20/0x224
[5.002141]d_alloc+0x10/0x60
[5.002152]d_alloc_parallel+0x48/0xa60
[5.002165]__lookup_slow+0x8c/0x178
[5.002184]lookup_one_len+0x98/0xd8
[5.002196]start_creating+0x94/0x14c
[5.002216]debugfs_create_dir+0x10/0x100
[5.002231]pinctrl_init+0x1c/0xd4
[5.002247]do_one_initcall+0x84/0x3b8
[5.002259]kernel_init_freeable+0x198/0x22c
[5.002271]kernel_init+0x10/0x128
[5.002286]ret_from_fork+0x14/0x38
[5.002296]0x0
[5.002303]
[5.002303] -> #1 (>s_type->i_mutex_key#2){+.+.}-{3:3}:
[5.002335]simple_recursive_removal+0x54/0x33c
[5.002350]debugfs_remove+0x30/0x4c
[5.002364]_regulator_put.part.0+0x30/0x1d8
[5.002383]regulator_put+0x2c/0x3c
[5.002395]release_nodes+0x50/0x190
[5.002415]devres_release_all+0x80/0xd4
[5.002426]really_probe+0xd4/0x314
[5.002438]__driver_probe_device+0x80/0xe4
[5.002449]driver_probe_device+0x30/0xd4
[5.002459]__driver_attach_async_helper+0x20/0x38
[5.002470]async_run_entry_fn+0x20/0xb4
[5.002483]process_one_work+0x2a0/0x7c0
[5.002500]worker_thread+0x30/0x510
[5.002512]kthread+0x154/0x17c
[5.002526]ret_from_fork+0x14/0x38
[5.002537]0x0
[5.002546]
[5.002546] -> #0 (regulator_list_mutex){+.+.}-{3:3}:
[5.002569]lock_acquire+0x13c/0x418
[5.002581]__mutex_lock+0x94/0x97c
[5.002595]mutex_lock_nested+0x1c/0x24
[5.002605]regulator_lock_dependent+0x40/0x294
[5.002622]regulator_enable+0x2c/0xec
[5.002632]panel_simple_resume+0x38/0x1f4
[5.002648]__rpm_callback+0x3c/0x108
[5.002661]rpm_callback+0x68/0x70
[5.002671]rpm_resume+0x604/0x7f4
[5.002681]__pm_runtime_resume+0x64/0x90
[5.002692]panel_simple_prepare+0x2c/0x50
[5.002703]imx_ldb_encoder_enable+0x58/0x2b0
[5.002715]drm_atomic_helper_commit_modeset_enables+0x230/0x26c
[5.002734]imx_drm_atomic_commit_tail+0x3c/0x160
[5.002753]commit_tail+0x9c/0x18c
[5.002766]drm_atomic_helper_commit+0x158/0x18c
[5.002778]drm_client_modeset_commit_atomic+0x23c/0x288
[5.002795]drm_client_modeset_commit_locked+0x60/0x1d0
[5.002806]drm_client_modeset_commit+0x24/0x40
[5.002819]__drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc8
[5.002835]drm_fb_helper_set_par+0x38/0x68
[5.002845]fbcon_init+0x2bc/0x550
[5.002862]visual_init+0xbc/0x104
[5.002881]do_bind_con_driver+0x1c8/0x3b0
[5.002896]do_take_over_console+0x134/0x1f0
[5.002910]do_fbcon_takeover+0x60/0xc0
[5.002924]register_framebuffer+0x1c8/0x2e8
[
Re: [RFC PATCH v2 0/2] RDMA/rxe: Add dma-buf support
On Wed, Sep 29, 2021 at 12:19 PM Shunsuke Mie wrote: > > This patch series add a dma-buf support for rxe driver. > > A dma-buf based memory registering has beed introduced to use the memory > region that lack of associated page structures (e.g. device memory and CMA > managed memory) [1]. However, to use the dma-buf based memory, each rdma > device drivers require add some implementation. The rxe driver has not > support yet. > > [1] https://www.spinics.net/lists/linux-rdma/msg98592.html It seems that dma-buf is in discussion. We will focus on this discussion. After dma-buf is accepted, we will check this dma-buf on rxe. Zhu Yanjun > > To enable to use the dma-buf memory in rxe rdma device, add some changes > and implementation in this patch series. > > This series consists of two patches. The first patch changes the IB core > to support for rdma drivers that has not dma device. The secound patch adds > the dma-buf support to rxe driver. > > Related user space RDMA library changes are provided as a separate patch. > > v2: > * Rebase to the latest linux-rdma 'for-next' branch (5.15.0-rc1+) > * Instead of using a dummy dma_device to attach dma-buf, just store > dma-buf to use software RDMA driver > * Use dma-buf vmap() interface > * Check to pass tests of rdma-core > v1: https://www.spinics.net/lists/linux-rdma/msg105376.html > * The initial patch set > * Use ib_device as dma_device. > * Use dma-buf dynamic attach interface > * Add dma-buf support to rxe device > > Shunsuke Mie (2): > RDMA/umem: Change for rdma devices has not dma device > RDMA/rxe: Add dma-buf support > > drivers/infiniband/core/umem_dmabuf.c | 20 - > drivers/infiniband/sw/rxe/rxe_loc.h | 2 + > drivers/infiniband/sw/rxe/rxe_mr.c| 118 ++ > drivers/infiniband/sw/rxe/rxe_verbs.c | 34 > drivers/infiniband/sw/rxe/rxe_verbs.h | 2 + > include/rdma/ib_umem.h| 1 + > 6 files changed, 173 insertions(+), 4 deletions(-) > > -- > 2.17.1 >
Re: [RFC PATCH v2 2/2] RDMA/rxe: Add dma-buf support
On Tue, Oct 5, 2021 at 6:20 PM Shunsuke Mie wrote:
>
> ping
Sorry. I will check it soon.
Zhu Yanjun
>
> 2021年10月1日(金) 12:56 Shunsuke Mie :
> >
> > 2021年9月30日(木) 23:41 Daniel Vetter :
> > >
> > > On Wed, Sep 29, 2021 at 01:19:05PM +0900, Shunsuke Mie wrote:
> > > > Implement a ib device operation ‘reg_user_mr_dmabuf’. Generate a
> > > > rxe_map from the memory space linked the passed dma-buf.
> > > >
> > > > Signed-off-by: Shunsuke Mie
> > > > ---
> > > > drivers/infiniband/sw/rxe/rxe_loc.h | 2 +
> > > > drivers/infiniband/sw/rxe/rxe_mr.c| 118 ++
> > > > drivers/infiniband/sw/rxe/rxe_verbs.c | 34
> > > > drivers/infiniband/sw/rxe/rxe_verbs.h | 2 +
> > > > 4 files changed, 156 insertions(+)
> > > >
> > > > diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h
> > > > b/drivers/infiniband/sw/rxe/rxe_loc.h
> > > > index 1ca43b859d80..8bc19ea1a376 100644
> > > > --- a/drivers/infiniband/sw/rxe/rxe_loc.h
> > > > +++ b/drivers/infiniband/sw/rxe/rxe_loc.h
> > > > @@ -75,6 +75,8 @@ u8 rxe_get_next_key(u32 last_key);
> > > > void rxe_mr_init_dma(struct rxe_pd *pd, int access, struct rxe_mr *mr);
> > > > int rxe_mr_init_user(struct rxe_pd *pd, u64 start, u64 length, u64
> > > > iova,
> > > >int access, struct rxe_mr *mr);
> > > > +int rxe_mr_dmabuf_init_user(struct rxe_pd *pd, int fd, u64 start, u64
> > > > length,
> > > > + u64 iova, int access, struct rxe_mr *mr);
> > > > int rxe_mr_init_fast(struct rxe_pd *pd, int max_pages, struct rxe_mr
> > > > *mr);
> > > > int rxe_mr_copy(struct rxe_mr *mr, u64 iova, void *addr, int length,
> > > > enum rxe_mr_copy_dir dir);
> > > > diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c
> > > > b/drivers/infiniband/sw/rxe/rxe_mr.c
> > > > index 53271df10e47..af6ef671c3a5 100644
> > > > --- a/drivers/infiniband/sw/rxe/rxe_mr.c
> > > > +++ b/drivers/infiniband/sw/rxe/rxe_mr.c
> > > > @@ -4,6 +4,7 @@
> > > > * Copyright (c) 2015 System Fabric Works, Inc. All rights reserved.
> > > > */
> > > >
> > > > +#include
> > > > #include "rxe.h"
> > > > #include "rxe_loc.h"
> > > >
> > > > @@ -245,6 +246,120 @@ int rxe_mr_init_user(struct rxe_pd *pd, u64
> > > > start, u64 length, u64 iova,
> > > > return err;
> > > > }
> > > >
> > > > +static int rxe_map_dmabuf_mr(struct rxe_mr *mr,
> > > > + struct ib_umem_dmabuf *umem_dmabuf)
> > > > +{
> > > > + struct rxe_map_set *set;
> > > > + struct rxe_phys_buf *buf = NULL;
> > > > + struct rxe_map **map;
> > > > + void *vaddr, *vaddr_end;
> > > > + int num_buf = 0;
> > > > + int err;
> > > > + size_t remain;
> > > > +
> > > > + mr->dmabuf_map = kzalloc(sizeof >dmabuf_map, GFP_KERNEL);
> > >
> > > dmabuf_maps are just tagged pointers (and we could shrink them to actually
> > > just a tagged pointer if anyone cares about the overhead of the separate
> > > bool), allocating them seperately is overkill.
> >
> > I agree with you. However, I think it is needed to unmap by
> > dma_buf_vunmap(). If there is another simple way to unmap it. It is not
> > needed I think. What do you think about it?
> >
> > > > + if (!mr->dmabuf_map) {
> > > > + err = -ENOMEM;
> > > > + goto err_out;
> > > > + }
> > > > +
> > > > + err = dma_buf_vmap(umem_dmabuf->dmabuf, mr->dmabuf_map);
> > > > + if (err)
> > > > + goto err_free_dmabuf_map;
> > > > +
> > > > + set = mr->cur_map_set;
> > > > + set->page_shift = PAGE_SHIFT;
> > > > + set->page_mask = PAGE_SIZE - 1;
> > > > +
> > > > + map = set->map;
> > > > + buf = map[0]->buf;
> > > > +
> > > > + vaddr = mr->dmabuf_map->vaddr;
> > >
> > > dma_buf_map can be an __iomem too, you shouldn't dig around in this, but
> > > use the dma-buf-map.h helpers instead. On x86 (and I think also on most
> > > arm) it doesn't matter, but it's kinda not very nice in a pure software
> > > driver.
> > >
> > > If anything is missing in dma-buf-map.h wrappers just add more.
> > >
> > > Or alternatively you need to fail the import if you can't handle __iomem.
> > >
> > > Aside from these I think the dma-buf side here for cpu access looks
> > > reasonable now.
> > > -Daniel
> > I'll see the dma-buf-map.h and consider the error handling that you
> > suggested.
> > I appreciate your support.
> >
> > Thanks a lot,
> > Shunsuke.
> >
> > > > + vaddr_end = vaddr + umem_dmabuf->dmabuf->size;
> > > > + remain = umem_dmabuf->dmabuf->size;
> > > > +
> > > > + for (; remain; vaddr += PAGE_SIZE) {
> > > > + if (num_buf >= RXE_BUF_PER_MAP) {
> > > > + map++;
> > > > + buf = map[0]->buf;
> > > > + num_buf = 0;
> > > > + }
> > > > +
> > > > + buf->addr = (uintptr_t)vaddr;
> > > > + if (remain >= PAGE_SIZE)
> > > > + buf->size = PAGE_SIZE;
> > > > + else
> > > >
[PATCH v6 1/2] dt-bindings: display: bridge: lvds-codec: Document LVDS data mapping select
Decoder input LVDS format is a property of the decoder chip or even its strapping. Add DT property data-mapping the same way lvds-panel does, to define the LVDS data mapping. Reviewed-by: Laurent Pinchart Reviewed-by: Rob Herring Signed-off-by: Marek Vasut Cc: Laurent Pinchart Cc: Rob Herring Cc: Sam Ravnborg Cc: devicet...@vger.kernel.org To: dri-devel@lists.freedesktop.org --- V2: - Use allOf - Move the data-mapping to endpoint V3: - Rebase on V2 submitted a while ago, reinstate changelog - Drop the allOf and un-rebase on previous pclk patch V4: - port@1, remove $ref: /schemas/graph.yaml#/properties/port and add $ref: /schemas/graph.yaml#/$defs/port-base V5: - Move the data-mapping property to port@0 , decoder LVDS input - Add RB from Laurent V6: - No change --- .../bindings/display/bridge/lvds-codec.yaml | 33 ++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 304a1367faaa..1faae3e323a4 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -49,11 +49,26 @@ properties: properties: port@0: -$ref: /schemas/graph.yaml#/properties/port +$ref: /schemas/graph.yaml#/$defs/port-base description: | For LVDS encoders, port 0 is the parallel input For LVDS decoders, port 0 is the LVDS input +properties: + endpoint: +$ref: /schemas/media/video-interfaces.yaml# +unevaluatedProperties: false + +properties: + data-mapping: +enum: + - jeida-18 + - jeida-24 + - vesa-24 +description: | + The color signals mapping order. See details in + Documentation/devicetree/bindings/display/panel/lvds.yaml + port@1: $ref: /schemas/graph.yaml#/properties/port description: | @@ -71,6 +86,22 @@ properties: power-supply: true +if: + not: +properties: + compatible: +contains: + const: lvds-decoder +then: + properties: +ports: + properties: +port@0: + properties: +endpoint: + properties: +data-mapping: false + required: - compatible - ports -- 2.33.0
[PATCH v6 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
Decoder input LVDS format is a property of the decoder chip or even
its strapping. Handle data-mapping the same way lvds-panel does. In
case data-mapping is not present, do nothing, since there are still
legacy bindings which do not specify this property.
Reviewed-by: Laurent Pinchart
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Sam Ravnborg
To: dri-devel@lists.freedesktop.org
---
V2: - Move the data-mapping to endpoint
V3: - Rebase on V2 submitted a while ago, reinstate changelog
- Use .atomic_get_input_bus_fmts for the decoder, separate funcs for encoder
V4: - No change
V5: - Move the data-mapping property to port@0 , decoder LVDS input
- Add RB from Laurent
V6: - Turn missing data-mapping into warning, since the driver does
continue in legacy probing mode without it.
---
drivers/gpu/drm/bridge/lvds-codec.c | 76 -
1 file changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
b/drivers/gpu/drm/bridge/lvds-codec.c
index dcf579a4cf83..ad460b96c0a3 100644
--- a/drivers/gpu/drm/bridge/lvds-codec.c
+++ b/drivers/gpu/drm/bridge/lvds-codec.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
@@ -22,6 +23,7 @@ struct lvds_codec {
struct regulator *vcc;
struct gpio_desc *powerdown_gpio;
u32 connector_type;
+ unsigned int bus_format;
};
static inline struct lvds_codec *to_lvds_codec(struct drm_bridge *bridge)
@@ -74,12 +76,50 @@ static const struct drm_bridge_funcs funcs = {
.disable = lvds_codec_disable,
};
+#define MAX_INPUT_SEL_FORMATS 1
+static u32 *
+lvds_codec_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+ struct lvds_codec *lvds_codec = to_lvds_codec(bridge);
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ input_fmts[0] = lvds_codec->bus_format;
+ *num_input_fmts = MAX_INPUT_SEL_FORMATS;
+
+ return input_fmts;
+}
+
+static const struct drm_bridge_funcs funcs_decoder = {
+ .attach = lvds_codec_attach,
+ .enable = lvds_codec_enable,
+ .disable = lvds_codec_disable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_get_input_bus_fmts = lvds_codec_atomic_get_input_bus_fmts,
+};
+
static int lvds_codec_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct device_node *panel_node;
+ struct device_node *bus_node;
struct drm_panel *panel;
struct lvds_codec *lvds_codec;
+ const char *mapping;
+ int ret;
lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
if (!lvds_codec)
@@ -119,13 +159,47 @@ static int lvds_codec_probe(struct platform_device *pdev)
if (IS_ERR(lvds_codec->panel_bridge))
return PTR_ERR(lvds_codec->panel_bridge);
+ lvds_codec->bridge.funcs =
+
+ /*
+* Decoder input LVDS format is a property of the decoder chip or even
+* its strapping. Handle data-mapping the same way lvds-panel does. In
+* case data-mapping is not present, do nothing, since there are still
+* legacy bindings which do not specify this property.
+*/
+ if (lvds_codec->connector_type != DRM_MODE_CONNECTOR_LVDS) {
+ bus_node = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
+ if (!bus_node) {
+ dev_dbg(dev, "bus DT node not found\n");
+ return -ENXIO;
+ }
+
+ ret = of_property_read_string(bus_node, "data-mapping",
+ );
+ of_node_put(bus_node);
+ if (ret < 0) {
+ dev_warn(dev, "missing 'data-mapping' DT property\n");
+ } else {
+ if (!strcmp(mapping, "jeida-18")) {
+ lvds_codec->bus_format =
MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
+ } else if (!strcmp(mapping, "jeida-24")) {
+ lvds_codec->bus_format =
MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
+ } else if (!strcmp(mapping, "vesa-24")) {
+ lvds_codec->bus_format =
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
+ } else {
+
Re: [PATCH v5 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
On 10/10/21 2:27 PM, Sam Ravnborg wrote:
Hi,
[...]
+ if (!bus_node) {
+ dev_dbg(dev, "bus DT node not found\n");
+ return -ENXIO;
+ }
+
+ ret = of_property_read_string(bus_node, "data-mapping",
+ );
+ of_node_put(bus_node);
+ if (ret < 0) {
+ dev_err(dev, "missing 'data-mapping' DT property\n");
+ } else {
It would be nice with a helper for the below code if we need this a third
time.
Where would you store it ?
drm_connector.c seems to be a good place.
Or maybe a static inline in drm_connector.h.
Sorry, this patch has been dragging on for over half a year, another
patch which depends on this has been dragging on for over a year, so I
don't feel particularly motivated to prolong that further by starting a
subsystem patch discussion here now. If someone wants to make this code
more generic, that can surely be a subsequent patch?
[PATCH] drm/i915: replacing drm_modeset_lock_all for DRM_MODESET_LOCK_ALL_*
As requested in GPU Driver Developers Guide TODO list, replaces all
drm_lock boilerplates for DRM_MODESET_LOCK_ALL_* helpers.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/i915/display/intel_display.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 17f44ffea586..71b7ff7b7dea 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13466,22 +13466,13 @@ void intel_display_resume(struct drm_device *dev)
if (state)
state->acquire_ctx =
- drm_modeset_acquire_init(, 0);
-
- while (1) {
- ret = drm_modeset_lock_all_ctx(dev, );
- if (ret != -EDEADLK)
- break;
-
- drm_modeset_backoff();
- }
+ DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
if (!ret)
ret = __intel_display_resume(dev, state, );
intel_enable_ipc(dev_priv);
- drm_modeset_drop_locks();
- drm_modeset_acquire_fini();
+ DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
if (ret)
drm_err(_priv->drm,
--
2.31.1
[PATCH] drm: Remove redundant 'flush_workqueue()' calls
'destroy_workqueue()' already drains the queue before destroying it, so
there is no need to flush it explicitly.
Remove the redundant 'flush_workqueue()' calls.
This was generated with coccinelle:
@@
expression E;
@@
- flush_workqueue(E);
destroy_workqueue(E);
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 1 -
drivers/gpu/drm/msm/dsi/dsi_host.c| 1 -
drivers/gpu/drm/msm/edp/edp_ctrl.c| 1 -
drivers/gpu/drm/msm/hdmi/hdmi.c | 4 +---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 +---
drivers/gpu/drm/vmwgfx/ttm_memory.c | 1 -
6 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 789acae37f55..06bde46df451 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -1733,7 +1733,6 @@ static void etnaviv_gpu_unbind(struct device *dev, struct
device *master,
DBG("%s", dev_name(gpu->dev));
- flush_workqueue(gpu->wq);
destroy_workqueue(gpu->wq);
etnaviv_sched_fini(gpu);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index c86b5090fae6..462ea65ebf89 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1925,7 +1925,6 @@ void msm_dsi_host_destroy(struct mipi_dsi_host *host)
DBG("");
dsi_tx_buf_free(msm_host);
if (msm_host->workqueue) {
- flush_workqueue(msm_host->workqueue);
destroy_workqueue(msm_host->workqueue);
msm_host->workqueue = NULL;
}
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index fe1366b4c49f..07129a6e5dbb 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -1190,7 +1190,6 @@ void msm_edp_ctrl_destroy(struct edp_ctrl *ctrl)
return;
if (ctrl->workqueue) {
- flush_workqueue(ctrl->workqueue);
destroy_workqueue(ctrl->workqueue);
ctrl->workqueue = NULL;
}
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index 737453b6e596..5ba7c8f28419 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -61,10 +61,8 @@ static void msm_hdmi_destroy(struct hdmi *hdmi)
* at this point, hpd has been disabled,
* after flush workq, it's safe to deinit hdcp
*/
- if (hdmi->workq) {
- flush_workqueue(hdmi->workq);
+ if (hdmi->workq)
destroy_workqueue(hdmi->workq);
- }
msm_hdmi_hdcp_destroy(hdmi);
if (hdmi->phy_dev) {
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 6b03f89a98d4..3ddb7c710a3d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -186,10 +186,8 @@ static void tilcdc_fini(struct drm_device *dev)
if (priv->mmio)
iounmap(priv->mmio);
- if (priv->wq) {
- flush_workqueue(priv->wq);
+ if (priv->wq)
destroy_workqueue(priv->wq);
- }
dev->dev_private = NULL;
diff --git a/drivers/gpu/drm/vmwgfx/ttm_memory.c
b/drivers/gpu/drm/vmwgfx/ttm_memory.c
index edd17c30d5a5..7f7fe35fc21d 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_memory.c
+++ b/drivers/gpu/drm/vmwgfx/ttm_memory.c
@@ -468,7 +468,6 @@ void ttm_mem_global_release(struct ttm_mem_global *glob)
struct ttm_mem_zone *zone;
unsigned int i;
- flush_workqueue(glob->swap_queue);
destroy_workqueue(glob->swap_queue);
glob->swap_queue = NULL;
for (i = 0; i < glob->num_zones; ++i) {
--
2.30.2
[PATCH v2] dma-buf: move dma-buf symbols into the DMA_BUF module namespace
In order to better track where in the kernel the dma-buf code is used,
put the symbols in the namespace DMA_BUF and modify all users of the
symbols to properly import the namespace to not break the build at the
same time.
Now the output of modinfo shows the use of these symbols, making it
easier to watch for users over time:
$ modinfo drivers/misc/fastrpc.ko | grep import
import_ns: DMA_BUF
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Mauro Carvalho Chehab
Cc: dri-devel@lists.freedesktop.org
Acked-by: Daniel Vetter
Acked-by: Christian König
Acked-by: Arnd Bergmann
Acked-by: Sumit Semwal
Acked-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman
---
v2: added lots of acks
added 2 more drivers that needed the change, as found by Arnd
drivers/dma-buf/dma-buf.c | 34 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++
drivers/gpu/drm/armada/armada_gem.c | 2 ++
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 3 ++
drivers/gpu/drm/drm_prime.c | 3 ++
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 ++
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 ++
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 3 ++
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 ++
drivers/gpu/drm/tegra/gem.c | 3 ++
drivers/gpu/drm/vmwgfx/ttm_object.c | 3 ++
drivers/infiniband/core/umem_dmabuf.c | 3 ++
.../media/common/videobuf2/videobuf2-core.c | 1 +
.../common/videobuf2/videobuf2-dma-contig.c | 1 +
.../media/common/videobuf2/videobuf2-dma-sg.c | 1 +
.../common/videobuf2/videobuf2-vmalloc.c | 1 +
drivers/misc/fastrpc.c| 1 +
.../staging/media/tegra-vde/dmabuf-cache.c| 3 ++
drivers/tee/tee_shm.c | 3 ++
drivers/virtio/virtio_dma_buf.c | 1 +
drivers/xen/gntdev-dmabuf.c | 3 ++
samples/vfio-mdev/mbochs.c| 1 +
22 files changed, 64 insertions(+), 17 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 63d32261b63f..6c2b5ea828a6 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -610,7 +610,7 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
module_put(exp_info->owner);
return ERR_PTR(ret);
}
-EXPORT_SYMBOL_GPL(dma_buf_export);
+EXPORT_SYMBOL_NS_GPL(dma_buf_export, DMA_BUF);
/**
* dma_buf_fd - returns a file descriptor for the given struct dma_buf
@@ -634,7 +634,7 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags)
return fd;
}
-EXPORT_SYMBOL_GPL(dma_buf_fd);
+EXPORT_SYMBOL_NS_GPL(dma_buf_fd, DMA_BUF);
/**
* dma_buf_get - returns the struct dma_buf related to an fd
@@ -660,7 +660,7 @@ struct dma_buf *dma_buf_get(int fd)
return file->private_data;
}
-EXPORT_SYMBOL_GPL(dma_buf_get);
+EXPORT_SYMBOL_NS_GPL(dma_buf_get, DMA_BUF);
/**
* dma_buf_put - decreases refcount of the buffer
@@ -679,7 +679,7 @@ void dma_buf_put(struct dma_buf *dmabuf)
fput(dmabuf->file);
}
-EXPORT_SYMBOL_GPL(dma_buf_put);
+EXPORT_SYMBOL_NS_GPL(dma_buf_put, DMA_BUF);
static void mangle_sg_table(struct sg_table *sg_table)
{
@@ -810,7 +810,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
dma_buf_detach(dmabuf, attach);
return ERR_PTR(ret);
}
-EXPORT_SYMBOL_GPL(dma_buf_dynamic_attach);
+EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach, DMA_BUF);
/**
* dma_buf_attach - Wrapper for dma_buf_dynamic_attach
@@ -825,7 +825,7 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
{
return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
}
-EXPORT_SYMBOL_GPL(dma_buf_attach);
+EXPORT_SYMBOL_NS_GPL(dma_buf_attach, DMA_BUF);
static void __unmap_dma_buf(struct dma_buf_attachment *attach,
struct sg_table *sg_table,
@@ -871,7 +871,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct
dma_buf_attachment *attach)
kfree(attach);
}
-EXPORT_SYMBOL_GPL(dma_buf_detach);
+EXPORT_SYMBOL_NS_GPL(dma_buf_detach, DMA_BUF);
/**
* dma_buf_pin - Lock down the DMA-buf
@@ -901,7 +901,7 @@ int dma_buf_pin(struct dma_buf_attachment *attach)
return ret;
}
-EXPORT_SYMBOL_GPL(dma_buf_pin);
+EXPORT_SYMBOL_NS_GPL(dma_buf_pin, DMA_BUF);
/**
* dma_buf_unpin - Unpin a DMA-buf
@@ -922,7 +922,7 @@ void dma_buf_unpin(struct dma_buf_attachment *attach)
if (dmabuf->ops->unpin)
dmabuf->ops->unpin(attach);
}
-EXPORT_SYMBOL_GPL(dma_buf_unpin);
+EXPORT_SYMBOL_NS_GPL(dma_buf_unpin, DMA_BUF);
/**
* dma_buf_map_attachment - Returns the scatterlist table of the attachment;
@@ -1012,7 +1012,7 @@ struct sg_table *dma_buf_map_attachment(struct
dma_buf_attachment *attach,
#endif /* CONFIG_DMA_API_DEBUG */
return sg_table;
}
-EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
Re: [PATCH] dma-buf: move dma-buf symbols into the DMA_BUF module namespace
On Mon, Sep 27, 2021 at 11:00:14AM -0400, Alex Deucher wrote: > On Mon, Sep 27, 2021 at 7:15 AM Sumit Semwal wrote: > > > > Hello Greg, > > > > Thanks for the patch! > > > > On Sat, 25 Sept 2021 at 19:17, Greg Kroah-Hartman > > wrote: > >> > >> In order to better track where in the kernel the dma-buf code is used, > >> put the symbols in the namespace DMA_BUF and modify all users of the > >> symbols to properly import the namespace to not break the build at the > >> same time. > >> > >> Now the output of modinfo shows the use of these symbols, making it > >> easier to watch for users over time: > >> > >> $ modinfo drivers/misc/fastrpc.ko | grep import > >> import_ns: DMA_BUF > >> > >> Cc: Sumit Semwal > >> Cc: "Christian König" > >> Cc: Alex Deucher > >> Cc: "Pan, Xinhui" > >> Cc: David Airlie > >> Cc: Daniel Vetter > >> Cc: Maarten Lankhorst > >> Cc: Maxime Ripard > >> Cc: Thomas Zimmermann > >> Cc: Mauro Carvalho Chehab > >> Cc: Arnd Bergmann > >> Cc: dri-devel@lists.freedesktop.org > >> Signed-off-by: Greg Kroah-Hartman > > > > > > With the addition of the 2 misses found by Arnd, please feel free to add my > > Acked-by: Sumit Semwal > > Same here. > > Acked-by: Alex Deucher Thanks both of you for your acks. greg k-h
Re: [PATCH] dma-buf: move dma-buf symbols into the DMA_BUF module namespace
On Mon, Sep 27, 2021 at 11:39:21AM +0200, Arnd Bergmann wrote: > On Sat, Sep 25, 2021 at 7:41 PM Arnd Bergmann wrote: > > On Sat, Sep 25, 2021 at 3:47 PM Greg Kroah-Hartman > > wrote: > > > > Only test-built on x86 allmodconfig, don't know what other arches will > > > pick up, will let 0-day run on it for a bit... > > > > I've added it to my build box doing arm32/arm64/x86 randconfig tests, > > if it doesn't report anything by Monday, it's probably good in that regard. > > It found these two, please fold into your patch: Now folded in, odd that 0-day didn't find it... Thanks for the ack as well, I'll send out a v2 soon. greg k-h
Re: [PATCH] dma-buf: move dma-buf symbols into the DMA_BUF module namespace
On Mon, Sep 27, 2021 at 12:08:45PM +0200, Christian König wrote: > Am 25.09.21 um 15:47 schrieb Greg Kroah-Hartman: > > In order to better track where in the kernel the dma-buf code is used, > > put the symbols in the namespace DMA_BUF and modify all users of the > > symbols to properly import the namespace to not break the build at the > > same time. > > > > Now the output of modinfo shows the use of these symbols, making it > > easier to watch for users over time: > > > > $ modinfo drivers/misc/fastrpc.ko | grep import > > import_ns: DMA_BUF > > > > Cc: Sumit Semwal > > Cc: "Christian König" > > Cc: Alex Deucher > > Cc: "Pan, Xinhui" > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > Cc: Mauro Carvalho Chehab > > Cc: Arnd Bergmann > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Greg Kroah-Hartman > > Acked-by: Christian König Thanks for the ack. greg k-h
Re: [PATCH] dma-buf: move dma-buf symbols into the DMA_BUF module namespace
On Tue, Sep 28, 2021 at 09:31:45AM +0200, Daniel Vetter wrote: > On Sat, Sep 25, 2021 at 03:47:00PM +0200, Greg Kroah-Hartman wrote: > > In order to better track where in the kernel the dma-buf code is used, > > put the symbols in the namespace DMA_BUF and modify all users of the > > symbols to properly import the namespace to not break the build at the > > same time. > > > > Now the output of modinfo shows the use of these symbols, making it > > easier to watch for users over time: > > > > $ modinfo drivers/misc/fastrpc.ko | grep import > > import_ns: DMA_BUF > > > > Cc: Sumit Semwal > > Cc: "Christian König" > > Cc: Alex Deucher > > Cc: "Pan, Xinhui" > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > Cc: Mauro Carvalho Chehab > > Cc: Arnd Bergmann > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Greg Kroah-Hartman > > --- > > > > The topic of dma-buf came up in the Maintainer's summit yesterday, and > > one comment was to put the symbols in their own module namespace, to > > make it easier to notice and track who was using them. This patch does > > so, and finds some "interesting" users of the api already in the tree. > > Yeah, the interesting ones is why I added the dma-buf wildcard match a > while ago. Since that landed I don't think anything escaped. Should we > perhaps also add > > K: MODULE_IMPORT_NS(DMA_BUF); > > to the dma-buf MAINATINERS entry? Entirely untested, also no idea whether > there's not a better way to match for module namespaces. Either way: I think MAINTAINERS is already overloaded with too many of these things, but feel free to mess with it if you want to :) > Acked-by: Daniel Vetter Thanks for the ack! greg k-h
[PATCH v3 5/5] drm/i915/panelreplay: Added state checker for panel replay state
has_panel_replay flag is used to check panel replay state
which is part of crtc_state structure.
v1: RFC version.
v2: has_panel_replay flag updated as per hw readout. [Jani]
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_display.c | 1 +
drivers/gpu/drm/i915/display/intel_psr.c | 6 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 4f0badb11bbb..a30b6fe87dfc 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8136,6 +8136,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_BOOL(has_psr);
PIPE_CONF_CHECK_BOOL(has_psr2);
PIPE_CONF_CHECK_BOOL(enable_psr2_sel_fetch);
+ PIPE_CONF_CHECK_BOOL(has_panel_replay);
PIPE_CONF_CHECK_I(dc3co_exitline);
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 49f6242c2fde..d1a30b82ce6f 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1054,6 +1054,12 @@ void intel_psr_get_config(struct intel_encoder *encoder,
pipe_config->has_psr2 = intel_dp->psr.psr2_enabled;
pipe_config->infoframes.enable |=
intel_hdmi_infoframe_enable(DP_SDP_VSC);
+ if (HAS_PANEL_REPLAY(dev_priv) && HAS_DP20(dev_priv)) {
+ val = intel_de_read(dev_priv,
TRANS_DP2_CTL(intel_dp->psr.transcoder));
+ if (val & TRANS_DP2_PANEL_REPLAY_ENABLE)
+ pipe_config->has_panel_replay = true;
+ }
+
if (!intel_dp->psr.psr2_enabled)
goto unlock;
--
2.29.0
[PATCH v3 4/5] drm/i915/panelreplay: enable/disable panel replay
TRANS_DP2_CTL register is programmed to enable panel replay from source
and sink is enabled through panel replay dpcd configuration address.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_psr.c | 30
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 91c2efe2f3ad..49f6242c2fde 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -370,8 +370,14 @@ static void intel_psr_enable_sink(struct intel_dp
*intel_dp)
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
u8 dpcd_val = DP_PSR_ENABLE;
- /* Enable ALPM at sink for psr2 */
+ if (intel_dp->psr.enabled && !intel_dp_is_edp(intel_dp)) {
+ drm_dp_dpcd_writeb(_dp->aux, PANEL_REPLAY_CONFIG,
+ PANEL_REPLAY_ENABLE);
+ return;
+ }
+
if (intel_dp->psr.psr2_enabled) {
+ /* Enable ALPM at sink for psr2 */
drm_dp_dpcd_writeb(_dp->aux, DP_RECEIVER_ALPM_CONFIG,
DP_ALPM_ENABLE |
DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE);
@@ -498,6 +504,17 @@ static u32 intel_psr2_get_tp_time(struct intel_dp
*intel_dp)
return val;
}
+static void dg2_activate_panel_replay(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+ intel_de_write(dev_priv, PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder),
+ ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE);
+
+ intel_de_rmw(dev_priv, TRANS_DP2_CTL(intel_dp->psr.transcoder), 0,
+TRANS_DP2_PANEL_REPLAY_ENABLE);
+}
+
static void hsw_activate_psr2(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -1069,8 +1086,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
drm_WARN_ON(_priv->drm, intel_dp->psr.active);
lockdep_assert_held(_dp->psr.lock);
- /* psr1 and psr2 are mutually exclusive.*/
- if (intel_dp->psr.psr2_enabled)
+ /* psr1, psr2 and panel-replay are mutually exclusive.*/
+ if (intel_dp->psr.enabled && !intel_dp_is_edp(intel_dp))
+ dg2_activate_panel_replay(intel_dp);
+ else if (intel_dp->psr.psr2_enabled)
hsw_activate_psr2(intel_dp);
else
hsw_activate_psr1(intel_dp);
@@ -1243,7 +1262,10 @@ static void intel_psr_exit(struct intel_dp *intel_dp)
return;
}
- if (intel_dp->psr.psr2_enabled) {
+ if (intel_dp->psr.enabled && !intel_dp_is_edp(intel_dp)) {
+ intel_de_rmw(dev_priv, TRANS_DP2_CTL(intel_dp->psr.transcoder),
+TRANS_DP2_PANEL_REPLAY_ENABLE, 0);
+ } else if (intel_dp->psr.psr2_enabled) {
tgl_disallow_dc3co_on_psr2_exit(intel_dp);
val = intel_de_read(dev_priv,
EDP_PSR2_CTL(intel_dp->psr.transcoder));
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a897f4abea0c..6cc6ebcd3bdb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4725,6 +4725,7 @@ enum {
#define PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME REG_BIT(3)
#define PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME REG_BIT(2)
#define PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE REG_BIT(1)
+#define ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE REG_BIT(31)
#define ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR_MASK REG_GENMASK(28,
16)
#define ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(val)
REG_FIELD_PREP(ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR_MASK, val)
#define ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR_MASK REG_GENMASK(12,
0)
--
2.29.0
[PATCH v3 3/5] drm/i915/panelreplay: Initializaton and compute config for panel replay
As panel replay feature similar to PSR feature of EDP panel, so currently
utilized existing psr framework for panel replay.
v1: RFC version.
v2: optimized code, pr_enabled and pr_dpcd variable removed. [Jose]
v3:
- code comments improved. [Jani]
- dpcd_readb used instead of dpcd_read. [Jani]
- panel-repaplay init/compute functions moved inside respective psr
function. [Jani]
Signed-off-by: Animesh Manna
---
.../drm/i915/display/intel_display_types.h| 2 +
drivers/gpu/drm/i915/display/intel_dp.c | 43 +
drivers/gpu/drm/i915/display/intel_psr.c | 48 +++
drivers/gpu/drm/i915/display/intel_psr.h | 3 ++
4 files changed, 87 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 39e11eaec1a3..48f7d676ed2c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1070,6 +1070,7 @@ struct intel_crtc_state {
bool req_psr2_sdp_prior_scanline;
u32 dc3co_exitline;
u16 su_y_granularity;
+ bool has_panel_replay;
struct drm_dp_vsc_sdp psr_vsc;
/*
@@ -1531,6 +1532,7 @@ struct intel_psr {
bool irq_aux_error;
u16 su_w_granularity;
u16 su_y_granularity;
+ bool sink_panel_replay_support;
u32 dc3co_exitline;
u32 dc3co_exit_delay;
struct delayed_work dc3co_work;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 10fda20a5bd8..f58a7b72be14 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1587,12 +1587,22 @@ static void intel_dp_compute_vsc_colorimetry(const
struct intel_crtc_state *crtc
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- /*
-* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
-* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
-* Colorimetry Format indication.
-*/
- vsc->revision = 0x5;
+ if (crtc_state->has_panel_replay) {
+ /*
+* Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
+* VSC SDP supporting 3D stereo, Panel Replay, and Pixel
+* Encoding/Colorimetry Format indication.
+*/
+ vsc->revision = 0x7;
+ } else {
+ /*
+* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
+* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
+* Colorimetry Format indication.
+*/
+ vsc->revision = 0x5;
+ }
+
vsc->length = 0x13;
/* DP 1.4a spec, Table 2-120 */
@@ -1701,6 +1711,21 @@ void intel_dp_compute_psr_vsc_sdp(struct intel_dp
*intel_dp,
vsc->revision = 0x4;
vsc->length = 0xe;
}
+ } else if (intel_dp->psr.enabled && !intel_dp_is_edp(intel_dp)) {
+ if (intel_dp->psr.colorimetry_support &&
+ intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
+ /* [Panel Replay with colorimetry info] */
+ intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
+vsc);
+ } else {
+ /*
+* [Panel Replay without colorimetry info]
+* Prepare VSC Header for SU as per DP 2.0 spec, Table
2-223
+* VSC SDP supporting 3D stereo + Panel Replay.
+*/
+ vsc->revision = 0x6;
+ vsc->length = 0x10;
+ }
} else {
/*
* [PSR1]
@@ -2749,10 +2774,10 @@ static ssize_t intel_dp_vsc_sdp_pack(const struct
drm_dp_vsc_sdp *vsc,
sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
/*
-* Only revision 0x5 supports Pixel Encoding/Colorimetry Format as
-* per DP 1.4a spec.
+* Revision 0x5 and 0x7 supports Pixel Encoding/Colorimetry Format as
+* per DP 1.4a spec and DP 2.0 spec respectively.
*/
- if (vsc->revision != 0x5)
+ if (vsc->revision != 0x5 || vsc->revision != 0x7)
goto out;
/* VSC SDP Payload for DB16 through DB18 */
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 7a205fd5023b..91c2efe2f3ad 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -933,6 +933,21 @@ static bool intel_psr2_config_valid(struct intel_dp
*intel_dp,
return true;
}
+void intel_panel_replay_compute_config(struct intel_dp *intel_dp,
+
[PATCH v3 2/5] drm/i915/panelreplay: HAS_PR() macro added for panel replay
Platforms having Display 13 and above will support panel replay feature of DP 2.0 monitor. Added a HAS_PR() macro to check for panel replay capability. v1: Initial version. v2: DISPLAY_VER macro used instead of has_pr flag. [Jose] v3: HAS_PR renamed to HAS_PANEL_REPLAY. [Jani] Signed-off-by: Animesh Manna --- drivers/gpu/drm/i915/i915_drv.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 12256218634f..37313bf51a90 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1693,6 +1693,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)->display.has_ddi) #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)->display.has_fpga_dbg) #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)->display.has_psr) +#define HAS_PANEL_REPLAY(dev_priv) (DISPLAY_VER(dev_priv) >= 13) #define HAS_PSR_HW_TRACKING(dev_priv) \ (INTEL_INFO(dev_priv)->display.has_psr_hw_tracking) #define HAS_PSR2_SEL_FETCH(dev_priv)(GRAPHICS_VER(dev_priv) >= 12) -- 2.29.0
[PATCH v3 1/5] drm/i915/panelreplay: dpcd register definition for panelreplay
DPCD register definition added to check and enable panel replay capability of the sink. Signed-off-by: Animesh Manna --- include/drm/drm_dp_helper.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index b52df4db3e8f..8a2b929c3f88 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -541,6 +541,9 @@ struct drm_panel; /* DFP Capability Extension */ #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT0x0a3 /* 2.0 */ +#define DP_PANEL_REPLAY_CAP 0x0b0 +# define PANEL_REPLAY_SUPPORT (1 << 0) + /* Link Configuration */ #defineDP_LINK_BW_SET 0x100 # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */ @@ -709,6 +712,9 @@ struct drm_panel; #define DP_BRANCH_DEVICE_CTRL 0x1a1 # define DP_BRANCH_DEVICE_IRQ_HPD (1 << 0) +#define PANEL_REPLAY_CONFIG 0x1b0 +# define PANEL_REPLAY_ENABLE(1 << 0) + #define DP_PAYLOAD_ALLOCATE_SET0x1c0 #define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1 #define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2 -- 2.29.0
[PATCH v3 0/5] Panel replay phase1 implementation
Panel Replay is a power saving feature for DP 2.0 monitor and similar to PSR on EDP. These patches are basic enablement patches and reused psr framework to add panel replay related new changes which may need further fine tuning to fill the gap if there is any. Note: The patches are not tested due to unavailability of monitor Animesh Manna (5): drm/i915/panelreplay: dpcd register definition for panelreplay drm/i915/panelreplay: HAS_PR() macro added for panel replay drm/i915/panelreplay: Initializaton and compute config for panel replay drm/i915/panelreplay: enable/disable panel replay drm/i915/panelreplay: Added state checker for panel replay state drivers/gpu/drm/i915/display/intel_display.c | 1 + .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_dp.c | 43 -- drivers/gpu/drm/i915/display/intel_psr.c | 84 ++- drivers/gpu/drm/i915/display/intel_psr.h | 3 + drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_reg.h | 1 + include/drm/drm_dp_helper.h | 6 ++ 8 files changed, 128 insertions(+), 13 deletions(-) -- 2.29.0
Re: [PATCH v5 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
Hi Laurent,
> > > +
> > > + /*
> > > + * Decoder input LVDS format is a property of the decoder chip or even
> > > + * its strapping. Handle data-mapping the same way lvds-panel does. In
> > > + * case data-mapping is not present, do nothing, since there are still
> > > + * legacy bindings which do not specify this property.
> >
> > The missing data-mapping property is reported as an error, but this
> > comments says it is OK. Info?
>
> It's not a fatal error, probe still continues in backward-compatibility
> mode. The message is there to tell that the DT should be updated. Would
> you downgrade that to a warning ?
Warning would IMO be better as this is not an error that stops it from
working.
>
> > > + */
> > > + if (lvds_codec->connector_type != DRM_MODE_CONNECTOR_LVDS) {
> > > + bus_node = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
> >
> > Are there any reg specified in the binding? If not then the second
> > parameter should be -1 here.
>
> Yes, the DT node has two ports, with port 0 being the input. For LVDS
> decoders, that's where the LVDS bus is.
OK.
>
> > > + if (!bus_node) {
> > > + dev_dbg(dev, "bus DT node not found\n");
> > > + return -ENXIO;
> > > + }
> > > +
> > > + ret = of_property_read_string(bus_node, "data-mapping",
> > > + );
> > > + of_node_put(bus_node);
> > > + if (ret < 0) {
> > > + dev_err(dev, "missing 'data-mapping' DT property\n");
> > > + } else {
> >
> > It would be nice with a helper for the below code if we need this a third
> > time.
>
> Where would you store it ?
drm_connector.c seems to be a good place.
Or maybe a static inline in drm_connector.h.
>
> > > + if (!strcmp(mapping, "jeida-18")) {
> > > + lvds_codec->bus_format =
> > > MEDIA_BUS_FMT_RGB666_1X7X3_SPWG;
> > > + } else if (!strcmp(mapping, "jeida-24")) {
> > > + lvds_codec->bus_format =
> > > MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA;
> > > + } else if (!strcmp(mapping, "vesa-24")) {
> > > + lvds_codec->bus_format =
> > > MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;
> > > + } else {
> > > + dev_err(dev, "invalid 'data-mapping' DT
> > > property\n");
> > > + return -EINVAL;
> > > + }
Sam
Re: [PATCH v5 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
Hi Sam,
On Sun, Oct 10, 2021 at 10:16:22AM +0200, Sam Ravnborg wrote:
> On Sun, Oct 10, 2021 at 12:41:52AM +0200, Marek Vasut wrote:
> > Decoder input LVDS format is a property of the decoder chip or even
> > its strapping. Handle data-mapping the same way lvds-panel does. In
> > case data-mapping is not present, do nothing, since there are still
> > legacy bindings which do not specify this property.
> >
> > Reviewed-by: Laurent Pinchart
> > Signed-off-by: Marek Vasut
> > Cc: Laurent Pinchart
> > Cc: Sam Ravnborg
> > To: dri-devel@lists.freedesktop.org
>
> I am late to the game here - sorry. A few details in the following.
> With these considered:
> Reviewed-by: Sam Ravnborg
>
> > ---
> > V2: - Move the data-mapping to endpoint
> > V3: - Rebase on V2 submitted a while ago, reinstate changelog
> > - Use .atomic_get_input_bus_fmts for the decoder, separate funcs for
> > encoder
> > V4: - No change
> > V5: - Move the data-mapping property to port@0 , decoder LVDS input
> > - Add RB from Laurent
> > ---
> > drivers/gpu/drm/bridge/lvds-codec.c | 76 -
> > 1 file changed, 75 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> > b/drivers/gpu/drm/bridge/lvds-codec.c
> > index dcf579a4cf83..08091bab4857 100644
> > --- a/drivers/gpu/drm/bridge/lvds-codec.c
> > +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> > @@ -12,6 +12,7 @@
> > #include
> > #include
> >
> > +#include
> > #include
> > #include
> >
> > @@ -22,6 +23,7 @@ struct lvds_codec {
> > struct regulator *vcc;
> > struct gpio_desc *powerdown_gpio;
> > u32 connector_type;
> > + unsigned int bus_format;
> > };
> >
> > static inline struct lvds_codec *to_lvds_codec(struct drm_bridge *bridge)
> > @@ -74,12 +76,50 @@ static const struct drm_bridge_funcs funcs = {
> > .disable = lvds_codec_disable,
> > };
> >
> > +#define MAX_INPUT_SEL_FORMATS 1
> > +static u32 *
> > +lvds_codec_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
> > +struct drm_bridge_state *bridge_state,
> > +struct drm_crtc_state *crtc_state,
> > +struct drm_connector_state *conn_state,
> > +u32 output_fmt,
> > +unsigned int *num_input_fmts)
> > +{
> > + struct lvds_codec *lvds_codec = to_lvds_codec(bridge);
> > + u32 *input_fmts;
> > +
> > + *num_input_fmts = 0;
> > +
> > + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
> > +GFP_KERNEL);
> > + if (!input_fmts)
> > + return NULL;
> > +
> > + input_fmts[0] = lvds_codec->bus_format;
> > + *num_input_fmts = MAX_INPUT_SEL_FORMATS;
> > +
> > + return input_fmts;
> > +}
> > +
> > +static const struct drm_bridge_funcs funcs_decoder = {
> > + .attach = lvds_codec_attach,
> > + .enable = lvds_codec_enable,
> > + .disable = lvds_codec_disable,
> > + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> > + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> > + .atomic_reset = drm_atomic_helper_bridge_reset,
> > + .atomic_get_input_bus_fmts = lvds_codec_atomic_get_input_bus_fmts,
> > +};
> > +
> > static int lvds_codec_probe(struct platform_device *pdev)
> > {
> > struct device *dev = >dev;
> > struct device_node *panel_node;
> > + struct device_node *bus_node;
> > struct drm_panel *panel;
> > struct lvds_codec *lvds_codec;
> > + const char *mapping;
> > + int ret;
> >
> > lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
> > if (!lvds_codec)
> > @@ -119,13 +159,47 @@ static int lvds_codec_probe(struct platform_device
> > *pdev)
> > if (IS_ERR(lvds_codec->panel_bridge))
> > return PTR_ERR(lvds_codec->panel_bridge);
> >
> > + lvds_codec->bridge.funcs =
> > +
> > + /*
> > +* Decoder input LVDS format is a property of the decoder chip or even
> > +* its strapping. Handle data-mapping the same way lvds-panel does. In
> > +* case data-mapping is not present, do nothing, since there are still
> > +* legacy bindings which do not specify this property.
>
> The missing data-mapping property is reported as an error, but this
> comments says it is OK. Info?
It's not a fatal error, probe still continues in backward-compatibility
mode. The message is there to tell that the DT should be updated. Would
you downgrade that to a warning ?
> > +*/
> > + if (lvds_codec->connector_type != DRM_MODE_CONNECTOR_LVDS) {
> > + bus_node = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
>
> Are there any reg specified in the binding? If not then the second
> parameter should be -1 here.
Yes, the DT node has two ports, with port 0 being the input. For LVDS
decoders, that's where the LVDS bus is.
> > + if (!bus_node) {
> > + dev_dbg(dev, "bus DT node not
[PATCH] [v5] dt-bindings: drm/msm/gpu: convert to YAML
Conversion of text binding for Adreno GPU to the YAML format.
Signed-off-by: David Heidelberg
---
v2:
- added compatbile description from Rob Clark
- dropped reg description
- reg numbers increased to 3 (since we also have uncommon cx_dbgc)
- specified interconnect-names items range
- defined zap-shader as an object and added it's properties
- enforce 0 clocks for Andreno >= 6xx since it's defined in GMU node
v3:
- fix patterns (add backslash before dot)
- add additional clocks
- adreno@ -> gpu@
- add few const and change enum to anyOf
- added clock & clock-names placeholder in non-conditional part
(description)
v4:
- clock & clock-names - true,false instead maxItems
- impl. #stream-id-cells, nvmem-cell-names, nvmem-cells
- dropped requirement on firmware-name in zap_shader
v5:
- maxOtems -> maxItems typo fix
.../devicetree/bindings/display/msm/gpu.txt | 157 -
.../devicetree/bindings/display/msm/gpu.yaml | 302 ++
2 files changed, 302 insertions(+), 157 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/msm/gpu.txt
create mode 100644 Documentation/devicetree/bindings/display/msm/gpu.yaml
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt
b/Documentation/devicetree/bindings/display/msm/gpu.txt
deleted file mode 100644
index 090dcb3fc34d..
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ /dev/null
@@ -1,157 +0,0 @@
-Qualcomm adreno/snapdragon GPU
-
-Required properties:
-- compatible: "qcom,adreno-XYZ.W", "qcom,adreno" or
- "amd,imageon-XYZ.W", "amd,imageon"
-for example: "qcom,adreno-306.0", "qcom,adreno"
- Note that you need to list the less specific "qcom,adreno" (since this
- is what the device is matched on), in addition to the more specific
- with the chip-id.
- If "amd,imageon" is used, there should be no top level msm device.
-- reg: Physical base address and length of the controller's registers.
-- interrupts: The interrupt signal from the gpu.
-- clocks: device clocks (if applicable)
- See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required by a3xx, a4xx and a5xx
- cores:
- * "core"
- * "iface"
- * "mem_iface"
- For GMU attached devices the GPU clocks are not used and are not required.
The
- following devices should not list clocks:
- - qcom,adreno-630.2
-- iommus: optional phandle to an adreno iommu instance
-- operating-points-v2: optional phandle to the OPP operating points
-- interconnects: optional phandle to an interconnect provider. See
- ../interconnect/interconnect.txt for details. Some A3xx and all A4xx
platforms
- will have two paths; all others will have one path.
-- interconnect-names: The names of the interconnect paths that correspond to
the
- interconnects property. Values must be gfx-mem and ocmem.
-- qcom,gmu: For GMU attached devices a phandle to the GMU device that will
- control the power for the GPU. Applicable targets:
-- qcom,adreno-630.2
-- zap-shader: For a5xx and a6xx devices this node contains a memory-region that
- points to reserved memory to store the zap shader that can be used to help
- bring the GPU out of secure mode.
-- firmware-name: optional property of the 'zap-shader' node, listing the
- relative path of the device specific zap firmware.
-- sram: phandle to the On Chip Memory (OCMEM) that's present on some a3xx and
-a4xx Snapdragon SoCs. See
-Documentation/devicetree/bindings/sram/qcom,ocmem.yaml.
-
-Optional properties:
-- #cooling-cells: The value must be 2. For details, please refer
- Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml.
-
-Example 3xx/4xx:
-
-/ {
- ...
-
- gpu: adreno@fdb0 {
- compatible = "qcom,adreno-330.2",
-"qcom,adreno";
- reg = <0xfdb0 0x1>;
- reg-names = "kgsl_3d0_reg_memory";
- interrupts = ;
- interrupt-names = "kgsl_3d0_irq";
- clock-names = "core",
- "iface",
- "mem_iface";
- clocks = < OXILI_GFX3D_CLK>,
-< OXILICX_AHB_CLK>,
-< OXILICX_AXI_CLK>;
- sram = <_sram>;
- power-domains = < OXILICX_GDSC>;
- operating-points-v2 = <_opp_table>;
- iommus = <_iommu 0>;
- #cooling-cells = <2>;
- };
-
- gpu_sram: ocmem@fdd0 {
- compatible = "qcom,msm8974-ocmem";
-
- reg = <0xfdd0 0x2000>,
- <0xfec0 0x18>;
- reg-names = "ctrl",
- "mem";
-
- clocks = < RPM_SMD_OCMEMGX_CLK>,
-< OCMEMCX_OCMEMNOC_CLK>;
- clock-names = "core",
- "iface";
-
- #address-cells = <1>;
-
Re: [PATCH v5 2/2] drm/bridge: lvds-codec: Add support for LVDS data mapping select
Hi Marek,
On Sun, Oct 10, 2021 at 12:41:52AM +0200, Marek Vasut wrote:
> Decoder input LVDS format is a property of the decoder chip or even
> its strapping. Handle data-mapping the same way lvds-panel does. In
> case data-mapping is not present, do nothing, since there are still
> legacy bindings which do not specify this property.
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc: Sam Ravnborg
> To: dri-devel@lists.freedesktop.org
I am late to the game here - sorry. A few details in the following.
With these considered:
Reviewed-by: Sam Ravnborg
Sam
> ---
> V2: - Move the data-mapping to endpoint
> V3: - Rebase on V2 submitted a while ago, reinstate changelog
> - Use .atomic_get_input_bus_fmts for the decoder, separate funcs for
> encoder
> V4: - No change
> V5: - Move the data-mapping property to port@0 , decoder LVDS input
> - Add RB from Laurent
> ---
> drivers/gpu/drm/bridge/lvds-codec.c | 76 -
> 1 file changed, 75 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/lvds-codec.c
> b/drivers/gpu/drm/bridge/lvds-codec.c
> index dcf579a4cf83..08091bab4857 100644
> --- a/drivers/gpu/drm/bridge/lvds-codec.c
> +++ b/drivers/gpu/drm/bridge/lvds-codec.c
> @@ -12,6 +12,7 @@
> #include
> #include
>
> +#include
> #include
> #include
>
> @@ -22,6 +23,7 @@ struct lvds_codec {
> struct regulator *vcc;
> struct gpio_desc *powerdown_gpio;
> u32 connector_type;
> + unsigned int bus_format;
> };
>
> static inline struct lvds_codec *to_lvds_codec(struct drm_bridge *bridge)
> @@ -74,12 +76,50 @@ static const struct drm_bridge_funcs funcs = {
> .disable = lvds_codec_disable,
> };
>
> +#define MAX_INPUT_SEL_FORMATS 1
> +static u32 *
> +lvds_codec_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
> + struct drm_bridge_state *bridge_state,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state,
> + u32 output_fmt,
> + unsigned int *num_input_fmts)
> +{
> + struct lvds_codec *lvds_codec = to_lvds_codec(bridge);
> + u32 *input_fmts;
> +
> + *num_input_fmts = 0;
> +
> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
> + GFP_KERNEL);
> + if (!input_fmts)
> + return NULL;
> +
> + input_fmts[0] = lvds_codec->bus_format;
> + *num_input_fmts = MAX_INPUT_SEL_FORMATS;
> +
> + return input_fmts;
> +}
> +
> +static const struct drm_bridge_funcs funcs_decoder = {
> + .attach = lvds_codec_attach,
> + .enable = lvds_codec_enable,
> + .disable = lvds_codec_disable,
> + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> + .atomic_reset = drm_atomic_helper_bridge_reset,
> + .atomic_get_input_bus_fmts = lvds_codec_atomic_get_input_bus_fmts,
> +};
> +
> static int lvds_codec_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct device_node *panel_node;
> + struct device_node *bus_node;
> struct drm_panel *panel;
> struct lvds_codec *lvds_codec;
> + const char *mapping;
> + int ret;
>
> lvds_codec = devm_kzalloc(dev, sizeof(*lvds_codec), GFP_KERNEL);
> if (!lvds_codec)
> @@ -119,13 +159,47 @@ static int lvds_codec_probe(struct platform_device
> *pdev)
> if (IS_ERR(lvds_codec->panel_bridge))
> return PTR_ERR(lvds_codec->panel_bridge);
>
> + lvds_codec->bridge.funcs =
> +
> + /*
> + * Decoder input LVDS format is a property of the decoder chip or even
> + * its strapping. Handle data-mapping the same way lvds-panel does. In
> + * case data-mapping is not present, do nothing, since there are still
> + * legacy bindings which do not specify this property.
The missing data-mapping property is reported as an error, but this
comments says it is OK. Info?
> + */
> + if (lvds_codec->connector_type != DRM_MODE_CONNECTOR_LVDS) {
> + bus_node = of_graph_get_endpoint_by_regs(dev->of_node, 0, 0);
Are there any reg specified in the binding? If not then the second
parameter should be -1 here.
> + if (!bus_node) {
> + dev_dbg(dev, "bus DT node not found\n");
> + return -ENXIO;
> + }
> +
> + ret = of_property_read_string(bus_node, "data-mapping",
> + );
> + of_node_put(bus_node);
> + if (ret < 0) {
> + dev_err(dev, "missing 'data-mapping' DT property\n");
> + } else {
It would be nice with a helper for the below code if we need this a third
time.
> + if (!strcmp(mapping,
Re: [PATCH 2/2] fbdev: fbmem: Fix double free of 'fb_info->pixmap.addr'
Hi Zheyu, On Sun, Oct 10, 2021 at 06:42:28AM +, Zheyu Ma wrote: > savagefb and some other drivers call kfree to free 'info->pixmap.addr' > even after calling unregister_framebuffer, which may cause double free. > > Fix this by setting 'fb_info->pixmap.addr' to NULL after kfree in > unregister_framebuffer. This is a nice general way to fix it that benefits all drivers. Applied to drm-misc-next as this is not an urgent fix. Sam
[airlied:drm-intel-display-refactor 7/9] drivers/gpu/drm/i915/display/intel_fbdev.c:251:60: sparse: sparse: incorrect type in argument 3 (different address spaces)
tree: git://people.freedesktop.org/~airlied/linux.git
drm-intel-display-refactor
head: 57c0bb98bd7351cfb13403dd854cc9a0fc9ad5df
commit: 0f3c35589c8c2924d384164482aa273def8aaf1a [7/9] drm/i915/display:
refactor fbdev pin/unpin out into functions.
config: i386-randconfig-s001-20211010 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-dirty
git remote add airlied git://people.freedesktop.org/~airlied/linux.git
git fetch --no-tags airlied drm-intel-display-refactor
git checkout 0f3c35589c8c2924d384164482aa273def8aaf1a
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/gpu/drm/i915/display/intel_fbdev.c:188:16: sparse: sparse: incorrect
type in assignment (different address spaces) @@ expected void * @@ got
void [noderef] __iomem * @@
drivers/gpu/drm/i915/display/intel_fbdev.c:188:16: sparse: expected void
*
drivers/gpu/drm/i915/display/intel_fbdev.c:188:16: sparse: got void
[noderef] __iomem *
>> drivers/gpu/drm/i915/display/intel_fbdev.c:251:60: sparse: sparse: incorrect
>> type in argument 3 (different address spaces) @@ expected void **vaddr
>> @@ got void [noderef] __iomem ** @@
drivers/gpu/drm/i915/display/intel_fbdev.c:251:60: sparse: expected void
**vaddr
drivers/gpu/drm/i915/display/intel_fbdev.c:251:60: sparse: got void
[noderef] __iomem **
vim +251 drivers/gpu/drm/i915/display/intel_fbdev.c
173
174 static int intel_fbdev_pin_and_fence(struct drm_i915_private *dev_priv,
175 struct intel_fbdev *ifbdev,
176 void **vaddr)
177 {
178 const struct i915_ggtt_view view = {
179 .type = I915_GGTT_VIEW_NORMAL,
180 };
181 ifbdev->vma = intel_pin_and_fence_fb_obj(>fb->base,
false,
182 , false,
>vma_flags);
183
184 if (IS_ERR(ifbdev->vma)) {
185 return PTR_ERR(ifbdev->vma);
186 }
187
> 188 *vaddr = i915_vma_pin_iomap(ifbdev->vma);
189 if (IS_ERR(*vaddr)) {
190 drm_err(_priv->drm,
191 "Failed to remap framebuffer into virtual
memory\n");
192 return PTR_ERR(vaddr);
193 }
194 return 0;
195 }
196
197 static void intel_fbdev_unpin(struct intel_fbdev *ifbdev)
198 {
199 if (ifbdev->vma)
200 intel_unpin_fb_vma(ifbdev->vma, ifbdev->vma_flags);
201 }
202
203 static int intelfb_create(struct drm_fb_helper *helper,
204struct drm_fb_helper_surface_size *sizes)
205 {
206 struct intel_fbdev *ifbdev =
207 container_of(helper, struct intel_fbdev, helper);
208 struct intel_framebuffer *intel_fb = ifbdev->fb;
209 struct drm_device *dev = helper->dev;
210 struct drm_i915_private *dev_priv = to_i915(dev);
211 struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
212 struct i915_ggtt *ggtt = _priv->ggtt;
213 intel_wakeref_t wakeref;
214 struct fb_info *info;
215 bool prealloc = false;
216 void __iomem *vaddr;
217 struct drm_i915_gem_object *obj;
218 int ret;
219
220 if (intel_fb &&
221 (sizes->fb_width > intel_fb->base.width ||
222 sizes->fb_height > intel_fb->base.height)) {
223 drm_dbg_kms(_priv->drm,
224 "BIOS fb too small (%dx%d), we require
(%dx%d),"
225 " releasing it\n",
226 intel_fb->base.width, intel_fb->base.height,
227 sizes->fb_width, sizes->fb_height);
228 drm_framebuffer_put(_fb->base);
229 intel_fb = ifbdev->fb = NULL;
230 }
231 if (!intel_fb || drm_WARN_ON(dev,
!intel_fb_obj(_fb->base))) {
232 drm_dbg_kms(_priv->drm,
233 "no BIOS fb, allocating a new one\n");
234 ret = intelfb_alloc(helper, sizes);
235 if (ret)
236 return ret;
237 intel_fb = ifbdev->fb;
238 } else {
239 drm_dbg_kms(_priv->drm, "re
Re: [RFC PATCH 2/2] RDMA/efa: Add support for dmabuf memory regions
On 07/10/2021 14:40, Jason Gunthorpe wrote:
> On Thu, Oct 07, 2021 at 01:43:00PM +0300, Gal Pressman wrote:
>
>> @@ -1491,26 +1493,29 @@ static int efa_create_pbl(struct efa_dev *dev,
>> return 0;
>> }
>>
>> -struct ib_mr *efa_reg_mr(struct ib_pd *ibpd, u64 start, u64 length,
>> - u64 virt_addr, int access_flags,
>> - struct ib_udata *udata)
>> +static void efa_dmabuf_invalidate_cb(struct dma_buf_attachment *attach)
>> +{
>> +WARN_ON_ONCE(1,
>> + "Invalidate callback should not be called when memory is
>> pinned\n");
>> +}
>> +
>> +static struct dma_buf_attach_ops efa_dmabuf_attach_ops = {
>> +.allow_peer2peer = true,
>> +.move_notify = efa_dmabuf_invalidate_cb,
>> +};
>
> Shouldn't move_notify really just be left as NULL? I mean fixing
> whatever is preventing that?
That's what I had in the previous RFC and I think Christian didn't really like
it.
>> +struct ib_mr *efa_reg_user_mr_dmabuf(struct ib_pd *ibpd, u64 start,
>> + u64 length, u64 virt_addr,
>> + int fd, int access_flags,
>> + struct ib_udata *udata)
>> +{
>> +struct efa_dev *dev = to_edev(ibpd->device);
>> +struct ib_umem_dmabuf *umem_dmabuf;
>> +struct efa_mr *mr;
>> +int err;
>> +
>> +mr = efa_alloc_mr(ibpd, access_flags, udata);
>> +if (IS_ERR(mr)) {
>> +err = PTR_ERR(mr);
>> +goto err_out;
>> +}
>> +
>> +umem_dmabuf = ib_umem_dmabuf_get(ibpd->device, start, length, fd,
>> + access_flags, _dmabuf_attach_ops);
>> +if (IS_ERR(umem_dmabuf)) {
>> +ibdev_dbg(>ibdev, "Failed to get dmabuf[%d]\n", err);
>> +err = PTR_ERR(umem_dmabuf);
>> +goto err_free;
>> +}
>> +
>> +dma_resv_lock(umem_dmabuf->attach->dmabuf->resv, NULL);
>> +err = dma_buf_pin(umem_dmabuf->attach);
>> +if (err) {
>> +ibdev_dbg(>ibdev, "Failed to pin dmabuf memory\n");
>> +goto err_release;
>> +}
>> +
>> +err = ib_umem_dmabuf_map_pages(umem_dmabuf);
>> +if (err) {
>> +ibdev_dbg(>ibdev, "Failed to map dmabuf pages\n");
>> +goto err_unpin;
>> +}
>> +dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
>
> If it is really this simple the core code should have this logic,
> 'ib_umem_dmabuf_get_pinned()' or something
Should get_pinned do just get + dma_buf_pin, or should it do
ib_umem_dmabuf_map_pages as well?
Re: [RFC PATCH 1/2] dma-buf: Fix pin callback comment
On 07/10/2021 13:44, Christian König wrote:
> Am 07.10.21 um 12:42 schrieb Gal Pressman:
>> The pin callback does not necessarily have to move the memory to system
>> memory, remove the sentence from the comment.
>>
>> Signed-off-by: Gal Pressman
>> ---
>> include/linux/dma-buf.h | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
>> index efdc56b9d95f..93830731a9a3 100644
>> --- a/include/linux/dma-buf.h
>> +++ b/include/linux/dma-buf.h
>> @@ -86,9 +86,7 @@ struct dma_buf_ops {
>> * @pin:
>> *
>> * This is called by dma_buf_pin() and lets the exporter know that the
>> - * DMA-buf can't be moved any more. The exporter should pin the buffer
>> - * into system memory to make sure it is generally accessible by other
>> - * devices.
>
> Maybe change that to something like "Ideally the exporter should pin the
> buffer
> so that it is generally accessible by all devices".
Sure, thanks.
[PATCH 2/2] fbdev: fbmem: Fix double free of 'fb_info->pixmap.addr'
savagefb and some other drivers call kfree to free 'info->pixmap.addr'
even after calling unregister_framebuffer, which may cause double free.
Fix this by setting 'fb_info->pixmap.addr' to NULL after kfree in
unregister_framebuffer.
The following log reveals it:
[ 37.318872] BUG: KASAN: double-free or invalid-free in kfree+0x13e/0x290
[ 37.319369]
[ 37.320803] Call Trace:
[ 37.320992] dump_stack_lvl+0xa8/0xd1
[ 37.321274] print_address_description+0x87/0x3b0
[ 37.321632] ? kfree+0x13e/0x290
[ 37.321879] ? kfree+0x13e/0x290
[ 37.322126] ? kfree+0x13e/0x290
[ 37.322374] kasan_report_invalid_free+0x58/0x90
[ 37.322724] kasan_slab_free+0x123/0x140
[ 37.323049] __kasan_slab_free+0x11/0x20
[ 37.323347] slab_free_freelist_hook+0x81/0x150
[ 37.323689] ? savagefb_remove+0xa1/0xc0 [savagefb]
[ 37.324066] kfree+0x13e/0x290
[ 37.324304] savagefb_remove+0xa1/0xc0 [savagefb]
[ 37.324655] pci_device_remove+0xa9/0x250
[ 37.324959] ? pci_device_probe+0x7d0/0x7d0
[ 37.325273] device_release_driver_internal+0x4f7/0x7a0
[ 37.325666] driver_detach+0x1e8/0x2c0
[ 37.325952] bus_remove_driver+0x134/0x290
[ 37.326262] ? sysfs_remove_groups+0x97/0xb0
[ 37.326584] driver_unregister+0x77/0xa0
[ 37.326883] pci_unregister_driver+0x2c/0x1c0
[ 37.336124]
[ 37.336245] Allocated by task 5465:
[ 37.336507] kasan_kmalloc+0xb5/0xe0
[ 37.336801] __kasan_kmalloc+0x9/0x10
[ 37.337069] kmem_cache_alloc_trace+0x12b/0x220
[ 37.337405] register_framebuffer+0x3f3/0xa00
[ 37.337731] foo_register_framebuffer+0x3b/0x50 [savagefb]
[ 37.338136]
[ 37.338255] Freed by task 5475:
[ 37.338492] kasan_set_track+0x3d/0x70
[ 37.338774] kasan_set_free_info+0x23/0x40
[ 37.339081] kasan_slab_free+0x10b/0x140
[ 37.339399] __kasan_slab_free+0x11/0x20
[ 37.339694] slab_free_freelist_hook+0x81/0x150
[ 37.340034] kfree+0x13e/0x290
[ 37.340267] do_unregister_framebuffer+0x21c/0x3d0
[ 37.340624] unregister_framebuffer+0x23/0x40
[ 37.340950] savagefb_remove+0x45/0xc0 [savagefb]
[ 37.341302] pci_device_remove+0xa9/0x250
[ 37.341603] device_release_driver_internal+0x4f7/0x7a0
[ 37.341990] driver_detach+0x1e8/0x2c0
[ 37.342272] bus_remove_driver+0x134/0x290
[ 37.342577] driver_unregister+0x77/0xa0
[ 37.342873] pci_unregister_driver+0x2c/0x1c0
[ 37.343196] cleanup_module+0x15/0x1c [savagefb]
[ 37.343543] __se_sys_delete_module+0x398/0x490
[ 37.343881] __x64_sys_delete_module+0x56/0x60
[ 37.344221] do_syscall_64+0x4d/0xc0
[ 37.344492] entry_SYSCALL_64_after_hwframe+0x44/0xae
Signed-off-by: Zheyu Ma
---
drivers/video/fbdev/core/fbmem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 7420d2c16e47..b81b0e37daed 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1702,8 +1702,10 @@ static void do_unregister_framebuffer(struct fb_info
*fb_info)
{
unlink_framebuffer(fb_info);
if (fb_info->pixmap.addr &&
- (fb_info->pixmap.flags & FB_PIXMAP_DEFAULT))
+ (fb_info->pixmap.flags & FB_PIXMAP_DEFAULT)) {
kfree(fb_info->pixmap.addr);
+ fb_info->pixmap.addr = NULL;
+ }
fb_destroy_modelist(_info->modelist);
registered_fb[fb_info->node] = NULL;
num_registered_fb--;
--
2.17.6
