mada XP bases board.
>
> Cc: sta...@vger.kernel.org # v3.12+
> Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
>
> Signed-off-by: Gregory CLEMENT
> ---
> drivers/i2c/busses/i2c-mv64xxx.c | 9 -
> 1 file changed, 8 insertions(+), 1
On Fri, Feb 07, 2014 at 10:09:53AM -0800, Kevin Hilman wrote:
> Jason Cooper writes:
>
> > On Fri, Feb 07, 2014 at 11:55:54AM +0100, Gregory CLEMENT wrote:
> >> Offload can be used only on regular transactions and for 1 to byte
> >> transfers. In the other cases we
On Fri, Feb 07, 2014 at 11:55:54AM +0100, Gregory CLEMENT wrote:
> Offload can be used only on regular transactions and for 1 to byte
> transfers. In the other cases we switch back to usual work flow.
>
> In this case we need to call mv64xxx_i2c_prepare_for_io() as this
> function is not used when
On Mon, Jan 20, 2014 at 12:20:40PM +0100, Gregory CLEMENT wrote:
> On 14/01/2014 09:46, Gregory CLEMENT wrote:
> > On 14/01/2014 03:14, Jason Cooper wrote:
> >> Gregory,
> >>
> >> On Wed, Jan 08, 2014 at 04:06:25PM +0100, Gregory CLEMENT wrote:
> >>&
Gregory,
On Wed, Jan 08, 2014 at 04:06:25PM +0100, Gregory CLEMENT wrote:
> Hi,
>
> Here come the 5th version of the series fixing the i2c bus hang on A0
> version of the Armada XP SoCs. It occurred on the early release of the
> OpenBlocks AX3-4 boards. Indeed the first variants of Armada XP SoCs
Gregory,
On Wed, Jan 08, 2014 at 04:06:29PM +0100, Gregory CLEMENT wrote:
> The first variants of Armada XP SoCs (A0 stepping) have issues related
> to the i2c controller which prevent to use the offload mechanism and
> ead to a kernel hang during boot.
I'll fixup s/ead/lead/ here.
>
> The comm
On Fri, Jan 10, 2014 at 10:21:29PM +0100, Gregory CLEMENT wrote:
> On 10/01/2014 22:14, Jason Cooper wrote:
> > On Fri, Jan 10, 2014 at 09:12:41PM +0100, Gregory CLEMENT wrote:
> >> Jason,
> >> On 10/01/2014 21:08, Jason Cooper wrote:
> >>> On Fri, Jan 10,
On Fri, Jan 10, 2014 at 02:06:34PM -0700, Jason Gunthorpe wrote:
> On Fri, Jan 10, 2014 at 02:45:50PM -0500, Jason Cooper wrote:
>
> > > IMHO the compatible string should represent a specific HW/SW ABI. So
> > > you need a unique compatible string for every variation
On Fri, Jan 10, 2014 at 09:12:41PM +0100, Gregory CLEMENT wrote:
> Jason,
> On 10/01/2014 21:08, Jason Cooper wrote:
> > On Fri, Jan 10, 2014 at 02:45:50PM -0500, Jason Cooper wrote:
> >> On Fri, Jan 10, 2014 at 12:05:21PM -0700, Jason Gunthorpe wrote:
> >>> O
On Fri, Jan 10, 2014 at 09:09:09PM +0100, Gregory CLEMENT wrote:
> Hi Jason,
>
> On 10/01/2014 20:45, Jason Cooper wrote:
> > On Fri, Jan 10, 2014 at 12:05:21PM -0700, Jason Gunthorpe wrote:
> >> On Fri, Jan 10, 2014 at 01:22:40PM -0500, Jason Cooper wrote:
> >>
On Fri, Jan 10, 2014 at 02:45:50PM -0500, Jason Cooper wrote:
> On Fri, Jan 10, 2014 at 12:05:21PM -0700, Jason Gunthorpe wrote:
> > On Fri, Jan 10, 2014 at 01:22:40PM -0500, Jason Cooper wrote:
> >
> > > Do we create new compatible strings to indicate errata, or to i
On Fri, Jan 10, 2014 at 12:05:21PM -0700, Jason Gunthorpe wrote:
> On Fri, Jan 10, 2014 at 01:22:40PM -0500, Jason Cooper wrote:
>
> > Do we create new compatible strings to indicate errata, or to indicate
> > 'from this version forward there are new features'? The
Gregory, Arnd,
On Wed, Jan 08, 2014 at 04:06:27PM +0100, Gregory CLEMENT wrote:
> The first variants of Armada XP SoCs (A0 stepping) have issues related
> to the i2c controller which prevent to use the offload mechanism and
> lead to a kernel hang during boot.
>
> This commit add quirk in the mve
Wolfram,
On Thu, Jan 02, 2014 at 05:01:16PM +0100, Gregory CLEMENT wrote:
> The first variants of Armada XP SoCs (A0 stepping) have issues related
> to the i2c controller which prevent to use the offload mechanism and
> lead to a kernel hang during boot.
>
> The driver now check the revision of t
[+ DT ml, Grant, Rob]
On Tue, Dec 31, 2013 at 05:44:53PM +0100, Gregory CLEMENT wrote:
> Signed-off-by: Gregory CLEMENT
> ---
> Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2
On Tue, Dec 31, 2013 at 05:44:53PM +0100, Gregory CLEMENT wrote:
> Signed-off-by: Gregory CLEMENT
> ---
> Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> b/Docu
On Wed, Jan 01, 2014 at 04:41:16PM -0500, Jason Cooper wrote:
> Sorry, but we seem to have a fundamental mis-understanding here. First,
> whatever we end up deciding for the compatible strings needs to be
> documented. Which seems to have not made it into this series.
Ok, this is take
Gregory,
Sorry, but we seem to have a fundamental mis-understanding here. First,
whatever we end up deciding for the compatible strings needs to be
documented. Which seems to have not made it into this series.
Second, I'm having trouble explaining this (in my head), so I'm adding
the DT ml so h
On Tue, Dec 31, 2013 at 01:50:34PM +0100, Sebastian Hesselbarth wrote:
> On 12/31/2013 01:28 PM, Gregory CLEMENT wrote:
> >>First I wanted to be sure that there the issue was not introduce by a
> >>commit so reverted one by one the commits on the file
> >>drivers/i2c/busses/i2c-mv64xxx.c. I tested
On Mon, Sep 02, 2013 at 01:44:45PM +0200, Gregory CLEMENT wrote:
> Hi Jason,
>
> Unless I missed it I didn't see this patch in your last pull request.
> Wolfram took the 3 others patches and Mark Rutland agreed with the binding
> introduced in the patch 3. So I think we are fine to take this patch
On Mon, Sep 02, 2013 at 01:44:45PM +0200, Gregory CLEMENT wrote:
> Hi Jason,
>
> Unless I missed it I didn't see this patch in your last pull request.
> Wolfram took the 3 others patches and Mark Rutland agreed with the binding
> introduced in the patch 3. So I think we are fine to take this patch
Ezequiel,
On Fri, Aug 09, 2013 at 06:13:37AM -0300, Ezequiel Garcia wrote:
> (Sending to devicetree)
As an FYI? I already responded to Mark Rutland's request for the
binding doc to be updated (that it was this patch, already merged into
mvebu/dt). I also asked him if everything looked ok to him
On Wed, Aug 07, 2013 at 04:35:46PM +0200, Wolfram Sang wrote:
>
> > But we shouldn't use it alone: we should always use:
> > compatible = "marvell,mv78230-i2c", "marvell,mv64xxx-i2c";
> >
> > From my point of view using "marvell,mv78230-i2c" alone is an error.
> >
> > Wolfram what is your opini
On Mon, Jul 15, 2013 at 04:24:38PM +0200, Gregory CLEMENT wrote:
> The mv64xxx-i2c embedded in the Armada XP have a new feature to
> offload i2c transaction. This new version of the IP come also with
> some errata. This lead to the introduction to a another compatible
> string.
>
> This commit spl
On Fri, Jun 21, 2013 at 05:03:23PM +0200, Wolfram Sang wrote:
>
> > > from a quick check of the patch set (which you forgot to send to LKML)
> > > I am wondering why you didn't update the of matches struct with the new
> > > compatible for "marvell,mv78230-i2c"? This will save you from still
> > >
On Fri, Jun 21, 2013 at 04:15:29PM +0200, Sebastian Hesselbarth wrote:
> On 06/21/13 16:07, Jason Cooper wrote:
> >On Fri, Jun 21, 2013 at 03:32:09PM +0200, Gregory CLEMENT wrote:
> >>The mv64xxx-i2c embedded in the Armada XP have a new feature to
> >>offload i2c trans
On Fri, Jun 21, 2013 at 03:32:09PM +0200, Gregory CLEMENT wrote:
> The mv64xxx-i2c embedded in the Armada XP have a new feature to
> offload i2c transaction. This new version of the IP come also with
> some errata. This lead to the introduction to a another compatible
> string.
>
> This commit spl
On Fri, Jun 07, 2013 at 05:42:23PM +0200, Gregory CLEMENT wrote:
> The mv64xxx-i2c embedded in the Armada XP have a new feature called
> i2c-bridge. This commit split the i2c information into armada-370.dtsi
> and armada-xp.dtsi. Most of the data remains the same and stay in the
> common file Armad
On Tue, Jun 12, 2012 at 02:04:33PM +0200, Andrew Lunn wrote:
> > > + spi@10600 {
> > > + compatible = "marvell,orion-spi";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + cell-index = <0>;
> > > +
label = "U-Boot Config";
> + };
> + partition@000c {
> + reg = <0x000c 0x0014>;
> + label = "NAS Config";
>
O controllers
> are found.
>
> Signed-off-by: Andrew Lunn
Acked-by: Jason Cooper
> ---
> .../devicetree/bindings/gpio/mrvl-gpio.txt | 25 +++
> arch/arm/boot/dts/kirkwood.dtsi| 20 ++
> arch/arm/mach-kirkwood/irq.c
On Sun, Jun 10, 2012 at 12:31:58PM +0200, Andrew Lunn wrote:
> From: Michael Walle
>
> Use the device tree for the SPI driver and partition layout.
>
> Signed-off-by: Michael Walle
> Signed-off-by: Andrew Lunn
Acked-by: Jason Cooper
> ---
> arch/arm/boot/dts/kirkw
xf1010600, "orion_spi.0", NULL),
Isn't this -^^ defined somewhere?
This is done about 1/4 of the time (56 / 187) in the kernel. But
honestly, I'd prefer it to be named.
Other than that,
Acked-by: Jason Cooper
> + {},
> +
On Sun, Jun 10, 2012 at 12:31:56PM +0200, Andrew Lunn wrote:
> From: Michael Walle
>
> Signed-off-by: Michael Walle
> Signed-off-by: Andrew Lunn
Looks good.
Acked-by: Jason Cooper
> ---
> Documentation/devicetree/bindings/spi/spi-orion.txt |5 +
> dr
+ kirkwood_init_irq();
> + irq_domain_add_legacy(np, 64, 0, 0, &irq_domain_simple_ops, NULL);
> + return 0;
> +}
> +
> +static const struct of_device_id kirkwood_irq_match[] = {
> + { .compatible = "marvell,orion-intc",
> + .data = kirkwood_add_irq_dom
On Sun, Jun 10, 2012 at 12:31:52PM +0200, Andrew Lunn wrote:
> This patch set adds Device Tree support for IRQ, SPI, I2C and GPIO on
> Orion based drivers, and makes use of these for kirkwood devices. It
> also adds the ability to boot QNAP TS219 based systems using device
> tree.
Andrew, thanks
36 matches
Mail list logo
