* [RFC PATCH 0/2] ARM: update cpuinfo to print CPU model name
From: Rob Herring @ 2013-01-29 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359474865-15408-1-git-send-email-ruslan.bilovol@ti.com>
On 01/29/2013 09:54 AM, Ruslan Bilovol wrote:
> Hi,
>
> The following patches update cpuinfo to print CPU
> model name for ARM. First patch exactly makes needed
> changes for ARM architecture.
> Second patch adds this ability to OMAP4 SoCs.
>
> This adds a common approach to show SoC name.
>
> Looks like there were few attempts to do similar
> changes to cpuinfo without any luck.
Care to point out how your solution is different from those or addresses
the issues with them.
Assuming we want to do this, I think this information should come from
DeviceTree. OMAP may have this in a register, but others don't.
Rob
>
> So - comments are welcome
>
> Ruslan Bilovol (2):
> ARM: kernel: update cpuinfo to print CPU model name
> ARM: OMAP4: setup CPU model name during ID initialisation
>
> arch/arm/include/asm/setup.h | 1 +
> arch/arm/kernel/setup.c | 10 ++++++++++
> arch/arm/mach-omap2/id.c | 18 ++++++++++++++++--
> 3 files changed, 27 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* [PATCH] serial: pl010/pl011: move clk_enable from console write to setup
From: Russell King - ARM Linux @ 2013-01-29 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359475526-17523-1-git-send-email-walimisdev@gmail.com>
On Wed, Jan 30, 2013 at 12:05:26AM +0800, Liming Wang wrote:
> There seems no need to call clk_enable in every console writing. And we
> can move clk_enable to setup function to enable the clock only once.
> Also combine the clk_enable and clk_prepare to clk_prepare_enable.
NAK. Just Nak.
^ permalink raw reply
* [RFC PATCH 1/2] ARM: kernel: update cpuinfo to print CPU model name
From: Russell King - ARM Linux @ 2013-01-29 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359474865-15408-2-git-send-email-ruslan.bilovol@ti.com>
On Tue, Jan 29, 2013 at 05:54:24PM +0200, Ruslan Bilovol wrote:
> CPU implementer : 0x41
> CPU name : OMAP4470 ES1.0 HS
Sigh. No. Look at what you're doing - look carefully at the above.
"CPU implementer" - 0x41. That's A. For ARM Ltd. ARM Ltd implemented
this CPU. Did ARM Ltd really implement OMAP4470 ? I think TI would be
very upset if that were to be the case.
So no, OMAP4470 is _NOT_ a CPU. It is a SoC. The CPU inside the SoC is
a collection of ARM Ltd Cortex A9 _CPUs_.
See? Please, learn what a CPU is as opposed to a SoC.
^ permalink raw reply
* [PATCH] serial: pl010/pl011: move clk_enable from console write to setup
From: Liming Wang @ 2013-01-29 16:05 UTC (permalink / raw)
To: linux-arm-kernel
There seems no need to call clk_enable in every console writing. And we
can move clk_enable to setup function to enable the clock only once.
Also combine the clk_enable and clk_prepare to clk_prepare_enable.
Signed-off-by: Liming Wang <walimisdev@gmail.com>
---
drivers/tty/serial/amba-pl010.c | 6 +-----
drivers/tty/serial/amba-pl011.c | 6 +-----
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/amba-pl010.c b/drivers/tty/serial/amba-pl010.c
index 22317dd..9b77188 100644
--- a/drivers/tty/serial/amba-pl010.c
+++ b/drivers/tty/serial/amba-pl010.c
@@ -569,8 +569,6 @@ pl010_console_write(struct console *co, const char *s, unsigned int count)
struct uart_amba_port *uap = amba_ports[co->index];
unsigned int status, old_cr;
- clk_enable(uap->clk);
-
/*
* First save the CR then disable the interrupts
*/
@@ -588,8 +586,6 @@ pl010_console_write(struct console *co, const char *s, unsigned int count)
barrier();
} while (status & UART01x_FR_BUSY);
writel(old_cr, uap->port.membase + UART010_CR);
-
- clk_disable(uap->clk);
}
static void __init
@@ -639,7 +635,7 @@ static int __init pl010_console_setup(struct console *co, char *options)
if (!uap)
return -ENODEV;
- ret = clk_prepare(uap->clk);
+ ret = clk_prepare_enable(uap->clk);
if (ret)
return ret;
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7fca402..53aafd4 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1777,8 +1777,6 @@ pl011_console_write(struct console *co, const char *s, unsigned int count)
unsigned long flags;
int locked = 1;
- clk_enable(uap->clk);
-
local_irq_save(flags);
if (uap->port.sysrq)
locked = 0;
@@ -1809,8 +1807,6 @@ pl011_console_write(struct console *co, const char *s, unsigned int count)
if (locked)
spin_unlock(&uap->port.lock);
local_irq_restore(flags);
-
- clk_disable(uap->clk);
}
static void __init
@@ -1876,7 +1872,7 @@ static int __init pl011_console_setup(struct console *co, char *options)
"could not set default pins\n");
}
- ret = clk_prepare(uap->clk);
+ ret = clk_prepare_enable(uap->clk);
if (ret)
return ret;
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 0/2] ARM: update cpuinfo to print CPU model name
From: Nishanth Menon @ 2013-01-29 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359474865-15408-1-git-send-email-ruslan.bilovol@ti.com>
On 17:54-20130129, Ruslan Bilovol wrote:
> Hi,
>
> The following patches update cpuinfo to print CPU
> model name for ARM. First patch exactly makes needed
> changes for ARM architecture.
> Second patch adds this ability to OMAP4 SoCs.
>
> This adds a common approach to show SoC name.
>
> Looks like there were few attempts to do similar
> changes to cpuinfo without any luck.
>
> So - comments are welcome
>
> Ruslan Bilovol (2):
> ARM: kernel: update cpuinfo to print CPU model name
> ARM: OMAP4: setup CPU model name during ID initialisation
We had an discussion on similar lines but a generic suggestion:
https://patchwork.kernel.org/patch/98720/
SoCinfo framework which was supposed to introduce this
Would'nt that be a better approach to take than an OMAP only solution?
Ccying eduardo who had driven this for some time.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 09/30] USB: ehci-omap: Use devm_request_and_ioremap()
From: Russell King - ARM Linux @ 2013-01-29 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1301291033000.1507-100000@iolanthe.rowland.org>
On Tue, Jan 29, 2013 at 10:34:53AM -0500, Alan Stern wrote:
> 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.
It may be in linux-next, but it isn't in Linus' yet... (of course, it's
probably scheduled for the upcoming merge window). Certainly:
$ grep -r devm_ioremap_resource include
against Linus' tree (6abb7c2) still turns up nothing.
^ permalink raw reply
* [PATCH 5/5] mv643xx_eth: convert to use the Marvell Orion MDIO driver
From: Thomas Petazzoni @ 2013-01-29 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-6-git-send-email-florian@openwrt.org>
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:08 +0100, Florian Fainelli wrote:
> 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 +++++++++++--
In this file, there was one "MV643XX_ETH_SHARED_NAME" platform_device
registered for each network interface. Why? If the driver is shared,
isn't the whole idea to register it only once?
In any case, one of the idea of separating the mvmdio driver from the
mvneta driver in the first place is that there should be only one
instance of the mvmdio device, even if there are multiple network
interfaces. The reason is that from a HW point of the view, the MDIO
unit is shared between the network interfaces. If you look at
armada-370-xp.dtsi, there is only one mvmdio device registered, and two
network interfaces (using the mvneta driver) that are registered (and
actually up to four network interfaces can exist, they are added by
some other .dtsi files depending on the specific SoC).
So I don't think there should be one instance of the mvmdio per network
interface.
Also, I am wondering what's left in this MV643XX_ETH_SHARED_NAME driver
once the MDIO stuff has been pulled out in a separate driver? I think
the whole point of this work should be to get rid of this
MV643XX_ETH_SHARED_NAME driver, no?
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 v2 05/27] arm: pci: add a align_resource hook
From: Russell King - ARM Linux @ 2013-01-29 15:58 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:
> 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.
BTW, this, as a general statement, is wrong - though it really depends
what you mean by "region".
Remember that BARs can be set where-ever provided that they satisify
their _individual_ alignment requirements. So, an IO bar which
occupies 16 bytes must be set to a 16-byte boundary.
Now, there's an additional complication there which occurs if you have
ISA devices sharing the PCI IO space: ISA devices used to only decode
10 bits of IO space, which means that their registers repeat throughout
the IO space.
Therefore, it is generally accepted that within any 1K block, only the
first 256 locations are only usable.
Moreover, some PCI cards have taken advantage of this, particularly VGA
cards. For example, S3 VGA cards put different registers on 1K
multiples of the standard PC VGA IO addresses...
Also, another reason why I suspect your statement is wrong if I were
to interpret "region" as "BAR" is that consider a bunch of PCI peripherals
behind a PCI bridge. The total number of IO BARs on the peripherals
is 16.
If you allocate each of those IO BARs to be 4K aligned, then you
consume all 64K of IO space behind one bridge, which leaves no space
for any other IO peripherals elsewhere in the bus structure.
Last reason I think that intepretation is wrong is, on this PC, I see:
Region 4: I/O ports at 1800 [size=8]
Region 0: I/O ports at 1830 [size=8]
Region 2: I/O ports at 1840 [size=32]
Region 4: I/O ports at 1860 [size=32]
Region 4: I/O ports at 1880 [size=32]
Region 4: I/O ports at 18a0 [size=32]
Region 4: I/O ports at 18c0 [size=32]
Region 4: I/O ports at 18e0 [size=32]
Region 4: I/O ports at 1c00 [size=32]
Region 0: I/O ports at 1c48 [size=8]
Region 1: I/O ports at 183c [size=4]
Region 2: I/O ports at 1c40 [size=8]
Region 3: I/O ports at 1838 [size=4]
Region 4: I/O ports at 1c20 [size=32]
Region 4: I/O ports at 1c60 [size=32]
which doesn't follow - and I can pull out other examples on other
x86 platforms where IO BARs aren't aligned to 4K...
^ permalink raw reply
* [RFC PATCH 2/2] ARM: OMAP4: setup CPU model name during ID initialisation
From: Ruslan Bilovol @ 2013-01-29 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359474865-15408-1-git-send-email-ruslan.bilovol@ti.com>
Set up the CPU model name during OMAP ID initialisation
so it will be displayed in /proc/cpuinfo:
/ # cat proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 10 (v7l)
BogoMIPS : 1590.23
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls
CPU implementer : 0x41
CPU name : OMAP4470 ES1.0 HS
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 10
[...]
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
---
arch/arm/mach-omap2/id.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 45cc7ed4..d1416e9 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -20,6 +20,7 @@
#include <linux/io.h>
#include <asm/cputype.h>
+#include <asm/setup.h>
#include "common.h"
@@ -33,8 +34,17 @@
static unsigned int omap_revision;
static const char *cpu_rev;
+static char omap_cpu_model_name[80];
u32 omap_features;
+static const char const *omap_types[] = {
+ [OMAP2_DEVICE_TYPE_TEST] = "TST",
+ [OMAP2_DEVICE_TYPE_EMU] = "EMU",
+ [OMAP2_DEVICE_TYPE_SEC] = "HS",
+ [OMAP2_DEVICE_TYPE_GP] = "GP",
+ [OMAP2_DEVICE_TYPE_BAD] = "BAD",
+};
+
unsigned int omap_rev(void)
{
return omap_revision;
@@ -502,8 +512,12 @@ void __init omap4xxx_check_revision(void)
omap_revision = OMAP4430_REV_ES2_3;
}
- pr_info("OMAP%04x ES%d.%d\n", omap_rev() >> 16,
- ((omap_rev() >> 12) & 0xf), ((omap_rev() >> 8) & 0xf));
+ sprintf(omap_cpu_model_name, "OMAP%04x ES%d.%d %s", omap_rev() >> 16,
+ ((omap_rev() >> 12) & 0xf), ((omap_rev() >> 8) & 0xf),
+ omap_types[omap_type()]);
+ set_cpu_model_name(omap_cpu_model_name);
+
+ pr_info("%s\n", omap_cpu_model_name);
}
void __init omap5xxx_check_revision(void)
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 1/2] ARM: kernel: update cpuinfo to print CPU model name
From: Ruslan Bilovol @ 2013-01-29 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359474865-15408-1-git-send-email-ruslan.bilovol@ti.com>
Currently, reading /proc/cpuinfo provides userspace with CPU ID of
the CPU carrying out the read from the file.
Userspace using this information may decide what module
to load or how to configure some specific (and processor-depended)
settings or so.
However, since really different SoCs can share same ARM core,
this information currently is not so useful.
For example, TI OMAP4460 and OMAP4470 SoCs show the same
information in the /proc/cpuinfo whereas they are different.
The "cpuinfo" file looks like exactly that place, where
This information have to be displayed.
So added new line "CPU name" in the "cpuinfo" output for CPU model name
Example:
/ # cat proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 10 (v7l)
BogoMIPS : 1590.23
Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls
CPU implementer : 0x41
CPU name : OMAP4470 ES1.0 HS
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 10
[...]
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
---
arch/arm/include/asm/setup.h | 1 +
arch/arm/kernel/setup.c | 10 ++++++++++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index c50f056..f49de38 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -52,5 +52,6 @@ extern struct meminfo meminfo;
extern int arm_add_memory(phys_addr_t start, phys_addr_t size);
extern void early_print(const char *str, ...);
extern void dump_machine_table(void);
+extern void set_cpu_model_name(char *name);
#endif
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..6fab2e2 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -134,6 +134,7 @@ char elf_platform[ELF_PLATFORM_SIZE];
EXPORT_SYMBOL(elf_platform);
static const char *cpu_name;
+static const char *cpu_model_name;
static const char *machine_name;
static char __initdata cmd_line[COMMAND_LINE_SIZE];
struct machine_desc *machine_desc __initdata;
@@ -493,6 +494,11 @@ static void __init setup_processor(void)
cpu_init();
}
+void set_cpu_model_name(char *name)
+{
+ cpu_model_name = name;
+}
+
void __init dump_machine_table(void)
{
struct machine_desc *p;
@@ -880,6 +886,10 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, "%s ", hwcap_str[j]);
seq_printf(m, "\nCPU implementer\t: 0x%02x\n", cpuid >> 24);
+
+ if (cpu_model_name)
+ seq_printf(m, "CPU name\t: %s\n", cpu_model_name);
+
seq_printf(m, "CPU architecture: %s\n",
proc_arch[cpu_architecture()]);
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 0/2] ARM: update cpuinfo to print CPU model name
From: Ruslan Bilovol @ 2013-01-29 15:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The following patches update cpuinfo to print CPU
model name for ARM. First patch exactly makes needed
changes for ARM architecture.
Second patch adds this ability to OMAP4 SoCs.
This adds a common approach to show SoC name.
Looks like there were few attempts to do similar
changes to cpuinfo without any luck.
So - comments are welcome
Ruslan Bilovol (2):
ARM: kernel: update cpuinfo to print CPU model name
ARM: OMAP4: setup CPU model name during ID initialisation
arch/arm/include/asm/setup.h | 1 +
arch/arm/kernel/setup.c | 10 ++++++++++
arch/arm/mach-omap2/id.c | 18 ++++++++++++++++--
3 files changed, 27 insertions(+), 2 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 2/2] ARM: imx_v6_v7_defconfig: Add VPU support
From: Fabio Estevam @ 2013-01-29 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359474553-8949-1-git-send-email-fabio.estevam@freescale.com>
Let the VPU driver be built by default.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
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..83822d9 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -160,6 +160,8 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_SOC_CAMERA=y
CONFIG_SOC_CAMERA_OV2640=y
CONFIG_VIDEO_MX3=y
+CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_VIDEO_CODA=y
CONFIG_FB=y
CONFIG_LCD_PLATFORM=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] ARM: imx_v4_v5_defconfig: Add VPU support
From: Fabio Estevam @ 2013-01-29 15:49 UTC (permalink / raw)
To: linux-arm-kernel
Let the VPU driver be built by default.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/configs/imx_v4_v5_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/imx_v4_v5_defconfig b/arch/arm/configs/imx_v4_v5_defconfig
index ebbfb27..10f78e5 100644
--- a/arch/arm/configs/imx_v4_v5_defconfig
+++ b/arch/arm/configs/imx_v4_v5_defconfig
@@ -127,6 +127,8 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_SOC_CAMERA=y
CONFIG_SOC_CAMERA_OV2640=y
CONFIG_VIDEO_MX2=y
+CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_VIDEO_CODA=y
CONFIG_FB=y
CONFIG_FB_IMX=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/5] net: mvmdio: allow Device Tree and platform device to coexist
From: Thomas Petazzoni @ 2013-01-29 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-5-git-send-email-florian@openwrt.org>
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:07 +0100, Florian Fainelli wrote:
> 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.
Not sure why you think devm_ioremap() can't be used here. Maybe I'm
missing something, but could you explain? If you use devm_ioremap(),
then basically you don't need to do anything in the error path
regarding to the I/O mapping... since it's the whole purpose of the
devm_*() stuff to automagically undo things in the error case, and in
the ->remove() code.
> - 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);
> + }
I think you can do a devm_ioremap() and a platform_get_irq() in both
cases here, and therefore keep the code common between the DT case and
the !DT case.
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 V3 5/5] DTS: Add device tree entry for onewire master on i.MX53
From: Martin Fuzzey @ 2013-01-29 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129154608.5184.46101.stgit@localhost>
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
---
arch/arm/boot/dts/imx53.dtsi | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index edc3f1e..00c957c 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -387,6 +387,14 @@
};
};
+ owire {
+ pinctrl_owire_1: owiregrp-1 {
+ fsl,pins = <
+ 1166 0x80000000 /* MX53_PAD_GPIO_18__OWIRE_LINE */
+ >;
+ };
+ };
+
uart1 {
pinctrl_uart1_1: uart1grp-1 {
fsl,pins = <
@@ -570,6 +578,13 @@
status = "disabled";
};
+ owire: owire@63fa4000 {
+ compatible = "fsl,imx53-owire", "fsl,imx21-owire";
+ reg = <0x63fa4000 0x4000>;
+ clocks = <&clks 159>;
+ status = "disabled";
+ };
+
ecspi2: ecspi at 63fac000 {
#address-cells = <1>;
#size-cells = <0>;
^ permalink raw reply related
* [PATCH V3 4/5] W1: Add pinctrl support to MXC onewire master.
From: Martin Fuzzey @ 2013-01-29 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129154608.5184.46101.stgit@localhost>
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
---
drivers/w1/masters/mxc_w1.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c
index 317b2bc..48afc2c 100644
--- a/drivers/w1/masters/mxc_w1.c
+++ b/drivers/w1/masters/mxc_w1.c
@@ -24,6 +24,7 @@
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/io.h>
+#include <linux/pinctrl/consumer.h>
#include "../w1.h"
#include "../w1_int.h"
@@ -107,6 +108,7 @@ static int mxc_w1_probe(struct platform_device *pdev)
{
struct mxc_w1_device *mdev;
struct resource *res;
+ struct pinctrl *pinctrl;
int err = 0;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -117,6 +119,13 @@ static int mxc_w1_probe(struct platform_device *pdev)
if (!mdev)
return -ENOMEM;
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl)) {
+ err = PTR_ERR(pinctrl);
+ dev_err(&pdev->dev, "failed to get default pinctrl: %d\n", err);
+ goto failed_pin;
+ }
+
mdev->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(mdev->clk)) {
err = PTR_ERR(mdev->clk);
@@ -152,6 +161,7 @@ failed_add:
failed_req:
failed_clk:
+failed_pin:
kfree(mdev);
return err;
}
^ permalink raw reply related
* [PATCH V3 3/5] W1: Convert MXC onewire master to devm_ functions.
From: Martin Fuzzey @ 2013-01-29 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129154608.5184.46101.stgit@localhost>
While doing this fix missing clk_disable_unprepare in error path.
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
---
drivers/w1/masters/mxc_w1.c | 26 ++++++--------------------
1 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c
index 949e566..317b2bc 100644
--- a/drivers/w1/masters/mxc_w1.c
+++ b/drivers/w1/masters/mxc_w1.c
@@ -117,7 +117,7 @@ static int mxc_w1_probe(struct platform_device *pdev)
if (!mdev)
return -ENOMEM;
- mdev->clk = clk_get(&pdev->dev, NULL);
+ mdev->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(mdev->clk)) {
err = PTR_ERR(mdev->clk);
goto failed_clk;
@@ -125,17 +125,11 @@ static int mxc_w1_probe(struct platform_device *pdev)
mdev->clkdiv = (clk_get_rate(mdev->clk) / 1000000) - 1;
- res = request_mem_region(res->start, resource_size(res),
- "mxc_w1");
- if (!res) {
- err = -EBUSY;
- goto failed_req;
- }
-
- mdev->regs = ioremap(res->start, resource_size(res));
+ mdev->regs = devm_request_and_ioremap(&pdev->dev, res);
if (!mdev->regs) {
dev_err(&pdev->dev, "Cannot map mxc_w1 registers\n");
- goto failed_ioremap;
+ err = -ENXIO;
+ goto failed_req;
}
clk_prepare_enable(mdev->clk);
@@ -154,11 +148,9 @@ static int mxc_w1_probe(struct platform_device *pdev)
return 0;
failed_add:
- iounmap(mdev->regs);
-failed_ioremap:
- release_mem_region(res->start, resource_size(res));
+ clk_disable_unprepare(mdev->clk);
+
failed_req:
- clk_put(mdev->clk);
failed_clk:
kfree(mdev);
return err;
@@ -170,16 +162,10 @@ failed_clk:
static int mxc_w1_remove(struct platform_device *pdev)
{
struct mxc_w1_device *mdev = platform_get_drvdata(pdev);
- struct resource *res;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
w1_remove_master_device(&mdev->bus_master);
- iounmap(mdev->regs);
- release_mem_region(res->start, resource_size(res));
clk_disable_unprepare(mdev->clk);
- clk_put(mdev->clk);
platform_set_drvdata(pdev, NULL);
^ permalink raw reply related
* [PATCH V3 2/5] ARM: i.MX53: Add clocks for i.mx53 onewire master.
From: Martin Fuzzey @ 2013-01-29 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129154608.5184.46101.stgit@localhost>
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
---
.../devicetree/bindings/clock/imx5-clock.txt | 1 +
arch/arm/mach-imx/clk-imx51-imx53.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt
index 04ad478..2a0c904 100644
--- a/Documentation/devicetree/bindings/clock/imx5-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt
@@ -171,6 +171,7 @@ clocks and IDs.
can_sel 156
can1_serial_gate 157
can1_ipg_gate 158
+ owire_gate 159
Examples (for mx53):
diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index 579023f..7ff293b 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -83,6 +83,7 @@ enum imx5_clks {
ssi2_root_gate, ssi3_root_gate, ssi_ext1_gate, ssi_ext2_gate,
epit1_ipg_gate, epit1_hf_gate, epit2_ipg_gate, epit2_hf_gate,
can_sel, can1_serial_gate, can1_ipg_gate,
+ owire_gate,
clk_max
};
@@ -233,12 +234,13 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
clk[epit1_hf_gate] = imx_clk_gate2("epit1_hf_gate", "per_root", MXC_CCM_CCGR2, 4);
clk[epit2_ipg_gate] = imx_clk_gate2("epit2_ipg_gate", "ipg", MXC_CCM_CCGR2, 6);
clk[epit2_hf_gate] = imx_clk_gate2("epit2_hf_gate", "per_root", MXC_CCM_CCGR2, 8);
+ clk[owire_gate] = imx_clk_gate2("owire_gate", "per_root", MXC_CCM_CCGR2, 22);
for (i = 0; i < ARRAY_SIZE(clk); i++)
if (IS_ERR(clk[i]))
pr_err("i.MX5 clk %d: register failed with %ld\n",
i, PTR_ERR(clk[i]));
-
+
clk_register_clkdev(clk[gpt_hf_gate], "per", "imx-gpt.0");
clk_register_clkdev(clk[gpt_ipg_gate], "ipg", "imx-gpt.0");
clk_register_clkdev(clk[uart1_per_gate], "per", "imx21-uart.0");
^ permalink raw reply related
* [PATCH V3 1/5] W1: Add device tree support to MXC onewire master.
From: Martin Fuzzey @ 2013-01-29 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129154608.5184.46101.stgit@localhost>
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
---
.../devicetree/bindings/w1/fsl-imx-owire.txt | 20 ++++++++++++++++++++
drivers/w1/masters/mxc_w1.c | 9 ++++++++-
2 files changed, 28 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/w1/fsl-imx-owire.txt
diff --git a/Documentation/devicetree/bindings/w1/fsl-imx-owire.txt b/Documentation/devicetree/bindings/w1/fsl-imx-owire.txt
new file mode 100644
index 0000000..b6d53b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/w1/fsl-imx-owire.txt
@@ -0,0 +1,20 @@
+* Freescale i.MX One wire bus master controller
+
+Required properties:
+- compatible : should be "fsl,imx21-owire"
+- reg : Address and length of the register set for the device
+
+Optional properties:
+- clocks : phandle of clock that supplies the module (required if platform
+ clock bindings use device tree)
+
+Example:
+
+- From imx53.dtsi:
+owire: owire at 63fa4000 {
+ compatible = "fsl,imx53-owire", "fsl,imx21-owire";
+ reg = <0x63fa4000 0x4000>;
+ clocks = <&clks 159>;
+ status = "disabled";
+};
+
diff --git a/drivers/w1/masters/mxc_w1.c b/drivers/w1/masters/mxc_w1.c
index 708a25f..949e566 100644
--- a/drivers/w1/masters/mxc_w1.c
+++ b/drivers/w1/masters/mxc_w1.c
@@ -186,9 +186,16 @@ static int mxc_w1_remove(struct platform_device *pdev)
return 0;
}
+static struct of_device_id mxc_w1_dt_ids[] = {
+ { .compatible = "fsl,imx21-owire" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, mxc_w1_dt_ids);
+
static struct platform_driver mxc_w1_driver = {
.driver = {
- .name = "mxc_w1",
+ .name = "mxc_w1",
+ .of_match_table = mxc_w1_dt_ids,
},
.probe = mxc_w1_probe,
.remove = mxc_w1_remove,
^ permalink raw reply related
* [PATCH V3 0/5] W1: Support onewire master on i.MX53
From: Martin Fuzzey @ 2013-01-29 15:46 UTC (permalink / raw)
To: linux-arm-kernel
W1: Support onewire master on i.MX53
* Add device tree and pinctrl support to the MXC master driver
* Convert to use devm_
* Add i.MX53 clocks
* Add i.MX53 device tree entries
Changes since V2
* Add documentation on device tree binding
* Add Acked-bys from Sascha and Evgeniy
Changes since V1
* Applied comments from Sascha Hauer:
* Move patch converting driver to devm_ before the one adding devm_ based pinctrl
* Fix existing unbalanced clk_prepare_enable/clk_disable_unprepare
in probe error path
* Place DT patch last since it includes pinctrls for driver.
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Russell King - ARM Linux @ 2013-01-29 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301291455.49347.arnd@arndb.de>
On Tue, Jan 29, 2013 at 02:55:49PM +0000, Arnd Bergmann wrote:
> On Tuesday 29 January 2013, Russell King - ARM Linux wrote:
> > No, that's not what I mean. I mean the situation we find on Versatile
> > platforms:
> >
> > 8 3 >3
> > PL080 DMA --/--+--/------> FPGA Mux --/--> {bunch of off-CPU peripherals}
> > | 5
> > `--/------> {On-CPU peripherals}
> >
> > This is something that I've been raising _every time_ I've been involved
> > with DMA engine discussions when it comes to the matching stuff, so this
> > is nothing new, and it's not unknown about.
>
> Ok, I see. I have not actually been involved with the DMA engine API
> much, so for me it's the first time /I/ see this being explained.
>
> From the DT binding perspective, doing this should be no problem. I guess
> you would model the MUX as a trivial dma engine device that forwards to
> another one, just like we do for nested interrupt controllers:
>
> pl080: dma-engine at 10000000 {
> compatible ="arm,pl080", "arm,primecell";
> reg = <0x10000000 0x1000>;
> dma-requests = <8>;
> dma-channels = <4>;
> #dma-cells = <2>;
> };
>
> fpga {
> mux: dma-mux at f0008000 {
> reg = <0xf0008000 100>;
> compatible = "arm,versatile-fpga-dmamux";
> dma-requests = <7>;
> dma-channels = <3>;
> #dma-cells = <1>;
> dmas = <&pl080 5 0>, <&pl080 6 0> <&pl080 7 0>;
> dma-names = "mux5", "mux6", "mux7";
> };
> ...
>
> some-device at f000a000 {
> compatible = "foo,using-muxed-dma";
> dmas = <&mux 3>, <&mux 4>;
> dma-names = "rx", "tx";
> };
> };
>
> The driver for foo,using-muxed-dma just requests a slave channel for its
> lines, which ends up calling the xlate function of the driver for the mux.
> That driver still needs to get written, of course, but it should be able
> to recursively call dma_request_slave_channel on the pl080 device.
> The arm,versatile-fpga-dmamux driver would not be registered to the dmaengine
> layer, but it would register as an of_dma_controller.
That's a good way to represent it but it fails in a very big way:
You're stuffing N peripherals down to 3 request lines to the DMA
engine, and you may want more than 3 of those peripherals to be
making use of the DMA engine at any one time.
Before anyone says "you shouldn't be doing this" consider this:
your typical DMA slave engine already has this structure:
N DMA channels <---> M DMA requests <---> M peripherals
where N < M. In other words, there is _already_ a MUX between the
peripherals and the DMA engine channels themselves (what do you think
the "request index" which you have to program into DMA channel control
registers is doing...
We support this external mux today in the PL080 driver - and we do that
by having the PL080 driver do the scheduling of virtual DMA channels on
the actual hardware itself. The PL080 driver has knowledge that there
may be some sort of additional muxing layer between it and the
peripheral.
As the APIs stand today, you just can't do this without having the
DMA engine driver itself intimately involved because a layer above
doesn't really have much clue as to what's going on, and the DMA
engine stuff itself doesn't layer particularly well.
^ permalink raw reply
* [PATCH v3 07/15] ARM: vexpress: Select the correct SMP operations at run-time
From: Jon Medhurst (Tixy) @ 2013-01-29 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359445870-18925-8-git-send-email-nicolas.pitre@linaro.org>
On Tue, 2013-01-29 at 02:51 -0500, Nicolas Pitre wrote:
> From: Jon Medhurst <tixy@linaro.org>
>
> Signed-off-by: Jon Medhurst <tixy@linaro.org>
> ---
Should this patch be split into two. One to introduce the new smp_init
hook into the generic ARM kernel code, and one to make vexpress use it?
With, descriptions something like:
-----------------------------------------------------------------------
ARM: kernel: Enable selection of SMP operations at boot time
Add a new 'smp_init' hook to machine_desc so platforms can specify a
function to be used to setup smp ops instead of having a statically
defined value.
-----------------------------------------------------------------------
ARM: vexpress: Select multi-cluster SMP operation if required
-----------------------------------------------------------------------
--
Tixy
> arch/arm/include/asm/mach/arch.h | 3 +++
> arch/arm/kernel/setup.c | 5 ++++-
> arch/arm/mach-vexpress/core.h | 2 ++
> arch/arm/mach-vexpress/platsmp.c | 12 ++++++++++++
> arch/arm/mach-vexpress/v2m.c | 2 +-
> 5 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
> index 917d4fcfd9..3d01c6d6c3 100644
> --- a/arch/arm/include/asm/mach/arch.h
> +++ b/arch/arm/include/asm/mach/arch.h
> @@ -17,8 +17,10 @@ struct pt_regs;
> struct smp_operations;
> #ifdef CONFIG_SMP
> #define smp_ops(ops) (&(ops))
> +#define smp_init_ops(ops) (&(ops))
> #else
> #define smp_ops(ops) (struct smp_operations *)NULL
> +#define smp_init_ops(ops) (void (*)(void))NULL
> #endif
>
> struct machine_desc {
> @@ -42,6 +44,7 @@ struct machine_desc {
> unsigned char reserve_lp2 :1; /* never has lp2 */
> char restart_mode; /* default restart mode */
> struct smp_operations *smp; /* SMP operations */
> + void (*smp_init)(void);
> void (*fixup)(struct tag *, char **,
> struct meminfo *);
> void (*reserve)(void);/* reserve mem blocks */
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 3f6cbb2e3e..41edca8582 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -768,7 +768,10 @@ void __init setup_arch(char **cmdline_p)
> arm_dt_init_cpu_maps();
> #ifdef CONFIG_SMP
> if (is_smp()) {
> - smp_set_ops(mdesc->smp);
> + if(mdesc->smp_init)
> + (*mdesc->smp_init)();
> + else
> + smp_set_ops(mdesc->smp);
> smp_init_cpus();
> }
> #endif
> diff --git a/arch/arm/mach-vexpress/core.h b/arch/arm/mach-vexpress/core.h
> index f134cd4a85..3a761fd76c 100644
> --- a/arch/arm/mach-vexpress/core.h
> +++ b/arch/arm/mach-vexpress/core.h
> @@ -6,6 +6,8 @@
>
> void vexpress_dt_smp_map_io(void);
>
> +void vexpress_smp_init_ops(void);
> +
> extern struct smp_operations vexpress_smp_ops;
>
> extern void vexpress_cpu_die(unsigned int cpu);
> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
> index c5d70de9bb..667344b479 100644
> --- a/arch/arm/mach-vexpress/platsmp.c
> +++ b/arch/arm/mach-vexpress/platsmp.c
> @@ -12,6 +12,7 @@
> #include <linux/errno.h>
> #include <linux/smp.h>
> #include <linux/io.h>
> +#include <linux/of.h>
> #include <linux/of_fdt.h>
> #include <linux/vexpress.h>
>
> @@ -206,3 +207,14 @@ struct smp_operations __initdata vexpress_smp_ops = {
> .cpu_die = vexpress_cpu_die,
> #endif
> };
> +
> +void __init vexpress_smp_init_ops(void)
> +{
> + struct smp_operations *ops = &vexpress_smp_ops;
> +#ifdef CONFIG_CLUSTER_PM
> + extern struct smp_operations mcpm_smp_ops;
> + if(of_find_compatible_node(NULL, NULL, "arm,cci"))
> + ops = &mcpm_smp_ops;
> +#endif
> + smp_set_ops(ops);
> +}
> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> index 011661a6c5..34172bd504 100644
> --- a/arch/arm/mach-vexpress/v2m.c
> +++ b/arch/arm/mach-vexpress/v2m.c
> @@ -494,7 +494,7 @@ static const char * const v2m_dt_match[] __initconst = {
>
> DT_MACHINE_START(VEXPRESS_DT, "ARM-Versatile Express")
> .dt_compat = v2m_dt_match,
> - .smp = smp_ops(vexpress_smp_ops),
> + .smp_init = smp_init_ops(vexpress_smp_init_ops),
> .map_io = v2m_dt_map_io,
> .init_early = v2m_dt_init_early,
> .init_irq = v2m_dt_init_irq,
^ permalink raw reply
* [PATCH 3/5] net: mvmdio: enhance driver to support SMI error/done interrupts
From: Thomas Petazzoni @ 2013-01-29 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359473048-26551-4-git-send-email-florian@openwrt.org>
Dear Florian Fainelli,
On Tue, 29 Jan 2013 16:24:06 +0100, Florian Fainelli wrote:
> #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;
What about using your new orion_mdio_smi_is_done() function here?
> +
> + 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)) {
Maybe it should be in an else if block so that the waitqueue case is
only considered if there is an IRQ registered? Of course practically
speaking, it's OK because if there is no IRQ, we'll wait in the polling
loop above, and either exit from the function on timeout, or continue
on success. But it still would make the code a little bit clearer, I'd
say.
> 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;
Not needed, you already do dev->err_interrupt = something() below.
> + 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);
free_irq() not needed since the IRQ handler is registered with
devm_request_irq().
> mdiobus_unregister(bus);
> kfree(bus->irq);
> mdiobus_free(bus);
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 v1 1/5] ARM: cache-l2x0: add 'smc' identifier
From: Tomasz Figa @ 2013-01-29 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129101328.GA11878@bnru10>
Hi Srinidhi,
On Tuesday 29 of January 2013 15:43:31 srinidhi kasagar wrote:
> Add 'smc' (Secure Monitor Call) identifier to differentiates
> the platforms which implements this.
>
> Signed-off-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
> ---
> arch/arm/boot/dts/omap4.dtsi | 1 +
> arch/arm/include/asm/hardware/cache-l2x0.h | 2 +-
> arch/arm/mach-cns3xxx/core.c | 4 ++--
> arch/arm/mach-exynos/common.c | 4 ++--
> arch/arm/mach-imx/mm-imx3.c | 4 ++--
> arch/arm/mach-nomadik/cpu-8815.c | 4 ++--
> arch/arm/mach-omap2/omap4-common.c | 2 +-
> arch/arm/mach-realview/realview_eb.c | 4 ++--
> arch/arm/mach-realview/realview_pb1176.c | 4 ++--
> arch/arm/mach-realview/realview_pb11mp.c | 4 ++--
> arch/arm/mach-realview/realview_pbx.c | 4 ++--
> arch/arm/mach-shmobile/board-ag5evm.c | 2 +-
> arch/arm/mach-shmobile/board-armadillo800eva.c | 4 ++--
> arch/arm/mach-shmobile/board-bonito.c | 4 ++--
> arch/arm/mach-shmobile/board-kota2.c | 4 ++--
> arch/arm/mach-shmobile/board-kzm9g.c | 4 ++--
> arch/arm/mach-shmobile/setup-r8a7779.c | 4 ++--
> arch/arm/mach-spear13xx/spear13xx.c | 2 +-
> arch/arm/mach-ux500/cache-l2x0.c | 2 +-
> arch/arm/mach-vexpress/ct-ca9x4.c | 2 +-
> arch/arm/mm/cache-l2x0.c | 18
> ++++++++++++++---- 21 files changed, 47 insertions(+), 36 deletions(-)
I'd recommend you to take a look at this series:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/202224/
It's already queued up for 3.9 in Samsung tree and most likely provides an
interface needed for what you want to achieve.
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
SW Solution Development, Linux Platform
^ permalink raw reply
* [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
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