On Mon, 15 Apr 2024 at 19:12, Derek Atkins <derek@xxxxxxxxx> wrote: > > Hi Peter, > > On Mon, April 15, 2024 1:47 pm, Peter Robinson wrote: > > >> >> I'm using > >> >> https://download.technexion.com/development_resources/wandboard/wbquad-revb1-userguide.pdf > >> >> as a reference for the board layout. Specifically, on page 27, it > >> shows > >> >> me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31, > >> >> CPIO1_24, > >> >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19. > >> >> > [snip] > > >> Being only ancillarily associated with Arm/Embedded HW -- what does it > >> mean for a GPIO to be "used for other things"? And more importantly, > >> why > >> would it be wired to a header if it's being used for something else? > > > > So in the case I mention below the GPIO pin is used for i2c and it's > > on that header so you could add say a i2c based temp sensor or other > > i2c device. > > > > Also board designers may use a GPIO to hook up a mSD card detect pin, > > or a WiFi interface reset pin, or something else on the board layout. > > I guess I don't understand why they would expose GPIO-x on a header and > ALSO use it elsewhere on the board. In my case, I just need to find 4 > open "button" inputs. They're not, eg to use the i2c example, they are changing those GPIOs to be i2c and exposing it on the header as an i2c interface (and hence they are not usable as a generic GPIO interface). To use 4 GPIOs to use for buttons you just need to work out where the open GPIOs as documented on the header map as open unused GPIO PINs. > > You can see the default pin allocation here from line 152-195: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx6qdl-wandboard.dtsi#n152 > > > > And the GPIOs mapped to i2c here on lines 103-104 and again 113-114, > > and then as a camera enable/reset at 139-140: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx6qdl-wandboard.dtsi#n103 > > Thanks. I see the duplication of scl-gpois and sda-gpios names in those > two sections, but in the first section it uses gpio3 21/28 and in the > second section is used gpio4 13/14. That's two different i2c interfaces, one I suspect is mapped out to the PIN headers, the other is used for audio codec and camera elsewhere on the board. > I also don't see the specific bindings for the pins on the JP4 header > (e.g. I don't see gpio3 12 being specified here). You need to follow the docs, I am not looking at that, I was purely explaining how the mappings are happening, not how they're routed on the HW. > >> > A quick look at the dtsi for the wandboards some of the GPIOs re used > >> > for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not have > >> > anything attached so I guess in on a pin header for end user use, and > >> > i2c12 has a audio codec and for the camera connector. > >> > >> How exactly is this done? Is the pin wired to two places on the PCB? > > > > It depends, for example on a RPi header you can use a DT overlay to > > change the default use of a PIN, by default is might be a standard > > GPIO but you apply an overlay that remaps it so it routes a i2s audio > > interface so you can use a DAC to output sound. So it's generally more > > about being able to use the reduced amounts of external pins for > > different usecases, someone might want it in a robot, someone else > > might want it to output audio. > > How would an end-user do that without building a custom kernel? Like I > said, all I need is to read from four input GPIOs for a water-detection > system, so instead of using a 'sleep' after opening the relay, it waits > for the appropriate gpio to turn on based on a water detector connected to > it (so it will turn off the relay as soon as it detects the water tank is > full). Basically read the docs and map that through to free GPIO PINS. > So really I just need to choose 4 pins that I can use, and map those to an > event manager to wait for the pin to go on. JP4 seems to be the only > layout with GPIO labeled, so I just need to figure out which pins to use > and how to read those inputs in this brave new world. I've not dug out a pdf to work out the physical pins and how they map to the SOC and hence the DT, I've left that up to you, I was just answering your questions about why some appear to be in use and trying to help you understand as you requested. -- _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
