On Thu, Apr 16, 2009 at 3:03 AM, Roderick Colenbrander <[email protected]> wrote: > On Thu, Apr 16, 2009 at 10:05 AM, Joakim Tjernlund > <[email protected]> wrote: >> Kumar Gala <[email protected]> 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 > [email protected] > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-dev
