* [U-Boot] [PATCH v2 2/6] configs: stm32f746-disco: Enable CONFIG_BLK
From: Patrice Chotard @ 2018-07-24 9:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532425165-29027-1-git-send-email-patrice.chotard@st.com>
CONFIG_BLK config flag becomes mandatory, enable it.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
---
Changes in v2: None
configs/stm32f746-disco_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/configs/stm32f746-disco_defconfig b/configs/stm32f746-disco_defconfig
index aa7403f3c516..6f07ff155862 100644
--- a/configs/stm32f746-disco_defconfig
+++ b/configs/stm32f746-disco_defconfig
@@ -40,7 +40,6 @@ CONFIG_CMD_FS_GENERIC=y
CONFIG_OF_CONTROL=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_NETCONSOLE=y
-# CONFIG_BLK is not set
CONFIG_DM_MMC=y
# CONFIG_SPL_DM_MMC is not set
CONFIG_ARM_PL180_MMCI=y
--
1.9.1
^ permalink raw reply related
* [U-Boot] [PATCH v2 1/6] configs: stm32f429-evaluation: Enable CONFIG_BLK
From: Patrice Chotard @ 2018-07-24 9:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532425165-29027-1-git-send-email-patrice.chotard@st.com>
CONFIG_BLK config flag becomes mandatory, enable it.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
---
Changes in v2: None
configs/stm32f429-evaluation_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/configs/stm32f429-evaluation_defconfig b/configs/stm32f429-evaluation_defconfig
index 1b14a4964067..3ddd5c50fb1d 100644
--- a/configs/stm32f429-evaluation_defconfig
+++ b/configs/stm32f429-evaluation_defconfig
@@ -26,7 +26,6 @@ CONFIG_CMD_FAT=y
CONFIG_CMD_FS_GENERIC=y
CONFIG_OF_CONTROL=y
CONFIG_OF_EMBED=y
-# CONFIG_BLK is not set
CONFIG_DM_MMC=y
CONFIG_ARM_PL180_MMCI=y
CONFIG_MTD_NOR_FLASH=y
--
1.9.1
^ permalink raw reply related
* [U-Boot] [PATCH v2 0/6] Add support of CONFIG_BLK for STM32Fx platforms
From: Patrice Chotard @ 2018-07-24 9:39 UTC (permalink / raw)
To: u-boot
This series :
_ adds support of CONFIG_BLK flag to STM32Fx platforms
_ enables CONFIG_BLK flag for STM32Fx based boards
_ adds missing clk_free() call in error path
_ adds read of "cd_inverted" DT property
Changes in v2:
- replace devfdt_get_addr() by dev_read_addr()
- re-introduce arm_pl180_mmc_ofdata_to_platdata()
Patrice Chotard (6):
configs: stm32f429-evaluation: Enable CONFIG_BLK
configs: stm32f746-disco: Enable CONFIG_BLK
configs: stm32f469-disco: Enable CONFIG_BLK
mmc: arm_pl180_mmci: Update to support CONFIG_BLK
mmc: arm_pl180_mmci: Add missing clk_free
mmc: arm_pl180_mmci: Add "cd_inverted" DT property read
configs/stm32f429-evaluation_defconfig | 1 -
configs/stm32f469-discovery_defconfig | 1 -
configs/stm32f746-disco_defconfig | 1 -
drivers/mmc/arm_pl180_mmci.c | 69 +++++++++++++++++++++-------------
4 files changed, 42 insertions(+), 30 deletions(-)
--
1.9.1
^ permalink raw reply
* [U-Boot] [PATCH V3 1/2] mmc: add HS400 support
From: Peng Fan @ 2018-07-24 8:59 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1aa691fb-29c5-5fbd-d106-343fda7985ac@ti.com>
>
> On Tuesday 24 July 2018 02:14 PM, Peng Fan wrote:
> > Hi Faiz,
> >
> > It's 2 months since this patchset out (:
>
> Has it already been accepted?
No. I did not receive response from Jaehoon.
>
> > drivers/mmc/Kconfig
> >>
> >> On Saturday 19 May 2018 06:24 PM, Peng Fan wrote:
> >>> Add HS400 support.
> >>> Selecting HS400 needs first select HS199 according to spec, so use a
> >>> dedicated function for HS400.
> >>> Add HS400 related macros.
> >>> Remove the restriction of only using the low 6 bits of
> >>> EXT_CSD_CARD_TYPE, using all the 8 bits.
> >>>
> >>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> >>> Cc: Jaehoon Chung <jh80.chung@samsung.com>
> >>> Cc: Jean-Jacques Hiblot <jjhiblot@ti.com>
> >>> Cc: Stefano Babic <sbabic@denx.de>
> >>> Cc: Simon Glass <sjg@chromium.org>
> >>> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> >>> Cc: Bin Meng <bmeng.cn@gmail.com>
> >>> ---
> >>>
> >>> V3:
> >>> Simplify code
> >>> add error msg
> >>>
> >>> V2:
> >>> remove 4bits support from HS400, as HS400 does not support 4bits per
> spec.
> >>>
> >>> drivers/mmc/Kconfig | 7 +++
> >>> drivers/mmc/mmc.c | 137
> >> +++++++++++++++++++++++++++++++++++++++++-----------
> >>> include/mmc.h | 11 +++++
> >>> 3 files changed, 128 insertions(+), 27 deletions(-)
> >>>
> >>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index
> >>> 3f15f85efd..a535a87a8e 100644
> >>> --- a/drivers/mmc/Kconfig
> >>> +++ b/drivers/mmc/Kconfig
> >>> @@ -104,6 +104,13 @@ config SPL_MMC_UHS_SUPPORT
> >>> cards. The IO voltage must be switchable from 3.3v to 1.8v. The bus
> >>> frequency can go up to 208MHz (SDR104)
> >>>
> >>> +config MMC_HS400_SUPPORT
> >>> + bool "enable HS400 support"
> >>> + select MMC_HS200_SUPPORT
> >>> + help
> >>> + The HS400 mode is support by some eMMC. The bus frequency is up
> to
> >>> + 200MHz. This mode requires tuning the IO.
> >>> +
> >>
> >> Please add SPL_MMC_HS400_SUPPORT also.
> >
> > What issue do you see? I did not test SPL MMC with HS400 support. You
> > mean only add a Kconfig entry SPL_MMC_HS400_SUPPORT?
>
> Yes only a Kconfig. It helps people who want to include/exclude it from SPL. You
> are implicitly checking for the config in
> CONFIG_IS_ENABLED(MMC_HS400_SUPPORT) below.
>
> I was just using your patch for some out of tree development and figured it
> would be useful to have the CONFIG.
Ok. I'll add it and post out V4 patchset.
Thanks,
Peng
>
> Thanks,
> Faiz
^ permalink raw reply
* [U-Boot] [UBOOT PATCH v2] net: zynq_gem: convert to use livetree
From: Michal Simek @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BN1PR02MB101A8BE4AAE6B40F4106905D9560@BN1PR02MB101.namprd02.prod.outlook.com>
Hi,
On 23.7.2018 07:48, Siva Durga Prasad Paladugu wrote:
> Hi Joe/Michal,
>
> Can you please take it up if it is fine.
joe: Can you please take it via your tree?
There are some patches before this.
Thanks,
Michal
^ permalink raw reply
* [U-Boot] [PATCH v3 5/5] sandbox: led: use new function to configure default state
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532422712-15107-1-git-send-email-patrick.delaunay@st.com>
Initialize the led with the default state defined in device tree
in board_init and solve issue with test for led default state.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
Led default-state is correctly handle in Sandbox, tested with:
./u-boot -d ./arch/sandbox/dts/test.dtb
=> led list
sandbox:red <inactive>
sandbox:green <inactive>
sandbox:default_on on
sandbox:default_off off
This patch solve "make tests" issue introduced by
http://patchwork.ozlabs.org/patch/943651/
Changes in v3: None
Changes in v2:
- add sandbox impact and test update
board/sandbox/sandbox.c | 9 +++++++++
common/board_r.c | 3 ++-
test/dm/led.c | 3 +++
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index 195f620..66b5f24 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -6,6 +6,7 @@
#include <common.h>
#include <cros_ec.h>
#include <dm.h>
+#include <led.h>
#include <os.h>
#include <asm/test.h>
#include <asm/u-boot-sandbox.h>
@@ -47,6 +48,14 @@ int dram_init(void)
return 0;
}
+int board_init(void)
+{
+#ifdef CONFIG_LED
+ led_default_state();
+#endif /* CONFIG_LED */
+ return 0;
+}
+
#ifdef CONFIG_BOARD_LATE_INIT
int board_late_init(void)
{
diff --git a/common/board_r.c b/common/board_r.c
index 64f2574..9402c0e 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -690,7 +690,8 @@ static init_fnc_t init_sequence_r[] = {
#ifdef CONFIG_DM
initr_dm,
#endif
-#if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || defined(CONFIG_RISCV)
+#if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || defined(CONFIG_RISCV) || \
+ defined(CONFIG_SANDBOX)
board_init, /* Setup chipselects */
#endif
/*
diff --git a/test/dm/led.c b/test/dm/led.c
index 0071f21..00de7b3 100644
--- a/test/dm/led.c
+++ b/test/dm/led.c
@@ -32,6 +32,9 @@ static int dm_test_led_default_state(struct unit_test_state *uts)
{
struct udevice *dev;
+ /* configure the default state (auto-probe) */
+ led_default_state();
+
/* Check that we handle the default-state property correctly. */
ut_assertok(led_get_by_label("sandbox:default_on", &dev));
ut_asserteq(LEDST_ON, led_get_state(dev));
--
2.7.4
^ permalink raw reply related
* [U-Boot] [PATCH v3 4/5] stm32mp1: use new function led default state
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532422712-15107-1-git-send-email-patrick.delaunay@st.com>
Initialize the led with the default state defined in device tree.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
Changes in v3:
- minor update after Simon review
- include led.h to avoid compilation warning on stm32mp1 board
Changes in v2: None
board/st/stm32mp1/stm32mp1.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index cc39fa6..bfc8ab6 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -4,6 +4,7 @@
*/
#include <config.h>
#include <common.h>
+#include <led.h>
#include <asm/arch/stm32.h>
/*
@@ -22,5 +23,8 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = STM32_DDR_BASE + 0x100;
+ if (IS_ENABLED(CONFIG_LED))
+ led_default_state();
+
return 0;
}
--
2.7.4
^ permalink raw reply related
* [U-Boot] [PATCH v3 3/5] dm: led: move default state support in led uclass
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532422712-15107-1-git-send-email-patrick.delaunay@st.com>
This patch save common LED property "default-state" value
in post bind of LED uclass.
The configuration for this default state is only performed when
led_default_state() is called;
It can be called in your board_init()
or it could added in init_sequence_r[] in future.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
Changes in v3: None
Changes in v2: None
drivers/led/led-uclass.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++
drivers/led/led_gpio.c | 8 -------
include/led.h | 23 +++++++++++++++++++++
3 files changed, 77 insertions(+), 8 deletions(-)
diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
index 2f4d69e..141401d 100644
--- a/drivers/led/led-uclass.c
+++ b/drivers/led/led-uclass.c
@@ -8,6 +8,7 @@
#include <dm.h>
#include <errno.h>
#include <led.h>
+#include <dm/device-internal.h>
#include <dm/root.h>
#include <dm/uclass-internal.h>
@@ -63,8 +64,61 @@ int led_set_period(struct udevice *dev, int period_ms)
}
#endif
+static int led_post_bind(struct udevice *dev)
+{
+ struct led_uc_plat *uc_pdata;
+ const char *default_state;
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+
+ /* common optional properties */
+ uc_pdata->default_state = LED_DEF_NO;
+ default_state = dev_read_string(dev, "default-state");
+ if (default_state) {
+ if (!strncmp(default_state, "on", 2))
+ uc_pdata->default_state = LED_DEF_ON;
+ else if (!strncmp(default_state, "off", 3))
+ uc_pdata->default_state = LED_DEF_OFF;
+ else if (!strncmp(default_state, "keep", 4))
+ uc_pdata->default_state = LED_DEF_KEEP;
+ }
+
+ return 0;
+}
+
+int led_default_state(void)
+{
+ struct udevice *dev;
+ struct uclass *uc;
+ struct led_uc_plat *uc_pdata;
+ int ret;
+
+ ret = uclass_get(UCLASS_LED, &uc);
+ if (ret)
+ return ret;
+ for (uclass_find_first_device(UCLASS_LED, &dev);
+ dev;
+ uclass_find_next_device(&dev)) {
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (!uc_pdata || uc_pdata->default_state == LED_DEF_NO)
+ continue;
+ ret = device_probe(dev);
+ if (ret)
+ return ret;
+ if (uc_pdata->default_state == LED_DEF_ON)
+ led_set_state(dev, LEDST_ON);
+ else if (uc_pdata->default_state == LED_DEF_OFF)
+ led_set_state(dev, LEDST_OFF);
+ printf("%s: default_state=%d\n",
+ uc_pdata->label, uc_pdata->default_state);
+ }
+
+ return ret;
+}
+
UCLASS_DRIVER(led) = {
.id = UCLASS_LED,
.name = "led",
+ .post_bind = led_post_bind,
.per_device_platdata_auto_alloc_size = sizeof(struct led_uc_plat),
};
diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index 533587d..93f6b91 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -57,7 +57,6 @@ static int led_gpio_probe(struct udevice *dev)
{
struct led_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
struct led_gpio_priv *priv = dev_get_priv(dev);
- const char *default_state;
int ret;
/* Ignore the top-level LED node */
@@ -68,13 +67,6 @@ static int led_gpio_probe(struct udevice *dev)
if (ret)
return ret;
- default_state = dev_read_string(dev, "default-state");
- if (default_state) {
- if (!strncmp(default_state, "on", 2))
- gpio_led_set_state(dev, LEDST_ON);
- else if (!strncmp(default_state, "off", 3))
- gpio_led_set_state(dev, LEDST_OFF);
- }
return 0;
}
diff --git a/include/led.h b/include/led.h
index 940b97f..ff45f03 100644
--- a/include/led.h
+++ b/include/led.h
@@ -8,12 +8,27 @@
#define __LED_H
/**
+ * enum led_default_state - The initial state of the LED.
+ * see Documentation/devicetree/bindings/leds/common.txt
+ */
+enum led_def_state_t {
+ LED_DEF_NO,
+ LED_DEF_ON,
+ LED_DEF_OFF,
+ LED_DEF_KEEP
+};
+
+/**
* struct led_uc_plat - Platform data the uclass stores about each device
*
* @label: LED label
+ * @default_state* - The initial state of the LED.
+ see Documentation/devicetree/bindings/leds/common.txt
+ * * - set automatically on device bind by the uclass's '.post_bind' method.
*/
struct led_uc_plat {
const char *label;
+ enum led_def_state_t default_state;
};
/**
@@ -106,4 +121,12 @@ enum led_state_t led_get_state(struct udevice *dev);
*/
int led_set_period(struct udevice *dev, int period_ms);
+/**
+ * led_default_state() - set the default state for all the LED
+ *
+ * This enables all leds which have default state.
+ *
+ */
+int led_default_state(void);
+
#endif
--
2.7.4
^ permalink raw reply related
* [U-Boot] [PATCH v3 2/5] Revert "dm: led: auto probe() LEDs with "default-state""
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532422712-15107-1-git-send-email-patrick.delaunay@st.com>
This reverts commit bc882f5d5c7b4d6ed5e927bf838863af43c786e7.
because this patch adds the probe of LED driver during the
binding phasis. It is not allowed in driver model because
the drivers (clock, pincontrol) needed by the LED driver can
be also probed before the binding of all the device and
it is a source of problems.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
Changes in v3:
- add motivation in revert commit
Changes in v2: None
drivers/led/led_gpio.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index a36942b..533587d 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -10,7 +10,6 @@
#include <led.h>
#include <asm/gpio.h>
#include <dm/lists.h>
-#include <dm/uclass-internal.h>
struct led_gpio_priv {
struct gpio_desc gpio;
@@ -118,14 +117,6 @@ static int led_gpio_bind(struct udevice *parent)
return ret;
uc_plat = dev_get_uclass_platdata(dev);
uc_plat->label = label;
-
- if (ofnode_read_bool(node, "default-state")) {
- struct udevice *devp;
-
- ret = uclass_get_device_tail(dev, 0, &devp);
- if (ret)
- return ret;
- }
}
return 0;
--
2.7.4
^ permalink raw reply related
* [U-Boot] [PATCH v3 1/5] stm32mp1: add gpio led support
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532422712-15107-1-git-send-email-patrick.delaunay@st.com>
This patch add the 4 LED available on the ED1 board and activated
gpio led driver.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
Changes in v3: None
Changes in v2: None
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 24 ++++++++++++++++++++++++
configs/stm32mp15_basic_defconfig | 2 ++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index 39a0ebc..4898483 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -13,6 +13,30 @@
mmc1 = &sdmmc2;
i2c3 = &i2c4;
};
+
+ led {
+ compatible = "gpio-leds";
+
+ red {
+ label = "stm32mp:red:status";
+ gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ green {
+ label = "stm32mp:green:user";
+ gpios = <&gpioa 14 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+ orange {
+ label = "stm32mp:orange:status";
+ gpios = <&gpioh 7 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ blue {
+ label = "stm32mp:blue:user";
+ gpios = <&gpiod 11 GPIO_ACTIVE_HIGH>;
+ };
+ };
};
&uart4_pins_a {
diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig
index c72a440..2cac114 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -29,6 +29,8 @@ CONFIG_CMD_EXT4_WRITE=y
# CONFIG_SPL_DOS_PARTITION is not set
CONFIG_DM_I2C=y
CONFIG_SYS_I2C_STM32F7=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
CONFIG_DM_MMC=y
CONFIG_STM32_SDMMC2=y
# CONFIG_PINCTRL_FULL is not set
--
2.7.4
^ permalink raw reply related
* [U-Boot] [PATCH v3 0/5] dm: led: remove auto probe in binding function
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
Hi,
The commit bc882f5d5c7b4d6ed5e927bf838863af43c786e7
introduce auto probe of LED in binding function
but that cause issue on my board.
This first patch of this patchset activateis the LED on my board
to explain the issue, the second patch revert this commit and
the third one propose an other solution.
For me, this commit is a error because in README of doc/driver-model/
it is indicated:
The device's bind() method is permitted to perform simple actions, but
should not scan the device tree node, not initialise hardware, nor set up
structures or allocate memory. All of these tasks should be left for
the probe() method.
And in the patch the LED driver is probed during the binding scan.
When I activated the LED in my ARM target with the patch
"stm32mp1: add gpio led support", I have the sequence:
dm_init_and_scan() :
1/ dm_scan_fdt_node()
=> loop on all the node
2/ scan for LED node
=> probe of LED driver is forced by "default-state" detection
LED1 - "red"
=> probe of father of "red" node
A - led
B - soc
C - root
=> probe of node needed by GPIO
1 - pin-controller
2 - gpio at 50002000
3 - rcc-clk at 50000000
4 - rcc at 50000000
=> probe forced by default state for other led
LED2 - green
LED3 - orange
=> probe of node needed by GPIO (other bank)
5 - gpio at 50009000
3/ dm_extended_scan_fdt scan continue...
scan node "fixed-clock" under "/clocks"
clk-hse
clk-hsi
clk-lse
clk-lsi
clk-csi
4/ probe of all the used devices.... after dm_extended_scan_fdt()
So many driver are probed before the end of the scan binding loop !
And that cause issue in my board (boot failed) because the rcc-clk clock
driver found the input frequency with these fixed-clock, which are binded
only after the stm32mp1 clock driver probe.
For me probe in forbidden in binding function and
thus uclass_get_device_tail() is not allowed in the commit
bc882f5d5c7b4d6ed5e927bf838863af43c786e7 which need to be reverted.
In the third patch I proposed an other solution based
on the existing solution in u-class regulator used to enable
regulator with "boot on" property (see regulators_enable_boot_on function).
I think that adding a function is the better solution in the driver model
to force probe for some node according binding information
(after dm_init_and_scan call).
This new function should be called in board_init function for each board
but it could be also added in init_sequence_r[] in future.
Changes in v3:
- add motivation in revert commit
- minor update after Simon review
- include led.h to avoid compilation warning on stm32mp1 board
Changes in v2:
- add sandbox impact and test update
Patrick Delaunay (5):
stm32mp1: add gpio led support
Revert "dm: led: auto probe() LEDs with "default-state""
dm: led: move default state support in led uclass
stm32mp1: use new function led default state
sandbox: led: use new function to configure default state
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 24 ++++++++++++++
board/sandbox/sandbox.c | 9 ++++++
board/st/stm32mp1/stm32mp1.c | 4 +++
common/board_r.c | 3 +-
configs/stm32mp15_basic_defconfig | 2 ++
drivers/led/led-uclass.c | 54 ++++++++++++++++++++++++++++++++
drivers/led/led_gpio.c | 17 ----------
include/led.h | 23 ++++++++++++++
test/dm/led.c | 3 ++
9 files changed, 121 insertions(+), 18 deletions(-)
--
2.7.4
^ permalink raw reply
* [U-Boot] [PATCH V3 1/2] mmc: add HS400 support
From: Faiz Abbas @ 2018-07-24 8:57 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AM0PR04MB44813EF0C18A49FD4963A4B688550@AM0PR04MB4481.eurprd04.prod.outlook.com>
Hi Peng,
On Tuesday 24 July 2018 02:14 PM, Peng Fan wrote:
> Hi Faiz,
>
> It's 2 months since this patchset out (:
Has it already been accepted?
> drivers/mmc/Kconfig
>>
>> On Saturday 19 May 2018 06:24 PM, Peng Fan wrote:
>>> Add HS400 support.
>>> Selecting HS400 needs first select HS199 according to spec, so use a
>>> dedicated function for HS400.
>>> Add HS400 related macros.
>>> Remove the restriction of only using the low 6 bits of
>>> EXT_CSD_CARD_TYPE, using all the 8 bits.
>>>
>>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>> Cc: Jaehoon Chung <jh80.chung@samsung.com>
>>> Cc: Jean-Jacques Hiblot <jjhiblot@ti.com>
>>> Cc: Stefano Babic <sbabic@denx.de>
>>> Cc: Simon Glass <sjg@chromium.org>
>>> Cc: Kishon Vijay Abraham I <kishon@ti.com>
>>> Cc: Bin Meng <bmeng.cn@gmail.com>
>>> ---
>>>
>>> V3:
>>> Simplify code
>>> add error msg
>>>
>>> V2:
>>> remove 4bits support from HS400, as HS400 does not support 4bits per spec.
>>>
>>> drivers/mmc/Kconfig | 7 +++
>>> drivers/mmc/mmc.c | 137
>> +++++++++++++++++++++++++++++++++++++++++-----------
>>> include/mmc.h | 11 +++++
>>> 3 files changed, 128 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index
>>> 3f15f85efd..a535a87a8e 100644
>>> --- a/drivers/mmc/Kconfig
>>> +++ b/drivers/mmc/Kconfig
>>> @@ -104,6 +104,13 @@ config SPL_MMC_UHS_SUPPORT
>>> cards. The IO voltage must be switchable from 3.3v to 1.8v. The bus
>>> frequency can go up to 208MHz (SDR104)
>>>
>>> +config MMC_HS400_SUPPORT
>>> + bool "enable HS400 support"
>>> + select MMC_HS200_SUPPORT
>>> + help
>>> + The HS400 mode is support by some eMMC. The bus frequency is up to
>>> + 200MHz. This mode requires tuning the IO.
>>> +
>>
>> Please add SPL_MMC_HS400_SUPPORT also.
>
> What issue do you see? I did not test SPL MMC with HS400 support. You mean only add a Kconfig
> entry SPL_MMC_HS400_SUPPORT?
Yes only a Kconfig. It helps people who want to include/exclude it from
SPL. You are implicitly checking for the config in
CONFIG_IS_ENABLED(MMC_HS400_SUPPORT) below.
I was just using your patch for some out of tree development and figured
it would be useful to have the CONFIG.
Thanks,
Faiz
^ permalink raw reply
* [U-Boot] [PATCH] sunxi: enable SATA on Banana Pi M2 Berry
From: Maxime Ripard @ 2018-07-24 8:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180723222219.20202-1-gmbnomis@gmail.com>
On Tue, Jul 24, 2018 at 12:22:19AM +0200, Simon Baatz wrote:
> Banana Pi M2 Ultra and M2 Berry are very similar boards. SATA can be
> enabled exactly the same as for M2 Ultra introduced in
> commit daa8b75a5527 ("sunxi: enable SATA on Banana Pi M2 Ultra").
>
> Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180724/735a8a15/attachment.sig>
^ permalink raw reply
* [U-Boot] [UBOOT PATCH] gpio: zynq: Used platdata structure for storing static data instead of priv
From: Michal Simek @ 2018-07-24 8:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ02o89Jj5ic1gtocgNnDPfFhYn9_qfRR6j-1+++Z1+QWQ@mail.gmail.com>
On 24.7.2018 01:48, Simon Glass wrote:
> On 20 July 2018 at 03:06, Vipul Kumar <vipul.kumar@xilinx.com> wrote:
>> This patch used platdata structure instead of priv for storing static
>> information read from DT.
>>
>> Signed-off-by: Vipul Kumar <vipul.kumar@xilinx.com>
>> ---
>> drivers/gpio/zynq_gpio.c | 67 ++++++++++++++++++++++++------------------------
>> 1 file changed, 34 insertions(+), 33 deletions(-)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
Applied.
M
^ permalink raw reply
* [U-Boot] [PATCH V3 1/2] mmc: add HS400 support
From: Peng Fan @ 2018-07-24 8:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <3ec20129-ad7c-8b1f-596a-9f2db8baeca7@ti.com>
Hi Faiz,
It's 2 months since this patchset out (:
>
> On Saturday 19 May 2018 06:24 PM, Peng Fan wrote:
> > Add HS400 support.
> > Selecting HS400 needs first select HS199 according to spec, so use a
> > dedicated function for HS400.
> > Add HS400 related macros.
> > Remove the restriction of only using the low 6 bits of
> > EXT_CSD_CARD_TYPE, using all the 8 bits.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > Cc: Jaehoon Chung <jh80.chung@samsung.com>
> > Cc: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > Cc: Stefano Babic <sbabic@denx.de>
> > Cc: Simon Glass <sjg@chromium.org>
> > Cc: Kishon Vijay Abraham I <kishon@ti.com>
> > Cc: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >
> > V3:
> > Simplify code
> > add error msg
> >
> > V2:
> > remove 4bits support from HS400, as HS400 does not support 4bits per spec.
> >
> > drivers/mmc/Kconfig | 7 +++
> > drivers/mmc/mmc.c | 137
> +++++++++++++++++++++++++++++++++++++++++-----------
> > include/mmc.h | 11 +++++
> > 3 files changed, 128 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index
> > 3f15f85efd..a535a87a8e 100644
> > --- a/drivers/mmc/Kconfig
> > +++ b/drivers/mmc/Kconfig
> > @@ -104,6 +104,13 @@ config SPL_MMC_UHS_SUPPORT
> > cards. The IO voltage must be switchable from 3.3v to 1.8v. The bus
> > frequency can go up to 208MHz (SDR104)
> >
> > +config MMC_HS400_SUPPORT
> > + bool "enable HS400 support"
> > + select MMC_HS200_SUPPORT
> > + help
> > + The HS400 mode is support by some eMMC. The bus frequency is up to
> > + 200MHz. This mode requires tuning the IO.
> > +
>
> Please add SPL_MMC_HS400_SUPPORT also.
What issue do you see? I did not test SPL MMC with HS400 support. You mean only add a Kconfig
entry SPL_MMC_HS400_SUPPORT?
Regards,
Peng.
>
> Thanks,
> Faiz
^ permalink raw reply
* [U-Boot] [PATCH v2.1 11/13] sunxi: add DRAM support to H6
From: Maxime Ripard @ 2018-07-24 8:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180722221334.3679-1-icenowy@aosc.io>
On Mon, Jul 23, 2018 at 06:13:34AM +0800, Icenowy Zheng wrote:
> The Allwinner H6 SoC comes with a set of new DRAM controller+PHY combo.
> Both the controller and the PHY seem to be originate from DesignWare,
> and are similar to the ones in ZynqMP SoCs.
>
> This commit introduces an initial DRAM driver for H6, which contains
> only LPDDR3 support. The currently known SBCs with H6 all come with
> LPDDR3 memory, including Pine H64 and several Orange Pi's.
>
> The BSP DRAM initialization code is closed source and violates GPL. Code
> in this commit is written by experimenting, referring the code/document
> of other users of the IPs (mainly the ZynqMP, as it's the only found PHY
> reference) and disassebling the BSP blob.
>
> Thanks for Jernej Skrabec for review and fix some issues in this driver
> (including the most critical one which made it to work), and rewrite
> some code from register dump!
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180724/a9648f1d/attachment.sig>
^ permalink raw reply
* [U-Boot] [PATCH V3 1/2] mmc: add HS400 support
From: Faiz Abbas @ 2018-07-24 8:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180519125448.16563-1-peng.fan@nxp.com>
Hi,
On Saturday 19 May 2018 06:24 PM, Peng Fan wrote:
> Add HS400 support.
> Selecting HS400 needs first select HS199 according to spec, so use
> a dedicated function for HS400.
> Add HS400 related macros.
> Remove the restriction of only using the low 6 bits of
> EXT_CSD_CARD_TYPE, using all the 8 bits.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Cc: Jaehoon Chung <jh80.chung@samsung.com>
> Cc: Jean-Jacques Hiblot <jjhiblot@ti.com>
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> V3:
> Simplify code
> add error msg
>
> V2:
> remove 4bits support from HS400, as HS400 does not support 4bits per spec.
>
> drivers/mmc/Kconfig | 7 +++
> drivers/mmc/mmc.c | 137 +++++++++++++++++++++++++++++++++++++++++-----------
> include/mmc.h | 11 +++++
> 3 files changed, 128 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 3f15f85efd..a535a87a8e 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -104,6 +104,13 @@ config SPL_MMC_UHS_SUPPORT
> cards. The IO voltage must be switchable from 3.3v to 1.8v. The bus
> frequency can go up to 208MHz (SDR104)
>
> +config MMC_HS400_SUPPORT
> + bool "enable HS400 support"
> + select MMC_HS200_SUPPORT
> + help
> + The HS400 mode is support by some eMMC. The bus frequency is up to
> + 200MHz. This mode requires tuning the IO.
> +
Please add SPL_MMC_HS400_SUPPORT also.
Thanks,
Faiz
^ permalink raw reply
* [U-Boot] [PATCH v2 13/13] sunxi: add support for Pine H64 board
From: Maxime Ripard @ 2018-07-24 8:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180721082032.39980-14-icenowy@aosc.io>
On Sat, Jul 21, 2018 at 04:20:32PM +0800, Icenowy Zheng wrote:
> Pine H64 is a SBC with Allwinner H6 SoC produced by Pine64. It features
> 1GiB/2GiB/4GiB(3GiB usable) DRAM, two USB 2.0 ports, one USB 3.0 port
> and a mPCIE slot.
>
> Add support for it.
>
> The device tree is from Linux next-20180720.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180724/3f0fa86c/attachment.sig>
^ permalink raw reply
* [U-Boot] [linux-sunxi] Re: [PATCH v2 10/13] sunxi: add MMC support for H6
From: Icenowy Zheng @ 2018-07-24 8:39 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180724083743.cboz25nswq6r7wry@flea>
于 2018年7月24日 GMT+08:00 下午4:37:43, Maxime Ripard <maxime.ripard@bootlin.com> 写到:
>On Sat, Jul 21, 2018 at 04:20:29PM +0800, Icenowy Zheng wrote:
>> The Allwinner H6 SoC has 3 MMC controllers like the ones in A64, with
>> the MMC2 come with the capability to do crypto by EMCE.
>>
>> Add MMC support for H6. EMCE support is not added yet.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> arch/arm/include/asm/arch-sunxi/mmc.h | 2 +-
>> board/sunxi/board.c | 7 +++++++
>> drivers/mmc/sunxi_mmc.c | 13 ++++++++++++-
>> 3 files changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
>b/arch/arm/include/asm/arch-sunxi/mmc.h
>> index 1574b8e8fe..d98c53faaa 100644
>> --- a/arch/arm/include/asm/arch-sunxi/mmc.h
>> +++ b/arch/arm/include/asm/arch-sunxi/mmc.h
>> @@ -45,7 +45,7 @@ struct sunxi_mmc {
>> u32 chda; /* 0x90 */
>> u32 cbda; /* 0x94 */
>> u32 res2[26];
>> -#ifdef CONFIG_SUNXI_GEN_SUN6I
>> +#if defined(CONFIG_SUNXI_GEN_SUN6I) ||
>defined(CONFIG_MACH_SUN50I_H6)
>> u32 res3[64];
>> #endif
>> u32 fifo; /* 0x100 / 0x200 FIFO access address */
>> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
>> index 5ed1b8bae1..857d5ff010 100644
>> --- a/board/sunxi/board.c
>> +++ b/board/sunxi/board.c
>> @@ -443,6 +443,13 @@ static void mmc_pinmux_setup(int sdc)
>> sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
>> sunxi_gpio_set_drv(pin, 2);
>> }
>> +#elif defined(CONFIG_MACH_SUN50I_H6)
>> + /* SDC2: PC4-PC14 */
>> + for (pin = SUNXI_GPC(4); pin <= SUNXI_GPC(14); pin++) {
>> + sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SDC2);
>> + sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
>> + sunxi_gpio_set_drv(pin, 2);
>> + }
>> #elif defined(CONFIG_MACH_SUN9I)
>> /* SDC2: PC6-PC16 */
>> for (pin = SUNXI_GPC(6); pin <= SUNXI_GPC(16); pin++) {
>> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
>> index 7fa1ae8b16..39f15eb423 100644
>> --- a/drivers/mmc/sunxi_mmc.c
>> +++ b/drivers/mmc/sunxi_mmc.c
>> @@ -70,10 +70,12 @@ static int mmc_resource_init(int sdc_no)
>> priv->reg = (struct sunxi_mmc *)SUNXI_MMC2_BASE;
>> priv->mclkreg = &ccm->sd2_clk_cfg;
>> break;
>> +#ifdef SUNXI_MMC3_BASE
>> case 3:
>> priv->reg = (struct sunxi_mmc *)SUNXI_MMC3_BASE;
>> priv->mclkreg = &ccm->sd3_clk_cfg;
>> break;
>> +#endif
>> default:
>> printf("Wrong mmc number %d\n", sdc_no);
>> return -1;
>> @@ -116,6 +118,9 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv
>*priv, unsigned int hz)
>> #ifdef CONFIG_MACH_SUN9I
>> pll = CCM_MMC_CTRL_PLL_PERIPH0;
>> pll_hz = clock_get_pll4_periph0();
>> +#elif defined(CONFIG_MACH_SUN50I_H6)
>> + pll = CCM_MMC_CTRL_PLL6X2;
>> + pll_hz = clock_get_pll6() * 2;
>> #else
>> pll = CCM_MMC_CTRL_PLL6;
>> pll_hz = clock_get_pll6();
>> @@ -494,7 +499,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>>
>> cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
>> cfg->host_caps = MMC_MODE_4BIT;
>> -#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I)
>> +#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I) ||
>defined(CONFIG_MACH_SUN50I_H6)
>> if (sdc_no == 2)
>> cfg->host_caps = MMC_MODE_8BIT;
>> #endif
>> @@ -509,6 +514,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>>
>> /* config ahb clock */
>> debug("init mmc %d clock and io\n", sdc_no);
>> +#if !defined(CONFIG_MACH_SUN50I_H6)
>> setbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_MMC(sdc_no));
>>
>> #ifdef CONFIG_SUNXI_GEN_SUN6I
>> @@ -519,6 +525,11 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>> /* sun9i has a mmc-common module, also set the gate and reset there
>*/
>> writel(SUNXI_MMC_COMMON_CLK_GATE | SUNXI_MMC_COMMON_RESET,
>> SUNXI_MMC_COMMON_BASE + 4 * sdc_no);
>> +#endif
>> +#else /* CONFIG_MACH_SUN50I_H6 */
>> + setbits_le32(&ccm->sd_gate_reset, 1 << sdc_no);
>> + /* unassert reset */
>> + setbits_le32(&ccm->sd_gate_reset, 1 << (RESET_SHIFT + sdc_no));
>> #endif
>> ret = mmc_set_mod_clk(priv, 24000000);
>> if (ret)
>
>You should use the DM instead.
Then we still need the DM-less ver for SPL.
>
>Maxime
^ permalink raw reply
* [U-Boot] [PATCH v2 12/13] sunxi: add support for Allwinner H6 SoC
From: Maxime Ripard @ 2018-07-24 8:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180721082032.39980-13-icenowy@aosc.io>
On Sat, Jul 21, 2018 at 04:20:31PM +0800, Icenowy Zheng wrote:
> Allwinner H6 is a new SoC from Allwinner features USB3 and PCIe
> interfaces.
>
> This patch adds support for it.
>
> The corresponding DTSI file, from Linux next-20180720, is also
> introduced.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180724/49abc4a8/attachment.sig>
^ permalink raw reply
* [U-Boot] [PATCH v2 10/13] sunxi: add MMC support for H6
From: Maxime Ripard @ 2018-07-24 8:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180721082032.39980-11-icenowy@aosc.io>
On Sat, Jul 21, 2018 at 04:20:29PM +0800, Icenowy Zheng wrote:
> The Allwinner H6 SoC has 3 MMC controllers like the ones in A64, with
> the MMC2 come with the capability to do crypto by EMCE.
>
> Add MMC support for H6. EMCE support is not added yet.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> arch/arm/include/asm/arch-sunxi/mmc.h | 2 +-
> board/sunxi/board.c | 7 +++++++
> drivers/mmc/sunxi_mmc.c | 13 ++++++++++++-
> 3 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h b/arch/arm/include/asm/arch-sunxi/mmc.h
> index 1574b8e8fe..d98c53faaa 100644
> --- a/arch/arm/include/asm/arch-sunxi/mmc.h
> +++ b/arch/arm/include/asm/arch-sunxi/mmc.h
> @@ -45,7 +45,7 @@ struct sunxi_mmc {
> u32 chda; /* 0x90 */
> u32 cbda; /* 0x94 */
> u32 res2[26];
> -#ifdef CONFIG_SUNXI_GEN_SUN6I
> +#if defined(CONFIG_SUNXI_GEN_SUN6I) || defined(CONFIG_MACH_SUN50I_H6)
> u32 res3[64];
> #endif
> u32 fifo; /* 0x100 / 0x200 FIFO access address */
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 5ed1b8bae1..857d5ff010 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -443,6 +443,13 @@ static void mmc_pinmux_setup(int sdc)
> sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> sunxi_gpio_set_drv(pin, 2);
> }
> +#elif defined(CONFIG_MACH_SUN50I_H6)
> + /* SDC2: PC4-PC14 */
> + for (pin = SUNXI_GPC(4); pin <= SUNXI_GPC(14); pin++) {
> + sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SDC2);
> + sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
> + sunxi_gpio_set_drv(pin, 2);
> + }
> #elif defined(CONFIG_MACH_SUN9I)
> /* SDC2: PC6-PC16 */
> for (pin = SUNXI_GPC(6); pin <= SUNXI_GPC(16); pin++) {
> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> index 7fa1ae8b16..39f15eb423 100644
> --- a/drivers/mmc/sunxi_mmc.c
> +++ b/drivers/mmc/sunxi_mmc.c
> @@ -70,10 +70,12 @@ static int mmc_resource_init(int sdc_no)
> priv->reg = (struct sunxi_mmc *)SUNXI_MMC2_BASE;
> priv->mclkreg = &ccm->sd2_clk_cfg;
> break;
> +#ifdef SUNXI_MMC3_BASE
> case 3:
> priv->reg = (struct sunxi_mmc *)SUNXI_MMC3_BASE;
> priv->mclkreg = &ccm->sd3_clk_cfg;
> break;
> +#endif
> default:
> printf("Wrong mmc number %d\n", sdc_no);
> return -1;
> @@ -116,6 +118,9 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
> #ifdef CONFIG_MACH_SUN9I
> pll = CCM_MMC_CTRL_PLL_PERIPH0;
> pll_hz = clock_get_pll4_periph0();
> +#elif defined(CONFIG_MACH_SUN50I_H6)
> + pll = CCM_MMC_CTRL_PLL6X2;
> + pll_hz = clock_get_pll6() * 2;
> #else
> pll = CCM_MMC_CTRL_PLL6;
> pll_hz = clock_get_pll6();
> @@ -494,7 +499,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>
> cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
> cfg->host_caps = MMC_MODE_4BIT;
> -#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I)
> +#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I) || defined(CONFIG_MACH_SUN50I_H6)
> if (sdc_no == 2)
> cfg->host_caps = MMC_MODE_8BIT;
> #endif
> @@ -509,6 +514,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>
> /* config ahb clock */
> debug("init mmc %d clock and io\n", sdc_no);
> +#if !defined(CONFIG_MACH_SUN50I_H6)
> setbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_MMC(sdc_no));
>
> #ifdef CONFIG_SUNXI_GEN_SUN6I
> @@ -519,6 +525,11 @@ struct mmc *sunxi_mmc_init(int sdc_no)
> /* sun9i has a mmc-common module, also set the gate and reset there */
> writel(SUNXI_MMC_COMMON_CLK_GATE | SUNXI_MMC_COMMON_RESET,
> SUNXI_MMC_COMMON_BASE + 4 * sdc_no);
> +#endif
> +#else /* CONFIG_MACH_SUN50I_H6 */
> + setbits_le32(&ccm->sd_gate_reset, 1 << sdc_no);
> + /* unassert reset */
> + setbits_le32(&ccm->sd_gate_reset, 1 << (RESET_SHIFT + sdc_no));
> #endif
> ret = mmc_set_mod_clk(priv, 24000000);
> if (ret)
You should use the DM instead.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180724/902ee2ff/attachment.sig>
^ permalink raw reply
* [U-Boot] [RFC PATCH] gpio: zynq: Setup bank_name to dev->name
From: Michal Simek @ 2018-07-24 8:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <589cfccf-dc79-c84f-f147-36a2ac7b4aee@herbrechtsmeier.net>
On 23.7.2018 20:29, Stefan Herbrechtsmeier wrote:
> Hi Michal,
>
>
> Am 23.07.2018 um 11:08 schrieb Michal Simek:
>> On 20.7.2018 21:31, Stefan Herbrechtsmeier wrote:
>>> Am 12.07.2018 um 16:04 schrieb Michal Simek:
>>>> There should be proper bank name setup to distiguish between different
>>>> gpio drivers. Use dev->name for it.
>>>>
>>>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>>>> ---
>>>>
>>>> drivers/gpio/zynq_gpio.c | 2 ++
>>>> 1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/drivers/gpio/zynq_gpio.c b/drivers/gpio/zynq_gpio.c
>>>> index 26f69b1a713f..f793ee5754a8 100644
>>>> --- a/drivers/gpio/zynq_gpio.c
>>>> +++ b/drivers/gpio/zynq_gpio.c
>>>> @@ -337,6 +337,8 @@ static int zynq_gpio_probe(struct udevice *dev)
>>>> struct zynq_gpio_privdata *priv = dev_get_priv(dev);
>>>> struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
>>>> + uc_priv->bank_name = dev->name;
>>>> +
>>>> if (priv->p_data)
>>>> uc_priv->gpio_count = priv->p_data->ngpio;
>>>>
>>> Does this not lead to ugly names because the gpio number is append to
>>> the bank_name? Have you check the "gpio status -a" output?
>> Yes I was checking it. Names are composed together but also just numbers
>> works as before.
>>
>> gpio at ff0a00000: input: 0 [ ]
>> gpio at ff0a00001: input: 0 [ ]
>> gpio at ff0a00002: input: 0 [ ]
>> gpio at ff0a00003: input: 0 [ ]
>> gpio at ff0a00004: input: 0 [ ]
>> gpio at ff0a00005: input: 0 [ ]
>> gpio at ff0a00006: input: 0 [ ]
>> gpio at ff0a00007: input: 0 [ ]
>> gpio at ff0a00008: input: 0 [ ]
>> gpio at ff0a00009: input: 0 [ ]
>
> Do you think that this are meaningful names? It isn't possible to
> separate the device and pin number as well as it mix hex and decimal
> numbers.
>
>> If you know better way how to setup a bank name please let me know but I
>> need to distinguish ps gpio from pl one and for pl we need to know the
>> address.
>
> I know the use case.
>
> A lot of drivers use the bank_name from the device tree, some drivers
> append an underscore to the bank name and others add the req_seq of the
> device to an alphabetic character.
>
>>> Other drivers use the gpio-bank-name from the device tree.
>> I can't see this property inside Linux kernel. If this has been reviewed
>> by dt guys please let me know.
>
> This property is only used by u-boot. I think it isn't needed by the
> Linux kernel.
I am happy to use consistent solution but what's that?
Mixing name with hex and int is not nice but adding "_" or something
else is just a pain in driver code. If this is done in core I am fine
with that but adding this code to all drivers don't look like generic
solution at all.
Using additional u-boot property is not good too.
I have mentioned in "gpio: xilinx: Convert driver to DM"
(sha1:10441ec9224d0d269dc512819a32c0785a6338d3)
that uc-priv->name is completely unused. Maybe this should be dev->name
and bank_name should be really used for banks.
Then in gpio status -a can be
Device gpio at a0001000:
Bank:
...
but not sure how gpio commands will work to address exact pin from
prompt. Because this is normally working
gpio toggle gpio at a00010001
Thanks,
Michal
^ permalink raw reply
* [U-Boot] [PATCH v2 09/13] sunxi: add UART0 setup for H6
From: Maxime Ripard @ 2018-07-24 8:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180721082032.39980-10-icenowy@aosc.io>
On Sat, Jul 21, 2018 at 04:20:28PM +0800, Icenowy Zheng wrote:
> The UART0 on H6 is available at PH bank (and PF bank, but the PF one is
> muxed with SD card).
>
> Add pinmux configuration.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180724/cd521a75/attachment.sig>
^ permalink raw reply
* [U-Boot] [PATCH v2 05/13] sunxi: add config for SPL at 0x20000 on H6
From: Icenowy Zheng @ 2018-07-24 8:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180724083452.5s7egt5zophyrmve@flea>
于 2018年7月24日 GMT+08:00 下午4:34:52, Maxime Ripard <maxime.ripard@bootlin.com> 写到:
>On Sat, Jul 21, 2018 at 04:20:24PM +0800, Icenowy Zheng wrote:
>> On the new Allwinner H6 SoC, the SRAM A2 address (SPL load address)
>is
>> at 0x20000, which is different with any old Allwinner SoCs.
>>
>> Add SPL position and size configuration for this.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> Changes in v2:
>> - Added Andre's Reviewed-by tag.
>>
>> include/configs/sunxi-common.h | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/include/configs/sunxi-common.h
>b/include/configs/sunxi-common.h
>> index 1b5daa8928..4db770d69d 100644
>> --- a/include/configs/sunxi-common.h
>> +++ b/include/configs/sunxi-common.h
>> @@ -199,6 +199,11 @@
>> #else
>> #define LOW_LEVEL_SRAM_STACK 0x00018000
>> #endif /* !CONFIG_ARM64 */
>> +#elif CONFIG_SUNXI_SRAM_ADDRESS == 0x20000
>> +#define CONFIG_SPL_TEXT_BASE 0x20060 /* sram start+header */
>> +#define CONFIG_SPL_MAX_SIZE 0x7fa0 /* 32 KiB */
>> +/* end of SRAM A2 on H6 for now */
>> +#define LOW_LEVEL_SRAM_STACK 0x00118000
>
>Can't we move those options to Kconfig, and deal with those changes
>there instead?
It's possible, but not any cleaner.
It will still be a hugh set of default xxx if xxx.
>
>Maxime
^ permalink raw reply
* [U-Boot] [PATCH v2 08/13] sunxi: use sun6i-style watchdog for H6
From: Maxime Ripard @ 2018-07-24 8:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20180721082032.39980-9-icenowy@aosc.io>
On Sat, Jul 21, 2018 at 04:20:27PM +0800, Icenowy Zheng wrote:
> The H6 SoC has a sun6i-style watchdog in its timer part.
>
> Enable the usage of it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180724/56b27ff1/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox