From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Date: Mon, 11 Nov 2019 11:15:31 +0100 Message-ID: <20191111101531.GA12294@lst.de> References: <20191029064834.23438-1-hch@lst.de> <20191029064834.23438-11-hch@lst.de> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Arnd Bergmann Cc: Christoph Hellwig , Guo Ren , Michal Simek , Greentime Hu , Vincent Chen , Guan Xuetao , the arch/x86 maintainers , alpha , "open list:SYNOPSYS ARC ARCHITECTURE" , Linux ARM , "open list:QUALCOMM HEXAGON..." , linux-ia64@vger.kernel.org, linux-m68k , linux-mips@vger.kernel.org, "moderated list:NIOS2 ARCHITECTURE" , openrisc@lists.librecores.org, Parisc List , linux-riscv@lists.infradead.org, li On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote: > Maybe we could move the definition into the atyfb driver itself? > > As I understand it, the difference between ioremap()/ioremap_nocache() > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5, > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86, > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms > anyway. That's not how I understood it. Based on the code and the UC- explanation ioremap_uc always overrides the MTRR, which can still be present on more modern x86 systems. In fact I remember a patch floating around very recently adding another ioremap_uc caller in some Atom platform device driver that works around buggy MTRR tables. Also this series actually adds a new override and a few callers for ia64 platform code, which works very similar to x86 based on the comments in the code. That being said I'm not sure the callers in ia64 are really required, but it was the safest thing to do as part of this cleanup. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Date: Mon, 11 Nov 2019 11:15:31 +0100 Message-ID: <20191111101531.GA12294@lst.de> References: <20191029064834.23438-1-hch@lst.de> <20191029064834.23438-11-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: Christoph Hellwig , Guo Ren , Michal Simek , Greentime Hu , Vincent Chen , Guan Xuetao , the arch/x86 maintainers , alpha , "open list:SYNOPSYS ARC ARCHITECTURE" , Linux ARM , "open list:QUALCOMM HEXAGON..." , linux-ia64@vger.kernel.org, linux-m68k , linux-mips@vger.kernel.org, "moderated list:NIOS2 ARCHITECTURE" , openrisc@lists.librecores.org, Parisc List , linux-riscv@lists.infradead.orgli List-Id: linux-arch.vger.kernel.org On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote: > Maybe we could move the definition into the atyfb driver itself? > > As I understand it, the difference between ioremap()/ioremap_nocache() > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5, > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86, > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms > anyway. That's not how I understood it. Based on the code and the UC- explanation ioremap_uc always overrides the MTRR, which can still be present on more modern x86 systems. In fact I remember a patch floating around very recently adding another ioremap_uc caller in some Atom platform device driver that works around buggy MTRR tables. Also this series actually adds a new override and a few callers for ia64 platform code, which works very similar to x86 based on the comments in the code. That being said I'm not sure the callers in ia64 are really required, but it was the safest thing to do as part of this cleanup. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de ([213.95.11.211]:48523 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726829AbfKKKPg (ORCPT ); Mon, 11 Nov 2019 05:15:36 -0500 Date: Mon, 11 Nov 2019 11:15:31 +0100 From: Christoph Hellwig Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Message-ID: <20191111101531.GA12294@lst.de> References: <20191029064834.23438-1-hch@lst.de> <20191029064834.23438-11-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann Cc: Christoph Hellwig , Guo Ren , Michal Simek , Greentime Hu , Vincent Chen , Guan Xuetao , the arch/x86 maintainers , alpha , "open list:SYNOPSYS ARC ARCHITECTURE" , Linux ARM , "open list:QUALCOMM HEXAGON..." , linux-ia64@vger.kernel.org, linux-m68k , linux-mips@vger.kernel.org, "moderated list:NIOS2 ARCHITECTURE" , openrisc@lists.librecores.org, Parisc List , linux-riscv@lists.infradead.org, linux-s390 , Linux-sh list , sparclinux , linux-xtensa@linux-xtensa.org, linux-mtd , linux-arch , "linux-kernel@vger.kernel.org" Message-ID: <20191111101531.J5Dyln5gVSFnLI4rqtj3_15Gn6amyRmwCO6Wf2sacy4@z> On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote: > Maybe we could move the definition into the atyfb driver itself? > > As I understand it, the difference between ioremap()/ioremap_nocache() > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5, > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86, > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms > anyway. That's not how I understood it. Based on the code and the UC- explanation ioremap_uc always overrides the MTRR, which can still be present on more modern x86 systems. In fact I remember a patch floating around very recently adding another ioremap_uc caller in some Atom platform device driver that works around buggy MTRR tables. Also this series actually adds a new override and a few callers for ia64 platform code, which works very similar to x86 based on the comments in the code. That being said I'm not sure the callers in ia64 are really required, but it was the safest thing to do as part of this cleanup. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Mon, 11 Nov 2019 10:15:31 +0000 Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Message-Id: <20191111101531.GA12294@lst.de> List-Id: References: <20191029064834.23438-1-hch@lst.de> <20191029064834.23438-11-hch@lst.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Arnd Bergmann Cc: Christoph Hellwig , Guo Ren , Michal Simek , Greentime Hu , Vincent Chen , Guan Xuetao , the arch/x86 maintainers , alpha , "open list:SYNOPSYS ARC ARCHITECTURE" , Linux ARM , "open list:QUALCOMM HEXAGON..." , linux-ia64@vger.kernel.org, linux-m68k , linux-mips@vger.kernel.org, "moderated list:NIOS2 ARCHITECTURE" , openrisc@lists.librecores.org, Parisc List , linux-riscv@lists.infradead.orgli On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote: > Maybe we could move the definition into the atyfb driver itself? > > As I understand it, the difference between ioremap()/ioremap_nocache() > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5, > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86, > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms > anyway. That's not how I understood it. Based on the code and the UC- explanation ioremap_uc always overrides the MTRR, which can still be present on more modern x86 systems. In fact I remember a patch floating around very recently adding another ioremap_uc caller in some Atom platform device driver that works around buggy MTRR tables. Also this series actually adds a new override and a few callers for ia64 platform code, which works very similar to x86 based on the comments in the code. That being said I'm not sure the callers in ia64 are really required, but it was the safest thing to do as part of this cleanup. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57DD8C43331 for ; Mon, 11 Nov 2019 10:16:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 286A5206BB for ; Mon, 11 Nov 2019 10:16:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="W0BsSCrt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 286A5206BB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dvGChW21syPV9Uf19pAFVjf8i34m2FWyUnUErez3O98=; b=W0BsSCrtGQVinf daAAOHt4j52RSIAihwSY+xPQtqINbNCppW23Waq0PozlPxG2+TTRP8Dnf1r8hkQTcrkt3YAIuJWgg 5ButF5ExX75ey+XApzjk8KXeCOuJCD9WuQs5exdOwAEy/qXGYion9ffIt70eHKdnaToU3lIM5IV8b WCpEc1pflERBCNnCB+GFt2E0B5FdV2koySM+oRUyCBVjhlvUyW6OvjdnhsYG2mqOtVJ+Nf/yxosmO YeBXmWWFu44zGJbb4ZvvHLJqMNSE+yPp9A7YdAjzjxuDJbuTxMUnqheRlwZh1wuqFEcxQKbBrYTs9 v9JhXLmbjS1lEZNhKzBQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iU6ja-00085o-RT; Mon, 11 Nov 2019 10:15:46 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iU6jO-0007w5-JL; Mon, 11 Nov 2019 10:15:35 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 8B1EE68BE1; Mon, 11 Nov 2019 11:15:31 +0100 (CET) Date: Mon, 11 Nov 2019 11:15:31 +0100 From: Christoph Hellwig To: Arnd Bergmann Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Message-ID: <20191111101531.GA12294@lst.de> References: <20191029064834.23438-1-hch@lst.de> <20191029064834.23438-11-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191111_021534_784127_CBD7C181 X-CRM114-Status: UNSURE ( 9.63 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, Linux-sh list , "linux-kernel@vger.kernel.org" , Guo Ren , sparclinux , linux-riscv@lists.infradead.org, Vincent Chen , Christoph Hellwig , linux-arch , linux-s390 , "open list:QUALCOMM HEXAGON..." , the arch/x86 maintainers , "open list:SYNOPSYS ARC ARCHITECTURE" , linux-xtensa@linux-xtensa.org, linux-m68k , openrisc@lists.librecores.org, Greentime Hu , linux-mtd , Guan Xuetao , Linux ARM , Michal Simek , Parisc List , linux-mips@vger.kernel.org, alpha , "moderated list:NIOS2 ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote: > Maybe we could move the definition into the atyfb driver itself? > > As I understand it, the difference between ioremap()/ioremap_nocache() > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5, > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86, > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms > anyway. That's not how I understood it. Based on the code and the UC- explanation ioremap_uc always overrides the MTRR, which can still be present on more modern x86 systems. In fact I remember a patch floating around very recently adding another ioremap_uc caller in some Atom platform device driver that works around buggy MTRR tables. Also this series actually adds a new override and a few callers for ia64 platform code, which works very similar to x86 based on the comments in the code. That being said I'm not sure the callers in ia64 are really required, but it was the safest thing to do as part of this cleanup. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10CB6C17445 for ; Mon, 11 Nov 2019 10:16:03 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DA507206BB for ; Mon, 11 Nov 2019 10:16:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FJ+scLcj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DA507206BB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WxtS0bNIJFFRKGwY14YC6eg7ZCtqDc7z+JwfkYlN70c=; b=FJ+scLcjCf7nOF AJOSJwNQRdOAUsWzm4bZdC2A88ZL7EH5dHrBJxjRl/9/8R5T7syX2aRvIJGRK+2pvv7B2KDaDnp9Z hyh0LR7aRzD3VEx4IfQ0HuiOttLOAxti5HEGtrI/9FHmfOvML5nFzMfX6BpgROD/nY07ADWFcjmGu P6haSlXMEXe6HMXFCDagY/xGd9RbFIdRWb4nXDaMoESHSqxvkuiH1yJPSk4mBgR5YKJs+d0TlYY0b X28iWAxu0RTon1XjI9qdUhTBPnwUu8AoS42urEY8VGu4cV+2E0U2Tvdp9jH54uhj43IUkCPezEJ11 CjJTTa6pTTQ3AU3cCGmw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iU6jp-0008PO-Fs; Mon, 11 Nov 2019 10:16:01 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iU6jO-0007w5-JL; Mon, 11 Nov 2019 10:15:35 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 8B1EE68BE1; Mon, 11 Nov 2019 11:15:31 +0100 (CET) Date: Mon, 11 Nov 2019 11:15:31 +0100 From: Christoph Hellwig To: Arnd Bergmann Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Message-ID: <20191111101531.GA12294@lst.de> References: <20191029064834.23438-1-hch@lst.de> <20191029064834.23438-11-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191111_021534_784127_CBD7C181 X-CRM114-Status: UNSURE ( 9.63 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, Linux-sh list , "linux-kernel@vger.kernel.org" , Guo Ren , sparclinux , linux-riscv@lists.infradead.org, Vincent Chen , Christoph Hellwig , linux-arch , linux-s390 , "open list:QUALCOMM HEXAGON..." , the arch/x86 maintainers , "open list:SYNOPSYS ARC ARCHITECTURE" , linux-xtensa@linux-xtensa.org, linux-m68k , openrisc@lists.librecores.org, Greentime Hu , linux-mtd , Guan Xuetao , Linux ARM , Michal Simek , Parisc List , linux-mips@vger.kernel.org, alpha , "moderated list:NIOS2 ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+infradead-linux-riscv=archiver.kernel.org@lists.infradead.org On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote: > Maybe we could move the definition into the atyfb driver itself? > > As I understand it, the difference between ioremap()/ioremap_nocache() > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5, > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86, > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms > anyway. That's not how I understood it. Based on the code and the UC- explanation ioremap_uc always overrides the MTRR, which can still be present on more modern x86 systems. In fact I remember a patch floating around very recently adding another ioremap_uc caller in some Atom platform device driver that works around buggy MTRR tables. Also this series actually adds a new override and a few callers for ia64 platform code, which works very similar to x86 based on the comments in the code. That being said I'm not sure the callers in ia64 are really required, but it was the safest thing to do as part of this cleanup. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D96AC43331 for ; Mon, 11 Nov 2019 10:16:06 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4DD48206BB for ; Mon, 11 Nov 2019 10:16:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jCEJVymc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4DD48206BB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0hFRRvp9uz81K547Ff8t7tmkTvAtbTGkZblhMVme9OM=; b=jCEJVymcFOPS8Z 1/xxph7GzB4rOJPSXRav8QQfwmgUPhbqByffqihlw6lgIRsfmfKc6I4O3fOc7Jiutg4Rf7ohv4VH1 y33NAodbFZR4wo/dCh3FXnNi02wyBqLAbxPJu+x7lqN45AnuV9+6LgPhciBS1/1qKQ6yGTP5HBGb8 bjdokyeBRugHf3J1JVsDDqAtT9SJfNrbmF1Bh0mvXckNiVVlismRqPFCTrP9CHSqmdK2rHtkqTuxN WJyBlECq9nZgVl8kJziuZ+45JPDZcnzJNiyDEqTTGzaIvoFpbpyBPaphsiMfeuJyeUAwUgXCTptK9 pWiZXD1AX98eoM2kxcXA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iU6jt-0008TX-4N; Mon, 11 Nov 2019 10:16:05 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iU6jO-0007w5-JL; Mon, 11 Nov 2019 10:15:35 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 8B1EE68BE1; Mon, 11 Nov 2019 11:15:31 +0100 (CET) Date: Mon, 11 Nov 2019 11:15:31 +0100 From: Christoph Hellwig To: Arnd Bergmann Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Message-ID: <20191111101531.GA12294@lst.de> References: <20191029064834.23438-1-hch@lst.de> <20191029064834.23438-11-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191111_021534_784127_CBD7C181 X-CRM114-Status: UNSURE ( 9.63 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, Linux-sh list , "linux-kernel@vger.kernel.org" , Guo Ren , sparclinux , linux-riscv@lists.infradead.org, Vincent Chen , Christoph Hellwig , linux-arch , linux-s390 , "open list:QUALCOMM HEXAGON..." , the arch/x86 maintainers , "open list:SYNOPSYS ARC ARCHITECTURE" , linux-xtensa@linux-xtensa.org, linux-m68k , openrisc@lists.librecores.org, Greentime Hu , linux-mtd , Guan Xuetao , Linux ARM , Michal Simek , Parisc List , linux-mips@vger.kernel.org, alpha , "moderated list:NIOS2 ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote: > Maybe we could move the definition into the atyfb driver itself? > > As I understand it, the difference between ioremap()/ioremap_nocache() > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5, > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86, > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms > anyway. That's not how I understood it. Based on the code and the UC- explanation ioremap_uc always overrides the MTRR, which can still be present on more modern x86 systems. In fact I remember a patch floating around very recently adding another ioremap_uc caller in some Atom platform device driver that works around buggy MTRR tables. Also this series actually adds a new override and a few callers for ia64 platform code, which works very similar to x86 based on the comments in the code. That being said I'm not sure the callers in ia64 are really required, but it was the safest thing to do as part of this cleanup. _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Mon, 11 Nov 2019 11:15:31 +0100 Subject: [OpenRISC] [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU In-Reply-To: References: <20191029064834.23438-1-hch@lst.de> <20191029064834.23438-11-hch@lst.de> Message-ID: <20191111101531.GA12294@lst.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: openrisc@lists.librecores.org On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote: > Maybe we could move the definition into the atyfb driver itself? > > As I understand it, the difference between ioremap()/ioremap_nocache() > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5, > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86, > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms > anyway. That's not how I understood it. Based on the code and the UC- explanation ioremap_uc always overrides the MTRR, which can still be present on more modern x86 systems. In fact I remember a patch floating around very recently adding another ioremap_uc caller in some Atom platform device driver that works around buggy MTRR tables. Also this series actually adds a new override and a few callers for ia64 platform code, which works very similar to x86 based on the comments in the code. That being said I'm not sure the callers in ia64 are really required, but it was the safest thing to do as part of this cleanup. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D9B8C43331 for ; Mon, 11 Nov 2019 10:15:41 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3260E214E0 for ; Mon, 11 Nov 2019 10:15:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Htp9KD08" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3260E214E0 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WnfPndWeX0mUsuAklT2o//R5OYl4xvQ+qR7VAwKKQLU=; b=Htp9KD08uLJaH7 LxojPnyA0TBnOk3rg7RE4tStNrVqiK6G50I+Rptor2uG2pkxJhiGhg/d1DQwpD6U4pGFwNA31Fruh M5RdMoNq8gKMOWPilx4/XLIiGCgMxSmoJWbgTIiaEtI4QAWAZIMfKgZWIJcHngooz2eK8e+inn3yx lhA1bn+BpaJ1cx6vzTZ0N0b3ATwWogoD7B4ZM/XDtwuGo/kaZhqrftynCdkLPiPU5W45ksxWN6szF 7DIIehmrzqsnnrAx744erFJ6Lszwyuo2Wc4jqN/m8ONQX/BVqeitfd2edku8syCdtnTxZdbqU7yBQ RwRQ+UafYuid0SrDNk1w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iU6jR-0007wp-W4; Mon, 11 Nov 2019 10:15:37 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iU6jO-0007w5-JL; Mon, 11 Nov 2019 10:15:35 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 8B1EE68BE1; Mon, 11 Nov 2019 11:15:31 +0100 (CET) Date: Mon, 11 Nov 2019 11:15:31 +0100 From: Christoph Hellwig To: Arnd Bergmann Subject: Re: [PATCH 10/21] asm-generic: ioremap_uc should behave the same with and without MMU Message-ID: <20191111101531.GA12294@lst.de> References: <20191029064834.23438-1-hch@lst.de> <20191029064834.23438-11-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191111_021534_784127_CBD7C181 X-CRM114-Status: UNSURE ( 9.63 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, Linux-sh list , "linux-kernel@vger.kernel.org" , Guo Ren , sparclinux , linux-riscv@lists.infradead.org, Vincent Chen , Christoph Hellwig , linux-arch , linux-s390 , "open list:QUALCOMM HEXAGON..." , the arch/x86 maintainers , "open list:SYNOPSYS ARC ARCHITECTURE" , linux-xtensa@linux-xtensa.org, linux-m68k , openrisc@lists.librecores.org, Greentime Hu , linux-mtd , Guan Xuetao , Linux ARM , Michal Simek , Parisc List , linux-mips@vger.kernel.org, alpha , "moderated list:NIOS2 ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Nov 11, 2019 at 11:09:05AM +0100, Arnd Bergmann wrote: > Maybe we could move the definition into the atyfb driver itself? > > As I understand it, the difference between ioremap()/ioremap_nocache() > and ioremap_uc() only exists on pre-PAT x86-32 systems (i.e. 486, P5, > Ppro, PII, K6, VIA C3), while on more modern systems (all non-x86, > PentiumIII, Athlon, VIA C7) those three are meant to be synonyms > anyway. That's not how I understood it. Based on the code and the UC- explanation ioremap_uc always overrides the MTRR, which can still be present on more modern x86 systems. In fact I remember a patch floating around very recently adding another ioremap_uc caller in some Atom platform device driver that works around buggy MTRR tables. Also this series actually adds a new override and a few callers for ia64 platform code, which works very similar to x86 based on the comments in the code. That being said I'm not sure the callers in ia64 are really required, but it was the safest thing to do as part of this cleanup. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel