Re: [PATCH v3 35/35] acpi: Add an acpi command to list/dump generated ACPI items
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > Add a command that shows the individual blocks of data generated by each > device, effectively splitting the full table into its component parts. > This can be helpful for debugging. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > Changes in v3: > - Update acpi_dump_items() to take an enum > - Update commit message and subject for clarity > > cmd/acpi.c | 15 +-- > drivers/core/acpi.c | 16 > include/dm/acpi.h | 16 > test/dm/acpi.c | 39 +++ > 4 files changed, 84 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 34/35] dm: acpi: Enhance acpi_get_name()
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> For many device types it is possible to figure out the name just by
> looking at its uclass or parent. Add a function to handle this, since it
> allows us to cover the vast majority of cases automatically.
>
> However it is sometimes impossible to figure out an ACPI name for a device
> just by looking at its uclass. For example a touch device may have a
> vendor-specific name. Add a new "acpi,name" property to allow a custom
> name to be created.
>
> With this new feature we can drop the get_name() methods in the sandbox
> I2C and SPI drivers. They were only added for testing purposes. Update the
> tests to use the new values.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v3:
> - Fix 'of' typo
>
> Changes in v1:
> - Use acpi,ddn instead of acpi,desc
> - Rename to acpi_device_infer_name()
> - Update newly created sandbox tests
>
> arch/sandbox/dts/test.dts | 1 +
> doc/device-tree-bindings/device.txt | 13
> drivers/core/acpi.c | 13 +++-
> drivers/i2c/sandbox_i2c.c | 10 ---
> drivers/spi/sandbox_spi.c | 10 ---
> include/acpi/acpi_device.h | 15
> lib/acpi/acpi_device.c | 106
> test/dm/acpi.c | 42 ++-
> test/dm/acpigen.c | 4 +-
> 9 files changed, 189 insertions(+), 25 deletions(-)
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index caf935cfdf..5d4d3daa28 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -113,6 +113,7 @@
> int-array = <5678 9123 4567>;
> str-value = "test string";
> interrupts-extended = < 3 0>;
> + acpi,name = "GHIJ";
> };
>
> junk {
> diff --git a/doc/device-tree-bindings/device.txt
> b/doc/device-tree-bindings/device.txt
> index 27bd3978d9..7140339623 100644
> --- a/doc/device-tree-bindings/device.txt
> +++ b/doc/device-tree-bindings/device.txt
> @@ -17,6 +17,8 @@ the acpi,compatible property.
> System) Device Name)
> - acpi,hid : Contains the string to use as the HID (Hardware ID)
> identifier _HID
> + - acpi,name : Provides the ACPI name for a device, which is a string
> consisting
> + of four alphanumeric character (upper case)
> - acpi,uid : _UID value for device
> - linux,probed : Tells U-Boot to add 'linux,probed' to the ACPI tables so
> that
> Linux will only load the driver if the device can be detected (e.g. on
> I2C
> @@ -34,3 +36,14 @@ elan_touchscreen: elan-touchscreen@10 {
> interrupts-extended = <_gpe GPIO_21_IRQ IRQ_TYPE_EDGE_FALLING>;
> linux,probed;
> };
> +
> +pcie-a0@14,0 {
> + reg = <0xa000 0 0 0 0>;
> + acpi,name = "RP01";
> + wifi: wifi {
> + compatible = "intel,generic-wifi";
> + acpi,ddn = "Intel WiFi";
> + acpi,name = "WF00";
> + interrupts-extended = <_gpe 0x3c 0>;
> + };
> +};
> diff --git a/drivers/core/acpi.c b/drivers/core/acpi.c
> index c1fc364550..acc2e3f7e9 100644
> --- a/drivers/core/acpi.c
> +++ b/drivers/core/acpi.c
> @@ -9,9 +9,10 @@
> #define LOG_CATEOGRY LOGC_ACPI
>
> #include
> -#include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -65,12 +66,20 @@ int acpi_copy_name(char *out_name, const char *name)
> int acpi_get_name(const struct udevice *dev, char *out_name)
> {
> struct acpi_ops *aops;
> + const char *name;
> + int ret;
>
> aops = device_get_acpi_ops(dev);
> if (aops && aops->get_name)
> return aops->get_name(dev, out_name);
> + name = dev_read_string(dev, "acpi,name");
> + if (name)
> + return acpi_copy_name(out_name, name);
> + ret = acpi_device_infer_name(dev, out_name);
> + if (ret)
> + return log_msg_ret("dev", ret);
>
> - return -ENOSYS;
> + return 0;
> }
>
> /**
> diff --git a/drivers/i2c/sandbox_i2c.c b/drivers/i2c/sandbox_i2c.c
> index 125026da90..57b1c60fde 100644
> --- a/drivers/i2c/sandbox_i2c.c
> +++ b/drivers/i2c/sandbox_i2c.c
> @@ -84,15 +84,6 @@ static int sandbox_i2c_xfer(struct udevice *bus, struct
> i2c_msg *msg,
> return ops->xfer(emul, msg, nmsgs);
> }
>
> -static int sandbox_i2c_get_name(const struct udevice *dev, char *out_name)
> -{
> - return acpi_copy_name(out_name, "SI2C");
> -}
> -
> -struct acpi_ops sandbox_i2c_acpi_ops = {
> - .get_name = sandbox_i2c_get_name,
> -};
> -
> static const struct dm_i2c_ops sandbox_i2c_ops = {
> .xfer = sandbox_i2c_xfer,
> };
> @@ -108,5 +99,4 @@ U_BOOT_DRIVER(i2c_sandbox) = {
> .of_match = sandbox_i2c_ids,
> .ops= _i2c_ops,
> .priv_auto_alloc_size = sizeof(struct sandbox_i2c_priv),
> -
Re: [PATCH v3 31/35] acpi: Add support for DSDT generation
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Some devices need to inject extra code into the Differentiated System
> Descriptor Table (DSDT). Add a method to handle this.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v3:
> - Fix 'THe' typo
> - Rename build_type() to sort_acpi_item_type()
>
> Changes in v1:
> - Generalise the ACPI function recursion with acpi_recurse_method()
>
> arch/sandbox/dts/test.dts | 2 ++
> drivers/core/acpi.c | 25 +-
> include/dm/acpi.h | 23
> test/dm/acpi.c| 44 +++
> 4 files changed, 93 insertions(+), 1 deletion(-)
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 993082763d..caf935cfdf 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -257,6 +257,7 @@
> acpi_test1: acpi-test {
> compatible = "denx,u-boot-acpi-test";
> acpi-ssdt-test-data = "ab";
> + acpi-dsdt-test-data = "hi";
> child {
> compatible = "denx,u-boot-acpi-test";
> };
> @@ -265,6 +266,7 @@
> acpi_test2: acpi-test2 {
> compatible = "denx,u-boot-acpi-test";
> acpi-ssdt-test-data = "cd";
> + acpi-dsdt-test-data = "jk";
> };
>
> clocks {
> diff --git a/drivers/core/acpi.c b/drivers/core/acpi.c
> index 4719a5c4e4..c1fc364550 100644
> --- a/drivers/core/acpi.c
> +++ b/drivers/core/acpi.c
> @@ -22,12 +22,14 @@
> enum gen_type_t {
> TYPE_NONE,
> TYPE_SSDT,
> + TYPE_DSDT,
> };
>
> /* Type of method to call */
> enum method_t {
> METHOD_WRITE_TABLES,
> METHOD_FILL_SSDT,
> + METHOD_INJECT_DSDT,
> };
>
> /* Prototype for all methods */
> @@ -144,7 +146,9 @@ static int sort_acpi_item_type(struct acpi_ctx *ctx, void
> *start,
> void *end = ctx->current;
>
> ptr = start;
> - order = ofnode_read_chosen_prop("u-boot,acpi-ssdt-order", );
> + order = ofnode_read_chosen_prop(type == TYPE_DSDT ?
> + "u-boot,acpi-dsdt-order" :
> + "u-boot,acpi-ssdt-order", );
> if (!order) {
> log_warning("Failed to find ordering, leaving as is\n");
> return 0;
> @@ -189,6 +193,8 @@ acpi_method acpi_get_method(struct udevice *dev, enum
> method_t method)
> return aops->write_tables;
> case METHOD_FILL_SSDT:
> return aops->fill_ssdt;
> + case METHOD_INJECT_DSDT:
> + return aops->inject_dsdt;
> }
> }
>
> @@ -247,6 +253,23 @@ int acpi_fill_ssdt(struct acpi_ctx *ctx)
> return ret;
> }
>
> +int acpi_inject_dsdt(struct acpi_ctx *ctx)
For naming consistency, this should be acpi_fill_dsdt(), or change the
ssdt one to: acpi_inject_ssdt() otherwise.
> +{
> + void *start = ctx->current;
> + int ret;
> +
> + log_debug("Writing DSDT tables\n");
> + item_count = 0;
> + ret = acpi_recurse_method(ctx, dm_root(), METHOD_INJECT_DSDT,
> + TYPE_DSDT);
> + log_debug("Writing DSDT finished, err=%d\n", ret);
> + ret = sort_acpi_item_type(ctx, start, TYPE_DSDT);
> + if (ret)
> + return log_msg_ret("build", ret);
> +
> + return ret;
> +}
> +
> int acpi_write_dev_tables(struct acpi_ctx *ctx)
> {
> int ret;
> diff --git a/include/dm/acpi.h b/include/dm/acpi.h
> index eda23f97a6..18bce2baf6 100644
> --- a/include/dm/acpi.h
> +++ b/include/dm/acpi.h
> @@ -87,6 +87,19 @@ struct acpi_ops {
> * @return 0 if OK, -ve on error
> */
> int (*fill_ssdt)(const struct udevice *dev, struct acpi_ctx *ctx);
> +
> + /**
> +* inject_dsdt() - Generate DSDT code for a device
> +*
> +* This is called to create the DSDT code. The method should write out
> +* whatever ACPI code is needed by this device. It will end up in the
> +* DSDT table.
> +*
> +* @dev: Device to write
> +* @ctx: ACPI context to use
> +* @return 0 if OK, -ve on error
> +*/
> + int (*inject_dsdt)(const struct udevice *dev, struct acpi_ctx *ctx);
> };
>
> #define device_get_acpi_ops(dev) ((dev)->driver->acpi_ops)
> @@ -141,6 +154,16 @@ int acpi_write_dev_tables(struct acpi_ctx *ctx);
> */
> int acpi_fill_ssdt(struct acpi_ctx *ctx);
>
> +/**
> + * acpi_inject_dsdt() - Generate ACPI tables for DSDT
> + *
> + * This is called to create the DSDT code for all devices.
> + *
> + * @ctx: ACPI context to use
> + * @return 0 if OK, -ve on error
> + */
> +int acpi_inject_dsdt(struct acpi_ctx *ctx);
> +
> #endif /* __ACPI__ */
>
> #endif
> diff --git a/test/dm/acpi.c
Re: [PATCH v3 32/35] x86: Allow devices to write to DSDT
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > Call the new core function to inject ASL programmatically into the DSDT. > This is made up of fragments generated by devices that have the > inject_dsdt() method. The normal, compiled ASL file is added after this. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Refactor the code to remove the extra memcpy() > - Recalculate the DSDT checksum only once > - Add a comment as to why the checksum byte is set to 0 > > arch/x86/lib/acpi_table.c | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 33/35] pci: Avoid a crash in device_is_on_pci_bus()
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > This function cannot currently be called on the root node. Add a check > for this as well as a test. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > include/dm/device.h | 2 +- > test/dm/pci.c | 14 ++ > 2 files changed, 15 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware
On 29/06/20 10:20 am, Jan Kiszka wrote:
> On 29.06.20 04:26, Lokesh Vutla wrote:
>> +Tom
>>
>> On 23/06/20 8:11 pm, Jan Kiszka wrote:
>>> On 23.06.20 14:37, Jan Kiszka wrote:
On 23.06.20 13:50, Lokesh Vutla wrote:
>
>
> On 23/06/20 4:45 pm, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> To avoid the need of extra boot scripting on AM65x for loading a
>> watchdog firmware, add the required rproc init and loading logic for the
>> first R5F core to the watchdog start handler. The firmware itself is
>> embedded into U-Boot binary.
>>
>> One possible firmware source is https://github.com/siemens/k3-rti-wdt.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>> drivers/watchdog/Kconfig | 20
>> drivers/watchdog/Makefile | 3 +++
>> drivers/watchdog/rti_wdt.c | 24
>> drivers/watchdog/rti_wdt_fw.S | 20
>> 4 files changed, 67 insertions(+)
>> create mode 100644 drivers/watchdog/rti_wdt_fw.S
>>
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>> index ee99bd2af1..fd6ab9a85b 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>> @@ -162,6 +162,26 @@ config WDT_K3_RTI
>> Say Y here if you want to include support for the K3 watchdog
>> timer (RTI module) available in the K3 generation of processors.
>> +if WDT_K3_RTI
>> +
>> +config WDT_K3_RTI_LOAD_FW
>> + bool "Load watchdog firmware"
>> + depends on REMOTEPROC
>> + help
>> + Automatically load the specified firmware image into the MCU R5F
>> + core 0. On the AM65x, this firmware is supposed to handle the
>> expiry
>> + of the watchdog timer, typically by resetting the system.
>> +
>> +config WDT_K3_RTI_FW_FILE
>> + string "Watchdog firmware image file"
>> + default "k3-rti-wdt.fw"
>> + depends on WDT_K3_RTI_LOAD_FW
>> + help
>> + Firmware image to be embedded into U-Boot and loaded on watchdog
>> + start.
>> +
>> +endif
>> +
>> config WDT_SANDBOX
>> bool "Enable Watchdog Timer support for Sandbox"
>> depends on SANDBOX && WDT
>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
>> index 16bdbf4970..bf58684875 100644
>> --- a/drivers/watchdog/Makefile
>> +++ b/drivers/watchdog/Makefile
>> @@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
>> obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
>> obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
>> obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o
>> +obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o
>> obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
>> obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
>> obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
>> obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o
>> +
>> +$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE))
>> FORCE
>> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
>> index ebe29c7409..38e82a6b6b 100644
>> --- a/drivers/watchdog/rti_wdt.c
>> +++ b/drivers/watchdog/rti_wdt.c
>> @@ -14,6 +14,7 @@
>> #include
>> #include
>> #include
>> +#include
>> /* Timer register set definition */
>> #define RTIDWDCTRL 0x90
>> @@ -37,11 +38,16 @@
>> #define WDT_PRELOAD_MAX 0xfff
>> +#define RTI_PROC_ID 0
>
> Can we get the rproc id from DT?
You mean, resolve "mcu_r5fss0_core0" to the ID? Doable.
>>>
>>> I'm now probing for the first instance of "ti,am654-r5f" compatible. That
>>> excludes usage for the J721E for now, but that one is fine without firmware
>>> -
>>> provided there is way to prevent power-down for RTI watchdog otherwise...
>>
>> I was more of thinking to have a DT property to reference R5-core. But
>> anyways,
>> the property is not present in kernel. I am okay with this for now.
>>
>>>
>
>> +
>> struct rti_wdt_priv {
>> phys_addr_t regs;
>> unsigned int clk_khz;
>> };
>> +extern const u32 rti_wdt_fw[];
>> +extern const int rti_wdt_fw_size;
>
> FIT is the preferred way of packing images in U-Boot. Can you try using
> it?
How does that work? Some example for me?
>>>
>>> If you happen to refer to fs-loader: That does not target OSPI, our primary
>>> use
>>> case.
>>
>> No. I was thinking to pack the image in FIT along with ATF and OPTEE like in
>> k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the
>> firmware.
>
> In case of our board, that image is not processed by U-Boot (only generated).
> Also, processing it from the R5 loader would imply putting remoteproc support
> into that level, duplicating what we have in A53 U-Boot.
>
>>
>>>
Re: [PATCH] rockchip: i2c: fix switch to new implementation for rk3188
Hi Alex,
Am 29.06.2020 um 05:23 schrieb David Wu:
Hi Alexander,
Thank you for your patch, the grf header file is missing for rk3066, the GRF_SOC_CON1 offset of 3066
is 0x154, the corresponding bit of i2c0~i2c4 is also bit11 ~ bit15.
There is currently no support for rk3066 at mainline, rk3066 is not handled here, I think it’s okay,
so,
Reviewed-by: David Wu
Reviewed-by: Heiko Schocher
@Kever: Do you pickup this patch?
(I cannot find it in patchwork, is it assigned to you?)
bye,
Heiko
在 2020/6/27 下午11:03, Alexander Kochetkov 写道:
To make clear, there is kernel driver i2c-rk3x.c.
For rk3066 it write bits in the GRF word at offset 0x154. See [1] and [2].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-rk3x.c#n1236
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-rk3x.c#n1137
In u-boot there is include file cru_rk3036.h [3]. If this include file valid for rk3066, than
offset 0x154 correspond
to soc_con3 register. But all documentation I found for 30xx SoC clarify that I2C switch bits
located in the
soc_con1 registers.
So I don’t know correct location for I2C switch bits.
[3]
https://github.com/u-boot/u-boot/blob/master/arch/arm/include/asm/arch-rockchip/cru_rk3036.h
27 июня 2020 г., в 17:17, Kever Yang написал(а):
+David,
Hi David,
Could you help to commend on this?
Hi Alex,
Thanks for your patch.
On 2020/6/22 下午9:06, Alexander Kochetkov wrote:
The commit e7ae4cf27a6d 'pinctrl: rockchip: Add common rockchip
pinctrl driver' dropped rk3188_pinctrl_request operation, that
did switching to new implementation.
This commit implement switching to new implementation using
writing bits to GRF.
I don't have rk3060
rk3066
board to test, so switching implemented
as a stub returning -ENOSYS.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/rk_i2c.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c
index 32b2ee8578..ad3c66843b 100644
--- a/drivers/i2c/rk_i2c.c
+++ b/drivers/i2c/rk_i2c.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -41,6 +43,7 @@ enum {
*/
struct rk_i2c_soc_data {
int controller_type;
+ int (*switch_to_new_type)(int bus_nr);
};
static inline void rk_i2c_get_div(int div, int *divh, int *divl)
@@ -388,11 +391,33 @@ static int rockchip_i2c_ofdata_to_platdata(struct udevice
*bus)
return 0;
}
+static int rockchip_i2c_switch_to_new_type_rk3066(int bus_nr)
+{
+ return -ENOSYS;
+}
+
+static int rockchip_i2c_switch_to_new_type_rk3188(int bus_nr)
+{
+ struct rk3188_grf *grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+
+ if (grf == NULL)
+ return -ENOSYS;
+
+ if (bus_nr < 0 || bus_nr > (RKI2C4_SEL_SHIFT - RKI2C0_SEL_SHIFT))
+ return -EINVAL;
+
+ /* enable new i2c controller */
+ rk_clrsetreg(>soc_con1,
+ 1 << (RKI2C0_SEL_SHIFT + bus_nr),
+ 1 << (RKI2C0_SEL_SHIFT + bus_nr));
+
+ return 0;
+}
+
static int rockchip_i2c_probe(struct udevice *bus)
{
struct rk_i2c *priv = dev_get_priv(bus);
struct rk_i2c_soc_data *soc_data;
- struct udevice *pinctrl;
int bus_nr;
int ret;
@@ -408,17 +433,10 @@ static int rockchip_i2c_probe(struct udevice *bus)
return ret;
}
- ret = uclass_get_device(UCLASS_PINCTRL, 0, );
- if (ret) {
- debug("%s: Cannot find pinctrl device\n", __func__);
- return ret;
- }
-
- /* pinctrl will switch I2C to new type */
- ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_I2C0 + bus_nr);
- if (ret) {
+ ret = soc_data->switch_to_new_type(bus_nr);
+ if (ret < 0) {
debug("%s: Failed to switch I2C to new type %s: %d\n",
- __func__, bus->name, ret);
+ __func__, bus->name, ret);
return ret;
}
}
@@ -433,10 +451,12 @@ static const struct dm_i2c_ops rockchip_i2c_ops = {
static const struct rk_i2c_soc_data rk3066_soc_data = {
.controller_type = RK_I2C_LEGACY,
+ .switch_to_new_type = rockchip_i2c_switch_to_new_type_rk3066,
};
static const struct rk_i2c_soc_data rk3188_soc_data = {
.controller_type = RK_I2C_LEGACY,
+ .switch_to_new_type = rockchip_i2c_switch_to_new_type_rk3188,
};
static const struct rk_i2c_soc_data rk3228_soc_data = {
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware
On 29.06.20 04:26, Lokesh Vutla wrote:
+Tom
On 23/06/20 8:11 pm, Jan Kiszka wrote:
On 23.06.20 14:37, Jan Kiszka wrote:
On 23.06.20 13:50, Lokesh Vutla wrote:
On 23/06/20 4:45 pm, Jan Kiszka wrote:
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. The firmware itself is
embedded into U-Boot binary.
One possible firmware source is https://github.com/siemens/k3-rti-wdt.
Signed-off-by: Jan Kiszka
---
drivers/watchdog/Kconfig | 20
drivers/watchdog/Makefile | 3 +++
drivers/watchdog/rti_wdt.c | 24
drivers/watchdog/rti_wdt_fw.S | 20
4 files changed, 67 insertions(+)
create mode 100644 drivers/watchdog/rti_wdt_fw.S
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ee99bd2af1..fd6ab9a85b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -162,6 +162,26 @@ config WDT_K3_RTI
Say Y here if you want to include support for the K3 watchdog
timer (RTI module) available in the K3 generation of processors.
+if WDT_K3_RTI
+
+config WDT_K3_RTI_LOAD_FW
+ bool "Load watchdog firmware"
+ depends on REMOTEPROC
+ help
+ Automatically load the specified firmware image into the MCU R5F
+ core 0. On the AM65x, this firmware is supposed to handle the expiry
+ of the watchdog timer, typically by resetting the system.
+
+config WDT_K3_RTI_FW_FILE
+ string "Watchdog firmware image file"
+ default "k3-rti-wdt.fw"
+ depends on WDT_K3_RTI_LOAD_FW
+ help
+ Firmware image to be embedded into U-Boot and loaded on watchdog
+ start.
+
+endif
+
config WDT_SANDBOX
bool "Enable Watchdog Timer support for Sandbox"
depends on SANDBOX && WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 16bdbf4970..bf58684875 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o
+obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o
obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o
+
+$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE)) FORCE
diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
index ebe29c7409..38e82a6b6b 100644
--- a/drivers/watchdog/rti_wdt.c
+++ b/drivers/watchdog/rti_wdt.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/* Timer register set definition */
#define RTIDWDCTRL 0x90
@@ -37,11 +38,16 @@
#define WDT_PRELOAD_MAX 0xfff
+#define RTI_PROC_ID 0
Can we get the rproc id from DT?
You mean, resolve "mcu_r5fss0_core0" to the ID? Doable.
I'm now probing for the first instance of "ti,am654-r5f" compatible. That
excludes usage for the J721E for now, but that one is fine without firmware -
provided there is way to prevent power-down for RTI watchdog otherwise...
I was more of thinking to have a DT property to reference R5-core. But anyways,
the property is not present in kernel. I am okay with this for now.
+
struct rti_wdt_priv {
phys_addr_t regs;
unsigned int clk_khz;
};
+extern const u32 rti_wdt_fw[];
+extern const int rti_wdt_fw_size;
FIT is the preferred way of packing images in U-Boot. Can you try using it?
How does that work? Some example for me?
If you happen to refer to fs-loader: That does not target OSPI, our primary use
case.
No. I was thinking to pack the image in FIT along with ATF and OPTEE like in
k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the
firmware.
In case of our board, that image is not processed by U-Boot (only
generated). Also, processing it from the R5 loader would imply putting
remoteproc support into that level, duplicating what we have in A53 U-Boot.
What benefit would that bring? There are other users of this pattern, e.g.
board/xilinx/zynqmp/pm_cfg_obj.S.
I didn't know U-Boot is accepting this. Tom, is this the preferred way for
including firmware images?
The only benefit of an alternative loading mechanism seems to be handling of
larger images from different sources. But that's what I would tackle via boot
scripting and, thus, without this feature. If you only have a few hundred bytes
to embed, like for k3-rti-wdt, you quickly have a lot of overhead with other
approaches.
hmm.. Does the build break if firmware is not present?
Yes, if you configure to include the firmware but specify an invalid
path, the build breaks.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Re: [PATCH v3 29/35] acpi: Support ordering SSDT data by device
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a /chosen property to control the order in which the data appears
> in the SSDT. This allows matching up U-Boot's output from a dump of the
> known-good data obtained from within Linux.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Make find_item() static and rename to find_acpi_item()
> - Rename build_type() and add a comment
>
> Changes in v1:
> - Generalise the ACPI function recursion with acpi_recurse_method()
>
> arch/sandbox/dts/test.dts | 5 +-
> doc/device-tree-bindings/chosen.txt | 9
> drivers/core/acpi.c | 75 +
> test/dm/acpi.c | 15 +++---
> 4 files changed, 96 insertions(+), 8 deletions(-)
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 30394946f8..993082763d 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -254,7 +254,7 @@
> compatible = "denx,u-boot-devres-test";
> };
>
> - acpi-test {
> + acpi_test1: acpi-test {
> compatible = "denx,u-boot-acpi-test";
> acpi-ssdt-test-data = "ab";
> child {
> @@ -262,7 +262,7 @@
> };
> };
>
> - acpi-test2 {
> + acpi_test2: acpi-test2 {
> compatible = "denx,u-boot-acpi-test";
> acpi-ssdt-test-data = "cd";
> };
> @@ -895,6 +895,7 @@
> setting = "sunrise ohoka";
> other-node = "/some-bus/c-test@5";
> int-values = <0x1937 72993>;
> + u-boot,acpi-ssdt-order = <_test2 _test1>;
> chosen-test {
> compatible = "denx,u-boot-fdt-test";
> reg = <9 1>;
> diff --git a/doc/device-tree-bindings/chosen.txt
> b/doc/device-tree-bindings/chosen.txt
> index 395c9501e3..d4dfc05847 100644
> --- a/doc/device-tree-bindings/chosen.txt
> +++ b/doc/device-tree-bindings/chosen.txt
> @@ -134,3 +134,12 @@ Example
> phandlepart = < 1>;
> };
> };
> +
> +u-boot,acpi-ssdt-order
> +--
> +
> +This provides the ordering to use when writing device data to the ACPI SSDT
> +(Secondary System Descriptor Table). Each cell is a phandle pointer to a
> device
> +node to add. The ACPI information is written in this order.
> +
> +If the ordering does not include all nodes, an error is generated.
> diff --git a/drivers/core/acpi.c b/drivers/core/acpi.c
> index df3d7ba417..4719a5c4e4 100644
> --- a/drivers/core/acpi.c
> +++ b/drivers/core/acpi.c
> @@ -108,6 +108,76 @@ static int acpi_add_item(struct acpi_ctx *ctx, struct
> udevice *dev,
> return 0;
> }
>
> +static struct acpi_item *find_acpi_item(const char *devname)
> +{
> + int i;
> +
> + for (i = 0; i < item_count; i++) {
> + struct acpi_item *item = _item[i];
> +
> + if (!strcmp(devname, item->dev->name))
> + return item;
> + }
> +
> + return NULL;
> +}
> +
> +/**
> + * sort_acpi_item_type - Sort the ACPI items into the desired order
> + *
> + * This looks up the ordering in the device tree and then adds each item one
> by
> + * one into the supplied buffer
> + *
> + * @ctx: ACPI context
> + * @start: Start position to put the sorted items. The items will follow each
> + * other in sorted order
> + * @type: Type of items to sort
> + * @return 0 if OK, -ve on error
> + */
> +static int sort_acpi_item_type(struct acpi_ctx *ctx, void *start,
> + enum gen_type_t type)
> +{
> + const u32 *order;
> + int size;
> + int count;
> + void *ptr;
> + void *end = ctx->current;
> +
> + ptr = start;
> + order = ofnode_read_chosen_prop("u-boot,acpi-ssdt-order", );
> + if (!order) {
> + log_warning("Failed to find ordering, leaving as is\n");
> + return 0;
> + }
> +
> + count = size / sizeof(u32);
> + while (count--) {
> + struct acpi_item *item;
> + const char *name;
> + ofnode node;
> +
> + node = ofnode_get_by_phandle(fdt32_to_cpu(*order++));
> + name = ofnode_get_name(node);
> + item = find_acpi_item(name);
> + if (!item) {
> + log_err("Failed to find item '%s'\n", name);
> + return log_msg_ret("find", -ENOENT);
> + }
> + if (item->type == type) {
> + log_debug(" - add %s\n", item->dev->name);
> + memcpy(ptr, item->buf, item->size);
> + ptr += item->size;
Should ctx->current be updated?
> + }
> + }
> +
> + if (ptr != end) {
> + log_warning("*** Missing bytes: ptr=%p, end=%p\n", ptr, end);
> + return -ENXIO;
> +
Re: [PATCH v3 28/35] acpi: Record the items added to SSDT
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > It is useful to be able to control the order of data written to the SSDT > so that we can compare the output against known-good kernel dumps. > > Add code to record each item that is added along with the device that > added it. That allows us to reorder things later if needed. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > Changes in v3: > - Rename MAX_ITEMS to MAX_ACPI_ITEMS > > Changes in v1: > - Generalise the ACPI function recursion with acpi_recurse_method() > > drivers/core/acpi.c | 83 ++--- > 1 file changed, 79 insertions(+), 4 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 30/35] x86: Allow devices to write an SSDT
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > Call the new core function to write the SSDT. This is made up of fragments > generated by devices that have the fill_ssdt() method. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > Drop coreboot_acpi_ids enum > > Changes in v1: > - Use OEM_TABLE_ID instead of ACPI_TABLE_CREATOR > - Update ACPI_DSTATUS enum > - Drop writing of coreboot tables > > arch/x86/lib/acpi_table.c | 29 + > 1 file changed, 29 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 27/35] x86: acpi: Move MADT down a bit
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > Put this table before MCFG so that it matches the order that coreboot uses > when passing tables to Linux. This is a cosmetic change since the order of > the tables does not otherwise matter. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > Changes in v1: > - Correct the commit subject > > arch/x86/lib/acpi_table.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 26/35] acpi: Add support for SSDT generation
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > Some devices need to generate code for the Secondary System Descriptor > Table (SSDT). Add a method to handle this. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > Changes in v3: > - Fix 'THe' typo > > Changes in v1: > - Switch parameter order of _acpi_fill_ssdt() and make it static > - Fix 'sentinal' and 'METHOD_FILL_SDDT' typos > > arch/sandbox/dts/test.dts | 2 ++ > drivers/core/acpi.c | 14 + > include/dm/acpi.h | 23 + > test/dm/acpi.c| 42 +++ > 4 files changed, 81 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH] rockchip: i2c: fix switch to new implementation for rk3188
Hi Alexander,
Thank you for your patch, the grf header file is missing for rk3066, the
GRF_SOC_CON1 offset of 3066 is 0x154, the corresponding bit of i2c0~i2c4
is also bit11 ~ bit15.
There is currently no support for rk3066 at mainline, rk3066 is not
handled here, I think it’s okay, so,
Reviewed-by: David Wu
在 2020/6/27 下午11:03, Alexander Kochetkov 写道:
To make clear, there is kernel driver i2c-rk3x.c.
For rk3066 it write bits in the GRF word at offset 0x154. See [1] and [2].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-rk3x.c#n1236
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/busses/i2c-rk3x.c#n1137
In u-boot there is include file cru_rk3036.h [3]. If this include file valid
for rk3066, than offset 0x154 correspond
to soc_con3 register. But all documentation I found for 30xx SoC clarify that
I2C switch bits located in the
soc_con1 registers.
So I don’t know correct location for I2C switch bits.
[3]
https://github.com/u-boot/u-boot/blob/master/arch/arm/include/asm/arch-rockchip/cru_rk3036.h
27 июня 2020 г., в 17:17, Kever Yang написал(а):
+David,
Hi David,
Could you help to commend on this?
Hi Alex,
Thanks for your patch.
On 2020/6/22 下午9:06, Alexander Kochetkov wrote:
The commit e7ae4cf27a6d 'pinctrl: rockchip: Add common rockchip
pinctrl driver' dropped rk3188_pinctrl_request operation, that
did switching to new implementation.
This commit implement switching to new implementation using
writing bits to GRF.
I don't have rk3060
rk3066
board to test, so switching implemented
as a stub returning -ENOSYS.
Signed-off-by: Alexander Kochetkov
---
drivers/i2c/rk_i2c.c | 42 +++---
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c
index 32b2ee8578..ad3c66843b 100644
--- a/drivers/i2c/rk_i2c.c
+++ b/drivers/i2c/rk_i2c.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -41,6 +43,7 @@ enum {
*/
struct rk_i2c_soc_data {
int controller_type;
+ int (*switch_to_new_type)(int bus_nr);
};
static inline void rk_i2c_get_div(int div, int *divh, int *divl)
@@ -388,11 +391,33 @@ static int rockchip_i2c_ofdata_to_platdata(struct udevice
*bus)
return 0;
}
+static int rockchip_i2c_switch_to_new_type_rk3066(int bus_nr)
+{
+ return -ENOSYS;
+}
+
+static int rockchip_i2c_switch_to_new_type_rk3188(int bus_nr)
+{
+ struct rk3188_grf *grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+
+ if (grf == NULL)
+ return -ENOSYS;
+
+ if (bus_nr < 0 || bus_nr > (RKI2C4_SEL_SHIFT - RKI2C0_SEL_SHIFT))
+ return -EINVAL;
+
+ /* enable new i2c controller */
+ rk_clrsetreg(>soc_con1,
+1 << (RKI2C0_SEL_SHIFT + bus_nr),
+1 << (RKI2C0_SEL_SHIFT + bus_nr));
+
+ return 0;
+}
+
static int rockchip_i2c_probe(struct udevice *bus)
{
struct rk_i2c *priv = dev_get_priv(bus);
struct rk_i2c_soc_data *soc_data;
- struct udevice *pinctrl;
int bus_nr;
int ret;
@@ -408,17 +433,10 @@ static int rockchip_i2c_probe(struct udevice *bus)
return ret;
}
- ret = uclass_get_device(UCLASS_PINCTRL, 0, );
- if (ret) {
- debug("%s: Cannot find pinctrl device\n", __func__);
- return ret;
- }
-
- /* pinctrl will switch I2C to new type */
- ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_I2C0 + bus_nr);
- if (ret) {
+ ret = soc_data->switch_to_new_type(bus_nr);
+ if (ret < 0) {
debug("%s: Failed to switch I2C to new type %s: %d\n",
- __func__, bus->name, ret);
+__func__, bus->name, ret);
return ret;
}
}
@@ -433,10 +451,12 @@ static const struct dm_i2c_ops rockchip_i2c_ops = {
static const struct rk_i2c_soc_data rk3066_soc_data = {
.controller_type = RK_I2C_LEGACY,
+ .switch_to_new_type = rockchip_i2c_switch_to_new_type_rk3066,
};
static const struct rk_i2c_soc_data rk3188_soc_data = {
.controller_type = RK_I2C_LEGACY,
+ .switch_to_new_type = rockchip_i2c_switch_to_new_type_rk3188,
};
static const struct rk_i2c_soc_data rk3228_soc_data = {
Re: [PATCH v3 1/2] drivers: tee: broadcom: add optee based bnxt fw load driver
Hi Simon,
On Fri, Jun 26, 2020 at 6:42 AM Simon Glass wrote:
>
> Hi Rayagonda,
>
> On Wed, 10 Jun 2020 at 05:15, Rayagonda Kokatanur
> wrote:
> >
> > From: Vikas Gupta
> >
> > Add optee based bnxt fw load driver.
> > bnxt is Broadcom NetXtreme controller Ethernet card.
> > This driver is used to load bnxt firmware binary using OpTEE.
> >
> > Signed-off-by: Vikas Gupta
> > Signed-off-by: Rayagonda Kokatanur
> > ---
> > Changes from v2:
> > -Address review comments from Simon,
> > Remove own return code and use standard error code.
> > Take out common lines from different functions and move them
> > into common static function.
> > Remove include as its not required.
> > Move functions with printf from header file into c file.
> >
> > drivers/tee/Kconfig| 1 +
> > drivers/tee/Makefile | 1 +
> > drivers/tee/broadcom/Kconfig | 7 ++
> > drivers/tee/broadcom/Makefile | 3 +
> > drivers/tee/broadcom/chimp_optee.c | 182 +
> > include/broadcom/chimp.h | 16 +++
> > 6 files changed, 210 insertions(+)
> > create mode 100644 drivers/tee/broadcom/Kconfig
> > create mode 100644 drivers/tee/broadcom/Makefile
> > create mode 100644 drivers/tee/broadcom/chimp_optee.c
> > create mode 100644 include/broadcom/chimp.h
> >
> > diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
> > index 5c0c89043f..5ca5a0836c 100644
> > --- a/drivers/tee/Kconfig
> > +++ b/drivers/tee/Kconfig
> > @@ -29,6 +29,7 @@ config SANDBOX_TEE
> > "avb" commands.
> >
> > source "drivers/tee/optee/Kconfig"
> > +source "drivers/tee/broadcom/Kconfig"
> >
> > endmenu
> >
> > diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
> > index f72c68c09f..5c8ffdbce8 100644
> > --- a/drivers/tee/Makefile
> > +++ b/drivers/tee/Makefile
> > @@ -3,3 +3,4 @@
> > obj-y += tee-uclass.o
> > obj-$(CONFIG_SANDBOX) += sandbox.o
> > obj-$(CONFIG_OPTEE) += optee/
> > +obj-y += broadcom/
> > diff --git a/drivers/tee/broadcom/Kconfig b/drivers/tee/broadcom/Kconfig
> > new file mode 100644
> > index 00..ce95072d4e
> > --- /dev/null
> > +++ b/drivers/tee/broadcom/Kconfig
> > @@ -0,0 +1,7 @@
> > +config CHIMP_OPTEE
> > + bool "Enable secure ChiMP firmware loading"
> > + depends on OPTEE
> > + default y
> > + help
> > + This driver is used to load bnxt firmware binary using OpTEE.
> > + bnxt is Broadcom NetXtreme controller Ethernet card.
> > diff --git a/drivers/tee/broadcom/Makefile b/drivers/tee/broadcom/Makefile
> > new file mode 100644
> > index 00..cb3cef16df
> > --- /dev/null
> > +++ b/drivers/tee/broadcom/Makefile
> > @@ -0,0 +1,3 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +
> > +obj-y += chimp_optee.o
> > diff --git a/drivers/tee/broadcom/chimp_optee.c
> > b/drivers/tee/broadcom/chimp_optee.c
> > new file mode 100644
> > index 00..4ca1b59c6a
> > --- /dev/null
> > +++ b/drivers/tee/broadcom/chimp_optee.c
> > @@ -0,0 +1,182 @@
> > +// SPDX-License-Identifier: BSD-2-Clause
> > +/*
> > + * Copyright 2020 Broadcom.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#ifdef CONFIG_CHIMP_OPTEE
> > +
> > +#define CHMIP_BOOT_UUID { 0x6272636D, 0x2019, 0x0716, \
> > + { 0x42, 0x43, 0x4D, 0x5F, 0x53, 0x43, 0x48, 0x49 } }
> > +
> > +enum {
> > + TEE_CHIMP_FASTBOOT = 0,
> > + TEE_CHIMP_HEALTH_STATUS,
> > + TEE_CHIMP_HANDSHAKE_STATUS,
> > +} tee_chmip_cmd;
> > +
> > +struct bcm_chimp_data {
> > + struct udevice *tee;
> > + u32 session;
> > +} chimp_data;
> > +
> > +static int get_open_session(struct bcm_chimp_data *b_data)
> > +{
> > + struct udevice *tee = NULL;
> > +
> > + while (!b_data->tee) {
> > + const struct tee_optee_ta_uuid uuid = CHMIP_BOOT_UUID;
> > + struct tee_open_session_arg arg;
> > + int rc;
> > +
> > + tee = tee_find_device(tee, NULL, NULL, NULL);
> > + if (!tee)
> > + return -ENODEV;
> > +
> > + memset(, 0, sizeof(arg));
> > + tee_optee_ta_uuid_to_octets(arg.uuid, );
> > + rc = tee_open_session(tee, , 0, NULL);
> > + if (!rc) {
> > + b_data->tee = tee;
> > + b_data->session = arg.session;
> > + }
> > + }
> > +
>
> Is this looping forever? Should you return -ETIMEDOUT using
> get_timer() to check this?
Its not an infinite loop.
Within the loop we are looking for our device.
Once all device iteration is over loop will exit or if we find our
device it will exit.
>
> > diff --git a/include/broadcom/chimp.h b/include/broadcom/chimp.h
> > new file mode 100644
> > index 00..2397e13da0
> > --- /dev/null
> > +++ b/include/broadcom/chimp.h
> > @@ -0,0 +1,16 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright 2020 Broadcom.
> > + *
> > + */
> > +
> > +#ifndef
Re: [PATCH v3 23/35] acpi: Add support for writing a Power Resource
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > These are used in ACPI to disable power to various pats of the system when > in sleep. Add a way to create a power resource, with the caller finishing > off the details. > > Reviewed-by: Wolfgang Wallner > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > include/acpi/acpigen.h | 22 ++ > lib/acpi/acpigen.c | 22 ++ > test/dm/acpigen.c | 41 + > 3 files changed, 85 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 24/35] acpi: Add support for writing a GPIO power sequence
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Power to some devices is controlled by GPIOs. Add a way to generate ACPI
> code to enable and disable a GPIO so that this can be handled within an
> ACPI method.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpigen.h | 12 +++
> lib/acpi/acpigen.c | 80 ++
> test/dm/acpigen.c | 54
> 3 files changed, 146 insertions(+)
>
> diff --git a/include/acpi/acpigen.h b/include/acpi/acpigen.h
> index d7a7f2f538..d68dca5dde 100644
> --- a/include/acpi/acpigen.h
> +++ b/include/acpi/acpigen.h
> @@ -13,6 +13,7 @@
> #include
>
> struct acpi_ctx;
> +struct acpi_gpio;
>
> /* Top 4 bits of the value used to indicate a three-byte length value */
> #define ACPI_PKG_LEN_3_BYTES 0x80
> @@ -340,4 +341,15 @@ void acpigen_write_power_res(struct acpi_ctx *ctx, const
> char *name, uint level,
> uint order, const char *const dev_states[],
> size_t dev_states_count);
>
> +/*
> + * Helper functions for enabling/disabling Tx GPIOs based on the GPIO
> + * polarity. These functions end up calling acpigen_soc_{set,clear}_tx_gpio
> to
> + * make callbacks into SoC acpigen code.
> + *
> + * Returns 0 on success and -1 on error.
> + */
> +int acpigen_set_enable_tx_gpio(struct acpi_ctx *ctx, u32 tx_state_val,
> + const char *dw0_name, struct acpi_gpio *gpio,
What is dw0? Is dw0 generic stuff or GPIO specific? Need a comment
block for parameter descriptions.
> + bool enable);
> +
> #endif
> diff --git a/lib/acpi/acpigen.c b/lib/acpi/acpigen.c
> index 5df6ebe334..e0af36f775 100644
> --- a/lib/acpi/acpigen.c
> +++ b/lib/acpi/acpigen.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> u8 *acpigen_get_current(struct acpi_ctx *ctx)
> @@ -392,3 +393,82 @@ void acpigen_write_debug_string(struct acpi_ctx *ctx,
> const char *str)
> acpigen_write_string(ctx, str);
> acpigen_emit_ext_op(ctx, DEBUG_OP);
> }
> +
> +/**
> + * acpigen_get_dw0_in_local5() - Generate code to put dw0 cfg0 in local5
Could you please explain why we put dw0 to local5? How about other
local objects?
> + *
> + * @ctx: ACPI context pointer
> + * @dw0_name: Name to use (e.g. "\\_SB.GPC0")
> + * @addr: GPIO pin configuration register address
> + *
> + * Store (\_SB.GPC0 (addr), Local5)
> + * \_SB.GPC0 is used to read cfg0 value from dw0. It is typically defined in
> + * the board's gpiolib.asl
> + */
> +static void acpigen_get_dw0_in_local5(struct acpi_ctx *ctx,
> + const char *dw0_name, ulong addr)
> +{
> + acpigen_write_store(ctx);
> + acpigen_emit_namestring(ctx, dw0_name);
> + acpigen_write_integer(ctx, addr);
> + acpigen_emit_byte(ctx, LOCAL5_OP);
> +}
> +
> +/**
> + * acpigen_set_gpio_val() - Set value of TX GPIO to on/off
> + *
> + * @ctx: ACPI context pointer
> + * @dw0_name: Name to use (e.g. "\\_SB.GPC0")
> + * @gpio_num: GPIO number to adjust
> + * @vaL: true to set on, false to set off
> + */
> +static int acpigen_set_gpio_val(struct acpi_ctx *ctx, u32 tx_state_val,
> + const char *dw0_name, struct acpi_gpio *gpio,
> + bool val)
> +{
> + acpigen_get_dw0_in_local5(ctx, dw0_name, gpio->pin0_addr);
> +
> + if (val) {
> + /* Or (Local5, PAD_CFG0_TX_STATE, Local5) */
> + acpigen_write_or(ctx, LOCAL5_OP, tx_state_val, LOCAL5_OP);
> + } else {
> + /* Not (PAD_CFG0_TX_STATE, Local6) */
> + acpigen_write_not(ctx, tx_state_val, LOCAL6_OP);
> +
> + /* And (Local5, Local6, Local5) */
> + acpigen_write_and(ctx, LOCAL5_OP, LOCAL6_OP, LOCAL5_OP);
> + }
> +
> + /*
> +* \_SB.SPC0 (addr, Local5)
> +* \_SB.SPC0 is used to write cfg0 value in dw0. It is defined in
> +* gpiolib.asl.
> +*/
> + acpigen_emit_namestring(ctx, dw0_name);
> + acpigen_write_integer(ctx, gpio->pin0_addr);
> + acpigen_emit_byte(ctx, LOCAL5_OP);
> +
> + return 0;
> +}
> +
> +/*
> + * Helper functions for enabling/disabling Tx GPIOs based on the GPIO
> + * polarity. These functions end up calling acpigen_{set,clear}_tx_gpio to
> + * make callbacks into SoC acpigen code.
> + *
> + * Returns 0 on success and -1 on error.
> + */
> +int acpigen_set_enable_tx_gpio(struct acpi_ctx *ctx, u32 tx_state_val,
> + const char *dw0_name, struct acpi_gpio *gpio,
> + bool enable)
> +{
> + bool set;
> + int ret;
> +
> + set = gpio->polarity == ACPI_GPIO_ACTIVE_HIGH ? enable : !enable;
> + ret = acpigen_set_gpio_val(ctx, tx_state_val, dw0_name, gpio, set);
> + if (ret)
Re: [PATCH v3 21/35] acpi: Support copying properties from device tree to ACPI
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Some drivers in Linux support both device tree and ACPI. U-Boot itself
> uses Linux device-tree bindings for its own configuration but does not use
> ACPI.
>
> It is convenient to copy these values over to the device tree for passing
copy these values over to "ACPI DP table"
> to linux. Add some convenience functions to help with this.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Fix incorrect function names and arguments in commments
> - Add error checking for acpi_dp_add...() functions
>
> arch/sandbox/dts/test.dts | 1 +
> include/acpi/acpi_dp.h| 51 +
> lib/acpi/acpi_dp.c| 56
> test/dm/acpi_dp.c | 67 +++
> 4 files changed, 175 insertions(+)
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index bad0b4f1a8..173778b09c 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -111,6 +111,7 @@
> uint-value = <(-1234)>;
> int64-value = /bits/ 64 <0x>;
> int-array = <5678 9123 4567>;
> + str-value = "test string";
> interrupts-extended = < 3 0>;
> };
>
> diff --git a/include/acpi/acpi_dp.h b/include/acpi/acpi_dp.h
> index efbec3d152..a90abcb102 100644
> --- a/include/acpi/acpi_dp.h
> +++ b/include/acpi/acpi_dp.h
> @@ -228,9 +228,60 @@ struct acpi_dp *acpi_dp_add_gpio(struct acpi_dp *dp,
> const char *name,
> *
> * This writes the table using acpigen and then frees it
> *
> + * @ctx: ACPI context
This change should be squashed into "[v3,19/35] acpi: Support writing
Device Properties objects via _DSD"
> * @table: Table to write
> * @return 0 if OK, -ve on error
> */
> int acpi_dp_write(struct acpi_ctx *ctx, struct acpi_dp *table);
>
> +/**
> + * acpi_dp_ofnode_copy_int() - Copy a property from device tree to DP
> + *
> + * This copies an integer property from the device tree to the ACPI DP table.
> + *
> + * @node: Node to copy from
> + * @dp: DP to copy to
> + * @prop: Property name to copy
> + * @return 0 if OK, -ve on error
> + */
> +int acpi_dp_ofnode_copy_int(ofnode node, struct acpi_dp *dp, const char
> *prop);
> +
> +/**
> + * acpi_dp_ofnode_copy_str() - Copy a property from device tree to DP
> + *
> + * This copies a string property from the device tree to the ACPI DP table.
> + *
> + * @node: Node to copy from
> + * @dp: DP to copy to
> + * @prop: Property name to copy
> + * @return 0 if OK, -ve on error
> + */
> +int acpi_dp_ofnode_copy_str(ofnode node, struct acpi_dp *dp, const char
> *prop);
> +
> +/**
> + * acpi_dp_dev_copy_int() - Copy a property from device tree to DP
> + *
> + * This copies an integer property from the device tree to the ACPI DP table.
> + *
> + * @dev: Device to copy from
> + * @dp: DP to copy to
> + * @prop: Property name to copy
> + * @return 0 if OK, -ve on error
> + */
> +int acpi_dp_dev_copy_int(const struct udevice *dev, struct acpi_dp *dp,
> +const char *prop);
> +
> +/**
> + * acpi_dp_dev_copy_str() - Copy a property from device tree to DP
> + *
> + * This copies a string property from the device tree to the ACPI DP table.
> + *
> + * @dev: Device to copy from
> + * @dp: DP to copy to
> + * @prop: Property name to copy
> + * @return 0 if OK, -ve on error
> + */
> +int acpi_dp_dev_copy_str(const struct udevice *dev, struct acpi_dp *dp,
> +const char *prop);
> +
> #endif
> diff --git a/lib/acpi/acpi_dp.c b/lib/acpi/acpi_dp.c
> index 4ff857a451..e85f077cc2 100644
> --- a/lib/acpi/acpi_dp.c
> +++ b/lib/acpi/acpi_dp.c
> @@ -344,3 +344,59 @@ struct acpi_dp *acpi_dp_add_gpio(struct acpi_dp *dp,
> const char *name,
>
> return gpio;
> }
> +
> +int acpi_dp_ofnode_copy_int(ofnode node, struct acpi_dp *dp, const char
> *prop)
> +{
> + int ret;
> + u32 val = 0;
> +
> + ret = ofnode_read_u32(node, prop, );
> + if (ret)
> + return ret;
> + if (!acpi_dp_add_integer(dp, prop, val))
> + return log_ret(-ENOMEM);
> +
> + return 0;
> +}
> +
> +int acpi_dp_ofnode_copy_str(ofnode node, struct acpi_dp *dp, const char
> *prop)
> +{
> + const char *val;
> +
> + val = ofnode_read_string(node, prop);
> + if (!val)
> + return -EINVAL;
> + if (!acpi_dp_add_string(dp, prop, val))
> + return log_ret(-ENOMEM);
> +
> + return 0;
> +}
> +
> +int acpi_dp_dev_copy_int(const struct udevice *dev, struct acpi_dp *dp,
> +const char *prop)
> +{
> + int ret;
> + u32 val = 0;
> +
> + ret = dev_read_u32(dev, prop, );
> + if (ret)
> + return ret;
> + if (!acpi_dp_add_integer(dp, prop, val))
> + return log_ret(-ENOMEM);
> +
> + return ret;
> +}
> +
> +int acpi_dp_dev_copy_str(const
Re: [PATCH v3 22/35] acpi: Add support for various misc ACPI opcodes
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add more functions to handle some miscellaneous ACPI opcodes.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v3:
> - Fix function name in comment for acpigen_write_not()
> - Use #defines for the mask values
>
> include/acpi/acpigen.h | 117 +
> lib/acpi/acpigen.c | 84 +
> test/dm/acpigen.c | 75 ++
> 3 files changed, 276 insertions(+)
>
> diff --git a/include/acpi/acpigen.h b/include/acpi/acpigen.h
> index 40cd72504a..d640324986 100644
> --- a/include/acpi/acpigen.h
> +++ b/include/acpi/acpigen.h
> @@ -17,6 +17,9 @@ struct acpi_ctx;
> /* Top 4 bits of the value used to indicate a three-byte length value */
> #define ACPI_PKG_LEN_3_BYTES 0x80
>
> +#define ACPI_METHOD_NARGS_MASK 0x7
> +#define ACPI_METHOD_SERIALIZED_MASKBIT(3)
> +
> /* ACPI Op/Prefix codes */
> enum {
> ZERO_OP = 0x00,
> @@ -29,9 +32,26 @@ enum {
> QWORD_PREFIX= 0x0e,
> BUFFER_OP = 0x11,
> PACKAGE_OP = 0x12,
> + METHOD_OP = 0x14,
> + SLEEP_OP= 0x22,
> DUAL_NAME_PREFIX= 0x2e,
> MULTI_NAME_PREFIX = 0x2f,
> + DEBUG_OP= 0x31,
> + EXT_OP_PREFIX = 0x5b,
> ROOT_PREFIX = 0x5c,
> + LOCAL0_OP = 0x60,
> + LOCAL1_OP = 0x61,
> + LOCAL2_OP = 0x62,
> + LOCAL3_OP = 0x63,
> + LOCAL4_OP = 0x64,
> + LOCAL5_OP = 0x65,
> + LOCAL6_OP = 0x66,
> + LOCAL7_OP = 0x67,
> + STORE_OP= 0x70,
> + AND_OP = 0x7b,
> + OR_OP = 0x7d,
> + NOT_OP = 0x80,
> + RETURN_OP = 0xa4,
> };
>
> /**
> @@ -201,4 +221,101 @@ void acpigen_write_name(struct acpi_ctx *ctx, const
> char *namepath);
> */
> int acpigen_write_uuid(struct acpi_ctx *ctx, const char *uuid);
>
> +/**
> + * acpigen_emit_ext_op() - Emit an extended op with the EXT_OP_PREFIX prefix
> + *
> + * @ctx: ACPI context pointer
> + * @op: Operation code (e.g. SLEEP_OP)
> + */
> +void acpigen_emit_ext_op(struct acpi_ctx *ctx, uint op);
> +
> +/**
> + * acpigen_write_method() - Write a method header
> + *
> + * @ctx: ACPI context pointer
> + * @name: Method name (4 characters)
> + * @nargs: Number of method arguments (0 if none)
> + */
> +void acpigen_write_method(struct acpi_ctx *ctx, const char *name, int nargs);
> +
> +/**
> + * acpigen_write_method_serialized() - Write a method header
> + *
> + * This sets the 'serialized' flag so that the method is thread-safe
> + *
> + * @ctx: ACPI context pointer
> + * @name: Method name (4 characters)
> + * @nargs: Number of method arguments (0 if none)
> + */
> +void acpigen_write_method_serialized(struct acpi_ctx *ctx, const char *name,
> +int nargs);
> +
> +/**
> + * acpigen_write_sta() - Write a _STA method
> + *
> + * @ctx: ACPI context pointer
> + * @status: Status value to return
> + */
> +void acpigen_write_sta(struct acpi_ctx *ctx, uint status);
> +
> +/**
> + * acpigen_write_sleep() - Write a sleep operation
> + *
> + * @ctx: ACPI context pointer
> + * @sleep_ms: Number of milliseconds to sleep for
> + */
> +void acpigen_write_sleep(struct acpi_ctx *ctx, u64 sleep_ms);
> +
> +/**
> + * acpigen_write_store() - Write a store operation
> + *
> + * @ctx: ACPI context pointer
> + */
> +void acpigen_write_store(struct acpi_ctx *ctx);
> +
> +/**
> + * acpigen_write_debug_string() - Write a debug string
> + *
> + * This writes a debug operation with an associated string
> + *
> + * @ctx: ACPI context pointer
> + * @str: String to write
> + */
> +void acpigen_write_debug_string(struct acpi_ctx *ctx, const char *str);
> +
> +/**
> + * acpigen_write_or() - Write a bitwise OR operation
> + *
> + * res = arg1 | arg2
> + *
> + * @ctx: ACPI context pointer
> + * @arg1: ACPI opcode for operand 1 (e.g. LOCAL0_OP)
> + * @arg2: ACPI opcode for operand 2 (e.g. LOCAL1_OP)
> + * @res: ACPI opcode for result (e.g. LOCAL2_OP)
> + */
> +void acpigen_write_or(struct acpi_ctx *ctx, u8 arg1, u8 arg2, u8 res);
> +
> +/**
> + * acpigen_write_and() - Write a bitwise AND operation
> + *
> + * res = arg1 & arg2
> + *
> + * @ctx: ACPI context pointer
> + * @arg1: ACPI opcode for operand 1 (e.g. LOCAL0_OP)
> + * @arg2: ACPI opcode for operand 2 (e.g. LOCAL1_OP)
> + * @res: ACPI opcode for result (e.g. LOCAL2_OP)
> + */
> +void acpigen_write_and(struct acpi_ctx *ctx, u8 arg1, u8 arg2, u8 res);
> +
> +/**
> + * acpigen_write_not() - Write a bitwise NOT operation
> + *
> + * res = ~arg1
> + *
> + * @ctx: ACPI context pointer
> + * @arg: ACPI opcode for operand (e.g.
Re: [PATCH 5/7] usb: ehci-mx6: fix controller index for imx8m and imx8
On 6/29/20 4:13 AM, Peng Fan wrote:
[...]
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index 046c6ab283..8090cb27fe 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -687,7 +687,11 @@ static int ehci_usb_bind(struct udevice *dev)
>* With these changes in place, the ad-hoc indexing goes away and
>* the driver is fully converted to DT probing.
>*/
> - u32 controller_spacing = is_mx7() ? 0x1 : 0x200;
> + u32 controller_spacing;
> + if (IS_ENABLED(CONFIG_MX6))
> + controller_spacing = 0x200;
> + else
> + controller_spacing = 0x1;
This looks related to this problem:
501547cec1 ("usb: ehci-mx6: Fix bus enumeration for DM case")
Maybe instead of adding to the problem, it would make sense to convert
the driver to DM fully and then this problem with figuring out offsets
would go away ?
Re: [PATCH 3/7] usb: ehci-mx6: Turn on the power domain of USB PHY
On 6/29/20 4:13 AM, Peng Fan wrote:
[...]
> @@ -23,6 +25,9 @@
> #include
>
> #include "ehci.h"
> +#if CONFIG_IS_ENABLED(POWER_DOMAIN)
> +#include
> +#endif
The ifdef here should not be needed.
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -590,6 +595,18 @@ static int ehci_usb_phy_mode(struct udevice *dev)
> if ((fdt_addr_t)addr == FDT_ADDR_T_NONE)
> return -EINVAL;
>
> + /* Need to power on the PHY before access it */
> +#if CONFIG_IS_ENABLED(POWER_DOMAIN)
> + struct udevice phy_dev;
> + struct power_domain pd;
> +
> + phy_dev.node = offset_to_ofnode(phy_off);
> + if (!power_domain_get(_dev, )) {
> + if (power_domain_on())
> + return -EINVAL;
Please return the return value of power_domain_on() in case of failure.
[...]
Re: [PATCH 2/7] usb: ehci-mx6: Add i.MX8 OTG controller support
On 6/29/20 4:13 AM, Peng Fan wrote:
Hi,
> The i.MX8 has two USB controllers: USBOH and USB3. The USBOH reuses
> previous i.MX6/7. It has same PHY IP as i.MX7ULP but NC registers
> are same as i.MX7D. So add its support in ehci-mx6 driver.
>
> Also the driver is updated to remove build warning for 64 bits CPU.
Please split the fixes into separate patch.
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -62,12 +62,20 @@ DECLARE_GLOBAL_DATA_PTR;
> #define UCTRL_OVER_CUR_POL (1 << 8) /* OTG Polarity of Overcurrent */
> #define UCTRL_OVER_CUR_DIS (1 << 7) /* Disable OTG Overcurrent Detection */
>
> +#define PLL_USB_EN_USB_CLKS_MASK (0x01 << 6)
> +#define PLL_USB_PWR_MASK (0x01 << 12)
> +#define PLL_USB_ENABLE_MASK (0x01 << 13)
> +#define PLL_USB_BYPASS_MASK (0x01 << 16)
> +#define PLL_USB_REG_ENABLE_MASK (0x01 << 21)
> +#define PLL_USB_DIV_SEL_MASK (0x07 << 22)
> +#define PLL_USB_LOCK_MASK(0x01 << 31)
Use BIT() macro
> /* USBCMD */
> #define UCMD_RUN_STOP (1 << 0) /* controller run/stop */
> #define UCMD_RESET (1 << 1) /* controller reset */
>
> -#if defined(CONFIG_MX6) || defined(CONFIG_MX7ULP)
> -static const unsigned phy_bases[] = {
> +#if defined(CONFIG_MX6) || defined(CONFIG_MX7ULP) || defined(CONFIG_IMX8)
> +static const ulong phy_bases[] = {
> USB_PHY0_BASE_ADDR,
> #if defined(USB_PHY1_BASE_ADDR)
> USB_PHY1_BASE_ADDR,
> @@ -101,6 +109,53 @@ static void usb_power_config(int index)
>
> scg_enable_usb_pll(true);
>
> +#elif defined(CONFIG_IMX8)
This function should be split into multiple, it's too long, make it a
per-SoC function.
> + struct usbphy_regs __iomem *usbphy =
> + (struct usbphy_regs __iomem *)USB_PHY0_BASE_ADDR;
> + int timeout = 100;
> +
> + if (index > 0)
> + return;
> +
> + writel(ANADIG_USB2_CHRG_DETECT_EN_B |
> +ANADIG_USB2_CHRG_DETECT_CHK_CHRG_B,
> +>usb1_chrg_detect);
> +
> + if (!(readl(>usb1_pll_480_ctrl) & PLL_USB_LOCK_MASK)) {
> +
> + /* Enable the regulator first */
> + writel(PLL_USB_REG_ENABLE_MASK,
> +>usb1_pll_480_ctrl_set);
> +
> + /* Wait at least 25us */
> + udelay(25);
> +
> + /* Enable the power */
> + writel(PLL_USB_PWR_MASK, >usb1_pll_480_ctrl_set);
> +
> + /* Wait lock */
> + while (timeout--) {
> + if (readl(>usb1_pll_480_ctrl) &
> + PLL_USB_LOCK_MASK)
> + break;
> + udelay(10);
> + }
Use wait_for_bit*() here.
[...]
> static void usb_power_config(int index)
> {
> - struct usbnc_regs *usbnc = (struct usbnc_regs *)(USB_BASE_ADDR +
> + struct usbnc_regs *usbnc = (struct usbnc_regs *)(ulong)(USB_BASE_ADDR +
Is the extra type cast really needed ? If so, then it should be
uintptr_t so it would work with 64bit addresses.
[...]
Re: [PATCH 4/7] usb: ehci-mx6: Update driver to support i.MX8MM
On 6/29/20 4:13 AM, Peng Fan wrote:
[...]
> @@ -366,7 +366,7 @@ static void usb_oc_config(int index)
> struct usbnc_regs *usbnc = (struct usbnc_regs *)(USB_BASE_ADDR +
> USB_OTHERREGS_OFFSET);
> void __iomem *ctrl = (void __iomem *)(>ctrl[index]);
> -#elif defined(CONFIG_MX7) || defined(CONFIG_MX7ULP) || defined(CONFIG_IMX8)
> +#elif defined(CONFIG_USB_EHCI_MX7) || defined(CONFIG_MX7ULP) ||
> defined(CONFIG_IMX8)
Can someone please clean up this growing ifdeffery ? This doesn't work
with the driver model. It's fine to do that in a subsequent patch, but
it really should be done soon.
> struct usbnc_regs *usbnc = (struct usbnc_regs *)(ulong)(USB_BASE_ADDR +
> (0x1 * index) + USBNC_OFFSET);
> void __iomem *ctrl = (void __iomem *)(>ctrl1);
> @@ -469,7 +469,7 @@ int ehci_hcd_init(int index, enum usb_init_type init,
> enum usb_init_type type;
> #if defined(CONFIG_MX6)
> u32 controller_spacing = 0x200;
> -#elif defined(CONFIG_MX7) || defined(CONFIG_MX7ULP) || defined(CONFIG_IMX8)
> +#elif defined(CONFIG_USB_EHCI_MX7) || defined(CONFIG_MX7ULP) ||
> defined(CONFIG_IMX8)
> u32 controller_spacing = 0x1;
> #endif
> struct usb_ehci *ehci = (struct usb_ehci *)(ulong)(USB_BASE_ADDR +
> @@ -537,6 +537,12 @@ static int mx6_init_after_reset(struct ehci_ctrl *dev)
> struct usb_ehci *ehci = priv->ehci;
> int ret;
>
> + ret = board_usb_init(priv->portnr, priv->init_type);
> + if (ret) {
> + printf("Failed to initialize board for USB\n");
> + return ret;
> + }
Are these hooks needed ?
Re: [PATCH 1/7] usb: ehci-mx6: Add powerup_fixup implementation
On 6/29/20 4:13 AM, Peng Fan wrote:
[...]
> +static void ehci_mx6_powerup_fixup(struct ehci_ctrl *ctrl, uint32_t
> *status_reg,
> +uint32_t *reg)
> +{
> + u32 result;
> + int usec = 2000;
> +
> + mdelay(50);
> +
> + do {
> + result = ehci_readl(status_reg);
> + udelay(5);
> + if (!(result & EHCI_PS_PR))
> + break;
> + usec--;
> + } while (usec > 0);
> +
> + *reg = ehci_readl(status_reg);
> +}
Please use wait_for_bit*() . Also, is the 50 mS delay upfront required
or can this be wait_for_bit with 6 uS timeout ?
Re: [PATCH v2 2/3] watchdog: rti_wdt: Add support for loading firmware
+Tom
On 23/06/20 8:11 pm, Jan Kiszka wrote:
> On 23.06.20 14:37, Jan Kiszka wrote:
>> On 23.06.20 13:50, Lokesh Vutla wrote:
>>>
>>>
>>> On 23/06/20 4:45 pm, Jan Kiszka wrote:
From: Jan Kiszka
To avoid the need of extra boot scripting on AM65x for loading a
watchdog firmware, add the required rproc init and loading logic for the
first R5F core to the watchdog start handler. The firmware itself is
embedded into U-Boot binary.
One possible firmware source is https://github.com/siemens/k3-rti-wdt.
Signed-off-by: Jan Kiszka
---
drivers/watchdog/Kconfig | 20
drivers/watchdog/Makefile | 3 +++
drivers/watchdog/rti_wdt.c | 24
drivers/watchdog/rti_wdt_fw.S | 20
4 files changed, 67 insertions(+)
create mode 100644 drivers/watchdog/rti_wdt_fw.S
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ee99bd2af1..fd6ab9a85b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -162,6 +162,26 @@ config WDT_K3_RTI
Say Y here if you want to include support for the K3 watchdog
timer (RTI module) available in the K3 generation of processors.
+if WDT_K3_RTI
+
+config WDT_K3_RTI_LOAD_FW
+ bool "Load watchdog firmware"
+ depends on REMOTEPROC
+ help
+ Automatically load the specified firmware image into the MCU R5F
+ core 0. On the AM65x, this firmware is supposed to handle the expiry
+ of the watchdog timer, typically by resetting the system.
+
+config WDT_K3_RTI_FW_FILE
+ string "Watchdog firmware image file"
+ default "k3-rti-wdt.fw"
+ depends on WDT_K3_RTI_LOAD_FW
+ help
+ Firmware image to be embedded into U-Boot and loaded on watchdog
+ start.
+
+endif
+
config WDT_SANDBOX
bool "Enable Watchdog Timer support for Sandbox"
depends on SANDBOX && WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 16bdbf4970..bf58684875 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -28,7 +28,10 @@ obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o
+obj-$(CONFIG_WDT_K3_RTI_LOAD_FW) += rti_wdt_fw.o
obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
obj-$(CONFIG_WDT_XILINX) += xilinx_wwdt.o
+
+$(obj)/rti_wdt_fw.o: $(shell readlink -f $(CONFIG_WDT_K3_RTI_FW_FILE))
FORCE
diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
index ebe29c7409..38e82a6b6b 100644
--- a/drivers/watchdog/rti_wdt.c
+++ b/drivers/watchdog/rti_wdt.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
/* Timer register set definition */
#define RTIDWDCTRL 0x90
@@ -37,11 +38,16 @@
#define WDT_PRELOAD_MAX 0xfff
+#define RTI_PROC_ID 0
>>>
>>> Can we get the rproc id from DT?
>>
>> You mean, resolve "mcu_r5fss0_core0" to the ID? Doable.
>>
>
> I'm now probing for the first instance of "ti,am654-r5f" compatible. That
> excludes usage for the J721E for now, but that one is fine without firmware -
> provided there is way to prevent power-down for RTI watchdog otherwise...
I was more of thinking to have a DT property to reference R5-core. But anyways,
the property is not present in kernel. I am okay with this for now.
>
>>>
+
struct rti_wdt_priv {
phys_addr_t regs;
unsigned int clk_khz;
};
+extern const u32 rti_wdt_fw[];
+extern const int rti_wdt_fw_size;
>>>
>>> FIT is the preferred way of packing images in U-Boot. Can you try using it?
>>
>> How does that work? Some example for me?
>>
>
> If you happen to refer to fs-loader: That does not target OSPI, our primary
> use
> case.
No. I was thinking to pack the image in FIT along with ATF and OPTEE like in
k3_fit_atf.sh and register a U_BOOT_FIT_LOADABLE_HANDLER for installing the
firmware.
>
>> What benefit would that bring? There are other users of this pattern, e.g.
>> board/xilinx/zynqmp/pm_cfg_obj.S.
I didn't know U-Boot is accepting this. Tom, is this the preferred way for
including firmware images?
>>
>
> The only benefit of an alternative loading mechanism seems to be handling of
> larger images from different sources. But that's what I would tackle via boot
> scripting and, thus, without this feature. If you only have a few hundred
> bytes
> to embed, like for k3-rti-wdt, you quickly have a lot of overhead with other
> approaches.
hmm.. Does the build break if firmware is not present?
Re: [PATCH] arm: k3: Consolidate and silence k3_fit_atf.sh call
On 25/06/20 12:13 pm, Jan Kiszka wrote: > From: Jan Kiszka > > Signed-off-by: Jan Kiszka Thanks for cleaning it up Jan. May be a small commit message would be really useful. Other than that: Acked-by: Lokesh Vutla Thanks and regards, Lokesh
Re: [PATCH] arm: k3: Consolidate and silence k3_fit_atf.sh call
On 25/06/20 12:13 pm, Jan Kiszka wrote: > From: Jan Kiszka > > Signed-off-by: Jan Kiszka Thanks for cleaning ti up Jan. May be a small commit message would help. Other that that: Acked-by: Lokesh Vutla Thanks and regards, Lokesh > --- > arch/arm/mach-k3/config.mk | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk > index f6b63db349..f7afef610c 100644 > --- a/arch/arm/mach-k3/config.mk > +++ b/arch/arm/mach-k3/config.mk > @@ -48,22 +48,23 @@ ALL-y += tiboot3.bin > endif > > ifdef CONFIG_ARM64 > + > ifeq ($(CONFIG_TI_SECURE_DEVICE),y) > SPL_ITS := u-boot-spl-k3_HS.its > -$(SPL_ITS): FORCE > - IS_HS=1 \ > - $(srctree)/tools/k3_fit_atf.sh \ > - $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) > $@ > - > +$(SPL_ITS): export IS_HS=1 > ALL-y+= tispl.bin_HS > else > SPL_ITS := u-boot-spl-k3.its > -$(SPL_ITS): FORCE > +ALL-y+= tispl.bin > +endif > + > +quiet_cmd_k3_mkits = MKITS $@ > +cmd_k3_mkits = \ > $(srctree)/tools/k3_fit_atf.sh \ > $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) > $@ > > -ALL-y+= tispl.bin > -endif > +$(SPL_ITS): FORCE > + $(call cmd,k3_mkits) > endif > > else >
[PATCH 6/7] f_sdp: Add EP1_OUT as default data receive pipe in sdp
From: Sherry Sun
EP0 has been used to transfer file data in sdp before, but the max
packetsize of ep0 is 64 bytes. So in order to improve the file transfer
speed, here add the EP1_OUT interrupt endpoint which max packetsize is
set to 1024 byte.
After testing, it turns out that using ep1out is twice as fast as using
ep0 while receiving data in sdp.
Signed-off-by: Sherry Sun
Reviewed-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/gadget/f_sdp.c | 123 +++--
1 file changed, 107 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index 9f5dab23d7..4e33be6ada 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -71,6 +71,8 @@ struct hid_report {
#define SDP_COMMAND_LEN16
+#define SDP_HID_PACKET_SIZE_EP1 1024
+
#define SDP_EXIT 1
struct sdp_command {
@@ -84,8 +86,10 @@ struct sdp_command {
enum sdp_state {
SDP_STATE_IDLE,
+ SDP_STATE_RX_CMD,
SDP_STATE_RX_DCD_DATA,
SDP_STATE_RX_FILE_DATA,
+ SDP_STATE_RX_FILE_DATA_BUSY,
SDP_STATE_TX_SEC_CONF,
SDP_STATE_TX_SEC_CONF_BUSY,
SDP_STATE_TX_REGISTER,
@@ -116,8 +120,12 @@ struct f_sdp {
/* EP1 IN */
struct usb_ep *in_ep;
struct usb_request *in_req;
+ /* EP1 OUT */
+ struct usb_ep *out_ep;
+ struct usb_request *out_req;
boolconfiguration_done;
+ boolep_int_enable;
};
static struct f_sdp *sdp_func;
@@ -131,7 +139,7 @@ static struct usb_interface_descriptor sdp_intf_runtime = {
.bLength = sizeof(sdp_intf_runtime),
.bDescriptorType = USB_DT_INTERFACE,
.bAlternateSetting =0,
- .bNumEndpoints =1,
+ .bNumEndpoints =2,
.bInterfaceClass = USB_CLASS_HID,
.bInterfaceSubClass = 0,
.bInterfaceProtocol = 0,
@@ -161,6 +169,16 @@ static struct usb_endpoint_descriptor in_desc = {
.bInterval =1,
};
+static struct usb_endpoint_descriptor out_desc = {
+ .bLength = USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType = USB_DT_ENDPOINT, /*USB_DT_CS_ENDPOINT*/
+
+ .bEndpointAddress = 1 | USB_DIR_OUT,
+ .bmAttributes = USB_ENDPOINT_XFER_INT,
+ .wMaxPacketSize = 64,
+ .bInterval =1,
+};
+
static struct usb_endpoint_descriptor in_hs_desc = {
.bLength = USB_DT_ENDPOINT_SIZE,
.bDescriptorType = USB_DT_ENDPOINT, /*USB_DT_CS_ENDPOINT*/
@@ -171,10 +189,21 @@ static struct usb_endpoint_descriptor in_hs_desc = {
.bInterval =1,
};
+static struct usb_endpoint_descriptor out_hs_desc = {
+ .bLength = USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType = USB_DT_ENDPOINT, /*USB_DT_CS_ENDPOINT*/
+
+ .bEndpointAddress = 1 | USB_DIR_OUT,
+ .bmAttributes = USB_ENDPOINT_XFER_INT,
+ .wMaxPacketSize = SDP_HID_PACKET_SIZE_EP1,
+ .bInterval =1,
+};
+
static struct usb_descriptor_header *sdp_runtime_descs[] = {
(struct usb_descriptor_header *)_intf_runtime,
(struct usb_descriptor_header *)_hid_desc,
(struct usb_descriptor_header *)_desc,
+ (struct usb_descriptor_header *)_desc,
NULL,
};
@@ -182,6 +211,7 @@ static struct usb_descriptor_header *sdp_runtime_hs_descs[]
= {
(struct usb_descriptor_header *)_intf_runtime,
(struct usb_descriptor_header *)_hid_desc,
(struct usb_descriptor_header *)_hs_desc,
+ (struct usb_descriptor_header *)_hs_desc,
NULL,
};
@@ -347,7 +377,7 @@ static void sdp_rx_data_complete(struct usb_ep *ep, struct
usb_request *req)
int status = req->status;
u8 *data = req->buf;
u8 report = data[0];
- int datalen = req->length - 1;
+ int datalen = req->actual - 1;
if (status != 0) {
pr_err("Status: %d\n", status);
@@ -370,13 +400,15 @@ static void sdp_rx_data_complete(struct usb_ep *ep,
struct usb_request *req)
sdp->dnl_bytes_remaining -= datalen;
}
- if (sdp->state == SDP_STATE_RX_FILE_DATA) {
+ if (sdp->state == SDP_STATE_RX_FILE_DATA_BUSY) {
memcpy(sdp_ptr(sdp->dnl_address), req->buf + 1, datalen);
sdp->dnl_address += datalen;
}
- if (sdp->dnl_bytes_remaining)
+ if (sdp->dnl_bytes_remaining) {
+ sdp->state = SDP_STATE_RX_FILE_DATA;
return;
+ }
#ifndef CONFIG_SPL_BUILD
env_set_hex("filesize", sdp->dnl_bytes);
@@ -384,7 +416,7 @@ static void sdp_rx_data_complete(struct usb_ep *ep, struct
usb_request *req)
printf("done\n");
switch (sdp->state) {
- case SDP_STATE_RX_FILE_DATA:
+ case
[PATCH 7/7] f_sdp: Change bInterval of interrupt endpoint to 3
From: Sherry Sun
Since the USB HID limits the maximum bandwidth(3072) for interrupt
endpoint transfers, when the bInterval set to 1, we can only support 3
boards to run sdp at the same time. In order to support more boards,
change the bInterval of interrupt endpoint to 3, which will not affect
the transmission speed.
Reviewed-by: Ye Li
Signed-off-by: Sherry Sun
Signed-off-by: Peng Fan
---
drivers/usb/gadget/f_sdp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index 4e33be6ada..5bde08f707 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -186,7 +186,7 @@ static struct usb_endpoint_descriptor in_hs_desc = {
.bEndpointAddress = 1 | USB_DIR_IN,
.bmAttributes = USB_ENDPOINT_XFER_INT,
.wMaxPacketSize = 512,
- .bInterval =1,
+ .bInterval =3,
};
static struct usb_endpoint_descriptor out_hs_desc = {
@@ -196,7 +196,7 @@ static struct usb_endpoint_descriptor out_hs_desc = {
.bEndpointAddress = 1 | USB_DIR_OUT,
.bmAttributes = USB_ENDPOINT_XFER_INT,
.wMaxPacketSize = SDP_HID_PACKET_SIZE_EP1,
- .bInterval =1,
+ .bInterval =3,
};
static struct usb_descriptor_header *sdp_runtime_descs[] = {
--
2.16.4
[PATCH 4/7] f_sdp: Support searching and loading FIT or container image
Add support to f_sdp to search and load iMX8 container image or iMX8M
FIT image by new UUU command SDPV.
When using the SDPV, the uuu will continue to send out data after first
level boot loader used by ROM. This means uuu won't skip to the offset
of the second boot loader, and the padding data before second boot loader
will be sent out. So we have to search the FIT header or container header
in the buffer that SDP received.
Also change to more common method to exit f_sdp handler not depending on
SPL_FIT_FOUND flag because container loader won't set this.
Signed-off-by: Peng Fan
---
drivers/usb/gadget/f_sdp.c | 72 +-
1 file changed, 59 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index eec7560fc2..9f5dab23d7 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -71,6 +71,8 @@ struct hid_report {
#define SDP_COMMAND_LEN16
+#define SDP_EXIT 1
+
struct sdp_command {
u16 cmd;
u32 addr;
@@ -667,19 +669,42 @@ static u32 sdp_jump_imxheader(void *address)
}
#ifdef CONFIG_SPL_BUILD
-#ifdef CONFIG_SPL_LOAD_FIT
-static ulong sdp_fit_read(struct spl_load_info *load, ulong sector,
- ulong count, void *buf)
+static ulong sdp_load_read(struct spl_load_info *load, ulong sector,
+ ulong count, void *buf)
{
debug("%s: sector %lx, count %lx, buf %lx\n",
__func__, sector, count, (ulong)buf);
memcpy(buf, (void *)(load->dev + sector), count);
return count;
}
-#endif
-#endif
-static void sdp_handle_in_ep(struct spl_image_info *spl_image)
+static ulong search_fit_header(ulong p, int size)
+{
+ int i;
+
+ for (i = 0; i < size; i += 4) {
+ if (genimg_get_format((const void *)(p + i)) ==
IMAGE_FORMAT_FIT)
+ return p + i;
+ }
+
+ return 0;
+}
+
+static ulong search_container_header(ulong p, int size)
+{
+ int i;
+ u8 *hdr;
+
+ for (i = 0; i < size; i += 4) {
+ hdr = (u8 *)(p + i);
+ if (*(hdr + 3) == 0x87 && *hdr == 0)
+ if (*(hdr + 1) != 0 || *(hdr + 2) != 0)
+ return p + i;
+ }
+ return 0;
+}
+
+static int sdp_handle_in_ep(struct spl_image_info *spl_image)
{
u8 *data = sdp_func->in_req->buf;
u32 status;
@@ -731,6 +756,16 @@ static void sdp_handle_in_ep(struct spl_image_info
*spl_image)
/* If imx header fails, try some U-Boot specific headers */
if (status) {
#ifdef CONFIG_SPL_BUILD
+ if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER))
+ sdp_func->jmp_address =
(u32)search_container_header((ulong)sdp_func->jmp_address, sdp_func->dnl_bytes);
+ else if (IS_ENABLED(CONFIG_SPL_LOAD_FIT))
+ sdp_func->jmp_address =
(u32)search_fit_header((ulong)sdp_func->jmp_address, sdp_func->dnl_bytes);
+#endif
+ if (sdp_func->jmp_address == 0)
+ panic("Error in search header, failed to
jump\n");
+
+ printf("Found header at 0x%08x\n",
sdp_func->jmp_address);
+
image_header_t *header =
sdp_ptr(sdp_func->jmp_address);
#ifdef CONFIG_SPL_LOAD_FIT
@@ -740,13 +775,23 @@ static void sdp_handle_in_ep(struct spl_image_info
*spl_image)
debug("Found FIT\n");
load.dev = header;
load.bl_len = 1;
- load.read = sdp_fit_read;
+ load.read = sdp_load_read;
spl_load_simple_fit(spl_image, , 0,
header);
- return;
+ return SDP_EXIT;
}
#endif
+ if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
+ struct spl_load_info load;
+
+ load.dev = header;
+ load.bl_len = 1;
+ load.read = sdp_load_read;
+ spl_load_imx_container(spl_image, , 0);
+ return SDP_EXIT;
+ }
+
/* In SPL, allow jumps to U-Boot images */
struct spl_image_info spl_image = {};
spl_parse_image_header(_image, header);
@@ -769,6 +814,8 @@ static void sdp_handle_in_ep(struct spl_image_info
*spl_image)
default:
break;
};
+
+ return 0;
}
#ifndef CONFIG_SPL_BUILD
@@ -777,6 +824,7 @@ int sdp_handle(int controller_index)
int spl_sdp_handle(int controller_index,
[PATCH 5/7] spl: add g_dnl_get_board_bcd_device_number
Add g_dnl_get_board_bcd_device_number, the new BCD value is used by uuu to
distinguish
if the SPL supports the SDPV.
Signed-off-by: Peng Fan
---
arch/arm/mach-imx/spl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 1a231c67f5..8c0596d1e1 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -187,6 +187,12 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev,
const char *name)
return 0;
}
+
+#define SDPV_BCD_DEVICE 0x500
+int g_dnl_get_board_bcd_device_number(int gcnum)
+{
+ return SDPV_BCD_DEVICE;
+}
#endif
#if defined(CONFIG_SPL_MMC_SUPPORT)
--
2.16.4
[PATCH 2/7] f_sdp: Add high speed endpoint descriptor
From: Ye Li
Add HS endpoint descriptor for SDP. So that we can use high speed endpoint,
and the SDP device can send packet with 512 byte size.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/gadget/f_sdp.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index f2fe89d2a6..f971ccdeca 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -159,6 +159,16 @@ static struct usb_endpoint_descriptor in_desc = {
.bInterval =1,
};
+static struct usb_endpoint_descriptor in_hs_desc = {
+ .bLength = USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType = USB_DT_ENDPOINT, /*USB_DT_CS_ENDPOINT*/
+
+ .bEndpointAddress = 1 | USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_INT,
+ .wMaxPacketSize = 512,
+ .bInterval =1,
+};
+
static struct usb_descriptor_header *sdp_runtime_descs[] = {
(struct usb_descriptor_header *)_intf_runtime,
(struct usb_descriptor_header *)_hid_desc,
@@ -166,6 +176,13 @@ static struct usb_descriptor_header *sdp_runtime_descs[] =
{
NULL,
};
+static struct usb_descriptor_header *sdp_runtime_hs_descs[] = {
+ (struct usb_descriptor_header *)_intf_runtime,
+ (struct usb_descriptor_header *)_hid_desc,
+ (struct usb_descriptor_header *)_hs_desc,
+ NULL,
+};
+
/* This is synchronized with what the SoC implementation reports */
static struct hid_report sdp_hid_report = {
.usage_page = {
@@ -489,6 +506,11 @@ static int sdp_bind(struct usb_configuration *c, struct
usb_function *f)
goto error;
}
+ if (gadget_is_dualspeed(gadget)) {
+ /* Assume endpoint addresses are the same for both speeds */
+ in_hs_desc.bEndpointAddress = in_desc.bEndpointAddress;
+ }
+
sdp->in_ep = ep; /* Store IN EP for enabling @ setup */
cdev->req->context = sdp;
@@ -541,11 +563,15 @@ static int sdp_set_alt(struct usb_function *f, unsigned
intf, unsigned alt)
{
struct f_sdp *sdp = func_to_sdp(f);
struct usb_composite_dev *cdev = f->config->cdev;
+ struct usb_gadget *gadget = cdev->gadget;
int result;
debug("%s: intf: %d alt: %d\n", __func__, intf, alt);
- result = usb_ep_enable(sdp->in_ep, _desc);
+ if (gadget_is_dualspeed(gadget) && gadget->speed == USB_SPEED_HIGH)
+ result = usb_ep_enable(sdp->in_ep, _hs_desc);
+ else
+ result = usb_ep_enable(sdp->in_ep, _desc);
if (result)
return result;
sdp->in_req = sdp_start_ep(sdp->in_ep);
@@ -591,7 +617,7 @@ static int sdp_bind_config(struct usb_configuration *c)
memset(sdp_func, 0, sizeof(*sdp_func));
sdp_func->usb_function.name = "sdp";
- sdp_func->usb_function.hs_descriptors = sdp_runtime_descs;
+ sdp_func->usb_function.hs_descriptors = sdp_runtime_hs_descs;
sdp_func->usb_function.descriptors = sdp_runtime_descs;
sdp_func->usb_function.bind = sdp_bind;
sdp_func->usb_function.unbind = sdp_unbind;
--
2.16.4
[PATCH 3/7] f_sdp: Fix wrong usb request size
From: Ye Li
Because the buffer length of sdp usb request is 65, we have to allocate
65 bytes not 64 bytes. Otherwise there is potential buffer overflow.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/gadget/f_sdp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index f971ccdeca..eec7560fc2 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -548,7 +548,7 @@ static struct usb_request *sdp_start_ep(struct usb_ep *ep)
{
struct usb_request *req;
- req = alloc_ep_req(ep, 64);
+ req = alloc_ep_req(ep, 65);
debug("%s: ep:%p req:%p\n", __func__, ep, req);
if (!req)
--
2.16.4
[PATCH 1/7] sdp: call board_usb_init at spl_sdp_load_image
From: Frank Li
Need initialize UDC before run sdp download
Signed-off-by: Frank Li
Signed-off-by: Peng Fan
---
common/spl/spl_sdp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
index e7f7b68411..ae9c09883a 100644
--- a/common/spl/spl_sdp.c
+++ b/common/spl/spl_sdp.c
@@ -19,6 +19,8 @@ static int spl_sdp_load_image(struct spl_image_info
*spl_image,
usb_gadget_initialize(controller_index);
+ board_usb_init(0, USB_INIT_DEVICE);
+
g_dnl_clear_detach();
ret = g_dnl_register("usb_dnl_sdp");
if (ret) {
--
2.16.4
Re: [PATCH v3 18/35] acpi: Support writing a UUID
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > ACPI supports writing a UUID in a special format. Add a function to handle > this. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > include/acpi/acpigen.h | 13 + > lib/acpi/acpigen.c | 38 ++ > test/dm/acpigen.c | 33 + > 3 files changed, 84 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 19/35] acpi: Support writing Device Properties objects via _DSD
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> More complex device properties can be provided to drivers via a
> device-specific data (_DSD) object.
>
> To create this we need to build it up in a separate data structure and
> then generate the ACPI code, due to its recursive nature.
>
> Add an implementation of this.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v3:
> - Allow the name parameter to be NULL
> - Add error checking to acpi_dp_add_integer_array()
> - Fix 'acpi_device.v' typo
> - Drop unused ACPI_CPU_STRING
>
> include/acpi/acpi_dp.h | 216 ++
> include/acpi/acpigen.h | 1 +
> lib/acpi/Makefile | 1 +
> lib/acpi/acpi_dp.c | 323
> test/dm/Makefile | 1 +
> test/dm/acpi_dp.c | 405 +
> 6 files changed, 947 insertions(+)
> create mode 100644 include/acpi/acpi_dp.h
> create mode 100644 lib/acpi/acpi_dp.c
> create mode 100644 test/dm/acpi_dp.c
>
> diff --git a/include/acpi/acpi_dp.h b/include/acpi/acpi_dp.h
> new file mode 100644
> index 00..3fd048e111
> --- /dev/null
> +++ b/include/acpi/acpi_dp.h
> @@ -0,0 +1,216 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Device properties, a temporary data structure for adding to ACPI code
> + *
> + * Copyright 2019 Google LLC
> + * Mostly taken from coreboot file acpi_device.h
> + */
> +
> +#ifndef __ACPI_DP_H
> +#define __ACPI_DP_H
> +
> +struct acpi_ctx;
> +
> +/*
> + * Writing Device Properties objects via _DSD
> + *
> + * This is described in ACPI 6.3 section 6.2.5
> + *
> + * This provides a structure to handle nested device-specific data which ends
> + * up in a _DSD table.
> + *
> + *
> https://www.kernel.org/doc/html/latest/firmware-guide/acpi/DSD-properties-rules.html
> + *
> https://uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
> + *
> https://uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf
> + *
> + * The Device Property Hierarchy can be multiple levels deep with multiple
> + * children possible in each level. In order to support this flexibility
> + * the device property hierarchy must be built up before being written out.
> + *
> + * For example:
> + *
> + * // Child table with string and integer
nits: /* */
> + * struct acpi_dp *child = acpi_dp_new_table("CHLD");
> + * acpi_dp_add_string(child, "childstring", "CHILD");
> + * acpi_dp_add_integer(child, "childint", 100);
> + *
> + * // _DSD table with integer and gpio and child pointer
nits: /* */
> + * struct acpi_dp *dsd = acpi_dp_new_table("_DSD");
> + * acpi_dp_add_integer(dsd, "number1", 1);
> + * acpi_dp_add_gpio(dsd, "gpio", "\_SB.PCI0.GPIO", 0, 0, 1);
> + * acpi_dp_add_child(dsd, "child", child);
> + *
> + * // Write entries into SSDT and clean up resources
nits: /* */
> + * acpi_dp_write(dsd);
> + *
> + * Name(_DSD, Package() {
> + * ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> + * Package() {
> + * Package() { "gpio", Package() { \_SB.PCI0.GPIO, 0, 0, 0 } }
> + * Package() { "number1", 1 }
> + * }
> + * ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b")
> + * Package() {
> + * Package() { "child", CHLD }
> + * }
> + * }
> + * Name(CHLD, Package() {
> + * ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
> + * Package() {
> + * Package() { "childstring", "CHILD" }
> + * Package() { "childint", 100 }
> + * }
> + * }
> + */
> +
> +#define ACPI_DP_UUID "daffd814-6eba-4d8c-8a91-bc9bbf4aa301"
> +#define ACPI_DP_CHILD_UUID "dbb8e3e6-5886-4ba6-8795-1319f52a966b"
> +
> +/**
> + * enum acpi_dp_type - types of device property objects
> + *
> + * These refer to the types defined by struct acpi_dp below
> + *
> + * @ACPI_DP_TYPE_UNKNOWN: Unknown / do not use
> + * @ACPI_DP_TYPE_INTEGER: Integer value (u64) in @integer
> + * @ACPI_DP_TYPE_STRING: String value in @string
> + * @ACPI_DP_TYPE_REFERENCE: Reference to another object, with value in
> @string
> + * @ACPI_DP_TYPE_TABLE: Type for a top-level table which may have children
> + * @ACPI_DP_TYPE_ARRAY: Array of items with first item in @array and
> following
> + * items linked from that item's @next
> + * @ACPI_DP_TYPE_CHILD: Child object, with siblings in that child's @next
> + */
> +enum acpi_dp_type {
> + ACPI_DP_TYPE_UNKNOWN,
> + ACPI_DP_TYPE_INTEGER,
> + ACPI_DP_TYPE_STRING,
> + ACPI_DP_TYPE_REFERENCE,
> + ACPI_DP_TYPE_TABLE,
> + ACPI_DP_TYPE_ARRAY,
> + ACPI_DP_TYPE_CHILD,
> +};
> +
> +/**
> + * struct acpi_dp - ACPI device properties
> + *
> + * @type: Table type
> + * @name: Name of object, typically _DSD but could be CHLD for a child
> object.
> + * This can be NULL if there is no name
> + * @next: Next object in list (next array element or next sibling)
> + * @child: Pointer to first child, if @type == ACPI_DP_TYPE_CHILD, else NULL
> + * @array: First array element,
Re: [PATCH v3 20/35] acpi: Support writing a GPIO
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > Allowing writing out a reference to a GPIO within the ACPI output. This > can be used by ACPI code to access a GPIO at runtime. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Use an enum for the GPIO priority > - Add error checking > > include/acpi/acpi_dp.h | 20 > lib/acpi/acpi_dp.c | 23 +++ > test/dm/acpi_dp.c | 40 > 3 files changed, 83 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 17/35] acpi: Support writing a name
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> ACPI supports storing names which are made up of multiple path components.
> Several special cases are supported. Add a function to emit a name.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpigen.h | 25 +++
> include/test/ut.h | 17
> lib/acpi/acpigen.c | 96 ++
> test/dm/acpigen.c | 93
> 4 files changed, 231 insertions(+)
>
> diff --git a/include/acpi/acpigen.h b/include/acpi/acpigen.h
> index cf7f6173db..4d3202c922 100644
> --- a/include/acpi/acpigen.h
> +++ b/include/acpi/acpigen.h
> @@ -21,12 +21,15 @@ struct acpi_ctx;
> enum {
> ZERO_OP = 0x00,
> ONE_OP = 0x01,
> + NAME_OP = 0x08,
> BYTE_PREFIX = 0x0a,
> WORD_PREFIX = 0x0b,
> DWORD_PREFIX= 0x0c,
> STRING_PREFIX = 0x0d,
> QWORD_PREFIX= 0x0e,
> PACKAGE_OP = 0x12,
> + DUAL_NAME_PREFIX= 0x2e,
> + MULTI_NAME_PREFIX = 0x2f,
> };
>
> /**
> @@ -162,4 +165,26 @@ void acpigen_write_integer(struct acpi_ctx *ctx, u64
> data);
> * @str: String to write
> */
> void acpigen_write_string(struct acpi_ctx *ctx, const char *str);
> +
> +/**
> + * acpigen_emit_namestring() - Emit an ACPI name
> + *
> + * This writes out an ACPI name or path in the required special format. It
> does
> + * not add the NAME_OP prefix.
> + *
> + * @ctx: ACPI context pointer
> + * @namepath: Name / path to emit
> + */
> +void acpigen_emit_namestring(struct acpi_ctx *ctx, const char *namepath);
> +
> +/**
> + * acpigen_write_name() - Write out an ACPI name
> + *
> + * This writes out an ACPI name or path in the required special format with a
> + * NAME_OP prefix.
> + *
> + * @ctx: ACPI context pointer
> + * @namepath: Name / path to emit
> + */
> +void acpigen_write_name(struct acpi_ctx *ctx, const char *namepath);
> #endif
> diff --git a/include/test/ut.h b/include/test/ut.h
> index 7ddd6e8872..99bbb1230c 100644
> --- a/include/test/ut.h
> +++ b/include/test/ut.h
> @@ -134,6 +134,23 @@ int ut_check_console_dump(struct unit_test_state *uts,
> int total_bytes);
> } \
> }
>
> +/*
> + * Assert that two string expressions are equal, up to length of the
> + * first
> + */
> +#define ut_asserteq_strn(expr1, expr2) { \
> + const char *_val1 = (expr1), *_val2 = (expr2); \
> + int _len = strlen(_val1); \
> + \
> + if (memcmp(_val1, _val2, _len)) { \
> + ut_failf(uts, __FILE__, __LINE__, __func__, \
> +#expr1 " = " #expr2, \
> +"Expected \"%.*s\", got \"%.*s\"", \
> +_len, _val1, _len, _val2); \
> + return CMD_RET_FAILURE; \
> + } \
> +}
> +
> /* Assert that two memory areas are equal */
> #define ut_asserteq_mem(expr1, expr2, len) { \
> const u8 *_val1 = (u8 *)(expr1), *_val2 = (u8 *)(expr2);\
> diff --git a/lib/acpi/acpigen.c b/lib/acpi/acpigen.c
> index dcf84afbe6..55d7afc633 100644
> --- a/lib/acpi/acpigen.c
> +++ b/lib/acpi/acpigen.c
> @@ -152,3 +152,99 @@ void acpigen_write_string(struct acpi_ctx *ctx, const
> char *str)
> acpigen_emit_byte(ctx, STRING_PREFIX);
> acpigen_emit_string(ctx, str);
> }
> +
> +/*
> + * The naming conventions for ACPI namespace names are a bit tricky as
> + * each element has to be 4 chars wide ("All names are a fixed 32 bits.")
> + * and "By convention, when an ASL compiler pads a name shorter than 4
> + * characters, it is done so with trailing underscores ('_')".
> + *
> + * Check sections 5.3, 20.2.2 and 20.4 of ACPI spec 6.3 for details.
> + */
> +static void acpigen_emit_simple_namestring(struct acpi_ctx *ctx,
> + const char *name)
> +{
> + const char *ptr;
> + int i;
> +
> + for (i = 0, ptr = name; i < 4; i++) {
> + if (!*ptr || *ptr == '.')
> + acpigen_emit_byte(ctx, '_');
> + else
> + acpigen_emit_byte(ctx, *ptr++);
> + }
> +}
> +
> +static void acpigen_emit_double_namestring(struct acpi_ctx *ctx,
> + const char *name, int dotpos)
> +{
> + acpigen_emit_byte(ctx, DUAL_NAME_PREFIX);
> +
Re: [PATCH v3 16/35] acpi: Support writing a string
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> ACPI supports storing a simple nul-terminated string. Add support for
nits: null
> this.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpigen.h | 10 ++
> lib/acpi/acpigen.c | 6 ++
> test/dm/acpigen.c | 32 ++--
> 3 files changed, 46 insertions(+), 2 deletions(-)
>
> diff --git a/include/acpi/acpigen.h b/include/acpi/acpigen.h
> index b17a9ef14c..cf7f6173db 100644
> --- a/include/acpi/acpigen.h
> +++ b/include/acpi/acpigen.h
> @@ -24,6 +24,7 @@ enum {
> BYTE_PREFIX = 0x0a,
> WORD_PREFIX = 0x0b,
> DWORD_PREFIX= 0x0c,
> + STRING_PREFIX = 0x0d,
> QWORD_PREFIX= 0x0e,
> PACKAGE_OP = 0x12,
> };
> @@ -152,4 +153,13 @@ char *acpigen_write_package(struct acpi_ctx *ctx, int
> nr_el);
> */
> void acpigen_write_integer(struct acpi_ctx *ctx, u64 data);
>
> +/**
> + * acpigen_write_string() - Write a string
> + *
> + * This writes a STRING_PREFIX followed by a nul-terminated string
nits: unull
> + *
> + * @ctx: ACPI context pointer
> + * @str: String to write
> + */
> +void acpigen_write_string(struct acpi_ctx *ctx, const char *str);
> #endif
> diff --git a/lib/acpi/acpigen.c b/lib/acpi/acpigen.c
> index c8c8f07897..dcf84afbe6 100644
> --- a/lib/acpi/acpigen.c
> +++ b/lib/acpi/acpigen.c
> @@ -146,3 +146,9 @@ void acpigen_emit_string(struct acpi_ctx *ctx, const char
> *str)
> acpigen_emit_stream(ctx, str, str ? strlen(str) : 0);
> acpigen_emit_byte(ctx, '\0'); /* NUL */
> }
> +
> +void acpigen_write_string(struct acpi_ctx *ctx, const char *str)
> +{
> + acpigen_emit_byte(ctx, STRING_PREFIX);
> + acpigen_emit_string(ctx, str);
> +}
> diff --git a/test/dm/acpigen.c b/test/dm/acpigen.c
> index 730f5713ec..836cb4f75c 100644
> --- a/test/dm/acpigen.c
> +++ b/test/dm/acpigen.c
> @@ -20,6 +20,7 @@
> #include
>
> #define TEST_STRING"frogmore"
> +#define TEST_STRING2 "ranch"
> #define TEST_STREAM2 "\xfa\xde"
>
> #define TEST_INT8 0x7d
> @@ -404,7 +405,7 @@ static int dm_test_acpi_len(struct unit_test_state *uts)
> }
> DM_TEST(dm_test_acpi_len, 0);
>
> -/* Test emitting a package */
> +/* Test writing a package */
nits: this change should be squashed in previous commit that
introduced this line in the first place
> static int dm_test_acpi_package(struct unit_test_state *uts)
> {
> struct acpi_ctx *ctx;
> @@ -431,7 +432,7 @@ static int dm_test_acpi_package(struct unit_test_state
> *uts)
> }
> DM_TEST(dm_test_acpi_package, 0);
>
> -/* Test emitting an integer */
> +/* Test writing an integer */
nits: this change should be squashed in previous commit that
introduced this line in the first place
> static int dm_test_acpi_integer(struct unit_test_state *uts)
> {
> struct acpi_ctx *ctx;
> @@ -471,3 +472,30 @@ static int dm_test_acpi_integer(struct unit_test_state
> *uts)
> return 0;
> }
> DM_TEST(dm_test_acpi_integer, 0);
> +
> +/* Test writing a string */
> +static int dm_test_acpi_string(struct unit_test_state *uts)
> +{
> + struct acpi_ctx *ctx;
> + u8 *ptr;
> +
> + ut_assertok(alloc_context());
> +
> + ptr = acpigen_get_current(ctx);
> +
> + acpigen_write_string(ctx, TEST_STRING);
> + acpigen_write_string(ctx, TEST_STRING2);
> +
> + ut_asserteq(2 + sizeof(TEST_STRING) + sizeof(TEST_STRING2),
> + acpigen_get_current(ctx) - ptr);
> + ut_asserteq(STRING_PREFIX, ptr[0]);
> + ut_asserteq_str(TEST_STRING, (char *)ptr + 1);
> + ptr += 1 + sizeof(TEST_STRING);
> + ut_asserteq(STRING_PREFIX, ptr[0]);
> + ut_asserteq_str(TEST_STRING2, (char *)ptr + 1);
> +
> + free_context();
> +
> + return 0;
> +}
> +DM_TEST(dm_test_acpi_string, 0);
Other than above,
Reviewed-by: Bin Meng
Regards,
Bin
[PATCH 4/7] usb: ehci-mx6: Update driver to support i.MX8MM
From: Ye Li
Since the i.MX8MM reuses the otg controllers on i.MX7D. We can use
CONFIG_USB_EHCI_MX7 for them.
Due the TCPC and load switch are used on Typec circuit. Add the
board_usb_init and board_usb_cleanup to ehci-mx6 DM driver. So
we can implement the TCPC settings in these board functions.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/host/Kconfig| 2 +-
drivers/usb/host/ehci-mx6.c | 31 ++-
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f48547caa0..1e2c5006d4 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -147,7 +147,7 @@ config USB_EHCI_MX6
config USB_EHCI_MX7
bool "Support for i.MX7 on-chip EHCI USB controller"
- depends on ARCH_MX7
+ depends on ARCH_MX7 || IMX8MM
default y
---help---
Enables support for the on-chip EHCI controller on i.MX7 SoCs.
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 92e8bb91d2..046c6ab283 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -297,7 +297,7 @@ struct usbnc_regs {
};
#endif
-#elif defined(CONFIG_MX7)
+#elif defined(CONFIG_USB_EHCI_MX7)
struct usbnc_regs {
u32 ctrl1;
u32 ctrl2;
@@ -366,7 +366,7 @@ static void usb_oc_config(int index)
struct usbnc_regs *usbnc = (struct usbnc_regs *)(USB_BASE_ADDR +
USB_OTHERREGS_OFFSET);
void __iomem *ctrl = (void __iomem *)(>ctrl[index]);
-#elif defined(CONFIG_MX7) || defined(CONFIG_MX7ULP) || defined(CONFIG_IMX8)
+#elif defined(CONFIG_USB_EHCI_MX7) || defined(CONFIG_MX7ULP) ||
defined(CONFIG_IMX8)
struct usbnc_regs *usbnc = (struct usbnc_regs *)(ulong)(USB_BASE_ADDR +
(0x1 * index) + USBNC_OFFSET);
void __iomem *ctrl = (void __iomem *)(>ctrl1);
@@ -469,7 +469,7 @@ int ehci_hcd_init(int index, enum usb_init_type init,
enum usb_init_type type;
#if defined(CONFIG_MX6)
u32 controller_spacing = 0x200;
-#elif defined(CONFIG_MX7) || defined(CONFIG_MX7ULP) || defined(CONFIG_IMX8)
+#elif defined(CONFIG_USB_EHCI_MX7) || defined(CONFIG_MX7ULP) ||
defined(CONFIG_IMX8)
u32 controller_spacing = 0x1;
#endif
struct usb_ehci *ehci = (struct usb_ehci *)(ulong)(USB_BASE_ADDR +
@@ -537,6 +537,12 @@ static int mx6_init_after_reset(struct ehci_ctrl *dev)
struct usb_ehci *ehci = priv->ehci;
int ret;
+ ret = board_usb_init(priv->portnr, priv->init_type);
+ if (ret) {
+ printf("Failed to initialize board for USB\n");
+ return ret;
+ }
+
ret = ehci_mx6_common_init(priv->ehci, priv->portnr);
if (ret)
return ret;
@@ -614,7 +620,7 @@ static int ehci_usb_phy_mode(struct udevice *dev)
plat->init_type = USB_INIT_DEVICE;
else
plat->init_type = USB_INIT_HOST;
- } else if (is_mx7()) {
+ } else if (is_mx7() || is_imx8mm()) {
phy_status = (void __iomem *)(addr +
USBNC_PHY_STATUS_OFFSET);
val = readl(phy_status);
@@ -711,6 +717,12 @@ static int ehci_usb_probe(struct udevice *dev)
priv->portnr = dev->seq;
priv->init_type = type;
+ ret = board_usb_init(priv->portnr, priv->init_type);
+ if (ret) {
+ printf("Failed to initialize board for USB\n");
+ return ret;
+ }
+
#if CONFIG_IS_ENABLED(DM_REGULATOR)
ret = device_get_supply_regulator(dev, "vbus-supply",
>vbus_supply);
@@ -748,6 +760,15 @@ static int ehci_usb_probe(struct udevice *dev)
return ehci_register(dev, hccr, hcor, _ehci_ops, 0,
priv->init_type);
}
+int ehci_usb_remove(struct udevice *dev)
+{
+ struct ehci_mx6_priv_data *priv = dev_get_priv(dev);
+
+ ehci_deregister(dev);
+
+ return board_usb_cleanup(dev->seq, priv->init_type);
+}
+
static const struct udevice_id mx6_usb_ids[] = {
{ .compatible = "fsl,imx27-usb" },
{ }
@@ -760,7 +781,7 @@ U_BOOT_DRIVER(usb_mx6) = {
.ofdata_to_platdata = ehci_usb_ofdata_to_platdata,
.bind = ehci_usb_bind,
.probe = ehci_usb_probe,
- .remove = ehci_deregister,
+ .remove = ehci_usb_remove,
.ops= _usb_ops,
.platdata_auto_alloc_size = sizeof(struct usb_platdata),
.priv_auto_alloc_size = sizeof(struct ehci_mx6_priv_data),
--
2.16.4
[PATCH 6/7] usb: ehci-mx6: Enable iMX EHCI driver for iMX8M Nano
From: Ye Li
Add the IMX8MN to the EHCI-MX7 kconfig dependency.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/host/Kconfig| 2 +-
drivers/usb/host/ehci-mx6.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 1e2c5006d4..36eb1138c4 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -147,7 +147,7 @@ config USB_EHCI_MX6
config USB_EHCI_MX7
bool "Support for i.MX7 on-chip EHCI USB controller"
- depends on ARCH_MX7 || IMX8MM
+ depends on ARCH_MX7 || IMX8MM || IMX8MN
default y
---help---
Enables support for the on-chip EHCI controller on i.MX7 SoCs.
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 8090cb27fe..74f6c80d93 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -620,7 +620,7 @@ static int ehci_usb_phy_mode(struct udevice *dev)
plat->init_type = USB_INIT_DEVICE;
else
plat->init_type = USB_INIT_HOST;
- } else if (is_mx7() || is_imx8mm()) {
+ } else if (is_mx7() || is_imx8mm() || is_imx8mn()) {
phy_status = (void __iomem *)(addr +
USBNC_PHY_STATUS_OFFSET);
val = readl(phy_status);
--
2.16.4
[PATCH 5/7] usb: ehci-mx6: fix controller index for imx8m and imx8
From: Ye Li
The bind codes calculate the address offset for controller index, but
it is wrong for imx8m and imx8. It causes secondary controller fails to
work. So fix this problem, and also change all seq to req_seq.
There is another issue here for imx8, the codes use runtime CPU type check.
One iMX8, this check depends on IPC communication with SCFW, and need
MU driver been probed. But the usbotg is configured with "u-boot,dm_spl"
property for SDP download in SPL, so it will bind in early DM in u-boot
while the MU is not bound at same time, so the CPU type check will hang.
Fix it to use static check.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/host/ehci-mx6.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 046c6ab283..8090cb27fe 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -687,7 +687,11 @@ static int ehci_usb_bind(struct udevice *dev)
* With these changes in place, the ad-hoc indexing goes away and
* the driver is fully converted to DT probing.
*/
- u32 controller_spacing = is_mx7() ? 0x1 : 0x200;
+ u32 controller_spacing;
+ if (IS_ENABLED(CONFIG_MX6))
+ controller_spacing = 0x200;
+ else
+ controller_spacing = 0x1;
fdt_addr_t addr = devfdt_get_addr_index(dev, 0);
dev->req_seq = (addr - USB_BASE_ADDR) / controller_spacing;
@@ -714,7 +718,7 @@ static int ehci_usb_probe(struct udevice *dev)
}
priv->ehci = ehci;
- priv->portnr = dev->seq;
+ priv->portnr = dev->req_seq;
priv->init_type = type;
ret = board_usb_init(priv->portnr, priv->init_type);
@@ -766,7 +770,7 @@ int ehci_usb_remove(struct udevice *dev)
ehci_deregister(dev);
- return board_usb_cleanup(dev->seq, priv->init_type);
+ return board_usb_cleanup(dev->req_seq, priv->init_type);
}
static const struct udevice_id mx6_usb_ids[] = {
--
2.16.4
[PATCH 7/7] usb: ehci-mx6: configure usb out of suspend state
When moving to support partition reboot or android auto on XEN,
linux kernel will runs into runtime suspend state, and the usb
will be configured to low power suspend state by Linux.
Then we reboot and runs into U-Boot, however the usb already in
suspended state and uboot not able to lock the phy pll,
after clearing PHCD to out of suspended state, the phy pll could be
locked and fastboot works.
Suggested-by: Li Jun
Reviewed-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/host/ehci-mx6.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 74f6c80d93..041b3da9ac 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -438,10 +438,17 @@ int __weak board_ehci_power(int port, int on)
int ehci_mx6_common_init(struct usb_ehci *ehci, int index)
{
int ret;
+ u32 portsc;
enable_usboh3_clk(1);
mdelay(1);
+ portsc = readl(>portsc);
+ if (portsc & PORT_PTS_PHCD) {
+ debug("suspended: portsc %x, enabled it.\n", portsc);
+ clrbits_le32(>portsc, PORT_PTS_PHCD);
+ }
+
/* Do board specific initialization */
ret = board_ehci_hcd_init(index);
if (ret)
--
2.16.4
[PATCH 3/7] usb: ehci-mx6: Turn on the power domain of USB PHY
From: Ye Li
Since there is no uclass for USB PHY. The device won't be setup for the USB PHY
node in DTB. And its associated power domain device won't be turned on neither
by DM framework.
This patch modifies the ehci-mx6 driver to enable the power domain device before
access the USB PHY. This is only for DM driver. For non-DM part, users still
need to power on the USB PHY in boards/SoC codes.
Reviewed-by: Peng Fan
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/host/ehci-mx6.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 191d619220..92e8bb91d2 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -2,6 +2,8 @@
/*
* Copyright (c) 2009 Daniel Mack
* Copyright (C) 2010 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ *
*/
#include
@@ -23,6 +25,9 @@
#include
#include "ehci.h"
+#if CONFIG_IS_ENABLED(POWER_DOMAIN)
+#include
+#endif
DECLARE_GLOBAL_DATA_PTR;
@@ -590,6 +595,18 @@ static int ehci_usb_phy_mode(struct udevice *dev)
if ((fdt_addr_t)addr == FDT_ADDR_T_NONE)
return -EINVAL;
+ /* Need to power on the PHY before access it */
+#if CONFIG_IS_ENABLED(POWER_DOMAIN)
+ struct udevice phy_dev;
+ struct power_domain pd;
+
+ phy_dev.node = offset_to_ofnode(phy_off);
+ if (!power_domain_get(_dev, )) {
+ if (power_domain_on())
+ return -EINVAL;
+ }
+#endif
+
phy_ctrl = (void __iomem *)(addr + USBPHY_CTRL);
val = readl(phy_ctrl);
--
2.16.4
[PATCH 2/7] usb: ehci-mx6: Add i.MX8 OTG controller support
From: Ye Li
The i.MX8 has two USB controllers: USBOH and USB3. The USBOH reuses
previous i.MX6/7. It has same PHY IP as i.MX7ULP but NC registers
are same as i.MX7D. So add its support in ehci-mx6 driver.
Also the driver is updated to remove build warning for 64 bits CPU.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/host/Kconfig| 4 +-
drivers/usb/host/ehci-mx6.c | 97 ++---
2 files changed, 85 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 1c374a7bd8..f48547caa0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -139,8 +139,8 @@ config USB_EHCI_MX5
Enables support for the on-chip EHCI controller on i.MX5 SoCs.
config USB_EHCI_MX6
- bool "Support for i.MX6/i.MX7ULP on-chip EHCI USB controller"
- depends on ARCH_MX6 || ARCH_MX7ULP
+ bool "Support for i.MX6/i.MX7ULP/i.MX8 on-chip EHCI USB controller"
+ depends on ARCH_MX6 || ARCH_MX7ULP || ARCH_IMX8
default y
---help---
Enables support for the on-chip EHCI controller on i.MX6 SoCs.
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index e654595683..191d619220 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -62,12 +62,20 @@ DECLARE_GLOBAL_DATA_PTR;
#define UCTRL_OVER_CUR_POL (1 << 8) /* OTG Polarity of Overcurrent */
#define UCTRL_OVER_CUR_DIS (1 << 7) /* Disable OTG Overcurrent Detection */
+#define PLL_USB_EN_USB_CLKS_MASK (0x01 << 6)
+#define PLL_USB_PWR_MASK (0x01 << 12)
+#define PLL_USB_ENABLE_MASK(0x01 << 13)
+#define PLL_USB_BYPASS_MASK(0x01 << 16)
+#define PLL_USB_REG_ENABLE_MASK(0x01 << 21)
+#define PLL_USB_DIV_SEL_MASK (0x07 << 22)
+#define PLL_USB_LOCK_MASK (0x01 << 31)
+
/* USBCMD */
#define UCMD_RUN_STOP (1 << 0) /* controller run/stop */
#define UCMD_RESET (1 << 1) /* controller reset */
-#if defined(CONFIG_MX6) || defined(CONFIG_MX7ULP)
-static const unsigned phy_bases[] = {
+#if defined(CONFIG_MX6) || defined(CONFIG_MX7ULP) || defined(CONFIG_IMX8)
+static const ulong phy_bases[] = {
USB_PHY0_BASE_ADDR,
#if defined(USB_PHY1_BASE_ADDR)
USB_PHY1_BASE_ADDR,
@@ -101,6 +109,53 @@ static void usb_power_config(int index)
scg_enable_usb_pll(true);
+#elif defined(CONFIG_IMX8)
+ struct usbphy_regs __iomem *usbphy =
+ (struct usbphy_regs __iomem *)USB_PHY0_BASE_ADDR;
+ int timeout = 100;
+
+ if (index > 0)
+ return;
+
+ writel(ANADIG_USB2_CHRG_DETECT_EN_B |
+ ANADIG_USB2_CHRG_DETECT_CHK_CHRG_B,
+ >usb1_chrg_detect);
+
+ if (!(readl(>usb1_pll_480_ctrl) & PLL_USB_LOCK_MASK)) {
+
+ /* Enable the regulator first */
+ writel(PLL_USB_REG_ENABLE_MASK,
+ >usb1_pll_480_ctrl_set);
+
+ /* Wait at least 25us */
+ udelay(25);
+
+ /* Enable the power */
+ writel(PLL_USB_PWR_MASK, >usb1_pll_480_ctrl_set);
+
+ /* Wait lock */
+ while (timeout--) {
+ if (readl(>usb1_pll_480_ctrl) &
+ PLL_USB_LOCK_MASK)
+ break;
+ udelay(10);
+ }
+
+ if (timeout <= 0) {
+ /* If timeout, we power down the pll */
+ writel(PLL_USB_PWR_MASK,
+ >usb1_pll_480_ctrl_clr);
+ return;
+ }
+ }
+
+ /* Clear the bypass */
+ writel(PLL_USB_BYPASS_MASK, >usb1_pll_480_ctrl_clr);
+
+ /* Enable the PLL clock out to USB */
+ writel((PLL_USB_EN_USB_CLKS_MASK | PLL_USB_ENABLE_MASK),
+ >usb1_pll_480_ctrl_set);
+
#else
struct anatop_regs __iomem *anatop =
(struct anatop_regs __iomem *)ANATOP_BASE_ADDR;
@@ -212,6 +267,20 @@ struct usbnc_regs {
u32 reserve0[2];
u32 hsic_ctrl;
};
+#elif defined(CONFIG_IMX8)
+struct usbnc_regs {
+ u32 ctrl1;
+ u32 ctrl2;
+ u32 reserve1[10];
+ u32 phy_cfg1;
+ u32 phy_cfg2;
+ u32 reserve2;
+ u32 phy_status;
+ u32 reserve3[4];
+ u32 adp_cfg1;
+ u32 adp_cfg2;
+ u32 adp_status;
+};
#else
/* Base address for this IP block is 0x02184800 */
struct usbnc_regs {
@@ -240,7 +309,7 @@ struct usbnc_regs {
static void usb_power_config(int index)
{
- struct usbnc_regs *usbnc = (struct usbnc_regs *)(USB_BASE_ADDR +
+ struct usbnc_regs *usbnc = (struct usbnc_regs *)(ulong)(USB_BASE_ADDR +
(0x1 * index) + USBNC_OFFSET);
void __iomem *phy_cfg2 = (void __iomem *)(>phy_cfg2);
@@ -253,7 +322,7 @@ static void usb_power_config(int index)
int
[PATCH 1/7] usb: ehci-mx6: Add powerup_fixup implementation
From: Ye Li
When doing port reset, the PR bit of PORTSC1 will be automatically
cleared by our IP, but standard EHCI needs explicit clear by software. The
EHCI-HCD driver follow the EHCI specification, so after 50ms wait, it
clear the PR bit by writting to the PORTSC1 register with value loaded before
setting PR.
This sequence is ok for our IP when the delay time is exact. But when the timer
is slower, some bits like PE, PSPD have been set by controller automatically
after the PR is automatically cleared. So the writing to the PORTSC1 will
overwrite
these bits set by controller. And eventually the driver gets wrong status.
We implement the powerup_fixup operation which delays 50ms and will check
the PR until it is cleared by controller. And will update the reg value which
is written
to PORTSC register by EHCI-HCD driver. This is much safer than depending on the
delay
time to be accurate and aligining with controller's behaiver.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/host/ehci-mx6.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 5f84c7b91d..e654595683 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -267,6 +267,25 @@ int usb_phy_mode(int port)
}
#endif
+static void ehci_mx6_powerup_fixup(struct ehci_ctrl *ctrl, uint32_t
*status_reg,
+ uint32_t *reg)
+{
+ u32 result;
+ int usec = 2000;
+
+ mdelay(50);
+
+ do {
+ result = ehci_readl(status_reg);
+ udelay(5);
+ if (!(result & EHCI_PS_PR))
+ break;
+ usec--;
+ } while (usec > 0);
+
+ *reg = ehci_readl(status_reg);
+}
+
static void usb_oc_config(int index)
{
#if defined(CONFIG_MX6)
@@ -366,6 +385,10 @@ int ehci_mx6_common_init(struct usb_ehci *ehci, int index)
}
#if !CONFIG_IS_ENABLED(DM_USB)
+static const struct ehci_ops mx6_ehci_ops = {
+ .powerup_fixup = ehci_mx6_powerup_fixup,
+};
+
int ehci_hcd_init(int index, enum usb_init_type init,
struct ehci_hccr **hccr, struct ehci_hcor **hcor)
{
@@ -394,6 +417,8 @@ int ehci_hcd_init(int index, enum usb_init_type init,
if (ret)
return ret;
+ ehci_set_controller_priv(index, NULL, _ehci_ops);
+
type = board_usb_phy_mode(index);
if (hccr && hcor) {
@@ -467,7 +492,8 @@ static int mx6_init_after_reset(struct ehci_ctrl *dev)
}
static const struct ehci_ops mx6_ehci_ops = {
- .init_after_reset = mx6_init_after_reset
+ .powerup_fixup = ehci_mx6_powerup_fixup,
+ .init_after_reset = mx6_init_after_reset
};
static int ehci_usb_phy_mode(struct udevice *dev)
--
2.16.4
[PATCH] usb: gadget: Fix controller index in UMS
From: Ye Li
The usb mass storage (f_mass_storage.c) uses fixed usb index 0,
this causes problem while CDNS3 USB controller index is 1.
Modify the API of fsg to pass the controller index.
Reviewed-by: Jun Li
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
cmd/usb_mass_storage.c | 2 +-
drivers/usb/gadget/f_mass_storage.c | 6 --
include/usb_mass_storage.h | 2 +-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/cmd/usb_mass_storage.c b/cmd/usb_mass_storage.c
index d565635c6c..cf2f55994e 100644
--- a/cmd/usb_mass_storage.c
+++ b/cmd/usb_mass_storage.c
@@ -170,7 +170,7 @@ static int do_usb_mass_storage(struct cmd_tbl *cmdtp, int
flag,
goto cleanup_ums_init;
}
- rc = fsg_init(ums, ums_count);
+ rc = fsg_init(ums, ums_count, controller_index);
if (rc) {
pr_err("fsg_init failed\n");
rc = CMD_RET_FAILURE;
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 439a31c255..45f0504b6e 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -435,6 +435,7 @@ static void set_bulk_out_req_length(struct fsg_common
*common,
static struct ums *ums;
static int ums_count;
static struct fsg_common *the_fsg_common;
+static unsigned int controller_index;
static int fsg_set_halt(struct fsg_dev *fsg, struct usb_ep *ep)
{
@@ -679,7 +680,7 @@ static int sleep_thread(struct fsg_common *common)
k = 0;
}
- usb_gadget_handle_interrupts(0);
+ usb_gadget_handle_interrupts(controller_index);
}
common->thread_wakeup_needed = 0;
return rc;
@@ -2764,10 +2765,11 @@ int fsg_add(struct usb_configuration *c)
return fsg_bind_config(c->cdev, c, fsg_common);
}
-int fsg_init(struct ums *ums_devs, int count)
+int fsg_init(struct ums *ums_devs, int count, unsigned int controller_idx)
{
ums = ums_devs;
ums_count = count;
+ controller_index = controller_idx;
return 0;
}
diff --git a/include/usb_mass_storage.h b/include/usb_mass_storage.h
index c7b770fa3e..08ccc97cf2 100644
--- a/include/usb_mass_storage.h
+++ b/include/usb_mass_storage.h
@@ -25,7 +25,7 @@ struct ums {
struct blk_desc block_dev;
};
-int fsg_init(struct ums *ums_devs, int count);
+int fsg_init(struct ums *ums_devs, int count, unsigned int controller_idx);
void fsg_cleanup(void);
int fsg_main_thread(void *);
int fsg_add(struct usb_configuration *c);
--
2.16.4
[PATCH] usb: ci_udc: Add function to remove usb device
From: Ye Li
When unregister gadget driver in ci_udc, the usb device is not
removed or stop. This causes next "usb start" fails to work.
Add a new interface "usb_remove_ehci_gadget" in usb-uclass to
remove the usb device for DM driver. Using "usb_lowlevel_stop" for
non-DM driver.
Signed-off-by: Ye Li
Signed-off-by: Peng Fan
---
drivers/usb/gadget/ci_udc.c | 7 +++
drivers/usb/host/usb-uclass.c | 18 ++
include/usb.h | 9 +
3 files changed, 34 insertions(+)
diff --git a/drivers/usb/gadget/ci_udc.c b/drivers/usb/gadget/ci_udc.c
index cdbdbcc5ca..cdb8f6fb3d 100644
--- a/drivers/usb/gadget/ci_udc.c
+++ b/drivers/usb/gadget/ci_udc.c
@@ -1053,6 +1053,13 @@ int usb_gadget_unregister_driver(struct
usb_gadget_driver *driver)
free(controller.items_mem);
free(controller.epts);
+#if CONFIG_IS_ENABLED(DM_USB)
+ usb_remove_ehci_gadget();
+#else
+ usb_lowlevel_stop(0);
+ controller.ctrl = NULL;
+#endif
+
return 0;
}
diff --git a/drivers/usb/host/usb-uclass.c b/drivers/usb/host/usb-uclass.c
index cb79dfbbd5..50ba39af42 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -411,6 +411,24 @@ int usb_setup_ehci_gadget(struct ehci_ctrl **ctlrp)
return 0;
}
+int usb_remove_ehci_gadget(struct ehci_ctrl **ctlrp)
+{
+ struct udevice *dev;
+ int ret;
+
+ /* Find the old device and remove it */
+ ret = uclass_find_device_by_seq(UCLASS_USB, 0, true, );
+ if (ret)
+ return ret;
+ ret = device_remove(dev, DM_REMOVE_NORMAL);
+ if (ret)
+ return ret;
+
+ *ctlrp = NULL;
+
+ return 0;
+}
+
/* returns 0 if no match, 1 if match */
static int usb_match_device(const struct usb_device_descriptor *desc,
const struct usb_device_id *id)
diff --git a/include/usb.h b/include/usb.h
index fa9e09607e..5a7af882fb 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -921,6 +921,15 @@ struct ehci_ctrl;
*/
int usb_setup_ehci_gadget(struct ehci_ctrl **ctlrp);
+/**
+ * usb_remove_ehci_gadget() - Remove a gadget USB device
+ *
+ * TODO(s...@chromium.org): Tidy this up when USB gadgets can use driver model
+ *
+ * This provides a way to tell a controller to remove a USB device
+ */
+int usb_remove_ehci_gadget(struct ehci_ctrl **ctlrp);
+
/**
* usb_stor_reset() - Prepare to scan USB storage devices
*
--
2.16.4
Re: Please pull u-boot-video
On Sun, Jun 28, 2020 at 02:27:57PM +0200, Anatolij Gustschin wrote: > Hi Tom, > > please pull some fixes for v2020.07. Thanks! > > gitlab CI: > https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/3806 > > The following changes since commit eae62ae8de1893f7cf08e276ab841d3f99245603: > > Merge tag 'efi-2020-07-rc6' of > https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-25 13:33:15 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-video.git > tags/fixes-for-v2020.07 > > for you to fetch changes up to bccb385a83a5f9ee603a30de1d39b03fd6f45b23: > > video: orisetech_otm8009a: fill characteristics of DSI data link > (2020-06-28 01:28:03 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request: u-boot-rockchip-20200628
On Sun, Jun 28, 2020 at 06:20:29PM +0800, Kever Yang wrote: > Hi Tom, > > Please pull the rockchip updates/fixes: > - rk3188 cpu init and APLL fix; > - rk3399: Add BOOTENV_SF command; > - rk3288 correct vop0 vop1 setting; > > Gitlab ci: > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3807 > > Thanks, > - Kever > > The following changes since commit eae62ae8de1893f7cf08e276ab841d3f99245603: > > Merge tag 'efi-2020-07-rc6' of > https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-25 13:33:15 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20200628 > > for you to fetch changes up to 673eb44e91bc0c06cb1e3f353f5d07b4f9e5a586: > > rockchip: correctly set vop0 or vop1 (2020-06-28 09:56:11 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] Uboot socfpga
On Fri, Jun 26, 2020 at 04:02:32AM +, Tan, Ley Foon wrote: > Hi Tom > > Please pull one fix for uboot socfpga. > Thanks. > > Regards > Ley Foon > > The following changes since commit eae62ae8de1893f7cf08e276ab841d3f99245603: > > Merge tag 'efi-2020-07-rc6' of > https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-25 13:33:15 > -0400) > > are available in the Git repository at: > > https://github.com/lftan/u-boot.git for-tom > > for you to fetch changes up to 8a204312abad7913f9b2209a71bef81853647b21: > > arm: socfpga: misc_s10: Fix EMAC register address calculation (2020-06-26 > 11:30:24 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 15/35] acpi: Support writing an integer
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > ACPI supports storing integers in various ways. Add a function to handle > this. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > include/acpi/acpigen.h | 17 ++ > lib/acpi/acpigen.c | 51 ++ > test/dm/acpigen.c | 46 + > 3 files changed, 114 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 13/35] acpigen: Support writing a length
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> It is convenient to write a length value for preceding a block of data.
> Of course the length is not known or is hard to calculate a priori. So add
> a way to mark the start on a stack, so the length can be updated when
> known.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v3:
> - Add a reference to the ACPI spec
> - Add a define for the 0x80 constant
> - Move the function comments into this patch
>
> include/acpi/acpigen.h | 38 +
> include/dm/acpi.h | 7 +
> lib/acpi/acpigen.c | 33 ++
> test/dm/acpigen.c | 64 --
> 4 files changed, 140 insertions(+), 2 deletions(-)
>
> diff --git a/include/acpi/acpigen.h b/include/acpi/acpigen.h
> index 7365cce738..12cd1bd578 100644
> --- a/include/acpi/acpigen.h
> +++ b/include/acpi/acpigen.h
> @@ -14,6 +14,9 @@
>
> struct acpi_ctx;
>
> +/* Top 4 bits of the value used to indicate a three-byte length value */
> +#define ACPI_PKG_LEN_3_BYTES 0x80
> +
> /**
> * acpigen_get_current() - Get the current ACPI code output pointer
> *
> @@ -65,4 +68,39 @@ void acpigen_emit_stream(struct acpi_ctx *ctx, const char
> *data, int size);
> */
> void acpigen_emit_string(struct acpi_ctx *ctx, const char *str);
>
> +/**
> + * acpigen_write_len_f() - Write a 'forward' length placeholder
> + *
> + * This adds space for a length value in the ACPI stream and pushes the
> current
> + * position (before the length) on the stack. After calling this you can
> write
> + * some data and then call acpigen_pop_len() to update the length value.
> + *
> + * Usage:
> + *
> + *acpigen_write_len_f() --\
> + *acpigen_write...() |
> + *acpigen_write...() |
> + * acpigen_write_len_f() --\ |
> + * acpigen_write...() | |
> + * acpigen_write...() | |
> + * acpigen_pop_len() --/ |
> + *acpigen_write...() |
> + *acpigen_pop_len() --/
> + *
> + * See ACPI 6.3 section 20.2.4 Package Length Encoding
It's better we put some more comments here mentioning that we are
hardcoding a 3 byte packet length encoding that can represent up to
2*20 packet length in total.
Any chance to optimize this routine not to use a hardcode 3 byte encoding?
> + *
> + * @ctx: ACPI context pointer
> + */
> +void acpigen_write_len_f(struct acpi_ctx *ctx);
> +
> +/**
> + * acpigen_pop_len() - Update the previously stacked length placeholder
> + *
> + * Call this after the data for the block gas been written. It updates the
typo: gas -> has
> + * top length value in the stack and pops it off.
> + *
> + * @ctx: ACPI context pointer
> + */
> +void acpigen_pop_len(struct acpi_ctx *ctx);
> +
> #endif
> diff --git a/include/dm/acpi.h b/include/dm/acpi.h
> index 696b1a96a0..f27ca64507 100644
> --- a/include/dm/acpi.h
> +++ b/include/dm/acpi.h
> @@ -22,6 +22,9 @@
> /* Length of an ACPI name string including nul terminator */
nits: nul -> null
> #define ACPI_NAME_MAX (ACPI_NAME_LEN + 1)
>
> +/* Number of nested objects supported */
> +#define ACPIGEN_LENSTACK_SIZE 10
> +
> #if !defined(__ACPI__)
>
> /**
> @@ -35,6 +38,8 @@
> * adding a new table. The RSDP holds pointers to the RSDT and XSDT.
> * @rsdt: Pointer to the Root System Description Table
> * @xsdt: Pointer to the Extended System Description Table
> + * @len_stack: Stack of 'length' words to fix up later
> + * @ltop: Points to current top of stack (0 = empty)
> */
> struct acpi_ctx {
> void *base;
> @@ -42,6 +47,8 @@ struct acpi_ctx {
> struct acpi_rsdp *rsdp;
> struct acpi_rsdt *rsdt;
> struct acpi_xsdt *xsdt;
> + char *len_stack[ACPIGEN_LENSTACK_SIZE];
> + int ltop;
> };
>
> /**
> diff --git a/lib/acpi/acpigen.c b/lib/acpi/acpigen.c
> index 1223f0d1c4..2c2b604d80 100644
> --- a/lib/acpi/acpigen.c
> +++ b/lib/acpi/acpigen.c
> @@ -10,6 +10,7 @@
>
> #include
> #include
> +#include
> #include
> #include
>
> @@ -37,6 +38,38 @@ void acpigen_emit_dword(struct acpi_ctx *ctx, uint data)
> acpigen_emit_byte(ctx, (data >> 24) & 0xff);
> }
>
> +/*
> + * Maximum length for an ACPI object generated by this code,
> + *
> + * If you need to change this, change acpigen_write_len_f(ctx) and
> + * acpigen_pop_len(ctx)
> + */
> +#define ACPIGEN_MAXLEN 0xf
> +
> +void acpigen_write_len_f(struct acpi_ctx *ctx)
> +{
> + assert(ctx->ltop < (ACPIGEN_LENSTACK_SIZE - 1));
> + ctx->len_stack[ctx->ltop++] = ctx->current;
> + acpigen_emit_byte(ctx, 0);
> + acpigen_emit_byte(ctx, 0);
> + acpigen_emit_byte(ctx, 0);
> +}
> +
> +void acpigen_pop_len(struct acpi_ctx *ctx)
> +{
> + int len;
> + char *p;
> +
> + assert(ctx->ltop > 0);
> + p = ctx->len_stack[--ctx->ltop];
> + len = ctx->current - (void *)p;
> + assert(len <= ACPIGEN_MAXLEN);
> + /* generate
Re: [PATCH v3 14/35] acpigen: Support writing a package
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > A package collects together several elements. Add an easy way of writing > a package header and updating its length later. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > Changes in v3: > - Fix 'easy of testing' typo > - Move two function comments into the previous patch > > include/acpi/acpigen.h | 32 > lib/acpi/acpigen.c | 12 > test/dm/acpigen.c | 27 +++ > 3 files changed, 71 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 12/35] acpi: Support generation of SPI descriptor
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a function to write a SPI descriptor to the generated ACPI code.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Make acpi_device_write_spi() static
> - Add an extra comment about scope to acpi_device_set_spi()
> - Use BIT() in a few places
> - Resist the temptation to go to >80 characters
>
> Changes in v2:
> - Fix memset of SPI descriptor
>
> drivers/spi/sandbox_spi.c | 11
> include/acpi/acpi_device.h | 36 +++
> include/spi.h | 4 +-
> lib/acpi/acpi_device.c | 124 +
> test/dm/acpigen.c | 36 +++
> 5 files changed, 209 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/sandbox_spi.c b/drivers/spi/sandbox_spi.c
> index b0a46c8868..4264acc953 100644
> --- a/drivers/spi/sandbox_spi.c
> +++ b/drivers/spi/sandbox_spi.c
> @@ -21,6 +21,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #ifndef CONFIG_SPI_IDLE_VAL
> @@ -133,6 +134,15 @@ static int sandbox_spi_get_mmap(struct udevice *dev,
> ulong *map_basep,
> return 0;
> }
>
> +static int sandbox_spi_get_name(const struct udevice *dev, char *out_name)
> +{
> + return acpi_copy_name(out_name, "SSPI");
> +}
> +
> +struct acpi_ops sandbox_spi_acpi_ops = {
> + .get_name = sandbox_spi_get_name,
> +};
> +
> static const struct dm_spi_ops sandbox_spi_ops = {
> .xfer = sandbox_spi_xfer,
> .set_speed = sandbox_spi_set_speed,
> @@ -151,4 +161,5 @@ U_BOOT_DRIVER(spi_sandbox) = {
> .id = UCLASS_SPI,
> .of_match = sandbox_spi_ids,
> .ops= _spi_ops,
> + ACPI_OPS_PTR(_spi_acpi_ops)
> };
> diff --git a/include/acpi/acpi_device.h b/include/acpi/acpi_device.h
> index f738b03d58..c0c96183e4 100644
> --- a/include/acpi/acpi_device.h
> +++ b/include/acpi/acpi_device.h
> @@ -10,6 +10,7 @@
> #define __ACPI_DEVICE_H
>
> #include
> +#include
> #include
>
> struct acpi_ctx;
> @@ -207,6 +208,29 @@ struct acpi_i2c {
> const char *resource;
> };
>
> +/**
> + * struct acpi_spi - representation of an ACPI SPI device
> + *
> + * @device_select: Chip select used by this device (typically 0)
> + * @device_select_polarity: Polarity for the device
> + * @wire_mode: Number of wires used for SPI
> + * @speed: Bus speed in Hz
> + * @data_bit_length: Word length for SPI (typically 8)
> + * @clock_phase: Clock phase to capture data
> + * @clock_polarity: Bus polarity
> + * @resource: Resource name for the SPI controller
> + */
> +struct acpi_spi {
> + u16 device_select;
> + enum spi_polarity device_select_polarity;
> + enum spi_wire_mode wire_mode;
> + unsigned int speed;
> + u8 data_bit_length;
> + enum spi_clock_phase clock_phase;
> + enum spi_polarity clock_polarity;
> + const char *resource;
> +};
> +
> /**
> * acpi_device_path() - Get the full path to an ACPI device
> *
> @@ -306,4 +330,16 @@ int acpi_device_write_interrupt_or_gpio(struct acpi_ctx
> *ctx,
> */
> int acpi_device_write_i2c_dev(struct acpi_ctx *ctx, const struct udevice
> *dev);
>
> +/**
> + * acpi_device_write_spi_dev() - Write a SPI device to ACPI
> + *
> + * This writes a serial bus descriptor for the SPI device so that ACPI can
> use
> + * it
> + *
> + * @ctx: ACPI context pointer
> + * @dev: SPI device to write
> + * @return 0 if OK, -ve on error
> + */
> +int acpi_device_write_spi_dev(struct acpi_ctx *ctx, const struct udevice
> *dev);
> +
> #endif
> diff --git a/include/spi.h b/include/spi.h
> index 5cc6d6e008..f34533f54e 100644
> --- a/include/spi.h
> +++ b/include/spi.h
> @@ -13,8 +13,8 @@
> #include
>
> /* SPI mode flags */
> -#define SPI_CPHA BIT(0) /* clock phase */
> -#define SPI_CPOL BIT(1) /* clock polarity */
> +#define SPI_CPHA BIT(0) /* clock phase (1 = SPI_CLOCK_PHASE_SECOND) */
> +#define SPI_CPOL BIT(1) /* clock polarity (1 = SPI_POLARITY_HIGH) */
> #define SPI_MODE_0 (0|0) /* (original MicroWire) */
> #define SPI_MODE_1 (0|SPI_CPHA)
> #define SPI_MODE_2 (SPI_CPOL|0)
> diff --git a/lib/acpi/acpi_device.c b/lib/acpi/acpi_device.c
> index 40d1a82d27..38101c8b96 100644
> --- a/lib/acpi/acpi_device.c
> +++ b/lib/acpi/acpi_device.c
> @@ -488,3 +488,127 @@ int acpi_device_write_i2c_dev(struct acpi_ctx *ctx,
> const struct udevice *dev)
>
> return 0;
> }
> +
> +#ifdef CONFIG_SPI
Why #ifdef? Other APIs don't have this
> +/* ACPI 6.1 section 6.4.3.8.2.2 - SpiSerialBus() */
> +static void acpi_device_write_spi(struct acpi_ctx *ctx, const struct
> acpi_spi *spi)
> +{
> + void *desc_length, *type_length;
> + u16 flags = 0;
> +
> + /* Byte 0: Descriptor Type */
> + acpigen_emit_byte(ctx, ACPI_DESCRIPTOR_SERIAL_BUS);
> +
> + /* Byte 1+2: Length (filled in later) */
> + desc_length =
Re: [PATCH v3 11/35] acpi: Support generation of I2C descriptor
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a function to write a GPIO descriptor to the generated ACPI code.
>
> Reviewed-by: Wolfgang Wallner
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Update comment in acpi_device_set_i2c() to talk about scope parameter
>
> Changes in v2:
> - Fix memset of I2C descriptor
>
> drivers/i2c/sandbox_i2c.c | 11
> drivers/rtc/sandbox_rtc.c | 13 +
> include/acpi/acpi_device.h | 36 +
> lib/acpi/acpi_device.c | 107 +
> test/dm/acpigen.c | 32 +++
> 5 files changed, 199 insertions(+)
>
> diff --git a/drivers/i2c/sandbox_i2c.c b/drivers/i2c/sandbox_i2c.c
> index f4ae2397a0..125026da90 100644
> --- a/drivers/i2c/sandbox_i2c.c
> +++ b/drivers/i2c/sandbox_i2c.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -83,6 +84,15 @@ static int sandbox_i2c_xfer(struct udevice *bus, struct
> i2c_msg *msg,
> return ops->xfer(emul, msg, nmsgs);
> }
>
> +static int sandbox_i2c_get_name(const struct udevice *dev, char *out_name)
> +{
> + return acpi_copy_name(out_name, "SI2C");
> +}
> +
> +struct acpi_ops sandbox_i2c_acpi_ops = {
> + .get_name = sandbox_i2c_get_name,
> +};
> +
> static const struct dm_i2c_ops sandbox_i2c_ops = {
> .xfer = sandbox_i2c_xfer,
> };
> @@ -98,4 +108,5 @@ U_BOOT_DRIVER(i2c_sandbox) = {
> .of_match = sandbox_i2c_ids,
> .ops= _i2c_ops,
> .priv_auto_alloc_size = sizeof(struct sandbox_i2c_priv),
> + ACPI_OPS_PTR(_i2c_acpi_ops)
> };
> diff --git a/drivers/rtc/sandbox_rtc.c b/drivers/rtc/sandbox_rtc.c
> index b08d758a74..f2906c3397 100644
> --- a/drivers/rtc/sandbox_rtc.c
> +++ b/drivers/rtc/sandbox_rtc.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
>
> #define REG_COUNT 0x80
>
> @@ -84,6 +85,17 @@ static int sandbox_rtc_write8(struct udevice *dev,
> unsigned int reg, int val)
> return dm_i2c_reg_write(dev, reg, val);
> }
>
> +#if CONFIG_IS_ENABLED(ACPIGEN)
> +static int sandbox_rtc_get_name(const struct udevice *dev, char *out_name)
> +{
> + return acpi_copy_name(out_name, "RTCC");
> +}
> +
> +struct acpi_ops sandbox_rtc_acpi_ops = {
> + .get_name = sandbox_rtc_get_name,
> +};
> +#endif
> +
> static const struct rtc_ops sandbox_rtc_ops = {
> .get = sandbox_rtc_get,
> .set = sandbox_rtc_set,
> @@ -102,4 +114,5 @@ U_BOOT_DRIVER(rtc_sandbox) = {
> .id = UCLASS_RTC,
> .of_match = sandbox_rtc_ids,
> .ops= _rtc_ops,
> + ACPI_OPS_PTR(_rtc_acpi_ops)
> };
> diff --git a/include/acpi/acpi_device.h b/include/acpi/acpi_device.h
> index 863bf7cf47..f738b03d58 100644
> --- a/include/acpi/acpi_device.h
> +++ b/include/acpi/acpi_device.h
> @@ -9,6 +9,7 @@
> #ifndef __ACPI_DEVICE_H
> #define __ACPI_DEVICE_H
>
> +#include
> #include
>
> struct acpi_ctx;
> @@ -183,6 +184,29 @@ struct acpi_gpio {
> enum acpi_gpio_polarity polarity;
> };
>
> +/* ACPI Descriptors for Serial Bus interfaces */
> +#define ACPI_SERIAL_BUS_TYPE_I2C 1
> +#define ACPI_SERIAL_BUS_TYPE_SPI 2
> +#define ACPI_I2C_SERIAL_BUS_REVISION_ID1 /* TODO: upgrade to
> 2 */
> +#define ACPI_I2C_TYPE_SPECIFIC_REVISION_ID 1
> +#define ACPI_SPI_SERIAL_BUS_REVISION_ID1
> +#define ACPI_SPI_TYPE_SPECIFIC_REVISION_ID 1
nits: the SPI macros should be introduced in the next patch
> +
> +/**
> + * struct acpi_i2c - representation of an ACPI I2C device
> + *
> + * @address: 7-bit or 10-bit I2C address
> + * @mode_10bit: Which address size is used
> + * @speed: Bus speed in Hz
> + * @resource: Resource name for the I2C controller
> + */
> +struct acpi_i2c {
> + u16 address;
> + enum i2c_address_mode mode_10bit;
> + enum i2c_speed_rate speed;
> + const char *resource;
> +};
> +
> /**
> * acpi_device_path() - Get the full path to an ACPI device
> *
> @@ -270,4 +294,16 @@ int acpi_device_write_gpio_desc(struct acpi_ctx *ctx,
> int acpi_device_write_interrupt_or_gpio(struct acpi_ctx *ctx,
> struct udevice *dev, const char
> *prop);
>
> +/**
> + * acpi_device_write_i2c_dev() - Write an I2C device to ACPI
> + *
> + * This creates a I2cSerialBus descriptor for an I2C device, including
> + * information ACPI needs to use it.
> + *
> + * @ctx: ACPI context pointer
> + * @dev: I2C device to write
> + * @return 0 if OK, -ve on error
> + */
> +int acpi_device_write_i2c_dev(struct acpi_ctx *ctx, const struct udevice
> *dev);
> +
> #endif
> diff --git a/lib/acpi/acpi_device.c b/lib/acpi/acpi_device.c
> index bf16e8d9dd..40d1a82d27 100644
> --- a/lib/acpi/acpi_device.c
> +++ b/lib/acpi/acpi_device.c
> @@ -381,3 +381,110 @@ int acpi_device_write_interrupt_or_gpio(struct acpi_ctx
> *ctx,
>
> return 0;
> }
> +
> +/* ACPI 6.3
Re: [PATCH v2] test/py: test_efi_fit: Update #size-cells to 1
Hi Heinrich,
On Sun, Jun 28, 2020 at 8:23 PM Heinrich Schuchardt wrote:
>
> On 6/28/20 3:03 AM, Bin Meng wrote:
> > From: Bin Meng
> >
> > test_efi_fit tests fail on RISC-V currently. This is due to the
> > RISC-V arch_fixup_fdt() checks the #size-cells of the root node
> > in order to correctly fix up the reserved memory node.
> >
> > Per the DT binding, the /reserved-memory node requires both
> > <#address-cells> and <#size-cells> and they should use the same
> > values as the root node. For the root node, it's not very useful
> > if <#size-cells> is zero.
>
> The text you refer to is Linux's
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> Will you also fix the underlying problem that the /reserved-memory node
> does not provide its own #address-cells, #size-cells?
There is no underlying problem. The /reserved-memory fix-up codes will
copy whatever is from root node's #address-cells, #size-cells to it.
>
> >
> > Update #size-cells to 1 so tests can pass.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > Changes in v2:
> > - Update the reset node's property to contain a size
> >
> > test/py/tests/test_efi_fit.py | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/test/py/tests/test_efi_fit.py b/test/py/tests/test_efi_fit.py
> > index beaf4a3..06fb151 100644
> > --- a/test/py/tests/test_efi_fit.py
> > +++ b/test/py/tests/test_efi_fit.py
> > @@ -106,14 +106,14 @@ FDT_DATA = '''
> >
> > / {
> > #address-cells = <1>;
> > -#size-cells = <0>;
> > +#size-cells = <1>;
> >
> > model = "%(sys-arch)s %(fdt_type)s EFI FIT Boot Test";
> > compatible = "%(sys-arch)s";
> >
> > reset@0 {
> > compatible = "%(sys-arch)s,reset";
> > -reg = <0>;
> > +reg = <0 4>;
>
> This reg property is not used by any driver. I think it was only added
> to avoid a dtc warning.
>
> Reviewed-by: Heinrich Schuchardt
Regards,
Bin
Re: [PATCH] video: rk_vop: Fix wrong bpix for frame buffer
On Sun, 28 Jun 2020 20:36:46 +0530 Jagan Teki ja...@amarulasolutions.com wrote: ... > Any comments on this fix? it needs to be in the release in order to > work 4K HDMI. I did tests lower than 4K resolution as well. I'm afraid that this is not the right fix, so I skipped this patch in the video pull request for now. -- Anatolij
Re: [PATCH] video: rk_vop: Fix wrong bpix for frame buffer
Hi Jagan,
On Wed, 24 Jun 2020 20:48:43 +0530
Jagan Teki ja...@amarulasolutions.com wrote:
...
> @@ -425,7 +425,7 @@ int rk_vop_bind(struct udevice *dev)
> {
> struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
>
> - plat->size = 4 * (CONFIG_VIDEO_ROCKCHIP_MAX_XRES *
> + plat->size = VIDEO_BPP32 * (CONFIG_VIDEO_ROCKCHIP_MAX_XRES *
> CONFIG_VIDEO_ROCKCHIP_MAX_YRES);
Factor 4 here is actually correct (4 bytes/pixel * xres * yres),
so the problem must be elsewhere. Are you sure that the detected
display resolution matches the values in CONFIG_VIDEO_ROCKCHIP_MAX_*
options in your .config?
Using VIDEO_BPP32 enum here is wrong, VIDEO_BPP32 is log2 value of 32BPP.
We could use VNBYTES(VIDEO_BPP32) for readability, but it won't fix the
problem you see.
--
Anatolij
Re: [PATCH v2 1/5] arm: kirkwood: add DT spi0 alias to LaCie boards
On Sun, Jun 28, 2020 at 07:00:27PM +0200, Simon Guinot wrote: > The spi0 alias is needed by the environment code to retrieve the SPI > flash. This patch adds some -u-boot.dtsi files, providing the spi0 > aliases, for all the following Kirkwood-based LaCie boards: > > - d2 Network v2 > - Internet Space v2 > - 2Big Network v2 > - Network Space v2 > - Network Space Lite v2 > - Network Space Max v2 > - Network Space Mini v2 > > Note that this -u-boot.dtsi files will be removed as soon as the spi0 > aliases will be available in the upstream Linux dtsi files. > > Signed-off-by: Simon Guinot Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PATCH v2 5/5] arm: kirkwood: enable DM_ETH for LaCie board
This patch enables DM_ETH for the following Kirkwood-based LaCie boards:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2
Signed-off-by: Simon Guinot
---
board/LaCie/net2big_v2/net2big_v2.c | 2 +-
board/LaCie/netspace_v2/netspace_v2.c | 4 ++--
configs/d2net_v2_defconfig| 1 +
configs/inetspace_v2_defconfig| 1 +
configs/net2big_v2_defconfig | 1 +
configs/netspace_lite_v2_defconfig| 1 +
configs/netspace_max_v2_defconfig | 1 +
configs/netspace_mini_v2_defconfig| 1 +
configs/netspace_v2_defconfig | 1 +
9 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/board/LaCie/net2big_v2/net2big_v2.c
b/board/LaCie/net2big_v2/net2big_v2.c
index dbd8b5755da3..e94c9a6dce96 100644
--- a/board/LaCie/net2big_v2/net2big_v2.c
+++ b/board/LaCie/net2big_v2/net2big_v2.c
@@ -239,7 +239,7 @@ int misc_init_r(void)
/* Configure and initialize PHY */
void reset_phy(void)
{
- mv_phy_88e1116_init("egiga0", 8);
+ mv_phy_88e1116_init("ethernet-controller@72000", 8);
}
#endif
diff --git a/board/LaCie/netspace_v2/netspace_v2.c
b/board/LaCie/netspace_v2/netspace_v2.c
index 011cc563d19d..33246b201528 100644
--- a/board/LaCie/netspace_v2/netspace_v2.c
+++ b/board/LaCie/netspace_v2/netspace_v2.c
@@ -100,9 +100,9 @@ int misc_init_r(void)
void reset_phy(void)
{
#if defined(CONFIG_NETSPACE_LITE_V2) || defined(CONFIG_NETSPACE_MINI_V2)
- mv_phy_88e1318_init("egiga0", 0);
+ mv_phy_88e1318_init("ethernet-controller@72000", 0);
#else
- mv_phy_88e1116_init("egiga0", 8);
+ mv_phy_88e1116_init("ethernet-controller@72000", 8);
#endif
}
#endif
diff --git a/configs/d2net_v2_defconfig b/configs/d2net_v2_defconfig
index 33f48e0dd94c..31a5d91af2b3 100644
--- a/configs/d2net_v2_defconfig
+++ b/configs/d2net_v2_defconfig
@@ -45,6 +45,7 @@ CONFIG_BLK=y
# CONFIG_MMC is not set
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_DM_ETH=y
CONFIG_MVGBE=y
CONFIG_MII=y
CONFIG_SYS_NS16550=y
diff --git a/configs/inetspace_v2_defconfig b/configs/inetspace_v2_defconfig
index ca444d0aafa3..b5973977a5b8 100644
--- a/configs/inetspace_v2_defconfig
+++ b/configs/inetspace_v2_defconfig
@@ -45,6 +45,7 @@ CONFIG_BLK=y
# CONFIG_MMC is not set
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_DM_ETH=y
CONFIG_MVGBE=y
CONFIG_MII=y
CONFIG_SYS_NS16550=y
diff --git a/configs/net2big_v2_defconfig b/configs/net2big_v2_defconfig
index 4d0e50b3e0a5..bba85030492a 100644
--- a/configs/net2big_v2_defconfig
+++ b/configs/net2big_v2_defconfig
@@ -45,6 +45,7 @@ CONFIG_BLK=y
# CONFIG_MMC is not set
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_DM_ETH=y
CONFIG_MVGBE=y
CONFIG_MII=y
CONFIG_SYS_NS16550=y
diff --git a/configs/netspace_lite_v2_defconfig
b/configs/netspace_lite_v2_defconfig
index 26ca464e0b48..bfa93dbd1c27 100644
--- a/configs/netspace_lite_v2_defconfig
+++ b/configs/netspace_lite_v2_defconfig
@@ -45,6 +45,7 @@ CONFIG_BLK=y
# CONFIG_MMC is not set
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_DM_ETH=y
CONFIG_MVGBE=y
CONFIG_MII=y
CONFIG_SYS_NS16550=y
diff --git a/configs/netspace_max_v2_defconfig
b/configs/netspace_max_v2_defconfig
index af2d9df6ff8a..d0f750369a3a 100644
--- a/configs/netspace_max_v2_defconfig
+++ b/configs/netspace_max_v2_defconfig
@@ -45,6 +45,7 @@ CONFIG_BLK=y
# CONFIG_MMC is not set
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_DM_ETH=y
CONFIG_MVGBE=y
CONFIG_MII=y
CONFIG_SYS_NS16550=y
diff --git a/configs/netspace_mini_v2_defconfig
b/configs/netspace_mini_v2_defconfig
index 7e013b48d1a1..6cfaccf51dbd 100644
--- a/configs/netspace_mini_v2_defconfig
+++ b/configs/netspace_mini_v2_defconfig
@@ -43,6 +43,7 @@ CONFIG_BLK=y
# CONFIG_MMC is not set
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_DM_ETH=y
CONFIG_MVGBE=y
CONFIG_MII=y
CONFIG_SYS_NS16550=y
diff --git a/configs/netspace_v2_defconfig b/configs/netspace_v2_defconfig
index 3585b7cf6318..1bd148f9b511 100644
--- a/configs/netspace_v2_defconfig
+++ b/configs/netspace_v2_defconfig
@@ -45,6 +45,7 @@ CONFIG_BLK=y
# CONFIG_MMC is not set
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_DM_ETH=y
CONFIG_MVGBE=y
CONFIG_MII=y
CONFIG_SYS_NS16550=y
--
2.27.0
[PATCH v2 3/5] arm: kirkwood: switch LaCie boards to sata_mv driver
This patch switches the SATA driver from mvsata_ide to sata_mv for the following Kirkwood-based LaCie boards: - d2 Network v2 - Internet Space v2 - 2Big Network v2 - Network Space v2 - Network Space Lite v2 - Network Space Max v2 - Network Space Mini v2 Signed-off-by: Simon Guinot --- configs/d2net_v2_defconfig | 6 +++--- configs/inetspace_v2_defconfig | 6 +++--- configs/net2big_v2_defconfig | 6 +++--- configs/netspace_lite_v2_defconfig | 5 +++-- configs/netspace_max_v2_defconfig | 5 +++-- configs/netspace_mini_v2_defconfig | 5 +++-- configs/netspace_v2_defconfig | 6 +++--- include/configs/lacie_kw.h | 19 +-- 8 files changed, 30 insertions(+), 28 deletions(-) diff --git a/configs/d2net_v2_defconfig b/configs/d2net_v2_defconfig index 0d240daf01a1..5a3a1f60e308 100644 --- a/configs/d2net_v2_defconfig +++ b/configs/d2net_v2_defconfig @@ -21,8 +21,8 @@ CONFIG_MISC_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="d2v2> " CONFIG_CMD_EEPROM=y -CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -40,7 +40,8 @@ CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_ENV_ADDR=0x7 CONFIG_DM=y -CONFIG_MVSATA_IDE=y +CONFIG_SATA_MV=y +CONFIG_BLK=y # CONFIG_MMC is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y @@ -52,4 +53,3 @@ CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y -CONFIG_USB_STORAGE=y diff --git a/configs/inetspace_v2_defconfig b/configs/inetspace_v2_defconfig index 2ef916fa85ba..6cd4348a3c1d 100644 --- a/configs/inetspace_v2_defconfig +++ b/configs/inetspace_v2_defconfig @@ -21,8 +21,8 @@ CONFIG_MISC_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="ns2> " CONFIG_CMD_EEPROM=y -CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -40,7 +40,8 @@ CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_ENV_ADDR=0x7 CONFIG_DM=y -CONFIG_MVSATA_IDE=y +CONFIG_SATA_MV=y +CONFIG_BLK=y # CONFIG_MMC is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y @@ -52,4 +53,3 @@ CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y -CONFIG_USB_STORAGE=y diff --git a/configs/net2big_v2_defconfig b/configs/net2big_v2_defconfig index 9c1ed539b2a0..e7b7be7ed506 100644 --- a/configs/net2big_v2_defconfig +++ b/configs/net2big_v2_defconfig @@ -21,8 +21,8 @@ CONFIG_MISC_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="2big2> " CONFIG_CMD_EEPROM=y -CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -40,7 +40,8 @@ CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_ENV_ADDR=0x7 CONFIG_DM=y -CONFIG_MVSATA_IDE=y +CONFIG_SATA_MV=y +CONFIG_BLK=y # CONFIG_MMC is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y @@ -52,4 +53,3 @@ CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y -CONFIG_USB_STORAGE=y diff --git a/configs/netspace_lite_v2_defconfig b/configs/netspace_lite_v2_defconfig index 180d1402a188..9e3768ef4efd 100644 --- a/configs/netspace_lite_v2_defconfig +++ b/configs/netspace_lite_v2_defconfig @@ -21,8 +21,8 @@ CONFIG_MISC_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="ns2> " CONFIG_CMD_EEPROM=y -CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -40,7 +40,8 @@ CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_ENV_ADDR=0x7 CONFIG_DM=y -CONFIG_MVSATA_IDE=y +CONFIG_SATA_MV=y +CONFIG_BLK=y # CONFIG_MMC is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y diff --git a/configs/netspace_max_v2_defconfig b/configs/netspace_max_v2_defconfig index ed1a4e2d3653..b06321895b20 100644 --- a/configs/netspace_max_v2_defconfig +++ b/configs/netspace_max_v2_defconfig @@ -21,8 +21,8 @@ CONFIG_MISC_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="ns2> " CONFIG_CMD_EEPROM=y -CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -40,7 +40,8 @@ CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_ENV_ADDR=0x7 CONFIG_DM=y -CONFIG_MVSATA_IDE=y +CONFIG_SATA_MV=y +CONFIG_BLK=y # CONFIG_MMC is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y diff --git a/configs/netspace_mini_v2_defconfig b/configs/netspace_mini_v2_defconfig index 884bb63f0b90..7e013b48d1a1 100644 --- a/configs/netspace_mini_v2_defconfig +++ b/configs/netspace_mini_v2_defconfig @@ -21,8 +21,8 @@ CONFIG_MISC_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="ns2> " CONFIG_CMD_EEPROM=y -CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y +CONFIG_CMD_SATA=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y CONFIG_CMD_MII=y @@ -38,7 +38,8 @@ CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_ENV_ADDR=0x7
[PATCH v2 4/5] arm: kirkwood: enable DM_USB for LaCie board
This patch enables DM_USB and USB_STORAGE for the following Kirkwood-based LaCie boards: - d2 Network v2 - Internet Space v2 - 2Big Network v2 - Network Space v2 - Network Space Lite v2 - Network Space Max v2 Signed-off-by: Simon Guinot --- configs/d2net_v2_defconfig | 2 ++ configs/inetspace_v2_defconfig | 2 ++ configs/net2big_v2_defconfig | 2 ++ configs/netspace_lite_v2_defconfig | 2 ++ configs/netspace_max_v2_defconfig | 2 ++ configs/netspace_v2_defconfig | 2 ++ 6 files changed, 12 insertions(+) diff --git a/configs/d2net_v2_defconfig b/configs/d2net_v2_defconfig index 5a3a1f60e308..33f48e0dd94c 100644 --- a/configs/d2net_v2_defconfig +++ b/configs/d2net_v2_defconfig @@ -52,4 +52,6 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y +CONFIG_USB_STORAGE=y diff --git a/configs/inetspace_v2_defconfig b/configs/inetspace_v2_defconfig index 6cd4348a3c1d..ca444d0aafa3 100644 --- a/configs/inetspace_v2_defconfig +++ b/configs/inetspace_v2_defconfig @@ -52,4 +52,6 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y +CONFIG_USB_STORAGE=y diff --git a/configs/net2big_v2_defconfig b/configs/net2big_v2_defconfig index e7b7be7ed506..4d0e50b3e0a5 100644 --- a/configs/net2big_v2_defconfig +++ b/configs/net2big_v2_defconfig @@ -52,4 +52,6 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y +CONFIG_USB_STORAGE=y diff --git a/configs/netspace_lite_v2_defconfig b/configs/netspace_lite_v2_defconfig index 9e3768ef4efd..26ca464e0b48 100644 --- a/configs/netspace_lite_v2_defconfig +++ b/configs/netspace_lite_v2_defconfig @@ -52,5 +52,7 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_STORAGE=y +CONFIG_USB_STORAGE=y diff --git a/configs/netspace_max_v2_defconfig b/configs/netspace_max_v2_defconfig index b06321895b20..af2d9df6ff8a 100644 --- a/configs/netspace_max_v2_defconfig +++ b/configs/netspace_max_v2_defconfig @@ -52,5 +52,7 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_STORAGE=y +CONFIG_USB_STORAGE=y diff --git a/configs/netspace_v2_defconfig b/configs/netspace_v2_defconfig index fc09c6b22464..3585b7cf6318 100644 --- a/configs/netspace_v2_defconfig +++ b/configs/netspace_v2_defconfig @@ -52,4 +52,6 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y +CONFIG_USB_STORAGE=y -- 2.27.0
[PATCH v2 2/5] arm: kirkwood: convert LaCie boards to DM_SPI_FLASH
This patch converts the following Kirkwood-based LaCie boards to DM, DM_SPI and DM_SPI_FLASH: - d2 Network v2 - Internet Space v2 - 2Big Network v2 - Network Space v2 - Network Space Lite v2 - Network Space Max v2 - Network Space Mini v2 Signed-off-by: Simon Guinot --- configs/d2net_v2_defconfig | 6 -- configs/inetspace_v2_defconfig | 6 -- configs/net2big_v2_defconfig | 6 -- configs/netspace_lite_v2_defconfig | 6 -- configs/netspace_max_v2_defconfig | 6 -- configs/netspace_mini_v2_defconfig | 6 -- configs/netspace_v2_defconfig | 6 -- 7 files changed, 28 insertions(+), 14 deletions(-) diff --git a/configs/d2net_v2_defconfig b/configs/d2net_v2_defconfig index fe3c6c47620d..0d240daf01a1 100644 --- a/configs/d2net_v2_defconfig +++ b/configs/d2net_v2_defconfig @@ -9,6 +9,7 @@ CONFIG_ENV_OFFSET=0x7 CONFIG_ENV_SECT_SIZE=0x1 CONFIG_NR_DRAM_BANKS=2 CONFIG_IDENT_STRING=" D2 v2" +# CONFIG_SYS_MALLOC_F is not set CONFIG_SYS_EXTRA_OPTIONS="D2NET_V2" CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y @@ -22,7 +23,6 @@ CONFIG_SYS_PROMPT="d2v2> " CONFIG_CMD_EEPROM=y CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y -CONFIG_CMD_SF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -39,14 +39,16 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_ENV_ADDR=0x7 +CONFIG_DM=y CONFIG_MVSATA_IDE=y # CONFIG_MMC is not set -CONFIG_SPI_FLASH=y +CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_MVGBE=y CONFIG_MII=y CONFIG_SYS_NS16550=y CONFIG_SPI=y +CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y diff --git a/configs/inetspace_v2_defconfig b/configs/inetspace_v2_defconfig index 6144eb5fad45..2ef916fa85ba 100644 --- a/configs/inetspace_v2_defconfig +++ b/configs/inetspace_v2_defconfig @@ -9,6 +9,7 @@ CONFIG_ENV_OFFSET=0x7 CONFIG_ENV_SECT_SIZE=0x1 CONFIG_NR_DRAM_BANKS=2 CONFIG_IDENT_STRING=" IS v2" +# CONFIG_SYS_MALLOC_F is not set CONFIG_SYS_EXTRA_OPTIONS="INETSPACE_V2" CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y @@ -22,7 +23,6 @@ CONFIG_SYS_PROMPT="ns2> " CONFIG_CMD_EEPROM=y CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y -CONFIG_CMD_SF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -39,14 +39,16 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_ENV_ADDR=0x7 +CONFIG_DM=y CONFIG_MVSATA_IDE=y # CONFIG_MMC is not set -CONFIG_SPI_FLASH=y +CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_MVGBE=y CONFIG_MII=y CONFIG_SYS_NS16550=y CONFIG_SPI=y +CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y diff --git a/configs/net2big_v2_defconfig b/configs/net2big_v2_defconfig index 1389d3090096..9c1ed539b2a0 100644 --- a/configs/net2big_v2_defconfig +++ b/configs/net2big_v2_defconfig @@ -9,6 +9,7 @@ CONFIG_ENV_OFFSET=0x7 CONFIG_ENV_SECT_SIZE=0x1 CONFIG_NR_DRAM_BANKS=2 CONFIG_IDENT_STRING=" 2Big v2" +# CONFIG_SYS_MALLOC_F is not set CONFIG_SYS_EXTRA_OPTIONS="NET2BIG_V2" CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y @@ -22,7 +23,6 @@ CONFIG_SYS_PROMPT="2big2> " CONFIG_CMD_EEPROM=y CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y -CONFIG_CMD_SF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -39,14 +39,16 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_ENV_ADDR=0x7 +CONFIG_DM=y CONFIG_MVSATA_IDE=y # CONFIG_MMC is not set -CONFIG_SPI_FLASH=y +CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_MVGBE=y CONFIG_MII=y CONFIG_SYS_NS16550=y CONFIG_SPI=y +CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y diff --git a/configs/netspace_lite_v2_defconfig b/configs/netspace_lite_v2_defconfig index c744d2c58efc..180d1402a188 100644 --- a/configs/netspace_lite_v2_defconfig +++ b/configs/netspace_lite_v2_defconfig @@ -9,6 +9,7 @@ CONFIG_ENV_OFFSET=0x7 CONFIG_ENV_SECT_SIZE=0x1 CONFIG_NR_DRAM_BANKS=2 CONFIG_IDENT_STRING=" NS v2 Lite" +# CONFIG_SYS_MALLOC_F is not set CONFIG_SYS_EXTRA_OPTIONS="NETSPACE_LITE_V2" CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y @@ -22,7 +23,6 @@ CONFIG_SYS_PROMPT="ns2> " CONFIG_CMD_EEPROM=y CONFIG_CMD_IDE=y CONFIG_CMD_I2C=y -CONFIG_CMD_SF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -39,14 +39,16 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=2000 CONFIG_ENV_ADDR=0x7 +CONFIG_DM=y CONFIG_MVSATA_IDE=y # CONFIG_MMC is not set -CONFIG_SPI_FLASH=y +CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_MVGBE=y CONFIG_MII=y CONFIG_SYS_NS16550=y CONFIG_SPI=y +CONFIG_DM_SPI=y CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y diff --git a/configs/netspace_max_v2_defconfig b/configs/netspace_max_v2_defconfig index 8602729fcb4e..ed1a4e2d3653 100644 --- a/configs/netspace_max_v2_defconfig +++ b/configs/netspace_max_v2_defconfig @@ -9,6
[PATCH v2 1/5] arm: kirkwood: add DT spi0 alias to LaCie boards
The spi0 alias is needed by the environment code to retrieve the SPI
flash. This patch adds some -u-boot.dtsi files, providing the spi0
aliases, for all the following Kirkwood-based LaCie boards:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2
Note that this -u-boot.dtsi files will be removed as soon as the spi0
aliases will be available in the upstream Linux dtsi files.
Signed-off-by: Simon Guinot
---
arch/arm/dts/kirkwood-d2net-u-boot.dtsi | 7 +++
arch/arm/dts/kirkwood-is2-u-boot.dtsi | 7 +++
arch/arm/dts/kirkwood-net2big-u-boot.dtsi | 7 +++
arch/arm/dts/kirkwood-ns2-u-boot.dtsi | 7 +++
arch/arm/dts/kirkwood-ns2lite-u-boot.dtsi | 7 +++
arch/arm/dts/kirkwood-ns2max-u-boot.dtsi | 7 +++
arch/arm/dts/kirkwood-ns2mini-u-boot.dtsi | 7 +++
board/LaCie/net2big_v2/MAINTAINERS| 6 ++
board/LaCie/netspace_v2/MAINTAINERS | 21 ++---
9 files changed, 69 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/dts/kirkwood-d2net-u-boot.dtsi
create mode 100644 arch/arm/dts/kirkwood-is2-u-boot.dtsi
create mode 100644 arch/arm/dts/kirkwood-net2big-u-boot.dtsi
create mode 100644 arch/arm/dts/kirkwood-ns2-u-boot.dtsi
create mode 100644 arch/arm/dts/kirkwood-ns2lite-u-boot.dtsi
create mode 100644 arch/arm/dts/kirkwood-ns2max-u-boot.dtsi
create mode 100644 arch/arm/dts/kirkwood-ns2mini-u-boot.dtsi
diff --git a/arch/arm/dts/kirkwood-d2net-u-boot.dtsi
b/arch/arm/dts/kirkwood-d2net-u-boot.dtsi
new file mode 100644
index ..1f3b1854795b
--- /dev/null
+++ b/arch/arm/dts/kirkwood-d2net-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/arch/arm/dts/kirkwood-is2-u-boot.dtsi
b/arch/arm/dts/kirkwood-is2-u-boot.dtsi
new file mode 100644
index ..1f3b1854795b
--- /dev/null
+++ b/arch/arm/dts/kirkwood-is2-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/arch/arm/dts/kirkwood-net2big-u-boot.dtsi
b/arch/arm/dts/kirkwood-net2big-u-boot.dtsi
new file mode 100644
index ..1f3b1854795b
--- /dev/null
+++ b/arch/arm/dts/kirkwood-net2big-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/arch/arm/dts/kirkwood-ns2-u-boot.dtsi
b/arch/arm/dts/kirkwood-ns2-u-boot.dtsi
new file mode 100644
index ..1f3b1854795b
--- /dev/null
+++ b/arch/arm/dts/kirkwood-ns2-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/arch/arm/dts/kirkwood-ns2lite-u-boot.dtsi
b/arch/arm/dts/kirkwood-ns2lite-u-boot.dtsi
new file mode 100644
index ..1f3b1854795b
--- /dev/null
+++ b/arch/arm/dts/kirkwood-ns2lite-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/arch/arm/dts/kirkwood-ns2max-u-boot.dtsi
b/arch/arm/dts/kirkwood-ns2max-u-boot.dtsi
new file mode 100644
index ..1f3b1854795b
--- /dev/null
+++ b/arch/arm/dts/kirkwood-ns2max-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/arch/arm/dts/kirkwood-ns2mini-u-boot.dtsi
b/arch/arm/dts/kirkwood-ns2mini-u-boot.dtsi
new file mode 100644
index ..1f3b1854795b
--- /dev/null
+++ b/arch/arm/dts/kirkwood-ns2mini-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/board/LaCie/net2big_v2/MAINTAINERS
b/board/LaCie/net2big_v2/MAINTAINERS
index 8fec70315f5d..7046e1b2c5c7 100644
--- a/board/LaCie/net2big_v2/MAINTAINERS
+++ b/board/LaCie/net2big_v2/MAINTAINERS
@@ -1,6 +1,12 @@
NET2BIG_V2 BOARD
M: Simon Guinot
S: Maintained
+F: arch/arm/dts/kirkwood-d2net.dts
+F: arch/arm/dts/kirkwood-d2net-u-boot.dtsi
+F: arch/arm/dts/kirkwood-d2net.dtsi
+F: arch/arm/dts/kirkwood-net2big.dts
+F: arch/arm/dts/kirkwood-net2big-u-boot.dtsi
+F: arch/arm/dts/kirkwood-netxbig.dtsi
F: board/LaCie/net2big_v2/
F: include/configs/lacie_kw.h
F: configs/d2net_v2_defconfig
diff --git a/board/LaCie/netspace_v2/MAINTAINERS
b/board/LaCie/netspace_v2/MAINTAINERS
index 55fd50d4eb1b..1cc4f7108b6b 100644
--- a/board/LaCie/netspace_v2/MAINTAINERS
+++ b/board/LaCie/netspace_v2/MAINTAINERS
@@ -1,14 +1,21 @@
-NETSPACE_V2 BOARD
+NETSPACE_V2 BOARDS
M: Simon Guinot
S: Maintained
+F: arch/arm/dts/kirkwood-is2.dts
+F: arch/arm/dts/kirkwood-is2-u-boot.dtsi
+F: arch/arm/dts/kirkwood-ns2-common.dtsi
+F: arch/arm/dts/kirkwood-ns2.dts
+F: arch/arm/dts/kirkwood-ns2lite.dts
+F:
[PATCH v2 0/5] Convert LaCie boards to use DM drivers
This patch series converts the following LaCie boards (Marvell Kirkwood-based) to use DM drivers: - d2 Network v2 - Internet Space v2 - 2Big Network v2 - Network Space v2 - Network Space Lite v2 - Network Space Max v2 - Network Space Mini v2 Changes in v2: - Move spi0 DT aliases into per boards -u-boot.dtsi files. This files will be removed as soon as the spi0 aliases will be available in the Linux upstream dtsi files. Simon Guinot (5): arm: kirkwood: add DT spi0 alias to LaCie boards arm: kirkwood: convert LaCie boards to DM_SPI_FLASH arm: kirkwood: switch LaCie boards to sata_mv driver arm: kirkwood: enable DM_USB for LaCie board arm: kirkwood: enable DM_ETH for LaCie board arch/arm/dts/kirkwood-d2net-u-boot.dtsi | 7 +++ arch/arm/dts/kirkwood-is2-u-boot.dtsi | 7 +++ arch/arm/dts/kirkwood-net2big-u-boot.dtsi | 7 +++ arch/arm/dts/kirkwood-ns2-u-boot.dtsi | 7 +++ arch/arm/dts/kirkwood-ns2lite-u-boot.dtsi | 7 +++ arch/arm/dts/kirkwood-ns2max-u-boot.dtsi | 7 +++ arch/arm/dts/kirkwood-ns2mini-u-boot.dtsi | 7 +++ board/LaCie/net2big_v2/MAINTAINERS| 6 ++ board/LaCie/net2big_v2/net2big_v2.c | 2 +- board/LaCie/netspace_v2/MAINTAINERS | 21 ++--- board/LaCie/netspace_v2/netspace_v2.c | 4 ++-- configs/d2net_v2_defconfig| 13 + configs/inetspace_v2_defconfig| 13 + configs/net2big_v2_defconfig | 13 + configs/netspace_lite_v2_defconfig| 14 ++ configs/netspace_max_v2_defconfig | 14 ++ configs/netspace_mini_v2_defconfig| 12 configs/netspace_v2_defconfig | 13 + include/configs/lacie_kw.h| 19 +-- 19 files changed, 145 insertions(+), 48 deletions(-) create mode 100644 arch/arm/dts/kirkwood-d2net-u-boot.dtsi create mode 100644 arch/arm/dts/kirkwood-is2-u-boot.dtsi create mode 100644 arch/arm/dts/kirkwood-net2big-u-boot.dtsi create mode 100644 arch/arm/dts/kirkwood-ns2-u-boot.dtsi create mode 100644 arch/arm/dts/kirkwood-ns2lite-u-boot.dtsi create mode 100644 arch/arm/dts/kirkwood-ns2max-u-boot.dtsi create mode 100644 arch/arm/dts/kirkwood-ns2mini-u-boot.dtsi -- 2.27.0
Re: [PATCH 1/4] arm: kirkwood: convert LaCie boards to DM_SPI_FLASH
On Fri, Jun 26, 2020 at 03:40:51PM -0400, Tom Rini wrote: > On Thu, Jun 25, 2020 at 12:28:56AM +0200, Simon Guinot wrote: > > > This patch converts the following Kirkwood-based LaCie boards to DM, > > DM_SPI and DM_SPI_FLASH: > > > > - d2 Network v2 > > - Internet Space v2 > > - 2Big Network v2 > > - Network Space v2 > > - Network Space Lite v2 > > - Network Space Max v2 > > - Network Space Mini v2 > > > > Signed-off-by: Simon Guinot > > --- > > arch/arm/dts/kirkwood-netxbig.dtsi| 4 > > arch/arm/dts/kirkwood-ns2-common.dtsi | 4 > > These files come from the kernel and need to be kept in sync as-is with > the kernel. Both of these aliases should be easy to push upstream but > if not that's also why we have the -u-boot.dtsi auto-include mechanism > that keys off of CONFIG_SYS_SOC/CPU/VENDOR. The entire rest of the > series looks good, thanks for updating these platforms! OK I'll create the -u-boot.dtsi files to have the spi0 aliases right now. And in the meantime, I'll submit this change to Linux kernel. Thanks Simon signature.asc Description: PGP signature
Re: [PATCH v2] arm64: issue ISB after updating system registers
On Wed, Jun 24, 2020 at 11:07 AM Volodymyr Babchuk
wrote:
>
> ARM Architecture reference manual clearly states that PE pipeline
> should be flushed after any change to system registers. Refer to
> paragraph "B2.3.5 Memory Barriers" at page B2-92 of "Arm Architecture
> Reference Manual ARMv8 for ARMv8-A Architecture Profile" (ARM DDI
> 0487B.a).
>
> Failing to issue instruction memory synchronization barrier can lead
> to spurious errors, like synchronous exception when accessing FPU
> registers. This is very prominent on CPUs with long instruction
> pipeline, like ARM Cortex A72.
>
> This change fixes the following U-Boot panic:
>
> "Synchronous Abort" handler, esr 0x1fe0
> elr: 800948cc lr : 80091e04
> x0 : 801ffdc8 x1 : 00c8
> x2 : 800979d4 x3 : 801ffc60
> x4 : 801ffd40 x5 : ff80ffd8
> x6 : 801ffd70 x7 : 801ffd70
> x8 : 000a x9 :
> x10: 0044 x11:
> x12: x13:
> x14: x15:
> x16: 8008b2e0 x17:
> x18: 801ffec0 x19: 800957b0
> x20: 00c8 x21: 801ffdc8
> x22: 8009909e x23:
> x24: x25:
> x26: x27:
> x28: x29: 801ffc50
>
> Code: a94417e4 a90217e4 a9051fe6 a90617e4 (3d801fe0)
>
> While executing instruction
>
> str q0, [sp, #112]
>
> in vsnprintf() prologue. This panic was observed only on Cortex A72 so
> far.
>
> This patch places ISBs on other strategic places as well.
>
> Also, this probably is the right fix for the issue workarounded in the
> commit 45f41c13 ("ARM: uniphier: add weird workaround code for LD20")
Thanks for addressing this issue.
Currently, I do not have a board in hand to test this.
(I do not commute to the office due to COVID-19 these days...)
I have another SoC board, but it does not integrate CA72.
I have ever seen this problem only on CA72.
Eventually, I will go to the office, and I can test this.
But, you do not need to wait for my test if other people
review it.
Thank you.
> Reported-by: Oleksandr Andrushchenko
> Suggested-by: Julien Grall
> Signed-off-by: Volodymyr Babchuk
> CC: Tom Rini
> CC: Masahiro Yamada
> CC: Stefano Stabellini
>
> --
>
> Changes from v1:
> - Added ISBs under CONFIG_ARMV8_SET_SMPEN and erratas.
> - Added Stefano, Julien and Oleksandr
> ---
> arch/arm/cpu/armv8/start.S | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
> index 99d126660d..002698b501 100644
> --- a/arch/arm/cpu/armv8/start.S
> +++ b/arch/arm/cpu/armv8/start.S
> @@ -120,6 +120,7 @@ pie_fixup_done:
> mov x0, #3 << 20
> msr cpacr_el1, x0 /* Enable FP/SIMD */
> 0:
> + isb
>
> /*
> * Enable SMPEN bit for coherency.
> @@ -132,6 +133,7 @@ pie_fixup_done:
> mrs x0, S3_1_c15_c2_1 /* cpuectlr_el1 */
> orr x0, x0, #0x40
> msr S3_1_c15_c2_1, x0
> + isb
> 1:
> #endif
>
> @@ -233,6 +235,7 @@ apply_a53_core_errata:
> /* Enable data cache clean as data cache clean/invalidate */
> orr x0, x0, #1 << 44
> msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
> + isb
> #endif
> b 0b
>
> @@ -247,6 +250,7 @@ apply_a57_core_errata:
> /* Disable write streaming no-allocate threshold */
> orr x0, x0, #3 << 27
> msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
> + isb
> #endif
>
> #ifdef CONFIG_ARM_ERRATA_826974
> @@ -254,6 +258,7 @@ apply_a57_core_errata:
> /* Disable speculative load execution ahead of a DMB */
> orr x0, x0, #1 << 59
> msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
> + isb
> #endif
>
> #ifdef CONFIG_ARM_ERRATA_833471
> @@ -263,6 +268,7 @@ apply_a57_core_errata:
> could impact performance. */
> orr x0, x0, #1 << 38
> msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
> + isb
> #endif
>
> #ifdef CONFIG_ARM_ERRATA_829520
> @@ -273,6 +279,7 @@ apply_a57_core_errata:
> could impact performance. */
> orr x0, x0, #1 << 4
> msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
> + isb
> #endif
>
> #ifdef CONFIG_ARM_ERRATA_833069
> @@ -280,6 +287,7 @@ apply_a57_core_errata:
> /* Disable Enable Invalidates of BTB bit */
> and x0, x0, #0xE
> msr S3_1_c15_c2_0, x0 /* cpuactlr_el1 */
> + isb
> #endif
> b 0b
> ENDPROC(apply_core_errata)
> --
> 2.27.0
--
Best Regards
Masahiro Yamada
Re: [PATCH] video: rk_vop: Fix wrong bpix for frame buffer
On Wed, Jun 24, 2020 at 8:48 PM Jagan Teki wrote:
>
> Video framework would use plat size as a frame buffer
> pointer in rockchip video drivers.
>
> Typical frame buffer pointer would compute based on
> maximum resolutions supporting followed by bits per
> pixel value. Right now the value 4 (VIDEO_BPP16) is
> using on this computation even though the HDMI vop_id
> assigned as VIDEO_BPP32.
>
> This results below synchronous abort while clearing the
> frame buffer to the background color.
>
> "Synchronous Abort" handler, esr 0x9645
> elr: 00236ff0 lr : 00236f74 (reloc)
> elr: f6f6eff0 lr : f6f6ef74
> x0 : f800 x1 :
> x2 : f97a4000 x3 : ff1a
> x4 : ff1a x5 : 0035
> x6 : 000a x7 : f4f1fe50
> x8 : x9 : 0008
> x10: ffd8 x11: 0006
> x12: 0001869f x13: 5dc0
> x14: x15:
> x16: 0001 x17: 0032
> x18: f4f31dc0 x19: f4f47160
> x20: f6fb5814 x21: f4f1feb0
> x22: f6fea748 x23: f6fea748
> x24: f4f47108 x25: f4f47110
> x26: f4f46ed0 x27: f4f47118
> x28: 0002 x29: f4f1fe50
>
> Reproduced on,
> Board: roc-rk3399-pc
> Video Out: HDMI with 3480x2160 resolution.
>
> Fix this by using maximum bpix value which is VIDEO_BPP32
> to satisfy all vop_id connections.
>
> Reported-by: Da Xue
> Signed-off-by: Jagan Teki
> ---
> drivers/video/rockchip/rk_vop.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/rockchip/rk_vop.c b/drivers/video/rockchip/rk_vop.c
> index ff1a80384d..3bae22a5bc 100644
> --- a/drivers/video/rockchip/rk_vop.c
> +++ b/drivers/video/rockchip/rk_vop.c
> @@ -425,7 +425,7 @@ int rk_vop_bind(struct udevice *dev)
> {
> struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
>
> - plat->size = 4 * (CONFIG_VIDEO_ROCKCHIP_MAX_XRES *
> + plat->size = VIDEO_BPP32 * (CONFIG_VIDEO_ROCKCHIP_MAX_XRES *
> CONFIG_VIDEO_ROCKCHIP_MAX_YRES);
>
> return 0;
> --
> 2.25.1
>
Any comments on this fix? it needs to be in the release in order to
work 4K HDMI. I did tests lower than 4K resolution as well.
Jagan.
[PATCH v7 4/4] riscv: cpu: check and append L1 cache to cpu features
All cpu cores within FU540-C000 having split I/D caches. Set the L1 cache feature bit using the i-cache-size or d-cache-size as one of the property from device tree indicating that L1 cache is present on the cpu core. => cpu detail 1: cpu@1 rv64imafdc ID = 1, freq = 999.100 MHz: L1 cache, MMU 2: cpu@2 rv64imafdc ID = 2, freq = 999.100 MHz: L1 cache, MMU 3: cpu@3 rv64imafdc ID = 3, freq = 999.100 MHz: L1 cache, MMU 4: cpu@4 rv64imafdc ID = 4, freq = 999.100 MHz: L1 cache, MMU Signed-off-by: Sagar Shrikant Kadam Reviewed-by: Pragnesh Patel Reviewed-by: Bin Meng --- drivers/cpu/riscv_cpu.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c index 112690f..100fe55 100644 --- a/drivers/cpu/riscv_cpu.c +++ b/drivers/cpu/riscv_cpu.c @@ -35,6 +35,8 @@ static int riscv_cpu_get_info(struct udevice *dev, struct cpu_info *info) int ret; struct clk clk; const char *mmu; + u32 i_cache_size; + u32 d_cache_size; /* First try getting the frequency from the assigned clock */ ret = clk_get_by_index(dev, 0, ); @@ -52,6 +54,16 @@ static int riscv_cpu_get_info(struct udevice *dev, struct cpu_info *info) if (mmu) info->features |= BIT(CPU_FEAT_MMU); + /* check if I cache is present */ + ret = dev_read_u32(dev, "i-cache-size", _cache_size); + if (ret) + /* if not found check if d-cache is present */ + ret = dev_read_u32(dev, "d-cache-size", _cache_size); + + /* if either I or D cache is present set L1 cache feature */ + if (!ret) + info->features |= BIT(CPU_FEAT_L1_CACHE); + return 0; } -- 2.7.4
[PATCH v7 3/4] riscv: cpu: correctly handle the setting of CPU_FEAT_MMU bit
The conditional check to read "mmu-type" from the device tree
is not rightly handled due to which the cpu feature doesn't include
CPU_FEAT_MMU even if it's corresponding entry is present in the device
tree.
The initialization of cpu features is now taken care in cpu-uclass
driver, so no need to zero out cpu_freq in riscv_cpu driver and can be
removed.
Signed-off-by: Sagar Shrikant Kadam
Reviewed-by: Pragnesh Patel
Reviewed-by: Bin Meng
---
drivers/cpu/riscv_cpu.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
index 76b0489..112690f 100644
--- a/drivers/cpu/riscv_cpu.c
+++ b/drivers/cpu/riscv_cpu.c
@@ -36,9 +36,6 @@ static int riscv_cpu_get_info(struct udevice *dev, struct
cpu_info *info)
struct clk clk;
const char *mmu;
- /* Zero out the frequency, in case sizeof(ulong) != sizeof(u32) */
- info->cpu_freq = 0;
-
/* First try getting the frequency from the assigned clock */
ret = clk_get_by_index(dev, 0, );
if (!ret) {
@@ -52,7 +49,7 @@ static int riscv_cpu_get_info(struct udevice *dev, struct
cpu_info *info)
dev_read_u32(dev, "clock-frequency", (u32 *)>cpu_freq);
mmu = dev_read_string(dev, "mmu-type");
- if (!mmu)
+ if (mmu)
info->features |= BIT(CPU_FEAT_MMU);
return 0;
--
2.7.4
[PATCH v7 1/4] riscv: dts: hifive-unleashed-a00: add cpu aliases
Add cpu aliases to U-Boot specific dtsi for hifive-unleashed.
Without aliases we see that the CPU device sequence numbers are set
randomly and the cpu list/detail command will show it as follows:
=> cpu list
1: cpu@1 rv64imafdc
2: cpu@2 rv64imafdc
3: cpu@3 rv64imafdc
0: cpu@4 rv64imafdc
Seems like CPU probing with dm-model also relies on aliases as observed
in case spi. The fu540-c000-u-boot.dtsi has cpu nodes and so adding
corresponding aliases we can ensure that cpu devices are assigned
proper sequence as follows:
=> cpu list
1: cpu@1 rv64imafdc
2: cpu@2 rv64imafdc
3: cpu@3 rv64imafdc
4: cpu@4 rv64imafdc
Signed-off-by: Sagar Shrikant Kadam
Reviewed-by: Pragnesh Patel
Reviewed-by: Bin Meng
---
arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
index 3038064..e037150 100644
--- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
+++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
@@ -8,6 +8,10 @@
/ {
aliases {
+ cpu1 =
+ cpu2 =
+ cpu3 =
+ cpu4 =
spi0 =
spi2 =
};
--
2.7.4
[PATCH v7 2/4] uclass: cpu: fix to display proper CPU features
The cmd "cpu detail" fetches uninitialized cpu feature information and thus displays wrong / inconsitent details as below. For eg: FU540-C000 doesn't have any microcode, yet the cmd display's it. => cpu detail 1: cpu@1 rv64imafdc ID = 1, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID Microcode version 0x0 Device ID 0x0 2: cpu@2 rv64imafdc ID = 2, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID Microcode version 0x0 Device ID 0x0 3: cpu@3 rv64imafdc ID = 3, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID Microcode version 0x0 Device ID 0x0 4: cpu@4 rv64imafdc ID = 4, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID Microcode version 0x0 Device ID 0x0 The L1 cache or MMU entry seen above is also displayed inconsistently. So initialize cpu information to zero into cpu-uclass itself so that similar issues can be avoided for other CPU drivers. We now see correct features as: => cpu detail 1: cpu@1 rv64imafdc ID = 1, freq = 999.100 MHz 2: cpu@2 rv64imafdc ID = 2, freq = 999.100 MHz 3: cpu@3 rv64imafdc ID = 3, freq = 999.100 MHz 4: cpu@4 rv64imafdc ID = 4, freq = 999.100 MHz Signed-off-by: Sagar Shrikant Kadam Reviewed-by: Pragnesh Patel Reviewed-by: Bin Meng --- drivers/cpu/cpu-uclass.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c index 7418c26..cbb4419 100644 --- a/drivers/cpu/cpu-uclass.c +++ b/drivers/cpu/cpu-uclass.c @@ -86,6 +86,9 @@ int cpu_get_info(struct udevice *dev, struct cpu_info *info) if (!ops->get_info) return -ENOSYS; + /* Init cpu_info to 0 */ + memset(info, 0, sizeof(struct cpu_info)); + return ops->get_info(dev, info); } -- 2.7.4
[PATCH v7 0/4] update clock handler and proper cpu features
U-Boot cmd "cpu detail" shows inconsistent CPU features.
The current "cpu detail" sometimes shows "Microcode" as a feature, which
is not the case with FU540-C000 on HiFive Unleashed board.
Patch 1: add cpu node aliases.
Patch 2: Init CPU information to avoid inconsistent cpu information.
Patch 3: Correctly parse and update mmu-type.
Patch 4: Set L1 Cache feature if either i-cache or d-cache is present
I have picked few dependent patches from Sean's series from here [1]
and [2].
These have applied on mainline U-Boot commit eae62ae8de18 ("Merge tag
'efi-2020-07-rc6' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi;)
Patch history:
=
v7:
-Included the nits suggestion.
V6:
-Rebase series with master
-Split patch 2 from v5 as suggested i.e init cpu feature in cpu-class.c
as one patch and handle mmu-type check into another.
-Updated Reviewed-by tags
V5:
-Addressed review comments on v4.
1. Removed patch 1 which was for debug message.
2. Updated commit logs with proper information on number of cpu's
3. Additionally used d-cache to set the L1 feature bit.
V4:
1. Rebased the series to mainline commit.
2. Updated dependency list as few patches are now merged.
3. Added U-Boot log of the flow i.e fsbl + fw_payload.bin (Opensbi+U-Boot)
V3:
1. Included the cosmetic change as suggested
s/L1 feature/L1 cache feature/
2. Added Reviewed-By tags
V2:
1. Incorporate review comments from Bin and Sean Anderson.
and dropped 2nd patch as similar work was already done in [1] and [2]
2 Add cpu node aliases to display cpu node's in sequence.
3. Add fix to show mmu as available cpu feature.
4. Check and append L1 cache feature.
V1: Base version
Thanks to Vincent Chen for testing the V1
version of this series.
[1] https://patchwork.ozlabs.org/patch/1316066
[2] https://patchwork.ozlabs.org/patch/1316067
All these together is available here:
https://github.com/sagsifive/u-boot/commits/dev/sagark/clk-v7
U-Boot log:
===
U-Boot SPL 2020.07-rc5-00063-g213d48a (Jun 28 2020 - 07:19:43 -0700)
Trying to boot from MMC1
U-Boot 2020.07-rc5-00063-g213d48a (Jun 28 2020 - 07:19:43 -0700)
CPU: rv64imafdc
Model: SiFive HiFive Unleashed A00
DRAM: 8 GiB
MMC: spi@1005:mmc@0: 0
In:serial@1001
Out: serial@1001
Err: serial@1001
Net: eth0: ethernet@1009
Hit any key to stop autoboot: 0
=>
=> cpu list
1: cpu@1 rv64imafdc
2: cpu@2 rv64imafdc
3: cpu@3 rv64imafdc
4: cpu@4 rv64imafdc
=> cpu detail
1: cpu@1 rv64imafdc
ID = 1, freq = 999.100 MHz: L1 cache, MMU
2: cpu@2 rv64imafdc
ID = 2, freq = 999.100 MHz: L1 cache, MMU
3: cpu@3 rv64imafdc
ID = 3, freq = 999.100 MHz: L1 cache, MMU
4: cpu@4 rv64imafdc
ID = 4, freq = 999.100 MHz: L1 cache, MMU
=>
Sagar Shrikant Kadam (4):
riscv: dts: hifive-unleashed-a00: add cpu aliases
uclass: cpu: fix to display proper CPU features
riscv: cpu: correctly handle the setting of CPU_FEAT_MMU bit
riscv: cpu: check and append L1 cache to cpu features
arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4
drivers/cpu/cpu-uclass.c| 3 +++
drivers/cpu/riscv_cpu.c | 17 +
3 files changed, 20 insertions(+), 4 deletions(-)
--
2.7.4
Please pull u-boot-video
Hi Tom, please pull some fixes for v2020.07. Thanks! gitlab CI: https://gitlab.denx.de/u-boot/custodians/u-boot-video/pipelines/3806 The following changes since commit eae62ae8de1893f7cf08e276ab841d3f99245603: Merge tag 'efi-2020-07-rc6' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-25 13:33:15 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-video.git tags/fixes-for-v2020.07 for you to fetch changes up to bccb385a83a5f9ee603a30de1d39b03fd6f45b23: video: orisetech_otm8009a: fill characteristics of DSI data link (2020-06-28 01:28:03 +0200) - fix logo on mx6ul_14x14_evk with DM_VIDEO enabled - fix banner string overwriting the logo on small displays - fix splash warning when building for ARM64 - fix STM32 DSI driver to probe only on supported hardware - fix memory corruption with DSI panel drivers Yannick Fertre (5): video: check hardware version of DSI video: mipi update panel platform data video: stm32: stm32_dsi: copy DSI fields video: raydium_rm68200: fill characteristics of DSI data link video: orisetech_otm8009a: fill characteristics of DSI data link Ye Li (3): video: bmp: support 8bits BMP drawing on 24/32 bpp framebuffer video: vidconsole: avoid multiple lines overwrite logo splash: Fix build warning on 64 bits CPU common/splash.c| 2 +- drivers/video/orisetech_otm8009a.c | 20 +--- drivers/video/raydium-rm68200.c| 20 +--- drivers/video/stm32/stm32_dsi.c| 13 - drivers/video/vidconsole-uclass.c | 1 + drivers/video/video_bmp.c | 27 +-- include/mipi_dsi.h | 6 ++ 7 files changed, 51 insertions(+), 38 deletions(-)
Re: [PATCH v2] test/py: test_efi_fit: Update #size-cells to 1
On 6/28/20 3:03 AM, Bin Meng wrote:
> From: Bin Meng
>
> test_efi_fit tests fail on RISC-V currently. This is due to the
> RISC-V arch_fixup_fdt() checks the #size-cells of the root node
> in order to correctly fix up the reserved memory node.
>
> Per the DT binding, the /reserved-memory node requires both
> <#address-cells> and <#size-cells> and they should use the same
> values as the root node. For the root node, it's not very useful
> if <#size-cells> is zero.
The text you refer to is Linux's
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Will you also fix the underlying problem that the /reserved-memory node
does not provide its own #address-cells, #size-cells?
>
> Update #size-cells to 1 so tests can pass.
>
> Signed-off-by: Bin Meng
> ---
>
> Changes in v2:
> - Update the reset node's property to contain a size
>
> test/py/tests/test_efi_fit.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/test/py/tests/test_efi_fit.py b/test/py/tests/test_efi_fit.py
> index beaf4a3..06fb151 100644
> --- a/test/py/tests/test_efi_fit.py
> +++ b/test/py/tests/test_efi_fit.py
> @@ -106,14 +106,14 @@ FDT_DATA = '''
>
> / {
> #address-cells = <1>;
> -#size-cells = <0>;
> +#size-cells = <1>;
>
> model = "%(sys-arch)s %(fdt_type)s EFI FIT Boot Test";
> compatible = "%(sys-arch)s";
>
> reset@0 {
> compatible = "%(sys-arch)s,reset";
> -reg = <0>;
> +reg = <0 4>;
This reg property is not used by any driver. I think it was only added
to avoid a dtc warning.
Reviewed-by: Heinrich Schuchardt
> };
> };
> '''
>
Pull request: u-boot-rockchip-20200628
Hi Tom, Please pull the rockchip updates/fixes: - rk3188 cpu init and APLL fix; - rk3399: Add BOOTENV_SF command; - rk3288 correct vop0 vop1 setting; Gitlab ci: https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3807 Thanks, - Kever The following changes since commit eae62ae8de1893f7cf08e276ab841d3f99245603: Merge tag 'efi-2020-07-rc6' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2020-06-25 13:33:15 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git tags/u-boot-rockchip-20200628 for you to fetch changes up to 673eb44e91bc0c06cb1e3f353f5d07b4f9e5a586: rockchip: correctly set vop0 or vop1 (2020-06-28 09:56:11 +0800) Alexander Kochetkov (2): rockchip: rk3188: Fix back to BROM boot rockchip: clk: rk3188: change APLL to safe 600MHz Jagan Teki (1): rk3399: Add BOOTENV_SF command Patrick Wildt (1): rockchip: correctly set vop0 or vop1 arch/arm/mach-rockchip/rk3188/rk3188.c | 21 +++-- drivers/clk/rockchip/clk_rk3188.c | 3 ++- drivers/video/rockchip/rk_edp.c| 3 ++- include/configs/rk3399_common.h| 1 + 4 files changed, 24 insertions(+), 4 deletions(-)
[PATCH] gitlab: add pycrypto for arm64
pycrypto is needed for script to generate correct its.
Signed-off-by: Kever Yang
---
.gitlab-ci.yml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index f2e491c117..4841e7afbe 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -67,7 +67,7 @@ build all 64bit ARM platforms:
script:
- virtualenv -p /usr/bin/python3 /tmp/venv
- . /tmp/venv/bin/activate
-- pip install pyelftools
+- pip install pyelftools pycrypto
- ret=0;
./tools/buildman/buildman -o /tmp -P -E -W aarch64 || ret=$?;
if [[ $ret -ne 0 ]]; then
@@ -159,7 +159,7 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
export USER=gitlab;
virtualenv -p /usr/bin/python3 /tmp/venv;
. /tmp/venv/bin/activate;
- pip install pyelftools pytest;
+ pip install pyelftools pytest pycrypto;
export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl;
export PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt";
export PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}";
--
2.17.1
Re: [PATCH v3 10/35] acpi: Support generation of a GPIO/irq for a device
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > Some devices use interrupts but some use GPIOs. Since these are fully > specified in the device tree we can automatically produce the correct ACPI > descriptor for a device. > > Add a function to handle this. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > Changes in v3: > - Fix 'an GPIO is found' typo > > include/acpi/acpi_device.h | 15 ++ > lib/acpi/acpi_device.c | 26 > test/dm/acpigen.c | 41 ++ > 3 files changed, 82 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v3 08/35] acpi: Support string output
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add support for output of strings and streams of bytes.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpigen.h | 19 +++
> lib/acpi/acpigen.c | 14 ++
> test/dm/acpigen.c | 42 ++
> 3 files changed, 75 insertions(+)
>
> diff --git a/include/acpi/acpigen.h b/include/acpi/acpigen.h
> index 8809cdb4e1..7365cce738 100644
> --- a/include/acpi/acpigen.h
> +++ b/include/acpi/acpigen.h
> @@ -46,4 +46,23 @@ void acpigen_emit_word(struct acpi_ctx *ctx, uint data);
> */
> void acpigen_emit_dword(struct acpi_ctx *ctx, uint data);
>
> +/**
> + * acpigen_emit_stream() - Emit a stream of bytes
> + *
> + * @ctx: ACPI context pointer
> + * @data: Data to output
> + * @size: Size of data in bytes
> + */
> +void acpigen_emit_stream(struct acpi_ctx *ctx, const char *data, int size);
> +
> +/**
> + * acpigen_emit_string() - Emit a string
> + *
> + * Emit a string with a nul terminator
nits: null
> + *
> + * @ctx: ACPI context pointer
> + * @str: String to output, or NULL for an empty string
> + */
> +void acpigen_emit_string(struct acpi_ctx *ctx, const char *str);
> +
> #endif
> diff --git a/lib/acpi/acpigen.c b/lib/acpi/acpigen.c
> index 59bd3af0b7..1223f0d1c4 100644
> --- a/lib/acpi/acpigen.c
> +++ b/lib/acpi/acpigen.c
> @@ -36,3 +36,17 @@ void acpigen_emit_dword(struct acpi_ctx *ctx, uint data)
> acpigen_emit_byte(ctx, (data >> 16) & 0xff);
> acpigen_emit_byte(ctx, (data >> 24) & 0xff);
> }
> +
> +void acpigen_emit_stream(struct acpi_ctx *ctx, const char *data, int size)
> +{
> + int i;
> +
> + for (i = 0; i < size; i++)
> + acpigen_emit_byte(ctx, data[i]);
> +}
> +
> +void acpigen_emit_string(struct acpi_ctx *ctx, const char *str)
> +{
> + acpigen_emit_stream(ctx, str, str ? strlen(str) : 0);
> + acpigen_emit_byte(ctx, '\0'); /* NUL */
nits: NULL
> +}
> diff --git a/test/dm/acpigen.c b/test/dm/acpigen.c
> index 4ee5c9cfe2..fac9886f2e 100644
> --- a/test/dm/acpigen.c
> +++ b/test/dm/acpigen.c
> @@ -17,6 +17,9 @@
> #include
> #include
>
> +#define TEST_STRING"frogmore"
> +#define TEST_STREAM2 "\xfa\xde"
> +
> static int alloc_context(struct acpi_ctx **ctxp)
> {
> struct acpi_ctx *ctx;
> @@ -70,6 +73,45 @@ static int dm_test_acpi_emit_simple(struct unit_test_state
> *uts)
> }
> DM_TEST(dm_test_acpi_emit_simple, 0);
>
> +/* Test emitting a stream */
> +static int dm_test_acpi_emit_stream(struct unit_test_state *uts)
> +{
> + struct acpi_ctx *ctx;
> + u8 *ptr;
> +
> + ut_assertok(alloc_context());
> +
> + ptr = acpigen_get_current(ctx);
> + acpigen_emit_stream(ctx, TEST_STREAM2, 2);
> + ut_asserteq(2, acpigen_get_current(ctx) - ptr);
> + ut_asserteq((u8)TEST_STREAM2[0], ptr[0]);
> + ut_asserteq((u8)TEST_STREAM2[1], ptr[1]);
> +
> + free_context();
> +
> + return 0;
> +}
> +DM_TEST(dm_test_acpi_emit_stream, 0);
> +
> +/* Test emitting a string */
> +static int dm_test_acpi_emit_string(struct unit_test_state *uts)
> +{
> + struct acpi_ctx *ctx;
> + u8 *ptr;
> +
> + ut_assertok(alloc_context());
> +
> + ptr = acpigen_get_current(ctx);
> + acpigen_emit_string(ctx, TEST_STRING);
> + ut_asserteq(sizeof(TEST_STRING), acpigen_get_current(ctx) - ptr);
> + ut_asserteq_str(TEST_STRING, (char *)ptr);
> +
> + free_context();
> +
> + return 0;
> +}
> +DM_TEST(dm_test_acpi_emit_string, 0);
> +
> /* Test emitting an interrupt descriptor */
> static int dm_test_acpi_interrupt(struct unit_test_state *uts)
> {
> --
Other than that,
Reviewed-by: Bin Meng
Regards,
Bin
Re: [PATCH v3 06/35] acpi: Support generation of interrupt descriptor
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a function to write an interrupt descriptor to the generated ACPI
> code.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpi_device.h | 15 +
> lib/acpi/acpi_device.c | 118 +
> test/dm/acpigen.c | 31 ++
> 3 files changed, 164 insertions(+)
>
> diff --git a/include/acpi/acpi_device.h b/include/acpi/acpi_device.h
> index 24895de0da..4f87cd003a 100644
> --- a/include/acpi/acpi_device.h
> +++ b/include/acpi/acpi_device.h
> @@ -11,6 +11,8 @@
>
> #include
>
> +struct acpi_ctx;
> +struct irq;
> struct udevice;
>
> /* ACPI descriptor values for common descriptors: SERIAL_BUS means I2C */
> @@ -128,4 +130,17 @@ int acpi_device_scope(const struct udevice *dev, char
> *scope, int maxlen);
> */
> enum acpi_dev_status acpi_device_status(const struct udevice *dev);
>
> +/**
> + * acpi_device_write_interrupt_irq() - Write an interrupt descriptor
> + *
> + * This writes an ACPI interrupt descriptor for the given interrupt,
> converting
> + * fields as needed.
> + *
> + * @ctx: ACPI context pointer
> + * @req_irq: Interrupt to output
> + * @return 0 if OK, -ve on error
> + */
> +int acpi_device_write_interrupt_irq(struct acpi_ctx *ctx,
> + const struct irq *req_irq);
> +
> #endif
> diff --git a/lib/acpi/acpi_device.c b/lib/acpi/acpi_device.c
> index 60f4fd8cd5..94f37b8d73 100644
> --- a/lib/acpi/acpi_device.c
> +++ b/lib/acpi/acpi_device.c
> @@ -8,8 +8,10 @@
>
> #include
> #include
> +#include
> #include
> #include
> +#include
> #include
>
> /**
> @@ -86,3 +88,119 @@ enum acpi_dev_status acpi_device_status(const struct
> udevice *dev)
> {
> return ACPI_DSTATUS_ALL_ON;
> }
> +
> +/**
> + * acpi_device_write_zero_len() - Write a placeholder word value
> + *
> + * @return pointer to the zero word (for fixing up later)
This function name seems to be generic. Are all lengths in various
ACPI objects following the same 2 bytes convention to represent
length?
Per the ACPI spec, this seems to only apply to Large Resource Data
Type, so we should probably rename this API to reflect this.
> + */
> +static void *acpi_device_write_zero_len(struct acpi_ctx *ctx)
> +{
> + u8 *p = acpigen_get_current(ctx);
> +
> + acpigen_emit_word(ctx, 0);
> +
> + return p;
> +}
> +
> +/**
> + * acpi_device_fill_from_len() - Fill in a length value
> + *
> + * This calculated the number of bytes since the provided @start and writes
> it
> + * to @ptr, which was previous returned by acpi_device_write_zero_len().
> + *
> + * @ptr: Word to update
> + * @start: Start address to count from to calculated the length
> + */
> +static void acpi_device_fill_from_len(struct acpi_ctx *ctx, char *ptr,
> + u8 *start)
> +{
> + u16 len = acpigen_get_current(ctx) - start;
> +
> + ptr[0] = len & 0xff;
> + ptr[1] = (len >> 8) & 0xff;
> +}
> +
> +/**
> + * acpi_device_fill_len() - Fill in a length value, excluding the length
> itself
> + *
> + * Fill in the length field with the value calculated from after the 16bit
> + * field to acpigen current. This is useful since the length value does not
> + * include the length field itself.
> + *
> + * This calls acpi_device_fill_from_len() passing @ptr + 2 as @start
> + *
> + * @ptr: Word to update.
> + */
> +static void acpi_device_fill_len(struct acpi_ctx *ctx, void *ptr)
> +{
> + acpi_device_fill_from_len(ctx, ptr, ptr + sizeof(u16));
> +}
> +
> +/* ACPI 6.3 section 6.4.3.6: Extended Interrupt Descriptor */
> +static int acpi_device_write_interrupt(struct acpi_ctx *ctx,
> + const struct acpi_irq *irq)
> +{
> + void *desc_length;
> + u8 flags;
> +
> + if (!irq->pin)
> + return -ENOENT;
> +
> + /* This is supported by GpioInt() but not Interrupt() */
> + if (irq->polarity == ACPI_IRQ_ACTIVE_BOTH)
> + return -EINVAL;
> +
> + /* Byte 0: Descriptor Type */
> + acpigen_emit_byte(ctx, ACPI_DESCRIPTOR_INTERRUPT);
> +
> + /* Byte 1-2: Length (filled in later) */
> + desc_length = acpi_device_write_zero_len(ctx);
> +
> + /*
> +* Byte 3: Flags
> +* [7:5]: Reserved
> +*[4]: Wake (0=NO_WAKE 1=WAKE)
> +*[3]: Sharing (0=EXCLUSIVE 1=SHARED)
> +*[2]: Polarity (0=HIGH 1=LOW)
> +*[1]: Mode (0=LEVEL 1=EDGE)
> +*[0]: Resource (0=PRODUCER 1=CONSUMER)
> +*/
> + flags = BIT(0); /* ResourceConsumer */
> + if (irq->mode == ACPI_IRQ_EDGE_TRIGGERED)
> + flags |= BIT(1);
> + if (irq->polarity == ACPI_IRQ_ACTIVE_LOW)
> + flags |= BIT(2);
> + if (irq->shared == ACPI_IRQ_SHARED)
> + flags |= BIT(3);
> + if
Re: [PATCH v3 07/35] gpio: Add a method to convert a GPIO to ACPI
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> When generating ACPI tables we need to convert GPIOs in U-Boot to the ACPI
> structures required by ACPI. This is a SoC-specific conversion and cannot
> be handled by generic code, so add a new GPIO method to do the conversion.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> Changes in v1:
> - Update sandbox driver slightly for testing
>
> drivers/gpio/gpio-uclass.c | 21 +
> drivers/gpio/sandbox.c | 86
> include/acpi/acpi_device.h | 90 ++
> include/asm-generic/gpio.h | 27
> test/dm/gpio.c | 62 ++
> test/dm/irq.c | 1 +
> 6 files changed, 287 insertions(+)
>
> diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
> index 9eeab22eef..e2f4d7e02c 100644
> --- a/drivers/gpio/gpio-uclass.c
> +++ b/drivers/gpio/gpio-uclass.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -809,6 +810,26 @@ int gpio_get_status(struct udevice *dev, int offset,
> char *buf, int buffsize)
> return 0;
> }
>
> +#if CONFIG_IS_ENABLED(ACPIGEN)
> +int gpio_get_acpi(const struct gpio_desc *desc, struct acpi_gpio *gpio)
> +{
> + struct dm_gpio_ops *ops;
> +
> + if (!dm_gpio_is_valid(desc)) {
> + /* Indicate that the GPIO is not valid */
> + gpio->pin_count = 0;
> + gpio->pins[0] = 0;
> + return -EINVAL;
> + }
> +
Let's do memset() to gpio so that GPIO driver doesn't need to clear by
themselves, to avoid potential issues.
> + ops = gpio_get_ops(desc->dev);
> + if (!ops->get_acpi)
> + return -ENOSYS;
> +
> + return ops->get_acpi(desc, gpio);
> +}
> +#endif
> +
> int gpio_claim_vector(const int *gpio_num_array, const char *fmt)
> {
> int i, ret;
> diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
> index 98b7fa4bb3..6cd2a1455a 100644
> --- a/drivers/gpio/sandbox.c
> +++ b/drivers/gpio/sandbox.c
> @@ -8,7 +8,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -197,6 +199,72 @@ static int sb_gpio_get_dir_flags(struct udevice *dev,
> unsigned int offset,
> return 0;
> }
>
> +#if CONFIG_IS_ENABLED(ACPIGEN)
> +static int sb_gpio_get_acpi(const struct gpio_desc *desc,
> + struct acpi_gpio *gpio)
> +{
> + int ret;
> +
> + /* All of these values are just used for testing */
> + if (desc->flags & GPIOD_ACTIVE_LOW) {
> + gpio->pin_count = 1;
> + gpio->pins[0] = desc->offset;
> + gpio->pin0_addr = 0x80012 + desc->offset;
> + gpio->type = ACPI_GPIO_TYPE_INTERRUPT;
> + gpio->pull = ACPI_GPIO_PULL_DOWN;
> + ret = acpi_device_scope(desc->dev, gpio->resource,
> + sizeof(gpio->resource));
> + if (ret)
> + return log_ret(ret);
> + gpio->interrupt_debounce_timeout = 4321;
> + memset(>irq, '\0', sizeof(gpio->irq));
> +
> + /* We use the GpioInt part */
> + gpio->irq.pin = desc->offset;
> + gpio->irq.polarity = ACPI_IRQ_ACTIVE_BOTH;
> + gpio->irq.shared = ACPI_IRQ_SHARED;
> + gpio->irq.wake = ACPI_IRQ_WAKE;
> +
> + /* The GpioIo part is not used */
> + gpio->output_drive_strength = 0;
> + gpio->io_shared = false;
> + gpio->io_restrict = 0;
> + gpio->polarity = ACPI_GPIO_ACTIVE_LOW;
> + } else {
> + gpio->pin_count = 1;
> + gpio->pins[0] = desc->offset;
> + gpio->pin0_addr = 0xc00dc + desc->offset;
> + gpio->type = ACPI_GPIO_TYPE_IO;
> + gpio->pull = ACPI_GPIO_PULL_UP;
> + ret = acpi_device_scope(desc->dev, gpio->resource,
> + sizeof(gpio->resource));
> + if (ret)
> + return log_ret(ret);
> + gpio->interrupt_debounce_timeout = 0;
> +
> + /* The GpioInt part is not used */
> + memset(>irq, '\0', sizeof(gpio->irq));
> +
> + /* We use the GpioIo part */
> + gpio->output_drive_strength = 1234;
> + gpio->io_shared = true;
> + gpio->io_restrict = ACPI_GPIO_IO_RESTRICT_INPUT;
> + gpio->polarity = 0;
> + }
Could we refactor the logic a little bit, such that the common part is
put outside the if () else () logic, and only different part is put
into the if () or else () part.
> +
> + return 0;
> +}
> +
> +static int sb_gpio_get_name(const struct udevice
Re: [PATCH v3 09/35] acpi: Support generation of GPIO descriptor
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a function to write a GPIO descriptor to the generated ACPI code.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/acpi/acpi_device.h | 22 ++
> lib/acpi/acpi_device.c | 151 +
> test/dm/acpigen.c | 89 ++
> 3 files changed, 262 insertions(+)
>
> diff --git a/include/acpi/acpi_device.h b/include/acpi/acpi_device.h
> index cb9166aeae..5f229d79cf 100644
> --- a/include/acpi/acpi_device.h
> +++ b/include/acpi/acpi_device.h
> @@ -12,6 +12,7 @@
> #include
>
> struct acpi_ctx;
> +struct gpio_desc;
> struct irq;
> struct udevice;
>
> @@ -233,4 +234,25 @@ enum acpi_dev_status acpi_device_status(const struct
> udevice *dev);
> int acpi_device_write_interrupt_irq(struct acpi_ctx *ctx,
> const struct irq *req_irq);
>
> +/**
> + * acpi_device_write_gpio() - Write GpioIo() or GpioInt() descriptor
> + *
> + * @gpio: GPIO information to write
> + * @return 0 if OK, -ve on error
> + */
> +int acpi_device_write_gpio(struct acpi_ctx *ctx, const struct acpi_gpio
> *gpio);
> +
> +/**
> + * acpi_device_write_gpio_desc() - Write a GPIO to ACPI
> + *
> + * This creates a GPIO descriptor for a GPIO, including information ACPI
> needs
> + * to use it. The type is always ACPI_GPIO_TYPE_IO.
Why is the type always ACPI_GPIO_TYPE_IO? Is gpio_get_acpi() supposed
to hard code gpio->type to ACPI_GPIO_TYPE_IO?
> + *
> + * @ctx: ACPI context pointer
> + * @desc: GPIO to write
> + * @return 0 if OK, -ve on error
> + */
> +int acpi_device_write_gpio_desc(struct acpi_ctx *ctx,
> + const struct gpio_desc *desc);
> +
> #endif
> diff --git a/lib/acpi/acpi_device.c b/lib/acpi/acpi_device.c
> index 94f37b8d73..1cc7dd8b37 100644
> --- a/lib/acpi/acpi_device.c
> +++ b/lib/acpi/acpi_device.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /**
> @@ -204,3 +205,153 @@ int acpi_device_write_interrupt_irq(struct acpi_ctx
> *ctx,
>
> return 0;
> }
> +
> +/* ACPI 6.3 section 6.4.3.8.1 - GPIO Interrupt or I/O */
> +int acpi_device_write_gpio(struct acpi_ctx *ctx, const struct acpi_gpio
> *gpio)
> +{
> + void *start, *desc_length;
> + void *pin_table_offset, *vendor_data_offset, *resource_offset;
> + u16 flags = 0;
> + int pin;
> +
> + if (gpio->type > ACPI_GPIO_TYPE_IO)
> + return -EINVAL;
> +
> + start = acpigen_get_current(ctx);
> +
> + /* Byte 0: Descriptor Type */
> + acpigen_emit_byte(ctx, ACPI_DESCRIPTOR_GPIO);
> +
> + /* Byte 1-2: Length (fill in later) */
> + desc_length = acpi_device_write_zero_len(ctx);
> +
> + /* Byte 3: Revision ID */
> + acpigen_emit_byte(ctx, ACPI_GPIO_REVISION_ID);
> +
> + /* Byte 4: GpioIo or GpioInt */
> + acpigen_emit_byte(ctx, gpio->type);
> +
> + /*
> +* Byte 5-6: General Flags
> +* [15:1]: 0 => Reserved
> +* [0]: 1 => ResourceConsumer
> +*/
> + acpigen_emit_word(ctx, 1 << 0);
> +
> + switch (gpio->type) {
> + case ACPI_GPIO_TYPE_INTERRUPT:
> + /*
> +* Byte 7-8: GPIO Interrupt Flags
> +* [15:5]: 0 => Reserved
> +* [4]: Wake (0=NO_WAKE 1=WAKE)
> +* [3]: Sharing (0=EXCLUSIVE 1=SHARED)
> +*[2:1]: Polarity (0=HIGH 1=LOW 2=BOTH)
> +* [0]: Mode (0=LEVEL 1=EDGE)
> +*/
> + if (gpio->irq.mode == ACPI_IRQ_EDGE_TRIGGERED)
> + flags |= 1 << 0;
> + if (gpio->irq.shared == ACPI_IRQ_SHARED)
> + flags |= 1 << 3;
> + if (gpio->irq.wake == ACPI_IRQ_WAKE)
> + flags |= 1 << 4;
> +
> + switch (gpio->irq.polarity) {
> + case ACPI_IRQ_ACTIVE_HIGH:
> + flags |= 0 << 1;
> + break;
> + case ACPI_IRQ_ACTIVE_LOW:
> + flags |= 1 << 1;
> + break;
> + case ACPI_IRQ_ACTIVE_BOTH:
> + flags |= 2 << 1;
> + break;
> + }
> + break;
> +
> + case ACPI_GPIO_TYPE_IO:
> + /*
> +* Byte 7-8: GPIO IO Flags
> +* [15:4]: 0 => Reserved
> +* [3]: Sharing (0=EXCLUSIVE 1=SHARED)
> +* [2]: 0 => Reserved
> +*[1:0]: IO Restriction
> +* 0 => IoRestrictionNone
> +* 1 => IoRestrictionInputOnly
> +* 2 => IoRestrictionOutputOnly
> +* 3 => IoRestrictionNoneAndPreserve
> +
Re: [PATCH v3 04/35] irq: Add a method to convert an interrupt to ACPI
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > When generating ACPI tables we need to convert IRQs in U-Boot to the ACPI > structures required by ACPI. This is a SoC-specific conversion and cannot > be handled by generic code, so add a new IRQ method to do the conversion. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > Changes in v1: > - Fix 'the an' typo > - Move header definitions into this patch > > drivers/misc/irq-uclass.c | 18 ++-- > drivers/misc/irq_sandbox.c | 16 +++ > include/acpi/acpi_device.h | 59 ++ > include/irq.h | 43 +++ > test/dm/irq.c | 22 ++ > 5 files changed, 156 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v3 05/35] acpi: Support generation of ACPI code
Hi Simon,
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote:
>
> Add a new file to handle generating ACPI code programatically. This is
> used when information must be dynamically added to the tables, e.g. the
> SSDT.
>
> Initial support is just for writing simple values. Also add a 'base' value
> so that the table can be freed. This likely doesn't happen in normal code,
> but is nice to do in tests.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Update to add a new 'base' field to struct acpi_ctx
> - Free the memory allocated to the table and context
>
> include/acpi/acpigen.h | 49 ++
> include/dm/acpi.h | 2 ++
> lib/acpi/Makefile | 1 +
> lib/acpi/acpi_table.c | 1 +
> lib/acpi/acpigen.c | 38 +++
> test/dm/Makefile | 1 +
> test/dm/acpigen.c | 69 ++
> 7 files changed, 161 insertions(+)
> create mode 100644 include/acpi/acpigen.h
> create mode 100644 lib/acpi/acpigen.c
> create mode 100644 test/dm/acpigen.c
>
> diff --git a/include/acpi/acpigen.h b/include/acpi/acpigen.h
> new file mode 100644
> index 00..8809cdb4e1
> --- /dev/null
> +++ b/include/acpi/acpigen.h
> @@ -0,0 +1,49 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Core ACPI (Advanced Configuration and Power Interface) support
> + *
> + * Copyright 2019 Google LLC
> + *
> + * Modified from coreboot file acpigen.h
> + */
> +
> +#ifndef __ACPI_ACPIGEN_H
> +#define __ACPI_ACPIGEN_H
> +
> +#include
> +
> +struct acpi_ctx;
> +
> +/**
> + * acpigen_get_current() - Get the current ACPI code output pointer
> + *
> + * @ctx: ACPI context pointer
> + * @return output pointer
> + */
> +u8 *acpigen_get_current(struct acpi_ctx *ctx);
> +
> +/**
> + * acpigen_emit_byte() - Emit a byte to the ACPI code
> + *
> + * @ctx: ACPI context pointer
> + * @data: Value to output
> + */
> +void acpigen_emit_byte(struct acpi_ctx *ctx, uint data);
> +
> +/**
> + * acpigen_emit_word() - Emit a 16-bit word to the ACPI code
> + *
> + * @ctx: ACPI context pointer
> + * @data: Value to output
> + */
> +void acpigen_emit_word(struct acpi_ctx *ctx, uint data);
> +
> +/**
> + * acpigen_emit_dword() - Emit a 32-bit 'double word' to the ACPI code
> + *
> + * @ctx: ACPI context pointer
> + * @data: Value to output
> + */
> +void acpigen_emit_dword(struct acpi_ctx *ctx, uint data);
> +
> +#endif
> diff --git a/include/dm/acpi.h b/include/dm/acpi.h
> index 7563a4c60a..696b1a96a0 100644
> --- a/include/dm/acpi.h
> +++ b/include/dm/acpi.h
> @@ -29,6 +29,7 @@
> *
> * This contains a few useful pieces of information used when writing
> *
> + * @base: Base address of ACPI tables
> * @current: Current address for writing
> * @rsdp: Pointer to the Root System Description Pointer, typically used when
> * adding a new table. The RSDP holds pointers to the RSDT and XSDT.
> @@ -36,6 +37,7 @@
> * @xsdt: Pointer to the Extended System Description Table
> */
> struct acpi_ctx {
> + void *base;
> void *current;
> struct acpi_rsdp *rsdp;
> struct acpi_rsdt *rsdt;
> diff --git a/lib/acpi/Makefile b/lib/acpi/Makefile
> index caae6c01bd..85a1f774ad 100644
> --- a/lib/acpi/Makefile
> +++ b/lib/acpi/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0+
> #
>
> +obj-y += acpigen.o
> obj-y += acpi_device.o
> obj-y += acpi_table.o
> diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
> index 43177e..17d5258438 100644
> --- a/lib/acpi/acpi_table.c
> +++ b/lib/acpi/acpi_table.c
> @@ -238,6 +238,7 @@ static void acpi_write_xsdt(struct acpi_xsdt *xsdt)
> void acpi_setup_base_tables(struct acpi_ctx *ctx, void *start)
> {
> ctx->current = start;
> + ctx->current = start;
This seems to be unnecessary.
>
> /* Align ACPI tables to 16 byte */
> acpi_align(ctx);
> diff --git a/lib/acpi/acpigen.c b/lib/acpi/acpigen.c
> new file mode 100644
> index 00..59bd3af0b7
> --- /dev/null
> +++ b/lib/acpi/acpigen.c
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Generation of ACPI (Advanced Configuration and Power Interface) tables
> + *
> + * Copyright 2019 Google LLC
> + * Mostly taken from coreboot
> + */
> +
> +#define LOG_CATEGORY LOGC_ACPI
> +
> +#include
> +#include
> +#include
> +#include
> +
> +u8 *acpigen_get_current(struct acpi_ctx *ctx)
> +{
> + return ctx->current;
> +}
> +
> +void acpigen_emit_byte(struct acpi_ctx *ctx, uint data)
> +{
> + *(u8 *)ctx->current++ = data;
> +}
> +
> +void acpigen_emit_word(struct acpi_ctx *ctx, uint data)
> +{
> + acpigen_emit_byte(ctx, data & 0xff);
> + acpigen_emit_byte(ctx, (data >> 8) & 0xff);
> +}
> +
> +void acpigen_emit_dword(struct acpi_ctx *ctx, uint data)
> +{
> + acpigen_emit_byte(ctx, data & 0xff);
> + acpigen_emit_byte(ctx, (data >> 8) & 0xff);
> + acpigen_emit_byte(ctx, (data >> 16) & 0xff);
> +
Re: [PATCH v3 03/35] acpi: Add a way to check device status
On Sun, Jun 14, 2020 at 10:55 AM Simon Glass wrote: > > At present U-Boot does not support the different ACPI status values, but > it is best to put this logic in a central place. Add a function to get the > device status. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > include/acpi/acpi_device.h | 28 > lib/acpi/acpi_device.c | 5 + > test/dm/acpi.c | 12 > 3 files changed, 45 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH v2 23/25] x86: mtrr: Update 'mtrr' to allow setting MTRRs on any CPU
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> Add a -c option to mtrr to allow any CPU to be updated with this command.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> cmd/x86/mtrr.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/x86/mtrr.c b/cmd/x86/mtrr.c
> index b51b1cd7e2..d88a875d92 100644
> --- a/cmd/x86/mtrr.c
> +++ b/cmd/x86/mtrr.c
> @@ -104,6 +104,17 @@ static int do_mtrr(struct cmd_tbl *cmdtp, int flag, int
> argc,
> int ret;
>
> cpu_select = MP_SELECT_BSP;
> + if (argc >= 3 && !strcmp("-c", argv[1])) {
> + const char *cpustr;
> +
> + cpustr = argv[2];
> + if (*cpustr == 'a')
> + cpu_select = MP_SELECT_ALL;
> + else
> + cpu_select = simple_strtol(cpustr, NULL, 16);
> + argc -= 2;
> + argv += 2;
> + }
> argc--;
> argv++;
> cmd = argv[0] ? *argv[0] : 0;
> @@ -145,11 +156,14 @@ static int do_mtrr(struct cmd_tbl *cmdtp, int flag, int
> argc,
> }
>
> U_BOOT_CMD(
> - mtrr, 6, 1, do_mtrr,
> + mtrr, 8, 1, do_mtrr,
> "Use x86 memory type range registers (32-bit only)",
> "[list]- list current registers\n"
> "set - set a register\n"
> "\t is Uncacheable, Combine, Through, Protect, Back\n"
> "disable - disable a register\n"
> - "enable- enable a register"
> + "enable- enable a register\n"
> + "\n"
> + "Precede command with '-c |all' to access a particular CPU, e.g.\n"
> + " mtrr -c all list; mtrr -c 2e list"
nits: better to mention cpu number is interpreted as a hex number
> );
> --
Reviewed-by: Bin Meng
Re: [PATCH v2 22/25] x86: mtrr: Restructure so command execution is in one place
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > At present do_mtrr() does the 'list' subcommand at the top and the rest > below. Update it to do them all in the same place so we can (in a later > patch) add parsing of the CPU number for all subcommands. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > (no changes since v1) > > cmd/x86/mtrr.c | 55 +- > 1 file changed, 36 insertions(+), 19 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 24/25] x86: mp: Add more comments to the module
Hi Simon, On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > Add a description of how this module works and also some missing function > comments. > > Drop struct cpu_map since it is not used. "struct cpu_map" was already dropped in patch "[v2,10/25] x86: mp: Support APs waiting for instructions" http://patchwork.ozlabs.org/project/uboot/patch/20200614105621.v2.10.I5cdb6d2b53a528eaebda2227b8cdfe26c4c73ceb@changeid/ So you may adjust the codes to drop "struct cpu_map" in this patch instead? > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add a new patch with more comments > > arch/x86/cpu/mp_init.c| 91 ++- > arch/x86/include/asm/mp.h | 14 +- > 2 files changed, 102 insertions(+), 3 deletions(-) > Other than the commit message, Reviewed-by: Bin Meng Regards, Bin
Re: [PATCH v2 21/25] x86: mtrr: Update the command to use the new mtrr calls
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > Use the multi-CPU calls to set the MTRR values. This still supports only > the boot CPU for now. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > Changes in v2: > - Drop the renamed mtrr_set_valid_() instead of mtrr_set_valid() > > cmd/x86/mtrr.c | 34 -- > 1 file changed, 8 insertions(+), 26 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 20/25] x86: mtrr: Add support for writing to MTRRs on any CPU
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > To enable support for the 'mtrr' command, add a way to perform MTRR > operations on selected CPUs. > > This works by setting up a little 'operation' structure and sending it > around the CPUs for action. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Keep things building by temporarily renaming the function in cmd/ > > arch/x86/cpu/mtrr.c | 81 + > arch/x86/include/asm/mtrr.h | 21 ++ > cmd/x86/mtrr.c | 6 +-- > 3 files changed, 105 insertions(+), 3 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 19/25] x86: mtrr: Update MTRRs on all CPUs
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> When the boot CPU MTRRs are updated, perform the same update on all other
> CPUs so they are kept in sync.
>
> This avoids kernel warnings about mismatched MTRRs.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> Changes in v2:
> - Rename function to mtrr_write_all()
>
> arch/x86/cpu/mtrr.c | 57 +
> 1 file changed, 57 insertions(+)
>
> diff --git a/arch/x86/cpu/mtrr.c b/arch/x86/cpu/mtrr.c
> index c9b4e7d06e..5c567551e5 100644
> --- a/arch/x86/cpu/mtrr.c
> +++ b/arch/x86/cpu/mtrr.c
> @@ -74,10 +74,61 @@ void mtrr_read_all(struct mtrr_info *info)
> }
> }
>
> +void mtrr_write_all(struct mtrr_info *info)
> +{
> + struct mtrr_state state;
> + int i;
> +
> + for (i = 0; i < MTRR_COUNT; i++) {
> + mtrr_open(, true);
> + wrmsrl(MTRR_PHYS_BASE_MSR(i), info->mtrr[i].base);
> + wrmsrl(MTRR_PHYS_MASK_MSR(i), info->mtrr[i].mask);
> + mtrr_close(, true);
> + }
> +}
> +
> +static void write_mtrrs(void *arg)
> +{
> + struct mtrr_info *info = arg;
> +
> + mtrr_write_all(info);
> +}
> +
> +static void read_mtrrs(void *arg)
> +{
> + struct mtrr_info *info = arg;
> +
> + mtrr_read_all(info);
> +}
> +
> +/**
> + * mtrr_copy_to_aps() - Copy the MTRRs from the boot CPU to other CPUs
> + *
> + * @return 0 on success, -ve on failure
> + */
> +static int mtrr_copy_to_aps(void)
> +{
> + struct mtrr_info info;
> + int ret;
> +
> + ret = mp_run_on_cpus(MP_SELECT_BSP, read_mtrrs, );
> + if (ret == -ENXIO)
> + return 0;
> + else if (ret)
> + return log_msg_ret("bsp", ret);
> +
> + ret = mp_run_on_cpus(MP_SELECT_APS, write_mtrrs, );
> + if (ret)
> + return log_msg_ret("bsp", ret);
> +
> + return 0;
> +}
> +
> int mtrr_commit(bool do_caches)
> {
> struct mtrr_request *req = gd->arch.mtrr_req;
> struct mtrr_state state;
> + int ret;
> int i;
>
> debug("%s: enabled=%d, count=%d\n", __func__, gd->arch.has_mtrr,
> @@ -99,6 +150,12 @@ int mtrr_commit(bool do_caches)
> mtrr_close(, do_caches);
> debug("mtrr done\n");
>
> + if (gd->flags & GD_FLG_RELOC) {
> + ret = mtrr_copy_to_aps();
> + if (ret)
> + return log_msg_ret("copy", ret);
> + }
> +
> return 0;
> }
>
> --
We need to find a place where mtrr in BSP is duplicated in AP.
Currently this is done in init_cache_f_r() but at that time SMP is not
ready yet.
Regards,
Bin
Re: [PATCH v2 17/25] x86: Don't enable SMP in SPL
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > SMP should be set up in U-Boot where possible, not SPL. Disable it in SPL. > For 64-bit U-Boot we should find a way to allow SMP operations in U-Boot, > but this is somewhat more complicated. For now that is disabled too. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add a new patch to avoid enabling SMP in SPL > > arch/x86/cpu/Makefile | 2 +- > arch/x86/include/asm/mp.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 18/25] x86: coral: Update the memory map
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > This currently excludes the temporary memory used to start up the APs. > Add it. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Add new patch to add AP_DEFAULT_BASE to coral's memory map > > doc/board/google/chromebook_coral.rst | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Bin Meng
Re: [PATCH v2 16/25] x86: mtrr: Use MP calls to list the MTRRs
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote: > > Update the mtrr command to use mp_run_on_cpus() to obtain its information. > Since the selected CPU is the boot CPU this does not change the result, > but it sets the stage for supporting other CPUs. > > Signed-off-by: Simon Glass > Reviewed-by: Wolfgang Wallner > --- > > Changes in v2: > - Rename mtrr_save_all() to mtrr_read_all() > > arch/x86/cpu/mtrr.c | 11 +++ > arch/x86/include/asm/mtrr.h | 30 ++ > cmd/x86/mtrr.c | 25 + > 3 files changed, 62 insertions(+), 4 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v2 15/25] x86: mp: Add iterators for CPUs
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> It is convenient to iterate through the CPUs performing work on each one
> and processing the result. Add a few iterator functions which handle this.
> These can be used by any client code. It can call mp_run_on_cpus() on
> each CPU that is returned, handling them one at a time.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> arch/x86/cpu/mp_init.c| 62 +++
> arch/x86/include/asm/mp.h | 40 +
> 2 files changed, 102 insertions(+)
>
> diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
> index 9970b51c8d..c708c3e3c0 100644
> --- a/arch/x86/cpu/mp_init.c
> +++ b/arch/x86/cpu/mp_init.c
> @@ -675,6 +675,68 @@ int mp_park_aps(void)
> return get_timer(start);
> }
>
> +int mp_first_cpu(int cpu_select)
> +{
> + struct udevice *dev;
> + int num_cpus;
> + int ret;
> +
> + /*
> +* This assumes that CPUs are numbered from 0. This function tries to
> +* avoid assuming the CPU 0 is the boot CPU
So CPU 0 is not BSP ..
> +*/
> + if (cpu_select == MP_SELECT_ALL)
> + return 0; /* start with the first one */
> +
> + ret = get_bsp(, _cpus);
> + if (ret < 0)
> + return log_msg_ret("bsp", ret);
> +
> + /* Return boot CPU if requested */
> + if (cpu_select == MP_SELECT_BSP)
> + return ret;
> +
> + /* Return something other than the boot CPU, if APs requested */
> + if (cpu_select == MP_SELECT_APS && num_cpus > 1)
> + return ret == 0 ? 1 : 0;
> +
> + /* Try to check for an invalid value */
> + if (cpu_select < 0 || cpu_select >= num_cpus)
The logic (cpu_select >= num_cpus) assumes that cpu number is consecutive.
> + return -EINVAL;
> +
> + return cpu_select; /* return the only selected one */
> +}
> +
> +int mp_next_cpu(int cpu_select, int prev_cpu)
> +{
> + struct udevice *dev;
> + int num_cpus;
> + int ret;
> + int bsp;
> +
> + /* If we selected the BSP or a particular single CPU, we are done */
> + if (cpu_select == MP_SELECT_BSP || cpu_select >= 0)
Why stops on MP_SELECT_BSP?
So if I call the 2 APIs with the following sequence, is this allowed?
int cpu = mp_first_cpu(MP_SELECT_ALL); // this will return zero
cpu = mp_next_cpu(MP_SELECT_BSP, cpu); // then I got -EFBIG
> + return -EFBIG;
> +
> + /* Must be doing MP_SELECT_ALL or MP_SELECT_APS; return the next CPU
> */
> + ret = get_bsp(, _cpus);
> + if (ret < 0)
> + return log_msg_ret("bsp", ret);
> + bsp = ret;
> +
> + /* Move to the next CPU */
> + assert(prev_cpu >= 0);
> + ret = prev_cpu + 1;
> +
> + /* Skip the BSP if needed */
> + if (cpu_select == MP_SELECT_APS && ret == bsp)
> + ret++;
> + if (ret >= num_cpus)
> + return -EFBIG;
> +
> + return ret;
> +}
> +
> int mp_init(void)
> {
> int num_aps, num_cpus;
> diff --git a/arch/x86/include/asm/mp.h b/arch/x86/include/asm/mp.h
> index 38961ca44b..9f4223ae8c 100644
> --- a/arch/x86/include/asm/mp.h
> +++ b/arch/x86/include/asm/mp.h
> @@ -115,6 +115,31 @@ int mp_run_on_cpus(int cpu_select, mp_run_func func,
> void *arg);
> * @return 0 on success, -ve on error
> */
> int mp_park_aps(void);
> +
> +/**
> + * mp_first_cpu() - Get the first CPU to process, from a selection
> + *
> + * This is used to iterate through selected CPUs. Call this function first,
> then
> + * call mp_next_cpu() repeatedly until it returns -EFBIG.
So how does specify the cpu_select of these 2 APIs? Do they have to be the same?
For example, how about the following code sequence:
int cpu = mp_first_cpu(MP_SELECT_APS);
cpu = mp_next_cpu(MP_SELECT_BSP, cpu);
cpu = mp_next_cpu(MP_SELECT_APS, cpu);
It's quite ambiguous API design.
> + *
> + * @cpu_select: Selected CPUs (either a CPU number or MP_SELECT_...)
> + * @return next CPU number to run on (e.g. 0)
> + */
> +int mp_first_cpu(int cpu_select);
> +
> +/**
> + * mp_next_cpu() - Get the next CPU to process, from a selection
> + *
> + * This is used to iterate through selected CPUs. After first calling
> + * mp_first_cpu() once, call this function repeatedly until it returns
> -EFBIG.
> + *
> + * The value of @cpu_select must be the same for all calls.
> + *
> + * @cpu_select: Selected CPUs (either a CPU number or MP_SELECT_...)
Per the codes, if cpu_select >=0, -EFBIG will be returned. So this
suggests that cpu_selct can only be MP_SELECT_APS?
I have to say that these 2 APIs are hard to understand ..
> + * @prev_cpu: Previous value returned by mp_first_cpu()/mp_next_cpu()
> + * @return next CPU number to run on (e.g. 0)
> + */
> +int mp_next_cpu(int cpu_select, int prev_cpu);
> #else
> static inline int mp_run_on_cpus(int cpu_select,
Re: [PATCH v2 12/25] x86: Set the SMP flag when MP init is complete
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> Set this flag so we can track when it is safe to use CPUs other than the
> main one.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> arch/x86/cpu/mp_init.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
> index 673fdc9628..b0df7a3965 100644
> --- a/arch/x86/cpu/mp_init.c
> +++ b/arch/x86/cpu/mp_init.c
> @@ -643,6 +643,7 @@ int mp_init(void)
> debug("CPU init failed: err=%d\n", ret);
> return ret;
> }
> + gd->flags |= GD_FLG_SMP_INIT;
Other than the FLG name,
Reviewed-by: Bin Meng
Re: [PATCH v2 14/25] x86: mp: Park CPUs before running the OS
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> With the new MP features the CPUs are no-longer parked when the OS is run.
> Fix this by calling a special function to park them, just before the OS is
> started.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> arch/x86/cpu/cpu.c| 5 +
> arch/x86/cpu/mp_init.c| 18 ++
> arch/x86/include/asm/mp.h | 17 +
> 3 files changed, 40 insertions(+)
>
> diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
> index d0720fb7fb..baa7dae172 100644
> --- a/arch/x86/cpu/cpu.c
> +++ b/arch/x86/cpu/cpu.c
> @@ -66,6 +66,11 @@ static const char *const x86_vendor_name[] = {
>
> int __weak x86_cleanup_before_linux(void)
> {
> + int ret;
> +
> + ret = mp_park_aps();
> + if (ret)
> + return log_msg_ret("park", ret);
> bootstage_stash((void *)CONFIG_BOOTSTAGE_STASH_ADDR,
> CONFIG_BOOTSTAGE_STASH_SIZE);
>
> diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
> index e65c82c8fd..9970b51c8d 100644
> --- a/arch/x86/cpu/mp_init.c
> +++ b/arch/x86/cpu/mp_init.c
> @@ -657,6 +657,24 @@ int mp_run_on_cpus(int cpu_select, mp_run_func func,
> void *arg)
> return 0;
> }
>
> +static void park_this_cpu(void *unused)
> +{
> + stop_this_cpu();
> +}
> +
> +int mp_park_aps(void)
> +{
> + unsigned long start;
> + int ret;
> +
> + start = get_timer(0);
> + ret = mp_run_on_cpus(MP_SELECT_APS, park_this_cpu, NULL);
> + if (ret)
> + return ret;
> +
> + return get_timer(start);
What is this return value for? It seems you wanted to do some timeout check?
> +}
> +
> int mp_init(void)
> {
> int num_aps, num_cpus;
> diff --git a/arch/x86/include/asm/mp.h b/arch/x86/include/asm/mp.h
> index 0272b3c0b6..38961ca44b 100644
> --- a/arch/x86/include/asm/mp.h
> +++ b/arch/x86/include/asm/mp.h
> @@ -106,6 +106,15 @@ typedef void (*mp_run_func)(void *arg);
> * @return 0 on success, -ve on error
> */
> int mp_run_on_cpus(int cpu_select, mp_run_func func, void *arg);
> +
> +/**
> + * mp_park_aps() - Park the APs ready for the OS
> + *
> + * This halts all CPUs except the main one, ready for the OS to use them
> + *
> + * @return 0 on success, -ve on error
The return value does not match the codes
> + */
> +int mp_park_aps(void);
> #else
> static inline int mp_run_on_cpus(int cpu_select, mp_run_func func, void *arg)
> {
> @@ -114,6 +123,14 @@ static inline int mp_run_on_cpus(int cpu_select,
> mp_run_func func, void *arg)
>
> return 0;
> }
> +
> +static inline int mp_park_aps(void)
> +{
> + /* No APs to park */
> +
> + return 0;
> +}
> +
> #endif
>
> #endif /* _X86_MP_H_ */
Regards,
Bin
Re: [PATCH v2 13/25] x86: mp: Allow running functions on multiple CPUs
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> Add a way to run a function on a selection of CPUs. This supports either
> a single CPU, all CPUs, just the main CPU or just the 'APs', in Intel
> terminology.
>
> It works by writing into a mailbox and then waiting for the CPUs to notice
> it, take action and indicate they are done.
>
> When SMP is not yet enabled, this just calls the function on the main CPU.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - Add a comment to run_ap_work()
>
> arch/x86/cpu/mp_init.c| 96 ---
> arch/x86/include/asm/mp.h | 30
> 2 files changed, 120 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
> index b0df7a3965..e65c82c8fd 100644
> --- a/arch/x86/cpu/mp_init.c
> +++ b/arch/x86/cpu/mp_init.c
> @@ -53,12 +53,7 @@ struct mp_flight_plan {
> * callback
> */
> struct mp_callback {
> - /**
> -* func() - Function to call on the AP
> -*
> -* @arg: Argument to pass
> -*/
> - void (*func)(void *arg);
> + mp_run_func func;
> void *arg;
> int logical_cpu_number;
> };
> @@ -517,6 +512,64 @@ static void store_callback(struct mp_callback **slot,
> struct mp_callback *val)
> );
> }
>
> +/**
> + * run_ap_work() - Run a callback on selected APs
> + *
> + * This writes @callback to all APs and waits for them all to acknowledge it,
> + * Note that whether each AP actually calls the callback depends on the value
> + * of logical_cpu_number.
Is logical cpu number the dev->req_seq?
> + *
> + * @callback: Callback information to pass to all APs
> + * @bsp: CPU device for the BSP
> + * @num_cpus: The number of CPUs in the system (= number of APs + 1)
> + * @expire_ms: Timeout to wait for all APs to finish, in milliseconds, or 0
> for
> + * no timeout
> + * @return 0 if OK, -ETIMEDOUT if one or more APs failed to respond in time
> + */
> +static int run_ap_work(struct mp_callback *callback, struct udevice *bsp,
> + int num_cpus, uint expire_ms)
> +{
> + int cur_cpu = bsp->req_seq;
> + int num_aps = num_cpus - 1; /* number of non-BSPs to get this message
> */
> + int cpus_accepted;
> + ulong start;
> + int i;
> +
> + /* Signal to all the APs to run the func. */
> + for (i = 0; i < num_cpus; i++) {
> + if (cur_cpu != i)
> + store_callback(_callbacks[i], callback);
> + }
> + mfence();
> +
> + /* Wait for all the APs to signal back that call has been accepted. */
> + start = get_timer(0);
> +
> + do {
> + mdelay(1);
> + cpus_accepted = 0;
> +
> + for (i = 0; i < num_cpus; i++) {
> + if (cur_cpu == i)
> + continue;
> + if (!read_callback(_callbacks[i]))
> + cpus_accepted++;
This will double count accepted number of APs when the do .. while()
loops for the 2nd time.
> + }
> +
> + if (expire_ms && get_timer(start) >= expire_ms) {
> + log(UCLASS_CPU, LOGL_CRIT,
> + "AP call expired; %d/%d CPUs accepted\n",
> + cpus_accepted, num_aps);
> + return -ETIMEDOUT;
> + }
> + } while (cpus_accepted != num_aps);
> +
> + /* Make sure we can see any data written by the APs */
> + mfence();
> +
> + return 0;
> +}
> +
> /**
> * ap_wait_for_instruction() - Wait for and process requests from the main
> CPU
> *
> @@ -573,6 +626,37 @@ static struct mp_flight_record mp_steps[] = {
> MP_FR_BLOCK_APS(ap_wait_for_instruction, NULL, NULL, NULL),
> };
>
> +int mp_run_on_cpus(int cpu_select, mp_run_func func, void *arg)
> +{
> + struct mp_callback lcb = {
> + .func = func,
> + .arg = arg,
> + .logical_cpu_number = cpu_select,
> + };
> + struct udevice *dev;
> + int num_cpus;
> + int ret;
> +
> + if (!(gd->flags & GD_FLG_SMP_INIT))
> + return -ENXIO;
> +
> + ret = get_bsp(, _cpus);
> + if (ret < 0)
> + return log_msg_ret("bsp", ret);
> + if (cpu_select == MP_SELECT_ALL || cpu_select == MP_SELECT_BSP ||
> + cpu_select == ret) {
> + /* Run on BSP first */
> + func(arg);
> + }
> +
> + /* Allow up to 1 second for all APs to finish */
> + ret = run_ap_work(, dev, num_cpus, 1000 /* ms */);
> + if (ret)
> + return log_msg_ret("aps", ret);
> +
> + return 0;
> +}
> +
> int mp_init(void)
> {
> int num_aps, num_cpus;
> diff --git a/arch/x86/include/asm/mp.h b/arch/x86/include/asm/mp.h
> index 41b1575f4b..0272b3c0b6 100644
> --- a/arch/x86/include/asm/mp.h
> +++
Re: [PATCH v2 11/25] global_data: Add a generic global_data flag for SMP state
Hi Simon,
On Mon, Jun 15, 2020 at 1:00 AM Simon Glass wrote:
>
> Allow keeping track of whether all CPUs have been enabled yet. This allows
> us to know whether other CPUs need to be considered when updating
> CPU-specific settings such as MTRRs on x86.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Wolfgang Wallner
> ---
>
> (no changes since v1)
>
> include/asm-generic/global_data.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/asm-generic/global_data.h
> b/include/asm-generic/global_data.h
> index 8c78792cc9..345f365d79 100644
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -167,5 +167,6 @@ typedef struct global_data {
> #define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use */
> #define GD_FLG_WDT_READY 0x1 /* Watchdog is ready for use */
> #define GD_FLG_SKIP_LL_INIT0x2 /* Don't perform low-level init*/
> +#define GD_FLG_SMP_INIT0x4 /* SMP init is complete
> */
The name is a little bit vague. It's unclear whether this indicates
SMP init start or done.
Maybe GD_FLG_SMP_READY ?
Regards,
Bin
