On Wed, Jan 25, 2012 at 4:19 PM, Michal Simek wrote:
> I started with pur vanilla kernel and patches from your tree
> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
> for-next branch
> but then I had to moved to for-next-acked-merged because in the origin
> one were some problem
On Thu, Jan 26, 2012 at 12:44 PM, Michal Simek wrote:
> I have one small problem which is that physical address is 0x1000
> which means that firmware entry point is the same.
This is what we do with the davinci DSPs, too.
> In rproc_load_segments is da composed from phdr->p_paddr which is
>
On Mon, Feb 13, 2012 at 3:20 PM, Michal Simek wrote:
> Here is how it is achieve
> ret = dma_declare_coherent_memory(&zynq_freertos.dev, 0,
> 0, 0x1000, DMA_MEMORY_MAP);
>
> which is fully compatible with remoteproc.
Great, this is what we've been doing w
On Thu, Feb 16, 2012 at 10:12 AM, Michal Simek wrote:
> I should be more specific. Can you point me to remoteproc code which publish
> remote service based on them Linux rpmsg driver will be probed? It is rtos
> part of code.
> In your ELCE presentation is called rpmsg-client-sample service.
Sorr
On Thu, Feb 16, 2012 at 2:07 PM, Michal Simek wrote:
> Above is condition "if (virtio_has_feature(vdev, VIRTIO_RPMSG_F_NS))" which
> is failing for me.
You might want to debug why.
For the dynamic channel creation to work, your rpmsg vdev should have
VIRTIO_RPMSG_F_NS. But that's part of the gen
On Thu, Feb 16, 2012 at 2:22 PM, Michal Simek wrote:
> ok on that addresses above is mapped vring_desc structure. I expect that
> addr is address to any memory location when data are places. Next is filled
> by init because of ring buffer. What flags should be used? And what is data
> structure?
On Thu, Feb 16, 2012 at 9:21 PM, Michal Simek wrote:
> IRC in init part Linux kick rtos which send which services are available.in
> any format which is unknown to me.
Check out struct rpmsg_ns_msg - that's the exact format of the name
service notification messages (it's also mentioned by
Documen
Hi Michal,
On Mon, Feb 20, 2012 at 4:22 PM, Michal Simek wrote:
> IRC you mentioned somewhere that you maybe will have firmware which is
> possible to
> compiled by gcc and which doesn't required that TI tools. Am I correct or
> that was
> something totally different?
You're correct - this is in
On Wed, Feb 22, 2012 at 2:10 PM, Michal Simek wrote:
> That will be great to get it. Please let me know when you have them.
Will do.
Thanks,
Ohad.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
Hi Michal,
On Tue, Mar 6, 2012 at 5:22 PM, Michal Simek wrote:
> 3) CGT TMS470: 4.9.0
> Public Links:-
> TMS470 Compiler is not available for free publicly. Please
> contact your TI representative.
I think you need those tools and can't build the image without them
(Mar
Hi Michal,
On Tue, Mar 13, 2012 at 11:41 AM, Michal Simek wrote:
> What do you think?
I'd really prefer to see some code to make sure I understand exactly
what you mean.
Any change you can post something ?
Maybe even just the hard coded forwarding implementation you have today.
Thanks,
Ohad.
Hi Michal,
On Mon, Mar 19, 2012 at 3:38 PM, Michal Simek wrote:
> Maybe I am trying to do things more complicated than they are but
> I still see that make sense to do it.
I agree, it definitely does.
OMAP4 is using this kind of resource allocation for a plethora of resources.
In general there
Signed-off-by: Benoit Cousson
> Cc: Grant Likely
> Cc: Ohad Ben-Cohen
> ---
...
> + spinlock {
> + compatible = "ti,omap-spinlock";
> + hwmods = "spinlock";
> + };
This seem to satisfy t
Hi Benoit,
On Thu, Sep 8, 2011 at 10:14 AM, Cousson, Benoit wrote:
> Hehe, I'm not the one who wrote that driver :-)
>
> This is not wrong for the current HW. The point is do we want to anticipate
> potential HW evolution that might never happen on that IP?
I originally really thought we can ign
On Thu, Sep 8, 2011 at 11:07 AM, Cousson, Benoit wrote:
> The (small) issue for my point of view is that the #hwspinlock is already
> encoded in the IP itself. So adding a baseid directly in DT will look like
> duplicating indirectly something that is already there in the HW.
> That being said, si
On Thu, Sep 8, 2011 at 5:47 PM, Arnd Bergmann wrote:
> I think a number would work here but is not optimal for the device tree
> representation. I think a better binding would be to encode it like
> interrupt numbers, where every device that uses a hwspinlock will describe
> that as a combination
On Fri, Sep 9, 2011 at 3:58 PM, Arnd Bergmann wrote:
> For dynamic allocation, my impression is that we don't
> need any link from the spinlock user device to the controller at all,
I agree.
> but instead the controller should have a list of the available
> spinlocks.
Might make more sense to g
Hi Benoit,
On Mon, Sep 26, 2011 at 7:50 PM, Benoit Cousson wrote:
> +++ b/Documentation/devicetree/bindings/hwspinlock/omap-spinlock.txt
> @@ -0,0 +1,5 @@
> +* HW spinlock on OMAP4 platform:
> +
> +Required properties:
> +- compatible : Must be "ti,omap4-spinlock";
> +- ti,hwmods : "spinlock"
> d
On Wed, Jun 27, 2012 at 8:17 AM, Michal Simek wrote:
> Ohad: What properties are required by TI to describe firmware?
> I would like to add together all requirements and create any formal
> remoteproc description.
I'm not so sure about this.
The low level remoteproc driver is platform specific a
19 matches
Mail list logo
