[U-Boot] [PATCH v2 11/11] dm: sunxi: Use driver model for Ethernet on Linksprite pcDuino3
Switch this board over to use driver model for Ethernet. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Drop bugfix patches that were incorporated in the Ethernet dm conversion - Drop the CONFIG_BOOTP_VCI_STRING patch configs/Linksprite_pcDuino3_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/Linksprite_pcDuino3_defconfig b/configs/Linksprite_pcDuino3_defconfig index 8c76a736..e5aabdb 100644 --- a/configs/Linksprite_pcDuino3_defconfig +++ b/configs/Linksprite_pcDuino3_defconfig @@ -17,3 +17,4 @@ CONFIG_OF_SEPARATE=y CONFIG_ETH_DESIGNWARE=y CONFIG_NETDEVICES=y CONFIG_NET=y +CONFIG_DM_ETH=y -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 07/11] dm: net: Adjust PHY interface to work with CONFIG_DM_ETH
When driver model is used for Ethernet a few functions are passed a udevice
instead of an eth_device. Also add a function to find a PHY type given its
name. This will be used to decode the device tree node.
Finally, put a phy_interface field in struct eth_pdata since this is an
important part of the platform data for Ethernet.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v2: None
common/miiphyutil.c | 1 +
drivers/net/phy/phy.c | 22 ++
include/net.h | 2 ++
include/phy.h | 23 ++-
4 files changed, 47 insertions(+), 1 deletion(-)
diff --git a/common/miiphyutil.c b/common/miiphyutil.c
index 74812e6..c88c28a 100644
--- a/common/miiphyutil.c
+++ b/common/miiphyutil.c
@@ -11,6 +11,7 @@
*/
#include common.h
+#include dm.h
#include miiphy.h
#include phy.h
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index df7e945..9d88afe 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -11,6 +11,7 @@
#include config.h
#include common.h
+#include dm.h
#include malloc.h
#include net.h
#include command.h
@@ -754,7 +755,11 @@ struct phy_device *phy_find_by_mask(struct mii_dev *bus,
unsigned phy_mask,
return get_phy_device_by_mask(bus, phy_mask, interface);
}
+#ifdef CONFIG_DM_ETH
+void phy_connect_dev(struct phy_device *phydev, struct udevice *dev)
+#else
void phy_connect_dev(struct phy_device *phydev, struct eth_device *dev)
+#endif
{
/* Soft Reset the PHY */
phy_reset(phydev);
@@ -767,8 +772,13 @@ void phy_connect_dev(struct phy_device *phydev, struct
eth_device *dev)
debug(%s connected to %s\n, dev-name, phydev-drv-name);
}
+#ifdef CONFIG_DM_ETH
+struct phy_device *phy_connect(struct mii_dev *bus, int addr,
+ struct udevice *dev, phy_interface_t interface)
+#else
struct phy_device *phy_connect(struct mii_dev *bus, int addr,
struct eth_device *dev, phy_interface_t interface)
+#endif
{
struct phy_device *phydev;
@@ -813,3 +823,15 @@ int phy_shutdown(struct phy_device *phydev)
return 0;
}
+
+int phy_get_interface_by_name(const char *str)
+{
+ int i;
+
+ for (i = 0; i PHY_INTERFACE_MODE_COUNT; i++) {
+ if (!strcmp(str, phy_interface_strings[i]))
+ return i;
+ }
+
+ return -1;
+}
diff --git a/include/net.h b/include/net.h
index f9df532..2b4f9f3 100644
--- a/include/net.h
+++ b/include/net.h
@@ -84,10 +84,12 @@ enum eth_state_t {
*
* @iobase: The base address of the hardware registers
* @enetaddr: The Ethernet MAC address that is loaded from EEPROM or env
+ * @phy_interface: PHY interface to use - see PHY_INTERFACE_MODE_...
*/
struct eth_pdata {
phys_addr_t iobase;
unsigned char enetaddr[6];
+ int phy_interface;
};
/**
diff --git a/include/phy.h b/include/phy.h
index d117fc1..384dc23 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -51,7 +51,9 @@ typedef enum {
PHY_INTERFACE_MODE_RGMII_TXID,
PHY_INTERFACE_MODE_RTBI,
PHY_INTERFACE_MODE_XGMII,
- PHY_INTERFACE_MODE_NONE /* Must be last */
+ PHY_INTERFACE_MODE_NONE,/* Must be last */
+
+ PHY_INTERFACE_MODE_COUNT,
} phy_interface_t;
static const char *phy_interface_strings[] = {
@@ -142,7 +144,11 @@ struct phy_device {
struct phy_driver *drv;
void *priv;
+#ifdef CONFIG_DM_ETH
+ struct udevice *dev;
+#else
struct eth_device *dev;
+#endif
/* forced speed duplex (no autoneg)
* partner speed duplex pause (autoneg)
@@ -205,10 +211,17 @@ int phy_init(void);
int phy_reset(struct phy_device *phydev);
struct phy_device *phy_find_by_mask(struct mii_dev *bus, unsigned phy_mask,
phy_interface_t interface);
+#ifdef CONFIG_DM_ETH
+void phy_connect_dev(struct phy_device *phydev, struct udevice *dev);
+struct phy_device *phy_connect(struct mii_dev *bus, int addr,
+ struct udevice *dev,
+ phy_interface_t interface);
+#else
void phy_connect_dev(struct phy_device *phydev, struct eth_device *dev);
struct phy_device *phy_connect(struct mii_dev *bus, int addr,
struct eth_device *dev,
phy_interface_t interface);
+#endif
int phy_startup(struct phy_device *phydev);
int phy_config(struct phy_device *phydev);
int phy_shutdown(struct phy_device *phydev);
@@ -242,6 +255,14 @@ int phy_vitesse_init(void);
int board_phy_config(struct phy_device *phydev);
+/**
+ * phy_get_interface_by_name() - Look up a PHY interface name
+ *
+ * @str: PHY interface name, e.g. mii
+ * @return PHY_INTERFACE_MODE_... value, or -1 if not found
+ */
+int phy_get_interface_by_name(const char *str);
+
/* PHY UIDs for various PHYs that are referenced in external code */
#define PHY_UID_CS4340 0x13e51002
#define
Re: [U-Boot] [PATCH] fdt: Pass the board serial number through devicetree
Hi Simon, thanks for the review,
Le dimanche 05 avril 2015 à 12:31 -0600, Simon Glass a écrit :
Hi Paul,
On 28 March 2015 at 11:34, Paul Kocialkowski cont...@paulk.fr wrote:
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
common/fdt_support.c | 25 +
common/image-fdt.c| 4
include/fdt_support.h | 1 +
3 files changed, 30 insertions(+)
This needs a commit message and something in
doc/device-tree-binding/root.txt (or similar) about it.
Ack
Is there binding documentation for Linux on this?
I have submitted a patch for documenting this in Linux:
Documentation: devicetree: root node serial-number property
documentation
As well as a patch to show that serial number in /proc/cpuinfo:
arch: arm: Show the serial number from devicetree in cpuinfo
Those were not reviewed yet but I'm hoping to get the discussion started
once the kernel merge window opens.
I'm fine with waiting for the kernel part to be accepted before getting
this into U-Boot.
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 8266bca..a97b4f0 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -194,6 +194,31 @@ static inline int fdt_setprop_uxx(void *fdt, int
nodeoffset, const char *name,
return fdt_setprop_u32(fdt, nodeoffset, name,
(uint32_t)val);
}
+int fdt_root(void *fdt)
+{
+ char *serial;
+ int err;
+
+ err = fdt_check_header(fdt);
+ if (err 0) {
+ printf(fdt_root: %s\n, fdt_strerror(err));
+ return err;
+ }
+
+ serial = getenv(serial#);
+ if (serial) {
+ err = fdt_setprop(fdt, 0, serial-number, serial,
+ strlen(serial) + 1);
+
+ if (err 0) {
+ printf(WARNING: could not set serial-number %s.\n,
+ fdt_strerror(err));
+ return err;
+ }
+ }
+
+ return 0;
+}
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end)
{
diff --git a/common/image-fdt.c b/common/image-fdt.c
index d9e4728..1600561 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -470,6 +470,10 @@ int image_setup_libfdt(bootm_headers_t *images, void
*blob,
int ret = -EPERM;
int fdt_ret;
+ if (fdt_root(blob) 0) {
+ printf(ERROR: root node setup failed\n);
+ goto err;
+ }
if (fdt_chosen(blob) 0) {
printf(ERROR: /chosen node create failed\n);
goto err;
diff --git a/include/fdt_support.h b/include/fdt_support.h
index ae5e8a3..8eb5968 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -16,6 +16,7 @@ u32 fdt_getprop_u32_default_node(const void *fdt, int
off, int cell,
const char *prop, const u32 dflt);
u32 fdt_getprop_u32_default(const void *fdt, const char *path,
const char *prop, const u32 dflt);
+int fdt_root(void *fdt);
int fdt_chosen(void *fdt);
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end);
void do_fixup_by_path(void *fdt, const char *path, const char *prop,
--
1.9.1
Regards,
Simon
signature.asc
Description: This is a digitally signed message part
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MAKEALL: fix get_target_arch() to adjust to '-' in Status field
Hi Masahiro, On 5 April 2015 at 21:08, Masahiro Yamada yamada.masah...@socionext.com wrote: Hi Simon, Tom, 2015-04-06 3:31 GMT+09:00 Simon Glass s...@chromium.org: Hi Tom, On 1 April 2015 at 05:19, Tom Rini tr...@konsulko.com wrote: On Tue, Mar 31, 2015 at 08:39:57PM -0600, Simon Glass wrote: Hi Masahiro, On 30 March 2015 at 05:59, Masahiro Yamada yamada.masah...@socionext.com wrote: Since the Kconfig conversion, boards.cfg scanned by MAKEALL is generated by tools/genboardscfg.py. Every board is supposed to have its own MAINTAINERS that contains maintainer and status information, but, in fact, MAINTAINERS is missing from some boards. For such boards, the first field, Status, is filled with '-'. It causes a problem for set command, which ignores '-' in its arguments. Consequently, get_target_arch() returns a wrong field and MAKEALL fails to get a correct toolchain. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com - Improve git description Should we perhaps apply the patch to deprecate MAKEALL? With the last patch I posted about what binaries to save all my usecases are covered now. OK, do you think we can wait until the merge window before doing these? I don't see any great hurry. I know MAKEALL is deprecated, but I still use it with a local-hack to compare MD5SUM. Buildman is a bigger program than MAKEALL and I have not been able to find time to dig into it. The above is my personal reason, but this patch is an apparent bug-fix and it is easy enough. Why don't we fix it? I wan't suggesting we don't fix it! I agree you patch is a good thing - it just jogged my memory about MAKEALL deprecation. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] sunxi: Complete i2c support for each supported platform
Le dimanche 05 avril 2015 à 12:31 -0600, Simon Glass a écrit :
Hi Paul,
On 4 April 2015 at 14:49, Paul Kocialkowski cont...@paulk.fr wrote:
Sunxi platforms come with at least 3 TWI (I2C) controllers and some
platforms
even have up to 5. This adds support for every controller on each supported
platform, which is especially useful when using expansion ports on
single-board-
computers.
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++
arch/arm/include/asm/arch-sunxi/gpio.h | 15 +-
arch/arm/include/asm/arch-sunxi/i2c.h | 13 +
board/sunxi/Kconfig | 31
board/sunxi/board.c | 75
-
5 files changed, 138 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index dae6069..f403742 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -94,6 +94,13 @@
#define SUNXI_TWI0_BASE0x01c2ac00
#define SUNXI_TWI1_BASE0x01c2b000
#define SUNXI_TWI2_BASE0x01c2b400
+#ifdef CONFIG_MACH_SUN6I
+#define SUNXI_TWI3_BASE0x01c0b800
+#endif
+#ifdef CONFIG_MACH_SUN7I
+#define SUNXI_TWI3_BASE0x01c2b800
+#define SUNXI_TWI4_BASE0x01c2c000
+#endif
#define SUNXI_CAN_BASE 0x01c2bc00
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index f227044..ae7cbb7 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -148,7 +148,11 @@ enum sunxi_gpio_number {
#define SUN6I_GPA_SDC2 5
#define SUN6I_GPA_SDC3 4
-#define SUNXI_GPB_TWI0 2
+#define SUN4I_GPB_TWI0 2
+#define SUN4I_GPB_TWI1 2
+#define SUN5I_GPB_TWI1 2
+#define SUN4I_GPB_TWI2 2
+#define SUN5I_GPB_TWI2 2
#define SUN4I_GPB_UART02
#define SUN5I_GPB_UART02
@@ -160,6 +164,7 @@ enum sunxi_gpio_number {
#define SUNXI_GPD_LVDS03
#define SUN5I_GPE_SDC2 3
+#define SUN8I_GPE_TWI2 3
#define SUNXI_GPF_SDC0 2
#define SUNXI_GPF_UART04
@@ -169,12 +174,20 @@ enum sunxi_gpio_number {
#define SUN5I_GPG_SDC1 2
#define SUN6I_GPG_SDC1 2
#define SUN8I_GPG_SDC1 2
+#define SUN6I_GPG_TWI3 2
#define SUN5I_GPG_UART14
#define SUN4I_GPH_SDC1 5
+#define SUN6I_GPH_TWI0 2
+#define SUN8I_GPH_TWI0 2
+#define SUN6I_GPH_TWI1 2
+#define SUN8I_GPH_TWI1 2
+#define SUN6I_GPH_TWI2 2
#define SUN6I_GPH_UART02
#define SUNXI_GPI_SDC3 2
+#define SUN7I_GPI_TWI3 3
+#define SUN7I_GPI_TWI4 3
#define SUN6I_GPL0_R_P2WI_SCK 3
#define SUN6I_GPL1_R_P2WI_SDA 3
diff --git a/arch/arm/include/asm/arch-sunxi/i2c.h
b/arch/arm/include/asm/arch-sunxi/i2c.h
index 502e3c6..5e9586f 100644
--- a/arch/arm/include/asm/arch-sunxi/i2c.h
+++ b/arch/arm/include/asm/arch-sunxi/i2c.h
@@ -9,6 +9,19 @@
#include asm/arch/cpu.h
#define CONFIG_I2C_MVTWSI_BASE0SUNXI_TWI0_BASE
+#ifdef CONFIG_I2C1_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE1SUNXI_TWI1_BASE
+#endif
+#ifdef CONFIG_I2C2_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE2SUNXI_TWI2_BASE
+#endif
+#ifdef CONFIG_I2C3_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE3SUNXI_TWI3_BASE
+#endif
+#ifdef CONFIG_I2C4_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE4SUNXI_TWI4_BASE
+#endif
+
/* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is
24MHz */
#define CONFIG_SYS_TCLK2400
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index ccc2080..d3b5bad 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -269,6 +269,37 @@ config USB2_VBUS_PIN
---help---
See USB1_VBUS_PIN help text.
+config I2C1_ENABLE
+ bool Enable I2C/TWI controller 1
+ default n
+ ---help---
+ This allows enabling I2C/TWI controller 1 by muxing its pins,
enabling
+ its clock and setting up the bus. This is especially useful on
devices
+ with slaves connected to the bus or with pins exposed through e.g.
an
+ expansion port/header.
+
+config I2C2_ENABLE
+ bool Enable I2C/TWI controller 2
+ default n
+ ---help---
+ See I2C1_ENABLE help text.
+
+if MACH_SUN6I || MACH_SUN7I
+config I2C3_ENABLE
+ bool Enable I2C/TWI controller 3
+ default n
+ ---help---
+ See
Re: [U-Boot] [PATCH v3 0/3] i2c: sunxi: Support every i2c controller on each supported platform
Hi Hans, Le dimanche 05 avril 2015 à 10:44 +0200, Hans de Goede a écrit : Hi, On 05-04-15 09:51, Paul Kocialkowski wrote: Changes since v2: * I2C/TWI busses enable for Cubietruck as well Changes since v1: * Kconfig option to enable I2C/TWI controllers 1-4 (when applicable) * Following patch to enable exposed busses on a few community-supported single-board-computers This series adds support for every i2c controller found on sun4i/sun5i/sun6i/sun7i/sun8i platforms and shouldn't break support for Marvell platforms (orion5x, kirkwood, armada xp) the driver was originally written for. Regarding sunxi, I double-checked that this doesn't conflict with VIDEO_LCD_PANEL_I2C. I would be interested in having this tested on sun8i (A23), since I changed TWI0 muxing (to PH2-PH3 instead of PB0-PB1), according to the user manual and what is being done on the upstream Linux kernel. I2C was either not working before, or it was being muxed correctly by the bootrom, probably to communicate with the AXP, which luckily made it work in U-Boot too, since the I/O base address was already correct. My use case here is that I'm writing a slave-side bitbang i2c implementation (with an Arduino) for a school project, using a Cubieboard2 as master and U-Boot as POC. However, only TWI1 was available through the expansion pins, hence the need for this series. Thanks for your work on this, may I request one more change ? For sunxi I would like to also see a CONFIG_I2C0_ENABLE, the reason for this is that on sun6i / sun8i we do not really use i2c0 as we use p2wi resp. rsb to talk to the axp pmic there. This way we will not end up messing with the muxing of the PH14/15 (sun6i) resp. PH2/3 (sun8i) which may be used in some other fashion. This also means making a small change to the first patch to also make registering of twsi0 #ifdef CONFIG_I2C_MVTWSI_BASE0 . Can you please make the default for CONFIG_I2C0_ENABLE y on sun4i / sun5i / sun7i and n on others? Ack that, it makes sense to me. Also I'm not entirely convinced that patch 3/3 is a good idea, on the olimex boards which have a i2c eeprom enabling the attached i2c controller makes sense, but on the other boards the i2c pins are really just gpio pins, any daughter board can be connected including one which uses them differently. I believe that in the defconfig the i2c controllers should thus be left off. It is after all a default config, users with a daughter board which they want to use in u-boot can easily change the config after running make foo_defconfig. I think the right bargain here would be to enable i2c lines that already have something useful for U-Boot attached (e.g. not an accelerometer sensor). I concur to your point otherwise. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Pass the board serial number through devicetree
Hi Paul, On 5 April 2015 at 14:49, Paul Kocialkowski cont...@paulk.fr wrote: Hi Simon, thanks for the review, Le dimanche 05 avril 2015 à 12:31 -0600, Simon Glass a écrit : Hi Paul, On 28 March 2015 at 11:34, Paul Kocialkowski cont...@paulk.fr wrote: Signed-off-by: Paul Kocialkowski cont...@paulk.fr --- common/fdt_support.c | 25 + common/image-fdt.c| 4 include/fdt_support.h | 1 + 3 files changed, 30 insertions(+) This needs a commit message and something in doc/device-tree-binding/root.txt (or similar) about it. Ack Is there binding documentation for Linux on this? I have submitted a patch for documenting this in Linux: Documentation: devicetree: root node serial-number property documentation As well as a patch to show that serial number in /proc/cpuinfo: arch: arm: Show the serial number from devicetree in cpuinfo Those were not reviewed yet but I'm hoping to get the discussion started once the kernel merge window opens. I'm fine with waiting for the kernel part to be accepted before getting this into U-Boot. OK. [snip] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] MAKEALL: fix get_target_arch() to adjust to '-' in Status field
Hi Simon, Tom, 2015-04-06 3:31 GMT+09:00 Simon Glass s...@chromium.org: Hi Tom, On 1 April 2015 at 05:19, Tom Rini tr...@konsulko.com wrote: On Tue, Mar 31, 2015 at 08:39:57PM -0600, Simon Glass wrote: Hi Masahiro, On 30 March 2015 at 05:59, Masahiro Yamada yamada.masah...@socionext.com wrote: Since the Kconfig conversion, boards.cfg scanned by MAKEALL is generated by tools/genboardscfg.py. Every board is supposed to have its own MAINTAINERS that contains maintainer and status information, but, in fact, MAINTAINERS is missing from some boards. For such boards, the first field, Status, is filled with '-'. It causes a problem for set command, which ignores '-' in its arguments. Consequently, get_target_arch() returns a wrong field and MAKEALL fails to get a correct toolchain. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com - Improve git description Should we perhaps apply the patch to deprecate MAKEALL? With the last patch I posted about what binaries to save all my usecases are covered now. OK, do you think we can wait until the merge window before doing these? I don't see any great hurry. I know MAKEALL is deprecated, but I still use it with a local-hack to compare MD5SUM. Buildman is a bigger program than MAKEALL and I have not been able to find time to dig into it. The above is my personal reason, but this patch is an apparent bug-fix and it is easy enough. Why don't we fix it? -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] sunxi: Complete i2c support for each supported platform
Hi Paul,
On 5 April 2015 at 14:56, Paul Kocialkowski cont...@paulk.fr wrote:
Le dimanche 05 avril 2015 à 12:31 -0600, Simon Glass a écrit :
Hi Paul,
On 4 April 2015 at 14:49, Paul Kocialkowski cont...@paulk.fr wrote:
Sunxi platforms come with at least 3 TWI (I2C) controllers and some
platforms
even have up to 5. This adds support for every controller on each supported
platform, which is especially useful when using expansion ports on
single-board-
computers.
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++
arch/arm/include/asm/arch-sunxi/gpio.h | 15 +-
arch/arm/include/asm/arch-sunxi/i2c.h | 13 +
board/sunxi/Kconfig | 31
board/sunxi/board.c | 75
-
5 files changed, 138 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index dae6069..f403742 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -94,6 +94,13 @@
#define SUNXI_TWI0_BASE0x01c2ac00
#define SUNXI_TWI1_BASE0x01c2b000
#define SUNXI_TWI2_BASE0x01c2b400
+#ifdef CONFIG_MACH_SUN6I
+#define SUNXI_TWI3_BASE0x01c0b800
+#endif
+#ifdef CONFIG_MACH_SUN7I
+#define SUNXI_TWI3_BASE0x01c2b800
+#define SUNXI_TWI4_BASE0x01c2c000
+#endif
#define SUNXI_CAN_BASE 0x01c2bc00
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index f227044..ae7cbb7 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -148,7 +148,11 @@ enum sunxi_gpio_number {
#define SUN6I_GPA_SDC2 5
#define SUN6I_GPA_SDC3 4
-#define SUNXI_GPB_TWI0 2
+#define SUN4I_GPB_TWI0 2
+#define SUN4I_GPB_TWI1 2
+#define SUN5I_GPB_TWI1 2
+#define SUN4I_GPB_TWI2 2
+#define SUN5I_GPB_TWI2 2
#define SUN4I_GPB_UART02
#define SUN5I_GPB_UART02
@@ -160,6 +164,7 @@ enum sunxi_gpio_number {
#define SUNXI_GPD_LVDS03
#define SUN5I_GPE_SDC2 3
+#define SUN8I_GPE_TWI2 3
#define SUNXI_GPF_SDC0 2
#define SUNXI_GPF_UART04
@@ -169,12 +174,20 @@ enum sunxi_gpio_number {
#define SUN5I_GPG_SDC1 2
#define SUN6I_GPG_SDC1 2
#define SUN8I_GPG_SDC1 2
+#define SUN6I_GPG_TWI3 2
#define SUN5I_GPG_UART14
#define SUN4I_GPH_SDC1 5
+#define SUN6I_GPH_TWI0 2
+#define SUN8I_GPH_TWI0 2
+#define SUN6I_GPH_TWI1 2
+#define SUN8I_GPH_TWI1 2
+#define SUN6I_GPH_TWI2 2
#define SUN6I_GPH_UART02
#define SUNXI_GPI_SDC3 2
+#define SUN7I_GPI_TWI3 3
+#define SUN7I_GPI_TWI4 3
#define SUN6I_GPL0_R_P2WI_SCK 3
#define SUN6I_GPL1_R_P2WI_SDA 3
diff --git a/arch/arm/include/asm/arch-sunxi/i2c.h
b/arch/arm/include/asm/arch-sunxi/i2c.h
index 502e3c6..5e9586f 100644
--- a/arch/arm/include/asm/arch-sunxi/i2c.h
+++ b/arch/arm/include/asm/arch-sunxi/i2c.h
@@ -9,6 +9,19 @@
#include asm/arch/cpu.h
#define CONFIG_I2C_MVTWSI_BASE0SUNXI_TWI0_BASE
+#ifdef CONFIG_I2C1_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE1SUNXI_TWI1_BASE
+#endif
+#ifdef CONFIG_I2C2_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE2SUNXI_TWI2_BASE
+#endif
+#ifdef CONFIG_I2C3_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE3SUNXI_TWI3_BASE
+#endif
+#ifdef CONFIG_I2C4_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE4SUNXI_TWI4_BASE
+#endif
+
/* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is
24MHz */
#define CONFIG_SYS_TCLK2400
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index ccc2080..d3b5bad 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -269,6 +269,37 @@ config USB2_VBUS_PIN
---help---
See USB1_VBUS_PIN help text.
+config I2C1_ENABLE
+ bool Enable I2C/TWI controller 1
+ default n
+ ---help---
+ This allows enabling I2C/TWI controller 1 by muxing its pins,
enabling
+ its clock and setting up the bus. This is especially useful on
devices
+ with slaves connected to the bus or with pins exposed through e.g.
an
+ expansion port/header.
+
+config I2C2_ENABLE
+ bool Enable I2C/TWI controller 2
+ default n
+ ---help---
+ See I2C1_ENABLE help text.
+
+if MACH_SUN6I || MACH_SUN7I
+config I2C3_ENABLE
+ bool Enable I2C/TWI
Re: [U-Boot] [PATCH 08/12] ARM: socfpga: use select instead of default value in defconfig
Hi Pavel, 2015-04-02 21:47 GMT+09:00 Pavel Machek pa...@denx.de: Hi! Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- arch/arm/Kconfig | 6 ++ configs/socfpga_arria5_defconfig | 3 --- configs/socfpga_cyclone5_defconfig | 3 --- configs/socfpga_socrates_defconfig | 3 --- 4 files changed, 6 insertions(+), 9 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index b25a4a9..6ae48c6 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -618,11 +618,17 @@ config TARGET_SOCFPGA_ARRIA5 bool Support socfpga_arria5 select CPU_V7 select SUPPORT_SPL + select DM + select DM_SPI_FLASH + select DM_SPI Are you sure? Yes, I'm sure. config DM_SPI_FLASH bool Enable Driver Model for SPI flash depends on DM SPI help DM_SPI_FLASH depends on SPI, you can't just select it... This dependency is wrong. Before this patch, it must be fixed. Please see 01/12 of this series: http://patchwork.ozlabs.org/patch/456458/ But I'm not sure. With this, you made CONFIG_DM_SPI_FLASH mandatory... even for users that have no SPI flash. There must be better solution...? In my opinion, CONFIG_DM_* should be user-unconfigurable. CONFIG_DM_* should not enable/disable a feature, but should define how it is implemented. For example, !defined(CONFIG_SPI) -- SPI is disabled defined(CONFIG_SPI) defined(CONFIG_DM_SPI) -- Driver Model SPI is enabled defined(CONFIG_SPI) !defined(CONFIG_DM_SPI) -- ad-hoc SPI is enabled Likewise, I think CONFIG_SPI_FLASH should decide if the system has SPI flash. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/11] dm: net: Conversion patches for sunxi driver model Ethernet
This series enables driver model Ethernet for the pcDuino3, converting the designware Ethernet MAC in the process. It also moves all sunxi board to use Kconfig for their basic Ethernet settings. This series is based on u-boot-dm/next and requires Joe's patch here: http://patchwork.ozlabs.org/patch/458111/ It is available at u-boot-dm in branch net-working. Changes in v2: - Add Ethernet for Orangepi, galileo - Add Ethernet for Orangepi_mini, Wits_Pro_A20_DKT, Mele_I7 - Drop bugfix patches that were incorporated in the Ethernet dm conversion - Drop the CONFIG_BOOTP_VCI_STRING patch - Rebase on dm/next - Remove unwanted printf() - Use the new recv() method and the free_pkt() method Simon Glass (11): sunxi: Replace the pcDuino3 config with FDT version Kconfig: Move CONFIG_DESIGNWARE_ETH to Kconfig dts: sunxi: Bring in Ethernet device tree bindings dm: core: Support allocating driver-private data for DMA dm: net: Use existing Ethernet init for driver model Avoid calling print_eths() with driver model dm: net: Adjust PHY interface to work with CONFIG_DM_ETH dm: net: Tidy up designware driver ready for driver model dm: net: Adjust designware driver to support driver model dm: sunxi: Support driver model for Ethernet dm: sunxi: Use driver model for Ethernet on Linksprite pcDuino3 arch/arm/cpu/arm926ejs/spear/cpu.c | 2 +- arch/arm/cpu/armv7/socfpga/misc.c | 2 +- board/bf609-ezkit/bf609-ezkit.c| 2 +- board/spear/spear300/spear300.c| 2 +- board/spear/spear310/spear310.c| 2 +- board/spear/spear320/spear320.c| 2 +- board/spear/spear600/spear600.c| 2 +- board/st/stv0991/stv0991.c | 2 +- board/sunxi/gmac.c | 10 +- common/cmd_bdinfo.c| 2 +- common/miiphyutil.c| 1 + configs/A20-OLinuXino-Lime2_defconfig | 3 + configs/A20-OLinuXino-Lime_defconfig | 3 + configs/A20-OLinuXino_MICRO_defconfig | 3 + configs/Bananapi_defconfig | 3 + configs/Bananapro_defconfig| 3 + configs/CSQ_CS908_defconfig| 3 + configs/Colombus_defconfig | 3 + configs/Cubieboard2_defconfig | 3 + configs/Cubietruck_defconfig | 3 + configs/Hummingbird_A31_defconfig | 3 + configs/Linksprite_pcDuino3_Nano_defconfig | 3 + configs/Linksprite_pcDuino3_defconfig | 11 + configs/Linksprite_pcDuino3_fdt_defconfig | 15 -- configs/Mele_I7_defconfig | 3 + configs/Mele_M3_defconfig | 3 + configs/Mele_M5_defconfig | 3 + configs/Mele_M9_defconfig | 3 + configs/Orangepi_defconfig | 3 + configs/Orangepi_mini_defconfig| 3 + configs/Wits_Pro_A20_DKT_defconfig | 3 + configs/axs101_defconfig | 5 +- configs/axs103_defconfig | 3 + configs/bf609-ezkit_defconfig | 3 + configs/galileo_defconfig | 3 + configs/i12-tvbox_defconfig| 3 + configs/socfpga_cyclone5_defconfig | 3 + configs/socfpga_socrates_defconfig | 3 + configs/spear300_defconfig | 3 + configs/spear300_nand_defconfig| 3 + configs/spear300_usbtty_defconfig | 3 + configs/spear300_usbtty_nand_defconfig | 3 + configs/spear310_defconfig | 3 + configs/spear310_nand_defconfig| 3 + configs/spear310_pnor_defconfig| 3 + configs/spear310_usbtty_defconfig | 3 + configs/spear310_usbtty_nand_defconfig | 3 + configs/spear310_usbtty_pnor_defconfig | 3 + configs/spear320_defconfig | 3 + configs/spear320_nand_defconfig| 3 + configs/spear320_pnor_defconfig| 3 + configs/spear320_usbtty_defconfig | 3 + configs/spear320_usbtty_nand_defconfig | 3 + configs/spear320_usbtty_pnor_defconfig | 3 + configs/spear600_defconfig | 3 + configs/spear600_nand_defconfig| 3 + configs/spear600_usbtty_defconfig | 3 + configs/spear600_usbtty_nand_defconfig | 3 + configs/stv0991_defconfig | 3 + configs/tb100_defconfig| 3 + configs/x600_defconfig | 3 +
[U-Boot] [PATCH v2 01/11] sunxi: Replace the pcDuino3 config with FDT version
We currently have Linksprite_pcDuino3 and Linksprite_pcDuino3_fdt. Drop the former in favour of the latter. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk --- Changes in v2: - Rebase on dm/next configs/Linksprite_pcDuino3_defconfig | 7 +++ configs/Linksprite_pcDuino3_fdt_defconfig | 15 --- 2 files changed, 7 insertions(+), 15 deletions(-) delete mode 100644 configs/Linksprite_pcDuino3_fdt_defconfig diff --git a/configs/Linksprite_pcDuino3_defconfig b/configs/Linksprite_pcDuino3_defconfig index e642069..ff817d5 100644 --- a/configs/Linksprite_pcDuino3_defconfig +++ b/configs/Linksprite_pcDuino3_defconfig @@ -7,3 +7,10 @@ CONFIG_MACH_SUN7I=y CONFIG_DRAM_CLK=480 CONFIG_DRAM_ZQ=122 CONFIG_DRAM_EMR1=4 +CONFIG_DM=y +CONFIG_DM_GPIO=y +CONFIG_DM_SERIAL=y +CONFIG_DEFAULT_DEVICE_TREE=sun7i-a20-pcduino3 +CONFIG_OF_CONTROL=y +CONFIG_SPL_DISABLE_OF_CONTROL=y +CONFIG_OF_SEPARATE=y diff --git a/configs/Linksprite_pcDuino3_fdt_defconfig b/configs/Linksprite_pcDuino3_fdt_defconfig deleted file mode 100644 index 7690d1e..000 --- a/configs/Linksprite_pcDuino3_fdt_defconfig +++ /dev/null @@ -1,15 +0,0 @@ -CONFIG_SPL=y -CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPH(2),USB_EHCI -CONFIG_FDTFILE=sun7i-a20-pcduino3.dtb -CONFIG_DM=y -CONFIG_DM_GPIO=y -CONFIG_DM_SERIAL=y -CONFIG_DEFAULT_DEVICE_TREE=sun7i-a20-pcduino3 -CONFIG_OF_CONTROL=y -CONFIG_OF_SEPARATE=y -CONFIG_ARM=y -CONFIG_ARCH_SUNXI=y -CONFIG_MACH_SUN7I=y -CONFIG_DRAM_CLK=480 -CONFIG_DRAM_ZQ=122 -CONFIG_DRAM_EMR1=4 -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/11] dm: core: Support allocating driver-private data for DMA
Some driver want to put DMA buffers in their private data. Add a flag
to tell driver model to align driver-private data to a cache boundary so
that DMA will work correctly in this case.
Signed-off-by: Simon Glass s...@chromium.org
---
This patch can be dropped once this one is applied:
http://patchwork.ozlabs.org/patch/454670/
Changes in v2: None
drivers/core/device.c | 11 ++-
include/dm/device.h | 3 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 7483405..872b703 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -182,7 +182,16 @@ int device_probe_child(struct udevice *dev, void
*parent_priv)
/* Allocate private data if requested */
if (drv-priv_auto_alloc_size) {
- dev-priv = calloc(1, drv-priv_auto_alloc_size);
+ if (drv-flags DM_FLAG_ALLOC_PRIV_DMA) {
+ dev-priv = memalign(ARCH_DMA_MINALIGN,
+drv-priv_auto_alloc_size);
+ if (dev-priv) {
+ memset(dev-priv, '\0',
+ drv-priv_auto_alloc_size);
+ }
+ } else {
+ dev-priv = calloc(1, drv-priv_auto_alloc_size);
+ }
if (!dev-priv) {
ret = -ENOMEM;
goto fail;
diff --git a/include/dm/device.h b/include/dm/device.h
index 6980954..f27b34b 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -30,6 +30,9 @@ struct driver_info;
/* DM is responsible for allocating and freeing parent_platdata */
#define DM_FLAG_ALLOC_PARENT_PDATA (1 3)
+/* Allocate driver private data on a DMA boundary */
+#define DM_FLAG_ALLOC_PRIV_DMA (1 4)
+
/**
* struct udevice - An instance of a driver
*
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/80] dm: Add USB support
Hi Marek, On 26 March 2015 at 13:40, Marek Vasut ma...@denx.de wrote: On Wednesday, March 25, 2015 at 07:21:48 PM, Simon Glass wrote: This series adds driver model support to USB. The intent is to permit the various subsystems (OHCI, EHCI, XHCI) to co-exist and allow any number of USB ports of different types. With the RFC series, only USB controllers had a real driver model device. USB devices (including the hub in the controller) were not modelled as driver model devices. While this was expedient, and produced much fewer patches, it is not a long-term solution. Also, since then, driver model Ethernet support (which USB can use) has been merged to u-boot-dm/next. It seems better to bite the bullet and do a full conversion. Whew. Reviewed-by: Marek Vasut ma...@denx.de Thanks very much for working through these! Unless there are other comments I plan to apply this to u-boot-dm/next in the next few days. I expect it will need some tweaking as boards are moved over too. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] MAKEALL: fix get_target_arch() to adjust to '-' in Status field
Since the Kconfig conversion, boards.cfg scanned by MAKEALL is
generated by tools/genboardscfg.py. Every board is supposed to have
its own MAINTAINERS that contains maintainer and status information,
but, in fact, MAINTAINERS is missing from some boards.
For such boards, the first field, Status, is filled with '-'.
It causes a problem for set command, which ignores '-' in its
arguments. Consequently, get_target_arch() returns a wrong field
and MAKEALL fails to get a correct toolchain.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
Changes in v3:
- Fix commit description
Changes in v2:
- Improve git description
MAKEALL | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index cd3b6c7..3808a59 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -551,13 +551,7 @@ get_target_maintainers() {
get_target_arch() {
local target=$1
- # Automatic mode
- local line=`awk '\$7 == '$target' { print \$0 }' boards.cfg`
-
- if [ -z ${line} ] ; then echo ; return ; fi
-
- set ${line}
- echo $2
+ awk '$7 == '$target' { print $2 }' boards.cfg
}
list_target() {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 02/11] Kconfig: Move CONFIG_DESIGNWARE_ETH to Kconfig
Move this to Kconfig and clean up board config files that use it. Also
rename it to CONFIG_ETH_DESIGNWARE to fit with the naming that exists
in drivers/net/Kconfig.
Signed-off-by: Simon Glass s...@chromium.org
Version 1:
Acked-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v2:
- Add Ethernet for Orangepi, galileo
- Add Ethernet for Orangepi_mini, Wits_Pro_A20_DKT, Mele_I7
- Rebase on dm/next
arch/arm/cpu/arm926ejs/spear/cpu.c | 2 +-
arch/arm/cpu/armv7/socfpga/misc.c | 2 +-
board/bf609-ezkit/bf609-ezkit.c| 2 +-
board/spear/spear300/spear300.c| 2 +-
board/spear/spear310/spear310.c| 2 +-
board/spear/spear320/spear320.c| 2 +-
board/spear/spear600/spear600.c| 2 +-
board/st/stv0991/stv0991.c | 2 +-
configs/A20-OLinuXino-Lime2_defconfig | 3 +++
configs/A20-OLinuXino-Lime_defconfig | 3 +++
configs/A20-OLinuXino_MICRO_defconfig | 3 +++
configs/Bananapi_defconfig | 3 +++
configs/Bananapro_defconfig| 3 +++
configs/CSQ_CS908_defconfig| 3 +++
configs/Colombus_defconfig | 3 +++
configs/Cubieboard2_defconfig | 3 +++
configs/Cubietruck_defconfig | 3 +++
configs/Hummingbird_A31_defconfig | 3 +++
configs/Linksprite_pcDuino3_Nano_defconfig | 3 +++
configs/Linksprite_pcDuino3_defconfig | 3 +++
configs/Mele_I7_defconfig | 3 +++
configs/Mele_M3_defconfig | 3 +++
configs/Mele_M5_defconfig | 3 +++
configs/Mele_M9_defconfig | 3 +++
configs/Orangepi_defconfig | 3 +++
configs/Orangepi_mini_defconfig| 3 +++
configs/Wits_Pro_A20_DKT_defconfig | 3 +++
configs/axs101_defconfig | 5 -
configs/axs103_defconfig | 3 +++
configs/bf609-ezkit_defconfig | 3 +++
configs/galileo_defconfig | 3 +++
configs/i12-tvbox_defconfig| 3 +++
configs/socfpga_cyclone5_defconfig | 3 +++
configs/socfpga_socrates_defconfig | 3 +++
configs/spear300_defconfig | 3 +++
configs/spear300_nand_defconfig| 3 +++
configs/spear300_usbtty_defconfig | 3 +++
configs/spear300_usbtty_nand_defconfig | 3 +++
configs/spear310_defconfig | 3 +++
configs/spear310_nand_defconfig| 3 +++
configs/spear310_pnor_defconfig| 3 +++
configs/spear310_usbtty_defconfig | 3 +++
configs/spear310_usbtty_nand_defconfig | 3 +++
configs/spear310_usbtty_pnor_defconfig | 3 +++
configs/spear320_defconfig | 3 +++
configs/spear320_nand_defconfig| 3 +++
configs/spear320_pnor_defconfig| 3 +++
configs/spear320_usbtty_defconfig | 3 +++
configs/spear320_usbtty_nand_defconfig | 3 +++
configs/spear320_usbtty_pnor_defconfig | 3 +++
configs/spear600_defconfig | 3 +++
configs/spear600_nand_defconfig| 3 +++
configs/spear600_usbtty_defconfig | 3 +++
configs/spear600_usbtty_nand_defconfig | 3 +++
configs/stv0991_defconfig | 3 +++
configs/tb100_defconfig| 3 +++
configs/x600_defconfig | 3 +++
drivers/net/Kconfig| 7 +++
drivers/net/Makefile | 2 +-
include/configs/axs101.h | 1 -
include/configs/bf609-ezkit.h | 1 -
include/configs/socfpga_common.h | 1 -
include/configs/spear-common.h | 1 -
include/configs/stv0991.h | 1 -
include/configs/sunxi-common.h | 1 -
include/configs/tb100.h| 1 -
include/configs/x600.h | 1 -
67 files changed, 164 insertions(+), 18 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/spear/cpu.c
b/arch/arm/cpu/arm926ejs/spear/cpu.c
index 697e094..1ce9db7 100644
--- a/arch/arm/cpu/arm926ejs/spear/cpu.c
+++ b/arch/arm/cpu/arm926ejs/spear/cpu.c
@@ -32,7 +32,7 @@ int arch_cpu_init(void)
periph_clk_cfg |= CONFIG_SPEAR_UART48M;
writel(periph_clk_cfg, misc_p-periph_clk_cfg);
#endif
-#if defined(CONFIG_DESIGNWARE_ETH)
+#if defined(CONFIG_ETH_DESIGNWARE)
periph1_clken |= MISC_ETHENB;
#endif
#if defined(CONFIG_DW_UDC)
diff --git a/arch/arm/cpu/armv7/socfpga/misc.c
b/arch/arm/cpu/armv7/socfpga/misc.c
index 7873c38..0f8b4d0 100644
--- a/arch/arm/cpu/armv7/socfpga/misc.c
+++ b/arch/arm/cpu/armv7/socfpga/misc.c
@@ -49,7 +49,7 @@ void enable_caches(void)
/*
* DesignWare Ethernet initialization
*/
-#ifdef CONFIG_DESIGNWARE_ETH
+#ifdef CONFIG_ETH_DESIGNWARE
int cpu_eth_init(bd_t *bis)
{
#if CONFIG_EMAC_BASE == SOCFPGA_EMAC0_ADDRESS
diff --git a/board/bf609-ezkit/bf609-ezkit.c b/board/bf609-ezkit/bf609-ezkit.c
index 43a4330..86da028 100644
--- a/board/bf609-ezkit/bf609-ezkit.c
[U-Boot] [PATCH v2 03/11] dts: sunxi: Bring in Ethernet device tree bindings
Since we will use these bindings on sunxi, bring them in from Linux
4.0-rc1.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Ian Campbell i...@hellion.org.uk
---
Changes in v2: None
.../net/allwinner,sun4i-emac.txt | 19 +++
.../net/allwinner,sun4i-mdio.txt | 27 ++
.../net/allwinner,sun7i-a20-gmac.txt | 27 ++
doc/device-tree-bindings/net/ethernet.txt | 25 +
doc/device-tree-bindings/net/stmmac.txt| 63 ++
5 files changed, 161 insertions(+)
create mode 100644 doc/device-tree-bindings/net/allwinner,sun4i-emac.txt
create mode 100644 doc/device-tree-bindings/net/allwinner,sun4i-mdio.txt
create mode 100644 doc/device-tree-bindings/net/allwinner,sun7i-a20-gmac.txt
create mode 100644 doc/device-tree-bindings/net/ethernet.txt
create mode 100644 doc/device-tree-bindings/net/stmmac.txt
diff --git a/doc/device-tree-bindings/net/allwinner,sun4i-emac.txt
b/doc/device-tree-bindings/net/allwinner,sun4i-emac.txt
new file mode 100644
index 000..10640b1
--- /dev/null
+++ b/doc/device-tree-bindings/net/allwinner,sun4i-emac.txt
@@ -0,0 +1,19 @@
+* Allwinner EMAC ethernet controller
+
+Required properties:
+- compatible: should be allwinner,sun4i-a10-emac (Deprecated:
+ allwinner,sun4i-emac)
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+- phy: see ethernet.txt file in the same directory.
+- clocks: A phandle to the reference clock for this device
+
+Example:
+
+emac: ethernet@01c0b000 {
+ compatible = allwinner,sun4i-a10-emac;
+ reg = 0x01c0b000 0x1000;
+ interrupts = 55;
+ clocks = ahb_gates 17;
+ phy = phy0;
+};
diff --git a/doc/device-tree-bindings/net/allwinner,sun4i-mdio.txt
b/doc/device-tree-bindings/net/allwinner,sun4i-mdio.txt
new file mode 100644
index 000..4ec5641
--- /dev/null
+++ b/doc/device-tree-bindings/net/allwinner,sun4i-mdio.txt
@@ -0,0 +1,27 @@
+* Allwinner A10 MDIO Ethernet Controller interface
+
+Required properties:
+- compatible: should be allwinner,sun4i-a10-mdio
+ (Deprecated: allwinner,sun4i-mdio).
+- reg: address and length of the register set for the device.
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+
+Example at the SoC level:
+mdio@01c0b080 {
+ compatible = allwinner,sun4i-a10-mdio;
+ reg = 0x01c0b080 0x14;
+ #address-cells = 1;
+ #size-cells = 0;
+};
+
+And at the board level:
+
+mdio@01c0b080 {
+ phy-supply = reg_emac_3v3;
+
+ phy0: ethernet-phy@0 {
+ reg = 0;
+ };
+};
diff --git a/doc/device-tree-bindings/net/allwinner,sun7i-a20-gmac.txt
b/doc/device-tree-bindings/net/allwinner,sun7i-a20-gmac.txt
new file mode 100644
index 000..ea4d752
--- /dev/null
+++ b/doc/device-tree-bindings/net/allwinner,sun7i-a20-gmac.txt
@@ -0,0 +1,27 @@
+* Allwinner GMAC ethernet controller
+
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+
+Required properties:
+ - compatible: Should be allwinner,sun7i-a20-gmac
+ - clocks: Should contain the GMAC main clock, and tx clock
+ The tx clock type should be allwinner,sun7i-a20-gmac-clk
+ - clock-names: Should contain the clock names stmmaceth,
+ and allwinner_gmac_tx
+
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+
+Examples:
+
+ gmac: ethernet@01c5 {
+ compatible = allwinner,sun7i-a20-gmac;
+ reg = 0x01c5 0x1,
+ 0x01c20164 0x4;
+ interrupts = 0 85 1;
+ interrupt-names = macirq;
+ clocks = ahb_gates 49, gmac_tx;
+ clock-names = stmmaceth, allwinner_gmac_tx;
+ phy-mode = mii;
+ };
diff --git a/doc/device-tree-bindings/net/ethernet.txt
b/doc/device-tree-bindings/net/ethernet.txt
new file mode 100644
index 000..3fc3605
--- /dev/null
+++ b/doc/device-tree-bindings/net/ethernet.txt
@@ -0,0 +1,25 @@
+The following properties are common to the Ethernet controllers:
+
+- local-mac-address: array of 6 bytes, specifies the MAC address that was
+ assigned to the network device;
+- mac-address: array of 6 bytes, specifies the MAC address that was last used
by
+ the boot program; should be used in cases where the MAC address assigned to
+ the device by the boot program is different from the local-mac-address
+ property;
+- max-speed: number, specifies maximum speed in Mbit/s supported by the device;
+- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
+ the maximum frame size (there's contradiction in ePAPR).
+- phy-mode: string, operation mode of the PHY interface; supported values are
+ mii, gmii, sgmii, qsgmii, tbi, rev-mii, rmii, rgmii,
rgmii-id,
+ rgmii-rxid, rgmii-txid, rtbi, smii, xgmii; this is now a de-facto
+ standard property;
+-
[U-Boot] [PATCH v2 09/11] dm: net: Adjust designware driver to support driver model
Add driver model support to the designware driver. This reuses most of the
existing code except for some duplication in the probe() method.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Use the new recv() method and the free_pkt() method
drivers/net/designware.c | 167 ++-
drivers/net/designware.h | 3 +-
2 files changed, 153 insertions(+), 17 deletions(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 5b36d4f..a4fe7a4 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -10,6 +10,7 @@
*/
#include common.h
+#include dm.h
#include errno.h
#include miiphy.h
#include malloc.h
@@ -18,6 +19,8 @@
#include asm/io.h
#include designware.h
+DECLARE_GLOBAL_DATA_PTR;
+
#if !defined(CONFIG_PHYLIB)
# error DesignWare Ether MAC requires PHYLIB - missing CONFIG_PHYLIB
#endif
@@ -343,11 +346,11 @@ static int _dw_eth_send(struct dw_eth_dev *priv, void
*packet, int length)
return 0;
}
-static int _dw_eth_recv(struct dw_eth_dev *priv)
+static int _dw_eth_recv(struct dw_eth_dev *priv, uchar **packetp)
{
u32 status, desc_num = priv-rx_currdescnum;
struct dmamacdescr *desc_p = priv-rx_mac_descrtable[desc_num];
- int length = 0;
+ int length = -EAGAIN;
uint32_t desc_start = (uint32_t)desc_p;
uint32_t desc_end = desc_start +
roundup(sizeof(*desc_p), ARCH_DMA_MINALIGN);
@@ -368,26 +371,35 @@ static int _dw_eth_recv(struct dw_eth_dev *priv)
/* Invalidate received data */
data_end = data_start + roundup(length, ARCH_DMA_MINALIGN);
invalidate_dcache_range(data_start, data_end);
+ *packetp = desc_p-dmamac_addr;
+ }
- NetReceive(desc_p-dmamac_addr, length);
+ return length;
+}
- /*
-* Make the current descriptor valid again and go to
-* the next one
-*/
- desc_p-txrx_status |= DESC_RXSTS_OWNBYDMA;
+static int _dw_free_pkt(struct dw_eth_dev *priv)
+{
+ u32 desc_num = priv-rx_currdescnum;
+ struct dmamacdescr *desc_p = priv-rx_mac_descrtable[desc_num];
+ uint32_t desc_start = (uint32_t)desc_p;
+ uint32_t desc_end = desc_start +
+ roundup(sizeof(*desc_p), ARCH_DMA_MINALIGN);
- /* Flush only status field - others weren't changed */
- flush_dcache_range(desc_start, desc_end);
+ /*
+* Make the current descriptor valid again and go to
+* the next one
+*/
+ desc_p-txrx_status |= DESC_RXSTS_OWNBYDMA;
- /* Test the wrap-around condition. */
- if (++desc_num = CONFIG_RX_DESCR_NUM)
- desc_num = 0;
- }
+ /* Flush only status field - others weren't changed */
+ flush_dcache_range(desc_start, desc_end);
+ /* Test the wrap-around condition. */
+ if (++desc_num = CONFIG_RX_DESCR_NUM)
+ desc_num = 0;
priv-rx_currdescnum = desc_num;
- return length;
+ return 0;
}
static int dw_phy_init(struct dw_eth_dev *priv, void *dev)
@@ -414,6 +426,7 @@ static int dw_phy_init(struct dw_eth_dev *priv, void *dev)
return 0;
}
+#ifndef CONFIG_DM_ETH
static int dw_eth_init(struct eth_device *dev, bd_t *bis)
{
return _dw_eth_init(dev-priv, dev-enetaddr);
@@ -426,7 +439,17 @@ static int dw_eth_send(struct eth_device *dev, void
*packet, int length)
static int dw_eth_recv(struct eth_device *dev)
{
- return _dw_eth_recv(dev-priv);
+ uchar *packet;
+ int length;
+
+ length = _dw_eth_recv(dev-priv, packet);
+ if (length == -EAGAIN)
+ return 0;
+ NetReceive(packet, length);
+
+ _dw_free_pkt(dev-priv);
+
+ return 0;
}
static void dw_eth_halt(struct eth_device *dev)
@@ -486,3 +509,115 @@ int designware_initialize(ulong base_addr, u32 interface)
return dw_phy_init(priv, dev);
}
+#endif
+
+#ifdef CONFIG_DM_ETH
+static int designware_eth_start(struct udevice *dev)
+{
+ struct eth_pdata *pdata = dev_get_platdata(dev);
+
+ return _dw_eth_init(dev-priv, pdata-enetaddr);
+}
+
+static int designware_eth_send(struct udevice *dev, void *packet, int length)
+{
+ struct dw_eth_dev *priv = dev_get_priv(dev);
+
+ return _dw_eth_send(priv, packet, length);
+}
+
+static int designware_eth_recv(struct udevice *dev, uchar **packetp)
+{
+ struct dw_eth_dev *priv = dev_get_priv(dev);
+
+ return _dw_eth_recv(priv, packetp);
+}
+
+static int designware_eth_free_pkt(struct udevice *dev, uchar *packet,
+ int length)
+{
+ struct dw_eth_dev *priv = dev_get_priv(dev);
+
+ return _dw_free_pkt(priv);
+}
+
+static void designware_eth_stop(struct udevice *dev)
+{
+ struct dw_eth_dev *priv = dev_get_priv(dev);
+
+ return
[U-Boot] [PATCH v2 05/11] dm: net: Use existing Ethernet init for driver model
At present even with driver model is used there is still much manual init
of related devices: PHY, environment and board init. Until these requirements
are dealt with in another way we need to keep them around.
Break out the init portion of the legacy eth_initialize() into a separate
function and call it from both the legacy and driver model eth_initialize()
functions.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v2: None
net/eth.c | 78 ++-
1 file changed, 42 insertions(+), 36 deletions(-)
diff --git a/net/eth.c b/net/eth.c
index 889ad8f..ede9367 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -79,6 +79,45 @@ static int eth_mac_skip(int index)
static void eth_current_changed(void);
+/*
+ * CPU and board-specific Ethernet initializations. Aliased function
+ * signals caller to move on
+ */
+static int __def_eth_init(bd_t *bis)
+{
+ return -1;
+}
+int cpu_eth_init(bd_t *bis) __attribute__((weak, alias(__def_eth_init)));
+int board_eth_init(bd_t *bis) __attribute__((weak, alias(__def_eth_init)));
+
+static void eth_common_init(void)
+{
+ bootstage_mark(BOOTSTAGE_ID_NET_ETH_START);
+#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) || defined(CONFIG_PHYLIB)
+ miiphy_init();
+#endif
+
+#ifdef CONFIG_PHYLIB
+ phy_init();
+#endif
+
+ eth_env_init();
+
+ /*
+* If board-specific initialization exists, call it.
+* If not, call a CPU-specific one
+*/
+ if (board_eth_init != __def_eth_init) {
+ if (board_eth_init(gd-bd) 0)
+ printf(Board Net Initialization Failed\n);
+ } else if (cpu_eth_init != __def_eth_init) {
+ if (cpu_eth_init(gd-bd) 0)
+ printf(CPU Net Initialization Failed\n);
+ } else {
+ printf(Net Initialization Skipped\n);
+ }
+}
+
#ifdef CONFIG_DM_ETH
/**
* struct eth_device_priv - private structure for each Ethernet device
@@ -390,8 +429,7 @@ int eth_initialize(void)
int num_devices = 0;
struct udevice *dev;
- bootstage_mark(BOOTSTAGE_ID_NET_ETH_START);
- eth_env_init();
+ eth_common_init();
/*
* Devices need to write the hwaddr even if not started so that Linux
@@ -518,16 +556,6 @@ UCLASS_DRIVER(eth) = {
#endif
#ifndef CONFIG_DM_ETH
-/*
- * CPU and board-specific Ethernet initializations. Aliased function
- * signals caller to move on
- */
-static int __def_eth_init(bd_t *bis)
-{
- return -1;
-}
-int cpu_eth_init(bd_t *bis) __attribute__((weak, alias(__def_eth_init)));
-int board_eth_init(bd_t *bis) __attribute__((weak, alias(__def_eth_init)));
#ifdef CONFIG_API
static struct {
@@ -702,32 +730,10 @@ int eth_unregister(struct eth_device *dev)
int eth_initialize(void)
{
int num_devices = 0;
+
eth_devices = NULL;
eth_current = NULL;
-
- bootstage_mark(BOOTSTAGE_ID_NET_ETH_START);
-#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) || defined(CONFIG_PHYLIB)
- miiphy_init();
-#endif
-
-#ifdef CONFIG_PHYLIB
- phy_init();
-#endif
-
- eth_env_init();
-
- /*
-* If board-specific initialization exists, call it.
-* If not, call a CPU-specific one
-*/
- if (board_eth_init != __def_eth_init) {
- if (board_eth_init(gd-bd) 0)
- printf(Board Net Initialization Failed\n);
- } else if (cpu_eth_init != __def_eth_init) {
- if (cpu_eth_init(gd-bd) 0)
- printf(CPU Net Initialization Failed\n);
- } else
- printf(Net Initialization Skipped\n);
+ eth_common_init();
if (!eth_devices) {
puts(No ethernet found.\n);
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 08/11] dm: net: Tidy up designware driver ready for driver model
Adjust the error handling to use errno.h instead of returning -1. Change
leaf functions to pass in the arguments they require rather than struct
eth_device. Apart from simplifying the code it makes is easier to reuse
these functions for driver model, since mostly they actually only use
struct dw_eth_priv (which we can keep).
Create a stub for each Ethernet operation function. This will allow use to
share code with the driver model versions.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Joe Hershberger joe.hershber...@ni.com
---
Changes in v2: None
drivers/net/designware.c | 87 +---
1 file changed, 53 insertions(+), 34 deletions(-)
diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index cc01604..5b36d4f 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -6,10 +6,11 @@
*/
/*
- * Designware ethernet IP driver for u-boot
+ * Designware ethernet IP driver for U-Boot
*/
#include common.h
+#include errno.h
#include miiphy.h
#include malloc.h
#include linux/compiler.h
@@ -40,7 +41,7 @@ static int dw_mdio_read(struct mii_dev *bus, int addr, int
devad, int reg)
udelay(10);
};
- return -1;
+ return -ETIMEDOUT;
}
static int dw_mdio_write(struct mii_dev *bus, int addr, int devad, int reg,
@@ -49,7 +50,7 @@ static int dw_mdio_write(struct mii_dev *bus, int addr, int
devad, int reg,
struct eth_mac_regs *mac_p = bus-priv;
ulong start;
u16 miiaddr;
- int ret = -1, timeout = CONFIG_MDIO_TIMEOUT;
+ int ret = -ETIMEDOUT, timeout = CONFIG_MDIO_TIMEOUT;
writel(val, mac_p-miidata);
miiaddr = ((addr MIIADDRSHIFT) MII_ADDRMSK) |
@@ -69,27 +70,26 @@ static int dw_mdio_write(struct mii_dev *bus, int addr, int
devad, int reg,
return ret;
}
-static int dw_mdio_init(char *name, struct eth_mac_regs *mac_regs_p)
+static int dw_mdio_init(const char *name, struct eth_mac_regs *mac_regs_p)
{
struct mii_dev *bus = mdio_alloc();
if (!bus) {
printf(Failed to allocate MDIO bus\n);
- return -1;
+ return -ENOMEM;
}
bus-read = dw_mdio_read;
bus-write = dw_mdio_write;
- sprintf(bus-name, name);
+ snprintf(bus-name, sizeof(bus-name), name);
bus-priv = (void *)mac_regs_p;
return mdio_register(bus);
}
-static void tx_descs_init(struct eth_device *dev)
+static void tx_descs_init(struct dw_eth_dev *priv)
{
- struct dw_eth_dev *priv = dev-priv;
struct eth_dma_regs *dma_p = priv-dma_regs_p;
struct dmamacdescr *desc_table_p = priv-tx_mac_descrtable[0];
char *txbuffs = priv-txbuffs[0];
@@ -128,9 +128,8 @@ static void tx_descs_init(struct eth_device *dev)
priv-tx_currdescnum = 0;
}
-static void rx_descs_init(struct eth_device *dev)
+static void rx_descs_init(struct dw_eth_dev *priv)
{
- struct dw_eth_dev *priv = dev-priv;
struct eth_dma_regs *dma_p = priv-dma_regs_p;
struct dmamacdescr *desc_table_p = priv-rx_mac_descrtable[0];
char *rxbuffs = priv-rxbuffs[0];
@@ -170,12 +169,10 @@ static void rx_descs_init(struct eth_device *dev)
priv-rx_currdescnum = 0;
}
-static int dw_write_hwaddr(struct eth_device *dev)
+static int _dw_write_hwaddr(struct dw_eth_dev *priv, u8 *mac_id)
{
- struct dw_eth_dev *priv = dev-priv;
struct eth_mac_regs *mac_p = priv-mac_regs_p;
u32 macid_lo, macid_hi;
- u8 *mac_id = dev-enetaddr[0];
macid_lo = mac_id[0] + (mac_id[1] 8) + (mac_id[2] 16) +
(mac_id[3] 24);
@@ -213,9 +210,8 @@ static void dw_adjust_link(struct eth_mac_regs *mac_p,
(phydev-port == PORT_FIBRE) ? , fiber mode : );
}
-static void dw_eth_halt(struct eth_device *dev)
+static void _dw_eth_halt(struct dw_eth_dev *priv)
{
- struct dw_eth_dev *priv = dev-priv;
struct eth_mac_regs *mac_p = priv-mac_regs_p;
struct eth_dma_regs *dma_p = priv-dma_regs_p;
@@ -225,12 +221,12 @@ static void dw_eth_halt(struct eth_device *dev)
phy_shutdown(priv-phydev);
}
-static int dw_eth_init(struct eth_device *dev, bd_t *bis)
+static int _dw_eth_init(struct dw_eth_dev *priv, u8 *enetaddr)
{
- struct dw_eth_dev *priv = dev-priv;
struct eth_mac_regs *mac_p = priv-mac_regs_p;
struct eth_dma_regs *dma_p = priv-dma_regs_p;
unsigned int start;
+ int ret;
writel(readl(dma_p-busmode) | DMAMAC_SRST, dma_p-busmode);
@@ -238,7 +234,7 @@ static int dw_eth_init(struct eth_device *dev, bd_t *bis)
while (readl(dma_p-busmode) DMAMAC_SRST) {
if (get_timer(start) = CONFIG_MACRESET_TIMEOUT) {
printf(DMA reset timeout\n);
- return -1;
+ return -ETIMEDOUT;
}
mdelay(100);
@@ -246,10 +242,10 @@ static int
[U-Boot] [PATCH v2 06/11] Avoid calling print_eths() with driver model
This function is not supported with driver model. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Joe Hershberger joe.hershber...@ni.com --- Note from Joe Hershberger joe.hershber...@ni.com At this point I don't see much value in listing the Ethernet devices in bdinfo. It seems like a bit of a spurious thing to display and as such I didn't feel like rewriting it to be compatible with DM or implementing the functions bdinfo's print_eths() uses. Also, it is only supported on ARM and Microblaze. The inconsistency also led to my decision to drop it. Changes in v2: None common/cmd_bdinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c index b4cce25..f16d5c7 100644 --- a/common/cmd_bdinfo.c +++ b/common/cmd_bdinfo.c @@ -377,7 +377,7 @@ static int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, print_num(- size,bd-bi_dram[i].size); } -#if defined(CONFIG_CMD_NET) +#if defined(CONFIG_CMD_NET) !defined(CONFIG_DM_ETH) print_eths(); #endif printf(baudrate= %u bps\n, gd-baudrate); -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 10/11] dm: sunxi: Support driver model for Ethernet
Adjust the Ethernet initialisation code to support driver model. It is no-longer necessary to call designware_initialize(). The device will be probed when it is used. The PHY type and GMAC base will come from the device tree. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Remove unwanted printf() board/sunxi/gmac.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/board/sunxi/gmac.c b/board/sunxi/gmac.c index 8849132..1540633 100644 --- a/board/sunxi/gmac.c +++ b/board/sunxi/gmac.c @@ -80,11 +80,15 @@ int sunxi_gmac_initialize(bd_t *bis) sunxi_gpio_set_cfgpin(pin, SUN6I_GPA0_GMAC); #endif -#ifdef CONFIG_RGMII +#ifdef CONFIG_DM_ETH + return 0; +#else +# ifdef CONFIG_RGMII return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_RGMII); -#elif defined CONFIG_GMII +# elif defined CONFIG_GMII return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_GMII); -#else +# else return designware_initialize(SUNXI_GMAC_BASE, PHY_INTERFACE_MODE_MII); +# endif #endif } -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] i2c: sunxi: Support every i2c controller on each supported platform
Hi, On 05-04-15 09:51, Paul Kocialkowski wrote: Changes since v2: * I2C/TWI busses enable for Cubietruck as well Changes since v1: * Kconfig option to enable I2C/TWI controllers 1-4 (when applicable) * Following patch to enable exposed busses on a few community-supported single-board-computers This series adds support for every i2c controller found on sun4i/sun5i/sun6i/sun7i/sun8i platforms and shouldn't break support for Marvell platforms (orion5x, kirkwood, armada xp) the driver was originally written for. Regarding sunxi, I double-checked that this doesn't conflict with VIDEO_LCD_PANEL_I2C. I would be interested in having this tested on sun8i (A23), since I changed TWI0 muxing (to PH2-PH3 instead of PB0-PB1), according to the user manual and what is being done on the upstream Linux kernel. I2C was either not working before, or it was being muxed correctly by the bootrom, probably to communicate with the AXP, which luckily made it work in U-Boot too, since the I/O base address was already correct. My use case here is that I'm writing a slave-side bitbang i2c implementation (with an Arduino) for a school project, using a Cubieboard2 as master and U-Boot as POC. However, only TWI1 was available through the expansion pins, hence the need for this series. Thanks for your work on this, may I request one more change ? For sunxi I would like to also see a CONFIG_I2C0_ENABLE, the reason for this is that on sun6i / sun8i we do not really use i2c0 as we use p2wi resp. rsb to talk to the axp pmic there. This way we will not end up messing with the muxing of the PH14/15 (sun6i) resp. PH2/3 (sun8i) which may be used in some other fashion. This also means making a small change to the first patch to also make registering of twsi0 #ifdef CONFIG_I2C_MVTWSI_BASE0 . Can you please make the default for CONFIG_I2C0_ENABLE y on sun4i / sun5i / sun7i and n on others? Also I'm not entirely convinced that patch 3/3 is a good idea, on the olimex boards which have a i2c eeprom enabling the attached i2c controller makes sense, but on the other boards the i2c pins are really just gpio pins, any daughter board can be connected including one which uses them differently. I believe that in the defconfig the i2c controllers should thus be left off. It is after all a default config, users with a daughter board which they want to use in u-boot can easily change the config after running make foo_defconfig. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/3] i2c: sunxi: Support every i2c controller on each supported platform
Changes since v2: * I2C/TWI busses enable for Cubietruck as well Changes since v1: * Kconfig option to enable I2C/TWI controllers 1-4 (when applicable) * Following patch to enable exposed busses on a few community-supported single-board-computers This series adds support for every i2c controller found on sun4i/sun5i/sun6i/sun7i/sun8i platforms and shouldn't break support for Marvell platforms (orion5x, kirkwood, armada xp) the driver was originally written for. Regarding sunxi, I double-checked that this doesn't conflict with VIDEO_LCD_PANEL_I2C. I would be interested in having this tested on sun8i (A23), since I changed TWI0 muxing (to PH2-PH3 instead of PB0-PB1), according to the user manual and what is being done on the upstream Linux kernel. I2C was either not working before, or it was being muxed correctly by the bootrom, probably to communicate with the AXP, which luckily made it work in U-Boot too, since the I/O base address was already correct. My use case here is that I'm writing a slave-side bitbang i2c implementation (with an Arduino) for a school project, using a Cubieboard2 as master and U-Boot as POC. However, only TWI1 was available through the expansion pins, hence the need for this series. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] i2c: mvtwsi: Support for up to 4 different controllers
Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI
controller. However, other platforms using MVTWSI may come with more: this is
the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found
on the same chip.
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
arch/arm/include/asm/arch-sunxi/i2c.h| 2 +-
arch/arm/mach-kirkwood/include/mach/config.h | 2 +-
drivers/i2c/mvtwsi.c | 124 ---
include/configs/db-mv784mp-gp.h | 2 +-
include/configs/edminiv2.h | 2 +-
include/configs/maxbcm.h | 2 +-
6 files changed, 100 insertions(+), 34 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/i2c.h
b/arch/arm/include/asm/arch-sunxi/i2c.h
index dc5406b..502e3c6 100644
--- a/arch/arm/include/asm/arch-sunxi/i2c.h
+++ b/arch/arm/include/asm/arch-sunxi/i2c.h
@@ -8,7 +8,7 @@
#include asm/arch/cpu.h
-#define CONFIG_I2C_MVTWSI_BASE SUNXI_TWI0_BASE
+#define CONFIG_I2C_MVTWSI_BASE0SUNXI_TWI0_BASE
/* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is 24MHz */
#define CONFIG_SYS_TCLK2400
diff --git a/arch/arm/mach-kirkwood/include/mach/config.h
b/arch/arm/mach-kirkwood/include/mach/config.h
index e77ac40..d049395 100644
--- a/arch/arm/mach-kirkwood/include/mach/config.h
+++ b/arch/arm/mach-kirkwood/include/mach/config.h
@@ -44,7 +44,7 @@
#define CONFIG_SYS_INIT_SP_ADDR0xC8012000
#define CONFIG_NR_DRAM_BANKS_MAX 2
-#define CONFIG_I2C_MVTWSI_BASE KW_TWSI_BASE
+#define CONFIG_I2C_MVTWSI_BASE0KW_TWSI_BASE
#define MV_UART_CONSOLE_BASE KW_UART0_BASE
#define MV_SATA_BASE KW_SATA_BASE
#define MV_SATA_PORT0_OFFSET KW_SATA_PORT0_OFFSET
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 6f6edd5..331d73c 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -14,7 +14,7 @@
#include asm/io.h
/*
- * include a file that will provide CONFIG_I2C_MVTWSI_BASE
+ * include a file that will provide CONFIG_I2C_MVTWSI_BASE*
* and possibly other settings
*/
@@ -91,11 +91,37 @@ struct mvtwsi_registers {
#defineMVTWSI_STATUS_IDLE 0xF8
/*
- * The single instance of the controller we'll be dealing with
+ * MVTWSI controller base
*/
-static struct mvtwsi_registers *twsi =
- (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE;
+static struct mvtwsi_registers *twsi_get_base(struct i2c_adapter *adap)
+{
+ switch (adap-hwadapnr) {
+ case 0:
+ return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE0;
+#ifdef CONFIG_I2C_MVTWSI_BASE1
+ case 1:
+ return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE1;
+#endif
+#ifdef CONFIG_I2C_MVTWSI_BASE2
+ case 2:
+ return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE2;
+#endif
+#ifdef CONFIG_I2C_MVTWSI_BASE3
+ case 3:
+ return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE3;
+#endif
+#ifdef CONFIG_I2C_MVTWSI_BASE4
+ case 4:
+ return (struct mvtwsi_registers *) CONFIG_I2C_MVTWSI_BASE4;
+#endif
+ default:
+ printf(Missing mvtwsi controller %d base\n, adap-hwadapnr);
+ break;
+ }
+
+ return NULL;
+}
/*
* Returned statuses are 0 for success and nonzero otherwise.
@@ -117,8 +143,9 @@ static struct mvtwsi_registers *twsi =
* Wait for IFLG to raise, or return 'timeout'; then if status is as expected,
* return 0 (ok) or return 'wrong status'.
*/
-static int twsi_wait(int expected_status)
+static int twsi_wait(struct i2c_adapter *adap, int expected_status)
{
+ struct mvtwsi_registers *twsi = twsi_get_base(adap);
int control, status;
int timeout = 1000;
@@ -153,35 +180,40 @@ static u8 twsi_control_flags = MVTWSI_CONTROL_TWSIEN;
* Assert the START condition, either in a single I2C transaction
* or inside back-to-back ones (repeated starts).
*/
-static int twsi_start(int expected_status)
+static int twsi_start(struct i2c_adapter *adap, int expected_status)
{
+ struct mvtwsi_registers *twsi = twsi_get_base(adap);
+
/* globally set TWSIEN in case it was not */
twsi_control_flags |= MVTWSI_CONTROL_TWSIEN;
/* assert START */
writel(twsi_control_flags | MVTWSI_CONTROL_START, twsi-control);
/* wait for controller to process START */
- return twsi_wait(expected_status);
+ return twsi_wait(adap, expected_status);
}
/*
* Send a byte (i2c address or data).
*/
-static int twsi_send(u8 byte, int expected_status)
+static int twsi_send(struct i2c_adapter *adap, u8 byte, int expected_status)
{
+ struct mvtwsi_registers *twsi = twsi_get_base(adap);
+
/* put byte in data register for sending */
writel(byte, twsi-data);
/* clear any pending interrupt -- that'll cause sending */
writel(twsi_control_flags,
[U-Boot] [PATCH v3 3/3] sunxi: I2C/TWI configs for a few single-board-computers
This enables the exposed I2C/TWI busses on a few single-board-computers (Olimex and Cubietech). Signed-off-by: Paul Kocialkowski cont...@paulk.fr --- configs/A10-OLinuXino-Lime_defconfig | 2 ++ configs/A10s-OLinuXino-M_defconfig| 2 ++ configs/A13-OLinuXinoM_defconfig | 2 ++ configs/A13-OLinuXino_defconfig | 2 ++ configs/A20-OLinuXino-Lime2_defconfig | 2 ++ configs/A20-OLinuXino-Lime_defconfig | 2 ++ configs/A20-OLinuXino_MICRO_defconfig | 2 ++ configs/Cubieboard2_defconfig | 1 + configs/Cubieboard_defconfig | 1 + configs/Cubietruck_defconfig | 2 ++ 10 files changed, 18 insertions(+) diff --git a/configs/A10-OLinuXino-Lime_defconfig b/configs/A10-OLinuXino-Lime_defconfig index 3e19424..63bd815 100644 --- a/configs/A10-OLinuXino-Lime_defconfig +++ b/configs/A10-OLinuXino-Lime_defconfig @@ -1,6 +1,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI CONFIG_FDTFILE=sun4i-a10-olinuxino-lime.dtb +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN4I=y diff --git a/configs/A10s-OLinuXino-M_defconfig b/configs/A10s-OLinuXino-M_defconfig index 73b7894..d7d52fc 100644 --- a/configs/A10s-OLinuXino-M_defconfig +++ b/configs/A10s-OLinuXino-M_defconfig @@ -5,6 +5,8 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=1 CONFIG_USB1_VBUS_PIN=PB10 CONFIG_MMC0_CD_PIN=PG1 CONFIG_MMC1_CD_PIN=PG13 +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN5I=y diff --git a/configs/A13-OLinuXinoM_defconfig b/configs/A13-OLinuXinoM_defconfig index ab890c6..821cb08 100644 --- a/configs/A13-OLinuXinoM_defconfig +++ b/configs/A13-OLinuXinoM_defconfig @@ -2,6 +2,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=CONS_INDEX=2,USB_EHCI CONFIG_FDTFILE=sun5i-a13-olinuxino-micro.dtb CONFIG_USB1_VBUS_PIN=PG11 +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_VIDEO_HDMI=n CONFIG_VIDEO_VGA_VIA_LCD=y CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y diff --git a/configs/A13-OLinuXino_defconfig b/configs/A13-OLinuXino_defconfig index b923d3e..0f52bb5 100644 --- a/configs/A13-OLinuXino_defconfig +++ b/configs/A13-OLinuXino_defconfig @@ -2,6 +2,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=CONS_INDEX=2,AXP209_POWER,USB_EHCI CONFIG_FDTFILE=sun5i-a13-olinuxino.dtb CONFIG_USB1_VBUS_PIN=PG11 +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_VIDEO_HDMI=n CONFIG_VIDEO_VGA_VIA_LCD=y CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y diff --git a/configs/A20-OLinuXino-Lime2_defconfig b/configs/A20-OLinuXino-Lime2_defconfig index 4fcff92..3c05a8b 100644 --- a/configs/A20-OLinuXino-Lime2_defconfig +++ b/configs/A20-OLinuXino-Lime2_defconfig @@ -4,6 +4,8 @@ CONFIG_FDTFILE=sun7i-a20-olinuxino-lime2.dtb CONFIG_MMC0_CD_PIN=PH1 CONFIG_USB0_VBUS_PIN=PC17 CONFIG_USB0_VBUS_DET=PH5 +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN7I=y diff --git a/configs/A20-OLinuXino-Lime_defconfig b/configs/A20-OLinuXino-Lime_defconfig index 8d71d5f..6537290 100644 --- a/configs/A20-OLinuXino-Lime_defconfig +++ b/configs/A20-OLinuXino-Lime_defconfig @@ -1,6 +1,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI CONFIG_FDTFILE=sun7i-a20-olinuxino-lime.dtb +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN7I=y diff --git a/configs/A20-OLinuXino_MICRO_defconfig b/configs/A20-OLinuXino_MICRO_defconfig index 377bd46..43bb8e7 100644 --- a/configs/A20-OLinuXino_MICRO_defconfig +++ b/configs/A20-OLinuXino_MICRO_defconfig @@ -2,6 +2,8 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI CONFIG_FDTFILE=sun7i-a20-olinuxino-micro.dtb CONFIG_MMC_SUNXI_SLOT_EXTRA=3 +CONFIG_I2C1_ENABLE=y +CONFIG_I2C2_ENABLE=y CONFIG_VIDEO_VGA=y CONFIG_MMC0_CD_PIN=PH1 CONFIG_MMC3_CD_PIN=PH11 diff --git a/configs/Cubieboard2_defconfig b/configs/Cubieboard2_defconfig index d866ad1..bcf2c34 100644 --- a/configs/Cubieboard2_defconfig +++ b/configs/Cubieboard2_defconfig @@ -2,6 +2,7 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI CONFIG_FDTFILE=sun7i-a20-cubieboard2.dtb CONFIG_MMC0_CD_PIN=PH1 +CONFIG_I2C1_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN7I=y diff --git a/configs/Cubieboard_defconfig b/configs/Cubieboard_defconfig index 0b5c536..84042b5 100644 --- a/configs/Cubieboard_defconfig +++ b/configs/Cubieboard_defconfig @@ -1,6 +1,7 @@ CONFIG_SPL=y CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI CONFIG_FDTFILE=sun4i-a10-cubieboard.dtb +CONFIG_I2C1_ENABLE=y CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN4I=y diff --git a/configs/Cubietruck_defconfig b/configs/Cubietruck_defconfig index fa48331..cc80368 100644 --- a/configs/Cubietruck_defconfig +++ b/configs/Cubietruck_defconfig @@ -2,6 +2,8 @@ CONFIG_SPL=y
[U-Boot] [PATCH v3 2/3] sunxi: Complete i2c support for each supported platform
Sunxi platforms come with at least 3 TWI (I2C) controllers and some platforms
even have up to 5. This adds support for every controller on each supported
platform, which is especially useful when using expansion ports on single-board-
computers.
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++
arch/arm/include/asm/arch-sunxi/gpio.h | 15 +-
arch/arm/include/asm/arch-sunxi/i2c.h | 13 +
board/sunxi/Kconfig | 31
board/sunxi/board.c | 75 -
5 files changed, 138 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index dae6069..f403742 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -94,6 +94,13 @@
#define SUNXI_TWI0_BASE0x01c2ac00
#define SUNXI_TWI1_BASE0x01c2b000
#define SUNXI_TWI2_BASE0x01c2b400
+#ifdef CONFIG_MACH_SUN6I
+#define SUNXI_TWI3_BASE0x01c0b800
+#endif
+#ifdef CONFIG_MACH_SUN7I
+#define SUNXI_TWI3_BASE0x01c2b800
+#define SUNXI_TWI4_BASE0x01c2c000
+#endif
#define SUNXI_CAN_BASE 0x01c2bc00
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index f227044..ae7cbb7 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -148,7 +148,11 @@ enum sunxi_gpio_number {
#define SUN6I_GPA_SDC2 5
#define SUN6I_GPA_SDC3 4
-#define SUNXI_GPB_TWI0 2
+#define SUN4I_GPB_TWI0 2
+#define SUN4I_GPB_TWI1 2
+#define SUN5I_GPB_TWI1 2
+#define SUN4I_GPB_TWI2 2
+#define SUN5I_GPB_TWI2 2
#define SUN4I_GPB_UART02
#define SUN5I_GPB_UART02
@@ -160,6 +164,7 @@ enum sunxi_gpio_number {
#define SUNXI_GPD_LVDS03
#define SUN5I_GPE_SDC2 3
+#define SUN8I_GPE_TWI2 3
#define SUNXI_GPF_SDC0 2
#define SUNXI_GPF_UART04
@@ -169,12 +174,20 @@ enum sunxi_gpio_number {
#define SUN5I_GPG_SDC1 2
#define SUN6I_GPG_SDC1 2
#define SUN8I_GPG_SDC1 2
+#define SUN6I_GPG_TWI3 2
#define SUN5I_GPG_UART14
#define SUN4I_GPH_SDC1 5
+#define SUN6I_GPH_TWI0 2
+#define SUN8I_GPH_TWI0 2
+#define SUN6I_GPH_TWI1 2
+#define SUN8I_GPH_TWI1 2
+#define SUN6I_GPH_TWI2 2
#define SUN6I_GPH_UART02
#define SUNXI_GPI_SDC3 2
+#define SUN7I_GPI_TWI3 3
+#define SUN7I_GPI_TWI4 3
#define SUN6I_GPL0_R_P2WI_SCK 3
#define SUN6I_GPL1_R_P2WI_SDA 3
diff --git a/arch/arm/include/asm/arch-sunxi/i2c.h
b/arch/arm/include/asm/arch-sunxi/i2c.h
index 502e3c6..5e9586f 100644
--- a/arch/arm/include/asm/arch-sunxi/i2c.h
+++ b/arch/arm/include/asm/arch-sunxi/i2c.h
@@ -9,6 +9,19 @@
#include asm/arch/cpu.h
#define CONFIG_I2C_MVTWSI_BASE0SUNXI_TWI0_BASE
+#ifdef CONFIG_I2C1_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE1SUNXI_TWI1_BASE
+#endif
+#ifdef CONFIG_I2C2_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE2SUNXI_TWI2_BASE
+#endif
+#ifdef CONFIG_I2C3_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE3SUNXI_TWI3_BASE
+#endif
+#ifdef CONFIG_I2C4_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE4SUNXI_TWI4_BASE
+#endif
+
/* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is 24MHz */
#define CONFIG_SYS_TCLK2400
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index ccc2080..d3b5bad 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -269,6 +269,37 @@ config USB2_VBUS_PIN
---help---
See USB1_VBUS_PIN help text.
+config I2C1_ENABLE
+ bool Enable I2C/TWI controller 1
+ default n
+ ---help---
+ This allows enabling I2C/TWI controller 1 by muxing its pins, enabling
+ its clock and setting up the bus. This is especially useful on devices
+ with slaves connected to the bus or with pins exposed through e.g. an
+ expansion port/header.
+
+config I2C2_ENABLE
+ bool Enable I2C/TWI controller 2
+ default n
+ ---help---
+ See I2C1_ENABLE help text.
+
+if MACH_SUN6I || MACH_SUN7I
+config I2C3_ENABLE
+ bool Enable I2C/TWI controller 3
+ default n
+ ---help---
+ See I2C1_ENABLE help text.
+endif
+
+if MACH_SUN7I
+config I2C4_ENABLE
+ bool Enable I2C/TWI controller 4
+ default n
+ ---help---
+ See I2C1_ENABLE help text.
+endif
+
config VIDEO
boolean Enable graphical uboot console on HDMI, LCD or VGA
default y
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 986261a..0fb458b 100644
--- a/board/sunxi/board.c
+++
Re: [U-Boot] [PATCH v2] dm: eth: Provide a way for drivers to manage packet buffers
Hi Joe,
On 3 April 2015 at 19:09, Joe Hershberger joe.hershber...@ni.com wrote:
Some drivers need a chance to manage their receive buffers after the
packet has been handled by the network stack. Add an operation that
will allow the driver to be called in that case.
Reported-by: Simon Glass s...@chromium.org
Signed-off-by: Joe Hershberger joe.hershber...@ni.com
Acked-by: Simon Glass s...@chromium.org
Tested-by: Simon Glass s...@chromium.org
Tested-on: pcduino3
---
This patch depends on dm/next
Changes in v2:
-Call free_pkt() even when driver returns 0
-Add more comments about this new behavior
include/net.h | 8 +++-
net/eth.c | 4 +++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/net.h b/include/net.h
index e7f28d7..35602cd 100644
--- a/include/net.h
+++ b/include/net.h
@@ -97,7 +97,12 @@ struct eth_pdata {
* send: Send the bytes passed in packet as a packet on the wire
* recv: Check if the hardware received a packet. If so, set the pointer to
the
* packet buffer in the packetp parameter. If not, return an error or 0
to
- * indicate that the hardware receive FIFO is empty
+ * indicate that the hardware receive FIFO is empty. If 0 is returned,
the
+ * network stack will not process the empty packet, but free_pkt() will
be
+ * called if supplied
+ * free_pkt: Give the driver an opportunity to manage its packet buffer
memory
+ * when the network stack is finished processing it. This will only
be
+ * called when no error was returned from recv - optional
* stop: Stop the hardware from looking for packets - may be called even if
* state == PASSIVE
* mcast: Join or leave a multicast group (for TFTP) - optional
@@ -113,6 +118,7 @@ struct eth_ops {
int (*start)(struct udevice *dev);
int (*send)(struct udevice *dev, void *packet, int length);
int (*recv)(struct udevice *dev, uchar **packetp);
+ int (*free_pkt)(struct udevice *dev, uchar *packet, int length);
void (*stop)(struct udevice *dev);
#ifdef CONFIG_MCAST_TFTP
int (*mcast)(struct udevice *dev, const u8 *enetaddr, int join);
diff --git a/net/eth.c b/net/eth.c
index 13b7723..05411f1 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -344,7 +344,9 @@ int eth_rx(void)
ret = eth_get_ops(current)-recv(current, packet);
if (ret 0)
net_process_received_packet(packet, ret);
- else
+ if (ret = 0 eth_get_ops(current)-free_pkt)
+ eth_get_ops(current)-free_pkt(current, packet, ret);
+ if (ret = 0)
break;
}
if (ret == -EAGAIN)
--
1.7.11.5
Looks good, I will pick this up for u-boot-dm/next.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/17] Power(full) framework based on Driver Model
Hi Przemyslaw,
On 3 April 2015 at 10:11, Przemyslaw Marczak p.marc...@samsung.com wrote:
Hello Simon,
On 03/29/2015 03:05 PM, Simon Glass wrote:
Hi Przemyslaw,
On 24 March 2015 at 14:30, Przemyslaw Marczak p.marc...@samsung.com
wrote:
Hello,
Here is the third RFC version of the new PMIC framework.Big thanks to
Simon Glass, your comments were really helpful, and I think, that this
version is much more better to discuss, than the previous. The changes
made in this version are described below each commit. Sorry that I didn't
reply to each patch, I agreed with most and just started the work.
This is looking really good. Here are a few overall comments.
1. There is one oddity that I'd like to address before merging.
I don't think the fdt_node_check_prop_compatible() is a good idea, nor
necessary. I don't think we should consider the regulator-compatible
property to be a compatible string. It has values like LDO8, LDO9 and
these don't look like compatible strings, which are normally unique
and point to a driver. Here they point to a particular device.
Right, those compatibles don't point to a driver. This is a specific case of
use from the kernel.
A similar problem is faced in pinctrl and if you look at
gpio_exynos_bind() you will see that it works through the sub-nodes,
creating devices as needed.
I don't think using udevice_id is right here either.
Yes, I know how it's done. But we haven't the compatibles for each GPIO as
for the regulators, and each GPIO driver, bind the childs by its own
implementation.
I tried to reuse the existing code. It was nice, but I missed one thing...if
there are more, than one driver with the same e.g. LDO1 compatible, then
the first one will bind - and it could be the wrong one...
But, it could be tune-up, to get the right drivers list by arg.
Here is my suggestion:
a. Create a new structure like this:
struct pmic_child_info {
const char *prefix; // LDO or BUCK
const char *driver_name; // max77686_ldo or max77686_buck
};
b. Pass a list of these to pmic_child_node_scan(). In your case there
will be three entries, one for LDO, one for BUCK, plus a NULL
termination entry,
Ok, this could be good.
c. It can work through the subnodes looking for the given prefixes. It
then calls device_bind_driver() on each. Then it changes the returned
device's of_data to hold the correct value (obtained with strtol() on
the part of the name that follows the prefix - e.g. 17 for LDO17).
This will be easier if you rebase on u-boot-dm/usb-working, where the
data is just a long, not a device tree pointer.
Yes, it's easy. I made something like this in the first version of this
patchset, to parse the nodes and fill the max77686 regulator descriptors in
function get_desc_for_compat(), from this patch:
http://lists.denx.de/pipermail/u-boot/2014-October/191024.html
Yes I see.
d. Now you have the same effect as before, but you can drop the tables
like max77686_ldo_ids[] and avoid misappropriating driver model's
device lookup.
Yes, this is an advantage.
I wonder about the usage of struct udevice_id, which should contain the
data, defined only by the driver, right?
In the method you mentioned, we bind the pmic childs and then
we modify the dev-of_id-data by putting the regulator number from
matched prefix in it.
This is ok, but I think, that the second part of this idea should be done by
the driver. I think, that the external function shouldn't modify this driver
data on bind.
This could be solved by leave this job for the device driver. For example on
max77686, we could leave the dev-of_id as null and use dev-priv for the
node prefix id.
So, it's not a big problem.
As I see it the regulator number (e.g. 1 for LDO1, 3 for BUCK3) is
picked up from the name string, so it feels like this is common code.
You would be calling a helper function from the driver, so yes you can
always have it return the regulator number, and then store it in
driver_data in the driver.
But you should rebase on dm/usb-working to get the new driver_data
member of struct udevice.
My only concern with using driver_data is that this is normally used
to specify the device type where the driver supports multiple hardware
variants. The regulator number is more correctly considered to be
platform data. This leads on to your point below.
Here, I would like mention the problem with the regulator_get() by name, for
which we want use the regulator-name constraint.
For this version, it requires probing of all regulator devices,
since it uses the dev-uclass_priv, which I think, is a good place to
provide the framework-specific structure type for regulator constraints and
mode descriptors.
What about moving it back to dev-platdata?
Then:
- the structure type: dm_regulator_info, will move to
dm_regulator_platdata
- only its .name field could be assigned at regulator bind stage from the
regulator-name constraint
- the
Re: [U-Boot] [ PATCH] patman: cover letter shows like 00/xx if more than 10 patches
Hi Josh,
On 31 March 2015 at 20:54, Josh Wu josh...@atmel.com wrote:
Hi, Simon
On 4/1/2015 10:04 AM, Simon Glass wrote:
Hi Josh,
On 30 March 2015 at 19:54, Josh Wu josh...@atmel.com wrote:
Make cover letter shows like 0/x, 00/xx and 000/xxx etc.
Signed-off-by: Josh Wu josh...@atmel.com
---
This is a quirk of patman that I've grown comfortable with. Still, we
should fix it. Thanks for the patch.
tools/patman/patchstream.py | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/patman/patchstream.py b/tools/patman/patchstream.py
index 8c3a0ec..4bfb1e9 100644
--- a/tools/patman/patchstream.py
+++ b/tools/patman/patchstream.py
@@ -468,8 +468,13 @@ def InsertCoverLetter(fname, series, count):
prefix = series.GetPatchPrefix()
for line in lines:
if line.startswith('Subject:'):
-# TODO: if more than 10 patches this should save 00/xx, not
0/xx
-line = 'Subject: [%s 0/%d] %s\n' % (prefix, count, text[0])
+# if more than 10 patches this should save 00/xx, not 0/xx
s/save/say/
(my typo, I think)
;-) I'll fix this.
+zero_repeat = 1
+while (count / (10 ** zero_repeat) 0):
+zero_repeat = zero_repeat + 1
How about:
zero_repeat = int(math.log10(count)) + 1
?
yes, it's better. just need to import the match lib.
I will change to this and sent v2 patch. Thanks.
BTW: speak of patman, I get an issue of using the Series-prefix.
When I use Series-prefix like following in the commit:
Series-prefix: U-Boot][
Then I get the patman generated patch like:
[U-Boot][ PATCH]
^ a space here.
A space is before the 'PATCH', that annoys me. But I don't see you have such
space in your patches. Any advice to avoid the extra space?
Thanks in advance.
This is intentional, since if you use a prefix of 'RFC' we want to get
'RFC PATCH v2' instead of 'RFCPATCH v2'. See GetPatchPrefix(). Why do
you want [U-Boot] anyway? That sounds more like the project than a
patch prefix. Perhaps you could add an option to prepend the project
in square brackets?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] sunxi: Complete i2c support for each supported platform
Hi Paul,
On 4 April 2015 at 14:49, Paul Kocialkowski cont...@paulk.fr wrote:
Sunxi platforms come with at least 3 TWI (I2C) controllers and some platforms
even have up to 5. This adds support for every controller on each supported
platform, which is especially useful when using expansion ports on
single-board-
computers.
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 7 +++
arch/arm/include/asm/arch-sunxi/gpio.h | 15 +-
arch/arm/include/asm/arch-sunxi/i2c.h | 13 +
board/sunxi/Kconfig | 31
board/sunxi/board.c | 75
-
5 files changed, 138 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index dae6069..f403742 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -94,6 +94,13 @@
#define SUNXI_TWI0_BASE0x01c2ac00
#define SUNXI_TWI1_BASE0x01c2b000
#define SUNXI_TWI2_BASE0x01c2b400
+#ifdef CONFIG_MACH_SUN6I
+#define SUNXI_TWI3_BASE0x01c0b800
+#endif
+#ifdef CONFIG_MACH_SUN7I
+#define SUNXI_TWI3_BASE0x01c2b800
+#define SUNXI_TWI4_BASE0x01c2c000
+#endif
#define SUNXI_CAN_BASE 0x01c2bc00
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index f227044..ae7cbb7 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -148,7 +148,11 @@ enum sunxi_gpio_number {
#define SUN6I_GPA_SDC2 5
#define SUN6I_GPA_SDC3 4
-#define SUNXI_GPB_TWI0 2
+#define SUN4I_GPB_TWI0 2
+#define SUN4I_GPB_TWI1 2
+#define SUN5I_GPB_TWI1 2
+#define SUN4I_GPB_TWI2 2
+#define SUN5I_GPB_TWI2 2
#define SUN4I_GPB_UART02
#define SUN5I_GPB_UART02
@@ -160,6 +164,7 @@ enum sunxi_gpio_number {
#define SUNXI_GPD_LVDS03
#define SUN5I_GPE_SDC2 3
+#define SUN8I_GPE_TWI2 3
#define SUNXI_GPF_SDC0 2
#define SUNXI_GPF_UART04
@@ -169,12 +174,20 @@ enum sunxi_gpio_number {
#define SUN5I_GPG_SDC1 2
#define SUN6I_GPG_SDC1 2
#define SUN8I_GPG_SDC1 2
+#define SUN6I_GPG_TWI3 2
#define SUN5I_GPG_UART14
#define SUN4I_GPH_SDC1 5
+#define SUN6I_GPH_TWI0 2
+#define SUN8I_GPH_TWI0 2
+#define SUN6I_GPH_TWI1 2
+#define SUN8I_GPH_TWI1 2
+#define SUN6I_GPH_TWI2 2
#define SUN6I_GPH_UART02
#define SUNXI_GPI_SDC3 2
+#define SUN7I_GPI_TWI3 3
+#define SUN7I_GPI_TWI4 3
#define SUN6I_GPL0_R_P2WI_SCK 3
#define SUN6I_GPL1_R_P2WI_SDA 3
diff --git a/arch/arm/include/asm/arch-sunxi/i2c.h
b/arch/arm/include/asm/arch-sunxi/i2c.h
index 502e3c6..5e9586f 100644
--- a/arch/arm/include/asm/arch-sunxi/i2c.h
+++ b/arch/arm/include/asm/arch-sunxi/i2c.h
@@ -9,6 +9,19 @@
#include asm/arch/cpu.h
#define CONFIG_I2C_MVTWSI_BASE0SUNXI_TWI0_BASE
+#ifdef CONFIG_I2C1_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE1SUNXI_TWI1_BASE
+#endif
+#ifdef CONFIG_I2C2_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE2SUNXI_TWI2_BASE
+#endif
+#ifdef CONFIG_I2C3_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE3SUNXI_TWI3_BASE
+#endif
+#ifdef CONFIG_I2C4_ENABLE
+#define CONFIG_I2C_MVTWSI_BASE4SUNXI_TWI4_BASE
+#endif
+
/* This is abp0-clk on sun4i/5i/7i / abp1-clk on sun6i/sun8i which is 24MHz
*/
#define CONFIG_SYS_TCLK2400
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index ccc2080..d3b5bad 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -269,6 +269,37 @@ config USB2_VBUS_PIN
---help---
See USB1_VBUS_PIN help text.
+config I2C1_ENABLE
+ bool Enable I2C/TWI controller 1
+ default n
+ ---help---
+ This allows enabling I2C/TWI controller 1 by muxing its pins, enabling
+ its clock and setting up the bus. This is especially useful on devices
+ with slaves connected to the bus or with pins exposed through e.g. an
+ expansion port/header.
+
+config I2C2_ENABLE
+ bool Enable I2C/TWI controller 2
+ default n
+ ---help---
+ See I2C1_ENABLE help text.
+
+if MACH_SUN6I || MACH_SUN7I
+config I2C3_ENABLE
+ bool Enable I2C/TWI controller 3
+ default n
+ ---help---
+ See I2C1_ENABLE help text.
+endif
+
+if MACH_SUN7I
+config I2C4_ENABLE
+ bool Enable I2C/TWI controller 4
+ default n
+ ---help---
+ See I2C1_ENABLE help text.
+endif
It seems wrong to me to add
Re: [U-Boot] [PATCH v2] MAKEALL: fix get_target_arch() to adjust to '-' in Status field
Hi Tom, On 1 April 2015 at 05:19, Tom Rini tr...@konsulko.com wrote: On Tue, Mar 31, 2015 at 08:39:57PM -0600, Simon Glass wrote: Hi Masahiro, On 30 March 2015 at 05:59, Masahiro Yamada yamada.masah...@socionext.com wrote: Since the Kconfig conversion, boards.cfg scanned by MAKEALL is generated by tools/genboardscfg.py. Every board is supposed to have its own MAINTAINERS that contains maintainer and status information, but, in fact, MAINTAINERS is missing from some boards. For such boards, the first field, Status, is filled with '-'. It causes a problem for set command, which ignores '-' in its arguments. Consequently, get_target_arch() returns a wrong field and MAKEALL fails to get a correct toolchain. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com - Improve git description Should we perhaps apply the patch to deprecate MAKEALL? With the last patch I posted about what binaries to save all my usecases are covered now. OK, do you think we can wait until the merge window before doing these? I don't see any great hurry. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] patman: cover letter shows like 00/xx if more than 10 patches
On 2 April 2015 at 20:51, Josh Wu josh...@atmel.com wrote: Make cover letter shows like 0/x, 00/xx and 000/xxx etc. Signed-off-by: Josh Wu josh...@atmel.com --- Changes in v2: - use math.log10() function instead tools/patman/patchstream.py | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/17] dm: regulator: add implementation of driver model regulator uclass
Hi Przemyslaw,
On 3 April 2015 at 10:09, Przemyslaw Marczak p.marc...@samsung.com wrote:
Hello Simon,
On 03/29/2015 03:07 PM, Simon Glass wrote:
Hi Przemyslaw,
On 24 March 2015 at 14:30, Przemyslaw Marczak p.marc...@samsung.com
wrote:
[snip]
+
+ info-min_uV = fdtdec_get_int(gd-fdt_blob, offset,
+ regulator-min-microvolt, -1);
+ if (info-min_uV 0)
+ return -ENXIO;
+
+ info-max_uV = fdtdec_get_int(gd-fdt_blob, offset,
+ regulator-max-microvolt, -1);
+ if (info-max_uV 0)
+ return -ENXIO;
+
+ /* Optional constraints */
+ info-min_uA = fdtdec_get_int(gd-fdt_blob, offset,
+ regulator-min-microamp, -1);
+ info-max_uA = fdtdec_get_int(gd-fdt_blob, offset,
+ regulator-max-microamp, -1);
+ info-always_on = fdtdec_get_bool(gd-fdt_blob, offset,
+regulator-always-on);
+ info-boot_on = fdtdec_get_bool(gd-fdt_blob, offset,
+regulator-boot-on);
+
+ return 0;
+}
+
+int regulator_get(char *name, struct udevice **devp)
+{
+ struct dm_regulator_info *info;
+ struct udevice *dev;
+ int ret;
+
+ *devp = NULL;
+
+ for (ret = uclass_first_device(UCLASS_REGULATOR, dev);
+dev;
+ret = uclass_next_device(dev)) {
This will probe all devices. See my suggestion about creating
uclass_find_first_device()/uclass_find_next_device() in the next
patch.
As before, I think this could use a function like
uclass_get_device_by_name().
Yes, this is the same. But in this case, there is one more issue, which is
the regulator device name.
Usually after bind - the dev-name is the same as node name. This is good,
since it's natural that regulator IC, provides e.g ldo1, or some other
device-output name.
But we would like check the regulator-name property. For this patch-set,
the name is fixed at device probe stage, when dev-ofdata_to_platdata() is
called, and the regulator constraints, the same as it's name goes to struct
dm_regulator_info.
I put the dm_regulator_info into uclass priv, because it it uclass-specific,
the same as struct dm_i2c_bus is specific for i2c buses.
But, the ucalss priv is allocated at device probe stage.
I can't use the .per_child_platdata_auto_alloc_size, since the parent is a
pmic, and its uclass type is different.
Actually I could, move the dm_regulator_info only to device platdata, but
then, the drivers should take care of this uclass-specific structure
allocation.
Is it acceptable?
But then, also ambiguous seem to be filling platdata (struct
dm_regulator_info) in uclass post_bind() method.
So then, maybe reasonable is:
- move dm_regulator_info from dev-uclass_priv to dev-platdata - is
allocated after device bind
- add .post_bind() method to regulator uclass, and get the regulator-name
in it - only
- fill all platdata constraints on call to dev-ofdata_to_platdata()
Then, I could avoid probing every device, when checking the regulator name.
But, still I can't use the uclass.c functions, since I'm checking the
regulator info at dev-platdata.
So I update the function as below:
+ uclass_foreach_dev(dev, uc) {
+ if (!dev-platdata)
+ continue;
+
+ info = dev-platdata;
+ if (!strcmp(name, info-name)) {
+ ret = device_probe(dev);
+ if (ret)
+
+ *regulator = dev;
+ return ret;
+ }
+ }
The problem here is similar to I2C which uses per-child platdata
(specified by the uclass) for the bus address. This is different from
device platdata. I think you are suggesting that we should support
uclass platdata. In this case we would have for each device:
- device platform data
- parent platform data
- uclass platform data
The last one is not supported. I have through several times about
adding it. The alternative is to require each device to provide a
platform data struct at the start of its own platform data, which the
uclass can find and use. This is not really in the spirit of driver
model. But for now this is what I have done with USB (see
dm/usb-working). struct usb_platdata appears at the start of struct
exynos_ehci_platdata but is owned by the uclass.
If PMIC has use for uclass platform data, then perhaps that would be
enough users to warrant it. You could add a patch to do this (don't
forget to update tests) or you could do what I have done with USB and
we can tidy it up later.
Re your naming problem, apart from case the device name and
regulator-compatible name are the same. So perhaps just use
case-insensitive search for regulators? But if not then I take back my
comment about using a common function
Re: [U-Boot] [PATCH v3 05/17] dm: pmic: add implementation of driver model pmic uclass
Hi Przemyslaw,
On 3 April 2015 at 10:08, Przemyslaw Marczak p.marc...@samsung.com wrote:
Hello Simon,
On 03/29/2015 03:07 PM, Simon Glass wrote:
Hi Prazemyslaw,
On 24 March 2015 at 14:30, Przemyslaw Marczak p.marc...@samsung.com
wrote:
+ UCLASS_PMIC,
+
UCLASS_COUNT,
UCLASS_INVALID = -1,
};
diff --git a/include/power/pmic.h b/include/power/pmic.h
index afbc5aa..b55304f 100644
--- a/include/power/pmic.h
+++ b/include/power/pmic.h
@@ -1,4 +1,7 @@
/*
+ * Copyright (C) 2014-2015 Samsung Electronics
+ * Przemyslaw Marczak p.marc...@samsung.com
+ *
* Copyright (C) 2011-2012 Samsung Electronics
* Lukasz Majewski l.majew...@samsung.com
*
@@ -9,10 +12,13 @@
#define __CORE_PMIC_H_
#include linux/list.h
+#include spi.h
#include i2c.h
#include power/power_chrg.h
enum { PMIC_I2C, PMIC_SPI, PMIC_NONE};
+
+#ifdef CONFIG_POWER
enum { I2C_PMIC, I2C_NUM, };
enum { PMIC_READ, PMIC_WRITE, };
enum { PMIC_SENSOR_BYTE_ORDER_LITTLE, PMIC_SENSOR_BYTE_ORDER_BIG, };
@@ -77,7 +83,210 @@ struct pmic {
struct pmic *parent;
struct list_head list;
};
+#endif /* CONFIG_POWER */
+
+#ifdef CONFIG_DM_PMIC
+/**
+ * Driver model pmic framework.
+ * The PMIC_UCLASS uclass is designed to provide a common I/O
+ * interface for pmic child devices of various uclass types.
I worry about having the docs in multiple places. Should you adjust
this to point to the Kconfig? Or change the Kconfig to point here? Or
maybe it would be better to drop both and put these in your README? I
am concerned that if we later change something, we end up with
inconsistent docs.
Right, this could be an issue in the future. I suppose that first thing is
to look at this header file, before anyone starts work with this framework.
So maybe it's better keep the description only in this file, and add some
basic info to Kconfig and doc, with the links to here?
Yes that sounds good to me. It's great that you have documented this so well.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] x86: minnowmax: add GPIO mapping support
Hi Gabriel, On 1 April 2015 at 05:20, Gabriel Huau cont...@huau-gabriel.fr wrote: Hi Simon, On 03/31/2015 07:32 PM, Simon Glass wrote: Hi Gabriel, On 27 February 2015 at 01:52, Bin Meng bmeng...@gmail.com wrote: Hi Gabriel, On Fri, Feb 27, 2015 at 3:54 PM, gabriel huau cont...@huau-gabriel.fr wrote: Hi Bin, On 02/26/2015 07:30 PM, Bin Meng wrote: Hi Gabriel, On Thu, Feb 26, 2015 at 12:27 AM, Gabriel Huau cont...@huau-gabriel.fr wrote: Hi Bin, On 02/24/2015 11:52 PM, Bin Meng wrote: Hi Gabriel, On Mon, Feb 16, 2015 at 5:55 AM, Gabriel Huau cont...@huau-gabriel.fr wrote: Configure the pinctrl as it required to make some IO controllers working (USB/UART/I2C/...). The idea would be in the next version to modify the pch GPIO driver and configure these pins through the device tree. These modifications are ported from the coreboot project. Signed-off-by: Gabriel Huau cont...@huau-gabriel.fr --- arch/x86/cpu/baytrail/Makefile| 1 + arch/x86/cpu/baytrail/gpio.c | 206 +++ arch/x86/include/asm/arch-baytrail/gpio.h | 364 ++ arch/x86/include/asm/arch-baytrail/iomap.h| 73 ++ arch/x86/include/asm/arch-baytrail/irq.h | 119 + arch/x86/include/asm/arch-baytrail/irqroute.h | 67 + arch/x86/include/asm/arch-baytrail/pci_devs.h | 144 ++ arch/x86/include/asm/arch-baytrail/pmc.h | 253 ++ board/intel/minnowmax/minnowmax.c | 212 +++ include/configs/minnowmax.h | 11 + 10 files changed, 1450 insertions(+) create mode 100644 arch/x86/cpu/baytrail/gpio.c create mode 100644 arch/x86/include/asm/arch-baytrail/iomap.h create mode 100644 arch/x86/include/asm/arch-baytrail/irq.h create mode 100644 arch/x86/include/asm/arch-baytrail/irqroute.h create mode 100644 arch/x86/include/asm/arch-baytrail/pci_devs.h create mode 100644 arch/x86/include/asm/arch-baytrail/pmc.h [snip] diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h index 823e051..738c6fa 100644 --- a/include/configs/minnowmax.h +++ b/include/configs/minnowmax.h @@ -69,4 +69,15 @@ /* Avoid a warning in the Realtek Ethernet driver */ #define CONFIG_SYS_CACHELINE_SIZE 16 +/* + * Baytrail has 3 GPIOs bank over PCI, there is no + * driver at the moment so let's disable the command + * and the default x86 driver to avoid any collision + * with the GPIO mapping code. + * @TODO: adding a baytrail-gpio driver and configure + * the muxing through the device tree + */ +#undef CONFIG_INTEL_ICH6_GPIO +#undef CONFIG_CMD_GPIO + Why undef these two? The BayTrail SoC does support GPIO banks in the legacy bridge. I might misunderstood the GPIO subsystem but I thought there was 2 banks available through the PCU iLB GPIO controller which contains the SCORE and SSUS (102 / 44 pins). The intel_ich6_gpio has a limitation of 32 GPIOs per bank and I thought it was just a different controller from the Baytrail, but if I can use it to control all the GPIOs + doing the IO mapping, I'll be glad to do it! I checked the BayTrail datasheet. Its GPIO is in the iLB (legacy bridge), which is the same as other IA chipset (Ivybridge, TunnelCreek, Quark). It has 4 banks in core domain and 2 banks in sus domain. So 6 banks in total. You need define 6 gpio nodes in the minnowmax board dts file. You should be able to use the existing gpio driver to configure. Thanks for the clarification! Actually, I saw it today when I was doing some tests and I configured the 6 banks in the devices tree. I also fixed the GPIO base address to 0x48 but I got some issues like the fact I'm reading only 0 from all the registers. Yep, the offset should be 0x48 for BayTrail. The registers are configured to be in the IO Space (0x500), I checked the PCI configuration space to make sure that everything is enabled correctly, but I'm still missing something. I checked the gpio driver codes, and it currently has: /* * Okay, I guess we're looking at the right device. The actual * GPIO registers are in the PCI device's I/O space, starting * at the offset that we just read. Bit 0 indicates that it's * an I/O address, not a memory address, so mask that off. */ gpiobase = tmplong 0xfffe; This should be changed to gpiobase = tmplong 0xfffc; as bit1 is the enable bit on BayTrail (Intel changes this GPIO base register again for BayTrail, sigh...) Once I'll be able to use these GPIOs, I will update the entire patch to remove the port from Coreboot as this is not necessary. #endif /* __CONFIG_H */ -- What is the next step with this patch please? It would be good to apply it to with the changes discussed. Sorry, actually I was super busy and wasn't able to work
Re: [U-Boot] [PATCH] buildman: Make -V (verbose_build) really be verbose
Hi Tom,
On 1 April 2015 at 05:47, Tom Rini tr...@konsulko.com wrote:
The help text for -V says we will pass V=1 but all it really did was not
pass in -s. Change the logic to pass make V=1 with given to buildman -V or
-s to make otherwise.
Cc: Simon Glass s...@chromium.org
Signed-off-by: Tom Rini tr...@konsulko.com
---
tools/buildman/builderthread.py |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Simon Glass s...@chromium.org
See also:
http://patchwork.ozlabs.org/patch/437051/
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
index efb62f1..d7e7a78 100644
--- a/tools/buildman/builderthread.py
+++ b/tools/buildman/builderthread.py
@@ -197,7 +197,9 @@ class BuilderThread(threading.Thread):
src_dir = os.getcwd()
else:
args.append('O=build')
-if not self.builder.verbose_build:
+if self.builder.verbose_build:
+args.append('V=1')
+else:
args.append('-s')
if self.builder.num_jobs is not None:
args.extend(['-j', str(self.builder.num_jobs)])
--
1.7.9.5
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Pass the board serial number through devicetree
Hi Paul,
On 28 March 2015 at 11:34, Paul Kocialkowski cont...@paulk.fr wrote:
Signed-off-by: Paul Kocialkowski cont...@paulk.fr
---
common/fdt_support.c | 25 +
common/image-fdt.c| 4
include/fdt_support.h | 1 +
3 files changed, 30 insertions(+)
This needs a commit message and something in
doc/device-tree-binding/root.txt (or similar) about it.
Is there binding documentation for Linux on this?
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 8266bca..a97b4f0 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -194,6 +194,31 @@ static inline int fdt_setprop_uxx(void *fdt, int
nodeoffset, const char *name,
return fdt_setprop_u32(fdt, nodeoffset, name, (uint32_t)val);
}
+int fdt_root(void *fdt)
+{
+ char *serial;
+ int err;
+
+ err = fdt_check_header(fdt);
+ if (err 0) {
+ printf(fdt_root: %s\n, fdt_strerror(err));
+ return err;
+ }
+
+ serial = getenv(serial#);
+ if (serial) {
+ err = fdt_setprop(fdt, 0, serial-number, serial,
+ strlen(serial) + 1);
+
+ if (err 0) {
+ printf(WARNING: could not set serial-number %s.\n,
+ fdt_strerror(err));
+ return err;
+ }
+ }
+
+ return 0;
+}
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end)
{
diff --git a/common/image-fdt.c b/common/image-fdt.c
index d9e4728..1600561 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -470,6 +470,10 @@ int image_setup_libfdt(bootm_headers_t *images, void
*blob,
int ret = -EPERM;
int fdt_ret;
+ if (fdt_root(blob) 0) {
+ printf(ERROR: root node setup failed\n);
+ goto err;
+ }
if (fdt_chosen(blob) 0) {
printf(ERROR: /chosen node create failed\n);
goto err;
diff --git a/include/fdt_support.h b/include/fdt_support.h
index ae5e8a3..8eb5968 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -16,6 +16,7 @@ u32 fdt_getprop_u32_default_node(const void *fdt, int off,
int cell,
const char *prop, const u32 dflt);
u32 fdt_getprop_u32_default(const void *fdt, const char *path,
const char *prop, const u32 dflt);
+int fdt_root(void *fdt);
int fdt_chosen(void *fdt);
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end);
void do_fixup_by_path(void *fdt, const char *path, const char *prop,
--
1.9.1
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
