Re: [PATCH v3 3/5] char: ti-usim: Add driver for USIM module on AM43xx

2014-05-29 Thread Satish Patel



On 5/29/2014 9:23 PM, Greg Kroah-Hartman wrote:

On Thu, May 29, 2014 at 03:35:37PM +0530, Satish Patel wrote:

+enum usim_card_mode {
+   USIM_CARD_MODE_ASYNC = 0,   /* asynchronous mode */
+   USIM_CARD_MODE_SYNC_TYPE1,  /* synchronous mode: Type 1 */
+   USIM_CARD_MODE_SYNC_TYPE2,  /* synchronous mode: Type 2 */
+   USIM_CARD_MODE_SYNC_OTHER,  /* Any other synchronous type */
+};
+struct usim_data {
+   int slot;
+   int rxexplen;
+   int txlen;
+   unsigned char apdu[256];
+};


You need to use the proper variable types for a structure that is going
to cross the user/kernel boundry in an ioctl :(
Do you mean to use __u32 instead int ? make use of types defined in 
types.h ? if yes, I will make that change :). Thanks for pointing out.



--
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] hugetlb: restrict hugepage_migration_support() to x86_64

2014-05-29 Thread Naoya Horiguchi
Curretly hugepage migration is available for all archs which support pmd-level
hugepage, but testing is done only for x86_64 and there're bugs for other archs.
So to avoid breaking such archs, this patch limits the availability strictly to
x86_64 until developers of other archs get interested in enabling this feature.

Simply disabling hugepage migration on non-x86_64 archs is not enough to fix
the reported problem where sys_move_pages() hits the BUG_ON() in
follow_page(FOLL_GET), so let's fix this by checking if hugepage migration is
supported in vma_migratable().

ChangeLog:
- add VM_HUGETLB check in vma_migratable()
- fix dependency in config ARCH_ENABLE_HUGEPAGE_MIGRATION
- remove comment on hugepage_migration_support()

Reported-by: Michael Ellerman m...@ellerman.id.au
Tested-by: Michael Ellerman m...@ellerman.id.au
Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Cc: sta...@vger.kernel.org # 3.12+
---
 arch/arm/mm/hugetlbpage.c |  5 -
 arch/arm64/mm/hugetlbpage.c   |  5 -
 arch/ia64/mm/hugetlbpage.c|  5 -
 arch/metag/mm/hugetlbpage.c   |  5 -
 arch/mips/mm/hugetlbpage.c|  5 -
 arch/powerpc/mm/hugetlbpage.c | 10 --
 arch/s390/mm/hugetlbpage.c|  5 -
 arch/sh/mm/hugetlbpage.c  |  5 -
 arch/sparc/mm/hugetlbpage.c   |  5 -
 arch/tile/mm/hugetlbpage.c|  5 -
 arch/x86/Kconfig  |  4 
 arch/x86/mm/hugetlbpage.c | 10 --
 include/linux/hugetlb.h   | 13 +
 include/linux/mempolicy.h |  6 ++
 mm/Kconfig|  3 +++
 15 files changed, 18 insertions(+), 73 deletions(-)

diff --git v3.15-rc5.orig/arch/arm/mm/hugetlbpage.c 
v3.15-rc5/arch/arm/mm/hugetlbpage.c
index 54ee6163c181..66781bf34077 100644
--- v3.15-rc5.orig/arch/arm/mm/hugetlbpage.c
+++ v3.15-rc5/arch/arm/mm/hugetlbpage.c
@@ -56,8 +56,3 @@ int pmd_huge(pmd_t pmd)
 {
return pmd_val(pmd)  !(pmd_val(pmd)  PMD_TABLE_BIT);
 }
-
-int pmd_huge_support(void)
-{
-   return 1;
-}
diff --git v3.15-rc5.orig/arch/arm64/mm/hugetlbpage.c 
v3.15-rc5/arch/arm64/mm/hugetlbpage.c
index 5e9aec358306..2fc8258bab2d 100644
--- v3.15-rc5.orig/arch/arm64/mm/hugetlbpage.c
+++ v3.15-rc5/arch/arm64/mm/hugetlbpage.c
@@ -54,11 +54,6 @@ int pud_huge(pud_t pud)
return !(pud_val(pud)  PUD_TABLE_BIT);
 }
 
-int pmd_huge_support(void)
-{
-   return 1;
-}
-
 static __init int setup_hugepagesz(char *opt)
 {
unsigned long ps = memparse(opt, opt);
diff --git v3.15-rc5.orig/arch/ia64/mm/hugetlbpage.c 
v3.15-rc5/arch/ia64/mm/hugetlbpage.c
index 68232db98baa..76069c18ee42 100644
--- v3.15-rc5.orig/arch/ia64/mm/hugetlbpage.c
+++ v3.15-rc5/arch/ia64/mm/hugetlbpage.c
@@ -114,11 +114,6 @@ int pud_huge(pud_t pud)
return 0;
 }
 
-int pmd_huge_support(void)
-{
-   return 0;
-}
-
 struct page *
 follow_huge_pmd(struct mm_struct *mm, unsigned long address, pmd_t *pmd, int 
write)
 {
diff --git v3.15-rc5.orig/arch/metag/mm/hugetlbpage.c 
v3.15-rc5/arch/metag/mm/hugetlbpage.c
index 042431509b56..3c52fa6d0f8e 100644
--- v3.15-rc5.orig/arch/metag/mm/hugetlbpage.c
+++ v3.15-rc5/arch/metag/mm/hugetlbpage.c
@@ -110,11 +110,6 @@ int pud_huge(pud_t pud)
return 0;
 }
 
-int pmd_huge_support(void)
-{
-   return 1;
-}
-
 struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
 pmd_t *pmd, int write)
 {
diff --git v3.15-rc5.orig/arch/mips/mm/hugetlbpage.c 
v3.15-rc5/arch/mips/mm/hugetlbpage.c
index 77e0ae036e7c..4ec8ee10d371 100644
--- v3.15-rc5.orig/arch/mips/mm/hugetlbpage.c
+++ v3.15-rc5/arch/mips/mm/hugetlbpage.c
@@ -84,11 +84,6 @@ int pud_huge(pud_t pud)
return (pud_val(pud)  _PAGE_HUGE) != 0;
 }
 
-int pmd_huge_support(void)
-{
-   return 1;
-}
-
 struct page *
 follow_huge_pmd(struct mm_struct *mm, unsigned long address,
pmd_t *pmd, int write)
diff --git v3.15-rc5.orig/arch/powerpc/mm/hugetlbpage.c 
v3.15-rc5/arch/powerpc/mm/hugetlbpage.c
index eb923654ba80..7e70ae968e5f 100644
--- v3.15-rc5.orig/arch/powerpc/mm/hugetlbpage.c
+++ v3.15-rc5/arch/powerpc/mm/hugetlbpage.c
@@ -86,11 +86,6 @@ int pgd_huge(pgd_t pgd)
 */
return ((pgd_val(pgd)  0x3) != 0x0);
 }
-
-int pmd_huge_support(void)
-{
-   return 1;
-}
 #else
 int pmd_huge(pmd_t pmd)
 {
@@ -106,11 +101,6 @@ int pgd_huge(pgd_t pgd)
 {
return 0;
 }
-
-int pmd_huge_support(void)
-{
-   return 0;
-}
 #endif
 
 pte_t *huge_pte_offset(struct mm_struct *mm, unsigned long addr)
diff --git v3.15-rc5.orig/arch/s390/mm/hugetlbpage.c 
v3.15-rc5/arch/s390/mm/hugetlbpage.c
index 0727a55d87d9..0ff66a7e29bb 100644
--- v3.15-rc5.orig/arch/s390/mm/hugetlbpage.c
+++ v3.15-rc5/arch/s390/mm/hugetlbpage.c
@@ -220,11 +220,6 @@ int pud_huge(pud_t pud)
return 0;
 }
 
-int pmd_huge_support(void)
-{
-   return 1;
-}
-
 struct page *follow_huge_pmd(struct mm_struct *mm, unsigned long address,
 pmd_t *pmdp, int write)
 {
diff --git 

[PATCH 2/2] hugetlb: rename hugepage_migration_support() to ..._supported()

2014-05-29 Thread Naoya Horiguchi
We already have a function named hugepage_supported(), and the similar
name hugepage_migration_support() is a bit unconfortable, so let's rename
it hugepage_migration_supported().

Signed-off-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
---
 include/linux/hugetlb.h | 4 ++--
 mm/hugetlb.c| 2 +-
 mm/migrate.c| 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git v3.15-rc5.orig/include/linux/hugetlb.h 
v3.15-rc5/include/linux/hugetlb.h
index c9de64cf288d..9d35e514312b 100644
--- v3.15-rc5.orig/include/linux/hugetlb.h
+++ v3.15-rc5/include/linux/hugetlb.h
@@ -385,7 +385,7 @@ static inline pgoff_t basepage_index(struct page *page)
 
 extern void dissolve_free_huge_pages(unsigned long start_pfn,
 unsigned long end_pfn);
-static inline int hugepage_migration_support(struct hstate *h)
+static inline int hugepage_migration_supported(struct hstate *h)
 {
 #ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
return huge_page_shift(h) == PMD_SHIFT;
@@ -441,7 +441,7 @@ static inline pgoff_t basepage_index(struct page *page)
return page-index;
 }
 #define dissolve_free_huge_pages(s, e) do {} while (0)
-#define hugepage_migration_support(h)  0
+#define hugepage_migration_supported(h)0
 
 static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
   struct mm_struct *mm, pte_t *pte)
diff --git v3.15-rc5.orig/mm/hugetlb.c v3.15-rc5/mm/hugetlb.c
index ea42b584661a..83d936d12c1d 100644
--- v3.15-rc5.orig/mm/hugetlb.c
+++ v3.15-rc5/mm/hugetlb.c
@@ -545,7 +545,7 @@ static struct page *dequeue_huge_page_node(struct hstate 
*h, int nid)
 /* Movability of hugepages depends on migration support. */
 static inline gfp_t htlb_alloc_mask(struct hstate *h)
 {
-   if (hugepages_treat_as_movable || hugepage_migration_support(h))
+   if (hugepages_treat_as_movable || hugepage_migration_supported(h))
return GFP_HIGHUSER_MOVABLE;
else
return GFP_HIGHUSER;
diff --git v3.15-rc5.orig/mm/migrate.c v3.15-rc5/mm/migrate.c
index bed48809e5d0..15b589ae6aaf 100644
--- v3.15-rc5.orig/mm/migrate.c
+++ v3.15-rc5/mm/migrate.c
@@ -1031,7 +1031,7 @@ static int unmap_and_move_huge_page(new_page_t 
get_new_page,
 * tables or check whether the hugepage is pmd-based or not before
 * kicking migration.
 */
-   if (!hugepage_migration_support(page_hstate(hpage))) {
+   if (!hugepage_migration_supported(page_hstate(hpage))) {
putback_active_hugepage(hpage);
return -ENOSYS;
}
-- 
1.9.3

--
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: Unionmount and overlayfs testsuite

2014-05-29 Thread Sedat Dilek
On Thu, May 29, 2014 at 10:59 PM, David Howells dhowe...@redhat.com wrote:
 Sedat Dilek sedat.di...@gmail.com wrote:

 Fixable in your testsuite?

 Done and pushed.


Thanks.

I still see lots of...

umount: /mnt: not mounted

...and impermissible.test fails here...

***
*** ./run.sh impermissible.test
***
umount: /mnt: not mounted
TEST100: Impermissible open O_TRUNC|O_WRONLY
 - open_file_as_bin -t -w /mnt/a/rootfile100 -E EACCES
 - open_file_as_bin -w /mnt/a/rootfile100 -E EACCES
 - open_file_as_bin -r /mnt/a/rootfile100 -R :xxx:yyy:zzz
 - open_file -r /mnt/a/rootfile100 -R :xxx:yyy:zzz
 - open_file -w /mnt/a/rootfile100 -W shark
 - open_file -r /mnt/a/rootfile100 -R sharkyyy:zzz
 - open_file_as_bin -r /mnt/a/rootfile100 -R sharkyyy:zzz
TEST101: Impermissible open O_WRONLY
 - open_file_as_bin -w /mnt/a/rootfile101 -E EACCES
 - open_file_as_bin -w /mnt/a/rootfile101 -E EACCES
 - open_file_as_bin -r /mnt/a/rootfile101 -R :xxx:yyy:zzz
 - open_file -r /mnt/a/rootfile101 -R :xxx:yyy:zzz
 - open_file -w /mnt/a/rootfile101 -W shark
 - open_file -r /mnt/a/rootfile101 -R sharkyyy:zzz
 - open_file_as_bin -r /mnt/a/rootfile101 -R sharkyyy:zzz
TEST102: Impermissible open O_APPEND
 - open_file_as_bin -a /mnt/a/rootfile102 -E EACCES
 - open_file_as_bin -a /mnt/a/rootfile102 -E EACCES
 - open_file_as_bin -r /mnt/a/rootfile102 -R :xxx:yyy:zzz
 - open_file -r /mnt/a/rootfile102 -R :xxx:yyy:zzz
 - open_file -a /mnt/a/rootfile102 -W shark
 - open_file -r /mnt/a/rootfile102 -R :xxx:yyy:zzzshark
 - open_file_as_bin -r /mnt/a/rootfile102 -R :xxx:yyy:zzzshark
TEST103: Impermissible truncate
 - fs_op_as_bin truncate /mnt/a/rootfile103 4 -E EACCES
 - fs_op_as_bin truncate /mnt/a/rootfile103 4 -E EACCES
 - open_file_as_bin -r /mnt/a/rootfile103 -R :xxx:yyy:zzz
 - open_file -r /mnt/a/rootfile103 -R :xxx:yyy:zzz
 - fs_op truncate /mnt/a/rootfile103 4
 - open_file -r /mnt/a/rootfile103 -R :xxx
 - open_file_as_bin -r /mnt/a/rootfile103 -R :xxx
TEST104: Impermissible utimes
 - fs_op_as_bin utimes /mnt/a/rootfile104 -E EACCES
/mnt/a/rootfile104: Test file not on upper filesystem (line 130)

Full log of run.sh is attached.

- Sedat -
***
*** ./run.sh open-plain.test
***
TEST100: Open O_RDONLY
 - open_file -r /mnt/a/foo100 -R :xxx:yyy:zzz
 - open_file -r /mnt/a/foo100 -R :xxx:yyy:zzz
TEST101: Open O_WRONLY
 - open_file -w /mnt/a/foo101 -W q
 - open_file -r /mnt/a/foo101 -R qxxx:yyy:zzz
 - open_file -w /mnt/a/foo101 -W p
 - open_file -r /mnt/a/foo101 -R pxxx:yyy:zzz
TEST102: Open O_APPEND|O_WRONLY
 - open_file -a /mnt/a/foo102 -W q
 - open_file -r /mnt/a/foo102 -R :xxx:yyy:zzzq
 - open_file -a /mnt/a/foo102 -W p
 - open_file -r /mnt/a/foo102 -R :xxx:yyy:zzzqp
TEST103: Open O_RDWR
 - open_file -r -w /mnt/a/foo103 -W q
 - open_file -r /mnt/a/foo103 -R qxxx:yyy:zzz
 - open_file -r -w /mnt/a/foo103 -W p
 - open_file -r /mnt/a/foo103 -R pxxx:yyy:zzz
TEST104: Open O_APPEND|O_RDWR
 - open_file -r -a /mnt/a/foo104 -W q
 - open_file -r /mnt/a/foo104 -R :xxx:yyy:zzzq
 - open_file -r -a /mnt/a/foo104 -W p
 - open_file -r /mnt/a/foo104 -R :xxx:yyy:zzzqp
***
*** ./run.sh open-trunc.test
***
umount: /mnt: not mounted
TEST100: Open O_TRUNC|O_RDONLY
 - open_file -t -r /mnt/a/foo100 -R 
 - open_file -t -r /mnt/a/foo100 -R 
TEST101: Open O_TRUNC|O_WRONLY
 - open_file -t -w /mnt/a/foo101 -W q
 - open_file -r /mnt/a/foo101 -R q
 - open_file -t -w /mnt/a/foo101 -W p
 - open_file -r /mnt/a/foo101 -R p
TEST102: Open O_TRUNC|O_APPEND|O_WRONLY
 - open_file -t -a /mnt/a/foo102 -W q
 - open_file -r /mnt/a/foo102 -R q
 - open_file -t -a /mnt/a/foo102 -W p
 - open_file -r /mnt/a/foo102 -R p
TEST103: Open O_TRUNC|O_RDWR
 - open_file -t -r -w /mnt/a/foo103 -W q
 - open_file -r /mnt/a/foo103 -R q
 - open_file -t -r -w /mnt/a/foo103 -W p
 - open_file -r /mnt/a/foo103 -R p
TEST104: Open O_TRUNC|O_APPEND|O_RDWR
 - open_file -t -r -a /mnt/a/foo104 -W q
 - open_file -r /mnt/a/foo104 -R q
 - open_file -t -r -a /mnt/a/foo104 -W p
 - open_file -r /mnt/a/foo104 -R p
***
*** ./run.sh open-creat.test
***
umount: /mnt: not mounted
TEST100: Open O_CREAT|O_RDONLY
 - open_file -c -r /mnt/a/foo100 -R :xxx:yyy:zzz
 - open_file -c -r /mnt/a/foo100 -R :xxx:yyy:zzz
TEST101: Open O_CREAT|O_WRONLY
 - open_file -c -w /mnt/a/foo101 -W q
 - open_file -c -r /mnt/a/foo101 -R qxxx:yyy:zzz
 - open_file -c -w /mnt/a/foo101 -W p
 - open_file -c -r /mnt/a/foo101 -R pxxx:yyy:zzz
TEST102: Open O_CREAT|O_APPEND|O_WRONLY
 - open_file -c -a /mnt/a/foo102 -W q
 - open_file -c -r /mnt/a/foo102 -R :xxx:yyy:zzzq
 - open_file -c -a /mnt/a/foo102 -W p
 - open_file -c -r /mnt/a/foo102 -R :xxx:yyy:zzzqp
TEST103: Open O_CREAT|O_RDWR
 - open_file -c -r -w /mnt/a/foo103 -W q
 - open_file -c -r /mnt/a/foo103 -R qxxx:yyy:zzz
 - open_file -c -r -w /mnt/a/foo103 -W p
 - open_file -c -r /mnt/a/foo103 -R pxxx:yyy:zzz
TEST104: Open O_CREAT|O_APPEND|O_RDWR
 - open_file -c -r -a /mnt/a/foo104 -W q
 - open_file -c -r /mnt/a/foo104 -R :xxx:yyy:zzzq
 - open_file -c -r -a /mnt/a/foo104 -W p
 - open_file -c -r /mnt/a/foo104 -R 

Re: Unionmount and overlayfs testsuite

2014-05-29 Thread Sedat Dilek
On Fri, May 30, 2014 at 6:15 AM, Sedat Dilek sedat.di...@gmail.com wrote:
 On Thu, May 29, 2014 at 10:59 PM, David Howells dhowe...@redhat.com wrote:
 Sedat Dilek sedat.di...@gmail.com wrote:

 Fixable in your testsuite?

 Done and pushed.


 Thanks.

 I still see lots of...

 umount: /mnt: not mounted

 ...and impermissible.test fails here...

[...]
 TEST104: Impermissible utimes
  - fs_op_as_bin utimes /mnt/a/rootfile104 -E EACCES
 /mnt/a/rootfile104: Test file not on upper filesystem (line 130)


rootfile104 is really not on /upper/ ...

# find /mnt/ /upper/ /lower/ -name rootfile104
/mnt/a/rootfile104
/lower/a/rootfile104

- Sedat -
--
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 0/3] staging: comedi: addi_apci_1564: prepare for adding Change-of-State interrupt support

2014-05-29 Thread Chase Southwood
Hi Greg,

On Sat, May 24, 2014 at 5:23 PM, Chase Southwood
chase.southw...@gmail.com wrote:
 This patchset adds the required subdevice for supporting DI COS interrupts,
 as well as introducing a driver-specific private data struct that will
 make the COS interrupt operations much more straightforward and clean.

 Chase Southwood (3):
   staging: comedi: addi_apci_1564: add a subdevice for Change-of-State
 interrupt support
   staging: comedi: addi_apci_1564: remove send_sig() use
   staging: comedi: addi_apci_1564: introduce apci1564_private struct

  .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 200 
 ++---
  drivers/staging/comedi/drivers/addi_apci_1564.c|  54 +++---
  2 files changed, 126 insertions(+), 128 deletions(-)

Please ignore this patchset completely, I am sending one out
momentarily that serves as its replacement.

Thanks,
Chase
--
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 2/2] x86_64: expand kernel stack to 16K

2014-05-29 Thread Linus Torvalds
On Thu, May 29, 2014 at 7:12 PM, Minchan Kim minc...@kernel.org wrote:

 Interim report,

 And result is as follows, It reduce about 800-byte compared to
 my first report but still stack usage seems to be high.
 Really needs diet of VM functions.

Yes. And in this case uninlining things might actually help, because
the it's not actually performing reclaim in the second case, so
inlining the reclaim code into that huge __alloc_pages_nodemask()
function means that it has the stack frame for all those cases even if
they don't actually get used.

That said, the way those functions are set up (with lots of arguments
passed from one to the other), not inlining will cause huge costs too
for the argument setup.

It really might be very good to create a struct alloc_info that
contains those shared arguments, and just pass a (const) pointer to
that around. Gcc would likely tend to be *much* better at generating
code for that, because it avoids a tons of temporaries being created
by function calls. Even when it's inlined, the argument itself ends up
being a new temporary internally, and I suspect one reason gcc
(especially your 4.6.3 version, apparently) generates those big spill
frames is because there's tons of these duplicate temporaries that
apparently don't get merged properly.

Ugh. I think I'll try looking at that tomorrow.

Linus
--
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/6] staging: comedi: addi_apci_1564: fix Change-of-State interrupt functionality.

2014-05-29 Thread Chase Southwood
This patchset introduces a new private data struct for this driver, adds
all of the code required to support Change-of-State interrupts for the
digital input subsystem, and finally focuses and fixes
apci1564_interrupt() to service this type of interrupt correctly.

Chase Southwood (6):
  staging: comedi: addi_apci_1564: remove send_sig() use
  staging: comedi: addi_apci_1564: remove use of
devpriv-b_OutputMemoryStatus
  staging: comedi: addi_apci_1564: introduce apci1564_private struct
  staging: comedi: addi_apci_1564: add a subdevice for Change-of-State
interrupt support
  staging: comedi: addi_apci_1564: hook-up the interrupt subdevice
  staging: comedi: addi_apci_1564: cleanup v_ADDI_Interrupt()

 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 295 -
 drivers/staging/comedi/drivers/addi_apci_1564.c| 294 +---
 2 files changed, 316 insertions(+), 273 deletions(-)

-- 
1.9.3

--
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/6] staging: comedi: addi_apci_1564: remove use of devpriv-b_OutputMemoryStatus

2014-05-29 Thread Chase Southwood
This member of the private data struct is only set at one location in the
entire driver, and then never even used for anything.  Let's just remove
its use.

Signed-off-by: Chase Southwood chase.southw...@gmail.com
Cc: Ian Abbott abbo...@mev.co.uk
Cc: H Hartley Sweeeten hswee...@visionengravers.com
---
 drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index be0e009..f974bd2 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -147,11 +147,6 @@ static int apci1564_do_config(struct comedi_device *dev,
return -EINVAL;
}
 
-   if (data[0])
-   devpriv-b_OutputMemoryStatus = ADDIDATA_ENABLE;
-   else
-   devpriv-b_OutputMemoryStatus = ADDIDATA_DISABLE;
-
if (data[1] == ADDIDATA_ENABLE)
ul_Command = ul_Command | 0x1;
else
-- 
1.9.3

--
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/6] staging: comedi: addi_apci_1564: remove send_sig() use

2014-05-29 Thread Chase Southwood
The addi-data drivers use send_sig() to let the user know when an
interrupt has occurred. The standard way to do this in the comedi
subsystem is to have a subdevice that supports asynchronous commands
and use comedi_event() to signal the user.

Remove the send_sig() usage in this driver.

Signed-off-by: Chase Southwood chase.southw...@gmail.com
Cc: Ian Abbott abbo...@mev.co.uk
Cc: H Hartley Sweeten hswee...@visionengravers.com
---
 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 23 --
 1 file changed, 23 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 0ba5385..be0e009 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -108,8 +108,6 @@ static int apci1564_di_config(struct comedi_device *dev,
 {
struct addi_private *devpriv = dev-private;
 
-   devpriv-tsk_Current = current;
-
/* Set the digital input logic */
if (data[0] == ADDIDATA_ENABLE) {
data[2] = data[2]  4;
@@ -166,7 +164,6 @@ static int apci1564_do_config(struct comedi_device *dev,
 
outl(ul_Command, devpriv-i_IobaseAmcc + APCI1564_DO_INT_CTRL_REG);
ui_InterruptData = inl(devpriv-i_IobaseAmcc + 
APCI1564_DO_INT_CTRL_REG);
-   devpriv-tsk_Current = current;
return insn-n;
 }
 
@@ -189,7 +186,6 @@ static int apci1564_timer_config(struct comedi_device *dev,
struct addi_private *devpriv = dev-private;
unsigned int ul_Command1 = 0;
 
-   devpriv-tsk_Current = current;
if (data[0] == ADDIDATA_WATCHDOG) {
devpriv-b_TimerSelectMode = ADDIDATA_WATCHDOG;
 
@@ -436,8 +432,6 @@ static void apci1564_interrupt(int irq, void *d)
ui_InterruptStatus_1564 =
inl(devpriv-i_IobaseAmcc + APCI1564_DI_INT_STATUS_REG);
ui_InterruptStatus_1564 = ui_InterruptStatus_1564  0X0000;
-   /* send signal to the sample */
-   send_sig(SIGIO, devpriv-tsk_Current, 0);
/* enable the interrupt */
outl(ui_DI, devpriv-i_IobaseAmcc + APCI1564_DI_IRQ_REG);
return;
@@ -451,8 +445,6 @@ static void apci1564_interrupt(int irq, void *d)
/* Disable the  Interrupt */
outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DO_INT_CTRL_REG);
 
-   /* Sends signal to user space */
-   send_sig(SIGIO, devpriv-tsk_Current, 0);
}
 
if (ui_Timer == 1) {
@@ -463,9 +455,6 @@ static void apci1564_interrupt(int irq, void *d)
ul_Command2 = inl(devpriv-i_IobaseAmcc + 
APCI1564_TIMER_CTRL_REG);
outl(0x0, devpriv-i_IobaseAmcc + 
APCI1564_TIMER_CTRL_REG);
 
-   /* Send a signal to from kernel to user space */
-   send_sig(SIGIO, devpriv-tsk_Current, 0);
-
/*  Enable Timer Interrupt */
 
outl(ul_Command2, devpriv-i_IobaseAmcc + 
APCI1564_TIMER_CTRL_REG);
@@ -482,9 +471,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
 dev-iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
 
-   /* Send a signal to from kernel to user space */
-   send_sig(SIGIO, devpriv-tsk_Current, 0);
-
/*  Enable Counter Interrupt */
outl(ul_Command2,
 dev-iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
@@ -501,9 +487,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
 dev-iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER2));
 
-   /* Send a signal to from kernel to user space */
-   send_sig(SIGIO, devpriv-tsk_Current, 0);
-
/*  Enable Counter Interrupt */
outl(ul_Command2,
 dev-iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER2));
@@ -520,9 +503,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
 dev-iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER3));
 
-   /* Send a signal to from kernel to user space */
-   send_sig(SIGIO, devpriv-tsk_Current, 0);
-
/*  Enable Counter Interrupt */
outl(ul_Command2,
 dev-iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER3));
@@ -539,9 +519,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
 dev-iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER4));
 
-   /* Send a signal to from kernel to user space */
-   send_sig(SIGIO, 

[PATCH 4/6] staging: comedi: addi_apci_1564: add a subdevice for Change-of-State interrupt support

2014-05-29 Thread Chase Southwood
This board supports an interrupt that can be generated by an AND/OR
combination of 16 of the input channels.

Create a separate subdevice to handle this interrupt.

Signed-off-by: Chase Southwood chase.southw...@gmail.com
Cc: Ian Abbott abbo...@mev.co.uk
Cc: H Hartley Sweeten hswee...@visionengravers.com
---
 drivers/staging/comedi/drivers/addi_apci_1564.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c 
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index 5901143..183fdc3 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -105,7 +105,7 @@ static int apci1564_auto_attach(struct comedi_device *dev,
dev-irq = pcidev-irq;
}
 
-   ret = comedi_alloc_subdevices(dev, 3);
+   ret = comedi_alloc_subdevices(dev, 4);
if (ret)
return ret;
 
@@ -144,6 +144,20 @@ static int apci1564_auto_attach(struct comedi_device *dev,
s-insn_read = apci1564_timer_read;
s-insn_config = apci1564_timer_config;
 
+   /* Change-Of-State (COS) interrupt subdevice */
+   s = dev-subdevices[3];
+   if (dev-irq) {
+   dev-read_subdev = s;
+   s-type = COMEDI_SUBD_DI;
+   s-subdev_flags = SDF_READABLE | SDF_CMD_READ;
+   s-n_chan = 1;
+   s-maxdata = 1;
+   s-range_table = range_digital;
+   s-len_chanlist = 1;
+   } else {
+   s-type = COMEDI_SUBD_UNUSED;
+   }
+
return 0;
 }
 
-- 
1.9.3

--
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 5/6] staging: comedi: addi_apci_1564: hook-up the interrupt subdevice

2014-05-29 Thread Chase Southwood
The board supported by this driver can generate an interrupt based
on the state of input channels 0-15.

The apci1564_di_config() function is used to configure which
inputs are used to generate the interrupt. Currently this function
is broken since it does not follow the comedi API for insn_config
functions. Fix this function by implementing the config instruction
INSN_CONFIG_DIGITAL_TRIG.

Add the remaining subdevice operations necessary for the interrupt
subdevice to support async commands.

Signed-off-by: Chase Southwood chase.southw...@gmail.com
Cc: Ian Abbott abbo...@mev.co.uk
Cc: H Hartley Sweeten hswee...@visionengravers.com
---

The structure of _much_ of this code was taken from/based on the similar
code found in addi_apci_1032.c.  As such, I would appreciate as much
review I can get to make sure what I've done here actually makes sense
for this driver :)

 .../comedi/drivers/addi-data/hwdrv_apci1564.c  |  37 +---
 drivers/staging/comedi/drivers/addi_apci_1564.c| 228 +++--
 2 files changed, 210 insertions(+), 55 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 054e731..41aa889 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -95,45 +95,14 @@ static unsigned int ui_InterruptData, ui_Type;
 
 struct apci1564_private {
unsigned int amcc_iobase;   /* base of AMCC I/O registers */
+   unsigned int mode1; /* riding-edge/high level channels */
+   unsigned int mode2; /* falling-edge/low level channels */
+   unsigned int ctrl;  /* interrupt mode OR (edge) . AND 
(level) */
unsigned char timer_select_mode;
unsigned char mode_select_register;
 };
 
 /*
- * Configures the digital input Subdevice
- *
- * data[0] 1 = Enable interrupt, 0 = Disable interrupt
- * data[1] 0 = ADDIDATA Interrupt OR LOGIC, 1 = ADDIDATA Interrupt AND LOGIC
- * data[2] Interrupt mask for the mode 1
- * data[3] Interrupt mask for the mode 2
- */
-static int apci1564_di_config(struct comedi_device *dev,
- struct comedi_subdevice *s,
- struct comedi_insn *insn,
- unsigned int *data)
-{
-   struct apci1564_private *devpriv = dev-private;
-
-   /* Set the digital input logic */
-   if (data[0] == ADDIDATA_ENABLE) {
-   data[2] = data[2]  4;
-   data[3] = data[3]  4;
-   outl(data[2], devpriv-amcc_iobase + APCI1564_DI_INT_MODE1_REG);
-   outl(data[3], devpriv-amcc_iobase + APCI1564_DI_INT_MODE2_REG);
-   if (data[1] == ADDIDATA_OR)
-   outl(0x4, devpriv-amcc_iobase + APCI1564_DI_IRQ_REG);
-   else
-   outl(0x6, devpriv-amcc_iobase + APCI1564_DI_IRQ_REG);
-   } else {
-   outl(0x0, devpriv-amcc_iobase + APCI1564_DI_INT_MODE1_REG);
-   outl(0x0, devpriv-amcc_iobase + APCI1564_DI_INT_MODE2_REG);
-   outl(0x0, devpriv-amcc_iobase + APCI1564_DI_IRQ_REG);
-   }
-
-   return insn-n;
-}
-
-/*
  * Configures The Digital Output Subdevice.
  *
  * data[1] 0 = Disable VCC Interrupt, 1 = Enable VCC Interrupt
diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c 
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index 183fdc3..cf58f90 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -8,6 +8,42 @@
 
 #include addi-data/hwdrv_apci1564.c
 
+#define APCI1564_CTRL_INT_OR   (0  1)
+#define APCI1564_CTRL_INT_AND  (1  1)
+#define APCI1564_CTRL_INT_ENA  (1  2)
+
+static int apci1564_reset(struct comedi_device *dev)
+{
+   struct apci1564_private *devpriv = dev-private;
+
+   ui_Type = 0;
+
+   /* Disable the input interrupts and reset status register */
+   outl(0x0, devpriv-amcc_iobase + APCI1564_DI_IRQ_REG);
+   inl(devpriv-amcc_iobase + APCI1564_DI_INT_STATUS_REG);
+   outl(0x0, devpriv-amcc_iobase + APCI1564_DI_INT_MODE1_REG);
+   outl(0x0, devpriv-amcc_iobase + APCI1564_DI_INT_MODE2_REG);
+
+   /* Reset the output channels and disable interrupts */
+   outl(0x0, devpriv-amcc_iobase + APCI1564_DO_REG);
+   outl(0x0, devpriv-amcc_iobase + APCI1564_DO_INT_CTRL_REG);
+
+   /* Reset the watchdog registers */
+   addi_watchdog_reset(devpriv-amcc_iobase + APCI1564_WDOG_REG);
+
+   /* Reset the timer registers */
+   outl(0x0, devpriv-amcc_iobase + APCI1564_TIMER_CTRL_REG);
+   outl(0x0, devpriv-amcc_iobase + APCI1564_TIMER_RELOAD_REG);
+
+   /* Reset the counter registers */
+   outl(0x0, dev-iobase + APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
+   outl(0x0, dev-iobase + APCI1564_TCW_CTRL_REG(APCI1564_COUNTER2));
+   outl(0x0, dev-iobase + 

[PATCH 3/6] staging: comedi: addi_apci_1564: introduce apci1564_private struct

2014-05-29 Thread Chase Southwood
The addi_private struct defined in addi-data/addi_common.h is very bloated
and contains many fields which addi_apci_1564 does not require.  In the
interest of eventually removing this driver's dependency on
addi_common.h, we can create a private data struct specifically for
addi_apci_1564 containing only the fields it will actually use.

Signed-off-by: Chase Southwood chase.southw...@gmail.com
Cc: Ian Abbott abbo...@mev.co.uk
Cc: H Hartley Sweeten hswee...@visionengravers.com
---
 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 164 +++--
 drivers/staging/comedi/drivers/addi_apci_1564.c|  34 ++---
 2 files changed, 102 insertions(+), 96 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index f974bd2..054e731 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -49,7 +49,7 @@
 #define APCI1564_COUNTER4  3
 
 /*
- * devpriv-i_IobaseAmcc Register Map
+ * devpriv-amcc_iobase Register Map
  */
 #define APCI1564_DI_REG0x04
 #define APCI1564_DI_INT_MODE1_REG  0x08
@@ -93,6 +93,12 @@
 static unsigned int ui_InterruptStatus_1564;
 static unsigned int ui_InterruptData, ui_Type;
 
+struct apci1564_private {
+   unsigned int amcc_iobase;   /* base of AMCC I/O registers */
+   unsigned char timer_select_mode;
+   unsigned char mode_select_register;
+};
+
 /*
  * Configures the digital input Subdevice
  *
@@ -106,22 +112,22 @@ static int apci1564_di_config(struct comedi_device *dev,
  struct comedi_insn *insn,
  unsigned int *data)
 {
-   struct addi_private *devpriv = dev-private;
+   struct apci1564_private *devpriv = dev-private;
 
/* Set the digital input logic */
if (data[0] == ADDIDATA_ENABLE) {
data[2] = data[2]  4;
data[3] = data[3]  4;
-   outl(data[2], devpriv-i_IobaseAmcc + 
APCI1564_DI_INT_MODE1_REG);
-   outl(data[3], devpriv-i_IobaseAmcc + 
APCI1564_DI_INT_MODE2_REG);
+   outl(data[2], devpriv-amcc_iobase + APCI1564_DI_INT_MODE1_REG);
+   outl(data[3], devpriv-amcc_iobase + APCI1564_DI_INT_MODE2_REG);
if (data[1] == ADDIDATA_OR)
-   outl(0x4, devpriv-i_IobaseAmcc + APCI1564_DI_IRQ_REG);
+   outl(0x4, devpriv-amcc_iobase + APCI1564_DI_IRQ_REG);
else
-   outl(0x6, devpriv-i_IobaseAmcc + APCI1564_DI_IRQ_REG);
+   outl(0x6, devpriv-amcc_iobase + APCI1564_DI_IRQ_REG);
} else {
-   outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DI_INT_MODE1_REG);
-   outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DI_INT_MODE2_REG);
-   outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DI_IRQ_REG);
+   outl(0x0, devpriv-amcc_iobase + APCI1564_DI_INT_MODE1_REG);
+   outl(0x0, devpriv-amcc_iobase + APCI1564_DI_INT_MODE2_REG);
+   outl(0x0, devpriv-amcc_iobase + APCI1564_DI_IRQ_REG);
}
 
return insn-n;
@@ -138,7 +144,7 @@ static int apci1564_do_config(struct comedi_device *dev,
  struct comedi_insn *insn,
  unsigned int *data)
 {
-   struct addi_private *devpriv = dev-private;
+   struct apci1564_private *devpriv = dev-private;
unsigned int ul_Command = 0;
 
if ((data[0] != 0)  (data[0] != 1)) {
@@ -157,8 +163,8 @@ static int apci1564_do_config(struct comedi_device *dev,
else
ul_Command = ul_Command  0xFFFD;
 
-   outl(ul_Command, devpriv-i_IobaseAmcc + APCI1564_DO_INT_CTRL_REG);
-   ui_InterruptData = inl(devpriv-i_IobaseAmcc + 
APCI1564_DO_INT_CTRL_REG);
+   outl(ul_Command, devpriv-amcc_iobase + APCI1564_DO_INT_CTRL_REG);
+   ui_InterruptData = inl(devpriv-amcc_iobase + APCI1564_DO_INT_CTRL_REG);
return insn-n;
 }
 
@@ -178,30 +184,30 @@ static int apci1564_timer_config(struct comedi_device 
*dev,
 struct comedi_insn *insn,
 unsigned int *data)
 {
-   struct addi_private *devpriv = dev-private;
+   struct apci1564_private *devpriv = dev-private;
unsigned int ul_Command1 = 0;
 
if (data[0] == ADDIDATA_WATCHDOG) {
-   devpriv-b_TimerSelectMode = ADDIDATA_WATCHDOG;
+   devpriv-timer_select_mode = ADDIDATA_WATCHDOG;
 
/* Disable the watchdog */
-   outl(0x0, devpriv-i_IobaseAmcc + APCI1564_WDOG_CTRL_REG);
+   outl(0x0, devpriv-amcc_iobase + APCI1564_WDOG_CTRL_REG);
/* Loading the Reload value */
-   outl(data[3], devpriv-i_IobaseAmcc + APCI1564_WDOG_RELOAD_REG);
+   

Re: Unionmount and overlayfs testsuite

2014-05-29 Thread J. R. Okajima

J. R. Okajima:
 - readlink.test,
   fs_op readlink $file -R $testdir/direct_dir_sym100 ${termslash:+-E 
 EINVAL}
   It expects $testdir/direct_dir_sym100. Does it mean UnionMount
   converts the target path?
   For example,
   - /u = /rw + /ro
   - /rw/symlinkA doesn't exist
   - /ro/symlinkA points to /ro/fileA
   Does readlink(2) return /u/fileA instead of /u/fileA?

Ouch!
I meant Does ... instead of /ro/fileA?


J. R. Okajima
--
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 6/6] staging: comedi: addi_apci_1564: cleanup v_ADDI_Interrupt()

2014-05-29 Thread Chase Southwood
Move the function apci1564_interrupt() from hwdrv_apci1564.c to
addi_apci_1564.c.  On moving, for now just strip out all of the
code for interrupts that the driver does not yet support at this
time.

Rename the variable ui_InterruptStatus_1564 to ctrl, and change the return
from IRQ_RETVAL(1) to IRQ_HANDLED.

We also check the device is asserting the shared interrupt line and check
that interrupts have been enabled.

Signed-off-by: Chase Southwood chase.southw...@gmail.com
Cc: Ian Abbott abbo...@mev.co.uk
Cc: H Hartley Sweeten hswee...@visionengravers.com
---

Admittedly, I am not sure if what I have done in the interrupt handler is
quite sufficient.  Am I missing anything that should be there due to the
fact that the handler does not yet support all of the types of interrupt
that the board is capable of issuing (i.e. does the interrupt handler need
to clear the other interrupts just in case they get triggered, etc?)

 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 130 -
 drivers/staging/comedi/drivers/addi_apci_1564.c|  34 +-
 2 files changed, 30 insertions(+), 134 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 41aa889..ebd763b 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -90,7 +90,6 @@
 #define APCI1564_TCW_WARN_TIMEBASE_REG(x)  (0x1c + ((x) * 0x20))
 
 /* Global variables */
-static unsigned int ui_InterruptStatus_1564;
 static unsigned int ui_InterruptData, ui_Type;
 
 struct apci1564_private {
@@ -367,132 +366,3 @@ static int apci1564_do_read(struct comedi_device *dev,
*data = ui_Type;
return insn-n;
 }
-
-/*
- * Interrupt handler for the interruptible digital inputs
- */
-static void apci1564_interrupt(int irq, void *d)
-{
-   struct comedi_device *dev = d;
-   struct apci1564_private *devpriv = dev-private;
-   unsigned int ui_DO, ui_DI;
-   unsigned int ui_Timer;
-   unsigned int ui_C1, ui_C2, ui_C3, ui_C4;
-   unsigned int ul_Command2 = 0;
-
-   ui_DI = inl(devpriv-amcc_iobase + APCI1564_DI_IRQ_REG)  0x01;
-   ui_DO = inl(devpriv-amcc_iobase + APCI1564_DO_IRQ_REG)  0x01;
-   ui_Timer = inl(devpriv-amcc_iobase + APCI1564_TIMER_IRQ_REG)  0x01;
-   ui_C1 =
-   inl(dev-iobase + APCI1564_TCW_IRQ_REG(APCI1564_COUNTER1))  
0x1;
-   ui_C2 =
-   inl(dev-iobase + APCI1564_TCW_IRQ_REG(APCI1564_COUNTER2))  
0x1;
-   ui_C3 =
-   inl(dev-iobase + APCI1564_TCW_IRQ_REG(APCI1564_COUNTER3))  
0x1;
-   ui_C4 =
-   inl(dev-iobase + APCI1564_TCW_IRQ_REG(APCI1564_COUNTER4))  
0x1;
-   if (ui_DI == 0  ui_DO == 0  ui_Timer == 0  ui_C1 == 0
-ui_C2 == 0  ui_C3 == 0  ui_C4 == 0) {
-   dev_err(dev-class_dev, Interrupt from unknown source.\n);
-   }
-
-   if (ui_DI == 1) {
-   ui_DI = inl(devpriv-amcc_iobase + APCI1564_DI_IRQ_REG);
-   outl(0x0, devpriv-amcc_iobase + APCI1564_DI_IRQ_REG);
-   ui_InterruptStatus_1564 =
-   inl(devpriv-amcc_iobase + APCI1564_DI_INT_STATUS_REG);
-   ui_InterruptStatus_1564 = ui_InterruptStatus_1564  0X0000;
-   /* enable the interrupt */
-   outl(ui_DI, devpriv-amcc_iobase + APCI1564_DI_IRQ_REG);
-   return;
-   }
-
-   if (ui_DO == 1) {
-   /* Check for Digital Output interrupt Type */
-   /* 1: VCC interrupt*/
-   /* 2: CC interrupt */
-   ui_Type = inl(devpriv-amcc_iobase + 
APCI1564_DO_INT_STATUS_REG)  0x3;
-   /* Disable the  Interrupt */
-   outl(0x0, devpriv-amcc_iobase + APCI1564_DO_INT_CTRL_REG);
-
-   }
-
-   if (ui_Timer == 1) {
-   devpriv-timer_select_mode = ADDIDATA_TIMER;
-   if (devpriv-timer_select_mode) {
-
-   /*  Disable Timer Interrupt */
-   ul_Command2 = inl(devpriv-amcc_iobase + 
APCI1564_TIMER_CTRL_REG);
-   outl(0x0, devpriv-amcc_iobase + 
APCI1564_TIMER_CTRL_REG);
-
-   /*  Enable Timer Interrupt */
-
-   outl(ul_Command2, devpriv-amcc_iobase + 
APCI1564_TIMER_CTRL_REG);
-   }
-   }
-
-   if (ui_C1 == 1) {
-   devpriv-timer_select_mode = ADDIDATA_COUNTER;
-   if (devpriv-timer_select_mode) {
-
-   /*  Disable Counter Interrupt */
-   ul_Command2 =
-   inl(dev-iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
-   outl(0x0,
-dev-iobase + 
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
-
-   /*  Enable Counter Interrupt */
-   

Re: [RFC PATCH 3/3] clk: tegra: Implement Tegra124 shared/cbus clks

2014-05-29 Thread Mike Turquette
Quoting Nishanth Menon (2014-05-29 16:22:45)
 On 05/26/2014 08:07 AM, Thierry Reding wrote:
  On Wed, May 14, 2014 at 12:35:18PM -0700, Mike Turquette wrote:
  Quoting Thierry Reding (2014-05-14 07:27:40)
  [...]
  As for shared clocks I'm only aware of one use-case, namely EMC scaling.
  Using clocks for that doesn't seem like the best option to me. While it
  can probably fix the immediate issue of choosing an appropriate
  frequency for the EMC clock it isn't a complete solution for the problem
  that we're trying to solve. From what I understand EMC scaling is one
  part of ensuring quality of service. The current implementations of that
  seems to abuse clocks (essentially one X.emc clock per X clock) to
  signal the amount of memory bandwidth required by any given device. But
  there are other parts to the puzzle. Latency allowance is one. The value
  programmed to the latency allowance registers for example depends on the
  EMC frequency.
 
  Has anyone ever looked into using a different framework to model all of
  these requirements? PM QoS looks like it might fit, but if none of the
  existing frameworks have what we need, perhaps something new can be
  created.
 
  It has been discussed. Using a QoS throughput constraint could help
  scale frequency. But this deserves a wider discussion and starts to
  stray into both PM QoS territory and also into should we have a DVFS
  framework territory.
  
  I've looked into this for a bit and it doesn't look like PM QoS is going
  to be a good match after all. One of the issues I found was that PM QoS
  deals with individual devices and there's no builtin way to collect the
  requests from multiple devices to produce a global constraint. So if we
  want to add something like that either the API would need to be extended
  or it would need to be tacked on using the notifier mechanism and some
  way of tracking (and filtering) the individual devices.
  
  Looking at devfreq it seems to be the DVFS framework that you mentioned,
  but from what I can tell it suffers from mostly the same problems. The
  governor applies some frequency scaling policy to a single device and
  does not allow multiple devices to register constraints against a single
  (global) constraint so that the result can be accumulated.
  
  For Tegra EMC scaling what we need is something more along the lines of
  this: we have a resource (external memory) that is shared by multiple
  devices in the system. Each of those devices requires a certain amount
  of that resource (memory bandwidth). The resource driver will need to
  accumulate all requests for the resource and apply the resulting
  constraint so that all requests can be satisfied.
  
  One solution I could imagine to make this work with PM QoS would be to
  add the concept of a pm_qos_group to manage a set of pm_qos_requests,
  but that will require a bunch of extra checks to make sure that requests
  are of the correct type and so on. In other words it would still be
  tacked on.
 
 just a minor note from previous experience: We(at TI) had attempted in
 our product kernel[1] to use QoS constraint for certain SoCs for
 rather unspectacular results.
 
 Our use case was similar: devices - L3(core bus)-memory. We had the
 following intent:
 a) wanted to scale L3 based on QoS requests coming in from various
 device drivers. intent was to scale either to 133MHz or 266MHz (two
 OPPs we supported on our devices) based on performance needs - So we
 asked drivers to report QoS requirements using an standard function -
 except drivers cannot always report it satisfactorily - example bursty
 transfer devices - ended up with consolidated requests  total
 bandwidth possible on the bus - (and never in practise hitting the
 lower frequency).

My opinion on why L3 QoS failed on OMAP is that we only used it for
DVFS. The voltage domain corresponding to the L3 interconnect had only
two OPPs, which meant that drivers submitting their constraints only had
two options: slow vs fast in the best case, or non-functional vs
functional in the worst case (some IPs simply did not work at the lower
OPP).

But the big failure in my opinion was that we did not use any of the
traffic-shaping or priority handling features of the L3 NoC. OMAP4 used
the Arteris NoC[1] which has plenty of capabilities for setting
initiator priorities and bandwidth-throttling on a point-to-point basis,
which is exactly that QoS is for. If these had been exposed a bit more
in software then I imagine some of the constraints that always resulted
in running at the fast OPP might have instead resulted in running at the
slow OPP, but with a fine-grained mixture of varying bandwidth
allocations and access priorities.

All of the hardware in the world doesn't do any good if we don't have
software that uses it. Anyways, just my $0.02.

Regards,
Mike

[1] http://www.arteris.com/OMAP4_QoS_security_NoC

 b) timing closure issues on certain devices such as USB - which can
 only function based on 

Re: [PATCH 18/27] perf tools: Add callback function to hist_entry_iter

2014-05-29 Thread Namhyung Kim
On Thu, 29 May 2014 15:16:51 +0200, Jiri Olsa wrote:
 On Thu, May 29, 2014 at 12:58:21PM +0900, Namhyung Kim wrote:
 +static int hist_iter__report_callback(struct hist_entry_iter *iter,
 +  struct addr_location *al, void *arg)
 +{
 +int err = 0;
 +struct hist_entry *he = iter-he;
 +struct perf_evsel *evsel = iter-evsel;
 +struct report *rep = arg;
 +
 +if (ui__has_annotation())
 +err = hist_entry__inc_addr_samples(he, evsel-idx, al-addr);

 if we put the annotation stats in here, shouldn't we remove all other
 instancies of above call from:

   iter_finish_normal_entry
   iter_add_single_cumulative_entry
   iter_finish_mem_entry

Right, they were double counted..  :-/  I changed this as below and push
to perf/cumulate-v12.  Would you please check it again?

Thanks,
Namhyung


From 0be9139edf446a5d6d753698f42809b2212dcf76 Mon Sep 17 00:00:00 2001
From: Namhyung Kim namhy...@kernel.org
Date: Tue, 7 Jan 2014 17:02:25 +0900
Subject: [PATCH] perf tools: Add callback function to hist_entry_iter

The new -add_entry_cb() will be called after an entry was added to
the histogram.  It's used for code sharing between perf report and
perf top.  Note that ops-add_*_entry() should set iter-he properly
in order to call the -add_entry_cb.

Also pass @arg to the callback function.  It'll be used by perf top
later.

Tested-by: Arun Sharma asha...@fb.com
Tested-by: Rodrigo Campos rodr...@sdfg.com.ar
Acked-by: Jiri Olsa jo...@redhat.com
Cc: Frederic Weisbecker fweis...@gmail.com
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
 tools/perf/builtin-report.c | 61 -
 tools/perf/tests/hists_filter.c |  2 +-
 tools/perf/tests/hists_output.c |  2 +-
 tools/perf/util/hist.c  | 67 +++--
 tools/perf/util/hist.h  |  5 ++-
 5 files changed, 84 insertions(+), 53 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 6cac509212ee..21d830bafff3 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -80,14 +80,59 @@ static int report__config(const char *var, const char 
*value, void *cb)
return perf_default_config(var, value, cb);
 }
 
-static void report__inc_stats(struct report *rep,
- struct hist_entry *he __maybe_unused)
+static void report__inc_stats(struct report *rep, struct hist_entry *he)
 {
/*
-* We cannot access @he at this time.  Just assume it's a new entry.
-* It'll be fixed once we have a callback mechanism in hist_iter.
+* The @he is either of a newly created one or an existing one
+* merging current sample.  We only want to count a new one so
+* checking -nr_events being 1.
 */
-   rep-nr_entries++;
+   if (he-stat.nr_events == 1)
+   rep-nr_entries++;
+}
+
+static int hist_iter__report_callback(struct hist_entry_iter *iter,
+ struct addr_location *al, bool single,
+ void *arg)
+{
+   int err = 0;
+   struct report *rep = arg;
+   struct hist_entry *he = iter-he;
+   struct perf_evsel *evsel = iter-evsel;
+   struct mem_info *mi;
+   struct branch_info *bi;
+
+   report__inc_stats(rep, he);
+
+   if (!ui__has_annotation())
+   return 0;
+
+   if (sort__mode == SORT_MODE__BRANCH) {
+   bi = he-branch_info;
+   err = addr_map_symbol__inc_samples(bi-from, evsel-idx);
+   if (err)
+   goto out;
+
+   err = addr_map_symbol__inc_samples(bi-to, evsel-idx);
+
+   } else if (rep-mem_mode) {
+   mi = he-mem_info;
+   err = addr_map_symbol__inc_samples(mi-daddr, evsel-idx);
+   if (err)
+   goto out;
+
+   err = hist_entry__inc_addr_samples(he, evsel-idx, al-addr);
+
+   } else if (symbol_conf.cumulate_callchain) {
+   if (single)
+   err = hist_entry__inc_addr_samples(he, evsel-idx,
+  al-addr);
+   } else {
+   err = hist_entry__inc_addr_samples(he, evsel-idx, al-addr);
+   }
+
+out:
+   return err;
 }
 
 static int process_sample_event(struct perf_tool *tool,
@@ -100,6 +145,7 @@ static int process_sample_event(struct perf_tool *tool,
struct addr_location al;
struct hist_entry_iter iter = {
.hide_unresolved = rep-hide_unresolved,
+   .add_entry_cb = hist_iter__report_callback,
};
int ret;
 
@@ -127,9 +173,8 @@ static int process_sample_event(struct perf_tool *tool,
if (al.map != NULL)
al.map-dso-hit = 1;
 
-   report__inc_stats(rep, NULL);
-
-   ret = hist_entry_iter__add(iter, al, evsel, sample, rep-max_stack);
+   ret = 

Re: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]

2014-05-29 Thread Al Viro
On Thu, May 29, 2014 at 12:14:51PM -0700, Linus Torvalds wrote:
 Yeah, I don't think you can reproduce that, but I guess renaming
 directories into each other (two renames needed) could trigger an ABBA
 deadlock by changing the topological order of dentry/parent.
 
 I suspect there's no way in hell that tiny race will ever happen in
 practice, but let's not risk it.
 
 And your solution (to re-check after just taking the parent lock)
 seems sufficient and sane, since dentry_lock_for_move() will always
 take the parent lock(s) before we move a dentry.
 
 So that looks good to me.

BTW, how serious is the problem with __lockref_is_dead(dentry-d_lockref)
with only -d_parent-d_lock held?  From my reading of lib/lockref.c it
should be safe - we only do lockref_mark_dead() with -d_parent-d_lock
held, and it'll provide all the serialization and barriers we need.

If I'm right, we could get rid of DCACHE_DENTRY_KILLED completely and replace
checking for it with checking for negative -d_lockref.count.  There are two
places where we check for it; in shrink_dentry_list() we definitely can go
that way (we are holding -d_lock there) and it simplifies the code nicely.
In d_walk(), though (in the bit that used to be try_to_ascend() we only hold
-d_parent-d_lock.  It looks like that ought to be safe to replace
if (this_parent != child-d_parent ||  
 (child-d_flags  DCACHE_DENTRY_KILLED) ||
 need_seqretry(rename_lock, seq)) {
with
if (this_parent != child-d_parent ||  
 __lockref_is_dead(child-d_lockref) ||
 need_seqretry(rename_lock, seq)) {
and remove DCACHE_DENTRY_KILLED completely...

The other user (in shrink_dentry_list()) simplifies to
if (dentry-d_lockref.count != 0) {
bool can_free = dentry-d_flags  DCACHE_MAY_FREE;
spin_unlock(dentry-d_lock);
if (parent)
spin_unlock(parent-d_lock);
if (can_free)
dentry_free(dentry);
continue;
}
taking care of both the DCACHE_DENTRY_KILLED case and simple lazy dget
one, and that one's definitely safe and worth doing.

Would be nice if we could switch d_walk() one as well and kill that flag off,
though...

Basically, we have
spin_lock(A);
spin_lock(R.lock);
V = 1;
lockref_mark_dead(R);
...
as the only place where R goes dead and we want to replace
spin_lock(A);
if (V)
...
with
spin_lock(A);
if (__lockref_is_dead(R))
...
Unless I'm missing something subtle in lockref.c, that should be safe...
Comments?
--
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 v4 2/3] mfd: intel_soc_pmic: Crystal Cove support

2014-05-29 Thread Zhu, Lejun


On 5/29/2014 7:49 PM, Lee Jones wrote:
 On Thu, 29 May 2014, Zhu, Lejun wrote:
 
 This patch provides chip-specific support for Crystal Cove. Crystal
 Cove is the PMIC in Baytrail-T platform.
(...)
 +enum crystal_cove_irq {
 +PWRSRC_IRQ = 0,
 +THRM_IRQ,
 +BCU_IRQ,
 +ADC_IRQ,
 +CHGR_IRQ,
 +GPIO_IRQ,
 +VHDMIOCP_IRQ
 +};
 
 I can't help thinking that these should be nice clear #defines
 
 #define CRYSTAL_COVE_IRQ_PWSRC0
 ...
 #define CRYSTAL_COVE_IRQ_VHDMIOCP 6
 

Sure. I'll fix it.

Best Regards
Lejun

--
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 v4 3/3] mfd: intel_soc_pmic: Build files

2014-05-29 Thread Zhu, Lejun


On 5/29/2014 7:43 PM, Lee Jones wrote:
 This patch adds Intel SoC PMIC support to the build files.
 These changes shouldn't really be in a separate patch.
I'll move them into the first (core.c) patch.

Best Regards
Lejun


--
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 v4 1/3] mfd: intel_soc_pmic: Core driver

2014-05-29 Thread Zhu, Lejun


On 5/29/2014 7:40 PM, Lee Jones wrote:
 [...]
 
 +static int intel_soc_pmic_find_gpio_irq(struct device *dev)
 +{
 +struct gpio_desc *desc;
 +int irq;
 +
 +desc = devm_gpiod_get_index(dev, KBUILD_MODNAME, 0);
 
 What does KBUILD_MODNAME translate to?

It translates into intel_soc_pmic.

 
 +if (IS_ERR(desc)) {
 +dev_dbg(dev, Not using GPIO as interrupt.\n);
 
 You can't have a debug print, then return an err - use dev_err().

Actually returning ENOENT here is just a hardware difference. On some
boards the PMIC interrupt is from a GPIO line exposed by the CPU, on the
rest (e.g. Asus T100TA) it's not. When -ENOENT is returned, probe() will
simply use the IRQ provided by the I2C.

I will remove this line completely, and put a comment before the function.

 
 [...]
 
 +static int intel_soc_pmic_i2c_probe(struct i2c_client *i2c,
 +const struct i2c_device_id *id)
 +{
 +struct device *dev = i2c-dev;
 +struct intel_soc_pmic_config *config =
 +(struct intel_soc_pmic_config *)id-driver_data;
 +struct intel_soc_pmic *pmic;
 +int ret;
 +int irq;
 +
 +pmic = devm_kzalloc(dev, sizeof(*pmic), GFP_KERNEL);
 +dev_set_drvdata(dev, pmic);
 +
 +pmic-regmap = devm_regmap_init_i2c(i2c, config-regmap_config);
 +
 +irq = intel_soc_pmic_find_gpio_irq(dev);
 +if (irq  0)
 +pmic-irq = i2c-irq;
 +else
 +pmic-irq = irq;
 
 pmic-irq = (irq  0) ? i2c-irq : irq;

I'll fix it.

 +ret = regmap_add_irq_chip(pmic-regmap, pmic-irq,
 +  config-irq_flags | IRQF_ONESHOT,
 +  0, config-irq_chip,
 +  pmic-irq_chip_data);
 +if (ret)
 +goto err;
 
 Just return ret here and remove the 'err:' label.

I'll fix it.

 
 [...]
 
 +static const struct i2c_device_id intel_soc_pmic_i2c_id[] = {
 +{INT33FD:00, (kernel_ulong_t)intel_soc_pmic_config_crc},
 +{ }
 +};
 +MODULE_DEVICE_TABLE(i2c, intel_soc_pmic_i2c_id);
 +
 +static struct acpi_device_id intel_soc_pmic_acpi_match[] = {
 +{INT33FD, (kernel_ulong_t)intel_soc_pmic_config_crc},
 +{ },
 +};
 +MODULE_DEVICE_TABLE(acpi, intel_soc_pmic_acpi_match);
 
 Does ACPI have a match function to extact it's .driver_data attribute?
 
 If so, are you using it here? If not, why not?
 

The ACPI table is used in i2c_device_match(), and the i2c table is used
in i2c_device_probe(), so the id in the i2c table is actually fed to
intel_soc_pmic_probe(). But I only found out now that having the i2c
table alone is enough, because i2c_device_match will fallback to the i2c
table if there's no ACPI table. So to keep it simple, I'll remove the
ACPI table completely.

By the way, the GPIO child driver got reviewed-by from Linus Walleij,
but can't be merged because it depends on intel_soc_pmic.h. May I
include it in next version of the patch set and have it merged along
with the MFD driver?

Best Regards
Lejun
--
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: [PATCHSET 00/27] perf tools: Add support to accumulate hist periods (v11)

2014-05-29 Thread Namhyung Kim
On Thu, 29 May 2014 15:59:00 +0200, Jiri Olsa wrote:
 On Thu, May 29, 2014 at 12:58:03PM +0900, Namhyung Kim wrote:
 Hello,
 
 This is a new attempt to implement cumulative hist period report.
 This work begins from Arun's SORT_INCLUSIVE patch [1] but I completely
 rewrote it from scratch.
 
 This patchset basically adds period in a sample to every node in the
 callchain.  A hist_entry now has an additional fields to keep the
 cumulative period if --children option is given on perf report.
 
 I changed the option as a separate --children and added a new
 Children column (and renamed the default Overhead column into
 Self).  The output will be sorted by children (cumulative) overhead
 for now.  It also adds 'overhead_children' field to -F/--fields option
 to be selected by user and it'll show you N/A if the cumulation is
 not supported (due to missing callchain).
 
 I added Tested-by from Rodrigo Campos since this version is basically
 rebase of previous series + bugfix.  But it still needs to be tested
 more intensively IMHO.  Also note that, this will change default
 behavior of perf report/top if callchain is recorded, so might confuse
 old users.  Let's see how many of them come to shout. :)  I think we
 need to merge Jiri's TUI column header patch at least.
 
 
  * changes in v11:
   - factor out hists__inc_nr_samples  (Jiri)
   - remove unrelated change  (Jiri)
   - disable accumulation on branch or mem mode
   - slightly refactor hist_iter code

 apart from that comment I sent, I think it's ready to go in

Thanks!  As I said, I've pushed v12 to korg with change you commented.

And I also found that the overhead in perf_hpp__should_skip() is
strangely high.. will check your patch.

Thanks,
Namhyung
--
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: fs/dcache.c - BUG: soft lockup - CPU#5 stuck for 22s! [systemd-udevd:1667]

2014-05-29 Thread Linus Torvalds
On Thu, May 29, 2014 at 9:50 PM, Al Viro v...@zeniv.linux.org.uk wrote:

 BTW, how serious is the problem with __lockref_is_dead(dentry-d_lockref)
 with only -d_parent-d_lock held?  From my reading of lib/lockref.c it
 should be safe - we only do lockref_mark_dead() with -d_parent-d_lock
 held, and it'll provide all the serialization and barriers we need.

 If I'm right, we could get rid of DCACHE_DENTRY_KILLED completely

Yeah, I think that would be good. Except I think you should create a
dentry_is_dead() helper function that then has that if you hold the
dentry or parent lock, this is safe comment, because for lockref in
general you do need to have the lock in the lockref itself. The fact
that dentries have more locking is very much dentry-specific.

But with that, go wild. I'd love to get rid of some of the redundant stuff.

For another example, the

BUG_ON((int)dentry-d_lockref.count  0);

test makes very little sense any more with lockrefs and the whole dead
marker (that should make sure that it never gets incremented), but
exists due to the direct conversion.

  Linus
--
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 1/5] sc_phy:SmartCard(SC) PHY interface to SC controller

2014-05-29 Thread Satish Patel



On 5/29/2014 9:21 PM, Greg KH wrote:

On Thu, May 29, 2014 at 02:26:55PM +0530, Satish Patel wrote:



On 5/29/2014 12:14 AM, Greg KH wrote:

On Wed, May 28, 2014 at 02:27:13PM +0530, Satish Patel wrote:

+/**
+ * struct sc_phy - The basic smart card phy structure
+ *
+ * @dev: phy device
+ * @pdata: pointer to phy's private data structure
+ * @set_config: called to set phy's configuration
+ * @get_config: called to get phy's configuration
+ * @activate_card: perform smart card activation
+ * @deactivate_card: perform smart card de-activation
+ * @warm_reset: execute smart card warm reset sequence
+ * @register_card_activity_cb: register call back to phy device.
+ * This call back will be called on card insert or remove event
+ *
+ * smart card controller uses this interface to communicate with
+ * smart card via phy.Some smart card phy has multiple slots for
+ * cards. This inerface also enables controller to communicate with
+ * one or more smart card connected over phy.
+ */
+struct sc_phy {
+   /* phy's device pointer */
+   struct device *dev;


So this is the parent, right?  Why not embed a struct device into this
structure as well, further streaching out the device tree.


Do you mean to use dev-p for pdata ?


No, use the device itself.


I have kept it outside, to give easeness/pragmatic focal for new phy driver
development. Driver can make this pointer null and use above pointer.


Ick, no, that's not how the driver model works.  Each device in the
system needs a struct device, don't try to chain off of an existing
device like this.  Make it a real one.


+
+   /* phy's private data */
+   void *pdata;


If you do the above, then this pointer is not needed.



+
+   /* notify data, passed by interface user as a part of
+* register_notify API. Data should be passed back when
+* notification raised to the interface user
+*/
+   void *notify_data;


What makes this different from the pdata?

pdata is phy's private data, while notify_data is something phy will send to
smart card controller on some event, like card remove/insert/timeout etc..


That doesn't make much sense to me, why not just put that in the notify
function callback itself?


Little correction over here..
Here is brief flow
USIM(Smart Card Controller) register notification callback to smarcard phy.

usim-phy-register_notify(phy handle, callback fn, notify_data);
notify_data : pass back when callback function will be called by PHY


Smartcard PHY - USIM
blocking_notifier_call_chain(notifier, action, notify_data);

action : card insert/remove/overheat etc..
notify data: USIM data passing back (supplied at the time of cb 
registration)




Please either use the existing phy layer of the kernel, or make a real
subsystem here, don't try to put a tiny shim on top of an existing
struct device for this driver, that's not how subsystems in Linux are
done.

Why I am not using exiting PHY framework ?

We will be more than happy to adapt generic phy if it
includes/add support for smart card requirements like

1) Some smart card phy (TDA8026-NxP) has multiple slots for smart
cards. This interface enables controller to communicate with specific
smart card inserted to the specific phy's slot.
2) Warm reset to smart card inserted to phy slot.
3) Bit banging of smart card pins to support vendor specific memory
cards.
4) Notification of card insert/remove/overheat etc.
5) synchronous and asynchronous modes for smart card transaction




thanks,

greg k-h


--
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] clk: exynos5420: Keep aclk66_peric enabled during boot

2014-05-29 Thread Tomasz Figa
Hi,

On 30.05.2014 00:29, Mike Turquette wrote:
 Quoting Doug Anderson (2014-05-29 14:21:36)
 Right now if you've got earlyprintk enabled on exynos5420-peach-pit
 then you'll get a hang on boot.  Here's why:

 1. The i2c-s3c2410 driver will probe at subsys_initcall.  It will
enable its clock and disable it.  This is the clock i2c2.
 2. The act of disabling i2c2 will disable its parents.  In this case
the parent is aclk66_peric.  There are no other children of
aclk66_peric officially enabled, so aclk66_peric will be turned
off (despite being CLK_IGNORE_UNUSED, but that's by design).
 3. The next time you try to earlyprintk you'll do so without the UART
clock enabled.  That's because the UART clocks are also children of
aclk66_peric.  You'll hang.

 There's no good place to put a clock enable for earlyprintk, which is
 handled by a bunch of assembly code.  The best we can do is to handle
 this in the clock driver.

 Signed-off-by: Doug Anderson diand...@chromium.org
 ---
  drivers/clk/samsung/clk-exynos5420.c | 24 
  1 file changed, 24 insertions(+)

 diff --git a/drivers/clk/samsung/clk-exynos5420.c 
 b/drivers/clk/samsung/clk-exynos5420.c
 index 9d7d7ee..1e586be 100644
 --- a/drivers/clk/samsung/clk-exynos5420.c
 +++ b/drivers/clk/samsung/clk-exynos5420.c
 @@ -1172,11 +1172,17 @@ static struct of_device_id ext_clk_match[] 
 __initdata = {
 { },
  };
  
 +/* Keep these clocks on until late_initcall */
 +static const char *boot_clocks[] __initconst = {
 +   aclk66_peric,
 +};
 +
  /* register exynos5420 clocks */
  static void __init exynos5x_clk_init(struct device_node *np,
 enum exynos5x_soc soc)
  {
 struct samsung_clk_provider *ctx;
 +   int i;
  
 if (np) {
 reg_base = of_iomap(np, 0);
 @@ -1226,6 +1232,12 @@ static void __init exynos5x_clk_init(struct 
 device_node *np,
 }
  
 exynos5420_clk_sleep_init();
 +
 +   for (i = 0; i  ARRAY_SIZE(boot_clocks); i++) {
 +   struct clk *to_enable = __clk_lookup(boot_clocks[i]);
 
 How about replacing __clk_lookup with clk_get? You can keep the struct
 clk object hanging around for later...
 

Mike, correct me if I'm wrong, but I thought you need clkdev look-up
entry for clk_get() to find a clock. Here, this clock apparently don't
have one and you don't even have a struct device * to pass to clk_get(),
so even if you had a look-up entry, it would need to be a wildcard entry
(with NULL device), which wouldn't be too elegant.

Doug, isn't a similar thing needed for PM debug as well? Maybe having
this clock always ungated whenever DEBUG_LL is enabled would be enough?

Best regards,
Tomasz
--
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 v11 0/3] Exynos 5410 support

2014-05-29 Thread Tomasz Figa
Hi Andreas,

On 29.05.2014 20:00, Andreas Färber wrote:

[snip]

 Some of the low-hanging fruit like no heartbeat/SD LEDs, no RTC, no
 usb3503 and thus no network I'm already looking into myself. For now I'm
 putting everything into the SMDK .dts, but I guess we'll need to split
 off -odroidxu.dts and -pinctrl.dtsi at some point.

Odroid XU needs its own dts for sure. I think you can make a copy of
SMDK dts and name it -odroidxu straightaway and work further with it.

exynos5410-pinctrl.dtsi is used for generic SoC-wide pinctrl
definitions, such as pin banks and pin groups. There should be no
board-specific things defined in it. Instead respective board dts should
have them.

 
 What about graphics? The 5410 is an oddball in using PowerVR rather than
 Mali GPU - should a framebuffer on HDMI or DisplayPort work if we add DT
 nodes, or will the GPU require larger code changes?

The 3D GPU is completely independent from display controllers, which are
standard Samsung IP blocks, so you should be able to get unaccelerated
output using VP+Mixer+HDMI or FIMD+DP using existing drivers.

Best regards,
Tomasz
--
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] crypto: crc32c-pclmul - Use pmovzxdq to shrink K_table

2014-05-29 Thread George Spelvin
Olay, recompiled with the acpi-cpufreq driver, so the performance governor
actually works, pegging the frequency at 3900 MHz.

Existing (old) code:
[  455.641397] 
[  455.641397] testing speed of crc32c
[  455.641403] test  0 (   16 byte blocks,   16 bytes per update,   1 updates): 
73 cycles/operation,4 cycles/byte
[  455.641406] test  1 (   64 byte blocks,   16 bytes per update,   4 updates): 
   418 cycles/operation,6 cycles/byte
[  455.641409] test  2 (   64 byte blocks,   64 bytes per update,   1 updates): 
89 cycles/operation,1 cycles/byte
[  455.641411] test  3 (  256 byte blocks,   16 bytes per update,  16 updates): 
  1330 cycles/operation,5 cycles/byte
[  455.641417] test  4 (  256 byte blocks,   64 bytes per update,   4 updates): 
   502 cycles/operation,1 cycles/byte
[  455.641420] test  5 (  256 byte blocks,  256 bytes per update,   1 updates): 
   170 cycles/operation,0 cycles/byte
[  455.641422] test  6 ( 1024 byte blocks,   16 bytes per update,  64 updates): 
  4971 cycles/operation,4 cycles/byte
[  455.641440] test  7 ( 1024 byte blocks,  256 bytes per update,   4 updates): 
   805 cycles/operation,0 cycles/byte
[  455.641445] test  8 ( 1024 byte blocks, 1024 bytes per update,   1 updates): 
   371 cycles/operation,0 cycles/byte
[  455.641448] test  9 ( 2048 byte blocks,   16 bytes per update, 128 updates): 
  9839 cycles/operation,4 cycles/byte
[  455.641484] test 10 ( 2048 byte blocks,  256 bytes per update,   8 updates): 
  1436 cycles/operation,0 cycles/byte
[  455.641490] test 11 ( 2048 byte blocks, 1024 bytes per update,   2 updates): 
   824 cycles/operation,0 cycles/byte
[  455.641494] test 12 ( 2048 byte blocks, 2048 bytes per update,   1 updates): 
   494 cycles/operation,0 cycles/byte
[  455.641498] test 13 ( 4096 byte blocks,   16 bytes per update, 256 updates): 
 19561 cycles/operation,4 cycles/byte
[  455.641568] test 14 ( 4096 byte blocks,  256 bytes per update,  16 updates): 
  2757 cycles/operation,0 cycles/byte
[  455.641579] test 15 ( 4096 byte blocks, 1024 bytes per update,   4 updates): 
  1633 cycles/operation,0 cycles/byte
[  455.641586] test 16 ( 4096 byte blocks, 4096 bytes per update,   1 updates): 
   861 cycles/operation,0 cycles/byte
[  455.641590] test 17 ( 8192 byte blocks,   16 bytes per update, 512 updates): 
 39015 cycles/operation,4 cycles/byte
[  455.641729] test 18 ( 8192 byte blocks,  256 bytes per update,  32 updates): 
  5412 cycles/operation,0 cycles/byte
[  455.641749] test 19 ( 8192 byte blocks, 1024 bytes per update,   8 updates): 
  3106 cycles/operation,0 cycles/byte
[  455.641762] test 20 ( 8192 byte blocks, 4096 bytes per update,   2 updates): 
  1656 cycles/operation,0 cycles/byte
[  455.641769] test 21 ( 8192 byte blocks, 8192 bytes per update,   1 updates): 
  1639 cycles/operation,0 cycles/byte
[  480.885336] 
[  480.885336] testing speed of crc32c
[  480.885342] test  0 (   16 byte blocks,   16 bytes per update,   1 updates): 
81 cycles/operation,5 cycles/byte
[  480.885345] test  1 (   64 byte blocks,   16 bytes per update,   4 updates): 
   426 cycles/operation,6 cycles/byte
[  480.885348] test  2 (   64 byte blocks,   64 bytes per update,   1 updates): 
96 cycles/operation,1 cycles/byte
[  480.885350] test  3 (  256 byte blocks,   16 bytes per update,  16 updates): 
  1331 cycles/operation,5 cycles/byte
[  480.885356] test  4 (  256 byte blocks,   64 bytes per update,   4 updates): 
   497 cycles/operation,1 cycles/byte
[  480.885359] test  5 (  256 byte blocks,  256 bytes per update,   1 updates): 
   179 cycles/operation,0 cycles/byte
[  480.885361] test  6 ( 1024 byte blocks,   16 bytes per update,  64 updates): 
  4961 cycles/operation,4 cycles/byte
[  480.885380] test  7 ( 1024 byte blocks,  256 bytes per update,   4 updates): 
   795 cycles/operation,0 cycles/byte
[  480.885384] test  8 ( 1024 byte blocks, 1024 bytes per update,   1 updates): 
   366 cycles/operation,0 cycles/byte
[  480.885387] test  9 ( 2048 byte blocks,   16 bytes per update, 128 updates): 
  9827 cycles/operation,4 cycles/byte
[  480.885423] test 10 ( 2048 byte blocks,  256 bytes per update,   8 updates): 
  1445 cycles/operation,0 cycles/byte
[  480.885430] test 11 ( 2048 byte blocks, 1024 bytes per update,   2 updates): 
   834 cycles/operation,0 cycles/byte
[  480.885434] test 12 ( 2048 byte blocks, 2048 bytes per update,   1 updates): 
   495 cycles/operation,0 cycles/byte
[  480.885437] test 13 ( 4096 byte blocks,   16 bytes per update, 256 updates): 
 19560 cycles/operation,4 cycles/byte
[  480.885507] test 14 ( 4096 byte blocks,  256 bytes per update,  16 updates): 
  2767 cycles/operation,0 cycles/byte
[  480.885518] test 15 ( 4096 byte blocks, 1024 bytes per update,   4 updates): 
  1643 cycles/operation,0 cycles/byte
[  480.885525] test 16 ( 4096 byte blocks, 4096 bytes per update,  

Re: [PATCH v4 00/16] PCI/iommu: Fix DMA alias problems

2014-05-29 Thread Andrew Cooks
On Thu, May 29, 2014 at 4:29 AM, Bjorn Helgaas bhelg...@google.com wrote:
 On Thu, May 22, 2014 at 05:07:23PM -0600, Alex Williamson wrote:
 For testing, this version can be found in my git tree:

 git://github.com/awilliam/linux-vfio.git dma-alias-v4

 Please report any issues.

 v4:
  - Change dma_func_alias to dma_alias_devfn, holding a single
devfn to alias, thereby supporting aliases to the wrong slot.
The DMA alias iterator is easily changed, but IOMMU grouping
requires significant rework.  This is now done in IOMMU code
rather than PCI code.

  - AMD-Vi - try to incorporate IVRS aliases dynamically into
PCI alias quirks to make sure that our grouping remains the
same.  Potentially this could end up reporting BIOS aliases
that we can add to our list of quirks.

 v3:
  - Found several instances where I had PCI_SLOT when I meant
PCI_FUNC.  Thanks to Andrew for spotting this.  This should
fix the problem he was having with Ricoh quirks.  We also
pruned down the func0 quirks to only those that we know are
needed.  We can always add them back later.

  - Found a case in intel-iommu of using dev_is_pci() where I
really wanted !dev_is_pci().  Fixed.

 v2:
  - Several new Marvell controllers added to quirks.  There's been
a lot of success reported with this series in
https://bugzilla.kernel.org/show_bug.cgi?id=42679

  - Add quirk for ASMedia and Tundra PCIe-to-PCI bridges that do
not expose a PCIe capability.  These have been shown to use
the standard PCIe-to-PCI bridge requester ID.

  - Fix copy/paste duplicate Ricoh quirk ID

  - Fixed AMD IOMMU for the ghost function case where the DMA
alias is for an absent device.  The iommu rlookup table and
data fields need to be initializes.

  - Fixed Intel interrupt remapping, I wasn't passing the target
bus number, only the alias bus number.

 These patches are split across PCI and IOMMU, but I've front-loaded
 all of the PCI infrastructure so that the first 7 patches can be
 applied to PCI-core, the IOMMU maintainers can pickup their patches,
 then we can finish with dead code removal.  Bjorn might also be
 willing to carry the IOMMU changes if the maintainers want to ack
 them.

 I put 1-7 on a pci/iommu branch for v3.16.  I'm happy to include the rest,
 too, given acks from Joerg and David.  Or if they prefer to take them all,
 which might be easier than coordinating two trees, especially since there's
 PCI stuff at the beginning and end, here's my ack for the PCI bits (patches
 1-7 and 15-16):

 Acked-by: Bjorn Helgaas bhelg...@google.com

 If you want to send me updated changelogs for patches 5  6, I'll drop
 those in.

 Didn't you have more testing reports?  I see George's, but I thought there
 were some others, too.

Tested-by: Andrew Cooks aco...@linux.com

I've reviewed parts of this patch set, over multiple iterations, if
that's worth anything.

 Original description:

 This series attempts to fix a couple issues we've had outstanding in
 the PCI/IOMMU code for a while.  The first issue is with devices that
 use the wrong requester ID for DMA transactions.  We already have a
 sort of half-baked attempt to fix this for several Ricoh devices, but
 the fix only helps them be useful through IOMMU groups, not the
 general DMA case.  There are also several Marvell devices which use
 use a different wrong requester ID and don't even fit into the DMA
 source idea.  This series creates a DMA alias iterator that will
 step through each possible alias of a device, allowing IOMMUs to
 insert mappings for both the device and its aliases.

 Hand-in-hand with this is our broken pci_find_upstream_pcie_bridge()
 function, which is known to blowup when it finds itself suddenly at
 a PCIe device without crossing a PCIe-to-PCI bridge (as identified by
 the PCIe capability).  It also likes to make the invalid assumption
 that a PCIe device never has its requester ID masked by any usptream
 bus.  We can fix this using the above new DMA alias iterator, since
 that's effectively what this function was meant to do.

 Finally, with all these helpers, it makes sense to consolidate code
 for determining IOMMU groups.  The first step in finding the root
 of a group is finding the final upstream DMA alias for the device,
 then applying additional ACS rules and incorporating device specific
 aliases.  As this is all common to PCI, create a single implementation
 and remove piles of code from the individual IOMMU drivers.

 This series allows devices like the Marvell 88SE9123 to finally work
 on Linux with either AMD-Vi or VT-d enabled on the box.  I've
 collected device IDs from various bugs to support as many SKUs of
 these devices as possible, but I'm sure there are others that I've
 missed.

 This should also enable motherboards with an onboard ASmedia
 ASM1083/1085 PCIe-to-PCI bridge to work with VT-d enabled.  I've
 acquired an adapter board with this chip, but it actually exposes
 a PCIe 

Re: [PATCH v2 03/18] PCI: designware: Configuration space should be specified in 'reg'

2014-05-29 Thread Kishon Vijay Abraham I
Hi,

On Thursday 29 May 2014 10:02 PM, Murali Karicheri wrote:
 On 5/29/2014 2:38 AM, ABRAHAM, KISHON VIJAY wrote:
 The configuration address space has so far been specified in *ranges*,
 however it should be specified in *reg* making it a platform MEM resource.
 Hence used 'platform_get_resource_*' API to get configuration address
 space in the designware driver.

 Cc: Jason Gunthorpe jguntho...@obsidianresearch.com
 Cc: Bjorn Helgaas bhelg...@google.com
 Cc: Mohit Kumar mohit.ku...@st.com
 Cc: Jingoo Han jg1@samsung.com
 Cc: Marek Vasut ma...@denx.de
 Cc: Arnd Bergmann a...@arndb.de
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
   .../devicetree/bindings/pci/designware-pcie.txt|1 +
   drivers/pci/host/pcie-designware.c |   17 +++--
   2 files changed, 16 insertions(+), 2 deletions(-)

 diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
 b/Documentation/devicetree/bindings/pci/designware-pcie.txt
 index d6fae13..8314360 100644
 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
 +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
 @@ -6,6 +6,7 @@ Required properties:
   as samsung,exynos5440-pcie or fsl,imx6q-pcie.
   - reg: base addresses and lengths of the pcie controller,
   the phy controller, additional register for the phy controller.
 +The configuration address space should also be specified here.
 Kishon,
 
 I am working on the Keystone PCI driver for which v1 is already posted. Want 
 to
 clarify
 following.
 1. Original text for reg states base addresses and lengths of the pcie
 controller,
 the phy controller, additional register for the phy controller and 
 you
 added
 The configuration address space should also be specified here
 
and the code below added resource name config
 
 Does PCI designware follow some convention? Does it mean after applying this 
 patch
 config name is mandatory or optional? Below code you are not returning error.
 Can you
 or author of PCI designware clarify what is expected to be present as 
 mandatory
 and
 what is optional.

From whatever I could make out from the comments for my previous version,
'config' is mandatory for all new platforms adding support for PCIe DW. However
since there already exists platforms that use 'ranges', I'm not returning
error. Once all the platforms that use DW is modified to use 'reg', will return
error.
 
 Does config refers to RC's config space or EP's config space or both? The code
 below divide

In the case of DRA7, it's the space from where you read the configuration space
contents of the EP (we have separate address space for the configuration space
of RC denoted by *rc_dbics* in this patch series). But there are other
platforms where RC does not have a separate configuration address space.
 the size by 2. So it appears to be RC's + EP's config space. Please clarify.

No. divide by 2 is for cfg1 and cfg1 is used by PCIe bridges.
 
   - interrupts: interrupt values for level interrupt,
   pulse interrupt, special interrupt.
   - clocks: from common clock binding: handle to pci clock.
 diff --git a/drivers/pci/host/pcie-designware.c
 b/drivers/pci/host/pcie-designware.c
 index c4e3732..603b386 100644
 --- a/drivers/pci/host/pcie-designware.c
 +++ b/drivers/pci/host/pcie-designware.c
 @@ -20,6 +20,7 @@
   #include linux/of_pci.h
   #include linux/pci.h
   #include linux/pci_regs.h
 +#include linux/platform_device.h
   #include linux/types.h
 #include pcie-designware.h
 @@ -392,11 +393,23 @@ static const struct irq_domain_ops msi_domain_ops = {
   int __init dw_pcie_host_init(struct pcie_port *pp)
   {
   struct device_node *np = pp-dev-of_node;
 +struct platform_device *pdev = to_platform_device(pp-dev);
   struct of_pci_range range;
   struct of_pci_range_parser parser;
 +struct resource *cfg_res;
   u32 val;
   int i;
   +cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, 
 config);
 +if (cfg_res) {
 +pp-config.cfg0_size = resource_size(cfg_res)/2;
 +pp-config.cfg1_size = resource_size(cfg_res)/2;
 +pp-cfg0_base = cfg_res-start;
 +pp-cfg1_base = cfg_res-start + pp-config.cfg0_size;
 +} else {
 +dev_err(pp-dev, missing *config* reg space\n);
 This should return error -EINVAL.

ah.. it'll break for other platforms. It should be part of a different patch
once we convert all users to 8reg*.
 
 +}
 +
   if (of_pci_range_parser_init(parser, np)) {
   dev_err(pp-dev, missing ranges property\n);
   return -EINVAL;
 @@ -429,6 +442,8 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
   of_pci_range_to_resource(range, np, pp-cfg);
   pp-config.cfg0_size = resource_size(pp-cfg)/2;
   pp-config.cfg1_size = resource_size(pp-cfg)/2;
 +pp-cfg0_base = pp-cfg.start;
 +pp-cfg1_base = pp-cfg.start + pp-config.cfg0_size;
   }
  

Re: [PATCHv5 2/4] mailbox: Introduce framework for mailbox

2014-05-29 Thread Jassi Brar
On Thu, May 29, 2014 at 9:13 PM, Matt Porter mpor...@linaro.org wrote:
 On Fri, May 16, 2014 at 07:03:25PM +0530, Jassi Brar wrote:
 On 15 May 2014 19:57, Arnd Bergmann a...@arndb.de wrote:
  On Thursday 15 May 2014 11:41:00 Jassi Brar wrote:

 ...

  +struct mbox_controller {
  + struct device *dev;
  + struct mbox_chan_ops *ops;
  + struct mbox_chan *chans;
  + int num_chans;
  + bool txdone_irq;
  + bool txdone_poll;
  + unsigned txpoll_period;
  + struct mbox_chan *(*of_xlate)(struct mbox_controller *mbox,
  + const struct of_phandle_args *sp);
  + /*
  +  * If the controller supports only TXDONE_BY_POLL,
  +  * this timer polls all the links for txdone.
  +  */
  + struct timer_list poll;
  + unsigned period;
  + /* Hook to add to the global controller list */
  + struct list_head node;
  +} __aligned(32);
 
  What is the __aligned(32) for?
 
 Attempt to align access to mailbox?

 I am still open to opinion about whether the mailbox ownership should
 be exclusive or shared among clients. Need to handle async messages
 from remote is one reason one might want more than one client to own a
 channel. Allowing for RX via notifiers might be one option but that
 breaks semantics of 'ownership' of a mailbox channel.

 This is the case we have on a new family of Broadcom SoCs. One mailbox
 channel is the system channel and is shared amongst many clients for
 reception of unsolicited events from the coprocessor. The same channel
 is also used commonly in drivers for debug/inspection of the M0 state.
 Functionality for clock, pmu, pinmux, and cpu idle/suspend is implemented
 via IPC with the M0 so all of those drivers need to share one mailbox.

OK, so you have a single mailbox channel used for communication with
the remote master.

 There's a lot of common code necessary to construct/parse IPCs for
 each of the drivers. I suppose this IPC driver/api could be the
 sole owner of that system channel. However, we'd need to develop some
 binding to represent IPC resources that devices need to operate. Coming
 into this late...I wonder if I missed something about where these vendor
 specific IPC layers should live and how, if it makes sense, they should
 be represented in DT. In our case, the IPC is an integral part of the
 hardware as it's loaded from ROM.

Like other platforms, the IPC protocol is going to be very specific to
Broadcom, even if the mailbox controller is some popular third party
IP like PL320. So you/Broadcom have to implement parser code for IPC
(client) above the mailbox common api and the controller driver below
it. Any resource/feature specific to your client and your controller
should be passed via some Broadcom specific DT bindings. The common
mailbox api DT bindings provide only for channel-client mapping.

 Being more specific to your platform, I think you need some server
code (mailbox's client) that every driver (like clock, pmu, pinmux
etc) registers with to send messages to remote and receive commands
from remote ... perhaps by registering some filter to sort out
messages for each driver.

-Jassi
--
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/3] lib: crc32: Greatly shrink CRC combining code

2014-05-29 Thread George Spelvin
There's no need for a full 32x32 matrix, when rows before the last are
just shifted copies of the rows after them.

There's still room for improvement (especially on X86 processors with
CRC32 and PCLMUL instructions), but this is a large step in the
right direction.

The internal primitive is now called crc32_generic_shift and takes one
less argument; the XOR with crc2 is done in inline wrappers.

Signed-off-by: George Spelvin li...@horizon.com
---
This is the significant patch; there other two patches are minor
cleanups that I did while in the area.

Tested extensively in user-space (the power variable is identical
to the last row of the current even/odd matrix in the previous code)
and with CONFIG_CRC32_SELFTEST:

[0.587152] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
[0.587186] crc32: self tests passed, processed 225944 bytes in 115727 nsec
[0.587341] crc32c: CRC_LE_BITS = 64
[0.587373] crc32c: self tests passed, processed 225944 bytes in 59505 nsec
[0.596827] crc32_combine: 8373 self tests passed
[0.606259] crc32c_combine: 8373 self tests passed

Code shrunk; comments increased to match.
Pulling 2x32x32 bits = 256 bytes off the stack is a nice bonus.

 include/linux/crc32.h |  12 -
 lib/crc32.c   | 142 +++---
 2 files changed, 76 insertions(+), 78 deletions(-)

diff --git a/include/linux/crc32.h b/include/linux/crc32.h
index 7d275c4f..bcb8e9d3 100644
--- a/include/linux/crc32.h
+++ b/include/linux/crc32.h
@@ -29,7 +29,11 @@ extern u32  crc32_be(u32 crc, unsigned char const *p, size_t 
len);
  *with the same initializer as crc1, and crc2 seed was 0. See
  *also crc32_combine_test().
  */
-extern u32  crc32_le_combine(u32 crc1, u32 crc2, size_t len2);
+u32  crc32_le_shift(u32 crc, size_t len) __attribute_const__;
+static inline u32  crc32_le_combine(u32 crc1, u32 crc2, size_t len2)
+{
+   return crc32_le_shift(crc1, len2) ^ crc2;
+}
 
 extern u32  __crc32c_le(u32 crc, unsigned char const *p, size_t len);
 
@@ -51,7 +55,11 @@ extern u32  __crc32c_le(u32 crc, unsigned char const *p, 
size_t len);
  *seeded with the same initializer as crc1, and crc2 seed
  *was 0. See also crc32c_combine_test().
  */
-extern u32  __crc32c_le_combine(u32 crc1, u32 crc2, size_t len2);
+u32  __crc32c_le_shift(u32 crc, size_t len) __attribute_const__;
+static inline u32  __crc32c_le_combine(u32 crc1, u32 crc2, size_t len2)
+{
+   return __crc32c_le_shift(crc1, len2) ^ crc2;
+}
 
 #define crc32(seed, data, length)  crc32_le(seed, (unsigned char const 
*)(data), length)
 
diff --git a/lib/crc32.c b/lib/crc32.c
index 70f00ca5..a4a576f3 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -50,29 +50,6 @@ MODULE_AUTHOR(Matt Domsch matt_dom...@dell.com);
 MODULE_DESCRIPTION(Various CRC32 calculations);
 MODULE_LICENSE(GPL);
 
-#define GF2_DIM32
-
-static u32 gf2_matrix_times(u32 *mat, u32 vec)
-{
-   u32 sum = 0;
-
-   while (vec) {
-   if (vec  1)
-   sum ^= *mat;
-   vec = 1;
-   mat++;
-   }
-
-   return sum;
-}
-
-static void gf2_matrix_square(u32 *square, u32 *mat)
-{
-   int i;
-
-   for (i = 0; i  GF2_DIM; i++)
-   square[i] = gf2_matrix_times(mat, mat[i]);
-}
 
 #if CRC_LE_BITS  8 || CRC_BE_BITS  8
 
@@ -155,51 +132,6 @@ crc32_body(u32 crc, unsigned char const *buf, size_t len, 
const u32 (*tab)[256])
 }
 #endif
 
-/* For conditions of distribution and use, see copyright notice in zlib.h */
-static u32 crc32_generic_combine(u32 crc1, u32 crc2, size_t len2,
-u32 polynomial)
-{
-   u32 even[GF2_DIM]; /* Even-power-of-two zeros operator */
-   u32 odd[GF2_DIM];  /* Odd-power-of-two zeros operator  */
-   u32 row;
-   int i;
-
-   if (len2 = 0)
-   return crc1;
-
-   /* Put operator for one zero bit in odd */
-   odd[0] = polynomial;
-   row = 1;
-   for (i = 1; i  GF2_DIM; i++) {
-   odd[i] = row;
-   row = 1;
-   }
-
-   gf2_matrix_square(even, odd); /* Put operator for two zero bits in even 
*/
-   gf2_matrix_square(odd, even); /* Put operator for four zero bits in odd 
*/
-
-   /* Apply len2 zeros to crc1 (first square will put the operator for one
-* zero byte, eight zero bits, in even).
-*/
-   do {
-   /* Apply zeros operator for this bit of len2 */
-   gf2_matrix_square(even, odd);
-   if (len2  1)
-   crc1 = gf2_matrix_times(even, crc1);
-   len2 = 1;
-   /* If no more bits set, then done */
-   if (len2 == 0)
-   break;
-   /* Another iteration of the loop with odd and even swapped */
-   gf2_matrix_square(odd, even);
-   if (len2  1)
-   crc1 = gf2_matrix_times(odd, crc1);
-   len2 = 1;
- 

[PATCH 2/3] lib: crc32: mark test data __initconst

2014-05-29 Thread George Spelvin
From 1ecab5281e3cfc8c2a61648410c8b25ba2654fcb Mon Sep 17 00:00:00 2001
From: George Spelvin li...@horizon.com
Date: Thu, 29 May 2014 00:08:03 -0400
Subject: [PATCH 2/3] lib: crc32: mark test data __initconst

So it gets discarded after the selftest.

Signed-off-by: George Spelvin li...@horizon.com
---
This is the patch I started with, when I was looking for lib/ self-test
code to emulate for my still-pending glob.c code.  But curiosity about
the combine code led me notice problems with it, and to study the
arch/x86/crypto code, where I also have a proposed patch.

Aren't tangents fun?

 lib/crc32.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/crc32.c b/lib/crc32.c
index a4a576f3..977167d6 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -341,7 +341,7 @@ EXPORT_SYMBOL(crc32_be);
 #ifdef CONFIG_CRC32_SELFTEST
 
 /* 4096 random bytes */
-static u8 __attribute__((__aligned__(8))) test_buf[] =
+static u8 const __aligned(8) test_buf[] __initconst =
 {
0x5b, 0x85, 0x21, 0xcb, 0x09, 0x68, 0x7d, 0x30,
0xc7, 0x69, 0xd7, 0x30, 0x92, 0xde, 0x59, 0xe4,
@@ -865,7 +865,7 @@ static struct crc_test {
u32 crc_le; /* expected crc32_le result */
u32 crc_be; /* expected crc32_be result */
u32 crc32c_le;  /* expected crc32c_le result */
-} test[] =
+} const test[] __initconst =
 {
{0x674bf11d, 0x0038, 0x0542, 0x0af6d466, 0xd8b6e4c1, 
0xf6e93d6c},
{0x35c672c6, 0x003a, 0x01aa, 0xc6d3dfba, 0x28aaf3ad, 
0x0fe92aca},
-- 
1.9.2

--
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 3/3] lib: crc32: Add some additional __pure annotations

2014-05-29 Thread George Spelvin
In case they help the compiler.

Signed-off-by: George Spelvin li...@horizon.com
---
As long as I'm messing with it.  I also have a large patch to do this
to a number of lib/ headers if anyone wants.

Redundant extern removed to keep things within 80 columns.

 include/linux/crc32.h | 6 +++---
 lib/crc32.c   | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/crc32.h b/include/linux/crc32.h
index bcb8e9d3..25e57f3a 100644
--- a/include/linux/crc32.h
+++ b/include/linux/crc32.h
@@ -8,8 +8,8 @@
 #include linux/types.h
 #include linux/bitrev.h
 
-extern u32  crc32_le(u32 crc, unsigned char const *p, size_t len);
-extern u32  crc32_be(u32 crc, unsigned char const *p, size_t len);
+u32  crc32_le(u32 crc, unsigned char const *p, size_t len) __pure;
+u32  crc32_be(u32 crc, unsigned char const *p, size_t len) __pure;
 
 /**
  * crc32_le_combine - Combine two crc32 check values into one. For two
@@ -35,7 +35,7 @@ static inline u32  crc32_le_combine(u32 crc1, u32 crc2, 
size_t len2)
return crc32_le_shift(crc1, len2) ^ crc2;
 }
 
-extern u32  __crc32c_le(u32 crc, unsigned char const *p, size_t len);
+u32  __crc32c_le(u32 crc, unsigned char const *p, size_t len) __pure;
 
 /**
  * __crc32c_le_combine - Combine two crc32c check values into one. For two
diff --git a/lib/crc32.c b/lib/crc32.c
index 977167d6..cf0c8e08 100644
--- a/lib/crc32.c
+++ b/lib/crc32.c
@@ -54,7 +54,7 @@ MODULE_LICENSE(GPL);
 #if CRC_LE_BITS  8 || CRC_BE_BITS  8
 
 /* implements slicing-by-4 or slicing-by-8 algorithm */
-static inline u32
+static inline u32 __pure
 crc32_body(u32 crc, unsigned char const *buf, size_t len, const u32 
(*tab)[256])
 {
 # ifdef __LITTLE_ENDIAN
-- 
1.9.2

--
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 0/2] x86,vdso: vdso build fixes and improvements

2014-05-29 Thread Stephen Rothwell
Hi Andy,

On Thu, 29 May 2014 15:49:52 -0700 Andy Lutomirski l...@amacapital.net wrote:

 On Thu, May 29, 2014 at 3:41 PM, Paul Gortmaker
 paul.gortma...@windriver.com wrote:
  On 14-05-29 05:57 PM, Andy Lutomirski wrote:
  Patch 1 causes make;make to behave similarly to make if vdso2c fails.
  Patch 2 hopefully fixes x86 crossbuilds on big-endian machines.  I don't
  have a big-endian machine to test on, though.
 
  Since the x86 builds are unconditionally failing as-is now in
  linux-next, perhaps Stephen [Cc'd] can layer these on the top of
  the tree he'll be making within the next couple of hours to give
  them a big-endian test.

I added them just after the merge of the tip tree today and will keep
them there until they (or somo other solution) turn up some other way.

 Stephen, if you do this, could you also send me some of the build outputs:
 
 arch/x86/vdso/*.so.dbg
 arch/x86/vdso/*-image-*.c
 
 I'd like to verify that the output is correct.  It would be
 unfortunate if the cross-built kernel had some subtle error.

OK, I will send them in a separate email.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature


Re: [RFC/PATCH 0/2] perf tools: Factor sort elide

2014-05-29 Thread Namhyung Kim
On Fri, 23 May 2014 17:15:45 +0200, Jiri Olsa wrote:
 hi,
 factoring the elide code to make perf_hpp__should_skip
 function cheap call/check again.

Both look good to me!

Acked-by: Namhyung Kim namhy...@kernel.org



 Also I was wondering.. do we want to get rid of sort_entry
 structs in favor of perf_hpp__* stuff? Any plans?

Probably.. but there's no plan for me currently. :)

Thanks,
Namhyung
--
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: imx: disable the receiver ready interrupt for imx_stop_rx

2014-05-29 Thread Dirk Behme

On 23.05.2014 06:32, Huang Shijie wrote:

This patch disables the receiver ready interrupt for imx_stop_rx.
It reduces the interrupt numbers when the uart is going to close
or suspend.

Signed-off-by: Huang Shijie b32...@freescale.com
---
  drivers/tty/serial/imx.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index ed6cdf7..6026101 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -440,6 +440,10 @@ static void imx_stop_rx(struct uart_port *port)

temp = readl(sport-port.membase + UCR2);
writel(temp  ~UCR2_RXEN, sport-port.membase + UCR2);
+
+   /* disable the `Receiver Ready Interrrupt` */
+   temp = readl(sport-port.membase + UCR1);
+   writel(temp  ~UCR1_RRDYEN, sport-port.membase + UCR1);


Will this change cause a loss or a processing delay of RX characters 
pending in the RX FIFO ?


It is not clear whether disabling the receiver will clear the RX FIFO. 
My guess is that the contents of the RX FIFO will remain intact when 
the receiver is disabled. The RX interrupt has an opportunity to mop 
up these pending characters in the RX FIFO but disabling the RX 
interrupt has potential to leave those characters in the RX FIFO. Does 
it matter ?


Thanks

Dirk

--
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]x86 efi: do not export efi runtime map in case old map

2014-05-29 Thread Dave Young
Ccing Simon.

Simon, appologize for not ccing you about this kernel patch. I see you have
applied the userspace patch for checking sysfs runtime existance.

The userspace patch depends on this patch but it is not harmful even without
this kernel patch. So applying the userspace patch before this one is still
safe.

On 05/30/14 at 11:20am, Dave Young wrote:
 
 For ioremapped efi memory aka old_map the virt addresses are not persistant
 across kexec reboot. kexec-tools will read the runtime maps from sysfs then
 pass them to 2nd kernel and assuming kexec efi boot is ok. This will cause
 kexec boot failure.
 
 To address this issue do not export runtime maps in case efi old_map so
 userspace can use no efi boot instead.
 
 Signed-off-by: Dave Young dyo...@redhat.com
 ---
  arch/x86/platform/efi/efi.c | 3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
 index 3781dd3..4d36932 100644
 --- a/arch/x86/platform/efi/efi.c
 +++ b/arch/x86/platform/efi/efi.c
 @@ -919,6 +919,9 @@ static void __init save_runtime_map(void)
   void *tmp, *p, *q = NULL;
   int count = 0;
  
 + if (efi_enabled(EFI_OLD_MEMMAP))
 + return;
 +
   for (p = memmap.map; p  memmap.map_end; p += memmap.desc_size) {
   md = p;
  
 -- 
 1.8.3.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/
--
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] staging: android: fix Missing a blank line after declarations warnings

2014-05-29 Thread Scott Weir
On Wed, May 28, 2014 at 02:30:27PM -0700, Greg KH wrote:
 On Wed, May 28, 2014 at 06:52:51PM +1000, Scott Weir wrote:
  This patch corrects coding style issue:
  WARNING: Missing a black line after declarations
  
  Signed-off-by: Scott Weir sjw0...@gmail.com
  ---
   drivers/staging/android/sync_debug.c | 4 
 
 This file isn't in my tree.  Always work against linux-next, not Linus's
 tree for new patches.
 
 thanks,
 
 greg k-h

This patch was made against linux-next. Is it better to use your staging tree?

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] block: virtio_blk: don't hold spin lock during world switch

2014-05-29 Thread Ming Lei
On Fri, May 30, 2014 at 11:35 AM, Jens Axboe ax...@kernel.dk wrote:
 On 2014-05-29 21:34, Ming Lei wrote:

 On Fri, May 30, 2014 at 11:19 AM, Jens Axboe ax...@kernel.dk wrote:

 On 2014-05-29 20:49, Ming Lei wrote:


 Firstly, it isn't necessary to hold lock of vblk-vq_lock
 when notifying hypervisor about queued I/O.

 Secondly, virtqueue_notify() will cause world switch and
 it may take long time on some hypervisors(such as, qemu-arm),
 so it isn't good to hold the lock and block other vCPUs.

 On arm64 quad core VM(qemu-kvm), the patch can increase I/O
 performance a lot with VIRTIO_RING_F_EVENT_IDX enabled:
  - without the patch: 14K IOPS
  - with the patch: 34K IOPS



 Patch looks good to me. I don't see a hit on my qemu-kvm testing, but it
 definitely makes sense and I can see it hurting in other places.


 It isn't easy to observe the improvement on x86 VM, especially
 with few vCPUs, because qemu-system-x86_64 only takes
 several microseconds to handle the notification, but on arm64, it
 may take hundreds of microseconds, so the improvement is
 obvious on arm VM.

 I hope this patch can be merged, at least arm VM can benefit
 from it.


 If Rusty agrees, I'd like to add it for 3.16 with a stable marker.

Interesting, even on x86, I still can observe the improvement
when the numjobs is set as 2 in the fio script(see commit log), but
when numjobs is set as 4, 8, 12, the difference isn't obvious between
patched kernel and non-patched kernel.

1, environment
- host: 2sockets, each CPU(4cores, 2 threads), total 16 logical cores
- guest: 16cores, 8GB ram
- guest kernel: 3.15-rc7-next with patch[1]
- fio: the script in commit log with numjobs set as 2

2, result
- without the patch: ~104K IOPS
- with the patch: ~140K IOPS


Rusty, considered the same trick has been applied in virt-scsi,
do you agree to take the same approach in virt-blk too?


[1], http://marc.info/?l=linux-kernelm=140135041423441w=2

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 3.14 000/140] 3.14.5-stable review

2014-05-29 Thread NeilBrown
On Wed, 28 May 2014 21:32:19 -0700 Greg Kroah-Hartman
 wrote:

> This is the start of the stable review cycle for the 3.14.5 release.
> There are 140 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sat May 31 04:30:12 UTC 2014.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.5-rc1.gz
> and the diffstat can be found below.
> 

Hi Greg,
I notice that the patch in commit cc13b1d1500656a2 (see below for comment) is
missing. I was hoping it would be in 3.14.5.  Is there a reason I missed out?

Thanks,
NeilBrown


commit cc13b1d1500656a20e41960668f3392dda9fa6e2
Author: NeilBrown 
Date:   Mon May 5 13:34:37 2014 +1000

md/raid10: call wait_barrier() for each request submitted.

wait_barrier() includes a counter, so we must call it precisely once
(unless balanced by allow_barrier()) for each request submitted.

Since
commit 20d0189b1012a37d2533a87fb451f7852f2418d1
block: Introduce new bio_split()
in 3.14-rc1, we don't call it for the extra requests generated when
we need to split a bio.

When this happens the counter goes negative, any resync/recovery will
never start, and  "mdadm --stop" will hang.

Reported-by: Chris Murphy 
Fixes: 20d0189b1012a37d2533a87fb451f7852f2418d1
Cc: sta...@vger.kernel.org (3.14+)
Cc: Kent Overstreet 
Signed-off-by: NeilBrown 


signature.asc
Description: PGP signature


Re: [PATCH v2] /proc/pid/status: show all sets of pid according to ns

2014-05-29 Thread Vasily Kulikov
On Wed, May 28, 2014 at 23:27 +0400, Pavel Emelyanov wrote:
> On 05/28/2014 10:28 PM, Vasily Kulikov wrote:
> > On Wed, May 28, 2014 at 16:44 +0400, Pavel Emelyanov wrote:
> > It will be simplier
> > to parse the file -- if 'ns_ids' file contains some ID then this ID for
> > every ns can be obtained regardless of the specific ID name (SID, PID,
> > PGID, etc.).
> 
> True, but given a task PID how to determine which pid namespaces it lives in
> to get the idea of how PIDs map to each other? Maybe we need some explicit
> API for converting (ID, NS1, NS2) into (ID)?

AFAIU the idea of the patch is to add a new debugging information which
can be trivially obtained via 'cat /proc/...':

] We need a direct method of getting the pid inside containers.
] If some issues occurred inside container guest, host user
] could not know which process is in trouble just by guest pid:
] the users of container guest only knew the pid inside containers.
] This will bring obstacle for trouble shooting.

A new syscall might complicate trouble shooting by admin.

-- 
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
--
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] Provide additional sample information to Python scripts

2014-05-29 Thread Namhyung Kim
Hi Joseph,

Sorry for late review, this looks very useful..  But please send a
separate email for each patch and make it inlined (not attached) in the
next version.


On Thu, 03 Apr 2014 10:57:39 +0200, Joseph Schuchart wrote:

[SNIP]
>  static void python_process_tracepoint(struct perf_sample *sample,
> struct perf_evsel *evsel,
> struct thread *thread,
> struct addr_location *al)
>  {
> - PyObject *handler, *retval, *context, *t, *obj, *dict = NULL;
> + PyObject *handler, *retval, *context, *t, *obj, *callchain;
> + PyObject *dict = NULL;
>   static char handler_name[256];
>   struct format_field *field;
>   unsigned long long val;
> @@ -327,6 +406,14 @@ static void python_process_tracepoint(struct perf_sample 
> *sample,
>   pydict_set_item_string_decref(dict, field->name, obj);
>  
>   }
> +
> + /* ip unwinding */
> + callchain = python_process_callchain(sample, evsel, al);
> + if (handler)
> + PyTuple_SetItem(t, n++, callchain);
> + else
> + pydict_set_item_string_decref(dict, "callchain", callchain);

But this makes the script not runnable anymore due to argument number
mismatch:

  $ perf script -s perf-script.py
  ...
  TypeError: sched__sched_wakeup() takes exactly 12 arguments (13 given)
  Fatal Python error: problem in Python trace event handler
  Aborted (core dumped)


So you need to change to pass callchain when generating the handler.


diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf
index 255d45177613..94e395c9a875 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -716,7 +716,7 @@ static int python_generate_script(struct pevent *pevent, con
 
fprintf(ofp, "%s", f->name);
}
-   fprintf(ofp, "):\n");
+   fprintf(ofp, ", callchain):\n");
 
fprintf(ofp, "\t\tprint_header(event_name, common_cpu, "
"common_secs, common_nsecs,\n\t\t\t"


Also I think it's very useful to generate code to print callchain by
default if exists - something like below?

for node in callchain:
if 'sym' in node:
print "\t[%x] %s" % (node['ip'], node['sym']['name'])
else:
print "\t[%x]" % (node['ip'])


  $ perf script -s perf-script.py
  in trace_begin
  sched__sched_wakeup  8 5021904.05609644419713 :19713
comm=perf, pid=19714, prio=120, success=1, target_cpu=9
[81091512] ttwu_do_wakeup
[810916d6] ttwu_do_activate.constprop.87
[81093b64] try_to_wake_up
[81093c22] default_wake_function
[8108348d] autoremove_wake_function
[8108b215] __wake_up_common
[8108e933] __wake_up_sync_key
[811a5b20] pipe_write
[8119cc07] do_sync_write
[8119d2cc] vfs_write
[8119d762] sys_write
[816640d9] system_call_fastpath
  sched__sched_wakeup  8 5021904.05610033419713 :19713
comm=perf, pid=19714, prio=120, success=1, target_cpu=9
[81091512] ttwu_do_wakeup
[810916d6] ttwu_do_activate.constprop.87
[81093b64] try_to_wake_up
[81093c22] default_wake_function
[8108348d] autoremove_wake_function
[8108b215] __wake_up_common
[8108e933] __wake_up_sync_key
[811a5b20] pipe_write
[8119cc07] do_sync_write
[8119d2cc] vfs_write
[8119d762] sys_write
[816640d9] system_call_fastpath
  ...


> +
>   if (!handler)
>   PyTuple_SetItem(t, n++, dict);
>  

[SNIP]
> @@ -385,15 +476,30 @@ static void python_process_general_event(struct 
> perf_sample *sample,
>   pydict_set_item_string_decref(dict, "ev_name", 
> PyString_FromString(perf_evsel__name(evsel)));
>   pydict_set_item_string_decref(dict, "attr", PyString_FromStringAndSize(
>   (const char *)>attr, sizeof(evsel->attr)));
> - pydict_set_item_string_decref(dict, "sample", 
> PyString_FromStringAndSize(
> - (const char *)sample, sizeof(*sample)));
> +
> + pydict_set_item_string_decref(dict_sample, "pid",
> + PyInt_FromLong(sample->pid));
> + pydict_set_item_string_decref(dict_sample, "tid",
> + PyInt_FromLong(sample->tid));
> + pydict_set_item_string_decref(dict_sample, "cpu",
> + PyInt_FromLong(sample->cpu));
> + pydict_set_item_string_decref(dict_sample, "time",
> + PyLong_FromUnsignedLongLong(sample->time));
> + 

Re: Resume from suspend broken in 3.15. (bisected)

2014-05-29 Thread Dan Carpenter
On Wed, May 28, 2014 at 08:26:53PM -0400, Alex Deucher wrote:
> On Wed, May 28, 2014 at 7:49 PM, Ken Moffat  wrote:
> > On Wed, May 28, 2014 at 06:25:21PM +0100, Ken Moffat wrote:
> >> Hi Daniel,
> >>
> >
> >  [ correcting details, confirming that reverting this does fix the
> > problem, adding Cc:s ]
> >
> >>  I've only started full testing of 3.15 on one of my machines now
> >> that -rc7 has been released (this one had two issues in the radeon
> >> code, second was fixed in rc7).  Unfortunately, suspend to RAM
> >> (pm-suspend), or rather the wake-up, is broken on this box [ my
> >> other two boxes are fine in rc7 ].
> >>
> >> Bisection identified one of your commits -
> >>
> >> commit 25f397a429dfa43f22c278d0119a60a343aa568f
> >> Author: Daniel Vetter 
> >> Date:   Fri Jul 19 18:57:11 2013 +0200
> >>
> >> drm/crtc-helper: explicit DPMS on after modeset
> >>
> >> Atm the crtc helper implementation of set_config has really
> >> inconsisten semantics: If just an fb update is good enough, dpms state
> >> will be left as-is, but if we do a full modeset we force everything to
> >> dpms on.
> >>
> >> This change has already been applied to the i915 modeset code in
> >>
> >> ('git show' stops at that point)
> >
> >  update : I've no idea what was going on there, nor for the problem
> > with attempting to revert it.  I've now gone back into git,
> > extracted the full commit to a file with 'git show', and then used
> > git apply -R to revert it from 3.15-rc7.  That version wakes up from
> > suspend to RAM, 3.15-rc7 itself did not.
> >
> >  Maybe I was still in git log when I thought I was on the command
> > line.  Anyway, snipping git's view of my failed attempt to revert
> > it, and adding Dan and Alex who were CC'd on the commit.
> >
> 
> Duplicate of:
> https://bugzilla.kernel.org/show_bug.cgi?id=74751
> and also reported here:
> https://lkml.org/lkml/2014/5/2/388
> Unless there is a good reason to keep the commit, I'd say let's just revert 
> it.
>

Yes.  Let's revert it.

regards,
dan carpenter

--
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 2/2] x86_64: expand kernel stack to 16K

2014-05-29 Thread Minchan Kim
On Wed, May 28, 2014 at 12:06:58PM -0400, Johannes Weiner wrote:
> On Wed, May 28, 2014 at 07:13:45PM +1000, Dave Chinner wrote:
> > On Wed, May 28, 2014 at 06:37:38PM +1000, Dave Chinner wrote:
> > > [ cc XFS list ]
> > 
> > [and now there is a complete copy on the XFs list, I'll add my 2c]
> > 
> > > On Wed, May 28, 2014 at 03:53:59PM +0900, Minchan Kim wrote:
> > > > While I play inhouse patches with much memory pressure on qemu-kvm,
> > > > 3.14 kernel was randomly crashed. The reason was kernel stack overflow.
> > > > 
> > > > When I investigated the problem, the callstack was a little bit deeper
> > > > by involve with reclaim functions but not direct reclaim path.
> > > > 
> > > > I tried to diet stack size of some functions related with alloc/reclaim
> > > > so did a hundred of byte but overflow was't disappeard so that I 
> > > > encounter
> > > > overflow by another deeper callstack on reclaim/allocator path.
> > 
> > That's a no win situation. The stack overruns through ->writepage
> > we've been seeing with XFS over the past *4 years* are much larger
> > than a few bytes. The worst case stack usage on a virtio block
> > device was about 10.5KB of stack usage.
> > 
> > And, like this one, it came from the flusher thread as well. The
> > difference was that the allocation that triggered the reclaim path
> > you've reported occurred when 5k of the stack had already been
> > used...
> > 
> > > > Of course, we might sweep every sites we have found for reducing
> > > > stack usage but I'm not sure how long it saves the world(surely,
> > > > lots of developer start to add nice features which will use stack
> > > > agains) and if we consider another more complex feature in I/O layer
> > > > and/or reclaim path, it might be better to increase stack size(
> > > > meanwhile, stack usage on 64bit machine was doubled compared to 32bit
> > > > while it have sticked to 8K. Hmm, it's not a fair to me and arm64
> > > > already expaned to 16K. )
> > 
> > Yup, that's all been pointed out previously. 8k stacks were never
> > large enough to fit the linux IO architecture on x86-64, but nobody
> > outside filesystem and IO developers has been willing to accept that
> > argument as valid, despite regular stack overruns and filesystem
> > having to add workaround after workaround to prevent stack overruns.
> > 
> > That's why stuff like this appears in various filesystem's
> > ->writepage:
> > 
> > /*
> >  * Refuse to write the page out if we are called from reclaim 
> > context.
> >  *
> >  * This avoids stack overflows when called from deeply used stacks 
> > in
> >  * random callers for direct reclaim or memcg reclaim.  We 
> > explicitly
> >  * allow reclaim from kswapd as the stack usage there is relatively 
> > low.
> >  *
> >  * This should never happen except in the case of a VM regression so
> >  * warn about it.
> >  */
> > if (WARN_ON_ONCE((current->flags & (PF_MEMALLOC|PF_KSWAPD)) ==
> > PF_MEMALLOC))
> > goto redirty;
> > 
> > That still doesn't guarantee us enough stack space to do writeback,
> > though, because memory allocation can occur when reading in metadata
> > needed to do delayed allocation, and so we could trigger GFP_NOFS
> > memory allocation from the flusher thread with 4-5k of stack already
> > consumed, so that would still overrun teh stack.
> > 
> > So, a couple of years ago we started defering half the writeback
> > stack usage to a worker thread (commit c999a22 "xfs: introduce an
> > allocation workqueue"), under the assumption that the worst stack
> > usage when we call memory allocation is around 3-3.5k of stack used.
> > We thought that would be safe, but the stack trace you've posted
> > shows that alloc_page(GFP_NOFS) can consume upwards of 5k of stack,
> > which means we're still screwed despite all the workarounds we have
> > in place.
> 
> The allocation and reclaim stack itself is only 2k per the stacktrace
> below.  What got us in this particular case is that we engaged a
> complicated block layer setup from within the allocation context in
> order to swap out a page.
> 
> In the past we disabled filesystem ->writepage from within the
> allocation context and deferred it to kswapd for stack reasons (see
> the WARN_ON_ONCE and the comment in your above quote), but I think we
> have to go further and do the same for even swap_writepage():
> 
> > > > I guess this topic was discussed several time so there might be
> > > > strong reason not to increase kernel stack size on x86_64, for me not
> > > > knowing so Ccing x86_64 maintainers, other MM guys and virtio
> > > > maintainers.
> > > >
> > > >  DepthSize   Location(51 entries)
> > > > 
> > > >0) 7696  16   lookup_address+0x28/0x30
> > > >1) 7680  16   _lookup_address_cpa.isra.3+0x3b/0x40
> > > >2) 7664  24   __change_page_attr_set_clr+0xe0/0xb50
> > > 

[PATCH net-next v2] mrf24j40: add managed API's provided by device layer

2014-05-29 Thread Varka Bhadram
forgot to use devm_* for spi buff.
sorry for that.

-Varka Bhadram

Signed-off-by: Varka Bhadram 
---
 drivers/net/ieee802154/mrf24j40.c |   21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ieee802154/mrf24j40.c 
b/drivers/net/ieee802154/mrf24j40.c
index 78a6552..90aed9b 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -618,10 +618,10 @@ static int mrf24j40_probe(struct spi_device *spi)
 
printk(KERN_INFO "mrf24j40: probe(). IRQ: %d\n", spi->irq);
 
-   devrec = kzalloc(sizeof(struct mrf24j40), GFP_KERNEL);
+   devrec = devm_kzalloc(>dev, sizeof(struct mrf24j40), GFP_KERNEL);
if (!devrec)
goto err_devrec;
-   devrec->buf = kzalloc(3, GFP_KERNEL);
+   devrec->buf = devm_kzalloc(>dev, 3, GFP_KERNEL);
if (!devrec->buf)
goto err_buf;
 
@@ -676,12 +676,13 @@ static int mrf24j40_probe(struct spi_device *spi)
val &= ~0x3; /* Clear RX mode (normal) */
write_short_reg(devrec, REG_RXMCR, val);
 
-   ret = request_threaded_irq(spi->irq,
-  NULL,
-  mrf24j40_isr,
-  IRQF_TRIGGER_LOW|IRQF_ONESHOT,
-  dev_name(>dev),
-  devrec);
+   ret = devm_request_threaded_irq(>dev,
+   spi->irq,
+   NULL,
+   mrf24j40_isr,
+   IRQF_TRIGGER_LOW|IRQF_ONESHOT,
+   dev_name(>dev),
+   devrec);
 
if (ret) {
dev_err(printdev(devrec), "Unable to get IRQ");
@@ -709,15 +710,11 @@ static int mrf24j40_remove(struct spi_device *spi)
 
dev_dbg(printdev(devrec), "remove\n");
 
-   free_irq(spi->irq, devrec);
ieee802154_unregister_device(devrec->dev);
ieee802154_free_device(devrec->dev);
/* TODO: Will ieee802154_free_device() wait until ->xmit() is
 * complete? */
 
-   /* Clean up the SPI stuff. */
-   kfree(devrec->buf);
-   kfree(devrec);
return 0;
 }
 
-- 
1.7.9.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] bio: decrease bi_iter.bi_size by len in the fail path

2014-05-29 Thread Jet Chen

On 05/29/2014 01:44 AM, Ming Lei wrote:

On Thu, May 29, 2014 at 1:21 AM, Maurizio Lombardi  wrote:

Hi Ming,

On Thu, May 29, 2014 at 12:59:19AM +0800, Ming Lei wrote:


Actually, the correct thing may be like what did in the
attached patch, as Maurizio discussed with me[1].

Very interestingly, I have reproduced the problem one time
with ext4/271 ext4/301 ext4/305, but won't with the attached
patch after running it for 3 rounds.

[tom@localhost xfstests]$ sudo ./check ext4/271 ext4/301 ext4/305
FSTYP -- ext4
PLATFORM  -- Linux/x86_64 localhost 3.15.0-rc7-next-20140527+
MKFS_OPTIONS  -- /dev/vdc
MOUNT_OPTIONS -- -o acl,user_xattr /dev/vdc /mnt/scratch

ext4/271 1s ... 1s
ext4/301 31s ... 32s
ext4/305 181s ... 180s
Ran: ext4/271 ext4/301 ext4/305
Passed all 3 tests

Jet, could you test the attached patch?

[1], https://lkml.org/lkml/2014/5/27/327


There is a little mistake in your patch, you removed bio->bi_iter.bi_size += 
len;
after the "done" label,
but be careful that at line 747 there is a "goto done"... bi_size should be 
incremented
before jumping there.


Good catch, thanks Maurizio.

Jet, please test the attached patch in this mail and ignore previous
one.

The story behind the patch should be like below:

- one page is added in __bio_add_page() 'successfully',
and bio->bi_phys_segments is equal to queue_max_segments(q),
but it should have been rejected since the last vector isn't covered

- next time, __bio_add_page() is called to add one page, but this
time blk_recount_segments() can figure out the actual physical
segments and find it is more than max segments, so failure is
triggered, but the bio->bi_phys_segments is updated with
max segments plus one

- the oops is triggered and reported by Jet, :-)


Thanks,


This patch works, thanks.

Tested-by: Jet Chen 

diff --git a/block/bio.c b/block/bio.c
index 0443694..f9bae56 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -744,6 +744,7 @@ static int __bio_add_page(struct request_queue *q, struct bio *bio, struct page
 }
 			}
 
+			bio->bi_iter.bi_size += len;
 			goto done;
 		}
 	}
@@ -761,6 +762,7 @@ static int __bio_add_page(struct request_queue *q, struct bio *bio, struct page
 	bvec->bv_offset = offset;
 	bio->bi_vcnt++;
 	bio->bi_phys_segments++;
+	bio->bi_iter.bi_size += len;
 
 	/*
 	 * Perform a recount if the number of segments is greater
@@ -802,7 +804,6 @@ static int __bio_add_page(struct request_queue *q, struct bio *bio, struct page
 		bio->bi_flags &= ~(1 << BIO_SEG_VALID);
 
  done:
-	bio->bi_iter.bi_size += len;
 	return len;
 
  failed:
@@ -810,6 +811,7 @@ static int __bio_add_page(struct request_queue *q, struct bio *bio, struct page
 	bvec->bv_len = 0;
 	bvec->bv_offset = 0;
 	bio->bi_vcnt--;
+	bio->bi_iter.bi_size -= len;
 	blk_recount_segments(q, bio);
 	return 0;
 }


[PATCH 2/3] hwmon: (iManager2) Add support for IT8516/18/28

2014-05-29 Thread Wei-Chun Pan
Advantech's new module comes equipped with "iManager" - an embedded 
controller (EC), providing embedded features for system integrators to increase 
reliability and simplify integration.
This patch add the MFD driver for enabling Advantech iManager V2.0 chipset. 
Available functions support HW Monitor base on ITE-IT85XX chip. These functions 
are tested on Advantech SOM-5892 board. All the embedded functions are 
configured by a utility. Advantech has done all the hard work for user with the 
release of a suite of Software APIs.
These provide not only the underlying drivers required but also a rich set 
of user-friendly, intelligent and integrated interfaces, which speeds 
development, enhances security and offers add-on value for Advantech platforms.

Signed-off-by: Wei-Chun Pan Developer 
---
 drivers/hwmon/Kconfig |   7 +
 drivers/hwmon/Makefile|   1 +
 drivers/hwmon/imanager2_hwm.c | 635 ++
 drivers/hwmon/imanager2_hwm.h | 118 
 4 files changed, 761 insertions(+)
 mode change 100644 => 100755 drivers/hwmon/Kconfig
 mode change 100644 => 100755 drivers/hwmon/Makefile
 create mode 100755 drivers/hwmon/imanager2_hwm.c
 create mode 100755 drivers/hwmon/imanager2_hwm.h

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
old mode 100644
new mode 100755
index bc196f4..d4aeab6
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -39,6 +39,13 @@ config HWMON_DEBUG_CHIP
 
 comment "Native drivers"
 
+config SENSORS_IMANAGER2
+   tristate "Support for Advantech iManager2 EC H.W. Monitor"
+   select MFD_CORE
+   select MFD_IMANAGER2
+   help
+ Support for the Advantech iManager2 EC H.W. Monitor
+
 config SENSORS_AB8500
tristate "AB8500 thermal monitoring"
depends on AB8500_GPADC && AB8500_BM
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
old mode 100644
new mode 100755
index c48f987..a2c8f07
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -146,6 +146,7 @@ obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
 obj-$(CONFIG_SENSORS_W83L786NG)+= w83l786ng.o
 obj-$(CONFIG_SENSORS_WM831X)   += wm831x-hwmon.o
 obj-$(CONFIG_SENSORS_WM8350)   += wm8350-hwmon.o
+obj-$(CONFIG_SENSORS_IMANAGER2)+= imanager2_hwm.o
 
 obj-$(CONFIG_PMBUS)+= pmbus/
 
diff --git a/drivers/hwmon/imanager2_hwm.c b/drivers/hwmon/imanager2_hwm.c
new file mode 100755
index 000..48fe3dd
--- /dev/null
+++ b/drivers/hwmon/imanager2_hwm.c
@@ -0,0 +1,635 @@
+/* imanager2_hwm.c - HW Monitoring interface for Advantech EC IT8516/18/28
+ * Copyright (C) 2014  Richard Vidal-Dorsch 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "imanager2_hwm.h"
+
+#define DRV_NAME   CHIP_NAME "_hwm"
+#define DRV_VERSION"0.4.6"
+
+/* Voltage */
+static int ec_get_voltage_adc(struct it85xx *ec, int index,
+ u32 *volt_millivolt)
+{
+   int ret;
+   u8 portnum, tmp[2];
+
+   *volt_millivolt = 0;
+
+   spin_lock(>lock);
+
+   if ((ec->flag & EC_F_MAILBOX) != 0) {
+   ret = ec_mailbox_read_buffer(ec, EC_CMD_MAILBOX_READ_HW_PIN,
+ec_volt_table[index].did, [0],
+2);
+   } else {
+   u8 pin = ec->table.pinnum[ec->table.devid2itemnum[
+   ec_volt_table[index].did]];
+
+   ret = ec_io_read(EC_CMD_ADC_INDEX, pin, , 1);
+   if (ret != 0)
+   goto unlock;
+   if (portnum == 0xFF) {
+   ret = -EFAULT;
+   goto unlock;
+   }
+
+   ret = ec_io_read_byte_without_offset(EC_CMD_ADC_READ_LSB,
+[1]);
+   if (ret != 0)
+   goto unlock;
+
+   ret = ec_io_read_byte_without_offset(EC_CMD_ADC_READ_MSB,
+[0]);
+   }
+unlock:
+   spin_unlock(>lock);
+
+   if (ret != 0)
+   return ret;
+
+   *volt_millivolt = ((tmp[0] << 8 | tmp[1]) & EC_ADC_RESOLUTION_MAX) *
+ 

[PATCH 3/3] i2c: iManager2: add support for IT8516/18/28

2014-05-29 Thread Wei-Chun Pan
Advantech's new module comes equipped with "iManager" - an embedded 
controller (EC), providing embedded features for system integrators to increase 
reliability and simplify integration.
This patch add the MFD driver for enabling Advantech iManager V2.0 chipset. 
Available functions support I2C base on ITE-IT85XX chip. These functions are 
tested on Advantech SOM-5892 board. All the embedded functions are configured 
by a utility. Advantech has done all the hard work for user with the release of 
a suite of Software APIs.
These provide not only the underlying drivers required but also a rich set 
of user-friendly, intelligent and integrated interfaces, which speeds 
development, enhances security and offers add-on value for Advantech platforms.

Signed-off-by: Wei-Chun Pan Developer 
---
 drivers/i2c/busses/Kconfig |   8 ++
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/imanager2_i2c.c | 257 +
 drivers/i2c/busses/imanager2_i2c.h |  38 ++
 4 files changed, 304 insertions(+)
 mode change 100644 => 100755 drivers/i2c/busses/Kconfig
 mode change 100644 => 100755 drivers/i2c/busses/Makefile
 create mode 100755 drivers/i2c/busses/imanager2_i2c.c
 create mode 100755 drivers/i2c/busses/imanager2_i2c.h

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
old mode 100644
new mode 100755
index c94db1c..8aad058
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -8,6 +8,14 @@ menu "I2C Hardware Bus support"
 comment "PC SMBus host controller drivers"
depends on PCI
 
+config I2C_IMANAGER2
+   tristate "Support for Advantech iManager2 EC I2C"
+   select MFD_CORE
+   select MFD_IMANAGER2
+   depends on I2C=y
+   help
+ Support for the Advantech iManager2 EC I2C.
+
 config I2C_ALI1535
tristate "ALI 1535"
depends on PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
old mode 100644
new mode 100755
index 18d18ff..8a2a26b
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_I2C_OCTEON)  += i2c-octeon.o
 obj-$(CONFIG_I2C_XILINX)   += i2c-xiic.o
 obj-$(CONFIG_I2C_XLR)  += i2c-xlr.o
 obj-$(CONFIG_I2C_RCAR) += i2c-rcar.o
+obj-$(CONFIG_I2C_IMANAGER2)+= imanager2_i2c.o
 
 # External I2C/SMBus adapter drivers
 obj-$(CONFIG_I2C_DIOLAN_U2C)   += i2c-diolan-u2c.o
diff --git a/drivers/i2c/busses/imanager2_i2c.c 
b/drivers/i2c/busses/imanager2_i2c.c
new file mode 100755
index 000..6510dca
--- /dev/null
+++ b/drivers/i2c/busses/imanager2_i2c.c
@@ -0,0 +1,257 @@
+/* imanager2_i2c.c - I2C interface for Advantech EC IT8516/18/28 driver
+ * Copyright (C) 2014  Richard Vidal-Dorsch 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include "imanager2_i2c.h"
+
+#define DRV_NAME   CHIP_NAME "_i2c"
+#define DRV_VERSION"0.2.4"
+
+struct it85xx_i2c {
+   struct i2c_adapter adapter;
+   struct it85xx *ec;
+   enum ec_device_id did;
+};
+
+struct it85xx_i2c_drv {
+   struct it85xx_i2c *devs[EC_I2C_SMB_DEV_MAX];
+   int devcount;
+};
+
+static int it85xx_smb_access(struct i2c_adapter *adap, u16 addr,
+unsigned short flags, char read_write, u8 command,
+int size, union i2c_smbus_data *data)
+{
+   struct it85xx_i2c *i2cdev = i2c_get_adapdata(adap);
+   int ret = 0;
+   u8 rlen = 0;
+
+   addr <<= 1;
+
+   spin_lock(>ec->lock);
+
+   switch (size) {
+   case I2C_SMBUS_QUICK:
+   pr_info("I2C_SMBUS_QUICK\n");
+   if (read_write == I2C_SMBUS_WRITE)
+   ret = ec_smbus_transmit_routine(
+   i2cdev->ec, i2cdev->did,
+   EC_CMD_MALLBOX_SMBUS_WRITE_QUICK,
+   (u8)addr, 0, NULL, 0, NULL, NULL, 0);
+   else
+   ret = ec_smbus_transmit_routine(
+   i2cdev->ec, i2cdev->did,
+   EC_CMD_MALLBOX_SMBUS_READ_QUICK,
+   (u8)addr, 0, NULL, 0, NULL, NULL, 0);
+   pr_info("ret = %X, addr = %X\n", ret , 

[PATCH 1/3] mfd: iManager2: Add support for IT8516/18/28

2014-05-29 Thread Wei-Chun Pan
Advantech's new module comes equipped with "iManager" - an embedded 
controller (EC), providing embedded features for system integrators to increase 
reliability and simplify integration.
This patch add the MFD driver for enabling Advantech iManager V2.0 chipset. 
Available functions support to recognize ITE-IT85XX and basic control APIs. 
These functions are tested on Advantech SOM-5892 board. All the embedded 
functions are configured by a utility. Advantech has done all the hard work for 
user with the release of a suite of Software APIs.
These provide not only the underlying drivers required but also a rich set 
of user-friendly, intelligent and integrated interfaces, which speeds 
development, enhances security and offers add-on value for Advantech platforms.

Signed-off-by: Wei-Chun Pan Developer 
---
 drivers/mfd/Kconfig|6 +
 drivers/mfd/Makefile   |2 +
 drivers/mfd/imanager2_core.c   |  316 
 drivers/mfd/imanager2_ec.c | 1093 
 include/linux/mfd/advantech/imanager2.h|   61 ++
 include/linux/mfd/advantech/imanager2_ec.h |  389 ++
 6 files changed, 1867 insertions(+)
 mode change 100644 => 100755 drivers/mfd/Kconfig
 mode change 100644 => 100755 drivers/mfd/Makefile
 create mode 100755 drivers/mfd/imanager2_core.c
 create mode 100755 drivers/mfd/imanager2_ec.c
 create mode 100755 include/linux/mfd/advantech/imanager2.h
 create mode 100755 include/linux/mfd/advantech/imanager2_ec.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
old mode 100644
new mode 100755
index 3383412..48b063f
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -10,6 +10,12 @@ config MFD_CORE
select IRQ_DOMAIN
default n
 
+config MFD_IMANAGER2
+   tristate "Support for Advantech iManager2 EC ICs"
+   select MFD_CORE
+   help
+ Support for Advantech iManager2 EC ICs
+
 config MFD_CS5535
tristate "AMD CS5535 and CS5536 southbridge core functions"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
old mode 100644
new mode 100755
index 2851275..10c64ae
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -166,3 +166,5 @@ obj-$(CONFIG_MFD_RETU)  += retu-mfd.o
 obj-$(CONFIG_MFD_AS3711)   += as3711.o
 obj-$(CONFIG_MFD_AS3722)   += as3722.o
 obj-$(CONFIG_MFD_STW481X)  += stw481x.o
+imanager2-objs := imanager2_core.o imanager2_ec.o
+obj-$(CONFIG_MFD_IMANAGER2)+= imanager2.o
diff --git a/drivers/mfd/imanager2_core.c b/drivers/mfd/imanager2_core.c
new file mode 100755
index 000..786853d
--- /dev/null
+++ b/drivers/mfd/imanager2_core.c
@@ -0,0 +1,316 @@
+/* imanager2_core.c - MFD core driver of Advantech EC IT8516/18/28
+ * Copyright (C) 2014  Richard Vidal-Dorsch 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+
+#define DRV_NAME   CHIP_NAME
+#define DRV_VERSION"0.2.2"
+
+static struct platform_device *pdev;
+
+static struct mfd_cell it85xx_devs[] = {
+   { .name = DRV_NAME "_hwm", },
+   { .name = DRV_NAME "_i2c", },
+};
+
+static int ec_authentication(struct it85xx *ec)
+{
+   u8 tmp;
+   int ret = 0;
+
+   spin_lock(>lock);
+
+   if (inb(EC_IO_PORT_CMD) == 0xFF && inb(EC_IO_PORT_DATA) == 0xFF) {
+   ret = -ENODEV;
+   goto out;
+   }
+
+   if ((inb(EC_IO_PORT_CMD) & OBF_MASK) != 0)
+   inb(EC_IO_PORT_DATA);   /* initial OBF */
+
+   if (outb_after_ibc(EC_IO_PORT_CMD, EC_CMD_AUTHENTICATION) != 0) {
+   ret = -ENODEV;
+   goto out;
+   }
+
+   if (inb_after_obf() != 0)
+   ret = -EFAULT;
+
+out:
+   spin_unlock(>lock);
+
+   if (ret != 0)
+   return ret;
+
+   if (tmp != 0x95)
+   return -EOPNOTSUPP;
+
+   return 0;
+}
+
+static int ec_get_chip_type(struct it85xx *ec)
+{
+   spin_lock(>lock);
+
+   outb(0x20, EC_SIO_CMD);
+   ec->type = (inb(EC_SIO_DATA) << 8);
+   outb(0x21, EC_SIO_CMD);
+   ec->type |= inb(EC_SIO_DATA);
+
+   pr_info("chip type = %04X\n", ec->type);
+
+   spin_unlock(>lock);
+
+   switch (ec->type) {
+   case it8516:
+   case it8518:
+   break;
+  

Re: [PATCH 01/27] mtd: nand: introduce function to fix a common bug in most nand-drivers not showing a device in sysfs

2014-05-29 Thread Artem Bityutskiy
On Wed, 2014-05-28 at 23:09 +0200, Alexander Holler wrote:
> I'm very sorry, but I find such discussions extremly tiresome.

Why discussing then at all, just go ahead and to something else.

-- 
Best Regards,
Artem Bityutskiy

--
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] vmalloc: use rcu list iterator to reduce vmap_area_lock contention

2014-05-29 Thread Joonsoo Kim
Richard Yao reported a month ago that his system have a trouble
with vmap_area_lock contention during performance analysis
by /proc/meminfo. Andrew asked why his analysis checks /proc/meminfo
stressfully, but he didn't answer it.

https://lkml.org/lkml/2014/4/10/416

Although I'm not sure that this is right usage or not, there is a solution
reducing vmap_area_lock contention with no side-effect. That is just
to use rcu list iterator in get_vmalloc_info(). This function only needs
values on vmap_area structure, so we don't need to grab a spinlock.

Reported-by: Richard Yao 
Signed-off-by: Joonsoo Kim 

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index f64632b..fdbb116 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2690,14 +2690,14 @@ void get_vmalloc_info(struct vmalloc_info *vmi)
 
prev_end = VMALLOC_START;
 
-   spin_lock(_area_lock);
+   rcu_read_lock();
 
if (list_empty(_area_list)) {
vmi->largest_chunk = VMALLOC_TOTAL;
goto out;
}
 
-   list_for_each_entry(va, _area_list, list) {
+   list_for_each_entry_rcu(va, _area_list, list) {
unsigned long addr = va->va_start;
 
/*
@@ -2724,7 +2724,7 @@ void get_vmalloc_info(struct vmalloc_info *vmi)
vmi->largest_chunk = VMALLOC_END - prev_end;
 
 out:
-   spin_unlock(_area_lock);
+   rcu_read_unlock();
 }
 #endif
 
-- 
1.7.9.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/


[PATCH] CMA: use MIGRATE_SYNC in alloc_contig_range()

2014-05-29 Thread Joonsoo Kim
Before commit 'mm, compaction: embed migration mode in compact_control'
from David is merged, alloc_contig_range() used sync migration,
instead of sync_light migration. This doesn't break anything currently
because page isolation doesn't have any difference with sync and
sync_light, but it could in the future, so change back as it was.

And pass cc->mode to migrate_pages(), instead of passing MIGRATE_SYNC
to migrate_pages().

Signed-off-by: Joonsoo Kim 

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7f97767..97c4185 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6262,7 +6262,7 @@ static int __alloc_contig_migrate_range(struct 
compact_control *cc,
cc->nr_migratepages -= nr_reclaimed;
 
ret = migrate_pages(>migratepages, alloc_migrate_target,
-   NULL, 0, MIGRATE_SYNC, MR_CMA);
+   NULL, 0, cc->mode, MR_CMA);
}
if (ret < 0) {
putback_movable_pages(>migratepages);
@@ -6301,7 +6301,7 @@ int alloc_contig_range(unsigned long start, unsigned long 
end,
.nr_migratepages = 0,
.order = -1,
.zone = page_zone(pfn_to_page(start)),
-   .mode = MIGRATE_SYNC_LIGHT,
+   .mode = MIGRATE_SYNC,
.ignore_skip_hint = true,
};
INIT_LIST_HEAD();
-- 
1.7.9.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/


[PATCH] CMA: correct unlock target

2014-05-29 Thread Joonsoo Kim
'cma: Remove potential deadlock situation' introduces per cma area mutex
for bitmap management. It is good, but there is one mistake. When we
can't find appropriate area in bitmap, we release cma_mutex global lock
rather than cma->lock and this is a bug. So fix it.

Signed-off-by: Joonsoo Kim 

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 6f6bffc..83969f8 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -331,7 +331,7 @@ struct page *dma_alloc_from_contiguous(struct device *dev, 
int count,
pageno = bitmap_find_next_zero_area(cma->bitmap, cma->count,
start, count, mask);
if (pageno >= cma->count) {
-   mutex_unlock(_mutex);
+   mutex_unlock(>lock);
break;
}
bitmap_set(cma->bitmap, pageno, count);
-- 
1.7.9.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 net-next v1] mrf24j40: add managed API's provided by device layer

2014-05-29 Thread Tushar Behera
On Thu, May 29, 2014 at 10:10:21AM +0530, Varka Bhadram wrote:
> Hi,
>   Previous patch having bug in using managed API's. I fixed that.
> 
> Regards,
> Varka Bhadram.

Only add relevant commit message here, no need to add 'Hi' and
'Regards'.

Something like ...

"Added devres managed APIs"

> 
> Signed-off-by: Varka Bhadram 
> ---
>  drivers/net/ieee802154/mrf24j40.c |   21 +
>  1 file changed, 9 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/net/ieee802154/mrf24j40.c 
> b/drivers/net/ieee802154/mrf24j40.c
> index 78a6552..f701cdb 100644
> --- a/drivers/net/ieee802154/mrf24j40.c
> +++ b/drivers/net/ieee802154/mrf24j40.c
> @@ -618,10 +618,10 @@ static int mrf24j40_probe(struct spi_device *spi)
>  
>   printk(KERN_INFO "mrf24j40: probe(). IRQ: %d\n", spi->irq);
>  
> - devrec = kzalloc(sizeof(struct mrf24j40), GFP_KERNEL);
> + devrec = devm_kzalloc(>dev, sizeof(struct mrf24j40), GFP_KERNEL);
>   if (!devrec)
>   goto err_devrec;
> - devrec->buf = kzalloc(3, GFP_KERNEL);
> + devrec->buf = kzalloc(>dev, 3, GFP_KERNEL);

devm_kzalloc()

Without this, it should not build at all. So remember to compile test
before sending the patches.

--
Warm regards,
Tushar
--
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 3/3] phy: sun4i-usb: Use PTR_ERR_OR_ZERO

2014-05-29 Thread Sachin Kamat
PTR_ERR_OR_ZERO simplifies the code.

Signed-off-by: Sachin Kamat 
Cc: Hans de Goede 
Cc: Maxime Ripard 
---
 drivers/phy/phy-sun4i-usb.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 115d8d5190d5..7a4ea552f621 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -22,6 +22,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -306,10 +307,8 @@ static int sun4i_usb_phy_probe(struct platform_device 
*pdev)
 
dev_set_drvdata(dev, data);
phy_provider = devm_of_phy_provider_register(dev, sun4i_usb_phy_xlate);
-   if (IS_ERR(phy_provider))
-   return PTR_ERR(phy_provider);
 
-   return 0;
+   return PTR_ERR_OR_ZERO(phy_provider);
 }
 
 static const struct of_device_id sun4i_usb_phy_of_match[] = {
-- 
1.7.9.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/


[PATCH 1/3] phy: exynos-dp-video: Use PTR_ERR_OR_ZERO

2014-05-29 Thread Sachin Kamat
PTR_ERR_OR_ZERO simplifies the code.

Signed-off-by: Sachin Kamat 
Cc: Jingoo Han 
---
 drivers/phy/phy-exynos-dp-video.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-exynos-dp-video.c 
b/drivers/phy/phy-exynos-dp-video.c
index 0786fef842e7..098f822a2fa4 100644
--- a/drivers/phy/phy-exynos-dp-video.c
+++ b/drivers/phy/phy-exynos-dp-video.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -84,10 +85,8 @@ static int exynos_dp_video_phy_probe(struct platform_device 
*pdev)
phy_set_drvdata(phy, state);
 
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
-   if (IS_ERR(phy_provider))
-   return PTR_ERR(phy_provider);
 
-   return 0;
+   return PTR_ERR_OR_ZERO(phy_provider);
 }
 
 static const struct of_device_id exynos_dp_video_phy_of_match[] = {
-- 
1.7.9.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/


[PATCH 2/3] phy: exynos-mipi-video: Use PTR_ERR_OR_ZERO

2014-05-29 Thread Sachin Kamat
PTR_ERR_OR_ZERO simplifies the code.

Signed-off-by: Sachin Kamat 
Cc: Sylwester Nawrocki 
---
 drivers/phy/phy-exynos-mipi-video.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-exynos-mipi-video.c 
b/drivers/phy/phy-exynos-mipi-video.c
index ff026689358c..6d6bcf52a10e 100644
--- a/drivers/phy/phy-exynos-mipi-video.c
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -9,6 +9,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -149,10 +150,8 @@ static int exynos_mipi_video_phy_probe(struct 
platform_device *pdev)
 
phy_provider = devm_of_phy_provider_register(dev,
exynos_mipi_video_phy_xlate);
-   if (IS_ERR(phy_provider))
-   return PTR_ERR(phy_provider);
 
-   return 0;
+   return PTR_ERR_OR_ZERO(phy_provider);
 }
 
 static const struct of_device_id exynos_mipi_video_phy_of_match[] = {
-- 
1.7.9.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] CMA: use MIGRATE_SYNC in alloc_contig_range()

2014-05-29 Thread Minchan Kim
On Thu, May 29, 2014 at 03:25:50PM +0900, Joonsoo Kim wrote:
> Before commit 'mm, compaction: embed migration mode in compact_control'
> from David is merged, alloc_contig_range() used sync migration,
> instead of sync_light migration. This doesn't break anything currently
> because page isolation doesn't have any difference with sync and
> sync_light, but it could in the future, so change back as it was.
> 
> And pass cc->mode to migrate_pages(), instead of passing MIGRATE_SYNC
> to migrate_pages().
> 
> Signed-off-by: Joonsoo Kim 
Acked-by: Minchan Kim 

Hello Joonsoo,

Please Ccing me if you send patch related to CMA mm part.
I have reviewed/fixed mm part of CMA for a long time so worth to Cced
although I always don't have a time to look at it. :)

Thanks.

> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 7f97767..97c4185 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6262,7 +6262,7 @@ static int __alloc_contig_migrate_range(struct 
> compact_control *cc,
>   cc->nr_migratepages -= nr_reclaimed;
>  
>   ret = migrate_pages(>migratepages, alloc_migrate_target,
> - NULL, 0, MIGRATE_SYNC, MR_CMA);
> + NULL, 0, cc->mode, MR_CMA);
>   }
>   if (ret < 0) {
>   putback_movable_pages(>migratepages);
> @@ -6301,7 +6301,7 @@ int alloc_contig_range(unsigned long start, unsigned 
> long end,
>   .nr_migratepages = 0,
>   .order = -1,
>   .zone = page_zone(pfn_to_page(start)),
> - .mode = MIGRATE_SYNC_LIGHT,
> + .mode = MIGRATE_SYNC,
>   .ignore_skip_hint = true,
>   };
>   INIT_LIST_HEAD();
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
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] Per-user namespace process accounting

2014-05-29 Thread Marian Marinov
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I have the following proposition.

Number of currently running processes is accounted at the root user namespace. 
The problem I'm facing is that multiple
containers in different user namespaces share the process counters.

So if containerX runs 100 with UID 99, containerY should have NPROC limit of 
above 100 in order to execute any
processes with ist own UID 99.

I know that some of you will tell me that I should not provision all of my 
containers with the same UID/GID maps, but
this brings another problem.

We are provisioning the containers from a template. The template has a lot of 
files 500k and more. And chowning these
causes a lot of I/O and also slows down provisioning considerably.

The other problem is that when we migrate one container from one host machine 
to another the IDs may be already in use
on the new machine and we need to chown all the files again.

Finally if we use different UID/GID maps we can not do live migration to 
another node because the UIDs may be already
in use.

So I'm proposing one hack modifying unshare_userns() to allocate new 
user_struct for the cred that is created for the
first task creating the user_ns and free it in exit_creds().

Can you please comment on that?

Or suggest a better solution?

Best regards,
Marian


- -- 
Marian Marinov
Founder & CEO of 1H Ltd.
Jabber/GTalk: hack...@jabber.org
ICQ: 7556201
Mobile: +359 886 660 270
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlOG1Y0ACgkQ4mt9JeIbjJQREACbBrax+ztBj2Y0P2jY3qYEUY9T
JJ0AnAqLj3pqFFjXCkczEydV1V0LdzQ3
=8M+P
-END PGP SIGNATURE-
--
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 v4 09/11] drm: sti: add Mixer

2014-05-29 Thread Benjamin Gaignard
Mixer hardware IP is responsible of mixing the different inputs layers.
Z-order is managed by the mixer.
We could 2 mixers: one for main path and one for auxillary path

Mixers are part of Compositor hardware block

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile|   1 +
 drivers/gpu/drm/sti/sti_mixer.c | 243 
 drivers/gpu/drm/sti/sti_mixer.h |  52 +
 3 files changed, 296 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/sti_mixer.c
 create mode 100644 drivers/gpu/drm/sti/sti_mixer.h

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index bb0f6b3..ce03e15 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -6,5 +6,6 @@ obj-$(CONFIG_DRM_STI) += \
sti_hdmi_tx3g4c28phy.o \
sti_hda.o \
sti_tvout.o \
+   sti_mixer.o \
sti_gdp.o \
sti_vid.o
\ No newline at end of file
diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
new file mode 100644
index 000..c812c68
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -0,0 +1,243 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Authors: Benjamin Gaignard 
+ *  Fabien Dessenne 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include "sti_mixer.h"
+#include "sti_vtg.h"
+
+/* Identity: G=Y , B=Cb , R=Cr */
+static const u32 MixerColorSpaceMatIdentity[] = {
+   0x1000, 0x, 0x1000, 0x1000,
+   0x, 0x, 0x, 0x
+};
+
+/* regs offset */
+#define GAM_MIXER_CTL  0x00
+#define GAM_MIXER_BKC  0x04
+#define GAM_MIXER_BCO  0x0C
+#define GAM_MIXER_BCS  0x10
+#define GAM_MIXER_AVO  0x28
+#define GAM_MIXER_AVS  0x2C
+#define GAM_MIXER_CRB  0x34
+#define GAM_MIXER_ACT  0x38
+#define GAM_MIXER_MBP  0x3C
+#define GAM_MIXER_MX0  0x80
+
+/* id for depth of CRB reg */
+#define GAM_DEPTH_VID0_ID  1
+#define GAM_DEPTH_VID1_ID  2
+#define GAM_DEPTH_GDP0_ID  3
+#define GAM_DEPTH_GDP1_ID  4
+#define GAM_DEPTH_GDP2_ID  5
+#define GAM_DEPTH_GDP3_ID  6
+#define GAM_DEPTH_MASK_ID  7
+
+/* mask in CTL reg */
+#define GAM_CTL_BACK_MASK  BIT(0)
+#define GAM_CTL_VID0_MASK  BIT(1)
+#define GAM_CTL_VID1_MASK  BIT(2)
+#define GAM_CTL_GDP0_MASK  BIT(3)
+#define GAM_CTL_GDP1_MASK  BIT(4)
+#define GAM_CTL_GDP2_MASK  BIT(5)
+#define GAM_CTL_GDP3_MASK  BIT(6)
+
+const char *sti_mixer_to_str(struct sti_mixer *mixer)
+{
+   switch (mixer->id) {
+   case STI_MIXER_MAIN:
+   return "MAIN_MIXER";
+   case STI_MIXER_AUX:
+   return "AUX_MIXER";
+   default:
+   return "";
+   }
+}
+
+static inline u32 sti_mixer_reg_read(struct sti_mixer *mixer, u32 reg_id)
+{
+   return readl(mixer->regs + reg_id);
+}
+
+static inline void sti_mixer_reg_write(struct sti_mixer *mixer,
+  u32 reg_id, u32 val)
+{
+   writel(val, mixer->regs + reg_id);
+}
+
+void sti_mixer_set_background_status(struct sti_mixer *mixer, bool enable)
+{
+   u32 val = sti_mixer_reg_read(mixer, GAM_MIXER_CTL);
+
+   val &= ~GAM_CTL_BACK_MASK;
+   val |= enable;
+   sti_mixer_reg_write(mixer, GAM_MIXER_CTL, val);
+}
+
+static void sti_mixer_set_background_color(struct sti_mixer *mixer,
+  u8 red, u8 green, u8 blue)
+{
+   u32 val = (red << 16) | (green << 8) | blue;
+
+   sti_mixer_reg_write(mixer, GAM_MIXER_BKC, val);
+}
+
+static void sti_mixer_set_background_area(struct sti_mixer *mixer,
+ struct drm_display_mode *mode)
+{
+   u32 ydo, xdo, yds, xds;
+
+   ydo = sti_vtg_get_line_number(*mode, 0);
+   yds = sti_vtg_get_line_number(*mode, mode->vdisplay - 1);
+   xdo = sti_vtg_get_pixel_number(*mode, 0);
+   xds = sti_vtg_get_pixel_number(*mode, mode->hdisplay - 1);
+
+   sti_mixer_reg_write(mixer, GAM_MIXER_BCO, ydo << 16 | xdo);
+   sti_mixer_reg_write(mixer, GAM_MIXER_BCS, yds << 16 | xds);
+}
+
+int sti_mixer_set_layer_depth(struct sti_mixer *mixer, struct sti_layer *layer)
+{
+   int layer_id = 0, depth = layer->zorder;
+   u32 mask, val;
+
+   if (depth >= GAM_MIXER_NB_DEPTH_LEVEL)
+   return 1;
+
+   switch (layer->desc) {
+   case STI_GDP_0:
+   layer_id = GAM_DEPTH_GDP0_ID;
+   break;
+   case STI_GDP_1:
+   layer_id = GAM_DEPTH_GDP1_ID;
+   break;
+   case STI_GDP_2:
+   layer_id = GAM_DEPTH_GDP2_ID;
+   break;
+   case STI_GDP_3:
+   layer_id = GAM_DEPTH_GDP3_ID;
+   break;
+   case STI_VID_0:
+   layer_id = GAM_DEPTH_VID0_ID;
+   break;
+   case STI_VID_1:
+   layer_id = GAM_DEPTH_VID1_ID;
+   break;
+   default:
+   DRM_ERROR("Unknown 

[PATCH v4 07/11] drm: sti: add GDP layer

2014-05-29 Thread Benjamin Gaignard
Generic Display Pipeline are one of the compositor input sub-devices.
GDP are dedicated to graphic input like RGB plans.
GDP is part of Compositor hardware block which will be introduce later.

A sti_layer structure is used to abstract GDP calls from Compositor.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile|   3 +-
 drivers/gpu/drm/sti/sti_gdp.c   | 482 
 drivers/gpu/drm/sti/sti_gdp.h   |  73 ++
 drivers/gpu/drm/sti/sti_layer.h | 111 +
 4 files changed, 668 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/sti/sti_gdp.c
 create mode 100644 drivers/gpu/drm/sti/sti_gdp.h
 create mode 100644 drivers/gpu/drm/sti/sti_layer.h

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index dcc9568..1745697 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_DRM_STI) += \
sti_hdmi_tx3g0c55phy.o \
sti_hdmi_tx3g4c28phy.o \
sti_hda.o \
-   sti_tvout.o
\ No newline at end of file
+   sti_tvout.o \
+   sti_gdp.o
\ No newline at end of file
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
new file mode 100644
index 000..a014214
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -0,0 +1,482 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Authors: Benjamin Gaignard 
+ *  Fabien Dessenne 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+
+#include "sti_gdp.h"
+#include "sti_layer.h"
+#include "sti_vtg.h"
+
+#define ENA_COLOR_FILL  BIT(8)
+#define WAIT_NEXT_VSYNC BIT(31)
+
+/* GDP color formats */
+#define GDP_RGB565  0x00
+#define GDP_RGB888  0x01
+#define GDP_RGB888_32   0x02
+#define GDP_ARGB85650x04
+#define GDP_ARGB0x05
+#define GDP_ARGB15550x06
+#define GDP_ARGB0x07
+#define GDP_CLUT8   0x0B
+#define GDP_YCBR888 0x10
+#define GDP_YCBR422R0x12
+#define GDP_AYCBR   0x15
+
+#define GAM_GDP_CTL_OFFSET  0x00
+#define GAM_GDP_AGC_OFFSET  0x04
+#define GAM_GDP_VPO_OFFSET  0x0C
+#define GAM_GDP_VPS_OFFSET  0x10
+#define GAM_GDP_PML_OFFSET  0x14
+#define GAM_GDP_PMP_OFFSET  0x18
+#define GAM_GDP_SIZE_OFFSET 0x1C
+#define GAM_GDP_NVN_OFFSET  0x24
+#define GAM_GDP_KEY1_OFFSET 0x28
+#define GAM_GDP_KEY2_OFFSET 0x2C
+#define GAM_GDP_PPT_OFFSET  0x34
+#define GAM_GDP_CML_OFFSET  0x3C
+#define GAM_GDP_MST_OFFSET  0x68
+
+#define GAM_GDP_ALPHARANGE_255  BIT(5)
+#define GAM_GDP_AGC_FULL_RANGE  0x00808080
+#define GAM_GDP_PPT_IGNORE  (BIT(1) | BIT(0))
+#define GAM_GDP_SIZE_MAX0x7FF
+
+static const uint32_t gdp_supported_formats[] = {
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ARGB1555,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_RGB888,
+   DRM_FORMAT_AYUV,
+   DRM_FORMAT_YUV444,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_C8,
+};
+
+static const uint32_t *sti_gdp_get_formats(void)
+{
+   return gdp_supported_formats;
+}
+
+static unsigned int sti_gdp_get_nb_formats(void)
+{
+   return ARRAY_SIZE(gdp_supported_formats);
+}
+
+static int sti_gdp_fourcc2format(int fourcc)
+{
+   switch (fourcc) {
+   case DRM_FORMAT_XRGB:
+   return GDP_RGB888_32;
+   case DRM_FORMAT_ARGB:
+   return GDP_ARGB;
+   case DRM_FORMAT_ARGB:
+   return GDP_ARGB;
+   case DRM_FORMAT_ARGB1555:
+   return GDP_ARGB1555;
+   case DRM_FORMAT_RGB565:
+   return GDP_RGB565;
+   case DRM_FORMAT_RGB888:
+   return GDP_RGB888;
+   case DRM_FORMAT_AYUV:
+   return GDP_AYCBR;
+   case DRM_FORMAT_YUV444:
+   return GDP_YCBR888;
+   case DRM_FORMAT_VYUY:
+   return GDP_YCBR422R;
+   case DRM_FORMAT_C8:
+   return GDP_CLUT8;
+   }
+   return -1;
+}
+
+static int sti_gdp_get_alpharange(int format)
+{
+   switch (format) {
+   case GDP_ARGB8565:
+   case GDP_ARGB:
+   case GDP_AYCBR:
+   return GAM_GDP_ALPHARANGE_255;
+   }
+   return 0;
+}
+
+/**
+ * sti_gdp_get_free_nodes
+ * @layer: gdp layer
+ *
+ * Look for a GDP node list that is not currently read by the HW.
+ *
+ * RETURNS:
+ * Pointer to the free GDP node list
+ */
+static struct sti_gdp_node_list *sti_gdp_get_free_nodes(struct sti_layer 
*layer)
+{
+   int hw_nvn;
+   void *virt_nvn;
+   struct sti_gdp *gdp = layer->gdp;
+   unsigned int i;
+
+   hw_nvn = readl(gdp->regs + GAM_GDP_NVN_OFFSET);
+   if (!hw_nvn)
+   goto end;
+
+   virt_nvn = dma_to_virt(gdp->dev, (dma_addr_t) hw_nvn);
+
+   for (i = 0; i < GDP_NODE_NB_BANK; i++)
+   if ((virt_nvn != gdp->node_list[i].btm_field) &&
+   (virt_nvn != 

[PATCH v4 00/11] Add DRM for stih4xx platforms

2014-05-29 Thread Benjamin Gaignard
This series of patches add the support of DRM/KMS drivers for STMicroelectronics
chipsets stih416 and stih407.

version 4:
- Remove depency between TVout it subdevices HDMI and HDA
- Rework and simplify VTG and VTAC code
- Fix numbers of typo and indentation
- Remove debug (will be push in separate patches)
- Fix remarks done in previous patcheset

patches could be found here: 
git://git.linaro.org/people/benjamin.gaignard/kernel.git
on branch: drm_kms_for_next-v4

version 3:
- Correctly split code between probe and bind funtions
- Squash some commits
- remove HQ-VDP device code to have a smaller patcheset,
  we will introduce it later.

patches could be found here: 
git://git.linaro.org/people/benjamin.gaignard/kernel.git
on branch: drm_kms_for_next-v3

version 2:
- Use componentized device instead of register sub-devices in master
driver probe function
- Fix Makefile and Kconfig to only allow built-in compilation

patches could be found here: 
git://git.linaro.org/people/benjamin.gaignard/kernel.git
on branch: drm_kms_for_next-v2

version 1:
- First path submission

Hardware is split in two main blocks: Compositor and TVout. Each of them
includes specific hardware IPs and the display timing are controlled by a 
specific
Video Timing Generator hardware IP (VTG).

Compositor is made of the follow hardware IPs:
 - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB)
   buffers
 - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers
 - HQVDP (High Quality Video Display Processor) that supports scaling,
   deinterlacing and some miscellaneous image quality improvements.
   It fetches the Video decoded buffers from memory, processes them and pushes
   them to the Compositor through a HW dedicated bus.
 - Mixer is responsible of mixing all the entries depending of their
   respective z-order and layout

TVout is divided in 3 parts:
 - HDMI to generate HDMI signals, depending of chipset version HDMI phy can
   change.
 - HDA to generate signals for HD analog TV
 - VIP to control/switch data path coming from Compositor

On stih416 compositor and Tvout are on different dies so a Video Trafic Advance
inter-die Communication mechanism (VTAC) is needed.

+-+   
++
| +---+   ++  |   |  ++   
+--+ |
| |   |   ||  |   |  ||   |  +-+
 ++  | |
| | ++  +--+  |   ||  |   |  ||   |  | VIP 
|>|HDMI|  | |
| | |GPD +->|  |  |   ||  |   |  ||   |  | |
 ++  | |
| | ++  |Mixer |--|-->||  |   |  ||---|->| switcher|
 | |
| | |  |  |   ||  |   |  ||   |  | |
 ++  | |
| | |  |  |   ||  |   |  ||   |  | 
|>|HDA |  | |
| | +--+  |   |VTAC|>|VTAC|   |  +-+
 ++  | |
| |   |   ||  |   |  ||   | 
 | |
| | Compositor|   ||  |   |  ||   |   TVout 
 | |
| +---+   ||  |   |  ||   
+--+ |
|  ^  ||  |   |  || ^   
   |
|  |  ||  |   |  || |   
   |
|   +--+  ||  |   |  ||  
+-+   |
|   | VTG (master) |->||  |   |  ||->| VTG (slave) 
|   |
|   +--+  ++  |   |  ++  
+-+   |
|Digital die  |   | 
 Analog Die|
+-+   
++

On stih407 Compositor and Tvout are on the same die

+-+
| +---+  +--+ |
| |   |  |  +-+ ++  | |
| | ++  +--+  |  |  | VIP |>|HDMI|  | |
| | |GPD +->|  |  |  |  | | ++  | |
| | ++  |Mixer |--|--|->| switcher| | |
| | ++   +-+|  |  |  |  | | ++  | |
| | |VDP +-->+HQVDP+--->|  |  |  |  | |>|HDA |  | |
| | ++   +-++--+  |  |  +-+ ++  | |
| |   |  |  | |
| | Compositor|  |   TVout  | |
| 

[PATCH v4 11/11] drm: sti: Add DRM driver itself

2014-05-29 Thread Benjamin Gaignard
Make the link between all the hardware drivers and DRM/KMS interface.
Create the driver itself and make it register all the sub-components.
Use GEM CMA helpers for buffer allocation.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Kconfig |   8 +
 drivers/gpu/drm/sti/Makefile|   8 +-
 drivers/gpu/drm/sti/sti_compositor.c|  47 +++-
 drivers/gpu/drm/sti/sti_drm_connector.c | 114 +
 drivers/gpu/drm/sti/sti_drm_connector.h |   4 +
 drivers/gpu/drm/sti/sti_drm_crtc.c  | 436 
 drivers/gpu/drm/sti/sti_drm_crtc.h  |  21 ++
 drivers/gpu/drm/sti/sti_drm_drv.c   | 229 +
 drivers/gpu/drm/sti/sti_drm_drv.h   |  35 +++
 drivers/gpu/drm/sti/sti_drm_encoder.c   | 108 
 drivers/gpu/drm/sti/sti_drm_encoder.h   |   3 +
 drivers/gpu/drm/sti/sti_drm_plane.c | 192 ++
 drivers/gpu/drm/sti/sti_drm_plane.h |  17 ++
 drivers/gpu/drm/sti/sti_hda.c   |   4 +
 drivers/gpu/drm/sti/sti_hdmi.c  |   4 +
 drivers/gpu/drm/sti/sti_tvout.c |   9 +
 16 files changed, 1237 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.c
 create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.c
 create mode 100644 drivers/gpu/drm/sti/sti_drm_crtc.h
 create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.c
 create mode 100644 drivers/gpu/drm/sti/sti_drm_drv.h
 create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.c
 create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.c
 create mode 100644 drivers/gpu/drm/sti/sti_drm_plane.h

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index 1013570..bb48696 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,6 +1,14 @@
 config DRM_STI
bool "DRM Support for STMicroelectronics SoC stiH41x Series"
depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
help
  Choose this option to enable DRM on STM stiH41x chipset
+
+config DRM_STI_FBDEV
+   bool "DRM frame buffer device for STMicroelectronics SoC stiH41x Serie"
+   depends on DRM_STI
+   help
+ Choose this option to enable FBDEV on top of DRM for STM stiH41x 
chipset
diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index a0612cc..e938028 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -7,7 +7,13 @@ obj-$(CONFIG_DRM_STI) += \
sti_hdmi_tx3g4c28phy.o \
sti_hda.o \
sti_tvout.o \
+   sti_drm_crtc.o \
+   sti_drm_plane.o \
+   sti_drm_connector.o \
+   sti_drm_encoder.o \
+   sti_hda.o \
sti_layer.o \
sti_mixer.o \
sti_gdp.o \
-   sti_vid.o
\ No newline at end of file
+   sti_vid.o \
+   sti_drm_drv.o
diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
index 3100917..d95da89 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -14,6 +14,9 @@
 #include 
 
 #include "sti_compositor.h"
+#include "sti_drm_crtc.h"
+#include "sti_drm_drv.h"
+#include "sti_drm_plane.h"
 #include "sti_gdp.h"
 #include "sti_vtg.h"
 
@@ -84,7 +87,48 @@ static int sti_compositor_init_subdev(struct sti_compositor 
*compo,
 static int sti_compositor_bind(struct device *dev, struct device *master,
void *data)
 {
-   /* to be filled with drm driver functions */
+   struct sti_compositor *compo = dev_get_drvdata(dev);
+   struct drm_device *drm_dev = data;
+   unsigned int i, crtc = 0, plane = 0;
+   struct sti_drm_private *dev_priv = drm_dev->dev_private;
+
+   dev_priv->compo = compo;
+   INIT_LIST_HEAD(_priv->pageflip_evt_list);
+
+   for (i = 0; i < compo->nb_mixers; i++) {
+   if (compo->mixer[i]) {
+   sti_drm_crtc_init(drm_dev, compo->mixer[i]);
+   crtc++;
+   }
+   }
+   if (crtc == 0) {
+   DRM_ERROR("No CRTC available\n");
+   return 1;
+   }
+
+   drm_vblank_init(drm_dev, crtc);
+   /* Allow usage of vblank without having to call drm_irq_install */
+   drm_dev->irq_enabled = 1;
+
+   for (i = 0; i < compo->nb_layers; i++) {
+   if (compo->layer[i]) {
+   /* Create planes for GDP.
+* except GDP0 as it is reserved for CRTC FB */
+   enum sti_layer_desc desc = compo->layer[i]->desc;
+   enum sti_layer_type type = desc & STI_LAYER_TYPE_MASK;
+
+   if ((type == STI_GDP) && (desc != STI_GDP_0)) {
+   sti_drm_plane_init(drm_dev, compo->layer[i],
+  (1 << crtc) - 1);
+   plane++;
+   }
+   

[PATCH v4 08/11] drm: sti: add VID layer

2014-05-29 Thread Benjamin Gaignard
VIDeo plug are one of the compositor input sub-devices.
VID are dedicated to video inputs like YUV plans.

Like GDP, VID are part of Compositor hardware block
and use sti_layer structure to provide an abstraction for
Compositor calls.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile|   3 +-
 drivers/gpu/drm/sti/sti_layer.h |   3 +
 drivers/gpu/drm/sti/sti_vid.c   | 138 
 drivers/gpu/drm/sti/sti_vid.h   |  33 ++
 4 files changed, 176 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/sti/sti_vid.c
 create mode 100644 drivers/gpu/drm/sti/sti_vid.h

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index 1745697..bb0f6b3 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_DRM_STI) += \
sti_hdmi_tx3g4c28phy.o \
sti_hda.o \
sti_tvout.o \
-   sti_gdp.o
\ No newline at end of file
+   sti_gdp.o \
+   sti_vid.o
\ No newline at end of file
diff --git a/drivers/gpu/drm/sti/sti_layer.h b/drivers/gpu/drm/sti/sti_layer.h
index 7ba5a40..c8a159d 100644
--- a/drivers/gpu/drm/sti/sti_layer.h
+++ b/drivers/gpu/drm/sti/sti_layer.h
@@ -11,6 +11,7 @@
 
 #include 
 #include "sti_gdp.h"
+#include "sti_vid.h"
 
 #define to_sti_layer(x) container_of(x, struct sti_layer, plane)
 
@@ -70,6 +71,7 @@ struct sti_fps_info {
  * @paddr:  physical address of the input buffer
  * @fps_info:   frame per second info
  * @gdp:related GDP (if the layer is a GDP)
+ * @vid:related VID (if the layer is a VID/VDP)
  */
 struct sti_layer {
struct drm_plane plane;
@@ -89,6 +91,7 @@ struct sti_layer {
dma_addr_t paddr;
struct sti_fps_info fps_info;
struct sti_gdp *gdp;
+   struct sti_vid *vid;
 };
 
 struct sti_layer *sti_layer_create(struct device *dev, int desc,
diff --git a/drivers/gpu/drm/sti/sti_vid.c b/drivers/gpu/drm/sti/sti_vid.c
new file mode 100644
index 000..0197291
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_vid.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Author: Fabien Dessenne  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+
+#include "sti_layer.h"
+#include "sti_vid.h"
+#include "sti_vtg.h"
+
+/* Registers */
+#define VID_CTL 0x00
+#define VID_ALP 0x04
+#define VID_CLF 0x08
+#define VID_VPO 0x0C
+#define VID_VPS 0x10
+#define VID_KEY10x28
+#define VID_KEY20x2C
+#define VID_MPR00x30
+#define VID_MPR10x34
+#define VID_MPR20x38
+#define VID_MPR30x3C
+#define VID_MST 0x68
+#define VID_BC  0x70
+#define VID_TINT0x74
+#define VID_CSAT0x78
+
+/* Registers values */
+#define VID_CTL_IGNORE  (BIT(31) | BIT(30))
+#define VID_CTL_PSI_ENABLE  (BIT(2) | BIT(1) | BIT(0))
+#define VID_ALP_OPAQUE  0x0080
+#define VID_BC_DFLT 0x8000
+#define VID_TINT_DFLT   0x
+#define VID_CSAT_DFLT   0x0080
+/* YCbCr to RGB BT709:
+ * R = Y+1.5391Cr
+ * G = Y-0.4590Cr-0.1826Cb
+ * B = Y+1.8125Cb */
+#define VID_MPR0_BT709  0x0A80
+#define VID_MPR1_BT709  0x0AC5
+#define VID_MPR2_BT709  0x07150545
+#define VID_MPR3_BT709  0x0AE8
+
+static int sti_vid_prepare_layer(void *lay, bool first_prepare)
+{
+   u32 val;
+   struct sti_layer *layer = (struct sti_layer *)lay;
+   struct sti_vid *vid = layer->vid;
+
+   /* Unmask */
+   val = readl(vid->regs + VID_CTL);
+   val &= ~VID_CTL_IGNORE;
+   writel(val, vid->regs + VID_CTL);
+
+   return 0;
+}
+
+static int sti_vid_commit_layer(void *lay)
+{
+   struct sti_layer *layer = (struct sti_layer *)lay;
+   struct sti_vid *vid = layer->vid;
+   struct drm_display_mode *mode = layer->mode;
+   u32 ydo, xdo, yds, xds;
+
+   ydo = sti_vtg_get_line_number(*mode, layer->dst_y);
+   yds = sti_vtg_get_line_number(*mode, layer->dst_y + layer->dst_h - 1);
+   xdo = sti_vtg_get_pixel_number(*mode, layer->dst_x);
+   xds = sti_vtg_get_pixel_number(*mode, layer->dst_x + layer->dst_w - 1);
+
+   writel((ydo << 16) | xdo, vid->regs + VID_VPO);
+   writel((yds << 16) | xds, vid->regs + VID_VPS);
+
+   return 0;
+}
+
+static int sti_vid_disable_layer(void *lay)
+{
+   u32 val;
+   struct sti_layer *layer = (struct sti_layer *)lay;
+   struct sti_vid *vid = layer->vid;
+
+   /* Mask */
+   val = readl(vid->regs + VID_CTL);
+   val |= VID_CTL_IGNORE;
+   writel(val, vid->regs + VID_CTL);
+
+   return 0;
+}
+
+static void sti_vid_set_default(struct sti_vid *vid)
+{
+   /* Enable PSI, Mask layer */
+   

[PATCH v4 10/11] drm: sti: add Compositor

2014-05-29 Thread Benjamin Gaignard
Compositor control all the input sub-device (VID, GDP)
and the mixer(s).
It is the main entry point for composition.
Layer interface is used to control the abstracted layers.

Add debug in mixer, GDP and VID

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Kconfig  |   1 +
 drivers/gpu/drm/sti/Makefile |   2 +
 drivers/gpu/drm/sti/sti_compositor.c | 220 
 drivers/gpu/drm/sti/sti_compositor.h |  90 ++
 drivers/gpu/drm/sti/sti_gdp.c|  30 
 drivers/gpu/drm/sti/sti_layer.c  | 312 +++
 drivers/gpu/drm/sti/sti_mixer.c  |   6 +
 drivers/gpu/drm/sti/sti_vid.c|   7 +
 8 files changed, 668 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/sti_compositor.c
 create mode 100644 drivers/gpu/drm/sti/sti_compositor.h
 create mode 100644 drivers/gpu/drm/sti/sti_layer.c

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index cbd664b..1013570 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,5 +1,6 @@
 config DRM_STI
bool "DRM Support for STMicroelectronics SoC stiH41x Series"
depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
+   select DRM_KMS_CMA_HELPER
help
  Choose this option to enable DRM on STM stiH41x chipset
diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index ce03e15..a0612cc 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -1,11 +1,13 @@
 obj-$(CONFIG_DRM_STI) += \
sti_vtg.o \
sti_vtac.o \
+   sti_compositor.o \
sti_hdmi.o \
sti_hdmi_tx3g0c55phy.o \
sti_hdmi_tx3g4c28phy.o \
sti_hda.o \
sti_tvout.o \
+   sti_layer.o \
sti_mixer.o \
sti_gdp.o \
sti_vid.o
\ No newline at end of file
diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
new file mode 100644
index 000..3100917
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -0,0 +1,220 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Authors: Benjamin Gaignard 
+ *  Fabien Dessenne 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "sti_compositor.h"
+#include "sti_gdp.h"
+#include "sti_vtg.h"
+
+/*
+ * stiH407 compositor properties
+ */
+struct sti_compositor_data stih407_compositor_data = {
+   .nb_subdev = 6,
+   .subdev_desc = {
+   {STI_GPD_SUBDEV, (int)STI_GDP_0, 0x100},
+   {STI_GPD_SUBDEV, (int)STI_GDP_1, 0x200},
+   {STI_GPD_SUBDEV, (int)STI_GDP_2, 0x300},
+   {STI_GPD_SUBDEV, (int)STI_GDP_3, 0x400},
+   {STI_VID_SUBDEV, (int)STI_VID_0, 0x700},
+   {STI_MIXER_MAIN_SUBDEV, STI_MIXER_MAIN, 0xC00}
+   },
+};
+
+/*
+ * stiH416 compositor properties
+ * Note:
+ * on stih416 MIXER_AUX has a different base address from MIXER_MAIN
+ * Moreover, GDPx is different for Main and Aux Mixer. So this subdev map does
+ * not fit for stiH416 if we want to enable the MIXER_AUX.
+ */
+struct sti_compositor_data stih416_compositor_data = {
+   .nb_subdev = 3,
+   .subdev_desc = {
+   {STI_GPD_SUBDEV, (int)STI_GDP_0, 0x100},
+   {STI_GPD_SUBDEV, (int)STI_GDP_1, 0x200},
+   {STI_MIXER_MAIN_SUBDEV, STI_MIXER_MAIN, 0xC00}
+   },
+};
+
+static int sti_compositor_init_subdev(struct sti_compositor *compo,
+   struct sti_compositor_subdev_descriptor *desc,
+   unsigned int array_size)
+{
+   unsigned int i, mixer_id = 0, layer_id = 0;
+
+   for (i = 0; i < array_size; i++) {
+   switch (desc[i].type) {
+   case STI_MIXER_MAIN_SUBDEV:
+   case STI_MIXER_AUX_SUBDEV:
+   compo->mixer[mixer_id++] =
+   sti_mixer_create(compo->dev, desc[i].id,
+compo->regs + desc[i].offset);
+   break;
+   case STI_GPD_SUBDEV:
+   case STI_VID_SUBDEV:
+   compo->layer[layer_id++] =
+   sti_layer_create(compo->dev, desc[i].id,
+compo->regs + desc[i].offset);
+   break;
+   /* case STI_CURSOR_SUBDEV : TODO */
+   default:
+   DRM_ERROR("Unknow subdev compoment type\n");
+   return 1;
+   }
+
+   }
+   compo->nb_mixers = mixer_id;
+   compo->nb_layers = layer_id;
+
+   return 0;
+}
+
+static int sti_compositor_bind(struct device *dev, struct device *master,
+   void *data)
+{
+   /* to be filled with drm driver functions */
+   return 0;
+}

[PATCH v4 04/11] drm: sti: add HDMI driver

2014-05-29 Thread Benjamin Gaignard
Add driver for HDMI output.
HDMI PHY registers are mixed into HDMI device registers
and their is only one IRQ for all this hardware block.
That is why PHYs aren't using phy framework but only a
thin hdmi_phy_ops structure with start and stop functions.

This patch introduce sti_connector structure which will be
use later in the drm driver.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile   |   5 +-
 drivers/gpu/drm/sti/sti_drm_connector.h|  51 ++
 drivers/gpu/drm/sti/sti_drm_encoder.h  |  14 +
 drivers/gpu/drm/sti/sti_hdmi.c | 744 +
 drivers/gpu/drm/sti/sti_hdmi.h |  88 
 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 +
 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h |  14 +
 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 211 
 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.h |  14 +
 9 files changed, 1476 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/sti/sti_drm_connector.h
 create mode 100644 drivers/gpu/drm/sti/sti_drm_encoder.h
 create mode 100644 drivers/gpu/drm/sti/sti_hdmi.c
 create mode 100644 drivers/gpu/drm/sti/sti_hdmi.h
 create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c
 create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h
 create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c
 create mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.h

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index 52e2e80..5521a85 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -1,3 +1,6 @@
 obj-$(CONFIG_DRM_STI) += \
sti_vtg.o \
-   sti_vtac.o
+   sti_vtac.o \
+   sti_hdmi.o \
+   sti_hdmi_tx3g0c55phy.o \
+   sti_hdmi_tx3g4c28phy.o
\ No newline at end of file
diff --git a/drivers/gpu/drm/sti/sti_drm_connector.h 
b/drivers/gpu/drm/sti/sti_drm_connector.h
new file mode 100644
index 000..798bd5c
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_drm_connector.h
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Author: Benjamin Gaignard  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#ifndef _STI_DRM_CONNECTOR_H_
+#define _STI_DRM_CONNECTOR_H_
+
+/*
+ * enum listing the supported connector
+ */
+enum sti_connector_type {
+   STI_CONNECTOR_HDMI,
+   STI_CONNECTOR_HDA,
+   STI_CONNECTOR_DVO,
+   STI_CONNECTOR_DENC,
+};
+
+/**
+ * struct sti_connector
+ *
+ * internal definition of connector
+ *
+ * @drm_connector: generic drm_connector struct
+ * @encoder: the linked encoder
+ * @dev: the connector device
+ * @master: the master device (i.e. tvout device)
+ * @type: the connector type
+ */
+struct sti_connector {
+   struct drm_connector drm_connector;
+   struct drm_encoder *encoder;
+   struct device *dev;
+   struct device *master;
+   enum  sti_connector_type type;
+   int  (*start)(struct drm_connector *connector);
+   void (*stop)(struct drm_connector *connector);
+   int  (*get_modes)(struct drm_connector *drm_connector);
+   int  (*check_mode)(struct drm_connector *connector,
+   struct drm_display_mode *mode);
+   int  (*set_mode)(struct drm_connector *connector,
+   struct drm_display_mode *mode, bool main_path);
+   int  (*detect)(struct drm_connector *connector);
+   void (*prepare)(struct drm_connector *connector);
+   bool (*is_enabled)(struct drm_connector *connector);
+};
+
+#define to_sti_connector(x) container_of(x, struct sti_connector, 
drm_connector)
+
+#endif
diff --git a/drivers/gpu/drm/sti/sti_drm_encoder.h 
b/drivers/gpu/drm/sti/sti_drm_encoder.h
new file mode 100644
index 000..bc7a91c
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_drm_encoder.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Author: Benjamin Gaignard  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#ifndef _STI_DRM_ENCODER_H_
+#define _STI_DRM_ENCODER_H_
+
+#include 
+
+#define ENCODER_MAIN_CRTC_MASK BIT(0)
+
+#endif
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
new file mode 100644
index 000..c963468
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -0,0 +1,744 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Author: Vincent Abriou  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "sti_drm_connector.h"
+#include "sti_drm_encoder.h"
+#include "sti_hdmi.h"
+#include "sti_hdmi_tx3g4c28phy.h"
+#include "sti_hdmi_tx3g0c55phy.h"
+#include "sti_vtg.h"
+
+#define HDMI_CFG0x
+#define HDMI_INT_EN 0x0004
+#define HDMI_INT_STA0x0008
+#define HDMI_INT_CLR0x000C

[PATCH v2 15/18] ARM: dts: dra7: Add dt data for PCIe controller

2014-05-29 Thread Kishon Vijay Abraham I
Added dt data for PCIe controller. This node contains dt data for
both the DRA7 part of designware controller and for the designware core.
The documention for this node can be found @ ../bindings/pci/ti-pci.txt.

Cc: Tony Lindgren 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Cc: Bjorn Helgaas 
Cc: Jingoo Han 
Cc: Jason Gunthorpe 
Cc: Marek Vasut 
Cc: Arnd Bergmann 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |   69 +++
 1 file changed, 69 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index eaeccaf..1239f0d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1036,6 +1036,75 @@
};
};
 
+   axi@0 {
+   compatible = "simple-bus";
+   #size-cells = <1>;
+   #address-cells = <1>;
+   ranges = <0x5100 0x5100 0x3000
+ 0x00x2000 0x1000>;
+   pcie@5100 {
+   compatible = "ti,dra7-pcie";
+   reg = <0x5100 0x2000>, <0x51002000 0x14c>, 
<0x1000 0x2000>;
+   reg-names = "rc_dbics", "ti_conf", "config";
+   interrupts = <0 232 0x4>, <0 233 0x4>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   ranges = <0x8100 0 0  0x03000 0 
0x0001
+ 0x8200 0 0x20013000 0x13000 0 
0xffed000>;
+   #interrupt-cells = <1>;
+   num-lanes = <1>;
+   ti,hwmods = "pcie1";
+   phys = <_phy>;
+   phy-names = "pcie-phy0";
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = <0 0 0 1 _intc 1>,
+   <0 0 0 2 _intc 2>,
+   <0 0 0 3 _intc 3>,
+   <0 0 0 4 _intc 4>;
+   pcie1_intc: interrupt-controller {
+   interrupt-controller;
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   };
+   };
+   };
+
+   axi@1 {
+   compatible = "simple-bus";
+   #size-cells = <1>;
+   #address-cells = <1>;
+   ranges = <0x5180 0x5180 0x3000
+ 0x00x3000 0x1000>;
+   status = "disabled";
+   pcie@5100 {
+   compatible = "ti,dra7-pcie";
+   reg = <0x5180 0x2000>, <0x51802000 0x14c>, 
<0x1000 0x2000>;
+   reg-names = "rc_dbics", "ti_conf", "config";
+   interrupts = <0 355 0x4>, <0 356 0x4>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   ranges = <0x8100 0 0  0x03000 0 
0x0001
+ 0x8200 0 0x30013000 0x13000 0 
0xffed000>;
+   #interrupt-cells = <1>;
+   num-lanes = <1>;
+   ti,hwmods = "pcie2";
+   phys = <_phy>;
+   phy-names = "pcie-phy0";
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = <0 0 0 1 _intc 1>,
+   <0 0 0 2 _intc 2>,
+   <0 0 0 3 _intc 3>,
+   <0 0 0 4 _intc 4>;
+   pcie2_intc: interrupt-controller {
+   interrupt-controller;
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   };
+   };
+   };
+
sata: sata@4a141100 {
compatible = "snps,dwc-ahci";
reg = <0x4a14 0x1100>, <0x4a141100 0x7>;
-- 
1.7.9.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  

[PATCH v2 04/18] PCI: designware: use untranslated address while programming ATU

2014-05-29 Thread Kishon Vijay Abraham I
In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit
address. So whenever the cpu issues a read/write request, the 4 most
significant bits are used by L3 to determine the target controller.
For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but
the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming
the outbound translation window the *base* should be programmed as 0x000_.
Whenever we try to write to say 0x2000_, it will be translated to whatever
we have programmed in the translation window with base as 0x000_.

This is needed when the dt node is modelled something like below
axi {
compatible = "simple-bus";
#size-cells = <1>;
#address-cells = <1>;
ranges = <0x00x2000 0x1000 // 28-bit bus
  0x5100 0x5100 0x3000>;
pcie@5100 {
reg = <0x1000 0x2000>, <0x51002000 0x14c>, <0x5100 0x2000>;
reg-names = "config", "ti_conf", "rc_dbics";
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x8100 0 0  0x03000 0 0x0001
  0x8200 0 0x20013000 0x13000 0 0xffed000>;
};
};

Here the CPU address for configuration space is 0x20013000 and the controller
address for configuration space is 0x13000. The controller address should be
used while programming the ATU (in order for translation to happen properly in
DRA7xx).

Cc: Jason Gunthorpe 
Cc: Bjorn Helgaas 
Cc: Mohit Kumar 
Cc: Jingoo Han 
Cc: Marek Vasut 
Cc: Arnd Bergmann 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/host/pcie-designware.c |   49 
 drivers/pci/host/pcie-designware.h |4 +++
 2 files changed, 42 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index 603b386..9dfd2d4 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -397,8 +397,15 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
struct of_pci_range range;
struct of_pci_range_parser parser;
struct resource *cfg_res;
-   u32 val;
-   int i;
+   u32 val, na, ns;
+   const __be32 *addrp;
+   int i, index;
+
+   /* Find the address cell size and the number of cells in order to get
+* the untranslated address.
+*/
+   of_property_read_u32(np, "#address-cells", );
+   ns = of_n_size_cells(np);
 
cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
if (cfg_res) {
@@ -406,6 +413,12 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
pp->config.cfg1_size = resource_size(cfg_res)/2;
pp->cfg0_base = cfg_res->start;
pp->cfg1_base = cfg_res->start + pp->config.cfg0_size;
+
+   /* Find the untranslated configuration space address */
+   index = of_property_match_string(np, "reg-names", "config");
+   addrp = of_get_address(np, index, false, false);
+   pp->cfg0_mod_addr = of_read_number(addrp, ns);
+   pp->cfg1_mod_addr = pp->cfg0_mod_addr + pp->config.cfg0_size;
} else {
dev_err(pp->dev, "missing *config* reg space\n");
}
@@ -431,12 +444,20 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
pp->config.io_size = resource_size(>io);
pp->config.io_bus_addr = range.pci_addr;
pp->io_base = range.cpu_addr;
+
+   /* Find the untranslated IO space address */
+   pp->io_mod_addr = of_read_number(parser.range -
+parser.np + na, ns);
}
if (restype == IORESOURCE_MEM) {
of_pci_range_to_resource(, np, >mem);
pp->mem.name = "MEM";
pp->config.mem_size = resource_size(>mem);
pp->config.mem_bus_addr = range.pci_addr;
+
+   /* Find the untranslated MEM space address */
+   pp->mem_mod_addr = of_read_number(parser.range -
+ parser.np + na, ns);
}
if (restype == 0) {
of_pci_range_to_resource(, np, >cfg);
@@ -444,6 +465,12 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
pp->config.cfg1_size = resource_size(>cfg)/2;
pp->cfg0_base = pp->cfg.start;
pp->cfg1_base = pp->cfg.start + pp->config.cfg0_size;
+
+   /* Find the untranslated configuration space address */
+   pp->cfg0_mod_addr = of_read_number(parser.range -
+  parser.np 

[PATCH v2 02/18] phy: pipe3: insert delay to enumerate in GEN2 mode

2014-05-29 Thread Kishon Vijay Abraham I
8-bit delay value (0xF1) is required for GEN2 devices to be enumerated
consistently. Added an API to be called from PHY drivers to set this delay
value and called it from PIPE3 driver to set the delay value.

Signed-off-by: Kishon Vijay Abraham I 
Reviewed-by: Roger Quadros 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |   12 ++---
 drivers/phy/phy-omap-control.c   |   52 +-
 drivers/phy/phy-ti-pipe3.c   |4 +-
 include/linux/phy/omap_control_phy.h |   10 +
 4 files changed, 71 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index cf3de7e..36bb6c9 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -9,15 +9,17 @@ Required properties:
 e.g. USB2_PHY on OMAP5.
  "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
 e.g. USB3 PHY and SATA PHY on OMAP5.
+ "ti,control-phy-pcie" - for pcie to support external clock for pcie and to
+   set PCS delay value.
+   e.g. PCIE PHY in DRA7x
  "ti,control-phy-usb2-dra7" - if it has power down register like USB2 PHY on
 DRA7 platform.
  "ti,control-phy-usb2-am437" - if it has power down register like USB2 PHY on
 AM437 platform.
- - reg : Address and length of the register set for the device. It contains
-   the address of "otghs_control" for control-phy-otghs or "power" register
-   for other types.
- - reg-names: should be "otghs_control" control-phy-otghs and "power" for
-   other types.
+ - reg : register ranges as listed in the reg-names property
+ - reg-names: "otghs_control" for control-phy-otghs
+ "power", "pcie_pcs" and "control_sma" for control-phy-pcie
+ "power" for all other types
 
 omap_control_usb: omap-control-usb@4a002300 {
 compatible = "ti,control-phy-otghs";
diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c
index 311b4f9..9487bf1 100644
--- a/drivers/phy/phy-omap-control.c
+++ b/drivers/phy/phy-omap-control.c
@@ -27,6 +27,41 @@
 #include 
 
 /**
+ * omap_control_pcie_pcs - set the PCS delay count
+ * @dev: the control module device
+ * @id: index of the pcie PHY (should be 1 or 2)
+ * @delay: 8 bit delay value
+ */
+void omap_control_pcie_pcs(struct device *dev, u8 id, u8 delay)
+{
+   u32 val;
+   struct omap_control_phy *control_phy;
+
+   if (IS_ERR(dev) || !dev) {
+   pr_err("%s: invalid device\n", __func__);
+   return;
+   }
+
+   control_phy = dev_get_drvdata(dev);
+   if (!control_phy) {
+   dev_err(dev, "%s: invalid control phy device\n", __func__);
+   return;
+   }
+
+   if (control_phy->type != OMAP_CTRL_TYPE_PCIE) {
+   dev_err(dev, "%s: unsupported operation\n", __func__);
+   return;
+   }
+
+   val = readl(control_phy->pcie_pcs);
+   val &= ~(OMAP_CTRL_PCIE_PCS_MASK <<
+   (id * OMAP_CTRL_PCIE_PCS_DELAY_COUNT_SHIFT));
+   val |= delay << (id * OMAP_CTRL_PCIE_PCS_DELAY_COUNT_SHIFT);
+   writel(val, control_phy->pcie_pcs);
+}
+EXPORT_SYMBOL_GPL(omap_control_pcie_pcs);
+
+/**
  * omap_control_phy_power - power on/off the phy using control module reg
  * @dev: the control module device
  * @on: 0 or 1, based on powering on or off the PHY
@@ -61,6 +96,7 @@ void omap_control_phy_power(struct device *dev, int on)
val |= OMAP_CTRL_DEV_PHY_PD;
break;
 
+   case OMAP_CTRL_TYPE_PCIE:
case OMAP_CTRL_TYPE_PIPE3:
rate = clk_get_rate(control_phy->sys_clk);
rate = rate/100;
@@ -211,6 +247,7 @@ EXPORT_SYMBOL_GPL(omap_control_usb_set_mode);
 static const enum omap_control_phy_type otghs_data = OMAP_CTRL_TYPE_OTGHS;
 static const enum omap_control_phy_type usb2_data = OMAP_CTRL_TYPE_USB2;
 static const enum omap_control_phy_type pipe3_data = OMAP_CTRL_TYPE_PIPE3;
+static const enum omap_control_phy_type pcie_data = OMAP_CTRL_TYPE_PCIE;
 static const enum omap_control_phy_type dra7usb2_data = 
OMAP_CTRL_TYPE_DRA7USB2;
 static const enum omap_control_phy_type am437usb2_data = 
OMAP_CTRL_TYPE_AM437USB2;
 
@@ -228,6 +265,10 @@ static const struct of_device_id 
omap_control_phy_id_table[] = {
.data = _data,
},
{
+   .compatible = "ti,control-phy-pcie",
+   .data = _data,
+   },
+   {
.compatible = "ti,control-phy-usb2-dra7",
.data = _data,
},
@@ -279,7 +320,8 @@ static int omap_control_phy_probe(struct platform_device 
*pdev)
}
}
 
-   if (control_phy->type == OMAP_CTRL_TYPE_PIPE3) {
+   if (control_phy->type == OMAP_CTRL_TYPE_PIPE3 ||
+   

[PATCH v2 00/18] PCIe support for DRA7xx

2014-05-29 Thread Kishon Vijay Abraham I
This patch series adds support for PCIe in DRA7xx including drivers and dt
data. PCIe in DRA7xx uses desingware IP and hence this re-uses the
pcie desingware driver (pcie-designware.c) by Jingoo.

The last couple of patches are marked as *TEMP* since the TI reset driver [1]
is not yet merged and is in RFC.

Tested broadcom PCIe card and XIO2000 bridge along with DGE530T ethernet
card.

Changes from v1:
* removed external clock support fro APLL since the clock framework patches
  are still in RFC.
* The configuration address space should be given in *reg* and made the
  corresponding driver changes in pcie-designware.c
* Used untraslated address while programming ATU since that is needed for
  DRA7. With this PCIe should be made the child node of axi.
* Used a new irq domain for PCIe legacy interrupts.
* Added clocks and dt data for the second instance of PCIe controller (with
  status = disabled).

Changes from RFC:
* Added external clock support for PCIE APLL
* Miscellaneous cleanups in Documentation, macro naming etc..

[1] -> http://www.spinics.net/lists/linux-omap/msg106411.html
Keerthy (2):
  ARM: dts: DRA7: Add divider table to optfclk_pciephy_div clock
  ARM: dts: DRA7: Change the parent of apll_pcie_in_clk_mux to
dpll_pcie_ref_m2ldo_ck

Kishon Vijay Abraham I (16):
  phy: phy-omap-pipe3: Add support for PCIe PHY
  phy: pipe3: insert delay to enumerate in GEN2 mode
  PCI: designware: Configuration space should be specified in 'reg'
  PCI: designware: use untranslated address while programming ATU
  PCI: host: pcie-dra7xx: add support for pcie-dra7xx controller
  arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy
  arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
  ARM: dts: dra7xx-clocks: Add missing 32khz clocks used for PHY
  ARM: dts: dra7: Add dt data for PCIe PHY control module
  ARM: dts: dra7xx-clocks: rename pcie clocks to accommodate second PHY
instance
  ARM: dts: dra7xx-clocks: Add missing clocks for second PCIe PHY
instance
  ARM: dts: dra7: Add dt data for PCIe PHY
  ARM: dts: dra7: Add dt data for PCIe controller
  ARM: OMAP: Enable PCI for DRA7
  PCI: host: pcie-dra7xx: use reset framework APIs to reset PCIe
  ARM: dts: dra7: Add *resets* property for PCIe dt node

 .../devicetree/bindings/pci/designware-pcie.txt|1 +
 Documentation/devicetree/bindings/pci/ti-pci.txt   |   63 +++
 Documentation/devicetree/bindings/phy/ti-phy.txt   |   20 +-
 arch/arm/boot/dts/dra7.dtsi|  127 ++
 arch/arm/boot/dts/dra7xx-clocks.dtsi   |   39 +-
 arch/arm/mach-omap2/Kconfig|2 +
 arch/arm/mach-omap2/cm2_7xx.h  |4 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c  |  112 +
 arch/arm/mach-omap2/prm7xx.h   |4 +
 drivers/pci/host/Kconfig   |   10 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pci-dra7xx.c  |  470 
 drivers/pci/host/pcie-designware.c |   66 ++-
 drivers/pci/host/pcie-designware.h |4 +
 drivers/phy/phy-omap-control.c |   52 ++-
 drivers/phy/phy-ti-pipe3.c |  101 -
 include/linux/phy/omap_control_phy.h   |   10 +
 17 files changed, 1041 insertions(+), 45 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
 create mode 100644 drivers/pci/host/pci-dra7xx.c

-- 
1.7.9.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/


[TEMP PATCH v2 17/18] PCI: host: pcie-dra7xx: use reset framework APIs to reset PCIe

2014-05-29 Thread Kishon Vijay Abraham I
Get reset nodes from dt and use reset framework APIs to reset PCIe.
This is needed since reset is handled by the SoC.

Cc: Dan Murphy 
Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/pci/ti-pci.txt |4 
 drivers/pci/host/pci-dra7xx.c|   10 ++
 2 files changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index d07d2eb..3649c2e 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -22,6 +22,8 @@ PCIe Designware Controller
num-lanes,
interrupt-map-mask,
interrupt-map : as specified in ../designware-pcie.txt
+ - resets: phandle used if reset is handled be soc
+ - reset-names: name given to the phandle
 
 Example:
 axi {
@@ -45,6 +47,8 @@ axi {
ti,hwmods = "pcie1";
phys = <_phy>;
phy-names = "pcie-phy0";
+   resets = <_resets _reset>;
+   reset-names = "reset";
interrupt-map-mask = <0 0 0 7>;
interrupt-map = <0 0 0 1 _intc 1>,
<0 0 0 2 _intc 2>,
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 8fb3a2e..17f5e6a 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "pcie-designware.h"
@@ -332,6 +333,7 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
struct device *dev = >dev;
struct device_node *np = dev->of_node;
char name[10];
+   struct reset_control *rstc;
 
dra7xx = devm_kzalloc(dev, sizeof(*dra7xx), GFP_KERNEL);
if (!dra7xx)
@@ -355,6 +357,14 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
if (!base)
return -ENOMEM;
 
+   rstc = devm_reset_control_get(dev, "reset");
+   if (IS_ERR(rstc))
+   return PTR_ERR(rstc);
+
+   ret = reset_control_deassert(rstc);
+   if (ret)
+   return ret;
+
phy_count = of_property_count_strings(np, "phy-names");
if (phy_count < 0) {
dev_err(dev, "unable to find the strings\n");
-- 
1.7.9.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/


[PATCH v2 16/18] ARM: OMAP: Enable PCI for DRA7

2014-05-29 Thread Kishon Vijay Abraham I
Now that we have added PCIe driver for DRA7 SOCs, enable PCI on
DRA7 SOCs.

Cc: Tony Lindgren 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/mach-omap2/Kconfig |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index cb31d43..b179e80 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -75,6 +75,8 @@ config SOC_DRA7XX
select ARM_GIC
select HAVE_ARM_ARCH_TIMER
select IRQ_CROSSBAR
+   select MIGHT_HAVE_PCI
+   select ARCH_SUPPORTS_MSI
 
 config ARCH_OMAP2PLUS
bool
-- 
1.7.9.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/


[TEMP PATCH v2 18/18] ARM: dts: dra7: Add *resets* property for PCIe dt node

2014-05-29 Thread Kishon Vijay Abraham I
Added *resets* and *reset-names* properies for PCIe dt node.
The documention for this node can be found @ ../bindings/pci/ti-pci.txt.

Cc: Dan Murphy 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1239f0d..03494b2 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1055,6 +1055,8 @@
#interrupt-cells = <1>;
num-lanes = <1>;
ti,hwmods = "pcie1";
+   resets = <_resets _reset>;
+   reset-names = "reset";
phys = <_phy>;
phy-names = "pcie-phy0";
interrupt-map-mask = <0 0 0 7>;
-- 
1.7.9.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 V2] staging: dgap: implement proper error handling in dgap_firmware_load()

2014-05-29 Thread Dan Carpenter
On Thu, May 29, 2014 at 09:17:09AM +0900, DaeSeok Youn wrote:
> Hi, Dan.
> 
> 2014-05-28 19:11 GMT+09:00 Dan Carpenter :
> > On Wed, May 28, 2014 at 06:29:38PM +0900, DaeSeok Youn wrote:
> >> > In your patch it has:
> >> > +   dgap_tty_uninit(brd, false);
> >> >
> >> > But it should only be "false" if dgap_tty_init() failed.  If
> >> > dgap_tty_register_ports() fails then it should be "true".  Another
> >> Yes, you're right. There were no error handle for 
> >> tty_port_register_device() and
> >> dgap_create_tty_sysfs() in dgap_tty_register_ports(). I didn't catch it. 
> >> :-(
> >> It need to add error handlers for them, right?
> >
> > Eventually, yes.  But I don't see a simple way to fix
> > dgap_firmware_load() until after the code is cleaned up.
> >
> >>
> >> > problem is that as you say, the earlier function are allocating
> >> > resources like dgap_tty_register() but only the last two function calls
> >> > have a "goto err_cleanup;" so the error handling is incomplete.
> >> So remove "goto" in dgap_firmware_load() and add error handler in
> >> dgap_tty_init()
> >
> > In the current code there isn't a goto in dgap_firmware_load().  Remove
> > the call to dgap_tty_uninit() and add error handling in dgap_tty_init().
> Yes. I will try to fix it.
> >
> > That will clean up the code, and fix some NULL dereference bugs inside
> > dgap_tty_uninit().
> >
> >> and dgap_tty_register_ports(), right?
> >
> > Inside dgap_tty_register_ports(), then we should add a
> > kfree(brd->serial_ports) if the "brd->printer_ports" allocation fails.
> > That is not a complete fix, but it is a part fix and it is clean.
> Actually, I sent a patch which is removing "kfree(brd->serial_ports)" and 
> pushed
> into staging-next branch.
> see the 0ade4a34fd43 staging: dgap: remove unneeded kfree() in
> dgap_tty_register_ports()
> Because I think dgap_tty_uninit() will free "brd->serial_ports" with this 
> patch.
> 
> Can I send a patch after revert "0ade4a34fd43" commit?

Oh, crud.  I missed that.  Yeah.  Let's revert it.

regards,
dan carpenter

--
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 v2 10/18] ARM: dts: dra7xx-clocks: Add missing 32khz clocks used for PHY

2014-05-29 Thread Kishon Vijay Abraham I
Added missing 32khz clock used by PCIe PHY.
The documention for this node can be found @ ../bindings/clock/ti/gate.txt.

Cc: Tony Lindgren 
Cc: Rajendra Nayak 
Cc: Tero Kristo 
Cc: Paul Walmsley 
Cc: Tony Lindgren 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi 
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 44993ec..e1bd052 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1165,6 +1165,14 @@
reg = <0x021c>, <0x0220>;
};
 
+   optfclk_pciephy_32khz: optfclk_pciephy_32khz@4a0093b0 {
+   compatible = "ti,gate-clock";
+   clocks = <_32k_ck>;
+   #clock-cells = <0>;
+   reg = <0x13b0>;
+   ti,bit-shift = <8>;
+   };
+
optfclk_pciephy_div: optfclk_pciephy_div@4a00821c {
compatible = "ti,divider-clock";
clocks = <_pcie_ck>;
-- 
1.7.9.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/


[PATCH v2 13/18] ARM: dts: dra7xx-clocks: Add missing clocks for second PCIe PHY instance

2014-05-29 Thread Kishon Vijay Abraham I
Added missing clocks used by second instance of PCIe PHY.
The documention for this nodes can be found @ ../bindings/clock/ti/gate.txt.

Cc: Rajendra Nayak 
Cc: Tero Kristo 
Cc: Paul Walmsley 
Cc: Tony Lindgren 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Signed-off-by: Keerthy 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi |   24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi 
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 3d8c9c2..a9ff0dc 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1173,6 +1173,14 @@
ti,bit-shift = <8>;
};
 
+   optfclk_pciephy2_32khz: optfclk_pciephy_32khz@4a0093b4 {
+   compatible = "ti,gate-clock";
+   clocks = <_32k_ck>;
+   #clock-cells = <0>;
+   reg = <0x13b4>;
+   ti,bit-shift = <8>;
+   };
+
optfclk_pciephy_div: optfclk_pciephy_div@4a00821c {
compatible = "ti,divider-clock";
clocks = <_pcie_ck>;
@@ -1191,6 +1199,14 @@
ti,bit-shift = <9>;
};
 
+   optfclk_pciephy2_clk: optfclk_pciephy_clk@4a0093b4 {
+   compatible = "ti,gate-clock";
+   clocks = <_pcie_ck>;
+   #clock-cells = <0>;
+   reg = <0x13b4>;
+   ti,bit-shift = <9>;
+   };
+
optfclk_pciephy1_div_clk: optfclk_pciephy_div_clk@4a0093b0 {
compatible = "ti,gate-clock";
clocks = <_pciephy_div>;
@@ -1199,6 +1215,14 @@
ti,bit-shift = <10>;
};
 
+   optfclk_pciephy2_div_clk: optfclk_pciephy_div_clk@4a0093b4 {
+   compatible = "ti,gate-clock";
+   clocks = <_pciephy_div>;
+   #clock-cells = <0>;
+   reg = <0x13b4>;
+   ti,bit-shift = <10>;
+   };
+
apll_pcie_clkvcoldo: apll_pcie_clkvcoldo {
#clock-cells = <0>;
compatible = "fixed-factor-clock";
-- 
1.7.9.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/


[PATCH v2 14/18] ARM: dts: dra7: Add dt data for PCIe PHY

2014-05-29 Thread Kishon Vijay Abraham I
Added dt data for PCIe PHY as a child node of ocp2scp3.
The documention for this node can be found @ ../bindings/phy/ti-phy.txt.

Cc: Tony Lindgren 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |   39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 3c7e7f2..eaeccaf 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -912,6 +912,45 @@
clock-names = "sysclk";
#phy-cells = <0>;
};
+
+   pcie1_phy: pciephy@4a094000 {
+   compatible = "ti,phy-pipe3-pcie";
+   reg = <0x4A094000 0x80>, /* phy_rx */
+ <0x4A094400 0x64>; /* phy_tx */
+   reg-names = "phy_rx", "phy_tx";
+   ctrl-module = <_control_pcie1phy>;
+   clocks = <_pcie_ref_ck>,
+<_pcie_ref_m2ldo_ck>,
+<_pciephy1_32khz>,
+<_pciephy1_clk>,
+<_pciephy1_div_clk>,
+<_pciephy_div>;
+   clock-names = "dpll_ref", "dpll_ref_m2",
+ "wkupclk", "refclk",
+ "div-clk", "phy-div";
+   #phy-cells = <0>;
+   ti,hwmods = "pcie1-phy";
+   };
+
+   pcie2_phy: pciephy@4a095000 {
+   compatible = "ti,phy-pipe3-pcie";
+   reg = <0x4A095000 0x80>, /* phy_rx */
+ <0x4A095400 0x64>; /* phy_tx */
+   reg-names = "phy_rx", "phy_tx";
+   ctrl-module = <_control_pcie1phy>;
+   clocks = <_pcie_ref_ck>,
+<_pcie_ref_m2ldo_ck>,
+<_pciephy2_32khz>,
+<_pciephy2_clk>,
+<_pciephy2_div_clk>,
+<_pciephy_div>;
+   clock-names = "dpll_ref", "dpll_ref_m2",
+ "wkupclk", "refclk",
+ "div-clk", "phy-div";
+   #phy-cells = <0>;
+   ti,hwmods = "pcie2-phy";
+   status = "disabled";
+   };
};
 
omap_dwc3_1@4888 {
-- 
1.7.9.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/


[PATCH v2 12/18] ARM: dts: dra7xx-clocks: rename pcie clocks to accommodate second PHY instance

2014-05-29 Thread Kishon Vijay Abraham I
There are two instances of PCIe PHY in DRA7xx. So renamed
optfclk_pciephy_32khz, optfclk_pciephy_clk and optfclk_pciephy_div_clk to
optfclk_pciephy1_32khz, optfclk_pciephy1_clk and optfclk_pciephy1_div_clk
respectively. This is needed for adding the clocks for second PCIe PHY
instance.

Cc: Rajendra Nayak 
Cc: Tero Kristo 
Cc: Paul Walmsley 
Cc: Tony Lindgren 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Signed-off-by: Keerthy 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi 
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index e1bd052..3d8c9c2 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1165,7 +1165,7 @@
reg = <0x021c>, <0x0220>;
};
 
-   optfclk_pciephy_32khz: optfclk_pciephy_32khz@4a0093b0 {
+   optfclk_pciephy1_32khz: optfclk_pciephy_32khz@4a0093b0 {
compatible = "ti,gate-clock";
clocks = <_32k_ck>;
#clock-cells = <0>;
@@ -1183,7 +1183,7 @@
ti,max-div = <2>;
};
 
-   optfclk_pciephy_clk: optfclk_pciephy_clk@4a0093b0 {
+   optfclk_pciephy1_clk: optfclk_pciephy_clk@4a0093b0 {
compatible = "ti,gate-clock";
clocks = <_pcie_ck>;
#clock-cells = <0>;
@@ -1191,7 +1191,7 @@
ti,bit-shift = <9>;
};
 
-   optfclk_pciephy_div_clk: optfclk_pciephy_div_clk@4a0093b0 {
+   optfclk_pciephy1_div_clk: optfclk_pciephy_div_clk@4a0093b0 {
compatible = "ti,gate-clock";
clocks = <_pciephy_div>;
#clock-cells = <0>;
-- 
1.7.9.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: [RFC PATCH v2 1/1] rename {before/after}_atomic_{inc/dec} to {before/after}_atomic

2014-05-29 Thread Peter Zijlstra
On Thu, May 29, 2014 at 12:28:10AM -0400, Pranith Kumar wrote:
>  There is no reason to have separete barriers for atomic_inc and atomic_dec. 
>  All the architectures use the same barriers for both.
> 
>  We can simplify it and just have {before/after}_atomic after renaming.
> 
>  I used coccinelle script to do the renames in the C files and did the rename 
> by hand in the headers.
> 
> v2: 
> * remove duplicate macros in missed files
> * correct indentation
> 
> Signed-off-by: Pranith Kumar 

See http://marc.info/?l=linux-kernel=139782635207358 and the 20 or so
patches afterwards.

This has already been done. See a -next tree or so near you.
--
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 v2 11/18] ARM: dts: dra7: Add dt data for PCIe PHY control module

2014-05-29 Thread Kishon Vijay Abraham I
Added dt data for PCIe PHY control module used by PCIe PHY.
The documention for this node can be found @ ../bindings/phy/ti-phy.txt

Cc: Tony Lindgren 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |   17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index f0ca46d..3c7e7f2 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -803,6 +803,23 @@
status = "disabled";
};
 
+   omap_control_pcie1phy: omap-control-pciephy@0x4a003c40 {
+   compatible = "ti,control-phy-pcie";
+   reg = <0x4a003c40 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
+   reg-names = "power", "control_sma", "pcie_pcs";
+   clocks = <_clkin1>;
+   clock-names = "sysclk";
+   };
+
+   omap_control_pcie2phy: omap-control-pciephy@0x4a003c44 {
+   compatible = "ti,control-phy-pcie";
+   reg = <0x4a003c44 0x4>, <0x4a003c14 0x4>, <0x4a003c34 
0x4>;
+   reg-names = "power", "control_sma", "pcie_pcs";
+   clocks = <_clkin1>;
+   clock-names = "sysclk";
+   status = "disabled";
+   };
+
omap_control_usb2phy1: control-phy@4a002300 {
compatible = "ti,control-phy-usb2";
reg = <0x4a002300 0x4>;
-- 
1.7.9.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/


[PATCH v2 05/18] PCI: host: pcie-dra7xx: add support for pcie-dra7xx controller

2014-05-29 Thread Kishon Vijay Abraham I
Added support for pcie controller in dra7xx. This driver re-uses
the designware core code that is already present in kernel.

Cc: Jason Gunthorpe 
Cc: Bjorn Helgaas 
Cc: Mohit Kumar 
Cc: Jingoo Han 
Cc: Marek Vasut 
Cc: Arnd Bergmann 
Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/pci/ti-pci.txt |   59 +++
 drivers/pci/host/Kconfig |   10 +
 drivers/pci/host/Makefile|1 +
 drivers/pci/host/pci-dra7xx.c|  460 ++
 4 files changed, 530 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
 create mode 100644 drivers/pci/host/pci-dra7xx.c

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
new file mode 100644
index 000..d07d2eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -0,0 +1,59 @@
+TI PCI Controllers
+
+PCIe Designware Controller
+ - compatible: Should be "ti,dra7-pcie""
+ - reg : Two register ranges as listed in the reg-names property
+ - reg-names : The first entry must be "ti-conf" for the TI specific registers
+  The second entry must be "rc-dbics" for the designware pcie
+  registers
+  The third entry must be "config" for the PCIe configurationspace
+ - phys : list of PHY specifiers (used by generic PHY framework)
+ - phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
+  number of PHYs as specified in *phys* property.
+ - ti,hwmods : Name of the hwmod associated to the pcie, "pcie",
+  where  is the instance number of the pcie from the HW spec.
+ - interrupts : Two interrupt entries must be specified. The first one is for
+   main interrupt line and the second for MSI interrupt line.
+ - #address-cells,
+   #size-cells,
+   #interrupt-cells,
+   device_type,
+   ranges,
+   num-lanes,
+   interrupt-map-mask,
+   interrupt-map : as specified in ../designware-pcie.txt
+
+Example:
+axi {
+   compatible = "simple-bus";
+   #size-cells = <1>;
+   #address-cells = <1>;
+   ranges = <0x5100 0x5100 0x3000
+ 0x00x2000 0x1000>;
+   pcie@5100 {
+   compatible = "ti,dra7-pcie";
+   reg = <0x5100 0x2000>, <0x51002000 0x14c>, <0x1000 0x2000>;
+   reg-names = "rc_dbics", "ti_conf", "config";
+   interrupts = <0 232 0x4>, <0 233 0x4>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   ranges = <0x8100 0 0  0x03000 0 0x0001
+ 0x8200 0 0x20013000 0x13000 0 0xffed000>;
+   #interrupt-cells = <1>;
+   num-lanes = <1>;
+   ti,hwmods = "pcie1";
+   phys = <_phy>;
+   phy-names = "pcie-phy0";
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = <0 0 0 1 _intc 1>,
+   <0 0 0 2 _intc 2>,
+   <0 0 0 3 _intc 3>,
+   <0 0 0 4 _intc 4>;
+   pcie_intc: interrupt-controller {
+   interrupt-controller;
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   };
+   };
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index a6f67ec..58ccb414 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -1,6 +1,16 @@
 menu "PCI host controller drivers"
depends on PCI
 
+config PCI_DRA7XX
+   bool "TI DRA7xx PCIe controller"
+   select PCIE_DW
+   depends on OF && HAS_IOMEM && TI_PIPE3
+   help
+Enables support for the PCIE controller present in DRA7xx SoC. There
+are two instances of PCIE controller in DRA7xx. This controller can
+act both as EP and RC. This reuses the same Designware core as used
+by other SoCs.
+
 config PCI_MVEBU
bool "Marvell EBU PCIe controller"
depends on ARCH_MVEBU || ARCH_DOVE || ARCH_KIRKWOOD
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 13fb333..5216f55 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_PCIE_DW) += pcie-designware.o
+obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
 obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
 obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
 obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
new file mode 100644
index 000..8fb3a2e
--- /dev/null
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -0,0 +1,460 @@
+/*
+ * pcie-dra7xx - PCIe controller driver for TI DRA7xx SoCs
+ *
+ * Copyright (C) 2013-2014 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * Authors: Kishon Vijay Abraham I 
+ *
+ * This program is free software; you can 

Re: [RFC PATCH] crypto: crc32c-pclmul - Use pmovzxdq to shrink K_table

2014-05-29 Thread Jan Beulich
>>> "George Spelvin"  05/28/14 11:47 PM >>>
>Jan Beulich  wrote:
>> "George Spelvin"  05/28/14 4:40 PM
>>> Jan: Is support for SLE10's pre-2.18 binutils still required?
>>> Your PEXTRD fix was only a year ago, so I expect, but I wanted to ask.
>
>> I'd much appreciate if I would be able to build the kernel that way for
>> another while.
>
>Does it matter that the code I'm working on is 64-bit only?

No.

>It aready
>uses crc32q instruction (added with SSE4.2) with no assembler workarounds,
>so I figure pmovzxdq (part of SSE 4.1) doesn't make it any worse.

If that's the case, then adding another (earlier) one shouldn't be an issue.

Jan

--
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 v2 07/18] ARM: dts: DRA7: Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck

2014-05-29 Thread Kishon Vijay Abraham I
From: Keerthy 

Change the parent of apll_pcie_in_clk_mux to dpll_pcie_ref_m2ldo_ck
from dpll_pcie_ref_ck.

Cc: Rajendra Nayak 
Cc: Tero Kristo 
Cc: Paul Walmsley 
Signed-off-by: Keerthy 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi 
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 55e95c5..44993ec 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1152,7 +1152,7 @@
 
apll_pcie_in_clk_mux: apll_pcie_in_clk_mux@4ae06118 {
compatible = "ti,mux-clock";
-   clocks = <_pcie_ref_ck>, <_acs_clk_ck>;
+   clocks = <_pcie_ref_m2ldo_ck>, <_acs_clk_ck>;
#clock-cells = <0>;
reg = <0x021c 0x4>;
ti,bit-shift = <7>;
-- 
1.7.9.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/


[PATCH v2 08/18] arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy

2014-05-29 Thread Kishon Vijay Abraham I
Added hwmod data for pcie1 and pcie2 phy present in DRA7xx SOC.
Also added the missing CLKCTRL OFFSET macro and CONTEXT OFFSET macro
for pcie1 phy and pcie2 phy.

Cc: Tony Lindgren 
Cc: Russell King 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/mach-omap2/cm2_7xx.h |4 ++
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |   57 +
 arch/arm/mach-omap2/prm7xx.h  |4 ++
 3 files changed, 65 insertions(+)

diff --git a/arch/arm/mach-omap2/cm2_7xx.h b/arch/arm/mach-omap2/cm2_7xx.h
index 9ad7594..e966e3a 100644
--- a/arch/arm/mach-omap2/cm2_7xx.h
+++ b/arch/arm/mach-omap2/cm2_7xx.h
@@ -357,6 +357,10 @@
 #define DRA7XX_CM_L3INIT_SATA_CLKCTRL  
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x0088)
 #define DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET0x00a0
 #define DRA7XX_CM_PCIE_STATICDEP_OFFSET0x00a4
+#define DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET0x00b0
+#define DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL   
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00b0)
+#define DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL_OFFSET0x00b8
+#define DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL   
DRA7XX_CM_CORE_REGADDR(DRA7XX_CM_CORE_L3INIT_INST, 0x00b8)
 #define DRA7XX_CM_GMAC_CLKSTCTRL_OFFSET0x00c0
 #define DRA7XX_CM_GMAC_STATICDEP_OFFSET0x00c4
 #define DRA7XX_CM_GMAC_DYNAMICDEP_OFFSET   0x00c8
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index b9bb476..1282a42 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1231,6 +1231,45 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
 };
 
 /*
+ * 'PCIE PHY' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_phy_hwmod_class = {
+   .name   = "pcie-phy",
+};
+
+/* pcie1 phy */
+static struct omap_hwmod dra7xx_pcie1_phy_hwmod = {
+   .name   = "pcie1-phy",
+   .class  = _pcie_phy_hwmod_class,
+   .clkdm_name = "l3init_clkdm",
+   .main_clk   = "l4_root_clk_div",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L3INIT_PCIESS1_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/* pcie2 phy */
+static struct omap_hwmod dra7xx_pcie2_phy_hwmod = {
+   .name   = "pcie2-phy",
+   .class  = _pcie_phy_hwmod_class,
+   .clkdm_name = "l3init_clkdm",
+   .main_clk   = "l4_root_clk_div",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_L3INIT_PCIESS2_CLKCTRL_OFFSET,
+   .context_offs = DRA7XX_RM_L3INIT_PCIESS2_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/*
  * 'qspi' class
  *
  */
@@ -2349,6 +2388,22 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1 
= {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_cfg -> pcie1 phy */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
+   .master = _l4_cfg_hwmod,
+   .slave  = _pcie1_phy_hwmod,
+   .clk= "l4_root_clk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> pcie2 phy */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2_phy = {
+   .master = _l4_cfg_hwmod,
+   .slave  = _pcie2_phy_hwmod,
+   .clk= "l4_root_clk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_addr_space dra7xx_qspi_addrs[] = {
{
.pa_start   = 0x4b30,
@@ -2696,6 +2751,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
_l4_cfg__mpu,
_l4_cfg__ocp2scp1,
_l4_cfg__ocp2scp3,
+   _l4_cfg__pcie1_phy,
+   _l4_cfg__pcie2_phy,
_l3_main_1__qspi,
_l4_cfg__sata,
_l4_cfg__smartreflex_core,
diff --git a/arch/arm/mach-omap2/prm7xx.h b/arch/arm/mach-omap2/prm7xx.h
index d92a840..4bb50fbf 100644
--- a/arch/arm/mach-omap2/prm7xx.h
+++ b/arch/arm/mach-omap2/prm7xx.h
@@ -374,6 +374,10 @@
 #define DRA7XX_RM_L3INIT_IEEE1500_2_OCP_CONTEXT_OFFSET 0x007c
 #define DRA7XX_PM_L3INIT_SATA_WKDEP_OFFSET 0x0088
 #define DRA7XX_RM_L3INIT_SATA_CONTEXT_OFFSET   0x008c
+#define DRA7XX_PM_L3INIT_PCIESS1_WKDEP_OFFSET  0x00b0
+#define DRA7XX_RM_L3INIT_PCIESS1_CONTEXT_OFFSET0x00b4
+#define DRA7XX_PM_L3INIT_PCIESS2_WKDEP_OFFSET  0x00b8
+#define DRA7XX_RM_L3INIT_PCIESS2_CONTEXT_OFFSET0x00bc
 #define 

[PATCH v2 09/18] arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems

2014-05-29 Thread Kishon Vijay Abraham I
Added hwmod data for pcie1 and pcie2 subsystem present in DRA7xx SOC.

Cc: Tony Lindgren 
Cc: Russell King 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |   55 +
 1 file changed, 55 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 1282a42..a51fa7f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1231,6 +1231,43 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
 };
 
 /*
+ * 'PCIE' class
+ *
+ */
+
+static struct omap_hwmod_class dra7xx_pcie_hwmod_class = {
+   .name   = "pcie",
+};
+
+/* pcie1 */
+static struct omap_hwmod dra7xx_pcie1_hwmod = {
+   .name   = "pcie1",
+   .class  = _pcie_hwmod_class,
+   .clkdm_name = "l3init_clkdm",
+   .main_clk   = "l4_root_clk_div",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs   = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+   .modulemode = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/* pcie2 */
+static struct omap_hwmod dra7xx_pcie2_hwmod = {
+   .name   = "pcie2",
+   .class  = _pcie_hwmod_class,
+   .clkdm_name = "l3init_clkdm",
+   .main_clk   = "l4_root_clk_div",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/*
  * 'PCIE PHY' class
  *
  */
@@ -2388,6 +2425,22 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1 
= {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_cfg -> pcie1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1 = {
+   .master = _l4_cfg_hwmod,
+   .slave  = _pcie1_hwmod,
+   .clk= "l4_root_clk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* l4_cfg -> pcie2 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2 = {
+   .master = _l4_cfg_hwmod,
+   .slave  = _pcie2_hwmod,
+   .clk= "l4_root_clk_div",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_cfg -> pcie1 phy */
 static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1_phy = {
.master = _l4_cfg_hwmod,
@@ -2751,6 +2804,8 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
_l4_cfg__mpu,
_l4_cfg__ocp2scp1,
_l4_cfg__ocp2scp3,
+   _l4_cfg__pcie1,
+   _l4_cfg__pcie2,
_l4_cfg__pcie1_phy,
_l4_cfg__pcie2_phy,
_l3_main_1__qspi,
-- 
1.7.9.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/


[PATCH v2 06/18] ARM: dts: DRA7: Add divider table to optfclk_pciephy_div clock

2014-05-29 Thread Kishon Vijay Abraham I
From: Keerthy 

Add divider table to optfclk_pciephy_div clock. The Documentation
for divider clock can be found at ../clock/ti/divider.txt

Cc: Rajendra Nayak 
Cc: Tero Kristo 
Cc: Paul Walmsley 
Signed-off-by: Keerthy 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7xx-clocks.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi 
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index c767687..55e95c5 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1170,6 +1170,7 @@
clocks = <_pcie_ck>;
#clock-cells = <0>;
reg = <0x021c>;
+   ti,dividers = <2>, <1>;
ti,bit-shift = <8>;
ti,max-div = <2>;
};
-- 
1.7.9.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/


[PATCH v2 03/18] PCI: designware: Configuration space should be specified in 'reg'

2014-05-29 Thread Kishon Vijay Abraham I
The configuration address space has so far been specified in *ranges*,
however it should be specified in *reg* making it a platform MEM resource.
Hence used 'platform_get_resource_*' API to get configuration address
space in the designware driver.

Cc: Jason Gunthorpe 
Cc: Bjorn Helgaas 
Cc: Mohit Kumar 
Cc: Jingoo Han 
Cc: Marek Vasut 
Cc: Arnd Bergmann 
Signed-off-by: Kishon Vijay Abraham I 
---
 .../devicetree/bindings/pci/designware-pcie.txt|1 +
 drivers/pci/host/pcie-designware.c |   17 +++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt 
b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index d6fae13..8314360 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -6,6 +6,7 @@ Required properties:
as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
 - reg: base addresses and lengths of the pcie controller,
the phy controller, additional register for the phy controller.
+   The configuration address space should also be specified here.
 - interrupts: interrupt values for level interrupt,
pulse interrupt, special interrupt.
 - clocks: from common clock binding: handle to pci clock.
diff --git a/drivers/pci/host/pcie-designware.c 
b/drivers/pci/host/pcie-designware.c
index c4e3732..603b386 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "pcie-designware.h"
@@ -392,11 +393,23 @@ static const struct irq_domain_ops msi_domain_ops = {
 int __init dw_pcie_host_init(struct pcie_port *pp)
 {
struct device_node *np = pp->dev->of_node;
+   struct platform_device *pdev = to_platform_device(pp->dev);
struct of_pci_range range;
struct of_pci_range_parser parser;
+   struct resource *cfg_res;
u32 val;
int i;
 
+   cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
+   if (cfg_res) {
+   pp->config.cfg0_size = resource_size(cfg_res)/2;
+   pp->config.cfg1_size = resource_size(cfg_res)/2;
+   pp->cfg0_base = cfg_res->start;
+   pp->cfg1_base = cfg_res->start + pp->config.cfg0_size;
+   } else {
+   dev_err(pp->dev, "missing *config* reg space\n");
+   }
+
if (of_pci_range_parser_init(, np)) {
dev_err(pp->dev, "missing ranges property\n");
return -EINVAL;
@@ -429,6 +442,8 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
of_pci_range_to_resource(, np, >cfg);
pp->config.cfg0_size = resource_size(>cfg)/2;
pp->config.cfg1_size = resource_size(>cfg)/2;
+   pp->cfg0_base = pp->cfg.start;
+   pp->cfg1_base = pp->cfg.start + pp->config.cfg0_size;
}
}
 
@@ -441,8 +456,6 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
}
}
 
-   pp->cfg0_base = pp->cfg.start;
-   pp->cfg1_base = pp->cfg.start + pp->config.cfg0_size;
pp->mem_base = pp->mem.start;
 
pp->va_cfg0_base = devm_ioremap(pp->dev, pp->cfg0_base,
-- 
1.7.9.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] CMA: use MIGRATE_SYNC in alloc_contig_range()

2014-05-29 Thread Joonsoo Kim
On Thu, May 29, 2014 at 03:35:05PM +0900, Minchan Kim wrote:
> On Thu, May 29, 2014 at 03:25:50PM +0900, Joonsoo Kim wrote:
> > Before commit 'mm, compaction: embed migration mode in compact_control'
> > from David is merged, alloc_contig_range() used sync migration,
> > instead of sync_light migration. This doesn't break anything currently
> > because page isolation doesn't have any difference with sync and
> > sync_light, but it could in the future, so change back as it was.
> > 
> > And pass cc->mode to migrate_pages(), instead of passing MIGRATE_SYNC
> > to migrate_pages().
> > 
> > Signed-off-by: Joonsoo Kim 
> Acked-by: Minchan Kim 

Thanks.

> 
> Hello Joonsoo,
> 
> Please Ccing me if you send patch related to CMA mm part.
> I have reviewed/fixed mm part of CMA for a long time so worth to Cced
> although I always don't have a time to look at it. :)

Okay! This is just small fix going back orignal, so I didn't cc many people
related to CMA mm part. Anyway, I'm sorry.

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 1/3] init/calibrate.c: convert printk(KERN_NOTICE to pr_notice

2014-05-29 Thread Fabian Frederick

Cc: Paul Gortmaker 
Cc: Andrew Morton 
---
 init/calibrate.c | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/init/calibrate.c b/init/calibrate.c
index 520702d..0d747bb 100644
--- a/init/calibrate.c
+++ b/init/calibrate.c
@@ -95,10 +95,8 @@ static unsigned long calibrate_delay_direct(void)
 * >= 12.5% apart, redo calibration.
 */
if (start >= post_end)
-   printk(KERN_NOTICE "calibrate_delay_direct() ignoring "
-   "timer_rate as we had a TSC wrap around"
-   " start=%lu >=post_end=%lu\n",
-   start, post_end);
+   pr_notice("calibrate_delay_direct() ignoring timer_rate 
as we had a TSC wrap around start=%lu >=post_end=%lu\n",
+ start, post_end);
if (start < post_end && pre_start != 0 && pre_end != 0 &&
(timer_rate_max - timer_rate_min) < (timer_rate_max >> 3)) {
good_timer_count++;
@@ -134,15 +132,13 @@ static unsigned long calibrate_delay_direct(void)
good_timer_count = 0;
if ((measured_times[max] - estimate) <
(estimate - measured_times[min])) {
-   printk(KERN_NOTICE "calibrate_delay_direct() dropping "
-   "min bogoMips estimate %d = %lu\n",
-   min, measured_times[min]);
+   pr_notice("calibrate_delay_direct() dropping min 
bogoMips estimate %d = %lu\n",
+ min, measured_times[min]);
measured_times[min] = 0;
min = max;
} else {
-   printk(KERN_NOTICE "calibrate_delay_direct() dropping "
-   "max bogoMips estimate %d = %lu\n",
-   max, measured_times[max]);
+   pr_notice("calibrate_delay_direct() dropping max 
bogoMips estimate %d = %lu\n",
+ max, measured_times[max]);
measured_times[max] = 0;
max = min;
}
@@ -160,9 +156,8 @@ static unsigned long calibrate_delay_direct(void)
 
}
 
-   printk(KERN_NOTICE "calibrate_delay_direct() failed to get a good "
-  "estimate for loops_per_jiffy.\nProbably due to long platform "
-   "interrupts. Consider using \"lpj=\" boot option.\n");
+   pr_notice("calibrate_delay_direct() failed to get a good estimate for 
loops_per_jiffy.\nProbably due to long platform "
+ "interrupts. Consider using \"lpj=\" boot option.\n");
return 0;
 }
 #else
-- 
1.9.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 v4 03/11] drm: sti: add VTAC drivers

2014-05-29 Thread Benjamin Gaignard
Video Traffic Advance Communication Rx and Tx drivers are designed
for inter-die communication.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile   |   3 +-
 drivers/gpu/drm/sti/sti_vtac.c | 211 +
 2 files changed, 213 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/sti/sti_vtac.c

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index 3658a13e..52e2e80 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_DRM_STI) += \
-   sti_vtg.o
+   sti_vtg.o \
+   sti_vtac.o
diff --git a/drivers/gpu/drm/sti/sti_vtac.c b/drivers/gpu/drm/sti/sti_vtac.c
new file mode 100644
index 000..5226a04
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_vtac.c
@@ -0,0 +1,211 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Author: Benjamin Gaignard  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* registers offset */
+#define VTAC_CONFIG 0x00
+#define VTAC_RX_FIFO_CONFIG 0x04
+#define VTAC_FIFO_CONFIG_VAL0x04
+
+#define VTAC_SYS_CFG85210x824
+#define VTAC_SYS_CFG85220x828
+
+/* Number of phyts per pixel */
+#define VTAC_2_5_PPP0x0005
+#define VTAC_3_PPP  0x0006
+#define VTAC_4_PPP  0x0008
+#define VTAC_5_PPP  0x000A
+#define VTAC_6_PPP  0x000C
+#define VTAC_13_PPP 0x001A
+#define VTAC_14_PPP 0x001C
+#define VTAC_15_PPP 0x001E
+#define VTAC_16_PPP 0x0020
+#define VTAC_17_PPP 0x0022
+#define VTAC_18_PPP 0x0024
+
+/* enable bits */
+#define VTAC_ENABLE 0x3003
+
+#define VTAC_TX_PHY_ENABLE_CLK_PHY  BIT(0)
+#define VTAC_TX_PHY_ENABLE_CLK_DLL  BIT(1)
+#define VTAC_TX_PHY_PLL_NOT_OSC_MODEBIT(3)
+#define VTAC_TX_PHY_RST_N_DLL_SWITCHBIT(4)
+#define VTAC_TX_PHY_PROG_N3 BIT(9)
+
+
+/**
+ * VTAC mode structure
+ *
+ * @vid_in_width: Video Data Resolution
+ * @phyts_width: Width of phyt buses(phyt low and phyt high).
+ * @phyts_per_pixel: Number of phyts sent per pixel
+ */
+struct sti_vtac_mode {
+   u32 vid_in_width;
+   u32 phyts_width;
+   u32 phyts_per_pixel;
+};
+
+static const struct sti_vtac_mode vtac_mode_main = {0x2, 0x2, VTAC_5_PPP};
+static const struct sti_vtac_mode vtac_mode_aux = {0x1, 0x0, VTAC_17_PPP};
+
+/**
+ * VTAC structure
+ *
+ * @dev: pointer to device structure
+ * @regs: ioremapped registers for RX and TX devices
+ * @phy_regs: phy registers for TX device
+ * @clk: clock
+ * @mode: main or auxillary configuration mode
+ */
+struct sti_vtac {
+   struct device *dev;
+   void __iomem *regs;
+   void __iomem *phy_regs;
+   struct clk *clk;
+   const struct sti_vtac_mode *mode;
+};
+
+static void sti_vtac_rx_set_config(struct sti_vtac *vtac)
+{
+   u32 config;
+
+   /* Enable VTAC clock */
+   if (clk_prepare_enable(vtac->clk))
+   DRM_ERROR("Failed to prepare/enable vtac_rx clock.\n");
+
+   writel(VTAC_FIFO_CONFIG_VAL, vtac->regs + VTAC_RX_FIFO_CONFIG);
+
+   config = VTAC_ENABLE;
+   config |= vtac->mode->vid_in_width << 4;
+   config |= vtac->mode->phyts_width << 16;
+   config |= vtac->mode->phyts_per_pixel << 23;
+   writel(config, vtac->regs + VTAC_CONFIG);
+}
+
+static void sti_vtac_tx_set_config(struct sti_vtac *vtac)
+{
+   u32 phy_config;
+   u32 config;
+
+   /* Enable VTAC clock */
+   if (clk_prepare_enable(vtac->clk))
+   DRM_ERROR("Failed to prepare/enable vtac_tx clock.\n");
+
+   /* Configure vtac phy */
+   phy_config = 0x;
+   writel(phy_config, vtac->phy_regs + VTAC_SYS_CFG8522);
+   phy_config = VTAC_TX_PHY_ENABLE_CLK_PHY;
+   writel(phy_config, vtac->phy_regs + VTAC_SYS_CFG8521);
+   phy_config = readl(vtac->phy_regs + VTAC_SYS_CFG8521);
+   phy_config |= VTAC_TX_PHY_PROG_N3;
+   writel(phy_config, vtac->phy_regs + VTAC_SYS_CFG8521);
+   phy_config = readl(vtac->phy_regs + VTAC_SYS_CFG8521);
+   phy_config |= VTAC_TX_PHY_ENABLE_CLK_DLL;
+   writel(phy_config, vtac->phy_regs + VTAC_SYS_CFG8521);
+   phy_config = readl(vtac->phy_regs + VTAC_SYS_CFG8521);
+   phy_config |= VTAC_TX_PHY_RST_N_DLL_SWITCH;
+   writel(phy_config, vtac->phy_regs + VTAC_SYS_CFG8521);
+   phy_config = readl(vtac->phy_regs + VTAC_SYS_CFG8521);
+   phy_config |= VTAC_TX_PHY_PLL_NOT_OSC_MODE;
+   writel(phy_config, vtac->phy_regs + VTAC_SYS_CFG8521);
+
+   /* Configure vtac tx */
+   config = VTAC_ENABLE;
+   config |= vtac->mode->vid_in_width << 4;
+   config |= vtac->mode->phyts_width << 16;
+   config |= 

Re: [RFC][PATCH 0/8] sched,idle: need resched polling rework

2014-05-29 Thread Peter Zijlstra
On Wed, May 28, 2014 at 05:01:41PM -0700, Andy Lutomirski wrote:
> On Thu, May 22, 2014 at 6:09 AM, Peter Zijlstra  wrote:
> > On Thu, May 22, 2014 at 02:58:18PM +0200, Peter Zijlstra wrote:
> >> ---
> >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> >> index 4ea7b3f1a087..a5da85fb3570 100644
> >> --- a/kernel/sched/core.c
> >> +++ b/kernel/sched/core.c
> >> @@ -546,12 +546,38 @@ static bool set_nr_and_not_polling(struct 
> >> task_struct *p)
> >>   struct thread_info *ti = task_thread_info(p);
> >>   return !(fetch_or(>flags, _TIF_NEED_RESCHED) & 
> >> _TIF_POLLING_NRFLAG);
> >>  }
> >> +
> >> +/*
> >> + * Atomically set TIF_NEED_RESCHED if TIF_POLLING_NRFLAG is set.
> >> + */
> >> +static bool set_nr_if_polling(struct task_struct *p)
> >> +{
> >> + struct thread_info *ti = task_thread_info(p);
> >> + typeof(ti->flags) old, val = ti->flags;
> >> +
> >> + for (;;) {
> >> + if (!(val & _TIF_POLLING_NRFLAG))
> >> + return false;
> >> + if (val & _TIF_NEED_RESCHED)
> >> + return true;
> >
> > Hmm, I think this is racy, false would be safer. If its already set we
> > might already be past the sched_ttwu_pending() invocation, while if its
> > clear and we're the one to set it, we're guaranteed not.
> >
> >> + old = cmpxchg(>flags, val, val | _TIF_NEED_RESCHED);
> >> + if (old == val)
> >> + return true;
> >> + val = old;
> >> + }
> >> +}
> 
> Do you have an updated patch?  After fixing the MIME flow damage
> (sigh), it doesn't apply to sched/core, which is my best guess for
> what it's based on.

https://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/commit/?h=sched/core=c224d4fee677ecc72209903d330b643bcf0793d7
--
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/3] init/calibrate.c: use __func__ in logging

2014-05-29 Thread Fabian Frederick
-coalesce formats in all pr_info
-use __func__ in pr_notice and pr_info (Calibrating delay -> calibrate_delay()).

Cc: Paul Gortmaker 
Cc: Andrew Morton 
---
 init/calibrate.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/init/calibrate.c b/init/calibrate.c
index 0d747bb..fb9be44 100644
--- a/init/calibrate.c
+++ b/init/calibrate.c
@@ -95,8 +95,8 @@ static unsigned long calibrate_delay_direct(void)
 * >= 12.5% apart, redo calibration.
 */
if (start >= post_end)
-   pr_notice("calibrate_delay_direct() ignoring timer_rate 
as we had a TSC wrap around start=%lu >=post_end=%lu\n",
- start, post_end);
+   pr_notice("%s() ignoring timer_rate as we had a TSC 
wrap around start=%lu >=post_end=%lu\n",
+ __func__, start, post_end);
if (start < post_end && pre_start != 0 && pre_end != 0 &&
(timer_rate_max - timer_rate_min) < (timer_rate_max >> 3)) {
good_timer_count++;
@@ -132,13 +132,13 @@ static unsigned long calibrate_delay_direct(void)
good_timer_count = 0;
if ((measured_times[max] - estimate) <
(estimate - measured_times[min])) {
-   pr_notice("calibrate_delay_direct() dropping min 
bogoMips estimate %d = %lu\n",
- min, measured_times[min]);
+   pr_notice("%s() dropping min bogoMips estimate %d = 
%lu\n",
+ __func__, min, measured_times[min]);
measured_times[min] = 0;
min = max;
} else {
-   pr_notice("calibrate_delay_direct() dropping max 
bogoMips estimate %d = %lu\n",
- max, measured_times[max]);
+   pr_notice("%s() dropping max bogoMips estimate %d = 
%lu\n",
+ __func__, max, measured_times[max]);
measured_times[max] = 0;
max = min;
}
@@ -156,8 +156,9 @@ static unsigned long calibrate_delay_direct(void)
 
}
 
-   pr_notice("calibrate_delay_direct() failed to get a good estimate for 
loops_per_jiffy.\nProbably due to long platform "
- "interrupts. Consider using \"lpj=\" boot option.\n");
+   pr_notice("%s() failed to get a good estimate for loops_per_jiffy.\n"
+ "Probably due to long platform interrupts. Consider using 
\"lpj=\" boot option.\n",
+ __func__);
return 0;
 }
 #else
@@ -266,26 +267,26 @@ void calibrate_delay(void)
if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
lpj = per_cpu(cpu_loops_per_jiffy, this_cpu);
if (!printed)
-   pr_info("Calibrating delay loop (skipped) "
-   "already calibrated this CPU");
+   pr_info("%s() loop (skipped) already calibrated this 
CPU",
+   __func__);
} else if (preset_lpj) {
lpj = preset_lpj;
if (!printed)
-   pr_info("Calibrating delay loop (skipped) "
-   "preset value.. ");
+   pr_info("%s() loop (skipped) preset value.. ",
+   __func__);
} else if ((!printed) && lpj_fine) {
lpj = lpj_fine;
-   pr_info("Calibrating delay loop (skipped), "
-   "value calculated using timer frequency.. ");
+   pr_info("%s() loop (skipped), value calculated using timer 
frequency.. ",
+   __func__);
} else if ((lpj = calibrate_delay_is_known())) {
;
} else if ((lpj = calibrate_delay_direct()) != 0) {
if (!printed)
-   pr_info("Calibrating delay using timer "
-   "specific routine.. ");
+   pr_info("%s() using timer specific routine.. ",
+   __func__);
} else {
if (!printed)
-   pr_info("Calibrating delay loop... ");
+   pr_info("%s() loop... ", __func__);
lpj = calibrate_delay_converge();
}
per_cpu(cpu_loops_per_jiffy, this_cpu) = lpj;
-- 
1.9.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 v4 06/11] drm: sti: add TVOut driver

2014-05-29 Thread Benjamin Gaignard
TVout hardware block is responsible to dispatch the data flow coming
from compositor block to any of the output (HDMI or Analog TV).
It control when output are start/stop and configure according the
require flow path.

TVout is the parent of HDMI and HDA drivers and bind them at runtime.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile|   3 +-
 drivers/gpu/drm/sti/sti_tvout.c | 678 
 drivers/gpu/drm/sti/sti_tvout.h |  18 ++
 3 files changed, 698 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/sti/sti_tvout.c
 create mode 100644 drivers/gpu/drm/sti/sti_tvout.h

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index df47171..dcc9568 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -4,4 +4,5 @@ obj-$(CONFIG_DRM_STI) += \
sti_hdmi.o \
sti_hdmi_tx3g0c55phy.o \
sti_hdmi_tx3g4c28phy.o \
-   sti_hda.o
+   sti_hda.o \
+   sti_tvout.o
\ No newline at end of file
diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
new file mode 100644
index 000..d778e35
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_tvout.c
@@ -0,0 +1,678 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Authors: Benjamin Gaignard 
+ *  Vincent Abriou 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "sti_drm_connector.h"
+#include "sti_drm_encoder.h"
+#include "sti_tvout.h"
+
+/* glue registers */
+#define TVO_CSC_MAIN_M0  0x000
+#define TVO_CSC_MAIN_M1  0x004
+#define TVO_CSC_MAIN_M2  0x008
+#define TVO_CSC_MAIN_M3  0x00c
+#define TVO_CSC_MAIN_M4  0x010
+#define TVO_CSC_MAIN_M5  0x014
+#define TVO_CSC_MAIN_M6  0x018
+#define TVO_CSC_MAIN_M7  0x01c
+#define TVO_MAIN_IN_VID_FORMAT   0x030
+#define TVO_CSC_AUX_M0   0x100
+#define TVO_CSC_AUX_M1   0x104
+#define TVO_CSC_AUX_M2   0x108
+#define TVO_CSC_AUX_M3   0x10c
+#define TVO_CSC_AUX_M4   0x110
+#define TVO_CSC_AUX_M5   0x114
+#define TVO_CSC_AUX_M6   0x118
+#define TVO_CSC_AUX_M7   0x11c
+#define TVO_AUX_IN_VID_FORMAT0x130
+#define TVO_VIP_HDF  0x400
+#define TVO_HD_SYNC_SEL  0x418
+#define TVO_HD_DAC_CFG_OFF   0x420
+#define TVO_VIP_HDMI 0x500
+#define TVO_HDMI_FORCE_COLOR_0   0x504
+#define TVO_HDMI_FORCE_COLOR_1   0x508
+#define TVO_HDMI_CLIP_VALUE_B_CB 0x50c
+#define TVO_HDMI_CLIP_VALUE_Y_G  0x510
+#define TVO_HDMI_CLIP_VALUE_R_CR 0x514
+#define TVO_HDMI_SYNC_SEL0x518
+#define TVO_HDMI_DFV_OBS 0x540
+
+#define TVO_IN_FMT_SIGNEDBIT(0)
+#define TVO_SYNC_EXT BIT(4)
+
+#define TVO_VIP_REORDER_R_SHIFT  24
+#define TVO_VIP_REORDER_G_SHIFT  20
+#define TVO_VIP_REORDER_B_SHIFT  16
+#define TVO_VIP_REORDER_MASK 0x3
+#define TVO_VIP_REORDER_Y_G_SEL  0
+#define TVO_VIP_REORDER_CB_B_SEL 1
+#define TVO_VIP_REORDER_CR_R_SEL 2
+
+#define TVO_VIP_CLIP_SHIFT   8
+#define TVO_VIP_CLIP_MASK0x7
+#define TVO_VIP_CLIP_DISABLED0
+#define TVO_VIP_CLIP_EAV_SAV 1
+#define TVO_VIP_CLIP_LIMITED_RANGE_RGB_Y 2
+#define TVO_VIP_CLIP_LIMITED_RANGE_CB_CR 3
+#define TVO_VIP_CLIP_PROG_RANGE  4
+
+#define TVO_VIP_RND_SHIFT4
+#define TVO_VIP_RND_MASK 0x3
+#define TVO_VIP_RND_8BIT_ROUNDED 0
+#define TVO_VIP_RND_10BIT_ROUNDED1
+#define TVO_VIP_RND_12BIT_ROUNDED2
+
+#define TVO_VIP_SEL_INPUT_MASK   0xf
+#define TVO_VIP_SEL_INPUT_MAIN   0x0
+#define TVO_VIP_SEL_INPUT_AUX0x8
+#define TVO_VIP_SEL_INPUT_FORCE_COLOR0xf
+#define TVO_VIP_SEL_INPUT_BYPASS_MASK0x1
+#define TVO_VIP_SEL_INPUT_BYPASSED   1
+
+#define TVO_SYNC_MAIN_VTG_SET_REF0x00
+#define TVO_SYNC_MAIN_VTG_SET_1  0x01
+#define TVO_SYNC_MAIN_VTG_SET_2  0x02
+#define TVO_SYNC_MAIN_VTG_SET_3  0x03
+#define TVO_SYNC_MAIN_VTG_SET_4  0x04
+#define TVO_SYNC_MAIN_VTG_SET_5  0x05
+#define TVO_SYNC_MAIN_VTG_SET_6  0x06
+#define TVO_SYNC_AUX_VTG_SET_REF 0x10
+#define TVO_SYNC_AUX_VTG_SET_1   0x11
+#define TVO_SYNC_AUX_VTG_SET_2   0x12
+#define TVO_SYNC_AUX_VTG_SET_3   0x13
+#define TVO_SYNC_AUX_VTG_SET_4   0x14
+#define TVO_SYNC_AUX_VTG_SET_5   0x15
+#define TVO_SYNC_AUX_VTG_SET_6   0x16
+
+#define TVO_SYNC_HD_DCS_SHIFT8
+
+/* enum listing the 

[PATCH v2 01/18] phy: phy-omap-pipe3: Add support for PCIe PHY

2014-05-29 Thread Kishon Vijay Abraham I
PCIe PHY uses an external pll instead of the internal pll used by SATA
and USB3. So added support in pipe3 PHY to use external pll.

Signed-off-by: Kishon Vijay Abraham I 
Reviewed-by: Roger Quadros 
---
 Documentation/devicetree/bindings/phy/ti-phy.txt |8 +-
 drivers/phy/phy-ti-pipe3.c   |   99 +-
 2 files changed, 84 insertions(+), 23 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 9ce458f..cf3de7e 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -56,8 +56,8 @@ usb2phy@4a0ad080 {
 TI PIPE3 PHY
 
 Required properties:
- - compatible: Should be "ti,phy-usb3" or "ti,phy-pipe3-sata".
-   "ti,omap-usb3" is deprecated.
+ - compatible: Should be "ti,phy-usb3", "ti,phy-pipe3-sata" or
+   "ti,phy-pipe3-pcie. "ti,omap-usb3" is deprecated.
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the 
registers
filled in "reg".
@@ -69,6 +69,10 @@ Required properties:
* "wkupclk" - wakeup clock.
* "sysclk" - system clock.
* "refclk" - reference clock.
+   * "dpll_ref" - external dpll ref clk
+   * "dpll_ref_m2" - external dpll ref clk
+   * "phy-div" - divider for apll
+   * "div-clk" - apll clock
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
diff --git a/drivers/phy/phy-ti-pipe3.c b/drivers/phy/phy-ti-pipe3.c
index 5913676..d43019d 100644
--- a/drivers/phy/phy-ti-pipe3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -80,6 +80,7 @@ struct ti_pipe3 {
struct clk  *wkupclk;
struct clk  *sys_clk;
struct clk  *refclk;
+   struct clk  *div_clk;
struct pipe3_dpll_map   *dpll_map;
 };
 
@@ -215,6 +216,9 @@ static int ti_pipe3_init(struct phy *x)
u32 val;
int ret = 0;
 
+   if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie"))
+   return 0;
+
/* Bring it out of IDLE if it is IDLE */
val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_CONFIGURATION2);
if (val & PLL_IDLE) {
@@ -238,8 +242,11 @@ static int ti_pipe3_exit(struct phy *x)
u32 val;
unsigned long timeout;
 
-   /* SATA DPLL can't be powered down due to Errata i783 */
-   if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-sata"))
+   /* SATA DPLL can't be powered down due to Errata i783 and PCIe
+* does not have internal DPLL
+*/
+   if (of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-sata") ||
+   of_device_is_compatible(phy->dev->of_node, "ti,phy-pipe3-pcie"))
return 0;
 
/* Put DPLL in IDLE mode */
@@ -286,32 +293,41 @@ static int ti_pipe3_probe(struct platform_device *pdev)
struct device_node *control_node;
struct platform_device *control_pdev;
const struct of_device_id *match;
-
-   match = of_match_device(of_match_ptr(ti_pipe3_id_table), >dev);
-   if (!match)
-   return -EINVAL;
+   struct clk *clk;
 
phy = devm_kzalloc(>dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
dev_err(>dev, "unable to alloc mem for TI PIPE3 PHY\n");
return -ENOMEM;
}
+   phy->dev= >dev;
 
-   phy->dpll_map = (struct pipe3_dpll_map *)match->data;
-   if (!phy->dpll_map) {
-   dev_err(>dev, "no DPLL data\n");
-   return -EINVAL;
-   }
+   if (!of_device_is_compatible(node, "ti,phy-pipe3-pcie")) {
+   match = of_match_device(of_match_ptr(ti_pipe3_id_table),
+   >dev);
+   if (!match)
+   return -EINVAL;
 
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pll_ctrl");
-   phy->pll_ctrl_base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(phy->pll_ctrl_base))
-   return PTR_ERR(phy->pll_ctrl_base);
+   phy->dpll_map = (struct pipe3_dpll_map *)match->data;
+   if (!phy->dpll_map) {
+   dev_err(>dev, "no DPLL data\n");
+   return -EINVAL;
+   }
 
-   phy->dev= >dev;
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  "pll_ctrl");
+   phy->pll_ctrl_base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(phy->pll_ctrl_base))
+   return PTR_ERR(phy->pll_ctrl_base);
 
-   if (!of_device_is_compatible(node, "ti,phy-pipe3-sata")) {
+   phy->sys_clk = devm_clk_get(phy->dev, "sysclk");
+   if (IS_ERR(phy->sys_clk)) {
+   dev_err(>dev, "unable to get sysclk\n");
+   return 

[PATCH v4 01/11] drm: sti: add bindings for DRM driver

2014-05-29 Thread Benjamin Gaignard
Add DRM/KMS driver bindings documentation.
Describe the required properties for each of the hardware IPs drivers.

Signed-off-by: Benjamin Gaignard 
---
 .../devicetree/bindings/gpu/st,stih4xx.txt | 189 +
 1 file changed, 189 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpu/st,stih4xx.txt

diff --git a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt 
b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
new file mode 100644
index 000..59a59a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt
@@ -0,0 +1,189 @@
+STMicroelectronics stih4xx platforms
+
+- sti-vtg: video timing generator
+  Required properties:
+  - compatible: "st,vtg"
+  - reg: Physical base address of the IP registers and length of memory mapped 
region.
+  Optional properties:
+  - interrupts : VTG interrupt number to the CPU.
+  - st,slave: phandle on a slave vtg
+
+- sti-vtac: video timing advanced inter dye communication Rx and TX
+  Required properties:
+  - compatible: "st,vtac-main" or "st,vtac-aux"
+  - reg: Physical base address of the IP registers and length of memory mapped 
region.
+  - clocks: from common clock binding: handle hardware IP needed clocks, the
+number of clocks may depend of the SoC type.
+See ../clocks/clock-bindings.txt for details.
+  - clock-names: names of the clocks listed in clocks property in the same
+order.
+
+- sti-display-subsystem: Master device for DRM sub-components
+  This device must be the parent of all the sub-components and is responsible
+  of bind them.
+  Required properties:
+  - compatible: "st,sti-display-subsystem"
+  - ranges: to allow probing of subdevices
+
+- sti-compositor: frame compositor engine
+  must be a child of sti-display-subsystem
+  Required properties:
+  - compatible: "st,stih-compositor"
+  - reg: Physical base address of the IP registers and length of memory mapped 
region.
+  - clocks: from common clock binding: handle hardware IP needed clocks, the
+number of clocks may depend of the SoC type.
+See ../clocks/clock-bindings.txt for details.
+  - clock-names: names of the clocks listed in clocks property in the same
+order.
+  - resets: resets to be used by the device
+See ../reset/reset.txt for details.
+  - reset-names: names of the resets listed in resets property in the same
+order.
+  - st,vtg: phandle(s) on vtg device (main and aux) nodes.
+
+- sti-tvout: video out hardware block
+  must be a child of sti-display-subsystem
+  Required properties:
+  - compatible: "st,stih-tvout"
+  - reg: Physical base address of the IP registers and length of memory mapped 
region.
+  - reg-names: names of the mapped memory regions listed in regs property in
+the same order.
+  - resets: resets to be used by the device
+See ../reset/reset.txt for details.
+  - reset-names: names of the resets listed in resets property in the same
+order.
+  - ranges: to allow probing of subdevices
+
+- sti-hdmi: hdmi output block
+  must be a child of sti-tvout
+  Required properties:
+  - compatible: "st,stih-hdmi";
+  - reg: Physical base address of the IP registers and length of memory mapped 
region.
+  - reg-names: names of the mapped memory regions listed in regs property in
+the same order.
+  - interrupts : HDMI interrupt number to the CPU.
+  - interrupt-names: name of the interrupts listed in interrupts property in
+the same order
+  - clocks: from common clock binding: handle hardware IP needed clocks, the
+number of clocks may depend of the SoC type.
+  - clock-names: names of the clocks listed in clocks property in the same
+order.
+  - hdmi,hpd-gpio: gpio id to detect if an hdmi cable is plugged or not.
+
+sti-hda:
+  Required properties:
+  must be a child of sti-tvout
+  - compatible: "st,stih-hda"
+  - reg: Physical base address of the IP registers and length of memory mapped 
region.
+  - reg-names: names of the mapped memory regions listed in regs property in
+the same order.
+  - clocks: from common clock binding: handle hardware IP needed clocks, the
+number of clocks may depend of the SoC type.
+See ../clocks/clock-bindings.txt for details.
+  - clock-names: names of the clocks listed in clocks property in the same
+order.
+
+Example:
+
+/ {
+   ...
+
+   vtg_main_slave: sti-vtg-main-slave@fe85A800 {
+   compatible  = "st,vtg";
+   reg = <0xfe85A800 0x300>;
+   interrupts  = ;
+   };
+
+   vtg_main: sti-vtg-main-master@fd348000 {
+   compatible  = "st,vtg";
+   reg = <0xfd348000 0x400>;
+   st,slave= <_main_slave>;
+   };
+
+   vtg_aux_slave: sti-vtg-aux-slave@fd348400 {
+   compatible  = "st,vtg";
+   reg = <0xfe858200 0x300>;
+   interrupts  = ;
+   };
+
+   vtg_aux: sti-vtg-aux-master@fd348400 {
+   

[PATCH v4 05/11] drm: sti: add HDA driver

2014-05-29 Thread Benjamin Gaignard
Add driver to support analog TV ouput.

As HDMI driver HDA use sti_connector structure to provide
helper functions.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Makefile  |   3 +-
 drivers/gpu/drm/sti/sti_hda.c | 723 ++
 2 files changed, 725 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/sti/sti_hda.c

diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
index 5521a85..df47171 100644
--- a/drivers/gpu/drm/sti/Makefile
+++ b/drivers/gpu/drm/sti/Makefile
@@ -3,4 +3,5 @@ obj-$(CONFIG_DRM_STI) += \
sti_vtac.o \
sti_hdmi.o \
sti_hdmi_tx3g0c55phy.o \
-   sti_hdmi_tx3g4c28phy.o
\ No newline at end of file
+   sti_hdmi_tx3g4c28phy.o \
+   sti_hda.o
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
new file mode 100644
index 000..9a6278d
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -0,0 +1,723 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Author: Fabien Dessenne  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "sti_drm_connector.h"
+#include "sti_drm_encoder.h"
+
+/* HDformatter registers */
+#define HDA_ANA_CFG 0x
+#define HDA_ANA_SCALE_CTRL_Y0x0004
+#define HDA_ANA_SCALE_CTRL_CB   0x0008
+#define HDA_ANA_SCALE_CTRL_CR   0x000C
+#define HDA_ANA_ANC_CTRL0x0010
+#define HDA_ANA_SRC_Y_CFG   0x0014
+#define HDA_COEFF_Y_PH1_TAP123  0x0018
+#define HDA_COEFF_Y_PH1_TAP456  0x001C
+#define HDA_COEFF_Y_PH2_TAP123  0x0020
+#define HDA_COEFF_Y_PH2_TAP456  0x0024
+#define HDA_COEFF_Y_PH3_TAP123  0x0028
+#define HDA_COEFF_Y_PH3_TAP456  0x002C
+#define HDA_COEFF_Y_PH4_TAP123  0x0030
+#define HDA_COEFF_Y_PH4_TAP456  0x0034
+#define HDA_ANA_SRC_C_CFG   0x0040
+#define HDA_COEFF_C_PH1_TAP123  0x0044
+#define HDA_COEFF_C_PH1_TAP456  0x0048
+#define HDA_COEFF_C_PH2_TAP123  0x004C
+#define HDA_COEFF_C_PH2_TAP456  0x0050
+#define HDA_COEFF_C_PH3_TAP123  0x0054
+#define HDA_COEFF_C_PH3_TAP456  0x0058
+#define HDA_COEFF_C_PH4_TAP123  0x005C
+#define HDA_COEFF_C_PH4_TAP456  0x0060
+#define HDA_SYNC_AWGI   0x0300
+
+/* HDA_ANA_CFG */
+#define CFG_AWG_ASYNC_ENBIT(0)
+#define CFG_AWG_ASYNC_HSYNC_MTD BIT(1)
+#define CFG_AWG_ASYNC_VSYNC_MTD BIT(2)
+#define CFG_AWG_SYNC_DELBIT(3)
+#define CFG_AWG_FLTR_MODE_SHIFT 4
+#define CFG_AWG_FLTR_MODE_MASK  (0xF << CFG_AWG_FLTR_MODE_SHIFT)
+#define CFG_AWG_FLTR_MODE_SD(0 << CFG_AWG_FLTR_MODE_SHIFT)
+#define CFG_AWG_FLTR_MODE_ED(1 << CFG_AWG_FLTR_MODE_SHIFT)
+#define CFG_AWG_FLTR_MODE_HD(2 << CFG_AWG_FLTR_MODE_SHIFT)
+#define CFG_SYNC_ON_PBPR_MASK   BIT(8)
+#define CFG_PREFILTER_EN_MASK   BIT(9)
+#define CFG_PBPR_SYNC_OFF_SHIFT 16
+#define CFG_PBPR_SYNC_OFF_MASK  (0x7FF << CFG_PBPR_SYNC_OFF_SHIFT)
+#define CFG_PBPR_SYNC_OFF_VAL   0x117 /* Voltage dependent. stiH416 */
+
+/* Default scaling values */
+#define SCALE_CTRL_Y_DFLT   0x00C50256
+#define SCALE_CTRL_CB_DFLT  0x00DB0249
+#define SCALE_CTRL_CR_DFLT  0x00DB0249
+
+/* Video DACs control */
+#define VIDEO_DACS_CONTROL_MASK 0x0FFF
+#define VIDEO_DACS_CONTROL_SYSCFG2535   0x085C /* for stih416 */
+#define DAC_CFG_HD_OFF_SHIFT5
+#define DAC_CFG_HD_OFF_MASK (0x7 << DAC_CFG_HD_OFF_SHIFT)
+#define VIDEO_DACS_CONTROL_SYSCFG5072   0x0120 /* for stih407 */
+#define DAC_CFG_HD_HZUVW_OFF_MASK   BIT(1)
+
+
+/* Upsampler values for the alternative 2X Filter */
+#define SAMPLER_COEF_NB 8
+#define HDA_ANA_SRC_Y_CFG_ALT_2X0x0113
+static u32 coef_y_alt_2x[] = {
+   0x00FE83FB, 0x1F900401, 0x, 0x,
+   0x00F408F9, 0x055F7C25, 0x, 0x
+};
+
+#define HDA_ANA_SRC_C_CFG_ALT_2X0x01750004
+static u32 coef_c_alt_2x[] = {
+   0x001305F7, 0x05274BD0, 0x, 0x,
+   0x0004907C, 0x09C80B9D, 0x, 0x
+};
+
+/* Upsampler values for the 4X Filter */
+#define HDA_ANA_SRC_Y_CFG_4X0x01ED0005
+#define HDA_ANA_SRC_C_CFG_4X0x01ED0004
+static u32 coef_yc_4x[] = {
+   0x00FC827F, 0x008FE20B, 0x00F684FC, 0x050F7C24,
+   0x00F4857C, 0x0A1F402E, 0x00FA027F, 0x0E076E1D
+};
+
+/* AWG instructions for some video modes */
+#define AWG_MAX_INST64
+
+/* 720p@50 */
+static u32 AWGi_720p_50[] = {
+   0x0971, 0x0C26, 0x013B, 0x0CDA,
+   0x0104, 0x0E7E, 0x0E7F, 0x013B,
+   0x0D8E, 0x0104, 0x1804, 0x0971,
+   0x0C26, 0x003B, 0x0FB4, 0x0FB5,

Re: [RFC] Implement Batched (group) ticket lock

2014-05-29 Thread Peter Zijlstra
On Wed, May 28, 2014 at 05:46:39PM +0530, Raghavendra K T wrote:
> In virtualized environment there are mainly three problems
> related to spinlocks that affect performance.
> 1. LHP (lock holder preemption)
> 2. Lock Waiter Preemption (LWP)
> 3. Starvation/fairness
> 
>  Though ticketlocks solve the fairness problem, it worsens LWP, LHP problems.
> pv-ticketlocks tried to address this. But we can further improve at the
> cost of relaxed fairness.

So I really hate the idea of having different locks for paravirt and
normal kernels.

And we're looking to move to that queued lock for normal kernels.
--
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 3/3] init/calibrate.c: no prefix in logging

2014-05-29 Thread Fabian Frederick
define pr_fmt without prefix to avoid any default prefix update

Cc: Paul Gortmaker 
Cc: Andrew Morton 
---
 init/calibrate.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/init/calibrate.c b/init/calibrate.c
index fb9be44..169e98d 100644
--- a/init/calibrate.c
+++ b/init/calibrate.c
@@ -4,6 +4,8 @@
  *  Copyright (C) 1991, 1992  Linus Torvalds
  */
 
+#define pr_fmt(fmt) fmt
+
 #include 
 #include 
 #include 
-- 
1.9.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 v4 02/11] drm: sti: add VTG driver

2014-05-29 Thread Benjamin Gaignard
Video Time Generator drivers are used to synchronize the compositor
and tvout hardware IPs by providing line count, sample count,
synchronization signals (HSYNC, VSYNC) and top and bottom fields
indication.
VTG are used by pair for each data path (main or auxiliary)
one for master and one for slave.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/sti/Kconfig   |   5 +
 drivers/gpu/drm/sti/Makefile  |   2 +
 drivers/gpu/drm/sti/sti_vtg.c | 356 ++
 drivers/gpu/drm/sti/sti_vtg.h |  28 
 6 files changed, 394 insertions(+)
 create mode 100644 drivers/gpu/drm/sti/Kconfig
 create mode 100644 drivers/gpu/drm/sti/Makefile
 create mode 100644 drivers/gpu/drm/sti/sti_vtg.c
 create mode 100644 drivers/gpu/drm/sti/sti_vtg.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index d1cc2f6..0e30029 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -201,3 +201,5 @@ source "drivers/gpu/drm/tegra/Kconfig"
 source "drivers/gpu/drm/panel/Kconfig"
 
 source "drivers/gpu/drm/bridge/Kconfig"
+
+source "drivers/gpu/drm/sti/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 5e792b0..44f7b17 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_BOCHS) += bochs/
 obj-$(CONFIG_DRM_MSM) += msm/
 obj-$(CONFIG_DRM_TEGRA) += tegra/
+obj-$(CONFIG_DRM_STI) += sti/
 obj-y  += i2c/
 obj-y  += panel/
 obj-y  += bridge/
diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
new file mode 100644
index 000..cbd664b
--- /dev/null
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -0,0 +1,5 @@
+config DRM_STI
+   bool "DRM Support for STMicroelectronics SoC stiH41x Series"
+   depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM)
+   help
+ Choose this option to enable DRM on STM stiH41x chipset
diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
new file mode 100644
index 000..3658a13e
--- /dev/null
+++ b/drivers/gpu/drm/sti/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_DRM_STI) += \
+   sti_vtg.o
diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
new file mode 100644
index 000..49f95d4
--- /dev/null
+++ b/drivers/gpu/drm/sti/sti_vtg.c
@@ -0,0 +1,356 @@
+/*
+ * Copyright (C) STMicroelectronics SA 2014
+ * Authors: Benjamin Gaignard 
+ *  Fabien Dessenne 
+ *  Vincent Abriou 
+ *  for STMicroelectronics.
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include "sti_vtg.h"
+
+#define VTG_TYPE_MASTER 0
+#define VTG_TYPE_SLAVE_BY_EXT0  1
+
+/* registers offset */
+#define VTG_MODE0x
+#define VTG_CLKLN   0x0008
+#define VTG_HLFLN   0x000C
+#define VTG_DRST_AUTOC  0x0010
+#define VTG_VID_TFO 0x0040
+#define VTG_VID_TFS 0x0044
+#define VTG_VID_BFO 0x0048
+#define VTG_VID_BFS 0x004C
+
+#define VTG_HOST_ITS0x0078
+#define VTG_HOST_ITS_BCLR   0x007C
+#define VTG_HOST_ITM_BCLR   0x0088
+#define VTG_HOST_ITM_BSET   0x008C
+
+#define VTG_H_HD_1  0x00C0
+#define VTG_TOP_V_VD_1  0x00C4
+#define VTG_BOT_V_VD_1  0x00C8
+#define VTG_TOP_V_HD_1  0x00CC
+#define VTG_BOT_V_HD_1  0x00D0
+
+#define VTG_H_HD_2  0x00E0
+#define VTG_TOP_V_VD_2  0x00E4
+#define VTG_BOT_V_VD_2  0x00E8
+#define VTG_TOP_V_HD_2  0x00EC
+#define VTG_BOT_V_HD_2  0x00F0
+
+#define VTG_H_HD_3  0x0100
+#define VTG_TOP_V_VD_3  0x0104
+#define VTG_BOT_V_VD_3  0x0108
+#define VTG_TOP_V_HD_3  0x010C
+#define VTG_BOT_V_HD_3  0x0110
+
+#define VTG_IRQ_BOTTOM  BIT(0)
+#define VTG_IRQ_TOP BIT(1)
+#define VTG_IRQ_MASK(VTG_IRQ_TOP | VTG_IRQ_BOTTOM)
+
+/* delay introduced by the Arbitrary Waveform Generator in nb of pixels */
+#define AWG_DELAY_HD(-9)
+#define AWG_DELAY_ED(-8)
+#define AWG_DELAY_SD(-7)
+
+LIST_HEAD(vtg_lookup);
+
+/**
+ * STI VTG structure
+ *
+ * @dev: pointer to device driver
+ * @data: data associated to the device
+ * @irq: VTG irq
+ * @type: VTG type (main or aux)
+ * @notifier_list: notifier callback
+ * @crtc_id: the crtc id for vblank event
+ * @slave: slave vtg
+ * @link: List node to link the structure in lookup list
+ */
+struct sti_vtg {
+   struct device *dev;
+   struct device_node *np;
+   void __iomem *regs;
+   int irq;
+   u32 irq_status;
+   struct raw_notifier_head notifier_list;
+   int crtc_id;
+   struct sti_vtg *slave;
+   struct list_head link;
+};
+
+static void vtg_register(struct sti_vtg *vtg)
+{
+   list_add_tail(>link, _lookup);
+}
+
+struct sti_vtg *of_vtg_find(struct device_node *np)
+{
+   struct sti_vtg *vtg;
+
+   

Re: [PATCH v2 16/18] ARM: OMAP: Enable PCI for DRA7

2014-05-29 Thread Jingoo Han
On Thursday, May 29, 2014 3:38 PM, Kishon Vijay Abraham I wrote:
> 
> Now that we have added PCIe driver for DRA7 SOCs, enable PCI on
> DRA7 SOCs.
> 
> Cc: Tony Lindgren 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Kumar Gala 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  arch/arm/mach-omap2/Kconfig |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index cb31d43..b179e80 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -75,6 +75,8 @@ config SOC_DRA7XX
>   select ARM_GIC
>   select HAVE_ARM_ARCH_TIMER
>   select IRQ_CROSSBAR
> + select MIGHT_HAVE_PCI
> + select ARCH_SUPPORTS_MSI

Hi Kishon,

Please, don't select ARCH_SUPPORTS_MSI, because this kconfig
option was already removed in v3.12 by the commit ebd97be635
('PCI: remove ARCH_SUPPORTS_MSI kconfig option'). So, there is
NO need to select 'ARCH_SUPPORTS_MSI'.

Best regards,
Jingoo Han

> 
>  config ARCH_OMAP2PLUS
>   bool
> --
> 1.7.9.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/


<    5   6   7   8   9   10   11   12   13   14   >