[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMmmMt3u=DB5onXdayMN5ZHvCmdnam4wOo0hKizve4K0LnZLZQ@mail.gmail.com>
Date: Fri, 7 Jun 2024 09:46:42 +0530
From: "Aniket ." <aniketmaurya@...gle.com>
To: Jeremy Kerr <jk@...econstruct.com.au>
Cc: Alexandre Belloni <alexandre.belloni@...tlin.com>, Joel Stanley <joel@....id.au>,
Billy Tsai <billy_tsai@...eedtech.com>, linux-i3c@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i3c: dw: Fix IBI intr signal programming
Hi Jeremy,
> I think we're OK in this case (just not reading the value out of the
> SIR_REQ_REJECT register), but any thoughts on adding corresponding
> switches in the driver so we can support those configurations? These
> would be represented as DT config of the specific hardware instance - at
> the most granular, just by the specific compatible string.
We can go with some DT quirk, but I don't see the strong need to do this
here. I guess optional registers like IBI_SIR_REQ_REJECT, IBI_MR_REQ_REJECT
should not be relied upon to set other registers.
> Could we use the SIR mask for this, but just read it from a field in the
> struct dw_i3c_master, instead of IBI_SIR_REQ_REJECT?
>
> This would mean that there's no possibility of the counter going out of
> sync from the SIR settings - say, on underflow if we get a spurious
> disable.
Yes, we can keep a SW SIR mask instead of a counter. It would replace
all the places where we read IBI_SIR_REQ_REJECT.
Both methods are okay, but if you think the mask might come in handy in
some situations rather than just the count, we can go with that.
Let me know your thoughts on this.
Thanks,
Aniket
Powered by blists - more mailing lists