from:"Przemyslaw Marczak"




On 09/15/2016 12:34 PM, Keerthy wrote:



On Thursday 15 September 2016 03:04 PM, Przemyslaw Marczak wrote:

Hello Keerthy,

On 09/15/2016 10:25 AM, Keerthy wrote:

Add support for gpio regulators. As of now this driver caters
to gpio regulators with one gpio. Supports setting voltage values to 
gpio

regulators and retrieving the values.

Signed-off-by: Keerthy <j-keer...@ti.com>
---
  drivers/power/regulator/Kconfig  |   8 ++
  drivers/power/regulator/Makefile |   1 +
  drivers/power/regulator/gpio-regulator.c | 136
+++
  include/power/regulator.h|   1 +
  4 files changed, 146 insertions(+)
  create mode 100644 drivers/power/regulator/gpio-regulator.c

diff --git a/drivers/power/regulator/Kconfig
b/drivers/power/regulator/Kconfig
index 2510474..4776011 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -58,6 +58,14 @@ config DM_REGULATOR_FIXED
  features for fixed value regulators. The driver implements
get/set api
  for enable and get only for voltage value.
  +config DM_REGULATOR_GPIO
+bool "Enable Driver Model for GPIO REGULATOR"
+depends on DM_REGULATOR
+---help---
+This config enables implementation of driver-model regulator 
uclass

+features for gpio regulators. The driver implements get/set for
+voltage value.
+
  config REGULATOR_RK808
  bool "Enable driver for RK808 regulators"
  depends on DM_REGULATOR && PMIC_RK808
diff --git a/drivers/power/regulator/Makefile
b/drivers/power/regulator/Makefile
index 2093048..2d350cb 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
  obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
  obj-$(CONFIG_DM_REGULATOR_PFUZE100) += pfuze100.o
  obj-$(CONFIG_$(SPL_)DM_REGULATOR_FIXED) += fixed.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_GPIO) += gpio-regulator.o
  obj-$(CONFIG_REGULATOR_RK808) += rk808.o
  obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
  obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
diff --git a/drivers/power/regulator/gpio-regulator.c
b/drivers/power/regulator/gpio-regulator.c
new file mode 100644
index 000..9c8832e
--- /dev/null
+++ b/drivers/power/regulator/gpio-regulator.c
@@ -0,0 +1,136 @@
+/*
+ * (C) Copyright 2016 Texas Instruments Incorporated, 
+ * Keerthy <j-keer...@ti.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct gpio_regulator_platdata {
+struct gpio_desc gpio; /* GPIO for regulator voltage control */
+int gpio_low_uV;
+int gpio_high_uV;
+};


The low/high values can be provided by regulator's uclass driver in
struct of type "dm_regulator_uclass_platdata", as for other regulators.


min_uV, max_uV represent the minimum and maximum voltages in 
dm_regulator_uclass_platdata. I would not use them here.




Ah right, sorry I just get wrong the name of those variables above - as 
min/max uV, but your point was about the GPIO lo/hi state.




But as I can see in the Linux, this driver should provide a structure
for the gpio states.


Yes so i am keeping the voltage values for 0 and 1 states in a driver 
specific struct.





+
+static int gpio_regulator_ofdata_to_platdata(struct udevice *dev)
+{
+struct dm_regulator_uclass_platdata *uc_pdata;
+struct gpio_regulator_platdata *dev_pdata;
+struct gpio_desc *gpio;
+const void *blob = gd->fdt_blob;
+int node = dev->of_offset;
+int ret, count, i;
+u32 states_array[8];
+
+dev_pdata = dev_get_platdata(dev);
+uc_pdata = dev_get_uclass_platdata(dev);
+if (!uc_pdata)
+return -ENXIO;
+
+/* Set type to gpio */
+uc_pdata->type = REGULATOR_TYPE_GPIO;
+
+/*
+ * Get gpio regulator gpio desc
+ * Assuming one GPIO per regulator.
+ * Can be extended later to multiple GPIOs
+ * per gpio-regulator. As of now no instance with multiple
+ * gpios is presnt
+ */
+gpio = _pdata->gpio;
+ret = gpio_request_by_name(dev, "gpios", 0, gpio, GPIOD_IS_OUT);
+if (ret)
+debug("regulator gpio - not found! Error: %d", ret);
+
+count = fdtdec_get_int_array_count(blob, node, "states",
+   states_array, 8);
+
+if (!count)
+return -EINVAL;
+
+for (i = 0; i < count; i += 2) {

The below condition is valid for most devices.

In Linux we can find dts for some ARMs in which I can find at least two
boards,
with inverted meaning of state/voltage, so "0", can be also valid for
the high uV.

I think, this driver should keep possible states in platdata.


Okay. I get the point. So i will have both states and corresponding 
states voltages stored in gpio_regulator_platdata structure and set 
states corresponding to r

Re: [U-Boot] [PATCH] power: regulator: Add limits checking while setting voltage and current


Hello Keerthy,

On 09/15/2016 10:54 AM, Keerthy wrote:

Currently the specific set ops functions are directly
called without any check for voltage/current limits for a regulator.
Check for them and proceed.

Signed-off-by: Keerthy <j-keer...@ti.com>
---
  drivers/power/regulator/regulator-uclass.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/power/regulator/regulator-uclass.c 
b/drivers/power/regulator/regulator-uclass.c
index 4434e36..089455e 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -41,6 +41,11 @@ int regulator_get_value(struct udevice *dev)
  int regulator_set_value(struct udevice *dev, int uV)
  {
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+   struct dm_regulator_uclass_platdata *uc_pdata;
+
+   uc_pdata = dev_get_uclass_platdata(dev);
+   if (uV < uc_pdata->min_uV || uV > uc_pdata->max_uV)
+   return -EINVAL;
  
  	if (!ops || !ops->set_value)

return -ENOSYS;
@@ -61,6 +66,11 @@ int regulator_get_current(struct udevice *dev)
  int regulator_set_current(struct udevice *dev, int uA)
  {
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+   struct dm_regulator_uclass_platdata *uc_pdata;
+
+   uc_pdata = dev_get_uclass_platdata(dev);
+   if (uA < uc_pdata->min_uA || uA > uc_pdata->max_uA)
+   return -EINVAL;
  
  	if (!ops || !ops->set_current)

return -ENOSYS;


Adding those two checks will conflict with "force" option for 
cmd/regulator.c:283.
There was value range checking in the command's code, but it was left 
unchecked

for regulator direct calls.

This change is good, but then maybe the "force" option should be removed 
from command,

or API's prototypes should be updated by force flag argument?

I assumed that this option could be useful for quick over-voltage 
setting (until reboot),
since usually (min_uV == max_uV) - the voltage can't be changed in any 
range.


The driver should take care about ignore it or not, however probably 
nobody used this.


Of course this could potentially damage the device by wrong use,
which can be also made by passing the force flag as an argument - by 
mistake.


What do you thing about, update the dm_regulator_ops by:

 - int (*set_value)(struct udevice *dev, int uV, int flag);
 - int (*set_current)(struct udevice *dev, int uA, int flag);

and also new flag to the present defined:

 - REGULATOR_FLAG_FORCE = 1 << 2

This requires more work, but will provide the functionality in a proper way.

Best regards,

--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com

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

Re: [U-Boot] [PATCH] power: regulator: Add support for gpio regulators

;gpio.dev)
+   return -ENOSYS;
+
+   uc_pdata = dev_get_uclass_platdata(dev);
+   if (uc_pdata->min_uV > uc_pdata->max_uV) {
+   debug("Invalid constraints for: %s\n", uc_pdata->name);
+   return -EINVAL;
+   }
+
+   enable = dm_gpio_get_value(_pdata->gpio);
The returned value (enable) should be compared to the states kept in 
platdata.



+   if (enable)
+   return dev_pdata->gpio_high_uV;
+   else
+   return dev_pdata->gpio_low_uV;
+}
+
+static int gpio_regulator_set_value(struct udevice *dev, int uV)
+{
+   struct gpio_regulator_platdata *dev_pdata = dev_get_platdata(dev);
+   int ret;
+   bool enable;
+
+   if (!dev_pdata->gpio.dev)
+   return -ENOSYS;
+
+   if (uV == dev_pdata->gpio_high_uV)
+   enable = 1;
+   else if (uV == dev_pdata->gpio_low_uV)
+   enable = 0;
+   else
+   return -EINVAL;
+


And also here you should get the "enable" value from states kept in 
platdata.



+   ret = dm_gpio_set_value(_pdata->gpio, enable);
+   if (ret) {
+   error("Can't set regulator : %s gpio to: %d\n", dev->name,
+ enable);
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct dm_regulator_ops gpio_regulator_ops = {
+   .get_value  = gpio_regulator_get_value,
+   .set_value  = gpio_regulator_set_value,
+};
+
+static const struct udevice_id gpio_regulator_ids[] = {
+   { .compatible = "regulator-gpio" },
+   { },
+};
+
+U_BOOT_DRIVER(gpio_regulator) = {
+   .name = "gpio regulator",
+   .id = UCLASS_REGULATOR,
+   .ops = _regulator_ops,
+   .of_match = gpio_regulator_ids,
+   .ofdata_to_platdata = gpio_regulator_ofdata_to_platdata,
+   .platdata_auto_alloc_size = sizeof(struct gpio_regulator_platdata),
+};
diff --git a/include/power/regulator.h b/include/power/regulator.h
index 8ae6b14..5d327e6 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -108,6 +108,7 @@ enum regulator_type {
REGULATOR_TYPE_BUCK,
REGULATOR_TYPE_DVS,
REGULATOR_TYPE_FIXED,
+   REGULATOR_TYPE_GPIO,
REGULATOR_TYPE_OTHER,
  };
  


Best regards,

--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com

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

Re: [U-Boot] [PATCH v3 3/5] regulator: fixed: honour optionality of enable gpio


Hello Marcel,

On 09/15/2016 09:27 AM, Marcel Ziswiler wrote:

According to the binding documentation the fixed regulator enable GPIO
is optional. However so far registration thereof failed if no enable
GPIO was specified. Fix this by making it entirely optional whether an
enable GPIO is used.

Signed-off-by: Marcel Ziswiler <marcel.ziswi...@toradex.com>

---

Changes in v3:
- Introduce new patch to honour optionality of fixed regulator enable
   GPIO.

Changes in v2: None

  drivers/power/regulator/fixed.c | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/power/regulator/fixed.c b/drivers/power/regulator/fixed.c
index 37b8400..c68da70 100644
--- a/drivers/power/regulator/fixed.c
+++ b/drivers/power/regulator/fixed.c
@@ -37,11 +37,12 @@ static int fixed_regulator_ofdata_to_platdata(struct 
udevice *dev)
/* Set type to fixed */
uc_pdata->type = REGULATOR_TYPE_FIXED;
  
-	/* Get fixed regulator gpio desc */

+   /* Get fixed regulator optional enable GPIO desc */
gpio = _pdata->gpio;
ret = gpio_request_by_name(dev, "gpio", 0, gpio, GPIOD_IS_OUT);
if (ret)
-   debug("Fixed regulator gpio - not found! Error: %d", ret);
+   debug("Fixed reg optional enable GPIO - not found! Error: %d",
+ ret);


The "reg" is usually threated as a "register", so full word is better here.

  
  	/* Get optional ramp up delay */

dev_pdata->startup_delay_us = fdtdec_get_uint(gd->fdt_blob,
@@ -87,8 +88,9 @@ static bool fixed_regulator_get_enable(struct udevice *dev)
  {
struct fixed_regulator_platdata *dev_pdata = dev_get_platdata(dev);
  
+	/* Enable GPIO is optional */

if (!dev_pdata->gpio.dev)
-   return false;
+   return true;


That is good fix :)

  
  	return dm_gpio_get_value(_pdata->gpio);

  }
@@ -98,8 +100,9 @@ static int fixed_regulator_set_enable(struct udevice *dev, 
bool enable)
struct fixed_regulator_platdata *dev_pdata = dev_get_platdata(dev);
int ret;
  
+	/* Enable GPIO is optional */

if (!dev_pdata->gpio.dev)
-   return -ENOSYS;
+   return 0;
  
  	ret = dm_gpio_set_value(_pdata->gpio, enable);

if (ret) {


I don't think, that returning the 0 (success) is a good idea.

We should return some error value, because this is checked
by the regulator's command code.

User can be informed about what was happened - instead of getting
command succeed - but without any results behind the command.

Maybe the -ENOSYS is not the best here. What about -EPERM?

We could assume, that such operation is not permitted for this device.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] power: regulator: Add ctrl_reg and volt_reg fields for pmic


Hello Keerthy,

On 09/14/2016 10:24 AM, Keerthy wrote:

Hi Marczak,

On Wednesday 14 September 2016 01:33 PM, Przemyslaw Marczak wrote:

Hello Keerthy,

On 09/14/2016 06:28 AM, Keerthy wrote:

The ctrl reg contains bit fields to enable and disable regulators,
and volt_reg has the bit fields to configure the voltage values.
The registers are frequently accessed hence make them part
of dm_regulator_uclass_platdata structure.

Signed-off-by: Keerthy <j-keer...@ti.com>
---
  include/power/regulator.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/include/power/regulator.h b/include/power/regulator.h
index 9bcd728..57b14a3 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -171,6 +171,8 @@ struct dm_regulator_uclass_platdata {
  bool boot_on;
  const char *name;
  int flags;
+u8 ctrl_reg;
+u8 volt_reg;
  };
/* Regulator device operations */


This structure above is used for some common "high-level" data, which
can be used by regulator uclass driver.

Even if most of PMICs has some ctrl/volt/etc regs, the regulator uclass
driver doesn't know, how to use it, so from this point of view it is
useless.

But, you can keep device/driver data in a proper fields. Please look at
those files:

drivers/power/regulator/fixed.c:119
drivers/power/regulator/pfuze100.c:567

To store some device internal data, you can use:
.platdata_auto_alloc_size -> with access by dev_get_platdata()
.priv_auto_alloc_size -> with access by dev_get_priv()


Thanks for a quick review. I did look at some of those options before 
introducing volt and ctrl here.


Many PMICs will have ctrl/volt registers we might end up having lot of 
private strutures with the same ctrl/volt fields. I agree uclass 
driver will not know how to use it.


If i have to draw parallels from the kernel world regulator_desc is a 
common structure which hosts vsel_reg/enable_reg fields.


Isn't it better to have a common structure instead of having a some 
platform specific structure that might have the same fields?


Let me know your thoughts on this.



Best regards,






You are right and I agree with you that make things common is a good 
approach.


At the begin of introducing this framework, I just wanted to provide a 
simple user interface for regulators, so I didn't tried to put all 
common things into a single structure, because not always it could be 
useful.


The present structure layout seems to be a good representation of 
regulator's node in the device-tree.


In the other hand, each driver can provide a static arrays with proper 
data like reg/mask/etc,

the driver:
drivers/power/regulator/s5m8767.c- is a good example.

I'm not going to break your solution, but let's wait for Simon's opinion.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com

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

Re: [U-Boot] [PATCH 1/5] power: regulator: Add ctrl_reg and volt_reg fields for pmic

2016-09-14 Thread Przemyslaw Marczak


Hello Keerthy,

On 09/14/2016 06:28 AM, Keerthy wrote:

The ctrl reg contains bit fields to enable and disable regulators,
and volt_reg has the bit fields to configure the voltage values.
The registers are frequently accessed hence make them part
of dm_regulator_uclass_platdata structure.

Signed-off-by: Keerthy <j-keer...@ti.com>
---
  include/power/regulator.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/include/power/regulator.h b/include/power/regulator.h
index 9bcd728..57b14a3 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -171,6 +171,8 @@ struct dm_regulator_uclass_platdata {
bool boot_on;
const char *name;
int flags;
+   u8 ctrl_reg;
+   u8 volt_reg;
  };
  
  /* Regulator device operations */


This structure above is used for some common "high-level" data, which 
can be used by regulator uclass driver.


Even if most of PMICs has some ctrl/volt/etc regs, the regulator uclass 
driver doesn't know, how to use it, so from this point of view it is 
useless.


But, you can keep device/driver data in a proper fields. Please look at 
those files:


drivers/power/regulator/fixed.c:119
drivers/power/regulator/pfuze100.c:567

To store some device internal data, you can use:
.platdata_auto_alloc_size -> with access by dev_get_platdata()
.priv_auto_alloc_size -> with access by dev_get_priv()

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Do not report bad cell count when #size-cells = <0>

2016-04-14 Thread Przemyslaw Marczak


Hello Michal,

+CC Stephen Warren

On 04/14/2016 08:20 AM, Michal Simek wrote:

Upcomming pca953x gpio driver (tca6416 is compatible with it)
is using for example this DT description (ZynqMP zcu102):
i2c0: i2c@ff02 {
compatible = "cdns,i2c-r1p10";
interrupt-parent = <>;
interrupts = <0 17 4>;
reg = <0x0 0xff02 0x1000>;
#address-cells = <1>;
#size-cells = <0>;

tca6416_u61: gpio@21 {
compatible = "ti,tca6416";
reg = <0x21>;
gpio-controller;
#gpio-cells = <2>;
};
};

I2C bus is using #size-cells = <0> which current code detects as
"Bad cell count":
OF: reached root node
OF: ** translation for device gpio@20 **
__of_translate_address: Bad cell count for gpio@20
Command 'gpio' failed: Error -19

This patch fixes OF_CHECK_COUNTS macro not to report problem when
size-cells is 0 which is also valid bus configuration.

Signed-off-by: Michal Simek <michal.si...@xilinx.com>
---

  common/fdt_support.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index ced119e70d9f..5f5b49c6210b 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -941,7 +941,7 @@ void fdt_del_node_and_alias(void *blob, const char *alias)
  #define OF_MAX_ADDR_CELLS 4
  #define OF_BAD_ADDR   FDT_ADDR_T_NONE
  #define OF_CHECK_COUNTS(na, ns)   ((na) > 0 && (na) <= OF_MAX_ADDR_CELLS 
&& \
-   (ns) > 0)
+   (ns) >= 0)

  /* Debug utility */
  #ifdef DEBUG



Some time ago I tried to solve GPIO issue on Exynos boards, by proposing 
change similar to your patch. After some discussion with Stephen Warren 
and Simon Glass, I was aware, that it was a wrong approach to solve this 
problem.


You can follow it here:

http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/247651

https://patchwork.ozlabs.org/patch/564246/
https://patchwork.ozlabs.org/patch/557008/
https://patchwork.ozlabs.org/patch/557010/
https://patchwork.ozlabs.org/patch/557009/

As a conclusion, for MMIO addresses we are using 'reg' property with a 
range. If you need use this as I2C address or I2C device's register - 
e.g. 'reg = <0x4>' - it's good until you don't use dev_get_addr() 
function to get it - because it's a different address space - non-MMIO.


I didn't saw your GPIO driver, but I can assume, that you should use 
fdtdec_get_int() to get the GPIO register addres instead of dev_get_addr().


Please look at function i2c_chip_ofdata_to_platdata() in i2c-uclass.c, 
the reg is taken by using fdtdec_get_int()...


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] odroid: Update README with correct firmware link and XU4 support

2016-04-08 Thread Przemyslaw Marczak


Hello Shawn,

On 04/08/2016 05:06 AM, Shawn Guo wrote:

The firmware from link [1] only works with U-Boot image that is no
bigger than 328KiB.  Using it with the default mainline U-Boot today
which is already around 500KiB is just not working.  Correct the link
to be hardkernel_1mb_uboot one [2], so that users can get mainline
U-Boot work out of box.

While at it, the README is updated to include XU4 support, like DTB file
name.

[1] 
https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel
[2] 
https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel_1mb_uboot

Signed-off-by: Shawn Guo <shawn...@kernel.org>
---
  doc/README.odroid | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/doc/README.odroid b/doc/README.odroid
index ef243d1bde36..c088ec4cb08f 100644
--- a/doc/README.odroid
+++ b/doc/README.odroid
@@ -1,11 +1,11 @@
- U-Boot for Odroid X2/U3/XU3
+ U-Boot for Odroid X2/U3/XU3/XU4
  

  1. Summary
  ==
  This is a quick instruction for setup Odroid boards.
  Board config: odroid_config for X2/U3
-Board config: odroid-xu3_config for XU3
+Board config: odroid-xu3_config for XU3/XU4

  2. Supported devices
  
@@ -14,6 +14,7 @@ This U-BOOT config can be used on three boards:
  - Odroid X2
  with CPU Exynos 4412 rev 2.0 and 2GB of RAM
  - Odroid XU3
+- Odroid XU4
  with CPU Exynos5422 and 2GB of RAM

  3. Boot sequence
@@ -29,9 +30,9 @@ 
http://dev.odroid.com/projects/4412boot/wiki/FrontPage?action=download=boo
  or here:
  http://odroid.in/guides/ubuntu-lfs/boot.tar.gz

-<< XU3 >>
+<< XU3/XU4 >>
  It can be downloaded from:
-https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel
+https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel_1mb_uboot


  4. Boot media layout
@@ -120,6 +121,7 @@ Supported fdt files are:
  - exynos4412-odroidx2.dtb
  - exynos4412-odroidu3.dtb
  - exynos5422-odroidxu3.dtb
+- exynos5422-odroidxu4.dtb

  Supported kernel files are:
  - Image.itb



Thank you for correcting this.

Acked-by: Przemyslaw Marczak <p.marc...@samsung.com>

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Mainline u-boot installation on Odroid-UX4

2016-04-07 Thread Przemyslaw Marczak


Hello Shawn,

On 04/07/2016 03:59 PM, Shawn Guo wrote:

On Thu, Apr 07, 2016 at 12:20:06PM +0200, Przemyslaw Marczak wrote:

There were two variants of boot chain with U-Boot for XU3/XU4, which
differs in U-Boot size - originally U-Boot was 328K, but for the
mainline we assume 1MB of size.

So for mainline, you need a prober version of BL2, which loads 1MB
of U-Boot instead of 328K - in other way, the mainline U-Boot will
be overwritten by tzsw and env.

Please use the resources from this site:
https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel_1mb_uboot


Thanks much, Przemyslaw.  It works now.

I think we should update README.odroid a bit to ease future users.  Do
you prefer something like the patch below, or we simply replace the
existing link with hardkernel_1mb_uboot one, considering the default
U-Boot image today is already bigger than 328KB anyway?

Shawn



Good point, it wasn't updated for a long time. Yes, useful U-Boot's size 
is much bigger than 328k, so you can just, replace the link.



---8<

diff --git a/doc/README.odroid b/doc/README.odroid
index ef243d1bde36..f0d1aa98542f 100644
--- a/doc/README.odroid
+++ b/doc/README.odroid
@@ -33,6 +33,10 @@ http://odroid.in/guides/ubuntu-lfs/boot.tar.gz
  It can be downloaded from:
  
https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel

+If U-Boot image is bigger than 328KB, the following binaries should be
+used instead.
+https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel_1mb_uboot
+

  4. Boot media layout
  





It would be nice if you could update the supported fdt files list at 
line 25 of doc/README.odroid - with file: exynos5422-odroidxu4.dtb, 
mentioned by Anand Moon.


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Mainline u-boot installation on Odroid-UX4

2016-04-07 Thread Przemyslaw Marczak


Hello Shawn.

On 04/07/2016 11:35 AM, Shawn Guo wrote:

Hi Przemyslaw, Anand,

I just got a Odroid-UX4 board to play.  I installed firmware (bl1, bl2,
tzsw, u-boot) from hardkernel using sd_fusing.sh, and the board boots
fine.  But when I install mainline u-boot v2016.03 by following
doc/README.odroid, the board refuses to boot with nothing appearing on
serial console.

Here is what I did:

  - make odroid-xu3_defconfig
  - make (using arm-linux-gnueabi-gcc 4.7.3)
  - copy u-boot.bin (which is same as u-boot-dtb.bin in v2016.03 release)
to sd_fuse/hardkernel folder, and modify sd_fusing.sh to get it point
to this new U-Boot
  - ./sd_fusing.sh /dev/sdX to flash the SD card


We can assume, that the aboce steps are ok.



One thing I'm not sure is the offset that firmware should be installed
to SD card.  The doc/README.odroid and hardkernel sd_fusing.sh tells
different ones.

doc/README.odroid:

  -
|  Binary   | Block offset| part type |
|   name| SD   | eMMC |(eMMC only)|
  -
| Bl1   | 1| 0|  1 (boot) |
| Bl2   | 31   | 30   |  1 (boot) |
| U-Boot| 63   | 62   |  1 (boot) |
| Tzsw  | 2111 | 2110 |  1 (boot) |
| Uboot Env | 2560 | 2560 |  0 (user) |
  -

sd_fusing.sh:

signed_bl1_position=1
bl2_position=31
uboot_position=63
tzsw_position=719
env_position=1231

I tried both sets, and neither works for me.

I know Odroid-UX4 is supported by mainline U-Boot today, so there must
be something missing from my setup.  Could you please help me here?
Thanks.

Shawn




There were two variants of boot chain with U-Boot for XU3/XU4, which 
differs in U-Boot size - originally U-Boot was 328K, but for the 
mainline we assume 1MB of size.


So for mainline, you need a prober version of BL2, which loads 1MB of 
U-Boot instead of 328K - in other way, the mainline U-Boot will be 
overwritten by tzsw and env.


Please use the resources from this site:
https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel_1mb_uboot

In sd_fuse.1M.sh, you can see, that for U-Boot area we have: 2111-63 == 
2048blk == 1MB.


And of course change the U-Boot to mainline.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: __of_translate_address(): check parent's 'ranges' before translate

2016-02-02 Thread Przemyslaw Marczak


Hello,

On 01/29/2016 07:23 PM, Simon Glass wrote:

Hi Przymyslaw,

On 15 January 2016 at 09:35, Stephen Warren <swar...@wwwdotorg.org> wrote:

On 01/15/2016 03:41 AM, Przemyslaw Marczak wrote:


Hello Simon,

On 01/14/2016 06:17 PM, Simon Glass wrote:


Hi Przemyslaw, Stephen,

On 13 January 2016 at 04:10, Przemyslaw Marczak
<p.marc...@samsung.com> wrote:


Hello Stephen,


On 01/12/2016 05:43 PM, Stephen Warren wrote:



On 01/12/2016 03:25 AM, Przemyslaw Marczak wrote:



Hello Stephen,

On 01/11/2016 05:47 PM, Stephen Warren wrote:



On 01/11/2016 04:21 AM, Przemyslaw Marczak wrote:



Hello Stephen,

On 01/07/2016 07:25 PM, Stephen Warren wrote:



On 01/07/2016 04:40 AM, Przemyslaw Marczak wrote:



The present implementation of __of_translate_address() taken
from the Linux, is designed for translate bus/child address
mappings by using 'ranges' property - and it doesn't allow
for checking an address for a device's node with zero size-cells.

The 'size-cells > 0' is required for bus/child address mapping,
but is not required for non-memory mapped address, e.g.: I2C chip.
Then when we need only raw 'reg' property's value.

Since the I2C device address goes to a single-cell reg property,
support for that case is welcome, but currently calling
dev_get_addr()
for I2C device will return 'FDT_ADDR_T_NONE', and print the
warning:

warning:
__of_translate_address: Bad cell count for 'some-dev'




This patch takes the wrong approach.

It simply doesn't make sense to /attempt/ to translate an I2C
address
into an MMIO address space. It's a nonsensical operation; no such
translation is possible under any circumstances because I2C and
MMIO
addresses mean completely different things and simply can't be
translated to each-other.

Rather than making this nonsensical operation succeed in a way that
gives the desired no-op result, the nonsensical operation simply
shouldn't be performed in the first place.




Okay, the example with I2C may be little confusing - I could use
some
general naming convention. However, this patch updates
FDT-related code
only.

In one of your previous e-mails, you well argued that we
shouldn't use
dev_get_reg() for some buses, since they have a different 'reg'
meaning.

You are right, using dev_get_addr() as universal function may be
nonsensical.

Please note, that the present implementation of function:
'__of_translate_address()' - allows for 1:1 translation, but only if
'#size-cells' exists. So the below case is possible:

--
parent {
   address-cells = <1>;
   size-cells = <1>;
   reg = <0x1000 0x1000>;

   child {
   reg = <0xa00 0x100>;
   };
};

dev_get_reg(child) - will return '0xa00'
--

If we don't need the address length, we can define:
--
parent {
   address-cells = <1>;
   size-cells = <0>;
   reg = <0x1000 0x1000>;

   child {
   reg = <0xa00>;
   };
};




This case won't ever appear in a correctly written DT where reg
represents an MMIO address; MMIO addresses always have sizes, and
hence
can't have size-cells=0. Hence, translating through a DT
structures like
that is an error case, and shouldn't work.




As we found out, the 'reg' property can represent not only MMIO,
but may
have other meaning,




Of course.


so the above case is possible.




Yes and no.

That DT snippet is certainly possible.

However, that's irrelevant to whether address translation should be
attempted across that boundary. *That* is not legal and should not be
attempted.



Going through your suggestions I took your side.
You are on Cc in the new patchset.


   > The 'reg' for the



parent bus can represent MMIO (depends on what its parent defines) and
the child is non-MMIO.




Correct.


You won't allow to use dev_get_addr() for other than MMIO addresses.
Ok, I have no more arguments and no more time.




"You" is incorrect. This has absolutely nothing to do with me, but
rather the rule is imposed by the semantics of device tree.

Also, I never said that dev_get_addr() must not be used for non-MMIO
addresses. In fact, I offered a suggestion to make it work correctly.
What I actually stated is that address translation must not be
attempted
across boundaries between address spaces, since it is semantically
non-sensical.



Ok, please don't take it personally:), it was just how I understood your
opinion.

As you know the specification is not so clean, I thought, that
checking the
existence of "ranges" in parent node - is enough to provide proper
"translation" (or rather choosing the root address space), when
size-cells
== 0. However, checking this condition is probably not enough, but you
didn't provide a device-tree example to give it some light.

Also maybe the translation is a bad word here, since we know that
it's not
MMIO translatable address.

For me, this patch is okay.
If

Re: [U-Boot] [PATCH] drivers/power/regulator/max77686.c: Don't use switch() on bools

2016-01-18 Thread Przemyslaw Marczak


Hello Tom,

On 01/17/2016 03:44 AM, Tom Rini wrote:

With gcc-5.3 we get a warning for using switch() on a bool type.
Rewrite these sections as if/else and update the one section that was
using 1/0 instead of true/false.

Cc: Simon Glass <s...@chromium.org>
Cc: Przemyslaw Marczak <p.marc...@samsung.com>
Signed-off-by: Tom Rini <tr...@konsulko.com>
---
  drivers/power/regulator/max77686.c | 28 
  1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/power/regulator/max77686.c 
b/drivers/power/regulator/max77686.c
index 71678b6..7479af7 100644
--- a/drivers/power/regulator/max77686.c
+++ b/drivers/power/regulator/max77686.c
@@ -515,25 +515,19 @@ static int max77686_ldo_enable(struct udevice *dev, int 
op, bool *enable)

switch (on_off) {
case OPMODE_OFF:
-   *enable = 0;
+   *enable = false;
break;
case OPMODE_ON:
-   *enable = 1;
+   *enable = true;
break;
default:
return -EINVAL;
}
} else if (op == PMIC_OP_SET) {
-   switch (*enable) {
-   case 0:
-   on_off = OPMODE_OFF;
-   break;
-   case 1:
+   if (*enable)
on_off = OPMODE_ON;
-   break;
-   default:
-   return -EINVAL;
-   }
+   else
+   on_off = OPMODE_OFF;

ret = max77686_ldo_mode(dev, op, _off);
if (ret)
@@ -651,16 +645,10 @@ static int max77686_buck_enable(struct udevice *dev, int 
op, bool *enable)
return -EINVAL;
}
} else if (op == PMIC_OP_SET) {
-   switch (*enable) {
-   case 0:
-   on_off = OPMODE_OFF;
-   break;
-   case 1:
+   if (*enable)
on_off = OPMODE_ON;
-   break;
-   default:
-   return -EINVAL;
-   }
+   else
+   on_off = OPMODE_OFF;

ret = max77686_buck_mode(dev, op, _off);
if (ret)



Thank you for pointing that:)

Acked-by: Przemyslaw Marczak <p.marc...@samsung.com>

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] Move all command code into its own directory

2016-01-18 Thread Przemyslaw Marczak


Hello Simon,

On 01/18/2016 04:53 AM, Simon Glass wrote:

There are a lot of unrelated files in common, including all of the commands.
Moving them into their own directory makes them easier to find and is more
logical.

Some commands include non-command code, such as cmd_scsi.c. This should be
sorted out at some point so that the function can be enabled with or without
the associated command.

Unfortunately, with m68k I get this error:

m68k:  +   M5329AFEE
+arch/m68k/cpu/mcf532x/start.o: In function `_start':
+arch/m68k/cpu/mcf532x/start.S:159:(.text+0x452): relocation truncated to fit: 
R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section 
in common/built-in.o

I hope someone can shed some light on what this means. I hope it isn't
depending on the position of code in the image.

Signed-off-by: Simon Glass 
---

  Kconfig |   2 +
  Makefile|   1 +
  cmd/Kconfig | 585 +++
  cmd/Makefile| 166 +
  {common => cmd}/cmd_aes.c   |   0
  {common => cmd}/cmd_ambapp.c|   0
  {common => cmd}/cmd_armflash.c  |   0
  {common => cmd}/cmd_bdinfo.c|   0
  {common => cmd}/cmd_bedbug.c|   0
  {common => cmd}/cmd_blob.c  |   0
  {common => cmd}/cmd_bmp.c   |   0
  {common => cmd}/cmd_boot.c  |   0
  {common => cmd}/cmd_bootldr.c   |   0
  {common => cmd}/cmd_bootm.c |   0
  {common => cmd}/cmd_bootmenu.c  |   0
  {common => cmd}/cmd_bootstage.c |   0
  {common => cmd}/cmd_cache.c |   0
  {common => cmd}/cmd_cbfs.c  |   0
  {common => cmd}/cmd_clk.c   |   0
  {common => cmd}/cmd_console.c   |   0
  {common => cmd}/cmd_cplbinfo.c  |   0
  {common => cmd}/cmd_cpu.c   |   0
  {common => cmd}/cmd_cramfs.c|   0
  {common => cmd}/cmd_dataflash_mmc_mux.c |   0
  {common => cmd}/cmd_date.c  |   0
  {common => cmd}/cmd_dcr.c   |   0
  {common => cmd}/cmd_demo.c  |   0
  {common => cmd}/cmd_dfu.c   |   0
  {common => cmd}/cmd_diag.c  |   0
  {common => cmd}/cmd_disk.c  |   0
  {common => cmd}/cmd_display.c   |   0
  {common => cmd}/cmd_dtt.c   |   0
  {common => cmd}/cmd_echo.c  |   0
  {common => cmd}/cmd_eeprom.c|   0
  {common => cmd}/cmd_efi.c   |   0
  {common => cmd}/cmd_elf.c   |   0
  {common => cmd}/cmd_ethsw.c |   0
  {common => cmd}/cmd_exit.c  |   0
  {common => cmd}/cmd_ext2.c  |   0
  {common => cmd}/cmd_ext4.c  |   0
  {common => cmd}/cmd_fastboot.c  |   0
  {common => cmd}/cmd_fat.c   |   0
  {common => cmd}/cmd_fdc.c   |   0
  {common => cmd}/cmd_fdt.c   |   0
  {common => cmd}/cmd_fitupd.c|   0
  {common => cmd}/cmd_flash.c |   0
  {common => cmd}/cmd_fpga.c  |   0
  {common => cmd}/cmd_fpgad.c |   0
  {common => cmd}/cmd_fs.c|   0
  {common => cmd}/cmd_fs_uuid.c   |   0
  {common => cmd}/cmd_fuse.c  |   0
  {common => cmd}/cmd_gettime.c   |   0
  {common => cmd}/cmd_gpio.c  |   0
  {common => cmd}/cmd_gpt.c   |   0
  {common => cmd}/cmd_hash.c  |   0
  {common => cmd}/cmd_help.c  |   0
  {common => cmd}/cmd_host.c  |   0
  {common => cmd}/cmd_i2c.c   |   0
  {common => cmd}/cmd_ide.c   |   0
  {common => cmd}/cmd_immap.c |   0
  {common => cmd}/cmd_ini.c   |   0
  {common => cmd}/cmd_io.c|   0
  {common => cmd}/cmd_iotrace.c   |   0
  {common => cmd}/cmd_irq.c   |   0
  {common => cmd}/cmd_itest.c |   0
  {common => cmd}/cmd_jffs2.c |   0
  {common => cmd}/cmd_ldrinfo.c   |   0
  {common => cmd}/cmd_led.c   |   0
  {common => cmd}/cmd_license.c   |   0
  {common => cmd}/cmd_load.c  |   0
  {common => cmd}/cmd_log.c   |   0
  {common => cmd}/cmd_lzmadec.c   |   0
  {common => cmd}/cmd_mac.c   |   0
  {common => cmd}/cmd_md5sum.c|   0
  {common => cmd}/cmd_mdio.c  |   0
  {common => cmd}/cmd_mem.c   |   0
  {common => cmd}/cmd_mfsl.c  |   0
  {common => cmd}/cmd_mii.c   |   0
  {common => cmd}/cmd_misc.c  |   0
  {common => cmd}/cmd_mmc.c   |   0
  {common => cmd}/cmd_mmc_spi.c   |   0
  {common => cmd}/cmd_mp.c|   0
  {common => cmd}/cmd_mtdparts.c  |   0
  {common => cmd}/cmd_nand.c  |   0
  {common => cmd}/cmd_net.c   |   0

Re: [U-Boot] [PATCH 2/2] Remove the cmd_ prefix from command files

2016-01-18 Thread Przemyslaw Marczak

ex 100%
rename from cmd/cmd_regulator.c
rename to cmd/regulator.c
diff --git a/cmd/cmd_reiser.c b/cmd/reiser.c
similarity index 100%
rename from cmd/cmd_reiser.c
rename to cmd/reiser.c
diff --git a/cmd/cmd_remoteproc.c b/cmd/remoteproc.c
similarity index 100%
rename from cmd/cmd_remoteproc.c
rename to cmd/remoteproc.c
diff --git a/cmd/cmd_sata.c b/cmd/sata.c
similarity index 100%
rename from cmd/cmd_sata.c
rename to cmd/sata.c
diff --git a/cmd/cmd_scsi.c b/cmd/scsi.c
similarity index 100%
rename from cmd/cmd_scsi.c
rename to cmd/scsi.c
diff --git a/cmd/cmd_setexpr.c b/cmd/setexpr.c
similarity index 100%
rename from cmd/cmd_setexpr.c
rename to cmd/setexpr.c
diff --git a/cmd/cmd_sf.c b/cmd/sf.c
similarity index 100%
rename from cmd/cmd_sf.c
rename to cmd/sf.c
diff --git a/cmd/cmd_sha1sum.c b/cmd/sha1sum.c
similarity index 100%
rename from cmd/cmd_sha1sum.c
rename to cmd/sha1sum.c
diff --git a/cmd/cmd_softswitch.c b/cmd/softswitch.c
similarity index 100%
rename from cmd/cmd_softswitch.c
rename to cmd/softswitch.c
diff --git a/cmd/cmd_sound.c b/cmd/sound.c
similarity index 100%
rename from cmd/cmd_sound.c
rename to cmd/sound.c
diff --git a/cmd/cmd_source.c b/cmd/source.c
similarity index 100%
rename from cmd/cmd_source.c
rename to cmd/source.c
diff --git a/cmd/cmd_spi.c b/cmd/spi.c
similarity index 100%
rename from cmd/cmd_spi.c
rename to cmd/spi.c
diff --git a/cmd/cmd_spibootldr.c b/cmd/spibootldr.c
similarity index 100%
rename from cmd/cmd_spibootldr.c
rename to cmd/spibootldr.c
diff --git a/cmd/cmd_spl.c b/cmd/spl.c
similarity index 100%
rename from cmd/cmd_spl.c
rename to cmd/spl.c
diff --git a/cmd/cmd_strings.c b/cmd/strings.c
similarity index 100%
rename from cmd/cmd_strings.c
rename to cmd/strings.c
diff --git a/cmd/cmd_terminal.c b/cmd/terminal.c
similarity index 100%
rename from cmd/cmd_terminal.c
rename to cmd/terminal.c
diff --git a/cmd/cmd_test.c b/cmd/test.c
similarity index 100%
rename from cmd/cmd_test.c
rename to cmd/test.c
diff --git a/cmd/cmd_thordown.c b/cmd/thordown.c
similarity index 100%
rename from cmd/cmd_thordown.c
rename to cmd/thordown.c
diff --git a/cmd/cmd_time.c b/cmd/time.c
similarity index 100%
rename from cmd/cmd_time.c
rename to cmd/time.c
diff --git a/cmd/cmd_tpm.c b/cmd/tpm.c
similarity index 100%
rename from cmd/cmd_tpm.c
rename to cmd/tpm.c
diff --git a/cmd/cmd_tpm_test.c b/cmd/tpm_test.c
similarity index 100%
rename from cmd/cmd_tpm_test.c
rename to cmd/tpm_test.c
diff --git a/cmd/cmd_trace.c b/cmd/trace.c
similarity index 100%
rename from cmd/cmd_trace.c
rename to cmd/trace.c
diff --git a/cmd/cmd_tsi148.c b/cmd/tsi148.c
similarity index 100%
rename from cmd/cmd_tsi148.c
rename to cmd/tsi148.c
diff --git a/cmd/cmd_ubi.c b/cmd/ubi.c
similarity index 100%
rename from cmd/cmd_ubi.c
rename to cmd/ubi.c
diff --git a/cmd/cmd_ubifs.c b/cmd/ubifs.c
similarity index 100%
rename from cmd/cmd_ubifs.c
rename to cmd/ubifs.c
diff --git a/cmd/cmd_universe.c b/cmd/universe.c
similarity index 100%
rename from cmd/cmd_universe.c
rename to cmd/universe.c
diff --git a/cmd/cmd_unzip.c b/cmd/unzip.c
similarity index 100%
rename from cmd/cmd_unzip.c
rename to cmd/unzip.c
diff --git a/cmd/cmd_usb.c b/cmd/usb.c
similarity index 100%
rename from cmd/cmd_usb.c
rename to cmd/usb.c
diff --git a/cmd/cmd_usb_mass_storage.c b/cmd/usb_mass_storage.c
similarity index 100%
rename from cmd/cmd_usb_mass_storage.c
rename to cmd/usb_mass_storage.c
diff --git a/cmd/cmd_version.c b/cmd/version.c
similarity index 100%
rename from cmd/cmd_version.c
rename to cmd/version.c
diff --git a/cmd/cmd_ximg.c b/cmd/ximg.c
similarity index 100%
rename from cmd/cmd_ximg.c
rename to cmd/ximg.c
diff --git a/cmd/cmd_yaffs2.c b/cmd/yaffs2.c
similarity index 100%
rename from cmd/cmd_yaffs2.c
rename to cmd/yaffs2.c
diff --git a/cmd/cmd_zfs.c b/cmd/zfs.c
similarity index 100%
rename from cmd/cmd_zfs.c
rename to cmd/zfs.c
diff --git a/cmd/cmd_zip.c b/cmd/zip.c
similarity index 100%
rename from cmd/cmd_zip.c
rename to cmd/zip.c



Acked-by: Przemyslaw Marczak <p.marc...@samsung.com>

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com

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

Re: [U-Boot] [PATCH] fdt: __of_translate_address(): check parent's 'ranges' before translate

2016-01-15 Thread Przemyslaw Marczak


Hello Simon,

On 01/14/2016 06:17 PM, Simon Glass wrote:

Hi Przemyslaw, Stephen,

On 13 January 2016 at 04:10, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

Hello Stephen,


On 01/12/2016 05:43 PM, Stephen Warren wrote:


On 01/12/2016 03:25 AM, Przemyslaw Marczak wrote:


Hello Stephen,

On 01/11/2016 05:47 PM, Stephen Warren wrote:


On 01/11/2016 04:21 AM, Przemyslaw Marczak wrote:


Hello Stephen,

On 01/07/2016 07:25 PM, Stephen Warren wrote:


On 01/07/2016 04:40 AM, Przemyslaw Marczak wrote:


The present implementation of __of_translate_address() taken
from the Linux, is designed for translate bus/child address
mappings by using 'ranges' property - and it doesn't allow
for checking an address for a device's node with zero size-cells.

The 'size-cells > 0' is required for bus/child address mapping,
but is not required for non-memory mapped address, e.g.: I2C chip.
Then when we need only raw 'reg' property's value.

Since the I2C device address goes to a single-cell reg property,
support for that case is welcome, but currently calling
dev_get_addr()
for I2C device will return 'FDT_ADDR_T_NONE', and print the warning:

warning:
__of_translate_address: Bad cell count for 'some-dev'



This patch takes the wrong approach.

It simply doesn't make sense to /attempt/ to translate an I2C address
into an MMIO address space. It's a nonsensical operation; no such
translation is possible under any circumstances because I2C and MMIO
addresses mean completely different things and simply can't be
translated to each-other.

Rather than making this nonsensical operation succeed in a way that
gives the desired no-op result, the nonsensical operation simply
shouldn't be performed in the first place.




Okay, the example with I2C may be little confusing - I could use some
general naming convention. However, this patch updates FDT-related code
only.

In one of your previous e-mails, you well argued that we shouldn't use
dev_get_reg() for some buses, since they have a different 'reg'
meaning.

You are right, using dev_get_addr() as universal function may be
nonsensical.

Please note, that the present implementation of function:
'__of_translate_address()' - allows for 1:1 translation, but only if
'#size-cells' exists. So the below case is possible:

--
parent {
  address-cells = <1>;
  size-cells = <1>;
  reg = <0x1000 0x1000>;

  child {
  reg = <0xa00 0x100>;
  };
};

dev_get_reg(child) - will return '0xa00'
--

If we don't need the address length, we can define:
--
parent {
  address-cells = <1>;
  size-cells = <0>;
  reg = <0x1000 0x1000>;

  child {
  reg = <0xa00>;
  };
};



This case won't ever appear in a correctly written DT where reg
represents an MMIO address; MMIO addresses always have sizes, and hence
can't have size-cells=0. Hence, translating through a DT structures like
that is an error case, and shouldn't work.



As we found out, the 'reg' property can represent not only MMIO, but may
have other meaning,



Of course.


so the above case is possible.



Yes and no.

That DT snippet is certainly possible.

However, that's irrelevant to whether address translation should be
attempted across that boundary. *That* is not legal and should not be
attempted.



Going through your suggestions I took your side.
You are on Cc in the new patchset.


  > The 'reg' for the


parent bus can represent MMIO (depends on what its parent defines) and
the child is non-MMIO.



Correct.


You won't allow to use dev_get_addr() for other than MMIO addresses.
Ok, I have no more arguments and no more time.



"You" is incorrect. This has absolutely nothing to do with me, but
rather the rule is imposed by the semantics of device tree.

Also, I never said that dev_get_addr() must not be used for non-MMIO
addresses. In fact, I offered a suggestion to make it work correctly.
What I actually stated is that address translation must not be attempted
across boundaries between address spaces, since it is semantically
non-sensical.



Ok, please don't take it personally:), it was just how I understood your
opinion.

As you know the specification is not so clean, I thought, that checking the
existence of "ranges" in parent node - is enough to provide proper
"translation" (or rather choosing the root address space), when size-cells
== 0. However, checking this condition is probably not enough, but you
didn't provide a device-tree example to give it some light.

Also maybe the translation is a bad word here, since we know that it's not
MMIO translatable address.

For me, this patch is okay.
If I call it for I2C chip and it returns the chip address in I2C address
space - then I can assume, that this is correct.

Since, at present I2C subsystem takes the 'reg' as property's value, it
looks that there should be no differen

Re: [U-Boot] [PATCH] fdt: __of_translate_address(): check parent's 'ranges' before translate

2016-01-13 Thread Przemyslaw Marczak


Hello Stephen,

On 01/12/2016 05:43 PM, Stephen Warren wrote:

On 01/12/2016 03:25 AM, Przemyslaw Marczak wrote:

Hello Stephen,

On 01/11/2016 05:47 PM, Stephen Warren wrote:

On 01/11/2016 04:21 AM, Przemyslaw Marczak wrote:

Hello Stephen,

On 01/07/2016 07:25 PM, Stephen Warren wrote:

On 01/07/2016 04:40 AM, Przemyslaw Marczak wrote:

The present implementation of __of_translate_address() taken
from the Linux, is designed for translate bus/child address
mappings by using 'ranges' property - and it doesn't allow
for checking an address for a device's node with zero size-cells.

The 'size-cells > 0' is required for bus/child address mapping,
but is not required for non-memory mapped address, e.g.: I2C chip.
Then when we need only raw 'reg' property's value.

Since the I2C device address goes to a single-cell reg property,
support for that case is welcome, but currently calling
dev_get_addr()
for I2C device will return 'FDT_ADDR_T_NONE', and print the warning:

warning:
__of_translate_address: Bad cell count for 'some-dev'


This patch takes the wrong approach.

It simply doesn't make sense to /attempt/ to translate an I2C address
into an MMIO address space. It's a nonsensical operation; no such
translation is possible under any circumstances because I2C and MMIO
addresses mean completely different things and simply can't be
translated to each-other.

Rather than making this nonsensical operation succeed in a way that
gives the desired no-op result, the nonsensical operation simply
shouldn't be performed in the first place.




Okay, the example with I2C may be little confusing - I could use some
general naming convention. However, this patch updates FDT-related code
only.

In one of your previous e-mails, you well argued that we shouldn't use
dev_get_reg() for some buses, since they have a different 'reg'
meaning.

You are right, using dev_get_addr() as universal function may be
nonsensical.

Please note, that the present implementation of function:
'__of_translate_address()' - allows for 1:1 translation, but only if
'#size-cells' exists. So the below case is possible:

--
parent {
 address-cells = <1>;
 size-cells = <1>;
 reg = <0x1000 0x1000>;

 child {
 reg = <0xa00 0x100>;
 };
};

dev_get_reg(child) - will return '0xa00'
--

If we don't need the address length, we can define:
--
parent {
 address-cells = <1>;
 size-cells = <0>;
 reg = <0x1000 0x1000>;

 child {
 reg = <0xa00>;
 };
};


This case won't ever appear in a correctly written DT where reg
represents an MMIO address; MMIO addresses always have sizes, and hence
can't have size-cells=0. Hence, translating through a DT structures like
that is an error case, and shouldn't work.


As we found out, the 'reg' property can represent not only MMIO, but may
have other meaning,


Of course.


so the above case is possible.


Yes and no.

That DT snippet is certainly possible.

However, that's irrelevant to whether address translation should be
attempted across that boundary. *That* is not legal and should not be
attempted.



Going through your suggestions I took your side.
You are on Cc in the new patchset.


 > The 'reg' for the

parent bus can represent MMIO (depends on what its parent defines) and
the child is non-MMIO.


Correct.


You won't allow to use dev_get_addr() for other than MMIO addresses.
Ok, I have no more arguments and no more time.


"You" is incorrect. This has absolutely nothing to do with me, but
rather the rule is imposed by the semantics of device tree.

Also, I never said that dev_get_addr() must not be used for non-MMIO
addresses. In fact, I offered a suggestion to make it work correctly.
What I actually stated is that address translation must not be attempted
across boundaries between address spaces, since it is semantically
non-sensical.



Ok, please don't take it personally:), it was just how I understood your 
opinion.


As you know the specification is not so clean, I thought, that checking 
the existence of "ranges" in parent node - is enough to provide proper 
"translation" (or rather choosing the root address space), when 
size-cells == 0. However, checking this condition is probably not 
enough, but you didn't provide a device-tree example to give it some light.


Also maybe the translation is a bad word here, since we know that it's 
not MMIO translatable address.


For me, this patch is okay.
If I call it for I2C chip and it returns the chip address in I2C address 
space - then I can assume, that this is correct.


Since, at present I2C subsystem takes the 'reg' as property's value, it 
looks that there should be no difference when using modified dev_get_reg().


However the main reason for this change was not I2C code update, but 
fixing Exynos GPIO driver which uses DTB in a quite different way than

Re: [U-Boot] [PATCH] fdt: fix address cell count checking in fdt_translate_address()


Hello Simon,

On 01/11/2016 05:59 PM, Simon Glass wrote:

Hi Przemyslaw,

On 8 January 2016 at 05:01, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

Hello Simon,


On 01/07/2016 08:24 PM, Simon Glass wrote:


+Stephen

On 4 January 2016 at 17:59, Simon Glass <s...@chromium.org> wrote:


Hi Przemyslaw,

On 5 November 2015 at 23:47, Stefan Roese <s...@denx.de> wrote:


On 06.11.2015 04:16, Simon Glass wrote:



Hi,

On 3 November 2015 at 02:57, Przemyslaw Marczak <p.marc...@samsung.com>
wrote:



Hello All,


On 10/29/2015 06:15 PM, Simon Glass wrote:




Hi Stefan,

On 28 October 2015 at 08:37, Przemyslaw Marczak
<p.marc...@samsung.com>
wrote:




Commit: dm: core: Enable optional use of fdt_translate_address()

Enables use of this function as default, but after this it's not
possible to get dev address for the case in which: '#size-cells ==
0'

This causes errors when getting address for some GPIOs, for which
the '#size-cells' is set to 0.

Example error:
'__of_translate_address: Bad cell count for gpx0'

Allowing for that case by modifying the macro 'OF_CHECK_COUNTS',
(called from )__of_translate_address(), fixes the issue.

Now, this macro doesn't check, that '#size-cells' is greater than 0.

This is possible from the specification point of view, but I'm not
sure
that it doesn't introduce a regression for other configs.

Please test and share the results.

Tested-on: Odroid U3, Odroid X2, Odroid XU3, Sandbox.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Masahiro Yamada <yamada.masah...@socionext.com>
Cc: Lukasz Majewski <l.majew...@samsung.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Stefan Roese <s...@denx.de>
Cc: Simon Glass <s...@chromium.org>
Cc: Bin Meng <bmeng...@gmail.com>
Cc: Marek Vasut <ma...@denx.de>
---
 common/fdt_support.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index f86365e..5f808cc 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -946,8 +946,7 @@ void fdt_del_node_and_alias(void *blob, const
char
*alias)
 /* Max address size we deal with */
 #define OF_MAX_ADDR_CELLS  4
 #define OF_BAD_ADDR((u64)-1)
-#define OF_CHECK_COUNTS(na, ns)((na) > 0 && (na) <=
OF_MAX_ADDR_CELLS && \
-   (ns) > 0)
+#define OF_CHECK_COUNTS(na)((na) > 0 && (na) <=
OF_MAX_ADDR_CELLS)

 /* Debug utility */
 #ifdef DEBUG
@@ -1115,7 +1114,7 @@ static u64 __of_translate_address(void *blob,
int
node_offset, const fdt32_t *in

/* Cound address cells & copy address locally */
bus->count_cells(blob, parent, , );
-   if (!OF_CHECK_COUNTS(na, ns)) {
+   if (!OF_CHECK_COUNTS(na)) {





This seems to conflict with the comment at the top of this function:

 * Note: We consider that crossing any level with #size-cells == 0
to
mean
 * that translation is impossible (that is we are not dealing with
a
value
 * that can be mapped to a cpu physical address). This is not
really
specified
 * that way, but this is traditionally the way IBM at least do
things

What should we do here?



Is that commit acceptable? I would like send V2 with removing the
above
comment.




That's what I am worried about. Presumably the comment is accurate
today and this check has some value. I was hoping Stefan might know.




Unfortunately no. I just stumbled over this problem with the
translation of the "complex" ranges on the MVEBU platform. And
noticed that we already have this functionality to translate
the addresses the "right way".

I'm wondering how this problem with those GPIOs is handled in
the kernel? I assume that it is working correctly there, right?
Przemyslaw, could you perhaps check this and see, why its
working there? And change / fix it in U-Boot accordingly?



Let's pick up this patch for now as a bug-fix. We can deal with this
problem after the release.



Applied to u-boot-dm/master.

I'll post a revert after the release. It seems like you and Stephen
are making good progress.

- Simon




Why so fast with this one?

I think, that more proper for a temporary fix is my latest patch with
#size-cells count checking only if ranges found in the parent node.

I will continue the discussion with Stephen.


The release is scheduled for today, so we had to do something to fix
the breakage.

Once you have a full solution figured out we can revert this patch and
apply what you come up with.

Regards,
Simon




Ok. It's hard to convince Stephen to accept such change, so I will send 
a patch with another solution - just bring back fdtdec_get_addr() for 
Exynos GPIO driver. And will revert this one within the patchset.


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: __of_translate_address(): check parent's 'ranges' before translate


Hello Simon,

On 01/12/2016 02:57 PM, Simon Glass wrote:

Hi Przemyslaw,

On 12 January 2016 at 03:25, Przemyslaw Marczak <p.marc...@samsung.com> wrote:


Hello Stephen,


On 01/11/2016 05:47 PM, Stephen Warren wrote:


On 01/11/2016 04:21 AM, Przemyslaw Marczak wrote:


Hello Stephen,

On 01/07/2016 07:25 PM, Stephen Warren wrote:


On 01/07/2016 04:40 AM, Przemyslaw Marczak wrote:


The present implementation of __of_translate_address() taken
from the Linux, is designed for translate bus/child address
mappings by using 'ranges' property - and it doesn't allow
for checking an address for a device's node with zero size-cells.

The 'size-cells > 0' is required for bus/child address mapping,
but is not required for non-memory mapped address, e.g.: I2C chip.
Then when we need only raw 'reg' property's value.

Since the I2C device address goes to a single-cell reg property,
support for that case is welcome, but currently calling dev_get_addr()
for I2C device will return 'FDT_ADDR_T_NONE', and print the warning:

warning:
__of_translate_address: Bad cell count for 'some-dev'



This patch takes the wrong approach.

It simply doesn't make sense to /attempt/ to translate an I2C address
into an MMIO address space. It's a nonsensical operation; no such
translation is possible under any circumstances because I2C and MMIO
addresses mean completely different things and simply can't be
translated to each-other.

Rather than making this nonsensical operation succeed in a way that
gives the desired no-op result, the nonsensical operation simply
shouldn't be performed in the first place.




Okay, the example with I2C may be little confusing - I could use some
general naming convention. However, this patch updates FDT-related code
only.

In one of your previous e-mails, you well argued that we shouldn't use
dev_get_reg() for some buses, since they have a different 'reg' meaning.

You are right, using dev_get_addr() as universal function may be
nonsensical.

Please note, that the present implementation of function:
'__of_translate_address()' - allows for 1:1 translation, but only if
'#size-cells' exists. So the below case is possible:

--
parent {
  address-cells = <1>;
  size-cells = <1>;
  reg = <0x1000 0x1000>;

  child {
  reg = <0xa00 0x100>;
  };
};

dev_get_reg(child) - will return '0xa00'
--

If we don't need the address length, we can define:
--
parent {
  address-cells = <1>;
  size-cells = <0>;
  reg = <0x1000 0x1000>;

  child {
  reg = <0xa00>;
  };
};



This case won't ever appear in a correctly written DT where reg
represents an MMIO address; MMIO addresses always have sizes, and hence
can't have size-cells=0. Hence, translating through a DT structures like
that is an error case, and shouldn't work.





As we found out, the 'reg' property can represent not only MMIO, but may have 
other meaning, so the above case is possible. The 'reg' for the parent bus can 
represent MMIO (depends on what its parent defines) and the child is non-MMIO.

You won't allow to use dev_get_addr() for other than MMIO addresses.
Ok, I have no more arguments and no more time.

My issue can be also fixed by removing dev_get_addr() call from Exynos GPIO 
driver - so I will do this and within this change, will also revert the commit:
"fdt: fix address cell count checking in fdt_translate_address()"


I'm sorry this has been so difficult. Thank you for digging into it.

I'm going to take this patch as is unless there is an alternative
patch on the table. Stephen please let me know if you'd like to write
something. One idea seems to be a new function (like
dev_get_addr_local()) which avoids the address translation. But
Przemyslaw has put enough energy into this I think.

Regards,
Simon




I think, that we don't need such function.

Stephen has right with the universal dev_get_addr() - it should be used 
only for MMIO addresses.


And also any universal function for getting the reg value is useless, 
for some specific reasons, which Stephen mentioned.


I'm going to send another patch soon, which I think (again) should close 
the issue at all. Changing GPIO driver is not required, it will be 
enough when I fix the device-tree files (SoCxxx-pinctrl-uboot.dts).


We don't need to look at kernel, since we have two different drivers and 
also the kernel doesn't use the GPIO's regs (addresses are hardcoded).

So fixing device-tree is a good choose. It's really only few lines per file.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: fix address cell count checking in fdt_translate_address()


Hello Simon,

On 01/12/2016 02:59 PM, Simon Glass wrote:

Hi Przemyslaw,

On 12 January 2016 at 03:49, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

Hello Simon,


On 01/11/2016 05:59 PM, Simon Glass wrote:


Hi Przemyslaw,

On 8 January 2016 at 05:01, Przemyslaw Marczak <p.marc...@samsung.com>
wrote:


Hello Simon,


On 01/07/2016 08:24 PM, Simon Glass wrote:



+Stephen

On 4 January 2016 at 17:59, Simon Glass <s...@chromium.org> wrote:



Hi Przemyslaw,

On 5 November 2015 at 23:47, Stefan Roese <s...@denx.de> wrote:



On 06.11.2015 04:16, Simon Glass wrote:




Hi,

On 3 November 2015 at 02:57, Przemyslaw Marczak
<p.marc...@samsung.com>
wrote:




Hello All,


On 10/29/2015 06:15 PM, Simon Glass wrote:





Hi Stefan,

On 28 October 2015 at 08:37, Przemyslaw Marczak
<p.marc...@samsung.com>
wrote:





Commit: dm: core: Enable optional use of fdt_translate_address()

Enables use of this function as default, but after this it's not
possible to get dev address for the case in which: '#size-cells ==
0'

This causes errors when getting address for some GPIOs, for which
the '#size-cells' is set to 0.

Example error:
'__of_translate_address: Bad cell count for gpx0'

Allowing for that case by modifying the macro 'OF_CHECK_COUNTS',
(called from )__of_translate_address(), fixes the issue.

Now, this macro doesn't check, that '#size-cells' is greater than
0.

This is possible from the specification point of view, but I'm not
sure
that it doesn't introduce a regression for other configs.

Please test and share the results.

Tested-on: Odroid U3, Odroid X2, Odroid XU3, Sandbox.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Masahiro Yamada <yamada.masah...@socionext.com>
Cc: Lukasz Majewski <l.majew...@samsung.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Stefan Roese <s...@denx.de>
Cc: Simon Glass <s...@chromium.org>
Cc: Bin Meng <bmeng...@gmail.com>
Cc: Marek Vasut <ma...@denx.de>
---
  common/fdt_support.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index f86365e..5f808cc 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -946,8 +946,7 @@ void fdt_del_node_and_alias(void *blob, const
char
*alias)
  /* Max address size we deal with */
  #define OF_MAX_ADDR_CELLS  4
  #define OF_BAD_ADDR((u64)-1)
-#define OF_CHECK_COUNTS(na, ns)((na) > 0 && (na) <=
OF_MAX_ADDR_CELLS && \
-   (ns) > 0)
+#define OF_CHECK_COUNTS(na)((na) > 0 && (na) <=
OF_MAX_ADDR_CELLS)

  /* Debug utility */
  #ifdef DEBUG
@@ -1115,7 +1114,7 @@ static u64 __of_translate_address(void
*blob,
int
node_offset, const fdt32_t *in

 /* Cound address cells & copy address locally */
 bus->count_cells(blob, parent, , );
-   if (!OF_CHECK_COUNTS(na, ns)) {
+   if (!OF_CHECK_COUNTS(na)) {






This seems to conflict with the comment at the top of this
function:

  * Note: We consider that crossing any level with #size-cells
== 0
to
mean
  * that translation is impossible (that is we are not dealing
with
a
value
  * that can be mapped to a cpu physical address). This is not
really
specified
  * that way, but this is traditionally the way IBM at least do
things

What should we do here?



Is that commit acceptable? I would like send V2 with removing the
above
comment.





That's what I am worried about. Presumably the comment is accurate
today and this check has some value. I was hoping Stefan might know.





Unfortunately no. I just stumbled over this problem with the
translation of the "complex" ranges on the MVEBU platform. And
noticed that we already have this functionality to translate
the addresses the "right way".

I'm wondering how this problem with those GPIOs is handled in
the kernel? I assume that it is working correctly there, right?
Przemyslaw, could you perhaps check this and see, why its
working there? And change / fix it in U-Boot accordingly?




Let's pick up this patch for now as a bug-fix. We can deal with this
problem after the release.




Applied to u-boot-dm/master.

I'll post a revert after the release. It seems like you and Stephen
are making good progress.

- Simon




Why so fast with this one?

I think, that more proper for a temporary fix is my latest patch with
#size-cells count checking only if ranges found in the parent node.

I will continue the discussion with Stephen.



The release is scheduled for today, so we had to do something to fix
the breakage.

Once you have a full solution figured out we can revert this patch and
apply what you come up with.

Regards,
Simon




Ok. It's hard to convince Stephen to accept such change, so I will send a
patch with another solution - just bring back fdtdec_get_addr() for Exynos
GPIO driver. And will rever

Re: [U-Boot] [PATCH] fdt: __of_translate_address(): check parent's 'ranges' before translate


Hello Stephen,

On 01/11/2016 05:47 PM, Stephen Warren wrote:

On 01/11/2016 04:21 AM, Przemyslaw Marczak wrote:

Hello Stephen,

On 01/07/2016 07:25 PM, Stephen Warren wrote:

On 01/07/2016 04:40 AM, Przemyslaw Marczak wrote:

The present implementation of __of_translate_address() taken
from the Linux, is designed for translate bus/child address
mappings by using 'ranges' property - and it doesn't allow
for checking an address for a device's node with zero size-cells.

The 'size-cells > 0' is required for bus/child address mapping,
but is not required for non-memory mapped address, e.g.: I2C chip.
Then when we need only raw 'reg' property's value.

Since the I2C device address goes to a single-cell reg property,
support for that case is welcome, but currently calling dev_get_addr()
for I2C device will return 'FDT_ADDR_T_NONE', and print the warning:

warning:
__of_translate_address: Bad cell count for 'some-dev'


This patch takes the wrong approach.

It simply doesn't make sense to /attempt/ to translate an I2C address
into an MMIO address space. It's a nonsensical operation; no such
translation is possible under any circumstances because I2C and MMIO
addresses mean completely different things and simply can't be
translated to each-other.

Rather than making this nonsensical operation succeed in a way that
gives the desired no-op result, the nonsensical operation simply
shouldn't be performed in the first place.




Okay, the example with I2C may be little confusing - I could use some
general naming convention. However, this patch updates FDT-related code
only.

In one of your previous e-mails, you well argued that we shouldn't use
dev_get_reg() for some buses, since they have a different 'reg' meaning.

You are right, using dev_get_addr() as universal function may be
nonsensical.

Please note, that the present implementation of function:
'__of_translate_address()' - allows for 1:1 translation, but only if
'#size-cells' exists. So the below case is possible:

--
parent {
 address-cells = <1>;
 size-cells = <1>;
 reg = <0x1000 0x1000>;

 child {
 reg = <0xa00 0x100>;
 };
};

dev_get_reg(child) - will return '0xa00'
--

If we don't need the address length, we can define:
--
parent {
 address-cells = <1>;
 size-cells = <0>;
 reg = <0x1000 0x1000>;

 child {
 reg = <0xa00>;
 };
};


This case won't ever appear in a correctly written DT where reg
represents an MMIO address; MMIO addresses always have sizes, and hence
can't have size-cells=0. Hence, translating through a DT structures like
that is an error case, and shouldn't work.





As we found out, the 'reg' property can represent not only MMIO, but may 
have other meaning, so the above case is possible. The 'reg' for the 
parent bus can represent MMIO (depends on what its parent defines) and 
the child is non-MMIO.


You won't allow to use dev_get_addr() for other than MMIO addresses.
Ok, I have no more arguments and no more time.

My issue can be also fixed by removing dev_get_addr() call from Exynos 
GPIO driver - so I will do this and within this change, will also revert 
the commit:

"fdt: fix address cell count checking in fdt_translate_address()"

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] Revert "fdt: fix address cell count checking in fdt_translate_address()"

This reverts commit 71105f50fedddfa5b0535d102c3d5078671721ad.

The reverted commit was applied for a temporary to unbreak
few Exynos boards on the release.

After the discussion about the change, this commit should be avoided.
Fixed device-tree for Exynos, allows reverting it without any issues.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Stefan Roese <s...@denx.de>
Cc: Tom Rini <tr...@konsulko.com>
Cc: Simon Glass <s...@chromium.org>
Cc: Stephen Warren <swar...@nvidia.com>
Cc: Stephen Warren <swar...@wwwdotorg.org>
---
 common/fdt_support.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index a539389..66464db 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -952,7 +952,8 @@ void fdt_del_node_and_alias(void *blob, const char *alias)
 /* Max address size we deal with */
 #define OF_MAX_ADDR_CELLS  4
 #define OF_BAD_ADDRFDT_ADDR_T_NONE
-#define OF_CHECK_COUNTS(na)((na) > 0 && (na) <= OF_MAX_ADDR_CELLS)
+#define OF_CHECK_COUNTS(na, ns)((na) > 0 && (na) <= OF_MAX_ADDR_CELLS 
&& \
+   (ns) > 0)
 
 /* Debug utility */
 #ifdef DEBUG
@@ -1120,7 +1121,7 @@ static u64 __of_translate_address(void *blob, int 
node_offset, const fdt32_t *in
 
/* Cound address cells & copy address locally */
bus->count_cells(blob, parent, , );
-   if (!OF_CHECK_COUNTS(na)) {
+   if (!OF_CHECK_COUNTS(na, ns)) {
printf("%s: Bad cell count for %s\n", __FUNCTION__,
   fdt_get_name(blob, node_offset, NULL));
goto bail;
@@ -1147,7 +1148,7 @@ static u64 __of_translate_address(void *blob, int 
node_offset, const fdt32_t *in
/* Get new parent bus and counts */
pbus = _busses[0];
pbus->count_cells(blob, parent, , );
-   if (!OF_CHECK_COUNTS(pna)) {
+   if (!OF_CHECK_COUNTS(pna, pns)) {
printf("%s: Bad cell count for %s\n", __FUNCTION__,
fdt_get_name(blob, node_offset, NULL));
break;
-- 
1.9.1

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

[U-Boot] [PATCH 0/2] Revert changes to __of_translate_address()

Globally enabled CONFIG_OF_TRANSLATE causes, that function dev_get_addr()
returns a different result for a node with: 'size-cells = <0>'.

The above change, breaks the Exynos boards for a long time, because of GPIO
driver, which uses the fdt in a non standard way.

After sending few approaches with adding support for that case,
the one was appllied for a temporary fix for the release:

"fdt: fix address cell count checking in fdt_translate_address()"

However, after discussion on the list, we found that this way can't be
accepted because the function __of_translate_address() as a backend
of dev_get_addr(), shouldn't be used for translating a non-MMIO addresses.

Updating some device tree files with '#size-cells = 1' and by extending
the 'reg' property by address length - fixes the problem.

This applies on u-boot-dm/master:
c5a7533 net: Fix delay in net_retry test

Przemyslaw Marczak (2):
  dts:exynos:update pinctrl size-cells and fix child regs
  Revert "fdt: fix address cell count checking in
fdt_translate_address()"

 arch/arm/dts/exynos4210-pinctrl-uboot.dtsi |  8 
 arch/arm/dts/exynos4x12-pinctrl-uboot.dtsi | 18 +-
 arch/arm/dts/exynos5250-pinctrl-uboot.dtsi | 16 
 arch/arm/dts/exynos54xx-pinctrl-uboot.dtsi | 12 ++--
 arch/arm/dts/s5pc110-pinctrl.dtsi  |  4 ++--
 common/fdt_support.c   |  7 ---
 6 files changed, 33 insertions(+), 32 deletions(-)

-- 
1.9.1

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

[U-Boot] [PATCH 1/2] dts:exynos:update pinctrl size-cells and fix child regs

This change is required to avoid warnings about invalid
size-cells defined in device-tree pinctrl nodes for Exynos.

Tested on:
- Odroid U3
- Odroid XU3

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Stefan Roese <s...@denx.de>
Cc: Tom Rini <tr...@konsulko.com>
Cc: Simon Glass <s...@chromium.org>
Cc: Stephen Warren <swar...@nvidia.com>
Cc: Stephen Warren <swar...@wwwdotorg.org>
---
 arch/arm/dts/exynos4210-pinctrl-uboot.dtsi |  8 
 arch/arm/dts/exynos4x12-pinctrl-uboot.dtsi | 18 +-
 arch/arm/dts/exynos5250-pinctrl-uboot.dtsi | 16 
 arch/arm/dts/exynos54xx-pinctrl-uboot.dtsi | 12 ++--
 arch/arm/dts/s5pc110-pinctrl.dtsi  |  4 ++--
 5 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/arch/arm/dts/exynos4210-pinctrl-uboot.dtsi 
b/arch/arm/dts/exynos4210-pinctrl-uboot.dtsi
index 0ff41d0..b76c77d 100644
--- a/arch/arm/dts/exynos4210-pinctrl-uboot.dtsi
+++ b/arch/arm/dts/exynos4210-pinctrl-uboot.dtsi
@@ -9,21 +9,21 @@
 /{
pinctrl_0: pinctrl@1140 {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;
compatible = "samsung,exynos4210-pinctrl";
};
 
pinctrl_1: pinctrl@1100 {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;
gpx0: gpx0 {
-   reg = <0xc00>;
+   reg = <0xc00 0x20>;
};
};
 
pinctrl_2: pinctrl@0386 {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;
};
 
 };
diff --git a/arch/arm/dts/exynos4x12-pinctrl-uboot.dtsi 
b/arch/arm/dts/exynos4x12-pinctrl-uboot.dtsi
index 8e5a6c6..33ecc14 100644
--- a/arch/arm/dts/exynos4x12-pinctrl-uboot.dtsi
+++ b/arch/arm/dts/exynos4x12-pinctrl-uboot.dtsi
@@ -9,37 +9,37 @@
 /{
pinctrl_0: pinctrl@1140 {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;
gpf0: gpf0 {
-   reg = <0x180>;
+   reg = <0x180 0x20>;
};
gpj0: gpj0 {
-   reg = <0x240>;
+   reg = <0x240 0x20>;
};
};
 
pinctrl_1: pinctrl@1100 {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;
gpk0: gpk0 {
-   reg = <0x40>;
+   reg = <0x40 0x20>;
};
gpm0: gpm0 {
-   reg = <0x260>;
+   reg = <0x260 0x20>;
};
gpx0: gpx0 {
-   reg = <0xc00>;
+   reg = <0xc00 0x20>;
};
};
 
pinctrl_2: pinctrl@0386 {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;
};
 
pinctrl_3: pinctrl@106E {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;
};
 
 };
diff --git a/arch/arm/dts/exynos5250-pinctrl-uboot.dtsi 
b/arch/arm/dts/exynos5250-pinctrl-uboot.dtsi
index 068c5f6..b8c0526 100644
--- a/arch/arm/dts/exynos5250-pinctrl-uboot.dtsi
+++ b/arch/arm/dts/exynos5250-pinctrl-uboot.dtsi
@@ -9,34 +9,34 @@
 /{
pinctrl_0: pinctrl@1140 {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;
gpc4: gpc4 {
-   reg = <0x2e0>;
+   reg = <0x2e0 0x20>;
};
gpx0: gpx0 {
-   reg = <0xc00>;
+   reg = <0xc00 0x20>;
};
};
 
pinctrl_1: pinctrl@1340 {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;
};
 
pinctrl_2: pinctrl@10d1 {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;
gpv2: gpv2 {
-   reg = <0x060>;
+   reg = <0x060 0x20>;
};
gpv4: gpv4 {
-   reg = <0xc0>;
+   reg = <0xc0 0x20>;
};
};
 
pinctrl_3: pinctrl@0386 {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;

Re: [U-Boot] [PATCH] fdt: __of_translate_address(): check parent's 'ranges' before translate

2016-01-11 Thread Przemyslaw Marczak


Hello Stephen,

On 01/07/2016 07:25 PM, Stephen Warren wrote:

On 01/07/2016 04:40 AM, Przemyslaw Marczak wrote:

The present implementation of __of_translate_address() taken
from the Linux, is designed for translate bus/child address
mappings by using 'ranges' property - and it doesn't allow
for checking an address for a device's node with zero size-cells.

The 'size-cells > 0' is required for bus/child address mapping,
but is not required for non-memory mapped address, e.g.: I2C chip.
Then when we need only raw 'reg' property's value.

Since the I2C device address goes to a single-cell reg property,
support for that case is welcome, but currently calling dev_get_addr()
for I2C device will return 'FDT_ADDR_T_NONE', and print the warning:

warning:
__of_translate_address: Bad cell count for 'some-dev'


This patch takes the wrong approach.

It simply doesn't make sense to /attempt/ to translate an I2C address
into an MMIO address space. It's a nonsensical operation; no such
translation is possible under any circumstances because I2C and MMIO
addresses mean completely different things and simply can't be
translated to each-other.

Rather than making this nonsensical operation succeed in a way that
gives the desired no-op result, the nonsensical operation simply
shouldn't be performed in the first place.




Okay, the example with I2C may be little confusing - I could use some 
general naming convention. However, this patch updates FDT-related code 
only.


In one of your previous e-mails, you well argued that we shouldn't use 
dev_get_reg() for some buses, since they have a different 'reg' meaning.


You are right, using dev_get_addr() as universal function may be 
nonsensical.


Please note, that the present implementation of function: 
'__of_translate_address()' - allows for 1:1 translation, but only if 
'#size-cells' exists. So the below case is possible:


--
parent {
address-cells = <1>;
size-cells = <1>;
reg = <0x1000 0x1000>;

child {
reg = <0xa00 0x100>;
};
};

dev_get_reg(child) - will return '0xa00'
--

If we don't need the address length, we can define:
--
parent {
address-cells = <1>;
size-cells = <0>;
reg = <0x1000 0x1000>;

child {
reg = <0xa00>;
};
};

code:

dev_get_reg(child) - returns '0xa00'
--

I would like to distinguish few things:

1. This patch just adds the support for the above second case, which is 
sensible and possible from specification point of view.


2. How it will be used by the code - is another thing.

3. If some driver's code can just use of dev_get_addr() for it's case,
then why shouldn't it? Since it, knows how to interpret the returned 
value in its own specified way - and also it's described by the proper 
binding file, what the reg represents - then I don't threat this as 
issue. And here the example may be:

- s5p_gpio.c - exynos GPIO driver

4. If I update the commit message with a general naming convention 
(parent/children) instead of using I2C suggestion - will be that patch 
acceptable for you?


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: fix address cell count checking in fdt_translate_address()

2016-01-08 Thread Przemyslaw Marczak


Hello Simon,

On 01/07/2016 08:24 PM, Simon Glass wrote:

+Stephen

On 4 January 2016 at 17:59, Simon Glass <s...@chromium.org> wrote:

Hi Przemyslaw,

On 5 November 2015 at 23:47, Stefan Roese <s...@denx.de> wrote:

On 06.11.2015 04:16, Simon Glass wrote:


Hi,

On 3 November 2015 at 02:57, Przemyslaw Marczak <p.marc...@samsung.com>
wrote:


Hello All,


On 10/29/2015 06:15 PM, Simon Glass wrote:



Hi Stefan,

On 28 October 2015 at 08:37, Przemyslaw Marczak <p.marc...@samsung.com>
wrote:



Commit: dm: core: Enable optional use of fdt_translate_address()

Enables use of this function as default, but after this it's not
possible to get dev address for the case in which: '#size-cells == 0'

This causes errors when getting address for some GPIOs, for which
the '#size-cells' is set to 0.

Example error:
'__of_translate_address: Bad cell count for gpx0'

Allowing for that case by modifying the macro 'OF_CHECK_COUNTS',
(called from )__of_translate_address(), fixes the issue.

Now, this macro doesn't check, that '#size-cells' is greater than 0.

This is possible from the specification point of view, but I'm not sure
that it doesn't introduce a regression for other configs.

Please test and share the results.

Tested-on: Odroid U3, Odroid X2, Odroid XU3, Sandbox.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Masahiro Yamada <yamada.masah...@socionext.com>
Cc: Lukasz Majewski <l.majew...@samsung.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Stefan Roese <s...@denx.de>
Cc: Simon Glass <s...@chromium.org>
Cc: Bin Meng <bmeng...@gmail.com>
Cc: Marek Vasut <ma...@denx.de>
---
common/fdt_support.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index f86365e..5f808cc 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -946,8 +946,7 @@ void fdt_del_node_and_alias(void *blob, const char
*alias)
/* Max address size we deal with */
#define OF_MAX_ADDR_CELLS  4
#define OF_BAD_ADDR((u64)-1)
-#define OF_CHECK_COUNTS(na, ns)((na) > 0 && (na) <=
OF_MAX_ADDR_CELLS && \
-   (ns) > 0)
+#define OF_CHECK_COUNTS(na)((na) > 0 && (na) <= OF_MAX_ADDR_CELLS)

/* Debug utility */
#ifdef DEBUG
@@ -1115,7 +1114,7 @@ static u64 __of_translate_address(void *blob, int
node_offset, const fdt32_t *in

   /* Cound address cells & copy address locally */
   bus->count_cells(blob, parent, , );
-   if (!OF_CHECK_COUNTS(na, ns)) {
+   if (!OF_CHECK_COUNTS(na)) {




This seems to conflict with the comment at the top of this function:

* Note: We consider that crossing any level with #size-cells == 0 to
mean
* that translation is impossible (that is we are not dealing with a
value
* that can be mapped to a cpu physical address). This is not really
specified
* that way, but this is traditionally the way IBM at least do things

What should we do here?



Is that commit acceptable? I would like send V2 with removing the above
comment.



That's what I am worried about. Presumably the comment is accurate
today and this check has some value. I was hoping Stefan might know.



Unfortunately no. I just stumbled over this problem with the
translation of the "complex" ranges on the MVEBU platform. And
noticed that we already have this functionality to translate
the addresses the "right way".

I'm wondering how this problem with those GPIOs is handled in
the kernel? I assume that it is working correctly there, right?
Przemyslaw, could you perhaps check this and see, why its
working there? And change / fix it in U-Boot accordingly?


Let's pick up this patch for now as a bug-fix. We can deal with this
problem after the release.


Applied to u-boot-dm/master.

I'll post a revert after the release. It seems like you and Stephen
are making good progress.

- Simon




Why so fast with this one?

I think, that more proper for a temporary fix is my latest patch with 
#size-cells count checking only if ranges found in the parent node.


I will continue the discussion with Stephen.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Allow fdt_translate_address() to work with buses

2016-01-07 Thread Przemyslaw Marczak


Hello,

On 01/05/2016 06:26 PM, Stephen Warren wrote:

On 01/05/2016 08:47 AM, Przemyslaw Marczak wrote:

Hello,

On 01/05/2016 02:00 AM, Simon Glass wrote:

Hi Stephen,

On 4 January 2016 at 13:15, Stephen Warren <swar...@wwwdotorg.org>
wrote:

On 01/03/2016 04:04 PM, Simon Glass wrote:


It is common for I2C and SPI buses to have a single-cell address and a
size
of 0. These produce a warning at present. For example on snow:

__of_translate_address: Bad cell count for gpc4
__of_translate_address: Bad cell count for gpx0
__of_translate_address: Bad cell count for gpv2
__of_translate_address: Bad cell count for gpv4

One of the nodes in question looks like this in part:

 pinctrl_2: pinctrl@10d1 {
 #address-cells = <1>;
 #size-cells = <0>;
 gpv2: gpv2 {
 reg = <0x060>;
 };
 gpv4: gpv4 {
 reg = <0xc0>;
 };
 };

This is clearly valid so it looks like the conversion to use
fdt_translate_address() in dev_get_addr() is not currently a good
move.



To disable that, why not simply turn off CONFIG_OF_TRANSLATE on the
affected
platforms? That's precisely why that config option was introduced
when the
call to fdt_translate_address() was added to dev_get_addr()?

That would prevent this patch from affecting platforms that don't
trigger
this issue, this leaving the valid check in place.


But since this breaks normal behaviour we don't know what platforms
are affected. We have made CONFIG_OF_TRANSLATE the default. So this
approach doesn't seem (in effect) any better than Przemyslaw's newer
series, below.




Przemyslaw Marczak sent three patches to resolve this for exynos
boards:

https://patchwork.ozlabs.org/patch/557008/
https://patchwork.ozlabs.org/patch/557010/
https://patchwork.ozlabs.org/patch/557009/

But this involves creating a new function, and everyone will need to
know
when to use which one. Also the problem may affect other boards.



I suggest adding an extra parameter to dev_get_addr() (or whatever
calls it)
that indicates the root of the address space. The check on #size-cells
should be skipped for that one node (or level of translation) but
enabled
for all other levels. This way, there would be no need for anyone to
choose
between functions; there'd only be one. Most cases (i.e. translation
of MMIO
addresses) would simply pass 0 as the extra parameter (for the root
node),
but in special cases where it's known translation is not expected to
reach
the root MMIO space (e.g. I2C, SPI controllers), the controller node
would
be passed in.


How would the caller know this root? It sounds plausible, but I do
want to avoid complex rules. I think you are saying that buses that
use their own address mechanism (i.e. not MMIO) must do something
special. The current dev_get_addr() is really simple.


Simon, Stephen

As a summary of the issue, please tell me your opinion about this:

Since the __of_translate_address() is called always with the "ranges" as
an argument, it looks reasonable to check it at the function beginning,
that the "ranges" property exists in the parent node.

If not exists - then don't check the size-cells count and this should
fix the problem with additional argument.
This is simple and correct from specification point of view - which says
ranges and #size-cells property's - are not required [ePAPR v1.1].


It /might/ indeed be reasonable to skip the check on #size-cells if
there is no ranges property; a missing ranges property is already
treated as a 1:1 translation as described by the comment at the top of
of_translate_one(). Still, there are likely some edge-cases w.r.t. the
"length" fields in the ranges property that would need to be thought
through in more detail before I'd say for certain that this change does
absolutely make sense.

Either way though, making that change wouldn't solve the problem at all.

It's simply not possible to translate an I2C device address beyond the
root of the I2C address space; there is no equivalent of an I2C device's
address in MMIO address space. The root of the problem is that the code
is attempting to perform an I2C->MMIO address translation. If we prevent
that (by capping any such translation at the root of the I2C address
space for example), the problem is solved at that point. Once that's
solved, the issue of translating across a boundary with #size-cells=0
will never appear, and hence does not need to be solved.




The problem with I2C and I2C->MMIO address translation is solved by my 
new patch. The specification is clear for such case, if reg can't be 
mapped to it's parent address space, then don't use 'ranges' and this 
can be easy solved by additional check.


Please review my new patch:

https://patchwork.ozlabs.org/patch/564246/

Best regards,
--
Przemyslaw Marczak
Sa

Re: [U-Boot] [PATCH 0/3] dm: add dev_get_reg() for getting device node's reg

2016-01-05 Thread Przemyslaw Marczak


Hello,

On 01/04/2016 09:06 PM, Stephen Warren wrote:

On 12/29/2015 01:47 AM, Przemyslaw Marczak wrote:

Hello Stephen,

On 12/16/2015 08:07 PM, Stephen Warren wrote:

On 12/16/2015 11:53 AM, Stephen Warren wrote:

On 12/15/2015 09:32 AM, Przemyslaw Marczak wrote:

commit: dm: core: Enable optional use of fdt_translate_address()

enables device's bus/child address translation method, depending
on bus 'ranges' property and including child 'reg' property.
This change makes impossible to decode the 'reg' for node with
'#size-cells' equal to 0.

Such case is possible by the specification and is also used in U-Boot,
e.g. by I2C uclass or S5P GPIO - the last one is broken at present.


Can you please explain the problem you're seeing in more detail?
Without
any context, my initial reaction is that this is simply a bug
somewhere.
That bug should be fixed, rather than introducing new APIs to hide the
problem.


Ah, I guess the problem is caused by the following code in
__of_translate_address():

 bus->count_cells(blob, parent, , );
 if (!OF_CHECK_COUNTS(na, ns)) {
 printf("%s: Bad cell count for %s\n", __FUNCTION__,



Yes, and this is what my previous patch 'fixes'.

[1] https://patchwork.ozlabs.org/patch/537372/

However Linux makes the translate in the same way.


That's because the function assumes it's called for MMIO addresses.
However, reg values for I2C devices aren't MMIO addresses, so those
assumptions don't apply. So, there is an argument for introducing some
new functionality. I'm not sure that a whole new function is the correct
way to go though. Rather, the existing translation functions should be
enhanced to know the location of root of the address space that contains
the address that's being translated. Then, translation can stop there.


This is okay but then, all device tree blobs should be defined in a
proper way.


Well, why shouldn't that be true? There are rules for how DTs must be
constructed. Nobody should expect DTs that violate those rules to work
in any particular way.


The problem is, that there are some additions and various assumptions in
the drivers, e.g. the exynos gpio driver (s5p_gpio.c) is checking the
reg's property value for each bank. But the driver in Linux hardcodes
those values, however for both cases this is wrong, because the gpio
regs could be mapped with ranges.


It sounds like there are many bugs to fix:-)



Unfortunately... :(


Even that issues above, I would prefer introduce a function or modify
the existing one to allow keeping this as it is.


Adding an extra function sounds OK, although I stand by my comment that
the caller should pass in a parameter indicating the root of the address
space, so that both #address-cells and #size-cells can be checked all
the way up the chain, and #size-cells should only be allowed to be 0 at
the root of the translation, not at any intermediate point.


Something like skipping the check on ns in the above code if parent ==
addr_space_root_offset, and also terminating the for (;;) loop in that
function under a similar condition.

This would allow for translation to occur for buses other than the CPU's
root MMIO space, yet not attempt to translate across known address space
boundaries (i.e. where address translation is known to be impossible).


To achieve this functionality, it should be enough to take my first
patch [1]. And then if no "ranges" is defined, then we have 1:1
translation.


I don't think so; that patch removes all checks on #size-cells rather
than only removing/ignoring the check at the root of the address space.


I think, that it is safe, but then we will have a different assumptions,
than in the Linux - is it acceptable?


Both Linux and U-Boot should conform to the DT specification. So, if
there's a difference between the two, there's likely a bug.




According to your comments with the new parameter, I think that we don't 
need this. As Simon wrote in one of his reply:


 "How would the caller know this root?".

What about adding a check that the parent defines "ranges" property and 
if not - then don't check the #size-cells?


So with this simple check, we could fix all present issues, beside the 
later fdt/drivers fixing.


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] dm: add dev_get_reg() for getting device node's reg

2016-01-05 Thread Przemyslaw Marczak


Hello,

On 01/04/2016 09:02 PM, Stephen Warren wrote:

On 12/29/2015 01:47 AM, Przemyslaw Marczak wrote:

Hello Stephen,

On 12/16/2015 07:53 PM, Stephen Warren wrote:

On 12/15/2015 09:32 AM, Przemyslaw Marczak wrote:

commit: dm: core: Enable optional use of fdt_translate_address()

enables device's bus/child address translation method, depending
on bus 'ranges' property and including child 'reg' property.
This change makes impossible to decode the 'reg' for node with
'#size-cells' equal to 0.

Such case is possible by the specification and is also used in U-Boot,
e.g. by I2C uclass or S5P GPIO - the last one is broken at present.


Can you please explain the problem you're seeing in more detail? Without
any context, my initial reaction is that this is simply a bug somewhere.
That bug should be fixed, rather than introducing new APIs to hide the
problem.



Some time ago I send a patch with such fix:

[1] https://patchwork.ozlabs.org/patch/537372/

Sorry, I didn't add you to the 'CC' list.

However. I checked this in linux, and the code is the same, the
size-cells == 0 is not supported also in Linux.


The discussion there does indicate that removing the check on
#size-cells would be incorrect.



Ok, this probably would be good if we assume that dts is always well 
written, so this is not acceptable.



So to prevent breaking some consistency in parsing fdt between U-boot
and Linux, I sent the patch which adds dev_get_reg(). And it seem to be
useful at least for I2C and Exynos GPIO driver.


OK; as I mentioned in my other reply, some form of new function or new
parameter does seem reasonable here.

...


At this point I can say, that the device-tree files and some compatible 
drivers are using wrong assumptions.


I think, that adding the new function is not needed, and also that we 
don't need any new parameter to the function dev_get_reg(),

because the right way is to fix the fdt.

For the Exynos GPIO issue, we can use two cases:
- define proper ranges
- move  #size-cells=0 to #size-cells=1 and extend the reg property by 
it's size (actually not too much to do)


This will fix the Exynos boot issue.


Looking at arch/arm/dts/exynos4412-trats2.dts, I see the following:


i2c@138d {
 samsung,i2c-sda-delay = <100>;
 samsung,i2c-slave-addr = <0x10>;
 samsung,i2c-max-bus-freq = <10>;
 status = "okay";

 max77686_pmic@09 {
 compatible = "maxim,max77686";
 interrupts = <7 0>;
 reg = <0x09 0 0>;

Is that the node you're having problems with? If so, I believe this may
simply be due to invalid DT content. In exynos4.dtsi, that i2c node is
defined as:

 i2c@138d {
 #address-cells = <1>;
 #size-cells = <0>;

Thus, any reg property in a child of that node must only contain a
single cell (the sum of #address-cells and #size-cells in the parent).
Does fixing the DT so it's valid solve your issue at all?


Nice hit above! However we don't use DM API yet for the above example,
so probably this is why it is still working - currently, the driver uses
fdtdec_get_int(), for getting this value.

But for test, after switching it to use of sequence: fdt_getprop() ->
fdt_translate_address(), then I can see the warning:

 cut 
_of_translate_address: Bad cell count for max77686_pmic@09
 cut 

And for the above issue - applying patch [1] - allows return the right
device address: 0x9 - without FDT modifying.

Now, I checked, why the above example compiles by dtc with no warning.
It looks, that dtc ignores some child's reg cells-count combination:


dtc doesn't check that the length of the reg property is *equal* to the
sum of #address-cells and #size-cells, but rather that the length is a
*multiple* of that value. This is because the reg property can contain
multiple addresses.


 case 1 -
parent {
 #address-cells = <1>;
 #size-cells = <0>;
 child {
 reg = <0x9>;
 };
};
This is ok!


This is "1 * (1 + 0)".


 case 2 -
parent {
 #address-cells = <1>;
 #size-cells = <0>;
 child {
 reg = <0x9 0 0>;
 };
};
This is ok: (the 2nd and 3rd child's cells are ignored by dtc)


The extra cells aren't ignored; the length is "3 * (1 + 0)".

 case 3 -
parent {
 #address-cells = <1>;
 #size-cells = <1>;
 child {
 reg = <0x9 0 0>;
 };
};

This is wrong! dtc warning:
Warning (reg_format): "reg" property in /i2c@138d/max77686_pmic has
invalid length (12 bytes) (#address-cells == 1, #size-cells == 1)


Yes, this is "1.5 * (1 + 1)", yet the "1.5" isn't an integer, hence the
warning is triggered.




Also thank you for the explanation.

Best regards,
--
Przemys

Re: [U-Boot] [PATCH] fdt: Allow fdt_translate_address() to work with buses

2016-01-05 Thread Przemyslaw Marczak


Hello,

On 01/05/2016 02:00 AM, Simon Glass wrote:

Hi Stephen,

On 4 January 2016 at 13:15, Stephen Warren <swar...@wwwdotorg.org> wrote:

On 01/03/2016 04:04 PM, Simon Glass wrote:


It is common for I2C and SPI buses to have a single-cell address and a
size
of 0. These produce a warning at present. For example on snow:

__of_translate_address: Bad cell count for gpc4
__of_translate_address: Bad cell count for gpx0
__of_translate_address: Bad cell count for gpv2
__of_translate_address: Bad cell count for gpv4

One of the nodes in question looks like this in part:

 pinctrl_2: pinctrl@10d1 {
 #address-cells = <1>;
 #size-cells = <0>;
 gpv2: gpv2 {
 reg = <0x060>;
 };
 gpv4: gpv4 {
 reg = <0xc0>;
 };
 };

This is clearly valid so it looks like the conversion to use
fdt_translate_address() in dev_get_addr() is not currently a good move.



To disable that, why not simply turn off CONFIG_OF_TRANSLATE on the affected
platforms? That's precisely why that config option was introduced when the
call to fdt_translate_address() was added to dev_get_addr()?

That would prevent this patch from affecting platforms that don't trigger
this issue, this leaving the valid check in place.


But since this breaks normal behaviour we don't know what platforms
are affected. We have made CONFIG_OF_TRANSLATE the default. So this
approach doesn't seem (in effect) any better than Przemyslaw's newer
series, below.




Przemyslaw Marczak sent three patches to resolve this for exynos boards:

https://patchwork.ozlabs.org/patch/557008/
https://patchwork.ozlabs.org/patch/557010/
https://patchwork.ozlabs.org/patch/557009/

But this involves creating a new function, and everyone will need to know
when to use which one. Also the problem may affect other boards.



I suggest adding an extra parameter to dev_get_addr() (or whatever calls it)
that indicates the root of the address space. The check on #size-cells
should be skipped for that one node (or level of translation) but enabled
for all other levels. This way, there would be no need for anyone to choose
between functions; there'd only be one. Most cases (i.e. translation of MMIO
addresses) would simply pass 0 as the extra parameter (for the root node),
but in special cases where it's known translation is not expected to reach
the root MMIO space (e.g. I2C, SPI controllers), the controller node would
be passed in.


How would the caller know this root? It sounds plausible, but I do
want to avoid complex rules. I think you are saying that buses that
use their own address mechanism (i.e. not MMIO) must do something
special. The current dev_get_addr() is really simple.

Regards,
Simon




Simon, Stephen

As a summary of the issue, please tell me your opinion about this:

Since the __of_translate_address() is called always with the "ranges" as 
an argument, it looks reasonable to check it at the function beginning, 
that the "ranges" property exists in the parent node.


If not exists - then don't check the size-cells count and this should 
fix the problem with additional argument.
This is simple and correct from specification point of view - which says 
ranges and #size-cells property's - are not required [ePAPR v1.1].


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fdt: Allow fdt_translate_address() to work with buses

2016-01-04 Thread Przemyslaw Marczak


Hello Simon,

On 01/04/2016 12:04 AM, Simon Glass wrote:

It is common for I2C and SPI buses to have a single-cell address and a size
of 0. These produce a warning at present. For example on snow:

__of_translate_address: Bad cell count for gpc4
__of_translate_address: Bad cell count for gpx0
__of_translate_address: Bad cell count for gpv2
__of_translate_address: Bad cell count for gpv4

One of the nodes in question looks like this in part:

pinctrl_2: pinctrl@10d1 {
#address-cells = <1>;
#size-cells = <0>;
gpv2: gpv2 {
reg = <0x060>;
};
gpv4: gpv4 {
reg = <0xc0>;
};
};

This is clearly valid so it looks like the conversion to use
fdt_translate_address() in dev_get_addr() is not currently a good move.

Przemyslaw Marczak sent three patches to resolve this for exynos boards:

https://patchwork.ozlabs.org/patch/557008/
https://patchwork.ozlabs.org/patch/557010/
https://patchwork.ozlabs.org/patch/557009/

But this involves creating a new function, and everyone will need to know
when to use which one. Also the problem may affect other boards.

Instead we can relax the contraint that there must be at least one size
cell. This fixes the problem on snow and should not affect anything else,
since the error check should not fire on normal device trees anyway.

After the release we will have more time to come up with a better solution,
if one exists.

Signed-off-by: Simon Glass <s...@chromium.org>
---

  common/fdt_support.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 66464db..43c5fa8 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -952,8 +952,7 @@ void fdt_del_node_and_alias(void *blob, const char *alias)
  /* Max address size we deal with */
  #define OF_MAX_ADDR_CELLS 4
  #define OF_BAD_ADDR   FDT_ADDR_T_NONE
-#define OF_CHECK_COUNTS(na, ns)((na) > 0 && (na) <= OF_MAX_ADDR_CELLS 
&& \
-   (ns) > 0)
+#define OF_CHECK_COUNTS(na, ns)((na) > 0 && (na) <= OF_MAX_ADDR_CELLS)

  /* Debug utility */
  #ifdef DEBUG



The patch with this fix was send by me some time ago:

https://patchwork.ozlabs.org/patch/537372/

It actually do the same, what your patch does.

And my next three patches (adding dev_get_reg()), which you mentioned, 
are another way to fix the issue.


So I think, we should choose between those two ways.

However the first one breaks the consistency with the kernel:

drivers/of/address.c: __of_translate_address()

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] dm: add dev_get_reg() for getting device node's reg

2015-12-29 Thread Przemyslaw Marczak


Hello Stephen,

On 12/16/2015 07:53 PM, Stephen Warren wrote:

On 12/15/2015 09:32 AM, Przemyslaw Marczak wrote:

commit: dm: core: Enable optional use of fdt_translate_address()

enables device's bus/child address translation method, depending
on bus 'ranges' property and including child 'reg' property.
This change makes impossible to decode the 'reg' for node with
'#size-cells' equal to 0.

Such case is possible by the specification and is also used in U-Boot,
e.g. by I2C uclass or S5P GPIO - the last one is broken at present.


Can you please explain the problem you're seeing in more detail? Without
any context, my initial reaction is that this is simply a bug somewhere.
That bug should be fixed, rather than introducing new APIs to hide the
problem.



Some time ago I send a patch with such fix:

[1] https://patchwork.ozlabs.org/patch/537372/

Sorry, I didn't add you to the 'CC' list.

However. I checked this in linux, and the code is the same, the 
size-cells == 0 is not supported also in Linux.


So to prevent breaking some consistency in parsing fdt between U-boot 
and Linux, I sent the patch which adds dev_get_reg(). And it seem to be 
useful at least for I2C and Exynos GPIO driver.



For this purpose this patch set introduces new core function:
  fdt_addr_t dev_get_reg(struct udevice *dev)
which returns the 'reg' value in the same way as previously
dev_get_addr().

This fixes s5p gpio driver and booting issue on few Exynos based boards:
- Trats2
- Odroid U3/X2


Looking at arch/arm/dts/exynos4412-trats2.dts, I see the following:


i2c@138d {
 samsung,i2c-sda-delay = <100>;
 samsung,i2c-slave-addr = <0x10>;
 samsung,i2c-max-bus-freq = <10>;
 status = "okay";

 max77686_pmic@09 {
 compatible = "maxim,max77686";
 interrupts = <7 0>;
 reg = <0x09 0 0>;

Is that the node you're having problems with? If so, I believe this may
simply be due to invalid DT content. In exynos4.dtsi, that i2c node is
defined as:

 i2c@138d {
 #address-cells = <1>;
 #size-cells = <0>;

Thus, any reg property in a child of that node must only contain a
single cell (the sum of #address-cells and #size-cells in the parent).
Does fixing the DT so it's valid solve your issue at all?




Nice hit above! However we don't use DM API yet for the above example, 
so probably this is why it is still working - currently, the driver uses 
fdtdec_get_int(), for getting this value.


But for test, after switching it to use of sequence: fdt_getprop() -> 
fdt_translate_address(), then I can see the warning:


 cut 
_of_translate_address: Bad cell count for max77686_pmic@09
 cut 

And for the above issue - applying patch [1] - allows return the right 
device address: 0x9 - without FDT modifying.


Now, I checked, why the above example compiles by dtc with no warning.
It looks, that dtc ignores some child's reg cells-count combination:

 case 1 -
parent {
#address-cells = <1>;
#size-cells = <0>;
child {
reg = <0x9>;
};
};
This is ok!

 case 2 -
parent {
#address-cells = <1>;
#size-cells = <0>;
child {
reg = <0x9 0 0>;
};
};
This is ok: (the 2nd and 3rd child's cells are ignored by dtc)

 case 3 -
parent {
#address-cells = <1>;
#size-cells = <1>;
child {
reg = <0x9 0 0>;
};
};

This is wrong! dtc warning:
Warning (reg_format): "reg" property in /i2c@138d/max77686_pmic has 
invalid length (12 bytes) (#address-cells == 1, #size-cells == 1)




Now I don't have a time for checking it in dtc code, however we can 
check in U-Boot, that the dtb is not coherent?


So I can compile my default dts - no dtc warnings, and next in U-Boot I 
can see:


 check i2c node 
Trats2 # fdt list /i2c@138d
i2c@138d {
#address-cells = <0x0001>;
#size-cells = <0x>;
compatible = "samsung,s3c2440-i2c";
reg = <0x138d 0x0100>;
interrupts = <0x0007 0x003f 0x>;
samsung,i2c-sda-delay = <0x0064>;
samsung,i2c-slave-addr = <0x0010>;
samsung,i2c-max-bus-freq = <0x000186a0>;
status = "okay";
max77686_pmic@09 {
};
};

 check pmic node 
Trats2 # fdt list /i2c@138d/max77686_pmic@09
max77686_pmic@09 {
compatible = "maxim,max77686";
interrupts = <0x0007 0x>;
reg = <0x0009 0x 0x>;
#clock-cells = <0x0001>;

Re: [U-Boot] [PATCH 0/3] dm: add dev_get_reg() for getting device node's reg

2015-12-29 Thread Przemyslaw Marczak


Hello Stephen,

On 12/16/2015 08:07 PM, Stephen Warren wrote:

On 12/16/2015 11:53 AM, Stephen Warren wrote:

On 12/15/2015 09:32 AM, Przemyslaw Marczak wrote:

commit: dm: core: Enable optional use of fdt_translate_address()

enables device's bus/child address translation method, depending
on bus 'ranges' property and including child 'reg' property.
This change makes impossible to decode the 'reg' for node with
'#size-cells' equal to 0.

Such case is possible by the specification and is also used in U-Boot,
e.g. by I2C uclass or S5P GPIO - the last one is broken at present.


Can you please explain the problem you're seeing in more detail? Without
any context, my initial reaction is that this is simply a bug somewhere.
That bug should be fixed, rather than introducing new APIs to hide the
problem.


Ah, I guess the problem is caused by the following code in
__of_translate_address():

 bus->count_cells(blob, parent, , );
 if (!OF_CHECK_COUNTS(na, ns)) {
 printf("%s: Bad cell count for %s\n", __FUNCTION__,



Yes, and this is what my previous patch 'fixes'.

[1] https://patchwork.ozlabs.org/patch/537372/

However Linux makes the translate in the same way.


That's because the function assumes it's called for MMIO addresses.
However, reg values for I2C devices aren't MMIO addresses, so those
assumptions don't apply. So, there is an argument for introducing some
new functionality. I'm not sure that a whole new function is the correct
way to go though. Rather, the existing translation functions should be
enhanced to know the location of root of the address space that contains
the address that's being translated. Then, translation can stop there.


This is okay but then, all device tree blobs should be defined in a 
proper way.
The problem is, that there are some additions and various assumptions in 
the drivers, e.g. the exynos gpio driver (s5p_gpio.c) is checking the 
reg's property value for each bank. But the driver in Linux hardcodes 
those values, however for both cases this is wrong, because the gpio 
regs could be mapped with ranges.


Even that issues above, I would prefer introduce a function or modify 
the existing one to allow keeping this as it is.




Something like skipping the check on ns in the above code if parent ==
addr_space_root_offset, and also terminating the for (;;) loop in that
function under a similar condition.

This would allow for translation to occur for buses other than the CPU's
root MMIO space, yet not attempt to translate across known address space
boundaries (i.e. where address translation is known to be impossible).




To achieve this functionality, it should be enough to take my first 
patch [1]. And then if no "ranges" is defined, then we have 1:1 translation.


I think, that it is safe, but then we will have a different assumptions, 
than in the Linux - is it acceptable?


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/3] gpio: s5p: use dev_get_reg() instead of dev_get_addr()

In a result of enabling the CONFIG_OF_TRANSLAE, function dev_get_addr(),
doesn't support device tree nodes with 'size-cells == 0'.

But this is the way how the s5p gpio driver's compatible device tree
nodes are defined. Switching the driver to use function dev_get_reg(),
fixes this issue.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Joe Hershberger <joe.hershber...@ni.com>
Cc: Stephen Warren <swar...@nvidia.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
 drivers/gpio/s5p_gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
index 0f22b23..383c6ce 100644
--- a/drivers/gpio/s5p_gpio.c
+++ b/drivers/gpio/s5p_gpio.c
@@ -350,7 +350,7 @@ static int gpio_exynos_bind(struct udevice *parent)
 
dev->of_offset = node;
 
-   reg = dev_get_addr(dev);
+   reg = dev_get_reg(dev);
if (reg != FDT_ADDR_T_NONE)
bank = (struct s5p_gpio_bank *)((ulong)base + reg);
 
-- 
1.9.1

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

[U-Boot] [PATCH 1/3] dm: core: extend API by new function: dev_get_reg()

After changes introduced to dev_get_addr() by:

commit: dm: core: Enable optional use of fdt_translate_address()

the mentioned function is not allowed to parse the 'reg' property
of child node for which the '#size-cells == 0'.

To fill the gap, this commit introduces new core function dev_get_reg(),
which makes it possible to get the 'reg' property's value for that use case.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Masahiro Yamada <yamada.masah...@socionext.com>
Cc: Simon Glass <s...@chromium.org>
Cc: Marek Vasut <ma...@denx.de>
Cc: Stefan Roese <s...@denx.de>
---
 drivers/core/device.c | 17 +
 include/dm/device.h   | 23 +++
 2 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 758f390..1131175 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -581,6 +581,18 @@ const char *dev_get_uclass_name(struct udevice *dev)
return dev->uclass->uc_drv->name;
 }
 
+fdt_addr_t dev_get_reg(struct udevice *dev)
+{
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+   return fdtdec_get_addr_size_auto_parent(gd->fdt_blob,
+   dev->parent->of_offset,
+   dev->of_offset, "reg",
+   0, NULL);
+#else
+   return FDT_ADDR_T_NONE;
+#endif
+}
+
 fdt_addr_t dev_get_addr(struct udevice *dev)
 {
 #if CONFIG_IS_ENABLED(OF_CONTROL)
@@ -601,14 +613,11 @@ fdt_addr_t dev_get_addr(struct udevice *dev)
 dev->of_offset, reg);
}
 
+   addr = dev_get_reg(dev);
/*
 * Use the "simple" translate function for less complex
 * bus setups.
 */
-   addr = fdtdec_get_addr_size_auto_parent(gd->fdt_blob,
-   dev->parent->of_offset,
-   dev->of_offset, "reg",
-   0, NULL);
if (CONFIG_IS_ENABLED(SIMPLE_BUS) && addr != FDT_ADDR_T_NONE) {
if (device_get_uclass_id(dev->parent) == UCLASS_SIMPLE_BUS)
addr = simple_bus_translate(dev->parent, addr);
diff --git a/include/dm/device.h b/include/dm/device.h
index 7fb9935..08bcb02 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -445,8 +445,31 @@ int device_find_first_child(struct udevice *parent, struct 
udevice **devp);
 int device_find_next_child(struct udevice **devp);
 
 /**
+ * dev_get_reg() - Get the reg property of a device
+ *
+ * This returns the address without bus/child address space translation.
+ *
+ * @dev: Pointer to a device
+ *
+ * @return addr
+ */
+fdt_addr_t dev_get_reg(struct udevice *dev);
+
+/**
  * dev_get_addr() - Get the reg property of a device
  *
+ * The returned address value depends on a config options:
+ * Case 1: CONFIG_OF_TRANSLATE=y (default)
+ * Result: Make bus/child address space translation, that dependents on 
"ranges"
+ * property.
+ *
+ * Case 2: CONFIG_OF_TRANSLATE is not set
+ * Result: Decode only device node's 'reg' property, without translation.
+ *
+ * Case 3: CONFIG_OF_TRANSLATE is not set; CONFIG_SIMPLE_BUS=y
+ * Result: When 'dev->parent' is a simple bus - then do the same as in case 1,
+ * otherwise do the same as in case 2.
+ *
  * @dev: Pointer to a device
  *
  * @return addr
-- 
1.9.1

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

[U-Boot] [PATCH 3/3] dm: i2c: get chip address with dev_get_reg()

This commit cleanups the I2C uclass driver by:
- simplify i2c_child_post_bind() method
- cleanups i2c_chip_ofdata_to_platdata(), by calling dev_get_reg()
  for getting chip address

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Masahiro Yamada <yamada.masah...@socionext.com>
Cc: Joe Hershberger <joe.hershber...@ni.com>
Cc: Simon Glass <s...@chromium.org>
Cc: Heiko Schocher <h...@denx.de>
Cc: Stefan Roese <s...@denx.de>
---
 drivers/i2c/i2c-uclass.c | 17 -
 include/i2c.h| 11 ---
 2 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index 50b99ea..3cfbd22 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -467,16 +467,17 @@ int i2c_deblock(struct udevice *bus)
return ops->deblock(bus);
 }
 
-int i2c_chip_ofdata_to_platdata(const void *blob, int node,
-   struct dm_i2c_chip *chip)
+int i2c_chip_ofdata_to_platdata(struct udevice *dev)
 {
-   chip->offset_len = fdtdec_get_int(gd->fdt_blob, node,
+   struct dm_i2c_chip *chip = dev_get_parent_platdata(dev);
+
+   chip->offset_len = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
  "u-boot,i2c-offset-len", 1);
chip->flags = 0;
-   chip->chip_addr = fdtdec_get_int(gd->fdt_blob, node, "reg", -1);
-   if (chip->chip_addr == -1) {
+   chip->chip_addr = dev_get_reg(dev);
+   if (chip->chip_addr == FDT_ADDR_T_NONE) {
debug("%s: I2C Node '%s' has no 'reg' property\n", __func__,
- fdt_get_name(blob, node, NULL));
+ fdt_get_name(gd->fdt_blob, dev->of_offset, NULL));
return -EINVAL;
}
 
@@ -501,12 +502,10 @@ static int i2c_post_bind(struct udevice *dev)
 
 static int i2c_child_post_bind(struct udevice *dev)
 {
-   struct dm_i2c_chip *plat = dev_get_parent_platdata(dev);
-
if (dev->of_offset == -1)
return 0;
 
-   return i2c_chip_ofdata_to_platdata(gd->fdt_blob, dev->of_offset, plat);
+   return i2c_chip_ofdata_to_platdata(dev);
 }
 
 UCLASS_DRIVER(i2c) = {
diff --git a/include/i2c.h b/include/i2c.h
index 1f5ae45..c5bb39c 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -518,15 +518,12 @@ int i2c_get_chip_for_busnum(int busnum, int chip_addr, 
uint offset_len,
  * i2c_chip_ofdata_to_platdata() - Decode standard I2C platform data
  *
  * This decodes the chip address from a device tree node and puts it into
- * its dm_i2c_chip structure. This should be called in your driver's
- * ofdata_to_platdata() method.
+ * its dm_i2c_chip structure. This is called after device's bind inside
+ * uclass driver's i2c_child_post_bind() method.
  *
- * @blob:  Device tree blob
- * @node:  Node offset to read from
- * @spi:   Place to put the decoded information
+ * @dev:   pointer to a chip device
  */
-int i2c_chip_ofdata_to_platdata(const void *blob, int node,
-   struct dm_i2c_chip *chip);
+int i2c_chip_ofdata_to_platdata(struct udevice *dev);
 
 /**
  * i2c_dump_msgs() - Dump a list of I2C messages
-- 
1.9.1

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

[U-Boot] [PATCH 0/3] dm: add dev_get_reg() for getting device node's reg

commit: dm: core: Enable optional use of fdt_translate_address()

enables device's bus/child address translation method, depending
on bus 'ranges' property and including child 'reg' property.
This change makes impossible to decode the 'reg' for node with
'#size-cells' equal to 0.

Such case is possible by the specification and is also used in U-Boot,
e.g. by I2C uclass or S5P GPIO - the last one is broken at present.

For this purpose this patch set introduces new core function:
 fdt_addr_t dev_get_reg(struct udevice *dev)
which returns the 'reg' value in the same way as previously dev_get_addr().

This fixes s5p gpio driver and booting issue on few Exynos based boards:
- Trats2
- Odroid U3/X2

As an example of use, this patch set also modifies i2c uclass driver
by using the new function for getting chip address.

Przemyslaw Marczak (3):
  dm: core: extend API by new function: dev_get_reg()
  gpio: s5p: use dev_get_reg() instead of dev_get_addr()
  dm: i2c: get chip address with dev_get_reg()

 drivers/core/device.c| 17 +
 drivers/gpio/s5p_gpio.c  |  2 +-
 drivers/i2c/i2c-uclass.c | 17 -
 include/dm/device.h  | 23 +++
 include/i2c.h| 11 ---
 5 files changed, 49 insertions(+), 21 deletions(-)

-- 
1.9.1

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

Re: [U-Boot] Samsung I2C driver

2015-12-11 Thread Przemyslaw Marczak


Hi,

On 12/11/2015 04:04 AM, Simon Glass wrote:

+David, who is the vcma9 maintainer.

Hi Przemyslaw,

On 7 December 2015 at 07:00, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

Hello Simon,


On 12/07/2015 02:07 PM, Simon Glass wrote:


Hi Przemyslaw,

At present this driver has a few implementations and supports
non-device-tree and non-driver model. From I can see the odroid and
perhaps one other platform need conversion and then all of this old
stuff can be removed. Do you have any plans to look at this?

Regards,
Simon




Yes, this driver is very dirty and needs a big clean-up, however at present
I don't have time for doing this.

I can see that there are few boards that are using the old version of this
driver. I suppose that the "COMPAT" layer can be enabled for those boards
and everything should work as previous, right?

I can help you with the testing for Trats/Trats2/OdroidU3 if you want move
it on your own. I could take care of this, but no sooner than in the new
year.


I can leave it to you for when you have time. David are you able to
move your board to driver model for i2c?

Regards,
Simon




That's ok for me. I have plan to do few things around this task and I 
think, that David will have enough time to move his board to dm before I 
finish all my tasks.


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Odroid U3 not able to boot using latest u-boot.

2015-12-11 Thread Przemyslaw Marczak


Hello Anand,

On 12/11/2015 01:48 PM, Anand Moon wrote:

Hi Przemyslaw,

I have give it a try to put latest u-boot on my microsdcard
u-boot and it failed to boot. Could you help me out on this.

U-Boot 2016.01-rc2-25762-g00502fe (Dec 11 2015 - 17:49:34 +0530)

CPU:   Exynos4412 @ 1 GHz
Model: Odroid based on Exynos4412
Board: Odroid based on Exynos4412
Type:  u3
DRAM:  2 GiB
__of_translate_address: Bad cell count for gpf0
__of_translate_address: Bad cell count for gpj0
__of_translate_address: Bad cell count for gpk0
__of_translate_address: Bad cell count for gpm0
__of_translate_address: Bad cell count for gpx0
LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
LDO21@TFLASH_2.8V: set 280 uV; enabling
MMC:   EXYNOS DWMMC: 0
Card did not respond to voltage select!
*** Warning - MMC init failed, using default environment

Net:   No ethernet found.
Hit any key to stop autoboot:  0
** Bad device mmc 0 **
** Bad device mmc 0 **
** Bad device mmc 0 **
** Bad device mmc 0 **
Odroid #
Odroid #
Odroid #
Odroid #

-Anand Moon




Yes, I know about this issue. There is a patch which fixes this:

https://patchwork.ozlabs.org/patch/537372/

Please apply this patch locally, I will send another solution for this 
issue, since at present it may be unsafe for some cases on other platforms.


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Samsung I2C driver

2015-12-07 Thread Przemyslaw Marczak


Hello Simon,

On 12/07/2015 02:07 PM, Simon Glass wrote:

Hi Przemyslaw,

At present this driver has a few implementations and supports
non-device-tree and non-driver model. From I can see the odroid and
perhaps one other platform need conversion and then all of this old
stuff can be removed. Do you have any plans to look at this?

Regards,
Simon




Yes, this driver is very dirty and needs a big clean-up, however at 
present I don't have time for doing this.


I can see that there are few boards that are using the old version of 
this driver. I suppose that the "COMPAT" layer can be enabled for those 
boards and everything should work as previous, right?


I can help you with the testing for Trats/Trats2/OdroidU3 if you want 
move it on your own. I could take care of this, but no sooner than in 
the new year.


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: imx6: novena, gw_ventana: Fix use of pfuze100 bit definitions

2015-11-30 Thread Przemyslaw Marczak


Hello Stefano,

On 11/26/2015 02:08 PM, Marek Vasut wrote:

The following patch changed the PFUZE100 swbst register bit definitions
and broke PMIC configuration on multiple boards, at least on the novena
and gw_ventana. This patch fixes it.

commit 8fa46350a4c7dca7710362f6c871098557b934ad
Author: Peng Fan <peng@freescale.com>
Date:   Fri Aug 7 16:43:45 2015 +0800

 power: regulator: add pfuze100 support

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Fabio Estevam <fabio.este...@freescale.com>
Cc: Peng Fan <peng....@freescale.com>
Cc: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Tim Harvey <thar...@gateworks.com>
Cc: Vagrant Cascadian <vagr...@aikidev.net>
---
  board/gateworks/gw_ventana/common.c | 2 +-
  board/kosagi/novena/novena.c| 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)


Will you pick-up this patch, or should it go through PMIC tree?

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: imx6: novena, gw_ventana: Fix use of pfuze100 bit definitions

2015-11-30 Thread Przemyslaw Marczak



On 11/30/2015 11:00 AM, Stefano Babic wrote:

On 30/11/2015 10:53, Przemyslaw Marczak wrote:

Hello Stefano,

On 11/26/2015 02:08 PM, Marek Vasut wrote:

The following patch changed the PFUZE100 swbst register bit definitions
and broke PMIC configuration on multiple boards, at least on the novena
and gw_ventana. This patch fixes it.

commit 8fa46350a4c7dca7710362f6c871098557b934ad
Author: Peng Fan <peng@freescale.com>
Date:   Fri Aug 7 16:43:45 2015 +0800

  power: regulator: add pfuze100 support

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Fabio Estevam <fabio.este...@freescale.com>
Cc: Peng Fan <peng....@freescale.com>
Cc: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Tim Harvey <thar...@gateworks.com>
Cc: Vagrant Cascadian <vagr...@aikidev.net>
---
   board/gateworks/gw_ventana/common.c | 2 +-
   board/kosagi/novena/novena.c| 2 +-
   2 files changed, 2 insertions(+), 2 deletions(-)


Will you pick-up this patch, or should it go through PMIC tree?


They are i.MXes, I pick them up.

Best regards,
Stefano




Ok, thank you.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] pmic: Fix pfuze100 bit definitions


Hello Marek,

On 11/26/2015 12:15 AM, Marek Vasut wrote:

The following patch changed the PFUZE100 swbst register bit definitions
and broke PMIC configuration on multiple boards, at least on the novena
and gw_ventana. This patch fixes it.



Ok we missed this in the review. But as I can see it broken only the two 
boards, you mentioned.



commit 8fa46350a4c7dca7710362f6c871098557b934ad
Author: Peng Fan <peng@freescale.com>
Date:   Fri Aug 7 16:43:45 2015 +0800

 power: regulator: add pfuze100 support

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Fabio Estevam <fabio.este...@freescale.com>
Cc: Peng Fan <peng....@freescale.com>
Cc: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Tim Harvey <thar...@gateworks.com>
Cc: Vagrant Cascadian <vagr...@aikidev.net>
---
  include/power/pfuze100_pmic.h | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/power/pfuze100_pmic.h b/include/power/pfuze100_pmic.h
index 41cb710..cc019a9 100644
--- a/include/power/pfuze100_pmic.h
+++ b/include/power/pfuze100_pmic.h
@@ -215,10 +215,10 @@ enum {
  #define SWBST_VOL_MASK0x3
  #define SWBST_MODE_MASK   0xC
  #define SWBST_MODE_SHIFT 0x2
-#define SWBST_MODE_OFF 0
-#define SWBST_MODE_PFM 1
-#define SWBST_MODE_AUTO2
-#define SWBST_MODE_APS 3
+#define SWBST_MODE_OFF (0 << 2)
+#define SWBST_MODE_PFM (1 << 2)
+#define SWBST_MODE_AUTO(2 << 2)
+#define SWBST_MODE_APS (3 << 2)

  /*
   * Regulator Mode Control



The intentions are good, but this patch fixes one thing and breaks the 
another one, I would prefer avoid this.


'git grep -n SWBST_MODE'

As I can see, you can fix the issue for multiple boards by update only 
two lines in those two boards, which you mentioned.


So why you moving back those definitions, since they are now used in 
more places?


The line suggested by Peng is good enough to call it 'fix' for your boards:

(SWBST_MODE_AUTO << SWBST_MODE_SHIFT)

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] pmic: Fix pfuze100 bit definitions


Hello Marek,

On 11/26/2015 02:08 PM, Marek Vasut wrote:

On Thursday, November 26, 2015 at 01:21:36 PM, Przemyslaw Marczak wrote:

Hello Marek,


Hi,


On 11/26/2015 12:15 AM, Marek Vasut wrote:

The following patch changed the PFUZE100 swbst register bit definitions
and broke PMIC configuration on multiple boards, at least on the novena
and gw_ventana. This patch fixes it.


Ok we missed this in the review. But as I can see it broken only the two
boards, you mentioned.


commit 8fa46350a4c7dca7710362f6c871098557b934ad
Author: Peng Fan <peng@freescale.com>
Date:   Fri Aug 7 16:43:45 2015 +0800

  power: regulator: add pfuze100 support

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Fabio Estevam <fabio.este...@freescale.com>
Cc: Peng Fan <peng....@freescale.com>
Cc: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Tim Harvey <thar...@gateworks.com>
Cc: Vagrant Cascadian <vagr...@aikidev.net>
---

   include/power/pfuze100_pmic.h | 8 
   1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/power/pfuze100_pmic.h
b/include/power/pfuze100_pmic.h index 41cb710..cc019a9 100644
--- a/include/power/pfuze100_pmic.h
+++ b/include/power/pfuze100_pmic.h
@@ -215,10 +215,10 @@ enum {

   #define SWBST_VOL_MASK   0x3
   #define SWBST_MODE_MASK  0xC
   #define SWBST_MODE_SHIFT 0x2

-#define SWBST_MODE_OFF 0
-#define SWBST_MODE_PFM 1
-#define SWBST_MODE_AUTO2
-#define SWBST_MODE_APS 3
+#define SWBST_MODE_OFF (0 << 2)
+#define SWBST_MODE_PFM (1 << 2)
+#define SWBST_MODE_AUTO(2 << 2)
+#define SWBST_MODE_APS (3 << 2)

   /*

* Regulator Mode Control


The intentions are good, but this patch fixes one thing and breaks the
another one, I would prefer avoid this.

'git grep -n SWBST_MODE'

As I can see, you can fix the issue for multiple boards by update only
two lines in those two boards, which you mentioned.

So why you moving back those definitions, since they are now used in
more places?

The line suggested by Peng is good enough to call it 'fix' for your boards:

(SWBST_MODE_AUTO << SWBST_MODE_SHIFT)


OK, so instead of fixing the patch which introduced a bug, we're supposed to
be fixing the fallout from that. I cannot say I'm very happy with this sort
of handling of a bug and with the testing this particular change received.



You are right, the mentioned patch breaks your boards, and we missed 
this in the review as I mentioned - sorry for that.


But for now, there is also other code based on those definitions, so you 
can not just revert only this particular change and ignore the rest - 
because it breaks the new code? Should we all work in this way?


As a custodian I'm not able to test everything, especially when I don't 
have the hardware for it. Moreover I trust people who are working for 
this project and I can imagine that they test the code.



Besides, seeing how this patch already needed another patch to make it complete
and how it now needs more patches to fix the boards which it broke, I am really
disappointed.


I can't understand what is the problem. You send new patch with two 
simple lines - it fixes your issue and doesn't break the existing PMIC 
driver. I think, this is what we need here.




Best regards,
Marek Vasut




Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] pmic: Fix pfuze100 bit definitions


Hello Marek,

On 11/26/2015 04:39 PM, Marek Vasut wrote:

On Thursday, November 26, 2015 at 03:35:26 PM, Przemyslaw Marczak wrote:

Hello Marek,


Hi,


On 11/26/2015 02:08 PM, Marek Vasut wrote:

On Thursday, November 26, 2015 at 01:21:36 PM, Przemyslaw Marczak wrote:

Hello Marek,


Hi,


On 11/26/2015 12:15 AM, Marek Vasut wrote:

The following patch changed the PFUZE100 swbst register bit definitions
and broke PMIC configuration on multiple boards, at least on the novena
and gw_ventana. This patch fixes it.


Ok we missed this in the review. But as I can see it broken only the two
boards, you mentioned.


commit 8fa46350a4c7dca7710362f6c871098557b934ad
Author: Peng Fan <peng@freescale.com>
Date:   Fri Aug 7 16:43:45 2015 +0800

   power: regulator: add pfuze100 support

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Fabio Estevam <fabio.este...@freescale.com>
Cc: Peng Fan <peng....@freescale.com>
Cc: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Tim Harvey <thar...@gateworks.com>
Cc: Vagrant Cascadian <vagr...@aikidev.net>
---

include/power/pfuze100_pmic.h | 8 
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/power/pfuze100_pmic.h
b/include/power/pfuze100_pmic.h index 41cb710..cc019a9 100644
--- a/include/power/pfuze100_pmic.h
+++ b/include/power/pfuze100_pmic.h
@@ -215,10 +215,10 @@ enum {

#define SWBST_VOL_MASK  0x3
#define SWBST_MODE_MASK 0xC
#define SWBST_MODE_SHIFT 0x2

-#define SWBST_MODE_OFF 0
-#define SWBST_MODE_PFM 1
-#define SWBST_MODE_AUTO2
-#define SWBST_MODE_APS 3
+#define SWBST_MODE_OFF (0 << 2)
+#define SWBST_MODE_PFM (1 << 2)
+#define SWBST_MODE_AUTO(2 << 2)
+#define SWBST_MODE_APS (3 << 2)

/*

 * Regulator Mode Control


The intentions are good, but this patch fixes one thing and breaks the
another one, I would prefer avoid this.

'git grep -n SWBST_MODE'

As I can see, you can fix the issue for multiple boards by update only
two lines in those two boards, which you mentioned.

So why you moving back those definitions, since they are now used in
more places?

The line suggested by Peng is good enough to call it 'fix' for your
boards:

(SWBST_MODE_AUTO << SWBST_MODE_SHIFT)


OK, so instead of fixing the patch which introduced a bug, we're supposed
to be fixing the fallout from that. I cannot say I'm very happy with
this sort of handling of a bug and with the testing this particular
change received.


You are right, the mentioned patch breaks your boards, and we missed
this in the review as I mentioned - sorry for that.

But for now, there is also other code based on those definitions, so you
can not just revert only this particular change and ignore the rest -
because it breaks the new code? Should we all work in this way?


This is even worse then -- the patch adds code which uses the changed macros,
but doesn't fix the existing users. This should not happen again and it'd be
very nice if the author actually checked when digging in /include and changing
some macros there if this might affect someone.



Ok, but as you could check in this example, even recompile all boards 
with such kind of 'new patch' - will not tell you what is wrong, because 
it doesn't break the build...



As a custodian I'm not able to test everything, especially when I don't
have the hardware for it. Moreover I trust people who are working for
this project and I can imagine that they test the code.


I don't expect you to test anything in this case, other but possibly compile
testing the stuff, don't get me wrong.


Besides, seeing how this patch already needed another patch to make it
complete and how it now needs more patches to fix the boards which it
broke, I am really disappointed.


I can't understand what is the problem. You send new patch with two
simple lines - it fixes your issue and doesn't break the existing PMIC
driver. I think, this is what we need here.


I did that. And unfortunatelly, it turns out we have really no other option
now, than to fix the boards. Sigh ...



But isn't this also an important part of our job?

I don't know why we discuss about this...

Found bug? Can fix?
Then send a patch and don't blame the people for a bugs - it's natural.
Don't cry if got a comments - this is the Open Source project:)

I hope you don't get me wrong.

Have a nice weekend! - I'm starting it right now:)

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: imx6: novena, gw_ventana: Fix use of pfuze100 bit definitions


Hello Marek,

On 11/26/2015 02:08 PM, Marek Vasut wrote:

The following patch changed the PFUZE100 swbst register bit definitions
and broke PMIC configuration on multiple boards, at least on the novena
and gw_ventana. This patch fixes it.

commit 8fa46350a4c7dca7710362f6c871098557b934ad
Author: Peng Fan <peng@freescale.com>
Date:   Fri Aug 7 16:43:45 2015 +0800

 power: regulator: add pfuze100 support

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Fabio Estevam <fabio.este...@freescale.com>
Cc: Peng Fan <peng....@freescale.com>
Cc: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Stefano Babic <sba...@denx.de>
Cc: Tim Harvey <thar...@gateworks.com>
Cc: Vagrant Cascadian <vagr...@aikidev.net>
---
  board/gateworks/gw_ventana/common.c | 2 +-
  board/kosagi/novena/novena.c| 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/gateworks/gw_ventana/common.c 
b/board/gateworks/gw_ventana/common.c
index d406c83..a20190e 100644
--- a/board/gateworks/gw_ventana/common.c
+++ b/board/gateworks/gw_ventana/common.c
@@ -806,7 +806,7 @@ void setup_pmic(void)
/* Set SWBST to 5.0V and enable */
pmic_reg_read(p, PFUZE100_SWBSTCON1, );
reg &= ~(SWBST_MODE_MASK | SWBST_VOL_MASK);
-   reg |= (SWBST_5_00V | SWBST_MODE_AUTO);
+   reg |= (SWBST_5_00V | (SWBST_MODE_AUTO << 
SWBST_MODE_SHIFT));
pmic_reg_write(p, PFUZE100_SWBSTCON1, reg);
}
}
diff --git a/board/kosagi/novena/novena.c b/board/kosagi/novena/novena.c
index babba85..b3159d3 100644
--- a/board/kosagi/novena/novena.c
+++ b/board/kosagi/novena/novena.c
@@ -216,7 +216,7 @@ int power_init_board(void)
/* Set SWBST to 5.0V and enable (for USB) */
pmic_reg_read(p, PFUZE100_SWBSTCON1, );
reg &= ~(SWBST_MODE_MASK | SWBST_VOL_MASK);
-   reg |= (SWBST_5_00V | SWBST_MODE_AUTO);
+   reg |= (SWBST_5_00V | (SWBST_MODE_AUTO << SWBST_MODE_SHIFT));
pmic_reg_write(p, PFUZE100_SWBSTCON1, reg);

    return 0;



Thanks for fixing :)

Reviewed-by: Przemyslaw Marczak <p.marc...@samsung.com>

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 4/5] gpt: part: Definition and declaration of GPT verification functions


Hi Tom,

On 11/24/2015 07:56 PM, Tom Rini wrote:

On Tue, Nov 24, 2015 at 10:56:41AM +0100, Przemyslaw Marczak wrote:

Hello Tom,

On 11/23/2015 11:44 PM, Tom Rini wrote:

On Fri, Nov 20, 2015 at 08:06:16AM +0100, Lukasz Majewski wrote:


This commit provides definition and declaration of GPT verification
functions - namely gpt_verify_headers() and gpt_verify_partitions().
The former is used to only check CRC32 of GPT's header and PTEs.
The latter examines each partition entry and compare attributes such as:
name, start offset and size with ones provided at '$partitions' env
variable.

Signed-off-by: Lukasz Majewski <l.majew...@majess.pl>
Reviewed-by: Tom Rini <tr...@konsulko.com>
Reviewed-by: Przemyslaw Marczak <p.marc...@samsung.com>


Applied to u-boot/master, thanks!



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



Why merged so quickly?

I tested this patchset on my device and posted about the issues. [1]

This should be reworked, since the verify assumptions are too simple
and doesn't fully match the GPT header creation.
So this command will fail for some cases of write/verify sequence,
depending on what the $partitions includes.

[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg193216.html


Mainly because I skimmed things too quickly, sorry.  Also in the future
(and this applies to anyone that's a custodian, and people can also
manage their own patches if they login) please update patches you're
asking for changes on in patchwork, it really does help me keep an eye
on things.  Thanks!



OK, that's a good point.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size


Hello Tim, Marek

On 11/20/2015 10:40 PM, Tim Harvey wrote:

On Fri, Nov 20, 2015 at 12:43 PM, Marek Vasut <ma...@denx.de> wrote:

Using 50 MiB malloc pool in SPL is nonsense. Since the caches are not
enabled in SPL, it takes 2 seconds to init the pool and has no obvious
benefit. Reduce the size to 1 MiB.

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Stefano Babic <sba...@denx.de>
Cc: Tim Harvey <thar...@gateworks.com>
---
  include/configs/imx6_spl.h | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h
index 1744f2c..43ce7fe 100644
--- a/include/configs/imx6_spl.h
+++ b/include/configs/imx6_spl.h
@@ -63,15 +63,15 @@

  #if defined(CONFIG_MX6SX) || defined(CONFIG_MX6UL) || defined(CONFIG_MX6SL)
  #define CONFIG_SPL_BSS_START_ADDR  0x8820
-#define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1 MB */
+#define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1 MB */
  #define CONFIG_SYS_SPL_MALLOC_START0x8830
-#define CONFIG_SYS_SPL_MALLOC_SIZE 0x320   /* 50 MB */
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10/* 1 MB */
  #define CONFIG_SYS_TEXT_BASE   0x8780
  #else
  #define CONFIG_SPL_BSS_START_ADDR  0x1820
  #define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1 MB */
  #define CONFIG_SYS_SPL_MALLOC_START0x1830
-#define CONFIG_SYS_SPL_MALLOC_SIZE 0x320   /* 50 MB */
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10/* 1 MB */
  #define CONFIG_SYS_TEXT_BASE   0x1780
  #endif
  #endif
--
2.1.4



Acked-by: Tim Harvey <thar...@gateworks.com>

thanks for dropping 2 secs off our time to boot!

Tim



The boot time for SPL and U-Boot can be reduced more if 
CONFIG_SYS_MALLOC_CLEAR_ON_INIT is unset (default is set).


Then it doesn't matter what is the size of malloc pool but it's not 
cleared - so needs check if malloc() calls should be changed to calloc().


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size


Hello Marek,

On 11/25/2015 11:56 AM, Marek Vasut wrote:

On Wednesday, November 25, 2015 at 11:40:36 AM, Przemyslaw Marczak wrote:

Hello Tim, Marek

On 11/20/2015 10:40 PM, Tim Harvey wrote:

On Fri, Nov 20, 2015 at 12:43 PM, Marek Vasut <ma...@denx.de> wrote:

Using 50 MiB malloc pool in SPL is nonsense. Since the caches are not
enabled in SPL, it takes 2 seconds to init the pool and has no obvious
benefit. Reduce the size to 1 MiB.

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Stefano Babic <sba...@denx.de>
Cc: Tim Harvey <thar...@gateworks.com>
---

   include/configs/imx6_spl.h | 6 +++---
   1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h
index 1744f2c..43ce7fe 100644
--- a/include/configs/imx6_spl.h
+++ b/include/configs/imx6_spl.h
@@ -63,15 +63,15 @@

   #if defined(CONFIG_MX6SX) || defined(CONFIG_MX6UL) ||
   defined(CONFIG_MX6SL) #define CONFIG_SPL_BSS_START_ADDR
   0x8820

-#define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1 MB */
+#define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1 MB
*/

   #define CONFIG_SYS_SPL_MALLOC_START0x8830

-#define CONFIG_SYS_SPL_MALLOC_SIZE 0x320   /* 50 MB */
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10/* 1 MB
*/

   #define CONFIG_SYS_TEXT_BASE   0x8780
   #else
   #define CONFIG_SPL_BSS_START_ADDR  0x1820
   #define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1 MB
   */ #define CONFIG_SYS_SPL_MALLOC_START0x1830

-#define CONFIG_SYS_SPL_MALLOC_SIZE 0x320   /* 50 MB */
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10/* 1 MB */

   #define CONFIG_SYS_TEXT_BASE   0x1780
   #endif
   #endif

--
2.1.4


Acked-by: Tim Harvey <thar...@gateworks.com>

thanks for dropping 2 secs off our time to boot!

Tim


The boot time for SPL and U-Boot can be reduced more if
CONFIG_SYS_MALLOC_CLEAR_ON_INIT is unset (default is set).


This might confuse DM, so I don't want this. DM checks if it's structures were
already inited and if we don't clear the malloc area, they would be.



DM is safe - it uses calloc() for it's structures and also driver's 
static structures are zeroed. Only some private data which is not 
allocated by DM can be risky to use.


To be precise - we don't use malloc() to get pointer for zeroed memory, 
this is the job for the calloc().


So any code with bad use of malloc() should be fixed ASAP.

If you assume that clear the malloc pool at boot is safe to use, then 
I'm asking you, what about the sequence malloc/free/malloc for 
potentially the same area? You can't be sure that the second returned 
pointer after calling free() - points to the initially zeroed pool.


We don't clean the malloc pool for configs that we maintain and we 
didn't noticed any issues related to this. And the boot time is reduced 
significantly.



Then it doesn't matter what is the size of malloc pool but it's not
cleared - so needs check if malloc() calls should be changed to calloc().

Best regards,


Best regards,
Marek Vasut



Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size


On 11/25/2015 01:16 PM, Marek Vasut wrote:

On Wednesday, November 25, 2015 at 01:00:41 PM, Przemyslaw Marczak wrote:

Hello Marek,

On 11/25/2015 11:56 AM, Marek Vasut wrote:

On Wednesday, November 25, 2015 at 11:40:36 AM, Przemyslaw Marczak wrote:

Hello Tim, Marek

On 11/20/2015 10:40 PM, Tim Harvey wrote:

On Fri, Nov 20, 2015 at 12:43 PM, Marek Vasut <ma...@denx.de> wrote:

Using 50 MiB malloc pool in SPL is nonsense. Since the caches are not
enabled in SPL, it takes 2 seconds to init the pool and has no obvious
benefit. Reduce the size to 1 MiB.

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Stefano Babic <sba...@denx.de>
Cc: Tim Harvey <thar...@gateworks.com>
---

include/configs/imx6_spl.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h
index 1744f2c..43ce7fe 100644
--- a/include/configs/imx6_spl.h
+++ b/include/configs/imx6_spl.h
@@ -63,15 +63,15 @@

#if defined(CONFIG_MX6SX) || defined(CONFIG_MX6UL) ||
defined(CONFIG_MX6SL) #define CONFIG_SPL_BSS_START_ADDR
0x8820

-#define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1 MB */
+#define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1
MB */

#define CONFIG_SYS_SPL_MALLOC_START0x8830

-#define CONFIG_SYS_SPL_MALLOC_SIZE 0x320   /* 50 MB */
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10/* 1
MB */

#define CONFIG_SYS_TEXT_BASE   0x8780
#else
#define CONFIG_SPL_BSS_START_ADDR  0x1820
#define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1
MB */ #define CONFIG_SYS_SPL_MALLOC_START0x1830

-#define CONFIG_SYS_SPL_MALLOC_SIZE 0x320   /* 50 MB */
+#define CONFIG_SYS_SPL_MALLOC_SIZE 0x10/* 1 MB */

#define CONFIG_SYS_TEXT_BASE   0x1780
#endif
#endif

--
2.1.4


Acked-by: Tim Harvey <thar...@gateworks.com>

thanks for dropping 2 secs off our time to boot!

Tim


The boot time for SPL and U-Boot can be reduced more if
CONFIG_SYS_MALLOC_CLEAR_ON_INIT is unset (default is set).


This might confuse DM, so I don't want this. DM checks if it's structures
were already inited and if we don't clear the malloc area, they would
be.


DM is safe - it uses calloc() for it's structures and also driver's
static structures are zeroed. Only some private data which is not
allocated by DM can be risky to use.

To be precise - we don't use malloc() to get pointer for zeroed memory,
this is the job for the calloc().

So any code with bad use of malloc() should be fixed ASAP.

If you assume that clear the malloc pool at boot is safe to use, then
I'm asking you, what about the sequence malloc/free/malloc for
potentially the same area? You can't be sure that the second returned
pointer after calling free() - points to the initially zeroed pool.

We don't clean the malloc pool for configs that we maintain and we
didn't noticed any issues related to this. And the boot time is reduced
significantly.


Do you use DM in SPL ?


No, we don't use the SPL - for the boards which we maintain.



I just checked and I see it's probably only the GD which needs to be cleared
out, so we should indeed be safe.  In which case, patch is welcome to enable
CONFIG_SYS_MALLOC_CLEAR_ON_INIT .



Yes I can see also for the Exynos SPL, that GD is manually cleared.

But disabling the default CONFIG_SYS_MALLOC_CLEAR_ON_INIT, will help you 
in reducing the U-Boot init time.
Just try and if you can easy measure the real difference for 
enable/disable this config - share the results - it can give us an 
interesting conclusions.


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 4/5] gpt: part: Definition and declaration of GPT verification functions

2015-11-24 Thread Przemyslaw Marczak


Hello Tom,

On 11/23/2015 11:44 PM, Tom Rini wrote:

On Fri, Nov 20, 2015 at 08:06:16AM +0100, Lukasz Majewski wrote:


This commit provides definition and declaration of GPT verification
functions - namely gpt_verify_headers() and gpt_verify_partitions().
The former is used to only check CRC32 of GPT's header and PTEs.
The latter examines each partition entry and compare attributes such as:
name, start offset and size with ones provided at '$partitions' env
variable.

Signed-off-by: Lukasz Majewski <l.majew...@majess.pl>
Reviewed-by: Tom Rini <tr...@konsulko.com>
Reviewed-by: Przemyslaw Marczak <p.marc...@samsung.com>


Applied to u-boot/master, thanks!



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



Why merged so quickly?

I tested this patchset on my device and posted about the issues. [1]

This should be reworked, since the verify assumptions are too simple and 
doesn't fully match the GPT header creation.
So this command will fail for some cases of write/verify sequence, 
depending on what the $partitions includes.


[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg193216.html

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] dfu: fix possible memory leak in dfu_init_env_entities()

2015-11-23 Thread Przemyslaw Marczak

The string of environment variable $dfu_alt_info is duplicated
by strdup() before parsing its content. The memory leak occurs,
when dfu fails, because the duplicated variable is freed only
on command success.

This simple fix allows calling free() always before the return.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Lukasz Majewski <l.majew...@samsung.com>
---
 drivers/dfu/dfu.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 8f5915e..420631a 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -66,13 +66,11 @@ int dfu_init_env_entities(char *interface, char *devstr)
 
env_bkp = strdup(str_env);
ret = dfu_config_entities(env_bkp, interface, devstr);
-   if (ret) {
+   if (ret)
error("DFU entities configuration failed!\n");
-   return ret;
-   }
 
free(env_bkp);
-   return 0;
+   return ret;
 }
 
 static unsigned char *dfu_buf;
-- 
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 5/5] gpt: command: Extend gpt command to support GPT table verification

2015-11-20 Thread Przemyslaw Marczak

ot;);
-   return CMD_RET_FAILURE;
-   }
+   } else if ((strcmp(argv[1], "verify") == 0)) {
+   ret = gpt_verify(blk_dev_desc, argv[4]);
+   printf("Verify GPT: ");
} else {
return CMD_RET_USAGE;
}
-   return ret;
+
+   if (ret) {
+   printf("error!\n");
+       return CMD_RET_FAILURE;
+   }
+
+   printf("success!\n");
+   return CMD_RET_SUCCESS;
  }

  U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,



Reviewed-by: Przemyslaw Marczak <p.marc...@samsung.com>

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/5] gpt: part: Definition and declaration of GPT verification functions

2015-11-20 Thread Przemyslaw Marczak

mp(efi_str, (char *)partitions[i].name,
+   sizeof(partitions->name))) {
+   error("Partition name: %s does not match %s!\n",
+ efi_str, (char *)partitions[i].name);
+   return -1;
+   }
+
+   /* Check if GPT and ENV sizes match */
+   gpt_part_size = le64_to_cpu(gpt_e[i].ending_lba) -
+   le64_to_cpu(gpt_e[i].starting_lba) + 1;
+   debug("size(LBA) - GPT: %8llu, ENV: %8llu ",
+ gpt_part_size, (u64) partitions[i].size);
+
+   if (le64_to_cpu(gpt_part_size) != partitions[i].size) {
+   error("Partition %s size: %llu does not match %llu!\n",
+ efi_str, gpt_part_size, (u64) partitions[i].size);
+   return -1;
+   }
+
+   /*
+* Start address is optional - check only if provided
+* in '$partition' variable
+*/
+   if (!partitions[i].start) {
+   debug("\n");
+   continue;
+   }
+
+   /* Check if GPT and ENV start LBAs match */
+   debug("start LBA - GPT: %8llu, ENV: %8llu\n",
+ le64_to_cpu(gpt_e[i].starting_lba),
+ (u64) partitions[i].start);
+
+   if (le64_to_cpu(gpt_e[i].starting_lba) != partitions[i].start) {
+   error("Partition %s start: %llu does not match %llu!\n",
+ efi_str, le64_to_cpu(gpt_e[i].starting_lba),
+ (u64) partitions[i].start);
+   return -1;
+   }
+   }
+
+   return 0;
+}
+
  int is_valid_gpt_buf(block_dev_desc_t *dev_desc, void *buf)
  {
gpt_header *gpt_h;
diff --git a/include/part.h b/include/part.h
index 8b5ac12..720a867 100644
--- a/include/part.h
+++ b/include/part.h
@@ -267,6 +267,41 @@ int is_valid_gpt_buf(block_dev_desc_t *dev_desc, void 
*buf);
   * @return - '0' on success, otherwise error
   */
  int write_mbr_and_gpt_partitions(block_dev_desc_t *dev_desc, void *buf);
+
+/**
+ * gpt_verify_headers() - Function to read and CRC32 check of the GPT's header
+ *and partition table entries (PTE)
+ *
+ * As a side effect if sets gpt_head and gpt_pte so they point to GPT data.
+ *
+ * @param dev_desc - block device descriptor
+ * @param gpt_head - pointer to GPT header data read from medium
+ * @param gpt_pte - pointer to GPT partition table enties read from medium
+ *
+ * @return - '0' on success, otherwise error
+ */
+int gpt_verify_headers(block_dev_desc_t *dev_desc, gpt_header *gpt_head,
+  gpt_entry **gpt_pte);
+
+/**
+ * gpt_verify_partitions() - Function to check if partitions' name, start and
+ *   size correspond to '$partitions' env variable
+ *
+ * This function checks if on medium stored GPT data is in sync with 
information
+ * provided in '$partitions' environment variable. Specificially, name, start
+ * and size of the partition is checked.
+ *
+ * @param dev_desc - block device descriptor
+ * @param partitions - partition data read from '$partitions' env variable
+ * @param parts - number of partitions read from '$partitions' env variable
+ * @param gpt_head - pointer to GPT header data read from medium
+ * @param gpt_pte - pointer to GPT partition table enties read from medium
+ *
+ * @return - '0' on success, otherwise error
+ */
+int gpt_verify_partitions(block_dev_desc_t *dev_desc,
+ disk_partition_t *partitions, int parts,
+ gpt_header *gpt_head, gpt_entry **gpt_pte);
  #endif

  #endif /* _PART_H */



Reviewed-by: Przemyslaw Marczak <p.marc...@samsung.com>

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 10/14] Exynos54xx: dts: add ADC node

2015-11-06 Thread Przemyslaw Marczak


Hello Simon,

On 11/06/2015 04:15 AM, Simon Glass wrote:

Hi Przemyslaw,

On 29 October 2015 at 07:58, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

Hi Simon,

On 10/28/2015 07:50 PM, Simon Glass wrote:


On 27 October 2015 at 06:08, Przemyslaw Marczak <p.marc...@samsung.com>
wrote:


This commit adds common ADC node, which is disabled as default.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- new commit



Reviewed-by: Simon Glass <s...@chromium.org>

This does not look like a new commit.



This is V3, and the commit was new in V2.
I didn't edit commit message if no changes made in V3.


---
   arch/arm/dts/exynos54xx.dtsi | 7 +++
   1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/exynos54xx.dtsi b/arch/arm/dts/exynos54xx.dtsi
index bd3619d..daa6a33 100644
--- a/arch/arm/dts/exynos54xx.dtsi
+++ b/arch/arm/dts/exynos54xx.dtsi
@@ -42,6 +42,13 @@
  xhci1 = "/xhci@1240";
  };

+   adc@12D1 {
+   compatible = "samsung,exynos-adc-v2";
+   reg = <0x12D1 0x100>;
+   interrupts = <0 106 0>;
+   status = "disabled";
+   };
+
  i2c@12CA {
  #address-cells = <1>;
  #size-cells = <0>;
--
1.9.1





Thank you for review.
Are you going to review the rest of patches (11-14)?


I just took a look now and made a few comments.

Regards,
Simon



Thank you for the review again, but this patchset was applied to 
u-boot-samsung four days ago and yesterday the pull request was send. 
Now I can see that, it's merged to master.


Your comments are cosmetic only, so I can send the cleanup as a 
separated patch set.


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] please pull u-boot-samsung master

Hello Minkyu,

On 11/04/2015 04:43 PM, Minkyu Kang wrote:

Dear Przemyslaw Marczak,

On 4 November 2015 at 18:37, Przemyslaw Marczak <p.marc...@samsung.com
<mailto:p.marc...@samsung.com>> wrote:

Hello Minkyu,

On 11/04/2015 03:05 AM, Minkyu Kang wrote:

    Dear Przemyslaw Marczak,

2015년 11월 4일 수요일, Tom Rini<tr...@konsulko.com
<mailto:tr...@konsulko.com>

 On Tue, Nov 03, 2015 at 02:02:57PM +0900, Minkyu Kang wrote:

  > Dear Tom,
  >
  > The following changes since commit
 0e067a65f57189703668826d9841fea477026bf6:
  >
  >   x86: Select the ns16550 debug UART for minnowmax,
 chromebook_link (2015-10-30 18:04:14 -0400)
  >
  > are available in the git repository at:
  >
  > http://git.denx.de/u-boot-samsung
  >
  > for you to fetch changes up to
 de5f9733f653091d4b227914d04432099a6448dc:
  >
  >   samsung: clean up checkpatch issues (2015-11-02
10:38:22 +0900)
  >

 NAK:

 +(sandbox) ../drivers/adc/sandbox.c:11:25: fatal error:
 sandbox-adc.h: No such file or directory
 +(sandbox)  #include 
 +(sandbox)  ^
 +(sandbox) compilation terminated.
 +(sandbox) make[3]: *** [drivers/adc/sandbox.o] Error 1
 +(sandbox) make[2]: *** [drivers/adc] Error 2
 +(sandbox) make[1]: *** [drivers] Error 2

 "sandbox: add ADC unit tests" is missing adding sandbox-adc.h

Could you please check it?

 --
 Tom

Thanks,
Minkyu Kang.

--
Thanks.
Minkyu Kang.

Sorry for this mistake. I have this file locally, so it build
properly for me.

Is that good to you if I send you a patch with this missing file, to
squash with one commit? Or do you prefer V3 of the whole patch-set?

If squash your patch  then I should do push forced.
I think it's not a good way.
I will merge your patch separately.

Thanks,
Minkyu Kang.
--
from. prom.
www.promsoft.net <http://www.promsoft.net>

Squashing would be better if we want prevent build break. This single 
file (include/sandbox-adc.h) will not conflict with any other, so it's 
easy to rebase it.
This is not a master tree, so I think that push with force will not 
cause any problems.

But if you really prefer to take it as a separate patch, then I will 
send one, with a proper commit message in a moment.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] sandbox: adc: Add missing header file

Commit: sandbox: add ADC driver

adds the driver without its main header file.
It causes build brake for sandbox_defonfig.

This commit adds a missing header:
- include/sandbox-adc.h

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
 include/sandbox-adc.h | 31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/sandbox-adc.h

diff --git a/include/sandbox-adc.h b/include/sandbox-adc.h
new file mode 100644
index 000..79ff01c
--- /dev/null
+++ b/include/sandbox-adc.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics
+ * Przemyslaw Marczak <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SANDBOX_ADC_H_
+#define _SANDBOX_ADC_H_
+
+#define SANDBOX_ADC_DEVNAME"adc@0"
+#define SANDBOX_ADC_DATA_MASK  0x /* 16-bits resolution */
+#define SANDBOX_ADC_CHANNELS   4
+#define SANDBOX_ADC_CHANNEL0_DATA  0x0
+#define SANDBOX_ADC_CHANNEL1_DATA  0x1000
+#define SANDBOX_ADC_CHANNEL2_DATA  0x2000
+#define SANDBOX_ADC_CHANNEL3_DATA  0x3000
+
+enum sandbox_adc_mode {
+   SANDBOX_ADC_MODE_SINGLE_CHANNEL = 0,
+   SANDBOX_ADC_MODE_MULTI_CHANNEL,
+};
+
+enum sandbox_adc_status {
+   SANDBOX_ADC_INACTIVE = 0,
+   SANDBOX_ADC_ACTIVE,
+};
+
+#define SANDBOX_ADC_VSS_VALUE  0
+
+#endif
-- 
1.9.1

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

Re: [U-Boot] please pull u-boot-samsung master


Hello Minkyu,

On 11/04/2015 03:05 AM, Minkyu Kang wrote:

Dear Przemyslaw Marczak,

2015년 11월 4일 수요일, Tom Rini<tr...@konsulko.com

On Tue, Nov 03, 2015 at 02:02:57PM +0900, Minkyu Kang wrote:

 > Dear Tom,
 >
 > The following changes since commit
0e067a65f57189703668826d9841fea477026bf6:
 >
 >   x86: Select the ns16550 debug UART for minnowmax,
chromebook_link (2015-10-30 18:04:14 -0400)
 >
 > are available in the git repository at:
 >
 > http://git.denx.de/u-boot-samsung
 >
 > for you to fetch changes up to
de5f9733f653091d4b227914d04432099a6448dc:
 >
 >   samsung: clean up checkpatch issues (2015-11-02 10:38:22 +0900)
 >

NAK:

+(sandbox) ../drivers/adc/sandbox.c:11:25: fatal error:
sandbox-adc.h: No such file or directory
+(sandbox)  #include 
+(sandbox)  ^
+(sandbox) compilation terminated.
+(sandbox) make[3]: *** [drivers/adc/sandbox.o] Error 1
+(sandbox) make[2]: *** [drivers/adc] Error 2
+(sandbox) make[1]: *** [drivers] Error 2

"sandbox: add ADC unit tests" is missing adding sandbox-adc.h


Could you please check it?

--
Tom


Thanks,
Minkyu Kang.


--
Thanks.
Minkyu Kang.


Sorry for this mistake. I have this file locally, so it build properly 
for me.


Is that good to you if I send you a patch with this missing file, to 
squash with one commit? Or do you prefer V3 of the whole patch-set?


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Add missing file: include/sandbox-adc.h

This should be squashed to commit:

sandbox: add ADC driver

This commit adds implementation of Sandbox ADC device emulation.
The device provides:
- single and multi-channel conversion
- 4 channels with predefined conversion output data
- 16-bit resolution

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V3:
- new commit
---
 include/sandbox-adc.h | 31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/sandbox-adc.h

diff --git a/include/sandbox-adc.h b/include/sandbox-adc.h
new file mode 100644
index 000..79ff01c
--- /dev/null
+++ b/include/sandbox-adc.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics
+ * Przemyslaw Marczak <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SANDBOX_ADC_H_
+#define _SANDBOX_ADC_H_
+
+#define SANDBOX_ADC_DEVNAME"adc@0"
+#define SANDBOX_ADC_DATA_MASK  0x /* 16-bits resolution */
+#define SANDBOX_ADC_CHANNELS   4
+#define SANDBOX_ADC_CHANNEL0_DATA  0x0
+#define SANDBOX_ADC_CHANNEL1_DATA  0x1000
+#define SANDBOX_ADC_CHANNEL2_DATA  0x2000
+#define SANDBOX_ADC_CHANNEL3_DATA  0x3000
+
+enum sandbox_adc_mode {
+   SANDBOX_ADC_MODE_SINGLE_CHANNEL = 0,
+   SANDBOX_ADC_MODE_MULTI_CHANNEL,
+};
+
+enum sandbox_adc_status {
+   SANDBOX_ADC_INACTIVE = 0,
+   SANDBOX_ADC_ACTIVE,
+};
+
+#define SANDBOX_ADC_VSS_VALUE  0
+
+#endif
-- 
1.9.1

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

Re: [U-Boot] [PATCH] fdt: fix address cell count checking in fdt_translate_address()

2015-11-03 Thread Przemyslaw Marczak


Hello All,

On 10/29/2015 06:15 PM, Simon Glass wrote:

Hi Stefan,

On 28 October 2015 at 08:37, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

Commit: dm: core: Enable optional use of fdt_translate_address()

Enables use of this function as default, but after this it's not
possible to get dev address for the case in which: '#size-cells == 0'

This causes errors when getting address for some GPIOs, for which
the '#size-cells' is set to 0.

Example error:
'__of_translate_address: Bad cell count for gpx0'

Allowing for that case by modifying the macro 'OF_CHECK_COUNTS',
(called from )__of_translate_address(), fixes the issue.

Now, this macro doesn't check, that '#size-cells' is greater than 0.

This is possible from the specification point of view, but I'm not sure
that it doesn't introduce a regression for other configs.

Please test and share the results.

Tested-on: Odroid U3, Odroid X2, Odroid XU3, Sandbox.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Masahiro Yamada <yamada.masah...@socionext.com>
Cc: Lukasz Majewski <l.majew...@samsung.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Stefan Roese <s...@denx.de>
Cc: Simon Glass <s...@chromium.org>
Cc: Bin Meng <bmeng...@gmail.com>
Cc: Marek Vasut <ma...@denx.de>
---
  common/fdt_support.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index f86365e..5f808cc 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -946,8 +946,7 @@ void fdt_del_node_and_alias(void *blob, const char *alias)
  /* Max address size we deal with */
  #define OF_MAX_ADDR_CELLS  4
  #define OF_BAD_ADDR((u64)-1)
-#define OF_CHECK_COUNTS(na, ns)((na) > 0 && (na) <= OF_MAX_ADDR_CELLS 
&& \
-   (ns) > 0)
+#define OF_CHECK_COUNTS(na)((na) > 0 && (na) <= OF_MAX_ADDR_CELLS)

  /* Debug utility */
  #ifdef DEBUG
@@ -1115,7 +1114,7 @@ static u64 __of_translate_address(void *blob, int 
node_offset, const fdt32_t *in

 /* Cound address cells & copy address locally */
 bus->count_cells(blob, parent, , );
-   if (!OF_CHECK_COUNTS(na, ns)) {
+   if (!OF_CHECK_COUNTS(na)) {


This seems to conflict with the comment at the top of this function:

  * Note: We consider that crossing any level with #size-cells == 0 to mean
  * that translation is impossible (that is we are not dealing with a value
  * that can be mapped to a cpu physical address). This is not really specified
  * that way, but this is traditionally the way IBM at least do things

What should we do here?



Is that commit acceptable? I would like send V2 with removing the above 
comment.


Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com


 printf("%s: Bad cell count for %s\n", __FUNCTION__,
fdt_get_name(blob, node_offset, NULL));
 goto bail;
@@ -1142,7 +1141,7 @@ static u64 __of_translate_address(void *blob, int 
node_offset, const fdt32_t *in
 /* Get new parent bus and counts */
 pbus = _busses[0];
 pbus->count_cells(blob, parent, , );
-   if (!OF_CHECK_COUNTS(pna, pns)) {
+   if (!OF_CHECK_COUNTS(pna)) {
 printf("%s: Bad cell count for %s\n", __FUNCTION__,
 fdt_get_name(blob, node_offset, NULL));
 break;
--
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 V3 10/14] Exynos54xx: dts: add ADC node

2015-10-29 Thread Przemyslaw Marczak


Hi Simon,

On 10/28/2015 07:50 PM, Simon Glass wrote:

On 27 October 2015 at 06:08, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

This commit adds common ADC node, which is disabled as default.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- new commit


Reviewed-by: Simon Glass <s...@chromium.org>

This does not look like a new commit.



This is V3, and the commit was new in V2.
I didn't edit commit message if no changes made in V3.


---
  arch/arm/dts/exynos54xx.dtsi | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/exynos54xx.dtsi b/arch/arm/dts/exynos54xx.dtsi
index bd3619d..daa6a33 100644
--- a/arch/arm/dts/exynos54xx.dtsi
+++ b/arch/arm/dts/exynos54xx.dtsi
@@ -42,6 +42,13 @@
 xhci1 = "/xhci@1240";
 };

+   adc@12D1 {
+   compatible = "samsung,exynos-adc-v2";
+   reg = <0x12D1 0x100>;
+   interrupts = <0 106 0>;
+   status = "disabled";
+   };
+
 i2c@12CA {
 #address-cells = <1>;
 #size-cells = <0>;
--
1.9.1





Thank you for review.
Are you going to review the rest of patches (11-14)?

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 4/4] exynos: more debug and cleanup in do_sdhci_init()


Hello Jaehoon,

On 10/28/2015 07:33 AM, Jaehoon Chung wrote:

Hi, All.

On 10/05/2015 08:47 PM, Tobias Jakobi wrote:

Add more debug printfs in do_sdhci_init() for calls
that can potentially fail.

Acked-by: Przemyslaw Marczak <p.marc...@samsung.com>
Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
  drivers/mmc/s5p_sdhci.c | 20 +++-
  1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
index b203bee..15ecfee 100644
--- a/drivers/mmc/s5p_sdhci.c
+++ b/drivers/mmc/s5p_sdhci.c
@@ -101,29 +101,31 @@ struct sdhci_host sdhci_host[SDHCI_MAX_HOSTS];

  static int do_sdhci_init(struct sdhci_host *host)
  {
-   int dev_id, flag;
-   int err = 0;
+   int dev_id, flag, ret;

flag = host->bus_width == 8 ? PINMUX_FLAG_8BIT_MODE : PINMUX_FLAG_NONE;
dev_id = host->index + PERIPH_ID_SDMMC0;

if (dm_gpio_is_valid(>pwr_gpio)) {
dm_gpio_set_value(>pwr_gpio, 1);
-   err = exynos_pinmux_config(dev_id, flag);
-   if (err) {
+   ret = exynos_pinmux_config(dev_id, flag);
+   if (ret) {
debug("MMC not configured\n");
-   return err;
+   return ret;
}
}

if (dm_gpio_is_valid(>cd_gpio)) {
-   if (dm_gpio_get_value(>cd_gpio))
+   ret = dm_gpio_get_value(>cd_gpio);
+   if (ret) {
+   debug("no SD card detected (%d)\n", ret);
return -ENODEV;
+   }


This patch was already applied. But i didn't know why used "ret" at here.
If cd-gpio is active-high, this should be always returned "no SD card detected".
Even if commonly cd-gpio is active-low, we don't know whether cd-gpio is 
active-low or not.

And dm_gpio_get_value() should be returned error for only one case.

Best Regards,
Jaehoon Chung



Could you precise, where is the problem exactly? The active low or high 
can be set in device tree, so the code can be still common.


And the ret value can inform, if card is not detected or the error is in 
GPIO subsystem(ret < 0). So where is the problem?




-   err = exynos_pinmux_config(dev_id, flag);
-   if (err) {
+   ret = exynos_pinmux_config(dev_id, flag);
+   if (ret) {
printf("external SD not configured\n");
-   return err;
+       return ret;
}
}






Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 4/4] exynos: more debug and cleanup in do_sdhci_init()


Hello Jaehoon,

On 10/28/2015 01:30 PM, Jaehoon Chung wrote:

Hi, Przemyslaw.

On 10/28/2015 08:33 PM, Przemyslaw Marczak wrote:

Hello Jaehoon,

On 10/28/2015 07:33 AM, Jaehoon Chung wrote:

Hi, All.

On 10/05/2015 08:47 PM, Tobias Jakobi wrote:

Add more debug printfs in do_sdhci_init() for calls
that can potentially fail.

Acked-by: Przemyslaw Marczak <p.marc...@samsung.com>
Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
   drivers/mmc/s5p_sdhci.c | 20 +++-
   1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
index b203bee..15ecfee 100644
--- a/drivers/mmc/s5p_sdhci.c
+++ b/drivers/mmc/s5p_sdhci.c
@@ -101,29 +101,31 @@ struct sdhci_host sdhci_host[SDHCI_MAX_HOSTS];

   static int do_sdhci_init(struct sdhci_host *host)
   {
-int dev_id, flag;
-int err = 0;
+int dev_id, flag, ret;

   flag = host->bus_width == 8 ? PINMUX_FLAG_8BIT_MODE : PINMUX_FLAG_NONE;
   dev_id = host->index + PERIPH_ID_SDMMC0;

   if (dm_gpio_is_valid(>pwr_gpio)) {
   dm_gpio_set_value(>pwr_gpio, 1);
-err = exynos_pinmux_config(dev_id, flag);
-if (err) {
+ret = exynos_pinmux_config(dev_id, flag);
+if (ret) {
   debug("MMC not configured\n");
-return err;
+return ret;
   }
   }

   if (dm_gpio_is_valid(>cd_gpio)) {
-if (dm_gpio_get_value(>cd_gpio))
+ret = dm_gpio_get_value(>cd_gpio);
+if (ret) {
+debug("no SD card detected (%d)\n", ret);
   return -ENODEV;
+}


This patch was already applied. But i didn't know why used "ret" at here.
If cd-gpio is active-high, this should be always returned "no SD card detected".
Even if commonly cd-gpio is active-low, we don't know whether cd-gpio is 
active-low or not.

And dm_gpio_get_value() should be returned error for only one case.

Best Regards,
Jaehoon Chung



Could you precise, where is the problem exactly? The active low or high can be 
set in device tree, so the code can be still common.


How can active low or high be set in device tree? I can't find any information.



It is defined here:
arch/arm/dts/include/dt-bindings/gpio/gpio.h
and is used by gpio's phandle, e.g.:
sdhci@1253 {
samsung,bus-width = <4>;
samsung,timing = <1 2 3>;
cd-gpios = < 2 0>;
}


Anyway, I have tested on Odroid-x2 board. And i have tried to boot with SD-card.
In that case, host can't detect SD-card.


Can you also see this error:
---
DRAM:  2 GiB
__of_translate_address: Bad cell count for gpf0
__of_translate_address: Bad cell count for gpj0
__of_translate_address: Bad cell count for gpk0
__of_translate_address: Bad cell count for gpm0
__of_translate_address: Bad cell count for gpx0
LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
LDO21@TFLASH_2.8V: set 280 uV; enabling
MMC:   process_nodes: failed to initialize dev 0 (-19)
---

This is caused by this commit:
commit ef5cd33064f83db6f6cfe774ecdb36e32ac1d232
dm: core: Enable optional use of fdt_translate_address()

And it's not related to GPIO configuration.

Right now, I'm looking on how to fix it.



MMC:   process_nodes: failed to initialize dev 0 (-19)

After Enable debug message..

no SD card detected (1)
process_nodes: failed to initialize dev 0 (-19)

no SD card detected (1) -> 1 is just gpio value. it should be to 0.
Do you distinguish between 0 and 1? We don't know whether gpio is active-low or 
high.
I don't think that included information.

It's just my thinking...other people should be helpful.

And I'm making some patches...and below is one of them for detecting SD-card.

Subject: [PATCH] mmc: s5p_sdhci: change the flags of cd-gpio to ACTIVE_LOW

In case of exynos, "cd-gpio" is commonly used the active-low.
So it changed the flags of gpio from GPIOD_IS_IN to GPIOD_ACTIVE_LOW.

Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>
---
  drivers/mmc/s5p_sdhci.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
index 15ecfee..26a8fe8 100644
--- a/drivers/mmc/s5p_sdhci.c
+++ b/drivers/mmc/s5p_sdhci.c
@@ -164,7 +164,7 @@ static int sdhci_get_config(const void *blob, int node, 
struct sdhci_host *host)
 gpio_request_by_name_nodev(blob, node, "pwr-gpios", 0, >pwr_gpio,
GPIOD_IS_OUT);
 gpio_request_by_name_nodev(blob, node, "cd-gpios", 0, >cd_gpio,
-  GPIOD_IS_IN);
+  GPIOD_ACTIVE_LOW);


This change, is a bad idea.

We uses this flag to set the direction (input/output), and also the f

[U-Boot] [PATCH 2/2] s5p sdhci: call pinmux for card's gpio pins before use them

The SD card detection depends on checking one pin state.
But the pin was configured after card was detected, which is wrong.

This commit fixes this, by moving call to pinmux before use the pin.

Tested-on: Odroid U3 and Odroid X2.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Lukasz Majewski <l.majew...@samsung.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
 drivers/mmc/s5p_sdhci.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
index 15ecfee..44353c7 100644
--- a/drivers/mmc/s5p_sdhci.c
+++ b/drivers/mmc/s5p_sdhci.c
@@ -106,6 +106,12 @@ static int do_sdhci_init(struct sdhci_host *host)
flag = host->bus_width == 8 ? PINMUX_FLAG_8BIT_MODE : PINMUX_FLAG_NONE;
dev_id = host->index + PERIPH_ID_SDMMC0;
 
+   ret = exynos_pinmux_config(dev_id, flag);
+   if (ret) {
+   printf("external SD not configured\n");
+   return ret;
+   }
+
if (dm_gpio_is_valid(>pwr_gpio)) {
dm_gpio_set_value(>pwr_gpio, 1);
ret = exynos_pinmux_config(dev_id, flag);
@@ -121,12 +127,6 @@ static int do_sdhci_init(struct sdhci_host *host)
debug("no SD card detected (%d)\n", ret);
return -ENODEV;
}
-
-   ret = exynos_pinmux_config(dev_id, flag);
-   if (ret) {
-   printf("external SD not configured\n");
-   return ret;
-   }
}
 
return s5p_sdhci_core_init(host);
@@ -193,7 +193,7 @@ static int process_nodes(const void *blob, int node_list[], 
int count)
}
 
ret = do_sdhci_init(host);
-   if (ret) {
+   if (ret && ret != -ENODEV) {
printf("%s: failed to initialize dev %d (%d)\n", 
__func__, i, ret);
failed++;
}
-- 
1.9.1

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

[U-Boot] [PATCH 1/2] Exynos4412: pinmux: disable pull for MMC pins

There are 8 pins for SD card in Exynos, but the MUX was configured
only for 7, since the one was used for card detection.
This caused the pin's pull wrong configuration.

This commit fixes this and the card detect can work properly,
after call this function.

Tested-on: Odroid U3 and Odroid X2.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Lukasz Majewski <l.majew...@samsung.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
 arch/arm/mach-exynos/pinmux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/pinmux.c b/arch/arm/mach-exynos/pinmux.c
index 179b294..925bd0a 100644
--- a/arch/arm/mach-exynos/pinmux.c
+++ b/arch/arm/mach-exynos/pinmux.c
@@ -737,10 +737,10 @@ static int exynos4x12_mmc_config(int peripheral, int 
flags)
return -1;
}
for (i = start; i < (start + 7); i++) {
+   gpio_set_pull(i, S5P_GPIO_PULL_NONE);
if (i == (start + 2))
continue;
gpio_cfg_pin(i,  func);
-   gpio_set_pull(i, S5P_GPIO_PULL_NONE);
gpio_set_drv(i, S5P_GPIO_DRV_4X);
}
if (flags & PINMUX_FLAG_8BIT_MODE) {
-- 
1.9.1

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

[U-Boot] [PATCH] fdt: fix address cell count checking in fdt_translate_address()

Commit: dm: core: Enable optional use of fdt_translate_address()

Enables use of this function as default, but after this it's not
possible to get dev address for the case in which: '#size-cells == 0'

This causes errors when getting address for some GPIOs, for which
the '#size-cells' is set to 0.

Example error:
'__of_translate_address: Bad cell count for gpx0'

Allowing for that case by modifying the macro 'OF_CHECK_COUNTS',
(called from )__of_translate_address(), fixes the issue.

Now, this macro doesn't check, that '#size-cells' is greater than 0.

This is possible from the specification point of view, but I'm not sure
that it doesn't introduce a regression for other configs.

Please test and share the results.

Tested-on: Odroid U3, Odroid X2, Odroid XU3, Sandbox.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Masahiro Yamada <yamada.masah...@socionext.com>
Cc: Lukasz Majewski <l.majew...@samsung.com>
Cc: Jaehoon Chung <jh80.ch...@samsung.com>
Cc: Stefan Roese <s...@denx.de>
Cc: Simon Glass <s...@chromium.org>
Cc: Bin Meng <bmeng...@gmail.com>
Cc: Marek Vasut <ma...@denx.de>
---
 common/fdt_support.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index f86365e..5f808cc 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -946,8 +946,7 @@ void fdt_del_node_and_alias(void *blob, const char *alias)
 /* Max address size we deal with */
 #define OF_MAX_ADDR_CELLS  4
 #define OF_BAD_ADDR((u64)-1)
-#define OF_CHECK_COUNTS(na, ns)((na) > 0 && (na) <= OF_MAX_ADDR_CELLS 
&& \
-   (ns) > 0)
+#define OF_CHECK_COUNTS(na)((na) > 0 && (na) <= OF_MAX_ADDR_CELLS)
 
 /* Debug utility */
 #ifdef DEBUG
@@ -1115,7 +1114,7 @@ static u64 __of_translate_address(void *blob, int 
node_offset, const fdt32_t *in
 
/* Cound address cells & copy address locally */
bus->count_cells(blob, parent, , );
-   if (!OF_CHECK_COUNTS(na, ns)) {
+   if (!OF_CHECK_COUNTS(na)) {
printf("%s: Bad cell count for %s\n", __FUNCTION__,
   fdt_get_name(blob, node_offset, NULL));
goto bail;
@@ -1142,7 +1141,7 @@ static u64 __of_translate_address(void *blob, int 
node_offset, const fdt32_t *in
/* Get new parent bus and counts */
pbus = _busses[0];
pbus->count_cells(blob, parent, , );
-   if (!OF_CHECK_COUNTS(pna, pns)) {
+   if (!OF_CHECK_COUNTS(pna)) {
printf("%s: Bad cell count for %s\n", __FUNCTION__,
fdt_get_name(blob, node_offset, NULL));
break;
-- 
1.9.1

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

Re: [U-Boot] [PATCH v3 4/4] exynos: more debug and cleanup in do_sdhci_init()


Hello Jaehoon,

On 10/28/2015 03:36 PM, Jaehoon Chung wrote:

Hi, Przemyslaw.

On 10/28/2015 10:46 PM, Przemyslaw Marczak wrote:

Hello Jaehoon,

On 10/28/2015 01:30 PM, Jaehoon Chung wrote:

Hi, Przemyslaw.

On 10/28/2015 08:33 PM, Przemyslaw Marczak wrote:

Hello Jaehoon,

On 10/28/2015 07:33 AM, Jaehoon Chung wrote:

Hi, All.

On 10/05/2015 08:47 PM, Tobias Jakobi wrote:

Add more debug printfs in do_sdhci_init() for calls
that can potentially fail.

Acked-by: Przemyslaw Marczak <p.marc...@samsung.com>
Signed-off-by: Tobias Jakobi <tjak...@math.uni-bielefeld.de>
---
drivers/mmc/s5p_sdhci.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
index b203bee..15ecfee 100644
--- a/drivers/mmc/s5p_sdhci.c
+++ b/drivers/mmc/s5p_sdhci.c
@@ -101,29 +101,31 @@ struct sdhci_host sdhci_host[SDHCI_MAX_HOSTS];

static int do_sdhci_init(struct sdhci_host *host)
{
-int dev_id, flag;
-int err = 0;
+int dev_id, flag, ret;

flag = host->bus_width == 8 ? PINMUX_FLAG_8BIT_MODE : PINMUX_FLAG_NONE;
dev_id = host->index + PERIPH_ID_SDMMC0;

if (dm_gpio_is_valid(>pwr_gpio)) {
dm_gpio_set_value(>pwr_gpio, 1);
-err = exynos_pinmux_config(dev_id, flag);
-if (err) {
+ret = exynos_pinmux_config(dev_id, flag);
+if (ret) {
debug("MMC not configured\n");
-return err;
+return ret;
}
}

if (dm_gpio_is_valid(>cd_gpio)) {
-if (dm_gpio_get_value(>cd_gpio))
+ret = dm_gpio_get_value(>cd_gpio);
+if (ret) {
+debug("no SD card detected (%d)\n", ret);
return -ENODEV;
+}


This patch was already applied. But i didn't know why used "ret" at here.
If cd-gpio is active-high, this should be always returned "no SD card detected".
Even if commonly cd-gpio is active-low, we don't know whether cd-gpio is 
active-low or not.

And dm_gpio_get_value() should be returned error for only one case.

Best Regards,
Jaehoon Chung



Could you precise, where is the problem exactly? The active low or high can be 
set in device tree, so the code can be still common.


How can active low or high be set in device tree? I can't find any information.



It is defined here:
arch/arm/dts/include/dt-bindings/gpio/gpio.h
and is used by gpio's phandle, e.g.:
sdhci@1253 {
 samsung,bus-width = <4>;
 samsung,timing = <1 2 3>;
 cd-gpios = < 2 0>;
}


Yes, I have checked.




Anyway, I have tested on Odroid-x2 board. And i have tried to boot with SD-card.
In that case, host can't detect SD-card.


Can you also see this error:
---
DRAM:  2 GiB
__of_translate_address: Bad cell count for gpf0
__of_translate_address: Bad cell count for gpj0
__of_translate_address: Bad cell count for gpk0
__of_translate_address: Bad cell count for gpm0
__of_translate_address: Bad cell count for gpx0
LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
LDO21@TFLASH_2.8V: set 280 uV; enabling
MMC:   process_nodes: failed to initialize dev 0 (-19)
---

This is caused by this commit:
commit ef5cd33064f83db6f6cfe774ecdb36e32ac1d232
dm: core: Enable optional use of fdt_translate_address()

And it's not related to GPIO configuration.

Right now, I'm looking on how to fix it.


Yes, i also found those message. I'm also finding solution.


Please check the patches for which you're Cc'ed :)

1 fdt fix:
https://patchwork.ozlabs.org/patch/537372/

2 patches for sd detection fix:
https://patchwork.ozlabs.org/patch/537381/
https://patchwork.ozlabs.org/patch/537379/

Tested for X2 and U3.





MMC:   process_nodes: failed to initialize dev 0 (-19)

After Enable debug message..

no SD card detected (1)
process_nodes: failed to initialize dev 0 (-19)

no SD card detected (1) -> 1 is just gpio value. it should be to 0.
Do you distinguish between 0 and 1? We don't know whether gpio is active-low or 
high.
I don't think that included information.

It's just my thinking...other people should be helpful.

And I'm making some patches...and below is one of them for detecting SD-card.

Subject: [PATCH] mmc: s5p_sdhci: change the flags of cd-gpio to ACTIVE_LOW

In case of exynos, "cd-gpio" is commonly used the active-low.
So it changed the flags of gpio from GPIOD_IS_IN to GPIOD_ACTIVE_LOW.

Signed-off-by: Jaehoon Chung <jh80.ch...@samsung.com>
---
   drivers/mmc/s5p_sdhci.c | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
index 15ecfee..26a8fe8 100644
--- a/drivers/mmc/s5p_sdhci.c
+++ b/drivers/mmc/s5p_sdhci.c
@@ -164,7 +164,7 @@ static int sdhci_get_config(const v

[U-Boot] [PATCH V3 05/14] dm: pmic: add s2mps11 PMIC I/O driver

This driver allows I/O operations on the Samsung S2MPS11 PMIC,
which provides lots of LDO/BUCK outputs.

To enable it, update defconfig with:
- CONFIG_PMIC_S2MPS11
and additional, if were not defined:
- CONFIG_CMD_PMIC
- CONFIG_ERRNO_STR

The binding info: doc/device-tree-bindings/pmic/s2mps11.txt

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
---
Changes V2:
- remove "DM" prefix from config name
- fix word mistake in binding description
Changes V3:
- correct return values for driver's read/write methods
---
 doc/device-tree-bindings/pmic/s2mps11.txt |  17 +
 drivers/power/pmic/Kconfig|  14 
 drivers/power/pmic/Makefile   |   1 +
 drivers/power/pmic/s2mps11.c  |  62 +
 include/power/s2mps11.h   | 109 ++
 5 files changed, 203 insertions(+)
 create mode 100644 doc/device-tree-bindings/pmic/s2mps11.txt
 create mode 100644 drivers/power/pmic/s2mps11.c
 create mode 100644 include/power/s2mps11.h

diff --git a/doc/device-tree-bindings/pmic/s2mps11.txt 
b/doc/device-tree-bindings/pmic/s2mps11.txt
new file mode 100644
index 000..422f14f
--- /dev/null
+++ b/doc/device-tree-bindings/pmic/s2mps11.txt
@@ -0,0 +1,17 @@
+SAMSUNG, S2MPS11 PMIC
+
+This file describes the binding info for the PMIC driver:
+- drivers/power/pmic/s2mps11.c
+
+Required properties:
+- compatible: "samsung,s2mps11-pmic"
+- reg = 0x66
+
+With those two properties, the pmic device can be used for read/write only.
+
+Example:
+
+s2mps11@66 {
+   compatible = "samsung,s2mps11-pmic";
+   reg = <0x66>;
+};
diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 547fd1a..fb29843 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -33,6 +33,20 @@ config DM_PMIC_MAX77686
This config enables implementation of driver-model pmic uclass features
for PMIC MAX77686. The driver implements read/write operations.
 
+config PMIC_S2MPS11
+   bool "Enable Driver Model for PMIC Samsung S2MPS11"
+   depends on DM_PMIC
+   ---help---
+   The Samsung S2MPS11 PMIC provides:
+- 38 adjustable LDO regulators
+- 9 High-Efficiency Buck Converters
+- 1 BuckBoost Converter
+- RTC with two alarms
+- Backup battery charger
+- I2C Configuration Interface
+   This driver provides access to I/O interface only.
+   Binding info: doc/device-tree-bindings/pmic/s2mps11.txt
+
 config DM_PMIC_SANDBOX
bool "Enable Driver Model for emulated Sandbox PMIC "
depends on DM_PMIC
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 00fde71..91e78f8 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -8,6 +8,7 @@
 obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
 obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
 obj-$(CONFIG_DM_PMIC_PFUZE100) += pfuze100.o
+obj-$(CONFIG_PMIC_S2MPS11) += s2mps11.o
 obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
 obj-$(CONFIG_PMIC_ACT8846) += act8846.o
 obj-$(CONFIG_PMIC_TPS65090) += tps65090.o
diff --git a/drivers/power/pmic/s2mps11.c b/drivers/power/pmic/s2mps11.c
new file mode 100644
index 000..9d83059
--- /dev/null
+++ b/drivers/power/pmic/s2mps11.c
@@ -0,0 +1,62 @@
+/*
+ *  Copyright (C) 2015 Samsung Electronics
+ *  Przemyslaw Marczak  <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int s2mps11_reg_count(struct udevice *dev)
+{
+   return S2MPS11_REG_COUNT;
+}
+
+static int s2mps11_write(struct udevice *dev, uint reg, const uint8_t *buff,
+int len)
+{
+   int ret;
+
+   ret = dm_i2c_write(dev, reg, buff, len);
+   if (ret)
+   error("write error to device: %p register: %#x!", dev, reg);
+
+   return ret;
+}
+
+static int s2mps11_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+   int ret;
+
+   ret = dm_i2c_read(dev, reg, buff, len);
+   if (ret)
+   error("read error from device: %p register: %#x!", dev, reg);
+
+   return ret;
+}
+
+static struct dm_pmic_ops s2mps11_ops = {
+   .reg_count = s2mps11_reg_count,
+   .read = s2mps11_read,
+   .write = s2mps11_write,
+};
+
+static const struct udevice_id s2mps11_ids[] = {
+   { .compatible = "samsung,s2mps11-pmic" },
+   { }
+};
+
+U_BOOT_DRIVER(pmic_s2mps11) = {
+   .name = "s2mps11_pmic",
+   .id = UCLASS_PMIC,
+   .of_match = s2mps11_ids,
+   .ops = _ops,
+};
diff --git a/include/power/s2mps11.h b/include/power/s2mps11.h
new file mode 100644
index 000..5da4719
--- /dev/null
+++ b/include/power/s2mps11.h
@@ -0,0 +1,109 @@
+#ifndef __S2MPS11__H__
+#define __S2MPS11__H__
+
+enum s2mps11_re

[U-Boot] [PATCH V3 08/14] dm: adc: add Exynos54xx compatible ADC driver

This commit adds driver for Exynos54xx ADC subsystem.

The driver is implemented using driver model, amd provides
ADC uclass's methods for ADC single channel operations:
- adc_start_channel()
- adc_channel_data()
- adc_stop()

The basic parameters of ADC conversion, are:
- sample rate: 600KSPS
- output the data as average of 8 time conversion

ADC features:
- sample rate: 600KSPS
- resolution: 12-bit
- channels: 10 (analog multiplexer)

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- new commit - move previous adc driver from SoC directory to drivers/adc
Changes V3:
- rework the driver to fit new API
- remove call to sdelay() from driver's code
- add active_channel to keep consistency between ADC request and result
---
 arch/arm/mach-exynos/include/mach/adc.h |  44 ++
 drivers/adc/Kconfig |   9 ++
 drivers/adc/Makefile|   1 +
 drivers/adc/exynos-adc.c| 145 
 4 files changed, 199 insertions(+)
 create mode 100644 drivers/adc/exynos-adc.c

diff --git a/arch/arm/mach-exynos/include/mach/adc.h 
b/arch/arm/mach-exynos/include/mach/adc.h
index a0e26d7..9af51ab 100644
--- a/arch/arm/mach-exynos/include/mach/adc.h
+++ b/arch/arm/mach-exynos/include/mach/adc.h
@@ -9,6 +9,39 @@
 #ifndef __ASM_ARM_ARCH_ADC_H_
 #define __ASM_ARM_ARCH_ADC_H_
 
+#define ADC_V2_CON1_SOFT_RESET (0x2 << 1)
+#define ADC_V2_CON1_STC_EN 0x1
+
+#define ADC_V2_CON2_OSEL(x)(((x) & 0x1) << 10)
+#define OSEL_2S0x0
+#define OSEL_BINARY0x1
+#define ADC_V2_CON2_ESEL(x)(((x) & 0x1) << 9)
+#define ESEL_ADC_EVAL_TIME_40CLK   0x0
+#define ESEL_ADC_EVAL_TIME_20CLK   0x1
+#define ADC_V2_CON2_HIGHF(x)   (((x) & 0x1) << 8)
+#define HIGHF_CONV_RATE_30KSPS 0x0
+#define HIGHF_CONV_RATE_600KSPS0x1
+#define ADC_V2_CON2_C_TIME(x)  (((x) & 0x7) << 4)
+#define ADC_V2_CON2_CHAN_SEL_MASK  0xf
+#define ADC_V2_CON2_CHAN_SEL(x)((x) & 
ADC_V2_CON2_CHAN_SEL_MASK)
+
+#define ADC_V2_GET_STATUS_FLAG(x)  (((x) >> 2) & 0x1)
+#define FLAG_CONV_END  0x1
+
+#define ADC_V2_INT_DISABLE 0x0
+#define ADC_V2_INT_ENABLE  0x1
+#define INT_NOT_GENERATED  0x0
+#define INT_GENERATED  0x1
+
+#define ADC_V2_VERSION 0x8008
+
+#define ADC_V2_MAX_CHANNEL 9
+
+/* For default 8 time convertion with sample rate 600 kSPS - 15us timeout */
+#define ADC_V2_CONV_TIMEOUT_US 15
+
+#define ADC_V2_DAT_MASK0xfff
+
 #ifndef __ASSEMBLY__
 struct s5p_adc {
unsigned int adccon;
@@ -21,6 +54,17 @@ struct s5p_adc {
unsigned int adcmux;
unsigned int adcclrintpndnup;
 };
+
+struct exynos_adc_v2 {
+   unsigned int con1;
+   unsigned int con2;
+   unsigned int status;
+   unsigned int dat;
+   unsigned int int_en;
+   unsigned int int_status;
+   unsigned int reserved[2];
+   unsigned int version;
+};
 #endif
 
 #endif /* __ASM_ARM_ARCH_ADC_H_ */
diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
index b6e226a..223b65e 100644
--- a/drivers/adc/Kconfig
+++ b/drivers/adc/Kconfig
@@ -10,3 +10,12 @@ config ADC
  - methods for get Vdd/Vss reference Voltage values with polarity
  - support supply's phandle with auto-enable
  - supply polarity setting in fdt
+
+config ADC_EXYNOS
+   bool "Enable Exynos 54xx ADC driver"
+   help
+ This enables basic driver for Exynos ADC compatible with Exynos54xx.
+ It provides:
+ - 10 analog input channels
+ - 12-bit resolution
+ - 600 KSPS of sample rate
diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
index c4d9618..eb85b8b 100644
--- a/drivers/adc/Makefile
+++ b/drivers/adc/Makefile
@@ -6,3 +6,4 @@
 #
 
 obj-$(CONFIG_ADC) += adc-uclass.o
+obj-$(CONFIG_ADC_EXYNOS) += exynos-adc.o
diff --git a/drivers/adc/exynos-adc.c b/drivers/adc/exynos-adc.c
new file mode 100644
index 000..534e68d
--- /dev/null
+++ b/drivers/adc/exynos-adc.c
@@ -0,0 +1,145 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics
+ * Przemyslaw Marczak <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct exynos_adc_priv {
+   int active_channel;
+   struct exynos_adc_v2 *regs;
+};
+
+int exynos_adc_channel_data(struct udevice *dev, int channel,
+   unsigned int *data)
+{
+   struct exynos_adc_priv *priv = dev_get_priv(dev);
+   struct exynos_adc_v2 *regs = priv->regs;
+
+   if (channel != priv->active_channel) {
+   error("Requested channel is no

[U-Boot] [PATCH V3 10/14] Exynos54xx: dts: add ADC node

This commit adds common ADC node, which is disabled as default.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- new commit
---
 arch/arm/dts/exynos54xx.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/dts/exynos54xx.dtsi b/arch/arm/dts/exynos54xx.dtsi
index bd3619d..daa6a33 100644
--- a/arch/arm/dts/exynos54xx.dtsi
+++ b/arch/arm/dts/exynos54xx.dtsi
@@ -42,6 +42,13 @@
xhci1 = "/xhci@1240";
};
 
+   adc@12D1 {
+   compatible = "samsung,exynos-adc-v2";
+   reg = <0x12D1 0x100>;
+   interrupts = <0 106 0>;
+   status = "disabled";
+   };
+
i2c@12CA {
#address-cells = <1>;
#size-cells = <0>;
-- 
1.9.1

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

[U-Boot] [PATCH V3 13/14] sandbox: add ADC driver

This commit adds implementation of Sandbox ADC device emulation.
The device provides:
- single and multi-channel conversion
- 4 channels with predefined conversion output data
- 16-bit resolution

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V3:
- new commit
---
 arch/sandbox/dts/sandbox_pmic.dtsi |   2 +-
 arch/sandbox/dts/test.dts  |   6 ++
 configs/sandbox_defconfig  |   2 +
 drivers/adc/Kconfig|   9 ++
 drivers/adc/Makefile   |   1 +
 drivers/adc/sandbox.c  | 174 +
 6 files changed, 193 insertions(+), 1 deletion(-)
 create mode 100644 drivers/adc/sandbox.c

diff --git a/arch/sandbox/dts/sandbox_pmic.dtsi 
b/arch/sandbox/dts/sandbox_pmic.dtsi
index 44a26b1..ce261b9 100644
--- a/arch/sandbox/dts/sandbox_pmic.dtsi
+++ b/arch/sandbox/dts/sandbox_pmic.dtsi
@@ -55,7 +55,7 @@
regulator-always-on;
};
 
-   buck2 {
+   buck2: buck2 {
regulator-name = "SUPPLY_3.3V";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 730de8a..e2c4971 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -189,6 +189,12 @@
};
};
 
+   adc@0 {
+   compatible = "sandbox,adc";
+   vdd-supply = <>;
+   vss-microvolts = <0>;
+   };
+
leds {
compatible = "gpio-leds";
 
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 67ae99b..94c8e68 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -65,3 +65,5 @@ CONFIG_UT_DM=y
 CONFIG_UT_ENV=y
 CONFIG_REMOTEPROC_SANDBOX=y
 CONFIG_CMD_REMOTEPROC=y
+CONFIG_ADC=y
+CONFIG_ADC_SANDBOX=y
diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
index 223b65e..e5335f7 100644
--- a/drivers/adc/Kconfig
+++ b/drivers/adc/Kconfig
@@ -19,3 +19,12 @@ config ADC_EXYNOS
  - 10 analog input channels
  - 12-bit resolution
  - 600 KSPS of sample rate
+
+config ADC_SANDBOX
+   bool "Enable Sandbox ADC test driver"
+   help
+ This enables driver for Sandbox ADC device emulation.
+ It provides:
+ - 4 analog input channels
+ - 16-bit resolution
+ - single and multi-channel conversion mode
diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
index eb85b8b..cebf26d 100644
--- a/drivers/adc/Makefile
+++ b/drivers/adc/Makefile
@@ -7,3 +7,4 @@
 
 obj-$(CONFIG_ADC) += adc-uclass.o
 obj-$(CONFIG_ADC_EXYNOS) += exynos-adc.o
+obj-$(CONFIG_ADC_SANDBOX) += sandbox.o
diff --git a/drivers/adc/sandbox.c b/drivers/adc/sandbox.c
new file mode 100644
index 000..3718922
--- /dev/null
+++ b/drivers/adc/sandbox.c
@@ -0,0 +1,174 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics
+ * Przemyslaw Marczak <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct sandbox_adc_priv - sandbox ADC device's operation status and data
+ *
+ * @conversion_status - conversion status: ACTIVE (started) / INACTIVE 
(stopped)
+ * @conversion_mode   - conversion mode: single or multi-channel
+ * @active_channel- active channel number, valid for single channel mode
+ * data[] - channels data
+ */
+struct sandbox_adc_priv {
+   int conversion_status;
+   int conversion_mode;
+   int active_channel_mask;
+   unsigned int data[4];
+};
+
+int sandbox_adc_start_channel(struct udevice *dev, int channel)
+{
+   struct sandbox_adc_priv *priv = dev_get_priv(dev);
+
+   /* Set single-channel mode */
+   priv->conversion_mode = SANDBOX_ADC_MODE_SINGLE_CHANNEL;
+   /* Select channel */
+   priv->active_channel_mask = 1 << channel;
+   /* Start conversion */
+   priv->conversion_status = SANDBOX_ADC_ACTIVE;
+
+   return 0;
+}
+
+int sandbox_adc_start_channels(struct udevice *dev, unsigned int channel_mask)
+{
+   struct sandbox_adc_priv *priv = dev_get_priv(dev);
+
+   /* Set single-channel mode */
+   priv->conversion_mode = SANDBOX_ADC_MODE_MULTI_CHANNEL;
+   /* Select channel */
+   priv->active_channel_mask = channel_mask;
+   /* Start conversion */
+   priv->conversion_status = SANDBOX_ADC_ACTIVE;
+
+   return 0;
+}
+
+int sandbox_adc_channel_data(struct udevice *dev, int channel,
+unsigned int *data)
+{
+   struct sandbox_adc_priv *priv = dev_get_priv(dev);
+
+   /* For single-channel conversion mode, check if channel was selected */
+   if ((priv->conversion_mode == SANDBOX_ADC_MODE_SINGLE_CHANNEL) &&
+   !(priv->active_channel_mask & (1 << channel))) {
+

[U-Boot] [PATCH V3 14/14] sandbox: add ADC unit tests

This commit adds unit tests for ADC uclass's methods using sandbox ADC.

Testing proper ADC binding:
- dm_test_adc_bind()- device binding
- dm_test_adc_wrong_channel_selection() - checking wrong channel selection

Testing ADC supply operations:
- dm_test_adc_supply():
  - Vdd/Vss values validating
  - Vdd regulator updated value validating
  - Vdd regulator's auto enable state validating

Testing ADC operations results:
- dm_test_adc_single_channel_conversion() - single channel start/data
- dm_test_adc_single_channel_shot()   - single channel shot
- dm_test_adc_multi_channel_conversion()  - multi channel start/data
- dm_test_adc_multi_channel_shot()- multi channel single shot

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V3:
- new commit
---
 include/power/sandbox_pmic.h |   4 ++
 test/dm/Makefile |   1 +
 test/dm/adc.c| 165 +++
 3 files changed, 170 insertions(+)
 create mode 100644 test/dm/adc.c

diff --git a/include/power/sandbox_pmic.h b/include/power/sandbox_pmic.h
index 8547674..7fdbfb9 100644
--- a/include/power/sandbox_pmic.h
+++ b/include/power/sandbox_pmic.h
@@ -126,6 +126,10 @@ enum {
 #define SANDBOX_BUCK1_AUTOSET_EXPECTED_UA  20
 #define SANDBOX_BUCK1_AUTOSET_EXPECTED_ENABLE  true
 
+/* BUCK2: for testing sandbox ADC's supply */
+#define SANDBOX_BUCK2_INITIAL_EXPECTED_UV  300
+#define SANDBOX_BUCK2_SET_UV   330
+
 /* LDO1/2 for testing regulator_list_autoset() */
 #define SANDBOX_LDO1_AUTOSET_EXPECTED_UV   180
 #define SANDBOX_LDO1_AUTOSET_EXPECTED_UA   10
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 7b3626c..39630f6 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -33,4 +33,5 @@ obj-y += syscon.o
 obj-$(CONFIG_DM_USB) += usb.o
 obj-$(CONFIG_DM_PMIC) += pmic.o
 obj-$(CONFIG_DM_REGULATOR) += regulator.o
+obj-$(CONFIG_ADC) += adc.o
 endif
diff --git a/test/dm/adc.c b/test/dm/adc.c
new file mode 100644
index 000..b0d4fe5
--- /dev/null
+++ b/test/dm/adc.c
@@ -0,0 +1,165 @@
+/*
+ * Tests for the driver model ADC API
+ *
+ * Copyright (c) 2015 Samsung Electronics
+ * Przemyslaw Marczak <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int dm_test_adc_bind(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+
+   ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc", ));
+   ut_asserteq_str(SANDBOX_ADC_DEVNAME, dev->name);
+
+   return 0;
+}
+DM_TEST(dm_test_adc_bind, DM_TESTF_SCAN_FDT);
+
+static int dm_test_adc_wrong_channel_selection(struct unit_test_state *uts)
+{
+   struct udevice *dev;
+
+   ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc", ));
+   ut_asserteq(-EINVAL, adc_start_channel(dev, SANDBOX_ADC_CHANNELS));
+
+   return 0;
+}
+DM_TEST(dm_test_adc_wrong_channel_selection, DM_TESTF_SCAN_FDT);
+
+static int dm_test_adc_supply(struct unit_test_state *uts)
+{
+   struct udevice *supply;
+   struct udevice *dev;
+   int uV;
+
+   ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc", ));
+
+   /* Test Vss value - predefined 0 uV */
+   ut_assertok(adc_vss_value(dev, ));
+   ut_asserteq(SANDBOX_ADC_VSS_VALUE, uV);
+
+   /* Test Vdd initial value - buck2 */
+   ut_assertok(adc_vdd_value(dev, ));
+   ut_asserteq(SANDBOX_BUCK2_INITIAL_EXPECTED_UV, uV);
+
+   /* Change Vdd value - buck2 manual preset */
+   ut_assertok(regulator_get_by_devname(SANDBOX_BUCK2_DEVNAME, ));
+   ut_assertok(regulator_set_value(supply, SANDBOX_BUCK2_SET_UV));
+   ut_asserteq(SANDBOX_BUCK2_SET_UV, regulator_get_value(supply));
+
+   /* Update ADC platdata and get new Vdd value */
+   ut_assertok(adc_vdd_value(dev, ));
+   ut_asserteq(SANDBOX_BUCK2_SET_UV, uV);
+
+   /* Disable buck2 and test ADC supply enable function */
+   ut_assertok(regulator_set_enable(supply, false));
+   ut_asserteq(false, regulator_get_enable(supply));
+   /* adc_start_channel() should enable the supply regulator */
+   ut_assertok(adc_start_channel(dev, 0));
+   ut_asserteq(true, regulator_get_enable(supply));
+
+   return 0;
+}
+DM_TEST(dm_test_adc_supply, DM_TESTF_SCAN_FDT);
+
+struct adc_channel adc_channel_test_data[] = {
+   { 0, SANDBOX_ADC_CHANNEL0_DATA },
+   { 1, SANDBOX_ADC_CHANNEL1_DATA },
+   { 2, SANDBOX_ADC_CHANNEL2_DATA },
+   { 3, SANDBOX_ADC_CHANNEL3_DATA },
+};
+
+static int dm_test_adc_single_channel_conversion(struct unit_test_state *uts)
+{
+   struct adc_channel *tdata = adc_channel_test_data;
+   unsigned int i, data;
+   struct udevice *dev;
+
+   ut_assertok(uclass_get_de

[U-Boot] [PATCH V3 11/14] Odroid-XU3: dts: enable ADC, with request for pre-reloc bind

This ADC is required for Odroid's board revision detection.
The pre-reloc request is enabled, since board detection will
be done in one of early function call.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- new commit
---
 arch/arm/dts/exynos5422-odroidxu3.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts 
b/arch/arm/dts/exynos5422-odroidxu3.dts
index 9dec679..690c747 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -31,6 +31,11 @@
0xb000 0xea0>;
};
 
+   adc@12D1 {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+   };
+
i2c@12CA {
s2mps11_pmic@66 {
compatible = "samsung,s2mps11-pmic";
-- 
1.9.1

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

[U-Boot] [PATCH V3 03/14] Peach-Pi: dts: add cpu-model string

This platform is based on Exynos5800 but the cpu id is 0x5422.
This doesn't fit the common Exynos SoC name convention, so now,
the CPU name is defined by device tree string, to be printed
properly.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- move cpu name from config to dts
---
 arch/arm/dts/exynos5800-peach-pi.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/exynos5800-peach-pi.dts 
b/arch/arm/dts/exynos5800-peach-pi.dts
index 1d7ff23..76826dc 100644
--- a/arch/arm/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/dts/exynos5800-peach-pi.dts
@@ -12,6 +12,7 @@
 
 / {
model = "Samsung/Google Peach Pi board based on Exynos5800";
+   cpu-model = "Exynos5800";
 
compatible = "google,pit-rev#", "google,pit",
"google,peach", "samsung,exynos5800", "samsung,exynos5";
-- 
1.9.1

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

[U-Boot] [PATCH V3 00/14] Add board detection for Odroid XU3 / XU3Lite / XU4

This patchset adds:
- 'cpu-model' dts property for Chromebook Peach Pi as Exynos5800
- set the cpu id of Exynos5422 to 0x5422
- S2MPS11 PMIC I/O driver
- ADC uclass implementation
- Exynos5420-compatible (9-channel, 12-bit) ADC driver
- new file for Exynos5: exynos5-dt-types.c
- board detection for Odroid XU3 / XU3lite / XU4
- fixed ADC value for XU4 detection

This was tested on Odroid XU3/XU3 Lite/XU4 and sandbox.

Tested with buildman for samsung.

Available on github:
https://github.com/bobenstein/u-boot/tree/xu3-detect-patchset-v1
https://github.com/bobenstein/u-boot/tree/xu3-detect-patchset-v2
https://github.com/bobenstein/u-boot/tree/xu3-detect-patchset-v3

Przemyslaw Marczak (14):
  samsung: board/misc: check returned pointer for get_board_type() calls
  s5p: cpu_info: print "cpu-model" if exists in dts
  Peach-Pi: dts: add cpu-model string
  Exynos5422/5800: set cpu id to 0x5422
  dm: pmic: add s2mps11 PMIC I/O driver
  dm: regulator: add function device_get_supply_regulator()
  dm: adc: add simple ADC uclass implementation
  dm: adc: add Exynos54xx compatible ADC driver
  Odroid-XU3: enable s2mps11 PMIC support
  Exynos54xx: dts: add ADC node
  Odroid-XU3: dts: enable ADC, with request for pre-reloc bind
  exynos5-dt-types: add board detection for Odroid XU3/XU3L/XU4.
  sandbox: add ADC driver
  sandbox: add ADC unit tests

 arch/arm/cpu/armv7/s5p-common/cpu_info.c   |  14 +-
 arch/arm/dts/exynos5422-odroidxu3.dts  |  12 +
 arch/arm/dts/exynos54xx.dtsi   |   7 +
 arch/arm/dts/exynos5800-peach-pi.dts   |   1 +
 arch/arm/mach-exynos/clock.c   |  16 +-
 arch/arm/mach-exynos/clock_init_exynos5.c  |   2 +-
 arch/arm/mach-exynos/common_setup.h|   4 +-
 arch/arm/mach-exynos/include/mach/adc.h|  44 
 arch/arm/mach-exynos/include/mach/cpu.h|   6 +-
 arch/arm/mach-exynos/include/mach/gpio.h   |   4 +-
 arch/arm/mach-exynos/pinmux.c  |   2 +-
 arch/arm/mach-exynos/power.c   |   2 +-
 arch/sandbox/dts/sandbox_pmic.dtsi |   2 +-
 arch/sandbox/dts/test.dts  |   6 +
 board/samsung/common/Makefile  |   5 +-
 board/samsung/common/board.c   |   4 +-
 board/samsung/common/exynos5-dt-types.c| 196 ++
 board/samsung/common/exynos5-dt.c  |  12 +
 board/samsung/common/misc.c|   3 +
 configs/odroid-xu3_defconfig   |   5 +
 configs/sandbox_defconfig  |   2 +
 doc/device-tree-bindings/adc/adc.txt   |  62 +
 doc/device-tree-bindings/exynos/soc.txt|  21 ++
 doc/device-tree-bindings/pmic/s2mps11.txt  |  17 ++
 drivers/Kconfig|   2 +
 drivers/Makefile   |   1 +
 drivers/adc/Kconfig|  30 +++
 drivers/adc/Makefile   |  10 +
 drivers/adc/adc-uclass.c   | 409 +
 drivers/adc/exynos-adc.c   | 145 ++
 drivers/adc/sandbox.c  | 174 
 drivers/power/pmic/Kconfig |  14 +
 drivers/power/pmic/Makefile|   1 +
 drivers/power/pmic/s2mps11.c   |  62 +
 drivers/power/regulator/regulator-uclass.c |   7 +
 include/adc.h  | 288 
 include/configs/odroid_xu3.h   |  12 +
 include/dm/uclass-id.h |   1 +
 include/power/regulator.h  |  16 ++
 include/power/s2mps11.h| 109 
 include/power/sandbox_pmic.h   |   4 +
 include/samsung/exynos5-dt-types.h |  27 ++
 test/dm/Makefile   |   1 +
 test/dm/adc.c  | 165 
 44 files changed, 1904 insertions(+), 23 deletions(-)
 create mode 100644 board/samsung/common/exynos5-dt-types.c
 create mode 100644 doc/device-tree-bindings/adc/adc.txt
 create mode 100644 doc/device-tree-bindings/exynos/soc.txt
 create mode 100644 doc/device-tree-bindings/pmic/s2mps11.txt
 create mode 100644 drivers/adc/Kconfig
 create mode 100644 drivers/adc/Makefile
 create mode 100644 drivers/adc/adc-uclass.c
 create mode 100644 drivers/adc/exynos-adc.c
 create mode 100644 drivers/adc/sandbox.c
 create mode 100644 drivers/power/pmic/s2mps11.c
 create mode 100644 include/adc.h
 create mode 100644 include/power/s2mps11.h
 create mode 100644 include/samsung/exynos5-dt-types.h
 create mode 100644 test/dm/adc.c

-- 
1.9.1

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

[U-Boot] [PATCH V3 01/14] samsung: board/misc: check returned pointer for get_board_type() calls

The function get_board_type() is called in two places by common code,
but the returned pointer was never check.

This commit adds checking the returned pointer, before use it.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
---
Changes V2:
- new commit
---
 board/samsung/common/board.c | 4 ++--
 board/samsung/common/misc.c  | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index d32c75d..1334c22 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -304,8 +304,8 @@ int checkboard(void)
printf("Board: %s\n", board_info ? board_info : "unknown");
 #ifdef CONFIG_BOARD_TYPES
board_info = get_board_type();
-
-   printf("Model: %s\n", board_info ? board_info : "unknown");
+   if (board_info)
+   printf("Type:  %s\n", board_info);
 #endif
return 0;
 }
diff --git a/board/samsung/common/misc.c b/board/samsung/common/misc.c
index e0e2c48..c8316d8 100644
--- a/board/samsung/common/misc.c
+++ b/board/samsung/common/misc.c
@@ -85,6 +85,9 @@ void set_board_info(void)
 
 #ifdef CONFIG_BOARD_TYPES
bdtype = get_board_type();
+   if (!bdtype)
+   bdtype = "";
+
sprintf(info, "%s%s", bdname, bdtype);
setenv("boardname", info);
 #endif
-- 
1.9.1

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

[U-Boot] [PATCH V3 06/14] dm: regulator: add function device_get_supply_regulator()

Some devices are supplied by configurable regulator's output.
But there was no function for getting it. This commit adds
function, that allows for getting the supply device by it's phandle.

The returned regulator device can be used with regulator uclass's API.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V3:
- new commit
---
 drivers/power/regulator/regulator-uclass.c |  7 +++
 include/power/regulator.h  | 16 
 2 files changed, 23 insertions(+)

diff --git a/drivers/power/regulator/regulator-uclass.c 
b/drivers/power/regulator/regulator-uclass.c
index a5170df..4241a4c 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -138,6 +138,13 @@ int regulator_get_by_devname(const char *devname, struct 
udevice **devp)
return uclass_get_device_by_name(UCLASS_REGULATOR, devname, devp);
 }
 
+int device_get_supply_regulator(struct udevice *dev, const char *supply_name,
+   struct udevice **devp)
+{
+   return uclass_get_device_by_phandle(UCLASS_REGULATOR, dev,
+   supply_name, devp);
+}
+
 int regulator_autoset(struct udevice *dev)
 {
struct dm_regulator_uclass_platdata *uc_pdata;
diff --git a/include/power/regulator.h b/include/power/regulator.h
index 1a51c3f..63c0814 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -419,4 +419,20 @@ int regulator_get_by_devname(const char *devname, struct 
udevice **devp);
  */
 int regulator_get_by_platname(const char *platname, struct udevice **devp);
 
+/**
+ * device_get_supply_regulator: returns the pointer to the supply regulator.
+ * Search by phandle, found in device's node.
+ *
+ * Note: Please pay attention to proper order of device bind sequence.
+ * The regulator device searched by the phandle, must be binded before
+ * this function call.
+ *
+ * @dev - device with supply phandle
+ * @supply_name - phandle name of regulator
+ * @devp- returned pointer to the supply device
+ * @return 0 on success or negative value of errno.
+ */
+int device_get_supply_regulator(struct udevice *dev, const char *supply_name,
+   struct udevice **devp);
+
 #endif /* _INCLUDE_REGULATOR_H_ */
-- 
1.9.1

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

[U-Boot] [PATCH V3 07/14] dm: adc: add simple ADC uclass implementation

This commit adds:
- new uclass id: UCLASS_ADC
- new uclass driver: drivers/adc/adc-uclass.c

The new uclass's API allows for ADC operation on:
* single-channel with channel selection by a number
* multti-channel with channel selection by bit mask

ADC uclass's functions:
* single-channel:
  - adc_start_channel()- start channel conversion
  - adc_channel_data() - get conversion data
  - adc_channel_single_shot()  - start/get conversion data
* multi-channel:
  - adc_start_channels()   - start selected channels conversion
  - adc_channels_data()- get conversion data
  - adc_channels_single_shot() - start/get conversion data for channels
 selected by bit mask
* general:
  - adc_stop()  - stop the conversion
  - adc_vdd_value() - positive reference Voltage value with polarity [uV]
  - adc_vss_value() - negative reference Voltage value with polarity [uV]
  - adc_data_mask() - conversion data bit mask

The device tree can provide below constraints/properties:
- vdd-polarity-negative: if true: Vdd = vdd-microvolts * (-1)
- vss-polarity-negative: if true: Vss = vss-microvolts * (-1)
- vdd-supply:phandle to Vdd regulator's node
- vss-supply:phandle to Vss regulator's node
And optional, checked only if the above corresponding, doesn't exist:
  - vdd-microvolts:  positive reference Voltage [uV]
  - vss-microvolts:  negative reference Voltage [uV]

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- new commit - introduce ADC uclass driver
Changes V3:
- Add binding info
- ADC uclass's code rework, add single/multi-channel API
- Select single channel by a number and multi, by a bit mask
- Wait for conversion end in uclass's internal function
- Add ADC supply polarity constraint
- Add function for getting supply Voltage with polarity
---
 doc/device-tree-bindings/adc/adc.txt |  62 ++
 drivers/Kconfig  |   2 +
 drivers/Makefile |   1 +
 drivers/adc/Kconfig  |  12 +
 drivers/adc/Makefile |   8 +
 drivers/adc/adc-uclass.c | 409 +++
 include/adc.h| 288 
 include/dm/uclass-id.h   |   1 +
 8 files changed, 783 insertions(+)
 create mode 100644 doc/device-tree-bindings/adc/adc.txt
 create mode 100644 drivers/adc/Kconfig
 create mode 100644 drivers/adc/Makefile
 create mode 100644 drivers/adc/adc-uclass.c
 create mode 100644 include/adc.h

diff --git a/doc/device-tree-bindings/adc/adc.txt 
b/doc/device-tree-bindings/adc/adc.txt
new file mode 100644
index 000..463de3c
--- /dev/null
+++ b/doc/device-tree-bindings/adc/adc.txt
@@ -0,0 +1,62 @@
+ADC device binding
+
+There are no mandatory properties for ADC. However, if Voltage info is 
required,
+then there are two options:
+- use microvolts constraint or
+- use regulator phandle to enable/read supply's Voltage
+
+Properties and constraints:
+*optional and always checked, Voltage polarity info:
+- vdd-polarity-negative:  positive reference Voltage has a negative polarity
+- vss-polarity-negative:  negative reference Voltage has a negative polarity
+
+Chose one option, for each supply (Vdd/Vss):
+
+*optional and always checked, supply Voltage constants:
+- vdd-supply:phandle to Vdd regulator's node
+- vss-supply:phandle to Vss regulator's node
+
+*optional and checked only if the above corresponding, doesn't exist:
+- vdd-microvolts:positive reference Voltage value [uV]
+- vss-microvolts:negative reference Voltage value [uV]
+
+Example with constant 'Vdd' value:
+adc@100 {
+   compatible = "some-adc";
+   reg = <0xaabb000 0x100>;
+   status = "enabled";
+   vdd-microvolts = <180>;
+};
+
+Example of supply phandle usage, for the ADC's VDD/VSS references as below:
+   ___ ___
+  |Sandbox|   |Sandbox|
+  : PMIC  :   :  ADC  :
+  .   .   .   .
+  |   | (Vdd) |   AIN0|-->
+  |  BUCK2|---|VDDref |
+  | (3.3V)|  _|VSSref |
+  |___| | |___|
+   _|_
+
+For the above PMIC, the node can be defined as follows:
+sandbox_pmic {
+   compatible = "sandbox,pmic";
+   ...
+   buck2: buck2 {
+   regulator-name = "SUPPLY_3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+   ...
+};
+
+For the above ADC, the node can be defined as follows:
+adc@0 {
+   compatible = "sandbox,adc";
+   vdd-supply = <>;
+   vss-microvolts = <0>;
+};
+
+The ADC uclass code, will enable the supply before start of the conversion,
+but it will not configure the regulator settings.
diff --git a/drivers/Kconfig b/drivers/Kconfig
index ba88b5e..c4

[U-Boot] [PATCH V3 09/14] Odroid-XU3: enable s2mps11 PMIC support

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- none
Chabges V3:
- fix merge conflict in configs/odroid-xu3_defconfig
---
 arch/arm/dts/exynos5422-odroidxu3.dts | 7 +++
 configs/odroid-xu3_defconfig  | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts 
b/arch/arm/dts/exynos5422-odroidxu3.dts
index d0a8621..9dec679 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -31,6 +31,13 @@
0xb000 0xea0>;
};
 
+   i2c@12CA {
+   s2mps11_pmic@66 {
+   compatible = "samsung,s2mps11-pmic";
+   reg = <0x66>;
+   };
+   };
+
ehci@1211 {
samsung,vbus-gpio = < 6 GPIO_ACTIVE_HIGH>;
};
diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
index 479af9e..780dcab 100644
--- a/configs/odroid-xu3_defconfig
+++ b/configs/odroid-xu3_defconfig
@@ -9,7 +9,10 @@ CONFIG_SYS_PROMPT="ODROID-XU3 # "
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_DM_I2C_COMPAT=y
 CONFIG_DM_PMIC=y
+CONFIG_CMD_PMIC=y
+CONFIG_ERRNO_STR=y
 CONFIG_DM_REGULATOR=y
+CONFIG_PMIC_S2MPS11=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_VIDEO_BRIDGE=y
-- 
1.9.1

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

[U-Boot] [PATCH V3 04/14] Exynos5422/5800: set cpu id to 0x5422

The proper CPU ID for those Exynos variants is 0x5422,
but before the 0x5800 was set. This commit fix this back.

Changes:
- set cpu id to 0x5422 instead of 0x5800
- remove macro proid_is_exynos5800()
- add macro proid_is_exynos5422()
- change the calls to proid_is_exynos5800() with new macro

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- none
---
 arch/arm/mach-exynos/clock.c  | 16 
 arch/arm/mach-exynos/clock_init_exynos5.c |  2 +-
 arch/arm/mach-exynos/common_setup.h   |  4 ++--
 arch/arm/mach-exynos/include/mach/cpu.h   |  6 +++---
 arch/arm/mach-exynos/include/mach/gpio.h  |  4 ++--
 arch/arm/mach-exynos/pinmux.c |  2 +-
 arch/arm/mach-exynos/power.c  |  2 +-
 7 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
index 18eadf5..3d31f9d 100644
--- a/arch/arm/mach-exynos/clock.c
+++ b/arch/arm/mach-exynos/clock.c
@@ -159,8 +159,8 @@ static int exynos_get_pll_clk(int pllreg, unsigned int r, 
unsigned int k)
div = PLL_DIV_1024;
else if (proid_is_exynos4412())
div = PLL_DIV_65535;
-   else if (proid_is_exynos5250() || proid_is_exynos5420()
-|| proid_is_exynos5800())
+   else if (proid_is_exynos5250() || proid_is_exynos5420() ||
+proid_is_exynos5422())
div = PLL_DIV_65536;
else
return 0;
@@ -346,7 +346,7 @@ static struct clk_bit_info *get_clk_bit_info(int peripheral)
int i;
struct clk_bit_info *info;
 
-   if (proid_is_exynos5420() || proid_is_exynos5800())
+   if (proid_is_exynos5420() || proid_is_exynos5422())
info = exynos542x_bit_info;
else
info = exynos5_bit_info;
@@ -558,7 +558,7 @@ static unsigned long exynos542x_get_periph_rate(int 
peripheral)
 unsigned long clock_get_periph_rate(int peripheral)
 {
if (cpu_is_exynos5()) {
-   if (proid_is_exynos5420() || proid_is_exynos5800())
+   if (proid_is_exynos5420() || proid_is_exynos5422())
return exynos542x_get_periph_rate(peripheral);
return exynos5_get_periph_rate(peripheral);
} else {
@@ -1576,7 +1576,7 @@ static unsigned long exynos4_get_i2c_clk(void)
 unsigned long get_pll_clk(int pllreg)
 {
if (cpu_is_exynos5()) {
-   if (proid_is_exynos5420() || proid_is_exynos5800())
+   if (proid_is_exynos5420() || proid_is_exynos5422())
return exynos542x_get_pll_clk(pllreg);
return exynos5_get_pll_clk(pllreg);
} else if (cpu_is_exynos4()) {
@@ -1692,7 +1692,7 @@ void set_mmc_clk(int dev_index, unsigned int div)
div -= 1;
 
if (cpu_is_exynos5()) {
-   if (proid_is_exynos5420() || proid_is_exynos5800())
+   if (proid_is_exynos5420() || proid_is_exynos5422())
exynos5420_set_mmc_clk(dev_index, div);
else
exynos5_set_mmc_clk(dev_index, div);
@@ -1708,7 +1708,7 @@ unsigned long get_lcd_clk(void)
} else if (cpu_is_exynos5()) {
if (proid_is_exynos5420())
return exynos5420_get_lcd_clk();
-   else if (proid_is_exynos5800())
+   else if (proid_is_exynos5422())
return exynos5800_get_lcd_clk();
else
return exynos5_get_lcd_clk();
@@ -1740,7 +1740,7 @@ void set_mipi_clk(void)
 int set_spi_clk(int periph_id, unsigned int rate)
 {
if (cpu_is_exynos5()) {
-   if (proid_is_exynos5420() || proid_is_exynos5800())
+   if (proid_is_exynos5420() || proid_is_exynos5422())
return exynos5420_set_spi_clk(periph_id, rate);
return exynos5_set_spi_clk(periph_id, rate);
}
diff --git a/arch/arm/mach-exynos/clock_init_exynos5.c 
b/arch/arm/mach-exynos/clock_init_exynos5.c
index 0200fd1..1b7498d 100644
--- a/arch/arm/mach-exynos/clock_init_exynos5.c
+++ b/arch/arm/mach-exynos/clock_init_exynos5.c
@@ -971,7 +971,7 @@ static void exynos5420_system_clock_init(void)
 
 void system_clock_init(void)
 {
-   if (proid_is_exynos5420() || proid_is_exynos5800())
+   if (proid_is_exynos5420() || proid_is_exynos5422())
exynos5420_system_clock_init();
else
exynos5250_system_clock_init();
diff --git a/arch/arm/mach-exynos/common_setup.h 
b/arch/arm/mach-exynos/common_setup.h
index 67aac2d..2829fb2 100644
--- a/arch/arm/mach-exynos/common_setup.h
+++ b/arch/arm/mach-exynos/common_setup.h
@@ -78,7 +78,7 @@ static inline void configure_l2_ctlr(void)
CACHE_TAG_RA

[U-Boot] [PATCH V3 12/14] exynos5-dt-types: add board detection for Odroid XU3/XU3L/XU4.

This commit adds additional file with implementation of board
detection code for Odroid-XU3/XU4.

The detection depends on compatible found in fdt:
- "samsung,exynos5" - uses Exynos5 generic code
- "samsung,odroidxu3" - try detect XU3 revision

There are few revisions of Odroid XU3/XU4, each can be detected
by checking the value of channel 9 of built-in ADC:
 Rev   ADC  Board
 0.1 0  XU3 0.1
 0.2   372  XU3 0.2 | XU3L - no DISPLAYPORT
 0.3  1280  XU4 0.1

The detection code depends on the ADC+10% value.

Implementation of functions:
- set_board_type() - read ADC and set type
- get_board_rev()  - returns board revision: 1..3
- get_board_type() - returns board type string

Additional functions with return values of bool:
- board_is_generic()   - true if found compatible "samsung,exynos5"
 but not "samsung,odroidxu3"
- board_is_odroidxu3() - true if found compatible "samsung,odroidxu3"
 and one of XU3 revision.
- board_is_odroidxu4() - true if found compatible "samsung,odroidxu3"
 and XU4 revision.

After I2C controller init, the get_board_type() can check
if the XU3 board is a "Lite" variant, by probing chip
0x40 on I2C0 (INA231 - exists only on non-lite).
This is useful for setting fdt file name at misc_init_r().

Enabled configs:
- CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
- CONFIG_ODROID_REV_AIN
- CONFIG_REVISION_TAG
- CONFIG_BOARD_TYPES

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- move detection code from exynos5-dt.c to exynos5-dt-types.c
- add header with board type function declarations
- check for compatible before do the detection
- update the ADC max values with 20% tolerance
- fix XU4 adc value, related to mistake from table in XU4 schematic
- return "Not supported" for XU4 when calls one of:
  --dfu_get_alt_boot()
  --dfu_get_alt_system()
- extend ${dfu_alt_system} by strings:
  -- 'exynos5422-odroidxu3-lite.dtb'
  -- 'exynos5422-odroidxu4.dtb' - allows prepare card on XU3

Changes V3:
- fix merge conflict in: configs/odroid-xu3_defconfig
---
 board/samsung/common/Makefile   |   5 +-
 board/samsung/common/exynos5-dt-types.c | 196 
 board/samsung/common/exynos5-dt.c   |  12 ++
 configs/odroid-xu3_defconfig|   2 +
 include/configs/odroid_xu3.h|  12 ++
 include/samsung/exynos5-dt-types.h  |  27 +
 6 files changed, 253 insertions(+), 1 deletion(-)
 create mode 100644 board/samsung/common/exynos5-dt-types.c
 create mode 100644 include/samsung/exynos5-dt-types.h

diff --git a/board/samsung/common/Makefile b/board/samsung/common/Makefile
index 6cbd906..ef1a8f3 100644
--- a/board/samsung/common/Makefile
+++ b/board/samsung/common/Makefile
@@ -11,5 +11,8 @@ obj-$(CONFIG_MISC_COMMON) += misc.o
 
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_BOARD_COMMON) += board.o
-obj-$(CONFIG_EXYNOS5_DT)   += exynos5-dt.o
+ifdef CONFIG_EXYNOS5_DT
+obj-y += exynos5-dt.o
+obj-$(CONFIG_BOARD_TYPES) += exynos5-dt-types.o
+endif
 endif
diff --git a/board/samsung/common/exynos5-dt-types.c 
b/board/samsung/common/exynos5-dt-types.c
new file mode 100644
index 000..48fd1f7
--- /dev/null
+++ b/board/samsung/common/exynos5-dt-types.c
@@ -0,0 +1,196 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics
+ * Przemyslaw Marczak <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct udevice_id board_ids[] = {
+   { .compatible = "samsung,odroidxu3", .data = EXYNOS5_BOARD_ODROID_XU3 },
+   { .compatible = "samsung,exynos5", .data = EXYNOS5_BOARD_GENERIC },
+   { },
+};
+
+/**
+ * Odroix XU3/4 board revisions:
+ * Rev   ADCmax  Board
+ * 0.1 0 XU3 0.1
+ * 0.2   410 XU3 0.2 | XU3L - no DISPLAYPORT (probe I2C0:0x40 / INA231)
+ * 0.3  1408 XU4 0.1
+ * Use +10 % for ADC value tolerance.
+ */
+struct odroid_rev_info odroid_info[] = {
+   { EXYNOS5_BOARD_ODROID_XU3_REV01, 1, 10, "xu3" },
+   { EXYNOS5_BOARD_ODROID_XU3_REV02, 2, 410, "xu3" },
+   { EXYNOS5_BOARD_ODROID_XU4_REV01, 1, 1408, "xu4" },
+   { EXYNOS5_BOARD_ODROID_UNKNOWN, 0, 4095, "unknown" },
+};
+
+static unsigned int odroid_get_rev(void)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(odroid_info); i++) {
+   if (odroid_info[i].board_type == gd->board_type)
+   return odroid_info[i].board_rev;
+   }
+
+   return 0;
+}
+
+static int odroid_get_board_type(void)
+{
+   unsigned int adcval;
+   int ret, i;
+
+   ret = adc_channel_single_shot("adc

[U-Boot] [PATCH V3 02/14] s5p: cpu_info: print "cpu-model" if exists in dts

The CPU name for Exynos was concatenated with cpu id,
but for new Exynos platforms, like Chromebook Peach Pi
based on Exynos5800, the name of SoC variant does not
include the real SoC cpu id (0x5422).

For such case, the CPU name should be defined in device tree.

This commit introduces new device-tree property for Exynos:
- "cpu-model" - with cpu name string
If defined, then the cpu id is not printed.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- new commit
Changes V3
- add cpu-model binding info
---
 arch/arm/cpu/armv7/s5p-common/cpu_info.c | 14 +-
 doc/device-tree-bindings/exynos/soc.txt  | 21 +
 2 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/exynos/soc.txt

diff --git a/arch/arm/cpu/armv7/s5p-common/cpu_info.c 
b/arch/arm/cpu/armv7/s5p-common/cpu_info.c
index 154d674..764c661 100644
--- a/arch/arm/cpu/armv7/s5p-common/cpu_info.c
+++ b/arch/arm/cpu/armv7/s5p-common/cpu_info.c
@@ -5,9 +5,12 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include 
+#include 
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
 /* Default is s5pc100 */
 unsigned int s5p_cpu_id = 0xC100;
 /* Default is EVT1 */
@@ -30,7 +33,16 @@ u32 get_device_type(void)
 #ifdef CONFIG_DISPLAY_CPUINFO
 int print_cpuinfo(void)
 {
-   printf("CPU:   %s%X @ ", s5p_get_cpu_name(), s5p_cpu_id);
+   const char *cpu_model;
+   int len;
+
+   /* For SoC with no real CPU ID in naming convention. */
+   cpu_model = fdt_getprop(gd->fdt_blob, 0, "cpu-model", );
+   if (cpu_model)
+   printf("CPU:   %.*s @ ", len, cpu_model);
+   else
+   printf("CPU:   %s%X @ ", s5p_get_cpu_name(), s5p_cpu_id);
+
print_freq(get_arm_clk(), "\n");
 
return 0;
diff --git a/doc/device-tree-bindings/exynos/soc.txt 
b/doc/device-tree-bindings/exynos/soc.txt
new file mode 100644
index 000..9ba6f3b
--- /dev/null
+++ b/doc/device-tree-bindings/exynos/soc.txt
@@ -0,0 +1,21 @@
+Exynos SoC model
+
+The "cpu-model" property is a non-standard extension for the device tree root
+node. Since the cpu id of some Exynos variants does not correspond to product
+name, this property fills the gap.
+
+For almost all Exynos based boards in the kernel, the product name corresponds
+to the device tree file name. The same name is generated in U-Boot, so the new
+property allows doing it automatically.
+
+Required properties:
+ - cpu-model : Exynos product name
+
+Example:
+
+/ {
+   model = "Samsung/Google Peach Pi board based on Exynos5800";
+   cpu-model = "Exynos5800";
+
+   compatible = ...
+};
-- 
1.9.1

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

Re: [U-Boot] [PATCH V3 07/14] dm: adc: add simple ADC uclass implementation


Hello all,

On 10/27/2015 01:08 PM, Przemyslaw Marczak wrote:

This commit adds:
- new uclass id: UCLASS_ADC
- new uclass driver: drivers/adc/adc-uclass.c

The new uclass's API allows for ADC operation on:
* single-channel with channel selection by a number
* multti-channel with channel selection by bit mask

ADC uclass's functions:
* single-channel:
   - adc_start_channel()- start channel conversion
   - adc_channel_data() - get conversion data
   - adc_channel_single_shot()  - start/get conversion data
* multi-channel:
   - adc_start_channels()   - start selected channels conversion
   - adc_channels_data()- get conversion data
   - adc_channels_single_shot() - start/get conversion data for channels
  selected by bit mask
* general:
   - adc_stop()  - stop the conversion
   - adc_vdd_value() - positive reference Voltage value with polarity [uV]
   - adc_vss_value() - negative reference Voltage value with polarity [uV]
   - adc_data_mask() - conversion data bit mask

The device tree can provide below constraints/properties:
- vdd-polarity-negative: if true: Vdd = vdd-microvolts * (-1)
- vss-polarity-negative: if true: Vss = vss-microvolts * (-1)
- vdd-supply:phandle to Vdd regulator's node
- vss-supply:phandle to Vss regulator's node
And optional, checked only if the above corresponding, doesn't exist:
   - vdd-microvolts:  positive reference Voltage [uV]
   - vss-microvolts:  negative reference Voltage [uV]

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Simon Glass <s...@chromium.org>
---
Changes V2:
- new commit - introduce ADC uclass driver
Changes V3:
- Add binding info
- ADC uclass's code rework, add single/multi-channel API
- Select single channel by a number and multi, by a bit mask
- Wait for conversion end in uclass's internal function
- Add ADC supply polarity constraint
- Add function for getting supply Voltage with polarity
---
  doc/device-tree-bindings/adc/adc.txt |  62 ++
  drivers/Kconfig  |   2 +
  drivers/Makefile |   1 +
  drivers/adc/Kconfig  |  12 +
  drivers/adc/Makefile |   8 +
  drivers/adc/adc-uclass.c | 409 +++
  include/adc.h| 288 
  include/dm/uclass-id.h   |   1 +
  8 files changed, 783 insertions(+)
  create mode 100644 doc/device-tree-bindings/adc/adc.txt
  create mode 100644 drivers/adc/Kconfig
  create mode 100644 drivers/adc/Makefile
  create mode 100644 drivers/adc/adc-uclass.c
  create mode 100644 include/adc.h



--- cut ---


diff --git a/drivers/adc/adc-uclass.c b/drivers/adc/adc-uclass.c
new file mode 100644
index 000..9233fcd
--- /dev/null
+++ b/drivers/adc/adc-uclass.c
@@ -0,0 +1,409 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics
+ * Przemyslaw Marczak <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define ADC_UCLASS_PLATDATA_SIZE   sizeof(struct adc_uclass_platdata)
+#define CHECK_NUMBER   true
+#define CHECK_MASK (!CHECK_NUMBER)
+
+/* TODO: add support for timer uclass (for early calls) */
+#ifdef CONFIG_SANDBOX_ARCH
+#define sdelay(x)  udelay(x)
+#else
+extern void sdelay(unsigned long loops);
+#endif

--- cut ---

I would like precise the sdelay() calls in this code.

I didn't make the cleanup for the sdelay(), as Simon requested.

For some architectures it's declared in a different headers, but we have 
timer uclass now, so this sdelay mess can be used temporary.


Now, I don't have time for moving Exynos timer to driver model.
And also it should be done as a separated patch set.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/7] Add board detection for Odroid XU3 / XU3Lite / XU4

2015-10-21 Thread Przemyslaw Marczak


Hello Siarhei, Anand,

On 10/21/2015 11:57 AM, Anand Moon wrote:

Hi Siarhei ,

On 21 October 2015 at 07:28, Siarhei Siamashka
<siarhei.siamas...@gmail.com> wrote:

On Mon, 31 Aug 2015 00:33:16 +0530
Anand Moon <linux.am...@gmail.com> wrote:


At the last moment I got this to work on my odroidxu3 board.

One problem I would like to address out is usb smsc95xx ethernet is not
getting started at the boot.

# usb start   /* command failed at the start */
--
U-Boot 2015.10-rc2-00226-g7dbe336 (Aug 30 2015 - 23:41:27 +0530) for
ODROID-XU3

CPU:   Exynos5422 @ 800 MHz
Model: Odroid XU3 based on EXYNOS5422
Board: Odroid XU3 based on EXYNOS5422
Model: xu3
DRAM:  2 GiB
MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
starting USB...
USB0:   USB EHCI 1.00
USB1:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB2:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
-


Hi Anand,

This looks like it might be the same problem as
 http://lists.denx.de/pipermail/u-boot/2015-October/230827.html

Simon Glass asked if this also happens on XU3, so maybe you could
test the same workaround on your board and provide feedback?

--


Odroid u3 also has the same problem
-
U-Boot 2015.10-rc5-00030-gac6a532-dirty (Oct 20 2015 - 01:37:27 +1030)

CPU:   Exynos4412 @ 1 GHz
Model: Odroid based on Exynos4412
Board: Odroid based on Exynos4412
Model: u3
DRAM:  2 GiB
LDO20@VDDQ_EMMC_1.8V: set 180 uV; enabling
LDO22@VDDQ_EMMC_2.8V: set 280 uV; enabling
LDO21@TFLASH_2.8V: set 280 uV; enabling
MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
*** Warning - bad CRC, using default environment

Net:   No ethernet found.
Hit any key to stop autoboot:  0
Odroid # setenv usbethaddr 02:DE:AD:BE:EF:FF
Odroid # usb start
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning usb for ethernet devices... 0 Ethernet Device(s) found
Odroid #
-

-Anand Moon

Best regards,
Siarhei Siamashka




Lukasz is working on that issue, and he discovered that the sequence of 
usb start/reset works for this and the Ethernet is detected then.


---
ODROID-XU3 # usb start
starting USB...
USB0:   USB EHCI 1.00
USB1:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB2:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
   scanning usb for ethernet devices... 0 Ethernet Device(s) found
ODROID-XU3 # usb reset
resetting USB...
USB0:   USB EHCI 1.00
USB1:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB2:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
   scanning usb for ethernet devices...
Error: sms0 address not set.
Warning: failed to set MAC address
1 Ethernet Device(s) found
ODROID-XU3 #
---

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] odroid DTB support

Hi Tom, Guillaume,

On 10/13/2015 09:37 AM, Guillaume Gardet wrote:

Le 12/10/2015 16:24, Tom Rini a écrit :

On Mon, Oct 12, 2015 at 10:54:04AM +0200, Guillaume Gardet wrote:

Hi,

Le 12/10/2015 01:45, Tom Rini a écrit :

On Fri, Oct 09, 2015 at 02:35:24PM +0200, Guillaume Gardet wrote:

Le 09/10/2015 14:23, Przemyslaw Marczak a écrit :

Hello Guillaume,

On 10/09/2015 02:11 PM, Guillaume Gardet wrote:

Hi Przemyslaw,

I would like to add DTB support for odroid board to be able to boot
upstream kernel easily.

I see 2 ways to do it:
* Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support to set
'board_rev'
and 'board_name' env vars. Then, you need a 'findfdt' script to
check
'board_rev' and set fdtfile accordingly (as done for OMAP4 panda
board)
* Set fdtfile name directly (as done for rpi or igep00x0).

What would you prefer?

Guillaume

Is, that the reason of adding the boot script by your last patches?

No, we need a boot script, because this is the way we boot our
openSUSE images (we boot with an initrd and some special bootargs).

Hang on, exynos stuff uses the generic distro hooks. Can you take a
look at doc/README.distro and see what openSUSE can hook into / provide
some feedback on what needs doing? Thanks!

This is true for odroid XU3 (Exynos5 based) but Odroid U3/X2 (Exynos4
based) has no generic distro hooks at the moment.

No, exynos-common pulls in generic distro. And in the event of boards
that do not the answer is to pull in the generic distro framework.

It seems that exynos-common includes only "config_distro_defaults.h",
not "config_distro_bootcmd.h".
And "config_distro_bootcmd.h" is needed for generic distro boot flow. Am
I missing something?

Guillaume

Tom,
it's true that, exynos5-common.h defines the CONFIG_EXTRA_ENV_SETTINGS,
which provides "BOOTENV".
Odroid XU3 redefines CONFIG_EXTRA_ENV_SETTINGS, but in the fact it uses
the same settings, appended by some private env variables.

Guillaume,
You're right, Exynos4 boards doesn't use the generic distro boot
commands. And each board defines CONFIG_EXTRA_ENV_SETTINGS.

All boards works with the mainline kernel by default, so it's not a high
priority for us to switch it to common env, but will do this soon.

You can check the bootscript example in the directory:
board/samsung/common/bootscripts/

As temporary, your patch for Odroid can be applied to support the
boot.scr, but anyway it support mainline kernel and probably can boot
Ubuntu images.

Some mainline release of U-Boot is used for Arch Linux images for Odroid
U3, you can check the changes for ARCH here:

https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/uboot-odroid/0001-arch-linux-arm-modifications.patch

So if you need write custom boot.scr, maybe this will help you.

One more thing, if you need append the bootargs for your kernel, then
you can set the $opts variable which is always appended to bootargs.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 0/2] *Enhance Odroid board


Hello,

On 10/09/2015 02:26 PM, Guillaume GARDET wrote:

Those 2 patches enhances Odroid board support.
* First patch replace 'fatload' command by 'load', to be able to use EXT*
partitions while keeping FAT partition compatibility.
* Second patch adds boot script (boot.scr) support. If no boot script are
found, it boots as usual.

Changes in V3:
* Uses 'elif' version as requested by Przemyslaw Marczak

Changes in V2:
* Expand commit messages
* Better code consistency

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>

---

Guillaume GARDET (2):
   odroid: replace 'fatload' with 'load' to be able to use EXT*
 partitions
   odroid: Add boot script (boot.scr) support

  include/configs/odroid.h | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)



For the series:

Tested-by: Przemyslaw Marczak <p.marc...@samsung.com>
Acked-by: Przemyslaw Marczak <p.marc...@samsung.com>

Thanks!
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] odroid DTB support


Hello,

On 10/13/2015 11:33 AM, Guillaume Gardet wrote:

Hi Przemyslaw, Tom,


Le 13/10/2015 11:11, Przemyslaw Marczak a écrit :

Hi Tom, Guillaume,

On 10/13/2015 09:37 AM, Guillaume Gardet wrote:



Le 12/10/2015 16:24, Tom Rini a écrit :

On Mon, Oct 12, 2015 at 10:54:04AM +0200, Guillaume Gardet wrote:

Hi,


Le 12/10/2015 01:45, Tom Rini a écrit :

On Fri, Oct 09, 2015 at 02:35:24PM +0200, Guillaume Gardet wrote:

Le 09/10/2015 14:23, Przemyslaw Marczak a écrit :

Hello Guillaume,

On 10/09/2015 02:11 PM, Guillaume Gardet wrote:

Hi Przemyslaw,

I would like to add DTB support for odroid board to be able to
boot
upstream kernel easily.

I see 2 ways to do it:
* Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support to set
'board_rev'
and 'board_name' env vars. Then, you need a 'findfdt' script to
check
'board_rev' and set fdtfile accordingly (as done for OMAP4 panda
board)
* Set fdtfile name directly (as done for rpi or igep00x0).

What would you prefer?


Guillaume



Is, that the reason of adding the boot script by your last patches?

No, we need a boot script, because this is the way we boot our
openSUSE images (we boot with an initrd and some special bootargs).

Hang on, exynos stuff uses the generic distro hooks.  Can you take a
look at doc/README.distro and see what openSUSE can hook into /
provide
some feedback on what needs doing?  Thanks!

This is true for odroid XU3 (Exynos5 based) but Odroid U3/X2 (Exynos4
based) has no generic distro hooks at the moment.

No, exynos-common pulls in generic distro.  And in the event of boards
that do not the answer is to pull in the generic distro framework.


It seems that exynos-common includes only "config_distro_defaults.h",
not "config_distro_bootcmd.h".
And "config_distro_bootcmd.h" is needed for generic distro boot flow. Am
I missing something?

Guillaume




Tom,
it's true that, exynos5-common.h defines the
CONFIG_EXTRA_ENV_SETTINGS, which provides "BOOTENV".
Odroid XU3 redefines CONFIG_EXTRA_ENV_SETTINGS, but in the fact it
uses the same settings, appended by some private env variables.

Guillaume,
You're right, Exynos4 boards doesn't use the generic distro boot
commands. And each board defines CONFIG_EXTRA_ENV_SETTINGS.


Thanks for clarification.



All boards works with the mainline kernel by default, so it's not a
high priority for us to switch it to common env, but will do this soon.


ok.



You can check the bootscript example in the directory:
 board/samsung/common/bootscripts/


Here, if $fdtfile is not defined, then it boots without it. This won't
work for us, since we need DTB (kernel multiplatform enabled).



Right, because it supports both fdt and non-fdt kernel images, the 
second one is to support old Hardkernel zImages.


Odroid XU3 defines fdtfile in board config extra envs, but the U3 sets 
it automatically on boot, since it supports both X2 and U3, the name 
depends on the board detection. This part of code is in set_board_info() 
in board/samsung/common/misc.c.


This is working well, if you have a minimum files on the boot partition 
(mmc 0:1):

- zImage
- exynos4412-odroidu3.dtb

then you will see:
---

Hit any key to stop autoboot: 0
reading exynos4412-odroidu3.dtb
46356 bytes read in 415 ms (108.4KiB/s)
reading uInitrd
** Unable to read file uInitrd **
reading zImage
5161952 bytes read in 685 ms (7.2 MiB/s)
Kernel image @ 0x40007fc0 [ 0x00 - 0x4ec3e0]
## Flattened Device Tree blob at 4080
Booting using the fdt blob at 0x4080
Loading Device Tree to 4fff1000, end 4513 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

---

After apply your patches and put the menioned boot.scr I can see this:

---
Hit any key to stop autoboot:0
reading boot.scr
3034 bytes read in 312 ms (8.8 KiB/s)
## Executing script at 4200
Found kernel image: zImage
reading exynos4412-odroidu3.dtb
46356 bytes read in 415 ms (108.4 KiB/s)
Warning! Booting without RAMDISK: uInitrd!
reading zImage
5161952 bytes read in 686 ms (7.2 MiB/s)
Kernel image @ 0x40007fc0 [ 0x00 - 0x4ec3e0 ]
## Flattened Device Tree blob at 4080
 Booting using the fdt blob at 0x4080
 Loading Device Tree to 4fff1000, end 4513 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
---

So this works for my setup. Maybe you have a problem with the filesystem?

Please check it manual if you can load dtb file, if not, maybe you 
should do mkfs.ext4/vfat on your boot partition to clean in, and then 
check again.




As temporary, your patch for Odroid can be applied to support the
boot.scr, but anyway it support mainline kernel and probably can boot
Ubuntu images.


Yes, please apply it to get boot.scr support until odroid switch to

Re: [U-Boot] [PATCH V2 07/11] dm: adc: add Exynos54xx compatible ADC driver


Hello Simon,

On 10/03/2015 04:28 PM, Simon Glass wrote:

Hi Przemyslaw,

On 21 September 2015 at 13:26, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

This commit adds driver for Exynos54xx ADC subsystem.

The driver is implemented using driver model,
amd provides ADC uclass's operations:
- adc_init()
- adc_data()

This driver uses sdelay() function on pooling, so it can
be used before the delay timer is inited.
The basic parameters of ADC conversion, are:
- sample rate: 600KSPS
- output the data as average of 8 time conversion

ADC features:
- sample rate: 600KSPS
- resolution: 12-bit
- channels: 10 (analog multiplexer)

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
---
Changes V2:
- new commit - move previous adc driver from SoC directory to drivers/adc
---
  arch/arm/mach-exynos/include/mach/adc.h |  45 ++
  drivers/adc/Kconfig |   9 +++
  drivers/adc/Makefile|   1 +
  drivers/adc/exynos-adc.c| 102 
  4 files changed, 157 insertions(+)
  create mode 100644 drivers/adc/exynos-adc.c

diff --git a/arch/arm/mach-exynos/include/mach/adc.h 
b/arch/arm/mach-exynos/include/mach/adc.h
index a0e26d7..228acf4 100644
--- a/arch/arm/mach-exynos/include/mach/adc.h
+++ b/arch/arm/mach-exynos/include/mach/adc.h
@@ -9,6 +9,38 @@
  #ifndef __ASM_ARM_ARCH_ADC_H_
  #define __ASM_ARM_ARCH_ADC_H_

+#define ADC_V2_CON1_SOFT_RESET (0x2 << 1)
+#define ADC_V2_CON1_STC_EN (0x1)


No need for brackets on these simple ones



Okay, I will remove them.


+
+#define ADC_V2_CON2_OSEL(x)(((x) & 0x1) << 10)
+#define OSEL_2S(0x0)
+#define OSEL_BINARY(0x1)
+#define ADC_V2_CON2_ESEL(x)(((x) & 0x1) << 9)
+#define ESEL_ADC_EVAL_TIME_40CLK   (0x0)
+#define ESEL_ADC_EVAL_TIME_20CLK   (0x1)
+#define ADC_V2_CON2_HIGHF(x)   (((x) & 0x1) << 8)
+#define HIGHF_CONV_RATE_30KSPS (0x0)
+#define HIGHF_CONV_RATE_600KSPS(0x1)
+#define ADC_V2_CON2_C_TIME(x)  (((x) & 0x7) << 4)
+#define ADC_V2_CON2_CHAN_SEL(x)((x) & 0xf)
+
+#define ADC_V2_GET_STATUS_FLAG(x)  (((x) >> 2) & 0x1)
+#define FLAG_CONV_END  (0x1)
+
+#define ADC_V2_INT_DISABLE (0x0)
+#define ADC_V2_INT_ENABLE  (0x1)
+#define INT_NOT_GENERATED  (0x0)
+#define INT_GENERATED  (0x1)
+
+#define ADC_V2_VERSION (0x8008)
+
+#define ADC_V2_MAX_CHANNEL (9)
+
+/* For default 8 time convertion with sample rate 600 kSPS - 15us timeout */
+#define ADC_V2_CONV_TIMEOUT_US (15)
+
+#define ADC_V2_DAT_MASK(0xfff)
+
  #ifndef __ASSEMBLY__
  struct s5p_adc {
 unsigned int adccon;
@@ -21,6 +53,19 @@ struct s5p_adc {
 unsigned int adcmux;
 unsigned int adcclrintpndnup;
  };
+
+struct exynos_adc_v2 {
+   unsigned int con1;
+   unsigned int con2;
+   unsigned int status;
+   unsigned int dat;
+   unsigned int int_en;
+   unsigned int int_status;
+   unsigned int reserved[2];
+   unsigned int version;
+};
+
+int exynos_adc_read_channel(int channel);
  #endif

  #endif /* __ASM_ARM_ARCH_ADC_H_ */
diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
index 1cb1a8d..8ee6531 100644
--- a/drivers/adc/Kconfig
+++ b/drivers/adc/Kconfig
@@ -6,3 +6,12 @@ config ADC
   - device enable
   - conversion init
   - conversion start and return data with data mask
+
+config ADC_EXYNOS
+   bool "Enable Exynos 54xx ADC driver"
+   help
+ This enables basic driver for Exynos ADC compatible with Exynos54xx.
+ It provides:
+ - 10 analog input channels
+ - 12-bit resolution
+ - 600 KSPS of sample rate


Great help!



Thanks:)


diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
index c4d9618..eb85b8b 100644
--- a/drivers/adc/Makefile
+++ b/drivers/adc/Makefile
@@ -6,3 +6,4 @@
  #

  obj-$(CONFIG_ADC) += adc-uclass.o
+obj-$(CONFIG_ADC_EXYNOS) += exynos-adc.o
diff --git a/drivers/adc/exynos-adc.c b/drivers/adc/exynos-adc.c
new file mode 100644
index 000..fdffea0
--- /dev/null
+++ b/drivers/adc/exynos-adc.c
@@ -0,0 +1,102 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics
+ * Przemyslaw Marczak <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct exynos_adc_priv {
+   struct exynos_adc_v2 *regs;
+};
+
+extern void sdelay(unsigned long loops);


Can you put this include system.h for exynos, or similar? Also, I
think the problem is that timer_init() is called after initf_dm().
There is a patch to add timer support to driver model so perhaps that
will help?



Ok, will move this. And yes, the problem is with too late timer init.

Re: [U-Boot] [PATCH V2 11/11] exynos5-dt-types: add board detection for Odroid XU3/XU3L/XU4.


Hello Simon,

On 10/03/2015 04:28 PM, Simon Glass wrote:

Hi Przemyslaw,

On 21 September 2015 at 13:26, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

This commit adds additional file with implementation of board
detection code for Odroid-XU3/XU4.

The detection depends on compatible found in fdt:
- "samsung,exynos5" - uses Exynos5 generic code
- "samsung,odroidxu3" - try detect XU3 revision

There are few revisions of Odroid XU3/XU4, each can be detected
by checking the value of channel 9 of built-in ADC:
  Rev   ADC  Board
  0.1 0  XU3 0.1
  0.2   372  XU3 0.2 | XU3L - no DISPLAYPORT
  0.3  1280  XU4 0.1

The detection code depends on the ADC+10% value.

Implementation of functions:
- set_board_type() - read ADC and set type
- get_board_rev()  - returns board revision: 1..3
- get_board_type() - returns board type string

Additional functions with return values of bool:
- board_is_generic()   - true if found compatible "samsung,exynos5"
  but not "samsung,odroidxu3"
- board_is_odroidxu3() - true if found compatible "samsung,odroidxu3"
  and one of XU3 revision.
- board_is_odroidxu4() - true if found compatible "samsung,odroidxu3"
  and XU4 revision.

After I2C controller init, the get_board_type() can check
if the XU3 board is a "Lite" variant, by probing chip
0x40 on I2C0 (INA231 - exists only on non-lite).
This is useful for setting fdt file name at misc_init_r().

Enabled configs:
- CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
- CONFIG_ODROID_REV_AIN
- CONFIG_REVISION_TAG
- CONFIG_BOARD_TYPES

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
---
Changes V2:
- move detection code from exynos5-dt.c to exynos5-dt-types.c
- add header with board type function declarations
- check for compatible before do the detection
- update the ADC max values with 20% tolerance
- fix XU4 adc value, related to mistake from table in XU4 schematic
- return "Not supported" for XU4 when calls one of:
   --dfu_get_alt_boot()
   --dfu_get_alt_system()
- extend ${dfu_alt_system} by strings:
   -- 'exynos5422-odroidxu3-lite.dtb'
   -- 'exynos5422-odroidxu4.dtb' - allows prepare card on XU3
---
  board/samsung/common/Makefile   |   5 +-
  board/samsung/common/exynos5-dt-types.c | 196 
  board/samsung/common/exynos5-dt.c   |  12 ++
  configs/odroid-xu3_defconfig|   2 +
  include/configs/odroid_xu3.h|  12 ++
  include/samsung/exynos5-dt-types.h  |  27 +
  6 files changed, 253 insertions(+), 1 deletion(-)
  create mode 100644 board/samsung/common/exynos5-dt-types.c
  create mode 100644 include/samsung/exynos5-dt-types.h


Reviewed-by: Simon Glass <s...@chromium.org>

See nits below.



Ok.



diff --git a/board/samsung/common/Makefile b/board/samsung/common/Makefile
index 6cbd906..ef1a8f3 100644
--- a/board/samsung/common/Makefile
+++ b/board/samsung/common/Makefile
@@ -11,5 +11,8 @@ obj-$(CONFIG_MISC_COMMON) += misc.o

  ifndef CONFIG_SPL_BUILD
  obj-$(CONFIG_BOARD_COMMON) += board.o
-obj-$(CONFIG_EXYNOS5_DT)   += exynos5-dt.o
+ifdef CONFIG_EXYNOS5_DT
+obj-y += exynos5-dt.o
+obj-$(CONFIG_BOARD_TYPES) += exynos5-dt-types.o
+endif
  endif
diff --git a/board/samsung/common/exynos5-dt-types.c 
b/board/samsung/common/exynos5-dt-types.c
new file mode 100644
index 000..1364e98
--- /dev/null
+++ b/board/samsung/common/exynos5-dt-types.c
@@ -0,0 +1,196 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics
+ * Przemyslaw Marczak <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static const struct udevice_id board_ids[] = {
+   { .compatible = "samsung,odroidxu3", .data = EXYNOS5_BOARD_ODROID_XU3 },
+   { .compatible = "samsung,exynos5", .data = EXYNOS5_BOARD_GENERIC },
+   { },
+};
+
+/**
+ * Odroix XU3/4 board revisions:
+ * Rev   ADCmax  Board
+ * 0.1 0 XU3 0.1
+ * 0.2   410 XU3 0.2 | XU3L - no DISPLAYPORT (probe I2C0:0x40 / INA231)
+ * 0.3  1408 XU4 0.1
+ * Use +10 % for ADC value tolerance.
+ */
+struct odroid_rev_info odroid_info[] = {
+   { EXYNOS5_BOARD_ODROID_XU3_REV01, 1, 10, "xu3" },
+   { EXYNOS5_BOARD_ODROID_XU3_REV02, 2, 410, "xu3" },
+   { EXYNOS5_BOARD_ODROID_XU4_REV01, 1, 1408, "xu4" },
+   { EXYNOS5_BOARD_ODROID_UNKNOWN, 0, 4095, "unknown" },
+};
+
+static unsigned int odroid_get_rev(void)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(odroid_info); i++) {
+   if (odroid_info[i].board_type == gd->board_type)
+   return odroid_info[i].board_rev;
+   }
+
+   return 0;
+}
+
+static int odroid_get_board_type(void)
+{
+

Re: [U-Boot] [PATCH V2 00/11] Add board detection for Odroid XU3 / XU3Lite / XU4


Hello,

On 10/03/2015 04:30 PM, Simon Glass wrote:

Hi Przemyslaw,

On 1 October 2015 at 12:07, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

Hello,


On 09/21/2015 02:26 PM, Przemyslaw Marczak wrote:


This patchset adds:
- CPU model in dts for Chromebook Peach Pi as Exynos5800
- set the cpu id of Exynos5422 to 0x5422
- S2MPS11 PMIC I/O driver
- Exynos5420-compatible (9-channel, 12-bit) ADC driver
- new file for Exynos5: exynos5-dt-types.c
- board detection for Odroid XU3 / XU3lite / XU4
- fixed ADC val for XU4

This was tested on Odroid XU3 and XU3 Lite, without the XU4,
but I'm waiting for reply from the Odroid forum users.

Tested with buildman for samsung.

Available on github:
https://github.com/bobenstein/u-boot/tree/xu3-detect-patchset-v1
https://github.com/bobenstein/u-boot/tree/xu3-detect-patchset-v2

Przemyslaw Marczak (11):
samsung: board/misc: check returned pointer for get_board_type() calls
s5p: cpu_info: print "cpu-model" if exists in dts
Peach-Pi: dts: add cpu-model string
Exynos5422/5800: set cpu id to 0x5422
dm: pmic: add s2mps11 PMIC I/O driver
dm: adc: add simple ADC uclass implementation
dm: adc: add Exynos54xx compatible ADC driver
Odroid-XU3: enable s2mps11 PMIC support
Exynos54xx: dts: add ADC node
Odroid-XU3: dts: enable ADC, with request for pre-reloc bind
exynos5-dt-types: add board detection for Odroid XU3/XU3L/XU4.

   arch/arm/cpu/armv7/s5p-common/cpu_info.c  |  14 ++-
   arch/arm/dts/exynos5422-odroidxu3.dts |  12 ++
   arch/arm/dts/exynos54xx.dtsi  |   7 ++
   arch/arm/dts/exynos5800-peach-pi.dts  |   1 +
   arch/arm/mach-exynos/clock.c  |  16 +--
   arch/arm/mach-exynos/clock_init_exynos5.c |   2 +-
   arch/arm/mach-exynos/common_setup.h   |   4 +-
   arch/arm/mach-exynos/include/mach/adc.h   |  45 +++
   arch/arm/mach-exynos/include/mach/cpu.h   |   6 +-
   arch/arm/mach-exynos/include/mach/gpio.h  |   4 +-
   arch/arm/mach-exynos/pinmux.c |   2 +-
   arch/arm/mach-exynos/power.c  |   2 +-
   board/samsung/common/Makefile |   5 +-
   board/samsung/common/board.c  |   4 +-
   board/samsung/common/exynos5-dt-types.c   | 196
++
   board/samsung/common/exynos5-dt.c |  12 ++
   board/samsung/common/misc.c   |   3 +
   configs/odroid-xu3_defconfig  |   5 +
   doc/device-tree-bindings/pmic/s2mps11.txt |  17 +++
   drivers/Kconfig   |   2 +
   drivers/Makefile  |   1 +
   drivers/adc/Kconfig   |  17 +++
   drivers/adc/Makefile  |   9 ++
   drivers/adc/adc-uclass.c  |  76 
   drivers/adc/exynos-adc.c  | 102 
   drivers/power/pmic/Kconfig|  14 +++
   drivers/power/pmic/Makefile   |   1 +
   drivers/power/pmic/s2mps11.c  |  60 +
   include/adc.h |  88 ++
   include/configs/odroid_xu3.h  |  12 ++
   include/dm/uclass-id.h|   1 +
   include/power/s2mps11.h   | 109 +
   include/samsung/exynos5-dt-types.h|  27 
   33 files changed, 854 insertions(+), 22 deletions(-)
   create mode 100644 board/samsung/common/exynos5-dt-types.c
   create mode 100644 doc/device-tree-bindings/pmic/s2mps11.txt
   create mode 100644 drivers/adc/Kconfig
   create mode 100644 drivers/adc/Makefile
   create mode 100644 drivers/adc/adc-uclass.c
   create mode 100644 drivers/adc/exynos-adc.c
   create mode 100644 drivers/power/pmic/s2mps11.c
   create mode 100644 include/adc.h
   create mode 100644 include/power/s2mps11.h
   create mode 100644 include/samsung/exynos5-dt-types.h



Simon,
Are you going to to review this patchset or can I update it and ask Minkyu
for taking it?


I thought Minkyu would take it as it seems to be exynos-specific.

Regards,
Simon



Ok. I will prepare the V3 and notify you.

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 03/11] Peach-Pi: dts: add cpu-model string


Hello Simon,

On 10/03/2015 04:28 PM, Simon Glass wrote:

Hi Przemyslaw,

On 21 September 2015 at 13:26, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

This platform is based on Exynos5800 but the cpu id is 0x5422.
This doesn't fit the common Exynos SoC name convention, so now,
the CPU name is defined by device tree string, to be printed
properly.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
---
Changes V2:
- move cpu name from config to dts
---
  arch/arm/dts/exynos5800-peach-pi.dts | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/exynos5800-peach-pi.dts 
b/arch/arm/dts/exynos5800-peach-pi.dts
index 1d7ff23..76826dc 100644
--- a/arch/arm/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/dts/exynos5800-peach-pi.dts
@@ -12,6 +12,7 @@

  / {
 model = "Samsung/Google Peach Pi board based on Exynos5800";
+   cpu-model = "Exynos5800";

 compatible = "google,pit-rev#", "google,pit",
 "google,peach", "samsung,exynos5800", "samsung,exynos5";
--
1.9.1



Is this defined by the standard binding? If not, can you add or change
the binding file?

Regards,
Simon



No, it's not standard. I will add binding info.

Best regards
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 06/11] dm: adc: add simple ADC uclass implementation


Hello Simon,

On 10/03/2015 04:28 PM, Simon Glass wrote:

Hi Przemyslaw,

On 21 September 2015 at 13:26, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

This commit adds:
- new uclass id: UCLASS_ADC
- new uclass driver: drivers/adc/adc-uclass.c

The uclass's implementation is as simple as needed and provides functions:
- adc_init() - init ADC conversion
- adc_data() - convert and return data
- adc_data_mask() - return ADC data mask
- adc_channel_single_shot() - function for single ADC convertion

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
---
Changes V2:
- new commit - introduce ADC uclass driver
---
  drivers/Kconfig  |  2 ++
  drivers/Makefile |  1 +
  drivers/adc/Kconfig  |  8 +
  drivers/adc/Makefile |  8 +
  drivers/adc/adc-uclass.c | 76 +
  include/adc.h| 88 
  include/dm/uclass-id.h   |  1 +
  7 files changed, 184 insertions(+)
  create mode 100644 drivers/adc/Kconfig
  create mode 100644 drivers/adc/Makefile
  create mode 100644 drivers/adc/adc-uclass.c
  create mode 100644 include/adc.h


Sorry I have quite a lot of questions and comments on this.



Yes, ok.



diff --git a/drivers/Kconfig b/drivers/Kconfig
index 63c92c5..ad9ae3a 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -4,6 +4,8 @@ source "drivers/core/Kconfig"

  # types of drivers sorted in alphabetical order

+source "drivers/adc/Kconfig"
+
  source "drivers/block/Kconfig"

  source "drivers/clk/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 9d0a595..d7d5e9f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_SPL_SATA_SUPPORT) += block/

  else

+obj-y += adc/
  obj-$(CONFIG_DM_DEMO) += demo/
  obj-$(CONFIG_BIOSEMU) += bios_emulator/
  obj-y += block/
diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig
new file mode 100644
index 000..1cb1a8d
--- /dev/null
+++ b/drivers/adc/Kconfig
@@ -0,0 +1,8 @@
+config ADC
+   bool "Enable ADC drivers using Driver Model"
+   help
+ This allows drivers to be provided for ADCs to drive their features,
+ trough simple ADC uclass driver interface, with operations:


through a simple



Ok.


+ - device enable
+ - conversion init
+ - conversion start and return data with data mask
diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile
new file mode 100644
index 000..c4d9618
--- /dev/null
+++ b/drivers/adc/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (C) 2015 Samsung Electronics
+# Przemyslaw Marczak <p.marc...@samsung.com>
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-$(CONFIG_ADC) += adc-uclass.o
diff --git a/drivers/adc/adc-uclass.c b/drivers/adc/adc-uclass.c
new file mode 100644
index 000..bb71b6e
--- /dev/null
+++ b/drivers/adc/adc-uclass.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2015 Samsung Electronics
+ * Przemyslaw Marczak <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ADC_UCLASS_PLATDATA_SIZE   sizeof(struct adc_uclass_platdata)


Can we drop #define?



Don't you think, that single line initialization looks better than those 
with line breaks? This is the purpose of that define.



+
+int adc_init(struct udevice *dev, int channel)
+{
+   const struct adc_ops *ops = dev_get_driver_ops(dev);
+
+   if (ops->adc_init)
+   return ops->adc_init(dev, channel);
+
+   return -ENOSYS;


Let's turn each of these around so that errors are the exception, not
the normal path.

if (!ops->adc_init)
return -ENOSYS;

return ops->...



Ok, I will turn it.


+}
+
+int adc_data(struct udevice *dev, unsigned int *data)
+{
+   const struct adc_ops *ops = dev_get_driver_ops(dev);
+
+   *data = 0;
+
+   if (ops->adc_data)
+   return ops->adc_data(dev, data);
+
+   return -ENOSYS;
+}
+
+int adc_data_mask(struct udevice *dev)
+{
+   struct adc_uclass_platdata *uc_pdata = dev_get_uclass_platdata(dev);
+
+   if (uc_pdata)
+   return uc_pdata->data_mask;
+
+   return -ENOSYS;
+}
+
+int adc_channel_single_shot(const char *name, int channel, unsigned int *data)
+{
+   struct udevice *dev;
+   int ret;
+
+   *data = 0;


I don't think we need this assignment. This can be undefined if an
error is returned.



Ok.


+
+   ret = uclass_get_device_by_name(UCLASS_ADC, name, );
+   if (ret)
+   return ret;
+
+   ret = adc_init(dev, channel);
+   if (ret)
+   return ret;
+
+   ret = adc_data(dev, data);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+UCLASS_DRIVER(adc) = {
+   .id = UCLASS_ADC,
+   .name   = "adc",
+   .per_device_platdata_auto_alloc_size = ADC_UCLASS_

Re: [U-Boot] [PATCH V2 05/11] dm: pmic: add s2mps11 PMIC I/O driver


Hi Simon,

On 10/03/2015 04:28 PM, Simon Glass wrote:

Hi Przemyslaw,

On 21 September 2015 at 13:26, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

This driver allows I/O operations on the Samsung S2MPS11 PMIC,
which provides lots of LDO/BUCK outputs.

To enable it, update defconfig with:
- CONFIG_PMIC_S2MPS11
and additional, if were not defined:
- CONFIG_CMD_PMIC
- CONFIG_ERRNO_STR

The binding info: doc/device-tree-bindings/pmic/s2mps11.txt

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
---
Changes V2:
- remove "DM" prefix from config name
- fix word mistake in binding description
---
  doc/device-tree-bindings/pmic/s2mps11.txt |  17 +
  drivers/power/pmic/Kconfig|  14 
  drivers/power/pmic/Makefile   |   1 +
  drivers/power/pmic/s2mps11.c  |  60 
  include/power/s2mps11.h   | 109 ++
  5 files changed, 201 insertions(+)
  create mode 100644 doc/device-tree-bindings/pmic/s2mps11.txt
  create mode 100644 drivers/power/pmic/s2mps11.c
  create mode 100644 include/power/s2mps11.h


Reviewed-by: Simon Glass <s...@chromium.org>

But please see nit below.



diff --git a/doc/device-tree-bindings/pmic/s2mps11.txt 
b/doc/device-tree-bindings/pmic/s2mps11.txt
new file mode 100644
index 000..422f14f
--- /dev/null
+++ b/doc/device-tree-bindings/pmic/s2mps11.txt
@@ -0,0 +1,17 @@
+SAMSUNG, S2MPS11 PMIC
+
+This file describes the binding info for the PMIC driver:
+- drivers/power/pmic/s2mps11.c
+
+Required properties:
+- compatible: "samsung,s2mps11-pmic"
+- reg = 0x66
+
+With those two properties, the pmic device can be used for read/write only.
+
+Example:
+
+s2mps11@66 {
+   compatible = "samsung,s2mps11-pmic";
+   reg = <0x66>;
+};
diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
index 547fd1a..fb29843 100644
--- a/drivers/power/pmic/Kconfig
+++ b/drivers/power/pmic/Kconfig
@@ -33,6 +33,20 @@ config DM_PMIC_MAX77686
 This config enables implementation of driver-model pmic uclass features
 for PMIC MAX77686. The driver implements read/write operations.

+config PMIC_S2MPS11
+   bool "Enable Driver Model for PMIC Samsung S2MPS11"
+   depends on DM_PMIC
+   ---help---
+   The Samsung S2MPS11 PMIC provides:
+- 38 adjustable LDO regulators
+- 9 High-Efficiency Buck Converters
+- 1 BuckBoost Converter
+- RTC with two alarms
+- Backup battery charger
+- I2C Configuration Interface
+   This driver provides access to I/O interface only.
+   Binding info: doc/device-tree-bindings/pmic/s2mps11.txt
+
  config DM_PMIC_SANDBOX
 bool "Enable Driver Model for emulated Sandbox PMIC "
 depends on DM_PMIC
diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
index 00fde71..91e78f8 100644
--- a/drivers/power/pmic/Makefile
+++ b/drivers/power/pmic/Makefile
@@ -8,6 +8,7 @@
  obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
  obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
  obj-$(CONFIG_DM_PMIC_PFUZE100) += pfuze100.o
+obj-$(CONFIG_PMIC_S2MPS11) += s2mps11.o
  obj-$(CONFIG_DM_PMIC_SANDBOX) += sandbox.o i2c_pmic_emul.o
  obj-$(CONFIG_PMIC_ACT8846) += act8846.o
  obj-$(CONFIG_PMIC_TPS65090) += tps65090.o
diff --git a/drivers/power/pmic/s2mps11.c b/drivers/power/pmic/s2mps11.c
new file mode 100644
index 000..7e28402
--- /dev/null
+++ b/drivers/power/pmic/s2mps11.c
@@ -0,0 +1,60 @@
+/*
+ *  Copyright (C) 2015 Samsung Electronics
+ *  Przemyslaw Marczak  <p.marc...@samsung.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static int s2mps11_reg_count(struct udevice *dev)
+{
+   return S2MPS11_REG_COUNT;
+}
+
+static int s2mps11_write(struct udevice *dev, uint reg, const uint8_t *buff,
+int len)
+{
+   if (dm_i2c_write(dev, reg, buff, len)) {
+   error("write error to device: %p register: %#x!", dev, reg);
+   return -EIO;


Should return the value of dm_i2c_write(). Also below.



Right, will fix.


+   }
+
+   return 0;
+}
+
+static int s2mps11_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
+{
+   if (dm_i2c_read(dev, reg, buff, len)) {
+   error("read error from device: %p register: %#x!", dev, reg);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static struct dm_pmic_ops s2mps11_ops = {
+   .reg_count = s2mps11_reg_count,
+   .read = s2mps11_read,
+   .write = s2mps11_write,
+};
+
+static const struct udevice_id s2mps11_ids[] = {
+   { .compatible = "samsung,s2mps11-pmic" },
+   { }
+};
+
+U_BOOT_DRIVER(pmic_s2mps11) = {
+   .name = "s2mps11_pmic",
+   .id = UCLASS_PMIC,
+   .of_match = s2mps11_ids,
+

Re: [U-Boot] [PATCH V2 02/11] s5p: cpu_info: print "cpu-model" if exists in dts


Hello Simon,

On 10/03/2015 04:27 PM, Simon Glass wrote:

On 21 September 2015 at 13:26, Przemyslaw Marczak <p.marc...@samsung.com> wrote:

The CPU name for Exynos was concatenated with cpu id,
but for new Exynos platforms, like Chromebook Peach Pi
based on Exynos5800, the name of SoC variant does not
include the real SoC cpu id (0x5422).

For such case, the CPU name should be defined in device tree.

This commit introduces new device-tree property for Exynos:
- "cpu-model" - with cpu name string
If defined, then the cpu id is not printed.

Signed-off-by: Przemyslaw Marczak <p.marc...@samsung.com>
---
Changes V2:
- new commit
---
  arch/arm/cpu/armv7/s5p-common/cpu_info.c | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)



Reviewed-by: Simon Glass <s...@chromium.org>

Please see nit below.


diff --git a/arch/arm/cpu/armv7/s5p-common/cpu_info.c 
b/arch/arm/cpu/armv7/s5p-common/cpu_info.c
index 154d674..97d611f 100644
--- a/arch/arm/cpu/armv7/s5p-common/cpu_info.c
+++ b/arch/arm/cpu/armv7/s5p-common/cpu_info.c
@@ -5,9 +5,12 @@
   * SPDX-License-Identifier:GPL-2.0+
   */
  #include 
+#include 
  #include 
  #include 

+DECLARE_GLOBAL_DATA_PTR;
+
  /* Default is s5pc100 */
  unsigned int s5p_cpu_id = 0xC100;
  /* Default is EVT1 */
@@ -30,7 +33,16 @@ u32 get_device_type(void)
  #ifdef CONFIG_DISPLAY_CPUINFO
  int print_cpuinfo(void)
  {
-   printf("CPU:   %s%X @ ", s5p_get_cpu_name(), s5p_cpu_id);
+   const char *cpu_model = NULL;
+   int len = 0;


No need to init these two variables.



Ok, will correct this.


+
+   /* For SoC with no real CPU ID in naming convention. */
+   cpu_model = fdt_getprop(gd->fdt_blob, 0, "cpu-model", );
+   if (cpu_model)
+   printf("CPU:   %.*s @ ", len, cpu_model);
+   else
+   printf("CPU:   %s%X @ ", s5p_get_cpu_name(), s5p_cpu_id);
+
 print_freq(get_arm_clk(), "\n");

 return 0;
--
1.9.1





Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] odroid DTB support

2015-10-12 Thread Przemyslaw Marczak


Hello,

On 10/12/2015 10:54 AM, Guillaume Gardet wrote:

Hi,


Le 12/10/2015 01:45, Tom Rini a écrit :

On Fri, Oct 09, 2015 at 02:35:24PM +0200, Guillaume Gardet wrote:


Le 09/10/2015 14:23, Przemyslaw Marczak a écrit :

Hello Guillaume,

On 10/09/2015 02:11 PM, Guillaume Gardet wrote:

Hi Przemyslaw,

I would like to add DTB support for odroid board to be able to boot
upstream kernel easily.

I see 2 ways to do it:
* Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support to set 'board_rev'
and 'board_name' env vars. Then, you need a 'findfdt' script to check
'board_rev' and set fdtfile accordingly (as done for OMAP4 panda
board)
* Set fdtfile name directly (as done for rpi or igep00x0).

What would you prefer?


Guillaume



Is, that the reason of adding the boot script by your last patches?

No, we need a boot script, because this is the way we boot our
openSUSE images (we boot with an initrd and some special bootargs).

Hang on, exynos stuff uses the generic distro hooks.  Can you take a
look at doc/README.distro and see what openSUSE can hook into / provide
some feedback on what needs doing?  Thanks!


This is true for odroid XU3 (Exynos5 based) but Odroid U3/X2 (Exynos4
based) has no generic distro hooks at the moment.

What we need:
* Boot on boot.scr (mainly to define kernel name, initrd name and bootargs)


If you need some more, than the above, then using boot.scr is required, 
but if not, then U-Boot provides this all at default.



* Use (pre-defined) fdtfile, or be able to define it manually if not
already set (or not in sync with Linux kernel)


Guillaume





For odroid_defconfig, the basic things are done automatically.

The variables:
- $fdtfile
- $boardname
are set automatically and are consistent with the mainline kernel file 
names, so for U3 the fdtfile is set as "exynos4412-odroidu3.dtb".
If you have u/zImage and fdtfile on the first partition(boot), then it 
just boot with defaults.

If you need some more features, then you can use multi config itb format.

The initrd is also loaded automatically.

All images must be stored on $boot partition

Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 2/2] odroid: Add boot script (boot.scr) support


Hi Sjoerd,

On 10/05/2015 11:13 AM, Sjoerd Simons wrote:

On Mon, 2015-10-05 at 11:07 +0200, Guillaume GARDET wrote:

Add boot script (boot.scr) support. If no boot script are
found, it boots as usual.


Instead of extending the specialized boot script, it would belovely to
see the odroid board switch to distro boot commands for a more
standardized boot sequence.

For reference, if you need an example how to add that while staying
backwards compatible see my patchset for am335x boards which did
something like that:

http://lists.denx.de/pipermail/u-boot/2015-August/225656.html



You're right. I will move it some day as it is in XU3, but for now I 
have some other things to do, so I prefer accept this patch. It's only 
few lines.



Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>

---
  include/configs/odroid.h | 9 +
  1 file changed, 9 insertions(+)

diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index e45b00e..f79847b 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -108,6 +108,8 @@
   * 2.  ROOT:  -
  */
  #define CONFIG_EXTRA_ENV_SETTINGS \
+   "loadbootscript=load mmc ${mmcbootdev}:${mmcbootpart}
${scriptaddr} " \
+   "boot.scr\0" \
"loadkernel=load mmc ${mmcbootdev}:${mmcbootpart}
${kerneladdr} " \
"${kernelname}\0" \
"loadinitrd=load mmc ${mmcbootdev}:${mmcbootpart}
${initrdaddr} " \
@@ -129,6 +131,9 @@
"kernel_args=" \
"setenv bootargs
root=/dev/mmcblk${mmcrootdev}p${mmcrootpart}" \
" rootwait ${console} ${opts}\0" \
+   "boot_script=" \
+   "run loadbootscript;" \
+   "source ${scriptaddr}\0" \
"boot_fit=" \
"setenv kerneladdr 0x4200;" \
"setenv kernelname Image.itb;" \
@@ -152,6 +157,9 @@
"run kernel_args;" \
"bootz ${kerneladdr} ${initrd_addr} ${fdt_addr};\0"
\
"autoboot=" \
+   "if test -e mmc 0 boot.scr; then; " \
+   "run boot_script; " \
+   "fi; " \
"if test -e mmc 0 Image.itb; then; " \
"run boot_fit;" \
"elif test -e mmc 0 zImage; then; " \
@@ -171,6 +179,7 @@
"consoleoff=set console console=ram; save; reset\0" \
"initrdname=uInitrd\0" \
"initrdaddr=4200\0" \
+   "scriptaddr=0x4200\0" \
"fdtaddr=4080\0"

  /* I2C */




Best regards,
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 2/2] odroid: Add boot script (boot.scr) support


Hello Guillaume,

On 10/05/2015 11:07 AM, Guillaume GARDET wrote:

Add boot script (boot.scr) support. If no boot script are
found, it boots as usual.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>

---
  include/configs/odroid.h | 9 +
  1 file changed, 9 insertions(+)

diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index e45b00e..f79847b 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -108,6 +108,8 @@
   * 2.  ROOT:  -
  */
  #define CONFIG_EXTRA_ENV_SETTINGS \
+   "loadbootscript=load mmc ${mmcbootdev}:${mmcbootpart} ${scriptaddr} " \
+   "boot.scr\0" \
"loadkernel=load mmc ${mmcbootdev}:${mmcbootpart} ${kerneladdr} " \
"${kernelname}\0" \
"loadinitrd=load mmc ${mmcbootdev}:${mmcbootpart} ${initrdaddr} " \
@@ -129,6 +131,9 @@
"kernel_args=" \
"setenv bootargs root=/dev/mmcblk${mmcrootdev}p${mmcrootpart}" \
" rootwait ${console} ${opts}\0" \
+   "boot_script=" \
+   "run loadbootscript;" \
+   "source ${scriptaddr}\0" \
"boot_fit=" \
"setenv kerneladdr 0x4200;" \
"setenv kernelname Image.itb;" \
@@ -152,6 +157,9 @@
"run kernel_args;" \
"bootz ${kerneladdr} ${initrd_addr} ${fdt_addr};\0" \
"autoboot=" \
+   "if test -e mmc 0 boot.scr; then; " \
+   "run boot_script; " \
+   "fi; " \


Why you not use "elif"?  Last time I gave you the correct version:

"if test -e mmc 0 boot.scr; then; " \
"run bootscript; " \
"elif test -e mmc 0 Image.itb; then; " \


"if test -e mmc 0 Image.itb; then; " \
"run boot_fit;" \
"elif test -e mmc 0 zImage; then; " \
@@ -171,6 +179,7 @@
"consoleoff=set console console=ram; save; reset\0" \
"initrdname=uInitrd\0" \
"initrdaddr=4200\0" \
+   "scriptaddr=0x4200\0" \
"fdtaddr=4080\0"

  /* I2C */



Best regards
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 2/2] odroid: Add boot script (boot.scr) support


Hello,

On 10/09/2015 01:59 PM, Guillaume Gardet wrote:



Le 09/10/2015 12:24, Przemyslaw Marczak a écrit :

Hello Guillaume,

On 10/05/2015 11:07 AM, Guillaume GARDET wrote:

Add boot script (boot.scr) support. If no boot script are
found, it boots as usual.

Signed-off-by: Guillaume GARDET <guillaume.gar...@free.fr>
Cc: Przemyslaw Marczak <p.marc...@samsung.com>
Cc: Minkyu Kang <mk7.k...@samsung.com>

---
  include/configs/odroid.h | 9 +
  1 file changed, 9 insertions(+)

diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index e45b00e..f79847b 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -108,6 +108,8 @@
   * 2.  ROOT:  -
  */
  #define CONFIG_EXTRA_ENV_SETTINGS \
+"loadbootscript=load mmc ${mmcbootdev}:${mmcbootpart}
${scriptaddr} " \
+"boot.scr\0" \
  "loadkernel=load mmc ${mmcbootdev}:${mmcbootpart} ${kerneladdr}
" \
  "${kernelname}\0" \
  "loadinitrd=load mmc ${mmcbootdev}:${mmcbootpart} ${initrdaddr}
" \
@@ -129,6 +131,9 @@
  "kernel_args=" \
  "setenv bootargs
root=/dev/mmcblk${mmcrootdev}p${mmcrootpart}" \
  " rootwait ${console} ${opts}\0" \
+"boot_script=" \
+"run loadbootscript;" \
+"source ${scriptaddr}\0" \
  "boot_fit=" \
  "setenv kerneladdr 0x4200;" \
  "setenv kernelname Image.itb;" \
@@ -152,6 +157,9 @@
  "run kernel_args;" \
  "bootz ${kerneladdr} ${initrd_addr} ${fdt_addr};\0" \
  "autoboot=" \
+"if test -e mmc 0 boot.scr; then; " \
+"run boot_script; " \
+"fi; " \


Why you not use "elif"?  Last time I gave you the correct version:

"if test -e mmc 0 boot.scr; then; " \
"run bootscript; " \
"elif test -e mmc 0 Image.itb; then; " \


Because, if boot script fails, then it allows to try to boot kernel
directly.
If you prefer the 'elif' version, I am fine with it.


I think, that only one boot path should be chosen at each boot.
Even if boot script will fail, it means, that the boot path was found, 
and loading uImage directly is not preferred - since maybe something can 
be missing then.


If user wants boot from script, then he puts it to disk, if not then he 
can choose one of supported image type, but not all at a time.




If 'elif' version is preferred, would you be ok to modify it directly
(faster) or would you like a V3?


Guillaume



I suggested that version to you in last review. I would like to apply 
locally the patch and test, if can compile with no error/warning, make 
test of run the board and test of booting the kernel. And after positive 
test sequence, your patch will be acked, and then can be taken by Minkyu.


So yes, please send the correct version.







  "if test -e mmc 0 Image.itb; then; " \
  "run boot_fit;" \
  "elif test -e mmc 0 zImage; then; " \
@@ -171,6 +179,7 @@
  "consoleoff=set console console=ram; save; reset\0" \
  "initrdname=uInitrd\0" \
  "initrdaddr=4200\0" \
+"scriptaddr=0x4200\0" \
  "fdtaddr=4080\0"

  /* I2C */



Best regards





Best regards
--
Przemyslaw Marczak
Samsung R Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] odroid DTB support