This patch changes the code setting ranges of GPIO pins in mach-s5pv310 using
s3c_gpio_cfgpin() to use the recently introduced s3c_gpio_cfgpin_range().
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Change the code setting ranges of GPIO pins using s3c_gpio_cfgpin() to
use the recently introduced s3c_gpio_cfgpin_range().
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
[kgene.kim@samsung.com: coding-style fixes]
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Change the code setting ranges of GPIO pins using s3c_gpio_cfgpin() to
use the recently introduced s3c_gpio_cfgpin_range().
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
[kgene.kim@samsung.com: Fixed wrong change]
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch changes the code setting ranges of GPIO pins in mach-s5p64x0 using
s3c_gpio_cfgpin() to use the recently introduced s3c_gpio_cfgpin_range().
NOTE: This is for missed things from the previous patch.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Change the code setting ranges of GPIO pins using s3c_gpio_cfgpin() to
use the recently introduced s3c_gpio_cfgpin_range().
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
[kgene.kim@samsung.com: modified to s5p64x0 from s5p6440]
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Change the code setting ranges of GPIO pins using s3c_gpio_cfgpin() to
use the recently introduced s3c_gpio_cfgpin_range().
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
[kgene.kim@samsung.com: fixed wrong change]
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Change the code setting ranges of GPIO pins using s3c_gpio_cfgpin() to
use the recently introduced s3c_gpio_cfgpin_range().
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
To aide in changing the gpio code, remove the use of pin-specific configs
and move to using the S3C_GPIO_SFN() versions.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Add s3c_gpio_cfgpin_range() to configure a range of pins to the given
value. This is useful for a number of blocks where the pins are in order
and saves multiple calls to s3c_gpio_cfgpin().
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch fixes build error about GPIO address due to
conflict of commit 4d914705 and 19a2c065.
- commit 4d914705: Fix on GPIO base addresses
- commit 19a2c065: Moves initial map for merging S5P64X0
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch adds header <linux/sched.h> into the below files for build with
CONFIG_PREEMPT_NONE.
arch/arm/mach-s5p64x0/cpu.c
Signed-off-by: Seung-Chull Suh <sc.suh@samsung.com>
[kgene.kim@samsung.com: edited title and message]
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
The patch removes s3c_gpio_lock/unlock to avoid acquiring the lock
recursively as lock is already acquired by calling function.
Signed-off-by: Atul Dahiya <atul.dahiya@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
[kgene.kim@samsung.com: removed useless variable due to this]
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
The s5p64x0_sysclass should be used in place of the obselete s5p6440_sysclass.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Sangbeom Kim <sbkim73@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Fix the touch screen device name from s3c64x0-adc to s3c64xx-adc.
Signed-off-by: Naveen Krishna Ch <ch.naveen@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch updates s5p64x0_defconfig and changes the name from
s5p6440_defconfig so that can support S5P6440 and S5P6450 with
one kernel.
Tested on SMDK6440(S5P6440) and SMDK6450(S5P6450).
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch adds UART serial port support for S5P6450 SoC.
The S5P6450 has 6 UARTs, so adds resource of UART4 and UART5.
And to fix membase which is in serial/samsung.c is from Ben Dooks.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
This patch moves smdk6440 board file from mach-s5p6440 into the new
mach-s5p64x0 directory and adds smdk6450 board file.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch moves S5P6440 GPIO support files from mach-s5p6440
into the new mach-s5p64x0 for merge S5P6440 and S5P6450 SocS.
NOTE: Not supported S5P6450 GPIO yet. Will be supported soon.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch adds S5P6450 I2C support in the ARCH_S5P64X0. And
moves S5P6440 I2C support files into the mach-s5p64x0 together.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch moves DMA support files in the mach-s5p64x0
for S5P6440 and S5P6450 SoCs.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Jassi Brar <jassi.brar@samsung.com>
This patch updates Audio and SPI for S5P6440 and S5P6450 SoCs.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Jassi Brar <jassi.brar@samsung.com>
This patch updates regarding clock files for supporting S5P6440 and
S5P6450 with one kernel image. The mach-s5p64x0/clock.c is for common
of them and there are specific clock files for each SoCs.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch adds ARCH_S5P64X0 which can support S5P6440 and S5P6450 with
one kernel image. So moved some files of mach-s5p6440 into the new ARCH
directory mach-s5p64x0.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch updates the Kconfig and Makefile for the S5P6440 and S5P6450
machines. It also updates arch/arm/ Kconfig and Makefile to include for
support ARCH_S5P64X0 with one kernel image.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch moves some initial maps from plat-s5p to machine,
so that can merge mach-s5p6440 and mach-s5p6450.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch moves OneNAND device definitions from mach-s5pv210 to plat-s5p
so that can support it commonly.
Note: S5PC110 and S5PC210 have same OneNAND driver.
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Tony Luck reports that the addition of the access_ok() check in commit
0eead9ab41 ("Don't dump task struct in a.out core-dumps") broke the
ia64 compile due to missing the necessary header file includes.
Rather than add yet another include (<asm/unistd.h>) to make everything
happy, just uninline the silly core dump helper functions and move the
bodies to fs/exec.c where they make a lot more sense.
dump_seek() in particular was too big to be an inline function anyway,
and none of them are in any way performance-critical. And we really
don't need to mess up our include file headers more than they already
are.
Reported-and-tested-by: Tony Luck <tony.luck@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
ehea: Fix a checksum issue on the receive path
net: allow FEC driver to use fixed PHY support
tg3: restore rx_dropped accounting
b44: fix carrier detection on bind
net: clear heap allocations for privileged ethtool actions
NET: wimax, fix use after free
ATM: iphase, remove sleep-inside-atomic
ATM: mpc, fix use after free
ATM: solos-pci, remove use after free
net/fec: carrier off initially to avoid root mount failure
r8169: use device model DMA API
r8169: allocate with GFP_KERNEL flag when able to sleep
akiphie points out that a.out core-dumps have that odd task struct
dumping that was never used and was never really a good idea (it goes
back into the mists of history, probably the original core-dumping
code). Just remove it.
Also do the access_ok() check on dump_write(). It probably doesn't
matter (since normal filesystems all seem to do it anyway), but he
points out that it's normally done by the VFS layer, so ...
[ I suspect that we should possibly do "vfs_write()" instead of
calling ->write directly. That also does the whole fsnotify and write
statistics thing, which may or may not be a good idea. ]
And just to be anal, do this all for the x86-64 32-bit a.out emulation
code too, even though it's not enabled (and won't currently even
compile)
Reported-by: akiphie <akiphie@lavabit.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
ring-buffer: Fix typo of time extends per page
perf, MIPS: Support cross compiling of tools/perf for MIPS
perf: Fix incorrect copy_from_user() usage
* master.kernel.org:/home/rmk/linux-2.6-arm:
ARM: relax ioremap prohibition (309caa9) for -final and -stable
ARM: 6440/1: ep93xx: DMA: fix channel_disable
cpuimx27: fix i2c bus selection
cpuimx27: fix compile when ULPI is selected
ARM: 6435/1: Fix HWCAP_TLS flag for ARM11MPCore/Cortex-A9
ARM: 6436/1: AT91: Fix power-saving in idle-mode on 926T processors
ARM: fix section mismatch warnings in Versatile Express
ARM: 6412/1: kprobes-decode: add support for MOVW instruction
ARM: 6419/1: mmu: Fix MT_MEMORY and MT_MEMORY_NONCACHED pte flags
ARM: 6416/1: errata: faulty hazard checking in the Store Buffer may lead to data corruption
* 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6:
omap: iommu-load cam register before flushing the entry
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon/kms: Silent spurious error message
drm/radeon/kms: fix bad cast/shift in evergreen.c
drm/radeon/kms: make TV/DFP table info less verbose
drm/radeon/kms: leave certain CP int bits enabled
drm/radeon/kms: avoid corner case issue with unmappable vram V2
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86, numa: For each node, register the memory blocks actually used
x86, AMD, MCE thresholding: Fix the MCi_MISCj iteration order
x86, mce, therm_throt.c: Fix missing curly braces in error handling logic
Commit 0793448 "DMAENGINE: generic channel status v2" changed the interface for
how dma channel progress is retrieved. It inadvertently exported an internal
helper function ioat_tx_status() instead of ioat_dma_tx_status(). The latter
polls the hardware to get the latest completion state, while the helper just
evaluates the current state without touching hardware. The effect is that we
end up waiting for completion timeouts or descriptor allocation errors before
the completion state is updated.
iperf (before fix):
[SUM] 0.0-41.3 sec 364 MBytes 73.9 Mbits/sec
iperf (after fix):
[SUM] 0.0- 4.5 sec 499 MBytes 940 Mbits/sec
This is a regression starting with 2.6.35.
Cc: <stable@kernel.org>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: Maciej Sosnowski <maciej.sosnowski@intel.com>
Reported-by: Richard Scobie <richard@sauce.co.nz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Currently we set all skbs with CHECKSUM_UNNECESSARY, even
those whose protocol we don't know. This patch just
add the CHECKSUM_COMPLETE tag for non TCP/UDP packets.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As of commit 43a9aa64a2 "NFSD:
Fill in WCC data for REMOVE, RMDIR, MKNOD, and MKDIR", we sometimes call
fh_unlock on a filehandle that isn't fully initialized.
We should fix up the callers, but as a quick fix it is also sufficient
just to remove this assertion.
Reported-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
Cc: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
At least one board using the FEC driver does not have a conventional
PHY attached to it, it is directly connected to a somewhat simple
ethernet switch (the board is the SnapGear/LITE, and the attached
4-port ethernet switch is a RealTek RTL8305). This switch does not
present the usual register interface of a PHY, it presents nothing.
So a PHY scan will find nothing - it finds ID's of 0 for each PHY
on the attached MII bus.
After the FEC driver was changed to use phylib for supporting PHYs
it no longer works on this particular board/switch setup.
Add code support to use a fixed phy if no PHY is found on the MII bus.
This is based on the way the cpmac.c driver solved this same problem.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
... but produce a big warning about the problem as encouragement
for people to fix their drivers.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When channel_disable() is called, it disables per channel interrupts and
waits until channels state becomes STATE_STALL, and then disables the
channel. Now, if the DMA transfer is disabled while the channel is in
STATE_NEXT we will not wait anything and disable the channel immediately.
This seems to cause weird data corruption for example in audio transfers.
Fix is to wait while we are in STATE_NEXT or STATE_ON and only then
disable the channel.
Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Ryan Mallon <ryan@bluewatersys.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Time stamps for the ring buffer are created by the difference between
two events. Each page of the ring buffer holds a full 64 bit timestamp.
Each event has a 27 bit delta stamp from the last event. The unit of time
is nanoseconds, so 27 bits can hold ~134 milliseconds. If two events
happen more than 134 milliseconds apart, a time extend is inserted
to add more bits for the delta. The time extend has 59 bits, which
is good for ~18 years.
Currently the time extend is committed separately from the event.
If an event is discarded before it is committed, due to filtering,
the time extend still exists. If all events are being filtered, then
after ~134 milliseconds a new time extend will be added to the buffer.
This can only happen till the end of the page. Since each page holds
a full timestamp, there is no reason to add a time extend to the
beginning of a page. Time extends can only fill a page that has actual
data at the beginning, so there is no fear that time extends will fill
more than a page without any data.
When reading an event, a loop is made to skip over time extends
since they are only used to maintain the time stamp and are never
given to the caller. As a paranoid check to prevent the loop running
forever, with the knowledge that time extends may only fill a page,
a check is made that tests the iteration of the loop, and if the
iteration is more than the number of time extends that can fit in a page
a warning is printed and the ring buffer is disabled (all of ftrace
is also disabled with it).
There is another event type that is called a TIMESTAMP which can
hold 64 bits of data in the theoretical case that two events happen
18 years apart. This code has not been implemented, but the name
of this event exists, as well as the structure for it. The
size of a TIMESTAMP is 16 bytes, where as a time extend is only
8 bytes. The macro used to calculate how many time extends can fit on
a page used the TIMESTAMP size instead of the time extend size
cutting the amount in half.
The following test case can easily trigger the warning since we only
need to have half the page filled with time extends to trigger the
warning:
# cd /sys/kernel/debug/tracing/
# echo function > current_tracer
# echo 'common_pid < 0' > events/ftrace/function/filter
# echo > trace
# echo 1 > trace_marker
# sleep 120
# cat trace
Enabling the function tracer and then setting the filter to only trace
functions where the process id is negative (no events), then clearing
the trace buffer to ensure that we have nothing in the buffer,
then write to trace_marker to add an event to the beginning of a page,
sleep for 2 minutes (only 35 seconds is probably needed, but this
guarantees the bug), and then finally reading the trace which will
trigger the bug.
This patch fixes the typo and prevents the false positive of that warning.
Reported-by: Hans J. Koch <hjk@linutronix.de>
Tested-by: Hans J. Koch <hjk@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Stable Kernel <stable@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
I see the following error message in my kernel log from time to time:
radeon 0000:07:00.0: ffff88007c334000 reserve failed for wait
radeon 0000:07:00.0: ffff88007c334000 reserve failed for wait
After investigation, it turns out that there's nothing to be afraid of
and everything works as intended. So remove the spurious log message.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
