Re: [PATCH 0/9] staging: comedi: addi_apci_1564: additional clean up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday, October 21, 2014 9:29 AM, Ian Abbott wrote:
> On 20/10/14 18:57, H Hartley Sweeten wrote:
>> This driver currently passes the timer "channel" in a manner that violates
>> the comedi API. Fix the timer subdevice so that the timers "channels" are
>> correctly used from the insn->chanspec.
>>
>> Fix the I/O access for the boards registers. Currently the iobase used to
>> access the counters and the main board registers are incorrect. According
>> to the ADDI-DATA datasheet the PCI BARs are:
>>
>>    PCI BAR0 - amcc chip registers
>>    PCI BAR1 - main board registers
>>    PCI BAR2 - counter registers

Ian,

Looking over the current driver I think the BAR mapping above is
correct.

There are a number of inconsistencies in the driver right now.

In apci1564_interrupt() the devpriv->amcc_iobase (BAR0) is used
to access one of the AMCC registers:

	/* check interrupt is from this device */
	if ((inl(devpriv->amcc_iobase + AMCC_OP_REG_INTCSR) &
	     INTCSR_INTR_ASSERTED) == 0)
		return IRQ_NONE;

That seems to indicate that the AMCC PCI registers are mapped to
BAR0, which matches the AMCC datasheet. That BAR could then
not be used to access the boards registers.

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.

I have sent an email to ADDI-DATA asking for clarification.

Regards,
Hartley

_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux