QCM6490 (Particle Tachyon): auto-detect gpiochip for f100000.pinctrl - #1111
Merged
makermelissa merged 4 commits intoMay 23, 2026
Merged
Conversation
All 40-pin header GPIOs are on gpiochip4 (176 lines). gpiochip0 has only 12 lines, so plain Pin(n) fails for any line > 11. Introduce _pin(line) which passes a (chip, line) tuple — safe for both gpiod 1.x (OPEN_BY_NUMBER) and 2.x. The version branch is kept explicit for easy future divergence. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
On Ubuntu 20.04 BSP f100000.pinctrl (176-line main bank) was gpiochip0 so plain Pin(n) worked. On later BSPs it is gpiochip4, making gpiochip0 only 12 lines and breaking any line > 11. Replace the hardcoded GPIO_CHIP=4 with _find_qcm6490_chip() which: - uses gpiod.ChipIter() on gpiod 1.x (zero overhead, clean API) - falls back to probing /dev/gpiochipN on gpiod 2.x - returns 0 if f100000.pinctrl is not found (Ubuntu 20.04 fallback) _pin() always uses Pin((GPIO_CHIP, line)) tuples; both Blinka libgpiod layers (1.x and 2.x) handle the tuple form correctly. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adds a reflection loop that publishes all GPIO_N names from the pin module (GPIO_6, GPIO_24, GPIO_44, …) as board.GPIO_N, consistent with other boards (dragonboard_410c, beaglebone_black, etc.) that expose raw GPIO line-number names alongside their header-pin aliases. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Member
|
I needed this on Ubuntu 24 when testing blinka with 2.2" ILI9341 + EYESPI Beret |
tyeth
marked this pull request as ready for review
May 23, 2026 01:31
Member
|
This does return proper pin objects, and pass CI, but not sure if it's an ideal fix, @makermelissa you'd probably know best. |
makermelissa
approved these changes
May 23, 2026
makermelissa
left a comment
makermelissa
left a comment
Collaborator
There was a problem hiding this comment.
This seems fine to me. Since these files are specific to each board, it's fine if it's a bit quirky.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
f100000.pinctrl, 176 lines) was enumerated asgpiochip0, so plainPin(n)worked fine.gpiochip4, makinggpiochip0only 12 lines (PMIC GPIOs) — any line > 11 fails withEINVAL.Pin(GPIO_BASE + n)form with a_pin(line)helper that auto-detects the correct chip at import time usinggpiod.ChipIter()(1.x) or/dev/gpiochipNprobing (2.x), then usesPin((chip, line))tuples — already supported by both Blinka libgpiod layers.f100000.pinctrlis not found, preserving Ubuntu 20.04 behaviour unchanged.Test plan
GPIO_CHIPdetects4on current Particle Tachyon BSP - Ubuntu 24.04 (gpiodetectshowsgpiochip4 [f100000.pinctrl])GPIO_CHIPdetects0on Ubuntu 20.04 BSP (or any system wheref100000.pinctrlisgpiochip0)EINVALgpiod.ChipIter()path exercised on gpiod 1.x/dev/gpiochipNprobe path exercised on gpiod 2.x🤖 Generated with Claude Code