Static mappings at boottime

Static mappings at boottime

[Khushhua Mogambo]

Dears

 my soc have very simple and limited device controllers. I have thought
maybe I can map all devices's register spaces using iotable_init in map_io.
And pass already mapped Virtual addr(and not phys addr) to device drivers
 via IORESOURCE_MEM.
i thinks that way i can do most use of virtual address space for ioremap
and I can set VMALLOC size to maximum possible. also drivers doesnt have
to worry about mapping(and no addr space is mapped twice in two code pieces)

is it considered good kernel porting practice? can we face any problem
after some times?

thanking you
M.Park

Static mappings at boottime

[Russell King - ARM Linux]

On Sat, Jan 30, 2010 at 11:47:36PM +0900, Khushhua Mogambo wrote:
> Dears
> 
>  my soc have very simple and limited device controllers. I have thought
> maybe I can map all devices's register spaces using iotable_init in map_io.

Yes, you can do this.

> And pass already mapped Virtual addr(and not phys addr) to device drivers
>  via IORESOURCE_MEM.

But you can't do this.  Resources take physical addresses, not virtual
addresses.

> i thinks that way i can do most use of virtual address space for ioremap
> and I can set VMALLOC size to maximum possible. also drivers doesnt have
> to worry about mapping(and no addr space is mapped twice in two code pieces)
> 
> is it considered good kernel porting practice? can we face any problem
> after some times?

Definitely not.

The "simple" approach to your proposal is to map the device space
statically and then intercept ioremap().  When you detect a request
for a range which is already statically mapped, then return the
already mapped virtual address.

This doesn't change the way you write the drivers; you write drivers
using the standard interfaces and continue to assume that those
interfaces will fail.

Static mappings at boottime

[Khushhua Mogambo]

On Sat, Jan 30, 2010 at 11:55 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jan 30, 2010 at 11:47:36PM +0900, Khushhua Mogambo wrote:
>> And pass already mapped Virtual addr(and not phys addr) to device drivers
>> ?via IORESOURCE_MEM.
>
> But you can't do this. ?Resources take physical addresses, not virtual
> addresses.
 but phys addr and virt addr is both u32 numbers
 how can kernel detect i passes virt and not phys address?

>> i thinks that way i can do most use of virtual address space for ioremap
>> and I can set VMALLOC size to maximum possible. also drivers doesnt have
>> to worry about mapping(and no addr space is mapped twice in two code pieces)
>>
>> is it considered good kernel porting practice? can we face any problem
>> after some times?
>
> Definitely not.
sorry i asks two opposite qeustions same time.
i am hopeful "Definitely not" is reply of second question ^^

> The "simple" approach to your proposal is to map the device space
> statically and then intercept ioremap(). ?When you detect a request
> for a range which is already statically mapped, then return the
> already mapped virtual address.
i almost forgets the __arch_ioremap. thanks.

Static mappings at boottime

[Russell King - ARM Linux]

On Sun, Jan 31, 2010 at 12:13:42AM +0900, Khushhua Mogambo wrote:
> On Sat, Jan 30, 2010 at 11:55 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Sat, Jan 30, 2010 at 11:47:36PM +0900, Khushhua Mogambo wrote:
> >> And pass already mapped Virtual addr(and not phys addr) to device drivers
> >> ?via IORESOURCE_MEM.
> >
> > But you can't do this. ?Resources take physical addresses, not virtual
> > addresses.
>  but phys addr and virt addr is both u32 numbers
>  how can kernel detect i passes virt and not phys address?

No, virtual addresses are _pointers_, not integers.

> 
> >> i thinks that way i can do most use of virtual address space for ioremap
> >> and I can set VMALLOC size to maximum possible. also drivers doesnt have
> >> to worry about mapping(and no addr space is mapped twice in two code pieces)
> >>
> >> is it considered good kernel porting practice? can we face any problem
> >> after some times?
> >
> > Definitely not.
> sorry i asks two opposite qeustions same time.
> i am hopeful "Definitely not" is reply of second question ^^

It was in reply to the first question.

Static mappings at boottime

[Mogambo Park]

On Sun, Jan 31, 2010 at 12:39 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sun, Jan 31, 2010 at 12:13:42AM +0900, Khushhua Mogambo wrote:
>> On Sat, Jan 30, 2010 at 11:55 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Sat, Jan 30, 2010 at 11:47:36PM +0900, Khushhua Mogambo wrote:
>> >> And pass already mapped Virtual addr(and not phys addr) to device drivers
>> >> ?via IORESOURCE_MEM.
>> >
>> > But you can't do this. ?Resources take physical addresses, not virtual
>> > addresses.
>> ?but phys addr and virt addr is both u32 numbers
>> ?how can kernel detect i passes virt and not phys address?
>
> No, virtual addresses are _pointers_, not integers.
OK I will the pass only phys addr.

>>
>> >> i thinks that way i can do most use of virtual address space for ioremap
>> >> and I can set VMALLOC size to maximum possible. also drivers doesnt have
>> >> to worry about mapping(and no addr space is mapped twice in two code pieces)
>> >>
>> >> is it considered good kernel porting practice? can we face any problem
>> >> after some times?
>> >
>> > Definitely not.
>> sorry i asks two opposite qeustions same time.
>> i am hopeful "Definitely not" is reply of second question ^^
>
> It was in reply to the first question.
i understands, I will use all staticaly mapped devices space and implement
__arch_ioremap type funcs to give virt addr to drivers.
thanks a lots.