Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5367346ybi; Wed, 12 Jun 2019 01:04:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqzu9JFYwxJep2NSwdcr8Q7dHx4G8iWvp2LdKm5Kict9r91FUcBXf589RvXPHjNhR/zcojox X-Received: by 2002:a65:6541:: with SMTP id a1mr15338617pgw.409.1560326677811; Wed, 12 Jun 2019 01:04:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560326677; cv=none; d=google.com; s=arc-20160816; b=hDZoeWLN9W7+gRJkRmKfd+nwx8c+LZlNaZNMaHbWtK+cb03jiZl4SLsHku8qZD/Wlt rpPU0nHVe6DDsLoDl8hs6V43gfVNjlAML2jQI0Gz4H61nOVCAb0DFf/4UVO7V4nRINgw b57TKuCdRQ/Gcu1KoJq6XeEBWw2juH89Vb0SBzA2zEuqovGBz8Wh+bDooatU9c71INnW NziOXounDXCtzDsVVMvni1Dkg/PahNJMAm+10Zc+kY+90aAGPNro5Bk/5kMbDF17r5nh Z2sWFWjoldwwp34v/Zx6Y95gmPcQbUUGmLEVAQymdB+W+fPlfAjl2lmvo4UJPKmN4DpS yUMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=MEsvB5fyfvbyP3599I1p81WWc20wTxokr+RDfF0sbmk=; b=CVduEVgRoBYVghgYHPrM+IvESPFc8puOsBje35+gw/IAZV6Fi/PdbuQWjPh2v0mD7p uLworyJq5TPLtjZylYsC/Y/3NPBF/0JBWgrAayVtOgIH7xYRzXXD5qH964GWprvgdnA2 C43oyNpJPrnE3KtqLJuMIoyv+SAqb9oE6g/9vVQkiZnTv1aAOLRzFItTO3pRabVtrhgH zmOFRl6jOKhzuQg8ArLp6KJzY+qmw5bkC1eTB+pjtcvd7qIbQRzHJAH4tOHUKS/h2Byc X3uj0WuXGJ/PQTMPSvDWztBqd02jY6J/TyCAlq5euNX+//Vw877SvP/94xXrdgw2sm2l RVvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MMp6AnWD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h36si15038623plb.199.2019.06.12.01.04.20; Wed, 12 Jun 2019 01:04:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MMp6AnWD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730634AbfFLFp3 (ORCPT + 99 others); Wed, 12 Jun 2019 01:45:29 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:35542 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726593AbfFLFp3 (ORCPT ); Wed, 12 Jun 2019 01:45:29 -0400 Received: by mail-io1-f66.google.com with SMTP id m24so11971519ioo.2 for ; Tue, 11 Jun 2019 22:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MEsvB5fyfvbyP3599I1p81WWc20wTxokr+RDfF0sbmk=; b=MMp6AnWDzd6KBcaZ05OJj4lxPNM4qSHKTHwrNpVrZ6ybQr2zPK2djNtQPFmTBjpyxx 3zMDD1ABcGN/hggjsojOwF5gDw0N019Go6xCg+jQbC7QiDEBY5KDb8L7w52J7wk6djL7 LevIYXcqmW6kumT1P6CdW1N6dlNJqSod/jQGwFyfrxO9KW3vg1O+AbvCxC9omfwpbJwx Dnu/RNlSn4zHBIhPOU5lxN6jS8ksoqnzLrUm1/ofe2JegPxv5OcJh4+TmeVXvmsYE0mh 8fSnavXYZBZDpnWmzWzIOiaOrHny6a71h2HBLD95a417HOxtpPywxe2+A16PcESVS/06 pheg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MEsvB5fyfvbyP3599I1p81WWc20wTxokr+RDfF0sbmk=; b=lWK2GoOsbXV0A7SHJKNemDQJGTSxAGC/dq4UIMT32/uey/ZtKjl+qdvAx1YF9PVS3X UkIj7qIejWfIgQiY2ouSILgWCt1WLtUeJ+UjJpwCNKZhZyUqlOpC9EfAyP73MLAlJBbA s9r3JfMOyiWchi/rxEjbhKvcmWexoeDLOM28S6ERVzY4mFgthj3Suibrw1ChPIXbYiQd 0tDlFIdfu1qGkrdY7xOzjsJUha2x9rqHbdt1NLuiCNZSVbikk+GavhE4iybmG0g2hKyq xyQ71OnikGS4MucWVhwhCX43yjJQuq+kHt1UiEHV0LiV/2oiYsiTYw3SGd3kZiR07LV2 Z+Gw== X-Gm-Message-State: APjAAAVqW4hP5CyEw5KRl80TrPe+934Qrhj/Wudkbt0gU1DVY2Am6zHJ JTNApF7NNiyuzoXgnUrPjJyeWn+WNW/bHuFpIfM= X-Received: by 2002:a5e:c70c:: with SMTP id f12mr31599418iop.293.1560318328476; Tue, 11 Jun 2019 22:45:28 -0700 (PDT) MIME-Version: 1.0 References: <20190611092144.11194-1-oded.gabbay@gmail.com> <20190611095857.GB24058@kroah.com> <20190611151753.GA11404@infradead.org> <20190611152655.GA3972@kroah.com> In-Reply-To: From: "Oliver O'Halloran" Date: Wed, 12 Jun 2019 15:45:17 +1000 Message-ID: Subject: Re: [PATCH v2 8/8] habanalabs: enable 64-bit DMA mask in POWER9 To: Benjamin Herrenschmidt Cc: Oded Gabbay , Greg KH , linuxppc-dev@ozlabs.org, Christoph Hellwig , Russell Currey , "Linux-Kernel@Vger. Kernel. Org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 12, 2019 at 8:54 AM Benjamin Herrenschmidt wrote: > > On Tue, 2019-06-11 at 20:22 +0300, Oded Gabbay wrote: > > > > > So, to summarize: > > > If I call pci_set_dma_mask with 48, then it fails on POWER9. However, > > > in runtime, I don't know if its POWER9 or not, so upon failure I will > > > call it again with 32, which makes our device pretty much unusable. > > > If I call pci_set_dma_mask with 64, and do the dedicated configuration > > > in Goya's PCIe controller, then it won't work on x86-64, because bit > > > 59 will be set and the host won't like it (I checked it). In addition, > > > I might get addresses above 50 bits, which my device can't generate. > > > > > > I hope this makes things more clear. Now, please explain to me how I > > > can call pci_set_dma_mask without any regard to whether I run on > > > x86-64 or POWER9, considering what I wrote above ? > > > > > > Thanks, > > > Oded > > > > Adding ppc mailing list. > > You can't. Your device is broken. Devices that don't support DMAing to > the full 64-bit deserve to be added to the trash pile. > > As a result, getting it to work will require hacks. Some GPUs have > similar issues and require similar hacks, it's unfortunate. > > Added a couple of guys on CC who might be able to help get those hacks > right. > It's still very fishy .. the idea is to detect the case where setting a > 64-bit mask will give your system memory mapped at a fixed high address > (1 << 59 in our case) and program that in your chip in the "Fixed high > bits" register that you seem to have (also make sure it doesn't affect > MSIs or it will break them). Judging from the patch (https://lkml.org/lkml/2019/6/11/59) this is what they're doing. Also, are you sure about the MSI thing? The IODA3 spec says the only important bits for a 64bit MSI are bits 61:60 (to hit the window) and the lower bits that determine what IVE to use. Everything in between is ignored so ORing in bit 59 shouldn't break anything. > This will only work as long as all of the system memory can be > addressed at an offset from that fixed address that itself fits your > device addressing capabilities (50 bits in this case). It may or may > not be the case but there's no way to check since the DMA mask logic > won't really apply. > > You might want to consider fixing your HW in the next iteration... This > is going to bite you when x86 increases the max physical memory for > example, or on other architectures. Yes, do this. The easiest way to avoid this sort of wierd hack is to just design the PCIe interface to the spec in the first place.