[Bug 107701] Asus X570ZD amdgpu display flicker at brightness level 1
https://bugs.freedesktop.org/show_bug.cgi?id=107701 --- Comment #1 from Daniel Drake --- Created attachment 141305 --> https://bugs.freedesktop.org/attachment.cgi?id=141305=edit Asus X570ZD dmesg with debug params Typo above - product name is Asus X570ZD. Here is the dmesg log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106639] System display has noise when amdgpu module is being loaded
https://bugs.freedesktop.org/show_bug.cgi?id=106639 --- Comment #8 from Daniel Drake --- Created attachment 141304 --> https://bugs.freedesktop.org/attachment.cgi?id=141304=edit Asus X570ZD dmesg with debug params -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107701] Asus X570ZD amdgpu display flicker at brightness level 1
https://bugs.freedesktop.org/show_bug.cgi?id=107701 Bug ID: 107701 Summary: Asus X570ZD amdgpu display flicker at brightness level 1 Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: d...@reactivated.net On the Asus X570VD laptop with AMD Ryzen 7 with Radeon Vega Mobile Gfx, if you use the brightness keys to reduce the screen brightness to the minimum level under GNOME, the display flickers disturbingly. This is reproducible under Ubuntu 18.04 with all updates applied (Linux 4.15). It's also reproducible with AMDGPU-PRO All-Open drivers installed on top. It's also reproducible under Linux 4.18.5. It's hard to capture on camera, but you can get some appreciation of the issue in this video: https://youtu.be/tCoA45TJlAk When the screen is in this state, the /sys/class/backlight/brightness file has value 1. If I manually adjust to value 2, the flicker goes away. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106639] System display has noise when amdgpu module is being loaded
https://bugs.freedesktop.org/show_bug.cgi?id=106639 --- Comment #7 from Daniel Drake --- Sorry for the typo above - the product is Asus X570ZD -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106639] System display has noise when amdgpu module is being loaded
https://bugs.freedesktop.org/show_bug.cgi?id=106639 --- Comment #6 from Daniel Drake --- This issue can be reproduced on Linux 4.18.5 on Asus X570VD (AMD Ryzen 7 with Radeon Vega Mobile Gfx) which includes the above patch. It can also be reproduced on the latest 4.15 kernel in Ubuntu 18.04. In both cases the glitch is quite jarring, lots of white flashing up in the middle of the screen. During ubuntu boot: https://youtu.be/cOYumE38Xac During manual modprobe: https://youtu.be/I1a6C4mF6pA I installed AMDGPU-PRO 18.20 All-Open version and the problem remains. Please let me know how we can assist with next steps. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107623] (4.18.3)[drm:hwss_edp_wait_for_hpd_ready [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_ready: wait timed out!
https://bugs.freedesktop.org/show_bug.cgi?id=107623 Daniel Drake changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Daniel Drake --- This issue was detected on 4.18.3 when using a somewhat reduced developer config. When using our usual full distro kernel config (from Ubuntu), the issue convincingly goes away. Both Jian-Hong and I looked at the differences in the config and couldn't spot anything obvious that would explain different behaviour. Trying to bisect good and bad configs, for a while it looked like it might be CONFIG_NUMA_BALANCING=y and CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y but we then disproved that in further experiments. We didn't find which config option is responsible for the different behaviour. There's probably a bug here somewhere, but as it's working on our shipped config I'll close this issue, as we need to focus our time on other issues on this platform. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107635] Internal display always be blank in mirror, extended and built-in only display mode
https://bugs.freedesktop.org/show_bug.cgi?id=107635 Daniel Drake changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Daniel Drake --- This issue was detected on 4.18.3 when using a somewhat reduced developer config. When using our usual full distro kernel config (from Ubuntu), the issue convincingly goes away. Both Jian-Hong and I looked at the differences in the config and couldn't spot anything obvious that would explain different behaviour. There's probably a bug here somewhere, but as it's working on our shipped config I'll close this issue, as we need to focus our time on other issues on this platform. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] backlight: pm8941: Convert to using %pOFn instead of device_node.name
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Bartlomiej Zolnierkiewicz
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Rob Herring
---
drivers/video/backlight/pm8941-wled.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pm8941-wled.c
b/drivers/video/backlight/pm8941-wled.c
index 0b6d21955d91..da6aab20fdcb 100644
--- a/drivers/video/backlight/pm8941-wled.c
+++ b/drivers/video/backlight/pm8941-wled.c
@@ -330,7 +330,7 @@ static int pm8941_wled_configure(struct pm8941_wled *wled,
struct device *dev)
rc = of_property_read_string(dev->of_node, "label", >name);
if (rc)
- wled->name = dev->of_node->name;
+ wled->name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn",
dev->of_node);
*cfg = pm8941_wled_config_defaults;
for (i = 0; i < ARRAY_SIZE(u32_opts); ++i) {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbdev: Convert to using %pOFn instead of device_node.name
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Cc: Bartlomiej Zolnierkiewicz
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Rob Herring
---
drivers/video/fbdev/cg14.c| 4 +---
drivers/video/fbdev/cg3.c | 2 +-
drivers/video/fbdev/core/fbmon.c | 4 ++--
drivers/video/fbdev/imsttfb.c | 2 +-
drivers/video/fbdev/leo.c | 2 +-
drivers/video/fbdev/offb.c| 12
drivers/video/fbdev/p9100.c | 2 +-
drivers/video/of_display_timing.c | 2 +-
8 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/cg14.c b/drivers/video/fbdev/cg14.c
index 8de88b129b62..9af54c2368fd 100644
--- a/drivers/video/fbdev/cg14.c
+++ b/drivers/video/fbdev/cg14.c
@@ -355,9 +355,7 @@ static int cg14_ioctl(struct fb_info *info, unsigned int
cmd, unsigned long arg)
static void cg14_init_fix(struct fb_info *info, int linebytes,
struct device_node *dp)
{
- const char *name = dp->name;
-
- strlcpy(info->fix.id, name, sizeof(info->fix.id));
+ snprintf(info->fix.id, sizeof(info->fix.id), "%pOFn", dp);
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
diff --git a/drivers/video/fbdev/cg3.c b/drivers/video/fbdev/cg3.c
index 6c334260cf53..1bd95b02f3aa 100644
--- a/drivers/video/fbdev/cg3.c
+++ b/drivers/video/fbdev/cg3.c
@@ -246,7 +246,7 @@ static int cg3_ioctl(struct fb_info *info, unsigned int
cmd, unsigned long arg)
static void cg3_init_fix(struct fb_info *info, int linebytes,
struct device_node *dp)
{
- strlcpy(info->fix.id, dp->name, sizeof(info->fix.id));
+ snprintf(info->fix.id, sizeof(info->fix.id), "%pOFn", dp);
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 852d86c1c527..dd3128990776 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -1480,8 +1480,8 @@ int of_get_fb_videomode(struct device_node *np, struct
fb_videomode *fb,
if (ret)
return ret;
- pr_debug("%pOF: got %dx%d display mode from %s\n",
- np, vm.hactive, vm.vactive, np->name);
+ pr_debug("%pOF: got %dx%d display mode\n",
+ np, vm.hactive, vm.vactive);
dump_fb_videomode(fb);
return 0;
diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c
index ecdcf358ad5e..901ca4ed10e9 100644
--- a/drivers/video/fbdev/imsttfb.c
+++ b/drivers/video/fbdev/imsttfb.c
@@ -1473,7 +1473,7 @@ static int imsttfb_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
dp = pci_device_to_OF_node(pdev);
if(dp)
- printk(KERN_INFO "%s: OF name %s\n",__func__, dp->name);
+ printk(KERN_INFO "%s: OF name %pOFn\n",__func__, dp);
else if (IS_ENABLED(CONFIG_OF))
printk(KERN_ERR "imsttfb: no OF node for pci device\n");
diff --git a/drivers/video/fbdev/leo.c b/drivers/video/fbdev/leo.c
index 71862188f528..446ac3364bad 100644
--- a/drivers/video/fbdev/leo.c
+++ b/drivers/video/fbdev/leo.c
@@ -434,7 +434,7 @@ static int leo_ioctl(struct fb_info *info, unsigned int
cmd, unsigned long arg)
static void
leo_init_fix(struct fb_info *info, struct device_node *dp)
{
- strlcpy(info->fix.id, dp->name, sizeof(info->fix.id));
+ snprintf(info->fix.id, sizeof(info->fix.id), "%pOFn", dp);
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = FB_VISUAL_TRUECOLOR;
diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index 77c0a2f45b3b..31f769d67195 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -419,9 +419,13 @@ static void __init offb_init_fb(const char *name,
var = >var;
info->par = par;
- strcpy(fix->id, "OFfb ");
- strncat(fix->id, name, sizeof(fix->id) - sizeof("OFfb "));
- fix->id[sizeof(fix->id) - 1] = '\0';
+ if (name) {
+ strcpy(fix->id, "OFfb ");
+ strncat(fix->id, name, sizeof(fix->id) - sizeof("OFfb "));
+ fix->id[sizeof(fix->id) - 1] = '\0';
+ } else
+ snprintf(fix->id, sizeof(fix->id), "OFfb %pOFn", dp);
+
var->xres = var->xres_virtual = width;
var->yres = var->yres_virtual = height;
@@ -644,7 +648,7 @@ static void __init offb_init_nodriver(struct device_node
*dp, int no_real_node)
/* kludge for valkyrie */
if (strcmp(dp->name, "valkyrie") == 0)
address += 0x1000;
- offb_init_fb(no_real_node ? "bootx" : dp->name,
+ offb_init_fb(no_real_node ? "bootx" : NULL,
width, height, depth, pitch, address,
[PATCH] drm: Convert to using %pOFn instead of device_node.name
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Cc: Gustavo Padovan
Cc: Maarten Lankhorst
Cc: Sean Paul
Cc: David Airlie
Cc: Rob Clark
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Rob Herring
---
drivers/gpu/drm/drm_modes.c | 4 ++--
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 02db9ac82d7a..24a750436559 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -716,8 +716,8 @@ int of_get_drm_display_mode(struct device_node *np,
if (bus_flags)
drm_bus_flags_from_videomode(, bus_flags);
- pr_debug("%pOF: got %dx%d display mode from %s\n",
- np, vm.hactive, vm.vactive, np->name);
+ pr_debug("%pOF: got %dx%d display mode\n",
+ np, vm.hactive, vm.vactive);
drm_mode_debug_printmodeline(dmode);
return 0;
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index c79659ca5706..23670907a29d 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -579,7 +579,7 @@ static int msm_hdmi_bind(struct device *dev, struct device
*master, void *data)
hdmi_cfg = (struct hdmi_platform_config *)
of_device_get_match_data(dev);
if (!hdmi_cfg) {
- dev_err(dev, "unknown hdmi_cfg: %s\n", of_node->name);
+ dev_err(dev, "unknown hdmi_cfg: %pOFn\n", of_node);
return -ENXIO;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/9] drm/msm/a6xx: Add support for an interconnect path
Hi Jordan, Thank you for the patch! Yet something to improve: [auto build test ERROR on robclark/msm-next] [also build test ERROR on v4.19-rc1 next-20180827] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jordan-Crouse/Add-interconnect-support-bindings-for-A630-GPU/20180828-004407 base: git://people.freedesktop.org/~robclark/linux msm-next config: arm-defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm All errors (new ones prefixed by >>): In file included from drivers/gpu/drm/msm/adreno/adreno_gpu.h:25:0, from drivers/gpu/drm/msm/adreno/adreno_device.c:20: >> drivers/gpu/drm/msm/msm_gpu.h:23:10: fatal error: linux/interconnect.h: No >> such file or directory #include ^~ compilation terminated. -- >> drivers/gpu/drm/msm/adreno/adreno_gpu.c:24:10: fatal error: >> linux/interconnect.h: No such file or directory #include ^~ compilation terminated. -- >> drivers/gpu/drm/msm/adreno/a6xx_gmu.c:7:10: fatal error: >> linux/interconnect.h: No such file or directory #include ^~ compilation terminated. vim +23 drivers/gpu/drm/msm/msm_gpu.h 20 21 #include 22 #include > 23 #include 24 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/4] intel: add IS_GENX() generic macro
On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-08-25 00:56:46)
> > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > index 4a34b7be..8a0e3e76 100644
> > --- a/intel/intel_chipset.h
> > +++ b/intel/intel_chipset.h
> > @@ -568,6 +568,26 @@
> >
> > #define IS_GEN11(devid)(IS_ICELAKE_11(devid))
> >
> > +/* New platforms use kernel pci ids */
> > +#include "i915_pciids.h"
> > +
> > +struct pci_device_id {
>
> Don't call it pci_device_id, depending on caller that name may already
> be taken by libpciaccess.
>
> > + uint32_t unused0, device;
> > + uint32_t unused1, unused2;
> > + uint32_t unused3, unused4;
> These are all uint16_t.
more on this:
I can make the first 2 uint16_t, but not the rest due to the way they
are declared in INTEL_VGA_DEVICE: (~0 has int type by default), unused3
and unused4 are clearly not uint16_t
>
> > + unsigned long unused5;
>
> Simply make the unused disappear from the macro.
that would mean defining macro hackery to get hid of them from
INTEL_VGA_DEVICE() by using macro recursion, but not worth IMO. If we
want to go this route, then I think we should at least use X Macro
to define the ids rather than the list we currently have. Something
along the lines (in i915_pciids.h):
#define _INTEL_ICL_IDS \
X(0x8A50) \
X(0x8A51) \
X(0x8A5C) \
X(0x8A5D) \
X(0x8A52) \
X(0x8A5A) \
X(0x8A5B) \
X(0x8A71) \
X(0x8A70)
...
#define X(id, info) INTEL_VGA_DEVICE(id, info),
#define INTEL_ICL_IDS(info) _INTEL_ICL_IDS
#undef X
Then here we would just define another X to transform the list into an
array:
#include "i915_pciids.h"
...
#define X(id, gen) { id, gen }
struct pci_device {
uint16_t id;
uint16_t gen;
} devices = {
_INTEL_ICL_IDS
}
We would be screwed if X is defined to something else, but we could change
the name.
Lucas De Marchi
>
> > +};
> > +
> > +#define IS_GENX(x, devid) ({ \
> > + struct pci_device_id __ids[] = { INTEL_ ## x ## _IDS(0) }; \
>
> While that's a neat trick it's instantiating the array for each caller,
> and it does appear that we repeat a few of the macros.
>
> The best I can offer to keep the change non-invasive (other than just
> switching to a platform bitmask and filling (devid, gen, platform) from
> the pci match data on initialisation) is a two pass approach.
>
> static inline int __find_in_pciid(uint16_t devid,
> const struct pci_device_id *ids, size_t count)
> {
> size_t i = 0; /* we should rethink this if we think there are more than
> 4B of them! */
> for (i = 0; i < count; i++) {
> if (ids[i].device == devid)
> return 1;
> }
> return 0;
> }
>
>
> #define __is_genx(x) \
> static inline int __is_gen##x(uint16_t devid) \
> { \
> static const struct pci_device_id __ids[] = { INTEL_ ## x ## _IDS(0) };
> \
> return __find_in_pciid(devid, __ids, sizeof(__ids)/sizeof(__ids[0]); \
> }
> __is_genx(3);
> __is_genx(4);
> __is_genx(5);
> __is_genx(6);
> __is_genx(7);
> __is_genx(8);
> __is_genx(9);
> __is_genx(10);
> __is_genx(11);
>
> #define IS_GENX(x, devid) __is_gen##x(devid)
>
> That should help cut down the object size expansion. But longer term I'd
> prefer if we moved to towards finding the match data once. Also we need
> to pull into the canonical header the friendly names for mesa.
> -Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99857] Radeon R7 M260/M265 *ERROR* amdgpu asic reset failed - Suspending notebook freezes it
https://bugs.freedesktop.org/show_bug.cgi?id=99857 --- Comment #4 from copperly --- I have a Lenovo Ideapad 320-15abr with an AMD Radeon R7 M265 2 GB and whenever I suspend in kubuntu 18.04 (what I had before) and more recently linux mint cinnamon 19 it will freeze and display a very garbled screen. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/dp_mst: Pass entire connector to drm_dp_mst_topology_mgr_init()
There's no actual reason we pass the connector ID instead of a pointer
to the connector itself, and we're going to need the entire connector
(but only temporarily) in order to name MST debugfs folders properly
since connector IDs can't be looked up until the driver has been
registered with userspace which happens after debugfs init.
So, just pass the entire drm_connector struct instead of just it's id.
Signed-off-by: Lyude Paul
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_dp_mst.c | 6 --
drivers/gpu/drm/i915/intel_drv.h | 3 ++-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 +++---
drivers/gpu/drm/radeon/radeon_dp_mst.c| 2 +-
include/drm/drm_dp_mst_helper.h | 3 ++-
8 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9a300732ba37..60da7e8fcca7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -503,6 +503,6 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
>dm_dp_aux.aux,
16,
4,
- aconnector->connector_id);
+ >base);
}
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7780567aa669..edba17073c7a 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3166,9 +3166,11 @@ EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
* Return 0 for success, or negative error code on failure
*/
int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr,
-struct drm_device *dev, struct drm_dp_aux *aux,
+struct drm_device *dev,
+struct drm_dp_aux *aux,
int max_dpcd_transaction_bytes,
-int max_payloads, int conn_base_id)
+int max_payloads,
+struct drm_connector *connector)
{
struct drm_dp_mst_topology_state *mst_state;
@@ -3186,7 +3188,7 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
mgr->aux = aux;
mgr->max_dpcd_transaction_bytes = max_dpcd_transaction_bytes;
mgr->max_payloads = max_payloads;
- mgr->conn_base_id = conn_base_id;
+ mgr->conn_base_id = connector->base.id;
if (max_payloads + 1 > sizeof(mgr->payload_mask) * 8 ||
max_payloads + 1 > sizeof(mgr->vcpi_mask) * 8)
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cd0f649b57a5..3688df38dbe7 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -6247,7 +6247,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
(port == PORT_B || port == PORT_C ||
port == PORT_D || port == PORT_F))
intel_dp_mst_encoder_init(intel_dig_port,
- intel_connector->base.base.id);
+ _connector->base);
if (!intel_edp_init_connector(intel_dp, intel_connector)) {
intel_dp_aux_fini(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 7e3e01607643..6c07c29235df 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -583,7 +583,8 @@ intel_dp_create_fake_mst_encoders(struct intel_digital_port
*intel_dig_port)
}
int
-intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_base_id)
+intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port,
+ struct drm_connector *connector)
{
struct intel_dp *intel_dp = _dig_port->dp;
struct drm_device *dev = intel_dig_port->base.base.dev;
@@ -595,7 +596,8 @@ intel_dp_mst_encoder_init(struct intel_digital_port
*intel_dig_port, int conn_ba
/* create encoders */
intel_dp_create_fake_mst_encoders(intel_dig_port);
ret = drm_dp_mst_topology_mgr_init(_dp->mst_mgr, dev,
- _dp->aux, 16, 3, conn_base_id);
+ _dp->aux, 16, 3,
+ connector);
if (ret) {
intel_dp->can_mst = false;
return ret;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8fc61e96754f..af7a6111ff74 100644
---
[PATCH 3/4] drm/dp_mst: Add dp_mst_status debugfs node for all drivers
Originally I was just going to be adding dp_mst_status for nouveau until
Daniel Stone pointed out that we should probably just make this so it's
magically added for every DRM driver that's using the DRM DP MST
helpers. So, let's do that!
Signed-off-by: Lyude Paul
Cc: Maarten Lankhorst
Cc: Daniel Stone
---
drivers/gpu/drm/drm_dp_mst_topology.c | 106 ++
include/drm/drm_dp_mst_helper.h | 14
2 files changed, 120 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index edba17073c7a..c12c2bfc3411 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
@@ -3154,6 +3155,104 @@ struct drm_dp_mst_topology_state
*drm_atomic_get_mst_topology_state(struct drm_a
}
EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
+#ifdef CONFIG_DEBUG_FS
+static int drm_dp_mst_debugfs_state_show(struct seq_file *m, void *data)
+{
+ drm_dp_mst_dump_topology(m, m->private);
+ return 0;
+}
+
+static int drm_dp_mst_debugfs_state_open(struct inode *inode,
+struct file *file)
+{
+ struct drm_dp_mst_topology_mgr *mgr = inode->i_private;
+
+ return single_open(file, drm_dp_mst_debugfs_state_show, mgr);
+}
+
+static const struct file_operations drm_dp_mst_debugfs_state_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_dp_mst_debugfs_state_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+struct drm_dp_mst_debugfs_init_data {
+ struct drm_dp_mst_topology_mgr *mgr;
+ char *connector_name;
+};
+
+static void
+drm_dp_mst_debugfs_init(void *data)
+{
+ struct drm_dp_mst_debugfs_init_data *init_data = data;
+ struct drm_dp_mst_topology_mgr *mgr = init_data->mgr;
+ struct drm_minor *minor = mgr->dev->primary;
+ struct dentry *root;
+ bool put_ref = false;
+
+ /* Create the dp_mst directory for this device if it doesn't exist
+* already
+*/
+ root = debugfs_lookup("dp_mst", minor->debugfs_root);
+ if (root) {
+ put_ref = true;
+ } else {
+ root = debugfs_create_dir("dp_mst", minor->debugfs_root);
+ if (!root || IS_ERR(root))
+ return;
+ }
+
+ mgr->debugfs = debugfs_create_dir(init_data->connector_name, root);
+ if (!mgr->debugfs)
+ goto out_dput;
+
+ debugfs_create_file("state", 0444, mgr->debugfs, mgr,
+ _dp_mst_debugfs_state_fops);
+
+out_dput:
+ if (put_ref)
+ dput(root);
+}
+
+static void
+drm_dp_mst_debugfs_cleanup_cb(void *data)
+{
+ struct drm_dp_mst_debugfs_init_data *init_data = data;
+
+ init_data->mgr->debugfs_init_cb = NULL;
+ kfree(init_data->connector_name);
+ kfree(init_data);
+}
+
+static void
+drm_dp_mst_debugfs_register(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_connector *connector)
+{
+ struct drm_dp_mst_debugfs_init_data *init_data;
+
+ if (!connector)
+ return;
+
+ init_data = kmalloc(sizeof(*init_data), GFP_KERNEL);
+ if (!init_data)
+ return;
+
+ init_data->mgr = mgr;
+ init_data->connector_name = kstrdup(connector->name, GFP_KERNEL);
+ if (!init_data->connector_name) {
+ kfree(init_data);
+ return;
+ }
+
+ drm_debugfs_register_callback(mgr->dev->primary,
+ drm_dp_mst_debugfs_init,
+ drm_dp_mst_debugfs_cleanup_cb,
+ init_data, >debugfs_init_cb);
+}
+#endif
+
/**
* drm_dp_mst_topology_mgr_init - initialise a topology manager
* @mgr: manager struct to initialise
@@ -3214,6 +3313,9 @@ int drm_dp_mst_topology_mgr_init(struct
drm_dp_mst_topology_mgr *mgr,
drm_atomic_private_obj_init(>base,
_state->base,
_state_funcs);
+#ifdef CONFIG_DEBUG_FS
+ drm_dp_mst_debugfs_register(mgr, connector);
+#endif
return 0;
}
@@ -3225,6 +3327,10 @@ EXPORT_SYMBOL(drm_dp_mst_topology_mgr_init);
*/
void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr)
{
+#ifdef CONFIG_DEBUG_FS
+ drm_debugfs_unregister_callback(mgr->dev->primary,
+ mgr->debugfs_init_cb);
+#endif
flush_work(>work);
flush_work(>destroy_connector_work);
mutex_lock(>payload_lock);
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index ef8ba093ae8a..c70b81cd78b1 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
struct drm_dp_mst_branch;
[PATCH 4/4] drm/i915: Remove i915_drm_dp_mst_status
Now that DRM can create these debugfs nodes automatically; this isn't
needed.
Signed-off-by: Lyude Paul
Cc: Maarten Lankhorst
Cc: Daniel Stone
---
drivers/gpu/drm/i915/i915_debugfs.c | 32 -
1 file changed, 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f9ce35da4123..5014828ca022 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3534,37 +3534,6 @@ static int i915_drrs_status(struct seq_file *m, void
*unused)
return 0;
}
-static int i915_dp_mst_info(struct seq_file *m, void *unused)
-{
- struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct drm_device *dev = _priv->drm;
- struct intel_encoder *intel_encoder;
- struct intel_digital_port *intel_dig_port;
- struct drm_connector *connector;
- struct drm_connector_list_iter conn_iter;
-
- drm_connector_list_iter_begin(dev, _iter);
- drm_for_each_connector_iter(connector, _iter) {
- if (connector->connector_type != DRM_MODE_CONNECTOR_DisplayPort)
- continue;
-
- intel_encoder = intel_attached_encoder(connector);
- if (!intel_encoder || intel_encoder->type ==
INTEL_OUTPUT_DP_MST)
- continue;
-
- intel_dig_port = enc_to_dig_port(_encoder->base);
- if (!intel_dig_port->dp.can_mst)
- continue;
-
- seq_printf(m, "MST Source Port %c\n",
- port_name(intel_dig_port->base.port));
- drm_dp_mst_dump_topology(m, _dig_port->dp.mst_mgr);
- }
- drm_connector_list_iter_end(_iter);
-
- return 0;
-}
-
static ssize_t i915_displayport_test_active_write(struct file *file,
const char __user *ubuf,
size_t len, loff_t *offp)
@@ -4733,7 +4702,6 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_rcs_topology", i915_rcs_topology, 0},
{"i915_shrinker_info", i915_shrinker_info, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
- {"i915_dp_mst_info", i915_dp_mst_info, 0},
{"i915_wa_registers", i915_wa_registers, 0},
{"i915_ddb_info", i915_ddb_info, 0},
{"i915_sseu_status", i915_sseu_status, 0},
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/debugfs: Add support for dynamic debugfs initialization
Currently all debugfs related initialization for the DRM core happens in
drm_debugfs_init(), which is called when registering the minor device.
While this works fine for features such as atomic modesetting and GEM,
this doesn't work at all for resources like DP MST topology managers
which can potentially be created both before and after the minor
device has been registered.
So, in order to add driver-wide debugfs files for MST we'll need to be
able to handle debugfs initialization for such resources. We do so by
introducing drm_debugfs_callback_register() and
drm_debugfs_callback_unregister(). These functions allow driver-agnostic
parts of DRM to add additional debugfs initialization callbacks at any
point during a DRM driver's lifetime.
Signed-off-by: Lyude Paul
Cc: Maarten Lankhorst
Cc: Daniel Stone
---
drivers/gpu/drm/drm_debugfs.c | 173 +++--
drivers/gpu/drm/drm_drv.c | 3 +
drivers/gpu/drm/drm_internal.h | 5 +
include/drm/drm_debugfs.h | 27 +
include/drm/drm_file.h | 4 +
5 files changed, 203 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 6f28fe58f169..a53a454b167f 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -39,6 +39,13 @@
#if defined(CONFIG_DEBUG_FS)
+struct drm_debugfs_callback {
+ void (*init)(void *data);
+ void (*cleanup_cb)(void *data);
+ void *data;
+ struct list_head list;
+};
+
/***
* Initialization, etc.
**/
@@ -67,6 +74,113 @@ static const struct file_operations drm_debugfs_fops = {
.release = single_release,
};
+/**
+ * drm_debugfs_register_callback - Register a callback for initializing
+ * dynamic driver-agnostic debugfs files
+ * @minor: device minor number
+ * @init: The callback to invoke to perform the debugfs initialization
+ * @cleanup_cb: The callback to invoke to cleanup any resources for the
+ * callback
+ * @data: Data to pass to @init and @cleanup_cb
+ * @out: Where to store the pointer to the callback struct
+ *
+ * Register an initialization callback with debugfs. This callback can be used
+ * to creating debugfs nodes for DRM resources that might get created before
+ * the debugfs node for @minor has been created.
+ *
+ * When a callback is registered with this function before the debugfs root
+ * has been created, the callback's execution will be delayed until all other
+ * debugfs nodes (including those owned by the DRM device's driver) have been
+ * instantiated. If a callback is registered with this function after the
+ * debugfs root has been created, @init and @cleanup_cb will be executed
+ * immediately without creating a drm_debugfs_callback.
+ *
+ * In the event that debugfs creation for the device fails; all registered
+ * debugfs callbacks will have their @cleanup_cb callbacks invoked without
+ * having their @init callbacks invoked. This is to ensure that no resources
+ * are leaked during initialization of debugfs, even if the initialization
+ * process fails. Likewise; any callbacks that are registered after DRM has
+ * failed to initialize it's debugfs files will have their @cleanup_cb
+ * callbacks invoked immediately and all of their respective resources
+ * destroyed.
+ *
+ * Implementations of @cleanup_cb should clean up all resources for the
+ * callback, with the exception of freeing the memory for @out. Freeing @out
+ * will be handled by the DRM core automatically.
+ *
+ * Users of this function should take care to add a symmetric call to
+ * @drm_debugfs_unregister_callback to handle destroying a registered callback
+ * in case the resources for the user of this function are destroyed before
+ * debugfs root is initialized.
+ *
+ */
+int
+drm_debugfs_register_callback(struct drm_minor *minor,
+ void (*init)(void *),
+ void (*cleanup_cb)(void *),
+ void *data, struct drm_debugfs_callback **out)
+{
+ int ret = 0;
+
+ mutex_lock(>debugfs_callback_lock);
+ if (minor->debugfs_callbacks_done) {
+ /* debugfs is already setup, so just handle the callback
+* immediately
+*/
+ if (minor->debugfs_root)
+ (*init)(data);
+ (*cleanup_cb)(data);
+ goto out_unlock;
+ }
+
+ *out = kzalloc(sizeof(**out), GFP_KERNEL);
+ if (!*out) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
+
+ (*out)->init = init;
+ (*out)->cleanup_cb = cleanup_cb;
+ (*out)->data = data;
+ list_add(&(*out)->list, >debugfs_callback_list);
+
+out_unlock:
+ mutex_unlock(>debugfs_callback_lock);
+ return ret;
+}
+EXPORT_SYMBOL(drm_debugfs_register_callback);
+
+/**
+ *
[PATCH 0/4] drm/dp_mst: Add DP MST debugfs nodes for all drivers
This is the next version of my patch series for teaching DRM how to automatically create debugfs nodes for drivers with MST topologies. This was originally intended just for nouveau, but has since been expanded to all DRM drivers. Cc: Maarten Lankhorst Cc: Daniel Stone Lyude Paul (4): drm/debugfs: Add support for dynamic debugfs initialization drm/dp_mst: Pass entire connector to drm_dp_mst_topology_mgr_init() drm/dp_mst: Add dp_mst_status debugfs node for all drivers drm/i915: Remove i915_drm_dp_mst_status .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- drivers/gpu/drm/drm_debugfs.c | 173 +- drivers/gpu/drm/drm_dp_mst_topology.c | 114 +++- drivers/gpu/drm/drm_drv.c | 3 + drivers/gpu/drm/drm_internal.h| 5 + drivers/gpu/drm/i915/i915_debugfs.c | 32 drivers/gpu/drm/i915/intel_dp.c | 2 +- drivers/gpu/drm/i915/intel_dp_mst.c | 6 +- drivers/gpu/drm/i915/intel_drv.h | 3 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 +- drivers/gpu/drm/radeon/radeon_dp_mst.c| 2 +- include/drm/drm_debugfs.h | 27 +++ include/drm/drm_dp_mst_helper.h | 17 +- include/drm/drm_file.h| 4 + 14 files changed, 342 insertions(+), 54 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 --- Comment #5 from Jon (jon...@gmail.com) --- Is there any other information I can provide to help diagnose? I'm not even sure if I have this bug filed in the right place. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/4] intel: add IS_GENX() generic macro
On Mon, Aug 27, 2018 at 10:40:28PM +0100, Chris Wilson wrote: > Quoting Lucas De Marchi (2018-08-27 22:19:54) > > On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote: > > > Quoting Lucas De Marchi (2018-08-25 00:56:46) > > > That should help cut down the object size expansion. But longer term I'd > > > > I'm not opposed to turning it into inline function, but if the goal is > > to reduce the object size expansion, just making the array static const > > should suffice... we do call the macros several times, but most of the > > size is for constructing the array, not to find the elements. > > It'll construct the array on the stack, painfully. I thought you were > trying for a minimal change :) the way I meant it it won't construct in the stack. > > > > prefer if we moved to towards finding the match data once. Also we need > > > to pull into the canonical header the friendly names for mesa. > > > > what do you mean by "friendly names for mesa". > > > > The other option that is actually my preferred is to let the kernel tell > > user space what it is. What do you think about having an ioctl that returns > > what is the gen + additional interesting info? Then user space could > > base its decisions on features and fallback to gen version when there > > isn't a way to discover if a feature/bug is present. This would allow > > to simply remove the pci ids from user space projects which IMO would be > > a good thing. > > There simply wasn't enough interest. The key point is selling it to > mesa, see include/pci_ids/i965_pci_ids.h > > The challenge with the centralised db of interesting info is that it > will always be out of date for userspace (think userspace having to cope > with a 5 year kernel, and a kernel having to cope with 10 year old > userspace) and never enough so they still have to supplement it without > their own db. > > That isn't to say that there isn't a lot of interesting hw properties > that userspace needs to know, but they are also tend to be the ones tied > to fuses and not pciid. > > What we do all duplicate are the pci-ids, so pulling those into a > central header containing the commonly used per-id information in a format > that can be embedded into any of the caller's structs is challenge > enough. I think kernel, igt and libdrm would be happy with either runtime or a common header. Checking now what mesa does, giving a friendly name and assigning the properties for each and every device is out of reach, at least for now. So fair enough regarding the runtime option. However I don't think that means we shouldn't try improve libdrm/igt just because it won't solve it for mesa (at least with the "common header approach"). I'll try to spin a new version to handle your comment. Lucas De Marchi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #36 from CheatCodesOfLife --- Created attachment 141303 --> https://bugs.freedesktop.org/attachment.cgi?id=141303=edit ddebug_dumps/Cemu.exe_2244_ dmesg_dump event_dump umr_dump Hi, This time I double-checked the tar archive, the trace, dmesg umr and ddebug file are there. It's just 1 ddebug file this time as you said, but it's only 368kb. Command I used was: GALLIUM_HUD="fps" GALLIUM_DDEBUG=1000 wine64 Cemu.exe -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #33 from Allan --- (In reply to Jan Jurzitza from comment #31) > I have found a workaround (amd patched kernel not required): > > cat /sys/class/drm/card0/device/pp_dpm_sclk > # insert appropriate index here, I went for 1077Mhz > echo 3 > /sys/class/drm/card0/device/pp_dpm_sclk > > Makes the GPU a bit slower (changes clock to 1077 Mhz on my card) for the > session, but at least applications don't freeze the system anymore now (or > at least this is delaying it so much that it works for multiple hours, but > it didn't freeze for me yet) > > Though because of the slowdown I don't think this is a good solution > long-term. Maybe a hint towards a solution though maybe? What I noticed in > radeon-profile is that on auto it is capable of running at the boost > frequency (1266 Mhz) and not limited to the base frequency the product page > specifies (1120 Mhz) by default, so I changed it here and it basically fixed > it. > > Fixes the issue on kernel 4.18.4 Even that I didn't mention, I tried it. It worked for me for a while, and most part while I wasn't properly running 3D rendering, but OpenCL codes instead. But it never worked as a workaround cause it just randomized the time to happen the errors. And this is exactly why I didn't mention it before. Indeed, I need to test it on kernel 4.18 yet. ### In time : seems like that the warranty of my motherboard will take a long time to finish. I borrowed an old PC from my aunt and I hope that it will be enough to compile the kernel and test the GPU. It is going to be fun to compile a kernel on a 1.6GHz dual core (1C/2T). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/4] intel: add IS_GENX() generic macro
Quoting Lucas De Marchi (2018-08-27 22:19:54) > On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote: > > Quoting Lucas De Marchi (2018-08-25 00:56:46) > > That should help cut down the object size expansion. But longer term I'd > > I'm not opposed to turning it into inline function, but if the goal is > to reduce the object size expansion, just making the array static const > should suffice... we do call the macros several times, but most of the > size is for constructing the array, not to find the elements. It'll construct the array on the stack, painfully. I thought you were trying for a minimal change :) > > prefer if we moved to towards finding the match data once. Also we need > > to pull into the canonical header the friendly names for mesa. > > what do you mean by "friendly names for mesa". > > The other option that is actually my preferred is to let the kernel tell > user space what it is. What do you think about having an ioctl that returns > what is the gen + additional interesting info? Then user space could > base its decisions on features and fallback to gen version when there > isn't a way to discover if a feature/bug is present. This would allow > to simply remove the pci ids from user space projects which IMO would be > a good thing. There simply wasn't enough interest. The key point is selling it to mesa, see include/pci_ids/i965_pci_ids.h The challenge with the centralised db of interesting info is that it will always be out of date for userspace (think userspace having to cope with a 5 year kernel, and a kernel having to cope with 10 year old userspace) and never enough so they still have to supplement it without their own db. That isn't to say that there isn't a lot of interesting hw properties that userspace needs to know, but they are also tend to be the ones tied to fuses and not pciid. What we do all duplicate are the pci-ids, so pulling those into a central header containing the commonly used per-id information in a format that can be embedded into any of the caller's structs is challenge enough. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Signed-off-by missing for commit in the drm-misc-fixes tree
Hi all,
Commit
ccb748df0058 ("drm/vc4: Fix the "no scaling" case on multi-planar YUV
formats")
is missing a Signed-off-by from its committer.
It was rebased.
--
Cheers,
Stephen Rothwell
pgpPsq45EkO5Y.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/4] intel: add IS_GENX() generic macro
On Sat, Aug 25, 2018 at 10:35:23AM +0100, Chris Wilson wrote:
> Quoting Lucas De Marchi (2018-08-25 00:56:46)
> > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > index 4a34b7be..8a0e3e76 100644
> > --- a/intel/intel_chipset.h
> > +++ b/intel/intel_chipset.h
> > @@ -568,6 +568,26 @@
> >
> > #define IS_GEN11(devid)(IS_ICELAKE_11(devid))
> >
> > +/* New platforms use kernel pci ids */
> > +#include "i915_pciids.h"
> > +
> > +struct pci_device_id {
>
> Don't call it pci_device_id, depending on caller that name may already
> be taken by libpciaccess.
ok. I can actually move it inside the function/macro and use an
autogenerated name.
>
> > + uint32_t unused0, device;
> > + uint32_t unused1, unused2;
> > + uint32_t unused3, unused4;
> These are all uint16_t.
kernel "document" them as uint32_t:
/*
* A pci_device_id struct {
* __u32 vendor, device;
* __u32 subvendor, subdevice;
* __u32 class, class_mask;
* kernel_ulong_t driver_data;
* };
* Don't use C99 here because "class" is reserved and we want to
* give userspace flexibility.
>
> > + unsigned long unused5;
>
> Simply make the unused disappear from the macro.
>
> > +};
> > +
> > +#define IS_GENX(x, devid) ({ \
> > + struct pci_device_id __ids[] = { INTEL_ ## x ## _IDS(0) }; \
>
> While that's a neat trick it's instantiating the array for each caller,
> and it does appear that we repeat a few of the macros.
>
> The best I can offer to keep the change non-invasive (other than just
> switching to a platform bitmask and filling (devid, gen, platform) from
> the pci match data on initialisation) is a two pass approach.
>
> static inline int __find_in_pciid(uint16_t devid,
> const struct pci_device_id *ids, size_t count)
> {
> size_t i = 0; /* we should rethink this if we think there are more than
> 4B of them! */
> for (i = 0; i < count; i++) {
> if (ids[i].device == devid)
> return 1;
> }
> return 0;
> }
>
>
> #define __is_genx(x) \
here I would name this DEFINE_IS_GENX, since it's a macro to define
the functions, not to be used in other places.
> static inline int __is_gen##x(uint16_t devid) \
> { \
> static const struct pci_device_id __ids[] = { INTEL_ ## x ## _IDS(0) };
> \
> return __find_in_pciid(devid, __ids, sizeof(__ids)/sizeof(__ids[0]); \
> }
> __is_genx(3);
> __is_genx(4);
> __is_genx(5);
> __is_genx(6);
> __is_genx(7);
> __is_genx(8);
> __is_genx(9);
> __is_genx(10);
> __is_genx(11);
>
> #define IS_GENX(x, devid) __is_gen##x(devid)
i915_pciids.h is not consistent with how the macros are called. See that
in my patch. So here I'd have:
#define DEFINE_IS_GENX(x, pfx) \
static inline int __is_gen##x(uint16_t devid) \
{ \
static const struct pci_device_id __ids[] = { INTEL_ ## pfx ## _IDS(0)
}; \
return __find_in_pciid(devid, __ids, sizeof(__ids)/sizeof(__ids[0]); \
}
#define IS_GEN10(devid) IS_GENX(10, CNL, devid)
For gen9 is more complicated as it needs several ids.
>
> That should help cut down the object size expansion. But longer term I'd
I'm not opposed to turning it into inline function, but if the goal is
to reduce the object size expansion, just making the array static const
should suffice... we do call the macros several times, but most of the
size is for constructing the array, not to find the elements.
> prefer if we moved to towards finding the match data once. Also we need
> to pull into the canonical header the friendly names for mesa.
what do you mean by "friendly names for mesa".
The other option that is actually my preferred is to let the kernel tell
user space what it is. What do you think about having an ioctl that returns
what is the gen + additional interesting info? Then user space could
base its decisions on features and fallback to gen version when there
isn't a way to discover if a feature/bug is present. This would allow
to simply remove the pci ids from user space projects which IMO would be
a good thing.
Lucas De Marchi
> -Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104362] GPU fault detected on wine-nine Path of Exile
https://bugs.freedesktop.org/show_bug.cgi?id=104362 --- Comment #3 from Andrey Grodzovsky --- (In reply to Vladimir Usikov from comment #2) > Created attachment 141280 [details] > dmesg > > Freeze still going on Linux 4.18.4 and mesa 18.1.7. Dmesg different. > > After freeze i try cat /sys/kernel/debug/dri/0/amdgpu_gpu_recover Please provide clean new dmesg loga also glxinfo. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107689] System freezes on shutdown. [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed (scratch(0xC040)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=107689 --- Comment #3 from Andrey Grodzovsky --- (In reply to john-s-84 from comment #2) > Created attachment 141300 [details] > full dmesg log (includes closing lit) I tried to reproduce the issues you report using Lexa card but encountered other, different bugs. But using Baffin ASIC i was able to reproduce something that looks what you experience. Will investigate. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support
On Mon, 27 Aug 2018 22:35:05 +0200 Boris Brezillon wrote: > On Mon, 27 Aug 2018 22:31:22 +0200 > Peter Rosin wrote: > > > On 2018-08-27 21:24, Boris Brezillon wrote: > > > On Sat, 25 Aug 2018 10:56:16 +0200 > > > Peter Rosin wrote: > > > > > >> Hi! > > >> > > >> The background for these patches is that our PCB interface between > > >> the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and > > >> this has to be described somewhere, or the atmel-hlcdc driver have no > > >> chance of selecting the correct output mode. Since we have similar > > >> problems with a tda19988 HDMI encoder I added patches to override > > >> the atmel-hlcdc output format via DT properties compatible with the > > >> media video-interface binding and things start to play together. > > > > > > Queued to drm-misc-next. > > > > Thanks! > > > > Minute issue, you seem to have some spell-check going on or something, > > because the subject of patch 1/4 has been "corrected" from > > "...add ti,ds90c185" to "...add ti, ds90c185" > > > > You might want to evaluate if that auto-correction "feature" should be > > disabled/tweaked/whatever... > > Hm, weird. I just downloaded the mbox from dri-devel's patchwork and > passed it to dim apply. dim tends to do a lot of things behind the > scene, so maybe it's also trying to fix typos :-). Nope, looks like it was already wrong on patchwork [1], don't know what happened, because the version I have in my mailbox is correct. [1]https://patchwork.freedesktop.org/patch/246039/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support
On Mon, 27 Aug 2018 22:31:22 +0200 Peter Rosin wrote: > On 2018-08-27 21:24, Boris Brezillon wrote: > > On Sat, 25 Aug 2018 10:56:16 +0200 > > Peter Rosin wrote: > > > >> Hi! > >> > >> The background for these patches is that our PCB interface between > >> the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and > >> this has to be described somewhere, or the atmel-hlcdc driver have no > >> chance of selecting the correct output mode. Since we have similar > >> problems with a tda19988 HDMI encoder I added patches to override > >> the atmel-hlcdc output format via DT properties compatible with the > >> media video-interface binding and things start to play together. > > > > Queued to drm-misc-next. > > Thanks! > > Minute issue, you seem to have some spell-check going on or something, > because the subject of patch 1/4 has been "corrected" from > "...add ti,ds90c185" to "...add ti, ds90c185" > > You might want to evaluate if that auto-correction "feature" should be > disabled/tweaked/whatever... Hm, weird. I just downloaded the mbox from dri-devel's patchwork and passed it to dim apply. dim tends to do a lot of things behind the scene, so maybe it's also trying to fix typos :-). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PL111 regression in v4.19-rc1
On Mon, Aug 27, 2018 at 4:34 PM Noralf Trønnes wrote: > I had time to look closer at this, and I don't think the fbdev change is > to blame. I think it's just that the problem shows up there because it's > the first to allocate a buffer. If the DRM side doesn't work either, I > guess the problem lies elsewhere. I think you're right. I tested today with the TVE200 driver (which is similar in structure) and it works just fine with the generic framebuffer refactorings. (Good job, by the way.) Oh well, I'll get back to bisecting. Thanks anyway! Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107689] System freezes on shutdown. [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disabled failed (scratch(0xC040)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=107689 --- Comment #2 from john-s...@gmx.net --- Created attachment 141300 --> https://bugs.freedesktop.org/attachment.cgi?id=141300=edit full dmesg log (includes closing lit) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/4] drm/atmel-hlcdc: bus-width override support
On Sat, 25 Aug 2018 10:56:16 +0200 Peter Rosin wrote: > Hi! > > The background for these patches is that our PCB interface between > the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and > this has to be described somewhere, or the atmel-hlcdc driver have no > chance of selecting the correct output mode. Since we have similar > problems with a tda19988 HDMI encoder I added patches to override > the atmel-hlcdc output format via DT properties compatible with the > media video-interface binding and things start to play together. Queued to drm-misc-next. Thanks, Boris > > Cheers, > Peter > > Changes since v8 https://lkml.org/lkml/2018/8/10/309 > - go back to the solution in v7 (but the ep device_node leak fixed) > for patch 4/4 > - redo (part of) 3/4 w/o using the disliked of_graph_parse_endpoint > > Changes since v7 https://lkml.org/lkml/2018/8/4/288 > - The ep device_node was leaked in v7 patch 3/3, so add patch 3/4 > which simplifies fixing this in patch 4/4 (and adds flexibility) > and adjust patch 4/4 to the changes done in the new 3/4. > - return -ENOMEM on allocation failure in patch 4/4 > > Changes since v6 https://lkml.org/lkml/2018/8/3/333 > - zap bus-type from the binding in patch 2/3 > > Changes since (the shortened) v5 https://lkml.org/lkml/2018/8/3/182 > - add reg properties (and #*-cells) to the example in patch 2/3 > - prohibit bus-width 0 in the device-tree in patch 3/3 > - added reviewed-by from Jacopo to patch 2/3 and 3/3 > > Peter Rosin (4): > dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185 > dt-bindings: display: atmel: optional video-interface of endpoints > drm/atmel-hlcdc: always iterate over the first 4 output endpoints > drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes > > .../devicetree/bindings/display/atmel/hlcdc-dc.txt | 23 ++ > .../bindings/display/bridge/lvds-transmitter.txt | 8 +- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 70 +++- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 1 + > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 92 > +++--- > 5 files changed, 163 insertions(+), 31 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] drm/atmel-hlcdc: revise selection of pixel-clock frequency divider
On Fri, 24 Aug 2018 11:24:56 +0200
Peter Rosin wrote:
> Hi!
>
> Some background can be found here:
> https://lists.freedesktop.org/archives/dri-devel/2018-August/187182.html
>
> The "10 times" discriminator in patch 2/2 can certainly be discussed...
Queued to drm-misc-next.
Thanks,
Boris
>
> Cheers,
> Peter
>
> Changes since v1https://lkml.org/lkml/2018/8/24/187
>
> - added {} to an if body for symmetry
> - reformatted comments a little bit
> - spelling/grammar fixes
>
> Peter Rosin (2):
> drm/atmel-hlcdc: prefer a higher rate clock as pixel-clock base
> drm/atmel-hlcdc: allow selecting a higher pixel-clock than requested
>
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 30
> --
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] drm/vc4: Fix TILE_Y_OFFSET definitions
On Fri, 3 Aug 2018 11:22:27 +0200
Boris Brezillon wrote:
> From: Eric Anholt
>
> Y_OFFSET field starts at bit 8 not 7.
>
> Signed-off-by: Eric Anholt
> Signed-off-by: Boris Brezillon
Queued the series to drm-misc-fixes.
> ---
> Changes in v2:
> - None
> ---
> drivers/gpu/drm/vc4/vc4_regs.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
> index d6864fa4bd14..ccbd6b377ffe 100644
> --- a/drivers/gpu/drm/vc4/vc4_regs.h
> +++ b/drivers/gpu/drm/vc4/vc4_regs.h
> @@ -1043,8 +1043,8 @@ enum hvs_pixel_format {
> #define SCALER_PITCH0_TILE_LINE_DIR BIT(15)
> #define SCALER_PITCH0_TILE_INITIAL_LINE_DIR BIT(14)
> /* Y offset within a tile. */
> -#define SCALER_PITCH0_TILE_Y_OFFSET_MASK VC4_MASK(13, 7)
> -#define SCALER_PITCH0_TILE_Y_OFFSET_SHIFT7
> +#define SCALER_PITCH0_TILE_Y_OFFSET_MASK VC4_MASK(13, 8)
> +#define SCALER_PITCH0_TILE_Y_OFFSET_SHIFT8
> #define SCALER_PITCH0_TILE_WIDTH_R_MASK VC4_MASK(6, 0)
> #define SCALER_PITCH0_TILE_WIDTH_R_SHIFT 0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v4] drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"
On Mon, Aug 27, 2018 at 01:45:48PM -0400, Lyude Paul wrote:
> On Mon, 2018-08-27 at 15:08 +0300, Ville Syrjälä wrote:
> > On Sat, Aug 25, 2018 at 03:10:35PM -0400, Lyude Paul wrote:
> > > From: Jan-Marek Glogowski
> > >
> > > This re-applies the workaround for "some DP sinks, [which] are a
> > > little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
> > > quality check unconditionally during long pulse").
> > > It makes the secondary AOC E2460P monitor connected via DP to an
> > > acer Veriton N4640G usable again.
> > >
> > > This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST
> > > DP link retraining into the ->post_hotplug() hook")
> > >
> > > Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the
> > > ->post_hotplug() hook")
> > > [Cleaned up commit message, added stable cc]
> > > Signed-off-by: Lyude Paul
> > > Signed-off-by: Jan-Marek Glogowski
> > > Cc: sta...@vger.kernel.org
> > > ---
> > > Resending this to update patchwork; will push in a little bit
> > >
> > > drivers/gpu/drm/i915/intel_dp.c | 33 +++--
> > > 1 file changed, 19 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index b3f6f04c3c7d..db8515171270 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -4333,18 +4333,6 @@ intel_dp_needs_link_retrain(struct intel_dp
> > > *intel_dp)
> > > return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> > > }
> > >
> > > -/*
> > > - * If display is now connected check links status,
> > > - * there has been known issues of link loss triggering
> > > - * long pulse.
> > > - *
> > > - * Some sinks (eg. ASUS PB287Q) seem to perform some
> > > - * weird HPD ping pong during modesets. So we can apparently
> > > - * end up with HPD going low during a modeset, and then
> > > - * going back up soon after. And once that happens we must
> > > - * retrain the link to get a picture. That's in case no
> > > - * userspace component reacted to intermittent HPD dip.
> > > - */
> > > int intel_dp_retrain_link(struct intel_encoder *encoder,
> > > struct drm_modeset_acquire_ctx *ctx)
> > > {
> > > @@ -5031,7 +5019,8 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> > > }
> > >
> > > static int
> > > -intel_dp_long_pulse(struct intel_connector *connector)
> > > +intel_dp_long_pulse(struct intel_connector *connector,
> > > + struct drm_modeset_acquire_ctx *ctx)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > > struct intel_dp *intel_dp = intel_attached_dp(>base);
> > > @@ -5090,6 +5079,22 @@ intel_dp_long_pulse(struct intel_connector
> > > *connector)
> > >*/
> > > status = connector_status_disconnected;
> > > goto out;
> > > + } else {
> > > + /*
> > > + * If display is now connected check links status,
> > > + * there has been known issues of link loss triggering
> > > + * long pulse.
> > > + *
> > > + * Some sinks (eg. ASUS PB287Q) seem to perform some
> > > + * weird HPD ping pong during modesets. So we can apparently
> > > + * end up with HPD going low during a modeset, and then
> > > + * going back up soon after. And once that happens we must
> > > + * retrain the link to get a picture. That's in case no
> > > + * userspace component reacted to intermittent HPD dip.
> > > + */
> > > + struct intel_encoder *encoder = _to_dig_port(intel_dp)-
> > > >base;
> > > +
> > > + intel_dp_retrain_link(encoder, ctx);
> >
> > We should really have a comment here that this is purely duct tape for
> > sinks that fail to signal a hpd when the link goes bad (either that or
> > we fail to process the hpd correctly).
> I'm fine with adding another patch to clarify that comment as well
>
> >
> > I suppose a better way to do this hack would be to do the link quality
> > check at the end of modeset, or from a delayed work. As is this depends
> > on userspace/fbdev doing an explicit probe after the modeset which seems
> > pretty fragile.
> I think having that at the end of a modeset in addition to this would be a
> good idea as well, I don't see any harm in having an additional check in the
> long pulse handler in case something causes the link to become unstable at
> some point in the future after the initial modeset
We already have that via the hotplug hook. The problem here is that there
is apparently no hpd signalled by the sink.
Someone should probably rename intel_dp_long_pulse() to something
else so that people don't get the wrong impression that it's somehow
dedicated to handling long hpds. In fact just
s/intel_dp_long_pulse()/intel_dp_detect()/ and sucking the few lines of
extra code into the function might be the right way to go.
>
> Jan, do you think you could
Re: [PATCH v2 4/7] drm/i2c: tda998x: convert to bridge driver
Hi Andrzej,
On Mon, Aug 27, 2018 at 06:15:59PM +0200, Andrzej Hajda wrote:
> On 30.07.2018 18:42, Russell King wrote:
> > static void tda998x_destroy(struct tda998x_priv *priv)
> > {
> > + drm_bridge_remove(>bridge);
> > +
> > /* disable all IRQs and free the IRQ handler */
> > cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
> > reg_clear(priv, REG_INT_FLAGS_2, INT_FLAGS_2_EDID_BLK_RD);
> > @@ -1650,6 +1663,7 @@ static int tda998x_create(struct i2c_client *client,
> > struct tda998x_priv *priv)
> > mutex_init(>mutex); /* protect the page access */
> > mutex_init(>audio_mutex); /* protect access from audio thread */
> > mutex_init(>edid_mutex);
> > + INIT_LIST_HEAD(>bridge.list);
>
> This line can be probably removed, unless there is a reason I am not
> aware of.
The addition above of drm_bridge_remove() to tda998x_destroy() means
that we end up calling this function in the error cleanup path. This
avoids unnecessary complexity with lots of different gotos - tda998x
has had a long history of not cleaning up stuff properly.
devm interfaces for bridge do not help avoid that - devm stuff only
works if everything that is registered previously is cleaned up via
devm mechanisms to ensure that a device's interface becomes unavailable
before stuff (eg, edid timers, detect work) is started to be cleaned up.
Otherwise, there's a chance of this stuff being triggered during
tear-down.
> > +static int tda998x_bind(struct device *dev, struct device *master, void
> > *data)
> > +{
> > + struct i2c_client *client = to_i2c_client(dev);
> > + struct drm_device *drm = data;
> > + struct tda998x_priv *priv;
> > + int ret;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + dev_set_drvdata(dev, priv);
> > +
> > + ret = tda998x_create(client, priv);
> > + if (ret)
> > + return ret;
> > +
> > + ret = tda998x_encoder_init(dev, drm);
> > + if (ret) {
> > + tda998x_destroy(priv);
> > + return ret;
> > + }
> > + return 0;
>
> It could be replaced by:
> ret = tda998x_encoder_init(dev, drm);
> if (ret)
> tda998x_destroy(priv);
> return ret;
>
> but this is probably matter of taste.
It's not clear to me what "It" is - I think you're suggesting combining
tda998x_create() and tda998x_encoder_init() ?
The code is structured this way to make the following patches easier -
there is no point of combining things only to have to then break them
apart again in a later patch. Please see patch 7, where tda998x_create()
moves out of this function, where exactly this happens.
> Moreover I guess priv->is_on could be removed if enable/disable
> callbacks are called only by drm_core, but this is for another patch.
Is it guaranteed that a bridge ->enable or ->disable callback won't be
called twice, even for legacy drivers? I think atomic guarantees this
but I don't think it's guaranteed for legacy drivers.
I'm guessing Rob had a reason why he added the check when he originally
created the driver (encoder ->dpms can be called for the same dpms
state multiple times?)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v4] drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"
On Mon, 2018-08-27 at 15:08 +0300, Ville Syrjälä wrote:
> On Sat, Aug 25, 2018 at 03:10:35PM -0400, Lyude Paul wrote:
> > From: Jan-Marek Glogowski
> >
> > This re-applies the workaround for "some DP sinks, [which] are a
> > little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
> > quality check unconditionally during long pulse").
> > It makes the secondary AOC E2460P monitor connected via DP to an
> > acer Veriton N4640G usable again.
> >
> > This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST
> > DP link retraining into the ->post_hotplug() hook")
> >
> > Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the
> > ->post_hotplug() hook")
> > [Cleaned up commit message, added stable cc]
> > Signed-off-by: Lyude Paul
> > Signed-off-by: Jan-Marek Glogowski
> > Cc: sta...@vger.kernel.org
> > ---
> > Resending this to update patchwork; will push in a little bit
> >
> > drivers/gpu/drm/i915/intel_dp.c | 33 +++--
> > 1 file changed, 19 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index b3f6f04c3c7d..db8515171270 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4333,18 +4333,6 @@ intel_dp_needs_link_retrain(struct intel_dp
> > *intel_dp)
> > return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> > }
> >
> > -/*
> > - * If display is now connected check links status,
> > - * there has been known issues of link loss triggering
> > - * long pulse.
> > - *
> > - * Some sinks (eg. ASUS PB287Q) seem to perform some
> > - * weird HPD ping pong during modesets. So we can apparently
> > - * end up with HPD going low during a modeset, and then
> > - * going back up soon after. And once that happens we must
> > - * retrain the link to get a picture. That's in case no
> > - * userspace component reacted to intermittent HPD dip.
> > - */
> > int intel_dp_retrain_link(struct intel_encoder *encoder,
> > struct drm_modeset_acquire_ctx *ctx)
> > {
> > @@ -5031,7 +5019,8 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> > }
> >
> > static int
> > -intel_dp_long_pulse(struct intel_connector *connector)
> > +intel_dp_long_pulse(struct intel_connector *connector,
> > + struct drm_modeset_acquire_ctx *ctx)
> > {
> > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > struct intel_dp *intel_dp = intel_attached_dp(>base);
> > @@ -5090,6 +5079,22 @@ intel_dp_long_pulse(struct intel_connector
> > *connector)
> > */
> > status = connector_status_disconnected;
> > goto out;
> > + } else {
> > + /*
> > +* If display is now connected check links status,
> > +* there has been known issues of link loss triggering
> > +* long pulse.
> > +*
> > +* Some sinks (eg. ASUS PB287Q) seem to perform some
> > +* weird HPD ping pong during modesets. So we can apparently
> > +* end up with HPD going low during a modeset, and then
> > +* going back up soon after. And once that happens we must
> > +* retrain the link to get a picture. That's in case no
> > +* userspace component reacted to intermittent HPD dip.
> > +*/
> > + struct intel_encoder *encoder = _to_dig_port(intel_dp)-
> > >base;
> > +
> > + intel_dp_retrain_link(encoder, ctx);
>
> We should really have a comment here that this is purely duct tape for
> sinks that fail to signal a hpd when the link goes bad (either that or
> we fail to process the hpd correctly).
I'm fine with adding another patch to clarify that comment as well
>
> I suppose a better way to do this hack would be to do the link quality
> check at the end of modeset, or from a delayed work. As is this depends
> on userspace/fbdev doing an explicit probe after the modeset which seems
> pretty fragile.
I think having that at the end of a modeset in addition to this would be a
good idea as well, I don't see any harm in having an additional check in the
long pulse handler in case something causes the link to become unstable at
some point in the future after the initial modeset
Jan, do you think you could provide some dmesg logs for this issue?
>
> > }
> >
> > /*
> > @@ -5151,7 +5156,7 @@ intel_dp_detect(struct drm_connector *connector,
> > return ret;
> > }
> >
> > - status = intel_dp_long_pulse(intel_dp->attached_connector);
> > + status = intel_dp_long_pulse(intel_dp->attached_connector,
> > ctx);
> > }
> >
> > intel_dp->detect_done = false;
> > --
> > 2.17.1
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
--
Cheers,
Re: [PATCH v4] drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"
On Mon, 2018-08-27 at 11:43 +0300, Jani Nikula wrote:
> On Sat, 25 Aug 2018, Lyude Paul wrote:
> > From: Jan-Marek Glogowski
> >
> > This re-applies the workaround for "some DP sinks, [which] are a
> > little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
> > quality check unconditionally during long pulse").
> > It makes the secondary AOC E2460P monitor connected via DP to an
> > acer Veriton N4640G usable again.
> >
> > This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST
> > DP link retraining into the ->post_hotplug() hook")
> >
> > Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the
> > ->post_hotplug() hook")
> > [Cleaned up commit message, added stable cc]
> > Signed-off-by: Lyude Paul
> > Signed-off-by: Jan-Marek Glogowski
> > Cc: sta...@vger.kernel.org
> > ---
> > Resending this to update patchwork; will push in a little bit
>
> Is there a bugzilla? Reference to a list discussion? Something with a
> dmesg where someone can actually verify this is the right fix?
This patch has actually been on the list for a while now-I have had mdnavare
take a look at it as well (they said it looked fine with the only change being
in regards to the comment), and it'd been on the list for a while already.
>
> IMO needs an ack from Ville too. He should be in Cc: in the first place
> as the author of the regressing commit.
>
> 'dim fixes c85d200e8321' gives you the output:
aaah-I had thought it was just for generating the Fixes line, I will be more
careful about that in the future
>
> Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the
> ->post_hotplug() hook")
> Cc: Manasi Navare
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Cc: Lyude Paul
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-...@lists.freedesktop.org
> Cc: # v4.17+
>
> BR,
> Jani.
>
> >
> > drivers/gpu/drm/i915/intel_dp.c | 33 +++--
> > 1 file changed, 19 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index b3f6f04c3c7d..db8515171270 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4333,18 +4333,6 @@ intel_dp_needs_link_retrain(struct intel_dp
> > *intel_dp)
> > return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> > }
> >
> > -/*
> > - * If display is now connected check links status,
> > - * there has been known issues of link loss triggering
> > - * long pulse.
> > - *
> > - * Some sinks (eg. ASUS PB287Q) seem to perform some
> > - * weird HPD ping pong during modesets. So we can apparently
> > - * end up with HPD going low during a modeset, and then
> > - * going back up soon after. And once that happens we must
> > - * retrain the link to get a picture. That's in case no
> > - * userspace component reacted to intermittent HPD dip.
> > - */
> > int intel_dp_retrain_link(struct intel_encoder *encoder,
> > struct drm_modeset_acquire_ctx *ctx)
> > {
> > @@ -5031,7 +5019,8 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> > }
> >
> > static int
> > -intel_dp_long_pulse(struct intel_connector *connector)
> > +intel_dp_long_pulse(struct intel_connector *connector,
> > + struct drm_modeset_acquire_ctx *ctx)
> > {
> > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > struct intel_dp *intel_dp = intel_attached_dp(>base);
> > @@ -5090,6 +5079,22 @@ intel_dp_long_pulse(struct intel_connector
> > *connector)
> > */
> > status = connector_status_disconnected;
> > goto out;
> > + } else {
> > + /*
> > +* If display is now connected check links status,
> > +* there has been known issues of link loss triggering
> > +* long pulse.
> > +*
> > +* Some sinks (eg. ASUS PB287Q) seem to perform some
> > +* weird HPD ping pong during modesets. So we can apparently
> > +* end up with HPD going low during a modeset, and then
> > +* going back up soon after. And once that happens we must
> > +* retrain the link to get a picture. That's in case no
> > +* userspace component reacted to intermittent HPD dip.
> > +*/
> > + struct intel_encoder *encoder = _to_dig_port(intel_dp)-
> > >base;
> > +
> > + intel_dp_retrain_link(encoder, ctx);
> > }
> >
> > /*
> > @@ -5151,7 +5156,7 @@ intel_dp_detect(struct drm_connector *connector,
> > return ret;
> > }
> >
> > - status = intel_dp_long_pulse(intel_dp->attached_connector);
> > + status = intel_dp_long_pulse(intel_dp->attached_connector,
> > ctx);
> > }
> >
> > intel_dp->detect_done = false;
>
>
--
Cheers,
Lyude Paul
___
dri-devel mailing list
[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #35 from Andrey Grodzovsky --- (In reply to Andrey Grodzovsky from comment #34) > (In reply to CheatCodesOfLife from comment #33) > > Created attachment 141277 [details] > > amd3.tar.gz dmesg, trace, ddebug logs > > > > Sorry about that. > > I don't have that dmesg any more but I did the whole process again and > > attached it. This time I have confirmed all the files are in the archive. > > But where is the trace file ? :) Any way I will try to check with what I > have. Any way, doesn't matter, could you please redo the capture and this time instead of GALLIUM_DDEBUG=always do GALLIUM_DDEBUG=1000 ? This way we can get one big dump file when VM_FAULT happens with all the info. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107668] Blank screen (Cannot find any crtc or sizes) since Kernel 4.17 (AMDGPU.DC) on Amd Radeon RX460 on HDMI LG Ultrawidescreen Monitor
https://bugs.freedesktop.org/show_bug.cgi?id=107668 --- Comment #3 from Naheem Zaffar --- Created attachment 141299 --> https://bugs.freedesktop.org/attachment.cgi?id=141299=edit Log messages from Gnome Logs for boot with blank screen Taken from kernel 4.19.0-0.rc0.git12.1.vanilla.knurd.1.fc28.x86_64 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drivers/block/z2ram: use ioremap_wt() instead of __ioremap(_PAGE_WRITETHRU)
On Mon, Aug 27, 2018 at 6:10 PM Christophe Leroy
wrote:
> _PAGE_WRITETHRU is a target specific flag. Prefer generic functions.
>
> Signed-off-by: Christophe Leroy
From a Zorro bus point of view:
Acked-by: Geert Uytterhoeven
> --- a/drivers/block/z2ram.c
> +++ b/drivers/block/z2ram.c
> @@ -190,8 +190,7 @@ static int z2_open(struct block_device *bdev, fmode_t
> mode)
> vfree(vmalloc (size));
> }
>
> - vaddr = (unsigned long) __ioremap (paddr, size,
> - _PAGE_WRITETHRU);
> + vaddr = (unsigned long)ioremap_wt(paddr, size);
>
> #else
> vaddr = (unsigned long)z_remap_nocache_nonser(paddr, size);
However, since the removal of APUS support, this file can no longer be
compiled on powerpc.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/i2c: tda998x: move mode_valid() to bridge
On 31.07.2018 11:26, Russell King wrote:
> Move the mode_valid() implementation to the bridge instead of the
> connector, as we're checking the bridge's capabilities.
>
> Signed-off-by: Russell King
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 32
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 8ca5c9786bdf..58831b6a4722 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -1244,21 +1244,6 @@ static int tda998x_connector_get_modes(struct
> drm_connector *connector)
> return n;
> }
>
> -static int tda998x_connector_mode_valid(struct drm_connector *connector,
> - struct drm_display_mode *mode)
> -{
> - /* TDA19988 dotclock can go up to 165MHz */
> - struct tda998x_priv *priv = conn_to_tda998x_priv(connector);
> -
> - if (mode->clock > ((priv->rev == TDA19988) ? 165000 : 15))
> - return MODE_CLOCK_HIGH;
> - if (mode->htotal >= BIT(13))
> - return MODE_BAD_HVALUE;
> - if (mode->vtotal >= BIT(11))
> - return MODE_BAD_VVALUE;
> - return MODE_OK;
> -}
> -
> static struct drm_encoder *
> tda998x_connector_best_encoder(struct drm_connector *connector)
> {
> @@ -1270,7 +1255,6 @@ tda998x_connector_best_encoder(struct drm_connector
> *connector)
> static
> const struct drm_connector_helper_funcs tda998x_connector_helper_funcs = {
> .get_modes = tda998x_connector_get_modes,
> - .mode_valid = tda998x_connector_mode_valid,
> .best_encoder = tda998x_connector_best_encoder,
> };
>
> @@ -1316,6 +1300,21 @@ static void tda998x_bridge_detach(struct drm_bridge
> *bridge)
> drm_connector_cleanup(>connector);
> }
>
> +static int tda998x_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode)
> +{
> + /* TDA19988 dotclock can go up to 165MHz */
> + struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
> +
> + if (mode->clock > ((priv->rev == TDA19988) ? 165000 : 15))
> + return MODE_CLOCK_HIGH;
> + if (mode->htotal >= BIT(13))
> + return MODE_BAD_HVALUE;
> + if (mode->vtotal >= BIT(11))
> + return MODE_BAD_VVALUE;
> + return MODE_OK;
> +}
> +
> static void tda998x_bridge_enable(struct drm_bridge *bridge)
> {
> struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
> @@ -1562,6 +1561,7 @@ static void tda998x_bridge_mode_set(struct drm_bridge
> *bridge,
> static const struct drm_bridge_funcs tda998x_bridge_funcs = {
> .attach = tda998x_bridge_attach,
> .detach = tda998x_bridge_detach,
> + .mode_valid = tda998x_bridge_mode_valid,
> .disable = tda998x_bridge_disable,
> .mode_set = tda998x_bridge_mode_set,
> .enable = tda998x_bridge_enable,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] drm/i2c: tda998x: register bridge outside of component helper
On 30.07.2018 18:42, Russell King wrote: > Register the bridge outside of the component helper as we have > drivers that wish to use the tda998x without its encoder. > > Signed-off-by: Russell King Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/7] drm/i2c: tda998x: convert to bridge driver
On 30.07.2018 18:42, Russell King wrote:
> Convert tda998x to a bridge driver with built-in encoder support for
> compatibility with existing component drivers.
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 154
> +++---
> 1 file changed, 79 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> b/drivers/gpu/drm/i2c/tda998x_drv.c
> index 843078e9fbf3..1ea62052f3e0 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -69,6 +69,7 @@ struct tda998x_priv {
> bool edid_delay_active;
>
> struct drm_encoder encoder;
> + struct drm_bridge bridge;
> struct drm_connector connector;
>
> struct tda998x_audio_port audio_port[2];
> @@ -79,9 +80,10 @@ struct tda998x_priv {
>
> #define conn_to_tda998x_priv(x) \
> container_of(x, struct tda998x_priv, connector)
> -
> #define enc_to_tda998x_priv(x) \
> container_of(x, struct tda998x_priv, encoder)
> +#define bridge_to_tda998x_priv(x) \
> + container_of(x, struct tda998x_priv, bridge)
>
> /* The TDA9988 series of devices use a paged register scheme.. to simplify
> * things we encode the page # in upper bits of the register #. To read/
> @@ -1262,7 +1264,7 @@ tda998x_connector_best_encoder(struct drm_connector
> *connector)
> {
> struct tda998x_priv *priv = conn_to_tda998x_priv(connector);
>
> - return >encoder;
> + return priv->bridge.encoder;
> }
>
> static
> @@ -1292,15 +1294,32 @@ static int tda998x_connector_init(struct tda998x_priv
> *priv,
> if (ret)
> return ret;
>
> - drm_mode_connector_attach_encoder(>connector, >encoder);
> + drm_mode_connector_attach_encoder(>connector,
> + priv->bridge.encoder);
>
> return 0;
> }
>
> -/* DRM encoder functions */
> +/* DRM bridge functions */
> +
> +static int tda998x_bridge_attach(struct drm_bridge *bridge)
> +{
> + struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
> +
> + return tda998x_connector_init(priv, bridge->dev);
> +}
> +
> +static void tda998x_bridge_detach(struct drm_bridge *bridge)
> +{
> + struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
> +
> + drm_connector_cleanup(>connector);
> +}
>
> -static void tda998x_enable(struct tda998x_priv *priv)
> +static void tda998x_bridge_enable(struct drm_bridge *bridge)
> {
> + struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
> +
> if (!priv->is_on) {
> /* enable video ports, audio will be enabled later */
> reg_write(priv, REG_ENA_VP_0, 0xff);
> @@ -1315,8 +1334,10 @@ static void tda998x_enable(struct tda998x_priv *priv)
> }
> }
>
> -static void tda998x_disable(struct tda998x_priv *priv)
> +static void tda998x_bridge_disable(struct drm_bridge *bridge)
> {
> + struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
> +
> if (!priv->is_on) {
> /* disable video ports */
> reg_write(priv, REG_ENA_VP_0, 0x00);
> @@ -1327,29 +1348,11 @@ static void tda998x_disable(struct tda998x_priv *priv)
> }
> }
>
> -static void tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
> +static void tda998x_bridge_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> {
> - struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
> - bool on;
> -
> - /* we only care about on or off: */
> - on = mode == DRM_MODE_DPMS_ON;
> -
> - if (on == priv->is_on)
> - return;
> -
> - if (on)
> - tda998x_enable(priv);
> - else
> - tda998x_disable(priv);
> -}
> -
> -static void
> -tda998x_encoder_mode_set(struct drm_encoder *encoder,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> - struct tda998x_priv *priv = enc_to_tda998x_priv(encoder);
> + struct tda998x_priv *priv = bridge_to_tda998x_priv(bridge);
> u16 ref_pix, ref_line, n_pix, n_line;
> u16 hs_pix_s, hs_pix_e;
> u16 vs1_pix_s, vs1_pix_e, vs1_line_s, vs1_line_e;
> @@ -1556,8 +1559,18 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> mutex_unlock(>audio_mutex);
> }
>
> +static const struct drm_bridge_funcs tda998x_bridge_funcs = {
> + .attach = tda998x_bridge_attach,
> + .detach = tda998x_bridge_detach,
> + .disable = tda998x_bridge_disable,
> + .mode_set = tda998x_bridge_mode_set,
> + .enable = tda998x_bridge_enable,
> +};
> +
> static void tda998x_destroy(struct tda998x_priv *priv)
> {
> + drm_bridge_remove(>bridge);
> +
> /* disable all IRQs and free the IRQ handler */
> cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
> reg_clear(priv, REG_INT_FLAGS_2,
[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #34 from Andrey Grodzovsky --- (In reply to CheatCodesOfLife from comment #33) > Created attachment 141277 [details] > amd3.tar.gz dmesg, trace, ddebug logs > > Sorry about that. > I don't have that dmesg any more but I did the whole process again and > attached it. This time I have confirmed all the files are in the archive. But where is the trace file ? :) Any way I will try to check with what I have. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
How to gracefully handle pci remove
Hi everybody , I am trying to resolve various problems I observe when logically removing AMDGPU device from pci - echo 1 > /sys/class/drm/card0/device/remove One of the problems I encountered was hitting WARNs in amdgpu_gem_force_release. It complaints about still open client FDs and BOs allocations which is obvious since we didn't let user space clients know about the device removal and hence they won't release allocations and won't close their FDs. Question - how other drivers handle this use case, especially eGPUs since they indeed may be extracted in any moment, is there any way to notify Xorg and other clients about this so they may have a chance to release all their allocations and probably terminate ? Maybe some kind of uevent ? Andrey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107668] Blank screen (Cannot find any crtc or sizes) since Kernel 4.17 (AMDGPU.DC) on Amd Radeon RX460 on HDMI LG Ultrawidescreen Monitor
https://bugs.freedesktop.org/show_bug.cgi?id=107668 Naheem Zaffar changed: What|Removed |Added Summary|Blank screen since Kernel |Blank screen (Cannot find |4.17 (AMDGPU.DC) on Amd |any crtc or sizes) since |Radeon RX460 on HDMI LG |Kernel 4.17 (AMDGPU.DC) on |Ultrawidescreen Monitor |Amd Radeon RX460 on HDMI LG ||Ultrawidescreen Monitor -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107668] Blank screen since Kernel 4.17 (AMDGPU.DC) on Amd Radeon RX460 on HDMI LG Ultrawidescreen Monitor
https://bugs.freedesktop.org/show_bug.cgi?id=107668 Naheem Zaffar changed: What|Removed |Added Summary|Blank screen since Kernel |Blank screen since Kernel |4.17 (AMDGPU.DC) on Amd |4.17 (AMDGPU.DC) on Amd |Radeon RX460 and RX380 on |Radeon RX460 on HDMI LG |HDMI Ultrawidescreen|Ultrawidescreen Monitor |Monitor | -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107668] Blank screen since Kernel 4.17 (AMDGPU.DC) on Amd Radeon RX460 and RX380 on HDMI Ultrawidescreen Monitor
https://bugs.freedesktop.org/show_bug.cgi?id=107668 Naheem Zaffar changed: What|Removed |Added Version|XOrg git|DRI git -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107668] Blank screen since Kernel 4.17 (AMDGPU.DC) on Amd Radeon RX460 and RX380 on HDMI Ultrawidescreen Monitor
https://bugs.freedesktop.org/show_bug.cgi?id=107668 --- Comment #2 from Naheem Zaffar --- Having a look online I can see the same bug reported on Ubuntu where attempted triage has provided more results that may help track this issue down: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1761751 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm/msm/A6xx: Add devfreq support for A6xx
On Mon, Aug 27, 2018 at 12:47:20PM +0530, Sharat Masetty wrote:
> Implement routines to estimate GPU busy time and fetching the
> current frequency for the polling interval. This is required by
> the devfreq framework which recommends a frequency change if needed.
> The driver code then tries to set this new frequency on the GPU by
> sending an Out Of Band(OOB) request to the GMU.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 39
> +++
> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 2 ++
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 ++
> 4 files changed, 66 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index f6634c0..3a7b899 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -67,7 +67,7 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
> A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
> }
>
> -static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> +static int __a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
> {
> gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
>
> @@ -84,7 +84,38 @@ static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int
> index)
> a6xx_gmu_set_oob(gmu, GMU_OOB_DCVS_SET);
> a6xx_gmu_clear_oob(gmu, GMU_OOB_DCVS_SET);
>
> - return gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
> + if (gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN) != 0)
> + return -EINVAL;
> +
> + gmu->freq = gmu->gpu_freqs[index];
> +
> + return 0;
> +}
While I was working on the interconnect patches it occurred to me that the upper
levels doesn't really care what the value of A6XX_GMU_DCVS_RETURN is so we might
want to just print an error message and return nothing. If the DCVS set didn't
work we might be headed for disaster on the GMU side but its more likely that
we'll just continue along at the current frequency for the next cycle so it
isn't terribly harmful.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107593] spam in dmesg about "SADs count" since recent Radeon RX550 install using amdgpu driver
https://bugs.freedesktop.org/show_bug.cgi?id=107593 --- Comment #8 from Fermulator --- (understood) - so the SADs count is a bug to be fixed (the comparison I provided against legit data is N/A here and anyway is fixed in newer kernel versions) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/msm: re-factor devfreq code
On Mon, Aug 27, 2018 at 12:47:19PM +0530, Sharat Masetty wrote:
> The devfreq framework requires the drivers to provide busy time estimations.
> The GPU driver relies on the hardware performance counteres for the busy time
> estimations, but different hardware revisions have counters which can be
> sourced from different clocks. So the busy time estimation will be target
> dependent. Additionally on targets where the clocks are completely controlled
> by the on chip microcontroller, fetching and setting the current GPU frequency
> will be different. This patch aims to embrace these differences by
> re-factoring
> the devfreq code a bit.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 16 +---
> drivers/gpu/drm/msm/msm_gpu.c | 49
> ---
> drivers/gpu/drm/msm/msm_gpu.h | 5 +++-
> 3 files changed, 44 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 897f3e2..043e680 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -1369,12 +1369,20 @@ static struct msm_ringbuffer *a5xx_active_ring(struct
> msm_gpu *gpu)
> return a5xx_gpu->cur_ring;
> }
>
> -static int a5xx_gpu_busy(struct msm_gpu *gpu, uint64_t *value)
> +static unsigned long a5xx_gpu_busy(struct msm_gpu *gpu)
> {
> - *value = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
> - REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
> + u64 busy_cycles;
> + unsigned long busy_time;
>
> - return 0;
> + busy_cycles = gpu_read64(gpu, REG_A5XX_RBBM_PERFCTR_RBBM_0_LO,
> + REG_A5XX_RBBM_PERFCTR_RBBM_0_HI);
> +
> + busy_time = (busy_cycles - gpu->devfreq.busy_cycles) /
> + (clk_get_rate(gpu->core_clk) / 100);
> +
> + gpu->devfreq.busy_cycles = busy_cycles;
> +
> + return busy_time;
> }
>
> static const struct adreno_gpu_funcs funcs = {
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 8d6bc0c..26c1c3a 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -36,12 +36,16 @@ static int msm_devfreq_target(struct device *dev,
> unsigned long *freq,
> struct msm_gpu *gpu = platform_get_drvdata(to_platform_device(dev));
> struct dev_pm_opp *opp;
>
> - opp = dev_pm_opp_find_freq_ceil(dev, freq);
> + opp = devfreq_recommended_opp(dev, freq, flags);
> + if (IS_ERR(opp))
> + return PTR_ERR(opp);
>
> - if (!IS_ERR(opp)) {
> + if (gpu->funcs->gpu_set_freq)
> + gpu->funcs->gpu_set_freq(gpu, (u64)*freq);
Depending on how the interconnect patches end up looking it might make more
sense for us to send the OPP itself to gpu_set_freq() but we'll put a pin in
that until we know more.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 7/7] drm/bridge: ti-sn65dsi86: Add mystery delay to enable()
On Mon, Aug 27, 2018 at 07:40:05AM +0530, spa...@codeaurora.org wrote: > On 2018-08-14 03:00, Sean Paul wrote: > > From: Sean Paul > > > > This patch adds a 70ms mystery delay to the bridge driver in enable. > > By experimentation, it seems like it can go anywhere up until we > > initiate semi-auto link training. If we don't have the delay, link > > training fails. > > > > I tried to root cause this as best I could, but neither the datasheet > > for the panel nor the bridge mention a delay of this magnitude in their > > timing requirements. So for now, add the mystery delay until someone > > figures out a better fix. > > > > Changes in v3: > > - Added to the set > > > > Cc: Sandeep Panda > > Signed-off-by: Sean Paul > > --- > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > index d3e27e52ea759..f8a931cf3665e 100644 > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > @@ -458,6 +458,18 @@ static void ti_sn_bridge_enable(struct drm_bridge > > *bridge) > > unsigned int val; > > int ret; > > > > + /* > > +* FIXME: > > +* This 70ms was found necessary by experimentation. If it's not > > +* present, link training fails. It seems like it can go anywhere from > > +* pre_enable() up to semi-auto link training initiation below. > > +* > > +* Neither the datasheet for the bridge nor the panel tested mention a > > +* delay of this magnitude in the timing requirements. So for now, add > > +* the mystery delay until someone figures out a better fix. > > +*/ > > + msleep(70); > > + > > /* DSI_A lane config */ > > val = CHA_DSI_LANES(4 - pdata->dsi->lanes); > > regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG, > > Reviewed-by: Sandeep Panda Pushed to -misc-next, thanks for your reviews. Sean -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/5] drm/msm: unregister devfreq upon clean up
On Mon, Aug 27, 2018 at 12:47:17PM +0530, Sharat Masetty wrote:
> Call the devfreq_remove_device() API to remove the GPU devfreq instance
> during GPU driver cleanup.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 04f9604..8d6bc0c 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -970,6 +970,8 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
>
> WARN_ON(!list_empty(>active_list));
>
> + devm_devfreq_remove_device(>pdev->dev, gpu->devfreq.devfreq);
> +
Sorry, I don't think I made myself clear. We should use devm_devfreq_add_device
during initialization so that we don't need to do a devfreq_remove_device during
cleanup. This will still be a one line patch but in a different location.
Jordan
> for (i = 0; i < ARRAY_SIZE(gpu->rb); i++) {
> msm_ringbuffer_destroy(gpu->rb[i]);
> gpu->rb[i] = NULL;
> --
> 1.9.1
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/9] OPP: Add dev_pm_opp_get_interconnect_bw()
Add dev_pm_opp_get_interconnect_bw() to read the interconnect
bandwidth values for a given OPP.
Signed-off-by: Jordan Crouse
---
drivers/opp/of.c | 36
include/linux/pm_opp.h | 7 +++
2 files changed, 43 insertions(+)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 7af0ddec936b..6a5eecaaf8c1 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -777,3 +777,39 @@ struct device_node *dev_pm_opp_get_of_node(struct
dev_pm_opp *opp)
return of_node_get(opp->np);
}
EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node);
+
+/**
+ * dev_pm_opp_get_interconnect_bw() - Get the interconnect bandwidth for the
opp
+ * @opp: opp containing the bandwidth values
+ * @pathname: name of the interconnect path for the bandwidth values
+ * @avgbw: Pointer for the value to hold the average BW defined for the OPP
+ * @peakbw:Pointer for the value to hold the peak BW defined for the OPP
+ *
+ * Return: Negative value on error or 0 on success
+ */
+int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp,
+ const char *pathname, u64 *avgbw, u64 *peakbw)
+{
+ char name[NAME_MAX];
+ struct property *prop;
+ int count;
+
+ if (IS_ERR_OR_NULL(opp))
+ return -ENOENT;
+
+ snprintf(name, NAME_MAX, "opp-interconnect-bw-%s", pathname);
+ prop = of_find_property(opp->np, name, NULL);
+
+ if (!prop)
+ return -ENOENT;
+
+ count = of_property_count_u64_elems(opp->np, name);
+ if (count != 2)
+ return -EINVAL;
+
+ of_property_read_u64_index(opp->np, name, 0, avgbw);
+ of_property_read_u64_index(opp->np, name, 0, peakbw);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_interconnect_bw);
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 099b31960dec..70e49e259d0e 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -301,6 +301,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev,
struct cpumask *cpuma
struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
struct dev_pm_opp *of_dev_pm_opp_find_required_opp(struct device *dev, struct
device_node *np);
struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
+int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char
*pathname, u64 *avgbw, u64 *peakbw);
#else
static inline int dev_pm_opp_of_add_table(struct device *dev)
{
@@ -343,6 +344,12 @@ static inline struct device_node
*dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
{
return NULL;
}
+
+static inline int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const
char *pathname,
+ u64 *avgbw, u64 *peakbw)
+{
+ return -ENOTSUPP;
+}
#endif
#endif /* __LINUX_OPP_H__ */
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/9] drm/msm/a6xx: Add support for an interconnect path
Add support for setting the OPP defined bandwidth for a given
GPU frequency value for a6xx. On sdm845 even though the GPU
frequency is set by the GMU but the bus bandwidth quota is
set by the CPU.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 27 +++--
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 7 +++
drivers/gpu/drm/msm/msm_gpu.h | 3 +++
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index d0dac4c2e3e7..d63eefc7c74d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include "a6xx_gpu.h"
@@ -65,8 +66,15 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
}
-static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
+static void a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
{
+ struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
+ struct adreno_gpu *adreno_gpu = _gpu->base;
+ struct msm_gpu *gpu = _gpu->base;
+ struct dev_pm_opp *opp;
+ u64 ab, ib;
+ int ret;
+
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
@@ -82,7 +90,22 @@ static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
a6xx_gmu_set_oob(gmu, GMU_OOB_DCVS_SET);
a6xx_gmu_clear_oob(gmu, GMU_OOB_DCVS_SET);
- return gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
+ ret = gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
+ if (ret)
+ dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
+
+ /* Set the interconnect bandwidth from the CPU */
+ if (IS_ERR_OR_NULL(gpu->icc_path))
+ return;
+
+ opp = dev_pm_opp_find_freq_exact(>pdev->dev,
+ gmu->gpu_freqs[index], true);
+ if (!IS_ERR_OR_NULL(opp)) {
+ if (!dev_pm_opp_get_interconnect_bw(opp, "port0", , ))
+ icc_set(gpu->icc_path, ab, ib);
+
+ dev_pm_opp_put(opp);
+ }
}
static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index da1363a0c54d..2eace9bf32c7 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "adreno_gpu.h"
#include "msm_gem.h"
#include "msm_mmu.h"
@@ -694,6 +695,9 @@ static int adreno_get_pwrlevels(struct device *dev,
DBG("fast_rate=%u, slow_rate=2700", gpu->fast_rate);
+ /* Check for an interconnect path for the bus */
+ gpu->icc_path = of_icc_get(dev, "port0");
+
return 0;
}
@@ -732,10 +736,13 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
{
+ struct msm_gpu *gpu = _gpu->base;
unsigned int i;
for (i = 0; i < ARRAY_SIZE(adreno_gpu->info->fw); i++)
release_firmware(adreno_gpu->fw[i]);
+ icc_put(gpu->icc_path);
+
msm_gpu_cleanup(_gpu->base);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 9122ee6e55e4..9c851d03f344 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -20,6 +20,7 @@
#include
#include
+#include
#include "msm_drv.h"
#include "msm_fence.h"
@@ -117,6 +118,8 @@ struct msm_gpu {
struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
uint32_t fast_rate;
+ struct icc_path *icc_path;
+
/* Hang and Inactivity Detection:
*/
#define DRM_MSM_INACTIVE_PERIOD 66 /* in ms (roughly four frames) */
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] dt-bindings: Document qcom,adreno-gmu
Document the device tree bindings for the Adreno GMU device
available on Adreno a6xx targets.
Reviewed-by: Rob Herring
Signed-off-by: Jordan Crouse
---
.../devicetree/bindings/display/msm/gmu.txt | 54 +++
.../devicetree/bindings/display/msm/gpu.txt | 10 +++-
2 files changed, 62 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt
diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
b/Documentation/devicetree/bindings/display/msm/gmu.txt
new file mode 100644
index ..f65bb49fff36
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
@@ -0,0 +1,54 @@
+Qualcomm adreno/snapdragon GMU (Graphics management unit)
+
+The GMU is a programmable power controller for the GPU. the CPU controls the
+GMU which in turn handles power controls for the GPU.
+
+Required properties:
+- compatible:
+ * "qcom,adreno-gmu"
+- reg: Physical base address and length of the GMU registers.
+- reg-names: Matching names for the register regions
+ * "gmu"
+ * "gmu_pdc"
+- interrupts: The interrupt signals from the GMU.
+- interrupt-names: Matching names for the interrupts
+ * "hfi"
+ * "gmu"
+- clocks: phandles to the device clocks
+- clock-names: Matching names for the clocks
+ * "gmu"
+ * "cxo"
+ * "axi"
+ * "mnoc"
+- power-domains: should be <_gpucc GPU_CX_GDSC>
+- iommus: phandle to the adreno iommu
+- operating-points-v2: phandle to the OPP operating points
+
+Example:
+
+/ {
+ ...
+
+ gmu: gmu@506a000 {
+ compatible="qcom,adreno-gmu";
+
+ reg = <0x506a000 0x3>,
+ <0xb20 0x30>;
+ reg-names = "gmu", "gmu_pdc";
+
+ interrupts = ,
+ ;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = <_gpucc GPU_CC_CX_GMU_CLK>,
+ <_gpucc GPU_CC_CXO_CLK>,
+ <_gcc GCC_DDRSS_GPU_AXI_CLK>,
+ <_gcc GCC_GPU_MEMNOC_GFX_CLK>;
+ clock-names = "gmu", "cxo", "axi", "memnoc";
+
+ power-domains = <_gpucc GPU_CX_GDSC>;
+ iommus = <_smmu 5>;
+
+ i operating-points-v2 = <_opp_table>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index 43fac0fe09bb..544a7510166b 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -8,12 +8,18 @@ Required properties:
with the chip-id.
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt signal from the gpu.
-- clocks: device clocks
+
+Optional properties.
+- clocks: device clocks. Required for a3xx, a4xx and a5xx targets. a6xx and
+ newer with a GMU attached do not have direct clock control from the CPU and
+ do not need to provide clock properties.
See ../clocks/clock-bindings.txt for details.
-- clock-names: the following clocks are required:
+- clock-names: the following clocks can be provided:
* "core"
* "iface"
* "mem_iface"
+- qcom,gmu: For a6xx and newer targets a phandle to the GMU device that will
+ control the power for the GPU
Example:
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm/msm/a6xx: Rename gmu phandle to qcom,gmu
From the review for the DT bindings for the GPU/GMU it was suggested that the phandle for the GMU be 'qcom,gmu' instead of just 'gmu' but that never actually got changed in the code. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index c629f742a1d1..9a14cb3d5027 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -799,7 +799,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev) } /* Check if there is a GMU phandle and set it up */ - node = of_parse_phandle(pdev->dev.of_node, "gmu", 0); + node = of_parse_phandle(pdev->dev.of_node, "qcom,gmu", 0); /* FIXME: How do we gracefully handle this? */ BUG_ON(!node); -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9] arm64: dts: Add interconnect for the GPU on SDM845
Add the interconnect properties for the GPU on SDM845
and set the corresponding OPP bandwidth values.
Signed-off-by: Jordan Crouse
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 10db0ceb3699..1e67f4fdd7d1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -198,36 +198,43 @@ gpu_opp_table: adreno-opp-table {
opp-71000 {
opp-hz = /bits/ 64 <71000>;
qcom,level = <416>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 721600>;
};
opp-67500 {
opp-hz = /bits/ 64 <67500>;
qcom,level = <384>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 721600>;
};
opp-59600 {
opp-hz = /bits/ 64 <59600>;
qcom,level = <320>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 518400>;
};
opp-52000 {
opp-hz = /bits/ 64 <52000>;
qcom,level = <256>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 406800>;
};
opp-41400 {
opp-hz = /bits/ 64 <41400>;
qcom,level = <192>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 307200>;
};
opp-34200 {
opp-hz = /bits/ 64 <34200>;
qcom,level = <128>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 218800>;
};
opp-25700 {
opp-hz = /bits/ 64 <25700>;
qcom,level = <64>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 12>;
};
};
@@ -418,6 +425,9 @@ gpu_opp_table: adreno-opp-table {
operating-points-v2 = <_opp_table>;
+ interconnects = < 26 512>;
+ interconnect-names = "port0";
+
qcom,gmu = <>;
};
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
Add the nodes to describe the Adreno GPU and GMU devices.
Signed-off-by: Jordan Crouse
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++
1 file changed, 121 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cdaabeb3c995..10db0ceb3699 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -192,6 +192,59 @@
method = "smc";
};
+gpu_opp_table: adreno-opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ opp-71000 {
+ opp-hz = /bits/ 64 <71000>;
+ qcom,level = <416>;
+ };
+
+ opp-67500 {
+ opp-hz = /bits/ 64 <67500>;
+ qcom,level = <384>;
+ };
+
+ opp-59600 {
+ opp-hz = /bits/ 64 <59600>;
+ qcom,level = <320>;
+ };
+
+ opp-52000 {
+ opp-hz = /bits/ 64 <52000>;
+ qcom,level = <256>;
+ };
+
+ opp-41400 {
+ opp-hz = /bits/ 64 <41400>;
+ qcom,level = <192>;
+ };
+
+ opp-34200 {
+ opp-hz = /bits/ 64 <34200>;
+ qcom,level = <128>;
+ };
+
+ opp-25700 {
+ opp-hz = /bits/ 64 <25700>;
+ qcom,level = <64>;
+ };
+ };
+
+ gmu_opp_table: adreno-gmu-opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ opp-4 {
+ opp-hz = /bits/ 64 <4>;
+ qcom,level = <128>;
+ };
+
+ opp-2 {
+ opp-hz = /bits/ 64 <2>;
+ qcom,level = <48>;
+ };
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -323,5 +376,73 @@
status = "disabled";
};
};
+
+ adreno_smmu: adreno-smmu@504 {
+ compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
+ reg = <0x504 0x1>;
+ #iommu-cells = <1>;
+ #global-interrupts = <2>;
+ interrupts = ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ;
+ clocks = < GCC_GPU_MEMNOC_GFX_CLK>,
+ < GCC_GPU_CFG_AHB_CLK>;
+ clock-names = "bus", "iface";
+
+ power-domains = < GPU_CX_GDSC>;
+ };
+
+ gpu@500 {
+ compatible = "qcom,adreno-630.2", "qcom,adreno";
+ #stream-id-cells = <16>;
+
+ reg = <0x500 0x4>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ /*
+* Look ma, no clocks! The GPU clocks and power are
+* controlled entirely by the GMU
+*/
+
+ interrupts = <0 300 0>;
+ interrupt-names = "kgsl_3d0_irq";
+
+ iommus = <_smmu 0>;
+
+ operating-points-v2 = <_opp_table>;
+
+ qcom,gmu = <>;
+ };
+
+ gmu: gmu@506a000 {
+ compatible="qcom,adreno-gmu";
+
+ reg = <0x506a000 0x3>,
+ <0xb28 0x1>,
+ <0xb48 0x1>;
+ reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+
+ interrupts = ,
+;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = < GPU_CC_CX_GMU_CLK>,
+ < GPU_CC_CXO_CLK>,
+ < GCC_DDRSS_GPU_AXI_CLK>,
+ < GCC_GPU_MEMNOC_GFX_CLK>;
+ clock-names = "gmu", "cxo", "axi", "memnoc";
+
+ power-domains = < GPU_CX_GDSC>;
+ iommus = <_smmu 5>;
+
+ operating-points-v2 = <_opp_table>;
+ };
};
};
--
2.18.0
___
dri-devel mailing list
[PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
Add the "opp-interconnect-bw" property to specify the
average and peak bandwidth for an interconnect path for
a specific operating power point. A separate bandwidth
pair can be specified for each of the interconnects
defined for the device by appending the interconnect
name to the property.
Signed-off-by: Jordan Crouse
---
Documentation/devicetree/bindings/opp/opp.txt | 36 +++
1 file changed, 36 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index c396c4c0af92..d714c084f36d 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -170,6 +170,11 @@ Optional properties:
functioning of the current device at the current OPP (where this property is
present).
+- opp-interconnect-bw-: This is an array of pairs specifying the average
+ and peak bandwidth in bytes per second for the interconnect path known by
+ 'name'. This should match the name(s) specified by interconnect-names in the
+ device definition.
+
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
/ {
@@ -543,3 +548,34 @@ Example 6: opp-microvolt-, opp-microamp-:
};
};
};
+
+Example 7: opp-interconnect-bw:
+(example: leaf device with frequency and BW quotas)
+
+/ {
+ soc {
+ gpu@500 {
+ ...
+ interconnects = < 26 512>;
+ interconnect-names = "port0";
+ ...
+ operating-points-v2 = <_opp_table>;
+ };
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp-71000 {
+ op-hz = /bits/ 64 <71000>;
+ /* Set peak bandwidth @ 7216000 KB/s */
+ opp-interconnect-bw-port0 = /bits/ 64 <0 721600>;
+ };
+
+ opp-21000 {
+ op-hz = /bits/ 64 <21000>;
+ /* Set peak bandwidth @ 120 KB/s */
+ opp-interconnect-bw-port0 = /bits/ 64 <0 12>;
+ };
+ };
+};
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/msm/a6xx: rnndb updates for a6xx
Update the register definitions for a6xx from the rnndb database.
Changes include new enums for upcoming devcoredump support, moving
the PDC and GCC_GX register definitions to their own domain and
various other register updates and additions.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 642 ++
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 26 +-
2 files changed, 416 insertions(+), 252 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
index 87eab51f7000..7acc57b2c1be 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -8,17 +8,17 @@ This file was generated by the rules-ng-ng headergen tool in
this git repository
git clone https://github.com/freedreno/envytools.git
The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/envytools/rnndb/adreno.xml (501 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/freedreno_copyright.xml ( 1572 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a2xx.xml ( 36805 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_common.xml ( 13634 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_pm4.xml( 42393 bytes,
from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a3xx.xml ( 83840 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a4xx.xml ( 112086 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a5xx.xml ( 147240 bytes,
from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx.xml ( 101627 bytes,
from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx_gmu.xml ( 10431 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/ocmem.xml ( 1773 bytes,
from 2018-07-03 19:37:13)
+- ./adreno.xml (501 bytes, from 2018-05-23 16:51:57)
+- ./freedreno_copyright.xml ( 1572 bytes, from 2016-10-24 21:12:27)
+- ./adreno/a2xx.xml ( 36805 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_common.xml ( 13634 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_pm4.xml( 42393 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a3xx.xml ( 83840 bytes, from 2017-12-05 18:20:27)
+- ./adreno/a4xx.xml ( 112086 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a5xx.xml ( 147240 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a6xx.xml ( 107521 bytes, from 2018-08-16 17:44:50)
+- ./adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-08-16 17:44:26)
+- ./adreno/ocmem.xml ( 1773 bytes, from 2016-10-24 21:12:27)
Copyright (C) 2013-2018 by the following authors:
- Rob Clark (robclark)
@@ -272,6 +272,98 @@ enum a6xx_cp_perfcounter_select {
PERF_CP_ALWAYS_COUNT = 0,
};
+enum a6xx_shader_id {
+ A6XX_TP0_TMO_DATA = 9,
+ A6XX_TP0_SMO_DATA = 10,
+ A6XX_TP0_MIPMAP_BASE_DATA = 11,
+ A6XX_TP1_TMO_DATA = 25,
+ A6XX_TP1_SMO_DATA = 26,
+ A6XX_TP1_MIPMAP_BASE_DATA = 27,
+ A6XX_SP_INST_DATA = 41,
+ A6XX_SP_LB_0_DATA = 42,
+ A6XX_SP_LB_1_DATA = 43,
+ A6XX_SP_LB_2_DATA = 44,
+ A6XX_SP_LB_3_DATA = 45,
+ A6XX_SP_LB_4_DATA = 46,
+ A6XX_SP_LB_5_DATA = 47,
+ A6XX_SP_CB_BINDLESS_DATA = 48,
+ A6XX_SP_CB_LEGACY_DATA = 49,
+ A6XX_SP_UAV_DATA = 50,
+ A6XX_SP_INST_TAG = 51,
+ A6XX_SP_CB_BINDLESS_TAG = 52,
+ A6XX_SP_TMO_UMO_TAG = 53,
+ A6XX_SP_SMO_TAG = 54,
+ A6XX_SP_STATE_DATA = 55,
+ A6XX_HLSQ_CHUNK_CVS_RAM = 73,
+ A6XX_HLSQ_CHUNK_CPS_RAM = 74,
+ A6XX_HLSQ_CHUNK_CVS_RAM_TAG = 75,
+ A6XX_HLSQ_CHUNK_CPS_RAM_TAG = 76,
+ A6XX_HLSQ_ICB_CVS_CB_BASE_TAG = 77,
+ A6XX_HLSQ_ICB_CPS_CB_BASE_TAG = 78,
+ A6XX_HLSQ_CVS_MISC_RAM = 80,
+ A6XX_HLSQ_CPS_MISC_RAM = 81,
+ A6XX_HLSQ_INST_RAM = 82,
+ A6XX_HLSQ_GFX_CVS_CONST_RAM = 83,
+ A6XX_HLSQ_GFX_CPS_CONST_RAM = 84,
+ A6XX_HLSQ_CVS_MISC_RAM_TAG = 85,
+ A6XX_HLSQ_CPS_MISC_RAM_TAG = 86,
+ A6XX_HLSQ_INST_RAM_TAG = 87,
+ A6XX_HLSQ_GFX_CVS_CONST_RAM_TAG = 88,
+ A6XX_HLSQ_GFX_CPS_CONST_RAM_TAG = 89,
+ A6XX_HLSQ_PWR_REST_RAM = 90,
+ A6XX_HLSQ_PWR_REST_TAG = 91,
+ A6XX_HLSQ_DATAPATH_META = 96,
+ A6XX_HLSQ_FRONTEND_META = 97,
+ A6XX_HLSQ_INDIRECT_META = 98,
+ A6XX_HLSQ_BACKEND_META = 99,
+};
+
+enum a6xx_debugbus_id {
+ A6XX_DBGBUS_CP = 1,
+ A6XX_DBGBUS_RBBM = 2,
+ A6XX_DBGBUS_VBIF = 3,
+ A6XX_DBGBUS_HLSQ = 4,
+ A6XX_DBGBUS_UCHE = 5,
+ A6XX_DBGBUS_DPM = 6,
+ A6XX_DBGBUS_TESS = 7,
+ A6XX_DBGBUS_PC = 8,
+ A6XX_DBGBUS_VFDP = 9,
+ A6XX_DBGBUS_VPC = 10,
+ A6XX_DBGBUS_TSE = 11,
+
[PATCH 2/9] drm/msm/a6xx: Fix PDC register overlap
The current design greedily takes a big chunk of the PDC
register space instead of just the GPU specific sections
which conflicts with other drivers and generally makes
a mess of things.
Furthermore we only need to map the GPU PDC sections
just once during init so map the memory inside the function
that uses it.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 87 ---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 6 --
2 files changed, 51 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index bbb8126ec5c5..d0dac4c2e3e7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -348,8 +348,23 @@ static void a6xx_rpmh_stop(struct a6xx_gmu *gmu)
gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 0);
}
+static inline void pdc_write(void __iomem *ptr, u32 offset, u32 value)
+{
+ return msm_writel(value, ptr + (offset << 2));
+}
+
+static void __iomem *a6xx_gmu_get_mmio(struct platform_device *pdev,
+ const char *name);
+
static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
{
+ struct platform_device *pdev = to_platform_device(gmu->dev);
+ void __iomem *pdcptr = a6xx_gmu_get_mmio(pdev, "gmu_pdc");
+ void __iomem *seqptr = a6xx_gmu_get_mmio(pdev, "gmu_pdc_seq");
+
+ if (!pdcptr || !seqptr)
+ goto err;
+
/* Disable SDE clock gating */
gmu_write(gmu, REG_A6XX_GPU_RSCC_RSC_STATUS0_DRV0, BIT(24));
@@ -374,44 +389,48 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
gmu_write(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 4, 0x0020e8a8);
/* Load PDC sequencer uCode for power up and power down sequence */
- pdc_write(gmu, REG_A6XX_PDC_GPU_SEQ_MEM_0, 0xfebea1e1);
- pdc_write(gmu, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 1, 0xa5a4a3a2);
- pdc_write(gmu, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 2, 0x8382a6e0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 3, 0xbce3e284);
- pdc_write(gmu, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 4, 0x002081fc);
+ pdc_write(seqptr, REG_A6XX_PDC_GPU_SEQ_MEM_0, 0xfebea1e1);
+ pdc_write(seqptr, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 1, 0xa5a4a3a2);
+ pdc_write(seqptr, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 2, 0x8382a6e0);
+ pdc_write(seqptr, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 3, 0xbce3e284);
+ pdc_write(seqptr, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 4, 0x002081fc);
/* Set TCS commands used by PDC sequence for low power modes */
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD_ENABLE_BANK, 7);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD_WAIT_FOR_CMPL_BANK, 0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CONTROL, 0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR, 0x30010);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA, 1);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID + 4, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR + 4, 0x3);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA + 4, 0x0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID + 8, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR + 8, 0x30080);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA + 8, 0x0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD_ENABLE_BANK, 7);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD_WAIT_FOR_CMPL_BANK, 0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CONTROL, 0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR, 0x30010);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA, 2);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID + 4, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR + 4, 0x3);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA + 4, 0x3);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID + 8, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR + 8, 0x30080);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA + 8, 0x3);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD_ENABLE_BANK, 7);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD_WAIT_FOR_CMPL_BANK, 0);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CONTROL, 0);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID, 0x10108);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR, 0x30010);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA, 1);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID + 4, 0x10108);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR + 4, 0x3);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA + 4, 0x0);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID + 8, 0x10108);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR + 8, 0x30080);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA + 8, 0x0);
+
[PATCH 0/9] Add interconnect support + bindings for A630 GPU
This patch series is a first stab at trying to add interconnect support for the Adreno 630 GPU in the sdm845 SOC. The most interesting thing for discussion is the OPP binding for specifying bandwidth - once that is worked out the actual code to implement it is pretty straight forward thanks to the hard work from Georgi and the PM lists. The first 5 patches are are just a sync / reminder of the still pending DT bindings and entries for the GPU itself - the interconnect folks can refer to them as a reference to see what the GPU nodes will look like but I suspect they are of more interest for the GPU. Patch 6 adds a proposed binding to specify the interconnect avg/peak BW for a given operating point. On devices that can do aggressive frequency scaling like the GPU we want to be able to set a peak bandwidth along with the frequency so that we can make sure that the bus can handle a faster GPU frequency if we scale up but also to reduce power consumption on the bus when we scale down. The proposed binding uses the form: opp-interconnect-bw- = Where 'name' is the corresponding interconnect-name of the interested path and 'avg' and 'peak' are the average and peak bandwidth values in HZ to program for the operating point. The path name is used to identify path specific settings for devices that may have multiple active interconnect paths. The next patch adds a generic OPP API to read the interconnect values given a operating point and a name. The 8th patch adds code support for an interconnect path to the for the a6xx GPU reading the bandwidth for the operating point from the OPP API. And the final patch adds the actual interconnect details the device tree specifying both the interconnect details as well as the bandwidth requirements for each of the operating points on the a630 GPU. Jordan Crouse (9): drm/msm/a6xx: rnndb updates for a6xx drm/msm/a6xx: Fix PDC register overlap drm/msm/a6xx: Rename gmu phandle to qcom,gmu dt-bindings: Document qcom,adreno-gmu arm64: dts: sdm845: Add gpu and gmu device nodes PM / OPP: dt-bindings: Add opp-interconnect-bw OPP: Add dev_pm_opp_get_interconnect_bw() drm/msm/a6xx: Add support for an interconnect path arm64: dts: Add interconnect for the GPU on SDM845 .../devicetree/bindings/display/msm/gmu.txt | 54 ++ .../devicetree/bindings/display/msm/gpu.txt | 10 +- Documentation/devicetree/bindings/opp/opp.txt | 36 + arch/arm64/boot/dts/qcom/sdm845.dtsi | 131 drivers/gpu/drm/msm/adreno/a6xx.xml.h | 642 +++--- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 114 ++-- drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 6 - drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 26 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 7 + drivers/gpu/drm/msm/msm_gpu.h | 3 + drivers/opp/of.c | 36 + include/linux/pm_opp.h| 7 + 13 files changed, 775 insertions(+), 299 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107655] X segfaults on startup in r300_dri.so, making system unusable
https://bugs.freedesktop.org/show_bug.cgi?id=107655 Michel Dänzer changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Status|RESOLVED|REOPENED QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r300|Drivers/Gallium/swr Resolution|NOTOURBUG |--- --- Comment #5 from Michel Dänzer --- (In reply to Sergey Kondakov from comment #4) > I don't know the actual reason of the crash but the guys there figured out > that > the crash was coming from AVX instruction in Mesa's SWR code. The affected > machine does not support any kind of AVX, so it threw out the error. But it's > unclear why SWR even been trying to initialize during the load of r300_dri. I think it's the combination of two things: * All Gallium drivers are linked into a single binary (so-called mega-driver) * SWR is compiled with AVX support and has initializers which are automatically executed when the above binary is dlopen()ed. Until there's a solution for this, SWR cannot be enabled in a build which has to run on non-AVX capable CPUs. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107696] account request for drm-misc
https://bugs.freedesktop.org/show_bug.cgi?id=107696 --- Comment #3 from Daniel Vetter --- https://dri.freedesktop.org/docs/dim/getting-started.html ... the fairly extensive documentation Daniel was talking about. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107655] X segfaults on startup in r300_dri.so, making system unusable
https://bugs.freedesktop.org/show_bug.cgi?id=107655
Sergey Kondakov changed:
What|Removed |Added
URL||https://bugzilla.opensuse.o
||rg/show_bug.cgi?id=1105608
--- Comment #4 from Sergey Kondakov ---
(In reply to Michel Dänzer from comment #3)
> GCC's libstdc++ code crashes trying to use an instruction not supported by
> your CPU. You need to report this to your distro.
So, I've bothered my distro's bugzilla, and gcc's, then figured out why it was
crashing: Mesa doesn't like being built with clang/gold and ThinLTO (Mesa
doesn't build via gcc with LTO and openSUSE's OBS can't handle gcc's LTO
implementation even if it would). I don't know the actual reason of the crash
but the guys there figured out that the crash was coming from AVX instruction
in Mesa's SWR code. The affected machine does not support any kind of AVX, so
it threw out the error. But it's unclear why SWR even been trying to initialize
during the load of r300_dri. If built without any {C,LD}FLAGS and with gcc,
nothing crashes even with SWR built and installed. And there is no trace of SWR
doing things at boot on AVX-capable amdgpu/radeonsi machine even with clang's
build.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PL111 regression in v4.19-rc1
Den 27.08.2018 14.43, skrev Linus Walleij: On Mon, Aug 27, 2018 at 2:21 PM Noralf Trønnes wrote: This is one suspect: 894a677f4b3e drm/cma-helper: Use the generic fbdev emulation This doesn't revert cleanly so I couldn't try that right off. But the graphics do work before this commit. I checked out the kernel tree on this commit and it just fails to create the framebuffer with no messages whatsoever: versatile-tft-panel 1000.sysreg:display@0: no panel detected drm-clcd-pl111 dev:20: set up callbacks for Versatile PL110 drm-clcd-pl111 dev:20: found bridge on endpoint 1 drm-clcd-pl111 dev:20: Using non-panel bridge [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. [drm] Initialized pl111 1.0.0 20170317 for dev:20 on minor 0 I guess this somehow broke it, then some more stuff down the road made the damage more visible. I'm trying to see if I can fix it, any hints welcome! I had time to look closer at this, and I don't think the fbdev change is to blame. I think it's just that the problem shows up there because it's the first to allocate a buffer. If the DRM side doesn't work either, I guess the problem lies elsewhere. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107696] account request for drm-misc
https://bugs.freedesktop.org/show_bug.cgi?id=107696 Daniel Stone changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Daniel Stone --- I've created your account now, so you should be able to use dim to push to drm-misc in the next 5-10 minutes. dim comes with pretty extensive documentation on the workflow within DRM and how to push new trees. The account request was missing most of the requested information, so I guessed a username of 'hverkuil' and forwarding address of hverk...@xs4all.nl. Hope that's correct. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107518] polaris powerplay init fails: There must be 1 or more PCIE levels defined in PPTable
https://bugs.freedesktop.org/show_bug.cgi?id=107518 --- Comment #10 from Alex Deucher --- Does this patch help? https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next=8242308cc3c4419832126ab78ca409ce7110ab33 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PL111 regression in v4.19-rc1
On Mon, Aug 27, 2018 at 2:43 PM Linus Walleij wrote: > I'm trying to see if I can fix it, any hints welcome! BTW this is pretty easy to reproduce in QEMU using a cross compilers: I realized we were missing the VGA DAC when testing this... make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- versatile_defconfig scripts/config --file .config --enable DRM_DUMB_VGA_DAC make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- zImage make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- dtbs qemu-system-arm -M versatileab -no-reboot -kernel arch/arm/boot/zImage -dtb arch/arm/boot/dts/versatile-ab.dtb -append "console=ttyAMA0" -serial stdio -initrd rootfs-versatile.cpio The initramfs/initrd is here: https://dflund.se/~triad/krad/versatile/rootfs-versatile.cpio I'm using this cross-compiler: https://releases.linaro.org/components/toolchain/binaries/latest/arm-linux-gnueabihf/ This requires a reasonably recent QEMU which I extended with the vblank emulation a while back. (If you don't have that the machine hangs waiting for vblank for a long time in the DRM init.) I get graphics on v4.18 and the commit preceeding this one. It fails on v4.19-rc1. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/i915: preparations for enabling P010, P012, P016 formats
On 27.08.2018 14:28, Maarten Lankhorst wrote:
Op 16-08-18 om 14:55 schreef Juha-Pekka Heikkila:
Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 3 +-
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 46 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 19 ++---
drivers/gpu/drm/i915/intel_sprite.c | 18 +++-
6 files changed, 69 insertions(+), 20 deletions(-)
For patches 2, 3, 4:
Acked-by: Jani Nikula #irc, for merging through
drm-misc-next.
Are you ok with Swati Sharma's comment on patch 4? I can fix it up when
committing.
I'm all ok with Swati Sharma's comment.
/Juha-Pekka
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index b04952b..ab76b72 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -334,8 +334,7 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
/* set scaler mode */
if ((INTEL_GEN(dev_priv) >= 9) &&
plane_state && plane_state->base.fb &&
- plane_state->base.fb->format->format ==
- DRM_FORMAT_NV12) {
+ is_planar_yuv_format(plane_state->base.fb->format->format))
{
if (INTEL_GEN(dev_priv) == 9 &&
!IS_GEMINILAKE(dev_priv) &&
!IS_SKYLAKE(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index dcba645..58b2fc6 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -182,7 +182,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
else
crtc_state->active_planes &= ~BIT(intel_plane->id);
- if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
+ if (state->visible && is_planar_yuv_format(state->fb->format->format))
crtc_state->nv12_planes |= BIT(intel_plane->id);
else
crtc_state->nv12_planes &= ~BIT(intel_plane->id);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 690e1e8..80ce742 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2667,6 +2667,12 @@ int skl_format_to_fourcc(int format, bool rgb_order,
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_P010:
+ return DRM_FORMAT_P010;
+ case PLANE_CTL_FORMAT_P012:
+ return DRM_FORMAT_P012;
+ case PLANE_CTL_FORMAT_P016:
+ return DRM_FORMAT_P016;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3182,7 +3188,7 @@ int skl_check_plane_surface(const struct intel_crtc_state
*crtc_state,
* Handle the AUX surface first since
* the main surface setup depends on it.
*/
- if (fb->format->format == DRM_FORMAT_NV12) {
+ if (is_planar_yuv_format(fb->format->format)) {
ret = skl_check_nv12_surface(crtc_state, plane_state);
if (ret)
return ret;
@@ -3507,6 +3513,12 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_P010:
+ return PLANE_CTL_FORMAT_P010;
+ case DRM_FORMAT_P012:
+ return PLANE_CTL_FORMAT_P012;
+ case DRM_FORMAT_P016:
+ return PLANE_CTL_FORMAT_P016;
default:
MISSING_CASE(pixel_format);
}
@@ -4808,8 +4820,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
need_scaling = src_w != dst_w || src_h != dst_h;
if (plane_scaler_check)
- if (pixel_format == DRM_FORMAT_NV12)
- need_scaling = true;
+ need_scaling = is_planar_yuv_format(pixel_format);
if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
need_scaling = true;
@@ -4850,7 +4861,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
return 0;
}
- if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12 &&
+ if (plane_scaler_check && is_planar_yuv_format(pixel_format) &&
(src_h < SKL_MIN_YUV_420_SRC_H || src_w < SKL_MIN_YUV_420_SRC_W)) {
DRM_DEBUG_KMS("NV12: src dimensions not met\n");
Re: [PATCH 3/3] mach64: optimize wait_for_fifo
On Sat, Aug 25, 2018 at 03:54:17PM -0400, Mikulas Patocka wrote:
> This is a simple optimization for fifo waiting that improves scrolling
> performance by 5%. If the queue has more free entries that what we
> consume, we can skip the costly register read next time.
>
> Signed-off-by: Mikulas Patocka
>
> ---
> drivers/video/fbdev/aty/atyfb.h| 12
> drivers/video/fbdev/aty/mach64_accel.c |4 +++-
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> Index: linux-stable/drivers/video/fbdev/aty/atyfb.h
> ===
> --- linux-stable.orig/drivers/video/fbdev/aty/atyfb.h 2018-08-25
> 21:49:16.0 +0200
> +++ linux-stable/drivers/video/fbdev/aty/atyfb.h 2018-08-25
> 21:52:51.0 +0200
> @@ -147,6 +147,7 @@ struct atyfb_par {
> u16 pci_id;
> u32 accel_flags;
> int blitter_may_be_busy;
> + unsigned fifo_space;
> int asleep;
> int lock_blank;
> unsigned long res_start;
> @@ -346,10 +347,13 @@ extern int aty_init_cursor(struct fb_inf
> * Hardware acceleration
> */
>
> -static inline void wait_for_fifo(u16 entries, const struct atyfb_par *par)
> +static inline void wait_for_fifo(u16 entries, struct atyfb_par *par)
> {
> - while ((aty_ld_le32(FIFO_STAT, par) & 0x) >
> -((u32) (0x8000 >> entries)));
> + unsigned fifo_space = par->fifo_space;
> + while (entries > fifo_space) {
> + fifo_space = 16 - fls(aty_ld_le32(FIFO_STAT, par) & 0x);
I don't recall off hand which way this register works, but based
on the existing code this looks correct.
Reviewed-by: Ville Syrjälä
> + }
> + par->fifo_space = fifo_space - entries;
> }
>
> static inline void wait_for_idle(struct atyfb_par *par)
> @@ -359,7 +363,7 @@ static inline void wait_for_idle(struct
> par->blitter_may_be_busy = 0;
> }
>
> -extern void aty_reset_engine(const struct atyfb_par *par);
> +extern void aty_reset_engine(struct atyfb_par *par);
> extern void aty_init_engine(struct atyfb_par *par, struct fb_info *info);
>
> void atyfb_copyarea(struct fb_info *info, const struct fb_copyarea *area);
> Index: linux-stable/drivers/video/fbdev/aty/mach64_accel.c
> ===
> --- linux-stable.orig/drivers/video/fbdev/aty/mach64_accel.c 2018-08-25
> 21:49:16.0 +0200
> +++ linux-stable/drivers/video/fbdev/aty/mach64_accel.c 2018-08-25
> 21:49:16.0 +0200
> @@ -37,7 +37,7 @@ static u32 rotation24bpp(u32 dx, u32 dir
> return ((rotation << 8) | DST_24_ROTATION_ENABLE);
> }
>
> -void aty_reset_engine(const struct atyfb_par *par)
> +void aty_reset_engine(struct atyfb_par *par)
> {
> /* reset engine */
> aty_st_le32(GEN_TEST_CNTL,
> @@ -50,6 +50,8 @@ void aty_reset_engine(const struct atyfb
> /* HOST errors */
> aty_st_le32(BUS_CNTL,
> aty_ld_le32(BUS_CNTL, par) | BUS_HOST_ERR_ACK |
> BUS_FIFO_ERR_ACK, par);
> +
> + par->fifo_space = 0;
> }
>
> static void reset_GTC_3D_engine(const struct atyfb_par *par)
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] mach64: fix image corruption due to reading accelerator registers
On Sat, Aug 25, 2018 at 03:51:52PM -0400, Mikulas Patocka wrote:
> Reading the registers without waiting for engine idle returns
> unpredictable values. These unpredictable values result in display
> corruption - if atyfb_imageblit reads the content of DP_PIX_WIDTH with the
> bit DP_HOST_TRIPLE_EN set (from previous invocation), the driver would
> never ever clear the bit, resulting in display corruption.
>
> We don't want to wait for idle because it would degrade performance, so
> this patch modifies the driver so that it never reads accelerator
> registers.
>
> HOST_CNTL doesn't have to be read, we can just write it with
> HOST_BYTE_ALIGN because no other part of the driver cares if
> HOST_BYTE_ALIGN is set.
>
> DP_PIX_WIDTH is written in the functions atyfb_copyarea and atyfb_fillrect
> with the default value and in atyfb_imageblit with the value set according
> to the source image data.
>
> Signed-off-by: Mikulas Patocka
> Cc: sta...@vger.kernel.org
>
> ---
> drivers/video/fbdev/aty/mach64_accel.c | 22 +-
> 1 file changed, 9 insertions(+), 13 deletions(-)
>
> Index: linux-stable/drivers/video/fbdev/aty/mach64_accel.c
> ===
> --- linux-stable.orig/drivers/video/fbdev/aty/mach64_accel.c 2018-08-24
> 19:51:34.0 +0200
> +++ linux-stable/drivers/video/fbdev/aty/mach64_accel.c 2018-08-24
> 20:28:55.0 +0200
> @@ -127,7 +127,7 @@ void aty_init_engine(struct atyfb_par *p
>
> /* set host attributes */
> wait_for_fifo(13, par);
> - aty_st_le32(HOST_CNTL, 0, par);
> + aty_st_le32(HOST_CNTL, HOST_BYTE_ALIGN, par);
>
> /* set pattern attributes */
> aty_st_le32(PAT_REG0, 0, par);
> @@ -233,7 +233,8 @@ void atyfb_copyarea(struct fb_info *info
> rotation = rotation24bpp(dx, direction);
> }
>
> - wait_for_fifo(4, par);
> + wait_for_fifo(5, par);
> + aty_st_le32(DP_PIX_WIDTH, par->crtc.dp_pix_width, par);
> aty_st_le32(DP_SRC, FRGD_SRC_BLIT, par);
> aty_st_le32(SRC_Y_X, (sx << 16) | sy, par);
> aty_st_le32(SRC_HEIGHT1_WIDTH1, (width << 16) | area->height, par);
> @@ -269,7 +270,8 @@ void atyfb_fillrect(struct fb_info *info
> rotation = rotation24bpp(dx, DST_X_LEFT_TO_RIGHT);
> }
>
> - wait_for_fifo(3, par);
> + wait_for_fifo(4, par);
> + aty_st_le32(DP_PIX_WIDTH, par->crtc.dp_pix_width, par);
> aty_st_le32(DP_FRGD_CLR, color, par);
> aty_st_le32(DP_SRC,
> BKGD_SRC_BKGD_CLR | FRGD_SRC_FRGD_CLR | MONO_SRC_ONE,
> @@ -284,7 +286,7 @@ void atyfb_imageblit(struct fb_info *inf
> {
> struct atyfb_par *par = (struct atyfb_par *) info->par;
> u32 src_bytes, dx = image->dx, dy = image->dy, width = image->width;
> - u32 pix_width_save, pix_width, host_cntl, rotation = 0, src, mix;
> + u32 pix_width, rotation = 0, src, mix;
>
> if (par->asleep)
> return;
> @@ -296,8 +298,7 @@ void atyfb_imageblit(struct fb_info *inf
> return;
> }
>
> - pix_width = pix_width_save = aty_ld_le32(DP_PIX_WIDTH, par);
> - host_cntl = aty_ld_le32(HOST_CNTL, par) | HOST_BYTE_ALIGN;
> + pix_width = par->crtc.dp_pix_width;
>
> switch (image->depth) {
> case 1:
> @@ -370,12 +371,11 @@ void atyfb_imageblit(struct fb_info *inf
> mix = FRGD_MIX_D_XOR_S | BKGD_MIX_D;
> }
>
> - wait_for_fifo(6, par);
> - aty_st_le32(DP_WRITE_MASK, 0x, par);
Looks like init_engine() sets this one for us. So dropping should be ok.
> + wait_for_fifo(5, par);
> aty_st_le32(DP_PIX_WIDTH, pix_width, par);
> aty_st_le32(DP_MIX, mix, par);
> aty_st_le32(DP_SRC, src, par);
> - aty_st_le32(HOST_CNTL, host_cntl, par);
> + aty_st_le32(HOST_CNTL, HOST_BYTE_ALIGN, par);
Presumably we could drop this as well since it never changes.
Either way
Reviewed-by: Ville Syrjälä
> aty_st_le32(DST_CNTL, DST_Y_TOP_TO_BOTTOM | DST_X_LEFT_TO_RIGHT |
> rotation, par);
>
> draw_rect(dx, dy, width, image->height, par);
> @@ -424,8 +424,4 @@ void atyfb_imageblit(struct fb_info *inf
> aty_st_le32(HOST_DATA0, get_unaligned_le32(pbitmap),
> par);
> }
> }
> -
> - /* restore pix_width */
> - wait_for_fifo(1, par);
> - aty_st_le32(DP_PIX_WIDTH, pix_width_save, par);
> }
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] mach64: fix display corruption on big endian machines
On Sat, Aug 25, 2018 at 03:51:00PM -0400, Mikulas Patocka wrote:
> The code for manual bit triple is not endian-clean. It builds the variable
> "hostdword" using byte accesses, therefore we must read the variable with
> "le32_to_cpu".
>
> The patch also enables (hardware or software) bit triple only if the image
> is monochrome (image->depth). If we want to blit full-color image, we
> shouldn't use the triple code.
Makes sense.
Reviewed-by: Ville Syrjälä
>
> Signed-off-by: Mikulas Patocka
> Cc: sta...@vger.kernel.org
>
> ---
> drivers/video/fbdev/aty/mach64_accel.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: linux-stable/drivers/video/fbdev/aty/mach64_accel.c
> ===
> --- linux-stable.orig/drivers/video/fbdev/aty/mach64_accel.c 2018-08-24
> 17:31:21.0 +0200
> +++ linux-stable/drivers/video/fbdev/aty/mach64_accel.c 2018-08-24
> 19:12:40.0 +0200
> @@ -345,7 +345,7 @@ void atyfb_imageblit(struct fb_info *inf
>* since Rage 3D IIc we have DP_HOST_TRIPLE_EN bit
>* this hwaccelerated triple has an issue with not aligned data
>*/
> - if (M64_HAS(HW_TRIPLE) && image->width % 8 == 0)
> + if (image->depth == 1 && M64_HAS(HW_TRIPLE) && image->width % 8
> == 0)
> pix_width |= DP_HOST_TRIPLE_EN;
> }
>
> @@ -382,7 +382,7 @@ void atyfb_imageblit(struct fb_info *inf
> src_bytes = (((image->width * image->depth) + 7) / 8) * image->height;
>
> /* manual triple each pixel */
> - if (info->var.bits_per_pixel == 24 && !(pix_width & DP_HOST_TRIPLE_EN))
> {
> + if (image->depth == 1 && info->var.bits_per_pixel == 24 && !(pix_width
> & DP_HOST_TRIPLE_EN)) {
> int inbit, outbit, mult24, byte_id_in_dword, width;
> u8 *pbitmapin = (u8*)image->data, *pbitmapout;
> u32 hostdword;
> @@ -415,7 +415,7 @@ void atyfb_imageblit(struct fb_info *inf
> }
> }
> wait_for_fifo(1, par);
> - aty_st_le32(HOST_DATA0, hostdword, par);
> + aty_st_le32(HOST_DATA0, le32_to_cpu(hostdword), par);
> }
> } else {
> u32 *pbitmap, dwords = (src_bytes + 3) / 4;
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PL111 regression in v4.19-rc1
On Mon, Aug 27, 2018 at 2:21 PM Noralf Trønnes wrote: > This is one suspect: 894a677f4b3e > drm/cma-helper: Use the generic fbdev emulation This doesn't revert cleanly so I couldn't try that right off. But the graphics do work before this commit. I checked out the kernel tree on this commit and it just fails to create the framebuffer with no messages whatsoever: versatile-tft-panel 1000.sysreg:display@0: no panel detected drm-clcd-pl111 dev:20: set up callbacks for Versatile PL110 drm-clcd-pl111 dev:20: found bridge on endpoint 1 drm-clcd-pl111 dev:20: Using non-panel bridge [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. [drm] Initialized pl111 1.0.0 20170317 for dev:20 on minor 0 I guess this somehow broke it, then some more stuff down the road made the damage more visible. I'm trying to see if I can fix it, any hints welcome! Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/2] drm/panel: Add support for Truly NT35597 panel driver
Hi Abhinav,
I have a few comments below.
On Fri, 2018-08-17 at 19:06 -0700, Abhinav Kumar wrote:
> From: "abhin...@codeaurora.org"
>
> Add support for Truly NT35597 panel driver used
> in MSM reference platforms.
>
> This panel driver supports both single DSI and dual DSI
> modes.
>
> However, this patch series adds support only for
> dual DSI mode.
>
> Changes in v6:
> - Introduce panel config to store panel specific
> details
> - Bring back the size member for the panel command
> structure to make the design more scalable
> - Move the display mode from the DT to driver
> - Change the compatible string to indicate which
> which board and panel it will be used for
> - Rename the functions to match the panel driver
> - Have a data member for each compatible string
> - Remove the panel commands split as its not
> required for the panel init functionality
>
> Signed-off-by: Archit Taneja
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/panel/Kconfig | 8 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 705
>
> 3 files changed, 714 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 6020c30..7ae74c2 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -186,4 +186,12 @@ config DRM_PANEL_SITRONIX_ST7789V
> Say Y here if you want to enable support for the Sitronix
> ST7789V controller for 240x320 LCD panels
>
> +config DRM_PANEL_TRULY_NT35597_WQXGA
> + tristate "Truly WQXGA"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
> + help
> + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual
> DSI
> + Video Mode panel
> endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 5ccaaa9..80fd19f 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) +=
> panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
> diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
> b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> new file mode 100644
> index 000..691be03
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
> @@ -0,0 +1,705 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +static const char * const regulator_names[] = {
> + "vdda",
> + "vdispp",
> + "vdispn",
> +};
> +
> +static unsigned long const regulator_enable_loads[] = {
> + 62000,
> + 10,
> + 10,
> +};
> +
> +static unsigned long const regulator_disable_loads[] = {
> + 80,
> + 100,
> + 100,
> +};
> +
> +struct nt35597_config {
> + u32 width_mm;
> + u32 height_mm;
> + char panel_name[256];
Why not
const char *panel_name;
?
> + void *panel_on_cmds;
const void *panel_on_cmds;
> + u32 num_on_cmds;
> + struct drm_display_mode *dm;
const struct drm_display_mode *dm;
> +};
> +
> +struct truly_nt35597 {
> + struct device *dev;
> + struct drm_panel panel;
> +
> + struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
> +
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *mode_gpio;
> +
> + struct backlight_device *backlight;
> +
> + struct mipi_dsi_device *dsi[2];
> +
> + const struct nt35597_config *config;
> + bool prepared;
> + bool enabled;
> +};
> +
> +static inline struct truly_nt35597 *panel_to_ctx(struct drm_panel *panel)
> +{
> + return container_of(panel, struct truly_nt35597, panel);
> +}
> +
> +#define MAX_LEN 5
> +#define SHORT_PACKET 2
> +#define LONG_PACKET 4
> +
> +struct cmd_set {
> + u8 commands[MAX_LEN];
> + int size;
Consider changing this to
u8 size;
> +};
> +
> +static struct cmd_set qcom_2k_panel_magic_cmds[] = {
> + /* CMD2_P0 */
[...]
> + /* VBP+VSA=,VFP = 10H */
> + { { 0x3B, 0x03, 0x0A, 0x0A }, 4 },
> + /* FTE on */
> + { { 0x35, 0x00 }, 2 },
> + /* EN_BK =1(auto black) */
> + { { 0xE5, 0x01 }, 2 },
> + /* CMD mode(10) VDO mode(03) */
> + { { 0xBB, 0x03 }, 2 },
> + /* Non Reload MTP */
> + { { 0xFB, 0x01 }, 2 },
> +};
> +
> +static int truly_dcs_write(struct drm_panel *panel, u32 command)
> +{
> + struct truly_nt35597 *ctx
[PATCH] drm/i2c/tda9950.c: set MAX_RETRIES for errors only
The CEC_TX_STATUS_MAX_RETRIES should be set for errors only to prevent the CEC framework from retrying the transmit. If the transmit was successful, then don't set this flag. Found by running 'cec-compliance -A' on a beaglebone box. Signed-off-by: Hans Verkuil --- drivers/gpu/drm/i2c/tda9950.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c index 5d2f0d548469..4a14fc3b5011 100644 --- a/drivers/gpu/drm/i2c/tda9950.c +++ b/drivers/gpu/drm/i2c/tda9950.c @@ -191,7 +191,8 @@ static irqreturn_t tda9950_irq(int irq, void *data) break; } /* TDA9950 executes all retries for us */ - tx_status |= CEC_TX_STATUS_MAX_RETRIES; + if (tx_status != CEC_TX_STATUS_OK) + tx_status |= CEC_TX_STATUS_MAX_RETRIES; cec_transmit_done(priv->adap, tx_status, arb_lost_cnt, nack_cnt, 0, err_cnt); break; -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: PL111 regression in v4.19-rc1
Hi Linus, Den 27.08.2018 14.12, skrev Linus Walleij: Hi folks, I'm seeing this on all PL111 systems (several ARM reference designs and Nomadik) with v4.19-rc1: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. [ cut here ] WARNING: CPU: 0 PID: 1 at ../include/linux/dma-mapping.h:516 drm_gem_cma_create+0x13c/0x158 Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0+ #135 Hardware name: ARM-Versatile (Device Tree Support) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (__warn+0xcc/0xf4) [] (__warn) from [] (warn_slowpath_null+0x3c/0x48) [] (warn_slowpath_null) from [] (drm_gem_cma_create+0x13c/0x158) [] (drm_gem_cma_create) from [] (drm_fbdev_cma_create+0x58/0x248) [] (drm_fbdev_cma_create) from [] (__drm_fb_helper_initial_config_and_unlock+0x1c8/0x450) [] (__drm_fb_helper_initial_config_and_unlock) from [] (drm_fb_cma_fbdev_init_with_funcs+0x8c/0x114) [] (drm_fb_cma_fbdev_init_with_funcs) from [] (pl111_amba_probe+0x3c8/0x4a4) [] (pl111_amba_probe) from [] (amba_probe+0xd8/0x154) [] (amba_probe) from [] (driver_probe_device+0x25c/0x310) [] (driver_probe_device) from [] (__driver_attach+0xd0/0xd4) [] (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4) [] (bus_for_each_dev) from [] (bus_add_driver+0x170/0x204) [] (bus_add_driver) from [] (driver_register+0x74/0x108) [] (driver_register) from [] (do_one_initcall+0x48/0x1a0) [] (do_one_initcall) from [] (kernel_init_freeable+0x104/0x1c4) [] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0) [] (kernel_init) from [] (ret_from_fork+0x14/0x34) Exception stack(0xc781ffb0 to 0xc781fff8) ffa0: ffc0: ffe0: 0013 ---[ end trace 63124893aa47fae0 ]--- drm-clcd-pl111 dev:20: coherent DMA mask is unset drm-clcd-pl111 dev:20: [drm:drm_fb_cma_fbdev_init_with_funcs] *ERROR* Failed to set fbdev configuration. [drm] Initialized pl111 1.0.0 20170317 for dev:20 on minor 0 I am trying to bisect but it is really painful because the kernel simply does not compile on a lot of bisect points :( This is one suspect: 894a677f4b3e drm/cma-helper: Use the generic fbdev emulation Noralf. Any hints? Eric is PL111 working for you? Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
PL111 regression in v4.19-rc1
Hi folks, I'm seeing this on all PL111 systems (several ARM reference designs and Nomadik) with v4.19-rc1: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] No driver support for vblank timestamp query. [ cut here ] WARNING: CPU: 0 PID: 1 at ../include/linux/dma-mapping.h:516 drm_gem_cma_create+0x13c/0x158 Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 4.18.0+ #135 Hardware name: ARM-Versatile (Device Tree Support) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (__warn+0xcc/0xf4) [] (__warn) from [] (warn_slowpath_null+0x3c/0x48) [] (warn_slowpath_null) from [] (drm_gem_cma_create+0x13c/0x158) [] (drm_gem_cma_create) from [] (drm_fbdev_cma_create+0x58/0x248) [] (drm_fbdev_cma_create) from [] (__drm_fb_helper_initial_config_and_unlock+0x1c8/0x450) [] (__drm_fb_helper_initial_config_and_unlock) from [] (drm_fb_cma_fbdev_init_with_funcs+0x8c/0x114) [] (drm_fb_cma_fbdev_init_with_funcs) from [] (pl111_amba_probe+0x3c8/0x4a4) [] (pl111_amba_probe) from [] (amba_probe+0xd8/0x154) [] (amba_probe) from [] (driver_probe_device+0x25c/0x310) [] (driver_probe_device) from [] (__driver_attach+0xd0/0xd4) [] (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4) [] (bus_for_each_dev) from [] (bus_add_driver+0x170/0x204) [] (bus_add_driver) from [] (driver_register+0x74/0x108) [] (driver_register) from [] (do_one_initcall+0x48/0x1a0) [] (do_one_initcall) from [] (kernel_init_freeable+0x104/0x1c4) [] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0) [] (kernel_init) from [] (ret_from_fork+0x14/0x34) Exception stack(0xc781ffb0 to 0xc781fff8) ffa0: ffc0: ffe0: 0013 ---[ end trace 63124893aa47fae0 ]--- drm-clcd-pl111 dev:20: coherent DMA mask is unset drm-clcd-pl111 dev:20: [drm:drm_fb_cma_fbdev_init_with_funcs] *ERROR* Failed to set fbdev configuration. [drm] Initialized pl111 1.0.0 20170317 for dev:20 on minor 0 I am trying to bisect but it is really painful because the kernel simply does not compile on a lot of bisect points :( Any hints? Eric is PL111 working for you? Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v4] drm/i915: Re-apply "Perform link quality check, unconditionally during long pulse"
On Sat, Aug 25, 2018 at 03:10:35PM -0400, Lyude Paul wrote:
> From: Jan-Marek Glogowski
>
> This re-applies the workaround for "some DP sinks, [which] are a
> little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
> quality check unconditionally during long pulse").
> It makes the secondary AOC E2460P monitor connected via DP to an
> acer Veriton N4640G usable again.
>
> This hunk was dropped in commit c85d200e8321 ("drm/i915: Move SST
> DP link retraining into the ->post_hotplug() hook")
>
> Fixes: c85d200e8321 ("drm/i915: Move SST DP link retraining into the
> ->post_hotplug() hook")
> [Cleaned up commit message, added stable cc]
> Signed-off-by: Lyude Paul
> Signed-off-by: Jan-Marek Glogowski
> Cc: sta...@vger.kernel.org
> ---
> Resending this to update patchwork; will push in a little bit
>
> drivers/gpu/drm/i915/intel_dp.c | 33 +++--
> 1 file changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b3f6f04c3c7d..db8515171270 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4333,18 +4333,6 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> }
>
> -/*
> - * If display is now connected check links status,
> - * there has been known issues of link loss triggering
> - * long pulse.
> - *
> - * Some sinks (eg. ASUS PB287Q) seem to perform some
> - * weird HPD ping pong during modesets. So we can apparently
> - * end up with HPD going low during a modeset, and then
> - * going back up soon after. And once that happens we must
> - * retrain the link to get a picture. That's in case no
> - * userspace component reacted to intermittent HPD dip.
> - */
> int intel_dp_retrain_link(struct intel_encoder *encoder,
> struct drm_modeset_acquire_ctx *ctx)
> {
> @@ -5031,7 +5019,8 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> }
>
> static int
> -intel_dp_long_pulse(struct intel_connector *connector)
> +intel_dp_long_pulse(struct intel_connector *connector,
> + struct drm_modeset_acquire_ctx *ctx)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_dp *intel_dp = intel_attached_dp(>base);
> @@ -5090,6 +5079,22 @@ intel_dp_long_pulse(struct intel_connector *connector)
>*/
> status = connector_status_disconnected;
> goto out;
> + } else {
> + /*
> + * If display is now connected check links status,
> + * there has been known issues of link loss triggering
> + * long pulse.
> + *
> + * Some sinks (eg. ASUS PB287Q) seem to perform some
> + * weird HPD ping pong during modesets. So we can apparently
> + * end up with HPD going low during a modeset, and then
> + * going back up soon after. And once that happens we must
> + * retrain the link to get a picture. That's in case no
> + * userspace component reacted to intermittent HPD dip.
> + */
> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> +
> + intel_dp_retrain_link(encoder, ctx);
We should really have a comment here that this is purely duct tape for
sinks that fail to signal a hpd when the link goes bad (either that or
we fail to process the hpd correctly).
I suppose a better way to do this hack would be to do the link quality
check at the end of modeset, or from a delayed work. As is this depends
on userspace/fbdev doing an explicit probe after the modeset which seems
pretty fragile.
> }
>
> /*
> @@ -5151,7 +5156,7 @@ intel_dp_detect(struct drm_connector *connector,
> return ret;
> }
>
> - status = intel_dp_long_pulse(intel_dp->attached_connector);
> + status = intel_dp_long_pulse(intel_dp->attached_connector, ctx);
> }
>
> intel_dp->detect_done = false;
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 0/5] drm/mxsfb: Fix runtime PM for unpowering lcdif block
Hi Leonard, On Mon, 2018-08-27 at 14:10 +0300, Leonard Crestez wrote: > Adding lcdif nodes to a power domain currently doesn't work, it results > in black/corrupted screens or hangs. While the driver does enable > runtime pm it does not deal correctly with the block being unpowered. > > All patches in this series have review tags from a few weeks ago. I'm > resending this today because 4.19 rc1 was released. I'm not sure if this > matters for DRM but in some areas unrelated series get lost during the > merge window. > > Marek/Phillip: Is one of you going to pick up these patches? I assumed Marek would pick them up. Marek, should I push these patches to drm-misc-fixes? regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/bridge: Add virtual display DT bindings
On 24.08.2018 14:23, Linus Walleij wrote:
> This adds bindings for a virtual display to be used with displays
> inside entirely virtual environments which do not emulate things
> like monitors but just need timing information to be supplied to
> its display controller.
>
> This is inspired by earlier work by Liviu Dudau.
If this is pure virtual then it should be connected to other pure
virtual components.
What will be this virtual bridge attached to? I expect some virtual
encoder, virtual crtc? If yes then why don't you create whole virtual
drm pipeline in one patchset?
Could you describe more what do you want to do.
And one more thing, you are defining virtual panel but you are using
drm_bridge framework, why not drm_panel?
Regards
Andrzej
>
> Cc: Liviu Dudau
> Cc: Ryan Harkin
> Signed-off-by: Linus Walleij
> ---
> .../display/bridge/virtual-display-bridge.txt | 62 +++
> 1 file changed, 62 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> new file mode 100644
> index ..ea4f5a91ab94
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/bridge/virtual-display-bridge.txt
> @@ -0,0 +1,62 @@
> +Virtual Display Bridge
> +
> +This represents a display that is contained within an emulated
> +environment.
> +
> +This means that the display engine mainly expects some timing
> +parameters to be written into it, and after that the emulator will
> +respond by creating a virtual display with the requested
> +resolution characteristics.
> +
> +As the operating system cannot "detect" such a display, rather the
> +emulator will respond to what the controller outputs, a
> +chicken-and-egg problem needs to be solved: the resolution and
> +timing characteristics need to be defined and set up somewhere.
> +
> +The virtual display bridge solves this by defining a bridge with
> +all timing characteristics encoded into the device tree node.
> +
> +Required properies:
> +- compatible: shall be "virtual-display-bridge"
> +
> +Required subnodes:
> +- display-timings: contains in turn a display timing node
> + see display-timing.txt
> +- ports: contains the display ports, see media/video-interfaces.txt
> +
> +Example:
> +
> +bridge {
> + compatible = "virtual-display-bridge";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + display-timings {
> + /* Some standard VGA timing */
> + timing0 {
> + clock-frequency = <23750>;
> + hactive = <640>;
> + vactive = <480>;
> + hfront-porch = <48>;
> + hback-porch = <16>;
> + hsync-len = <96>;
> + vfront-porch = <33>;
> + vback-porch = <9>;
> + vsync-len = <3>;
> + vrefresh = <60>;
> + };
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + display_bridge_in: endpoint {
> + remote-endpoint = <>;
> + };
> + };
> + };
> +};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 7/7] drm/rockchip: dsi: add dual mipi support
On 21.08.2018 16:05, Heiko Stuebner wrote:
> Add the Rockchip-sepcific dual-dsi setup and hook it into the VOP as well.
> As described in the general dual-dsi devicetree binding, the panel should
> define two input ports and point each of them to one of the used dsi-
> controllers, as well as declare one of them as clock-master.
> This is used to determine the dual-dsi state and get access to both
> controller instances.
>
> Signed-off-by: Heiko Stuebner
> v4:
> add component directly in probe when adding empty dsi slave controller
> v5:
> use driver-internal mechanism to find dual dsi slave
> ---
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 105 ++
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 +
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
> 5 files changed, 114 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index b3aae8439aa3..e4aee2ccbf4d 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -218,6 +218,10 @@ struct dw_mipi_dsi_rockchip {
> struct clk *grf_clk;
> struct clk *phy_cfg_clk;
>
> + /* dual-channel */
> + bool is_slave;
> + struct dw_mipi_dsi_rockchip *slave;
> +
> unsigned int lane_mbps; /* per lane */
> u16 input_div;
> u16 feedback_div;
> @@ -226,6 +230,7 @@ struct dw_mipi_dsi_rockchip {
> struct dw_mipi_dsi *dmd;
> const struct rockchip_dw_dsi_chip_data *cdata;
> struct dw_mipi_dsi_plat_data pdata;
> + int devcnt;
> };
>
> struct dphy_pll_parameter_map {
> @@ -602,6 +607,8 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder
> *encoder,
> }
>
> s->output_type = DRM_MODE_CONNECTOR_DSI;
> + if (dsi->slave)
> + s->output_flags = ROCKCHIP_OUTPUT_DSI_DUAL;
>
> return 0;
> }
> @@ -617,6 +624,8 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
> *encoder)
> return;
>
> pm_runtime_get_sync(dsi->dev);
> + if (dsi->slave)
> + pm_runtime_get_sync(dsi->slave->dev);
>
> /*
>* For the RK3399, the clk of grf must be enabled before writing grf
> @@ -630,6 +639,8 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
> *encoder)
> }
>
> dw_mipi_dsi_rockchip_config(dsi, mux);
> + if (dsi->slave)
> + dw_mipi_dsi_rockchip_config(dsi->slave, mux);
>
> clk_disable_unprepare(dsi->grf_clk);
> }
> @@ -638,6 +649,8 @@ static void dw_mipi_dsi_encoder_disable(struct
> drm_encoder *encoder)
> {
> struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
>
> + if (dsi->slave)
> + pm_runtime_put(dsi->slave->dev);
> pm_runtime_put(dsi->dev);
> }
>
> @@ -673,14 +686,76 @@ static int rockchip_dsi_drm_create_encoder(struct
> dw_mipi_dsi_rockchip *dsi,
> return 0;
> }
>
> +static int dw_mipi_dsi_rockchip_match_second(struct device *dev, void *data)
> +{
> + struct dw_mipi_dsi_rockchip *dsi = data;
> + struct drm_bridge *bridge1, *bridge2;
> + struct drm_panel *panel1, *panel2;
> + int ret;
> +
> + if (dsi->dev->of_node == dev->of_node)
> + return 0;
> +
> + ret = drm_of_find_panel_or_bridge(dsi->dev->of_node, 1, 0,
> + , );
> + if (ret)
> + return ret;
> +
> + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
> + , );
> + if (ret)
> + return ret;
> +
> + return (panel1 == panel2) && (bridge1 == bridge2);
> +}
> +
> static int dw_mipi_dsi_rockchip_bind(struct device *dev,
>struct device *master,
>void *data)
> {
> struct dw_mipi_dsi_rockchip *dsi = dev_get_drvdata(dev);
> struct drm_device *drm_dev = data;
> + struct device *second;
> + bool master1, master2;
> int ret;
>
> + second = driver_find_device(dsi->dev->driver, NULL, dsi,
> + dw_mipi_dsi_rockchip_match_second);
This function performs get_device on the matched device, so you should
probably call somewhere put_device to make the counter balanced.
I hope second device is somehow guarded by component framework from
being unbound in unexpected moments (ie. when in use by master).
> + if (IS_ERR(second))
> + return PTR_ERR(second);
> +
> + if (second) {
> + master1 = of_property_read_bool(dsi->dev->of_node,
> + "clock-master");
> + master2 = of_property_read_bool(second->of_node,
> + "clock-master");
> +
> + if (master1 && master2) {
> +
Re: [PATCH 3/4] drm/i915: preparations for enabling P010, P012, P016 formats
Op 16-08-18 om 14:55 schreef Juha-Pekka Heikkila:
> Preparations for enabling P010, P012 and P016 formats. These
> formats will extend NV12 for larger bit depths.
>
> Signed-off-by: Juha-Pekka Heikkila
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 3 +-
> drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 46
> +++
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 19 ++---
> drivers/gpu/drm/i915/intel_sprite.c | 18 +++-
> 6 files changed, 69 insertions(+), 20 deletions(-)
For patches 2, 3, 4:
Acked-by: Jani Nikula #irc, for merging through
drm-misc-next.
Are you ok with Swati Sharma's comment on patch 4? I can fix it up when
committing.
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index b04952b..ab76b72 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -334,8 +334,7 @@ int intel_atomic_setup_scalers(struct drm_i915_private
> *dev_priv,
> /* set scaler mode */
> if ((INTEL_GEN(dev_priv) >= 9) &&
> plane_state && plane_state->base.fb &&
> - plane_state->base.fb->format->format ==
> - DRM_FORMAT_NV12) {
> + is_planar_yuv_format(plane_state->base.fb->format->format))
> {
> if (INTEL_GEN(dev_priv) == 9 &&
> !IS_GEMINILAKE(dev_priv) &&
> !IS_SKYLAKE(dev_priv))
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index dcba645..58b2fc6 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -182,7 +182,7 @@ int intel_plane_atomic_check_with_state(const struct
> intel_crtc_state *old_crtc_
> else
> crtc_state->active_planes &= ~BIT(intel_plane->id);
>
> - if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
> + if (state->visible && is_planar_yuv_format(state->fb->format->format))
> crtc_state->nv12_planes |= BIT(intel_plane->id);
> else
> crtc_state->nv12_planes &= ~BIT(intel_plane->id);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 690e1e8..80ce742 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2667,6 +2667,12 @@ int skl_format_to_fourcc(int format, bool rgb_order,
> bool alpha)
> return DRM_FORMAT_RGB565;
> case PLANE_CTL_FORMAT_NV12:
> return DRM_FORMAT_NV12;
> + case PLANE_CTL_FORMAT_P010:
> + return DRM_FORMAT_P010;
> + case PLANE_CTL_FORMAT_P012:
> + return DRM_FORMAT_P012;
> + case PLANE_CTL_FORMAT_P016:
> + return DRM_FORMAT_P016;
> default:
> case PLANE_CTL_FORMAT_XRGB_:
> if (rgb_order) {
> @@ -3182,7 +3188,7 @@ int skl_check_plane_surface(const struct
> intel_crtc_state *crtc_state,
>* Handle the AUX surface first since
>* the main surface setup depends on it.
>*/
> - if (fb->format->format == DRM_FORMAT_NV12) {
> + if (is_planar_yuv_format(fb->format->format)) {
> ret = skl_check_nv12_surface(crtc_state, plane_state);
> if (ret)
> return ret;
> @@ -3507,6 +3513,12 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
> return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
> case DRM_FORMAT_NV12:
> return PLANE_CTL_FORMAT_NV12;
> + case DRM_FORMAT_P010:
> + return PLANE_CTL_FORMAT_P010;
> + case DRM_FORMAT_P012:
> + return PLANE_CTL_FORMAT_P012;
> + case DRM_FORMAT_P016:
> + return PLANE_CTL_FORMAT_P016;
> default:
> MISSING_CASE(pixel_format);
> }
> @@ -4808,8 +4820,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
> bool force_detach,
> need_scaling = src_w != dst_w || src_h != dst_h;
>
> if (plane_scaler_check)
> - if (pixel_format == DRM_FORMAT_NV12)
> - need_scaling = true;
> + need_scaling = is_planar_yuv_format(pixel_format);
>
> if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
> need_scaling = true;
> @@ -4850,7 +4861,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
> bool force_detach,
> return 0;
> }
>
> - if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12 &&
> + if (plane_scaler_check && is_planar_yuv_format(pixel_format) &&
> (src_h < SKL_MIN_YUV_420_SRC_H || src_w < SKL_MIN_YUV_420_SRC_W)) {
> DRM_DEBUG_KMS("NV12: src dimensions not met\n");
> return
Re: [PATCH v5 6/7] drm/bridge/synopsys: dsi: add dual-dsi support
On 21.08.2018 16:05, Heiko Stuebner wrote: > From: Nickey Yang > > Allow to also drive a slave dw-mipi-dsi controller in a dual-dsi > setup. This will require additional implementation-specific > code to look up the slave instance and do specific setup. > Also will probably need code in the specific crtcs as dual-dsi > does not equal two separate dsi outputs. > > To activate, the implementation-specific code should set the slave > using dw_mipi_dsi_set_slave() before calling __dw_mipi_dsi_bind(). > > v2: > - expect real interface number of lanes > - keep links to both master and slave > v3: > - remove unneeded separate variables > - remove unneeded second slave settings > - disable slave before master > - lane-sum calculation comments > > Signed-off-by: Nickey Yang > Signed-off-by: Heiko Stuebner > Tested-by: Philippe Cornu Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
4.19-rc1 on droid 4: screen not updating
Hi! With Sebastian's patches, display works on Droid 4 in v4.18. I had to do some manual merging, and I see kernel messages in v4.19-rc1, but they are frozen -- no updates. a) does someone have it working? b) is there some way I can help to get it working in mainline? Droid 4 is not exactly new, and this is painful point that makes it hard to use. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107545] radeon - ring 0 stalled - GPU lockup - SI
https://bugs.freedesktop.org/show_bug.cgi?id=107545 --- Comment #12 from Christian König --- (In reply to Julien Isorce from comment #11) > Could it be an issue with pcie (though is works with admgpu, well in fact it > uses kdata on amdgpu) ? Is there anyway I can force a commit/flush just > after it writes to parser->ib.ptr as a test even if it is slower ? thx! Really unlikely, if we would have a hardware problem with PCIe we would see random bit values flip and not a constant pattern like we do. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/4] drm/i915: preparations for enabling P010, P012, P016 formats
On 21.08.2018 17:26, Sharma, Swati2 wrote:
On 16-Aug-18 6:25 PM, Juha-Pekka Heikkila wrote:
Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 3 +-
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 46
+++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 19 ++---
drivers/gpu/drm/i915/intel_sprite.c | 18 +++-
6 files changed, 69 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index b04952b..ab76b72 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -334,8 +334,7 @@ int intel_atomic_setup_scalers(struct
drm_i915_private *dev_priv,
/* set scaler mode */
if ((INTEL_GEN(dev_priv) >= 9) &&
plane_state && plane_state->base.fb &&
- plane_state->base.fb->format->format ==
- DRM_FORMAT_NV12) {
+
is_planar_yuv_format(plane_state->base.fb->format->format)) {
if (INTEL_GEN(dev_priv) == 9 &&
!IS_GEMINILAKE(dev_priv) &&
!IS_SKYLAKE(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index dcba645..58b2fc6 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -182,7 +182,7 @@ int intel_plane_atomic_check_with_state(const
struct intel_crtc_state *old_crtc_
else
crtc_state->active_planes &= ~BIT(intel_plane->id);
- if (state->visible && state->fb->format->format == DRM_FORMAT_NV12)
+ if (state->visible &&
is_planar_yuv_format(state->fb->format->format))
crtc_state->nv12_planes |= BIT(intel_plane->id);
else
crtc_state->nv12_planes &= ~BIT(intel_plane->id);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 690e1e8..80ce742 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2667,6 +2667,12 @@ int skl_format_to_fourcc(int format, bool
rgb_order, bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_P010:
+ return DRM_FORMAT_P010;
+ case PLANE_CTL_FORMAT_P012:
+ return DRM_FORMAT_P012;
+ case PLANE_CTL_FORMAT_P016:
+ return DRM_FORMAT_P016;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3182,7 +3188,7 @@ int skl_check_plane_surface(const struct
intel_crtc_state *crtc_state,
* Handle the AUX surface first since
* the main surface setup depends on it.
*/
- if (fb->format->format == DRM_FORMAT_NV12) {
+ if (is_planar_yuv_format(fb->format->format)) {
ret = skl_check_nv12_surface(crtc_state, plane_state);
if (ret)
return ret;
@@ -3507,6 +3513,12 @@ static u32 skl_plane_ctl_format(uint32_t
pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_P010:
+ return PLANE_CTL_FORMAT_P010;
+ case DRM_FORMAT_P012:
+ return PLANE_CTL_FORMAT_P012;
+ case DRM_FORMAT_P016:
+ return PLANE_CTL_FORMAT_P016;
default:
MISSING_CASE(pixel_format);
}
@@ -4808,8 +4820,7 @@ skl_update_scaler(struct intel_crtc_state
*crtc_state, bool force_detach,
need_scaling = src_w != dst_w || src_h != dst_h;
if (plane_scaler_check)
- if (pixel_format == DRM_FORMAT_NV12)
- need_scaling = true;
+ need_scaling = is_planar_yuv_format(pixel_format);
if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
need_scaling = true;
@@ -4850,7 +4861,7 @@ skl_update_scaler(struct intel_crtc_state
*crtc_state, bool force_detach,
return 0;
}
- if (plane_scaler_check && pixel_format == DRM_FORMAT_NV12 &&
+ if (plane_scaler_check && is_planar_yuv_format(pixel_format) &&
(src_h < SKL_MIN_YUV_420_SRC_H || src_w <
SKL_MIN_YUV_420_SRC_W)) {
DRM_DEBUG_KMS("NV12: src dimensions not met\n");
return -EINVAL;
@@ -4955,6 +4966,9 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_P010:
+ case DRM_FORMAT_P012:
+ case DRM_FORMAT_P016:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling
format 0x%x\n",
@@ -13179,7 +13193,7 @@ skl_max_scale(struct intel_crtc *intel_crtc,
* or
* cdclk/crtc_clock
Re: [PATCH V5 5/8] backlight: qcom-wled: Restructure the driver for WLED3
On Fri 2018-08-24 15:57:44, Kiran Gunda wrote: > Restructure the driver to add the support for new WLED > peripherals. > > Signed-off-by: Kiran Gunda > Acked-by: Daniel Thompson > --- > Changes from V3: > - This is the new patch after splitting the > "backlight: qcom-wled: Add support for WLED4 peripheral" patch > to seperate the WLED3 specific restructure. > > Changes from V4: > - Initialize wled->cfg.enabled_strings to 0,1,2,3. > - Replaced the WLED3 macro with 3. > > drivers/video/backlight/qcom-wled.c | 395 > ++-- > 1 file changed, 245 insertions(+), 150 deletions(-) > > diff --git a/drivers/video/backlight/qcom-wled.c > b/drivers/video/backlight/qcom-wled.c > index 3cd6e75..a746bec 100644 > --- a/drivers/video/backlight/qcom-wled.c > +++ b/drivers/video/backlight/qcom-wled.c > @@ -15,59 +15,71 @@ > #include > #include > #include > +#include > #include > > /* From DT binding */ > +#define WLED_MAX_STRINGS 4 > + > #define WLED_DEFAULT_BRIGHTNESS 2048 > > -#define WLED3_SINK_REG_BRIGHT_MAX0xFFF > -#define WLED3_CTRL_REG_VAL_BASE 0x40 > +#define WLED_SINK_REG_BRIGHT_MAX 0xFFF Stop this, no. In previous patch you renamed from ABC123_ to WLED3_, now you are renaming back to WLED? Stop messing with the names. I'd actually prefer you to stick with original driver name, and just add note that this now supports more hardware. But yes, _one_ rename is okay. I guess. But renaming it twice in one series is not acceptable. > @@ -365,6 +433,15 @@ static int wled_configure(struct wled *wled, struct > device *dev) > > cfg->num_strings = cfg->num_strings + 1; > > + string_len = of_property_count_elems_of_size(dev->of_node, > + "qcom,enabled-strings", > + sizeof(u32)); > + if (string_len > 0) > + rc = of_property_read_u32_array(dev->of_node, > + "qcom,enabled-strings", > + wled->cfg.enabled_strings, > + sizeof(u32)); > + > return 0; > } rc is assigned but never used. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [ANNOUNCE] libdrm 2.4.94
On 2018-08-27 12:03 p.m., Emil Velikov wrote:
> On 27 August 2018 at 10:38, Michel Dänzer wrote:
>> On 2018-08-24 7:44 p.m., Laurent Carlier wrote:
>>>
>>> 11/15 amdgpu-symbol-check FAIL 0.22 s (exit status
>>> 1)
>>>
>>> --- command ---
>>> LANG='en_US.UTF-8' SUDO_GID='0' OLDPWD='/build/libdrm/src'
>>> COMMAND_MODE='legacy' USERNAME='builduser' SUDO_COMMAND='/bin/bash -c bash
>>> -c
>>> cd\ /startdir;\ makepkg\ "$@" -bash --syncdeps --noconfirm --log --holdver
>>> --
>>> skipinteg --install' CFLAGS='-march=x86-64 -mtune=generic -O2 -pipe -fstack-
>>> protector-strong -fno-plt' USER='builduser' CXXFLAGS='-march=x86-64 -
>>> mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt' TEXTDOMAINDIR='/
>>> usr/share/locale' PWD='/build/libdrm/src/build' HOME='/build'
>>> TEXTDOMAIN='pacman-scripts' SUDO_USER='root' SUDO_UID='0' MAIL='/var/mail/
>>> builduser' CHOST='x86_64-pc-linux-gnu' SHELL='/bin/bash'
>>> TERM='xterm-256color'
>>> SHLVL='3' CPPFLAGS='-D_FORTIFY_SOURCE=2' SOURCE_DATE_EPOCH='1535132201'
>>> LOGNAME='builduser' LDFLAGS='-Wl,-O1,--sort-common,--as-needed,-z,relro,-
>>> z,now'
>>> PATH='/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/
>>> bin/vendor_perl:/usr/bin/core_perl:/usr/bin/site_perl:/usr/bin/vendor_perl:/
>>> usr/bin/core_perl:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/
>>> usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl' MAKEFLAGS='-j9'
>>> _='/usr/bin/meson' NM='/usr/bin/nm' /usr/bin/bash
>>> /build/libdrm/src/build/../
>>> libdrm-2.4.94/amdgpu/amdgpu-symbol-check amdgpu/libdrm_amdgpu.so.1.0.0
>>> --- stdout ---
>>> amdgpu_find_bo_by_cpu_mapping
>>
>> Part of the problem here is probably that the *-symbol-check scripts
>> haven't actually checked anything in an autotools build since commit
>> 4f08bfe96da1 ("*-symbol-check: Don't hard-code nm executable"):
>>
>> ../../amdgpu/amdgpu-symbol-check: line 74: -D: command not found
>> PASS amdgpu-symbol-check (exit status: 0)
>>
> Disclaimer: Coffee hasn't kicked in fully
I'm afraid it shows. :)
> It does work as intended. Problem is that:
> a) when running manually one needs to set NM
I realize that, but the above is the contents of
amdgpu/amdgpu-symbol-check.log in the build tree.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 4/8] backlight: qcom-wled: Rename PM8941* to WLED3
On Fri 2018-08-24 15:57:43, Kiran Gunda wrote:
> Rename the PM8941* references as WLED3 to make the driver
> generic and have WLED support for other PMICs. Also rename
> "i_boost_limit" and "i_limit" variables to "boost_i_limit"
> and "string_i_limit" respectively to resemble the corresponding
> register names.
Acked-by: Pavel Machek
> -MODULE_DESCRIPTION("pm8941 wled driver");
> +MODULE_DESCRIPTION("Qualcomm WLED driver");
"... supporting pm8941, xxx devices" ?
> MODULE_LICENSE("GPL v2");
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [ANNOUNCE] libdrm 2.4.94
On 27 August 2018 at 10:38, Michel Dänzer wrote:
> On 2018-08-24 7:44 p.m., Laurent Carlier wrote:
>>
>> 11/15 amdgpu-symbol-check FAIL 0.22 s (exit status 1)
>>
>> --- command ---
>> LANG='en_US.UTF-8' SUDO_GID='0' OLDPWD='/build/libdrm/src'
>> COMMAND_MODE='legacy' USERNAME='builduser' SUDO_COMMAND='/bin/bash -c bash -c
>> cd\ /startdir;\ makepkg\ "$@" -bash --syncdeps --noconfirm --log --holdver --
>> skipinteg --install' CFLAGS='-march=x86-64 -mtune=generic -O2 -pipe -fstack-
>> protector-strong -fno-plt' USER='builduser' CXXFLAGS='-march=x86-64 -
>> mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt' TEXTDOMAINDIR='/
>> usr/share/locale' PWD='/build/libdrm/src/build' HOME='/build'
>> TEXTDOMAIN='pacman-scripts' SUDO_USER='root' SUDO_UID='0' MAIL='/var/mail/
>> builduser' CHOST='x86_64-pc-linux-gnu' SHELL='/bin/bash'
>> TERM='xterm-256color'
>> SHLVL='3' CPPFLAGS='-D_FORTIFY_SOURCE=2' SOURCE_DATE_EPOCH='1535132201'
>> LOGNAME='builduser' LDFLAGS='-Wl,-O1,--sort-common,--as-needed,-z,relro,-
>> z,now' PATH='/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/
>> bin/vendor_perl:/usr/bin/core_perl:/usr/bin/site_perl:/usr/bin/vendor_perl:/
>> usr/bin/core_perl:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/
>> usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl' MAKEFLAGS='-j9'
>> _='/usr/bin/meson' NM='/usr/bin/nm' /usr/bin/bash /build/libdrm/src/build/../
>> libdrm-2.4.94/amdgpu/amdgpu-symbol-check amdgpu/libdrm_amdgpu.so.1.0.0
>> --- stdout ---
>> amdgpu_find_bo_by_cpu_mapping
>
> Part of the problem here is probably that the *-symbol-check scripts
> haven't actually checked anything in an autotools build since commit
> 4f08bfe96da1 ("*-symbol-check: Don't hard-code nm executable"):
>
> ../../amdgpu/amdgpu-symbol-check: line 74: -D: command not found
> PASS amdgpu-symbol-check (exit status: 0)
>
Disclaimer: Coffee hasn't kicked in fully
It does work as intended. Problem is that:
a) when running manually one needs to set NM
b) script don't error out when NM is not set - need a "set -u"
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 3/8] backlight: qcom-wled: Add new properties for PMI8998
Hi! On Fri 2018-08-24 15:57:42, Kiran Gunda wrote: > Update the bindings with the new properties used for > PMI8998. > Changes from V3: > - Removed the default values. Why? > +- qcom,current-limit-microamp > + Usage:optional > + Value type: > + Definition: uA; per-string current limit; value from 0 to 3 with > + 2500 uA step. > > - qcom,current-boost-limit > Usage:optional > Value type: > Definition: mA; boost current limit. > For pm8941: one of: 105, 385, 525, 805, 980, 1260, 1400, > - 1680. Default: 805 mA > + 1680. > For pmi8998: one of: 105, 280, 450, 620, 970, 1150, 1300, > - 1500. Default: 970 mA > + 1500. > I'd say that optional properties should list default values...? > - qcom,ovp > Usage:optional > Value type: > Definition: V; Over-voltage protection limit; one of: > - 27, 29, 32, 35. default: 29V > + 27, 29, 32, 35. > This property is supported only for PM8941. > Same here. > +- qcom,ovp-millivolt > + Usage:optional > + Value type: > + Definition: mV; Over-voltage protection limit; > + For pmi8998: one of 18100, 19600, 29600, 31100 > + If this property is not specified for PM8941, it > + falls back to "qcom,ovp" property. > + "voltage-limit-millivolt"? "ovp" is not really well known acronym. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 2/8] backlight: qcom-wled: restructure the qcom-wled bindings
On Fri 2018-08-24 15:57:41, Kiran Gunda wrote: > Restructure the qcom-wled bindings for the better readability. > > Signed-off-by: Kiran Gunda > Reviewed-by: Bjorn Andersson > Reviewed-by: Rob Herring > Acked-by: Daniel Thompson Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5 1/8] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c
On Fri 2018-08-24 15:57:40, Kiran Gunda wrote: > pm8941-wled.c driver is supporting the WLED peripheral > on pm8941. Rename it to qcom-wled.c so that it can support > WLED on multiple PMICs. > > Signed-off-by: Kiran Gunda > Reviewed-by: Bjorn Andersson > Acked-by: Rob Herring > Acked-by: Daniel Thompson Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [ANNOUNCE] libdrm 2.4.94
On 2018-08-24 7:44 p.m., Laurent Carlier wrote:
>
> 11/15 amdgpu-symbol-check FAIL 0.22 s (exit status 1)
>
> --- command ---
> LANG='en_US.UTF-8' SUDO_GID='0' OLDPWD='/build/libdrm/src'
> COMMAND_MODE='legacy' USERNAME='builduser' SUDO_COMMAND='/bin/bash -c bash -c
> cd\ /startdir;\ makepkg\ "$@" -bash --syncdeps --noconfirm --log --holdver --
> skipinteg --install' CFLAGS='-march=x86-64 -mtune=generic -O2 -pipe -fstack-
> protector-strong -fno-plt' USER='builduser' CXXFLAGS='-march=x86-64 -
> mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt' TEXTDOMAINDIR='/
> usr/share/locale' PWD='/build/libdrm/src/build' HOME='/build'
> TEXTDOMAIN='pacman-scripts' SUDO_USER='root' SUDO_UID='0' MAIL='/var/mail/
> builduser' CHOST='x86_64-pc-linux-gnu' SHELL='/bin/bash'
> TERM='xterm-256color'
> SHLVL='3' CPPFLAGS='-D_FORTIFY_SOURCE=2' SOURCE_DATE_EPOCH='1535132201'
> LOGNAME='builduser' LDFLAGS='-Wl,-O1,--sort-common,--as-needed,-z,relro,-
> z,now' PATH='/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/
> bin/vendor_perl:/usr/bin/core_perl:/usr/bin/site_perl:/usr/bin/vendor_perl:/
> usr/bin/core_perl:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/
> usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl' MAKEFLAGS='-j9'
> _='/usr/bin/meson' NM='/usr/bin/nm' /usr/bin/bash /build/libdrm/src/build/../
> libdrm-2.4.94/amdgpu/amdgpu-symbol-check amdgpu/libdrm_amdgpu.so.1.0.0
> --- stdout ---
> amdgpu_find_bo_by_cpu_mapping
Part of the problem here is probably that the *-symbol-check scripts
haven't actually checked anything in an autotools build since commit
4f08bfe96da1 ("*-symbol-check: Don't hard-code nm executable"):
../../amdgpu/amdgpu-symbol-check: line 74: -D: command not found
PASS amdgpu-symbol-check (exit status: 0)
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7] Add udmabuf misc device
A driver to let userspace turn memfd regions into dma-bufs.
Use case: Allows qemu create dmabufs for the vga framebuffer or
virtio-gpu ressources. Then they can be passed around to display
those guest things on the host. To spice client for classic full
framebuffer display, and hopefully some day to wayland server for
seamless guest window display.
qemu test branch:
https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf
Cc: David Airlie
Cc: Tomeu Vizoso
Cc: Laurent Pinchart
Cc: Daniel Vetter
Signed-off-by: Gerd Hoffmann
---
Documentation/ioctl/ioctl-number.txt | 1 +
include/uapi/linux/udmabuf.h | 33 +++
drivers/dma-buf/udmabuf.c | 287 ++
tools/testing/selftests/drivers/dma-buf/udmabuf.c | 96
MAINTAINERS | 16 ++
drivers/dma-buf/Kconfig | 8 +
drivers/dma-buf/Makefile | 1 +
tools/testing/selftests/drivers/dma-buf/Makefile | 5 +
8 files changed, 447 insertions(+)
create mode 100644 include/uapi/linux/udmabuf.h
create mode 100644 drivers/dma-buf/udmabuf.c
create mode 100644 tools/testing/selftests/drivers/dma-buf/udmabuf.c
create mode 100644 tools/testing/selftests/drivers/dma-buf/Makefile
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 13a7c999c0..f2ac672eb7 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -272,6 +272,7 @@ Code Seq#(hex) Include FileComments
't'90-91 linux/toshiba.h toshiba and toshiba_acpi SMM
'u'00-1F linux/smb_fs.h gone
'u'20-3F linux/uvcvideo.hUSB video class host driver
+'u'40-4f linux/udmabuf.h userspace dma-buf misc device
'v'00-1F linux/ext2_fs.h conflict!
'v'00-1F linux/fs.h conflict!
'v'00-0F linux/sonypi.h conflict!
diff --git a/include/uapi/linux/udmabuf.h b/include/uapi/linux/udmabuf.h
new file mode 100644
index 00..46b6532ed8
--- /dev/null
+++ b/include/uapi/linux/udmabuf.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_UDMABUF_H
+#define _UAPI_LINUX_UDMABUF_H
+
+#include
+#include
+
+#define UDMABUF_FLAGS_CLOEXEC 0x01
+
+struct udmabuf_create {
+ __u32 memfd;
+ __u32 flags;
+ __u64 offset;
+ __u64 size;
+};
+
+struct udmabuf_create_item {
+ __u32 memfd;
+ __u32 __pad;
+ __u64 offset;
+ __u64 size;
+};
+
+struct udmabuf_create_list {
+ __u32 flags;
+ __u32 count;
+ struct udmabuf_create_item list[];
+};
+
+#define UDMABUF_CREATE _IOW('u', 0x42, struct udmabuf_create)
+#define UDMABUF_CREATE_LIST _IOW('u', 0x43, struct udmabuf_create_list)
+
+#endif /* _UAPI_LINUX_UDMABUF_H */
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
new file mode 100644
index 00..8e24204526
--- /dev/null
+++ b/drivers/dma-buf/udmabuf.c
@@ -0,0 +1,287 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct udmabuf {
+ u32 pagecount;
+ struct page **pages;
+};
+
+static int udmabuf_vm_fault(struct vm_fault *vmf)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct udmabuf *ubuf = vma->vm_private_data;
+
+ if (WARN_ON(vmf->pgoff >= ubuf->pagecount))
+ return VM_FAULT_SIGBUS;
+
+ vmf->page = ubuf->pages[vmf->pgoff];
+ get_page(vmf->page);
+ return 0;
+}
+
+static const struct vm_operations_struct udmabuf_vm_ops = {
+ .fault = udmabuf_vm_fault,
+};
+
+static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma)
+{
+ struct udmabuf *ubuf = buf->priv;
+
+ if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0)
+ return -EINVAL;
+
+ vma->vm_ops = _vm_ops;
+ vma->vm_private_data = ubuf;
+ return 0;
+}
+
+static struct sg_table *map_udmabuf(struct dma_buf_attachment *at,
+ enum dma_data_direction direction)
+{
+ struct udmabuf *ubuf = at->dmabuf->priv;
+ struct sg_table *sg;
+
+ sg = kzalloc(sizeof(*sg), GFP_KERNEL);
+ if (!sg)
+ goto err1;
+ if (sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount,
+ 0, ubuf->pagecount << PAGE_SHIFT,
+ GFP_KERNEL) < 0)
+ goto err2;
+ if (!dma_map_sg(at->dev, sg->sgl, sg->nents, direction))
+ goto err3;
+
+ return sg;
+
+err3:
+ sg_free_table(sg);
+err2:
+ kfree(sg);
+err1:
+ return ERR_PTR(-ENOMEM);
+}
+
+static void unmap_udmabuf(struct dma_buf_attachment *at,
+ struct sg_table *sg,
+
Re: [PATCH v6] Add udmabuf misc device
Hi, > > Covering udmabuf.c maintainance is a different issue. I could just add > > myself to the existing entry, or create a new one specifically for > > udmabuf. > > That's what I meant, do a more specific entry to add yourself just for > udmabuf. Ok. Back from summer vacation, finally found the time to continue working on this. Entry added, rebased to 4.19-rc1, v7 comes in a moment. Please review & ack. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
