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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 DFAD0C10F05 for ; Thu, 4 Apr 2019 05:41:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id AC9052133D for ; Thu, 4 Apr 2019 05:41:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="WbSng2aR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726618AbfDDFlg (ORCPT ); Thu, 4 Apr 2019 01:41:36 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:36718 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726031AbfDDFlg (ORCPT ); Thu, 4 Apr 2019 01:41:36 -0400 Received: by mail-wr1-f68.google.com with SMTP id y13so1937245wrd.3 for ; Wed, 03 Apr 2019 22:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PQzyq/pD246NAZfNEoxnAusNg1XluHoy5IqpEkx2rQ0=; b=WbSng2aRyy0O1EZQAK09lHWeYdLvSgPJ2rF1yOD+Nha9UKl8ObftVsXQymd4tiCDgU 9QsGA2TnT3KTjaduQIlaUCISrtnKiFP0TR/b3fNnEOX0lM7FLT5tyaH04nHLFYxxYUbi SKdL3kEwXIM7PkynYCYEWSqXsga8pXnwzGWTw= 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=PQzyq/pD246NAZfNEoxnAusNg1XluHoy5IqpEkx2rQ0=; b=PJaAx+VB2rINVdDQSK2rxxa9UiHZUiM2npRlrxwxwDZzw12+vI1qKExQyebhzrNvX4 QFoAC+BuIoSz8nj+Y8eQ6mX5CNgK5joOeNGlSa6fS3g2WzJTBSFEWfW/yKJgq6yWBg3J G0ZrdhwxvaDiT+cz8NZw29uz/nS7t2lyUj/wQJX7NyioCCVT/syD6LEOcZbbr1s1wXpm XzfZTVwqR3eQJ/BRJZ/QjiltvnXFQlM//jxWmZvd/T5Qat7/qjDiYZMbbe3ak2n96UhE bfKrFKmCmBvR8RnFqw9w6ZvHi9mZ30dLTn9DlgVIKLwRVGkmmlsW326Yq/a+oxyjn8B7 95Hw== X-Gm-Message-State: APjAAAU4LXYvvM/4beic/SxXxieMPSfKGRjsW6FmJAts+lZGkVAXt0kK fOPgx4+5JwUf5dauZrowPG6Rm9EYRD1H1BkqsFRjhw== X-Google-Smtp-Source: APXvYqxB/9RznvrIwJYGZIRwMIYu8hLE7kMquXzytzOWHppTDc06gFKm7WogSh/ebBT//x/5Vq9ZqmdpAodBGBProZc= X-Received: by 2002:adf:e790:: with SMTP id n16mr2291635wrm.292.1554356493939; Wed, 03 Apr 2019 22:41:33 -0700 (PDT) MIME-Version: 1.0 References: <1551415936-30174-3-git-send-email-srinath.mannam@broadcom.com> <20190329173515.GA10367@e107981-ln.cambridge.arm.com> <20190401164416.GA8616@e107981-ln.cambridge.arm.com> <20190402102639.GB22708@e107981-ln.cambridge.arm.com> <20190402133851.GA26122@e107981-ln.cambridge.arm.com> <20190403113124.GA16233@e107981-ln.cambridge.arm.com> In-Reply-To: <20190403113124.GA16233@e107981-ln.cambridge.arm.com> From: Srinath Mannam Date: Thu, 4 Apr 2019 11:11:22 +0530 Message-ID: Subject: Re: [PATCH v4 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region To: Lorenzo Pieralisi Cc: Ray Jui , Bjorn Helgaas , Ray Jui , Scott Branden , BCM Kernel Feedback , linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Linux Kernel Mailing List , Abhishek Shah 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 Hi Lorenzo, I am sorry, I took your long time. In my commit log I gave details about purpose of feature instead of implementation. Thanks a lot for all inputs and knowledge. I will remember and follow these notes while writing commit log. commit log re-written by you is very much impressive and have detailed description of feature and implementation. Thank again for you patience. Regards, Srinath. On Wed, Apr 3, 2019 at 5:01 PM Lorenzo Pieralisi wrote: > > On Wed, Apr 03, 2019 at 08:41:44AM +0530, Srinath Mannam wrote: > > Hi Lorenzo, > > > > Please see my reply below, > > > > On Tue, Apr 2, 2019 at 7:08 PM Lorenzo Pieralisi > > wrote: > > > > > > On Tue, Apr 02, 2019 at 04:16:13PM +0530, Srinath Mannam wrote: > > > > > > [...] > > > > > > > > Ok - I start to understand. What does it mean in HW terms that your > > > > > 32bit AXI address region size is 32MB ? Please explain to me in details. > > > > > > > > > In our PCIe controller HW, AXI address from 0x42000000 to 0x44000000 > > > > of 32MB size and . > > > > AXI address from 0x400000000 to 0x480000000 of 2GB size are provided > > > > to map ob address. > > > > First IO region is inside 32bit address and second IO region is > > > > outside 32bit address. > > > > This code change is to map first IO region(0x42000000 to 0x44000000). > > > > > > > > > IIUC you are using an OARR0 of 128MB in size to map a 32MB address > > > > > region, that's what I understand this patch does (and the lowest index > > > > > corresponds to the smallest possible size - it is far from clear by > > > > > looking at the patch). > > > > Yes, lowest index corresponds to smallest possible size (128MB). > > > > In our controller we have multiple windows like OARR0, OARR1, OARR2, > > > > OARR3 all supports multiple sizes from 128MB to 1024MB. > > > > These details are given at the top of this driver file, as shown > > > > below. all windows supports 128MB size still we must use OARR0 window > > > > to configure first IO region(0x42000000 to 0x44000000). > > > > > > > > static const struct iproc_pcie_ob_map paxb_v2_ob_map[] = { > > > > { > > > > /* OARR0/OMAP0 */ > > > > .window_sizes = { 128, 256 }, > > > > .nr_sizes = 2, > > > > }, > > > > { > > > > /* OARR1/OMAP1 */ > > > > .window_sizes = { 128, 256 }, > > > > .nr_sizes = 2, > > > > }, > > > > { > > > > /* OARR2/OMAP2 */ > > > > .window_sizes = { 128, 256, 512, 1024 }, > > > > .nr_sizes = 4, > > > > }, > > > > { > > > > /* OARR3/OMAP3 */ > > > > .window_sizes = { 128, 256, 512, 1024 }, > > > > .nr_sizes = 4, > > > > }, > > > > }; > > > > > > Ok so this patch allows mapping an AXI I/O window that is smaller > > > than OARR possible sizes, why it was not done from the beginning > > > I really do not know. > > > > > Same Iproc driver we use for multiple SOCs, in previous SOCs does not > > have 32-bit AXI address region to map ob. > > In the present SOC, 32-bit AXI address region is available so that > > this change is added. > > > > > Now explain this to me please: > > > > > > > This patch add outbound window configuration to map below 32-bit I/O range > > > > with corresponding PCI memory, which helps to access I/O region in ARM > > > > 32-bit and one to one mapping of I/O region to PCI memory. > > > > > > > > Ex: > > > > 1. ranges DT property given for current driver is, > > > > ranges = <0x83000000 0x0 0x40000000 0x4 0x00000000 0 0x40000000>; > > > > I/O region address is 0x400000000 > > > > 2. ranges DT property can be given after this patch, > > > > ranges = <0x83000000 0x0 0x42000000 0x0 0x42000000 0 0x2000000>; > > > > I/O region address is 0x42000000 > > > > > > Why 1:1 AXI<->PCI address mapping is not possible in (1), how does the > > > current code works on 32-bit systems and what's the benefit your change > > > is bringing. > > non-prefetchable memory range can only support 32-bit addresses, so > > that we have taken 32-bit PCI bus address in (1). > > current code does not work in 32-bit systems. In the present SOC with > > this new change we can access from 32-bit CPU. > > Thank you. I rewrote the log and pushed patches to pci/iproc, please > have a look (Ray/Scott please do have a look too) and report back > if that's fine. > > Do you agree that the initial commit was lacking _significant_ > information ? Please remember that the commit log plays a fundamental > part in understanding a change and this one is a very important one > so I am being pedantic on it. > > Thanks, > Lorenzo 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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable 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 92F3DC4360F for ; Thu, 4 Apr 2019 05:41:44 +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 5D7D82075E for ; Thu, 4 Apr 2019 05:41:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="GvgZp7co"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="WbSng2aR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D7D82075E Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=broadcom.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:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FWDqpQL+eilNYuz1BKd5AVlWN8WIKi6EMJ5QSG0lS3A=; b=GvgZp7couSiCLy wM7Uu45ZNC54o9kpA8UNy7DdTsBqgR0IUOpW9P2yzX0ZagfHiK82yJtq3I+UERk5lGNja18WuUxEW NFaS7GlEY3gey3VMaQlQ68EDiNv+HUeH6Zs5aOM2ZzPzkGrEiXrDtSBjPtavEav/WUdA5W1CbNdys ikGcAbKBxn86AaEpjjpDh0AmRZKgbyO8Rm/YvdTnd7VMsxG+Nsb2Eei0ub3uG6gP9X3uGatyfr4Sr O7/AXLrvDEkAj6LdeHn4F6+LF2Jxjai790ILNN21ttTQPdtgB8Gcbk/IAWrK/H6slNXDuDcAOcTRF +SoOg1e4nr+cksHxkmsg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBv87-0001wP-6a; Thu, 04 Apr 2019 05:41:39 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBv83-0001vt-W1 for linux-arm-kernel@lists.infradead.org; Thu, 04 Apr 2019 05:41:37 +0000 Received: by mail-wr1-x443.google.com with SMTP id s15so1865998wra.12 for ; Wed, 03 Apr 2019 22:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PQzyq/pD246NAZfNEoxnAusNg1XluHoy5IqpEkx2rQ0=; b=WbSng2aRyy0O1EZQAK09lHWeYdLvSgPJ2rF1yOD+Nha9UKl8ObftVsXQymd4tiCDgU 9QsGA2TnT3KTjaduQIlaUCISrtnKiFP0TR/b3fNnEOX0lM7FLT5tyaH04nHLFYxxYUbi SKdL3kEwXIM7PkynYCYEWSqXsga8pXnwzGWTw= 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=PQzyq/pD246NAZfNEoxnAusNg1XluHoy5IqpEkx2rQ0=; b=gtx5nsRu0whMiMmmrJ84t5OX6AXNI0PujJVVtQZKOTehqBVW/wgZi8oaKf/UeOBfkh Ijzg5XeM5qSGKiNNQPYfG5dQx9Rs6MvYRkrgCFeLZvy9XlHWNIvM2vixQfZfPdI2yQT8 kaNFZOcbHYgdWEPiMLAlNmqS+K0+HOoBqj0YNJKxChMhhRY3yA4jtEXNPeiyxtYiLUqE 4oELUfcgoLjeD8eJVIQJ1qvkvBd7bt6Hhsg3Rl9x7lJFR3wIT9ZVHb0QgwT4zcpi60ZL 6QVOzct+1tO19adO2m7T5w9Zr3u1imwDVoq4nAdznJ2v+JcBup2F9iOBQXcclXfeZ3AU dkcQ== X-Gm-Message-State: APjAAAWThbv/7pctXMrE6eQ42j3XRvVyWeBimXMn6DyEOqqvjwk8L0vI FXcH/nmKFEoZeAz2UamqlW32t3mQa+jo5igMaQUnCA== X-Google-Smtp-Source: APXvYqxB/9RznvrIwJYGZIRwMIYu8hLE7kMquXzytzOWHppTDc06gFKm7WogSh/ebBT//x/5Vq9ZqmdpAodBGBProZc= X-Received: by 2002:adf:e790:: with SMTP id n16mr2291635wrm.292.1554356493939; Wed, 03 Apr 2019 22:41:33 -0700 (PDT) MIME-Version: 1.0 References: <1551415936-30174-3-git-send-email-srinath.mannam@broadcom.com> <20190329173515.GA10367@e107981-ln.cambridge.arm.com> <20190401164416.GA8616@e107981-ln.cambridge.arm.com> <20190402102639.GB22708@e107981-ln.cambridge.arm.com> <20190402133851.GA26122@e107981-ln.cambridge.arm.com> <20190403113124.GA16233@e107981-ln.cambridge.arm.com> In-Reply-To: <20190403113124.GA16233@e107981-ln.cambridge.arm.com> From: Srinath Mannam Date: Thu, 4 Apr 2019 11:11:22 +0530 Message-ID: Subject: Re: [PATCH v4 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region To: Lorenzo Pieralisi X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190403_224136_033248_62955981 X-CRM114-Status: GOOD ( 29.71 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Scott Branden , Ray Jui , Linux Kernel Mailing List , Ray Jui , linux-pci@vger.kernel.org, Bjorn Helgaas , BCM Kernel Feedback , Abhishek Shah , 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 Hi Lorenzo, I am sorry, I took your long time. In my commit log I gave details about purpose of feature instead of implementation. Thanks a lot for all inputs and knowledge. I will remember and follow these notes while writing commit log. commit log re-written by you is very much impressive and have detailed description of feature and implementation. Thank again for you patience. Regards, Srinath. On Wed, Apr 3, 2019 at 5:01 PM Lorenzo Pieralisi wrote: > > On Wed, Apr 03, 2019 at 08:41:44AM +0530, Srinath Mannam wrote: > > Hi Lorenzo, > > > > Please see my reply below, > > > > On Tue, Apr 2, 2019 at 7:08 PM Lorenzo Pieralisi > > wrote: > > > > > > On Tue, Apr 02, 2019 at 04:16:13PM +0530, Srinath Mannam wrote: > > > > > > [...] > > > > > > > > Ok - I start to understand. What does it mean in HW terms that your > > > > > 32bit AXI address region size is 32MB ? Please explain to me in details. > > > > > > > > > In our PCIe controller HW, AXI address from 0x42000000 to 0x44000000 > > > > of 32MB size and . > > > > AXI address from 0x400000000 to 0x480000000 of 2GB size are provided > > > > to map ob address. > > > > First IO region is inside 32bit address and second IO region is > > > > outside 32bit address. > > > > This code change is to map first IO region(0x42000000 to 0x44000000). > > > > > > > > > IIUC you are using an OARR0 of 128MB in size to map a 32MB address > > > > > region, that's what I understand this patch does (and the lowest index > > > > > corresponds to the smallest possible size - it is far from clear by > > > > > looking at the patch). > > > > Yes, lowest index corresponds to smallest possible size (128MB). > > > > In our controller we have multiple windows like OARR0, OARR1, OARR2, > > > > OARR3 all supports multiple sizes from 128MB to 1024MB. > > > > These details are given at the top of this driver file, as shown > > > > below. all windows supports 128MB size still we must use OARR0 window > > > > to configure first IO region(0x42000000 to 0x44000000). > > > > > > > > static const struct iproc_pcie_ob_map paxb_v2_ob_map[] = { > > > > { > > > > /* OARR0/OMAP0 */ > > > > .window_sizes = { 128, 256 }, > > > > .nr_sizes = 2, > > > > }, > > > > { > > > > /* OARR1/OMAP1 */ > > > > .window_sizes = { 128, 256 }, > > > > .nr_sizes = 2, > > > > }, > > > > { > > > > /* OARR2/OMAP2 */ > > > > .window_sizes = { 128, 256, 512, 1024 }, > > > > .nr_sizes = 4, > > > > }, > > > > { > > > > /* OARR3/OMAP3 */ > > > > .window_sizes = { 128, 256, 512, 1024 }, > > > > .nr_sizes = 4, > > > > }, > > > > }; > > > > > > Ok so this patch allows mapping an AXI I/O window that is smaller > > > than OARR possible sizes, why it was not done from the beginning > > > I really do not know. > > > > > Same Iproc driver we use for multiple SOCs, in previous SOCs does not > > have 32-bit AXI address region to map ob. > > In the present SOC, 32-bit AXI address region is available so that > > this change is added. > > > > > Now explain this to me please: > > > > > > > This patch add outbound window configuration to map below 32-bit I/O range > > > > with corresponding PCI memory, which helps to access I/O region in ARM > > > > 32-bit and one to one mapping of I/O region to PCI memory. > > > > > > > > Ex: > > > > 1. ranges DT property given for current driver is, > > > > ranges = <0x83000000 0x0 0x40000000 0x4 0x00000000 0 0x40000000>; > > > > I/O region address is 0x400000000 > > > > 2. ranges DT property can be given after this patch, > > > > ranges = <0x83000000 0x0 0x42000000 0x0 0x42000000 0 0x2000000>; > > > > I/O region address is 0x42000000 > > > > > > Why 1:1 AXI<->PCI address mapping is not possible in (1), how does the > > > current code works on 32-bit systems and what's the benefit your change > > > is bringing. > > non-prefetchable memory range can only support 32-bit addresses, so > > that we have taken 32-bit PCI bus address in (1). > > current code does not work in 32-bit systems. In the present SOC with > > this new change we can access from 32-bit CPU. > > Thank you. I rewrote the log and pushed patches to pci/iproc, please > have a look (Ray/Scott please do have a look too) and report back > if that's fine. > > Do you agree that the initial commit was lacking _significant_ > information ? Please remember that the commit log plays a fundamental > part in understanding a change and this one is a very important one > so I am being pedantic on it. > > Thanks, > Lorenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel