| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6
* 'media_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6:
[media] mantis_pci: remove asm/pgtable.h include
[media] tda829x: fix regression in probe functions
[media] mceusb: don't claim multifunction device non-IR parts
[media] nuvoton-cir: fix wake from suspend
[media] cx18: Add support for Hauppauge HVR-1600 models with s5h1411
[media] ivtv: Fix corrective action taken upon DMA ERR interrupt to avoid hang
[media] cx25840: fix probing of cx2583x chips
[media] cx23885: Remove unused 'err:' labels to quiet compiler warning
[media] cx23885: Revert "Check for slave nack on all transactions"
[media] DiB7000M: add pid filtering
[media] Fix sysfs rc protocol lookup for rc-5-sz
[media] au0828: fix VBI handling when in V4L2 streaming mode
[media] ir-raw: Properly initialize the IR event (BZ#27202)
[media] s2255drv: firmware re-loading changes
[media] Fix double free of video_device in mem2mem_testdev
[media] DM04/QQBOX memcpy to const char fix
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
mantis_pci.c is including asm/pgtable.h and it's leading to a build failure on
arm. It has been noticed here :
https://buildd.debian.org/fetch.cgi?pkg=linux-2.6&arch=armel&ver=2.6.38~rc6-1~experimental.1&stamp=1298430952&file=log&as=raw
As this header doesn't seem to be used, I'm removing it. I've build tested it
with arm and x86.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In commit 567aba0b7997dad5fe3fb4aeb174ee9018df8c5b, the probe address
for tda8290_probe and tda8295_probe was hard-coded to 0x4b, which is the
default i2c address for those devices, but its possible for the device
to be at an alternate address, 0x42, which is the case for the HVR-1950.
If we probe the wrong address, probe fails and we have a non-working
device. We have the actual address passed into the function by way of
i2c_props, we just need to use it. Also fix up some copy/paste comment
issues and streamline debug spew a touch. Verified to restore my
HVR-1950 to full working order.
Special thanks to Ken Bass for reporting the issue in the first place,
and to both he and Gary Buhrmaster for aiding in debugging and analysis
of the problem.
Reported-by: Ken Bass <kbass@kenbass.com>
Tested-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's a Realtek combo card reader and IR receiver device with multiple
usb interfaces on it. The mceusb driver is incorrectly grabbing all of
them. This change should make it bind to only interface 2 (patch based
on lsusb output on the linux-media list from Lucian Muresan).
Tested regression-free with the six mceusb devices I have myself.
Reported-by: Patrick Boettcher <pboettcher@kernellabs.com>
Reported-by: Lucian Muresan <lucianm@users.sourceforge.net>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The CIR Wake FIFO is 67 bytes long, but the stock remote appears to only
populate 65 of them. Limit comparison to 65 bytes, and wake from suspend
works a whole lot better (it wasn't working at all for most folks).
Fix based on comparison with the old lirc_wb677 driver from Nuvoton,
debugging and testing done by Dave Treacy by way of the lirc mailing
list.
Reported-by: Dave Treacy <davetreacy@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The newest variants of the HVR-1600 have an s5h1411/tda18271 for the digital
frontend. Add support for these boards.
Thanks to Hauppauge Computer Works for providing sample hardware.
[awalls@md.metrocast.net: Changed an additional log message to clarify for
the end user that the driver is defaulting to an original HVR-1600 for
unknown model numbers.]
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After upgrading the kernel from stock Ubuntu 7.10 to
10.04, with no hardware changes, I started getting the dreaded DMA
TIMEOUT errors, followed by inability to encode until the machine was
rebooted.
I came across a post from Andy in March
(http://www.gossamer-threads.com/lists/ivtv/users/40943#40943) where he
speculates that perhaps the corrective actions being taken after a DMA
ERROR are not sufficient to recover the situation. After some testing
I suspect that this is indeed the case, and that in fact the corrective
action may be what hangs the card's DMA engine, rather than the
original error.
Specifically these DMA ERROR IRQs seem to present with two different
values in the IVTV_REG_DMASTATUS register: 0x11 and 0x13. The current
corrective action is to clear that status register back to 0x01 or
0x03, and then issue the next DMA request. In the case of a 0x13 this
seems to result in a minor glitch in the encoded stream due to the
failed transfer that was not retried, but otherwise things continue OK.
In the case of a 0x11 the card's DMA write engine is never heard from
again, and a DMA TIMEOUT follows shortly after. 0x11 is the killer.
I suspect that the two cases need to be handled differently. The
difference is in bit 1 (0x02), which is set when the error is about to
be successfully recovered, and clear when things are about to go bad.
Bit 1 of DMASTATUS is described differently in different places either
as a positive "write finished", or an inverted "write busy". If we
take the first definition, then when an error arises with state 0x11,
it means that the write did not complete. It makes sense to start a
new transfer, as in the current code. But if we take the second
definition, then 0x11 means "an error but the write engine is still
busy". Trying to feed it a new transfer in this situation might not be
a good idea.
As an experiment, I added code to ignore the DMA ERROR IRQ if DMASTATUS
is 0x11. I.e., don't start a new transfer, don't clear our flags, etc.
The hope was that the card would complete the transfer and issue a ENC
DMA COMPLETE, either successfully or with an error condition there.
However the card still hung.
The only remaining corrective action being taken with a 0x11 status was
then the write back to the status register to clear the error, i.e.
DMASTATUS = DMASTATUS & ~3. This would have the effect of clearing the
error bit 4, while leaving the lower bits indicating DMA write busy.
Strangely enough, removing this write to the status register solved the
problem! If the DMA ERROR IRQ with DMASTATUS=0x11 is completely
ignored, with no corrective action at all, then the card will complete
the transfer and issue a new IRQ. If the status register is written to
when it has the value 0x11, then the DMA engine hangs. Perhaps it's
illegal to write to
DMASTATUS while the read or write busy bit is set? At any rate, it
appears that the current corrective action is indeed making things
worse rather than better.
I put together a patch that modifies ivtv_irq_dma_err to do the
following:
- Don't write back to IVTV_REG_DMASTATUS.
- If write-busy is asserted, leave the card alone. Just extend the
timeout slightly.
- If write-busy is de-asserted, retry the current transfer.
This has completely fixed my DMA TIMEOUT woes. DMA ERR events still
occur, but now they seem to be correctly handled. 0x11 events no
longer hang the card, and 0x13 events no longer result in a glitch in
the stream, as the failed transfer is retried. I'm happy.
I've inlined the patch below in case it is of interest. As described
above, I have a theory about why it works (based on a different
interpretation of bit 1 of DMASTATUS), but I can't guarantee that my
theory is correct. There may be another explanation, or it may be a
fluke. Maybe ignoring that IRQ entirely would be equally effective?
Maybe the status register read/writeback sequence is race condition if
the card changes it in the mean time? Also as I am using a PVR-150
only, I have not been able to test it on other cards, which may be
especially relevant for 350s that support concurrent decoding.
Hopefully the patch does not break the DMA READ path.
Mike
[awalls@md.metrocast.net: Modified patch to add a verbose comment, make minor
brace reformats, and clear the error flags in the IVTV_REG_DMASTATUS iff both
read and write DMA were not in progress. Mike's conjecture about a race
condition with the writeback is correct; it can confuse the DMA engine.]
[Comment and analysis from the ML post by Michael <mike@rsy.com>]
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix the probing of cx2583x chips, because two controls were clustered
that are not created for these chips.
This regression was introduced in 2.6.36.
Signed-off-by: Sven Barth <pascaldragon@googlemail.com>
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The previous revert-commit, that affected cx23885-i2c.c, left some
unused labels that the compiler griped about. Clean them up.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 44835f197bf1e3f57464f23dfb239fef06cf89be.
With the CX23885 hardware I2C master, checking for I2C slave ACK/NAK
is not valid when the I2C_EXTEND or I2C_NOSTOP bits are set.
Revert the commit that checks for I2C slave ACK/NAK on all transactions,
so that XC5000 tuners work with the CX23885 again.
Thanks go to Mark Zimmerman for reporting and bisecting this problem.
Bisected-by: Mark Zimmerman <markzimm@frii.com>
Reported-by: Mark Zimmerman <markzimm@frii.com>
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch adds the pid filtering for the dib7000M demod. It also
corrects the pid filtering for the dib7700 based board. It should
prevent an oops, when using dib7700p based board.
References: https://bugzilla.novell.com/show_bug.cgi?id=644807
Signed-off-by: Olivier Grenie <olivier.grenie@dibcom.fr>
Signed-off-by: Patrick Boettcher <patrick.boettcher@dibcom.fr>
Tested-by: Pavel SKARKA <paul.sp@seznam.cz>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With the current matching rules the lookup for rc protocol named rc-5-sz matches with "rc-5" before finding "rc-5-sz". Thus one is able to never enable/disable the rc-5-sz protocol via sysfs.
Fix the lookup to require an exact match which allows the manipulation of sz protocol.
Signed-off-by: Antti Seppälä <a.seppala@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
au0828: fix VBI handling when in V4L2 streaming mode
It turns up V4L2 streaming mode (a.k.a mmap) was broken for VBI streaming.
This was causing libzvbi to fall back to V4L1 capture mode, and is a blatent
violation of the V4L2 specification.
Make the implementation work properly in this mode.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Changeset 4651918a4afdd49bdea21d2f919b189ef17a6399 changed the way events
are stored. However, it forgot to fix ir_raw_event_store_edge() to work
with the new way. Due to that, the decoders will likely do bad things.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| | |
Change for firmware re-loading and updated firmware versions.
Signed-off-by: Dean Anderson <linux-dev@sensoray.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
video_device is already being freed in video_device.release callback on
release.
Signed-off-by: Pawel Osciak <pawel@osciak.com>
Reported-by: Roland Kletzing <devzero@web.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Driver Version v1.75 Kernel oops appears in 2.6.37-rc8 in
lme_firmware_switch because of a memcpy to a const char.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch fixes an issue in OpenIPMI module where sometimes an ABORT command
is sent after sending an IPMI request to BMC causing the IPMI request to fail.
Signed-off-by: YiCheng Doe <yicheng.doe@hp.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Acked-by: Tom Mingarelli <thomas.mingarelli@hp.com>
Tested-by: Andy Cress <andy.cress@us.kontron.com>
Tested-by: Mika Lansirine <Mika.Lansirinne@stonesoft.com>
Tested-by: Brian De Wolf <bldewolf@csupomona.edu>
Cc: Jean Michel Audet <Jean-Michel.Audet@ca.Kontron.com>
Cc: Jozef Sudelsky <jozef.sudolsky@elbiahosting.sk>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb
drm/i915: Do not handle backlight combination mode specially
since this commit introduced other regressions due to untouched LBPC
register, e.g. the backlight dimmed after resume.
In addition to the revert, this patch includes a fix for the original
issue (weird backlight levels) by removing the wrong bit shift for
computing the current backlight level.
Also, including typo fixes (lpbc -> lbpc).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524
Acked-by: Indan Zupancic <indan@nul.nu>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| |\ \
| | |
| | |
| | |
| | | |
* git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog:
watchdog: sbc_fitpc2_wdt, fix crash on systems without DMI_BOARD_NAME
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some systems don't provide DMI_BOARD_NAME in their DMI tables. Avoid
crash in such situations in fitpc2_wdt_init.
The fix is to check if the dmi_get_system_info return value is NULL.
The oops:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<ffffffff81253ae6>] strstr+0x26/0xa0
PGD 3966e067 PUD 39605067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map
CPU 1
Modules linked in: ...
Pid: 1748, comm: modprobe Not tainted 2.6.37-22-default #1 /Bochs
RIP: 0010:[<ffffffff81253ae6>] [<ffffffff81253ae6>] strstr+0x26/0xa0
RSP: 0018:ffff88003ad73f18 EFLAGS: 00010206
RAX: 0000000000000000 RBX: 00000000ffffffed RCX: 00000000ffffffff
RDX: ffffffffa003f4cc RSI: ffffffffa003f4c2 RDI: 0000000000000000
...
CR2: 0000000000000000 CR3: 000000003b7ac000 CR4: 00000000000006e0
...
Process modprobe (pid: 1748, threadinfo ffff88003ad72000, task ffff88002e6365c0)
Stack: ...
Call Trace:
[<ffffffffa004201f>] fitpc2_wdt_init+0x1f/0x13c [sbc_fitpc2_wdt]
[<ffffffff810002da>] do_one_initcall+0x3a/0x170
...
Code: f3 c3 0f 1f 00 80 3e 00 53 48 89 f8 74 1b 48 89 f2 0f 1f 40 00 48 83 c2 01 80 3a 00 75 f7 49 89 d0 48 89 f8 49 29 f0 75 02 5b c3 <80> 3f 00 74 0e 0f 1f 44 00 00 48 83 c0 01 80 38 00 75 f7 49 89
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* 'for-2639-rc7/i2c-fixes' of git://git.fluff.org/bjdooks/linux:
i2c-eg20t: include slab.h for memory allocations
i2c-ocores: Fix pointer type mismatch error
i2c-omap: Program I2C_WE on OMAP4 to enable i2c wakeup
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes (with v2.6.38-rc3/parisc/parisc-allmodconfig):
src/drivers/i2c/busses/i2c-eg20t.c:720: error: implicit declaration of function 'kzalloc'
src/drivers/i2c/busses/i2c-eg20t.c:790: error: implicit declaration of function 'kfree'
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
ocores_i2c_of_probe needs to use a const __be32 type for handing
device tree property values. This patch fixed the following build
warning:
CC drivers/i2c/busses/i2c-ocores.o
drivers/i2c/busses/i2c-ocores.c: In function 'ocores_i2c_of_probe':
drivers/i2c/busses/i2c-ocores.c:254: warning: assignment discards qualifiers from pointer target type
drivers/i2c/busses/i2c-ocores.c:261: warning: assignment discards qualifiers from pointer target type
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: linux-i2c@vger.kernel.org
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
For the I2C module to be wakeup capable, programming I2C_WE register (which
was skipped for OMAP4430) is needed even on OMAP4.
This fixes i2c controller timeouts which were seen recently with the static
dependency being cleared between MPU and L4PER clockdomains.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[ben-linux@fluff.org: re-flowed description]
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
mmc: fix CONFIG_MMC_UNSAFE_RESUME regression
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
30201e7f3 ("mmc: skip detection of nonremovable cards on rescan")
allowed skipping detection of nonremovable cards on mmc_rescan().
The intention was to only skip detection of hardwired cards that
cannot be removed, so make sure this is indeed the case by directly
checking for (lack of) MMC_CAP_NONREMOVABLE, instead of using
mmc_card_is_removable(), which is overloaded with
CONFIG_MMC_UNSAFE_RESUME semantics.
The user-visible symptom of the bug this patch fixes is that no
"mmc: card XXXX removed" message appears in dmesg when a card is
removed and CONFIG_MMC_UNSAFE_RESUME=y.
Reported-and-tested-by: Dmitry Shmidt <dimitrysh@google.com>
Reported-and-tested-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm:
davinci: cpufreq: fix section mismatch warning
DaVinci: fix compilation warnings in <mach/clkdev.h>
davinci: tnetv107x: fix register indexing for GPIOs numbers > 31
davinci: da8xx/omap-l1x: add platform device for davinci-pcm-audio
ARM: pxa/tosa: register wm9712 codec device
ARM: pxa: enable pxa-pcm-audio on pxa210/pxa25x platform
ARM: pxa/colibri: don't register pxa2xx-pcmcia nodes on non-colibri platforms
ARM: pxa/tosa: drop setting LED trigger name, as it's unsupported now
ARM: 6762/1: Update number of VIC for S5P6442 and S5PC100
ARM: 6761/1: Update number of VIC for S5PV210
ARM: 6768/1: hw_breakpoint: ensure debug logic is powered up on v7 cores
ARM: 6767/1: ptrace: fix register indexing in GETHBPREGS request
ARM: 6765/1: remove obsolete comment from asm/mach/arch.h
ARM: 6757/1: fix tlb.h induced linux/swap.h build failure
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
PXA supports multi-machine kernels since long ago. However a kernel
compiled with support for colibri and any other PXA machine and with
PCMCIA enabled will barf at runtime about duplicate registration of
pxa2xx-pcmcia device. Fix that.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
mmc: sdio: Allow sdio operations in other threads during sdio_add_func()
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This fixes a bug introduced by 807e8e40673d ("mmc: Fix sd/sdio/mmc
initialization frequency retries") that prevented SDIO drivers from
performing SDIO commands in their probe routines -- the above patch
called mmc_claim_host() before sdio_add_func(), which causes a deadlock
if an external SDIO driver calls sdio_claim_host().
Fix tested on an OLPC XO-1.75 with libertas on SDIO.
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Reviewed-and-Tested-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
|
| |\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm: index i shadowed in 2nd loop
drm/nv50-nvc0: prevent multiple vm/bar flushes occuring simultanenously
drm/nouveau: fix regression causing ttm to not be able to evict vram
drm/i915: Rebind the buffer if its alignment constraints changes with tiling
drm/i915: Disable GPU semaphores by default
drm/i915: Do not overflow the MMADDR write FIFO
Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Index i was already used in thhe first loop
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* ickle/drm-intel-fixes:
drm/i915: Rebind the buffer if its alignment constraints changes with tiling
drm/i915: Disable GPU semaphores by default
drm/i915: Do not overflow the MMADDR write FIFO
Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Early gen3 and gen2 chipset do not have the relaxed per-surface tiling
constraints of the later chipsets, so we need to check that the GTT
alignment is correct for the new tiling. If it is not, we need to
rebind.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Andi Kleen narrowed his GPU hangs on his Sugar Bay (SNB desktop) rev 09
down to the use of GPU semaphores, and we already know that they appear
broken up to Huron River (mobile) rev 08. (I'm optimistic that disabling
GPU semaphores is simply hiding another bug by the latency and
side-effects of the additional device interaction it introduces...)
However, use of semaphores is a massive performance improvement... Only
as long as the system remains stable. Enable at your peril.
Reported-by: Andi Kleen <andi-fd@firstfloor.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33921
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Whilst the GT is powered down (rc6), writes to MMADDR are placed in a
FIFO by the System Agent. This is a limited resource, only 64 entries, of
which 20 are reserved for Display and PCH writes, and so we must take
care not to queue up too many writes. To avoid this, there is counter
which we can poll to ensure there are sufficient free entries in the
fifo.
"Issuing a write to a full FIFO is not supported; at worst it could
result in corruption or a system hang."
Reported-and-Tested-by: Matt Turner <mattst88@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34056
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This reverts commit c2e0eb167070a6e9dcb49c84c13c79a30d672431.
As it turns out, userspace already depends upon being able to enable
tiling on existing bo which it promises to be large enough for its
purposes i.e. it will not access beyond the end of the last full-tile
row.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35016
Reported-and-tested-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The per-vm mutex doesn't prevent this completely, a flush coming from the
BAR VM could potentially happen at the same time as one for the channel
VM. Not to mention that if/when we get per-client/channel VM, this will
happen far more frequently.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| | | |_|/ /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
TTM assumes an error condition from man->func->get_node() means that
something went horribly wrong, and causes it to bail.
The driver is supposed to return 0, and leave mm_node == NULL to
signal that it couldn't allocate any memory.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:
[S390] tape: deadlock on system work queue
[S390] keyboard: integer underflow bug
[S390] xpram: remove __initdata attribute from module parameters
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The 34xx and 3590 tape driver uses the system work queue to defer work
from the interrupt function to process context, e.g. a medium sense
after an unsolicited interrupt. The tape commands started by the work
handler need to be asynchronous, otherwise a deadlock on the system
work queue can occur.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The "ct" variable should be an unsigned int. Both struct kbdiacrs
->kb_cnt and struct kbd_data ->accent_table_size are unsigned ints.
Making it signed causes a problem in KBDIACRUC because the user could
set the signed bit and cause a buffer overflow.
Cc: <stable@kernel.org>
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The module parameter 'devs' and 'sizes' are marked as __initdata. The
memory for the parameters are freed after module_init completed. This
can lead to kernel crashes in param_free_charp. Remove the __initdata
attribute to fix the problem.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
| | |/ / / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If a virtio-console device gets unplugged while a port is open, a
subsequent close() call on the port accesses vqs to free up buffers.
This can lead to a crash.
The buffers are already freed up as a result of the call to
unplug_ports() from virtcons_remove(). The fix is to simply not access
vq information if port->portdev is NULL.
Reported-by: juzhang <juzhang@redhat.com>
CC: stable@kernel.org
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This driver causes hard lockups, when the active clock soure is jiffies.
The reason is that it loops with interrupts disabled waiting for a
timestamp to be reached by polling getnstimeofday(). Though with a
jiffies clocksource, when that code runs on the same CPU which is
responsible for updating jiffies, then we loop in circles for ever
simply because the timer interrupt cannot update jiffies. So both UP
and SMP can be affected.
There is no easy fix for that problem so make it depend on BROKEN for
now.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Alexander Gordeev <lasaine@lvk.cs.msu.su>
Cc: Rodolfo Giometti <giometti@linux.it>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The device table is required to load modules based on modaliases.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Shubhrajyoti D <shubhrajyoti@ti.com>
Cc: Christoph Mair <christoph.mair@gmail.com>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fix s3c_rtc_setaie() prototype to eliminate the following compile
warning:
drivers/rtc/rtc-s3c.c:383: warning: initialization from incompatible pointer type
(akpm: the rtc_class_ops.alarm_irq_enable() handler is being passed two
arguments where it expects just one, presumably with undesired effects)
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The nv30/nv40 3d driver is about to start using DMA_FENCE from the 3D
object which, it turns out, doesn't like its DMA object to not be
aligned to a 4KiB boundary.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
