* [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
From: Premi, Sanjeev @ 2011-01-06 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D25CB18.3080904@ti.com>
> -----Original Message-----
> From: Menon, Nishanth
> Sent: Thursday, January 06, 2011 7:31 PM
> To: Premi, Sanjeev
> Cc: Koen Kooi; Hilman, Kevin; l-o; l-a; Tony
> Subject: Re: [PATCH 2/2] OMAP3: beagle xm: enable upto 800MHz OPP
>
> Premi, Sanjeev had written, on 01/06/2011 07:58 AM, the following:
> [..]
> > Some of the patches generic that Koen attached are based on my
> > submissions. As part of migration to 2.6.37, I am in process of
> > validating them on internal integration tree. Will post them
> > soon... may be end of tomorrow.
> >
> > I will be testing them on OMAP3EVM.
> Sure. please do post them to l-o and cc l-a - I suppose until
> then, they
> are unofficial if they are lying around in some private tree(even if
> viewable over internet ;) ).
That's what I meant by submitting :)
My plans were tomorrow/MON - wasn't expecting this thread to happen!!
~sanjeev
>
> --
> Regards,
> Nishanth Menon
>
^ permalink raw reply
* [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
From: Premi, Sanjeev @ 2011-01-06 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294225024-21857-2-git-send-email-santosh.shilimkar@ti.com>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org
> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of
> Santosh Shilimkar
> Sent: Wednesday, January 05, 2011 4:27 PM
> To: linux-omap at vger.kernel.org
> Cc: Hilman, Kevin; tony at atomide.com;
> linux-arm-kernel at lists.infradead.org; Shilimkar, Santosh;
> Paul Walmsley
> Subject: [PATCH v2 2/5] omap2plus: prm: Trvial build break
> fix for undefined reference to 'omap2_prm_read_mod_reg'
[snip]
>
> #ifndef __ASSEMBLER__
> -
> +/*
> + * Stub omap2xxx/omap3xxx functions so that common files
> + * continue to build when custom builds are used
> + */
> +#if defined(CONFIG_ARCH_OMAP4) &&
> !(defined(CONFIG_ARCH_OMAP2) || \
> + defined(CONFIG_ARCH_OMAP3))
> +static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
> +{
> + WARN_ONCE(1, "prm: omap2xxx/omap3xxx specific function and "
> + "not suppose to be used on omap4\n");
> + return 0;
> +}
Looking forward, the warning of incorrect SOC may be required
for when kernel is build for one specific SOC.
Wouldn't it be easy/better to have common global function:
void wrong_soc(char* func, int soc_id)
{
WARN_ONCE(1, "Function %s cannot be used for %d", func, soc_id);
}
OR we could have soc specific functions e.g.
void omap2xxx_only (char* func)
{
WARN_ONCE(1, "Function %s is specific to OMAP2XXX");
}
..etc..
Later these functions can be called from the stubs.
This is prelim idea, will need to be worked upon.
~sanjeev
^ permalink raw reply
* [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
From: Santosh Shilimkar @ 2011-01-06 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930248201A7E@dbde02.ent.ti.com>
> -----Original Message-----
> From: Premi, Sanjeev [mailto:premi at ti.com]
> Sent: Thursday, January 06, 2011 8:03 PM
> To: Shilimkar, Santosh; linux-omap at vger.kernel.org
> Cc: Hilman, Kevin; tony at atomide.com; linux-arm-
> kernel at lists.infradead.org; Shilimkar, Santosh; Paul Walmsley
> Subject: RE: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix
> for undefined reference to 'omap2_prm_read_mod_reg'
>
> > -----Original Message-----
> > From: linux-omap-owner at vger.kernel.org
> > [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of
> > Santosh Shilimkar
> > Sent: Wednesday, January 05, 2011 4:27 PM
> > To: linux-omap at vger.kernel.org
> > Cc: Hilman, Kevin; tony at atomide.com;
> > linux-arm-kernel at lists.infradead.org; Shilimkar, Santosh;
> > Paul Walmsley
> > Subject: [PATCH v2 2/5] omap2plus: prm: Trvial build break
> > fix for undefined reference to 'omap2_prm_read_mod_reg'
>
> [snip]
>
> >
> > #ifndef __ASSEMBLER__
> > -
> > +/*
> > + * Stub omap2xxx/omap3xxx functions so that common files
> > + * continue to build when custom builds are used
> > + */
> > +#if defined(CONFIG_ARCH_OMAP4) &&
> > !(defined(CONFIG_ARCH_OMAP2) || \
> > + defined(CONFIG_ARCH_OMAP3))
> > +static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
> > +{
> > + WARN_ONCE(1, "prm: omap2xxx/omap3xxx specific function and "
> > + "not suppose to be used on omap4\n");
> > + return 0;
> > +}
> Looking forward, the warning of incorrect SOC may be required
> for when kernel is build for one specific SOC.
>
> Wouldn't it be easy/better to have common global function:
>
> void wrong_soc(char* func, int soc_id)
> {
> WARN_ONCE(1, "Function %s cannot be used for %d", func,
> soc_id);
> }
>
> OR we could have soc specific functions e.g.
>
> void omap2xxx_only (char* func)
> {
> WARN_ONCE(1, "Function %s is specific to OMAP2XXX");
> }
> ..etc..
>
> Later these functions can be called from the stubs.
>
> This is prelim idea, will need to be worked upon.
>
Not sure. May appear like over engineering considering it's a
stub.
Paul can comment.
Regards,
Santosh
^ permalink raw reply
* [PATCH 1/2] stackprotector: add stack smashing protector generic implementation
From: Carmelo AMOROSO @ 2011-01-06 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106141946.GE31708@n2100.arm.linux.org.uk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 1/6/2011 3:19 PM, Russell King - ARM Linux wrote:
> On Thu, Jan 06, 2011 at 03:16:25PM +0100, Carmelo AMOROSO wrote:
> > Well, SH (in CC) does not have this support. Indeed we posted it
> > initially to linux-sh only. We got useful feedback from Paul, Mike and
> > Nicolas suggesting to promote the ARM/SH solution based on the global
> > __stack_chk_guard variable as a generic solution for all other
> > architectures. This is why I thought to post to the LKML instead of each
> > linux-<arch> list.
>
> Have you thought about posting it to _the_ linux-arch list?
>
I did not know this list. I'll do. Thanks.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0l1RUACgkQoRq/3BrK1s8a1gCgpSdHez/S8cJ8BM5jVhYH0TKy
84gAnRkeALaLGMoXJqtxdDRL7Xusc6JT
=L6Oj
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH 1/3] ARM i.MX53: enable fec driver on EVK board
From: Russell King - ARM Linux @ 2011-01-06 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294317033-9194-2-git-send-email-yong.shen@freescale.com>
On Thu, Jan 06, 2011 at 08:30:31PM +0800, yong.shen at freescale.com wrote:
> #include <linux/init.h>
> #include <linux/clk.h>
> +#include <linux/fec.h>
> +#include <linux/delay.h>
> #include <mach/common.h>
> #include <mach/hardware.h>
> +#include <mach/gpio.h>
linux/gpio.h please
^ permalink raw reply
* [patch v2] mtd: pxa3xx_nand: NULL dereference in pxa3xx_nand_probe
From: Artem Bityutskiy @ 2011-01-06 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106140536.GB1717@bicker>
On Thu, 2011-01-06 at 17:05 +0300, Dan Carpenter wrote:
> "info->cmdset" gets dereferenced in __readid() so it needs to be
> initialized earlier in the function. This bug was introduced in
> 18c81b1828f8 "mtd: pxa3xx_nand: remove the flash info in driver
> structure".
>
> Cc: stable at kernel.org [2.6.37+]
> Reported-and-tested-by: Sven Neumann <s.neumann@raumfeld.com>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
> ---
> v2: changed the commit text. added stable at kernel.org and a reported-by tag.
Pushed to l2-mtd-2.6.git, thanks!
--
Best Regards,
Artem Bityutskiy (???????? ?????)
^ permalink raw reply
* [PATCH] omap: wd_timer: Fix crash frm wdt_probe when!CONFIG_RUNTIME_PM
From: Russell King - ARM Linux @ 2011-01-06 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19b4a66bfdd4ef3e51fdb27bf43b9ce2@mail.gmail.com>
On Thu, Jan 06, 2011 at 09:27:32AM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Sent: Thursday, January 06, 2011 3:49 AM
> > To: Santosh Shilimkar
> > Cc: linux-omap at vger.kernel.org; Paul Walmsley; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: [PATCH] omap: wd_timer: Fix crash frm wdt_probe
> > when!CONFIG_RUNTIME_PM
> >
> > On Wed, Jan 05, 2011 at 07:10:55PM +0530, Santosh Shilimkar wrote:
> > > Commit ff2516fb 'wd_timer: disable on boot via hwmod postsetup
> > mechanism'
> > > introduced watchdog timer state state management using
> > postsetup_state.
> > > This was done to allow some board files to support watchdog
> > coverage
> > > throughout kernel initialization and it work as intended when
> > RUNTIME_PM
> > > is enabled.
> > >
> > > With !CONFIG_RUNTIME_PM and no board is specifically requests
> > watchdog
> > > to remain enabled the omap_wdt_probe crashesh. This is because
> > hwmod
> > > in absense of runtime PM unable to turn watchdog clocks because
> > it's
> > > state is set to be disabled. For rest of the device, the state is
> > > set as enabled in absense of RUNTIME_PM
> >
> > Err... wasn't this provoked by an attempt to fix the LDP issue, that
> > is
> > (I believe) because the boot loader enables the watchdog and pre-
> > hwmod
> > kernels used to disable it. Post-hwmod kernels stopped disabling
> > the
> > watchdog, resulting in a few seconds booting userspace before the
> > system
> > resets itself.
>
> Yes. That's managed through the shutdown part. Apart from that there
> is another enhancement done in case some one wants to have WDT running
> throughout the kernel boot.
Good - and just to confirm, the fix for LDP watchdogging will be submitted
in the current merge window?
^ permalink raw reply
* [PATCH 1/1] mtd: msm_nand: Add initial msm nand driver support.
From: David Woodhouse @ 2011-01-06 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1293785680-19850-1-git-send-email-mnalajal@codeaurora.org>
On Fri, 2010-12-31 at 14:24 +0530, Murali Nalajala wrote:
>
> +#define NAND_CMD_STATUS 0x0C
> +#define NAND_CMD_RESET 0x0D
Er, what?
--
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
^ permalink raw reply
* [PATCH] ARM: Fix warning with gcc 4.5.1 in alignment fixup
From: Jamie Iles @ 2011-01-06 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1291753724-14437-1-git-send-email-jamie@jamieiles.com>
On Tue, Dec 07, 2010 at 08:28:44PM +0000, Jamie Iles wrote:
> With GCC 4.5.1 we get the following warning:
>
> CC arch/arm/mm/alignment.o
> arch/arm/mm/alignment.c: In function 'do_alignment':
> arch/arm/mm/alignment.c:720:21: warning: 'offset.un' may be used
> uninitialized in this function
>
> This warning is triggered for the LDM/STM instructions which don't have
> a register offset so set the offset to 0 to keep GCC happy.
>
> Cc: George G. Davis <gdavis@mvista.com>
> Cc: Min Zhang <mzhang@mvista.com>
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
> ---
Hi Russell,
Ok to send this one to the patch system?
Jamie
^ permalink raw reply
* [PATCH 1/1] mtd: msm_nand: Add initial msm nand driver support.
From: Russell King - ARM Linux @ 2011-01-06 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1293785680-19850-1-git-send-email-mnalajal@codeaurora.org>
On Fri, Dec 31, 2010 at 02:24:40PM +0530, Murali Nalajala wrote:
> + info->msm_nand.dev = &pdev->dev;
> +
> + init_waitqueue_head(&info->msm_nand.wait_queue);
> +
> + info->msm_nand.dma_channel = res->start;
> + pr_debug("dma channel 0x%x\n", info->msm_nand.dma_channel);
> + info->msm_nand.dma_buffer =
> + dma_alloc_coherent(NULL, MSM_NAND_DMA_BUFFER_SIZE,
> + &info->msm_nand.dma_addr, GFP_KERNEL);
Haven't you got a struct device for this (&pdev->dev) ?
> + if (info->msm_nand.dma_buffer == NULL) {
> + err = -ENOMEM;
> + goto out_free_info;
> + }
> +
> + pr_debug("allocated dma buffer at %p, dma_addr %x\n",
> + info->msm_nand.dma_buffer, info->msm_nand.dma_addr);
> +
> + info->mtd.name = dev_name(&pdev->dev);
> + info->mtd.priv = &info->msm_nand;
> + info->mtd.owner = THIS_MODULE;
> +
> + if (msm_nand_scan(&info->mtd, 1)) {
> + err = -ENXIO;
> + goto out_free_dma_buffer;
> + }
> +
> +#ifdef CONFIG_MTD_PARTITIONS
> + err = parse_mtd_partitions(&info->mtd, part_probes, &info->parts, 0);
> + if (err > 0)
> + err = add_mtd_partitions(&info->mtd, info->parts, err);
> + else if (err <= 0 && pdata && pdata->parts)
> + err = add_mtd_partitions(&info->mtd, pdata->parts,
> + pdata->nr_parts);
> + else
> +#endif
> + err = add_mtd_device(&info->mtd);
> +
> + if (err != 0)
> + goto out_free_dma_buffer;
> +
> + platform_set_drvdata(pdev, info);
> +
> + return 0;
> +
> +out_free_dma_buffer:
> + dma_free_coherent(NULL, MSM_NAND_DMA_BUFFER_SIZE,
Ditto.
> + info->msm_nand.dma_buffer, info->msm_nand.dma_addr);
> +out_free_info:
> + kfree(info);
> +
> + return err;
> +}
> +
> +static int __devexit msm_nand_remove(struct platform_device *pdev)
> +{
> + struct msm_nand_info *info = platform_get_drvdata(pdev);
> +
> + platform_set_drvdata(pdev, NULL);
> +
> +#ifdef CONFIG_MTD_PARTITIONS
> + if (info->parts)
> + del_mtd_partitions(&info->mtd);
> + else
> +#endif
> + del_mtd_device(&info->mtd);
> +
> + msm_nand_release(&info->mtd);
> + dma_free_coherent(NULL, MSM_NAND_DMA_BUFFER_SIZE,
Ditto.
^ permalink raw reply
* [PATCH V2] ARM: S5PV310: Implement kernel timers using MCT
From: Russell King - ARM Linux @ 2011-01-06 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294107527-27915-1-git-send-email-kgene.kim@samsung.com>
On Tue, Jan 04, 2011 at 11:18:47AM +0900, Kukjin Kim wrote:
> From: Changhwan Youn <chaos.youn@samsung.com>
>
> The Multi-Core Timer(MCT) of S5PV310 is designed for implementing
> clock source timer and clock event timers. This patch implements
> 1 clock source timer with 64 bit free running counter of MCT and
> 2 clock event timers with two of 31-bit tick counters.
I want to wait until after this merge window before commenting too much
on this; some of this patch will be impacted by changes in this merge
window.
> +static void s5pv310_frc_suspend(struct clocksource *cs)
> +{
> + time_suspended = s5pv310_frc_read(cs);
> +};
> +
> +static void s5pv310_frc_resume(struct clocksource *cs)
> +{
> + s5pv310_mct_frc_start((u32)(time_suspended >> 32), (u32)time_suspended);
> +};
Is this something which other clocksource drivers need to do, or does the
core automatically deal with the clocksource being irregular across a
suspend/resume event?
> +irqreturn_t s5pv310_mct_tick0_isr(int irq, void *dev_id)
> +{
> + struct clock_event_device *evt = dev_id;
> +
> + /*
> + * This is for supporting oneshot mode.
> + * Mct would generate interrupt periodically
> + * without explicit stopping.
> + */
> + if (evt->mode != CLOCK_EVT_MODE_PERIODIC)
> + s5pv310_mct_tick_stop(MCT_TICK0);
> +
> + /* Clear the MCT tick0 interrupt */
> + s5pv310_mct_write(0x1, S5PV310_MCT_L0_INT_CSTAT);
> +
> + evt->event_handler(evt);
> +
> + return IRQ_HANDLED;
> +}
> +
> +irqreturn_t s5pv310_mct_tick1_isr(int irq, void *dev_id)
> +{
> + struct clock_event_device *evt = dev_id;
> +
> + /*
> + * This is for supporting oneshot mode.
> + * Mct would generate interrupt periodically
> + * without explicit stopping.
> + */
> + if (evt->mode != CLOCK_EVT_MODE_PERIODIC)
> + s5pv310_mct_tick_stop(MCT_TICK1);
> +
> + /* Clear the MCT tick1 interrupt */
> + s5pv310_mct_write(0x1, S5PV310_MCT_L1_INT_CSTAT);
> +
> + evt->event_handler(evt);
> +
> + return IRQ_HANDLED;
> +}
Umm, why not wrap up the clock_event_device into your own structure,
which then carries the base address of the MCT to be used - rather than
duplicating the code just because the base address is different. Eg,
struct mct_clock_event_device {
struct clock_event_device evt;
void __iomem *base;
};
^ permalink raw reply
* [PATCH] leds/h1940: Use gpiolib for latch access / fix build failure
From: Vasily Khoruzhick @ 2011-01-06 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110104153725.2f3fede2.akpm@linux-foundation.org>
On Wednesday 05 January 2011 01:37:25 Andrew Morton wrote:
> So which patch to use?
>
> I queued Peter's patch because it's simpler. I queued it for
> 2.6.38-rc1, taged for backporting into 2.6.37.x, so we have a bit of
> time to think about it.
Anyway, it's time to drop leds-h1940 driver, I'll submit patch to support
H1940 leds via generic leds-gpio driver tonight.
Regards
Vasily
^ permalink raw reply
* [PATCH 1/2] Add a common struct clk
From: Richard Cochran @ 2011-01-06 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294199462.348449.192344022926.1.gpush@pororo>
On Wed, Jan 05, 2011 at 11:51:02AM +0800, Jeremy Kerr wrote:
> + * The @lock member provides either a spinlock or a mutex to protect (at least)
> + * @enable_count. The type of lock used will depend on @flags; if CLK_ATOMIC is
> + * set, then the core clock code will use a spinlock, otherwise a mutex. This
> + * lock will be acquired during clk_enable and clk_disable, so for atomic
> + * clocks, these ops callbacks must not sleep.
> + *
> + * The choice of atomic or non-atomic clock depends on how the clock is enabled.
> + * Typically, you'll want to use a non-atomic clock. For clocks that need to be
> + * enabled/disabled in interrupt context, use CLK_ATOMIC. Note that atomic
> + * clocks with parents will typically cascade enable/disable operations to
> + * their parent, so the parent of an atomic clock *must* be atomic too.
...
> +struct clk {
> + const struct clk_ops *ops;
> + unsigned int enable_count;
> + int flags;
> + union {
> + struct mutex mutex;
> + spinlock_t spinlock;
> + } lock;
> +};
Here you have a "polymorphic" lock, where the clock instance knows
which type it is supposed to be. I got flak from David Miller and
others trying to do the same thing with the mdio_bus:
http://kerneltrap.org/mailarchive/linux-netdev/2010/7/6/6280618
The criticism, applied to your case, is that the clk_enable() caller
cannot know whether it is safe to make the call or not. I was told,
"there has got to be a better way."
Richard
^ permalink raw reply
* [PATCH v2 0/3] add CNS3xxx AHCI support
From: Lin Mac @ 2011-01-06 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106105157.GA9560@oksana.dev.rtsoft.ru>
2011/1/6 Anton Vorontsov <cbouatmailru@gmail.com>:
> On Thu, Jan 06, 2011 at 02:43:08PM +0800, Lin Mac wrote:
> [...]
>> > It is overkill to rename the entirety of ahci_platform just for one override
>> > function.
>> > This sort of thing I would have expected to be added directly to
>> > ahci_platform.c.
>> It might be overkill for only one controller. but it is more clean and
>> readable to have different SoC specific changes in separate files,
>> especially when more SoCs need to make similar changes.
> I think that renaming the file is not necessary. You can just
> rename the module in the makefile.
That is for consist end user experience. I wouldn't like to find my
script not working anymore when changing to some linux version, simply
because someone fix some issue on some platform I'm not using.
> Personally I like the current approach more than putting
> controller-specific fixups directly into ahci_platform.
Best Regards,
Mac Lin.
^ permalink raw reply
* [PATCH] omap: wd_timer: Fix crash frm wdt_probewhen!CONFIG_RUNTIME_PM
From: Santosh Shilimkar @ 2011-01-06 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106152638.GC1198@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Thursday, January 06, 2011 8:57 PM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; Paul Walmsley; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH] omap: wd_timer: Fix crash frm
> wdt_probewhen!CONFIG_RUNTIME_PM
>
[.....]
> >
> > Yes. That's managed through the shutdown part. Apart from that
> there
> > is another enhancement done in case some one wants to have WDT
> running
> > throughout the kernel boot.
>
> Good - and just to confirm, the fix for LDP watchdogging will be
> submitted
> in the current merge window?
Yes. It's in the queue already.
^ permalink raw reply
* [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling
From: Kevin Hilman @ 2011-01-06 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BC214410FD04D84F9079A62423659707161C0C@008-AM1MPN1-003.mgdnok.nokia.com>
<aaro.koskinen@nokia.com> writes:
> Hi,
>
> Kevin Hilman [khilman at ti.com]:
>> Aaro Koskinen <aaro.koskinen@nokia.com> writes:
>>
>> > Make !CONFIG_SUSPEND init declarations identical on all OMAPs and
>> > eliminate some ifdefs.
>> >
>> > Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
>>
>> I like this solution, but it introduces compiler warnings:
>>
>> [...]
>>
>> As you likely noticed, removing the const leads to checkpatch warnings:
>>
>> WARNING: struct platform_suspend_ops should normally be const
>>
>> so the choice is between a checkpatch warning or a bunch of compiler
>> warnings.
>>
>> Alternatively, I just posted a patch[1] to linux-pm propsing to fix this
>> at the source. Let's see what happens there. Merging $SUBJECT patch
>> will depend on how this is fixed upstream.
>
> Sorry, I should have mentioned this when I posted the patch. I was aware of
> this issue, but I thought this was already fixed in upstream. Check the following
> commit in linux-next:
>
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=2f55ac072f5344519348c0c94b3d2f4cca46847b
>
> (suspend: constify platform_suspend_ops)
ah, thanks. somehow I missed that one when looking to see if this was
already fixed.
Kevin
^ permalink raw reply
* Current OMAP build failures
From: Kevin Hilman @ 2011-01-06 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106110336.GC31708@n2100.arm.linux.org.uk>
Hi Russell,
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> I've observed the following issues while building 2.6.37 + my devel
> branch. I don't believe any of them to be due to anything in my tree,
> so would be in 2.6.37 as well.
What defconfig are you using for these builds?
Kevin
^ permalink raw reply
* Current OMAP build failures
From: Russell King - ARM Linux @ 2011-01-06 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878vyyx8s4.fsf@ti.com>
On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> Hi Russell,
>
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>
> > I've observed the following issues while building 2.6.37 + my devel
> > branch. I don't believe any of them to be due to anything in my tree,
> > so would be in 2.6.37 as well.
>
> What defconfig are you using for these builds?
I couldn't say offhand because they're built from configs created a while
back. I tend to just re-run the build with appropriate O= arguments to
test things.
I can send the defconfigs if it'd help.
^ permalink raw reply
* [PATCH 1/1] mtd: msm_nand: Add initial msm nand driver support.
From: Daniel Walker @ 2011-01-06 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294259965.2179.23.camel@koala>
On Wed, 2011-01-05 at 22:39 +0200, Artem Bityutskiy wrote:
> On Wed, 2011-01-05 at 09:12 -0800, Daniel Walker wrote:
> > On Wed, 2011-01-05 at 10:41 +0200, Artem Bityutskiy wrote:
> > > On Fri, 2010-12-31 at 14:24 +0530, Murali Nalajala wrote:
> > > > From: Arve Hj?nnev?g <arve@android.com>
> > > >
> > > > Add initial msm nand driver support for Qualcomm MSM and QSD platforms.
> > > > This driver is currently capable of handling 2K page nand devices.
> > > >
> > > > This driver is originally
> > > > developed by Google and its source is available at
> > > > http://android.git.kernel.org/?p=kernel/experimental.git
> > > >
> > > > CC: Brian Swetland <swetland@google.com>
> > > > Signed-off-by: Arve Hj?nnev?g <arve@android.com>
> > > > Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>
> > >
> > > Pushed to l2-mtd-2.6.git.
> >
> > This patch had incorrect authorship .. Can you replace it with the
> > second one that was sent ?
>
> Yes, I did that actually, noticed the second one later.
Is it too late for you to drop this ? It's got some additional issues
that we need some time to address ..
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: James Bottomley @ 2011-01-06 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294270104.16957.73.camel@mulgrave.site>
On Wed, 2011-01-05 at 23:28 +0000, James Bottomley wrote:
> Can you explain how the code works? it looks to me like you read the xdr
> stuff through the vmap region then write it out directly to the pages?
OK, I think I see how this is supposed to work: It's a sequential loop
of reading in via the pages (i.e. through the kernel mapping) and then
updating those pages via the vmap. In which case, I think this patch is
what you need.
The theory of operation is that the readdir on pages actually uses the
network DMA operations to perform, so when it's finished, the underlying
page is up to date. After this you invalidate the vmap range, so we
have no cache lines above it (so it picks up the values from the
uptodate page). Finally, after the operation on the vmap region has
finished, you flush it so that any updated contents go back to the pages
themselves before the next iteration begins.
Does this look right to people? I've verified it fixes the issues on
parisc.
James
---
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 996dd89..bde1911 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -587,12 +587,16 @@ int nfs_readdir_xdr_to_array(nfs_readdir_descriptor_t *desc, struct page *page,
if (status < 0)
break;
pglen = status;
+
+ invalidate_kernel_vmap_range(pages_ptr, pglen);
+
status = nfs_readdir_page_filler(desc, &entry, pages_ptr, page, pglen);
if (status < 0) {
if (status == -ENOSPC)
status = 0;
break;
}
+ flush_kernel_vmap_range(pages_ptr, pglen);
} while (array->eof_index < 0);
nfs_readdir_free_large_page(pages_ptr, pages, array_size);
^ permalink raw reply related
* still nfs problems [Was: Linux 2.6.37-rc8]
From: Trond Myklebust @ 2011-01-06 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294335614.22825.154.camel@mulgrave.site>
On Thu, 2011-01-06 at 11:40 -0600, James Bottomley wrote:
> On Wed, 2011-01-05 at 23:28 +0000, James Bottomley wrote:
> > Can you explain how the code works? it looks to me like you read the xdr
> > stuff through the vmap region then write it out directly to the pages?
>
> OK, I think I see how this is supposed to work: It's a sequential loop
> of reading in via the pages (i.e. through the kernel mapping) and then
> updating those pages via the vmap. In which case, I think this patch is
> what you need.
>
> The theory of operation is that the readdir on pages actually uses the
> network DMA operations to perform, so when it's finished, the underlying
> page is up to date. After this you invalidate the vmap range, so we
> have no cache lines above it (so it picks up the values from the
> uptodate page). Finally, after the operation on the vmap region has
> finished, you flush it so that any updated contents go back to the pages
> themselves before the next iteration begins.
>
> Does this look right to people? I've verified it fixes the issues on
> parisc.
>
> James
>
> ---
>
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index 996dd89..bde1911 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -587,12 +587,16 @@ int nfs_readdir_xdr_to_array(nfs_readdir_descriptor_t *desc, struct page *page,
> if (status < 0)
> break;
> pglen = status;
> +
> + invalidate_kernel_vmap_range(pages_ptr, pglen);
> +
> status = nfs_readdir_page_filler(desc, &entry, pages_ptr, page, pglen);
> if (status < 0) {
> if (status == -ENOSPC)
> status = 0;
> break;
> }
> + flush_kernel_vmap_range(pages_ptr, pglen);
Why is this line needed? We're not writing through the virtual mapping.
We checked using just the invalidate_kernel_vmap_range(), and that
appeared to suffice to fix the problem on ARM.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust at netapp.com
www.netapp.com
^ permalink raw reply
* Current OMAP build failures
From: Tony Lindgren @ 2011-01-06 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106171019.GF1198@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [110106 09:09]:
> On Thu, Jan 06, 2011 at 09:05:15AM -0800, Kevin Hilman wrote:
> > Hi Russell,
> >
> > Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> >
> > > I've observed the following issues while building 2.6.37 + my devel
> > > branch. I don't believe any of them to be due to anything in my tree,
> > > so would be in 2.6.37 as well.
> >
> > What defconfig are you using for these builds?
>
> I couldn't say offhand because they're built from configs created a while
> back. I tend to just re-run the build with appropriate O= arguments to
> test things.
>
> I can send the defconfigs if it'd help.
I have the following patch queued up as commit be40f7a3d7b53c1a44e11b376b4a395d6b91f58d
which should fix the compile error you're seeing. This seems to be related
to some option in the .config that's not happening with any of the
defconfigs.
Regards,
Tony
commit be40f7a3d7b53c1a44e11b376b4a395d6b91f58d
Author: Tony Lindgren <tony@atomide.com>
Date: Tue Dec 7 16:25:40 2010 -0800
omap: Fix undefined reference to omap2_i2c_mux_pins
In some cases we can get error function `omap2_i2c_add_bus':
arch/arm/plat-omap/i2c.c:136: undefined reference to `omap2_i2c_mux_pins'
arch/arm/plat-omap/i2c.c:141: undefined reference to `omap_hwmod_lookup'
arch/arm/plat-omap/i2c.c:157: undefined reference to `omap_device_build'
Signed-off-by: Tony Lindgren <tony@atomide.com>
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a6cf4e9..db9c4ef 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -130,6 +130,7 @@ static struct omap_device_pm_latency omap_i2c_latency[] = {
},
};
+#ifdef CONFIG_ARCH_OMAP2PLUS
static inline int omap2_i2c_add_bus(int bus_id)
{
int l;
@@ -166,6 +167,12 @@ static inline int omap2_i2c_add_bus(int bus_id)
return PTR_ERR(od);
}
+#else
+static inline int omap2_i2c_add_bus(int bus_id)
+{
+ return 0;
+}
+#endif
static int __init omap_i2c_add_bus(int bus_id)
{
^ permalink raw reply related
* still nfs problems [Was: Linux 2.6.37-rc8]
From: James Bottomley @ 2011-01-06 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294336054.2905.1.camel@heimdal.trondhjem.org>
On Thu, 2011-01-06 at 12:47 -0500, Trond Myklebust wrote:
> On Thu, 2011-01-06 at 11:40 -0600, James Bottomley wrote:
> > On Wed, 2011-01-05 at 23:28 +0000, James Bottomley wrote:
> > > Can you explain how the code works? it looks to me like you read the xdr
> > > stuff through the vmap region then write it out directly to the pages?
> >
> > OK, I think I see how this is supposed to work: It's a sequential loop
> > of reading in via the pages (i.e. through the kernel mapping) and then
> > updating those pages via the vmap. In which case, I think this patch is
> > what you need.
> >
> > The theory of operation is that the readdir on pages actually uses the
> > network DMA operations to perform, so when it's finished, the underlying
> > page is up to date. After this you invalidate the vmap range, so we
> > have no cache lines above it (so it picks up the values from the
> > uptodate page). Finally, after the operation on the vmap region has
> > finished, you flush it so that any updated contents go back to the pages
> > themselves before the next iteration begins.
> >
> > Does this look right to people? I've verified it fixes the issues on
> > parisc.
> >
> > James
> >
> > ---
> >
> > diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> > index 996dd89..bde1911 100644
> > --- a/fs/nfs/dir.c
> > +++ b/fs/nfs/dir.c
> > @@ -587,12 +587,16 @@ int nfs_readdir_xdr_to_array(nfs_readdir_descriptor_t *desc, struct page *page,
> > if (status < 0)
> > break;
> > pglen = status;
> > +
> > + invalidate_kernel_vmap_range(pages_ptr, pglen);
> > +
> > status = nfs_readdir_page_filler(desc, &entry, pages_ptr, page, pglen);
> > if (status < 0) {
> > if (status == -ENOSPC)
> > status = 0;
> > break;
> > }
> > + flush_kernel_vmap_range(pages_ptr, pglen);
>
> Why is this line needed? We're not writing through the virtual mapping.
If you're not altering it, it isn't ... the problem on parisc is that
invalidate is a nop for us because flush does it all, but I can fix
that.
James
> We checked using just the invalidate_kernel_vmap_range(), and that
> appeared to suffice to fix the problem on ARM.
>
> Cheers
> Trond
^ permalink raw reply
* [PATCH v3 0/2] add CNS3xxx AHCI support
From: mkl0301 at gmail.com @ 2011-01-06 17:53 UTC (permalink / raw)
To: linux-arm-kernel
From: Mac Lin <mkl0301@gmail.com>
v3:
- Make the SoC-specific changes into ahci_platform.c directly.
- Some cosmetic code changes
v2: http://www.spinics.net/lists/linux-ide/msg39766.html
- Switch ahci_platform to module device table matching to add SoC specific support
v1: http://www.spinics.net/lists/arm-kernel/msg106236.html
- Add CNS3xxx SoC specific AHCI support
This patchset is based on linux-2.6.37
Mac Lin (2):
ahci_platform: switch to module device table matching
ahci_platform: add support for CNS3xxx SoC devices
arch/arm/mach-cns3xxx/devices.c | 2 +-
drivers/ata/Kconfig | 11 ++++++++
drivers/ata/ahci_platform.c | 52 ++++++++++++++++++++++++++++++++++++++-
3 files changed, 63 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH v3 1/2] ahci_platform: switch to module device table matching
From: mkl0301 at gmail.com @ 2011-01-06 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294336393-920-1-git-send-email-mkl0301@gmail.com>
From: Mac Lin <mkl0301@gmail.com>
Switch the driver to use module device table matching mechanism to add SoC-specific parts to the generic driver.
Signed-off-by: Mac Lin <mkl0301@gmail.com>
---
drivers/ata/ahci_platform.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 6fef1fa..25d98c8 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -19,6 +19,7 @@
#include <linux/interrupt.h>
#include <linux/device.h>
#include <linux/platform_device.h>
+#include <linux/mod_devicetable.h>
#include <linux/libata.h>
#include <linux/ahci_platform.h>
#include "ahci.h"
@@ -29,6 +30,7 @@ static struct scsi_host_template ahci_platform_sht = {
static int __init ahci_probe(struct platform_device *pdev)
{
+ const struct platform_device_id *platid = platform_get_device_id(pdev);
struct device *dev = &pdev->dev;
struct ahci_platform_data *pdata = dev->platform_data;
struct ata_port_info pi = {
@@ -46,6 +48,9 @@ static int __init ahci_probe(struct platform_device *pdev)
int i;
int rc;
+ if (!pdata && platid && platid->driver_data)
+ pdata = (void *)platid->driver_data;
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(dev, "no mmio space\n");
@@ -171,12 +176,19 @@ static int __devexit ahci_remove(struct platform_device *pdev)
return 0;
}
+static const struct platform_device_id ahci_pltfm_ids[] = {
+ { "ahci", },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, ahci_pltfm_ids);
+
static struct platform_driver ahci_driver = {
.remove = __devexit_p(ahci_remove),
.driver = {
.name = "ahci",
.owner = THIS_MODULE,
},
+ .id_table = ahci_pltfm_ids,
};
static int __init ahci_init(void)
@@ -194,4 +206,3 @@ module_exit(ahci_exit);
MODULE_DESCRIPTION("AHCI SATA platform driver");
MODULE_AUTHOR("Anton Vorontsov <avorontsov@ru.mvista.com>");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:ahci");
--
1.7.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox