On Thu, 2018-11-08 at 12:04 -0200, Renato Lui Geh wrote: > Hi, > Hey, > On 11/06, Ardelean, Alexandru wrote: > > For AD778x you could also add support for the GAIN & FILTER pins via > > GPIOs, > > to control these settings. And then in the ad7780_postprocess_sample() > > function check if the GPIO settings (stored on a gpio_desc on > > ad7780_state) > > match the expected GAIN & FILTER bit settings ; if not return -EIO. > > We're having some trouble with the GPIOs, and would like some insight on > how to proceed. Any help would be very much appreciated! > > We're wondering if we should do something like this in ad7780.c's probe: > > st->powerdown_gpio = devm_gpiod_get_optional(&spi->dev, > "powerdown", > GPIOD_OUT_LOW); > Yes, something like this. > for both gain and filter. Taking a look at driver drivers/iio/adc/hx711.c > (another adc driver out of staging), we have: > > hx711_data->gpiod_pd_sck = devm_gpiod_get(dev, "sck", GPIOD_OUT_LOW); > > So we're assuming "sck" and "powerdown" are the pins we're looking for. > Are we > correct to assume that these strings are compared with a table that map > the > actual GPIO pins? So we'd have something like: > > st->gain_gpio = devm_gpiod_get_optional(&spi->dev, > "gain", > GPIO_DOUT_LOW); This is exactly a good idea to do for `gain`. And similar for `filter` > > Where "gain" is the pin 4 or 5 on the AD778x The pin 4 or 5 on the AD778x are not what you define here. The GPIOs you define/use here are on the host-board. So, Host-board [dt-entry] <----> AD778x [HW-pin] Where: * `dt-entry` is definted in the device-tree something like: gain-gpio = <&gpio GPIO_NUMBER_ON_HOST_BOARD GPIO_FLAGS> * GPIO_NUMBER_ON_HOST_BOARD is a number, which varies ; for example for Raspberry Pi it could be pin 25 [in the device tree]; * GPIO_FLAGS is usually 0 ; but can be any other numeric value defined here: https://github.com/torvalds/linux/blob/master/include/dt-bindings/gpio/gpio.h * `HW-pin` doesn't matter, because it's a physical pin that can be defined as anything in SW > ( > https://www.analog.com/media/en/technical-documentation/data-sheets/ad7780.pdf > ) > chip. > > Where can we find this table that maps these pin names to the actual pin > numbers? We found this link The actual pin number doesn't matter in the driver you write. It matters in the device-tree for the board you use the driver [and chip] on. If you were to test your driver change on a RPi board and you physically connect this on Pin 25 (physical) and in your device-tree GPIO_NUMBER_ON_HOST_BOARD is the value (in SW) for Pin 25, then that's what matters when you test/run the code. In the kernel, a pin numbers table for the RPi can be found here: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/bcm283x.dtsi#L185 I keep referring to RPi because we've used it a bit more than other boards, and also because for RPi usually Pin 25 in HW is also Pin 25 in SW. > https://www.kernel.org/doc/html/v4.17/driver-api/gpio/board.html that > shows how > to declare table attributes, but we couldn't find this lookup table > there. > > Are we missing something? Out of curiosity, why do we have to pass a > string > (e.g. powerdown, gain, sck, dout) instead of the pin number? We found > somewhere > that they are names to functions. Are these functions implemented on the > chip? > So, the string in the driver, will be used to lookup the physical pin in the device-tree. The pin number differs from one host-board to another [as I've said], so the string is a unique identifier for the driver, which resolves to the physical pin on the board. By the way: one work item (maybe after the driver is moved out of staging) would be to also write a device-tree binding doc. An example: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/sound/adi,adau17x1.txt It's not the best one, and feel free to look for others as well, that define GPIOs. But in that file, is an example of how to link a reset-gpio that would be called by that driver to physically reset the device when probed & initialized. Usually the arch/arm[64]/boot/dts have a lot of device-trees that may help shape some thinking about device-trees. I'm hoping I got to explain things somewhat. It is a bit late in the afternoon [for me], but I thought I'd give it a try :) If there are still questions, feel free to ask. I think I can get to them tomorrow. Thanks Alex > Thanks, > Renato >
