07 Jan, 2012

1 commit

  • …git-cur/linux-2.6-arm

    * 'amba-modalias' of git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-2.6-arm:
    sound: aaci: Enable module alias autogeneration for AMBA drivers
    watchdog: sp805: Enable module alias autogeneration for AMBA drivers
    fbdev: amba: Enable module alias autogeneration for AMBA drivers
    serial: pl011: Enable module alias autogeneration for AMBA drivers
    serial: pl010: Enable module alias autogeneration for AMBA drivers
    spi: pl022: Enable module alias autogeneration for AMBA drivers
    rtc: pl031: Enable module alias autogeneration for AMBA drivers
    rtc: pl030: Enable module alias autogeneration for AMBA drivers
    mmc: mmci: Enable module alias autogeneration for AMBA drivers
    input: ambakmi: Enable module alias autogeneration for AMBA drivers
    gpio: pl061: Enable module alias autogeneration for AMBA drivers
    dmaengine: pl330: Enable module alias autogeneration for AMBA drivers
    dmaengine: pl08x: Enable module alias autogeneration for AMBA drivers
    hwrng: nomadik: Enable module alias autogeneration for AMBA drivers
    ARM: amba: Auto-generate AMBA driver module aliases during modpost
    ARM: amba: Move definition of struct amba_id to mod_devicetable.h

    Linus Torvalds
     

26 Dec, 2011

1 commit

  • The AMBA ID table is marked as __initdata, yet it is referenced by the
    driver struct which is not. This causes a (somewhat unhelpful) section
    mismatch warning:

    WARNING: drivers/watchdog/sp805_wdt.o(.data+0x4c): Section mismatch in
    reference from the variable sp805_wdt_driver to the (unknown
    reference) .init.data:(unknown)

    Fix this by removing the annotation.

    Signed-off-by: Nick Bowler
    Signed-off-by: Wim Van Sebroeck

    Nick Bowler
     

22 Nov, 2011

1 commit


27 Jul, 2011

2 commits

  • There are no reads in these functions, so if MMIO writes are posted,
    the writes in enable/disable may not have completed by the time these
    functions return. If the functions run from different CPUs, it's
    in theory possible for the writes to be interleaved, which would be
    disastrous for this driver.

    At the very least, we need an mmiowb() before releasing the lock, but
    since it seems desirable for the watchdog timer to be actually stopped
    or reset when these functions return, read the lock register to force
    the writes out.

    Signed-off-by: Nick Bowler
    Signed-off-by: Wim Van Sebroeck

    Nick Bowler
     
  • At least on the Versatile Express' V2M, calling wdt_disable followed by
    wdt_enable, for instance by running the following sequence:

    echo V > /dev/watchdog; echo V > /dev/watchdog

    results in an immediate reset. The wdt_disable function writes 0 to the
    load register; while the watchdog interrupts are disabled at this point,
    this special value is defined to trigger an interrupt immediately. It
    appears that in this instance, the reset happens when the interrupts
    are subsequently enabled by wdt_enable.

    Putting in a short delay after writing a new load value in wdt_enable
    solves the issue, but it seems cleaner to simply never write 0 to the
    load register at all: according to the hardware docs, writing 0 to the
    control register suffices to stop the counter, and the write of 0 to
    the load register is questionable anyway since this register resets to
    0xffffffff.

    Signed-off-by: Nick Bowler
    Signed-off-by: Wim Van Sebroeck

    Nick Bowler
     

31 Mar, 2011

1 commit


24 Feb, 2011

1 commit


09 Aug, 2010

1 commit