On Wed, Nov 28, 2012 at 09:21:07PM -0500, Chao Xie wrote:
> The original sa1100_rtc_open/sa1100_rtc_release will be called
> when the /dev/rtc0 is opened or closed.
> In fact, these two functions will enable/disable the clock, and
> register/unregister the irqs.
> User application will use /dev/rtc
On Wed, Nov 28, 2012 at 09:21:10PM -0500, Chao Xie wrote:
> The original pxa_rtc_open/pxa_rtc_release will be called
> when the /dev/rtc0 is opened or closed.
> In fact, these two functions will register/unregister the irqs.
> User application will use /dev/rtc0 to read the rtc time or set
> the al
On Mon, Oct 22, 2012 at 09:34:51PM -0400, Michael Spang wrote:
> for_each_bank (i, mi) {
> struct membank *bank = &mi->bank[i];
> - unsigned int pfn1, pfn2;
> - struct page *page, *end;
> + unsigned int start, end, pfn;
>
> - pfn
On Thu, Nov 29, 2012 at 02:09:51PM +0100, Marko Katić wrote:
> Well, the commit message was short because i thought it was a quick
> and obvious fix.
Don't always expect the person who ends up applying your patch to know
what your patch is doing. Don't expect people who are looking back
through t
On Thu, Nov 29, 2012 at 02:24:25PM +, Arnd Bergmann wrote:
> Hi Linus,
>
> These should be the last bug fixes you get from Olof and me for 3.7.
> This is based on the previous one you pulled and there is nothing
> spectacular in here. I'll follow up with a second pull request
> knowing that th
On Sun, Mar 17, 2013 at 09:33:21PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Sun, Mar 17, 2013 at 10:00:08PM +0800, Dongsheng Song wrote:
> > “make ARCH=arm menuconfig” no complains, but "make ARCH=arm
> > CROSS_COMPILE=arm-linux-gnueabihf-" failed:
> >
> > $ make ARCH=arm CROSS_COMPILE=arm-linux
On Sun, Mar 17, 2013 at 08:05:43PM +, Will Deacon wrote:
> On Sat, Mar 16, 2013 at 03:32:43AM +, chpoph wrote:
> > On Sat, Mar 16, 2013 at 2:14 AM, Russell King - ARM Linux
> > wrote:
> > > We don't support different CPUs running at different frequencies with
On Mon, Mar 18, 2013 at 10:40:56PM +0800, chpoph wrote:
> On Sun, Mar 17, 2013 at 08:05:43PM +, Will Deacon wrote:
> >Do you actually have an ARM platform that can scale the CPU frequencies
> independently?
>
> Yes, my smart phone use Qualcomm's 8x25 and 8064 platform, which can
> scale the
On Mon, Mar 18, 2013 at 01:15:51PM -0700, Mike Turquette wrote:
> Quoting Ulf Hansson (2013-02-28 01:54:34)
> > On 28 February 2013 05:49, Mike Turquette wrote:
> > > @@ -703,10 +744,29 @@ int clk_enable(struct clk *clk)
> > > unsigned long flags;
> > > int ret;
> > >
> > > +
On Sat, Feb 02, 2013 at 08:27:42PM +0400, Sergei Shtylyov wrote:
>> There are two people on this thread CC list who were also involved or
>> CC'd on the mails from the thread in 2010... Tony and Felipe.
>> Unfortunately, the person who agreed to do the work is no longer in the
>> land of the livin
On Mon, Feb 04, 2013 at 03:02:49AM +0100, Markus F.X.J. Oberhumer wrote:
> At least akpm did approve the LZO update for inclusion into 3.7, but the code
> still has not been merged into the main tree.
> > On 2012-10-09 21:26, Andrew Morton wrote:
> > [...]
> > The changes look OK to me. Plea
On Mon, Feb 04, 2013 at 05:41:53PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Fri, Feb 01, 2013 at 09:30:03PM +, Russell King - ARM Linux wrote:
> > > > > I guess to make the MUSB side simpler we would need musb-dma-engine
> > > > > glue
> > > &g
On Mon, Feb 04, 2013 at 06:47:12PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
> >In my eyes, getting rid of the mess doesn't justify breaking the rules
> > that
> > Russell formulated above.
>
> MUSB is no PCI, there is no single, st
On Tue, Feb 05, 2013 at 11:22:52AM +0100, Hiroshi Doyu wrote:
> diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c
> index f30fb4b..8f88805 100644
> --- a/drivers/clk/clk-composite.c
> +++ b/drivers/clk/clk-composite.c
> @@ -27,6 +27,9 @@ static u8 clk_composite_get_parent(struc
On Tue, Feb 05, 2013 at 06:36:34AM +, Vishwanathrao Badarkhe, Manish wrote:
> I made following changes, in order to update "dip->p" pointer with
> correct value:
>
> - if (!dpi->p) {
> + if (IS_ERR_OR_NULL(dpi->p)) {
> dpi->p = devm_pinctrl_get(dev);
> -
On Mon, Feb 04, 2013 at 09:47:38PM +, Arnd Bergmann wrote:
> On Monday 04 February 2013, Linus Walleij wrote:
> > So I think the above concerns are moot. The callback we can
> > set on cookies is entirely optional, and it's even implemented by
> > each DMA engine, and some may not even support
On Mon, Feb 04, 2013 at 04:54:45PM -0500, Cyril Chemparathy wrote:
> You're assuming that cookies complete in order. That is not necessarily
> true.
Under what circumstances is that not true?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, Feb 05, 2013 at 04:47:05PM +, Mark Brown wrote:
> On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote:
>
> > For IRQ mode, use the completion callback to push each cookie
> > to NAPI, and thus let the IRQ drive the traffic.
>
> The whole purpose of NAPI is to avoid taking in
On Tue, Feb 05, 2013 at 04:30:45PM +0100, Linus Walleij wrote:
> On Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy wrote:
> > On 02/04/2013 04:11 PM, Linus Walleij wrote:
>
> >> Cyril, just stack up the cookies and take a sweep over them to see
> >> which ones are baked when the NAPI poll comes
On Wed, Feb 06, 2013 at 11:28:11AM +0530, Kishon Vijay Abraham I wrote:
> Added has_mailbox to the musb platform data to specify that omap uses
> an external mailbox (in control module) to communicate with the musb
> core during device connect and disconnect.
So, I've been through your five patche
On Wed, Feb 06, 2013 at 01:22:31PM +0200, Felipe Balbi wrote:
> there's a little more to it. When running allmodconfig,
> CONFIG_ARCH_MULTIPLATFORM is set but none of the other ARCHes
> (ARCH_OMAP, ARCH_AT91, ARCH_VERSATILE, etc) are set, so it turned out
> that the driver wasn't even included on m
On Tue, Feb 05, 2013 at 09:41:48PM +0100, Thierry Reding wrote:
> On Wed, Jan 09, 2013 at 09:43:06PM +0100, Thierry Reding wrote:
> > When using deferred driver probing, PCI host controller drivers may
> > actually require this function after the init stage.
> >
> > Signed-off-by: Thierry Reding
On Wed, Feb 06, 2013 at 10:33:53AM +0100, Linus Walleij wrote:
> On Wed, Feb 6, 2013 at 6:21 AM, Joonsoo Kim wrote:
>
> > If we want load epoch_cyc and epoch_ns atomically,
> > we should update epoch_cyc_copy first of all.
> > This notify reader that updating is in progress.
>
> If you think the
On Wed, Feb 06, 2013 at 11:43:10PM +0100, André Hentschel wrote:
> There are more and more applications coming to WinRT, Wine could support them,
> but mostly they expect to have the thread environment block (TEB) in TPIDRURW.
> This register must be preserved per thread instead of being cleared.
On Wed, Feb 06, 2013 at 07:19:05PM -0600, Kim Phillips wrote:
> either that, or link with libgcc - why does arch/arm64 do this and
> arch/arm not? It's not obvious from git log.
We want to be in control of what code the kernel runs, and that means
not using libgcc. libgcc can do all sorts of stu
On Fri, Feb 08, 2013 at 03:51:25PM +0900, Joonsoo Kim wrote:
> I try to put it into patch tracker, but I fail to put it.
> I use following command.
>
> git send-email --to patc...@arm.linux.org.uk 0001-ARM-sched-correct~
>
> Am I wrong?
> Could you teach me how to put patch into your patch tr
On Thu, Feb 07, 2013 at 06:19:35PM -0800, H. Peter Anvin wrote:
> On 02/07/2013 03:45 PM, kbuild test robot wrote:
> > tree: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/mm
> > head: 6fcddf474ae1c8e2fb5f14c850c8aa018e7a5034
> > commit: 6fcddf474ae1c8e2fb5f14c850c8aa018e7a5034 x
On Thu, Feb 07, 2013 at 11:41:34AM +0530, Srivatsa S. Bhat wrote:
> On 02/07/2013 09:44 AM, Rusty Russell wrote:
> > "Srivatsa S. Bhat" writes:
> >> On 01/22/2013 01:03 PM, Srivatsa S. Bhat wrote:
> >> Avg. latency of 1 CPU offline (ms) [stop-cpu/stop-m/c
> >> latency]
> >>
> >>
On Fri, Feb 08, 2013 at 08:50:57PM +0200, Ville Syrjälä wrote:
> struct {
> uint8_t sika1;
> uint16_t sika2;
> uint32_t sika4;
> uint64_t sika8;
Note - you also need to check what the behaviour is with a pointer type
too - that's the on
On Thu, Feb 07, 2013 at 06:06:57PM +0530, Philip Avinash wrote:
> +static int elm_suspend(struct device *dev)
> +{
> + struct elm_info *info = dev_get_drvdata(dev);
> + wait_queue_head_t wq;
> + DECLARE_WAITQUEUE(wait, current);
> +
> + init_waitqueue_head(&wq);
> + while (1) {
On Sat, Feb 09, 2013 at 11:41:42AM +0100, Borislav Petkov wrote:
> On Fri, Feb 08, 2013 at 11:08:52AM -0800, H. Peter Anvin wrote:
> > Yes, or anything else getting a pointer in memory from user space.
>
> Here are some more from a 32-bit build here:
>
> fs/exec.c: In function ‘get_user_arg_ptr’:
On Sat, Feb 09, 2013 at 09:35:53PM +0530, Sekhar Nori wrote:
> On 2/1/2013 11:52 PM, Matt Porter wrote:
> > + ret = of_address_to_resource(node, 1, &res);
>
> of_address_to_resource() needs
>
> > + if (IS_ERR_VALUE(ret))
>
> This needs
More importantly, is this the correct way to check fo
On Mon, Feb 11, 2013 at 02:53:47PM +0100, Linus Walleij wrote:
> NB: among the error codes people want to propagate from
> consumer interfaces such as say, clk_get(), regulator_get()
> and pinctrl_get() is -EPROBE_DEFER. So just "something
> failed" (return NULL) isn't enough.
>
> We then obviousl
On Mon, Feb 11, 2013 at 04:02:30PM +, Catalin Marinas wrote:
> On Sun, Feb 10, 2013 at 05:58:13AM +, Len Brown wrote:
> > pm_idle() on ARM was a synonym for default_idle(),
> > so simply invoke default_idle() directly.
>
> The clean-up looks fine as we already have an arm_pm_idle but longe
On Tue, Feb 12, 2013 at 09:32:54AM -0800, Linus Torvalds wrote:
> On Tue, Feb 12, 2013 at 9:14 AM, H. Peter Anvin wrote:
> >
> > No, I think what he is talking about it this bit:
>
> Ok, I agree that the bitfield code actually looks cleaner.
>
> That said, maybe gcc has an easier time using a fe
On Tue, Feb 12, 2013 at 03:06:51PM -0800, Linus Torvalds wrote:
> So this looks clean, but I noticed something (that was true even of
> the old 64-bit accesses)
>
> On Tue, Feb 12, 2013 at 12:55 PM, tip-bot for H. Peter Anvin
> wrote:
> > + register __inttype(*(ptr)) __val_gu asm("%edx");
On Tue, Mar 12, 2013 at 10:56:38AM +, Russell King - ARM Linux wrote:
> On Tue, Mar 12, 2013 at 10:32:21AM +0800, Ming Lei wrote:
> > On Thu, Mar 7, 2013 at 9:35 PM, Ming Lei wrote:
> > > Commit 14318efb(ARM: 7587/1: implement optimized percpu variable access)
>
On Tue, Jan 29, 2013 at 12:13:46PM +0530, Santosh Shilimkar wrote:
> To avoid the server latency, we didn't do continuous sync. The time was
> synced in the beginning and after 62.5 hours (#ntpd -qg) and the drift
> of about 174 ms was observed. As you said this could be because of
> server sync
On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote:
> 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?
>
> It's a
On Tue, Jan 29, 2013 at 12:43:20PM +0100, Egon Alter wrote:
> Am Dienstag, 29. Januar 2013, 10:15:49 schrieb Russell King - ARM Linux:
> > On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote:
> > > What's this "with enabled unaligned memory access" th
On Mon, Jan 28, 2013 at 07:30:33PM -0600, Kim Phillips wrote:
> AFAICT, arm gcc got __builtin_bswap{32,64} support in 4.6,
> and for the 16-bit version in 4.8.
Hmm.
$ /usr/local/aeabi/bin/arm-linux-gcc --version
arm-linux-gcc (GCC) 4.5.4
Copyright (C) 2010 Free Software Foundation, Inc.
This is f
On Tue, Jan 29, 2013 at 10:34:53AM -0500, Alan Stern wrote:
> On Mon, 28 Jan 2013, Russell King - ARM Linux wrote:
>
> > On Mon, Jan 28, 2013 at 10:17:33AM -0500, Alan Stern wrote:
> > > On Mon, 28 Jan 2013, Roger Quadros wrote:
> > >
> > > > Make use
On Tue, Jan 29, 2013 at 05:54:24PM +0200, Ruslan Bilovol wrote:
> CPU implementer : 0x41
> CPU name: OMAP4470 ES1.0 HS
Sigh. No. Look at what you're doing - look carefully at the above.
"CPU implementer" - 0x41. That's A. For ARM Ltd. ARM Ltd implemented
this CPU. Did ARM Ltd really
On Wed, Jan 30, 2013 at 09:21:28AM +0100, walter harms wrote:
> Great hit Joe :)
>
> Sometimes i am really surprised what code can be found
> in the kernal and it is still working.
> Having no clue of the code i suspect somebody tries to
> check is mask outside the range it should read
> PHYS_OFFS
On Wed, Jan 30, 2013 at 12:21:21PM +0100, Julia Lawall wrote:
>
>
> On Wed, 30 Jan 2013, Russell King - ARM Linux wrote:
>
> > On Wed, Jan 30, 2013 at 09:21:28AM +0100, walter harms wrote:
> > > Great hit Joe :)
> > >
> > > Sometimes i am really
On Wed, Jan 30, 2013 at 05:01:31PM +0200, Ruslan Bilovol wrote:
> Set up the SoC model name during OMAP ID initialisation
> so it will be displayed in /proc/cpuinfo:
>
> / # cat proc/cpuinfo
> [...]
> CPU variant : 0x2
> CPU part: 0xc09
> CPU revision: 10
>
> SoC name: OMA
On Wed, Jan 30, 2013 at 08:53:29AM -0800, Joe Perches wrote:
> On Wed, 2013-01-30 at 11:35 +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 30, 2013 at 12:21:21PM +0100, Julia Lawall wrote:
> > > On Wed, 30 Jan 2013, Russell King - ARM Linux wrote:
> > > > So, _
On Wed, Jan 30, 2013 at 02:07:53PM -0500, Nicolas Pitre wrote:
> On Wed, 30 Jan 2013, Ruslan Bilovol wrote:
>
> > Currently, reading /proc/cpuinfo provides userspace with CPU ID of
> > the CPU carrying out the read from the file.
> > Userspace using this information may decide what module
> > to l
On Wed, Jan 30, 2013 at 08:09:00PM -0600, Kim Phillips wrote:
> The savings come mostly from device-tree related code, and some
> from drivers.
You forget that IP networking is all big endian, so these will be using
the byte swapping too (search it for htons/ntohs/htonl/ntohl).
> v2:
> - at91 and
On Thu, Jan 31, 2013 at 02:59:47PM -0600, Kim Phillips wrote:
> On Thu, 31 Jan 2013 09:28:01 +
> Russell King - ARM Linux wrote:
>
> > On Wed, Jan 30, 2013 at 08:09:00PM -0600, Kim Phillips wrote:
> > > v2:
> > > - at91 and lpd270 builds fixed by limitin
On Thu, Jan 31, 2013 at 06:37:47PM -0600, Kim Phillips wrote:
> +#if GCC_VERSION >= 40600
> +#define __HAVE_BUILTIN_BSWAP32__
> +#define __HAVE_BUILTIN_BSWAP64__
You really aren't listening to anything that's been said to you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
On Mon, Jan 28, 2013 at 10:00:08AM +0900, Minchan Kim wrote:
> @@ -663,7 +661,7 @@ static inline void __zs_unmap_object(struct mapping_area
> *area,
>
> flush_cache_vunmap(addr, end);
> unmap_kernel_range_noflush(addr, PAGE_SIZE * 2);
> - local_flush_tlb_kernel_range(addr, end);
On Fri, Feb 01, 2013 at 10:10:37AM -0500, Cyril Chemparathy wrote:
> With this, I ran simple network and filesystem performance tests to
> compare the code-patching vs. non-code-patching variants. These tests
> didn't yield any significant performance difference between the two on
> an ARMv7
On Fri, Feb 01, 2013 at 10:56:00PM +0200, Felipe Balbi wrote:
> hi,
>
> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
> > > good point, do you wanna send some patches ?
> >
> >I have already sent them countless times and even stuck CPPI 4.1 support
> > (in
> > arch/arm/com
On Sat, Feb 02, 2013 at 04:07:59AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 02-02-2013 1:30, Russell King - ARM Linux wrote:
>
>>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
>>>>> good point, do you wanna send some patches ?
>
>
On Sat, Feb 02, 2013 at 06:09:24AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 02-02-2013 4:44, Russell King - ARM Linux wrote:
>
>>>>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
>>>>>>> good point, do you wanna send some
On Sat, Feb 02, 2013 at 10:18:51AM +, Russell King - ARM Linux wrote:
> On Sat, Feb 02, 2013 at 06:09:24AM +0400, Sergei Shtylyov wrote:
> > Hello.
> >
> > On 02-02-2013 4:44, Russell King - ARM Linux wrote:
> >
> >>>>> On Fri, Feb 01, 20
On Fri, Feb 01, 2013 at 01:59:59PM -0500, Matt Porter wrote:
> On Fri, Feb 01, 2013 at 07:52:46PM +, Sergei Shtylyov wrote:
> > Hello.
> >
> > On 02/01/2013 09:49 PM, Matt Porter wrote:
> >
> > >>> Move mach-davinci/dma.c to common/edma.c so it can be used
> > >>> by OMAP (specifically AM33xx
On Fri, Feb 01, 2013 at 10:41:08AM -0800, Tony Lindgren wrote:
> * Matt Porter [130201 10:25]:
> > Move mach-davinci/dma.c to common/edma.c so it can be used
> > by OMAP (specifically AM33xx) as well.
>
> I think this should rather go to drivers/dma/?
Yes, it should, but just like OMAP, there's
On Thu, Jan 24, 2013 at 10:01:26PM -0500, Steven Rostedt wrote:
> I've recently started testing my work on arm boards and have found that
> they both don't boot under the latest kernel anymore. I already posted
> about my snowball board, but my panda board also locks up.
You need to enable DMA eng
On Fri, Jan 25, 2013 at 12:25:07PM -0800, Greg Kroah-Hartman wrote:
> On Wed, Jan 23, 2013 at 02:07:57PM +0900, Chanho Min wrote:
> > On Tue, Jan 22, 2013 at 10:18 PM, Linus Walleij
> > wrote:
> > >> - If poll timer is activated, We use consistent DMA mappings to avoid
> > >> from
> > >> the fr
On Fri, Jan 25, 2013 at 10:03:05PM +0100, Rafael J. Wysocki wrote:
> On Friday, January 25, 2013 01:46:42 PM Mark Langsdorf wrote:
> > From: Rob Herring
> >
> > Move clk setup to twd_local_timer_common_register and rely on
> > twd_timer_rate being 0 to force calibration if there is no clock.
> >
On Sat, Jan 26, 2013 at 05:49:29PM +0800, Mark Brown wrote:
> Oh, ffs. This is a false positive from the compiler - there is no case
> where it can actually do this as we will bail out before the walk if the
> list is empty so we'll always take at least one trip through our
> list_for_each_entry()
On Fri, Jan 25, 2013 at 10:43:59PM +, Arnd Bergmann wrote:
> I will get to those once this series is sorted out.
> Since there are no interdepencies between the patches,
> my preference is to have them applied by the individual
> subsystem maintainers. Anything that has not at
> least made it i
On Sat, Jan 26, 2013 at 06:03:28PM +0800, Mark Brown wrote:
> On Sat, Jan 26, 2013 at 09:59:16AM +0000, Russell King - ARM Linux wrote:
>
> > Why not code the function in a way that avoids the problem altogether?
>
> That'd do the trick too; feel free to submit a pat
On Fri, Jan 25, 2013 at 11:45:25PM +, Arnd Bergmann wrote:
> On Friday 25 January 2013, Myklebust, Trond wrote:
> > > -Original Message-
> > > From: Arnd Bergmann [mailto:a...@arndb.de]
> > > Marking it as __maybe_unused avoids a harmless gcc warning.
> >
> > Alternatively, just declar
On Mon, Jan 28, 2013 at 09:18:55AM +0200, Hiroshi Doyu wrote:
> Hi Russell,
>
> On Tue, 22 Jan 2013 18:04:46 +0100
> Olof Johansson wrote:
>
> > Since Russell had comments on it earlier, I'd like him to give a nod
> > that he's happy with it too.
>
> Is this ok for you?
>
> The original patch
On Mon, Jan 28, 2013 at 10:36:07AM +0100, Florian Vaussard wrote:
> Hello,
>
> Le 28/01/2013 09:45, Peter Ujfalusi a écrit :
>> hi Thierry,
>>
>> On 01/26/2013 06:40 AM, Thierry Reding wrote:
+{
+ return pwm->chip->can_sleep;
+}
+EXPORT_SYMBOL_GPL(pwm_cansleep);
>>>
>>> Would i
On Mon, Jan 28, 2013 at 11:17:48AM +0100, Linus Walleij wrote:
> On Fri, Jan 25, 2013 at 5:59 PM, Gregory CLEMENT
> wrote:
>
> > From: Linus Walleij
> >
> > Using the devm_* managed resources the pca driver can be simplified
> > and cut down on boilerplate code.
> >
> > [gcl: fixed a inccorect r
On Mon, Jan 28, 2013 at 10:17:33AM -0500, Alan Stern wrote:
> On Mon, 28 Jan 2013, Roger Quadros wrote:
>
> > Make use of devm_request_and_ioremap() and correct comment.
>
> Didn't a big patch come through recently converting all usages of
> devm_request_and_ioremap() to another function (I forg
On Sat, Feb 23, 2013 at 01:30:57AM -0500, Brad Parker wrote:
> I then reversed this commit on 3.7.9 and the board booted
> successfully. I'm not sure if this affects other boards of the same
> arch or not, I only have access to a Pronghorn which also requires a
> patch for the board files as they a
On Sun, Feb 24, 2013 at 12:45:11PM +0100, Julia Lawall wrote:
> The function s3c24xx_irq_map in arch/arm/mach-s3c24xx/irq.c contains the
> code:
>
> parent_irq_data = &parent_intc->irqs[irq_data->parent_irq];
> if (!irq_data) {
> pr_err("irq-s3
On Fri, Feb 22, 2013 at 12:08:05AM -0800, Stephen Boyd wrote:
> From: Steve Muckle
>
> The subarchitecture field in the fpsid register is 7 bits wide.
> The topmost bit is used to designate that the subarchitecture
> designer is not ARM. We use this field to determine which VFP
> version is suppo
On Mon, Feb 25, 2013 at 05:25:45PM +, Russell King - ARM Linux wrote:
> On Fri, Feb 22, 2013 at 12:08:05AM -0800, Stephen Boyd wrote:
> > From: Steve Muckle
> >
> > The subarchitecture field in the fpsid register is 7 bits wide.
> > The topmost bit is
On Mon, Feb 25, 2013 at 07:01:11PM -0800, Stephen Boyd wrote:
> On 02/25/13 03:18, Will Deacon wrote:
> > On Fri, Feb 22, 2013 at 11:46:18PM +, Stephen Boyd wrote:
> >> On 2/22/2013 10:27 AM, Will Deacon wrote:
> >>> What value do you have in fpsid? As far as I can tell, the
> >>> subarchitectu
On Tue, Feb 26, 2013 at 10:58:02PM +0100, Peter Korsgaard wrote:
> > "Nicolas" == Nicolas Pitre writes:
>
> Hi,
>
> >> Did you actually *try* the new LZO version and the patch (which is
> attached
> >> once again) as explained in https://lkml.org/lkml/2013/2/3/367 ?
> >>
> >> Because t
On Wed, Feb 27, 2013 at 04:36:47PM +0900, Kyungsik Lee wrote:
> Compiler: Linaro ARM gcc 4.6.2
> 2. ARMv7, 1.7GHz based board
>Kernel: linux 3.7
>Uncompressed Kernel Size: 14MB
> Compressed Size Decompression Speed
> LZO 6.0MB34.1MB/sOld
> ---
On Tue, Feb 26, 2013 at 05:40:34PM -0800, Joe Perches wrote:
> On Tue, 2013-02-26 at 22:10 +0000, Russell King - ARM Linux wrote:
> > So... for a selected kernel version of a particular size, can we please
> > have a comparison between the new LZO code and this LZ4 code, so that
On Wed, Feb 27, 2013 at 11:30:11AM +0530, Santosh Shilimkar wrote:
> P.S: Time and again it proves that making the local timer wakeup
> capable solves the issue.
Slightly different take: it proves that hardware people don't talk to
software people about what they require to make an operating syste
On Tue, Feb 26, 2013 at 05:37:17PM -0800, Stephen Boyd wrote:
> On 02/25/13 12:02, Russell King - ARM Linux wrote:
> >
> > This can of worms is getting bigger. We have more problems with our
> > handling of the different VFP versions, specifically the handling of
&g
On Wed, Feb 27, 2013 at 07:49:12AM -0800, Joe Perches wrote:
> On Wed, 2013-02-27 at 09:56 +0000, Russell King - ARM Linux wrote:
> > On Tue, Feb 26, 2013 at 05:40:34PM -0800, Joe Perches wrote:
> > > On Tue, 2013-02-26 at 22:10 +0000, Russell King - ARM Linux wrote:
> >
On Wed, Feb 27, 2013 at 09:04:48AM -0800, Joe Perches wrote:
> On Wed, 2013-02-27 at 16:31 +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 27, 2013 at 07:49:12AM -0800, Joe Perches wrote:
> > > On Wed, 2013-02-27 at 09:56 +0000, Russell King - ARM Linux wrote:
> >
On Wed, Feb 27, 2013 at 09:39:47AM -0800, Joe Perches wrote:
> On Wed, 2013-02-27 at 12:16 -0500, Nicolas Pitre wrote:
> > On Wed, 27 Feb 2013, Joe Perches wrote:
> > > On Wed, 2013-02-27 at 16:31 +0000, Russell King - ARM Linux wrote:
> > > > On Wed, Feb 27, 2013 at
On Wed, Feb 20, 2013 at 10:24:02PM +0100, Alessandro Rubini wrote:
> This is a PCI driver that registers AMBA devices for the range of
> supported devices. It is currently used by STA2X11, which exports
> AMBA peripherals under PCIe. The original AMBA drivers work with no
> changes or minimal one
On Wed, Feb 20, 2013 at 02:50:17PM -0800, H. Peter Anvin wrote:
> On 02/20/2013 02:45 PM, Alessandro Rubini wrote:
> > [meanwhile I posted V6 with the acked-by of linusw and others, that
> > were missing in V5]
> >
> > rmk:
> >>> I'm happy to take it through my tree if everyone is now happy with t
On Wed, Feb 20, 2013 at 10:54:38AM -0700, Stephen Warren wrote:
> On 02/11/2013 10:30 AM, Hiroshi Doyu wrote:
> > Hiroshi Doyu wrote @ Wed, 06 Feb 2013 21:16:35 +0200
> > (EET):
> >
> >> Hi Russell,
> >>
> >> Stephen Warren wrote @ Wed, 6 Feb 2013 19:51:46
> >> +0100:
> >>
> >>> On 02/06/2013
On Thu, Feb 21, 2013 at 10:53:07PM +0100, Frederic Weisbecker wrote:
> That too should be kcpustat_this_cpu_set(), or kcpustat_this_cpu_add()
> FWIW. But we probably don't need the overhead of atomic_add() that
> does a LOCK.
> atomic_set(var, atomic_read(var) + delta) would be better. All we need
On Tue, Mar 12, 2013 at 09:58:29AM +0200, Silviu-Mihai Popescu wrote:
> This uses PTR_RET instead of IS_ERR and PTR_ERR in order to increase
> readability.
>
> Signed-off-by: Silviu-Mihai Popescu
> ---
> arch/arm/mach-omap2/devices.c |4 ++--
> arch/arm/mach-omap2/fb.c |5 +
> a
On Tue, Mar 12, 2013 at 07:25:28PM +0800, Ming Lei wrote:
> On Tue, Mar 12, 2013 at 6:56 PM, Russell King - ARM Linux
> wrote:
> >>
> >> Looks no one objects the patch, so I has submitted it into Russell's
> >> patch system, and hope it can be pushed to l
On Tue, Mar 12, 2013 at 08:01:07PM +0800, Danny Huang wrote:
> + if (IS_ERR_OR_NULL(soc_dev))
Sigh. NAK. Fur cryin out loud! Use the IS_ERR() version.
And you don't need the following "return;" statement - that's already
implied at the closing brace of a function.
--
To unsubscribe from th
On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote:
> Add the below four notifier events so drivers which are interested in
> knowing the clock status can act accordingly. This is extremely useful
> in some of the DVFS (Dynamic Voltage Frequency Scaling) design.
>
> PRE_CLK_ENABLE
> POST_C
On Tue, Mar 12, 2013 at 04:54:33PM +0100, Uwe Kleine-König wrote:
> +#include
> +#include
linux/io.h
> + unsigned int irqs, i, irq_base;
> +
> + irq_base = irq_alloc_descs(-1, 16, irqs - 16, numa_node_id());
> + if (IS_ERR_VALUE(irq_base)) {
Erm... irq_alloc_descs() returns a negat
On Tue, Mar 12, 2013 at 08:27:02PM +0100, Uwe Kleine-König wrote:
> On Tue, Mar 12, 2013 at 04:01:01PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Mar 12, 2013 at 04:54:33PM +0100, Uwe Kleine-König wrote:
> > > +#include
> > > +#include
> >
> > li
On Tue, Mar 12, 2013 at 09:11:38PM -0700, Andrew Morton wrote:
> Please reread my email. The page at b_frozen_data was allocated with
> GFP_NOFS. Hence it should not need bounce treatment (if arm is
> anything like x86).
>
> And yet it *did* receive bounce treatment. Why?
If I had to guess, it
On Wed, Mar 13, 2013 at 05:48:00PM +0800, Danny Huang wrote:
> + soc_dev = soc_device_register(soc_dev_attr);
> + if (IS_ERR(soc_dev)) {
> + kfree(soc_dev_attr->soc_id);
> + kfree(soc_dev_attr->revision);
> + kfree(soc_dev_attr->family);
> + k
On Thu, Mar 14, 2013 at 12:38:00PM +0800, Chen Gang wrote:
> Hello Maintainers:
>
> are these warnings for head.S OK ?
>
>
> make:
> make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig
> (this time, CONFIG_MMU=y)
>
> warning information:
> arch/arm/boot/compressed/head.S: Assembler messages:
On Tue, Mar 12, 2013 at 06:47:53PM -0700, Bill Huang wrote:
> On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote:
> > On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote:
> > > Add the below four notifier events so drivers which are interested in
>
On Tue, Mar 12, 2013 at 10:42:30PM -0600, Stephen Warren wrote:
> I believe the point Russell is making is not that the idea behind this
> patch is wrong, but simply that the function where you put the hooks is
> wrong. The hooks should at least be in clk_enable/clk_disable and not
Indeed, remembe
On Tue, Mar 12, 2013 at 10:40:04PM -0700, Bill Huang wrote:
> That will be too bad, it looks like we deadlock in the mechanism, we
> cannot change existing drivers behavior (that means some call
> clk_disable/enable directly, some are not), and we cannot hook notifier
> in clk_disable/enable either
On Thu, Mar 14, 2013 at 11:22:47PM -0600, Stephen Warren wrote:
> Is clk_set_rate() only legal to call in non-atomic contexts then? The
> header file doesn't say, although I guess since many other functions
> explicitly say they can't, then by omission it can...
I think when all this was discussed
1 - 100 of 4247 matches
Mail list logo
