Hi Bryan,
On 10/8/24 16:24, Bryan O'Donoghue wrote:
On 08/10/2024 13:00, Vladimir Zapolskiy wrote:
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.
Please share the change to the driver, which you've used to test
high level type of interrupts, shall it be send for upstream inclusion?
Such a change has never been a subject of discussion.
I tried running libcamera "cam" application to capture a data stream
before and after your change - from memory at least on the sc8280xp and
I think on 8250 too.
it does not test high level type of CAMSS interrupts, I hope this is closed.
Nobody has ever tested high level type of CAMSS interrupts, and there is no
reason why they are specified in the platform dtsi file, but I repeat myself.
What I haven't tested is unloading and reloading the kernel module. My
understanding of your bug report is your change fixes an error on reload.
Since you have access to the hardware, you are always welcome to make a simple
test, which was given in the recent past, but I do accept that quite many
things has to be repeated a few times in a row before people, me included,
grasp them:
https://lore.kernel.org/all/8d3e4ad1-82e3-42ad-80c2-dacd863e8e3e@xxxxxxxxxx/
% echo -n ac5a000.camss > /sys/bus/platform/drivers/qcom-camss/unbind
% echo -n ac5a000.camss > /sys/bus/platform/drivers/qcom-camss/bind
--
Best wishes,
Vladimir
