| Age | Commit message (Collapse) | Author |
|---|
|
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 <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Chin Liang See <[email protected]>
Cc: Bhuvanchandra DV <[email protected]>
Cc: Daniel Schwierzeck <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Stefano Babic <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Jagan Teki <[email protected]>
Acked-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Przemyslaw Marczak <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Jagan Teki <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Use the device's own DT offset, not the device's parent's.
Fixes: 43c4d44e3330 ("fdt: implement dev_get_addr_name()")
Signed-off-by: Stephen Warren <[email protected]>
Acked-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Stephen Warren <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Boards can now use DM serial driver, or still legacy mcf uart
driver version.
Signed-off-by: Angelo Dureghello <[email protected]>
Acked-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Wenyou Yang <[email protected]>
Cc: Daniel Schwierzeck <[email protected]>
Cc: Purna Chandra Mandal <[email protected]>
Cc: Thomas Chou <[email protected]>
Cc: Bhuvanchandra DV <[email protected]>
Cc: Andrea Scian <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: Stefano Babic <[email protected]>
Cc: Fabio Estevam <[email protected]>
Acked-by: Simon Glass <[email protected]>
Tested-by: Michal Simek <[email protected]> #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 <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Peng Fan <[email protected]>
Cc: Stefano Babic <[email protected]>
Cc: Tom Rini <[email protected]>
|
|
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Cc: Heiko Schocher <[email protected]>
|
|
This patch adds an entry for the Designware I2C driver in Kconfig.
Signed-off-by: Stefan Roese <[email protected]>
Cc: Heiko Schocher <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
Signed-off-by: Mario Six <[email protected]>
|
|
Signed-off-by: Mario Six <[email protected]>
|
|
Signed-off-by: Mario Six <[email protected]>
|
|
Signed-off-by: Mario Six <[email protected]>
|
|
Signed-off-by: Mario Six <[email protected]>
|
|
Signed-off-by: Mario Six <[email protected]>
|
|
Signed-off-by: Mario Six <[email protected]>
|
|
Signed-off-by: Mario Six <[email protected]>
|
|
Signed-off-by: Mario Six <[email protected]>
|
|
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 <[email protected]>
Cc: Heiko Schocher <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
|
|
|
|
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 <[email protected]>
Cc: "Łukasz Majewski" <[email protected]>
Cc: Marek Vasut <[email protected]>
|
|
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 <[email protected]>
Cc: "Łukasz Majewski" <[email protected]>
Cc: Marek Vasut <[email protected]>
|
|
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 <[email protected]>
Cc: Chin Liang See <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Stephen Warren <[email protected]>
Cc: Marek Vasut <[email protected]>
|
|
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 <[email protected]>
Cc: Anatolij Gustschin <[email protected]>
Cc: Chin Liang See <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Jagan Teki <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Stefan Roese <[email protected]>
Cc: Vignesh R <[email protected]>
|
|
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 <[email protected]>
Cc: Anatolij Gustschin <[email protected]>
Cc: Chin Liang See <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Jagan Teki <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Stefan Roese <[email protected]>
Cc: Vignesh R <[email protected]>
|
|
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 <[email protected]>
|
|
Spelling corrections for (among other things):
* environment
* override
* variable
* ftd (should be "fdt", for flattened device tree)
* embedded
* FTDI
* emulation
* controller
|
|
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: e81ca88451cf ("dm: tegra: pci: Convert tegra boards to driver model for PCI")
Signed-off-by: Stephen Warren <[email protected]>
Reviewed-by: Thierry Reding <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Warren <[email protected]>
|
|
Memset pools_params as "0" to avoid garbage value in dpni_set_pools.
Signed-off-by: Prabhakar Kushwaha <[email protected]>
Reported-by: Jose Rivera <[email protected]>
Acked-by: Joe Hershberger <[email protected]>
|
|
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 <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Cc: Stefan Roese <[email protected]>
Cc: Dinh Nguyen <[email protected]>
|
|
Introduce a boolean flag in the dwc2 controller private data and set
it according to the macro (for now) instead of having this macro
directly in the dwc_otg_core_init(). This will let us configure the
flag from DT or such later on, if needed.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Stefan Roese <[email protected]>
Cc: Dinh Nguyen <[email protected]>
|
|
Pass the whole bulk of private data instead of just the regs,
since the private data will soon contain important configuration
flags.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Stefan Roese <[email protected]>
Cc: Dinh Nguyen <[email protected]>
|
|
Signed-off-by: Vagrant Cascadian <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The DMA was outputting the palette on the screen because the base
for the DMA was not after the palette. In addition to that, the ceiling was
also too high, this led that the output on the screen was shifted.
NOTE: According to the TRM, even in 16/24bit mode a palette is required
in the first 32 bytes of the framebuffer.
See also:
https://e2e.ti.com/support/arm/sitara_arm/f/791/p/234967/834483#834483
"In this mode, the LCDC will assume all information is data and thus you
need to ensure that the DMA points to the first pixel of data and not the
first entry in the frame buffer which is the beginning of the 512 byte
palette."
Signed-off-by: Martin Pietryka <[email protected]>
Reviewed-by: Hannes Schmelzer <[email protected]>
Tested-by: Hannes Schmelzer <[email protected]>
|
|
To support 16bpp we just need to change the raster_ctrl register
accordingly. Also 32bpp mode should work as well, but was not tested.
According to the TRM the uppermost byte will be ignored when
LCD_TFT_24BPP_UNPACK is set.
The switch logic is based on the Linux kernel tilcdc driver:
drivers/gpu/drm/tilcdc/tilcdc_crtc.c: lines 407 through 419
(kernel was checked out at commit: bcc981e9ed8)
Signed-off-by: Martin Pietryka <[email protected]>
Reviewed-by: Hannes Schmelzer <[email protected]>
Tested-by: Hannes Schmelzer <[email protected]>
|
|
Some toolchains fail to build
"clk->rate = (u64)(clk->parent->rate * 16) / div;"
And the cast usage is wrong.
Use the following code to fix the issue,
"
do_div(parent_rate, div);
clk->rate = parent_rate;
"
Reported-by: Peter Robinson <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
Cc: Stefano Babic <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Anatolij Gustschin <[email protected]>
Cc: Peter Robinson <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Tested-by: Peter Robinson <[email protected]>
|
|
|
|
According to the TRM you have to set bits [21:20] to 0b10 for RAW mode, so
(0x10 << 20) is obviously wrong here.
Signed-off-by: Martin Pietryka <[email protected]>
|
|
The terminal condition in the area where a PCI device is scanned is wrong,
and 1f.7 isn't scanned.
Signed-off-by: Yoshinori Sato <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
