[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJK669ZcH-GTrkCZRMjDnr2pBjODifCHcSXCvceFPQtqZyZftg@mail.gmail.com>
Date: Thu, 6 Dec 2012 20:45:31 +0100
From: Sjur Brændeland <sjurbren@...il.com>
To: Ohad Ben-Cohen <ohad@...ery.com>
Cc: linux-kernel@...r.kernel.org,
Omar Ramirez Luna <omar.ramirez@...com>,
Fernando Guzman Lugo <fernando.lugo@...com>,
Suman Anna <s-anna@...com>, Bhavin Shah <bshah@...com>
Subject: Re: [RFC 1/4] remoteproc: Bugfix assign device address to carveout (noiommu)
Hi Ohad,
On Sat, Aug 11, 2012 at 2:34 PM, Ohad Ben-Cohen <ohad@...ery.com> wrote:
> On Fri, Aug 10, 2012 at 6:30 PM, Ohad Ben-Cohen <ohad@...ery.com> wrote:
>> This will solve all sort of open issues we have (or going to have soon):
>>
...
> 1. dynamically-allocated address of the vrings can be communicated
> 2. vdev statuses can be communicated
> 3. virtio config space will finally become bi-directional as it should
I just posted a RFC patch-set on this to linux-kernel@...r.kernel.org.
Review comments is welcomed :-)
> and 5. let the remote processor know about the notifyids that we've
> dynamically allocated.
I have run into one issue with the dynamically allocated notifyids. When
allocating multiple virtio devices, only ids for the first virtio
device is allocated
when the remote device is started. This is fails for me, because I need to know
all of the kick-ids before starting the remote device.
Do you have any preference on how to solve this, Ohad?
One idea could be to call rproc->start from a work-queue and wait for completion
of firmware loading before actually starting. In this way we will not
trigger start-up
of the remote device before all virtio devices and their kick-ids are allocated.
Thanks,
Sjur
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists