* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: kishon @ 2013-01-30 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130101102.GV1906@pengutronix.de>
Hi,
On Wednesday 30 January 2013 03:41 PM, Sascha Hauer wrote:
> On Wed, Jan 30, 2013 at 11:21:35AM +0530, kishon wrote:
>> On Wednesday 30 January 2013 02:00 AM, Sascha Hauer wrote:
>>> On Tue, Jan 29, 2013 at 07:14:51PM +0530, kishon wrote:
>>>> Hi,
>>>>
>>>> On Tuesday 29 January 2013 04:52 PM, Sascha Hauer wrote:
>>>>> From: Michael Grzeschik <m.grzeschik@pengutronix.de>
>>>>>
>>>>> This adds two little devicetree helper functions for determining the
>>>>> dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
>>>>> the devicetree.
>>>>>
>>>>> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
>>>>> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>>>>> ---
>>>>>
>>>>> The properties and their values have been taken from the fsl-mph-dr driver.
>>>>> This binding is also documented (though currently not used) for the tegra
>>>>> ehci driver (Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt).
>>>>> This is a first attempt to parse these bindings at a common place so that
>>>>> others can make use of it.
>>>>>
>>>>> Basically I want to know whether this binding is recommended for new drivers
>>>>> since normally the devicetree uses '-' instead of '_', and maybe there are
>>>>> other problems with it.
>>>>>
>>>>> I need this binding for the chipidea driver. I suspect that the fsl-mph-dr
>>>>> driver also really handles a chipidea core.
>>>>>
>>>>> Should we agree on this I would convert the fsl-mph-dr driver to use these
>>>>> helpers.
>>>>>
>>>>> Sascha
>>>>>
>>>>> drivers/usb/core/Makefile | 1 +
>>>>> drivers/usb/core/of.c | 76 +++++++++++++++++++++++++++++++++++++++++++++
>>>>
>>>> This file should ideally go into drivers/usb/phy/.
>>>
>>> I originally wanted to do that, but the host/peripheral/otg property is
>>> not phy specific. DO you still want to move it there?
>>
>> I think then you can just move of_usb_get_phy_mode() to phy/of.c.
>> Then we can also move some functions defined in otg.c (specific to
>> PHY and dt) to phy/of.c.
>
> The phy specific stuff in otg.c can't easily be moved as all functions
> operate on a static list and spinlock. Also nothing in otg/otg.c is
> currently of specific.
Actually nothing in otg.c is specific to OTG except one function
otg_state_string(). So we should ideally have all the list and spinlock
stuff be moved to phy.c
Some of them got added recently (like devm_usb_get_phy_by_phandle). It
should be in
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next
>
> What about the dr_mode helper? Moving it to otg/ would mean that all
*dr_mode* doesn't look like it should be in phy/ or otg/. You can keep
it as is in core/of.c
Thanks
Kishon
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Viresh Kumar @ 2013-01-30 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301301008.31196.arnd@arndb.de>
On 30 January 2013 15:38, Arnd Bergmann <arnd@arndb.de> wrote:
> I meant the spear13xx data sheet, which has to list the request lines
> for its integrated components. There may be other SoCs using the
> same dw_dmac, but this is the main one that is upstream now, and it's
> probably as good as any other one. I just wouldn't want to establish
> a binding that doesn't match any of the known implementations in the
> way it expresses request lines.
Your binding (<controller request-line src-master dst-master) is good
enough for SPEAr :)
SPEAr13xx is a bit complex. Request lines are distributed among masters.
+ there is multiplexing among them.. over that there are two controllers..
But yes, your binding is good enough :)
^ permalink raw reply
* [PATCH] mfd: vexpress: Add pseudo-GPIO based LEDs
From: Pawel Moll @ 2013-01-30 10:33 UTC (permalink / raw)
To: linux-arm-kernel
The LEDs on the Versatile Express motherboard are controlled
through simple memory-mapped register. This patch extends
the pseudo-GPIO controller definition for these lines and
creates generic "leds-gpio" device using them
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
Hello Samuel,
Would you be so kind to take this patch in for 3.9? Or would
you prefer to get it in through arm-soc tree?
Thanks!
Pawel
drivers/mfd/vexpress-sysreg.c | 73 +++++++++++++++++++++++++++++++----------
include/linux/vexpress.h | 8 +++++
2 files changed, 63 insertions(+), 18 deletions(-)
diff --git a/drivers/mfd/vexpress-sysreg.c b/drivers/mfd/vexpress-sysreg.c
index 77048b1..51c3ca2 100644
--- a/drivers/mfd/vexpress-sysreg.c
+++ b/drivers/mfd/vexpress-sysreg.c
@@ -49,6 +49,8 @@
#define SYS_ID_HBI_SHIFT 16
#define SYS_PROCIDx_HBI_SHIFT 0
+#define SYS_LED_LED(n) (1 << (n))
+
#define SYS_MCI_CARDIN (1 << 0)
#define SYS_MCI_WPROT (1 << 1)
@@ -348,22 +350,27 @@ void __init vexpress_sysreg_of_early_init(void)
}
+#define VEXPRESS_SYSREG_GPIO(_name, _reg, _value) \
+ [VEXPRESS_GPIO_##_name] = { \
+ .reg = _reg, \
+ .value = _reg##_##_value, \
+ }
+
static struct vexpress_sysreg_gpio {
unsigned long reg;
u32 value;
} vexpress_sysreg_gpios[] = {
- [VEXPRESS_GPIO_MMC_CARDIN] = {
- .reg = SYS_MCI,
- .value = SYS_MCI_CARDIN,
- },
- [VEXPRESS_GPIO_MMC_WPROT] = {
- .reg = SYS_MCI,
- .value = SYS_MCI_WPROT,
- },
- [VEXPRESS_GPIO_FLASH_WPn] = {
- .reg = SYS_FLASH,
- .value = SYS_FLASH_WPn,
- },
+ VEXPRESS_SYSREG_GPIO(MMC_CARDIN, SYS_MCI, CARDIN),
+ VEXPRESS_SYSREG_GPIO(MMC_WPROT, SYS_MCI, WPROT),
+ VEXPRESS_SYSREG_GPIO(FLASH_WPn, SYS_FLASH, WPn),
+ VEXPRESS_SYSREG_GPIO(LED0, SYS_LED, LED(0)),
+ VEXPRESS_SYSREG_GPIO(LED1, SYS_LED, LED(1)),
+ VEXPRESS_SYSREG_GPIO(LED2, SYS_LED, LED(2)),
+ VEXPRESS_SYSREG_GPIO(LED3, SYS_LED, LED(3)),
+ VEXPRESS_SYSREG_GPIO(LED4, SYS_LED, LED(4)),
+ VEXPRESS_SYSREG_GPIO(LED5, SYS_LED, LED(5)),
+ VEXPRESS_SYSREG_GPIO(LED6, SYS_LED, LED(6)),
+ VEXPRESS_SYSREG_GPIO(LED7, SYS_LED, LED(7)),
};
static int vexpress_sysreg_gpio_direction_input(struct gpio_chip *chip,
@@ -372,12 +379,6 @@ static int vexpress_sysreg_gpio_direction_input(struct gpio_chip *chip,
return 0;
}
-static int vexpress_sysreg_gpio_direction_output(struct gpio_chip *chip,
- unsigned offset, int value)
-{
- return 0;
-}
-
static int vexpress_sysreg_gpio_get(struct gpio_chip *chip,
unsigned offset)
{
@@ -401,6 +402,14 @@ static void vexpress_sysreg_gpio_set(struct gpio_chip *chip,
writel(reg_value, vexpress_sysreg_base + gpio->reg);
}
+static int vexpress_sysreg_gpio_direction_output(struct gpio_chip *chip,
+ unsigned offset, int value)
+{
+ vexpress_sysreg_gpio_set(chip, offset, value);
+
+ return 0;
+}
+
static struct gpio_chip vexpress_sysreg_gpio_chip = {
.label = "vexpress-sysreg",
.direction_input = vexpress_sysreg_gpio_direction_input,
@@ -412,6 +421,30 @@ static struct gpio_chip vexpress_sysreg_gpio_chip = {
};
+#define VEXPRESS_SYSREG_GREEN_LED(_name, _default_trigger, _gpio) \
+ { \
+ .name = "v2m:green:"_name, \
+ .default_trigger = _default_trigger, \
+ .gpio = VEXPRESS_GPIO_##_gpio, \
+ }
+
+struct gpio_led vexpress_sysreg_leds[] = {
+ VEXPRESS_SYSREG_GREEN_LED("user1", "heartbeat", LED0),
+ VEXPRESS_SYSREG_GREEN_LED("user2", "mmc0", LED1),
+ VEXPRESS_SYSREG_GREEN_LED("user3", "cpu0", LED2),
+ VEXPRESS_SYSREG_GREEN_LED("user4", "cpu1", LED3),
+ VEXPRESS_SYSREG_GREEN_LED("user5", "cpu2", LED4),
+ VEXPRESS_SYSREG_GREEN_LED("user6", "cpu3", LED5),
+ VEXPRESS_SYSREG_GREEN_LED("user7", "cpu4", LED6),
+ VEXPRESS_SYSREG_GREEN_LED("user8", "cpu5", LED7),
+};
+
+struct gpio_led_platform_data vexpress_sysreg_leds_pdata = {
+ .num_leds = ARRAY_SIZE(vexpress_sysreg_leds),
+ .leds = vexpress_sysreg_leds,
+};
+
+
static ssize_t vexpress_sysreg_sys_id_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -456,6 +489,10 @@ static int vexpress_sysreg_probe(struct platform_device *pdev)
return err;
}
+ platform_device_register_data(vexpress_sysreg_dev, "leds-gpio",
+ PLATFORM_DEVID_AUTO, &vexpress_sysreg_leds_pdata,
+ sizeof(vexpress_sysreg_leds_pdata));
+
vexpress_sysreg_dev = &pdev->dev;
device_create_file(vexpress_sysreg_dev, &dev_attr_sys_id);
diff --git a/include/linux/vexpress.h b/include/linux/vexpress.h
index c52215f..7581874 100644
--- a/include/linux/vexpress.h
+++ b/include/linux/vexpress.h
@@ -27,6 +27,14 @@
#define VEXPRESS_GPIO_MMC_CARDIN 0
#define VEXPRESS_GPIO_MMC_WPROT 1
#define VEXPRESS_GPIO_FLASH_WPn 2
+#define VEXPRESS_GPIO_LED0 3
+#define VEXPRESS_GPIO_LED1 4
+#define VEXPRESS_GPIO_LED2 5
+#define VEXPRESS_GPIO_LED3 6
+#define VEXPRESS_GPIO_LED4 7
+#define VEXPRESS_GPIO_LED5 8
+#define VEXPRESS_GPIO_LED6 9
+#define VEXPRESS_GPIO_LED7 10
#define VEXPRESS_RES_FUNC(_site, _func) \
{ \
--
1.7.10.4
^ permalink raw reply related
* [PATCH v6 08/10] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
From: Mark Brown @ 2013-01-30 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359529229-22207-9-git-send-email-mporter@ti.com>
On Wed, Jan 30, 2013 at 02:00:27AM -0500, Matt Porter wrote:
> Convert dmaengine channel requests to use
> dma_request_slave_channel_compat(). This supports the DT case of
> platforms requiring channel selection from either the OMAP DMA or
> the EDMA engine. AM33xx only boots from DT and is the only user
> implementing EDMA so in the !DT case we can default to the OMAP DMA
> filter.
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
^ permalink raw reply
* [GIT PULL] vexpress: drivers for v3.9
From: Pawel Moll @ 2013-01-30 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMinJef-9OsKi0LGB0W6i73sgyUqhm2Mie4gyC2JLjnd1Q@mail.gmail.com>
Morning,
> > Pawel Moll (1):
> > mfd: vexpress: Add pseudo-GPIO based LEDs
>
> I can't find record of this patch ever having been posted (under that
> subject at least) on any list I am on, including linux-arm-kernel and
> linux-kernel.
Uh, the brief LEDs discussion happened so long ago (almost 3 months)
that I was convinced I posted it back then. Should have checked it
myself, sorry.
> You should at least post it to those lists, and cc the MFD maintainer.
> And you should get his ack if you are going to merge this patch
> through arm-soc instead of through his tree.
You're right, I'll approach Samuel regarding this bit.
In the meantime, could you please take the other patch please? I mean:
> > Catalin Marinas (1):
> > arm: Move sp810.h to include/linux/amba/
I can rework the branch to contain this patch only and send a new pull
request if you prefer.
Thanks!
Pawe?
^ permalink raw reply
* [PATCH v4 5/8] MFD: ti_am335x_tscadc: Add DT support
From: Koen Kooi @ 2013-01-30 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358999112-31192-6-git-send-email-rachna@ti.com>
Op 24 jan. 2013, om 04:45 heeft "Patil, Rachna" <rachna@ti.com> het volgende geschreven:
> From: "Patil, Rachna" <rachna@ti.com>
>
> Make changes to add DT support in the MFD core driver.
>
> Signed-off-by: Patil, Rachna <rachna@ti.com>
> ---
> Changes in v4:
> Non-standard properties prefixed with vendor name.
>
> drivers/mfd/ti_am335x_tscadc.c | 28 +++++++++++++++++++++++-----
> 1 file changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
> index e9f3fb5..87b446b 100644
> --- a/drivers/mfd/ti_am335x_tscadc.c
> +++ b/drivers/mfd/ti_am335x_tscadc.c
> @@ -22,6 +22,8 @@
> #include <linux/regmap.h>
> #include <linux/mfd/core.h>
> #include <linux/pm_runtime.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
>
> #include <linux/mfd/ti_am335x_tscadc.h>
> #include <linux/input/ti_am335x_tsc.h>
> @@ -64,20 +66,31 @@ static int ti_tscadc_probe(struct platform_device *pdev)
> struct resource *res;
> struct clk *clk;
> struct mfd_tscadc_board *pdata = pdev->dev.platform_data;
> + struct device_node *node = pdev->dev.of_node;
> struct mfd_cell *cell;
> int err, ctrl;
> int clk_value, clock_rate;
> - int tsc_wires, adc_channels = 0, total_channels;
> + int tsc_wires = 0, adc_channels = 0, total_channels;
>
> - if (!pdata) {
> + if (!pdata && !pdev->dev.of_node) {
> dev_err(&pdev->dev, "Could not find platform data\n");
> return -EINVAL;
> }
>
> - if (pdata->adc_init)
> - adc_channels = pdata->adc_init->adc_channels;
> + if (pdev->dev.platform_data) {
> + if (pdata->tsc_init)
> + tsc_wires = pdata->tsc_init->wires;
> +
> + if (pdata->adc_init)
> + adc_channels = pdata->adc_init->adc_channels;
> + } else {
> + node = of_find_node_by_name(pdev->dev.of_node, "tsc");
> + of_property_read_u32(node, "ti,wires", &tsc_wires);
> +
> + node = of_find_node_by_name(pdev->dev.of_node, "adc");
> + of_property_read_u32(node, "ti,adc-channels", &adc_channels);
> + }
Since AM335x is DT only, why is there a platform data codepath and why is it the first branch it tries? And I guess the next question is related to the first: why doesn't it work when used with DT? When I copy over the nodes from the evm.dts to my board I get "tsc tsc: Missing platform data" in dmesg.
What are the chances this driver will work when applied on top of 3.8-rcX? Has it even been tested with that? Has it been tested at all?
^ permalink raw reply
* [PATCH] serial: pl010/pl011: move clk_enable from console write to setup
From: walimis @ 2013-01-30 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbEMO0wuDDXcd6oW6Jnn3LBhATBdcoHJEAdg7MrU6h-jQ@mail.gmail.com>
Resend to mailling list.
2013/1/30 Linus Walleij <linus.walleij@linaro.org>:
> On Tue, Jan 29, 2013 at 5:05 PM, Liming Wang <walimisdev@gmail.com> 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.
>>
>> Signed-off-by: Liming Wang <walimisdev@gmail.com>
>
> NAK.
>
> Consider the case where the console outputs nothing or
> a string every 30 minutes. Why should we not gate off the
Yes, it's reasonable. But I haven't see any other serial drivers do that except
pl010/pl011. Except the above consideration, is there any reason that we have to
do clk_enable in console write?
> clock between these sporadic prints?
It works fine under the normal condition, but I encountered backtrace
while using kgdboc under preempt_rt kernel:
# echo "g" >/proc/sysrq-trigger
SysRq : DEBUG
<3>BUG: sleeping function called from invalid context at kernel/rtmutex.c:646
<3>in_atomic(): 1, irqs_disabled(): 128, pid: 676, name: sh
[<80017d64>] (unwind_backtrace+0x0/0x104) from [<8068fc24>]
(dump_stack+0x20/0x24)
[<8068fc24>] (dump_stack+0x20/0x24) from [<80061130>] (__might_sleep+0xf4/0x108)
[<80061130>] (__might_sleep+0xf4/0x108) from [<80698fc4>]
(rt_spin_lock+0x2c/0x38)
[<80698fc4>] (rt_spin_lock+0x2c/0x38) from [<80027f1c>] (clk_enable+0x2c/0x4c)
[<80027f1c>] (clk_enable+0x2c/0x4c) from [<803fddcc>]
(pl011_console_write+0x34/0x148)
[<803fddcc>] (pl011_console_write+0x34/0x148) from [<8009e60c>]
(vkdb_printf+0x384/0xa78)
[<8009e60c>] (vkdb_printf+0x384/0xa78) from [<8009ed44>] (kdb_printf+0x44/0x58)
[<8009ed44>] (kdb_printf+0x44/0x58) from [<800a399c>]
(kdb_main_loop+0x10c/0x914)
[<800a399c>] (kdb_main_loop+0x10c/0x914) from [<800a7a34>]
(kdb_stub+0x800/0x95c)
[<800a7a34>] (kdb_stub+0x800/0x95c) from [<8009b7b0>]
(kgdb_cpu_enter+0x350/0x780)
[<8009b7b0>] (kgdb_cpu_enter+0x350/0x780) from [<8009be64>]
(kgdb_handle_exception+0x94/0x1bc)
[<8009be64>] (kgdb_handle_exception+0x94/0x1bc) from [<80016efc>]
(kgdb_compiled_brk_fn+0x38/0x40)
[<80016efc>] (kgdb_compiled_brk_fn+0x38/0x40) from [<800082f4>]
(do_undefinstr+0x154/0x184)
[<800082f4>] (do_undefinstr+0x154/0x184) from [<80699a2c>]
(__und_svc_finish+0x0/0x14)
Exception stack(0xbcd6de08 to 0xbcd6de50)
de00: bcd6c000 bcd6c028 bcd6de68 80020318 809b77c0 809b77c8
de20: 80923e5c 00000007 00000000 bcd6c000 bcd6df68 bcd6deac bcd6de38 bcd6de90
de40: 800627d8 8009ac28 600d0013 ffffffff
[<80699a2c>] (__und_svc_finish+0x0/0x14) from [<8009ac28>]
(kgdb_breakpoint+0x50/0x80)
[<8009ac28>] (kgdb_breakpoint+0x50/0x80) from [<8009af18>]
(sysrq_handle_dbg+0x4c/0x70)
[<8009af18>] (sysrq_handle_dbg+0x4c/0x70) from [<803e9c38>]
(__handle_sysrq+0x138/0x19c)
[<803e9c38>] (__handle_sysrq+0x138/0x19c) from [<803e9ce4>]
(write_sysrq_trigger+0x48/0x58)
[<803e9ce4>] (write_sysrq_trigger+0x48/0x58) from [<801886c8>]
(proc_reg_write+0x88/0xb0)
[<801886c8>] (proc_reg_write+0x88/0xb0) from [<80132b1c>] (vfs_write+0xb8/0x148)
[<80132b1c>] (vfs_write+0xb8/0x148) from [<80132e64>] (sys_write+0x50/0x124)
[<80132e64>] (sys_write+0x50/0x124) from [<8000e7a0>]
(ret_fast_syscall+0x0/0x30)
[<80132e64>] (sys_write+0x50/0x124) from [<8on processor 1 due to Keyboard Entry
[1]kdb>
It seems that clk_enable/clk_disable are called in pl011_console_write
function with the irq disabeld. So that spin_lock in clk_enable/clk_disable
trips the rtmutex debug code.
There are two ways to resolve the issues:
1. One way is to convert spin_lock in clk_enable/clk_disable to raw spin_lock.
2. Another way is to move clk_enable/clk_disable from console write.
This patch is an attempt to make clear whether we can move
clk_enable/clk_disable from console write.
Thanks
Liming Wang
>
> Yours,
> Linus Walleij
^ permalink raw reply
* [PATCH] ARM:mach-msm: seting tail NUL after strncpy
From: Chen Gang @ 2013-01-30 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87pq0nni3v.fsf@nemi.mork.no>
? 2013?01?30? 17:19, Bj?rn Mork ??:
> Maybe use strlcpy() instead?
ok, I will send patch v2.
it will be "strlcpy(temp, clock->dbg_name, ARRAY_SIZE(temp));"
thanks.
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH] serial: pl010/pl011: move clk_enable from console write to setup
From: Russell King - ARM Linux @ 2013-01-30 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+8yKp-VGp=HWoSH4Ce0f9-+u5mYDFN0ri7_nN3q4aOAeY223A@mail.gmail.com>
On Wed, Jan 30, 2013 at 06:41:34PM +0800, walimis wrote:
> 2013/1/30 Linus Walleij <linus.walleij@linaro.org>:
> > On Tue, Jan 29, 2013 at 5:05 PM, Liming Wang <walimisdev@gmail.com> 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.
> >>
> >> Signed-off-by: Liming Wang <walimisdev@gmail.com>
> >
> > NAK.
> >
> > Consider the case where the console outputs nothing or
> > a string every 30 minutes. Why should we not gate off the
>
> Yes, it's reasonable. But I haven't see any other serial drivers do that except
> pl010/pl011. Except the above consideration, is there any reason that we have to
> do clk_enable in console write?
The reason that it's done is because the author of the driver (me) is also
the author of the clk API, and I know how these things work, and I know
how to code drivers to work most effectively with it.
Everyone else appears to be totally and utterly lazy about it.
> It works fine under the normal condition, but I encountered backtrace
> while using kgdboc under preempt_rt kernel:
>
> # echo "g" >/proc/sysrq-trigger
> SysRq : DEBUG
> <3>BUG: sleeping function called from invalid context at kernel/rtmutex.c:646
> <3>in_atomic(): 1, irqs_disabled(): 128, pid: 676, name: sh
> [<80017d64>] (unwind_backtrace+0x0/0x104) from [<8068fc24>]
> (dump_stack+0x20/0x24)
> [<8068fc24>] (dump_stack+0x20/0x24) from [<80061130>] (__might_sleep+0xf4/0x108)
> [<80061130>] (__might_sleep+0xf4/0x108) from [<80698fc4>]
> (rt_spin_lock+0x2c/0x38)
> [<80698fc4>] (rt_spin_lock+0x2c/0x38) from [<80027f1c>] (clk_enable+0x2c/0x4c)
Well, I guess that's down to the use of rt_spin_lock there. I think that's
one for the RT Preempt guys; I don't deal with RT kernels at all - I know
nothing about that.
In standard kernel programming it is perfectly acceptable to take spinlocks
in non-preemptable contexts like this.
> This patch is an attempt to make clear whether we can move
> clk_enable/clk_disable from console write.
clk_enable/clk_disable should be callable from this context; the bug is that
they aren't.
^ permalink raw reply
* [BUG] i.MX25: soft lockups/freezes while getnstimeofday
From: Fabio Estevam @ 2013-01-30 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130070315.GC30136@pengutronix.de>
On Wed, Jan 30, 2013 at 5:03 AM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:
> Do your hardware guys have documentation about *why* it "must be derived
> from AHB clock"?
I have asked for more clarification about this.
^ permalink raw reply
* [PATCH] ARM: sync comments about available data abort models with the code
From: Uwe Kleine-König @ 2013-01-30 11:09 UTC (permalink / raw)
To: linux-arm-kernel
While at it bring both in the same increasing order.
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Hello,
Jonny critizised that I didn't update the comment for my new entry. I
suggest to fix the already existing issues first.
Best regards
Uwe
arch/arm/include/asm/glue-df.h | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/asm/glue-df.h b/arch/arm/include/asm/glue-df.h
index 8cacbcd..b6e9f2c 100644
--- a/arch/arm/include/asm/glue-df.h
+++ b/arch/arm/include/asm/glue-df.h
@@ -18,12 +18,12 @@
* ================
*
* We have the following to choose from:
- * arm6 - ARM6 style
* arm7 - ARM7 style
* v4_early - ARMv4 without Thumb early abort handler
* v4t_late - ARMv4 with Thumb late abort handler
* v4t_early - ARMv4 with Thumb early abort handler
- * v5tej_early - ARMv5 with Thumb and Java early abort handler
+ * v5t_early - ARMv5 with Thumb early abort handler
+ * v5tj_early - ARMv5 with Thumb and Java early abort handler
* xscale - ARMv5 with Thumb with Xscale extensions
* v6_early - ARMv6 generic early abort handler
* v7_early - ARMv7 generic early abort handler
@@ -39,19 +39,19 @@
# endif
#endif
-#ifdef CONFIG_CPU_ABRT_LV4T
+#ifdef CONFIG_CPU_ABRT_EV4
# ifdef CPU_DABORT_HANDLER
# define MULTI_DABORT 1
# else
-# define CPU_DABORT_HANDLER v4t_late_abort
+# define CPU_DABORT_HANDLER v4_early_abort
# endif
#endif
-#ifdef CONFIG_CPU_ABRT_EV4
+#ifdef CONFIG_CPU_ABRT_LV4T
# ifdef CPU_DABORT_HANDLER
# define MULTI_DABORT 1
# else
-# define CPU_DABORT_HANDLER v4_early_abort
+# define CPU_DABORT_HANDLER v4t_late_abort
# endif
#endif
@@ -63,19 +63,19 @@
# endif
#endif
-#ifdef CONFIG_CPU_ABRT_EV5TJ
+#ifdef CONFIG_CPU_ABRT_EV5T
# ifdef CPU_DABORT_HANDLER
# define MULTI_DABORT 1
# else
-# define CPU_DABORT_HANDLER v5tj_early_abort
+# define CPU_DABORT_HANDLER v5t_early_abort
# endif
#endif
-#ifdef CONFIG_CPU_ABRT_EV5T
+#ifdef CONFIG_CPU_ABRT_EV5TJ
# ifdef CPU_DABORT_HANDLER
# define MULTI_DABORT 1
# else
-# define CPU_DABORT_HANDLER v5t_early_abort
+# define CPU_DABORT_HANDLER v5tj_early_abort
# endif
#endif
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2] ARM:mach-msm: using strlcpy instead lof strncpy
From: Chen Gang @ 2013-01-30 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87pq0nni3v.fsf@nemi.mork.no>
The fields must be null-terminated, or next ptr, will cause issue
Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
arch/arm/mach-msm/clock-debug.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-msm/clock-debug.c b/arch/arm/mach-msm/clock-debug.c
index 4886404..c40dcaf 100644
--- a/arch/arm/mach-msm/clock-debug.c
+++ b/arch/arm/mach-msm/clock-debug.c
@@ -17,6 +17,7 @@
#include <linux/module.h>
#include <linux/ctype.h>
#include <linux/debugfs.h>
+#include <linux/string.h>
#include <linux/clk.h>
#include "clock.h"
@@ -104,7 +105,7 @@ int __init clock_debug_add(struct clk *clock)
if (!debugfs_base)
return -ENOMEM;
- strncpy(temp, clock->dbg_name, ARRAY_SIZE(temp)-1);
+ strlcpy(temp, clock->dbg_name, ARRAY_SIZE(temp));
for (ptr = temp; *ptr; ptr++)
*ptr = tolower(*ptr);
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Russell King - ARM Linux @ 2013-01-30 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359399397-29729-20-git-send-email-thomas.petazzoni@free-electrons.com>
On Mon, Jan 28, 2013 at 07:56:28PM +0100, Thomas Petazzoni wrote:
> +static resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
> + const struct resource *res,
> + resource_size_t start,
> + resource_size_t size,
> + resource_size_t align)
> +{
> + if (!(res->flags & IORESOURCE_IO))
> + return start;
> +
> + /*
> + * The I/O regions must be 64K aligned, because the
> + * granularity of PCIe I/O address decoding windows is 64 K
> + */
> + return round_up(start, SZ_64K);
> +}
You do realise that this will result in all PCI I/O BARs being rounded
up to 64K.
I've just been digging through the PCI code and have come across a
function - pcibios_window_alignment() - which the PCI code allows to be
overriden which allows you to increase the alignment requirement of
bridge windows. It takes the PCI bus and window type as arguments.
I'd suggest using that, and checking whether the bus which is passed
corresponds with a bus which gives you problems, so that you don't
impose the 64K requirement on downstream bridges.
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-30 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130113245.GH23505@n2100.arm.linux.org.uk>
Russell,
On Wed, 30 Jan 2013 11:32:46 +0000, Russell King - ARM Linux wrote:
> You do realise that this will result in all PCI I/O BARs being rounded
> up to 64K.
Hum, yes, correct.
> I've just been digging through the PCI code and have come across a
> function - pcibios_window_alignment() - which the PCI code allows to be
> overriden which allows you to increase the alignment requirement of
> bridge windows. It takes the PCI bus and window type as arguments.
>
> I'd suggest using that, and checking whether the bus which is passed
> corresponds with a bus which gives you problems, so that you don't
> impose the 64K requirement on downstream bridges.
Seems interesting indeed, I'll look into this idea! 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: Thomas Petazzoni @ 2013-01-30 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301301003.44272.arnd@arndb.de>
Dear Arnd Bergmann,
On Wed, 30 Jan 2013 10:03:43 +0000, Arnd Bergmann wrote:
> 0xfee00000 is the platform independent virtual address that pci_ioremap_io
> maps your platform specific physical address (from pcie->io.start) to. It's
> defined (in the kernel I am looking at) in asm/io.h as
>
> #define PCI_IO_VIRT_BASE 0xfee00000
>
> and used by pci_ioremap_io as
>
> return ioremap_page_range(PCI_IO_VIRT_BASE + offset,
> PCI_IO_VIRT_BASE + offset + SZ_64K,
> phys_addr,
> __pgprot(get_mem_type(MT_DEVICE)->prot_pte));
>
>
> > And it works just fine, I get my I/O ranges allocated at 0xc0000000 for
> > the first device, 0xc0010000 (i.e base address + 64KB) for the second
> > device, etc.
>
> (void*)0xc0000000 is the normal PAGE_OFFSET. If you map your I/O space there,
> you are in big trouble because that is supposed to have the start of your
> physical memory mapping.
Aaah, I know where the confusion comes from. You are talking about
virtual addresses, while I am talking about physical addresses.
0xC0000000 in my DT is a *physical* address.
Basically, with Marvell SoCs, we have the following behavior:
------- --------------------
Virtual address --> | MMU | --> Physical address --> | Address decoding | --> real hardware
------- --------------------
The MMU is the usual stuff everybody knows about. What's more special
about Marvell SoC is this "Address decoding" thing. Basically, instead
of having the physical address of things fully hardcoded and mentioned
in the datasheets, they are configurable. So for each PCIe interface,
you have to set up an address decoding window for the I/O accesses and
another address decoding window for the memory accesses. And the
physical address associated to each of these "address decoding windows"
can be freely chosen, so they must be "assigned" for each PCIe
interface.
So, my 0xC0000000 is a *physical* address is the diagram above. The
fact that it gets maps at 0xfee00000 as a virtual address doesn't
really matter for me, I'm just fine with that.
Does that clarify things?
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:omap2: using strlcpy instead of strncpy
From: Chen Gang @ 2013-01-30 11:46 UTC (permalink / raw)
To: linux-arm-kernel
the fields must be null-terminated:
the caller may use it as null-terminted string, next.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
arch/arm/mach-omap2/twl-common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index e49b40b..6a7aec6 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -23,6 +23,7 @@
#include <linux/i2c.h>
#include <linux/i2c/twl.h>
#include <linux/gpio.h>
+#include <linux/string.h>
#include <linux/regulator/machine.h>
#include <linux/regulator/fixed.h>
@@ -56,7 +57,7 @@ void __init omap_pmic_init(int bus, u32 clkrate,
struct twl4030_platform_data *pmic_data)
{
omap_mux_init_signal("sys_nirq", OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE);
- strncpy(pmic_i2c_board_info.type, pmic_type,
+ strlcpy(pmic_i2c_board_info.type, pmic_type,
sizeof(pmic_i2c_board_info.type));
pmic_i2c_board_info.irq = pmic_irq;
pmic_i2c_board_info.platform_data = pmic_data;
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Thomas Petazzoni @ 2013-01-30 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301300955.49473.arnd@arndb.de>
Dear Arnd Bergmann,
On Wed, 30 Jan 2013 09:55:49 +0000, Arnd Bergmann wrote:
> I don't remember the kernel ever caring about whether hardware complies
> to a standard or not. The kernel's job is to make hardware work, based
> on the actual implementation of that hardware. In a lot of cases that
> means taking the standard document as a reference, and adding quirks
> for the devices that are different.
>
> In the end, it comes down to the impact on the code complexity, and
> the run-time overhead for whatever hardware is most common when adding
> those quirks.
This is not only about standards, it is also about re-using the PCI
resource allocation code.
In my RFCv1, sent December, 7th, I wasn't using any emulated PCI-to-PCI
bridge. So it *can* perfectly work without it.
However, one major drawback of my RFCv1 version is that since I didn't
know how much I/O space and memory space was needed for each PCIe
device, I had to oversize the address decoding windows. And also, I had
to have a special allocator (certainly simple, but still) to find an
available physical address to set up each address decoding window.
Emulating a PCI-to-PCI bridge very nicely allows to re-use the PCI core
resource allocation code. I think it's really the main reason for
emulated those PCI-to-PCI bridges, rather than willing to comply to
some standards.
So what I'm going to do now is rework my patch series by removing the
emulated host bridge (which is normally mandatory by PCIe standard, but
Linux doesn't need it, so we don't care), but I'll keep the emulated
PCI-to-PCI bridges in order to benefit for the PCI core resource
allocation mechanisms.
Is this ok for you?
I'd like to settle on the strategy to follow, because we're really
going a funny road here: on December 7th, I submit a series that
doesn't use any PCI-to-PCI bridge, and I'm told that I should emulate
some. I spent a long time working on an implementation that uses
emumlated PCI-to-PCI bridges, which I submitted on Monday, now to be
told that I should work really hard not to use PCI-to-PCI bridges. I
hope you can feel my little embarrassment here...
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
* kernel 3.8 make problem
From: Jean-Francois Moine @ 2013-01-30 11:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I build the kernels in my Cubox (Marvel Dove), and it is no more
possible with kernels 3.8 while it works well with a kernel 3.5
(on the same machine - the kernels 3.5 and 3.8 have quite the
same .config).
Doing:
make oldconfig
returns:
Makefile:495: /home/jef/kernel/arch//Makefile: No such file or directory
make: *** No rule to make target `/home/jef/kernel/arch//Makefile'. Stop.
Going further, it seems that it is because the make command 'shell'
returns nothing. A simple Makefile as:
# Makefile
var=$(shell echo toto)
$(info var:$(var))
returns:
var:
make: *** No targets. Stop.
With strace, I get:
...
read(3, "var=$(shell echo toto)\n$(info va"..., 4096) = 43
pipe([4, 5]) = 0
vfork() = 3545
close(5) = 0
read(4, "", 200) = 0
close(4) = 0
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV}], 0, NULL) = 3545
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn() = ? (mask now [])
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f70000
write(1, "var:\n", 5var:
) = 5
...
What did I miss?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 2/3] arm: sunxi: Add clock definitions for the new clock driver
From: Emilio López @ 2013-01-30 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5108D8BE.1080906@free-electrons.com>
Hi Maxime,
El 30/01/13 05:24, Maxime Ripard escribi?:
> Hi Emilio,
>
> Le 22/01/2013 07:12, Emilio L?pez a ?crit :
>
>> + cpu: cpu at 01c20054 {
>> + #clock-cells = <0>;
>> + compatible = "allwinner,sunxi-cpu-clk";
>> + reg = <0x01c20054 0x4>;
>> + clocks = <&osc32k>, <&osc24M>, <&pll1>;
>> + };
>
> Why do you need these three clocks here ? From what you said in patch 3,
> it seems like the 24M oscillator is not a direct parent, but only the
> pll1 and the 32k oscillator, right?
There are two reasons:
* Hardware wise it actually is a parent, as in, it is an usable source
you can choose on the mux. There is also PLL6 as an option, but it has
no representation yet so I have not listed it.
Quoting the linux-sunxi wiki:
0x00 = 32 KHz internal RC clock
0x01 = 24 MHz external Oscillator
0x02 = PLL1
0x03 = 200 MHz sourced from PPL6
* The example in patch 3 is simplified, you may want to switch to the
24M oscillator first. My intention was to just present the concept/idea,
the actual clock handling on standby contains some more steps; see:
https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.0/arch/arm/mach-sun4i/pm/standby/standby.c#L179
Thanks for the review,
Emilio
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thierry Reding @ 2013-01-30 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130113245.GH23505@n2100.arm.linux.org.uk>
On Wed, Jan 30, 2013 at 11:32:46AM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 28, 2013 at 07:56:28PM +0100, Thomas Petazzoni wrote:
> > +static resource_size_t mvebu_pcie_align_resource(struct pci_dev *dev,
> > + const struct resource *res,
> > + resource_size_t start,
> > + resource_size_t size,
> > + resource_size_t align)
> > +{
> > + if (!(res->flags & IORESOURCE_IO))
> > + return start;
> > +
> > + /*
> > + * The I/O regions must be 64K aligned, because the
> > + * granularity of PCIe I/O address decoding windows is 64 K
> > + */
> > + return round_up(start, SZ_64K);
> > +}
>
> You do realise that this will result in all PCI I/O BARs being rounded
> up to 64K.
>
> I've just been digging through the PCI code and have come across a
> function - pcibios_window_alignment() - which the PCI code allows to be
> overriden which allows you to increase the alignment requirement of
> bridge windows. It takes the PCI bus and window type as arguments.
>
> I'd suggest using that, and checking whether the bus which is passed
> corresponds with a bus which gives you problems, so that you don't
> impose the 64K requirement on downstream bridges.
That approach isn't going to work very well with multi-platform, though,
since the function can only be overridden on a per-architecture basis.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130130/74cffa44/attachment.sig>
^ permalink raw reply
* [PATCH v2 00/30] USB: omap-ehci: Move PHY management to PHY driver
From: Mohammed, Afzal @ 2013-01-30 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359372631-8180-1-git-send-email-rogerq@ti.com>
Hi Roger,
On Mon, Jan 28, 2013 at 17:00:01, Quadros, Roger wrote:
> NOTE: Tested on 4460ES-B1 Panda and BeagleBoard C4 only. Other boards are only
> build tested.
Please try to ensure that beagle bone USB0 works with this.
Regards
Afzal
^ permalink raw reply
* [PATCH] Asoc: Samsung: I2S: Add support for runtime S2R
From: R. Chandrasekar @ 2013-01-30 12:11 UTC (permalink / raw)
To: linux-arm-kernel
From: "R. Chandrasekar" <rcsekar@samsung.com>
This patch adds runtime suspend to resume support for I2S.
I2S clk is disabled at suspend and enabled at resume.
Signed-off-by: R. Chandrasekar <rcsekar@samsung.com>
Signed-off-by: Padmavathi Venna <padma.v@samsung.com>
---
sound/soc/samsung/i2s.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 2fc42f9..d7231e3 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -1071,6 +1071,26 @@ static inline int samsung_i2s_get_driver_data(struct platform_device *pdev)
return platform_get_device_id(pdev)->driver_data;
}
+#ifdef CONFIG_PM_RUNTIME
+static int i2s_runtime_suspend(struct device *dev)
+{
+ struct i2s_dai *i2s = dev_get_drvdata(dev);
+
+ clk_disable_unprepare(i2s->clk);
+
+ return 0;
+}
+
+static int i2s_runtime_resume(struct device *dev)
+{
+ struct i2s_dai *i2s = dev_get_drvdata(dev);
+
+ clk_prepare_enable(i2s->clk);
+
+ return 0;
+}
+#endif /* CONFIG_PM_RUNTIME */
+
static int samsung_i2s_probe(struct platform_device *pdev)
{
struct i2s_dai *pri_dai, *sec_dai = NULL;
@@ -1288,6 +1308,11 @@ static const struct of_device_id exynos_i2s_match[] = {
MODULE_DEVICE_TABLE(of, exynos_i2s_match);
#endif
+static const struct dev_pm_ops samsung_i2s_pm = {
+ SET_RUNTIME_PM_OPS(i2s_runtime_suspend,
+ i2s_runtime_resume, NULL)
+};
+
static struct platform_driver samsung_i2s_driver = {
.probe = samsung_i2s_probe,
.remove = samsung_i2s_remove,
@@ -1296,6 +1321,7 @@ static struct platform_driver samsung_i2s_driver = {
.name = "samsung-i2s",
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(exynos_i2s_match),
+ .pm = &samsung_i2s_pm,
},
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 15/15] ARM: vexpress/dcscb: probe via device tree
From: Achin Gupta @ 2013-01-30 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301291634140.6300@xanadu.home>
On Tue, Jan 29, 2013 at 9:41 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Tue, 29 Jan 2013, Rob Herring wrote:
>
>> On 01/29/2013 01:51 AM, Nicolas Pitre wrote:
>> > This allows for the DCSCB support to be compiled in and selected
>> > at run time.
>>
>> Shouldn't this just be rolled into the commit creating dcscb.c?
>
> Probably, yes.
>
>> > Signed-off-by: Nicolas Pitre <nico@linaro.org>
>> > ---
>> > arch/arm/mach-vexpress/dcscb.c | 9 ++++++---
>> > 1 file changed, 6 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-vexpress/dcscb.c b/arch/arm/mach-vexpress/dcscb.c
>> > index 58051ffafb..a724507cbc 100644
>> > --- a/arch/arm/mach-vexpress/dcscb.c
>> > +++ b/arch/arm/mach-vexpress/dcscb.c
>> > @@ -14,6 +14,7 @@
>> > #include <linux/io.h>
>> > #include <linux/spinlock.h>
>> > #include <linux/errno.h>
>> > +#include <linux/of_address.h>
>> > #include <linux/vexpress.h>
>> > #include <linux/arm-cci.h>
>> >
>> > @@ -24,8 +25,6 @@
>> > #include <asm/cp15.h>
>> >
>> >
>> > -#define DCSCB_PHYS_BASE 0x60000000
>> > -
>> > #define RST_HOLD0 0x0
>> > #define RST_HOLD1 0x4
>> > #define SYS_SWRESET 0x8
>> > @@ -215,10 +214,14 @@ extern void dcscb_power_up_setup(unsigned int affinity_level);
>> >
>> > static int __init dcscb_init(void)
>> > {
>> > + struct device_node *node;
>> > unsigned int cfg;
>> > int ret;
>> >
>> > - dcscb_base = ioremap(DCSCB_PHYS_BASE, 0x1000);
>> > + node = of_find_compatible_node(NULL, NULL, "arm,dcscb");
>>
>> This needs binding documentation and should be a more specific name. Not
>> knowing what dcscb is, I don't have a suggestion.
>
> Yes, I mentioned in the cover page that DT bindings are not yet
> documented.
>
> DCSCB stands for "Dual Cluster System Control Block". This is in fact a
> set of miscellaneous registers, mainly for reset control of individual
> CPUs and clusters.
>
>> Perhaps should include vexpress or specific core tile name it is part
>> of.
>
> /me hopes for some ARM dude more acquainted with their nomenclature to
> chime in with suggestions.
>
As nico said, the DCSCB is just a reset controller thats a part of the
FastModels implementation. The implementation should be referred to as
VE bL RTSM. The official name goes by:
RTSM_VE_Cortex-A15x4-A7x4
RTSM_VE_Cortex-A15x1-A7x1
The file should be renamed as bL_rtsm.c or something similar.
Thanks,
Achin
^ permalink raw reply
* [RFC 3/3] arm: mach-mxs: make enabling enet_out a legacy function
From: Shawn Guo @ 2013-01-30 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130075832.GA13075@pengutronix.de>
On Wed, Jan 30, 2013 at 08:58:32AM +0100, Wolfram Sang wrote:
> On Wed, Jan 30, 2013 at 01:48:40PM +0800, Shawn Guo wrote:
> > On Tue, Jan 29, 2013 at 03:46:13PM +0100, Wolfram Sang wrote:
> > > @@ -351,7 +359,7 @@ static void __init tx28_post_init(void)
> > > struct pinctrl *pctl;
> > > int ret;
> > >
> > > - enable_clk_enet_out();
> > > + legacy_enable_clk_enet_out();
> >
> > I think TX28 is the only case that really needs to turn on enet_out
> > clock at platform level, since it has some dirty work about PHY to do
> > here. With with fec driver handling the clock, enable_clk_enet_out()
> > can just be removed for other boards.
>
> I would love to, but this will cause regression on boards which update
> the kernel but not the devicetree (no third clock), or?
>
Ah, that's the consideration. When someday arch/arm/boot/dts gets
maintained outside kernel tree, we may be required to keep devicetree
compatibility to different kernel versions. But we haven't got there
yet. Today people are supposed to use devicetree matching kernel.
Shawn
^ permalink raw reply
* [PATCH] ARM:boot: support the command with COMMAND_LINE_SIZE - 1 useful chars
From: Chen Gang @ 2013-01-30 12:32 UTC (permalink / raw)
To: linux-arm-kernel
originally, not support the command with COMMAND_LINE_SIZE - 1 useful chars.
but in fact, we can support it:
Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
arch/arm/boot/compressed/atags_to_fdt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
index aabc02a..ed23ec2 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -63,7 +63,7 @@ static void merge_fdt_bootargs(void *fdt, const char *fdt_cmdline)
/* copy the fdt command line into the buffer */
fdt_bootargs = getprop(fdt, "/chosen", "bootargs", &len);
if (fdt_bootargs)
- if (len < COMMAND_LINE_SIZE) {
+ if (len <= COMMAND_LINE_SIZE) {
memcpy(ptr, fdt_bootargs, len);
/* len is the length of the string
* including the NULL terminator */
@@ -73,7 +73,7 @@ static void merge_fdt_bootargs(void *fdt, const char *fdt_cmdline)
/* and append the ATAG_CMDLINE */
if (fdt_cmdline) {
len = strlen(fdt_cmdline);
- if (ptr - cmdline + len + 2 < COMMAND_LINE_SIZE) {
+ if (ptr - cmdline + len + 2 <= COMMAND_LINE_SIZE) {
*ptr++ = ' ';
memcpy(ptr, fdt_cmdline, len);
ptr += len;
--
1.7.10.4
^ permalink raw reply related
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