[PATCH 4/7] ptp: switch to use gpiolib

[PATCH 4/7] ptp: switch to use gpiolib

[Linus Walleij]

This platform supports gpiolib, so remove the custom API use
and replace with calls to gpiolib. Also request the GPIO before
starting to use it.

Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Hi Richard, I'm seeking an ACK on this patch to take it throug
the GPIO tree as part of a clean-out of custom GPIO implementations.
---
 drivers/ptp/ptp_ixp46x.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/ptp/ptp_ixp46x.c b/drivers/ptp/ptp_ixp46x.c
index d49b851..4a08727 100644
--- a/drivers/ptp/ptp_ixp46x.c
+++ b/drivers/ptp/ptp_ixp46x.c
@@ -259,8 +259,15 @@ static struct ixp_clock ixp_clock;
 static int setup_interrupt(int gpio)
 {
 	int irq;
+	int err;
 
-	gpio_line_config(gpio, IXP4XX_GPIO_IN);
+	err = gpio_request(gpio, "ixp4-ptp");
+	if (err)
+		return err;
+
+	err = gpio_direction_input(gpio);
+	if (err)
+		return err;
 
 	irq = gpio_to_irq(gpio);
 
-- 
1.8.3.1

[PATCH 4/7] ptp: switch to use gpiolib

[Linus Walleij]

This platform supports gpiolib, so remove the custom API use
and replace with calls to gpiolib. Also request the GPIO before
starting to use it.

Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: netdev at vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Hi Richard, I'm seeking an ACK on this patch to take it throug
the GPIO tree as part of a clean-out of custom GPIO implementations.
---
 drivers/ptp/ptp_ixp46x.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/ptp/ptp_ixp46x.c b/drivers/ptp/ptp_ixp46x.c
index d49b851..4a08727 100644
--- a/drivers/ptp/ptp_ixp46x.c
+++ b/drivers/ptp/ptp_ixp46x.c
@@ -259,8 +259,15 @@ static struct ixp_clock ixp_clock;
 static int setup_interrupt(int gpio)
 {
 	int irq;
+	int err;
 
-	gpio_line_config(gpio, IXP4XX_GPIO_IN);
+	err = gpio_request(gpio, "ixp4-ptp");
+	if (err)
+		return err;
+
+	err = gpio_direction_input(gpio);
+	if (err)
+		return err;
 
 	irq = gpio_to_irq(gpio);
 
-- 
1.8.3.1

Re: [PATCH 4/7] ptp: switch to use gpiolib

[Richard Cochran]

On Tue, Sep 10, 2013 at 02:31:00PM +0200, Linus Walleij wrote:
> This platform supports gpiolib, so remove the custom API use
> and replace with calls to gpiolib. Also request the GPIO before
> starting to use it.
> 
> Cc: Imre Kaloz <kaloz@openwrt.org>
> Cc: Krzysztof Halasa <khc@pm.waw.pl>
> Cc: Alexandre Courbot <acourbot@nvidia.com>
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Hi Richard, I'm seeking an ACK on this patch to take it throug
> the GPIO tree as part of a clean-out of custom GPIO implementations.

I don't have this hardware for testing (it is really obsolete now),
but the change looks okay to me.

Acked-by: Richard Cochran <richardcochran@gmail.com>

[PATCH 4/7] ptp: switch to use gpiolib

[Richard Cochran]

On Tue, Sep 10, 2013 at 02:31:00PM +0200, Linus Walleij wrote:
> This platform supports gpiolib, so remove the custom API use
> and replace with calls to gpiolib. Also request the GPIO before
> starting to use it.
> 
> Cc: Imre Kaloz <kaloz@openwrt.org>
> Cc: Krzysztof Halasa <khc@pm.waw.pl>
> Cc: Alexandre Courbot <acourbot@nvidia.com>
> Cc: Richard Cochran <richardcochran@gmail.com>
> Cc: netdev at vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Hi Richard, I'm seeking an ACK on this patch to take it throug
> the GPIO tree as part of a clean-out of custom GPIO implementations.

I don't have this hardware for testing (it is really obsolete now),
but the change looks okay to me.

Acked-by: Richard Cochran <richardcochran@gmail.com>

Re: [PATCH 4/7] ptp: switch to use gpiolib

[Linus Walleij]

On Tue, Sep 10, 2013 at 4:19 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Tue, Sep 10, 2013 at 02:31:00PM +0200, Linus Walleij wrote:

>> Hi Richard, I'm seeking an ACK on this patch to take it throug
>> the GPIO tree as part of a clean-out of custom GPIO implementations.
>
> I don't have this hardware for testing (it is really obsolete now),
> but the change looks okay to me.
>
> Acked-by: Richard Cochran <richardcochran@gmail.com>

Thanks, I have found numerous active hobbyists using the
IXP4-based NSLU2 NAS machine for various things - mostly
non-network related as it happens, so it'll be with us for a
while I think.

Yours,
Linus Walleij

[PATCH 4/7] ptp: switch to use gpiolib

[Linus Walleij]

On Tue, Sep 10, 2013 at 4:19 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Tue, Sep 10, 2013 at 02:31:00PM +0200, Linus Walleij wrote:

>> Hi Richard, I'm seeking an ACK on this patch to take it throug
>> the GPIO tree as part of a clean-out of custom GPIO implementations.
>
> I don't have this hardware for testing (it is really obsolete now),
> but the change looks okay to me.
>
> Acked-by: Richard Cochran <richardcochran@gmail.com>

Thanks, I have found numerous active hobbyists using the
IXP4-based NSLU2 NAS machine for various things - mostly
non-network related as it happens, so it'll be with us for a
while I think.

Yours,
Linus Walleij

Re: [PATCH 4/7] ptp: switch to use gpiolib

[Krzysztof Halasa]

Linus Walleij <linus.walleij@linaro.org> writes:

> Thanks, I have found numerous active hobbyists using the
> IXP4-based NSLU2 NAS machine for various things - mostly
> non-network related as it happens, so it'll be with us for a
> while I think.

IXP42x are most probably "end of life" in the commercial sense, but the
newer IXP46x/455 and even newer IXP43x are still being sold. For
example, Gateworks have a couple of IXP43x boards ("Cambria") which
I personally find interesting, for some specific applications.

There is no platform driver for Cambria in the official Linux, guess it
should be changed.
-- 
Krzysztof Halasa

Re: [PATCH 4/7] ptp: switch to use gpiolib

[Krzysztof Halasa]

Linus Walleij <linus.walleij@linaro.org> writes:

> Thanks, I have found numerous active hobbyists using the
> IXP4-based NSLU2 NAS machine for various things - mostly
> non-network related as it happens, so it'll be with us for a
> while I think.

IXP42x are most probably "end of life" in the commercial sense, but the
newer IXP46x/455 and even newer IXP43x are still being sold. For
example, Gateworks have a couple of IXP43x boards ("Cambria") which
I personally find interesting, for some specific applications.

There is no platform driver for Cambria in the official Linux, guess it
should be changed.
-- 
Krzysztof Halasa

[PATCH 4/7] ptp: switch to use gpiolib

[Krzysztof Halasa]

Linus Walleij <linus.walleij@linaro.org> writes:

> Thanks, I have found numerous active hobbyists using the
> IXP4-based NSLU2 NAS machine for various things - mostly
> non-network related as it happens, so it'll be with us for a
> while I think.

IXP42x are most probably "end of life" in the commercial sense, but the
newer IXP46x/455 and even newer IXP43x are still being sold. For
example, Gateworks have a couple of IXP43x boards ("Cambria") which
I personally find interesting, for some specific applications.

There is no platform driver for Cambria in the official Linux, guess it
should be changed.
-- 
Krzysztof Halasa

Re: [PATCH 4/7] ptp: switch to use gpiolib

[Richard Cochran]

On Fri, Sep 13, 2013 at 02:22:16PM +0200, Krzysztof Halasa wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
> 
> > Thanks, I have found numerous active hobbyists using the
> > IXP4-based NSLU2 NAS machine for various things - mostly
> > non-network related as it happens, so it'll be with us for a
> > while I think.
> 
> IXP42x are most probably "end of life" in the commercial sense, but the
> newer IXP46x/455 and even newer IXP43x are still being sold. For
> example, Gateworks have a couple of IXP43x boards ("Cambria") which
> I personally find interesting, for some specific applications.

I was really talking about the IXP465 with its PTP function. The Intel
devel board had a silicon bug making the PTP function useless. But
even if the bug got fixed, still the PTP function was very limiting.

I never got any feedback about the IXP465 PTP stuff, and so I doubt
whether anyone is really using the Linux PTP driver on the IXP465, but
you never know.

Thanks,
Richard

[PATCH 4/7] ptp: switch to use gpiolib

[Richard Cochran]

On Fri, Sep 13, 2013 at 02:22:16PM +0200, Krzysztof Halasa wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
> 
> > Thanks, I have found numerous active hobbyists using the
> > IXP4-based NSLU2 NAS machine for various things - mostly
> > non-network related as it happens, so it'll be with us for a
> > while I think.
> 
> IXP42x are most probably "end of life" in the commercial sense, but the
> newer IXP46x/455 and even newer IXP43x are still being sold. For
> example, Gateworks have a couple of IXP43x boards ("Cambria") which
> I personally find interesting, for some specific applications.

I was really talking about the IXP465 with its PTP function. The Intel
devel board had a silicon bug making the PTP function useless. But
even if the bug got fixed, still the PTP function was very limiting.

I never got any feedback about the IXP465 PTP stuff, and so I doubt
whether anyone is really using the Linux PTP driver on the IXP465, but
you never know.

Thanks,
Richard

Re: [PATCH 4/7] ptp: switch to use gpiolib

[Krzysztof Halasa]

Richard Cochran <richardcochran@gmail.com> writes:

> I was really talking about the IXP465 with its PTP function. The Intel
> devel board had a silicon bug making the PTP function useless. But
> even if the bug got fixed, still the PTP function was very limiting.
>
> I never got any feedback about the IXP465 PTP stuff, and so I doubt
> whether anyone is really using the Linux PTP driver on the IXP465, but
> you never know.

Ah, OK.
I have just checked, Intel's spec update says IXP46x steppings A1 and A2
are fixed. PTP on 46x-A0 is broken.
42x and 43x don't support PTP.

OTOH there is interesting stuff there:
Problem: The A-0 and A-1 stepping of the Intel® IXP45X/IXP46X Product Line of Network
         Processors can enter a condition whereby the system locks up when certain
         combinations of memory accesses occur nearly simultaneously.

         After more extensive investigation, it has been identified that the lockup condition can
         be caused by near-simultaneous accesses to 1 or 2 cache lines. The accesses to the
         cache lines must be performed by the Intel XScale processor, South AHB, and/or North
         AHB for the lockup to happen.

Hmmm...
-- 
Krzysztof Halasa

Re: [PATCH 4/7] ptp: switch to use gpiolib

[Krzysztof Halasa]

Richard Cochran <richardcochran@gmail.com> writes:

> I was really talking about the IXP465 with its PTP function. The Intel
> devel board had a silicon bug making the PTP function useless. But
> even if the bug got fixed, still the PTP function was very limiting.
>
> I never got any feedback about the IXP465 PTP stuff, and so I doubt
> whether anyone is really using the Linux PTP driver on the IXP465, but
> you never know.

Ah, OK.
I have just checked, Intel's spec update says IXP46x steppings A1 and A2
are fixed. PTP on 46x-A0 is broken.
42x and 43x don't support PTP.

OTOH there is interesting stuff there:
Problem: The A-0 and A-1 stepping of the Intel® IXP45X/IXP46X Product Line of Network
         Processors can enter a condition whereby the system locks up when certain
         combinations of memory accesses occur nearly simultaneously.

         After more extensive investigation, it has been identified that the lockup condition can
         be caused by near-simultaneous accesses to 1 or 2 cache lines. The accesses to the
         cache lines must be performed by the Intel XScale processor, South AHB, and/or North
         AHB for the lockup to happen.

Hmmm...
-- 
Krzysztof Halasa

[PATCH 4/7] ptp: switch to use gpiolib

[Krzysztof Halasa]

Richard Cochran <richardcochran@gmail.com> writes:

> I was really talking about the IXP465 with its PTP function. The Intel
> devel board had a silicon bug making the PTP function useless. But
> even if the bug got fixed, still the PTP function was very limiting.
>
> I never got any feedback about the IXP465 PTP stuff, and so I doubt
> whether anyone is really using the Linux PTP driver on the IXP465, but
> you never know.

Ah, OK.
I have just checked, Intel's spec update says IXP46x steppings A1 and A2
are fixed. PTP on 46x-A0 is broken.
42x and 43x don't support PTP.

OTOH there is interesting stuff there:
Problem: The A-0 and A-1 stepping of the Intel? IXP45X/IXP46X Product Line of Network
         Processors can enter a condition whereby the system locks up when certain
         combinations of memory accesses occur nearly simultaneously.

         After more extensive investigation, it has been identified that the lockup condition can
         be caused by near-simultaneous accesses to 1 or 2 cache lines. The accesses to the
         cache lines must be performed by the Intel XScale processor, South AHB, and/or North
         AHB for the lockup to happen.

Hmmm...
-- 
Krzysztof Halasa