Re: [RFC] commands: i2c_write: enable raw write to address

2018-02-15 Thread Sascha Hauer 
On Wed, Feb 14, 2018 at 09:19:06AM +0300, Antony Pavlov wrote:
> On Tue, 13 Feb 2018 09:19:43 +0100
> Sascha Hauer  wrote:
> 
> > On Fri, Feb 09, 2018 at 02:22:24PM +0300, Antony Pavlov wrote:
> > > On Fri, 9 Feb 2018 09:36:36 +0100
> > > Sascha Hauer  wrote:
> > > 
> > > > Hi Antony,
> > > > 
> > > > On Thu, Feb 08, 2018 at 10:48:56AM +0300, Antony Pavlov wrote:
> > > > > Sometimes for communication with a simple I2C devices
> > > > > (e.g. PCF8574 or TM1650) it's necessary to send only
> > > > > one data byte into the I2C device.
> > > > > Current i2c_write command makes this impossible because
> > > > > you can't just pass 'device address' and 'register number'
> > > > > (or 'device address' and 'one data byte') to the command.
> > > > > You always have to pass all three parameters:
> > > > > 'device address', 'register number' and 'data'.
> > > > > 
> > > > > This commit fixes the problem.
> > > > > 
> > > > > Sample usage:
> > > > > 
> > > > >   barebox@barebox sandbox:/ i2c_write -a 0x24 0x01
> > > > > 
> > > > > Signed-off-by: Antony Pavlov 
> > > > > ---
> > > > >  commands/i2c.c | 8 ++--
> > > > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > > > 
> > > > Looks good to me.
> > > > 
> > > > I applied this one despite the [RFC] tag. If for some reason you want to
> > > > resend this, feel free to do so, but otherwise consider this applied.
> > > 
> > > Thanks!
> > > 
> > > The patch is short, it's understandable and it fixes the problem.
> > > I prefere to apply this patch as is.
> > > 
> > > I see some inconsistency in drivers/i2c/i2c.c.
> > > We have i2c_master_send() and i2c_write_reg() functions.
> > > These functions are intended to make similar work but they are
> > > written in very different style. I suppose that we can rewrite
> > > i2c_master_send() (e.g. drop FIXME) and make i2c_write_reg()
> > > work on top of i2c_master_send(). Any comments?
> > 
> > Rewrite i2c_master_send()? Do you mean rewrite i2c_write_reg() instead?
> 
> You are right, of course I propose rewrite i2c_write_reg() (there is no
> FIXME comment inside i2c_master_send()).

Ok, that should work I think. Feel free to propose a patch.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: barebox for a ti am335x based board

2018-02-15 Thread Sascha Hauer 
Hi Giorgio,

On Tue, Feb 13, 2018 at 11:12:54PM +0100, Giorgio Dal Molin wrote:
> Hi all,
> 
> I'm trying to add board code for an am335x based HW project.
> I had a look at similar boards like 'boards/phytec-som-am335x'
> or 'boards/beaglebone'.
> I understand that I need two images: the (little) MLO and the
> (bigger) barebox.
> 
> What it's not really clear is how the MLO loads and starts the
> barebox.

See arch/arm/mach-omap/xload.c. It is compiled when no shell is enabled
(I think at least for clarity there should be a separate Kconfig
symbol). In this file omap_xload() detects where the SoC has booted from
and loads the full barebox from the same source.

> 
> Moreover I saw there's always a call to:
> 
>  am33xx_save_bootinfo((void *)bootinfo);
> 
> in the MLO lowlevel entry function; I suspect the argument
> 'bootinfo' is the register r0 left by the function __barebox_arm_head()
> but I cannot really understand the logic behind it.

When the am335x ROM passes control to the bootloader then it passes in
R0 a pointer to the bootinfo. This is a three word structure which has
informations where the SoC has booted from. In am33xx_save_bootinfo() we
copy the information to a known place where we can pick it up later, see
am33xx_bootsource().

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] net: cpsw: fix probe with fixed-link

2018-02-15 Thread Sascha Hauer 
Hi Andreas,

On Tue, Feb 13, 2018 at 10:48:16PM +0100, Andreas Schmidt wrote:
> If cpsw slave is set to fixed-link cpsw probe still try to probe and use
> a phy. This patch fix cpsw probe in case of fixed-link.
> 
> Signed-off-by: Andreas Schmidt 
> ---
>  drivers/net/cpsw.c | 41 +++--
>  1 file changed, 27 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
> index d11ca33f7..37e480248 100644
> --- a/drivers/net/cpsw.c
> +++ b/drivers/net/cpsw.c
> @@ -184,6 +184,7 @@ struct cpsw_slave {
>   struct eth_device   edev;
>   struct cpsw_priv*cpsw;
>   struct device_d dev;
> + int fixed_link;
>  };
>  
>  struct cpdma_desc {
> @@ -913,18 +914,20 @@ static int cpsw_slave_setup(struct cpsw_slave *slave, 
> int slave_num,
>   struct eth_device   *edev = >edev;
>   struct device_d *dev = >dev;
>   int ret;
> - struct phy_device *phy;
> + struct phy_device *phy = NULL;
>  
> - phy = mdiobus_scan(>miibus, priv->slaves[slave_num].phy_id);
> - if (IS_ERR(phy)) {
> - ret = PTR_ERR(phy);
> - goto err_out;
> - }
> + if (!slave->fixed_link) {
> + phy = mdiobus_scan(>miibus, 
> priv->slaves[slave_num].phy_id);
> + if (IS_ERR(phy)) {
> + ret = PTR_ERR(phy);
> + goto err_out;
> + }

Calling mdiobus_scan() here is not only wrong for a fixed phy, it is
wrong for a regular mdiobus phy aswell. I just sent out a patch which
just removes the call to mdiobus_scan(). Tested on a beaglebone which
has a real phy, it should work for you aswell.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH] net: cpsw: remove unnecessary mdiobus_scan()

2018-02-15 Thread Sascha Hauer 
No need to call mdiobus_scan() manually. it is called from
phy_device_connect() already in cpsw_open() which does all
the magic to connect a network device with its phy.

Signed-off-by: Sascha Hauer 
---
 drivers/net/cpsw.c | 18 ++
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index d11ca33f70..54ee5f327a 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -913,25 +913,13 @@ static int cpsw_slave_setup(struct cpsw_slave *slave, int 
slave_num,
struct eth_device   *edev = >edev;
struct device_d *dev = >dev;
int ret;
-   struct phy_device *phy;
-
-   phy = mdiobus_scan(>miibus, priv->slaves[slave_num].phy_id);
-   if (IS_ERR(phy)) {
-   ret = PTR_ERR(phy);
-   goto err_out;
-   }
-
-   phy->dev.device_node = priv->slaves[slave_num].dev.device_node;
-   ret = phy_register_device(phy);
-   if (ret)
-   goto err_out;
 
sprintf(dev->name, "cpsw-slave");
dev->id = slave->slave_num;
dev->parent = priv->dev;
ret = register_device(dev);
if (ret)
-   goto err_register_dev;
+   return ret;
 
dev_dbg(>dev, "* %s\n", __func__);
 
@@ -956,11 +944,9 @@ static int cpsw_slave_setup(struct cpsw_slave *slave, int 
slave_num,
 
return 0;
 
-err_register_dev:
-   phy_unregister_device(phy);
 err_register_edev:
unregister_device(dev);
-err_out:
+
slave->slave_num = -1;
 
return ret;
-- 
2.15.1


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 3/3] drivers: mtd: nand: omap: Return stat value

2018-02-15 Thread Daniel Schultz 

Hi Sascha,


On 01/30/2018 08:11 AM, Sascha Hauer wrote:

On Mon, Jan 29, 2018 at 02:04:11PM +0100, Daniel Schultz wrote:

The read page function should return the total count of flipped bits,
otherwise the caller always thinks no bitflip occured.

Signed-off-by: Daniel Schultz 
---
  drivers/mtd/nand/nand_omap_gpmc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/nand_omap_gpmc.c 
b/drivers/mtd/nand/nand_omap_gpmc.c
index e18ce63..38f4960 100644
--- a/drivers/mtd/nand/nand_omap_gpmc.c
+++ b/drivers/mtd/nand/nand_omap_gpmc.c
@@ -712,7 +712,7 @@ static int omap_gpmc_read_page_bch_rom_mode(struct mtd_info 
*mtd,
else
mtd->ecc_stats.corrected += stat;
  
-	return 0;

+   return stat;
  }

I'm afraid this is not enough. read_page should return the maximum
number of bitflips in any ECC step. You first have to change
omap_correct_bch() so that it returns this number.
ahh, we worked on this problem a half year ago and it seems like three 
patches are missing upstream:


http://lists.infradead.org/pipermail/barebox/2017-June/030385.html
http://lists.infradead.org/pipermail/barebox/2017-June/030384.html
http://lists.infradead.org/pipermail/barebox/2017-June/030355.html

Daniel


Sascha




--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz

- Entwicklung -
Tel.:   +49 6131 92 21 457
d.schu...@phytec.de
www.phytec.de

Sie finden uns auch auf: Facebook, LinkedIn, Xing, YouTube

PHYTEC Messtechnik GmbH | Robert-Koch-Str. 39 | 55129 Mainz, Germany
Geschäftsführer: Dipl.-Ing. Michael Mitezki, Dipl.-Ing. Bodo Huber |
Handelsregister Mainz HRB 4656 | Finanzamt Mainz-Mitte | St.Nr. 266500608,
DE 149059855
This E-Mail may contain confidential or privileged information. If you are
not the intended recipient (or have received this E-Mail in error) please
notify the sender immediately and destroy this E-Mail. Any unauthorized
copying, disclosure or distribution of the material in this E-Mail is
strictly forbidden.


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox