[U-Boot] [PATCH 0/2 V5] spi: Enable SPI_PREAMBLE Mode
This patch set enables PREAMBLE Mode for EXYNOS SPI. Changes in v2: - Remove preamable_count variable which is not really needed - Fix checkpatch warning (multiple assignments) Changes in V3: - Modified the if logic in spi_rx_tx function - Added blank lines as suggested by Minkyu Kang. - Removed in_bytes check in while loop. - Added a error check. Changes in V4: - Corrected a if condition. Changes in V5: - In commit message header changed SPI to spi EXYNOS: SPI: to spi: exynos: Rajeshwari Shinde (2): spi: Add support for preamble bytes spi: exynos: Support SPI_PREAMBLE mode drivers/spi/exynos_spi.c | 69 +++-- include/spi.h|5 +++ 2 files changed, 64 insertions(+), 10 deletions(-) -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 V5] spi: Add support for preamble bytes
A SPI slave may take time to react to a request. For SPI flash devices this time is defined as one bit time, or a whole byte for 'fast read' mode. If the SPI slave is another CPU, then the time it takes to react may vary. It is convenient to allow the slave device to tag the start of the actual reply so that the host can determine when this 'preamble' finishes and the actual message starts. Add a preamble flag to the available SPI flags. If supported by the driver then it will ignore any received bytes before the preamble on each transaction. This ensures that reliable communication with the slave is possible. Signed-off-by: Simon Glass s...@chromium.org Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com --- Changes in V2: - None Changes in V3: - None. Changes in V4: - None. Changes in V5: - In commit message header changed SPI to spi. include/spi.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/spi.h b/include/spi.h index 3fe2e1e..1638b50 100644 --- a/include/spi.h +++ b/include/spi.h @@ -37,11 +37,16 @@ #defineSPI_LSB_FIRST 0x08/* per-word bits-on-wire */ #defineSPI_3WIRE 0x10/* SI/SO signals shared */ #defineSPI_LOOP0x20/* loopback mode */ +#defineSPI_SLAVE 0x40/* slave mode */ +#defineSPI_PREAMBLE0x80/* Skip preamble bytes */ /* SPI transfer flags */ #define SPI_XFER_BEGIN 0x01/* Assert CS before transfer */ #define SPI_XFER_END 0x02/* Deassert CS after transfer */ +/* Header byte that marks the start of the message */ +#define SPI_PREAMBLE_END_BYTE 0xec + /*--- * Representation of a SPI slave, i.e. what we're communicating with. * -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 V5] spi: exynos: Support SPI_PREAMBLE mode
Support interfaces with a preamble before each received message.
We handle this when the client has requested a SPI_XFER_END, meaning
that we must close of the transaction. In this case we read until we
see the preamble (or a timeout occurs), skipping all data before and
including the preamble. The client will receive only data bytes after
the preamble.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Remove preamable_count variable which is not really needed
- Fix checkpatch warning (multiple assignments)
Changes in V3:
- Modified the if logic in spi_rx_tx function
- Added blank lines as suggested by Minkyu Kang.
- Removed in_bytes check in while loop.
- Added a error check.
Changes in V4:
- Corrected a if condition.
Changes in V5:
- In commit message header changed EXYNOS: SPI: to spi:exynos.
drivers/spi/exynos_spi.c | 69 +++--
1 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index 607e1cd..01378d0 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -51,6 +51,7 @@ struct exynos_spi_slave {
unsigned int mode;
enum periph_id periph_id; /* Peripheral ID for this device */
unsigned int fifo_size;
+ int skip_preamble;
};
static struct spi_bus *spi_get_bus(unsigned dev_index)
@@ -105,6 +106,8 @@ struct spi_slave *spi_setup_slave(unsigned int busnum,
unsigned int cs,
else
spi_slave-fifo_size = 256;
+ spi_slave-skip_preamble = 0;
+
spi_slave-freq = bus-frequency;
if (max_hz)
spi_slave-freq = min(max_hz, spi_slave-freq);
@@ -217,17 +220,23 @@ static void spi_request_bytes(struct exynos_spi *regs,
int count)
writel(count | SPI_PACKET_CNT_EN, regs-pkt_cnt);
}
-static void spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
- void **dinp, void const **doutp)
+static int spi_rx_tx(struct exynos_spi_slave *spi_slave, int todo,
+ void **dinp, void const **doutp, unsigned long flags)
{
struct exynos_spi *regs = spi_slave-regs;
uchar *rxp = *dinp;
const uchar *txp = *doutp;
int rx_lvl, tx_lvl;
uint out_bytes, in_bytes;
+ int toread;
+ unsigned start = get_timer(0);
+ int stopping;
out_bytes = in_bytes = todo;
+ stopping = spi_slave-skip_preamble (flags SPI_XFER_END)
+ !(spi_slave-mode SPI_SLAVE);
+
/*
* If there's something to send, do a software reset and set a
* transaction size.
@@ -238,6 +247,8 @@ static void spi_rx_tx(struct exynos_spi_slave *spi_slave,
int todo,
* Bytes are transmitted/received in pairs. Wait to receive all the
* data because then transmission will be done as well.
*/
+ toread = in_bytes;
+
while (in_bytes) {
int temp;
@@ -248,15 +259,43 @@ static void spi_rx_tx(struct exynos_spi_slave *spi_slave,
int todo,
writel(temp, regs-tx_data);
out_bytes--;
}
- if (rx_lvl 0 in_bytes) {
+ if (rx_lvl 0) {
temp = readl(regs-rx_data);
- if (rxp)
- *rxp++ = temp;
- in_bytes--;
+ if (spi_slave-skip_preamble) {
+ if (temp == SPI_PREAMBLE_END_BYTE) {
+ spi_slave-skip_preamble = 0;
+ stopping = 0;
+ }
+ } else {
+ if (rxp || stopping)
+ *rxp++ = temp;
+ in_bytes--;
+ }
+ toread--;
+ } else if (!toread) {
+ /*
+* We have run out of input data, but haven't read
+* enough bytes after the preamble yet. Read some more,
+* and make sure that we transmit dummy bytes too, to
+* keep things going.
+*/
+ assert(!out_bytes);
+ out_bytes = in_bytes;
+ toread = in_bytes;
+ txp = NULL;
+ spi_request_bytes(regs, toread);
+ }
+ if (spi_slave-skip_preamble get_timer(start) 100) {
+ printf(SPI timeout: in_bytes=%d, out_bytes=%d, ,
+ in_bytes, out_bytes);
+ return -1;
}
}
+
*dinp = rxp;
*doutp =
Re: [U-Boot] [PATCH v4 1/7] arm: vf610: Add IOMUX support for Vybrid VF610
On 29/05/2013 07:29, Wang Huan-B18965 wrote: Where is this one defined? I don't see it in include/configs/vf610twr.h. [Alison Wang] CONFIG_IOMUX_SHARE_CONF_REG is defined in arch/arm/include/asm/arch-vf610/imx-regs.h. Because this is not a board configuration, it is related to the SOC. Please refer to Stefano's comments below which also could be found in the email on May 15th. Stefano wrote: + +/* MUX mode and PAD ctrl are in one register */ +#define CONFIG_IOMUX_SHARE_CONF_REG NAK. This is not a board configuration, it is related to the SOC. This setup should flow into the related imx-regs.h for this SOC. When you set CONFIG_MVF600, this value should be set automatically. Why not use #ifdef CONFIG_VF610 since this is a platform-dependent code, and not a board-specific config option? [Alison Wang] I use this CONFIG_IOMUX_SHARE_CONF_REG option, because this part of codes not only could be used on VF610 platform, but also could be used on VF620 or other platforms. When it is used on VF620 or others, you could just enable CONFIG_IOMUX_SHARE_CONF_REG in the related imx-regs.h. Otherwise, if ifdef CONFIG_VF610 is used, you need to add #if defined(CONFIG_VF610) || defined(CONFIG_VF620) When this part of codes is also used on VF620. Then when this part of codes is used on VF630 too, this line will be very very long. Agree. This is a property of the processor and should be automatically set. It should not flow into board config file, and having a family of processor we cannot use ifdef CONFIG_VF610. IMHO the patch is ok. Acked-by: Stefano Babic sba...@denx.de Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 0/9] EXYNOS5: Enable DWMMC, add FDT support for DWMMC and enable EMMC boot
Hi Andy, U seem to be busy. I you have no issues can I ask Minkyu Kang to take them in u-boot-samsung tree. Please do reply. -- Regards, Rajeshwari Shinde On Fri, May 24, 2013 at 11:16 AM, Rajeshwari Birje rajeshwari.bi...@gmail.com wrote: Hi Andy, Please do let us know if any comments on this patch set. If no comments can we get them merged, as they seem to be floating in mainline for quite sometime now. Regards, Rajeshwari Shinde On Sat, May 11, 2013 at 8:55 AM, Simon Glass s...@chromium.org wrote: On Sat, Apr 27, 2013 at 12:12 AM, amar_g amarendra...@samsung.com wrote: From: Amar amarendra...@samsung.com This patch set enables and initialises DWMMC for Exynos5250 on SMDK5250. Adds driver changes required for DWMMC. Adds FDT support for DWMMC. Adds EMMC boot support for SMDK5250. This patch set is based on: EXYNOS: mmc: support DesignWare Controller for Samsung-SoC, which is merged in u-boot-mmc. Exynos: clock: support get_mmc_clk for exynos. Add DT based ethernet driver for SMDK5250. SMDK5250: Add FDT support present at the following link http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/149991 Changes since V1: 1)Corrected in response to review comments. 2)Created separate board files for FDT and non-FDT versions. 3)Added binding file for DWMMC device node. 4)Removed the propname 'index' from device node. 5)Prefixed the vendor name 'samsung' before propname in device node. 6)Ensured to have same signature for the function exynos_dwmci_init() for both FDT and non-FDT versions. 7)EMMC clock setting has been moved from spl_boot.c to clock_init.c. Changes since V2: 1)Updation of commit message and resubmition of proper patch set. Changes since V3: 1)Updated to use the macro DWMCI_CTRL_SEND_AS_CCSD instead of the hard coded value (1 10). 2)In the file exynos_dw_mmc.c, replaced the new function exynos5_mmc_set_clk_div() with the existing function set_mmc_clk(). set_mmc_clk() will do the purpose. 3)In the file exynos_dw_mmc.c, computation of FSYS block clock divisor (pre-ratio) value is added. 4)Removed the new function exynos5_mmc_set_clk_div() from clock.c. Changes since V4: 1)Updated the function dwmci_send_cmd() to use get_timer() instead of using mdelay(1). 2)Replaced the function call 'exynos_dwmmc_init(0, 8);' with the function exynos_dwmmc_add_port() in smdk5250.c. 3)The function get_irom_func(int index) has been added to avoid type casting at many places. 4)Used the generic function mmc_boot_part_access() instead of two functions mmc_boot_open() and mmc_boot_close(). By doing so user can specify which boot partition to be accessed (opened / closed). Changes since V5: 1)Added the 'removable' flag to mmc device node. 2)Changed the mmc clock value from 50MHz to 52MHz in the function exynos_dwmci_add_port() present in file drivers/mmc/exynos_dw_mmc.c. 3)Enabled CONFIG_LCD only for non-FDT operation. 4)Removed the function call i2c_init() present inside the function board_i2c_init(). Changes since V6: 1)Re-based to the patch SMDK5250: Add PMIC voltage settings. Changes since V7: 1)Re-based to the patch Exynos: pwm: Remove dead code of function exynos5_get_pwm_clk. 2)In file dw_mmc.c, updated the function dwmci_setup_bus() to return 0 if (freq == 0).This is to avoid the run time exception raise:Signal # 8 caught. 3)In the files drivers/mmc/mmc.c and common/cmd_mmc.c, the piece of code involved in EMMC open/close and resize of EMMC boot partition has been made conditional and is enabled only if the macro CONFIG_SUPPORT_EMMC_BOOT is defined. 4)The macros FSYS1_MMC0_DIV_MASK and FSYS1_MMC0_DIV_VAL are made local to file clock_init.c. Changes since V8: 1)Re-based to the patch exynos: fdt: Add TMU node for snow. 2)In spl_boot.c, updated USB boot piece of code, to use get_irom_func(int index) to avoid type casting. 3)Updated the below in response to review comments a)Changed the type of input parameters from u32 to u8 for the function boot_part_access(). b)Updated the function call to use a constant value 1, for boot_part_access(mmc, 1, part_num, access). c)In function dwmci_init, auto stop command is disabled, as this feature is not required. The series tested on snow: Acked-by: Simon Glass s...@chromium.org Tested-by: Simon Glass s...@chromium.org Amar (9): FDT: Add compatible string for DWMMC EXYNOS5: FDT: Add DWMMC device node data DWMMC: Initialise dwmci and resolve EMMC read write issues EXYNOS5: DWMMC: Added FDT support for DWMMC EXYNOS5:
[U-Boot] [PATCH 2/3] ARM: OMAP5: clocks: Do not enable sgx clocks
From: Sricharan R r.sricha...@ti.com SGX clocks should be enabled only for OMAP5 ES1.0. So this can be removed. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/cpu/armv7/omap5/hw_data.c |6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 604fa42..842cf27 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -383,12 +383,6 @@ void enable_basic_clocks(void) clk_modules_explicit_en_essential, 1); - /* Select 384Mhz for GPU as its the POR for ES1.0 */ - setbits_le32((*prcm)-cm_sgx_sgx_clkctrl, - CLKSEL_GPU_HYD_GCLK_MASK); - setbits_le32((*prcm)-cm_sgx_sgx_clkctrl, - CLKSEL_GPU_CORE_GCLK_MASK); - /* Enable SCRM OPT clocks for PER and CORE dpll */ setbits_le32((*prcm)-cm_wkupaon_scrm_clkctrl, OPTFCLKEN_SCRM_PER_MASK); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] ARM: OMAP4+: Misc Cleanup
Misc cleanup. And also adding a Generic bus init and write functions for PMIC. This series is applied on top of u-boot-ti: git://git.denx.de/u-boot-ti.git Lokesh Vutla (2): ARM: OMAP4+: Cleanup header files ARM: OMAP4+: pmic: Make generic bus init and write functions Sricharan R (1): ARM: OMAP5: clocks: Do not enable sgx clocks arch/arm/cpu/armv7/omap-common/clocks-common.c |6 ++--- arch/arm/cpu/armv7/omap-common/vc.c| 14 ++- arch/arm/cpu/armv7/omap4/hw_data.c | 11 - arch/arm/cpu/armv7/omap4/prcm-regs.c |3 +++ arch/arm/cpu/armv7/omap5/hw_data.c |9 +++ arch/arm/cpu/armv7/omap5/prcm-regs.c |2 ++ arch/arm/include/asm/arch-omap4/clocks.h | 28 - arch/arm/include/asm/arch-omap4/cpu.h | 12 - arch/arm/include/asm/arch-omap4/omap.h | 14 --- arch/arm/include/asm/arch-omap4/sys_proto.h|2 +- arch/arm/include/asm/arch-omap5/clocks.h | 22 - arch/arm/include/asm/arch-omap5/cpu.h | 12 - arch/arm/include/asm/arch-omap5/omap.h | 31 +--- arch/arm/include/asm/arch-omap5/sys_proto.h|2 +- arch/arm/include/asm/omap_common.h |7 +++--- board/ti/omap5_uevm/evm.c | 12 ++--- board/ti/panda/panda.c | 20 +-- board/ti/sdp4430/sdp.c | 16 +++- drivers/usb/musb/omap3.c |4 ++- 19 files changed, 73 insertions(+), 154 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ARM: OMAP4+: Cleanup header files
After having the u-boot clean up series, there are
many definitions that are unused in header files.
Removing all those unused ones.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap4/prcm-regs.c |3 +++
arch/arm/cpu/armv7/omap5/prcm-regs.c |2 ++
arch/arm/include/asm/arch-omap4/clocks.h | 28 ---
arch/arm/include/asm/arch-omap4/cpu.h| 12
arch/arm/include/asm/arch-omap4/omap.h | 14 --
arch/arm/include/asm/arch-omap5/clocks.h | 22 -
arch/arm/include/asm/arch-omap5/cpu.h| 12
arch/arm/include/asm/arch-omap5/omap.h | 31 +-
arch/arm/include/asm/omap_common.h |4 +---
board/ti/omap5_uevm/evm.c| 12
board/ti/panda/panda.c | 20 +++
board/ti/sdp4430/sdp.c | 16 +--
drivers/usb/musb/omap3.c |4 +++-
13 files changed, 40 insertions(+), 140 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/prcm-regs.c
b/arch/arm/cpu/armv7/omap4/prcm-regs.c
index 7225a30..7e71ca0 100644
--- a/arch/arm/cpu/armv7/omap4/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap4/prcm-regs.c
@@ -301,6 +301,8 @@ struct omap_sys_ctrl_regs const omap4_ctrl = {
.control_ldosram_iva_voltage_ctrl = 0x4A002320,
.control_ldosram_mpu_voltage_ctrl = 0x4A002324,
.control_ldosram_core_voltage_ctrl = 0x4A002328,
+ .control_usbotghs_ctrl = 0x4A00233C,
+ .control_padconf_core_base = 0x4A10,
.control_pbiaslite = 0x4A100600,
.control_lpddr2io1_0= 0x4A100638,
.control_lpddr2io1_1= 0x4A10063C,
@@ -312,4 +314,5 @@ struct omap_sys_ctrl_regs const omap4_ctrl = {
.control_lpddr2io2_3= 0x4A100654,
.control_efuse_1= 0x4A100700,
.control_efuse_2= 0x4A100704,
+ .control_padconf_wkup_base = 0x4A31E000,
};
diff --git a/arch/arm/cpu/armv7/omap5/prcm-regs.c
b/arch/arm/cpu/armv7/omap5/prcm-regs.c
index e9f6a32..db779f2 100644
--- a/arch/arm/cpu/armv7/omap5/prcm-regs.c
+++ b/arch/arm/cpu/armv7/omap5/prcm-regs.c
@@ -311,6 +311,7 @@ struct prcm_regs const omap5_es1_prcm = {
struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_status = 0x4A002134,
+ .control_padconf_core_base = 0x4A002800,
.control_paconf_global = 0x4A002DA0,
.control_paconf_mode= 0x4A002DA4,
.control_smart1io_padconf_0 = 0x4A002DA8,
@@ -358,6 +359,7 @@ struct omap_sys_ctrl_regs const omap5_ctrl = {
.control_port_emif2_sdram_config= 0x4AE0C118,
.control_emif1_sdram_config_ext = 0x4AE0C144,
.control_emif2_sdram_config_ext = 0x4AE0C148,
+ .control_padconf_wkup_base = 0x4AE0C800,
.control_smart1nopmio_padconf_0 = 0x4AE0CDA0,
.control_smart1nopmio_padconf_1 = 0x4AE0CDA4,
.control_padconf_mode = 0x4AE0CDA8,
diff --git a/arch/arm/include/asm/arch-omap4/clocks.h
b/arch/arm/include/asm/arch-omap4/clocks.h
index ed7a1c8..f544edf 100644
--- a/arch/arm/include/asm/arch-omap4/clocks.h
+++ b/arch/arm/include/asm/arch-omap4/clocks.h
@@ -34,25 +34,6 @@
*/
#define LDELAY 100
-#define CM_CLKMODE_DPLL_CORE 0x4A004120
-#define CM_CLKMODE_DPLL_PER0x4A008140
-#define CM_CLKMODE_DPLL_MPU0x4A004160
-#define CM_CLKSEL_CORE 0x4A004100
-
-/* DPLL register offsets */
-#define CM_CLKMODE_DPLL0
-#define CM_IDLEST_DPLL 0x4
-#define CM_AUTOIDLE_DPLL 0x8
-#define CM_CLKSEL_DPLL 0xC
-#define CM_DIV_M2_DPLL 0x10
-#define CM_DIV_M3_DPLL 0x14
-#define CM_DIV_M4_DPLL 0x18
-#define CM_DIV_M5_DPLL 0x1C
-#define CM_DIV_M6_DPLL 0x20
-#define CM_DIV_M7_DPLL 0x24
-
-#define DPLL_CLKOUT_DIV_MASK 0x1F /* post-divider mask */
-
/* CM_DLL_CTRL */
#define CM_DLL_CTRL_OVERRIDE_SHIFT 0
#define CM_DLL_CTRL_OVERRIDE_MASK (1 0)
@@ -94,8 +75,6 @@
#define CM_CLKSEL_DCC_EN_SHIFT 22
#define CM_CLKSEL_DCC_EN_MASK (1 22)
-#define OMAP4_DPLL_MAX_N 127
-
/* CM_SYS_CLKSEL */
#define CM_SYS_CLKSEL_SYS_CLKSEL_MASK 7
@@ -181,9 +160,7 @@
#define MPU_CLKCTRL_CLKSEL_ABE_DIV_MODE_MASK (1 25)
/* Clock frequencies */
-#define OMAP_SYS_CLK_FREQ_38_4_MHZ 3840
#define OMAP_SYS_CLK_IND_38_4_MHZ 6
-#define OMAP_32K_CLK_FREQ 32768
/* PRM_VC_VAL_BYPASS */
#define PRM_VC_I2C_CHANNEL_FREQ_KHZ400
@@ -234,11 +211,6 @@
#define ALTCLKSRC_MODE_ACTIVE 1
-/* Defines for DPLL setup */
-#define
[U-Boot] [PATCH 3/3] ARM: OMAP4+: pmic: Make generic bus init and write functions
Voltage scaling can be done in two ways:
- Using SR I2C
- Using GP I2C
In order to support both, have a function pointer in pmic_data
so that we can call as per our requirement.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c |6 ++
arch/arm/cpu/armv7/omap-common/vc.c| 14 +-
arch/arm/cpu/armv7/omap4/hw_data.c | 11 ++-
arch/arm/cpu/armv7/omap5/hw_data.c |3 +++
arch/arm/include/asm/arch-omap4/sys_proto.h|2 +-
arch/arm/include/asm/arch-omap5/sys_proto.h|2 +-
arch/arm/include/asm/omap_common.h |3 +++
7 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 99910cd..0daf98c 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -487,6 +487,7 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct
pmic_data *pmic)
u32 offset = volt_mv;
int ret = 0;
+ pmic-pmic_bus_init();
/* See if we can first get the GPIO if needed */
if (pmic-gpio_en)
ret = gpio_request(pmic-gpio, PMIC_GPIO);
@@ -509,8 +510,7 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct
pmic_data *pmic)
debug(do_scale_vcore: volt - %d offset_code - 0x%x\n, volt_mv,
offset_code);
- if (omap_vc_bypass_send_value(SMPS_I2C_SLAVE_ADDR,
- vcore_reg, offset_code))
+ if (pmic-pmic_write(pmic-i2c_slave_addr, vcore_reg, offset_code))
printf(Scaling voltage failed for 0x%x\n, vcore_reg);
if (pmic-gpio_en)
@@ -525,8 +525,6 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct
pmic_data *pmic)
*/
void scale_vcores(struct vcores_data const *vcores)
{
- omap_vc_init(PRM_VC_I2C_CHANNEL_FREQ_KHZ);
-
do_scale_vcore(vcores-core.addr, vcores-core.value,
vcores-core.pmic);
diff --git a/arch/arm/cpu/armv7/omap-common/vc.c
b/arch/arm/cpu/armv7/omap-common/vc.c
index e6e5f78..911191d 100644
--- a/arch/arm/cpu/armv7/omap-common/vc.c
+++ b/arch/arm/cpu/armv7/omap-common/vc.c
@@ -17,6 +17,7 @@
#include common.h
#include asm/omap_common.h
#include asm/arch/sys_proto.h
+#include asm/arch/clocks.h
/*
* Define Master code if there are multiple masters on the I2C_SR bus.
@@ -57,7 +58,7 @@
* omap_vc_init() - Initialization for Voltage controller
* @speed_khz: I2C buspeed in KHz
*/
-void omap_vc_init(u16 speed_khz)
+static void omap_vc_init(u16 speed_khz)
{
u32 val;
u32 sys_clk_khz, cycles_hi, cycles_low;
@@ -137,3 +138,14 @@ int omap_vc_bypass_send_value(u8 sa, u8 reg_addr, u8
reg_data)
/* All good.. */
return 0;
}
+
+void sri2c_init(void)
+{
+ static int sri2c = 1;
+
+ if (sri2c) {
+ omap_vc_init(PRM_VC_I2C_CHANNEL_FREQ_KHZ);
+ sri2c = 0;
+ }
+ return;
+}
diff --git a/arch/arm/cpu/armv7/omap4/hw_data.c
b/arch/arm/cpu/armv7/omap4/hw_data.c
index 06a2fc8..02322cc 100644
--- a/arch/arm/cpu/armv7/omap4/hw_data.c
+++ b/arch/arm/cpu/armv7/omap4/hw_data.c
@@ -219,6 +219,9 @@ struct pmic_data twl6030_4430es1 = {
.step = 12660, /* 12.66 mV represented in uV */
/* The code starts at 1 not 0 */
.start_code = 1,
+ .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+ .pmic_bus_init = sri2c_init,
+ .pmic_write = omap_vc_bypass_send_value,
};
struct pmic_data twl6030 = {
@@ -226,6 +229,9 @@ struct pmic_data twl6030 = {
.step = 12660, /* 12.66 mV represented in uV */
/* The code starts at 1 not 0 */
.start_code = 1,
+ .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+ .pmic_bus_init = sri2c_init,
+ .pmic_write = omap_vc_bypass_send_value,
};
struct pmic_data tps62361 = {
@@ -233,7 +239,10 @@ struct pmic_data tps62361 = {
.step = 1, /* 10 mV represented in uV */
.start_code = 0,
.gpio = TPS62361_VSEL0_GPIO,
- .gpio_en = 1
+ .gpio_en = 1,
+ .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+ .pmic_bus_init = sri2c_init,
+ .pmic_write = omap_vc_bypass_send_value,
};
struct vcores_data omap4430_volts_es1 = {
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 842cf27..74e473d 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -289,6 +289,9 @@ struct pmic_data palmas = {
* Offset code 0 switches OFF the SMPS
*/
.start_code = 6,
+ .i2c_slave_addr = SMPS_I2C_SLAVE_ADDR,
+ .pmic_bus_init = sri2c_init,
+ .pmic_write = omap_vc_bypass_send_value,
};
struct vcores_data omap5430_volts = {
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index
[U-Boot] [PATCH 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's
This series update support for DRA7xx family Socs and the data for DRA752 ES1.0 soc. This is on top of my recent Misc cleanup series: http://u-boot.10912.n7.nabble.com/PATCH-0-3-ARM-OMAP4-Misc-Cleanup-tt155877.html Tested on DRA752 ES1.0, OMAP5432 ES2.0, MAKEALL for all armv7 board has been verified. Balaji T K (1): mmc: omap_hsmmc: add mmc1 pbias, ldo1 Lokesh Vutla (6): ARM: DRA7xx: Add control id code for DRA7xx ARM: DRA7xx: power Add support for tps659038 PMIC ARM: DRA7xx: clocks: Fixing i2c_init for PMIC ARM: DRA7xx: Do not enable srcomp for DRA7xx Soc's ARM: DRA7xx: Update pinmux data ARM: DRA7xx: clocks: Update PLL values Nishanth Menon (1): ARM: OMAP5: DRA7xx: support class 0 optimized voltages Sricharan R (4): ARM: DRA7xx: Change the Debug UART to UART1 ARM: DRA7xx: Correct the SYS_CLK to 20MHZ ARM: DRA7xx: Correct SRAM END address ARM: DRA7xx: EMIF: Change settings required for EVM board arch/arm/cpu/armv7/omap-common/clocks-common.c | 86 +--- arch/arm/cpu/armv7/omap-common/emif-common.c | 26 +++- arch/arm/cpu/armv7/omap-common/hwinit-common.c |2 - arch/arm/cpu/armv7/omap5/hw_data.c | 156 -- arch/arm/cpu/armv7/omap5/hwinit.c | 22 ++- arch/arm/cpu/armv7/omap5/prcm-regs.c |2 + arch/arm/cpu/armv7/omap5/sdram.c | 170 ++-- arch/arm/include/asm/arch-omap4/clocks.h |2 +- arch/arm/include/asm/arch-omap4/sys_proto.h|1 + arch/arm/include/asm/arch-omap5/clocks.h | 64 - arch/arm/include/asm/arch-omap5/mux_dra7xx.h |7 +- arch/arm/include/asm/arch-omap5/omap.h | 14 +- arch/arm/include/asm/arch-omap5/sys_proto.h|1 + arch/arm/include/asm/emif.h| 12 +- arch/arm/include/asm/omap_common.h | 26 +++- board/ti/dra7xx/mux_data.h | 38 -- drivers/mmc/omap_hsmmc.c | 26 ++-- drivers/power/palmas.c | 25 +++- include/configs/dra7xx_evm.h | 11 ++ include/configs/omap5_common.h |9 +- include/configs/omap5_uevm.h | 13 +- include/palmas.h |5 +- 22 files changed, 582 insertions(+), 136 deletions(-) -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/12] ARM: DRA7xx: clocks: Fixing i2c_init for PMIC
In DRA7xx Soc's voltage scaling is done using GPI2C. So i2c_init should happen before scaling. I2C driver uses __udelay which needs timer to be initialized. So moving timer_init just before voltage scaling. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- arch/arm/cpu/armv7/omap-common/clocks-common.c |1 + arch/arm/cpu/armv7/omap-common/hwinit-common.c |2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c b/arch/arm/cpu/armv7/omap-common/clocks-common.c index c51c359..1861df4 100644 --- a/arch/arm/cpu/armv7/omap-common/clocks-common.c +++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c @@ -721,6 +721,7 @@ void prcm_init(void) case OMAP_INIT_CONTEXT_UBOOT_FROM_NOR: case OMAP_INIT_CONTEXT_UBOOT_AFTER_CH: enable_basic_clocks(); + timer_init(); scale_vcores(*omap_vcores); setup_dplls(); #ifdef CONFIG_SYS_CLOCKS_ENABLE_ALL diff --git a/arch/arm/cpu/armv7/omap-common/hwinit-common.c b/arch/arm/cpu/armv7/omap-common/hwinit-common.c index 1645120..5602b0e 100644 --- a/arch/arm/cpu/armv7/omap-common/hwinit-common.c +++ b/arch/arm/cpu/armv7/omap-common/hwinit-common.c @@ -202,8 +202,6 @@ void s_init(void) #endif prcm_init(); #ifdef CONFIG_SPL_BUILD - timer_init(); - /* For regular u-boot sdram_init() is called from dram_init() */ sdram_init(); #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
From: Balaji T K balaj...@ti.com
add dra mmc pbias support and ldo1 power on
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-omap5/omap.h |3 ++-
drivers/mmc/omap_hsmmc.c | 26 ++
drivers/power/palmas.c | 25 -
include/configs/omap5_common.h |4
include/configs/omap5_uevm.h |5 -
include/palmas.h |5 -
6 files changed, 48 insertions(+), 20 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index 15d429f..63378fb 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -96,9 +96,10 @@
/* CONTROL_EFUSE_2 */
#define CONTROL_EFUSE_2_NMOS_PMOS_PTV_CODE_1 0x00ffc000
+#define SDCARD_BIAS_PWRDNZ (1 27)
#define SDCARD_PWRDNZ (1 26)
#define SDCARD_BIAS_HIZ_MODE (1 25)
-#define SDCARD_BIAS_PWRDNZ (1 22)
+#define SDCARD_BIAS_PWRDNZ2(1 22)
#define SDCARD_PBIASLITE_VMODE (1 21)
#ifndef __ASSEMBLY__
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index afdfa88..60807df 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -113,23 +113,25 @@ static void omap5_pbias_config(struct mmc *mmc)
u32 value = 0;
value = readl((*ctrl)-control_pbias);
- value = ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
- value |= SDCARD_BIAS_HIZ_MODE;
+ value = ~SDCARD_PWRDNZ;
+ writel(value, (*ctrl)-control_pbias);
+ udelay(10); /* wait 10 us */
+ value = ~SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)-control_pbias);
- palmas_mmc1_poweron_ldo();
+#if defined(CONFIG_DRA7XX)
+ palmas_mmc1_poweron_ldo1();
+#else
+ palmas_mmc1_poweron_ldo9();
+#endif
value = readl((*ctrl)-control_pbias);
- value = ~SDCARD_BIAS_HIZ_MODE;
- value |= SDCARD_PBIASLITE_VMODE | SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ;
+ value |= SDCARD_BIAS_PWRDNZ;
writel(value, (*ctrl)-control_pbias);
-
- value = readl((*ctrl)-control_pbias);
- if (value (1 23)) {
- value = ~(SDCARD_PWRDNZ | SDCARD_BIAS_PWRDNZ);
- value |= SDCARD_BIAS_HIZ_MODE;
- writel(value, (*ctrl)-control_pbias);
- }
+ udelay(150); /* wait 10 us */
+ value |= SDCARD_PWRDNZ;
+ writel(value, (*ctrl)-control_pbias);
+ udelay(150); /* wait 10 us */
}
#endif
diff --git a/drivers/power/palmas.c b/drivers/power/palmas.c
index 09c832d..84ec881 100644
--- a/drivers/power/palmas.c
+++ b/drivers/power/palmas.c
@@ -28,7 +28,7 @@ void palmas_init_settings(void)
return;
}
-int palmas_mmc1_poweron_ldo(void)
+int palmas_mmc1_poweron_ldo9(void)
{
u8 val = 0;
@@ -50,3 +50,26 @@ int palmas_mmc1_poweron_ldo(void)
return 0;
}
+
+int palmas_mmc1_poweron_ldo1(void)
+{
+ u8 val = 0;
+
+ /* set LDO9 TWL6035 to 3V */
+ val = 0x2b; /* (3 -.9)*20 +1 */
+
+ if (palmas_i2c_write_u8(0x58, LDO1_VOLTAGE, val)) {
+ printf(twl6035: could not set LDO1 voltage\n);
+ return 1;
+ }
+
+ /* TURN ON LDO9 */
+ val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;
+
+ if (palmas_i2c_write_u8(0x58, LDO1_CTRL, val)) {
+ printf(twl6035: could not turn on LDO1\n);
+ return 1;
+ }
+
+ return 0;
+}
diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h
index 9fef21c..f2c4c70 100644
--- a/include/configs/omap5_common.h
+++ b/include/configs/omap5_common.h
@@ -241,6 +241,10 @@
#define CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS
#endif
+#ifndef CONFIG_SPL_BUILD
+#define CONFIG_PALMAS_POWER
+#endif
+
/* Defines for SPL */
#define CONFIG_SPL
#define CONFIG_SPL_FRAMEWORK
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 96c5955..69754c6 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -39,11 +39,6 @@
#define CONFIG_SYS_NS16550_COM3UART3_BASE
#define CONFIG_BAUDRATE115200
-/* TWL6035 */
-#ifndef CONFIG_SPL_BUILD
-#define CONFIG_PALMAS_POWER
-#endif
-
/* MMC ENV related defines */
#define CONFIG_ENV_IS_IN_MMC
#define CONFIG_SYS_MMC_ENV_DEV 1 /* SLOT2: eMMC(1) */
diff --git a/include/palmas.h b/include/palmas.h
index 3b18589..18a25ff 100644
--- a/include/palmas.h
+++ b/include/palmas.h
@@ -30,6 +30,8 @@
#define PALMAS_CHIP_ADDR 0x48
/* 0x1XY translates to page 1, register address 0xXY */
+#define LDO1_CTRL 0x50
+#define LDO1_VOLTAGE 0x51
#define LDO9_CTRL 0x60
#define LDO9_VOLTAGE 0x61
@@ -53,6 +55,7 @@
[U-Boot] [PATCH 05/12] ARM: DRA7xx: Do not enable srcomp for DRA7xx Soc's
Slew rate compensation cells are not present for DRA7xx
Soc's. So return from function srcomp_enable() if soc is not
OMAP54xx.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap5/hwinit.c |3 +++
arch/arm/include/asm/omap_common.h |8
2 files changed, 11 insertions(+)
diff --git a/arch/arm/cpu/armv7/omap5/hwinit.c
b/arch/arm/cpu/armv7/omap5/hwinit.c
index e192fea..784aa11 100644
--- a/arch/arm/cpu/armv7/omap5/hwinit.c
+++ b/arch/arm/cpu/armv7/omap5/hwinit.c
@@ -201,6 +201,9 @@ void srcomp_enable(void)
u32 sysclk_ind = get_sys_clk_index();
u32 omap_rev= omap_revision();
+ if (!is_omap54xx())
+ return;
+
mul_factor = srcomp_parameters[sysclk_ind].multiply_factor;
div_factor = srcomp_parameters[sysclk_ind].divide_factor;
diff --git a/arch/arm/include/asm/omap_common.h
b/arch/arm/include/asm/omap_common.h
index 1435674..7007177 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -575,6 +575,14 @@ static inline u32 omap_revision(void)
extern u32 *const omap_si_rev;
return *omap_si_rev;
}
+
+#define OMAP54xx 0x5400
+
+static inline u8 is_omap54xx(void)
+{
+ extern u32 *const omap_si_rev;
+ return ((*omap_si_rev 0xFF00) == OMAP54xx);
+}
#endif
/*
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/12] ARM: DRA7xx: Change the Debug UART to UART1
From: Sricharan R r.sricha...@ti.com Serial UART is connected to UART1. So add the change for the same. Signed-off-by: Sricharan R r.sricha...@ti.com --- include/configs/dra7xx_evm.h |3 +++ include/configs/omap5_common.h |4 include/configs/omap5_uevm.h |4 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h index 28a306b..b142049 100644 --- a/include/configs/dra7xx_evm.h +++ b/include/configs/dra7xx_evm.h @@ -35,4 +35,7 @@ #define CONFIG_DRA7XX /* in a TI DRA7XX core */ #define CONFIG_SYS_PROMPT DRA752 EVM # +#define CONFIG_CONS_INDEX 1 +#define CONFIG_SYS_NS16550_COM1UART1_BASE +#define CONFIG_BAUDRATE115200 #endif /* __CONFIG_DRA7XX_EVM_H */ diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h index deb5e9f..d57c0da 100644 --- a/include/configs/omap5_common.h +++ b/include/configs/omap5_common.h @@ -81,10 +81,6 @@ #define CONFIG_SYS_NS16550_SERIAL #define CONFIG_SYS_NS16550_REG_SIZE(-4) #define CONFIG_SYS_NS16550_CLK V_NS16550_CLK -#define CONFIG_CONS_INDEX 3 -#define CONFIG_SYS_NS16550_COM3UART3_BASE - -#define CONFIG_BAUDRATE115200 /* CPU */ #define CONFIG_ARCH_CPU_INIT diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h index c791789..ba81e30 100644 --- a/include/configs/omap5_uevm.h +++ b/include/configs/omap5_uevm.h @@ -35,6 +35,10 @@ #include configs/omap5_common.h +#define CONFIG_CONS_INDEX 3 +#define CONFIG_SYS_NS16550_COM3UART3_BASE +#define CONFIG_BAUDRATE115200 + /* TWL6035 */ #ifndef CONFIG_SPL_BUILD #define CONFIG_PALMAS_POWER -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/12] ARM: DRA7xx: power Add support for tps659038 PMIC
TPS659038 is the power IC used in DRA7XX boards.
Adding support for this and also adding pmic data
for DRA7XX boards.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 23 ++
arch/arm/cpu/armv7/omap5/hw_data.c | 38 +++-
arch/arm/include/asm/arch-omap4/sys_proto.h|1 +
arch/arm/include/asm/arch-omap5/clocks.h | 15 ++
arch/arm/include/asm/arch-omap5/sys_proto.h|1 +
arch/arm/include/asm/omap_common.h |3 ++
6 files changed, 80 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 0daf98c..c51c359 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -30,6 +30,7 @@
* MA 02111-1307 USA
*/
#include common.h
+#include i2c.h
#include asm/omap_common.h
#include asm/gpio.h
#include asm/arch/clocks.h
@@ -487,6 +488,9 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct
pmic_data *pmic)
u32 offset = volt_mv;
int ret = 0;
+ if (!volt_mv)
+ return;
+
pmic-pmic_bus_init();
/* See if we can first get the GPIO if needed */
if (pmic-gpio_en)
@@ -534,6 +538,15 @@ void scale_vcores(struct vcores_data const *vcores)
do_scale_vcore(vcores-mm.addr, vcores-mm.value,
vcores-mm.pmic);
+ do_scale_vcore(vcores-gpu.addr, vcores-gpu.value,
+ vcores-gpu.pmic);
+
+ do_scale_vcore(vcores-eve.addr, vcores-eve.value,
+ vcores-eve.pmic);
+
+ do_scale_vcore(vcores-iva.addr, vcores-iva.value,
+ vcores-iva.pmic);
+
if (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3) {
/* Configure LDO SRAM magic bits */
writel(2, (*prcm)-prm_sldo_core_setup);
@@ -723,3 +736,13 @@ void prcm_init(void)
if (OMAP_INIT_CONTEXT_SPL != omap_hw_init_context())
enable_basic_uboot_clocks();
}
+
+void gpi2c_init(void)
+{
+ static int gpi2c = 1;
+
+ if (gpi2c) {
+ i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+ gpi2c = 0;
+ }
+}
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 74e473d..e9d34c1 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -26,6 +26,7 @@
* MA 02111-1307 USA
*/
#include common.h
+#include palmas.h
#include asm/arch/omap.h
#include asm/arch/sys_proto.h
#include asm/omap_common.h
@@ -294,6 +295,19 @@ struct pmic_data palmas = {
.pmic_write = omap_vc_bypass_send_value,
};
+struct pmic_data tps659038 = {
+ .base_offset = PALMAS_SMPS_BASE_VOLT_UV,
+ .step = 1, /* 10 mV represented in uV */
+ /*
+* Offset codes 1-6 all give the base voltage in Palmas
+* Offset code 0 switches OFF the SMPS
+*/
+ .start_code = 6,
+ .i2c_slave_addr = TPS659038_I2C_SLAVE_ADDR,
+ .pmic_bus_init = gpi2c_init,
+ .pmic_write = palmas_i2c_write_u8,
+};
+
struct vcores_data omap5430_volts = {
.mpu.value = VDD_MPU,
.mpu.addr = SMPS_REG_ADDR_12_MPU,
@@ -322,6 +336,28 @@ struct vcores_data omap5430_volts_es2 = {
.mm.pmic = palmas,
};
+struct vcores_data dra752_volts = {
+ .mpu.value = VDD_MPU_DRA752,
+ .mpu.addr = TPS659038_REG_ADDR_SMPS12_MPU,
+ .mpu.pmic = tps659038,
+
+ .eve.value = VDD_EVE_DRA752,
+ .eve.addr = TPS659038_REG_ADDR_SMPS45_EVE,
+ .eve.pmic = tps659038,
+
+ .gpu.value = VDD_GPU_DRA752,
+ .gpu.addr = TPS659038_REG_ADDR_SMPS6_GPU,
+ .gpu.pmic = tps659038,
+
+ .core.value = VDD_CORE_DRA752,
+ .core.addr = TPS659038_REG_ADDR_SMPS7_CORE,
+ .core.pmic = tps659038,
+
+ .iva.value = VDD_IVA_DRA752,
+ .iva.addr = TPS659038_REG_ADDR_SMPS8_IVA,
+ .iva.pmic = tps659038,
+};
+
/*
* Enable essential clock domains, modules and
* do some additional special settings needed
@@ -562,7 +598,7 @@ void hw_data_init(void)
case DRA752_ES1_0:
*prcm = dra7xx_prcm;
*dplls_data = dra7xx_dplls;
- *omap_vcores = omap5430_volts_es2;
+ *omap_vcores = dra752_volts;
*ctrl = dra7xx_ctrl;
break;
diff --git a/arch/arm/include/asm/arch-omap4/sys_proto.h
b/arch/arm/include/asm/arch-omap4/sys_proto.h
index 37d6c69..438cb96 100644
--- a/arch/arm/include/asm/arch-omap4/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap4/sys_proto.h
@@ -57,6 +57,7 @@ u32 cortex_rev(void);
void init_omap_revision(void);
void do_io_settings(void);
void sri2c_init(void);
+void gpi2c_init(void);
int omap_vc_bypass_send_value(u8 sa, u8 reg_addr, u8 reg_data);
u32 warm_reset(void);
[U-Boot] [PATCH 01/12] ARM: DRA7xx: Add control id code for DRA7xx
The registers that are used for device identification are changed from OMAP5 to DRA7xx. Using the correct registers for DRA7xx. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- arch/arm/include/asm/arch-omap5/clocks.h | 11 +++ arch/arm/include/asm/arch-omap5/omap.h |3 --- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/arm/include/asm/arch-omap5/clocks.h b/arch/arm/include/asm/arch-omap5/clocks.h index 6673a02..ca75f63 100644 --- a/arch/arm/include/asm/arch-omap5/clocks.h +++ b/arch/arm/include/asm/arch-omap5/clocks.h @@ -239,4 +239,15 @@ * into microsec and passing the value. */ #define CONFIG_DEFAULT_OMAP_RESET_TIME_MAX_USEC31219 + +/* CONTROL ID CODE */ +#define CONTROL_CORE_ID_CODE 0x4A002204 +#define CONTROL_WKUP_ID_CODE 0x4AE0C204 + +#ifdef CONFIG_DRA7XX +#define CONTROL_ID_CODECONTROL_WKUP_ID_CODE +#else +#define CONTROL_ID_CODECONTROL_CORE_ID_CODE +#endif + #endif /* _CLOCKS_OMAP5_H_ */ diff --git a/arch/arm/include/asm/arch-omap5/omap.h b/arch/arm/include/asm/arch-omap5/omap.h index 6dfedf4..df8222a 100644 --- a/arch/arm/include/asm/arch-omap5/omap.h +++ b/arch/arm/include/asm/arch-omap5/omap.h @@ -44,9 +44,6 @@ #define DRAM_ADDR_SPACE_START OMAP54XX_DRAM_ADDR_SPACE_START #define DRAM_ADDR_SPACE_ENDOMAP54XX_DRAM_ADDR_SPACE_END -/* CONTROL_ID_CODE */ -#define CONTROL_ID_CODE0x4A002204 - /* To be verified */ #define OMAP5430_CONTROL_ID_CODE_ES1_0 0x0B94202F #define OMAP5430_CONTROL_ID_CODE_ES2_0 0x1B94202F -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/12] ARM: OMAP5: DRA7xx: support class 0 optimized voltages
From: Nishanth Menon n...@ti.com
DRA752 now uses AVS Class 0 voltages which are voltages in efuse.
This means that we can now use the optimized voltages which are
stored as mV values in efuse and program PMIC accordingly.
This allows us to go with higher OPP as needed in the system without
the need for implementing complex AVS logic.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 58 +++-
arch/arm/cpu/armv7/omap5/hw_data.c | 10
arch/arm/include/asm/arch-omap5/clocks.h | 30
arch/arm/include/asm/omap_common.h | 11 +
4 files changed, 97 insertions(+), 12 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 1861df4..928327a 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -521,6 +521,38 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct
pmic_data *pmic)
gpio_direction_output(pmic-gpio, 1);
}
+static u32 optimize_vcore_voltage(struct volts const *v)
+{
+ u32 val;
+ if (!v-value)
+ return 0;
+ if (!v-efuse.reg)
+ return v-value;
+
+ switch (v-efuse.reg_bits) {
+ case 16:
+ val = readw(v-efuse.reg);
+ break;
+ case 32:
+ val = readl(v-efuse.reg);
+ break;
+ default:
+ printf(Error: efuse 0x%08x bits=%d unknown\n,
+ v-efuse.reg, v-efuse.reg_bits);
+ return v-value;
+ }
+
+ if (!val) {
+ printf(Error: efuse 0x%08x bits=%d val=0, using %d\n,
+ v-efuse.reg, v-efuse.reg_bits, v-value);
+ return v-value;
+ }
+
+ debug(%s:efuse 0x%08x bits=%d Vnom=%d, using efuse value %d\n,
+ __func__, v-efuse.reg, v-efuse.reg_bits, v-value, val);
+ return val;
+}
+
/*
* Setup the voltages for vdd_mpu, vdd_core, and vdd_iva
* We set the maximum voltages allowed here because Smart-Reflex is not
@@ -529,23 +561,25 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct
pmic_data *pmic)
*/
void scale_vcores(struct vcores_data const *vcores)
{
- do_scale_vcore(vcores-core.addr, vcores-core.value,
- vcores-core.pmic);
+ u32 val;
+
+ val = optimize_vcore_voltage(vcores-core);
+ do_scale_vcore(vcores-core.addr, val, vcores-core.pmic);
- do_scale_vcore(vcores-mpu.addr, vcores-mpu.value,
- vcores-mpu.pmic);
+ val = optimize_vcore_voltage(vcores-mpu);
+ do_scale_vcore(vcores-mpu.addr, val, vcores-mpu.pmic);
- do_scale_vcore(vcores-mm.addr, vcores-mm.value,
- vcores-mm.pmic);
+ val = optimize_vcore_voltage(vcores-mm);
+ do_scale_vcore(vcores-mm.addr, val, vcores-mm.pmic);
- do_scale_vcore(vcores-gpu.addr, vcores-gpu.value,
- vcores-gpu.pmic);
+ val = optimize_vcore_voltage(vcores-gpu);
+ do_scale_vcore(vcores-gpu.addr, val, vcores-gpu.pmic);
- do_scale_vcore(vcores-eve.addr, vcores-eve.value,
- vcores-eve.pmic);
+ val = optimize_vcore_voltage(vcores-eve);
+ do_scale_vcore(vcores-eve.addr, val, vcores-eve.pmic);
- do_scale_vcore(vcores-iva.addr, vcores-iva.value,
- vcores-iva.pmic);
+ val = optimize_vcore_voltage(vcores-iva);
+ do_scale_vcore(vcores-iva.addr, val, vcores-iva.pmic);
if (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3) {
/* Configure LDO SRAM magic bits */
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index e9d34c1..53aea93 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -338,22 +338,32 @@ struct vcores_data omap5430_volts_es2 = {
struct vcores_data dra752_volts = {
.mpu.value = VDD_MPU_DRA752,
+ .mpu.efuse.reg = STD_FUSE_OPP_VMIN_MPU_NOM,
+ .mpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.mpu.addr = TPS659038_REG_ADDR_SMPS12_MPU,
.mpu.pmic = tps659038,
.eve.value = VDD_EVE_DRA752,
+ .eve.efuse.reg = STD_FUSE_OPP_VMIN_DSPEVE_NOM,
+ .eve.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.eve.addr = TPS659038_REG_ADDR_SMPS45_EVE,
.eve.pmic = tps659038,
.gpu.value = VDD_GPU_DRA752,
+ .gpu.efuse.reg = STD_FUSE_OPP_VMIN_GPU_NOM,
+ .gpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
.gpu.addr = TPS659038_REG_ADDR_SMPS6_GPU,
.gpu.pmic = tps659038,
.core.value = VDD_CORE_DRA752,
+ .core.efuse.reg = STD_FUSE_OPP_VMIN_CORE_NOM,
+ .core.efuse.reg_bits = DRA752_EFUSE_REGBITS,
[U-Boot] [PATCH 10/12] ARM: DRA7xx: Update pinmux data
Updating pinmux data as specified in the latest DM
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/include/asm/arch-omap5/mux_dra7xx.h |7 +++--
board/ti/dra7xx/mux_data.h | 38 --
2 files changed, 29 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
b/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
index 55e9de6..5f2b0f9 100644
--- a/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
+++ b/arch/arm/include/asm/arch-omap5/mux_dra7xx.h
@@ -28,11 +28,14 @@
#include asm/types.h
+#define FSC(1 19)
+#define SSC(0 19)
+
#define IEN(1 18)
#define IDIS (0 18)
-#define PTU(3 16)
-#define PTD(1 16)
+#define PTU(1 17)
+#define PTD(0 17)
#define PEN(1 16)
#define PDIS (0 16)
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 04c95fd..338a241 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -29,19 +29,29 @@
#include asm/arch/mux_dra7xx.h
const struct pad_conf_entry core_padconf_array_essential[] = {
- {MMC1_CLK, (PTU | IEN | M0)}, /* MMC1_CLK */
- {MMC1_CMD, (PTU | IEN | M0)}, /* MMC1_CMD */
- {MMC1_DAT0, (PTU | IEN | M0)}, /* MMC1_DAT0 */
- {MMC1_DAT1, (PTU | IEN | M0)}, /* MMC1_DAT1 */
- {MMC1_DAT2, (PTU | IEN | M0)}, /* MMC1_DAT2 */
- {MMC1_DAT3, (PTU | IEN | M0)}, /* MMC1_DAT3 */
- {MMC1_SDCD, (PTU | IEN | M0)}, /* MMC1_SDCD */
- {MMC1_SDWP, (PTU | IEN | M0)}, /* MMC1_SDWP */
- {UART1_RXD, (PTU | IEN | M0)}, /* UART1_RXD */
- {UART1_TXD, (M0)}, /* UART1_TXD */
- {UART1_CTSN, (PTU | IEN | M0)}, /* UART1_CTSN */
- {UART1_RTSN, (M0)}, /* UART1_RTSN */
- {I2C1_SDA, (PTU | IEN | M0)}, /* I2C1_SDA */
- {I2C1_SCL, (PTU | IEN | M0)}, /* I2C1_SCL */
+ {MMC1_CLK, (IEN | PTU | PDIS | M0)},/* MMC1_CLK */
+ {MMC1_CMD, (IEN | PTU | PDIS | M0)},/* MMC1_CMD */
+ {MMC1_DAT0, (IEN | PTU | PDIS | M0)}, /* MMC1_DAT0 */
+ {MMC1_DAT1, (IEN | PTU | PDIS | M0)}, /* MMC1_DAT1 */
+ {MMC1_DAT2, (IEN | PTU | PDIS | M0)}, /* MMC1_DAT2 */
+ {MMC1_DAT3, (IEN | PTU | PDIS | M0)}, /* MMC1_DAT3 */
+ {MMC1_SDCD, (FSC | IEN | PTU | PDIS | M0)}, /* MMC1_SDCD */
+ {MMC1_SDWP, (FSC | IEN | PTD | PEN | M14)}, /* MMC1_SDWP */
+ {GPMC_A19, (IEN | PTU | PDIS | M1)},/* mmc2_dat4 */
+ {GPMC_A20, (IEN | PTU | PDIS | M1)},/* mmc2_dat5 */
+ {GPMC_A21, (IEN | PTU | PDIS | M1)},/* mmc2_dat6 */
+ {GPMC_A22, (IEN | PTU | PDIS | M1)},/* mmc2_dat7 */
+ {GPMC_A23, (IEN | PTU | PDIS | M1)},/* mmc2_clk */
+ {GPMC_A24, (IEN | PTU | PDIS | M1)},/* mmc2_dat0 */
+ {GPMC_A25, (IEN | PTU | PDIS | M1)},/* mmc2_dat1 */
+ {GPMC_A26, (IEN | PTU | PDIS | M1)},/* mmc2_dat2 */
+ {GPMC_A27, (IEN | PTU | PDIS | M1)},/* mmc2_dat3 */
+ {GPMC_CS1, (IEN | PTU | PDIS | M1)},/* mmm2_cmd */
+ {UART1_RXD, (FSC | IEN | PTU | PDIS | M0)}, /* UART1_RXD */
+ {UART1_TXD, (FSC | IEN | PTU | PDIS | M0)}, /* UART1_TXD */
+ {UART1_CTSN, (IEN | PTU | PDIS | M3)}, /* UART1_CTSN */
+ {UART1_RTSN, (IEN | PTU | PDIS | M3)}, /* UART1_RTSN */
+ {I2C1_SDA, (IEN | PTU | PDIS | M0)},/* I2C1_SDA */
+ {I2C1_SCL, (IEN | PTU | PDIS | M0)},/* I2C1_SCL */
};
#endif /* _MUX_DATA_DRA7XX_H_ */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/12] ARM: DRA7xx: Correct the SYS_CLK to 20MHZ
From: Sricharan R r.sricha...@ti.com The sys_clk on the dra evm board is 20MHZ. Changing the configuration for the same. Signed-off-by: Sricharan R r.sricha...@ti.com --- include/configs/dra7xx_evm.h |4 include/configs/omap5_common.h |1 - include/configs/omap5_uevm.h |3 +++ 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h index b142049..b0b0bda 100644 --- a/include/configs/dra7xx_evm.h +++ b/include/configs/dra7xx_evm.h @@ -38,4 +38,8 @@ #define CONFIG_CONS_INDEX 1 #define CONFIG_SYS_NS16550_COM1UART1_BASE #define CONFIG_BAUDRATE115200 + +/* Clock Defines */ +#define V_OSCK 2000/* Clock output from T2 */ + #endif /* __CONFIG_DRA7XX_EVM_H */ diff --git a/include/configs/omap5_common.h b/include/configs/omap5_common.h index d57c0da..9fef21c 100644 --- a/include/configs/omap5_common.h +++ b/include/configs/omap5_common.h @@ -46,7 +46,6 @@ #define CONFIG_DISPLAY_BOARDINFO /* Clock Defines */ -#define V_OSCK 1920/* Clock output from T2 */ #define V_SCLK V_OSCK #define CONFIG_MISC_INIT_R diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h index ba81e30..4f2d425 100644 --- a/include/configs/omap5_uevm.h +++ b/include/configs/omap5_uevm.h @@ -58,5 +58,8 @@ #define CONFIG_SYS_PROMPT OMAP5430 EVM # +/* Clock Defines */ +#define V_OSCK 1920/* Clock output from T2 */ + #define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC 16296 #endif /* __CONFIG_OMAP5_EVM_H */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/12] ARM: DRA7xx: clocks: Update PLL values
Update PLL values.
SYS_CLKSEL value for 20MHz is changed to 2. In other platforms
SYS_CLKSEL value 2 represents reserved. But in sys_clk array
ind 1 is used for 13Mhz. Since other platforms are not using
13Mhz, reusing index 1 for 20MHz.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/clocks-common.c | 16 ++---
arch/arm/cpu/armv7/omap5/hw_data.c | 87 +++-
arch/arm/cpu/armv7/omap5/prcm-regs.c |1 +
arch/arm/include/asm/arch-omap4/clocks.h |2 +-
arch/arm/include/asm/arch-omap5/clocks.h |8 ++-
arch/arm/include/asm/omap_common.h |3 +-
include/configs/dra7xx_evm.h |1 +
7 files changed, 72 insertions(+), 46 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/clocks-common.c
b/arch/arm/cpu/armv7/omap-common/clocks-common.c
index 928327a..88d9392 100644
--- a/arch/arm/cpu/armv7/omap-common/clocks-common.c
+++ b/arch/arm/cpu/armv7/omap-common/clocks-common.c
@@ -50,13 +50,12 @@
const u32 sys_clk_array[8] = {
1200, /* 12 MHz */
- 1300, /* 13 MHz */
+ 2000, /* 20 MHz */
1680, /* 16.8 MHz */
1920, /* 19.2 MHz */
2600, /* 26 MHz */
2700, /* 27 MHz */
3840, /* 38.4 MHz */
- 2000, /* 20 MHz */
};
static inline u32 __get_sys_clk_index(void)
@@ -75,13 +74,6 @@ static inline u32 __get_sys_clk_index(void)
/* SYS_CLKSEL - 1 to match the dpll param array indices */
ind = (readl((*prcm)-cm_sys_clksel)
CM_SYS_CLKSEL_SYS_CLKSEL_MASK) - 1;
- /*
-* SYS_CLKSEL value for 20MHz is 0. This is introduced newly
-* in DRA7XX socs. SYS_CLKSEL -1 will be greater than
-* NUM_SYS_CLK. So considering the last 3 bits as the index
-* for the dpll param array.
-*/
- ind = CM_SYS_CLKSEL_SYS_CLKSEL_MASK;
}
return ind;
}
@@ -441,6 +433,12 @@ static void setup_non_essential_dplls(void)
params = get_abe_dpll_params(*dplls_data);
#ifdef CONFIG_SYS_OMAP_ABE_SYSCK
abe_ref_clk = CM_ABE_PLL_REF_CLKSEL_CLKSEL_SYSCLK;
+
+ if (omap_revision() == DRA752_ES1_0)
+ /* Select the sys clk for dpll_abe */
+ clrsetbits_le32((*prcm)-cm_abe_pll_sys_clksel,
+ CM_CLKSEL_ABE_PLL_SYS_CLKSEL_MASK,
+ CM_ABE_PLL_SYS_CLKSEL_SYSCLK2);
#else
abe_ref_clk = CM_ABE_PLL_REF_CLKSEL_CLKSEL_32KCLK;
/*
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 53aea93..8303390 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -100,14 +100,13 @@ static const struct dpll_params
mpu_dpll_params_499mhz[NUM_SYS_CLKS] = {
};
static const struct dpll_params mpu_dpll_params_1ghz[NUM_SYS_CLKS] = {
- {250, 2, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 12 MHz */
- {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
- {119, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1},/* 16.8 MHz */
- {625, 11, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 19.2 MHz */
- {500, 12, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 26 MHz */
+ {250, 2, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 12 MHz */
+ {500, 9, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 20 MHz */
+ {119, 1, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 16.8 MHz */
+ {625, 11, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1},/* 19.2 MHz */
+ {500, 12, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1},/* 26 MHz */
{-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 27 MHz */
- {625, 23, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 38.4 MHz */
- {50, 0, 1, -1, -1, -1, -1, -1, -1, -1, -1, -1} /* 20 MHz */
+ {625, 23, 1, 1, -1, -1, -1, -1, -1, -1, -1, -1},/* 38.4 MHz */
};
static const struct dpll_params
@@ -133,15 +132,14 @@ static const struct dpll_params
};
static const struct dpll_params
- core_dpll_params_2128mhz_ddr532_dra7xx[NUM_SYS_CLKS] = {
- {266, 2, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 12 MHz */
- {-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1}, /* 13 MHz */
- {443, 6, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 16.8 MHz */
- {277, 4, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 19.2 MHz */
- {368, 8, 2, -1, -1, 4, 62, 5, -1, 5, 7, 6}, /* 26 MHz */
+ core_dpll_params_2128mhz_dra7xx[NUM_SYS_CLKS] = {
+ {266, 2, 2, 1, -1, 4, 62, 5, -1, 5, 4, 6},
[U-Boot] [PATCH 08/12] ARM: DRA7xx: Correct SRAM END address
From: Sricharan R r.sricha...@ti.com
NON SECURE SRAM is 512KB in DRA7xx devices.
So fixing it here.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/include/asm/arch-omap5/omap.h |7 ---
include/configs/dra7xx_evm.h |3 +++
include/configs/omap5_uevm.h |3 +++
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap5/omap.h
b/arch/arm/include/asm/arch-omap5/omap.h
index df8222a..15d429f 100644
--- a/arch/arm/include/asm/arch-omap5/omap.h
+++ b/arch/arm/include/asm/arch-omap5/omap.h
@@ -159,13 +159,6 @@ struct s32ktimer {
#define EFUSE_4 0x45145100
#endif /* __ASSEMBLY__ */
-/*
- * Non-secure SRAM Addresses
- * Non-secure RAM starts at 0x4030 for GP devices. But we keep SRAM_BASE
- * at 0x40304000(EMU base) so that our code works for both EMU and GP
- */
-#define NON_SECURE_SRAM_START 0x4030
-#define NON_SECURE_SRAM_END0x4032 /* Not inclusive */
/* base address for indirect vectors (internal boot mode) */
#define SRAM_ROM_VECT_BASE 0x4031F000
diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
index b0b0bda..fc35f2f 100644
--- a/include/configs/dra7xx_evm.h
+++ b/include/configs/dra7xx_evm.h
@@ -42,4 +42,7 @@
/* Clock Defines */
#define V_OSCK 2000/* Clock output from T2 */
+#define NON_SECURE_SRAM_START 0x4030
+#define NON_SECURE_SRAM_END0x4038 /* Not inclusive */
+
#endif /* __CONFIG_DRA7XX_EVM_H */
diff --git a/include/configs/omap5_uevm.h b/include/configs/omap5_uevm.h
index 4f2d425..96c5955 100644
--- a/include/configs/omap5_uevm.h
+++ b/include/configs/omap5_uevm.h
@@ -61,5 +61,8 @@
/* Clock Defines */
#define V_OSCK 1920/* Clock output from T2 */
+#define NON_SECURE_SRAM_START 0x4030
+#define NON_SECURE_SRAM_END0x4032 /* Not inclusive */
+
#define CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC 16296
#endif /* __CONFIG_OMAP5_EVM_H */
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/12] ARM: DRA7xx: EMIF: Change settings required for EVM board
From: Sricharan R r.sricha...@ti.com
DRA7 EVM board has the below configuration. Adding the
settings for the same here.
2Gb_1_35V_DDR3L part * 2 on EMIF1
2Gb_1_35V_DDR3L part * 4 on EMIF2
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 26 +++-
arch/arm/cpu/armv7/omap5/hw_data.c | 21 +++-
arch/arm/cpu/armv7/omap5/hwinit.c| 19 +--
arch/arm/cpu/armv7/omap5/prcm-regs.c |1 +
arch/arm/cpu/armv7/omap5/sdram.c | 170 --
arch/arm/include/asm/arch-omap5/omap.h |1 +
arch/arm/include/asm/emif.h | 12 +-
arch/arm/include/asm/omap_common.h |1 +
8 files changed, 220 insertions(+), 31 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index 11e830a..f925e82 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -209,7 +209,8 @@ void emif_update_timings(u32 base, const struct emif_regs
*regs)
writel(regs-temp_alert_config, emif-emif_temp_alert_config);
writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1_shdw);
- if (omap_revision() = OMAP5430_ES1_0) {
+ if ((omap_revision() = OMAP5430_ES1_0) ||
+ (omap_revision() == DRA752_ES1_0)) {
writel(EMIF_L3_CONFIG_VAL_SYS_10_MPU_5_LL_0,
emif-emif_l3_config);
} else if (omap_revision() = OMAP4460_ES1_0) {
@@ -263,6 +264,18 @@ static void ddr3_leveling(u32 base, const struct emif_regs
*regs)
__udelay(130);
}
+static void ddr3_sw_leveling(u32 base, const struct emif_regs *regs)
+{
+ struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
+
+ writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1);
+ writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1_shdw);
+ config_data_eye_leveling_samples(base);
+
+ writel(regs-emif_rd_wr_lvl_ctl, emif-emif_rd_wr_lvl_ctl);
+ writel(regs-sdram_config, emif-emif_sdram_config);
+}
+
static void ddr3_init(u32 base, const struct emif_regs *regs)
{
struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
@@ -273,6 +286,7 @@ static void ddr3_init(u32 base, const struct emif_regs
*regs)
* defined, contents of mode Registers must be fully initialized.
* H/W takes care of this initialization
*/
+ writel(regs-sdram_config2, emif-emif_lpddr2_nvm_config);
writel(regs-sdram_config_init, emif-emif_sdram_config);
writel(regs-emif_ddr_phy_ctlr_1_init, emif-emif_ddr_phy_ctrl_1);
@@ -290,7 +304,10 @@ static void ddr3_init(u32 base, const struct emif_regs
*regs)
/* enable leveling */
writel(regs-emif_rd_wr_lvl_rmp_ctl, emif-emif_rd_wr_lvl_rmp_ctl);
- ddr3_leveling(base, regs);
+ if (omap_revision() == DRA752_ES1_0)
+ ddr3_sw_leveling(base, regs);
+ else
+ ddr3_leveling(base, regs);
}
#ifndef CONFIG_SYS_EMIF_PRECALCULATED_TIMING_REGS
@@ -1078,7 +1095,10 @@ static void do_sdram_init(u32 base)
if (warm_reset() (emif_sdram_type() == EMIF_SDRAM_TYPE_DDR3)) {
set_lpmode_selfrefresh(base);
emif_reset_phy(base);
- ddr3_leveling(base, regs);
+ if (omap_revision() == DRA752_ES1_0)
+ ddr3_sw_leveling(base, regs);
+ else
+ ddr3_leveling(base, regs);
}
/* Write to the shadow registers */
diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c
b/arch/arm/cpu/armv7/omap5/hw_data.c
index 8303390..9374c6a 100644
--- a/arch/arm/cpu/armv7/omap5/hw_data.c
+++ b/arch/arm/cpu/armv7/omap5/hw_data.c
@@ -602,6 +602,17 @@ const struct ctrl_ioregs ioregs_omap5432_es2 = {
.ctrl_emif_sdram_config_ext = SDRAM_CONFIG_EXT_RD_LVL_11_SAMPLES,
};
+const struct ctrl_ioregs ioregs_dra7xx_es1 = {
+ .ctrl_ddrch = 0x40404040,
+ .ctrl_lpddr2ch = 0x40404040,
+ .ctrl_ddr3ch = 0x80808080,
+ .ctrl_ddrio_0 = 0xbae8c631,
+ .ctrl_ddrio_1 = 0xb46318d8,
+ .ctrl_ddrio_2 = 0x8421,
+ .ctrl_emif_sdram_config_ext = 0xb2c0,
+ .ctrl_ddr_ctrl_ext_0 = 0xA200,
+};
+
void hw_data_init(void)
{
u32 omap_rev = omap_revision();
@@ -644,14 +655,16 @@ void get_ioregs(const struct ctrl_ioregs **regs)
case OMAP5430_ES1_0:
case OMAP5430_ES2_0:
*regs = ioregs_omap5430;
- break;
+ break;
case OMAP5432_ES1_0:
*regs = ioregs_omap5432_es1;
- break;
+ break;
case OMAP5432_ES2_0:
- case DRA752_ES1_0:
*regs = ioregs_omap5432_es2;
- break;
+ break;
+ case DRA752_ES1_0:
+ *regs = ioregs_dra7xx_es1;
+
Re: [U-Boot] dfu: dfu and UBI Volumes
On Wed, May 29, 2013 at 06:35:27AM +0200, Heiko Schocher wrote: Hello Tom, Am 28.05.2013 23:16, schrieb Tom Rini: On Tue, May 28, 2013 at 11:01:09PM +0200, Wolfgang Denk wrote: Dear Tom, In message 20130528172309.GF5829@bill-the-cat you wrote: Of course this can't yet apply to writing files on file systems since the current API in U-Boot misses the append feature, but this could be applied to program raw memory partitions, including UBI images. Correct. We can write a whole UBI image, today, of NAND size, regardless of DDR size. But modifying UBI volumes (so UBIFS or your I don't think so. To write a UBI volume on an existing UBI device, you would use the ubi write command. This translates into a call of ubi_volume_write(char *volume, void *buf, size_t size) which means the size must be known before you start writing; as far as I can tell ubi_volume_write() does not support incremental write operations of individual parts of a volume. OK. A very quick read of ubi_volume_write leads into the guts of the write being in drivers/mtd/ubi/upd.c and it feels like you could actually do the volume write in chunks with ubi_start_update() and ubi_more_update_data() (and maybe some other housekeeping bits). It might take a bit more work since it looks like looks like both functions rely on knowing the size at the start, but that's just to make sure the size will fit in the volume. Yes, I think so too ... seems some work, but not unsolveable ... Hmm.. is it possible to get the filesize over dfu on startup? (I hope so, as it makes no sense to transfer a file, if it does not fit in the partition ... ) There is not, but that's OK. Even if you think you had the room for the whole image you could find a new bad block and not fit, so it's just behaving like when we do a raw NAND write, get the data chunk, make sure we think we still have room, write if we do, error if we don't. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] mmc: sdhci: Enable 8-bit bus width only for 3.0 spec onwards
Any help on this, was this a useful fix.
Thanks,
Jagan.
On Mon, May 27, 2013 at 10:49 AM, Jagannadha Sutradharudu Teki
jagannadha.sutradharudu-t...@xilinx.com wrote:
Request for an update on this.
Thanks,
Jagan.
-Original Message-
From: Jagannadha Sutradharudu Teki [mailto:jagannadha.sutradharudu-
t...@xilinx.com]
Sent: 21 May 2013 15:02
To: u-boot@lists.denx.de
Cc: mon...@monstr.eu; Andy Fleming; Jagannadha Sutradharudu Teki
Subject: [U-BOOT] mmc: sdhci: Enable 8-bit bus width only for 3.0 spec
onwards
CAP register don't have any information for 8-bit buswidth support on 2.0
sdhci
spec, only from 3.0 onwards bit[18] got this information.
Due to this misassignment in sdhci, mmc is setting 8-bit buswidth using
mmc_set_bus_width even if controller doesn't support.
Below change has code information.
mmc: Properly determine maximum supported bus width
(sha1: 7798f6dbd5e1a3030ed81a81da5dfb57c3307cac)
Bug log: mmc plus and emmc cards)
---
zynq-uboot mmcinfo
Error detected in status(0x208100)!
Device: zynq_sdhci
Manufacturer ID: fe
.
So enable 8-bit support only for 3.0 spec using CAP and for below 3.0 assign
mmc-host_caps = MMC_MODE_8BIT on respective platform driver if host have
a support.
Signed-off-by: Jagannadha Sutradharudu Teki jaga...@xilinx.com
---
drivers/mmc/sdhci.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index 1eaea04..c5631bf
100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -486,8 +486,10 @@ int add_sdhci(struct sdhci_host *host, u32 max_clk,
u32 min_clk)
mmc-voltages |= host-voltages;
mmc-host_caps = MMC_MODE_HS | MMC_MODE_HS_52MHz |
MMC_MODE_4BIT;
- if (caps SDHCI_CAN_DO_8BIT)
- mmc-host_caps |= MMC_MODE_8BIT;
+ if ((host-version SDHCI_SPEC_VER_MASK) = SDHCI_SPEC_300) {
+ if (caps SDHCI_CAN_DO_8BIT)
+ mmc-host_caps |= MMC_MODE_8BIT;
+ }
if (host-host_caps)
mmc-host_caps |= host-host_caps;
--
1.7.4
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any
attachments. Delete this email message and any attachments immediately.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
--
--
Thanks,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 5/7] Adjust Kconfig scripts for use by U-Boot
On Wed, May 29, 2013 at 09:47:34AM +0900, Masahiro Yamada wrote:
Hello, Simon.
Please let me ask some more questions.
By applying these series of commits,
U-Boot's config file scheme and Kconfig coexist.
For example, scripts/Makefile.build includes
both auto.conf generated by Kconfig
and autoconf.mk derived from U-boot's config.
-include include/config/auto.conf
-include $(objtree)/include/config/autoconf.mk
I think the redundancy and dirtiness do not matter
if they are temporary.
What I'd like to make clear is our goal.
It is intended to move all U-Boot's config files
to Kconfig over long time and
after that, delete U-Boot's config system.
Is this right?
Yes, long term.
If the answer is yes, there are some macros
I don't know how to port to Kconfig.
For example,
CONFIG_SYS_BAUDRATE_TABLE is defined like follows.
#define CONFIG_SYS_BAUDRATE_TABLE {9600, 19200, 38400, 57600, 115200}
To my knowledge this macro can not be described by Kconfig.
We would probably want to change it to something like:
- Do you want the standard baud rate table?
Yes: 9600/19200/38400/57600/115200
No: Prompt for string value of comma sep list of rates
And in the right header:
#ifdef CONFIG_SYS_STD_BAUD_RATE
#define BAUDRATTE_TABLE { 9600, }
#else
#define BAUDRATE_TABLE { CONFIG_SYS_PROMPTED_VALUE }
#endif
And also, some config files still include macros without CONFIG_ prefix.
For example, LINUX_BOOT_PARAM_ADDR, PHYS_SDRAM_1, PHYS_SDRAM_2, etc.
These don't belong in the config file, and need to be either in the
board or asm/arch/ or similar construct instead.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/7] Tidy up Makefiles to use COBJS consistently
On Sun, May 12, 2013 at 07:25:36PM -0700, Simon Glass wrote: Some Makefiles doen't define COBJS, but just use COBJS-y directly. This messes with our Kconfig script which uses COBJS to decide which objects are needed. Also, for directories where COBJS produces an empty list, COBJS- must be defined and non-empty, otherwise Kconfig will not create the empty built-in.o file and the link will fail. So adjust things such that COBJS- is defined when needed. Finally, Kconfig needs to know about subdirectories with the obj-y variable, so add these as needed. All of the above changes should have no effect on the existing U-Boot build system. Except for the obj-y for directories stuff, the other bits are cleanups for what we have today yes? If so, lets get them separated out and merged in soon rather than later. One less patch to carry. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: OMAP5: clocks: Do not enable sgx clocks
On Wed, May 29, 2013 at 03:39:54PM +0530, Lokesh Vutla wrote: From: Sricharan R r.sricha...@ti.com SGX clocks should be enabled only for OMAP5 ES1.0. So this can be removed. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/cpu/armv7/omap5/hw_data.c |6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 604fa42..842cf27 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -383,12 +383,6 @@ void enable_basic_clocks(void) clk_modules_explicit_en_essential, 1); - /* Select 384Mhz for GPU as its the POR for ES1.0 */ - setbits_le32((*prcm)-cm_sgx_sgx_clkctrl, - CLKSEL_GPU_HYD_GCLK_MASK); - setbits_le32((*prcm)-cm_sgx_sgx_clkctrl, - CLKSEL_GPU_CORE_GCLK_MASK); - /* Enable SCRM OPT clocks for PER and CORE dpll */ setbits_le32((*prcm)-cm_wkupaon_scrm_clkctrl, OPTFCLKEN_SCRM_PER_MASK); Wait, will everyone with ES1.0 be updating to ES2.0 and be OK with this? Lubomir's board is ES1.0, currently. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] Factorize ARM relocate_code instances
Hi Albert, On Tue, May 28, 2013 at 10:28 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Did you manage this test? If you did and it succeeded, then I'll merge the series into u-boot-arm. Unfortunately I did not manage to find some spare time to test this, sorry. Please go ahead and apply them. Hopefully I will be able to test next week and then I will report in case of any issue. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/12] ARM: DRA7xx: Correct the SYS_CLK to 20MHZ
On Wed, May 29, 2013 at 04:32:42PM +0530, Lokesh Vutla wrote: From: Sricharan R r.sricha...@ti.com The sys_clk on the dra evm board is 20MHZ. Changing the configuration for the same. Signed-off-by: Sricharan R r.sricha...@ti.com --- include/configs/dra7xx_evm.h |4 include/configs/omap5_common.h |1 - include/configs/omap5_uevm.h |3 +++ 3 files changed, 7 insertions(+), 1 deletion(-) OK, lets start fixing some of this madness while we're in here. V_OSCK (setting aside am335x) is only used for V_SCLK. V_SCLK is only used for TIMER_CLOCK in arch/arm/cpu/armv7/omap-common/timer.c. We need to move this value (or value pair) into asm/arch/clock.h and rename omap*/clocks.h to clock.h (it's the outlier vs the rest of ARM). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/12] ARM: DRA7xx: Correct SRAM END address
On Wed, May 29, 2013 at 04:32:43PM +0530, Lokesh Vutla wrote: From: Sricharan R r.sricha...@ti.com NON SECURE SRAM is 512KB in DRA7xx devices. So fixing it here. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/include/asm/arch-omap5/omap.h |7 --- include/configs/dra7xx_evm.h |3 +++ include/configs/omap5_uevm.h |3 +++ No, we need to handle this in the include files, not the config files. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/12] mmc: omap_hsmmc: add mmc1 pbias, ldo1
On Wed, May 29, 2013 at 04:32:44PM +0530, Lokesh Vutla wrote:
From: Balaji T K balaj...@ti.com
add dra mmc pbias support and ldo1 power on
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
[snip]
+ udelay(150); /* wait 10 us */
+ value |= SDCARD_PWRDNZ;
+ writel(value, (*ctrl)-control_pbias);
+ udelay(150); /* wait 10 us */
That's not 10us.
+ val = 0x2b; /* (3 -.9)*20 +1 */
Consistent spacing in the math please (and leading 0).
+ if (palmas_i2c_write_u8(0x58, LDO1_CTRL, val)) {
No magic values please.
Thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's
On Wed, May 29, 2013 at 04:32:35PM +0530, Lokesh Vutla wrote: This series update support for DRA7xx family Socs and the data for DRA752 ES1.0 soc. This is on top of my recent Misc cleanup series: http://u-boot.10912.n7.nabble.com/PATCH-0-3-ARM-OMAP4-Misc-Cleanup-tt155877.html Tested on DRA752 ES1.0, OMAP5432 ES2.0, MAKEALL for all armv7 board has been verified. Aside from a few comments, everything else looks good. Oh, and please test with MAKEALL -s omap as well as -c armv7, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: OMAP5: clocks: Do not enable sgx clocks
On Wednesday 29 May 2013 06:10 PM, Tom Rini wrote: On Wed, May 29, 2013 at 03:39:54PM +0530, Lokesh Vutla wrote: From: Sricharan R r.sricha...@ti.com SGX clocks should be enabled only for OMAP5 ES1.0. So this can be removed. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/cpu/armv7/omap5/hw_data.c |6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/cpu/armv7/omap5/hw_data.c b/arch/arm/cpu/armv7/omap5/hw_data.c index 604fa42..842cf27 100644 --- a/arch/arm/cpu/armv7/omap5/hw_data.c +++ b/arch/arm/cpu/armv7/omap5/hw_data.c @@ -383,12 +383,6 @@ void enable_basic_clocks(void) clk_modules_explicit_en_essential, 1); -/* Select 384Mhz for GPU as its the POR for ES1.0 */ -setbits_le32((*prcm)-cm_sgx_sgx_clkctrl, -CLKSEL_GPU_HYD_GCLK_MASK); -setbits_le32((*prcm)-cm_sgx_sgx_clkctrl, -CLKSEL_GPU_CORE_GCLK_MASK); - /* Enable SCRM OPT clocks for PER and CORE dpll */ setbits_le32((*prcm)-cm_wkupaon_scrm_clkctrl, OPTFCLKEN_SCRM_PER_MASK); Wait, will everyone with ES1.0 be updating to ES2.0 and be OK with this? Lubomir's board is ES1.0, currently. Thanks! Even if so, these clocks should/need not be enabled in boot loader. It should not have been enabled in, but earlier we had the habit enabling unnessecary things.. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/12] ARM: DRA7xx: Correct SRAM END address
On Wednesday 29 May 2013 06:36 PM, Tom Rini wrote: On Wed, May 29, 2013 at 04:32:43PM +0530, Lokesh Vutla wrote: From: Sricharan R r.sricha...@ti.com NON SECURE SRAM is 512KB in DRA7xx devices. So fixing it here. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/include/asm/arch-omap5/omap.h |7 --- include/configs/dra7xx_evm.h |3 +++ include/configs/omap5_uevm.h |3 +++ No, we need to handle this in the include files, not the config files. Ok.. The only concern was headers were shared between OMAP5/DRA and this results in #ifdef CONFIG_XX checks. Just thinking how to handle this better. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot OMAP issues
Hi Tom, On 29/05/13 16:24, Tom Rini wrote: On 05/29/2013 02:34 AM, Lubomir Popov wrote: Hi Tom, On 29.05.2013 01:55, Tom Rini wrote: On 05/27/2013 02:44 PM, Lubomir Popov wrote: P.S. I have an updated version of the I2C driver patch, with some minor improvements (mainly on identification of unconfigured bus). Should I submit it, what are you plans in respect to I2C? Yes, please submit the i2c driver changes, I shall take them in some form or another soon. OK, can even try to do this now from here. Submitted - http://patchwork.ozlabs.org/patch/246204/ Looking at it again, I tend to dislike this solution more and more. Ugly ifdef-ed code. Couldn't we reconsider again adding this as a new driver, built for those SoCs that are confirmed to work (OMAP4 and 5 for sure)? Lets take another swag at this. Update the functions for everyone and I'll get some omap3 testing done. OK, but you shall have to either entirely remove the ifdefs and the old functions, or edit the #if defined(CONFIG_OMAP)... conditions to include the SoC types you are testing on. Yeah. If you don't repost the patch with just always using the new functions, I'll do some local yanking out. I kinda hope to pencil that in as my task for tomorrow. Thanks :) OK, I shall do it now. Does it matter if I base on u-boot-ti, or on mainline? Guess not... Regards, Lubo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/12] ARM: DRA7xx: Correct SRAM END address
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/29/2013 09:33 AM, Sricharan R wrote: On Wednesday 29 May 2013 06:36 PM, Tom Rini wrote: On Wed, May 29, 2013 at 04:32:43PM +0530, Lokesh Vutla wrote: From: Sricharan R r.sricha...@ti.com NON SECURE SRAM is 512KB in DRA7xx devices. So fixing it here. Signed-off-by: Sricharan R r.sricha...@ti.com --- arch/arm/include/asm/arch-omap5/omap.h |7 --- include/configs/dra7xx_evm.h |3 +++ include/configs/omap5_uevm.h |3 +++ No, we need to handle this in the include files, not the config files. Ok.. The only concern was headers were shared between OMAP5/DRA and this results in #ifdef CONFIG_XX checks. Just thinking how to handle this better. That's fine. If we end up with large differences we can split the files, ala am335x and ti814x (and later, ti816x). - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRpgg/AAoJENk4IS6UOR1WwpoP/0dzJxZRFRRStw96ef46hi8m gtCBN4AXxTrv5+d2wgShOxmFTufTqHYJDi68kVKmrB3brMUjpgbp/ApTyi4a4vRh Dim9VWHHnlFZOKHwJwfDNr6CTx4mPXmI2qs94pfzHOvFmGtfkhYRVF/wbF1XwgW5 86Qep+YW1mr62t3kact+Cg6Pln3Krbb3RjX3waUSZeKzOlifaSI3Dntvp2uLgrA2 YQCIVVYd3TE8L7utgHF48v8x7aRuAxcd5ZtZvtXoVAxXv3zFyyibGyBFFXxnMmLz 0dFwUm9mE1+MYATAjcxlB+OpD5bJDp30JhtF0s42rvrQGyBxy1mdLAQBxR0DxoPa 1GvhQgWKGJKhwXr9TSDT3N1DTCt0nPEzjs7iekz2NLHjhoYMPL/yfj0rliyfaw5o O2S3I1d1Yy/V0gyLJgAey1SqC4G9n9XQyjsxAeSdosdDHSKUM3w6bkIS+UbTL8OZ gq1MteO/fddvSGQIR5+YQ6R7boH3BenSOxJRiKNMWVXlDiqZGgMRSEqT/HGnrBgh WBM0Va5c3HJjce4WXc+gWpJR+QREB6cHuc7lRGjI+VAKFioFDdaDXQSc2TJ6Q74W QRwl0xCMgykvXekHG9t+KXrSBFh1cDiJXeyI9dD3UnvE09Hzu1DwPCZf/XfhcT+4 ic2Z/9fUSgPfHFqZqOnq =/EmW -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/7] arm: vf610: Add Vybrid VF610 CPU support
Hi Alison, On Wednesday, May 29, 2013 7:37:32 AM, Wang Huan-B18965 wrote: Hi, Benoit, diff --git a/doc/README.vf610 b/doc/README.vf610 new file mode 100644 index 000..38cf5cf --- /dev/null +++ b/doc/README.vf610 @@ -0,0 +1,10 @@ +U-Boot for Freescale Vybrid VF610 + +This file contains information for the port of U-Boot to the +Freescale Vybrid +VF610 SoC. + +1. CONVENTIONS FOR FUSE ASSIGNMENTS +--- + +1.1 MAC Address: It is stored in fuse bank 4, with the 16 msbs in +word 2 and the +32 lsbs in word 3. The hunk below is still missing: doc/README.mxc_ocotp: --- on MXC This IP can be found on the following SoCs: + - Vybrid VF610, - i.MX6. Note that this IP is different from albeit similar to the IPs of the same name --- I have just noticed that this was actually in 6/7. Why are you putting this into a separate patch? [Alison Wang] Because patch 2/7 is about VF610 CPU support, and doc/README.vf610 is also a document about VF610 SoC. Doc/README.mxc_ocotp is the document about a driver (IP OCOTP), so this driver document should be separated from CPU patch 2/7. I don't think so: It's part of what comes with the addition of the VF610 platform, so 6/7 could be merged into 2/7. But it does not really matter. It's probably also fine if you keep what you did. Stefano, any opinion? Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 7/7] arm: vf610: Add basic support for Vybrid VF610TWR board
Hi Alison, On Wednesday, May 29, 2013 7:52:33 AM, Wang Huan-B18965 wrote: Hi, Benoit, + +#define CONFIG_CMD_PING +#define CONFIG_CMD_DHCP +#define CONFIG_CMD_MII +#define CONFIG_CMD_NET +#define CONFIG_FEC_MXC +#define CONFIG_MII +#define IMX_FEC_BASE ENET_BASE_ADDR +#define CONFIG_FEC_XCV_TYPE RMII +#define CONFIG_FEC_MXC_PHYADDR 0 Why don't you add support for the 2nd FEC? Do you plan to do it later? [Alison Wang] In u-boot, one FEC is enough for user. We do not plan to do it later. +#define CONFIG_PHYLIB +#define CONFIG_PHY_MICREL + +#define CONFIG_BOOTDELAY 3 + +#define CONFIG_SYS_TEXT_BASE 0x3f008000 + +/* Miscellaneous configurable options */ +#define CONFIG_SYS_LONGHELP /* undef to save memory */ +#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */ +#define CONFIG_SYS_PROMPT_HUSH_PS2 +#define CONFIG_SYS_PROMPTVybrid U-Boot +#undef CONFIG_AUTO_COMPLETE +#define CONFIG_SYS_CBSIZE256 /* Console I/O Buffer Size */ +#define CONFIG_SYS_PBSIZE\ + (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) +#define CONFIG_SYS_MAXARGS 16 /* max number of command args */ +#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE + +#define CONFIG_CMD_MEMTEST +#define CONFIG_SYS_MEMTEST_START 0x8001 +#define CONFIG_SYS_MEMTEST_END 0x87C0 Please make sure to have runtime-tested this address range with the mtest command since bad mtest addresses are the reason why CONFIG_CMD_MEMTEST has been removed from the default commands. [Alison Wang] Thanks for your reminder, we have tested. OK, then, for this patch: Reviewed-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/7] arm: vf610: Add IOMUX support for Vybrid VF610
Hi Stefano, On Wednesday, May 29, 2013 8:21:00 AM, Stefano Babic wrote: On 29/05/2013 07:29, Wang Huan-B18965 wrote: Where is this one defined? I don't see it in include/configs/vf610twr.h. [Alison Wang] CONFIG_IOMUX_SHARE_CONF_REG is defined in arch/arm/include/asm/arch-vf610/imx-regs.h. Because this is not a board configuration, it is related to the SOC. Please refer to Stefano's comments below which also could be found in the email on May 15th. Stefano wrote: + +/* MUX mode and PAD ctrl are in one register */ +#define CONFIG_IOMUX_SHARE_CONF_REG NAK. This is not a board configuration, it is related to the SOC. This setup should flow into the related imx-regs.h for this SOC. When you set CONFIG_MVF600, this value should be set automatically. Why not use #ifdef CONFIG_VF610 since this is a platform-dependent code, and not a board-specific config option? [Alison Wang] I use this CONFIG_IOMUX_SHARE_CONF_REG option, because this part of codes not only could be used on VF610 platform, but also could be used on VF620 or other platforms. When it is used on VF620 or others, you could just enable CONFIG_IOMUX_SHARE_CONF_REG in the related imx-regs.h. Otherwise, if ifdef CONFIG_VF610 is used, you need to add #if defined(CONFIG_VF610) || defined(CONFIG_VF620) When this part of codes is also used on VF620. Then when this part of codes is used on VF630 too, this line will be very very long. Agree. This is a property of the processor and should be automatically set. It should not flow into board config file, and having a family of processor we cannot use ifdef CONFIG_VF610. IMHO the patch is ok. Acked-by: Stefano Babic sba...@denx.de I agree: Reviewed-by: Benoît Thébaudeau benoit.thebaud...@advansee.com Best regards, Benoît ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
Hi Stephen,
On Tue, May 28, 2013 at 1:57 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/28/2013 01:36 PM, Simon Glass wrote:
There are a few partially conflicting requirements in compiling the device
tree, since U-Boot relies on whatever is installed on the build machine.
Some versions of dtc support -i, and this is often better than using #include
since you get correct line number information in errors.
What issue is there with line numbers when using dtc? Recent dtc
supports #line directives from the pre-processing results, and hence
reports errors in terms of the source files, just like raw dtc without cpp.
That's the issue. What does dtc v1.3 do?
Unfortunately this
version must be installed manually in current Linux distributions.
Well, then that gets into the problem of some .dts files choosing to use
/include/ and rely on -i, but others using #include and not. I don't
really think it's a good idea to propagate both versions. Picking one
and using it would be far better.
I really do think we should simply require a reasonably recent dtc and
be done with it.
I would be happy with that, but it can be an extra barrier to getting
U-Boot building. So do we need using #include at all if we are using
-i ?
Some device tree files use the word 'linux' which gets replaced with '1' by
many version of gcc, including version 4.7. So undefine this.
Linux chose to use -undef rather than undefining specific/individual
defines. It'd be best to be consistent to that .dts files are more
likely to be portable between the two.
Seems a bit extreme, but OK. Are you worried that gcc defines other
things without the double underscore?
diff --git a/dts/Makefile b/dts/Makefile
+# Provide a list of include directories for dtc
+DTS_INCS-y := -i $(SRCTREE)/arch/$(ARCH)/dts
+
+DTS_INCS-y += -i $(SRCTREE)/board/$(VENDOR)/dts
That has arch/ first then board/ ... (continued a few comments below)
+DTS_INCS-$(CONFIG_CHROMEOS) += -i $(SRCTREE)/cros/dts
Is that meant to be upstream?
+# Check if our dtc includes the -i option
+DTS_FLAGS := $(shell if ! dtc -i 21 | grep -q invalid option; then \
+ echo $(DTS_INCS-y); fi)
+
# We preprocess the device tree file provide a useful define
-DTS_CPPFLAGS := -x assembler-with-cpp \
+# Undefine 'linux' since it might be used in device tree files
+DTS_CPPFLAGS := -x assembler-with-cpp -Ulinux \
I'll repeat my request to use -undef instead.
-DARCH_CPU_DTS=\$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\
\
-DBOARD_DTS=\$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\ \
- -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts
+ -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include \
+ -I$(OBJTREE)/include2 \
Do we really want include or include2 (what's that?) at all? The .dts
files really should be standalone, and not interact with the U-Boot
headers at all.
I understood that you were wanting to make use of U-Boot defines. If
you want to include include/config.h then I think you need these.
+ -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts
\
... whereas this has board/ first then arch/. It'd be better to be
consistent.
OK
+ -include $(OBJTREE)/include/config.h
+
+DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in
Hmm. This really isn't a generated header file. Can this instead be
$(OBJTREE)/$(dir $@).$(notdir $@).dts or something like that?
I didn't say header file.
The nice thing about having everything in include/generated is that it
doesn't pollute the source for in-tree builds.
+DTS_SRC := board/$(VENDOR)/dts/$(DEVICE_TREE).dts
all: $(obj).depend $(LIB)
@@ -50,13 +68,19 @@ all: $(obj).depend $(LIB)
# the filename.
DT_BIN := $(obj)dt.dtb
-$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts
+DTC_CMD := $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DTS_FLAGS) $(DTS_TMP)
It may be better to leave $(DTS_TMP) in the make script below, so it's
more obvious what file is being compiled; the re-direct to $(DTS_TMP) is
left in the $(CPP) invocation below, so it'd also be consistent with that.
+$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
rc=$$( \
- cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \
- { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \
+ cat $ | $(CPP) -P $(DTS_CPPFLAGS) - $(DTS_TMP); \
+ { { $(DTC_CMD) 21 ; \
...
+ if [ $$rc != 0 ]; then \
+ echo Source file is $(DTS_SRC); \
+ echo Compiler: $(DTC_CMD); \
+ fi; \
Isn't that what make V=1 is for?
It produces about 800KB of other spiel though. If the build fails it
is already printing stuff out - so I find this useful.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
Hi Wolfgang, On Tue, May 28, 2013 at 2:08 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message 1369769778-12455-1-git-send-email-...@chromium.org you wrote: Some device tree files use the word 'linux' which gets replaced with '1' by many version of gcc, including version 4.7. So undefine this. I think this is not a good way to address this issue. The GCC documentation (section System-specific Predefined Macros [1]) desribes how this should be handled. The correct (TM) way to fix this is by adding -ansi or any -std option that requests strict conformance to the compiler/preprocessor command line. [1] http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros Stephen suggested a slightly more extreme version too - I was worried that all the typing stuff in U-Boot headers would break in this case, but I didn't actually test it, so perhaps it is fine. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request for u-boot-tegra/master into ARM/master
Hi Tom, On Tue, 28 May 2013 14:16:41 -0700, Tom Warren twarren.nvi...@gmail.com wrote: Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL for all the Tegra boards is OK, running a ./MAKEALL -a arm now. tools/checkpatch.pl is clean. The following changes since commit fd725691797bb3192af15a15c2cba7d0b2ee9327: arm: Enable -ffunction-sections / -fdata-sections / --gc-sections (2013-05-23 12:09:56 +0200) are available in the git repository at: git://git.denx.de/u-boot-tegra master for you to fetch changes up to 60985bba58e7695dac1fddae8cdbb62d8cfd1254: tegra: Define CONFIG_SKIP_LOWLEVEL_INIT for SPL build (2013-05-28 12:58:44 -0700) Allen Martin (1): Tegra: clk: always use find_best_divider() for periph clocks Axel Lin (2): ARM: arm720t: Add missing CONFIG_SKIP_LOWLEVEL_INIT guard for cpu_init_crit tegra: Define CONFIG_SKIP_LOWLEVEL_INIT for SPL build Stephen Warren (3): tegra: always build u-boot-nodtb-tegra.bin ARM: tegra: support SKU 1 of Tegra114 ARM: tegra: support SKU 7 of Tegra20 Tom Warren (2): Tegra: T30: Beaver: Fix board/board_name env vars, s/b beaver, not cardhu Tegra: Remove unused/non-existent spl linker script reference Makefile| 17 ++- arch/arm/cpu/arm720t/start.S| 4 ++-- arch/arm/cpu/tegra-common/ap.c | 2 ++ arch/arm/cpu/tegra-common/clock.c | 10 - arch/arm/include/asm/arch-tegra/tegra.h | 2 ++ board/nvidia/beaver/Makefile| 38 + boards.cfg | 2 +- include/configs/tegra-common-post.h | 2 ++ include/configs/tegra114-common.h | 2 -- include/configs/tegra20-common.h| 2 -- include/configs/tegra30-common.h| 2 -- 11 files changed, 59 insertions(+), 24 deletions(-) create mode 100644 board/nvidia/beaver/Makefile Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
On 05/29/2013 09:59 AM, Simon Glass wrote:
Hi Stephen,
On Tue, May 28, 2013 at 1:57 PM, Stephen Warren swar...@wwwdotorg.org wrote:
On 05/28/2013 01:36 PM, Simon Glass wrote:
There are a few partially conflicting requirements in compiling the device
tree, since U-Boot relies on whatever is installed on the build machine.
Some versions of dtc support -i, and this is often better than using
#include
since you get correct line number information in errors.
What issue is there with line numbers when using dtc? Recent dtc
supports #line directives from the pre-processing results, and hence
reports errors in terms of the source files, just like raw dtc without cpp.
That's the issue. What does dtc v1.3 do?
v1.3 doesn't include the feature, but it also doesn't support -i either.
Unfortunately this
version must be installed manually in current Linux distributions.
Well, then that gets into the problem of some .dts files choosing to use
/include/ and rely on -i, but others using #include and not. I don't
really think it's a good idea to propagate both versions. Picking one
and using it would be far better.
I really do think we should simply require a reasonably recent dtc and
be done with it.
I would be happy with that, but it can be an extra barrier to getting
U-Boot building.
The Linux kernel chose to solve this by bundling the required dtc source
inside the kernel source tree as a tool. This seems by far the simplest
way to solve the problem for U-Boot too. If not, it's not exactly hard to:
git clone
make
... given that one is already building U-Boot from source anyway.
So do we need using #include at all if we are using -i ?
Well, *.dts are moving to #include (and other cpp constructs) rather
than /include/ in the copies in the Linux kernel, which I think will
eventually make their way into U-Boot for consistency. Equally, if/when
*.dts get separated out into a separate project from the kernel, I think
we'd want the same to happen for U-Boot so that the same *.dts is used.
Then, there won't be a choice.
Some device tree files use the word 'linux' which gets replaced with '1' by
many version of gcc, including version 4.7. So undefine this.
Linux chose to use -undef rather than undefining specific/individual
defines. It'd be best to be consistent to that .dts files are more
likely to be portable between the two.
Seems a bit extreme, but OK. Are you worried that gcc defines other
things without the double underscore?
IIRC there were some other issues, yes. unix may have been one of
them. The problem was reported (and I think that fix suggested) by
someone else, so I don't remember the full details, although they're in
the mailing list archives I suppose.
diff --git a/dts/Makefile b/dts/Makefile
-DARCH_CPU_DTS=\$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVICE_TREE).dtsi\
\
-DBOARD_DTS=\$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TREE).dts\ \
- -I$(SRCTREE)/board/$(VENDOR)/dts -I$(SRCTREE)/arch/$(ARCH)/dts
+ -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include \
+ -I$(OBJTREE)/include2 \
Do we really want include or include2 (what's that?) at all? The .dts
files really should be standalone, and not interact with the U-Boot
headers at all.
I understood that you were wanting to make use of U-Boot defines. If
you want to include include/config.h then I think you need these.
I hope I didn't want to:-) The DT should really represent the HW not
anything about the way U-Boot is configured.
+ -include $(OBJTREE)/include/config.h
+
+DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in
Hmm. This really isn't a generated header file. Can this instead be
$(OBJTREE)/$(dir $@).$(notdir $@).dts or something like that?
I didn't say header file.
The nice thing about having everything in include/generated is that it
doesn't pollute the source for in-tree builds.
Well, it's in a directory that's for generated headers; it has
/include/ in the path. I don't think we should put it somewhere that C
code could accidentally #include it, irrespective of how (un-)likely
that is to get passed review. Also, for in-tree builds, doesn't every
single other derived file get put into the source tree? I'm not sure why
this file would need to be special?
+$(DT_BIN): $(TOPDIR)/$(DTS_SRC)
rc=$$( \
- cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \
- { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \
+ cat $ | $(CPP) -P $(DTS_CPPFLAGS) - $(DTS_TMP); \
+ { { $(DTC_CMD) 21 ; \
...
+ if [ $$rc != 0 ]; then \
+ echo Source file is $(DTS_SRC); \
+ echo Compiler: $(DTC_CMD); \
+ fi; \
Isn't that what make V=1 is for?
It produces about 800KB of other spiel though. If the build fails it
is already printing stuff out - so I find this useful.
But again, why be special? I could
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
On 05/28/2013 03:08 PM, Wolfgang Denk wrote: Dear Simon Glass, In message 1369769778-12455-1-git-send-email-...@chromium.org you wrote: Some device tree files use the word 'linux' which gets replaced with '1' by many version of gcc, including version 4.7. So undefine this. I think this is not a good way to address this issue. The GCC documentation (section System-specific Predefined Macros [1]) desribes how this should be handled. The correct (TM) way to fix this is by adding -ansi or any -std option that requests strict conformance to the compiler/preprocessor command line. [1] http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros -ansi at least was considered when the Linux kernel patches for dtc+cpp support were being developed, but it was rejected. While it possibly does solve this specific issue fine, there were other more general problems; IIRC (and I might not) it completely changes the way macro expansion happens, which results in it being pretty useless. Hence, -x assembler-with-cpp was chosen over e.g. -ansi. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
Dear Simon, In message CAPnjgZ2a+qrsPWTz5Y=48m_lcrqaiky0-sejudw8ay5asdw...@mail.gmail.com you wrote: I think this is not a good way to address this issue. The GCC documentation (section System-specific Predefined Macros [1]) desribes how this should be handled. The correct (TM) way to fix this is by adding -ansi or any -std option that requests strict conformance to the compiler/preprocessor command line. [1] http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros Stephen suggested a slightly more extreme version too - I was worried that all the typing stuff in U-Boot headers would break in this case, but I didn't actually test it, so perhaps it is fine. Yes, I've seen it. I think either approach is better that manually undef-ing specific variables. From my personal point of view I think the -undef approach is a bit of overkill, but I would not protest. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de panic: can't find / ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
Dear Stephen, In message 51a62f8d.9010...@wwwdotorg.org you wrote: The Linux kernel chose to solve this by bundling the required dtc source inside the kernel source tree as a tool. This seems by far the simplest way to solve the problem for U-Boot too. If not, it's not exactly hard to: Actually it's a horrible approach to fixing tool issues upstream. Or rather to NOT fixing issues. Instead of pushing forward that distros distribute useful, recent versions we simply copy the dtc source. Tomorrow we include the source tree for make, and next week for binutils and gcc. And in a few months we build a full distro. It's the same with the Kconfig approach to print only short compile messages - instead of fixing this once where it belongs (in make), a zillion projects copy the pretty expensive code around, because it is so much easier. It's frustrating to watch how good old methods that brought free software to the state we have today (or we had some time ago already) more and more get lost and forgotten :-( Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A rolling stone gathers momentum. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
Dear Stephen, In message 51a634b5.5060...@wwwdotorg.org you wrote: I think this is not a good way to address this issue. The GCC documentation (section System-specific Predefined Macros [1]) desribes how this should be handled. The correct (TM) way to fix this is by adding -ansi or any -std option that requests strict conformance to the compiler/preprocessor command line. [1] http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros -ansi at least was considered when the Linux kernel patches for dtc+cpp support were being developed, but it was rejected. While it possibly Can you provide references? I'd like to understand why it was rejected - it seems to be the official approach to the problem. does solve this specific issue fine, there were other more general problems; IIRC (and I might not) it completely changes the way macro expansion happens, which results in it being pretty useless. Hence, -x assembler-with-cpp was chosen over e.g. -ansi. Again, do you have any reference? completely changes the way macro expansion happens sounds terribly dangerous, so it would be better to know about that exactly... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You shouldn't make my toaster angry. - Household security explained in Johnny Quest ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
On 05/29/2013 03:31 PM, Wolfgang Denk wrote: Dear Stephen, In message 51a62f8d.9010...@wwwdotorg.org you wrote: The Linux kernel chose to solve this by bundling the required dtc source inside the kernel source tree as a tool. This seems by far the simplest way to solve the problem for U-Boot too. If not, it's not exactly hard to: Actually it's a horrible approach to fixing tool issues upstream. Or rather to NOT fixing issues. Instead of pushing forward that distros distribute useful, recent versions we simply copy the dtc source. I don't understand the hangup about the version of dtc that distros package. Sure, it'd be nice if distros updated the the (currently) latest version of dtc and packaged that, so that at some time the desired version was there, and everything just worked. However, that's not going to outright solve the problem for a /long/ time. What if someone wants to build U-Boot on Ubuntu 10.04 or RHEL 5. It seems quite reasonable for someone to be using those for development since they're long-term supported stable releases. Those releases don't have the (current) latest version of dtc packaged, and it's exceedingly unlikely anyone could push an update into those distros to update dtc, since they're probably in bug-fix-only mode right now, and a dtc update would be to add new features. So, to cover that issue we must: a) Get the latest dtc into distros right now. Wait until everyone has updated. Then, we can use the new features. This could take many many years. b) Simply require people to install dtc from source, if their distro doesn't already package the desired version. This will immediately solve the problem, and is honestly quite simple if you're already building other things (U-Boot) from source. I prefer option (b) here. And given that, I assert that whatever version distros package is largely irrelevant, since there's a trivial workaround if they don't have the desired version. Longer-term distros will pick up a new version, and remove the need for build-from-source, thus streamlining the process. To keep this process in check a bit, we could always pick a specific git commit or release version of dtc that each U-Boot version (release) will be allowed to assume. That will limit the number of times people need to update their locally-built dtc to at most once per U-Boot release. Hopefully much less often. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] OMAP: I2C: New read, write and probe functions
Tested on OMAP4/5 only, but should work on older OMAPs and
derivatives as well.
- Rewritten i2c_read to operate correctly with all types of chips
(old function could not read consistent data from some I2C slaves).
- Optimised i2c_write.
- New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
performs write access vs read. The old probe could hang the system
under certain conditions (e.g. unconfigured pads).
- The read/write/probe functions try to identify unconfigured bus.
- Status functions now read irqstatus_raw as per TRM guidelines
(except for OMAP243X and OMAP34XX).
- Driver now supports up to I2C5 (OMAP5).
Signed-off-by: Lubomir Popov lpo...@mm-sol.com
---
V3 changes:
- Removed old functions and conditional compilation. New functions
are now built unconditionally for all SoCs using this driver. The
only chip that should break is the OMAP2420 dinosaur.
- Interrupts are enabled for OMAP243X and OMAP34XX only (where we
don't have an irqstatus_raw register).
V2 changes:
- Probe tries to identify misconfigured pads as well.
- Status is retrieved from irqstatus_raw rather than from stat.
- Some minor style format changes.
drivers/i2c/omap24xx_i2c.c | 482 ++---
1 file changed, 326 insertions(+), 156 deletions(-)
mode change 100644 = 100755 drivers/i2c/omap24xx_i2c.c
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
old mode 100644
new mode 100755
index 54e9b15..deac0ec
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -18,6 +18,18 @@
*
* Adapted for OMAP2420 I2C, r-woodru...@ti.com
*
+ * Copyright (c) 2013 Lubomir Popov lpo...@mm-sol.com, MM Solutions
+ * New i2c_read, i2c_write and i2c_probe functions, tested on OMAP4/5
+ * only, but should work on older OMAPs and derivatives as well.
+ * - Rewritten i2c_read to operate correctly with all types of chips
+ * (old function could not read consistent data from some I2C slaves).
+ * - Optimized i2c_write.
+ * - New i2c_probe, optionally selectable via CONFIG_I2C_PROBE_WRITE,
+ * performs write access vs read. The old probe could hang the system
+ * under certain conditions (e.g. unconfigured pads).
+ * - The read/write/probe functions try to identify unconfigured bus.
+ * - Status functions now read irqstatus_raw as per TRM guidelines.
+ * - Driver now supports up to I2C5 (OMAP5).
*/
#include common.h
@@ -31,8 +43,11 @@ DECLARE_GLOBAL_DATA_PTR;
#define I2C_TIMEOUT1000
+/* Absolutely safe for status update at 100 kHz I2C: */
+#define I2C_WAIT 200
+
static int wait_for_bb(void);
-static u16 wait_for_pin(void);
+static u16 wait_for_event(void);
static void flush_fifo(void);
/*
@@ -137,10 +152,14 @@ void i2c_init(int speed, int slaveadd)
/* own address */
writew(slaveadd, i2c_base-oa);
writew(I2C_CON_EN, i2c_base-con);
-
- /* have to enable intrrupts or OMAP i2c module doesn't work */
+#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX)
+ /*
+* Have to enable interrupts for OMAP2/3, these IPs don't have
+* an 'irqstatus_raw' register and we shall have to poll 'stat'
+*/
writew(I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE |
I2C_IE_NACK_IE | I2C_IE_AL_IE, i2c_base-ie);
+#endif
udelay(1000);
flush_fifo();
writew(0x, i2c_base-stat);
@@ -150,88 +169,6 @@ void i2c_init(int speed, int slaveadd)
bus_initialized[current_bus] = 1;
}
-static int i2c_read_byte(u8 devaddr, u16 regoffset, u8 alen, u8 *value)
-{
- int i2c_error = 0;
- u16 status;
- int i = 2 - alen;
- u8 tmpbuf[2] = {(regoffset) 8, regoffset 0xff};
- u16 w;
-
- /* wait until bus not busy */
- if (wait_for_bb())
- return 1;
-
- /* one byte only */
- writew(alen, i2c_base-cnt);
- /* set slave address */
- writew(devaddr, i2c_base-sa);
- /* no stop bit needed here */
- writew(I2C_CON_EN | I2C_CON_MST | I2C_CON_STT |
- I2C_CON_TRX, i2c_base-con);
-
- /* send register offset */
- while (1) {
- status = wait_for_pin();
- if (status == 0 || status I2C_STAT_NACK) {
- i2c_error = 1;
- goto read_exit;
- }
- if (status I2C_STAT_XRDY) {
- w = tmpbuf[i++];
-#if !(defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
- defined(CONFIG_OMAP44XX) || defined(CONFIG_AM33XX) || \
- defined(CONFIG_OMAP54XX))
- w |= tmpbuf[i++] 8;
-#endif
- writew(w, i2c_base-data);
- writew(I2C_STAT_XRDY, i2c_base-stat);
- }
- if (status I2C_STAT_ARDY) {
- writew(I2C_STAT_ARDY, i2c_base-stat);
- break;
- }
- }
-
- /* set slave address */
-
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
Dear Stephen Warren, In message 51a67ec1.2000...@wwwdotorg.org you wrote: To keep this process in check a bit, we could always pick a specific git commit or release version of dtc that each U-Boot version (release) will be allowed to assume. That will limit the number of times people need to update their locally-built dtc to at most once per U-Boot release. Hopefully much less often. I think this is broken by design, in several aspects. First, U-Boot is usually not the only user of DTC. Second, assume you run a git bisect over a U-Boot tree - would you really want to switch DTC in- flight? Sorry, instead we should strive to be compatible to a reasonably old, stable version of DTC, like we do for all other tools as well. As mentioned before - just because RHEL 5 ships an ancient version of - say - make we will NOT start building this from the sources ourself. This cannot be the way to go. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de An expert is a person who avoids the small errors while sweeping on to the grand fallacy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
On 05/29/2013 03:33 PM, Wolfgang Denk wrote: Dear Stephen, In message 51a634b5.5060...@wwwdotorg.org you wrote: I think this is not a good way to address this issue. The GCC documentation (section System-specific Predefined Macros [1]) desribes how this should be handled. The correct (TM) way to fix this is by adding -ansi or any -std option that requests strict conformance to the compiler/preprocessor command line. [1] http://gcc.gnu.org/onlinedocs/cpp/System_002dspecific-Predefined-Macros.html#System_002dspecific-Predefined-Macros -ansi at least was considered when the Linux kernel patches for dtc+cpp support were being developed, but it was rejected. While it possibly Can you provide references? I'd like to understand why it was rejected - it seems to be the official approach to the problem. does solve this specific issue fine, there were other more general problems; IIRC (and I might not) it completely changes the way macro expansion happens, which results in it being pretty useless. Hence, -x assembler-with-cpp was chosen over e.g. -ansi. Again, do you have any reference? completely changes the way macro expansion happens sounds terribly dangerous, so it would be better to know about that exactly... Sorry, I was thinking about -traditional-cpp, not -ansi. We had considered -traditional-cpp as a workaround because DT uses property names that start with #, and this triggered cpp to treat them as macro names, which went wrong. However, due to -traditional-cpp being quite different from ISO cpp, we selected -x assembler-with-cpp instead, which both implements an ISO cpp, but also only handles pre-processing directives with the # in column 1. Now, let's discuss -ansi vs. -undef some more. Since DT is supposed to be a HW description, it shouldn't be using cpp's built-in macros to compile in different ways; there really isn't a concept of the target arch of compilation; a .dts file should simply compile the same way everywhere. Different DTs represent different HW; we don't use a single DT with conditional compilation to represent different HW. This led Rob Herring (one of the kernel device tree maintainers) to propose the following rules for cpp usage on device trees: https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-October/020831.html One of which was: - No gcc built-in define usage I don't see any disagreement with that bullet point in the thread, and indeed it makes sense to me for the reasons I outlined above. Some history on why we needed to not-define, or un-define, some macros (such as the linux macro we're discussing here) can be found in: http://linux-kernel.2935.n7.nabble.com/PATCH-V7-kbuild-create-a-rule-to-run-the-pre-processor-on-dts-files-td575632.html The last few messages there end up mentioning -undef, which we/I ended up using. It looks like -ansi wasn't mentioned at all when discussing this issue. However, I assert that -undef is better, since we end up without any pre-defined macros, which DT files shouldn't be using anyway. By my reading of the cpp manual link you send, -ansi simply stops non-conforming pre-defined macros from being defined, but doesn't stop them all being defined as -undef does. Hence, I prefer -undef. Oh, and another of Rob's proposed rules: - No kernel kconfig option usage Would also imply that U-Boots config headers shouldn't be accessible when compiling device trees. The last few kernel patches I sent to enable dtc+cpp usage were specifically aimed at limiting the set of headers that DT files can use to those specifically part of the DT bindings, and not general Linux headers, For example, see the following Linux kernel commit: == kbuild: create an include chroot for DT bindings The recent dtc+cpp support allows header files and C pre-processor defines/macros to be used when compiling device tree files. These headers will typically define various constants that are part of the device tree bindings. The original patch which set up the dtc+cpp include path only considered using those headers from device tree files. However, most are also useful for kernel code which needs to interpret the device tree. In both the DT files and the kernel, I'd like to include the DT-related headers in the same way, for example, dt-bindings/gpio/tegra-gpio.h. That will simplify any text which discusses the DT header locations. Creating a dt-bindings/ for kernel source to use is as simple as placing files into include/dt-bindings/. However, when compiling DT files, the include path should be restricted so that only the dt-bindings path is available; arbitrary kernel headers shouldn't be exposed. For this reason, create a specific include directory for use by dtc+cpp, and symlink dt-bindings from there to the actual location of include/dt-bindings/. For want of a better location, place this include chroot into the existing dts/ directory. arch/*/boot/dts/include/dt-bindings - ../../../../../include/dt-bindings
Re: [U-Boot] [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality
On 05/28/2013 09:11:17 PM, Zhang Ying-B40530 wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, May 29, 2013 6:34 AM To: Zhang Ying-B40530 Cc: Wood Scott-B07421; u-boot@lists.denx.de; aflem...@gmail.com; Xie Xiaobo-R63061; Ilya Yanok Subject: Re: [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality On 05/22/2013 08:26:31 PM, Zhang Ying-B40530 wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, May 22, 2013 11:46 PM To: Zhang Ying-B40530 Cc: Wood Scott-B07421; u-boot@lists.denx.de; aflem...@gmail.com; Xie Xiaobo-R63061; Ilya Yanok Subject: Re: [PATCH 5/6] spl: Make CONFIG_SPL_BUILD contain more functionality On 05/21/2013 09:15:08 PM, Zhang Ying-B40530 wrote: diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h index c28dfe0..a2bdcff 100644 --- a/include/configs/MPC8313ERDB.h +++ b/include/configs/MPC8313ERDB.h @@ -40,7 +40,9 @@ #define CONFIG_SPL_INIT_MINIMAL #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_NAND_SUPPORT +#ifdef CONFIG_SPL_BUILD #define CONFIG_SPL_NAND_MINIMAL +#endif #define CONFIG_SPL_FLUSH_IMAGE #define CONFIG_SPL_TARGET u-boot-with-spl.bin #define CONFIG_SPL_MPC83XX_WAIT_FOR_NAND diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h index 8b13b10..5bdd44a 100644 --- a/include/configs/P1022DS.h +++ b/include/configs/P1022DS.h @@ -41,7 +41,9 @@ #define CONFIG_SPL_INIT_MINIMAL #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_NAND_SUPPORT +#ifdef CONFIG_SPL_BUILD #define CONFIG_SPL_NAND_MINIMAL +#endif #define CONFIG_SPL_FLUSH_IMAGE #define CONFIG_SPL_TARGET u-boot-with-spl.bin diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h index 7ed634b..bc48d62 100644 --- a/include/configs/p1_p2_rdb_pc.h +++ b/include/configs/p1_p2_rdb_pc.h @@ -159,7 +159,9 @@ #define CONFIG_SPL_INIT_MINIMAL #define CONFIG_SPL_SERIAL_SUPPORT #define CONFIG_SPL_NAND_SUPPORT +#ifdef CONFIG_SPL_BUILD #define CONFIG_SPL_NAND_MINIMAL +#endif #define CONFIG_SPL_FLUSH_IMAGE #define CONFIG_SPL_TARGET u-boot-with-spl.bin Are you sure this belongs in this patch? [Zhang Ying] Yes, it is necessary. Because CONFIG_SPL_NAND_MINIMAL has been used in the file law.c and tlb.c in this patch. What I mean is that it should probably have been done earlier, when you introduced CONFIG_SPL_NAND_MINIMAL. [Zhang Ying] I can understand you mean. Because the symbol CONFIG_SPL_NAND_MINIMAL has been useless, I think no need to split out a separate patch. OK, it looks like CONFIG_SPL_NAND_MINIMAL was there before your patchset. I think that was an accidental left-over and should have been removed (it was replaced with CONFIG_SPL_NAND_DRIVERS, _BASE, and _ECC). Could you describe what specifically you're using it to mean here? [Zhang Ying] CONFIG_SPL_NAND_MINIMAL is effective only for mpc85xx NAND SPL. No, it's just a mistake that should be removed. It doesn't mean anything. There are other SPL targets that use minimal NAND drivers (e.g. mxc_nand_spl.c) that don't define this. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
On 05/29/2013 04:36 PM, Wolfgang Denk wrote: Dear Stephen Warren, In message 51a67ec1.2000...@wwwdotorg.org you wrote: To keep this process in check a bit, we could always pick a specific git commit or release version of dtc that each U-Boot version (release) will be allowed to assume. That will limit the number of times people need to update their locally-built dtc to at most once per U-Boot release. Hopefully much less often. I think this is broken by design, in several aspects. First, U-Boot is usually not the only user of DTC. Second, assume you run a git bisect over a U-Boot tree - would you really want to switch DTC in- flight? Sorry, instead we should strive to be compatible to a reasonably old, stable version of DTC, like we do for all other tools as well. As mentioned before - just because RHEL 5 ships an ancient version of - say - make we will NOT start building this from the sources ourself. This cannot be the way to go. So the result of that is that we can never ever use new features in any tool, at least in any meaningful time-frame. I think we need to differentiate between tools that are already stable and/or core to all aspects of the U-Boot build process (such as make), and tools that enable new features that are under development. Clearly the U-Boot makefiles have to be fairly cautious in their use of any new make features, so that everyone with any reasonable version of make can build U-Boot. However, when enabling a new feature, such as using device trees to configure U-Boot[1], for which tool support is new and evolving along with the feature itself, and which is only used on a very very few boards and even fewer SoCs right now within U-Boot, it seems entirely reasonable to demand that the people working on/with that new feature are aware that it's evolving, and that they may need to take a few extra steps to go out and get tools that support that new feature. No doubt once this feature has settled down a bit, and distros have pulled in newer versions of dtc, everthing will just work just like any other stable feature. If you don't accept this, then we simply have to ban any include use in U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd need to stop using that. We'd need to move *.dts into a single directory within U-Boot to work around that, or perhaps hard-coding relative include paths in *.dts might work. Similarly for the patches to support dtc+cpp usage, so we wouldn't be able to use named constants in DT files for many years, which would prevent sharing DT files with the kernel and/or any other standard repository of DT files, which are bound to use this feature. [1] Which is very specifically a different feature than simply having U-Boot pass a DT to the Linux kernel during boot, and perhaps modify it a little, which clearly is not a new feature. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] fopen/fwrite functions
Hi, experts: Could i use fopen/fwrite standard C lib functions in U-boot code? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/12] ARM: DRA7xx: Update support for DRA7xx Soc's
Hi, On Wednesday 29 May 2013 06:42 PM, Tom Rini wrote: On Wed, May 29, 2013 at 04:32:35PM +0530, Lokesh Vutla wrote: This series update support for DRA7xx family Socs and the data for DRA752 ES1.0 soc. This is on top of my recent Misc cleanup series: http://u-boot.10912.n7.nabble.com/PATCH-0-3-ARM-OMAP4-Misc-Cleanup-tt155877.html Tested on DRA752 ES1.0, OMAP5432 ES2.0, MAKEALL for all armv7 board has been verified. Aside from a few comments, everything else looks good. Oh, and please test with MAKEALL -s omap as well as -c armv7, thanks! Thanks Tom. Will address your comments and post a V2. Ok will do MAKEALL for omap boards also. Regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2 V5] spi: Enable SPI_PREAMBLE Mode
Hi, On Tue, May 28, 2013 at 11:10 PM, Rajeshwari Shinde rajeshwar...@samsung.com wrote: This patch set enables PREAMBLE Mode for EXYNOS SPI. Changes in v2: - Remove preamable_count variable which is not really needed - Fix checkpatch warning (multiple assignments) Changes in V3: - Modified the if logic in spi_rx_tx function - Added blank lines as suggested by Minkyu Kang. - Removed in_bytes check in while loop. - Added a error check. Changes in V4: - Corrected a if condition. Changes in V5: - In commit message header changed SPI to spi EXYNOS: SPI: to spi: exynos: Rajeshwari Shinde (2): spi: Add support for preamble bytes spi: exynos: Support SPI_PREAMBLE mode Hoping these patches can be applied soon... Regards, Simon drivers/spi/exynos_spi.c | 69 +++-- include/spi.h|5 +++ 2 files changed, 64 insertions(+), 10 deletions(-) -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
Hi, On Wed, May 29, 2013 at 4:07 PM, Stephen Warren swar...@wwwdotorg.orgwrote: On 05/29/2013 04:36 PM, Wolfgang Denk wrote: Dear Stephen Warren, In message 51a67ec1.2000...@wwwdotorg.org you wrote: To keep this process in check a bit, we could always pick a specific git commit or release version of dtc that each U-Boot version (release) will be allowed to assume. That will limit the number of times people need to update their locally-built dtc to at most once per U-Boot release. Hopefully much less often. I think this is broken by design, in several aspects. First, U-Boot is usually not the only user of DTC. Second, assume you run a git bisect over a U-Boot tree - would you really want to switch DTC in- flight? Sorry, instead we should strive to be compatible to a reasonably old, stable version of DTC, like we do for all other tools as well. As mentioned before - just because RHEL 5 ships an ancient version of - say - make we will NOT start building this from the sources ourself. This cannot be the way to go. So the result of that is that we can never ever use new features in any tool, at least in any meaningful time-frame. I think we need to differentiate between tools that are already stable and/or core to all aspects of the U-Boot build process (such as make), and tools that enable new features that are under development. Clearly the U-Boot makefiles have to be fairly cautious in their use of any new make features, so that everyone with any reasonable version of make can build U-Boot. However, when enabling a new feature, such as using device trees to configure U-Boot[1], for which tool support is new and evolving along with the feature itself, and which is only used on a very very few boards and even fewer SoCs right now within U-Boot, it seems entirely reasonable to demand that the people working on/with that new feature are aware that it's evolving, and that they may need to take a few extra steps to go out and get tools that support that new feature. No doubt once this feature has settled down a bit, and distros have pulled in newer versions of dtc, everthing will just work just like any other stable feature. If you don't accept this, then we simply have to ban any include use in U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd need to stop using that. We'd need to move *.dts into a single directory within U-Boot to work around that, or perhaps hard-coding relative include paths in *.dts might work. Similarly for the patches to support dtc+cpp usage, so we wouldn't be able to use named constants in DT files for many years, which would prevent sharing DT files with the kernel and/or any other standard repository of DT files, which are bound to use this feature. [1] Which is very specifically a different feature than simply having U-Boot pass a DT to the Linux kernel during boot, and perhaps modify it a little, which clearly is not a new feature. My patch: - doesn't require -i but uses it if available (ARCH_CPU_DTS works around this) - honours #define, #include, etc. - works with old and new versions of dtc - uses -Ulinux which we are thinking might be better done another way Let's not throw the baby out with the bathwater. I have no problem with updating my dtc as needed, but it would certainly be nice if U-Boot didn't require this. However, let's say Tegra needs a newer dtc than 1.3. I wonder whether we should just add a setting to tell U-Boot to not build the device tree at all? The same U-Boot binary can run on many different board times, just needing a different device tree. Rather than pick one, we could just pick none. Then if you want to use new features in dtc, just define CONFIG_OF_NO_BUILD, or similar, and you can deal with the device tree details yourself. MAKEALL/buildman will be happy with this. Otherwise for now I think my patch is a reasonable compromise in terms of features. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V9 0/9] EXYNOS5: Enable DWMMC, add FDT support for DWMMC and enable EMMC boot
On Tue, May 28, 2013 at 11:36 PM, Rajeshwari Birje rajeshwari.bi...@gmail.com wrote: Hi Andy, U seem to be busy. I you have no issues can I ask Minkyu Kang to take them in u-boot-samsung tree. Please do reply. It would be great to get this applied soon, thank you. -- Regards, Rajeshwari Shinde On Fri, May 24, 2013 at 11:16 AM, Rajeshwari Birje rajeshwari.bi...@gmail.com wrote: Hi Andy, Please do let us know if any comments on this patch set. If no comments can we get them merged, as they seem to be floating in mainline for quite sometime now. Regards, Rajeshwari Shinde On Sat, May 11, 2013 at 8:55 AM, Simon Glass s...@chromium.org wrote: On Sat, Apr 27, 2013 at 12:12 AM, amar_g amarendra...@samsung.com wrote: From: Amar amarendra...@samsung.com This patch set enables and initialises DWMMC for Exynos5250 on SMDK5250. Adds driver changes required for DWMMC. Adds FDT support for DWMMC. Adds EMMC boot support for SMDK5250. This patch set is based on: EXYNOS: mmc: support DesignWare Controller for Samsung-SoC, which is merged in u-boot-mmc. Exynos: clock: support get_mmc_clk for exynos. Add DT based ethernet driver for SMDK5250. SMDK5250: Add FDT support present at the following link http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/149991 Changes since V1: 1)Corrected in response to review comments. 2)Created separate board files for FDT and non-FDT versions. 3)Added binding file for DWMMC device node. 4)Removed the propname 'index' from device node. 5)Prefixed the vendor name 'samsung' before propname in device node. 6)Ensured to have same signature for the function exynos_dwmci_init() for both FDT and non-FDT versions. 7)EMMC clock setting has been moved from spl_boot.c to clock_init.c. Changes since V2: 1)Updation of commit message and resubmition of proper patch set. Changes since V3: 1)Updated to use the macro DWMCI_CTRL_SEND_AS_CCSD instead of the hard coded value (1 10). 2)In the file exynos_dw_mmc.c, replaced the new function exynos5_mmc_set_clk_div() with the existing function set_mmc_clk(). set_mmc_clk() will do the purpose. 3)In the file exynos_dw_mmc.c, computation of FSYS block clock divisor (pre-ratio) value is added. 4)Removed the new function exynos5_mmc_set_clk_div() from clock.c. Changes since V4: 1)Updated the function dwmci_send_cmd() to use get_timer() instead of using mdelay(1). 2)Replaced the function call 'exynos_dwmmc_init(0, 8);' with the function exynos_dwmmc_add_port() in smdk5250.c. 3)The function get_irom_func(int index) has been added to avoid type casting at many places. 4)Used the generic function mmc_boot_part_access() instead of two functions mmc_boot_open() and mmc_boot_close(). By doing so user can specify which boot partition to be accessed (opened / closed). Changes since V5: 1)Added the 'removable' flag to mmc device node. 2)Changed the mmc clock value from 50MHz to 52MHz in the function exynos_dwmci_add_port() present in file drivers/mmc/exynos_dw_mmc.c. 3)Enabled CONFIG_LCD only for non-FDT operation. 4)Removed the function call i2c_init() present inside the function board_i2c_init(). Changes since V6: 1)Re-based to the patch SMDK5250: Add PMIC voltage settings. Changes since V7: 1)Re-based to the patch Exynos: pwm: Remove dead code of function exynos5_get_pwm_clk. 2)In file dw_mmc.c, updated the function dwmci_setup_bus() to return 0 if (freq == 0).This is to avoid the run time exception raise:Signal # 8 caught. 3)In the files drivers/mmc/mmc.c and common/cmd_mmc.c, the piece of code involved in EMMC open/close and resize of EMMC boot partition has been made conditional and is enabled only if the macro CONFIG_SUPPORT_EMMC_BOOT is defined. 4)The macros FSYS1_MMC0_DIV_MASK and FSYS1_MMC0_DIV_VAL are made local to file clock_init.c. Changes since V8: 1)Re-based to the patch exynos: fdt: Add TMU node for snow. 2)In spl_boot.c, updated USB boot piece of code, to use get_irom_func(int index) to avoid type casting. 3)Updated the below in response to review comments a)Changed the type of input parameters from u32 to u8 for the function boot_part_access(). b)Updated the function call to use a constant value 1, for boot_part_access(mmc, 1, part_num, access). c)In function dwmci_init, auto stop command is disabled, as this feature is not required. The series tested on snow: Acked-by: Simon Glass
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
On 05/29/2013 10:46 PM, Simon Glass wrote: Hi, On Wed, May 29, 2013 at 4:07 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: On 05/29/2013 04:36 PM, Wolfgang Denk wrote: Dear Stephen Warren, In message 51a67ec1.2000...@wwwdotorg.org mailto:51a67ec1.2000...@wwwdotorg.org you wrote: To keep this process in check a bit, we could always pick a specific git commit or release version of dtc that each U-Boot version (release) will be allowed to assume. That will limit the number of times people need to update their locally-built dtc to at most once per U-Boot release. Hopefully much less often. I think this is broken by design, in several aspects. First, U-Boot is usually not the only user of DTC. Second, assume you run a git bisect over a U-Boot tree - would you really want to switch DTC in- flight? Sorry, instead we should strive to be compatible to a reasonably old, stable version of DTC, like we do for all other tools as well. As mentioned before - just because RHEL 5 ships an ancient version of - say - make we will NOT start building this from the sources ourself. This cannot be the way to go. So the result of that is that we can never ever use new features in any tool, at least in any meaningful time-frame. I think we need to differentiate between tools that are already stable and/or core to all aspects of the U-Boot build process (such as make), and tools that enable new features that are under development. Clearly the U-Boot makefiles have to be fairly cautious in their use of any new make features, so that everyone with any reasonable version of make can build U-Boot. However, when enabling a new feature, such as using device trees to configure U-Boot[1], for which tool support is new and evolving along with the feature itself, and which is only used on a very very few boards and even fewer SoCs right now within U-Boot, it seems entirely reasonable to demand that the people working on/with that new feature are aware that it's evolving, and that they may need to take a few extra steps to go out and get tools that support that new feature. No doubt once this feature has settled down a bit, and distros have pulled in newer versions of dtc, everthing will just work just like any other stable feature. If you don't accept this, then we simply have to ban any include use in U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd need to stop using that. We'd need to move *.dts into a single directory within U-Boot to work around that, or perhaps hard-coding relative include paths in *.dts might work. Similarly for the patches to support dtc+cpp usage, so we wouldn't be able to use named constants in DT files for many years, which would prevent sharing DT files with the kernel and/or any other standard repository of DT files, which are bound to use this feature. [1] Which is very specifically a different feature than simply having U-Boot pass a DT to the Linux kernel during boot, and perhaps modify it a little, which clearly is not a new feature. My patch: - doesn't require -i but uses it if available (ARCH_CPU_DTS works around this) If we ever need to support a dtc that doesn't implement -i, then we always need to support that. So, there's no point using -i when it's available; we should simply have a single way of writing the *.dts files that doesn't ever assume dtc -i is available. Otherwise, there will be rampant inconsistency between different *.dts files; how they're written, the flow by which they're compiled, etc. In other words, we /always/ have to use ARCH_CPU_DTS in *.dts throughout the entire U-Boot source tree if we're to support not using dtc -i. - honours #define, #include, etc. - works with old and new versions of dtc If we are forced to rely only upon features in old versions of dtc, we specifically shouldn't allow use of features that will only work with newer dtc. If we don't actively enforce this rule, we haven't achieved the goal of not relying upon new versions of dtc. ... However, let's say Tegra needs a newer dtc than 1.3. I wonder whether we This shouldn't be about whether a specific Soc's DT requires some feature or not. All the U-Boot *.dts should work the same way. should just add a setting to tell U-Boot to not build the device tree at all? The same U-Boot binary can run on many different board times, just needing a different device tree. Unfortunately, that's not remotely true yet for any Tegra system at least; there's still a bunch of C code specific to each board. The amount is reducing as things get migrated to DT, but we certainly aren't there yet. Rather than pick one, we could just pick none. Then if
[U-Boot] [PATCH 0/2 V3] exynos: Support a delay after deactivate for SPI
This patch set exports the function timer_get_us and adds a delay for devices that need some time to react after spi transation finishes This patch set is based on EXYNOS: SPI: Support SPI_PREAMBLE mode link: http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/162269; Changes in V2: - Removed #ifdefine for exported function. Changes in V3: - Rebased on [PATCH 0/2 V5] spi: Enable SPI_PREAMBLE Mode Rajeshwari Shinde (2): exynos: Export timer_get_us() to get microsecond timer spi: exynos: Support a delay after deactivate drivers/spi/exynos_spi.c | 19 +++ include/common.h |6 ++ 2 files changed, 25 insertions(+), 0 deletions(-) -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 V3] exynos: Export timer_get_us() to get microsecond timer
This function, if implemented by the board, provides a microsecond
timer. The granularity may be larger than 1us if hardware does not
support this.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Removed #ifdefine for exported function.
Changes in V3:
- None
include/common.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/common.h b/include/common.h
index 8a1f3e4..c228d44 100644
--- a/include/common.h
+++ b/include/common.h
@@ -590,6 +590,12 @@ void ddr_enable_ecc(unsigned int dram_size);
#endif
#endif
+/*
+ * Return the current value of a monotonically increasing microsecond timer.
+ * Granularity may be larger than 1us if hardware does not support this.
+ */
+ulong timer_get_us(void);
+
/* $(CPU)/cpu.c */
static inline int cpumask_next(int cpu, unsigned int mask)
{
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 V3] spi: exynos: Support a delay after deactivate
For devices that need some time to react after a spi transaction
finishes, add the ability to set a delay.
Implement this as a delay on the first/next transaction to avoid
any delay in the fairly common case where a SPI transaction is
followed by other processing.
Based on:
[U-Boot] [PATCH 0/2 V5] spi: Enable SPI_PREAMBLE Mode
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- None.
Changes in V3:
- Rebased on [PATCH 0/2 V5] spi: Enable SPI_PREAMBLE Mode
drivers/spi/exynos_spi.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index 01378d0..03cf503 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -38,6 +38,7 @@ struct spi_bus {
struct exynos_spi *regs;
int inited; /* 1 if this bus is ready for use */
int node;
+ uint deactivate_delay_us; /* Delay to wait after deactivate */
};
/* A list of spi buses that we know about */
@@ -52,6 +53,8 @@ struct exynos_spi_slave {
enum periph_id periph_id; /* Peripheral ID for this device */
unsigned int fifo_size;
int skip_preamble;
+ struct spi_bus *bus;/* Pointer to our SPI bus info */
+ ulong last_transaction_us; /* Time of last transaction end */
};
static struct spi_bus *spi_get_bus(unsigned dev_index)
@@ -97,6 +100,7 @@ struct spi_slave *spi_setup_slave(unsigned int busnum,
unsigned int cs,
}
bus = spi_bus[busnum];
+ spi_slave-bus = bus;
spi_slave-regs = bus-regs;
spi_slave-mode = mode;
spi_slave-periph_id = bus-periph_id;
@@ -107,6 +111,7 @@ struct spi_slave *spi_setup_slave(unsigned int busnum,
unsigned int cs,
spi_slave-fifo_size = 256;
spi_slave-skip_preamble = 0;
+ spi_slave-last_transaction_us = timer_get_us();
spi_slave-freq = bus-frequency;
if (max_hz)
@@ -371,9 +376,21 @@ void spi_cs_activate(struct spi_slave *slave)
{
struct exynos_spi_slave *spi_slave = to_exynos_spi(slave);
+ /* If it's too soon to do another transaction, wait */
+ if (spi_slave-bus-deactivate_delay_us
+ spi_slave-last_transaction_us) {
+ ulong delay_us; /* The delay completed so far */
+ delay_us = timer_get_us() - spi_slave-last_transaction_us;
+ if (delay_us spi_slave-bus-deactivate_delay_us)
+ udelay(spi_slave-bus-deactivate_delay_us - delay_us);
+ }
clrbits_le32(spi_slave-regs-cs_reg, SPI_SLAVE_SIG_INACT);
debug(Activate CS, bus %d\n, spi_slave-slave.bus);
spi_slave-skip_preamble = spi_slave-mode SPI_PREAMBLE;
+
+ /* Remember time of this transaction so we can honour the bus delay */
+ if (spi_slave-bus-deactivate_delay_us)
+ spi_slave-last_transaction_us = timer_get_us();
}
/**
@@ -423,6 +440,8 @@ static int spi_get_config(const void *blob, int node,
struct spi_bus *bus)
/* Use 500KHz as a suitable default */
bus-frequency = fdtdec_get_int(blob, node, spi-max-frequency,
50);
+ bus-deactivate_delay_us = fdtdec_get_int(blob, node,
+ spi-deactivate-delay, 0);
return 0;
}
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] spi: exynos: Minimise access to SPI FIFO level
Accessing SPI registers is slow, but access to the FIFO level register
in particular seems to be extraordinarily expensive (I measure up to
600ns). Perhaps it is required to synchronise with the SPI byte output
logic which might run at 1/8th of the 40MHz SPI speed (just a guess).
Reduce access to this register by filling up and emptying FIFOs
more completely, rather than just one word each time around the inner
loop.
Since the rxfifo value will now likely be much greater that what we read
before we fill the txfifo, we only fill the txfifo halfway. This is
because if the txfifo is empty, but the rxfifo has data in it, then writing
too much data to the txfifo may overflow the rxfifo as data arrives.
This speeds up SPI flash reading from about 1MB/s to about 2MB/s on snow.
Based on [PATCH 0/2 V3] exynos: Support a delay after deactivate for SPI
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Rebased on [PATCH 0/2 V5] spi: Enable SPI_PREAMBLE Mode
drivers/spi/exynos_spi.c | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index deb32bd..bcca3d6 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -259,24 +259,27 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave,
int todo,
/* Keep the fifos full/empty. */
spi_get_fifo_levels(regs, rx_lvl, tx_lvl);
- if (tx_lvl spi_slave-fifo_size out_bytes) {
+ while (tx_lvl spi_slave-fifo_size/2 out_bytes) {
temp = txp ? *txp++ : 0xff;
writel(temp, regs-tx_data);
out_bytes--;
+ tx_lvl++;
}
if (rx_lvl 0) {
- temp = readl(regs-rx_data);
- if (spi_slave-skip_preamble) {
- if (temp == SPI_PREAMBLE_END_BYTE) {
- spi_slave-skip_preamble = 0;
- stopping = 0;
+ while (rx_lvl 0) {
+ temp = readl(regs-rx_data);
+ if (spi_slave-skip_preamble) {
+ if (temp == SPI_PREAMBLE_END_BYTE) {
+ spi_slave-skip_preamble = 0;
+ stopping = 0;
+ }
+ } else {
+ if (rxp || stopping)
+ *rxp++ = temp;
+ in_bytes--;
}
- } else {
- if (rxp || stopping)
- *rxp++ = temp;
- in_bytes--;
- }
- toread--;
+ toread--;
+ rx_lvl--;
} else if (!toread) {
/*
* We have run out of input data, but haven't read
--
1.7.4.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Enhance dts/Makefile to be all things to all men
Hi Stephen, On Wed, May 29, 2013 at 10:11 PM, Stephen Warren swar...@wwwdotorg.orgwrote: On 05/29/2013 10:46 PM, Simon Glass wrote: Hi, On Wed, May 29, 2013 at 4:07 PM, Stephen Warren swar...@wwwdotorg.org mailto:swar...@wwwdotorg.org wrote: On 05/29/2013 04:36 PM, Wolfgang Denk wrote: Dear Stephen Warren, In message 51a67ec1.2000...@wwwdotorg.org mailto:51a67ec1.2000...@wwwdotorg.org you wrote: To keep this process in check a bit, we could always pick a specific git commit or release version of dtc that each U-Boot version (release) will be allowed to assume. That will limit the number of times people need to update their locally-built dtc to at most once per U-Boot release. Hopefully much less often. I think this is broken by design, in several aspects. First, U-Boot is usually not the only user of DTC. Second, assume you run a git bisect over a U-Boot tree - would you really want to switch DTC in- flight? Sorry, instead we should strive to be compatible to a reasonably old, stable version of DTC, like we do for all other tools as well. As mentioned before - just because RHEL 5 ships an ancient version of - say - make we will NOT start building this from the sources ourself. This cannot be the way to go. So the result of that is that we can never ever use new features in any tool, at least in any meaningful time-frame. I think we need to differentiate between tools that are already stable and/or core to all aspects of the U-Boot build process (such as make), and tools that enable new features that are under development. Clearly the U-Boot makefiles have to be fairly cautious in their use of any new make features, so that everyone with any reasonable version of make can build U-Boot. However, when enabling a new feature, such as using device trees to configure U-Boot[1], for which tool support is new and evolving along with the feature itself, and which is only used on a very very few boards and even fewer SoCs right now within U-Boot, it seems entirely reasonable to demand that the people working on/with that new feature are aware that it's evolving, and that they may need to take a few extra steps to go out and get tools that support that new feature. No doubt once this feature has settled down a bit, and distros have pulled in newer versions of dtc, everthing will just work just like any other stable feature. If you don't accept this, then we simply have to ban any include use in U-Boot; dtc -i isn't in distro-packaged versions of dtc, so we'd need to stop using that. We'd need to move *.dts into a single directory within U-Boot to work around that, or perhaps hard-coding relative include paths in *.dts might work. Similarly for the patches to support dtc+cpp usage, so we wouldn't be able to use named constants in DT files for many years, which would prevent sharing DT files with the kernel and/or any other standard repository of DT files, which are bound to use this feature. [1] Which is very specifically a different feature than simply having U-Boot pass a DT to the Linux kernel during boot, and perhaps modify it a little, which clearly is not a new feature. My patch: - doesn't require -i but uses it if available (ARCH_CPU_DTS works around this) I had to remove all sharp objects from the room half-way through reading your email :-) Gosh, things aren't that bad! If we ever need to support a dtc that doesn't implement -i, then we always need to support that. So, there's no point using -i when it's available; we should simply have a single way of writing the *.dts files that doesn't ever assume dtc -i is available. Otherwise, there will be rampant inconsistency between different *.dts files; how they're written, the flow by which they're compiled, etc. In other words, we /always/ have to use ARCH_CPU_DTS in *.dts throughout the entire U-Boot source tree if we're to support not using dtc -i. Well realistically at some point there will be a new dtc release, and perhaps a year or so after that we can maybe start deprecating this and requiring -i. - honours #define, #include, etc. - works with old and new versions of dtc If we are forced to rely only upon features in old versions of dtc, we specifically shouldn't allow use of features that will only work with newer dtc. If we don't actively enforce this rule, we haven't achieved the goal of not relying upon new versions of dtc. As you know I'm uncomfortable with the idea of using CPP to do things that I feel dtc should do for itself, but yes if dtc does not grow these features, we have little choice. But as an example, both
[U-Boot] [PATCH V2] spi: exynos: Support word transfers
Since SPI register access is so expensive, it is worth transferring data
a word at a time if we can. This complicates the driver unfortunately.
Use the byte-swapping feature to avoid having to convert to/from big
endian in software.
This change increases speed from about 2MB/s to about 4.5MB/s.
Based on [PATCH V2] spi: exynos: Minimise access to SPI FIFO level
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
Changes in V2:
- Rebased on [PATCH V2] spi: exynos: Minimise access to SPI FIFO level
arch/arm/include/asm/arch-exynos/spi.h | 11 -
drivers/spi/exynos_spi.c | 79 ++--
2 files changed, 74 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/spi.h
b/arch/arm/include/asm/arch-exynos/spi.h
index 7cab1e9..e67ad27 100644
--- a/arch/arm/include/asm/arch-exynos/spi.h
+++ b/arch/arm/include/asm/arch-exynos/spi.h
@@ -34,7 +34,7 @@ struct exynos_spi {
unsigned intrx_data;/* 0x1c */
unsigned intpkt_cnt;/* 0x20 */
unsigned char reserved2[4];
- unsigned char reserved3[4];
+ unsigned intswap_cfg; /* 0x28 */
unsigned intfb_clk; /* 0x2c */
unsigned char padding[0xffd0];
};
@@ -74,5 +74,14 @@ struct exynos_spi {
/* Packet Count */
#define SPI_PACKET_CNT_EN (1 16)
+/* Swap config */
+#define SPI_TX_SWAP_EN (1 0)
+#define SPI_TX_BYTE_SWAP (1 2)
+#define SPI_TX_HWORD_SWAP (1 3)
+#define SPI_TX_BYTE_SWAP (1 2)
+#define SPI_RX_SWAP_EN (1 4)
+#define SPI_RX_BYTE_SWAP (1 6)
+#define SPI_RX_HWORD_SWAP (1 7)
+
#endif /* __ASSEMBLY__ */
#endif
diff --git a/drivers/spi/exynos_spi.c b/drivers/spi/exynos_spi.c
index bcca3d6..4dda23b 100644
--- a/drivers/spi/exynos_spi.c
+++ b/drivers/spi/exynos_spi.c
@@ -216,12 +216,29 @@ static void spi_get_fifo_levels(struct exynos_spi *regs,
*
* @param regs SPI peripheral registers
* @param countNumber of bytes to transfer
+ * @param step Number of bytes to transfer in each packet (1 or 4)
*/
-static void spi_request_bytes(struct exynos_spi *regs, int count)
+static void spi_request_bytes(struct exynos_spi *regs, int count, int step)
{
+ /* For word address we need to swap bytes */
+ if (step == 4) {
+ setbits_le32(regs-mode_cfg,
+SPI_MODE_CH_WIDTH_WORD | SPI_MODE_BUS_WIDTH_WORD);
+ count /= 4;
+ setbits_le32(regs-swap_cfg, SPI_TX_SWAP_EN | SPI_RX_SWAP_EN |
+ SPI_TX_BYTE_SWAP | SPI_RX_BYTE_SWAP |
+ SPI_TX_HWORD_SWAP | SPI_RX_HWORD_SWAP);
+ } else {
+ /* Select byte access and clear the swap configuration */
+ clrbits_le32(regs-mode_cfg,
+SPI_MODE_CH_WIDTH_WORD | SPI_MODE_BUS_WIDTH_WORD);
+ writel(0, regs-swap_cfg);
+ }
+
assert(count count (1 16));
setbits_le32(regs-ch_cfg, SPI_CH_RST);
clrbits_le32(regs-ch_cfg, SPI_CH_RST);
+
writel(count | SPI_PACKET_CNT_EN, regs-pkt_cnt);
}
@@ -236,6 +253,7 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave,
int todo,
int toread;
unsigned start = get_timer(0);
int stopping;
+ int step;
out_bytes = in_bytes = todo;
@@ -243,10 +261,19 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave,
int todo,
!(spi_slave-mode SPI_SLAVE);
/*
+* Try to transfer words if we can. This helps read performance at
+* SPI clock speeds above about 20MHz.
+*/
+ step = 1;
+ if (!((todo | (uintptr_t)rxp | (uintptr_t)txp) 3)
+ !spi_slave-skip_preamble)
+ step = 4;
+
+ /*
* If there's something to send, do a software reset and set a
* transaction size.
*/
- spi_request_bytes(regs, todo);
+ spi_request_bytes(regs, todo, step);
/*
* Bytes are transmitted/received in pairs. Wait to receive all the
@@ -259,14 +286,26 @@ static int spi_rx_tx(struct exynos_spi_slave *spi_slave,
int todo,
/* Keep the fifos full/empty. */
spi_get_fifo_levels(regs, rx_lvl, tx_lvl);
+
+ /*
+* Don't completely fill the txfifo, since we don't want our
+* rxfifo to overflow, and it may already contain data.
+*/
while (tx_lvl spi_slave-fifo_size/2 out_bytes) {
- temp = txp ? *txp++ : 0xff;
+ if (!txp)
+ temp = -1;
+ else if (step == 4)
+ temp = *(uint32_t *)txp;
+ else
+ temp
