<dhruvag2000>
Perhaps @tmlind_ can comment on this better, we were trying to get gpio-keys based IO daisychaining to work but with little success. The gpio-keys based io daisychaining still requires some debug and hence we are using the Main UART as demo.
<dhruvag2000>
Please can talk more about what the use case is that you wish to use MAIN GPIO gpio-keys specifically as a chained IO wakeup? MCU GPIOs isn't a workable option?
<pivi>
dhruvag2000: no, MCU GPIOs are not an option. We concluded the HW design with a commitment from TI that this was going to work on 09.00 release.
<pivi>
dhruvag2000: the use case is very simple, we need to wake the system from a GPIO on the main domain. This is just a requirement for our system.
<pivi>
dhruvag2000: anyway, I guess I got my answer on the current status: not working.
<dhruvag2000>
I understand your concern, currently we have a Proof of Concept that a Main domain I/O pin can wake the system (as I have explained in the SDK Docs shared above). Thus we have demonstrated that device can do Main IO daisychain wakeup. Software level cleanup and integration with various drivers and systems is the next step. In this particular case, gpio-keys. gpio-keys chaining of wake IRQs is an ongoing debug and will need
<dhruvag2000>
time.
<dhruvag2000>
In the meanwhile if the requirement if to use that particular I/O to wakeup from deepsleep, a temporary SDK based solution could be to replace the padconf register from the <&main_pmx0 0x1c8>; /* (D14) UART0_RXD PADCONFIG114 */ to the one you desire. So although the linux side wake IRQ maping would be via UART, it would still atleast be configured as a wakeup pin when in deepsleep.
<pivi>
dhruvag2000: thanks, probably we can wait a little bit more till you figure out the proper solution, if not we will have a look at the workaround you suggested, thanks!
<pivi>
dhruvag2000: I just raised this once more to some of your managers, if someone is coming to "you" on this topic asking for a timeline it's me ;-)
<dhruvag2000>
Great, please give your R-by on the list when possible :D
padovan has quit [*.net *.split]
MWelchUK has quit [*.net *.split]
mkorpershoek has quit [*.net *.split]
padovan has joined #linux-ti
MWelchUK has joined #linux-ti
mkorpershoek has joined #linux-ti
florian_kc has joined #linux-ti
ikarso has quit [Quit: Connection closed for inactivity]
Kubu_work has quit [Ping timeout: 244 seconds]
ikarso has joined #linux-ti
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 260 seconds]
florian_kc has joined #linux-ti
<pivi>
NishanthMenon: are you planning to pick at least the patch adding the tidss node to the am62 main dtsi? this would be very beneficial to others, me included :-)
<NishanthMenon>
pivi: it will introduce checkpatch warnings on my tree. i have been beaten up on that before
<NishanthMenon>
i can dig up all the old dirt again all over..
<NishanthMenon>
the trouble is that rest of the patches are probably OK.. just the am62-dss compatible stuff is outstanding.
<pivi>
NishanthMenon: this specific patch or something else in thst series?
<pivi>
ah ok, so it's really the patch I want
<NishanthMenon>
pivi: yeah, i know.. so do i
<pivi>
do we know what needs to be fixed? I did not really look into it
<NishanthMenon>
it is in next actually. just not in 6.5-rc1
<pivi>
NishanthMenon: what's in next? I did dry to apply $ ./scripts/checkpatch.pl tidss.patch
<pivi>
so, the concern is that this commit ad2ac9dc9426 ("drm/tidss: Add support for AM625 DSS"), is in next, but not in 6.5-rc1?
<pivi>
If I understand correctly that would mean that to enable anything we would need 2 development cycles
<NishanthMenon>
binding,driver in 1, dts in next
<pivi>
is this the way we want to work? to me it seems that we are artifically delay getting stuff integrated in mainline. In the end the yaml is going to get merged in v6.6-rc1, we are postpoining this just because we have different tree (drm and soc/ti in this case)
<pivi>
I mean, to me it's not a huge deal, I would benefit for it, but I can way a few weeks.
<pivi>
s/way/wait/
<NishanthMenon>
that is what we ended up with the mess we created years back
<NishanthMenon>
after a couple of merge windows of mess, once we introduced this rule, things have been smooth for a few years now.
<pivi>
SOC tree? TI tree or in general?
<pivi>
anyway, fine for me, of course
<NishanthMenon>
TI SoC tree
<pivi>
understood, thanks for taking the time to explain the reasoning here
<NishanthMenon>
i dont remember if it was mmc or usb or probably both.. driver tree was'nt merged and the patches got dropped, redone...
<pivi>
NishanthMenon: gonna prepare a series based on the one Aradhya so it's ready and lined up for the coming weeks ;-)
<NishanthMenon>
pivi: sure - it will be vigneshr 's turn at the helm.. i get a break ;)
<NishanthMenon>
i can however put them on stage though..
<NishanthMenon>
if that helps everyone.. and get it into next
<NishanthMenon>
now that i think about it.. stephen just requires us to queue things that are meant to go to linus tree..
<pivi>
the main reason is that we have a couple of other series, currently in review, that were tested with some patches non in -next, and that require the tidss to work. Nothing crazy, just some small pain that make testing stuff with mainline more effort
<pivi>
gonna go, have a nice rest of the day
<NishanthMenon>
sure. thanks pivi
Kubu_work has joined #linux-ti
ikarso has quit [Quit: Connection closed for inactivity]