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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 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 843CAC282DD for ; Fri, 10 Jan 2020 15:08:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 59EC62077C for ; Fri, 10 Jan 2020 15:08:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728305AbgAJPIo (ORCPT ); Fri, 10 Jan 2020 10:08:44 -0500 Received: from foss.arm.com ([217.140.110.172]:46356 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728152AbgAJPIo (ORCPT ); Fri, 10 Jan 2020 10:08:44 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 15CEA30E; Fri, 10 Jan 2020 07:08:43 -0800 (PST) Received: from donnerap.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EF6973F6C4; Fri, 10 Jan 2020 07:08:41 -0800 (PST) Date: Fri, 10 Jan 2020 15:08:36 +0000 From: Andre Przywara To: Andrew Lunn Cc: "David S . Miller" , Radhey Shyam Pandey , Michal Simek , Robert Hancock , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 12/14] net: axienet: Autodetect 64-bit DMA capability Message-ID: <20200110150836.1f92a0a8@donnerap.cambridge.arm.com> In-Reply-To: <20200110142250.GH19739@lunn.ch> References: <20200110115415.75683-1-andre.przywara@arm.com> <20200110115415.75683-13-andre.przywara@arm.com> <20200110140852.GF19739@lunn.ch> <20200110141303.2e5863ab@donnerap.cambridge.arm.com> <20200110142250.GH19739@lunn.ch> Organization: ARM X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; aarch64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 10 Jan 2020 15:22:50 +0100 Andrew Lunn wrote: Hi, > On Fri, Jan 10, 2020 at 02:13:03PM +0000, Andre Przywara wrote: > > On Fri, 10 Jan 2020 15:08:52 +0100 > > Andrew Lunn wrote: > > > > Hi Andrew, > > > > thanks for having a look! > > > > > > To autodetect this configuration, at probe time we write all 1's to such > > > > an MSB register, and see if any bits stick. > > > > > > So there is no register you can read containing the IP version? > > > > There is, and I actually read this before doing this check. But the 64-bit DMA capability is optional even in this revision. It depends on what you give it as the address width. If you say 32, the IP config tool disables the 64-bit capability completely, so it stays compatible with older revisions. > > Anything beyond 32 will enable the MSB register and will also require you to write to them. > > So you are saying there is no way to enumerate the synthesised > configuration of the IP. Great :-( Apparently not. > Do Xilinx at least document you can discover the DMA size by writing > into these upper bits? Does Xilinx own 'vendor crap' driver do this? So far I couldn't be bothered to put my asbestos trousers on and go into BSP land ;-) Now quickly browsing the linux-xlnx github repo suggests they make this MSB register access dependent on CONFIG_PHYS_ADDR_T_64BIT. Which would mean: - A 32-bit kernel on a device configured for >32 bit DMA would not work. - They always write to the MSB registers on 64-bit and (L)PAE kernels. The DMA mask is set to the value of the xlnx,addrwidth, in a similar way I did it in the next patch. Minus the safety check for the 64-bit DMA capability. I got this idea of probing when I saw that those registers are marked as "Reserved" in earlier revisions of the documentation. I couldn't find an exact definition of "Reserved" in that manual, though. Then I confirmed that behaviour by testing this on an image configured for only a 32 bit wide address bus, where those registers are apparently hardwired to zero. So if you were hoping for an official blessing, I have to disappoint you ;-) We could rely completely on the addrwidth property, at the price of it not working when the IP is configured for >32 bits, but the addrwidth property is missing or erroneously set to 32. But I think their: struct xxx { .... phys_addr_t next; /* Physical address of next buffer descriptor */ #ifndef CONFIG_PHYS_ADDR_T_64BIT u32 reserved1; #endif construct is broken, and we should not copy this. Also they do writeq to this register, not sure that's the right thing to do. Cheers, Andre. 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_2 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 782D4C282DD for ; Fri, 10 Jan 2020 15:08:50 +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 438342077C for ; Fri, 10 Jan 2020 15:08:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="PLe2Hsp2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 438342077C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com 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:MIME-Version:References:In-Reply-To: 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=b0LcnKEZM1hRwzHFIxabO4R7HBXKYCtKAv7tP4OKni4=; b=PLe2Hsp2nFzSqH UwIwvf2d28fjxbWkfYNGcBjzy450hSSxYg2QpjK07i8brNZdJTXmKl6IyBKVkt7HgoZ9T3YkfpXI/ 6VYMLpp72o1xvhTagO3KvkqWC+jl8OqEfdPJvTHYaCzmxa3V1/eoNvwUto+9ZORRxu9fa7f8a1JpM HGuOu7Y1yLF+o+hd6MQ4+pLnsuMiaKvyFBVP1Hqf6uEPCehiLTYe/cGr1MU2BaKkQSKEDT/xZYSO3 9gxStxrDY0e/c1lgW619FOQPKalAKXpXtyghlZyR+PPkLyqvFgFjpn5hrVoz8WqOn1hu1ry2nQq4/ oqZbaF+QcIN/9tbNAY5A==; 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 1ipvu3-000796-JI; Fri, 10 Jan 2020 15:08:47 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1ipvtz-00078R-Ux for linux-arm-kernel@lists.infradead.org; Fri, 10 Jan 2020 15:08:45 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 15CEA30E; Fri, 10 Jan 2020 07:08:43 -0800 (PST) Received: from donnerap.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EF6973F6C4; Fri, 10 Jan 2020 07:08:41 -0800 (PST) Date: Fri, 10 Jan 2020 15:08:36 +0000 From: Andre Przywara To: Andrew Lunn Subject: Re: [PATCH 12/14] net: axienet: Autodetect 64-bit DMA capability Message-ID: <20200110150836.1f92a0a8@donnerap.cambridge.arm.com> In-Reply-To: <20200110142250.GH19739@lunn.ch> References: <20200110115415.75683-1-andre.przywara@arm.com> <20200110115415.75683-13-andre.przywara@arm.com> <20200110140852.GF19739@lunn.ch> <20200110141303.2e5863ab@donnerap.cambridge.arm.com> <20200110142250.GH19739@lunn.ch> Organization: ARM X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; aarch64-unknown-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200110_070844_080074_02E221D5 X-CRM114-Status: GOOD ( 19.55 ) 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: netdev@vger.kernel.org, Radhey Shyam Pandey , Michal Simek , linux-kernel@vger.kernel.org, Robert Hancock , "David S . Miller" , linux-arm-kernel@lists.infradead.org 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 Fri, 10 Jan 2020 15:22:50 +0100 Andrew Lunn wrote: Hi, > On Fri, Jan 10, 2020 at 02:13:03PM +0000, Andre Przywara wrote: > > On Fri, 10 Jan 2020 15:08:52 +0100 > > Andrew Lunn wrote: > > > > Hi Andrew, > > > > thanks for having a look! > > > > > > To autodetect this configuration, at probe time we write all 1's to such > > > > an MSB register, and see if any bits stick. > > > > > > So there is no register you can read containing the IP version? > > > > There is, and I actually read this before doing this check. But the 64-bit DMA capability is optional even in this revision. It depends on what you give it as the address width. If you say 32, the IP config tool disables the 64-bit capability completely, so it stays compatible with older revisions. > > Anything beyond 32 will enable the MSB register and will also require you to write to them. > > So you are saying there is no way to enumerate the synthesised > configuration of the IP. Great :-( Apparently not. > Do Xilinx at least document you can discover the DMA size by writing > into these upper bits? Does Xilinx own 'vendor crap' driver do this? So far I couldn't be bothered to put my asbestos trousers on and go into BSP land ;-) Now quickly browsing the linux-xlnx github repo suggests they make this MSB register access dependent on CONFIG_PHYS_ADDR_T_64BIT. Which would mean: - A 32-bit kernel on a device configured for >32 bit DMA would not work. - They always write to the MSB registers on 64-bit and (L)PAE kernels. The DMA mask is set to the value of the xlnx,addrwidth, in a similar way I did it in the next patch. Minus the safety check for the 64-bit DMA capability. I got this idea of probing when I saw that those registers are marked as "Reserved" in earlier revisions of the documentation. I couldn't find an exact definition of "Reserved" in that manual, though. Then I confirmed that behaviour by testing this on an image configured for only a 32 bit wide address bus, where those registers are apparently hardwired to zero. So if you were hoping for an official blessing, I have to disappoint you ;-) We could rely completely on the addrwidth property, at the price of it not working when the IP is configured for >32 bits, but the addrwidth property is missing or erroneously set to 32. But I think their: struct xxx { .... phys_addr_t next; /* Physical address of next buffer descriptor */ #ifndef CONFIG_PHYS_ADDR_T_64BIT u32 reserved1; #endif construct is broken, and we should not copy this. Also they do writeq to this register, not sure that's the right thing to do. Cheers, Andre. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel