Fix PHY addresses for QSGMII Riser Card working in
SGMII mode on board P3041/P5020/P4080/P5040/B4860.
QSGMII Riser Card can work in SGMII mode, but
having the different PHY addresses.
So the following steps should be done:
1. Confirm whether QSGMII Riser Card is used.
2. If yes, set the proper PHY address.
Generally, the function is_qsgmii_riser_card() is
for step 1, and set_sgmii_phy() for step 2.
However, there are still some special situations,
take P5040 and B4860 as examples, the PHY addresses
need to be changed when serdes protocol is changed,
so it is necessary to confirm the protocol before
setting PHY addresses.
Signed-off-by: Zhao Qiang <B45475@freescale.com>
The patch:
"blackfin: Move blackfin watchdog driver out of the blackfin arch folder."
(sha1: e9a389a184)
changed hw_watchdog_init() prototype which didn't match
with Microblaze one.
This patch fixes the driver and Microblaze initialization.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
If dout buffer is not 32 bit-aligned or data to transmit is not multiple
of 32 bit the read data pointer is already incremented on single byte reads.
Signed-off-by: Timo Herbrecher <t.herbrecher@gateware.de>
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
As the spi flash transfer to multiple parts, it is forgot to add
Atmel AT25DF321 spi flash support, which broken several Atmel EK
boards which this chip. So, add it
Signed-off-by: Bo Shen <voice.shen@atmel.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Added GPL-2.0+ SPDX-License-Identifier for missed sf
source files.
Signed-off-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Signed-off-by: Bo Shen <voice.shen@atmel.com>
The musb driver defines and uses MUSB_CSR0_H_DIS_PING, however this
bit is reserved on the DM36x. Thus this patch ensures that the
reserved bit is not accesssed.
It has been observed that some USB devices will fail to enumerate
with errors such as 'error in inquiry' without this patch.
See http://www.ti.com/litv/pdf/sprufh9a for details.
Cc: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@ti.com>
Signed-off-by: Andrew Murray <amurray@embedded-bits.co.uk>
Acked-by: Marek Vasut <marex@denx.de>
Linux modified the MTD driver interface in commit edbc4540 (with the
same name as this commit). The effect is that calls to mtd_read will
not return -EUCLEAN if the number of ECC-corrected bit errors is below
a certain threshold, which defaults to the strength of the ECC. This
allows -EUCLEAN to stop indicating "some bits were corrected" and begin
indicating "a large number of bits were corrected, the data held in
this region of flash may be lost soon". UBI makes use of this and when
-EUCLEAN is returned from mtd_read it will move data to another block
of flash. Without adopting this interface change UBI on U-boot attempts
to move data between blocks every time a single bit is corrected using
the ECC, which is a very common occurance on some devices.
For some devices where bit errors are common enough, UBI can get stuck
constantly moving data around because each block it attempts to use has
a single bit error. This condition is hit when wear_leveling_worker
attempts to move data from one PEB to another in response to an
-EUCLEAN/UBI_IO_BITFLIPS error. When this happens ubi_eba_copy_leb is
called to perform the data copy, and after the data is written it is
read back to check its validity. If that read returns UBI_IO_BITFLIPS
(in response to an MTD -EUCLEAN) then ubi_eba_copy_leb returns 1 to
wear_leveling worker, which then proceeds to schedule the destination
PEB for erasure. This leads to erase_worker running on the PEB, and
following a successful erase wear_leveling_worker is called which
begins this whole cycle all over again. The end result is that (without
UBI debug output enabled) the boot appears to simply hang whilst in
reality U-boot busily works away at destroying a block of the NAND
flash. Debug output from this situation:
UBI DBG: ensure_wear_leveling: schedule scrubbing
UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 1027
UBI DBG: ubi_io_read: read 4096 bytes from PEB 1027:4096
UBI DBG: ubi_eba_copy_leb: copy LEB 0:0, PEB 1027 to PEB 4083
UBI DBG: ubi_eba_copy_leb: read 1040384 bytes of data
UBI DBG: ubi_io_read: read 1040384 bytes from PEB 1027:8192
UBI: fixable bit-flip detected at PEB 1027
UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 4083
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:4096
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 4083
UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:4096
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:8192
UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:8192
UBI: fixable bit-flip detected at PEB 4083
UBI DBG: schedule_erase: schedule erasure of PEB 4083, EC 55, torture 0
UBI DBG: erase_worker: erase PEB 4083 EC 55
UBI DBG: sync_erase: erase PEB 4083, old EC 55
UBI DBG: do_sync_erase: erase PEB 4083
UBI DBG: sync_erase: erased PEB 4083, new EC 56
UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 4083
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:0
UBI DBG: ensure_wear_leveling: schedule scrubbing
UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
...
This patch adopts the interface change as in Linux commit edbc4540 in
order to avoid such situations. Given that none of the drivers under
drivers/mtd return -EUCLEAN, this should only affect those using
software ECC. I have tested that it works on a board which is
currently out of tree, but which I hope to be able to begin
upstreaming soon.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Acked-by: Stefan Roese <sr@denx.de>
Since SPI register access is so expensive, it is worth transferring data
a word at a time if we can. This complicates the driver unfortunately.
Use the byte-swapping feature to avoid having to convert to/from big
endian in software.
This change increases speed from about 2MB/s to about 4.5MB/s.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Accessing SPI registers is slow, but access to the FIFO level register
in particular seems to be extraordinarily expensive (I measure up to
600ns). Perhaps it is required to synchronise with the SPI byte output
logic which might run at 1/8th of the 40MHz SPI speed (just a guess).
Reduce access to this register by filling up and emptying FIFOs
more completely, rather than just one word each time around the inner
loop.
Since the rxfifo value will now likely be much greater that what we read
before we fill the txfifo, we only fill the txfifo halfway. This is
because if the txfifo is empty, but the rxfifo has data in it, then writing
too much data to the txfifo may overflow the rxfifo as data arrives.
This speeds up SPI flash reading from about 1MB/s to about 2MB/s on snow.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
For devices that need some time to react after a spi transaction
finishes, add the ability to set a delay.
Implement this as a delay on the first/next transaction to avoid
any delay in the fairly common case where a SPI transaction is
followed by other processing.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
There is no page_size for ramtron flashes,
so just print the detected flash and it's size.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Qspi controller can have a memory mapped port which can be used for
data read. Added support to enable memory mapped port read.
This patch enables the following:
- It enables exchange of memory map address between mtd and qspi
through the introduction of "memory_map" flag.
- Add support to communicate to the driver that memory mapped
transfer is to be started through introduction of new flags like
"SPI_XFER_MEM_MAP" and "SPI_XFER_MEM_MAP_END".
This will enable the spi controller to do memory mapped configurations
if required.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
Use flash->page_size arg in print_size() instead of
flash->sector_size while printing detected flas part details.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Now the common probing is handled in spi_flash_probe.c
hence removed the unneeded flash drivers.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Compared to other spi flashes, ramtron has a different
probing and implementation on flash ops, hence moved
ramtron probe code into ramtron driver.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
From Micron, 512MB onwards, flash requires to poll flag status
instead of read status- hence added E_FSR flag on spectific
flash parts.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
SECT_4K, SECT_32K and SECT_64K opeartions are performed to
to specific flash by adding a SECT* flag on respective
spi_flash_params.flag param.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Few of the flashes(Atmel, Macronix and SST) require to
clear BP# bits in flash power ups.
So clear these BP# bits at probe time, so-that the flash
is ready for user operations.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Most of the SST flashes needs to write up using SST_WP, AAI
Word Program, so added a flag param on spi_flash_params table.
SST flashes, which supports SST_WP need to use a WP write
sst_write_wp instead of common flash write.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Added AT45DB* parts are which are avilable in spi_flash_probe_legacy.c.
Updated the sector_size attributes as per the flash parts.
Looks fine for with this sector_size for computing the size
of flash.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Added SST25* parts are which are avilable in spi_flash_probe_legacy.c.
Updated the sector_size attributes as per the flash parts.
Looks fine for with this sector_size for computing the size
of flash.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Tested-by: Eric Nelson <eric.nelson@boundarydevices.com>
Added S25FL* parts are which are avilable in spi_flash_probe_legacy.c.
Updated the sector_size attributes as per the flash parts.
Looks fine for with this sector_size for computing the size
of flash.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Added W25* parts are which are avilable in spi_flash_probe_legacy.c.
Updated the sector_size attributes as per the flash parts.
Looks fine for with this sector_size for computing the size
of flash.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Added MX25L* parts are which are avilable in spi_flash_probe_legacy.c.
Updated the sector_size attributes as per the flash parts.
Looks fine for with this sector_size for computing the size
of flash.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
