| Message ID | 1378816260-8091-1-git-send-email-linus.walleij@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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>
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
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.
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
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 --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);
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(-)