Statistics polling can not be done by lmedm04 driver's implementation of
M88RS2000/TS2020 because I2C messages stop the device's demuxer, so allow
polling for statistics to be suppressed in the ts2020 driver by setting
dont_poll in the ts2020_config struct.
Reported-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Copy the loop_through setting from the ts2020_config struct to the internal
ts2020_priv struct so that it can actually be used.
Whilst we're at it, group the bitfields together in the same order in both
structs so that the compiler has a good chance to copy them in one go.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Provide a DVBv5 API signal strength. This is in units of 0.001 dBm rather
than a percentage.
>From Antti Palosaari's testing with a signal generator, it appears that the
gain calculated according to Montage's specification if negated is a
reasonable representation of the signal strength of the generator.
To this end:
(1) Polled statistic gathering needed to be implemented in the TS2020 driver.
This is done in the ts2020_stat_work() function.
(2) The calculated gain is placed as the signal strength in the
dtv_property_cache associated with the front end with the scale set to
FE_SCALE_DECIBEL.
(3) The DVBv3 format signal strength then needed to be calculated from the
signal strength stored in the dtv_property_cache rather than accessing
the value when ts2020_read_signal_strength() is called.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The fix for NULL pointer exception related to calling uevent for not
finished probe caused to set all writeable properties as non-writeable.
This was caused by checking if property is writeable before the initial
increase of power supply usage counter and in the same time using
wrapper over property_is_writeable(). The wrapper returns ENODEV if the
usage counter is still 0.
The call trace looked like:
device probe:
power_supply_register()
use_cnt = 0;
device_add()
create sysfs entries
power_supply_attr_is_visible()
power_supply_property_is_writeable()
if (use_cnt == 0) return -ENODEV;
use_cnt++;
Replace the usage of wrapper with direct call to property_is_writeable()
from driver. This should be safe call during device probe because
implementations of this callback just return 0/1 for different
properties and they do not access any of the driver's internal data.
Fixes: 8e59c7f234 ("power_supply: Fix NULL pointer dereference during bq27x00_battery probe")
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The TS2020 and TS2022 tuners take an input from the demodulator indicating the
AGC setting on that component that is then used to influence the tuner's own
gain. This should be taken into account when calculating the gain and signal
strength.
Further, the existing TS2020 driver miscalculates the signal strength as the
result of its calculations can exceed the storage capacity of the 16-bit word
used to return it to userspace.
To this end:
(1) Add a callback function (->get_agc_pwm()) in the ts2020_config struct that
the tuner can call to get the AGC PWM value from the demodulator.
(2) Modify the TS2020 driver to calculate the gain according to Montage's
specification with the adjustment that we produce a negative value and
scale it to 0.001dB units (which is what the DVBv5 API will require):
(a) Callback to the demodulator to retrieve the AGC PWM value and then
turn that into Vagc for incorporation in the calculations. If the
callback is unset, assume a Vagc of 0.
(b) Calculate the tuner gain from a combination of Vagc and the tuner's RF
gain and baseband gain settings.
(3) Turn this into a percentage signal strength as per Montage's
specification for return to userspace with the DVBv3 API.
(4) Provide a function in the M88DS3103 demodulator driver that can be used to
get the AGC PWM value on behalf of the tuner.
(5) The ts2020_config.get_agc_pwm function should be set by the code that
stitches together the drivers for each card.
For the DVBSky cards that use the M88DS3103 with the TS2020 or the TS2022,
set the get_agc_pwm function to point to m88ds3103_get_agc_pwm.
I have tested this with a DVBSky S952 card which has an M88DS3103 and a TS2022.
Thanks to Montage for providing access to information about the workings of
these parts.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Use regmap for I2C register access.
Remove own I2C repeated mutex as it should not be needed. I2C adapter
lock is already taken when I2C mux adapter is called, no need for
double locking.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Rename driver state from priv to dev.
Use I2C client for correct logging.
Use adapter and address from I2C client structure where needed.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
As we're running out of hardware capability flags pretty quickly,
convert them to use the regular test_bit() style unsigned long
bitmaps.
This introduces a number of helper functions/macros to set and to
test the bits, along with new debugfs code.
The occurrences of an explicit __clear_bit() are intentional, the
drivers were never supposed to change their supported bits on the
fly. We should investigate changing this to be a per-frame flag.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
lockdep report following warning in test:
[25176.843958] =================================
[25176.844519] [ INFO: inconsistent lock state ]
[25176.845047] 4.1.0-rc3 #22 Tainted: G W
[25176.845591] ---------------------------------
[25176.846153] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[25176.846713] fsstress/26661 [HC0[0]:SC1[1]:HE1:SE0] takes:
[25176.847246] (&wr_ctx->wr_lock){+.?...}, at: [<ffffffffa04cdc6d>] scrub_free_ctx+0x2d/0xf0 [btrfs]
[25176.847838] {SOFTIRQ-ON-W} state was registered at:
[25176.848396] [<ffffffff810bf460>] __lock_acquire+0x6a0/0xe10
[25176.848955] [<ffffffff810bfd1e>] lock_acquire+0xce/0x2c0
[25176.849491] [<ffffffff816489af>] mutex_lock_nested+0x7f/0x410
[25176.850029] [<ffffffffa04d04ff>] scrub_stripe+0x4df/0x1080 [btrfs]
[25176.850575] [<ffffffffa04d11b1>] scrub_chunk.isra.19+0x111/0x130 [btrfs]
[25176.851110] [<ffffffffa04d144c>] scrub_enumerate_chunks+0x27c/0x510 [btrfs]
[25176.851660] [<ffffffffa04d3b87>] btrfs_scrub_dev+0x1c7/0x6c0 [btrfs]
[25176.852189] [<ffffffffa04e918e>] btrfs_dev_replace_start+0x36e/0x450 [btrfs]
[25176.852771] [<ffffffffa04a98e0>] btrfs_ioctl+0x1e10/0x2d20 [btrfs]
[25176.853315] [<ffffffff8121c5b8>] do_vfs_ioctl+0x318/0x570
[25176.853868] [<ffffffff8121c851>] SyS_ioctl+0x41/0x80
[25176.854406] [<ffffffff8164da17>] system_call_fastpath+0x12/0x6f
[25176.854935] irq event stamp: 51506
[25176.855511] hardirqs last enabled at (51506): [<ffffffff810d4ce5>] vprintk_emit+0x225/0x5e0
[25176.856059] hardirqs last disabled at (51505): [<ffffffff810d4b77>] vprintk_emit+0xb7/0x5e0
[25176.856642] softirqs last enabled at (50886): [<ffffffff81067a23>] __do_softirq+0x363/0x640
[25176.857184] softirqs last disabled at (50949): [<ffffffff8106804d>] irq_exit+0x10d/0x120
[25176.857746]
other info that might help us debug this:
[25176.858845] Possible unsafe locking scenario:
[25176.859981] CPU0
[25176.860537] ----
[25176.861059] lock(&wr_ctx->wr_lock);
[25176.861705] <Interrupt>
[25176.862272] lock(&wr_ctx->wr_lock);
[25176.862881]
*** DEADLOCK ***
Reason:
Above warning is caused by:
Interrupt
-> bio_endio()
-> ...
-> scrub_put_ctx()
-> scrub_free_ctx() *1
-> ...
-> mutex_lock(&wr_ctx->wr_lock);
scrub_put_ctx() is allowed to be called in end_bio interrupt, but
in code design, it will never call scrub_free_ctx(sctx) in interrupe
context(above *1), because btrfs_scrub_dev() get one additional
reference of sctx->refs, which makes scrub_free_ctx() only called
withine btrfs_scrub_dev().
Now the code runs out of our wish, because free sequence in
scrub_pending_bio_dec() have a gap.
Current code:
-----------------------------------+-----------------------------------
scrub_pending_bio_dec() | btrfs_scrub_dev
-----------------------------------+-----------------------------------
atomic_dec(&sctx->bios_in_flight); |
wake_up(&sctx->list_wait); |
| scrub_put_ctx()
| -> atomic_dec_and_test(&sctx->refs)
scrub_put_ctx(sctx); |
-> atomic_dec_and_test(&sctx->refs)|
-> scrub_free_ctx() |
-----------------------------------+-----------------------------------
We expected:
-----------------------------------+-----------------------------------
scrub_pending_bio_dec() | btrfs_scrub_dev
-----------------------------------+-----------------------------------
atomic_dec(&sctx->bios_in_flight); |
wake_up(&sctx->list_wait); |
scrub_put_ctx(sctx); |
-> atomic_dec_and_test(&sctx->refs)|
| scrub_put_ctx()
| -> atomic_dec_and_test(&sctx->refs)
| -> scrub_free_ctx()
-----------------------------------+-----------------------------------
Fix:
Move scrub_pending_bio_dec() to a workqueue, to avoid this function run
in interrupt context.
Tested by check tracelog in debug.
Changelog v1->v2:
Use workqueue instead of adjust function call sequence in v1,
because v1 will introduce a bug pointed out by:
Filipe David Manana <fdmanana@gmail.com>
Reported-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
The extent-same code rejects requests with an unaligned length. This
poses a problem when we want to dedupe the tail extent of files as we
skip cloning the portion between i_size and the extent boundary.
If we don't clone the entire extent, it won't be deleted. So the
combination of these behaviors winds up giving us worst-case dedupe on
many files.
We can fix this by allowing a length that extents to i_size and
internally aligining those to the end of the block. This is what
btrfs_ioctl_clone() so we can just copy that check over.
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Signed-off-by: Chris Mason <clm@fb.com>
max_to_defrag represents the number of pages to defrag rather than the last
page of the file range to be defragged.
Consider a file having 10 4k blocks (i.e. blocks in the range [0 - 9]). If the
defrag ioctl was invoked for the block range [3 - 6], then max_to_defrag
should actually have the value 4. Instead in the current code we end up
setting it to 6.
Now, this does not (yet) cause an issue since the first part of the while loop
condition in btrfs_defrag_file() (i.e. "i <= last_index") causes the control
to flow out of the while loop before any buggy behavior is actually caused. So
the patch just makes sure that max_to_defrag ends up having the right value
rather than fixing a bug. I did run the xfstests suite to make sure that the
code does not regress.
Changelog: v1->v2:
Provide a much descriptive commit message.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: Chris Mason <clm@fb.com>
Read-ahead is done for the pages in the range [ra_index, ra_index + cluster -
1]. So the next read-ahead should be starting from the page at index 'ra_index
+ cluster' (unless we deemed that the extent at 'ra_index + cluster' as
non-defraggable) rather than from the page at index 'ra_index +
max_cluster'. This patch fixes this. I did run the xfstests suite to make sure
that the code does not regress.
Signed-off-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: Chris Mason <clm@fb.com>
When allocating a new chunk or removing one we need to update num_devs
device items and insert or remove a chunk item in the chunk tree, so
in the worst case the space needed in the chunk space_info is:
btrfs_calc_trunc_metadata_size(chunk_root, num_devs) +
btrfs_calc_trans_metadata_size(chunk_root, 1)
That is, in the worst case we need to cow num_devs paths and cow 1 other
path that can result in splitting every node and leaf, and each path
consisting of BTRFS_MAX_LEVEL - 1 nodes and 1 leaf. We were requiring
some additional chunk_root->nodesize * BTRFS_MAX_LEVEL * num_devs bytes,
which were unnecessary since updating the existing device items does
not result in splitting the nodes and leaf since after updating them
they remain with the same size.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
We don't need to attach ordered extents that have completed to the current
transaction. Doing so only makes us hold memory for longer than necessary
and delaying the iput of the inode until the transaction is committed (for
each created ordered extent we do an igrab and then schedule an asynchronous
iput when the ordered extent's reference count drops to 0), preventing the
inode from being evictable until the transaction commits.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Commit 3a8b36f378 ("Btrfs: fix data loss in the fast fsync path") added
a performance regression for that causes an unnecessary sync of the log
trees (fs/subvol and root log trees) when 2 consecutive fsyncs are done
against a file, without no writes or any metadata updates to the inode in
between them and if a transaction is committed before the second fsync is
called.
Huang Ying reported this to lkml (https://lkml.org/lkml/2015/3/18/99)
after a test sysbench test that measured a -62% decrease of file io
requests per second for that tests' workload.
The test is:
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
mkfs -t btrfs /dev/sda2
mount -t btrfs /dev/sda2 /fs/sda2
cd /fs/sda2
for ((i = 0; i < 1024; i++)); do fallocate -l 67108864 testfile.$i; done
sysbench --test=fileio --max-requests=0 --num-threads=4 --max-time=600 \
--file-test-mode=rndwr --file-total-size=68719476736 --file-io-mode=sync \
--file-num=1024 run
A test on kvm guest, running a debug kernel gave me the following results:
Without 3a8b36f378: 16.01 reqs/sec
With 3a8b36f378: 3.39 reqs/sec
With 3a8b36f378 and this patch: 16.04 reqs/sec
Reported-by: Huang Ying <ying.huang@intel.com>
Tested-by: Huang, Ying <ying.huang@intel.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
A previous commit wanted to make CFQ default to IOPS mode on
non-rotational storage, however it did so when the queue was
initialized and the non-rotational flag is only set later on
in the probe.
Add an elevator hook that gets called off the add_disk() path,
at that point we know that feature probing has finished, and
we can reliably check for the various flags that drivers can
set.
Fixes: 41c0126b ("block: Make CFQ default to IOPS mode on SSDs")
Tested-by: Romain Francoise <romain@orebokech.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
ts2020_attach() allocates a variable pdata on the stack and then passes a
pointer to it to i2c_new_device() which stashes the pointer in persistent
structures.
Add a comment to the effect that this isn't actually an error because the
contents of the variable are only used in ts2020_probe() and this is only
called ts2020_attach()'s stack frame exists.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Register driver using I2C bindings internally when legacy media
attach is used. That is done by registering driver using I2C binding
from legacy attach. That way we can get valid I2C client, which is
needed for proper dev_() logging and regmap for example even legacy
binding is used.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
* We don't need calculate channel bandwidth from symbol rate as it
is calculated by DVB core.
* Use clamp() to force upper/lower limit of filter 3dB frequency.
Upper limit should never exceeded 40MHz (80MHz BW) in any case,
though...
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Used frequency synthesizer is simple Integer-N PLL, with configurable
reference divider, output divider and of course N itself. Old
calculations were working fine, but not so easy to understand.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
smu_init allocates buffers and initializes them. It does not
touch the hw. There is no need to do it again on resume. It
should really be part of sw_init (and smu_fini should be part
of sw_fini), but we need the firmware sizes from the other IPs
for firmware loading so we have to wait until sw init is done
for all other IPs.
Reviewed-by: Sonny Jiang <Sonny.Jiang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
smu_init allocates buffers and initializes them. It does not
touch the hw. There is no need to do it again on resume. It
should really be part of sw_init (and smu_fini should be part
of sw_fini), but we need the firmware sizes from the other IPs
for firmware loading so we have to wait until sw init is done
for all other IPs.
Reviewed-by: Sonny Jiang <Sonny.Jiang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
smu_init allocates buffers and initializes them. It does not
touch the hw. There is no need to do it again on resume. It
should really be part of sw_init (and smu_fini should be part
of sw_fini), but we need the firmware sizes from the other IPs
for firmware loading so we have to wait until sw init is done
for all other IPs.
Reviewed-by: Sonny Jiang <Sonny.Jiang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
acpi_gpiochip_request(free)_interrupts can be used for modules,
so export them. This also fixs a compile error when xgene-sb
configured as kernel module.
Fixes: 733cf014f0 "gpio: xgene: add ACPI support for APM X-Gene GPIO standby driver"
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Fix section mismatch error during kernel build for xgene_slimpro_i2c_probe
function. It was incorrectly defined with __init declaration.
Signed-off-by: Feng Kan <fkan@apm.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Some leftover copy and pastes from radeon that never
got updated.
Reviewed-by: Christian König <christian.koenig@amd.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Sending a message to own address locks the controller up in very bizarre state,
it behaves as slave even if MDR register clearly states master. The controller
remains in this state until reset. To avoid unnecessary timeouts simply avoid
sending to own address. The controller cannot do this any way. Also, do not
enable AAS IRQ, as the slave mode is not supported by the driver and the only
possibility to trigger this IRQ is to send to own address.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
There are several problems in the function:
- "to_cnt" variable does nothing
- schedule_timeout() call without setting current state does nothing
- "allow_sleep" parameter is not really used
Refactor the function so that it really tries to wait. In case of timeout try
to recover the bus.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Adding support for i2c controller driver for Broadcom settop
SoCs.
Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com>
[wsa: removed superfluous owner in platform_driver]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
There are still some 64-bit division problems in the cobalt code.
Replace it by div_u64.
[mchehab@osg.samsung.com: folded with an additional diff sent by
Hans via a priv e-mail]
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Reported-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
When FIFOs are available and enabled, the driver now configures the Atmel
eXtended DMA Controller to perform word accesses instead of byte accesses
when possible.
The actual access width depends on the size of the buffer to transmit.
To enable FIFO support the "atmel,fifo-size" property must be set properly
in the I2C controller node of the device tree.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The probe() function now prints the hardware version of the I2C
controller.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
[wsa: s/version/hw version/] for clarity]
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The alternative command mode was introduced to simplify the transmission
of STOP conditions and to solve timing and latency issues around them.
This mode relies on a new register, the Alternative Command Register,
which must be set at the same time as the Master Mode Register. This new
register was designed to allow simple setup of basic combined transactions
built from up to two unitary transactions.
Indeed, the ACR is split into two areas, which describe one unitary
transaction each. Each area is filled with Data Length 8bit counter, a
Direction and a PEC Request bit. The PEC bit is only used in SMBus mode
and is not supported by this driver yet. Also when using alternative
command mode, the MREAD bit from the Master Mode Register is ignored.
Instead the Direction bits from ACR are used to setup the direction, read
or write, of each unitary transaction. Finally the 8bit counters must
filled with the data length of their respective transaction. Then if only
one transaction is to be used, the data length of the second one must be
set to zero. At the moment, this driver uses only the first transaction.
In addition to MMR and ACR, the Control Register also need to be written
to enable the alternative command mode. That's the purpose of its ACMEN
bit, which stands for Alternative Command Mode Enable.
Note that the alternative command mode is compatible with the use of the
Internal Address Register. So combined transactions for eeprom read are
actually implemented with the Internal Address Register. This register is
written with up to 3 bytes, which are the internal address sent to the
slave through the first write transaction. Then the first area of the ACR
describe the write transaction to follow, which carries the data to be
read from the eeprom. The second area of the ACR is not used so its Data
Length 8bit counter is cleared.
For each byte sent or received by the device, the Data Length 8bit counter
is decremented. When it reaches 0, a STOP condition is automatically sent.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
add a new value "atmel,sama5d2-i2c" for the "compatible" property.
add a new optional property "atmel,fifo-size" to enable FIFO support when
available.
add missing optional properties "dmas" and "dma-names".
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This patch just fixes typo before applying later patches which will use
register bits with index above 16.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
For TX transactions, the TXCOMP bit in the Status Register is cleared
when the first data is written into the Transmit Holding Register.
In the lines from at91_do_twi_transfer():
at91_twi_write_data_dma(dev);
at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_TXCOMP);
the TXCOMP interrupt may be enabled before the DMA controller has
actually started to write into the THR. In such a case, the TXCOMP bit
is still set into the Status Register so the interrupt is triggered
immediately. The driver understands that a transaction completion has
occurred but this transaction hasn't started yet. Hence the TXCOMP
interrupt is no longer enabled by at91_do_twi_transfer() but instead
by at91_twi_write_data_dma_callback().
Also, the TXCOMP bit in the Status Register in not a clear on read flag
but a snapshot of the transmission state at the time the Status
Register is read.
When a NACK error is dectected by the I2C controller, the TXCOMP, NACK
and TXRDY bits are set together to 1 in the SR. If enabled, the TXCOMP
interrupt is triggered at the same time. Also setting the TXRDY to 1
triggers the DMA controller to write the next data into the THR. Such
a write resets the TXCOMP bit to 0 in the SR. So depending on when the
interrupt handler reads the SR, it may fail to detect the NACK error
if it relies on the TXCOMP bit. The NACK bit and its interrupt should
be used instead.
For RX transactions, the TXCOMP bit in the Status Register is cleared
when the START bit is set into the Control Register. However to unify
the management of the TXCOMP bit when the DMA controller is used, the
TXCOMP interrupt is now enabled by the DMA callbacks for both TX and
RX transfers.
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Cc: stable@vger.kernel.org #3.10 and later
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Currently, pinctrl_register() just returns NULL on error, so the
callers can not know the exact reason of the failure.
Some of the pinctrl drivers return -EINVAL, some -ENODEV, and some
-ENOMEM on error of pinctrl_register(), although the error code
might be different from the real cause of the error.
This commit reworks pinctrl_register() to return the appropriate
error code and modifies all of the pinctrl drivers to use IS_ERR()
for the error checking and PTR_ERR() for getting the error code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Lee Jones <lee@kernel.org>
Acked-by: Sören Brinkmann <soren.brinkmann@xilinx.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Ray Jui <rjui@broadcom.com>
Acked-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
Acked-by: Wei Chen <Wei.Chen@csr.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Armada 39x SoC family has grown a new variant, the Armada 395,
which sits between the Armada 390 and Armada 398 in terms of
features. This commit adds support for this additional variant to the
Armada 39x pinctrl driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The latest version of the Armada 39x datasheet documents several new
SATA related functions on various MPP pins. This commit adds the
description of these new functions to the Armada 39x pinctrl driver as
well as to its DT binding documentation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The latest version of the Armada 39x datasheet documents several new
PCIe related functions on various MPP pins. This commit adds the
description of these new functions to the Armada 39x pinctrl driver as
well as to its DT binding documentation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The latest version of the Armada 38x datasheet documents several new
PTP related functions on various MPP pins. This commit adds the
description of these new functions to the Armada 38x pinctrl driver as
well as to its DT binding documentation.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
