Commit 6d803ba736 (ARM: 6483/1: arm & sh:
factorised duplicated clkdev.c) caused the following warnings:
In file included from /home/headless/src/kernel.org/linux-davinci/arch/arm/
include/asm/clkdev.h:17,
from include/linux/clkdev.h:15,
from arch/arm/mach-davinci/clock.h:71,
from arch/arm/mach-davinci/common.c:22:
arch/arm/mach-davinci/include/mach/clkdev.h:4: warning: `struct clk' declared
inside parameter list
arch/arm/mach-davinci/include/mach/clkdev.h:4: warning: its scope is only this
definition or declaration, which is probably not what you want
arch/arm/mach-davinci/include/mach/clkdev.h:9: warning: `struct clk' declared
inside parameter list
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
For DMA operation, the davinci spi driver needs an event queue number.
Currently, this number is passed as a IORESOURCE_DMA. This is not
correct, as the event queue is not a DMA channel. Pass the event queue
via the platform data structure instead.
On dm355 and dm365, move the eventq assignment for spi0 out of resources
array and into platform data.
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Kevin Hilman <khilman@ti.com>
The da850 uart pinmux arrays are not used. Remove them.
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
The da850_mmcsd0_pins pinmux array contains pins that are specific to the
da850 evm board (the write protect and card detect GPIO pins). Move
the array to the board file.
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
The da850_mcasp_pins pinmux array is specific to the da850_evm, and is
not generic. Move the array to the board file, make it static initdata,
and rename it accordingly.
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
The da850_emif25_pins pinmux array is not used. Remove it.
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
The da850_cpgmac_pins pinmux array is not used. Remove it.
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
For the MityDSP-L138/MityARM-1808 SoMs, the speed grade can be determined
from the part number string read from the factory configuration block on
the on-board I2C PROM. Configure the maximum CPU speed based on this
information.
This patch was tested using a MityDSP-L138 and MityARM-1808 at various
speedgrades. Also, for code coverage, a bogus configuration was tested
as well as a configuration having an unknown part number.
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Michael Williamson <michael.williamson@criticallink.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
From: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
The JTAG variant code for Rev-2.0 silicon of the OMAP-L138 has changed.
In addition, the variant code for the AM-1808 SoC appears to match
the Rev-2.0 code for the OMAP-L138. Add an additional entry to support
these chips.
This patch is originally from a patch on the arago project, here:
http://arago-project.org/git/projects/?p=linux-omapl1.git;a=commit;h=6157618435e313a444cdf059702bd34036a6e2b7
Further information related to the need for this patch can be located at
http://e2e.ti.com/support/embedded/f/354/p/67290/248486.aspxhttp://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-November/021224.html
This patch was tested using an AM-1808 SoC on a MityARM-1808 SoM card. It
was also tested using a Rev 1.0 silicon OMAP-L138 on a MityDSP-L138F card.
Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Michael Williamson <michael.williamson@criticallink.com>
Tested-by: Michael Williamson <michael.williamson@criticallink.com>
Reported-by: Nicolas Luna <luna.id@gmail.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This patch adds USB1.1 support for the Hawkboard-L138 system
Signed-off-by: Victor Rodriguez <vm.rod25@gmail.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This patch adds USB1.1 and USB2.0 clocks for the Hawkboard-L138 system
Signed-off-by: Victor Rodriguez <vm.rod25@gmail.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This patch adds MMC/SD support for the Hawkboard-L138 system
Signed-off-by: Victor Rodriguez <vm.rod25@gmail.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This patch defines Pin Mux configuration to enable MMC/SD
and USB-OHCI on the Hawkboard-L138 system
Signed-off-by: Victor Rodriguez <vm.rod25@gmail.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This patch adds EDMA support for the Hawkboard-L138 system
Signed-off-by: Victor Rodriguez <vm.rod25@gmail.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This patch adds EMAC support for the Hawkboard-L138 system
Signed-off-by: Victor Rodriguez <vm.rod25@gmail.com>
Tested-by: Rene Gonzalez <renegs.2378@gmail.com>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This patch fix a bug in the register indexing for GPIOs numbers > 31
to get the relevant hardware registers of tnetv107x to control the GPIOs.
In the structure tnetv107x_gpio_regs:
struct tnetv107x_gpio_regs {
u32 idver;
u32 data_in[3];
u32 data_out[3];
u32 direction[3];
u32 enable[3];
};
The GPIO hardware register addresses of tnetv107x are stored.
The chip implements 3 registers of each entity to serve 96 GPIOs,
each register provides a subset of 32 GPIOs.
The driver provides these macros: gpio_reg_set_bit, gpio_reg_get_bit
and gpio_reg_clear_bit.
The bug implied the use of macros to access the relevant hardware
register e.g. the driver code used the macro like this:
'gpio_reg_clear_bit(®->data_out, gpio)'
But it has to be used like this:
'gpio_reg_clear_bit(reg->data_out, gpio)'.
The different results are shown here:
- ®->data_out + 1 (it will add the full array size of data_out i.e. 12 bytes)
- reg->data_out + 1 (it will increment only the size of data_out i.e. only 4 bytes)
Acked-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Hirosh Dabui <hirosh.dabui@snom.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
After the multi-component commit f0fba2ad (ASoC: multi-component - ASoC
Multi-Component Support) for ASoC, we need to register the platform
device for davinci-pcm-audio.
This patch and patch at [1] are required for audio to work on
DA850/OMAP-L138.
[1] https://patchwork.kernel.org/patch/495211/
Signed-off-by: Rajashekhara, Sudhakar <sudhakar.raj@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This uncouple PHYS_OFFSET from the platform definitions, thereby
facilitating run-time computation of the physical memory offset.
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@st.com>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Magnus Damm <damm@opensource.se>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Wan ZongShun <mcuos.com@gmail.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Acked-by: Jiandong Zheng <jdzheng@broadcom.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
In d7e81c2 (clocksource: Add clocksource_register_hz/khz interface) new
interfaces were added which simplify (and optimize) the selection of the
divisor shift/mult constants. Switch over to using this new interface.
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Tested-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Apart from the regular AM18x/DA850/OMAP-L138 SoC operating
at 300MHz, these SoCs have variants that can operate at a
maximum of 456MHz. Variants at 408Mhz and 375 Mhz are available
as well.
Not all silicon is qualified to run at higher speeds and
unfortunately the maximum speed the chip can support can only
be determined from the label on the package (not software
readable).
The EVM hardware for all these variants is the same (except
for the actual SoC populated).
U-Boot on the EVM sets up ATAG_REVISION to inform the OS
regarding the speed grade supported by the silicon. We use
this information to pass on the speed grade information to
the SoC code.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
AM18x/DA850/OMAP-L138 SoCs have variants that can operate
at a maximum of 456 MHz at 1.3V operating point. Also the
1.2V operating point has a variant that can support a maximum
of 375 MHz.
This patch adds three new OPPs (456 MHz, 408 MHz and 372 MHz)
to the list of DA850 OPPs.
Not all silicon is qualified to run at higher speeds and
unfortunately the maximum speed the chip can support can only
be determined from the label on the package (not software
readable).
Because of this, we depend on the maximum speed grade information
to be provided to us in some board specific way. The board informs
the maximum speed grade information by setting the da850_max_speed
variable.
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Use the mach-davinci/Kconfig to enable gpio-keys-polled as default when
da850-evm machine is enabled.
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
CC: Kevin Hilman <khilman@deeprootsystems.com>
CC: "Nori, Sekhar" <nsekhar@ti.com>
CC: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch adds a pca953x platform device for the tca6416 found on the evm
baseboard. The tca6416 is a GPIO expander, also found on the UI board at a
separate I2C address. The pins of the baseboard IO expander are connected to
software reset, deep sleep enable, test points, a push button, DIP switches and
LEDs.
Add support for the push button, DIP switches and LEDs and test points (as
free GPIOs). The reset and deep sleep enable connections are reserved by the
setup routine so that userspace can't toggle those lines.
The existing tca6416-keypad driver was not employed because there was no
apararent way to register the LEDs connected to gpio's on the tca6416 while
simultaneously registering the tca6416-keypad instance.
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
Reviewed-by: Chris Cordahi <christophercordahi@nanometrics.ca>
CC: Govindarajan, Sriramakrishnan <srk@ti.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
The setup and teardown methods of the UI expander reference the SEL_{A,B,C}
pins by 'magic number' in each function. This uses the common enum for their offsets
in the expander setup and teardown functions.
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
Reviewed-by: Chris Cordahi <christophercordahi@nanometrics.ca>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
CC: Victor Rodriguez <vm.rod25@gmail.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch adds EV_KEYs for each of the 8 pushbuttons on the UI board via a
gpio-key device.
The expander is a tca6416; it controls the SEL_{A,B,C} lines which enable and
disable the peripherals found on the UI board in addition to the 8 pushbuttons
mentioned above. The reason the existing tca6416-keypad driver is not employed
is because there was no aparent way to keep the gpio lines used as
SEL_{A,B,C} registered while simultaneously registering the pushbuttons as a
tca6416-keypad instance.
Some experimentation with the polling interval was performed; we were searching
for the largest polling interval that did not affect the feel of the
responsiveness of the buttons. It is very subjective but 200ms seems to be a
good value that accepts firm pushes but rejects very light ones. The key values
assigned to the buttons were arbitrarily chosen to be F1-F8.
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
Reviewed-by: Chris Cordahi <christophercordahi@nanometrics.ca>
CC: Govindarajan, Sriramakrishnan <srk@ti.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
CC: Kevin Hilman <khilman@deeprootsystems.com>
CC: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Commit fcf173e451 (usb: musb: add names for IRQs
in structure resource) forgot to assign name to the DA8xx MUSB IRQ resource.
Because of that MUSB driver fails to load on DA8xx machines.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Ensure that the at24 eeprom driver is selected for certain boards that
need boot data (e.g. MAC address) from EEPROM.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
There was a single case of 'da850evm' prefix in the board-da850-evm.c file
where the reset of the prefixes were 'da850_evm'; change it to 'da850_evm' for
consistency.
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Change the mach-davinci Kconfig file so that GPIO_PCA953X is default when
MACH_DAVINCI_DA850_EVM is set instead of always selecting. This allows users
to compile pca953x as a module.
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
CC: Sergei Shtylyov <sshtylyov@mvista.com>
CC: Nori, Sekhar <nsekhar@ti.com>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
When the RMII PHY on the UI board is enabled with CONFIG_DA850_UI_RMII
then then following will be printed to the console when warnings are
also enabled:
WARNING: at drivers/gpio/gpiolib.c:1567 __gpio_set_value+0x4c/0x5c()
Modules linked in:
[<c002c6ac>] (unwind_backtrace+0x0/0xf8) from [<c003b48c>] (warn_slowpath_common+0x4c/0x64)
[<c003b48c>] (warn_slowpath_common+0x4c/0x64) from [<c003b4c0>] (warn_slowpath_null+0x1c/0x24)
[<c003b4c0>] (warn_slowpath_null+0x1c/0x24) from [<c01aed60>] (__gpio_set_value+0x4c/0x5c)
[<c01aed60>] (__gpio_set_value+0x4c/0x5c) from [<c0033bd4>] (da850_evm_ui_expander_setup+0x1e4/0x2
44)
[<c0033bd4>] (da850_evm_ui_expander_setup+0x1e4/0x244) from [<c02e2e1c>] (pca953x_probe+0x1f8/0x29
0)
<snip>
Traced the WARN_ON to the gpio_set_value(rmii_sel,0) call in
da850_evm_setup_emac_rmii. Replacing the call with the _cansleep variant
results in no more warning. Also replacing the gpio_set_value calls in the
teardown function.
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
Reviewed-by: Chris Cordahi <christophercordahi@nanometrics.ca>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
aemif_calc_rate() can return a negative error value, so all the
variables that get tested for this value need to be signed.
The maximum bit width of WSETUP(WSETUP_MAX) appears to be 30 bits
(0xf << 26). Using a signed instead of an unsigned integer
shouldn't make a difference here.
Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
A common do-while loop can be factored out from the end of
the branches.
Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch applies the following modifications to the tnetv107x clock tree:
- reparent tnetv107x usb clocks to usbss
- mark timer1 as always enabled
- enable set_rate on pll divider output clocks
- adjust tnetv107x tsc sysclk rate lower to fix invalid reset defaults
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
This patch modifies the sysclk rate setting code to use the divider mask
specified in pll_data. Without this, devices with different divider ranges
(e.g. tnetv107x) fail.
Signed-off-by: Cyril Chemparathy <cyril@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Overwrite the default implementation of sched_clock that is based on
jiffies by something more precise. This improves timestamps in ftrace.
Implementation is copied from OMAP platform code.
Signed-off-by: Andreas Gaeer <Andreas.Gaer@baslerweb.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Just adding its own platform_driver, not really
using it yet.
When all HW glue layers are converted, more patches
will come to split power management code from musb_core
and move it completely to HW glue layer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Just adding its own platform_driver, not really
using it yet.
When all HW glue layers are converted, more patches
will come to split power management code from musb_core
and move it completely to HW glue layer.
Signed-off-by: Felipe Balbi <balbi@ti.com>
change all ocurrences of musb_hdrc to musb-hdrc.
We will call glue layer drivers musb-<glue layer>,
so in order to keep things somewhat standard, let's
change the underscore into a dash.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Defining iounmap() with arguments prevents it from being used as a
function pointer, causing platforms to work around this. Instead,
define it to be a simple macro.
Do the same for __arch_io(re|un)map too.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Soon resource data will get automatically
populated from a set of autogenerated data
from TI's hardware database for the OMAP
platform.
Such database, might not have resources at
the expected order by the current drivers.
While we could hack in some exceptions to
that tool to generate resources in a specific
order, it seems less fragile to use the
resource name instead. That way, no matter
what order the resources are generated, the
driver still work.
Modified the OMAP, Blackfin and Davinci
architecture files to add the name of the IRQs
in the resource structures and musb driver to
use the platform_get_irq_byname() api to get
the device and dma irq numbers instead of using
the index.
Cc: Tony Lindgren <tony@atomide.com>
Acked-by: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Hema HK <hemahk@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
factorise some generic infrastructure to assist looking up struct clks
for the ARM & SH architecture.
as the code is identical at 99%
put the arch specific code for allocation as example in asm/clkdev.h
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add comments describing the platform data members
and per-chip-select SPI configuration structure.
Also, add some comments describing the what happens
during the driver probe.
Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The "clk_internal" platform data member which contols the
CLKMOD bit in Global Control Register 1 is not useful
since CLKMOD needs be set to 1 *always* to ensure master
mode operation.
Remove this platform data.
Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Let DMA operation be specified on a per-device basis instead
of selecting it once during probe.
A side effect of this is the need to combine the PIO and DMA buffer
txrx_bufs routine. This is good since they anyway share some common
functionality.
Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Do not allocate (and de-allocate) SPI DMA channels during setup
(and cleanup) for each SPI device. Instead, allocate the DMA
channels once duing probe and use them for the life time of
the driver.
This makes sense since there are dedicated DMA channels meant
for SPI use.
This also helps remove the unnecessary DMA "sync_dev" variables
being used to store DMA channel information.
Also, the "use_dma" platform variable is now eliminated since
it is possible to check if the platform supports DMA or not
based upon whether DMA resources can be found or not.
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Tested-By: Brian Niebuhr <bniebuhr@efjohnson.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Due to the full duplex nature of the SPI bus, the SPI master
on DaVinci needs transmit to be active even if the tranfer is
only meant to collect receive data.
The current code achieves this by using a temporary zeroed buffer
to provide DMA data in case the transfer does not have a transmit
buffer provided.
However, the transmit DMA is started only if transmit buffer is
provided rendering the temporary buffer unused. Instead the code
relies on a write to SPIDAT1 register to trigger transmit operation.
This however only sends two bytes of data.
Fix this by starting transmit DMA always.
This changes exposes a bug on DM355 where the CSHOLD bit in
SPIDAT1 needs to be written to in between transfers. Handle
that by introducing a "cshold_bug" platform data which is
set to true for DM355.
Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Add support for SPI interrupt mode operation.
Define a per chip-select "io type" variable which
specifies if the transfers on this chip-select should
happen in interrupt mode or polled mode.
Introduce a new function davinci_spi_process_events()
to help consolidate the code between interrupt mode
processing and polled mode processing.
Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The interrupt mode support as it stands is another version
of poll mode. Even when interrupt mode is selected, the code
tight loops on interrupt status register, rendering it totally
useless. A completion variable is initialized, but never used.
Remove this fake interrupt mode since users can anyway use
poll mode with no functional difference. A usefully implemented
interrupt mode support can be added later.
Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Just enabling WAITENA in SPIFMTn register waits for the
enable signal from the slave indefinitely. Allow support
for finite waiting by adding support for c2e delay
(maximum time for addressed slave to respond) and t2e
delay (maximum time for slave to respond after transmit
data finished).
While at it, modify the T2C and C2T defines by prepending
the register name as is the convention followed for other
register field elsewhere in the driver.
Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com>
Tested-By: Michael Williamson <michael.williamson@criticallink.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Sergei Shtylyov