piolib: support transfer lengths that don't fit in 16 bits

[jepler]

struct rp1_pio_sm_xfer_data_args {
    uint16_t sm;
    uint16_t dir;
    uint16_t data_bytes;
    void *data;
};

The structure used for data transfers is limited to a 16-bit count of data_bytes.

Our application would like to do larger transfers. Right now we are working around this limitation by submitting several buffers of data sequentially, but it would be preferable if we could submit all the data in one go:

constexpr size_t MAX_XFER = 32768;

void pio_sm_xfer_data_large(PIO pio, int sm, int direction, size_t size, uint32_t *databuf) {
    while(size) {
        size_t xfersize = std::min(size_t{MAX_XFER}, size);
        int r = pio_sm_xfer_data(pio, sm, direction, xfersize, databuf);
        if (r) {
            perror("pio_sm_xfer_data (reboot may be required)");
            abort();
        }
        size -= xfersize;
        databuf += xfersize / sizeof(*databuf);
    }
}```

[pelwell]

That's a lot of data - what's your use case?

I'm not against in principle, it's just a matter of not breaking anything in the process. It might be that, due to the alignment requirements, switching to uint32_t would just work.

[jepler]

I'm driving HUB75 matrices with PIO. Ideally I'd submit a whole frame with one ioctl, but even a 64x32 matrix with 10 bitplanes exceeds 64kB in the encoding I'm using. And folks like to use several of these matrices in daisy chain mode.

Right now I'm just submitting 32kB at a time and trying to determine whether some artifacts I'm seeing are due to a flaw in my code or are due to a pause in the bitstream between ioctls. (a smaller 32x16 display that just needs one data submission per frame doesn't have these artifacts)

[jepler]

(@ladyada ping for interest)

[pelwell]

There are now two PRs for this: one for piolib (#108), and one for the kernel driver (raspberrypi/linux#6543). Both are needed for larger transfers to work. The library should simply fail to do larger transfers with a non-updated kernel.

[jepler]

Thanks!

[pelwell]

That's all been merged now. The driver change missed yesterdays rpi-update release, but you can install a kernel containing the updated driver using either sudo rpi-update pulls/6543 or sudo rpi-updates rpi-6.6.y.