Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp597430ybc; Tue, 12 Nov 2019 06:28:34 -0800 (PST) X-Google-Smtp-Source: APXvYqwzhbZD+arXZEOoKvr9FnOnbr0N5pPhm6szpDVXkRARr6YMR5WD9iAHoXAIFEaE1TspHgZV X-Received: by 2002:a17:906:f10:: with SMTP id z16mr9098541eji.211.1573568914267; Tue, 12 Nov 2019 06:28:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573568914; cv=none; d=google.com; s=arc-20160816; b=ijho3+AVUgBhX0s0VXxdUCCQ+y6D22oUxwooeZcQez7ufLBWcpzrIgQ2Uq4Vzcr/DB KbWLVI5/SNU9CxJfOBKFmPYxjJ9qr18f6lF6LTO9esGCjqgwURXjP9B5zudv57RamTNP z81Dq/+onpVAUQcmaqj0/d8HDVTLf9o5fhsnM63Tpbi1cvwrc36tjmWG8kDnBy4x4ys3 +JOMe7pVtvT4RJ5y/wg2JfayYzHyYHoMKONev/lclyDAh+OUqHMxB+eirOib7cZNmeEx hHg9t3KsEBKpu/SNi6YL5m6lLeZsNczmn9dlvzqOk+U4Q5RCIwvHvmtefzCgrjbuYhxz mW8A== 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=vOq3Ga6TU7d+OBIVxdc75mj6tT8YQYRdorOOD6OFfXY=; b=Sp2cRCMgvQx6zNQhURaiZG1BuqFoRTGJUDHnqegss0hBSg7FEVZfP6OQRRLJj8uFd2 xCqOZPi43mZRFsHerk7GItCgWke77nem8ROXKb65CoB+afjG/B3KWAoWODUID0h/9HTK 4I6LtKu2g9o7l/ptGcurRMjuuaPzIOerUtStf9in0IOvBCXi9oQ61lbnT6ZjC6nQq+Hz +oPhWufiZJZEDoQjGOwc9fjbw9i+kdcXxxa4ct/YiXOGtYo5rTRJde9cebSnemTy7k/g UoI5Lxne1pWrNe9VkupCkCguTga7IMYBIN6pJBKUdW4h4lBF3HdADPyiFYkmc3BhgYQX xNBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=BxRrXJzC; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o2si14351260edj.290.2019.11.12.06.28.10; Tue, 12 Nov 2019 06:28:34 -0800 (PST) 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=@ffwll.ch header.s=google header.b=BxRrXJzC; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727827AbfKLO0t (ORCPT + 99 others); Tue, 12 Nov 2019 09:26:49 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:39584 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727794AbfKLO0s (ORCPT ); Tue, 12 Nov 2019 09:26:48 -0500 Received: by mail-oi1-f193.google.com with SMTP id v138so14915634oif.6 for ; Tue, 12 Nov 2019 06:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vOq3Ga6TU7d+OBIVxdc75mj6tT8YQYRdorOOD6OFfXY=; b=BxRrXJzCCx1hIyEvZSBVA0yZXvf4Od5JT6l96C9dyN0qzywU8gAzJY+k+1FXxp5U8b mjqYVSvosbEgInhTINXOvCrJh8KWb8Cq/gr9rEqAPGz2C4d7Q6wn4rqp9tqzAZjAWs82 j6Ape7bP7RYA6XvgX0LqZl9CF1t26JVGPpTz8= 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=vOq3Ga6TU7d+OBIVxdc75mj6tT8YQYRdorOOD6OFfXY=; b=g2V1wDS8Ty/gMz9WM/H8gMFHhg+yvWyVKuHoj6+jDtU4haSivZu41tLAhVxRzbz1yG OIAQO200J6UdE/KL98HVNqU1QVR9zH1TY+anh+oc7OHRarm9Y5SAOf6WOQPXzbo3p3Xf Eepc0wpKmfcdxiEycK49xUkpfUULJHocco0RyHCx+OiaMWjz6UqI9zC9JgR/Sksr17Fq tlnuR2AoUjqTxnvLsNK0oT5qLEcvuWoFE33FK2o0t9obLBx7X0AoaNfpsqD0Y3ZRndmO 1EDIdbe53C4UdIcn+NRZAo70klMUCOYY07Lks6G+q1o2MlI736+LwiFwyCba/xAt6a5i TIBQ== X-Gm-Message-State: APjAAAX/3FsZisXy3Zd/5R2OaQ39/vPHMbf26XmRpqNv+YKKlmjf/z0M 6xfcuiAoHfOwf4EscqmEii8xKVfU2nbZtRNx6/OEqA== X-Received: by 2002:aca:ead7:: with SMTP id i206mr4359423oih.128.1573568807592; Tue, 12 Nov 2019 06:26:47 -0800 (PST) MIME-Version: 1.0 References: <20191111192258.2234502-1-arnd@arndb.de> <20191112105507.GA7122@lst.de> <20191112140631.GA10922@lst.de> In-Reply-To: <20191112140631.GA10922@lst.de> From: Daniel Vetter Date: Tue, 12 Nov 2019 15:26:35 +0100 Message-ID: Subject: Re: [PATCH] video: fbdev: atyfb: only use ioremap_uc() on i386 and ia64 To: Christoph Hellwig , Tuowen Zhao , AceLan Kao , Mika Westerberg , Andy Shevchenko , Roman Gilg , Lee Jones , "Luis R. Rodriguez" Cc: Arnd Bergmann , Bartlomiej Zolnierkiewicz , X86 ML , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , linux-ia64@vger.kernel.org, Tony Luck , Fenghua Yu , Maarten Lankhorst , Souptick Joarder , dri-devel , Linux Fbdev development list , Linux Kernel Mailing List , Luis Chamberlain 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 Tue, Nov 12, 2019 at 3:06 PM Christoph Hellwig wrote: > On Tue, Nov 12, 2019 at 02:04:16PM +0100, Daniel Vetter wrote: > > Wut ... Maybe I'm missing something, but from how we use mtrr in other > > gpu drivers it's a) either you use MTRR because that's all you got or > > b) you use pat. Mixing both sounds like a pretty bad idea, since if > > you need MTRR for performance (because you dont have PAT) then you > > can't fix the wc with the PAT-based ioremap_uc. And if you have PAT, > > then you don't really need an MTRR to get wc. > > > > So I'd revert this patch from Luis and ... > > Sounds great to me.. > > > ... apply this one. Since the same reasoning should apply to anything > > that's running on any cpu with PAT. > > Can you take a look at "mfd: intel-lpss: Use devm_ioremap_uc for MMIO" > in linux-next, which also looks rather fishy to me? Can't we use > the MTRR APIs to override the broken BIOS MTRR setup there as well? Hm so that's way out of my knowledge, but I think mtrr_cleanup() was supposed to fix up messy/broken MTRR setups by the bios. So maybe they simply didn't enable that in their .config with CONFIG_MTRR_SANITIZER. An explicit cleanup is currently not possible for drivers, since the only interface exported to drivers is arch_phys_wc_add/del (which short-circuits if pat works since you don't need mtrr in that case). Adding everyone from that commit, plus Luis. Drivers really shouldn't assume/work around the bios setting up superflous/wrong MTRR. > With that we could kill ioremap_uc entirely. So yeah removing that seems definitely like the right thing. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch