RE: [PATCH v9 1/6] rpmsg: Process all available messages in virtqueue callback
Just one small fix needed (see below) and it's good-to-go.
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Tuesday, April 09, 2013 1:26 AM
On Tue, Apr 9, 2013 at 1:56 AM, Tivy, Robert rt...@ti.com wrote:
Shouldn't the virtqueue_kick() be called only when we successfully
added a buffer with virtqueue_add_buf()?
Definitely, thanks for noticing!
Take 2:
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
b/drivers/rpmsg/virtio_rpmsg_bus.c
index a59684b..4ade672 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -776,22 +776,11 @@ out:
}
EXPORT_SYMBOL(rpmsg_send_offchannel_raw);
-/* called when an rx buffer is used, and it's time to digest a message
*/
-static void rpmsg_recv_done(struct virtqueue *rvq)
+static int rpmsg_recv_single(struct virtproc_info *vrp, struct device
*dev,
+struct rpmsg_hdr *msg, unsigned int len)
{
- struct rpmsg_hdr *msg;
- unsigned int len;
struct rpmsg_endpoint *ept;
struct scatterlist sg;
- struct virtproc_info *vrp = rvq-vdev-priv;
- struct device *dev = rvq-vdev-dev;
- int err;
This new function also uses an 'int err;', so the above line should not be
removed.
-
- msg = virtqueue_get_buf(rvq, len);
- if (!msg) {
- dev_err(dev, uhm, incoming signal, but no used buffer
?\n);
- return;
- }
dev_dbg(dev, From: 0x%x, To: 0x%x, Len: %d, Flags: %d,
Reserved: %d\n,
msg-src, msg-dst, msg-len,
@@ -806,7 +795,7 @@ static void rpmsg_recv_done(struct virtqueue *rvq)
if (len RPMSG_BUF_SIZE ||
msg-len (len - sizeof(struct rpmsg_hdr))) {
dev_warn(dev, inbound msg too big: (%d, %d)\n, len,
msg-len);
- return;
+ return -EINVAL;
}
/* use the dst addr to fetch the callback of the appropriate
user */
@@ -842,11 +831,42 @@ static void rpmsg_recv_done(struct virtqueue
*rvq)
err = virtqueue_add_buf(vrp-rvq, sg, 0, 1, msg, GFP_KERNEL);
if (err 0) {
dev_err(dev, failed to add a virtqueue buffer: %d\n,
err);
+ return err;
+ }
+
+ return 0;
+}
+
+/* called when an rx buffer is used, and it's time to digest a message
*/
+static void rpmsg_recv_done(struct virtqueue *rvq)
+{
+ struct virtproc_info *vrp = rvq-vdev-priv;
+ struct device *dev = rvq-vdev-dev;
+ struct rpmsg_hdr *msg;
+ unsigned int len, msgs_received = 0;
+ int err;
+
+ msg = virtqueue_get_buf(rvq, len);
+ if (!msg) {
+ dev_err(dev, uhm, incoming signal, but no used buffer
?\n);
return;
}
+ while (msg) {
+ err = rpmsg_recv_single(vrp, dev, msg, len);
+ if (err)
+ break;
+
+ msgs_received++;
+
+ msg = virtqueue_get_buf(rvq, len);
+ };
+
+ dev_dbg(dev, Received %u messages\n, msgs_received);
+
/* tell the remote processor we added another available rx
buffer */
- virtqueue_kick(vrp-rvq);
+ if (msgs_received)
+ virtqueue_kick(vrp-rvq);
}
/*
Thanks for the rewrite, looks better. I'll give it a try and let you
know how it goes.
Thanks!
Ohad.
I added the above-mentioned 'int err;' to my tree's rpmsg_recv_single() and
tested it out, it worked well. So once that is corrected, you can add:
Acked-by: Robert Tivy rt...@ti.com
Regards,
- Rob
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver implementation for OMAP-L13x DSP
Hi Ohad,
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Sunday, April 07, 2013 6:03 AM
To: Tivy, Robert
Cc: davinci-linux-open-source; linux-arm; Nori, Sekhar; Rob Landley;
linux-...@vger.kernel.org; Grosen, Mark; Ring, Chris
Subject: Re: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver
implementation for OMAP-L13x DSP
Hi Rob,
On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy rt...@ti.com wrote: +
+static int da8xx_rproc_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct da8xx_rproc *drproc;
+ struct rproc *rproc;
+ struct irq_data *irq_data;
+ struct resource *bootreg_res;
+ struct resource *chipsig_res;
+ struct clk *dsp_clk;
+ void __iomem *chipsig;
+ void __iomem *bootreg;
+ int irq;
+ int ret;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ dev_err(dev, platform_get_irq(pdev, 0) error: %d\n,
irq);
+ return irq;
+ }
+
+ irq_data = irq_get_irq_data(irq);
+ if (!irq_data) {
+ dev_err(dev, irq_get_irq_data(%d): NULL\n, irq);
+ return -EINVAL;
+ }
+
+ bootreg_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!bootreg_res) {
+ dev_err(dev,
+ platform_get_resource(IORESOURCE_MEM, 0):
NULL\n);
+ return -EADDRNOTAVAIL;
+ }
+
+ chipsig_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!chipsig_res) {
+ dev_err(dev,
+ platform_get_resource(IORESOURCE_MEM, 1):
NULL\n);
+ return -EADDRNOTAVAIL;
+ }
+
+ bootreg = devm_request_and_ioremap(dev, bootreg_res);
+ if (!bootreg) {
+ dev_err(dev, unable to map boot register\n);
+ return -EADDRNOTAVAIL;
+ }
+
+ chipsig = devm_request_and_ioremap(dev, chipsig_res);
+ if (!chipsig) {
+ dev_err(dev, unable to map CHIPSIG register\n);
+ return -EADDRNOTAVAIL;
+ }
+
+ dsp_clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(dsp_clk)) {
+ dev_err(dev, clk_get error: %ld\n,
PTR_ERR(dsp_clk));
+
+ return PTR_RET(dsp_clk);
+ }
+
+ rproc = rproc_alloc(dev, dsp, da8xx_rproc_ops,
da8xx_fw_name,
+ sizeof(*drproc));
+ if (!rproc)
+ return -ENOMEM;
+
+ drproc = rproc-priv;
+ drproc-rproc = rproc;
+
+ platform_set_drvdata(pdev, rproc);
+
+ /* everything the ISR needs is now setup, so hook it up */
+ ret = devm_request_threaded_irq(dev, irq,
da8xx_rproc_callback,
+ handle_event, 0, da8xx-remoteproc, rproc);
+ if (ret) {
+ dev_err(dev, devm_request_threaded_irq error: %d\n,
ret);
+ goto free_rproc;
+ }
+
+ /*
+* rproc_add() can end up enabling the DSP's clk with the DSP
+* *not* in reset, but da8xx_rproc_start() needs the DSP to
be
+* held in reset at the time it is called.
+*/
+ ret = reset_assert(dev);
+ if (ret)
+ goto free_rproc;
+
+ ret = rproc_add(rproc);
+ if (ret) {
+ dev_err(dev, rproc_add failed: %d\n, ret);
+ goto free_rproc;
+ }
+
+ drproc-chipsig = chipsig;
+ drproc-bootreg = bootreg;
+ drproc-ack_fxn = irq_data-chip-irq_ack;
+ drproc-irq_data = irq_data;
+ drproc-irq = irq;
+ drproc-dsp_clk = dsp_clk;
+
+ return 0;
+
+free_rproc:
+ rproc_put(rproc);
+
+ return ret;
+}
Two small changes please:
- could you please fix the error path of probe? it seems that some
resources are taken but not freed in case a failure shows up
subsequently
I'm not sure what resources you mean?
The platform_get_irq()/irq_get_irq_data()/platform_get_resource() calls don't
have put counterparts. The devm_* calls get automatically cleaned up (and
I wasn't able to find any existing example of some code that actually does the
cleanup explicitly).
- seems like it's safer to set drproc before calling rproc_add
otherwise you have a small race there
Agreed, will change.
If you could respin this one quickly it'd be great, thanks!
Ohad.
Sergei had a comment to change devm_request_and_ioremap() to
devm_ioremap_resource(), so I will submit a new patch with your and Sergei's
comments applied.
Regards,
- Rob
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v9 1/6] rpmsg: Process all available messages in virtqueue callback
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Sunday, April 07, 2013 5:51 AM
On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy rt...@ti.com wrote:
Change virtqueue callback function rpmsg_recv_done() to process all
available messages instead of just one message.
Signed-off-by: Robert Tivy rt...@ti.com
I'm thinking instead of adding an indentation level, let's split the
_recv function.
This is what I have in mind - let me know if it works for you - thanks:
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
b/drivers/rpmsg/virtio_rpmsg_bus.c
index a59684b..42b9872 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -776,22 +776,11 @@ out:
}
EXPORT_SYMBOL(rpmsg_send_offchannel_raw);
-/* called when an rx buffer is used, and it's time to digest a message
*/
-static void rpmsg_recv_done(struct virtqueue *rvq)
+static int rpmsg_recv_single(struct virtproc_info *vrp, struct device
*dev,
+struct rpmsg_hdr *msg, unsigned int len)
{
- struct rpmsg_hdr *msg;
- unsigned int len;
struct rpmsg_endpoint *ept;
struct scatterlist sg;
- struct virtproc_info *vrp = rvq-vdev-priv;
- struct device *dev = rvq-vdev-dev;
- int err;
-
- msg = virtqueue_get_buf(rvq, len);
- if (!msg) {
- dev_err(dev, uhm, incoming signal, but no used buffer
?\n);
- return;
- }
dev_dbg(dev, From: 0x%x, To: 0x%x, Len: %d, Flags: %d,
Reserved: %d\n,
msg-src, msg-dst, msg-len,
@@ -806,7 +795,7 @@ static void rpmsg_recv_done(struct virtqueue *rvq)
if (len RPMSG_BUF_SIZE ||
msg-len (len - sizeof(struct rpmsg_hdr))) {
dev_warn(dev, inbound msg too big: (%d, %d)\n, len,
msg-len);
- return;
+ return -EINVAL;
}
/* use the dst addr to fetch the callback of the appropriate
user */
@@ -842,9 +831,39 @@ static void rpmsg_recv_done(struct virtqueue *rvq)
err = virtqueue_add_buf(vrp-rvq, sg, 0, 1, msg, GFP_KERNEL);
if (err 0) {
dev_err(dev, failed to add a virtqueue buffer: %d\n,
err);
+ return err;
+ }
+
+ return 0;
+}
+
+/* called when an rx buffer is used, and it's time to digest a message
*/
+static void rpmsg_recv_done(struct virtqueue *rvq)
+{
+ struct virtproc_info *vrp = rvq-vdev-priv;
+ struct device *dev = rvq-vdev-dev;
+ struct rpmsg_hdr *msg;
+ unsigned int len, msgs_received = 0;
+ int err;
+
+ msg = virtqueue_get_buf(rvq, len);
+ if (!msg) {
+ dev_err(dev, uhm, incoming signal, but no used buffer
?\n);
return;
}
+ while (msg) {
+ err = rpmsg_recv_single(vrp, dev, msg, len);
+ if (err)
+ break;
+
+ msgs_received++;
+
+ msg = virtqueue_get_buf(rvq, len);
+ };
+
+ dev_dbg(dev, Received %u messages\n, msgs_received);
+
/* tell the remote processor we added another available rx
buffer */
virtqueue_kick(vrp-rvq);
}
Shouldn't the virtqueue_kick() be called only when we successfully added a
buffer with virtqueue_add_buf()?
If so, we should make it:
if (msgs_received)
/* tell the remote processor we added another available rx
buffer */
virtqueue_kick(vrp-rvp);
}
Thanks for the rewrite, looks better. I'll give it a try and let you know how
it goes.
Regards,
- Rob
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver implementation for OMAP-L13x DSP
Hi Sergei,
-Original Message-
From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
Sent: Sunday, April 07, 2013 10:55 AM
Hello.
On 04/07/2013 05:02 PM, Ohad Ben-Cohen wrote:
+static int da8xx_rproc_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct da8xx_rproc *drproc;
+ struct rproc *rproc;
+ struct irq_data *irq_data;
+ struct resource *bootreg_res;
+ struct resource *chipsig_res;
+ struct clk *dsp_clk;
+ void __iomem *chipsig;
+ void __iomem *bootreg;
+ int irq;
+ int ret;
+
[...]
+ bootreg = devm_request_and_ioremap(dev, bootreg_res);
+ if (!bootreg) {
+ dev_err(dev, unable to map boot register\n);
+ return -EADDRNOTAVAIL;
+ }
+
+ chipsig = devm_request_and_ioremap(dev, chipsig_res);
I suggest that you use more modern (yes, already a newer interface
:-)
devm_ioremap_resource() instead -- it returns the error code (as a
pointer)
in case of error, and it certainly doesn't require you to print error
messages.
Thanks, will do.
I appreciate the notice of a more modern function, it's really tough to keep up
with the flurry of activity to the kernel.
Regarding this change, should the code use
return PTR_ERR(bootreg);
or
return PTR_RET(bootreg);
I ask because PTR_ERR() returns 'long' whereas PTR_RET() returns 'int' (and
probe returns 'int'), but I see that the majority of existing code uses return
PTR_ERR() in probe functions.
+ if (!chipsig) {
+ dev_err(dev, unable to map CHIPSIG register\n);
+ return -EADDRNOTAVAIL;
+ }
WBR, Sergei
Regards,
- Rob
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v7 1/2] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
Hi Ohad,
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Friday, February 15, 2013 12:07 AM
Hi Rob,
On Fri, Feb 1, 2013 at 4:24 AM, Robert Tivy rt...@ti.com wrote:
drivers/remoteproc/Kconfig| 29 ++-
drivers/remoteproc/Makefile |1 +
drivers/remoteproc/da8xx_remoteproc.c | 346
+
drivers/remoteproc/remoteproc_core.c | 22 ++-
It looks like this patch squashes:
1. A fix to drivers/remoteproc/Kconfig
2. New functionality in remoteproc_core.c
3. A new da8xx driver
These are independent changes, so we better split them up to separate
patches.
Ok, I will submit separate patches for these. In doing so, I will have a
stand-alone patch for the drivers/remoteproc/Kconfig fix, as well as the
driver-related addition to that file in the driver patch. PCMIIW.
config OMAP_REMOTEPROC
tristate OMAP remoteproc support
- depends on EXPERIMENTAL
...
config STE_MODEM_RPROC
tristate STE-Modem remoteproc support
- depends on EXPERIMENTAL
These look unrelated to this patch, and it seems that Kees Cook
submitted these awhile ago so it should probably already be in
linux-next (haven't looked). I think we can drop these.
OK, will drop.
+/**
+ * handle_event() - inbound virtqueue message workqueue function
+ *
+ * This function is registered as a kernel thread and is scheduled
by the
+ * kernel handler.
+ */
+static irqreturn_t handle_event(int irq, void *p)
+{
+ struct rproc *rproc = (struct rproc *)p;
+
+ /* Process incoming buffers on our vring */
+ while (IRQ_HANDLED == rproc_vq_interrupt(rproc, 0))
+ ;
+
+ /* Must allow wakeup of potenitally blocking senders */
+ rproc_vq_interrupt(rproc, 1);
IIRC we agreed on removing this part, and instead adding it to the
generic remoteproc framework (i.e. Cyril's patch).
I didn't like the idea of having extra overhead when calling the all
virtqueues version.
We know that we want to call rproc_vq_interrupt(rproc, 1) just once, and don't
care about its return value. If we did
/* Process incoming buffers on our vring */
while (IRQ_HANDLED == rproc_vq_interrupt(rproc, -1))
;
then that would essentially turn into:
do {
ret = IRQ_NONE;
if (rproc_vq_interrupt(rproc, 0) == IRQ_HANDLED)
ret = IRQ_HANDLED;
if (rproc_vq_interrupt(rproc, 1) == IRQ_HANDLED)
ret = IRQ_HANDLED;
} while (ret == IRQ_HANDLED);
which will end up calling rproc_vq_interrupt(rproc, 1) too many times.
We have a benchmark goal to keep wrt/ the whole round-trip time of messages and
we're currently not even achieving that, so more overhead than today can't be
tolerated.
+static int da8xx_rproc_start(struct rproc *rproc)
+{
...
+ dsp_clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(dsp_clk)) {
+ dev_err(dev, clk_get error: %ld\n,
PTR_ERR(dsp_clk));
+
+ return PTR_RET(dsp_clk);
+ }
+ drproc-dsp_clk = dsp_clk;
Have you considered doing this in -probe() instead? Do we need to
call get/put every time we start/stop the remote processor?
I suppose we don't need to call it every time, I will try moving it to -probe()
+/* kick a virtqueue */
+static void da8xx_rproc_kick(struct rproc *rproc, int vqid)
+{
+ struct da8xx_rproc *drproc = (struct da8xx_rproc *)rproc-
priv;
+ int timed_out;
+ unsigned long timeout;
+
+ timed_out = 0;
+ timeout = jiffies + HZ/100;
+
+ /* Poll for ack from other side first */
+ while (readl(drproc-chipsig) SYSCFG_CHIPSIG2)
+ if (time_after(jiffies, timeout)) {
+ if (readl(drproc-chipsig) SYSCFG_CHIPSIG2)
{
+ dev_err(rproc-dev.parent,
+ failed to receive ack\n);
+ timed_out = 1;
+ }
+
+ break;
+ }
This still looks a bit out of place here.
Kicking should be a fast unilateral action, that doesn't depend on the
other side.
Ok, I'll drop this complexity.
While that code sorta looks like too much, in a smoothly working system it's
just a register read and single false if-test, since SYSCFG_CHIPSIG2 will
actually never be set there. If SYSCFG_CHIPSIG2 *is* set then it will likely
not unset and the timed_out situation will happen.
+static int da8xx_rproc_probe(struct platform_device *pdev)
+{
...
+ ret = rproc_add(rproc);
+ if (ret) {
+ dev_err(dev, rproc_add failed: %d\n, ret);
+ goto free_rproc;
+ }
+
+ drproc-chipsig = chipsig;
+ drproc-bootreg = bootreg;
+
RE: [PATCH v6 1/2] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
-Original Message- From: Sergei Shtylyov [mailto:sshtyl...@mvista.com] Sent: Saturday, January 26, 2013 7:22 AM Hello. On 26-01-2013 6:45, Robert Tivy wrote: Adding a remoteproc driver implementation for OMAP-L138 DSP diff --git a/drivers/remoteproc/da8xx_remoteproc.c b/drivers/remoteproc/da8xx_remoteproc.c new file mode 100644 index 000..c6eb6bf --- /dev/null +++ b/drivers/remoteproc/da8xx_remoteproc.c @@ -0,0 +1,327 @@ [...] +#define SYSCFG_CHIPSIG_OFFSET 0x174 +#define SYSCFG_CHIPSIG_CLR_OFFSET 0x178 Wait, you don't even use these #define's -- why they're here at all? WBR, Sergei I will remove those. They were inadvertently left over from when the driver was mapping SYSCFG0's base address and using those offsets to get to the CHIPSIG registers. Regards, - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v6 2/2] ARM: davinci: Remoteproc platform device creation data/code
Hi Sergei,
-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
Sent: Saturday, January 26, 2013 6:43 AM
Hello.
On 26-01-2013 6:45, Robert Tivy wrote:
Added a new remoteproc platform device for DA8XX. Contains CMA-based
reservation of physical memory block. A new kernel command-line
parameter has been added to allow boot-time specification of the
physical memory block.
No signoff again.
Thanks, I will fix this.
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-
davinci/devices-da8xx.c
index fb2f51b..a455e5c 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
[...]
@@ -706,6 +706,96 @@ int __init da850_register_mmcsd1(struct
davinci_mmc_config *config)
}
#endif
+static struct resource da8xx_rproc_resources[] = {
+ { /* DSP boot address */
+ .start = DA8XX_SYSCFG0_BASE +
DA8XX_HOST1CFG_REG,
+ .end= DA8XX_SYSCFG0_BASE + DA8XX_HOST1CFG_REG + 3,
+ .flags = IORESOURCE_MEM,
+ },
+ { /* DSP interrupt registers */
+ .start = DA8XX_SYSCFG0_BASE + DA8XX_CHIPSIG_REG,
+ .end= DA8XX_SYSCFG0_BASE + DA8XX_CHIPSIG_REG + 7,
+ .flags = IORESOURCE_MEM,
Does it really make sense to pass these as 2 resources -- they have
the
same base address?
I didn't want to impart that knowledge on the remoteproc driver. As far as the
driver is concerned, there is a boot address register and some
interrupt-related registers. That the boot address and interrupt-related
registers share the same base address is a device-specific fact.
+int __init da8xx_register_rproc(void)
+{
+ int ret;
+
+ ret = platform_device_register(da8xx_dsp);
+ if (ret) {
+ pr_err(%s: platform_device_register: %d\n, __func__,
ret);
Better message would be can't register DSP device.
Agreed, I will change this.
+
Empty line hardly needed here.
+ return ret;
Not needed here, just move it outside the {} to replace 'return 0'.
Thanks, I will change this.
Regards,
- Rob
+ }
+
+ return 0;
+};
+
WBR, Sergei
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v5 9/9] ARM: davinci: da850: Added dsp clock definition
-Original Message-
From: Nori, Sekhar
Sent: Tuesday, January 22, 2013 4:04 AM
Rob,
On 1/11/2013 5:53 AM, Robert Tivy wrote:
Added dsp clock definition, keyed to davinci-rproc.0.
Signed-off-by: Robert Tivy rt...@ti.com
---
arch/arm/mach-davinci/da850.c |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-
davinci/da850.c
index 097fcb2..50107c5 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -375,6 +375,14 @@ static struct clk sata_clk = {
.flags = PSC_FORCE,
};
+static struct clk dsp_clk = {
+ .name = dsp,
+ .parent = pll0_sysclk1,
+ .domain = DAVINCI_GPSC_DSPDOMAIN,
+ .lpsc = DA8XX_LPSC0_GEM,
+ .flags = PSC_LRST,
+};
+
static struct clk_lookup da850_clks[] = {
CLK(NULL, ref, ref_clk),
CLK(NULL, pll0, pll0_clk),
@@ -421,6 +429,7 @@ static struct clk_lookup da850_clks[] = {
CLK(spi_davinci.1,NULL, spi1_clk),
CLK(vpif, NULL, vpif_clk),
CLK(ahci, NULL, sata_clk),
+ CLK(davinci-rproc.0, NULL, dsp_clk),
Adding this clock node without the having the driver probed leads to
kernel hang while booting. With CONFIG_DAVINCI_RESET_CLOCKS=n, the
kernel boot fine. It looks like there is some trouble disabling the
clock if it is not used. Can you please check this issue?
Thanks,
Sekhar
Sekhar,
Thankyou for trying that out.
I discovered that the kernel boot hang is caused when trying to disable this
clk during init, from within the function davinci_clk_disable_unused(). That
function calls davinci_psc_config() which attempts to disable the DSP clock.
Since this clk is enabled after reset, disabling it involves a state
transition, and therefore the function must wait for GOSTAT[1] to be 0. For
most peripherals this happens automatically, but for the DSP (and ARM, too),
the DSP must execute the IDLE instruction to allow a clock enable-disable
transition. Since this is bootup and there is no real program on the DSP yet,
this doesn't happen.
I was able to overcome this by adding PSC_FORCE to the clk-flags for dsp_clk.
In fact, without PSC_FORCE I was not able to rmmod davinci_remoteproc since
the firmware file that I'm loading did not execute IDLE. It feels like for
davinci we should have a way to control the clk-flags' PSC_FORCE setting at
run-time. The PSC_FORCE would be set initially (during boot) and the user (or
system integrator) would have a way to unset it dynamically. That way, when
the DSP firmware does actually have a structured way to enter IDLE, the user
can say I'd like a structured shutdown and unset PSC_FORCE (via a clean API).
But for now I'm just going to turn on PSC_FORCE:
.flags = PSC_LRST | PSC_FORCE,
Thanks Regards,
- Rob
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
Russell, thankyou for the review and notice, all this will be straightened out
in the next patch submission.
Regards,
- Rob
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Monday, January 21, 2013 8:41 AM
To: Nori, Sekhar
Cc: Tivy, Robert; o...@wizery.com; davinci-linux-open-
sou...@linux.davincidsp.com; linux-...@vger.kernel.org; Ring, Chris;
r...@landley.net; Grosen, Mark; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for
OMAP-L138 DSP
On Mon, Jan 21, 2013 at 11:08:43AM +0530, Sekhar Nori wrote:
+ if (IS_ERR_OR_NULL(r)) {
+ dev_err(dev, platform_get_resource() error: %ld\n,
+ PTR_ERR(r));
+
+ return PTR_ERR(r);
Sigh. Bug.
+ }
+ host1cfg_physaddr = (unsigned long)r-start;
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ dev_err(dev, platform_get_irq(pdev, 0) error: %d\n, irq);
+
+ return irq;
+ }
+
+ irq_data = irq_get_irq_data(irq);
+ if (IS_ERR_OR_NULL(irq_data)) {
+ dev_err(dev, irq_get_irq_data(%d) error: %ld\n,
+ irq, PTR_ERR(irq_data));
+
+ return PTR_ERR(irq_data);
Bug.
+ }
+ ack_fxn = irq_data-chip-irq_ack;
+
+ ret = request_threaded_irq(irq, davinci_rproc_callback,
handle_event,
+ 0, davinci-remoteproc, drproc);
+ if (ret) {
+ dev_err(dev, request_threaded_irq error: %d\n, ret);
+
+ return ret;
+ }
+
+ syscfg0_base = ioremap(host1cfg_physaddr PAGE_MASK, SZ_4K);
+ host1cfg_offset = offset_in_page(host1cfg_physaddr);
+ writel(rproc-bootaddr, syscfg0_base + host1cfg_offset);
+
+ dsp_clk = clk_get(dev, NULL);
devm_clk_get() here.
+ if (IS_ERR_OR_NULL(dsp_clk)) {
+ dev_err(dev, clk_get error: %ld\n, PTR_ERR(dsp_clk));
+ ret = PTR_ERR(dsp_clk);
Bug.
See, yet again... almost every use of IS_ERR_OR_NULL() is a bug.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
-Original Message-
From: Nori, Sekhar
Sent: Sunday, January 20, 2013 9:39 PM
On 1/11/2013 5:53 AM, Robert Tivy wrote:
Adding a remoteproc driver implementation for OMAP-L138 DSP
Signed-off-by: Robert Tivy rt...@ti.com
---
drivers/remoteproc/Kconfig | 23 ++
drivers/remoteproc/Makefile|1 +
drivers/remoteproc/davinci_remoteproc.c| 307
include/linux/platform_data/da8xx-remoteproc.h | 33 +++
naming the driver davinci_remoteproc.c and platform data as
da8xx-remoteproc.h is odd. The driver looks really specific to omap-
l138
so may be call the driver da8xx-remoteproc.c?
At first when I started working on this stuff we intended to unify this naming,
to either davinci-based or da8xx-based, but after looking at it for a while
we realized that it is already so hopelessly mixed in many areas that it wasn't
worth the effort.
But for new stuff that's directly tied to omap-l138 we should be consistent, so
I agree. I'll change it to da8xx-remoteproc.c, at the same time changing all
the code/data names to be prefixed with da8xx_.
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 96ce101..7d3a5e0 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -41,4 +41,27 @@ config STE_MODEM_RPROC
This can be either built-in or a loadable module.
If unsure say N.
+config DAVINCI_REMOTEPROC
+ tristate DaVinci DA850/OMAPL138 remoteproc support
(EXPERIMENTAL)
+ depends on ARCH_DAVINCI_DA850
+ select REMOTEPROC
+ select RPMSG
+ select FW_LOADER
+ select CMA
+ default n
+ help
+ Say y here to support DaVinci DA850/OMAPL138 remote processors
+ via the remote processor framework.
+
+ You want to say y here in order to enable AMP
+ use-cases to run on your platform (multimedia codecs are
+ offloaded to remote DSP processors using this framework).
+
+ It's safe to say n here if you're not interested in multimedia
+ offloading or just want a bare minimum kernel.
+ This feature is considered EXPERIMENTAL, due to it not having
+ any previous exposure to the general public and therefore
+ limited developer-based testing.
This is probably true in general for remoteproc (I am being warned a
lot
by the framework when using it) so may be you can drop this specific
reference.
OK, we'll let the overlying REMOTEPROC EXPERIMENTAL status preside.
diff --git a/drivers/remoteproc/davinci_remoteproc.c
b/drivers/remoteproc/davinci_remoteproc.c
new file mode 100644
index 000..fc6fd72
--- /dev/null
+++ b/drivers/remoteproc/davinci_remoteproc.c
@@ -0,0 +1,307 @@
+/*
+ * Remote processor machine-specific module for Davinci
+ *
+ * Copyright (C) 2011-2012 Texas Instruments, Inc.
2013?
Yep.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt)%s: fmt, __func__
You dont seem to be using this anywhere.
Will remove.
+
+#include linux/kernel.h
+#include linux/err.h
+#include linux/printk.h
+#include linux/bitops.h
+#include linux/platform_device.h
+#include linux/remoteproc.h
+#include linux/platform_data/da8xx-remoteproc.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/irq.h
It will be nice to keep this sorted. It avoids duplicate includes
later.
OK
+static char *fw_name;
+module_param(fw_name, charp, S_IRUGO);
+MODULE_PARM_DESC(fw_name, \n\t\tName of DSP firmware file in
/lib/firmware);
+
+/*
+ * OMAP-L138 Technical References:
+ * http://www.ti.com/product/omap-l138
+ */
+#define SYSCFG_CHIPSIG_OFFSET 0x174
+#define SYSCFG_CHIPSIG_CLR_OFFSET 0x178
+#define SYSCFG_CHIPINT0 (1 0)
+#define SYSCFG_CHIPINT1 (1 1)
+#define SYSCFG_CHIPINT2 (1 2)
+#define SYSCFG_CHIPINT3 (1 3)
You can use BIT(x) here.
Will do.
+
+/**
+ * struct davinci_rproc - davinci remote processor state
+ * @rproc: rproc handle
+ */
+struct davinci_rproc {
+ struct rproc *rproc;
+ struct clk *dsp_clk;
+};
+
+static void __iomem *syscfg0_base;
+static struct platform_device *remoteprocdev;
+static struct irq_data *irq_data;
+static void (*ack_fxn)(struct irq_data *data);
+static int irq;
+
+/**
+ * handle_event() - inbound virtqueue message workqueue function
+ *
+ * This funciton is registered as a kernel thread and is scheduled
by the
+ * kernel handler.
+ */
+static irqreturn_t handle_event(int irq, void *p)
+{
+ struct rproc *rproc = platform_get_drvdata(remoteprocdev);
+
+ /* Process incoming buffers on our vring */
+ while (IRQ_HANDLED ==
RE: [PATCH v5 7/9] ARM: davinci: Remoteproc platform device creation data/code
-Original Message-
From: Nori, Sekhar
Sent: Monday, January 21, 2013 12:34 AM
To: Tivy, Robert
Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm-
ker...@lists.infradead.org; Ring, Chris; Grosen, Mark; o...@wizery.com;
r...@landley.net; linux-...@vger.kernel.org
Subject: Re: [PATCH v5 7/9] ARM: davinci: Remoteproc platform device
creation data/code
On 1/11/2013 5:53 AM, Robert Tivy wrote:
Added a new remoteproc platform device for DA8XX. Contains CMA-based
reservation of physical memory block. A new kernel command-line
parameter has been added to allow boot-time specification of the
physical memory block.
Signed-off-by: Robert Tivy rt...@ti.com
---
Documentation/kernel-parameters.txt|7 +++
arch/arm/mach-davinci/devices-da8xx.c | 93
+++-
arch/arm/mach-davinci/include/mach/da8xx.h |4 ++
3 files changed, 103 insertions(+), 1 deletion(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 363e348..e95afb1 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -44,6 +44,7 @@ parameter is applicable:
AVR32 AVR32 architecture is enabled.
AX25Appropriate AX.25 support is enabled.
BLACKFIN Blackfin architecture is enabled.
+ CMA Contiguous Memory Area support is enabled.
DRM Direct Rendering Management support is enabled.
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
@@ -2634,6 +2635,12 @@ bytes respectively. Such letter suffixes can
also be entirely omitted.
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
+ rproc_mem=nn[KMG][@address]
+ [KNL,ARM,CMA] Remoteproc physical memory block.
+ Memory area to be used by remote processor image,
+ managed by CMA. Suitable defaults exist if not
+ specified.
There are no defaults now, right?
That's right, booter must specify rproc_mem in u-boot bootargs.
+
rw [KNL] Mount root device read-write on boot
S [KNL] Run init in single mode
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-
davinci/devices-da8xx.c
index fb2f51b..e8016ca 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -12,10 +12,11 @@
*/
#include linux/init.h
#include linux/platform_device.h
-#include linux/dma-mapping.h
+#include linux/dma-contiguous.h
#include linux/serial_8250.h
#include linux/ahci_platform.h
#include linux/clk.h
+#include linux/platform_data/da8xx-remoteproc.h
#include mach/cputype.h
#include mach/common.h
@@ -706,6 +707,96 @@ int __init da850_register_mmcsd1(struct
davinci_mmc_config *config)
}
#endif
+static struct resource da8xx_rproc_resources[] = {
+ { /* DSP boot address */
+ .start = DA8XX_SYSCFG0_BASE +
DA8XX_HOST1CFG_REG,
+ .end= DA8XX_SYSCFG0_BASE + DA8XX_HOST1CFG_REG + 3,
+ .flags = IORESOURCE_MEM,
+ },
+ { /* dsp irq */
+ .start = IRQ_DA8XX_CHIPINT0,
+ .end= IRQ_DA8XX_CHIPINT0,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct da8xx_rproc_pdata rproc_pdata = {
+ .name = dsp,
+};
Since the driver is only for da850 so the name of the remote processor
is fixed and can probably be hardcoded in the driver itself.
In which case I wouldn't even need the da8xx_rproc_pdata at all, which would be
nice.
+
+static struct platform_device da8xx_dsp = {
+ .name = davinci-rproc,
+ .id = 0,
+ .dev= {
+ .platform_data = rproc_pdata,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .num_resources = ARRAY_SIZE(da8xx_rproc_resources),
+ .resource = da8xx_rproc_resources,
+};
+
+#if IS_ENABLED(CONFIG_DAVINCI_REMOTEPROC)
+
+static phys_addr_t rproc_base __initdata;
+static unsigned long rproc_size __initdata;
+
+static int __init early_rproc_mem(char *p)
+{
+ char *endp;
+
+ if (p == NULL)
+ return 0;
+
+ rproc_size = memparse(p, endp);
+ if (*endp == '@')
+ rproc_base = memparse(endp + 1, NULL);
+
+ return 0;
+}
+early_param(rproc_mem, early_rproc_mem);
+
+void __init da8xx_rproc_reserve_cma(void)
+{
+ int ret;
+
+ if (!rproc_base || !rproc_size) {
+ pr_err(%s: 'rproc_mem=nn@address' badly specified\n
+ 'nn' and 'address' must both be non-zero\n,
+ __func__);
+
+ return;
+ }
+
+ pr_info(%s: reserving 0x%lx @ 0x%lx...\n
RE: [PATCH v5 5/9] ARM: davinci: New reset functionality/API provided for Davinci DSP
Thankyou for all your help Sekhar. I'm fine with your fixups (both commentary and code naming). Regards, - Rob -Original Message- From: Nori, Sekhar Sent: Thursday, January 17, 2013 3:33 AM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Ring, Chris; Grosen, Mark; o...@wizery.com; r...@landley.net; linux-...@vger.kernel.org Subject: Re: [PATCH v5 5/9] ARM: davinci: New reset functionality/API provided for Davinci DSP On 1/11/2013 5:53 AM, Robert Tivy wrote: Since there is no general reset support for SoC devices, and since the remoteproc driver needs explicit control of the DSP's reset line, a new Davinci-specific API is added. This private API will disappear with DT migration. Some discussion regarding a proposed DT reset binding is here: https://patchwork.kernel.org/patch/1635051/ Modified davinci_clk_init() to set clk reset function for clocks that indicate PSC_LRST support. Also fixed indentation issue with function opening curly brace. Signed-off-by: Robert Tivy rt...@ti.com I applied this patch for v3.9. The subject seemed too long with repeated references to davinci so I shortened it to: ARM: davinci: psc: introduce reset API --- a/arch/arm/mach-davinci/include/mach/psc.h +++ b/arch/arm/mach-davinci/include/mach/psc.h @@ -246,6 +246,7 @@ #define MDSTAT_STATE_MASK 0x3f #define PDSTAT_STATE_MASK 0x1f +#define MDCTL_LRST BIT(8) #define MDCTL_FORCEBIT(31) #define PDCTL_NEXT BIT(0) #define PDCTL_EPCGOOD BIT(8) @@ -253,6 +254,8 @@ #ifndef __ASSEMBLER__ extern int davinci_psc_is_clk_active(unsigned int ctlr, unsigned int id); +extern void davinci_psc_reset_config(unsigned int ctlr, unsigned int id, + bool reset); I felt the word 'config' in the name is not really required since the functionality is fixed (as opposed to the davinci_psc_config() function which could do multiple configurations) I updated the function name to davinci_psc_reset() when I committed the patch locally. Hope that's okay with you. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
-Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Tuesday, January 15, 2013 4:49 AM To: Nori, Sekhar Cc: Tivy, Robert; davinci-linux-open-source; linux-arm; Ring, Chris; Grosen, Mark; r...@landley.net; linux-...@vger.kernel.org; Chemparathy, Cyril Subject: Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP On Tue, Jan 15, 2013 at 2:29 PM, Sekhar Nori nsek...@ti.com wrote: May be rproc_alloc() could auto-assign the firmware name to something like 'rproc%d-fw' if firmware name passed to it is NULL? I prefer we use name-based filenames instead to make it easier for users (and us developers). We can probably do something like rproc-%s-fw with pdata-name assuming we/you do maintain a meaningful name in the latter. This sounds good, although it will introduce the need to handle dynamic storage for the generated name. I think I can jam that storage on the end of the already-dynamically-sized 'struct rproc + sizeof(pdata)' allocation in rproc_alloc(). Thanks Regards, - Rob Thanks, Ohad. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP
Hi Ohad,
Glad to see you jump in the fray, please see responses below...
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Friday, January 11, 2013 4:26 AM
To: Tivy, Robert
Cc: davinci-linux-open-source; linux-arm; Nori, Sekhar; Ring, Chris;
Grosen, Mark; r...@landley.net; linux-...@vger.kernel.org; Chemparathy,
Cyril
Subject: Re: [PATCH v5 6/9] ARM: davinci: Remoteproc driver support for
OMAP-L138 DSP
Hi Robert,
I'm happy to see this driver going upstream, thanks for pushing!
Please see below my few comments. PS - sorry for the belated review.
On Fri, Jan 11, 2013 at 2:23 AM, Robert Tivy rt...@ti.com wrote:
+config DAVINCI_REMOTEPROC
+ tristate DaVinci DA850/OMAPL138 remoteproc support
(EXPERIMENTAL)
+ depends on ARCH_DAVINCI_DA850
+ select REMOTEPROC
+ select RPMSG
+ select FW_LOADER
This one gets selected by CONFIG_REMOTEPROC, so you don't need to do so
too.
From drivers/remoteproc/Kconfig:
# REMOTEPROC gets selected by whoever wants it
config REMOTEPROC
tristate
depends on EXPERIMENTAL
depends on HAS_DMA
select FW_CONFIG
select VIRTIO
Is FW_CONFIG above supposed to be FW_LOADER?
I don't see any support for FW_CONFIG anywhere in the kernel.
diff --git a/drivers/remoteproc/davinci_remoteproc.c
b/drivers/remoteproc/davinci_remoteproc.c
new file mode 100644
index 000..fc6fd72
--- /dev/null
+++ b/drivers/remoteproc/davinci_remoteproc.c
+static char *fw_name;
+module_param(fw_name, charp, S_IRUGO);
+MODULE_PARM_DESC(fw_name, \n\t\tName of DSP firmware file in
/lib/firmware);
+
+/*
+ * OMAP-L138 Technical References:
+ * http://www.ti.com/product/omap-l138
+ */
+#define SYSCFG_CHIPSIG_OFFSET 0x174
+#define SYSCFG_CHIPSIG_CLR_OFFSET 0x178
+#define SYSCFG_CHIPINT0 (1 0)
+#define SYSCFG_CHIPINT1 (1 1)
+#define SYSCFG_CHIPINT2 (1 2)
+#define SYSCFG_CHIPINT3 (1 3)
+
+/**
+ * struct davinci_rproc - davinci remote processor state
+ * @rproc: rproc handle
Add @dsp_clk ?
Yep.
+ */
+struct davinci_rproc {
+ struct rproc *rproc;
+ struct clk *dsp_clk;
+};
+
+static void __iomem *syscfg0_base;
+static struct platform_device *remoteprocdev;
+static struct irq_data *irq_data;
+static void (*ack_fxn)(struct irq_data *data);
+static int irq;
Is it safe to maintain these as globals (i.e. what if we have more
than a single pdev instance) ?
I think it makes sense for some of them to be globals, will review/change
accordingly.
+
+/**
+ * handle_event() - inbound virtqueue message workqueue function
+ *
+ * This funciton is registered as a kernel thread and is scheduled
by the
typo
Will fix.
+ * kernel handler.
+ */
+static irqreturn_t handle_event(int irq, void *p)
+{
+ struct rproc *rproc = platform_get_drvdata(remoteprocdev);
It's probably better to pass this as an irq cookie instead of relying
on global data
Agreed, will change.
+
+ /* Process incoming buffers on our vring */
+ while (IRQ_HANDLED == rproc_vq_interrupt(rproc, 0))
+ ;
This is interesting. IIUC, you want a single irq event to trigger
processing of all the available messages. It makes sense, but I'm not
sure we need this to be platform-specific.
YUC :)
+
+ /* Must allow wakeup of potenitally blocking senders: */
+ rproc_vq_interrupt(rproc, 1);
IIUC, you do this is because you have a single irq for all the vrings
(PCMIIW).
YUC again.
We may want to add something in these lines to the generic remoteproc
framework, as additional platforms require it (e.g. keystone). I
remember a similar patch by Cyril was circulating internally but never
hit the mailing lists - you may want to take it even though it would
probably need to be refreshed.
Ok, I got Cyril's patch (sent privately by you) and will incorporate it in the
generic processing, and modify davinci_remoteproc.c to:
while (IRQ_HANDLED == rproc_vq_interrupt(rproc, -1))
;
+static int davinci_rproc_start(struct rproc *rproc)
+{
+ struct platform_device *pdev = to_platform_device(rproc-
dev.parent);
+ struct device *dev = rproc-dev.parent;
+ struct davinci_rproc *drproc = rproc-priv;
+ struct clk *dsp_clk;
+ struct resource *r;
+ unsigned long host1cfg_physaddr;
+ unsigned int host1cfg_offset;
+ int ret;
+
+ remoteprocdev = pdev;
+
+ /* hw requires the start (boot) address be on 1KB boundary */
+ if (rproc-bootaddr 0x3ff) {
+ dev_err(dev, invalid boot address: must be aligned
to 1KB\n);
+
+ return -EINVAL;
+ }
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (IS_ERR_OR_NULL(r)) {
+ dev_err
RE: [PATCH v4 0/9] ARM: davinci: remoteproc support
Sekhar, At this point we have some examples/tests that exercise the davinci remoteproc framework using a socket layer that exists only in personal repos. Ohad created rpmsg-based socket support for the kernel using vrings, and along with SYS/BIOS-based content developed by my TI team and others, it allows a SysLink-like MessageQ implementation to be used between the DSP and Linux user apps. These apps consist of a Linux app communicating with the DSP firmware file loaded by remoteproc. They rely on the rpmsg-based socket support, so they're of no use without that. What I can do, for now, is provide a simple DSP firmware file that prints a Hello, world to a SYS/BIOS trace buffer that is known to remoteproc, and the remoteproc driver can be used to display the trace buffer contents through debugfs. However, this won't exercise the run-time component of davinci remoteproc (which is really just interrupt support between the DSP and ARM). I will do this and upload the firmware file and a README to my GitHub repo. I will provide just the firmware binary since the capability to build it from source relies on SYS/BIOS, TI IPC, and XDC packages/installations. Regards, - Rob -Original Message- From: Nori, Sekhar Sent: Friday, January 04, 2013 4:11 AM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; o...@wizery.com; r...@landley.net; linux- d...@vger.kernel.org; Ring, Chris; Grosen, Mark Subject: Re: [PATCH v4 0/9] ARM: davinci: remoteproc support On 12/22/2012 3:39 AM, Tivy, Robert wrote: I have uploaded the commits corresponding to this patch set to a public repo on GitHub, forked from Linus' v3.7-rc2 tag on his linux repo. These commits are on a branch named davinci-remoteproc, here is the URL: https://github.com/RTivy/linux/tree/davinci-remoteproc This should make for an easier review of the changes. Thanks. Is there a sample application we could use to exercise the driver? Looks like we need some firmware to load on the DSP too. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v4 0/9] ARM: davinci: remoteproc support
I have uploaded the commits corresponding to this patch set to a public repo on GitHub, forked from Linus' v3.7-rc2 tag on his linux repo. These commits are on a branch named davinci-remoteproc, here is the URL: https://github.com/RTivy/linux/tree/davinci-remoteproc This should make for an easier review of the changes. Regards, - Rob -Original Message- From: Tivy, Robert Sent: Wednesday, December 19, 2012 5:34 PM To: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Nori, Sekhar; o...@wizery.com; r...@landley.net; linux-...@vger.kernel.org; Ring, Chris; Grosen, Mark Cc: Tivy, Robert Subject: [PATCH v4 0/9] ARM: davinci: remoteproc support This patch series adds remoteproc support for OMAP-L138, along with needed supporting mach-davinci infrastructure. Some notes for reviewers... DOCUMENTATION maintainers: patch 6/9 in this series contains a change to kernel-parameters.txt that adds a description for a new kernel command- line parameter, along with the code that defines the new kernel command-line parameter. You are, of course, free to look at the whole series, but only patch 6/9 is of particular interest. Robert Tivy (9): ARM: davinci: da850 board: change pr_warning() to pr_warn() ARM: davinci: devices-da8xx.c: change pr_warning() to pr_warn() ARM: davinci: psc.c: change pr_warning() to pr_warn() ARM: davinci: da850: added pll0_sysclk1 for DSP usage New reset assert/deassert functionality/API provided for Davinci DSP Remoteproc platform device creation data/code for DA8xx devices Added .reserve function and rproc platform registration Added dsp clock definition, keyed to davinci-rproc.0 Remoteproc driver support for OMAP-L138 DSP Documentation/kernel-parameters.txt|7 + arch/arm/mach-davinci/board-da850-evm.c| 110 - arch/arm/mach-davinci/board-omapl138-hawk.c| 38 +-- arch/arm/mach-davinci/clock.c | 31 +++ arch/arm/mach-davinci/clock.h |3 + arch/arm/mach-davinci/da850.c | 18 ++ arch/arm/mach-davinci/devices-da8xx.c | 93 +++- arch/arm/mach-davinci/include/mach/clock.h |3 + arch/arm/mach-davinci/include/mach/da8xx.h |6 + arch/arm/mach-davinci/include/mach/psc.h |3 + arch/arm/mach-davinci/psc.c| 32 ++- drivers/remoteproc/Kconfig | 20 ++ drivers/remoteproc/Makefile|1 + drivers/remoteproc/davinci_remoteproc.c| 303 include/linux/platform_data/da8xx-remoteproc.h | 33 +++ 15 files changed, 617 insertions(+), 84 deletions(-) create mode 100644 drivers/remoteproc/davinci_remoteproc.c create mode 100644 include/linux/platform_data/da8xx-remoteproc.h -- 1.7.9.4 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
-Original Message-
From: Nori, Sekhar
Sent: Wednesday, December 12, 2012 2:34 AM
On 12/12/2012 7:06 AM, Tivy, Robert wrote:
-Original Message-
From: Nori, Sekhar
Sent: Friday, November 30, 2012 2:51 AM
Hi Rob,
On 11/29/2012 7:08 AM, Tivy, Robert wrote:
Hi Sekhar,
Please see comments and noob questions below...
They can run a single image if the image supports overriding the
Kconfig settings with kernel command-line arguments.
The most basic solution is constants in the .c file itself. A
better
solution is Kconfig settings used by the .c file. An even better
solution is Kconfig settings with kernel command-line overrides.
If you have kernel command line, you could default to some values
which
are sane in most cases if they are not provided. No, need to have a
Kconfig as well. That will be too many hooks to control the same
things
and probably not necessary.
If you want the remoteproc driver to allocate a certain area of
memory
to the dsp, why don't you take that value as a module parameter so
people who need different values can pass them differently? It is
not
clear to me why this memory management needs to be dealt with in
platform code.
Unfortunetly we need to reserve this dsp memory during early boot,
using CMA. Runtime module insertion is too late.
Then I guess most of the time the module would be built into the
kernel
and will be initialized using an early enough initcall.
That's right, a .reserve function is assigned to the MACHINE_START
structure, and this function calls dma_declare_contiguous().
I meant use an early initcall in the driver.
+
+static int __init early_rproc_mem(char *p) {
+ char *endp;
+
+ rproc_size = memparse(p, endp);
+ if (*endp == '@')
+ rproc_base = memparse(endp + 1, NULL);
+
+ return 0;
+}
+early_param(rproc_mem, early_rproc_mem);
Use of non-standard kernel parameters is discouraged. All kernel
parameters should be documented in Documentation/kernel-
parameters.txt
(this means each and every kernel parameter needs to be justified
well).
Can I use the kernel command-line (i.e., u-boot bootargs variable)
to
specify non-kernel parameters? I guess my question is more one
about
the terminology kernel parameter - is there a way to specify a
module
parameter on the kernel command line (like, perhaps, rproc.membase
and
rproc.memsize)?
Right. Module parameters are passed from kernel command line when
the
module is built into the kernel.
Unfortunately, it seems that module parameters, when stated on the
kernel command line with module-name.var-name syntax, are not yet
assigned when the kernel calls the early init .reserve functions. For
the char * I'm using, I observed a NULL value during the early init
call and the proper assigned value during a later normal __init
function.
By later normal __init you mean module_init()? And you see
dma_declare_contiguous() returning error by this time?
That's right, dma_declare_contiguous() must be called very early in the boot,
else it fails. The module_init() function is too late, and I even tried with a
function qualified with early_initcall() instead of module_init(). Here's some
text from the header comment for dma_declare_contiguous():
* This function reserves memory for specified device. It should be
* called by board specific code when early allocator (memblock or bootmem)
* is still activate.
Is there any other method that allows specifying a parameter for an
early CMA reservation without having to rebuild the kernel?
Nothing else comes to mind. Can you share your code in some public
repo?
It will allow me to try if something comes to mind.
I will attempt to put my code on github.
Thanks Regards,
- Rob
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
-Original Message-
From: Nori, Sekhar
Sent: Friday, November 30, 2012 2:51 AM
Hi Rob,
On 11/29/2012 7:08 AM, Tivy, Robert wrote:
Hi Sekhar,
Please see comments and noob questions below...
They can run a single image if the image supports overriding the
Kconfig settings with kernel command-line arguments.
The most basic solution is constants in the .c file itself. A better
solution is Kconfig settings used by the .c file. An even better
solution is Kconfig settings with kernel command-line overrides.
If you have kernel command line, you could default to some values which
are sane in most cases if they are not provided. No, need to have a
Kconfig as well. That will be too many hooks to control the same things
and probably not necessary.
If you want the remoteproc driver to allocate a certain area of
memory
to the dsp, why don't you take that value as a module parameter so
people who need different values can pass them differently? It is
not
clear to me why this memory management needs to be dealt with in
platform code.
Unfortunetly we need to reserve this dsp memory during early boot,
using CMA. Runtime module insertion is too late.
Then I guess most of the time the module would be built into the kernel
and will be initialized using an early enough initcall.
That's right, a .reserve function is assigned to the MACHINE_START structure,
and this function calls dma_declare_contiguous().
+
+static int __init early_rproc_mem(char *p) {
+ char *endp;
+
+ rproc_size = memparse(p, endp);
+ if (*endp == '@')
+ rproc_base = memparse(endp + 1, NULL);
+
+ return 0;
+}
+early_param(rproc_mem, early_rproc_mem);
Use of non-standard kernel parameters is discouraged. All kernel
parameters should be documented in Documentation/kernel-
parameters.txt
(this means each and every kernel parameter needs to be justified
well).
Can I use the kernel command-line (i.e., u-boot bootargs variable) to
specify non-kernel parameters? I guess my question is more one about
the terminology kernel parameter - is there a way to specify a module
parameter on the kernel command line (like, perhaps, rproc.membase and
rproc.memsize)?
Right. Module parameters are passed from kernel command line when the
module is built into the kernel.
Unfortunately, it seems that module parameters, when stated on the kernel
command line with module-name.var-name syntax, are not yet assigned when the
kernel calls the early init .reserve functions. For the char * I'm using, I
observed a NULL value during the early init call and the proper assigned value
during a later normal __init function.
Is there any other method that allows specifying a parameter for an early CMA
reservation without having to rebuild the kernel?
If not, is this a strong enough use case to justify a new kernel parameter?
I guess I don't understand why non-standard kernel parameters are discouraged.
I can adorn the name with enough module-specific naming to reduce the chances
of any namespace collisions to a minimum.
Regards,
- Rob
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
-Original Message- From: Nori, Sekhar Sent: Friday, December 07, 2012 12:24 AM On 12/4/2012 9:43 PM, Murali Karicheri wrote: On 12/04/2012 09:53 AM, Murali Karicheri wrote: I believe this is addressing the same issue. This is a DT based solution, which I believe should add a framework and enhance it to support DT. Forgot to paste the link. Here we go https://patchwork.kernel.org/patch/1635051/ Rob, Since there is a solution for reset handling proposed but seems to be slightly far from taking a concrete shape, I suggest you go ahead and implement davinci reset using a platform private API ala Tegra. You can create and send the patches. I will review and accept them but not send them upstream immediately. Lets wait till v3.8-rc4. If there is a generic solution that is merged by that time, I will ask you to use that instead of your API (this will give you about 2 weeks to convert). If the generic solution is not merged by that time, I will send your private API to the upstreams for v3.9 and we can convert to generic solution for later kernel versions. This should give you a fair chance to get remoteproc working on DA850 for v3.9. Sounds like a plan? The remoteproc folks need to agree too. I am copying Ohad here. I'm on board with that plan, thanks very much for the suggestion, I agree completely. Meanwhile I do suggest you work with Stephen and Mike in giving shape to the reset API so it suits your needs when it gets ready. Will do. Thanks Regards, - Rob Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Karicheri, Muralidharan Sent: Tuesday, December 04, 2012 8:13 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP On 12/04/2012 09:53 AM, Murali Karicheri wrote: I believe this is addressing the same issue. This is a DT based solution, which I believe should add a framework and enhance it to support DT. Forgot to paste the link. Here we go https://patchwork.kernel.org/patch/1635051/ Thanks Murali, very interesting. The thread in your link above mentions omap_hwmod at the end, and I've been looking at how that's handled but it's quite complex. Would a similar solution (davinci_hwmod) be a good approach? Regards, - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
-Original Message- From: Chemparathy, Cyril Sent: Monday, December 03, 2012 12:13 PM To: Nori, Sekhar Cc: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP On 12/03/2012 09:41 AM, Sekhar Nori wrote: Hi Rob, On 12/1/2012 7:41 AM, Tivy, Robert wrote: Hi Sekhar, -Original Message- From: Nori, Sekhar Sent: Friday, November 30, 2012 2:51 AM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Ring, Chris; Grosen, Mark Subject: Re: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP Hi Rob, On 11/29/2012 7:08 AM, Tivy, Robert wrote: Hi Sekhar, Please see comments and noob questions below... -Original Message- From: Nori, Sekhar Sent: Tuesday, November 20, 2012 4:27 AM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Ring, Chris; Grosen, Mark Subject: Re: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP On 11/14/2012 6:03 AM, Robert Tivy wrote: Requires CMA services. New 'clk_reset()' API added so that the DSP's reset state can be toggled separately from its enable/disable operation. But we cannot add a private clk_ API without it being defined in include/linux/clk.h. So, this requires wider alignment. And I am not sure clock API should be extended to support reset since resetting a clock does not make a lot of sense. On DaVinci, clock gating and reset are handled by the same module, but that need not always be the case. What you need is a way to reset an IP. I do not know of an existing framework to do this; likely a new API needs to be created. I am guessing this never existed so far because most of the IPs can be reset internally (by writing a bit within its own register space). I guess DSP is different since its actually a co-processor and may not have such a bit. How about simulating a reset by making the DSP jump to its reset address. While I am sure its not quite the same as resetting the DSP using PSC, may be it could be used while you wait for consensus around handling module reset in kernel? Since the ARM can't write the DSP's program counter I suspect such a temporary solution is not possible. Okay. I think the way forward on this is to start a separate thread including the ARM list, LKML and the remoteproc folks to see if it makes sense to create a reset API in kernel. You can describe the usecase you have. Instead of fighting that fight, I thought of another way. The da8xx_dsp platform_device has private data registered in its device struct. This private data can contain a function pointer for a DSP reset function, and davinci_remoteproc.c can call the registered function. Does that sound OK? Passing function pointers from platform code will not work when converting to device tree (DT). DA850 will gain DT boot with v3.8 and there is work ongoing on converting drivers to be DT-aware. Adding a new driver which is DT-incompatible will not be right. Hence, I will not recommend this now. Not sure if this solves your problem, but you could add a new clock type (PSC_LRESET?) as a child under the PSC clock node for the DSP. Something like: | +-- PSC x (DSP0 clock) || |+-- PSC-LRESET x (DSP0 reset control) | +-- PSC y (DSP1 clock) || |+-- PSC-LRESET y (DSP1 reset control) | +-- PSC z (DSP2 clock) || |+-- PSC-LRESET z (DSP2 reset control) The idea here being that if you enable the PSC clocks, you enable the clock gates, but leave the DSPs in reset. On the other hand, if you enable the reset clock, the code implicitly enables the gate (via parent), and takes the DSP out of reset as well. This is not quite the cleanest way to do it, considering that reset lines have no business in the clock tree, but then, this is probably the simplest way to fit in. Thoughts? BTW, we have the same situation on Keystone. Thanks -- Cyril. Cyril, Thankyou for the good suggestion. In trying it out to see if it would work I ran into an issue where the clk_register() function failed when called for the new child clock, complaining that its parent has no rate. This is true, since the parent was previously just a leaf and handled by the PSC (and the parent's parent is a CLK_PLL clock). So, I would need to add code to arch/arm/mach-davinci/clock.c that prevents rate operations from being performed on a clock of this PSC_LRESET type (as well as code that allows for no rate or parent-rate to be associated with it, instead of failing). I can modify clock.c to allow for this new clock type in this way, unless you have a better suggestion (I'm not too
RE: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
Hi Sekhar, -Original Message- From: Nori, Sekhar Sent: Friday, November 30, 2012 2:51 AM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Ring, Chris; Grosen, Mark Subject: Re: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP Hi Rob, On 11/29/2012 7:08 AM, Tivy, Robert wrote: Hi Sekhar, Please see comments and noob questions below... -Original Message- From: Nori, Sekhar Sent: Tuesday, November 20, 2012 4:27 AM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Ring, Chris; Grosen, Mark Subject: Re: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP On 11/14/2012 6:03 AM, Robert Tivy wrote: Requires CMA services. New 'clk_reset()' API added so that the DSP's reset state can be toggled separately from its enable/disable operation. But we cannot add a private clk_ API without it being defined in include/linux/clk.h. So, this requires wider alignment. And I am not sure clock API should be extended to support reset since resetting a clock does not make a lot of sense. On DaVinci, clock gating and reset are handled by the same module, but that need not always be the case. What you need is a way to reset an IP. I do not know of an existing framework to do this; likely a new API needs to be created. I am guessing this never existed so far because most of the IPs can be reset internally (by writing a bit within its own register space). I guess DSP is different since its actually a co-processor and may not have such a bit. How about simulating a reset by making the DSP jump to its reset address. While I am sure its not quite the same as resetting the DSP using PSC, may be it could be used while you wait for consensus around handling module reset in kernel? Since the ARM can't write the DSP's program counter I suspect such a temporary solution is not possible. Okay. I think the way forward on this is to start a separate thread including the ARM list, LKML and the remoteproc folks to see if it makes sense to create a reset API in kernel. You can describe the usecase you have. Instead of fighting that fight, I thought of another way. The da8xx_dsp platform_device has private data registered in its device struct. This private data can contain a function pointer for a DSP reset function, and davinci_remoteproc.c can call the registered function. Does that sound OK? Regards, - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
Hi Sekhar, Please see comments and noob questions below... -Original Message- From: Nori, Sekhar Sent: Tuesday, November 20, 2012 4:27 AM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Ring, Chris; Grosen, Mark Subject: Re: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP On 11/14/2012 6:03 AM, Robert Tivy wrote: Requires CMA services. New 'clk_reset()' API added so that the DSP's reset state can be toggled separately from its enable/disable operation. But we cannot add a private clk_ API without it being defined in include/linux/clk.h. So, this requires wider alignment. And I am not sure clock API should be extended to support reset since resetting a clock does not make a lot of sense. On DaVinci, clock gating and reset are handled by the same module, but that need not always be the case. What you need is a way to reset an IP. I do not know of an existing framework to do this; likely a new API needs to be created. I am guessing this never existed so far because most of the IPs can be reset internally (by writing a bit within its own register space). I guess DSP is different since its actually a co-processor and may not have such a bit. How about simulating a reset by making the DSP jump to its reset address. While I am sure its not quite the same as resetting the DSP using PSC, may be it could be used while you wait for consensus around handling module reset in kernel? Since the ARM can't write the DSP's program counter I suspect such a temporary solution is not possible. Signed-off-by: Robert Tivy rt...@ti.com --- arch/arm/mach-davinci/board-da850-evm.c| 10 +++ arch/arm/mach-davinci/board-omapl138-hawk.c| 10 +++ arch/arm/mach-davinci/clock.c | 22 +++ arch/arm/mach-davinci/clock.h |1 + arch/arm/mach-davinci/da850.c | 17 ++ arch/arm/mach-davinci/devices-da8xx.c | 78 +++- arch/arm/mach-davinci/include/mach/da8xx.h |1 + arch/arm/mach-davinci/include/mach/psc.h |3 + arch/arm/mach-davinci/psc.c| 27 arch/arm/mach-davinci/remoteproc.h | 23 +++ include/linux/clk.h| 17 ++ include/linux/platform_data/da8xx-remoteproc.h | 34 +++ This patch is touching too many areas at once and needs to be split according to whether the changes are in the soc support or board support. OK. Also, platform data needs be added along with the driver. And the driver itself needs to be added before its platform users. Are these comments suggesting some change to the code, or are they more of a guide as to how to split this part of the patch up into related chunks? Please clarify. 12 files changed, 242 insertions(+), 1 deletion(-) create mode 100644 arch/arm/mach-davinci/remoteproc.h create mode 100644 include/linux/platform_data/da8xx-remoteproc.h diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c index 6c172b3..4e86008 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c @@ -48,6 +48,8 @@ #include media/tvp514x.h #include media/adv7343.h +#include remoteproc.h + #define DA850_EVM_PHY_ID davinci_mdio-0:00 #define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8) #define DA850_LCD_BL_PIN GPIO_TO_PIN(2, 15) @@ -1550,6 +1552,11 @@ static __init void da850_evm_init(void) pr_warn(%s: sata registration failed: %d\n, __func__, ret); da850_evm_setup_mac_addr(); + + ret = da8xx_register_rproc(); + if (ret) + pr_warn(%s: dsp/rproc registration failed: %d\n, + __func__, ret); } #ifdef CONFIG_SERIAL_8250_CONSOLE @@ -1577,4 +1584,7 @@ MACHINE_START(DAVINCI_DA850_EVM, DaVinci DA850/OMAP-L138/AM18x EVM) .init_late = davinci_init_late, .dma_zone_size = SZ_128M, .restart= da8xx_restart, +#ifdef CONFIG_CMA + .reserve= da8xx_rproc_reserve_cma, +#endif MACHINE_END diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c index 8aea169..a0b81c1 100644 --- a/arch/arm/mach-davinci/board-omapl138-hawk.c +++ b/arch/arm/mach-davinci/board-omapl138-hawk.c @@ -21,6 +21,8 @@ #include mach/da8xx.h #include mach/mux.h +#include remoteproc.h + #define HAWKBOARD_PHY_ID davinci_mdio-0:07 #define DA850_HAWK_MMCSD_CD_PINGPIO_TO_PIN(3, 12) #define DA850_HAWK_MMCSD_WP_PINGPIO_TO_PIN(3, 13) @@ -311,6 +313,11 @@ static __init void omapl138_hawk_init(void) if (ret) pr_warn(%s: watchdog registration failed: %d\n, __func__, ret
RE: [PATCH v3 2/6] ARM: davinci: Changed pr_warning() to pr_warn() (part 2)
Hi Sergei,
Thanks for your feedback, please see below...
-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
Sent: Wednesday, November 14, 2012 2:17 AM
To: Tivy, Robert
Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm-
ker...@lists.infradead.org; Ring, Chris; Grosen, Mark; Nori, Sekhar
Subject: Re: [PATCH v3 2/6] ARM: davinci: Changed pr_warning() to
pr_warn() (part 2)
Hello.
On 14-11-2012 4:33, Robert Tivy wrote:
Also, while modifying those pr_warning() calls I changed hardcoded
function names to use '%s:, __func__' instead
Signed-off-by: Robert Tivy rt...@ti.com
---
Clean up files that will be otherwise modified in subsequent patch.
Applies to v3.7-rc2 tag (commit
6f0c0580b70c89094b3422ba81118c7b959c7556) of Linus' mainline kernel
at git.kernel.org.
arch/arm/mach-davinci/board-omapl138-hawk.c | 30 ++--
---
1 file changed, 11 insertions(+), 19 deletions(-)
Taksing of separation of board and SoC specific changes, this patch
shouldn't have been separated from patch 1 at all -- since it's two
boards built around the same chip, OMAP-L138...
The 4 patches that are of the same nature (Changed pr_warning() to pr_warn()
(part #)) were split as 4 separate patches on request by Sekhar, for the
purpose of making it easier to merge later.
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index dc1208e..8aea169 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -48,8 +48,7 @@ static __init void omapl138_hawk_config_emac(void)
val = ~BIT(8);
ret = davinci_cfg_reg_list(omapl138_hawk_mii_pins);
if (ret) {
- pr_warning(%s: cpgmac/mii mux setup failed: %d\n,
- __func__, ret);
+ pr_warn(%s: cpgmac/mii mux setup failed: %d\n, __func__,
ret);
I'd have preferred this as CPGMAC/MII. Almost all other acronyms
in the messages are capitalized.
I didn't originate those acronyms so I'm not inclined to change them.
Regards,
- Rob
return;
}
@@ -61,8 +60,7 @@ static __init void omapl138_hawk_config_emac(void)
ret = da8xx_register_emac();
if (ret)
- pr_warning(%s: emac registration failed: %d\n,
- __func__, ret);
+ pr_warn(%s: emac registration failed: %d\n, __func__,
ret);
... and EMAC here.
WBR, Sergei
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
Hi Prabhakar, Thanks for your consideration, please see my response below... -Original Message- From: Prabhakar Lad [mailto:prabhakar.cse...@gmail.com] Sent: Monday, November 05, 2012 9:02 PM To: Tivy, Robert; Ben Gardiner Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Marek Szyprowski Subject: Re: [PATCH v2 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP Hi Robert, On Thu, Nov 1, 2012 at 7:22 PM, Ben Gardiner bengardi...@nanometrics.ca wrote: Hi Rob, On Thu, Oct 25, 2012 at 4:35 PM, Robert Tivy rt...@ti.com wrote: [...] @@ -660,6 +667,99 @@ int __init da850_register_mmcsd1(struct davinci_mmc_config *config) } #endif +static struct platform_device *da8xx_dsp; + +#ifdef CONFIG_CMA + +/* + * The following address range was chosen because the XDC Platform for + * OMAP-L138 DSP has this range as its default code/data placement. + */ +#define DA8XX_RPROC_CMA_BASE (0xc300) [...] +/* + * The following address range was chosen because the XDC Platform for + * OMAP-L138 DSP has this range as its default code/data placement. + * + * System integrators must ensure that Linux does not own this range. + */ +#define DA_CONTIG_BASE (0xc300) +#define DA_CONTIG_SIZE (0x0200) Is there a specific requirement for the dsp dev to have the buffers from this '0xc300' address range only ? If yes then dma_declare_contiguous() is must to ensure contiguous memory so the above macros cant be avoided. If there isn't a requirement of a specific region for dsp device you can use a global CMA instead, so as to ensure you have contiguous memory. The requirement is that the contiguous buffer matches the address range to which the DSP image was linked, including uninitialized sections that don't actually get loaded. I was thinking of making those #defines into Kconfig variables, so that kernel sources don't need to be touched by the end customer. Another alternative is to make them be kernel command line variables, which would prevent the need to even rebuild the kernel. What are your thoughts regarding those alternatives? The above address range was decided upon because it matches the RTSC platform's defined area for OMAP-L138 [1] (although, the customer can end up redefining that range). One of the reasons that range was chosen for the RTSC platform is that it exists on boards with smaller DDR sizes. In other words, for a board with 256MB of DDR, if a range at the top of the DDR address space was chosen then that DSP image wouldn't work with a board with only 128MB. Regards, - Rob [1] http://rtsc.eclipse.org/cdoc-tip/index.html#ti/platforms/evmOMAPL138/Platform.html#per-instance_config_parameters, however, we extended the range an additional 16MB beyond the RTSC platform's range. Regards, --Prabhakar Lad I am concerned with the rigidity of the memory hole as its definition is currently proposed. As you noted DA_CONTIG_BASE and DA_CONTIG_SIZE must describe a range that is not used by Linux. Ideally this hole would not be in the middle of the usuable memory but instead at the top. For L138 boards with larger DDR packages this would mean carrying a patch to this file. I think the same also applies to DA8XX_RPROC_CMA_BASE but I have no hands-on experience yet with CMA. Is there any other means by which the hole's location and size can be specified which does not require patching this file? I imagine KConfig would work, but is this an acceptable use of KConfig? Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 1/6] ARM: davinci: Changed pr_warning() to pr_warn()
Thanks for your comments, Sergei. Please see below... -Original Message- From: Sergei Shtylyov [mailto:sshtyl...@mvista.com] Sent: Friday, October 26, 2012 2:46 AM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Ring, Chris; Grosen, Mark; Nori, Sekhar Subject: Re: [PATCH v2 1/6] ARM: davinci: Changed pr_warning() to pr_warn() Hello. It's not a good idea to send multiple patches with the same subject. Actually, in this case it's worth merging all 4 patches into one. My first patch submission had them all as one patch, but Sekhar asked that they be split into 4 separate patches to make the merge easier. I can make each one have a different subject, though. On 26-10-2012 0:35, Robert Tivy wrote: Also, while modifying those pr_warning() calls I changed hardcoded function names to use '%s:, __func__' instead Signed-off-by: Robert Tivy rt...@ti.com --- Clean up files that will be otherwise modified in subsequent patch. Applies to v3.5 tag (commit 28a33cbc24e4256c143dce96c7d93bf423229f92) of Linus' mainline kernel at git.kernel.org. 3.5 is too old. Why not to 3.6 or even 3.7-rc2? I will attempt to recreate this patch series on 3.7-rc2, although I will need to change it to use the newer rproc APIs and data structures. diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach- davinci/board-da850-evm.c index 0149fb4..bbb3c73 100644 --- a/arch/arm/mach-davinci/board-da850-evm.c +++ b/arch/arm/mach-davinci/board-da850-evm.c [...] @@ -1046,21 +1046,19 @@ static int __init da850_evm_config_emac(void) } if (ret) - pr_warning(da850_evm_init: cpgmac/rmii mux setup failed: %d\n, - ret); + pr_warn(%s: cpgmac/rmii mux setup failed: %d\n, + __func__, ret); /* configure the CFGCHIP3 register for RMII or MII */ __raw_writel(val, cfg_chip3_base); ret = davinci_cfg_reg(DA850_GPIO2_6); if (ret) - pr_warning(da850_evm_init:GPIO(2,6) mux setup - failed\n); + pr_warn(%s:GPIO(2,6) mux setup failed\n, __func__); Worth inserting space after colon here. Will do. WBR, Sergei Thanks Regards, - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Error While Running Demos
More details about the failure to open the codec engine are needed. You can generate more info by setting the environment variable CE_DEBUG=3 and re-running your app: % export CE_DEBUG=3 % ./decode ... Regards, - Rob From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On Behalf Of Aditya Barawkar Sent: Thursday, February 03, 2011 11:56 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Error While Running Demos I'm trying to run demos for encode decode which came with DVSDK v1.30.01 for DM6446 EVM When i boot the board then I'm not seeing any demos which should run automatically as per the TI doc. So i opted to run the demos using command line. First i loaded all the modules which are required to run the demos Modules loaded :: cmemk.ko and dsplinkk.ko root@10.42.43.10:/opt/demos/dm6446/decode/release# lsmod Module Size Used by cmemk 17368 0 dsplinkk 96360 0 But when i excute command to run the demo ::: ./decode -v /opt/demos/dm6446/data/videos/davincieffect_ntsc.m2v -k i get following error:: Decode demo started. TraceUtil Error: Failed to open codec engine decode TraceUtil Error: Aborting TraceUtil_start Decode Error: Failed to open codec engine decode Decode Error: Failed to open codec engine decode root@10.42.43.10:/opt/demos/dm6446/decode/release# Please help me out on how to make the sample demos run. Thanks in advance.! ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DM355 - 256MB RAM memory issue
From: Tharmarajan Ganeshan [mailto:tha...@e-consystems.com] Sent: Wednesday, July 14, 2010 8:17 AM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; maharajan; dhineshkumar Subject: RE: DM355 - 256MB RAM memory issue Hi Robert, I have built the cmemk.ko by running the command 'make debug'. But I could not find any extra messages while loading this cmemk driver. Here I have attached two log files when mem=50M and mem=168M to the kernel. CMEM is reserved with 88M. Regards, Tharmarajan G I don't know why you suspect CMEM here. Both your logs show CMEM being loaded properly - from your 50M log: cmemk: no version for struct_module found: kernel tainted. ioremap_nocache(0x8980, 109051904)=0xc388 allocated heap buffer 0xc388 of size 0x3204000 cmem initialized 14 pools between 0x8980 and 0x9000 The kernel panics don't show any CMEM-related function either. But you do seem to have other problems, here's just a sample of some from your 50M log: insmod: cannot insert `dm350mmap.ko': Bad address (-1): Bad address BusyBox v1.01 (2005.12.18-04:57+) multi-call binary Usage: mknod [OPTIONS] NAME TYPE MAJOR MINOR Create a special file (block, character, or pipe). Options: - m create the special file using the specified mode (default a=rw) TYPEs include: b: Make a block (buffered) device. c or u: Make a character (un-buffered) device. p: Make a named pipe. MAJOR and MINOR are ignored for named pipes. insmod: cannot insert `sbull.ko': Bad address (-1): Bad address insmod: cannot insert `musb_hdrc.ko': Bad address (-1): Bad address I don't know anything about those problems, I was just seeing if I could help with what I do know about - CMEM - but I don't see any problems related to CMEM in your logs. Regards, - Rob On Mon, 2010-07-12 at 16:32 -0500, Tivy, Robert wrote: From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Tharmarajan Ganeshan Sent: Saturday, July 10, 2010 8:35 AM To: todd.fisc...@ridgerun.com; Ring, Chris Cc: davinci-linux-open-source@linux.davincidsp.com; dhineshkumar; Mohamed Thalib H; maharajan Subject: Re: DM355 - 256MB RAM memory issue Hi Todd and Chris, Thank for your suggestion. We tried the option 'hole in the kernel memory space'. But that is not solving our issue. We tried to reserve memory 30MB at various place in RAM. But these trials does not help us to solve this issue. And also we tried to get the memory for this 5MP image capturing from the CMEM driver. For this we allocated 86MB to CMEM driver. But the kernel is hanging while loading this CMEM driver. Is there any limitation in CMEM driver ? As far as we know there is no limitation on the size of the physical block granted to CMEM. If you'd like to pursue this approach (getting your 5MP image memory from CMEM) then I could help, but would need to see the debug output of the CMEMK kernel module that you say is hanging while loading this CMEM driver. To produce debug output, build the debug version by: % cd linuxutils/ti/sdo/linuxutils/cmem/src/module % make debug Then 'insmod' this cmemk.ko and observe CMEMK debug output on the Linux console. Regards, - Rob Regards, Tharmarajan G On Tue, 2010-07-06 at 09:00 -0600, Todd Fischer wrote: Tharmarajan, I believe you need to rebuild your codec server with a different memory map. Another idea is to have a hole in the kernel memory space (specify mem= in the kernel command line twice). I am not sure if the kernel version you are using for dm355 supports a hole in the kernel memory space. Todd On Mon, 2010-07-05 at 19:44 +0530, Tharmarajan Ganeshan wrote: Hi All, We are working on a DM355 processor based Development board. The Board has 256MB mDDR RAM and 5MP image sensor MT9P031. We are using the kernel version 2.6.10 We have modified the driver code for capturing 5MP raw image and converting this 5MP raw into YUV. For this 5MP image capturing , we have reserved 30MB. We have allocated 56MB to the CMEM driver. The reserved memory 30MB and the 56MB memory for CMEM are at top of the RAM. We are passing the remaining memory size to the kernel in bootargs as mem=170M. And we are using the NFS rootfilesystem. But we are getting kernel hanging issues while testing the IPNC_APP applications and 5MP still image capturing. Sometimes the kernel is hanging while booting itself. If we reserve the 30MB from the address region 0x8320 - 0x84FF and pass the memory size to kernel in bootargs as mem=50M, then we are NOT having
RE: DM355 - 256MB RAM memory issue
From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Tharmarajan Ganeshan Sent: Saturday, July 10, 2010 8:35 AM To: todd.fisc...@ridgerun.com; Ring, Chris Cc: davinci-linux-open-source@linux.davincidsp.com; dhineshkumar; Mohamed Thalib H; maharajan Subject: Re: DM355 - 256MB RAM memory issue Hi Todd and Chris, Thank for your suggestion. We tried the option 'hole in the kernel memory space'. But that is not solving our issue. We tried to reserve memory 30MB at various place in RAM. But these trials does not help us to solve this issue. And also we tried to get the memory for this 5MP image capturing from the CMEM driver. For this we allocated 86MB to CMEM driver. But the kernel is hanging while loading this CMEM driver. Is there any limitation in CMEM driver ? As far as we know there is no limitation on the size of the physical block granted to CMEM. If you'd like to pursue this approach (getting your 5MP image memory from CMEM) then I could help, but would need to see the debug output of the CMEMK kernel module that you say is hanging while loading this CMEM driver. To produce debug output, build the debug version by: % cd linuxutils/ti/sdo/linuxutils/cmem/src/module % make debug Then 'insmod' this cmemk.ko and observe CMEMK debug output on the Linux console. Regards, - Rob Regards, Tharmarajan G On Tue, 2010-07-06 at 09:00 -0600, Todd Fischer wrote: Tharmarajan, I believe you need to rebuild your codec server with a different memory map. Another idea is to have a hole in the kernel memory space (specify mem= in the kernel command line twice). I am not sure if the kernel version you are using for dm355 supports a hole in the kernel memory space. Todd On Mon, 2010-07-05 at 19:44 +0530, Tharmarajan Ganeshan wrote: Hi All, We are working on a DM355 processor based Development board. The Board has 256MB mDDR RAM and 5MP image sensor MT9P031. We are using the kernel version 2.6.10 We have modified the driver code for capturing 5MP raw image and converting this 5MP raw into YUV. For this 5MP image capturing , we have reserved 30MB. We have allocated 56MB to the CMEM driver. The reserved memory 30MB and the 56MB memory for CMEM are at top of the RAM. We are passing the remaining memory size to the kernel in bootargs as mem=170M. And we are using the NFS rootfilesystem. But we are getting kernel hanging issues while testing the IPNC_APP applications and 5MP still image capturing. Sometimes the kernel is hanging while booting itself. If we reserve the 30MB from the address region 0x8320 - 0x84FF and pass the memory size to kernel in bootargs as mem=50M, then we are NOT having any issues in running the applications. But we want to use the exact remaining memory. And also we are not able to program the NAND flash memory in kernel level if we are not passing the mem=50M in bootargs. What could be the cause for this kernel hanging issue ? Are we missing any configurations while building the kernel image ? Our Bootargs is : mem=50M console=ttyS1,115200n8 root=/dev/nfs rootwait rw ip=192.168.1.90:192.168.1.99:192.168.1.1:255.255.255.0 nfsroot=192.168.1.99:/tftpboot/bellatrix_rootfilesystem,nolock eth=00:0C:0C:A0:01:FE v4l2_video_capture=:device=MT9P031 Regards, Tharmarajan G ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.commailto:Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: CMEM module build with recent kernel drop.
-Original Message- From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincids p.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d avincidsp.com] On Behalf Of Mike Williamson Sent: Friday, May 28, 2010 6:46 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: CMEM module build with recent kernel drop. Not sure if this is the right place for this... It looks like the latest version of the linux utilities (specifically CMEM for the OMAP-L138) no longer build with kernel Revs = 2.6.34. This is due to the change in the dma-api (e.g., the dmac_inv_range and clean functions have gone away). I tried to replace the dmac_* calls with dmac_map_area as suggested in another thread I stumbled upon, but the module failed to load as the underlying __glue'd symbols (arm926_dma_map_area) are not exported. Has anyone else run into this? Am I missing something? My understanding is CMEM is required in order to use DSPLink. Is this not the case? I'm trying to build linuxutils_2.25.02.08 from TI. I'm tempted to simply export the needed symbols, but that sort of flies in the face of the new DMA-API architecture. Is there a patch to CMEM out there? Thanks for any insight. -Mike -- Michael Williamson 315-425-4045x230 www.criticallink.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source This place is as good as any for CMEM issues, as it is monitored by those that are responsible for developing CMEM (and we did see your old post here but wanted to wait to respond until we knew the answer). Another good place would be the TI Forums (http://e2e.ti.com/) which are an ever-evolving database of TI issues and answers. There's a TI Linux Forum here: http://e2e.ti.com/support/embedded/f/354.aspx TI has just released a Linux Utils package that contains a CMEM with support for Linux 2.6.34. It can be downloaded from http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/2_25_04_10/index_FDS.html. Since this is new it hasn't gained a lot of mileage, so please let us know (using this list would be fine) if there are issues or if the new cache functionality doesn't work. Regards, - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
kernel cache APIs
I need to port CMEM to the newer 2.6.34 Linux kernel but am having trouble with
the cache functions. This is for the TI ARM, in general.
CMEM provides general capability to user programs to initiate a cache
operation, mostly for the purpose of affecting the cache contents pertaining to
the CMEM buffers. CMEM allows the user to specify either a writeback, an
invalidate, or a writeback/invalidate. These operations are always for user
virtual addresses.
Previously I was calling dmac_{clean,inv,flush}_range() to do the wb/inv/wbinv,
respectively. Now it seems that only dmac_flush_range() exists (at least,
that's the only one of the 3 that doesn't get an implicit declaration error
when compiling). There was some talk a while back on this maillist of having
to change to use dma_map_single(), but in 2.6.34 that API appears to be much
different than before, and not appropriate for just triggering an operation on
the cache.
Can anyone please point me to the appropriate cache APIs? (I don't want to
call all type operations, just range type)
Thanks Regards,
- Rob
Texas Instruments, Santa Barbara
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Compile Error
-z means that every following option is for the linker, and since many compiler options follow the expansion of usr.bld, you can't use -z in that file. Is there not a link.cmd or linker.cmd file that can be used instead (and is consumed by the XDC tooling)? Regards, - Rob From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Mohamed AbdElwahed Sent: Tuesday, April 27, 2010 5:38 AM To: Davinci Mailing list Subject: Compile Error I use DM6446 and i implemented my own codec and i success to compile(the CGT is version 6.1.12) and run it. but when i edit the usr.bld file by adding this options -z -l forder.cmd to the compiler options, it fail with the below error. # generating interfaces for package codecs.decode_slice_h264 (because package/package.xdc.xml is older than package.xdc) ... /opt/xdc_3_05/xs -Dxdc.path=/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../..;/opt/codec_engine_2_10/cetools/packages;/opt/codec_engine_2_10/packages;/opt/bios_5_32_02/packages;/opt/xdc_3_05/packages;../.. -Dxdc.root=/opt/xdc_3_05 -Dxdc.hostOS=Linux -Dconfig.importPath=.;/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../..;/opt/codec_engine_2_10/cetools/packages;/opt/codec_engine_2_10/packages;/opt/bios_5_32_02/packages;/opt/xdc_3_05/packages;../..;/opt/xdc_3_05;/opt/xdc_3_05/etc -Dxdc.bld.targets= -DTOOLS= -f xdc/services/intern/cmd/build.xs -m package/package.xdc.dep -i package/package.xdc.inc package.xdc translating DECODE_SLICE_H264 .interfaces files complete: Tue Apr 27 14:04:08 EET 2010. .libraries [/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264] rm -f package/lib/lib/decode_slice_h264/package/package_codecs.decode_slice_h264.o64P # # cl64P package/package_codecs.decode_slice_h264.c ... /opt/TI/C6000CGT6.1.13/bin/cl6x -c -mt -mo --opt_for_speed=5 -O3 --program_level_compile --silicon_version=6446 --keep_asm --opt_for_speed=5 -z -l forder.cmd -mv64p -eo.o64P -ea.s64P -D__xdc_bld_pkg_c__=package.bld.c -Dxdc_target_name__=C64P -Dxdc_target_types__=ti/targets/std.h -Dxdc_bld__profile_release -Dxdc_bld__vers_1_0_6_1_13 -o2 -I. -I/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264/../.. -I/opt/codec_engine_2_10/cetools/packages -I/opt/codec_engine_2_10/packages -I/opt/bios_5_32_02/packages -I/opt/xdc_3_05/packages -I../.. -I/opt/TI/C6000CGT6.1.13/include -fs=./package/lib/lib/decode_slice_h264/package -fr=./package/lib/lib/decode_slice_h264/package -fc package/package_codecs.decode_slice_h264.c WARNING: invalid linker option -D__xdc_bld_pkg_c__=package.bld.c (ignored) WARNING: invalid linker option -Dxdc_target_name__=C64P (ignored) WARNING: invalid linker option -Dxdc_target_types__=ti/targets/std.h (ignored) WARNING: invalid linker option -Dxdc_bld__profile_release (ignored) WARNING: invalid linker option -Dxdc_bld__vers_1_0_6_1_13 (ignored) ERROR: argument to option -f (value) is out of range gmake[1]: *** [package/lib/lib/decode_slice_h264/package/package_codecs.decode_slice_h264.o64P] Error 1 gmake: *** [/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264,.libraries] Error 2 make[2]: *** [all] Error 2 make[2]: Leaving directory `/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs/decode_slice_h264' make[1]: *** [all] Error 2 make[1]: Leaving directory `/ESDU/Wasiem/filesys/All_in_One/esdu_decode_slice_h264/codecs' make: *** [all] Error 2 Any help is highly appreciated Mohamed AbdElwahed Ibrahim [http://graphics.hotmail.com/i.p.emthup.gif] From: davinci-linux-open-source-requ...@linux.davincidsp.com Subject: Davinci-linux-open-source Digest, Vol 52, Issue 65 To: davinci-linux-open-source@linux.davincidsp.com Date: Wed, 21 Apr 2010 07:11:32 -0500 Send Davinci-linux-open-source mailing list submissions to davinci-linux-open-source@linux.davincidsp.com To subscribe or unsubscribe via the World Wide Web, visit http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source or, via email, send a message with subject or body 'help' to davinci-linux-open-source-requ...@linux.davincidsp.com You can reach the person managing the list at davinci-linux-open-source-ow...@linux.davincidsp.com When replying, please edit your Subject line so it is more specific than Re: Contents of Davinci-linux-open-source digest... Today's Topics: 1. Re: [PATCH 4/4] DM365: Add platform resource management (Kevin Hilman) 2. Re: [PATCH 2/4]
RE: how Codec_engine call the dsplink
From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of liuyue18301 Sent: Tuesday, April 06, 2010 6:56 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: how Codec_engine call the dsplink hello everybody: well in the video_copy demos of the codec_engine i think i call the api of dsplink to implement the communication between arm and dsp. but i can't find out that in the code who can help me it confused me so long time. what is the relationship codec_engine and dsplink and the relationship of calling thank you very much. DSPLink is used internally by Codec Engine. You do not call any DSPLink APIs, which is the whole point of Codec Engine, to insulate the user from the details of the implementation. You just call Codec Engine APIs, as the video_copy demo does, or any of the Codec Engine example apps. DSPLink is used by Codec Engine when there is a remote server configured into the system, so you need to configure a remote server but you don't need to configure the use of DSPLink, since Codec Engine does that for you. If you're just doing a local codec then you won't specify a server and DSPLink is not needed in this case. - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: CMEM Memory Map
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Vladimir Pantelic Sent: Monday, February 15, 2010 4:27 AM To: davinci-linux-open-source@linux.davincidsp.com Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: CMEM Memory Map Sameer Naik wrote: One way to achieve this is my simply increasing the cmem memory, so that the module load line, for example, would look like this: 1. # insert cmemk, tell it to occupy physical 109MB-128MB (19M). insmod cmemk.ko phys_start=0x86D0 phys_end=0x8800 pools=1x360,16x829440,2x1244160,1x40960,2x8192 2. The other way is to get rid of all other pools that are existing, and keep only the 829440 bytes sized pool, eg. # insert cmemk, tell it to occupy physical 115MB-128MB (13M). insmod cmemk.ko phys_start=0x8730 phys_end=0x8800 pools=16x829440 At least currently i am not allocating buffers other than of size 829440, using CMEM, but at the same time i am not sure whether any of the dsp algorithms allocated memory using CMEM (by guess would be no). there should be at least one other CMEM buffer to pass the h264 data fro the ARM to the DSP. There is something in /proc or /sys where you can see the cmem memory usage... % cat /proc/cmem Will show you the state of all CMEM buffers. Regards, - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: How to integrate another decoder to my existing decoder?
There is a good manual here, named Codec Engine Server Integrator User's
Guide: http://focus.ti.com/lit/ug/sprued5b/sprued5b.pdf.
It describes what you need to do to put multiple codecs in an application. You
will need to create a Codec Server that contains both your algorithms (codecs),
since you can load only one server at a time on the DSP.
You say you tried but didn't state details about what you tried, nor details
about it failing. You will get better support if you provide more detail, but
hopefully the guide I pointed to will be enough to get you going in the right
direction.
Regards,
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Mohamed AbdElwahed
Sent: Tuesday, February 09, 2010 5:02 AM
To: Davinci Mailing list
Subject: How to integrate another decoder to my existing decoder?
Hi all,
i am using DM6446. i used the video_copy example to implement my codec, and i
do it. now i do another one based also on the video_copy example but i want now
to integrate both of them.
note:- currently i have 2 seperate folder structures each one contains the
folders named (apps, buildutils, codecs, and servers)
i want to have only one folder structure for the 2 codecs.
Is there any document/URL/HELP/Suggestions to do this? or this is not possible
to do this at all?
I tryed below but it failed
i modified ceapp_init(), that open, (Engine_open()), the codec engine and
create, (VIDDEC_create()), two video decoders that attached to it.
as below
--
// reset, load, and start DSP Engine
if ((ceHandle = Engine_open(engineName, NULL, NULL)) == NULL)
{
printf(CEapp- ERROR: can't open engine %s\n, engineName);
goto init_end;
}
else
printf(CEapp- Engine opened %s\n, engineName);
// activate DSP trace collection thread
TraceUtil_start(engineName);
// allocate and initialize video decoder on the engine
decHandle1 = VIDDEC_create(ceHandle, decoderName1, NULL);
if (decHandle == NULL)
{
printf(CEapp- ERROR: can't open codec %s\n, decoderName);
goto init_end;
}
decHandle2 = VIDDEC_create(ceHandle, decoderName2, NULL);
if (decHandle == NULL)
{
printf(CEapp- ERROR: can't open codec %s\n, decoderName);
goto init_end;
}
// success
status = 0;
--
also i created two functions named ceapp_decodeBuf1() and ceapp_decodeBuf2()
each one call the corresponding decoder.
that is all i do, am i right or this is totally wrong or there is still other
modifications that should be done and i missed!!
--
your help is highly appreciated
thanks
Mohamed AbdElwahed Ibrahim [http://graphics.hotmail.com/i.p.emthup.gif]
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up
now.https://signup.live.com/signup.aspx?id=60969
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Arago Kerenel w/ codec_engine_2_00_01 issues?
Chris has already responded to your other issues, so please see just one comment from me below. Regards, - Rob -Original Message- From: Paul Stuart [mailto:paul_stu...@seektech.com] Sent: Tuesday, January 05, 2010 7:26 AM To: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com Subject: RE: Arago Kerenel w/ codec_engine_2_00_01 issues? Thanks for the response! I'll give the latest CMEM, LinuxUtils, et al a whirl and see what happens. The strange thing is that the mpeg4 decoder, jpeg encode/decode, and mp3 encode/decode all load without complaint. It's just the mpeg4enc that fails. I've rebuilt cmemk.ko and dm350mmap.ko against the arago kernel. Neither process was straight forward though because of changes between the montavista kernel we were using. Maybe something got botched in the process. One of the reasons to upgrade to the latest LinuxUtils is that they've been ported to the recent DaVinci GIT kernel releases, although I don't know if the MontaVista changes have kept up-to-date with the GIT changes. Turning on the trace, with CE_DEBUG=2, I get the following during mpeg4enc initialization: @5,653,051us: [+0 T:0x43300490] ti.sdo.ce.video1.VIDENC1 - VIDENC1_create Enter (engine=0x100670, name='mpeg4enc', params=0x432ffca8) @5,653,350us: [+0 T:0x43300490] CV - VISA_create(0x100670, 'mpeg4enc', 0x432ffca8, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') @5,653,569us: [+0 T:0x43300490] CV - VISA_create2(0x100670, 'mpeg4enc', 0x432ffca8, 0x30, 0x2496, 'ti.sdo.ce.video1.IVIDENC1') @5,654,187us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_create Enter(fxns=0xf89c0, idma3Fxns=0xf8988, iresFxns=0x0, params=0x432ffca8, attrs=0x432ffac8) @5,654,470us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Enter (scratchId=1, fxns=0xf89c0, parentAlg=0x0, params=0x432ffca8) @5,678,280us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create algNumAlloc 7 memory recs @5,678,574us: [+2 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create algAlloc returned numRecs=7 @5,678,777us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[0]: size=0x2c58, align=0x100, space=0x11, attrs=0x1 @5,678,985us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[1]: size=0x200, align=0x100, space=0x11, attrs=0x1 @5,679,182us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[2]: size=0x19a400, align=0x100, space=0x11, attrs=0x1 @5,679,568us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[3]: size=0x10e0, align=0x100, space=0x11, attrs=0x1 @5,679,816us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[4]: size=0x4, align=0x100, space=0x11, attrs=0x1 @5,680,026us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[5]: size=0x14000, align=0x100, space=0x11, attrs=0x1 @5,680,233us: [+4 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Memory requested memTab[6]: size=0x3840, align=0x100, space=0x11, attrs=0x1 @5,680,648us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(11352) = 0x43301000. @5,680,909us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x43301000) = 0x8702c000. @5,681,514us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(512) = 0x42a02000. @5,681,792us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x42a02000) = 0x87018000. @5,682,401us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(1680384) = 0x43305000. @5,682,711us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x43305000) = 0x87e0. @5,698,324us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(4320) = 0x43505000. @5,698,622us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x43505000) = 0x8702a000. @5,699,098us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(4) = 0x43507000. @5,699,535us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x43507000) = 0x87019000. @5,700,033us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(81920) = 0x43508000. @5,700,348us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x43508000) = 0x8704e000. @5,701,570us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_alloc(14400) = 0x4351c000. @5,701,844us: [+4 T:0x43300490] OM - Memory_contigAlloc CMEM_getPhys(0x4351c000) = 0x8703. @5,757,804us: [+7 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create algInit call failed 49280 @5,765,522us: [+0 T:0x43300490] ti.sdo.ce.osal.alg - ALG_create Exit (algHandle=NULL) @5,765,791us: [+7 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_create Algorithm creation FAILED; make sure that 1) alg params are correct/appropriate, 2) there is enough internal and external algorithm memory available -- check DSKT2 settings for heap assignments and scratch allocation @5,766,031us: [+0 T:0x43300490] ti.sdo.ce.alg.Algorithm - Algorithm_delete Enter(alg=0x1fb020
RE: Cmem address translation when working with Codec Engine
This sounds like an odd setup, how are you even calling the codec if not through CE? Since the first codec is assuming responsibility for doing first things, like calling CERuntime_init(), can't it also call Memory_registerContigBuf()? From your earlier descriptions it sounds like you might need a way to inform this first codec of the (big CMEM) buffer size to register, but communicating that info sounds easier than tracking small buffer subdivisions. Regards, - Rob -Original Message- From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincids p.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d avincidsp.com] On Behalf Of Erez Kinarti Sent: Tuesday, January 05, 2010 1:26 AM To: Vladimir Pantelic; Davinci-linux-open-source@linux.davincidsp.com Cc: Davinci-linux-open-source@linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine No, because in my system, the first codec that is generated is calling CERuntimeInit (working with C++, keeping reference counter for the call to CERuntimeInit and CERuntimeExit), while the system buffers are allocated before that. -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Vladimir Pantelic Sent: Tuesday, January 05, 2010 11:15 AM To: Davinci-linux-open-source@linux.davincidsp.com Cc: Davinci-linux-open-source@linux.davincidsp.com Subject: Re: Cmem address translation when working with Codec Engine Erez Kinarti wrote: Hey Rob, I see that calling the register functions require that CE is in the air (CERuntimeInit) so it is problematic for us in the same way as doing the CMEM allocations via CodecEngine. as you have to call CERuntimeInit() before using any of CE, you can do the Memory_registerContigBuf() after CERuntimeInit(), no? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Cmem address translation when working with Codec Engine
I would expect that the size that you use is good enough for the Memory_registerContigBuf() call. The only way you can query the size of the buffers allocated by CMEM is to do so in a non-direct manner, by performing %cat /proc/cmem and parsing the ASCII output (try out that command, you'll see what I mean). - Rob -Original Message- From: Erez Kinarti [mailto:er...@radvision.com] Sent: Tuesday, January 05, 2010 12:21 AM To: Tivy, Robert; Vladimir Pantelic; Davinci-linux-open-source@linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine Thank you very much Rob, I'm going to try it now. Just one open issue is the size of the big buffer: In the app I cannot be sure what is the buffer size that CMEM allocated for me, I just know that the size is at least the size that I requested. Do I have to put the size parameter in these function the exact size allocated by CMEM, or just the size that I use is enough? In case I must use the size allocated by CMEM, is there a way to know what this size is? Thanks, Erez -Original Message- From: Tivy, Robert [mailto:rt...@ti.com] Sent: Tuesday, January 05, 2010 1:30 AM To: Erez Kinarti; Vladimir Pantelic; Davinci-linux-open-source@linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine There is no function available to invalidate all the Memory module virt-phys translations. If your app structure allows it, you can call Memory_registerContigBuf(bigCMEMBufferVirtAddr, 258048, CMEM_getPhys(bigCMEMBufferVirtAddr)); once, and all smaller subdivided buffers will be covered by this one registration (or, even simpler, just call Memory_getBufferPhysicalAddress(bigCMEMBufferVirtAddr, 258048, NULL); and ignore the result, which will do the CMEM_getPhys() for you and register it). You can then call Memory_unregisterContigBuf(bigCMEMBufferVirtAddr, 258048) once when you're ready to free the CMEM buffer. FYI, if you want to double-check me, you can call Memory_dumpKnownContigBufsList() to display (through GT tracing) the contig buffer list (AKA, the Memory module virt-phys translation table). Regards, - Rob -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Erez Kinarti Sent: Monday, January 04, 2010 9:15 AM To: Vladimir Pantelic; Davinci-linux-open-source@linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine Thank you Vladimir, But we are not able to allocate and free via CodecEngine due to the structure of our application and the need to call the alloc not before calling CERuntimeInit(). -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Vladimir Pantelic Sent: Monday, January 04, 2010 7:09 PM To: Davinci-linux-open-source@linux.davincidsp.com Subject: Re: Cmem address translation when working with Codec Engine Erez Kinarti wrote: Thanks a lot Rob. calling this function for each of the pointers used with CodecEngine solved the problem. However, we need something else, some function that invalidates all this virt-phy table and not each of the virtual pointers separately. Is there a way to do a full invalidate in a single call without keep tracking on each of the virtual pointers? The reason that Memory_unregisterContigBuf it is not enough for us: In our system, we allocate a very big buffer from CMEM (258048 bytes), but we don't call CodecEngine with a pointer to the big buffer. You dont need to call Memory_unregisterContigBuf, just alloc and free the buffers via CE and CE will know that you are calling it with a smaller buffer inside a larger one that it knows the translation to... ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Cmem address translation when working with Codec Engine
There is no function available to invalidate all the Memory module virt-phys translations. If your app structure allows it, you can call Memory_registerContigBuf(bigCMEMBufferVirtAddr, 258048, CMEM_getPhys(bigCMEMBufferVirtAddr)); once, and all smaller subdivided buffers will be covered by this one registration (or, even simpler, just call Memory_getBufferPhysicalAddress(bigCMEMBufferVirtAddr, 258048, NULL); and ignore the result, which will do the CMEM_getPhys() for you and register it). You can then call Memory_unregisterContigBuf(bigCMEMBufferVirtAddr, 258048) once when you're ready to free the CMEM buffer. FYI, if you want to double-check me, you can call Memory_dumpKnownContigBufsList() to display (through GT tracing) the contig buffer list (AKA, the Memory module virt-phys translation table). Regards, - Rob -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Erez Kinarti Sent: Monday, January 04, 2010 9:15 AM To: Vladimir Pantelic; Davinci-linux-open-source@linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine Thank you Vladimir, But we are not able to allocate and free via CodecEngine due to the structure of our application and the need to call the alloc not before calling CERuntimeInit(). -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Vladimir Pantelic Sent: Monday, January 04, 2010 7:09 PM To: Davinci-linux-open-source@linux.davincidsp.com Subject: Re: Cmem address translation when working with Codec Engine Erez Kinarti wrote: Thanks a lot Rob. calling this function for each of the pointers used with CodecEngine solved the problem. However, we need something else, some function that invalidates all this virt-phy table and not each of the virtual pointers separately. Is there a way to do a full invalidate in a single call without keep tracking on each of the virtual pointers? The reason that Memory_unregisterContigBuf it is not enough for us: In our system, we allocate a very big buffer from CMEM (258048 bytes), but we don't call CodecEngine with a pointer to the big buffer. You dont need to call Memory_unregisterContigBuf, just alloc and free the buffers via CE and CE will know that you are calling it with a smaller buffer inside a larger one that it knows the translation to... ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: codec hangs
Nothing comes to mind from just your description. BTW, that really strange address (0xbeffc850) seems like a Linux user stack address. Since nothing jumps out from your top-down description, I would suggest a bottom-up investigation - debugging the DSP. Seems that the codec's control() code is sending the DSP into the weeds, at least with the parameters passed in. I would suggest putting a BP on the codec's control() function and stepping that function to see where the DSP goes bad. Regards, - Rob From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Albert Burbea Sent: Tuesday, December 29, 2009 11:22 AM To: davinci-linux-open-source Subject: codec hangs Hi everybody, I am using mv 4.01 with codec engine 2.01. I am integrating the TI JPEG encoder 1.1.13. At the beginning it did not work,it did not even open, until I modified the JPEGENC.xs to return the saram and daram scratch sizes. Before that, I modified also the ce/JPEGENC.xdc to use an IMGENC1 VISA interface instead of the IMGENC interface. I was able to open it and do an XDM_SETPARAMS control, but I did not try anything more. I restored the IMGENC interface in ce/JPEGENC.xdc, and compiled. Still worked. Then, I added a CMEM allocation for the output buffer, and... it hangs! Of course I removed the allocation and retried, but nope, I can only open it. Wen I execute the XDM_SETPARAMS, everything seems fine until the VISA_call for the XDM_SETPARAMS. The pointers it receives seem really strange to me, one of them if beffc850 or something like. It only enters the call, is able to queue the call, but then waits forever for the message queue to return, and everyting dies. What can be the problem? I verified several times the tcf file and the cmem settings and seem correct to me. Thanks in advance Albert -- Albert Burbea Harishonim 8 Ramat Gan 52502, Israel Tel/Fax + 972-3-7526016 Mobile: +972-52-3541842 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Arago Kerenel w/ codec_engine_2_00_01 issues?
Generally, user-level code doesn't care much about the kernel version, and CE itself is all user-level code. Since CE encapsulates other packages that do contain kernel modules (which do care about kernel version), such as CMEM in LinuxUtils and DSPLink, the problem probably is with those. The kernel modules call APIs that can come or go with particular Linux kernels, hence the dependency of kernel modules on the kernel. Typically you will need to rebuild the kernel modules for the particular kernel that you're running. Rebuilding is also important with respect to simply inserting the kernel modules (usually done with a loadmodules.sh script) - you can't insert a kernel module that's been built against a kernel other than the one you're running (although there is some flexibility if the kernels in question are close enough to each other). It would help if you described your problem opening the mpeg4enc video encode algorithm. CE 2.00.01 is fairly old at this point, much older than 2.6.26 Linux. I would suggest updating to a newer CE, which also might just fix your problem. Regards, - Rob -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Paul Stuart Sent: Thursday, December 31, 2009 12:55 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: Arago Kerenel w/ codec_engine_2_00_01 issues? Hi There, Wondering if there is any magic that has to happen to make the dvsdk's codec engine (2_00_01) play with the arago kernel (2.6.26)? Everything compiles fine, but my app can't open the mpeg4enc video encode algorithm. Thanks, Paul ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
FW: Cmem address translation when working with Codec Engine
Oops, forgot to Reply All... - Rob From: Tivy, Robert Sent: Wednesday, December 30, 2009 10:57 AM To: 'Erez Kinarti' Subject: RE: Cmem address translation when working with Codec Engine Erez, Thanks for your detailed explanation, it allows me to understand your problem and the solution. The bottom line is that you should be using CE's Memory module to allocate CMEM memory. This will alleviate your wrong phys addr to the DSP. If you want to continue using CMEM_alloc/free, then you can remove CE's cached virt-phys translation with: Memory_unregisterContigBuf(virtAddr, 258048); The reason you need to use CE's Memory module is because the codec class stub file is using it to get the phys addr of a virt buffer. What happens when you allocate outside of Memory is the following: - allocate with CMEM_alloc(), which causes the kernel to create the virt-phys mapping (there is no table in CMEM). - pass this buffer to CODECCLASS_process() - CODECCLASS_process() calls Memory_getBufferPhysicalAddress(virtAddr) - the Memory module keeps a cache of virt-phys mappings, and since Memory hasn't seen this buffer before, it asks CMEM with CMEM_getPhys(). - CMEM returns the correct phys addr and Memory caches this mapping. - you free the buffer, which frees the kernel mapping for it, then allocate a new one, and the Linux kernel creates a new mapping - the Linux kernel decides to reuse the same virt addr from before, but this time with a different phys addr - CODECCLASS_process() calls Memory_getBufferPhysicalAddress(virtAddr) - since Memory module didn't know about the freeing of the previous buffer, it uses its old cached translation. To allocate CMEM through Memory: Memory_AllocParams params; params.type = Memory_CONTIGPOOL; params.flags = Memory_CACHED; // or Memory_NONCACHED if so desired addr = Memory_alloc(258048, params); ... Memory_free(addr, 258048, params); Regards, - Rob From: Erez Kinarti [mailto:er...@radvision.com] Sent: Wednesday, December 30, 2009 12:10 AM To: Tivy, Robert; Amit Klir; Davinci-linux-open-source@linux.davincidsp.com Subject: RE: Cmem address translation when working with Codec Engine Hello Rob, I'm working with Amit on the same problem. Thank you very much for your quick answer and willing to help. We take the buffers directly from Cmem pool. We have a pool of 3x258048 in cmem (three buffers with size 258048), and we take one of the buffers from CMEM directly using CMEM_alloc. We do it only once for the speech codec, and this buffer is the only buffer used by us as for output buffer. After we close the codec (SPHENC_delete), we release the buffer back to CMEM directly using CMEM_free. All the CMEM allocation and free is done directly with CMEM and NOT via CodecEngine. In our case, after closing the codec and releasing the buffer, we want to reopen the codec. What we do is getting a new buffer from CMEM directly using CMEM_alloc, and then opening the codec using SPHENC_create. Another issue that is important is that in the second time, we get from CMEM a buffer with the same virtual address as the first buffer, just with different physical address. It seems like CMEM changed the virtual to physical mapping. However, when calling the DSP, it seems like CE is using the same mapping as in the first time which is no longer valid, and the DSP codec is getting a pointer to the physical buffer used in the first time. Is it possible that CMEM is changing the address translation mapping and CE is not synchronized with it and is using its old virt-to-phy mapping. Our main question: === What action should we do in order to synchronize the virt-to-phys cache in CE's Memory module with the CMEM virtual to physical mapping? Is there any CE command that tells CE to invalidate its virt-to-phys cache and take the updated values from CMEM? Thanks, Erez From: Tivy, Robert [mailto:rt...@ti.com] Sent: Tuesday, December 29, 2009 7:52 PM To: Amit Klir; Davinci-linux-open-source@linux.davincidsp.com Cc: Erez Kinarti Subject: RE: Cmem address translation when working with Codec Engine How are you returning CMEM buf to the pool for each codec thread? CE contains a virt-to-phys cache in CE's Memory module, and a CE codec class stubs file will use the Memory module to translate the virt addr to a phys addr. If CMEM buffer allocation is happening through the Memory module but CMEM buffer freeing is done through just CMEM then this situation can happen. There is no known problem in CMEM 2.10 of this sort, however CMEM 2.10 is older and I believe you could upgrade to LinuxUtils 2.25 which contains a later CMEM. There is also a CE 2.25 that you could upgrade to. In order for me to tell more of what's going on I would need to see some trace output from your application. Later CE releases contain support for an environment
RE: Cmem address translation when working with Codec Engine
How are you returning CMEM buf to the pool for each codec thread? CE contains a virt-to-phys cache in CE's Memory module, and a CE codec class stubs file will use the Memory module to translate the virt addr to a phys addr. If CMEM buffer allocation is happening through the Memory module but CMEM buffer freeing is done through just CMEM then this situation can happen. There is no known problem in CMEM 2.10 of this sort, however CMEM 2.10 is older and I believe you could upgrade to LinuxUtils 2.25 which contains a later CMEM. There is also a CE 2.25 that you could upgrade to. In order for me to tell more of what's going on I would need to see some trace output from your application. Later CE releases contain support for an environment variable called CE_DEBUG that can be set to 1|2|3. Setting it to 3 will generate lots of useful output (and lots of noise too, unfortunately). I don't recall if 2.10 supports CE_DEBUG or if that came after 2.10, if not then you would have to use CE_TRACE instead (which is documented). If you can run your app with this trace output enabled and send it to me I can take a look. Regards, - Rob From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Amit Klir Sent: Tuesday, December 29, 2009 7:26 AM To: Davinci-linux-open-source@linux.davincidsp.com Cc: Erez Kinarti Subject: Cmem address translation when working with Codec Engine Hello, I'm working with DaVinci DM6467, using ARM running linux, and CodecEngine as the interface between ARM and DSP. My application is doing audio and video encoding in parallel in two different threads. I'm also using CMEM version 2.10 for continuous buffers allocation. The problem is that, in some situation, the CMEM buffer physical address viewed by ARM (using CMEM_getPhys()) is different than the physical address sent to DSP (translated by CodecEngine). Scenario where ArmPhyAddr != DspPhyAddr: === In my application, I open CodecEngine and then open two codecs on the DSP: VIDENC1 and SPHENC1. In the beginning both codecs are running in two different threads, and for each of them we keep a CMEM buffers pool in ARM for their IO buffers. When the app starts running, for each Codec it take a single buffer from the relevant Cmem pool, and use only this buffer for all the run. In the beginning the physical addresses viewed by ARM and DSP are equal. After a while, we do the following sequence of closing and opening the codecs: 1. Close and open the video codec - VIDENC1_delete() - Return the CMEM buf of VIDENC to the pool. - Take a new CMEM buffer from the pool to be used for VIDENC. - VIDENC_create() - Running video processing of a stream ... 2. Close and open the speech codec: - SPHENC1_delete() - Return the CMEM buf of SPHENC to the pool. - Take a new CMEM buffer from the pool to be used for SPHENC. - SPHENC_create() - Running speech processing of a stream ... After doing this sequence and continue running the video and audio processing. Now on the SPHENC codec, the CMEM buffer physical address viewed by ARM is different than the one viewed by the DSP for the same buffer. In addition I see that there is a constant offset between them which is the size of a CMEM buffer used for the speech (in our case 258048). That means that the same virtual address in the ARM is translated in ARM to different physical address than the one translated by CodecEngine. It seems like two different translation tables are used, and they are not synchronized. Our CMEM pool for the speech usage is made of 3 buffers of size 258048. Does anyone know what can cause this problem? To me it seems like CMEM problem, however, when checking in TI site I see that version 2_10 that I'm using is currently the official version. Thanks in advance for any help, ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Where is dm350mmap_reply_mutex defined?
Perhaps you missed an earlier build error related to it. My (old) copy of dm350mmap.c has: static DECLARE_MUTEX_LOCKED (dm350mmap_reply_mutex); You can know that it *should* be defined in dm350mmap.c because it's got the dm350mmap perfix. Regards, - Rob -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Paul Stuart Sent: Tuesday, December 15, 2009 3:11 PM To: Linux on DaVinci Subject: Where is dm350mmap_reply_mutex defined? Hi, Can't rebuild the DVSDK's dm350mmap.ko because dm350mmap_reply_mutex is undefined. (dm350mmap.ko seems to ship with the DVSDK precompiled) Can't find it (dm350mmap_reply_mutex) in the DVSDK sources, git, arago, or montavista kernels. Any leads? Thanks! Paul ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Passing buffers to Codec engine as inArgs params
I'm not really a codec or XDAIS guy, but I believe it would violate some codec coding standard (probably XDAIS) to call cache functions inside the codec process call. With Codec Engine's skeletons there is a way for the codec to tell the skeleton to perform a cache operation after returning from the process call (by setting an 'accessMask' structure element), but this applies only to outBufs usually. What CE codec class are you using? IVIDDEC? IVIDDEC1? Different codec classes have different cache management operations in the skeletons, so a different one than what you're using today could help with your cache management. Regards, - Rob From: Sriraja Yagneswaran [mailto:sriraja_yagneswa...@mindtree.com] Sent: Tuesday, November 17, 2009 8:34 PM To: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com Subject: RE: Passing buffers to Codec engine as inArgs params Thanks Robert, I'm unsure about where exactly would the cache invalidation and writeback functions be called. Would if be sufficient if I do cache management within the process call of my DSP codec (before and after the buffers are used ) or do they have to appear elsewhere (i.e. do I have to build a customized stub and skeleton for the codec that includes the cache management for the extra buffers?) Regards Sriraja From: Tivy, Robert [mailto:rt...@ti.com] Sent: Tuesday, November 17, 2009 11:41 PM To: Sriraja Yagneswaran; davinci-linux-open-source@linux.davincidsp.com Subject: RE: Passing buffers to Codec engine as inArgs params Codec Engine has mechanisms in place to manage the cache for inBufs outBufs being transferred between an ARM and DSP, but there is no cache management for inArgs/outArgs. Perhaps this is your problem and you could try to manage the cache for these buffers manually using the CE osal's Memory interface? Regards, - Rob From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On Behalf Of Sriraja Yagneswaran Sent: Tuesday, November 17, 2009 12:44 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Passing buffers to Codec engine as inArgs params I have a setup as described below: A capture device on the ARM side that gives me an input frame that contains data for 4 input channels interleaved as 4 quadrants of a larger frame. To supply the 4 processes with input data I make 4 copies of the captured frame (capture copy buffers). The copy buffers are allocated contiguous memory on the ARM though the CMEM pools. The physical memory of the copy buffers is obtained and shared among the processes. Another buffer of the larger size is allocated through CMEM and its physical memory is also shared (display copy buffer). This is for the processes to write back the processed data and display them. The 4 processes make a codec engine call with the physical address of their respective capture copy buffer is passed as input argument (extended inArgs). This is done as the buffer itself is created in another ARM application and not readily available for the current application context. Within the DSP process call each of the process copies out their relevant quadrants to work on them. The DSP process call also writes its processed buffer back into the corresponding quadrant of the display copy buffer before returning from the DSP. On the ARM side the display copy buffer is copied to the display buffer and sent to the device for display. We have put a signaling mechanism around the codec engine process calls on the ARM side for 4 codec engine + capture applications such that they execute in a serial manner (i.e. one starts only after the previous one has returned). This setup runs and seems to function as intended but hangs at intermittent times (sometime after 10+ hours). One of our suspicions is on the usage of the copy buffers (that are being used on both ARM and DSP side without being passed as either inBufs or outBufs). Please advise if such a usage is correct and if some sanity checks are possible. Alternative suggestions for usage are also welcome. Thanks Sriraja http://www.mindtree.com/email/disclaimer.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Passing buffers to Codec engine as inArgs params
Codec Engine has mechanisms in place to manage the cache for inBufs outBufs being transferred between an ARM and DSP, but there is no cache management for inArgs/outArgs. Perhaps this is your problem and you could try to manage the cache for these buffers manually using the CE osal's Memory interface? Regards, - Rob From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On Behalf Of Sriraja Yagneswaran Sent: Tuesday, November 17, 2009 12:44 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Passing buffers to Codec engine as inArgs params I have a setup as described below: A capture device on the ARM side that gives me an input frame that contains data for 4 input channels interleaved as 4 quadrants of a larger frame. To supply the 4 processes with input data I make 4 copies of the captured frame (capture copy buffers). The copy buffers are allocated contiguous memory on the ARM though the CMEM pools. The physical memory of the copy buffers is obtained and shared among the processes. Another buffer of the larger size is allocated through CMEM and its physical memory is also shared (display copy buffer). This is for the processes to write back the processed data and display them. The 4 processes make a codec engine call with the physical address of their respective capture copy buffer is passed as input argument (extended inArgs). This is done as the buffer itself is created in another ARM application and not readily available for the current application context. Within the DSP process call each of the process copies out their relevant quadrants to work on them. The DSP process call also writes its processed buffer back into the corresponding quadrant of the display copy buffer before returning from the DSP. On the ARM side the display copy buffer is copied to the display buffer and sent to the device for display. We have put a signaling mechanism around the codec engine process calls on the ARM side for 4 codec engine + capture applications such that they execute in a serial manner (i.e. one starts only after the previous one has returned). This setup runs and seems to function as intended but hangs at intermittent times (sometime after 10+ hours). One of our suspicions is on the usage of the copy buffers (that are being used on both ARM and DSP side without being passed as either inBufs or outBufs). Please advise if such a usage is correct and if some sanity checks are possible. Alternative suggestions for usage are also welcome. Thanks Sriraja http://www.mindtree.com/email/disclaimer.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [Fwd: Re: how do I build the dvsdk to use the lastest git kernel?]
See below... Regards, - Rob -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Steve Chen Sent: Tuesday, November 03, 2009 4:53 AM To: Shlomo Kut Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [Fwd: Re: how do I build the dvsdk to use the lastest git kernel?] On Tue, 2009-11-03 at 09:35 +0200, Shlomo Kut wrote: Hi Kevin, I am trying to build the dvsdk against that latest git kernel linux-davinci-2.6.32-rc5 and I am having problems. I am using dvsdk_2_10_01_18. Is there a more up to date version of the dvsdk available? I append some of my build problems. Please can you help? regards Shlomo Kut CC[M] /home/shlomo/work/DaVinchi/dvsdk_2_10_01_18/linuxutils_2_24_02/package s/ti/sdo/linuxutils/cmem/src/module/cmemk.o /home/shlomo/work/DaVinchi/dvsdk_2_10_01_18/linuxutils_2_24_02/package s/ti/sdo/linuxutils/cmem/src/module/cmemk.c:53:2: warning: #warning *** not a warning *** Note: LINUX_VERSION_CODE = 2.6.26 /home/shlomo/work/DaVinchi/dvsdk_2_10_01_18/linuxutils_2_24_02 /packages/ti/sdo/linuxutils/cmem/src/module/cmemk.c: In function 'set_cached': /home/shlomo/work/DaVinchi/dvsdk_2_10_01_18/linuxutils_2_24_02/package s/ti/sdo/linuxutils/cmem/src/module/cmemk.c:1086: error: 'L_PTE_CACHEABLE' undeclared (first use in this function) /home/shlomo/work/DaVinchi/dvsdk_2_10_01_18/linuxutils_2_24_02/package s/ti/sdo/linuxutils/cmem/src/module/cmemk.c:1086: error: (Each undeclared identifier is reported only once /home/shlomo/work/DaVinchi/dvsdk_2_10_01_18/linuxutils_2_24_02/package s/ti/sdo/linuxutils/cmem/src/module/cmemk.c:1086: error: for each function it appears in.) /home/shlomo/work/DaVinchi/dvsdk_2_10_01_18/linuxutils_2_24_02/package s/ti/sdo/linuxutils/cmem/src/module/cmemk.c:1086: error: 'L_PTE_BUFFERABLE' undeclared (first use in this function) Are you building cmem against the davinci git kernel? According to the warning message, it may not work. Since the git kernel is 2.6.32, but cmem needs kernel version 2.6.26. The about-to-be-released LinuxUtils 2.25 has a fix for this. If you like you can just edit your current release, changing the following line vma-vm_page_prot = __pgprot(pgprot_val(vma-vm_page_prot) | (L_PTE_CACHEABLE | L_PTE_BUFFERABLE) ); with vma-vm_page_prot = __pgprot(pgprot_val(vma-vm_page_prot) | (L_PTE_MT_WRITETHROUGH | L_PTE_MT_BUFFERABLE) ); CC[M] /home/shlomo/work/DaVinchi/dvsdk_2_10_01_18/dm365mm/module/dm365mmap.o /home/shlomo/work/DaVinchi/dvsdk_2_10_01_18/dm365mm/module/dm365mmap.c :29:27: error: asm-arm/memory.h: No such file or directory I believe I've seen this error when I use a kernel source base that hasn't been built. Performing the 'make xxx_config' and 'make uImage' phases might fix this. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Failed to run dsplink sample
See below... Regards, - Rob -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of ??? Sent: Sunday, November 01, 2009 9:35 PM To: Richard Williams Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: Failed to run dsplink sample BTW: When I executed the loadmodules.sh on DM6446. I got the message like this : == r...@192.168.1.14:/opt/dvsdk/dm6446# ./loadmodules.sh CMEMK Error: CMEM phys_start (0x8760) overlaps kernel (0x8000 - 0x8780) insmod: error inserting 'cmemk.ko': -1 Invalid parameters dsplinkk: no version for struct_module found: kernel tainted. DSPLINK Module (1.61.03) created on Date: Apr 16 2009 Time: 18:22:23 == It seems that CMEM module is loaded to the wrong position, but if I change the starting address of load CMEM module to the address 0x8780, it still does not work. Here is the message : == ioremap_nocache(0x8780, 8388608)=0xc900 CMEMK Error: Failed to find a big enough free block CMEMK Error: alloc_pool failed to get contiguous area of size 1245184 CMEMK Error: Failed to alloc pool of size 1244160 and number of buffers 2 insmod: error inserting 'cmemk.ko': -1 Cannot allocate memory == Since I don't know your CMEM insmod parameters I can't say for sure, but the above message indicates that you don't have enough phys memory granted to CMEM to satisfy your pool geometry. You can either: - change the u-boot 'bootargs' parameter mem=120M to mem=118M, which will avoid the overlaps w/ kernel messages since the kernel will then end at 0x8760. - change your CMEM insmod params geometry to fit the 8 MB given to CMEM when you specify phys_start=0x8780. When doing so, realize that each buffer gets rounded up to the nearest 0x1000 in size. and what is the meaning of the message dsplinkk: no version for struct_module found: kernel tainted.. Is there something wrong with my dsplink module? Thanks, Wei-Ting 2009/11/2 Richard Williams rkw...@lewiscounty.com: richard, Most packages that I have seen end in .deb or something similar, rather than .bin. Where did you find the .bin archive packages? BTW: according to the data you supplied, the first indication of a problem is in the DRV_initialize function at line 238. To me, this means the function failed to initialize a device. Is your development system DM6446 connected to the computer? Is your setup correctly identifying the 6446 DSP? Is your connection to the PC from the DM6446 correctly identified in the setup? R. Williams -- Original Message --- From: ©P«Â§Ê richard925...@gmail.com To: davinci-linux-open-source@linux.davincidsp.com Sent: Sun, 1 Nov 2009 20:10:13 +0800 Subject: Failed to run dsplink sample Hi all, I am trying to run the dsplink sample program (loop) on DM6446 platform. I followed the steps from TMS320DM6446 DVEVM v2.0 Getting Started Guide, but it seemed something wrong. I haven't found anything useful to solve the problem. Could anyone help me to solve this problem? My development environment : Ubuntu 9.04 Here is the package I used : * bios_setuplinux_5_33_03.bin * dvsdk_setuplinux_2_00_00_22.bin (include dsplink-1_61_03-prebuilt package) * TI-C6x-CGT-v6.0.21.1.bin * mvl_5_0_0801921_demo_sys_setuplinux.bin * mvl_5_0_0_demo_lsp_setuplinux_02_00_00_140.bin This is the message I got : r...@192.168.1.14:/opt/test# ./loopgpp /opt/test/loop.out 1024 1000 0 === Sample Application : LOOP == Executing sample for DSP processor Id 0 Entered LOOP_Create () Entered PROC_setup () linkCfg [0x0] Entered DRV_Initialize () drvObj [0x2fad0] arg [0x0] Leaving DRV_Initialize () status [0x80008008] Failure: Status:[0x80008008] File:[0x200] Line:[238] Leaving PROC_setup () status [0x80008008] PROC_setup failed. Status = [0x80008008] Leaving LOOP_Create () Entered LOOP_Delete () Entered CHNL_freeBuffer () procId [0x0] chnlId [0x0] bufArray [0x2f718] numBufs [0x1] Entered DRV_Invoke () drvObj [0x0] cmdId [0x6d06] arg1 [0xbe8e3c14] arg2 [0x0] Leaving DRV_Invoke () status [0x80008002] Failure: Status:[0x80008002] File:[0x201] Line:[300] Leaving CHNL_freeBuffer () status [0x80008002] CHNL_freeBuffer () failed (output). Status = [0x80008002] Entered CHNL_delete () procId [0x0] chnlId [0x1] Entered
RE: Codec Engine Algorithm Create
A compilation of source code does not require any libraries, just header files. Libraries are used only by a linker, usually for linking the final app. You could pre-link your library of algorithms with the other libraries by doing a partial link, which would bring the needed library code into your library. Or, you could just require the final application builder to obtain/install the other libraries and link with them. - Rob From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On Behalf Of Magic Lin Sent: Wednesday, October 21, 2009 2:37 AM To: davinci-linux-open-source Subject: Codec Engine Algorithm Create I want to compile a library of algorithms that providing for Codec Server in the linux environment. However, the compilation of this library need to use other libraries. How can I build passed? 2009-10-21 北京闻亭泰科技术发展有限公司 姓名：林法宝 Email:li...@dspchina.com 地址:北京市海淀区上地三街9号嘉华大厦B811 网址: www.wintechdigital.com.cnhttp://www.wintechdigital.com.cn/ ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: CMEM in DM6467
That output is normal. CMEM is just showing what it did. If you need more info about your failure try setting CE_DEBUG=1|2|3, the higher the number the more output you get. - Rob From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of kirthika varadarajan Sent: Monday, October 19, 2009 8:47 AM To: Davinci-linux-open-source@linux.davincidsp.com Subject: CMEM in DM6467 Hi all, When i run ./loadmodules.sh I am getting this. ioremap_nocache(0x8780, 69206016)=0xc818 allocated heap buffer 0xc818 of size 0x821000 cmem initialized 5 pools between 0x8780 and 0x8ba0 DSPLINK Module (1.50) created on Date: Jan 3 2008 Time: 13:16:55 When i run the decode demo given with DM6467 i am not getting composite display output I never see such kind of output earlier. Suggest me to resolve this ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: CMEMK Error
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of david.kond...@legrandna.com Sent: Thursday, October 08, 2009 7:47 AM To: jaya.krish...@samsung.com Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: CMEMK Error Jaya krishnan wrote: Hi Thanks for the mail No such errors. Could this be related to the shell? It happened after I changed the Busybox. Yes, that happened to us also... the busybox insmod is *very* picky. Try using the full path to the module with the same parameters you listed.. \ I.E: insmod /full_path_to/cmemk.ko \ phys_start=0x8500 phys_end=0x8aa0 pools=5x4697152,64x718848 I'll blame the busybox sh, since I've had bad experience with it, and because your original email showed something strange: cmemk: Unknown parameter `phys_start' Note the double quote before phys_start, it's inside the single quotes, which tells me that's what insmod is getting. Regards, - Rob___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Initializing ramdisk
Hi Folks, A colleague is trying to increase the size of his ramdisk from 16MB to 24MB, and one of the steps he's taken is to increase the size for 'initrd' in bootargs: bootargs=console=ttyS0,115200n8 root=/dev/ram initrd=0x8090,24M init=/bin/ash lpj=5000 mem=80M bootcmd=bootm 0x8070 When doing so he gets the following error output: RAMDISK: ext2 filesystem found at block 0 RAMDISK: image too big! (24576KiB/16384KiB) RAMDISK: image too big! (24576KiB/16384KiB) List of all partitions: List of all partitions: No filesystem could mount root, tried: No filesystem could mount root, tried: ext3 ext3 ext2 ext2 vfat vfat msdos msdos Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) It seems the kernel still thinks the ramdisk is 16MB and doesn't like being asked to initialize more than that (24MB). Is there some other u-boot setting that needs to be done? Thanks Regards, - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] DaVinci: EDMA: New API edma_free_resource
Thanks for considering this API. It's the embedded programmer in me that's always trying to consolidate code at as low a level as possible. Perhaps a better name would be edma_free_channel_or_slot(), so it matches up with the allocation API naming, but it would just be a helper function that existed along with edma_free_channel() and edma_free_slot(). My request was certainly a selfish one, but since it would improve my EDMA driver code I thought it could do the same for others. I suppose the LinuxUtils EDMA driver is a unique client of the EDMA APIs, in that it is a resource manager and doesn't actually call any of the functional EDMA APIs (the ones that drive the EDMA HW), and from that perspective slots and channels are just different parts of the same resource space, so I'm not really representative of the typical EDMA API client. Regards, - Rob -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, September 16, 2009 8:43 AM To: Tivy, Robert Cc: Nori, Sekhar; Paulraj, Sandeep; davinci-linux-open-source@linux.davincidsp.com Subject: Re: [PATCH] DaVinci: EDMA: New API edma_free_resource Tivy, Robert rt...@ti.com writes: Since I was the one to ask Sandeep for this API, I will offer up my reasoning... Without this API, in order to call either edma_free_slot() or edma_free_channel() the LinuxUtils EDMAK device driver will have to carry a slot-vs-channel flag or cookie around with the EDMA allocation record. Then we need to consult this flag and call one or the other free. Other drivers will be doing this as well. This sounds pretty normal to me, and expected. Having this API will simplify code that allocates both slots and channels. It seems prudent to consolidate the decision making to one place (edma_free_resource()) instead of having it be sprinkled throughout the calling code, and also removes the possibility of the driver calling the wrong one. I agree with Sekhar that a free_resource() without a corresponding alloc_resource() doesn't make sense and is more confusing. Kevin Regards, - Rob -Original Message- From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincids p.com [mailto:davinci-linux-open-source- bounces+rtivy=ti@linux.davincidsp.com] On Behalf Of Nori, Sekhar Sent: Saturday, September 12, 2009 9:27 PM To: Paulraj, Sandeep Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: [PATCH] DaVinci: EDMA: New API edma_free_resource Hi Sandeep, On Sat, Sep 12, 2009 at 21:50:44, Paulraj, Sandeep wrote: From: Sandeep Paulraj s-paul...@ti.com This API is very similar to the edma_free_slot and edma_free_channel APIs. It is actually a consolidated version of these 2 APIs. A resource can be a channel or a slot. Using this API, the EDMA driver code makes the determination to free up a channel or a slot. The user does not have to decide the correct free API from among edma_free_channel or edma_free_slot. This API will be used by TI codecs and the DVSDK. Hmm, wonder how it improves convenience considering that channels and slots are allocated separately. Presumably, user will need to maintain separate cookies for channels and slots. IMHO, in the absence of an alloc_resource() API, this sounds incongruous. [...] +/** + * edma_free_resource - deallocate DMA parameter RAM channel/resource + * @resource: Either a channel or a slot to be freed + * + * This deallocates the DMA channel and associated parameter RAM slot + * if the resource happens to be a channel, i.e if the resource +number is + * less than 64 for DaVinci SOCs and less than 32 for Primus. ^^^ I think you mean to say DA8XX/OMAP-L1 Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-sourc e ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] DaVinci: EDMA: New API edma_free_resource
Thanks Dave, understood. See my reply to Kevin that I just sent, it explains that the LinuxUtils EDMA driver is probably unlike other drivers, in that it doesn't actually use any of the functional EDMA APIs, hence can treat slots and channels equivalently once they're allocated. Regards, - Rob -Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Wednesday, September 16, 2009 1:49 PM To: davinci-linux-open-source@linux.davincidsp.com Cc: Tivy, Robert; Nori, Sekhar; Paulraj, Sandeep Subject: Re: [PATCH] DaVinci: EDMA: New API edma_free_resource On Monday 14 September 2009, Tivy, Robert wrote: Without this API, in order to call either edma_free_slot() or edma_free_channel() the LinuxUtils EDMAK device driver will have to carry a slot-vs-channel flag or cookie around with the EDMA allocation record. It already needs one of those though doesn't it? You can't use a slot to trigger a DMA transfer (keyed on an event, manually, or by chaining). Unless it's been set up as a QDMA channel... which and thus needs even more special handling during deallocation. The reason there'is no edma_alloc_resource() is that there really are two very distinct resource types, which need distinct treatment almost everywhere. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] DaVinci: EDMA: New API edma_free_resource
Since I was the one to ask Sandeep for this API, I will offer up my reasoning... Without this API, in order to call either edma_free_slot() or edma_free_channel() the LinuxUtils EDMAK device driver will have to carry a slot-vs-channel flag or cookie around with the EDMA allocation record. Then we need to consult this flag and call one or the other free. Other drivers will be doing this as well. Having this API will simplify code that allocates both slots and channels. It seems prudent to consolidate the decision making to one place (edma_free_resource()) instead of having it be sprinkled throughout the calling code, and also removes the possibility of the driver calling the wrong one. Regards, - Rob -Original Message- From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincids p.com [mailto:davinci-linux-open-source- bounces+rtivy=ti@linux.davincidsp.com] On Behalf Of Nori, Sekhar Sent: Saturday, September 12, 2009 9:27 PM To: Paulraj, Sandeep Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: [PATCH] DaVinci: EDMA: New API edma_free_resource Hi Sandeep, On Sat, Sep 12, 2009 at 21:50:44, Paulraj, Sandeep wrote: From: Sandeep Paulraj s-paul...@ti.com This API is very similar to the edma_free_slot and edma_free_channel APIs. It is actually a consolidated version of these 2 APIs. A resource can be a channel or a slot. Using this API, the EDMA driver code makes the determination to free up a channel or a slot. The user does not have to decide the correct free API from among edma_free_channel or edma_free_slot. This API will be used by TI codecs and the DVSDK. Hmm, wonder how it improves convenience considering that channels and slots are allocated separately. Presumably, user will need to maintain separate cookies for channels and slots. IMHO, in the absence of an alloc_resource() API, this sounds incongruous. [...] +/** + * edma_free_resource - deallocate DMA parameter RAM channel/resource + * @resource: Either a channel or a slot to be freed + * + * This deallocates the DMA channel and associated parameter RAM slot + * if the resource happens to be a channel, i.e if the resource +number is + * less than 64 for DaVinci SOCs and less than 32 for Primus. ^^^ I think you mean to say DA8XX/OMAP-L1 Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Problem with the current EDMA driver in the DaVinci GIT kernel
Does anyone have any feedback/thoughts on my suggestion below? We at TI need to know, and hopefully have some say in, the availability of EDMA channel allocations. Regards, - Rob -Original Message- From: Tivy, Robert Sent: Wednesday, August 26, 2009 8:25 PM To: David Brownell; Paulraj, Sandeep Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: Problem with the current EDMA driver in the DaVinci GIT kernel It seems that arriving at a consensus for reserved channels isn't going to be easy. I'd like to suggest a scheme involving some sort of driver-controlled unlocking of reserved channels, intended to be used late in the EDMA acquisition timeline. The LinuxUtils EDMA driver has a strong need for EDMA_ANY type of allocation, to support memory-to-memory transfers by codecs, mostly. It could call a kernel API when it's first open()'ed, that tells the EDMA driver to transfer all unallocated reserved channels over to the EDMA_ANY bitmask. Most EDMA allocations will have already happened at that point, and even if more fixed-channel request are coming, there's more than a small chance that it will still be available (not picked for an EDMA_ANY request). There could be a priority to the EDMA_ANY acquisition, whereby certain reserved channels are deemed to be more or less likely to be requested later on, affecting how soon a channel is chosen for EDMA_ANY. There could also be an API for a driver to request that a certain channel not be allowed to be transferred to the EDMA_ANY list, or some sort of a notification of future usage. It would be nice to also solve the issue of raw EDMA usage through mmap()'ing the EDMA register set and directly writing registers. Perhaps the /dev/mem driver can intercept these requests and somehow negotiate or control access to those registers (I'm just tossing this out there with not much idea of how to solve it). Regards, - Rob From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincids p.com [davinci-linux-open-source-bounces+rtivy=ti@linux.davincid sp.com] On Behalf Of David Brownell [davi...@pacbell.net] Sent: Wednesday, August 26, 2009 12:00 PM To: Paulraj, Sandeep Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: Problem with the current EDMA driver in the DaVinci GIT kernel On Wednesday 26 August 2009, Paulraj, Sandeep wrote: What's unclear is just why you chose those numbers. I suspect the issue is that you just want to avoid channels which are (a) used by Linux drivers, and (b) the board uses the relevant driver. [Sandeep] yes Suggesting a name like EDMA_CHANNEL_HW_UNUSED. [Sandeep] I don't think this is needed Maybe not. If all devices associated with DMA drivers can be relied on to (i) register by a certain point in the init sequence, and (ii) properly list the DMA channels they use in their platform resources, then it's obviously possible to construct a set of all DMA channels potentially in use by drivers on that particular board. [Sandeep] this can also be achieved by updating the structure appropriately as I have done in the patches whose links I had given earlier No; that's not maintainable. Each time a new driver starts to use a channel, someone has to remember to update that table. That's why it's just a hack. People WILL forget to update that stuff, and then things WILL break. Plus, notice that your static updates won't accomodate board-specific differences either ... like a board not using one peripheral, and thereby making its DMA channels available for other use. And the list of channels available for use with software triggering, or chaining, or whatever this LinuxUtils thing is ... would be the inverse of that set. At that point in the init sequence -- and before drivers are expected to make CHANNEL_whatever allocations -- feed the set of free channels to the EDMA infrastructure. IMCOP and similar codec drivers would of course need to claim the channels they need; same deal. [Sandeep] how the IMCOP deals with its channels is handled by other components of the DVSDK. I am not sure of how exactly it is handled and I don't even know if the IMCOP actually used hardware triggering. If those components don't say that they use those DMA channels, then something other than IMCOP will be able to allocate them... trouble. So you'd better *find out* how it allocates those resources, if you're trying to redefine the semantics of the mechanism you identified. Or at least, you need to make sure they use the right allocation scheme. That would maximize the number of channels available for dynamic use by triggering and chaining. [Sandeep] basically the objective is to atleast allow all channels
RE: Problem with the current EDMA driver in the DaVinci GIT kernel
Thanks for the reply, please see below... Regards, - Rob -Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Friday, August 28, 2009 2:37 PM On Friday 28 August 2009, Tivy, Robert wrote: I'd like to suggest a scheme involving some sort of driver-controlled unlocking of reserved channels, intended to be used late in the EDMA acquisition timeline. I think the suggestion I made was a lot simpler, and less error prone. The very *notion* of locking/unlocking things is asking for trouble. Why expose such a concept when it's clearly not needed? Perhaps locking/unlocking was a poor choice of terminology, but essentially my scheme is the same as your's - transfer a set of unused channels to the free list late in the game, after you already have a good idea of specific need. I was just trying to avoid implementation-specific terminology, whereby the current implementation uses wording for the bitmasks such as reserved and no_event. Before exploring different solutions ... how about giving my previous suggestion a fair shake first?? Sure, and to be honest, I didn't much notice your original suggestion, it got buried at the end of a back-and-forth discussion about what should go in the static bitmasks, and at that point I was thinking your suggestion was more static in nature. In no way did I intend to supercede your suggestion. A simple implementation would be just scanning all the platform devices at some point (say, the first EDMA_ANY allocation) to construct that mask of potentially used on this board EDMA channels ... making the rest available for EDMA_ANY usage. Completely transparent to callers, and no need for SOC-specific hackery. That sounds good, better than having a driver trigger this action explicitly (as per my original suggestion). And a fairly trivial thing to implement too ... just a driver model call to walk the platform_bus devices, then an array iteration to find the DMA resources. Is this something that can be implemented today, with the current driver model, or would it need some new information to be added to every DMA-using driver? (sorry for asking you to educate me, but I'm just not that familiar with all the driver specifics) The LinuxUtils EDMA driver has a strong need for EDMA_ANY type of allocation, to support memory-to-memory transfers by codecs, mostly. My suggestion made many such channels available. Great. BTW, I've been told that future codecs would want on the order of 50 EDMA_ANY-type channels. - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Problem with the current EDMA driver in the DaVinci GIT kernel
-Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Friday, August 28, 2009 3:27 PM On Friday 28 August 2009, Tivy, Robert wrote: Great. BTW, I've been told that future codecs would want on the order of 50 EDMA_ANY-type channels. Sounds a bit excessive; like they needlessly refuse to share those resources! But if that's on hardware with channels to burn, so be it. - Dave Below is a codec DMA needs FAQ that a TI codec programmer supplied me. Regards, - Rob 1. Why does codec need so many EDMA channels ? Ans: DM365 HDVICP architecture needs data to be transferred from one buffer to another for its encode/decode operation. The src/destination can be DDR, ARM TCM or HDVICP/VICP internal buffers. EDMA is used for doing these data transfers. The nature of the HDVICP architecture requires multiple transfers to happen in parallel which mandates need to as many as 36 channels. Going forward in future codec release, there are further optimization planned which will require even more channels. Viz, in DM375, codecs plan to use as many as 50 channels. 2 Can there be any other alternative to do memory transfer? Ans: CPU copy is very slow and needs CPU intervention. EDMA is the only option available. 3. If codec blocks so many channels, can it effect application use case ? Ans: DM365/DM375 is planned for wide variety of application. Hence it has got so many peripherals and EDMA events associated. In a given use case/application, all the EDMA events does not get used. Hence ample EDMA channels are available for other use. For example, in a video record application, audio will need 1 edma event, SPI may need 1/2, SDCRD may need 1. Out of 64, almost 60 channels would be free. 4. Why does codec need EDMA_ANY channel support? Ans: Codec needs EDMA ch only for internal memory transfer. It always operate in manual sync mode(writing to ESR bits), the transfers are not really related to events. Hence codec does not want to ask specifically for any EDMA channels. LSP is free to give any channel which is free at that point of time. This arrangements gives lot of flexibility to the application design. Imagine a situation if codec asks specific EDMA channels, there is a good probability that it will block an EDMA channel which could be needed by some driver. In case it doesn't block, it is impossible for the codec to predict which are the free channels available at the time to its creation. On the other hand, if codec uses EDMA_ANY, then LSP can give any free channel available at that time. Application has to just ensure that it asks the edma channel for the drivers before creating the codec instance. 5. What is the market demand for codecs ? Ans: DM365 is basically a media processor chip. Hence Codec is the primary use case. BU/ marketing will have the exact answer of how much % of the chips gets used for video related application. I feel it would be majority of the %. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Problem with the current EDMA driver in the DaVinci GIT kernel
It seems that arriving at a consensus for reserved channels isn't going to be easy. I'd like to suggest a scheme involving some sort of driver-controlled unlocking of reserved channels, intended to be used late in the EDMA acquisition timeline. The LinuxUtils EDMA driver has a strong need for EDMA_ANY type of allocation, to support memory-to-memory transfers by codecs, mostly. It could call a kernel API when it's first open()'ed, that tells the EDMA driver to transfer all unallocated reserved channels over to the EDMA_ANY bitmask. Most EDMA allocations will have already happened at that point, and even if more fixed-channel request are coming, there's more than a small chance that it will still be available (not picked for an EDMA_ANY request). There could be a priority to the EDMA_ANY acquisition, whereby certain reserved channels are deemed to be more or less likely to be requested later on, affecting how soon a channel is chosen for EDMA_ANY. There could also be an API for a driver to request that a certain channel not be allowed to be transferred to the EDMA_ANY list, or some sort of a notification of future usage. It would be nice to also solve the issue of raw EDMA usage through mmap()'ing the EDMA register set and directly writing registers. Perhaps the /dev/mem driver can intercept these requests and somehow negotiate or control access to those registers (I'm just tossing this out there with not much idea of how to solve it). Regards, - Rob From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com [davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On Behalf Of David Brownell [davi...@pacbell.net] Sent: Wednesday, August 26, 2009 12:00 PM To: Paulraj, Sandeep Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: Problem with the current EDMA driver in the DaVinci GIT kernel On Wednesday 26 August 2009, Paulraj, Sandeep wrote: What's unclear is just why you chose those numbers. I suspect the issue is that you just want to avoid channels which are (a) used by Linux drivers, and (b) the board uses the relevant driver. [Sandeep] yes Suggesting a name like EDMA_CHANNEL_HW_UNUSED. [Sandeep] I don't think this is needed Maybe not. If all devices associated with DMA drivers can be relied on to (i) register by a certain point in the init sequence, and (ii) properly list the DMA channels they use in their platform resources, then it's obviously possible to construct a set of all DMA channels potentially in use by drivers on that particular board. [Sandeep] this can also be achieved by updating the structure appropriately as I have done in the patches whose links I had given earlier No; that's not maintainable. Each time a new driver starts to use a channel, someone has to remember to update that table. That's why it's just a hack. People WILL forget to update that stuff, and then things WILL break. Plus, notice that your static updates won't accomodate board-specific differences either ... like a board not using one peripheral, and thereby making its DMA channels available for other use. And the list of channels available for use with software triggering, or chaining, or whatever this LinuxUtils thing is ... would be the inverse of that set. At that point in the init sequence -- and before drivers are expected to make CHANNEL_whatever allocations -- feed the set of free channels to the EDMA infrastructure. IMCOP and similar codec drivers would of course need to claim the channels they need; same deal. [Sandeep] how the IMCOP deals with its channels is handled by other components of the DVSDK. I am not sure of how exactly it is handled and I don't even know if the IMCOP actually used hardware triggering. If those components don't say that they use those DMA channels, then something other than IMCOP will be able to allocate them... trouble. So you'd better *find out* how it allocates those resources, if you're trying to redefine the semantics of the mechanism you identified. Or at least, you need to make sure they use the right allocation scheme. That would maximize the number of channels available for dynamic use by triggering and chaining. [Sandeep] basically the objective is to atleast allow all channels not being used by the kernel to be acquired by the linuxutils/DVSDK. How they then use these channels is the responsibility of these other components. If they want a channel they need to use the allocation calls. The how they use them is irrelevant ... but if as you said some of them (IMCOP etc) need *specific* channels, usually because they're hard-wired to some peripheral but maybe just because some firmware doesn't understand dynamic allocation, it's got to request those specific channels. The reason to use CHANNEL_ANY is because you don't have a requirement for a specific channel. - Dave
RE: Regarding increase in Sever Thread stack size
The limit is the amount of memory in the heap that you assign for stacks.
- Rob
From: Sandeep YEDIRE [mailto:sandee...@yahoo.co.in]
Sent: Monday, August 17, 2009 5:43 AM
To: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire
Subject: Re: Regarding increase in Sever Thread stack size
Thanks for your reply. I am looking for the same. Is there any max limit for
this segment?
Many Thanks,
Sandeep.Yedire
From: Tivy, Robert rt...@ti.com
To: Sandeep YEDIRE sandee...@yahoo.co.in;
davinci-linux-open-source@linux.davincidsp.com
davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire sande...@acmet.com
Sent: Saturday, 15 August, 2009 5:09:38 AM
Subject: RE: Regarding increase in Sever Thread stack size
Is this what you're looking for?:
var Server = xdc.useModule('ti.sdo.ce.Server');
Server.algs = [
{name: viddec_copy, mod: VIDDEC_COPY, threadAttrs: {
stackSize: 0x4096, stackMemId: 0, priority: Server.MINPRI + 2}, groupId
: 0,
},
{name: videnc_copy, mod: VIDENC_COPY, threadAttrs: {
stackMemId: 0, priority: Server.MINPRI + 2}, groupId : 0,
}
];
The max limit is dictated by your available memory for BIOS TSK stacks.
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Sandeep YEDIRE
Sent: Tuesday, August 11, 2009 10:34 PM
To: davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire
Subject: Regarding increase in Sever Thread stack size
Hello all,
is there anyway to increase server thread stack size for one particular codec?
What is max limit ?
Many Thanks,
Sandeep.Yedire
See the Web's breaking stories, chosen by people like you. Check out Yahoo!
Buzzhttp://in.rd.yahoo.com/tagline_buzz_1/*http://in.buzz.yahoo.com/.
Looking for local information? Find it on Yahoo!
Localhttp://in.rd.yahoo.com/tagline_local_1/*http://in.local.yahoo.com/
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Regarding increase in Sever Thread stack size
Is this what you're looking for?:
var Server = xdc.useModule('ti.sdo.ce.Server');
Server.algs = [
{name: viddec_copy, mod: VIDDEC_COPY, threadAttrs: {
stackSize: 0x4096, stackMemId: 0, priority: Server.MINPRI + 2}, groupId
: 0,
},
{name: videnc_copy, mod: VIDENC_COPY, threadAttrs: {
stackMemId: 0, priority: Server.MINPRI + 2}, groupId : 0,
}
];
The max limit is dictated by your available memory for BIOS TSK stacks.
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Sandeep YEDIRE
Sent: Tuesday, August 11, 2009 10:34 PM
To: davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire
Subject: Regarding increase in Sever Thread stack size
Hello all,
is there anyway to increase server thread stack size for one particular codec?
What is max limit ?
Many Thanks,
Sandeep.Yedire
See the Web's breaking stories, chosen by people like you. Check out Yahoo!
Buzzhttp://in.rd.yahoo.com/tagline_buzz_1/*http://in.buzz.yahoo.com/.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: cmem and init_mm
The next CMEM release (of which I don't know the plans) should have this fixed, we have been informed of the issue. For now, you can comment out or #if 0 the function that uses it, since that function is never called. - Rob TI, Santa Barbara -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Ramakrishnan Muthukrishnan Sent: Thursday, August 13, 2009 10:06 AM To: davinci-linux-open-source@linux.davincidsp.com; Anderberg, Niclas Subject: cmem and init_mm Hi, The current git davinci kernels (and other architectures) do not have the init_mm exported. CMEM is using this interface. Without reexporting this in the kernel, I am unable to load cmemk module. Is there any plan to rewrite the cmemk modules working around init_mm? regards -- Ramakrishnan ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Reg. two out buffers in encoding of DM6446
You must have a bug somewhere with respect to your buffer pointers. The
virtual addresses that CMEM is complaining about are not ones that would be
returned by Memory_contigAlloc on a Linux system. However, CMEM_getPhys() (the
user front end to the kernel support) is often used for more than just
CMEM-allocated buffers, so your pointer bug is not necessarily with the CMEM
buffer.
Can you enable CMEM debug and rerun? You can do so with
var cmem = xdc.useModule('ti.sdo.linuxutils.cmem.CMEM');
cmem.debug = true;
in your appname.cfg file. This should give you a better idea of where these
pointers are coming from. You could also enable the environment variable
CE_DEBUG, setting it to 2 or 3, to give you some trace of what's happening.
Regards,
- Rob
From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On
Behalf Of kirthika varadarajan
Sent: Monday, July 06, 2009 4:05 AM
To: Davinci-linux-open-source@linux.davincidsp.com
Subject: Reg. two out buffers in encoding of DM6446
Hi,
I want to read the motion vector in another buffer which i pass from
application.
Already i am allocating the memory using Memory_ContigAlloc()
XDAS_Int32 inBufSizeArray[1];
XDAS_Int8 OutPutBuffers[2];
OutPutBuffers[0] = outBuf;
OutPutBuffers[1] = MotionVecData;
XDAS_Int32 outBufSizeArray[2];
XDAS_Int32 status;
XDM_BufDesc inBufDesc;
XDM_BufDesc outBufDesc;
VIDENC_InArgs inArgs;
VIDENC_OutArgs outArgs;
inBufSizeArray[0] = inBufSize;
outBufSizeArray[0] = outBufMaxSize; //Encoded data
outBufSizeArray[1] = MotionVecSize; //Motion vector
inBufDesc.numBufs = 1;
inBufDesc.bufSizes = inBufSizeArray;
inBufDesc.bufs = (XDAS_Int8 **) inBuf;
outBufDesc.numBufs = 2;
outBufDesc.bufSizes = outBufSizeArray;
outBufDesc.bufs = OutPutBuffers;
inArgs.size = sizeof(VIDENC_InArgs);
outArgs.size= sizeof(VIDENC_OutArgs);
/* Encode video buffer */
status = VIDENC_process(hEncode,inBufDesc,outBufDesc,inArgs, outArgs);
if (status != VIDENC_EOK)
{
ERR(VIDENC_process() failed with a fatal error (%ld ext:
%#lx)\n,status, outArgs.extendedError);
return FAILURE;
}
*outBufSize = outArgs.bytesGenerated;
EncodedFrameType = outArgs.encodedFrameType;
return SUCCESS;
In the codec i am copying the data in two output buffers.
outBufs-bufs[0] -encoded data
outBufs-bufs[1] -Motion vec data.
When ever i call the encode_process()
I am getting the following error
Memory Allocated for Motion Vector
crop.c.left=0
crop.c.top=0
crop.c.width=640
Capturing 640x480 video (cropped to 640x480)
CMEMK Error: GETPHYS: Failed to convert virtual 0x0 to physical.
CMEMK Error: GETPHYS: Failed to convert virtual 0xa8bff to physical.
Jpeg Encode Error: VIDENC_process() failed with a fatal error (-2 ext: 0
Struck some where.
Suggest me.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: looking for h264 encoder examples
A general observation, since I don't know about the implementation...
You memset(video_params, 0, sizeof (IVIDENC1_Params)) and then explicitly
set some of them to real values, but what about the other possible members of
IVIDENC1_Params, which remain as 0?
Usually one would do something like:
video_params = default params;
video_params.encodingPreset = XDM_DEFAULT;
...
When you pass NULL (and it works), some default set gets used. You need to
find the identifier for this default set and use it where I put default
params above.
Regards,
- Rob
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com
] On Behalf Of Ottavio Campana
Sent: Monday, June 22, 2009 1:36 AM
To: Davinci-linux-open-source@linux.davincidsp.com
Subject: looking for h264 encoder examples
Hi,
I'm having some problems with the h264 encoder on a dm6446.
If I call
video_enc = VIDENC1_create (ce, h264enc, NULL);
it creates the encoder, but if I call
memset (video_params, 0, sizeof (IVIDENC1_Params));
video_params.size = sizeof(IVIDENC1_Params);
video_params.encodingPreset = XDM_DEFAULT;
video_params.rateControlPreset = IVIDEO_LOW_DELAY;
video_params.dataEndianness = XDM_BYTE;
video_params.maxInterFrameInterval = 1;
video_params.inputContentType = IVIDEO_PROGRESSIVE;
video_params.reconChromaFormat = XDM_YUV_422ILE;
video_enc = VIDENC1_create (ce, h264enc, video_params);
I get the following error and I think it should be a
configuration error, but I cannot understand what it is.
So I am looking for some examples to use as trace to
implement my h264 encoder. Where can I find them?
Ottavio.
@0,542,540us: [+0 T:0x4001eb80] CE - Engine_fwriteTrace
returning count [7152]
@0,542,713us: [+0 T:0x4001eb80] CE - Engine_open return(322888)
@0,542,965us: [+0 T:0x4001eb80] ti.sdo.ce.video1.VIDENC1 -
VIDENC1_create Enter (engine=0x4ed48, name='h264enc', params=0x43574)
@0,543,202us: [+0 T:0x4001eb80] CV - VISA_create(0x4ed48,
'h264enc', 0x43574, 0x2496, 'ti.sdo.ce.video1.IVIDENC1')
@0,543,371us: [+0 T:0x4001eb80] CV - VISA_create2(0x4ed48,
'h264enc', 0x43574, 0x30, 0x2496, 'ti.sdo.ce.video1.IVIDENC1')
@0,543,553us: [+0 T:0x4001eb80] CE -
Engine_createNode(0x4ed48, 'h264enc', 2496, 0x43574, 0x30, 0xbedc5adc)
@0,543,716us: [+0 T:0x4001eb80] CE - Engine allocNode
Enter(engine=0x4ed48, impId='h264enc')
@0,543,894us: [+0 T:0x4001eb80] CE - Engine allocNode().
Calling Comm_create(gppfromnode_1738_1, 0x4c588, NULL)
@0,547,482us: [+6 T:0x4001eb80] CE - Engine_createNode
Remote node creation FAILED (0x80008008).
[DSP] @0,110,429tk: [+0 T:0x8fa424cc] OM - Memory_alloc
Enter(size=0x18) [DSP] @0,110,477tk: [+0 T:0x8fa424cc] OM -
Memory_alloc return (0x8fa46f88) [DSP] @0,110,526tk: [+0
T:0x8fa424cc] OM - Memory_alloc Enter(size=0xa) [DSP]
@0,110,571tk: [+0 T:0x8fa424cc] OM - Memory_alloc return
(0x8fa46fa0) [DSP] @0,110,626tk: [+0 T:0x8fa424cc] OM -
Memory_alloc Enter(size=0x20) [DSP] @0,110,671tk: [+0
T:0x8fa424cc] OM - Memory_alloc return (0x8fa46fb0) [DSP]
@0,110,721tk: [+0 T:0x8fa424cc] OM - Memory_alloc
Enter(size=0x24) [DSP] @0,110,766tk: [+0 T:0x8fa424cc] OM -
Memory_alloc return (0x8fa46fd0) [DSP] @0,110,835tk: [+0
T:0x8fa424cc] ti.sdo.ce.video1.VIDENC1 - VIDENC1_create
Enter (engine=0x0, name='h264enc', params=0x8fe05cc0) [DSP]
@0,110,924tk: [+0 T:0x8fa424cc] CV - VISA_create(0x0,
'h264enc', 0x8fe05cc0, 0x2496, 'ti.sdo.ce.video1.IVIDENC1')
[DSP] @0,111,001tk: [+0 T:0x8fa424cc] CV - VISA_create2(0x0,
'h264enc', 0x8fe05cc0, 0x30, 0x2496,
'ti.sdo.ce.video1.IVIDENC1') [DSP] @0,111,097tk: [+0
T:0x8fa424cc] CE - Engine_open Enter('local', 0x8fa461cc,
0x9c0) [DSP] @0,111,157tk: [+0 T:0x8fa424cc] OM -
Memory_alloc Enter(size=0x2c) [DSP] @0,111,207tk: [+0
T:0x8fa424cc] OM - Memory_alloc return (0x8fa47040) [DSP]
@0,111,264tk: [+0 T:0x8fa424cc] CE - Engine_open
return(-1885048768) [DSP] @0,111,328tk: [+0 T:0x8fa424cc] OM
- Memory_alloc Enter(size=0x30) [DSP] @0,111,373tk: [+0
T:0x8fa424cc] OM - Memory_alloc return (0x8fa47070) [DSP]
@0,111,427tk: [+0 T:0x8fa424cc] ti.sdo.ce.alg.Algorithm -
Algorithm_create Enter(fxns=0x8fac4fb8,
idma3Fxns=0x8fac4fe4, iresFxns=0x0, params=0x8fe05cc0,
attrs=0x8fa462e0) [DSP] @0,111,535tk: [+0 T:0x8fa424cc] OM -
Memory_alloc Enter(size=0x10) [DSP] @0,111,580tk: [+0
T:0x8fa424cc] OM - Memory_alloc return (0x8fa470a0) [DSP]
@0,111,947tk: [+7 T:0x8fa424cc] ti.sdo.ce.alg.Algorithm -
RE: CMEM usage in no codec oriented application
The CMEM module does not need to be loaded for the application link stage. If you get undefined reference to CMEM_init then that just means that you're not correctly referencing cmem.a in your link. Regards, - Rob From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Gopal Sukumar Sent: Thursday, June 11, 2009 1:54 AM To: Ondrej Pindroch Cc: davinci-linux-open-source Subject: Re: CMEM usage in no codec oriented application Hi Ondrej, This means linking cmem to your app has failed. Ensure that you have loaded the cmem module. Thanks, Gopal Sukumar. Ondrej Pindroch wrote: Hi How can I use CMEM and all it's API. In my application. I need to get one buffer with size almost 10MB, which will be continous in virtual and physical memory space. I have tried link cmem.a to my project but it told me undefined reference to CMEM_init and so on. Thanks for your answer Ondrej Pindroch SoftHard Technology ltd. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.commailto:Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source http://www.mindtree.com/email/disclaimer.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: EDMA with user provided virtual addresses.
TI's Codec Engine Linux Utils module CMEM can do what you want, but I don't know if it's even a possibility for you. EDMA requires physically contiguous buffers, so in addition to needing to know the physical address, you also must ensure that your buffers are contiguous physically, and CMEM provides both these services. Regards, - Rob -Original Message- From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincids p.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d avincidsp.com] On Behalf Of Andrea Gasparini Sent: Thursday, June 11, 2009 3:55 AM To: davinci-linux-open-source Subject: EDMA with user provided virtual addresses. Hi, I'm coding a module that takes from userspace an address pointer, and uses it to fill the memory with some EDMA process. My problem is that EDMA (fairly) wants a physical address: I usually use dma_map_single() to have returned a physical pointer to do this kind of stuff, but in this case, although, pointer are from user spaces, and so involves mmu. So, the question is: is there a way to use EDMA with (at least one) user space address? Can I know (and how) a physical address given the userspace one? If could make the answer easier: I'm not (ATM) using swap space at all, so pages are surely resident in memory. Thanks, bye! -- Andrea Gasparini ImaVis S.r.l. web: www.imavis.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: EDMA with user provided virtual addresses.
-Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Thursday, June 11, 2009 1:09 PM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; Andrea Gasparini Subject: Re: EDMA with user provided virtual addresses. On Thursday 11 June 2009, Tivy, Robert wrote: EDMA requires physically contiguous buffers, so in addition to needing to know the physical address, you also must ensure that your buffers are contiguous physically, Not really. The usual way to handle that sort of thing is to make whatever user-to-kernel mapping call you need, which returns something along the lines of a scatterlist. Then just construct a chain of DMA transfers, one for each segment. So a 12 Kbyte userspace buffer might scan three pages: page N+0 offset 1K, len 3K page N+1 offset 0, len 4K page N+2 offset 0, len 1K Map that to the kernel, and it'll still be three pages but the page addresses will differ ... say, pages X, Y, and Z. Offsets and lengths will be unchanged. Now just feed EDMA a chain of three transfers. That kind of logic is easy to wrap in utility functions. (If it were wrapped, would non-DSP code really need CMEM?) Good point, thanks for letting me know. So, the requirement for phys contig buffers is mostly for HW accelerators that address memory w/o the benefit of an MMU or without chaining capability. Having one contig buf for EDMA also makes things simpler to handle, but isn't necessary. CMEM can help in the non-DSP case for those HW accelerators. One last advantage of CMEM - ARM/DSP-based combo code can move over to ARM only without any porting, or using a different allocator. - Rob___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: EDMA with user provided virtual addresses.
-Original Message- From: David Brownell [mailto:davi...@pacbell.net] Sent: Thursday, June 11, 2009 3:18 PM To: Tivy, Robert Cc: davinci-linux-open-source@linux.davincidsp.com; Andrea Gasparini Subject: Re: EDMA with user provided virtual addresses. On Thursday 11 June 2009, Tivy, Robert wrote: That kind of logic is easy to wrap in utility functions. (If it were wrapped, would non-DSP code really need CMEM?) ... the requirement for phys contig buffers is mostly for HW accelerators that address memory w/o the benefit of an MMU or without chaining capability. (You mean ... *and* without chaining yes? If either tech is available, there is no hard requirement.) Yes, if the bus master has *neither* an MMU nor block-chaining, phys contig bufs are needed. For completeness: which accelerators are those? I'm not sure of the specifics of each one, but I was thinking of coprocessors such as IMX/VICP/HDVICP/MJCP/etc. I expect it might be quite painful to update DSP code to change assumptions like physically contiguous buffers, but on the flip side of things it seems like such changes should probably be assumed for all mainstream Linux code that's got to take buffers from userspace. Some codecs probably don't have a choice but to require phsyically contiguous buffers, if for no other reason than to guarantee stated performance, and to maximize throughput to allow as many instances as possible on a single system. But I'm not familiar with codecs, just heard through the grapevine. - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: CMEM and mmap'd buffers in 2.6.28rc6
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Ryan Talbot Sent: Tuesday, June 09, 2009 2:29 PM To: Vladimir Pantelic; davinci-linux-open-source@linux.davincidsp.com Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: CMEM and mmap'd buffers in 2.6.28rc6 Hi Vladimir, Ryan Talbot wrote: CMEM Error: getPhys: Failed to get physical address of 0x4015c000 CMEM Error: getPhys: Failed to get physical address of 0x40226fff Those addresses correspond to the virtual addresses of the first capture buffer, and the second capture buffer -1, respectively. Those were allocated via kzalloc(), which should yield physically contiguous memory, so we don't know what the problem would be. It was suggested by our codec vendor that the issue might be the CMEM pool configuration. We find this confusing since the capture buffers come from Linux memory, not the CMEM pools. CMEM merely does the virt-phys address translation to hand to the DSP in that case, right? Additionally, when recording from file and CMEM actually is in charge of allocating the input buffers, things work fine. It would seem, then, that CMEM is having trouble translating an address for memory that it didn't allocate. Yes, as seen by the above error. why don't you allocate the mem from CMEM? Well, it was my understanding that CMEM should be able to translate any virtual address to a physical address. These buffers are internally allocated by the vpfe_capture driver and mmap'd to user space. This was the way it worked in 2.6.10, anyhow. Furthermore, looking at the code for the CMEM module, it just uses get_user() and get_phys() system calls to do the translation, so it should not care who originally allocated the memory. Am I mistaken in this? Ryan Sometime after 2.6.10 the CMEM get_phys() function stopped working for kernel addresses. Kevin Hillman provided a new one to work with newer kernels (unverified), but I discovered that this new one didn't correctly translate non-direct-mapped kernel addresses, so I added code to CMEM to save the lower/upper bounds of the CMEM blocks' kernel addresses, and manually look for those in get_phys() before trying more general methods of translation. So, in short, CMEM's get_phys() doesn't handle non-direct-mapped kernel addresses except the ones that correspond to CMEM's managed memory block(s). Regards, - Rob ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: SRAM allocator(s!)
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Vladimir Pantelic Sent: Sunday, May 24, 2009 10:52 AM To: Troy Kisky Cc: Koen Kooi; davinci-linux-open-source@linux.davincidsp.com Subject: Re: SRAM allocator(s!) Troy Kisky wrote: Koen Kooi wrote: On 23-05-09 01:15, Ring, Chris wrote: New thread, as requested... I like Rob/David's suggestion of adding calls to request_mem_region()/release_mem_region() in each allocator (SRAM and CMEM) What's the plan for getting CMEM upstream? I've been asking that question to TI engineers for a while now and the only responses usually are That's a good idea! and We don't know if it will be accepted. It shouldn't be too hard to get it pushed into Greg KH's staging tree... regards, Koen My personal bias is against CMEM being in the kernel. I dislike pools of fixed size in an general purpose allocator. I think there are better ways to solve fragmentation problems. Actually, I do not understand why CMEM is always used with all these pools and not with one big heap, where any size chunks can be allocated from. I am using a CMEM compatible heap allocator with Davinci and OMAP3 for a couple of years now and fragmentation never was a problem. FYI, the insmod'er of CMEM can choose to have all pools and no heap, or all heap and no pools, or a mix of both. You may not experience fragmentation of the heap in your personal experience, but there is ample research that no heap-based allocator is immune to fragmentation issues, given the right (or wrong) set of allocation pattern. Having said that, CMEM is not really there to solve any fragmentation issue, it's there to provide physically-contiguous buffers of memory (original intent), and it has been exploited to allow user-mode programs access to general cache maintenance and virtual-to-physical translations of non-CMEM addresses. Regards, - Rob What I think should go into the kernel is a general (heap based) allocator that can supply DSP/DMA mem in large quantities, I agree it may not be CMEM with pools in the end. Regards, Vladimir ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 3/3] davinci: add SRAM allocator
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Kevin Hilman Sent: Friday, May 22, 2009 8:11 AM To: Ring, Chris Cc: davinci-linux-open-source@linux.davincidsp.com; David Brownell; linux-arm-ker...@lists.arm.linux.org.uk Subject: Re: [PATCH 3/3] davinci: add SRAM allocator Ring, Chris cr...@ti.com writes: Just a quick can we talk through this patch a bit note... I _think_ there are existing codecs on some DaVinci platforms (e.g. DM365) that are already using this SRAM memory. The current [easy] solution to their use case was to keep this memory out of the kernel, and simply give it to CMEM to manage (via its insmod params) and the codecs indirectly allocate from CMEM. Couldn't the CMEM driver just call sram_alloc() in this case? I suppose it could, in cases where sram_alloc() is defined for the particular Linux version. However, supporting SRAM w/ CMEM as it is today involves simply using the 2nd block instance that CMEM already supports, i.e., no additional code needed to differentiate between using CMEM's internal allocator or using sram_alloc(). I think the way codecs are going to request SRAM is by asking for all of it, which means that if the audio driver takes any of it through sram_alloc(), codecs won't have any. And if codecs take it all before the audio driver asks for it, the audio driver is out of luck. David Brownell suggested that it would be easy to add a request_mem_region() reservation call into the sram allocator. Regardless of whether or not CMEM uses sram_alloc(), I'd still like to see that. If you're unfamiliar with CMEM, there is an overview here: http://tiexpressdsp.com/index.php?title=CMEM_Overview I'm not the expert, I only want to encourage further discussion! But I'm a little concerned about a resource collision if this SRAM allocator gets pushed, and more than one client thinks they own that resource. I would argue that these potentical collisions are all the more reason to push an allocator which can be used to avoid collisions. I'd like to see CMEM's internal allocator go by the wayside as well, and one thing that would help that goal is to have an allocator that can handle all types of memory that CMEM handles. Today, those types that CMEM has been asked to handle are: - DDR that is not given to the Linux kernel (the large majority of the cases) - SRAM on OMAP3 - TCM on DM365 CMEM is just told a memory range. If we need to call a different allocator for each type, so be it, and CMEM would have to now be told the type of memory (just thinking out loud here). If we had a common allocator for all types above, CMEM would be that much cleaner. Would the slab allocator be at all appropriate here? Regards, - Rob Kevin -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Kevin Hilman Sent: Thursday, May 21, 2009 2:47 PM To: linux-arm-ker...@lists.arm.linux.org.uk Cc: davinci-linux-open-source@linux.davincidsp.com; David Brownell Subject: [PATCH 3/3] davinci: add SRAM allocator From: David Brownell dbrown...@users.sourceforge.net Provide a generic SRAM allocator using genalloc, and vaguely modeled after what AVR32 uses. This builds on top of the static CPU mapping set up in the previous patch, and returns DMA mappings as requested (if possible). Compared to its OMAP cousin, there's no current support for (currently non-existent) DaVinci power management code running in SRAM; and this has ways to deallocate, instead of being allocate-only. The initial user of this should probably be the audio code, because EDMA from DDR is subject to various dropouts on at least DM355 and DM6446 chips. Signed-off-by: David Brownell dbrown...@users.sourceforge.net Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/Kconfig |1 + arch/arm/mach-davinci/Makefile|2 +- arch/arm/mach-davinci/include/mach/sram.h | 27 ++ arch/arm/mach-davinci/sram.c | 74 + 4 files changed, 103 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-davinci/include/mach/sram.h create mode 100644 arch/arm/mach-davinci/sram.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e60ec54..ffa8427 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -586,6 +586,7 @@ config ARCH_DAVINCI select ZONE_DMA select HAVE_IDE select COMMON_CLKDEV + select GENERIC_ALLOCATOR help Support for TI's DaVinci platform. diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile index 5b62d8a..059ab78
RE: what I am missing here with DVEVM kit? How to solve this issue.
Or, you could reduce the memory to CMEM, increasing the phys_start address on the 'insmod' command in loadmodules_hd.sh. You can start it right at the end of the kernel memory. If the kernel goes up to 0x85c0, you can change to use phys_start=0x85c0 . Regards, - Rob -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Saran, Sajesh Kumar Sent: Tuesday, April 28, 2009 8:00 AM To: dengyz; davinci-linux-open-source@linux.davincidsp.com Subject: RE: what I am missing here with DVEVM kit? How to solve this issue. Try reducing the memory available to Linux kernel (in bootargs set to mem=80M or lower). Regards, Sajesh -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of dengyz Sent: Tuesday, April 28, 2009 5:48 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: what I am missing here with DVEVM kit? How to solve this issue. Hi : I test the TMX320DM365 for h264 encode/decode demo by TI TMX320DM365 DVEVM kit. Running the Demos from the Command Line: Target $ cd /opt/dvsdk/dm365 Target $ ./loadmodules_hd.sh A issue occur as follows: Target $ cmemk: no version for struct_module found: kernel tainted. CMEMK Error: CMEM phys_start (0x8500) overlaps kernel (0x8100 - 0x85c0) insmod: error inserting 'cmemk.ko': -1 Invalid parameters Can anybody please let me know, what I am missing here with DVEVM kit? How to solve this issue. Thanks! -- --- If A is success in life, then A equals x plus y plus z. Work is x; y is play; and z is keeping your mouth shut. Albert Einstein (1879 - 1955) - Original Message - From: davinci-linux-open-source-requ...@linux.davincidsp.com To: davinci-linux-open-source@linux.davincidsp.com Sent: Tuesday, April 28, 2009 10:39 AM Subject: Davinci-linux-open-source Digest, Vol 40, Issue 180 Send Davinci-linux-open-source mailing list submissions to davinci-linux-open-source@linux.davincidsp.com To subscribe or unsubscribe via the World Wide Web, visit http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source or, via email, send a message with subject or body 'help' to davinci-linux-open-source-requ...@linux.davincidsp.com You can reach the person managing the list at davinci-linux-open-source-ow...@linux.davincidsp.com When replying, please edit your Subject line so it is more specific than Re: Contents of Davinci-linux-open-source digest... Today's Topics: 1. Re: [PATCH 3/3 v4] ARM: da830 - Add support for DA830/OMAP-L137 EVM (Mark A. Greer) 2. RE: Problem about DSP server config of DM6446 (Tivy, Robert) 3. Re: when port a software , bus error (zhenfeng ren) 4. Re: THS8200 Module and DM6446EVM Initial Setup (Carl Renaud) 5. Re: is there any LCD Kits for DM355 DVEVM board (Carl Renaud) 6. RE: Changing Machine ID (Manjunatha AM) -- Message: 1 Date: Mon, 27 Apr 2009 14:28:42 -0700 From: Mark A. Greer mgr...@mvista.com Subject: Re: [PATCH 3/3 v4] ARM: da830 - Add support for DA830/OMAP-L137 EVM To: David Brownell davi...@pacbell.net Cc: davinci-linux-open-source@linux.davincidsp.com Message-ID: 20090427212842.ga19...@mag.az.mvista.com Content-Type: text/plain; charset=iso-8859-1 On Mon, Apr 27, 2009 at 12:49:54PM -0700, David Brownell wrote: On Monday 27 April 2009, Mark A. Greer wrote: --- a/arch/arm/mach-davinci/include/mach/debug-macro.S +++ b/arch/arm/mach-davinci/include/mach/debug-macro.S @@ -24,7 +24,14 @@ tst \rx, #1 @ MMU enabled? moveq \rx, #0x0100 @ physical base address movne \rx, #0xfe00 @ virtual base +#if defined(CONFIG_ARCH_DAVINCI_DA830_EVM) +defined(CONFIG_ARCH_DAVINCI_DMx) This should be 'CONFIG_MACH_DAVINCI_DA830_EVM'. You man it wouldn't be applicable to DA830 boards other than that EVM?? Maybe, maybe not. Same comment in a few other places. From what you've said, these are chip-specific issues, not board-specific ones... Well, there are lots of pinmux conflicts on the da830. For devices that aren't used all of the time, it makes sense to allow the driver and the resources it requires to come and go on demand--maybe even the console if there is a graphic console. Either way, what uart is used for the serial console is determined by the board not the chip. Mark -- -- Message: 2 Date: Mon, 27 Apr 2009 17:36:25 -0500 From: Tivy, Robert rt...@ti.com Subject: RE: Problem about DSP server config of DM6446 To: chensu.main chensu.m...@263.net, davinci-linux-open-source
RE: Problem about DSP server config of DM6446
I'm not sure about a document, but the number of algorithm objects that you can
create depends on the size of the memory block from which the stacks are
allocated. As you've seen, cutting the stack size down allows you to create
more. You might be able to find a formula, but the real answer is as many as
you have memory for.
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
chensu.main
Sent: Monday, April 27, 2009 8:03 AM
To: davinci-linux-open-source
Subject: Problem about DSP server config of DM6446
Hi all ,
In my application , I have to create one algorithm many times .
Fistly I config DSP server's CFG file and set stack size to 16384 in
Server.algs {} , but app can only create 7 instances of my algorithm . Then I
fix stack to 4096 and I can create more .
My question is How many algorithm objects can I create . Which document
describe it indetail ?
2009-04-27
chensu.main
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Codec Engine DSP_ETIMEOUT When loading DSP
I would suggest hooking up CCS and looking at what's going on with the DSP when
this happens. The DSP server needs to get to a handshake point with the ARM,
and it appears that the ARM is timing out after not receiving a response from
the DSP (error code DSP_EBASE + 0x17 is a timeout error).
Perhaps you need to use a different power control option in CE, or use the LPM
power manager from CE to turn on the DSP before running the ARM app.
Also, make sure you're using a recent CE/DSPLink combo that supports the 2.6.28
kernel.
- Rob
From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On
Behalf Of Jeremy Larsen
Sent: Friday, April 10, 2009 2:08 PM
To: davinci-linux-open-source
Subject: Codec Engine DSP_ETIMEOUT When loading DSP
I am using a DM6446 on a custom board and with a custom 2.6.28 Kernel and
trying to get Codec Engine working.
I have reconfigured the memory map for 64MB of RAM.
To change the memory map I have followed the directions found here
http://focus.ti.com/lit/an/spraaq6/spraaq6.pdf
I can succesfully run DSPLINK and CMEM examples.
When I try to run the video_copy (or any other) example in codec engine I get
the following:
@0x00046b00:[T:0x4001cf40] OG - Global_atexit enter (fxn=0xad74)
@0x00046ca4:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00046dfd:[T:0x4001cf40] OM - Memory_alloc return (0x43890)
@0x000474a1:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x1790c)
@0x000475e3:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x0004768b:[T:0x4001cf40] OM - Memory_alloc return (0x438e0)
@0x00047712:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x167b8)
@0x00047808:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x19040)
@0x00047918:[T:0x4001cf40] ti.sdo.ce.osal.Sem - Sem_create count: 0
@0x000479b0:[T:0x4001cf40] OM - Memory_alloc Enter(0x14)
@0x00047a36:[T:0x4001cf40] OM - Memory_alloc return (0x43960)
@0x00047ad8:[T:0x4001cf40] ti.sdo.ce.osal.Sem - Leaving Sem_create sem[0x43960]
@0x00047b61:[T:0x4001cf40] ti.sdo.ce.osal.Sem - Sem_create count: 0
@0x00047bd6:[T:0x4001cf40] OM - Memory_alloc Enter(0x14)
@0x00047c4f:[T:0x4001cf40] OM - Memory_alloc return (0x43978)
@0x00047cc5:[T:0x4001cf40] ti.sdo.ce.osal.Sem - Leaving Sem_create sem[0x43978]
@0x00047d37:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00047db1:[T:0x4001cf40] OM - Memory_alloc return (0x43990)
@0x00047e2b:[T:0x4001cf40] OT - Thread_create Enter (fxn=0x14f90, attrs=0x0)
@0x00047ea2:[T:0x4001cf40] OM - Memory_alloc Enter(0x64)
@0x00047f1f:[T:0x4001cf40] OM - Memory_alloc return (0x439b0)
@0x000482dd:[T:0x40960490] OP - daemon thread created.
@0x000483d3:[T:0x40960490] OP - getCmd_d Enter (proc=0x4095fde0)
@0x00048470:[T:0x40960490] ti.sdo.ce.osal.Sem - Entered Sem_pend sem[0x43960]
timeout[0x]
@0x00048568:[T:0x4001cf40] OT - Thread_create Exit (task=0x439b0)
@0x0004860e:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x14980)
@0x000486b2:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x16d04)
@0x000487a0:[T:0x4001cf40] ti.sdo.ce.alg - ALG_init Enter
@0x0004882f:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x145cc)
@0x000488b9:[T:0x4001cf40] ti.sdo.ce.alg - ALG_init Exit
@0x0004892c:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x139f8)
@0x000489bf:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00048a48:[T:0x4001cf40] OM - Memory_alloc return (0x43b90)
@0x00048acb:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x19530)
@0x00048bc8:[T:0x4001cf40] OG - Global_atexit enter (fxn=0x10e8c)
@0x00048c6a:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00048cf4:[T:0x4001cf40] OM - Memory_alloc return (0x43bf0)
@0x00048d7a:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00048dfb:[T:0x4001cf40] OM - Memory_alloc return (0x43c10)
@0x00048e75:[T:0x4001cf40] OM - Memory_alloc Enter(0x18)
@0x00048ef3:[T:0x4001cf40] OM - Memory_alloc return (0x43c30)
@0x00048fd2:[T:0x4001cf40] CS - Server_init()
@0x0004905a:[T:0x4001cf40] CS - Server_init Global_useLinkArbiter = 0
@0x000490dd:[T:0x4001cf40] OG - Global_atexit enter (fxn=0xf16c)
@0x000494bb:[T:0x4001cf40] OG - Global_atexit enter (fxn=0xcb90)
@0x000495e8:[T:0x4001cf40] CE - Engine_open Enter('video_copy', 0x0,
0xbecb8bf4)
@0x00049691:[T:0x4001cf40] OM - Memory_alloc Enter(0x2c)
@0x0004971f:[T:0x4001cf40] OM - Memory_alloc return (0x43cb0)
@0x000497a0:[T:0x4001cf40] CE - rserverOpen('video_copy.x64P'), count = 0
@0x00049821:[T:0x4001cf40] OP - Processor_create
Enter(imageName='video_copy.x64P', linkCfg='(null)', attrs=0xbecb8bd8)
@0x00049c98:[T:0x4001cf40] OM - Memory_alloc Enter(0x24)
@0x00049d67:[T:0x4001cf40] OM - Memory_alloc return (0x43ce0)
@0x00049dfb:[T:0x4001cf40] OP - doCmd Enter (cmdId=1, proc=0x43ce0)
@0x00049e83:[T:0x4001cf40] ti.sdo.ce.osal.Sem - Entered Sem_post sem[0x43960]
@0x00049f7b:[T:0x40960490] ti.sdo.ce.osal.Sem - Leaving Sem_pend sem[0x43960]
status[0]
@0x0004a038:[T:0x40960490] OP - getCmd_d Exit (result=1)
RE: migration to CE 2.10: DSP server linkage failure
-ml3 is legacy code/data model support. Before --mem_model: came along -ml? was used for specifying data and code models (where ? is 0-3). -mv6400+ specifies C64+ DSP architecture, as available on Davinci and other processors. Removing -ml3 should solve your problem. However, it might cause performance issues if you remove -mv6400+. This option, or one of the equivalent forms of it, needs to be present somewhere in your build options, since it tells the compiler to generate C64+ assembly code, instead of whatever the default is (the default will work, since C64+ supports running C62 or C64 assembly, but will prevent full entitlement to the advanced C64+ instruction set). But if you're using XDC platforms, and are specifying a Davinci platform, then this option should already be in place as part of the platform's build options, but you should check the end result of the compile command to find out what you're getting. Regards, - Rob From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Avishai Hendel Sent: Tuesday, March 31, 2009 6:16 AM To: Ring, Chris; davinci-linux-open-source@linux.davincidsp.com Subject: RE: migration to CE 2.10: DSP server linkage failure Hi Chris, Thanx for the quick reply. You have removed that flag from config.bld, and indeed it was not found in my config.bld. Turns out that my server's package.bld had a few other compilation flags added which caused the confusion: Pkg.attrs.copts = -d__C6446__ -O2 -ml3 --symdebug:none -mv6400+; I have changed it to be: Pkg.attrs.copts = -d__C6446__ -O2; which resulted in a successful build. However, I'm not really sure what the ' -ml3' and the '-mv6400+' mean, and why they were in the build script in the first place (presumably I've copy / pasted the build flags from one or more codec packages I'm using in the combo.) Any insight on that (or better yet, the correct spr.pdf :) ? I just need to know I haven't caused some massive performance degradation. Regards, Avishai From: Ring, Chris [mailto:cr...@ti.com] Sent: Monday, March 30, 2009 3:21 AM To: Avishai Hendel; davinci-linux-open-source@linux.davincidsp.com Subject: RE: migration to CE 2.10: DSP server linkage failure I think you see this if you build your server with --mem_model:data=far. Servers shouldn't throw that build flag. I checked and CE 1.20's config.bld _did_ have this option thrown - looks like we removed it in CE 2.00. [ FYI, some details on C6000 memory models are here: http://tiexpressdsp.com/wiki/index.php?title=C6000_Memory_models ] Can you see if your config.bld has this option thrown, and if so, remove it? Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Avishai Hendel Sent: Sunday, March 29, 2009 7:43 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: migration to CE 2.10: DSP server linkage failure Hello all, I've been trying to migrate our DSP server combo to CE 2.10 environment from CE 1.20. I haven't changed anything in our usual configuration (server.cfg, server.tcf etc.), except for the xdcpaths.mak file, which now specifies these recommended packages: CE Ver: 2_10_02 XDC: 3_00_06 DSP/BIOS: 5_32_01 CG: 6_0_22 (I have also used 6_0_16, with the same outcome) The rest of the modules are presumably taken from the CE internal 'cetools' directory. Compilation fails with these warnings: warning: Detected a near (.bss section relative) data reference to the symbol _VISA_checked defined in section .far. The reference occurs in videnc1.o64P (/home/dvevm/codec_engine_2_10_02/packages/ti/sdo/ce/video1/lib/debug/videnc1.a64P), section .text, SPC offset . Either make the symbol near data by placing it in the .bss section, or make the references to the symbol far. For C/C++ code use 'far' or 'near' modifiers on the type definition of the symbol or compile with the --mem_model:data switch. warning: Detected a near (.bss section relative) data reference to the symbol _VISA_checked defined in section .far. The reference occurs in imgenc.o64P (/home/dvevm/codec_engine_2_10_02/packages/ti/sdo/ce/image/lib/debug/image.a64P), section .text, SPC offset . Either make the symbol near data by placing it in the .bss section, or make the references to the symbol far. For C/C++ code use 'far' or 'near' modifiers on the type definition of the symbol or compile with the --mem_model:data switch. warning: Detected a near (.bss section relative) data reference to the symbol _VISA_checked defined in section .far. The reference occurs in videnc.o64P
RE: CMEM Issue in Decode Demo Application
From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Prabhaharan R-TLS,Chennai Sent: Sunday, March 22, 2009 2:08 AM To: davinci-linux-open-source Subject: CMEM Issue in Decode Demo Application Hello All, We are working on DM355 to play the live streamed video from an external source frame by frame. For achieving this, we are modifying the TI's Decode Demo application in the DM355 EVM in such a way that the streamed video frame is read from the custom kernel driver node instead of reading from the file. While doing this, we see that the memory allocated in CMEM pool is not accessible by the kernel driver that we have developed. How are you trying to access CMEM memory from your kernel driver? The kernel already has mappings to the CMEM memory, as established in the CMEM kernel driver. How is your kernel driver mapping to CMEM memory? To resolve this, we allocated memory for the loader module statically instead of CMEM memory pools. When we do like this, the Decode demo application is not all running. We assume that the Decode Demo application can't access memory area other than CMEM pools, whereas the kernel driver can't access the CMEM pools. Because of this, we are not able to feed the frame by frame received video data to the Decode Demo application. CMEM serves the needs of codecs that need physically contiguous memory, such as codecs that acccess data through physical addresses (either through the CPU or some HW accelerator). That's really the only difference between CMEM memory and other memory. Statically allocated buffers are probably not physically contiguous. Regards, - Rob Could anyone please suggest some ways to resolve this issue? Thanks a lot in advance. Thanks, Prabha. DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. --- ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Compiling codec engine video1_copy in DM6446
Your C64P.rootDir needs to point to the location of your TI C6x codegen tools (not your XDC tools). The path you set there needs to end at the CG tools base directory (directory above 'bin', 'include', etc.). - Rob From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On Behalf Of kirthika varadarajan Sent: Tuesday, February 24, 2009 10:13 PM To: Davinci-linux-open-source@linux.davincidsp.com Subject: Compiling codec engine video1_copy in DM6446 While compiling codec engine video1_copy in DM6446 i am getting the following errors. WARNING: Can't call useModule() now: ti.sdo.ce.Engine ti.sdo.ce.osal.validate() ... js: /home/kirthika/dvevm_1_20/xdc_2_94/packages/xdc/cfg/Main.xs, line 169: exception from uncaught JavaScript throw: Error: incompatible use of the target 'ti.targets.C64P': imported ti.targets.C64P [], ti.targets.rts6000 was built using ti.targets.C64P [1,0,6.0,11], ti.xdais.dm.examples.viddec1_copy was built using ti.targets.C64P [1,0,6.0,7], ti.xdais.dm.examples.videnc1_copy was built using ti.targets.C64P [1,0,6.0,7] /home/kirthika/dvevm_1_20/xdc_2_94/packages/xdc/xs.js, line 137 gmake[1]: *** [package/cfg/app_x64Pcfg.s62] Error 1 gmake[1]: *** Deleting file `package/cfg/app_x64Pcfg.s62' gmake[1]: *** [package/cfg/app_x64Pcfg.s62] Deleting file `package/cfg/app_x64Pcfg.cmd' gmake[1]: *** [package/cfg/app_x64Pcfg.s62] Deleting file `package/cfg/app_x64Pcfg_c.c' gmake: *** [/home/kirthika/dvevm_1_20/codec_engine_1_10_01/examples/apps/video1_copy,.executables] Error 2 gmake: *** [all] Error 2 I modified /home/dvevm_1_20/codec_engine_1_10_01/examples/xdcpaths.mak and user.bld to the reference where the actual FC_INSTALL,BIOS,xdc etc. as well as user.bld to C64P.rootDir = /home/kirthika/dvevm_1_20/xdc_2_94; MVArm9.rootDir = /opt/mv_pro_4.0/montavista/pro/devkit/arm/v5t_le; I am getting the above errors ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Building video_copy using CCS3.3
Try adding the following to your .pjt file's C compiler options. -i%XDC_INSTALL_DIR%/packages -dxdc_target_types__=ti/targets/std.h Regards, - Rob From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of ? ? Sent: Sunday, February 15, 2009 5:40 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Building video_copy using CCS3.3 hi,all. I'm using DM6446,I want to build the video_copy using CCS3.3, the video_copy is a example of xdias6.22 but I got some errors when I builded the project. the error says can not open file 'xdc/std.h' and It's the same about other header files I'm sure I've add the directory to the compiler in customize-directories How can I fix the program? Thanks in advance! Bob 好玩贺卡等你发，邮箱贺卡全新上线！http://cn.rd.yahoo.com/mail_cn/tagline/card/*http://card.mail.cn.yahoo.com/ ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: CMEM/DSPLink and 2.6.28 kernel?
Linux Utils 2.22 contains an update to CMEM for 2.6.28 kernels, although it hasn't yet been validated. Here's the output of a diff -c with the Linux Utils 2.21 cmemk.c: *** *** 1694,1700 --- 1694,1704 #ifdef USE_CLASS_DEVICE class_device_create(cmem_class, NULL, MKDEV(cmem_major, 0), NULL, cmem); #else + #if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,27) + device_create(cmem_class, NULL, MKDEV(cmem_major, 0), NULL, cmem); + #else device_create(cmem_class, NULL, MKDEV(cmem_major, 0), cmem); + #endif // LINUX_VERSION_CODE = KERNEL_VERSION(2,6,27) #endif // USE_CLASS_DEVICE #endif // USE_CLASS_SIMPLE #endif // USE_UDEV I hear the DSPLink team is being pressured to provide an update for 2.6.28, but don't know the status of that. - Rob -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com ] On Behalf Of Yusuf Caglar AKYUZ Sent: Thursday, January 29, 2009 2:11 PM To: Ryan Talbot Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: CMEM/DSPLink and 2.6.28 kernel? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Talbot wrote: I searched the list, but couldn't find any evidence of patches to get CMEM or DSPLink working with davinci-git kernels 2.6.26. We're currently using 2.6.28-rc6-davinci1, CMEM from TI's LinuxUtils 2.21 package, and DSPLink 1.60. CMEM at least looks like it needs some patches to work with 2.6.28 kernels; I haven't tried building DSPLink yet. Are there no patches available? I just wanted to make sure I wouldn't be reproducing work, if there were. You can find all the necessary patches in the openembedded tree. I worked with dsplink 1.50, dsplink 1.60 and 1.30 with latest kernels. CMEM is the well-behaved child when compared to dsplink. It was always easy to make it work, though I haven't tried latest CMEM. Regards, Caglar Thanks, Ryan Talbot rtal...@vtti.vt.edu -- -- ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkmCKXgACgkQ/nL+S5dojeiHlwCePLMuW9ifZdod0oJuxdvo58eT 0fAAnj5goTVustlHL6LT9ssHjRXrSd+P =lez1 -END PGP SIGNATURE- ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [patch 2.6.28-rc8-davinci1-git+ 0/8] EDMA cleanup/shrinkage
-Original Message- From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincids p.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d avincidsp.com] On Behalf Of Troy Kisky Sent: Tuesday, January 06, 2009 2:07 PM To: David Brownell Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: [patch 2.6.28-rc8-davinci1-git+ 0/8] EDMA cleanup/shrinkage David Brownell wrote: On Tuesday 06 January 2009, David Brownell wrote: int edma_request_p_ram(int slot); ... allocates PaRAM slot not bound to a channel, returning that or negative errno. Negative slot (typical case) means to just choose one. I can't imagine wanting to request a specific reload slot. I think no parameters would be better. I'd like to chime in here and state a need coming from TI's Framework Components layer - the need to allocate a range of contiguous unbound PaRAM slots. From this perspective, a single function parameter of int num would be sufficient. Regards, - Rob Troy ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: A way to export from c an environment var
This is overly complex. The initial setting of env var EVR at the beginning of
the script does nothing, and the C program is just using the environment to
store a temp value, which isn't even needed. The usage of a file is also
unnecessary (unless you want to retain the value).
This would do the same thing...
#!/bin/sh
EVR=`./your_c_program`
Or in csh
#!/bin/csh
setenv EVR `./your_c_program`
With the C program being
printf(%d, int_value);
or
printf(string_value);
or whatever needs to be set in the env var.
- Rob
-Original Message-
From:
davinci-linux-open-source-bounces+rtivy=ti@linux.davincids
p.com
[mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d
avincidsp.com] On Behalf Of Sander Huijsen
Sent: Thursday, December 18, 2008 6:08 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: RE: A way to export from c an environment var
Well yes, Arie, you are right about that. I did find a
clever/nasty (you be the judge of that) solution for the
problem. Simply write the environment variable from within
your application to a file, and then source the file in
your script. :-)
The script might look something like this:
[script]
#!/bin/sh
# create some environment variable 'EVR' and show it
EVR=your value
echo $EVR
# run your C program, which changes EVR and exports it
to /tmp/evr.env
./your_c_program
# source the changed environment
source /tmp/evr.env
# now show the changed value
echo $EVR
# and exit the script.
exit 0
[/script]
In your C program, you would do something like this:
[snippet]
// Here, you change the environment variable
setenv(EVR, my changed value, 1);
// Open a temp file to write the environment variable in
FILE *fh = fopen(/tmp/evr.env, w+);
if (fh)
{
// This will write 'EVR=my changed value' in
the temp file
fprintf(fh, EVR=\%s\\n, getenv(EVR));
fclose(fh);
}
[/snippet]
Regards,
Sander
-Original Message-
From: Arie de Muijnck [mailto:leon...@ademu.com]
Sent: Thursday, December 18, 2008 10:52 AM
To: Sander Huijsen; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: A way to export from c an environment var
Unless one wants to set a persistant value, that can be used
after his/hers process finishes...
Unfortunately functions like setenv(), putenv(),
system(export ...) change only the current environment of
the process itself, not the 'global'
environment of the user (let alone the system).
Regards,
Arie de Muijnck
- Original Message -
You might want to try setenv(). Just type 'man 3 setenv' in a Linux
shell to get the man-page for that function (which is in stdlib).
Sander
-Original Message-
Hi,
Is there a way to create and export from c an environment
variable a
bash script can be aware of? I intend something like PATH, etc.
Thanks and Regards,
VanVliet
Dr. Caroline Van Vliet
Adfl Group
Advanced DSP Flexible Language Group
Via Greto di Cornigliano 6R
16152 - Genova, Italy
Tel. +39 010 8609370 - Fax +39 010 8609381
CONFIDENTIALITY NOTICE - This e-mail transmission, and any
documents, files or previous e-mail messages attached to it
may contain information that is confidential or legally
privileged. If you are not the intended recipient, or a
person responsible for delivering it to the intended
recipient, you are hereby notified that you must not read
this transmission and that any disclosure, copying, printing,
distribution or use of any of the information contained in or
attached to this transmission is STRICTLY PROHIBITED. If you
have received this transmission in error, please immediately
notify Sander Huijsen by telephone or
shuij...@optelecom-nkf.com and delete the original
transmission and its attachments without reading or saving in
any manner.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: A way to export from c an environment var
No, a process can't modify the environment of its parent (and the parent of a program is typically a shell). You could have the program output the desired environment variable contents and do % YOURENVVAR=`yourprogramname` - Rob -Original Message- From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincids p.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d avincidsp.com] On Behalf Of Van Vliet Sent: Wednesday, December 17, 2008 7:57 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: A way to export from c an environment var Hi, Is there a way to create and export from c an environment variable a bash script can be aware of? I intend something like PATH, etc. Thanks and Regards, VanVliet Dr. Caroline Van Vliet Adfl Group Advanced DSP Flexible Language Group Via Greto di Cornigliano 6R 16152 - Genova, Italy Tel. +39 010 8609370 - Fax +39 010 8609381 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Error with CMem
Your insmod command looks fine. With it, you've got 3 buffers available from pools that have large enough buffers (the first 2 entries in your 'pools' setting). The 3rd entry configures 7 buffers of size 829440, which is a little bit too small for satisfying requests for 8884736. So, it comes down to how many allocations from the first 2 pools have already happened prior to this error. I'd guess that you're simply running out of large enough buffers. - Rob From: davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com] On Behalf Of Neerav Patel Sent: Wednesday, December 17, 2008 11:15 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Error with CMem Hi I have managed to get jpeg compression working on the DM355 Board, but everytime I run the code, I am getting a error like: CMem Error: getPool: Failed to get a pool fitting a size 884736 CMEMK Error: Failed to find a pool which fits 884736 I have tried to change the insmod command but I don't think I am doing it right since, no matter what I do it pops this error out, can someone show me how this is done. This is the following insmod command I am using Insmod cmemk.ko phys_start=0x8740 phys_end=0x8800 pools=1x2097152,2x1529856,7x829440,1x524288,1x108680,1x81920,2x8192,6x4096 Thanks in advance ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Error with CMem
While you might not be explicitly allocating much memory, probably codecs that
you're using are. You will need to increase the number of buffers of size =
884736 for CMEM. Since your current pool configuration consumes all of the
12MB granted to CMEM, you will need to either reduce some of the pools or grant
more memory to CMEM.
One possibility is to simply increase the pool buffer size that currently is
configured as 7x829440. You should have enough room in your CMEM memory to
change 829440 to 884736.
If that doesn't do the trick for you, you will need to get some idea of your
CMEM memory needs. One way to do this is to set the CMEM module's debug flag
to true in your application .cfg file:
var cmem=xdc.useModule('ti.sdo.linuxutils.cmem.CMEM');
cmem.debug = true;
It looks like you're already doing this (or some other module is doing this for
you), since you listed CMEM debug in your original email. Take a look at the
allocation requests to CMEM, and match your pool allocations accordingly.
This Wiki might help:
http://wiki.davincidsp.com/index.php?title=CMEM_Overview
- Rob
-Original Message-
From: Neerav Patel [mailto:neer...@ptgrey.com]
Sent: Wednesday, December 17, 2008 11:34 AM
To: Tivy, Robert
Cc: Neerav Patel; davinci-linux-open-source@linux.davincidsp.com
Subject: Re: Error with CMem
Hi Robert,
Thanks for the response, is there anything that I can do to
then to stop getting this error, I am not doing a lot of
memory allocation?
Is there a way to make more space?
Tivy, Robert wrote:
Your insmod command looks fine. With it, you've got 3 buffers
available from pools that have large enough buffers (the first 2
entries in your 'pools' setting). The 3rd entry configures
7 buffers
of size 829440, which is a little bit too small for satisfying
requests for 8884736.
So, it comes down to how many allocations from the first 2
pools have
already happened prior to this error. I'd guess that you're simply
running out of large enough buffers.
- Rob
--
--
*From:*
davinci-linux-open-source-bounces+rtivy=ti@linux.davincidsp.com
[mailto:davinci-linux-open-source-bounces+rtivy=ti@linux.d
avincidsp.com]
*On Behalf Of *Neerav Patel
*Sent:* Wednesday, December 17, 2008 11:15 AM
*To:* davinci-linux-open-source@linux.davincidsp.com
*Subject:* Error with CMem
Hi
I have managed to get jpeg compression working on the
DM355 Board,
but everytime I run the code, I am getting a error like:
CMem Error: getPool: Failed to get a pool fitting a size 884736
CMEMK Error: Failed to find a pool which fits 884736
I have tried to change the insmod command but I don't think I am
doing it right since, no matter what I do it pops this
error out,
can someone show me how this is done. This is the following
insmod command I am using
Insmod cmemk.ko phys_start=0x8740 phys_end=0x8800
pools=1x2097152,2x1529856,7x829440,1x524288,1x108680,1x81920,2x8192,6x
4096
Thanks in advance
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: undefined reference to 'IMGENC1_create' error
Either the application .cfg file or some included package would need to do:
xdc.useModule('ti.sdo.ce.image1.IIMGENC1');
to bring in the library containing IMGENC1_create().
I'm not familiar with the details of the ti.sdo.codecs.jpegenc.dm355.ce.JPEGENC
module so I can't check that out, but perhaps you need to manually invoke the
above statement in your cfg.
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Neerav Patel
Sent: Monday, December 15, 2008 12:44 PM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: undefined reference to 'IMGENC1_create' error
Hi,
I am getting an error of undefined reference to 'IMGENC1_create' I have added
the appropriate header file #include ti/sdo/ce/image1/imgenc1.h to the code,
I suspect that something in the cfg file may be not correct to make it not link
to the proper libraries?
This is my cfg file I am using! Thank in advance
/*
* Copyright (c) Texas Instruments Incorporated 2007
*
* Use of this software is controlled by the terms and conditions found in the
* license agreement under which this software has been supplied or provided.
*
*/
var osalGlobal = xdc.useModule( 'ti.sdo.ce.osal.Global' );
osalGlobal.runtimeEnv = osalGlobal.LINUX;
//var MPEG4ENC = xdc.useModule('ti.sdo.codecs.mpeg4enc.dm355.ce.MPEG4ENC');
//var MPEG4DEC = xdc.useModule('ti.sdo.codecs.mpeg4dec.dm355.ce.MPEG4DEC');
var JPEGENC = xdc.useModule('ti.sdo.codecs.jpegenc.dm355.ce.JPEGENC');
/*
* Engine Configuration
*/
var Engine = xdc.useModule('ti.sdo.ce.Engine');
var demoEngine = Engine.create(securitycamera, [
//{name: mpeg4enc, mod: MPEG4ENC, local: true, groupId: 1},
//{name: mpeg4dec, mod: MPEG4DEC, local: true, groupId: 1},
{name: jpegenc, mod: JPEGENC, local: true, groupId: 1},
]);
/*
* DMAN3 Configuration
*/
var DMAN3 = xdc.useModule('ti.sdo.fc.dman3.DMAN3');
/* give DMAN3 all TCCs except those hard-coded by The JPEG MPEG Enc Decs */
/*
* For the 32-63 range, configure tccAllocationMaskH to exclude used channels
* JPEG Dec: {33-47, 52-57}
* JPEG Enc: {34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49}
* MPEG Dec: {32-63}
* MPEG Enc: {12, 13, 34, 35, 40,41,42,43,44,45,46,47,48,49,50,52,53,
* 54,55,56,57,63}
*/
DMAN3.tccAllocationMaskH = 0x0; /* everthing 32-63 hardcoded and unavailable */
/* Give DMAN3 all lower TCCs except what's taken by Linux kernel and a Codec:
* Based on the info from montavista: {2, 3, 8, 9, 26, 27, 30, 31}
* and MPEG Enc taking up:{12, 13}
*/
DMAN3.tccAllocationMaskL = 0x33ffccf3;
/* Following assignments will give DMAN3 control of PaRAMs above 78: */
DMAN3.paRamBaseIndex = 64;
DMAN3.numPaRamEntries = 48;
DMAN3.nullPaRamIndex = 127;
/* Configure Scratch Group's DMAN3 resources */
DMAN3.numTccGroup[1] = 0;
DMAN3.numPaRamGroup[1] = 32;
DMAN3.qdmaChannels = [0, 1, 2, 3, 4, 5, 6, 7];
DMAN3.maxQdmaChannels = 8;
DMAN3.numQdmaChannels = 8;
DMAN3.maxTCs = 2;
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Re: CMEM Error
Your loadmodules.sh shows you giving 12MB to CMEM (although the insmod line
appears to be commented out). This amount will satisfy your specified needs of
My memory req are like
pool fitting a size 4147200
pool fitting a size 8294400
although enough for only one of each. However, you are partitioning the 12MB
with too many pools/buffers to allow your allocations to succeed. Try
specifying:
pools=1x8294400,1x4147200
If you need more than just those two buffers, you will need to give less memory
to Linux and more to CMEM. Linux kernel memory is specified on the boot
command. With your given loadmodules.sh, you would need to be specifying
mem=116M at a maximum, and to give more to CMEM you would need to specify less
than 116M.
- Rob
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of ashish pareek [EMAIL
PROTECTED]
Sent: Monday, November 03, 2008 4:56 AM
To: Vladimir Pantelic
Cc: davinci
Subject: Re: Re: CMEM Error
Hi,
Since i am new to linux can u let me know how i can exchange memory with linux .
My loadmodules.sh script looks like
#!/bin/sh
# 12MB
# insmod cmemk.ko phys_start=0x8740 phys_end=0x8800
pools=1x2097152,2x1529856,7x829440,1x524288,1x108680,1x81920,2x8192,6x4096
./mapdmaq
insmod dm350mmap.ko
rm -f /dev/dm350mmap
mknod /dev/dm350mmap c `awk \\$2==\dm350mmap\ {print \\$1} /proc/devices` 0
My memory req are like
pool fitting a size 4147200
pool fitting a size 8294400
Regard's
Ashish
On Mon, 03 Nov 2008 Vladimir Pantelic wrote : ashish pareek wrote: Hi, I
tried to configure my memory requirements in loadmodules.sh script that
allocated memory pools , but i got error CMEMK Error :failed to get big
enough free block . increase the size of memory that you give to cmem and
reduce the size given to linux (mem=xxx). Is it because my mem req are so
high ? How cud i find maxm memory supported ? I don't know your memory
requirements, but you exchange cmem for linux mem easily.Ashish
On Mon, 03 Nov 2008 Vladimir Pantelic wrote : ashish pareek wrote:
Hi , Is it possible to have an jpg image of high resolution (i.e. 1920 x
1080) from jpeg engine using DM355 . Are their any kind of hardware limitation
in doing that ? My idea is to get an high resolution RAW and YUV (i.e.
1920 x 1080) image and than convert YUV image to jpg using JPEG engine .
When i tried to have an image 1920 x 1080 resolution i found following
error CMEM Error : getPool : failed to get a pool fitting a size 4147200
CMEM Error : getPool : failed to get a pool fitting a size 8294400
CMEM was not able to find a large enough buffer, check how it is configured
(when the modules is loaded) and increase the pool size.
___ Davinci-linux-open-source
mailing list Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Rediff Shopping___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: RTSC Server Package Wizard
Stabbing in the dark, could it be that your XDCPATH definition has a typo?
There is no leading / in front of home/albertb/albertb_tests/packages.
- Rob
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert Burbea
Sent: Wednesday, October 22, 2008 8:05 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: RTSC Server Package Wizard
Hi everybody
I am trying to build a codec/server bundle. I succeed to run the example viddec
provided in ceutils_1_06.
when I try to build the h264dec provided from TI, I succeed to build the codec,
but when I build the server I consistenly encounter the following error:
Package, ti.sdo.codecs.h264dec, not found with module H264DEC... modify your
XDCPATH to include the package's repository.
Now, I checked all the points in the FAQ, and I think I am OK. I build the
server using the following script
[EMAIL PROTECTED] albertb_tests]$ cat rtsc_svr_file.sh
export MOZILLA_FIVE_HOME=/usr/lib/xulrunner-1.9pre
export LD_LIBRARY_PATH=$MOZILLA_FIVE_HOME
export LD_LIBRARY_PATH=$MOZILLA_FIVE_HOME/plugins:$LD_LIBRARY_PATH
export DVSDK_INSTALL_DIR=${ACTIVE_DVSDK}
export
XDCPATH=home/albertb/albertb_tests/packages;$DVSDK_INSTALL_DIR/ceutils_1_06/packages;$DVSDK_INSTALL_DIR/codec_engine_2_10_01/packages;$DVSDK_INSTALL_DIR/xdais_6_10_01/packages;$DVSDK_INSTALL_DIR/bios_5_32_01/package
echo XDC PATH IS
echo $XDCPATH
echo
xs ti.sdo.codecutils.genserver -f=./test3.xml
and here is test3.xml
[EMAIL PROTECTED] albertb_tests]$ cat test3.xml
?xml version=1.0?rtsc_server_package_wizard
version0.2.3/version
packageNameti.sdo.codecs.h264dec/packageName
serverNameti.sdo.servers.h264dec_unitserver_evmdm6467/serverName
outputRepository/home/albertb/albertb_tests/codecs/outputRepository
platformti.platforms.evmDM6467/platform
moduleH264DEC/module
/rtsc_server_package_wizard
the codec files are under /home/albertb/albertb_tests/codecs, and the body of
the codec is under /home/albertb/albertb_tests/codecs/ti/sdo/codecs/h264dec/
Yet, it does not build the server I begin to be quite desperate.
Any help?
Albert
--
Albert Burbea
Harishonim 8
Ramat Gan 52502, Israel
Tel/Fax + 972-3-7526016
Mobile: +972-52-3541842
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: basic question(s)...
I don't know about standard library/hookup, but DSP/BIOS and DSPLink are widely used for the ARM-DSP communication. DSPLink is kind of low level, so you could also use Codec Engine from TI for simplifying and/or abstracting the interface between the DSP and ARM, and in doing so could probably forgo the need for CCS. - Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Ed Sutter Sent: Wednesday, October 22, 2008 12:14 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: basic question(s)... Hi, More questions for any of you patient enough to answer... I'm trying to get to know the OMAP35xx development environment a bit better. What is the typical mode of development for OMAP35xx based projects? I'm guessing that the answer to this question is dependent on what it is I need to develop. Do most folks dig right in and do both linux/arm and C64 development? Is there a standard library/hookup between linux on the ARM and the DSP? If I need to do some DSP programming do I have to purchase CCS or are there other alternatives? Thanks in advance... Ed ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Non blocking VISA API calls on DM6467
Arvind, Yes, non-blocking VISA APIs (asynchronous APIs) are available in CE 2.10 w/DM6467 and the VIDENC1/VIDDEC2 codecs. I'm not sure what pointers you want, except to say that instead of doing VIDENC1_process() you would do VIDENC1_processAsync() ... VIDENC1_processWait() Regards, - Rob From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arvind Raman Sent: Friday, October 03, 2008 6:38 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Non blocking VISA API calls on DM6467 I was wondering if anybody would be able to confirm if DVSDK version 1.40.00.31http://1.40.00.31 (codec engine version 2.10.01) on DM6467 supports non-blocking VISA API calls. I presume this is the latest build of the DVSDK available on DM6467. I am particularly interested in knowing if the video encoder (VIDENC1) and decoder (VIDDEC2) calls can be made in a non-blocking manner (asynchronous) from the ARM of the DM6467. Would appreciate any pointers that would help me figure this out. Thanks and Regards Arvind ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: ememk.ko build error
Ramesh, Your UCTOOL_PREFIX macro is commented out. This is preventing the uClibc build of the src/interface library, and it looks like the failure is stopping the build and therefore not even getting around to the cmemk.ko build. Your cmemk.ko build will just use the MVTOOL_PREFIX (we don't build it w/ uClibc since that's a user-level lib). - Rob From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ramesh Sent: Thursday, September 25, 2008 11:24 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: ememk.ko build error Hi all, I am facing an problem in when I wanted to run DM6467 demo code. I have build the Server and application side. But I am not able to build the cmemk.ko file. When I wanted to build cmem, getting the following error. Error Message : ## [EMAIL PROTECTED] cmem]# gmake Making all in subdirectory src... gmake[1]: Entering directory `/home/Ramesh/dvsdk_1_40_00_11/cmem_2_00/packages/ti/sdo/linuxutils/cmem/src' Making all in subdirectory interface... gmake[2]: Entering directory `/home/Ramesh/dvsdk_1_40_00_11/cmem_2_00/packages/ti/sdo/linuxutils/cmem/src/interface' /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-gcc -I. -Wall -c -g -D__DEBUG -o debug/cmem.o cmem.c /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-ar rc ../../lib/cmemd.a debug/cmem.o Installing headers... /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-gcc -I. -Wall -c -O2 -o release/cmem.o cmem.c /opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-ar rc ../../lib/cmem.a release/cmem.o /gcc -c -g -I. -Wall -o debug/cmem.o470uC cmem.c gmake[2]: /gcc: Command not found gmake[2]: *** [debuguc] Error 127 gmake[2]: Leaving directory `/home/Ramesh/dvsdk_1_40_00_11/cmem_2_00/packages/ti/sdo/linuxutils/cmem/src/interface' gmake[1]: *** [interface] Error 2 gmake[1]: Leaving directory `/home/Ramesh/dvsdk_1_40_00_11/cmem_2_00/packages/ti/sdo/linuxutils/cmem/src' gmake: *** [src] Error 2 ### My setting : EXEC_DIR=/home/Ramesh/tmp6467 # The prefix to be added before the GNU compiler tools (optionally including # path), i.e. arm_v5t_le- or /opt/bin/arm_v5t_le-. MVTOOL_PREFIX=/opt/mv_pro_4.0.1/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le- # Equivalent path for uClibc compiler tools # UCTOOL_PREFIX =/db/toolsrc/library/vendors2005/opensource/buildroot/16012006/staging_dir/arm-linux-uclibc/bin # # # The directory that points to your kernel source directory. This is used # for building the cmemk.ko kernel module, as the kernel's build system # gets invoked. Note that this also means that the below C_FLAGS etc. will # be ignored when building this particular module. #LINUXKERNEL_INSTALL_DIR=/db/toolsrc/library/vendors2005/mvl/arm/DaVinci-Linux-Rel_mvl401c/Linux #LINUXKERNEL_INSTALL_DIR=/db/toolsrc/library/vendors2005/mvl/arm/dm355/REL_TI_DM355_LSP_120_004/montavista/pro/devkit/lsp/ti-davinci #LINUXKERNEL_INSTALL_DIR=/db/toolsrc/library/vendors2005/mvl/arm/dm6467/REL_DM700_LINUX_PSP_0.4.0/Linux LINUXKERNEL_INSTALL_DIR=/opt/mv_pro_4.0.1/montavista/pro/devkit/lsp/ti-davinci ### And I did not change the Makefile. I am not able to locate the error. Help me , if I am doing something wrong. Thanks Ramesh. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Need Help on Gstreamer AVI - 264 video files
Anil, It sounds like you're doing the right things with CMEM, so I can't directly answer your problem but do have some suggestions... First, make sure that cmemk.ko insmod's correctly, without error (errors will go to the console, and/or retrieved with the 'dmesg' command). Second, after getting the failure, you can do % cat /proc/cmem to see the allocation status of all buffers in all pools. You might see the problem from this output, but if you still believe that it's failing when it should be succeeding, email me (and/or this list) and we'll take it from there. Regards, - Rob From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anil Sent: Thursday, August 28, 2008 1:46 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Need Help on Gstreamer AVI - 264 video files Hi, I have issue with playing AVI / 264 video file using Gstreamer Release 2008.07.26 Followings are default parameter which I got with this release for cmemk and dsplink insmod cmemk.ko phys_start=0x8780 phys_end=0x88E0 pools=20x4096,8x202752,10x131072,2x1048576,1x2097152,18x614400 insmod dsplinkk.ko ddr_start=0x8F80 ddr_size=0x6 Following is the error what I got while running demo test script for avi files CMEMK Error: Failed to find a pool which fits 691200 I added pool of 25x691200 by adjusting the pools which I got with gstreamer release for CMEMK. I even tried to play video files of CIF ,4CIF,QCIF resolution of h264 format files using following gst-launch-0.10 filesrc location=$1 ! queue max-size-buffers=60 ! gdecoder Codec=0 ! fbvideosink device=/dev/fb/3 I even tried to change the resolution in gstdecoder.h default was (720x480) which it seems is in NTSC format so i changed it to PAL format (720x576) ,and adjusted the cmemk memory poll to accommodate 25x829440 but still get the following error CMEMK Error: Failed to find a pool which fits 829440 Thank's Regards, Anil ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Mempry Cpnversion Problem
Omkiran, It appears that there is a problem with the Memory_getBufferVirtualAddress() (and possibly Memory_getBufferPhysicalAddress()) when passing in a size of 0, as you are doing with all your calls. The problem occurs when 2 buffers are physically adjacent, i.e., one buffer ends at another buffer's start (minus 1). For an explanation to this, and other answers, see below... Regards, - Rob From: Omkiran Sharma [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2008 11:41 PM To: Tivy, Robert Cc: davinci forum Subject: Re: Mempry Cpnversion Problem Rob, That raises an interesting question then: Is it then necessary that something converted from VIR (virtual address) to PHY (physical address) will convert back to the same VIR when converted back? That's not an easy question to answer. Normally, all contiguous buffers in this cache list that's used by Memory_getBufferPhysicalAddress() are added to the list by way of Memory_contigAlloc(), which gets contiguous buffers from CMEM. CMEM will never return the same physical buffer with different virtual addresses. The story is complicated by the fact that Memory_getBufferPhysicalAddress can be called for non-CMEM buffers, and the function that adds to this cache list can also be manually invoked by way of Memory_registerContigBuf(). I haven't tried this, but I can imagine doing the following: - virtAddr = Memory_contigAlloc() to get a CMEM buffer - physAddr = Memory_getBufferPhysicalAddress() - newVirtAddr = mmap(/dev/mem, physAddr) will give a different virt addr than the one returned by Memory_contigAlloc() - foo = Memory_getBufferPhysicalAddress(newVirtAddr) which translates and changes virt addr for existing phys entry in contig buffer cache list - bar = Memory_getBufferVirtualAddress(foo) will return newVirtAddr I'm just braindumping here in the hope that this will somehow answer your question, but the meat of my response is below in the code trace listings... Reason why I ask: For some time we have been facing a wierd issue with CE 2.00 and have given up on it with some work arounds. We are doing 1 process call on a video codec and the outBufs-bufs pointers gets changed. and some reason it does not happen if I simply use a static global buffer for outBufs. I had two suspicions: 1. Outbufs being a input structure should not have changed. But it appears it is getting updated on the way back. 2. Even if it is getting updated, ideally the same physical address (which is what the dsp is returning) should have come back to the same virtual address. (Which does not appear to be the case) I can also see in the trace some parameters like Ss=0x40ea5000, Es=0x40ea5000, PSc=0x84057000 which ofcourse I do not understand that are different. I guess the key question is Given that Memory_getBufferVirtualAddress() works only with buffers that have previously been translated with Memory_getBufferPhysicalAddress(), is it also assured that it will return the same address back even if another virtual address is mapped to the same physical address? If that alternate mapping is known by Memory APIs then I suppose it's possible that a Memory_getBufferVirtualAddress() can return different values for the same physical address, but only if something has happened in between the two calls. If you have two virt addrs mapped to the same phys addr, and you call Memory_getBufferPhysicalAddress() with both those virt addrs *and* the same size in both calls, the virt addr in the 2nd call will get recorded in the contig buffer cache list. Memory_getBufferPhysicalAddress() first checks its cache list and if not found there, asks CMEM_getPhys(), and if that returns a valid address, it adds this phys/virt address pairing to the contig buf cache list. I'm not sure if that makes sense, but see below for the reason you're seeing what you're seeing... If it helps to notice anything the trace for the videnc_process call with the culprit section highlighted in bold, but I guess simply a clarification on the previous question will also help. @45,433,549us: [+0 T:0x00014006 S:0xbdfff41c] ti.sdo.ce.video.VIDENC - VIDENC_process Enter (handle=0xfe230, inBufs=0x4 0e774d8, outBufs=0x40e774e4, inArgs=0x40e77428, outArgs=0x40e77434) @45,433,889us: [+5 T:0x00014006 S:0xbdfff3dc] CV - VISA_allocMsg Allocating message for messageId=0x00030a5f @45,434,122us: [+0 T:0x00014006 S:0xbdfff3ac] OM - Memory_getBufferPhysicalAddress Enter(virtAddr=0x40f2b000, size=0) @45,434,373us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress Enter(virtAddr=0x40f2b000, size=0) @45,434,609us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress found in cb(Sc=0x40f2b000, Ec=0x40f50200, Ss=0x40f2b000, Es=0x40f2b000, PSc=0x84131000) @45,434,927us: [+1 T:0x00014006 S:0xbdfff3ac] OM - Memory__getPhysicalAddress returning physAddr=0x84131000 @45,435,150us: [+0 T:0x00014006 S:0xbdfff3ac] OM
RE: Problem Rebuilding the DVSDK Software for the Target
Panchy, You need to edit the CMEM Rules.make file to reflect your GCC tools location. In that file is the definition MVTOOL_PREFIX=/db/toolsrc/library/vendors2005/mvl/arm/mvl4.0-new/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le You need to change this to match the location of your compiler tools. Regards, - Rob From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Panchy Rivas Sent: Monday, August 04, 2008 8:15 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Problem Rebuilding the DVSDK Software for the Target I am having problems Rebuilding the DVSDK Software for the Target. I am following the getting started guide. Here is my screen output. [EMAIL PROTECTED] dvsdk_1_30_01_41]$ make Making all in subdirectory /home/frivas/dvsdk_1_30_01_41//cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/src/module... make[1]: Entering directory `/home/frivas/dvsdk_1_30_01_41/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/src/module' make -C /home/frivas/workdir/lsp/ti-davinci/ M=`pwd` ARCH=arm CROSS_COMPILE=/db/toolsrc/library/vendors2005/mvl/arm/mvl4.0-new/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le- \ EXTRA_CFLAGS=-DUSE_UDEV=1 -DMAX_POOLS=128 modules make[2]: Entering directory `/home/frivas/workdir/lsp/ti-davinci' CC [M] /home/frivas/dvsdk_1_30_01_41/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.o /bin/sh: /db/toolsrc/library/vendors2005/mvl/arm/mvl4.0-new/montavista/pro/devkit/arm/v5t_le/bin/arm_v5t_le-gcc: No such file or directory make[3]: *** [/home/frivas/dvsdk_1_30_01_41/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.o] Error 1 make[2]: *** [_module_/home/frivas/dvsdk_1_30_01_41/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/src/module] Error 2 make[2]: Leaving directory `/home/frivas/workdir/lsp/ti-davinci' make[1]: *** [release] Error 2 make[1]: Leaving directory `/home/frivas/dvsdk_1_30_01_41/cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/src/module' make: *** [/home/frivas/dvsdk_1_30_01_41//cmem_2_00_01/packages/ti/sdo/linuxutils/cmem/src/module] Error 2 [EMAIL PROTECTED] dvsdk_1_30_01_41]$ Thanks for the help... Panchy Rivas ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: CMEMK issue:::
Santosh, This looks like a problem with the 'insmod' command to insert CMEMK into the kernel. Usually, the insmod command is in the loadmodules.sh script. The CMEMK insmod command specifies pools of buffers. The application is allocating 1658880 bytes, so you need to make sure that a pool is specified with buffers at least that big: % insmod cmemk.ko phys_start=0x phys_end=0x pools=Nx1658880,... Regards, - Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Santoshkumar GK Sent: Wednesday, July 23, 2008 7:59 PM To: Davinci_linux_open_source (E-mail) Subject: CMEMK issue::: Hi, I am working on TMS320DM6467 board. When i run my ELF. I am getting cmemk errors such as :: CMEMK Error: Failed to find a pool which fits 1658880 CMEM Error: getPool: Failed to get a pool fitting a size 1658880 Failed to allocate memory. CMEM Error: getPhys: Failed to get physical address of 0x56376593 CMEMK Error: get_phys: Unable to find phys addr for 0x56376593 CMEMK Error: get_phys: get_user_pages() failed: -14 CMEMK Error: GETPHYS: Failed to convert virtual 0x56376593 to physical. I am using dvsdk 1_40_00_21 and cmem_2_10_00_02. Can u please let me know the solution for this . Regards, Santosh Kumar G.K The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. Contact your Administrator for further information. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Bad kernel bootargs, or bad whole kernel
The message 'no version for struct_module found: kernel tainted' occurs because the module was not built against the kernel that is booted. It's happening for both dsplinkk and ipv6, so both these modules need to be rebuilt pointing to the booted kernel sources. For CMEM, you need to insmod it with phys_start that's after all kernel memory. Making mem=120M will allow the cmemk.ko insmod to use phys_start=0x8780, since 120M = 0x0780. If more memory is granted to the kernel, some will need to be taken away from CMEM. Regards, - Rob -Original Message- From: [EMAIL PROTECTED] p.com [mailto:[EMAIL PROTECTED] avincidsp.com] On Behalf Of steven.zhang Sent: Friday, June 27, 2008 5:00 AM To: Ondrej Pindroch Cc: davinci-linux-open-source Subject: Re: Bad kernel bootargs, or bad whole kernel To correct CMEM, simple solution is passing mem=120M in u-boot. As cmem will occupy memory start at 0x8780(DDR 120M). Is IP6 a module license problem? However, I am not sure. On Fri, 2008-06-27 at 13:49 +0200, Ondrej Pindroch wrote: Can anybody tell me what is wrong. First how to correct cmem.ko. and next one, why is the IP6 not starting well. Down are some lines from kernel booting. CMEMK Error: CMEM phys_start (0x8780) overlaps kernel (0x8000 - 0x9 000) insmod: error inserting 'cmemk.ko': -1 Invalid parameters dsplinkk: no version for struct_module found: kernel tainted. dsplinkk: module license 'DSP/BIOS(TM) LINK' taints kernel. DSPLINK Module (1.50) created on Date: Jan 3 2008 Time: 13:16:55 Starting web server ... thttpd ipv6: disagrees about version of symbol struct_module modprobe: FATAL: Error inserting ipv6 (/lib/modules/2.6.10_mvl401-davinci_evm/ke rnel/net/ipv6/ipv6.ko): Invalid module format Starting MontaVista target tools daemon: mvltdipv6: disagrees about version of s ymbol struct_module modprobe: FATAL: Error inserting ipv6 (/lib/modules/2.6.10_mvl401-davinci_evm/ke rnel/net/ipv6/ipv6.ko): Invalid module format mvltd version 2.1 MontaVista Software,Inc. . mvltd[1127]: started on port 34577 MontaVista(R) Linux(R) Professional Edition 4.0.1 (0600980) Ondrej Pindroch SoftHard Technology ltd. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: davincifb driver works only at reserver memory 120M-126M usingioremap
Are you using CMEM? Typically, CMEM is configured (during 'insmod', usually from the loadmodules.sh script) to use 120MB - 128 MB. Regards, - Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of steven.zhang Sent: Thursday, June 26, 2008 1:33 AM To: davinci Cc: torran; [EMAIL PROTECTED] Subject: davincifb driver works only at reserver memory 120M-126M usingioremap Hi, all. I change davincifb driver DMA buffer allocation from dma_alloc_coherent() into using ioremap() to reserver FB memory. If the reserve memory resides between 120M-126M, it works fine,while larger than 126M, its output is lines instead of linux tux. phys memory of my board is 256M, and pass mem=120M into bootargs. any thoughts? Regards, steven ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: CMEM warnings during codec create
This warning is produced at GT trace level 6, so it can be disabled by not enabling 6 in CE_TRACE (but CE_DEBUG=[1|2|3] might turn it on). The simplest solution is to pass Memory_DEFAULTALIGNMENT in the align parameter. I'm not sure about the DSKT2 question, perhaps the answer is IRES/RMAN? Regards, - Rob From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Omkiran Sharma Sent: Friday, June 20, 2008 2:31 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: CMEM warnings during codec create Hi, During codec create we get a warning saying that pool based allocation does not support an alignment using default alignment 0x during codec create. While it does not cause any issues, is there any way to switch of this warning? This raised another question in my head: While we have a DSKT2 manager on the DSP, who is the manager on the ARM side? Regards, Omkiran ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: VISA API Error
This assertion is produced when VISA_freeMsg() is called more times than VISA_allocMsg(). These APIs are used by the VISA codec class 'process()' and 'control()' functions, as well as asynchronous SPIs 'processAsync()' [calls VISA_allocMsg()]and 'processWait()' [calls VISA_freeMsg()]. It's difficult to deduce exactly why you are hitting this false assertion, so in order to determine any further cause, could you please re-run the application with the env variable CE_DEBUG=2 and reply with the output? Perhaps something failed earlier and this message is just secondary. Regards, - Rob From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of amr ali Sent: Sunday, June 15, 2008 4:23 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: VISA API Error Hi, I am currently porting some open source algorithms to DM6446. I managed to successfully compile it on DSP. When I run the algorithm, I get the following message visa.c:561: VISA_freeMsg: Assertion `visa-cmd[visa-cmdFreeIndex] == ((void *)0)' failed.. Why do I get this message? How to avoid it? BR, Amr Ali. Get news, entertainment and everything you care about at Live.com. Check it out! http://www.live.com/getstarted.aspx ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: cmem issure of DVEVM_1_30
Udev is there, it just looks different in the 2.6.23 kernel. CMEM
v2.00.01 was written for the 2.6.10 kernel. Sometime between 2.6.10 and
2.6.23 the 'class_simple' interface was replaced by 'class'. Later
CMEMs support both interfaces, dependant on:
#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,18)
#undef USE_CLASS_SIMPLE
#else /* LINUX_VERSION_CODE = KERNEL_VERSION(2,6,18) */
#define USE_CLASS_SIMPLE
#endif /* LINUX_VERSION_CODE = KERNEL_VERSION(2,6,18) */
...
...
#ifdef USE_CLASS_SIMPLE
cmem_class = class_simple_create(THIS_MODULE, cmem);
#else
cmem_class = class_create(THIS_MODULE, cmem);
#endif
if (IS_ERR(cmem_class)) {
__E(Error creating cmem device class.\n);
err = -EIO;
goto fail_after_reg;
}
#ifdef USE_CLASS_SIMPLE
class_simple_device_add(cmem_class, MKDEV(cmem_major, 0), NULL,
cmem);
#else
class_device_create(cmem_class, NULL, MKDEV(cmem_major, 0), NULL,
cmem);
#endif
So you have a few options:
- stick with what you're doing
- manually modify your cmemk.c file to convert usage of
class_simple to class (quite easy), and use USE_UDEV=1
- upgrade to CMEM 2.10 or later
Regards,
- Rob
-Original Message-
From: steven.zhang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2008 10:21 PM
To: Tivy, Robert
Cc: davinci
Subject: RE: cmem issure of DVEVM_1_30
Yes,USE_UDEV is disable.
If I enable it, compile error arises.
class_simple_create not define.
My kernel version is 2.6.23 which is cut from davinci tree.
As I know, udev is included in almost every 2.6 kernel based
Linux distribution.But why davinci kernel tree does not support it?
However, I can create /dev/cmem manually with the help of Andre.
Thanks.
Steven
On Wed, 2008-06-11 at 12:15 -0500, Tivy, Robert wrote:
Steven,
Did you use the provided Makefile (which includes ../../Rules.make)?
There is a macro USE_UDEV that needs to be set to 1 in order to get
insmod-time /dev/cmem creation. This setting of USE_UDEV
is usually
done in the provided 'make' file Rules.make and is
'consumed' in the
rule to build cmemk.c.
Regards,
- Rob
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of steven.zhang
Sent: Tuesday, June 10, 2008 11:08 PM
To: davinci
Subject: cmem issure of DVEVM_1_30
Hi, all.
Days before, I updated my evm to 1.30.
cmem module is also upgraded to cmem_2_00_01 from cmem_1_02.
And succeed in building cmemk.ko.However, after running
loadmodules.sh, everything seems right, but I can not
find any cmem
entry in /dev/! What can be the problem?
The following message is grabbed while insmod cmemk.ko.
[EMAIL PROTECTED]:/opt/dvevm# ./loadmodules.sh
ioremap_nocache(0x8780, 8388608)=0xc900
ioremap_nocache(0x8780, 8388608)=0xc900 6allocated heap
buffer 0xc900 of size 0xf7000 allocated heap buffer
0xc900
of size 0xf7000 6cmem initialized 4 pools between
0x8780 and
0x8800 cmem initialized 4 pools between 0x8780 and
0x8800
dsplinkk: no version for struct_module found: kernel tainted.
dsplinkk: no version for struct_module found: kernel tainted.
1DSPLINK Module (1.40.05_p1) created on Date: Jun 11 2008 Time:
13:32:41
DSPLINK Module (1.40.05_p1) created on Date: Jun 11 2008
Time: 13:32:41
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-sour
ce
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: cmem issure of DVEVM_1_30
Steven, Did you use the provided Makefile (which includes ../../Rules.make)? There is a macro USE_UDEV that needs to be set to 1 in order to get insmod-time /dev/cmem creation. This setting of USE_UDEV is usually done in the provided 'make' file Rules.make and is 'consumed' in the rule to build cmemk.c. Regards, - Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of steven.zhang Sent: Tuesday, June 10, 2008 11:08 PM To: davinci Subject: cmem issure of DVEVM_1_30 Hi, all. Days before, I updated my evm to 1.30. cmem module is also upgraded to cmem_2_00_01 from cmem_1_02. And succeed in building cmemk.ko.However, after running loadmodules.sh, everything seems right, but I can not find any cmem entry in /dev/! What can be the problem? The following message is grabbed while insmod cmemk.ko. [EMAIL PROTECTED]:/opt/dvevm# ./loadmodules.sh ioremap_nocache(0x8780, 8388608)=0xc900 ioremap_nocache(0x8780, 8388608)=0xc900 6allocated heap buffer 0xc900 of size 0xf7000 allocated heap buffer 0xc900 of size 0xf7000 6cmem initialized 4 pools between 0x8780 and 0x8800 cmem initialized 4 pools between 0x8780 and 0x8800 dsplinkk: no version for struct_module found: kernel tainted. dsplinkk: no version for struct_module found: kernel tainted. 1DSPLINK Module (1.40.05_p1) created on Date: Jun 11 2008 Time: 13:32:41 DSPLINK Module (1.40.05_p1) created on Date: Jun 11 2008 Time: 13:32:41 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
