| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The driver report a reset event when the hardware reports and overflow.
There is no reason to have a generic "reset" event.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
|
|
rc-core kapi uses nanoseconds for infrared durations for receiving, and
microseconds for sending. The uapi already uses microseconds for both,
so this patch does not change the uapi.
Infrared durations do not need nanosecond resolution. IR protocols do not
have durations shorter than about 100 microseconds. Some IR hardware offers
250 microseconds resolution, which is sufficient for most protocols.
Better hardware has 50 microsecond resolution and is enough for every
protocol I am aware off.
Unify on microseconds everywhere. This simplifies the code since less
conversion between microseconds and nanoseconds needs to be done.
This affects:
- rx_resolution member of struct rc_dev
- timeout member of struct rc_dev
- duration member in struct ir_raw_event
Cc: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Patrick Lerda <patrick9876@free.fr>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: "David Härdeman" <david@hardeman.nu>
Cc: Benjamin Valentin <benpicco@googlemail.com>
Cc: Antti Palosaari <crope@iki.fi>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Since this driver could never transmit IR, setting the tx carrier makes
no sense.
Fixes: 87284271b73b8 ("media: rc: nuvoton: remove rudimentary transmit functionality")
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
|
This can be done with c99 initializers, which makes the code cleaner
and more transparent. It does require gcc 4.6, because of this bug
in earlier versions:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
Since commit cafa0010cd51 ("Raise the minimum required gcc version to
4.6"), this is the case.
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
|
Doing writes when the device is disabled seems to be a NOOP.
For CIR device, we should enable it, initialize it, and then disable it
until it's opened. CIR_WAKE should always be enabled.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
|
Core rc keeps track of the users - let's use it to tweak the code and
use the common code path on suspend/resume.
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
|
It appears that we need to enable CIR device before attempting to touch
some of the registers. Previously, this was not a big issue, since we
were rarely seeing nvt_close() getting called.
Unfortunately, since commit cb84343fced1 ("media: lirc: do not call close()
or open() on unregistered devices") the initial open() during probe from
rc_setup_rx_device() is no longer successful, which means that userspace
clients will actually end up calling nvt_open()/nvt_close(). Since
nvt_open() is broken, the device doesn't seem to work as expected.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199597
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
|
|
RC_TYPE is confusing and it's just the protocol. So rename it.
Suggested-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sean Young <sean@mess.org>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Transmit support in this driver was never tested and based on the code
it can't work. Just one example:
The buffer provided to nvt_tx_ir holds unsigned int values in
micro seconds: First value is for a pulse, second for a pause, etc.
Bytes in this buffer are copied as-is to the chip FIFO what can't work
as the chip-internal format is totally different. See also conversion
done in nvt_process_rx_ir_data.
Even if we would try to fix this we have the issue that we can't test
it. There seems to be no device on the market using IR transmit with
one of the chips supported by this driver.
To facilitate maintenance of the driver I'd propose to remove the
rudimentary transmit support.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
When an ir-spi is registered, you get this message.
rc rc0: Unspecified device as /devices/platform/soc/3f215080.spi/spi_master/spi32766/spi32766.128/rc/rc0
"Unspecified device" refers to input_name, which makes no sense for IR
TX only devices. So, rename to device_name.
Also make driver_name const char* so that no casts are needed anywhere.
Now ir-spi reports:
rc rc0: IR SPI as /devices/platform/soc/3f215080.spi/spi_master/spi32766/spi32766.128/rc/rc0
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
nvt_write_wakeup_codes acquires the same lock as the ISR but doesn't
disable interrupts on the local CPU. This caused the following
deadlock. Fix this by using spin_lock_irqsave.
[ 432.362008] ================================
[ 432.362074] WARNING: inconsistent lock state
[ 432.362144] 4.10.0-rc7-next-20170210 #1 Not tainted
[ 432.362219] --------------------------------
[ 432.362286] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[ 432.362379] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[ 432.362457] (&(&nvt->lock)->rlock){?.+...}, at: [<ffffffffa016b17d>] nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[ 432.362611] {HARDIRQ-ON-W} state was registered at:
[ 432.362686]
[ 432.362698] [<ffffffff810adb7c>] __lock_acquire+0x5dc/0x1260
[ 432.362812]
[ 432.362817] [<ffffffff810aec29>] lock_acquire+0xe9/0x1d0
[ 432.362927]
[ 432.362934] [<ffffffff81609f63>] _raw_spin_lock+0x33/0x50
[ 432.363045]
[ 432.363051] [<ffffffffa016b822>] nvt_write_wakeup_codes.isra.12+0x22/0xe0 [nuvoton_cir]
[ 432.363193]
[ 432.363199] [<ffffffffa016b9bf>] wakeup_data_store+0xdf/0xf0 [nuvoton_cir]
[ 432.363327]
[ 432.363333] [<ffffffff81484223>] dev_attr_store+0x13/0x20
[ 432.363441]
[ 432.363449] [<ffffffff81232450>] sysfs_kf_write+0x40/0x50
[ 432.363558]
[ 432.363564] [<ffffffff81231640>] kernfs_fop_write+0x150/0x1e0
[ 432.363676]
[ 432.363685] [<ffffffff811b36a3>] __vfs_write+0x23/0x120
[ 432.363791]
[ 432.363798] [<ffffffff811b4d53>] vfs_write+0xc3/0x1e0
[ 432.363902]
[ 432.363909] [<ffffffff811b6124>] SyS_write+0x44/0xa0
[ 432.364012]
[ 432.364021] [<ffffffff81002c47>] do_syscall_64+0x57/0x140
[ 432.364129]
[ 432.364135] [<ffffffff8160a9e4>] return_from_SYSCALL_64+0x0/0x7a
[ 432.364252] irq event stamp: 415118
[ 432.364313] hardirqs last enabled at (415115): [<ffffffff814fd2eb>] cpuidle_enter_state+0x11b/0x370
[ 432.364445] hardirqs last disabled at (415116): [<ffffffff8160b2cb>] common_interrupt+0x8b/0x90
[ 432.364573] softirqs last enabled at (415118): [<ffffffff8106157c>] _local_bh_enable+0x1c/0x50
[ 432.364699] softirqs last disabled at (415117): [<ffffffff810629a3>] irq_enter+0x43/0x60
[ 432.364814]
other info that might help us debug this:
[ 432.364909] Possible unsafe locking scenario:
[ 432.367821] CPU0
[ 432.370645] ----
[ 432.373432] lock(&(&nvt->lock)->rlock);
[ 432.376228] <Interrupt>
[ 432.378982] lock(&(&nvt->lock)->rlock);
[ 432.381757]
*** DEADLOCK ***
[ 432.389888] no locks held by swapper/0/0.
[ 432.392574]
stack backtrace:
[ 432.397774] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc7-next-20170210 #1
[ 432.400375] Hardware name: ZOTAC ZBOX-CI321NANO/ZBOX-CI321NANO, BIOS B246P105 06/01/2015
[ 432.403023] Call Trace:
[ 432.405636] <IRQ>
[ 432.408208] dump_stack+0x68/0x93
[ 432.410775] print_usage_bug+0x1dd/0x1f0
[ 432.413334] mark_lock+0x559/0x5c0
[ 432.415871] ? print_shortest_lock_dependencies+0x1a0/0x1a0
[ 432.418431] __lock_acquire+0x6b1/0x1260
[ 432.420941] lock_acquire+0xe9/0x1d0
[ 432.423396] ? nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[ 432.425844] _raw_spin_lock+0x33/0x50
[ 432.428252] ? nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[ 432.430670] nvt_cir_isr+0x2d/0x520 [nuvoton_cir]
[ 432.433085] __handle_irq_event_percpu+0x43/0x330
[ 432.435493] handle_irq_event_percpu+0x1e/0x50
[ 432.437884] handle_irq_event+0x34/0x60
[ 432.440236] handle_edge_irq+0x6a/0x150
[ 432.442561] handle_irq+0x15/0x20
[ 432.444854] do_IRQ+0x57/0x110
[ 432.447115] common_interrupt+0x90/0x90
[ 432.449380] RIP: 0010:cpuidle_enter_state+0x120/0x370
[ 432.451653] RSP: 0018:ffffffff81c03dd8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffffcc
[ 432.453994] RAX: ffffffff81c14500 RBX: 0000000000000008 RCX: 00000064aac6f2d2
[ 432.456349] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff81c14500
[ 432.458704] RBP: ffffffff81c03e18 R08: cccccccccccccccd R09: 0000000000000018
[ 432.461072] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880100a21260
[ 432.463450] R13: ffffffff81c7e6f8 R14: 0000000000000008 R15: ffffffff81c7e6e0
[ 432.465819] </IRQ>
[ 432.468104] ? cpuidle_enter_state+0x11b/0x370
[ 432.470413] cpuidle_enter+0x12/0x20
[ 432.472698] call_cpuidle+0x1e/0x40
[ 432.474967] do_idle+0xe3/0x1c0
[ 432.477172] cpu_startup_entry+0x18/0x20
[ 432.479376] rest_init+0x130/0x140
[ 432.481565] start_kernel+0x3cc/0x3d9
[ 432.483750] x86_64_start_reservations+0x2a/0x2c
[ 432.485980] x86_64_start_kernel+0x178/0x18b
[ 432.488222] start_cpu+0x14/0x14
[ 432.490453] ? start_cpu+0x14/0x14
Fixes: 97c129747af5 "[media] rc: nuvoton-cir: Add support wakeup via sysfs filter callback"
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The driver type can be assigned immediately when an RC device
requests to the framework to allocate the device.
This is an 'enum rc_driver_type' data type and specifies whether
the device is a raw receiver or scancode receiver. The type will
be given as parameter to the rc_allocate_device device.
Change accordingly all the drivers calling rc_allocate_device()
so that the device type is specified during the rc device
allocation. Whenever the device type is not specified, it will be
set as RC_DRIVER_SCANCODE which was the default '0' value.
Suggested-by: Sean Young <sean@mess.org>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Nuvoton-cir utilizes the encoding capabilities of rc-core to convert
scancodes from user space to pulse/space format understood by the
underlying hardware.
Converted samples are then written to the wakeup fifo along with other
necessary configuration to enable wake up functionality.
Signed-off-by: Antti Seppälä <a.seppala@gmail.com>
Signed-off-by: James Hogan <james@albanarts.com>
Signed-off-by: Sean Young <sean@mess.org>
Cc: Jarod Wilson <jarod@redhat.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
unknown and other are for IR protocols for which we have no decoder,
so the raw IR drivers have no chance of generating them. cec is not
an IR protocol.
Signed-off-by: Sean Young <sean@mess.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Drop the FSF's postal address from the source code files that typically
contain mostly the license text. Of the 628 removed instances, 578 are
outdated.
The patch has been created with the following command without manual edits:
git grep -l "675 Mass Ave\|59 Temple Place\|51 Franklin St" -- \
drivers/media/ include/media|while read i; do i=$i perl -e '
open(F,"< $ENV{i}");
$a=join("", <F>);
$a =~ s/[ \t]*\*\n.*You should.*\n.*along with.*\n.*(\n.*USA.*$)?\n//m
&& $a =~ s/(^.*)Or, (point your browser to) /$1To obtain the license, $2\n$1/m;
close(F);
open(F, "> $ENV{i}");
print F $a;
close(F);'; done
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Kernel takes care that interrupts from one source are serialized.
So there's no need to use spinlock_irq_save.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Spinlock nvt_lock is a member of struct nvt_dev and there's no need
to prefix it with nvt_. So remove this prefix.
[mchehab@s-opensource.org: change the prefix also at the open function,
as the patch removing it were not applied (yet?)]
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Using a separate spinlock to protect access to substruct tx of struct
nvt_dev doesn't provide any actual benefit. We can use spinlock
nvt_lock to protect all access to struct nvt_dev and get rid of
nvt->tx.lock.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Member pdev of struct nvt_dev is needed only to access &pdev->dev.
We can get rid of this it by using rdev->dev.parent instead
(both point to the same struct device).
Setting rdev->dev.parent can be removed from the probe function
as this is done by devm_rc_allocate_device now.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
rc_register_device
Simplify the remove function and the error path in the probe function by
using the managed versions of rc_allocate_device and rc_register_device.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Simplify the code a little.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
ir_raw_event_handle is called anyway after the hw fifo content stored
in nvt->buf[] has been written to the kfifo. There is not really a
benefit in the potential additional call to ir_raw_event_handle
whilst nvt->buf[] is being processed.
Getting rid of this additional call allows to simplify the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The call to nvt_get_rx_ir_data and nvt_process_rx_ir_data from
the ISR is protected with spinlock nvt->lock. Therefore it's
guaranteed that nvt->pkts is 0 when entering nvt_get_rx_ir_data
(as nvt->pkts is set to 0 at the end of nvt_process_rx_ir_data).
Having said that we can remove b_idx.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
being disabled
When removing module nuvoton-cir I get a fifo overrun warning.
It turned out to be caused by a spurious interrupt when the logical CIR
device is being disabled (although no interrupt source bit being set).
Reading the interrupt status register returns 0xff, therefore the fifo
overrun bit is mistakenly interpreted as being set.
Fix this by ignoring interrupts when interrupt source and status register
reads return 0xff.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
address
If a system configures the Nuvoton chip to use the alternative
EFM IO address (CR_EFIR2) then after probing the primary EFM IO
address (CR_EFIR) this region is not released.
If a driver for another function of the Nuvoton Super I/O
chip uses the same probing mechanism then it will hang if
loaded after the nuvoton-cir driver.
This was reported for the nct6775 hwmon driver.
Fix this by properly releasing the region after probing CR_EFIR.
This regression was introduced with kernel 4.6 so cc it to stable.
Reported-by: Antti Seppälä <a.seppala@gmail.com>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Antti Seppälä <a.seppala@gmail.com>
Cc: <stable@vger.kernel.org> # 4.6.x-
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
If the logical device is disabled then it can not generate interrupts.
Therefore this check is not needed.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Simplify interupt handling code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Study states have never been used and are not needed. Remove them.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The definition of rawir includes the initialization already.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Simplify a few functions.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Wake states have never been in use and now that we can set the
wakeup sequence via sysfs there's in general no need for them.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
The registers defining wakeup sequence handling are set when the
wakeup sequence is set via sysfs. There's no need to initialize them
otherwise.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
There is a rudimentary ISR for handling interrupts generated by the
wakeup part of the chip. Interrupts however have never been enabled
in the wakeup part.
Also, now that we can set the wakeup sequence via sysfs, there's in
general no need to enable interrupts in the wakeup part.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
To detect a rx fifo overrun it's checked whether the number of elements
in the chip fifo exceeds the fifo size. This check can never return true
and is wrong.
Instead we should generate an interrupt if the fifo overruns.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
|
Switch attribute wakeup_data from binary to a text attribute.
This makes it easier to handle in userspace and allows to
use the output of tools like mode2 almost as is to set a
wakeup sequence.
Changing to a text format and values in microseconds also
makes the userspace interface independent of the setting of
SAMPLE_PERIOD in the driver.
In addition document the new sysfs attribute in
Documentation/ABI/testing/sysfs-class-rc-nuvoton.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
This patch adds a binary attribute /sys/class/rc/rc?/wakeup_data which
allows to read / write the wakeup sequence.
In combination with the core extension for exposing the most recent raw
packet this allows to easily define and set a wakeup sequence.
At least on my Zotac CI321 the BIOS resets the wakeup sequence at each boot
to a factory default. Therefore I use a udev rule
SUBSYSTEM=="rc", DRIVERS=="nuvoton-cir", ACTION=="add", RUN+="<script>"
with the script basically doing
cat <stored wakeup sequence> >/sys${DEVPATH}/wakeup_data
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
nvt_disable_cir calls nvt_disable_logical_dev (that may sleep) and is
called from contexts holding a spinlock.
Fix this and remove the unneeded clearing of CIR_IREN as this is done
in nvt_cir_disable already.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
nvt_enable_wake calls nvt_select_logical_dev (that may sleep) and is called
from contexts holding a spinlock. Fix this.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
nvt_enable_cir calls nvt_enable_logical_dev (that may sleep)
while holding a spinlock.
This patch fixes this and moves the content of nvt_enable_cir
to nvt_open as this is the only caller.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Extend the locking to protect more critical actions like register accesses
in the interrupt handlers.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Only handle an interrupt if at least one combination of event bit
and related interrupt bit is set.
Previously it was just checked that at least one event bit and
at least one interrupt bit are set.
This fixes issues like the following which was caused by
interrupt sharing:
An interrupt intended for nvt_cir_isr was handled by nvt_cir_wake_isr
first and because status bit CIR_WAKE_IRSTS_IR_PENDING was set
the wake fifo was accidently cleared.
This patch also fixes the bug that nvt_cir_wake_isr returned IRQ_HANDLED
even if it detected that the (shared) interrupt was meant for another
handler.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Add locking to nvt_enable_wake calls.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Check for the case that no Nuvoton chip is found on either EFM port.
Also move the position of nvt_efm_disable to reduce the time the
EFM ports are locked.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
At least on Zotac CI321 ACPI provides an ioport range for the wake up part
but accessing these ioports has no effect.
Instead the ioport base address is set to another value already
(0xa20 in my case) and accessing this ioport range works.
Therefore set a new ioport base address only if the current ioport base
address is 0 (register reset default).
The need to use the existing base address instead of trying to set
an own one doesn't seem to be limited to this specific device as other
drivers like hwmon/nct6775 do it the same way.
This change was successfully tested on the mentioned device.
And the change should be generic enough to not break the driver for
other chips (however due to lack of appropriate hardware I wasn't
able to test this).
[mchehab@osg.samsung.com: Tested on Intel NUC NUC5i7RYB with BIOS
version RYBDWi35.86A.0350.2015.0812.1722]
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Calling nvt_set_cir_iren separately is not needed as this is done
by nvt_cir_regs_init.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Selecting the logical device in the interrupt handler is not needed
as no configuration register is accessed.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Only enable the logical devices after the registers have been initialized.
The call to nvt_enable_logical_dev in nvt_resume is not needed as this is
done implicitely by nvt_cir_regs_init now.
[mchehab@osg.samsung.com: fixed multiline comment to kernel CodingStyle]
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
Factor out enabling of a logical device.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
|
At least on NVT6779D clearing the wake fifo works in learning mode only
(although this condition is not mentioned in the chip spec).
Setting the clear fifo bit has no effect in wake up mode.
Even if clearing the wake fifo should work in wake up mode on other
chips this workaround doesn't hurt.
If needed the caller of nvt_clear_cir_wake_fifo has to take care
of locking.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
