| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/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
|
| |
| |
| |
| | |
Signed-off-by: Dave Martin <dave.martin@linaro.org>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <nbowler@elliptictech.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <nbowler@elliptictech.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <nbowler@elliptictech.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
|
|
|
|
|
| |
Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
|
|
|
|
|
|
|
|
| |
Make Primecell driver probe functions take a const pointer to their
ID tables. Drivers should never modify their ID tables in their
probe handler.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
|
|
Technical Reference Manual can be found at:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0270b/DDI0270.pdf
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|