Getting rid of static IO mapping

Getting rid of static IO mapping

[Sylvain Munaut]

Hi,

In the mpc5200 2.6 support, I'm trying to get rid of all static io
mapping.
So every address I use must be ioremaped. For the device drivers, no
problem they are remaped during probe and released if modules get
unloaded. For some routines used at boot & setup, I just ioremap at
the function begining and ioumap at the end. For interrupt handling,
since ioremap at each interrupt is not really nice, I just do it
durint irq_init and then keep the vaddr in a global var to the file
(static).

Until there, it works fine. My only problem left is with the
ppc_md.progress. I'm not sure what is the memory environment at each
time it might be called. Can I use ioremap/iounmap at each call ? (I
know I could just try but that might work even if it's wrong(tm) ).

In the current situation, I use the physical address and there is a
1:1 mapping. The mapping is first done by directly manipulating
{D,I}BAT2, then by setup_io_mappings.
If I understood correctly, I should use the physical address while the
BAT2 mapping is still active, then when the memory managment is ok,
ioremap it. Is it correct ? How can I know when BAT2 has been
overwritten and ioremap ready to go ? Is this the purpose of
mem_init_done ?


Sylvain Munaut


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Getting rid of static IO mapping

[Sylvain Munaut]

Sylvain Munaut wrote:

 > In the current situation, I use the physical address and there is a
 >  1:1 mapping. The mapping is first done by directly manipulating
 > {D,I}BAT2, then by setup_io_mappings.

Actually, looking at the code in arch/ppc/mm/init.c

        /* Map in all of RAM starting at KERNELBASE */
        if (ppc_md.progress)
                ppc_md.progress("MMU:mapin", 0x301);
        mapin_ram();

#ifdef CONFIG_HIGHMEM
        ioremap_base = PKMAP_BASE;
#else
        ioremap_base = 0xfe000000UL;    /* for now, could be 0xfffff000 */
#endif /* CONFIG_HIGHMEM */
        ioremap_bot = ioremap_base;

        /* Map in I/O resources */
        if (ppc_md.progress)
                ppc_md.progress("MMU:setio", 0x302);
        if (ppc_md.setup_io_mappings)
                ppc_md.setup_io_mappings();


I wonder how it works. At the mapin_ram(), my BAT are overwritten,
then the "MMU:setio" progress is called, but at this point, my BAT is
no longer active and my setup_io_mappings is not yet called. Shouldn't
that crash ? During these two calls, the uart zone shouldn't be mapped.


Sylvain Munaut


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Getting rid of static IO mapping

[Linh Dang]

On 6 Jul 2004, tnt@246tnt.com wrote:
[...]
> I wonder how it works. At the mapin_ram(), my BAT are overwritten,

No they're not. the BAT configurations (which will be used later by
load_up_mmu) are written, NOT the BATs themselves.

> then the "MMU:setio" progress is called, but at this point, my BAT
> is no longer active and my setup_io_mappings is not yet
> called. Shouldn't that crash ? During these two calls, the uart zone
> shouldn't be mapped.

setup_io_mappings is similar to mapin_ram. the configurations are
changed but not the BATs.

--
Linh Dang

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Getting rid of static IO mapping

[Sylvain Munaut]

Linh Dang wrote:

>On 6 Jul 2004, tnt@246tnt.com wrote:
>[...]
>
>
>>I wonder how it works. At the mapin_ram(), my BAT are overwritten,
>>
>>
>
>No they're not. the BAT configurations (which will be used later by
>load_up_mmu) are written, NOT the BATs themselves.
>
>
>
Ok, thanks. That's what I've missed.

>>then the "MMU:setio" progress is called, but at this point, my BAT
>>is no longer active and my setup_io_mappings is not yet
>>called. Shouldn't that crash ? During these two calls, the uart zone
>>shouldn't be mapped.
>>
>>
>
>setup_io_mappings is similar to mapin_ram. the configurations are
>changed but not the BATs.
>
>


Sylvain Munaut

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Getting rid of static IO mapping

[Sylvain Munaut]

Hi

I'll try to re-explain my problem more clearly. Maybe some one will
see a solution.

I'm trying to avoid any static io mapping. So no use of
setup_io_mapping. I also setup a handler for ppc_md.progress to have
early debug.
This progress function makes use of the UART, so at every call the
uart must be mapped and I have to know where.

In the current code, during platform setup, I setup BAT2 to 1:1 map
this area. So I can access it early and I know the address. But when
load_up_mmu is called, my mapping disapear ( wanted behavior ), so
from this point, I should ioremap the zone once and keep it in a
static var (to avoir ioremap/iounmap each time). The problem is to
detect WHEN I should ioremap it, detect if the load_up_mmu part is
done or not.

The solutions I have thinked of :
 - Don't use BAT2 at all and ioremap it from the start. But at that
point ioremap will use io_remap_base and not the vm. So I'm not sure
it's a good idea to keep it all the time. Does the vm will know not to
use it ? And looking at the comment in arch/ppc/mm/init.c :

        ioremap_base = 0xfe000000UL;    /* for now, could be 0xfffff000 */

I'd say that I should avoir ioremap before mem_init_done.

 - Another solution, use BAT2, then when mem_init_done == 1, ioremap.
But mem_init_done is set to 1 before load_up_mmu, so I would end up
with the same area mapped by the BATs and the pages. IIRC in the 603
manual, it's clearly noted that should not happen.

So anyone has a clue on how to do it ?


Sylvain Munaut


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Getting rid of static IO mapping

[Dan Malek]

On Jul 7, 2004, at 1:07 PM, Sylvain Munaut wrote:

> I'll try to re-explain my problem more clearly. Maybe some one will
> see a solution.

I think you are trying too hard to solve something that really
isn't a problem.

The use of BATs is a significant performance advantage.  It's
relatively easy to create an ioremap() function that can see if
a BAT covers a space we want and return an appropriate
mapped address.  The converse, creating an ioremap() function
that is smart enough to track all of the I/O usage and determine
how best to use BATs, is very challenging.

Due to the way we have to access memory and devices for
initialization (when vm mapping through ioremap() isn't available)
and the constraints on the kernel VM space, I find it easy to
just declare the BAT values and let ioremap() work as it does in 2.4.

If you look outside of the traditional PowerPC cores (to things
like 8xx, 4xx, and 85xx) you will find even more challenging
early or efficient mapping problems.

Just set the BATs according to the board configurations, keep
the functions simple, and move on.  These functions are
currently working fine for many of the 603 core platforms.  I'd
suggest changing your board setup functions to work with
the common code already present instead of trying to fix
something that isn't broken.

Thanks.

	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Getting rid of static IO mapping

[Sylvain Munaut]

Hi

> The use of BATs is a significant performance advantage.  It's
> relatively easy to create an ioremap() function that can see if
> a BAT covers a space we want and return an appropriate
> mapped address.  The converse, creating an ioremap() function
> that is smart enough to track all of the I/O usage and determine
> how best to use BATs, is very challenging.

Yes, sure.

> Due to the way we have to access memory and devices for
> initialization (when vm mapping through ioremap() isn't available)
> and the constraints on the kernel VM space, I find it easy to
> just declare the BAT values and let ioremap() work as it does in 2.4.

> If you look outside of the traditional PowerPC cores (to things
> like 8xx, 4xx, and 85xx) you will find even more challenging
> early or efficient mapping problems.
>
> Just set the BATs according to the board configurations, keep
> the functions simple, and move on.  These functions are
> currently working fine for many of the 603 core platforms.  I'd
> suggest changing your board setup functions to work with
> the common code already present instead of trying to fix
> something that isn't broken.

Well, I certainly never meant to change any standard functions.
I just wanted to avoid being dependent on it, so it works with or
without it. But I've dropped it. As you said, there are multiples
register that need to be accessed at init while other things just don't
work yet.

Just a remaining question. I got one call to ioremap() before
mem_init_done, it works as expected and returns a valid pointer. I just
wonder if the mapping it has done will remain valid after vm init. I
guess so but I'd rather not discover it the hard way.


Sylvain Munaut

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Getting rid of static IO mapping

[Linh Dang]

On 7 Jul 2004, tnt@246tnt.com wrote:

>
> Hi
>
> I'll try to re-explain my problem more clearly. Maybe some one will
> see a solution.
>
> I'm trying to avoid any static io mapping. So no use of
> setup_io_mapping. I also setup a handler for ppc_md.progress to have
> early debug.
> This progress function makes use of the UART, so at every call the
> uart must be mapped and I have to know where.

I'm NOT sure what are you trying to avoid. a typical setup_io_mapping
function is:


static void __init
my_card_map_io(void)
{
    io_block_mapping(MY_IO_VIRT_ADDR_1, MY_IO_PHYS_ADDR_1,
                     MY_IO_1_SIZE, PAGE_XXX);

    io_block_mapping(MY_IO_VIRT_ADDR_2, MY_IO_PHYS_ADDR_2,
                     MY_IO_2_SIZE, PAGE_XXX);

    ...
}


1. you HAVE TO provide the virt address and the phys
   address. io_block_mapping will not do it for you.


2. io_block_mapping will try to use available bats. if none avail, it
   will use pages. So you're NOT hardcoding the BAT values.


3. By CONVENTION, in your platform_init(), you should use bat3 to map
   the io space needed for your uart. Also by convention, you should
   reuse that same addresses in your setup_io_mapping(). So your UART
   is located at the SAME address BEFORE (via BAT3) and AFTER (using
   whatever io_block_mapping can use) the call to load_up_mmu().


I think you should probably explain what are you trying to achieve
before we can give you better suggestions.


--
Linh Dang

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/