2 QTDs are allocated for each EP. The current allocation scheme aligns
the first QTD in each pair, but simply adds the struct size to calculate
the second QTD's address. This will result in a non-cache-aligned
addresss IF the system's ARCH_DMA_MINALIGN is not 32 bytes (i.e. the
size of struct ept_queue_item).
Similarly, the original ilist_ent_sz calculation aligned the value to
ARCH_DMA_MINALIGN but didn't take the USB HW's 32-byte alignment
requirement into account. This doesn't cause a practical issue unless
ARCH_DMA_MINALIGN < 32 (which I suspect is quite unlikely), but we may
as well fix the code to be explicit, so it's obviously completely
correct.
The new value of ILIST_ENT_SZ takes all alignment requirements into
account, so we can simplify ci_{flush,invalidate}_qtd() by simply using
that macro rather than calling roundup().
Similarly, the calculation of controller.items[i] can be simplified,
since each QTD is evenly spaced at its individual alignment requirement,
rather than each pair being aligned, and entries within the pair being
spaced apart only by structure size.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This will allow functions other than ci_udc_probe() to make use of the
constants in a future change.
This in turn requires converting the const int variables to #defines,
since the initialization of one global const int can't depend on the
value of another const int; the compiler thinks it's non-constant if
that dependency exists.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Fix ci_ep_submit_next_request()'s ZLP transmission code to explicitly
call ci_get_qtd() to find the address of the other QTD to use. This
will allow us to correctly align each QTD individually in the future,
which may involve leaving a gap between the QTDs.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ci_udc_probe() initializes a pair of QHs and QTDs for each EP. After
each pair has been initialized, the pair is cache-flushed. The
conversion from QH/QTD index [0..2*NUM_END_POINTS) to EP index
[0..NUM_ENDPOINTS] is incorrect; it simply subtracts 1 (which yields
the QH/QTD index of the first entry in the pair) rather than dividing
by two (which scales the range). Fix this.
On my system, this avoids cache debug prints due to requests to flush
unaligned ranges. This is caused because the flush calls happen before
the items[] array entries are initialized for all but EP0.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Add LAN9500A product ID (0x9e00) in order to support LAN9500A based dongles.
Tested on cm_t335.
Signed-off-by: Ilya Ledvich <ilya@compulab.co.il>
Acked-by: Marek Vasut <marex@denx.de>
cb_getvar tries to prevent overflowing the response buffer
by using strncat. But strncat takes the number of data bytes
copied as a limit not the total buffer length so it can still
overflow. Pass the correct value instead.
cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
cc: Rob Herring <robh@kernel.org>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Because of the brackets the & and && is evaluated before
the comparison. This is likely not the intention. Change
it to test the first and second condition to both be true.
cc: Marek Vasut <marex@denx.de>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
since ALLOC_CACHE_ALIGN_BUFFER defines a pointer and not a
buffer, the memset with sizeof(rqt) likely does something else
then intended. Since there is a memcpy directly after it with
the full size, drop the memset completely.
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Since the struct fsg_common is calloced, reset it completely
with zero's when reused. While at it, make checkpatch happy.
cc: Lukasz Majewski <l.majewski@samsung.com>
cc: Piotr Wilczek <p.wilczek@samsung.com>
cc: Kyungmin Park <kyungmin.park@samsung.com>
cc: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Initialization of r8a66597 info structure is not enough.
Because initilization was used size of pointer.
This fixes that use size of r8a6659 info structure.
Signed-off-by: Yasuhisa Umano <yasuhisa.umano.zc@renesas.com>
This driver is processed as two USB hub despite one.
The number of root hub is defined in R8A66597_MAX_ROOT_HUB.
This fixes that register is accessed by using the definition
of R8A66597_MAX_ROOT_HUB.
Signed-off-by: Yasuhisa Umano <yasuhisa.umano.zc@renesas.com>
For plain array const can be either before or after
the type definition. Adding both is simply redundand.
Remove the later one.
cc: marex@denx.de
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
ci_udc.c's usb_gadget_unregister_driver() doesn't call driver->unbind()
unlike other USB gadget drivers. Fix it to do this.
Without this, when ether.c's CDC Ethernet device is torn down,
eth_unbind() is never called, so dev->gadget is never set to NULL.
For some reason, usb_eth_halt() is called both at the end of the first
use of the Ethernet device, and prior to any subsequent use. Since
dev->gadget is never cleared, all calls to usb_eth_halt() attempt to
stop, disconnect, and clean up the device, resulting in double cleanup,
which hangs U-Boot on my Tegra device at least.
ci_udc allocates its own singleton EP0 request object, and cleans it up
during usb_gadget_unregister_driver(). This appears necessary when using
the USB gadget framework in U-Boot, since that does not allocate/free
the EP0 request. However, the CDC Ethernet driver *does* allocate and
free its own EP0 requests. Consequently, we must protect
ci_ep_free_request() against double-freeing the request.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
In a very few cases we need to adjust the driver model root device, such as
when setting it up at initialisation. Add a macro to make this easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want 'N0' and 'n0' to mean the same thing, so ensure that case is not
considered when naming GPIO banks.
Signed-off-by: Simon Glass <sjg@chromium.org>
The function tps65090_init checks the i2c bus of p->bus. However
the pointer p is not intialiased at this point. Check the local
variable bus instead.
cc: Tom Wai-Hong Tam <waihong@chromium.org>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Acked-by: Simon Glass <sjg@chromium.org>
commit 18b06652cd "tools: include u-boot version of sha256.h"
unconditionally forced the sha256.h from u-boot to be used
for tools instead of the host version. This is fragile though
as it will also include the host version. Therefore move it
to include/u-boot to join u-boot/md5.h etc which were renamed
for the same reason.
cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Cleanup to balance malloc/free calls.
Signed-off-by: Darwin Rambo <drambo@broadcom.com>
Reviewed-by: Steve Rae <srae@broadcom.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Rather than just returning -1 everywhere, try to return something
meaningful from mmc_select_hwpart(). Note that most other MMC functions
don't do this, including functions called from mmc_select_hwpart(), so
I'm not sure how effective this will be. Still, it's one less place with
hard-coded -1.
Suggested-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Most of the warnings seem to be related to using 'int' for size_t. Change
this and fix up the remaining warnings and problems. For bootm, the warning
was masked by others, and there is an actual bug in the code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Patch (SHA1: bd694244db)
dfu: Introduction of the "dfu_hash_algo" env variable for checksum method
setting
already introduced more generic handling of the crc32 calculation.
Up till now the CRC32 of received data was calculated unconditionally.
This patch changes this and from now - by default the crc32 is NOT
calculated anymore.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Sometimes, a zero-length packet is required at the end of an IN
transaction so that the host knows the device is done sending data.
Enhance ci_udc to send a zlp when necessary. See the comments for
more details.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb_gadget_unregister_driver() is called to tear down the USB device mode
stack. Fix the driver to stop the USB HW (which causes any attached host
to notice the disappearance of the device), and free all allocations
(which obviously prevents memory leaks).
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ci_ep_alloc_request() avoids allocating multiple request objects for ep0
by keeping a record of the first req allocated for ep0, and always
returning that instead of allocating a new req. However, if this req is
ever freed, the record of the previous allocation is not cleared, so
ci_ep_alloc_request() will keep returning this stale pointer. Fix
ci_ep_free_request() to clear the record of the previous allocation.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ci_pullup()'s !is_on path contains a cut/paste copy of udc_disconnect().
Remove the duplication by simply calling udc_disconnect() instead.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
'r' of rESR_RTLF is a mistake of E.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The R7S72100 of ARM SoC that Renesas manufactured has one Ether port.
This has the same IP SH-Ether. This patch adds support of the R7S72100
in SH-Ether.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Currently, flash quad bit is set in "spi_flash_validate_params" and later
at the end in the same api, we write 0 to status register for few flashes,
thereby overriding the quad bit set. This fix moves the quad bit setting
outside this api in "spi_flash_probe_slave"
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This mirrors the conventions used in other SPI drivers (kirkwood,
davinci, atmel, et al) where the din/dout buffer can be NULL when the
received/transmitted data isn't important. This reduces the need for
allocating additional buffers when write-only/read-only functionality is
needed.
In the din == NULL case, the received data is simply not stored. In the
dout == NULL case, zeroes are transmitted.
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Reviewed-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
The patch populates the slave data which will be used by flash driver to
set the flash quad enable bit.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
This patch add support for BCH16_ECC to omap_gpmc driver.
*need to BCH16 ECC scheme*
With newer SLC Flash technologies and MLC NAND, and large densities, pagesizes
Flash devices have become more suspectible to bit-flips. Thus stronger
ECC schemes are required for protecting the data.
But stronger ECC schemes have come with larger-sized ECC syndromes which require
more space in OOB/Spare. This puts constrains like;
(a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data.
(b) BCH16_ECC generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy following equation:
OOBsize per page >= 26 * (page-size / 512)
Signed-off-by: Pekon Gupta <pekon@ti.com>
GPMC controller needs to be configured based on bus-width of the NAND device
connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI
parameters is not possible in following situations:
SPL: SPL NAND drivers does not support ONFI parameter reading.
U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init()
which is called before probing for devices, hence any ONFI parameter
information is not available during GPMC initialization.
Thus, OMAP NAND driver expected board developers to explicitely write GPMC
configurations specific to NAND device attached on board in board files itself.
But this was troublesome for board manufacturers as they need to dive into
lengthy platform & SoC documents to find details of GPMC registers and
appropriate configurations to get NAND device working.
This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config
hich indicates that connected NAND device has x16 bus-width. And then based on
this config GPMC driver itself initializes itself based on NAND bus-width. This
keeps board developers free from knowing GPMC controller specific internals.
Signed-off-by: Pekon Gupta <pekon@ti.com>
As per following Sections in ONFI Spec, NAND_CMD_READID should use only
lower 8-bit for transfering command, address and data even on x16 NAND device.
*Section: Target Initialization"
"The Read ID and Read Parameter Page commands only use the lower 8-bits of the
data bus. The host shall not issue commands that use a word data width on x16
devices until the host determines the device supports a 16-bit data bus width
in the parameter page."
*Section: Bus Width Requirements*
"When the host supports a 16-bit bus width, only data is transferred at the
16-bit width. All address and command line transfers shall use only the lower
8-bits of the data bus. During command transfers, the host may place any value
on the upper 8-bits of the data bus. During address transfers, the host shall
set the upper 8-bits of the data bus to 00h."
Thus porting following commit from linux-kernel to ensure that column address
is not altered to align to x16 bus when issuing NAND_CMD_READID command.
commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7
mtd: nand: force NAND_CMD_READID onto 8-bit bus
Author: Brian Norris <computersforpeace@gmail.com> (preserving authorship)
The NAND command helpers tend to automatically shift the column address
for x16 bus devices, since most commands expect a word address, not a
byte address. The Read ID command, however, expects an 8-bit address
(i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or
0x20).
This fixes the column address for a few drivers which imitate the
nand_base defaults.
Signed-off-by: Pekon Gupta <pekon@ti.com>
Porting below commit from linux-tree, preserving original authorship & commit log
commit bd9c6e99b58255b9de1982711ac9487c9a2f18be
Author: Brian Norris <computersforpeace@gmail.com>
mtd: nand: don't use read_buf for 8-bit ONFI transfers
Use a repeated read_byte() instead of read_buf(), since for x16 buswidth
devices, we need to avoid the upper I/O[16:9] bits. See the following
commit for reference:
commit 05f7835975dad6b3b517f9e23415985e648fb875 (from linux-tree)
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Thu Dec 5 22:22:04 2013 +0100
mtd: nand: don't use {read,write}_buf for 8-bit transfers
Now, I think that all barriers to probing ONFI on x16 devices are
removed, so remove the check from nand_flash_detect_onfi().
Signed-off-by: Pekon Gupta <pekon@ti.com>
This patch
omap-elm.c: replaces -ve integer value returned during errorneous condition,
with proper error-codes.
omap-gpmc.c: updates omap-gpmc driver to pass error-codes returned from
omap-elm driver to upper layers
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This patch tries to avoid some local pointer dereferences, by using common
local variables in omap_correct_data_bch()
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
This patch renames 'struct nand_bch_priv' which currently holds private data only
for BCH ECC schemes, into 'struct omap_nand_info' so that same can be used for
all ECC schemes
Signed-off-by: Pekon Gupta <pekon@ti.com>
Reviewed-by: Stefan Roese <sr@denx.de>
