Some masters may have different DMA burst size than hard coded default.
In such case respect the value given by DMA burst size provided via
platform data.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When the commit b6ced294fb
("spi: pxa2xx: Switch to SPI core DMA mapping functionality")
switches to SPI core provided DMA helpers, it missed to setup maximum
supported DMA transfer length for the controller and thus users
mistakenly try to send more data than supported with the following
warning:
ili9341 spi-PRP0001:01: DMA disabled for transfer length 153600 greater than 65536
Setup maximum supported DMA transfer length in order to make users know
the limit.
Fixes: b6ced294fb ("spi: pxa2xx: Switch to SPI core DMA mapping functionality")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
It's also a slave controller driver now, calling it "master" is slightly
misleading.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
There doesn't seem to be a way to empty TXFIFO on MMP2. The datasheet is
super-secret and the method described in Armada 16x manual won't work:
"The TXFIFO and RXFIFO are cleared to 0b0 when the SSPx port is reset or
disabled (by writing a 0b0 to the <Synchronous Serial Port Enable> field
in the SSP Control Register 0)."
# devmem 0xd4037008 # read SSSR
0x0000F204
# devmem 0xd4037000 32 0x07 # SSE off in SSCR0
# devmem 0xd4037000 32 0x87 # SSE on
# devmem 0xd4037008
0x0000F204
^ TXFIFO level is still 2. Sigh.
The OLPC 1.75 boot firmware leaves two bytes in the TXFIFO. Those are
basically throwaway bytes used in response to the messages from the EC.
The OLPC kernel copes with this by power-cycling the hardware. Perhaps
the firmware should do this instead.
Other than that, there's not much we can do other than complain loudly
until the garbage gets drained and discard the actual data... For the
OLPC EC this will work just fine and pushing more data to TXFIFO would
break further transactions.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Mark Brown <broonie@kernel.org>
Strobe a GPIO line when the slave TX FIFO is filled. This is how the
Embedded Controller on an OLPC XO-1.75 machine, that happens to be a SPI
master, learns that it can initiate a transaction.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Tested-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Mark Brown <broonie@kernel.org>
Tested on an OLPC XO-1.75 machine, where the Embedded Controller happens
to be a SPI master.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Mark Brown <broonie@kernel.org>
Intel LPSS private register restoring in spi-pxa2xx.c: pxa2xx_spi_resume()
was added before there was no any other code restoring them. This was
changed after following commits for previous and current LPSS platforms:
c78b083066 ("ACPI / LPSS: custom power domain for LPSS")
41a3da2b8e ("mfd: intel-lpss: Save register context on suspend")
However there is one caveat: There is no LPSS private register context
save/restore for the Intel Lynxpoint in the Linux kernel code.
I did some debugging on one Lynxpoint based device I have and on it the
LPSS register context is not lost over suspend/resume cycle (s2idle).
Which happens for instance on Intel Braswell. I'm speculating but I guess
either firmware does it or the LPSS is kept always on Lynxpoint.
Given that we haven't needed to implement Lynxpoint LPSS I2C or UART
private register context save/restore over four years time I think we are
safe to remove this LPSS private register restoring during resume here.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The MMP2 platform, that uses device tree, has this controller. Let's add
devicetree alongside platform & PCI.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Rewrite switch code block to directly do the expected number
of shifts in each case and have break statements.
Addresses-Coverity-ID: 1056539 ("Missing break in switch")
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It makes no sense to remove the device on shutdown. And it break things
when the hardware crucial for shutdown (such as the embedded controller)
is attached to the SPI bus.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Mark Brown <broonie@kernel.org>
spi_controller_{suspend,resume}() already prints an error message on
failure, so there is no need to repeat this in individual drivers.
Note: spi_master_{suspend,resume}() is an alias for
spi_controller_{suspend,resume}().
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Daniel Mack <daniel@zonque.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Intel Ice Lake SPI host controller follows the Intel Cannon Lake but the
PCI IDs are different. Add the new PCI IDs to the driver supported
devices list.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
clk_prepare_enable() can fail, so its return value should be checked and
acted upon.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 3343b7a6d2 ("spi/pxa2xx: convert to the common clk framework")
Signed-off-by: Tobias Jordan <Tobias.Jordan@elektrobit.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Convert the pump_transfers() transfer tasklet to transfer_one() hook the
SPI core calls to process single transfer instead of handling message
processing and chip select handling in the driver. This not only
simplifies the driver but also brings transfer statistics from the core.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We are going to rename and modify pump_transfers(). Prepare for it by
removing the string "pump_transfers:" from error and warning prints.
While at it make these user-visible strings single line in sources as it
helps source grepping from error reports.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Current DMA engine implementation of pxa2xx_spi_dma_prepare() don't use
the dma_burst argument. Remove it since it became unused after
commit 6356437e65 ("spi: spi-pxa2xx: remove legacy PXA DMA bits").
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Don't leave runtime PM enabled in case devm_spi_register_controller()
returns with an error. Otherwise runtime PM will complain when driver is
reloaded:
[ 693.855811] pxa2xx-spi pxa2xx-spi.13: Unbalanced pm_runtime_enable!
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Convert to generalized SPI controller API introduced by the
commit 8caab75fd2 ("spi: Generalize SPI "master" to "controller"").
Inside driver variable name "master" is still used to indicate the driver
is master only.
While at it, change "unsigned cs" to "unsigned int cs" in
pxa2xx_spi_fw_translate_cs() to suppress checkpatch warning.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Move SSP idle waiting before CS deassert from error and end of message
handling function giveback() to cs_deassert(). This ensures idle waiting
is done also if there is CS change between transfers.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
gpiod_free() is an internal function for gpiolib, gpiod_put() is the
correct external function.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
gpio_free(gpio) simply does gpiod_free(gpio_to_desc(gpio)), so it's
simpler and cleaner to use gpiod_free directly.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Mark Brown <broonie@kernel.org>
We still need to request/free GPIOs passed via the legacy path of
pxa2xx_spi_chip::gpio_cs, but we can use the gpiod API otherwise.
Consistently use the descriptor API instead of the legacy one.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
GPIO descriptors, when being requested, may configure pin at the same
time. In case of SPI chip select we shouldn't do any assumptions of the
state of pin since we don't know yet what chip is connected there and if
it uses high or low active state. So, leave the state of pin as is until
transfer will start.
Fixes: 99f499cd65 ("spi: pxa2xx: Add support for GPIO descriptor chip selects")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westeberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a valid case to call setup() following by setup_cs() several
times for the same chip.
With the commit
676a4e3bab ("spi: pxa2xx: Only claim CS GPIOs when the slave device is created")
it is not possible anymore due to GPIO line being requested already
during the first call to setup_cs().
For now, revert the commit to make things work again.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Avoid hogging chip select GPIOs just because they are listed for the
master. They might be mulitplexed and, if no slave device is attached,
used for different purposes. Moreover, this strategy avoids having to
allocate a cs_gpiods structure.
Tested on the IOT2000 where the second SPI bus is connected to an
Arduino-compatible connector and multiplexed between SPI, GPIO and PWM
usage.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Intel Cannonlake LPSS SPI has up to four chip selects per port like in
Broxton and is clocked like Sunrisepoint and Kaby Lake. Add a new type
LPSS_CNL_SSP and configuration that enable runtime chip select detection
and use the same FIFO thresholds than in Sunrisepoint.
Patch adds support for both Cannonlake SoC and PCH.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
When using the a device with edge-triggered interrupts, such as MSIs,
the interrupt handler has to ensure that there is a point in time during
its execution where all interrupts sources are silent so that a new
event can trigger a new interrupt again.
This is achieved here by disabling all interrupt sources for a moment
before processing them according to the status register. If a new
interrupt should have arrived after we read the status, it will now
re-trigger the interrupt, even in edge mode.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Gemini Lake reuses the same LPSS SPI configuration as Broxton
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As suggested by Andy Shevchenko: Decouple this corner cause from the
general handling logic in ssp_int.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The commit 7c7289a404 ("spi: pxa2xx: Default thresholds to PXA
configuration") while splitting up CE4100 code obviously missed a break
condition in one chunk. Add it here.
Looks like we have no active user of CE4100, though better to fix this later
than never.
Fixes: commit 7c7289a404 ("spi: pxa2xx: Default thresholds to PXA configuration")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Kbuild test robot reports:
drivers/spi/spi-pxa2xx.c: In function ‘setup_cs’:
drivers/spi/spi-pxa2xx.c:1190:20: error: implicit declaration of function ‘desc_to_gpio’
...
Reason for this is the fact that those functions are declared in
linux/gpio/consumer.h which is not included in the driver. Fix this by
including it.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver uses custom chip_info coming from platform data for chip selects
implemented as GPIOs. If the system lacks board files setting up the
platform data, it is not possible to use GPIOs as chip selects.
This adds support for GPIO descriptors so that regardless of the underlying
firmware interface (DT, ACPI or platform data) the driver can request GPIOs
used as chip selects and configure them accordingly.
The custom chip_info GPIO support is still left there to make sure the
existing systems keep working as expected.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Most of the devices in the supported list have PXA configuration of FIFO. In
particularly Intel Medfield and Merrifield have bigger FIFO, than it's defined
for CE4100.
Split CE4100 in the similar way how it was done for Intel Quark, i.e. prefix
definitions by CE4100 and append necessary pieces of code to switch case
conditions.
We are on safe side since those bits are ignored on all LPSS IPs.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Transfer state machine in this driver does not need to set/unset pointer
to chip data between queueing and finalizing message as it is not
actually used as a state info itself but just pointer passing.
Since this per SPI device specific chip data is already carried in
ctldata use that and remove pointer to chip data from driver data.
While at it, group initialized variables before uninitialized variables
in pump_transfers().
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no need to carry pointer to current SPI message in driver data
because cur_msg in struct spi_master holds it already when driver is using
the message queueing infrastructure from the SPI core.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
All of these variables are unconditionally set before their use.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
It seems the commit e5262d0568 ("spi: spi-pxa2xx: SPI support for Intel Quark
X1000") misses one place to be adapted for Intel Quark, i.e. in reset_sccr1().
Clear all RFT bits when call reset_sccr1() on Intel Quark.
Fixes: e5262d0568 ("spi: spi-pxa2xx: SPI support for Intel Quark X1000")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Kaby Lake PCH-H has the same SPI host controller as Skylake. Add these new
PCI IDs to the list of supported devices.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
SPI core provides DMA mapping with scatterlists. Start using it instead
of own implementation in spi-pxa2xx. Major difference in addition to
bunch of removed boilerplate code is that SPI core does
mapping/unmapping for all transfers in a message before and after the
message sending where spi-pxa2xx did mapping/unmapping for each
transfers separately.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We will find more use for struct spi_master pointer in pump_transfers()
and code will be more readable if we access it using local pointer than
through the drv_data->master.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently, even if the PXA2xx SPI master supports DMA, it won't be
enabled unless (i) the slave device is enumerated through ACPI, or
(ii) the slave device is registered with board-specific
controller_data specified. Even then, there isn't a field in the
controller_data that explicitly enables dma - it just gets enabled
if the master supports it and controller_data is non-NULL.
This means that drivers which register SPI devices on a bus without
awareness of this controller cannot avail of DMA performance gains.
This patch allows DMA transfers to be used if supported.
Signed-off-by: Dan O'Donovan <dan@emutex.com>
Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Certain Intel Sunrisepoint PCH variants report zero chip selects in SPI
capabilities register even they have one per port. Detection in
pxa2xx_spi_probe() sets master->num_chipselect to 0 leading to -EINVAL
from spi_register_master() where chip select count is validated.
Fix this by not using SPI capabilities register on Sunrisepoint. They don't
have more than one chip select so use the default value 1 instead of
detection.
Fixes: 8b136baa58 ("spi: pxa2xx: Detect number of enabled Intel LPSS SPI chip select signals")
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Fix cs_change management so that it is in line with other spi drivers.
In the spi core api helpers such as spi_bus_lock/unlock and spi_sync_locked
or cs_change field in spi_transfer help to manage chip select from the
device driver.
The driver was setting the chip select to idle if the message queue was
empty despite cs_change or other status field set by spi_bus_lock/unlock
or spi_sync_locked.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Dummy buffer is used for half duplex transfers that don't have TX or RX
buffer set. Instead of own dummy buffer management here let the SPI core to
handle it by setting the SPI_MASTER_MUST_RX and SPI_MASTER_MUST_TX flags.
Then core makes sure both transfer buffers are set.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If by some reason pxa2xx_spi_dma_prepare() fails we have not to ignore its
error. In such case we abort the transfer and return the error to upper
level.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
[Jarkko: Avoid leaking TX descriptors in case RX descriptor allocation
fails. Noted by Robert Jarzmik <robert.jarzmik@free.fr>.
Unmap also buffers in case of failure.]
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for third Intel Broxton variant and update comment for
A-Step variant.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Steve Sakoman <steve.sakoman@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Only legacy PXA DMA implementation was using these rx_dma and tx_dma DMA
addresses so they are not needed after commit 6356437e65
("spi: spi-pxa2xx: remove legacy PXA DMA bits").
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Intel Braswell LPSS SPI controller actually has two chip selects and there
is no capabilities register where this could be found out. These two chip
selects are controlled by bits which are in slightly differrent location
than Broxton has.
Braswell Windows driver also starts chip select (ACPI DeviceSelection)
numbering from 1 so translate it to be suitable for Linux as well.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some Intel LPSS SPI controllers, like the one in Braswell has these bits in
a different location so move these bits to be part of the LPSS
configuration.
Since not all LPSS SPI controllers support multiple native chip selects we
refactor selecting chip select to its own function and check
control->cs_sel_mask before switching to another chip select.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The Windows Baytrail SPI host controller driver uses 1 as the first (and
only) value for ACPI DeviceSelection like can be seen in DSDT taken from
Lenovo Thinkpad 10:
Device (FPNT)
{
...
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (UBUF, ResourceTemplate ()
{
SpiSerialBus (0x0001, // DeviceSelection
PolarityLow, FourWireMode, 0x08,
ControllerInitiated, 0x007A1200, ClockPolarityLow,
ClockPhaseFirst, "\\_SB.SPI1",
0x00, ResourceConsumer,,)
This will fail to enumerate in Linux with following error:
[ 0.241296] pxa2xx-spi 80860F0E:00: cs1 >= max 1
[ 0.241312] spi_master spi32766: failed to add SPI device VFSI6101:00 from ACPI
To make the Linux SPI core successfully enumerate the device we provide a
custom version of ->fw_translate_cs() that translates DeviceSelection
correctly.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a chance that chipselect is deasserted too early while the last
clock cycle is still running. Protocol analyzers will see this as a failed
last byte. This is more likely to occur with slow bitrates, for instance
at 25 kbps.
Reason for this is when using SPI mode 0 that both SPI host controller and
SPI slave will drive the data lines at the falling edge of clock signal
and sample at the rising edge. Receive FIFO gets the last bit now at the
rising edge and code sees transfer to be finished either by the interrupt
in PIO mode or by the DMA completion in DMA mode.
The SSP Time Out register SSTO should take care of delaying the
completion but it does not seems to have effect at least on Intel
Skylake and Broxton even when using long enough values. Depending on
timing code may get into point where chipselect is deasserted while the
last clock cycle is still running at its second half cycle.
Fix this by adding a wait loop in giveback() that waits until SSP becomes
idle before deasserting the chipselect.
Reported-by: Weifeng Voon <weifeng.voon@intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The register writes here actually don't stop the SSP but clean and
disable interrupts and set the receive FIFO inactivity timeout to zero.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Transfer debug messages don't actually show is the transfer really using
DMA. Driver may fall back to PIO in case transfer size is not within the
certain limits or fails to map DMA buffers but debug messages don't reveal
that.
Move these debug messages further in pump_transfers() where the actual
transfer mode is known and use drv_data->dma_mapped flag instead of
chip->enable_dma for printing the mode.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 8b136baa58 ("spi: pxa2xx: Detect number of enabled Intel LPSS SPI
chip select signals") added a block where lpss_ssp_setup() gets called
again for Intel LPSS SPI host controllers before checking number of chip
selects from the capabilities register.
There is no point in calling the function twice in probe so remove the
first call.
Reported-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Extend the pxa2xx_spi_acpi_get_pdata() so that it can create platform data
also on platforms that do not support ACPI or if CONFIG_ACPI is not set.
Now it is expected that "pxa2xx-spi" platform device is either created with
explicit platform data or has an ACPI companion device.
However there is only little in pxa2xx_spi_acpi_get_pdata() that is really
dependent on ACPI companion and it can be reworked to cover also cases
where "pxa2xx-spi" device doesn't have ACPI companion and is created
without platform data.
Do this by renaming the pxa2xx_spi_acpi_get_pdata(), moving it outside of
CONFIG_ACPI test and changing a few runtime tests there to support non-ACPI
case. Only port/bus ID setting based on ACPI _UID is dependent on ACPI and
is moved to own function inside CONFIG_ACPI.
Purpose of this to support non-ACPI case for those PCI enumerated compound
devices that integrate both LPSS SPI host controller and integrated DMA
engine under the same PCI ID and which are registered in MFD layer instead
of in spi-pxa2xx-pci.c.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
LPSS SPI in Intel Broxton is otherwise the same than in Intel Sunrisepoint
but it supports up to four chip selects per port and has different FIFO
thresholds. Patch adds support for two Broxton SoC variants.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
SPI capabilities register located in private registers space of newer
Intel LPSS SPI host controllers tell in register bits 12:9 which chip
select signals are enabled.
Use that information for detecting the number of chip selects. For
simplicity we assume chip selects are enabled one after another without
disabled chip selects between. For instance CS0 | CS1 | CS2 but not
CS0 | CS1 | CS3.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Intel LPSS SPI host controllers in upcoming Intel platforms can have up
to 4 chip selects per port. Extend chip select control in
lpss_ssp_cs_control() by adding a code that selects the active chip
select output prior to changing the state. Detection for number of
enabled chip select signals will be added by another patch.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Rename a few defines that are specific to Intel LPSS SPI private
registers with LPSS prefix. It makes easier to distinguish them from
common defines.
Suggested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add more indentation to define lines for making them aligned with the
longest one. They would look messy after adding more long defines.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Upcoming Intel platforms use LPSS SPI_CS_CONTROL register bits 15:12 for
configuring the chip select polarities. Touch only chip select SW mode and
state bits when enabling the software chip select control in order to not
clear any other bits in the register.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Andy noticed numeric unique device ID is unsigned integer so convert it
using kstrtouint(). Actually integer in ACPI 2.0 and later is 64 bits
litte-endian unsigned integer but quite certainly having so big value here
would mean something extra than just the SPI bus number so it won't hurt to
assume only lower 32 bits carry the bus number for now.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Since we call pxa2xx_ssp_get_clk_div() from pump_transfers() we may derive
pointer to struct chip_data from struct drv_data like it's done in the rest
of the functions. This will make it less errorprone.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The speed can be changed from transfer to transfer, that's why the messages
do not depict the actual values during ->setup(). Move debug messages from
->setup() to pump_transfers(). Get rid of leftovers as well.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
As per discussion [1] the best choice is to set closest speed which is not
going over the asked one.
Do the same approach for Intel Quark boards.
[1] http://www.spinics.net/lists/linux-spi/msg03389.html
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This was leftover from the legacy pxa2xx DMA implementation and not needed
anymore so remove it.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Get pointer to the struct acpi_device by using ACPI_COMPANION() macro. This
is more efficient than using ACPI_HANDLE() and acpi_bus_get_device().
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Carry input clock of the controller in max_speed_hz of struct spi_master
instead of in own driver data. They mean the same thing and more over now
the max_speed_hz is not even set here.
As an added bonus this allows SPI core to validate that transfer speed is
not beyond the maximum input clock. This is not a problem in spi-pxa2xx as
the driver doesn't use transfer speed parameter directly but via input
clock divider calculation which will top at divide by one. However it's
better to validate speed before passing it here.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There hasn't been need to carry chip->cr0 after SPI core started to
validate speed_hz and bits_per_word transfer parameters. That effectively
caused that pump_transfers() always recalculated it and practically
chip->cr0 is used locally in setup() for debug prints only.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This is continuation to previous commit by separating unindentation from
variable removal done in previous commit. As said SPI core have validated
both the speed_hz and bits_per_word and the if statement here evaluates
always to true.
Remove the test and unindent the code block accordingly. While at it remove
also needless "cr0 = chip->cr0" as cr0 will be overwritten anyway and fix
block comment style.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no need to carry spi->max_speed_hz and spi->bits_per_word from
setup() in "struct chip_data" since pump_transfers() will anyway take the
transfer parameters from "struct spi_transfer". This is since SPI core
validates both bits_per_word and speed_hz transfer parameters and defaults
to spi->bits_per_word and spi->max_speed_hz in case these per transfer
parameters are not set.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
On Intel Baytrail, there is case when interrupt handler get called, no SPI
message is captured. The RX FIFO is indeed empty when RX timeout pending
interrupt (SSSR_TINT) happens.
Use the BIOS version where both HSUART and SPI are on the same IRQ. Both
drivers are using IRQF_SHARED when calling the request_irq function. When
running two separate and independent SPI and HSUART application that
generate data traffic on both components, user will see messages like
below on the console:
pxa2xx-spi pxa2xx-spi.0: bad message state in interrupt handler
This commit will fix this by first checking Receiver Time-out Interrupt,
if it is disabled, ignore the request and return without servicing.
Signed-off-by: Tan, Jui Nee <jui.nee.tan@intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Remove null_dma_buf variable and extra allocation for it. It is not needed
since commit 6356437e65 ("spi: spi-pxa2xx: remove legacy PXA DMA bits").
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
These became unused by the commit 6356437e65
("spi: spi-pxa2xx: remove legacy PXA DMA bits").
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Major difference in LPSS SPI between Intel Sunrisepoint PCH and earlier
platforms is an integrated DMA (iDMA) engine. iDMA is an IP that is private
for each LPSS host controller (UART/SPI/I2C). Other differences are private
register space offset, a few private registers that are in different
location and FIFO thresholds.
Intel Sunrisepoint LPSS SPI and iDMA devices are probed and registered in
MFD layer as platform devices. Here these compound devices are detected by
matching against known PCI IDs. This allows us to share
pxa2xx_spi_acpi_get_pdata() for setting up the platform data instead of
duplicating it in MFD part.
This patch adds configuration for Intel Sunrisepoint LPSS SPI, above
detection and DMA filter function that picks the DMA channel only from an
associated iDMA block.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Constify the ACPI device ID array, it doesn't need to be writable at
runtime.
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
General register located in LPSS SPI private register space is not found in
upcoming Intel LPSS platforms. Access it conditionally depending is it
defined in configuration.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some of the Intel LPSS SPI properties will be different in upcoming
platforms compared to existing Lynxpoint and BayTrail/Braswell. LPSS SPI
private registers will be at different offset and there will be changes in
individual registers and default FIFO thresholds too.
Add configuration for these differences and use them in runtime based on
LPSS SSP type. With this change private registers offset autodetection
becomes needless.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Intel LPSS SPI properties differ between between platforms. Now private
registers offset 0x400 or 0x800 is autodetected but there is need to
support also other offset and handle a few other differences.
Prepare for that by splitting the LPSS_SSP type into compatible hardware
types and set it now based on PCI or ACPI ID. That type will be used to set
properties that differ between current and upcoming platforms.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We refactored this code but accidentally left out a break statement so
QUARK_X1000_SSP isn't handled correctly.
Fixes: 025ffe88ee ('spi: pxa2xx: shift clk_div in one place')
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The Quark SoC data sheet describes the baud rate setting using fractional
divider. The subset of possible values represented by a table suggests that the
divisor has one block that could divide by 5. This explains the number of the
beast in some cases in the table. Thus, in this particular case the divisor can
be evaluated as
5^i * 2^j * 2 * k,
where
i = [0, 1]
j = [0, 23]
k = [1, 256]
There are few cases as mentioned in the data sheet, i.e. better form of the
clock signal will be in case if DDS_CLK_RATE either 2^n or 2/5. It's also
possible to use any value that is less or equal to 0x33333 (1/5/16 = 1/80).
All three cases are compared to each other and the one that suits better is
chosen by the approximation algorithm. Anyone can play with the script [1] that
represents the algorithm.
[1] https://gist.github.com/06b084488b3629898121
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch refactors ssp_get_clk_div() and pxa2xx_ssp_get_clk_div() to align
clk_div calculations, i.e. ssp_get_clk_div() and quark_x1000_set_clk_regvals()
will return plain clk_div and it will be shifted to proper position in
pxa2xx_ssp_get_clk_div().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
These asm/io.h, asm/irq.h and asm/delay.h are needless since they are
already included by linux/io.h via drivers/spi/spi-pxa2xx.h,
linux/interrupt.h and linux/delay.h.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 7566bcc76b ("spi: pxa2xx: Move is_lpss_ssp() tests to caller") did
not check LPSS before calling lpss_ssp_setup() in pxa2xx_spi_resume().
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Once the current message is finished, the driver notifies SPI core about
this by calling spi_finalize_current_message(). This function queues next
message to be transferred. If there are more messages in the queue, it is
possible that the driver is asked to transfer the next message at this
point.
When spi_finalize_current_message() returns the driver clears the
drv_data->cur_chip pointer to NULL. The problem is that if the driver
already started the next message clearing drv_data->cur_chip will cause
NULL pointer dereference which crashes the kernel like:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
IP: [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform]
PGD 78bb8067 PUD 37712067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G O 3.18.0-rc4-mjo #5
Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS MNW2CRB1.X64.0071.R30.1408131301 08/13/2014
task: ffff880077f9f290 ti: ffff88007a820000 task.ti: ffff88007a820000
RIP: 0010:[<ffffffffa0022bc8>] [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform]
RSP: 0018:ffff88007a823d08 EFLAGS: 00010202
RAX: 0000000000000008 RBX: ffff8800379a4430 RCX: 0000000000000026
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800379a4430
RBP: ffff88007a823d18 R08: 00000000ffffffff R09: 000000007a9bc65a
R10: 000000000000028f R11: 0000000000000005 R12: ffff880070123e98
R13: ffff880070123de8 R14: 0000000000000100 R15: ffffc90004888000
FS: 0000000000000000(0000) GS:ffff880079a80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000048 CR3: 000000007029b000 CR4: 00000000001007e0
Stack:
ffff88007a823d58 ffff8800379a4430 ffff88007a823d48 ffffffffa0022c89
0000000000000000 ffff8800379a4430 0000000000000000 0000000000000006
ffff88007a823da8 ffffffffa0023be0 ffff88007a823dd8 ffffffff81076204
Call Trace:
[<ffffffffa0022c89>] giveback+0x69/0xa0 [spi_pxa2xx_platform]
[<ffffffffa0023be0>] pump_transfers+0x710/0x740 [spi_pxa2xx_platform]
[<ffffffff81076204>] ? pick_next_task_fair+0x744/0x830
[<ffffffff81049679>] tasklet_action+0xa9/0xe0
[<ffffffff81049a0e>] __do_softirq+0xee/0x280
[<ffffffff81049bc0>] run_ksoftirqd+0x20/0x40
[<ffffffff810646df>] smpboot_thread_fn+0xff/0x1b0
[<ffffffff810645e0>] ? SyS_setgroups+0x150/0x150
[<ffffffff81060f9d>] kthread+0xcd/0xf0
[<ffffffff81060ed0>] ? kthread_create_on_node+0x180/0x180
[<ffffffff8187a82c>] ret_from_fork+0x7c/0xb0
Fix this by clearing drv_data->cur_chip before we call spi_finalize_current_message().
Reported-by: Martin Oldfield <m@mjoldfield.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
