04 Apr, 2013
10 commits
-
This reverts commit 478af139295b451c59eeba8f851654964321cbfe.
With a proper fix to this code, this is no longer neccessary.
Signed-off-by: Russ Dill
-
Allocating an extra byte is not necessary here. The driver will check
that the allocation is large enough to satisfy the IIO subsystem.Signed-off-by: Russ Dill
-
In the case that the FIFO threshold handler gets called when the
FIFO has not actually reached the threshold, the driver will pass
uninitialized memory to the IIO subsystem.In the past, this would occur due to bugs in the driver, those bugs
have been fixed. However, it is still a good idea to close this just
in case additional bugs in hardware or software exist.Signed-off-by: Russ Dill
-
If we fail to allocate a buffer, unmask the interrupt to allow a retry.
The interrupt handler will be re-run, and our workqueue rescheduled.
If we are able to allocate memory next time around, everything will
continue as normal, otherwise, we will eventually get an underrun.Before this patch, the driver would stop capturing without any
indication of error to the IIO subsystem or the user.Signed-off-by: Russ Dill
-
While not pulling out samples, the FIFO will fill up causing an
overrun event. Before starting up another continuous sample, clear that
event.Signed-off-by: Russ Dill
-
When an overrun occurs, the FIFO is cleared. If a FIFO threshold event
was pending, the data is now gone. Clear the threshold event when
handling an overrun (or underflow).Signed-off-by: Russ Dill
-
The threshold event handler is being called before the FIFO has
actually reached the threshold.The current code receives a FIFO threshold event, masks the interrupt,
clears the event, and schedules a workqueue. The workqueue is run, it
empties the FIFO, and unmasks the interrupt.In the above sequence, after the event is cleared, it immediately
retriggers since the FIFO remains beyond the threshold. When the IRQ is
unmasked, this triggered event generates another IRQ. However, as the
FIFO has just been emptied, it is likely to not contain enough samples.The waits to clear the event until the FIFO has actually been emptied,
in the workqueue. The unmasking and masking of the interrupt remains
unchanged.Signed-off-by: Russ Dill
-
If an overrun occurs, the threshold event is meaningless, handle
the overrun event first.Signed-off-by: Russ Dill
-
The driver is currently mishandling the IRQSTATUS register by peforming
a read/update/write cycle. The actual functionality of the register is as follows:Write 0 = No action.
Read 0 = No (enabled) event pending.
Read 1 = Event pending.
Write 1 = Clear (raw) event.By reading the status and writing it back, the driver is clearing
all pending events, not just the one indicated in the bitmask.Signed-off-by: Russ Dill
-
The driver is currently mishandling the IRQENABLE register. The driver
should write a 1 for bits it wishes to set, and a zero for bits it does not
wish to change. The read of the current register contents is not
necessary.Write 0 = No action.
Read 0 = Interrupt disabled (masked).
Read 1 = Interrupt enabled.
Write 1 = Enable interrupt.The current read/update/write method is currently not causing any
problems, but could cause confusion in the future.Signed-off-by: Russ Dill
07 Mar, 2013
1 commit
-
The current code does not enable all the input channels asked for.
For example if we want to read continuous data from 3 channels at a
time, the code only enables one channel.
Also the step configuration while switching from one shot to continuous,
configured the 1st input to the rest of the channels as well.
Hence in continuous mode voltage from 1st channel appears on all
the remaining channels. Fix the issue by configuring to correct input
channels.Signed-off-by: Patil, Rachna
Signed-off-by: Vaibhav Hiremath
01 Mar, 2013
9 commits
-
Touchscreen once enabled in standby needs to be disabled again.
Writing 0x02 will only re-enable touchscreen. Fix the same by writing
0x00 to the registers.Signed-off-by: Patil, Rachna
-
Since TSC is configured to use FIFO 0 to store the touch data,
enable FIFO 0 underflow and overflow interrupts, so that all states of
FIFO can be addressed.Signed-off-by: Patil, Rachna
-
Handle wakeup from TSC where in we could have data pending In FIFO
which needs to be flushed out.
Also make sure that we don't have any interrupts pending due to wakeup
from TSC.Signed-off-by: Patil, Rachna
-
The MFD device has 2 fifo's FIFO0 and FIFO1.
Previously these FIFO's were shared between touchscreen and ADC.
This led to a situation were in while using TSC, ADC interrupts were
also getting generated. Ideally this should not be the condition.
Hence TSC now has been updated to use FIFO 0 only to store touchscreen
samples.
By this we can even make sure that data between the clients is not lost
and corrupted.Signed-off-by: Patil, Rachna
-
The remove module and the error return path missed checks for buffer
management. Add the same in ADC driver.Signed-off-by: Patil, Rachna
-
ADC is ideally expected to work at a frequency of 3MHz.
The present code had a check, which returned error if the frequency
went below the threshold value. But since AM335x supports various
working frequencies, this check is not required.
Now the code just uses the internal ADC clock divider to set the ADC
frequency w.r.t the sys clock.Signed-off-by: Patil, Rachna
-
This line was added during debug, missed removing
fifo1count variable. Update the code.Signed-off-by: Patil, Rachna
-
The code did not have context save done on IRQ register bits
for the MFD device.
Also the control register bits after resume were loaded to the
default value. Now changes have been made to save both IRQ and control
register bits in MFD core.
In ADC client the mode in which ADC is operating has to store,
hence modify the step_config function to pass the current mode.Signed-off-by: Patil, Rachna
-
Since IRQ is a part of continuous mode feature, Enabling should also
take place when continuous data is asked for.
In default mode ADC is configured as one shot, IRQ need not be enabled
if one wants to use one shot mode only.Signed-off-by: Patil, Rachna
28 Feb, 2013
2 commits
-
The timer TISTAT register is a read-only register and therefore restoring the
context is not needed. Furthermore, the context of TISTAT is never saved
anywhere in the current code. The TISTAT register is read-only for all OMAP
devices from OMAP1 to OMAP4. OMAP5 timers no longer have this register.[akshay.s@ti.com: Observed a crash when adding support for the
DMTIMER wakeup for standby mode.
This crash occurred during context restore when restoring values
to TIOCP_CFG and TISTAT registers in the function
omap_timer_restore_context().
This issue was fixed in the mainline. So backporting it to fix the same]Signed-off-by: Jon Hunter
Acked-by: Santosh Shilimkar
Signed-off-by: ShankarMurthy, Akshay
Signed-off-by: Satyanarayana Sandhya -
Since hwmod framework now manages sysconfig context save/restore
there is no more need to touch this register in driver. Hence,
remove restore of sysconfig register in omap_timer_restore_context.
This was causing incorrect context restore of sysconfig register.[akshay.s@ti.com: Observed a warning when adding support for the
DMTIMER wakeup for standby mode.WARNING: at arch/arm/plat-omap/dmtimer.c:77
omap_dm_timer_write_reg+0x6c/0x74()This issue was fixed in the mainline. So backporting this patch
to fix the same]Signed-off-by: Tarun Kanti DebBarma
Acked-by: Santosh Shilimkar
Acked-by: Kevin Hilman
Signed-off-by: Tony Lindgren
Signed-off-by: ShankarMurthy, Akshay
Signed-off-by: Satyanarayana Sandhya
22 Feb, 2013
13 commits
-
Wakeup from standby mode is supported via GPIO method where peripherals
can be configured as gpios while entering standby and wakeup happens
through gpio interrupt.This patch provides an method to handle the same through a debugfs
approach.User should know the IO pads to be configured and the trigger value to
be written to them. The PAD offset & gpio configuration depends mainly
on the wake-up source selected.Inside /omap_mux/board/ (Directory where these
features are available)standby_gpio_pad_conf
standby_gpio_pad_conf
Expected input: pinmux_name=,
Pin-mux name that is to be setup as gpio during standby
suspend with gpio interrupt trigger mode as per field
with value .
Pin-mux name should be in "mode0_name.mode7_function_name"
format. Internally the pin-mux offset is calculated from the
pin-mux names. Invalid pin-mux names and values are ignored.
Remember,
- No spaces anywhere in the input.
- field is a must
- field is a must and must be one of "rising",
"falling"Example:
echo uart0_rxd.gpio1_10=0x27,rising > standby_gpio_pad_conf
sets up uart0_rxd.gpio1_10 for gpio mode with interrupt trigger
as rising and pin-mux value as 0x27 when entering standby mode.During standby, If "standby_gpio_pad_conf" is configured, then the
respective pin-mux value is saved, the gpio pin-mux mode is selected
for the pin. Relevant gpio settings & interrupts are configured.
During resume, the original values saved are restored back.User should make sure that the mux mode exists for the selected pin-mux
and the trigger is proper.When here a duplicate header include (linux/io.h> is removed
Signed-off-by: Hebbar Gururaja
-
Keep GPIO0 module enabled during standby to support
GPIO0 io-pads to wakeup the system from standby mode.Signed-off-by: Satyanarayana Sandhya
-
This patch enables touch screen wakeup from standby by keeping
TSC module enabled during standby.Signed-off-by: Satyanarayana Sandhya
-
This patch adds support for USB remote wakeup from standby mode.
This has been tested as below.
- Connect a USB mouse to EVM.
- Run the following two commands
echo enabled > /sys/bus/usb/devices/1-1/power/wakeup
echo enabled > /sys/bus/usb/devices/usb1/power/wakeup
- Run "echo standby > /sys/power/state"
- Click the mouse to resume from standby
- Also tested for a keyboard key press.Suggested-by: Vaibhav Bedia
Signed-off-by: Satyanarayana Sandhya -
This patch adds basic support for Standby mode
wherein SDRAM is placed in self-refresh,
PLLs are put in bypass and MPU is power gated.
GFX power domain is under user control,
PER power domain is ON.Wakeup happens via MPU_WAKE interrupt to Cortex-M3.
To enter standby mode, run
"echo standby > /sys/power/state"Wakeup from standby mode is through gpio.
Signed-off-by: Satyanarayana Sandhya
-
The ADC driver did not check for FIFO1 underflow and overrun
conditions. Add support to handle these conditions.
TSC/ADC module does not recover from this state by itself,
a module reset is required.Signed-off-by: Patil, Rachna
-
ADC reports few wrong/erroneous data on read in continuous mode.
Providing an appropriate delay so that ADC has sufficient time to
sequence data present on the input channel.Signed-off-by: Patil, Rachna
-
This patch adds context loss related platform data for mcasp.
This allows mcasp driver to check for the loss of context depending upon
the status it will decide whether to restore or not.Signed-off-by: ShankarMurthy, Akshay
-
Context restore is not required when there is no loss of context which
is the case with standby.This patch adds support to check for loss of context and context restore
is done if there has been a loss of context.This reduces the overall resume latency of Standby.
Signed-off-by: ShankarMurthy, Akshay
-
This patch adds context loss related platform data for lcd.
This allows lcd driver to check for the loss of context and
depending upon the status it will decide whether to restore or not.Signed-off-by: ShankarMurthy, Akshay
-
Context restore is not required when there is no loss of context which is
the case with standby.This patch adds support for lcd to check for loss of context and
context restore is done if there has been a loss of context.This reduces the overall resume latency of Standby approximately by
15ms.Signed-off-by: ShankarMurthy, Akshay
-
This patch adds context loss related platform data for USB.
This allows USB driver to check for the loss of context and
depending upon the status it will decide whether to restore or not.Signed-off-by: Satyanarayana Sandhya
Signed-off-by: ShankarMurthy, Akshay -
Context restore is not required when there is no loss of context which
is the case with standby.This patch adds support to check for loss of context and context restore
is done if there has been a loss of context.This reduces the overall resume latency of Standby approximately by
200ms.Signed-off-by: Satyanarayana Sandhya
Signed-off-by: ShankarMurthy, Akshay
18 Feb, 2013
1 commit
-
The commit #793ba3e7 moved setting MUSB_CSR0 register out of
musb_load_testpacket(), which breaks generating test packet
through debugfs.So added the MUSB_CSR0 setting in debugfs.
Signed-off-by: Bin Liu
Signed-off-by: Ravi Babu
13 Feb, 2013
1 commit
-
Under heavy load (flood ping) it is possible for the MDIO timeout to
expire before the loop checks the GO bit again. This patch adds an
additional check whether the operation was done before actually
returning -ETIMEDOUT.To reproduce this bug, flood ping the device, e.g., ping -f -l 1000
After some time, a "timed out waiting for user access" warning
may appear. And even worse, link may go down since the PHY reported a
timeout.Signed-off-by: Christian Riesch
Cc:
Cc: Cyril Chemparathy
Signed-off-by: David S. Miller
Signed-off-by: Mugunthan V N
12 Feb, 2013
3 commits
-
sd injects and synchronizes probe work on the global kernel-wide domain.
This runs into conflict with PM that wants to perform resume actions in
async context:[ 494.237079] INFO: task kworker/u:3:554 blocked for more than 120 seconds.
[ 494.294396] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 494.360809] kworker/u:3 D 0000000000000000 0 554 2 0x00000000
[ 494.420739] ffff88012e4d3af0 0000000000000046 ffff88013200c160 ffff88012e4d3fd8
[ 494.484392] ffff88012e4d3fd8 0000000000012500 ffff8801394ea0b0 ffff88013200c160
[ 494.548038] ffff88012e4d3ae0 00000000000001e3 ffffffff81a249e0 ffff8801321c5398
[ 494.611685] Call Trace:
[ 494.632649] [] schedule+0x5a/0x5c
[ 494.674687] [] async_synchronize_cookie_domain+0xb6/0x112
[ 494.734177] [] ? __init_waitqueue_head+0x50/0x50
[ 494.787134] [] ? scsi_remove_target+0x48/0x48
[ 494.837900] [] async_synchronize_cookie+0x15/0x17
[ 494.891567] [] async_synchronize_full+0x54/0x70 ] ? async_synchronize_full_domain+0x1a/0x1a
[ 495.002547] [] sd_remove+0x2c/0xa2 [sd_mod]
[ 495.051861] [] __device_release_driver+0x86/0xcf
[ 495.104807] [] device_release_driver+0x25/0x32 ] schedule+0x5a/0x5c
[ 853.949670] [] __mutex_lock_common+0x220/0x351
[ 854.001225] [] ? device_resume+0x58/0x1c4
[ 854.049082] [] ? device_resume+0x58/0x1c4
[ 854.097011] [] mutex_lock_nested+0x2f/0x36 ] device_resume+0x58/0x1c4
[ 854.192066] [] async_resume+0x1e/0x45
[ 854.237019] [] async_run_entry_fn+0xc6/0x173
[alan: uplevel scsi_sd_probe_domain, clarify scsi_device_resume]
Signed-off-by: Dan Williams
[jejb: remove unneeded config guards in include file]
Signed-off-by: James Bottomley -
This patch (as1520) fixes a bug in the SCSI layer's power management
implementation.LUN scanning can be carried out asynchronously in do_scan_async(), and
sd uses an asynchronous thread for the time-consuming parts of disk
probing in sd_probe_async(). Currently nothing coordinates these
async threads with system sleep transitions; they can and do attempt
to continue scanning/probing SCSI devices even after the host adapter
has been suspended. As one might expect, the outcome is not ideal.This is what the "prepare" stage of system suspend was created for.
After the prepare callback has been called for a host, target, or
device, drivers are not allowed to register any children underneath
them. Currently the SCSI prepare callback is not implemented; this
patch rectifies that omission.For SCSI hosts, the prepare routine calls scsi_complete_async_scans()
to wait until async scanning is finished. It might be slightly more
efficient to wait only until the host in question has been scanned,
but there's currently no way to do that. Besides, during a sleep
transition we will ultimately have to wait until all the host scanning
has finished anyway.For SCSI devices, the prepare routine calls async_synchronize_full()
to wait until sd probing is finished. The routine does nothing for
SCSI targets, because asynchronous target scanning is done only as
part of host scanning.Signed-off-by: Alan Stern
CC:
Signed-off-by: James Bottomley -
If MUSB is in peripheral mode system suspend is not allowed if connected
to USB HOST. The suspend should be initiated from USB HOST side.Signed-off-by: George Cherian
