* [PATCH v2 01/13] clk: davinci - add Main PLL clock driver
From: Sekhar Nori @ 2012-10-11 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348683037-9705-2-git-send-email-m-karicheri2@ti.com>
On 9/26/2012 11:40 PM, Murali Karicheri wrote:
> +struct clk_davinci_pll_data {
> + /* physical addresses set by platform code */
> + u32 phy_pllm;
> + /* if PLL has a prediv register this should be non zero */
> + u32 phy_prediv;
> + /* if PLL has a postdiv register this should be non zero */
> + u32 phy_postdiv;
"phys" is typically used for physical addresses. I couldn't immediately
related this to physical address when I looked at this variable outside
of this file.
Also, physical addresses should be of type phys_addr_t.
> + /* mapped addresses. should be initialized by */
> + void __iomem *pllm;
> + void __iomem *prediv;
> + void __iomem *postdiv;
> + u32 pllm_mask;
> + u32 prediv_mask;
> + u32 postdiv_mask;
> + u32 num;
Wondering what num is for? May be it will be clear once you document the
complete structure as Linus suggested.
> + /* framework flags */
> + u32 flags;
> + /* pll flags */
> + u32 pll_flags;
> + /* use this value for prediv */
> + u32 fixed_prediv;
Why is this called "fixed". Isn't this the pre-divider value that user
can configure? Also, shouldn't there be a post-divider value that you
need as well.
> + /* multiply PLLM by this factor. By default most SOC set this to zero
> + * that translates to a multiplier of 1 and incrementer of 1.
> + * To override default, set this factor
> + */
> + u32 pllm_multiplier;
'm' in pllm stands for multiplier. So, instead of calling it
"pllm_multiplier", call it "pllm_val" instead?
Sorry about late comments on this, looks like I missed looking at this
structure altogether yesterday and had to go back to this only when I
tried understanding whats going on in 4/13
Thanks,
Sekhar
^ permalink raw reply
* alignment faults in 3.6
From: Maxime Bizon @ 2012-10-11 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349952574.21172.8604.camel@edumazet-glaptop>
On Thu, 2012-10-11 at 12:49 +0200, Eric Dumazet wrote:
> So if you have an alignment fault, thats because IP header is not
> aligned on 4 bytes ?
>
> If so a driver is buggy and must be fixed.
So a driver that does not align the ip header is buggy ?
I always thought it was ok not to do so (with a potential performance
penalty).
I have some MIPS hardware that is not able to DMA on anything but 32bits
aligned addresses (bcm63xx). I tried once to add a memcpy instead of
taking unaligned faults and the result was *much slower* on a ipv4
forwarding test (which is what the hardware is used for).
--
Maxime
^ permalink raw reply
* alignment faults in 3.6
From: Eric Dumazet @ 2012-10-11 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011103257.GO4625@n2100.arm.linux.org.uk>
On Thu, 2012-10-11 at 11:32 +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 11, 2012 at 12:22:06PM +0200, Eric Dumazet wrote:
> > I took a look, and I dont see why/how gcc could use a ldm instruction
> >
> > Doing so assumed the alignment of the structure was 8 bytes, but its
> > not.
> >
> > Networking stack mandates that IP headers are aligned on 4 bytes
> > boundaries, not 8 bytes.
>
> Err, no. ldm is "load multiple" not "load double". It loads multiple
> 32-bit registers, and its requirement for non-faulting behaviour is for
> the pointer to be 4 byte aligned. However, "load double" requires 8
> byte alignment.
So if you have an alignment fault, thats because IP header is not
aligned on 4 bytes ?
If so a driver is buggy and must be fixed.
Please send us full stack trace
^ permalink raw reply
* alignment faults in 3.6
From: Måns Rullgård @ 2012-10-11 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B703B@saturn3.aculab.com>
"David Laight" <David.Laight@ACULAB.COM> writes:
>> > It might be enough to use __attribute__((aligned(2))) on some structure
>> > members (actually does 'ldm' need 8 byte alignment?? - in which case
>> > aligned(4) is enough).
>>
>> The aligned attribute can only increase alignment.
>
> Not true.
> If you have:
>
> struct foo {
> short a;
> int b __attribute__((aligned(2)));
> short c;
> };
>
> You'll find sizeof (struct foo) is 8, and that, on arm/sparc etc,
> gcc will generate 2 16bit accesses (and shifts) for foo.b;
That is not what the manual says. Quoting:
When used on a struct, or struct member, the `aligned' attribute
can only increase the alignment
My gcc agrees with the manual:
$ cat foo.c
struct foo {
short a;
int b __attribute__((aligned(2)));
short c;
};
int foo(struct foo *f)
{
return f->b;
}
$ arm-unknown-linux-gnueabi-gcc-4.7.2 -O2 -o- -S foo.c
.text
.align 2
.global foo
.type foo, %function
foo:
ldr r0, [r0, #4]
bx lr
(compiler output edited for clarity)
This clearly says the 'b' member resides at an offset of 4 bytes into
the struct.
--
M?ns Rullg?rd
mans at mansr.com
^ permalink raw reply
* bug with 3.4.6, 3.5.3, 3.6.1
From: Will Deacon @ 2012-10-11 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50765D3B.6000909@xenomai.org>
On Thu, Oct 11, 2012 at 06:46:35AM +0100, Gilles Chanteperdrix wrote:
> Hi,
Hi Gilles,
> when booting Linux v3.4.6, v3.5.3, or v3.6.1 on a pandaboard with an
> OMAP4430 ES2.1, compiled with the following configuration:
> http://xenomai.org/~gch/config-panda
>
> I get the bug below after mounting the root filesystem.
>
> CONFIG_VMSPLIT_2G and CONFIG_THUMB2_KERNEL disabled seems to be the
> combination which triggers the bug.
>
> With this configuration, it seems the init_mm.mm_count incrementation
> done at the beginning of secondary_start_kernel() is "lost" after the
> calls to cpu_switch_mm() and local_flush_tlb().
>
> Modifying the secondary_startup() function in head.S to pass the
> swapper pgdir instead of the idmap pgdir in r4 also avoids the issue.
What's your PHYS_OFFSET? I suspect it's >= 2GB, in which case I have some
ideas about this problem.
Will
^ permalink raw reply
* [PATCH 01/13] clk: davinci - add Main PLL clock driver
From: Sekhar Nori @ 2012-10-11 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507563C3.2000305@ti.com>
On 10/10/2012 5:32 PM, Sekhar Nori wrote:
> Hi Murali,
>
> On 9/26/2012 11:37 PM, Murali Karicheri wrote:
>> This is the driver for the main PLL clock hardware found on DM SoCs.
>> This driver borrowed code from arch/arm/mach-davinci/clock.c and
>> implemented the driver as per common clock provider API. The main PLL
>> hardware typically has a multiplier, a pre-divider and a post-divider.
>> Some of the SoCs has the divider fixed meaning they can not be
>> configured through a register. HAS_PREDIV and HAS_POSTDIV flags are used
>> to tell the driver if a hardware has these dividers present or not.
>> Driver is configured through the structure clk_davinci_pll_data
>> that has the platform data for the driver.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>
> Are you using git-format-patch to generate the patches? It should have
> added a diffstat here by default which is very useful in quickly
> understanding what the patch is touching.
>>
>> diff --git a/drivers/clk/davinci/clk-davinci-pll.c b/drivers/clk/davinci/clk-davinci-pll.c
Looking at how common clock framework for mxs has been implemented, this
file should simply be clk-pll.c. That makes sense as you are creating a
davinci folder anyway. Similar change required for psc as well.
Thanks,
Sekhar
^ permalink raw reply
* alignment faults in 3.6
From: Russell King - ARM Linux @ 2012-10-11 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349950926.21172.8521.camel@edumazet-glaptop>
On Thu, Oct 11, 2012 at 12:22:06PM +0200, Eric Dumazet wrote:
> I took a look, and I dont see why/how gcc could use a ldm instruction
>
> Doing so assumed the alignment of the structure was 8 bytes, but its
> not.
>
> Networking stack mandates that IP headers are aligned on 4 bytes
> boundaries, not 8 bytes.
Err, no. ldm is "load multiple" not "load double". It loads multiple
32-bit registers, and its requirement for non-faulting behaviour is for
the pointer to be 4 byte aligned. However, "load double" requires 8
byte alignment.
^ permalink raw reply
* [PATCH 4/7] ARM: tegra30: common: enable csite clock
From: Joseph Lo @ 2012-10-11 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5074A77D.9080500@wwwdotorg.org>
On Wed, 2012-10-10 at 06:38 +0800, Stephen Warren wrote:
> On 10/08/2012 04:26 AM, Joseph Lo wrote:
> > Enable csite (debug and trace controller) clock at init to prevent it
> > be disabled. And this also the necessary clock for CPU be brought up or
> > resumed from a power-gate low power state (e.g., LP2).
>
> Does it make sense to enable this clock only when entering LP2? Or do we
> really need to keep it on 100% of the time?
Hmmm. I am not sure does the RealView or Lauterbach ICE can still attach
to the target if the clock is not available. Or even it can be attached
but some functions of the debugger may not work. Because the CoreSight
is a very fancy debug module.
I only test it with a light weight debugger (OpenOCD). It still can work
without turning on the CoreSight clock. Maybe it just because the
openocd debugger only using the jtag interface.
Anyway, I think we need the csite always on for the developer that using
RealView or Lauterbach ICE.
Thanks,
Joseph
^ permalink raw reply
* alignment faults in 3.6
From: Eric Dumazet @ 2012-10-11 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349949638.21172.8445.camel@edumazet-glaptop>
On Thu, 2012-10-11 at 12:00 +0200, Eric Dumazet wrote:
> On Thu, 2012-10-11 at 10:45 +0100, M?ns Rullg?rd wrote:
>
> I have no idea what is the problem,
>
> -ENOTENOUGHCONTEXT
>
>
I took a look, and I dont see why/how gcc could use a ldm instruction
Doing so assumed the alignment of the structure was 8 bytes, but its
not.
Networking stack mandates that IP headers are aligned on 4 bytes
boundaries, not 8 bytes.
(Some arches like x86 dont care, so we might have some bugs in some
drivers, but not in the GRO code)
Some drivers are not aware of the NET_IP_ALIGN stuff.
They should be fixed, or else you have alignment faults.
struct iphdr {
__u8 ihl:4,
version:4;
__u8 tos;
__be16 tot_len;
__be16 id;
__be16 frag_off;
__u8 ttl;
__u8 protocol;
__sum16 check;
__be32 saddr;
__be32 daddr;
/*The options start here. */
};
The alignment of iphdr is 4, not 8
doing id = ntohl(*(__be32 *)&iph->id); is valid
doing flush = (u16)((ntohl(*(__be32 *)iph) ^ len) | (id ^ IP_DF)); is valid as well.
If arm compiler decided to use a 8bytes load, thats a compiler bug.
(unless compiler was specifically told that alignment did not matter)
c02ac020: e8920840 ldm r2, {r6, fp} // HERE
c02ac024: e6bfbf3b rev fp, fp
c02ac028: e6bf6f36 rev r6, r6
c02ac02c: e22bc901 eor ip, fp, #16384 ; 0x4000
c02ac030: e0266008 eor r6, r6, r8
c02ac034: e18c6006 orr r6, ip, r6
^ permalink raw reply
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Sourav @ 2012-10-11 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011095443.GH28061@n2100.arm.linux.org.uk>
Hi Russell,
On Thursday 11 October 2012 03:24 PM, Russell King - ARM Linux wrote:
> On Thu, Oct 11, 2012 at 03:13:43PM +0530, Sourav wrote:
>> Hi Kevin,
>> On Wednesday 10 October 2012 11:59 PM, Kevin Hilman wrote:
>>> Hi Sourav,
>>>
>>> Sourav <sourav.poddar@ti.com> writes:
>>>
>>> [...]
>>>
>>>> Boot Tested this patch series against v3.6 tag(applied cleanly) on
>>>> panda board and
>>>> PM tested(hitting off in Idle and suspend) on omap3630 based beagle board.
>>>>
>>>> Note, I also tested the patches against the current master but only
>>>> after rebasing, since the current master includes serial patches from
>>>> Felipe Balbi[1].
>>>> [1] https://lkml.org/lkml/2012/8/24/139
>>>>
>>>> Tested-by: Sourav Poddar <sourav.poddar@ti.com>
>>> Did you test flow control after off-mode transitons?
>>>
>>> Russell indicated that the context save/restore is not saving important
>>> bits related to HW flow control, so I suspect some more testing,
>>> specifically of flow control after off-mode is needed.
>>>
>>> Kevin
>> The testing done was without any flow control enabled.
> So, as the patch set is about fixing the flow control stuff, would
> you say that your testing without flow control enabled has much value?
True. I missed that point while doing the testing. Sorry for that.
I further looked into it and saw some two options in my minicom
settings(Hardware Flow Control/ Software Flow Control) Which I am
thinking are the ones used to enable the flow control ? and they are
both set to NO.
I already enable software flow control and did the testing on beagle,
where things are working fine
after off mode.
But if I enable hardware flow control, the teraterm does not allow me to
load my fs and uImage from mmc.
If you have any pointers on how to test hardware flow control, I will
like to do that on my beagle board.
Thanks,
Sourav
>> I will try to figure out how to do a hardware flow control testing
>> and see the status after the off mode.
> It's software flow control which isn't properly restored...
^ permalink raw reply
* alignment faults in 3.6
From: Måns Rullgård @ 2012-10-11 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349949638.21172.8445.camel@edumazet-glaptop>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> On Thu, 2012-10-11 at 10:45 +0100, M?ns Rullg?rd wrote:
>> "David Laight" <David.Laight@ACULAB.COM> writes:
>>
>> >> -----Original Message-----
>> >> From: netdev-owner at vger.kernel.org [mailto:netdev-owner at vger.kernel.org] On Behalf Of M?ns Rullg?rd
>> >> Sent: 11 October 2012 03:27
>> >> To: Jon Masters
>> >> Cc: linux-arm-kernel at lists.infradead.org; netdev at vger.kernel.org
>> >> Subject: Re: alignment faults in 3.6
>> >>
>> >> Jon Masters <jonathan@jonmasters.org> writes:
>> >>
>> >> > Hi everyone,
>> >> >
>> >> > On 10/05/2012 10:33 AM, Rob Herring wrote:
>> >> >> On 10/05/2012 09:05 AM, Russell King - ARM Linux wrote:
>> >> >>> On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
>> >> >>>> On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
>> >> >>>>> Does it matter? I'm just relaying the argument against adding __packed
>> >> >>>>> which was used before we were forced (by the networking folk) to implement
>> >> >>>>> the alignment fault handler.
>> >> >>>>
>> >> >>>> It doesn't really matter what will be accepted or not as adding __packed
>> >> >>>> to struct iphdr doesn't fix the problem anyway.
>> > ...
>> >> There are exactly two possible solutions:
>> >>
>> >> 1. Change the networking code so those structs are always aligned. This
>> >> might not be (easily) possible.
>> >> 2. Mark the structs __packed and fix any typecasts like the ones seen in
>> >> this thread. This will have an adverse effect in cases where the
>> >> structs are in fact aligned.
>> >>
>> >> Both solutions lie squarely in the networking code. It's time to
>> >> involve that list, or we'll never get anywhere.
>> >
>> > It might be enough to use __attribute__((aligned(2))) on some structure
>> > members (actually does 'ldm' need 8 byte alignment?? - in which case
>> > aligned(4) is enough).
>>
>> The aligned attribute can only increase alignment.
>
> I have no idea what is the problem,
>
> -ENOTENOUGHCONTEXT
The thread starts here:
http://marc.info/?l=linux-arm-kernel&m=134939228120020
Summary: a pointer to "struct iphdr" is not 4-byte aligned as required
by the ARM ABI rules, and this causes traps to the unaligned access
fault handler. A recent change makes the kernel print "scheduling while
atomic" warnings on some of these traps, which may or may not be
benign. Either way, this is bad for performance and should be fixed one
way or another.
--
M?ns Rullg?rd
mans at mansr.com
^ permalink raw reply
* [PATCH v4 RESEND 1/3] Input: egalax_ts: get gpio from devicetree
From: Russell King - ARM Linux @ 2012-10-11 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011085535.GA31464@S2101-09.ap.freescale.net>
On Thu, Oct 11, 2012 at 04:55:40PM +0800, Shawn Guo wrote:
> Add LAKML ...
>
> On Wed, Oct 10, 2012 at 09:30:36AM -0700, Dmitry Torokhov wrote:
> > Hi Hui,
> >
> > On Wed, Oct 10, 2012 at 05:12:01PM +0800, Hui Wang wrote:
> > > The irq_to_gpio() is old, most platforms use GENERIC_GPIO framework
> > > and don't support this API anymore.
> > >
> > > The i.MX6q sabrelite platform equips an egalax touchscreen controller,
> > > and this platform already transfered to GENERIC_GPIO framework, to
> > > support this driver, we use a more generic way to get gpio.
> >
> > Unfortunately this does break the driver for platforms that do still
> > support irq_to_gpio and have not transitioned to device tree (yet?).
> > It looks like the API suffered from premature deletion...
> >
> > I really do not want to add a new platform data structure with only gpio
> > in it, is there a better way to detect if irq_to_gpio() (even if only a
> > stub) is available?
> >
> If CONFIG_ARCH_HAVE_CUSTOM_GPIO_H is not enabled for an architecture,
> the irq_to_gpio() in include/linux/gpio.h will tell unavailability by
> returning -EINVAL. But ARM architecture still selects ARCH_HAVE_CUSTOM_GPIO_H
> because there are still some platforms having mach/gpio.h.
>
> We may also need a stub irq_to_gpio simply returning -EINVAL into
> arch/arm/include/asm/gpio.h when platform does not provide irq_to_gpio,
> so that driver can detect if irq_to_gpio() is available. And that
> stub can be removed later when we deselect ARCH_HAVE_CUSTOM_GPIO_H
> for ARM architecture.
Or fix the drivers using irq_to_gpio() not to use it. I thought we had
resolved to do that already, with Grant's agreement that irq_to_gpio()
needed to die.
(Mainly because neither gpiolib nor the IRQ layer provides any assistance
for irq_to_gpio(), so it's not possible to make it work for all GPIOs in
the system, especially when GPIOs are allocated dynamically.)
^ permalink raw reply
* alignment faults in 3.6
From: David Laight @ 2012-10-11 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xpq4ppcju.fsf@unicorn.mansr.com>
> > It might be enough to use __attribute__((aligned(2))) on some structure
> > members (actually does 'ldm' need 8 byte alignment?? - in which case
> > aligned(4) is enough).
>
> The aligned attribute can only increase alignment.
Not true.
If you have:
struct foo {
short a;
int b __attribute__((aligned(2)));
short c;
};
You'll find sizeof (struct foo) is 8, and that, on arm/sparc etc,
gcc will generate 2 16bit accesses (and shifts) for foo.b;
David
^ permalink raw reply
* [PATCH 01/13] calk: davinci - add Main PLL clock driver
From: Sekhar Nori @ 2012-10-11 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3E54258959B69E4282D79E01AB1F32B7041FB712@DFLE12.ent.ti.com>
On 10/10/2012 8:04 PM, Karicheri, Muralidharan wrote:
>>>> +struct clk *clk_register_davinci_pll(struct device *dev, const char *name,
>>>> + const char *parent_name,
>>>> + struct clk_davinci_pll_data *pll_data) {
>>>> + struct clk_init_data init;
>>>> + struct clk_davinci_pll *pll;
>>>> + struct clk *clk;
>>>> +
>>>> + if (!pll_data)
>>>> + return ERR_PTR(-ENODEV);
>>>> +
>>>> + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
>>>> + if (!pll)
>>>> + return ERR_PTR(-ENOMEM);
>>>> + init.name = name;
>>>> + init.ops = &clk_pll_ops;
>>>> + init.flags = pll_data->flags;
>>>> + init.parent_names = (parent_name ? &parent_name : NULL);
>>>> + init.num_parents = (parent_name ? 1 : 0);
>>>> +
>>>> + pll->pll_data = pll_data;
>>>> + pll->hw.init = &init;
>>>> +
>>>> + clk = clk_register(NULL, &pll->hw);
>>>> + if (IS_ERR(clk))
>>>> + kfree(pll);
>>>> +
>>>> + return clk;
>>>> +}
>>>
>>> I guess there is an an "unregister" required as well which will free the pll memory
>>> allocated above and unregister the clock? Not sure if you would ever unregister a PLL,
>>> but providing this will probably help symmetry.
> Sekhar,
>
> clk_unregister() itself is a null statement in clk.c. Besides none of the clk drivers presently have implemented the unregister(). So I believe this is unnecessary.
I am ok with this.
> BTW, please review the v2 patch for the rest of the series. For the one you have already reviewed, it should be fine.
Okay. I see those now. BTW, this series also has a v2 in its 0/13. Are
there any differences between this and the other v2, or is that merely a
resend?
Thanks,
Sekhar
^ permalink raw reply
* [REMINDER: PATCH 1/1] mtd:nand:clk: preparation for switch to common clock framework
From: Artem Bityutskiy @ 2012-10-11 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50769A45.5030105@ti.com>
On Thu, 2012-10-11 at 15:37 +0530, Sekhar Nori wrote:
> Hi Artem,
>
> On 10/11/2012 3:27 PM, Artem Bityutskiy wrote:
> > On Fri, 2012-09-28 at 16:10 +0000, Karicheri, Muralidharan wrote:
> >>>> -----Original Message-----
> >>>> From: Karicheri, Muralidharan
> >>>> Sent: Monday, September 17, 2012 12:38 PM
> >>>> To: dwmw2 at infradead.org; artem.bityutskiy at linux.intel.com; hs at denx.de;
> >>>> mikedunn at newsguy.com; linux-mtd at lists.infradead.org; linux-kernel at vger.kernel.org;
> >>>> davinci-linux-open-source at linux.davincidsp.com; linux-arm-kernel at lists.infradead.org
> >>>> Cc: Karicheri, Muralidharan
> >>>> Subject: [PATCH 1/1] mtd:nand:clk: preparation for switch to common clock framework
> >
> > I do not see this patch in my mailbox. Can you please re-send with all
> > the acks?
>
> This patch is already applied to linux-next. Do you need it still?
>
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=ea73fe7f0d562154975a77fe77ae3da6ab4d3e77
Ah, right, no, I don't, thanks!
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121011/684817ab/attachment.sig>
^ permalink raw reply
* [REMINDER: PATCH 1/1] mtd:nand:clk: preparation for switch to common clock framework
From: Sekhar Nori @ 2012-10-11 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349949469.20594.67.camel@sauron.fi.intel.com>
Hi Artem,
On 10/11/2012 3:27 PM, Artem Bityutskiy wrote:
> On Fri, 2012-09-28 at 16:10 +0000, Karicheri, Muralidharan wrote:
>>>> -----Original Message-----
>>>> From: Karicheri, Muralidharan
>>>> Sent: Monday, September 17, 2012 12:38 PM
>>>> To: dwmw2 at infradead.org; artem.bityutskiy at linux.intel.com; hs at denx.de;
>>>> mikedunn at newsguy.com; linux-mtd at lists.infradead.org; linux-kernel at vger.kernel.org;
>>>> davinci-linux-open-source at linux.davincidsp.com; linux-arm-kernel at lists.infradead.org
>>>> Cc: Karicheri, Muralidharan
>>>> Subject: [PATCH 1/1] mtd:nand:clk: preparation for switch to common clock framework
>
> I do not see this patch in my mailbox. Can you please re-send with all
> the acks?
This patch is already applied to linux-next. Do you need it still?
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=ea73fe7f0d562154975a77fe77ae3da6ab4d3e77
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] usb: remove CONFIG_USB_MUSB_HOST etc
From: Constantine Shulyupin @ 2012-10-11 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50768850.7030607@ti.com>
I've tested gadget mode on DM365 without HW changes.
On Thu, Oct 11, 2012 at 10:50 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On 10/11/2012 12:05 PM, Heiko Schocher wrote:
>> Hello Manjunathappa
>>
>> On 11.10.2012 07:42, Manjunathappa, Prakash wrote:
>>> Hi,
>>> On Mon, Oct 08, 2012 at 18:47:07, Constantine Shulyupin wrote:
>>>> From: Constantine Shulyupin<const@MakeLinux.com>
>>>>
>>>> Remove USB configuration in arch/arm/mach-davinci/usb.c accordingly
>>>> CONFIG_USB_MUSB_OTG CONFIG_USB_MUSB_PERIPHERAL CONFIG_USB_MUSB_HOST
>>>> and set MUSB_OTG configuration by default
>>>> because this configuration options are removed from Kconfig.
>>>>
>>>> Signed-off-by: Constantine Shulyupin<const@MakeLinux.com>
>>>>
>>>> ---
>>>> arch/arm/mach-davinci/usb.c | 6 ------
>>>> 1 file changed, 6 deletions(-)
>>>>
>>>> diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c
>>>> index f77b953..34509ff 100644
>>>> --- a/arch/arm/mach-davinci/usb.c
>>>> +++ b/arch/arm/mach-davinci/usb.c
>>>> @@ -42,14 +42,8 @@ static struct musb_hdrc_config musb_config = {
>>>> };
>>>>
>>>> static struct musb_hdrc_platform_data usb_data = {
>>>> -#if defined(CONFIG_USB_MUSB_OTG)
>>>> /* OTG requires a Mini-AB connector */
>>>> .mode = MUSB_OTG,
>>>> -#elif defined(CONFIG_USB_MUSB_PERIPHERAL)
>>>> - .mode = MUSB_PERIPHERAL,
>>>> -#elif defined(CONFIG_USB_MUSB_HOST)
>>>> - .mode = MUSB_HOST,
>>>> -#endif
>>>> .clock = "usb",
>>>> .config =&musb_config,
>>>> };
>>>
>>> Tested it on DM6446-EVM for host mode with MSC thumb drive and gadget
>>> mode with g-ether. It works.
>>>
>>> Acked-by: Manjunathappa, Prakash<prakash.pm@ti.com>
>>
>> I sent a similiar patch here:
>>
>> http://comments.gmane.org/gmane.linux.usb.general/54512
>>
>> If the issues, mentioned from Sergei for my patch, nullified I add my:
>
> The last outstanding issue from Sergei seems to be additional comments
> describing why MUSB_OTG is OK to use.
>
> Prakash/Constantine,
>
> Did you have to make any hardware changes when testing host/gadget on
> DM6446 EVM? Or change in kernel configuration?
>
> It appears that there is no way to choose any of the config option
> affecting the mode setting. Right now it seems to be just defaulting to
> MUSB_UNDEFINED. Setting it to MUSB_OTG would be better than that.
>
> Thanks,
> Sekhar
--
Constantine Shulyupin
http://www.MakeLinux.com/
Embedded Linux Systems,
Device Drivers, TI DaVinci
^ permalink raw reply
* alignment faults in 3.6
From: Eric Dumazet @ 2012-10-11 10:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xpq4ppcju.fsf@unicorn.mansr.com>
On Thu, 2012-10-11 at 10:45 +0100, M?ns Rullg?rd wrote:
> "David Laight" <David.Laight@ACULAB.COM> writes:
>
> >> -----Original Message-----
> >> From: netdev-owner at vger.kernel.org [mailto:netdev-owner at vger.kernel.org] On Behalf Of M?ns Rullg?rd
> >> Sent: 11 October 2012 03:27
> >> To: Jon Masters
> >> Cc: linux-arm-kernel at lists.infradead.org; netdev at vger.kernel.org
> >> Subject: Re: alignment faults in 3.6
> >>
> >> Jon Masters <jonathan@jonmasters.org> writes:
> >>
> >> > Hi everyone,
> >> >
> >> > On 10/05/2012 10:33 AM, Rob Herring wrote:
> >> >> On 10/05/2012 09:05 AM, Russell King - ARM Linux wrote:
> >> >>> On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
> >> >>>> On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
> >> >>>>> Does it matter? I'm just relaying the argument against adding __packed
> >> >>>>> which was used before we were forced (by the networking folk) to implement
> >> >>>>> the alignment fault handler.
> >> >>>>
> >> >>>> It doesn't really matter what will be accepted or not as adding __packed
> >> >>>> to struct iphdr doesn't fix the problem anyway.
> > ...
> >> There are exactly two possible solutions:
> >>
> >> 1. Change the networking code so those structs are always aligned. This
> >> might not be (easily) possible.
> >> 2. Mark the structs __packed and fix any typecasts like the ones seen in
> >> this thread. This will have an adverse effect in cases where the
> >> structs are in fact aligned.
> >>
> >> Both solutions lie squarely in the networking code. It's time to
> >> involve that list, or we'll never get anywhere.
> >
> > It might be enough to use __attribute__((aligned(2))) on some structure
> > members (actually does 'ldm' need 8 byte alignment?? - in which case
> > aligned(4) is enough).
>
> The aligned attribute can only increase alignment.
>
I have no idea what is the problem,
-ENOTENOUGHCONTEXT
^ permalink raw reply
* [REMINDER: PATCH 1/1] mtd:nand:clk: preparation for switch to common clock framework
From: Artem Bityutskiy @ 2012-10-11 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3E54258959B69E4282D79E01AB1F32B7041EF679@DFLE12.ent.ti.com>
On Fri, 2012-09-28 at 16:10 +0000, Karicheri, Muralidharan wrote:
> >> -----Original Message-----
> >> From: Karicheri, Muralidharan
> >> Sent: Monday, September 17, 2012 12:38 PM
> >> To: dwmw2 at infradead.org; artem.bityutskiy at linux.intel.com; hs at denx.de;
> >> mikedunn at newsguy.com; linux-mtd at lists.infradead.org; linux-kernel at vger.kernel.org;
> >> davinci-linux-open-source at linux.davincidsp.com; linux-arm-kernel at lists.infradead.org
> >> Cc: Karicheri, Muralidharan
> >> Subject: [PATCH 1/1] mtd:nand:clk: preparation for switch to common clock framework
I do not see this patch in my mailbox. Can you please re-send with all
the acks?
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121011/7d5ad1bf/attachment.sig>
^ permalink raw reply
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Russell King - ARM Linux @ 2012-10-11 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507694CF.3020204@ti.com>
On Thu, Oct 11, 2012 at 03:13:43PM +0530, Sourav wrote:
>
> Hi Kevin,
> On Wednesday 10 October 2012 11:59 PM, Kevin Hilman wrote:
>> Hi Sourav,
>>
>> Sourav <sourav.poddar@ti.com> writes:
>>
>> [...]
>>
>>> Boot Tested this patch series against v3.6 tag(applied cleanly) on
>>> panda board and
>>> PM tested(hitting off in Idle and suspend) on omap3630 based beagle board.
>>>
>>> Note, I also tested the patches against the current master but only
>>> after rebasing, since the current master includes serial patches from
>>> Felipe Balbi[1].
>>> [1] https://lkml.org/lkml/2012/8/24/139
>>>
>>> Tested-by: Sourav Poddar <sourav.poddar@ti.com>
>> Did you test flow control after off-mode transitons?
>>
>> Russell indicated that the context save/restore is not saving important
>> bits related to HW flow control, so I suspect some more testing,
>> specifically of flow control after off-mode is needed.
>>
>> Kevin
> The testing done was without any flow control enabled.
So, as the patch set is about fixing the flow control stuff, would
you say that your testing without flow control enabled has much value?
> I will try to figure out how to do a hardware flow control testing
> and see the status after the off mode.
It's software flow control which isn't properly restored...
^ permalink raw reply
* alignment faults in 3.6
From: Måns Rullgård @ 2012-10-11 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7038@saturn3.aculab.com>
"David Laight" <David.Laight@ACULAB.COM> writes:
>> -----Original Message-----
>> From: netdev-owner at vger.kernel.org [mailto:netdev-owner at vger.kernel.org] On Behalf Of M?ns Rullg?rd
>> Sent: 11 October 2012 03:27
>> To: Jon Masters
>> Cc: linux-arm-kernel at lists.infradead.org; netdev at vger.kernel.org
>> Subject: Re: alignment faults in 3.6
>>
>> Jon Masters <jonathan@jonmasters.org> writes:
>>
>> > Hi everyone,
>> >
>> > On 10/05/2012 10:33 AM, Rob Herring wrote:
>> >> On 10/05/2012 09:05 AM, Russell King - ARM Linux wrote:
>> >>> On Fri, Oct 05, 2012 at 07:24:44AM -0500, Rob Herring wrote:
>> >>>> On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
>> >>>>> Does it matter? I'm just relaying the argument against adding __packed
>> >>>>> which was used before we were forced (by the networking folk) to implement
>> >>>>> the alignment fault handler.
>> >>>>
>> >>>> It doesn't really matter what will be accepted or not as adding __packed
>> >>>> to struct iphdr doesn't fix the problem anyway.
> ...
>> There are exactly two possible solutions:
>>
>> 1. Change the networking code so those structs are always aligned. This
>> might not be (easily) possible.
>> 2. Mark the structs __packed and fix any typecasts like the ones seen in
>> this thread. This will have an adverse effect in cases where the
>> structs are in fact aligned.
>>
>> Both solutions lie squarely in the networking code. It's time to
>> involve that list, or we'll never get anywhere.
>
> It might be enough to use __attribute__((aligned(2))) on some structure
> members (actually does 'ldm' need 8 byte alignment?? - in which case
> aligned(4) is enough).
The aligned attribute can only increase alignment.
--
M?ns Rullg?rd
mans at mansr.com
^ permalink raw reply
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Sourav @ 2012-10-11 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mwzuxjtc.fsf@deeprootsystems.com>
Hi Kevin,
On Wednesday 10 October 2012 11:59 PM, Kevin Hilman wrote:
> Hi Sourav,
>
> Sourav <sourav.poddar@ti.com> writes:
>
> [...]
>
>> Boot Tested this patch series against v3.6 tag(applied cleanly) on
>> panda board and
>> PM tested(hitting off in Idle and suspend) on omap3630 based beagle board.
>>
>> Note, I also tested the patches against the current master but only
>> after rebasing, since the current master includes serial patches from
>> Felipe Balbi[1].
>> [1] https://lkml.org/lkml/2012/8/24/139
>>
>> Tested-by: Sourav Poddar <sourav.poddar@ti.com>
> Did you test flow control after off-mode transitons?
>
> Russell indicated that the context save/restore is not saving important
> bits related to HW flow control, so I suspect some more testing,
> specifically of flow control after off-mode is needed.
>
> Kevin
The testing done was without any flow control enabled.
I will try to figure out how to do a hardware flow control testing
and see the status after the off mode.
~Sourav
^ permalink raw reply
* [PATCH v4 RESEND 1/3] Input: egalax_ts: get gpio from devicetree
From: Hui Wang @ 2012-10-11 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011085535.GA31464@S2101-09.ap.freescale.net>
Shawn Guo wrote:
> Add LAKML ...
>
> On Wed, Oct 10, 2012 at 09:30:36AM -0700, Dmitry Torokhov wrote:
>
>> Hi Hui,
>>
>> On Wed, Oct 10, 2012 at 05:12:01PM +0800, Hui Wang wrote:
>>
>>> The irq_to_gpio() is old, most platforms use GENERIC_GPIO framework
>>> and don't support this API anymore.
>>>
>>> The i.MX6q sabrelite platform equips an egalax touchscreen controller,
>>> and this platform already transfered to GENERIC_GPIO framework, to
>>> support this driver, we use a more generic way to get gpio.
>>>
>> Unfortunately this does break the driver for platforms that do still
>> support irq_to_gpio and have not transitioned to device tree (yet?).
>> It looks like the API suffered from premature deletion...
>>
>> I really do not want to add a new platform data structure with only gpio
>> in it, is there a better way to detect if irq_to_gpio() (even if only a
>> stub) is available?
>>
>>
> If CONFIG_ARCH_HAVE_CUSTOM_GPIO_H is not enabled for an architecture,
> the irq_to_gpio() in include/linux/gpio.h will tell unavailability by
> returning -EINVAL. But ARM
>
So far, the only way i can figure out is to add following in the
arch/arm/include/asm/gpio.h
static inline int arm_irq_to_gpio(unsigned int irq)
{
return -EINVAL;
}
#ifndef irq_to_gpio
#define irq_to_gpio arm_irq_to_gpio
#endif
And remove all irq_to_gpio() function definitions in the arch/arm/, if
mach want a specific irq_to_gpio, they can use macro to define their own.
Regards,
Hui.
^ permalink raw reply
* [PATCH 4/6] ARM: ux500: Add UART support to the u9540 Device Tree
From: Lee Jones @ 2012-10-11 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011085002.GV12801@game.jcrosoft.org>
On Thu, 11 Oct 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 08:29 Thu 11 Oct , Lee Jones wrote:
> > On Wed, 10 Oct 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >
> > > On 16:18 Wed 10 Oct , Lee Jones wrote:
> > > > Add the 3 UART nodes required to enable serial ports on the u9540.
> > > >
> > > > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > ---
> > > > arch/arm/boot/dts/u9540.dts | 13 ++++++++++++-
> > > dts? it's dtsi
> >
> > No it's not.
> so the name of the file is wrong s u9540 is a SoC name
The board could actually be called either ccu9540, or just
u9540. I picked one and went with it. The full name is the
u9540 development board.
--
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 3/6] ARM: ux500: Add support for ST-Ericsson's u9540 SoC
From: Lee Jones @ 2012-10-11 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011085223.GW12801@game.jcrosoft.org>
On Thu, 11 Oct 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 08:38 Thu 11 Oct , Lee Jones wrote:
> > On Wed, 10 Oct 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >
> > > On 16:18 Wed 10 Oct , Lee Jones wrote:
> > > > First level board support for the u9540.
> > > >
> > > > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > > ---
> > > > arch/arm/mach-ux500/cpu-db8500.c | 14 ++++++++++++++
> > > > 1 file changed, 14 insertions(+)
> > > >
> > > > diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c
> > > > index 3d8e321..6b7f970 100644
> > > > --- a/arch/arm/mach-ux500/cpu-db8500.c
> > > > +++ b/arch/arm/mach-ux500/cpu-db8500.c
> > > > @@ -17,6 +17,7 @@
> > > > #include <linux/platform_device.h>
> > > > #include <linux/io.h>
> > > > #include <linux/mfd/abx500/ab8500.h>
> > > > +#include <linux/mfd/dbx500-prcmu.h>
> > > > #include <linux/of.h>
> > > > #include <linux/of_platform.h>
> > > > #include <linux/regulator/machine.h>
> > > > @@ -319,6 +320,8 @@ static void __init u8500_init_machine(void)
> > > > snowball_pinmaps_init();
> > > > else if (of_machine_is_compatible("st-ericsson,hrefv60+"))
> > > > hrefv60_pinmaps_init();
> > > > + else if (of_machine_is_compatible("st-ericsson,u9540")) {}
> > > > + /* TODO: Add u9540 pinmaps. */
> > > do you via DT no here
> >
> > We don't support pinctrl yet. It will come, it's just not available yet.
> so stop to add more and update the drviers
We'll get round to it.
We have a set priority list. Neither you nor I have control over that.
> and u9540 is a SoC name not a baord name
It's both. The u9540 board is affectionately called the u9540 board.
> > > > /* TODO: Export SoC, USB, cpu-freq and DMA40 */
> > > > parent = u8500_of_init_devices();
> > > > @@ -331,6 +334,7 @@ static const char * u8500_dt_board_compat[] = {
> > > > "calaosystems,snowball-a9500",
> > > > "st-ericsson,hrefv60+",
> > > > "st-ericsson,mop500",
> > > > + "st-ericsson,u9540",
> > > stop to add more compatible sue a more generic one
> >
> > Not entirely sure what you mean here.
> >
> > These are the only four boards we officially support.
> >
> > There are other uXXXX boards that we do not.
> you do not need it just mach a global compatbile
Why? What difference does it make? I could understand if we
had a long list of supported boards, but I think this is move
verbose and descriptive.
> > > > NULL,
> > > > };
> > > >
> > > > @@ -345,4 +349,14 @@ DT_MACHINE_START(U8500_DT, "ST-Ericsson U8500 platform (Device Tree Support)")
> > > > .dt_compat = u8500_dt_board_compat,
> > > > MACHINE_END
> > > >
> > > > +DT_MACHINE_START(U9540_DT, "ST-Ericsson 9540 platform (Device Tree Support)")
> > > > + .map_io = u8500_map_io,
> > > > + .init_irq = ux500_init_irq,
> > > > + .timer = &ux500_timer,
> > > > + .handle_irq = gic_handle_irq,
> > > > + .init_machine = u8500_init_machine,
> > > > + .init_late = NULL,
> > > > + .dt_compat = u8500_dt_board_compat,
> > > > +MACHINE_END
> > > really?
> > > no need drop it for a more generic on
> >
> > This may look the same as the previous MACHINE_START now, but
> > it will have differences in the future as more u9540 support is
> > upstreamed. I think it should stick around as a separate entity
> > for the time being. If we can consolidate the init functions at
> > a later date, believe me I will make sure it happens.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ 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