* [BUG] keyboard doesn't work on Olimex teres-I notebook @ 2022-04-19 12:27 Milan P. Stanić 2022-06-08 0:30 ` Andre Przywara 0 siblings, 1 reply; 3+ messages in thread From: Milan P. Stanić @ 2022-04-19 12:27 UTC (permalink / raw) To: u-boot; +Cc: Samuel Holland [ Please CC to me, I'm not subscribed to mailing list ] Hi, On u-boot release 2022.04 keyboard doesn't work in u-boot on Olimex TERES-I notebook. With git bisect I found that commit 35ae126c16a6a9149edc6638faaa247f67b8a400 is introduced this. Reverting this commit solved problem and in my test keyboard now works. -- Kind regards ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] keyboard doesn't work on Olimex teres-I notebook 2022-04-19 12:27 [BUG] keyboard doesn't work on Olimex teres-I notebook Milan P. Stanić @ 2022-06-08 0:30 ` Andre Przywara 2022-06-08 9:53 ` Andre Przywara 0 siblings, 1 reply; 3+ messages in thread From: Andre Przywara @ 2022-06-08 0:30 UTC (permalink / raw) To: Milan P. Stanić; +Cc: u-boot, Samuel Holland, Simon Glass On Tue, 19 Apr 2022 14:27:24 +0200 Milan P. Stanić <mps@arvanta.net> wrote: Hi Milan, > [ Please CC to me, I'm not subscribed to mailing list ] > > Hi, > > On u-boot release 2022.04 keyboard doesn't work in u-boot on Olimex > TERES-I notebook. Thanks for the report, and sorry for the delay! > With git bisect I found that commit 35ae126c16a6a9149edc6638faaa247f67b8a400 > is introduced this. Reverting this commit solved problem and in my test > keyboard now works. Unfortunately just reverting this commit is not really the way forward, but I had a closer look and few printf's later found the problem: The USB PHY driver uses the legacy GPIO interface, which is now wrapped in gpio-uclass.c, to call the actual DM functions. The commit that you bisected to implements the recommended .set_flags ops member, which relies on the GPIO being properly configured before. Unfortunately those compat wrappers seem to be broken, and not using .set_flags just papered over this problem before: - A call to gpio_direction_output() fills the DM struct gpio_desc *locally*, on the stack, so any setup is lost when the function returns. The GPIO hardware is still configured as an output, but U-Boot doesn't remember this. - A call to gpio_direction_output() in the legacy interface is supposed to also set the output value, but the compat wrapper does not implement this. - When .set_flags is implemented in a GPIO driver implementation, the DM GPIO interface *requires* GPIOs to be configured before, but since this information is lot, a call to gpio_set_value() does nothing. So while those issues looks like they demand fixing, in the generic compat GPIO wrappers, I decided to upgrade the sunxi USB PHY driver to just use the DM GPIO interface directly. Eventually this driver should drop the U-Boot configured GPIOs, and use proper DT methods, but this is a bigger change I'd rather not introduce that late in the development cycle. So for now I sent this patch, that should fix the issue: https://lore.kernel.org/u-boot/20220608000604.3357-1-andre.przywara@arm.com/ If you could please test this patch, then reply to that patch email, for instance with a Tested-by:, this would be greatly appreciated! Cheers, Andre ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] keyboard doesn't work on Olimex teres-I notebook 2022-06-08 0:30 ` Andre Przywara @ 2022-06-08 9:53 ` Andre Przywara 0 siblings, 0 replies; 3+ messages in thread From: Andre Przywara @ 2022-06-08 9:53 UTC (permalink / raw) To: Milan P. Stanić; +Cc: u-boot, Samuel Holland, Simon Glass On Wed, 8 Jun 2022 01:30:42 +0100 Andre Przywara <andre.przywara@arm.com> wrote: Hi, > On Tue, 19 Apr 2022 14:27:24 +0200 > Milan P. Stanić <mps@arvanta.net> wrote: > > Hi Milan, > > > [ Please CC to me, I'm not subscribed to mailing list ] > > > > Hi, > > > > On u-boot release 2022.04 keyboard doesn't work in u-boot on Olimex > > TERES-I notebook. > > Thanks for the report, and sorry for the delay! > > > With git bisect I found that commit 35ae126c16a6a9149edc6638faaa247f67b8a400 > > is introduced this. Reverting this commit solved problem and in my test > > keyboard now works. > > Unfortunately just reverting this commit is not really the way forward, > but I had a closer look and few printf's later found the problem: > The USB PHY driver uses the legacy GPIO interface, which is now wrapped > in gpio-uclass.c, to call the actual DM functions. > The commit that you bisected to implements the recommended > .set_flags ops member, which relies on the GPIO being properly > configured before. Unfortunately those compat wrappers seem to be > broken, and not using .set_flags just papered over this problem before: > - A call to gpio_direction_output() fills the DM struct gpio_desc > *locally*, on the stack, so any setup is lost when the function > returns. The GPIO hardware is still configured as an output, but > U-Boot doesn't remember this. > - A call to gpio_direction_output() in the legacy interface is supposed > to also set the output value, but the compat wrapper does not > implement this. Scratch that part: that works, as the h/w routines are called inside dm_gpio_clrset_flags(), where we set the correct flags in our (temporary) struct gpio_desc, before calling the .set_flags implementation. Got tricked by the rather innocent function name. But still calling gpio_direction_output(), then later gpio_set_value() is broken. I guess we should fix it, maybe by forcing GPIOD_IS_OUT in the desc, before calling dm_gpio_set_value()? Cheers, Andre > - When .set_flags is implemented in a GPIO driver implementation, the > DM GPIO interface *requires* GPIOs to be configured before, but > since this information is lot, a call to gpio_set_value() does > nothing. > > So while those issues looks like they demand fixing, in the generic > compat GPIO wrappers, I decided to upgrade the sunxi USB PHY driver to > just use the DM GPIO interface directly. Eventually this driver should > drop the U-Boot configured GPIOs, and use proper DT methods, but this > is a bigger change I'd rather not introduce that late in the > development cycle. > So for now I sent this patch, that should fix the issue: > https://lore.kernel.org/u-boot/20220608000604.3357-1-andre.przywara@arm.com/ > > If you could please test this patch, then reply to that patch email, > for instance with a Tested-by:, this would be greatly appreciated! > > Cheers, > Andre ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-06-08 9:53 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-19 12:27 [BUG] keyboard doesn't work on Olimex teres-I notebook Milan P. Stanić 2022-06-08 0:30 ` Andre Przywara 2022-06-08 9:53 ` Andre Przywara
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.