Comedi Driver with LPCIe-7250 problem

[Gus Cerda]

Hi all,

I'm working with ADlink LPCIe-7250 and comedi drivers, the driver loads correctly:

root@tramuntana:~# lspci | grep -i adlink

41:00.0 DPIO module: Adlink Technology PCI-7250 (rev 01)

root@tramuntana:~# dmesg | grep comedi

[    3.136992] comedi: loading out-of-tree module taints kernel.

[    3.143073] comedi: version 0.7.76.1 - http://www.comedi.org

[    3.162617] comedi0: adl_pci7250

[    3.162799] comedi: base addr 92001000

[    3.162804] comedi: attached

But when I try to capture channel 0 with this sample code:

#include <comedilib.h>
#include <stdio.h>
int main()
{
        comedi_t *dev = comedi_open("/dev/comedi0");
        if (!dev) { perror("comedi_open");
        return 1;
         }
        int value;
        comedi_dio_read(dev, 1, 0, &value); // Read subdevice 1, channel 0
        printf("Input value: %d\n", value);
        comedi_close(dev);
        return 0;
}

I'm always receiving a "1", independently of applying voltage or not to the input. 

The card works fine in windows environment, for this input.

Could someone give me an advice or something to look in order to make the card work under Linux?

Thank you in advance.

[Gus Cerda]

This is the output of comedi_test:

tramuntana:~/comedi_prova$ comedi_test
I: Comedi version: 0.7.76
I: Comedilib version: unknown =)
I: driver name: adl_pci7250
I: device name: pci7250
I:
I: subdevice 0
I: testing info...
rev 1
I: subdevice type: 4 (digital output)
  number of channels: 32
  max data value: 1
  ranges:
    all chans: [0,5]
I: testing insn_read...
rev 1
comedi_do_insn returned 1, good
I: testing insn_read_0...
comedi_do_insn returned 0, good
I: testing insn_read_time...
rev 1
comedi_do_insn: 3
read time: 1 us
I: testing cmd_no_cmd...
got EIO, good
I: testing cmd_probe_src_mask...
not applicable
I: testing cmd_probe_fast_1chan...
not applicable
I: testing cmd_read_fast_1chan...
not applicable
I: testing cmd_write_fast_1chan...
not applicable
I: testing cmd_logic_bug...
not applicable
I: testing cmd_fifo_depth_check...
not applicable
I: testing cmd_start_inttrig...
not applicable
I: testing mmap...
not applicable
I: testing read_select...
not applicable
I: testing bufconfig...
buffer length is 0, good
I:
I: subdevice 1
I: testing info...
rev 1
I: subdevice type: 3 (digital input)
  number of channels: 32
  max data value: 1
  ranges:
    all chans: [0,5]
I: testing insn_read...
rev 1
comedi_do_insn returned 1, good
I: testing insn_read_0...
comedi_do_insn returned 0, good
I: testing insn_read_time...
rev 1
comedi_do_insn: 3
read time: 4 us
I: testing cmd_no_cmd...
got EIO, good
I: testing cmd_probe_src_mask...
not applicable
I: testing cmd_probe_fast_1chan...
not applicable
I: testing cmd_read_fast_1chan...
not applicable
I: testing cmd_write_fast_1chan...
not applicable
I: testing cmd_logic_bug...
not applicable
I: testing cmd_fifo_depth_check...
not applicable
I: testing cmd_start_inttrig...
not applicable
I: testing mmap...
not applicable
I: testing read_select...
not applicable
I: testing bufconfig...
buffer length is 0, good

[Ian Abbott]

Hi Gus,

Apparently, I wrote this driver in 2015 (which was a surprise to me as I'd forgotten writing it!), based on the fairly simple register layout from the user manual, but I didn't test it myself. It was reported working by Emma Peace in this email:

https://groups.google.com/g/comedi_list/c/RaQGeavOr0U/m/aa-EadJxy8AJ

She wrote that she had tested input and output fairly heavily without any problems.

I don't know why it is not working for you. It's a fairly simple driver.

Could you try reading all dio inputs at once as a bitmask using the following sample code?

#include <comedilib.h>
#include <stdio.h>
int main()
{
        comedi_t *dev = comedi_open("/dev/comedi0");
        if (!dev) { perror("comedi_open");
        return 1;
         }
        unsigned int bits;
        comedi_dio_bitfield(dev, 1, 0, &bits); // Get bits from subdevice 1
        printf("Input bits: 0x%08X\n", bits);
        comedi_close(dev);
        return 0;
}

This will read all 32 digital inputs as a 32-bit value, although only channels 0 to 7 will be valid on the LPCIe-7250. (The other 24 channels are for the PCI-7250 with PCI-7251 extension cards fitted.) These 32 inputs are read from register offsets 1, 3, 5, and 7, 8 bits per register. (Register offsets 0, 2, 4, and 6, 8 bits per register are used to control the relays.)

Looking at the manual, one other thing to check is that the input signal jumpers JP1 to JP8 on the board are set to position 2-3 for Non-AC-Filter (DC signal), although it's probably OK as you already tested the input in Windows.

I should really port this driver (assuming it is not completely broken) for inclusion in the Linux kernel. I probably meant to do that 10 years ago!

Thank you in advance.

I hope you manage to get it working!

Ian

-- 
-=( Ian Abbott <abb...@mev.co.uk> || MEV Ltd. is a company  )=-
-=( registered in England & Wales.  Regd. number: 02862268.  )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-

[Gus Cerda]

Hi Ian,

This is the output without any input signals:

Input bits: 0x000000C1

Exciting some inputs doesn't make a difference. Any further test that I can make to check any incompatibility with current Kernels?

Thank you so much!!

[Ian Abbott]

On 27/05/2025 13:37, Gus Cerda wrote:

Hi Ian,

This is the output without any input signals:

Input bits: 0x000000C1

Exciting some inputs doesn't make a difference. Any further test that I can make to check any incompatibility with current Kernels?

I do sometimes have to update the comedi module sources in the Git repository to get them to build properly when new versions of the kernel are released, but that is normal for out-of-tree Linux kernel module development, and I don't think that's the problem here. Some distros include pre-built comedi modules in their kernel packages, in which case it is important not to mix and match the comedi modules from the Linux kernel image with the comedi modules built from Comedi's git repository, due to kernel API differences between the two sets of modules. The usual symptom in that case is that the low-level comedi driver module fails to load, but it could also result in kernel OOPS messages.

It's interesting that some of the inputs are reading low, and some of them are reading high, which is normal for floating inputs. But it does suggest that its reading something.

Are the relay channels on subdevice 0 working? The relay channels are both readable and writeable. Assuming all the relays are de-energized on power up, I would expect the relay channels to read back as 0 until they written, and turning single relay channels on or off should not affect the other relays.

Ian

--
You received this message because you are subscribed to the Google Groups "Comedi: Linux Control and Measurement Device Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to comedi_list...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/comedi_list/eb9922e1-5c85-4f96-a4d0-1972be315604n%40googlegroups.com.

[Gus Cerda]

Hi again,

In a fresh boot state, the output for the test program you send me is:

 
Input bits: 0x000000C0

Only when I try to activate a relay on subdevice 0, the state of the inputs change to:

 Input bits: 0x000000C1

But the relay is not working, I can't hear the sound of the relay commuting. 

The initial relay values on a fresh boot are the following:

Relay values: 0x00000000 

Input bits: 0x000000C0

When you write to all the outputs you can see this:

Relay values: 0x000000FF

Input bits: 0x000000C1

But no relays change is noticed, no sound and tester doesn't show continuity between NO and COM pins. 

If you change relay values to 0 another time I realized that the input bits maintain the values until reboot, this is the result:

Relay values: 0x00000000

Input bits: 0x000000C1

Could be that the register offsets have changed on a revision of the card?

Is there any method to check it?

Thank you.

[Ian Abbott]

On 28/05/2025 11:36, Gus Cerda wrote:

Hi again,

In a fresh boot state, the output for the test program you send me is:

 
Input bits: 0x000000C0

Only when I try to activate a relay on subdevice 0, the state of the inputs change to:

 Input bits: 0x000000C1

But the relay is not working, I can't hear the sound of the relay commuting. 

The initial relay values on a fresh boot are the following:

Relay values: 0x00000000 

Input bits: 0x000000C0

When you write to all the outputs you can see this:

Relay values: 0x000000FF

Input bits: 0x000000C1

But no relays change is noticed, no sound and tester doesn't show continuity between NO and COM pins. 

If you change relay values to 0 another time I realized that the input bits maintain the values until reboot, this is the result:

Relay values: 0x00000000

Input bits: 0x000000C1

Could be that the register offsets have changed on a revision of the card?

Is there any method to check it?

That's all pretty weird. I don't think the register offsets will have have changed unless there was some reason to do so, such as PCI bridge chips going obsolete. I assume your card has the two PLX chips pictured here (the small PEX 8112, and the large PLX PCI-9052):

Basically, that's a cost-reduced version of the original ADLINK PCI-7250 (with extra connectors for the PCI-7250 extension cards removed), placed behind a PCIe-to-PCI bridge (the PLX PEX-8112 chip). The PLX PCI-9052 chip is the one that maps PCI base address region 2 to the local bus registers, with the logic for handling the individual registers controlled by some of the other chips.

I've managed to find an original PCI-7250 going very cheap (about £17 UK) on eBay, so have bought it. (My current work PC is old enough to still have some PCI slots!)

ADLINK do have some software for Ubuntu that works with very specific kernel versions, but with no source code at all provided. Still, I may be able to disassemble the code to try and work out what it's doing.

Ian

To view this discussion visit https://groups.google.com/d/msgid/comedi_list/75a066da-d8f3-437c-8cb1-e27c30d217f5n%40googlegroups.com.

[Gus Cerda]

Hi Ian,

I can't find the chips you suggested, I'm sending you a pictures our card:

It seems something has changed.

Thank you very much!!

[Ian Abbott]

It looks like they have replaced the two PLX PCIe/PCI/local bus chips and the internal card logic with a Lattice FPGA doing everything.

They might have changed the register layout. If they have changed the register layout but kept the same PCI vendor and PCI device ID, they should at least have changed the PCI subvendor ID or PCI subdevice ID, or possibly the PCI revision code, or PCI class code, or possibly changed the PCI BAR regions. In other words, they would need some way for their driver to differentiate it from the original board so can account for any changes to the register layout.

[Ian Abbott]

On 2025-05-29 10:49, Ian Abbott wrote:

On 2025-05-29 08:03, Gus Cerda wrote:

It seems something has changed.

It looks like they have replaced the two PLX PCIe/PCI/local bus chips and the internal card logic with a Lattice FPGA doing everything.

They might have changed the register layout. If they have changed the register layout but kept the same PCI vendor and PCI device ID, they should at least have changed the PCI subvendor ID or PCI subdevice ID, or possibly the PCI revision code, or PCI class code, or possibly changed the PCI BAR regions. In other words, they would need some way for their driver to differentiate it from the original board so can account for any changes to the register layout.

Speaking of which, it would be useful to dump the PCI config for this device:

$ lspci -v -n -d 0x144a:7250

I don't currently have an older device to compare it to though!

[Gus Cerda]

This is the information requested:

41:00.0 1100: 144a:7250 (rev 01)
        Subsystem: 144a:7000
        Flags: fast devsel, IRQ 242, IOMMU group 56
        Memory at 92002000 (32-bit, non-prefetchable) [size=256]
        Memory at 92001000 (32-bit, non-prefetchable) [size=256]
        Memory at 92000000 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>
        Kernel driver in use: adl_pci7250
        Kernel modules: adl_pci7250

[Gus Cerda]

Sorry, the same command as root:

41:00.0 1100: 144a:7250 (rev 01)
        Subsystem: 144a:7000
        Flags: fast devsel, IRQ 242, IOMMU group 56
        Memory at 92002000 (32-bit, non-prefetchable) [size=256]
        Memory at 92001000 (32-bit, non-prefetchable) [size=256]
        Memory at 92000000 (32-bit, non-prefetchable) [size=256]

        Capabilities: [50] Power Management version 3
        Capabilities: [70] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [90] Express Endpoint, MSI 00
        Capabilities: [100] Device Serial Number 00-00-00-00-00-00-00-00

        Kernel driver in use: adl_pci7250
        Kernel modules: adl_pci7250

[Ian Abbott]

On 2025-05-29 12:08, Gus Cerda wrote:

This is the information requested:

41:00.0 1100: 144a:7250 (rev 01)
        Subsystem: 144a:7000
        Flags: fast devsel, IRQ 242, IOMMU group 56
        Memory at 92002000 (32-bit, non-prefetchable) [size=256]
        Memory at 92001000 (32-bit, non-prefetchable) [size=256]
        Memory at 92000000 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>
        Kernel driver in use: adl_pci7250
        Kernel modules: adl_pci7250

OK, one change is that all three PCI BARs (0, 1, and 2) are using memory mapped I/O, but the driver is assuming that BAR 2 (the one that contained the DIO registers) uses port I/O. There might be other changes to the register layout.

Looking at the Windows driver .INF file, I can see that this new card's details where added during the last 10 years, and is tied specifically to the LPCIe-7250. That .INF file shows that previous iterations of the PCI-7250 family used the following IDs:

10b5:9050 subsystem 9999:7250 (very early, using PLX's vendor and device ID and a dubious looking subvendor ID 0x9999)
144a:7250 subsystem 9999:7250 (newer, using ADLINK's vendor ID, but still using a dodgy subvendor ID)
144a:7250 subsystem 144a:7250 (probably the newest, before the redesigned LPCIe-7250)

The Comedi driver will need changing to support the redesigned LPCIe-7250, once we've figured out the register layout.

Ian

El jueves, 29 de mayo de 2025 a las 12:10:36 UTC+2, Ian Abbott escribió:

On 2025-05-29 10:49, Ian Abbott wrote:

On 2025-05-29 08:03, Gus Cerda wrote:

It seems something has changed.

It looks like they have replaced the two PLX PCIe/PCI/local bus chips and the internal card logic with a Lattice FPGA doing everything.

They might have changed the register layout. If they have changed the register layout but kept the same PCI vendor and PCI device ID, they should at least have changed the PCI subvendor ID or PCI subdevice ID, or possibly the PCI revision code, or PCI class code, or possibly changed the PCI BAR regions. In other words, they would need some way for their driver to differentiate it from the original board so can account for any changes to the register layout.

Speaking of which, it would be useful to dump the PCI config for this device:

$ lspci -v -n -d 0x144a:7250

I don't currently have an older device to compare it to though!

-- 
-=( Ian Abbott <abb...@mev.co.uk> || MEV Ltd. is a company  )=-
-=( registered in England & Wales.  Regd. number: 02862268.  )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-

--

You received this message because you are subscribed to the Google Groups "Comedi: Linux Control and Measurement Device Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to comedi_list...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/comedi_list/575b57b0-afc9-4d5e-b48c-e2df411770e7n%40googlegroups.com.

[Ian Abbott]

On 29/05/2025 13:45, Ian Abbott wrote:

On 2025-05-29 12:08, Gus Cerda wrote:

This is the information requested:

41:00.0 1100: 144a:7250 (rev 01)
        Subsystem: 144a:7000
        Flags: fast devsel, IRQ 242, IOMMU group 56
        Memory at 92002000 (32-bit, non-prefetchable) [size=256]
        Memory at 92001000 (32-bit, non-prefetchable) [size=256]
        Memory at 92000000 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>
        Kernel driver in use: adl_pci7250
        Kernel modules: adl_pci7250

OK, one change is that all three PCI BARs (0, 1, and 2) are using memory mapped I/O, but the driver is assuming that BAR 2 (the one that contained the DIO registers) uses port I/O. There might be other changes to the register layout.

Looking at the Windows driver .INF file, I can see that this new card's details where added during the last 10 years, and is tied specifically to the LPCIe-7250. That .INF file shows that previous iterations of the PCI-7250 family used the following IDs:

10b5:9050 subsystem 9999:7250 (very early, using PLX's vendor and device ID and a dubious looking subvendor ID 0x9999)
144a:7250 subsystem 9999:7250 (newer, using ADLINK's vendor ID, but still using a dodgy subvendor ID)
144a:7250 subsystem 144a:7250 (probably the newest, before the redesigned LPCIe-7250)

The Comedi driver will need changing to support the redesigned LPCIe-7250, once we've figured out the register layout.

I have implemented an experimental change to try and support the newer LPCIe-7250 on branch wip-adl_pci7250-updates of the comedi git repository.

For now, I have assumed the registers are still in PCI BAR 2 and have the same layout as the older cards. The change detects whether PCI BAR 2 is port I/O based or memory based, maps memory based registers to virtual address space, and uses either the port I/O register access functions or the memory-mapped I/O register access functions depending on the type of registers.

It also limits the number of channels to 8 if the PCI subsystem device ID is 0x7000 (which is used by the newer LPCIe-7250 cards), since it cannot possibly have any PCI-7251 extension cards fitted to increase the number of channels in that case.

The assumptions I made about the PCI BAR and register layout may not be accurate, so please test and report your findings.

[Gus Cerda]

I can't test the card today, I will try to test it on monday. 

Have a good weekend!!

Thank you for all your effort.

[Der Alte]

Hi Folks, I'm just confused about the set of driver sources in the github Repo and the Linux 6.4.0 kernel:

single files for each card vs. adl_pci7x3x.c . Which concept is the modern way?

[Der Alte]

Hi Folks, in my 6.4.0 openSuse kernel tree there is a file named adl_pci_7x3x.c but no adl_pci7230.c, adl_pci7432.c and no adl_pci7250.c like in the github  Linux-CoMeDI repo.

I remember addint Interupt functionality "once" in adl_pci_7x3x.c and adv_pci_dio.c but can't remember the year in the moment.

Was the splitting done after that or before the IRQ add-on?

Seems like I missed someting.

Which concept is the more modern one? One driver for each card type or the collecting driver for a family of cards?

Ciao, Bernd

Gus Cerda schrieb am Mittwoch, 28. Mai 2025 um 12:36:50 UTC+2:

[Ian Abbott]

On 28/05/2025 13:03, Der Alte wrote:
> Hi Folks, in my 6.4.0 openSuse kernel tree there is a file named
> adl_pci_7x3x.c but no adl_pci7230.c, adl_pci7432.c and no adl_pci7250.c
> like in the github  Linux-CoMeDI repo.

The adl_pci7x3x.c in the kernel sources supports the cards that were
previously supported by adl_pci7230.c and adl_pci7432.c, but not
adl_pci7250.c. Support for the {L}PCI{e}-7250 cards is currently
missing from the kernel sources, but I plan to port the adl_pci7250
driver over from the Linux-CoMeDI repo. (It's only taken me 10 years to
get around to it, so far!) There are some recently discovered
incompatibilities with the latest hardware revisions of the LPCIe-7250
that need to be resolved first.

> I remember addint Interupt functionality "once" in adl_pci_7x3x.c and
> adv_pci_dio.c but can't remember the year in the moment.

You added interrupt handling into those files for the ADLINK PCI-7230
and the Advantech PCI-1730 back in early 2021 (kernel version 5.12).

> Was the splitting done after that or before the IRQ add-on?
> Seems like I missed someting.

Hartley Sweeten replaced adl_pci7230.c and adl_pci7432.c with
adl_pci7x3x.c in mid 2012 (kernel version 3.7).

> Which concept is the more modern one? One driver for each card type or
> the collecting driver for a family of cards?

In general, it depends how similar the cards are at the register level.
There is no hard and fast rule. It's a bit of a judgement call.

[Gus Cerda]

Hi Ian,

I tested all the inputs and now are working as expected.

Thank you very much for making this card work as well as the old version of the card.

I sincerely appreciate your help.

[Ian Abbott]

Hi Gus,

On 02/06/2025 10:19, Gus Cerda wrote:
> Hi Ian,
> I tested all the inputs and now are working as expected.
> Thank you very much for making this card work as well as the old
> version of the card.

Thanks for testing. Do the relays also work as expected? I'm guessing
they will, but it's nice to be sure!

My old-school PCI-7250 card has arrived from eBay, so I should be able
to check my change did not break anything for the older cards.

[Ian Abbott]

On 02/06/2025 12:36, Ian Abbott wrote:
> Hi Gus,
>
> On 02/06/2025 10:19, Gus Cerda wrote:
>> Hi Ian,
>> I tested all the inputs and now are working as expected.
>> Thank you very much for making this card work as well as the old
>> version of the card.
>
> Thanks for testing. Do the relays also work as expected? I'm guessing
> they will, but it's nice to be sure!
>
> My old-school PCI-7250 card has arrived from eBay, so I should be able
> to check my change did not break anything for the older cards.

Actually, it does look like I managed to break the relay handling code.
I'm working on it!

[Gus Cerda]

I'm testing relays, It seems that I can put it at HIGH state but I can't reverse it to the LOW state.

If I can help you with the tests let me know.

[Ian Abbott]

On 02/06/2025 13:38, Ian Abbott wrote:
> On 02/06/2025 12:36, Ian Abbott wrote:
>> Hi Gus,
>>
>> On 02/06/2025 10:19, Gus Cerda wrote:
>>> Hi Ian,
>>> I tested all the inputs and now are working as expected.
>>> Thank you very much for making this card work as well as the old
>>> version of the card.
>>
>> Thanks for testing. Do the relays also work as expected? I'm guessing
>> they will, but it's nice to be sure!
>>
>> My old-school PCI-7250 card has arrived from eBay, so I should be able
>> to check my change did not break anything for the older cards.
>
> Actually, it does look like I managed to break the relay handling code.
> I'm working on it!

It was a stupid, one-line bug that I introduced, that allowed relays to
be turned on, but not turned off! I've fixed it now. I have also
merged the changes into the 'master' branch of the Git repo.

[Ian Abbott]

On 02/06/2025 13:57, Gus Cerda wrote:
> I'm testing relays, It seems that I can put it at HIGH state but I can't
> reverse it to the LOW state.
> If I can help you with the tests let me know.

Yes, it should be fixed now if you can re-test. The fix is on the
"wip-adl_pci7250-updates branch", but all the changes have now been
merged into the "master" branch. I'll remove the
"wip-adl_pci7250-updates" branch in a few days.

[Gus Cerda]

All is working right now on the new LPCIe-7250, I can enable all relays and disable them with success and all the inputs are working well.

Thank you so much!!