* [RFC PATCH 1/2] ARM: kernel: update cpuinfo to print CPU model name
From: anish singh @ 2013-01-30 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5108B532.6000706@ti.com>
On Wed, Jan 30, 2013 at 11:22 AM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On Wednesday 30 January 2013 04:42 AM, Ruslan Bilovol wrote:
>>
>> Hi,
>>
>> On Tue, Jan 29, 2013 at 6:08 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>>
>>> 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
Wouldn't it be nice to display the name rather than hex?I think this would have
definitely occurred to Russell but it is still done this way.I think
there would be
a valid reason for this and it would be nice to know that.
If not then I can cook up a patch.
>>> this CPU. Did ARM Ltd really implement OMAP4470 ? I think TI would be
>>> very upset if that were to be the case.
>>
>>
>> Yes, it would be very surprisingly :)
>>
>>>
>>> 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.
>>
>>
>> Completely agree with you. I will fix this
>>
> Thank god you agreed to drop your current approach. Please elaborate
> what you are going to fix and also state what user-space features
> changes from OMAP4460 to OMAP4470.
>
> Regards,
> Santosh
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] ARM: ux500: rename ab8500 to abx500 for hwmon driver
From: Hongbo Zhang @ 2013-01-30 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359531747-3636-1-git-send-email-hongbo.zhang@linaro.org>
Hi Linus Walleij,
This is for upstreaming AB8500 hwmon, see another Email:
[PATCH] hwmon: add ST-Ericsson ABX500 hwmon driver
On 30 January 2013 15:42, Hongbo Zhang <hongbo.zhang@linaro.org> wrote:
> We are using a generic abx500 hwmon layer, so rename specific ab8500 to generic
> abx500 for hwmon device and driver matching.
>
> Signed-off-by: Hongbo Zhang <hongbo.zhang@linaro.org>
> ---
> drivers/mfd/ab8500-core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
> index e1650ba..579753f 100644
> --- a/drivers/mfd/ab8500-core.c
> +++ b/drivers/mfd/ab8500-core.c
> @@ -922,7 +922,7 @@ static struct resource ab8505_iddet_resources[] = {
>
> static struct resource ab8500_temp_resources[] = {
> {
> - .name = "AB8500_TEMP_WARM",
> + .name = "ABX500_TEMP_WARM",
> .start = AB8500_INT_TEMP_WARM,
> .end = AB8500_INT_TEMP_WARM,
> .flags = IORESOURCE_IRQ,
> @@ -998,8 +998,8 @@ static struct mfd_cell abx500_common_devs[] = {
> .of_compatible = "stericsson,ab8500-denc",
> },
> {
> - .name = "ab8500-temp",
> - .of_compatible = "stericsson,ab8500-temp",
> + .name = "abx500-temp",
> + .of_compatible = "stericsson,abx500-temp",
> .num_resources = ARRAY_SIZE(ab8500_temp_resources),
> .resources = ab8500_temp_resources,
> },
> --
> 1.8.0
>
^ permalink raw reply
* [RFC 3/3] arm: mach-mxs: make enabling enet_out a legacy function
From: Wolfram Sang @ 2013-01-30 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130054833.GA24450@S2100-06.ap.freescale.net>
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?
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130130/f802a8ba/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/3] pwm: Add pwm_can_sleep() as exported API to users
From: Thierry Reding @ 2013-01-30 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359381659-24454-2-git-send-email-florian.vaussard@epfl.ch>
On Mon, Jan 28, 2013 at 03:00:57PM +0100, Florian Vaussard wrote:
> Calls to some external PWM chips can sleep. To help users,
> add pwm_can_sleep() API.
>
> Cc: Thierry Reding <thierry.reding@avionic-design.de>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
> drivers/pwm/core.c | 12 ++++++++++++
> include/linux/pwm.h | 10 ++++++++++
> 2 files changed, 22 insertions(+), 0 deletions(-)
Applied (with a minor fixup to the kerneldoc comment), thanks.
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/ea77a483/attachment.sig>
^ permalink raw reply
* [PATCH v3 2/3] pwm: Add can_sleep property to drivers
From: Thierry Reding @ 2013-01-30 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359381659-24454-3-git-send-email-florian.vaussard@epfl.ch>
On Mon, Jan 28, 2013 at 03:00:58PM +0100, Florian Vaussard wrote:
> Calls to PWM drivers connected through I2C can sleep.
> Use the new can_sleep property.
>
> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
> drivers/pwm/pwm-twl-led.c | 1 +
> drivers/pwm/pwm-twl.c | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
Applied, thanks.
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/a2d8738d/attachment.sig>
^ permalink raw reply
* [PATCH 0/3] clock driver for sunxi
From: Maxime Ripard @ 2013-01-30 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358835176-7197-1-git-send-email-emilio@elopez.com.ar>
Hi Emilio,
Le 22/01/2013 07:12, Emilio L?pez a ?crit :
> Hello everyone,
>
> This patchset adds basic clock support for sunxi devices. Currently, it
> implements support for the two oscillators, the main PLL, the CPU mux,
> and its three divisor clocks. With this in place, it is possible to
> write a cpufreq driver and have it work.
>
> I have tested this driver successfully on a Cubieboard (A10, sun4i)
> using the cpufreq driver from the linux-sunxi tree after minor
> modifications (the clock names are not the same).
Thanks for doing this. I'll try to test it on my boards this week.
I don't have a lot of comments, but Mike will probably have some.
Maxime
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 3/3] leds: leds-pwm: Defer led_pwm_set() if PWM can sleep
From: Thierry Reding @ 2013-01-30 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359381659-24454-4-git-send-email-florian.vaussard@epfl.ch>
On Mon, Jan 28, 2013 at 03:00:59PM +0100, Florian Vaussard wrote:
> Call to led_pwm_set() can happen inside atomic context, like triggers.
> If the PWM call can sleep, defer using a worker.
>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
> drivers/leds/leds-pwm.c | 50 +++++++++++++++++++++++++++++++++++++++-------
> 1 files changed, 42 insertions(+), 8 deletions(-)
Bryan, I assume that you'll be taking this? It doesn't apply cleanly to
my tree, probably because of Peter's recent changes that you took
through your tree and Florian based his patches on top of that. The
conflict resolution should be trivial, though.
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/68110b04/attachment.sig>
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Thomas Petazzoni @ 2013-01-30 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130045655.GE5734@obsidianresearch.com>
Dear Jason Gunthorpe,
On Tue, 29 Jan 2013 21:56:55 -0700, Jason Gunthorpe wrote:
> However, Thomas how did you recover the high bits of the
> IO window address from the bridge configuration? Are you reading the
> struct resource directly? That probably causes problems with
> hotplug/etc...
The PCI-to-PCI bridge configuration space has a register with the high
bits of the I/O window address. If you look at the PCI-to-PCI emulation
code, I set the bit that says "I'm a bridge capable of 32 bits
addressing of I/O addresses", and then when setting up the windows, I
reconstruct the full 32 bits address by reading the two I/O address
registers.
See 3.2.5.6 in the PCI-to-PCI bridge specification:
If the low four bits of the I/O Base and I/O Limit registers are 01h,
then the bridge supports 32-bit I/O address decoding, and the I/O
Base Upper 16 Bits and the I/O Limit Upper 16 Bits hold the upper 16
bits, corresponding to AD[31::16], of the 32-bit I/O Base and I/O
Limit addresses respectively. In this case, system configuration
software is permitted to locate the I/O address range supported by
the anywhere in the 4-GB I/O Space. Note that the 4-KB alignment and
granularity restrictions still apply when the bridge supports 32 -bit
I/O addressing.
(And my code does ensure that the low four bits of the I/O Base and I/O
Limit registers are 01h)
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/3] arm: sunxi: Add clock definitions for the new clock driver
From: Maxime Ripard @ 2013-01-30 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358835176-7197-3-git-send-email-emilio@elopez.com.ar>
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?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Simon Baatz @ 2013-01-30 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51086E86.8040705@gmail.com>
On Wed, Jan 30, 2013 at 01:51:18AM +0100, Sebastian Hesselbarth wrote:
> above using CLK_IGNORE_UNUSED on runit maybe is the best.
> >Fine with all of that. But: I am talking about 3.8 all the time. We
> >have three options for issues 2 and 3 from my point of view:
> >
> >1. We do proper fixes in 3.8 for issues 2 and 3.
> >
> >2. We fix this regression by not gating the clock in both the DT and
> >the non-DT case, preferably by using the correct clocks in
> >kirkwood_ge0[01]_init(). Additionally, Jason promises that all gets
> >well with the DT aware driver in 3.9. ;-)
> >
> >3. Do nothing. Simply accept that we broke modular Ethernet for DT
> >because some code relies on two pointers being set. When we
> >introduced a new code path for DT, we forgot about these pointers.
> >Bad luck, the solution was not nice anyway and we will do proper
> >fixes in 3.9.
> >
> >As should be clear by now, I think we should go for option 2.
>
> Agreed, do you think all issues you are suffering will be solved with:
>
> - [PATCH v2 2/2] clk: mvebu: Do not gate runit clock on Kirkwood
> (no lockup for minimal kernel configs)
>
> - [PATCH] NET: mv643xx: get smi clock from device tree
> (no lockup for modular DT ethernet)
>
> - Some patch that adds MV643XX_ETH_SHARED_NAME ".0" and ".1" clk aliases
> (no lockup for modular non-DT ethernet)
I think your patch to get the smi clock is intended for device tree.
Thus, the driver won't use these aliases, right?
> - Some patch that adds clk_prepare_enable to ge0/ge1 clocks to
> kirkwood_legacy_clk_init()
> (retain MAC address for modular DT ethernet)
I like mine better, since it only enables the clocks of the
interfaces that are initialized in the init code. I tested it with
non-DT as well. But either is fine with me.
> I'll prepare the latter patches and post them.
Thanks!
- Simon
^ permalink raw reply
* i.Mx6Quad - eth0: tx queue full!
From: Duan Fugang-B38611 @ 2013-01-30 8:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51081910.4030707@boundarydevices.com>
Hi, all
The issue cannot be found kernel 3.0.35 branch: (even run stress test with IPU and VPU)
ssh://sw-git01-tx30/git/sw_git/repos/linux-2.6-imx.git
branch name: imx_3.0.35
The patch as below:
>From 91a0c892263e57ecde9e9ff38be3acdb7f66a17f Mon Sep 17 00:00:00 2001
From: Fugang Duan <B38611@freescale.com>
Date: Thu, 9 Aug 2012 17:59:44 +0800
Subject: [PATCH] ENGR00180288 - FEC : Fix kernel dump about eth0
Kernel dump when do wifi stress test with suspend and resume as below:
eth0: tx queue full!.
remove wake up source irq 103
PM: resume of devices complete after 348.934 msecs
Restarting tasks ... done.
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x284/0x2a8()
NETDEV WATCHDOG: eth0 (fec): transmit queue 0 timed out
Modules linked in: ar6000
[<8004482c>] (unwind_backtrace+0x0/0xf8) from
[<80068cd0>] (warn_slowpath_common+0x4c/0x64)
[<80068cd0>] (warn_slowpath_common+0x4c/0x64)from
[<80068d7c>] (warn_slowpath_fmt+0x30/0x40)
[<80068d7c>] (warn_slowpath_fmt+0x30/0x40) from
[<803f0c50>] (dev_watchdog+0x284/0x2a8)
[<803f0c50>] (dev_watchdog+0x284/0x2a8) from
[<80074430>] (run_timer_softirq+0xec/0x214)
[<80074430>] (run_timer_softirq+0xec/0x214) from
[<8006e524>] (__do_softirq+0xac/0x140)
[<8006e524>] (__do_softirq+0xac/0x140) from
[<8006ea60>] (irq_exit+0x94/0x9c)
[<8006ea60>] (irq_exit+0x94/0x9c) from
[<80039240>] (do_local_timer+0x54/0x70)
[<80039240>] (do_local_timer+0x54/0x70) from
[<8003ea0c>] (__irq_svc+0x4c/0xe8)
Exception stack(0x80a2bf68 to 0x80a2bfb0)
bf60: 0000001f 80a3babc 80a2bfb0 00000000 80a2a000 80a7b8e4
bf80: 804befcc 80a3ee7c 1000406a 412fc09a 00000000 00000000 80a81440 80a2bfb0
bfa0: 8003fa64 8003fa68 60000013 ffffffff
[<8003ea0c>] (__irq_svc+0x4c/0xe8) from [<8003fa68>] (default_idle+0x24/0x28)
[<8003fa68>] (default_idle+0x24/0x28) from [<8003fc60>] (cpu_idle+0xbc/0xfc)
[<8003fc60>] (cpu_idle+0xbc/0xfc) from [<80008878>] (start_kernel+0x258/0x29c)
[<80008878>] (start_kernel+0x258/0x29c) from [<10008040>] (0x10008040)
---[ end trace 30671ac42e272c2d ]---
But ethernet and system still be alive. In sometime,the issue
will cause system hang like "nfs: server 10.192.242.179 not
responding, still trying".
The root cause is tx buffer descriptors are not cleaned when
ethernet resume back.
Signed-off-by: Fugang Duan <B38611@freescale.com>
drivers/net/fec.c | 39 ++++++++++++++++++++++++++-------------
1 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index f007bf0..b1fa464 100755
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -1456,6 +1456,28 @@ static const struct net_device_ops fec_netdev_ops = {
#endif
};
+/* Init TX buffer descriptors
+ */
+static void fec_enet_txbd_init(struct net_device *dev)
+{
+ struct fec_enet_private *fep = netdev_priv(dev);
+ struct bufdesc *bdp;
+ int i;
+
+ /* ...and the same for transmit */
+ bdp = fep->tx_bd_base;
+ for (i = 0; i < TX_RING_SIZE; i++) {
+
+ /* Initialize the BD for every fragment in the page. */
+ bdp->cbd_sc = 0;
+ bdp++;
+ }
+
+ /* Set the last buffer to wrap */
+ bdp--;
+ bdp->cbd_sc |= BD_SC_WRAP;
+}
+
/*
* XXX: We need to clean up on failure exits here.
*
@@ -1512,19 +1534,8 @@ static int fec_enet_init(struct net_device *ndev)
bdp--;
bdp->cbd_sc |= BD_SC_WRAP;
- /* ...and the same for transmit */
- bdp = fep->tx_bd_base;
- for (i = 0; i < TX_RING_SIZE; i++) {
-
- /* Initialize the BD for every fragment in the page. */
- bdp->cbd_sc = 0;
- bdp->cbd_bufaddr = 0;
- bdp++;
- }
-
- /* Set the last buffer to wrap */
- bdp--;
- bdp->cbd_sc |= BD_SC_WRAP;
+ /* Init transmit descriptors */
+ fec_enet_txbd_init(ndev);
fec_restart(ndev, 0);
@@ -1575,6 +1586,8 @@ fec_restart(struct net_device *dev, int duplex)
writel(fep->bd_dma, fep->hwp + FEC_R_DES_START);
writel((unsigned long)fep->bd_dma + sizeof(struct bufdesc) * RX_RING_SIZE,
fep->hwp + FEC_X_DES_START);
+ /* Reinit transmit descriptors */
+ fec_enet_txbd_init(dev);
fep->dirty_tx = fep->cur_tx = fep->tx_bd_base;
fep->cur_rx = fep->rx_bd_base;
--
1.7.0.4
Thanks,
Andy
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner at vger.kernel.org] On Behalf Of Troy Kisky
Sent: Wednesday, January 30, 2013 2:47 AM
To: Vikram Narayanan
Cc: netdev at vger.kernel.org; Greg Ungerer; shawn.guo at linaro.org; LAK; Uwe Kleine-K?nig; Fabio Estevam
Subject: Re: i.Mx6Quad - eth0: tx queue full!
On 1/29/2013 9:34 AM, Vikram Narayanan wrote:
> On 1/29/2013 1:17 AM, Troy Kisky wrote:
>> On 1/28/2013 10:39 AM, Vikram Narayanan wrote:
>>> Running the latest head <linux-2.6.git> on an i.Mx6Quad based
>>> platform gives me the below error when flooded with ping requests.
>>>
>>> == Start log ==
>>> [ 2555.004031] ------------[ cut here ]------------ [ 2555.009740]
>>> WARNING: at net/sched/sch_generic.c:254
>>> dev_watchdog+0x298/0x2b8()
>>> [ 2555.018721] NETDEV WATCHDOG: eth0 (fec): transmit queue 0 timed
>>> out
>>
>> I think the tx interrupt status bit was lost. The packets were
>> transmitted, but the interrupt never happened. The controller should
>> have been reset here, but perhaps a bug with the reset code.
>> Are you using the mainline kernel, or a version Freescale's kernel.
>
> I tried with both the kernels. Freescale's and mainline results in the
> same error.
>
>> mainline fec_restart does not reset tx_full
>>
>> You can try adding
>> fep->tx_full = 0;
>
> With this there was no improvement.
I have fixed this bug (and more) on Freescale's kernel (imx-3.0.35_1.1.0). I created a branch you can try.
Feel free to port to mainline.
This is the patch that should fix your problem
fec: clear TX_FULL in fec_restart
git://github.com/boundarydevices/linux-imx6.git ethernet_test
Please let me know results.
Thanks
Troy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
From: Kumar, Anil @ 2013-01-30 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5108C052.3070604@ti.com>
Hi Sourav,
On Wed, Jan 30, 2013 at 12:10:18, Poddar, Sourav wrote:
> Hi Luciano,
> On Wednesday 30 January 2013 11:55 AM, Luciano Coelho wrote:
> > Hi Sourav,
> >
> > On Mon, 2013-01-28 at 16:47 +0530, Sourav Poddar wrote:
> >> Booting 3.8-rc4 om omap 4430sdp results in the following error
> >>
> >> omap_i2c 48070000.i2c: did not get pins for i2c error: -19
> >> [ 1.024261] omap_i2c 48070000.i2c: bus 0 rev0.12 at 100 kHz
> >> [ 1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
> >> [ 1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
> >> [ 1.043762] omap_i2c 48060000.i2c: did not get pins for i2c error: -19
> >> [ 1.050964] omap_i2c 48060000.i2c: bus 2 rev0.12 at 100 kHz
> >> [ 1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
> >> [ 1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
> >>
> >> This happens because omap4 dts file is not adapted to use i2c through pinctrl
> >> framework. Populating i2c pinctrl data to get rid of the error.
> >>
> >> Tested on omap4430 sdp with 3.8-rc4 kernel.
> >>
> >> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
> >> Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >> ---
> > Could you do the same thing for panda? I'm getting the same kind of
> > errors with it:
omap4 uses pinctrl-single driver for pinmux with DT. Currently
pinctrl-single driver is getting up after I2C driver. So I2c cannot
use pinctrl. The below patch solve this issue
http://www.gossamer-threads.com/lists/linux/kernel/1669067
Can you try with this ? it may solve it.
Thanks,
Anil
[...]
^ permalink raw reply
* [PATCH] ARM: at91: at91sam9x5.dtsi:usart3 TXD
From: Douglas Gilbert @ 2013-01-30 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51083A70.1070809@interlog.com>
On 13-01-29 10:09 PM, Douglas Gilbert wrote:
> Comment for usart3 TXD (TXD3) is correct, dt code is wrong.
>
> The patch is against lk 3.8.0-rc5 .
Actually this patch also depends on a patch by Robert Nelson
titled: "[PATCH] ARM: at91: at91sam9x5: fix usart3 pinctrl name"
posted on Monday 28 January, 2013. Two separate bugs in
3 lines of code, not bad going :-)
Doug Gilbert
^ permalink raw reply
* [PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
From: Santosh Shilimkar @ 2013-01-30 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <F3DBB1B3EF102E4994C89758CFCA32412C16DD@DBDE01.ent.ti.com>
On Wednesday 30 January 2013 02:13 PM, Kumar, Anil wrote:
> Hi Sourav,
>
> On Wed, Jan 30, 2013 at 12:10:18, Poddar, Sourav wrote:
>> Hi Luciano,
>> On Wednesday 30 January 2013 11:55 AM, Luciano Coelho wrote:
>>> Hi Sourav,
>>>
>>> On Mon, 2013-01-28 at 16:47 +0530, Sourav Poddar wrote:
>>>> Booting 3.8-rc4 om omap 4430sdp results in the following error
>>>>
>>>> omap_i2c 48070000.i2c: did not get pins for i2c error: -19
>>>> [ 1.024261] omap_i2c 48070000.i2c: bus 0 rev0.12 at 100 kHz
>>>> [ 1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
>>>> [ 1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
>>>> [ 1.043762] omap_i2c 48060000.i2c: did not get pins for i2c error: -19
>>>> [ 1.050964] omap_i2c 48060000.i2c: bus 2 rev0.12 at 100 kHz
>>>> [ 1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
>>>> [ 1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
>>>>
>>>> This happens because omap4 dts file is not adapted to use i2c through pinctrl
>>>> framework. Populating i2c pinctrl data to get rid of the error.
>>>>
>>>> Tested on omap4430 sdp with 3.8-rc4 kernel.
>>>>
>>>> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
>>>> Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>>> ---
>>> Could you do the same thing for panda? I'm getting the same kind of
>>> errors with it:
>
> omap4 uses pinctrl-single driver for pinmux with DT. Currently
> pinctrl-single driver is getting up after I2C driver. So I2c cannot
> use pinctrl. The below patch solve this issue
>
> http://www.gossamer-threads.com/lists/linux/kernel/1669067
>
> Can you try with this ? it may solve it.
>
OMAP i2c driver already takes care of -EPROBE_DEFER. The issue
as you see from the log is not probe failure but missing the
pin information in DT blob. And thats what patch does.
Regards
santosh
^ permalink raw reply
* [BUG] snowball board locks up on boot
From: Lee Jones @ 2013-01-30 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZU80XB2GiDtc7nh0hgMpyVYesi+xwhndu50jGS1L=wiw@mail.gmail.com>
> > I tried to get my snowball board working on the latest kernel, but it
> > locks up hard very early on boot up.
> >
> > I bisected it down to this commit:
> >
> > commit ebc96db7632f987e0b9bffcb782cf5cfb8afb0dd
> > Author: Ulf Hansson <ulf.hansson@linaro.org>
> > Date: Mon Aug 27 15:45:53 2012 +0200
> >
> > ARM: ux500: Switch to use common clock framework
>
> Yeah the new common clock framework is a bit like a heart
> transplant on the platforms you convert, some fallout is expected.
>
> However I thought we had all the clk fixes covered by -rc4 :-(
>
> I don't have a Snowball right now myself, so have to ask
> for help here (non snowball ux500's work just fine for me).
>
> Lee, are you still booting the Snowball on new kernels
> everyday, and do you know if some fix is still missing?
Can you provide your bootlog please Steven?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] ARM: at91: at91sam9x5.dtsi:usart3 TXD
From: Nicolas Ferre @ 2013-01-30 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5108DE57.4090905@interlog.com>
On 01/30/2013 09:48 AM, Douglas Gilbert :
> On 13-01-29 10:09 PM, Douglas Gilbert wrote:
>> Comment for usart3 TXD (TXD3) is correct, dt code is wrong.
>>
>> The patch is against lk 3.8.0-rc5 .
>
> Actually this patch also depends on a patch by Robert Nelson
> titled: "[PATCH] ARM: at91: at91sam9x5: fix usart3 pinctrl name"
> posted on Monday 28 January, 2013. Two separate bugs in
> 3 lines of code, not bad going :-)
Okay, I try to queue both of them for 3.8-fixes...
Thanks, bye,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
From: Luciano Coelho @ 2013-01-30 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5108DE5F.5090803@ti.com>
On Wed, 2013-01-30 at 14:18 +0530, Santosh Shilimkar wrote:
> On Wednesday 30 January 2013 02:13 PM, Kumar, Anil wrote:
> > Hi Sourav,
> >
> > On Wed, Jan 30, 2013 at 12:10:18, Poddar, Sourav wrote:
> >> Hi Luciano,
> >> On Wednesday 30 January 2013 11:55 AM, Luciano Coelho wrote:
> >>> Hi Sourav,
> >>>
> >>> On Mon, 2013-01-28 at 16:47 +0530, Sourav Poddar wrote:
> >>>> Booting 3.8-rc4 om omap 4430sdp results in the following error
> >>>>
> >>>> omap_i2c 48070000.i2c: did not get pins for i2c error: -19
> >>>> [ 1.024261] omap_i2c 48070000.i2c: bus 0 rev0.12 at 100 kHz
> >>>> [ 1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
> >>>> [ 1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
> >>>> [ 1.043762] omap_i2c 48060000.i2c: did not get pins for i2c error: -19
> >>>> [ 1.050964] omap_i2c 48060000.i2c: bus 2 rev0.12 at 100 kHz
> >>>> [ 1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
> >>>> [ 1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
> >>>>
> >>>> This happens because omap4 dts file is not adapted to use i2c through pinctrl
> >>>> framework. Populating i2c pinctrl data to get rid of the error.
> >>>>
> >>>> Tested on omap4430 sdp with 3.8-rc4 kernel.
> >>>>
> >>>> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
> >>>> Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >>>> ---
> >>> Could you do the same thing for panda? I'm getting the same kind of
> >>> errors with it:
> >
> > omap4 uses pinctrl-single driver for pinmux with DT. Currently
> > pinctrl-single driver is getting up after I2C driver. So I2c cannot
> > use pinctrl. The below patch solve this issue
> >
> > http://www.gossamer-threads.com/lists/linux/kernel/1669067
> >
> > Can you try with this ? it may solve it.
> >
> OMAP i2c driver already takes care of -EPROBE_DEFER. The issue
> as you see from the log is not probe failure but missing the
> pin information in DT blob. And thats what patch does.
Yes, Santosh is right. I tried this patch, but it didn't fix the
warnings.
--
Luca.
^ permalink raw reply
* [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
From: Santosh Shilimkar @ 2013-01-30 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129172410.GS15361@atomide.com>
On Tuesday 29 January 2013 10:54 PM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130129 05:59]:
>> OK so we do managed to clean up the address space, IRQ lines
>> and DMA request lines data from hwmod completely.
>>
>> -OMAP5 hwmod data file, 2076 lines we could remove which significant
>> reduction. I ran the same scripts on OMAP4 and there too about 2200
>> lines getting deleted.
>
> Great, thanks for looking into it. I guess we cannot do that quite
> yet for omap4 as we have not made it DT only. But we should be able
> to do that for am33xx as that's DT only already.
>
>> - I have to udapte DT file to add the all supported hwmods with reg
>> property so that OMAP5 continue to boot. Similar work is needed for
>> OMAP4 too once OMAP4 is made DT only support.
>
> OK
>
>> - To my suprise, the DT lookup isn't that bad. It is adding just
>> 24 milliseconds to the boot time which is more or less noise.
>
> That's good to hear.
>
>> Have pushed a branch with above update for OMAP5 here [1]
>>
>> So we are left with two other topics which you mentioned in the
>> comments.
>>
>> 1. Movement of clock data to drivers/clk. Till we get direction here
>> I would like to hear the alternative to get OMAP5 booting from mainline.
>> If there is no alternative, we can keep OMAP5 clock data alone
>> out of tree and get rest of the data files merged.
>
> I agree, no reason to hold back the other patches. But we should
> resolve the common clock move to drivers/clk properly now,
> otherwise it will just get postponed again and we have even bigger
> problem to deal with.
>
I will go ahead and separate the clock data from rest of the data
files so that we can get rest of the data patches in.
>> 2. The iormap() done by hwmod for sysconfig handling which you are
>> discussing with Rajendra. So far we don't have a viable way to
>> get the iormapped address from device drivers back to platform
>> code. Lets continue on this thread but this can evolve in
>> parallel.
>
> Yes that can be fixed separately.
>
Yep. Thanks for the comments.
Regards
Santosh
^ permalink raw reply
* [PATCH] ARM: at91: at91sam9x5: fix usart3 pinctrl name
From: Nicolas Ferre @ 2013-01-30 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359387816-11730-1-git-send-email-robertcnelson@gmail.com>
On 01/28/2013 04:43 PM, Robert Nelson :
> The renaming of pinctrl_uart3 to pinctrl_usart3 was missed in:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9e3129e937e2f178d2a003ea45765e5e63e34665
>
> Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
With little reformatting of commit message, queued in at91-fixes.
Thanks a lot!
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> arch/arm/boot/dts/at91sam9x5.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
> index 8ecca69..464e34f 100644
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@ -197,7 +197,7 @@
> };
>
> usart3 {
> - pinctrl_uart3: usart3-0 {
> + pinctrl_usart3: usart3-0 {
> atmel,pins =
> <2 23 0x2 0x1 /* PC22 periph B with pullup */
> 2 23 0x2 0x0>; /* PC23 periph B */
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] ARM: at91: at91sam9x5.dtsi:usart3 TXD
From: Nicolas Ferre @ 2013-01-30 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51083A70.1070809@interlog.com>
On 01/29/2013 10:09 PM, Douglas Gilbert :
> Comment for usart3 TXD (TXD3) is correct, dt code is wrong.
>
> The patch is against lk 3.8.0-rc5 .
>
> Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Queued in at91-fixes with little formating in message subject.
Thank for your help.
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Bye,
--
Nicolas Ferre
^ permalink raw reply
* [GIT PULL v3] arm-soc: Xilinx zynq timer changes for v3.9
From: Michal Simek @ 2013-01-30 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130021159.GA13897@quad.lixom.net>
2013/1/30 Olof Johansson <olof@lixom.net>:
> On Mon, Jan 28, 2013 at 01:53:11PM +0100, Michal Simek wrote:
>> Hi Olof,
>>
>> based on your previous email I am sending updated pull request which is based
>> on arm-soc depends/cleanup branch.
>> As I wrote in my email I tend to keep there Soren's patch around
>> renaming PSS to PS
>> and be more strict on this for future.
>> I have also added one more patch which fix Rob's conversion to irqchip_init.
>
> Ok, pulled. Sorry for the delay, I had forgotten this email halfway read on my
> machine at home, so it fell of my list of branches to pull earlier today.
>
>> btw: As I mentioned in the previous email I want to add 2 defconfig
>> updates + maintainer
>> fragment. I have created branch zynq/misc in the same repo. Is this
>> name ok for you?
>> If yes, I will send you separate pull request just for this branch.
>
> Ah, do'h, I replied to the previous email. Nevermind that suggestion then, I'll
> just pull the misc branch.
I just collection that patches just for sure not to be lost.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
^ permalink raw reply
* [PATCH] ARM:mach-msm: seting tail NUL after strncpy
From: Bjørn Mork @ 2013-01-30 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5108A913.6080304@asianux.com>
Chen Gang <gang.chen@asianux.com> writes:
> temp need NUL terminated, or next ptr may cause issue.
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> arch/arm/mach-msm/clock-debug.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-msm/clock-debug.c
> b/arch/arm/mach-msm/clock-debug.c
> index 4886404..bdca900 100644
> --- a/arch/arm/mach-msm/clock-debug.c
> +++ b/arch/arm/mach-msm/clock-debug.c
> @@ -105,6 +105,8 @@ int __init clock_debug_add(struct clk *clock)
> return -ENOMEM;
>
> strncpy(temp, clock->dbg_name, ARRAY_SIZE(temp)-1);
> + temp[ARRAY_SIZE(temp)-1] = '\0';
> +
> for (ptr = temp; *ptr; ptr++)
> *ptr = tolower(*ptr);
Maybe use strlcpy() instead?
Bj?rn
^ permalink raw reply
* [PATCH] ARM: ux500: enable ux500 EXT4_FS and LBDAF support by default
From: Hongbo Zhang @ 2013-01-30 9:21 UTC (permalink / raw)
To: linux-arm-kernel
EXT4 file system and LBDAF are used commonly, should be enabled by default.
Signed-off-by: Hongbo Zhang <hongbo.zhang@linaro.org>
---
arch/arm/configs/u8500_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index 231dca6..746c8a2 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
@@ -5,7 +5,6 @@ CONFIG_BLK_DEV_INITRD=y
CONFIG_KALLSYMS_ALL=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
-# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
CONFIG_ARCH_U8500=y
CONFIG_MACH_HREFV60=y
@@ -103,6 +102,7 @@ CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
+CONFIG_EXT4_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
--
1.8.0
^ permalink raw reply related
* [PATCH v6 09/10] spi: omap2-mcspi: add generic DMA request support to the DT binding
From: Arnd Bergmann @ 2013-01-30 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359529229-22207-10-git-send-email-mporter@ti.com>
On Wednesday 30 January 2013, Matt Porter wrote:
> +Optional properties:
> +- dmas: List of DMA controller phandle and DMA request ordered
> + pairs. One tx and one rx pair is required for each chip
> + select.
The binding looks ok, but the wording is slightly incorrect here:
strictly speaking, it's not a pair of controller phandle and request
line number, but a DMA descriptor as specified in bindings/dma/dma.txt
with a format specific to the dma engine being used. That can
require more than just a single integer request number.
Arnd
^ permalink raw reply
* [BUG] i.MX25: soft lockups/freezes while getnstimeofday
From: Steffen Trumtrar @ 2013-01-30 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DLDikzF5LMWQLw_65ADSy2-aydvhTbpFhbBV_DwS9sCQ@mail.gmail.com>
On Tue, Jan 29, 2013 at 02:38:59PM -0200, Fabio Estevam wrote:
> Hi Steffen,
>
> On Tue, Jan 29, 2013 at 2:12 PM, Steffen Trumtrar
> <s.trumtrar@pengutronix.de> wrote:
>
> > The board itself supposedly worked up until v3.4.
> >
> > The mxc-timer is set up to use ipg_clk_highfreq with a per5_div set to 2,
> > therefore it is clocked with 120MHz. I tried to set the per5_div to 4 to have
> > a 60MHz clock, but this didn't change anything.
> > On the other hand, I tried parenting the ipg_clk to the per5_clk to get a
> > 66MHz clock. This seems to be working fine, but I only have it running for 4h now.
>
> Can you dump the clock tree in 3.4 and 3.7.2, so that we can compare them?
>
> Just looked at the FSL BSP and they have the following:
>
> /* GPT clock must be derived from AHB clock */
> clk_set_rate(&per_clk[5], ahb_clk.rate / 10);
>
Well, v3.4 has 2012d9ca2a1381ae3e733330a7f0d1d2f1988bba
/* Clock source for gpt is ahb_div */
__raw_writel(__raw_readl(CRM_BASE+0x64) & ~(1 << 5), CRM_BASE + 0x64);
Seems, that it got lost somewhere. Therefore the clocktree in v3.4 and v3.7.2
is different.
I will send a patch, that will clk_set_parent per5 to ahb.
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ 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