On Mon, Dec 11, 2017 at 6:11 AM, Bjorn Andersson
<bjorn.andersson@xxxxxxxxxx> wrote:
> On Thu 07 Dec 06:13 PST 2017, Will Newton wrote:
> [..]
>>
>> I think I have narrowed down the issue to the fact that the qcom_smd
>> driver is not getting any interrupts. I get a channel created:
>>
>> [ 0.728352] smd:rpm: new channel 'rpm_requests' info-size: 88
>> fifo-size: 1024
>> [ 0.731684] smd:rpm: new channel found: 'rpm_requests'
>>
>
> That's good.
>
>> But on the first (and only) time through qcom_channel_state_worker the
>> channel is in state FLUSHING so we never create a device. Any idea why
>> I might not be getting any interrupts?
>>
>
> I presume you mean the value of GET_RX_CHANNEL_INFO(channel, state)
> here. This has been reported on 8994 as well and do stem from a
> misunderstanding of mine when it comes to how the state machine is
> ticking when a channel is closed.
Yes, that's correct.
> What we see on 8994 is that the boot loader opens the rpm_requests
> channel, send a few regulator requests and then put the channel (the
> apps side of it) in closing state. During boot of the Linux kernel the
> rpm_requests channel is then found in "closing" state.
>
> And looking at LK, the two platforms implementing this schema are 8994
> and 8909.
Is this conditional on ENABLE_SMD_SUPPORT in lk? It certainly sounds
plausible, although the version of lk that I am running looks like it
waits for an interrupt after setting the state to CLOSING and sets the
state to CLOSED so should get this right.
> My two hypothesises for 8994 was that we could either:
>
> 1) Complete the closing (i.e. not leave the channel in closing/reset
> state) and that might cause the other side to move to "opening" again,
So as I understand it the idea here is to do what lk failed to do. I
tried adding some code at the top of qcom_smd_channel_reset to detect
that a channel was in the closing state and set it to closed:
if (remote_state == SMD_CHANNEL_CLOSING) {
SET_RX_CHANNEL_FLAG(channel, fDSR, 0);
SET_RX_CHANNEL_FLAG(channel, fCTS, 0);
SET_RX_CHANNEL_FLAG(channel, fCD, 0);
SET_RX_CHANNEL_INFO(channel, state,
SMD_CHANNEL_CLOSED);
SET_RX_CHANNEL_INFO(channel, head, 0);
SET_RX_CHANNEL_INFO(channel, tail, 0);
SET_RX_CHANNEL_FLAG(channel, fTAIL, 1);
qcom_smd_signal_channel(channel);
}
This didn't seem to work though. The channel was now in the CLOSED
state but did not seem to move to OPENING afterward.
I also added some code to dump the state of the channel in case that is useful:
[ 0.709877] TX: state 0 fDSR 0x0 fCTS 0x0 fCD 0x0 fRI 0x0 fHEAD 0x0
fTAIL 0x0 fSTATE 0x0 fBLOCKREADINTR 0x1 tail 0x120 head 0x120
[ 0.728901] RX: state 4 fDSR 0x1 fCTS 0x1 fCD 0x1 fRI 0x0 fHEAD 0x0
fTAIL 0x1 fSTATE 0x1 fBLOCKREADINTR 0x1 tail 0x78 head 0x78
> or
> 2) take a more active role in driving the channel to opening,
> based on the knowledge that Linux do have someone to interested in
> communicating over this link.
Do you have an idea of what this approach might look like?
Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
