All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Lina Iyer <lina.iyer@linaro.org>
Cc: Ohad Ben-Cohen <ohad@wizery.com>,
	linux-remoteproc@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 00/17] Make rpmsg a framework
Date: Mon, 12 Sep 2016 15:58:55 -0700	[thread overview]
Message-ID: <20160912225855.GL405@tuxbot> (raw)
In-Reply-To: <20160912222240.GA28944@linaro.org>

On Mon 12 Sep 15:22 PDT 2016, Lina Iyer wrote:

> On Mon, Sep 12 2016 at 10:52 -0600, Lina Iyer wrote:
> >Hi Bjorn,
> >
> >On Thu, Sep 01 2016 at 16:28 -0600, Bjorn Andersson wrote:
> >>This series splits the virtio rpmsg bus driver into a rpmsg bus and a virtio
> >>backend/wireformat.
> >>
> >>
> >>As we discussed the Qualcomm SMD implementation a couple of years back people
> >>suggested that I should make it "a rpmsg thingie". With the introduction of the
> >>Qualcomm 8996 platform, we must support a variant of the communication
> >>mechanism that share many of the characteristics of SMD, but are different
> >>enough that it can't be done in a single implementation. As such there is
> >>enough benefit to do the necessary work and being able to make SMD a "rpmsg
> >>thingie".
> >>
> >>On-top of this series I have patches to switch the current smd clients over to
> >>rpmsg (and by that drop the existing SMD implementation).
> >>
> >>All this allows me to implement the new backend and reuse all existing SMD
> >>drivers with the new mechanism.
> >>
> >
> >RPM Communication has to supported even when IRQs are disabled. The most
> >important use of this communication is to set the wake up time for the
> >CPU subsystem when all the CPUs are powered off. In addition to that,
> >"sleep" votes that are sent by the application processor subsystem to
> >allow system to go into deep sleep modes can only be triggered when the
> >CPU PM domains are power collapsed, drivers do not have a knowledge of
> >when that happens. This has to be done by a platform code that registers
> >for CPU PM domain power_off/on callbacks.
> >
> Ok, my bad. These two cases are not critical for the SoC supported by
> this driver. So you are good to go from cpuidle perspective
> 

Thanks for letting me know. Please keep me updated if you find any
changes to this.

Just to be clear, I'm not against supporting sending and receiving
messages in atomic context as long as it doesn't just add accidental
complexity.

Regards,
Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: bjorn.andersson@linaro.org (Bjorn Andersson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 00/17] Make rpmsg a framework
Date: Mon, 12 Sep 2016 15:58:55 -0700	[thread overview]
Message-ID: <20160912225855.GL405@tuxbot> (raw)
In-Reply-To: <20160912222240.GA28944@linaro.org>

On Mon 12 Sep 15:22 PDT 2016, Lina Iyer wrote:

> On Mon, Sep 12 2016 at 10:52 -0600, Lina Iyer wrote:
> >Hi Bjorn,
> >
> >On Thu, Sep 01 2016 at 16:28 -0600, Bjorn Andersson wrote:
> >>This series splits the virtio rpmsg bus driver into a rpmsg bus and a virtio
> >>backend/wireformat.
> >>
> >>
> >>As we discussed the Qualcomm SMD implementation a couple of years back people
> >>suggested that I should make it "a rpmsg thingie". With the introduction of the
> >>Qualcomm 8996 platform, we must support a variant of the communication
> >>mechanism that share many of the characteristics of SMD, but are different
> >>enough that it can't be done in a single implementation. As such there is
> >>enough benefit to do the necessary work and being able to make SMD a "rpmsg
> >>thingie".
> >>
> >>On-top of this series I have patches to switch the current smd clients over to
> >>rpmsg (and by that drop the existing SMD implementation).
> >>
> >>All this allows me to implement the new backend and reuse all existing SMD
> >>drivers with the new mechanism.
> >>
> >
> >RPM Communication has to supported even when IRQs are disabled. The most
> >important use of this communication is to set the wake up time for the
> >CPU subsystem when all the CPUs are powered off. In addition to that,
> >"sleep" votes that are sent by the application processor subsystem to
> >allow system to go into deep sleep modes can only be triggered when the
> >CPU PM domains are power collapsed, drivers do not have a knowledge of
> >when that happens. This has to be done by a platform code that registers
> >for CPU PM domain power_off/on callbacks.
> >
> Ok, my bad. These two cases are not critical for the SoC supported by
> this driver. So you are good to go from cpuidle perspective
> 

Thanks for letting me know. Please keep me updated if you find any
changes to this.

Just to be clear, I'm not against supporting sending and receiving
messages in atomic context as long as it doesn't just add accidental
complexity.

Regards,
Bjorn

  reply	other threads:[~2016-09-12 22:58 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-01 22:27 [PATCH v2 00/17] Make rpmsg a framework Bjorn Andersson
2016-09-01 22:27 ` Bjorn Andersson
2016-09-01 22:27 ` [PATCH v2 01/17] rpmsg: Enable matching devices with drivers based on DT Bjorn Andersson
2016-09-01 22:27   ` Bjorn Andersson
2016-09-01 22:27   ` Bjorn Andersson
2016-09-08  1:46   ` spjoshi
2016-09-08  1:46     ` spjoshi at codeaurora.org
2016-09-09  4:30     ` Bjorn Andersson
2016-09-09  4:30       ` Bjorn Andersson
2016-09-09 22:07       ` Sarangdhar Joshi
2016-09-09 22:07         ` Sarangdhar Joshi
2016-09-01 22:27 ` [PATCH v2 02/17] rpmsg: Name rpmsg devices based on channel id Bjorn Andersson
2016-09-01 22:27   ` Bjorn Andersson
2016-09-01 22:27   ` Bjorn Andersson
2016-09-08  1:46   ` spjoshi
2016-09-08  1:46     ` spjoshi at codeaurora.org
2016-09-01 22:27 ` [PATCH v2 03/17] rpmsg: rpmsg_send() operations takes rpmsg_endpoint Bjorn Andersson
2016-09-01 22:27   ` Bjorn Andersson
2016-09-01 22:27 ` [PATCH v2 04/17] rpmsg: Make rpmsg_create_ept() take channel_info struct Bjorn Andersson
2016-09-01 22:27   ` Bjorn Andersson
2016-09-01 22:27   ` Bjorn Andersson
2016-09-01 22:27 ` [PATCH v2 05/17] rpmsg: Clean up rpmsg device vs channel naming Bjorn Andersson
2016-09-01 22:27   ` Bjorn Andersson
2016-09-01 22:27   ` Bjorn Andersson
2016-09-01 22:27 ` [PATCH v2 06/17] rpmsg: Introduce indirection table for rpmsg_device operations Bjorn Andersson
2016-09-01 22:27   ` Bjorn Andersson
2016-09-01 22:27 ` [PATCH v2 07/17] rpmsg: Move rpmsg_device API to new file Bjorn Andersson
2016-09-01 22:27   ` Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 08/17] rpmsg: Indirection table for rpmsg_endpoint operations Bjorn Andersson
2016-09-01 22:28   ` Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 09/17] rpmsg: Move endpoint related interface to rpmsg core Bjorn Andersson
2016-09-01 22:28   ` Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 10/17] rpmsg: Move helper for finding rpmsg devices to core Bjorn Andersson
2016-09-01 22:28   ` Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 11/17] rpmsg: Split off generic tail of create_channel() Bjorn Andersson
2016-09-01 22:28   ` Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 12/17] rpmsg: Split rpmsg core and virtio backend Bjorn Andersson
2016-09-01 22:28   ` Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 13/17] rpmsg: Hide rpmsg indirection tables Bjorn Andersson
2016-09-01 22:28   ` Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 14/17] rpmsg: virtio: Hide vrp pointer from the public API Bjorn Andersson
2016-09-01 22:28   ` Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 15/17] rpmsg: Move virtio specifics from public header Bjorn Andersson
2016-09-01 22:28   ` Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 16/17] rpmsg: Allow callback to return errors Bjorn Andersson
2016-09-01 22:28   ` Bjorn Andersson
2016-09-01 22:28 ` [PATCH v2 17/17] rpmsg: Introduce Qualcomm SMD backend Bjorn Andersson
2016-09-01 22:28   ` Bjorn Andersson
2016-09-12 16:52 ` [PATCH v2 00/17] Make rpmsg a framework Lina Iyer
2016-09-12 16:52   ` Lina Iyer
2016-09-12 18:00   ` Bjorn Andersson
2016-09-12 18:00     ` Bjorn Andersson
2016-09-12 18:13     ` Jeffrey Hugo
2016-09-12 18:13       ` Jeffrey Hugo
2016-09-12 18:49       ` Bjorn Andersson
2016-09-12 18:49         ` Bjorn Andersson
2016-09-12 19:21         ` Jeffrey Hugo
2016-09-12 19:21           ` Jeffrey Hugo
2016-09-12 19:58           ` Bjorn Andersson
2016-09-12 19:58             ` Bjorn Andersson
2016-09-12 21:36             ` Karthikeyan Ramasubramanian
2016-09-12 21:36               ` Karthikeyan Ramasubramanian
2016-09-12 21:53               ` Bjorn Andersson
2016-09-12 21:53                 ` Bjorn Andersson
2016-09-12 22:22   ` Lina Iyer
2016-09-12 22:22     ` Lina Iyer
2016-09-12 22:58     ` Bjorn Andersson [this message]
2016-09-12 22:58       ` Bjorn Andersson

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=20160912225855.GL405@tuxbot \
    --to=bjorn.andersson@linaro.org \
    --cc=lina.iyer@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=ohad@wizery.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.