Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1438917

Re: [PATCH V2 05/10] firmware: tegra: add BPMP support

From Stephen Warren <swarren@wwwdotorg.org>
Newsgroups linux.kernel
Subject Re: [PATCH V2 05/10] firmware: tegra: add BPMP support
Date 2016-07-07 22:00 +0200
Message-ID <rSnCO-2WC-27@gated-at.bofh.it> (permalink)
References <rRuwF-MJ-15@gated-at.bofh.it> <rRuwG-MJ-35@gated-at.bofh.it> <rRTEJ-iL-5@gated-at.bofh.it> <rScHq-4lY-81@gated-at.bofh.it> <rSezv-5yn-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 07/07/2016 04:18 AM, Alexandre Courbot wrote:
> On Thu, Jul 7, 2016 at 5:17 PM, Joseph Lo <josephl@nvidia.com> wrote:
>> On 07/06/2016 07:39 PM, Alexandre Courbot wrote:
>>>
>>> Sorry, I will probably need to do several passes on this one to
>>> understand everything, but here is what I can say after a first look:
>>>
>>> On Tue, Jul 5, 2016 at 6:04 PM, Joseph Lo <josephl@nvidia.com> wrote:
>>>>
>>>> The Tegra BPMP (Boot and Power Management Processor) is designed for the
>>>> booting process handling, offloading the power management tasks and
>>>> some system control services from the CPU. It can be clock, DVFS,
>>>> thermal/EDP, power gating operation and system suspend/resume handling.
>>>> So the CPU and the drivers of these modules can base on the service that
>>>> the BPMP firmware driver provided to signal the event for the specific PM
>>>> action to BPMP and receive the status update from BPMP.
>>>>
>>>> Comparing to the ARM SCPI, the service provided by BPMP is message-based
>>>> communication but not method-based. The BPMP firmware driver provides the
>>>> send/receive service for the users, when the user concerns the response
>>>> time. If the user needs to get the event or update from the firmware, it
>>>> can request the MRQ service as well. The user needs to take care of the
>>>> message format, which we call BPMP ABI.
>>>>
>>>> The BPMP ABI defines the message format for different modules or usages.
>>>> For example, the clock operation needs an MRQ service code called
>>>> MRQ_CLK with specific message format which includes different sub
>>>> commands for various clock operations. This is the message format that
>>>> BPMP can recognize.
>>>>
>>>> So the user needs two things to initiate IPC between BPMP. Get the
>>>> service from the bpmp_ops structure and maintain the message format as
>>>> the BPMP ABI defined.

>>>> +static struct tegra_bpmp *bpmp;
>>>
>>> static? Ok, we only need one... for now. How about a private member in
>>> your ivc structure that allows you to retrieve the bpmp and going
>>> dynamic? This will require an extra argument in many functions, but is
>>> cleaner design IMHO.
>>
>> IVC is designed as a generic IPC protocol among different modules (We have
>> not introduced some other usages of the IVC right now.). Maybe don't churn
>> some other stuff into IVC is better.
>
> Anything is fine if you can get rid of that static.

Typically the way this is handled is to store the "struct ivc" inside 
some other struct, and use the container_of macro to "move" from a 
"struct ivc *" to a "struct XXX *" where "struct XXX" contains a "struct 
ivc" field within it. That way, the IVC code's "struct ivc" knows 
nothing about any IVC client's code/structures/..., doesn't have to 
store any "client data", and yet the IVC client (the BPMP driver) can 
acquire a "struct bpmp" pointer from any "struct ivc" pointer that it 
"owns".

struct bpmp_mbox {
     struct bpmp *bpmp;
     struct ivc ivc;
};

void bpmp_call_ivc(struct bpmp_mbox *mb) {
     ivc_something(&mb->ivc);
}

void bpmp_callback_from_ivc(struct ivc *ivc) {
     struct bpmp_mbox *mb = container_of(struct bpmp_mbox, ivc, ivc);
     struct bpmp *bpmp = mb->bpmp;
}

(I didn't check if I got the parameters to container_of correct above)

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH V2 00/10] arm64: tegra: add BPMP support Joseph Lo <josephl@nvidia.com> - 2016-07-05 11:10 +0200
  [PATCH V2 02/10] mailbox: tegra-hsp: Add HSP(Hardware Synchronization Primitives) driver Joseph Lo <josephl@nvidia.com> - 2016-07-05 11:10 +0200
    Re: [PATCH V2 02/10] mailbox: tegra-hsp: Add HSP(Hardware  Synchronization Primitives) driver Alexandre Courbot <gnurou@gmail.com> - 2016-07-06 09:10 +0200
      Re: [PATCH V2 02/10] mailbox: tegra-hsp: Add HSP(Hardware  Synchronization Primitives) driver Joseph Lo <josephl@nvidia.com> - 2016-07-06 11:10 +0200
        Re: [PATCH V2 02/10] mailbox: tegra-hsp: Add HSP(Hardware  Synchronization Primitives) driver Alexandre Courbot <gnurou@gmail.com> - 2016-07-06 14:30 +0200
          Re: [PATCH V2 02/10] mailbox: tegra-hsp: Add HSP(Hardware  Synchronization Primitives) driver Joseph Lo <josephl@nvidia.com> - 2016-07-07 08:40 +0200
            Re: [PATCH V2 02/10] mailbox: tegra-hsp: Add HSP(Hardware  Synchronization Primitives) driver Sivaram Nair <sivaramn@nvidia.com> - 2016-07-07 23:40 +0200
        Re: [PATCH V2 02/10] mailbox: tegra-hsp: Add HSP(Hardware  Synchronization Primitives) driver Stephen Warren <swarren@wwwdotorg.org> - 2016-07-06 19:00 +0200
          Re: [PATCH V2 02/10] mailbox: tegra-hsp: Add HSP(Hardware  Synchronization Primitives) driver Joseph Lo <josephl@nvidia.com> - 2016-07-07 08:50 +0200
    Re: [PATCH V2 02/10] mailbox: tegra-hsp: Add HSP(Hardware  Synchronization Primitives) driver Sivaram Nair <sivaramn@nvidia.com> - 2016-07-07 23:20 +0200
  [PATCH V2 07/10] arm64: defconfig: Enable Tegra186 SoC Joseph Lo <josephl@nvidia.com> - 2016-07-05 11:10 +0200
  [PATCH V2 09/10] arm64: dts: tegra: Add NVIDIA Tegra186 P3310 main board support Joseph Lo <josephl@nvidia.com> - 2016-07-05 11:10 +0200
  [PATCH V2 10/10] arm64: dts: tegra: Add NVIDIA P2771 board support Joseph Lo <josephl@nvidia.com> - 2016-07-05 11:10 +0200
  [PATCH V2 04/10] firmware: tegra: add IVC library Joseph Lo <josephl@nvidia.com> - 2016-07-05 11:10 +0200
    Re: [PATCH V2 04/10] firmware: tegra: add IVC library Alexandre Courbot <gnurou@gmail.com> - 2016-07-07 13:20 +0200
    Re: [PATCH V2 04/10] firmware: tegra: add IVC library Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-07-10 01:50 +0200
  [PATCH V2 08/10] arm64: dts: tegra: Add Tegra186 support Joseph Lo <josephl@nvidia.com> - 2016-07-05 11:10 +0200
  [PATCH V2 06/10] soc/tegra: Add Tegra186 support Joseph Lo <josephl@nvidia.com> - 2016-07-05 11:10 +0200
  Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add  bindings of the BPMP Alexandre Courbot <gnurou@gmail.com> - 2016-07-06 13:50 +0200
    Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add  bindings of the BPMP Joseph Lo <josephl@nvidia.com> - 2016-07-07 08:30 +0200
  Re: [PATCH V2 05/10] firmware: tegra: add BPMP support Alexandre Courbot <gnurou@gmail.com> - 2016-07-06 14:00 +0200
    Re: [PATCH V2 05/10] firmware: tegra: add BPMP support Stephen Warren <swarren@wwwdotorg.org> - 2016-07-06 18:50 +0200
    Re: [PATCH V2 05/10] firmware: tegra: add BPMP support Matt Longnecker <mlongnecker@nvidia.com> - 2016-07-06 18:50 +0200
      Re: [PATCH V2 05/10] firmware: tegra: add BPMP support Alexandre Courbot <gnurou@gmail.com> - 2016-07-07 04:30 +0200
    Re: [PATCH V2 05/10] firmware: tegra: add BPMP support Joseph Lo <josephl@nvidia.com> - 2016-07-07 10:20 +0200
      Re: [PATCH V2 05/10] firmware: tegra: add BPMP support Alexandre Courbot <gnurou@gmail.com> - 2016-07-07 12:20 +0200
        Re: [PATCH V2 05/10] firmware: tegra: add BPMP support Stephen Warren <swarren@wwwdotorg.org> - 2016-07-07 22:00 +0200
        Re: [PATCH V2 05/10] firmware: tegra: add BPMP support Sivaram Nair <sivaramn@nvidia.com> - 2016-07-08 22:30 +0200
  Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add  bindings of the BPMP Stephen Warren <swarren@wwwdotorg.org> - 2016-07-06 19:10 +0200
    Re: [PATCH V2 03/10] Documentation: dt-bindings: firmware: tegra: add  bindings of the BPMP Joseph Lo <josephl@nvidia.com> - 2016-07-07 08:30 +0200

csiph-web