All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, devicetree@vger.kernel.org,
	galak@codeaurora.org, netdev@vger.kernel.org,
	linux-sh@vger.kernel.org,
	Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>,
	masaru.nagai.vx@renesas.com
Subject: Re: [PATCH resend] Renesas Ethernet AVB driver
Date: Mon, 13 Apr 2015 20:23:26 +0000	[thread overview]
Message-ID: <552C25BE.3070606@cogentembedded.com> (raw)
In-Reply-To: <5519D380.6070200@cogentembedded.com>

Hello.

On 03/31/2015 01:51 AM, Sergei Shtylyov wrote:

>>> Ethernet AVB includes an Gigabit Ethernet controller (E-MAC) that is basically
>>> compatible with SuperH Gigabit Ethernet E-MAC). Ethernet AVB  has a dedicated
>>> direct memory access controller (AVB-DMAC) that is a new design compared to
>>> the
>>> SuperH E-DMAC. The AVB-DMAC is compliant with 3 standards formulated for IEEE
>>> 802.1BA: IEEE 802.1AS timing and synchronization protocol, IEEE 802.1Qav real-
>>> time transfer, and the IEEE 802.1Qat stream reservation protocol.

>>> The driver only supports device tree probing, so the binding document is
>>> included in this patch.

>>> Based on the patches by Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com> and
>>> Masaru Nagai <masaru.nagai.vx@renesas.com>.

>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

[...]

>>> Index: net-next/drivers/net/ethernet/renesas/ravb.c
>>> =================================>>> --- /dev/null
>>> +++ net-next/drivers/net/ethernet/renesas/ravb.c
>>> @@ -0,0 +1,3071 @@
[...]

>>> +/* There is CPU dependent code */
>>> +static int ravb_wait_clear(struct net_device *ndev, u16 reg, u32 bits)
>>> +{
>>> +    int i;
>>> +
>>> +    for (i = 0; i < 100; i++) {
>>> +        if (!(ravb_read(ndev, reg) & bits))
>>> +            break;
>>> +        mdelay(1);
>>> +    }
>>> +    if (i >= 100)
>>> +        return -ETIMEDOUT;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int ravb_wait_setting(struct net_device *ndev, u16 reg, u32 bits)
>>> +{

>> This function is identical to the previous one.

>     It is not, the *break* condition is different. I'll look into merging them
> though...

    Done.

[...]

>>> +/* Caller must hold the lock */
>>> +static void ravb_ptp_update_compare(struct ravb_private *priv, u32 ns)
>>> +{
>>> +    struct net_device *ndev = priv->ndev;
>>> +    /* When the comparison value (GPTC.PTCV) is in range of
>>> +     * [x-1 to x+1] (x is the configured increment value in
>>> +     * GTI.TIV), it may happen that a comparison match is
>>> +     * not detected when the timer wraps around.
>>> +     */

>> What does this funtion do, exactly?

    Loads the new timer comparator value, apparenlty.

>  This looks very fishy to me.

>     Perhaps a workaround for an errata I don't know about.

    Or perhaps it's to keep the comparison value between x and 2**32 - x 
(where x is increment in ns) as required by the manual?

> Nagai-san, could you maybe elaborate?

[...]

>>> +static bool ravb_ptp_is_config(struct ravb_private *priv)
>>> +{

>> This is a bit hacky.  Can't your driver make sure that the HW is ready?

>     Will look into this. Perhaps it's a remainder from when the PTP driver was
> separate...

    No, we enter this mode upon closing the Ethernet device and when the ring 
DMA sizes are changed. Seems unavoidable...

>>> +    if (ravb_read(priv->ndev, CSR) & CSR_OPS_CONFIG)
>>> +        return true;
>>> +    else
>>> +        return false;
>>> +}
>>> +

[...]

WBR, Sergei


WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, devicetree@vger.kernel.org,
	galak@codeaurora.org, netdev@vger.kernel.org,
	linux-sh@vger.kernel.org,
	Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com>,
	masaru.nagai.vx@renesas.com
Subject: Re: [PATCH resend] Renesas Ethernet AVB driver
Date: Mon, 13 Apr 2015 23:23:26 +0300	[thread overview]
Message-ID: <552C25BE.3070606@cogentembedded.com> (raw)
In-Reply-To: <5519D380.6070200@cogentembedded.com>

Hello.

On 03/31/2015 01:51 AM, Sergei Shtylyov wrote:

>>> Ethernet AVB includes an Gigabit Ethernet controller (E-MAC) that is basically
>>> compatible with SuperH Gigabit Ethernet E-MAC). Ethernet AVB  has a dedicated
>>> direct memory access controller (AVB-DMAC) that is a new design compared to
>>> the
>>> SuperH E-DMAC. The AVB-DMAC is compliant with 3 standards formulated for IEEE
>>> 802.1BA: IEEE 802.1AS timing and synchronization protocol, IEEE 802.1Qav real-
>>> time transfer, and the IEEE 802.1Qat stream reservation protocol.

>>> The driver only supports device tree probing, so the binding document is
>>> included in this patch.

>>> Based on the patches by Mitsuhiro Kimura <mitsuhiro.kimura.kc@renesas.com> and
>>> Masaru Nagai <masaru.nagai.vx@renesas.com>.

>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

[...]

>>> Index: net-next/drivers/net/ethernet/renesas/ravb.c
>>> ===================================================================
>>> --- /dev/null
>>> +++ net-next/drivers/net/ethernet/renesas/ravb.c
>>> @@ -0,0 +1,3071 @@
[...]

>>> +/* There is CPU dependent code */
>>> +static int ravb_wait_clear(struct net_device *ndev, u16 reg, u32 bits)
>>> +{
>>> +    int i;
>>> +
>>> +    for (i = 0; i < 100; i++) {
>>> +        if (!(ravb_read(ndev, reg) & bits))
>>> +            break;
>>> +        mdelay(1);
>>> +    }
>>> +    if (i >= 100)
>>> +        return -ETIMEDOUT;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static int ravb_wait_setting(struct net_device *ndev, u16 reg, u32 bits)
>>> +{

>> This function is identical to the previous one.

>     It is not, the *break* condition is different. I'll look into merging them
> though...

    Done.

[...]

>>> +/* Caller must hold the lock */
>>> +static void ravb_ptp_update_compare(struct ravb_private *priv, u32 ns)
>>> +{
>>> +    struct net_device *ndev = priv->ndev;
>>> +    /* When the comparison value (GPTC.PTCV) is in range of
>>> +     * [x-1 to x+1] (x is the configured increment value in
>>> +     * GTI.TIV), it may happen that a comparison match is
>>> +     * not detected when the timer wraps around.
>>> +     */

>> What does this funtion do, exactly?

    Loads the new timer comparator value, apparenlty.

>  This looks very fishy to me.

>     Perhaps a workaround for an errata I don't know about.

    Or perhaps it's to keep the comparison value between x and 2**32 - x 
(where x is increment in ns) as required by the manual?

> Nagai-san, could you maybe elaborate?

[...]

>>> +static bool ravb_ptp_is_config(struct ravb_private *priv)
>>> +{

>> This is a bit hacky.  Can't your driver make sure that the HW is ready?

>     Will look into this. Perhaps it's a remainder from when the PTP driver was
> separate...

    No, we enter this mode upon closing the Ethernet device and when the ring 
DMA sizes are changed. Seems unavoidable...

>>> +    if (ravb_read(priv->ndev, CSR) & CSR_OPS_CONFIG)
>>> +        return true;
>>> +    else
>>> +        return false;
>>> +}
>>> +

[...]

WBR, Sergei


  parent reply	other threads:[~2015-04-13 20:23 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-27 23:13 [PATCH resend] Renesas Ethernet AVB driver Sergei Shtylyov
2015-03-27 23:13 ` Sergei Shtylyov
2015-03-28  5:17 ` Lino Sanfilippo
2015-03-28  5:17   ` Lino Sanfilippo
2015-03-28  8:36   ` Richard Cochran
2015-03-28  8:36     ` Richard Cochran
2015-03-28 13:55   ` Sergei Shtylyov
2015-03-28 13:55     ` Sergei Shtylyov
2015-03-28  8:28 ` Richard Cochran
2015-03-28  8:28   ` Richard Cochran
2015-03-28 18:26   ` David Miller
2015-03-28 18:26     ` David Miller
2015-03-30 22:51   ` Sergei Shtylyov
2015-03-30 22:51     ` Sergei Shtylyov
2015-03-31  6:43     ` Richard Cochran
2015-03-31  6:43       ` Richard Cochran
2015-03-31  9:01       ` Richard Cochran
2015-03-31  9:01         ` Richard Cochran
2015-03-31 15:38       ` David Miller
2015-03-31 15:38         ` David Miller
2015-03-31 17:40         ` Sergei Shtylyov
2015-03-31 17:40           ` Sergei Shtylyov
2015-03-31 17:48           ` David Miller
2015-03-31 17:48             ` David Miller
2015-04-03  6:27             ` masaru.nagai.vx
2015-04-03  6:27               ` masaru.nagai.vx
2015-04-03  6:27               ` masaru.nagai.vx
2015-04-12 22:03               ` Sergei Shtylyov
2015-04-12 22:03                 ` Sergei Shtylyov
2015-04-09 13:11       ` Bjørn Mork
2015-04-09 13:11         ` Bjørn Mork
2015-04-09 17:57         ` David Miller
2015-04-09 17:57           ` David Miller
2015-04-13 20:23     ` Sergei Shtylyov [this message]
2015-04-13 20:23       ` Sergei Shtylyov
2015-04-14  5:27       ` Richard Cochran
2015-04-14  5:27         ` Richard Cochran
2015-04-14 10:14         ` Sergei Shtylyov
2015-04-14 10:14           ` Sergei Shtylyov
2015-04-14 16:30           ` Richard Cochran
2015-04-14 16:30             ` Richard Cochran
2015-04-14 16:58             ` Sergei Shtylyov
2015-04-14 16:58               ` Sergei Shtylyov
2015-04-14 18:30               ` Richard Cochran
2015-04-14 18:30                 ` Richard Cochran
2015-04-15  1:01                 ` masaru.nagai.vx
2015-04-15  1:01                   ` masaru.nagai.vx
2015-04-15  1:01                   ` masaru.nagai.vx
2015-04-15  5:31                   ` Richard Cochran
2015-04-15  5:31                     ` Richard Cochran
2015-04-02 13:56 ` Ben Hutchings
2015-04-02 13:56   ` Ben Hutchings
2015-04-13 20:34   ` Sergei Shtylyov
2015-04-13 20:34     ` Sergei Shtylyov
2015-04-13 22:13     ` Lino Sanfilippo
2015-04-13 22:13       ` Lino Sanfilippo
2015-04-13 22:31       ` Ben Hutchings
2015-04-13 22:31         ` Ben Hutchings
2015-04-13 22:53         ` Lino Sanfilippo
2015-04-13 22:53           ` Lino Sanfilippo
2015-04-13 23:08           ` Ben Hutchings
2015-04-13 23:08             ` Ben Hutchings

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=552C25BE.3070606@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-sh@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=masaru.nagai.vx@renesas.com \
    --cc=mitsuhiro.kimura.kc@renesas.com \
    --cc=netdev@vger.kernel.org \
    --cc=pawel.moll@arm.com \
    --cc=richardcochran@gmail.com \
    --cc=robh+dt@kernel.org \
    /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.