* [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
* [PATCH v6 07/10] dmaengine: add dma_request_slave_channel_compat()
From: Arnd Bergmann @ 2013-01-30 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359529229-22207-8-git-send-email-mporter@ti.com>
On Wednesday 30 January 2013, Matt Porter wrote:
> Adds a dma_request_slave_channel_compat() wrapper which accepts
> both the arguments from dma_request_channel() and
> dma_request_slave_channel(). Based on whether the driver is
> instantiated via DT, the appropriate channel request call will be
> made.
>
> This allows for a much cleaner migration of drivers to the
> dmaengine DT API as platforms continue to be mixed between those
> that boot using DT and those that do not.
>
> Suggested-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Matt Porter <mporter@ti.com>
> Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
> @@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct dma_async_tx_descriptor *tx);
> struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> struct dma_chan *net_dma_find_channel(void);
> #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
> +#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
> + __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
> +
> +static inline struct dma_chan
> +*__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn,
> + void *fn_param, struct device *dev,
> + char *name)
> +{
> + struct dma_chan *chan;
> +
> + chan = dma_request_slave_channel(dev, name);
> + if (chan)
> + return chan;
> +
> + return __dma_request_channel(mask, fn, fn_param);
> +}
After I have spent some more time with implementing the code for dw_dma,
I think the mask is actually unnecessary here, the helper could just
always set it to DMA_SLAVE before calling __dma_request_channel.
It's not a bug to do it this way though, and it may help convert drivers
a little easier if there is less to change.
Arnd
^ permalink raw reply
* [PATCH v6 03/10] ARM: edma: add AM33XX support to the private EDMA API
From: Arnd Bergmann @ 2013-01-30 9:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359529229-22207-4-git-send-email-mporter@ti.com>
On Wednesday 30 January 2013, Matt Porter wrote:
> + dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
> + of_dma_controller_register(dev->of_node,
> + of_dma_simple_xlate,
> + &edma_filter_info);
> + }
How do you actually deal with the problem mentioned by Padma, that
the filter function does not know which edma instance it is looking
at? If you assume that there can only be a single edma instance in
the system, that is probably a limitation that should be documented
somewhere, and ideally the probe() function should check for that.
Arnd
^ permalink raw reply
* [PATCH] ARM i.MX25: clk: parent per5_clk to AHB clock
From: Steffen Trumtrar @ 2013-01-30 9:33 UTC (permalink / raw)
To: linux-arm-kernel
The mxc-timer on the imx25 needs to be derived from the AHB clock.
If a bootloader reparents this clock to the ipg_clk_highfreq, which according
to the datasheet is a valid operation, the system can/will produce lockups/
freezes after some time [1].
This can be forced with code like
while(1)
syscall(SYS_clock_gettime, CLOCK_REALTIME, &tp);
This was already fixed with the commit
"i.MX25 GPT clock fix: ensure correct the clock source" [2],
but it seems, that it got lost. So, re-add this to have a correct gpt.
[1]: http://lists.arm.linux.org.uk/lurker/message/20130129.161230.229bda17.en.html
[2]: 2012d9ca2a1381ae3e733330a7f0d1d2f1988bba
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: stable at vger.kernel.org
---
arch/arm/mach-imx/clk-imx25.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index 5d34f67..0e6dde6 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -177,6 +177,9 @@ static int __init __mx25_clocks_init(unsigned long osc_rate)
pr_err("i.MX25 clk %d: register failed with %ld\n",
i, PTR_ERR(clk[i]));
+ /* Clock source for gpt must be derived from AHB */
+ clk_set_parent(clk[per5_sel], clk[ahb]);
+
clk_register_clkdev(clk[ipg], "ipg", "imx-gpt.0");
clk_register_clkdev(clk[gpt_ipg_per], "per", "imx-gpt.0");
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-30 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo41TbWTZ_6m0_uv-EaKnnqMR9jpqsarOJLGYZ31mrdkiw@mail.gmail.com>
Dear Bjorn Helgaas,
On Tue, 29 Jan 2013 15:27:43 -0700, Bjorn Helgaas wrote:
> I'm not sure the existing emulation in these patches is sufficient.
> For example, pci_sw_pci_bridge_write() updates bridge->membase when we
> write to the window register, but I don't see anything that updates
> the actual hardware decoder. That might be done in
> mvebu_pcie_window_config_port() via armada_370_xp_alloc_pcie_window(),
> but that looks like it's only done once.
That's correct. I currently let the Linux PCI core enumerate the
real PCIe devices, allocate the resources, and set the appropriate
values in the emulated PCI-to-PCI bridge registers. Once this is all
done, the Marvell PCIe driver looks at each PCI-to-PCI bridge, reads
the membase and iobase registers, and creates address decoding windows
so that the physical addresses assigned by the Linux PCI core actually
resolve to the right PCIe interface. This is done once for all.
> If the PCI core updates a root port window later, I don't see where the hardware
> decoder will be updated.
It will not be updated.
> Maybe you're counting on the window assignments to be static? The PCI
> core doesn't guarantee anything like that, though in the absence of
> hotplug I don't know any reason why it would change things.
Right. Is supporting hotplug a show-stopper to get this included? I
think it could be added later, if it happens to be needed, no?
I could of course do it, but the patch series is already quite large
and complicated, so if we could merge a simple, but working, version
first, and then improve on top of it when needed, it would be nice.
> I also forgot about the bus number munging in mvebu_pcie_rd_conf().
> The PCI core can update the bridge secondary/subordinate registers.
> It looks like you don't support writing to them, and the read path
> (pci_sw_pci_bridge_read()) looks like it doesn't do any translation
> between the hardware and Linux bus numbers. I don't understand the
> system well enough to know if this is an issue.
Right. Could you explain a little bit for what reasons the PCI core
could update the secondary/subordinate registers, and to what values it
sets them?
For now, I statically assign the secondary bus register value to be
X+1, where X is the number of the PCIe interface, since X=0 is reserved
for the root bus (which has the host bridge and the PCI-to-PCI
bridges).
Also, could you detail what kind of translation I should be doing when
reading the hardware and Linux bus numbers?
I apologize for asking so many, probably silly, questions, but I am
still learning all those internal PCI mechanisms.
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
* [GIT PULL] at91: fixes for 3.8-rc6
From: Nicolas Ferre @ 2013-01-30 9:38 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
Here are two little DT fixes that will fix the use of
USART3 on at91sam9x5 platforms.
The following changes since commit 949db153b6466c6f7cad5a427ecea94985927311:
Linux 3.8-rc5 (2013-01-25 11:57:28 -0800)
are available in the git repository at:
git://github.com/at91linux/linux-at91.git tags/at91-fixes
for you to fetch changes up to 7d4cfece23f535b60496d88a717a3d7bfca50187:
ARM: at91/at91sam9x5.dtsi: fix usart3 TXD (2013-01-30 10:09:17 +0100)
----------------------------------------------------------------
Two little Device Tree fixes for USART on at91sam9x5.
----------------------------------------------------------------
Douglas Gilbert (1):
ARM: at91/at91sam9x5.dtsi: fix usart3 TXD
Robert Nelson (1):
ARM: at91: at91sam9x5: fix usart3 pinctrl name
arch/arm/boot/dts/at91sam9x5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Thanks, bye,
--
Nicolas Ferre
^ permalink raw reply
* [GIT PULL] ux500 <mach/id.h> removal
From: Linus Walleij @ 2013-01-30 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMiKCHUz9BJ31o-4kthr0CZABuL7SuuMNEjbkUQ06KsfMw@mail.gmail.com>
On Wed, Jan 30, 2013 at 1:12 AM, Olof Johansson <olof@lixom.net> wrote:
> [Me]
>> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
>> tags/ux500-no-idh
>
> Pulled in.
>
> This has a somewhat annoying (but trivial) conflict against your own
> code (the cpufreq driver changes).
Arnd always told me to split stuff cleanly on branches, which of course
leads to conflicts like that, but I thought he wanted them, rather than
huge accumulated patch sets built on to of each othere ... a bit hard to
do the right thing here, what would have been the right way?
Does it help if I base stuff off ARM SoC tree branches, and which
ones can be relied upon in that case?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Arnd Bergmann @ 2013-01-30 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpon30hB9S+MUyXwZpefAGQE4hvF36d-6jXNRk_XoK5dwww@mail.gmail.com>
On Wednesday 30 January 2013, Viresh Kumar wrote:
> On 29 January 2013 21:51, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tuesday 29 January 2013, Viresh Kumar wrote:
> >> On 29 January 2013 19:01, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > Ah, good. So I guess the "dma-requests" property should actually
> >> > be "16" then.
> >>
> >> yes, even i was checking on that separately :)
> >
> > Actually, I just discovered something odd in the
> > arch/arm/mach-spear/spear13xx-dma.h file that gets removed
> > in the last patch: there, we define request numbers up to
> > 32, e.g.
> >
> > - SPEAR1310_DMA_REQ_UART2_RX = 14,
> > - SPEAR1310_DMA_REQ_UART2_TX = 15,
> > - SPEAR1310_DMA_REQ_UART5_RX = 16,
> > - SPEAR1310_DMA_REQ_UART5_TX = 17,
> >
> > What is the meaning of this, if the maximum request number is 15?
>
> I knew you will come to this :)
> So, the hardware is like: there are 16 request line slots per master, a
> platform can choose to connect same or separate devices to these.
>
> So, these are really 16 per master.
Ok, I see. Do you know how these are numbered in the data sheet?
If the convention is to have subsequent numbers for these in the
hardware description, we should probably just have that single
request number in the binding, too, and calculate the master number
from that. If it lists pairs of request/master number, we should
use pairs in the binding as well, in the same order.
> > Ok. Would it be enough to have only one master and one request
> > field in the DT dma descriptor then, and have the code figure
> > whether to use it as source or destination, based on the
> > configuration? Which one should come first? Since you have
> > multiple masters per controller, and multiple requests per
> > master, it sounds like the cleanest descriptor form would
> > be
> >
> > <controller master request>;
> >
> > Or possibly
> >
> > <controller master request direction>;
> >
> > if the direction needs to be known at the time the channel
> > is requested.
>
> Its better to keep masters as is. So, that we can use appropriate
> masters for peripheral and memory to make the transfer fast.
So you mean keep the format as
<controller request src-master dst-master>;
?
Arnd
^ permalink raw reply
* [PATCH] ARM: ux500: rename ab8500 to abx500 for hwmon driver
From: Linus Walleij @ 2013-01-30 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359531747-3636-1-git-send-email-hongbo.zhang@linaro.org>
On Wed, Jan 30, 2013 at 8:42 AM, 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>
You need to have the ACK:ed by the MFD subsystem maintainer
so that G?nther can merge it later, along with the HWMON patch.
Also combine them into a series, this one as 1/2 and the other
patch as 2/2.
And remember to send both to the relevant maintainers
(see MAINTAINERS file):
HARDWARE MONITORING
M: Jean Delvare <khali@linux-fr.org>
M: Guenter Roeck <linux@roeck-us.net>
MULTIFUNCTION DEVICES (MFD)
M: Samuel Ortiz <sameo@linux.intel.com>
Both patches should also go into the linux-kernel at vger.kernel.org mailing
list "LKML".
Thanks!
Linus Walleij
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Arnd Bergmann @ 2013-01-30 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130045655.GE5734@obsidianresearch.com>
On Wednesday 30 January 2013, Jason Gunthorpe wrote:
> > But we normally only assign a 64 KB I/O window to each PCI host bridge.
> > Requiring PCI bridges to be space 64 KB apart would mean that we cannot
> > actually support bridges at all.
>
> The PCI resource code uses full 32 bit integers when it handles IO
> addresses, so this actually does sort of work out.
However, we only reserve 1 MB (I think) virtual address window for all
I/O spaces of all PCI domains combined, at a fixed location (0xfee00000).
This means we can have at most 16 such windows at run-time. That can
be changed if necessary, but it seems like overkill when in practice
you only need a few bytes at most.
Arnd
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Viresh Kumar @ 2013-01-30 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301300941.35886.arnd@arndb.de>
On Wed, Jan 30, 2013 at 3:11 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 30 January 2013, Viresh Kumar wrote:
>> I knew you will come to this :)
>> So, the hardware is like: there are 16 request line slots per master, a
>> platform can choose to connect same or separate devices to these.
>>
>> So, these are really 16 per master.
>
> Ok, I see. Do you know how these are numbered in the data sheet?
>
> If the convention is to have subsequent numbers for these in the
> hardware description, we should probably just have that single
> request number in the binding, too, and calculate the master number
> from that. If it lists pairs of request/master number, we should
> use pairs in the binding as well, in the same order.
Actually what would be better to have is:
- have this range from 0-15 only
- together with the master we want to use for peripheral
this should be enough.
Datasheet of dw_dmac doesn't tell much about it.. just four bits for programming
it and so values are from 0-15 :)
>> > Ok. Would it be enough to have only one master and one request
>> > field in the DT dma descriptor then, and have the code figure
>> > whether to use it as source or destination, based on the
>> > configuration? Which one should come first? Since you have
>> > multiple masters per controller, and multiple requests per
>> > master, it sounds like the cleanest descriptor form would
>> > be
>> >
>> > <controller master request>;
>> >
>> > Or possibly
>> >
>> > <controller master request direction>;
>> >
>> > if the direction needs to be known at the time the channel
>> > is requested.
>>
>> Its better to keep masters as is. So, that we can use appropriate
>> masters for peripheral and memory to make the transfer fast.
>
> So you mean keep the format as
>
> <controller request src-master dst-master>;
>
> ?
Yes..
^ permalink raw reply
* [PATCH] ARM: ux500: enable ux500 EXT4_FS and LBDAF support by default
From: Linus Walleij @ 2013-01-30 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359537700-19293-1-git-send-email-hongbo.zhang@linaro.org>
On Wed, Jan 30, 2013 at 10:21 AM, Hongbo Zhang <hongbo.zhang@linaro.org> wrote:
> EXT4 file system and LBDAF are used commonly, should be enabled by default.
>
> Signed-off-by: Hongbo Zhang <hongbo.zhang@linaro.org>
Thanks!
Applied to my defconfig branch.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: ux500: rename ab8500 to abx500 for hwmon driver
From: Hongbo Zhang @ 2013-01-30 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdajhr__+8=6JbQAgYBq39S8XJZe6PDjVFA+znOJGHa7uQ@mail.gmail.com>
On 30 January 2013 17:45, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Jan 30, 2013 at 8:42 AM, 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>
>
> You need to have the ACK:ed by the MFD subsystem maintainer
> so that G?nther can merge it later, along with the HWMON patch.
>
> Also combine them into a series, this one as 1/2 and the other
> patch as 2/2.
>
> And remember to send both to the relevant maintainers
> (see MAINTAINERS file):
>
> HARDWARE MONITORING
> M: Jean Delvare <khali@linux-fr.org>
> M: Guenter Roeck <linux@roeck-us.net>
>
> MULTIFUNCTION DEVICES (MFD)
> M: Samuel Ortiz <sameo@linux.intel.com>
>
> Both patches should also go into the linux-kernel at vger.kernel.org mailing
> list "LKML".
>
Thanks for your instructions, will follow them.
> Thanks!
> Linus Walleij
^ permalink raw reply
* [PATCH] ARM i.MX25: clk: parent per5_clk to AHB clock
From: Uwe Kleine-König @ 2013-01-30 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359538435-21304-1-git-send-email-s.trumtrar@pengutronix.de>
On Wed, Jan 30, 2013 at 10:33:55AM +0100, Steffen Trumtrar wrote:
> The mxc-timer on the imx25 needs to be derived from the AHB clock.
> If a bootloader reparents this clock to the ipg_clk_highfreq, which according
> to the datasheet is a valid operation, the system can/will produce lockups/
> freezes after some time [1].
>
> This can be forced with code like
> while(1)
> syscall(SYS_clock_gettime, CLOCK_REALTIME, &tp);
>
> This was already fixed with the commit
> "i.MX25 GPT clock fix: ensure correct the clock source" [2],
> but it seems, that it got lost. So, re-add this to have a correct gpt.
>
> [1]: http://lists.arm.linux.org.uk/lurker/message/20130129.161230.229bda17.en.html
> [2]: 2012d9ca2a1381ae3e733330a7f0d1d2f1988bba
Instead of the last paragraph I'd write:
This problem was already fixed with commit
2012d9c (i.MX25 GPT clock fix: ensure correct the clock source)
for v3.1-rc2 but this was lost when i.MX was converted to the common
clock framework (commit 6bbaec5; ARM i.MX25: implement clocks using
common clock framework).
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Cc: stable at vger.kernel.org
Cc: stable at vger.kernel.org # v3.5+
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Thomas Petazzoni @ 2013-01-30 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301300946.54040.arnd@arndb.de>
Dear Arnd Bergmann,
On Wed, 30 Jan 2013 09:46:53 +0000, Arnd Bergmann wrote:
> On Wednesday 30 January 2013, Jason Gunthorpe wrote:
> > > But we normally only assign a 64 KB I/O window to each PCI host bridge.
> > > Requiring PCI bridges to be space 64 KB apart would mean that we cannot
> > > actually support bridges at all.
> >
> > The PCI resource code uses full 32 bit integers when it handles IO
> > addresses, so this actually does sort of work out.
>
> However, we only reserve 1 MB (I think) virtual address window for all
> I/O spaces of all PCI domains combined, at a fixed location (0xfee00000).
> This means we can have at most 16 such windows at run-time. That can
> be changed if necessary, but it seems like overkill when in practice
> you only need a few bytes at most.
I am not sure where this 0xfee00000 address comes from, but in my case
(and I think in the Tegra PCI driver as well), we tell the Linux PCI
core from which addresses the I/O ranges should be allocated. In my DT,
I have:
ranges = <0x00000800 0 0xd0040000 0xd0040000 0 0x00002000 /* port 0.0 registers */
0x00004800 0 0xd0042000 0xd0042000 0 0x00002000 /* port 2.0 registers */
0x00001000 0 0xd0044000 0xd0044000 0 0x00002000 /* port 0.1 registers */
0x00001800 0 0xd0048000 0xd0048000 0 0x00002000 /* port 0.2 registers */
0x00002000 0 0xd004C000 0xd004C000 0 0x00002000 /* port 0.3 registers */
0x00002800 0 0xd0080000 0xd0080000 0 0x00002000 /* port 1.0 registers */
0x00005000 0 0xd0082000 0xd0082000 0 0x00002000 /* port 3.0 registers */
0x00003000 0 0xd0084000 0xd0084000 0 0x00002000 /* port 1.1 registers */
0x00003800 0 0xd0088000 0xd0088000 0 0x00002000 /* port 1.2 registers */
0x00004000 0 0xd008C000 0xd008C000 0 0x00002000 /* port 1.3 registers */
0x81000000 0 0 0xc0000000 0 0x00100000 /* downstream I/O */
0x82000000 0 0 0xc1000000 0 0x08000000>; /* non-prefetchable memory */
And then, the Marvell PCI driver gets the "downstream I/O" range,
parses it into a "struct resource", and then does (where &pcie->io is
the struct resource into which we parsed the "downstream I/O" range):
pci_add_resource_offset(&sys->resources, &pcie->io, sys->io_offset);
[...]
pci_ioremap_io(nr * SZ_64K, pcie->io.start);
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.
The Tegra PCI driver does exactly the same (I shamelessly copied what
Thierry has done).
I somehow have the feeling that we are looking for problems that simply
don't exist...
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 v2 05/27] arm: pci: add a align_resource hook
From: Arnd Bergmann @ 2013-01-30 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130042103.GB5734@obsidianresearch.com>
On Wednesday 30 January 2013, Jason Gunthorpe wrote:
> On Tue, Jan 29, 2013 at 10:54:00PM +0000, Arnd Bergmann wrote:
> > The part that I did not like about having emulated PCI-to-PCI bridges
> > is that it seems to just work around a (percieved or real) limitation
> > in the Linux kernel by adding a piece of infrastructure, rather than
> > lifting that limitation by making the kernel deal with what the
> > hardware provides. That reminded me of the original mach-vt8500
>
> Well.. in this case there is a standard - PCI-E for what HW vendors
> are supposed to do. The kernel core code follows it and works with
> compliant hardware.
>
> Marvell HW is not compliant.
>
> So..
>
> Should the kernel core PCI code support this particular non-compliance?
> Should the driver work around the non-compliance and present a
> compliant interface to the kernel and userspace?
>
> My take is the kernel core PCI code is fine, and I hope
> this will be an isolated issue with one family of Marvell IP. So
> working around the HW problem in the driver seems best.
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.
Can you (or someone else) describe what kind of changes to the core
code we would actually need to make it work without emulting the
bridge?
> If we learn of many more instances like this then, yah, update the
> core code and rip out this driver work around...
But the code was specifically written to be reusable, which is normally
a good thing.
Arnd
^ permalink raw reply
* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Arnd Bergmann @ 2013-01-30 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130105418.7f53bc77@skate>
On Wednesday 30 January 2013, Thomas Petazzoni wrote:
> I am not sure where this 0xfee00000 address comes from, but in my case
> (and I think in the Tegra PCI driver as well), we tell the Linux PCI
> core from which addresses the I/O ranges should be allocated. In my DT,
> I have:
>
> ranges = <0x00000800 0 0xd0040000 0xd0040000 0 0x00002000 /* port 0.0 registers */
> 0x00004800 0 0xd0042000 0xd0042000 0 0x00002000 /* port 2.0 registers */
> 0x00001000 0 0xd0044000 0xd0044000 0 0x00002000 /* port 0.1 registers */
> 0x00001800 0 0xd0048000 0xd0048000 0 0x00002000 /* port 0.2 registers */
> 0x00002000 0 0xd004C000 0xd004C000 0 0x00002000 /* port 0.3 registers */
> 0x00002800 0 0xd0080000 0xd0080000 0 0x00002000 /* port 1.0 registers */
> 0x00005000 0 0xd0082000 0xd0082000 0 0x00002000 /* port 3.0 registers */
> 0x00003000 0 0xd0084000 0xd0084000 0 0x00002000 /* port 1.1 registers */
> 0x00003800 0 0xd0088000 0xd0088000 0 0x00002000 /* port 1.2 registers */
> 0x00004000 0 0xd008C000 0xd008C000 0 0x00002000 /* port 1.3 registers */
> 0x81000000 0 0 0xc0000000 0 0x00100000 /* downstream I/O */
> 0x82000000 0 0 0xc1000000 0 0x08000000>; /* non-prefetchable memory */
>
> And then, the Marvell PCI driver gets the "downstream I/O" range,
> parses it into a "struct resource", and then does (where &pcie->io is
> the struct resource into which we parsed the "downstream I/O" range):
>
> pci_add_resource_offset(&sys->resources, &pcie->io, sys->io_offset);
> [...]
> pci_ioremap_io(nr * SZ_64K, pcie->io.start);
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.
Arnd
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Arnd Bergmann @ 2013-01-30 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOh2x==WZePgfTWwL0vPdE693n44vW05OS=DSqbnDCs2xzHXuw@mail.gmail.com>
On Wednesday 30 January 2013, Viresh Kumar wrote:
> On Wed, Jan 30, 2013 at 3:11 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 30 January 2013, Viresh Kumar wrote:
> >> I knew you will come to this :)
> >> So, the hardware is like: there are 16 request line slots per master, a
> >> platform can choose to connect same or separate devices to these.
> >>
> >> So, these are really 16 per master.
> >
> > Ok, I see. Do you know how these are numbered in the data sheet?
> >
> > If the convention is to have subsequent numbers for these in the
> > hardware description, we should probably just have that single
> > request number in the binding, too, and calculate the master number
> > from that. If it lists pairs of request/master number, we should
> > use pairs in the binding as well, in the same order.
>
> Actually what would be better to have is:
> - have this range from 0-15 only
> - together with the master we want to use for peripheral
>
> this should be enough.
Ok.
> Datasheet of dw_dmac doesn't tell much about it.. just four bits for programming
> it and so values are from 0-15 :)
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.
Arnd
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Sascha Hauer @ 2013-01-30 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5108B4E7.4020505@ti.com>
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.
What about the dr_mode helper? Moving it to otg/ would mean that all
users which want to use it would have to select USB_OTG_UTILS. At least
the fsl mph driver currently does not need USB_OTG_UTILS.
ATM I'm feeling like killing USB_OTG_UTILS completely, that would make
things easier.
Sascha
--
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
* ixp4xx eth broken in 3.7.0/3.8-rc5?
From: Mikael Pettersson @ 2013-01-30 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359509647.4144.36.camel@bwh-desktop.uk.solarflarecom.com>
Ben Hutchings writes:
> On Tue, 2013-01-29 at 19:32 -0500, Xi Wang wrote:
> > On 1/29/13 7:11 PM, Mikael Pettersson wrote:
> > > A git bisect identified the following as the culprit:
> > >
> > > > From 1a4901177574083c35fafc24c4d151c2a7c7647c Mon Sep 17 00:00:00 2001
> > > > From: Xi Wang <xi.wang@gmail.com>
> > > > Date: Sat, 17 Nov 2012 20:25:09 +0000
> > > > Subject: [PATCH] ixp4xx_eth: avoid calling dma_pool_create() with NULL dev
> > > >
> > > > Use &port->netdev->dev instead of NULL since dma_pool_create() doesn't
> > > > allow NULL dev.
> > > >
> > > > Signed-off-by: Xi Wang <xi.wang@gmail.com>
> > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > Signed-off-by: David S. Miller <davem@davemloft.net>
> > > > ---
> > > > drivers/net/ethernet/xscale/ixp4xx_eth.c | 8 +++++---
> > > > 1 files changed, 5 insertions(+), 3 deletions(-)
> > >
> > > Reverting this unbreaks ixp4xx_eth on my ixp4xx machine with kernels
> > > 3.7.0 and 3.8-rc5.
> >
> > Thanks. The problem was that in init_queues(), the dma_pool_create()
> > call requires a non-null dev.
> >
> > dma_pool = dma_pool_create(DRV_NAME, ??, ...);
I had a look around in the 3.8-rc5 kernel source.
mm/dmapool.c:dma_pool_create() needs a non-NULL dev in the CONFIG_NUMA case,
because it calls dev_to_node(dev) which dereferences dev if CONFIG_NUMA.
But in the non-CONFIG_NUMA case there is no dereference of dev, and in fact
there is an explicit check for dev being NULL or not towards the end of
dma_pool_create(). So that explains why ixp4xx works without the change:
it's not NUMA.
A quick grep found three calls to dma_pool_create() with a NULL dev parameter,
two in drivers/usb/gadget/amd5536udc.c and one in arch/arm/mach-s3c64xx/dma.c.
These would all be broken with CONFIG_NUMA but Ok otherwise.
> >
> > What do you think would work here?
>
> For DMA purposes I would expect the right device to be the parent bus
> device, i.e. port->netdev->dev.parent. The driver might also need to
> set its DMA masks.
At least on ixp4xx the DMA masks are normally set by the platform PCI init
code (it has a 64MB PCI DMA window limitation).
I can give the port->netdev->dev.parent variant a try later this evening.
/Mikael
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Sebastian Hesselbarth @ 2013-01-30 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130083044.GA25688@schnuecks.de>
On 01/30/2013 09:30 AM, Simon Baatz wrote:
> On Wed, Jan 30, 2013 at 01:51:18AM +0100, Sebastian Hesselbarth wrote:
>> - [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?
Actually, both patches above will not fix modular ethernet for 3.8-rc as
shared driver is probed before core driver and not requesting any clk at
all. The "NET: mv643xx: get smi clock from device tree" patch is based
on Jason's attempt to separate shared driver.
If we need to fix modular ethernet now, we also need to add a clk_get
to shared ethernet.
But yes, DT doesn't need any clock aliases.
>> - 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 know the difference, but here it is not only about fixing an issue
but have it cleanly removed later on. But I don't have a strong opinion
on that and maybe Andrew or Jason should coordinate what must be fixed
now and how we do it.
Sebastian
^ permalink raw reply
* [RFC] arm: use built-in byte swap function
From: Woodhouse, David @ 2013-01-30 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129181046.GC25415@pd.tnic>
On Tue, 2013-01-29 at 19:10 +0100, Borislav Petkov wrote:
> So, IMHO it sounds to me like we want to explicitly state for each arch
> separately that it is ok to use the __builtin_bswapXX things. This also
> takes care of the case where the compiler is doing something suboptimal
> by excluding the affected versions.
Well, if it really does end up being different for every architecture,
then that means I probably made the wrong decision when I chose to make
it "generic", and override the __arch_swabXX() macros. I could have just
pushed all the architectures to use the builtins in their __arch_swabXX
macros instead, as appropriate.
Let's see how many special cases we actually end up with, and perhaps
we'll end up switching that round. For now, let's just make ARM set
__HAVE_BUILTIN_BSWAPxx__ for the appropriate sizes in <asm/swab.h>,
according to whatever criteria it needs.
It's not entirely clear how much of a win it is on ARM anyway; we don't
have load-and-swap or store-and-swap instructions so there are only a
few added opportunities for optimisation that we get by letting the
compiler see what's going on.
--
Sent with MeeGo's ActiveSync support.
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4370 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130130/366a3921/attachment.bin>
^ permalink raw reply
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: Johannes Stezenbach @ 2013-01-30 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301282320430.6300@xanadu.home>
On Mon, Jan 28, 2013 at 11:29:14PM -0500, Nicolas Pitre wrote:
> On Mon, 28 Jan 2013, Andrew Morton wrote:
>
> > On Sat, 26 Jan 2013 14:50:43 +0900
> > Kyungsik Lee <kyungsik.lee@lge.com> wrote:
> >
> > > This patchset is for supporting LZ4 compressed kernel and initial ramdisk on
> > > the x86 and ARM architectures.
> > >
> > > According to http://code.google.com/p/lz4/, LZ4 is a very fast lossless
> > > compression algorithm and also features an extremely fast decoder.
> > >
> > > Kernel Decompression APIs are based on implementation by Yann Collet
> > > (http://code.google.com/p/lz4/source/checkout).
> > > De/compression Tools are also provided from the site above.
> > >
> > > The initial test result on ARM(v7) based board shows that the size of kernel
> > > with LZ4 compressed is 8% bigger than LZO compressed but the decompressing
> > > speed is faster(especially under the enabled unaligned memory access).
> > >
> > > Test: 3.4 based kernel built with many modules
> > > Uncompressed kernel size: 13MB
> > > lzo: 6.3MB, 301ms
> > > lz4: 6.8MB, 251ms(167ms, with enabled unaligned memory access)
> >
> > What's this "with enabled unaligned memory access" thing? You mean "if
> > the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so,
> > that's only x86, which isn't really in the target market for this
> > patch, yes?
>
> I'm guessing this is referring to commit 5010192d5a.
>
> > It's a lot of code for a 50ms boot-time improvement. Does anyone have
> > any opinions on whether or not the benefits are worth the cost?
>
> Well, we used to have only one compressed format. Now we have nearly
> half a dozen, with the same worthiness issue between themselves.
> Either we keep it very simple, or we make it very flexible. The former
> would argue in favor of removing some of the existing formats, the later
> would let this new format in.
This reminded me to check the status of the lzo update and it
seems it got lost?
http://lkml.org/lkml/2012/10/3/144
(Cc: added, I hope Markus still cares and someone could
eventually take his patch once he resends it.)
Johannes
^ permalink raw reply
* [RESEND PATCH v5 3/7] usb: chipidea: add otg id switch and vbus connect/disconnect detect
From: Alexander Shishkin @ 2013-01-30 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130130065724.GC699@nchen-desktop>
Peter Chen <peter.chen@freescale.com> writes:
> On Wed, Jan 30, 2013 at 11:36:42AM +0530, kishon wrote:
>> Hi,
>>
>> > bool global_phy;
>> > struct usb_phy *transceiver;
>> > struct usb_hcd *hcd;
>> >- struct usb_otg otg;
>> >+ struct usb_otg otg;
>> You have added *otg* in previous patch and added a tab for *otg* in
>> this patch.
> thanks, I will change at previous patch
>>
>> >+
>> >+#define CI_VBUS_STABLE_TIMEOUT 500
>>
>> Just curious.. how was this timeout value obtained?
>
> Just a timeout value, if the vbus goes to required value, it will quit.
> Besides, 5s for vbus stable should be enough for an well behaviour hardware.
Can you also mention this in the patch, since it raises questions?
Thanks,
--
Alex
^ permalink raw reply
* [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
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