Then better to set it as supported by driver, and ignore them in driver. Otherwise other controllers who support pullup/pulldown will have unpredictable results on that lines, because nobody said to pull it.
I seem GPIO_PIN_PULLUP/GPIO_PIN_PULLDOWN not set in any sys/mips/ gpio code. And gpioiic.c not use GPIO_PIN_PULLUP/GPIO_PIN_PULLDOWN that is same bitbang code . I think better not use in gpiospi.c rather than low driver ignore.
@yamori813_yahoo.co.jp with i2c the bus hardware must have pullups (required by standard). This is why I haven't added it to gpioiic (but maybe I should...).
It is safe to ignore pullup/pulldown in gpio driver, they will have no meaning for that specific gpio controller, if you have a different controller they can still be used.
The check in gpio_check_flags() is wrong, I going to fix it. Thanks!
|316 ↗||(On Diff #22810)|
The delays still seem wrong to me, see: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
We have to take the phase into account.
|120–121 ↗||(On Diff #22810)|
|125 ↗||(On Diff #22810)|
Correct, please commit.
I check this code on my develop SPI module code that is ksz8995ma ether switch chip and FON2100. This case delay is fixed problem and work. I check signal enclose picture. If no delay clock is not to zero.
This is my setting hints.
yeah, this delay() fixes the clock output, but what I am saying is that data and clock should come out with a 90o phase difference. your patch doesn't not fix this but it is surely an improvement (you can commit this change too).
gpio_delay has been committed by next commit in sequence: https://github.com/freebsd/freebsd/commit/1ea50c0b5014d04d2b8586d6efd258abe411d87f
I suppose Phabricator doesn't track commits for already closed reviews (smells like possible improvement ;).