From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Tanmay Inamdar <tinamdar@apm.com>,
devicetree@vger.kernel.org, Jon Masters <jcm@redhat.com>,
linux-doc@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
patches <patches@apm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Grant Likely <grant.likely@linaro.org>,
Rob Herring <robh+dt@kernel.org>, Rob Landley <rob@landley.net>,
linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [RFC PATCH V2 1/4] pci: APM X-Gene PCIe controller driver
Date: Sat, 25 Jan 2014 21:11:34 +0100 [thread overview]
Message-ID: <5086198.ZOWZ5xuyna@wuerfel> (raw)
In-Reply-To: <CACoXjc=-JtpiM3m4DSA_DeOxYr3sihGGf4FSaJ2yC08rpm6ANQ@mail.gmail.com>
On Friday 24 January 2014 13:28:22 Tanmay Inamdar wrote:
> On Thu, Jan 16, 2014 at 5:10 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
> > On Wed, Jan 15, 2014 at 4:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Wednesday 15 January 2014, Tanmay Inamdar wrote:
> >>
> >>> +static void xgene_pcie_poll_linkup(struct xgene_pcie_port *port, u32 *lanes)
> >>> +{
> >>> + void *csr_base = port->csr_base;
> >>> + u32 val32;
> >>> + u64 start_time, time;
> >>> +
> >>> + /*
> >>> + * A component enters the LTSSM Detect state within
> >>> + * 20ms of the end of fundamental core reset.
> >>> + */
> >>> + msleep(XGENE_LTSSM_DETECT_WAIT);
> >>> + port->link_up = 0;
> >>> + start_time = jiffies;
> >>> + do {
> >>> + val32 = readl(csr_base + PCIECORE_CTLANDSTATUS);
> >>> + if (val32 & LINK_UP_MASK) {
> >>> + port->link_up = 1;
> >>> + port->link_speed = PIPE_PHY_RATE_RD(val32);
> >>> + val32 = readl(csr_base + BRIDGE_STATUS_0);
> >>> + *lanes = val32 >> 26;
> >>> + }
> >>> + time = jiffies_to_msecs(jiffies - start_time);
> >>> + } while ((!port->link_up) || (time <= XGENE_LTSSM_L0_WAIT));
> >>> +}
> >>
> >> Maybe another msleep() in the loop? It seems weird to first do an
> >> unconditional sleep but then busy-wait for the result.
> >
> > ok.
>
> This loop can execute for maximum 4 msec. So putting msleep(1) won't
> get us much.
4 msec is still quite a long time for a busy loop that can be spent doing
useful work in another thread.
> >>
> >> Another general note: Your "compatible" strings are rather unspecific.
> >> Do you have a version number for this IP block? I suppose that it's related
> >> to one that has been used in other chips before, or will be used in future
> >> chips, if it's not actually licensed from some other company.
> >
> > I will have to check this.
> >
>
> We have decided to stick with current compatible string for now.
Can you elaborate on your reasoning? Does this mean X-Gene is a one-off
product and you won't be doing any new chips based on the same hardware
components?
Arnd
next prev parent reply other threads:[~2014-01-25 20:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 23:34 [RFC PATCH V2 0/4] APM X-Gene PCIe controller Tanmay Inamdar
2014-01-14 23:34 ` [RFC PATCH V2 1/4] pci: APM X-Gene PCIe controller driver Tanmay Inamdar
2014-01-15 12:39 ` Arnd Bergmann
2014-01-17 1:10 ` Tanmay Inamdar
[not found] ` <CACoXjc=ZT9fEm_KdY4WFSoS8n5FmO+hn9LjsR4m8YZG2iBbt5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-01-17 15:07 ` Arnd Bergmann
2014-01-24 21:28 ` Tanmay Inamdar
2014-01-25 20:11 ` Arnd Bergmann [this message]
2014-01-27 22:54 ` Tanmay Inamdar
2014-01-29 19:36 ` Arnd Bergmann
2014-01-28 0:55 ` Bjorn Helgaas
2014-01-28 2:02 ` Tanmay Inamdar
2014-01-14 23:34 ` [RFC PATCH V2 2/4] arm64:dts: APM X-Gene PCIe device tree nodes Tanmay Inamdar
2014-01-14 23:34 ` [RFC PATCH V2 3/4] dt-bindings: pci: xgene pcie device tree bindings Tanmay Inamdar
2014-01-15 9:57 ` Arnd Bergmann
2014-01-17 1:17 ` Tanmay Inamdar
[not found] ` <1389742458-7693-1-git-send-email-tinamdar-qTEPVZfXA3Y@public.gmane.org>
2014-01-14 23:34 ` [RFC PATCH V2 4/4] MAINTAINERS: entry for APM X-Gene PCIe host driver Tanmay Inamdar
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=5086198.ZOWZ5xuyna@wuerfel \
--to=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=jcm@redhat.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=patches@apm.com \
--cc=rob@landley.net \
--cc=robh+dt@kernel.org \
--cc=tinamdar@apm.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).