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
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
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.
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
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
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
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
--- 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 },
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 },