OF PCI howto?

[Grant Likely]

On Thu, Apr 16, 2009 at 3:03 AM, Roderick Colenbrander
<thunderbird2k at gmail.com> wrote:
> On Thu, Apr 16, 2009 at 10:05 AM, Joakim Tjernlund
> <Joakim.Tjernlund at transmode.se> wrote:
>> Kumar Gala <galak at kernel.crashing.org> wrote on 15/04/2009 17:20:21:
>>> On Apr 15, 2009, at 8:08 AM, Wolfram Sang wrote:
>>>
>>> > On Wed, Apr 15, 2009 at 02:54:57PM +0200, Joakim Tjernlund wrote:
>>> >
>>> >> dts fragment correct for my setup? If not, is there a better
>>> >> example I can
>>> >> look at?
>>> >
>>> > Maybe this message/thread can help you:
>>> >
>>> > http://ozlabs.org/pipermail/devicetree-discuss/2009-March/000597.html
>>>
>>> You may also want to take a look at ePAPR on the power.org site
>>
>> Thanks guys
>>
>> Looking in ePAPR I see I should read the IDSEL like this:
>>                /* IDSEL 0x11 AD17 */
>>                0x8800 0x0 0x0 0x1 &ipic 20 0x8 /* INTA */
>>                0x8800 0x0 0x0 0x2 &ipic 21 0x8 /* INTB */
>>                0x8800 0x0 0x0 0x3 &ipic 22 0x8 /* INTC */
>>                0x8800 0x0 0x0 0x4 &ipic 23 0x8 /* INTD */
>>
>> grouping the first line into:
>> "0x8800 0x0 0x0" "0x1" "&ipic" "20 0x8" /* INTA */
>>
>> "0x8800 0x0 0x0" = child unit address
>> "0x1" = child interrupt specifier = INTA
>> "&ipic" = interrupt parent
>> "20 0x8" = parent interrupt specifier
>>
>> Questions:
>>  MPC832x appears to only have INTA so why are the INTB,INTC
>>  and INTD lines there?
>>
>>  I don't understand how IDSEL values are decided. Are IDSEL 0x11-0x18
>> randomly
>>  selected or are they fixed for MPC832x?
>
> The idsel values depend on how the pci slots are wired on your board.
> The 0x8800 value is
> in general a function of bus, device and function number. ( bus << 16
> | devfn << 8)
>
> Further I would also watch out with the parent interrupt specifier
> e.g. '20 0x8'. The openfirmware spec
> normally suggests to use a value of '2' for interrupts which are
> active low. During parsing of the interrupt-map
> this value is normally translated using 'xlate' to linux kernel values
> (active low is defined as IRQ_TYPE_LEVEL_LOW      0x00000008 in the
> kernel).
> The ipic driver code and various dts files are evil and store the
> linux kernel value inside the DTS file, so they don't do any
> conversion whis is EVIL
> in my opinion. Watch out for that.

They're just numbers and they are intended to by interrupt controller
specific values.  Some IRQ controllers don't even have a 'flags' field
for instance.  The binding author is free to choose values he or she
deems suitable for the purpose as long as it is documented and
reviewed.

> (The corresponding DTS files and
> drivers should be updated).

No.  The binding is set.  We've made a commitment to not change
bindings after they are defined and deployed.  In some cases it is not
easy to update the device tree blob in deployed systems.


>
> Regards,
> Roderick Colenbrander
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.