When data is read through DMA, the last element must be read separately
through the RX register. It cannot be transferred by the DMA. For
further details see e.g. OMAP35x TRM (table 19-16).
Without the fix the driver causes extra clocks to be clocked to the bus
after DMA RX operations. This can cause interesting behaviour with some
devices.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: Eero Nurkkala <ext-eero.nurkkala@nokia.com>
[aaro.koskinen@nokia.com: Simplified the patch while keeping the idea.]
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix a post-2.6.31 regression which was introduced by
2ff05b2b4e ("oom: move oom_adj value from
task_struct to mm_struct").
After moving the oom_adj value from the task struct to the mm_struct, the
oom_adj value was no longer properly inherited by child processes.
Copying over the oom_adj value at fork time fixes that bug.
[kosaki.motohiro@jp.fujitsu.com: test for current->mm before dereferencing it]
Signed-off-by: Rik van Riel <riel@redhat.com>
Reported-by: Paul Menage <manage@google.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If a task is oom killed and still cannot find memory when trying with
no watermarks, it's better to fail the allocation attempt than to loop
endlessly. Direct reclaim has already failed and the oom killer will
be a no-op since current has yet to die, so there is no other
alternative for allocations that are not __GFP_NOFAIL.
Acked-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix a post-2.6.24 performace regression caused by
3dfa5721f1 ("page-allocator: preserve PFN
ordering when __GFP_COLD is set").
Narayanan reports "The regression is around 15%. There is no disk controller
as our setup is based on Samsung OneNAND used as a memory mapped device on a
OMAP2430 based board."
The page allocator tries to preserve contiguous PFN ordering when returning
pages such that repeated callers to the allocator have a strong chance of
getting physically contiguous pages, particularly when external fragmentation
is low. However, of the bulk of the allocations have __GFP_COLD set as they
are due to aio_read() for example, then the PFNs are in reverse PFN order.
This can cause performance degration when used with IO controllers that could
have merged the requests.
This patch attempts to preserve the contiguous ordering of PFNs for users of
__GFP_COLD.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Reported-by: Narayananu Gopalakrishnan <narayanan.g@samsung.com>
Tested-by: Narayanan Gopalakrishnan <narayanan.g@samsung.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When an XRDY/XDR is hit, wait for XUDF before writing data to DATA_REG.
Otherwise some data bytes can be lost while transferring them from the
memory to the I2C interface.
Do a Busy-wait for XUDF, before writing data to DATA_REG. While waiting
if there is NACK | AL, set the appropriate error flags, ack the pending
interrupts and return from the ISR.
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Vikram pandita <vikram.pandita@ti.com>
[ben-linux@fluff.org: fixed mail format and added i2c-omap to subject]
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
In case of a NACK or ARDY or AL interrupt, complete the request.
There is no need to service the RRDY/RDR or XRDY/XDR interrupts.
Refer TRM SWPU114: Figure 18-31.I2C Master Transmitter Mode, Interrupt Method,
in F/S and HS Modes
http://focus.ti.com/pdfs/wtbu/SWPU114T_PrelimFinalEPDF_06_25_2009.pdf
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Vikram pandita <vikram.pandita@ti.com>
[ben-linux@fluff.org: fixed mail format and added i2c-omap to subject]
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Fix bug in reading the I2C_BUFFSTAT register for getting byte count on RX/TX interrupt.
On Interrupt: I2C_STAT[RDR],
read 'RXSTAT' from I2C_BUFFSTAT[8-13]
On Interrupt: I2C_STAT[XDR]
read 'TXSTAT' from I2C_BUFFSTAT[0-5]
Signed-off-by: Jagadeesh Pakaravoor <j-pakaravoor@ti.com>
Signed-off-by: Moiz Sonasath <m-sonasath@ti.com>
Signed-off-by: Vikram pandita <vikram.pandita@ti.com>
[ben-linux@fluff.org: fixed mail format and added i2c-omap to subject]
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Convert the i2c-sh_mobile i2c bus driver to use
subsys_initcall() instead of module_init().
This change makes the driver register a bit earlier which
together with earlier platform data moves the time for probe().
The earlier probe() makes it possible to use i2c_get_adapter()
and i2c_transfer() from device_initcall().
The same strategy is used by other i2c bus drivers such as
i2c-pxa.c and i2c-s3c2410.c.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
[ben-linux@fluff.org: minor subject updaye]
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
s3c24xx_i2c_init() was overwriting the IICLC value set just above in
s3c24xx_i2c_clockrate() with zero, effectively disabling the platform
line control setting.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
The value of armclk_mask needs to be inverted for use as a mask on
the register value when updating ARM_RATIO.
This is critical for cpufreq support, without it attempts to scale
the frequency of the core trash pretty much the entire clock tree.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
If the requested clock is faster than the parent clock then the
parent clock is the closest we can get to the request so we need
to return that instead of the requested clock.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
In the s3c_gpiolib_getchip implementation for s3c24xx the check whether a pin is
in the gpio banks range is reversed. Thus the function returns NULL for valid
pins and the gpio chip if its not valid.
As a result gpio states are not saved/restored properly during suspend/resume.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Early Pentium M models use different method for enabling TM2
(per paragraph 13.5.2.3 of the "Intel 64 and IA-32 Architectures
Software Developer's Manual Volume 3A: System Programming Guide,
Part 1").
Tested on the affected Pentium M variant (model == 13).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
fseverities_coverage is never NULL in err_out code path.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Reviewed-by: Andi Kleen <andi@firstfloor.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
mce_cap_init() and mce_cpu_quirks() can be tagged with __cpuinit.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Reviewed-by: Andi Kleen <andi@firstfloor.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
"mce argument mce ignored. Please use /sys" message shouldn't
be printed when using "mce" boot option.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Reviewed-by: Andi Kleen <andi@firstfloor.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
On my legacy Pentium M laptop (Acer Extensa 2900) I get bogus MCE on a cold
boot with CONFIG_X86_NEW_MCE enabled, i.e. (after decoding it with mcelog):
MCE 0
HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 0 BANK 1 MCG status:
MCi status:
Error overflow
Uncorrected error
Error enabled
Processor context corrupt
MCA: Data CACHE Level-1 UNKNOWN Error
STATUS f200000000000195 MCGSTATUS 0
[ The other STATUS values observed: f2000000000001b5 (... UNKNOWN error)
and f200000000000115 (... READ Error).
To verify that this is not a CONFIG_X86_NEW_MCE bug I also modified
the CONFIG_X86_OLD_MCE code (which doesn't log any MCEs) to dump
content of STATUS MSR before it is cleared during initialization. ]
Since the bogus MCE results in a kernel taint (which in turn disables
lockdep support) don't log boot MCEs on Pentium M (model == 13) CPUs
by default ("mce=bootlog" boot parameter can be be used to get the old
behavior).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Reviewed-by: Andi Kleen <andi@firstfloor.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Baed on Eric's idea in order to handle multiple sdvo encoders
we implement another approach to dynamically chose real one
encoder after detection, which is contrasted with patch -
drm/i915:Construct all possible sdvo outputs for sdvo encoder.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
In order to get best possible quality image we chose 640x480 for
NTSC, PAL and 480p, 1280x720 for 720p, 1920x1080 for 1080i/p
TV format respectively.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
I had one report of flicker due to FIFO underruns on 845G. Scott was
kind enough to test a few patches and report success with this one.
Looks like 845G measures FIFO size slightly differently than other
chips, and we were also clobbering the FIFO burst length. Fixing both
of those issues gives him a healthy machine again.
Note that we still only adjust plane A's watermark in the 830/845
case. If someone is willing to test we could support a bigger variety
of dual-head 830/845 configurations with a bit more code.
Fixes fdo bug #19304 (again).
Reported-by: Scott Hansen <scottandchrystie@comcast.net>
Tested-by: Scott Hansen <scottandchrystie@comcast.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Check FORCE_DETECT bit to be clear for the finish
of hotplug detect process. Also check possible mono
monitor which should also be marked as connected.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This adds embedded DisplayPort support on next mobile chip which
aims to replace origin LVDS port. VBT's driver feature block has
been used to determine the type of current internal panel for eDP
or LVDS.
Currently no panel fitting support for eDP and backlight control
would be added in future.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
We should use current channel 'status' bits to clear DP aux channel's
done and error bits, instead of using the channel setting bits, that
will set send/busy bit again to initiate new transaction.
This also includes also some minor cleanup.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
During pipe DPMS off, instead of busy waiting pipe off, insert
delays during wait and don't loop after enough tries which matches
spec requirement. Also try to match DPMS on path by disable FDI TX
PLL in DPMS off. Disable PF by writing PF_WIN_SZ which really trigger
the update.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This does VGA disable like DDX driver. SR01 bit 5 should be set
before VGA plane disable through control register, otherwise we
might get random crash and lockups.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Now the DVO timing in LVDS data entry is obtained by using the
following step:
a. get the entry size for every LVDS panel data
b. Get the LVDS fp entry for the preferred panel type
c. get the DVO timing by using entry->dvo_timing
In our driver the entry->dvo_timing is related with the size of
lvds_fp_timing. For example: the size is 46.
But it seems that the size of lvds_fp_timing varies on the differnt
platform. In such case we will get the incorrect DVO timing entry
because of the incorrect DVO offset in LVDS panel data entry.
This also removes a hack on new IGDNG to get proper DVO timing.
Calculate the DVO timing offset in LVDS data entry to get the DVO timing
a. get the DVO timing offset in the LVDS fp data entry by using the
pointer definition in LVDS data ptr
b. get the LVDS data entry
c. get the DVO timing by adding the DVO timing offset to data entry
https://bugs.freedesktop.org/show_bug.cgi?id=22787
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Tested-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
1. fix "line over 80 characters" checkpatch warnings
2. ‘DMA_nnBIT_MASK’ is deprecated, use DMA_BIT_MASK instead
3. fix typos
Signed-off-by: Barry Song <21cnbao@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
With the s3c platform has implementing gpiolib support the s3c_gpio api has been
deprecated.
This patch gets rid of all s3c_gpio calls and replaces them by using gpiolib.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Add debugfs file to enable/disable HT40(40MHz) channel support.
By default, 40MHz is supported if AP can support the function.
By echo "1" to "disable_ht40" file, iwlwifi driver will disable the
40MHz support and only allow 20MHz channel.
Because the information exchange happen during association time,
so enable/disable ht40 channel only can be performed when it is not
associated with AP.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Finally! This is what you've all been waiting for!
This patch makes cfg80211 take care of wext emulation
_completely_ by itself, drivers that don't need things
cfg80211 doesn't do yet don't even need to be aware of
wireless extensions.
This means we can also clean up mac80211's and iwm's
Kconfig and make it possible to build them w/o wext
now!
RIP wext.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since we now have handlers IWESSID for all modes, we can
combine them into one.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Since we now have IWAP handlers for all modes, we can
combine them into one.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Until now we implemented iwfreq for managed mode, we
needed to keep the implementations separate, but now
that we have all versions implemented we can combine
them and export just one handler.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When enqueuing packets on the internal packet queue, we
need to ensure that we have a valid vif pointer since
that is required since the net namespace work. Add some
assertions to verify this, but also don't crash is for
some reason we don't end up with a vif pointer -- warn
and drop the packet in all these cases.
Since this code touches a number of hotpaths, it is
intended to be temporary, or maybe configurable in the
future, at least the bit that is in the path that gets
hit for every packet, ieee80211_tx_pending().
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When trying to disassociate while not associated,
the kernel would crash rather than refusing the
operation, fix this;
Reported-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix an oops in ieee80211_scan_state_set_channel which was triggered
if the last scanned channel was skipped (for example due to regulatory
restrictions) by returning to the decision state after each skipped
channel.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Jouni and Maxim reported an oops when using wpa_supplicant -Dnl80211,
which seems to be due to random data being contained in the crypto
settings for the assoc() command. This seems to be due to the missing
memset here, so add it -- it's certainly missing but I'm not 100%
certain that it will fix the problem.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We are using setpower routines regardless of the current power mode.
Don't bother the hardware, if it is not necessary.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There is a small window where the mac80211 changes the IEEE80211_CONF_PS
flag, and then informs the driver about the change. We have a race
condition if we are checking the flag in the same time. Avoid it by
introducing a local variable, and using that instead of checking the
IEEE80211_CONF_PS flag directly.
This fix the problem reported by Luis:
http://article.gmane.org/gmane.linux.kernel.wireless.general/34363
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix this build error when CONFIG_AR9170_LEDS is not set
drivers/net/wireless/ath/ar9170/main.c:1296: error: 'struct ar9170' has
no member named 'led_work'
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
