07 Jun, 2014

7 commits


02 Jun, 2014

1 commit


28 May, 2014

4 commits

  • The current pmic i2c code assumes the current i2c bus is
    the same as the pmic device's bus. There is nothing ensuring
    that to be true. Therefore, select the proper bus before performing
    a transaction.

    Signed-off-by: Aaron Durbin
    Signed-off-by: Simon Glass
    Acked-by: Heiko Schocher
    Reviewed-by: Simon Glass
    Signed-off-by: Minkyu Kang

    Aaron Durbin
     
  • This adds driver support for the TPS65090 PMU. Support includes
    hooking into the pmic infrastructure so that the pmic commands
    can be used on the console. The TPS65090 supports the following
    functionality:

    - fet enable/disable/querying
    - getting and setting of charge state

    Even though it is connected to the pmic infrastructure it does
    not hook into the pmic charging charging infrastructure.

    The device tree binding is from Linux, but only a small subset of
    functionality is supported.

    Signed-off-by: Tom Wai-Hong Tam
    Signed-off-by: Hatim Ali
    Signed-off-by: Katie Roberts-Hoffman
    Signed-off-by: Rong Chang
    Signed-off-by: Sean Paul
    Signed-off-by: Vincent Palatin
    Signed-off-by: Aaron Durbin
    Signed-off-by: Simon Glass
    Signed-off-by: Minkyu Kang

    Tom Wai-Hong Tam
     
  • This enum should be common across all PMICs rather than having it
    independently defined with the same name in multiple places.

    Signed-off-by: Simon Glass
    Signed-off-by: Minkyu Kang

    Simon Glass
     
  • Commit be3b51aa did this mostly, but several have been added since. Do the
    job again.

    Signed-off-by: Simon Glass
    Acked-by: Lukasz Majewski
    Signed-off-by: Minkyu Kang

    Simon Glass
     

27 May, 2014

2 commits


25 May, 2014

5 commits

  • The correct value for this setting can vary across SoCs and boards, so make it
    configurable.

    Also reduce the default value to 8, which is the same default as used in the
    Linux driver.

    Signed-off-by: Ian Campbell
    Cc: Alexey Brodkin

    Ian Campbell
     
  • On Thu, 2014-05-08 at 22:26 +0100, Ian Campbell wrote:
    > The {r,t}xbuffs fields also need to be aligned. Previously this was done
    > implicitly because they immediately followed the descriptor tables. Make this
    > explicit and also move to the head of the struct.

    Looks like I managed to not actually commit the move of the field to the
    head of the struct! v3.1 follows....

    Ian.

    8From 2937ba01841887317f6792709ed57cb86b5fc0cd Mon Sep 17 00:00:00 2001
    From: Ian Campbell
    Date: Thu, 1 May 2014 19:45:15 +0100
    Subject: [PATCH] net/designware: reorder struct dw_eth_dev to pack more
    efficiently.

    The {tx,rx}_mac_descrtable fields are aligned to ARCH_DMA_MINALIGN, which could
    be 256 or even larger. That means there is a potentially huge hole in the
    struct before those fields, so move them to the front where they are better
    packed.

    Moving them to the front also helps ensure that so long as dw_eth_dev is
    properly aligned (which it is since "net/designware: ensure device private data
    is DMA aligned.") the {tx,rx}_mac_descrtable will be too, or at least avoids
    having to worry too much about compiler specifics.

    The {r,t}xbuffs fields also need to be aligned. Previously this was done
    implicitly because they immediately followed the descriptor tables. Make this
    explicit and also move to the head of the struct.

    Signed-off-by: Ian Campbell
    Cc: Alexey Brodkin
    Tested-by: Siarhei Siamashka
    Reviewed-by: Siarhei Siamashka

    Ian Campbell
     
  • This is required at least on ARM.

    When sending instead of simply invalidating the entire descriptor, flush
    as little as possible while still respecting ARCH_DMA_MINALIGN, as
    requested by Alexey.

    Signed-off-by: Ian Campbell
    Cc: Alexey Brodkin

    Ian Campbell
     
  • struct dw_eth_dev contains fields which are accessed via DMA, so make sure it
    is aligned to a dma boundary. Without this I see:
    ERROR: v7_dcache_inval_range - start address is not aligned - 0x7fb677e0

    Signed-off-by: Ian Campbell
    Reviewed-by: Alexey Brodkin
    Acked-by: Marek Vasut

    Ian Campbell
     
  • On Mon, 2014-05-05 at 14:18 +0200, Stefan Roese wrote:
    > > + case 1:
    > > +#if CONFIG_MMC1_PG

    > Are you sure that this is correct and shouldn't be:
    >
    > +#ifdef CONFIG_MMC1_PG
    >
    > ?

    It's "correct" in so far as it works (the boards.cfg config stuff
    #defines things to 1), but I think you are right that it isn't the
    preferred style. But...

    > A quick scan through this patch series shows that this define
    > is not set at all. Perhaps its outdated? Or is it used to support
    > some other sunxi SoC? Not sure, perhaps it should be removed for
    > now.

    ...I had thought that it was to support some other board which wasn't
    being upstreamed right now, so eventually useful and harmless for now,
    but I've just checked and it isn't actually used by any of the boards in
    u-boot-sunxi.git. So rather than fix it to use #ifdef lets drop it.
    Rather than resend the entire series, here is v5.1 of this patch.

    > Other than this please add my:
    >
    > Reviewed-by: Stefan Roese

    Thanks!

    8From 20704e35a41664de5f516ed0e02981ac06085102 Mon Sep 17 00:00:00 2001
    From: Ian Campbell
    Date: Fri, 7 Mar 2014 04:29:39 +0000
    Subject: [PATCH v5.1 7/8] sunxi: mmc support

    This adds support for the MMC controller on the Allwinner A20 (sun7i)
    processor.

    Signed-off-by: Henrik Nordstrom
    Signed-off-by: Luke Leighton
    Signed-off-by: Oliver Schinagl
    Signed-off-by: Wills Wang
    Signed-off-by: Ian Campbell
    Reviewed-by: Marek Vasut
    Reviewed-by: Stefan Roese
    Cc: Tom Cubie
    Cc: Aaron Maoye
    Cc: Pantelis Antoniou
    Reviewed-by: Tom Rini

    Ian Campbell
     

24 May, 2014

1 commit


23 May, 2014

10 commits


22 May, 2014

1 commit

  • When configure the fsl_esdhc driver to PIO mode by defining
    "CONFIG_SYS_FSL_ESDHC_USE_PIO", the SD/MMC read and write will fail.

    Two bugs in the driver to cause the issue:
    1. The read buffer was invalidated after reading from DATAPORT register,
    which should be only applied to DMA mode. The valid data in cache was
    overwritten by physical memory.
    2. The watermarks are not set in PIO mode, will cause according state not
    be set.

    Acked-by: Pantelis Antoniou
    Signed-off-by: Ye.Li

    Ye.Li
     

20 May, 2014

4 commits


17 May, 2014

4 commits


16 May, 2014

1 commit