IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Only few members of struct mpc8xxx_spi are relevant for fsl-espi.
Therefore replace it with a ESPI-specific struct fsl_espi.
Replace variable names mpc8xxx_spi and mspi with espi.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The register initialization is the same in fsl_espi_probe and in
of_fsl_espi_resume. Therefore factor it out into fsl_espi_init_regs.
It was actually a bug that CSMODE_BEF and CSMODE_AFT were not set
in of_fsl_espi_resume. Seems like nobody ever used values other
than zero for these parameters.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Very little from struct spi_mpc8xxx_cs is relevant for fsl-espi.
Therefore replace it with struct fsl_espi_cs.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Very little of the library functions mpc8xxx_spi_probe and
of_mpc8xxx_spi_probe is relevant for fsl-espi.
Therefore migrate the relevant parts to fsl-espi (considering
that get_brgfreq() always returns -1 on systems with ESPI)
and remove use of these functions.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There's no need to access mpc8xxx_spi->irq, we can use function
parameter irq directly.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Change the check to access property "mode" directly.
This allows us to get rid of mpc8xxx_spi->flags in a subsequent
patch in this patch series as it's used nowhere else.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use master->num_chipselect directly instead of pdata->max_chipselect.
In this context let of_fsl_espi_get_chipselects return max_chipselect.
This change allows us to get rid of struct fsl_spi_platform_data
completely in the fsl-espi driver.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Don't set pdata->cs_control as it's nowhere used in fsl-espi and fsl-lib.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove pdata->initial_spmode as it is nowhere set.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for dual output read mode.
It was successfully tested on a P1014-based device with S25FL128S
SPINOR flash. With 50MHz SPI clock the read rate is 11MByte/s.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for ESPI RXSKIP mode. This mode is optimized
for flash reads:
- sends a number of bytes and then reads a number of bytes
- shifts out zeros automatically when reading
Supporting RXSKIP mode is a prerequisite for supporting dual output
read mode.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver only has runtime but no build time dependency with PLAT_SAMSUNG
|| ARCH_EXYNOS so it can be built for testing purposes if the COMPILE_TEST
option is enabled.
This is useful to have more build coverage and make sure that the driver
is not affected by changes that could cause build regressions.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The newly introduced rspi_pio_transfer_in_or_our() function must
take either a valid 'rx' or 'tx' pointer, and has undefined behavior
if both are NULL, as found by 'gcc -Wmaybe-unintialized':
drivers/spi/spi-rspi.c: In function 'rspi_pio_transfer_in_or_our':
drivers/spi/spi-rspi.c:558:5: error: 'len' may be used uninitialized in this function [-Werror=maybe-uninitialized]
The analysis of the function is correct in principle, but the code
is currently safe because both callers always pass exactly one
of the two pointers.
Looking closer at this function shows that having a combined
method for rx and tx here actually increases the complexity
and the size of the file. This simplifies it again by keeping
the two separate, which then ends up avoiding that warning.
Fixes: 3be09bec42a8 ("spi: rspi: supports 32bytes buffer for DUAL and QUAD")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use the managed gpio CS pin request so that we avoid having trouble
in the cleanup code.
In fact, if module was configured with DT, cleanup code released
invalid pin. Since resource wasn't freed, module cannot be reinserted.
This require to extract the gpio request call from the "setup" function
and call it in the appropriate probe function.
Reported-by: Alexander Morozov <linux@meltdown.ru>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
There's no need to bother the chip if the mode doesn't change.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Resetting the chip to a default transfer mode after each transfer
doesn't provide any benefit. Therefore remove this call.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch supports 32bytes of buffer for DUAL and QUAD in QSPI by
Using Transmit/Receive Buffer Data Triggering Number.
In order to improve the DUAL and QUAD's performance of SPI
while transferring data in PIO mode, it sends/receives each 32bytes
data instead of each byte data as current situation.
Signed-off-by: Hiep Cao Minh <cm-hiep@jinso.co.jp>
Signed-off-by: Mark Brown <broonie@kernel.org>
H3 has two SPI controllers. The size of the buffer is 64 * 8.
(8 bit transfer by 64 entry FIFO)
A31 has four controllers. The size of the buffer is 128 * 8.
(8 bit transfer by 128 entry FIFO)
Register maps are sharable, so sun6i SPI driver is reusable with
device configuration.
Use the variable, 'fifo_depth' instead of fixed value to support both SPI
controllers.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Introduce additional output parameter in spi_imx_clkdiv_1()
function to return result frequency and set it to spi_bus_clk.
This fixes division by zero bug, which occurred in
spi_imx_calculate_timeout() function.
Signed-off-by: Robert Baldyga <r.baldyga@hackerion.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Once dspi is used in uboot, the SPI_SR have been set by some value.
At this time, if kernel enable the interrupt before clear the
status flag, that will trigger the wrong interrupt.
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
SPI transfers were limited to one FIFO depth, which is 64 bytes.
This was an artificial limitation, however, as the hardware can handle
much larger bursts. To accommodate this, we enable the interrupt when
the Rx FIFO is 3/4 full, and drain the FIFO within the interrupt
handler. The 3/4 ratio was chosen arbitrarily, with the intention to
reduce the potential number of interrupts.
Since the SUN4I_CTL_TP bit is set, the hardware will pause
transmission whenever the FIFO is full, so there is no risk of losing
data if we can't service the interrupt in time.
For the Tx side, enable and use the Tx FIFO 3/4 empty interrupt to
replenish the FIFO on large SPI bursts. This requires more care in
when the interrupt is left enabled, as this interrupt will continually
trigger when the FIFO is less than 1/4 full, even though we
acknowledge it.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Olliver Schinagl <o.schinagl@ultimaker.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
According to NXP ESPI datasheet, the SPI clock rate is:
spi_clk = System_Clock / ( 2 * DIV16 * ( 1 + PM ) )
Where System_Clock is the platform clock divided by 2,
DIV16 may be 1 or 16, and PM is a 4 bits integer (0 to 15).
Isolating PM on the expression, we get:
PM = (System_Clock / ( 2 * DIV16 * spi_clk ) ) - 1
Where System_Clock = mpc8xxx_spi->spibrg / 2, spi_clk = hz,
and DIV16 = 1 or DIV16 = 16. So,
PM = (mpc8xxx_spi->spibrg / ( 4 * hz) ) - 1
or
PM = (mpc8xxx_spi->spibrg / ( 16 * 4 * hz) ) - 1
Current spi-fsl-espi driver can't configure the HW for all
supported clock rates. It filters out clock rates for PM = 0
and PM = 1.
This patch allows all range of supported clock rates to be
configured on the ESPI controller.
Signed-off-by: Paulo Zaneti <paulo.zaneti@datacom.ind.br>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
spin_lock is used to obtain the spinlock, so spin_unlock
has to be used here.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently the driver polls in the ISR for enough bytes in the RX FIFO.
An ISR should never do this.
Change it to read as much as possible whenever the ISR is called.
This also allows to significantly simplify the code.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
So far an interrupt is triggered whenever there's at least one byte
in the RX FIFO. This results in a unnecessarily high number of
interrupts.
Change this to generate an interrupt if
- RX FIFO is half full (except if all bytes to read fit into the
RX FIFO anyway)
- end of transfer has been reached
This way the number of interrupts can be significantly reduced.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Extend and improve transfer error handling
- in case of timeout report also number of remaining rx bytes
- in case of timeout return ETIMEDOUT instead of EMSGSIZE
- add sanity checks after all bytes have been sent / read:
- check that HW has flag SPIE_DON set
- check that RX / TX FIFO are empty
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The ESPI spec mentions no requirement to turn off the ESPI unit prior
to changing the mode. Most likely the ESPI unit is only turned off to
clear the FIFO's as before this patch series single bytes could
remain in the TX FIFO after transfer end.
Therefore remove disabling / re-enabling the ESPI unit.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Now that we introduced element tx_len in struct mpc8xxx_spi let's
rename element len to rx_len as it actually is the number of bytes to
receive. In addition make it unsigned.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This change addresses two issues:
- If the TX FIFO is full the ISR polls until there's free space again.
An ISR should never wait for something.
- Currently the number of bytes to transfer is rounded up to the next
multiple of 4. For most transfers therefore few bytes remain in the
TX FIFO after end of transfer.
This would cause the next transfer to fail and as a workaround the
ESPI block is disabled / re-enabled in fsl_espi_change_mode.
This seems to clear the FIFO's (although it's not mentioned in the
spec).
With this change the TX FIFO is filled as much as possible initially
and whenever the ISR is called. Also the exact number of bytes is
transferred.
The spinlock protects against a potential race if the first interrupt
occurs whilst the TX FIFO is still being initially filled.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
SPI_QE_CPU_MODE doesn't exist for ESPI and is set by of_mpc8xxx_spi_probe
based on DT property "mode". This property is not defined for ESPI,
see Documentation/devicetree/bindings/spi/fsl-spi.txt.
So print an error message and bail out if SPI_QE_CPU_MODE is set.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 5c0ba57744b1 ("spi: fsl-espi: avoid processing uninitalized
data on error") applied fine to stable but caused a merge conflict
on next. This patch fixes that.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The spi_transfer parameter delay_usecs allows specifying a time to wait
after transferring a spi message. This wait can be quite long - some
devices, such as some Chrome OS ECs, require as much as 2000 usecs after
a SPI transaction, before it can respond.
(cf: arch/arm64/boot/dts/nvidia/tegra132-norrin.dts:
google,cros-ec-spi-msg-delay = <2000>
)
Blocking a CPU for 2 msecs in a busy loop like this doesn't seem very
friendly to other processes, so change the blocking delay to a sleep
to allow other things to use this CPU (or so it can sleep).
This should be safe to do, because:
(a) A post-transaction delay like this is always specified as a minimum
wait time
(b) A delay here is most likely not very time sensitive, as it occurs
after all data has been transferred
(c) This delay occurs in a non-critical section of the spi worker thread
so where it is safe to sleep.
Two caveats:
1) To avoid penalizing short delays, still use udelay for delays < 10us.
2) usleep_range() very often picks the upper bound, an upper bounds 10%
should be plenty.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When we get a spurious interrupt in fsl_espi_irq, we end up
processing four uninitalized bytes of data, as shown in this
warning message:
drivers/spi/spi-fsl-espi.c: In function 'fsl_espi_irq':
drivers/spi/spi-fsl-espi.c:462:4: warning: 'rx_data' may be used uninitialized in this function [-Wmaybe-uninitialized]
This adds another check so we skip the data in this case.
Fixes: 6319a68011b8 ("spi/fsl-espi: avoid infinite loops on fsl_espi_cpu_irq()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Instantiated SPI device nodes are marked with OF_POPULATE. This was
introduced in bd6c164. On unloading, loaded device nodes will of course
be unmarked. The problem are nodes that fail during initialisation: If a
node fails, it won't be unloaded and hence not be unmarked.
If a SPI driver module is unloaded and reloaded, it will skip nodes that
failed before.
Skip device nodes that are already populated and mark them only in case
of success.
Note that the same issue exists for I2C.
Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer <ralf@ramses-pyramidenbau.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Support DMA transfers on imx35 and compatible chipsets (imx31, imx25).
If DMA can be used, set the start mode control (SMC) bit to start the
SPI burst as soon as data is written into the tx fifo. Configure DMA
requests when the fifo is half empty during tx or half full during rx.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove unneeded error handling on the result of a call
to platform_get_resource() when the value is passed to
devm_ioremap_resource().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Entries are needed in the spidev ID list to configure configure it from a
device tree. Add entry for the following device:
- "ge,achc" : GE Healthcare USB Management Controller
The USB Management Controller does not expose USB to the host, but acts as
an offload engine, communicating with specific USB based data acquisition
devices which are connected to it, extracting the required data and
providing it to the host via other methods. SPI is used as an out-of-band
configuration channel.
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
currently during probe the resource data gets modified and device
physical address remains valid only during first load. If the module is
unloaded and loaded again, the ioremp will be done on a incorrect address
as the resource was modified during previous module load.
This patch fixes this issue.
Signed-off-by: Vikram N <vicky773@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The code in fsl_espi_tx_buf_lsb and parts of fsl_espi_setup_transfer
look very weird and don't reflect the ESPI spec.
ESPI stores values with <= 8 bit word size right justified as 8 bit
value and values with > 8 bit word size right justified as 16 bit
value. Therefore no such shifting is needed.
Only case MSB-first with 8 bit word size is correctly handled,
and most likely nobody ever used this driver with a different config.
On ESPI only the case LSB-first with word size > 8 bit needs a
special handling. In this case a little endian 16 bit value has
to be written to the TX FIFO what requires a byte swap as the
host system is big endian.
The same applies to reading from the RX FIFO.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
According to the ESPI spec MSB-first transfers are supported for
word size 8 and 16 only.
Check for this and reject MSB-first transfers with other word sizes.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
of_property_read_u32 is better here than generic of_get_property:
- implicit endianness conversion if needed
- implicit checking of size of property
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some SPI masters require slave selection before the transfer
can begin [1]. The SPI framework currently selects the chip using
either 1) the internal CS mechanism or 2) the GPIO CS, but not both.
This patch adds a new master->flags define to indicate both the GPIO
CS and the internal chip select mechanism should be used.
Tested On:
Altera CycloneV development kit
Compile tested for build errors on x86_64 (allyesconfigs)
[1] DesignWare dw_apb_ssi Databook, Version 3.20a (page 39)
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
A good practice is to prefix the names of functions by the name
of the subsystem.
The kthread worker API is a mix of classic kthreads and workqueues. Each
worker has a dedicated kthread. It runs a generic function that process
queued works. It is implemented as part of the kthread subsystem.
This patch renames the existing kthread worker API to use
the corresponding name from the workqueues API prefixed by
kthread_:
__init_kthread_worker() -> __kthread_init_worker()
init_kthread_worker() -> kthread_init_worker()
init_kthread_work() -> kthread_init_work()
insert_kthread_work() -> kthread_insert_work()
queue_kthread_work() -> kthread_queue_work()
flush_kthread_work() -> kthread_flush_work()
flush_kthread_worker() -> kthread_flush_worker()
Note that the names of DEFINE_KTHREAD_WORK*() macros stay
as they are. It is common that the "DEFINE_" prefix has
precedence over the subsystem names.
Note that INIT() macros and init() functions use different
naming scheme. There is no good solution. There are several
reasons for this solution:
+ "init" in the function names stands for the verb "initialize"
aka "initialize worker". While "INIT" in the macro names
stands for the noun "INITIALIZER" aka "worker initializer".
+ INIT() macros are used only in DEFINE() macros
+ init() functions are used close to the other kthread()
functions. It looks much better if all the functions
use the same scheme.
+ There will be also kthread_destroy_worker() that will
be used close to kthread_cancel_work(). It is related
to the init() function. Again it looks better if all
functions use the same naming scheme.
+ there are several precedents for such init() function
names, e.g. amd_iommu_init_device(), free_area_init_node(),
jump_label_init_type(), regmap_init_mmio_clk(),
+ It is not an argument but it was inconsistent even before.
[arnd@arndb.de: fix linux-next merge conflict]
Link: http://lkml.kernel.org/r/20160908135724.1311726-1-arnd@arndb.de
Link: http://lkml.kernel.org/r/1470754545-17632-3-git-send-email-pmladek@suse.com
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Borislav Petkov <bp@suse.de>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Designware SPI master requires slave selection before the transfer
can begin [1].
This patch uses the new master flag to indicate both the GPIO CS and
the internal chip select should be used.
Tested On:
Altera CycloneV development kit
Compile tested for build errors on x86_64 (allyesconfigs)
[1] DesignWare dw_apb_ssi Databook, Version 3.20a (page 39)
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Some SPI masters require slave selection before the transfer
can begin [1]. The SPI framework currently selects the chip using
either 1) the internal CS mechanism or 2) the GPIO CS, but not both.
This patch adds a new master->flags define to indicate both the GPIO
CS and the internal chip select mechanism should be used.
Tested On:
Altera CycloneV development kit
Compile tested for build errors on x86_64 (allyesconfigs)
[1] DesignWare dw_apb_ssi Databook, Version 3.20a (page 39)
Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
