Unanswered topics | Active topics


Board index » »

All times are UTC-06:00



Post new topic  Reply to topic  Page 1 of 1
  [ 13 posts ] 
  Previous topic | Next topic 
Author Message
rjs
PostPosted: Mon Jun 30, 2008 6:12 pm 
Offline

Joined: Wed May 10, 2006 9:55 am
Posts: 7
Location: Manchester, UK
Is there any reason why device tree entries that are generated for PCI cards on Efika don't use the same three cell encoding as the builtin devices ?

I have a RealTek card in the PCI slot which is given the following device tree properties:
Code:
vendor-id 0x10EC (4332)
device-id 0x8139 (33081)
revision-id 0x10 (16)
class-code 0x20000 (131072)
subsystem-id 0x10EC (4332)
subsystem-vendor-id 0x8139 (33081)
.vendor-name "Realtek"
.part-number "RT8139A/B/C"
.description "Fast Ethernet Adapter"
.class "Network Controller"
.subclass "Ethernet"
interrupts 0x1 (1)
devsel-speed 0x1 (1)
fast-back-to-back
min-grant 0x20 (32)
max-latency 0x40 (64)
cache-line-size 0x20 (32)
name "ethernet"
reg 18:0
i18,0,10,0:100
m18,0,14,0:100
assigned-addresses i18,0,10,F8001000:100
m18,0,14,80000000:100
I would have expected to see 1 16 3 as the value of "interrupts".
Top
   
Reply with quote  
Neko
PostPosted: Tue Jul 01, 2008 9:06 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
Is there any reason why device tree entries that are generated for PCI cards on Efika don't use the same three cell encoding as the builtin devices ?

I have a RealTek card in the PCI slot which is given the following device tree properties:
Code:
interrupts 0x1 (1)
I would have expected to see 1 16 3 as the value of "interrupts".
You might, if it was reporting which SIU interrupt was firing, but this is a PCI interrupt and as far as I recall it corresponds to the single PCI interrupt line on the MPC5200B. By some magic this is resolved by PCI support in the OS.

_________________
Matt Sealey
Top
   
Reply with quote  
rjs
PostPosted: Tue Jul 01, 2008 12:14 pm 
Offline

Joined: Wed May 10, 2006 9:55 am
Posts: 7
Location: Manchester, UK
Quote:
Quote:
Is there any reason why device tree entries that are generated for PCI cards on Efika don't use the same three cell encoding as the builtin devices ?

I have a RealTek card in the PCI slot which is given the following device tree properties:
Code:
interrupts 0x1 (1)
I would have expected to see 1 16 3 as the value of "interrupts".
You might, if it was reporting which SIU interrupt was firing, but this is a PCI interrupt and as far as I recall it corresponds to the single PCI interrupt line on the MPC5200B. By some magic this is resolved by PCI support in the OS.
Ok, but I can't find anything in the interrupt-map property of the "pci" node that will map from "1" onto the corresponding SIU interrupt.

The pci node properties are:
Code:
name "pci"
device_type "pci"
#address-cells 0x3 (3)
#size-cells 0x2 (2)
clock-frequency 0x1F78A40 (33000000)
ranges [0x30 bytes]
[000] 01000000 00000000 00000000 F8000000
[010] 00000000 00010000 02000000 00000000
[020] 80000000 80000000 00000000 40000000

reg 80000000:40000000
#interrupt-cells 0x1 (1)
interrupt-map-mask [0x10 bytes]
[000] 00000000 00000000 00000000 00000007

bus-range 0:1
interrupt-map [0x20 bytes]
[000] 0000C000 00000000 00000000 00000001
[010] 07C57D28 00000000 00000000 00000003
Should the second line of interrupt-map read:
Code:
[010] 07C57D28 00000001 00000010 00000003
I thought that the idea behind the device tree was to avoid the need for any magic in the OS. I know that Linux just has conversion tables for each platform, I was trying to avoid that.
Top
   
Reply with quote  
rjs
PostPosted: Tue Jul 01, 2008 12:31 pm 
Offline

Joined: Wed May 10, 2006 9:55 am
Posts: 7
Location: Manchester, UK
Quote:
Should the second line of interrupt-map read:
Code:
[010] 07C57D28 00000001 00000010 00000003
Ignore this bit, I have read the Interrupt Mapping document a bit more carefully.
Top
   
Reply with quote  
Neko
PostPosted: Tue Jul 01, 2008 1:20 pm 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
I thought that the idea behind the device tree was to avoid the need for any magic in the OS. I know that Linux just has conversion tables for each platform, I was trying to avoid that.
interrupt-map and interrupt-map-mask are exactly the magic I was talking about.

I'm not sure where you got the 1 10 3 interrupt number expecations from?

_________________
Matt Sealey
Top
   
Reply with quote  
rjs
PostPosted: Tue Jul 01, 2008 1:29 pm 
Offline

Joined: Wed May 10, 2006 9:55 am
Posts: 7
Location: Manchester, UK
Quote:
I'm not sure where you got the 1 10 3 interrupt number expecations from?
My suggestion for the interrupt-map contents was in hex. I had read the thread on initializing the CAN controllers and followed the link to here.

What document should we read to work out how to decode the device tree ?
Top
   
Reply with quote  
Neko
PostPosted: Thu Jul 03, 2008 6:07 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
Quote:
I'm not sure where you got the 1 10 3 interrupt number expecations from?
My suggestion for the interrupt-map contents was in hex. I had read the thread on initializing the CAN controllers and followed the link to here.
1-10-3 would be a Main level interrupt, that doesn't match my docs on what fires for PCI...
Quote:
What document should we read to work out how to decode the device tree ?
Now you ask, I am not sure any of the documentation makes sense anymore. I just had a look for the documentation on the interrupt-#? properties and I can't find it anymore.. sigh.

If anyone a little more kernel-hacky than me wants to have a go at this, feel free :(

_________________
Matt Sealey
Top
   
Reply with quote  
rjs
PostPosted: Thu Jul 03, 2008 10:17 am 
Offline

Joined: Wed May 10, 2006 9:55 am
Posts: 7
Location: Manchester, UK
Quote:
Quote:
Quote:
I'm not sure where you got the 1 10 3 interrupt number expecations from?
My suggestion for the interrupt-map contents was in hex. I had read the thread on initializing the CAN controllers and followed the link to here.
1-10-3 would be a Main level interrupt, that doesn't match my docs on what fires for PCI...
An encoding of 0x1 0x10 0x3 would be Main level interrupt #16 - external IRQ1. PCI card interrupts are connected to this pin on the Lite5200 and on EFIKA.
Quote:
Quote:
What document should we read to work out how to decode the device tree ?
Now you ask, I am not sure any of the documentation makes sense anymore. I just had a look for the documentation on the interrupt-#? properties and I can't find it anymore.. sigh.

If anyone a little more kernel-hacky than me wants to have a go at this, feel free :(
It isn't really anything to do with the kernel, just down to whether the device tree reflects the design of your board.
Top
   
Reply with quote  
Neko
PostPosted: Thu Jul 03, 2008 3:12 pm 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
It isn't really anything to do with the kernel, just down to whether the device tree reflects the design of your board.
It does, or it just wouldn't work? :)

Where did you find the interrupt mapping documentation, for reference? Posting it to this thread means people can search for it.. :)

_________________
Matt Sealey
Top
   
Reply with quote  
rjs
PostPosted: Thu Jul 03, 2008 8:19 pm 
Offline

Joined: Wed May 10, 2006 9:55 am
Posts: 7
Location: Manchester, UK
Quote:
Quote:
It isn't really anything to do with the kernel, just down to whether the device tree reflects the design of your board.
It does, or it just wouldn't work? :)
As I wrote a few messages back, the source you distribute for Linux does not read this information from the device tree, it is just hard-wired when compiled for EFIKA. I'm not running Linux, I am porting NetBSD to it and want to know whether I should be able to pull all the configuration info from the device tree.
Quote:
Where did you find the interrupt mapping documentation, for reference? Posting it to this thread means people can search for it.. :)
I found some initial pointers here then found a draft interrupt mapping document here which does seem to match most of what is on the EFIKA.
Top
   
Reply with quote  
Neko
PostPosted: Fri Jul 04, 2008 2:30 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
As I wrote a few messages back, the source you distribute for Linux does not read this information from the device tree, it is just hard-wired when compiled for EFIKA. I'm not running Linux, I am porting NetBSD to it and want to know whether I should be able to pull all the configuration info from the device tree.
You're looking at the 2.6.19 kernel on http://www.efika.de/?

I am surprised to hear it is hardcoded in this way. Perhaps it was to get a quick start but then has been replaced by more generic means in the next versions.. have you checked the mainline?

_________________
Matt Sealey
Top
   
Reply with quote  
rjs
PostPosted: Fri Jul 04, 2008 10:01 am 
Offline

Joined: Wed May 10, 2006 9:55 am
Posts: 7
Location: Manchester, UK
Quote:
Quote:
As I wrote a few messages back, the source you distribute for Linux does not read this information from the device tree, it is just hard-wired when compiled for EFIKA. I'm not running Linux, I am porting NetBSD to it and want to know whether I should be able to pull all the configuration info from the device tree.
You're looking at the 2.6.19 kernel on http://www.efika.de/?

I am surprised to hear it is hardcoded in this way. Perhaps it was to get a quick start but then has been replaced by more generic means in the next versions.. have you checked the mainline?
I had a look at 2.6.25.10, it does read the PCI interrupt mapping from the device tree. Does this kernel work correctly on EFIKA ?
Top
   
Reply with quote  
Neko
PostPosted: Fri Jul 04, 2008 11:16 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
I had a look at 2.6.25.10, it does read the PCI interrupt mapping from the device tree. Does this kernel work correctly on EFIKA ?
2.6.25.5 does, as implemented in openSUSE 11.0

I doubt PCI support for Efika has been touched since 2.6.21.

_________________
Matt Sealey
Top
   
Reply with quote  
Display posts from previous:  Sort by  
Post new topic  Reply to topic  Page 1 of 1
  [ 13 posts ] 

Board index » »

All times are UTC-06:00

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
PowerDeveloper.org: Copyright © 2004-2012, Genesi USA, Inc. The Power Architecture and Power.org wordmarks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org.
All other names and trademarks used are property of their respective owners. Privacy Policy
Powered by phpBB® Forum Software © phpBB Group