-----Original Message-----
From: Andrew Halaney <ahalaney@xxxxxxxxxx>
Sent: Friday, July 14, 2023 11:17 AM
To: Ninad Naik (QUIC) <quic_ninanaik@xxxxxxxxxxx>
Cc: andersson@xxxxxxxxxx; agross@xxxxxxxxxx; konrad.dybcio@xxxxxxxxxx; linux-arm-msm@xxxxxxxxxxxxxxx; linux-gpio@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Parikshit Pareek (QUIC) <quic_ppareek@xxxxxxxxxxx>; Prasad Sodagudi <psodagud@xxxxxxxxxxx>; Prasanna Kumar (QUIC) <quic_kprasan@xxxxxxxxxxx>
Subject: Re: [PATCH] pinctrl: qcom: Add intr_target_width to define intr_target_bit field width
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
On Fri, Jul 14, 2023 at 11:40:09AM +0530, Ninad Naik wrote:
SA8775 and newer target have added support for an increased number of
interrupt targets. To implement this change, the intr_target field,
which is used to configure the interrupt target in the interrupt
configuration register is increased from 3 bits to 4 bits.
In accordance to these updates, a new intr_target_width member is
introduced in msm_pingroup structure. This member stores the value of
width of intr_target field in the interrupt configuration register.
This value is used to dynamically calculate and generate mask for
setting the intr_target field. By default, this mask is set to 3 bit
wide, to ensure backward compatibility with the older targets.
Signed-off-by: Ninad Naik <quic_ninanaik@xxxxxxxxxxx>
Thanks for the patch. Naive question (without really reading the code), but what practical affect does this have?
Target bits configures irq destination processor on Qualcomm SoC.
g->intr_target_kpss_val(0x3) routes the gpio IRQ to application process.
On this SoCs target bits length is changed from 3 bits to 4 bits in hw
and reset value of g->intr_target_reg register value is 0x1E2. So reset
value of target bits is 0xf. With old logic, when writing
g->intr_target_kpss_val(0x3) value result is 0xb instead of 0x3 as top
most bit is not getting cleared out and leading to IRQ is not getting
fired on application processor. 0xb value is unused on current HW and
IRQ would not be fired.
i.e. does this change behavior of how IRQs were handled before this patch vs after on this platform?
To shed some light on the question, there's a GPIO IRQ for the ethernet phy on this platform that is purposely _not_ described because it didn't ever trigger, resulting in the interface staying down. Things work fine without the IRQ (the driver goes into polling mode).
The explanation I got was very brief and attributed it to a "hardware issue".
I'm wondering if I should re-evaluate that, and if this was the "hardware issue".
Hi Andrew,
I don't have complete idea on ethernet phy gpio irq issue and I will
sync up with offline. Please try this patch for ethernet use case.
Thanks,
Andrew
