linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jingoo Han <jg1.han@samsung.com>
To: 'Richard Zhu' <Hong-Xing.Zhu@freescale.com>,
	'Marek Vasut' <marex@denx.de>,
	'Kishon Vijay Abraham I' <kishon@ti.com>,
	'Mohit KUMAR DCG' <Mohit.KUMAR@st.com>
Cc: 'Bjorn Helgaas' <bhelgaas@google.com>,
	linux-pci@vger.kernel.org,
	'Pratyush ANAND' <pratyush.anand@st.com>,
	'Jingoo Han' <jg1.han@samsung.com>
Subject: Re: [PATCH] PCI: designware: Remove unnecessary RC BAR setting
Date: Fri, 04 Apr 2014 11:31:34 +0900	[thread overview]
Message-ID: <000001cf4fad$ff227ae0$fd6770a0$%han@samsung.com> (raw)
In-Reply-To: <65debfc7f79a4a27a58bd7c64382881f@BLUPR03MB136.namprd03.prod.outlook.com>

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.

Thank you. :-)

Best regards,
Jingoo Han


  reply	other threads:[~2014-04-04  2:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-01 10:30 [PATCH] PCI: designware: Remove unnecessary RC BAR setting Jingoo Han
2014-04-02  4:57 ` Mohit KUMAR DCG
2014-04-02  5:22   ` Jingoo Han
2014-04-02  5:33     ` Mohit KUMAR DCG
2014-04-02  5:34       ` Kishon Vijay Abraham I
2014-04-02 10:34         ` Marek Vasut
2014-04-02 11:58           ` Hong-Xing.Zhu
2014-04-04  2:31             ` Jingoo Han [this message]
2014-04-24 21:35               ` Bjorn Helgaas
2014-04-25  1:04                 ` Jingoo Han

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000001cf4fad$ff227ae0$fd6770a0$%han@samsung.com' \
    --to=jg1.han@samsung.com \
    --cc=Hong-Xing.Zhu@freescale.com \
    --cc=Mohit.KUMAR@st.com \
    --cc=bhelgaas@google.com \
    --cc=kishon@ti.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=pratyush.anand@st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).