On 10/8/24 15: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.
Debugging of what? Again, nobody ever tested high level type of interrupts
of CAMSS IP. Why some irrelevant imaginary "races" are into the discussion,
have you or any other CAMSS user ever seen them? If no, this argument shall
be excluded.
Apparently nobody followerd the link in the cover letter to comprehend
the problem...
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.
The driver and only the driver dictates what's been tested so far in
this respect.
--
Best wishes,
Vladimir
