There are still lots of 80-columns warnings and a few errors
at some tables, but changing them would require more work and
with probably not much gain.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The macro is defined as:
#define CHK_ERROR(s) if( (status = s)<0 ) break
This sucks, as makes harder to debug if something got wrong and
there are more than one level of loops. Also, violates CodingStyle.
Fixed by this simple perl script:
while (<>) { $f.=$_; };
$f=~ s,\n\#define CHK_ERROR[^\n]+\n,\n,;
$f=~ s=(CHK_ERROR\(.*\,)\n\s+=\1 =g;
$f=~ s=(CHK_ERROR\(.*\,)\n\s+=\1 =g;
$f=~ s=(CHK_ERROR\(.*\,)\n\s+=\1 =g;
$f=~ s=(CHK_ERROR\(.*)\s+(\,)\n\s+=\1\2 =g;
$f=~ s=(CHK_ERROR\(.*)\s+(\,)\n\s+=\1\2 =g;
$f=~ s=(CHK_ERROR\(.*)\s+(\,)\n\s+=\1\2 =g;
$f=~ s,\n(\t+)CHK_ERROR\((.*)\)\;,\n\1status = \2;\n\1if (status < 0)\n\1\tbreak;,g;
print $f;
Plus a few manual adjustments
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This file is big. It has 12000+ lines! Most of the defined stuff aren't
used anyware inside the driver, so we can just remove most of the lines
and still keep everything that have any interest for the driver.
If anyone ever need the other devices, it will be stored at git logs, so
it is easy to recover.
The diff result is impressive:
1 files changed, 1013 insertions(+), 12694 deletions(-)
rewrite drivers/media/dvb/frontends/drxd_map_firm.h (90%)
As a sideback effect, drxd driver will likely compile faster, and
checkpatch.pl can run on this file without taking (literally) hours.
The code cleanup was done using this small script:
$ for i in `perl -ne 'print "$1\n" if (m/define\s+([^\s+]+)/)' drxd_map_firm.h`; do if [ "`grep $i drivers/media/dvb/frontends/drxd*.[ch]`" != "" ] ; then echo $i; fi; done|sort|uniq >used_symbols
$ grep -f used_symbols drxd_map_firm.h >defines
And then deleting the old #define lines, replacing by "defines" file content.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Take a first cleanup pass over the sources to bring them closer to the
Linux coding style.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for the PCTV 330e remote control
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove the flag indicating the 330e board is not validated, based on the half
dozen users who have reported today that everything is working.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Abstract out the firmware for the drx-d so that it can be loaded by the
request_firmware() interface.
The firmware licensing permits free redistribution, and can be found here:
http://kernellabs.com/firmware/drxd
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add the calls necessary to use the new drx-d driver for the PCTV 330e
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Given how PCTV has multiple products with the same model name, include the
model number in the description and #define to make it a little more clear.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The em28xx bridge strobes the reset pin on the drx-d on every ts_ctrl call.
This results in the state of the chip getting out of the sync with the
state of the driver (and hence all tuning requests after the first one fail).
Make sure the drx-d is not being held in reset, but don't actually perform a
hardware reset on the chip.
The GPIO block has been split out from the other HVR-9x0 variants to reduce
the risk of regression, although in theory they would not have any issues
since none of those cases have the frontend driver managing any internal
state.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If the tuner is not actually behind an i2c gate, using the i2c gate control
function can wedge the i2c bus. Provide the ability to control on a per-board
basis whether it should be used.
Problem was noticed on the HVR-900 R2, where it resulted in the first tuning
attempt succeeding, and then all subsequent attempts to access the xc3028
being treated as failures (including the call to sleep the tuner).
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Provide the ability for the board configuration to specify whether to insert
the RS byte into the TS interconnect to the bridge, while not required for
the ngene in fact is required for the em28xx.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add the drxd to the Makefile and Kconfig
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
These are the original drx-d sources, extracted from Ralph Metzler's GPL'd
ngene driver. No modifications/cleanup have yet been made. In fact, no
measures have been taken to see if the code even compiles.
Signed-off-by Ralph Metzler <rjkm@metzlerbros.de>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The default for "verbose" is 0. Update description to match.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Acked-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
pci_setup_device() has saved the PCI revision in the pci_dev
struct since Linux 2.6.23. Use it.
Cc: Auke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Brazil uses 6MHz-spaced channels. So, the nyquist filter for
DVB-C should be different, otherwise, inter-channel interference
may badly affect the device, and signal may not be properly decoded.
On my tests here, without this patch, sometimes channels are seen,
but, most of the time, PID filter returns with timeout.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix issue where firmware does not release on cold reset.
Also, default firmware never cold resets in multi tuner
environment.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'devicetree/merge' of git://git.secretlab.ca/git/linux-2.6:
drivercore: revert addition of of_match to struct device
of: fix race when matching drivers
Commit b826291c, "drivercore/dt: add a match table pointer to struct
device" added an of_match pointer to struct device to cache the
of_match_table entry discovered at driver match time. This was unsafe
because matching is not an atomic operation with probing a driver. If
two or more drivers are attempted to be matched to a driver at the
same time, then the cached matching entry pointer could get
overwritten.
This patch reverts the of_match cache pointer and reworks all users to
call of_match_device() directly instead.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
block: don't delay blk_run_queue_async
scsi: remove performance regression due to async queue run
blk-throttle: Use task_subsys_state() to determine a task's blkio_cgroup
block: rescan partitions on invalidated devices on -ENOMEDIA too
cdrom: always check_disk_change() on open
block: unexport DISK_EVENT_MEDIA_CHANGE for legacy/fringe drivers
Adding the necessary MODULE_DEVICE_TABLE() information allows the driver
to be automatically loaded by udev.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Shreshtha Kumar SAHU <shreshthakumar.sahu@stericsson.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>
Fix switch initialization to ensure that all switches have default routing
disabled. This guarantees that no unexpected RapidIO packets arrive to
the default port set by reset and there is no default routing destination
until it is properly configured by software.
This update also unifies handling of unmapped destinations by tsi57x, IDT
Gen1 and IDT Gen2 switches.
Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Li Yang <leoli@freescale.com>
Cc: Thomas Moll <thomas.moll@sysgo.com>
Cc: <stable@kernel.org> [2.6.37+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit c21e6beb removed our queue request_fn re-enter
protection, and defaulted to always running the queues from
kblockd to be safe. This was a known potential slow down,
but should be safe.
Unfortunately this is causing big performance regressions for
some, so we need to improve this logic. Looking into the details
of the re-enter, the real issue is on requeue of requests.
Requeue of requests upon seeing a BUSY condition from the device
ends up re-running the queue, causing traces like this:
scsi_request_fn()
scsi_dispatch_cmd()
scsi_queue_insert()
__scsi_queue_insert()
scsi_run_queue()
scsi_request_fn()
...
potentially causing the issue we want to avoid. So special
case the requeue re-run of the queue, but improve it to offload
the entire run of local queue and starved queue from a single
workqueue callback. This is a lot better than potentially
kicking off a workqueue run for each device seen.
This also fixes the issue of the local device going into recursion,
since the above mentioned commit never moved that queue run out
of line.
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
Revert "mmc: fix a race between card-detect rescan and clock-gate work instances"
During pci remove/rescan testing found:
pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
pci 0000:c0:03.0: bridge window [io 0x1000-0x0fff]
pci 0000:c0:03.0: bridge window [mem 0xf0000000-0xf00fffff]
pci 0000:c0:03.0: bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
pci 0000:c0:03.0: device not available (can't reserve [io 0x1000-0x0fff])
pci 0000:c0:03.0: Error enabling bridge (-22), continuing
pci 0000:c0:03.0: enabling bus mastering
pci 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: device not available (can't reserve [io 0x1000-0x0fff])
pcieport: probe of 0000:c0:03.0 failed with error -22
This bug was caused by commit c8adf9a3e8 ("PCI: pre-allocate
additional resources to devices only after successful allocation of
essential resources.")
After that commit, pci_hotplug_io_size is changed to additional_io_size
from minium size. So it will not go through resource_size(res) != 0
path, and will not be reset.
The root cause is: pci_bridge_check_ranges will set RESOURCE_IO flag for
pci bridge, and later if children do not need IO resource. those bridge
resources will not need to be allocated. but flags is still there.
that will confuse the the pci_enable_bridges later.
related code:
static void assign_requested_resources_sorted(struct resource_list *head,
struct resource_list_x *fail_head)
{
struct resource *res;
struct resource_list *list;
int idx;
for (list = head->next; list; list = list->next) {
res = list->res;
idx = res - &list->dev->resource[0];
if (resource_size(res) && pci_assign_resource(list->dev, idx)) {
...
reset_resource(res);
}
}
}
At last, We have to clear the flags in pbus_size_mem/io when requested
size == 0 and !add_head. becasue this case it will not go through
adjust_resources_sorted().
Just make size1 = size0 when !add_head. it will make flags get cleared.
At the same time when requested size == 0, add_size != 0, will still
have in head and add_list. because we do not clear the flags for it.
After this, we will get right result:
pci 0000:c0:03.0: PCI bridge to [bus c4-c9]
pci 0000:c0:03.0: bridge window [io disabled]
pci 0000:c0:03.0: bridge window [mem 0xf0000000-0xf00fffff]
pci 0000:c0:03.0: bridge window [mem 0xfc180000000-0xfc197ffffff 64bit pref]
pci 0000:c0:03.0: enabling bus mastering
pci 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: setting latency timer to 64
pcieport 0000:c0:03.0: irq 160 for MSI/MSI-X
pcieport 0000:c0:03.0: Signaling PME through PCIe PME interrupt
pci 0000:c4:00.0: Signaling PME through PCIe PME interrupt
pcie_pme 0000:c0:03.0:pcie01: service driver pcie_pme loaded
aer 0000:c0:03.0:pcie02: service driver aer loaded
pciehp 0000:c0:03.0:pcie04: Hotplug Controller:
v3: more simple fix. also fix one typo in pbus_size_mem
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
During initialization of vmxnet3, the state of LRO
gets out of sync with netdev->features.
This leads to very poor TCP performance in a IP forwarding
setup and is hitting many VMware users.
Simplified call sequence:
1. vmxnet3_declare_features() initializes "adapter->lro" to true.
2. The kernel automatically disables LRO if IP forwarding is enabled,
so vmxnet3_set_flags() gets called. This also updates netdev->features.
3. Now vmxnet3_setup_driver_shared() is called. "adapter->lro" is still
set to true and LRO gets enabled again, even though
netdev->features shows it's disabled.
Fix it by updating "adapter->lro", too.
The private vmxnet3 adapter flags are scheduled for removal
in net-next, see commit a0d2730c95
"net: vmxnet3: convert to hw_features".
Patch applies to 2.6.37 / 2.6.38 and 2.6.39-rc6.
Please CC: comments.
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 747df2258b ('sfc: Always map MCDI
shared memory as uncacheable') introduced a separate mapping for the
MCDI shared memory (MC_TREG_SMEM). This means we can no longer easily
include it in the register dump. Since it is not particularly useful
in debugging, substitute a recognisable dummy value.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.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: Take lock around probes for drm_fb_helper_hotplug_event
drm/i915: Revert i915.semaphore=1 default from 47ae63e0
vga_switcheroo: don't toggle-switch devices
drm/radeon/kms: add some evergreen/ni safe regs
drm/radeon/kms: fix extended lvds info parsing
drm/radeon/kms: fix tiling reg on fusion
We need to hold the dev->mode_config.mutex whilst detecting the output
status. But we also need to drop it for the call into
drm_fb_helper_single_fb_probe(), which indirectly acquires the lock when
attaching the fbcon.
Failure to do so exposes a race with normal output probing. Detected by
adding some warnings that the mutex is held to the backend detect routines:
[ 17.772456] WARNING: at drivers/gpu/drm/i915/intel_crt.c:471 intel_crt_detect+0x3e/0x373 [i915]()
[ 17.772458] Hardware name: Latitude E6400
[ 17.772460] Modules linked in: ....
[ 17.772582] Pid: 11, comm: kworker/0:1 Tainted: G W 2.6.38.4-custom.2 #8
[ 17.772584] Call Trace:
[ 17.772591] [<ffffffff81046af5>] ? warn_slowpath_common+0x78/0x8c
[ 17.772603] [<ffffffffa03f3e5c>] ? intel_crt_detect+0x3e/0x373 [i915]
[ 17.772612] [<ffffffffa0355d49>] ? drm_helper_probe_single_connector_modes+0xbf/0x2af [drm_kms_helper]
[ 17.772619] [<ffffffffa03534d5>] ? drm_fb_helper_probe_connector_modes+0x39/0x4d [drm_kms_helper]
[ 17.772625] [<ffffffffa0354760>] ? drm_fb_helper_hotplug_event+0xa5/0xc3 [drm_kms_helper]
[ 17.772633] [<ffffffffa035577f>] ? output_poll_execute+0x146/0x17c [drm_kms_helper]
[ 17.772638] [<ffffffff81193c01>] ? cfq_init_queue+0x247/0x345
[ 17.772644] [<ffffffffa0355639>] ? output_poll_execute+0x0/0x17c [drm_kms_helper]
[ 17.772648] [<ffffffff8105b540>] ? process_one_work+0x193/0x28e
[ 17.772652] [<ffffffff8105c6bc>] ? worker_thread+0xef/0x172
[ 17.772655] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772658] [<ffffffff8105c5cd>] ? worker_thread+0x0/0x172
[ 17.772663] [<ffffffff8105f767>] ? kthread+0x7a/0x82
[ 17.772668] [<ffffffff8100a724>] ? kernel_thread_helper+0x4/0x10
[ 17.772671] [<ffffffff8105f6ed>] ? kthread+0x0/0x82
[ 17.772674] [<ffffffff8100a720>] ? kernel_thread_helper+0x0/0x10
Reported-by: Frederik Himpe <fhimpe@telenet.be>
References: https://bugs.freedesktop.org/show_bug.cgi?id=36394
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
My Q67 / i7-2600 box has rev09 Sandy Bridge graphics. It hangs
instantly when GNOME loads and it hangs so hard the reset button
doesn't work. Setting i915.semaphore=0 fixes it.
Semaphores were disabled in a1656b9090
in 2.6.38 and were re-enabled by
commit 47ae63e0c2
Merge: c59a333467cffb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Mar 7 12:32:44 2011 +0000
Merge branch 'drm-intel-fixes' into drm-intel-next
Apply the trivial conflicting regression fixes, but keep GPU semaphores
enabled.
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_gem_execbuffer.c
(It's worth noting that the offending change is i915_drv.c,
which is not a conflict.)
Signed-off-by: Andy Lutomirski <luto@mit.edu>
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the requested device is already active, ignore the request.
This restores the original behaviour of the interface. The change was
probably an unintended side effect of
commit 66b37c6777 vga_switcheroo: split switching into two stages
which did not take into account to duplicate the !active check in the split-off
stage2.
Fix this by factoring that check out of stage1 into the debugfs_write routine.
References: https://bugzilla.kernel.org/show_bug.cgi?id=34252
Reported-by: Igor Murzov <e-mail@date.by>
Tested-by: Igor Murzov <e-mail@date.by>
Signed-off-by: Florian Mickler <florian@mickler.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 270dac35c2.
The commits causes command timeouts on AC plug/unplug. It isn't yet
clear why. As the commit was for a single rather obscure controller,
revert the change for now.
The problem was reported and bisected by Gu Rui in bug#34692.
https://bugzilla.kernel.org/show_bug.cgi?id=34692
Also, reported by Rafael and Michael in the following thread.
http://thread.gmane.org/gmane.linux.kernel/1138771
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Gu Rui <chaos.proton@gmail.com>
Reported-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Michael Leun <lkml20100708@newton.leun.net>
Cc: Jian Peng <jipeng2005@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This moves the
if (num_registered_fb == FB_MAX)
return -ENXIO;
check _AFTER_ the call to do_remove_conflicting_framebuffers() as this
would (now in a safe way) allow a native driver to replace the
conflicting one even if all slots in registered_fb[] are taken.
This also prevents unregistering a framebuffer that is no longer
registered (vga16f will unregister at module unload time even if the
frame buffer had been unregistered earlier due to being found
conflicting).
Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When a register_framebuffer() call results in us removing old
conflicting framebuffers, the new registration_lock doesn't protect that
situation. And we can't just add the same locking to the function,
because these functions call each other: register_framebuffer() calls
remove_conflicting_framebuffers, which in turn calls
unregister_framebuffer for any conflicting entry.
In order to fix it, this just creates wrapper functions around all three
functions and makes the versions that actually do the work be called
"do_xxx()", leaving just the wrapper that gets the lock and calls the
worker function.
So the rule becomes simply that "do_xxxx()" has to be called with the
lock held, and now do_register_framebuffer() can just call
do_remove_conflicting_framebuffers(), and that in turn can call
_do_unregister_framebuffer(), and there is no deadlock, and we can hold
the registration lock over the whole sequence, fixing the races.
It also makes error cases simpler, and fixes one situation where we
would return from unregister_framebuffer() without releasing the lock,
pointed out by Bruno Prémont.
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Tested-by: Anca Emanuel <anca.emanuel@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
