VR4131 - MQ1132 - UPD63335

VR4131 - MQ1132 - UPD63335

[Suresh. R]

Hi,
   This might be a very basic question, but I am very new to this field. 
So please help me.

I am writing a linux device driver for UPD63335 audio codec. Its 
controlled through the MQ1132 co-processor. The VR4131 is the processor. 
The memory of MQ1132 is mapped to the processor memory in Kseg1 (0xA000 
0000 onwards) which the manual says is TLB Unmapped region. Now my 
question is is it necessary to map this region before using it in Linux. 
Actually I have WinCE code for my reference. In that code the programmer 
is mapping the region using Virtual Cpoy and Virtual Alloc. Is it 
necessary to do that or Can I directly address the memory locatoin.

Please help

Thanks in advance

Regards
Suresh

Re: VR4131 - MQ1132 - UPD63335

[Geert Uytterhoeven]

On Fri, 16 Jan 2004, Suresh. R wrote:
> I am writing a linux device driver for UPD63335 audio codec. Its
> controlled through the MQ1132 co-processor. The VR4131 is the processor.
> The memory of MQ1132 is mapped to the processor memory in Kseg1 (0xA000
> 0000 onwards) which the manual says is TLB Unmapped region. Now my
> question is is it necessary to map this region before using it in Linux.
> Actually I have WinCE code for my reference. In that code the programmer
> is mapping the region using Virtual Cpoy and Virtual Alloc. Is it
> necessary to do that or Can I directly address the memory locatoin.

From the Linux kernel, you can access all memory at 0xa0000000 'till 0xbfffffff
directly.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: VR4131 - MQ1132 - UPD63335

[Geert Uytterhoeven]

On Fri, 16 Jan 2004, Suresh. R wrote:
> I am writing a linux device driver for UPD63335 audio codec. Its
> controlled through the MQ1132 co-processor. The VR4131 is the processor.
> The memory of MQ1132 is mapped to the processor memory in Kseg1 (0xA000
> 0000 onwards) which the manual says is TLB Unmapped region. Now my
> question is is it necessary to map this region before using it in Linux.
> Actually I have WinCE code for my reference. In that code the programmer
> is mapping the region using Virtual Cpoy and Virtual Alloc. Is it
> necessary to do that or Can I directly address the memory locatoin.

Re: VR4131 - MQ1132 - UPD63335

[Kevin D. Kissell]

If I recall correctly, WinCE runs drivers and system services in User mode,
so any memory-mapped I/O would need to be set-up explicitly in the virtual 
address space.  As Geert has pointed out, so long as it's in that first 512MB,
a Linux driver running in Kernel mode can access it directly via Kseg1 (or
Kseg0, if you wanted to be able to cache the data).

----- Original Message ----- 
From: "Suresh. R" <suresh@mistralsoftware.com>
To: <linux-mips@linux-mips.org>
Sent: Friday, January 16, 2004 8:32
Subject: VR4131 - MQ1132 - UPD63335


> Hi,
>    This might be a very basic question, but I am very new to this field. 
> So please help me.
> 
> I am writing a linux device driver for UPD63335 audio codec. Its 
> controlled through the MQ1132 co-processor. The VR4131 is the processor. 
> The memory of MQ1132 is mapped to the processor memory in Kseg1 (0xA000 
> 0000 onwards) which the manual says is TLB Unmapped region. Now my 
> question is is it necessary to map this region before using it in Linux. 
> Actually I have WinCE code for my reference. In that code the programmer 
> is mapping the region using Virtual Cpoy and Virtual Alloc. Is it 
> necessary to do that or Can I directly address the memory locatoin.
> 
> Please help
> 
> Thanks in advance
> 
> Regards
> Suresh
> 
> 
> 

Re: VR4131 - MQ1132 - UPD63335

[Kevin D. Kissell]

If I recall correctly, WinCE runs drivers and system services in User mode,
so any memory-mapped I/O would need to be set-up explicitly in the virtual 
address space.  As Geert has pointed out, so long as it's in that first 512MB,
a Linux driver running in Kernel mode can access it directly via Kseg1 (or
Kseg0, if you wanted to be able to cache the data).

----- Original Message ----- 
From: "Suresh. R" <suresh@mistralsoftware.com>
To: <linux-mips@linux-mips.org>
Sent: Friday, January 16, 2004 8:32
Subject: VR4131 - MQ1132 - UPD63335


> Hi,
>    This might be a very basic question, but I am very new to this field. 
> So please help me.
> 
> I am writing a linux device driver for UPD63335 audio codec. Its 
> controlled through the MQ1132 co-processor. The VR4131 is the processor. 
> The memory of MQ1132 is mapped to the processor memory in Kseg1 (0xA000 
> 0000 onwards) which the manual says is TLB Unmapped region. Now my 
> question is is it necessary to map this region before using it in Linux. 
> Actually I have WinCE code for my reference. In that code the programmer 
> is mapping the region using Virtual Cpoy and Virtual Alloc. Is it 
> necessary to do that or Can I directly address the memory locatoin.
> 
> Please help
> 
> Thanks in advance
> 
> Regards
> Suresh
> 
> 
> 

Re: VR4131 - MQ1132 - UPD63335

[Ralf Baechle]

On Fri, Jan 16, 2004 at 01:02:33PM +0530, Suresh. R wrote:

>   This might be a very basic question, but I am very new to this field. 
> So please help me.
> 
> I am writing a linux device driver for UPD63335 audio codec. Its 
> controlled through the MQ1132 co-processor. The VR4131 is the processor. 
> The memory of MQ1132 is mapped to the processor memory in Kseg1 (0xA000 
> 0000 onwards) which the manual says is TLB Unmapped region. Now my 
> question is is it necessary to map this region before using it in Linux. 
> Actually I have WinCE code for my reference. In that code the programmer 
> is mapping the region using Virtual Cpoy and Virtual Alloc. Is it 
> necessary to do that or Can I directly address the memory locatoin.

Generally a driver under Linux maps a device in it's initialization
routine with a bit of code like

#define FOO_BASE	0x12340000UL		/* physical address */
#define FOO_SIZE	0x00001000UL

...
	struct foo_regs *base;

	base = ioremap(0x1234, FOO_SIZE);
	if (!base) {
		/* Failed, game over  */
		harakiri();
		...
	}

	/* Success, make it blink ... */
	foo->blinkenlight = 42;
...
	/* Done, unmap before exiting.
	unmap(base);
...

This removes all knowledge about how a particular architecture handles
mappings from the driver and therefore is generally the prefered way in
Linux.

Linux/MIPS optimize the case where an unmapped area can be used, so no
runtime overhead at all.

  Ralf

Re: VR4131 - MQ1132 - UPD63335

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

On Sat, 2004-01-17 13:20:22 +0100, Ralf Baechle <ralf@linux-mips.org>
wrote in message <20040117122022.GD5288@linux-mips.org>:
> #define FOO_BASE	0x12340000UL		/* physical address */
                        ^^^^^^^^^^
> #define FOO_SIZE	0x00001000UL
> 
> 	base = ioremap(0x1234, FOO_SIZE);
                       ^^^^^^
Not FOO_BASE?

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: VR4131 - MQ1132 - UPD63335

[Dimitri Torfs]

On Sat, Jan 17, 2004 at 01:51:42PM +0100, Jan-Benedict Glaw wrote:
> On Sat, 2004-01-17 13:20:22 +0100, Ralf Baechle <ralf@linux-mips.org>
> wrote in message <20040117122022.GD5288@linux-mips.org>:
> > #define FOO_BASE	0x12340000UL		/* physical address */
>                         ^^^^^^^^^^
> > #define FOO_SIZE	0x00001000UL
> > 
> > 	base = ioremap(0x1234, FOO_SIZE);
>                        ^^^^^^
> Not FOO_BASE?
> 

And it's better to use writel/readl and friends on thingies returned by
ioremap:

      struct foo_regs* foo = ioremap(FOO_BASE, FOO_SIZE);
      ...      
      writel(42, &foo->blinkenlight);


Dimitri


-- 
Dimitri Torfs       |  NSCE 
dimitri@sonycom.com |  The Corporate Village
tel: +32 2 7008541  |  Da Vincilaan 7 - D1 
fax: +32 2 7008622  |  B-1935 Zaventem - Belgium