IO port conflict between timer & watchdog on PCISA-C800EV board ?

IO port conflict between timer & watchdog on PCISA-C800EV board ?

[Charles-Edouard Ruault]

Hi All,

i wrote a driver for the watchdog timer provided by a small form factor 
board from IEI ( the PCISA-C800EV : 
http://www.iei.com.tw/en/product_IPC.asp?model=PCISA-C800 ).
This board has a Via Apollo PLE133 ( VT8601A and VT82C686B ) chipset.
The watchdog uses two registers at addresses 0x43 and 0x443, therefore 
my driver tries to get bot addresses for its own use calling
request_region(0x43, 1, "watchdog" ) and request_region(0x443, 1, 
"watchdog").
The first call to request 0x43 fails because the address has already 
been allocated to the timer ( /proc/ioports shows 0040-005f : timer ).

So my questions are :
- Why is the generic timer using this address ? isn't it reserving a too 
wide portion of IO ports ? Should it be modified for this board ?
-  If there's a good reason for the timer to request this address, is  
there a clean way to share it with the timer ?

Thanks for your answers.
Regards.
PS: Please CC me to your replies, i'm not on the list.

-- 
Charles-Edouard Ruault
Idtect SA
115 rue Reaumur - 75002, Paris, France
Tel: +33-1-55-34-76-65
Fax: +33-1-55-34-76-75
Web: http://www.idtect.com

Re: IO port conflict between timer & watchdog on PCISA-C800EV board ?

[Randy.Dunlap]

Charles-Edouard Ruault wrote:
> Hi All,
> 
> i wrote a driver for the watchdog timer provided by a small form factor 
> board from IEI ( the PCISA-C800EV : 
> http://www.iei.com.tw/en/product_IPC.asp?model=PCISA-C800 ).
> This board has a Via Apollo PLE133 ( VT8601A and VT82C686B ) chipset.
> The watchdog uses two registers at addresses 0x43 and 0x443, therefore 
> my driver tries to get bot addresses for its own use calling
> request_region(0x43, 1, "watchdog" ) and request_region(0x443, 1, 
> "watchdog").
> The first call to request 0x43 fails because the address has already 
> been allocated to the timer ( /proc/ioports shows 0040-005f : timer ).
> 
> So my questions are :
> - Why is the generic timer using this address ? isn't it reserving a too 
> wide portion of IO ports ? Should it be modified for this board ?
> -  If there's a good reason for the timer to request this address, is  
> there a clean way to share it with the timer ?

Missing kernel version.... must be "not the current/latest",
so early 2.6 or more likely 2.4 (just guessing)?

/proc/ioports timer assignments have now been split up like this:
0040-0043 : timer0
0050-0053 : timer1

However, port 0x43 is still assigned to timer0, so your request_region
call will still fail.  What system board timer resource assignments
should be used for that VIA chipset?  If the chipset timer only needs
0x40-0x42, e.g., leaving 0x43 available, then it would be possible
to do some kind of workaround (maybe not real clean, but possible).

-- 
~Randy

Re: IO port conflict between timer & watchdog on PCISA-C800EV board ?

[linux-os]

On Mon, 7 Feb 2005, Randy.Dunlap wrote:

> Charles-Edouard Ruault wrote:
>> Hi All,
>> 
>> i wrote a driver for the watchdog timer provided by a small form factor 
>> board from IEI ( the PCISA-C800EV : 
>> http://www.iei.com.tw/en/product_IPC.asp?model=PCISA-C800 ).
>> This board has a Via Apollo PLE133 ( VT8601A and VT82C686B ) chipset.
>> The watchdog uses two registers at addresses 0x43 and 0x443, therefore my 
>> driver tries to get bot addresses for its own use calling
>> request_region(0x43, 1, "watchdog" ) and request_region(0x443, 1, 
>> "watchdog").
>> The first call to request 0x43 fails because the address has already been 
>> allocated to the timer ( /proc/ioports shows 0040-005f : timer ).
>> 
>> So my questions are :
>> - Why is the generic timer using this address ? isn't it reserving a too 
>> wide portion of IO ports ? Should it be modified for this board ?
>> -  If there's a good reason for the timer to request this address, is 
>> there a clean way to share it with the timer ?
>
> Missing kernel version.... must be "not the current/latest",
> so early 2.6 or more likely 2.4 (just guessing)?
>
> /proc/ioports timer assignments have now been split up like this:
> 0040-0043 : timer0
> 0050-0053 : timer1
>
> However, port 0x43 is still assigned to timer0, so your request_region
> call will still fail.  What system board timer resource assignments
> should be used for that VIA chipset?  If the chipset timer only needs
> 0x40-0x42, e.g., leaving 0x43 available, then it would be possible
> to do some kind of workaround (maybe not real clean, but possible).
>
> -- 
> ~Randy

The driver can still R/W registers that it hasn't allocated.
There is no hardware trap preventing this. I suggest that,
as a temporary work-around, just don't allocate the low
port, but attempt to use it. I think the watchdog probably
just looks for read at that address.


Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: IO port conflict between timer & watchdog on PCISA-C800EV board ?

[Charles-Edouard Ruault]

linux-os wrote:

> On Mon, 7 Feb 2005, Randy.Dunlap wrote:
>
>> Charles-Edouard Ruault wrote:
>>
>>> Hi All,
>>>
>>> i wrote a driver for the watchdog timer provided by a small form 
>>> factor board from IEI ( the PCISA-C800EV : 
>>> http://www.iei.com.tw/en/product_IPC.asp?model=PCISA-C800 ).
>>> This board has a Via Apollo PLE133 ( VT8601A and VT82C686B ) chipset.
>>> The watchdog uses two registers at addresses 0x43 and 0x443, 
>>> therefore my driver tries to get bot addresses for its own use calling
>>> request_region(0x43, 1, "watchdog" ) and request_region(0x443, 1, 
>>> "watchdog").
>>> The first call to request 0x43 fails because the address has already 
>>> been allocated to the timer ( /proc/ioports shows 0040-005f : timer ).
>>>
>>> So my questions are :
>>> - Why is the generic timer using this address ? isn't it reserving a 
>>> too wide portion of IO ports ? Should it be modified for this board ?
>>> -  If there's a good reason for the timer to request this address, 
>>> is there a clean way to share it with the timer ?
>>
>>
>> Missing kernel version.... must be "not the current/latest",
>> so early 2.6 or more likely 2.4 (just guessing)?
>>
>> /proc/ioports timer assignments have now been split up like this:
>> 0040-0043 : timer0
>> 0050-0053 : timer1
>>
>> However, port 0x43 is still assigned to timer0, so your request_region
>> call will still fail.  What system board timer resource assignments
>> should be used for that VIA chipset?  If the chipset timer only needs
>> 0x40-0x42, e.g., leaving 0x43 available, then it would be possible
>> to do some kind of workaround (maybe not real clean, but possible).
>>
>> -- 
>> ~Randy
>
>
> The driver can still R/W registers that it hasn't allocated.
> There is no hardware trap preventing this. I suggest that,
> as a temporary work-around, just don't allocate the low
> port, but attempt to use it. I think the watchdog probably
> just looks for read at that address.

Hi Dick,
thanks for the reply. Right now i'm doing exactly what you suggest and 
it works fine ... but i'm not really happy about this "workaround" since 
it's not clean.
The driver reads only at 0x43 to disable the watchdog , i have not seen 
any side effect so far but ... one never knows !

>
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
>  Notice : All mail here is now cached for review by Dictator Bush.
>                  98.36% of all statistics are fiction.



-- 
Charles-Edouard Ruault
Idtect SA
115 rue Reaumur - 75002, Paris, France
Tel: +33-1-55-34-76-65
Fax: +33-1-55-34-76-75
Web: http://www.idtect.com

Re: IO port conflict between timer & watchdog on PCISA-C800EV board ?

[Charles-Edouard Ruault]

Randy.Dunlap wrote:

> Charles-Edouard Ruault wrote:
>
>> Hi All,
>>
>> i wrote a driver for the watchdog timer provided by a small form 
>> factor board from IEI ( the PCISA-C800EV : 
>> http://www.iei.com.tw/en/product_IPC.asp?model=PCISA-C800 ).
>> This board has a Via Apollo PLE133 ( VT8601A and VT82C686B ) chipset.
>> The watchdog uses two registers at addresses 0x43 and 0x443, 
>> therefore my driver tries to get bot addresses for its own use calling
>> request_region(0x43, 1, "watchdog" ) and request_region(0x443, 1, 
>> "watchdog").
>> The first call to request 0x43 fails because the address has already 
>> been allocated to the timer ( /proc/ioports shows 0040-005f : timer ).
>>
>> So my questions are :
>> - Why is the generic timer using this address ? isn't it reserving a 
>> too wide portion of IO ports ? Should it be modified for this board ?
>> -  If there's a good reason for the timer to request this address, 
>> is  there a clean way to share it with the timer ?
>
>
> Missing kernel version.... must be "not the current/latest",
> so early 2.6 or more likely 2.4 (just guessing)?
>
> /proc/ioports timer assignments have now been split up like this:
> 0040-0043 : timer0
> 0050-0053 : timer1
>
> However, port 0x43 is still assigned to timer0, so your request_region
> call will still fail.  What system board timer resource assignments
> should be used for that VIA chipset?  If the chipset timer only needs
> 0x40-0x42, e.g., leaving 0x43 available, then it would be possible
> to do some kind of workaround (maybe not real clean, but possible).
>
Hi Randy,
thanks for the reply.
My apologies for not including the kernel version ( that's what you get 
when you try to go too fast ;)
You were right, i'm running 2.4.29 !
I don't know about the resources assignments needed by this timer. I 
tried to get the spec sheets for the chipset from the via site but i was 
not able to find it ( i did not spend hours looking tough ).
I was wondering if someone had the info out there !
Right now i'm just not taking into account the failure of the 
request_region and everything works fine. But i wanted to make it clean 
so ... i'll have to dig deeper into this i guess !


-- 
Charles-Edouard Ruault
Idtect SA
115 rue Reaumur - 75002, Paris, France
Tel: +33-1-55-34-76-65
Fax: +33-1-55-34-76-75
Web: http://www.idtect.com

Re: IO port conflict between timer & watchdog on PCISA-C800EV board ?

[Ondrej Zary]

Randy.Dunlap wrote:
[...]
> /proc/ioports timer assignments have now been split up like this:
> 0040-0043 : timer0
> 0050-0053 : timer1
> 
> However, port 0x43 is still assigned to timer0, so your request_region
> call will still fail.  What system board timer resource assignments
> should be used for that VIA chipset?  If the chipset timer only needs
> 0x40-0x42, e.g., leaving 0x43 available, then it would be possible
> to do some kind of workaround (maybe not real clean, but possible).

The timer uses ports 0x40-0x43. However, port 0x43 is defined as WO 
(write-only) - it's timer command register.

-- 
Ondrej Zary

Re: IO port conflict between timer & watchdog on PCISA-C800EV board ?

[Alan Cox]

On Llu, 2005-02-07 at 09:29, Charles-Edouard Ruault wrote:
> - Why is the generic timer using this address ? isn't it reserving a too 
> wide portion of IO ports ? Should it be modified for this board ?

It just reserved the entire chip space since way back when.

> -  If there's a good reason for the timer to request this address, is  
> there a clean way to share it with the timer ?

Submit a small patch to Linus/Andrew to make the generic code only
reserve the ports it should. It's just a historical oversight

[PATCH] Reserve only needed regions for PC timers on i386 and x86_64

[Charles-Edouard Ruault]

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

Alan Cox wrote:

>On Llu, 2005-02-07 at 09:29, Charles-Edouard Ruault wrote:
>  
>
>>- Why is the generic timer using this address ? isn't it reserving a too 
>>wide portion of IO ports ? Should it be modified for this board ?
>>    
>>
>
>It just reserved the entire chip space since way back when.
>
>  
>
>>-  If there's a good reason for the timer to request this address, is  
>>there a clean way to share it with the timer ?
>>    
>>
>
>Submit a small patch to Linus/Andrew to make the generic code only
>reserve the ports it should. It's just a historical oversight
>
>  
>
Linus, Andrew,
As suggested by Alan, here's a small patch against kernel 2.4.29 to 
split the IO addresses reserved for the  PC timer into two regions 
instead of a large one.
It mimics what has been done in kernel 2.6.
Instead of reserving 0x40 through 0x5f it reserves only what the two 
timers need, i.e 0x40-0x43 and 0x50-0x53.
It patches both i386 and x86_64 architecture.

Please CC me in replies since i did not subscribe to the list.

-- 
Charles-Edouard Ruault
Idtect SA
115 rue Reaumur - 75002, Paris, France
Tel: +33-1-55-34-76-65
Fax: +33-1-55-34-76-75
Web: http://www.idtect.com


[-- Attachment #2: i386-x86_64-timer.patch --]
[-- Type: text/plain, Size: 1104 bytes --]

--- linux/arch/i386/kernel/setup.c.orig	Fri Feb 18 18:46:55 2005
+++ linux/arch/i386/kernel/setup.c	Mon Feb 21 11:19:45 2005
@@ -354,7 +354,8 @@
 struct resource standard_io_resources[] = {
 	{ "dma1", 0x00, 0x1f, IORESOURCE_BUSY },
 	{ "pic1", 0x20, 0x3f, IORESOURCE_BUSY },
-	{ "timer", 0x40, 0x5f, IORESOURCE_BUSY },
+	{ "timer0", 0x40, 0x43, IORESOURCE_BUSY },
+	{ "timer1", 0x50, 0x53, IORESOURCE_BUSY },
 	{ "keyboard", 0x60, 0x6f, IORESOURCE_BUSY },
 	{ "dma page reg", 0x80, 0x8f, IORESOURCE_BUSY },
 	{ "pic2", 0xa0, 0xbf, IORESOURCE_BUSY },
--- linux/arch/x86_64/kernel/setup.c.orig	Mon Feb 21 11:56:11 2005
+++ linux/arch/x86_64/kernel/setup.c	Mon Feb 21 11:54:41 2005
@@ -93,7 +93,8 @@
 struct resource standard_io_resources[] = {
 	{ "dma1", 0x00, 0x1f, IORESOURCE_BUSY },
 	{ "pic1", 0x20, 0x3f, IORESOURCE_BUSY },
-	{ "timer", 0x40, 0x5f, IORESOURCE_BUSY },
+	{ "timer0", 0x40, 0x43, IORESOURCE_BUSY },
+	{ "timer1", 0x50, 0x53, IORESOURCE_BUSY },
 	{ "keyboard", 0x60, 0x6f, IORESOURCE_BUSY },
 	{ "dma page reg", 0x80, 0x8f, IORESOURCE_BUSY },
 	{ "pic2", 0xa0, 0xbf, IORESOURCE_BUSY },

Re: [PATCH] Reserve only needed regions for PC timers on i386 and x86_64

[Marcelo Tosatti]

On Mon, Feb 21, 2005 at 02:06:18PM +0100, Charles-Edouard Ruault wrote:
> Alan Cox wrote:
> >On Llu, 2005-02-07 at 09:29, Charles-Edouard Ruault wrote:
> >>- Why is the generic timer using this address ? isn't it reserving a too 
> >>wide portion of IO ports ? Should it be modified for this board ?
> >
> >It just reserved the entire chip space since way back when.
> >>-  If there's a good reason for the timer to request this address, is  
> >>there a clean way to share it with the timer ?
> >
> >Submit a small patch to Linus/Andrew to make the generic code only
> >reserve the ports it should. It's just a historical oversight
> >
> > 
> >
> Linus, Andrew,
> As suggested by Alan, here's a small patch against kernel 2.4.29 to 
> split the IO addresses reserved for the  PC timer into two regions 
> instead of a large one.
> It mimics what has been done in kernel 2.6.
> Instead of reserving 0x40 through 0x5f it reserves only what the two 
> timers need, i.e 0x40-0x43 and 0x50-0x53.
> It patches both i386 and x86_64 architecture.

Applied, 

Thanks Charles.

> --- linux/arch/i386/kernel/setup.c.orig	Fri Feb 18 18:46:55 2005
> +++ linux/arch/i386/kernel/setup.c	Mon Feb 21 11:19:45 2005
> @@ -354,7 +354,8 @@
>  struct resource standard_io_resources[] = {
>  	{ "dma1", 0x00, 0x1f, IORESOURCE_BUSY },
>  	{ "pic1", 0x20, 0x3f, IORESOURCE_BUSY },
> -	{ "timer", 0x40, 0x5f, IORESOURCE_BUSY },
> +	{ "timer0", 0x40, 0x43, IORESOURCE_BUSY },
> +	{ "timer1", 0x50, 0x53, IORESOURCE_BUSY },
>  	{ "keyboard", 0x60, 0x6f, IORESOURCE_BUSY },
>  	{ "dma page reg", 0x80, 0x8f, IORESOURCE_BUSY },
>  	{ "pic2", 0xa0, 0xbf, IORESOURCE_BUSY },
> --- linux/arch/x86_64/kernel/setup.c.orig	Mon Feb 21 11:56:11 2005
> +++ linux/arch/x86_64/kernel/setup.c	Mon Feb 21 11:54:41 2005
> @@ -93,7 +93,8 @@
>  struct resource standard_io_resources[] = {
>  	{ "dma1", 0x00, 0x1f, IORESOURCE_BUSY },
>  	{ "pic1", 0x20, 0x3f, IORESOURCE_BUSY },
> -	{ "timer", 0x40, 0x5f, IORESOURCE_BUSY },
> +	{ "timer0", 0x40, 0x43, IORESOURCE_BUSY },
> +	{ "timer1", 0x50, 0x53, IORESOURCE_BUSY },
>  	{ "keyboard", 0x60, 0x6f, IORESOURCE_BUSY },
>  	{ "dma page reg", 0x80, 0x8f, IORESOURCE_BUSY },
>  	{ "pic2", 0xa0, 0xbf, IORESOURCE_BUSY },