From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout2.samsung.com ([203.254.224.25]:36375 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751200AbaDYBES (ORCPT ); Thu, 24 Apr 2014 21:04:18 -0400 Received: from epcpsbgr5.samsung.com (u145.gpu120.samsung.co.kr [203.254.230.145]) by mailout2.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N4K00E4WAZ3IR30@mailout2.samsung.com> for linux-pci@vger.kernel.org; Fri, 25 Apr 2014 10:04:16 +0900 (KST) From: Jingoo Han To: 'Bjorn Helgaas' Cc: 'Richard Zhu' , 'Marek Vasut' , 'Kishon Vijay Abraham I' , 'Mohit KUMAR DCG' , linux-pci@vger.kernel.org, 'Pratyush ANAND' , 'Jingoo Han' References: <000801cf4d95$64322ef0$2c968cd0$%han@samsung.com> <2CC2A0A4A178534D93D5159BF3BCB66189FEC4809B@EAPEX1MAIL1.st.com> <533BA157.6030004@ti.com> <201404021234.48134.marex@denx.de> <65debfc7f79a4a27a58bd7c64382881f@BLUPR03MB136.namprd03.prod.outlook.com> <000001cf4fad$ff227ae0$fd6770a0$%han@samsung.com> <20140424213537.GJ29593@google.com> In-reply-to: <20140424213537.GJ29593@google.com> Subject: Re: [PATCH] PCI: designware: Remove unnecessary RC BAR setting Date: Fri, 25 Apr 2014 10:04:15 +0900 Message-id: <000001cf6022$47395d10$d5ac1730$%han@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: linux-pci-owner@vger.kernel.org List-ID: On Friday, April 25, 2014 6:36 AM, Bjorn Helgaas wrote: > On Fri, Apr 04, 2014 at 11:31:34AM +0900, Jingoo Han wrote: > > On Wednesday, April 02, 2014 8:59 PM, Richard Zhu wrote: > > > Wednesday, April 02, 2014 6:35 PM, Marek Vasut wrote: > > > > On Wednesday, April 02, 2014 at 07:34:15 AM, Kishon Vijay Abraham I wrote: > > > > > On Wednesday 02 April 2014 11:03 AM, Mohit KUMAR DCG wrote: > > > > > > Wednesday, April 02, 2014 10:53 AM, Jingoo Han wrote: > > > > > >> On Wednesday, April 02, 2014 1:57 PM, Mohit KUMAR DCG wrote: > > > > > >>> On Tuesday, April 01, 2014 4:00 PM, Jingoo Han wrote: > > > > > >>>> According to the spec, the synopsys core does not implement the > > > > > >>>> optional BARs such as BAR0/1. This is based on the assumption > > > > > >>>> that the RC host probably has registers on some other internal > > > > > >>>> bus and has knowledge and setup access to these registers already. > > > > > >>>> So, remove unnecessary RC BAR setting. > > > > > >>> > > > > > >>> - Normally BARs in RC are not used but somehow available in the > > > > > >>> design. One possible BAR use can be if RC has some memory > > > > > >>> connected to > > > > > >> > > > > > >> the BAR that needs to be accessed through link. > > > > > >> > > > > > >>> Otherwise we can ignore BARs setup here. > > > > > >> > > > > > >> Hi Mohit KUMAR DCG, > > > > > >> > > > > > >> Thank you for your feedback. > > > > > >> > > > > > >> I want to know whether or not other SoCs such as ST, Freescale, TI > > > > > >> support BAR0/BAR1. If no SoC supports BAR0/BAR1, the unnecessary RC > > > > > >> BAR setting code should be removed. > > > > > > > > > > > > - We are not currently using RC's BAR0/1 in any application but no > > > > > > such restriction from HW as ST SoCs support BARs in HW design. > > > > > > > > > > Neither do we in DRA7xx. > > > > > > > > I suspect that means we should keep the code to make sure the registers are > > > > configured correctly, no? > > > > > > > > Richard, can you comment on MX6 please ? > > > > > > [Richard] Sorry to reply late. I'm engaged in another stuff in the past days. > > > i.MX6 pcie doesn't use RC's BAR0/1 in applications either. > > > > > > > > Thank you all for your comments! > > > > I noticed that Synopsys PCIe "Dual mode" can support BAR0/BAR1. > > The bits[3:0] of BAR0 is RO(CS), which means Read-Only, but writable > > from the local application through the DBI. > > > > So, the BAR0/1 setting might be necessary, in order to ensure the > > BAR0/1 setting is written properly. > > > > But, when BAR0/1 are implemented, the bits[3:0] of BAR0 is decided > > by hardware configuration parameters. So, this BAR0/1 setting looks > > unnecessary. > > > > How about others' opinions? > > > > 1. Necessary: in order to ensure the BAR0/BAR1 setting, even though > > BAR0/BAR1 were already set as hardware default values > > > > 2. Unnecessary: the BAR0/BAR1 setting code is dummy, because BAR0/BAR1 > > were already set as hardware default values > > > > For example, in the case of Exynos5440, BAR0/BAR1 are not implemented; > > thus, even though BAR0 is written as 0x4, BAR0 can be always read as 0. > > So, there is not side effect, but just unnecessary code is executed > > during boot time. > > I don't sense a clear consensus that we should apply this, so I'll drop > it for now. Please repost with appropriate acks if we do need it. OK, I agree with your opinion. Thank you. Best regards, Jingoo Han