mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Yojana Mallik <y-mallik@ti.com>
Cc: schnelle@linux.ibm.com, wsa+renesas@sang-engineering.com,
	diogo.ivo@siemens.com, rdunlap@infradead.org, horms@kernel.org,
	vigneshr@ti.com, rogerq@ti.com, danishanwar@ti.com,
	pabeni@redhat.com, kuba@kernel.org, edumazet@google.com,
	davem@davemloft.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, srk@ti.com, rogerq@kernel.org,
	Siddharth Vadapalli <s-vadapalli@ti.com>
Subject: Re: [PATCH net-next v2 2/3] net: ethernet: ti: Register the RPMsg driver as network device
Date: Sun, 16 Jun 2024 18:19:18 +0200	[thread overview]
Message-ID: <efff16aa-33d9-45eb-ac42-86f3411abfc9@lunn.ch> (raw)
In-Reply-To: <60bc57a7-732b-4dcb-ae72-158639a635c0@ti.com>

> The Linux Remoteproc driver which initializes remote processor cores carves out
> a section from DDR memory as reserved memory for each remote processor on the
> SOC. This memory region has been reserved in the Linux device tree file as
> reserved-memory. Out of this reserved memory for R5 core some memory is
> reserved for shared memory.

I don't know much about rpmsg, so i read the documentation:

https://docs.kernel.org/staging/rpmsg.html

There is no mention of carving out a region of DDR memory. It says
nothing about memory reserved in DT.

The API is pretty much: Please send these bytes to the peer. Call this
callback when bytes have been received from a peer.

> The shared memory is divided into two distinct regions:
> one for the A53 -> R5 data path (Tx buffer for Linux), and other for R5 -> A53
> data path (Rx buffer for Linux).

As i said in my previous message. Forget about the A54->R5. Think
about a generic architecture. You have an RPMSG facility using the API
described in the documentation. You have a block of shared
memory. That memory could be VRAM, it could be a dual port SRAM, a PCI
BAR region, or some DDR which both CPU have mapped into their address
space. Design a protocol around that. This might mean you need to
modify your firmware. It might mean you need to throw away your
firmware and start again. But for mainline, we want something generic
which any vendor can use with a wide range of hardware, with as few
assumptions as possible.

	Andrew

  reply	other threads:[~2024-06-16 16:19 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-31  6:40 [PATCH net-next v2 0/3] Introducing Intercore Virtual Ethernet (ICVE) driver Yojana Mallik
2024-05-31  6:40 ` [PATCH net-next v2 1/3] net: ethernet: ti: RPMsg based shared memory ethernet driver Yojana Mallik
2024-05-31 15:30   ` Randy Dunlap
2024-06-03  5:50     ` Yojana Mallik
2024-06-02  7:01   ` Siddharth Vadapalli
2024-06-03  6:16     ` Yojana Mallik
2024-06-02 16:21   ` Andrew Lunn
2024-06-03  8:56     ` Yojana Mallik
2024-06-03 12:54       ` Andrew Lunn
2024-05-31  6:40 ` [PATCH net-next v2 2/3] net: ethernet: ti: Register the RPMsg driver as network device Yojana Mallik
2024-06-01  3:13   ` kernel test robot
2024-06-03  9:26     ` Yojana Mallik
2024-06-02  7:22   ` Siddharth Vadapalli
2024-06-02 15:54     ` Andrew Lunn
2024-06-02  7:35   ` Siddharth Vadapalli
2024-06-02 16:45   ` Andrew Lunn
2024-06-04  6:23     ` Yojana Mallik
2024-06-04 12:54       ` Andrew Lunn
2024-06-12 12:52         ` Yojana Mallik
2024-06-12 14:59           ` Andrew Lunn
2024-06-14  9:08             ` Yojana Mallik
2024-06-16 16:19               ` Andrew Lunn [this message]
2024-06-16 19:03                 ` Andrew Lunn
2024-06-04 13:00       ` Andrew Lunn
2024-06-12 12:49         ` Yojana Mallik
2024-06-12 14:36           ` Andrew Lunn
2024-05-31  6:40 ` [PATCH net-next v2 3/3] net: ethernet: ti: icve: Add support for multicast filtering Yojana Mallik
2024-06-03 21:27   ` kernel test robot
2024-06-02 15:45 ` [PATCH net-next v2 0/3] Introducing Intercore Virtual Ethernet (ICVE) driver Andrew Lunn
2024-06-03 23:54   ` Jakub Kicinski
2024-06-12 12:48   ` Yojana Mallik

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=efff16aa-33d9-45eb-ac42-86f3411abfc9@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=danishanwar@ti.com \
    --cc=davem@davemloft.net \
    --cc=diogo.ivo@siemens.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=rogerq@kernel.org \
    --cc=rogerq@ti.com \
    --cc=s-vadapalli@ti.com \
    --cc=schnelle@linux.ibm.com \
    --cc=srk@ti.com \
    --cc=vigneshr@ti.com \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=y-mallik@ti.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

all inboxes | Powered by JetHome®