[PATCH 5/6] Clocklib: Use correct clock for IrDA on pxa - Kernel

This is a discussion on [PATCH 5/6] Clocklib: Use correct clock for IrDA on pxa - Kernel ; Signed-off-by: Dmitry Baryshkov --- drivers/net/irda/pxaficp_ir.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/irda/pxaficp_ir.c b/drivers/net/irda/pxaficp_ir.c index 8c09344..36d2ec0 100644 --- a/drivers/net/irda/pxaficp_ir.c +++ b/drivers/net/irda/pxaficp_ir.c @@ -814,7 +814,7 @@ static int pxa_irda_probe(struct platform_device *pdev) si->dev = &pdev->dev; si->pdata = ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: [PATCH 5/6] Clocklib: Use correct clock for IrDA on pxa

  1. [PATCH 5/6] Clocklib: Use correct clock for IrDA on pxa

    Signed-off-by: Dmitry Baryshkov
    ---
    drivers/net/irda/pxaficp_ir.c | 2 +-
    1 files changed, 1 insertions(+), 1 deletions(-)

    diff --git a/drivers/net/irda/pxaficp_ir.c b/drivers/net/irda/pxaficp_ir.c
    index 8c09344..36d2ec0 100644
    --- a/drivers/net/irda/pxaficp_ir.c
    +++ b/drivers/net/irda/pxaficp_ir.c
    @@ -814,7 +814,7 @@ static int pxa_irda_probe(struct platform_device *pdev)
    si->dev = &pdev->dev;
    si->pdata = pdev->dev.platform_data;

    - si->sir_clk = clk_get(&pdev->dev, "UARTCLK");
    + si->sir_clk = clk_get(&pdev->dev, "SIRCLK");
    si->fir_clk = clk_get(&pdev->dev, "FICPCLK");
    if (IS_ERR(si->sir_clk) || IS_ERR(si->fir_clk)) {
    err = PTR_ERR(IS_ERR(si->sir_clk) ? si->sir_clk : si->fir_clk);
    --
    1.5.4.4


    --
    With best wishes
    Dmitry

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 5/6] Clocklib: Use correct clock for IrDA on pxa

    On Wed, Apr 09, 2008 at 09:52:33PM +0100, Alan Cox wrote:
    > > > It's called a line discipline, we've had them for many years. We may need
    > > > a way for ldiscs and drivers to co-operate a bit more but these days we
    > > > support proper buffering and arbitary baud rates (except on a few
    > > > platforms whose maintainers are not paying attention ).

    > >
    > > I feel that's a "it would be nice if" solution - and something worth
    > > aiming for, but the amount of work required to get there is not going
    > > to be insignificant.

    >
    > The work required to fix up the existing FIR hacks is not insignifcant
    > either. Also right now the tty layer is getting a major rework so now is
    > actually the time to sort out anything extra that is needed.
    >
    > If you want 4MBit please just use an ldisc and do
    >
    > struct ktermios tmp;
    > mutex_lock(&tty->termios_mutex);
    > tmp = *tty->termios;
    > tty_encode_baud_rate(tty, 4000000, 4000000);
    > tty->driver->set_termios(tty, &tmp);
    > mutex_unlock(&tty->termios_mutex);


    There's more to FIR than just a baud rate change. On PXA for instance,
    SIR is implemented using the standard UART device in "SIR" mode, but FIR
    is a completely separate hardware block with its own IRQs and clocks -
    you need to switch the pin muxing from the UART to the FIR device.

    So it's not just a matter of setting the baud rate to 4Mbps.

    However, you can't just say "have two separate drivers and only use
    one or the other" - all IrDA link negotiation is done at SIR at 9600
    baud and only when negotiation is complete will the selected rate
    become effective - be that SIR or FIR based.

    So yes, using a ldisc for SIR (with a hook into the driver to tell the
    driver to setup the port for IR) sounds ideal, but we're still going to
    need to deal with the FIR device and switch IrDA between that and the
    SIR UART ldisc.

    Note - there are other reasons for finally sorting this out as well -
    there are systems with IR which want to support both IrDA up to FIR
    and other uart-based IR applications. IIRC this came up on the iPAQs.
    I forget exactly which applications but I believe lirc might fall into
    the "want a serial port not the FIR network device interface" class.
    Having SIR always go via ldiscs should sort that out nicely as well.
    (I'm thinking maybe we want some control to set a port into IR
    transmission/reception mode independent of selecting the IrDA ldisc -
    but I'd suggest further research first - I may be just handwaving
    about an already solved problem.)

    --
    Russell King
    Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
    maintainer of:
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread