From: Arnd Bergmann <arnd@arndb.de>
To: "Kwok, WingMan" <w-kwok2@ti.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"pawel.moll@arm.com" <pawel.moll@arm.com>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
"galak@codeaurora.org" <galak@codeaurora.org>,
KISHON VIJAY ABRAHAM <kishon@ti.com>,
"Quadros, Roger" <rogerq@ti.com>,
"Karicheri, Muralidharan" <m-karicheri2@ti.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"ssantosh@kernel.org" <ssantosh@kernel.org>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie
Date: Thu, 15 Oct 2015 22:53:16 +0200 [thread overview]
Message-ID: <9008744.UmMoJzNEVK@wuerfel> (raw)
In-Reply-To: <230CBA6E4B6B6B418E8730AC28E6FC7E04228DB8@DFLE11.ent.ti.com>
On Thursday 15 October 2015 20:08:32 Kwok, WingMan wrote:
>
> > > +#define reg_rmw(addr, value, mask) \
> > > + __raw_writel(((__raw_readl(addr) & (~(mask))) | \
> > > + (value & (mask))), (addr))
> >
> > not endian safe, and potentially racy.
> >
>
> will change to
>
> #define reg_rmw(addr, value, mask) \
> writel(((readl(addr) & (~(mask))) | \
> (value & (mask))), (addr))
Ok, sounds good. Note that if any of this is performance critical,
better use readl_relaxed(), but as long as this is just for setup
code and not for data transfers, staying with readl() as you
suggest is better.
> > > +static inline void _kserdes_reset_cdr(void __iomem *sregs, int lane)
> > > +{
> > > + /* toggle signal detect */
> > > + _kserdes_force_signal_detect_low(sregs, lane);
> > > + mdelay(1);
> > > + _kserdes_force_signal_detect_high(sregs, lane);
> > > +}
> >
> > Can you change the code so you can use msleep(1) here?
> >
>
> will replace delays with usleep_range()
Ok.
> > > +
> > > + do {
> > > + mdelay(10);
> > > + memset(lane_down, 0, sizeof(lane_down));
> > > +
> > > + link_up = _kserdes_check_link_status(dev, sregs,
> > > + pcsr_regmap, lanes,
> > > + lanes_enable,
> > > + current_state, lane_down);
> > > +
> > > + /* if we did not get link up then wait 100ms
> > > + * before calling it again
> > > + */
> > > + if (link_up)
> > > + break;
> > > +
> > > + for (i = 0; i < lanes; i++) {
> > > + if ((lanes_enable & (1 << i)) && lane_down[i])
> > > + dev_dbg(dev,
> > > + "XGE: detected lane down on lane %d\n",
> > > + i);
> > > + }
> > > +
> > > + if (++retries > 100)
> > > + return -ETIMEDOUT;
> > > +
> > > + } while (!link_up);
> >
> > an more importantly here. Blocking the CPU for over one second is not good.
> >
> > Any use of mdelay() should have a comment explaining why you cannot use
> > msleep() in that instance.
> >
>
> will replace delays with usleep_range()
Here you have to be careful with the total runtime. Using usleep_range()
is a good idea, and you can have a particularly wide range, but then you
should changen the timeout condition from number of retries to total
elapsed time like
unsigned long timeout = jiffies + HZ; /* 1 second maximum */
do {
...
if (link_up)
break;
if (time_after(jiffies, timeout)
return -ETIMEOUT;
usleep_range(1000, 50000);
} while (1);
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie
Date: Thu, 15 Oct 2015 22:53:16 +0200 [thread overview]
Message-ID: <9008744.UmMoJzNEVK@wuerfel> (raw)
In-Reply-To: <230CBA6E4B6B6B418E8730AC28E6FC7E04228DB8@DFLE11.ent.ti.com>
On Thursday 15 October 2015 20:08:32 Kwok, WingMan wrote:
>
> > > +#define reg_rmw(addr, value, mask) \
> > > + __raw_writel(((__raw_readl(addr) & (~(mask))) | \
> > > + (value & (mask))), (addr))
> >
> > not endian safe, and potentially racy.
> >
>
> will change to
>
> #define reg_rmw(addr, value, mask) \
> writel(((readl(addr) & (~(mask))) | \
> (value & (mask))), (addr))
Ok, sounds good. Note that if any of this is performance critical,
better use readl_relaxed(), but as long as this is just for setup
code and not for data transfers, staying with readl() as you
suggest is better.
> > > +static inline void _kserdes_reset_cdr(void __iomem *sregs, int lane)
> > > +{
> > > + /* toggle signal detect */
> > > + _kserdes_force_signal_detect_low(sregs, lane);
> > > + mdelay(1);
> > > + _kserdes_force_signal_detect_high(sregs, lane);
> > > +}
> >
> > Can you change the code so you can use msleep(1) here?
> >
>
> will replace delays with usleep_range()
Ok.
> > > +
> > > + do {
> > > + mdelay(10);
> > > + memset(lane_down, 0, sizeof(lane_down));
> > > +
> > > + link_up = _kserdes_check_link_status(dev, sregs,
> > > + pcsr_regmap, lanes,
> > > + lanes_enable,
> > > + current_state, lane_down);
> > > +
> > > + /* if we did not get link up then wait 100ms
> > > + * before calling it again
> > > + */
> > > + if (link_up)
> > > + break;
> > > +
> > > + for (i = 0; i < lanes; i++) {
> > > + if ((lanes_enable & (1 << i)) && lane_down[i])
> > > + dev_dbg(dev,
> > > + "XGE: detected lane down on lane %d\n",
> > > + i);
> > > + }
> > > +
> > > + if (++retries > 100)
> > > + return -ETIMEDOUT;
> > > +
> > > + } while (!link_up);
> >
> > an more importantly here. Blocking the CPU for over one second is not good.
> >
> > Any use of mdelay() should have a comment explaining why you cannot use
> > msleep() in that instance.
> >
>
> will replace delays with usleep_range()
Here you have to be careful with the total runtime. Using usleep_range()
is a good idea, and you can have a particularly wide range, but then you
should changen the timeout condition from number of retries to total
elapsed time like
unsigned long timeout = jiffies + HZ; /* 1 second maximum */
do {
...
if (link_up)
break;
if (time_after(jiffies, timeout)
return -ETIMEOUT;
usleep_range(1000, 50000);
} while (1);
Arnd
next prev parent reply other threads:[~2015-10-15 20:53 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-15 14:25 [PATCH v1 0/2] Common SerDes driver for TI's Keystone Platforms WingMan Kwok
2015-10-15 14:25 ` WingMan Kwok
2015-10-15 14:25 ` WingMan Kwok
2015-10-15 14:25 ` [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie WingMan Kwok
2015-10-15 14:25 ` WingMan Kwok
2015-10-15 14:25 ` WingMan Kwok
2015-10-15 14:51 ` Arnd Bergmann
2015-10-15 14:51 ` Arnd Bergmann
2015-10-15 16:01 ` Murali Karicheri
2015-10-15 16:01 ` Murali Karicheri
2015-10-15 16:01 ` Murali Karicheri
2015-10-15 19:34 ` Arnd Bergmann
2015-10-15 19:34 ` Arnd Bergmann
2015-10-19 14:47 ` Kwok, WingMan
2015-10-19 14:47 ` Kwok, WingMan
2015-10-19 14:47 ` Kwok, WingMan
2015-10-19 14:47 ` Kwok, WingMan
2015-10-19 18:50 ` Murali Karicheri
2015-10-19 18:50 ` Murali Karicheri
2015-10-20 8:24 ` Arnd Bergmann
2015-10-20 8:24 ` Arnd Bergmann
2015-10-20 8:24 ` Arnd Bergmann
2015-10-20 15:11 ` Murali Karicheri
2015-10-20 15:11 ` Murali Karicheri
2015-10-15 20:08 ` Kwok, WingMan
2015-10-15 20:08 ` Kwok, WingMan
2015-10-15 20:08 ` Kwok, WingMan
2015-10-15 20:08 ` Kwok, WingMan
2015-10-15 20:53 ` Arnd Bergmann [this message]
2015-10-15 20:53 ` Arnd Bergmann
2015-10-15 23:57 ` Kwok, WingMan
2015-10-15 23:57 ` Kwok, WingMan
2015-10-15 23:57 ` Kwok, WingMan
2015-10-15 23:57 ` Kwok, WingMan
2015-10-15 16:14 ` Rob Herring
2015-10-15 16:14 ` Rob Herring
2015-10-15 23:53 ` Kwok, WingMan
2015-10-15 23:53 ` Kwok, WingMan
2015-10-15 23:53 ` Kwok, WingMan
2015-10-15 23:53 ` Kwok, WingMan
2015-10-15 14:25 ` [PATCH v1 2/2] PCI: keystone: update to use generic keystone serdes driver WingMan Kwok
2015-10-15 14:25 ` WingMan Kwok
2015-10-15 14:25 ` WingMan Kwok
2015-10-15 16:51 ` [PATCH v1 0/2] Common SerDes driver for TI's Keystone Platforms Russell King - ARM Linux
2015-10-15 16:51 ` Russell King - ARM Linux
2015-10-15 16:51 ` Russell King - ARM Linux
2015-10-15 19:21 ` Kishon Vijay Abraham I
2015-10-15 19:21 ` Kishon Vijay Abraham I
2015-10-15 19:21 ` Kishon Vijay Abraham I
2015-10-16 0:02 ` Kwok, WingMan
2015-10-16 0:02 ` Kwok, WingMan
2015-10-16 0:02 ` Kwok, WingMan
2015-10-16 0:02 ` Kwok, WingMan
2015-10-16 1:00 ` Rob Herring
2015-10-16 1:00 ` Rob Herring
2015-10-16 1:00 ` Rob Herring
2015-10-16 8:02 ` Russell King - ARM Linux
2015-10-16 8:02 ` Russell King - ARM Linux
2015-10-16 14:10 ` Murali Karicheri
2015-10-16 14:10 ` Murali Karicheri
2015-10-16 14:14 ` Kishon Vijay Abraham I
2015-10-16 14:14 ` Kishon Vijay Abraham I
2015-10-16 14:14 ` Kishon Vijay Abraham I
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=9008744.UmMoJzNEVK@wuerfel \
--to=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=m-karicheri2@ti.com \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=rogerq@ti.com \
--cc=ssantosh@kernel.org \
--cc=w-kwok2@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.