Re: [Nouveau] [PATCH 0/2] drm/nouveau: Use more standard logging styles
For the whole series: Reviewed-by: Lyude Paul Nice catch! On Thu, 2018-08-30 at 11:36 -0700, Joe Perches wrote: > Reduces object size ~4kb > > Joe Perches (2): > drm/nouveau: Add new logging function nv_cli_printk > drm/nouveau: Convert NV_PRINTK macros and uses to new nv_cli_ > macros > > drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_chan.c | 12 +++ > drivers/gpu/drm/nouveau/nouveau_drm.c | 21 +++ > drivers/gpu/drm/nouveau/nouveau_drv.h | 44 ++- > drivers/gpu/drm/nouveau/nouveau_gem.c | 62 > - > 5 files changed, 87 insertions(+), 54 deletions(-) > -- Cheers, Lyude Paul ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] PCI: add prefetch quirk to work around Asus/Nvidia suspend issues
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on pci/next]
[also build test WARNING on v4.19-rc1 next-20180831]
[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/Daniel-Drake/PCI-add-prefetch-quirk-to-work-around-Asus-Nvidia-suspend-issues/20180901-043245
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-randconfig-x000-201834 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/pci/quirks.c: In function 'quirk_asus_pci_prefetch':
>> drivers/pci/quirks.c:5134:6: warning: argument 1 null where non-null
>> expected [-Wnonnull]
if (strcmp(sys_vendor, "ASUSTeK COMPUTER INC.") != 0)
^~~
In file included from include/linux/uuid.h:20:0,
from include/linux/mod_devicetable.h:13,
from include/linux/pci.h:21,
from drivers/pci/quirks.c:18:
include/linux/string.h:44:12: note: in a call to function 'strcmp' declared
here
extern int strcmp(const char *,const char *);
^~
vim +5134 drivers/pci/quirks.c
4983
4984 /*
4985 * Microsemi Switchtec NTB uses devfn proxy IDs to move TLPs between
4986 * NT endpoints via the internal switch fabric. These IDs replace the
4987 * originating requestor ID TLPs which access host memory on peer NTB
4988 * ports. Therefore, all proxy IDs must be aliased to the NTB device
4989 * to permit access when the IOMMU is turned on.
4990 */
4991 static void quirk_switchtec_ntb_dma_alias(struct pci_dev *pdev)
4992 {
4993 void __iomem *mmio;
4994 struct ntb_info_regs __iomem *mmio_ntb;
4995 struct ntb_ctrl_regs __iomem *mmio_ctrl;
4996 struct sys_info_regs __iomem *mmio_sys_info;
4997 u64 partition_map;
4998 u8 partition;
4999 int pp;
5000
5001 if (pci_enable_device(pdev)) {
5002 pci_err(pdev, "Cannot enable Switchtec device\n");
5003 return;
5004 }
5005
5006 mmio = pci_iomap(pdev, 0, 0);
5007 if (mmio == NULL) {
5008 pci_disable_device(pdev);
5009 pci_err(pdev, "Cannot iomap Switchtec device\n");
5010 return;
5011 }
5012
5013 pci_info(pdev, "Setting Switchtec proxy ID aliases\n");
5014
5015 mmio_ntb = mmio + SWITCHTEC_GAS_NTB_OFFSET;
5016 mmio_ctrl = (void __iomem *) mmio_ntb +
SWITCHTEC_NTB_REG_CTRL_OFFSET;
5017 mmio_sys_info = mmio + SWITCHTEC_GAS_SYS_INFO_OFFSET;
5018
5019 partition = ioread8(_ntb->partition_id);
5020
5021 partition_map = ioread32(_ntb->ep_map);
5022 partition_map |= ((u64) ioread32(_ntb->ep_map + 4)) << 32;
5023 partition_map &= ~(1ULL << partition);
5024
5025 for (pp = 0; pp < (sizeof(partition_map) * 8); pp++) {
5026 struct ntb_ctrl_regs __iomem *mmio_peer_ctrl;
5027 u32 table_sz = 0;
5028 int te;
5029
5030 if (!(partition_map & (1ULL << pp)))
5031 continue;
5032
5033 pci_dbg(pdev, "Processing partition %d\n", pp);
5034
5035 mmio_peer_ctrl = _ctrl[pp];
5036
5037 table_sz = ioread16(_peer_ctrl->req_id_table_size);
5038 if (!table_sz) {
5039 pci_warn(pdev, "Partition %d table_sz 0\n", pp);
5040 continue;
5041 }
5042
5043 if (table_sz > 512) {
5044 pci_warn(pdev,
5045 "Invalid Switchtec partition %d
table_sz %d\n",
5046 pp, table_sz);
5047 continue;
5048 }
5049
5050 for (te = 0; te < table_sz; te++) {
5051 u32 rid_entry;
5052 u8 devfn;
5053
5054 rid_entry =
ioread32(_peer_ctrl->req_id_table[te]);
5055 devfn = (rid_entry >> 1) & 0xFF;
5056 pci_dbg(pdev,
5057 "Aliasing Partition %d Proxy ID
%02x.%d\n",
5058 pp, PCI_SLOT(devfn), PCI_FUNC(devfn));
5059 pci_add_dma_alias(pdev, de
Re: [Nouveau] [PATCH] PCI: add prefetch quirk to work around Asus/Nvidia suspend issues
[+cc Intel folks] On Fri, Aug 31, 2018 at 03:30:57PM +0800, Daniel Drake wrote: > On over 40 Intel-based Asus products, the nvidia GPU becomes unusable > after S3 suspend/resume. The affected products include multiple > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > many errors such as: > > fifo: fault 00 [READ] at 00555000 engine 00 [GR] client 04 > [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown] > DRM: failed to idle channel 0 [DRM] > > Similarly, the nvidia proprietary driver also fails after resume > (black screen, 100% CPU usage in Xorg process). We shipped a sample > to Nvidia for diagnosis, and their response indicated that it's a > problem with the parent PCI bridge (on the Intel SoC), not the GPU. > > We found a workaround: on resume, rewrite the Intel PCI bridge > 'Prefetchable Base Upper 32 Bits' register. In the cases that I checked, > this register has value 0 and we just have to rewrite that value. > > It's very strange that rewriting the exact same register value > makes a difference, but it definitely makes the issue go away. > It's not just acting as some kind of memory barrier, because rewriting > other bridge registers does not work around the issue. There's something > magic in this particular register. If true, this sounds like some sort of erratum, so it would be good to get some input from Intel, and I cc'd a few Intel folks. It's interesting that all the systems below are from Asus. That makes me think there's some BIOS or SMM connection, e.g., SMM traps the register write and does something magic. Does this problem happen after a full system suspend/resume, or does it happen after runtime suspend of only the GPU? Or runtime suspend of only the GPU and the upstream bridge? Can we tell whether Windows rewrites this register unconditionally at resume-time? If so, it may be more robust for Linux to do the same. The whole thing is black magic, which I hate, but if it's our only choice, it may be better to have this applied everywhere so we don't keep stubbing our toes on new systems that require the quirk. > We examined our database of Asus hardware and identified 43 products > that we believe are affected. Checking the nvidia GPU parent PCI bridge > on each one, in total 5 Intel PCI bridges need quirking as below. > The quirk will run on bridges even where no nvidia GPU is connected, > but it should be harmless, and we at least limit it to only running > on Asus products. > > This fix was tested on all the affected models that we have in hands > (X542UQ, UX533FD, X530UN, V272UN). > > Signed-off-by: Daniel Drake > --- > > Notes: > If anyone has ideas for why writing this register makes a difference, or > suggestions for other approaches then I'm all ears... > > Here is some basic info of the 43 products believed to be affected: > basic DMI data, nvidia GPU PCI info, parent PCI bridge info. Can you attach the list below to a kernel.org bugzilla and include the URL in your changelog? > sys_vendor: ASUSTeK COMPUTER INC. > board_name: FX502VD > product_name: FX502VD > 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev > ff) (prog-if ff) > !!! Unknown header type 7f > 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) > (prog-if 00 [Normal decode]) > > sys_vendor: ASUSTeK COMPUTER INC. > board_name: FX570UD > product_name: ASUS Gaming FX570UD > 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev > a1) > Subsystem: ASUSTeK Computer Inc. Device [1043:1f40] > 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) > (prog-if 00 [Normal decode]) > > sys_vendor: ASUSTeK COMPUTER INC. > board_name: GL553VD > product_name: GL553VD > 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev > a1) > Subsystem: ASUSTeK Computer Inc. Device [1043:15e0] > 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) > (prog-if 00 [Normal decode]) > > sys_vendor: ASUSTeK COMPUTER INC. > board_name: GL553VD > product_name: GL553VD > 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev > a1) > Subsystem: ASUSTeK Computer Inc. Device [1043:15e0] > 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) > (prog-if 00 [Normal decode]) > > sys_vendor: ASUSTeK COMPUTER INC. > board_name: GL753VD > product_name: GL753VD > 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev > a1) > Subsystem: ASUSTeK Computer Inc. Device [1043:1590] > 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) > (prog-if 00 [Normal decode]) > > sys_vendor: ASUSTeK COMPUTER INC. > board_name: GL753VD > product_name: GL753VD > 01:00.0 3D controller [0302]: NVIDIA Corporation Device
Re: [Nouveau] [PATCH (repost) 5/5] drm/amdgpu: add DisplayPort CEC-Tunneling-over-AUX support
On 08/24/2018 04:59 PM, Alex Deucher wrote:
> On Fri, Aug 24, 2018 at 3:20 AM Hans Verkuil wrote:
>>
>> On 08/23/2018 08:38 PM, Harry Wentland wrote:
>>> On 2018-08-17 10:11 AM, Hans Verkuil wrote:
From: Hans Verkuil
Add DisplayPort CEC-Tunneling-over-AUX support to amdgpu.
Signed-off-by: Hans Verkuil
Acked-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +++--
.../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 ++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 34f34823bab5..77898c95bef6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -898,6 +898,7 @@ amdgpu_dm_update_connector_after_detect(struct
amdgpu_dm_connector *aconnector)
aconnector->dc_sink = sink;
if (sink->dc_edid.length == 0) {
aconnector->edid = NULL;
+drm_dp_cec_unset_edid(>dm_dp_aux.aux);
} else {
aconnector->edid =
(struct edid *) sink->dc_edid.raw_edid;
@@ -905,10 +906,13 @@ amdgpu_dm_update_connector_after_detect(struct
amdgpu_dm_connector *aconnector)
drm_connector_update_edid_property(connector,
aconnector->edid);
+drm_dp_cec_set_edid(>dm_dp_aux.aux,
+aconnector->edid);
}
amdgpu_dm_add_sink_to_freesync_module(connector,
aconnector->edid);
} else {
+drm_dp_cec_unset_edid(>dm_dp_aux.aux);
amdgpu_dm_remove_sink_from_freesync_module(connector);
drm_connector_update_edid_property(connector, NULL);
aconnector->num_modes = 0;
@@ -1059,12 +1063,16 @@ static void handle_hpd_rx_irq(void *param)
drm_kms_helper_hotplug_event(dev);
}
}
+
if ((dc_link->cur_link_settings.lane_count != LANE_COUNT_UNKNOWN) ||
-(dc_link->type == dc_connection_mst_branch))
+(dc_link->type == dc_connection_mst_branch)) {
dm_handle_hpd_rx_irq(aconnector);
+}
>>>
>>> These lines don't really add anything functional.
>>
>> Oops, a left-over from debugging code. I'll remove this 'change' and post a
>> v2
>> with all the Acks/reviewed-bys.
>>
>> Any idea who would typically merge a patch series like this?
>
> I (or anyone else with drm-misc rights) can push them for you, however
> drm-misc is a committer tree so if you'd like access to apply patches
> yourself, you could do that too. Request access here:
> https://www.freedesktop.org/wiki/AccountRequests/
OK, I pushed this series to drm-next. It's the first time I'm using dim &
drm-misc
so let me know if I did anything silly.
Regards,
Hans
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] PCI: add prefetch quirk to work around Asus/Nvidia suspend issues
On over 40 Intel-based Asus products, the nvidia GPU becomes unusable after S3 suspend/resume. The affected products include multiple generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs many errors such as: fifo: fault 00 [READ] at 00555000 engine 00 [GR] client 04 [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown] DRM: failed to idle channel 0 [DRM] Similarly, the nvidia proprietary driver also fails after resume (black screen, 100% CPU usage in Xorg process). We shipped a sample to Nvidia for diagnosis, and their response indicated that it's a problem with the parent PCI bridge (on the Intel SoC), not the GPU. We found a workaround: on resume, rewrite the Intel PCI bridge 'Prefetchable Base Upper 32 Bits' register. In the cases that I checked, this register has value 0 and we just have to rewrite that value. It's very strange that rewriting the exact same register value makes a difference, but it definitely makes the issue go away. It's not just acting as some kind of memory barrier, because rewriting other bridge registers does not work around the issue. There's something magic in this particular register. We examined our database of Asus hardware and identified 43 products that we believe are affected. Checking the nvidia GPU parent PCI bridge on each one, in total 5 Intel PCI bridges need quirking as below. The quirk will run on bridges even where no nvidia GPU is connected, but it should be harmless, and we at least limit it to only running on Asus products. This fix was tested on all the affected models that we have in hands (X542UQ, UX533FD, X530UN, V272UN). Signed-off-by: Daniel Drake --- Notes: If anyone has ideas for why writing this register makes a difference, or suggestions for other approaches then I'm all ears... Here is some basic info of the 43 products believed to be affected: basic DMI data, nvidia GPU PCI info, parent PCI bridge info. sys_vendor: ASUSTeK COMPUTER INC. board_name: FX502VD product_name: FX502VD 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev ff) (prog-if ff) !!! Unknown header type 7f 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode]) sys_vendor: ASUSTeK COMPUTER INC. board_name: FX570UD product_name: ASUS Gaming FX570UD 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev a1) Subsystem: ASUSTeK Computer Inc. Device [1043:1f40] 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode]) sys_vendor: ASUSTeK COMPUTER INC. board_name: GL553VD product_name: GL553VD 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev a1) Subsystem: ASUSTeK Computer Inc. Device [1043:15e0] 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode]) sys_vendor: ASUSTeK COMPUTER INC. board_name: GL553VD product_name: GL553VD 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev a1) Subsystem: ASUSTeK Computer Inc. Device [1043:15e0] 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode]) sys_vendor: ASUSTeK COMPUTER INC. board_name: GL753VD product_name: GL753VD 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev a1) Subsystem: ASUSTeK Computer Inc. Device [1043:1590] 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode]) sys_vendor: ASUSTeK COMPUTER INC. board_name: GL753VD product_name: GL753VD 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:1c8d] (rev a1) Subsystem: ASUSTeK Computer Inc. Device [1043:1590] 00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:1901] (rev 05) (prog-if 00 [Normal decode]) sys_vendor: ASUSTeK COMPUTER INC. board_name: K401UQK product_name: K401UQK 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134d] (rev a2) Subsystem: ASUSTeK Computer Inc. Device [1043:14b0] 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode]) sys_vendor: ASUSTeK COMPUTER INC. board_name: P1440UF product_name: ASUSPRO P1440UF 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:174d] (rev a2) Subsystem: ASUSTeK Computer Inc. Device [1043:1f10] 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] (rev f1) (prog-if 00 [Normal decode]) sys_vendor: ASUSTeK COMPUTER INC. board_name: P2440UQ product_name: P2440UQ 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:134d] (rev a2) Subsystem: ASUSTeK Computer Inc. Device [1043:13ce] 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10]
Re: [Nouveau] Rewriting Intel PCI bridge prefetch base address bits solves nvidia graphics issues
On Thu, Aug 30, 2018 at 5:40 PM, Peter Wu wrote: > As the BIOS date is not visible, can you also confirm that this message > is visible in dmesg? > >nouveau: detected PR support, will not use DSM Yes, that gets logged. > For laptops, it appears that you have to do at least two things: > - Ensure that the Subsystem Vendor/Product ID are set. > - Expose a _ROM ACPI method that provides VBIOS. > > Perhaps you also need to provide a "_DSM" method that emulates at least > the "Optimus" interface for GUID a486d8f8-0bda-471b-a72b-6042a6b5bee0. > > You probably lost interest here, but if you want to continue anyway this > is what allowed me to install the driver on the XPS 9560: > https://github.com/Lekensteyn/acpi-stuff/blob/master/d3test/fakedev.asl Indeed. I'm going to submit the workaround and I'll look to come back to this qemu/vfio analysis later. Thanks Daniel ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
