This patch add a compatible spi driver for ath79 series SOC.
Signed-off-by: Wills Wang <wills.wang@live.com>
Reviewed-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
This patch add support for ar933x serial.
Signed-off-by: Wills Wang <wills.wang@live.com>
Reviewed-by: Thomas Chou <thomas@wytron.com.tw>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This is a simple pinctrl driver, it just support uart and spi pin-mux now.
Signed-off-by: Wills Wang <wills.wang@live.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[fixed typo in commit subject line]
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
This is a simple pinctrl driver, it just support uart and spi pin-mux now.
Signed-off-by: Wills Wang <wills.wang@live.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[fixed typo in commit subject line]
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
For reason unknown, recently, the DDR init code writers are really fond
of hiding some small floating point operating deep in their creations.
This patch removes one from the Marvell A38x code.
Instead of returning size of chip as float from ddr3_get_device_size()
in GiB units, return it as int in MiB units. Since this would interfere
with the huge switch code in ddr3_calc_mem_cs_size(), rework the code
to match the change.
Before this patch, the cs_mem_size variable could have these values:
( { 16, 32 } x { 8, 16 } x { 0.01, 0.5, 1, 2, 4, 8 } ) / 8 =
{ 0.000000, 0.001250, 0.002500, 0.005000, 0.062500, 0.125000,
0.250000, 0.500000, 1.000000, 2.000000, 4.000000, }
The switch code checked for a subset of the resulting RAM sizes, which
is in range 128 MiB ... 2048 MiB.
With this patch, the cs_mem_size variable can have these values:
( { 16, 32 } x { 8, 16 } x { 0, 512, 1024, 2048, 4096, 8192 } ) / 8 =
{ 0, 64, 128, 256, 512, 1024, 2048, 4096 }
To retain previous behavior, filter out 0 MiB (invalid size), 64 MiB
and 4096 MiB options.
Removing the floating point stuff also saves 1.5k from text segment:
clearfog : spl/u-boot-spl:all -1592 spl/u-boot-spl:text -1592
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dirk Eibach <dirk.eibach@gdsys.cc>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
During DDR-2133 operation, the transmit data eye margins determined
during the memory controller initialization may be sub-optimal, set
DEBUG_29[12] and DEBUG_29[13:16] = 4'b0100 before MEM_EN is set.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
For SoCs that contain multiple SEC engines, each of them needs
to be initialized (by means of initializing among others the
random number generator).
Signed-off-by: Alex Porosanu <alexandru.porosanu@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
The S25FS-S family physical sectors may be configured as a hybrid
combination of eight 4-kB parameter sectors at the top or bottom
of the address space with all but one of the remaining sectors
being uniform size.
The default status of the flash is in this hybrid architecture.
The parameter sectors and the uniform sectors have different erase
commands.
This patch disable the hybrid sector architecture then the flash will
has uniform sector size and uniform erase command.
This configuration is temporary, the flash will revert to hybrid
architecture after power on reset.
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
The flash type of LS2085AQDS QSPI is S25FS256S. It has special write
any device register command and read any device register command.
This patch enable support for those commands.
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <york.sun@nxp.com>
QSPI controller automatic enable the chipselect signal according the
dest AMBA memory address. Now we distribute the AMBA memory zone
averagely to every chipselect slave device according chipselect
numbers got from dts node.
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <york.sun@nxp.com>
The address value and size value get from dts "reg" property have
type of u64 on arm64. If we assign those values to "u32" variables,
driver can't work correctly. Converting the type of those variables
to fdt_xxx_t.
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <york.sun@nxp.com>
The initial training for the DDRC may provide results that are not
optimized. The workaround provides better read timing margins.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Per the latest erratum document, update step 4 and step 8, only
DEBUG_29[21] is changed, all other bits should not be changed.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Add an emulation of an SD card to sandbox, allowing MMC to be used in tests.
The emulation is very simple, supporting only card detection and reading
test data.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for enabling CONFIG_BLK with MMC. This involves changing a
few functions to use struct udevice and adding a MMC block device driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Binding an MMC device when CONFIG_BLK is enabled requires that a block
device be bound as a child of the MMC device. Add a function to do this.
The mmc_create() method will be used only when DM_BLK is disabled.
Add an unbind method also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Implement the functions in mmc_legacy.c for driver-model block devices, so
that MMC can use driver model for these. This allows CONFIG_BLK to be enabled
with DM_MMC.
Signed-off-by: Simon Glass <sjg@chromium.org>
This driver will require generic MMC and block-device support in a future
commit. To avoid test errors, make this change now.
Signed-off-by: Simon Glass <sjg@chromium.org>
Instead of looking up the MMC device by number, just pass it in. This makes
it possible to use this function with driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present the MMC subsystem maintains its own list of MMC devices. This
cannot work with driver model, which needs to maintain this itself. Move the
list code into a separate 'legacy' file. The core MMC code remains, and will
be shared with the driver-model implementation.
Signed-off-by: Simon Glass <sjg@chromium.org>
The block device uclass does not currently support selecting a particular
hardware partition but this is needed for MMC. Add it so that the blk API
can support MMC properly.
Signed-off-by: Simon Glass <sjg@chromium.org>
The MMC block device is contained within struct mmc. But with driver model
this will not be the case. Add a function to obtain the block device. We
can later implement this for CONFIG_BLK.
Signed-off-by: Simon Glass <sjg@chromium.org>
This function is defined after it is used. In preparation for making it
static, move it up a little. Also drop the printf() which should not appear
in a driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Some devices have a name that is stored in allocated memory. At present
there is no mechanism to free this memory when the device is unbound.
Add a device flag to track whether a name is allocated and a function to
add the flag. Free the memory when the device is unbound.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add a function that automatically builds the device name given the parent
and a supplied string. Most callers will want to do this, so putting this
functionality in one place makes more sense.
Signed-off-by: Simon Glass <sjg@chromium.org>
Allow a devnum parameter of -1 to indicate that the device number should be
alocated automatically. The next highest available device number for that
interface type is used.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that the MMC code accesses devices by number, we can implement this same
interface for driver model, allowing MMC to support using driver model for
block devices.
Add the required functions to the uclass.
Signed-off-by: Simon Glass <sjg@chromium.org>
There is quite a bit of duplicated common code related to block devices
in the IDE and SCSI implementations.
Create some helper functions that can be used to reduce the duplication.
These rely on a linker list of interface-type drivers
Signed-off-by: Simon Glass <sjg@chromium.org>
This option currently enables both the command and the SCSI functionality.
Rename the existing option to CONFIG_SCSI since most of the code relates
to the feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add some functions needed by the SATA code. This allows it to be compiled
for sandbox, thus increasing build coverage.
Signed-off-by: Simon Glass <sjg@chromium.org>
Add some functions needed by the SCSI code. This allows it to be compiled
for sandbox, thus increasing build coverage.
Signed-off-by: Simon Glass <sjg@chromium.org>
This started as 'ahci' and was renamed to 'disk' during code review. But it
seems that this is too generic. Now that we have a 'blk' uclass, we can use
that as the generic piece, and revert to ahci for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Bring this support back so that sandbox can be compiled with CONFIG_BLK. This
allows sandbox to have greater build coverage during the block-device
transition. This can be removed again later.
This reverts commit 33cf727b16.
Signed-off-by: Simon Glass <sjg@chromium.org>
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the Exynos/S5P gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson <eric@nelint.com>
Acked-by: Simon Glass <sjg@chromium.org>
Acked-by: Minkyu Kang <mk7.kang@samsung.com>
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the Rockchip gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson <eric@nelint.com>
Acked-by: Simon Glass <sjg@chromium.org>
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the pic32 gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson <eric@nelint.com>
Acked-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Purna Chandra Mandal <purna.mandal@microchip.com>
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the omap gpio driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson <eric@nelint.com>
Acked-by: Simon Glass <sjg@chromium.org>
With the addition of GPIO_ACTIVE_LOW parsing in gpio-uclass,
the intel_broadwell driver doesn't need a custom xlate routine.
Signed-off-by: Eric Nelson <eric@nelint.com>
Acked-by: Simon Glass <sjg@chromium.org>
Many drivers use a common form of offset + flags for device
tree nodes. e.g.:
<&gpio1 2 GPIO_ACTIVE_LOW>
This patch adds a common implementation of this type of parsing
and calls it when a gpio driver doesn't supply its' own xlate
routine.
This will allow removal of the driver-specific versions in a
handful of drivers and simplify the addition of new drivers.
Signed-off-by: Eric Nelson <eric@nelint.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Introduce driver to support "fairchild,74hc595" devices.
1. Take linux drivers/drivers/gpio/gpio-74x164.c as reference.
2. Following the naming used in Linux driver with gen_7x164 as the prefix.
3. Enable CONFIG_DM_74X164 to use this driver.
4. Follow Documentation/devicetree/bindings/gpio/gpio-74x164.txt to add device
nodes
5. Tested on i.MX6 UltraLite with 74LV595 using gpio command and oscillograph.
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Chin Liang See <clsee@altera.com>
Cc: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Introduce dm_spi_claim_bus, dm_spi_release_bus and dm_spi_xfer
Convert spi_claim_bus, spi_release_bus and spi_xfer to use
the new API.
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Jagan Teki <jteki@openedev.com>
Acked-by: Simon Glass <sjg@chromium.org>
1. Support compatible string "spi-gpio" which is used by Linux
Linux use different bindings, so use UBOOT_COMPAT and
LINUX_COMPAT to differentiate them.
2. Introduce SPI_MASTER_NO_RX and SPI_MASTER_NO_TX to handle
no rx or no tx case.
3. Tested on i.MX6 UltraLite board with 74LV595 spi-gpio chip.
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Przemyslaw Marczak <p.marczak@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When doing xfer, should use device->parent, but not device
When doing bit xfer, should use "!!(tmpdout & 0x80)", but not
"(tmpdout & 0x80)"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Jagan Teki <jteki@openedev.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use the device's own DT offset, not the device's parent's.
Fixes: 43c4d44e33 ("fdt: implement dev_get_addr_name()")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
This prevents the following boot-time message on any board where only the
first DC is in use, yet the DC's DT node is enabled:
stdio_add_devices: Video device failed (ret=-22)
(This happens on at least Harmony, Ventana, and likely any other Tegra20
board with display enabled other than Seaboard).
The Tegra DC's DT node represents a display controller. It may itself
drive an integrated RGB display output, or be used by some other display
controller such as HDMI. For this reason the DC node itself is not
enabled/disabled in DT; the DC itself is considered a shared resource, not
the final (board-specific) display output. The node should instantiate a
display output driver only if the rgb subnode is enabled. Other output
drivers are free to use the DC if they are enabled and their DT node
references the DC's DT node. Adapt the Tegra display drivers' bind()
routine to only bind to the DC's DT node if the RGB subnode is enabled.
Now that the display driver does the right thing, remove the workaround
for this issue from Seaboard's DT file.
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
In some cases, drivers may not want to bind to a device. Allow bind() to
return -ENODEV in this case, and don't treat this as an error. This can
be useful in situations where some information source other than the DT
node's main status property indicates whether the device should be
enabled, for example other DT properties might indicate this, or the
driver might query non-DT sources such as system fuses or a version number
register.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Boards can now use DM serial driver, or still legacy mcf uart
driver version.
Signed-off-by: Angelo Dureghello <angelo@sysam.it>
Acked-by: Simon Glass <sjg@chromium.org>
Introduce a new driver that supports driver model for pca953x.
The pca953x chips are used as I2C I/O expanders.
This driver is designed to support the following chips:
"
4 bits: pca9536, pca9537
8 bits: max7310, max7315, pca6107, pca9534, pca9538, pca9554,
pca9556, pca9557, pca9574, tca6408, xra1202
16 bits: max7312, max7313, pca9535, pca9539, pca9555, pca9575,
tca6416
24 bits: tca6424
40 bits: pca9505, pca9698
"
But for now this driver only supports max 24 bits and pca953x compatible
chips. pca957x compatible chips are not supported now.
These can be addressed when we need to add such support for the different
chips.
This driver has been tested on i.MX6 SoloX Sabreauto board with max7310
i2c expander using gpio command as following:
=>gpio status -a
Bank gpio@30_:
gpio@30_0: input: 1 [ ]
=> dm tree:
i2c [ ] | | `-- i2c@021a8000
gpio [ ] | | |-- gpio@30
gpio [ ] | | `-- gpio@32
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Wenyou Yang <wenyou.yang@atmel.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Purna Chandra Mandal <purna.mandal@microchip.com>
Cc: Thomas Chou <thomas@wytron.com.tw>
Cc: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Cc: Andrea Scian <andrea.scian@dave.eu>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Michal Simek <michal.simek@xilinx.com> #on ZynqMP zcu102
Allow the spl_parse_image_header() to return value. This is convenient
for controlling the SPL boot flow if the loaded image is corrupted.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Peng Fan <van.freenix@gmail.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tom Rini <trini@konsulko.com>
In a system where the initial u-boot location is genuinely NOR flash (as
opposed to RAM or a cache-line setup by a pre-bootloader) writes to the
data section are problematic. At best these writes have no effect, at
worst they put the flash memory into a status mode which changes the
executable code underneath us.
Pass around a stack variable from the top of the twsi i2c driver to
avoid writing to global data.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The DW I2C controller in the SPEAr SoCs doesn't support the enable
status register check. This patch selects
SYS_I2C_DW_ENABLE_STATUS_UNSUPPORTED for these boards.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
This patch adds an entry for the Designware I2C driver in Kconfig.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some platforms don't implement the enable status register at offset 0x9c.
The SPEAr600 platform is one of them. The recently added check to this
status register can't be performend on these platforms.
This patch introduces a new config option that can be enabled on such
platforms not supporting this register.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
Add support for common TI i2c mux which is available on ZynqMP zcu102
board.
DM i2c mux core code is selecting/deselecting bus before/after
every command is performed that's why only one channel is active at a
time. That's also the reason why deselect is just disable all available
channels.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
400kHz is maximum freq which can be used on Xilinx ZynqMP.
Support it with standard divider calculator.
Input freq is hardcoded to 100MHz input freq till we have clock driver
which can provide this information for exact configuration.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
set_bus_speed is the right function where bus speed should be setup.
This move enable option to remove probe and remove functions which are
empty.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Extract reading IP base address in function which is designed for it.
Also enable option to read more information from DT in this function.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reported by Coverity:
Logically dead code (DEADCODE)
dead_error_line: Execution cannot reach this statement:
(f_dfu->strings + --i).s = ....
If calloc failed, i is still 0 and no need to call free,
so discard the dead code.
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: "Łukasz Majewski" <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
When dfu_fill_entity fail, need to free dfu to avoid memory leak.
Reported by Coverity:
"
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable dfu going out of scope leaks the storage
it points to.
"
Signed-off-by: Peng Fan <van.freenix@gmail.com>
Cc: "Łukasz Majewski" <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
With patch c998da0d (usb: Change power-on / scanning timeout handling),
the USB scanning is started earlier and with a smaller timeout. This
resulted on SoCFPGA (using the DWC2 driver) in some USB sticks not
getting detected any more. This patch now adds a 1 second delay (in
the host mode only) to the DWC2 driver before the scanning is started.
With this delay, now all problematic USB keys are detected successfully
again. And there is no need any more to change the delay / timeout
in the common USB code (usb_hub.c).
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Chin Liang See <clsee@altera.com>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Marek Vasut <marex@denx.de>
The indirect read code is a pile of nastiness. This patch replaces
the whole unmaintainable indirect read implementation with the one
from upcoming Linux CQSPI driver, which went through multiple rounds
of thorough review and testing. All the patch does is it plucks out
duplicate ad-hoc code distributed across the driver and replaces it
with more compact code doing exactly the same thing. There is no
speed change of the read operation.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Chin Liang See <clsee@altera.com>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Jagan Teki <jteki@openedev.com>
Cc: Pavel Machek <pavel@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Vignesh R <vigneshr@ti.com>
The indirect write code is buggy pile of nastiness which fails horribly
when the system runs fast enough to saturate the controller. The failure
results in some pages (256B) not being written to the flash. This can be
observed on systems which run with Dcache enabled and L2 cache enabled,
like the Altera SoCFPGA.
This patch replaces the whole unmaintainable indirect write implementation
with the one from upcoming Linux CQSPI driver, which went through multiple
rounds of thorough review and testing. While this makes the patch look
terrifying and violates all best-practices of software development, all
the patch does is it plucks out duplicate ad-hoc code distributed across
the driver and replaces it with more compact code doing exactly the same
thing.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Chin Liang See <clsee@altera.com>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Jagan Teki <jteki@openedev.com>
Cc: Pavel Machek <pavel@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Vignesh R <vigneshr@ti.com>
There could be runtime determined board specific reason why a EHCI
initialization fails (e.g. ENODEV if a Port is not available). In
this case, properly return the error code.
While at it, that function (board_ehci_hcd_init) has actually two
documentation blocks... Use the correct function name for the
documentation block of board_usb_phy_mode.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Tegra20's PCIe controller has a couple of quirks. There are workarounds in
the driver for these, but they don't work after the DM conversion:
1) The PCI_CLASS value is wrong in HW.
This is worked around in pci_tegra_read_config() by patching up the value
read from that register. Pre-DM, the PCIe core always read this via a
16-bit access to the 16-bit offset 0xa. With DM, 32-bit accesses are used,
so we need to check for offset 0x8 instead. Mask the offset value back to
32-bit alignment to make this work in all cases.
2) Accessing devices other than dev 1 causes a data abort.
Pre-DM, this was worked around in pci_skip_dev(), which the PCIe core code
called during enumeration while iterating over a bus. The DM PCIe core
doesn't use this function. Instead, enhance tegra_pcie_conf_address() to
validate the bdf being accessed, and refuse to access invalid devices.
Since pci_skip_dev() isn't used, delete it.
I've also validated that both these WARs are only needed for Tegra20, by
testing on Tegra30/Cardhu and Tegra124/Jetson TKx. So, compile them in
conditionally.
Fixes: e81ca88451 ("dm: tegra: pci: Convert tegra boards to driver model for PCI")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Memset pools_params as "0" to avoid garbage value in dpni_set_pools.
Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Reported-by: Jose Rivera <german.rivera@nxp.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Initialize desc_before_addr, otherwise the USB core won't send the
first 64B Get Device Descriptor request in common/usb.c function
usb_setup_descriptor() . There are some USB devices which expect
this sequence and otherwise can misbehave.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Tom Rini <trini@konsulko.com>
Introduce a new flag in the controller private data, which allows selectively
disabling the OC protection. Use the standard 'disable-over-current' OF prop
to set this flag. This OC protection must be disabled on EBV SoCrates rev 1.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Dinh Nguyen <dinguyen@kernel.org>
