cx88 only depends on VIDEO_IR because it needs ir_extract_bits().
Move that function to ir-core.h and make it inline.
Lots of drivers had dependencies on VIDEO_IR when they really
wanted IR_CORE.
The only remaining drivers to depend on VIDEO_IR are bt8xx and
saa7134 (ir_rc5_timer_end is the only function exported by
ir-functions).
Rename VIDEO_IR -> IR_LEGACY to give a hint to anyone writing or
converting drivers to IR_CORE that they do not want a dependency
on IR_LEGACY.
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch removes the remaining usages of the ir_input_nokey() and
ir_input_keydown() functions provided by drivers/media/IR/ir-functions.c
by using the corresponding functionality in ir-core instead.
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch converts the cx88 driver (for sampling hw) to use the
decoders provided by ir-core instead of the separate ones provided
by ir-functions (and gets rid of those).
The value for MO_DDS_IO had a comment saying it corresponded to
a 4kHz samplerate. That comment was unfortunately misleading. The
actual samplerate was something like 3250Hz.
The current value has been derived by analyzing the elapsed time
between interrupts for different values (knowing that each interrupt
corresponds to 32 samples).
Thanks to Mariusz Bialonczyk <manio@skyboo.net> for testing my patches
(about one a day for two weeks!) on actual hardware.
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert the driver to use regulator framework instead of set_power callback.
This with gpio_reset platform data provide cleaner way to manage chip VIO,
VDD and reset signal inside the driver.
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Cc: Eduardo Valentin <eduardo.valentin@nokia.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Because some clients (e.g. tvtime) will just open the filehandle and call
read() instead of explicitly calling streamon first, we need to make sure the
VBI timeout routine gets enabled in this case.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The first pass of fixes to cause the driver to continue streaming even when
there is no video arriving over the ITU656 bus were not adequate. Continue
the work from the previous patch.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We need the au0828 to continue delivering frames even when the device is not
delivering video, or else applications such as tvtime will block indefinitely.
Unfortunately, the au8522 doesn't have any sort of free-running mode or "blue
screen on no video" like some other decoders.
This work was sponsored by GetWellNetwork Inc.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Tweak the comb filter config when in s-video mode to match the Hauppauge
Windows driver values (based on register dumps).
This work was sponsored by GetWellNetwork Inc.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Straighten out the clamp control configurations for the various video modes,
based off of register diffs done against the Hauppauge Windows driver.
This work was sponsored by GetWellNetwork Inc.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Cleanup the routine which disables the audio decoder. In particular, the i2s
output was being shut off but the audio processor itself was not, resulting
in more power being consumed than needed.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix the alignment of fields being delivered by the driver, which was
resulting in jerky video when there was horizontal motion (since the bottom
field of the frame was being sent with the top field of the previous frame)
This work was sponsored by GetWellNetwork Inc.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We had the max packets per URB set to an incredibly low "10" as opposed to
the Windows driver which has it as 128. Set the value to match the
Windows driver, which will reduce interrupts considerably.
This work was sponsored by GetWellNetwork Inc.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The chip's default value for the brightness didn't match what we were sending
back in the queryctrl ioctl(), so if the application actually set the
brightness to the "default", it would actually end up being way too bright.
This work was sponsored by GetWellNetwork Inc.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bad value prevented the autogain to work correctly
and some images were truncated.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Generate a release button event when the button is still pressed when the
stream stops.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
gspca_xirlink_cit: Add support camera button
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
At least on the ibm netcam pro frames have a 4 byte footer, take this
into account when calculating sizeimage.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following usb bandwidth allocation changes were made to the ibm netcam
pro code:
- Don't restart negotiation at max packet size on stop0, as that gets called
by gspca_main during negotiation. Move this to sd_isoc_init.
- Don't ask for full bandwidth when running at 160x120, that does not need
full bandwidth
- Make minimum acceptable bandwidth depend upon resolution
[mchehab@redhat.com: Fix CodingStyle problems at switch statements]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently alloc_and_submit_int_urb() is setting gspca->int_urb
as soon as the allocation has succeeded, but if the subsequent
submit fails, the urb gets destroyed. And then later will
get destroyed again in gspca_input_destroy_urb() because
gspca->int_urb is set, leading to a double free.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently gspca supported usb-1.1 webcams for which we support the input
button through an interrupt endpoint won't stream (not enough bandwidth
error) when used through an USB-2.0 hub.
After much debugging I've found out that the cause for this is that the
ehci-sched.c schedeling code does not like it when there are already urb's
scheduled when (large) isoc urbs are queued. By moving the submission
of the interrupt urbs to after submitting the isoc urbs the camera
starts working again through usb-2.0 hubs.
Note that this does not fix isoc. streaming through a usb-hub while another
1.1 usb device (like the microphone of the same cam) is also active
at the same time :(
I've spend a long time analyzing the linux kernel ehci scheduler code,
resulting in this (long) mail:
http://www.spinics.net/lists/linux-usb/msg37982.html
The conclusion of the following mail thread is that yes there are several
issues when using usb-1.1 devices through a usb-2.0 hub, but these are not
easily fixable in the current code. Fixing this in ehci-sched.c requires
an almost full rewrite, which is not bound to happen anytime soon.
So with this patch gspca driven usb-1.1 webcams will atleast work when
connected through an usb-2.0 hub when the microphone is not used.
As an added bonus this patch avoids extra destroy/create input urb cycles
when we end up falling back to a lower speed alt setting because of bandwidth
limitations.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
DM04/QQBOX USB Timing change.
Improved timing to avoid USB corruptions on some systems.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro 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: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro 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/10190
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro 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: Mauro 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: Mauro 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: Mauro Carvalho Chehab <mchehab@redhat.com>
This device uses an em2874B + Sharp 921 One Seg frontend.
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro 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: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro 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: Ahmed S. Darwish <darwish.07@gmail.com>
Acked-by: Marco Stornelli <marco.stornelli@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'fbdev-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6:
fbdev: sh_mobile_lcdc: increase maximum framebuffer size to support 1080p
video: imxfb: Fix the maximum value for yres
fb: fix overlapping test off-by-one.
fbdev: sh-mobile: retrieve and propagate display sizes from EDID
fbdev: sh-mobile: restore display size configuration
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: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul 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: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Paul 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
9272dcc232 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: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Jeff 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=25412
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (42 commits)
ipv4: dont create routes on down devices
epic100: hamachi: yellowfin: Fix skb allocation size
sundance: Fix oopses with corrupted skb_shared_info
Revert "ipv4: Allow configuring subnets as local addresses"
USB: mcs7830: return negative if auto negotiate fails
irda: prevent integer underflow in IRLMP_ENUMDEVICES
tcp: fix listening_get_next()
atl1c: Do not use legacy PCI power management
mac80211: fix mesh forwarding
MAINTAINERS: email address change
net: Fix range checks in tcf_valid_offset().
net_sched: sch_sfq: fix allot handling
hostap: remove netif_stop_queue from init
mac80211/rt2x00: add ieee80211_tx_status_ni()
typhoon: memory corruption in typhoon_get_drvinfo()
net: Add USB PID for new MOSCHIP USB ethernet controller MCS7832 variant
net_sched: always clone skbs
ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed.
netlink: fix gcc -Wconversion compilation warning
asix: add USB ID for Logitec LAN-GTJ U2A
...
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: Jarek Poplawski <jarkao2@gmail.com>
Cc: Joel Soete <soete.joel@scarlet.be>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David 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: Joel Soete <soete.joel@scarlet.be>
Tested-by: Joel Soete <soete.joel@scarlet.be>
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David 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: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'merge' of git://git.secretlab.ca/git/linux-2.6:
spi/mpc52xx-spi: fix annotation for remove()-pointer
spi/fsl_espi: fix wrong setting of the address in the command buffer
spi/fsl_espi: change the read behaviour of the SPIRF
of/i2c: Fix request module by alias
powerpc/mpc5200: include fs.h in mpc52xx_gpt.c
* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
libata: issue DIPM enable commands with LPM state updated
libata: no special completion processing for EH commands
pata_mpc52xx: driver needs BMDMA
pata_cs5536: Add support for non-X86_32 platforms
libata-sff: fix HSM_ST_ERR handling in __ata_sff_port_intr()
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
[SCSI] fix up documentation for change in ->queuecommand to lockless calling
[SCSI] bfa: rename log_level to bfa_log_level
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: Tejun Heo <tj@kernel.org>
Reported-by: Kyle McMartin <kyle@mcmartin.ca>
Cc: stable@kernel.org
Signed-off-by: Jeff 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: Tejun Heo <tj@kernel.org>
Reported-by: Kyle McMartin <kyle@mcmartin.ca>
Cc: stable@kernel.org
Signed-off-by: Jeff 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
9a7780c9ac (libata-sff: make BMDMA optional)
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jeff 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: Zhang Le <r0bertz@gentoo.org>
Signed-off-by: Chen Jie <chenj@lemote.com>
Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
Signed-off-by: Jeff 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: Tejun Heo <tj@kernel.org>
Reported-by: Antonio Toma <antonio.toma@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Jeff 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: Paul Mundt <lethal@linux-sh.org>
Or else we can't operate on the right address when the trans length
is greater than 65535.
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: Grant 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: Mingkai Hu <Mingkai.hu@freescale.com>
Signed-off-by: Grant 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: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Grant 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: Dave Airlie <airlied@redhat.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (21 commits)
[media] mceusb: set a default rx timeout
[media] mceusb: fix inverted mask inversion logic
[media] mceusb: add another Fintek device ID
[media] lirc_dev: fixes in lirc_dev_fop_read()
[media] lirc_dev: stray unlock in lirc_dev_fop_poll()
[media] rc: fix sysfs entry for mceusb and streamzap
[media] streamzap: merge timeout space with trailing space
[media] mceusb: fix keybouce issue after parser simplification
[media] IR: add tv power scancode to rc6 mce keymap
[media] mceusb: buffer parsing fixups for 1st-gen device
[media] mceusb: fix up reporting of trailing space
[media] nuvoton-cir: improve buffer parsing responsiveness
[media] mceusb: add support for Conexant Hybrid TV RDU253S
[media] s5p-fimc: Fix output DMA handling in S5PV310 IP revisions
[media] s5p-fimc: Use correct fourcc code for 32-bit RGB format
[media] s5p-fimc: Convert m2m driver to unlocked_ioctl
[media] s5p-fimc: Explicitly add required header file
[media] s5p-fimc: Fix vidioc_g_crop/cropcap on camera sensor
[media] s5p-fimc: BKL lock removal - compilation fix
[media] soc-camera: fix static build of the sh_mobile_csi2.c driver
...
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: Daniel Drake <dsd@laptop.org>
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Linus 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: Daniel Drake <dsd@laptop.org>
Signed-off-by: Andres Salomon <dilinger@queued.net>
Signed-off-by: Linus 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: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Acked-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse 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: Dan Carpenter <error27@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm: Include the connector name in the output_poll_execute() debug message
drm/radeon/kms: fix bug in r600_gpu_is_lockup
drm/radeon/kms: reorder display resume to avoid problems
drm/radeon/kms/evergreen: reset the grbm blocks at resume and init
drm/radeon/kms: fix evergreen asic reset
Revert "drm: Don't try and disable an encoder that was never enabled"
drm/radeon: Add early unregister of firmware fb's
drm/radeon: use aperture size not vram size for overlap tests
drm/radeon/kms/evergreen: flush hdp cache when flushing gart tlb
drm/radeon/kms: disable the r600 cb offset checker for linear surfaces
drm/radeon/kms: disable ss fixed ref divide
drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
agp/intel: Fix missed cached memory flags setting in i965_write_entry()
drm/i915/sdvo: Only use the SDVO pin if it is in the valid range
drm/i915/ringbuffer: Handle wrapping of the autoreported HEAD
drm/i915/dp: Fix I2C/EDID handling with active DisplayPort to DVI converter
This was fixed by David Lamparter in v2.6.36-rc5 3486008 ("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: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: David Lamparter <equinox@diac24.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When I added led_blink_set I had a typo: the return value of the hw
offload is a regular error code that is zero when succesful, and in that
case software emulation should not be used, rather than the other way
around.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: Richard Purdie <rpurdie@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Thomas Hellstrom <thomas@tungstengraphics.com>
Cc: Alan Hourihane <alanh@tungstengraphics.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>
Match the buffer size to the amount of initialized values. Before, it was
one too big and thus destroyed the neighbouring register causing the clock
to run at false speeds.
Reported-by: Andre van Rooyen <a.v.rooyen@sercom.nl>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If GPIO request succeeds, but configuration fails, it should be released.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
Acked-by: Eric Miao <eric.miao@canonical.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The atl1c driver uses the legacy PCI power management, so it has to
do some PCI-specific things in its ->suspend() and ->resume()
callbacks and they are not done correctly.
Convert atl1c to the new PCI power management framework and make it
let the PCI subsystem handle all of the PCI-specific aspects of
device handling during system power transitions.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some newer device revisions add a second parent ID. Support this in
the device validity checks done at startup.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
We want to find the first set bit on value, not status.
Signed-off-by: Mattias Wallin <mattias.wallin@stericsson.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Without this the IRQ base will not be correctly configured for the
subdevices.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
rdc321x-wdt currently fetches its driver specific data by using the
platform_device->platform_data pointer, this is wrong because the mfd
device which registers our platform_device has been added using
mfd_add_device() which sets the platform_device->driver_data pointer
instead.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
CC: stable@kernel.org
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
rdc321x-gpio currently fetches its driver specific data by using the
platform_device->platform_data pointer, this is wrong because the mfd
device which registers our platform_device has been added using
mfd_add_device() which sets the platform_device->driver_data pointer
instead.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
CC: stable@kernel.org
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Monitor EDID contains information about physical display sizes. Retrieve
it and propagate to the framebuffer driver.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
An earlier patch replaced open-coded video-mode configuration from
platform data by a call to fb_videomode_to_var(), thereby setting
ofdisplay sizes have been accidentally lost. Restore them.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Always useful to know just which connector was polled and had its
status updated.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We were using the lockup struct from the wrong union.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the error-path where PM notifies PM_POST_RESTORE, the rescan-blockage
should be cleared as well. Otherwise it'll be never re-probed.
Also, as a bonus, this fixes a bug in S4 with user-mode suspend in the
current code, as it sends PM_POST_RESTORE instead of
PM_POST_HIBERNATION wrongly.
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Based on report made by Yauhen in:
"MMC: Fix multiblock SDIO transfers in AT91 MCI" patch,
I report those changes to the brother driver: atmel-mci.
So, this patch sets SDIO transfer types: SDIO block and SDIO byte
transfers instead of using ordinary MMC block transfers.
It is checking opcode for SDIO CMD53 and setting transfer
type in MCI_CMDR register properly.
Reported-by: Yauhen Kharuzhy <yauhen.kharuzhy@promwad.com>
Cc: <stable@kernel.org>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The AT91 MCI has special SDIO transfer types: SDIO block and SDIO byte
transfers, but at91_mci driver doesn't use them and handles all SDIO
transfers as ordinary MMC block transfers. This causes problems for
multiple-block SDIO transfers (in particular for 256-bytes blocks).
Fix this situation by checking the opcode for SDIO CMD53 and setting
the transfer type in the AT91_MCI_CMDR register properly.
This patch was tested with libertas SDIO driver: problem with TX
timeouts on big packets was eliminated.
Signed-off-by: Yauhen Kharuzhy <yauhen.kharuzhy@promwad.com>
Cc: <stable@kernel.org>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
* 'tty-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6:
n_gsm: gsm_data_alloc buffer allocation could fail and it is not being checked
n_gsm: Fix message length handling when building header
* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
Revert "USB: gadget: Allow function access to device ID data during bind()"
USB: misc: uss720.c: add another vendor/product ID
USB: usb-storage: unusual_devs entry for the Samsung YP-CP3
USB: gadget: Remove suspended sysfs file before freeing cdev
USB: core: Add input prompt and help text for USB_OTG config
USB: ftdi_sio: Add D.O.Tec PID
xhci: Fix issue with port array setup and buggy hosts.
On resume, we were attemping to unblank the displays before the
timing and plls had be reprogrammed which led to atom timeouts
waiting for things that are not yet programmed. Re-program
the mode first, then reset the dpms state.
This fixes the infamous atombios timeouts on resume.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes module reloading and resume as the gfx block seems to
be left in a bad state in some cases.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Only reset the grbm blocks, srbm tends to lock the GPU
if not done properly and in most cases is not necessary.
Also, no need to call asic init after reset the grbm blocks.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 541cc96691.
Wei Yonjun reported this caused a regression against Intel VGA hotplug
on his G33 hw.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Without this, we attempt the handover too late, the firmware fb
might be accessing the chip simultaneously to us re-initializing
various parts of it, which might frighten babies or cause all sort
of nasty psychologic trauma to kitten.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
[danvet: add cc: stable, forward ported and compile-fixed for X86]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[airlied: move to even earlier in module load.]
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fix runtime warning with backtrace from hostap by removing
netif_stop_queue() call before register_netdev. Tested to work fine on
hostap_pci Prism 2.5.
(This removes a warning about calling netif_stop_queue before
register_netdev is called. -- JWL)
Signed-off-by: Meelis Roos <mroos@linux.ee>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
All rt2x00 drivers except rt2800pci call ieee80211_tx_status() from
a workqueue, which causes "NOHZ: local_softirq_pending 08" messages.
To fix it, add ieee80211_tx_status_ni() similar to ieee80211_rx_ni()
which can be called from process context, and call it from
rt2x00lib_txdone(). For the rt2800pci special case a driver
flag is introduced.
https://bugzilla.kernel.org/show_bug.cgi?id=24892
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
info->version only has space for 32 characters but my UTS_RELEASE is
"2.6.37-rc6-next-20101217-05817-ge935fc8-dirty" so it doesn't fit.
This is supposed to be the version of the driver, not the kernel
version. This driver doesn't have a version so lets just leave it
blank.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Due to active notification of the new MCS7832 version by the manufacturer
(Mr. Milton; thanks!) -- quote: "functionality same as MCS7830",
I'm now submitting this patch (on -rc6), intended for networking.git and -stable.
- add MCS7832 USB PID to be able to support this new device variant, too
- add related descriptions
Signed-off-by: Andreas Mohr <andi@lisas.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6:
[media] gspca - sonixj: Better handling of the bridge registers 0x01 and 0x17
[media] gspca - sonixj: Add the bit definitions of the bridge reg 0x01 and 0x17
[media] gspca - sonixj: Set the flag for some devices
[media] gspca - sonixj: Add a flag in the driver_info table
[media] gspca - sonixj: Fix a bad probe exchange
[media] gspca - sonixj: Move bridge init to sd start
[media] bttv: remove unneeded locking comments
[media] bttv: fix mutex use before init (BZ#24602)
[media] Don't export format_by_forcc on two different drivers
Rename log_level to bfa_log_level to make the global variable more bfa
specific and avoid clashes with other drivers which was causing a
build failure.
Signed-off-by: Jing Huang <huangj@brocade.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
* 'fbdev-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6:
OMAP: OMAPFB: disable old omapfb for OMAP4 builds
OMAP: DSS: VRAM: Align start & size of vram to 2M
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
cciss: fix cciss_revalidate panic
block: max hardware sectors limit wrapper
block: Deprecate QUEUE_FLAG_CLUSTER and use queue_limits instead
blk-throttle: Correct the placement of smp_rmb()
blk-throttle: Trim/adjust slice_end once a bio has been dispatched
block: check for proper length of iov entries earlier in blk_rq_map_user_iov()
drbd: fix for spin_lock_irqsave in endio callback
drbd: don't recvmsg with zero length
Its possible for the call to read rx timeout from the hardware to fail,
in which case we end up with a bogus rx timeout value. Set a default one
when filling in the rc struct, and we'll just overwrite it later w/the
value from hardware, but if that read fails, we've at least got a sane
rx timeout value to work with (1000ms is the default value I've seen
returned on most if not all mceusb hardware).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As it turns out, somewhere along the way, we managed to invert the
meaning of the tx_mask_inverted flag. Looking back over the old lirc
driver, tx_mask_inverted was set to 0 if the device was in tx_mask_list.
Now we have a tx_mask_inverted flag set to 1 for all the devices that
were in the list, and set tx_mask_inverted to that flag value, which is
actually the opposite of what we used to set, causing set_tx_mask to use
the wrong mask setting option. Since there seem to be more devices with
inverted masks than not (using the original device as the baseline for
inverted vs. normal), lets just call the ones currently marked as
inverted normal instead, and flip the if/else actions that key off of
the inverted flag.
Note: the problem only cropped up if a call to set_tx_mask was made, if
no mask was set, the device would work just fine, which is why this
managed to slip though w/o getting noticed until now.
Tested successfully by myself and Dennis Gilmore.
Reported-by: Dennis Gilmore <dgilmore@redhat.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This makes several changes but they're in one function and sort of
related:
"buf" was leaked on error. The leak if we try to read an invalid
length is the main concern because it could be triggered over and
over.
If the copy_to_user() failed, then the original code returned the
number of bytes remaining. read() is supposed to be the opposite way,
where we return the number of bytes copied. I changed it to just return
-EFAULT on errors.
Also I changed the debug output from "-EFAULT" to just "<fail>" because
it isn't -EFAULT necessarily. And since we go though that path if the
length is invalid now, there was another debug print that I removed.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We shouldn't unlock here. I think this was a cut and paste error.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When trying to create persistent device names for mceusb and streamzap
devices, I noticed that their respective drivers are not creating the rc
device as a child of the USB device. Rather it creates it as virtual
device. As a result, udev cannot use the USB device information to
create persistent device names for event and lirc devices associated
with the rc device. Not having persistent device names makes it more
difficult to make use of the devices in userspace as their names can
change.
Signed-off-by: Paul Bender <pebender@gmail.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are cases where we get an ending space, and our trailing timeout
space then gets sent right after it, which breaks repeat, at least for
lirc userspace decoding. Merge the two spaces by way of using
ir_raw_event_store_filter, set a timeout value, and we're back to good.
Successfully tested with streamzap and windows mce remotes.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Something I failed to notice while testing the mceusb RLE buffer
decoding simplification patches was that we were getting an extra event
from the previously pressed key.
As was pointed out to me on irc by Maxim, this is actually due to using
ir_raw_event_store_with_filter without having set up a timeout value.
The hardware has a timeout value we're now reading and storing, which
properly enables the transition to idle in the raw event storage
process, and makes IR decode behave correctly w/o keybounce.
Also remove no-longer-used ir_raw_event struct from mceusb_dev struct
and add as-yet-unused enable flags for carrier reports and learning
mode, which I'll hopefully start wiring up sooner than later. While
looking into that, found evidence that 0x9f 0x15 responses are only
non-zero when the short-range learning sensor is used, so correct the
debug spew message, and then suppress it when using the standard
long-range sensor.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If we pass in an offset, we shouldn't skip 2 bytes. And the first-gen
hardware generates a constant stream of interrupts, always with two
header bytes, and if there's been no IR, with nothing else. Bail from
ir processing without calling ir_handle_raw_event when we get such a
buffer delivered to us.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We were storing a bunch of spaces at the end of each signal, rather than
a single long space. The in-kernel decoders were actually okay with
this, but lirc isn't. As suggested by David Härdeman, switch to storing
samples using ir_raw_event_store_with_filter, which auto-merges the
consecutive space samples for us. This also allows us to bypass having
to store rawir samples in our device struct, further simplifying the
buffer parsing state machine. Both in-kernel decoders and lirc are happy
again with this change.
Also included in this patch is proper parsing of 0x9f 0x01 commands, the
removal of some magic number usage and some printk spew fixups.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rather than waiting for trigger bits, the formula for which was slightly
messy, and apparently, not actually 100% complete for some remotes, just
call ir_raw_event_handle whenever we finish parsing a chunk of data from
the rx fifo, similar to mceusb, as well as whenever we see an 'end of
signal data' 0x80 packet.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Another multi-function Conexant device. Interface 0 is IR, though on
this model, TX isn't wired up at all, so I've mixed in support for
models without TX (and verified that lircd says TX isn't supported when
trying to send w/this device).
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
FIMC IP in S5Pv310 series has extended DMA status registers
and some bit fields are marked as reserved comparing to S5PC100/110.
Use correct registers for getting DMA write pointer in each SoC variant
supported by the driver.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Replace V4L2_PIX_FMT_RGB24 code with V4L2_PIX_FMT_RGB32
since the hardware uses 24-bits for actual pixel data but pixels
are 4-byte aligned in memory.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Create separate vidioc_g_crop/vidioc_s_crop handlers for capture
video node and so image cropping parameters are properly queried
at FIMC input (image sensor) and not at FIMC output.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The test for driver->owner != NULL in sh_mobile_ceu_camera.c is unneeded and it
breaks the static build of sh_mobile_csi2.c. Remove it.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When SOCAM_PCLK_SAMPLE_FALLING, just leave CSICR1_REDGE unset, otherwise we get
the inverted behaviour.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86-32: Make sure we can map all of lowmem if we need to
x86, vt-d: Handle previous faults after enabling fault handling
x86: Enable the intr-remap fault handling after local APIC setup
x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode
x86, vt-d: Quirk for masking vtd spec errors to platform error handling logic
x86, xsave: Use alloc_bootmem_align() instead of alloc_bootmem()
bootmem: Add alloc_bootmem_align()
x86, gcc-4.6: Use gcc -m options when building vdso
x86: HPET: Chose a paranoid safe value for the ETIME check
x86: io_apic: Avoid unused variable warning when CONFIG_GENERIC_PENDING_IRQ=n
* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
perf: Fix off by one in perf_swevent_init()
perf: Fix duplicate events with multiple-pmu vs software events
ftrace: Have recordmcount honor endianness in fn_ELF_R_INFO
scripts/tags.sh: Add magic for trace-events
tracing: Fix panic when lseek() called on "trace" opened for writing
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
x86: avoid high BIOS area when allocating address space
x86: avoid E820 regions when allocating address space
x86: avoid low BIOS area when allocating address space
resources: add arch hook for preventing allocation in reserved areas
Revert "resources: support allocating space within a region from the top down"
Revert "PCI: allocate bus resources from the top down"
Revert "x86/PCI: allocate space from the end of a region, not the beginning"
Revert "x86: allocate space within a region top-down"
Revert "PCI: fix pci_bus_alloc_resource() hang, prefer positive decode"
PCI: Update MCP55 quirk to not affect non HyperTransport variants
If a device is reported as inactive or not present by its _STA
control method, acpi_bus_check_add() skips it without evaluating its
_PRW method. This leads to a problem when the device's _PRW method
points to a GPE, because in that case the GPE may be enabled by
ACPICA during the subsequent acpi_update_gpes() call which, in
turn, may cause a GPE storm to appear.
To avoid this issue, make acpi_bus_check_add() evaluate _PRW for
inactive or not present devices and register the wakeup GPE
information returned by them, so that acpi_update_gpes() does not
enable their GPEs unnecessarily.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The initial values of the registers 0x01 and 0x17 are taken from the sensor
table at capture start and updated according to the flag PDN_INV.
Their values are updated at each step of the capture initialization and
memorized for reuse in capture stop.
This patch also fixed automatically some bad hardcoded values of these
registers.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The flag PDN_INV indicates that the sensor pin S_PWR_DN has not the same
value as other webcams with the same sensor. For now, only two webcams have
been so detected: the Microsoft's VX1000 and VX3000.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After Mauro's "bttv: Fix locking issues due to BKL removal code" there
are a number of comments that are no longer needed about lock ordering.
Remove them.
Signed-off-by: Brandon Philips <bphilips@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix a regression where bttv driver causes oopses when loading, since it
were using some non-initialized mutexes. While it would be possible to
fix the issue, there are some other lock troubles, like to the presence of
lock code at free_btres_lock().
It is possible to fix, but the better is to just use the core-assisted
locking schema. This way, V4L2 core will serialize access to all
ioctl's/open/close/mmap/read/poll operations, avoiding to have two
processes accessing the hardware at the same time. Also, as there's just
one lock, instead of 3, there's no risk of dead locks.
The net result is a cleaner code, with just one lock.
Reported-by: Dan Carpenter <error27@gmail.com>
Reported-by: Brandon Philips<brandon@ifup.org>
Reported-by: Chris Clayton <chris2553@googlemail.com>
Reported-by: Torsten Kaiser <just.for.lkml@googlemail.com>
Tested-by: Chris Clayton <chris2553@googlemail.com>
Tested-by: Torsten Kaiser <just.for.lkml@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Logitec LAN-GTJ U2A (http://www.pro.logitec.co.jp/pro/g/gLAN-GTJU2A/)
USB 2.0 10/10/1000 Ethernet adapter is based on ASIX AX88178 chipset.
This patch adds missing USB ID for the device.
Signed-off-by: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
My conversion of tehuti to use request_firmware() was confused about
the filename of the firmware blob. Change the driver to match the
blob.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Mauro Carvalho Chehab