On 08/10/2024 13:01, Krzysztof Kozlowski wrote:
On 08/10/2024 13:50, Bryan O'Donoghue wrote:
On 08/10/2024 12:37, Vladimir Zapolskiy wrote:
I don't have access to datasheets or hardware of sc8280xp powered board,
someone may either verify, if CAMSS level high type interrupts are
supported/working at all or not (obviously its current presence in dts is
insufficient), or check the SoC datasheet.
I've tested both as was submitted and your change.
I _always_ test my patches. I'm not sure there's a datasheet which
spells this out to be honest.
Datasheet, HPG, interrupt list in the IP catalog. They all might provide
some hints, e.g. recommendation.
Rising or High can both be justified, its really down to how your
interrupt controller latches the state change. However I personally am
fine with the change you've provided because I trust it fixes an error
for you.
That's a GIC, right? So most of the GIC interrupts are level high.
I can easily imagine that 10 years ago one engineer made mistake and
wrote camss downstream DTS with edge and this kept going, because
"99.999% it works" and no one will ever hit that 0.001%. And if it is
hit, we blame something else because debugging is very difficult.
If this entire patchset is based on downstream driver code, not
datasheets, then it should be clearly explained in commit msg, not just
"The expected type is...".
Why? Because "the expected type" means datasheet or some hardware
engineer says it, not driver.
Best regards,
Krzysztof
Yes, true its entirely possible - likely even that copy/paste is the
dejure method.
Lets have a poke around the qcom documentation and see if we can come up
with a definitive answer rooted in the spec.
+1
---
bod