* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Cooper @ 2013-01-27 15:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51053F81.6020904@gmail.com>
On Sun, Jan 27, 2013 at 03:53:53PM +0100, Sebastian Hesselbarth wrote:
> On 01/27/2013 03:46 PM, Jason Cooper wrote:
> >>I _cannot_ confirm that gbe is loosing its MAC address on Dove. I will
> >>post a follow-up patch to Jason's cleanup patches that will also
> >>grab a clock for smi. With that patch insmod'ing/rmmod'ing mv643xx_eth
> >>does work just fine here on Dove.
> >
> >I believe Simon's issue is that the mv643xx_eth driver is not loaded at
> >boot, it's clocks get gated, then when he loads the driver, there is no
> >mac address. Is that correct Simon? I don't think unloading the driver
> >after boot will trigger this regression.
>
> Loading and unloading the driver module hangs because of the missing
> clk_prepeare_enable in shared driver part. This should be fixed by the
> patch I sent you.
>
> Dove and Kirkwood have the same gbe internally and I can boot into Dove
> without mv643xx_eth, load, unload, reload the module and it always finds
> its MAC address.
>
> I just want Simon to confirm that Kirkwood's gbe is really loosing the
> contents of its MAC address registers during gated clocks, which is from
> a HW point of view very unlikely.
Ok, I just wanted to make sure we understood his problem correctly, and
if possible, reproduce it.
Simon, can you give us some steps to reproduce this on our side so we
can see exactly what's happening?
thx,
Jason.
^ permalink raw reply
* [RFC V2 PATCH 3/8] ARM: kirkwood: nsa310: cleanup includes and unneeded code
From: Jason Cooper @ 2013-01-27 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51054219.1020004@mvista.com>
On Sun, Jan 27, 2013 at 07:04:57PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 27-01-2013 0:22, Jason Cooper wrote:
>
> >>>Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> >>>---
> >>> arch/arm/mach-kirkwood/board-nsa310.c | 9 +--------
> >>> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> >>>diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
> >>>index 1bd328d..0b99533 100644
> >>>--- a/arch/arm/mach-kirkwood/board-nsa310.c
> >>>+++ b/arch/arm/mach-kirkwood/board-nsa310.c
> >>>@@ -10,11 +10,8 @@
> >>>
> >>> #include <linux/kernel.h>
> >>> #include <linux/init.h>
> >>>-#include <linux/i2c.h>
> >>>-
> >>>-#include <asm/mach-types.h>
> >>>-#include <asm/mach/arch.h>
> >>> #include <mach/kirkwood.h>
> >>>+#include <linux/of.h>
>
> >> You also add an #include and don't mention it anywhere. Or is
> >>that part of the cleanup?
>
> >After removing the unneeded linux/i2c.h, linux/of.h was needed for
> >of_machine_is_compatible(). i2c.h had included of.h.
>
> Would be worth mentioning it in the changelog.
Ok, I'll add it when I pull it in.
thx,
Jason.
^ permalink raw reply
* [PATCH] clk: mvebu: Do not gate ge0/1 and runit clocks on Kirkwood
From: Andrew Lunn @ 2013-01-27 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51050B9E.8000605@gmail.com>
> Except for loosing the MAC address, I disagree. From a "clock gating"
> point-of-view all kirkwoods (except that crippled one on keymile board)
> are the same. Even if there is no/one/two ethernet _jacks_ on a specific
> board you still want to disable all _unused_ ethernet modules inside the
> SoC.
>
> We should find a way to retain the MAC address and in the meantime we
> can add a "always prepare ge clocks" workaround in
> kirkwood_clk_legacy_init().
Hi Sebastian
I've been thinking the same, store the MAC address before turning the
clock off and restore it when enabling the clock. We have a need for
special clocks on kirkwood anyway for turning off the sata and pcie
PHYs. So adding special clocks for ethernet is not too big a deal.
Andrew
^ permalink raw reply
* [PATCH V4 10/11] ARM: kirkwood: mv643xx_eth dt conversion
From: Jason Cooper @ 2013-01-27 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51052E6C.1020102@gmail.com>
On Sun, Jan 27, 2013 at 02:41:00PM +0100, Sebastian Hesselbarth wrote:
> On 01/26/2013 09:50 PM, Jason Cooper wrote:
> >Tested on the dreamplug:
> >
> >mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
> >libphy: mv643xx_eth smi: probed
> >libphy: mv643xx_eth smi: probed
> >mv643xx_eth_port f1072000.egiga0 eth0: port 0 with MAC address XX:XX:XX...
> >mv643xx_eth_port f1076000.egiga1 eth1: port 0 with MAC address XX:XX:XX...
> >
> >Successfully pulled an ip address and pinged through the interface
> >
> >...
> >
> >diff --git a/arch/arm/boot/dts/kirkwood.dtsi b/arch/arm/boot/dts/kirkwood.dtsi
> >index 2c738d9..b13a405 100644
> >--- a/arch/arm/boot/dts/kirkwood.dtsi
> >+++ b/arch/arm/boot/dts/kirkwood.dtsi
> >@@ -201,5 +201,43 @@
> > clocks =<&gate_clk 4>;
> > status = "disabled";
> > };
> >+
> >+ smi0: mdio at 72000 {
> >+ compatible = "marvell,mdio-mv643xx";
> >+ reg =<0x72000 0x4000>;
> >+ interrupts =<46>;
> >+ tx_csum_limit =<1600>;
> >+ status = "disabled";
> >+ };
> >+
> >+ smi1: mdio at 76000 {
> >+ compatible = "marvell,mdio-mv643xx";
> >+ reg =<0x76000 0x4000>;
> >+ interrupts =<47>;
> >+ tx_csum_limit =<1600>;
> >+ status = "disabled";
> >+ };
> >+
> >+ egiga0 {
> >+ compatible = "marvell,mv643xx-eth";
> >+ reg =<0x72000 0x4000>;
> >+ mdio =<&smi0>;
> >+ port_number =<0>;
> >+ phy_addr =<0x80>;
>
> Jason,
>
> This will break phy_scan on all kirkwood boards as 0x80 is _not_ equal
> MV643XX_ETH_PHY_ADDR_DEFAULT.
Good point.
> I suggest not to set phy_addr in kirkwood.dtsi at all and let the
> board specific DT files set the phy addresses (or rely on phy_scan if not
> set).
>
> Also, you are ORing the address passed by phy_addr with 0x80 anyway. So
> all phy addresses should be passed as <0> or <1> instead the ORed ones.
agreed. I'll make the changes for V5.
thanks for the review.
Jason.
^ permalink raw reply
* [PATCH] clk: mvebu: Do not gate ge0/1 and runit clocks on Kirkwood
From: Sebastian Hesselbarth @ 2013-01-27 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127152837.GI29973@lunn.ch>
On 01/27/2013 04:28 PM, Andrew Lunn wrote:
>> Except for loosing the MAC address, I disagree. From a "clock gating"
>> point-of-view all kirkwoods (except that crippled one on keymile board)
>> are the same. Even if there is no/one/two ethernet _jacks_ on a specific
>> board you still want to disable all _unused_ ethernet modules inside the
>> SoC.
>>
>> We should find a way to retain the MAC address and in the meantime we
>> can add a "always prepare ge clocks" workaround in
>> kirkwood_clk_legacy_init().
>
> I've been thinking the same, store the MAC address before turning the
> clock off and restore it when enabling the clock. We have a need for
> special clocks on kirkwood anyway for turning off the sata and pcie
> PHYs. So adding special clocks for ethernet is not too big a deal.
Andrew,
if Simon confirms that gbe is really loosing its MAC address when
clocks get gated, I still think that we should rely on other mechanisms
to get a valid MAC address.
Have a look at other DT ethernet drivers, they use local-mac-address
property to pass MAC address from boot loader. IMHO that is what we
should exploit on mv643xx_eth, too.
If the property is set on boot, we can store it in some private data.
If it is not set because some legacy u-boot without DT, we can rely
on what is in the MAC address registers and just call modular eth
on those platforms broken. If the easy fix is to update u-boot or
compile it as built-in we shouldn't care at all. Without proper DT
in u-boot you will always have a board specific kernel anyway.
Sebastian
^ permalink raw reply
* [PATCH] clk: mvebu: Do not gate ge0/1 and runit clocks on Kirkwood
From: Thomas Petazzoni @ 2013-01-27 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127152837.GI29973@lunn.ch>
Dear Andrew Lunn,
On Sun, 27 Jan 2013 16:28:37 +0100, Andrew Lunn wrote:
> I've been thinking the same, store the MAC address before turning the
> clock off and restore it when enabling the clock. We have a need for
> special clocks on kirkwood anyway for turning off the sata and pcie
> PHYs. So adding special clocks for ethernet is not too big a deal.
At least on Armada 370/XP, U-Boot passes the MAC address through a
special ATAG. Willy Tarreau has written some code to read this special
ATAG and feed it into the Device Tree, so that we get the MAC address
as set by U-Boot. I unfortunately haven't had the time to look at
Willy's code and push it, but it does seem like an interesting solution.
Are you interested?
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 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Andrew Lunn @ 2013-01-27 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpomWM41MhRjdhFixy-ELXc6QjE0BhCAHfTzovOD0CBPoOQ@mail.gmail.com>
On Sun, Jan 27, 2013 at 08:19:56PM +0530, Viresh Kumar wrote:
> On 27 January 2013 15:37, Andrew Lunn <andrew@lunn.ch> wrote:
> > diff --git a/drivers/cpufreq/kirkwood-cpufreq.c b/drivers/cpufreq/kirkwood-cpufreq.c
> > +static void kirkwood_cpufreq_set_cpu_state(unsigned int index)
> > +{
>
> > + if (freqs.old != freqs.new) {
>
> > + switch (state) {
> > + case STATE_CPU_FREQ:
> > + clk_disable(priv.powersave_clk);
> > + break;
> > + case STATE_DDR_FREQ:
> > + clk_enable(priv.powersave_clk);
> > + break;
> > + default:
> > + WARN_ON(1);
>
> I still don't feel this case is required :)
O.K, i will take it out.
> > +static struct platform_driver kirkwood_cpufreq_platform_driver = {
> > + .probe = kirkwood_cpufreq_probe,
> > + .remove = kirkwood_cpufreq_remove,
> > + .driver = {
> > + .name = "kirkwood-cpufreq",
> > + .owner = THIS_MODULE,
> > + },
> > +};
>
> Two things. Any reason why you created an extra layer of platform_driver?
> You could have called cpufreq_probe/remove (with names modified) from
> module init/exit.
And how would the module get loaded? There is no hardware anchor to
make the module load. No enumeration of some bus causing it to be
loaded. In the ARM world, platform drivers are the norm.
Andrew
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Viresh Kumar @ 2013-01-27 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127154212.GJ29973@lunn.ch>
On 27 January 2013 21:12, Andrew Lunn <andrew@lunn.ch> wrote:
> And how would the module get loaded? There is no hardware anchor to
> make the module load. No enumeration of some bus causing it to be
> loaded. In the ARM world, platform drivers are the norm.
The way you do it now is by creating a platform device for it in your
arch/arm/mach-* directory. And you are passing an IOMEM resource too.
I believe, normally we don't require any DT node or platform device from
arch/arm/mach-* for cpufreq drivers. This is something which should
always be initialized once it is selected in .config.
Because we will call the _probe() (or renamed as kirkwood_cpufreq_init)
from module_init() now, it will get initialized directly. No need to any
enumeration at all. Now, in case there are multiple values of IOMEM resource
depending on machine type, you can create properties in cpu node. Otherwise
just embed the address directly into driver as nobody else is going to use it.
Makes sense?
--
viresh
^ permalink raw reply
* [kvmarm] [Qemu-devel] [RFC] Virtio-desktop: Virtio-based virtual desktop
From: Alexander Graf @ 2013-01-27 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wquysor6.fsf@codemonkey.ws>
On 27.01.2013, at 15:07, Anthony Liguori wrote:
> Anup Patel <anup.patel@linaro.org> writes:
>
>> Hi All,
>>
>> How about having a generic Virtio-based machine for emulating a virtual
>> desktop ?
>>
>> I know folks have already thought about this and probably also tried
>> something or other on this front but, it will be good to know the downsides.
>>
>> Virtio-desktop can be a separate specification describing a virtual
>> desktop.
>> Of-course we cannot avoid few architecture dependent virtual devices in but
>> the Virtio-desktop specification will try to keep minimum possible
>> architecture dependent devices.
>
> There's a lot of reasons why a pure PV machine type is a bad idea. Lots
> of people have enumerated them in this thread.
>
> But let me mention some things that I think we don't have covered today
> with PV:
>
> - Graphics. Yes, I know QXL exists but it's (a) dependent on PCI (b)
> lacks the ability to gracefully degrade making it hopelessly tied to
> spice.
There was a QXL-on-virtio port in the works a while ago IIRC:
> - Input. PS/2 mouse provides relative input which sucks in guests.
> For absolute input, we have VMMouse which is x86-specific, USB
> tablets (which are expensive to emulate) or the spice mouse which is
> intimately tied to the full Spice stack.
I thought the USB tablet is ok today thanks to auto-suspend of the bus? Or was that only with ehci?
>
> - Guest interaction. Copy/paste, drag and drop, etc. In theory this
> is covered in spice agents but it's all again hopelessly tied to
> Spice which makes it non-portable.
- Keyboard. When running with VNC, the 3 stacks involved in converting keyboard layouts back and forth are really confusing to users.
> So there's good work todo but it's almost certainly in working with the
> Spice community to try to make what they already have more accessible to
> non-x86 architectures.
Hooray :)
Alex
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Andrew Lunn @ 2013-01-27 16:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpomQJfsWBY5o3ep4r86fYYQ39JnMPswjoe8YFT37ekM20w@mail.gmail.com>
On Sun, Jan 27, 2013 at 09:33:04PM +0530, Viresh Kumar wrote:
> On 27 January 2013 21:12, Andrew Lunn <andrew@lunn.ch> wrote:
> > And how would the module get loaded? There is no hardware anchor to
> > make the module load. No enumeration of some bus causing it to be
> > loaded. In the ARM world, platform drivers are the norm.
>
> The way you do it now is by creating a platform device for it in your
> arch/arm/mach-* directory. And you are passing an IOMEM resource too.
>
> I believe, normally we don't require any DT node or platform device from
> arch/arm/mach-* for cpufreq drivers. This is something which should
> always be initialized once it is selected in .config.
What current happens is that most of the drivers use a late_initcall():
linux/drivers/cpufreq$ grep late_initcall *
acpi-cpufreq.c:late_initcall(acpi_cpufreq_init);
cpufreq-cpu0.c:late_initcall(cpu0_cpufreq_driver_init);
exynos-cpufreq.c:late_initcall(exynos_cpufreq_init);
longhaul.c:late_initcall(longhaul_init);
p4-clockmod.c:late_initcall(cpufreq_p4_init);
pcc-cpufreq.c:late_initcall(pcc_cpufreq_init);
powernow-k7.c:late_initcall(powernow_init);
powernow-k8.c:late_initcall(powernowk8_init);
s5pv210-cpufreq.c:late_initcall(s5pv210_cpufreq_init);
spear-cpufreq.c:late_initcall(spear_cpufreq_driver_init);
speedstep-centrino.c:late_initcall(centrino_init);
So when we have a multiplatform kernel with many of these drivers
built in, all but one are going to notice they are not on the hardware
they support, and return -ENODEV.
By making it a platform driver, the kirkwood cpufreq driver will only
get loaded on kirkwood systems, and won't slow down the boot for
everybody else.
Andrew
^ permalink raw reply
* [PATCH] clk: mvebu: Do not gate ge0/1 and runit clocks on Kirkwood
From: Jason Cooper @ 2013-01-27 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127164104.1b2e66e6@skate>
On Sun, Jan 27, 2013 at 04:41:04PM +0100, Thomas Petazzoni wrote:
> Dear Andrew Lunn,
>
> On Sun, 27 Jan 2013 16:28:37 +0100, Andrew Lunn wrote:
>
> > I've been thinking the same, store the MAC address before turning the
> > clock off and restore it when enabling the clock. We have a need for
> > special clocks on kirkwood anyway for turning off the sata and pcie
> > PHYs. So adding special clocks for ethernet is not too big a deal.
>
> At least on Armada 370/XP, U-Boot passes the MAC address through a
> special ATAG. Willy Tarreau has written some code to read this special
> ATAG and feed it into the Device Tree, so that we get the MAC address
> as set by U-Boot. I unfortunately haven't had the time to look at
> Willy's code and push it, but it does seem like an interesting solution.
Does this add on to ARM_ATAG_DTB_COMPAT [1]? Perhaps APPENDED_DTB
should select it?
Maybe the answer is as simple as having the driver pull the mac address
from the dtb while ARM_ATAG_DTB_COMPAT is configured.
thx,
Jason.
[1] arch/arm/Kconfig:1970
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Viresh Kumar @ 2013-01-27 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127162523.GK29973@lunn.ch>
On 27 January 2013 21:55, Andrew Lunn <andrew@lunn.ch> wrote:
> So when we have a multiplatform kernel with many of these drivers
> built in, all but one are going to notice they are not on the hardware
> they support, and return -ENODEV.
>
> By making it a platform driver, the kirkwood cpufreq driver will only
> get loaded on kirkwood systems, and won't slow down the boot for
> everybody else.
I tried to grep platform_driver in drivers/cpufreq/ and got only:
drivers/cpufreq/dbx500-cpufreq.c
Now, the counter argument to your explanation is, multiplatform kernel would be
built only for testing purpose and not for real product. So, even this kind
of delay is really not a big issue. On the other hand with platform driver
too, we will hit lot of other code and would consume some extra memory
for keeping its structures :)
--
viresh
^ permalink raw reply
* [PATCH] ARM: mxs: gpio-mxs: Add IRQ_TYPE_EDGE_BOTH support
From: Gwenhael Goavec-Merou @ 2013-01-27 17:04 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for IRQ_TYPE_EDGE_BOTH needed for some driver
(gpio-keys).
Inspired from gpio-mxc.c
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
---
drivers/gpio/gpio-mxs.c | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpio/gpio-mxs.c b/drivers/gpio/gpio-mxs.c
index fa2a63c..7690eec 100644
--- a/drivers/gpio/gpio-mxs.c
+++ b/drivers/gpio/gpio-mxs.c
@@ -65,6 +65,7 @@ struct mxs_gpio_port {
struct irq_domain *domain;
struct bgpio_chip bgc;
enum mxs_gpio_id devid;
+ u32 both_edges;
};
static inline int is_imx23_gpio(struct mxs_gpio_port *port)
@@ -81,13 +82,24 @@ static inline int is_imx28_gpio(struct mxs_gpio_port *port)
static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type)
{
+ u32 val;
u32 pin_mask = 1 << d->hwirq;
+ u32 gpio_idx = d->hwirq;
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
struct mxs_gpio_port *port = gc->private;
void __iomem *pin_addr;
int edge;
+ port->both_edges &= ~(1 << gpio_idx);
switch (type) {
+ case IRQ_TYPE_EDGE_BOTH:
+ val = gpio_get_value(port->bgc.gc.base + gpio_idx);
+ if (val)
+ edge = GPIO_INT_LOW_LEV;
+ else
+ edge = GPIO_INT_HIGH_LEV;
+ port->both_edges |= 1 << gpio_idx;
+ break;
case IRQ_TYPE_EDGE_RISING:
edge = GPIO_INT_RISE_EDGE;
break;
@@ -123,6 +135,22 @@ static int mxs_gpio_set_irq_type(struct irq_data *d, unsigned int type)
return 0;
}
+static void mxs_flip_edge(struct mxs_gpio_port *port, u32 gpio)
+{
+ u32 bit, val, edge;
+ void __iomem *pin_addr;
+
+ bit = 1<<gpio;
+
+ pin_addr = port->base + PINCTRL_IRQPOL(port);
+ val = readl(pin_addr);
+ edge = val&bit;
+
+ if (edge)
+ writel(bit, pin_addr + MXS_CLR);
+ else
+ writel(bit, pin_addr + MXS_SET);
+}
/* MXS has one interrupt *per* gpio port */
static void mxs_gpio_irq_handler(u32 irq, struct irq_desc *desc)
@@ -137,6 +165,9 @@ static void mxs_gpio_irq_handler(u32 irq, struct irq_desc *desc)
while (irq_stat != 0) {
int irqoffset = fls(irq_stat) - 1;
+ if (port->both_edges & (1 << irqoffset))
+ mxs_flip_edge(port, irqoffset);
+
generic_handle_irq(irq_find_mapping(port->domain, irqoffset));
irq_stat &= ~(1 << irqoffset);
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Russell King - ARM Linux @ 2013-01-27 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359281244-31455-2-git-send-email-andrew@lunn.ch>
On Sun, Jan 27, 2013 at 11:07:22AM +0100, Andrew Lunn wrote:
> +static struct priv
> +{
> + struct clk *cpu_clk;
> + struct clk *ddr_clk;
> + struct clk *powersave_clk;
> + struct device *dev;
> + void __iomem *base;
> +} priv;
I guess you probably think that the compiler will do something special
with this, like reference these all through a base address and offset,
but you'd be wrong there. This is no different from declaring each
as an individual static variable.
> +static unsigned int kirkwood_cpufreq_get_cpu_frequency(unsigned int cpu)
> +{
> + if (__clk_is_enabled(priv.powersave_clk))
This looks to me to be a layering violation.
> +static int kirkwood_cpufreq_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = of_find_compatible_node(
> + NULL, NULL, "marvell,kirkwood-core-clock");
What if np is NULL?
> +
> + struct of_phandle_args clkspec;
> + struct resource *res;
> + int err;
> +
> + priv.dev = &pdev->dev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + dev_err(&pdev->dev, "Cannot get memory resource\n");
> + return -ENODEV;
> + }
> + priv.base = devm_request_and_ioremap(&pdev->dev, res);
> + if (!priv.base) {
> + dev_err(&pdev->dev, "Cannot ioremap\n");
> + return -ENOMEM;
A number of people have been pointing out that the right return value for
this is -EADDRNOTAVAIL as documented against devm_request_and_ioremap().
> + }
> +
> + clkspec.np = np;
> + clkspec.args_count = 1;
> + clkspec.args[0] = 1;
> +
> + priv.cpu_clk = of_clk_get_from_provider(&clkspec);
Oh, yet another way to get clocks...
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Andrew Lunn @ 2013-01-27 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohponWS73JtB3Vwk5bR=+UcT2tfrKsAmHCJEW9DqobkuYgmQ@mail.gmail.com>
On Sun, Jan 27, 2013 at 10:15:18PM +0530, Viresh Kumar wrote:
> On 27 January 2013 21:55, Andrew Lunn <andrew@lunn.ch> wrote:
> > So when we have a multiplatform kernel with many of these drivers
> > built in, all but one are going to notice they are not on the hardware
> > they support, and return -ENODEV.
> >
> > By making it a platform driver, the kirkwood cpufreq driver will only
> > get loaded on kirkwood systems, and won't slow down the boot for
> > everybody else.
>
> I tried to grep platform_driver in drivers/cpufreq/ and got only:
> drivers/cpufreq/dbx500-cpufreq.c
>
> Now, the counter argument to your explanation is, multiplatform kernel would be
> built only for testing purpose and not for real product.
I expect Debian, Fedora etc will strongly disagree with you
there. They want one kernel that will run on as many products they
support as possible. Kirkwood is mostly used in NAS boxes and is
supported by all these distributions.
Now for a SoC used in a deeply embedded system, using a custom
distribution, buildroot, etc, multiplatform is probably not
wanted. But the products i've seen using Kirkwood don't fit this use
case.
> So, even this kind of delay is really not a big issue. On the other
> hand with platform driver too, we will hit lot of other code and
> would consume some extra memory for keeping its structures
Kirkwood has many platform drivers, all this code is already pulled
in, lots of structures already exist. The incremental costs of another
platform device is minimal.
Andrew
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Andrew Lunn @ 2013-01-27 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127171111.GG23505@n2100.arm.linux.org.uk>
> > + clkspec.np = np;
> > + clkspec.args_count = 1;
> > + clkspec.args[0] = 1;
> > +
> > + priv.cpu_clk = of_clk_get_from_provider(&clkspec);
>
> Oh, yet another way to get clocks...
Yep. I didn't like it, but could not find a better way. It has been
argued that cpufreq drivers should not have nodes in DT. So the normal
of_clk_get() does not work. Since the clocks themselves are
instantiated from DT, there are no clkdev alias, so plain clk_get()
also does not work.
Do you know of a better way to do this?
Thanks
Andrew
^ permalink raw reply
* [PATCH v2 16/22] PCI, arm: Kill pci_root_buses
From: Russell King - ARM Linux @ 2013-01-27 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359265003-16166-17-git-send-email-yinghai@kernel.org>
On Sat, Jan 26, 2013 at 09:36:37PM -0800, Yinghai Lu wrote:
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: linux-arm-kernel at lists.infradead.org
So... what's this about. This email is all I've recieved, and the only
thing that I have to go on is one single subject line and not description
about what's going on. I guess there's some other patch introducing this
for_each_pci_host_bridge() macro somewhere? I guess that's part of this
patch set?
Yet... I guess you want an ack for this or something... which would be
irresponsible to give without knowing the purpose behind this, the
reasoning, or even being able to tell whether the replacement code is
functionally equivalent.
So, no ack (or nack) at the moment.
> ---
> arch/arm/kernel/bios32.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index 9b72261..d0befe4 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -57,13 +57,10 @@ static void pcibios_bus_report_status(struct pci_bus *bus, u_int status_mask, in
>
> void pcibios_report_status(u_int status_mask, int warn)
> {
> - struct list_head *l;
> + struct pci_host_bridge *host_bridge = NULL;
>
> - list_for_each(l, &pci_root_buses) {
> - struct pci_bus *bus = pci_bus_b(l);
> -
> - pcibios_bus_report_status(bus, status_mask, warn);
> - }
> + for_each_pci_host_bridge(host_bridge)
> + pcibios_bus_report_status(host_bridge->bus, status_mask, warn);
> }
>
> /*
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH v3 1/3] cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs
From: Andrew Lunn @ 2013-01-27 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127171111.GG23505@n2100.arm.linux.org.uk>
On Sun, Jan 27, 2013 at 05:11:11PM +0000, Russell King - ARM Linux wrote:
> On Sun, Jan 27, 2013 at 11:07:22AM +0100, Andrew Lunn wrote:
> > +static struct priv
> > +{
> > + struct clk *cpu_clk;
> > + struct clk *ddr_clk;
> > + struct clk *powersave_clk;
> > + struct device *dev;
> > + void __iomem *base;
> > +} priv;
>
> I guess you probably think that the compiler will do something special
> with this
Nope, i expect nothing at all from the compiler. I just know i need
only one of these structures so i statically allocated it. I could
allocate it dynamically, probably get the cleanup wrong in the error
path and get shouted at by Russel King. Oh well...
> > +static unsigned int kirkwood_cpufreq_get_cpu_frequency(unsigned int cpu)
> > +{
> > + if (__clk_is_enabled(priv.powersave_clk))
>
> This looks to me to be a layering violation.
Possibly is. Not sure. This is a gated clock, so clk_get_rate()
returns the rate of the parent clock independent of if the gated clock
is enabled or not. So that does not help me. The cpufreq driver needs
to cause a transition on this clock, either disabled->enabled, or
enabled->disabled, then do a WFI, and once the system is stable it
wakes up. If there is no transition, it was already enabled and all
that clk_enable() does is increment the count, the WFI never exits and
the system sleeps forever. I'm assuming here that no other driver is
using this clock, which i think is a sensible assumption. But i've no
idea of the initial state of the clock. Did uboot enable it or not?
Thanks
Andrew
^ permalink raw reply
* [PATCH v2 16/22] PCI, arm: Kill pci_root_buses
From: Yinghai Lu @ 2013-01-27 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130127173816.GH23505@n2100.arm.linux.org.uk>
On Sun, Jan 27, 2013 at 9:38 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jan 26, 2013 at 09:36:37PM -0800, Yinghai Lu wrote:
>> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: linux-arm-kernel at lists.infradead.org
>
> So... what's this about. This email is all I've recieved, and the only
> thing that I have to go on is one single subject line and not description
> about what's going on. I guess there's some other patch introducing this
> for_each_pci_host_bridge() macro somewhere? I guess that's part of this
> patch set?
yes.
sorry for not put you in the cc list of the whole patchset. will do
that next reversion.
>
> Yet... I guess you want an ack for this or something... which would be
> irresponsible to give without knowing the purpose behind this, the
> reasoning, or even being able to tell whether the replacement code is
> functionally equivalent.
the purpose is to make iteration for root bus to be root-bus
hotplug safe.
will update change log.
>
> So, no ack (or nack) at the moment.
>
>> ---
>> arch/arm/kernel/bios32.c | 9 +++------
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
>> index 9b72261..d0befe4 100644
>> --- a/arch/arm/kernel/bios32.c
>> +++ b/arch/arm/kernel/bios32.c
>> @@ -57,13 +57,10 @@ static void pcibios_bus_report_status(struct pci_bus *bus, u_int status_mask, in
>>
>> void pcibios_report_status(u_int status_mask, int warn)
>> {
>> - struct list_head *l;
>> + struct pci_host_bridge *host_bridge = NULL;
>>
>> - list_for_each(l, &pci_root_buses) {
>> - struct pci_bus *bus = pci_bus_b(l);
>> -
>> - pcibios_bus_report_status(bus, status_mask, warn);
>> - }
>> + for_each_pci_host_bridge(host_bridge)
>> + pcibios_bus_report_status(host_bridge->bus, status_mask, warn);
>> }
>>
>> /*
>> --
>> 1.7.10.4
>>
^ permalink raw reply
* [PATCH V3 8/8] ARM: kirkwood: mv643xx_eth dt conversion
From: Russell King - ARM Linux @ 2013-01-27 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5105275B.1020909@gmail.com>
On Sun, Jan 27, 2013 at 02:10:51PM +0100, Sebastian Hesselbarth wrote:
> On 01/27/2013 01:21 PM, Russell King - ARM Linux wrote:
>> On Sat, Jan 26, 2013 at 02:40:12PM +0100, Andrew Lunn wrote:
>>> On Sat, Jan 26, 2013 at 01:50:11PM +0100, Sebastian Hesselbarth wrote:
>>> The code here is based on dove_legacy_clk_init(). However the change
>>> made by Jason is in order to make a DT device work, not an non-DT
>>> device.
>>>
>>> The problem is the way the driver is getting the clock.
>>>
>>> mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
>>>
> > ...
>> So, the whole:
>>
>> mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
>>
>> is absolutely ludicrous. You already know which device it is by means of
>> the first argument. You don't need to pass a "0" or a "1". So that should
>> be NULL, so:
>>
>> mp->clk = clk_get(&pdev->dev, NULL);
>>
>> That will get a clock from clkdev which is setup in the _matching_ tables
>> to correlate with the device (and a NULL connection ID _there_ too). With
>> OF, I believe it will get the first clock.
>
> The conid was set for mv643xx but shouldn't be set anymore - check
> mach-kirkwood/common.c.
If you're referring to:
mp->clk = clk_get(&pdev->dev, (pdev->id ? "1" : "0"));
That should _never_ have ever been allowed. It's total bollocks as I've
pointed out above.
> I guess we can just remove the conid check and rely on DT passed
> clock only.
Yes, and it _will_ work fine for non-DT too, because you have a device
with a single clock connection. If it doesn't, then you've revealed a
latent bug - probably down to a non-conforming clk API implementation
by someone else.
^ permalink raw reply
* [PATCH 0/3] Add support for user LED on the A13-Olinuxino
From: Maxime Ripard @ 2013-01-27 19:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This patchset adds the user LED of the Olinuxino to the device tree.
To do so, we also add a custom of_xlate function to the PIO driver so that
we can use a more convenient format for the gpios from the device tree.
Thanks,
Maxime
Maxime Ripard (3):
pinctrl: sunxi: Add of_xlate function
sunxi: dts: Report the pinctrl nodes as gpio-controllers
sunxi: a13-olinuxino: Add user LED to the device tree
arch/arm/boot/dts/sun4i-a10.dtsi | 4 +++-
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 20 ++++++++++++++++++++
arch/arm/boot/dts/sun5i-a13.dtsi | 4 +++-
drivers/pinctrl/pinctrl-sunxi.c | 20 ++++++++++++++++++++
4 files changed, 46 insertions(+), 2 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [PATCH 1/3] pinctrl: sunxi: Add of_xlate function
From: Maxime Ripard @ 2013-01-27 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359313332-12305-1-git-send-email-maxime.ripard@free-electrons.com>
Since the pin controller of sunxi chips is represented as a single bank
in the driver.
Since this is neither convenient nor represented that way in the
datasheets, define a custom of_xlate function with the layout <bank pin
flag>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
drivers/pinctrl/pinctrl-sunxi.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-sunxi.c b/drivers/pinctrl/pinctrl-sunxi.c
index 353f6a8..122eeca 100644
--- a/drivers/pinctrl/pinctrl-sunxi.c
+++ b/drivers/pinctrl/pinctrl-sunxi.c
@@ -1261,6 +1261,24 @@ static void sunxi_pinctrl_gpio_set(struct gpio_chip *chip,
writel((value & DATA_PINS_MASK) << index, pctl->membase + reg);
}
+static int sunxi_pinctrl_gpio_of_xlate(struct gpio_chip *gc,
+ const struct of_phandle_args *gpiospec,
+ u32 *flags)
+{
+ int pin, base;
+
+ base = PINS_PER_BANK * gpiospec->args[0];
+ pin = base + gpiospec->args[1];
+
+ if (pin > (gc->base + gc->ngpio))
+ return -EINVAL;
+
+ if (flags)
+ *flags = gpiospec->args[2];
+
+ return pin;
+}
+
static struct gpio_chip sunxi_pinctrl_gpio_chip __devinitconst = {
.owner = THIS_MODULE,
.request = sunxi_pinctrl_gpio_request,
@@ -1269,6 +1287,8 @@ static struct gpio_chip sunxi_pinctrl_gpio_chip __devinitconst = {
.direction_output = sunxi_pinctrl_gpio_direction_output,
.get = sunxi_pinctrl_gpio_get,
.set = sunxi_pinctrl_gpio_set,
+ .of_xlate = sunxi_pinctrl_gpio_of_xlate,
+ .of_gpio_n_cells = 3,
.can_sleep = 0,
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] sunxi: dts: Report the pinctrl nodes as gpio-controllers
From: Maxime Ripard @ 2013-01-27 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359313332-12305-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 4 +++-
arch/arm/boot/dts/sun5i-a13.dtsi | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index f99f60d..03d2b53 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -18,11 +18,13 @@
};
soc {
- pinctrl at 01c20800 {
+ pio: pinctrl at 01c20800 {
compatible = "allwinner,sun4i-a10-pinctrl";
reg = <0x01c20800 0x400>;
+ gpio-controller;
#address-cells = <1>;
#size-cells = <0>;
+ #gpio-cells = <3>;
uart0_pins_a: uart0 at 0 {
allwinner,pins = "PB22", "PB23";
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index e112189..945bfac 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -19,11 +19,13 @@
};
soc {
- pinctrl at 01c20800 {
+ pio: pinctrl at 01c20800 {
compatible = "allwinner,sun5i-a13-pinctrl";
reg = <0x01c20800 0x400>;
+ gpio-controller;
#address-cells = <1>;
#size-cells = <0>;
+ #gpio-cells = <3>;
uart1_pins_a: uart1 at 0 {
allwinner,pins = "PE10", "PE11";
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/3] sunxi: a13-olinuxino: Add user LED to the device tree
From: Maxime Ripard @ 2013-01-27 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359313332-12305-1-git-send-email-maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index 4a1e45d..33d1c7e 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -23,10 +23,30 @@
};
soc {
+ pinctrl at 01c20800 {
+ led_pins_olinuxino: led_pins at 0 {
+ allwinner,pins = "PG9";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <1>;
+ allwinner,pull = <0>;
+ };
+ };
+
uart1: uart at 01c28400 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins_b>;
status = "okay";
};
};
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins_olinuxino>;
+
+ power {
+ gpios = <&pio 6 9 0>;
+ default-state = "on";
+ };
+ };
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH v3 00/22] PCI: Iterate pci host bridge instead of pci root bus
From: Yinghai Lu @ 2013-01-27 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAE9FiQXHG01NjnYNDbC-KEpbcvY-q4pBe97CxTOGS7W4vZQBYQ@mail.gmail.com>
Now we have pci_root_buses list, and there is lots of iteration with
list_of_each of it, that is not safe after we add pci root bus hotplug
support after booting stage.
Add pci_get_next_host_bridge and use bus_find_device in driver core to
iterate host bridge and the same time get root bus.
We replace searching root bus with searching host_bridge,
as host_bridge->bus is the root bus.
After those replacing, we even could kill pci_root_buses list.
based on pci/next
could get from
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-for-each-host-bridge
-v2: updated after pci_root_bus_hotplug get into pci/next
-v3: update changelog and add cc for pci core change for arch guys.
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Cc: linux-edac at vger.kernel.org
Cc: x86 at kernel.org
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel at lists.freedesktop.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux at vger.kernel.org
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: linux-ia64 at vger.kernel.org
Cc: linux-altix at sgi.com
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: linux-alpha at vger.kernel.org
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: David Howells <dhowells@redhat.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: microblaze-uclinux at itee.uq.edu.au
Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
Cc: linux-am33-list at redhat.com
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev at lists.ozlabs.org
Yinghai Lu (22):
PCI: Rename pci_release_bus_bridge_dev to pci_release_host_bridge_dev
PCI: Add dummy bus_type for pci_host_bridge
PCI, libata: remove find_bridge in acpi_bus_type
PCI, ACPI: Update comments for find_bridge in acpi_bus_type
PCI: Add for_each_pci_host_bridge() and pci_get_next_host_bridge
PCI, hotplug: Kill pci_find_next_bus in sgi_hotplug
PCI: Kill pci_find_next_bus in pci_sysfs
PCI, edac: Kill pci_find_next_bus in edac
PCI, x86: Kill pci_find_next_bus in pcibios_scan_root
PCI, x86: Kill pci_root_buses in resources reservations
PCI, drm: Kill pci_root_buses in alpha hose setting
PCI: Kill pci_root_buses in setup-bus
PCI, sparc: Kill pci_find_next_bus
PCI, ia64: Kill pci_find_next_bus
PCI, alpha: Kill pci_root_buses
PCI, arm: Kill pci_root_buses
PCI, frv: Kill pci_root_buses in resources reservations
PCI, microblaze: Kill pci_root_buses in resources reservations
PCI, mn10300: Kill pci_root_buses in resources reservations
PCI, powerpc: Kill pci_root_buses in resources reservations
PCI: Kill pci_find_next_bus
PCI: Kill pci_root_buses
arch/alpha/kernel/pci.c | 6 +--
arch/arm/kernel/bios32.c | 9 ++---
arch/frv/mb93090-mb00/pci-frv.c | 37 +++++++++---------
arch/ia64/hp/common/sba_iommu.c | 7 ++--
arch/ia64/sn/kernel/io_common.c | 5 ++-
arch/microblaze/pci/pci-common.c | 10 ++---
arch/mn10300/unit-asb2305/pci-asb2305.c | 62 ++++++++++++++++---------------
arch/powerpc/kernel/pci-common.c | 13 +++----
arch/powerpc/kernel/pci_64.c | 8 ++--
arch/sparc/kernel/pci.c | 6 ++-
arch/x86/pci/common.c | 9 +++--
arch/x86/pci/i386.c | 20 +++++-----
drivers/ata/libata-acpi.c | 6 ---
drivers/edac/i7core_edac.c | 6 +--
drivers/gpu/drm/drm_fops.c | 10 +++--
drivers/pci/hotplug/sgi_hotplug.c | 6 ++-
drivers/pci/pci-driver.c | 11 +++++-
drivers/pci/pci-sysfs.c | 6 +--
drivers/pci/probe.c | 13 ++-----
drivers/pci/search.c | 61 +++++++++++++++---------------
drivers/pci/setup-bus.c | 24 ++++++------
include/acpi/acpi_bus.h | 2 +-
include/linux/pci.h | 18 +++++----
23 files changed, 187 insertions(+), 168 deletions(-)
--
1.7.10.4
^ 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