* [PATCH 1/5] net: mvmdio: unmap base register address at driver removal
From: Florian Fainelli @ 2013-01-29 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129163242.1df2caf5@skate>
On 01/29/2013 04:32 PM, Thomas Petazzoni wrote:
> Dear Florian Fainelli,
>
> On Tue, 29 Jan 2013 16:24:04 +0100, Florian Fainelli wrote:
>> Fix the driver remove callback to unmap the base register address and
>> not leak this mapping after the driver has been removed.
>>
>> Signed-off-by: Florian Fainelli <florian@openwrt.org>
> What about using devm_request_and_ioremap() instead, in order to get
> automatic unmap on error and in the ->remove() path?
Right now, you are using of_iomap() which eases the task of fetching the
resource and getting an ioremap cookie, which I why I kept that.
>
> But maybe it won't work because this memory range is claimed both by
> the MDIO driver and the Ethernet driver itself. In that case, you could
> use devm_ioremap().
Then we would loose the facility of of_iomap(), but fair enough, it can
be inserted as a patch in this serie.
Thanks
--
Florian
^ permalink raw reply
* [PATCH 09/30] USB: ehci-omap: Use devm_request_and_ioremap()
From: Alan Stern @ 2013-01-29 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128152010.GN23505@n2100.arm.linux.org.uk>
On Mon, 28 Jan 2013, Russell King - ARM Linux wrote:
> On Mon, Jan 28, 2013 at 10:17:33AM -0500, Alan Stern wrote:
> > On Mon, 28 Jan 2013, Roger Quadros wrote:
> >
> > > Make use of devm_request_and_ioremap() and correct comment.
> >
> > Didn't a big patch come through recently converting all usages of
> > devm_request_and_ioremap() to another function (I forget the name) that
> > does its own error reporting and returns an ERR_PTR value?
> >
> > (Checks the mailing list archive...) Ah, here it is:
> >
> > http://marc.info/?l=linux-usb&m=135876311801537&w=2
> >
> > And the new function is devm_ioremap_resource(). We should avoid
> > adding new usages of an old interface.
>
> Maybe... if devm_ioremap_resource() was already in the kernel. The
> problem at the moment is it isn't, and it'll probably be rather
> horrid for everyone to deal with especially when it comes to testing.
Not in the kernel yet? I didn't realize that. Looks like Thierry
Reding will have some clean-up work to do when it does get in.
Okay, then
Acked-by: Alan Stern <stern@rowland.harvard.edu>
^ permalink raw reply
* [PATCH 2/5] net: mvmdio: rename base register cookie from smireg to regs
From: Thomas Petazzoni @ 2013-01-29 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-3-git-send-email-florian@openwrt.org>
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:05 +0100, Florian Fainelli wrote:
> This patch renames the base register cookie in the mvmdio drive from
> "smireg" to "regs" since a subsequent patch is going to use an ioremap()
> cookie whose size is larger than a single register of 4 bytes. No
> functionnal code change introduced.
>
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 10/30] USB: ehci-omap: Use PHY APIs to get the PHY device and put it out of suspend
From: Roger Quadros @ 2013-01-29 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1301291026020.1507-100000@iolanthe.rowland.org>
On 01/29/2013 05:30 PM, Alan Stern wrote:
> On Tue, 29 Jan 2013, Roger Quadros wrote:
>
>> For each port that is in PHY mode we obtain a PHY device using the USB PHY
>> library and put it out of suspend.
>>
>> It is up to platform code to associate the PHY to the controller's
>> port and it is upto the PHY driver to manage the PHY's resources.
>
> s/upto/up to/
>
>> Also remove wired spacing around declarations we come across.
>
> s/wired/weird/ -- not that people care about misspellings in the
> Changelog. You don't have to resubmit the patch just to fix these two
> items.
>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
>
Thanks Alan. I'll fix them in the pull request.
cheers,
-roger
^ permalink raw reply
* [PATCH 1/5] net: mvmdio: unmap base register address at driver removal
From: Thomas Petazzoni @ 2013-01-29 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-2-git-send-email-florian@openwrt.org>
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:04 +0100, Florian Fainelli wrote:
> Fix the driver remove callback to unmap the base register address and
> not leak this mapping after the driver has been removed.
>
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
What about using devm_request_and_ioremap() instead, in order to get
automatic unmap on error and in the ->remove() path?
But maybe it won't work because this memory range is claimed both by
the MDIO driver and the Ethernet driver itself. In that case, you could
use devm_ioremap().
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 10/30] USB: ehci-omap: Use PHY APIs to get the PHY device and put it out of suspend
From: Alan Stern @ 2013-01-29 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359453032-20604-1-git-send-email-rogerq@ti.com>
On Tue, 29 Jan 2013, Roger Quadros wrote:
> For each port that is in PHY mode we obtain a PHY device using the USB PHY
> library and put it out of suspend.
>
> It is up to platform code to associate the PHY to the controller's
> port and it is upto the PHY driver to manage the PHY's resources.
s/upto/up to/
> Also remove wired spacing around declarations we come across.
s/wired/weird/ -- not that people care about misspellings in the
Changelog. You don't have to resubmit the patch just to fix these two
items.
> Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Thomas Petazzoni @ 2013-01-29 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129152518.GZ23505@n2100.arm.linux.org.uk>
Russell,
On Tue, 29 Jan 2013 15:25:18 +0000, Russell King - ARM Linux wrote:
> Yep, otherwise we'll have yet more code to review rather than one
> algorithm with a set of numbers...
>
> I work on the principle that if something can be expressed numerically,
> that's always better than expressing it with code.
Having a hook allows for more flexibility (for example having special
alignment requirements depending on the device or something like that),
but I don't need this flexibility for the specific case I'm interested
in. So as you suggest, let's not over-engineer this, and use numerical
values. I'll rework my patch according to this suggestion.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Arnd Bergmann @ 2013-01-29 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359467140.31148.41.camel@smile>
On Tuesday 29 January 2013, Andy Shevchenko wrote:
> On Tue, 2013-01-29 at 13:31 +0000, Arnd Bergmann wrote:
> > On Tuesday 29 January 2013, Viresh Kumar wrote:
> > Ah, good. So I guess the "dma-requests" property should actually
> > be "16" then.
> >
> > Does this mean that an implicit zero request line means memory?
>
> No, it doesn't.
> When dma is doing mem2mem transfers the request line field is ignored by
> the hw.
Ok.
> > Could we have device-to-device DMAs with this controller, and if
> > we can, should we have both 'src' and 'dst' fields?
>
> As far as I know there is no driver under dmaengine that supports
> per2per transfers.
Well, I'm asking because we need to describe the hardware properly,
even if drivers today don't do this does not mean that it is not
possible. We can always change the Linux implementation, but we
cannot as easily change an established DT binding, just like
we don't change user space interfaces.
Of course, if that is a thing we don't expect anyone to do,
we don't have to describe it, or we could make a compatible
extension to the binding later.
> > Are the
> > two number ranges sharing the same address space, i.e. is
> > request '7' as the destination guaranteed to be the same device
> > as request '7' in the source?
>
> Request line should be unique. It means a real wire from slave
> hw to the dmac.
Ok, good.
Arnd
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Russell King - ARM Linux @ 2013-01-29 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129162337.0121cbab@skate>
On Tue, Jan 29, 2013 at 04:23:37PM +0100, Thomas Petazzoni wrote:
> Russell,
>
> Thanks for your quick feedback!
>
> On Tue, 29 Jan 2013 15:15:01 +0000, Russell King - ARM Linux wrote:
>
> > Given the description, I'd feel much happier with this if we specified
> > the alignment numerically rather than allowing "some random code" to do
> > something with the passed values.
>
> So, you'd prefer to have two new members added in the hw_pci structure
> to give the alignment requirements for I/O regions and memory regions?
Yep, otherwise we'll have yet more code to review rather than one
algorithm with a set of numbers...
I work on the principle that if something can be expressed numerically,
that's always better than expressing it with code.
^ permalink raw reply
* [PATCH 5/5] mv643xx_eth: convert to use the Marvell Orion MDIO driver
From: Florian Fainelli @ 2013-01-29 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-1-git-send-email-florian@openwrt.org>
This patch converts the Marvell MV643XX ethernet driver to use the
Marvell Orion MDIO driver. As a result, PowerPC and ARM platforms
registering the Marvell MV643XX ethernet driver are also updated to
register a Marvell Orion MDIO driver. This driver voluntarily overlaps
with the Marvell Ethernet shared registers because it will use a subset
of this shared register (shared_base + 0x4 - shared_base + 0x84). The
Ethernet driver is also updated to look up for a PHY device using the
Orion MDIO bus driver.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
arch/arm/plat-orion/common.c | 84 +++++++++++--
arch/powerpc/platforms/chrp/pegasos_eth.c | 20 +++
arch/powerpc/sysdev/mv64x60_dev.c | 14 ++-
drivers/net/ethernet/marvell/Kconfig | 1 +
drivers/net/ethernet/marvell/mv643xx_eth.c | 187 ++--------------------------
5 files changed, 113 insertions(+), 193 deletions(-)
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index 2d4b641..f9bc66e 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -238,6 +238,7 @@ static __init void ge_complete(
struct mv643xx_eth_shared_platform_data *orion_ge_shared_data,
struct resource *orion_ge_resource, unsigned long irq,
struct platform_device *orion_ge_shared,
+ struct platform_device *orion_ge_mvmdio,
struct mv643xx_eth_platform_data *eth_data,
struct platform_device *orion_ge)
{
@@ -247,6 +248,7 @@ static __init void ge_complete(
orion_ge->dev.platform_data = eth_data;
platform_device_register(orion_ge_shared);
+ platform_device_register(orion_ge_mvmdio);
platform_device_register(orion_ge);
}
@@ -258,8 +260,6 @@ struct mv643xx_eth_shared_platform_data orion_ge00_shared_data;
static struct resource orion_ge00_shared_resources[] = {
{
.name = "ge00 base",
- }, {
- .name = "ge00 err irq",
},
};
@@ -271,6 +271,19 @@ static struct platform_device orion_ge00_shared = {
},
};
+static struct resource orion_ge00_mvmdio_resources[] = {
+ {
+ .name = "ge00 mvmdio base",
+ }, {
+ .name = "ge00 mvmdio err irq",
+ },
+};
+
+static struct platform_device orion_ge00_mvmdio = {
+ .name = "orion-mdio",
+ .id = 0,
+};
+
static struct resource orion_ge00_resources[] = {
{
.name = "ge00 irq",
@@ -295,10 +308,13 @@ void __init orion_ge00_init(struct mv643xx_eth_platform_data *eth_data,
unsigned int tx_csum_limit)
{
fill_resources(&orion_ge00_shared, orion_ge00_shared_resources,
- mapbase + 0x2000, SZ_16K - 1, irq_err);
+ mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
+ fill_resources(&orion_ge00_mvmdio, orion_ge00_mvmdio_resources,
+ mapbase + 0x2004, 0x84 - 1, irq_err);
orion_ge00_shared_data.tx_csum_limit = tx_csum_limit;
ge_complete(&orion_ge00_shared_data,
orion_ge00_resources, irq, &orion_ge00_shared,
+ &orion_ge00_mvmdio,
eth_data, &orion_ge00);
}
@@ -312,9 +328,7 @@ struct mv643xx_eth_shared_platform_data orion_ge01_shared_data = {
static struct resource orion_ge01_shared_resources[] = {
{
.name = "ge01 base",
- }, {
- .name = "ge01 err irq",
- },
+ }
};
static struct platform_device orion_ge01_shared = {
@@ -325,6 +339,19 @@ static struct platform_device orion_ge01_shared = {
},
};
+static struct resource orion_ge01_mvmdio_resources[] = {
+ {
+ .name = "ge01 mdio base",
+ }, {
+ .name = "ge01 mdio err irq",
+ },
+};
+
+static struct platform_device orion_ge01_mvmdio = {
+ .name = "orion-mdio",
+ .id = 1,
+};
+
static struct resource orion_ge01_resources[] = {
{
.name = "ge01 irq",
@@ -349,10 +376,13 @@ void __init orion_ge01_init(struct mv643xx_eth_platform_data *eth_data,
unsigned int tx_csum_limit)
{
fill_resources(&orion_ge01_shared, orion_ge01_shared_resources,
- mapbase + 0x2000, SZ_16K - 1, irq_err);
+ mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
+ fill_resources(&orion_ge01_mvmdio, orion_ge01_mvmdio_resources,
+ mapbase + 0x2004, 0x84 - 1, irq_err);
orion_ge01_shared_data.tx_csum_limit = tx_csum_limit;
ge_complete(&orion_ge01_shared_data,
orion_ge01_resources, irq, &orion_ge01_shared,
+ &orion_ge01_mvmdio,
eth_data, &orion_ge01);
}
@@ -366,9 +396,7 @@ struct mv643xx_eth_shared_platform_data orion_ge10_shared_data = {
static struct resource orion_ge10_shared_resources[] = {
{
.name = "ge10 base",
- }, {
- .name = "ge10 err irq",
- },
+ }
};
static struct platform_device orion_ge10_shared = {
@@ -379,6 +407,19 @@ static struct platform_device orion_ge10_shared = {
},
};
+static struct resource orion_ge10_mvmdio_resources[] = {
+ {
+ .name = "ge10 mvmdio base",
+ }, {
+ .name = "ge10 mvmdio err irq",
+ },
+};
+
+static struct platform_device orion_ge10_mvmdio = {
+ .name = "orion-mdio",
+ .id = 1,
+};
+
static struct resource orion_ge10_resources[] = {
{
.name = "ge10 irq",
@@ -403,8 +444,11 @@ void __init orion_ge10_init(struct mv643xx_eth_platform_data *eth_data,
{
fill_resources(&orion_ge10_shared, orion_ge10_shared_resources,
mapbase + 0x2000, SZ_16K - 1, irq_err);
+ fill_resources(&orion_ge10_mvmdio, orion_ge10_mvmdio_resources,
+ mapbase + 0x2004, 0x84 - 1, irq_err);
ge_complete(&orion_ge10_shared_data,
orion_ge10_resources, irq, &orion_ge10_shared,
+ &orion_ge10_mvmdio,
eth_data, &orion_ge10);
}
@@ -418,8 +462,6 @@ struct mv643xx_eth_shared_platform_data orion_ge11_shared_data = {
static struct resource orion_ge11_shared_resources[] = {
{
.name = "ge11 base",
- }, {
- .name = "ge11 err irq",
},
};
@@ -431,6 +473,19 @@ static struct platform_device orion_ge11_shared = {
},
};
+static struct resource orion_ge11_mvmdio_resources[] = {
+ {
+ .name = "ge11 mvmdio base",
+ }, {
+ .name = "ge11 mvmdio err irq",
+ },
+};
+
+static struct platform_device orion_ge11_mvmdio = {
+ .name = "orion-mdio",
+ .id = 1,
+};
+
static struct resource orion_ge11_resources[] = {
{
.name = "ge11 irq",
@@ -454,9 +509,12 @@ void __init orion_ge11_init(struct mv643xx_eth_platform_data *eth_data,
unsigned long irq_err)
{
fill_resources(&orion_ge11_shared, orion_ge11_shared_resources,
- mapbase + 0x2000, SZ_16K - 1, irq_err);
+ mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
+ fill_resources(&orion_ge11_mvmdio, orion_ge11_mvmdio_resources,
+ mapbase + 0x2004, 0x84 - 1, irq_err);
ge_complete(&orion_ge11_shared_data,
orion_ge11_resources, irq, &orion_ge11_shared,
+ &orion_ge11_mvmdio,
eth_data, &orion_ge11);
}
diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/powerpc/platforms/chrp/pegasos_eth.c
index 039fc8e..a671508 100644
--- a/arch/powerpc/platforms/chrp/pegasos_eth.c
+++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
@@ -47,6 +47,25 @@ static struct platform_device mv643xx_eth_shared_device = {
.resource = mv643xx_eth_shared_resources,
};
+/*
+ * The orion mdio driver only covers shared + 0x4 up to shared + 0x84 - 1
+ */
+static struct resource mv643xx_eth_mvmdio_resources[] = {
+ [0] = {
+ .name = "ethernet mdio base",
+ .start = 0xf1000000 + MV643XX_ETH_SHARED_REGS + 0x4,
+ .end = 0xf1000000 + MV643XX_ETH_SHARED_REGS + 0x83,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device mv643xx_eth_mvmdio_device = {
+ .name = "orion-mdio",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(mv643xx_eth_mvmdio_resources),
+ .resource = mv643xx_eth_shared_resources,
+};
+
static struct resource mv643xx_eth_port1_resources[] = {
[0] = {
.name = "eth port1 irq",
@@ -82,6 +101,7 @@ static struct platform_device eth_port1_device = {
static struct platform_device *mv643xx_eth_pd_devs[] __initdata = {
&mv643xx_eth_shared_device,
+ &mv643xx_eth_mvmdio_device,
ð_port1_device,
};
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c
index 0f6af41..630cea3 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -214,15 +214,25 @@ static struct platform_device * __init mv64x60_eth_register_shared_pdev(
struct device_node *np, int id)
{
struct platform_device *pdev;
- struct resource r[1];
+ struct resource r[2];
int err;
err = of_address_to_resource(np, 0, &r[0]);
if (err)
return ERR_PTR(err);
+ /* register an orion mdio bus driver */
+ r[1].start = r[0].start + 0x4;
+ r[1].end = r[0].start + 0x84 - 1;
+ r[1].flags = IORESOURCE_MEM;
+
+ pdev = platform_device_register_simple("orion-mdio", id, &r[1], 1);
+ if (!pdev)
+ return pdev;
+
pdev = platform_device_register_simple(MV643XX_ETH_SHARED_NAME, id,
- r, 1);
+ &r[0], 1);
+
return pdev;
}
diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
index edfba93..df06061 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -23,6 +23,7 @@ config MV643XX_ETH
depends on (MV64X60 || PPC32 || PLAT_ORION) && INET
select INET_LRO
select PHYLIB
+ select MVMDIO
---help---
This driver supports the gigabit ethernet MACs in the
Marvell Discovery PPC/MIPS chipset family (MV643XX) and
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index c27b23d8..8ef186f 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -67,14 +67,6 @@ static char mv643xx_eth_driver_version[] = "1.4";
* Registers shared between all ports.
*/
#define PHY_ADDR 0x0000
-#define SMI_REG 0x0004
-#define SMI_BUSY 0x10000000
-#define SMI_READ_VALID 0x08000000
-#define SMI_OPCODE_READ 0x04000000
-#define SMI_OPCODE_WRITE 0x00000000
-#define ERR_INT_CAUSE 0x0080
-#define ERR_INT_SMI_DONE 0x00000010
-#define ERR_INT_MASK 0x0084
#define WINDOW_BASE(w) (0x0200 + ((w) << 3))
#define WINDOW_SIZE(w) (0x0204 + ((w) << 3))
#define WINDOW_REMAP_HIGH(w) (0x0280 + ((w) << 2))
@@ -264,25 +256,6 @@ struct mv643xx_eth_shared_private {
void __iomem *base;
/*
- * Points@the right SMI instance to use.
- */
- struct mv643xx_eth_shared_private *smi;
-
- /*
- * Provides access to local SMI interface.
- */
- struct mii_bus *smi_bus;
-
- /*
- * If we have access to the error interrupt pin (which is
- * somewhat misnamed as it not only reflects internal errors
- * but also reflects SMI completion), use that to wait for
- * SMI access completion instead of polling the SMI busy bit.
- */
- int err_interrupt;
- wait_queue_head_t smi_busy_wait;
-
- /*
* Per-port MBUS window access register value.
*/
u32 win_protect;
@@ -1080,98 +1053,6 @@ static void txq_set_fixed_prio_mode(struct tx_queue *txq)
}
-/* mii management interface *************************************************/
-static irqreturn_t mv643xx_eth_err_irq(int irq, void *dev_id)
-{
- struct mv643xx_eth_shared_private *msp = dev_id;
-
- if (readl(msp->base + ERR_INT_CAUSE) & ERR_INT_SMI_DONE) {
- writel(~ERR_INT_SMI_DONE, msp->base + ERR_INT_CAUSE);
- wake_up(&msp->smi_busy_wait);
- return IRQ_HANDLED;
- }
-
- return IRQ_NONE;
-}
-
-static int smi_is_done(struct mv643xx_eth_shared_private *msp)
-{
- return !(readl(msp->base + SMI_REG) & SMI_BUSY);
-}
-
-static int smi_wait_ready(struct mv643xx_eth_shared_private *msp)
-{
- if (msp->err_interrupt == NO_IRQ) {
- int i;
-
- for (i = 0; !smi_is_done(msp); i++) {
- if (i == 10)
- return -ETIMEDOUT;
- msleep(10);
- }
-
- return 0;
- }
-
- if (!smi_is_done(msp)) {
- wait_event_timeout(msp->smi_busy_wait, smi_is_done(msp),
- msecs_to_jiffies(100));
- if (!smi_is_done(msp))
- return -ETIMEDOUT;
- }
-
- return 0;
-}
-
-static int smi_bus_read(struct mii_bus *bus, int addr, int reg)
-{
- struct mv643xx_eth_shared_private *msp = bus->priv;
- void __iomem *smi_reg = msp->base + SMI_REG;
- int ret;
-
- if (smi_wait_ready(msp)) {
- pr_warn("SMI bus busy timeout\n");
- return -ETIMEDOUT;
- }
-
- writel(SMI_OPCODE_READ | (reg << 21) | (addr << 16), smi_reg);
-
- if (smi_wait_ready(msp)) {
- pr_warn("SMI bus busy timeout\n");
- return -ETIMEDOUT;
- }
-
- ret = readl(smi_reg);
- if (!(ret & SMI_READ_VALID)) {
- pr_warn("SMI bus read not valid\n");
- return -ENODEV;
- }
-
- return ret & 0xffff;
-}
-
-static int smi_bus_write(struct mii_bus *bus, int addr, int reg, u16 val)
-{
- struct mv643xx_eth_shared_private *msp = bus->priv;
- void __iomem *smi_reg = msp->base + SMI_REG;
-
- if (smi_wait_ready(msp)) {
- pr_warn("SMI bus busy timeout\n");
- return -ETIMEDOUT;
- }
-
- writel(SMI_OPCODE_WRITE | (reg << 21) |
- (addr << 16) | (val & 0xffff), smi_reg);
-
- if (smi_wait_ready(msp)) {
- pr_warn("SMI bus busy timeout\n");
- return -ETIMEDOUT;
- }
-
- return 0;
-}
-
-
/* statistics ***************************************************************/
static struct net_device_stats *mv643xx_eth_get_stats(struct net_device *dev)
{
@@ -2611,47 +2492,6 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
goto out_free;
/*
- * Set up and register SMI bus.
- */
- if (pd == NULL || pd->shared_smi == NULL) {
- msp->smi_bus = mdiobus_alloc();
- if (msp->smi_bus == NULL)
- goto out_unmap;
-
- msp->smi_bus->priv = msp;
- msp->smi_bus->name = "mv643xx_eth smi";
- msp->smi_bus->read = smi_bus_read;
- msp->smi_bus->write = smi_bus_write,
- snprintf(msp->smi_bus->id, MII_BUS_ID_SIZE, "%s-%d",
- pdev->name, pdev->id);
- msp->smi_bus->parent = &pdev->dev;
- msp->smi_bus->phy_mask = 0xffffffff;
- if (mdiobus_register(msp->smi_bus) < 0)
- goto out_free_mii_bus;
- msp->smi = msp;
- } else {
- msp->smi = platform_get_drvdata(pd->shared_smi);
- }
-
- msp->err_interrupt = NO_IRQ;
- init_waitqueue_head(&msp->smi_busy_wait);
-
- /*
- * Check whether the error interrupt is hooked up.
- */
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (res != NULL) {
- int err;
-
- err = request_irq(res->start, mv643xx_eth_err_irq,
- IRQF_SHARED, "mv643xx_eth", msp);
- if (!err) {
- writel(ERR_INT_SMI_DONE, msp->base + ERR_INT_MASK);
- msp->err_interrupt = res->start;
- }
- }
-
- /*
* (Re-)program MBUS remapping windows if we are asked to.
*/
dram = mv_mbus_dram_info();
@@ -2666,10 +2506,6 @@ static int mv643xx_eth_shared_probe(struct platform_device *pdev)
return 0;
-out_free_mii_bus:
- mdiobus_free(msp->smi_bus);
-out_unmap:
- iounmap(msp->base);
out_free:
kfree(msp);
out:
@@ -2679,14 +2515,7 @@ out:
static int mv643xx_eth_shared_remove(struct platform_device *pdev)
{
struct mv643xx_eth_shared_private *msp = platform_get_drvdata(pdev);
- struct mv643xx_eth_shared_platform_data *pd = pdev->dev.platform_data;
- if (pd == NULL || pd->shared_smi == NULL) {
- mdiobus_unregister(msp->smi_bus);
- mdiobus_free(msp->smi_bus);
- }
- if (msp->err_interrupt != NO_IRQ)
- free_irq(msp->err_interrupt, msp);
iounmap(msp->base);
kfree(msp);
@@ -2752,11 +2581,11 @@ static void set_params(struct mv643xx_eth_private *mp,
static struct phy_device *phy_scan(struct mv643xx_eth_private *mp,
int phy_addr)
{
- struct mii_bus *bus = mp->shared->smi->smi_bus;
struct phy_device *phydev;
int start;
int num;
int i;
+ char phy_id[MII_BUS_ID_SIZE + 3];
if (phy_addr == MV643XX_ETH_PHY_ADDR_DEFAULT) {
start = phy_addr_get(mp) & 0x1f;
@@ -2766,17 +2595,19 @@ static struct phy_device *phy_scan(struct mv643xx_eth_private *mp,
num = 1;
}
+ /* Attempt to connect to the PHY using orion-mdio */
phydev = NULL;
for (i = 0; i < num; i++) {
int addr = (start + i) & 0x1f;
- if (bus->phy_map[addr] == NULL)
- mdiobus_scan(bus, addr);
+ snprintf(phy_id, sizeof(phy_id), PHY_ID_FMT,
+ "orion-mdio-mii", addr);
- if (phydev == NULL) {
- phydev = bus->phy_map[addr];
- if (phydev != NULL)
- phy_addr_set(mp, addr);
+ phydev = phy_connect(mp->dev, phy_id, NULL,
+ PHY_INTERFACE_MODE_GMII);
+ if (!IS_ERR(phydev)) {
+ phy_addr_set(mp, addr);
+ break;
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/5] net: mvmdio: allow Device Tree and platform device to coexist
From: Florian Fainelli @ 2013-01-29 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-1-git-send-email-florian@openwrt.org>
This patch changes the Marvell MDIO driver to be registered by using
both Device Tree and platform device methods. The driver voluntarily
does not use devm_ioremap() to share the same error path for Device Tree
and non-Device Tree cases.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
drivers/net/ethernet/marvell/mvmdio.c | 46 +++++++++++++++++++++++----------
1 file changed, 33 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index cada794..10c593c 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -190,6 +190,7 @@ static irqreturn_t orion_mdio_err_irq(int irq, void *dev_id)
static int orion_mdio_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
+ struct resource *r = NULL;
struct mii_bus *bus;
struct orion_mdio_dev *dev;
int i, ret;
@@ -219,18 +220,31 @@ static int orion_mdio_probe(struct platform_device *pdev)
bus->irq[i] = PHY_POLL;
dev = bus->priv;
- dev->regs = of_iomap(pdev->dev.of_node, 0);
- if (!dev->regs) {
- dev_err(&pdev->dev, "No SMI register address given in DT\n");
- kfree(bus->irq);
- mdiobus_free(bus);
- return -ENODEV;
- }
-
dev->err_interrupt = NO_IRQ;
init_waitqueue_head(&dev->smi_busy_wait);
- dev->err_interrupt = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ if (pdev->dev.of_node) {
+ dev->regs = of_iomap(pdev->dev.of_node, 0);
+ if (!dev->regs) {
+ dev_err(&pdev->dev, "No SMI register address given in DT\n");
+ ret = -ENODEV;
+ goto out_free;
+ }
+
+ dev->err_interrupt = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ } else {
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ dev->regs = ioremap(r->start, resource_size(r));
+ if (!dev->regs) {
+ dev_err(&pdev->dev, "No SMI register address given\n");
+ ret = -ENODEV;
+ goto out_free;
+ }
+
+ dev->err_interrupt = platform_get_irq(pdev, 0);
+ }
+
if (dev->err_interrupt != NO_IRQ) {
ret = devm_request_irq(&pdev->dev, dev->err_interrupt,
orion_mdio_err_irq,
@@ -242,18 +256,24 @@ static int orion_mdio_probe(struct platform_device *pdev)
mutex_init(&dev->lock);
- ret = of_mdiobus_register(bus, np);
+ if (np)
+ ret = of_mdiobus_register(bus, np);
+ else
+ ret = mdiobus_register(bus);
if (ret < 0) {
dev_err(&pdev->dev, "Cannot register MDIO bus (%d)\n", ret);
iounmap(dev->regs);
- kfree(bus->irq);
- mdiobus_free(bus);
- return ret;
+ goto out_free;
}
platform_set_drvdata(pdev, bus);
return 0;
+
+out_free:
+ kfree(bus->irq);
+ mdiobus_free(bus);
+ return ret;
}
static int orion_mdio_remove(struct platform_device *pdev)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/5] net: mvmdio: enhance driver to support SMI error/done interrupts
From: Florian Fainelli @ 2013-01-29 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-1-git-send-email-florian@openwrt.org>
This patch enhances the "mvmdio" to support a SMI error/done interrupt
line which can be used along with a wait queue instead of doing
busy-waiting on the registers. This is a feature which is available in
the mv643xx_eth SMI code and thus reduces again the gap between the two.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
.../devicetree/bindings/net/marvell-orion-mdio.txt | 3 +
drivers/net/ethernet/marvell/mvmdio.c | 83 +++++++++++++++++---
2 files changed, 75 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 34e7aaf..052b5f2 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -9,6 +9,9 @@ Required properties:
- compatible: "marvell,orion-mdio"
- reg: address and length of the SMI register
+Optional properties:
+- interrupts: interrupt line number for the SMI error/done interrupt
+
The child nodes of the MDIO driver are the individual PHY devices
connected to this MDIO bus. They must have a "reg" property given the
PHY address on the MDIO bus.
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 5ecda58..cada794 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -24,10 +24,14 @@
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/phy.h>
+#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of_mdio.h>
+#include <linux/of_irq.h>
#include <linux/platform_device.h>
#include <linux/delay.h>
+#include <linux/sched.h>
+#include <linux/wait.h>
#define MVMDIO_SMI_DATA_SHIFT 0
#define MVMDIO_SMI_PHY_ADDR_SHIFT 16
@@ -36,12 +40,28 @@
#define MVMDIO_SMI_WRITE_OPERATION 0
#define MVMDIO_SMI_READ_VALID BIT(27)
#define MVMDIO_SMI_BUSY BIT(28)
+#define MVMDIO_ERR_INT_CAUSE 0x007C
+#define MVMDIO_ERR_INT_SMI_DONE 0x00000010
+#define MVMDIO_ERR_INT_MASK 0x0080
struct orion_mdio_dev {
struct mutex lock;
void __iomem *regs;
+ /*
+ * If we have access to the error interrupt pin (which is
+ * somewhat misnamed as it not only reflects internal errors
+ * but also reflects SMI completion), use that to wait for
+ * SMI access completion instead of polling the SMI busy bit.
+ */
+ int err_interrupt;
+ wait_queue_head_t smi_busy_wait;
};
+static int orion_mdio_smi_is_done(struct orion_mdio_dev *dev)
+{
+ return !(readl(dev->regs) & MVMDIO_SMI_BUSY);
+}
+
/* Wait for the SMI unit to be ready for another operation
*/
static int orion_mdio_wait_ready(struct mii_bus *bus)
@@ -50,19 +70,30 @@ static int orion_mdio_wait_ready(struct mii_bus *bus)
int count;
u32 val;
- count = 0;
- while (1) {
- val = readl(dev->regs);
- if (!(val & MVMDIO_SMI_BUSY))
- break;
-
- if (count > 100) {
- dev_err(bus->parent, "Timeout: SMI busy for too long\n");
- return -ETIMEDOUT;
+ if (dev->err_interrupt == NO_IRQ) {
+ count = 0;
+ while (1) {
+ val = readl(dev->regs);
+ if (!(val & MVMDIO_SMI_BUSY))
+ break;
+
+ if (count > 100) {
+ dev_err(bus->parent,
+ "Timeout: SMI busy for too long\n");
+ return -ETIMEDOUT;
+ }
+
+ udelay(10);
+ count++;
}
+ }
- udelay(10);
- count++;
+ if (!orion_mdio_smi_is_done(dev)) {
+ wait_event_timeout(dev->smi_busy_wait,
+ orion_mdio_smi_is_done(dev),
+ msecs_to_jiffies(100));
+ if (!orion_mdio_smi_is_done(dev))
+ return -ETIMEDOUT;
}
return 0;
@@ -141,6 +172,21 @@ static int orion_mdio_reset(struct mii_bus *bus)
return 0;
}
+static irqreturn_t orion_mdio_err_irq(int irq, void *dev_id)
+{
+ struct orion_mdio_dev *dev = dev_id;
+
+ if (readl(dev->regs + MVMDIO_ERR_INT_CAUSE) &
+ MVMDIO_ERR_INT_SMI_DONE) {
+ writel(~MVMDIO_ERR_INT_SMI_DONE,
+ dev->regs + MVMDIO_ERR_INT_CAUSE);
+ wake_up(&dev->smi_busy_wait);
+ return IRQ_HANDLED;
+ }
+
+ return IRQ_NONE;
+}
+
static int orion_mdio_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -181,6 +227,19 @@ static int orion_mdio_probe(struct platform_device *pdev)
return -ENODEV;
}
+ dev->err_interrupt = NO_IRQ;
+ init_waitqueue_head(&dev->smi_busy_wait);
+
+ dev->err_interrupt = irq_of_parse_and_map(pdev->dev.of_node, 0);
+ if (dev->err_interrupt != NO_IRQ) {
+ ret = devm_request_irq(&pdev->dev, dev->err_interrupt,
+ orion_mdio_err_irq,
+ IRQF_SHARED, pdev->name, dev);
+ if (!ret)
+ writel(MVMDIO_ERR_INT_SMI_DONE,
+ dev->regs + MVMDIO_ERR_INT_MASK);
+ }
+
mutex_init(&dev->lock);
ret = of_mdiobus_register(bus, np);
@@ -202,6 +261,8 @@ static int orion_mdio_remove(struct platform_device *pdev)
struct mii_bus *bus = platform_get_drvdata(pdev);
struct orion_mdio_dev *dev = bus->priv;
+ writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
+ free_irq(dev->err_interrupt, dev);
mdiobus_unregister(bus);
kfree(bus->irq);
mdiobus_free(bus);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/5] net: mvmdio: rename base register cookie from smireg to regs
From: Florian Fainelli @ 2013-01-29 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-1-git-send-email-florian@openwrt.org>
This patch renames the base register cookie in the mvmdio drive from
"smireg" to "regs" since a subsequent patch is going to use an ioremap()
cookie whose size is larger than a single register of 4 bytes. No
functionnal code change introduced.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
drivers/net/ethernet/marvell/mvmdio.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index be5c690..5ecda58 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -39,7 +39,7 @@
struct orion_mdio_dev {
struct mutex lock;
- void __iomem *smireg;
+ void __iomem *regs;
};
/* Wait for the SMI unit to be ready for another operation
@@ -52,7 +52,7 @@ static int orion_mdio_wait_ready(struct mii_bus *bus)
count = 0;
while (1) {
- val = readl(dev->smireg);
+ val = readl(dev->regs);
if (!(val & MVMDIO_SMI_BUSY))
break;
@@ -87,12 +87,12 @@ static int orion_mdio_read(struct mii_bus *bus, int mii_id,
writel(((mii_id << MVMDIO_SMI_PHY_ADDR_SHIFT) |
(regnum << MVMDIO_SMI_PHY_REG_SHIFT) |
MVMDIO_SMI_READ_OPERATION),
- dev->smireg);
+ dev->regs);
/* Wait for the value to become available */
count = 0;
while (1) {
- val = readl(dev->smireg);
+ val = readl(dev->regs);
if (val & MVMDIO_SMI_READ_VALID)
break;
@@ -129,7 +129,7 @@ static int orion_mdio_write(struct mii_bus *bus, int mii_id,
(regnum << MVMDIO_SMI_PHY_REG_SHIFT) |
MVMDIO_SMI_WRITE_OPERATION |
(value << MVMDIO_SMI_DATA_SHIFT)),
- dev->smireg);
+ dev->regs);
mutex_unlock(&dev->lock);
@@ -173,8 +173,8 @@ static int orion_mdio_probe(struct platform_device *pdev)
bus->irq[i] = PHY_POLL;
dev = bus->priv;
- dev->smireg = of_iomap(pdev->dev.of_node, 0);
- if (!dev->smireg) {
+ dev->regs = of_iomap(pdev->dev.of_node, 0);
+ if (!dev->regs) {
dev_err(&pdev->dev, "No SMI register address given in DT\n");
kfree(bus->irq);
mdiobus_free(bus);
@@ -186,7 +186,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
ret = of_mdiobus_register(bus, np);
if (ret < 0) {
dev_err(&pdev->dev, "Cannot register MDIO bus (%d)\n", ret);
- iounmap(dev->smireg);
+ iounmap(dev->regs);
kfree(bus->irq);
mdiobus_free(bus);
return ret;
@@ -205,7 +205,7 @@ static int orion_mdio_remove(struct platform_device *pdev)
mdiobus_unregister(bus);
kfree(bus->irq);
mdiobus_free(bus);
- iounmap(dev->smireg);
+ iounmap(dev->regs);
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/5] net: mvmdio: unmap base register address at driver removal
From: Florian Fainelli @ 2013-01-29 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-1-git-send-email-florian@openwrt.org>
Fix the driver remove callback to unmap the base register address and
not leak this mapping after the driver has been removed.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
drivers/net/ethernet/marvell/mvmdio.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 74f1c15..be5c690 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -200,9 +200,12 @@ static int orion_mdio_probe(struct platform_device *pdev)
static int orion_mdio_remove(struct platform_device *pdev)
{
struct mii_bus *bus = platform_get_drvdata(pdev);
+ struct orion_mdio_dev *dev = bus->priv;
+
mdiobus_unregister(bus);
kfree(bus->irq);
mdiobus_free(bus);
+ iounmap(dev->smireg);
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/5] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli @ 2013-01-29 15:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver
instead of rolling its own implementation. As a result, all users of this
mv643xx_eth driver are converted to register an "orion-mdio" platform_device.
The mvmdio driver is also updated to support an interrupt line which reports
SMI error/completion, and to allow traditionnal platform device registration
instead of just device tree.
David, I think it makes sense for you to merge all of this, since we do
not want the architecture files to be desynchronized from the mv643xx_eth to
avoid runtime breakage. The potential for merge conflicts should be very small.
You can probably safely merge patches 1 to 4 if Thomas agrees, and we will
see what kind of feeback I get on patch 5.
Florian Fainelli (5):
net: mvmdio: unmap base register address at driver removal
net: mvmdio: rename base register cookie from smireg to regs
net: mvmdio: enhance driver to support SMI error/done interrupts
net: mvmdio: allow Device Tree and platform device to coexist
mv643xx_eth: convert to use the Marvell Orion MDIO driver
.../devicetree/bindings/net/marvell-orion-mdio.txt | 3 +
arch/arm/plat-orion/common.c | 84 +++++++--
arch/powerpc/platforms/chrp/pegasos_eth.c | 20 +++
arch/powerpc/sysdev/mv64x60_dev.c | 14 +-
drivers/net/ethernet/marvell/Kconfig | 1 +
drivers/net/ethernet/marvell/mv643xx_eth.c | 187 +-------------------
drivers/net/ethernet/marvell/mvmdio.c | 136 +++++++++++---
7 files changed, 226 insertions(+), 219 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Thomas Petazzoni @ 2013-01-29 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129151501.GY23505@n2100.arm.linux.org.uk>
Russell,
Thanks for your quick feedback!
On Tue, 29 Jan 2013 15:15:01 +0000, Russell King - ARM Linux wrote:
> Given the description, I'd feel much happier with this if we specified
> the alignment numerically rather than allowing "some random code" to do
> something with the passed values.
So, you'd prefer to have two new members added in the hw_pci structure
to give the alignment requirements for I/O regions and memory regions?
Something like:
struct hw_pci {
[...]
unsigned long io_align;
unsigned long mem_align;
};
If that's fine with you, I'll go ahead and change the implementation in
this direction. As long as I can express my special 64 KB alignment
requirement for I/O regions, I'm just fine :-)
Thanks again,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] ARM: imx_v6_v7_defconfig: eanble anatop regulator and snvs rtc
From: Shawn Guo @ 2013-01-29 15:18 UTC (permalink / raw)
To: linux-arm-kernel
Eanble anatop regulator and snvs rtc support which are very useful
for imx6q build.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index 6966713..1d9b9fc6 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -151,6 +151,7 @@ CONFIG_MFD_MC13XXX_I2C=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_DA9052=y
+CONFIG_REGULATOR_ANATOP=y
CONFIG_REGULATOR_MC13783=y
CONFIG_REGULATOR_MC13892=y
CONFIG_MEDIA_SUPPORT=y
@@ -197,6 +198,7 @@ CONFIG_RTC_CLASS=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_DRV_MC13XXX=y
CONFIG_RTC_DRV_MXC=y
+CONFIG_RTC_DRV_SNVS=y
CONFIG_DMADEVICES=y
CONFIG_IMX_SDMA=y
CONFIG_MXS_DMA=y
--
1.7.9.5
^ permalink raw reply related
* [GIT PULL] ARM: mvebu fixes for v3.8-rc6
From: Jason Cooper @ 2013-01-29 15:18 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 09d75bc7d217bd8868899028a98b53423e6b3324:
ARM: kirkwood: fix missing #interrupt-cells property (2013-01-23 01:10:48 +0000)
are available in the git repository at:
git://git.infradead.org/users/jcooper/linux.git tags/mvebu_fixes_for_v3.8-rc6
for you to fetch changes up to de27686b77f1c5c5dddf06d48fd322c52f098d51:
arm: mvebu: i2c come back in defconfig (2013-01-23 15:05:11 +0000)
----------------------------------------------------------------
fixes for v3.8-rc6
- add missing gpio interrupt lines to dove dt
- fix bad logic for printing MPP error message on orion boards
- build proper serial port driver after changing mvebu DT compatible property
- This is a change to mvebu_defconfig that I wouldn't usually push out as a
fix. However, the commit
b24212f arm: mvebu: Use dw-apb-uart instead of ns16650 as UART driver
changed the serial driver for the board in the dts file. without the patch
I've included in this pull, users won't see any log messages.
----------------------------------------------------------------
Gerlando Falauto (1):
arm: plat-orion: fix printing of "MPP config unavailable on this hardware"
Gregory CLEMENT (1):
arm: mvebu: i2c come back in defconfig
Jean-Francois Moine (1):
Dove: activate GPIO interrupts in DT
arch/arm/boot/dts/dove.dtsi | 2 ++
arch/arm/configs/mvebu_defconfig | 2 ++
arch/arm/plat-orion/mpp.c | 2 +-
3 files changed, 5 insertions(+), 1 deletion(-)
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Viresh Kumar @ 2013-01-29 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301291331.48427.arnd@arndb.de>
On 29 January 2013 19:01, Arnd Bergmann <arnd@arndb.de> wrote:
> Ah, good. So I guess the "dma-requests" property should actually
> be "16" then.
yes, even i was checking on that separately :)
> Does this mean that an implicit zero request line means memory?
No. 0 is also request line for a peripheral and numbers are from 0 to 15.
memcpy are identified by setting type of transfer as memcpy.
> Could we have device-to-device DMAs with this controller, and if
> we can, should we have both 'src' and 'dst' fields? Are the
> two number ranges sharing the same address space, i.e. is
> request '7' as the destination guaranteed to be the same device
> as request '7' in the source?
Request lines are per master... So, for a master single request line
is independent of direction. Many DMA controllers have capability of
doing dev-to-dev transfers but DMAENGINE doesn't have any support
for it, even we don't have a usecase too :)
> If we need two lines, we could interleave them with the bus
> master numbers:
not required.
> In theory, we could use bit-stuffing to put them all into
> a single 32 bit word I guess, but generally people don't
> seem to like that for new bindings.
:)
--
viresh
^ permalink raw reply
* [GIT PULL] imx cleanup for 3.9
From: Fabio Estevam @ 2013-01-29 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129151005.GC11345@S2101-09.ap.freescale.net>
On Tue, Jan 29, 2013 at 1:10 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
> On Tue, Jan 29, 2013 at 06:18:57AM -0800, Olof Johansson wrote:
>> Ok. Just to make clear: While I personally prefer the regular way of specifying
>> the board dts files, my main concern with this patch is that it is _pure
>> churn_. It's 1000 lines of change without a functional benefit, and without
>> really being a cleanup that benefits long-term development.
>>
> You can say it's not a cleanup, but it definitely benefits long-term
> development. It makes board dts development a lot easier, and that's
> why I came up with the patch.
I also agree here.
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Russell King - ARM Linux @ 2013-01-29 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129161211.7bb8cada@skate>
On Tue, Jan 29, 2013 at 04:12:11PM +0100, Thomas Petazzoni wrote:
> Russell,
>
> As the arch/arm/kernel/ maintainer, what is your position regarding the
> below patch?
Given the description, I'd feel much happier with this if we specified
the alignment numerically rather than allowing "some random code" to do
something with the passed values.
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Thomas Petazzoni @ 2013-01-29 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359399397-29729-6-git-send-email-thomas.petazzoni@free-electrons.com>
Russell,
As the arch/arm/kernel/ maintainer, what is your position regarding the
below patch?
Thanks for your review,
Thomas
On Mon, 28 Jan 2013 19:56:14 +0100, Thomas Petazzoni wrote:
> The PCI specifications says that an I/O region must be aligned on a 4
> KB boundary, and a memory region aligned on a 1 MB boundary.
>
> However, the Marvell PCIe interfaces rely on address decoding windows
> (which allow to associate a range of physical addresses with a given
> device). For PCIe memory windows, those windows are defined with a 1
> MB granularity (which matches the PCI specs), but PCIe I/O windows can
> only be defined with a 64 KB granularity, so they have to be 64 KB
> aligned. We therefore need to tell the PCI core about this special
> alignement requirement.
>
> The PCI core already calls pcibios_align_resource() in the ARM PCI
> core, specifically for such purposes. So this patch extends the ARM
> PCI core so that it calls a ->align_resource() hook registered by the
> PCI driver, exactly like the existing ->map_irq() and ->swizzle()
> hooks.
>
> A particular PCI driver can register a align_resource() hook, and do
> its own specific alignement, depending on the specific constraints of
> the underlying hardware.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> ---
> arch/arm/include/asm/mach/pci.h | 11 +++++++++++
> arch/arm/kernel/bios32.c | 6 ++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
> index 5cf2e97..7d2c3c8 100644
> --- a/arch/arm/include/asm/mach/pci.h
> +++ b/arch/arm/include/asm/mach/pci.h
> @@ -30,6 +30,11 @@ struct hw_pci {
> void (*postinit)(void);
> u8 (*swizzle)(struct pci_dev *dev, u8 *pin);
> int (*map_irq)(const struct pci_dev *dev, u8 slot, u8 pin);
> + resource_size_t (*align_resource)(struct pci_dev *dev,
> + const struct resource *res,
> + resource_size_t start,
> + resource_size_t size,
> + resource_size_t align);
> };
>
> /*
> @@ -51,6 +56,12 @@ struct pci_sys_data {
> u8 (*swizzle)(struct pci_dev *, u8 *);
> /* IRQ mapping */
> int (*map_irq)(const struct pci_dev *, u8, u8);
> + /* Resource alignement requirements */
> + resource_size_t (*align_resource)(struct pci_dev *dev,
> + const struct resource *res,
> + resource_size_t start,
> + resource_size_t size,
> + resource_size_t align);
> void *private_data; /* platform controller private data */
> };
>
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index 5401645..be2e6c9 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -462,6 +462,7 @@ static void __init pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
> sys->busnr = busnr;
> sys->swizzle = hw->swizzle;
> sys->map_irq = hw->map_irq;
> + sys->align_resource = hw->align_resource;
> INIT_LIST_HEAD(&sys->resources);
>
> if (hw->private_data)
> @@ -574,6 +575,8 @@ char * __init pcibios_setup(char *str)
> resource_size_t pcibios_align_resource(void *data, const struct resource *res,
> resource_size_t size, resource_size_t align)
> {
> + struct pci_dev *dev = data;
> + struct pci_sys_data *sys = dev->sysdata;
> resource_size_t start = res->start;
>
> if (res->flags & IORESOURCE_IO && start & 0x300)
> @@ -581,6 +584,9 @@ resource_size_t pcibios_align_resource(void *data, const struct resource *res,
>
> start = (start + align - 1) & ~(align - 1);
>
> + if (sys->align_resource)
> + return sys->align_resource(dev, res, start, size, align);
> +
> return start;
> }
>
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [RFC] arm: use built-in byte swap function
From: Woodhouse, David @ 2013-01-29 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5107E285.8060304@gmail.com>
On Tue, 2013-01-29 at 08:53 -0600, Rob Herring wrote:
> If you specify to use the builtin's, do you still get inline rev
> instructions emitted?
You mean from the architecture's __arch_swab32() et al. macros?
No. If the architecture enables ARCH_USE_BUILTIN_BSWAP and the compiler
version checks indicate that the correspondingly-sized builtin is
available, then the builtin will be used. Only if the arch *doesn't* set
ARCH_USE_BUILTIN_BSWAP, or if the compiler is old enough not to have the
corresponding intrinsic, will the inline assembler in the __arch_swabXX
macros get used.
Note, however, that there is no such compiler intrinsic for swahb32(),
which is where rev16 gets used. That's still being left to the inline
asm in all cases.
--
Sent with MeeGo's ActiveSync support.
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4370 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/cac8d645/attachment.bin>
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-29 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129150201.GA24101@avionic-0098.mockup.avionic-design.de>
Dear Thierry Reding,
On Tue, 29 Jan 2013 16:02:01 +0100, Thierry Reding wrote:
> Now that I think about it, there were a few more changes needed.
> For one, the reg property of the root port nodes need to be in the
> format specified by the PCI DT binding. That is, 3 cells for the
> address and 2 cells for the size.
>
> So I end up with something like this:
>
> pcie-controller {
> ...
>
> ranges = <0x00000800 0 0x80000000 0x80000000 0 0x00001000 /* port 0 registers */
> 0x00001000 0 0x80001000 0x80001000 0 0x00001000 /* port 1 registers */
> ...>;
>
> pci at 1,0 {
> reg = <0x000800 0 0x80000000 0 0x1000>;
> ...
> };
>
> pci at 2,0 {
> reg = <0x001000 0 0x80001000 0 0x1000>;
> ...
> };
> };
>
> So what happens here is that for each root port (pci at 1,0 and pci at 2,0),
> the reg property is translated into the parent address space via the
> pcie-controller's ranges property. pci at 1,0 gets the memory region
> 0x80000000-0x80000fff and pci at 2,0 gets 0x80001000-0x80001fff. (These are
> actually windows through which the configuration space of the root ports
> is accessed.)
>
> At the same time this reg property maps both devices into the PCI
> address space at addresses 0:01.0 and 0:02.0 respectively.
This part I think I've done exactly the same thing in the Marvell PCIe
DT binding.
> The second change is that you can't rely on ARM's default implementation
> of the bus scan operation, which calls pci_scan_root_bus(), passing in a
> NULL as the struct device which acts as the bus' parent. So on Tegra I
> added a custom implementation which calls pci_create_root_bus(), passing
> in the struct device of the PCI host bridge, whose .of_node field will
> be set to the pcie-controller node above. Incidentally this also fixed
> another issue where the PCI core and ARM's pci_common_init() both
> eventually end up calling pci_bus_add_devices(). I don't remember the
> exact symptoms but I think this was causing resource conflicts during
> the second enumeration or so.
>
> Because a proper struct device with the correct .of_node field is passed
> into pci_create_root_bus(), the generic pcibios_get_phb_of_node() will
> know how to find it by looking at bus->bridge->parent->of_node. After
> that the generic matching code will search the bridge (pcie-controller)
> node's children and relate them to the struct pci_dev by devfn. This is
> done in pci_set_of_node() defined in drivers/pci/of.c, which calls
> of_pci_find_child_device() from drivers/of/of_pci.c.
This is quite certainly the part that I was missing. I'll try this and
let you know.
Thanks a lot for the lengthy, but very useful explanation!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL] imx cleanup for 3.9
From: Shawn Guo @ 2013-01-29 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129141857.GA12723@quad.lixom.net>
On Tue, Jan 29, 2013 at 06:18:57AM -0800, Olof Johansson wrote:
> Ok. Just to make clear: While I personally prefer the regular way of specifying
> the board dts files, my main concern with this patch is that it is _pure
> churn_. It's 1000 lines of change without a functional benefit, and without
> really being a cleanup that benefits long-term development.
>
You can say it's not a cleanup, but it definitely benefits long-term
development. It makes board dts development a lot easier, and that's
why I came up with the patch.
> We're starting to get more comments about the volume of churn again (Linus made
> a couple of them the last merge window), and I'd rather be a bit more
> conservative on some of the larger changes that lack strong benefit for
> a release or two, than have him get ticked off and make life miserable for all
> of us.
>
> So, I'm not saying that it's a bad idea to change to labels, but I would rather
> hold off this while we give some of the remaining platforms still not
> multiplatform-enabled a chance to "use the churn quota" since they will need it
> for include file moves, etc, etc.
>
Then it will hold off the while IMX device tree development. All the
patches I queued on imx/dt branch are all based on that. While it
looks like a "churn", it should not cause any conflict, as all IMX
dts changes will go via the same branch for this cycle. So please
give it a go to avoid hurting people who contribute IMX device tree
development.
Shawn
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox