diff mbox

[4/7] ptp: switch to use gpiolib

Message ID 1378816260-8091-1-git-send-email-linus.walleij@linaro.org
State Not Applicable, archived
Delegated to: David Miller
Headers show

Commit Message

Linus Walleij Sept. 10, 2013, 12:31 p.m. UTC
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(-)

Comments

Richard Cochran Sept. 10, 2013, 2:19 p.m. UTC | #1
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>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij Sept. 13, 2013, 8:38 a.m. UTC | #2
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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Krzysztof Halasa Sept. 13, 2013, 12:22 p.m. UTC | #3
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.
Richard Cochran Sept. 13, 2013, 1:36 p.m. UTC | #4
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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Krzysztof Halasa Sept. 13, 2013, 5:36 p.m. UTC | #5
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...
diff mbox

Patch

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);