14 Jun, 2013
3 commits
-
Recent commit from Greg (OPP Table fix for 720MHZ and ZCE
support) added OPP120 support for PG 2.x.OPP120 support needs to be disabled when the board is booted and
running at OPP50. This is as per the Advisory 1.0.15 (ARM Cortex-A8:
OPP50 Operation on MPU Domain Not Supported)Voltage checked here are Core Voltage and not MPU. Hence, When here
correct the preprocessors to indicate correct voltages.As per Sitara AM335x ARM Cortex -A8 Microprocessors (MPUs) data sheet
(SPRS717F) APRIL 2013 available at
http://www.ti.com/lit/ds/symlink/am3359.pdfTable 3-7 and 3-9 has been updated to show the defined OPPs on ZCZ and
ZCE packages respectivelySigned-off-by: Hebbar Gururaja
-
Current OPP table excludes 720MHz OPPs for ES 2.0 and ES 2.1. It also
excludes an 300MHz at 1.1V operating point required for ZCE support on
ES 2.1.
This patch implements support for the same.As per Sitara AM335x ARM Cortex -A8 Microprocessors (MPUs) data sheet
(SPRS717F) APRIL 2013 available at
http://www.ti.com/lit/ds/symlink/am3359.pdfTable 3-7 and 3-9 has been updated to show the defined OPPs on ZCZ and
ZCE packages respectively[ Hebbar Gururaja]:
- Add Link to Documentation and reference table.
- Fix merge issue and remove whitespace warningSigned-off-by: Greg Guyotte
Signed-off-by: Hebbar Gururaja -
After random iteration, uart standby using (gpio pin configs) hangs.
Upon deep observation (and lots of debug prints), it was observed that
the GPIO Rising/Falling detect registers were cleared (IRQ disabled)
before system entered standby. Any UART activity (key press) was not
detected.This registers were properly setup by request_irq call from
am33xx_pm_prepare_late() (initial suspend stage).However, driver suspend calls (.suspend()) come in later stage and due
to some race condition, gpio_mask_irq() masks/clears above registers.The fix is to call the standby setup function (which calls request_irq)
at final stage just before the actual suspend call.This fix was tested by placing the system under standby stress test for
more than 20 Hours.Signed-off-by: Hebbar Gururaja
05 Jun, 2013
2 commits
-
Add OPP table for MPU voltage domain.
Changes from PG2.0:
1. The Operating voltage for Nitro Mode is 1.35V
2. PG 2.1 SoC has a new efuse sma register which describes the device's
ARM maximum frequency capabilities and package type. Upon parsing this
register, the supported maximum frequency is obtained.
Note:
If this register is not populated (mpu max freq field is 0), then we
revert back to PG 2.0 OPP list.Signed-off-by: Hebbar Gururaja
-
This reverts commit ee9dfd8d729d3e7b5ce9e404a0e87f27f6f79135.
This patch checks for the package type for checking the supported opp
bits & also if the bits are set, the opp table is updated.
However, checking package type bit is not required & also, the opp bit
checking must be reversed.A fix for the same will follow after this commit
29 May, 2013
2 commits
-
As per Advisory 1.0.15 (ARM Cortex-A8: OPP50 Operation on MPU Domain Not
Supported), when the board is booted with OPP50, reliable operation is
not guaranteed for OPP greater than OPP100 (OPP120, TURBO, NITRO).So, Check if the board is booted at OPP50 voltage & if yes, disable
higher OPP (OPP120, TURBO, NITRO).Signed-off-by: Hebbar Gururaja
-
Add OPP table for MPU voltage domain.
Changes from PG2.0:
1. The Operating voltage for Nitro Mode is 1.35v
2. PG 2.1 SoC has a new efuse sma register which describes the device's
ARM maximum frequency capabilities and package type. Upon parsing this
register, the supported maximum frequency is obtained.
Note:
If this register is not populated or the data is invalid (package type),
then we revert back to PG 2.0 OPP list.Signed-off-by: Hebbar Gururaja
02 May, 2013
1 commit
-
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer
registers after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode
(TSICR [2].POSTED=1), due to internal resynchronizations, values read in
TCRR, TCAR1 and TCAR2 registers right after the timer interface clock
(L4) goes from stopped to active may not return the expected values. The
most common event leading to this situation occurs upon wake up from
idle.GPTimer non-posted synchronization mode is not impacted by this
limitation.Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock
domain
3). Use no-idle mode when the timer is activeWorkarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU
overhead for configuring and reading the timers as the CPU has to wait
for accesses to be re-synchronised within the timer. However, disabling
posted mode guarantees correct operation.Please note that it is safe to use posted mode for timers if the counter
(TCRR) and capture (TCARx) registers will never be read. An example of
this is the clock-event system timer. This is used by the kernel to
schedule events however, the timers counter is never read and capture
registers are not used. Given that the kernel configures this timer
often yet never reads the counter register it is safe to enable posted
mode in this case. Hence, for the timer used for kernel clock-events,
posted mode is enabled by overriding the errata for devices that are
impacted by this defect.For drivers using the timers that do not read the counter or capture
registers and wish to use posted mode, can override the errata and
enable posted mode by making the following function calls.__omap_dm_timer_override_errata(timer, OMAP_TIMER_ERRATA_I103_I767);
__omap_dm_timer_enable_posted(timer);Both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver
does not read the counter register and so no workaround is necessary.Posted mode will be disabled for all OMAP2+ devices (including AM33xx)
using a GP timer as a clock-source timer to guarantee correct operation.
This is not necessary for OMAP24xx devices but the default clock-source
timer for OMAP24xx devices is the 32k-sync timer and not the GP timer
and so should not have any impact. This should be re-visited for future
devices if this errata is fixed.Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx
devices.Signed-off-by: Jon Hunter
Acked-by: Santosh Shilimkar
[hvaibhav@ti.com: Backported to v3.2 PSP kernel, also merged
commit 7b44cf2c15f (ARM: OMAP: Fix timer posted mode support)]
Signed-off-by: Vaibhav Hiremath
26 Apr, 2013
3 commits
-
In DMA mode, when the data is received from host before the next request
is programmed, the pio interrupt occurs and data lost since no request.This scenario occurs sometimes in android gadget, when adb protocol receive
bigger size (>4KB) files.The fix is not to disable the dma after completion of current rx request
so that dma interrupt will occur correctly for next request
when data received from host before next request is programmed.Signed-off-by: Ravi Babu
-
fixes the missing declaration for manufacturer & vendorID
for multi gadget configurationSigned-off-by: Ravi Babu
-
- bug fixes for schedular table add_(remove) channel API's
- adds the sched_tbl_control flag to add/remove channel dynamically.
- This fixes the g_multi gadget issue.Signed-off-by: Ravi Babu
17 Apr, 2013
1 commit
-
This adds the function for AM335x SGX device registration using HWMOD APIs.
Also added is omap_device handle creation for SGX module.
This is required for supporting pm_runtime APIs in SGX driver.
This patch is required for 3.2 kernel only.Signed-off-by: Prathap M S
16 Apr, 2013
2 commits
-
Add support for rtc wakeup from standby by keeping RTC module
enabled during standby.RTC wakeup is corrected in the PG2.0 and hence it is supported
only on PG2.x boards.To test RTC wakeup use below command:
@ rtcwake -d /dev/rtc0 -m standby -s 5Signed-off-by: Vaibhav Hiremath
-
Add support for chip id detection of AM335x PG2.1 Silicon.
Currently omap3xxx_check_revision() detects PG1.0 and PG2.0,
so this patch extends it by adding PG2.1 Si support.Signed-off-by: Vaibhav Hiremath
04 Apr, 2013
12 commits
-
Currently coupld of instances where code checks only for
PG2.0, which requires change when we add PG2.1 Si support.So change the condition check from '==' to '>='.
Signed-off-by: Vaibhav Hiremath
-
The ADC needs to go through a proper initialization sequence after
resuming from suspend.Signed-off-by: Russ Dill
-
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
2 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
