| Age | Commit message (Collapse) | Author |
|---|
|
Update the codes to conform with xHCI spec chapter 6.2.3.
Signed-off-by: Bin Meng <[email protected]>
|
|
Per xHCI spec, 'Error Count' should be set to 0 for isoch endpoints.
Signed-off-by: Bin Meng <[email protected]>
|
|
The 'Max Burst Size' indicates to the xHC the maximum number of
consecutive USB transactions that should be executed per scheduling
opportunity. This is a “zero-based” value, where 0 to 15 represents
burst sizes of 1 to 16, but at present this is always set to zero.
Let's program the required value according to real needs.
Signed-off-by: Bin Meng <[email protected]>
|
|
USB endpoint reports the period between consecutive requests to send
or receive data as bInverval in its endpoint descriptor. So far this
is ignored by xHCI driver and the 'Interval' field in xHC's endpoint
context is always programmed to zero which means 1ms for low speed
or full speed , or 125us for high speed or super speed. We should
honor the interval by getting it from endpoint descriptor.
Signed-off-by: Bin Meng <[email protected]>
|
|
In xhci_check_maxpacket(), the control endpoint 0 max packet size
is wrongly taken from the interface's endpoint descriptor. However
the default endpoint 0 does not come with an endpoint descriptor
hence is not included in the interface structure. Change to use
epmaxpacketin[0] instead.
The other bug in this routine is that when setting max packet size
to the xHC endpoint 0 context, it does not clear its previous value
at all before programming a new one.
Signed-off-by: Bin Meng <[email protected]>
|
|
xHCI uses normal TRBs for both bulk and interrupt. This adds the
missing interrupt transfer support to xHCI so that devices like
USB keyboard that uses interrupt transfer can work.
Signed-off-by: Bin Meng <[email protected]>
|
|
At present xHCI driver assumes LS/FS devices are attached directly
to a HS hub. If they are connected to a LS/FS hub, the driver will
fail to perform the USB enumeration process on such devices.
This is fixed by looking from the device itself all the way up to
the HS hub where the TT that serves the device is located.
Signed-off-by: Bin Meng <[email protected]>
|
|
With the root hub unbinding in usb_stop(), there is no need to do
a Sandbox-specific reset operation. usb_emul_reset() is no longer
used anywhere, drop it.
Signed-off-by: Bin Meng <[email protected]>
|
|
With the root hub unbinding in usb_stop(), there is no need to do
a blk uclass specific unbind operation.
Signed-off-by: Bin Meng <[email protected]>
|
|
At present we only do device_remove() during usb stop. The DM API
device_remove() only marks the device state as inactivated, but
still keeps its USB topology (eg: parent, children, etc) in the DM
device structure. There is no issue if we only start USB subsystem
once and never stop it. But a big issue occurs when we do 'usb stop'
and 'usb start' multiple times.
Strange things may be observed with current implementation, like:
- the enumeration may report only 1 mass storage device is detected,
but the total number of USB devices is correct.
- USB keyboard does not work anymore after a bunch of 'usb reset'
even if 'usb tree' shows it is correctly identified.
- read/write flash drive via 'fatload usb' may complain "Bad device"
In fact, every time when USB host controller starts the enumeration
process, it takes random time for each USB port to show up online,
hence each USB device may appear in a different order from previous
enumeration, and gets assigned to a totally different USB address.
As a result, we end up using a stale USB topology in the DM device
structure which still reflects the previous enumeration result, and
it may create an exact same DM device name like generic_bus_0_dev_7
that is already in the DM device structure. And since the DM device
structure is there, there is no device_bind() call to bind driver to
the device during current enumeration process, eventually creating
an inconsistent software representation of the hardware topology, a
non-working USB subsystem.
The fix is to clear the unused USB topology in the usb_stop(), by
calling device_unbind() on each controller's root hub device, and
the unbinding will unbind all of its children automatically.
For Sandbox, we need scan the device tree each time when we start
the USB stack, in order to re-create the emulated USB devices and
bind drivers for them before we actually do the driver probe.
Signed-off-by: Bin Meng <[email protected]>
|
|
At present the usb hub emulator always reports its downstream port
speed as full speed. Actually it is high speed for sandbox-flash,
and low speed for sandbox-keyb. We can determine the device speed
by checking its device descriptor bcdUSB field, and do the proper
hub port status report based on that.
Signed-off-by: Bin Meng <[email protected]>
|
|
This can be useful outside of the sandbox usb emulation uclass
driver. Expose it as a public API with a proper prefix (usb_emul_).
Signed-off-by: Bin Meng <[email protected]>
|
|
Current emulator select logic in usb_emul_find_devnum() is to test
the USB address. The USB address of the device being enumerated is
initialized to zero at the beginning of the enumeration process in
usb_setup_device(). At this point, the saved USB address in the
platform data has not been assigned to any valid USB address either.
This means: the logic will select an emulator device according to
its sequence of declaring order in the device tree. Take test.dts
for example, flash-stick@0 will be selected before flash-stick@1.
But unfortunately such logic is wrong.
In fact USB devices show up in a random order during the enumeration
which means usb_emul_find_devnum() may be called on port 3 for keyb@3
before on port 0 for flash-stick@0.
To fix this, we introduce a new emulator uclass specific platdata
to store the USB device's port number on its parent hub, and update
the logic to test the port number instead.
Signed-off-by: Bin Meng <[email protected]>
|
|
At present 'usb tree' shows that the root hub on the Sandbox USB
controller is at full speed. But its device descriptor says it's
USB 2.0, so let's report it as a high speed device.
Signed-off-by: Bin Meng <[email protected]>
|
|
This parameter is never used.
Signed-off-by: Bin Meng <[email protected]>
|
|
The Makefile already tests for SPL_DM_REGULATOR_FIXED, but Kconfig
does not provide it. This adds SPL_DM_REGULATOR_FIXED to Kconfig.
Signed-off-by: Philipp Tomsich <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add compatible to support rk3328 i2c
Signed-off-by: Elaine Zhang <[email protected]>
Signed-off-by: Kever Yang <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
Acked-by: Heiko Schocher<[email protected]>
|
|
Apparently, our earlier assumption that the BROM will always set up
the iomux for SDcard communication does not always hold true: when
booting U-Boot from the on-module (on the RK3368-uQ7) eMMC, the SDcard
pins are not set up and need to be configured by the pinctrl driver to
allow SD card access.
This change implements support for setting up the SDMMC pins in
pinctrl for the RK3368.
Reported-by: Klaus Goger <[email protected]>
Signed-off-by: Philipp Tomsich <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The pd_bus hclk/pclk source is pd_bus aclk, not the PLL.
Signed-off-by: Kever Yang <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
Fix typo RK322X/RK3036 in rk322x clock driver.
Signed-off-by: Kever Yang <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
|
|
RK3188 using the same ddr_conf for both 15 bit and 16 bit row address.
Signed-off-by: Kever Yang <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
[Fixed compile-error by declaring 'row':]
Signed-off-by: Philipp Tomsich <[email protected]>
|
|
Add driver for rk322x to support sdram initialize in SPL.
Signed-off-by: Kever Yang <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
Since we have CONFIG_RAM framwork and its driver folder, move the driver
into it.
Signed-off-by: Kever Yang <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
Since we have CONFIG_RAM framwork and its driver folder, move the driver
into it.
Signed-off-by: Kever Yang <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
Since we have CONFIG_RAM framwork and its driver folder, move the driver
into it.
Signed-off-by: Kever Yang <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
Since we have CONFIG_RAM framwork and its driver folder, move the driver
into it.
Signed-off-by: Kever Yang <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
The clk_saradc is dividing from the 24M, clk_saradc=24MHz/(saradc_div_con+1).
SARADC integer divider control register is 8-bits width.
Signed-off-by: David Wu <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
The clk_saradc is dividing from the 24M, clk_saradc=24MHz/(saradc_div_con+1).
SARADC integer divider control register is 8-bits width.
Signed-off-by: David Wu <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
The clk_saradc is dividing from the 24M, clk_saradc=24MHz/(saradc_div_con+1).
SARADC integer divider control register is 10-bits width.
Signed-off-by: David Wu <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
The clk_saradc is dividing from the 24M, clk_saradc=24MHz/(saradc_div_con+1).
SARADC integer divider control register is 8-bits width.
Signed-off-by: David Wu <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
|
|
The clk_saradc is dividing from the 24M, clk_saradc=24MHz/(saradc_div_con+1).
SARADC integer divider control register is 10-bits width.
Signed-off-by: David Wu <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
The ADC can support some channels signal-ended some bits Successive Approximation
Register (SAR) A/D Converter, like 6-channel and 10-bit. It converts the analog
input signal into some bits binary digital codes.
Signed-off-by: David Wu <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
Add missing .priv_auto_alloc_size() callback.
Previously private struct stm32_clk was not allocate
which leads to unpredictable behaviour
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Note that this doesn't differentiate (due to lack of information in
video_priv) between different possible component orders for 32bpp.
But the main user at this point is efi_loader, and GOP expects xBGR
so any video drivers that this is incorrect for already have problems.
(Also, conveniently, this matches what simple-framebuffer bindings
expect for kernels that use the simple-framebuffer DT binding to
take over the bootloader display.)
Signed-off-by: Rob Clark <[email protected]>
|
|
Really just the subset that is needed by efi_console. Perhaps more will
be added later, for example color support would be useful to implement
efi_cout_set_attribute().
Signed-off-by: Rob Clark <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Content can come to screen via putc() and we cannot always rely on
updates ending with a puts(). This is the case with efi_console output
to vidconsole. Fixes corruption with Shell.efi.
Signed-off-by: Rob Clark <[email protected]>
|
|
The DM support is already in the driver, so add
da830-spi to the compatible list.
Reviewed-by: Jagan Teki <[email protected]>
Signed-off-by: Adam Ford <[email protected]>
|
|
The MMC framework in U-Boot does not support a systematic API for
timing switch like mmc_set_timing() in Linux.
U-Boot just provides a hook to change the clock frequency via
mmc_set_clock(). It is up to drivers if additional register
settings are needed.
This driver needs to set a correct timing mode into a register when
it migrates to a different speed mode. Only increasing clock frequency
could result in setup/hold timing violation.
The timing mode should be decided by checking MMC_TIMING_* like
drivers/mmc/host/sdhci-cadence.c in Linux, but "timing" is not
supported by U-Boot for now. Just use mmc->clock to decide the
timing mode.
Signed-off-by: Masahiro Yamada <[email protected]>
|
|
Add initial support for setting the vqmmc regulator. Since we do not
support 1V8 modes, set the regulator to 3V3 and enable it.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Jaehoon Chung <[email protected]>
Acked-by: Masahiro Yamada <[email protected]>
|
|
Old version of the uniphier-sd 64bit IO support patchset V1 was
applied by the maintainer, update the uniphier-sd.c with the
changes from the V3 of the patchset.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Jaehoon Chung <[email protected]>
Acked-by: Masahiro Yamada <[email protected]>
|
|
This patch adds SD/MMC support for STM32H7 SoCs.
Here is an extraction of SDMMC main features, embedded in
STM32H7 SoCs.
The SD/MMC block include the following:
_ Full compliance with MultiMediaCard System Specification
Version 4.51. Card support for three different databus modes:
1-bit (default), 4-bit and 8-bit.
_ Full compatibility with previous versions of MultiMediaCards
(backward compatibility).
_ Full compliance with SD memory card specifications version 4.1.
(SDR104 SDMMC_CK speed limited to maximum allowed IO speed,
SPI mode and UHS-II mode not supported).
_ Full compliance with SDIO card specification version 4.0.
Card support for two different databus modes: 1-bit (default)
and 4-bit. (SDR104 SDMMC_CK speed limited to maximum allowed IO
speed, SPI mode and UHS-II mode not supported).
_ Data transfer up to 208 Mbyte/s for the 8 bit mode.
(depending maximum allowed IO speed).
_ Data and command output enable signals to control external
bidirectional drivers.
The current version of the SDMMC supports only one SD/SDIO/MMC card
at any one time and a stack of MMC Version 4.51 or previous.
Signed-off-by: Christophe Kerello <[email protected]>
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add GPIO driver for the Renesas RCar SoCs . The driver currently supports
only the RCar Gen3 R8A7795 and R8A7796 SoCs, but is easily extensible for
the other RCar SoCs as well.
This driver is meant to replace the pinmux part of SH_GPIO_PFC driver.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Nobuhiro Iwamatsu <[email protected]>
Signed-off-by: Nobuhiro Iwamatsu <[email protected]>
|
|
Add PFC pincontrol driver for the Renesas RCar Gen3 R8A7795 and R8A7796
SoCs. This driver uses the PFC pin tables from Linux, thus letting us
share the occassional fixes to those tables. This driver also has a DT
support, so the pinmux is configured from DT instead of the ad-hoc setup
in board file.
This driver is meant to replace the pinmux part of SH_GPIO_PFC driver.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Nobuhiro Iwamatsu <[email protected]>
Signed-off-by: Nobuhiro Iwamatsu <[email protected]>
|
|
During using dwc2 usb gadget, if usb message size is too small,
following cache misaligned warning is shown:
CACHE: Misaligned operation at range [bfdbcb00, bfdbcb04]
Align size of invalidating dcache before starting DMA to remove the
warning.
Signed-off-by: Seung-Woo Kim <[email protected]>
|
|
The choice of "USB keyboard polling" cannot be optional as without
one mechanism being set, it just doesn't work. Set the default one
to CONFIG_SYS_USB_EVENT_POLL.
Fixes: ecad7051 ("configs: Migrate all of the existing USB symbols, except fastboot")
Signed-off-by: Bin Meng <[email protected]>
|
|
Update the generic EHCI driver to support a live tree.
Signed-off-by: Philipp Tomsich <[email protected]>
|
|
Update the DWC2 USB driver to support a live tree.
Signed-off-by: Philipp Tomsich <[email protected]>
|
|
Update the Rockchip xhci wrapper driver to support a live device tree.
Signed-off-by: Philipp Tomsich <[email protected]>
|
|
EHCD can handle any transfer length as long as there is enough free
heap space left, hence set the theoretical max number SIZE_MAX.
Signed-off-by: Bin Meng <[email protected]>
|
|
xHCD allocates one segment which includes 64 TRBs for each endpoint
and the last TRB in this segment is configured as a link TRB to form
a TRB ring. Each TRB can transfer up to 64K bytes, however data
buffers referenced by transfer TRBs shall not span 64KB boundaries.
Hence the maximum number of TRBs we can use in one transfer is 62.
Signed-off-by: Bin Meng <[email protected]>
|
