All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Chris Ball <chris@printf.net>,
	linux-mmc@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
	Andrew Lunn <andrew@lunn.ch>,
	Gregory Clement <gregory.clement@free-electrons.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Lior Amsalem <alior@marvell.com>,
	Tawfik Bayouk <tawfik@marvell.com>,
	Marcin Wojtas <mw@semihalf.com>
Subject: Re: [PATCH] mmc: sdhci-pxav3: add support for the Armada 38x SDHCI controller
Date: Tue, 18 Feb 2014 20:43:04 +0100	[thread overview]
Message-ID: <5574693.NJgodrZ14k@wuerfel> (raw)
In-Reply-To: <20140218202616.3cfa0ef8@skate>

On Tuesday 18 February 2014 20:26:16 Thomas Petazzoni wrote:
> On Tue, 18 Feb 2014 19:02:47 +0100, Arnd Bergmann wrote:
> 
> > > In order to achieve this, the sdhci-pxav3 driver is extended with an
> > > additional compatible string "marvell,armada-380-sdhci". When this
> > > compatible string is used, the MBus windows are initialized in a way
> > > that is identical to what all other DMA-capable drivers for Marvell
> > > EBU platforms do.
> > 
> > It seems odd to do this in the sdhci driver, when the configuration
> > is done in registers that belong to mbus.
> 
> No, those registers don't belong to MBus. They belong to the device
> itself, as they configure the device -> memory windows.
> 
> Because SDHCI has a standard register interface, they separated the
> SDHCI registers (standard) from the registers to configure the device
> -> Mbus windows (Marvell-specific).
> 
> But in all other IPs, the device -> memory windows are configured in
> registers that are just in the middle of the other registers for this
> device.

Ok, got it.


> > 
> > > +/*
> > > + * These registers are relative to the second register region, for the
> > > + * MBus bridge.
> > > + */
> > > +#define SDHCI_WINDOW_CTRL(i)   (0x80 + ((i) << 3))
> > > +#define SDHCI_WINDOW_BASE(i)   (0x84 + ((i) << 3))
> > > +#define SDHCI_MAX_WIN_NUM      8
> > 
> > These look similar to the outbound mbus windows that are used for MMIO,
> > but it's not really clear from the code what they really do.
> 
> There are two completely different mechanisms:
> 
>  * The CPU -> { memory, device } windows. These windows are managed by
>    the mvebu-mbus driver, as they are configured using global
>    registers, owned by the mvebu-driver.
> 
>  * The device -> memory windows. These windows are needed for a given
>    device to access memory in order to do DMA. These windows are
>    configured through registers that are part of each peripheral
>    register area.

Yes, I understand the difference. The former corresponds to
the DT 'ranges' property, while the latter is the 'dma-ranges'
property.

> > I assume there are more the same register ranges for each bus master
> > behind mbus (PCI being special again). How about adding an exported
> > function to the mbus driver that sets up all the windows for one
> > bus master correctly, passing only the number of the bus master?
> 
> This is certainly a possible refactoring, but it involves changing a
> fairly large number of drivers, since many drivers are using
> mv_mbus_dram_info() (this function and all the code spread in drivers
> to configure windows predates the mach-mvebu thing and all the DT
> conversion).

Is the layout of the mbus configuration windows in each device
the same?

> Therefore, I'd like to have the possibility of handling sdhci-pxav3.c
> like all other drivers for now, and then do a cleanup of this area.
> Would this be possible?

Yes, sounds reasonable.

Thanks for the clarification.

	Arnd

  reply	other threads:[~2014-02-18 19:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18 15:08 [PATCH] mmc: sdhci-pxav3: add support for the Armada 38x SDHCI controller Thomas Petazzoni
2014-02-18 18:02 ` Arnd Bergmann
2014-02-18 19:26   ` Thomas Petazzoni
2014-02-18 19:43     ` Arnd Bergmann [this message]
2014-02-18 19:57       ` Thomas Petazzoni
2014-02-25 18:40 ` Thomas Petazzoni
2014-03-20 20:13   ` Thomas Petazzoni
2014-03-29 15:14 ` Thomas Petazzoni
2014-03-29 16:19   ` Chris Ball
2014-03-29 16:48     ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5574693.NJgodrZ14k@wuerfel \
    --to=arnd@arndb.de \
    --cc=alior@marvell.com \
    --cc=andrew@lunn.ch \
    --cc=chris@printf.net \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-mmc@vger.kernel.org \
    --cc=mw@semihalf.com \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=tawfik@marvell.com \
    --cc=thomas.petazzoni@free-electrons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.