Driver advertises its support for 'retry' bit and 'conf completion' bit in PRLI
params to enable support for 'sequence level error recovery'
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Program the firmware task structure with init_flags indicating the device is
'sequence level error recovery' capable.
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Driver decides to initiate REC on REC_TOV timer pop. The firmware maintains the
REC timer and informs the driver as a firmware error message, which is an
unsolicited event to the driver. Driver also issues REC on other unsolicited
events from firmware that indicate data loss.
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
For the devices that support sequence level error recovery, based on the REC
response, the firmware has to be informed about the offset from which the
retransmission should happen. Driver initiates sequence cleanup task to
firmware so that the firmware can program the task. Upon the sequence cleanup
completion, SRR is issued to retransmit the sequence.
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
rdac hardware handler assumes that there is one-to-one relation ship
between the host and the controller w.r.t lun. IOW, it does not
support "multiple storage partitions" within a storage.
Example:
HBA1 and HBA2 see lun 0 and 1 in storage A (1)
HBA3 and HBA4 see lun 0 and 1 in storage A (2)
HBA5 and HBA6 see lun 0 and 1 in storage A (3)
luns 0 and 1 in (1), (2) and (3) are totally different.
But, rdac handler treats the lun 0s (and lun 1s) as the same when
sending a mode select to the controller, which is wrong.
This patch makes the rdac hardware handler associate HBA and the
storage w.r.t lun (and not the host itself).
Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
This patch adds the core and pkg support to coretemp.
These thresholds can be configured via the sysfs interfaces tempX_max
and tempX_max_hyst. An interrupt is generated when CPU temperature reaches
or crosses above tempX_max OR drops below tempX_max_hyst.
This patch is based on the documentation in IA Manual vol 3A, that can be
downloaded from here:
http://download.intel.com/design/processor/manuals/253668.pdf
Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
LM95231 is fully compatible to LM95241; only necessary change is to add
chip detection.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
A hwmon driver for the National Semiconductor LM95245 dual temperature
sensors chip.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Add support for Philips SA56004, an LM86 compatible temperature sensor.
Signed-off-by: Stijn Devriendt <sdevrien@cisco.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Add support for NTC Thermistor series. In this release, the
following thermistors are supported: NCP15WB473, NCP18WB473, NCP03WB473,
and NCP15WL333. This driver is based on the datasheet of MURATA.
The driver in the patch does conversion from the raw ADC value
(either voltage or resistence) to temperature. In order to use
voltage values as input, the circuit schematics should be provided
with the platform data. A compensation table for each type of thermistor
is provided for the conversion.
Signed-off-by: Donggeun Kim <dg77.kim@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: KyungMin Park <kyungmin.park@samsung.com>
Reviewed-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
MAX1668 and compatibles have several external temperature sensors, but only a
single FAULT status bit. If a fault occurs, the temperature reported on the
affected sensors is 127 degrees C. Use this knowledge to report fault on
external sensors.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
This patch adds support for MAX1668 and compatible temperature sensors.
Signed-off-by: David George <david.george@ska.ac.za>
[guenter.roeck@ericsson.com: minor cleanup of probe error path]
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
This patch fixes a bug in WRITE_SAME_16 LBA assignment where get_unaligned_be16()
is incorrectly being used instead of get_unaligned_be64() for a 64-bit LBA.
This was introduced with:
commit a1d8b49abd
Author: Andy Grover <agrover@redhat.com>
Date: Mon May 2 17:12:10 2011 -0700
target: Updates from AGrover and HCH (round 3)
(target: inline struct se_transport_task into struct se_cmd)
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
The A0 revision of this chip is the only device that requires these
features to be disabled.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The 5719 has bug where RDMAs larger than 4k can cause problems. This
patch works around the problem by dividing larger DMA requests into
something the hardware can handle.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As the driver breaks large skb fragments into smaller submissions to the
hardware, there is a new danger that BDs might get exhausted before all
fragments have been mapped. This patch adds code to make sure tx BDs
aren't oversubscribed and flag the condition if it happens.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch consolidates all code that populates tx BDs into a single
routine. Setting tx BDs needs to be more carefully controlled to see if
workarounds need to be applied.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The following patches are going to break skb fragments into smaller
sizes. This patch attempts to make the change easier to digest by only
addressing the skb teardown portion.
The patch modifies the driver to skip over any BDs that have a flag set
that indicates the BD isn't the beginning of an skb fragment. Such BDs
were a result of segmentation and do not need a pci_unmap_page() call.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the following patches, unmapping skb fragments will get just as
complicated as mapping them. This patch generalizes
tg3_skb_error_unmap() and makes it the one-stop-shop for skb unmapping.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The first fragment of an skb should always be greater than 8 bytes.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the following patches, the process the driver will use to assign skb
fragments to transmit BDs will get more complicated. To prepare for
that new code, this patch seeks to simplify how transmit BDs are
populated. It does this by separating the code that assigns the BD
members from the logic that controls how the fields are set.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The following patches will require the use of an additional flag in the
ring_info structure. The use of this flag is tx path specific, so this
patch defines a specialized ring_info structure.
Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
Reviewed-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The AX88772B uses only 11 bits of the header for the actual size. The other bits
are used for something else. This causes dmesg full of messages:
asix_rx_fixup() Bad Header Length
This patch trims the check to only 11 bits. I believe on older chips, the
remaining 5 top bits are unused.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Try to send to correct address this time!
---------- Forwarded Message ----------
Subject: [PATCH] Fix cdc-phonet build
Date: Saturday 23 Jul 2011
From: Chris Clayton <chris2553@googlemail.com>
To: linux-net@vger.kernel.org
cdc-phonet does not presently build on linux-3.0 because there is no entry for it in
drivers/net/Makefile. This patch adds that entry.
Signed-off-by: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On Tue, Jul 26, 2011 at 05:40:27PM -0700, Joe Perches wrote:
> On Tue, 2011-07-26 at 17:37 -0700, Jay Vosburgh wrote:
> > Joe Perches <joe@perches.com> wrote:
> > >I'd prefer you don't separate the format string
> > >into multiple pieces.
> > Why not? To me, it looks easier to read split into sections
> > that don't wrap lines.
>
> Harder to grep for a dmesg and the
> defect rate of these split formats is
> typically higher than single strings
> because of bad spacing between string
> segments.
>
I noticed that you took some time back in late 2009 to 'consolidate' the
split format-strings present in the bonding driver at the time and I've
decided I'm fine to leave them the way they are. The main point of my
patch was to change the output and I would like to get that included.
Here is my updated patch...
Subject: [PATCH net-next-2.6 v2] bonding: reduce noise during init
Many are using sysfs to configure bonding rather than module options, so
there is no need for bonding to throw this warning in normal cases.
Keep the message around when debugging is enabled as it might be useful
for someone desperate enough to enable debugging, but eliminate it
otherwise.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
When a bond contains a device where one name is the subset of another
(eth1 and eth10, for example), one cannot properly set the primary
device or the currently active device.
This was reported and based on work by Takuma Umeya. I also verified
the problem and tested that this fix resolves it.
V2: A few did not like the the current code or my changes, so I
refactored bonding_store_primary and bonding_store_active_slave to be a
bit cleaner, dropped the use of strnicmp since we did not really need
the comparison to be case insensitive, and formatted the input string
from sysfs so a comparison to IFNAMSIZ could be used.
I also discovered an error in bonding_store_active_slave that would
modify bond->primary_slave rather than bond->curr_active_slave before
forcing the bonding driver to choose a new active slave.
V3: Actually sending the proper patch....
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Reported-by: Takuma Umeya <tumeya@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After the last patch, We are left in a state in which only drivers calling
ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real
hardware call ether_setup for their net_devices and don't hold any state in
their skbs. There are a handful of drivers that violate this assumption of
course, and need to be fixed up. This patch identifies those drivers, and marks
them as not being able to support the safe transmission of skbs by clearning the
IFF_TX_SKB_SHARING flag in priv_flags
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Karsten Keil <isdn@linux-pingi.de>
CC: "David S. Miller" <davem@davemloft.net>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: Patrick McHardy <kaber@trash.net>
CC: Krzysztof Halasa <khc@pm.waw.pl>
CC: "John W. Linville" <linville@tuxdriver.com>
CC: Greg Kroah-Hartman <gregkh@suse.de>
CC: Marcel Holtmann <marcel@holtmann.org>
CC: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
For some reason, when rxaccel is disabled, NV_RX3_VLAN_TAG_PRESENT is
still set and some pseudorandom vids appear. So check for
NETIF_F_HW_VLAN_RX as well. Also set correctly hw_features and set vlan
mode on probe.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 87c288c6e9 "gianfar: do vlan cleanup" has two issues:
# permutation of rx and tx flags
# enabling vlan tag insertion by default (this leads to unusable connections on some configurations)
If VLAN insertion is requested (via ethtool) it will be set at an other point ...
Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
create_path() on something without a single / in it will return err
without initializing it. It actually can't happen (we call that thing
only if create on the same path returns -ENOENT, which won't happen
happen for single-component path), but in this case initializing err
to 0 is more than making compiler to STFU - would be the right thing
to return on such paths; the function creates a parent directory of
given pathname and in that case it has no work to do...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6: (54 commits)
tpm_nsc: Fix bug when loading multiple TPM drivers
tpm: Move tpm_tis_reenable_interrupts out of CONFIG_PNP block
tpm: Fix compilation warning when CONFIG_PNP is not defined
TOMOYO: Update kernel-doc.
tpm: Fix a typo
tpm_tis: Probing function for Intel iTPM bug
tpm_tis: Fix the probing for interrupts
tpm_tis: Delay ACPI S3 suspend while the TPM is busy
tpm_tis: Re-enable interrupts upon (S3) resume
tpm: Fix display of data in pubek sysfs entry
tpm_tis: Add timeouts sysfs entry
tpm: Adjust interface timeouts if they are too small
tpm: Use interface timeouts returned from the TPM
tpm_tis: Introduce durations sysfs entry
tpm: Adjust the durations if they are too small
tpm: Use durations returned from TPM
TOMOYO: Enable conditional ACL.
TOMOYO: Allow using argv[]/envp[] of execve() as conditions.
TOMOYO: Allow using executable's realpath and symlink's target as conditions.
TOMOYO: Allow using owner/group etc. of file objects as conditions.
...
Fix up trivial conflict in security/tomoyo/realpath.c
Currently when we get a read error during recovery, we simply abort
the recovery.
Instead, repeat the read in page-sized blocks.
On successful reads, write to the target.
On read errors, record a bad block on the destination,
and only if that fails do we abort the recovery.
As we now retry reads we need to know where we read from. This was in
bi_sector but that can be changed during a read attempt.
So store the correct from_addr and to_addr in the r10_bio for later
access.
Signed-off-by: NeilBrown<neilb@suse.de>
If a read error is detected during recovery the code currently
fails the read device.
This isn't really necessary. recovery_request_write will signal
a write error to end_sync_write and it will record a write
error on the destination device which will record a bad block
there or kick it from the array.
So just remove this call to do md_error.
Signed-off-by: NeilBrown <neilb@suse.de>
If we get a write error during resync/recovery don't fail the device
but instead record a bad block. If that fails we can then fail the
device.
Signed-off-by: NeilBrown <neilb@suse.de>
We already attempt to fix read errors found during normal IO
and a 'repair' process.
It is best to try to repair them at any time they are found,
so move a test so that during sync and check a read error will
be corrected by over-writing with good data.
If both (all) devices have known bad blocks in the sync section we
won't try to fix even though the bad blocks might not overlap. That
should be considered later.
Also if we hit a read error during recovery we don't try to fix it.
It would only be possible to fix if there were at least three copies
of data, which is not very common with RAID10. But it should still
be considered later.
Signed-off-by: NeilBrown <neilb@suse.de>
When we get a write error (in the data area, not in metadata),
update the badblock log rather than failing the whole device.
As the write may well be many blocks, we trying writing each
block individually and only log the ones which fail.
Signed-off-by: NeilBrown <neilb@suse.de>
If we succeed in writing to a block that was recorded as
being bad, we clear the bad-block record.
This requires some delayed handling as the bad-block-list update has
to happen in process-context.
Signed-off-by: NeilBrown <neilb@suse.de>
Writing to known bad blocks on drives that have seen a write error
is asking for trouble. So try to avoid these blocks.
Signed-off-by: NeilBrown <neilb@suse.de>
When recovering one or more devices, if all the good devices have
bad blocks we should record a bad block on the device being rebuilt.
If this fails, we need to abort the recovery.
To ensure we don't think that we aborted later than we actually did,
we need to move the check for MD_RECOVERY_INTR earlier in md_do_sync,
in particular before mddev->curr_resync is updated.
Signed-off-by: NeilBrown <neilb@suse.de>
During resync/recovery limit the size of the request to avoid
reading into a bad block that does not start at-or-before the current
read address.
Similarly if there is a bad block at this address, don't allow the
current request to extend beyond the end of that bad block.
Now that we don't ever read from known bad blocks, it is safe to allow
devices with those blocks into the array.
Signed-off-by: NeilBrown <neilb@suse.de>
When attempting to repair a read error, don't read from
devices with a known bad block.
As we are only reading PAGE_SIZE blocks, we don't try to
narrow down to smaller regions in the hope that only part of this
page is bad - it isn't worth the effort.
Signed-off-by: NeilBrown <neilb@suse.de>
When redirecting a read error to a different device, we must
again avoid bad blocks and possibly split the request.
Spin_lock typo fixed thanks to Dan Carpenter <error27@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
This patch just covers the basic read path:
1/ read_balance needs to check for badblocks, and return not only
the chosen slot, but also how many good blocks are available
there.
2/ read submission must be ready to issue multiple reads to
different devices as different bad blocks on different devices
could mean that a single large read cannot be served by any one
device, but can still be served by the array.
This requires keeping count of the number of outstanding requests
per bio. This count is stored in 'bi_phys_segments'
On read error we currently just fail the request if another target
cannot handle the whole request. Next patch refines that a bit.
Signed-off-by: NeilBrown <neilb@suse.de>
When a loop ends with a large if, it can be neater to change the
if to invert the condition and just 'continue'.
Then the body of the if can be indented to a lower level.
Signed-off-by: NeilBrown <neilb@suse.de>
On a successful write to a known bad block, flag the sh
so that raid5d can remove the known bad block from the list.
Signed-off-by: NeilBrown <neilb@suse.de>
When a write error is detected, don't mark the device as failed
immediately but rather record the fact for handle_stripe to deal with.
Handle_stripe then attempts to record a bad block. Only if that fails
does the device get marked as faulty.
Signed-off-by: NeilBrown <neilb@suse.de>
If we get an uncorrectable read error - record a bad block rather than
failing the device.
And if these errors (which may be due to known bad blocks) cause
recovery to be impossible, record a bad block on the recovering
devices, or abort the recovery.
As we might abort a recovery without failing a device we need to teach
RAID5 about recovery_disabled handling.
Signed-off-by: NeilBrown <neilb@suse.de>
There are two times that we might read in raid5:
1/ when a read request fits within a chunk on a single
working device.
In this case, if there is any bad block in the range of
the read, we simply fail the cache-bypass read and
perform the read though the stripe cache.
2/ when reading into the stripe cache. In this case we
mark as failed any device which has a bad block in that
strip (1 page wide).
Note that we will both avoid reading and avoid writing.
This is correct (as we will never read from the block, there
is no point writing), but not optimal (as writing could 'fix'
the error) - that will be addressed later.
If we have not seen any write errors on the device yet, we treat a bad
block like a recent read error. This will encourage an attempt to fix
the read error which will either generate a write error, or will
ensure good data is stored there. We don't yet forget the bad block
in that case. That comes later.
Now that we honour bad blocks when reading we can allow devices with
bad blocks into the array.
Signed-off-by: NeilBrown <neilb@suse.de>
raid1d is too big with several deep branches.
So separate them out into their own functions.
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
If we cannot read a block from anywhere during recovery, there is
now a better approach than just giving up.
We can record a bad block on each device and keep going - being
careful not to clear the bad block when a write succeeds as it might -
it will be a write of incorrect data.
We have now reached the state where - for raid1 - we only call
md_error if md_set_badblocks has failed.
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
If we find a bad block while writing as part of resync/recovery we
need to report that back to raid1d which must record the bad block,
or fail the device.
Similarly when fixing a read error, a further error should just
record a bad block if possible rather than failing the device.
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
When we get a write error (in the data area, not in metadata),
update the badblock log rather than failing the whole device.
As the write may well be many blocks, we trying writing each
block individually and only log the ones which fail.
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
When performing write-behind we allocate pages to store the data
during write.
Previously we just keep a list of pages. Now we keep a list of
bi_vec which includes offset and size.
This means that the r1bio has complete information to create a new
bio which will be needed for retrying after write errors.
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
If we succeed in writing to a block that was recorded as
being bad, we clear the bad-block record.
This requires some delayed handling as the bad-block-list update has
to happen in process-context.
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
If we have seen any write error on a drive, then don't write to
any known-bad blocks on that drive.
If necessary, we divide the write request up into pieces just
like we do for reads, so each piece is either all written or
all not written to any given drive.
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
It is only safe to choose not to write to a bad block if that bad
block is safely recorded in metadata - i.e. if it has been
'acknowledged'.
If it hasn't we need to wait for the acknowledgement.
We support that using rdev->blocked wait and
md_wait_for_blocked_rdev by introducing a new device flag
'BlockedBadBlock'.
This flag is only advisory.
It is cleared whenever we acknowledge a bad block, so that a waiter
can re-check the particular bad blocks that it is interested it.
It should be set by a caller when they find they need to wait.
This (set after test) is inherently racy, but as
md_wait_for_blocked_rdev already has a timeout, losing the race will
have minimal impact.
When we clear "Blocked" was also clear "BlockedBadBlocks" incase it
was set incorrectly (see above race).
We also modify the way we manage 'Blocked' to fit better with the new
handling of 'BlockedBadBlocks' and to make it consistent between
externally managed and internally managed metadata. This requires
that each raidXd loop checks if the metadata needs to be written and
triggers a write (md_check_recovery) if needed. Otherwise a queued
write request might cause raidXd to wait for the metadata to write,
and only that thread can write it.
Before writing metadata, we set FaultRecorded for all devices that
are Faulty, then after writing the metadata we clear Blocked for any
device for which the Fault was certainly Recorded.
The 'faulty' device flag now appears in sysfs if the device is faulty
*or* it has unacknowledged bad blocks. So user-space which does not
understand bad blocks can continue to function correctly.
User space which does, should not assume a device is faulty until it
sees the 'faulty' flag, and then sees the list of unacknowledged bad
blocks is empty.
Signed-off-by: NeilBrown <neilb@suse.de>
If a device has ever seen a write error, we will want to handle
known-bad-blocks differently.
So create an appropriate state flag and export it via sysfs.
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
When performing resync/etc, keep the size of the request
small enough that it doesn't overlap any known bad blocks.
Devices with badblocks at the start of the request are completely
excluded.
If there is nowhere to read from due to bad blocks, record
a bad block on each target device.
Now that we never read from known-bad-blocks we can allow devices with
known-bad-blocks into a RAID1.
Signed-off-by: NeilBrown <neilb@suse.de>
Now that we have a bad block list, we should not read from those
blocks.
There are several main parts to this:
1/ read_balance needs to check for bad blocks, and return not only
the chosen device, but also how many good blocks are available
there.
2/ fix_read_error needs to avoid trying to read from bad blocks.
3/ read submission must be ready to issue multiple reads to
different devices as different bad blocks on different devices
could mean that a single large read cannot be served by any one
device, but can still be served by the array.
This requires keeping count of the number of outstanding requests
per bio. This count is stored in 'bi_phys_segments'
4/ retrying a read needs to also be ready to submit a smaller read
and queue another request for the rest.
This does not yet handle bad blocks when reading to perform resync,
recovery, or check.
'md_trim_bio' will also be used for RAID10, so put it in md.c and
export it.
Signed-off-by: NeilBrown <neilb@suse.de>
Space must have been allocated when array was created.
A feature flag is set when the badblock list is non-empty, to
ensure old kernels don't load and trust the whole device.
We only update the on-disk badblocklist when it has changed.
If the badblocklist (or other metadata) is stored on a bad block, we
don't cope very well.
If metadata has no room for bad block, flag bad-blocks as disabled,
and do the same for 0.90 metadata.
Signed-off-by: NeilBrown <neilb@suse.de>
As no personality understand bad block lists yet, we must
reject any device that is known to contain bad blocks.
As the personalities get taught, these tests can be removed.
This only applies to raid1/raid5/raid10.
For linear/raid0/multipath/faulty the whole concept of bad blocks
doesn't mean anything so there is no point adding the checks.
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
This can show the log (providing it fits in one page) and
allows bad blocks to be 'acknowledged' meaning that they
have safely been recorded in metadata.
Clearing bad blocks is not allowed via sysfs (except for
code testing). A bad block can only be cleared when
a write to the block succeeds.
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
This the first step in allowing md to track bad-blocks per-device so
that we can fail individual blocks rather than the whole device.
This patch just adds a data structure for recording bad blocks, with
routines to add, remove, search the list.
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
When calling bioset_create we pass the size of the front_pad as
sizeof(mddev)
which looks suspicious as mddev is a pointer and so it looks like a
common mistake where
sizeof(*mddev)
was intended.
The size is actually correct as we want to store a pointer in the
front padding of the bios created by the bioset, so make the intent
more explicit by using
sizeof(mddev_t *)
Reported-by: Zdenek Kabelac <zdenek.kabelac@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
added new bit offset defines,
more supported BE colour formats
and also support BGR565 swapped pixel formats
removed pixfmt helper functions and option flags
setting the configuration register directly in set_pixfmt
added reg_mask function
reg_mask is basically the same as clearing & setting registers,
but it is more convenient and faster (saves one rw cycle).
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Philipp Wiesner <p.wiesner@phytec.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
[g.liakhovetski@gmx.de: remove Bayer swap, forward-port, rename macros]
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is an initial driver release for the Omnivision 5642 CMOS sensor.
Signed-off-by: Bastian Hecht <hechtb@gmail.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If vb2_dma_contig_get_userptr() fails on a videobuffer, driver's
.buf_init() method will not be called and the list will not be
initialised. Trying to remove an uninitialised element from a list leads
to a NULL-dereference.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Tested-by: Bastian Hecht <hechtb@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that v4l2 subdevices have got their own device objects, having
one more device in soc-camera clients became redundant and confusing.
This patch removes those devices and the soc-camera bus, they used to
reside on.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The soc-camera bus is now completely local again.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This moves us one more step closer to eliminating the soc-camera bus
and devices on it. Besides, as a side effect, CSI-2 runtime PM on
sh-mobile secomes finer grained now: we only have to power on the
interface, when the device nodes are open.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
soc-camera host drivers shall be implementing their PM, using standard
kernel methods, soc-camera specific hooks can die.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The pxa-camera driver doesn't need soc-camera specific PM callbacks,
switch it to using the standard PM hooks instead.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add two fields to the ISP parallel platform data to set the HS and VS
signals polarities.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The current omap3isp driver is missing regulator handling
for CSIb complex in omap34xx based devices. This patch
adds a mechanism for this to the omap3isp driver.
Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@nokia.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support to map the buffer using dma_map_single during qbuf which inturn
calls cache flush and unmap the same during dqbuf. This is done to prevent
the artifacts seen because of cache-coherency issues on OMAP4
Signed-off-by: Amber Jain <amber@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Introduce omap_vout_vrfb.c and omap_vout_vrfb.h, for all VRFB related API's,
making OMAP_VOUT driver independent from VRFB. This is required for OMAP4 DSS,
since OMAP4 doesn't have VRFB block.
Added new enum vout_rotation_type and "rotation_type" member to omapvideo_info,
this is initialized based on the arch type in omap_vout_probe. The rotation_type
var is now used to choose between vrfb and non-vrfb calls.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Rename rotation_enabled() and rotate_90_or_270() to is_rotation_enabled()
and is_rotation_90_or_270() to make them more descriptive.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Move the inline functions rotate_90_or_270(), rotation_enabled(), and
calc_rotation() from omap_vout.c to omap_voutdef.h.
Move the independent functions omap_vout_alloc_buffer() and
omap_vout_free_buffer() to omap_voutlib.c.
Remove extern identifier from function definitions in omap_voutlib.h
Add static identifier to functions that are used locally in omap_vout.c
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove GFP_DMA from the __get_free_pages() call from omap24xxcam as ZONE_DMA
is not configured on OMAP. Earlier the page allocator used to return a page
from ZONE_NORMAL even when GFP_DMA is passed and CONFIG_ZONE_DMA is disabled.
As a result of commit a197b59ae6, page allocator
returns null in such a scenario with a warning emitted to kernel log.
Signed-off-by: Amber Jain <amber@ti.com>
Acked-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove GFP_DMA from the __get_free_pages() call from omap_vout as ZONE_DMA
is not configured on OMAP. Earlier the page allocator used to return a page
from ZONE_NORMAL even when GFP_DMA is passed and CONFIG_ZONE_DMA is disabled.
As a result of commit a197b59ae6, page allocator
returns null in such a scenario with a warning emitted to kernel log.
Signed-off-by: Amber Jain <amber@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The signal state field in G_TUNER is typically scaled from 0-100%. Since we
don't know the signal level, we really would prefer the field to contain 100%
than 1/256, which in many utilities (such as v4l2-ctl) rounds to 0% even when
a signal is actually present.
This patch makes the behavior consistent with other drivers.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Make use of the signal state registers to properly populate the signal lock
registers in the cx231xx driver.
This allows applications to know whether there is a signal present even in
devices which lack a tuner (since such apps typically won't call G_TUNER if
no tuner is present).
[mchehab@redhat.com: Fix CodingStyle: don't use {} for one-line if's]
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On platforms that have CONFIG_HZ set to 100, the power ramp time effectively
ends up being 10ms. However, on those that have a higher CONFIG_HZ, the time
ends up *actually* being 5ms, which doesn't allow enough time for the hardware
to be fully powered up before attempting to address it via i2c.
Change the constant to 10ms, which is long enough for the hardware to power
up, and won't really be anymore time than it was previously on platforms
with CONFIG_HZ being 100.
Credit goes to Mauro Carvalho Chehab and Gerd Hoffmann who previously
investigated this issue.
Tested with the Hauppauge USBLive 2, with which the problem was readily
reproducible after setting CONFIG_HZ to 1000.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following patch addresses the regression introduced in the cx231xx
driver which stopped the Hauppauge USBLive2 from working.
Confirmed working by both myself and the user who reported the issue
on the KernelLabs blog (Robert DeLuca).
At some point during refactoring of the cx231xx driver, the USBLive 2 device
became broken. This patch results in the device working again.
Thanks to Robert DeLuca for sponsoring this work.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Robert DeLuca <robertdeluca@me.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The search for matching extension units fails to take account of the
current chain. In the case where you have two distinct video chains,
both containing an XU with the same GUID but different unit ids, you
will be unable to perform a mapping on the second chain because entity
on the first chain will always be found first
Fix this by only searching the current chain when performing a control
mapping. This is analogous to the search used by uvc_find_control(),
and is the correct behaviour.
Signed-off-by: Stephan Lachowsky <stephan.lachowsky@maxim-ic.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The driver reads PCI subsystem IDs from the PCI configuration registers while
they are already stored by the PCI subsystem in the 'subsystem_{vendor|device}'
fields of 'struct pci_dev'...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix the DRX-K logic that selects between DVB-C annex A and C
Fix a typo where DVB-C annex type is set via setEnvParameters, but
the driver, uses, instead, setParamParameters[2].
While here, cleans up the code, fixing a bad identation at the fallback
code for other types of firmware, and put the multiple-line comments
into the Linux CodingStyle.
Acked-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After return, we don't need any other statement to change the
function flux ;)
Reported-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The error propagation changeset c23bf4402 broke the DVB-T
code.
The legacy way for propagate errors was:
do {
status = foo_func()
if (status < 0)
break;
} while (0);
return status;
However, on a few places, it was doing:
do {
switch(foo) {
case bar:
status = foo_func()
if (status < 0)
break;
break;
}
switch(foo2) {
case bar:
status = foo_func()
if (status < 0)
break;
break;
}
...
} while (0);
return (status)
The inner error break were not working, as it were breaking only
the switch, instead of the do. The solution used were to do a
s/break/goto error/ at the inner breaks, but preserving the last
break. Onfortunately, on a few switches, the replacement were
applied also to the final break for the case statements.
Fix the broken logic, by reverting them to break, where pertinent,
in order to fix DVB-T support.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Both ngene and ddbrige calls dvb_attach once for drxk_attach.
The logic used there, and by tda18271c2dd driver is different
from similar logic on other frontends.
The right fix is to change them to use the same logic, but,
while we don't do that, we need to patch em28xx-dvb in order
to do cope with ngene/ddbridge magic.
While here, document why drxk_t_release should do nothing.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This reverts commit a3e4adf274f86b2363fedaa964297cb38526cef0.
As pointed by Andread Oberritter <obi@linuxtv.org>:
That's wrong, because the array size is DTV_MAX_COMMAND + 1.
Using the ARRAY_SIZE macro instead might reduce the confusion.
Also, changeset 3995223038 already fixed this issue.
Reported-by: Andread Oberritter <obi@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following patch adds a new control that makes it possible to set the
luma notch filter type to finetune picture quality.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch implements support for a sharpness control, using the luma
peaking filter feature of cx2388x.
[mchehab@redhat.com: use cx_andor instead of cx_write]
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add driver for TV Mixer on Samsung platforms from S5P family.
Mixer is responsible for merging images from three layers and
passing result to the output.
Drivers are using:
- v4l2 framework
- videobuf2
- runtime PM
Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add drivers for Standard Definition output (SDO) on Samsung platforms
from S5P family. The driver provides control over streaming analog TV
via Composite connector.
Driver is using:
- v4l2 framework
- runtime PM
Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The cx88 driver would force core->input to always be zero when doing the
the request_acquire(). While it wasn't actually changing the input register
in the hardware, the driver makes decision based on the current input. In
particular, it decides whether to do things like enabling the comb filter
when on a composite input but disabling it on s-video. So for example, on
the HVR-1300, using the s-video input with the MPEG encoder would end up with
the video decoder core configured as though the input type were composite.
In short, the driver state did not match the hardware state.
This patch does two things:
1. It forces the input to zero only if actually switching to DVB mode. This
prevents the input from changing when the blackbird driver opens the device.
2. Keep track of what the input was set to when switching to DVB, and reset
it back when done. This eliminates a condition where for example the user
had the analog side of the board set to capture on the s-video input, then
he used DVB for a bit, then the analog input would unexpectedly be set to
the tuner input.
This work was sponsored by Anevia S.A.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Florent Audebert <florent.audebert@anevia.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Multi Format Codec 5.1 is a hardware video coding acceleration
module found in the S5PV210 and Exynos4 Samsung SoCs. It is
capable of handling a range of video codecs and this driver
provides a V4L2 interface for video decoding and encoding.
Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Jeongtae Park <jtp.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is admittedly a bit of a hack, but if we change our timeout value
to something longer and fudge our synthesized trailing space sample
based on the initial pulse sample, rc-core decode continues to work just
fine with both rc-6 and rc-5, and now lirc userspace decode shows proper
repeats for both of those protocols as well. Also tested NEC
successfully with both decode options.
We do still need a reset timer callback using the hardware's timeout
value to make sure we actually process samples correctly, regardless of
our somewhat hacky timeout and synthesized trailer above.
This also adds a missing del_timer_sync call to the module unload path.
CC: Chris Dodge <chris@redrat.co.uk>
CC: Andrew Vincer <andrew.vincer@redrat.co.uk>
CC: Stephen Cox <scox_nz@yahoo.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Trying to cap duration before multiplying it was obviously wrong.
CC: Chris Dodge <chris@redrat.co.uk>
CC: Andrew Vincer <andrew.vincer@redrat.co.uk>
CC: Stephen Cox <scox_nz@yahoo.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We already add a trailing space, this wasn't doing anything useful, and
actually confused lirc userspace a bit. Rip it out.
CC: Chris Dodge <chris@redrat.co.uk>
CC: Andrew Vincer <andrew.vincer@redrat.co.uk>
CC: Stephen Cox <scox_nz@yahoo.com>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a custom IR protocol decoder, for the RC-6-ish protocol used by
the Microsoft Remote Keyboard, apparently developed internally at
Microsoft, and officially dubbed MCIR-2, per their March 2011 remote and
transceiver requirements and specifications document, which also touches
on this IR keyboard/mouse device.
Its a standard keyboard with embedded thumb stick mouse pointer and
mouse buttons, along with a number of media keys. The media keys are
standard RC-6, identical to the signals from the stock MCE remotes, and
will be handled as such. The keyboard and mouse signals will be decoded
and delivered to the system by an input device registered specifically
by this driver.
Successfully tested with multiple mceusb-driven transceivers, as well as
with fintek-cir and redrat3 hardware. Essentially, any raw IR hardware
with enough sampling resolution should be able to use this decoder,
nothing about it is at all receiver-hardware-specific.
This work is inspired by lirc_mod_mce:
The documentation there and code aided in understanding and decoding the
protocol, but the bulk of the code is actually borrowed more from the
existing in-kernel decoders than anything. I did recycle the keyboard
keycode table, a few defines, and some of the keyboard and mouse data
parsing bits from lirc_mod_mce though.
Special thanks to James Meyer for providing the hardware, and being
patient with me as I took forever to get around to writing this.
callback routine to ensure we don't get any stuck keys, and used
symbolic names for the keytable. Also cc'ing Florian this time, who I
believe is the original mod-mce author...
CC: Florian Demski <fdemski@users.sourceforge.net>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is useless. There is only one physical I2C-adapter.
2nd adapter was added originally due to some plans for allowing only one
demod to access bus at time. But I never implemented proper locking...
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove old code which is not used anymore since IR code is read
directly from memory nowadays.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Reported-by: Jacek M. Holeczek <jacek.m.holeczek@gmail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
That's this tuner:
The credit card sized remote more or less works if I set remote=4,
so I added the hash to get it autodetected. (`more or less' there
meaning sometimes buttons are `stuck on repeat', i.e. ir-keytable -t
keeps repeating the same scancode until i press another button.)
Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In drivers/media/dvb/frontends/drxd_hard.c::load_firmware() I see 3
small issues:
1) When the 'fw' variable goes out of scope we'll leak the memory
allocated to it by request_firmware() by neglecting to call
release_firmware().
2) After a successful request_firmware() we allocate fw->size bytes
of memory using kzalloc() only to immediately overwrite all that
memory with memcpy(), so asking for zeroed memory seems like wasted
effort - just use kmalloc().
3) In one of the error messages "no memory" lacks a space and is
written as "nomemory".
This patch fixes all 3 issues.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Microsoft's Windows Media Center specification and requirements doc from
2011.03.18 now refers to the former Power Toggle button as the Sleep
Toggle, and recommends using a new moon sleep icon for it. Its the same
key, but its apparently always been meant to put the system to sleep,
not power it off. Adjust accordingly. While we're here, lets also remove
the duplicate KEY_PLAYPAUSE entry.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Clear the cx231xx_devused variable and free dev in the error handling code,
as done in the error handling code nearby.
The semantic match that finds this problem is as follows:
// <smpl>
@r@
identifier x;
@@
kfree(x)
@@
identifier r.x;
expression E1!=0,E2,E3,E4;
statement S;
@@
(
if (<+...x...+>) S
|
if (...) { ... when != kfree(x)
when != if (...) { ... kfree(x); ... }
when != x = E3
* return E1;
}
... when != x = E2
if (...) { ... when != x = E4
kfree(x); ... return ...; }
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Free the recently allocated qcam in each case.
The semantic match that finds this problem is as follows:
// <smpl>
@r@
identifier x;
@@
kfree(x)
@@
identifier r.x;
expression E1!=0,E2,E3,E4;
statement S;
@@
(
if (<+...x...+>) S
|
if (...) { ... when != kfree(x)
when != if (...) { ... kfree(x); ... }
when != x = E3
* return E1;
}
... when != x = E2
if (...) { ... when != x = E4
kfree(x); ... return ...; }
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There were several coding style errors as reported by checkpatch.pl. This
patch should fix those errors with the single exception of the open square
bracket issue on line 45.
[mchehab@redhat.com: Fix a merge conflict]
Signed-off-by: Adam M. Dutko <dutko.adam@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If the tvp->cmd == DTV_MAX_COMMAND then we read past the end of the
array.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch, based on code by Mirek Slugen, implements support for the
Leadtek WinFast PxDVR3200 H card with XC4000 tuner (107d:6f39).
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Make sure that the 'static' keywork is at the beginning of declaration
for drivers/media/video/omap/omap_vout.c
This gets rid of warnings like
when building with -Wold-style-declaration (and/or -Wextra which also
enables it).
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Delete a couple of leftover fields whose time has passed.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Marvell camera core can support all three videobuf2 buffer modes, which
is slick, but it also requires that all three modes be built and present,
even though only one is likely to be used. This patch allows the supported
modes to be selected at configuration time, reducing the footprint of the
driver. Prior to this patch, the MMP camera driver looked like this:
mmp_camera 19092 0
videobuf2_core 15542 1 mmp_camera
videobuf2_dma_sg 3173 1 mmp_camera
videobuf2_dma_contig 2188 1 mmp_camera
videobuf2_vmalloc 1718 1 mmp_camera
videobuf2_memops 2100 3 videobuf2_dma_sg,videobuf2_dma_contig,videobuf2_vmalloc
Afterward, instead, with scatter/gather only configured:
mmp_camera 16021 0
videobuf2_core 15542 1 mmp_camera
videobuf2_dma_sg 3173 1 mmp_camera
videobuf2_memops 2100 1 videobuf2_dma_sg
The total goes from 43,813 bytes to 36,836.
The emphasis has been on simplicity and minimal #ifdef use rather than on
squeezing out every possible byte of code. For configuration, the driver
simply looks at which videobuf2 modes have been configured in and supports
them all; it's simplistic but should be good enough.
The cafe driver is set to support vmalloc and dma-contig; mmp supports only
dma-sg, since that's the only mode that really makes sense to use.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If registration does not work, we don't want to leave the sensor powered on.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Somewhere along the way the code stopped actually paying any attention to
them, and I doubt anybody has ever made use of them.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This code shows signs of having been mucked with over the last five years
or so; things were kind of mixed up. This patch reorders functions into a
more rational organization which, with luck, will facilitate making the
buffer modes selectable at configuration time. Code movement only: no
functional changes here.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This structure got passed over in the videobuf2 conversion; it has no
reason to exist now.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The third parameter of module_param is supposed to represent sysfs
file permissions. A value of "1" leads to the following:
$ ls -l /sys/module/radio_tea5764/parameters/
total 0
I am changing it to "0" to align with the other module parameters in
this driver.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Fabio Belavenuto <belavenuto@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Based on the work of John Newbigin, Davor Emard and others who contributed
on the mailing lists.
The previous 'support' for this card was a partial merge of John's changes
that, as far as I can tell, never actually got the thing working (no DVB-T,
analog tuner not initialised).
Initialise the analog tuner properly and hook up the DVB tuner and demodulator.
DVB-T and analog now work (though I can't tune every DVB channel, but I think
there's an issue with the aerial and signal boosters here that is causing
me problems).
Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If those demods are unselected, but a bridge driver requires them,
produce a runtime message, instead of missing symbols.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use a name convention for the firmware file that matches on the
current firmware namespacing. Also, add it to the firmware
download script.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The QAM standard is set using this scu_command:
SCU_RAM_COMMAND_STANDARD_QAM |
SCU_RAM_COMMAND_CMD_DEMOD_SET_PARAM
The driver implements a version that has 4 parameters, however,
Terratec H5 needs to break this into two separate commands, otherwise,
DVB-C doesn't work.
With this fix, scan is now properly working and getting the
channel list:
>>> tune to: 609000000:INVERSION_AUTO:5217000:FEC_3_4:QAM_256
>>> tuning status == 0x00
>>> tuning status == 0x07
>>> tuning status == 0x1f
0x0093 0x0026: pmt_pid 0x0758 (null) -- SporTV2 (running, scrambled)
0x0093 0x0027: pmt_pid 0x0748 (null) -- SporTV (running, scrambled)
0x0093 0x0036: pmt_pid 0x0768 (null) -- FX (running, scrambled)
0x0093 0x0052: pmt_pid 0x0788 (null) -- The History Channel (running, scrambled)
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now, it outputs:
[10927.639641] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params:
[10927.646283] drxk: 02 00 00 00 10 00 07 00 03 02 ..........
Better than ERROR -3. This happens with Terratec H5 firmware.
It adds 2 new error conditions, and something useful to track
what the heck is that.
I suspect that the scu_command is dependent on the firmware
revision.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The driver is too limited: it assumes that UIO is used only for
controlling the antenna, and that only UIO-1 is in usage. However,
from Terratec H7 driver [1], 3 UIO's can be used. In fact, it seems
that H7 needs to use all 3. So, make the code generic enough to handle
the most complex scenario. For now, only antena GPIO can be specified,
but is is easier now to add the other GPIO/UIO needs.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
DRX-K configuration is interesting when writing/testing
new devices. Add an info line showing the discovered info.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Terratec H5 doesn't require to switch mode, but generates
an error due to this logic. Also, GPIO's are board-dependent.
So, add it at the board config struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The set mode routines assume that state were changed to the
new mode, otherwise, they'll fail.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This driver is very big and complex. An error happening in the middle
of any initialization may cause the frontend to not work. So, it
needs to properly propagate error codes internally and to userspace.
Also, printing the error codes at the places it happened helps to
discover were's a bug at the code.
Before this change, a do { } while (0) loop and lots of breaks inside
were used to propagate errors. While this works, if there are
loops inside other loops, it could be easy to forget to add another
break, causing the error to not abort the function.
Also, as not all functions were reporting errors, it is hard to
discover why something failed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On em28xx, tda18271C2 is accessible when the i2c port
is not touched. Touching on it breaks the driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
All I2C logs we got for em28xx does that. With Terratec H5, at
400MHz speed, it seems that this is required, to avoid having
troubles at the I2C bus.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The microcode firmware provided on Terratec H5 seems to be
different. Add a parameter to allow specifying a different
firmware per-device.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using #ifdef I2C_LONG_ADR for some devices, convert
it into a parameter. Terratec H5 logs from the original driver
seems to need this mode.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently, the only parameter to be configured is the I2C
address. However, Terratec H5 logs shows that it needs a different
setting for some things, and it has its own firmware.
So, move the addr into a config structure, in order to allow adding
the required configuration bits.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The normal 16-bits read routine is called as "Read16_0". This is
due to a flags that could optionally be passed. Yet, on no places
at the code, a flag is passed there.
The same happens with 16-bits write and 32-read/write routines,
and with WriteBlock.
Also, using flags, is an exception: there's no place currently using
flags, except for an #ifdef at WriteBlock.
Rename the function as just "read16", and the one that requires flags,
as "read16_flags".
This helps to see where the flags are used, and also avoid using
CamelCase on Kernel.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a complex driver. Adding support for other devices with drxk
requires to be able to debug it and see where it is failing. So, add
optional printk messages to allow debugging it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is hard to identify the origin for those errors without a
prefix to indicate which driver produced them:
[ 1390.220984] i2c_write error
[ 1390.224133] I2C Write error
[ 1391.284202] i2c_read error
[ 1392.288685] i2c_read error
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is hard to identify the origin for those errors without a
prefix to indicate which driver produced them:
[ 1390.220984] i2c_write error
[ 1390.224133] I2C Write error
[ 1391.284202] i2c_read error
[ 1392.288685] i2c_read error
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/dvb/ddbridge/built-in.o: In function `my_dvb_dmx_ts_card_init':
/home/v4l/v4l/patchwork/drivers/media/dvb/ddbridge/ddbridge-core.c:718: multiple definition of `my_dvb_dmx_ts_card_init'
drivers/media/dvb/ngene/built-in.o:/home/v4l/v4l/patchwork/drivers/media/dvb/ngene/ngene-dvb.c:227: first defined here
drivers/media/dvb/ddbridge/built-in.o: In function `my_dvb_dmxdev_ts_card_init':
/home/v4l/v4l/patchwork/drivers/media/dvb/ddbridge/ddbridge-core.c:737: multiple definition of `my_dvb_dmxdev_ts_card_init'
drivers/media/dvb/ngene/built-in.o:/home/v4l/v4l/patchwork/drivers/media/dvb/ngene/ngene-dvb.c:246: first defined here
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix compilation of ngene/ddbridge for DVB_CXD2099=n.
Note: Bug was introduced by commit 'cxd2099: Update to latest version'.
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Driver support for Digital Devices ddbridge-based cards:
Octopus, Octopus mini, Octopus LE, cineS2(v6)
with DuoFlex S2 and/or DuoFlex CT tuners.
Driver was taken from ddbridge-0.6.1.tar.bz2.
Signed-off-by: Ralph Metzler <rmetzler@digitaldevices.de>
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The CHK_ERROR macro does a flow control, violating chapter 12
of the Documentation/CodingStyle. Doing flow controls inside
macros is a bad idea, as it hides what's happening. It also
hides the var "status" with is also a bad idea.
The changes were done by this small perl script:
my $blk=0;
while (<>) {
s/^\s+// if ($blk);
$f =~ s/\s+$// if ($blk && /^\(/);
$blk = 1 if (!m/\#/ && m/CHK_ERROR/);
$blk=0 if ($blk && m/\;/);
s/\n/ / if ($blk);
$f.=$_;
};
$f=~ s,\n(\t+)CHK_ERROR\((.*)\)\;([^\n]*),\n\1status = \2;\3\n\1if (status < 0)\n\1\tbreak;,g;
print $f;
And manually fixed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
One of the problems of the old CHECK_ERROR is that it was hiding
the status parameter. Maybe due to that, on a few places, the return
code might lead to return incorrect status:
drivers/media/dvb/frontends/drxk_hard.c: In function ‘load_microcode.clone.0’:
drivers/media/dvb/frontends/drxk_hard.c:1281: warning: ‘status’ may be used uninitialized in this function
drivers/media/dvb/frontends/drxk_hard.c:1281: note: ‘status’ was declared here
drivers/media/dvb/frontends/drxk_hard.c: In function ‘GetLockStatus’:
drivers/media/dvb/frontends/drxk_hard.c:1792: warning: ‘status’ may be used uninitialized in this function
drivers/media/dvb/frontends/drxk_hard.c: In function ‘Start.clone.7’:
drivers/media/dvb/frontends/drxk_hard.c:1734: warning: ‘status’ may be used uninitialized in this function
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/dvb/frontends/drxk_hard.c: In function ‘SetDVBT’:
drivers/media/dvb/frontends/drxk_hard.c:3766: warning: enumeration value ‘BANDWIDTH_5_MHZ’ not handled in switch
drivers/media/dvb/frontends/drxk_hard.c:3766: warning: enumeration value ‘BANDWIDTH_10_MHZ’ not handled in switch
drivers/media/dvb/frontends/drxk_hard.c:3766: warning: enumeration value ‘BANDWIDTH_1_712_MHZ’ not handled in switch
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The CHK_ERROR macro does a flow control, violating chapter 12
of the Documentation/CodingStyle. Doing flow controls inside
macros is a bad idea, as it hides what's happening. It also
hides the var "status" with is also a bad idea.
The changes were done by this small perl script:
my $blk=0;
while (<>) {
s/^\s+// if ($blk);
$f =~ s/\s+$// if ($blk && /^\(/);
$blk = 1 if (!m/\#/ && m/CHK_ERROR/);
$blk=0 if ($blk && m/\;/);
s/\n/ / if ($blk);
$f.=$_;
};
$f=~ s,\n(\t+)CHK_ERROR\((.*)\)\;([^\n]*),\n\1status = \2;\3\n\1if (status < 0)\n\1\tbreak;,g;
print $f;
And manually fixed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The CHK_ERROR macro does a flow control, violating chapter 12
of the Documentation/CodingStyle. Doing flow controls inside
macros is a bad idea, as it hides what's happening. It also
hides the var "status" with is also a bad idea.
The changes were done by this small perl script:
my $blk=0;
while (<>) {
s /^\s+// if ($blk);
$f =~ s/\s+$// if ($blk && /^\(/);
$blk = 1 if (!m/\#/ && m/CHK_ERROR/);
$blk=0 if ($blk && m/\;/);
s/\n/ / if ($blk);
$f.=$_;
};
$f=~ s,\n(\t+)CHK_ERROR\((.*)\)\;([^\n]*),\n\1status = \2;\3\n\1if (status < 0)\n\1\tbreak;,g;
print $f;
And manually fixed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
/home/v4l/v4l/patchwork/drivers/media/dvb/frontends/drxk_hard.c:181: multiple definition of `MulDiv32'
drivers/media/dvb/frontends/drxd.o:/home/v4l/v4l/patchwork/drivers/media/dvb/frontends/drxd_hard.c:236: first defined here
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As the CI requires a continuous data stream, the driver inserts dummy
packets when necessary. Do not pass these packets to userspace anymore.
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Support DuoFlex CT with Digital Devices CineS2 and Mystique SaTiX-S2.
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix return code if no demux was found (cineS2_probe).
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Support Digital Devices DuoFlex CT with ngene.
Signed-off-by: Ralph Metzler <rmetzler@digitaldevices.de>
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Deleted all unused symbold from drxk_map.h,
which reduced the size from 1.1M to 37K!
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Driver for the DRX-K DVB-C/T demodulator.
Signed-off-by: Ralph Metzler <rjkm@metzlerbros.de>
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Driver for the NXP TDA18271c2 silicon tuner.
Signed-off-by: Ralph Metzler <rjkm@metzlerbros.de>
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for the codec controls to the v4l2 control framework.
[mchehab@redhat.com: Fix merge conflicts and removed some hunks that were
adding blank lines without a good reason]
Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds the driver for the adp1653 LED flash controller. This
controller supports a high power led in flash and torch modes and an
indicator light, sometimes also called privacy light.
The adp1653 is used on the Nokia N900.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Tuukka Toivonen <tuukkat76@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: David Cohen <dacohen@gmail.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add a control class and a set of controls to support LED and Xenon flash
devices. An example of such a device is the adp1653.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
By default no control events are sent to the application that caused the
control value or flags change (i.e. the control(s) passed to VIDIOC_S_CTRL
or VIDIOC_S_EXT_CTRLS). But if a change in one control causes a change in
another control that was not part of the control(s) in VIDIOC_S_CTRL or
S_EXT_CTRLS, then the application should be notified.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The new values were never copied to userspace due to this copy and paste
error. This was introduced during the rewrite of this part of the code in
commit 3219f8a362640b7e4b7e2187b1094c4e46d85aa0.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove unused pwc-ioctl.h (the copy in include/media is used everywhere)
Remove almost empty pwc-uncompress.h, move single define to pwc.h
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This makes the API for this:
1) v4l2 spec compliant
2) match that of the UVC Logitech QuickCam Sphere models
For now this operates in parellel to the sysfs interface for this, but the
intend is to deprecate the sysfs interface and remove it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Also remove all the converting from native range to 0-65535 and back
that was going on. This is no longer needed now that we no longer support
v4l1.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Allow multiple opens of the /dev/video node so that control panel apps
can be open to-gether with streaming apps.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Doing a bunch of initialization every time /dev/video is opened, and thus
for example when the udev rules probe for capabilities makes no sense,
do it at driver load, resp. stream start instead.
This is a preparation patch for allowing multiple opens of the /dev/video
node.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
as vcinterface must be set before calling pwc_camera_power()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Having 2 ways of tracking disconnection is too much, remove both and
instead simply set pdev->udev to NULL on disconnect. Also check for
pdev->udev being NULL in all possible entry paths.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Looking at the pwc buffer management code has made it clear to me it needed
some serious fixing. Not only was there a ton of code duplication even
internally to pwc (read and mmap wait for frame code was duplicated), the
code also was outright buggy. With the worst offender being dqbuf, which
just round robin returned all the mmap buffers, without paying any attention
to them being queued by the app with qbuf or not. And qbuf itself was a noop.
So I set out to fix this and already had some cleanups in place when
I read Jonathan Corbet's lwn article on videobuf2, this inspired me to just
rip out the buffer management code and replace it with videobuf2, greatly
reducing the amount of code, and fixing all bugs in one go:
Many thanks to Jonathan for the timely article on this !
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The chances if any of these becoming NULL magically are 0% And if they
do become NULL oopsing is the right thing to do (so that the user logs a
bug with the kernel rather then with whatever app he was using).
Returning EFAULT to userspace should only be done when userspace supplies
a bad address, not on driver bugs / hw issues, so in the few cases where the
check is not bogus return something else.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Just like in userspace strncpy does not guarantee 0 termination. Use strlcpy
instead which does guarantee 0 termination.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Don't issue a stream stop to the camera at the end of sd_start, this fixes
streaming with this particular model.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Based on the old v4l1 camera by Jeroen Vreeken driver which recently got
removed from the kernel.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Reset image and image_len to NULL/0 on LAST_PACKET when we're in discard
frame mode, just like we do when not discarding the current frame.
The new se401 driver uses image_len for SOF/EOF detection and thus depends on
this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the webcam 041e:405f, the LED is inverted.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The sensor of some webcams could not be detected due to timing problems
in sensor register reading. This patch adds bridge register readings
before sensor register reading.
Signed-off-by: Jean-François Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Mauro Carvalho Chehab wrote:
> I'm validating if all drivers are behaving equally with respect to the
> error codes returned to userspace, and double-checking with the API.
>
> On almost all places, -EFAULT code is used only to indicate when
> copy_from_user/copy_to_user fails. However, firedtv uses a lot of
> -EFAULT, where it seems to me that other error codes should be used
> instead (like -EIO for bus transfer errors and -EINVAL/-ERANGE for
> invalid/out of range parameters).
This concerns only the CI (CAM) related code of firedtv of which I know
little. Let's just pass through the error returns of lower level I/O
code where applicable, and -EACCES (permission denied) when a seemingly
valid but negative FCP response or an unknown-to-firedtv CA message is
received.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Henrik Kurelid <henrik@kurelid.se>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Those drivers are not relying at the V4L2 core to handle the ioctl's.
So, we need to manually patch them every time a change goes to the
core.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-By: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently, -EINVAL is used to return either when an IOCTL is not
implemented, or if the ioctl was not implemented.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When a device (or their PCI structs) are not found, the error should
be -ENODEV. -EFAULT is reserved for errors while copying arguments
from/to userspace.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
data from/to userspace. Don't mix it with I2C bus error (-EIO).
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Scatter/gather DMA mode works nicely on this platform and is clearly the
best way of doing things.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The core Marvell camera driver can now do scatter/gather DMA on controllers
which support that functionality.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Normally no control events will go to the filehandle that called the
VIDIOC_S_CTRL/VIDIOC_S_EXT_CTRLS ioctls. This is to prevent a feedback
loop.
This can now be overridden by setting the new V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK
flag.
Based on suggestions from Mauro Carvalho Chehab <mchehab@redhat.com> and
Laurent Pinchart <laurent.pinchart@ideasonboard.com>.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Split try_or_set_ext_ctrls() into a validate_ctrls() part ('Phase 1')
and merge the second part ('Phase 2') into try_set_ext_ctrls().
This makes a lot more sense and it also does the validation before
trying to try/set the controls.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The implementation of VIDIOC_G/S/TRY_EXT_CTRLS in the control framework has
to figure out which controls in the control list belong to the same cluster.
Since controls belonging to the same cluster need to be handled as a unit,
this is important information.
It did that by going over the controls in the list and for each control that
belonged to a multi-control cluster it would walk the remainder of the list
to try and find controls that belong to that same cluster.
This approach has two disadvantages:
1) it was a potentially quadratic algorithm (although highly unlikely that
it would ever be that bad in practice).
2) it took place with the control handler's lock held.
Since we want to make it possible in the future to change control values
from interrupt context, doing a lot of work while holding a lock is not a
good idea.
In the new code the algorithm is no longer quadratic but linear in the
number of controls in the list. Also, it now can be done beforehand.
Another change that was made was to so the try and set at the same time.
Before when S_TRY_EXT_CTRLS was called it would 'try' the controls first,
and then it would 'set' them. The idea was that any 'try' errors would
prevent the 'set' from happening, thus avoiding having partially set
control lists.
However, this caused more problems than it solved because between the 'try'
and the 'set' changes might have happened, so it had to try a second time,
and since actual controls with a try_ctrl op are very rare (and those that
we have just adjust values and do not return an error), I've decided to
drop that two-stage approach and just combine try and set.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When sending the SEND_INITIAL event for write-only controls the
V4L2_EVENT_CTRL_CH_VALUE flag should not be set. It's meaningless.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When the event queue for a subscribed event is full, then the oldest
event is dropped. It would be nice if the contents of that oldest
event could be merged with the next-oldest. That way no information is
lost, only intermediate steps are lost.
This patch adds optional replace() (called when only one kevent was allocated)
and merge() (called when more than one kevent was allocated) callbacks that
will be called to do this job.
These two callbacks are implemented for the V4L2_EVENT_CTRL event.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The driver had to decide how many events to allocate when the v4l2_fh struct
was created. It was possible to add more events afterwards, but there was no
way to ensure that you wouldn't miss important events if the event queue
would fill up for that filehandle.
In addition, once there were no more free events, any new events were simply
dropped on the floor.
For the control event in particular this made life very difficult since
control status/value changes could just be missed if the number of allocated
events and the speed at which the application read events was too low to keep
up with the number of generated events. The application would have no idea
what the latest state was for a control since it could have missed the latest
control change.
So this patch makes some major changes in how events are allocated. Instead
of allocating events per-filehandle they are now allocated when subscribing an
event. So for that particular event type N events (determined by the driver)
are allocated. Those events are reserved for that particular event type.
This ensures that you will not miss events for a particular type altogether.
In addition, if there are N events in use and a new event is raised, then
the oldest event is dropped and the new one is added. So the latest event
is always available.
This can be further improved by adding the ability to merge the state of
two events together, ensuring that no data is lost at all. This will be
added in the next patch.
This also makes it possible to allow the user to determine the number of
events that will be allocated. This is not implemented at the moment, but
would be trivial.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The v4l2_ctrl_fh struct connected v4l2_ctrl with v4l2_fh so the control
would know which filehandles subscribed to it. However, it is much easier
to use struct v4l2_subscribed_event directly for that and get rid of that
intermediate struct.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Drivers that supported events used to be rare, but now that controls can also
raise events this will become much more common since almost all drivers have
controls.
This means that keeping struct v4l2_events as a separate struct make no more
sense. Merging it into struct v4l2_fh simplifies things substantially as it
is now an integral part of the filehandle struct.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On suspend, remember whether we are streaming or not, and at what frame format,
so that on resume, we can start streaming again.
Signed-off-by: Andrew Chew <achew@nvidia.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is to avoid needing a forward declaration when ov9740_s_power() (in the
subsequent patch) calls ov9740_s_fmt().
Signed-off-by: Andrew Chew <achew@nvidia.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Based on vendor feedback, should issue a software reset at start of day.
Also, OV9740_ANALOG_CTRL15 needs to be changed so the sensor does not begin
streaming until it is ready (otherwise, results in a nonsense frame for the
initial frame).
Added a comment on using discontinuous clock.
Finally, OV9740_ISP_CTRL19 needs to be changed to really use YUYV ordering
(the previous value was for VYUY).
Signed-off-by: Andrew Chew <achew@nvidia.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The register width of the ov9740 is 16-bits, so correct the debug print
to reflect this.
Signed-off-by: Andrew Chew <achew@nvidia.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Made all hex number casing use lower-case throughout the entire driver
for consistency.
Signed-off-by: Andrew Chew <achew@nvidia.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch removes .enum_input(), .suspend() and .resume() soc-camera
client operations.
Functionality, provided by .enum_input(), if needed, can be implemented
using the v4l2-subdev API.
As for .suspend() and .resume(), the only client driver, implementing
these methods has been mt9m111, and the only host driver, using them
has been pxa-camera. Now that both those drivers have been converted
to the standard subdev .s_power() operation, .suspend() and .resume()
can be removed.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Eliminate soc-camera specific .suspend() and .restore() methods in favour
of the standard v4l2-subdev .s_power() method
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is more convenient to propagate the higher level abstraction - the
struct mt9m111 object into functions and then retrieve a pointer to
the i2c client, if needed, than to do the reverse.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
tw9910 is a TV decoder, it doesn't have a tuner. Besides, the
.enum_input soc-camera operation is optional and normally not needed.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
soc_camera core now performs the standard .bytesperline and .sizeimage
calculations internally, no need to duplicate in drivers.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If the user is requesting too large a frame, instead of failing
select an acceptable geometry, preserving the requested aspect ratio.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
soc-camera specific .suspend() and .resume() methods are deprecated
and should be replaced by the subdev standard .s_power() operation.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The pxa-camera driver only supports progressive video so far. Passing
down to the client the same format, as what the user has requested can
result in interlaced video, even if the client supports both. This
patch avoids such cases.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
soc_camera core now performs the standard .bytesperline and .sizeimage
calculations internally, no need to duplicate in drivers.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
soc_camera core now performs the standard .bytesperline and .sizeimage
calculations internally, no need to duplicate in drivers.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Whenever a control changes value or state an event is sent to anyone
that subscribed to it.
This functionality is useful for control panels but also for applications
that need to wait for (usually status) controls to change value.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When an application changes a control you want to generate an event.
However, you want to avoid sending such an event back to the application
(file handle) that caused the change.
Add the filehandle to the various set control functions.
The filehandle isn't used yet, but the control event patches will need
this.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is a bit tricky to handle autogain/gain type scenerios correctly. Such
controls need to be clustered and the V4L2_CTRL_FLAG_UPDATE should be set on
the autofoo controls. In addition, the manual controls should be marked
inactive when the automatic mode is on, and active when the manual mode is on.
This also requires specialized volatile handling.
The chances of drivers doing all these things correctly are pretty remote.
So a new v4l2_ctrl_auto_cluster function was added that takes care of these
issues.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If you have a cluster of controls that is a mix of volatile and non-volatile
controls, then requesting the value of the volatile control would fail if the
master control of that cluster was non-volatile. The code assumed that the
volatile state of the master control was the same for all other controls in
the cluster.
This is now fixed.
In addition, it was clear from bugs in some drivers that it was confusing that
the ctrl->cur union had to be used in g_volatile_ctrl. Several drivers used the
'new' values instead. The framework was changed so that drivers now set the new
value instead of the current value.
This has an additional benefit as well: the volatile values are now only stored
in the 'new' value, leaving the current value alone. This is useful for
autofoo/foo control clusters where you want to have a 'foo' control act like a
volatile control if 'autofoo' is on, but as a normal control when it is off.
Since with this change the cur value is no longer overwritten when g_volatile_ctrl
is called, you can use it to remember the original 'foo' value. For example:
autofoo = 0, foo = 10 and foo is non-volatile.
Now autofoo is set to 1 and foo is marked volatile. Retrieving the foo value
will get the volatile value. Set autofoo back to 0, which marks foo as non-
volatile again, and retrieving foo will get the old current value of 10.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is required to implement control events and is also needed to allow
for per-filehandle control handlers.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When applications try to set READ_ONLY controls an error should
be returned. However, when drivers do that it should be accepted.
Those controls could reflect some driver status which the application
can't change but the driver obviously has to be able to change it.
This is needed among others for future HDMI status controls.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The lower-level prepare functions just set error_idx for each control that
might have an error. The high-level functions will override this with
cs->count in the get and set cases. Only try will keep the error_idx.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add the call_op define to safely call the control ops. This also allows
for controls without any ops such as the 'control class' controls.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Just like the video drivers, the right thing to do is to use
the per-subsystem version control.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Standardize the remaining video drivers to return the API version
for the VIDIOC_QUERYCAP version, instead of a per-driver version.
Those drivers had the version updated more recently or are SoC
drivers. Even so, it doesn't sound a good idea to keep a per-driver
version control, so, let's use the per-subsystem version control
instead.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of handling a per-driver driver version, use the
per-subsystem one.
As reviewed by Jean-Francois Moine <moinejf@free.fr>:
- the 'info' may be simplified:
Reviewed-by: Jean-Francois Moine <moinejf@free.fr>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
uvcvideo doesn't use vidioc_ioctl2. As the API is changing to use
a common version for all drivers, we need to expliticly fix this
driver.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
sn9c102 doesn't use vidioc_ioctl2. As the API is changing to use
a common version for all drivers, we need to expliticly fix this
driver.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
pvrusb2 doesn't use vidioc_ioctl2. As the API is changing to use
a common version for all drivers, we need to expliticly fix this
driver.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
et61x251 doesn't use vidioc_ioctl2. As the API is changing to use
a common version for all drivers, we need to expliticly fix this
driver.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After discussing with Andy Walls on irc, we've agreed that this
is the best thing to do. No regressions will be introduced, as 3.x.y
is greater then the current versions for cx18 and ivtv.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After discussing with Hans, change pwc to use the default version
control.
The only version ever used for pwc driver is 10.0.12, due to
commit 2b455db6d4.
Changing it to 3.x.y won't conflict with the old version.
There's no namespace conflicts in any predictable future.
Even on the remote far-away case where we might have a conflict,
it will be on just one specific stable Kernel release (Kernel 10.0.12),
if we ever have such stable release.
So, it is safe and consistent on using 3.x.y numering schema for
it.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
All the modified drivers didn't have any version increment since
Jan, 1 2011. Several of them didn't have any version increment
for a long time, even having new features and important bug fixes
happening.
As we're now filling the QUERYCAP version with the current Kernel
Release, we don't need to maintain a per-driver version control
anymore. So, let's just use the default.
In order to preserve the Kernel module version history, a
KERNEL_VERSION() macro were added to all modified drivers, and
the extraver number were incremented.
I opted to preserve the per-driver version control to a few
pwc, pvrusb2, s2255, s5p-fimc and sh_vou.
A few drivers are still using the legacy way to handle ioctl's.
So, we can't do such change on them, otherwise, they'll break.
Those are: uvc, et61x251 and sn9c102.
The rationale is that the per-driver version control seems to be
actively maintained on those.
Yet, I think that the better for them would be to just use the
default version numbering, instead of doing that by themselves.
While here, removed a few uneeded include linux/version.h
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Both drxd and siano drivers were including linux/version.h without
any reason. Probably, this is due to some compatibility code that
used to exist before having their support added into the Linux
Kernel.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Most drivers don't increase kernel versions as newer features are added or
bug fixes are solved. So, vidioc_querycap returned value for cap->version is
meaningless. Instead of keeping this situation forever, let's add a default
value matching the current Linux version.
Drivers that want to keep their own version control can still do it, as they
can override the default value for cap->version.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The core driver can now operate in either vmalloc or dma-contig modes;
obviously the latter is preferable when it is supported. Default is
currently vmalloc on all platforms; load the module with buffer_mode=1 for
contiguous DMA mode.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The sequence numbers already give that information if user space cares;
this is a frequent occurrence on slower machines, alas.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This was an old debugging thing from years ago. It's only done at
initialization time, but it's still unnecessary; take it out.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Put the includes into a slightly more readable ordering and get rid of a
few unneeded ones.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is a basic, naive conversion to the videobuf2 infrastructure, removing
a lot of code in the process. For now, we're using vmalloc, which is
suboptimal, but it does match what the cafe driver did before. In the cafe
case, it may have to stay that way just because memory is too tight to do
direct streaming; mmp-camera will be able to do better.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds the VENC or the Video encoder, which is responsible
for the blending of all source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the analog DACs. The venc block is implemented
as a subdevice, allowing for additional external and internal encoders
of other kind to plug-in.
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Acked-by: Muralidharan Karicheri <m-karicheri2@ti.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch implements the functionality of the OSD block
of the VPBE. The OSD in total supports 4 planes or Video
sources - 2 mainly RGB and 2 Video. The patch implements general
handling of all the planes, with specific emphasis on the Video
plane capabilities as the Video planes are supported through the
V4L2 driver.
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Acked-by: Muralidharan Karicheri <m-karicheri2@ti.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch implements the core functionality of the display driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the main V4L2 driver. This implements
the core of each of the V4L2 IOCTLs.
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Acked-by: Muralidharan Karicheri <m-karicheri2@ti.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is the display driver for Texas Instruments's DM644X family
SoC. This patch contains the main implementation of the driver with the
V4L2 interface. The driver implements the streaming model with
support for both kernel allocated buffers and user pointers. It also
implements all of the necessary IOCTLs necessary and supported by the
video display device.
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Acked-by: Muralidharan Karicheri <m-karicheri2@ti.com>
Acked-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Telling the user they can disable an option if they want is not the
much useful. Describe what it is good for instead.
The text was derived from Mauro's email.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Hans Petter Selasky <hselasky@c2i.net>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Acked-by: Hans Petter Selasky <hselasky@c2i.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
flush_scheduled_work() is deprecated and scheduled to be removed.
technisat-usb2 already sync-cancels the only work item it uses and
there's no reason for it to call flush_scheduled_work(). Don't use
it.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch simplifies the platform data slightly, by removing
unused elements.
Signed-off-by: Richard Röjfors <richard.rojfors@pelagicore.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds support for the "Hauppauge WinTV USB2-FM" Analog TV Stick.
It includes support for both the PAL and NTSC variants of the device.
Signed-off-by: Peter Moon <pomoon@gmail.com>
Reviewed-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Changes clock_settting to clock_setting.
Note: This could be intentionally set this way from the beginning and/or
is a typo.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following patch replaces code to reset the XC3028 tuner with a call
to the tuner reset callback.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch implements support for the Leadtek WinFast DTV1800 H card with
XC4000 tuner (107d:6f38).
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch implements support for the Leadtek WinFast DTV2000 H Plus card
with XC4000 tuner (107d:6f42).
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This board were used for testing the em28xx-alsa using a separate interface.
So, it is obviously validated ;)
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Mark the alsa stream with SNDRV_PCM_INFO_BATCH,
as the timing to get audio streams can vary.
Also, add SNDRV_PCM_TRIGGER for pause/release.
while here, fix the stop indicator, to be sure that audio
will be properly released at the stop events.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If the audio stream fails for any reason, it should:
1) Report an error via dmesg;
2) Mark internally that the stream didn't started.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Export ac97 volume controls via mixer.
Pulseaudio will probably handle it very badly, as it has
no idea about how volumes are wired, and how are they
associated with each TV input. Those wirings are
card model dependent, and we don't have the wiring mappings
for each supported device.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixes most cases of initializing a var but not using it.
There are still 3 cases at em28xx-alsa, were those vars should
probably be used.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now we have a camera working over the marvell cam controller core. It
works like the cafe driver and has all the same limitations, contiguous DMA
only being one of them. But it's a start.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The upcoming mmp-camera driver will need an i2c_adapter structure allocated
externally, so change the core adapter to a pointer and require the
platform code to fill it in.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This makes the cafe i2c implement consistent with the rest of Linux so that
the core can use the same slave ID everywhere.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Nobody else ever needs to see these, so let's hide them.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Depending on the controller, the ov7670 sensor may be told to work with a
different clock speed or to use the SMBUS protocol. Remove the wired-in
code and pass that information from the platform layer. The Cafe driver
now just assumes it's running on an OLPC XO 1; I do not believe it has ever
run anywhere else.
Cc: Daniel Drake <dsd@laptop.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There will eventually be multiple users of the core camera controller, so
separate it from the bus/platform/i2c stuff. I've tried to do the minimal
set of changes to get the driver functioning in this configuration; I did
clean up a bunch of old checkpatch gripes in the process. This driver
works like the old one did on OLPC XO 1 systems.
Cc: Daniel Drake <dsd@laptop.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This driver will soon become a family of drivers, so let's give it its own
place to live. This move requires putting ov7670.h into include/media, but
there are no code changes.
Cc: Daniel Drake <dsd@laptop.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
cxsc is not freed in the error case.
Signed-off-by: Andre Bartke <andre.bartke@gmail.com>
Cc: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Make sure the return value is set in all cases
>From 9b38a5c9878b5e4be2899ae291c4524f5f5fc218 Mon Sep 17 00:00:00 2001
Signed-off-by: Hans Petter Selasky <hselasky@c2i.net>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Durations can never be negative, so it makes sense to consistently use
unsigned int for LIRC transmission. Contrary to the initial impression,
this shouldn't actually change the userspace API.
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Solve the ./scripts/checkpatch.pl compliants for the patches
that added xc4000 support, including a few changes at dib0700.
While here, remove a few printk noise by converting some msgs
into debug ones.
Cc: Istvan Varga <istvan_v@mailbox.hu>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Removed the use of 'card_type' from the tuner configuration structure, and
replaced it with separate parameters to set board-specific configuration.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Enabled code to check if the version of the firmware reported by the hardware
is correct after uploading it.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Automatically select the xc4000 module for dib0700 if the tuner selection is
not customized.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Various coding style changes:
- removed unused / commented out code
- changed C++ style comments to C format
- renamed functions and variables that included upper case letters in the name
- removed tabs from module parameter descriptions
- replaced the use of XC_RESULT_* with standard error codes
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Added code to detect the XC4100 chip, which is presumably an analog-only
"value" version of the XC4000. It is not sure, however, if any devices
using this have actually been produced and sold, so the patch may be
unneeded.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch causes the tuner reset command to be ignored in the firmware
code, since this only happens when the BASE/INIT1 firmware is loaded by
check_firmware(), and in that case check_firmware() already calls the
reset callback before starting to load the firmware.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Minor coding changes related to the xc_tune_channel() function.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following patch implements support for analog TV and FM radio.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The 'audio_std' module parameter makes it possible to fine tune
some audio related aspects of the driver, like setting the exact
audio standard (NICAM, A2, etc.) to be used for some video standards.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch implements setting the registers in xc4000_set_params()
and xc4000_set_analog_params(). A new register is defined which enables
filtering of the composite video output (this is needed to avoid bad
picture quality with some boards).
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following patch makes a few minor changes to the printing
of debug messages, and reporting the tuner status. The 'debug'
module parameter can now be set from 0 to 2 to control the
verbosity of debug messages.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes/cleans up the loading of the firmware file when the
driver is loaded and initialized.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following patch implements the xc4000_sleep() function.
The 'no_powerdown' module parameter is now interpreted differently:
- 0 uses a device-specific default
- 1 disables power management like before
- 2 enables power management
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds support for selecting a card type in struct
xc4000_config, to allow for implementing some card specific code
in the driver.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch makes the following fixes in check_firmware():
- there is only one BASE and INIT1 firmware for XC4000
- loading SCODE is needed also for FM radio
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Removed unused code from load_scode() (all SCODE firmwares are
assumed to have the HAS_IF bit set).
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The firmware_name module parameter makes it possible to set the firmware
file name. It defaults to "xc4000.fw" if not specified.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The xc_get_frequency_error() function reported the frequency error
incorrectly. The data read from the hardware is a signed integer, in
15625 Hz units. The attached patch fixes the bug.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds a mutex to xc4000_priv, to protect the driver
from being accessed by multiple processes at the same time.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following patch implements support for DVB-T with 7 MHz bandwidth.
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch makes the following changes to the standards table:
- added 'u16 int_freq' to struct XC_TV_STANDARD (needed for analog TV
and radio, 0 for DVB-T)
- added new standard for SECAM-D/K video with PAL-D/K audio
- the 'int_freq' values are now specified in the table
- changed VideoMode for NTSC and PAL-B/G standards
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is the first of a set of patches that update the original xc4000
sources to my modified version. It removes some unused code, and makes
a few minor formatting changes.
[mchehab@redhat.com: re-add XC_TUNE_ANALOG/XC_TUNE_DIGITAL constants, to avoid compilation breakage]
Signed-off-by: Istvan Varga <istvan_v@mailbox.hu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove some inline comments I had written from when I was computing the proper
dib7000p configuration to work with the xc4000.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove some printk() calls added during driver development, and demote some
other messages to debug only (to reduce dmesg chatter).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Give the xc4000 firmware filename a filename that makes more sense for public
release.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Don't dump debug into to dmesg by default (something I had enabled during
bringup of the xc4000 driver).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixup the PLL and AGC configs so that the 340e works (correcting errors I made
when I did the original config blindly).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove a hack I had put in to force the firmware to be 8MHz, now setting
the firmware properly based on the target standard.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Based on a reference trace under Windows, reverse engineer the PLL config.
Note that the xtal is not yet setup, and the timf cannot be determined yet
because my reference trace doesn't actually achieve a signal lock.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It was confirmed by DibCom that i2c stretching is broken in the i2c master
on the dib7700. So we need to put a hack into the xc4000 driver to not
complain in certain very specific cases where we know i2c stretching occurs.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Setup a proper AGC config for the 340e, based on the Windows USB trace
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove hard-coded references to 5400, using the value passed in when the
xc4000 is attached.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Properly setup the standard firmware loading and scode loading, as well as
getting rid of a ton of dead code. Note that I am getting a single i2c
error when the standard firmware sets the video standard, but everything else
seems to be loading properly now.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add code to handle firmware blobs for the standard and scode. Note there
appears to be some issue with loading the DTV8 standard firmware, probably
related to direct/indirect mode.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since we use the xc3028 version of the firmware file parsing routine (which
includes support for scodes and separate blobs), we can drop the xc5000
version of the code.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The xc4000 driver is based on the original xc5000 driver, and while the
xc5000 supports the XREG_BUSY register, the xc4000 does not. So remove the
code in question.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We need to set the firmware type properly in order to locate the init1
firmware.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The xc3028 version does i2c splitting in a different manner than xc4000 and
xc5000, so reuse the xc5000 version of the routine (the key here being that
xc4000 expects the first *two* bytes to be the same for splitting transactions.
Doing it the xc3028 way was resulting in i2c errors partially through the
firmware load. With this change, it would appear that the entire base firmware
is being loaded successfully (product id now properly shows 0x0FA0).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Switch over to using the firmware management routines from the tuner-xc2028,
since that has support for scodes, etc.
This code still requires signficant cleanup, and at this point the base
firmware does not load properly (i2c write errors about 300 bytes in).
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We need to set the dev.parent member on the dib7000p on its i2c master, or
else calls to request_firmware() will hit an oops in 2.6.31.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add a sleep since in some cases the dib7000p wasn't online when being probed.
The optimal timing has not yet been determined.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use the correct i2c bus to communicate with the tuner, and properly setup the
reset GPIO and i2c address.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Provide a frontend setup routine for the PCTV 340e which takes into account
the specific GPIO setup of the board.
Note that this patch does *not* take into account the xc4000 reset pin, which
is attached to the dib7000.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add the board profile for the PCTV 340eSE, since that's what I have here
for development.
[mchehab@redhat.com: rebased on the top of the current tree]
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This is initial code written by Davide Ferri for the PCTV 340e, including
a new xc4000 driver. I am checking in all the code unmodified, and making
no assertions about its quality (other than confirming it compiles).
[mchehab@redhat.com: rebased on the top of the current tree]
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Davide Ferri <davidef1986@gmail.com>
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The implementation of the gain calculation for this sensor is incorrect.
It is only working for the first 127 values.
The reason is, that the gain cannot be set directly by writing a value
into the gain registers of the sensor. The gain register work this way
(see datasheet page 24): bits 0 to 6 are called "initial gain". These
are linear. But bits 7 and 8 ("analog multiplicative factors") and bits
9 and 10 ("digital multiplicative factors") work completely different:
Each of these bits increase the gain by the factor 2. So if the bits
7-10 are 0011, 0110, 1100 or 0101 for example, the gain from bits 0-6 is
multiplied by 4. The order of the bits 7-10 is not important for the
resulting gain. (But there are some recommended values for low noise)
The current driver doesn't do this correctly: If the current gain is 000
0111 1111 (127) and the gain is increased by 1, you would expect the
image to become brighter. But the image is completly dark, because the
new gain is 000 1000 0000 (128). This means: Initial gain of 0,
multiplied by 2. The result is 0.
This patch adds a new function which does the gain calculation and also
fixes the same bug for red_balance and blue_balance. Additionally, the
driver follows the recommendation from the datasheet, which says, that
the gain should always be above 0x0020.
Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Johannes Obermaier <johannes.obermaier@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are problems when you use this camera/sensor in a very bright room
or outside. The image is completely white, because it is overexposed.
The driver uses a default value which is not suitable for all
environments.
This patch makes it possible to adjust the exposure time by youself. I
found out by logging the i2c-data, that the windows driver for this
sensor is doing this, too. I tested the camera on a sunny day and after
adjusting the exposure time, I was able to see a very good image.
Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Johannes Obermaier <johannes.obermaier@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
According to the datasheet (page 8), the first optical clear
pixel-column is not at position 14. The correct/recommended value is 20.
Without this patch there is a dark line on the left side of the image.
Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Johannes Obermaier <johannes.obermaier@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The conversion of winbond-cir to use rc-core seems to have missed a
a few bits and pieces which were in my local tree. Kudos to
Juan Jesús García de Soria Lucena <skandalfo@gmail.com> for noticing.
[mchehab@redhat.com: fix two UTF-8 violations]
Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the original code, if the allocation failed we dereference "rr3"
when it was NULL.
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If change_protocol() fails and we goto out_raw, then it calls unlock
twice. I noticed that the other time we called change_protocol() we
held the &dev->lock, so I changed it to hold it here too.
Reviewed-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Otherwise they clutter the dmesg buffer even on a production kernel.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The function "rc5_scan" in "dvb_usb.h" is returning invalid value.
The value should be returned "u16" but is returning "u8".
See example below in "drivers/media/dvb/dvb-usb/opera1.c":
send_key = (send_key & 0xffff) | 0x0100;
for (i = 0; i < ARRAY_SIZE(rc_map_opera1_table); i++) {
if (rc5_scan(&rc_map_opera1_table[i]) == (send_key & 0xffff)) {
*state = REMOTE_KEY_PRESSED;
*event = rc_map_opera1_table[i].keycode;
opst->last_key_pressed =
rc_map_opera1_table[i].keycode;
break;
}
opst->last_key_pressed = 0;
}
Signed-off-by: Manoel Pinheiro <pinusdtv@hotmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert radio-sf16fmr2 to use generic TEA575x implementation. Most of the
driver code goes away as SF16-FMR2 is basically just a TEA5757 tuner
connected to ISA bus.
The card can optionally be equipped with PT2254A volume control (equivalent
of TC9154AP) - the volume setting is completely reworked (with balance control
added) and tested.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The info and err macros are already defined by the USB stack. Rename
these macros to avoid macro redefinition warnings.
Signed-off-by: Hans Petter Selasky <hselasky@c2i.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The dbg, warn and info macros are already defined by the USB stack.
Rename these macros to avoid macro redefinition warnings.
Refactor lineshift in printouts.
Signed-off-by: Hans Petter Selasky <hselasky@c2i.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
radio->int_in_urb is not deallocated on error paths in si470x_usb_driver_probe().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
