linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).