Re: [U-Boot] [RFC PATCH 1/2] dm: Add support for scsi/sata based devices

2016-09-26 Thread Michal Simek
Hi Simon,

On 27.9.2016 02:35, Simon Glass wrote:
> Hi Michal,
> 
> On 26 September 2016 at 05:06, Michal Simek  wrote:
>> On 24.9.2016 19:26, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On 8 September 2016 at 07:57, Michal Simek  wrote:
 All sata based drivers are bind and corresponding block
 device is created. Based on this find_scsi_device() is able
 to get back block device based on scsi_curr_dev pointer.

 intr_scsi() is commented now but it can be replaced by calling
 find_scsi_device() and scsi_scan().

 scsi_dev_desc[] is commented out but common/scsi.c heavily depends on
 it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol
 is reassigned to a block description allocated by uclass.
 There is only one block description by device now but it doesn't need to
 be correct when more devices are present.

 scsi_bind() ensures corresponding block device creation.
 uclass post_probe (scsi_post_probe()) is doing low level init.

 SCSI/SATA DM based drivers requires to have 64bit base address as
 the first entry in platform data structure to setup mmio_base.

 Signed-off-by: Michal Simek 
 ---

  cmd/scsi.c  | 38 ++
  common/board_r.c|  4 ++--
  common/scsi.c   | 17 -
  drivers/block/ahci-uclass.c | 38 ++
  drivers/block/ahci.c| 30 ++
  include/ahci.h  |  2 +-
  include/sata.h  |  3 +++
  include/scsi.h  | 15 ++-
  8 files changed, 134 insertions(+), 13 deletions(-)
>>>
>>> Thanks for looking at this. I've taken a look and have a few comments.
>>>
>>> It's confusing that you are changing both scsi and sata. Do you need
>>> to add a DM_SCSI also? As far as I can see, they are separate
>>> subsystems.
>>
>> TBH I am confused with that too. This is ceva sata driver
>> but we use scsi subsystem to work with it.
>> From my look sata is mostly copied from scsi but I don't know history of
>> it.
>> I will look at using just one interface - sata or scsi to see how this
>> will look like.
> 
> Here is my understanding. I may have it wrong.
> 
> SCSI should be a uclass
> SATA should be a uclass (called AHCI)
> 
> SCSI provide a library of functions which can be called by SCSI or
> SATA code. This is distinct from the uclass so really should be in
> some sort of common file.

will look at it.

> 
>>
>>
>>> I think you need a uclass which implements the scsi_scan() function.
>>> The existing code could be refactored so that the common parts are
>>> called from both scsi.c and your scsi-uclass.c. It should look for
>>> devices, and then create a block device for each. Since you don't know
>>> how many block devices to create, I don't think you can avoid creating
>>> them 'on the fly' in scsi_scan(). For an example, see
>>> usb_stor_probe_device().
>>
>> Will look.
>>
>>>
>>> Also we will need a sandbox device at some point so we can run tests.
>>
>> This can be added later.
>>
>>>
>>> Minor point - please put #idef CONFIG_DM_SATA first and the legacy
>>> path in the #else cause. Mostly you do this but in a few cases it is
>>> not consistent.
>>
>> ok. Will look at it.
>>
>>>
>>> A few more notes below.
>>>

 diff --git a/cmd/scsi.c b/cmd/scsi.c
 index 387ca1a262ab..dc1176610672 100644
 --- a/cmd/scsi.c
 +++ b/cmd/scsi.c
 @@ -10,6 +10,7 @@
   */
  #include 
  #include 
 +#include 
  #include 

  static int scsi_curr_dev; /* current device */
 @@ -25,6 +26,23 @@ int do_scsiboot(cmd_tbl_t *cmdtp, int flag, int argc, 
 char *const argv[])
  /*
   * scsi command intepreter
   */
 +#ifdef CONFIG_DM_SATA
 +struct udevice *find_scsi_device(int dev_num)
 +{
 +   struct udevice *bdev;
 +   int ret;
 +
 +   ret = blk_get_device(IF_TYPE_SCSI, dev_num, );
 +
 +   if (ret) {
 +   printf("SCSI Device %d not found\n", dev_num);
 +   return NULL;
 +   }
 +
 +   return bdev;
 +}
 +#endif
 +
  int do_scsi(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
  {
 switch (argc) {
 @@ -35,7 +53,18 @@ int do_scsi(cmd_tbl_t *cmdtp, int flag, int argc, char 
 *const argv[])
 if (strncmp(argv[1], "res", 3) == 0) {
 printf("\nReset SCSI\n");
 scsi_bus_reset();
 +
 +#if defined(CONFIG_DM_SATA)
 +   struct udevice *bdev;
 +
 +   bdev = find_scsi_device(scsi_curr_dev);
 +   if (!bdev)
 +   return CMD_RET_FAILURE;
 +
 

[U-Boot] [PATCH v3 1/2] mtd: nand : zynq_nand: Add nand driver support for zynq

2016-09-26 Thread Siva Durga Prasad Paladugu
Add nand flash controller driver support for zynq SoC.

Signed-off-by: Siva Durga Prasad Paladugu 
---
Changes for v3:
- Fixed compilation failure by correct errno.h inclusion
- Fixed compilation warning
Changes for v2:
- Corrected the from address
---
 drivers/mtd/nand/Kconfig |7 +
 drivers/mtd/nand/Makefile|1 +
 drivers/mtd/nand/zynq_nand.c | 1186 ++
 3 files changed, 1194 insertions(+)
 create mode 100644 drivers/mtd/nand/zynq_nand.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 5ce7d6d..7e5c436 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -80,6 +80,13 @@ config NAND_ARASAN
  controller. This uses the hardware ECC for read and
  write operations.
 
+config NAND_ZYNQ
+   bool "Support for Zynq Nand controller"
+   select SYS_NAND_SELF_INIT
+   help
+ This enables Nand driver support for Nand flash controller
+ found on Zynq SoC.
+
 comment "Generic NAND options"
 
 # Enhance depends when converting drivers to Kconfig which use this config
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1df9273..fd4bb66 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_NAND_OMAP_GPMC) += omap_gpmc.o
 obj-$(CONFIG_NAND_OMAP_ELM) += omap_elm.o
 obj-$(CONFIG_NAND_PLAT) += nand_plat.o
 obj-$(CONFIG_NAND_SUNXI) += sunxi_nand.o
+obj-$(CONFIG_NAND_ZYNQ) += zynq_nand.o
 
 else  # minimal SPL drivers
 
diff --git a/drivers/mtd/nand/zynq_nand.c b/drivers/mtd/nand/zynq_nand.c
new file mode 100644
index 000..cb3340d
--- /dev/null
+++ b/drivers/mtd/nand/zynq_nand.c
@@ -0,0 +1,1186 @@
+/*
+ * (C) Copyright 2016 Xilinx, Inc.
+ *
+ * Xilinx Zynq NAND Flash Controller Driver
+ * This driver is based on plat_nand.c and mxc_nand.c drivers
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* The NAND flash driver defines */
+#define ZYNQ_NAND_CMD_PHASE1
+#define ZYNQ_NAND_DATA_PHASE   2
+#define ZYNQ_NAND_ECC_SIZE 512
+#define ZYNQ_NAND_SET_OPMODE_8BIT  (0 << 0)
+#define ZYNQ_NAND_SET_OPMODE_16BIT (1 << 0)
+#define ZYNQ_NAND_ECC_STATUS   (1 << 6)
+#define ZYNQ_MEMC_CLRCR_INT_CLR1   (1 << 4)
+#define ZYNQ_MEMC_SR_RAW_INT_ST1   (1 << 6)
+#define ZYNQ_MEMC_SR_INT_ST1   (1 << 4)
+#define ZYNQ_MEMC_NAND_ECC_MODE_MASK   0xC
+
+/* Flash memory controller operating parameters */
+#define ZYNQ_NAND_CLR_CONFIG   ((0x1 << 1)  |  /* Disable interrupt */ \
+   (0x1 << 4)   |  /* Clear interrupt */ \
+   (0x1 << 6)) /* Disable ECC interrupt */
+
+/* Assuming 50MHz clock (20ns cycle time) and 3V operation */
+#define ZYNQ_NAND_SET_CYCLES   ((0x2 << 20) |  /* t_rr from nand_cycles */ \
+   (0x2 << 17)  |  /* t_ar from nand_cycles */ \
+   (0x1 << 14)  |  /* t_clr from nand_cycles */ \
+   (0x3 << 11)  |  /* t_wp from nand_cycles */ \
+   (0x2 << 8)   |  /* t_rea from nand_cycles */ \
+   (0x5 << 4)   |  /* t_wc from nand_cycles */ \
+   (0x5 << 0)) /* t_rc from nand_cycles */
+
+
+#define ZYNQ_NAND_DIRECT_CMD   ((0x4 << 23) |  /* Chip 0 from interface 1 */ \
+   (0x2 << 21))/* UpdateRegs operation */
+
+#define ZYNQ_NAND_ECC_CONFIG   ((0x1 << 2)  |  /* ECC available on APB */ \
+   (0x1 << 4)   |  /* ECC read at end of page */ \
+   (0x0 << 5)) /* No Jumping */
+
+#define ZYNQ_NAND_ECC_CMD1 ((0x80)  |  /* Write command */ \
+   (0x00 << 8)  |  /* Read command */ \
+   (0x30 << 16) |  /* Read End command */ \
+   (0x1 << 24))/* Read End command calid */
+
+#define ZYNQ_NAND_ECC_CMD2 ((0x85)  |  /* Write col change cmd */ \
+   (0x05 << 8)  |  /* Read col change cmd */ \
+   (0xE0 << 16) |  /* Read col change end cmd */ \
+   (0x1 << 24))/* Read col change
+   end cmd valid */
+/* AXI Address definitions */
+#define START_CMD_SHIFT3
+#define END_CMD_SHIFT  11
+#define END_CMD_VALID_SHIFT20
+#define ADDR_CYCLES_SHIFT  21
+#define CLEAR_CS_SHIFT 21
+#define ECC_LAST_SHIFT 10
+#define COMMAND_PHASE  (0 << 19)
+#define DATA_PHASE (1 << 19)
+#define ONDIE_ECC_FEATURE_ADDR 0x90
+#define ONDIE_ECC_FEATURE_ENABLE   0x08
+
+#define 

Re: [U-Boot] [PATCH 2/2] power: regulator: lp873x: Add regulator support

2016-09-26 Thread Keerthy



On Tuesday 27 September 2016 06:04 AM, Simon Glass wrote:

Hi,

On 26 September 2016 at 00:00, Keerthy  wrote:

The driver provides regulator set/get voltage
enable/disable functions for lp873x family of PMICs.

Signed-off-by: Keerthy 
---
 drivers/power/regulator/Kconfig|   8 +
 drivers/power/regulator/Makefile   |   1 +
 drivers/power/regulator/lp873x_regulator.c | 361 +
 3 files changed, 370 insertions(+)
 create mode 100644 drivers/power/regulator/lp873x_regulator.c

diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index adb710a..84cf914 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -123,3 +123,11 @@ config DM_REGULATOR_PALMAS
This enables implementation of driver-model regulator uclass
features for REGULATOR PALMAS and the family of PALMAS PMICs.
The driver implements get/set api for: value and enable.
+
+config DM_REGULATOR_LP873X
+   bool "Enable driver for LP873X PMIC regulators"
+depends on PMIC_LP873X
+   ---help---
+   This enables implementation of driver-model regulator uclass
+   features for REGULATOR LP873X and the family of LP873X PMICs.
+   The driver implements get/set api for: value and enable.
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 75080d4..2093048 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
 obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
 obj-$(CONFIG_REGULATOR_TPS65090) += tps65090_regulator.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_PALMAS) += palmas_regulator.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_LP873X) += lp873x_regulator.o
diff --git a/drivers/power/regulator/lp873x_regulator.c 
b/drivers/power/regulator/lp873x_regulator.c
new file mode 100644
index 000..7675173
--- /dev/null
+++ b/drivers/power/regulator/lp873x_regulator.c
@@ -0,0 +1,361 @@
+/*
+ * (C) Copyright 2016
+ * Texas Instruments Incorporated, 
+ *
+ * Keerthy 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const char lp873x_buck_ctrl[LP873X_BUCK_NUM] = {0x2, 0x4};
+static const char lp873x_buck_volt[LP873X_BUCK_NUM] = {0x6, 0x7};
+static const char lp873x_ldo_ctrl[LP873X_LDO_NUM] = {0x8, 0x9};
+static const char lp873x_ldo_volt[LP873X_LDO_NUM] = {0xA, 0xB};
+
+static int lp873x_buck_enable(struct udevice *dev, int op, bool *enable)
+{
+   int ret;
+   uint8_t val;
+   unsigned int adr;
+   struct dm_regulator_uclass_platdata *uc_pdata;
+
+   uc_pdata = dev_get_uclass_platdata(dev);
+   adr = uc_pdata->ctrl_reg;
+
+   ret = dm_i2c_u8_read(dev->parent, adr, );
+   if (ret < 0)
+   return ret;


You can use

val = dm_i2c_reg_reg(dev->parent, adr);


I guess you meant dm_i2c_reg_read.


if (val < 0)
   return val;

What is the benefit of using extra u8 variable?


Just keeping the consistency with write and read. ret stores the return
value and any case it is not added just for read so not a redundancy.

val is u8 and that is used with write as well hence i used the above.



But in this case, you should use pmic_reg_read(). We should avoid i2c
access in drivers. There is no need for it, and the PMIC may come in a
SPI version one day.



I checked the data manual entirely. No SPI support in the case of lp873x.

So I2C is the way to access.

Hence instead of multiple indirections:

pmic_reg_read--> pmic_read --> ops->read --> foo_read --> i2c_read

I have used the i2c read as it is the only means in case of this PMIC>
I am afraid i am yet to find a public document for this but i confirm 
there is no SPI involved and I2C is the way.


Hope this justifies why i used i2c directly here.

Regards,
Keerthy


+
+   if (op == PMIC_OP_GET) {
+   val &= LP873X_BUCK_MODE_MASK;
+
+   if (val)
+   *enable = true;
+   else
+   *enable = false;
+
+   return 0;
+   } else if (op == PMIC_OP_SET) {
+   if (*enable)
+   val |= LP873X_BUCK_MODE_MASK;
+   else
+   val &= ~(LP873X_BUCK_MODE_MASK);
+   ret = dm_i2c_u8_write(dev->parent, adr, );
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}


Regards,
Simon


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] power: pmic: lp873x: Add the base pmic support

2016-09-26 Thread Keerthy



On Tuesday 27 September 2016 06:04 AM, Simon Glass wrote:

Hi,

On 26 September 2016 at 00:00, Keerthy  wrote:

Add support to bind the regulators/child nodes with the pmic.

Signed-off-by: Keerthy 
---
 drivers/power/pmic/Kconfig  |  7 ++
 drivers/power/pmic/Makefile |  1 +
 drivers/power/pmic/lp873x.c | 59 +
 include/power/lp873x.h  | 19 +++
 4 files changed, 86 insertions(+)
 create mode 100644 drivers/power/pmic/lp873x.c
 create mode 100644 include/power/lp873x.h

diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 92931c5..00fcacb 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -142,3 +142,10 @@ config PMIC_PALMAS
---help---
The PALMAS is a PMIC containing several LDOs, SMPS.
This driver binds the pmic children.
+
+config PMIC_LP873X
+   bool "Enable driver for Texas Instruments LP873X PMIC"
+   depends on DM_PMIC
+   ---help---
+   The LP873X is a PMIC containing couple of LDOs and couple of SMPS.
+   This driver binds the pmic children.
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 828c0cf..334a24f 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_PMIC_RK808) += rk808.o
 obj-$(CONFIG_PMIC_TPS65090) += tps65090.o
 obj-$(CONFIG_PMIC_S5M8767) += s5m8767.o
 obj-$(CONFIG_$(SPL_)PMIC_PALMAS) += palmas.o
+obj-$(CONFIG_$(SPL_)PMIC_LP873X) += lp873x.o

 obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
 obj-$(CONFIG_POWER_MAX77696) += pmic_max77696.o
diff --git a/drivers/power/pmic/lp873x.c b/drivers/power/pmic/lp873x.c
new file mode 100644
index 000..ace798c
--- /dev/null
+++ b/drivers/power/pmic/lp873x.c
@@ -0,0 +1,59 @@
+/*
+ * (C) Copyright 2016 Texas Instruments Incorporated, 
+ * Keerthy 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct pmic_child_info pmic_children_info[] = {
+   { .prefix = "ldo", .driver = LP873X_LDO_DRIVER },
+   { .prefix = "buck", .driver = LP873X_BUCK_DRIVER },
+   { },
+};
+
+static int lp873x_bind(struct udevice *dev)
+{
+   int regulators_node;
+   const void *blob = gd->fdt_blob;
+   int children;
+   int node = dev->of_offset;
+
+   regulators_node = fdt_subnode_offset(blob, node, "regulators");
+
+   if (regulators_node <= 0) {
+   printf("%s: %s reg subnode not found!", __func__, dev->name);


These should be debug() I think. We should not be printing things in
drivers. Also it bloats the code for an error condition that should
never happen.


Ah my bad! I should have used debug here. I will fix this.




+   return -ENXIO;
+   }
+
+   children = pmic_bind_children(dev, regulators_node, pmic_children_info);
+   if (!children)
+   printf("%s: %s - no child found\n", __func__, dev->name);
+
+   /* Always return success for this device */
+   return 0;
+}
+
+static const struct udevice_id lp873x_ids[] = {
+   { .compatible = "ti,lp8732", .data = LP8732 },
+   { .compatible = "ti,lp8733" , .data = LP8733 },
+   { }
+};
+
+U_BOOT_DRIVER(pmic_lp873x) = {
+   .name = "lp873x_pmic",
+   .id = UCLASS_PMIC,
+   .of_match = lp873x_ids,
+   .bind = lp873x_bind,
+};
diff --git a/include/power/lp873x.h b/include/power/lp873x.h
new file mode 100644
index 000..e0c0711
--- /dev/null
+++ b/include/power/lp873x.h
@@ -0,0 +1,19 @@
+#defineLP8732  0x0
+#define LP8733 0x1
+
+#define LP873X_LDO_NUM 2
+#define LP873X_BUCK_NUM2
+
+/* Drivers name */
+#define LP873X_LDO_DRIVER  "lp873x_ldo"
+#define LP873X_BUCK_DRIVER "lp873x_buck"
+
+#define LP873X_BUCK_VOLT_MASK  0xFF
+#define LP873X_BUCK_VOLT_MAX_HEX   0xFF
+#define LP873X_BUCK_VOLT_MAX   336
+#define LP873X_BUCK_MODE_MASK  0x1
+
+#define LP873X_LDO_VOLT_MASK0x1F
+#define LP873X_LDO_VOLT_MAX_HEX 0x19
+#define LP873X_LDO_VOLT_MAX 330
+#define LP873X_LDO_MODE_MASK   0x1
--
1.9.1



Regards,
Simon


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 1/6] dm: i2c: Add u8 read/write i2c functions

2016-09-26 Thread Keerthy



On Tuesday 27 September 2016 06:03 AM, Simon Glass wrote:

On 25 September 2016 at 22:35, Keerthy  wrote:

Add u8 i2c read/write hooks.

Signed-off-by: Keerthy 
Reviewed-by: Tom Rini 
---
 drivers/i2c/i2c-uclass.c | 10 ++
 include/i2c.h| 24 
 2 files changed, 34 insertions(+)


Well, OK.

Reviewed-by: Simon Glass 


Thanks Simon.




___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] arm: dra7xx: Move fastboot options to defconfig

2016-09-26 Thread Lokesh Vutla


On Friday 23 September 2016 12:22 AM, Sam Protsenko wrote:
> Now that fastboot options are available in Kconfig, we can migrate them
> from DRA7 header to corresponding DRA7 defconfigs.
> 
> Signed-off-by: Sam Protsenko 

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> ---
>  configs/dra7xx_evm_defconfig|  8 
>  configs/dra7xx_hs_evm_defconfig |  8 
>  include/configs/dra7xx_evm.h| 18 +-
>  3 files changed, 25 insertions(+), 9 deletions(-)
> 
> diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
> index 64df490..321ac45 100644
> --- a/configs/dra7xx_evm_defconfig
> +++ b/configs/dra7xx_evm_defconfig
> @@ -14,6 +14,14 @@ CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_SPL_DMA_SUPPORT=y
>  CONFIG_HUSH_PARSER=y
> +CONFIG_FASTBOOT=y
> +CONFIG_USB_FUNCTION_FASTBOOT=y
> +CONFIG_CMD_FASTBOOT=y
> +CONFIG_ANDROID_BOOT_IMAGE=y
> +CONFIG_FASTBOOT_BUF_ADDR=0x8200
> +CONFIG_FASTBOOT_BUF_SIZE=0x2f00
> +CONFIG_FASTBOOT_FLASH=y
> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
>  CONFIG_CMD_ASKENV=y
> diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
> index 5fdc2b7..c0485e0 100644
> --- a/configs/dra7xx_hs_evm_defconfig
> +++ b/configs/dra7xx_hs_evm_defconfig
> @@ -18,6 +18,14 @@ CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_SPL_DMA_SUPPORT=y
>  CONFIG_HUSH_PARSER=y
> +CONFIG_FASTBOOT=y
> +CONFIG_USB_FUNCTION_FASTBOOT=y
> +CONFIG_CMD_FASTBOOT=y
> +CONFIG_ANDROID_BOOT_IMAGE=y
> +CONFIG_FASTBOOT_BUF_ADDR=0x8200
> +CONFIG_FASTBOOT_BUF_SIZE=0x2f00
> +CONFIG_FASTBOOT_FLASH=y
> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
>  CONFIG_CMD_ASKENV=y
> diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
> index 194804c..273374a 100644
> --- a/include/configs/dra7xx_evm.h
> +++ b/include/configs/dra7xx_evm.h
> @@ -121,15 +121,15 @@
>   DFU_ALT_INFO_EMMC \
>   DFU_ALT_INFO_RAM \
>   DFU_ALT_INFO_QSPI
> -
> -/* Fastboot */
> -#define CONFIG_USB_FUNCTION_FASTBOOT
> -#define CONFIG_CMD_FASTBOOT
> -#define CONFIG_ANDROID_BOOT_IMAGE
> -#define CONFIG_FASTBOOT_BUF_ADDRCONFIG_SYS_LOAD_ADDR
> -#define CONFIG_FASTBOOT_BUF_SIZE0x2F00
> -#define CONFIG_FASTBOOT_FLASH
> -#define CONFIG_FASTBOOT_FLASH_MMC_DEV   1
> +#else
> +/* Discard fastboot in SPL build, to spare some space */
> +#undef CONFIG_FASTBOOT
> +#undef CONFIG_USB_FUNCTION_FASTBOOT
> +#undef CONFIG_CMD_FASTBOOT
> +#undef CONFIG_ANDROID_BOOT_IMAGE
> +#undef CONFIG_FASTBOOT_BUF_ADDR
> +#undef CONFIG_FASTBOOT_BUF_SIZE
> +#undef CONFIG_FASTBOOT_FLASH
>  #endif
>  
>  #include 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/3] ARM: keystone: rename clk_get_rate() to ks_clk_get_rate()

2016-09-26 Thread Lokesh Vutla


On Monday 26 September 2016 05:15 PM, Masahiro Yamada wrote:
> The KeyStone platform has its own clk_get_rate() but its prototype
> is different from that of the common-clk (clk-uclass) framework.
> 
> Prefix the KeyStone specific implementation with _ks in order to
> avoid name-space conflict.
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Lokesh Vutla 

Thanks and regards,
Lokesh


> ---
> 
>  arch/arm/include/asm/ti-common/keystone_net.h |  4 ++--
>  arch/arm/mach-keystone/clock.c| 24 
>  arch/arm/mach-keystone/cmd_clock.c|  2 +-
>  arch/arm/mach-keystone/include/mach/clock.h   |  2 +-
>  include/configs/ti_armv7_keystone2.h  |  8 
>  5 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm/include/asm/ti-common/keystone_net.h 
> b/arch/arm/include/asm/ti-common/keystone_net.h
> index a0d0d9b..0627728 100644
> --- a/arch/arm/include/asm/ti-common/keystone_net.h
> +++ b/arch/arm/include/asm/ti-common/keystone_net.h
> @@ -51,9 +51,9 @@
>  
>  /* MDIO module input frequency */
>  #ifdef CONFIG_SOC_K2G
> -#define EMAC_MDIO_BUS_FREQ   (clk_get_rate(sys_clk0_3_clk))
> +#define EMAC_MDIO_BUS_FREQ   (ks_clk_get_rate(sys_clk0_3_clk))
>  #else
> -#define EMAC_MDIO_BUS_FREQ   (clk_get_rate(pass_pll_clk))
> +#define EMAC_MDIO_BUS_FREQ   (ks_clk_get_rate(pass_pll_clk))
>  #endif
>  /* MDIO clock output frequency */
>  #define EMAC_MDIO_CLOCK_FREQ 250 /* 2.5 MHz */
> diff --git a/arch/arm/mach-keystone/clock.c b/arch/arm/mach-keystone/clock.c
> index b25db1e..d8804724 100644
> --- a/arch/arm/mach-keystone/clock.c
> +++ b/arch/arm/mach-keystone/clock.c
> @@ -341,7 +341,7 @@ static unsigned long pll_freq_get(int pll)
>   return ret;
>  }
>  
> -unsigned long clk_get_rate(unsigned int clk)
> +unsigned long ks_clk_get_rate(unsigned int clk)
>  {
>   unsigned long freq = 0;
>  
> @@ -381,37 +381,37 @@ unsigned long clk_get_rate(unsigned int clk)
>   freq = pll_freq_get(CORE_PLL) / pll0div_read(4);
>   break;
>   case sys_clk0_2_clk:
> - freq = clk_get_rate(sys_clk0_clk) / 2;
> + freq = ks_clk_get_rate(sys_clk0_clk) / 2;
>   break;
>   case sys_clk0_3_clk:
> - freq = clk_get_rate(sys_clk0_clk) / 3;
> + freq = ks_clk_get_rate(sys_clk0_clk) / 3;
>   break;
>   case sys_clk0_4_clk:
> - freq = clk_get_rate(sys_clk0_clk) / 4;
> + freq = ks_clk_get_rate(sys_clk0_clk) / 4;
>   break;
>   case sys_clk0_6_clk:
> - freq = clk_get_rate(sys_clk0_clk) / 6;
> + freq = ks_clk_get_rate(sys_clk0_clk) / 6;
>   break;
>   case sys_clk0_8_clk:
> - freq = clk_get_rate(sys_clk0_clk) / 8;
> + freq = ks_clk_get_rate(sys_clk0_clk) / 8;
>   break;
>   case sys_clk0_12_clk:
> - freq = clk_get_rate(sys_clk0_clk) / 12;
> + freq = ks_clk_get_rate(sys_clk0_clk) / 12;
>   break;
>   case sys_clk0_24_clk:
> - freq = clk_get_rate(sys_clk0_clk) / 24;
> + freq = ks_clk_get_rate(sys_clk0_clk) / 24;
>   break;
>   case sys_clk1_3_clk:
> - freq = clk_get_rate(sys_clk1_clk) / 3;
> + freq = ks_clk_get_rate(sys_clk1_clk) / 3;
>   break;
>   case sys_clk1_4_clk:
> - freq = clk_get_rate(sys_clk1_clk) / 4;
> + freq = ks_clk_get_rate(sys_clk1_clk) / 4;
>   break;
>   case sys_clk1_6_clk:
> - freq = clk_get_rate(sys_clk1_clk) / 6;
> + freq = ks_clk_get_rate(sys_clk1_clk) / 6;
>   break;
>   case sys_clk1_12_clk:
> - freq = clk_get_rate(sys_clk1_clk) / 12;
> + freq = ks_clk_get_rate(sys_clk1_clk) / 12;
>   break;
>   default:
>   break;
> diff --git a/arch/arm/mach-keystone/cmd_clock.c 
> b/arch/arm/mach-keystone/cmd_clock.c
> index 3d5cf3f..06afa72 100644
> --- a/arch/arm/mach-keystone/cmd_clock.c
> +++ b/arch/arm/mach-keystone/cmd_clock.c
> @@ -74,7 +74,7 @@ int do_getclk_cmd(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
>  
>   clk = simple_strtoul(argv[1], NULL, 10);
>  
> - freq = clk_get_rate(clk);
> + freq = ks_clk_get_rate(clk);
>   if (freq)
>   printf("clock index [%d] - frequency %lu\n", clk, freq);
>   else
> diff --git a/arch/arm/mach-keystone/include/mach/clock.h 
> b/arch/arm/mach-keystone/include/mach/clock.h
> index e2bdec1..0d8a944 100644
> --- a/arch/arm/mach-keystone/include/mach/clock.h
> +++ b/arch/arm/mach-keystone/include/mach/clock.h
> @@ -125,7 +125,7 @@ extern int speeds[];
>  void init_plls(void);
>  void init_pll(const struct pll_init_data *data);
>  struct pll_init_data *get_pll_init_data(int pll);
> -unsigned long 

Re: [U-Boot] [PATCH 1/3] ARM: keystone: remove declaration of unused functions

2016-09-26 Thread Lokesh Vutla


On Monday 26 September 2016 05:15 PM, Masahiro Yamada wrote:
> These two functions are neither defined nor referenced.
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Lokesh Vutla 

Thanks and regards,
Lokesh

> ---
> 
>  arch/arm/mach-keystone/include/mach/clock.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/mach-keystone/include/mach/clock.h 
> b/arch/arm/mach-keystone/include/mach/clock.h
> index 72724aa..e2bdec1 100644
> --- a/arch/arm/mach-keystone/include/mach/clock.h
> +++ b/arch/arm/mach-keystone/include/mach/clock.h
> @@ -126,8 +126,6 @@ void init_plls(void);
>  void init_pll(const struct pll_init_data *data);
>  struct pll_init_data *get_pll_init_data(int pll);
>  unsigned long clk_get_rate(unsigned int clk);
> -unsigned long clk_round_rate(unsigned int clk, unsigned long hz);
> -int clk_set_rate(unsigned int clk, unsigned long hz);
>  int get_max_dev_speed(int *spds);
>  int get_max_arm_speed(int *spds);
>  void pll_pa_clk_sel(void);
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3 6/7] usb: ehci-atmel: Remove unnecessary clock calling

2016-09-26 Thread Wenyou Yang
Due to the peripheral clock driver improvement, remove the
unnecessary clock calling.

Signed-off-by: Wenyou Yang 
---

Changes in v3: None
Changes in v2: None

 drivers/usb/host/ehci-atmel.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 2b138c5..a5c6d34 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -56,9 +56,7 @@ struct ehci_atmel_priv {
 
 static int ehci_atmel_enable_clk(struct udevice *dev)
 {
-   struct udevice *dev_clk;
struct clk clk;
-   int periph;
int ret;
 
ret = clk_get_by_index(dev, 0, );
@@ -73,19 +71,6 @@ static int ehci_atmel_enable_clk(struct udevice *dev)
if (ret)
return -EINVAL;
 
-   periph = fdtdec_get_uint(gd->fdt_blob, clk.dev->of_offset, "reg", -1);
-   if (periph < 0)
-   return -EINVAL;
-
-   dev_clk = dev_get_parent(clk.dev);
-   if (!dev_clk)
-   return -ENODEV;
-
-   ret = clk_request(dev_clk, );
-   if (ret)
-   return ret;
-
-   clk.id = periph;
ret = clk_enable();
if (ret)
return ret;
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3 7/7] mmc: atmel_sdhci: Remove unnecessary clock calling

2016-09-26 Thread Wenyou Yang
Due to the peripheral and generated clock driver improvement,
remove the unnecessary clock calling.

Signed-off-by: Wenyou Yang 
Reviewed-by: Jaehoon Chung 
---

Changes in v3:
 - Fix typo, unneccessary -> unnecessary.
 - Add Reviewed-by tag.

Changes in v2: None

 drivers/mmc/atmel_sdhci.c | 27 ++-
 1 file changed, 2 insertions(+), 25 deletions(-)

diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
index d8f8087..080a0a1 100644
--- a/drivers/mmc/atmel_sdhci.c
+++ b/drivers/mmc/atmel_sdhci.c
@@ -51,29 +51,6 @@ struct atmel_sdhci_plat {
struct mmc mmc;
 };
 
-static int atmel_sdhci_get_clk(struct udevice *dev, int index, struct clk *clk)
-{
-   struct udevice *dev_clk;
-   int periph, ret;
-
-   ret = clk_get_by_index(dev, index, clk);
-   if (ret)
-   return ret;
-
-   periph = fdtdec_get_uint(gd->fdt_blob, clk->dev->of_offset, "reg", -1);
-   if (periph < 0)
-   return -EINVAL;
-
-   dev_clk = dev_get_parent(clk->dev);
-   ret = clk_request(dev_clk, clk);
-   if (ret)
-   return ret;
-
-   clk->id = periph;
-
-   return 0;
-}
-
 static int atmel_sdhci_probe(struct udevice *dev)
 {
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
@@ -86,7 +63,7 @@ static int atmel_sdhci_probe(struct udevice *dev)
struct clk clk;
int ret;
 
-   ret = atmel_sdhci_get_clk(dev, 0, );
+   ret = clk_get_by_index(dev, 0, );
if (ret)
return ret;
 
@@ -107,7 +84,7 @@ static int atmel_sdhci_probe(struct udevice *dev)
clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >> SDHCI_CLOCK_MUL_SHIFT;
gck_rate = clk_base * 100 * (clk_mul + 1);
 
-   ret = atmel_sdhci_get_clk(dev, 1, );
+   ret = clk_get_by_index(dev, 1, );
if (ret)
return ret;
 
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3 5/7] i2c: at91_i2c: Change error return -ENODEV to -EINVAL

2016-09-26 Thread Wenyou Yang
Change the error return value -ENODEV from to -EINVAL for more
reasonable.

Signed-off-by: Wenyou Yang 
Reviewed-by: Heiko Schocher 
---

Changes in v3: None
Changes in v2: None

 drivers/i2c/at91_i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c
index dcd3ce8..4bc54ee 100644
--- a/drivers/i2c/at91_i2c.c
+++ b/drivers/i2c/at91_i2c.c
@@ -190,7 +190,7 @@ static int at91_i2c_enable_clk(struct udevice *dev)
 
clk_rate = clk_get_rate();
if (!clk_rate)
-   return -ENODEV;
+   return -EINVAL;
 
bus->bus_clk_rate = clk_rate;
 
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3 4/7] i2c: at91_i2c: Remove unnecessary clock calling

2016-09-26 Thread Wenyou Yang
Due to the peripheral clock driver improvement, remove the
unnecessary clock calling.

Signed-off-by: Wenyou Yang 
Reviewed-by: Heiko Schocher 
---

Changes in v3: None
Changes in v2: None

 drivers/i2c/at91_i2c.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/drivers/i2c/at91_i2c.c b/drivers/i2c/at91_i2c.c
index d71f75c..dcd3ce8 100644
--- a/drivers/i2c/at91_i2c.c
+++ b/drivers/i2c/at91_i2c.c
@@ -176,34 +176,18 @@ static void at91_calc_i2c_clock(struct udevice *dev, int 
i2c_clk)
 static int at91_i2c_enable_clk(struct udevice *dev)
 {
struct at91_i2c_bus *bus = dev_get_priv(dev);
-   struct udevice *dev_clk;
struct clk clk;
ulong clk_rate;
-   int periph;
int ret;
 
ret = clk_get_by_index(dev, 0, );
if (ret)
return -EINVAL;
 
-   periph = fdtdec_get_uint(gd->fdt_blob, clk.dev->of_offset, "reg", -1);
-   if (periph < 0)
-   return -EINVAL;
-
-   dev_clk = dev_get_parent(clk.dev);
-   ret = clk_request(dev_clk, );
-   if (ret)
-   return ret;
-
-   clk.id = periph;
ret = clk_enable();
if (ret)
return ret;
 
-   ret = clk_get_by_index(dev_clk, 0, );
-   if (ret)
-   return ret;
-
clk_rate = clk_get_rate();
if (!clk_rate)
return -ENODEV;
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3 2/7] clk: at91: Improve the clock implementation

2016-09-26 Thread Wenyou Yang
For the peripheral clock, provide the clock ops for the clock
provider, such as spi0_clk. The .of_xlate is to get the clk->id,
the .enable is to enable the spi0 peripheral clock, the .get_rate
is to get the clock frequency.

The driver for periph32ck node is responsible for recursively
binding its children as clk devices, not provide the clock ops.

So do the generated clock and system clock.

Signed-off-by: Wenyou Yang 
Acked-by: Stephen Warren 
---

Changes in v3:
 - Remove the unneeded wrapper functions.
 - Fix typo, Invaild -> Invalid.
 - Add Acked-by tag.

Changes in v2:
 - For the periph32ck, periph64ck, gck, systemck nodes, they aren't
   the clock providers, are to house various actual clock providers,
   use UCLASS_MISC, instead of UCLASS_CLK.
 - For *_of_xlate(), add argument check.
 - Fix the implementation of the *_get_rate().
 - Use documentation-wise variables for *_clk_probe().
 - Remove the duplicated code, use the common functions.

 drivers/clk/at91/Kconfig  |  1 +
 drivers/clk/at91/clk-generated.c  | 87 +++
 drivers/clk/at91/clk-peripheral.c | 72 ++--
 drivers/clk/at91/clk-system.c | 57 ++---
 drivers/clk/at91/pmc.c| 62 
 drivers/clk/at91/pmc.h|  5 ++-
 6 files changed, 195 insertions(+), 89 deletions(-)

diff --git a/drivers/clk/at91/Kconfig b/drivers/clk/at91/Kconfig
index 10050d8..904ed48 100644
--- a/drivers/clk/at91/Kconfig
+++ b/drivers/clk/at91/Kconfig
@@ -1,6 +1,7 @@
 config CLK_AT91
bool "AT91 clock drivers"
depends on CLK
+   select MISC
help
  This option is used to enable the AT91 clock driver.
  The driver supports the AT91 clock generator, including
diff --git a/drivers/clk/at91/clk-generated.c b/drivers/clk/at91/clk-generated.c
index f6164cc..d36f64f 100644
--- a/drivers/clk/at91/clk-generated.c
+++ b/drivers/clk/at91/clk-generated.c
@@ -17,15 +17,41 @@ DECLARE_GLOBAL_DATA_PTR;
 #define GENERATED_SOURCE_MAX   6
 #define GENERATED_MAX_DIV  255
 
-struct generated_clk_priv {
+/**
+ * generated_clk_bind() - for the generated clock driver
+ * Recursively bind its children as clk devices.
+ *
+ * @return: 0 on success, or negative error code on failure
+ */
+static int generated_clk_bind(struct udevice *dev)
+{
+   return at91_clk_sub_device_bind(dev, "generic-clk");
+}
+
+static const struct udevice_id generated_clk_match[] = {
+   { .compatible = "atmel,sama5d2-clk-generated" },
+   {}
+};
+
+U_BOOT_DRIVER(generated_clk) = {
+   .name = "generated-clk",
+   .id = UCLASS_MISC,
+   .of_match = generated_clk_match,
+   .bind = generated_clk_bind,
+};
+
+/*-*/
+
+struct generic_clk_priv {
u32 num_parents;
 };
 
-static ulong generated_clk_get_rate(struct clk *clk)
+static ulong generic_clk_get_rate(struct clk *clk)
 {
struct pmc_platdata *plat = dev_get_platdata(clk->dev);
struct at91_pmc *pmc = plat->reg_base;
struct clk parent;
+   ulong clk_rate;
u32 tmp, gckdiv;
u8 parent_id;
int ret;
@@ -36,18 +62,22 @@ static ulong generated_clk_get_rate(struct clk *clk)
AT91_PMC_PCR_GCKCSS_MASK;
gckdiv = (tmp >> AT91_PMC_PCR_GCKDIV_OFFSET) & AT91_PMC_PCR_GCKDIV_MASK;
 
-   ret = clk_get_by_index(clk->dev, parent_id, );
+   ret = clk_get_by_index(dev_get_parent(clk->dev), parent_id, );
if (ret)
return 0;
 
-   return clk_get_rate() / (gckdiv + 1);
+   clk_rate = clk_get_rate() / (gckdiv + 1);
+
+   clk_free();
+
+   return clk_rate;
 }
 
-static ulong generated_clk_set_rate(struct clk *clk, ulong rate)
+static ulong generic_clk_set_rate(struct clk *clk, ulong rate)
 {
struct pmc_platdata *plat = dev_get_platdata(clk->dev);
struct at91_pmc *pmc = plat->reg_base;
-   struct generated_clk_priv *priv = dev_get_priv(clk->dev);
+   struct generic_clk_priv *priv = dev_get_priv(clk->dev);
struct clk parent, best_parent;
ulong tmp_rate, best_rate = rate, parent_rate;
int tmp_diff, best_diff = -1;
@@ -58,7 +88,7 @@ static ulong generated_clk_set_rate(struct clk *clk, ulong 
rate)
int ret;
 
for (i = 0; i < priv->num_parents; i++) {
-   ret = clk_get_by_index(clk->dev, i, );
+   ret = clk_get_by_index(dev_get_parent(clk->dev), i, );
if (ret)
return ret;
 
@@ -111,18 +141,20 @@ static ulong generated_clk_set_rate(struct clk *clk, 
ulong rate)
return 0;
 }
 
-static struct clk_ops generated_clk_ops = {
-   .get_rate = generated_clk_get_rate,
-   .set_rate = generated_clk_set_rate,
+static struct clk_ops generic_clk_ops = {
+   .of_xlate = at91_clk_of_xlate,
+   .get_rate = generic_clk_get_rate,
+

[U-Boot] [PATCH v3 3/7] gpio: atmel_pio4: Remove unnecessary clock calling

2016-09-26 Thread Wenyou Yang
Due to the peripheral clock driver improvement, remove the
unnecessary clock calling.

Signed-off-by: Wenyou Yang 
Acked-by: Stephen Warren 
---

Changes in v3: None
Changes in v2:
 - Add Acked-by tag for gpio/atmel_pio4.

 drivers/gpio/atmel_pio4.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpio/atmel_pio4.c b/drivers/gpio/atmel_pio4.c
index 7adea88..cb90b02 100644
--- a/drivers/gpio/atmel_pio4.c
+++ b/drivers/gpio/atmel_pio4.c
@@ -284,27 +284,15 @@ static int atmel_pio4_probe(struct udevice *dev)
struct atmel_pio4_platdata *plat = dev_get_platdata(dev);
struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
struct atmel_pioctrl_data *pioctrl_data;
-   struct udevice *dev_clk;
struct clk clk;
fdt_addr_t addr_base;
u32 nbanks;
-   int periph;
int ret;
 
ret = clk_get_by_index(dev, 0, );
if (ret)
return ret;
 
-   periph = fdtdec_get_uint(gd->fdt_blob, clk.dev->of_offset, "reg", -1);
-   if (periph < 0)
-   return -EINVAL;
-
-   dev_clk = dev_get_parent(clk.dev);
-   ret = clk_request(dev_clk, );
-   if (ret)
-   return ret;
-
-   clk.id = periph;
ret = clk_enable();
if (ret)
return ret;
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3 1/7] clk: clk-uclass: Assign clk->dev before call .of_xlate

2016-09-26 Thread Wenyou Yang
In order to make clk->dev available in ops->of_xlate() to get the
clock ID from the 'reg' property of the clock node, assign the
clk->dev before calling ops->of_xlate().

Signed-off-by: Wenyou Yang 
Acked-by: Stephen Warren 
---

Changes in v3: None
Changes in v2:
 - Add Acked-by tag.

 drivers/clk/clk-uclass.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 4d78e3f..4a3248b 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -80,6 +80,9 @@ int clk_get_by_index(struct udevice *dev, int index, struct 
clk *clk)
  __func__, ret);
return ret;
}
+
+   clk->dev = dev_clk;
+
ops = clk_dev_ops(dev_clk);
 
if (ops->of_xlate)
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3 0/7] clk: at91: Improve the clock implementation

2016-09-26 Thread Wenyou Yang
Add the clock ops for such as spi0_clk, which is the real clock
provider, instead of periph32ck, which only recursively bind its
children as clk devices. Also update the clocks called in the
drivers.

Changes in v3:
 - Remove the unneeded wrapper functions.
 - Fix typo, Invaild -> Invalid.
 - Add Acked-by tag.
 - Fix typo, unneccessary -> unnecessary.
 - Add Reviewed-by tag.

Changes in v2:
 - Add Acked-by tag.
 - For the periph32ck, periph64ck, gck, systemck nodes, they aren't
   the clock providers, are to house various actual clock providers,
   use UCLASS_MISC, instead of UCLASS_CLK.
 - For *_of_xlate(), add argument check.
 - Fix the implementation of the *_get_rate().
 - Use documentation-wise variables for *_clk_probe().
 - Remove the duplicated code, use the common functions.
 - Add Acked-by tag for gpio/atmel_pio4.

Wenyou Yang (7):
  clk: clk-uclass: Assign clk->dev before call .of_xlate
  clk: at91: Improve the clock implementation
  gpio: atmel_pio4: Remove unnecessary clock calling
  i2c: at91_i2c: Remove unnecessary clock calling
  i2c: at91_i2c: Change error return -ENODEV to -EINVAL
  usb: ehci-atmel: Remove unnecessary clock calling
  mmc: atmel_sdhci: Remove unnecessary clock calling

 drivers/clk/at91/Kconfig  |  1 +
 drivers/clk/at91/clk-generated.c  | 87 +++
 drivers/clk/at91/clk-peripheral.c | 72 ++--
 drivers/clk/at91/clk-system.c | 57 ++---
 drivers/clk/at91/pmc.c| 62 
 drivers/clk/at91/pmc.h|  5 ++-
 drivers/clk/clk-uclass.c  |  3 ++
 drivers/gpio/atmel_pio4.c | 12 --
 drivers/i2c/at91_i2c.c| 18 +---
 drivers/mmc/atmel_sdhci.c | 27 +---
 drivers/usb/host/ehci-atmel.c | 15 ---
 11 files changed, 201 insertions(+), 158 deletions(-)

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/8] x86: Add implementations of setjmp() and longjmp()

2016-09-26 Thread Bin Meng
On Tue, Sep 27, 2016 at 8:34 AM, Simon Glass  wrote:
> Hi Alex,
>
> On 26 September 2016 at 01:28, Alexander Graf  wrote:
>>
>>
>> On 26.09.16 09:21, Bin Meng wrote:
>>> Hi Alex,
>>>
>>> On Mon, Sep 26, 2016 at 3:05 PM, Alexander Graf  wrote:


 On 26.09.16 09:00, Bin Meng wrote:
> Hi Simon,
>
> On Mon, Sep 26, 2016 at 5:27 AM, Simon Glass  wrote:
>> Bring in these functions from Linux v4.4. They will be needed for EFI 
>> loader
>> support.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v2:
>> - Drop irrelevant comment
>> - Add a comment about .size
>> - Drop unnecessary .text directive
>> - Make longjmp() always cause setjmp() to return 1
>>
>>  arch/x86/cpu/Makefile |  2 +-
>>  arch/x86/cpu/setjmp.S | 66 
>> +++
>>  arch/x86/include/asm/setjmp.h | 24 
>>  3 files changed, 91 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/x86/cpu/setjmp.S
>>  create mode 100644 arch/x86/include/asm/setjmp.h
>>
>> diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile
>> index 2667e0b..f5b8c9e 100644
>> --- a/arch/x86/cpu/Makefile
>> +++ b/arch/x86/cpu/Makefile
>> @@ -10,7 +10,7 @@
>>
>>  extra-y= start.o
>>  obj-$(CONFIG_X86_RESET_VECTOR) += resetvec.o start16.o
>> -obj-y  += interrupts.o cpu.o cpu_x86.o call64.o
>> +obj-y  += interrupts.o cpu.o cpu_x86.o call64.o setjmp.o
>>
>>  AFLAGS_REMOVE_call32.o := -mregparm=3 \
>> $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
>> diff --git a/arch/x86/cpu/setjmp.S b/arch/x86/cpu/setjmp.S
>> new file mode 100644
>> index 000..7443274
>> --- /dev/null
>> +++ b/arch/x86/cpu/setjmp.S
>> @@ -0,0 +1,66 @@
>> +/*
>> + * Written by H. Peter Anvin 
>> + * Brought in from Linux v4.4 and modified for U-Boot
>> + * From Linux arch/um/sys-i386/setjmp.S
>> + *
>> + * SPDX-License-Identifier:GPL-2.0
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +
>
> I believe the above 3 includes are not needed.
>
>> +#define _REGPARM
>> +
>> +/*
>> + * The jmp_buf is assumed to contain the following, in order:
>> + * %ebx
>> + * %esp
>> + * %ebp
>> + * %esi
>> + * %edi
>> + * 
>> + */
>> +
>> +   .text
>> +   .align 4
>> +   .globl setjmp
>> +   .type setjmp, @function
>> +setjmp:
>> +#ifdef _REGPARM
>> +   movl %eax, %edx
>> +#else
>> +   movl 4(%esp), %edx
>> +#endif
>> +   popl %ecx   /* Return address, and adjust the stack 
>> */
>> +   xorl %eax, %eax /* Return value */
>> +   movl %ebx, (%edx)
>> +   movl %esp, 4(%edx)  /* Post-return %esp! */
>> +   pushl %ecx  /* Make the call/return stack happy */
>> +   movl %ebp, 8(%edx)
>> +   movl %esi, 12(%edx)
>> +   movl %edi, 16(%edx)
>> +   movl %ecx, 20(%edx) /* Return address */
>> +   ret
>> +
>> +   /* Provide function size if needed */
>> +   .size setjmp, .-setjmp
>> +
>> +   .align 4
>> +   .globl longjmp
>> +   .type longjmp, @function
>> +longjmp:
>> +#ifdef _REGPARM
>> +   xchgl %eax, %edx
>> +#else
>> +   movl 4(%esp), %edx  /* jmp_ptr address */
>> +#endif
>> +   movl 1, %eax
>
> This should be $1.
>
> But I still think the setjmp/longjump codes in efi_loader is wrong. We
> should have longjump() to pass the return value to setjmp().

 Why? Where's the difference?

>>>
>>> longjump() does not have the setjmp() return value as the parameter,
>>> which concerns me as it does not conform to the standard longjump()
>>> implementation. This v2 hardcoded the return value to 1, which makes
>>> the following logic work in efi_loader.
>>>
>>> if (setjmp(>exit_jmp)) {
>>> /* We returned from the child image */
>>> return EFI_EXIT(info->exit_status);
>>> }
>>>
>>> If we want such a simplified implementation in efi_loader, we should
>>> probably rename these functions to efi_setjmp() and efi_longjump().
>>
>> Ah, I see. The second parameter to longjmp() should be the the return
>> value after the jump - which the code above actually implements. And
>> then it clobbers it with a 1.
>>
>> I guess that's my fault, because I skipped the second argument bit in my
>> longjmp header definition. Please just add it to the longjmp prototype
>> and explicitly pass "1" as return value in (don't forget to adapt the
>> prototypes in arch/arm/include/asm/setjmp.h). I can fix up the arm code
>> later to actually pass 

[U-Boot] [PATCH v3] fsl-ifc-nand : Corrected the programming of chip select

2016-09-26 Thread Matt Weber
Corrected the chip selection in IFC_NAND_CSEL register. Due to this
issue in multi-chip nand use-case, IFC was always pointing to the last
probed chip even though the user select another device through "nand
device " command.

Also, remove the usage of ifc_ctrl->cs_nand from driver as chipselect
is a property of the chip not the controller.

Signed-off-by: Matthew Weber 
Signed-off-by: Ronak Desai 

--
v1 -> v2
[ Scott W
 - Update fsl_ifc_sram_init() with correct csel and
   cs_nand removed.

v2 -> v3
[ Prabhakar
 - Remove braces around if in fsl_ifc_chip_init()
---
 drivers/mtd/nand/fsl_ifc_nand.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index bc6bdc9..990b698 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -48,7 +48,7 @@ struct fsl_ifc_ctrl {
/* device info */
struct fsl_ifc regs;
void __iomem *addr;  /* Address of assigned IFC buffer*/
-   unsigned int cs_nand;/* On which chipsel NAND is connected*/
+   unsigned int cs_nand;/* On which chipsel NAND is connected*/
unsigned int page;   /* Last page written to / read from  */
unsigned int read_bytes; /* Number of bytes read during command   */
unsigned int column; /* Saved column from SEQIN   */
@@ -296,7 +296,7 @@ static int fsl_ifc_run_command(struct mtd_info *mtd)
int i;
 
/* set the chip select for NAND Transaction */
-   ifc_out32(>ifc_nand.nand_csel, ifc_ctrl->cs_nand);
+   ifc_out32(>ifc_nand.nand_csel, priv->bank << IFC_NAND_CSEL_SHIFT);
 
/* start read/write seq */
ifc_out32(>ifc_nand.nandseq_strt,
@@ -798,7 +798,7 @@ static void fsl_ifc_select_chip(struct mtd_info *mtd, int 
chip)
 {
 }
 
-static int fsl_ifc_sram_init(uint32_t ver)
+static int fsl_ifc_sram_init(uint32_t ver, struct fsl_ifc_mtd *priv)
 {
struct fsl_ifc_runtime *ifc = ifc_ctrl->regs.rregs;
uint32_t cs = 0, csor = 0, csor_8k = 0, csor_ext = 0;
@@ -823,7 +823,7 @@ static int fsl_ifc_sram_init(uint32_t ver)
return 1;
}
 
-   cs = ifc_ctrl->cs_nand >> IFC_NAND_CSEL_SHIFT;
+   cs = priv->bank;
 
/* Save CSOR and CSOR_ext */
csor = ifc_in32(_ctrl->regs.gregs->csor_cs[cs].csor);
@@ -850,7 +850,7 @@ static int fsl_ifc_sram_init(uint32_t ver)
ifc_out32(>ifc_nand.col0, 0x0);
 
/* set the chip select for NAND Transaction */
-   ifc_out32(>ifc_nand.nand_csel, ifc_ctrl->cs_nand);
+   ifc_out32(>ifc_nand.nand_csel, priv->bank << IFC_NAND_CSEL_SHIFT);
 
/* start read seq */
ifc_out32(>ifc_nand.nandseq_strt, IFC_NAND_SEQ_STRT_FIR_STRT);
@@ -911,10 +911,8 @@ static int fsl_ifc_chip_init(int devnum, u8 *addr)
csor = ifc_in32(>csor_cs[priv->bank].csor);
 
if ((cspr & CSPR_V) && (cspr & CSPR_MSEL) == CSPR_MSEL_NAND &&
-   (cspr & CSPR_BA) == CSPR_PHYS_ADDR(phys_addr)) {
-   ifc_ctrl->cs_nand = priv->bank << IFC_NAND_CSEL_SHIFT;
+   (cspr & CSPR_BA) == CSPR_PHYS_ADDR(phys_addr))
break;
-   }
}
 
if (priv->bank >= MAX_BANKS) {
@@ -1029,7 +1027,7 @@ static int fsl_ifc_chip_init(int devnum, u8 *addr)
 
ver = ifc_in32(>ifc_rev);
if (ver >= FSL_IFC_V1_1_0)
-   ret = fsl_ifc_sram_init(ver);
+   ret = fsl_ifc_sram_init(ver, priv);
if (ret)
return ret;
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 4/8] x86: Tidy up selection of building the EFI stub

2016-09-26 Thread Bin Meng
Hi Simon,

On Tue, Sep 27, 2016 at 8:35 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 26 September 2016 at 02:50, Bin Meng  wrote:
>> Hi Simon,
>>
>> On Mon, Sep 26, 2016 at 5:27 AM, Simon Glass  wrote:
>>> At present we use a CONFIG option in efi.h to determine whether we are
>>> building the EFI stub or not. This means that the same header cannot be
>>> used for EFI_LOADER support. The CONFIG option will be enabled for the
>>> whole build, even when not building the stub.
>>>
>>> Use a different define instead, set up just for the files that make up the
>>> stub.
>>>
>>> Signed-off-by: Simon Glass 
>>> ---
>>>
>>> Changes in v2:
>>> - Add new patch to tidy up selection of building the EFI stub
>>>
>>>  include/efi.h| 7 +--
>>>  lib/efi/Makefile | 4 ++--
>>>  2 files changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/include/efi.h b/include/efi.h
>>> index d07187c..3d58780 100644
>>> --- a/include/efi.h
>>> +++ b/include/efi.h
>>> @@ -30,8 +30,11 @@ struct efi_device_path;
>>>
>>>  #define EFI_BITS_PER_LONG  BITS_PER_LONG
>>>
>>> -/* With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64 */
>>> -#ifdef CONFIG_EFI_STUB_64BIT
>>> +/*
>>> + * With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64. EFI_STUB is set
>>> + * in lib/efi/Makefile, when building the stub.
>>> + */
>>> +#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
>>
>> I don't understand why this is needed?
>
> If building the 64-bit EFI stub, we need to use 64-bit ints for the
> stub, but 32-bits for the rest of U-Boot. So this header gets used
> both ways.
>

For 32-bit EFI stub or U-Boot itself, EFI_BITS_PER_LONG is defined as
BITS_PER_LONG which is 32.

>>
>>>  #undef EFI_BITS_PER_LONG
>>>  #define EFI_BITS_PER_LONG  64
>>>  #endif
>>> diff --git a/lib/efi/Makefile b/lib/efi/Makefile
>>> index e32dc14..9449600 100644
>>> --- a/lib/efi/Makefile
>>> +++ b/lib/efi/Makefile
>>> @@ -9,9 +9,9 @@ obj-$(CONFIG_EFI_STUB) += efi_info.o
>>>
>>>  CFLAGS_REMOVE_efi_stub.o := -mregparm=3 \
>>> $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
>>> -CFLAGS_efi_stub.o := -fpic -fshort-wchar
>>> +CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB
>>>  CFLAGS_REMOVE_efi.o := -mregparm=3 \
>>> $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
>>> -CFLAGS_efi.o := -fpic -fshort-wchar
>>> +CFLAGS_efi.o := -fpic -fshort-wchar -DEFI_STUB
>>>
>>>  extra-$(CONFIG_EFI_STUB) += efi_stub.o efi.o
>>> --

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/6] arm: efi: Add a hello world test program

2016-09-26 Thread Leif Lindholm

On Mon, Sep 26, 2016 at 08:09:40AM -0600, Simon Glass wrote:
> >> >> If so, can we just remove this for arm64?
> >> >
> >> > Actually I was hoping that Alexander might have a suitable arm64
> >> > HelloWorld.efi lying around. When I tried building UEFI for arm64, for
> >> > some reason it did not create it.
> >>
> >> Is it part of edk2? If so, Leif (CC'ed) might have one :). I usually
> >> use grub as my hello world application.
> >
> > There is a hello world application in EDK2, but it does not get built
> > as part of a normal platform build.
> > Currently it also fails to build for ARM* on its own :|
> > See
> > http://patchew.org/EDK2/1471021908-3509-1-git-send-email-leif.lindholm%40linaro.org/
> > for a hack of how to build one before upstream is resolved.
> >
> > If cross compiling, prepend GCC5_AARCH64_PREFIX=aarch64-linux-gnu- to
> > build command line.
> 
> Thanks for the pointer. Unfortunately that patch appears to make no
> differences for me. Are you able to build and send me a 64-bit
> HelloWorld.efi please?

So, I probably could, but if that isn't working for you, I'd quite
like to know why.

To make that a little less painful though, I've added support for
building the helloworld app to my set of scripts:
https://git.linaro.org/uefi/uefi-tools.git

This still depends on this (updated) patch.
https://lists.01.org/pipermail/edk2-devel/2016-September/002112.html

But with a current edk2, and a uefi-tools placed in the same directory
as the edk2 clone, could you try executing:

../uefi-tools/uefi-build.sh -A AARCH64 hello

If the build fails and creates messy output due to being parallel,
could you stick a -1 on that command line and send me the output (or
pastebin)?

/
Leif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 5/5] check-config: allow to complete build even with ad-hoc CONFIG options

2016-09-26 Thread Masahiro Yamada
Hi Simon,


2016-09-27 9:34 GMT+09:00 Simon Glass :
> Hi Masahiro,
>
> On 25 September 2016 at 22:05, Masahiro Yamada
>  wrote:
>> Currently, the check-config.sh terminates the build when unknown
>> ad-hoc options are detected.  I think it is too much because we may
>> want to patch config headers locally in a build/deployment project.
>>
>> So, let's relax check-config.sh to just warn even if it detects
>> options that are not in the whitelist.  Instead, this check can be
>> done at the end of build, along with other checks.  It will catch
>> more attention.
>>
>> Even with this change, the Buildman tool catches new warnings,
>> so Tom can give NACK to new ad-hoc options.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  scripts/check-config.sh | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> I am not sure this is a good idea. We need buildman to fail the build;
> otherwise patches will make it to mainline with new CONFIGs. Perhaps
> we should have an ENV variable to skip the check?


It is OK for me as long as there is a way to work-around this check,
ENV or whatever.





-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/5] check-config: fix wrong comment about how to build whitelist

2016-09-26 Thread Masahiro Yamada
Hi Simon,

2016-09-27 9:34 GMT+09:00 Simon Glass :
> Hi Masahiro,
>
> On 25 September 2016 at 22:04, Masahiro Yamada
>  wrote:
>> The command suggested in this comment block is wrong; it would not
>> rip off CONFIG options that had already been converted to Kconfig.
>>
>> Instead, we should use the scripts/build-whitelist.sh tool.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  scripts/check-config.sh | 9 ++---
>>  1 file changed, 2 insertions(+), 7 deletions(-)
>>
>> diff --git a/scripts/check-config.sh b/scripts/check-config.sh
>> index 28c8fe9..6618dfb 100755
>> --- a/scripts/check-config.sh
>> +++ b/scripts/check-config.sh
>> @@ -5,13 +5,8 @@
>>  # Check that the u-boot.cfg file provided does not introduce any new
>>  # ad-hoc CONFIG options
>>  #
>> -# You can generate the list of current ad-hoc CONFIG options (those which 
>> are
>> -# not in Kconfig) with this command:
>> -#
>> -# export LC_ALL=C LC_COLLATE=C
>> -# git grep CONFIG_ |tr ' \t' '\n\n' |sed -n 
>> 's/^\(CONFIG_[A-Z0-9_]*\).*/\1/p' \
>> -#  |sort |uniq >scripts/config_whitelist.txt;
>> -# unset LC_ALL LC_COLLATE
>> +# Use scripts/build-whitelist.sh to generate the list of current ad-hoc
>> +# CONFIG options (those which are not in Kconfig).
>
> For me the LC setup is needed. Does it work correctly without it for
> you? I found that the sorting was wrong.


I am not quite sure about this, but it worked for me.



I can see

export LC_ALL=C
export LC_COLLATE=C

in both check-config.sh and build-whitelist.sh


That's why?




-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 15/23] gpio: eg20t: Add driver for Intel EG20T GPIO controllers

2016-09-26 Thread Simon Glass
Hi Paul,

On 26 September 2016 at 12:29, Paul Burton  wrote:
> Add a driver for the GPIO controller found in the Intel EG20T Platform
> Controller Hub. This is used on the MIPS Boston development board to
> provide GPIOs including ethernet PHY reset.
>
> Signed-off-by: Paul Burton 
>
> ---
>
>  drivers/gpio/Kconfig  |   8 +++
>  drivers/gpio/Makefile |   1 +
>  drivers/gpio/eg20t-gpio.c | 133 
> ++
>  3 files changed, 142 insertions(+)
>  create mode 100644 drivers/gpio/eg20t-gpio.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 8d9ab52..4a6a22f 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -221,4 +221,12 @@ config MPC85XX_GPIO
>
>   The driver has been tested on MPC85XX, but it is likely that other
>   PowerQUICC III devices will work as well.
> +
> +config EG20T_GPIO
> +   bool "Intel EG20T GPIO driver"
> +   depends on DM_GPIO && DM_PCI
> +   help
> + Enable this to support the GPIO controller found in the Intel EG20T
> + Platform Controller Hub.

Can you add a few more details? How many GPIOs? Bank organisation?
Pull-up/down support?

> +
>  endmenu
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 8939226..a94aeb1 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -58,3 +58,4 @@ obj-$(CONFIG_MVEBU_GPIO)  += mvebu_gpio.o
>  obj-$(CONFIG_MSM_GPIO) += msm_gpio.o
>  obj-$(CONFIG_$(SPL_)PCF8575_GPIO)  += pcf8575_gpio.o
>  obj-$(CONFIG_PM8916_GPIO)  += pm8916_gpio.o
> +obj-$(CONFIG_EG20T_GPIO)   += eg20t-gpio.o
> diff --git a/drivers/gpio/eg20t-gpio.c b/drivers/gpio/eg20t-gpio.c
> new file mode 100644
> index 000..05db771
> --- /dev/null
> +++ b/drivers/gpio/eg20t-gpio.c
> @@ -0,0 +1,133 @@
> +/*
> + * Copyright (C) 2016 Imagination Technologies
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum {
> +   REG_IEN = 0x00,
> +   REG_ISTATUS = 0x04,
> +   REG_IDISP   = 0x08,
> +   REG_ICLR= 0x0c,
> +   REG_IMASK   = 0x10,
> +   REG_IMASKCLR= 0x14,
> +   REG_PO  = 0x18,
> +   REG_PI  = 0x1c,
> +   REG_PM  = 0x20,

How about using a struct?

> +};
> +
> +struct eg20t_gpio_priv {
> +   void *base;
> +};
> +
> +static int eg20t_gpio_get_value(struct udevice *dev, unsigned int offset)
> +{
> +   struct eg20t_gpio_priv *priv = dev_get_priv(dev);
> +   uint32_t pm, pval;
> +
> +   pm = readl(priv->base + REG_PM);
> +   if ((pm >> offset) & 0x1)
> +   pval = readl(priv->base + REG_PO);
> +   else
> +   pval = readl(priv->base + REG_PI);
> +
> +   return (pval >> offset) & 0x1;
> +}
> +
> +static int eg20t_gpio_set_value(struct udevice *dev, unsigned int offset,
> +   int value)
> +{
> +   struct eg20t_gpio_priv *priv = dev_get_priv(dev);
> +   uint32_t po;
> +
> +   po = readl(priv->base + REG_PO);
> +   if (value)
> +   po |= 1 << offset;
> +   else
> +   po &= ~(1 << offset);
> +   writel(po, priv->base + REG_PO);
> +   return 0;
> +}
> +
> +static int eg20t_gpio_direction_input(struct udevice *dev, unsigned int 
> offset)
> +{
> +   struct eg20t_gpio_priv *priv = dev_get_priv(dev);
> +   uint32_t pm;
> +
> +   pm = readl(priv->base + REG_PM);
> +   pm &= ~(1 << offset);
> +   writel(pm, priv->base + REG_PM);

clrbits_le32(ADDR, 1 << OFFSET);

> +   return 0;
> +}
> +
> +static int eg20t_gpio_direction_output(struct udevice *dev, unsigned int 
> offset,
> +  int value)
> +{
> +   struct eg20t_gpio_priv *priv = dev_get_priv(dev);
> +   uint32_t pm;
> +
> +   pm = readl(priv->base + REG_PM);
> +   pm |= 1 << offset;
> +   writel(pm, priv->base + REG_PM);

setbits_le32()

> +
> +   return eg20t_gpio_set_value(dev, offset, value);
> +}
> +
> +static int eg20t_gpio_get_function(struct udevice *dev, unsigned int offset)
> +{
> +   struct eg20t_gpio_priv *priv = dev_get_priv(dev);
> +   uint32_t pm;
> +
> +   pm = readl(priv->base + REG_PM);
> +
> +   if ((pm >> offset) & 0x1)
> +   return GPIOF_OUTPUT;
> +
> +   return GPIOF_INPUT;

Can it have pins which are GPIOF_FUNC?

> +}
> +
> +static const struct dm_gpio_ops eg20t_gpio_ops = {
> +   .direction_input= eg20t_gpio_direction_input,
> +   .direction_output   = eg20t_gpio_direction_output,
> +   .get_value  = eg20t_gpio_get_value,
> +   .set_value  = eg20t_gpio_set_value,
> +   .get_function   = eg20t_gpio_get_function,
> +};
> +
> +static int eg20t_gpio_probe(struct udevice *dev)
> +{
> +   struct eg20t_gpio_priv *priv = 

Re: [U-Boot] [PATCH 06/23] pci: Set of_offset for devices not probed via DT compatible strings

2016-09-26 Thread Simon Glass
Hi Paul,

On 26 September 2016 at 12:29, Paul Burton  wrote:
> A PCI device may be probed through standard PCI config space probing but
> still be represented in a device tree. However U-Boot would not
> previously set the of_offset field of the struct udevice for such PCI
> devices. Fix this by searching for a DT node based upon its "reg"
> property after binding a PCI device that wasn't already seen in the DT.
>
> Signed-off-by: Paul Burton 
>
> ---
>
>  drivers/pci/pci-uclass.c | 32 
>  1 file changed, 32 insertions(+)

I can't see how this can happen. The PCI binding is supposed to
operate using the device tree:

/* Find this device in the device tree */
ret = pci_bus_find_devfn(bus, PCI_MASK_BUS(bdf), );

Do you know what is going wrong?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH 1/2] dm: Add support for scsi/sata based devices

2016-09-26 Thread Simon Glass
Hi Michal,

On 26 September 2016 at 05:06, Michal Simek  wrote:
> On 24.9.2016 19:26, Simon Glass wrote:
>> Hi Michal,
>>
>> On 8 September 2016 at 07:57, Michal Simek  wrote:
>>> All sata based drivers are bind and corresponding block
>>> device is created. Based on this find_scsi_device() is able
>>> to get back block device based on scsi_curr_dev pointer.
>>>
>>> intr_scsi() is commented now but it can be replaced by calling
>>> find_scsi_device() and scsi_scan().
>>>
>>> scsi_dev_desc[] is commented out but common/scsi.c heavily depends on
>>> it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol
>>> is reassigned to a block description allocated by uclass.
>>> There is only one block description by device now but it doesn't need to
>>> be correct when more devices are present.
>>>
>>> scsi_bind() ensures corresponding block device creation.
>>> uclass post_probe (scsi_post_probe()) is doing low level init.
>>>
>>> SCSI/SATA DM based drivers requires to have 64bit base address as
>>> the first entry in platform data structure to setup mmio_base.
>>>
>>> Signed-off-by: Michal Simek 
>>> ---
>>>
>>>  cmd/scsi.c  | 38 ++
>>>  common/board_r.c|  4 ++--
>>>  common/scsi.c   | 17 -
>>>  drivers/block/ahci-uclass.c | 38 ++
>>>  drivers/block/ahci.c| 30 ++
>>>  include/ahci.h  |  2 +-
>>>  include/sata.h  |  3 +++
>>>  include/scsi.h  | 15 ++-
>>>  8 files changed, 134 insertions(+), 13 deletions(-)
>>
>> Thanks for looking at this. I've taken a look and have a few comments.
>>
>> It's confusing that you are changing both scsi and sata. Do you need
>> to add a DM_SCSI also? As far as I can see, they are separate
>> subsystems.
>
> TBH I am confused with that too. This is ceva sata driver
> but we use scsi subsystem to work with it.
> From my look sata is mostly copied from scsi but I don't know history of
> it.
> I will look at using just one interface - sata or scsi to see how this
> will look like.

Here is my understanding. I may have it wrong.

SCSI should be a uclass
SATA should be a uclass (called AHCI)

SCSI provide a library of functions which can be called by SCSI or
SATA code. This is distinct from the uclass so really should be in
some sort of common file.

>
>
>> I think you need a uclass which implements the scsi_scan() function.
>> The existing code could be refactored so that the common parts are
>> called from both scsi.c and your scsi-uclass.c. It should look for
>> devices, and then create a block device for each. Since you don't know
>> how many block devices to create, I don't think you can avoid creating
>> them 'on the fly' in scsi_scan(). For an example, see
>> usb_stor_probe_device().
>
> Will look.
>
>>
>> Also we will need a sandbox device at some point so we can run tests.
>
> This can be added later.
>
>>
>> Minor point - please put #idef CONFIG_DM_SATA first and the legacy
>> path in the #else cause. Mostly you do this but in a few cases it is
>> not consistent.
>
> ok. Will look at it.
>
>>
>> A few more notes below.
>>
>>>
>>> diff --git a/cmd/scsi.c b/cmd/scsi.c
>>> index 387ca1a262ab..dc1176610672 100644
>>> --- a/cmd/scsi.c
>>> +++ b/cmd/scsi.c
>>> @@ -10,6 +10,7 @@
>>>   */
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>
>>>  static int scsi_curr_dev; /* current device */
>>> @@ -25,6 +26,23 @@ int do_scsiboot(cmd_tbl_t *cmdtp, int flag, int argc, 
>>> char *const argv[])
>>>  /*
>>>   * scsi command intepreter
>>>   */
>>> +#ifdef CONFIG_DM_SATA
>>> +struct udevice *find_scsi_device(int dev_num)
>>> +{
>>> +   struct udevice *bdev;
>>> +   int ret;
>>> +
>>> +   ret = blk_get_device(IF_TYPE_SCSI, dev_num, );
>>> +
>>> +   if (ret) {
>>> +   printf("SCSI Device %d not found\n", dev_num);
>>> +   return NULL;
>>> +   }
>>> +
>>> +   return bdev;
>>> +}
>>> +#endif
>>> +
>>>  int do_scsi(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
>>>  {
>>> switch (argc) {
>>> @@ -35,7 +53,18 @@ int do_scsi(cmd_tbl_t *cmdtp, int flag, int argc, char 
>>> *const argv[])
>>> if (strncmp(argv[1], "res", 3) == 0) {
>>> printf("\nReset SCSI\n");
>>> scsi_bus_reset();
>>> +
>>> +#if defined(CONFIG_DM_SATA)
>>> +   struct udevice *bdev;
>>> +
>>> +   bdev = find_scsi_device(scsi_curr_dev);
>>> +   if (!bdev)
>>> +   return CMD_RET_FAILURE;
>>> +
>>> +   scsi_scan(1, bdev);
>>> +#else
>>> scsi_scan(1);
>>> +#endif
>>> return 0;
>>> }
>>> if (strncmp(argv[1], "inf", 3) == 

Re: [U-Boot] [PATCH v2 4/8] x86: Tidy up selection of building the EFI stub

2016-09-26 Thread Simon Glass
Hi Bin,

On 26 September 2016 at 02:50, Bin Meng  wrote:
> Hi Simon,
>
> On Mon, Sep 26, 2016 at 5:27 AM, Simon Glass  wrote:
>> At present we use a CONFIG option in efi.h to determine whether we are
>> building the EFI stub or not. This means that the same header cannot be
>> used for EFI_LOADER support. The CONFIG option will be enabled for the
>> whole build, even when not building the stub.
>>
>> Use a different define instead, set up just for the files that make up the
>> stub.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v2:
>> - Add new patch to tidy up selection of building the EFI stub
>>
>>  include/efi.h| 7 +--
>>  lib/efi/Makefile | 4 ++--
>>  2 files changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/efi.h b/include/efi.h
>> index d07187c..3d58780 100644
>> --- a/include/efi.h
>> +++ b/include/efi.h
>> @@ -30,8 +30,11 @@ struct efi_device_path;
>>
>>  #define EFI_BITS_PER_LONG  BITS_PER_LONG
>>
>> -/* With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64 */
>> -#ifdef CONFIG_EFI_STUB_64BIT
>> +/*
>> + * With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64. EFI_STUB is set
>> + * in lib/efi/Makefile, when building the stub.
>> + */
>> +#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
>
> I don't understand why this is needed?

If building the 64-bit EFI stub, we need to use 64-bit ints for the
stub, but 32-bits for the rest of U-Boot. So this header gets used
both ways.

>
>>  #undef EFI_BITS_PER_LONG
>>  #define EFI_BITS_PER_LONG  64
>>  #endif
>> diff --git a/lib/efi/Makefile b/lib/efi/Makefile
>> index e32dc14..9449600 100644
>> --- a/lib/efi/Makefile
>> +++ b/lib/efi/Makefile
>> @@ -9,9 +9,9 @@ obj-$(CONFIG_EFI_STUB) += efi_info.o
>>
>>  CFLAGS_REMOVE_efi_stub.o := -mregparm=3 \
>> $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
>> -CFLAGS_efi_stub.o := -fpic -fshort-wchar
>> +CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB
>>  CFLAGS_REMOVE_efi.o := -mregparm=3 \
>> $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
>> -CFLAGS_efi.o := -fpic -fshort-wchar
>> +CFLAGS_efi.o := -fpic -fshort-wchar -DEFI_STUB
>>
>>  extra-$(CONFIG_EFI_STUB) += efi_stub.o efi.o
>> --
>
> Regards,
> Bin

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 08/23] pci: Make PCI bridge memory alignment configurable

2016-09-26 Thread Simon Glass
Hi Paul,

On 26 September 2016 at 12:29, Paul Burton  wrote:
> On some systems aligning PCI memory to a 1MB boundary every time a
> bridge is encountered may lead to exhausting the available memory space
> before all devices have been assigned addresses.
>
> For example on the MIPS Boston development board we have an Intel EG20T
> Platform Controller Hub connected to a Xilinx AXI to PCIe root port
> which is only assigned a 1MB memory region. The Intel EG20T contains a
> bridge device beneath which all of its peripheral devices can be found,
> and that bridge device contains a ROM. If we align to 1MB when we
> encounter each bridge device we therefore do something like this:
>
>   - Start with bus_lower at 0x1600.
>
>   - Find the Xilinx root bridge, which has no visible BARs so we do very
> little to it.
>
>   - Probe the bus beneath the Xilinx bridge device, aligning bus_lower
> to a 1MB boundary first. That leaves it still at 0x1600.
>
>   - Find the EG20T bridge device, which we find has a 64KiB ROM. We
> assign it the address range 0x1600-0x1600 which leaves
> bus_lower at 0x1601.
>
>   - Probe the bus beneath the EG20T bridge device, aligning bus_lower to
> a 1MB boundary first. This leaves bus_lower at 0x1610, which is
> the end of the available memory space.
>
>   - Find the various peripheral devices the EG20T contains, but fail to
> assign any memory space to them since bus_lower is at the end of the
> memory space available to the PCI bus.
>
> This patch allows that 1MB alignment to be changed or disabled via
> Kconfig, so that systems such as this can select an alignment which
> works for them.
>
> Signed-off-by: Paul Burton 
>
> ---
>
>  drivers/pci/Kconfig|  7 +++
>  drivers/pci/pci_auto.c | 24 
>  2 files changed, 23 insertions(+), 8 deletions(-)

Reviewed-by: Simon Glass 

Please see below

>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 9a7c187..35bf8fe 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -18,6 +18,13 @@ config DM_PCI_COMPAT
>   measure when porting a board to use driver model for PCI. Once the
>   board is fully supported, this option should be disabled.
>
> +config DM_PCI_BRIDGE_MEM_ALIGN
> +   hex "PCI bridge memory alignment"
> +   default 0x10
> +   help
> + PCI memory space will be aligned to be a multiple of this value
> + whenever a PCI-to-PCI bridge is encountered.

Can you also add why this is useful, and why 1MB is a suitable default?

> +
>  config PCI_SANDBOX
> bool "Sandbox PCI support"
> depends on SANDBOX && DM_PCI
> diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
> index ee9a854..0326316 100644
> --- a/drivers/pci/pci_auto.c
> +++ b/drivers/pci/pci_auto.c
> @@ -186,8 +186,10 @@ void dm_pciauto_prescan_setup_bridge(struct udevice 
> *dev, int sub_bus)
> dm_pci_write_config8(dev, PCI_SUBORDINATE_BUS, 0xff);
>
> if (pci_mem) {
> -   /* Round memory allocator to 1MB boundary */
> -   pciauto_region_align(pci_mem, 0x10);
> +   /* Round memory allocator to a suitable boundary */
> +   if (CONFIG_DM_PCI_BRIDGE_MEM_ALIGN)

Can you update the pciauto_region_align() so you can omit this if () ?

> +   pciauto_region_align(pci_mem,
> +CONFIG_DM_PCI_BRIDGE_MEM_ALIGN);
>
> /*
>  * Set up memory and I/O filter limits, assume 32-bit
> @@ -200,8 +202,10 @@ void dm_pciauto_prescan_setup_bridge(struct udevice 
> *dev, int sub_bus)
> }
>
> if (pci_prefetch) {
> -   /* Round memory allocator to 1MB boundary */
> -   pciauto_region_align(pci_prefetch, 0x10);
> +   /* Round memory allocator to a suitable boundary */
> +   if (CONFIG_DM_PCI_BRIDGE_MEM_ALIGN)
> +   pciauto_region_align(pci_prefetch,
> +CONFIG_DM_PCI_BRIDGE_MEM_ALIGN);
>
> /*
>  * Set up memory and I/O filter limits, assume 32-bit
> @@ -260,8 +264,10 @@ void dm_pciauto_postscan_setup_bridge(struct udevice 
> *dev, int sub_bus)
> dm_pci_write_config8(dev, PCI_SUBORDINATE_BUS, sub_bus);
>
> if (pci_mem) {
> -   /* Round memory allocator to 1MB boundary */
> -   pciauto_region_align(pci_mem, 0x10);
> +   /* Round memory allocator to a suitable boundary */
> +   if (CONFIG_DM_PCI_BRIDGE_MEM_ALIGN)
> +   pciauto_region_align(pci_mem,
> +CONFIG_DM_PCI_BRIDGE_MEM_ALIGN);
>
> dm_pci_write_config16(dev, PCI_MEMORY_LIMIT,
>   (pci_mem->bus_lower - 1) >> 16);
> 

Re: [U-Boot] [PATCH 09/23] boston: Disable PCI bridge memory space alignment

2016-09-26 Thread Simon Glass
On 26 September 2016 at 12:29, Paul Burton  wrote:
> On the MIPS Boston development board we have an Intel EG20T Platform
> Controller Hub connected to a Xilinx AXI to PCIe root port which is only
> assigned a 1MB memory region. The Intel EG20T contains a bridge device
> beneath which all of its peripheral devices can be found, and that
> bridge device contains a ROM. If we align to 1MB when we encounter each
> bridge device we therefore do something like this:
>
>   - Start with bus_lower at 0x1600.
>
>   - Find the Xilinx root bridge, which has no visible BARs so we do very
> little to it.
>
>   - Probe the bus beneath the Xilinx bridge device, aligning bus_lower
> to a 1MB boundary first. That leaves it still at 0x1600.
>
>   - Find the EG20T bridge device, which we find has a 64KiB ROM. We
> assign it the address range 0x1600-0x1600 which leaves
> bus_lower at 0x1601.
>
>   - Probe the bus beneath the EG20T bridge device, aligning bus_lower to
> a 1MB boundary first. This leaves bus_lower at 0x1610, which is
> the end of the available memory space.
>
>   - Find the various peripheral devices the EG20T contains, but fail to
> assign any memory space to them since bus_lower is at the end of the
> memory space available to the PCI bus.
>
> Fix this by disabling that 1MB alignment, which allows all of the EG20T
> peripheral devices to be assigned memory space within the 1MB region
> available.
>
> Signed-off-by: Paul Burton 
>
> ---
>
>  configs/boston32r2_defconfig   | 1 +
>  configs/boston32r2el_defconfig | 1 +
>  configs/boston64r2_defconfig   | 1 +
>  configs/boston64r2el_defconfig | 1 +
>  4 files changed, 4 insertions(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 16/23] net: pch_gbe: Support PHY reset GPIOs

2016-09-26 Thread Simon Glass
Hi Paul,

On 26 September 2016 at 12:29, Paul Burton  wrote:
> Add support to the pch_gbe driver for resetting the PHY using a GPIO
> specified in the device tree. This matches the support already in Linux.
>
> Signed-off-by: Paul Burton 
>
> ---
>
>  drivers/net/pch_gbe.c | 29 +++--
>  drivers/net/pch_gbe.h |  1 +
>  2 files changed, 28 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

>
> diff --git a/drivers/net/pch_gbe.c b/drivers/net/pch_gbe.c
> index 8866f66..cc3ca8b 100644
> --- a/drivers/net/pch_gbe.c
> +++ b/drivers/net/pch_gbe.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "pch_gbe.h"
>
>  #if !defined(CONFIG_PHYLIB)
> @@ -72,6 +73,14 @@ static int pch_gbe_reset(struct udevice *dev)
> priv->rx_idx = 0;
> priv->tx_idx = 0;
>
> +   if (dm_gpio_is_valid(>gpio_phy_reset)) {
> +   /* Reset the PHY */
> +   dm_gpio_set_value(>gpio_phy_reset, 1);

I'm assuming you don't check the return value because this GPIO might
not be valid / used?

Regards.
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 14/23] gpio: Provide dummy get/request & is_valid functions

2016-09-26 Thread Simon Glass
Hi Paul,

On 26 September 2016 at 12:29, Paul Burton  wrote:
> Allow for drivers to make use of driver model GPIOs when they're enabled
> & available without needing to #ifdef on CONFIG_DM_GPIO by providing
> dummy functions covering GPIO requests. Each will simply return -ENODEV
> or -EINVAL, depending upon which the real implementation returns when a
> GPIO isn't found. Only the driver model versions of the GPIO request
> functions are covered & dm_gpio_request is excluded since it's
> documented as only being of use for debugging, so drivers shouldn't be
> calling it anyway.
>
> Also provide a dummy dm_gpio_is_valid, with the idea that all other GPIO
> functions called would be within an if (dm_gpio_is_valid(...)) statement
> and have been optimised out in cases where that returns a compile-time
> constant false.
>
> This parallels the clock API, keeping the #ifdefs & checks in a single
> location allowing drivers or other code to use GPIOs without needing to
> perform such checks themselves.
>
> Signed-off-by: Paul Burton 
>
> ---
>
>  include/asm-generic/gpio.h | 38 ++
>  1 file changed, 38 insertions(+)

Ick - why not just define DM_GPIO? I don't think we want to provide
special support for legacy things. It is just confusing.

- Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 07/23] pci: Handle MIPS systems with virtual CONFIG_SYS_SDRAM_BASE

2016-09-26 Thread Simon Glass
Hi Paul,

On 26 September 2016 at 12:29, Paul Burton  wrote:
> The decode_regions() function in the PCI code presumes that
> CONFIG_SYS_SDRAM_BASE is a physical address, which seems reasonable
> given that README states that it should be.
>
> However there is also common code which expects CONFIG_SYS_SDRAM_BASE to
> be an address accessible by the CPU, ie. a valid virtual address -
> notably gd->ram_top is set to it & various pieces of data are located
> relative to that, and getenv_bootm_low() defaults to
> CONFIG_SYS_SDRAM_BASE as the lower bound on addresses to load into. Thus
> on MIPS CONFIG_SYS_SDRAM_BASE is a virtual address.
>
> This patch takes the simple approach to fixing this & converts
> CONFIG_SYS_SDRAM_BASE to a physical address for use by the PCI code when
> built for MIPS.
>
> Signed-off-by: Paul Burton 
>
> ---
>
>  drivers/pci/pci-uclass.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index 415c632..26fe0f4 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -848,7 +848,9 @@ static int decode_regions(struct pci_controller *hose, 
> const void *blob,
>
> /* Add a region for our local memory */
> size = gd->ram_size;
> -#ifdef CONFIG_SYS_SDRAM_BASE
> +#if defined(CONFIG_MIPS)
> +   base = virt_to_phys((void *)CONFIG_SYS_SDRAM_BASE);
> +#elif defined(CONFIG_SYS_SDRAM_BASE)
> base = CONFIG_SYS_SDRAM_BASE;
>  #endif
> if (gd->pci_ram_top && gd->pci_ram_top < base + size)
> --
> 2.10.0
>

Can you find another way? We don't want arch- or board-specific
#ifdefs in uclasses or driver code.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 7/9] serial: bcm283x_mu: support disabling after initialization

2016-09-26 Thread Simon Glass
On 26 September 2016 at 06:26, Fabian Vogt  wrote:
> For the Raspberry Pi 3 it needs to be possible to disable the serial
> device after initialization happens, as only after the GPIO device is 
> available
> it is known whether the mini uart is usable.
>
> Signed-off-by: Fabian Vogt 
> ---
>  drivers/serial/serial_bcm283x_mu.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 8/9] board: rpi: move uart deactivation to board_init

2016-09-26 Thread Simon Glass
On 26 September 2016 at 06:26, Fabian Vogt  wrote:
> When using OF_CONTROL, the disabled value of the mini UART platdata
> gets reset after board_early_init_f. So move detection and disabling
> to board_init and remove board_early_init_f.
> This uses the first device using the mini uart driver, as this method
> works reliably with different device trees or even no device tree at all.
>
> Signed-off-by: Fabian Vogt 
> ---
>  board/raspberrypi/rpi/rpi.c | 40 ++--
>  include/configs/rpi.h   |  1 -
>  2 files changed, 26 insertions(+), 15 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 6/9] fdt: adjust bcm283x device tree for u-boot

2016-09-26 Thread Simon Glass
On 26 September 2016 at 06:26, Fabian Vogt  wrote:
> The information currently set via platdata has to be represented in the
> device tree now. bcm283x-uboot.dtsi adds the u-boot specific "skip-init"
> property to the serial nodes and enables initialization in the pre-reloc 
> phase.
>
> Cc: Albert Aribaud 
> Signed-off-by: Fabian Vogt 
> ---
>  arch/arm/dts/bcm283x-uboot.dtsi | 22 ++
>  arch/arm/dts/bcm283x.dtsi   |  4 +++-
>  2 files changed, 25 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/bcm283x-uboot.dtsi

Reviewed-by: Simon Glass 

I'd be intrigued to see if Linux would accept a version of this patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 9/9] ARM: bcm283x: use OF_CONTROL for bcm283x

2016-09-26 Thread Simon Glass
On 26 September 2016 at 06:26, Fabian Vogt  wrote:
> This patch removes use of U_BOOT_DEVICE in board/raspberrypi/rpi/rpi.c,
> enables OF_CONTROL in the config and adjusts the rpi_*defconfig configs.
>
> Signed-off-by: Fabian Vogt 
> ---
>  arch/arm/Kconfig|  1 +
>  board/raspberrypi/rpi/rpi.c | 37 -
>  configs/rpi_2_defconfig |  2 ++
>  configs/rpi_3_32b_defconfig |  2 ++
>  configs/rpi_3_defconfig |  2 ++
>  configs/rpi_defconfig   |  2 ++
>  6 files changed, 9 insertions(+), 37 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 5/9] fdt: import bcm283x device tree sources from the linux kernel tree

2016-09-26 Thread Simon Glass
On 26 September 2016 at 06:26, Fabian Vogt  wrote:
> This patch adds device trees for the bcm283x platform to be used with
> OF_CONTROL. The version 4.8-rc7 of the linux kernel was used as source.
>
> Cc: Albert Aribaud 
> Signed-off-by: Fabian Vogt 
> ---
>  arch/arm/dts/Makefile  |   9 +
>  arch/arm/dts/bcm2835-rpi-a-plus.dts|  35 
>  arch/arm/dts/bcm2835-rpi-a.dts |  28 +++
>  arch/arm/dts/bcm2835-rpi-b-plus.dts|  36 
>  arch/arm/dts/bcm2835-rpi-b-rev2.dts|  29 +++
>  arch/arm/dts/bcm2835-rpi-b.dts |  23 +++
>  arch/arm/dts/bcm2835-rpi.dtsi  |  86 +
>  arch/arm/dts/bcm2835.dtsi  |  25 +++
>  arch/arm/dts/bcm2836-rpi-2-b.dts   |  40 
>  arch/arm/dts/bcm2836.dtsi  |  78 
>  arch/arm/dts/bcm2837-rpi-3-b.dts   |  30 +++
>  arch/arm/dts/bcm2837.dtsi  |  76 
>  arch/arm/dts/bcm283x-rpi-smsc9512.dtsi |  19 ++
>  arch/arm/dts/bcm283x-rpi-smsc9514.dtsi |  19 ++
>  arch/arm/dts/bcm283x.dtsi  | 321 
> +
>  15 files changed, 854 insertions(+)
>  create mode 100644 arch/arm/dts/bcm2835-rpi-a-plus.dts
>  create mode 100644 arch/arm/dts/bcm2835-rpi-a.dts
>  create mode 100644 arch/arm/dts/bcm2835-rpi-b-plus.dts
>  create mode 100644 arch/arm/dts/bcm2835-rpi-b-rev2.dts
>  create mode 100644 arch/arm/dts/bcm2835-rpi-b.dts
>  create mode 100644 arch/arm/dts/bcm2835-rpi.dtsi
>  create mode 100644 arch/arm/dts/bcm2835.dtsi
>  create mode 100644 arch/arm/dts/bcm2836-rpi-2-b.dts
>  create mode 100644 arch/arm/dts/bcm2836.dtsi
>  create mode 100644 arch/arm/dts/bcm2837-rpi-3-b.dts
>  create mode 100644 arch/arm/dts/bcm2837.dtsi
>  create mode 100644 arch/arm/dts/bcm283x-rpi-smsc9512.dtsi
>  create mode 100644 arch/arm/dts/bcm283x-rpi-smsc9514.dtsi
>  create mode 100644 arch/arm/dts/bcm283x.dtsi

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/9] serial: pl01x: expose skip_init platdata option in DT

2016-09-26 Thread Simon Glass
On 26 September 2016 at 06:26, Fabian Vogt  wrote:
> To be able to represent the skip-init platdata element with OF_CONTROL,
> it needs to be read from the device tree as well and put into the platform 
> data.
>
> Cc: Eric Anholt 
> Signed-off-by: Fabian Vogt 
> ---
>  doc/device-tree-bindings/serial/pl01x.txt | 3 +++
>  drivers/serial/serial_pl01x.c | 2 ++
>  2 files changed, 5 insertions(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/9] fdt: add dt-bindings for bcm2835

2016-09-26 Thread Simon Glass
On 26 September 2016 at 06:26, Fabian Vogt  wrote:
> This patch adds dt-bindings as used by the linux kernel device trees
> for the bcm283x family.
>
> Albert Aribaud 
> Signed-off-by: Fabian Vogt 
> ---
>  include/dt-bindings/clock/bcm2835-aux.h   | 17 +++
>  include/dt-bindings/clock/bcm2835.h   | 66 
> +++
>  include/dt-bindings/pinctrl/bcm2835.h | 27 +++
>  include/dt-bindings/power/raspberrypi-power.h | 41 +
>  4 files changed, 151 insertions(+)
>  create mode 100644 include/dt-bindings/clock/bcm2835-aux.h
>  create mode 100644 include/dt-bindings/clock/bcm2835.h
>  create mode 100644 include/dt-bindings/pinctrl/bcm2835.h
>  create mode 100644 include/dt-bindings/power/raspberrypi-power.h

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/3] Revert "ns16650: Make sure we have CONFIG_CLK set before using infrastructure"

2016-09-26 Thread Simon Glass
On 26 September 2016 at 05:45, Masahiro Yamada
 wrote:
> This reverts commit 82f5279b0cd99a9163d34cfe926d0316d9dc0d37.
>
> The build failure of k2*evm boards was fixed in a different way by
> the previous commit.  It is nasty to patch generic drivers around
> with #ifdef CONFIG_CLK just for the KeyStone's matter.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/serial/ns16550.c |  7 ++-
>  include/clk.h| 25 +
>  2 files changed, 15 insertions(+), 17 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/9] serial: bcm283x_mu: add device tree support

2016-09-26 Thread Simon Glass
On 26 September 2016 at 06:26, Fabian Vogt  wrote:
> This patch adds device tree support for the bcm283x mini-uart driver.
>
> Signed-off-by: Fabian Vogt 
> ---
>  .../serial/bcm2835-aux-uart.txt| 10 
>  drivers/serial/serial_bcm283x_mu.c | 28 
> ++
>  2 files changed, 38 insertions(+)
>  create mode 100644 doc/device-tree-bindings/serial/bcm2835-aux-uart.txt

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 1/8] x86: Add implementations of setjmp() and longjmp()

2016-09-26 Thread Simon Glass
Hi Alex,

On 26 September 2016 at 01:28, Alexander Graf  wrote:
>
>
> On 26.09.16 09:21, Bin Meng wrote:
>> Hi Alex,
>>
>> On Mon, Sep 26, 2016 at 3:05 PM, Alexander Graf  wrote:
>>>
>>>
>>> On 26.09.16 09:00, Bin Meng wrote:
 Hi Simon,

 On Mon, Sep 26, 2016 at 5:27 AM, Simon Glass  wrote:
> Bring in these functions from Linux v4.4. They will be needed for EFI 
> loader
> support.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Drop irrelevant comment
> - Add a comment about .size
> - Drop unnecessary .text directive
> - Make longjmp() always cause setjmp() to return 1
>
>  arch/x86/cpu/Makefile |  2 +-
>  arch/x86/cpu/setjmp.S | 66 
> +++
>  arch/x86/include/asm/setjmp.h | 24 
>  3 files changed, 91 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/cpu/setjmp.S
>  create mode 100644 arch/x86/include/asm/setjmp.h
>
> diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile
> index 2667e0b..f5b8c9e 100644
> --- a/arch/x86/cpu/Makefile
> +++ b/arch/x86/cpu/Makefile
> @@ -10,7 +10,7 @@
>
>  extra-y= start.o
>  obj-$(CONFIG_X86_RESET_VECTOR) += resetvec.o start16.o
> -obj-y  += interrupts.o cpu.o cpu_x86.o call64.o
> +obj-y  += interrupts.o cpu.o cpu_x86.o call64.o setjmp.o
>
>  AFLAGS_REMOVE_call32.o := -mregparm=3 \
> $(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
> diff --git a/arch/x86/cpu/setjmp.S b/arch/x86/cpu/setjmp.S
> new file mode 100644
> index 000..7443274
> --- /dev/null
> +++ b/arch/x86/cpu/setjmp.S
> @@ -0,0 +1,66 @@
> +/*
> + * Written by H. Peter Anvin 
> + * Brought in from Linux v4.4 and modified for U-Boot
> + * From Linux arch/um/sys-i386/setjmp.S
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +
> +#include 
> +#include 
> +#include 
> +

 I believe the above 3 includes are not needed.

> +#define _REGPARM
> +
> +/*
> + * The jmp_buf is assumed to contain the following, in order:
> + * %ebx
> + * %esp
> + * %ebp
> + * %esi
> + * %edi
> + * 
> + */
> +
> +   .text
> +   .align 4
> +   .globl setjmp
> +   .type setjmp, @function
> +setjmp:
> +#ifdef _REGPARM
> +   movl %eax, %edx
> +#else
> +   movl 4(%esp), %edx
> +#endif
> +   popl %ecx   /* Return address, and adjust the stack */
> +   xorl %eax, %eax /* Return value */
> +   movl %ebx, (%edx)
> +   movl %esp, 4(%edx)  /* Post-return %esp! */
> +   pushl %ecx  /* Make the call/return stack happy */
> +   movl %ebp, 8(%edx)
> +   movl %esi, 12(%edx)
> +   movl %edi, 16(%edx)
> +   movl %ecx, 20(%edx) /* Return address */
> +   ret
> +
> +   /* Provide function size if needed */
> +   .size setjmp, .-setjmp
> +
> +   .align 4
> +   .globl longjmp
> +   .type longjmp, @function
> +longjmp:
> +#ifdef _REGPARM
> +   xchgl %eax, %edx
> +#else
> +   movl 4(%esp), %edx  /* jmp_ptr address */
> +#endif
> +   movl 1, %eax

 This should be $1.

 But I still think the setjmp/longjump codes in efi_loader is wrong. We
 should have longjump() to pass the return value to setjmp().
>>>
>>> Why? Where's the difference?
>>>
>>
>> longjump() does not have the setjmp() return value as the parameter,
>> which concerns me as it does not conform to the standard longjump()
>> implementation. This v2 hardcoded the return value to 1, which makes
>> the following logic work in efi_loader.
>>
>> if (setjmp(>exit_jmp)) {
>> /* We returned from the child image */
>> return EFI_EXIT(info->exit_status);
>> }
>>
>> If we want such a simplified implementation in efi_loader, we should
>> probably rename these functions to efi_setjmp() and efi_longjump().
>
> Ah, I see. The second parameter to longjmp() should be the the return
> value after the jump - which the code above actually implements. And
> then it clobbers it with a 1.
>
> I guess that's my fault, because I skipped the second argument bit in my
> longjmp header definition. Please just add it to the longjmp prototype
> and explicitly pass "1" as return value in (don't forget to adapt the
> prototypes in arch/arm/include/asm/setjmp.h). I can fix up the arm code
> later to actually pass the argument.

Would you mind doing the fix-up patch? I don't think we should change
the prototype separate from the ARM code.

Regards,
Simon
___
U-Boot mailing list

Re: [U-Boot] [PATCH 2/3] ARM: keystone: rename clk_get_rate() to ks_clk_get_rate()

2016-09-26 Thread Simon Glass
On 26 September 2016 at 05:45, Masahiro Yamada
 wrote:
> The KeyStone platform has its own clk_get_rate() but its prototype
> is different from that of the common-clk (clk-uclass) framework.
>
> Prefix the KeyStone specific implementation with _ks in order to
> avoid name-space conflict.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/arm/include/asm/ti-common/keystone_net.h |  4 ++--
>  arch/arm/mach-keystone/clock.c| 24 
>  arch/arm/mach-keystone/cmd_clock.c|  2 +-
>  arch/arm/mach-keystone/include/mach/clock.h   |  2 +-
>  include/configs/ti_armv7_keystone2.h  |  8 
>  5 files changed, 20 insertions(+), 20 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 5/5] check-config: allow to complete build even with ad-hoc CONFIG options

2016-09-26 Thread Simon Glass
Hi Masahiro,

On 25 September 2016 at 22:05, Masahiro Yamada
 wrote:
> Currently, the check-config.sh terminates the build when unknown
> ad-hoc options are detected.  I think it is too much because we may
> want to patch config headers locally in a build/deployment project.
>
> So, let's relax check-config.sh to just warn even if it detects
> options that are not in the whitelist.  Instead, this check can be
> done at the end of build, along with other checks.  It will catch
> more attention.
>
> Even with this change, the Buildman tool catches new warnings,
> so Tom can give NACK to new ad-hoc options.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  scripts/check-config.sh | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

I am not sure this is a good idea. We need buildman to fail the build;
otherwise patches will make it to mainline with new CONFIGs. Perhaps
we should have an ENV variable to skip the check?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] power: pmic: lp873x: Add the base pmic support

2016-09-26 Thread Simon Glass
Hi,

On 26 September 2016 at 00:00, Keerthy  wrote:
> Add support to bind the regulators/child nodes with the pmic.
>
> Signed-off-by: Keerthy 
> ---
>  drivers/power/pmic/Kconfig  |  7 ++
>  drivers/power/pmic/Makefile |  1 +
>  drivers/power/pmic/lp873x.c | 59 
> +
>  include/power/lp873x.h  | 19 +++
>  4 files changed, 86 insertions(+)
>  create mode 100644 drivers/power/pmic/lp873x.c
>  create mode 100644 include/power/lp873x.h
>
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index 92931c5..00fcacb 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -142,3 +142,10 @@ config PMIC_PALMAS
> ---help---
> The PALMAS is a PMIC containing several LDOs, SMPS.
> This driver binds the pmic children.
> +
> +config PMIC_LP873X
> +   bool "Enable driver for Texas Instruments LP873X PMIC"
> +   depends on DM_PMIC
> +   ---help---
> +   The LP873X is a PMIC containing couple of LDOs and couple of SMPS.
> +   This driver binds the pmic children.
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 828c0cf..334a24f 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -16,6 +16,7 @@ obj-$(CONFIG_PMIC_RK808) += rk808.o
>  obj-$(CONFIG_PMIC_TPS65090) += tps65090.o
>  obj-$(CONFIG_PMIC_S5M8767) += s5m8767.o
>  obj-$(CONFIG_$(SPL_)PMIC_PALMAS) += palmas.o
> +obj-$(CONFIG_$(SPL_)PMIC_LP873X) += lp873x.o
>
>  obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
>  obj-$(CONFIG_POWER_MAX77696) += pmic_max77696.o
> diff --git a/drivers/power/pmic/lp873x.c b/drivers/power/pmic/lp873x.c
> new file mode 100644
> index 000..ace798c
> --- /dev/null
> +++ b/drivers/power/pmic/lp873x.c
> @@ -0,0 +1,59 @@
> +/*
> + * (C) Copyright 2016 Texas Instruments Incorporated, 
> + * Keerthy 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static const struct pmic_child_info pmic_children_info[] = {
> +   { .prefix = "ldo", .driver = LP873X_LDO_DRIVER },
> +   { .prefix = "buck", .driver = LP873X_BUCK_DRIVER },
> +   { },
> +};
> +
> +static int lp873x_bind(struct udevice *dev)
> +{
> +   int regulators_node;
> +   const void *blob = gd->fdt_blob;
> +   int children;
> +   int node = dev->of_offset;
> +
> +   regulators_node = fdt_subnode_offset(blob, node, "regulators");
> +
> +   if (regulators_node <= 0) {
> +   printf("%s: %s reg subnode not found!", __func__, dev->name);

These should be debug() I think. We should not be printing things in
drivers. Also it bloats the code for an error condition that should
never happen.

> +   return -ENXIO;
> +   }
> +
> +   children = pmic_bind_children(dev, regulators_node, 
> pmic_children_info);
> +   if (!children)
> +   printf("%s: %s - no child found\n", __func__, dev->name);
> +
> +   /* Always return success for this device */
> +   return 0;
> +}
> +
> +static const struct udevice_id lp873x_ids[] = {
> +   { .compatible = "ti,lp8732", .data = LP8732 },
> +   { .compatible = "ti,lp8733" , .data = LP8733 },
> +   { }
> +};
> +
> +U_BOOT_DRIVER(pmic_lp873x) = {
> +   .name = "lp873x_pmic",
> +   .id = UCLASS_PMIC,
> +   .of_match = lp873x_ids,
> +   .bind = lp873x_bind,
> +};
> diff --git a/include/power/lp873x.h b/include/power/lp873x.h
> new file mode 100644
> index 000..e0c0711
> --- /dev/null
> +++ b/include/power/lp873x.h
> @@ -0,0 +1,19 @@
> +#defineLP8732  0x0
> +#define LP8733 0x1
> +
> +#define LP873X_LDO_NUM 2
> +#define LP873X_BUCK_NUM2
> +
> +/* Drivers name */
> +#define LP873X_LDO_DRIVER  "lp873x_ldo"
> +#define LP873X_BUCK_DRIVER "lp873x_buck"
> +
> +#define LP873X_BUCK_VOLT_MASK  0xFF
> +#define LP873X_BUCK_VOLT_MAX_HEX   0xFF
> +#define LP873X_BUCK_VOLT_MAX   336
> +#define LP873X_BUCK_MODE_MASK  0x1
> +
> +#define LP873X_LDO_VOLT_MASK0x1F
> +#define LP873X_LDO_VOLT_MAX_HEX 0x19
> +#define LP873X_LDO_VOLT_MAX 330
> +#define LP873X_LDO_MODE_MASK   0x1
> --
> 1.9.1
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] power: regulator: lp873x: Add regulator support

2016-09-26 Thread Simon Glass
Hi,

On 26 September 2016 at 00:00, Keerthy  wrote:
> The driver provides regulator set/get voltage
> enable/disable functions for lp873x family of PMICs.
>
> Signed-off-by: Keerthy 
> ---
>  drivers/power/regulator/Kconfig|   8 +
>  drivers/power/regulator/Makefile   |   1 +
>  drivers/power/regulator/lp873x_regulator.c | 361 
> +
>  3 files changed, 370 insertions(+)
>  create mode 100644 drivers/power/regulator/lp873x_regulator.c
>
> diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
> index adb710a..84cf914 100644
> --- a/drivers/power/regulator/Kconfig
> +++ b/drivers/power/regulator/Kconfig
> @@ -123,3 +123,11 @@ config DM_REGULATOR_PALMAS
> This enables implementation of driver-model regulator uclass
> features for REGULATOR PALMAS and the family of PALMAS PMICs.
> The driver implements get/set api for: value and enable.
> +
> +config DM_REGULATOR_LP873X
> +   bool "Enable driver for LP873X PMIC regulators"
> +depends on PMIC_LP873X
> +   ---help---
> +   This enables implementation of driver-model regulator uclass
> +   features for REGULATOR LP873X and the family of LP873X PMICs.
> +   The driver implements get/set api for: value and enable.
> diff --git a/drivers/power/regulator/Makefile 
> b/drivers/power/regulator/Makefile
> index 75080d4..2093048 100644
> --- a/drivers/power/regulator/Makefile
> +++ b/drivers/power/regulator/Makefile
> @@ -15,3 +15,4 @@ obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
>  obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
>  obj-$(CONFIG_REGULATOR_TPS65090) += tps65090_regulator.o
>  obj-$(CONFIG_$(SPL_)DM_REGULATOR_PALMAS) += palmas_regulator.o
> +obj-$(CONFIG_$(SPL_)DM_REGULATOR_LP873X) += lp873x_regulator.o
> diff --git a/drivers/power/regulator/lp873x_regulator.c 
> b/drivers/power/regulator/lp873x_regulator.c
> new file mode 100644
> index 000..7675173
> --- /dev/null
> +++ b/drivers/power/regulator/lp873x_regulator.c
> @@ -0,0 +1,361 @@
> +/*
> + * (C) Copyright 2016
> + * Texas Instruments Incorporated, 
> + *
> + * Keerthy 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +static const char lp873x_buck_ctrl[LP873X_BUCK_NUM] = {0x2, 0x4};
> +static const char lp873x_buck_volt[LP873X_BUCK_NUM] = {0x6, 0x7};
> +static const char lp873x_ldo_ctrl[LP873X_LDO_NUM] = {0x8, 0x9};
> +static const char lp873x_ldo_volt[LP873X_LDO_NUM] = {0xA, 0xB};
> +
> +static int lp873x_buck_enable(struct udevice *dev, int op, bool *enable)
> +{
> +   int ret;
> +   uint8_t val;
> +   unsigned int adr;
> +   struct dm_regulator_uclass_platdata *uc_pdata;
> +
> +   uc_pdata = dev_get_uclass_platdata(dev);
> +   adr = uc_pdata->ctrl_reg;
> +
> +   ret = dm_i2c_u8_read(dev->parent, adr, );
> +   if (ret < 0)
> +   return ret;

You can use

val = dm_i2c_reg_reg(dev->parent, adr);
if (val < 0)
   return val;

What is the benefit of using extra u8 variable?

But in this case, you should use pmic_reg_read(). We should avoid i2c
access in drivers. There is no need for it, and the PMIC may come in a
SPI version one day.

> +
> +   if (op == PMIC_OP_GET) {
> +   val &= LP873X_BUCK_MODE_MASK;
> +
> +   if (val)
> +   *enable = true;
> +   else
> +   *enable = false;
> +
> +   return 0;
> +   } else if (op == PMIC_OP_SET) {
> +   if (*enable)
> +   val |= LP873X_BUCK_MODE_MASK;
> +   else
> +   val &= ~(LP873X_BUCK_MODE_MASK);
> +   ret = dm_i2c_u8_write(dev->parent, adr, );
> +   if (ret)
> +   return ret;
> +   }
> +
> +   return 0;
> +}

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/5] kbuild: move no_new_adhoc_configs_check to "all" target command

2016-09-26 Thread Simon Glass
On 25 September 2016 at 22:04, Masahiro Yamada
 wrote:
> I am going to move the build rule of u-boot.cfg.  Before that,
> no_new_adhoc_configs_check must be tweaked to not depend on it.
>
> The ad-hoc option check can be done at the end of build, along
> with other checks.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  Makefile | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/5] kbuild: generate u-boot.cfg as a byproduct of include/autoconf.mk

2016-09-26 Thread Simon Glass
On 25 September 2016 at 22:05, Masahiro Yamada
 wrote:
> Our build system still parses ad-hoc CONFIG options in header files
> and generates include/autoconf.mk so that Makefiles can reference
> them.  This gimmick was introduced in the pre-Kconfig days and will
> be kept until Kconfig migration is completed.
>
> The include/autoconf.mk is generated like follows:
>
>   [1] Preprocess include/common.h with -DDO_DEPS_ONLY and
>   retrieve macros into include/autoconf.mk.tmp
>   [2] Reformat include/autoconf.mk.dep into include/autoconf.mk
>   with tools/scripts/define2mk.sed script
>   [3] Remove include/autoconf.mk.tmp
>
> Here, include/autoconf.mk.tmp is similar to u-boot.cfg, which is
> also generated by preprocessing include/config.h with -DDO_DEPS_ONLY.
> In other words, there is much overlap among include/autoconf.mk and
> u-boot.cfg build rules.
>
> So, the idea is to split the build rule of include/autoconf.mk
> into two stages.  The first preprocesses headers into u-boot.cfg.
> The second parses the u-boot.cfg into include/autoconf.mk.  The
> build rules of u-boot.cfg in Makefile and spl/Makefile will be gone.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  Makefile  | 17 +
>  scripts/Makefile.autoconf | 37 ++---
>  scripts/Makefile.spl  | 20 +---
>  3 files changed, 28 insertions(+), 46 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/5] check-config: fix wrong comment about how to build whitelist

2016-09-26 Thread Simon Glass
Hi Masahiro,

On 25 September 2016 at 22:04, Masahiro Yamada
 wrote:
> The command suggested in this comment block is wrong; it would not
> rip off CONFIG options that had already been converted to Kconfig.
>
> Instead, we should use the scripts/build-whitelist.sh tool.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  scripts/check-config.sh | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/check-config.sh b/scripts/check-config.sh
> index 28c8fe9..6618dfb 100755
> --- a/scripts/check-config.sh
> +++ b/scripts/check-config.sh
> @@ -5,13 +5,8 @@
>  # Check that the u-boot.cfg file provided does not introduce any new
>  # ad-hoc CONFIG options
>  #
> -# You can generate the list of current ad-hoc CONFIG options (those which are
> -# not in Kconfig) with this command:
> -#
> -# export LC_ALL=C LC_COLLATE=C
> -# git grep CONFIG_ |tr ' \t' '\n\n' |sed -n 
> 's/^\(CONFIG_[A-Z0-9_]*\).*/\1/p' \
> -#  |sort |uniq >scripts/config_whitelist.txt;
> -# unset LC_ALL LC_COLLATE
> +# Use scripts/build-whitelist.sh to generate the list of current ad-hoc
> +# CONFIG options (those which are not in Kconfig).

For me the LC setup is needed. Does it work correctly without it for
you? I found that the sorting was wrong.

>
>  # Usage
>  #check-config.shdir>
> --
> 1.9.1
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/5] kbuild: make dependencies in scripts/Makefile.autoconf more readable

2016-09-26 Thread Simon Glass
On 25 September 2016 at 22:05, Masahiro Yamada
 wrote:
> I do not remember why I wrote the code like this, but let's make it
> a bit more readable.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  scripts/Makefile.autoconf | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] ARM: tegra: flush caches via SMC call

2016-09-26 Thread Simon Glass
On 23 September 2016 at 17:43, Stephen Warren  wrote:
> From: Stephen Warren 
>
> On Tegra186, it is necessary to perform an SMC to fully flush all caches;
> flushing/cleaning by set/way is not enough. Implement the required hook
> to make this happen.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/tegra186/Makefile |  1 +
>  arch/arm/mach-tegra/tegra186/cache.c  | 23 +++
>  2 files changed, 24 insertions(+)
>  create mode 100644 arch/arm/mach-tegra/tegra186/cache.c

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 9/9] common/board_f: enable initr_trap for MIPS

2016-09-26 Thread Simon Glass
On 25 September 2016 at 12:05, Daniel Schwierzeck
 wrote:
> Enable initr_trap hook also for MIPS to install and enable
> U-Boot's specific MIPS exception handlers.
>
> Signed-off-by: Daniel Schwierzeck 
>
> ---
>
>  common/board_r.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] mmc: dw_mmc: remove the unnecessary arguments for dwmci_setup_cfg

2016-09-26 Thread Simon Glass
On 23 September 2016 at 04:13, Jaehoon Chung  wrote:
> Some arguments don't need to pass to dwmci_setup_cfg.
> They are already included in dwmci_host structure.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/mmc/dw_mmc.c  | 13 ++---
>  drivers/mmc/exynos_dw_mmc.c   |  3 +--
>  drivers/mmc/rockchip_dw_mmc.c |  3 +--
>  drivers/mmc/socfpga_dw_mmc.c  |  3 +--
>  include/dwmmc.h   |  8 +++-
>  5 files changed, 12 insertions(+), 18 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCHv2] scripts: Add script to extract default environment

2016-09-26 Thread Simon Glass
Hi Lukasz,

On 16 September 2016 at 22:57, Lukasz Majewski  wrote:
> This script looks for env_common.o object file and extracts from it default
> u-boot environment, which is afterwards printed on standard output.
>
> Usage example:
> get_default_envs.sh > u-boot-env-default.txt
>
> The generated text file can be used as input for mkenvimage.
>
> Signed-off-by: Lukasz Majewski 
>
> ---
> Changes for v2:
> - Sort uniquely entries
> - Exclude env_common.o generated for SPL
> ---
>  scripts/get_default_envs.sh | 34 ++
>  1 file changed, 34 insertions(+)
>  create mode 100755 scripts/get_default_envs.sh

Reviewed-by: Simon Glass 

But why is this needed?

>
> diff --git a/scripts/get_default_envs.sh b/scripts/get_default_envs.sh
> new file mode 100755
> index 000..7955db6
> --- /dev/null
> +++ b/scripts/get_default_envs.sh
> @@ -0,0 +1,34 @@
> +#! /bin/bash
> +#
> +# Copyright (C) 2016, Lukasz Majewski 
> +#
> +# SPDX-License-Identifier:  GPL-2.0+
> +#
> +
> +# This file extracts default envs from built u-boot
> +# usage: get_default_envs.sh > u-boot-env-default.txt
> +set -ue
> +
> +ENV_OBJ_FILE="env_common.o"
> +ENV_OBJ_FILE_COPY="copy_${ENV_OBJ_FILE}"
> +
> +echoerr() { echo "$@" 1>&2; }
> +
> +path=$(readlink -f $0)
> +env_obj_file_path=$(find ${path%/scripts*} -not -path "*/spl/*" \
> +-name "${ENV_OBJ_FILE}")
> +[ -z "${env_obj_file_path}" ] && \
> +{ echoerr "File '${ENV_OBJ_FILE}' not found!"; exit 1; }
> +
> +cp ${env_obj_file_path} ${ENV_OBJ_FILE_COPY}
> +
> +# NOTE: objcopy saves its output to file passed in
> +# (copy_env_common.o in this case)
> +objcopy -O binary -j ".rodata.default_environment" ${ENV_OBJ_FILE_COPY}
> +
> +# Replace default '\0' with '\n' and sort entries
> +tr '\0' '\n' < ${ENV_OBJ_FILE_COPY} | sort -u
> +
> +rm ${ENV_OBJ_FILE_COPY}
> +
> +exit 0

This isn't needed.

> --
> 2.1.4
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] ARM: tegra: fix clock_get_periph_rate() for UART clocks

2016-09-26 Thread Simon Glass
On 23 September 2016 at 16:44, Stephen Warren  wrote:
> From: Stephen Warren 
>
> Make clock_get_periph_rate() return the correct value for UART clocks.
>
> This change needs to be applied before the patches that enable CONFIG_CLK
> for Tegra SoCs before Tegra186, since enabling that option causes
> ns16550_serial_ofdata_to_platdata() to rely on clk_get_rate() for UART
> clocks, and clk_get_rate() eventually calls clock_get_periph_rate().
>
> This change is a rather horrible hack, as explained in the comment added
> to the clock driver. I've tried fixing this correctly for all clocks as
> described in that comment, but there's too much fallout elsewhere. I
> believe the clock driver has a number of bugs which all cancel each-other
> out, and unravelling that chain is too complex at present. This change is
> the smallest change that fixes clock_get_periph_rate() for UART clocks
> while guaranteeing no change in behaviour for any other clock, which
> avoids other regressions.
>
> Signed-off-by: Stephen Warren 
> ---
>  arch/arm/mach-tegra/clock.c | 38 --
>  1 file changed, 36 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/2] mmc: sdhci: use the generic error number

2016-09-26 Thread Simon Glass
On 25 September 2016 at 17:10, Jaehoon Chung  wrote:
> Use the generic error number instead of meaningless value.
>
> Signed-off-by: Jaehoon Chung 
> ---
> Changelog for V2:
> - Fix the missed error number
> - Add the other controller (bcm2835_sdhci, ftsdc021_sdhc)
>
>  drivers/mmc/bcm2835_sdhci.c  |  2 +-
>  drivers/mmc/ftsdc021_sdhci.c |  2 +-
>  drivers/mmc/kona_sdhci.c |  6 +++---
>  drivers/mmc/mv_sdhci.c   |  2 +-
>  drivers/mmc/s5p_sdhci.c  |  8 
>  drivers/mmc/sdhci.c  | 12 ++--
>  6 files changed, 16 insertions(+), 16 deletions(-)
>

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] mmc: sdhci: use the host version value in sdhci_setup_cfg

2016-09-26 Thread Simon Glass
On 23 September 2016 at 04:14, Jaehoon Chung  wrote:
> "host->version" isn't a SoC specific value.
> It doesn't need to get in each SoC drivers.
>
> Signed-off-by: Jaehoon Chung 
> ---
>  drivers/mmc/atmel_sdhci.c   | 1 -
>  drivers/mmc/bcm2835_sdhci.c | 1 -
>  drivers/mmc/kona_sdhci.c| 5 -
>  drivers/mmc/msm_sdhci.c | 3 ---
>  drivers/mmc/mv_sdhci.c  | 4 
>  drivers/mmc/s5p_sdhci.c | 1 -
>  drivers/mmc/sdhci.c | 6 +-
>  drivers/mmc/spear_sdhci.c   | 5 -
>  drivers/mmc/zynq_sdhci.c| 2 --
>  9 files changed, 5 insertions(+), 23 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v1] common/console.c: ensure GD_FLG_SILENT is set or cleared

2016-09-26 Thread Simon Glass
Hi Chris,

On 22 September 2016 at 21:59, Chris Packham  wrote:
> When CONFIG_SILENT_CONSOLE is defined and the default environment has
> silent=1 it is not possible for a user to make the console un-silent if
> the environment is not available when console_init_f() is called (for
> example because the environment is in SPI).
>
> Add a new helper function console_update_silent() and call it from both
> console_init_f() and console_init_r().
>
> Signed-off-by: Chris Packham 
> ---
>
>  common/console.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass 

I'm not completely sure that this is the intended behaviour, but it
seems reasonable. I'd really like to see docs in the README (or
elsewhere) about the effect of the 'silent' env variable...

- Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] building u-boot x86 with device tree disabled , still refers to device tree function

2016-09-26 Thread Simon Glass
Hi,

On 17 August 2016 at 06:59, Ding, ChiX  wrote:
> Hi Simon
> We have an older version u-boot code that is built without device tree.
> It works fine as coreboot payload on the target board with Denverton chipset.
> With the current u-boot code from git://git.denx.de/u-boot.git, I run 
> coreboot-x86_defconfig,
> then make menuconfig, and by default qemu-x86 is the target board. I use 
> device tree in the
> beginning which is enalbed by default, but I didn't see the dts file for my 
> target board.
> Since I'm new to the bootloader world, I 'm not sure how to define it 
> correctly for my target board.
> I did experiments of the dst file and menuconfig to use it, but the built 
> u-boot file doesn't work
> properly as Coreboot payload when booting : it gets stuck when jumping into 
> u-boot from coreboot.
>
> Jumping to boot code at 01110020(7f6ea000)
> CPU0: stack: 0012d000 - 0012e000, lowest used address 0012d9cc, stack used: 
> 1588 bytes
> entry= 0x01110020
> lb_start = 0x0010
> lb_size  = 0x00036870
> buffer   = 0x7f67c000
>
> After that I tried to use the board configure file instead (taken from my 
> older version u-boot code) of device tree, therefore I disabled device tree 
> in menuconfig. That's how my question comes from.
>
> I also tried to make u-boot work as payload of coreboot on qemu-x86.
> I ran make dist clean, make coreboot-x86_defconfig and built uboot using the 
> default menuconfig setting of device tree enabled, and embedded
> Then I built coreboot using u-boot as ELF payload. Somehow when I run it with 
> qemu-86, it crashes inside uboot :
>
>
> [root@localhost cid_iafw_opensource-coreboot]# qemu-system-x86_64 --nographic 
> -bios build/coreboot.rom
>
>
> U-Boot 2016.09-rc1-00324-g2863a9b-dirty (Aug 12 2016 - 11:13:50 +0100)
>
> CPU: x86_64, vendor AMD, device 663h
> DRAM:  127.6 MiB
> Using default environment
>
> Video: No video mode configured in coreboot!
> Model: QEMU x86 (I440FX)
> Net:   General Protection
> EIP: 0010:[<07f1440a>] EFLAGS: 0002
> Original EIP :[<0111040a>]
> EAX: 0002 EBX: 07d15668 ECX: 0001 EDX: c002
> ESI: 0041 EDI: 00c8 EBP: 00010001 ESP: 07d129d4
> DS: 0018 ES: 0018 FS: 0020 GS: 0018 SS: 0018
> CR0: 0033 CR2:  CR3:  CR4: 
> DR0:  DR1:  DR2:  DR3: 
> DR6: 0ff0 DR7: 0400
> Stack:
>0x07d12a14 : 0x0001
> 0x07d12a10 : 0x
> 0x07d12a0c : 0x07d15668
> 0x07d12a08 : 0x
> 0x07d12a04 : 0x159dc191
> 0x07d12a00 : 0x
> 0x07d129fc : 0x
> 0x07d129f8 : 0x1800
> 0x07d129f4 : 0x0001
> 0x07d129f0 : 0x07d12a5c
> 0x07d129ec : 0x07f35f29
> 0x07d129e8 : 0x07d15668
> 0x07d129e4 : 0x0001
> 0x07d129e0 : 0x0001
> 0x07d129dc : 0x0202
> 0x07d129d8 : 0x0010
> --->0x07d129d4 : 0x07f35efc
> 0x07d129d0 : 0x0002
> 0x07d129cc : 0x0010
> 0x07d129c8 : 0x07f1440a
> ### ERROR ### Please RESET the board ###
>
> When looking at the code, I see it crashes here
> /* IRQ Low-Level Service Routine */
> void irq_llsr(struct irq_regs *regs)
> {
> /*
>  * For detailed description of each exception, refer to:
>  * Intel® 64 and IA-32 Architectures Software Developer's Manual
>  * Volume 1: Basic Architecture
>  * Order Number: 253665-029US, November 2008
>  * Table 6-1. Exceptions and Interrupts
>  */
> if (regs->irq_id < 32) {
> /* Architecture defined exception */
> do_exception(regs);
>
> Any suggestion on this issue?

Are you using a recent-enough version of qemu? I think you need 2.3 or later.

Regards,
Simon


>
> Thanks a lot,
> Chi
>
>
>
>
>
> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Friday, August 12, 2016 7:21 PM
> To: Ding, ChiX
> Cc: u-boot@lists.denx.de; Bin Meng
> Subject: Re: [U-Boot] building u-boot x86 with device tree disabled , still 
> refers to device tree function
>
> +Bin
>
> Hi,
>
>
>
> On 11 August 2016 at 08:36, Ding, ChiX  wrote:
>> Hi there
>> I'm building u-boot as payload for x86 platform. I didn't enable
>> device tree in menuconfig (CONFIG_OF_CONTROL is not set) because I use
>> a board config file coreboot.h. When I built u-boot, it reports error
>> during linking stage : undefined reference to dm_scan_fdt_dev
>>
>> arch/x86/lib/built-in.o:(.u_boot_list_2_uclass_2_lpc+0x8): undefined 
>> reference to `dm_scan_fdt_dev'
>> common/built-in.o:(.u_boot_list_2_uclass_2_usb_hub+0x8): undefined reference 
>> to `dm_scan_fdt_dev'
>> drivers/built-in.o:(.u_boot_list_2_uclass_2_pch+0x8): undefined reference to 
>> `dm_scan_fdt_dev'
>> drivers/pci/built-in.o:(.u_boot_list_2_uclass_2_pci+0x8): undefined 
>> reference to `dm_scan_fdt_dev'
>> drivers/spi/built-in.o:(.u_boot_list_2_uclass_2_spi+0x8): undefined 
>> reference to 

Re: [U-Boot] [PATCH v2] mmc: s5p_sdhci: support the Driver model for Exynos

2016-09-26 Thread Simon Glass
On 9 September 2016 at 03:23, Jaehoon Chung  wrote:
> This patch support the driver model for s5p_sdhci controller.
> To support the legacy model, maintained the existing code.
>
> Note: If use the Driver Model, it needs to modify the device-tree.
> In future, will update the Device-tree and enable the configuratioin.
> (CONFIG_BLK, CONFIG_DM_MMC and CONFING_DM_MMC_OPS)
>
> Signed-off-by: Jaehoon Chung 
> Reviewed-by: Simon Glass 
> Acked-by: Minkyu Kang 
> ---
> Changelog for V2:
> - Rebase on latest u-boot
>
>  drivers/mmc/s5p_sdhci.c | 71 
> +
>  1 file changed, 71 insertions(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v4 1/6] dm: i2c: Add u8 read/write i2c functions

2016-09-26 Thread Simon Glass
On 25 September 2016 at 22:35, Keerthy  wrote:
> Add u8 i2c read/write hooks.
>
> Signed-off-by: Keerthy 
> Reviewed-by: Tom Rini 
> ---
>  drivers/i2c/i2c-uclass.c | 10 ++
>  include/i2c.h| 24 
>  2 files changed, 34 insertions(+)

Well, OK.

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 7/9] dtoc: Use items() to iterate over dictionaries in python 3.x

2016-09-26 Thread Simon Glass
On 26 September 2016 at 08:30, Paul Burton  wrote:
> In python 3.x the iteritems() method has been removed from dictionaries,
> and the items() method does effectively the same thing. Convert the code
> to attempt to use iteritems() to be efficient on python 2.x, but use
> items() when that fails on python 3.x.
>
> Signed-off-by: Paul Burton 
> ---
>
>  tools/dtoc/dtoc.py | 24 
>  tools/dtoc/fdt_fallback.py |  8 +++-
>  2 files changed, 27 insertions(+), 5 deletions(-)

Similar comment to previous patch...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 0/9] Python 3.x support for patman & dtoc

2016-09-26 Thread Simon Glass
Hi Paul,

On 26 September 2016 at 08:30, Paul Burton  wrote:
> This series makes patman & dtoc run on python 3.x, which allows them to
> work without hacks on distributions where the python binary is python
> 3.x. All changes are made in a way that continue to work on python 2.x,
> so both tools should work on either major version of python.
>

Thanks for doing this! Does it still install correctly with setup.py?

>
> Paul Burton (9):
>   patman: Replace tabs with spaces
>   patman: Make print statements python 3.x safe
>   patman: Make exception handling python 3.x safe
>   patman: Import 'configparser' lower case to be  python 3.x safe
>   patman: Decode stdout/stderr as utf8, be python 3.x safe
>   patman: Use items() to iterate over dictionaries in python 3.x
>   dtoc: Use items() to iterate over dictionaries in python 3.x
>   dtoc: Decode strings for struct.unpack on python 3.x
>   dtoc: Make integer division python 3.x safe
>
>  tools/dtoc/dtoc.py  | 26 -
>  tools/dtoc/fdt_fallback.py  |  8 +++-
>  tools/dtoc/fdt_util.py  |  3 +++
>  tools/patman/checkpatch.py  | 16 
>  tools/patman/command.py |  2 +-
>  tools/patman/cros_subprocess.py |  6 +++---
>  tools/patman/get_maintainer.py  |  2 +-
>  tools/patman/gitutil.py | 18 +-
>  tools/patman/patchstream.py |  6 +++---
>  tools/patman/patman.py  | 12 ++--
>  tools/patman/series.py  | 42 
> +
>  tools/patman/settings.py| 28 ++-
>  tools/patman/terminal.py| 12 +++-
>  tools/patman/test.py|  2 +-
>  14 files changed, 111 insertions(+), 72 deletions(-)
>
> --
> 2.10.0
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 8/9] dtoc: Decode strings for struct.unpack on python 3.x

2016-09-26 Thread Simon Glass
On 26 September 2016 at 08:30, Paul Burton  wrote:
> On python 3.x struct.unpack will complain if we provide it with a
> string since it expects to operate on a bytes object. In order to
> satisfy this requirement, encode the string to a bytes object when
> running on python 3.x.
>
> Signed-off-by: Paul Burton 
> ---
>
>  tools/dtoc/fdt_util.py | 3 +++
>  1 file changed, 3 insertions(+)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 5/9] patman: Decode stdout/stderr as utf8, be python 3.x safe

2016-09-26 Thread Simon Glass
On 26 September 2016 at 08:30, Paul Burton  wrote:
> In python 3.x reading stdout or stdin will produce a bytestring rather
> than a string. Decode it in CommunicateFilter such that the rest of the
> code can continue to deal with strings. This works fine with python 2.x
> too.
>
> Signed-off-by: Paul Burton 
> ---
>
>  tools/patman/cros_subprocess.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 9/9] dtoc: Make integer division python 3.x safe

2016-09-26 Thread Simon Glass
On 26 September 2016 at 08:30, Paul Burton  wrote:
> If we use the '/' operator then python 3.x will produce a float, and
> refuse to multiply the string sequence in Conv_name_to_c by it with:
>
> TypeError: can't multiply sequence by non-int of type 'float'
>
> Use the '//' operator instead to enforce that we want integer rather
> than floating point division.
>
> Signed-off-by: Paul Burton 
>
> ---
>
>  tools/dtoc/dtoc.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 6/9] patman: Use items() to iterate over dictionaries in python 3.x

2016-09-26 Thread Simon Glass
Hi Paul,

On 26 September 2016 at 08:30, Paul Burton  wrote:
> In python 3.x the iteritems() method has been removed from dictionaries,
> and the items() method does effectively the same thing. Convert the code
> to attempt to use iteritems() to be efficient on python 2.x, but use
> items() when that fails on python 3.x.
>
> Signed-off-by: Paul Burton 
> ---
>
>  tools/patman/settings.py | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

I'd be happy with just using items(), since efficiency is not a
concern here, and I'm not keen on the try..except approach for
handling Python 2/3 differences.

>
> diff --git a/tools/patman/settings.py b/tools/patman/settings.py
> index 3caf379..8b10630 100644
> --- a/tools/patman/settings.py
> +++ b/tools/patman/settings.py
> @@ -94,7 +94,11 @@ class _ProjectConfigParser(ConfigParser.SafeConfigParser):
>  if not self.has_section(project_settings):
>  self.add_section(project_settings)
>  project_defaults = _default_settings.get(project_name, {})
> -for setting_name, setting_value in project_defaults.iteritems():
> +try:
> +iterator = project_defaults.iteritems()
> +except:
> +iterator = project_defaults.items()
> +for setting_name, setting_value in iterator:
>  self.set(project_settings, setting_name, setting_value)
>
>  def get(self, section, option, *args, **kwargs):
> --
> 2.10.0
>

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/9] patman: Import 'configparser' lower case to be python 3.x safe

2016-09-26 Thread Simon Glass
On 26 September 2016 at 08:30, Paul Burton  wrote:
> In python 3.x module names used in import statements are case sensitive,
> and the configparser module is named in all lower-case. Import it as such
> in order to avoid errors when running with python 3.x.
>
> Signed-off-by: Paul Burton 
> ---
>
>  tools/patman/settings.py | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 3/9] patman: Make exception handling python 3.x safe

2016-09-26 Thread Simon Glass
On 26 September 2016 at 08:30, Paul Burton  wrote:
> Syntax for exception handling is a little more strict in python 3.x.
> Convert all uses to a form accepted by both python 2.x & python 3.x.
>
> Signed-off-by: Paul Burton 
> ---
>
>  tools/patman/command.py |  2 +-
>  tools/patman/cros_subprocess.py |  2 +-
>  tools/patman/gitutil.py | 12 ++--
>  3 files changed, 8 insertions(+), 8 deletions(-)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/9] gpio: bcm2835: add device tree support

2016-09-26 Thread Simon Glass
On 26 September 2016 at 06:26, Fabian Vogt  wrote:
> This patch adds device tree support for the bcm2835 GPIO driver.
>
> Signed-off-by: Fabian Vogt 
> ---
>  doc/device-tree-bindings/gpio/bcm2835-gpio.txt |  5 +
>  drivers/gpio/bcm2835_gpio.c| 24 
>  2 files changed, 29 insertions(+)
>  create mode 100644 doc/device-tree-bindings/gpio/bcm2835-gpio.txt

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/9] patman: Make print statements python 3.x safe

2016-09-26 Thread Simon Glass
On 26 September 2016 at 08:30, Paul Burton  wrote:
> In python 3.x, print must be used as a function call. Convert all print
> statements to the function call style, importing from __future__ where
> we print with no trailing newline or print to a file object.
>
> Signed-off-by: Paul Burton 
> ---
>
>  tools/patman/checkpatch.py | 16 
>  tools/patman/get_maintainer.py |  2 +-
>  tools/patman/gitutil.py|  6 +++---
>  tools/patman/patchstream.py|  6 +++---
>  tools/patman/patman.py | 12 ++--
>  tools/patman/series.py | 38 --
>  tools/patman/settings.py   | 16 +---
>  tools/patman/terminal.py   | 12 +++-
>  tools/patman/test.py   |  2 +-
>  9 files changed, 58 insertions(+), 52 deletions(-)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/9] patman: Replace tabs with spaces

2016-09-26 Thread Simon Glass
On 26 September 2016 at 08:30, Paul Burton  wrote:
> In preparation for running on python 3.x, which will refuse to run
> scripts which mix tabs & spaces for indentation, replace 2 tab
> characters present in series.py with spaces.
>
> Signed-off-by: Paul Burton 
> ---
>
>  tools/patman/series.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] spl: saveenv: adding saveenv support in SPL

2016-09-26 Thread Simon Glass
Hi Ravi,

On 26 September 2016 at 06:56, Ravi Babu  wrote:
> By default saveenv option is not supported for SPL. This patch
> enable the support for save environment variable for SPL build.
>
> Enable save environment support in SPL after setenv. By default
> the saveenv option is not provided in SPL, but some boards need
> this support in 'Falcon' boot, where SPL need to boot from
> different images based on environment variable set by OS. For
> example OS may set "reboot_image" environment variable to
> "recovery" inorder to boot recovery image by SPL. The SPL read
> "reboot_image" and act accordingly and change the reboot_image
> to default mode using setenv and save the environemnt.
>
> Signed-off-by: Ravi Babu 
> ---
>  common/spl/Kconfig| 13 +
>  drivers/mmc/Makefile  |  1 +
>  drivers/mmc/mmc_private.h |  3 +--
>  lib/Makefile  |  1 +
>  lib/hashtable.c   |  2 +-
>  5 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 2a8ddbc..0daa835 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -163,6 +163,19 @@ config SPL_ENV_SUPPORT
>   starting U-Boot first. Enabling this option will make getenv()
>   and setenv() available in SPL.
>
> +config SPL_SAVEENV_SUPPORT
> +   bool "Support save environment"
> +   depends on SPL && SPL_ENV_SUPPORT
> +   help
> + Enable save environment support in SPL after setenv. By default
> + the saveenv option is not provided in SPL, but some boards need
> + this support in 'Falcon' boot, where SPL need to boot from
> + different images based on environment variable set by OS. For
> + example OS may set "reboot_image" environment variable to
> + "recovery" inorder to boot recovery image by SPL. The SPL read
> + "reboot_image" and act accordingly and change the reboot_image
> + to default mode using setenv and save the environemnt.
> +

Reviewed-by: Simon Glass 

But I wonder if we could use SPL_SAVEENV, and drop the SUPPORT? For
U-Boot proper we use CONFIG_CMD_SAVEENV which is inconsistent - I
think we should really have a CONFIG_SAVEENV separate from the
command.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 3/3] config_whitelist: remove bogus options

2016-09-26 Thread Simon Glass
On 25 September 2016 at 20:52, Masahiro Yamada
 wrote:
> These are not CONFIG options (detected by my eyes).
>
> CONFIG_SPL_BUILD and CONFIG_TPL_BUILD are build options defined only
> for building SPL and TPL, respectively.
>
> The others are just mentioned in comment blocks.
>
> Now, scripts/build-whitelist.sh never picks up new options.  Once
> we kill these false ones, they will never revive.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> Changes in v3:
>   - Newly added
>
>  scripts/config_whitelist.txt | 10 --
>  1 file changed, 10 deletions(-)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Chrome OS keyboard not responding on snow

2016-09-26 Thread Moritz Fischer
Hi Adam

On Mon, Sep 26, 2016 at 12:35 PM, Adam Van Ymeren  wrote:
> I'm trying to run the latest u-boot on the old samsung exynos5250
> chromebook (snow_defconfig).  I've managed to get the u-boot console
> up but it doesn't respond to keyboard input.
>
> I managed to hack the startup procedure to call dm_dump_all() which
> shows the the keyboard-controller of cros_ec was attached I think.
>
> Anyone remember much about this board or have any tips on how I could
> start debugging this?

Not sure if helpful: Try to build with CONFIG_USB_KEYBOARD enabled,
and change stdin?

Cheers,

Moritz
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] net: add driver for Synopsys Ethernet QoS device

2016-09-26 Thread Stephen Warren

On 09/23/2016 03:49 PM, Joe Hershberger wrote:

Hi Stephen,

Thanks for sending this! I have some comments below.

Cheers,
-Joe

On Mon, Sep 12, 2016 at 12:48 PM, Stephen Warren  wrote:

From: Stephen Warren 

This driver supports the Synopsys Designware Ethernet QoS (Quality of
Service) a/k/a eqos IP block, which is a different design than the HW
supported by the existing designware.c driver. The IP supports many
options for bus type, clocking/reset structure, and feature list. This
driver currently supports the specific configuration used in NVIDIA's
Tegra186 chip, but should be extensible to other combinations quite
easily, as explained in the source.



diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c



+/* Core registers */


Why are registers not defined as a struct? That is the common way that
is accepted to represent registers in a driver.


It is common, but I find using structs has significant disadvantages, 
which outweigh any advantages, so I strongly prefer not to use them.


Disadvantages of structs:

* Drivers often have to deal with different but similar HW variants. 
Similar enough that it makes sense to use the same driver for them, but 
different enough that certain registers are placed differently in the 
memory map. With structs, there's little choice but to use ifdefs to 
pick a particular HW variant and bake that into the driver. This doesn't 
work well for drivers that must pick the variant at run-time rather than 
compile-time, e.g. drivers for USB or PCIe devices, or when you wish to 
build a single SW image that can run on multiple SoCs.


A common variant on this theme is device with different register layouts 
due to IP integration issues, such as a UART with byte-wide registers 
that appear at consecutive byte offsets in some SoCs, but at separate 
word addresses in other SoCs.


This issue is relevant here since the EQoS block is a generic IP block 
with many options that may have different SoC- or IP-version-specific 
differences between SoCs.


* The register space for the EQoS driver is quite sparse, and U-Boot 
uses a subset of the registers effectively making it even more sparse. 
Defining a struct to describe this will be a frustrating exercise in 
calculating the right amount of padding to place into the struct to get 
the correct offsets. Mistakes will be made and it will be annoying.


* Structs don't translate well to interactive debugging. It's common to 
read/write registers using md/mw U-Boot shell commands. With structs, 
you need to either (a) use some other data source for the register 
offsets, (b) manually add up field sizes (c) write a comment indicating 
the offset next to each field. (a) and (b) are both annoying, and by the 
time you've done (c) (which is quite complicated in the face of ifdefs) 
you may as well have simply used #defines in the first place.



+/*
+ * Warn if the cache-line size is larger than the descriptor size. In such
+ * cases the driver will likely fail because the CPU needs to flush the cache
+ * when requeuing RX buffers, therefore descriptors written by the hardware
+ * may be discarded.
+ *
+ * This can be fixed by defining CONFIG_SYS_NONCACHED_MEMORY which will cause
+ * the driver to allocate descriptors from a pool of non-cached memory.
+ */
+#if EQOS_DESCRIPTOR_SIZE < ARCH_DMA_MINALIGN
+#if !defined(CONFIG_SYS_NONCACHED_MEMORY) && \
+   !defined(CONFIG_SYS_DCACHE_OFF) && !defined(CONFIG_X86)


Please include an explanation for why x86 is special.


Sure. Do note though that this exact text already exists in other U-Boot 
drivers.



+static int eqos_start_clks_tegra(struct udevice *dev)


Why is this not in a board file and a separate patch?


The clocks (and other resources) that this driver operates on are 
directly related to the EQoS IP block itself. Hence, it's completely 
appropriate for this driver to deal with them.


Perhaps the name "tegra" is slightly misleading; it refers to "the 
configuration of the core EQoS block that Tegra happens to have chosen" 
rather than "something entirely Tegra-specific that is unrelated to this 
device/driver". However, I'm not sure what name would be better than 
"tegra" here; the correct name is something like 
axi_ahb_dma_mtl_core_single_phy_rgmii, but that's far too long for a 
symbol name. I attempted to describe this in the comment regarding IP 
configuration at the beginning of the file. Is there a specific 
shortcoming in that comment that could be changed to address this better?



+static int eqos_calibrate_pads_tegra(struct udevice *dev)


This function is the only part that's truly Tegra-specific, rather than 
specific to the standard IP configuration Tegra happens to use. However, 
I still believe it's entirely appropriate for this driver to include the 
logic to control these registers; they are part of the Ethernet IP block 
itself, even if NVIDIA added them as customer registers. The registers 
can't 

Re: [U-Boot] [U-Boot,v2] kconfig: introduce kconfig for UBI

2016-09-26 Thread Tom Rini
On Wed, Sep 21, 2016 at 07:58:19AM +0200, Heiko Schocher wrote:

> move the UBI config options into Kconfig.
> 
> Signed-off-by: Heiko Schocher 
> Reviewed-by: Simon Glass 
> Reviewed-by: Andrew F. Davis 
> Reviewed by: Evgeni Dobrev 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Chrome OS keyboard not responding on snow

2016-09-26 Thread Adam Van Ymeren
I'm trying to run the latest u-boot on the old samsung exynos5250
chromebook (snow_defconfig).  I've managed to get the u-boot console
up but it doesn't respond to keyboard input.

I managed to hack the startup procedure to call dm_dump_all() which
shows the the keyboard-controller of cros_ec was attached I think.

Anyone remember much about this board or have any tips on how I could
start debugging this?

Thanks,
-Adam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] rk3288 u-boot

2016-09-26 Thread Andrea Di Chiara

Hi,
I'd like to update provided u-boot image on a rk3288 FireFly board with
a standard version. There is any u-boot mainline branch that has network
support for rk3288 (gmac). Could someone suggest me which u-boot should
I use?
thank you for the attention,
regards
Andrea

Software Department
softw...@teseo.com

-
TESEO spavia Agnelli, 49  63023 FERMO (FM) ITALY
Tel. +39 0734 628818   --Fax. +39 0734 628816

Disclaimer: This electronic mail transmission may contain legally privileged 
and/or confidential information. Do not read this if you are not the person(s) 
named. Any use, distribution, copying or disclosure by any other person is 
strictly prohibited. If you receive this transmission by mistake destroy the 
original transmission and its attachments without reading or saving in any 
manner.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Please pull fsl-qoriq master

2016-09-26 Thread Tom Rini
On Mon, Sep 26, 2016 at 03:58:05PM +, york sun wrote:

> Tom,
> 
> Let's try again.
> 
> The following changes since commit 8cbb389bb3da80cbf8911f8386cbff92c6a78afe:
> 
>Prepare v2016.09 (2016-09-12 10:05:51 -0400)
> 
> are available in the git repository at:
> 
>git://git.denx.de/u-boot-fsl-qoriq.git
> 
> for you to fetch changes up to 295a24b3d6a751b79373e7ff2199d91765cae8a9:
> 
>armv7: ls102xa: Rename GIC_ADDR and DCSR_RCPM_ADDR (2016-09-26 
> 08:53:07 -0700)
> 

Applied to u-boot/master, 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] arm: dra7xx: Move fastboot options to defconfig

2016-09-26 Thread Sam Protsenko
Bump.

On Thu, Sep 22, 2016 at 9:52 PM, Sam Protsenko
 wrote:
> Now that fastboot options are available in Kconfig, we can migrate them
> from DRA7 header to corresponding DRA7 defconfigs.
>
> Signed-off-by: Sam Protsenko 
> ---
>  configs/dra7xx_evm_defconfig|  8 
>  configs/dra7xx_hs_evm_defconfig |  8 
>  include/configs/dra7xx_evm.h| 18 +-
>  3 files changed, 25 insertions(+), 9 deletions(-)
>
> diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
> index 64df490..321ac45 100644
> --- a/configs/dra7xx_evm_defconfig
> +++ b/configs/dra7xx_evm_defconfig
> @@ -14,6 +14,14 @@ CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_SPL_DMA_SUPPORT=y
>  CONFIG_HUSH_PARSER=y
> +CONFIG_FASTBOOT=y
> +CONFIG_USB_FUNCTION_FASTBOOT=y
> +CONFIG_CMD_FASTBOOT=y
> +CONFIG_ANDROID_BOOT_IMAGE=y
> +CONFIG_FASTBOOT_BUF_ADDR=0x8200
> +CONFIG_FASTBOOT_BUF_SIZE=0x2f00
> +CONFIG_FASTBOOT_FLASH=y
> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
>  CONFIG_CMD_ASKENV=y
> diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
> index 5fdc2b7..c0485e0 100644
> --- a/configs/dra7xx_hs_evm_defconfig
> +++ b/configs/dra7xx_hs_evm_defconfig
> @@ -18,6 +18,14 @@ CONFIG_SPL=y
>  CONFIG_SPL_STACK_R=y
>  CONFIG_SPL_DMA_SUPPORT=y
>  CONFIG_HUSH_PARSER=y
> +CONFIG_FASTBOOT=y
> +CONFIG_USB_FUNCTION_FASTBOOT=y
> +CONFIG_CMD_FASTBOOT=y
> +CONFIG_ANDROID_BOOT_IMAGE=y
> +CONFIG_FASTBOOT_BUF_ADDR=0x8200
> +CONFIG_FASTBOOT_BUF_SIZE=0x2f00
> +CONFIG_FASTBOOT_FLASH=y
> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1
>  CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_IMLS is not set
>  CONFIG_CMD_ASKENV=y
> diff --git a/include/configs/dra7xx_evm.h b/include/configs/dra7xx_evm.h
> index 194804c..273374a 100644
> --- a/include/configs/dra7xx_evm.h
> +++ b/include/configs/dra7xx_evm.h
> @@ -121,15 +121,15 @@
> DFU_ALT_INFO_EMMC \
> DFU_ALT_INFO_RAM \
> DFU_ALT_INFO_QSPI
> -
> -/* Fastboot */
> -#define CONFIG_USB_FUNCTION_FASTBOOT
> -#define CONFIG_CMD_FASTBOOT
> -#define CONFIG_ANDROID_BOOT_IMAGE
> -#define CONFIG_FASTBOOT_BUF_ADDRCONFIG_SYS_LOAD_ADDR
> -#define CONFIG_FASTBOOT_BUF_SIZE0x2F00
> -#define CONFIG_FASTBOOT_FLASH
> -#define CONFIG_FASTBOOT_FLASH_MMC_DEV   1
> +#else
> +/* Discard fastboot in SPL build, to spare some space */
> +#undef CONFIG_FASTBOOT
> +#undef CONFIG_USB_FUNCTION_FASTBOOT
> +#undef CONFIG_CMD_FASTBOOT
> +#undef CONFIG_ANDROID_BOOT_IMAGE
> +#undef CONFIG_FASTBOOT_BUF_ADDR
> +#undef CONFIG_FASTBOOT_BUF_SIZE
> +#undef CONFIG_FASTBOOT_FLASH
>  #endif
>
>  #include 
> --
> 2.9.3
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/9] MIPS: fix ROM exception vectors

2016-09-26 Thread Matthew Fortune
Daniel Schwierzeck  writes:
> 2016-09-26 9:58 GMT+02:00 Matthew Fortune :
> > Daniel Schwierzeck  writes:
> >> When booting from ROM, early exceptions can't be handled
> >> properly. Instead of busy-looping give the developer the
> >> possibilty to examine the situation. Thus issue a SDBBP
> >> instruction to transfer control to hardware debugger if one
> >> is attached.
> >
> > You could make the SDBBP into a UHI operation that can be read by
> > a debugger as an unhandled exception rather than an unexpected
> > breakpoint (assuming said debugger knows about UHI). The fragment
> > I use in lightweight boot code is:
> >
> > move  k0, t9# Preserve t9
> > move  k1, a0# Preserve a0
> > li$25, 15   # UHI exception operation
> > li$4, 0 # Use hard register context
> > sdbbp 1 # Invoke UHI operation
> >
> > You lose k0/k1 in this which may be undesirable but it might
> > be a reasonable trade off. This shouldn't go in the debug vector
> > of course!
> >
> 
> sounds interesting. I'll have a look into that. Can I test this with
> OpenOCD and GDB?

I'm sorry to say progress with getting UHI into OpenOCD is rather slow.
The main effort for OpenOCD has been part of the MIPSfpga project which
I am not directly involved with. To my knowledge they have the basic
'write' call implemented but are not handling all the operations and
the implementation is out of tree. I'll try and check on this and let
you know.

I had an idea of using a special UHI operation to indicate a boot failure
with a simple enumerated 'reason' code so you could get a quick hint at
what blew up in low level boot code without the source. I.e. any errors
that can be detected without ending up raising an exception. I put two
quickly thought up errors into the UHI spec as an example but I only
have some simplistic boot code to play with. If you think U-boot could
have a range of errors to report like this (and want to use it) then we
can add to the list.

Matthew
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 23/23] boston: Enable CONFIG_DISTRO_DEFAULTS in defconfigs

2016-09-26 Thread Paul Burton
CONFIG_DISTRO_DEFAULTS selects a number of things we want for Boston
defconfigs & generally describes what we want - to be able to boot an
arbitrary Linux distribution. Enable it in order to shorten the
defconfigs & to automatically keep up with any changes in the choice of
Kconfig symbols selected.

Signed-off-by: Paul Burton 

---

 configs/boston32r2_defconfig   | 7 +--
 configs/boston32r2el_defconfig | 7 +--
 configs/boston64r2_defconfig   | 7 +--
 configs/boston64r2el_defconfig | 7 +--
 4 files changed, 4 insertions(+), 24 deletions(-)

diff --git a/configs/boston32r2_defconfig b/configs/boston32r2_defconfig
index 61360c5..3843411 100644
--- a/configs/boston32r2_defconfig
+++ b/configs/boston32r2_defconfig
@@ -6,11 +6,11 @@ CONFIG_SYS_TEXT_BASE=0x9fc0
 CONFIG_MIPS_BOOT_FDT=y
 CONFIG_MIPS_CM_BASE=0x1610
 CONFIG_DEFAULT_DEVICE_TREE="img,boston"
+CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_FIT_BEST_MATCH=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="boston # "
 # CONFIG_CMD_ELF is not set
 # CONFIG_CMD_IMLS is not set
@@ -19,16 +19,11 @@ CONFIG_CMD_MEMTEST=y
 # CONFIG_CMD_LOADB is not set
 # CONFIG_CMD_LOADS is not set
 # CONFIG_CMD_FPGA is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_SNTP=y
 CONFIG_CMD_DNS=y
 CONFIG_CMD_LINK_LOCAL=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
diff --git a/configs/boston32r2el_defconfig b/configs/boston32r2el_defconfig
index 74d16ea..d9436b8 100644
--- a/configs/boston32r2el_defconfig
+++ b/configs/boston32r2el_defconfig
@@ -7,11 +7,11 @@ CONFIG_SYS_LITTLE_ENDIAN=y
 CONFIG_MIPS_BOOT_FDT=y
 CONFIG_MIPS_CM_BASE=0x1610
 CONFIG_DEFAULT_DEVICE_TREE="img,boston"
+CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_FIT_BEST_MATCH=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="boston # "
 # CONFIG_CMD_ELF is not set
 # CONFIG_CMD_IMLS is not set
@@ -20,16 +20,11 @@ CONFIG_CMD_MEMTEST=y
 # CONFIG_CMD_LOADB is not set
 # CONFIG_CMD_LOADS is not set
 # CONFIG_CMD_FPGA is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_SNTP=y
 CONFIG_CMD_DNS=y
 CONFIG_CMD_LINK_LOCAL=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
diff --git a/configs/boston64r2_defconfig b/configs/boston64r2_defconfig
index 4d67804..fb0a99c 100644
--- a/configs/boston64r2_defconfig
+++ b/configs/boston64r2_defconfig
@@ -6,11 +6,11 @@ CONFIG_CPU_MIPS64_R2=y
 CONFIG_MIPS_BOOT_FDT=y
 CONFIG_MIPS_CM_BASE=0x1610
 CONFIG_DEFAULT_DEVICE_TREE="img,boston"
+CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_FIT_BEST_MATCH=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="boston # "
 # CONFIG_CMD_ELF is not set
 # CONFIG_CMD_IMLS is not set
@@ -19,16 +19,11 @@ CONFIG_CMD_MEMTEST=y
 # CONFIG_CMD_LOADB is not set
 # CONFIG_CMD_LOADS is not set
 # CONFIG_CMD_FPGA is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_SNTP=y
 CONFIG_CMD_DNS=y
 CONFIG_CMD_LINK_LOCAL=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
diff --git a/configs/boston64r2el_defconfig b/configs/boston64r2el_defconfig
index e0d514f..f1d752f 100644
--- a/configs/boston64r2el_defconfig
+++ b/configs/boston64r2el_defconfig
@@ -7,11 +7,11 @@ CONFIG_CPU_MIPS64_R2=y
 CONFIG_MIPS_BOOT_FDT=y
 CONFIG_MIPS_CM_BASE=0x1610
 CONFIG_DEFAULT_DEVICE_TREE="img,boston"
+CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_FIT_BEST_MATCH=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="boston # "
 # CONFIG_CMD_ELF is not set
 # CONFIG_CMD_IMLS is not set
@@ -20,16 +20,11 @@ CONFIG_CMD_MEMTEST=y
 # CONFIG_CMD_LOADB is not set
 # CONFIG_CMD_LOADS is not set
 # CONFIG_CMD_FPGA is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_SNTP=y
 CONFIG_CMD_DNS=y
 CONFIG_CMD_LINK_LOCAL=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 21/23] boston: Enable Realtek ethernet PHY support

2016-09-26 Thread Paul Burton
The ethernet PHY used on the MIPS Boston development board is a Realtek
RTL8211E. Enable support for it.

Signed-off-by: Paul Burton 
---

 include/configs/boston.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/configs/boston.h b/include/configs/boston.h
index 7c6210e..9fa2714 100644
--- a/include/configs/boston.h
+++ b/include/configs/boston.h
@@ -79,4 +79,9 @@
(0xb800 + (128 << 20) - CONFIG_ENV_SIZE)
 #endif
 
+/*
+ * Ethernet
+ */
+#define CONFIG_PHY_REALTEK
+
 #endif /* __CONFIGS_BOSTON_H__ */
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 22/23] boston: Probe ethernet controller during boot

2016-09-26 Thread Paul Burton
Add compatible strings for the PCIe bridges & EG20T ethernet controller
such that the devices are probed during boot, without the user needing
to manually cause that to happen by running "pci enum" after boot. This
allows for use of the ethernet controller without the manual PCI
enumeration step. Enable the GPIO driver to provide the PHY reset GPIO.

Signed-off-by: Paul Burton 
---

 arch/mips/Kconfig  | 1 +
 arch/mips/dts/img,boston.dts   | 6 +++---
 configs/boston32r2_defconfig   | 1 +
 configs/boston32r2el_defconfig | 1 +
 configs/boston64r2_defconfig   | 1 +
 configs/boston64r2el_defconfig | 1 +
 6 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 9fa41e9..407dad8 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -78,6 +78,7 @@ config MACH_PIC32
 config TARGET_BOSTON
bool "Support Boston"
select DM
+   select DM_GPIO
select DM_SERIAL
select OF_CONTROL
select MIPS_CM
diff --git a/arch/mips/dts/img,boston.dts b/arch/mips/dts/img,boston.dts
index 1d4eeda..1623a25 100644
--- a/arch/mips/dts/img,boston.dts
+++ b/arch/mips/dts/img,boston.dts
@@ -130,7 +130,7 @@
};
 
pci2_root@0,0,0 {
-   compatible = "pci10ee,7021";
+   compatible = "pci10ee,7021", "pci-bridge";
reg = <0x 0 0 0 0>;
 
#address-cells = <3>;
@@ -138,7 +138,7 @@
#interrupt-cells = <1>;
 
eg20t_bridge@1,0,0 {
-   compatible = "pci8086,8800";
+   compatible = "pci8086,8800", "pci-bridge";
reg = <0x0001 0 0 0 0>;
 
#address-cells = <3>;
@@ -146,7 +146,7 @@
#interrupt-cells = <1>;
 
eg20t_mac@2,0,1 {
-   compatible = "pci8086,8802";
+   compatible = "pci8086,8802", 
"intel,pch-gbe";
reg = <0x00020100 0 0 0 0>;
phy-reset-gpios = <_gpio 6 
GPIO_ACTIVE_LOW>;
};
diff --git a/configs/boston32r2_defconfig b/configs/boston32r2_defconfig
index 6b38da9..61360c5 100644
--- a/configs/boston32r2_defconfig
+++ b/configs/boston32r2_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
+CONFIG_EG20T_GPIO=y
 CONFIG_MTD=y
 CONFIG_CFI_FLASH=y
 CONFIG_DM_ETH=y
diff --git a/configs/boston32r2el_defconfig b/configs/boston32r2el_defconfig
index d56c405..74d16ea 100644
--- a/configs/boston32r2el_defconfig
+++ b/configs/boston32r2el_defconfig
@@ -33,6 +33,7 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
+CONFIG_EG20T_GPIO=y
 CONFIG_MTD=y
 CONFIG_CFI_FLASH=y
 CONFIG_DM_ETH=y
diff --git a/configs/boston64r2_defconfig b/configs/boston64r2_defconfig
index 2c0ac4d..4d67804 100644
--- a/configs/boston64r2_defconfig
+++ b/configs/boston64r2_defconfig
@@ -32,6 +32,7 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
+CONFIG_EG20T_GPIO=y
 CONFIG_MTD=y
 CONFIG_CFI_FLASH=y
 CONFIG_DM_ETH=y
diff --git a/configs/boston64r2el_defconfig b/configs/boston64r2el_defconfig
index e784d68..e0d514f 100644
--- a/configs/boston64r2el_defconfig
+++ b/configs/boston64r2el_defconfig
@@ -33,6 +33,7 @@ CONFIG_CMD_FS_GENERIC=y
 CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_CLK=y
+CONFIG_EG20T_GPIO=y
 CONFIG_MTD=y
 CONFIG_CFI_FLASH=y
 CONFIG_DM_ETH=y
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 19/23] boston: Setup memory ranges in FDT provided to Linux

2016-09-26 Thread Paul Burton
The boston memory map isn't suited to the simple "all memory starting
from 0" approach that the MIPS arch_fixup_fdt() implementation takes.
Instead we need to indicate the first 256MiB of DDR from 0 and the rest
from 0x9000. Implement ft_board_setup to do that.

Signed-off-by: Paul Burton 
---

 arch/mips/Kconfig|  1 +
 board/imgtec/boston/Makefile |  1 +
 board/imgtec/boston/dt.c | 27 +++
 3 files changed, 29 insertions(+)
 create mode 100644 board/imgtec/boston/dt.c

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index b425414..9fa41e9 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -83,6 +83,7 @@ config TARGET_BOSTON
select MIPS_CM
select MIPS_L1_CACHE_SHIFT_6
select MIPS_L2_CACHE
+   select OF_BOARD_SETUP
select SUPPORTS_BIG_ENDIAN
select SUPPORTS_LITTLE_ENDIAN
select SUPPORTS_CPU_MIPS32_R1
diff --git a/board/imgtec/boston/Makefile b/board/imgtec/boston/Makefile
index deda457..d3fd49d 100644
--- a/board/imgtec/boston/Makefile
+++ b/board/imgtec/boston/Makefile
@@ -6,4 +6,5 @@
 
 obj-y += checkboard.o
 obj-y += ddr.o
+obj-y += dt.o
 obj-y += lowlevel_init.o
diff --git a/board/imgtec/boston/dt.c b/board/imgtec/boston/dt.c
new file mode 100644
index 000..b34f9bc
--- /dev/null
+++ b/board/imgtec/boston/dt.c
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2016 Imagination Technologies
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+
+int ft_board_setup(void *blob, bd_t *bd)
+{
+   DECLARE_GLOBAL_DATA_PTR;
+   u64 mem_start[2], mem_size[2];
+   int mem_regions;
+
+   mem_start[0] = 0;
+   mem_size[0] = min_t(u64, 256llu << 20, gd->ram_size);
+   mem_regions = 1;
+
+   if (gd->ram_size > mem_size[0]) {
+   mem_start[1] = 0x8000 + mem_size[0];
+   mem_size[1] = gd->ram_size - mem_size[0];
+   mem_regions++;
+   }
+
+   return fdt_fixup_memory_banks(blob, mem_start, mem_size, mem_regions);
+}
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 18/23] boston: Move CM GCRs away from flash

2016-09-26 Thread Paul Burton
Move the MIPS Coherence Manager (CM) Global Configuration Registers
(GCRs) away from the region of the physical address space which the
Boston board's parallel flash is found in, such that we can access all
of flash without clobbering GCRs.

Signed-off-by: Paul Burton 
---

 configs/boston32r2_defconfig   | 1 +
 configs/boston32r2el_defconfig | 1 +
 configs/boston64r2_defconfig   | 1 +
 configs/boston64r2el_defconfig | 1 +
 4 files changed, 4 insertions(+)

diff --git a/configs/boston32r2_defconfig b/configs/boston32r2_defconfig
index e5f61b8..6b38da9 100644
--- a/configs/boston32r2_defconfig
+++ b/configs/boston32r2_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x9fc0
 # CONFIG_MIPS_BOOT_CMDLINE_LEGACY is not set
 # CONFIG_MIPS_BOOT_ENV_LEGACY is not set
 CONFIG_MIPS_BOOT_FDT=y
+CONFIG_MIPS_CM_BASE=0x1610
 CONFIG_DEFAULT_DEVICE_TREE="img,boston"
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
diff --git a/configs/boston32r2el_defconfig b/configs/boston32r2el_defconfig
index e9a23b8..d56c405 100644
--- a/configs/boston32r2el_defconfig
+++ b/configs/boston32r2el_defconfig
@@ -5,6 +5,7 @@ CONFIG_SYS_LITTLE_ENDIAN=y
 # CONFIG_MIPS_BOOT_CMDLINE_LEGACY is not set
 # CONFIG_MIPS_BOOT_ENV_LEGACY is not set
 CONFIG_MIPS_BOOT_FDT=y
+CONFIG_MIPS_CM_BASE=0x1610
 CONFIG_DEFAULT_DEVICE_TREE="img,boston"
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
diff --git a/configs/boston64r2_defconfig b/configs/boston64r2_defconfig
index 55943c5..2c0ac4d 100644
--- a/configs/boston64r2_defconfig
+++ b/configs/boston64r2_defconfig
@@ -4,6 +4,7 @@ CONFIG_CPU_MIPS64_R2=y
 # CONFIG_MIPS_BOOT_CMDLINE_LEGACY is not set
 # CONFIG_MIPS_BOOT_ENV_LEGACY is not set
 CONFIG_MIPS_BOOT_FDT=y
+CONFIG_MIPS_CM_BASE=0x1610
 CONFIG_DEFAULT_DEVICE_TREE="img,boston"
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
diff --git a/configs/boston64r2el_defconfig b/configs/boston64r2el_defconfig
index 865177d..e784d68 100644
--- a/configs/boston64r2el_defconfig
+++ b/configs/boston64r2el_defconfig
@@ -5,6 +5,7 @@ CONFIG_CPU_MIPS64_R2=y
 # CONFIG_MIPS_BOOT_CMDLINE_LEGACY is not set
 # CONFIG_MIPS_BOOT_ENV_LEGACY is not set
 CONFIG_MIPS_BOOT_FDT=y
+CONFIG_MIPS_CM_BASE=0x1610
 CONFIG_DEFAULT_DEVICE_TREE="img,boston"
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 20/23] boston: Bump CONFIG_SYS_BOOTM_LEN to 64MiB

2016-09-26 Thread Paul Burton
The default value of CONFIG_SYS_BOOTM_LEN is too small for typical
boston Linux kernels. Increase the limit to 64MB, which covers current
kernels with plenty of breathing room.

Signed-off-by: Paul Burton 
---

 include/configs/boston.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/boston.h b/include/configs/boston.h
index e958054..7c6210e 100644
--- a/include/configs/boston.h
+++ b/include/configs/boston.h
@@ -11,6 +11,7 @@
  * General board configuration
  */
 #define CONFIG_DISPLAY_BOARDINFO
+#define CONFIG_SYS_BOOTM_LEN   (64 * 1024 * 1024)
 
 /*
  * CPU
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 14/23] gpio: Provide dummy get/request & is_valid functions

2016-09-26 Thread Paul Burton
Allow for drivers to make use of driver model GPIOs when they're enabled
& available without needing to #ifdef on CONFIG_DM_GPIO by providing
dummy functions covering GPIO requests. Each will simply return -ENODEV
or -EINVAL, depending upon which the real implementation returns when a
GPIO isn't found. Only the driver model versions of the GPIO request
functions are covered & dm_gpio_request is excluded since it's
documented as only being of use for debugging, so drivers shouldn't be
calling it anyway.

Also provide a dummy dm_gpio_is_valid, with the idea that all other GPIO
functions called would be within an if (dm_gpio_is_valid(...)) statement
and have been optimised out in cases where that returns a compile-time
constant false.

This parallels the clock API, keeping the #ifdefs & checks in a single
location allowing drivers or other code to use GPIOs without needing to
perform such checks themselves.

Signed-off-by: Paul Burton 

---

 include/asm-generic/gpio.h | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 4aa0004..f6593a7 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -135,6 +135,9 @@ struct gpio_desc {
  */
 static inline bool dm_gpio_is_valid(const struct gpio_desc *desc)
 {
+   if (!IS_ENABLED(CONFIG_DM_GPIO))
+   return false;
+
return desc->dev != NULL;
 }
 
@@ -343,7 +346,14 @@ const char *gpio_get_bank_info(struct udevice *dev, int 
*offset_count);
  * @desc:  Returns description, on success
  * @return 0 if OK, -ve on error
  */
+#ifdef CONFIG_DM_GPIO
 int dm_gpio_lookup_name(const char *name, struct gpio_desc *desc);
+#else
+static inline int dm_gpio_lookup_name(const char *name, struct gpio_desc *desc)
+{
+   return -EINVAL;
+}
+#endif
 
 /**
  * gpio_lookup_name - Look up a GPIO name and return its details
@@ -356,8 +366,17 @@ int dm_gpio_lookup_name(const char *name, struct gpio_desc 
*desc);
  * @offsetp: Returns the offset number within this device
  * @gpiop: Returns the absolute GPIO number, numbered from 0
  */
+#ifdef CONFIG_DM_GPIO
 int gpio_lookup_name(const char *name, struct udevice **devp,
 unsigned int *offsetp, unsigned int *gpiop);
+#else
+static inline int
+gpio_lookup_name(const char *name, struct udevice **devp,
+unsigned int *offsetp, unsigned int *gpiop)
+{
+   return -EINVAL;
+}
+#endif
 
 /**
  * gpio_get_values_as_int() - Turn the values of a list of GPIOs into an int
@@ -428,8 +447,17 @@ int gpio_claim_vector(const int *gpio_num_array, const 
char *fmt);
  * something wrong with the list, or other -ve for another error (e.g.
  * -EBUSY if a GPIO was already requested)
  */
+#ifdef CONFIG_DM_GPIO
 int gpio_request_by_name(struct udevice *dev, const char *list_name,
 int index, struct gpio_desc *desc, int flags);
+#else
+static inline int
+gpio_request_by_name(struct udevice *dev, const char *list_name,
+int index, struct gpio_desc *desc, int flags)
+{
+   return -ENOENT;
+}
+#endif
 
 /**
  * gpio_request_list_by_name() - Request a list of GPIOs
@@ -452,9 +480,19 @@ int gpio_request_by_name(struct udevice *dev, const char 
*list_name,
  * @flags: Indicates the GPIO input/output settings (GPIOD_...)
  * @return number of GPIOs requested, or -ve on error
  */
+#ifdef CONFIG_DM_GPIO
 int gpio_request_list_by_name(struct udevice *dev, const char *list_name,
  struct gpio_desc *desc_list, int max_count,
  int flags);
+#else
+static inline int
+gpio_request_list_by_name(struct udevice *dev, const char *list_name,
+ struct gpio_desc *desc_list, int max_count,
+ int flags)
+{
+   return -ENOENT;
+}
+#endif
 
 /**
  * dm_gpio_request() - manually request a GPIO
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 17/23] MIPS: Make CM GCR base configurable

2016-09-26 Thread Paul Burton
Without adding a prompt for CONFIG_MIPS_CM_BASE, Kconfig doesn't allow
defconfigs to set it. Provide the prompt in order to allow for that.

Signed-off-by: Paul Burton 
---

 arch/mips/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 097ad58..b425414 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -352,7 +352,8 @@ config MIPS_CM
  information such as cache configuration.
 
 config MIPS_CM_BASE
-   hex
+   hex "MIPS CM GCR Base Address"
+   depends on MIPS_CM
default 0x1fbf8000
help
  The physical base address at which to map the MIPS Coherence Manager
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 15/23] gpio: eg20t: Add driver for Intel EG20T GPIO controllers

2016-09-26 Thread Paul Burton
Add a driver for the GPIO controller found in the Intel EG20T Platform
Controller Hub. This is used on the MIPS Boston development board to
provide GPIOs including ethernet PHY reset.

Signed-off-by: Paul Burton 

---

 drivers/gpio/Kconfig  |   8 +++
 drivers/gpio/Makefile |   1 +
 drivers/gpio/eg20t-gpio.c | 133 ++
 3 files changed, 142 insertions(+)
 create mode 100644 drivers/gpio/eg20t-gpio.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8d9ab52..4a6a22f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -221,4 +221,12 @@ config MPC85XX_GPIO
 
  The driver has been tested on MPC85XX, but it is likely that other
  PowerQUICC III devices will work as well.
+
+config EG20T_GPIO
+   bool "Intel EG20T GPIO driver"
+   depends on DM_GPIO && DM_PCI
+   help
+ Enable this to support the GPIO controller found in the Intel EG20T
+ Platform Controller Hub.
+
 endmenu
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 8939226..a94aeb1 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -58,3 +58,4 @@ obj-$(CONFIG_MVEBU_GPIO)  += mvebu_gpio.o
 obj-$(CONFIG_MSM_GPIO) += msm_gpio.o
 obj-$(CONFIG_$(SPL_)PCF8575_GPIO)  += pcf8575_gpio.o
 obj-$(CONFIG_PM8916_GPIO)  += pm8916_gpio.o
+obj-$(CONFIG_EG20T_GPIO)   += eg20t-gpio.o
diff --git a/drivers/gpio/eg20t-gpio.c b/drivers/gpio/eg20t-gpio.c
new file mode 100644
index 000..05db771
--- /dev/null
+++ b/drivers/gpio/eg20t-gpio.c
@@ -0,0 +1,133 @@
+/*
+ * Copyright (C) 2016 Imagination Technologies
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum {
+   REG_IEN = 0x00,
+   REG_ISTATUS = 0x04,
+   REG_IDISP   = 0x08,
+   REG_ICLR= 0x0c,
+   REG_IMASK   = 0x10,
+   REG_IMASKCLR= 0x14,
+   REG_PO  = 0x18,
+   REG_PI  = 0x1c,
+   REG_PM  = 0x20,
+};
+
+struct eg20t_gpio_priv {
+   void *base;
+};
+
+static int eg20t_gpio_get_value(struct udevice *dev, unsigned int offset)
+{
+   struct eg20t_gpio_priv *priv = dev_get_priv(dev);
+   uint32_t pm, pval;
+
+   pm = readl(priv->base + REG_PM);
+   if ((pm >> offset) & 0x1)
+   pval = readl(priv->base + REG_PO);
+   else
+   pval = readl(priv->base + REG_PI);
+
+   return (pval >> offset) & 0x1;
+}
+
+static int eg20t_gpio_set_value(struct udevice *dev, unsigned int offset,
+   int value)
+{
+   struct eg20t_gpio_priv *priv = dev_get_priv(dev);
+   uint32_t po;
+
+   po = readl(priv->base + REG_PO);
+   if (value)
+   po |= 1 << offset;
+   else
+   po &= ~(1 << offset);
+   writel(po, priv->base + REG_PO);
+   return 0;
+}
+
+static int eg20t_gpio_direction_input(struct udevice *dev, unsigned int offset)
+{
+   struct eg20t_gpio_priv *priv = dev_get_priv(dev);
+   uint32_t pm;
+
+   pm = readl(priv->base + REG_PM);
+   pm &= ~(1 << offset);
+   writel(pm, priv->base + REG_PM);
+   return 0;
+}
+
+static int eg20t_gpio_direction_output(struct udevice *dev, unsigned int 
offset,
+  int value)
+{
+   struct eg20t_gpio_priv *priv = dev_get_priv(dev);
+   uint32_t pm;
+
+   pm = readl(priv->base + REG_PM);
+   pm |= 1 << offset;
+   writel(pm, priv->base + REG_PM);
+
+   return eg20t_gpio_set_value(dev, offset, value);
+}
+
+static int eg20t_gpio_get_function(struct udevice *dev, unsigned int offset)
+{
+   struct eg20t_gpio_priv *priv = dev_get_priv(dev);
+   uint32_t pm;
+
+   pm = readl(priv->base + REG_PM);
+
+   if ((pm >> offset) & 0x1)
+   return GPIOF_OUTPUT;
+
+   return GPIOF_INPUT;
+}
+
+static const struct dm_gpio_ops eg20t_gpio_ops = {
+   .direction_input= eg20t_gpio_direction_input,
+   .direction_output   = eg20t_gpio_direction_output,
+   .get_value  = eg20t_gpio_get_value,
+   .set_value  = eg20t_gpio_set_value,
+   .get_function   = eg20t_gpio_get_function,
+};
+
+static int eg20t_gpio_probe(struct udevice *dev)
+{
+   struct eg20t_gpio_priv *priv = dev_get_priv(dev);
+   struct gpio_dev_priv *uc_priv = dev->uclass_priv;
+
+   priv->base = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_1, PCI_REGION_MEM);
+   if (!priv->base) {
+   debug("failed to map GPIO registers\n");
+   return -EINVAL;
+   }
+
+   uc_priv->gpio_count = 12;
+   uc_priv->bank_name = "eg20t";
+   return 0;
+}
+
+U_BOOT_DRIVER(eg20t_gpio) = {
+   .name   = "eg20t-gpio",
+   .id = UCLASS_GPIO,
+   .probe  = eg20t_gpio_probe,
+   .priv_auto_alloc_size = sizeof(struct eg20t_gpio_priv),
+   .ops= _gpio_ops,

[U-Boot] [PATCH 16/23] net: pch_gbe: Support PHY reset GPIOs

2016-09-26 Thread Paul Burton
Add support to the pch_gbe driver for resetting the PHY using a GPIO
specified in the device tree. This matches the support already in Linux.

Signed-off-by: Paul Burton 

---

 drivers/net/pch_gbe.c | 29 +++--
 drivers/net/pch_gbe.h |  1 +
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/net/pch_gbe.c b/drivers/net/pch_gbe.c
index 8866f66..cc3ca8b 100644
--- a/drivers/net/pch_gbe.c
+++ b/drivers/net/pch_gbe.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pch_gbe.h"
 
 #if !defined(CONFIG_PHYLIB)
@@ -72,6 +73,14 @@ static int pch_gbe_reset(struct udevice *dev)
priv->rx_idx = 0;
priv->tx_idx = 0;
 
+   if (dm_gpio_is_valid(>gpio_phy_reset)) {
+   /* Reset the PHY */
+   dm_gpio_set_value(>gpio_phy_reset, 1);
+   udelay(15000);
+   dm_gpio_set_value(>gpio_phy_reset, 0);
+   udelay(5000);
+   }
+
writel(PCH_GBE_ALL_RST, _regs->reset);
 
/*
@@ -451,6 +460,11 @@ int pch_gbe_probe(struct udevice *dev)
plat->iobase = (ulong)iobase;
priv->mac_regs = (struct pch_gbe_regs *)iobase;
 
+   err = gpio_request_by_name(dev, "phy-reset-gpios", 0,
+  >gpio_phy_reset, GPIOD_IS_OUT);
+   if (err && (err != -ENOENT))
+   return err;
+
/* Read MAC address from SROM and initialize dev->enetaddr with it */
pch_gbe_mac_read(priv->mac_regs, plat->enetaddr);
 
@@ -460,9 +474,17 @@ int pch_gbe_probe(struct udevice *dev)
 
err = pch_gbe_reset(dev);
if (err)
-   return err;
+   goto out_err;
 
-   return pch_gbe_phy_init(dev);
+   err = pch_gbe_phy_init(dev);
+   if (err)
+   goto out_err;
+
+   return 0;
+out_err:
+   if (dm_gpio_is_valid(>gpio_phy_reset))
+   dm_gpio_free(dev, >gpio_phy_reset);
+   return err;
 }
 
 int pch_gbe_remove(struct udevice *dev)
@@ -473,6 +495,9 @@ int pch_gbe_remove(struct udevice *dev)
mdio_unregister(priv->bus);
mdio_free(priv->bus);
 
+   if (dm_gpio_is_valid(>gpio_phy_reset))
+   dm_gpio_free(dev, >gpio_phy_reset);
+
return 0;
 }
 
diff --git a/drivers/net/pch_gbe.h b/drivers/net/pch_gbe.h
index 0ea0c73..1d13380 100644
--- a/drivers/net/pch_gbe.h
+++ b/drivers/net/pch_gbe.h
@@ -293,6 +293,7 @@ struct pch_gbe_priv {
struct udevice *dev;
int rx_idx;
int tx_idx;
+   struct gpio_desc gpio_phy_reset;
 };
 
 #endif /* _PCH_GBE_H_ */
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 13/23] net: pch_gbe: Add cache maintenance

2016-09-26 Thread Paul Burton
On MIPS systems DMA isn't coherent with the CPU caches unless an IOCU is
present. When there is no IOCU we need to writeback or invalidate the
data caches at appropriate points. Perform this cache maintenance in
the pch_gbe driver which is used on the MIPS Boston development board.

Signed-off-by: Paul Burton 
---

 drivers/net/pch_gbe.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/pch_gbe.c b/drivers/net/pch_gbe.c
index 1432351..8866f66 100644
--- a/drivers/net/pch_gbe.c
+++ b/drivers/net/pch_gbe.c
@@ -120,6 +120,8 @@ static void pch_gbe_rx_descs_init(struct udevice *dev)
rx_desc[i].buffer_addr = dm_pci_virt_to_mem(priv->dev,
priv->rx_buff[i]);
 
+   flush_dcache_range((ulong)rx_desc, (ulong)_desc[PCH_GBE_DESC_NUM]);
+
writel(dm_pci_virt_to_mem(priv->dev, rx_desc),
   _regs->rx_dsc_base);
writel(sizeof(struct pch_gbe_rx_desc) * (PCH_GBE_DESC_NUM - 1),
@@ -137,6 +139,8 @@ static void pch_gbe_tx_descs_init(struct udevice *dev)
 
memset(tx_desc, 0, sizeof(struct pch_gbe_tx_desc) * PCH_GBE_DESC_NUM);
 
+   flush_dcache_range((ulong)tx_desc, (ulong)_desc[PCH_GBE_DESC_NUM]);
+
writel(dm_pci_virt_to_mem(priv->dev, tx_desc),
   _regs->tx_dsc_base);
writel(sizeof(struct pch_gbe_tx_desc) * (PCH_GBE_DESC_NUM - 1),
@@ -245,6 +249,8 @@ static int pch_gbe_send(struct udevice *dev, void *packet, 
int length)
u32 int_st;
ulong start;
 
+   flush_dcache_range((ulong)packet, (ulong)packet + length);
+
tx_head = >tx_desc[0];
tx_desc = >tx_desc[priv->tx_idx];
 
@@ -258,6 +264,8 @@ static int pch_gbe_send(struct udevice *dev, void *packet, 
int length)
tx_desc->dma_status = 0;
tx_desc->gbec_status = 0;
 
+   flush_dcache_range((ulong)tx_desc, (ulong)_desc[1]);
+
/* Test the wrap-around condition */
if (++priv->tx_idx >= PCH_GBE_DESC_NUM)
priv->tx_idx = 0;
@@ -295,8 +303,12 @@ static int pch_gbe_recv(struct udevice *dev, int flags, 
uchar **packetp)
if (virt_to_phys(rx_desc) == hw_desc)
return -EAGAIN;
 
+   /* Invalidate the descriptor */
+   invalidate_dcache_range((ulong)rx_desc, (ulong)_desc[1]);
+
length = rx_desc->rx_words_eob - 3 - ETH_FCS_LEN;
buffer = dm_pci_mem_to_virt(priv->dev, rx_desc->buffer_addr, length, 0);
+   invalidate_dcache_range((ulong)buffer, (ulong)buffer + length);
*packetp = (uchar *)buffer;
 
return length;
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 12/23] net: pch_gbe: CPU accessible addresses are virtual

2016-09-26 Thread Paul Burton
Use the virt_to_bus & bus_to_virt functions rather than phys_to_bus &
bus_to_phys, since the addresses accessed by the CPU will be virtual
rather than physical. On MIPS physical & virtual addresses differ as we
use virtual addresses in kseg0, and attempting to use physical addresses
directly caused problems as they're in the user segment which would be
mapped via the uninitialised TLB.

Signed-off-by: Paul Burton 
---

 drivers/net/pch_gbe.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/net/pch_gbe.c b/drivers/net/pch_gbe.c
index e41d737..1432351 100644
--- a/drivers/net/pch_gbe.c
+++ b/drivers/net/pch_gbe.c
@@ -120,12 +120,12 @@ static void pch_gbe_rx_descs_init(struct udevice *dev)
rx_desc[i].buffer_addr = dm_pci_virt_to_mem(priv->dev,
priv->rx_buff[i]);
 
-   writel(dm_pci_phys_to_mem(priv->dev, (ulong)rx_desc),
+   writel(dm_pci_virt_to_mem(priv->dev, rx_desc),
   _regs->rx_dsc_base);
writel(sizeof(struct pch_gbe_rx_desc) * (PCH_GBE_DESC_NUM - 1),
   _regs->rx_dsc_size);
 
-   writel(dm_pci_phys_to_mem(priv->dev, (ulong)(rx_desc + 1)),
+   writel(dm_pci_virt_to_mem(priv->dev, rx_desc + 1),
   _regs->rx_dsc_sw_p);
 }
 
@@ -137,11 +137,11 @@ static void pch_gbe_tx_descs_init(struct udevice *dev)
 
memset(tx_desc, 0, sizeof(struct pch_gbe_tx_desc) * PCH_GBE_DESC_NUM);
 
-   writel(dm_pci_phys_to_mem(priv->dev, (ulong)tx_desc),
+   writel(dm_pci_virt_to_mem(priv->dev, tx_desc),
   _regs->tx_dsc_base);
writel(sizeof(struct pch_gbe_tx_desc) * (PCH_GBE_DESC_NUM - 1),
   _regs->tx_dsc_size);
-   writel(dm_pci_phys_to_mem(priv->dev, (ulong)(tx_desc + 1)),
+   writel(dm_pci_virt_to_mem(priv->dev, tx_desc + 1),
   _regs->tx_dsc_sw_p);
 }
 
@@ -251,7 +251,7 @@ static int pch_gbe_send(struct udevice *dev, void *packet, 
int length)
if (length < 64)
frame_ctrl |= PCH_GBE_TXD_CTRL_APAD;
 
-   tx_desc->buffer_addr = dm_pci_phys_to_mem(priv->dev, (ulong)packet);
+   tx_desc->buffer_addr = dm_pci_virt_to_mem(priv->dev, packet);
tx_desc->length = length;
tx_desc->tx_words_eob = length + 3;
tx_desc->tx_frame_ctrl = frame_ctrl;
@@ -262,7 +262,7 @@ static int pch_gbe_send(struct udevice *dev, void *packet, 
int length)
if (++priv->tx_idx >= PCH_GBE_DESC_NUM)
priv->tx_idx = 0;
 
-   writel(dm_pci_phys_to_mem(priv->dev, (ulong)(tx_head + priv->tx_idx)),
+   writel(dm_pci_virt_to_mem(priv->dev, tx_head + priv->tx_idx),
   _regs->tx_dsc_sw_p);
 
start = get_timer(0);
@@ -283,7 +283,8 @@ static int pch_gbe_recv(struct udevice *dev, int flags, 
uchar **packetp)
struct pch_gbe_priv *priv = dev_get_priv(dev);
struct pch_gbe_regs *mac_regs = priv->mac_regs;
struct pch_gbe_rx_desc *rx_desc;
-   ulong hw_desc, buffer_addr, length;
+   ulong hw_desc, length;
+   void *buffer;
 
rx_desc = >rx_desc[priv->rx_idx];
 
@@ -291,12 +292,12 @@ static int pch_gbe_recv(struct udevice *dev, int flags, 
uchar **packetp)
hw_desc = readl(_regs->rx_dsc_hw_p_hld);
 
/* Just return if not receiving any packet */
-   if ((ulong)rx_desc == hw_desc)
+   if (virt_to_phys(rx_desc) == hw_desc)
return -EAGAIN;
 
-   buffer_addr = dm_pci_mem_to_phys(priv->dev, rx_desc->buffer_addr);
-   *packetp = (uchar *)buffer_addr;
length = rx_desc->rx_words_eob - 3 - ETH_FCS_LEN;
+   buffer = dm_pci_mem_to_virt(priv->dev, rx_desc->buffer_addr, length, 0);
+   *packetp = (uchar *)buffer;
 
return length;
 }
@@ -315,7 +316,7 @@ static int pch_gbe_free_pkt(struct udevice *dev, uchar 
*packet, int length)
if (++rx_swp >= PCH_GBE_DESC_NUM)
rx_swp = 0;
 
-   writel(dm_pci_phys_to_mem(priv->dev, (ulong)(rx_head + rx_swp)),
+   writel(dm_pci_virt_to_mem(priv->dev, rx_head + rx_swp),
   _regs->rx_dsc_sw_p);
 
return 0;
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 09/23] boston: Disable PCI bridge memory space alignment

2016-09-26 Thread Paul Burton
On the MIPS Boston development board we have an Intel EG20T Platform
Controller Hub connected to a Xilinx AXI to PCIe root port which is only
assigned a 1MB memory region. The Intel EG20T contains a bridge device
beneath which all of its peripheral devices can be found, and that
bridge device contains a ROM. If we align to 1MB when we encounter each
bridge device we therefore do something like this:

  - Start with bus_lower at 0x1600.

  - Find the Xilinx root bridge, which has no visible BARs so we do very
little to it.

  - Probe the bus beneath the Xilinx bridge device, aligning bus_lower
to a 1MB boundary first. That leaves it still at 0x1600.

  - Find the EG20T bridge device, which we find has a 64KiB ROM. We
assign it the address range 0x1600-0x1600 which leaves
bus_lower at 0x1601.

  - Probe the bus beneath the EG20T bridge device, aligning bus_lower to
a 1MB boundary first. This leaves bus_lower at 0x1610, which is
the end of the available memory space.

  - Find the various peripheral devices the EG20T contains, but fail to
assign any memory space to them since bus_lower is at the end of the
memory space available to the PCI bus.

Fix this by disabling that 1MB alignment, which allows all of the EG20T
peripheral devices to be assigned memory space within the 1MB region
available.

Signed-off-by: Paul Burton 

---

 configs/boston32r2_defconfig   | 1 +
 configs/boston32r2el_defconfig | 1 +
 configs/boston64r2_defconfig   | 1 +
 configs/boston64r2el_defconfig | 1 +
 4 files changed, 4 insertions(+)

diff --git a/configs/boston32r2_defconfig b/configs/boston32r2_defconfig
index ca66248..e5f61b8 100644
--- a/configs/boston32r2_defconfig
+++ b/configs/boston32r2_defconfig
@@ -36,6 +36,7 @@ CONFIG_CFI_FLASH=y
 CONFIG_DM_ETH=y
 CONFIG_PCH_GBE=y
 CONFIG_DM_PCI=y
+CONFIG_DM_PCI_BRIDGE_MEM_ALIGN=0x0
 CONFIG_PCI_XILINX=y
 CONFIG_SYS_NS16550=y
 CONFIG_LZ4=y
diff --git a/configs/boston32r2el_defconfig b/configs/boston32r2el_defconfig
index 67f54bf..e9a23b8 100644
--- a/configs/boston32r2el_defconfig
+++ b/configs/boston32r2el_defconfig
@@ -37,6 +37,7 @@ CONFIG_CFI_FLASH=y
 CONFIG_DM_ETH=y
 CONFIG_PCH_GBE=y
 CONFIG_DM_PCI=y
+CONFIG_DM_PCI_BRIDGE_MEM_ALIGN=0x0
 CONFIG_PCI_XILINX=y
 CONFIG_SYS_NS16550=y
 CONFIG_LZ4=y
diff --git a/configs/boston64r2_defconfig b/configs/boston64r2_defconfig
index 1245d1b..55943c5 100644
--- a/configs/boston64r2_defconfig
+++ b/configs/boston64r2_defconfig
@@ -36,6 +36,7 @@ CONFIG_CFI_FLASH=y
 CONFIG_DM_ETH=y
 CONFIG_PCH_GBE=y
 CONFIG_DM_PCI=y
+CONFIG_DM_PCI_BRIDGE_MEM_ALIGN=0x0
 CONFIG_PCI_XILINX=y
 CONFIG_SYS_NS16550=y
 CONFIG_LZ4=y
diff --git a/configs/boston64r2el_defconfig b/configs/boston64r2el_defconfig
index 9b5fa5a..865177d 100644
--- a/configs/boston64r2el_defconfig
+++ b/configs/boston64r2el_defconfig
@@ -37,6 +37,7 @@ CONFIG_CFI_FLASH=y
 CONFIG_DM_ETH=y
 CONFIG_PCH_GBE=y
 CONFIG_DM_PCI=y
+CONFIG_DM_PCI_BRIDGE_MEM_ALIGN=0x0
 CONFIG_PCI_XILINX=y
 CONFIG_SYS_NS16550=y
 CONFIG_LZ4=y
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 11/23] net: pch_gbe: Fix rx descriptor buffer addresses

2016-09-26 Thread Paul Burton
The loop to set up buffer addresses in rx descriptors always operated on
descriptor 0, rather than on each descriptor sequentially. Fix this in
order to setup correct buffer addresses for each descriptor.

Signed-off-by: Paul Burton 
---

 drivers/net/pch_gbe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/pch_gbe.c b/drivers/net/pch_gbe.c
index 4aac0f6..e41d737 100644
--- a/drivers/net/pch_gbe.c
+++ b/drivers/net/pch_gbe.c
@@ -117,8 +117,8 @@ static void pch_gbe_rx_descs_init(struct udevice *dev)
 
memset(rx_desc, 0, sizeof(struct pch_gbe_rx_desc) * PCH_GBE_DESC_NUM);
for (i = 0; i < PCH_GBE_DESC_NUM; i++)
-   rx_desc->buffer_addr = dm_pci_phys_to_mem(priv->dev,
-   (ulong)(priv->rx_buff[i]));
+   rx_desc[i].buffer_addr = dm_pci_virt_to_mem(priv->dev,
+   priv->rx_buff[i]);
 
writel(dm_pci_phys_to_mem(priv->dev, (ulong)rx_desc),
   _regs->rx_dsc_base);
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 10/23] net: pch_gbe: Reset during probe

2016-09-26 Thread Paul Burton
Using the EG20T gigabit ethernet controller on the MIPS Boston board, we
find that we have to reset the controller in order for the RGMII link to
the PHY to become functional. Without doing so we constantly time out in
pch_gbe_mdio_ready.

Signed-off-by: Paul Burton 
---

 drivers/net/pch_gbe.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/pch_gbe.c b/drivers/net/pch_gbe.c
index d40fff0..4aac0f6 100644
--- a/drivers/net/pch_gbe.c
+++ b/drivers/net/pch_gbe.c
@@ -422,6 +422,7 @@ int pch_gbe_probe(struct udevice *dev)
struct pch_gbe_priv *priv;
struct eth_pdata *plat = dev_get_platdata(dev);
void *iobase;
+   int err;
 
/*
 * The priv structure contains the descriptors and frame buffers which
@@ -444,6 +445,10 @@ int pch_gbe_probe(struct udevice *dev)
pch_gbe_mdio_init(dev->name, priv->mac_regs);
priv->bus = miiphy_get_dev_by_name(dev->name);
 
+   err = pch_gbe_reset(dev);
+   if (err)
+   return err;
+
return pch_gbe_phy_init(dev);
 }
 
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 08/23] pci: Make PCI bridge memory alignment configurable

2016-09-26 Thread Paul Burton
On some systems aligning PCI memory to a 1MB boundary every time a
bridge is encountered may lead to exhausting the available memory space
before all devices have been assigned addresses.

For example on the MIPS Boston development board we have an Intel EG20T
Platform Controller Hub connected to a Xilinx AXI to PCIe root port
which is only assigned a 1MB memory region. The Intel EG20T contains a
bridge device beneath which all of its peripheral devices can be found,
and that bridge device contains a ROM. If we align to 1MB when we
encounter each bridge device we therefore do something like this:

  - Start with bus_lower at 0x1600.

  - Find the Xilinx root bridge, which has no visible BARs so we do very
little to it.

  - Probe the bus beneath the Xilinx bridge device, aligning bus_lower
to a 1MB boundary first. That leaves it still at 0x1600.

  - Find the EG20T bridge device, which we find has a 64KiB ROM. We
assign it the address range 0x1600-0x1600 which leaves
bus_lower at 0x1601.

  - Probe the bus beneath the EG20T bridge device, aligning bus_lower to
a 1MB boundary first. This leaves bus_lower at 0x1610, which is
the end of the available memory space.

  - Find the various peripheral devices the EG20T contains, but fail to
assign any memory space to them since bus_lower is at the end of the
memory space available to the PCI bus.

This patch allows that 1MB alignment to be changed or disabled via
Kconfig, so that systems such as this can select an alignment which
works for them.

Signed-off-by: Paul Burton 

---

 drivers/pci/Kconfig|  7 +++
 drivers/pci/pci_auto.c | 24 
 2 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 9a7c187..35bf8fe 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -18,6 +18,13 @@ config DM_PCI_COMPAT
  measure when porting a board to use driver model for PCI. Once the
  board is fully supported, this option should be disabled.
 
+config DM_PCI_BRIDGE_MEM_ALIGN
+   hex "PCI bridge memory alignment"
+   default 0x10
+   help
+ PCI memory space will be aligned to be a multiple of this value
+ whenever a PCI-to-PCI bridge is encountered.
+
 config PCI_SANDBOX
bool "Sandbox PCI support"
depends on SANDBOX && DM_PCI
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index ee9a854..0326316 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -186,8 +186,10 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, 
int sub_bus)
dm_pci_write_config8(dev, PCI_SUBORDINATE_BUS, 0xff);
 
if (pci_mem) {
-   /* Round memory allocator to 1MB boundary */
-   pciauto_region_align(pci_mem, 0x10);
+   /* Round memory allocator to a suitable boundary */
+   if (CONFIG_DM_PCI_BRIDGE_MEM_ALIGN)
+   pciauto_region_align(pci_mem,
+CONFIG_DM_PCI_BRIDGE_MEM_ALIGN);
 
/*
 * Set up memory and I/O filter limits, assume 32-bit
@@ -200,8 +202,10 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev, 
int sub_bus)
}
 
if (pci_prefetch) {
-   /* Round memory allocator to 1MB boundary */
-   pciauto_region_align(pci_prefetch, 0x10);
+   /* Round memory allocator to a suitable boundary */
+   if (CONFIG_DM_PCI_BRIDGE_MEM_ALIGN)
+   pciauto_region_align(pci_prefetch,
+CONFIG_DM_PCI_BRIDGE_MEM_ALIGN);
 
/*
 * Set up memory and I/O filter limits, assume 32-bit
@@ -260,8 +264,10 @@ void dm_pciauto_postscan_setup_bridge(struct udevice *dev, 
int sub_bus)
dm_pci_write_config8(dev, PCI_SUBORDINATE_BUS, sub_bus);
 
if (pci_mem) {
-   /* Round memory allocator to 1MB boundary */
-   pciauto_region_align(pci_mem, 0x10);
+   /* Round memory allocator to a suitable boundary */
+   if (CONFIG_DM_PCI_BRIDGE_MEM_ALIGN)
+   pciauto_region_align(pci_mem,
+CONFIG_DM_PCI_BRIDGE_MEM_ALIGN);
 
dm_pci_write_config16(dev, PCI_MEMORY_LIMIT,
  (pci_mem->bus_lower - 1) >> 16);
@@ -274,8 +280,10 @@ void dm_pciauto_postscan_setup_bridge(struct udevice *dev, 
int sub_bus)
 _64);
prefechable_64 &= PCI_PREF_RANGE_TYPE_MASK;
 
-   /* Round memory allocator to 1MB boundary */
-   pciauto_region_align(pci_prefetch, 0x10);
+   /* Round memory allocator to a suitable boundary */
+   if (CONFIG_DM_PCI_BRIDGE_MEM_ALIGN)
+   

[U-Boot] [PATCH 07/23] pci: Handle MIPS systems with virtual CONFIG_SYS_SDRAM_BASE

2016-09-26 Thread Paul Burton
The decode_regions() function in the PCI code presumes that
CONFIG_SYS_SDRAM_BASE is a physical address, which seems reasonable
given that README states that it should be.

However there is also common code which expects CONFIG_SYS_SDRAM_BASE to
be an address accessible by the CPU, ie. a valid virtual address -
notably gd->ram_top is set to it & various pieces of data are located
relative to that, and getenv_bootm_low() defaults to
CONFIG_SYS_SDRAM_BASE as the lower bound on addresses to load into. Thus
on MIPS CONFIG_SYS_SDRAM_BASE is a virtual address.

This patch takes the simple approach to fixing this & converts
CONFIG_SYS_SDRAM_BASE to a physical address for use by the PCI code when
built for MIPS.

Signed-off-by: Paul Burton 

---

 drivers/pci/pci-uclass.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 415c632..26fe0f4 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -848,7 +848,9 @@ static int decode_regions(struct pci_controller *hose, 
const void *blob,
 
/* Add a region for our local memory */
size = gd->ram_size;
-#ifdef CONFIG_SYS_SDRAM_BASE
+#if defined(CONFIG_MIPS)
+   base = virt_to_phys((void *)CONFIG_SYS_SDRAM_BASE);
+#elif defined(CONFIG_SYS_SDRAM_BASE)
base = CONFIG_SYS_SDRAM_BASE;
 #endif
if (gd->pci_ram_top && gd->pci_ram_top < base + size)
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 06/23] pci: Set of_offset for devices not probed via DT compatible strings

2016-09-26 Thread Paul Burton
A PCI device may be probed through standard PCI config space probing but
still be represented in a device tree. However U-Boot would not
previously set the of_offset field of the struct udevice for such PCI
devices. Fix this by searching for a DT node based upon its "reg"
property after binding a PCI device that wasn't already seen in the DT.

Signed-off-by: Paul Burton 

---

 drivers/pci/pci-uclass.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 3b00e6a..415c632 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -670,6 +670,33 @@ error:
return ret;
 }
 
+static int find_pci_of_offset(struct udevice *bus, struct udevice *dev,
+ pci_dev_t bdf)
+{
+   struct fdt_pci_addr addr;
+   int offset, err;
+
+   if (bus->of_offset == -1)
+   return -ENOENT;
+
+   fdt_for_each_subnode(gd->fdt_blob, offset, bus->of_offset) {
+   err = fdtdec_get_pci_addr(gd->fdt_blob, offset,
+ FDT_PCI_SPACE_CONFIG, "reg", );
+   if (err == -ENOENT)
+   continue;
+   if (err)
+   return err;
+
+   if (bdf != (addr.phys_hi & 0x00))
+   continue;
+
+   dev->of_offset = offset;
+   return 0;
+   }
+
+   return -ENOENT;
+}
+
 int pci_bind_bus_devices(struct udevice *bus)
 {
ulong vendor, device;
@@ -731,6 +758,11 @@ int pci_bind_bus_devices(struct udevice *bus)
}
ret = pci_find_and_bind_driver(bus, _id, bdf,
   );
+   if (!ret) {
+   ret = find_pci_of_offset(bus, dev, bdf);
+   if (ret == -ENOENT)
+   ret = 0;
+   }
}
if (ret == -EPERM)
continue;
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH 05/23] pci: xilinx: Avoid writing memory base or limit registers

2016-09-26 Thread Paul Burton
Writing the PCI memory base & limit registers leads to the root bridge
reporting a PCI_MEMORY_BASE value of 0 & a PCI_MEMORY_LIMIT value of
0x1600. If we then boot Linux, it sees that the bridge device needs
0x1600 bytes of memory space & fails to assign it.

It's unclear to me why this happens, and poking values from the shell
doesn't seem to make anything clearer, but this workaround allows a MIPS
Boston board to boot Linux & let Linux successfully probe the PCIe bus &
all devices connected to it.

Signed-off-by: Paul Burton 
---

 drivers/pci/pcie_xilinx.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/pci/pcie_xilinx.c b/drivers/pci/pcie_xilinx.c
index 9059c41..0237bec 100644
--- a/drivers/pci/pcie_xilinx.c
+++ b/drivers/pci/pcie_xilinx.c
@@ -160,6 +160,15 @@ static int pcie_xilinx_write_config(struct udevice *bus, 
pci_dev_t bdf,
if (err < 0)
return 0;
 
+   if (bdf == PCI_BDF(bus->seq, 0, 0)) {
+   switch (offset) {
+   case PCI_MEMORY_BASE:
+   case PCI_MEMORY_LIMIT:
+   /* Writing the memory base or limit causes problems */
+   return 0;
+   }
+   }
+
switch (size) {
case PCI_SIZE_8:
__raw_writeb(value, address);
-- 
2.10.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


  1   2   3   >