Hi Johan,
Johan Hovold 於 2019/10/23 下午 08:22 寫道:
On Mon, Sep 23, 2019 at 10:24:49AM +0800, Ji-Ze Hong (Peter Hong) wrote:
The Fintek F81534A series contains 3 GPIOs per UART and The max GPIOs
is 12x3 = 36 GPIOs and this patch will implements GPIO device as a
gpiochip to control all GPIO pins even transforms to transceiver pins.
Depending to your answer to my question whether these pins are truly
general purpose or not, this may not be the right interface.
Our F81534A series contains F81532A/534A/535/536. For the following link
of F81534A pin-out:
https://imgur.com/a/AZHqQ1N
We had 2 type about GPIO pins, MODEx_y & GPIOxx. All MODEx_y & GPIOxx
are GPIOs and can be controlled by GPIO device, but they had some
difference about usage.
MODEx_y:
1. 3 pins(x: 0/1/2) can be access by UART port y.
2. Used to control UART's transceiver normally, but it
also can be configure as GPIO when UART disabled by
H/W (DTR strap to GND).
GPIOxx:
1. Access only by GPIO device.
The series patch only support RS233 mode for all serial port, So we'll
direct set all MODEx_y to (0/0/1) for our demo board for default. If
user really want to use the pin, we had provide the gpiolib with GPIO
device, but we'll recommend user to use GPIOxy first.
Is any suggest about this ? Could I maintain this for this series patch?
+
+ status = devm_gpiochip_add_data(&intf->dev, &priv->chip, priv);
+ if (status) {
+ dev_err(&intf->dev, "failed to register gpiochip: %d\n",
+ status);
+ return status;
+ }
Have you tried disconnecting the device with gpios requested? This used
to break gpiolib, but was fixed. Just want to make sure it hasn't
regressed.
I had try export GPIOs and detach the F81534A in kernel 5.0.0, it seems
no problem. Is any link about this issue for me to do more test ?
Thanks
--
With Best Regards,
Peter Hong
