On Wednesday, October 22, 2014 4:09 AM, Ian Abbott wrote:
> On 21/10/14 18:15, Hartley Sweeten wrote:
>> In addition, in apci1564_interrupt() the dev->iobase (BAR1) is used for:
>>
>> s->state = inl(dev->iobase + APCI1564_DI_INT_STATUS_REG) & 0xffff;
>>
>> But is apci1564_reset() and apci1564_cos_insn_config() that register
>> is accessed using devpriv->amcc_iobase (BAR0):
>>
>> inl(devpriv->amcc_iobase + APCI1564_DI_INT_STATUS_REG);
>>
>> The register should not be accessible from both BARs so BAR1 must be
>> the real base address for the boards main registers.
>>
>> dev->iobase (BAR1) is currently used to access the counter register
>> (other than the one access to APCI1564_DI_INT_STATUS_REG listed
>> above). The mapping of those registers would overlay the boards main
>> registers so my guess is they should really use BAR2 as the base address.
>>
>> I need to dig thru the git history to see if the screw up was
>> caused by various patches to the driver or if the problem
>> existed from when it was initially merged.
>
> Looks like commit 860ba36cbeadee9064e2925be11dfb8368b9b25d ("staging:
> comedi: addi_apci_1564: move apci1564_interrupt() into
> addi_apci_1564.c") is the culprit.
Ian,
I finally got the correct information on the PCI BARs from ADDI-DATA.
It appears that this board has always used an FPGA with a PCI core so
the AMCC stuff in the driver is completely wrong.
In addition, there are two major revisions of the board and they have
different I/O mapping. The driver is currently coded to support the
Rev 2.x versions of the board (other than the AMCC stuff).
Greg just applied a slew of comedi patches. After they hit linux-next
I will post a series to fix the APCI-1564.
Regards,
Hartley
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
