DM04/QQBOX USB Timing change.

Improved timing to avoid USB corruptions on some systems.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Improved frontend handling.

Frontend now remains open at all times, with signal lock, snr & signal level
polled from Interupt.

Updated driver for DM04/QQBOX USB DVB-S BOXES to version 1.70.
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

If you suspend and resume during video capture, the video colours
are corrupted on resume. This is because the sensor is being unconditionally
powered off during the resume path.

Only power down during resume if the camera is not in use, and correctly
reconfigure the sensor during resume.
Fixes http://dev.laptop.org/ticket/10190Signed-off-by: NDaniel Drake <dsd@laptop.org>
Acked-by: NJonathan Corbet <corbet@lwn.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Converted if (debug >= 2) printk(KERN_DEBUG... to if debug >= 2) dprintk(...)
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Although cx231xx has a very good IR support, already supported by
mceusb driver, some designs decided to add a separate I2C
microcontroller chip in order to handle IR.

Due to that, add a glue to ir-kbd-i2c is needed, in order to support
those devices.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

By comparing the traffic between Pixelview (cx23102-based and Kworld
(saa7134-based), the only difference is at register 0xd5. After some
tests, It seems that it is used to change mode between serial and parallel.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This adds the trivial bits to mb86a20s. As the driver won't touch
at the channel/layer parameters, this may not be enough for
receiving all channels, especially ISDB-Tsb, but the driver worked
properly for receiving video channels on my tests.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This device uses an em2874B + Sharp 921 One Seg frontend.
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

On our tests with Leadership ISDBT, the s921 frontend were not work. As its
design contained some weird things, it ended to be easier to just re-write
it, getting another frontend as an example (cx24123).

As the old s921 driver weren't used, there's no regression. Some info from
the old frontend were used as a way to double check the behavior that were
noticed on the USB dumps retrieved from Leadership driver.
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The current code mis-calculates the ramoops header size, leading to an
overflow over the next record at best, or over a non-allocated region at
worst.  Fix that calculation.
Signed-off-by: NAhmed S. Darwish <darwish.07@gmail.com>
Acked-by: NMarco Stornelli <marco.stornelli@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

LCDC hardware can support 1920x1080 formats, adjust the driver to cover them.
Besides, instead of guessing some "reasonable" validity checks, only verify
values in .fb_check_var(), that we are sure, we cannot support.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

MX27 and MX25 have 10 bits in the YMAX field of LCDC Size Register.

Fix the maximum value for yres.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

We don't need or want MSR usage here, on x86-64.
x86-64 was disabled intentionally in Kconfig, but commit
9272dcc2 changed that.

drivers/ata/pata_cs5536.c:47:1: warning: "rdmsr" redefined
In file included from arch/x86/include/asm/irqflags.h:60,
                 from include/linux/irqflags.h:15,
                 from arch/x86/include/asm/system.h:11,
                 from arch/x86/include/asm/processor.h:17,
                 from include/linux/prefetch.h:14,
                 from include/linux/list.h:7,
                 from include/linux/module.h:9,
                 from drivers/ata/pata_cs5536.c:33:
arch/x86/include/asm/paravirt.h:146:1: warning: this is the location of the previous definition
drivers/ata/pata_cs5536.c:48:1: warning: "wrmsr" redefined
arch/x86/include/asm/paravirt.h:154:1: warning: this is the location of the previous definition
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

GPEs with corresponding _Lxx/_Exx control methods need to be disabled
during initialization in case they have been enabled by the BIOS, so
that they don't fire up until they are enabled by acpi_update_gpes().

References: https://bugzilla.kernel.org/show_bug.cgi?id=25412Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLen Brown <len.brown@intel.com>

Joel Soete reported oopses during pppoe over sundance NIC, caused by
a bug in skb allocation and dma mapping code, where skb_reserve()
bytes weren't taken into account. As a followup to the patch:
"sundance: Fix oopses with corrupted skb_shared_info" very similar
code is fixed here for three other drivers.
Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
Cc: Joel Soete <soete.joel@scarlet.be>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Joel Soete reported oopses at the beginning of pppoe connections since
v2.6.35. After debugging the bug was found in sundance skb allocation
and dma mapping code, where skb_reserve() bytes aren't taken into
account. This is an old bug, only uncovered by some change in 2.6.35.

Initial debugging patch by: Eric Dumazet <eric.dumazet@gmail.com>
Reported-by: NJoel Soete <soete.joel@scarlet.be>
Tested-by: NJoel Soete <soete.joel@scarlet.be>
Signed-off-by: NJarek Poplawski <jarkao2@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A recent patch has introduced a regression, whereby a second open of an
soc-camera video device breaks the running capture. This patch fixes this bug
by guaranteeing, that video buffers get initialised only during the first open
of the device node.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This reverts commit 3138b32d.

as it caused a crash upon battery removal:
https://bugzilla.kernel.org/show_bug.cgi?id=25302Signed-off-by: NLen Brown <len.brown@intel.com>

Low level drivers may behave differently depending on the current
link->lpm_policy.  During ata_eh_set_lpm(), DIPM enable commands are
issued after the successful completion of ap->ops->set_lpm(), which
means that the controller is already in the target state.  This causes
DIPM enable commands to be processed with mismatching controller power
state and link->lpm_policy value.

In ahci, link->lpm_policy is used to ignore certain PHY events if LPM
is enabled; however, as DIPM commands are issued with stale
link->lpm_policy, they sometimes end up triggering these conditions
and get aborted leading to LPM configuration failure.

Fix it by updating link->lpm_policy before issuing DIPM enable
commands.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NKyle McMartin <kyle@mcmartin.ca>
Cc: stable@kernel.org
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

ata_qc_complete() contains special handling for certain commands.  For
example, it schedules EH for device revalidation after certain
configurations are changed.  These shouldn't be applied to EH
commands but they were.

In most cases, it doesn't cause an actual problem because EH doesn't
issue any command which would trigger special handling; however, ACPI
can issue such commands via _GTF which can cause weird interactions.

Restructure ata_qc_complete() such that EH commands are always passed
on to __ata_qc_complete().

stable: Please apply to -stable only after 2.6.38 is released.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NKyle McMartin <kyle@mcmartin.ca>
Cc: stable@kernel.org
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Found by this build-error if BMDMA is disabled:

drivers/ata/pata_mpc52xx.c: In function 'mpc52xx_ata_init_one':
drivers/ata/pata_mpc52xx.c:662: error: 'ata_bmdma_interrupt' undeclared (first use in this function)
...

Move the Kconfig entry to the proper location as needed since
9a7780c9 (libata-sff: make BMDMA optional)
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

pata_cs5536 does work on the other platforms(e.g. Loongson, a MIPS
variant), so, remove the dependency of X86_32 and fix the building
errors under the other platforms via only reserving the X86_32 specific
parts for X86_32.

pata_amd also supports cs5536 IDE controller, but this one saves about
33k for the compressed kernel image(vmlinuz for MIPS).
Signed-off-by: NZhang Le <r0bertz@gentoo.org>
Signed-off-by: NChen Jie <chenj@lemote.com>
Signed-off-by: NWu Zhangjin <wuzhangjin@gmail.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

While separating out BMDMA irq handler from SFF, commit c3b28894
(libata-sff: separate out BMDMA irq handler) incorrectly made
__ata_sff_port_intr() consider an IRQ to be an idle one if the host
state was transitioned to HSM_ST_ERR by ata_bmdma_port_intr().

This makes BMDMA drivers ignore IRQs reporting host bus error which
leads to timeouts instead of triggering EH immediately.  Fix it by
making __ata_sff_port_intr() consider the IRQ to be an idle one iff
the state is HSM_ST_IDLE.  This is equivalent to adding HSM_ST_ERR to
the "break"ing case but less error-prone.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NAntonio Toma <antonio.toma@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Presently the root node is initialized by way of kzalloc on the parent
data structure, which by chance happens to do the bulk of what an
explicit initialization does with GFP_NOWAIT semantics. This however is
more by luck than by design, and as we ideally want to permit radix node
allocations access to the emergency pools anyways, add in the proper
initializer with the desired mask.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Or else we can't operate on the right address when the trans length
is greater than 65535.
Signed-off-by: NMingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

The user must read N bytes of SPIRF (1 <= N <= 4) that do not exceed the
amount of data in the receive FIFO, so read the SPIRF byte by byte when
the data in receive FIFO is less than 4 bytes.

On Simics, when read N bytes that exceed the amount of data in receive
FIFO, we can't read the data out, that is we can't clear the rx FIFO,
then the CPU will loop on the espi rx interrupt.
Signed-off-by: NMingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

If we are registering an i2c device that has a device tree node like
this real-world example:

      rtc@68 {
        compatible = "dallas,ds1337";
        reg = <0x68>;
      };

of_i2c_register_devices() will try to load a module called ds1337.ko.
There is no such module, so it will fail.  If we look in modules.alias
we will find entries like these:

.
.
.
alias i2c:ds1339 rtc_ds1307
alias i2c:ds1338 rtc_ds1307
alias i2c:ds1337 rtc_ds1307
alias i2c:ds1307 rtc_ds1307
alias i2c:ds1374 rtc_ds1374
.
.
.

The module we want is really called rtc_ds1307.ko.  If we request a
module called "i2c:ds1337", the userspace module loader will do the
right thing (unless it is busybox) and load rtc_ds1307.ko.  So we add
the I2C_MODULE_PREFIX to the request_module() string.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

On my system with a radeon x2, the first GPU was not overlapping vesa
but the test decided it was.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NMichel Dänzer <michel@daenzer.net>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

The default for non-READ_BACK GPIO regs is to have the clear bits set;
this means that our original errata fix was too simplistic.  This
changes it to the following behavior:

 - when setting GPIOs, ignore the higher order bits (they're for
   clearing, we don't need to care about them).

 - when clearing GPIOs, keep all the bits, but unset (via XOR) the
   lower order bit that negates the clear bit that we care about.  That
   is, if we're clearing GPIO 26 (val = 0x04000000), we first XOR what's
   currently in the register with 0x0400 (GPIO 26's SET bit), and then
   OR that with the GPIO 26's CLEAR bit.
Tested-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The edge detect status GPIOs function differently from the other atomic
model CS5536 GPIO registers; writing 1 to the high bits clears the GPIO,
but writing 1 to the lower bits also clears the bit.

This means that read-modify-write doesn't actually work for it, so don't
apply the errata here.  If a negative edge status gets lost after
resume..  well, we tried our best!
Tested-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If pcie_ports_disabled is set, pcie_port_service_register() returns
error code and select_detection_mode() should not attempt to
unregister dummy_driver and use dummy_slots.  It should return
PCIEHP_DETECT_ACPI immediately instead.
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Acked-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The original code returns 0 on success and 1 on failure.  In fact, at
this point, "ret" is already either zero or a negative error code so
we can just return it directly.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This was fixed by David Lamparter in v2.6.36-rc5 34860089 ("spi: free
children in spi_unregister_master, not siblings") and broken again in
v2.6.37-rc1~2^2~4 during the merge of 2b9603a0 ("spi: enable
spi_board_info to be registered after spi_master").
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NDavid Lamparter <equinox@diac24.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>