[PATCH -next] metag: Fix ioremap_wc/ioremap_cached build errors

2015-03-23 Thread James Hogan
When ioremap_wc() or ioremap_cached() are used without first including
asm/pgtable.h, the _PAGE_CACHEABLE or _PAGE_WR_COMBINE definitions
aren't found, resulting in build errors like the following (in
next-20150323 due to "lib: devres: add a helper function for
ioremap_wc"):

lib/devres.c: In function ‘devm_ioremap_wc’:
lib/devres.c:91: error: ‘_PAGE_WR_COMBINE’ undeclared

We can't easily include asm/pgtable.h in asm/io.h due to dependency
problems, so split out the _PAGE_* definitions from asm/pgtable.h into a
separate asm/pgtable-bits.h header (as a couple of other architectures
already do), and include that in io.h instead.

Signed-off-by: James Hogan 
Cc: linux-metag@vger.kernel.org
Cc: Abhilash Kesavan 
Cc: Greg Kroah-Hartman 
---
GregKH: I can apply this patch to the metag tree for 4.0. However commit
34644524bce9 "lib: devres: add a helper function for ioremap_wc" in
your char-misc-next branch in next-20150323 will still break the metag
build until the two changes merge. How do you want to handle that?
---
 arch/metag/include/asm/io.h   |   1 +
 arch/metag/include/asm/pgtable-bits.h | 104 ++
 arch/metag/include/asm/pgtable.h  |  95 +--
 3 files changed, 106 insertions(+), 94 deletions(-)
 create mode 100644 arch/metag/include/asm/pgtable-bits.h

diff --git a/arch/metag/include/asm/io.h b/arch/metag/include/asm/io.h
index 9359e5048442..d5779b0ec573 100644
--- a/arch/metag/include/asm/io.h
+++ b/arch/metag/include/asm/io.h
@@ -2,6 +2,7 @@
 #define _ASM_METAG_IO_H
 
 #include 
+#include 
 
 #define IO_SPACE_LIMIT  0
 
diff --git a/arch/metag/include/asm/pgtable-bits.h 
b/arch/metag/include/asm/pgtable-bits.h
new file mode 100644
index ..25ba6729f496
--- /dev/null
+++ b/arch/metag/include/asm/pgtable-bits.h
@@ -0,0 +1,104 @@
+/*
+ * Meta page table definitions.
+ */
+
+#ifndef _METAG_PGTABLE_BITS_H
+#define _METAG_PGTABLE_BITS_H
+
+#include 
+
+/*
+ * Definitions for MMU descriptors
+ *
+ * These are the hardware bits in the MMCU pte entries.
+ * Derived from the Meta toolkit headers.
+ */
+#define _PAGE_PRESENT  MMCU_ENTRY_VAL_BIT
+#define _PAGE_WRITEMMCU_ENTRY_WR_BIT
+#define _PAGE_PRIV MMCU_ENTRY_PRIV_BIT
+/* Write combine bit - this can cause writes to occur out of order */
+#define _PAGE_WR_COMBINE   MMCU_ENTRY_WRC_BIT
+/* Sys coherent bit - this bit is never used by Linux */
+#define _PAGE_SYS_COHERENT MMCU_ENTRY_SYS_BIT
+#define _PAGE_ALWAYS_ZERO_10x020
+#define _PAGE_CACHE_CTRL0  0x040
+#define _PAGE_CACHE_CTRL1  0x080
+#define _PAGE_ALWAYS_ZERO_20x100
+#define _PAGE_ALWAYS_ZERO_30x200
+#define _PAGE_ALWAYS_ZERO_40x400
+#define _PAGE_ALWAYS_ZERO_50x800
+
+/* These are software bits that we stuff into the gaps in the hardware
+ * pte entries that are not used.  Note, these DO get stored in the actual
+ * hardware, but the hardware just does not use them.
+ */
+#define _PAGE_ACCESSED _PAGE_ALWAYS_ZERO_1
+#define _PAGE_DIRTY_PAGE_ALWAYS_ZERO_2
+
+/* Pages owned, and protected by, the kernel. */
+#define _PAGE_KERNEL   _PAGE_PRIV
+
+/* No cacheing of this page */
+#define _PAGE_CACHE_WIN0   (MMCU_CWIN_UNCACHED << MMCU_ENTRY_CWIN_S)
+/* burst cacheing - good for data streaming */
+#define _PAGE_CACHE_WIN1   (MMCU_CWIN_BURST << MMCU_ENTRY_CWIN_S)
+/* One cache way per thread */
+#define _PAGE_CACHE_WIN2   (MMCU_CWIN_C1SET << MMCU_ENTRY_CWIN_S)
+/* Full on cacheing */
+#define _PAGE_CACHE_WIN3   (MMCU_CWIN_CACHED << MMCU_ENTRY_CWIN_S)
+
+#define _PAGE_CACHEABLE(_PAGE_CACHE_WIN3 | _PAGE_WR_COMBINE)
+
+/* which bits are used for cache control ... */
+#define _PAGE_CACHE_MASK   (_PAGE_CACHE_CTRL0 | _PAGE_CACHE_CTRL1 | \
+_PAGE_WR_COMBINE)
+
+/* This is a mask of the bits that pte_modify is allowed to change. */
+#define _PAGE_CHG_MASK (PAGE_MASK)
+
+#define _PAGE_SZ_SHIFT 1
+#define _PAGE_SZ_4K(0x0)
+#define _PAGE_SZ_8K(0x1 << _PAGE_SZ_SHIFT)
+#define _PAGE_SZ_16K   (0x2 << _PAGE_SZ_SHIFT)
+#define _PAGE_SZ_32K   (0x3 << _PAGE_SZ_SHIFT)
+#define _PAGE_SZ_64K   (0x4 << _PAGE_SZ_SHIFT)
+#define _PAGE_SZ_128K  (0x5 << _PAGE_SZ_SHIFT)
+#define _PAGE_SZ_256K  (0x6 << _PAGE_SZ_SHIFT)
+#define _PAGE_SZ_512K  (0x7 << _PAGE_SZ_SHIFT)
+#define _PAGE_SZ_1M(0x8 << _PAGE_SZ_SHIFT)
+#define _PAGE_SZ_2M(0x9 << _PAGE_SZ_SHIFT)
+#define _PAGE_SZ_4M(0xa << _PAGE_SZ_SHIFT)
+#define _PAGE_SZ_MASK  (0xf << _PAGE_SZ_SHIFT)
+
+#if defined(CONFIG_PAGE_SIZE_4K)
+#define _PAGE_SZ   (_PAGE_SZ_4K)
+#elif defined(CONFIG_PAGE_SIZE_8K)
+#define _PAGE_SZ   (_PAGE_SZ_8K)
+#elif defined(CONFIG_PAGE_SIZE_16K)
+#define _PAGE_SZ   (_PAGE_SZ_16K)
+#endif
+#define _PAGE_TABLE(_PAGE_SZ | _PAGE_PRESENT)
+
+#if defined(CONFIG

Re: [PATCH -next] metag: Fix ioremap_wc/ioremap_cached build errors

2015-03-23 Thread Greg Kroah-Hartman
On Mon, Mar 23, 2015 at 12:26:15PM +, James Hogan wrote:
> When ioremap_wc() or ioremap_cached() are used without first including
> asm/pgtable.h, the _PAGE_CACHEABLE or _PAGE_WR_COMBINE definitions
> aren't found, resulting in build errors like the following (in
> next-20150323 due to "lib: devres: add a helper function for
> ioremap_wc"):
> 
> lib/devres.c: In function ‘devm_ioremap_wc’:
> lib/devres.c:91: error: ‘_PAGE_WR_COMBINE’ undeclared
> 
> We can't easily include asm/pgtable.h in asm/io.h due to dependency
> problems, so split out the _PAGE_* definitions from asm/pgtable.h into a
> separate asm/pgtable-bits.h header (as a couple of other architectures
> already do), and include that in io.h instead.
> 
> Signed-off-by: James Hogan 
> Cc: linux-metag@vger.kernel.org
> Cc: Abhilash Kesavan 
> Cc: Greg Kroah-Hartman 
> ---
> GregKH: I can apply this patch to the metag tree for 4.0. However commit
> 34644524bce9 "lib: devres: add a helper function for ioremap_wc" in
> your char-misc-next branch in next-20150323 will still break the metag
> build until the two changes merge. How do you want to handle that?

I don't know, I can't pull that into 4.0-final as it's not 4.0-final
material.  So there's nothing I can do from my end, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH -next] metag: Fix ioremap_wc/ioremap_cached build errors

2015-03-23 Thread Stephen Rothwell
Hi Greg,

On Mon, 23 Mar 2015 20:54:01 +0100 Greg Kroah-Hartman 
 wrote:
>
> On Mon, Mar 23, 2015 at 12:26:15PM +, James Hogan wrote:
> > When ioremap_wc() or ioremap_cached() are used without first including
> > asm/pgtable.h, the _PAGE_CACHEABLE or _PAGE_WR_COMBINE definitions
> > aren't found, resulting in build errors like the following (in
> > next-20150323 due to "lib: devres: add a helper function for
> > ioremap_wc"):
> > 
> > lib/devres.c: In function ‘devm_ioremap_wc’:
> > lib/devres.c:91: error: ‘_PAGE_WR_COMBINE’ undeclared
> > 
> > We can't easily include asm/pgtable.h in asm/io.h due to dependency
> > problems, so split out the _PAGE_* definitions from asm/pgtable.h into a
> > separate asm/pgtable-bits.h header (as a couple of other architectures
> > already do), and include that in io.h instead.
> > 
> > Signed-off-by: James Hogan 
> > Cc: linux-metag@vger.kernel.org
> > Cc: Abhilash Kesavan 
> > Cc: Greg Kroah-Hartman 
> > ---
> > GregKH: I can apply this patch to the metag tree for 4.0. However commit
> > 34644524bce9 "lib: devres: add a helper function for ioremap_wc" in
> > your char-misc-next branch in next-20150323 will still break the metag
> > build until the two changes merge. How do you want to handle that?
> 
> I don't know, I can't pull that into 4.0-final as it's not 4.0-final
> material.  So there's nothing I can do from my end, sorry.

Am I missing something?  Why can't you just put that commit in your
char-misc-next branch along with the commit that causes the need for
that commit?  If James put it in it's own (non rebasing) branch, you
could even both merge it into your trees ...
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgphPDif_nA5U.pgp
Description: OpenPGP digital signature


Re: [PATCH -next] metag: Fix ioremap_wc/ioremap_cached build errors

2015-03-24 Thread James Hogan
On 23/03/15 21:02, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Mon, 23 Mar 2015 20:54:01 +0100 Greg Kroah-Hartman 
>  wrote:
>>
>> On Mon, Mar 23, 2015 at 12:26:15PM +, James Hogan wrote:
>>> When ioremap_wc() or ioremap_cached() are used without first including
>>> asm/pgtable.h, the _PAGE_CACHEABLE or _PAGE_WR_COMBINE definitions
>>> aren't found, resulting in build errors like the following (in
>>> next-20150323 due to "lib: devres: add a helper function for
>>> ioremap_wc"):
>>>
>>> lib/devres.c: In function ‘devm_ioremap_wc’:
>>> lib/devres.c:91: error: ‘_PAGE_WR_COMBINE’ undeclared
>>>
>>> We can't easily include asm/pgtable.h in asm/io.h due to dependency
>>> problems, so split out the _PAGE_* definitions from asm/pgtable.h into a
>>> separate asm/pgtable-bits.h header (as a couple of other architectures
>>> already do), and include that in io.h instead.
>>>
>>> Signed-off-by: James Hogan 
>>> Cc: linux-metag@vger.kernel.org
>>> Cc: Abhilash Kesavan 
>>> Cc: Greg Kroah-Hartman 
>>> ---
>>> GregKH: I can apply this patch to the metag tree for 4.0. However commit
>>> 34644524bce9 "lib: devres: add a helper function for ioremap_wc" in
>>> your char-misc-next branch in next-20150323 will still break the metag
>>> build until the two changes merge. How do you want to handle that?
>>
>> I don't know, I can't pull that into 4.0-final as it's not 4.0-final
>> material.  So there's nothing I can do from my end, sorry.
> 
> Am I missing something?  Why can't you just put that commit in your
> char-misc-next branch along with the commit that causes the need for
> that commit?  If James put it in it's own (non rebasing) branch, you
> could even both merge it into your trees ...

Greg: I've pushed a fix_ioremap_wc branch to:
git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag.git

based on v4.0-rc3, with just this patch. Feel free to merge it if you're
happy to do so.

Cheers
James



signature.asc
Description: OpenPGP digital signature


Re: [PATCH -next] metag: Fix ioremap_wc/ioremap_cached build errors

2015-03-25 Thread Greg Kroah-Hartman
On Tue, Mar 24, 2015 at 03:16:46PM +, James Hogan wrote:
> On 23/03/15 21:02, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > On Mon, 23 Mar 2015 20:54:01 +0100 Greg Kroah-Hartman 
> >  wrote:
> >>
> >> On Mon, Mar 23, 2015 at 12:26:15PM +, James Hogan wrote:
> >>> When ioremap_wc() or ioremap_cached() are used without first including
> >>> asm/pgtable.h, the _PAGE_CACHEABLE or _PAGE_WR_COMBINE definitions
> >>> aren't found, resulting in build errors like the following (in
> >>> next-20150323 due to "lib: devres: add a helper function for
> >>> ioremap_wc"):
> >>>
> >>> lib/devres.c: In function ‘devm_ioremap_wc’:
> >>> lib/devres.c:91: error: ‘_PAGE_WR_COMBINE’ undeclared
> >>>
> >>> We can't easily include asm/pgtable.h in asm/io.h due to dependency
> >>> problems, so split out the _PAGE_* definitions from asm/pgtable.h into a
> >>> separate asm/pgtable-bits.h header (as a couple of other architectures
> >>> already do), and include that in io.h instead.
> >>>
> >>> Signed-off-by: James Hogan 
> >>> Cc: linux-metag@vger.kernel.org
> >>> Cc: Abhilash Kesavan 
> >>> Cc: Greg Kroah-Hartman 
> >>> ---
> >>> GregKH: I can apply this patch to the metag tree for 4.0. However commit
> >>> 34644524bce9 "lib: devres: add a helper function for ioremap_wc" in
> >>> your char-misc-next branch in next-20150323 will still break the metag
> >>> build until the two changes merge. How do you want to handle that?
> >>
> >> I don't know, I can't pull that into 4.0-final as it's not 4.0-final
> >> material.  So there's nothing I can do from my end, sorry.
> > 
> > Am I missing something?  Why can't you just put that commit in your
> > char-misc-next branch along with the commit that causes the need for
> > that commit?  If James put it in it's own (non rebasing) branch, you
> > could even both merge it into your trees ...
> 
> Greg: I've pushed a fix_ioremap_wc branch to:
> git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag.git
> 
> based on v4.0-rc3, with just this patch. Feel free to merge it if you're
> happy to do so.

I've now done this, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html