linux-kernel - Re: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABb+yY3nSZCbF7G1LP_7cGkKJpdJ1fko_6d3UkrF_vNpHk4uBg@mail.gmail.com>
Date:	Thu, 11 Feb 2016 09:53:29 +0530
From:	Jassi Brar <jassisinghbrar@...il.com>
To:	Nishanth Menon <nm@...com>
Cc:	Devicetree List <devicetree@...r.kernel.org>,
	Franklin S Cooper Jr <fcooper@...com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Santosh Shilimkar <ssantosh@...nel.org>
Subject: Re: [PATCH 1/2] Documentation: dt: mailbox: Add TI Message Manager

On Tue, Feb 9, 2016 at 11:40 PM, Nishanth Menon <nm@...com> wrote:
> On 09:43-20160209, Nishanth Menon wrote:
>> On Tue, Feb 9, 2016 at 8:54 AM, Jassi Brar <jassisinghbrar@...il.com> wrote:
> [..]
>> Let me prototype this as part of of_xlate and see if I can pull the
>> qinst data back out.. obviously one negative will be that I will
>> register *all* valid channels as part of probe.. at least based on
>> initial code i wrote today morning..
>
> OK - I believe I have it working now. How does the following look? If
> this looks fine to you, then I will post a v2 including the driver
> update.
> Changes here:
>         - dropped the generic message-manager compatible
>         - dropped child nodes
>         - moved the valid queue information to driver (no longer in dts)
>         - rx interrupts per SoC are explicitly named list in binding(and
>           dts)
>
> Texas Instruments' Message Manager Driver
> ========================================
>
> The Texas Instruments' Message Manager is a mailbox controller that has
> configurable queues selectable at SoC(System on Chip) integration. The Message
> manager is broken up into queues in different address regions that are called
> "proxies" - each instance is unidirectional and is instantiated at SoC
> integration level to indicate receive or transmit path.
>
> Message Manager Device Node:
> ===========================
> Required properties:
> --------------------
> - compatible:           Shall be: "ti,k2g-message-manager"
> - reg-names             queue_proxy_region - Map the queue proxy region.
>                         queue_state_debug_region - Map the queue state debug
>                         region.
> - reg:                  Contains the register map per reg-names.
> - #mbox-cells           Shall be 2. Contains the queue ID and proxy ID in that
>                         order referring to the transfer path.
> - interrupt-names:      Contains interrupt names matching the rx transfer path
>                         for a given SoC. Receive interrupts shall be of the
>                         format: "rx_<QID>_<PID>".
>                         For ti,k2g-message-manager, this shall contain:
>                                 "rx_005_002", "rx_057_002"
> - interrupts:           Contains the interrupt information corresponding to
>                         interrupt-names property.
>
> Example(K2G):
> ------------
>
>         msgmgr: msgmgr@...00000 {
>                 compatible = "ti,k2g-message-manager";
>                 #mbox-cells = <2>;
>                 reg-names = "queue_proxy_region", "queue_state_debug_region";
>                 reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
>                 interrupt-names = "rx_005_002",
>                                   "rx_057_002";
>
Looking at figure in page-1445, it seems QID is the h/w channel id,
while proxy is its programming parameter. So maybe we need to list all
the ARM irq's as a list here, matched only by the qid asked by the
consumer ... assuming no two channels could have the same qid (?).

  interrupt-names = "irq_005", "irq_037", "irq_049", "irq_057",
"perr", "ferr", "eerr";

I may be slightly off, but the idea remains to not have to encode any
consumer specific info in the provider node.

>         pmmc: pmmc {
>                 [...]
>                 mbox-names = "rx", "tx";
>                 # RX queue ID is 5, proxy ID is 2
>                 # TX queue ID is 0, proxy ID is 0
>                 mboxes= <&msgmgr 5 2>,
>                         <&msgmgr 0 0>;
>                 [...]
>         };