Re: [PATCH v3 18/21] vmcore: check if vmcore objects satify mmap()'s page-size boundary requirement

[HATAYAMA Daisuke]

From: Vivek Goyal 
Subject: Re: [PATCH v3 18/21] vmcore: check if vmcore objects satify mmap()'s 
page-size boundary requirement
Date: Thu, 21 Mar 2013 10:49:29 -0400

> On Thu, Mar 21, 2013 at 12:22:59AM -0700, Eric W. Biederman wrote:
>> HATAYAMA Daisuke  writes:
>> 
>> > OK, rigorously, suceess or faliure of the requested free pages
>> > allocation depends on actual memory layout at the 2nd kernel boot. To
>> > increase the possibility of allocating memory, we have no method but
>> > reserve more memory for the 2nd kernel now.
>> 
>> Good enough.   If there are fragmentation issues that cause allocation
>> problems on larger boxes we can use vmalloc and remap_vmalloc_range, but
>> we certainly don't need to start there.
>> 
>> Especialy as for most 8 or 16 core boxes we are talking about a 4KiB or
>> an 8KiBP allocation.  Aka order 0 or order 1.
>> 
> 
> Actually we are already handling the large SGI machines so we need
> to plan for 4096 cpus now while we write these patches.
> 
> vmalloc() and remap_vmalloc_range() sounds reasonable. So that's what
> we should probaly use.
> 
> Alternatively why not allocate everything in 4K pages and use vmcore_list
> to map offset into right addresses and call remap_pfn_range() on these
> addresses.

I have an introductory question about design of vmalloc. My
understanding is that vmalloc allocates *pages* enough to cover a
requested size and returns the first corresponding virtual address.
So, the address returned is inherently always page-size aligned.

It looks like vmalloc does so in the current implementation, but I
don't know older implementations and I cannot make sure this is
guranteed in vmalloc's interface. There's the comment explaing the
interface of vmalloc as below, but it seems to me a little vague in
that it doesn't say clearly what's is returned as an address.

/**
 *  vmalloc  -  allocate virtually contiguous memory
 *  @size:  allocation size
 *  Allocate enough pages to cover @size from the page level
 *  allocator and map them into contiguous kernel virtual space.
 *
 *  For tight control over page level allocator and protection flags
 *  use __vmalloc() instead.
 */
void *vmalloc(unsigned long size)
{
return __vmalloc_node_flags(size, NUMA_NO_NODE,
GFP_KERNEL | __GFP_HIGHMEM);
}
EXPORT_SYMBOL(vmalloc);

BTW, simple test module code also shows they returns page-size aligned
objects, where 1-byte objects are allocated 12-times.

$ dmesg | tail -n 12
[3552817.290982] test: objects[0] = c960c000
[3552817.291197] test: objects[1] = c960e000
[3552817.291379] test: objects[2] = c967d000
[3552817.291566] test: objects[3] = c90010f99000
[3552817.291833] test: objects[4] = c90010f9b000
[3552817.292015] test: objects[5] = c90010f9d000
[3552817.292207] test: objects[6] = c90010f9f000
[3552817.292386] test: objects[7] = c90010fa1000
[3552817.292574] test: objects[8] = c90010fa3000
[3552817.292785] test: objects[9] = c90010fa5000
[3552817.292964] test: objects[10] = c90010fa7000
[3552817.293143] test: objects[11] = c90010fa9000

Thanks.
HATAYAMA, Daisuke

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 linux-next] cpufreq: governors: Calculate iowait time only when necessary

[Stratos Karafotis]

On 03/22/2013 01:54 AM, Rafael J. Wysocki wrote:
> 
> Applied to linux-pm.git/bleeding-edge and will be moved to linux-next if there
> are no build problems in the bleeding-edge branch.
> 
> Thanks,
> Rafael

Hi Rafael,

I just noticed a regression with this patch with the calculation of wall time
in get get_cpu_idle_time that prevents the CPU to increase to max frequency,
when we use ondemand with io_is_busy = 1.

I'm sorry about that, I'm sending a patch to fix it.

Regards,
Stratos 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH linux-pm] cpufreq: governors: Fix calculation of wall time in get_cpu_idle_time

[Stratos Karafotis]

With commit 8755a8ae31ba213db196324011a0da2a85807f25 the wall in
get_cpu_idle_time is not calculated, when we use ondemand with
io_is_busy = 1, preventing the CPU to increase to max frequency.

Properly, calculate wall time when we use io_is_busy.

Signed-off-by: Stratos Karafotis 
---
 drivers/cpufreq/cpufreq_governor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/cpufreq_governor.c 
b/drivers/cpufreq/cpufreq_governor.c
index b49d45d..41e5e56 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -53,7 +53,7 @@ static inline u64 get_cpu_idle_time_jiffy(unsigned int cpu, 
u64 *wall)
 
 u64 get_cpu_idle_time(unsigned int cpu, u64 *wall, int io_busy)
 {
-   u64 idle_time = get_cpu_idle_time_us(cpu, NULL);
+   u64 idle_time = get_cpu_idle_time_us(cpu, io_busy ? wall : NULL);
 
if (idle_time == -1ULL)
return get_cpu_idle_time_jiffy(cpu, wall);
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] memcg: Add memory.pressure_level events

[Anton Vorontsov]

With this patch userland applications that want to maintain the
interactivity/memory allocation cost can use the pressure level
notifications. The levels are defined like this:

The "low" level means that the system is reclaiming memory for new
allocations. Monitoring this reclaiming activity might be useful for
maintaining cache level. Upon notification, the program (typically
"Activity Manager") might analyze vmstat and act in advance (i.e.
prematurely shutdown unimportant services).

The "medium" level means that the system is experiencing medium memory
pressure, the system might be making swap, paging out active file caches,
etc. Upon this event applications may decide to further analyze
vmstat/zoneinfo/memcg or internal memory usage statistics and free any
resources that can be easily reconstructed or re-read from a disk.

The "critical" level means that the system is actively thrashing, it is
about to out of memory (OOM) or even the in-kernel OOM killer is on its
way to trigger. Applications should do whatever they can to help the
system. It might be too late to consult with vmstat or any other
statistics, so it's advisable to take an immediate action.

The events are propagated upward until the event is handled, i.e. the
events are not pass-through. Here is what this means: for example you have
three cgroups: A->B->C. Now you set up an event listener on cgroups A, B
and C, and suppose group C experiences some pressure. In this situation,
only group C will receive the notification, i.e. groups A and B will not
receive it. This is done to avoid excessive "broadcasting" of messages,
which disturbs the system and which is especially bad if we are low on
memory or thrashing. So, organize the cgroups wisely, or propagate the
events manually (or, ask us to implement the pass-through events,
explaining why would you need them.)

Performance wise, the memory pressure notifications feature itself is
lightweight and does not require much of bookkeeping, in contrast to the
rest of memcg features. Unfortunately, as of current memcg implementation,
pages accounting is an inseparable part and cannot be turned off. The good
news is that there are some efforts[1] to improve the situation; plus,
implementing the same, fully API-compatible[2] interface for
CONFIG_MEMCG=n case (e.g. embedded) is also a viable option, so it will
not require any changes on the userland side.

[1] http://permalink.gmane.org/gmane.linux.kernel.cgroups/6291
[2] http://lkml.org/lkml/2013/2/21/454

Signed-off-by: Anton Vorontsov 
Acked-by: Kirill A. Shutemov 
---

Hi all,

Here is a shiny new v3!

In v3:

- No changes in the code, just updated commit message to incorporate the
  answer to Minchan Kim's comment regarding applicability to embedded use
  cases in the light of memcg performance overhead, plus gave some
  references to Glauber Costa's memcg work.

- Rebased onto 3.9.0-rc3-next-20130321.

In v2:

- Addressed Glauber Costa's comments:
  o Use parent_mem_cgroup() instead of own parent function (also suggested
by Kamezawa). This change also affected events distribution logic, so
it became more like memory thresholds notifications, i.e. we deliver
the event to the cgroup where the event originated, not to the parent
cgroup; (This also addreses Kamezawa's remark regarding which cgroup
receives which event.)
  o Register vmpressure cgroup file directly in memcontrol.c.

  - Addressed Greg Thelen's comments:
o Fixed bool/int inconsistency in the code;
o Fixed nr_scanned accounting;
o Don't use cryptic 's', 'r' abbreviations; get rid of confusing
  'window' argument.

- Addressed Kamezawa Hiroyuki's comments:
  o Moved declarations from mm/internal.h into linux/vmpressue.h;
  o Removed Kconfig symbol. Vmpressure is pretty lightweight (especially
comparing to the memcg accounting). If it ever causes any measurable
performance effect, we want to fix it, not paper it over with a
Kconfig option. :-)
  o Removed read operation on pressure_level cgroup file. In apps, we only
use notifications, we don't need the content of the file, so let's
keep things simple for now. Plus this resolves questions like what
should we return there when the system is not reclaiming;
  o Reworded documentation;
  o Improved comments for vmpressure_prio().

Old changelogs/submissions:
  v2: http://lkml.org/lkml/2013/2/18/577
  v1: http://lkml.org/lkml/2013/2/10/140
  mempressure cgroup: http://lkml.org/lkml/2013/1/4/55

 Documentation/cgroups/memory.txt |  61 +-
 include/linux/vmpressure.h   |  47 
 mm/Makefile  |   2 +-
 mm/memcontrol.c  |  28 +
 mm/vmpressure.c  | 252 +++
 mm/vmscan.c  |   8 ++
 6 files changed, 396 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/vmpressure.h
 create mode 100644 mm/vmpressure.c

diff --git a/Documentation/cgroups/memory.txt b/D

Re: [PATCH] KVM: fix powerpc build error for !CONFIG_KVM

[Gleb Natapov]

On Fri, Mar 22, 2013 at 02:35:50PM +1100, Stephen Rothwell wrote:
> Fixes these build error when CONFIG_KVM is not defined:
> 
> In file included from arch/powerpc/include/asm/kvm_ppc.h:33:0,
>  from arch/powerpc/kernel/setup_64.c:67:
> arch/powerpc/include/asm/kvm_book3s.h:65:20: error: field 'pte' has 
> incomplete type
> arch/powerpc/include/asm/kvm_book3s.h:69:18: error: field 'vcpu' has 
> incomplete type
> arch/powerpc/include/asm/kvm_book3s.h:98:34: error: 'HPTEG_HASH_NUM_PTE' 
> undeclared here (not in a function)
> arch/powerpc/include/asm/kvm_book3s.h:99:39: error: 'HPTEG_HASH_NUM_PTE_LONG' 
> undeclared here (not in a function)
> arch/powerpc/include/asm/kvm_book3s.h:100:35: error: 'HPTEG_HASH_NUM_VPTE' 
> undeclared here (not in a function)
> arch/powerpc/include/asm/kvm_book3s.h:101:40: error: 
> 'HPTEG_HASH_NUM_VPTE_LONG' undeclared here (not in a function)
> arch/powerpc/include/asm/kvm_book3s.h:129:4: error: 'struct kvm_run' declared 
> inside parameter list [-Werror]
> arch/powerpc/include/asm/kvm_book3s.h:129:4: error: its scope is only this 
> definition or declaration, which is probably not what you want [-Werror]
> 
> ... and so on ...
> 
> This was introduced by commit f445f11eb2cc265dd47da5b2e864df46cd6e5a82
> "KVM: allow host header to be included even for !CONFIG_KVM"
> 
This will re-introduce the problem that Kevin tried to fix with his
original patch. The problem is that kernel/context_tracking.c includes
linux/kvm_host.h unconditionally and the later includes asm/kvm_host.h
and this breaks on archs without KVM.

I think the correct solution is to not include linux/kvm_host.h in
kernel/context_tracking.c unconditionally. The patch by Kevin is here:
http://lkml.org/lkml/2013/3/21/745

> Cc: Kevin Hilman 
> Cc: Marcelo Tosatti 
> Signed-off-by: Stephen Rothwell 
> ---
>  include/linux/kvm_host.h | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> Kevin, does this still fix the error that commit
> f445f11eb2cc265dd47da5b2e864df46cd6e5a82 was fixing?
> 
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index a942863..90ebec0 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -1,8 +1,6 @@
>  #ifndef __KVM_HOST_H
>  #define __KVM_HOST_H
>  
> -#if IS_ENABLED(CONFIG_KVM)
> -
>  /*
>   * This work is licensed under the terms of the GNU GPL, version 2.  See
>   * the COPYING file in the top-level directory.
> @@ -751,6 +749,7 @@ static inline int kvm_deassign_device(struct kvm *kvm,
>  }
>  #endif /* CONFIG_IOMMU_API */
>  
> +#if IS_ENABLED(CONFIG_KVM)
>  static inline void __guest_enter(void)
>  {
>   /*
> @@ -770,6 +769,10 @@ static inline void __guest_exit(void)
>   vtime_account_system(current);
>   current->flags &= ~PF_VCPU;
>  }
> +#else
> +static inline void __guest_enter(void) { return; }
> +static inline void __guest_exit(void) { return; }
> +#endif /* IS_ENABLED(CONFIG_KVM) */
>  
>  #ifdef CONFIG_CONTEXT_TRACKING
>  extern void guest_enter(void);
> @@ -1057,8 +1060,4 @@ static inline bool 
> kvm_vcpu_eligible_for_directed_yield(struct kvm_vcpu *vcpu)
>  }
>  
>  #endif /* CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT */
> -#else
> -static inline void __guest_enter(void) { return; }
> -static inline void __guest_exit(void) { return; }
> -#endif /* IS_ENABLED(CONFIG_KVM) */
>  #endif
> -- 
> 1.8.1
> 
> -- 
> Cheers,
> Stephen Rothwells...@canb.auug.org.au



--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] mm: speedup in __early_pfn_to_nid

[Ingo Molnar]

* David Rientjes  wrote:

> On Thu, 21 Mar 2013, Ingo Molnar wrote:
> 
> > > Index: linux/mm/page_alloc.c
> > > ===
> > > --- linux.orig/mm/page_alloc.c2013-03-18 10:52:11.510988843 -0500
> > > +++ linux/mm/page_alloc.c 2013-03-18 10:52:14.214931348 -0500
> > > @@ -4161,10 +4161,19 @@ int __meminit __early_pfn_to_nid(unsigne
> > >  {
> > >   unsigned long start_pfn, end_pfn;
> > >   int i, nid;
> > > + static unsigned long last_start_pfn, last_end_pfn;
> > > + static int last_nid;
> > 
> > Please move these globals out of function local scope, to make it more 
> > apparent that they are not on-stack. I only noticed it in the second pass.
> 
> The way they're currently defined places these in meminit.data as 
> appropriate; if they are moved out, please make sure to annotate their 
> definitions with __meminitdata.

I'm fine with having them within the function as well in this special 
case, as long as a heavy /* NOTE: ... */ warning is put before them - 
which explains why these SMP-unsafe globals are safe.

( That warning will also act as a visual delimiter that breaks the 
  normally confusing and misleading 'globals mixed amongst stack 
  variables' pattern. )

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ipc,sem: sysv semaphore scalability

[Mike Galbraith]

On Wed, 2013-03-20 at 15:55 -0400, Rik van Riel wrote: 
> Include lkml in the CC: this time... *sigh*
> ---8<---
> 
> This series makes the sysv semaphore code more scalable,
> by reducing the time the semaphore lock is held, and making
> the locking more scalable for semaphore arrays with multiple
> semaphores.
> 
> The first four patches were written by Davidlohr Buesso, and
> reduce the hold time of the semaphore lock.
> 
> The last three patches change the sysv semaphore code locking
> to be more fine grained, providing a performance boost when
> multiple semaphores in a semaphore array are being manipulated
> simultaneously.
> 
> On a 24 CPU system, performance numbers with the semop-multi
> test with N threads and N semaphores, look like this:
> 
>   vanilla Davidlohr's Davidlohr's +   Davidlohr's +
> threads   patches rwlock patches  v3 patches
> 10610652  726325  1783589 2142206
> 20341570  365699  1520453 1977878
> 30288102  307037  1498167 2037995
> 40290714  305955  1612665 2256484
> 50288620  312890  1733453 2650292
> 60289987  306043  1649360 2388008
> 70291298  306347  1723167 2717486
> 80290948  305662  1729545 2763582
> 90290996  306680  1736021 2757524
> 100   292243  306700  1773700 3059159

Hi Rik,

I plugged this set into enterprise -rt kernel, and beat on four boxen.
I ran into no trouble while giving boxen a generic drubbing fwtw.

Some semop-multi -rt numbers for an abby-normal 8 node box, and a
mundane 4 node box below.


32 cores+SMT, 3.0.68-rt92

numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 32 33 34 35 36 37 38 39
node 0 size: 32733 MB
node 0 free: 29910 MB
node 1 cpus: 8 9 10 11 12 13 14 15 40 41 42 43 44 45 46 47
node 1 size: 32768 MB
node 1 free: 30396 MB
node 2 cpus: 16 17 18 19 20 21 22 23 48 49 50 51 52 53 54 55
node 2 size: 32768 MB
node 2 free: 30568 MB
node 3 cpus: 24 25 26 27 28 29 30 31 56 57 58 59 60 61 62 63
node 3 size: 32767 MB
node 3 free: 28706 MB
node distances:
node   0   1   2   3 
  0:  10  21  21  21 
  1:  21  10  21  21 
  2:  21  21  10  21 
  3:  21  21  21  10 

SCHED_OTHER
   -v3 set+v3 set
threads
10  4384851744599
20  3764111580813
30  3966391546841
40  4490622152861
50  4775942431344
60  4464531874476
70  5787052047884
80  6079282144898
90  6621362171074
100 6228892295879
200 7096682867273
300 6619023008695
400 6417583273250
500 6141173403775

SCHED_FIFO
   -v3 set+v3 set
threads
10 158656  914343
20  99784 1133775
30  84245 1099604
40  89725 1756577
50  85697 1607893
60  84033 1467272
70  86833 1979405
80  91451 1922250
90  92484 1990699
100 90691 2067705
200103692 2308652
300101161 2376921
400103722 2417580
500108838 2443349


64 core box (poor thing, smi free zone though), 3.0.68-rt92

numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 
25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 
51 52 53 54 55 56 57 58 59 60 61 62 63
node 0 size: 8181 MB
node 0 free: 6309 MB
node distances:
node   0
  0:  10

SCHED_OTHER
   -v3 set+v3 set
threads
10  6775342304417
20  4515071873474
30  3568761542688
40  3295851500392
50  4157611318676
60  4034821380644
70  3940891185165
80  4074081191834
90  4457641249156
100 4308231245573
200 4254701421686
300 4270921480379
400 4979001516599
500 4219271551309

SCHED_FIFO
10  3235601882543
20  2262571806862
30  1878511263163
40  205337 881331
50  196806 76
60  193218 612709
70  2094321241797
80  2404451269146
90  2198651482649
100 2279701473038
200 2013541719977
300 1837281823074
400 1750511808792
500 2437081849803


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] serial: of_serial: Handle fifosize property

[Heikki Krogerus]

On Fri, Mar 22, 2013 at 11:32:18AM +0800, Ley Foon Tan wrote:
> On Thu, 2013-03-21 at 15:24 +0200, Heikki Krogerus wrote:
> > On Thu, Mar 21, 2013 at 07:41:39PM +0800, Ley Foon Tan wrote:
> > > Suggest to use "fifo-size" for the device tree property, to align with
> > > other DT properties.
> > 
> > I was going to, but then I noticed that in some .dtsi files "fifosize"
> > is used with uarts. Should I still change it?
> I just make the grep for "fifosize" in arch/. It is used by other serial
> drivers (not of_serial.c). So, you are safe to change it to "fifo-size".

OK, I'll change it.

Thanks!

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] davinci: vpss: clock cleanup

[Prabhakar lad]

From: Lad, Prabhakar 

This patch series cleanup's the VPSS clock enabling.
The first patch removes vpss clock enabling from the capture
drivers and moves it to the VPSS driver itself.
The second patch moves the venc_enable_vpss_clock() to the driver
which was being done in platform code.

Lad, Prabhakar (2):
  media: davinci: vpss: enable vpss clocks
  media: davinci: vpbe: venc: move the enabling of vpss clocks to
driver

 arch/arm/mach-davinci/dm355.c|3 -
 arch/arm/mach-davinci/dm365.c|9 +++-
 arch/arm/mach-davinci/dm644x.c   |5 --
 drivers/media/platform/davinci/dm355_ccdc.c  |   39 +
 drivers/media/platform/davinci/dm644x_ccdc.c |   44 ---
 drivers/media/platform/davinci/isif.c|   28 ++--
 drivers/media/platform/davinci/vpbe_venc.c   |   26 +++
 drivers/media/platform/davinci/vpss.c|   60 ++
 8 files changed, 98 insertions(+), 116 deletions(-)

-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] media: davinci: vpss: enable vpss clocks

[Prabhakar lad]

From: Lad, Prabhakar 

By default the VPSS clocks are only enabled in capture driver
for davinci family which creates duplicates. This
patch adds support to enable the VPSS clocks in VPSS driver.
This avoids duplication of code and also adding clock aliases.
This patch cleanups the VPSS clock enabling in the capture driver,
and also removes the clock alias in machine file. Along side adds
a vpss slave clock for DM365 as mentioned by Sekhar
(https://patchwork.kernel.org/patch/1221261/).

Signed-off-by: Lad, Prabhakar 
---
 arch/arm/mach-davinci/dm355.c|3 -
 arch/arm/mach-davinci/dm365.c|9 +++-
 arch/arm/mach-davinci/dm644x.c   |5 --
 drivers/media/platform/davinci/dm355_ccdc.c  |   39 +
 drivers/media/platform/davinci/dm644x_ccdc.c |   44 ---
 drivers/media/platform/davinci/isif.c|   28 ++--
 drivers/media/platform/davinci/vpss.c|   60 ++
 7 files changed, 72 insertions(+), 116 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index b49c3b7..a917983 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -873,9 +873,6 @@ static int __init dm355_init_devices(void)
if (!cpu_is_davinci_dm355())
return 0;
 
-   /* Add ccdc clock aliases */
-   clk_add_alias("master", dm355_ccdc_dev.name, "vpss_master", NULL);
-   clk_add_alias("slave", dm355_ccdc_dev.name, "vpss_master", NULL);
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(&dm355_edma_device);
platform_device_register(&dm355_vpss_device);
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 6c39805..f4c19f7 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -257,6 +257,12 @@ static struct clk vpss_master_clk = {
.flags  = CLK_PSC,
 };
 
+static struct clk vpss_slave_clk = {
+   .name   = "vpss_slave",
+   .parent = &pll1_sysclk5,
+   .lpsc   = DAVINCI_LPSC_VPSSSLV,
+};
+
 static struct clk arm_clk = {
.name   = "arm_clk",
.parent = &pll2_sysclk2,
@@ -450,6 +456,7 @@ static struct clk_lookup dm365_clks[] = {
CLK(NULL, "pll2_sysclk9", &pll2_sysclk9),
CLK(NULL, "vpss_dac", &vpss_dac_clk),
CLK(NULL, "vpss_master", &vpss_master_clk),
+   CLK(NULL, "vpss_slave", &vpss_slave_clk),
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "uart0", &uart0_clk),
CLK(NULL, "uart1", &uart1_clk),
@@ -1239,8 +1246,6 @@ static int __init dm365_init_devices(void)
clk_add_alias(NULL, dev_name(&dm365_mdio_device.dev),
  NULL, &dm365_emac_device.dev);
 
-   /* Add isif clock alias */
-   clk_add_alias("master", dm365_isif_dev.name, "vpss_master", NULL);
platform_device_register(&dm365_vpss_device);
platform_device_register(&dm365_isif_dev);
platform_device_register(&vpfe_capture_dev);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index ee0e994..026e7e3 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -901,11 +901,6 @@ int __init dm644x_init_video(struct vpfe_config *vpfe_cfg,
dm644x_vpfe_dev.dev.platform_data = vpfe_cfg;
platform_device_register(&dm644x_ccdc_dev);
platform_device_register(&dm644x_vpfe_dev);
-   /* Add ccdc clock aliases */
-   clk_add_alias("master", dm644x_ccdc_dev.name,
- "vpss_master", NULL);
-   clk_add_alias("slave", dm644x_ccdc_dev.name,
- "vpss_slave", NULL);
}
 
if (vpbe_cfg) {
diff --git a/drivers/media/platform/davinci/dm355_ccdc.c 
b/drivers/media/platform/davinci/dm355_ccdc.c
index 2364dba..05f8fb7 100644
--- a/drivers/media/platform/davinci/dm355_ccdc.c
+++ b/drivers/media/platform/davinci/dm355_ccdc.c
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -59,10 +58,6 @@ static struct ccdc_oper_config {
struct ccdc_params_raw bayer;
/* YCbCr configuration */
struct ccdc_params_ycbcr ycbcr;
-   /* Master clock */
-   struct clk *mclk;
-   /* slave clock */
-   struct clk *sclk;
/* ccdc base address */
void __iomem *base_addr;
 } ccdc_cfg = {
@@ -997,32 +992,10 @@ static int dm355_ccdc_probe(struct platform_device *pdev)
goto fail_nomem;
}
 
-   /* Get and enable Master clock */
-   ccdc_cfg.mclk = clk_get(&pdev->dev, "master");
-   if (IS_ERR(ccdc_cfg.mclk)) {
-   status = PTR_ERR(ccdc_cfg.mclk);
-   goto fail_nomap;
-   }
-   if (clk_prepare_enable(ccdc_cfg.mclk)) {
-   status = -ENODEV;
-   goto fail_mclk;
-   }
-
-   /* Get and enable Slave c

[PATCH 2/2] media: davinci: vpbe: venc: move the enabling of vpss clocks to driver

[Prabhakar lad]

From: Lad, Prabhakar 

The vpss clocks were enabled by calling a exported function from a driver
in a machine code. calling driver code from platform code is incorrect way.

This patch fixes this issue and calls the function from driver code itself.

Signed-off-by: Lad, Prabhakar 
---
 Note: This patch is based on the comment from Sekhar
  (https://patchwork-mail1.kernel.org/patch/2278441/).
  Shekar I haven't completely removed the callback, I just added
  the function calls after the callback. As you mentioned just to
  pass the VPSS_CLK_CTRL as a resource to venc but the VPSS_CLK_CTRL
  is already being used by VPSS driver. I'll take this cleanup task later
  point of time.

 drivers/media/platform/davinci/vpbe_venc.c |   26 ++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/drivers/media/platform/davinci/vpbe_venc.c 
b/drivers/media/platform/davinci/vpbe_venc.c
index f15f211..26bdf9b 100644
--- a/drivers/media/platform/davinci/vpbe_venc.c
+++ b/drivers/media/platform/davinci/vpbe_venc.c
@@ -202,6 +202,26 @@ static void venc_enabledigitaloutput(struct v4l2_subdev 
*sd, int benable)
}
 }
 
+static void
+venc_enable_vpss_clock(int venc_type,
+  enum vpbe_enc_timings_type type,
+  unsigned int pclock)
+{
+   if (venc_type == VPBE_VERSION_1)
+   return;
+
+   if (venc_type == VPBE_VERSION_2 && (type == VPBE_ENC_STD ||
+   (type == VPBE_ENC_DV_TIMINGS && pclock <= 2700))) {
+   vpss_enable_clock(VPSS_VENC_CLOCK_SEL, 1);
+   vpss_enable_clock(VPSS_VPBE_CLOCK, 1);
+   return;
+   }
+
+   if (venc_type == VPBE_VERSION_3 && type == VPBE_ENC_STD)
+   vpss_enable_clock(VPSS_VENC_CLOCK_SEL, 0);
+
+}
+
 #define VDAC_CONFIG_SD_V3  0x0E21A6B6
 #define VDAC_CONFIG_SD_V2  0x081141CF
 /*
@@ -220,6 +240,7 @@ static int venc_set_ntsc(struct v4l2_subdev *sd)
if (pdata->setup_clock(VPBE_ENC_STD, V4L2_STD_525_60) < 0)
return -EINVAL;
 
+   venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_STD, V4L2_STD_525_60);
venc_enabledigitaloutput(sd, 0);
 
if (venc->venc_type == VPBE_VERSION_3) {
@@ -265,6 +286,7 @@ static int venc_set_pal(struct v4l2_subdev *sd)
if (venc->pdata->setup_clock(VPBE_ENC_STD, V4L2_STD_625_50) < 0)
return -EINVAL;
 
+   venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_STD, V4L2_STD_625_50);
venc_enabledigitaloutput(sd, 0);
 
if (venc->venc_type == VPBE_VERSION_3) {
@@ -319,6 +341,7 @@ static int venc_set_480p59_94(struct v4l2_subdev *sd)
if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 2700) < 0)
return -EINVAL;
 
+   venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 2700);
venc_enabledigitaloutput(sd, 0);
 
if (venc->venc_type == VPBE_VERSION_2)
@@ -366,6 +389,7 @@ static int venc_set_576p50(struct v4l2_subdev *sd)
if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 2700) < 0)
return -EINVAL;
 
+   venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 2700);
venc_enabledigitaloutput(sd, 0);
 
if (venc->venc_type == VPBE_VERSION_2)
@@ -406,6 +430,7 @@ static int venc_set_720p60_internal(struct v4l2_subdev *sd)
if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 7425) < 0)
return -EINVAL;
 
+   venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 7425);
venc_enabledigitaloutput(sd, 0);
 
venc_write(sd, VENC_OSDCLK0, 0);
@@ -434,6 +459,7 @@ static int venc_set_1080i30_internal(struct v4l2_subdev *sd)
if (pdata->setup_clock(VPBE_ENC_DV_TIMINGS, 7425) < 0)
return -EINVAL;
 
+   venc_enable_vpss_clock(venc->venc_type, VPBE_ENC_DV_TIMINGS, 7425);
venc_enabledigitaloutput(sd, 0);
 
venc_write(sd, VENC_OSDCLK0, 0);
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 02/10] mm: vmscan: Obey proportional scanning requirements for kswapd

[Michal Hocko]

On Thu 21-03-13 15:34:42, Mel Gorman wrote:
> On Thu, Mar 21, 2013 at 04:07:55PM +0100, Michal Hocko wrote:
> > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > > > index 4835a7a..182ff15 100644
> > > > > --- a/mm/vmscan.c
> > > > > +++ b/mm/vmscan.c
> > > > > @@ -1815,6 +1815,45 @@ out:
> > > > >   }
> > > > >  }
> > > > >  
> > > > > +static void recalculate_scan_count(unsigned long nr_reclaimed,
> > > > > + unsigned long nr_to_reclaim,
> > > > > + unsigned long nr[NR_LRU_LISTS])
> > > > > +{
> > > > > + enum lru_list l;
> > > > > +
> > > > > + /*
> > > > > +  * For direct reclaim, reclaim the number of pages requested. 
> > > > > Less
> > > > > +  * care is taken to ensure that scanning for each LRU is 
> > > > > properly
> > > > > +  * proportional. This is unfortunate and is improper aging but
> > > > > +  * minimises the amount of time a process is stalled.
> > > > > +  */
> > > > > + if (!current_is_kswapd()) {
> > > > > + if (nr_reclaimed >= nr_to_reclaim) {
> > > > > + for_each_evictable_lru(l)
> > > > > + nr[l] = 0;
> > > > > + }
> > > > > + return;
> > > > 
> > > > Heh, this is nicely cryptically said what could be done in shrink_lruvec
> > > > as
> > > > if (!current_is_kswapd()) {
> > > > if (nr_reclaimed >= nr_to_reclaim)
> > > > break;
> > > > }
> > > > 
> > > 
> > > Pretty much. At one point during development, this function was more
> > > complex and it evolved into this without me rechecking if splitting it
> > > out still made sense.
> > > 
> > > > Besides that this is not memcg aware which I think it would break
> > > > targeted reclaim which is kind of direct reclaim but it still would be
> > > > good to stay proportional because it starts with DEF_PRIORITY.
> > > > 
> > > 
> > > This does break memcg because it's a special sort of direct reclaim.
> > > 
> > > > I would suggest moving this back to shrink_lruvec and update the test as
> > > > follows:
> > > 
> > > I also noticed that we check whether the scan counts need to be
> > > normalised more than once
> > 
> > I didn't mind this because it "disqualified" at least one LRU every
> > round which sounds reasonable to me because all LRUs would be scanned
> > proportionally.
> 
> Once the scan count for one LRU is 0 then min will always be 0 and no
> further adjustment is made. It's just redundant to check again.

Hmm, I was almost sure I wrote that min should be adjusted only if it is >0
in the first loop but it is not there...

So for real this time.
for_each_evictable_lru(l)
if (nr[l] && nr[l] < min)
min = nr[l];

This should work, no? Everytime you shrink all LRUs you and you have
reclaimed enough already you get the smallest LRU out of game. This
should keep proportions evenly.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gpio: palmas: add in GPIO support for palmas charger

[Linus Walleij]

On Tue, Feb 26, 2013 at 3:14 PM, Laxman Dewangan  wrote:

> On Tuesday 26 February 2013 07:43 PM, Ian Lartey wrote:
> On 26/02/13 13:58, Laxman Dewangan wrote:
>
> On Tuesday 26 February 2013 06:51 PM, Ian Lartey wrote:
>
> this patch depenfs on [PATCH] mfd: palmas: is_palmas_charger needed by
> multiple drivers
>
> Palmas charger has 16 GPIOs
> add palmas_gpio_[read|write|update] api to take account
> second bank of GPIOs
>
> Signed-off-by: Ian Lartey 
> Signed-off-by: Graeme Gregory 

Is something happening in this series?

I'm ignoring it for now since the last activity in the thread was
some concerns from Laxman.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3 linux-next] cpufreq: conservative: Use an inline function to evaluate freq_target

[Stratos Karafotis]

Hi Rafael,

On 03/22/2013 01:51 AM, Rafael J. Wysocki wrote:
> This one didn't apply for me to linux-pm.git/bleeding-edge.  Care to rebase?
> 
> Rafael

Yes, of course. 
Bellow the rebased patched against latest linux-pm.git/bleeding-edge.

Thanks,
Stratos

--8<---
Use an inline function to evaluate freq_target to avoid duplicate code.

Also, define a macro for the default frequency step.

Signed-off-by: Stratos Karafotis 
---
 drivers/cpufreq/cpufreq_conservative.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_conservative.c 
b/drivers/cpufreq/cpufreq_conservative.c
index fe17bd3..63499c8 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -29,11 +29,24 @@
 /* Conservative governor macros */
 #define DEF_FREQUENCY_UP_THRESHOLD (80)
 #define DEF_FREQUENCY_DOWN_THRESHOLD   (20)
+#define DEF_FREQUENCY_STEP (5)
 #define DEF_SAMPLING_DOWN_FACTOR   (1)
 #define MAX_SAMPLING_DOWN_FACTOR   (10)
 
 static DEFINE_PER_CPU(struct cs_cpu_dbs_info_s, cs_cpu_dbs_info);
 
+static inline unsigned int get_freq_target(struct cs_dbs_tuners *cs_tuners,
+  struct cpufreq_policy *policy)
+{
+   unsigned int freq_target = (cs_tuners->freq_step * policy->max) / 100;
+
+   /* max freq cannot be less than 100. But who knows... */
+   if (unlikely(freq_target == 0))
+   freq_target = DEF_FREQUENCY_STEP;
+
+   return freq_target;
+}
+
 /*
  * Every sampling_rate, we check, if current idle time is less than 20%
  * (default), then we try to increase frequency. Every sampling_rate *
@@ -49,7 +62,6 @@ static void cs_check_cpu(int cpu, unsigned int load)
struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
struct dbs_data *dbs_data = policy->governor_data;
struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
-   unsigned int freq_target;
 
/*
 * break out if we 'cannot' reduce the speed as the user might
@@ -66,13 +78,7 @@ static void cs_check_cpu(int cpu, unsigned int load)
if (dbs_info->requested_freq == policy->max)
return;
 
-   freq_target = (cs_tuners->freq_step * policy->max) / 100;
-
-   /* max freq cannot be less than 100. But who knows */
-   if (unlikely(freq_target == 0))
-   freq_target = 5;
-
-   dbs_info->requested_freq += freq_target;
+   dbs_info->requested_freq += get_freq_target(cs_tuners, policy);
if (dbs_info->requested_freq > policy->max)
dbs_info->requested_freq = policy->max;
 
@@ -94,9 +100,7 @@ static void cs_check_cpu(int cpu, unsigned int load)
if (policy->cur == policy->min)
return;
 
-   freq_target = (cs_tuners->freq_step * policy->max) / 100;
-
-   dbs_info->requested_freq -= freq_target;
+   dbs_info->requested_freq -= get_freq_target(cs_tuners, policy);
if (dbs_info->requested_freq < policy->min)
dbs_info->requested_freq = policy->min;
 
@@ -323,7 +327,7 @@ static int cs_init(struct dbs_data *dbs_data)
tuners->down_threshold = DEF_FREQUENCY_DOWN_THRESHOLD;
tuners->sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR;
tuners->ignore_nice = 0;
-   tuners->freq_step = 5;
+   tuners->freq_step = DEF_FREQUENCY_STEP;
 
dbs_data->tuners = tuners;
dbs_data->min_sampling_rate = MIN_SAMPLING_RATE_RATIO *
-- 
1.8.1.4


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 0/2] ARM: davinci: add support for dm365 vpbe display

[Prabhakar lad]

From: Lad, Prabhakar 


This patch series enables VPBE display driver on DM365.

This patch is work on on following pull request from Hans
http://davinci-linux-open-source.1494791.n2.nabble.com/GIT-PULL-FOR-v3-10-tvp7002-davinci-blackfin-legacy-cleanups-td7582451.html
+ 
http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg25499.html
 (from me)
+ 
http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2013-March/026639.html
 (from me)


Changes for v7:
1: Fixed nits pointed by Sekhar.

Changes for v6:
1: Fixed review comments pointed by Sekhar.

Changes for v5:
1: pass different platform names to handle different ip's.
2: Fixed review comments pointed by Sekhar.

Changes for v4:
1: Replaced the obsolete preset API by timings API.

Changes for v3:
1: Removed VPSS clock alias for master and slave which was
   sent for VPSS driver. since this patch was dependent on
   patch[1]. I will revist this patch once MC(captrure driver)
   goes into mainline.
[1] http://www.spinics.net/lists/linux-media/msg50562.html

Changes for v2:
1: Added VPSS clock so that capture and display
   can work independent.


Lad, Prabhakar (2):
  ARM: davinci: dm365: add support for v4l2 video display
  ARM: davinci: dm365 EVM: add support for VPBE display

 arch/arm/mach-davinci/board-dm365-evm.c |  166 ++-
 arch/arm/mach-davinci/davinci.h |2 +-
 arch/arm/mach-davinci/dm365.c   |  194 +--
 3 files changed, 350 insertions(+), 12 deletions(-)

-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 1/2] ARM: davinci: dm365: add support for v4l2 video display

[Prabhakar lad]

From: Lad, Prabhakar 

Create platform devices for various video modules like venc,osd,
vpbe and v4l2 driver for dm365.

Signed-off-by: Lad, Prabhakar 
---
 arch/arm/mach-davinci/board-dm365-evm.c |4 +-
 arch/arm/mach-davinci/davinci.h |2 +-
 arch/arm/mach-davinci/dm365.c   |  194 +--
 3 files changed, 188 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index c2d4958..cf77c46 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -564,8 +564,6 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm365_evm_map_io(void)
 {
-   /* setup input configuration for VPFE input devices */
-   dm365_set_vpfe_config(&vpfe_cfg);
dm365_init();
 }
 
@@ -597,6 +595,8 @@ static __init void dm365_evm_init(void)
 
davinci_setup_mmc(0, &dm365evm_mmc_config);
 
+   dm365_init_video(&vpfe_cfg, NULL);
+
/* maybe setup mmc1/etc ... _after_ mmc0 */
evm_init_cpld();
 
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..1c2670f 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -84,7 +84,7 @@ void __init dm365_init_ks(struct davinci_ks_platform_data 
*pdata);
 void __init dm365_init_rtc(void);
 void dm365_init_spi0(unsigned chipselect_mask,
const struct spi_board_info *info, unsigned len);
-void dm365_set_vpfe_config(struct vpfe_config *cfg);
+int __init dm365_init_video(struct vpfe_config *, struct vpbe_config *);
 
 /* DM644x function declarations */
 void __init dm644x_init(void);
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f4c19f7..0a2dba2 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -40,10 +40,16 @@
 
 #define DM365_REF_FREQ 2400/* 24 MHz on the DM365 EVM */
 
+#define DM365_VDAC_CONFIG  0x01c4002c
+
+#define DM365_RTC_BASE 0x01c69000
+
 /* Base of key scan register bank */
 #define DM365_KEYSCAN_BASE 0x01c69400
 
-#define DM365_RTC_BASE 0x01c69000
+#define DM365_OSD_BASE 0x01c71c00
+
+#define DM365_VENC_BASE0x01c71e00
 
 #define DAVINCI_DM365_VC_BASE  0x01d0c000
 #define DAVINCI_DMA_VC_TX  2
@@ -56,6 +62,11 @@
 #define DM365_EMAC_CNTRL_RAM_OFFSET0x1000
 #define DM365_EMAC_CNTRL_RAM_SIZE  0x2000
 
+#define DM365_VPSS_CLK_CTRL_ADDR   0x44
+#define DM365_VPSS_VENCCLKEN_ENABLEBIT(3)
+#define DM365_VPSS_DACCLKEN_ENABLE BIT(4)
+#define DM365_VPSS_PLLC2SYSCLK5_ENABLE BIT(5)
+
 static struct pll_data pll1_data = {
.num= 1,
.phys_base  = DAVINCI_PLL1_BASE,
@@ -1233,6 +1244,179 @@ static struct platform_device dm365_isif_dev = {
},
 };
 
+static struct resource dm365_osd_resources[] = {
+   {
+   .start = DM365_OSD_BASE,
+   .end   = DM365_OSD_BASE + 0x100,
+   .flags = IORESOURCE_MEM,
+   },
+};
+
+static u64 dm365_video_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm365_osd_dev = {
+   .name   = DM365_VPBE_OSD_SUBDEV_NAME,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm365_osd_resources),
+   .resource   = dm365_osd_resources,
+   .dev= {
+   .dma_mask   = &dm365_video_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   },
+};
+
+static struct resource dm365_venc_resources[] = {
+   {
+   .start = IRQ_VENCINT,
+   .end   = IRQ_VENCINT,
+   .flags = IORESOURCE_IRQ,
+   },
+   /* venc registers io space */
+   {
+   .start = DM365_VENC_BASE,
+   .end   = DM365_VENC_BASE + 0x180,
+   .flags = IORESOURCE_MEM,
+   },
+   /* vdaccfg registers io space */
+   {
+   .start = DM365_VDAC_CONFIG,
+   .end   = DM365_VDAC_CONFIG + 3,
+   .flags = IORESOURCE_MEM,
+   },
+};
+
+static struct resource dm365_v4l2_disp_resources[] = {
+   {
+   .start = IRQ_VENCINT,
+   .end   = IRQ_VENCINT,
+   .flags = IORESOURCE_IRQ,
+   },
+   /* venc registers io space */
+   {
+   .start = DM365_VENC_BASE,
+   .end   = DM365_VENC_BASE + 0x180,
+   .flags = IORESOURCE_MEM,
+   },
+};
+
+static int dm365_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
+   int field)
+{
+   switch (if_type) {
+   case V4L2_MBUS_FMT_SGRBG8_1X8:
+   davinci_cfg_reg(DM365_VOUT_FIELD_G81);
+   davinci_cfg_reg(DM365_VOUT_COUTL_EN);
+   davinci_cfg_reg(DM365_VOUT_COUTH_EN);
+   

[PATCH v7 2/2] ARM: davinci: dm365 EVM: add support for VPBE display

[Prabhakar lad]

From: Lad, Prabhakar 

add support for V4L2 video display to DM365 EVM.
Support for SD and ED modes is provided, along with Composite
and Component outputs.

Signed-off-by: Lad, Prabhakar 
---
 arch/arm/mach-davinci/board-dm365-evm.c |  164 ++-
 1 files changed, 163 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index cf77c46..0518ce5 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -39,6 +40,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include "davinci.h"
@@ -374,6 +376,166 @@ static struct vpfe_config vpfe_cfg = {
.ccdc = "ISIF",
 };
 
+/* venc standards timings */
+static struct vpbe_enc_mode_info dm365evm_enc_std_timing[] = {
+   {
+   .name   = "ntsc",
+   .timings_type   = VPBE_ENC_STD,
+   .std_id = V4L2_STD_525_60,
+   .interlaced = 1,
+   .xres   = 720,
+   .yres   = 480,
+   .aspect = {11, 10},
+   .fps= {3, 1001},
+   .left_margin= 0x79,
+   .upper_margin   = 0x10,
+   },
+   {
+   .name   = "pal",
+   .timings_type   = VPBE_ENC_STD,
+   .std_id = V4L2_STD_625_50,
+   .interlaced = 1,
+   .xres   = 720,
+   .yres   = 576,
+   .aspect = {54, 59},
+   .fps= {25, 1},
+   .left_margin= 0x7E,
+   .upper_margin   = 0x16,
+   },
+};
+
+/* venc dv timings */
+static struct vpbe_enc_mode_info dm365evm_enc_preset_timing[] = {
+   {
+   .name   = "480p59_94",
+   .timings_type   = VPBE_ENC_DV_TIMINGS,
+   .dv_timings = V4L2_DV_BT_CEA_720X480P59_94,
+   .interlaced = 0,
+   .xres   = 720,
+   .yres   = 480,
+   .aspect = {1, 1},
+   .fps= {5994, 100},
+   .left_margin= 0x8F,
+   .upper_margin   = 0x2D,
+   },
+   {
+   .name   = "576p50",
+   .timings_type   = VPBE_ENC_DV_TIMINGS,
+   .dv_timings = V4L2_DV_BT_CEA_720X576P50,
+   .interlaced = 0,
+   .xres   = 720,
+   .yres   = 576,
+   .aspect = {1, 1},
+   .fps= {50, 1},
+   .left_margin= 0x8C,
+   .upper_margin   = 0x36,
+   },
+   {
+   .name   = "720p60",
+   .timings_type   = VPBE_ENC_DV_TIMINGS,
+   .dv_timings = V4L2_DV_BT_CEA_1280X720P60,
+   .interlaced = 0,
+   .xres   = 1280,
+   .yres   = 720,
+   .aspect = {1, 1},
+   .fps= {60, 1},
+   .left_margin= 0x117,
+   .right_margin   = 70,
+   .upper_margin   = 38,
+   .lower_margin   = 3,
+   .hsync_len  = 80,
+   .vsync_len  = 5,
+   },
+   {
+   .name   = "1080i60",
+   .timings_type   = VPBE_ENC_DV_TIMINGS,
+   .dv_timings = V4L2_DV_BT_CEA_1920X1080I60,
+   .interlaced = 1,
+   .xres   = 1920,
+   .yres   = 1080,
+   .aspect = {1, 1},
+   .fps= {30, 1},
+   .left_margin= 0xc9,
+   .right_margin   = 80,
+   .upper_margin   = 30,
+   .lower_margin   = 3,
+   .hsync_len  = 88,
+   .vsync_len  = 5,
+   },
+};
+
+#define VENC_STD_ALL   (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * the order same as that of encoders. First those from venc followed by that
+ * from encoders. Index in the output refers to index on a particular
+ * encoder.Driver uses this index to pass it to encoder when it supports more
+ * than one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm365evm_vpbe_outputs[] = {
+   {
+   .output = {
+   .index  = 0,
+   .name   = "Composite",
+   .type   = V4L2_OUTPUT_TYPE_ANALOG,
+   .std= VENC_STD_ALL,
+   .capabilities   = V4L2_OUT_CAP_STD,
+   },
+   .subdev_name= DM365_VPBE_VENC_SUBDEV_NAME,
+   .default_mode   = "ntsc",
+   

[PATCHv2 2/2] serial: of_serial: Handle fifo-size property

[Heikki Krogerus]

This will reduce the need for extra types in 8250.c just
in case the fifo size differs from the standard.

Signed-off-by: Heikki Krogerus 
---
 Documentation/devicetree/bindings/tty/serial/of-serial.txt |1 +
 drivers/tty/serial/of_serial.c |4 
 2 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt 
b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
index 8f01cb1..c13f0ce 100644
--- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt
+++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
@@ -33,6 +33,7 @@ Optional properties:
   RTAS and should not be registered.
 - no-loopback-test: set to indicate that the port does not implements loopback
   test mode
+- fifo-size: the fifo size of the UART.
 
 Example:
 
diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
index b025d54..267711b 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -97,6 +97,10 @@ static int of_platform_serial_setup(struct platform_device 
*ofdev,
if (of_property_read_u32(np, "reg-shift", &prop) == 0)
port->regshift = prop;
 
+   /* Check for fifo size */
+   if (of_property_read_u32(np, "fifo-size", &prop) == 0)
+   port->fifosize = prop;
+
port->irq = irq_of_parse_and_map(np, 0);
port->iotype = UPIO_MEM;
if (of_property_read_u32(np, "reg-io-width", &prop) == 0) {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()

[Michal Hocko]

On Fri 22-03-13 09:22:06, Li Zefan wrote:
> On 2013/3/21 18:22, Michal Hocko wrote:
> > On Thu 21-03-13 10:08:49, Michal Hocko wrote:
> >> On Thu 21-03-13 09:22:21, Li Zefan wrote:
> >>> As cgroup supports rename, it's unsafe to dereference dentry->d_name
> >>> without proper vfs locks. Fix this by using cgroup_name().
> >>>
> >>> Signed-off-by: Li Zefan 
> >>> ---
> >>>
> >>> This patch depends on "cgroup: fix cgroup_path() vs rename() race",
> >>> which has been queued for 3.10.
> >>>
> >>> ---
> >>>  mm/memcontrol.c | 15 +++
> >>>  1 file changed, 7 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> >>> index 53b8201..72be5c9 100644
> >>> --- a/mm/memcontrol.c
> >>> +++ b/mm/memcontrol.c
> >>> @@ -3217,17 +3217,16 @@ void mem_cgroup_destroy_cache(struct kmem_cache 
> >>> *cachep)
> >>>  static char *memcg_cache_name(struct mem_cgroup *memcg, struct 
> >>> kmem_cache *s)
> >>>  {
> >>>   char *name;
> >>> - struct dentry *dentry;
> >>> +
> >>> + name = (char *)__get_free_page(GFP_TEMPORARY);
> >>
> >> Ouch. Can we use a static temporary buffer instead?
> > 
> >> This is called from workqueue context so we do not have to be afraid
> >> of the deep call chain.
> > 
> > Bahh, I was thinking about two things at the same time and that is how
> > it ends... I meant a temporary buffer on the stack. But a separate
> > allocation sounds even easier.
> > 
> 
> Actually I don't care much about which way to take. Use on-stack buffer (if 
> stack
> usage is not a concern) or local static buffer (caller already held 
> memcg_cache_mutex)
> is simplest.
> 
> But why it's bad to allocate a page for temp use?

GFP_TEMPORARY groups short lived allocations but the mem cache is not
an ideal candidate of this type of allocations..

> >> It is also not a hot path AFAICS.
> >>
> >> Even GFP_ATOMIC for kasprintf would be an improvement IMO.
> > 
> > What about the following (not even compile tested because I do not have
> > cgroup_name in my tree yet):
> 
> No, it won't compile. ;)

Somehow expected so as this was just a quick hack to show what I meant.
The full patch is bellow (compile time tested on top of for-3.10 branch
this time :P)
---
>From 7e1f6f0e266a230ced238a9bf2398b4069a6a764 Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Fri, 22 Mar 2013 09:04:58 +0100
Subject: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()

As cgroup supports rename, it's unsafe to dereference dentry->d_name
without proper vfs locks. Fix this by using cgroup_name().

Signed-off-by: Li Zefan 
Signed-off-by: Michal Hocko 
---
 mm/memcontrol.c |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 53b8201..5741bf5 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3220,13 +3220,18 @@ static char *memcg_cache_name(struct mem_cgroup *memcg, 
struct kmem_cache *s)
struct dentry *dentry;
 
rcu_read_lock();
-   dentry = rcu_dereference(memcg->css.cgroup->dentry);
+   name = kasprintf(GFP_ATOMIC, "%s(%d:%s)", s->name,
+memcg_cache_id(memcg), 
dcgroup_name(memcg->css.cgroup));
rcu_read_unlock();
 
-   BUG_ON(dentry == NULL);
+   if (!name) {
+   name = kmalloc(PAGE_SIZE, GFP_KERNEL);
+   rcu_read_lock();
+   name = snprintf(name, PAGE_SIZE, "%s(%d:%s)", s->name,
+memcg_cache_id(memcg), 
dcgroup_name(memcg->css.cgroup));
+   rcu_read_unlock();
 
-   name = kasprintf(GFP_KERNEL, "%s(%d:%s)", s->name,
-memcg_cache_id(memcg), dentry->d_name.name);
+   }
 
return name;
 }
-- 
1.7.10.4

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 0/2] ARM: davinci: dm355: add support for vpbe display

[Prabhakar lad]

From: Lad, Prabhakar 

This patch series enables VPBE display driver on DM355.

This patch series is dependent on VPSS clock cleanup patches
(http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg25499.html)
posted.

Chnages for v6:
1: Fixed nits pointed by Sekhar.

Changes for v5:
1: Rebased on 3.9, fix review comments pointed by Sekhar for DM365 series.

Changes for v4:
1: pass different platform names to handle different ip's.

Changes for v3:
1: Replaced obsolete preset API by timings API.

Changes for v2:
1: Removed VPSS clock alias for master and slave which was
   sent for VPSS driver. since this patch was dependent on
   patch[1]. I will revist this patch once MC(captrure driver)
   goes into mainline.
[1] http://www.spinics.net/lists/linux-media/msg50562.html

Lad, Prabhakar (2):
  ARM: davinci: dm355: add support for v4l2 video display
  ARM: davinci: dm355 EVM: add support for VPBE display

 arch/arm/mach-davinci/board-dm355-evm.c |   71 -
 arch/arm/mach-davinci/davinci.h |2 +-
 arch/arm/mach-davinci/dm355.c   |  181 ++-
 3 files changed, 246 insertions(+), 8 deletions(-)

-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 1/2] ARM: davinci: dm355: add support for v4l2 video display

[Prabhakar lad]

From: Lad, Prabhakar 

Create platform devices for various video modules like venc,osd,
vpbe and v4l2 driver for dm355.

Signed-off-by: Lad, Prabhakar 
---
 arch/arm/mach-davinci/board-dm355-evm.c |4 +-
 arch/arm/mach-davinci/davinci.h |2 +-
 arch/arm/mach-davinci/dm355.c   |  181 ++-
 3 files changed, 179 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index 147b8e1..37d12cc 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -253,8 +253,6 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm355_evm_map_io(void)
 {
-   /* setup input configuration for VPFE input devices */
-   dm355_set_vpfe_config(&vpfe_cfg);
dm355_init();
 }
 
@@ -344,6 +342,8 @@ static __init void dm355_evm_init(void)
davinci_setup_mmc(0, &dm355evm_mmc_config);
davinci_setup_mmc(1, &dm355evm_mmc_config);
 
+   dm355_init_video(&vpfe_cfg, NULL);
+
dm355_init_spi0(BIT(0), dm355_evm_spi_info,
ARRAY_SIZE(dm355_evm_spi_info));
 
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 1c2670f..acfe0bb 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -74,7 +74,7 @@ void __init dm355_init(void);
 void dm355_init_spi0(unsigned chipselect_mask,
const struct spi_board_info *info, unsigned len);
 void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata);
-void dm355_set_vpfe_config(struct vpfe_config *cfg);
+int __init dm355_init_video(struct vpfe_config *, struct vpbe_config *);
 
 /* DM365 function declarations */
 void __init dm365_init(void);
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index a917983..20fc75c 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -36,6 +36,17 @@
 
 #define DM355_UART2_BASE   (IO_PHYS + 0x206000)
 
+#define DM355_VDAC_CONFIG  0x01c4002c
+
+#define DM355_OSD_BASE 0x01c70200
+
+#define DM355_VENC_BASE0x01c70400
+
+#define DM355_VPSS_CLK_CTRL_ADDR   0x44
+#define DM355_VPSS_MUXSEL_EXTCLK_ENABLEBIT(1)
+#define DM355_VPSS_VENCCLKEN_ENABLEBIT(3)
+#define DM355_VPSS_DACCLKEN_ENABLE BIT(4)
+
 /*
  * Device specific clocks
  */
@@ -744,11 +755,151 @@ static struct platform_device vpfe_capture_dev = {
},
 };
 
-void dm355_set_vpfe_config(struct vpfe_config *cfg)
+static struct resource dm355_osd_resources[] = {
+   {
+   .start  = DM355_OSD_BASE,
+   .end= DM355_OSD_BASE + 0x180,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device dm355_osd_dev = {
+   .name   = DM355_VPBE_OSD_SUBDEV_NAME,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm355_osd_resources),
+   .resource   = dm355_osd_resources,
+   .dev= {
+   .dma_mask   = &vpfe_capture_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   },
+};
+
+static struct resource dm355_venc_resources[] = {
+   {
+   .start  = IRQ_VENCINT,
+   .end= IRQ_VENCINT,
+   .flags  = IORESOURCE_IRQ,
+   },
+   /* venc registers io space */
+   {
+   .start  = DM355_VENC_BASE,
+   .end= DM355_VENC_BASE + 0x180,
+   .flags  = IORESOURCE_MEM,
+   },
+   /* VDAC config register io space */
+   {
+   .start  = DM355_VDAC_CONFIG,
+   .end= DM355_VDAC_CONFIG + 3,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct resource dm355_v4l2_disp_resources[] = {
+   {
+   .start  = IRQ_VENCINT,
+   .end= IRQ_VENCINT,
+   .flags  = IORESOURCE_IRQ,
+   },
+   /* venc registers io space */
+   {
+   .start  = DM355_VENC_BASE,
+   .end= DM355_VENC_BASE + 0x180,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static int dm355_vpbe_setup_pinmux(enum v4l2_mbus_pixelcode if_type,
+   int field)
 {
-   vpfe_capture_dev.dev.platform_data = cfg;
+   switch (if_type) {
+   case V4L2_MBUS_FMT_SGRBG8_1X8:
+   davinci_cfg_reg(DM355_VOUT_FIELD_G70);
+   break;
+
+   case V4L2_MBUS_FMT_YUYV10_1X20:
+   if (field)
+   davinci_cfg_reg(DM355_VOUT_FIELD);
+   else
+   davinci_cfg_reg(DM355_VOUT_FIELD_G70);
+   break;
+
+   default:
+   return -EINVAL;
+   }
+
+   davinci_cfg_reg(DM355_VOUT_COUTL_EN);
+   davinci_cfg_reg(DM355_VOUT_COUTH_EN);
+
+   return 0;
+}
+
+static int dm355_venc_

[PATCH v6 2/2] ARM: davinci: dm355 EVM: add support for VPBE display

[Prabhakar lad]

From: Lad, Prabhakar 

add support for V4L2 video display to DM355 EVM.
Support for SD modes is provided, along with Composite
output

Signed-off-by: Lad, Prabhakar 
---
 arch/arm/mach-davinci/board-dm355-evm.c |   69 ++-
 1 files changed, 68 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index 37d12cc..1043506 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -242,6 +242,73 @@ static struct vpfe_config vpfe_cfg = {
.ccdc = "DM355 CCDC",
 };
 
+/* venc standards timings */
+static struct vpbe_enc_mode_info dm355evm_enc_preset_timing[] = {
+   {
+   .name   = "ntsc",
+   .timings_type   = VPBE_ENC_STD,
+   .std_id = V4L2_STD_525_60,
+   .interlaced = 1,
+   .xres   = 720,
+   .yres   = 480,
+   .aspect = {11, 10},
+   .fps= {3, 1001},
+   .left_margin= 0x79,
+   .upper_margin   = 0x10,
+   },
+   {
+   .name   = "pal",
+   .timings_type   = VPBE_ENC_STD,
+   .std_id = V4L2_STD_625_50,
+   .interlaced = 1,
+   .xres   = 720,
+   .yres   = 576,
+   .aspect = {54, 59},
+   .fps= {25, 1},
+   .left_margin= 0x7E,
+   .upper_margin   = 0x16
+   },
+};
+
+#define VENC_STD_ALL   (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * the order same as that of encoders. First those from venc followed by that
+ * from encoders. Index in the output refers to index on a particular encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm355evm_vpbe_outputs[] = {
+   {
+   .output = {
+   .index  = 0,
+   .name   = "Composite",
+   .type   = V4L2_OUTPUT_TYPE_ANALOG,
+   .std= VENC_STD_ALL,
+   .capabilities   = V4L2_OUT_CAP_STD,
+   },
+   .subdev_name= DM355_VPBE_VENC_SUBDEV_NAME,
+   .default_mode   = "ntsc",
+   .num_modes  = ARRAY_SIZE(dm355evm_enc_preset_timing),
+   .modes  = dm355evm_enc_preset_timing,
+   .if_params  = V4L2_MBUS_FMT_FIXED,
+   },
+};
+
+static struct vpbe_config dm355evm_display_cfg = {
+   .module_name= "dm355-vpbe-display",
+   .i2c_adapter_id = 1,
+   .osd= {
+   .module_name= DM355_VPBE_OSD_SUBDEV_NAME,
+   },
+   .venc   = {
+   .module_name= DM355_VPBE_VENC_SUBDEV_NAME,
+   },
+   .num_outputs= ARRAY_SIZE(dm355evm_vpbe_outputs),
+   .outputs= dm355evm_vpbe_outputs,
+};
+
 static struct platform_device *davinci_evm_devices[] __initdata = {
&dm355evm_dm9000,
&davinci_nand_device,
@@ -342,7 +409,7 @@ static __init void dm355_evm_init(void)
davinci_setup_mmc(0, &dm355evm_mmc_config);
davinci_setup_mmc(1, &dm355evm_mmc_config);
 
-   dm355_init_video(&vpfe_cfg, NULL);
+   dm355_init_video(&vpfe_cfg, &dm355evm_display_cfg);
 
dm355_init_spi0(BIT(0), dm355_evm_spi_info,
ARRAY_SIZE(dm355_evm_spi_info));
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: remap kernel static memory to user space

[Clemens Ladisch]

Eduardo Cruz wrote:
> Please, anyone knows how to solve this problem?
>
> 2013/3/20 Eduardo Cruz :
>> I'm trying to remap some kernel static memory to user space using
>> remap_pfn_range.

Well, don't do that.

What is the actual problem you're trying to solve?


Regards,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2 3/3] ARM: davinci: da850: add EHRPWM & ECAP DT node

[Philip, Avinash]

On Fri, Mar 22, 2013 at 11:23:32, Nori, Sekhar wrote:
> On 3/21/2013 1:31 PM, Philip, Avinash wrote:
> > On Wed, Mar 20, 2013 at 18:17:59, Peter Korsgaard wrote:
> >>> "Sekhar" == Sekhar Nori  writes:
> >>
> >>  Sekhar> On 3/20/2013 12:11 PM, Philip Avinash wrote:
> >>  >> Add da850 EHRPWM & ECAP DT node.
> >>  >> Also adds OF_DEV_AUXDATA for EHRPWM & ECAP driver to use EHRPWM & ECAP
> >>  >> clock.
> >>  >> 
> >>  >> Signed-off-by: Philip Avinash 
> >>  >> ---
> >>  >> Changes since v1:
> >>  >> - Reusing ti,am33xx as compatible field as both IP's are
> >>  >> same with am33xx platform and da850 has no platform specific
> >>  >> dependency.
> >>
> >>  Sekhar> Which is fine, but I think the binding documentation still needs 
> >> to be
> >>  Sekhar> updated to document the ti,da850-ehrpwm binding. Looping Peter 
> >> (it is
> >>  Sekhar> always a good idea to CC folks who reviewed your patch last time
> >>  Sekhar> around). Also, please Cc the DT folks and devicetree-discuss list 
> >> too
> >>  Sekhar> for their opinion.
> >>
> >> Yes, thanks for CC'ing me. I also think da850-* should be
> >> documented. See Documentation/devicetree/bindings/gpio/8xxx_gpio.txt for
> >> an similar (old) example.
> > 
> > Peter,
> > 
> > In this binding file also, only initial compatible field is updated. Later 
> > on many
> > compatible were added in driver. But not update back to binding doc.
> 
> Probably someone forgot to keep updating the binding doc after a point.
> 
> > 
> > 
> > ---
> > followed by "fsl,mpc8349-gpio" for 83xx, "fsl,mpc8572-gpio" for 85xx and
> > "fsl,mpc8610-gpio" for 86xx.
> > ---
> > 
> > ---
> > static struct of_device_id mpc8xxx_gpio_ids[] __initdata = {
> > { .compatible = "fsl,mpc8349-gpio", },
> > { .compatible = "fsl,mpc8572-gpio", },
> > { .compatible = "fsl,mpc8610-gpio", },
> > { .compatible = "fsl,mpc5121-gpio", .data = mpc512x_irq_set_type, },
> > { .compatible = "fsl,pq3-gpio", },
> > { .compatible = "fsl,qoriq-gpio",   },
> > {}
> > };
> > ---
> > 
> > Grant/Rob,
> > With respect peters explanation (below), what is your opinion on adding 
> > information to 
> > binding doc for da850 support?
> > 
> > Peter --> if the hardware block is identical the dts should simply list:
> > Peter --> compatible = "ti,da850-ecap", "ti,am33xx-ecap"
> > Peter --> And the driver only bind to ti,am33xx-ecap (unless there ever 
> > needs to
> > Peter --> be a da850 specific workaround.
> > 
> > Or
> > Should I update both binding doc & the driver to use new compatible option 
> > "ti,da830-ecap"
> > (as da830 platform has initial IP support)?
> > Even with this, platforms da830, da850 and am33xx can reuse "ti,da830-ecap" 
> > compatible field.
> 
> To me updating the driver to keep adding a .compatible even when not
> using it elsewhere in code is not required. Adding the new binding in
> .dts file is must since you may need to do something specific to da830
> at a later time (and the .dtb should be considered ROM'ed so you wont be
> able to change it then).

Thanks for the explanation.
I will add "ti,da850-ecap" for da850.dtsi along with "ti,am33xx-ecap" as
compatible fields.

> Adding documentation for the binding is also
> required to help anyone wanting to know more about the binding after
> reading the .dts file.

I will adding documentation part for "ti,da850-ecap".

Thanks
Avinash

> 
> Thanks,
> Sekhar
> 

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 1/2] mfd: stmpe: DT: Enable no-irq mode configuration

[Linus Walleij]

On Fri, Mar 1, 2013 at 1:07 PM, Linus Walleij
 wrote:

> From: Gabriel Fernandez 
>
> If there is no interrupt property into stmpe node
> then activate the no-irq mode by setting the irq
> value to -1.
>
> Cc: devicetree-disc...@lists.ozlabs.org
> Signed-off-by: Gabriel Fernandez 
> Signed-off-by: Linus Walleij 

Hi Sam, ping on this!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] mfd: stmpe: DT: Add stmpe-i2c dt alias to get id device

[Linus Walleij]

On Fri, Mar 1, 2013 at 1:07 PM, Linus Walleij
 wrote:

> From: Gabriel Fernandez 
>
> This patch augments the STMP driver to read the device id
> from the stmpe-i2c dt alias if present.
>
> Cc: devicetree-disc...@lists.ozlabs.org
> Signed-off-by: Gabriel Fernandez 
> Signed-off-by: Linus Walleij 

Hi Sam,

ping on this!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2 2/2] serial: of_serial: Handle fifo-size property

[Ley Foon Tan]

On Fri, 2013-03-22 at 10:05 +0200, Heikki Krogerus wrote:
> This will reduce the need for extra types in 8250.c just
> in case the fifo size differs from the standard.
Besides the fifo size, we need to have hardware flow control setting
from device tree as well.
Thanks.
> 
> Signed-off-by: Heikki Krogerus 
> ---
>  Documentation/devicetree/bindings/tty/serial/of-serial.txt |1 +
>  drivers/tty/serial/of_serial.c |4 
>  2 files changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt 
> b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
> index 8f01cb1..c13f0ce 100644
> --- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt
> +++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt
> @@ -33,6 +33,7 @@ Optional properties:
>RTAS and should not be registered.
>  - no-loopback-test: set to indicate that the port does not implements 
> loopback
>test mode
> +- fifo-size: the fifo size of the UART.
>  



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()

[Li Zefan]

> @@ -3217,17 +3217,16 @@ void mem_cgroup_destroy_cache(struct kmem_cache 
> *cachep)
>  static char *memcg_cache_name(struct mem_cgroup *memcg, struct 
> kmem_cache *s)
>  {
>   char *name;
> - struct dentry *dentry;
> +
> + name = (char *)__get_free_page(GFP_TEMPORARY);

 Ouch. Can we use a static temporary buffer instead?
>>>
 This is called from workqueue context so we do not have to be afraid
 of the deep call chain.
>>>
>>> Bahh, I was thinking about two things at the same time and that is how
>>> it ends... I meant a temporary buffer on the stack. But a separate
>>> allocation sounds even easier.
>>>
>>
>> Actually I don't care much about which way to take. Use on-stack buffer (if 
>> stack
>> usage is not a concern) or local static buffer (caller already held 
>> memcg_cache_mutex)
>> is simplest.
>>
>> But why it's bad to allocate a page for temp use?
> 
> GFP_TEMPORARY groups short lived allocations but the mem cache is not
> an ideal candidate of this type of allocations..
> 

I'm not sure I'm following you...

char *memcg_cache_name()
{
char *name = alloc();
return name;
}

kmem_cache_dup()
{
name = memcg_cache_name();
kmem_cache_create_memcg(name);
free(name);
}

Isn't this a short lived allocation?

 It is also not a hot path AFAICS.

 Even GFP_ATOMIC for kasprintf would be an improvement IMO.
>>>
>>> What about the following (not even compile tested because I do not have
>>> cgroup_name in my tree yet):
>>
>> No, it won't compile. ;)
> 
> Somehow expected so as this was just a quick hack to show what I meant.
> The full patch is bellow (compile time tested on top of for-3.10 branch
> this time :P)
> ---
>>From 7e1f6f0e266a230ced238a9bf2398b4069a6a764 Mon Sep 17 00:00:00 2001
> From: Michal Hocko 
> Date: Fri, 22 Mar 2013 09:04:58 +0100
> Subject: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()
> 
> As cgroup supports rename, it's unsafe to dereference dentry->d_name
> without proper vfs locks. Fix this by using cgroup_name().
> 
> Signed-off-by: Li Zefan 
> Signed-off-by: Michal Hocko 
> ---
>  mm/memcontrol.c |   13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 53b8201..5741bf5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3220,13 +3220,18 @@ static char *memcg_cache_name(struct mem_cgroup 
> *memcg, struct kmem_cache *s)
>   struct dentry *dentry;
>  
>   rcu_read_lock();
> - dentry = rcu_dereference(memcg->css.cgroup->dentry);
> + name = kasprintf(GFP_ATOMIC, "%s(%d:%s)", s->name,
> +  memcg_cache_id(memcg), 
> dcgroup_name(memcg->css.cgroup));
>   rcu_read_unlock();
>  
> - BUG_ON(dentry == NULL);
> + if (!name) {
> + name = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + rcu_read_lock();
> + name = snprintf(name, PAGE_SIZE, "%s(%d:%s)", s->name,
> +  memcg_cache_id(memcg), 
> dcgroup_name(memcg->css.cgroup));
> + rcu_read_unlock();
>  
> - name = kasprintf(GFP_KERNEL, "%s(%d:%s)", s->name,
> -  memcg_cache_id(memcg), dentry->d_name.name);
> + }
>  
>   return name;
>  }
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/10] mm: vmscan: Block kswapd if it is encountering pages under writeback

[Mel Gorman]

On Thu, Mar 21, 2013 at 02:42:26PM -0400, Rik van Riel wrote:
> On 03/17/2013 09:04 AM, Mel Gorman wrote:
> >Historically, kswapd used to congestion_wait() at higher priorities if it
> >was not making forward progress. This made no sense as the failure to make
> >progress could be completely independent of IO. It was later replaced by
> >wait_iff_congested() and removed entirely by commit 258401a6 (mm: don't
> >wait on congested zones in balance_pgdat()) as it was duplicating logic
> >in shrink_inactive_list().
> >
> >This is problematic. If kswapd encounters many pages under writeback and
> >it continues to scan until it reaches the high watermark then it will
> >quickly skip over the pages under writeback and reclaim clean young
> >pages or push applications out to swap.
> >
> >The use of wait_iff_congested() is not suited to kswapd as it will only
> >stall if the underlying BDI is really congested or a direct reclaimer was
> >unable to write to the underlying BDI. kswapd bypasses the BDI congestion
> >as it sets PF_SWAPWRITE but even if this was taken into account then it
> >would cause direct reclaimers to stall on writeback which is not desirable.
> >
> >This patch sets a ZONE_WRITEBACK flag if direct reclaim or kswapd is
> >encountering too many pages under writeback. If this flag is set and
> >kswapd encounters a PageReclaim page under writeback then it'll assume
> >that the LRU lists are being recycled too quickly before IO can complete
> >and block waiting for some IO to complete.
> 
> I really like the concept of this patch.
> 

Thanks.

> >@@ -756,9 +769,11 @@ static unsigned long shrink_page_list(struct list_head 
> >*page_list,
> >  */
> > SetPageReclaim(page);
> > nr_writeback++;
> >+
> > goto keep_locked;
> >+} else {
> >+wait_on_page_writeback(page);
> > }
> >-wait_on_page_writeback(page);
> > }
> >
> > if (!force_reclaim)
> 
> This looks like an area for future improvement.
> 
> We do not need to wait for this specific page to finish writeback,
> we only have to wait for any (bunch of) page(s) to finish writeback,
> since we do not particularly care which of the pages from near the
> end of the LRU get reclaimed first.
> 

We do not have a good interface for waiting on IO to complete on any of a
list of pages. It could be polled but that feels unsatisfactory. Calling
congestion_wait() would sortof work and it's sortof what we used to do
in the past bvased on scanning priority but it only works if we happen to
wait on the correct async/sync queue and there is no guarnatee that it'll
wake when IO on a relevant page completes.

> I wonder if this is one of the causes for the high latencies that
> are sometimes observed in direct reclaim...
> 

I'm skeptical.

In the far past, direct reclaim would only indirectly stall on page writeback
using congestion_wait or a similar interface. Later it was possible for
direct reclaim to stall on wait_on_page_writeback() during lumpy reclaim
and that might be what you're thinking of?

It could be an indirect cause of direct reclaim stalls. If kswapd is
blocked on page writeback then it does mean that a process may stall in
direct reclaim because kswapd is not making forward progress but it
should not be the cause of high latencies.

Under what circumstances are you seeing high latencies in
direct reclaim? We should be able to measure the stalls using the
trace_mm_vmscan_direct_reclaim_begin and trace_mm_vmscan_direct_reclaim_end
tracepoints and pin down the cause.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv8 0/9] Support for Tegra 2D hardware

[Terje Bergstrom]

This set of patches adds support for Tegra20 and Tegra30 host1x and
2D. It is based on linux-next-20130322 with RTC fixes applied.

Changes in this version:
 * Own version of framebuffer driver due to move to own allocator
   * Thanks to Thierry Reding for help
 * Miscellaneous variable name, whitespace and IOCTL interface cleanups
 * Bug fixes:
   * Validator enabled again
   * Added new class 2D strechblit
 * Dropped patch "Support CMA object preallocation"

Changes in version 7:
 * host1x memory data structures refactored
 * Some "nvhost" leftovers renamed to host1x

Changes in version 6:
 * Rebased on latest tegradrm
 * Renamed tegradrm's host1x to host1x_drm
 * Indentation and line split fixed to follow tegradrm convention
 * Pointers to platform_device replaced with pointers to device
 * Added host1x allocator, and wired it in
 * Debug spew code fixed to access mem handles from host1x_job
 * CDMA code doesn't keep the mem handles anymore
 * Push buffer ops have been made generic code
 * Removed the pin_array optimization in host1x_job to simplify code
 * Large number of smaller changes

The driver implements an allocator using the dma mapping API. Each buffer is
assigned an ops structure to operate on it.

host1x is the driver that controls host1x hardware. It supports
host1x command channels, synchronization, and memory management. It
is sectioned into logical driver under drivers/gpu/host1x and
physical driver under drivers/host1x/hw. The physical driver is
compiled with the hardware headers of the particular host1x version.

The hardware units are described (briefly) in the Tegra2 TRM. Wiki
page http://http.download.nvidia.com/tegra-public-appnotes/host1x.html
also contains a short description of the functionality.

The patch set merges tegradrm into host1x and adds 2D driver, which
uses host1x channels and sync points. The patch set also adds user
space API to tegradrm for accessing host1x and 2D.

The changes to add support to libdrm are in
g...@gitorious.org:linux-host1x/libdrm-host1x.git

Arto Merilainen (2):
  gpu: host1x: drm: Rename host1x to host1x_drm
  gpu: host1x: drm: Add memory manager and fb

Terje Bergstrom (7):
  gpu: host1x: Add host1x driver
  gpu: host1x: Add syncpoint wait and interrupts
  gpu: host1x: Add channel support
  gpu: host1x: Add debug support
  drm: tegra: Move drm to live under host1x
  gpu: host1x: Remove second host1x driver
  drm: tegra: Add gr2d device

 drivers/gpu/Makefile   |1 +
 drivers/gpu/drm/Kconfig|2 -
 drivers/gpu/drm/Makefile   |1 -
 drivers/gpu/drm/tegra/Makefile |7 -
 drivers/gpu/drm/tegra/drm.c|  217 
 drivers/gpu/drm/tegra/fb.c |   52 --
 drivers/gpu/drm/tegra/host1x.c |  327 
 drivers/gpu/host1x/Kconfig |   23 +
 drivers/gpu/host1x/Makefile|   20 +
 drivers/gpu/host1x/cdma.c  |  491 ++
 drivers/gpu/host1x/cdma.h  |  100 
 drivers/gpu/host1x/channel.c   |  126 +
 drivers/gpu/host1x/channel.h   |   52 ++
 drivers/gpu/host1x/debug.c |  210 
 drivers/gpu/host1x/debug.h |   51 ++
 drivers/gpu/host1x/dev.c   |  246 +
 drivers/gpu/host1x/dev.h   |  308 
 drivers/gpu/{drm/tegra => host1x/drm}/Kconfig  |   19 +-
 drivers/gpu/{drm/tegra => host1x/drm}/dc.c |   26 +-
 drivers/gpu/{drm/tegra => host1x/drm}/dc.h |0
 drivers/gpu/host1x/drm/drm.c   |  641 
 drivers/gpu/{drm/tegra => host1x/drm}/drm.h|   68 ++-
 drivers/gpu/host1x/drm/fb.c|  374 ++
 drivers/gpu/host1x/drm/gem.c   |  270 ++
 drivers/gpu/host1x/drm/gem.h   |   59 +++
 drivers/gpu/host1x/drm/gr2d.c  |  340 +
 drivers/gpu/{drm/tegra => host1x/drm}/hdmi.c   |5 +-
 drivers/gpu/{drm/tegra => host1x/drm}/hdmi.h   |0
 drivers/gpu/{drm/tegra => host1x/drm}/output.c |0
 drivers/gpu/{drm/tegra => host1x/drm}/rgb.c|0
 drivers/gpu/host1x/host1x.h|   30 ++
 drivers/gpu/host1x/host1x_bo.h |   87 
 drivers/gpu/host1x/host1x_client.h |   35 ++
 drivers/gpu/host1x/hw/Makefile |6 +
 drivers/gpu/host1x/hw/cdma_hw.c|  326 
 drivers/gpu/host1x/hw/channel_hw.c |  168 +++
 drivers/gpu/host1x/hw/debug_hw.c   |  322 
 drivers/gpu/host1x/hw/host1x01.c   |   42 ++
 drivers/gpu/host1x/hw/host1x01.h   |   25 +
 drivers/gpu/host1x/hw/host1x01_hardware.h  |  143 ++
 drivers/gpu/host1x/hw/hw_host1x01_channel.h

[PATCHv8 5/9] drm: tegra: Move drm to live under host1x

[Terje Bergstrom]

Make drm part of host1x driver.

Signed-off-by: Arto Merilainen 
Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/drm/Kconfig|2 --
 drivers/gpu/drm/Makefile   |1 -
 drivers/gpu/drm/tegra/Makefile |7 ---
 drivers/gpu/host1x/Kconfig |2 ++
 drivers/gpu/host1x/Makefile|5 +
 drivers/gpu/{drm/tegra => host1x/drm}/Kconfig  |0
 drivers/gpu/{drm/tegra => host1x/drm}/dc.c |0
 drivers/gpu/{drm/tegra => host1x/drm}/dc.h |0
 drivers/gpu/{drm/tegra => host1x/drm}/drm.c|0
 drivers/gpu/{drm/tegra => host1x/drm}/drm.h|6 +++---
 drivers/gpu/{drm/tegra => host1x/drm}/fb.c |0
 drivers/gpu/{drm/tegra => host1x/drm}/hdmi.c   |0
 drivers/gpu/{drm/tegra => host1x/drm}/hdmi.h   |0
 drivers/gpu/{drm/tegra => host1x/drm}/host1x.c |0
 drivers/gpu/{drm/tegra => host1x/drm}/output.c |0
 drivers/gpu/{drm/tegra => host1x/drm}/rgb.c|0
 16 files changed, 10 insertions(+), 13 deletions(-)
 delete mode 100644 drivers/gpu/drm/tegra/Makefile
 rename drivers/gpu/{drm/tegra => host1x/drm}/Kconfig (100%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/dc.c (100%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/dc.h (100%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/drm.c (100%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/drm.h (98%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/fb.c (100%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/hdmi.c (100%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/hdmi.h (100%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/host1x.c (100%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/output.c (100%)
 rename drivers/gpu/{drm/tegra => host1x/drm}/rgb.c (100%)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1e82882..9031bb7 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -215,8 +215,6 @@ source "drivers/gpu/drm/cirrus/Kconfig"
 
 source "drivers/gpu/drm/shmobile/Kconfig"
 
-source "drivers/gpu/drm/tegra/Kconfig"
-
 source "drivers/gpu/drm/omapdrm/Kconfig"
 
 source "drivers/gpu/drm/tilcdc/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0d59b24..847b830 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -49,7 +49,6 @@ obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
-obj-$(CONFIG_DRM_TEGRA) += tegra/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
 obj-$(CONFIG_DRM_TILCDC)   += tilcdc/
 obj-y  += i2c/
diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
deleted file mode 100644
index 80f73d1..000
--- a/drivers/gpu/drm/tegra/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-ccflags-y := -Iinclude/drm
-ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
-
-tegra-drm-y := drm.o fb.o dc.o host1x.o
-tegra-drm-y += output.o rgb.o hdmi.o
-
-obj-$(CONFIG_DRM_TEGRA) += tegra-drm.o
diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
index 00f0859..ee3af1e 100644
--- a/drivers/gpu/host1x/Kconfig
+++ b/drivers/gpu/host1x/Kconfig
@@ -18,4 +18,6 @@ config TEGRA_HOST1X_FIREWALL
 
  If unsure, choose Y.
 
+source "drivers/gpu/host1x/drm/Kconfig"
+
 endif
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 49fd580..4761e8a 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -10,4 +10,9 @@ host1x-y = \
debug.o \
hw/host1x01.o
 
+ccflags-y += -Iinclude/drm
+ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
+
+host1x-$(CONFIG_DRM_TEGRA) += drm/drm.o drm/fb.o drm/dc.o drm/host1x.o
+host1x-$(CONFIG_DRM_TEGRA) += drm/output.o drm/rgb.o drm/hdmi.o
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/host1x/drm/Kconfig
similarity index 100%
rename from drivers/gpu/drm/tegra/Kconfig
rename to drivers/gpu/host1x/drm/Kconfig
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/host1x/drm/dc.c
similarity index 100%
rename from drivers/gpu/drm/tegra/dc.c
rename to drivers/gpu/host1x/drm/dc.c
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/host1x/drm/dc.h
similarity index 100%
rename from drivers/gpu/drm/tegra/dc.h
rename to drivers/gpu/host1x/drm/dc.h
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/host1x/drm/drm.c
similarity index 100%
rename from drivers/gpu/drm/tegra/drm.c
rename to drivers/gpu/host1x/drm/drm.c
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/host1x/drm/drm.h
similarity index 98%
rename from drivers/gpu/drm/tegra/drm.h
rename to drivers/gpu/host1x/drm/drm.h
index 6dd75a2..a6c011d 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/host1x/drm/drm.h
@@ -7,8 +7,8 @@
  * published by the Free Software Foundation.
  */
 
-#ifndef TEGRA_DRM_H
-#define TEGRA_DRM_H 1
+#ifndef HOST1X_DRM_H
+#define HOST1X_DRM_H 1
 
 #include 
 #include 
@@ -234,4 +234,4 @@ extern struct platform_driver tegra

[PATCHv8 4/9] gpu: host1x: Add debug support

[Terje Bergstrom]

Add support for host1x debugging. Adds debugfs entries, and dumps
channel state to UART in case of stuck job.

Signed-off-by: Arto Merilainen 
Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/host1x/Makefile |1 +
 drivers/gpu/host1x/cdma.c   |4 +
 drivers/gpu/host1x/debug.c  |  210 +
 drivers/gpu/host1x/debug.h  |   51 +
 drivers/gpu/host1x/dev.c|3 +
 drivers/gpu/host1x/dev.h|   42 
 drivers/gpu/host1x/hw/cdma_hw.c |2 +
 drivers/gpu/host1x/hw/channel_hw.c  |   25 +++
 drivers/gpu/host1x/hw/debug_hw.c|  322 +++
 drivers/gpu/host1x/hw/host1x01.c|2 +
 drivers/gpu/host1x/hw/hw_host1x01_channel.h |   18 ++
 drivers/gpu/host1x/hw/hw_host1x01_sync.h|  115 ++
 drivers/gpu/host1x/hw/hw_host1x01_uclass.h  |6 +
 drivers/gpu/host1x/hw/syncpt_hw.c   |1 +
 drivers/gpu/host1x/syncpt.c |5 +
 15 files changed, 807 insertions(+)
 create mode 100644 drivers/gpu/host1x/debug.c
 create mode 100644 drivers/gpu/host1x/debug.h
 create mode 100644 drivers/gpu/host1x/hw/debug_hw.c

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 06a995b..49fd580 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -7,6 +7,7 @@ host1x-y = \
cdma.o \
channel.o \
job.o \
+   debug.o \
hw/host1x01.o
 
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 33935de..de72172 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -439,6 +439,10 @@ void host1x_cdma_push(struct host1x_cdma *cdma, u32 op1, 
u32 op2)
struct push_buffer *pb = &cdma->push_buffer;
u32 slots_free = cdma->slots_free;
 
+   if (host1x_debug_trace_cmdbuf)
+   trace_host1x_cdma_push(dev_name(cdma_to_channel(cdma)->dev),
+  op1, op2);
+
if (slots_free == 0) {
host1x_hw_cdma_flush(host1x, cdma);
slots_free = host1x_cdma_wait_locked(cdma,
diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
new file mode 100644
index 000..3ec7d77
--- /dev/null
+++ b/drivers/gpu/host1x/debug.c
@@ -0,0 +1,210 @@
+/*
+ * Copyright (C) 2010 Google, Inc.
+ * Author: Erik Gilling 
+ *
+ * Copyright (C) 2011-2013 NVIDIA Corporation
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "dev.h"
+#include "debug.h"
+#include "channel.h"
+
+unsigned int host1x_debug_trace_cmdbuf;
+
+static pid_t host1x_debug_force_timeout_pid;
+static u32 host1x_debug_force_timeout_val;
+static u32 host1x_debug_force_timeout_channel;
+
+void host1x_debug_output(struct output *o, const char *fmt, ...)
+{
+   va_list args;
+   int len;
+
+   va_start(args, fmt);
+   len = vsnprintf(o->buf, sizeof(o->buf), fmt, args);
+   va_end(args);
+   o->fn(o->ctx, o->buf, len);
+}
+
+static int show_channels(struct host1x_channel *ch, void *data, bool show_fifo)
+{
+   struct host1x *m = dev_get_drvdata(ch->dev->parent);
+   struct output *o = data;
+
+   mutex_lock(&ch->reflock);
+   if (ch->refcount) {
+   mutex_lock(&ch->cdma.lock);
+   if (show_fifo)
+   host1x_hw_show_channel_fifo(m, ch, o);
+   host1x_hw_show_channel_cdma(m, ch, o);
+   mutex_unlock(&ch->cdma.lock);
+   }
+   mutex_unlock(&ch->reflock);
+
+   return 0;
+}
+
+static void show_syncpts(struct host1x *m, struct output *o)
+{
+   int i;
+   host1x_debug_output(o, " syncpts \n");
+   for (i = 0; i < host1x_syncpt_nb_pts(m); i++) {
+   u32 max = host1x_syncpt_read_max(m->syncpt + i);
+   u32 min = host1x_syncpt_load(m->syncpt + i);
+   if (!min && !max)
+   continue;
+   host1x_debug_output(o, "id %d (%s) min %d max %d\n",
+   i, m->syncpt[i].name, min, max);
+   }
+
+   for (i = 0; i < host1x_syncpt_nb_bases(m); i++) {
+   u32 base_val;
+   base_val = host1x_syncpt_load_wait_base(m->syncpt + i);
+   if (base_val)
+   host1x_debug_output(o, "waitbase id %d val %d\n", i,
+   base_val);
+   }
+
+   host1x_debug_outp

[PATCHv8 1/9] gpu: host1x: Add host1x driver

[Terje Bergstrom]

Add host1x, the driver for host1x and its client unit 2D. The Tegra
host1x module is the DMA engine for register access to Tegra's
graphics- and multimedia-related modules. The modules served by
host1x are referred to as clients. host1x includes some other
functionality, such as synchronization.

Signed-off-by: Arto Merilainen 
Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/Makefile  |1 +
 drivers/gpu/host1x/Kconfig|9 ++
 drivers/gpu/host1x/Makefile   |8 ++
 drivers/gpu/host1x/dev.c  |  153 +
 drivers/gpu/host1x/dev.h  |   96 +
 drivers/gpu/host1x/hw/Makefile|6 +
 drivers/gpu/host1x/hw/host1x01.c  |   33 +
 drivers/gpu/host1x/hw/host1x01.h  |   25 
 drivers/gpu/host1x/hw/host1x01_hardware.h |   27 
 drivers/gpu/host1x/hw/hw_host1x01_sync.h  |   74 ++
 drivers/gpu/host1x/hw/syncpt_hw.c |  102 ++
 drivers/gpu/host1x/syncpt.c   |  212 +
 drivers/gpu/host1x/syncpt.h   |  147 
 drivers/video/Kconfig |2 +
 include/trace/events/host1x.h |   61 +
 15 files changed, 956 insertions(+)
 create mode 100644 drivers/gpu/host1x/Kconfig
 create mode 100644 drivers/gpu/host1x/Makefile
 create mode 100644 drivers/gpu/host1x/dev.c
 create mode 100644 drivers/gpu/host1x/dev.h
 create mode 100644 drivers/gpu/host1x/hw/Makefile
 create mode 100644 drivers/gpu/host1x/hw/host1x01.c
 create mode 100644 drivers/gpu/host1x/hw/host1x01.h
 create mode 100644 drivers/gpu/host1x/hw/host1x01_hardware.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x01_sync.h
 create mode 100644 drivers/gpu/host1x/hw/syncpt_hw.c
 create mode 100644 drivers/gpu/host1x/syncpt.c
 create mode 100644 drivers/gpu/host1x/syncpt.h
 create mode 100644 include/trace/events/host1x.h

diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index 30879df..d8a22c2 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1,2 @@
 obj-y  += drm/ vga/
+obj-$(CONFIG_TEGRA_HOST1X) += host1x/
diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
new file mode 100644
index 000..c01c450
--- /dev/null
+++ b/drivers/gpu/host1x/Kconfig
@@ -0,0 +1,9 @@
+config TEGRA_HOST1X
+   tristate "NVIDIA Tegra host1x driver"
+   help
+ Driver for the NVIDIA Tegra host1x hardware.
+
+ The Tegra host1x module is the DMA engine for register access to
+ Tegra's graphics- and multimedia-related modules. The modules served
+ by host1x are referred to as clients. host1x includes some other
+ functionality, such as synchronization.
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
new file mode 100644
index 000..363e6ab
--- /dev/null
+++ b/drivers/gpu/host1x/Makefile
@@ -0,0 +1,8 @@
+ccflags-y = -Idrivers/gpu/host1x
+
+host1x-y = \
+   syncpt.o \
+   dev.o \
+   hw/host1x01.o
+
+obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
new file mode 100644
index 000..0d6002c
--- /dev/null
+++ b/drivers/gpu/host1x/dev.c
@@ -0,0 +1,153 @@
+/*
+ * Tegra host1x driver
+ *
+ * Copyright (c) 2010-2013, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CREATE_TRACE_POINTS
+#include 
+
+#include "dev.h"
+#include "hw/host1x01.h"
+
+void host1x_sync_writel(struct host1x *host1x, u32 v, u32 r)
+{
+   void __iomem *sync_regs = host1x->regs + host1x->info->sync_offset;
+
+   writel(v, sync_regs + r);
+}
+
+u32 host1x_sync_readl(struct host1x *host1x, u32 r)
+{
+   void __iomem *sync_regs = host1x->regs + host1x->info->sync_offset;
+
+   return readl(sync_regs + r);
+}
+
+static const struct host1x_info host1x01_info = {
+   .nb_channels= 8,
+   .nb_pts = 32,
+   .nb_mlocks  = 16,
+   .nb_bases   = 8,
+   .init   = host1x01_init,
+   .sync_offset= 0x3000,
+};
+
+static struct of_device_id host1x_of_match[] = {
+   { .compatible = "nvidia,tegra30-host1x", .data = &host1x01_info, },
+   { .compatible = "nvidia,tegra20-host1x", .data = &host1x01_info, },
+   { },
+};
+MODULE_DEVI

[PATCHv8 2/9] gpu: host1x: Add syncpoint wait and interrupts

[Terje Bergstrom]

Add support for sync point interrupts, and sync point wait. Sync
point wait used interrupts for unblocking wait.

Signed-off-by: Arto Merilainen 
Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/host1x/Makefile  |1 +
 drivers/gpu/host1x/dev.c |   12 ++
 drivers/gpu/host1x/dev.h |   51 +
 drivers/gpu/host1x/hw/host1x01.c |2 +
 drivers/gpu/host1x/hw/hw_host1x01_sync.h |   42 
 drivers/gpu/host1x/hw/intr_hw.c  |  143 +
 drivers/gpu/host1x/intr.c|  328 ++
 drivers/gpu/host1x/intr.h|   96 +
 drivers/gpu/host1x/syncpt.c  |  159 +++
 drivers/gpu/host1x/syncpt.h  |   12 ++
 10 files changed, 846 insertions(+)
 create mode 100644 drivers/gpu/host1x/hw/intr_hw.c
 create mode 100644 drivers/gpu/host1x/intr.c
 create mode 100644 drivers/gpu/host1x/intr.h

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 363e6ab..5ef47ff 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -3,6 +3,7 @@ ccflags-y = -Idrivers/gpu/host1x
 host1x-y = \
syncpt.o \
dev.o \
+   intr.o \
hw/host1x01.o
 
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 0d6002c..b967f6e 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -28,6 +28,7 @@
 #include 
 
 #include "dev.h"
+#include "intr.h"
 #include "hw/host1x01.h"
 
 void host1x_sync_writel(struct host1x *host1x, u32 v, u32 r)
@@ -123,13 +124,24 @@ static int host1x_probe(struct platform_device *pdev)
return err;
}
 
+   err = host1x_intr_init(host, syncpt_irq);
+   if (err) {
+   dev_err(&pdev->dev, "failed to initialize interrupts\n");
+   goto fail_deinit_syncpt;
+   }
+
return 0;
+
+fail_deinit_syncpt:
+   host1x_syncpt_deinit(host);
+   return err;
 }
 
 static int __exit host1x_remove(struct platform_device *pdev)
 {
struct host1x *host = platform_get_drvdata(pdev);
 
+   host1x_intr_deinit(host);
host1x_syncpt_deinit(host);
clk_disable_unprepare(host->clk);
 
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index eaf6026..caf9cc6 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -21,6 +21,7 @@
 #include 
 
 #include "syncpt.h"
+#include "intr.h"
 
 struct host1x_syncpt;
 
@@ -33,6 +34,17 @@ struct host1x_syncpt_ops {
int (*patch_wait)(struct host1x_syncpt *syncpt, void *patch_addr);
 };
 
+struct host1x_intr_ops {
+   int (*init_host_sync)(struct host1x *host, u32 cpm,
+   void (*syncpt_thresh_work)(struct work_struct *work));
+   void (*set_syncpt_threshold)(
+   struct host1x *host, u32 id, u32 thresh);
+   void (*enable_syncpt_intr)(struct host1x *host, u32 id);
+   void (*disable_syncpt_intr)(struct host1x *host, u32 id);
+   void (*disable_all_syncpt_intrs)(struct host1x *host);
+   int (*free_syncpt_irq)(struct host1x *host);
+};
+
 struct host1x_info {
int nb_channels;/* host1x: num channels supported */
int nb_pts; /* host1x: num syncpoints supported */
@@ -50,7 +62,13 @@ struct host1x {
struct device *dev;
struct clk *clk;
 
+   struct mutex intr_mutex;
+   struct workqueue_struct *intr_wq;
+   int intr_syncpt_irq;
+
const struct host1x_syncpt_ops *syncpt_op;
+   const struct host1x_intr_ops *intr_op;
+
 };
 
 void host1x_sync_writel(struct host1x *host1x, u32 r, u32 v);
@@ -93,4 +111,37 @@ static inline int host1x_hw_syncpt_patch_wait(struct host1x 
*host,
return host->syncpt_op->patch_wait(sp, patch_addr);
 }
 
+static inline int host1x_hw_intr_init_host_sync(struct host1x *host, u32 cpm,
+   void (*syncpt_thresh_work)(struct work_struct *))
+{
+   return host->intr_op->init_host_sync(host, cpm, syncpt_thresh_work);
+}
+
+static inline void host1x_hw_intr_set_syncpt_threshold(struct host1x *host,
+  u32 id, u32 thresh)
+{
+   host->intr_op->set_syncpt_threshold(host, id, thresh);
+}
+
+static inline void host1x_hw_intr_enable_syncpt_intr(struct host1x *host,
+u32 id)
+{
+   host->intr_op->enable_syncpt_intr(host, id);
+}
+
+static inline void host1x_hw_intr_disable_syncpt_intr(struct host1x *host,
+ u32 id)
+{
+   host->intr_op->disable_syncpt_intr(host, id);
+}
+
+static inline void host1x_hw_intr_disable_all_syncpt_intrs(struct host1x *host)
+{
+   host->intr_op->disable_all_syncpt_intrs(host);
+}
+
+static inline int host1x_hw_intr_free_syncpt_irq(struct host1x *host)
+{
+   return host->intr_op->free_syncpt_irq(host);
+}
 #endif
diff --git a

[PATCHv8 6/9] gpu: host1x: drm: Rename host1x to host1x_drm

[Terje Bergstrom]

From: Arto Merilainen 

Both host1x and drm drivers have host1x structures. This patch
renames the host1x structure under drm to follow name host1x_drm.

Signed-off-by: Arto Merilainen 
Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/host1x/drm/dc.c |4 ++--
 drivers/gpu/host1x/drm/drm.c|4 ++--
 drivers/gpu/host1x/drm/drm.h|   14 +++---
 drivers/gpu/host1x/drm/fb.c |6 +++---
 drivers/gpu/host1x/drm/hdmi.c   |4 ++--
 drivers/gpu/host1x/drm/host1x.c |   22 --
 6 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/host1x/drm/dc.c b/drivers/gpu/host1x/drm/dc.c
index de94707..d1f6609 100644
--- a/drivers/gpu/host1x/drm/dc.c
+++ b/drivers/gpu/host1x/drm/dc.c
@@ -1097,7 +1097,7 @@ static const struct host1x_client_ops dc_client_ops = {
 
 static int tegra_dc_probe(struct platform_device *pdev)
 {
-   struct host1x *host1x = dev_get_drvdata(pdev->dev.parent);
+   struct host1x_drm *host1x = dev_get_drvdata(pdev->dev.parent);
struct resource *regs;
struct tegra_dc *dc;
int err;
@@ -1160,7 +1160,7 @@ static int tegra_dc_probe(struct platform_device *pdev)
 
 static int tegra_dc_remove(struct platform_device *pdev)
 {
-   struct host1x *host1x = dev_get_drvdata(pdev->dev.parent);
+   struct host1x_drm *host1x = dev_get_drvdata(pdev->dev.parent);
struct tegra_dc *dc = platform_get_drvdata(pdev);
int err;
 
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 9d452df..6c59bcd 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -26,7 +26,7 @@
 static int tegra_drm_load(struct drm_device *drm, unsigned long flags)
 {
struct device *dev = drm->dev;
-   struct host1x *host1x;
+   struct host1x_drm *host1x;
int err;
 
host1x = dev_get_drvdata(dev);
@@ -69,7 +69,7 @@ static int tegra_drm_open(struct drm_device *drm, struct 
drm_file *filp)
 
 static void tegra_drm_lastclose(struct drm_device *drm)
 {
-   struct host1x *host1x = drm->dev_private;
+   struct host1x_drm *host1x = drm->dev_private;
 
drm_fbdev_cma_restore_mode(host1x->fbdev);
 }
diff --git a/drivers/gpu/host1x/drm/drm.h b/drivers/gpu/host1x/drm/drm.h
index a6c011d..7fedb6c 100644
--- a/drivers/gpu/host1x/drm/drm.h
+++ b/drivers/gpu/host1x/drm/drm.h
@@ -18,7 +18,7 @@
 #include 
 #include 
 
-struct host1x {
+struct host1x_drm {
struct drm_device *drm;
struct device *dev;
void __iomem *regs;
@@ -44,7 +44,7 @@ struct host1x_client_ops {
 };
 
 struct host1x_client {
-   struct host1x *host1x;
+   struct host1x_drm *host1x;
struct device *dev;
 
const struct host1x_client_ops *ops;
@@ -52,12 +52,12 @@ struct host1x_client {
struct list_head list;
 };
 
-extern int host1x_drm_init(struct host1x *host1x, struct drm_device *drm);
-extern int host1x_drm_exit(struct host1x *host1x);
+extern int host1x_drm_init(struct host1x_drm *host1x, struct drm_device *drm);
+extern int host1x_drm_exit(struct host1x_drm *host1x);
 
-extern int host1x_register_client(struct host1x *host1x,
+extern int host1x_register_client(struct host1x_drm *host1x,
  struct host1x_client *client);
-extern int host1x_unregister_client(struct host1x *host1x,
+extern int host1x_unregister_client(struct host1x_drm *host1x,
struct host1x_client *client);
 
 struct tegra_output;
@@ -66,7 +66,7 @@ struct tegra_dc {
struct host1x_client client;
spinlock_t lock;
 
-   struct host1x *host1x;
+   struct host1x_drm *host1x;
struct device *dev;
 
struct drm_crtc base;
diff --git a/drivers/gpu/host1x/drm/fb.c b/drivers/gpu/host1x/drm/fb.c
index 0391495..6ed885a 100644
--- a/drivers/gpu/host1x/drm/fb.c
+++ b/drivers/gpu/host1x/drm/fb.c
@@ -11,7 +11,7 @@
 
 static void tegra_drm_fb_output_poll_changed(struct drm_device *drm)
 {
-   struct host1x *host1x = drm->dev_private;
+   struct host1x_drm *host1x = drm->dev_private;
 
drm_fbdev_cma_hotplug_event(host1x->fbdev);
 }
@@ -23,7 +23,7 @@ static const struct drm_mode_config_funcs 
tegra_drm_mode_funcs = {
 
 int tegra_drm_fb_init(struct drm_device *drm)
 {
-   struct host1x *host1x = drm->dev_private;
+   struct host1x_drm *host1x = drm->dev_private;
struct drm_fbdev_cma *fbdev;
 
drm->mode_config.min_width = 0;
@@ -46,7 +46,7 @@ int tegra_drm_fb_init(struct drm_device *drm)
 
 void tegra_drm_fb_exit(struct drm_device *drm)
 {
-   struct host1x *host1x = drm->dev_private;
+   struct host1x_drm *host1x = drm->dev_private;
 
drm_fbdev_cma_fini(host1x->fbdev);
 }
diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
index bb747f6..f438f80 100644
--- a/drivers/gpu/host1x/drm/hdmi.c
+++ b/drivers/gpu/host1x/drm/hdmi.c
@@ -1189,7 +1189,7 @@ static const struct host1x_client_ops hdmi_client_ops = {
 

Re: [PATCH v3] gpio: mcp23s08: convert driver to DT

[Linus Walleij]

Hi Lars,

sorry for taking eternities to review stuff :-(

I recommend that you include SPI co-maintainer Mark Brown on subsequent
postings.

On Mon, Mar 4, 2013 at 5:34 PM, Lars Poeschel  wrote:

> This converts the mcp23s08 driver to be able to be used with device
> tree.

OK!

> +++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
> @@ -0,0 +1,43 @@
> +Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for
> +8-/16-bit I/O expander with serial interface (I2C/SPI)
> +
> +Required properties:
> +- compatible : Should be
> +- "mcp,mcp23s08" for  8 GPIO SPI version
> +- "mcp,mcp23s17" for 16 GPIO SPI version
> +- "mcp,mcp23008" for  8 GPIO I2C version or
> +- "mcp,mcp23017" for 16 GPIO I2C version of the chip
> +- #gpio-cells : Should be two.
> +  - first cell is the pin number
> +  - second cell is used to specify flags. Flags currently used:
> +bit0 : activate a ~100k pullup

Pullup is basically about pin config. This is sort of sneaking
behind the subsystems, but I know I might be overzealous.

Can the electronics do more things than pull-up?

Like pull-down, open drain, drive strength...

If it's a lot it's better to consider pinctrl from the start.
I'm saying this because the DT bindings will be maintained
perpetually and need to set a good example.

I would currently feel a lot better if you did not include this
flag. How would you control this the day drivers need to
enable/disable pull-up at runtime?

> +- gpio-controller : Marks the device node as a GPIO controller.
> +- reg : For an address on its bus

On the I2C/SPI bus?

Please state here what kind of buses it can be. Explain if multiple
buses are supported.

> +Required device specific properties (only for SPI chips):
> +- mcp,spi-present-mask : This is a present flag, that makes only sense for 
> SPI
> +chips - as the name suggests.

AFAIK this is not how we disable/enable devices in the device tree.

Istead we include a property on the node called "status" and set it
to "disabled" if the device is not there.

> +Multiple chips can share the same
> +SPI chipselect. Set bit 0-7 in this mask to 1 if there is a chip
> +connected with this spi address. If you have a chip with address 3
> +connected, you have to set bit3 to 1, which is 0x08. mcp23s08 only
> +supports bits 0-3. It is not possible to mix mcp23s08 and mcp23s17
> +on the same chipselect. Set at least one bit to 1 for SPI chips.

This looks awkward, why are you using a bitfield for this? Then you
can only ever support 8 devices, since the text also implies that the
value is 8bit (this should be stated).

What about just using a number?

> diff --git a/drivers/gpio/gpio-mcp23s08.c b/drivers/gpio/gpio-mcp23s08.c
> index 3cea0ea..a8ca469 100644
> --- a/drivers/gpio/gpio-mcp23s08.c
> +++ b/drivers/gpio/gpio-mcp23s08.c
> @@ -12,6 +12,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  /**
>   * MCP types supported by driver
> @@ -21,6 +23,11 @@
>  #define MCP_TYPE_008   2
>  #define MCP_TYPE_017   3
>
> +/**
> + * Flags used in device tree
> + */
> +#define MCP_DT_FLAG_PULLUP 0x01

So I'm sceptical here. Is this already supported using platform data?

>  /* Registers are all 8 bits wide.
>   *
>   * The mcp23s17 has twice as many bits, and can be configured to work
> @@ -75,6 +82,25 @@ struct mcp23s08_driver_data {
> struct mcp23s08 chip[];
>  };
>
> +#ifdef CONFIG_OF
> +static int mcp23s08_of_xlate(struct gpio_chip *gc,
> +   const struct of_phandle_args *gpiospec, u32 *flags);
> +
> +static int mcp23s08_set_pullup(struct mcp23s08 *mcp, unsigned offset)
> +{
> +   int status;
> +   u16 value;
> +
> +   mutex_lock(&mcp->lock);
> +   value = mcp->cache[MCP_GPPU] | (1 << offset);
> +   status = mcp->ops->write(mcp, MCP_GPPU, value);
> +   if (!status)
> +   mcp->cache[MCP_GPPU] = value;
> +   mutex_unlock(&mcp->lock);
> +
> +   return status;
> +}

The pull-up business actually looks like new functionality that
has nothing to do with adding device tree support and should be
a separate patch.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv8 8/9] gpu: host1x: drm: Add memory manager and fb

[Terje Bergstrom]

From: Arto Merilainen 

This patch introduces a memory manager for tegra drm and moves
existing parts to use it. As cma framebuffer helpers can no more
be used, this patch adds also a separate framebuffer driver for
tegra.

Signed-off-by: Arto Merilainen 
Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/host1x/Makefile|1 +
 drivers/gpu/host1x/drm/Kconfig |8 +-
 drivers/gpu/host1x/drm/dc.c|   23 +--
 drivers/gpu/host1x/drm/drm.c   |   17 +-
 drivers/gpu/host1x/drm/drm.h   |   18 ++-
 drivers/gpu/host1x/drm/fb.c|  338 +++-
 drivers/gpu/host1x/drm/gem.c   |  270 
 drivers/gpu/host1x/drm/gem.h   |   59 +++
 8 files changed, 700 insertions(+), 34 deletions(-)
 create mode 100644 drivers/gpu/host1x/drm/gem.c
 create mode 100644 drivers/gpu/host1x/drm/gem.h

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 9a6fc76..3768dbc 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -15,4 +15,5 @@ ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
 
 host1x-$(CONFIG_DRM_TEGRA) += drm/drm.o drm/fb.o drm/dc.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/output.o drm/rgb.o drm/hdmi.o
+host1x-$(CONFIG_DRM_TEGRA) += drm/gem.o
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/drm/Kconfig b/drivers/gpu/host1x/drm/Kconfig
index 7db9b3a..f743540 100644
--- a/drivers/gpu/host1x/drm/Kconfig
+++ b/drivers/gpu/host1x/drm/Kconfig
@@ -2,11 +2,9 @@ config DRM_TEGRA
bool "NVIDIA Tegra DRM"
depends on DRM && OF && ARCH_TEGRA
select DRM_KMS_HELPER
-   select DRM_GEM_CMA_HELPER
-   select DRM_KMS_CMA_HELPER
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
+   select FB_SYS_FILLRECT
+   select FB_SYS_COPYAREA
+   select FB_SYS_IMAGEBLIT
help
  Choose this option if you have an NVIDIA Tegra SoC.
 
diff --git a/drivers/gpu/host1x/drm/dc.c b/drivers/gpu/host1x/drm/dc.c
index 29a79b6..85ea616 100644
--- a/drivers/gpu/host1x/drm/dc.c
+++ b/drivers/gpu/host1x/drm/dc.c
@@ -14,9 +14,10 @@
 #include 
 #include 
 
-#include "drm.h"
-#include "dc.h"
 #include "host1x_client.h"
+#include "dc.h"
+#include "drm.h"
+#include "gem.h"
 
 struct tegra_plane {
struct drm_plane base;
@@ -52,9 +53,9 @@ static int tegra_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
window.bits_per_pixel = fb->bits_per_pixel;
 
for (i = 0; i < drm_format_num_planes(fb->pixel_format); i++) {
-   struct drm_gem_cma_object *gem = drm_fb_cma_get_gem_obj(fb, i);
+   struct tegra_bo *bo = tegra_fb_get_plane(fb, i);
 
-   window.base[i] = gem->paddr + fb->offsets[i];
+   window.base[i] = bo->paddr + fb->offsets[i];
 
/*
 * Tegra doesn't support different strides for U and V planes
@@ -137,7 +138,7 @@ static int tegra_dc_add_planes(struct drm_device *drm, 
struct tegra_dc *dc)
 static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
 struct drm_framebuffer *fb)
 {
-   struct drm_gem_cma_object *gem = drm_fb_cma_get_gem_obj(fb, 0);
+   struct tegra_bo *bo = tegra_fb_get_plane(fb, 0);
unsigned long value;
 
tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
@@ -145,7 +146,7 @@ static int tegra_dc_set_base(struct tegra_dc *dc, int x, 
int y,
value = fb->offsets[0] + y * fb->pitches[0] +
x * fb->bits_per_pixel / 8;
 
-   tegra_dc_writel(dc, gem->paddr + value, DC_WINBUF_START_ADDR);
+   tegra_dc_writel(dc, bo->paddr + value, DC_WINBUF_START_ADDR);
tegra_dc_writel(dc, fb->pitches[0], DC_WIN_LINE_STRIDE);
 
value = GENERAL_UPDATE | WIN_A_UPDATE;
@@ -187,20 +188,20 @@ static void tegra_dc_finish_page_flip(struct tegra_dc *dc)
 {
struct drm_device *drm = dc->base.dev;
struct drm_crtc *crtc = &dc->base;
-   struct drm_gem_cma_object *gem;
unsigned long flags, base;
+   struct tegra_bo *bo;
 
if (!dc->event)
return;
 
-   gem = drm_fb_cma_get_gem_obj(crtc->fb, 0);
+   bo = tegra_fb_get_plane(crtc->fb, 0);
 
/* check if new start address has been latched */
tegra_dc_writel(dc, READ_MUX, DC_CMD_STATE_ACCESS);
base = tegra_dc_readl(dc, DC_WINBUF_START_ADDR);
tegra_dc_writel(dc, 0, DC_CMD_STATE_ACCESS);
 
-   if (base == gem->paddr + crtc->fb->offsets[0]) {
+   if (base == bo->paddr + crtc->fb->offsets[0]) {
spin_lock_irqsave(&drm->event_lock, flags);
drm_send_vblank_event(drm, dc->pipe, dc->event);
drm_vblank_put(drm, dc->pipe);
@@ -570,7 +571,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
   struct drm_display_mode *adjusted,
   int x, int y, struct drm_framebuffer *old_fb)
 {
-   struct d

Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()

[Glauber Costa]

On 03/22/2013 12:17 PM, Li Zefan wrote:
>> GFP_TEMPORARY groups short lived allocations but the mem cache is not
>> > an ideal candidate of this type of allocations..
>> > 
> I'm not sure I'm following you...
> 
> char *memcg_cache_name()
> {
>   char *name = alloc();
>   return name;
> }
> 
> kmem_cache_dup()
> {
>   name = memcg_cache_name();
>   kmem_cache_create_memcg(name);
>   free(name);
> }
> 
> Isn't this a short lived allocation?
> 

Hi,

Thanks for identifying and fixing this.

Li is right. The cache name will live long, but this is because the
slab/slub caches will strdup it internally. So the actual memcg
allocation is short lived.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv8 9/9] drm: tegra: Add gr2d device

[Terje Bergstrom]

Add client driver for 2D device, and IOCTLs to pass work to host1x
channel for 2D.

Also adds functions that can be called to access sync points from
DRM.

Signed-off-by: Arto Merilainen 
Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/host1x/Makefile|1 +
 drivers/gpu/host1x/dev.c   |7 +
 drivers/gpu/host1x/drm/Kconfig |9 ++
 drivers/gpu/host1x/drm/drm.c   |  213 -
 drivers/gpu/host1x/drm/drm.h   |   27 +++-
 drivers/gpu/host1x/drm/gr2d.c  |  340 
 drivers/gpu/host1x/host1x.h|4 +-
 include/uapi/drm/tegra_drm.h   |  136 
 8 files changed, 734 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/host1x/drm/gr2d.c
 create mode 100644 include/uapi/drm/tegra_drm.h

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 3768dbc..3b037b6 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -16,4 +16,5 @@ ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
 host1x-$(CONFIG_DRM_TEGRA) += drm/drm.o drm/fb.o drm/dc.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/output.o drm/rgb.o drm/hdmi.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/gem.o
+host1x-$(CONFIG_DRM_TEGRA) += drm/gr2d.o
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 8ce9889..28e28a2 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -209,11 +209,17 @@ static int __init tegra_host1x_init(void)
err = platform_driver_register(&tegra_hdmi_driver);
if (err < 0)
goto unregister_dc;
+
+   err = platform_driver_register(&tegra_gr2d_driver);
+   if (err < 0)
+   goto unregister_hdmi;
 #endif
 
return 0;
 
 #ifdef CONFIG_DRM_TEGRA
+unregister_hdmi:
+   platform_driver_unregister(&tegra_hdmi_driver);
 unregister_dc:
platform_driver_unregister(&tegra_dc_driver);
 unregister_host1x:
@@ -226,6 +232,7 @@ module_init(tegra_host1x_init);
 static void __exit tegra_host1x_exit(void)
 {
 #ifdef CONFIG_DRM_TEGRA
+   platform_driver_unregister(&tegra_gr2d_driver);
platform_driver_unregister(&tegra_hdmi_driver);
platform_driver_unregister(&tegra_dc_driver);
 #endif
diff --git a/drivers/gpu/host1x/drm/Kconfig b/drivers/gpu/host1x/drm/Kconfig
index f743540..6e3f567 100644
--- a/drivers/gpu/host1x/drm/Kconfig
+++ b/drivers/gpu/host1x/drm/Kconfig
@@ -13,6 +13,15 @@ config DRM_TEGRA
 
 if DRM_TEGRA
 
+config DRM_TEGRA_STAGING
+   bool "Enable HOST1X interface"
+   depends on STAGING
+   default n
+   help
+ Say yes if HOST1X should be available for userspace DRM users.
+
+ If unsure, choose N.
+
 config DRM_TEGRA_DEBUG
bool "NVIDIA Tegra DRM debug support"
help
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index c4e45c1..6db1bd6 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2012 Avionic Design GmbH
- * Copyright (C) 2012 NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (C) 2012-2013 NVIDIA CORPORATION.  All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -14,6 +14,11 @@
 #include 
 #include 
 
+#include 
+#include 
+
+#include 
+
 #include "host1x_client.h"
 #include "dev.h"
 #include "drm.h"
@@ -81,8 +86,10 @@ static int host1x_parse_dt(struct host1x_drm *host1x)
static const char * const compat[] = {
"nvidia,tegra20-dc",
"nvidia,tegra20-hdmi",
+   "nvidia,tegra20-gr2d",
"nvidia,tegra30-dc",
"nvidia,tegra30-hdmi",
+   "nvidia,tegra30-gr2d",
};
unsigned int i;
int err;
@@ -277,9 +284,24 @@ static int tegra_drm_unload(struct drm_device *drm)
 
 static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp)
 {
+   struct host1x_drm_file *fpriv;
+
+   fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
+   if (!fpriv)
+   return -ENOMEM;
+
+   INIT_LIST_HEAD(&fpriv->contexts);
+   filp->driver_priv = fpriv;
+
return 0;
 }
 
+static void host1x_drm_context_free(struct host1x_drm_context *context)
+{
+   context->client->ops->close_channel(context);
+   kfree(context);
+}
+
 static void tegra_drm_lastclose(struct drm_device *drm)
 {
struct host1x_drm *host1x = drm->dev_private;
@@ -287,7 +309,189 @@ static void tegra_drm_lastclose(struct drm_device *drm)
tegra_fbdev_restore_mode(host1x->fbdev);
 }
 
+#ifdef CONFIG_DRM_TEGRA_STAGING
+static int tegra_drm_ioctl_syncpt_read(struct drm_device *drm, void *data,
+  struct drm_file *file)
+{
+   struct drm_tegra_syncpt_read *args = data;
+   struct host1x *host = dev_get_drvdata(drm->dev);
+   struct host1x_syncpt *sp = host1x_syncpt_get(ho

[PATCHv8 7/9] gpu: host1x: Remove second host1x driver

[Terje Bergstrom]

Remove second host1x driver, and bind tegra-drm to the new host1x
driver. The logic to parse device tree and track clients is moved
to drm.c.

Signed-off-by: Arto Merilainen 
Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/host1x/Makefile|2 +-
 drivers/gpu/host1x/dev.c   |   58 ++-
 drivers/gpu/host1x/dev.h   |6 +
 drivers/gpu/host1x/drm/Kconfig |2 +-
 drivers/gpu/host1x/drm/dc.c|5 +-
 drivers/gpu/host1x/drm/drm.c   |  214 ++-
 drivers/gpu/host1x/drm/drm.h   |3 -
 drivers/gpu/host1x/drm/hdmi.c  |5 +-
 drivers/gpu/host1x/drm/host1x.c|  329 
 drivers/gpu/host1x/host1x_client.h |   35 
 10 files changed, 317 insertions(+), 342 deletions(-)
 delete mode 100644 drivers/gpu/host1x/drm/host1x.c
 create mode 100644 drivers/gpu/host1x/host1x_client.h

diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 4761e8a..9a6fc76 100644
--- a/drivers/gpu/host1x/Makefile
+++ b/drivers/gpu/host1x/Makefile
@@ -13,6 +13,6 @@ host1x-y = \
 ccflags-y += -Iinclude/drm
 ccflags-$(CONFIG_DRM_TEGRA_DEBUG) += -DDEBUG
 
-host1x-$(CONFIG_DRM_TEGRA) += drm/drm.o drm/fb.o drm/dc.o drm/host1x.o
+host1x-$(CONFIG_DRM_TEGRA) += drm/drm.o drm/fb.o drm/dc.o
 host1x-$(CONFIG_DRM_TEGRA) += drm/output.o drm/rgb.o drm/hdmi.o
 obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 9689724..8ce9889 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -32,6 +32,19 @@
 #include "channel.h"
 #include "debug.h"
 #include "hw/host1x01.h"
+#include "host1x_client.h"
+
+void host1x_set_drm_data(struct device *dev, void *data)
+{
+   struct host1x *host1x = dev_get_drvdata(dev);
+   host1x->drm_data = data;
+}
+
+void *host1x_get_drm_data(struct device *dev)
+{
+   struct host1x *host1x = dev_get_drvdata(dev);
+   return host1x->drm_data;
+}
 
 void host1x_sync_writel(struct host1x *host1x, u32 v, u32 r)
 {
@@ -150,6 +163,8 @@ static int host1x_probe(struct platform_device *pdev)
 
host1x_debug_init(host);
 
+   host1x_drm_alloc(pdev);
+
return 0;
 
 fail_deinit_syncpt:
@@ -168,7 +183,7 @@ static int __exit host1x_remove(struct platform_device 
*pdev)
return 0;
 }
 
-static struct platform_driver platform_driver = {
+static struct platform_driver tegra_host1x_driver = {
.probe = host1x_probe,
.remove = __exit_p(host1x_remove),
.driver = {
@@ -178,8 +193,47 @@ static struct platform_driver platform_driver = {
},
 };
 
-module_platform_driver(platform_driver);
+static int __init tegra_host1x_init(void)
+{
+   int err;
+
+   err = platform_driver_register(&tegra_host1x_driver);
+   if (err < 0)
+   return err;
+
+#ifdef CONFIG_DRM_TEGRA
+   err = platform_driver_register(&tegra_dc_driver);
+   if (err < 0)
+   goto unregister_host1x;
+
+   err = platform_driver_register(&tegra_hdmi_driver);
+   if (err < 0)
+   goto unregister_dc;
+#endif
+
+   return 0;
+
+#ifdef CONFIG_DRM_TEGRA
+unregister_dc:
+   platform_driver_unregister(&tegra_dc_driver);
+unregister_host1x:
+   platform_driver_unregister(&tegra_host1x_driver);
+   return err;
+#endif
+}
+module_init(tegra_host1x_init);
+
+static void __exit tegra_host1x_exit(void)
+{
+#ifdef CONFIG_DRM_TEGRA
+   platform_driver_unregister(&tegra_hdmi_driver);
+   platform_driver_unregister(&tegra_dc_driver);
+#endif
+   platform_driver_unregister(&tegra_host1x_driver);
+}
+module_exit(tegra_host1x_exit);
 
+MODULE_AUTHOR("Thierry Reding ");
 MODULE_AUTHOR("Terje Bergstrom ");
 MODULE_DESCRIPTION("Host1x driver for Tegra products");
 MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index 4d16fe9..a1607d6 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -124,6 +124,8 @@ struct host1x {
unsigned int num_allocated_channels;
 
struct dentry *debugfs;
+
+   void *drm_data;
 };
 
 void host1x_sync_writel(struct host1x *host1x, u32 r, u32 v);
@@ -299,4 +301,8 @@ static inline void host1x_hw_show_mlocks(struct host1x 
*host, struct output *o)
host->debug_op->show_mlocks(host, o);
 }
 
+extern struct platform_driver tegra_hdmi_driver;
+extern struct platform_driver tegra_dc_driver;
+extern struct platform_driver tegra_gr2d_driver;
+
 #endif
diff --git a/drivers/gpu/host1x/drm/Kconfig b/drivers/gpu/host1x/drm/Kconfig
index be1daf7..7db9b3a 100644
--- a/drivers/gpu/host1x/drm/Kconfig
+++ b/drivers/gpu/host1x/drm/Kconfig
@@ -1,5 +1,5 @@
 config DRM_TEGRA
-   tristate "NVIDIA Tegra DRM"
+   bool "NVIDIA Tegra DRM"
depends on DRM && OF && ARCH_TEGRA
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
diff --git a/drivers/gpu/host1x/drm/dc.c b/drivers/gpu/host1x/drm/dc.c
index d1f6609..29a79b6 100644
--- a/drivers/gpu/hos

Re: [PATCH 02/10] mm: vmscan: Obey proportional scanning requirements for kswapd

[Mel Gorman]

On Fri, Mar 22, 2013 at 08:54:27AM +0100, Michal Hocko wrote:
> On Thu 21-03-13 15:34:42, Mel Gorman wrote:
> > On Thu, Mar 21, 2013 at 04:07:55PM +0100, Michal Hocko wrote:
> > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > > > > index 4835a7a..182ff15 100644
> > > > > > --- a/mm/vmscan.c
> > > > > > +++ b/mm/vmscan.c
> > > > > > @@ -1815,6 +1815,45 @@ out:
> > > > > > }
> > > > > >  }
> > > > > >  
> > > > > > +static void recalculate_scan_count(unsigned long nr_reclaimed,
> > > > > > +   unsigned long nr_to_reclaim,
> > > > > > +   unsigned long nr[NR_LRU_LISTS])
> > > > > > +{
> > > > > > +   enum lru_list l;
> > > > > > +
> > > > > > +   /*
> > > > > > +* For direct reclaim, reclaim the number of pages requested. 
> > > > > > Less
> > > > > > +* care is taken to ensure that scanning for each LRU is 
> > > > > > properly
> > > > > > +* proportional. This is unfortunate and is improper aging but
> > > > > > +* minimises the amount of time a process is stalled.
> > > > > > +*/
> > > > > > +   if (!current_is_kswapd()) {
> > > > > > +   if (nr_reclaimed >= nr_to_reclaim) {
> > > > > > +   for_each_evictable_lru(l)
> > > > > > +   nr[l] = 0;
> > > > > > +   }
> > > > > > +   return;
> > > > > 
> > > > > Heh, this is nicely cryptically said what could be done in 
> > > > > shrink_lruvec
> > > > > as
> > > > >   if (!current_is_kswapd()) {
> > > > >   if (nr_reclaimed >= nr_to_reclaim)
> > > > >   break;
> > > > >   }
> > > > > 
> > > > 
> > > > Pretty much. At one point during development, this function was more
> > > > complex and it evolved into this without me rechecking if splitting it
> > > > out still made sense.
> > > > 
> > > > > Besides that this is not memcg aware which I think it would break
> > > > > targeted reclaim which is kind of direct reclaim but it still would be
> > > > > good to stay proportional because it starts with DEF_PRIORITY.
> > > > > 
> > > > 
> > > > This does break memcg because it's a special sort of direct reclaim.
> > > > 
> > > > > I would suggest moving this back to shrink_lruvec and update the test 
> > > > > as
> > > > > follows:
> > > > 
> > > > I also noticed that we check whether the scan counts need to be
> > > > normalised more than once
> > > 
> > > I didn't mind this because it "disqualified" at least one LRU every
> > > round which sounds reasonable to me because all LRUs would be scanned
> > > proportionally.
> > 
> > Once the scan count for one LRU is 0 then min will always be 0 and no
> > further adjustment is made. It's just redundant to check again.
> 
> Hmm, I was almost sure I wrote that min should be adjusted only if it is >0
> in the first loop but it is not there...
> 
> So for real this time.
>   for_each_evictable_lru(l)
>   if (nr[l] && nr[l] < min)
>   min = nr[l];
> 
> This should work, no? Everytime you shrink all LRUs you and you have
> reclaimed enough already you get the smallest LRU out of game. This
> should keep proportions evenly.

Lets say we started like this

LRU_INACTIVE_ANON 60
LRU_ACTIVE_FILE 1000
LRU_INACTIVE_FILE   3000

and we've reclaimed nr_to_reclaim pages then we recalculate the number
of pages to scan from each list as;

LRU_INACTIVE_ANON 0
LRU_ACTIVE_FILE 940
LRU_INACTIVE_FILE  2940

We then shrink SWAP_CLUSTER_MAX from each LRU giving us this.

LRU_INACTIVE_ANON 0
LRU_ACTIVE_FILE 908
LRU_INACTIVE_FILE  2908

Then under your suggestion this would be recalculated as

LRU_INACTIVE_ANON 0
LRU_ACTIVE_FILE   0
LRU_INACTIVE_FILE  2000

another SWAP_CLUSTER_MAX reclaims and then it stops we stop reclaiming. I
might still be missing the point of your suggestion but I do not think it
would preserve the proportion of pages we reclaim from the anon or file LRUs.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gpio: palmas: add in GPIO support for palmas charger

[Ian Lartey]

On 22/03/13 07:55, Linus Walleij wrote:

On Tue, Feb 26, 2013 at 3:14 PM, Laxman Dewangan  wrote:


On Tuesday 26 February 2013 07:43 PM, Ian Lartey wrote:
On 26/02/13 13:58, Laxman Dewangan wrote:

On Tuesday 26 February 2013 06:51 PM, Ian Lartey wrote:

this patch depenfs on [PATCH] mfd: palmas: is_palmas_charger needed by
multiple drivers

Palmas charger has 16 GPIOs
add palmas_gpio_[read|write|update] api to take account
second bank of GPIOs

Signed-off-by: Ian Lartey 
Signed-off-by: Graeme Gregory 


Is something happening in this series?

I'm ignoring it for now since the last activity in the thread was
some concerns from Laxman.

Yours,
Linus Walleij



Yes there's going to be an patch series update [v9] posted today.


Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] Adds support for Open Firmware in MAX730x GPIO Driver

[Linus Walleij]

On Tue, Mar 5, 2013 at 4:26 PM, Christophe Leroy
 wrote:

> This patch allows the use of the MAX730x Driver on systems using
> the Open Firmware platform format.
> The bit_per_word can be set in the OF Device tree, so no need to force it as 
> with
> the platform_data.
>
> Signed-off-by: Patrick Vasseur 
> Signed-off-by: Christophe Leroy 

I tried applying this but it fails. Can you send based on e.g.
v3.9-rc3 or so?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout

[Roger Quadros]

Hi Frank,

On 03/22/2013 04:45 AM, Frank Rowand wrote:
> On 03/21/13 07:41, Alan Stern wrote:
>> On Wed, 20 Mar 2013, Frank Rowand wrote:
>>
>>> Hi All,
>>>
>>> Not quite sure quite where the problem is (USB, OMAP, smsc95xx driver, 
>>> other???),
>>> so casting the nets wide...
>>>
>>> The PandaBoard frequently fails to boot with an eth0 error when mounting
>>> the root file system via NFS (ethernet driver fails due to a USB timeout;
>>> no ethernet means NFS won't work).  A typical set of error messages is:
>>>
>>> [3.264373] smsc95xx 1-1.1:1.0: usb_probe_interface
>>> [3.269500] smsc95xx 1-1.1:1.0: usb_probe_interface - got id
>>> [3.275543] smsc95xx v1.0.4
>>> [8.078674] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at 
>>> usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 82:b9:1d:fa:67:0d
>>> [8.091003] hub 1-1:1.0: state 7 ports 5 chg  evt 0002
>>> [   13.509918] usb 1-1.1: swapper/0 timed out on ep0out len=0/4
>>> [   13.515869] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 
>>> 0x0108
>>> [   13.523559] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110
>>> [   13.529998] IP-Config: Failed to open eth0
>>>
>>> I have bisected this to:
>>>
>>>   commit 18aafe64d75d0e27dae206cacf4171e4e485d285
>>>   Author: Alan Stern 
>>>   Date:   Wed Jul 11 11:23:04 2012 -0400
>>>
>>>  USB: EHCI: use hrtimer for the I/O watchdog
>>
>> I don't understand how that commit could cause a timeout unless there 
>> are at least two other bugs present in your system.
>>
>>> Note that to compile this version of the kernel, an additional fix must
>>> also be applied:
>>>
>>>   commit ba5952e0711b14d8d4fe172671f8aa6091ace3ee
>>>   Author: Ming Lei 
>>>   Date:   Fri Jul 13 17:25:24 2012 +0800
>>>
>>>  USB: ehci-omap: fix compile failure(v1)
>>>
>>> The symptom can be worked around by retrying the USB access if a timeout
>>> occurs.  This is clearly _not_ the fix, just a hack that I used to
>>> investigate the problem:
>>>
>>>   http://article.gmane.org/gmane.linux.rt.user/9773
>>>
>>> My kernel configuration is:
>>>
>>>   arch/arm/configs/omap2plus_defconfig
>>>
>>>   plus to get the ethernet driver I add:
>>>
>>> CONFIG_USB_EHCI_HCD
>>> CONFIG_USB_NET_SMSC95XX
>>>
>>> I found the problem on 3.6.11, but have not replicated it on 3.9-rcX
>>> yet because my config fails to build on 3.9-rc1 and 3.9-rc2.  I'll try
>>> to work on that issue tomorrow.
>>
>> Let me know how it works out.
> 
> My PandaBoard builds fail on 3.9-rcX due to ARM multiplatform issues.
> Either there is something I need to change about the way I build it,
> or it is broken (that is a side issue).  My simple expedient was to
> hack around multiplatform, and just make it build (patch below if
> anyone else wants a _temporary_ hack).

This is a known issue and will be resolved the proper way in 3.10.
For 3.9 you could also use a temporary fix posted here

http://thread.gmane.org/gmane.linux.usb.general/82693/

> 
> The problem appears to not be present in 3.9-rc3.  In older kernel versions, 
> the worst case to see the problem was 18 boots.  For 3.9-rc3 I booted 42
> times without seeing the problem.

This is good to hear.

> 
> The problem occurs at least up through 3.8.  I'll try to reverse bisect
> between 3.8 and 3.9-rc3 to see when the problem disappeared (I'm running
> short of time, so no promises for a near term result).

Thanks for the tests. There were a lot of OMAP EHCI related cleanup/fixes [1]
that went into 3.9. It would be interesting to know what fixed it.

[1] - https://lkml.org/lkml/2013/1/23/155

cheers,
-roger


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch v5 06/15] sched: log the cpu utilization at rq

[Alex Shi]

On 02/20/2013 11:22 PM, Peter Zijlstra wrote:
> On Wed, 2013-02-20 at 22:33 +0800, Alex Shi wrote:
>>> You don't actually compute the rq utilization, you only compute the
>>> utilization as per the fair class, so if there's significant RT
>> activity
>>> it'll think the cpu is under-utilized, whihc I think will result in
>> the
>>> wrong thing.
>>
>> yes. A bit complicit to resolve this. Any suggestions on this, guys?
> 
> Shouldn't be too hard seeing as we already track cpu utilization for !
> fair usage; see rq::rt_avg and scale_rt_power.
> 

Hi Peter,

rt_avg will be accumulated the irq time and steal time in
update_rq_clock_task(), if CONFIG_IRQ_TIME_ACCOUNTING or
CONFIG_IRQ_TIME_ACCOUNTING defined. That cause irq/steal time was double
added into rq utilisation, since normal rq->util already include the irq
time. So we do wrongly judgement to think it is a overload cpu. but it
is not.

To resolve this issue, if is it possible to introduce another member in
rq to describe rt_avg non irq/steal beside the rt_avg? If so, what the
name do you like to use?

-- 
Thanks Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-next] Not able to fetch next-20130321

[Axel Lin]

2013/3/22 Stephen Rothwell :
> Hi Axel,
>
> On Thu, 21 Mar 2013 22:50:18 +0800 Axel Lin  wrote:
>>
>> I run "git remote update" but cannot find next-20130321 tag.
>> It seems the latest tag is "next-20130318".
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/
>
> It seems to have come good by the time I had a look.  And I am pretty
> sure that people had downloaded next-20130320 ok.

Even with a fresh git clone, it still shows the latest commit is 20130318.

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

git log shows the latest commit is:
commit 0e78c0989334e9c1d578ba25621de14e8441d8b4
Author: Stephen Rothwell 
Date:   Mon Mar 18 16:10:47 2013 +1100

Add linux-next specific files for 20130318

Signed-off-by: Stephen Rothwell 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC 0/2] PCI: Introduce MSI chip infrastructure

[Thierry Reding]

This pair of patches introduces a new MSI chip infrastructure aimed at
replacing the current per-architecture implementation of the MSI support
functions. The rationale being that for multi-platform support on ARM
(and of course other architectures as well) per-architecture hooks no
longer work, given that more than one implementation will be provided.

The approach chosen in this patch series is to introduce a new structure
called struct msi_chip that contains pointers to the functions that have
previously been implemented on a per-architecture basis. A pointer to
this structure is embedded with each struct pci_bus, similar to struct
pci_ops, and automatically passed to child busses during enumeration. It
is the responsibility of the PCI host bridge driver to setup the MSI
chip for the root bus.

An example for the usage of this new infrastructure is provided in the
second patch, which implements this for the Tegra PCIe controller
driver. Note that this driver has not been merged yet because this MSI
infrastructure is a prerequisite. Nevertheless it should serve as a
reference for implementors on how to use the MSI chip.

Thierry

Thierry Reding (2):
  PCI: Introduce new MSI chip infrastructure
  PCI: tegra: Use new MSI chip infrastructure

 drivers/pci/host/pci-tegra.c | 105 ---
 drivers/pci/msi.c|  35 +--
 drivers/pci/probe.c  |   1 +
 include/linux/msi.h  |  10 +
 include/linux/pci.h  |   1 +
 5 files changed, 103 insertions(+), 49 deletions(-)

-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC 2/2] PCI: tegra: Use new MSI chip infrastructure

[Thierry Reding]

Implement an MSI chip that uses the Tegra PCIe controller's built-in
support to provide MSI services to the root bus and its children.

Signed-off-by: Thierry Reding 
---
 drivers/pci/host/pci-tegra.c | 105 ---
 1 file changed, 60 insertions(+), 45 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 1efd746..19c250f 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -183,14 +183,20 @@
 #define  PADS_PLL_CTL_TXCLKREF_DIV10   (0 << 20)
 #define  PADS_PLL_CTL_TXCLKREF_DIV5(1 << 20)
 
-struct tegra_pcie_msi {
+struct tegra_msi {
DECLARE_BITMAP(used, INT_PCI_MSI_NR);
struct irq_domain *domain;
+   struct msi_chip chip;
unsigned long pages;
struct mutex lock;
int irq;
 };
 
+static inline struct tegra_msi *to_tegra_msi(struct msi_chip *chip)
+{
+   return container_of(chip, struct tegra_msi, chip);
+}
+
 struct tegra_pcie {
struct device *dev;
 
@@ -211,7 +217,7 @@ struct tegra_pcie {
struct clk *pcie_xclk;
struct clk *pll_e;
 
-   struct tegra_pcie_msi msi;
+   struct tegra_msi msi;
 
struct list_head ports;
unsigned int num_ports;
@@ -605,6 +611,9 @@ static struct pci_bus *tegra_pcie_scan_bus(int nr, struct 
pci_sys_data *sys)
if (!bus)
return NULL;
 
+   if (IS_ENABLED(CONFIG_PCI_MSI))
+   bus->msi = &pcie->msi.chip;
+
pci_scan_child_bus(bus);
 
return bus;
@@ -1001,38 +1010,41 @@ static int tegra_pcie_put_resources(struct tegra_pcie 
*pcie)
return 0;
 }
 
-static int tegra_pcie_msi_alloc(struct tegra_pcie *pcie)
+static int tegra_msi_alloc(struct tegra_msi *chip)
 {
int msi;
 
-   mutex_lock(&pcie->msi.lock);
+   mutex_lock(&chip->lock);
 
-   msi = find_first_zero_bit(pcie->msi.used, INT_PCI_MSI_NR);
+   msi = find_first_zero_bit(chip->used, INT_PCI_MSI_NR);
if (msi < INT_PCI_MSI_NR)
-   set_bit(msi, pcie->msi.used);
+   set_bit(msi, chip->used);
else
msi = -ENOSPC;
 
-   mutex_unlock(&pcie->msi.lock);
+   mutex_unlock(&chip->lock);
 
return msi;
 }
 
-static void tegra_pcie_msi_free(struct tegra_pcie *pcie, unsigned long irq)
+static void tegra_msi_free(struct tegra_msi *chip, unsigned long irq)
 {
-   mutex_lock(&pcie->msi.lock);
+   struct device *dev = chip->chip.dev;
+
+   mutex_lock(&chip->lock);
 
-   if (!test_bit(irq, pcie->msi.used))
-   dev_err(pcie->dev, "trying to free unused MSI#%lu\n", irq);
+   if (!test_bit(irq, chip->used))
+   dev_err(dev, "trying to free unused MSI#%lu\n", irq);
else
-   clear_bit(irq, pcie->msi.used);
+   clear_bit(irq, chip->used);
 
-   mutex_unlock(&pcie->msi.lock);
+   mutex_unlock(&chip->lock);
 }
 
 static irqreturn_t tegra_pcie_msi_irq(int irq, void *data)
 {
struct tegra_pcie *pcie = data;
+   struct tegra_msi *msi = &pcie->msi;
unsigned int i;
 
for (i = 0; i < 8; i++) {
@@ -1046,9 +1058,9 @@ static irqreturn_t tegra_pcie_msi_irq(int irq, void *data)
/* clear the interrupt */
afi_writel(pcie, 1 << offset, AFI_MSI_VEC0 + i * 4);
 
-   irq = irq_find_mapping(pcie->msi.domain, index);
+   irq = irq_find_mapping(msi->domain, index);
if (irq) {
-   if (test_bit(index, pcie->msi.used))
+   if (test_bit(index, msi->used))
generic_handle_irq(irq);
else
dev_info(pcie->dev, "unhandled MSI\n");
@@ -1068,20 +1080,20 @@ static irqreturn_t tegra_pcie_msi_irq(int irq, void 
*data)
return IRQ_HANDLED;
 }
 
-#ifdef CONFIG_PCI_MSI
-/* called by arch_setup_msi_irqs in drivers/pci/msi.c */
-int arch_setup_msi_irq(struct pci_dev *pdev, struct msi_desc *desc)
+static int tegra_msi_setup_irq(struct msi_chip *chip, struct pci_dev *pdev,
+  struct msi_desc *desc)
 {
-   struct tegra_pcie *pcie = sys_to_pcie(pdev->bus->sysdata);
+   struct tegra_msi *msi = to_tegra_msi(chip);
+   struct tegra_pcie *pcie = container_of(chip, struct tegra_pcie, 
msi.chip);
struct msi_msg msg;
unsigned int irq;
int hwirq;
 
-   hwirq = tegra_pcie_msi_alloc(pcie);
+   hwirq = tegra_msi_alloc(msi);
if (hwirq < 0)
return hwirq;
 
-   irq = irq_create_mapping(pcie->msi.domain, hwirq);
+   irq = irq_create_mapping(msi->domain, hwirq);
if (!irq)
return -EINVAL;
 
@@ -1097,16 +1109,15 @@ int arch_setup_msi_irq(struct pci_dev *pdev, struct 
msi_desc *desc)
return 0;
 }
 
-void arch_teardown_msi_irq(unsigned in

[RFC 1/2] PCI: Introduce new MSI chip infrastructure

[Thierry Reding]

The new struct msi_chip is used to associated an MSI controller with a
PCI bus. It is automatically handed down from the root to its children
during bus enumeration.

This patch provides default (weak) implementations for the architecture-
specific MSI functions (arch_setup_msi_irq(), arch_teardown_msi_irq()
and arch_msi_check_device()) which check if a PCI device's bus has an
attached MSI chip and forward the call appropriately.

Signed-off-by: Thierry Reding 
---
TODO:
- remove arch_msi_check_device (and other arch-specificities)
---
 drivers/pci/msi.c   | 35 +++
 drivers/pci/probe.c |  1 +
 include/linux/msi.h | 10 ++
 include/linux/pci.h |  1 +
 4 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 00cc78c..fce3549 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -26,14 +26,41 @@
 
 static int pci_msi_enable = 1;
 
-/* Arch hooks */
+int __weak arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
+{
+   struct msi_chip *chip = dev->bus->msi;
+
+   if (chip && chip->setup_irq) {
+   int err;
+
+   err = chip->setup_irq(chip, dev, desc);
+   if (err < 0)
+   return err;
+
+   irq_set_chip_data(desc->irq, chip);
+   return err;
+   }
+
+   return -EINVAL;
+}
 
-#ifndef arch_msi_check_device
-int arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+void __weak arch_teardown_msi_irq(unsigned int irq)
 {
+   struct msi_chip *chip = irq_get_chip_data(irq);
+
+   if (chip && chip->teardown_irq)
+   chip->teardown_irq(chip, irq);
+}
+
+int __weak arch_msi_check_device(struct pci_dev *dev, int nvec, int type)
+{
+   struct msi_chip *chip = dev->bus->msi;
+
+   if (chip && chip->check_device)
+   return chip->check_device(chip, dev, nvec, type);
+
return 0;
 }
-#endif
 
 #ifndef arch_setup_msi_irqs
 # define arch_setup_msi_irqs default_setup_msi_irqs
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b494066..9307550 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -634,6 +634,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus 
*parent,
 
child->parent = parent;
child->ops = parent->ops;
+   child->msi = parent->msi;
child->sysdata = parent->sysdata;
child->bus_flags = parent->bus_flags;
 
diff --git a/include/linux/msi.h b/include/linux/msi.h
index ce93a34..ea4a5be 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -58,5 +58,15 @@ extern int arch_setup_msi_irqs(struct pci_dev *dev, int 
nvec, int type);
 extern void arch_teardown_msi_irqs(struct pci_dev *dev);
 extern int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
 
+struct msi_chip {
+   struct module *owner;
+   struct device *dev;
+
+   int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
+struct msi_desc *desc);
+   void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
+   int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
+   int nvec, int type);
+};
 
 #endif /* LINUX_MSI_H */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2461033a..6aca43ea 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -416,6 +416,7 @@ struct pci_bus {
struct resource busn_res;   /* bus numbers routed to this bus */
 
struct pci_ops  *ops;   /* configuration access functions */
+   struct msi_chip *msi;   /* MSI controller */
void*sysdata;   /* hook for sys-specific extension */
struct proc_dir_entry *procdir; /* directory entry in /proc/bus/pci */
 
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 06/34] arc: Use generic idle loop

[Vineet Gupta]

Hi Thomas,

> On 03/22/2013 03:23 AM, Thomas Gleixner wrote:

While the ARC specific changes look simple enough, do you have the series put up
somewhere which I can merge to give a quick build/run test.

Are you planning to add this to linux-next at some point as that will make it
really trivial to test out.

Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] PM / devfreq: tie suspend/resume to runtime-pm

[Rajagopal Venkat]

On 21 March 2013 20:32, Alan Stern  wrote:
> On Thu, 21 Mar 2013, Rajagopal Venkat wrote:
>
>> Allow device devfreq to be suspend/resume automatically with
>> runtime pm suspend/resume. The devfreq drivers should be least
>> cared when to suspend/resume the devfreq.
>>
>> pm_runtime_suspend(dev) will first suspend device devfreq(if available)
>> before device is suspended from runtime pm core.
>>
>> pm_runtime_resume(dev) will resume device devfreq(if available) after
>> device is resumed from runtime pm core.
>
> Aren't these backward?  The device continues to need its clocks and
> frequency settings until _after_ it has been suspended.  Similarly, it
> needs them to be available _before_ it resumes.
>

To clarify, devfreq suspend/resume means suspend/resume of load
monitoring of a device. The clocks and other resources are still taken
care by the devfreq driver runtime-pm callbacks. The devfreq must be
suspended _before_ runtime-pm suspend callback in order to stop load
monitoring while device is suspending. Similarly devfreq resume should
happen _after_ runtime-pm resume callback.

Just realised both devfreq suspend/resume are done _before_ invoking
runtime-pm callbacks. I will fix this up. Thanks.


> Alan Stern
>



-- 
Regards,
Rajagopal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Intel-gfx] Regression: HSW eDP broken on 3.9-rc[12]

[Daniel Vetter]

On Thu, Mar 14, 2013 at 4:15 PM, Takashi Iwai  wrote:
> I noticed that a Haswell desktop machine with eDP gets only the blank
> screen on the latest Linus tree.  It works fine with 3.8, so it's a
> regression since 3.9-rc1.  Actually, it's not a regression.  It's
> three regressions in a shot! (I had to do painful bisections three
> times...)
>
> c464b2a17c59adedbdc02cc54341d630354edc3
> drm/i915: set TRANSCODER_EDP even earlier
>
> d6dd9eb1d96d2b7345fe4664066c2b7ed86da898
> drm/i915: dynamic Haswell display power well support
>
> commit cf0a6584aa6d382f802f2c3cacac23ccbccde0cd
> drm/i915: write backlight harder
>
>
> The first commit affects no matter whether power well is on or off.
> It brings the eDP output always blank.

Can you please attach the xrandr output and drm.debug=0xe dmesg from
booting for that hsw eDP machine quickly?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ath9k : Fix ieee80211 work while going to suspend

[Stanislaw Gruszka]

On Thu, Mar 21, 2013 at 12:33:31PM -0700, Luis R. Rodriguez wrote:
> So when does this work get called?
> 
> Given the trace this is hit when the timer rx_poll_timer runs,
> which in turn calls ath_rx_poll() to schedule hw_check_work work.
> The rx_poll_timer however was originally only set at the end of
> the routine that hw_check_work sets off but also at other entry
> points (ath_start_rx_poll() callers). Once ath_start_rx_poll()
> gets called though we can go on looping as follows:
> 
> work  timer   work
> hw_check_work --> rx_poll_timer   --> hw_check_work
>
> At suspend time we do this though:
> 
> ath_cancel_work(sc);
> del_timer_sync(&sc->rx_poll_timer);  
>  
> + del_timer_sync(&sc->rx_poll_timer);
>   ath_cancel_work(sc);
>   ath_stop_ani(sc);
> - del_timer_sync(&sc->rx_poll_timer);

[snip]

> But then we have the chicken and the egg problem, as the work item
> could fire off the timer so it would seem to be good to prevent
> adding new work when suspending.

Yup, this is egg and chicken problem, I think it can not be fixed by
changing ordering of del_timer and cancel_work, it would be like:

del_timer_sync(&sc->rx_poll_timer);
/* but timer could schedule work */
ath_cancel_work(sc);
/* but work could schedule timer */ 
del_timer_sync(&sc->rx_poll_timer);
/* but timer could schedule work */
ath_cancel_work(sc);
/* And so on ... */

Check is needed in work or timer callback, depending what is canceled
last, to fix the problem ...

> > In mac80211 we use local->suspended and local->quiesce booleans to
> > prevent reschedule of timers when going to suspend for example.
> > Works use ifmgd->associted to prevent reschedule when we are
> > disassociating.
> > 
> > I think on ath9k also some boolean variable should be used, not only
> > for rx_poll_timer but also for other works i.e. tx_complete_work.
> > Is possible to use SC_OP_INVALID flags, since mac80211 call ath9k_stop
> > on suspend and ath9k_start on resume.
> 
> Indeed however ieee80211_queue_work() already does a suspend check for
> us, it just complains as many drivers including mac80211 were setting
> up work incorrectly. The warning was put in place to help us find the
> issues. Using SC_OP_INVALID seems fair but we could also add a routine
> ieee80211_queue_work_safe() that silently fails if we are quiescing or
> suspended and not resuming but I can see that creating very sloppy
> driver writing and everyone abusing it.

We also have to reliable cancel works on ath9k_stop() if device goes
down for other reason than suspend, new mac80211 ieee80211_queue_work_safe()
routine will not help with that.

> OK how about this for stable for now:
> 
> diff --git a/drivers/net/wireless/ath/ath9k/link.c 
> b/drivers/net/wireless/ath/ath9k/link.c
> index 39c84ec..7fdac6c 100644
> --- a/drivers/net/wireless/ath/ath9k/link.c
> +++ b/drivers/net/wireless/ath/ath9k/link.c
> @@ -170,7 +170,8 @@ void ath_rx_poll(unsigned long data)
>  {
>   struct ath_softc *sc = (struct ath_softc *)data;
>  
> - ieee80211_queue_work(sc->hw, &sc->hw_check_work);
> + if (!test_bit(SC_OP_INVALID, &sc->sc_flags))
> + ieee80211_queue_work(sc->hw, &sc->hw_check_work);
>  }

That looks ok for me as -stable fix

Reviewed-by: Stanislaw Gruszka 

Stanislaw 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2, RFC 02/30] mm: implement zero_huge_user_segment and friends

[Kirill A. Shutemov]

Dave Hansen wrote:
> On 03/14/2013 10:50 AM, Kirill A. Shutemov wrote:
> > Let's add helpers to clear huge page segment(s). They provide the same
> > functionallity as zero_user_segment{,s} and zero_user, but for huge
> > pages
> ...
> > +static inline void zero_huge_user_segments(struct page *page,
> > +   unsigned start1, unsigned end1,
> > +   unsigned start2, unsigned end2)
> > +{
> > +   zero_huge_user_segment(page, start1, end1);
> > +   zero_huge_user_segment(page, start2, end2);
> > +}
> 
> I'm not sure that this helper saves very much code.  The one call later
> in these patches:
> 
> +   zero_huge_user_segments(page, 0, from,
> +   from + len, HPAGE_PMD_SIZE);
> 
> really only saves one line over this:
> 
>   zero_huge_user_segment(page, 0, from);
>   zero_huge_user_segment(page, from + len,
>  HPAGE_PMD_SIZE);
> 
> and I think the second one is much more clear to read.

I've tried to mimic non-huge zero_user*, but, yeah, this is silly.
Will drop.

> I do see that there's a small-page variant of this, but I think that one
> was done to save doing two kmap_atomic() operations when you wanted to
> zero two separate operations.  This variant doesn't have that kind of
> optimization, so it makes much less sense.
> 
> > +void zero_huge_user_segment(struct page *page, unsigned start, unsigned 
> > end)
> > +{
> > +   int i;
> > +   
> > +   BUG_ON(end < start);
> > +
> > +   might_sleep();
> > +
> > +   if (start == end)
> > +   return;
> 
> I've really got to wonder how much of an optimization this is in
> practice.  Was there a specific reason this was added?

It's likely for simple_write_begin() to call zero[_huge]_user_segments()
with one of two segments start == end.

But, honestly, it was just easier to cut the corner case first and don't
bother about it in following code. ;)

> > +   /* start and end are on the same small page */
> > +   if ((start & PAGE_MASK) == ((end - 1) & PAGE_MASK))
> > +   return zero_user_segment(page + (start >> PAGE_SHIFT),
> > +   start & ~PAGE_MASK,
> > +   ((end - 1) & ~PAGE_MASK) + 1);
> 
> It wasn't immediately obvious to me why we need to optimize the "on the
> same page" case.  I _think_ it's because using zero_user_segments()
> saves us a kmap_atomic() over the code below.  Is that right?  It might
> be worth a comment.

The code below will call zero_user_segment() twice for the same small
page, but here we can use just one.

I'll document it.

> > +   zero_user_segment(page + (start >> PAGE_SHIFT),
> > +   start & ~PAGE_MASK, PAGE_SIZE);
> > +   for (i = (start >> PAGE_SHIFT) + 1; i < (end >> PAGE_SHIFT) - 1; i++) {
> > +   cond_resched();
> > +   clear_highpage(page + i);
> 
> zero_user_segments() does a flush_dcache_page(), which wouldn't get done
> on these middle pages.  Is that a problem?

I think, it is. Will fix.

> > +   }
> > +   zero_user_segment(page + i, 0, ((end - 1) & ~PAGE_MASK) + 1);
> > +}
> 
> This code is dying for some local variables.  It could really use a
> 'start_pfn_offset' and 'end_pfn_offset' or something similar.  All of
> the shifting and masking is a bit hard to read and it would be nice to
> think of some real names for what it is doing.
> 
> It also desperately needs some comments about how it works.  Some
> one-liners like:
> 
>   /* zero the first (possibly partial) page */
>   for()..
>   /* zero the full pages in the middle */
>   /* zero the last (possibly partial) page */
> 
> would be pretty sweet.

Okay, will rework it.

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 5/6] ARM: dts: omap: update usb_otg_hs data

[Kishon Vijay Abraham I]

Hi,

On Thursday 21 March 2013 10:40 PM, Stephen Warren wrote:

On 03/21/2013 12:23 AM, kishon wrote:

Hi,

On Thursday 21 March 2013 02:29 AM, Stephen Warren wrote:

On 03/20/2013 03:12 AM, Kishon Vijay Abraham I wrote:

Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
binding in order for the driver to use the new generic PHY framework.
Also updated the Documentation to include the binding information.



diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index abce256..3d6f9f6 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -19,6 +19,9 @@ OMAP MUSB GLUE
- power : Should be "50". This signifies the controller can supply
upto
  100mA when operating in host mode.
- usb-phy : the phandle for the PHY device
+ - phy : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs
present in the
+   *phy* phandle.


If the intent is for those properties to be generic and used by any DT
binding that refers to a PHY node, I think you'd want to define those
properties in e.g. Documentation/devicetree/bindings/phy/phy.txt, just
like common clock/GPIO/... properties are defined in standalone common
files.


Ok. Will add it.


I think you want to require that DT nodes that represent PHYs have a
#phy-cells property, and that the format of the phy property be
<&phy_phandle phy_specifier*>, where #phy-cells in the referenced node
defines how many cells are part of phy_specifier*, just like (almost)
any other DT property that references another node by phandle. That way,
if a single DT node represents a HW block that implements e.g. 3 PHYs,
it can use #phy-cells = <1>, and the referencing phy property can
include a cell that indicates which of those 3 PHYs is being referenced.


Currently, if a single phandle have reference to multiple PHYs, we can
get PHY by passing index or by name as give in phy-names.
I'm not sure if we have <&phy_phandle phy_specifier*>, what could that
phy_specifier be? Maybe phy_type?


I'm not talking about the case where a consumer node references multiple
PHYs. As you say, that is indeed handled by the driver looking at a
particular index in the phys property, or using phy-names.

I'm talking about the case where a single provider provides multiple
PHYs. For example, consider:

phys: phy {
 compatible = "xxx";
 reg = <...>;
 #phy-cells = <1>;
};

That node describes an IP block that implements 3 different PHYs. The
registers are inter-mixed in such a way that you can't split it into 3
separate nodes each with a separate device instance. If the consumers
simply say:

phys = <&phys>;

then which of the 3 PHYs are you referring to?

Instead, the consumer needs to say one of:

phys = <&phys 0>;
phys = <&phys 1>;
phys = <&phys 2>;

in order to specify which of the PHYs it refers to.

The number of cells in the phy property after the phandle is specified
by the #phy-cells property in the node referred to by the phandle. The
meaning of all those cells is defined by the binding for the phy node.
This could include both the PHY ID (as in my example here), or whatever
configuration information or flags the provider needs. For example, both
GPIOs and interrupts have specifiers than describe both of these things.


Thanks for the explanation. I'll add it in my next version.


For more background, take a look at almost any other binding that uses
phandles.

By the way, the property in the consumer should probably be "phys" not
"phy" to be consistent with other similar properties (e.g. gpios,
interrupts, ... which are all plural).


Ok.

Thanks
Kishon

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2 2/2] serial: of_serial: Handle fifo-size property

[Heikki Krogerus]

Hi,

On Fri, Mar 22, 2013 at 04:16:48PM +0800, Ley Foon Tan wrote:
> On Fri, 2013-03-22 at 10:05 +0200, Heikki Krogerus wrote:
> > This will reduce the need for extra types in 8250.c just
> > in case the fifo size differs from the standard.
> Besides the fifo size, we need to have hardware flow control setting
> from device tree as well.

This is a bit problematic. We can set the uart_8250_port.capabilities
flag UART_CAP_AFE based on "hw-flow-control" property, but then the
properties from the type will not be used, just like in case of
fifosize. We would need to know all the flags of the type that are
normally taken from the uart_config[] array.

The UART_CAP_FIFO can be set by checking if we have set the
port.fifosize or not, so if the bellow is acceptable then I can make a
patch. There is no risk of overriding the capabilities for the
existing uarts, as we only touch the uart_8250_port.capabilities if
the new properties are used. So is it OK?

diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
index 267711b..cc5135d 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -171,11 +171,16 @@ static int of_platform_serial_probe(struct 
platform_device *ofdev)
 #ifdef CONFIG_SERIAL_8250
case PORT_8250 ... PORT_MAX_8250:
{
-   /* For now the of bindings don't support the extra
-  8250 specific bits */
struct uart_8250_port port8250;
memset(&port8250, 0, sizeof(port8250));
port8250.port = port;
+
+   if (port.fifosize)
+   port8250.capabilities = UART_CAP_FIFO;
+
+   if (of_property_read_u32(np, "hw-flow-control", &prop) == 0)
+   port8250.capabilities |= UART_CAP_AFE;
+
ret = serial8250_register_8250_port(&port8250);
break;
}

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 02/34] arch: Consolidate tsk_is_polling()

[Thomas Gleixner]

On Fri, 22 Mar 2013, Tony Breeds wrote:

> On Thu, Mar 21, 2013 at 09:52:57PM -, Thomas Gleixner wrote:
>  
> > +/*
> > + * Idle thread specific functions to determine the need_resched
> > + * polling state. We have two versions, one based on TS_POLLING in
> > + * thread_info.status and one based on TIF_POLLING_NRFLAG in
> > + * thread_info.flags
> > + */
> > +#ifdef TS_POLLING
> > +static inline int tsk_is_polling(struct task_struct *p)
> > +{
> > +   return task_thread_info(p)->status & TS_POLLING;
> > +}
> > +#elif defined(TIF_POLLING_NRFLAG)
> > +static inline int tsk_is_polling(struct task_struct *p)
> > +{
> > +   test_tsk_thread_flag(p, TIF_POLLING_NRFLAG);
> > +}
> 
> On powerpc (at least) this is used before it's declared.  Also I think
> you're missing a 'return' in that function.

Mooo
 
> *cough* https://www.kernel.org/pub/tools/crosstool/ *cough*

Yes, I know. /me feels bad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PREEMPT_RT vs 'hrtimer: Prevent hrtimer_enqueue_reprogram race'

[Thomas Gleixner]

On Thu, 21 Mar 2013, Steven Rostedt wrote:

> On Fri, 2013-03-22 at 03:24 +, Ben Hutchings wrote:
> 
> > > Note, I posted a fix on Tuesday:
> > > 
> > > https://lkml.org/lkml/2013/3/19/369
> > 
> > Thanks.  I did search GMANE with some obvious terms but I think its
> > index is lagging.
> 
> It didn't help that my subject had no mention of -rt in it :-(
> 
> > I'm rebasing the rt patch series generated with
> > 'git format-patch v3.2.39..v3.2.39-rt59-rebase' on top of v3.2.41 (plus
> > Debian changes, which introduce some trivial textual conflicts).
> 
> Ah, OK, I do it the opposite way. As the stable rt git never rebases, I
> always merge the latest stable into my tree. I then create a rebased
> tree as well. When I do that, I'm sure I'll end up fixing the patches up
> pretty much the same as you have.

Looks correct. The fixup is pretty obvious.

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 0/2] PCI: Introduce MSI chip infrastructure

[Andrew Murray]

On Fri, Mar 22, 2013 at 08:51:45AM +, Thierry Reding wrote:
> It
> is the responsibility of the PCI host bridge driver to setup the MSI
> chip for the root bus.

I think this could work well. In the future if the use of an independent MSI
controller is required, then new DT bindings for host-bridges could use
phandles to reference independent MSI controllers as their providers of
MSIs. I guess this functionality can be built on top of what you have proposed
later as the need arises.

Andrew Murray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] i2c: tegra: check the clk_prepare_enable() return value

[Wolfram Sang]

On Fri, Mar 15, 2013 at 09:04:08PM +0530, Laxman Dewangan wrote:
> NVIDIA's Tegra SoC allows read/write of controller register only
> if controller clock is enabled. System hangs if read/write happens
> to registers without enabling clock.
> 
> clk_prepare_enable() can be fail due to unknown reason and hence
> adding check for return value of this function. If this function
> success then only access register otherwise return to caller with
> error.
> 
> Signed-off-by: Laxman Dewangan 

Applied to for-current, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] sysfs: fix race between readdir and lseek

[Ming Lei]

On Fri, Mar 22, 2013 at 1:48 PM, Li Zefan  wrote:
> On 2013/3/21 12:48, Ming Lei wrote:
>
> Yes, it can...As I said, it's irrelevant, because it's vfs that changes
> file->f_pos.
>
> SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
> {
> struct fd f = fdget(fd);
> ssize_t ret = -EBADF;
>
> if (f.file) {
> loff_t pos = file_pos_read(f.file); <--- read 
> f_pos
> ret = vfs_read(f.file, buf, count, &pos);   <--- return 
> -EISDIR
> file_pos_write(f.file, pos);<--- write 
> f_pos

Considered that f_pos of sysfs directory is always less than INT_MAX,
we need't worry about atomic writing it in file_pos_write().

The only probable problem on sysfs is below scenario in read()/write():

-  pos is read as less than 2 in file_pos_read(f.file)
-  ret = vfs_read(f.file, buf, count, &pos)
  ---> readdir() in another path
-  file_pos_write(pos)
 ---> readdir() found f_pos becomes 0 or 1, and may cause
use-after-free problem

Considered that vfs_read()/vfs_write on sysfs dir is almost doing nothing, the
above problem may only exist in theory. The patch[1] can't avoid it too.
I am wondering if it need to be fixed, but I will try to figure out how to
avoid it in sysfs_readdir() if possible.

[1], https://patchwork.kernel.org/patch/2160771/

Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()

[Michal Hocko]

On Fri 22-03-13 12:22:23, Glauber Costa wrote:
> On 03/22/2013 12:17 PM, Li Zefan wrote:
> >> GFP_TEMPORARY groups short lived allocations but the mem cache is not
> >> > an ideal candidate of this type of allocations..
> >> > 
> > I'm not sure I'm following you...
> > 
> > char *memcg_cache_name()
> > {
> > char *name = alloc();
> > return name;
> > }
> > 
> > kmem_cache_dup()
> > {
> > name = memcg_cache_name();
> > kmem_cache_create_memcg(name);
> > free(name);
> > }
> > 
> > Isn't this a short lived allocation?
> > 
> 
> Hi,
> 
> Thanks for identifying and fixing this.
> 
> Li is right. The cache name will live long, but this is because the
> slab/slub caches will strdup it internally. So the actual memcg
> allocation is short lived.

OK, I have totally missed that. Sorry about the confusion. Then all the
churn around the allocation is pointless, no?
What about:
---
>From 7ed7f53bb597e8cb40d9ac91ce16142fb60f1e93 Mon Sep 17 00:00:00 2001
From: Michal Hocko 
Date: Fri, 22 Mar 2013 10:22:54 +0100
Subject: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()

As cgroup supports rename, it's unsafe to dereference dentry->d_name
without proper vfs locks. Fix this by using cgroup_name() rather than
dentry directly.

Also open code memcg_cache_name because it is called only from
kmem_cache_dup which frees the returned name right after
kmem_cache_create_memcg makes a copy of it. Such a short-lived
allocation doesn't make too much sense. So replace it by a static
buffer as kmem_cache_dup is called with memcg_cache_mutex.

Signed-off-by: Li Zefan 
Signed-off-by: Michal Hocko 
---
 mm/memcontrol.c |   33 +++--
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 53b8201..9452b56 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3214,40 +3214,29 @@ void mem_cgroup_destroy_cache(struct kmem_cache *cachep)
schedule_work(&cachep->memcg_params->destroy);
 }
 
-static char *memcg_cache_name(struct mem_cgroup *memcg, struct kmem_cache *s)
-{
-   char *name;
-   struct dentry *dentry;
-
-   rcu_read_lock();
-   dentry = rcu_dereference(memcg->css.cgroup->dentry);
-   rcu_read_unlock();
-
-   BUG_ON(dentry == NULL);
-
-   name = kasprintf(GFP_KERNEL, "%s(%d:%s)", s->name,
-memcg_cache_id(memcg), dentry->d_name.name);
-
-   return name;
-}
-
+/*
+ * Called with memcg_cache_mutex held
+ */
 static struct kmem_cache *kmem_cache_dup(struct mem_cgroup *memcg,
 struct kmem_cache *s)
 {
char *name;
struct kmem_cache *new;
+   static char tmp_name[PAGE_SIZE];
 
-   name = memcg_cache_name(memcg, s);
-   if (!name)
-   return NULL;
+   lockdep_assert_held(&memcg_cache_mutex);
+
+   rcu_read_lock();
+   tmp_name = snprintf(tmp_name, sizeof(tmp_name), "%s(%d:%s)", s->name,
+memcg_cache_id(memcg), cgroup_name(memcg->css.cgroup));
+   rcu_read_unlock();
 
-   new = kmem_cache_create_memcg(memcg, name, s->object_size, s->align,
+   new = kmem_cache_create_memcg(memcg, tmp_name, s->object_size, s->align,
  (s->flags & ~SLAB_PANIC), s->ctor, s);
 
if (new)
new->allocflags |= __GFP_KMEMCG;
 
-   kfree(name);
return new;
 }
 
-- 
1.7.10.4


-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: BUG at kmem_cache_alloc

[David Rientjes]

On Fri, 22 Mar 2013, CAI Qian wrote:

> Starting to see those on 3.8.4 (never saw in 3.8.2) stable kernel on a few 
> systems
> during LTP run,
> 
> [11297.597242] BUG: unable to handle kernel paging request at 
> fffe 
> [11297.598022] IP: [] kmem_cache_alloc+0x68/0x1e0 

Is this repeatable?  Do you have CONFIG_SLAB or CONFIG_SLUB enabled?

> [11297.598022] PGD 7b9eb067 PUD 0  
> [11297.598022] Oops:  [#2] SMP  
> [11297.598022] Modules linked in: cmtp kernelcapi bnep scsi_transport_iscsi 
> rfcomm l2tp_ppp l2tp_netlink l2tp_core hidp ipt_ULOG af_key nfc rds pppoe 
> pppox ppp_generic slhc af_802154 atm ip6table_filter ip6_tables 
> iptable_filter ip_tables btrfs zlib_deflate vfat fat nfs_layout_nfsv41_files 
> nfsv4 auth_rpcgss nfsv3 nfs_acl nfsv2 nfs lockd sunrpc fscache nfnetlink_log 
> nfnetlink bluetooth rfkill arc4 md4 nls_utf8 cifs dns_resolver nf_tproxy_core 
> nls_koi8_u nls_cp932 ts_kmp sctp sg kvm_amd kvm virtio_balloon i2c_piix4 
> pcspkr xfs libcrc32c ata_generic pata_acpi cirrus drm_kms_helper ttm ata_piix 
> virtio_net drm libata virtio_blk i2c_core floppy dm_mirror dm_region_hash 
> dm_log dm_mod [last unloaded: ipt_REJECT] 
> [11297.598022] CPU 1  
> [11297.598022] Pid: 14134, comm: ltp-pan Tainted: G  D  3.8.4+ #1 
> Bochs Bochs 
> [11297.598022] RIP: 0010:[]  [] kmem_cache_alloc+0x68/0x1e0 
> [11297.598022] RSP: 0018:8800447dbdd0  EFLAGS: 00010246 
> [11297.598022] RAX:  RBX: 88007c169970 RCX: 
> 018acdcd 
> [11297.598022] RDX: 0006c104 RSI: 80d0 RDI: 
> 88007d04ac00 
> [11297.598022] RBP: 8800447dbe10 R08: 00017620 R09: 
> 810fe2e2 
> [11297.598022] R10:  R11:  R12: 
> fffe 
> [11297.598022] R13: 80d0 R14: 88007d04ac00 R15: 
> 88007d04ac00 
> [11297.598022] FS:  7f09c29b4740() GS:88007fd0() 
> knlGS:f74d86c0 
> [11297.598022] CS:  0010 DS:  ES:  CR0: 8005003b 
> [11297.598022] CR2: fffe CR3: 37213000 CR4: 
> 06e0 
> [11297.598022] DR0:  DR1:  DR2: 
>  
> [11297.598022] DR3:  DR6: 0ff0 DR7: 
> 0400 
> [11297.598022] Process ltp-pan (pid: 14134, threadinfo 8800447da000, task 
> 8800551ab2e0) 
> [11297.598022] Stack: 
> [11297.598022]  810fe2e2 8108cf0f 01200011 
> 88007c169970 
> [11297.598022]   7f09c29b4a10  
> 88007c169970 
> [11297.598022]  8800447dbe30 810fe2e2  
> 01200011 
> [11297.598022] Call Trace: 
> [11297.598022]  [] ? __delayacct_tsk_init+0x22/0x40 
> [11297.598022]  [] ? prepare_creds+0xdf/0x190 
> [11297.598022]  [] __delayacct_tsk_init+0x22/0x40 
> [11297.598022]  [] copy_process.part.25+0x31f/0x13f0 
> [11297.598022]  [] do_fork+0xa9/0x350 
> [11297.598022]  [] sys_clone+0x16/0x20 
> [11297.598022]  [] stub_clone+0x69/0x90 
> [11297.598022]  [] ? system_call_fastpath+0x16/0x1b 
> [11297.598022] Code: 90 4d 89 fe 4d 8b 06 65 4c 03 04 25 c8 db 00 00 49 8b 50 
> 08 4d 8b 20 4d 85 e4 0f 84 2b 01 00 00 49 63 46 20 4d 8b 06 41 f6 c0 0f <49> 
> 8b 1c 04 0f 85 55 01 00 00 48 8d 4a 01 4c 89 e0 65 49 0f c7  
> [11297.598022] RIP  [] kmem_cache_alloc+0x68/0x1e0 
> [11297.598022]  RSP  
> [11297.598022] CR2: fffe 
> [11297.727799] ---[ end trace 037bde72f23b34d2 ]---
> 
> Never saw this in mainline but only something like this wondering could be 
> related
> (that kmem_cache_alloc also in the trace).
> 

These are unrelated.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/2] PCI: Introduce new MSI chip infrastructure

[Andrew Murray]

On Fri, Mar 22, 2013 at 08:51:46AM +, Thierry Reding wrote:
> index ce93a34..ea4a5be 100644
> --- a/include/linux/msi.h
> +++ b/include/linux/msi.h
> @@ -58,5 +58,15 @@ extern int arch_setup_msi_irqs(struct pci_dev *dev, int 
> nvec, int type);
>  extern void arch_teardown_msi_irqs(struct pci_dev *dev);
>  extern int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
>  
> +struct msi_chip {
> + struct module *owner;
> + struct device *dev;
> +
> + int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> +  struct msi_desc *desc);
> + void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
> + int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
> + int nvec, int type);
> +};

Is there a need to add setup_irqs and teardown_irqs functions here? This will
allow your MSI chips to support multiple MSIs per requesting device.

What about restore_msi_irqs? Does this fit in here too?

Andrew Murray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 03/34] idle: Implement set/clr functions for need_resched poll

[James Hogan]

On 21/03/13 21:52, Thomas Gleixner wrote:
> Implement set/clear functions for the idle need_resched poll
> implementation.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  include/linux/sched.h |   23 ++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6/include/linux/sched.h
> ===
> --- linux-2.6.orig/include/linux/sched.h
> +++ linux-2.6/include/linux/sched.h
> @@ -2473,7 +2473,7 @@ static inline unsigned long *end_of_stac
>  #endif
>  
>  /*
> - * Idle thread specific functions to determine the need_resched
> + * Idle thread specific functions for the the need_resched
>   * polling state. We have two versions, one based on TS_POLLING in

s/the the/the/?

Cheers
James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH RESEND v2] of/pci: Provide support for parsing PCI DT ranges property

[Andrew Murray]

On Thu, Mar 21, 2013 at 04:06:25PM +, Thomas Petazzoni wrote:
> Dear Andrew Murray,
> 
> On Fri,  1 Mar 2013 12:23:36 +, Andrew Murray wrote:
> > This patch factors out common implementations patterns to reduce overall 
> > kernel
> > code and provide a means for host bridge drivers to directly obtain struct
> > resources from the DT's ranges property without relying on architecture 
> > specific
> > DT handling. This will make it easier to write archiecture independent host 
> > bridge
> > drivers and mitigate against further duplication of DT parsing code.
> > 
> > This patch can be used in the following way:
> > 
> > struct of_pci_range_iter iter;
> > for_each_of_pci_range(&iter, np) {
> > 
> > //directly access properties of the address range, e.g.:
> > //iter.pci_space, iter.pci_addr, iter.cpu_addr, iter.size or
> > //iter.flags
> > 
> > //alternatively obtain a struct resource, e.g.:
> > //struct resource res;
> > //range_iter_fill_resource(iter, np, res);
> > }
> > 
> > Additionally the implementation takes care of adjacent ranges and merges 
> > them
> > into a single range (as was the case with powerpc and microblaze).
> > 
> > The modifications to microblaze, mips and powerpc have not been tested.
> > 
> > v2:
> >   This follows on from suggestions made by Grant Likely
> >   (marc.info/?l=linux-kernel&m=136079602806328)
> > 
> > Signed-off-by: Andrew Murray 
> > Signed-off-by: Liviu Dudau 
> 
> Thanks, I've tested this successfully with the Marvell PCIe driver. I'm
> about to send a new version of the Marvell PCIe patch set that includes
> this RFC proposal.
> 
> I only made two small changes compared to your version, detailed below.

Thanks for the feedback, all looks good to me. Do I need to give ack?

Andrew Murray
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()

[Glauber Costa]

On 03/22/2013 01:31 PM, Michal Hocko wrote:
> On Fri 22-03-13 12:22:23, Glauber Costa wrote:
>> On 03/22/2013 12:17 PM, Li Zefan wrote:
 GFP_TEMPORARY groups short lived allocations but the mem cache is not
> an ideal candidate of this type of allocations..
>
>>> I'm not sure I'm following you...
>>>
>>> char *memcg_cache_name()
>>> {
>>> char *name = alloc();
>>> return name;
>>> }
>>>
>>> kmem_cache_dup()
>>> {
>>> name = memcg_cache_name();
>>> kmem_cache_create_memcg(name);
>>> free(name);
>>> }
>>>
>>> Isn't this a short lived allocation?
>>>
>>
>> Hi,
>>
>> Thanks for identifying and fixing this.
>>
>> Li is right. The cache name will live long, but this is because the
>> slab/slub caches will strdup it internally. So the actual memcg
>> allocation is short lived.
> 
> OK, I have totally missed that. Sorry about the confusion. Then all the
> churn around the allocation is pointless, no?
> What about:

If we're really not concerned about stack, then yes. Even if always
running from workqueues, a PAGE_SIZEd stack variable seems risky to me.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] hwrng: exynos - add CONFIG_PM_RUNTIME to suspend/resume functions

[David Rientjes]

On Fri, 22 Mar 2013, Jingoo Han wrote:

> Add CONFIG_PM_RUNTIME to suspend/resume functions to fix the build
> error. It is because UNIVERSAL_DEV_PM_OPS macro is related to both
> CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME.
> 
> drivers/char/hw_random/exynos-rng.c:167:8: error: 
> 'exynos_rng_runtime_suspend' undeclared here (not in a function)
> drivers/char/hw_random/exynos-rng.c:167:8: error: 'exynos_rng_runtime_resume' 
> undeclared here (not in a function)
> 
> Signed-off-by: Jingoo Han 
> Reported-by: David Rientjes 
> Cc: Herbert Xu 

Acked-by: David Rientjes 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2, RFC 04/30] radix-tree: implement preload for multiple contiguous elements

[Kirill A. Shutemov]

Dave Hansen wrote:
> On 03/14/2013 10:50 AM, Kirill A. Shutemov wrote:
> > From: "Kirill A. Shutemov" 
> > 
> > Currently radix_tree_preload() only guarantees enough nodes to insert
> > one element. It's a hard limit. You cannot batch a number insert under
> > one tree_lock.
> > 
> > This patch introduces radix_tree_preload_count(). It allows to
> > preallocate nodes enough to insert a number of *contiguous* elements.
> 
> You don't need to write a paper on how radix trees work, but it might be
> nice to include a wee bit of text in here about how the existing preload
> works, and how this new guarantee works.

Reasonable, will do.

> > diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
> > index ffc444c..81318cb 100644
> > --- a/include/linux/radix-tree.h
> > +++ b/include/linux/radix-tree.h
> > @@ -83,6 +83,8 @@ do {  
> > \
> > (root)->rnode = NULL;   \
> >  } while (0)
> >  
> > +#define RADIX_TREE_PRELOAD_NR  512 /* For THP's benefit */
> 
> This eventually boils down to making the radix_tree_preload array
> larger.  Do we really want to do this unconditionally if it's only for
> THP's benefit?

It will be useful not only for THP. Batching can be useful to solve
scalability issues.

> >  /**
> >   * Radix-tree synchronization
> >   *
> > @@ -231,6 +233,7 @@ unsigned long radix_tree_next_hole(struct 
> > radix_tree_root *root,
> >  unsigned long radix_tree_prev_hole(struct radix_tree_root *root,
> > unsigned long index, unsigned long max_scan);
> >  int radix_tree_preload(gfp_t gfp_mask);
> > +int radix_tree_preload_count(unsigned size, gfp_t gfp_mask);
> >  void radix_tree_init(void);
> >  void *radix_tree_tag_set(struct radix_tree_root *root,
> > unsigned long index, unsigned int tag);
> > diff --git a/lib/radix-tree.c b/lib/radix-tree.c
> > index e796429..9bef0ac 100644
> > --- a/lib/radix-tree.c
> > +++ b/lib/radix-tree.c
> > @@ -81,16 +81,24 @@ static struct kmem_cache *radix_tree_node_cachep;
> >   * The worst case is a zero height tree with just a single item at index 0,
> >   * and then inserting an item at index ULONG_MAX. This requires 2 new 
> > branches
> >   * of RADIX_TREE_MAX_PATH size to be created, with only the root node 
> > shared.
> > + *
> > + * Worst case for adding N contiguous items is adding entries at indexes
> > + * (ULONG_MAX - N) to ULONG_MAX. It requires nodes to insert single 
> > worst-case
> > + * item plus extra nodes if you cross the boundary from one node to the 
> > next.
> > + *
> >   * Hence:
> >   */
> > -#define RADIX_TREE_PRELOAD_SIZE (RADIX_TREE_MAX_PATH * 2 - 1)
> > +#define RADIX_TREE_PRELOAD_MIN (RADIX_TREE_MAX_PATH * 2 - 1)
> > +#define RADIX_TREE_PRELOAD_MAX \
> > +   (RADIX_TREE_PRELOAD_MIN + \
> > +DIV_ROUND_UP(RADIX_TREE_PRELOAD_NR - 1, RADIX_TREE_MAP_SIZE))
> >  
> >  /*
> >   * Per-cpu pool of preloaded nodes
> >   */
> >  struct radix_tree_preload {
> > int nr;
> > -   struct radix_tree_node *nodes[RADIX_TREE_PRELOAD_SIZE];
> > +   struct radix_tree_node *nodes[RADIX_TREE_PRELOAD_MAX];
> >  };
> 
> For those of us too lazy to go compile a kernel and figure this out in
> practice, how much bigger does this make the nodes[] array?

We have three possible RADIX_TREE_MAP_SHIFT:

#ifdef __KERNEL__
#define RADIX_TREE_MAP_SHIFT(CONFIG_BASE_SMALL ? 4 : 6)
#else
#define RADIX_TREE_MAP_SHIFT3   /* For more stressful testing */
#endif

On 64-bit system:
For RADIX_TREE_MAP_SHIFT=3, old array size is 43, new is 107.
For RADIX_TREE_MAP_SHIFT=4, old array size is 31, new is 63.
For RADIX_TREE_MAP_SHIFT=6, old array size is 21, new is 30.

On 32-bit system:
For RADIX_TREE_MAP_SHIFT=3, old array size is 21, new is 84.
For RADIX_TREE_MAP_SHIFT=4, old array size is 15, new is 46.
For RADIX_TREE_MAP_SHIFT=6, old array size is 11, new is 19.

On most machines we will have RADIX_TREE_MAP_SHIFT=6.

> 
> >  static DEFINE_PER_CPU(struct radix_tree_preload, radix_tree_preloads) = { 
> > 0, };
> >  
> > @@ -257,29 +265,34 @@ radix_tree_node_free(struct radix_tree_node *node)
> >  
> >  /*
> >   * Load up this CPU's radix_tree_node buffer with sufficient objects to
> > - * ensure that the addition of a single element in the tree cannot fail.  
> > On
> > - * success, return zero, with preemption disabled.  On error, return 
> > -ENOMEM
> > + * ensure that the addition of *contiguous* elements in the tree cannot 
> > fail.
> > + * On success, return zero, with preemption disabled.  On error, return 
> > -ENOMEM
> >   * with preemption not disabled.
> >   *
> >   * To make use of this facility, the radix tree must be initialised without
> >   * __GFP_WAIT being passed to INIT_RADIX_TREE().
> >   */
> > -int radix_tree_preload(gfp_t gfp_mask)
> > +int radix_tree_preload_count(unsigned size, gfp_t gfp_mask)
> >  {
> > struct radix_tree_preload *rtp;
> > struct radix

Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()

[Michal Hocko]

On Fri 22-03-13 13:41:40, Glauber Costa wrote:
> On 03/22/2013 01:31 PM, Michal Hocko wrote:
> > On Fri 22-03-13 12:22:23, Glauber Costa wrote:
> >> On 03/22/2013 12:17 PM, Li Zefan wrote:
>  GFP_TEMPORARY groups short lived allocations but the mem cache is not
> > an ideal candidate of this type of allocations..
> >
> >>> I'm not sure I'm following you...
> >>>
> >>> char *memcg_cache_name()
> >>> {
> >>>   char *name = alloc();
> >>>   return name;
> >>> }
> >>>
> >>> kmem_cache_dup()
> >>> {
> >>>   name = memcg_cache_name();
> >>>   kmem_cache_create_memcg(name);
> >>>   free(name);
> >>> }
> >>>
> >>> Isn't this a short lived allocation?
> >>>
> >>
> >> Hi,
> >>
> >> Thanks for identifying and fixing this.
> >>
> >> Li is right. The cache name will live long, but this is because the
> >> slab/slub caches will strdup it internally. So the actual memcg
> >> allocation is short lived.
> > 
> > OK, I have totally missed that. Sorry about the confusion. Then all the
> > churn around the allocation is pointless, no?
> > What about:
> 
> If we're really not concerned about stack, then yes. Even if always
> running from workqueues, a PAGE_SIZEd stack variable seems risky to me.

This is not on stack. It is static

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH RESEND v2] of/pci: Provide support for parsing PCI DT ranges property

[Thomas Petazzoni]

Andrew,

On Fri, 22 Mar 2013 09:39:36 +, Andrew Murray wrote:

> > Thanks, I've tested this successfully with the Marvell PCIe driver. I'm
> > about to send a new version of the Marvell PCIe patch set that includes
> > this RFC proposal.
> > 
> > I only made two small changes compared to your version, detailed below.
> 
> Thanks for the feedback, all looks good to me. Do I need to give ack?

If you could ack the version I sent in the PCIe patch set yesterday, it
would be great yes.

I'm hoping also that Grant will have a look at this and say if he
agrees. The entire PCIe patch set depends on this patch, so if any
rework of this OF patch needs to be done, it'd be great to know it
sooner rather than later.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] nohz1: Documentation

[Mats Liljegren]

Christoph Lameter wrote:
> On Thu, 21 Mar 2013, Paul E. McKenney wrote:
> 
> > > Yeah doing that right now but I'd like to see it handled without manual
> > > intervention.
> >
> > Given that RCU has no idea where you want them to run, some manual
> > intervention would most likely be required even if RCU spawned them
> > dynamically, right?
> 
> If rcuoXX is a SCHED_OTHER process/thread then the kernel will move it to
> another processor from the one running the SCHED_FIFO task. There would be
> no manual intervention required.
> 
> > So, again, removing scheduling-clock interrupts in more situations is
> > a good future enhancement.
> 
> The point here is that the check for a single runnable process is wrong
> because it accounts for tasks in all scheduling classes.
> 
> It would be better to check if there is only one runnable task in the
> highest scheduling class. That would work and defer the SCHED_OTHER kernel
> threads for the SCHED_FIFO thread.
> 
> I am wondering how you actually can get NOHZ to work right? There is
> always a kernel thread that is scheduled in a couple of ticks.

In my case I use 2 CPU PandaBoard where I use cpuset to create a
non-realtime domain for CPU0 and a real-time domain for CPU1. I then move
all kernel threads and IRQs to CPU0, leaving only the application specific
IRQ for CPU1. I then start a singe thread on CPU1.

I use a quite down-stripped version of Linux built using Yocto. I have run
the application for a minute and got 70-80 ticks, most (all?) occurring
during start and exit of the application. I use 100Hz ticks.

So personally I do get something by using full NOHZ in its current
incarnation. I'd like some better interrupt latency though, so disabling
 nohz-idle might be interesting for me. But that's another story...

-- Mats
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/2] PCI: Introduce new MSI chip infrastructure

[Thierry Reding]

On Fri, Mar 22, 2013 at 09:37:50AM +, Andrew Murray wrote:
> On Fri, Mar 22, 2013 at 08:51:46AM +, Thierry Reding wrote:
> > index ce93a34..ea4a5be 100644
> > --- a/include/linux/msi.h
> > +++ b/include/linux/msi.h
> > @@ -58,5 +58,15 @@ extern int arch_setup_msi_irqs(struct pci_dev *dev, int 
> > nvec, int type);
> >  extern void arch_teardown_msi_irqs(struct pci_dev *dev);
> >  extern int arch_msi_check_device(struct pci_dev* dev, int nvec, int type);
> >  
> > +struct msi_chip {
> > +   struct module *owner;
> > +   struct device *dev;
> > +
> > +   int (*setup_irq)(struct msi_chip *chip, struct pci_dev *dev,
> > +struct msi_desc *desc);
> > +   void (*teardown_irq)(struct msi_chip *chip, unsigned int irq);
> > +   int (*check_device)(struct msi_chip *chip, struct pci_dev *dev,
> > +   int nvec, int type);
> > +};
> 
> Is there a need to add setup_irqs and teardown_irqs functions here? This will
> allow your MSI chips to support multiple MSIs per requesting device.
> 
> What about restore_msi_irqs? Does this fit in here too?

I guess those could be added as well. I've concentrated on the most
common use-cases here, which seem to be the three included functions.
Most other implementations use the generic implementations for multiple
MSIs.

Note that the proposed framework is in no way fixed and can be extended
at will. The important step is to get rid of the one implementation for
the whole kernel concept.

Thierry


pgp0zNDwJVFsl.pgp
Description: PGP signature

Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()

[Glauber Costa]

On 03/22/2013 01:48 PM, Michal Hocko wrote:
> On Fri 22-03-13 13:41:40, Glauber Costa wrote:
>> On 03/22/2013 01:31 PM, Michal Hocko wrote:
>>> On Fri 22-03-13 12:22:23, Glauber Costa wrote:
 On 03/22/2013 12:17 PM, Li Zefan wrote:
>> GFP_TEMPORARY groups short lived allocations but the mem cache is not
>>> an ideal candidate of this type of allocations..
>>>
> I'm not sure I'm following you...
>
> char *memcg_cache_name()
> {
>   char *name = alloc();
>   return name;
> }
>
> kmem_cache_dup()
> {
>   name = memcg_cache_name();
>   kmem_cache_create_memcg(name);
>   free(name);
> }
>
> Isn't this a short lived allocation?
>

 Hi,

 Thanks for identifying and fixing this.

 Li is right. The cache name will live long, but this is because the
 slab/slub caches will strdup it internally. So the actual memcg
 allocation is short lived.
>>>
>>> OK, I have totally missed that. Sorry about the confusion. Then all the
>>> churn around the allocation is pointless, no?
>>> What about:
>>
>> If we're really not concerned about stack, then yes. Even if always
>> running from workqueues, a PAGE_SIZEd stack variable seems risky to me.
> 
> This is not on stack. It is static
> 
Ah, right, I totally missed that. And then you're taking the mutex.

But actually, you don't need to take the mutex. All calls to
kmem_cache_dup are protected by the memcg_cache_mutex. So you should be
able to just use the buffer without further problems.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] bisected: PandaBoard smsc95xx ethernet driver error from USB timeout

[Mats Liljegren]

Frank Rowand wrote:
> On 03/21/13 07:41, Alan Stern wrote:
> > On Wed, 20 Mar 2013, Frank Rowand wrote:
> > 
> >> Hi All,
> >>
> >> Not quite sure quite where the problem is (USB, OMAP, smsc95xx driver, 
> >> other???),
> >> so casting the nets wide...
> >>
> >> The PandaBoard frequently fails to boot with an eth0 error when mounting
> >> the root file system via NFS (ethernet driver fails due to a USB timeout;
> >> no ethernet means NFS won't work).  A typical set of error messages is:
> >>
> >> [3.264373] smsc95xx 1-1.1:1.0: usb_probe_interface
> >> [3.269500] smsc95xx 1-1.1:1.0: usb_probe_interface - got id
> >> [3.275543] smsc95xx v1.0.4
> >> [8.078674] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at 
> >> usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 82:b9:1d:fa:67:0d
> >> [8.091003] hub 1-1:1.0: state 7 ports 5 chg  evt 0002
> >> [   13.509918] usb 1-1.1: swapper/0 timed out on ep0out len=0/4
> >> [   13.515869] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 
> >> 0x0108
> >> [   13.523559] smsc95xx 1-1.1:1.0: eth0: Failed to write ADDRL: -110
> >> [   13.529998] IP-Config: Failed to open eth0
> >>
> >> I have bisected this to:
> >>
> >>   commit 18aafe64d75d0e27dae206cacf4171e4e485d285
> >>   Author: Alan Stern 
> >>   Date:   Wed Jul 11 11:23:04 2012 -0400
> >>
> >>  USB: EHCI: use hrtimer for the I/O watchdog
> > 
> > I don't understand how that commit could cause a timeout unless there 
> > are at least two other bugs present in your system.
> > 
> >> Note that to compile this version of the kernel, an additional fix must
> >> also be applied:
> >>
> >>   commit ba5952e0711b14d8d4fe172671f8aa6091ace3ee
> >>   Author: Ming Lei 
> >>   Date:   Fri Jul 13 17:25:24 2012 +0800
> >>
> >>  USB: ehci-omap: fix compile failure(v1)
> >>
> >> The symptom can be worked around by retrying the USB access if a timeout
> >> occurs.  This is clearly _not_ the fix, just a hack that I used to
> >> investigate the problem:
> >>
> >>   http://article.gmane.org/gmane.linux.rt.user/9773
> >>
> >> My kernel configuration is:
> >>
> >>   arch/arm/configs/omap2plus_defconfig
> >>
> >>   plus to get the ethernet driver I add:
> >>
> >> CONFIG_USB_EHCI_HCD
> >> CONFIG_USB_NET_SMSC95XX
> >>
> >> I found the problem on 3.6.11, but have not replicated it on 3.9-rcX
> >> yet because my config fails to build on 3.9-rc1 and 3.9-rc2.  I'll try
> >> to work on that issue tomorrow.
> > 
> > Let me know how it works out.
> 
> My PandaBoard builds fail on 3.9-rcX due to ARM multiplatform issues.
> Either there is something I need to change about the way I build it,
> or it is broken (that is a side issue).  My simple expedient was to
> hack around multiplatform, and just make it build (patch below if
> anyone else wants a _temporary_ hack).

I have built 3.9-RC2 for PandaBoard ES and the only problem I have seen is
that you need to add "LOADADDR=0x80008000" when building uImage target.

-- Mats
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/7] KVM: MMU: fast zap all shadow pages

[Xiao Guangrong]

On 03/22/2013 10:11 AM, Xiao Guangrong wrote:

>> The modifications should be contained to kvm_mmu_get_page() mostly,
>> correct? (would also have to keep counters to increase SLAB freeing 
>> ratio, relative to number of outdated shadow pages).
> 
> Yes.
> 
>>
>> And then have codepaths that nuke shadow pages break from the spinlock,
> 
> I think this is not needed any more. We can let mmu_notify use the generation
> number to invalid all shadow pages, then we only need to free them after
> all vcpus down and mmu_notify unregistered - at this point, no lock 
> contention,
> we can directly free them.

Sorry. This is wrong since after call ->release(), the memory will be
freed. zap-all-sp can not be delayed. Will think out a good way to handle 
this...


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 02/10] mm: vmscan: Obey proportional scanning requirements for kswapd

[Michal Hocko]

On Fri 22-03-13 08:37:04, Mel Gorman wrote:
> On Fri, Mar 22, 2013 at 08:54:27AM +0100, Michal Hocko wrote:
> > On Thu 21-03-13 15:34:42, Mel Gorman wrote:
> > > On Thu, Mar 21, 2013 at 04:07:55PM +0100, Michal Hocko wrote:
> > > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > > > > > index 4835a7a..182ff15 100644
> > > > > > > --- a/mm/vmscan.c
> > > > > > > +++ b/mm/vmscan.c
> > > > > > > @@ -1815,6 +1815,45 @@ out:
> > > > > > >   }
> > > > > > >  }
> > > > > > >  
> > > > > > > +static void recalculate_scan_count(unsigned long nr_reclaimed,
> > > > > > > + unsigned long nr_to_reclaim,
> > > > > > > + unsigned long nr[NR_LRU_LISTS])
> > > > > > > +{
> > > > > > > + enum lru_list l;
> > > > > > > +
> > > > > > > + /*
> > > > > > > +  * For direct reclaim, reclaim the number of pages requested. 
> > > > > > > Less
> > > > > > > +  * care is taken to ensure that scanning for each LRU is 
> > > > > > > properly
> > > > > > > +  * proportional. This is unfortunate and is improper aging but
> > > > > > > +  * minimises the amount of time a process is stalled.
> > > > > > > +  */
> > > > > > > + if (!current_is_kswapd()) {
> > > > > > > + if (nr_reclaimed >= nr_to_reclaim) {
> > > > > > > + for_each_evictable_lru(l)
> > > > > > > + nr[l] = 0;
> > > > > > > + }
> > > > > > > + return;
> > > > > > 
> > > > > > Heh, this is nicely cryptically said what could be done in 
> > > > > > shrink_lruvec
> > > > > > as
> > > > > > if (!current_is_kswapd()) {
> > > > > > if (nr_reclaimed >= nr_to_reclaim)
> > > > > > break;
> > > > > > }
> > > > > > 
> > > > > 
> > > > > Pretty much. At one point during development, this function was more
> > > > > complex and it evolved into this without me rechecking if splitting it
> > > > > out still made sense.
> > > > > 
> > > > > > Besides that this is not memcg aware which I think it would break
> > > > > > targeted reclaim which is kind of direct reclaim but it still would 
> > > > > > be
> > > > > > good to stay proportional because it starts with DEF_PRIORITY.
> > > > > > 
> > > > > 
> > > > > This does break memcg because it's a special sort of direct reclaim.
> > > > > 
> > > > > > I would suggest moving this back to shrink_lruvec and update the 
> > > > > > test as
> > > > > > follows:
> > > > > 
> > > > > I also noticed that we check whether the scan counts need to be
> > > > > normalised more than once
> > > > 
> > > > I didn't mind this because it "disqualified" at least one LRU every
> > > > round which sounds reasonable to me because all LRUs would be scanned
> > > > proportionally.
> > > 
> > > Once the scan count for one LRU is 0 then min will always be 0 and no
> > > further adjustment is made. It's just redundant to check again.
> > 
> > Hmm, I was almost sure I wrote that min should be adjusted only if it is >0
> > in the first loop but it is not there...
> > 
> > So for real this time.
> > for_each_evictable_lru(l)
> > if (nr[l] && nr[l] < min)
> > min = nr[l];
> > 
> > This should work, no? Everytime you shrink all LRUs you and you have
> > reclaimed enough already you get the smallest LRU out of game. This
> > should keep proportions evenly.
> 
> Lets say we started like this
> 
> LRU_INACTIVE_ANON   60
> LRU_ACTIVE_FILE   1000
> LRU_INACTIVE_FILE 3000
> 
> and we've reclaimed nr_to_reclaim pages then we recalculate the number
> of pages to scan from each list as;
> 
> LRU_INACTIVE_ANON   0
> LRU_ACTIVE_FILE   940
> LRU_INACTIVE_FILE  2940
> 
> We then shrink SWAP_CLUSTER_MAX from each LRU giving us this.
> 
> LRU_INACTIVE_ANON   0
> LRU_ACTIVE_FILE   908
> LRU_INACTIVE_FILE  2908
> 
> Then under your suggestion this would be recalculated as
> 
> LRU_INACTIVE_ANON   0
> LRU_ACTIVE_FILE 0
> LRU_INACTIVE_FILE  2000
> 
> another SWAP_CLUSTER_MAX reclaims and then it stops we stop reclaiming. I
> might still be missing the point of your suggestion but I do not think it
> would preserve the proportion of pages we reclaim from the anon or file LRUs.

It wouldn't preserve proportion precisely because each reclaim round is
in SWAP_CLUSTER_MAX units but it would reclaim bigger lists more than
smaller ones which I thought was the whole point. So yes using word
"proportionally" is unfortunate but I didn't find out better one.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()

[Michal Hocko]

On Fri 22-03-13 14:03:30, Glauber Costa wrote:
> On 03/22/2013 01:48 PM, Michal Hocko wrote:
> > On Fri 22-03-13 13:41:40, Glauber Costa wrote:
> >> On 03/22/2013 01:31 PM, Michal Hocko wrote:
> >>> On Fri 22-03-13 12:22:23, Glauber Costa wrote:
>  On 03/22/2013 12:17 PM, Li Zefan wrote:
> >> GFP_TEMPORARY groups short lived allocations but the mem cache is not
> >>> an ideal candidate of this type of allocations..
> >>>
> > I'm not sure I'm following you...
> >
> > char *memcg_cache_name()
> > {
> > char *name = alloc();
> > return name;
> > }
> >
> > kmem_cache_dup()
> > {
> > name = memcg_cache_name();
> > kmem_cache_create_memcg(name);
> > free(name);
> > }
> >
> > Isn't this a short lived allocation?
> >
> 
>  Hi,
> 
>  Thanks for identifying and fixing this.
> 
>  Li is right. The cache name will live long, but this is because the
>  slab/slub caches will strdup it internally. So the actual memcg
>  allocation is short lived.
> >>>
> >>> OK, I have totally missed that. Sorry about the confusion. Then all the
> >>> churn around the allocation is pointless, no?
> >>> What about:
> >>
> >> If we're really not concerned about stack, then yes. Even if always
> >> running from workqueues, a PAGE_SIZEd stack variable seems risky to me.
> > 
> > This is not on stack. It is static
> > 
> Ah, right, I totally missed that. And then you're taking the mutex.
> 
> But actually, you don't need to take the mutex. All calls to
> kmem_cache_dup are protected by the memcg_cache_mutex.

Yes and I am not taking that mutex. I've just added lockdep assert to
make sure that this still holds true.

> So you should be able to just use the buffer without further problems.

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2, RFC 05/30] thp, mm: avoid PageUnevictable on active/inactive lru lists

[Kirill A. Shutemov]

Dave Hansen wrote:
> On 03/14/2013 10:50 AM, Kirill A. Shutemov wrote:
> > active/inactive lru lists can contain unevicable pages (i.e. ramfs pages
> > that have been placed on the LRU lists when first allocated), but these
> > pages must not have PageUnevictable set - otherwise shrink_active_list
> > goes crazy:
> ...
> > For lru_add_page_tail(), it means we should not set PageUnevictable()
> > for tail pages unless we're sure that it will go to LRU_UNEVICTABLE.
> > The tail page will go LRU_UNEVICTABLE if head page is not on LRU or if
> > it's marked PageUnevictable() too.
> 
> This is only an issue once you're using lru_add_page_tail() for
> non-anonymous pages, right?

I'm not sure about that. Documentation/vm/unevictable-lru.txt:

Some examples of these unevictable pages on the LRU lists are:

 (1) ramfs pages that have been placed on the LRU lists when first allocated.

 (2) SHM_LOCK'd shared memory pages.  shmctl(SHM_LOCK) does not attempt to
 allocate or fault in the pages in the shared memory region.  This happens
 when an application accesses the page the first time after SHM_LOCK'ing
 the segment.

 (3) mlocked pages that could not be isolated from the LRU and moved to the
 unevictable list in mlock_vma_page().

 (4) Pages mapped into multiple VM_LOCKED VMAs, but try_to_munlock() couldn't
 acquire the VMA's mmap semaphore to test the flags and set PageMlocked.
 munlock_vma_page() was forced to let the page back on to the normal LRU
 list for vmscan to handle.

> > diff --git a/mm/swap.c b/mm/swap.c
> > index 92a9be5..31584d0 100644
> > --- a/mm/swap.c
> > +++ b/mm/swap.c
> > @@ -762,7 +762,8 @@ void lru_add_page_tail(struct page *page, struct page 
> > *page_tail,
> > lru = LRU_INACTIVE_ANON;
> > }
> > } else {
> > -   SetPageUnevictable(page_tail);
> > +   if (!PageLRU(page) || PageUnevictable(page))
> > +   SetPageUnevictable(page_tail);
> > lru = LRU_UNEVICTABLE;
> > }
> 
> You were saying above that ramfs pages can get on the normal
> active/inactive lists.  But, this will end up getting them on the
> unevictable list, right?  So, we have normal ramfs pages on the
> active/inactive lists, but ramfs pages after a huge-page-split on the
> unevictable list.  That seems a bit inconsistent.

Yeah, it's confusing.

I was able to trigger another bug on this code:
if page_evictable(page_tail) is false and PageLRU(page) is true, page_tail
will go to the same lru as page, but nobody cares to sync page_tail
active/inactive state with page. So we can end up with inactive page on
active lru...

I've updated the patch for the next interation. You can check it in git.
It should be cleaner. Description need to be updated.

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2, RFC 07/30] thp, mm: introduce mapping_can_have_hugepages() predicate

[Kirill A. Shutemov]

Dave Hansen wrote:
> On 03/14/2013 10:50 AM, Kirill A. Shutemov wrote:
> > +static inline bool mapping_can_have_hugepages(struct address_space *m)
> > +{
> > +   if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) {
> > +   gfp_t gfp_mask = mapping_gfp_mask(m);
> > +   return !!(gfp_mask & __GFP_COMP);
> > +   }
> > +
> > +   return false;
> > +}
> 
> I did a quick search in all your patches and don't see __GFP_COMP
> getting _set_ anywhere.  Am I missing something?

__GFP_COMP is part of GFP_TRANSHUGE. We set it for ramfs in patch 20/30.

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] cpufreq: stats: do cpufreq_cpu_put() corresponding to cpufreq_cpu_get

[Viresh Kumar]

In cpufreq_stats_free_sysfs() we aren't balancing calls to cpufreq_cpu_get()
with cpufreq_cpu_put(). This will never let us have ref count to policy->kobj as
zero.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq_stats.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index 2fd779e..bfd6273 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -180,15 +180,19 @@ static void cpufreq_stats_free_sysfs(unsigned int cpu)
 {
struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
 
-   if (!cpufreq_frequency_get_table(cpu))
+   if (!policy)
return;
 
-   if (policy && !policy_is_shared(policy)) {
+   if (!cpufreq_frequency_get_table(cpu))
+   goto put_ref;
+
+   if (!policy_is_shared(policy)) {
pr_debug("%s: Free sysfs stat\n", __func__);
sysfs_remove_group(&policy->kobj, &stats_attr_group);
}
-   if (policy)
-   cpufreq_cpu_put(policy);
+
+put_ref:
+   cpufreq_cpu_put(policy);
 }
 
 static int cpufreq_stats_create_table(struct cpufreq_policy *policy,
-- 
1.7.12.rc2.18.g61b472e

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] deb-pkg: split debug symbols in their own package

[Anisse Astier]

This can reduce almost 3 times the size of the linux-image package,
while keeping the debug symbols available for this particular build, in
their own package.

This mimics the way kernels are built in debian, ubuntu, or with
make-kpkg, and comes at the price of a small slowdown in the building of
packages.

Signed-off-by: Anisse Astier 
---
 scripts/package/builddeb | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index acb8650..7f7a7fd 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -78,17 +78,19 @@ tmpdir="$objtree/debian/tmp"
 fwdir="$objtree/debian/fwtmp"
 kernel_headers_dir="$objtree/debian/hdrtmp"
 libc_headers_dir="$objtree/debian/headertmp"
+dbg_dir="$objtree/debian/dbgtmp"
 packagename=linux-image-$version
 fwpackagename=linux-firmware-image
 kernel_headers_packagename=linux-headers-$version
 libc_headers_packagename=linux-libc-dev
+dbg_packagename=$packagename-dbg
 
 if [ "$ARCH" = "um" ] ; then
packagename=user-mode-linux-$version
 fi
 
 # Setup the directory structure
-rm -rf "$tmpdir" "$fwdir" "$kernel_headers_dir" "$libc_headers_dir"
+rm -rf "$tmpdir" "$fwdir" "$kernel_headers_dir" "$libc_headers_dir" "$dbg_dir"
 mkdir -m 755 -p "$tmpdir/DEBIAN"
 mkdir -p  "$tmpdir/lib" "$tmpdir/boot" "$tmpdir/usr/share/doc/$packagename"
 mkdir -m 755 -p "$fwdir/DEBIAN"
@@ -98,6 +100,8 @@ mkdir -p 
"$libc_headers_dir/usr/share/doc/$libc_headers_packagename"
 mkdir -m 755 -p "$kernel_headers_dir/DEBIAN"
 mkdir -p "$kernel_headers_dir/usr/share/doc/$kernel_headers_packagename"
 mkdir -p "$kernel_headers_dir/lib/modules/$version/"
+mkdir -p "$dbg_dir/usr/share/doc/$dbg_packagename"
+mkdir -m 755 -p "$dbg_dir/DEBIAN"
 if [ "$ARCH" = "um" ] ; then
mkdir -p "$tmpdir/usr/lib/uml/modules/$version" "$tmpdir/usr/bin"
 fi
@@ -128,8 +132,24 @@ if grep -q '^CONFIG_MODULES=y' .config ; then
mv "$tmpdir/lib/modules/$version"/* 
"$tmpdir/usr/lib/uml/modules/$version/"
rmdir "$tmpdir/lib/modules/$version"
fi
+   # Build debug package
+   (
+   cd $tmpdir
+   for module in $(find lib/modules/ -name *.ko); do
+   mkdir -p $(dirname $dbg_dir/usr/lib/debug/$module)
+   # only keep debug symbols in the debug file
+   objcopy --only-keep-debug $module 
$dbg_dir/usr/lib/debug/$module
+   # strip original module from debug symbols
+   objcopy --strip-debug $module
+   # then add a link to those
+   objcopy 
--add-gnu-debuglink=$dbg_dir/usr/lib/debug/$module $module
+   done
+   )
 fi
 
+mkdir -p $dbg_dir/usr/lib/debug/lib/modules/$version/
+cp vmlinux $dbg_dir/usr/lib/debug/lib/modules/$version/
+
 if [ "$ARCH" != "um" ]; then
$MAKE headers_check KBUILD_SRC=
$MAKE headers_install KBUILD_SRC= 
INSTALL_HDR_PATH="$libc_headers_dir/usr"
@@ -297,6 +317,17 @@ if [ "$ARCH" != "um" ]; then
create_package "$libc_headers_packagename" "$libc_headers_dir"
 fi
 
+cat <> debian/control
+
+Package: $dbg_packagename
+Section: devel
+Provides: linux-debug, linux-debug-$version
+Architecture: any
+Description: Linux kernel debugging symbols for $version
+ This package will come in handy if you need to debug the kernel.
+EOF
+
+create_package "$dbg_packagename" "$dbg_dir"
 create_package "$packagename" "$tmpdir"
 
 exit 0
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] hwrng: exynos - add CONFIG_PM_RUNTIME to suspend/resume functions

[Herbert Xu]

On Fri, Mar 22, 2013 at 02:38:53AM -0700, David Rientjes wrote:
> On Fri, 22 Mar 2013, Jingoo Han wrote:
> 
> > Add CONFIG_PM_RUNTIME to suspend/resume functions to fix the build
> > error. It is because UNIVERSAL_DEV_PM_OPS macro is related to both
> > CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME.
> > 
> > drivers/char/hw_random/exynos-rng.c:167:8: error: 
> > 'exynos_rng_runtime_suspend' undeclared here (not in a function)
> > drivers/char/hw_random/exynos-rng.c:167:8: error: 
> > 'exynos_rng_runtime_resume' undeclared here (not in a function)
> > 
> > Signed-off-by: Jingoo Han 
> > Reported-by: David Rientjes 
> > Cc: Herbert Xu 
> 
> Acked-by: David Rientjes 

Thanks, I've folded this into the original patch and rebased
the tree so that it is bisectable.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] i2c: iSMT SMBus patch for Intel Avoton DeviceIDs

[Wolfram Sang]

On Thu, Feb 21, 2013 at 02:30:43PM -0800, Seth Heasley wrote:
> This patch adds the iSMT SMBus Controller DeviceIDs for the Intel Avoton SOC.
> 
> Signed-off-by: Seth Heasley 

Applied to for-current, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] register_console: prevent adding the same console twice

[Andreas Bießmann]

This patch guards the console_drivers list to be corrupted. The
for_each_console() macro insist on a strictly forward list ended by NULL:

 con0->next->con1->next->NULL

Without this patch it may happen easily to destroy this list for example by
adding 'earlyprintk' twice. This will result in the following list:

 con0->next->con0

This in turn will result in an endless loop in console_unlock() later on by
printing the first __log_buf line endlessly.

Signed-off-by: Andreas Bießmann 
Cc: Greg Kroah-Hartman 
Cc: Kay Sievers 
Cc: sta...@vger.kernel.org
---
 kernel/printk.c |8 
 1 file changed, 8 insertions(+)

diff --git a/kernel/printk.c b/kernel/printk.c
index 0b31715..f78bfcd 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -2254,6 +2254,14 @@ void register_console(struct console *newcon)
unsigned long flags;
struct console *bcon = NULL;
 
+   if (console_drivers)
+   for_each_console(bcon)
+   if (bcon == newcon) {
+   pr_warn("prevent adding console '%s%d' twice\n",
+   newcon->name, newcon->index);
+   return;
+   }
+
/*
 * before we register a new CON_BOOT console, make sure we don't
 * already have a valid console
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 20/34] metag: Use generic idle loop

[James Hogan]

On 21/03/13 21:53, Thomas Gleixner wrote:
> Signed-off-by: Thomas Gleixner 
> Cc: James Hogan 
> ---
>  arch/metag/Kconfig  |1 +
>  arch/metag/kernel/process.c |   32 +++-
>  arch/metag/kernel/smp.c |2 +-
>  3 files changed, 5 insertions(+), 30 deletions(-)
> 
> Index: linux-2.6/arch/metag/Kconfig
> ===
> --- linux-2.6.orig/arch/metag/Kconfig
> +++ linux-2.6/arch/metag/Kconfig
> @@ -9,6 +9,7 @@ config METAG
>   select GENERIC_CLOCKEVENTS
>   select GENERIC_IRQ_SHOW
>   select GENERIC_SMP_IDLE_THREAD
> + select GENERIC_IDLE_LOOP

Please preserve alphabetical ordering

>   select HAVE_64BIT_ALIGNED_ACCESS
>   select HAVE_ARCH_TRACEHOOK
>   select HAVE_C_RECORDMCOUNT
> Index: linux-2.6/arch/metag/kernel/process.c
> ===
> --- linux-2.6.orig/arch/metag/kernel/process.c
> +++ linux-2.6/arch/metag/kernel/process.c
> @@ -31,7 +31,7 @@
>  /*
>   * Wait for the next interrupt and enable local interrupts
>   */
> -static inline void arch_idle(void)
> +void arch_cpu_idle(void)
>  {
>   int tmp;
>  
> @@ -59,35 +59,9 @@ static inline void arch_idle(void)
> : "r" (get_trigger_mask()));
>  }
>  
> -void cpu_idle(void)
> +void arch_cpu_idle_dead(void)
>  {
> - set_thread_flag(TIF_POLLING_NRFLAG);
> -
> - while (1) {
> - tick_nohz_idle_enter();
> - rcu_idle_enter();
> -
> - while (!need_resched()) {
> - /*
> -  * We need to disable interrupts here to ensure we don't
> -  * miss a wakeup call.
> -  */
> - local_irq_disable();
> - if (!need_resched()) {
> -#ifdef CONFIG_HOTPLUG_CPU
> - if (cpu_is_offline(smp_processor_id()))
> - cpu_die();
> -#endif
> - arch_idle();
> - } else {
> - local_irq_enable();
> - }
> - }
> -
> - rcu_idle_exit();
> - tick_nohz_idle_exit();
> - schedule_preempt_disabled();
> -  }
> + cpu_die();

This requires #include  and even then the definition of
cpu_die() is guarded by #ifdef CONFIG_HOTPLUG_CPU, like blackfin & s390.

>  }
>  
>  void (*pm_power_off)(void);
> Index: linux-2.6/arch/metag/kernel/smp.c
> ===
> --- linux-2.6.orig/arch/metag/kernel/smp.c
> +++ linux-2.6/arch/metag/kernel/smp.c
> @@ -297,7 +297,7 @@ asmlinkage void secondary_start_kernel(v
>   /*
>* OK, it's off to the idle thread for us
>*/
> - cpu_idle();
> + cpu_startup_entry(CPUHP_ONLINE);
>  }
>  
>  void __init smp_cpus_done(unsigned int max_cpus)
> 
> 

I also hit the same problems Tony Breeds hit.

After hacking around them, and enabling SMP and HOTPLUG_CPU, I hit the
WARN_ON_ONCE(!irqs_disabled()) after arch_cpu_idle() in cpu_idle_loop():

> META213-Thread1 DSP [LogF] WARNING: at kernel/cpu/idle.c:94 
> _cpu_startup_entry+0x1cc/0x1e0()

arch_cpu_idle() enables interrupts. See Arnd's comment in
https://patchwork.kernel.org/patch/2002571/:

> To avoid that, you need to disable interrupts around
> the inner loop. The sleep instruction should return with
> interrupts implicitly enabled if ARC behaves like most
> other architectures doing this.

Cheers
James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MAINTAINERS: add maintainer entry for atmel i2c driver

[Wolfram Sang]

On Fri, Mar 15, 2013 at 04:32:57PM +0100, ludovic.desroc...@atmel.com wrote:
> From: Ludovic Desroches 
> 
> Create an entry for atmel i2c driver: i2c-at91.c
> 
> Signed-off-by: Ludovic Desroches 

Applied to for-current, thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] deb-pkg: add a hook argument to match debian hooks parameters

[Anisse Astier]

This should allow the package to better integrate with debian hooks, and
should not be too disruptive of hooks supporting only one parameter.

Signed-off-by: Anisse Astier 
---
 scripts/package/builddeb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 7f7a7fd..30d8756 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -169,7 +169,7 @@ set -e
 # Pass maintainer script parameters to hook scripts
 export DEB_MAINT_PARAMS="\$*"
 
-test -d $debhookdir/$script.d && run-parts --arg="$version" 
$debhookdir/$script.d
+test -d $debhookdir/$script.d && run-parts --arg="$version" 
--arg="/boot/vmlinuz-$version" $debhookdir/$script.d
 exit 0
 EOF
chmod 755 "$tmpdir/DEBIAN/$script"
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] EDAC fixes for 3.9

[Borislav Petkov]

Hi Linus,

please pull the fixes below.

Thanks.

The following changes since commit 6dbe51c251a327e012439c4772097a13df43c5b8:

  Linux 3.9-rc1 (2013-03-03 15:11:05 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/for_linus

for you to fetch changes up to 9713faecff3d071de1208b081d4943b002e9cb1c:

  EDAC: Merge mci.mem_is_per_rank with mci.csbased (2013-03-16 06:32:30 +0100)


A fix from Mauro to correct csrow size accounting in sysfs and a sparse
fix from Stephen Hemminger.


Mauro Carvalho Chehab (2):
  amd64_edac: Correct DIMM sizes
  EDAC: Merge mci.mem_is_per_rank with mci.csbased

Stephen Hemminger (1):
  EDAC: Make sysfs functions static

 drivers/edac/amd64_edac.c| 15 +--
 drivers/edac/edac_mc.c   |  6 +++---
 drivers/edac/edac_mc_sysfs.c | 17 +
 include/linux/edac.h |  7 ++-
 4 files changed, 19 insertions(+), 26 deletions(-)

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] memcg: fix memcg_cache_name() to use cgroup_name()

[Glauber Costa]

On 03/22/2013 02:06 PM, Michal Hocko wrote:
> On Fri 22-03-13 14:03:30, Glauber Costa wrote:
>> On 03/22/2013 01:48 PM, Michal Hocko wrote:
>>> On Fri 22-03-13 13:41:40, Glauber Costa wrote:
 On 03/22/2013 01:31 PM, Michal Hocko wrote:
> On Fri 22-03-13 12:22:23, Glauber Costa wrote:
>> On 03/22/2013 12:17 PM, Li Zefan wrote:
 GFP_TEMPORARY groups short lived allocations but the mem cache is not
> an ideal candidate of this type of allocations..
>
>>> I'm not sure I'm following you...
>>>
>>> char *memcg_cache_name()
>>> {
>>> char *name = alloc();
>>> return name;
>>> }
>>>
>>> kmem_cache_dup()
>>> {
>>> name = memcg_cache_name();
>>> kmem_cache_create_memcg(name);
>>> free(name);
>>> }
>>>
>>> Isn't this a short lived allocation?
>>>
>>
>> Hi,
>>
>> Thanks for identifying and fixing this.
>>
>> Li is right. The cache name will live long, but this is because the
>> slab/slub caches will strdup it internally. So the actual memcg
>> allocation is short lived.
>
> OK, I have totally missed that. Sorry about the confusion. Then all the
> churn around the allocation is pointless, no?
> What about:

 If we're really not concerned about stack, then yes. Even if always
 running from workqueues, a PAGE_SIZEd stack variable seems risky to me.
>>>
>>> This is not on stack. It is static
>>>
>> Ah, right, I totally missed that. And then you're taking the mutex.
>>
>> But actually, you don't need to take the mutex. All calls to
>> kmem_cache_dup are protected by the memcg_cache_mutex.
> 
> Yes and I am not taking that mutex. I've just added lockdep assert to
> make sure that this still holds true.
> 
It is impressive what a busy week does to our brains...

I read the code as lockdep_assert(memcg_cache_mutex), and then later on
mutex_lock(&memcg_mutex). But reading again, that was a just an
rcu_read_lock(). Good thing it is Friday

You guys can add my Acked-by, and thanks again

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3 linux-next] cpufreq: conservative: Use an inline function to evaluate freq_target

[Viresh Kumar]

On 22 March 2013 13:33, Stratos Karafotis  wrote:
> Use an inline function to evaluate freq_target to avoid duplicate code.
>
> Also, define a macro for the default frequency step.
>
> Signed-off-by: Stratos Karafotis 
> ---
>  drivers/cpufreq/cpufreq_conservative.c | 28 
>  1 file changed, 16 insertions(+), 12 deletions(-)

Acked-by: Viresh Kumar 

> diff --git a/drivers/cpufreq/cpufreq_conservative.c 
> b/drivers/cpufreq/cpufreq_conservative.c
> index fe17bd3..63499c8 100644
> --- a/drivers/cpufreq/cpufreq_conservative.c
> +++ b/drivers/cpufreq/cpufreq_conservative.c
> @@ -29,11 +29,24 @@
>  /* Conservative governor macros */
>  #define DEF_FREQUENCY_UP_THRESHOLD (80)
>  #define DEF_FREQUENCY_DOWN_THRESHOLD   (20)
> +#define DEF_FREQUENCY_STEP (5)
>  #define DEF_SAMPLING_DOWN_FACTOR   (1)
>  #define MAX_SAMPLING_DOWN_FACTOR   (10)
>
>  static DEFINE_PER_CPU(struct cs_cpu_dbs_info_s, cs_cpu_dbs_info);
>
> +static inline unsigned int get_freq_target(struct cs_dbs_tuners *cs_tuners,
> +  struct cpufreq_policy *policy)
> +{
> +   unsigned int freq_target = (cs_tuners->freq_step * policy->max) / 100;
> +
> +   /* max freq cannot be less than 100. But who knows... */
> +   if (unlikely(freq_target == 0))
> +   freq_target = DEF_FREQUENCY_STEP;
> +
> +   return freq_target;
> +}
> +
>  /*
>   * Every sampling_rate, we check, if current idle time is less than 20%
>   * (default), then we try to increase frequency. Every sampling_rate *
> @@ -49,7 +62,6 @@ static void cs_check_cpu(int cpu, unsigned int load)
> struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
> struct dbs_data *dbs_data = policy->governor_data;
> struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
> -   unsigned int freq_target;
>
> /*
>  * break out if we 'cannot' reduce the speed as the user might
> @@ -66,13 +78,7 @@ static void cs_check_cpu(int cpu, unsigned int load)
> if (dbs_info->requested_freq == policy->max)
> return;
>
> -   freq_target = (cs_tuners->freq_step * policy->max) / 100;
> -
> -   /* max freq cannot be less than 100. But who knows */
> -   if (unlikely(freq_target == 0))
> -   freq_target = 5;
> -
> -   dbs_info->requested_freq += freq_target;
> +   dbs_info->requested_freq += get_freq_target(cs_tuners, 
> policy);
> if (dbs_info->requested_freq > policy->max)
> dbs_info->requested_freq = policy->max;
>
> @@ -94,9 +100,7 @@ static void cs_check_cpu(int cpu, unsigned int load)
> if (policy->cur == policy->min)
> return;
>
> -   freq_target = (cs_tuners->freq_step * policy->max) / 100;
> -
> -   dbs_info->requested_freq -= freq_target;
> +   dbs_info->requested_freq -= get_freq_target(cs_tuners, 
> policy);
> if (dbs_info->requested_freq < policy->min)
> dbs_info->requested_freq = policy->min;
>
> @@ -323,7 +327,7 @@ static int cs_init(struct dbs_data *dbs_data)
> tuners->down_threshold = DEF_FREQUENCY_DOWN_THRESHOLD;
> tuners->sampling_down_factor = DEF_SAMPLING_DOWN_FACTOR;
> tuners->ignore_nice = 0;
> -   tuners->freq_step = 5;
> +   tuners->freq_step = DEF_FREQUENCY_STEP;
>
> dbs_data->tuners = tuners;
> dbs_data->min_sampling_rate = MIN_SAMPLING_RATE_RATIO *
> --
> 1.8.1.4
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/2] of: remove /proc/device-tree

[Grant Likely]

On Thu, Mar 21, 2013 at 8:07 PM, Grant Likely  wrote:
> On Thu, Mar 21, 2013 at 12:52 PM, Benjamin Herrenschmidt
>  wrote:
>> On Thu, 2013-03-21 at 11:24 +, Grant Likely wrote:
>> kexec comes to mind (all 4 variants of fs2dt.c (yuck !)), dtc, various
>> powerpc-utils (bootloader configuration etc...), and more.
>>
>> We also need to test the new code with hotplug, I'll see if I can get
>> somebody at IBM to give it a spin.
>
> Thanks

Actually, this will be broken. I missed adding hooks to the property
add/remove paths. It will be fixed in v3.

BTW, I'd really like to revisit the locking semantics and reference
counting of OF_DYNAMIC. It is incredibly painful it is for driver
authors to get right. What is the device_node lifecycle on pseries? Do
we really need to be doing of_node_get/put() every time we walk the
tree, or is there a different model that can be used?

Bear with me as I think through this out-loud...

How about instead of doing get/put by default every time, we have an
explicit mutex that needs to be grabbed if there is a potential that
the code will be dealing with dynamic nodes. For device drivers this
will almost never be true because the node ref counts will already
have been incremented when the device was created (well before probe
occurs). Plus the ref count won't be decremented again until the point
of struct device removal.

The other scenario is when searching for nodes there is the potential
that any node in the system could disappear mid-search, and in most
cases it won't even be one of the nodes that is being searched for.
For the non-matching nodes that shouldn't be a problem because the
lock is held while traversing past them. No worries about them
dropping out from under us. It's when one of the matching nodes might
disappear that problems could happen.

But for the vast majority of use cases that simply isn't going to
happen. We aren't removing individual nodes from a passed in .dtb (at
least not yet). I'm not going to base design decisions on that, but it
seems like the the current scheme is optimized for the wrong use case.

Would it be reasonable to expect that the caller explicitly grab a
lock to hold off node removal tree wide? Then only increment the
refcount on nodes that are actually cared about?

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v3 1/2] epoll: avoid spinlock contention with wfcqueue

[Eric Wong]

Arve Hjønnevåg  wrote:
> On Thu, Mar 21, 2013 at 8:24 PM, Eric Wong  wrote:
> >
> > With EPOLLET and improper usage (not hitting EAGAIN), the event now
> > has a larger window to be lost (as mentioned in my changelog).
> >
> 
> What about the case where EPOLLET is not set? The old code did not
> drop events in that case.

Nothing is dropped, if the event wasn't on the ready list before,
ep_poll_callback may still append the ready list while __put_user
is running.

If the event was on the ready list:

1) It does not matter for EPOLLONESHOT, it'll get masked out and
   discarded in the next ep_send_events call until ep_modify reenables
   it.  Since ep_modify and ep_send_events both take ep->mtx, there's
   no conflict.

2) Level Trigger - event stays ready, so nothing is dropped.

> > As far as correct __pm_stay_awake/__pm_relax handling, perhaps adding
> > an atomic counter to struct eventpoll (or each epitem) will work?
> 
> The wakeup_source should stay in sync with the epoll state. I don't
> think any additional state is needed.

The problem is epi->state is not set atomically in ep_send_events,

Having atomic operations in the loop hurts performance (early versions
of this patch did that, and hurt the single-threaded case).

Maybe I'll only set epi->state atomically if epi->ws is used...

> > If we go with atomic counter in struct eventpoll, is per-epitem
> > wakeup_source still necessary?  We have space in epitem now, but
> > maybe one day we will might need it.
> >
> 
> The wakeup_source per epitem is useful for accounting reasons. If
> suspend fails, it is useful to know which device caused it.

OK.  I'll keep epitem->ws
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] wfcqueue: functions for local append and enqueue

[Eric Wong]

Mathieu Desnoyers  wrote:
> * Eric Wong (normalper...@yhbt.net) wrote:
> >  /*
> > + * __wfcq_append_local: append one local queue to another local queue
> > + *
> > + * No memory barriers are issued.  Mutual exclusion is the responsibility
> > + * of the caller.
> > + *
> > + * Returns false if the queue was empty prior to adding the node.
> > + * Returns true otherwise.
> > + */
> > +static inline bool __wfcq_append_local(struct wfcq_head *head,
> 
> Following the rest of the header, we could use:
> 
> ___wfcq_append() for this function,

OK.

However, I think ___ is a little confusing (but I'm easily confused :x).
I didn't even realize some functions in wfcqueue.h had ___ (vs __) until
just now(!)

But I will resend later tonight/tomorrow with ___ for consistency with
the existing API unless I've convinced you "_local" is easier :)

On a related note to underscores, I totally missed the existence of
cacheline_aligned_in_smp in my first RFC even though I had seen
the __ version for .data around.

> and:
> 
> __wfcq_enqueue()
> 
> we should also update the "Synchronization table" at the beginning of
> the file accordingly.

Will update.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2, RFC 08/30] thp, mm: rewrite add_to_page_cache_locked() to support huge pages

[Kirill A. Shutemov]

Dave Hansen wrote:
> On 03/14/2013 10:50 AM, Kirill A. Shutemov wrote:
> > From: "Kirill A. Shutemov" 
> > 
> > For huge page we add to radix tree HPAGE_CACHE_NR pages at once: head
> > page for the specified index and HPAGE_CACHE_NR-1 tail pages for
> > following indexes.
> > 
> > Signed-off-by: Kirill A. Shutemov 
> > ---
> >  mm/filemap.c |   76 
> > --
> >  1 file changed, 53 insertions(+), 23 deletions(-)
> > 
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index 2d99191..6bac9e2 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -447,6 +447,7 @@ int add_to_page_cache_locked(struct page *page, struct 
> > address_space *mapping,
> > pgoff_t offset, gfp_t gfp_mask)
> >  {
> > int error;
> > +   int nr = 1;
> >  
> > VM_BUG_ON(!PageLocked(page));
> > VM_BUG_ON(PageSwapBacked(page));
> > @@ -454,32 +455,61 @@ int add_to_page_cache_locked(struct page *page, 
> > struct address_space *mapping,
> > error = mem_cgroup_cache_charge(page, current->mm,
> > gfp_mask & GFP_RECLAIM_MASK);
> > if (error)
> > -   goto out;
> > +   return error;
> >  
> > -   error = radix_tree_preload(gfp_mask & ~__GFP_HIGHMEM);
> > -   if (error == 0) {
> > -   page_cache_get(page);
> > -   page->mapping = mapping;
> > -   page->index = offset;
> > +   if (PageTransHuge(page)) {
> > +   BUILD_BUG_ON(HPAGE_CACHE_NR > RADIX_TREE_PRELOAD_NR);
> > +   nr = HPAGE_CACHE_NR;
> > +   }
> 
> That seems like a slightly odd place to put a BUILD_BUG_ON().  I guess
> it doesn't matter to some degree, but does putting it inside the if()
> imply anything?

It actually matters.

HPAGE_CACHE_NR is BUILD_BUG() if !CONFIG_TRANSPARENT_HUGEPAGE, so we need
to hide it inside 'if (PageTransHuge(page))'. PageTransHuge(page) is 0 in
compile time if !CONFIG_TRANSPARENT_HUGEPAGE, so compiler can be smart and
optimize out the check.

> > +   error = radix_tree_preload_count(nr, gfp_mask & ~__GFP_HIGHMEM);
> > +   if (error) {
> > +   mem_cgroup_uncharge_cache_page(page);
> > +   return error;
> > +   }
> >  
> > -   spin_lock_irq(&mapping->tree_lock);
> > -   error = radix_tree_insert(&mapping->page_tree, offset, page);
> > -   if (likely(!error)) {
> > -   mapping->nrpages++;
> > -   __inc_zone_page_state(page, NR_FILE_PAGES);
> > -   spin_unlock_irq(&mapping->tree_lock);
> > -   trace_mm_filemap_add_to_page_cache(page);
> > -   } else {
> > -   page->mapping = NULL;
> > -   /* Leave page->index set: truncation relies upon it */
> > -   spin_unlock_irq(&mapping->tree_lock);
> > -   mem_cgroup_uncharge_cache_page(page);
> > -   page_cache_release(page);
> 
> I do really like how this rewrite de-indents this code. :)

:)

> > +   page_cache_get(page);
> > +   spin_lock_irq(&mapping->tree_lock);
> > +   page->mapping = mapping;
> > +   page->index = offset;
> > +   error = radix_tree_insert(&mapping->page_tree, offset, page);
> > +   if (unlikely(error))
> > +   goto err;
> > +   if (PageTransHuge(page)) {
> > +   int i;
> > +   for (i = 1; i < HPAGE_CACHE_NR; i++) {
> > +   page_cache_get(page + i);
> > +   page[i].index = offset + i;
> 
> Is it OK to leave page->mapping unset for these?

Good catch, thanks.
Seems nobody really use it, since I haven't got any oops, but we need to
set it anyway.

> > +   error = radix_tree_insert(&mapping->page_tree,
> > +   offset + i, page + i);
> > +   if (error) {
> > +   page_cache_release(page + i);
> > +   break;
> > +   }
> > }
> 
> Throughout all this new code, I'd really challenge you to try as much as
> possible to minimize the code stuck under "if (PageTransHuge(page))".

I put thp-related code under the 'if' intentionally to be able to optimize
it out if !CONFIG_TRANSPARENT_HUGEPAGE. The config option is disabled by
default.

> For instance, could you change the for() loop a bit and have it shared
> between both cases, like:
> 
> > +   for (i = 0; i < nr; i++) {
> > +   page_cache_get(page + i);
> > +   page[i].index = offset + i;
> > +   error = radix_tree_insert(&mapping->page_tree,
> > +   offset + i, page + i);
> > +   if (error) {
> > +   page_cache_release(page + i);
> > +   break;
> > +   }
> > }
> 
> > -   radix_tree_preload_end();
> > -   } else
> > -   mem_cgroup_uncharge_cache_page(page);
> > -out:
> > +   if (error) {
> > +   error = ENOSPC; /* no space for a huge page */
> > +   for

[GIT PULL] AMD RAS improvements for v3.10

[Borislav Petkov]

Hi Ingo,

please pull the two improvements below; not urgent stuff, can go into
tip/x86/ras for 3.10.

Thanks.

The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git tags/ras_for_next

for you to fetch changes up to bafcdd3b6cb86035cdb0511450961edcdc084c27:

  x86, MCE, AMD: Use MCG_CAP MSR to find out number of banks on AMD (2013-03-22 
11:25:01 +0100)


Basically, the main reason for this is virtualization but it is also
correct, at the same time, to read out the number of supported banks
from hardware instead of having hardcoded defines. Which means it is a
nice cleanup for baremetal too.


Boris Ostrovsky (2):
  x86, MCE, AMD: Replace shared_bank array with is_shared_bank() helper
  x86, MCE, AMD: Use MCG_CAP MSR to find out number of banks on AMD

 arch/x86/kernel/cpu/mcheck/mce_amd.c | 39 
---
 1 file changed, 24 insertions(+), 15 deletions(-)

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] pwm: pwm-tiecap: add CONFIG_PM_SLEEP to suspend/resume functions

[Thierry Reding]

On Mon, Mar 11, 2013 at 11:12:58AM +0900, Jingoo Han wrote:
> This patch adds CONFIG_PM_SLEEP to suspend/resume functions to fix
> the following build warning when CONFIG_PM_SLEEP is not selected.
> 
> drivers/pwm/pwm-tiecap.c:314:12: warning: 'ecap_pwm_suspend' defined but not 
> used [-Wunused-function]
> drivers/pwm/pwm-tiecap.c:328:12: warning: 'ecap_pwm_resume' defined but not 
> used [-Wunused-function]
> 
> Signed-off-by: Jingoo Han 
> ---
>  drivers/pwm/pwm-tiecap.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)

All 3 patches applied, thanks.

Thierry


pgpH7OaM2MgVC.pgp
Description: PGP signature

Re: [PATCH] pwm: ab8500: use devm_kzalloc()

[Thierry Reding]

On Fri, Mar 08, 2013 at 12:45:58PM +0900, Jingoo Han wrote:
> Use devm_kzalloc() to make cleanup paths more simple.
> 
> Signed-off-by: Jingoo Han 
> ---
>  drivers/pwm/pwm-ab8500.c |7 ++-
>  1 files changed, 2 insertions(+), 5 deletions(-)

Applied, thanks.

Thierry


pgphhRKGKlY4a.pgp
Description: PGP signature

Re: [PATCH] pwm: samsung: convert s3c_pwm to dev_pm_ops

[Thierry Reding]

On Fri, Mar 08, 2013 at 01:03:31PM +0900, Jingoo Han wrote:
> Instead of using legacy suspend/resume methods, using newer dev_pm_ops
> structure allows better control over power management.
> 
> Signed-off-by: Jingoo Han 
> ---
>  drivers/pwm/pwm-samsung.c |   20 +---
>  1 files changed, 9 insertions(+), 11 deletions(-)

Applied, thanks.

Thierry


pgplrqkbE9x0e.pgp
Description: PGP signature

Re: I2C: Fix i2c fail problem when a process is terminated by a signal on octeon in 3.8

[Wolfram Sang]

On Tue, Feb 26, 2013 at 09:08:43PM +, 송은봉 wrote:
> 
> I've been debugging the abnormal operation of i2c on octeon. 
> If a process is terminated by signal in the middle of i2c operation, 
> next i2c read operation which is done by another process was failed.
> So i changed to ignore signal in the middle of i2c operation. 
> After that the problem was not reproduced.
> 
>  
> 
> Signed-off-by: EunBong Song 

Basically OK, but you have lots of whitespace issues, so I can't apply
your patch. Please resend and make sure it applies.

Thanks,

   Wolfram
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/