From: Jeremy McNicoll <jmcnicol@redhat.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Ohad Ben-Cohen <ohad@wizery.com>,
Will Newton <will.newton@gmail.com>,
linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, Chris Lew <clew@quicinc.com>
Subject: Re: [PATCH 2/5] rpmsg: smd: Create device for all channels
Date: Fri, 26 Jan 2018 17:01:52 -0800 [thread overview]
Message-ID: <20180127010152.GA32527@mini-rhel.redhat.com> (raw)
In-Reply-To: <20171212235857.10432-3-bjorn.andersson@linaro.org>
On Tue, Dec 12, 2017 at 03:58:54PM -0800, Bjorn Andersson wrote:
> Rather than selectively creating devices only for the channels that the
> remote have moved to "opening" state let's create devices for all
> channels found. The driver model will match drivers to the ones we care
> about and attempt to open these.
>
> The one case where this fails is if the user loads a firmware that lacks
> a particular channel of the previous firmware that was running, in which
> case we would find the old channel and attempt to probe it. The channel
> opening handshake will ensure this will result in a graceful failure.
Another case is that on the 8992/8994 there is no call to create_device
due to the RPM always leaving the RX channel in the CLOSING state.
I believe this may be happening in the LK based on this message:
"[270] Waiting for the RPM to populate smd channel table "
The exact same behaviour has been observed on the downstream kernel
(initial state needing to be ignored in order). Stated another way,
downstream _BLINDLY_ calls platform_device_register in smd_alloc_channel
regardless of the value returned by ch->half_ch->get_state(ch->recv));
In the afore mentioned case _ALL_ of the images (RPM, bootloader: BZ11h, LK)
used on the Nexus 5X/6P under test were unmodified as provided by MSM
and/or Google.
>
> The result of this patch is that we will actively open the RPM channel
> even though it's left in a state other than "opening" after the boot
> loader's closing of the channel.
>
Its been a while since I looked at this closely but, isn't the result
of this patch that we now will create a channel / register a platform
device if the state of the channel is left in any state.
> Reported-by: Jeremy McNicoll <jmcnicol@redhat.com>
.....and Suggested-by: Jeremy McNicoll <jeremymc@redhat.com>
> Reported-by: Will Newton <will.newton@gmail.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> drivers/rpmsg/qcom_smd.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
> index 58dd44493420..1beddea6f087 100644
> --- a/drivers/rpmsg/qcom_smd.c
> +++ b/drivers/rpmsg/qcom_smd.c
> @@ -1225,11 +1225,6 @@ static void qcom_channel_state_worker(struct work_struct *work)
> if (channel->state != SMD_CHANNEL_CLOSED)
> continue;
>
> - remote_state = GET_RX_CHANNEL_INFO(channel, state);
> - if (remote_state != SMD_CHANNEL_OPENING &&
> - remote_state != SMD_CHANNEL_OPENED)
> - continue;
> -
The code looks good, and the change is _VERY_ familiar.
-jeremy
> if (channel->registered)
> continue;
>
> --
> 2.15.0
>
next prev parent reply other threads:[~2018-01-27 1:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-12 23:58 [PATCH 0/5] Qualcomm SMD updates Bjorn Andersson
2017-12-12 23:58 ` [PATCH 1/5] rpmsg: smd: Perform handshake during open Bjorn Andersson
2018-01-27 1:32 ` Jeremy McNicoll
2017-12-12 23:58 ` [PATCH 2/5] rpmsg: smd: Create device for all channels Bjorn Andersson
2018-01-27 1:01 ` Jeremy McNicoll [this message]
2018-02-02 22:57 ` Bjorn Andersson
2017-12-12 23:58 ` [PATCH 3/5] rpmsg: smd: Wake up all waiters Bjorn Andersson
2017-12-12 23:58 ` [PATCH 4/5] rpmsg: smd: Fail send on a closed channel Bjorn Andersson
2017-12-12 23:58 ` [PATCH 5/5] rpmsg: smd: Don't hold the tx lock during wait Bjorn Andersson
2018-01-27 1:35 ` [PATCH 0/5] Qualcomm SMD updates Jeremy McNicoll
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180127010152.GA32527@mini-rhel.redhat.com \
--to=jmcnicol@redhat.com \
--cc=bjorn.andersson@linaro.org \
--cc=clew@quicinc.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=ohad@wizery.com \
--cc=will.newton@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.