April 2014 - U-Boot

[U-Boot] [PATCH] usb: gadget: allow ci_udc to build with new gadget framework
by Stephen Warren 28 Apr '14

28 Apr '14

From: Stephen Warren <swarren(a)nvidia.com> Allow ci_udc.o to be built when using the new(?) USB gadget framework, as enabled by CONFIG_USB_GADGET. Note that this duplicates the Makefile entry for ci_udc.o, since it's also included inside #ifdef CONFIG_USB_ETHER. I'm not sure what that define means; perhaps an old style of Ethernet-specific USB gadget implementation? I wonder if the line that this patch adds shouldn't be outside all of the ifdefs, so it stands on its own, similar to how e.g. epautoconf.o is shared between the two? Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- drivers/usb/gadget/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 804a2bd412dd..896c8d407e4b 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -13,6 +13,7 @@ ifdef CONFIG_USB_GADGET obj-$(CONFIG_USB_GADGET_ATMEL_USBA) += atmel_usba_udc.o obj-$(CONFIG_USB_GADGET_S3C_UDC_OTG) += s3c_udc_otg.o obj-$(CONFIG_USB_GADGET_FOTG210) += fotg210.o +obj-$(CONFIG_CI_UDC) += ci_udc.o obj-$(CONFIG_THOR_FUNCTION) += f_thor.o obj-$(CONFIG_USBDOWNLOAD_GADGET) += g_dnl.o obj-$(CONFIG_DFU_FUNCTION) += f_dfu.o -- 1.8.1.5

1 0

[U-Boot] [PATCH v4 0/6] PPC 85xx: Add support for QEMU's ppce500 PV machine
by Alexander Graf 28 Apr '14

28 Apr '14

In QEMU we implement a PV machine type called "ppce500". That board is able to run any e500+ FSL cores (e500v2, e500mc, e5500, e6500). It is heavily inspired by the MPC8544DS SoC and board combination, but implements only the bare minimum to make Linux happy enough to drive a virtual machine. This patch set implements support for this PV machine type in U-Boot, enabling users to run their virtual machines with netboot, u-boot payload binaries or other fun things they come up with. --- v1 -> v2: - Write device tree offset directly into global variable - use r4 rather than r2 for that - access fdt directly from in-memory copy - remove unneeded header includes - clean up pci enumeration - coding style fixes - populate and only use fdt_addr_r - remove unused exported functions - remove unused TLB0 entries - make TLB1 I/O maps non-executable - remove unused defines in board header - make -kernel boot variables more clear - remove TLB0 invalidation - use tlb1.14 for temporary as=1 map - use CONFIG_SYS_MPC85XX_NO_RESETVEC - store fdt pointer in gd through cpu_init_early_f() - replace fixup_tlb1() with dynamic TLB creation hook - find CCSRBAR from device tree - find PCI controllers from device tree - find CPU speed from device tree v2 -> v3: - new patch: fdt_support: split fdt_getprop_u32_default - new patch: fdt_support: Add helper function to read "ranges" property - new patch: PPC: 85xx: Remove IVOR reset - removed patch: PPC 85xx: Detect e500v2 / e500mc during runtime - merge dt patches into machine patch - Document and rename CONFIG_SYS_USE_DYNAMIC_TLBS - remove CONFIG_DDR_SPD - Reduce PCI message to only base address - Map AS=1 fdt behind CCSRBAR - Use CONFIG_SYS_CCSR_DO_NOT_RELOCATE - remove unnecessary ccsr map - s/cell size/cell count/ - add temporary map define - use fdt_get_base_address() to find region - use new APIs - remove myfdt helpers v3 -> v4: - tlb_map_range: return unmapped size - tlb_map_range: take ram/io parameter as enum rather than bool - use new tlb map syntax - check that tlb map mapped everything - always save/restore r3 for cpu_init_early_f - remove CONFIG_DYNAMIC_CCSRBAR - make init_tlbs weak and remove all init_tlbs_dynamic() cruft - always map fdt to fixed virtual address - fold together AS=1 fdt map functions - use tlb_map_range for CCSR map - search for PCI based on device type rather than compatible - remove unnecessary cast - call get_linear_ram_size directly - override get_tbclk with timebase-frequency fetching code Alexander Graf (6): fdt_support: split fdt_getprop_u32_default fdt_support: Add helper function to read "ranges" property PPC: 85xx: Remove IVOR reset PPC: 85xx: Generalize DDR TLB mapping function PPC 85xx: Add ELF entry point PPC 85xx: Add qemu-ppce500 machine arch/powerpc/cpu/mpc85xx/Makefile | 2 + arch/powerpc/cpu/mpc85xx/cpu.c | 4 +- arch/powerpc/cpu/mpc85xx/cpu_init.c | 4 - arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 8 +- arch/powerpc/cpu/mpc85xx/fixed_ivor.S | 63 ----- arch/powerpc/cpu/mpc85xx/release.S | 3 - arch/powerpc/cpu/mpc85xx/start.S | 17 +- arch/powerpc/cpu/mpc85xx/tlb.c | 48 ++-- arch/powerpc/cpu/mpc85xx/u-boot.lds | 1 + arch/powerpc/include/asm/config_mpc85xx.h | 4 + arch/powerpc/include/asm/mmu.h | 8 + board/freescale/qemu-ppce500/Makefile | 9 + board/freescale/qemu-ppce500/qemu-ppce500.c | 345 ++++++++++++++++++++++++++ boards.cfg | 1 + common/fdt_support.c | 132 +++++++++- include/configs/qemu-ppce500.h | 203 +++++++++++++++ include/fdt_support.h | 4 + nand_spl/board/freescale/mpc8536ds/Makefile | 4 - nand_spl/board/freescale/mpc8569mds/Makefile | 4 - nand_spl/board/freescale/mpc8572ds/Makefile | 4 - nand_spl/board/freescale/p1023rds/Makefile | 4 - nand_spl/board/freescale/p1_p2_rdb/Makefile | 4 - 22 files changed, 757 insertions(+), 119 deletions(-) delete mode 100644 arch/powerpc/cpu/mpc85xx/fixed_ivor.S create mode 100644 board/freescale/qemu-ppce500/Makefile create mode 100644 board/freescale/qemu-ppce500/qemu-ppce500.c create mode 100644 include/configs/qemu-ppce500.h -- 1.7.10.4

3 12

Re: [U-Boot] IPv6 in U-BOOT
by chris packham 28 Apr '14

28 Apr '14

Hi, >>> On 29/4/2014 at 05:01 AM, "Jean-Pierre TOSONI" <jp.tosoni(a)acksys.fr> wrote: > Hello Chris, > > I am looking for IPv6 support in U-Boot. I saw that you made some work > about it last year. > > Did you obtain a working IPv6 ? Is it available somewhere ? > I've got it to a point where it is possible to process ICMPv6 echos (ping6). My next planned step was to get tftp to work over IPv6. Unfortunately $life and $dayjob have got in the way and I haven't been able to spend the time I would like to on it. I don't think it's actually far off getting tftp working but getting the code into shape where it's acceptable to Joe and Wolfgang/Tom might take a bit of work. My code is up on github https://github.com/cpackham/u-boot/tree/ipv6 I haven't rebased against u-boot master for a while so it's fairly out of date. If there is enough interest I'd be happy to put some more work into this. I could try to convince my employer to let me spend some work time on it. > > Thanks for your time, > > Jean-Pierre Tosoni

1 0

[U-Boot] [PATCH v3 0/9] sunxi: initial upstreamining effort
by Ian Campbell 28 Apr '14

28 Apr '14

This is my third cut at an upstreamable series based upon the https://github.com/linux-sunxi/u-boot-sunxi.git#sunxi tree. The intention is to present a minimal starting point for upstreaming to which support for other processors, peripherals, boards etc can be added in the future. Therefore this has been stripped right back and currently supports only sun7i processors (AKA Allwinner A20) and the cubietruck board. Supported peripherals are UART, MMC and Ethernet. The code here is from u-boot-sunxi.git#sunxi[0] changeset based on c89867dca2e9 "sunxi: clocks: clock_get_pll5 prototype and coding style" and applies to u-boot v2014.04. Global changes in v3: - Rebased onto v2014.04 and resynced with u-boot-sunxi.git c89867dca2e9 - Improved commit messages - Updated lists of contributors - Added some CCs - Lots of cleanup based on review comments. Global changes in v2: - Use SPDX-License-Identifier - Resync with u-boot-sunxi.git - Lot of updates to the individual patches, see the individual commit messages (checkpatch.pl fixes, magic number removal etc). - Pulled the Ethernet stuff before the MMC and non-FEL boot stuff. The MMC stuff (which non-FEL boot needs) still needs some more cleanup, but the reordering means that the initial part of the series could in principal go in. This series can also be found at: git://gitorious.org/ijc/u-boot.git sunxi-mainlining-v3 There is no SMP here, since that relies on the PSCI support from Marc Zyngier which has yet to land in mainline. Marc has recently rebased and a version based on this series can be found at: git://gitorious.org/ijc/u-boot.git sunxi-mainlining-v3-smp I've tried to give corect credit and S-o-b based upon: git log --pretty='%aN' linux-sunxi/sunxi -- [PATHS] | sort -u git log linux-sunxi/sunxi -- [PATHS] | grep -i signed.off.by | sort -u Manual inspection This will tend to over credit, since it will include folks who contributed code which has since been removed as well as those who contributed code which is not included in this patch set, but I think it is better to be conservative and include too many rather than incorrectly exclude people. Doing better than this would be IMHO too hard to be worth it (e.g. git blame would prefer a recent whitespace cleanup to the actual author of the code and prefer someone did code motion over the original author, so it would be a massive & manual process). [0] https://github.com/linux-sunxi/u-boot-sunxi.git

4 34

[U-Boot] [PATCH v2 1/2] net/designware: ensure device private data is DMA aligned.
by Ian Campbell 28 Apr '14

28 Apr '14

struct dw_eth_dev contains fields which are accessed via DMA, so make sure it is aligned to a dma boundary. Without this I see: ERROR: v7_dcache_inval_range - start address is not aligned - 0x7fb677e0 Signed-off-by: Ian Campbell <ijc(a)hellion.org.uk> Reviewed-by: Alexey Brodkin <abrodkin(a)synopsys.com> Acked-by: Marek Vasut <marex(a)denx.de> --- v2: Sign of with my own mail not my work mail. I made these changes on my own time, but a .gitconfig vcsh mismerge caused "git commit -s" to use the wrong thing. (I wondered why everyone was CCing me at work...) --- drivers/net/designware.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/designware.c b/drivers/net/designware.c index 9824b42..b70df82 100644 --- a/drivers/net/designware.c +++ b/drivers/net/designware.c @@ -414,7 +414,8 @@ int designware_initialize(ulong base_addr, u32 interface) * Since the priv structure contains the descriptors which need a strict * buswidth alignment, memalign is used to allocate memory */ - priv = (struct dw_eth_dev *) memalign(16, sizeof(struct dw_eth_dev)); + priv = (struct dw_eth_dev *) memalign(ARCH_DMA_MINALIGN, + sizeof(struct dw_eth_dev)); if (!priv) { free(dev); return -ENOMEM; -- 1.9.0

1 0

[U-Boot] [PATCH] nitrogen6x: Fix the PAD settings for the ECSPI chipselect
by Fabio Estevam 28 Apr '14

28 Apr '14

From: Fabio Estevam <fabio.estevam(a)freescale.com> ECSPI chipselect (MX6_PAD_EIM_D19__GPIO3_IO19) is used with GPIO functionality, so it does not make sense to set its pad as SPI pin. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Eric, This is untested. board/boundary/nitrogen6x/nitrogen6x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/boundary/nitrogen6x/nitrogen6x.c b/board/boundary/nitrogen6x/nitrogen6x.c index d9c05b0..f2492e4 100644 --- a/board/boundary/nitrogen6x/nitrogen6x.c +++ b/board/boundary/nitrogen6x/nitrogen6x.c @@ -331,7 +331,7 @@ int board_mmc_init(bd_t *bis) #ifdef CONFIG_MXC_SPI iomux_v3_cfg_t const ecspi1_pads[] = { /* SS1 */ - MX6_PAD_EIM_D19__GPIO3_IO19 | MUX_PAD_CTRL(SPI_PAD_CTRL), + MX6_PAD_EIM_D19__GPIO3_IO19 | MUX_PAD_CTRL(NO_PAD_CTRL), MX6_PAD_EIM_D17__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL), MX6_PAD_EIM_D18__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL), MX6_PAD_EIM_D16__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL), -- 1.8.3.2

4 7

[U-Boot] [PATCH] mx6slevk: Add SPI NOR flash support
by Fabio Estevam 28 Apr '14

28 Apr '14

From: Fabio Estevam <fabio.estevam(a)freescale.com> mx6slevk has a m25p32 SPI NOR flash connected to ESCSPI port. Add support for it. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- arch/arm/include/asm/arch-mx6/mx6sl_pins.h | 4 ++++ board/freescale/mx6slevk/mx6slevk.c | 20 ++++++++++++++++++++ include/configs/mx6slevk.h | 12 ++++++++++++ 3 files changed, 36 insertions(+) diff --git a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h index 5f9c90a..045ccc4 100644 --- a/arch/arm/include/asm/arch-mx6/mx6sl_pins.h +++ b/arch/arm/include/asm/arch-mx6/mx6sl_pins.h @@ -10,6 +10,10 @@ #include <asm/imx-common/iomux-v3.h> enum { + MX6_PAD_ECSPI1_MISO__ECSPI_MISO = IOMUX_PAD(0x0358, 0x0068, 0, 0x0684, 0, 0), + MX6_PAD_ECSPI1_MOSI__ECSPI_MOSI = IOMUX_PAD(0x035C, 0x006C, 0, 0x0688, 0, 0), + MX6_PAD_ECSPI1_SCLK__ECSPI_SCLK = IOMUX_PAD(0x0360, 0x0070, 0, 0x067C, 0, 0), + MX6_PAD_ECSPI1_SS0__GPIO4_IO11 = IOMUX_PAD(0x0364, 0x0074, 5, 0x0000, 0, 0), MX6_PAD_SD2_CLK__USDHC2_CLK = IOMUX_PAD(0x055C, 0x0254, 0, 0x0000, 0, 0), MX6_PAD_SD2_CMD__USDHC2_CMD = IOMUX_PAD(0x0560, 0x0258, 0, 0x0000, 0, 0), MX6_PAD_SD2_DAT0__USDHC2_DAT0 = IOMUX_PAD(0x0564, 0x025C, 0, 0x0000, 0, 0), diff --git a/board/freescale/mx6slevk/mx6slevk.c b/board/freescale/mx6slevk/mx6slevk.c index aadad32..d2b64cc 100644 --- a/board/freescale/mx6slevk/mx6slevk.c +++ b/board/freescale/mx6slevk/mx6slevk.c @@ -34,6 +34,9 @@ DECLARE_GLOBAL_DATA_PTR; PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \ PAD_CTL_DSE_40ohm | PAD_CTL_HYS) +#define SPI_PAD_CTRL (PAD_CTL_HYS | PAD_CTL_SPEED_MED | \ + PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST) + #define ETH_PHY_RESET IMX_GPIO_NR(4, 21) int dram_init(void) @@ -71,6 +74,20 @@ static iomux_v3_cfg_t const fec_pads[] = { MX6_PAD_FEC_TX_CLK__GPIO_4_21 | MUX_PAD_CTRL(NO_PAD_CTRL), }; +#ifdef CONFIG_MXC_SPI +static iomux_v3_cfg_t ecspi1_pads[] = { + MX6_PAD_ECSPI1_MISO__ECSPI_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL), + MX6_PAD_ECSPI1_MOSI__ECSPI_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL), + MX6_PAD_ECSPI1_SCLK__ECSPI_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL), + MX6_PAD_ECSPI1_SS0__GPIO4_IO11 | MUX_PAD_CTRL(NO_PAD_CTRL), +}; + +static void setup_spi(void) +{ + imx_iomux_v3_setup_multiple_pads(ecspi1_pads, ARRAY_SIZE(ecspi1_pads)); +} +#endif + static void setup_iomux_uart(void) { imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads)); @@ -132,6 +149,9 @@ static int setup_fec(void) int board_early_init_f(void) { setup_iomux_uart(); +#ifdef CONFIG_MXC_SPI + setup_spi(); +#endif return 0; } diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h index 1876dbf..3d05a64 100644 --- a/include/configs/mx6slevk.h +++ b/include/configs/mx6slevk.h @@ -10,6 +10,7 @@ #define __CONFIG_H #include <asm/arch/imx-regs.h> +#include <asm/imx-common/gpio.h> #include <linux/sizes.h> #include "mx6_common.h" @@ -196,4 +197,15 @@ #define CONFIG_CMD_CACHE #endif +#define CONFIG_CMD_SF +#ifdef CONFIG_CMD_SF +#define CONFIG_SPI_FLASH +#define CONFIG_SPI_FLASH_STMICRO +#define CONFIG_MXC_SPI +#define CONFIG_SF_DEFAULT_BUS 0 +#define CONFIG_SF_DEFAULT_CS (0 | (IMX_GPIO_NR(4, 11) << 8)) +#define CONFIG_SF_DEFAULT_SPEED 20000000 +#define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 +#endif + #endif /* __CONFIG_H */ -- 1.8.3.2

5 10

[U-Boot] Failure on attempt to build env tools
by Alexey Brodkin 28 Apr '14

28 Apr '14

Hi Marek, I noticed you recently committed support of AES encryption in U-Boot tools here - http://git.denx.de/?p=u-boot.git;a=commit;h=a8a752c084031905940129f8a6ba303… And now I cannot build env tools. Here's how to reproduce my experience: =============== $ make yourboard_config $ make env make[1]: *** No rule to make target `tools/env/aes.c', needed by `tools/env/aes.o'. Stop. make: *** [env] Error 2 =============== And from tools/env/Makefile I see that target "aes.o" exists while "aes.c" itself is situated in "./lib" folder. Could you please try to build env tools and if you see the same error could you please fix it? If it's me who builds env tools improperly could you please teach me how to build them correctly? -- Best regards, Alexey Brodkin

2 1

Re: [U-Boot] [PATCH v9 1/2] S5P: Exynos: Add GPIO pin numbering and rename definitions
by Akshay Saraswat 28 Apr '14

28 Apr '14

Hi Przemyslaw Marczak, >Hi, > >On 04/21/2014 04:25 PM, Akshay Saraswat wrote: >> This patch includes following changes : >> * Adds gpio pin numbering support for EXYNOS SOCs. >> To have consistent 0..n-1 GPIO numbering the banks are divided >> into different parts where ever they have holes in them. >> >> * Rename GPIO definitions from GPIO_... to S5P_GPIO_... >> These changes were done to enable cmd_gpio for EXYNOS and >> cmd_gpio has GPIO_INPUT same as s5p_gpio driver and hence >> getting a error during compilation. >> >> * Adds support for name to gpio conversion in s5p_gpio to enable >> gpio command EXYNOS SoCs. Function has been added to asm/gpio.h >> to decode the input gpio name to gpio number. >> Example: SMDK5420 # gpio set gpa00 >> >> Signed-off-by: Leela Krishna Amudala <l.krishna(a)samsung.com> >> Signed-off-by: Rajeshwari Shinde <rajeshwari.s(a)samsung.com> >> Signed-off-by: Akshay Saraswat <akshay.s(a)samsung.com> >> --- >> arch/arm/cpu/armv7/exynos/pinmux.c | 403 +++---- >> arch/arm/include/asm/arch-exynos/cpu.h | 17 +- >> arch/arm/include/asm/arch-exynos/gpio.h | 1786 +++++++++++++++++++++++++----- >> arch/arm/include/asm/arch-s5pc1xx/gpio.h | 941 +++++++++++++--- >> board/samsung/arndale/arndale.c | 11 +- >> board/samsung/goni/goni.c | 26 +- >> board/samsung/smdk5250/exynos5-dt.c | 20 +- >> board/samsung/smdk5250/smdk5250.c | 19 +- >> board/samsung/smdk5420/smdk5420.c | 15 +- >> board/samsung/smdkc100/smdkc100.c | 5 +- >> board/samsung/smdkv310/smdkv310.c | 17 +- >> board/samsung/trats/trats.c | 39 +- >> board/samsung/trats2/trats2.c | 74 +- >> board/samsung/universal_c210/universal.c | 51 +- >> drivers/gpio/s5p_gpio.c | 195 +++- >> 15 files changed, 2778 insertions(+), 841 deletions(-) >> >> diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c >> index 11a0472..a93928a 100644 >> --- a/drivers/gpio/s5p_gpio.c >> +++ b/drivers/gpio/s5p_gpio.c >> @@ -8,11 +8,12 @@ >> #include <common.h> >> #include <asm/io.h> >> #include <asm/gpio.h> >> +#include <asm/arch-exynos/gpio.h> >This is common driver, so it should be: > >#include <asm/arch/gpio.h> > Will fix it in the next patch-set. >> #define S5P_GPIO_GET_BANK(x) ((x >> S5P_GPIO_BANK_SHIFT) \ >> & S5P_GPIO_BANK_MASK) >> >> -#define S5P_GPIO_GET_PIN(x) (x & S5P_GPIO_PIN_MASK) >> +#define S5P_GPIO_GET_PIN(x) ((x & S5P_GPIO_PIN_MASK) % GPIO_PER_BANK) > >And again...we don't need above macros, we can use now linear numbering. > Yes, you are right we don't need S5P_GPIO_GET_BANK but we are still using S5P_GPIO_GET_PIN. Will fix it. > >> +#ifdef HAVE_GENERIC_GPIO >> +struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned int gpio) >> +{ >> + const struct gpio_info *data; >> + unsigned int upto; >> + int i, count; >> + >> + data = get_gpio_data(); >> + count = get_bank_num(); >> + for (i = upto = 0; i < count; >> + i++, upto = data->max_gpio, data++) { >> + debug("i=%d, upto=%d\n", i, upto); >> + if (gpio < data->max_gpio) { >> + struct s5p_gpio_bank *bank; >> + bank = (struct s5p_gpio_bank *)data->reg_addr; >> + bank += (gpio - upto) / GPIO_PER_BANK; >> + debug("gpio=%d, bank=%p\n", gpio, bank); >> + return bank; >> + } >> + } >> + return NULL; >> +} >> +#else > >You are using exynos_gpio_get() in code but this function is not >compiled. Again please remove it. > Yes, #else part is not being used, I can get rid of this. But I can't see exynos_gpio_get() call here. >> struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned gpio) >> { >> unsigned bank = S5P_GPIO_GET_BANK(gpio); >> @@ -134,6 +252,7 @@ struct s5p_gpio_bank *s5p_gpio_get_bank(unsigned gpio) >> >> return (struct s5p_gpio_bank *)(base + bank); >> } >> +#endif > >Thanks > >-- >Przemyslaw Marczak >Samsung R&D Institute Poland >Samsung Electronics >p.marczak(a)samsung.com > Regards, Akshay Saraswat

2 1

Re: [U-Boot] [PATCH v9 0/2] S5P: Exynos: Add GPIO numbering feature
by Akshay Saraswat 28 Apr '14

28 Apr '14

Hi Przemyslaw Marczak, >Hello, > >On 04/21/2014 04:25 PM, Akshay Saraswat wrote: >> Used a script to recheck/verify pin mapping and existing mapping >> appears to be fine, returning correct bank and pin values. >> Did ./MAKEALL -a arm and found all Exynos/S5P related boards >> compiled successfully. >> Couldn't test booting over all of them. >> Tested U-Boot bootup over SMDK5420, SMDK5250, Snow. >> Requesting maintaners to please test over affected SoCs/boards. >> >> Changes in V2: >> - Enabled CMD_GPIO as suggested by Simon Glass >> and supported same for EXYNOS5. >> Changes in V3: >> - New patch added to rename S5P GPIO definitions >> to S5P_GPIO. >> - GPIO Table added to calculate the base address >> of input gpio bank. >> Changes in V4: >> - To have consistent 0..n-1 GPIO numbering the banks >> are divided into different parts where ever they >> have holes in them. >> - Function and table to support gpio command moved >> to s5p-gpio driver. >> - Rebased on latest u-boot-samsung tree. >> Changes in V5: >> - Rebased on latest u-boot-samsung tree. >> - Removed Exynos5 specific code in gpio driver api to >> get bank. >> - Added #define HAVE_GENERIC_GPIO in config file >> to remove conditinal CPU check in gpio driver. >> Changes in V6: >> - Isolated config changes in a new patch. >> - Updated patches with corresponding changes for Exynos 5420. >> Changes in V7: >> - Added changes for other SoCs like Exynos 4412, 4210 etc. >> Changes in V8: >> - Changed Subject of patch 2/2 to reflect affected SoCs/boards. >> - Fixed arndale board compile time errors introduced due to >> patch-set v7. >> Changes in V9: >> - Fixed checkpatch errors. >> - Fixed naming error in exynosxxxx_gpio_data arrays which could >> be the possible reason behind data abort witnessed over >> Exynos4 boards. >> >> Akshay Saraswat (2): >> EXYNOS: Add GPIO pin numbering and rename definitions >> S5P: Exynos: Config: Enable Generic GPIO and CMD configs >> >> arch/arm/cpu/armv7/exynos/pinmux.c | 403 +++---- >> arch/arm/include/asm/arch-exynos/cpu.h | 17 +- >> arch/arm/include/asm/arch-exynos/gpio.h | 1786 +++++++++++++++++++++++++----- >> arch/arm/include/asm/arch-s5pc1xx/gpio.h | 941 +++++++++++++--- >> board/samsung/arndale/arndale.c | 11 +- >> board/samsung/goni/goni.c | 26 +- >> board/samsung/smdk5250/exynos5-dt.c | 20 +- >> board/samsung/smdk5250/smdk5250.c | 19 +- >> board/samsung/smdk5420/smdk5420.c | 15 +- >> board/samsung/smdkc100/smdkc100.c | 5 +- >> board/samsung/smdkv310/smdkv310.c | 17 +- >> board/samsung/trats/trats.c | 39 +- >> board/samsung/trats2/trats2.c | 74 +- >> board/samsung/universal_c210/universal.c | 51 +- >> drivers/gpio/s5p_gpio.c | 195 +++- >> include/configs/arndale.h | 1 + >> include/configs/exynos5-dt.h | 3 + >> include/configs/origen.h | 1 + >> include/configs/s5p_goni.h | 5 +- >> include/configs/s5pc210_universal.h | 17 +- >> include/configs/smdkc100.h | 1 + >> include/configs/smdkv310.h | 2 + >> include/configs/trats.h | 9 +- >> include/configs/trats2.h | 5 +- >> 24 files changed, 2806 insertions(+), 857 deletions(-) >> > >I think that you missed my last few comments. >You are still using exynos_gpio_get() - what for? >It returns some number and next it's interpreted as >gpio continuous number - but it isn't continuous. >It's because each samsung board has now defined "HAVE_GENERIC_GPIO", >so gpio numbers are interpreted as linear. >We don't need additional macro since you introduce linear numbering. > >Please read my last comments again. I have read your comments and replied to it. I am sorry may be I was not clear. Please look at the patch-set 2/2 again, I am not introducing I just replaced bank and pin number with sequential pin number. exynos_gpio_get() function was already there. I can't afford to remove it because I2C driver uses it and also I don't have boards to test outcomes of such changes. In opinion it would be better if the maintainer of the board could do these changes. > >I tried test this on trats2 device but data abort occurs at PMIC init, >it's probably because exynos_gpio_get(). Please use just gpio numbering >as you defined in this patchset. > As far as I could understand, exynos_gpio_get still returns what it used to before this patch because we still extract bank and pin number from linear number to do the needfull. But I will definitely try to look for the bug. Thanks for the suggestion. > >Thank you >-- >Przemyslaw Marczak >Samsung R&D Institute Poland >Samsung Electronics >p.marczak(a)samsung.com Regards, Akshay Saraswat

2 1