Re: sja1000 interrupt problem

[Oliver Hartkopp <socketcan@hartkopp.net>]

Ok. I think I got it now:

As long as the PCAN PCI adapter had only 2 channels PEAK obviously used the
PSB4600 PITA v1.2 (1-pita_12p.pdf) where there are two interrupt lines INT0
and INT1 accessible by bit 0 and bit 1 in the ICR register (see page 191).

Due to the discontinuation of the PSB4600 in newer designs there's a Lattice
4256V CPLD, see detail photo at

	http://gridconnect.com/pcan/can-adapters/can-mini-pci.html

The CPLD now obviously uses the formerly reserved bits 6+7 for the channels
3+4 in a backward compatible manner. So everything with peak_pci_icr_masks[]
is fine but it's no real PITA anymore :-)

Sorry for the confusion.

Looks like there's some more investigation of the -rt irq threads to do :-(

Regards,
Oliver


On 13.12.2013 22:14, Oliver Hartkopp wrote:
> Hi all,
> 
> after some more investigation of the two PITA specifications
> 
> https://www.google.de/#q=PCI+Interface+for+Telephony+infineon
> 
> http://pdf.datasheetcatalog.com/datasheet/infineon/1-pita_22p.pdf
> 
> and
> 
> http://pdf.datasheetcatalog.com/datasheet/infineon/1-pita_12p.pdf
> 
> I'm not sure *why* the driver works at all.
> 
> It's the mix between byte and word accesses and especially the per-device
> interrupt bits in the PITA_ICR (Interrupt Control Register).
> 
> The interrupt bits in this register GP[0123]_INT are located in the bits
> 2,3,4,5 in the ICR (1-pita_12p.pdf, p. 191 / 1-pita_22p.pdf p.202)
> 
> If my interpretation is correct the
> 
> 	static const u16 peak_pci_icr_masks[PEAK_PCI_CHAN_MAX] = {
>         	0x02, 0x01, 0x40, 0x80
> 	};
> 
> would be completely bogus and would not hit the right bit in
> 
> static void peak_pci_post_irq(const struct sja1000_priv *priv)
> {
>         struct peak_pci_chan *chan = priv->priv;
>         u16 icr;
> 
>         /* Select and clear in PITA stored interrupt */
>         icr = readw(chan->cfg_base + PITA_ICR);
>         if (icr & chan->icr_mask)
>                 writew(chan->icr_mask, chan->cfg_base + PITA_ICR);
> }
> 
> at all.
> 
> Am I wrong? Or is this the wrong specification?
> The code in ems_pci.c seems to fit to this PITA spec ...
> 
> Regards,
> Oliver
> 
> 
> On 13.12.2013 18:14, Oliver Hartkopp wrote:
>> Answering myself ...
>>
>>>
>>> Maybe it's time to look into other implementations than PEAK/mainline ...
>>>
>>
>> E.g. a EMS_PCI adapter has a PITA-2 too (depending on it's HW revicsion).
>> There's a EMS PCI driver in mainline and (at least) can4linux.
>>
>> Both access the registers with 32 bit read/write functions but the peak_pci
>> only writes 16 bit values?!?
>>
>> Checking
>>
>> 	http://pdf.datasheetcatalog.com/datasheet/infineon/1-pita_22p.pdf
>>
>> 32 bit should be the right way to do it.
>>
>> Regards,
>> Oliver
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-can" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>