Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Thu, Aug 07, 2008 at 07:04:04PM -0500, Kumar Gala wrote: mem_init_done isn't a good indication. We can do page tables when it's 0, we would have to use a separate mem_preinit_done or something :-) I initially also though about a flag to ioremap_prot to be honest. But it does obfuscate the normal ioremap code path and if there's a flag, that means that callers know the difference and thus may as well call a separate function, don't you think ? I'm ok with exposing a separate function as far as the API goes.. I'm not ok with duplicating the logic of __ioremap(). Turns out there is very little actual duplication of code with __ioremap(). The checks for p_mapped_by_* are the same, but all the alignment checks are different because different boundaries are used. I attempted to break things down to a common function, but there is not a lot there. But I will add a function to manage modification of ioremap_bot. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, Aug 06, 2008 at 05:11:08PM -0600, Grant Likely wrote: I do this particular test to make absolute sure that the caller absolutely understands the limitations of the block mapping. If they call this with something that isn't 128k aligned, then I make it fail immediately so the coder is forced to go and understand what they are allowed to do. Basically, I'm reinforcing the fact that this is not the same as ioremap(). I haven't decided yet if I should test size in the same way. Thoughts? I'd prefer it round up the size as needed to cover the requested mapping and needed alignment. The minimum size is going to be different on Book E, for example, and I can think of at least one user that will be shared between Book E and classic (CPM2 early console). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Aug 7, 2008, at 11:45 AM, Scott Wood wrote: On Wed, Aug 06, 2008 at 05:11:08PM -0600, Grant Likely wrote: I do this particular test to make absolute sure that the caller absolutely understands the limitations of the block mapping. If they call this with something that isn't 128k aligned, then I make it fail immediately so the coder is forced to go and understand what they are allowed to do. Basically, I'm reinforcing the fact that this is not the same as ioremap(). I haven't decided yet if I should test size in the same way. Thoughts? I'd prefer it round up the size as needed to cover the requested mapping and needed alignment. The minimum size is going to be different on Book E, for example, and I can think of at least one user that will be shared between Book E and classic (CPM2 early console). Which is how ioremap works today. We ask for a size of 3 bytes and it rounds up to a 4k page. The same should be true of the new interface (and round up to whatever the smallest size the HW we are using can handle). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, 2008-08-06 at 17:11 -0600, Grant Likely wrote: I'm not sure what you're asking. Are you asking about this particular test, or are you asking why I don't also test the size? Badly worded. I meant BAT sizes are masks of bits. IE, they are power of 2 and the BAT address must be aligned to that power of 2 (ie, the BAT matching uses the size as a bit mask of relevant bits to compare). Unless I misread, your code doesn't provide the necessary tests/rounding of size and alignment of the virtual address.. does it ? I do this particular test to make absolute sure that the caller absolutely understands the limitations of the block mapping. If they call this with something that isn't 128k aligned, then I make it fail immediately so the coder is forced to go and understand what they are allowed to do. Basically, I'm reinforcing the fact that this is not the same as ioremap(). I haven't decided yet if I should test size in the same way. Thoughts? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
From: Grant Likely [EMAIL PROTECTED]
ioremap_bat() is useful for things like mapping SoC internally memory mapped
register and early text because it allows mappings to devices to be setup
early in the boot process where they are needed, and the mappings persist
after the MMU is configured.
Without ioremap_bat(), setting up the MMU would cause the early text
mappings to get lost and mostly likely result in a kernel panic on the next
attempt at output.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
arch/powerpc/kernel/setup_32.c |9 ++
arch/powerpc/mm/init_32.c|7 --
arch/powerpc/mm/mmu_decl.h |4 +
arch/powerpc/mm/pgtable_32.c |2 -
arch/powerpc/mm/ppc_mmu_32.c | 148 --
arch/powerpc/sysdev/cpm_common.c |2 -
include/asm-powerpc/pgalloc-32.h |2 +
7 files changed, 140 insertions(+), 34 deletions(-)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 066e65c..7b25b57 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -113,6 +113,15 @@ notrace unsigned long __init early_init(unsigned long
dt_ptr)
*/
notrace void __init machine_init(unsigned long dt_ptr, unsigned long phys)
{
+ /* Do the bare minimum to start allocting from the IO region so
+* that ioremap_bat() works */
+#ifdef CONFIG_HIGHMEM
+ ioremap_base = PKMAP_BASE;
+#else
+ ioremap_base = 0xfe00UL;/* for now, could be 0xf000 */
+#endif /* CONFIG_HIGHMEM */
+ ioremap_bot = ioremap_base;
+
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 388ceda..a3d9b4e 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -169,13 +169,6 @@ void __init MMU_init(void)
ppc_md.progress(MMU:mapin, 0x301);
mapin_ram();
-#ifdef CONFIG_HIGHMEM
- ioremap_base = PKMAP_BASE;
-#else
- ioremap_base = 0xfe00UL;/* for now, could be 0xf000 */
-#endif /* CONFIG_HIGHMEM */
- ioremap_bot = ioremap_base;
-
/* Map in I/O resources */
if (ppc_md.progress)
ppc_md.progress(MMU:setio, 0x302);
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index fab3cfa..5027736 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -29,8 +29,8 @@ extern void hash_preload(struct mm_struct *mm, unsigned long
ea,
#ifdef CONFIG_PPC32
extern void mapin_ram(void);
extern int map_page(unsigned long va, phys_addr_t pa, int flags);
-extern void setbat(int index, unsigned long virt, phys_addr_t phys,
- unsigned int size, int flags);
+extern int setbat(unsigned long virt, phys_addr_t phys,
+ unsigned int size, int flags);
extern void settlbcam(int index, unsigned long virt, phys_addr_t phys,
unsigned int size, int flags, unsigned int pid);
extern void invalidate_tlbcam_entry(int index);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 2001abd..e96f745 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -55,8 +55,6 @@ extern void hash_page_sync(void);
#ifdef HAVE_BATS
extern phys_addr_t v_mapped_by_bats(unsigned long va);
extern unsigned long p_mapped_by_bats(phys_addr_t pa);
-void setbat(int index, unsigned long virt, phys_addr_t phys,
- unsigned int size, int flags);
#else /* !HAVE_BATS */
#define v_mapped_by_bats(x)(0UL)
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index c53145f..62c4603 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -72,41 +72,44 @@ unsigned long p_mapped_by_bats(phys_addr_t pa)
return 0;
}
+/**
+ * mmu_mapin_ram - Map as much of RAM as possible into kernel space using BATs
+ */
unsigned long __init mmu_mapin_ram(void)
{
#ifdef CONFIG_POWER4
return 0;
#else
unsigned long tot, bl, done;
- unsigned long max_size = (25620);
+ int rc;
if (__map_without_bats) {
printk(KERN_DEBUG RAM mapped without BATs\n);
return 0;
}
- /* Set up BAT2 and if necessary BAT3 to cover RAM. */
-
- /* Make sure we don't map a block larger than the
- smallest alignment of the physical address. */
+ /* Set up BATs to cover RAM. */
tot = total_lowmem;
- for (bl = 12810; bl max_size; bl = 1) {
- if (bl * 2 tot)
+ done = 0;
+ while (done tot) {
+ /* determine the smallest block size need to map the region.
+* Don't use a BAT mapping if the remaining region is less
+* that 128k */
+ if (tot - done = 12810)
break;
- }
-
- setbat(2, KERNELBASE, 0, bl, _PAGE_RAM);
- done = (unsigned long)bat_addrs[2].limit -
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Aug 6, 2008, at 1:02 AM, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] ioremap_bat() is useful for things like mapping SoC internally memory mapped register and early text because it allows mappings to devices to be setup early in the boot process where they are needed, and the mappings persist after the MMU is configured. Without ioremap_bat(), setting up the MMU would cause the early text mappings to get lost and mostly likely result in a kernel panic on the next attempt at output. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- why can't we just do this in ioremap itself? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, Aug 6, 2008 at 8:07 AM, Kumar Gala [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 1:02 AM, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] ioremap_bat() is useful for things like mapping SoC internally memory mapped register and early text because it allows mappings to devices to be setup early in the boot process where they are needed, and the mappings persist after the MMU is configured. Without ioremap_bat(), setting up the MMU would cause the early text mappings to get lost and mostly likely result in a kernel panic on the next attempt at output. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- why can't we just do this in ioremap itself? I suppose we could; but the usecase is somewhat different and I wanted to keep it simple. Using a separate API also helps reenforce that the caller really needs to know what they are doing because BATs are a limited resource. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Aug 6, 2008, at 4:54 PM, Grant Likely wrote: On Wed, Aug 6, 2008 at 8:07 AM, Kumar Gala [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 1:02 AM, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] ioremap_bat() is useful for things like mapping SoC internally memory mapped register and early text because it allows mappings to devices to be setup early in the boot process where they are needed, and the mappings persist after the MMU is configured. Without ioremap_bat(), setting up the MMU would cause the early text mappings to get lost and mostly likely result in a kernel panic on the next attempt at output. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- why can't we just do this in ioremap itself? I suppose we could; but the usecase is somewhat different and I wanted to keep it simple. Using a separate API also helps reenforce that the caller really needs to know what they are doing because BATs are a limited resource. there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, especially since we expect there to only be one actual invocation of the API for serial console access. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
ioremap_bat() is useful for things like mapping SoC internally memory mapped
register and early text because it allows mappings to devices to be setup
early in the boot process where they are needed, and the mappings persist
after the MMU is configured.
Without ioremap_bat(), setting up the MMU would cause the early text
mappings to get lost and mostly likely result in a kernel panic on the next
attempt at output.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
First comment, make the name more generic. This facility could be
implemented on processors without BATs using different techniques.
Maybe ioremap_block() or ioremap_early() or something like that.
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 066e65c..7b25b57 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -113,6 +113,15 @@ notrace unsigned long __init early_init(unsigned long
dt_ptr)
*/
notrace void __init machine_init(unsigned long dt_ptr, unsigned long phys)
{
+ /* Do the bare minimum to start allocting from the IO region so
+ * that ioremap_bat() works */
+#ifdef CONFIG_HIGHMEM
+ ioremap_base = PKMAP_BASE;
+#else
+ ioremap_base = 0xfe00UL;/* for now, could be 0xf000 */
+#endif /* CONFIG_HIGHMEM */
+ ioremap_bot = ioremap_base;
+
Can't these be statically initialized ? If not, then do a function call
to mm/ please. Something like mm_init_early().
+ /* BAT mappings must be 128k aligned */
+ if (addr != _ALIGN_DOWN(addr, 128 10))
+ return NULL;
Mustn't they be naturally aligned on their size ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
Kumar Gala wrote: On Aug 6, 2008, at 4:54 PM, Grant Likely wrote: I suppose we could; but the usecase is somewhat different and I wanted to keep it simple. Using a separate API also helps reenforce that the caller really needs to know what they are doing because BATs are a limited resource. there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, Why is it silly? It seems silly to me to complicate ioremap() with knowing when to use BATs and when not to use them. especially since we expect there to only be one actual invocation of the API for serial console access. I could also see a BAT (or equivalent) being used for IMMR-space, or other frequently accessed registers, to save TLB entries. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, especially since we expect there to only be one actual invocation of the API for serial console access. Not necessarily There's another aspect to BAT mappings here. First, they should be permanent (ie, not unmappable). That way, we have ioremap just use an existing BAT mapping when asked for a device that is covered by a BAT. This allows to have platform code do something like setup a BAT over a bunch of SOC registers or over a device, to automagically get drivers doing ioremap to that area benefit from it. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, Aug 6, 2008 at 4:11 PM, Kumar Gala [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 4:54 PM, Grant Likely wrote: On Wed, Aug 6, 2008 at 8:07 AM, Kumar Gala [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 1:02 AM, Grant Likely wrote: From: Grant Likely [EMAIL PROTECTED] ioremap_bat() is useful for things like mapping SoC internally memory mapped register and early text because it allows mappings to devices to be setup early in the boot process where they are needed, and the mappings persist after the MMU is configured. Without ioremap_bat(), setting up the MMU would cause the early text mappings to get lost and mostly likely result in a kernel panic on the next attempt at output. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- why can't we just do this in ioremap itself? I suppose we could; but the usecase is somewhat different and I wanted to keep it simple. Using a separate API also helps reenforce that the caller really needs to know what they are doing because BATs are a limited resource. there is a bunch of error checking and difference in semantics that you need to fix. details please? I agree that it can be tightened up in some areas, but I'd like to know if you've seen something I haven't. I think introduce a new API for this is silly, I don't think so. I actually prefer it being an different API. It forces the caller to understand what the function does. It forces the programmer to think and to understand the effect of mapping large io blocks. especially since we expect there to only be one actual invocation of the API for serial console access. Actually, this is not only for early serial. Early serial just happens to be the first user. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, Aug 6, 2008 at 4:26 PM, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
ioremap_bat() is useful for things like mapping SoC internally memory mapped
register and early text because it allows mappings to devices to be setup
early in the boot process where they are needed, and the mappings persist
after the MMU is configured.
Without ioremap_bat(), setting up the MMU would cause the early text
mappings to get lost and mostly likely result in a kernel panic on the next
attempt at output.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
First comment, make the name more generic. This facility could be
implemented on processors without BATs using different techniques.
Maybe ioremap_block() or ioremap_early() or something like that.
okay
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 066e65c..7b25b57 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -113,6 +113,15 @@ notrace unsigned long __init early_init(unsigned long
dt_ptr)
*/
notrace void __init machine_init(unsigned long dt_ptr, unsigned long phys)
{
+ /* Do the bare minimum to start allocting from the IO region so
+ * that ioremap_bat() works */
+#ifdef CONFIG_HIGHMEM
+ ioremap_base = PKMAP_BASE;
+#else
+ ioremap_base = 0xfe00UL;/* for now, could be 0xf000 */
+#endif /* CONFIG_HIGHMEM */
+ ioremap_bot = ioremap_base;
+
Can't these be statically initialized ? If not, then do a function call
to mm/ please. Something like mm_init_early().
heh, I had just moved this code block without thinking about it. I'll
investigate and see what I can do.
+ /* BAT mappings must be 128k aligned */
+ if (addr != _ALIGN_DOWN(addr, 128 10))
+ return NULL;
Mustn't they be naturally aligned on their size ?
I'm not sure what you're asking. Are you asking about this particular
test, or are you asking why I don't also test the size?
I do this particular test to make absolute sure that the caller
absolutely understands the limitations of the block mapping. If they
call this with something that isn't 128k aligned, then I make it fail
immediately so the coder is forced to go and understand what they are
allowed to do. Basically, I'm reinforcing the fact that this is not
the same as ioremap().
I haven't decided yet if I should test size in the same way. Thoughts?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Wed, Aug 6, 2008 at 4:28 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, especially since we expect there to only be one actual invocation of the API for serial console access. Not necessarily There's another aspect to BAT mappings here. First, they should be permanent (ie, not unmappable). That way, we have ioremap just use an existing BAT mapping when asked for a device that is covered by a BAT. This allows to have platform code do something like setup a BAT over a bunch of SOC registers or over a device, to automagically get drivers doing ioremap to that area benefit from it. Actually, that is exactly what I am in the process of doing right now for all the 5200 platforms. It is a performance win with no apparent downside. Next I want to investigate if it makes sense to do it for PCI IO regions. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Thu, Aug 07, 2008 at 08:28:29AM +1000, Benjamin Herrenschmidt wrote: there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, especially since we expect there to only be one actual invocation of the API for serial console access. Not necessarily There's another aspect to BAT mappings here. First, they should be permanent (ie, not unmappable). That way, we have ioremap just use an existing BAT mapping when asked for a device that is covered by a BAT. This allows to have platform code do something like setup a BAT over a bunch of SOC registers or over a device, to automagically get drivers doing ioremap to that area benefit from it. The m68k arch code does something similar with TT registers and ioremap, but it's a little hackish currently. If there was a more generic way to handle it, that would make things a little cleaner. In the m68k implementation, there are just exceptions in the ioremap code that are hard wired to know about the ranges that are normally set earlier. Since the ranges end up being in multiple files, it's more fragile to change what is mapped in these blocks. Brad Boyer [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
On Aug 6, 2008, at 5:28 PM, Benjamin Herrenschmidt wrote: there is a bunch of error checking and difference in semantics that you need to fix. I think introduce a new API for this is silly, especially since we expect there to only be one actual invocation of the API for serial console access. Not necessarily There's another aspect to BAT mappings here. First, they should be permanent (ie, not unmappable). That way, we have ioremap just use an existing BAT mapping when asked for a device that is covered by a BAT. This allows to have platform code do something like setup a BAT over a bunch of SOC registers or over a device, to automagically get drivers doing ioremap to that area benefit from it. why should they be permanent.. We could implement reference counting around the regions and free BATs if the count = 0. I'm more concerned about this being implemented around the existing ioremap core in __ioremap(). We can easily use a flag bit to say use large mappings or the fact that mem_init_done == 0. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH 1/3] powerpc: add ioremap_bat() function for setting up BAT translated IO regions.
why can't we just do this in ioremap itself? I suppose we could; but the usecase is somewhat different and I wanted to keep it simple. Using a separate API also helps reenforce that the caller really needs to know what they are doing because BATs are a limited resource. there is a bunch of error checking and difference in semantics that you need to fix. details please? I agree that it can be tightened up in some areas, but I'd like to know if you've seen something I haven't. The alignment checks for one? Why does the caller need to ensure alignment.. we just force alignment in __ioremap().. we should be doing the same thing here. I think introduce a new API for this is silly, I don't think so. I actually prefer it being an different API. It forces the caller to understand what the function does. It forces the programmer to think and to understand the effect of mapping large io blocks. Ok.. My feeling is the same core logic should be used so I don't have to fix 2 places in the future. especially since we expect there to only be one actual invocation of the API for serial console access. Actually, this is not only for early serial. Early serial just happens to be the first user. Than this really should be done as part of __ioremap() since you have to deal with doing different things depending on how mem_init_done is set. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
