On Wed, Jun 18, 2014 at 9:17 AM, Barry G <mr.scada@xxxxxxxxx> wrote:
> NIP [c02b3f58] usb_gadget_map_request+0x118/0x1a4
> LR [c02bc68c] fsl_ep_queue+0xc4/0x19c
> Call Trace:
> [dfff7ea8] [c02bc68c] fsl_ep_queue+0xc4/0x19c
> [dfff7ec8] [c02b7514] composite_setup+0x1324/0x13e8
> [dfff7f20] [c02bd070] fsl_udc_irq+0x5cc/0xcbc
> [dfff7f78] [c004b42c] handle_irq_event_percpu+0x4c/0x150
> [dfff7fa8] [c004b594] handle_irq_event+0x64/0x94
> [dfff7fc0] [c004e7bc] handle_level_irq+0x138/0x15c
> [dfff7fd8] [c004b118] generic_handle_irq+0x38/0x50
> [dfff7fe8] [c000530c] __do_irq+0x44/0x58
> [dfff7ff0] [c000c510] call_do_irq+0x24/0x3c
> [c054fe98] [c0005510] do_IRQ+0x94/0xe0
> [c054fec0] [c000dca4] ret_from_except+0x0/0x14
> --- Exception: 501 at arch_cpu_idle+0x24/0x68
> LR = arch_cpu_idle+0x24/0x68
> [c054ff80] [c054e000] 0xc054e000 (unreliable)
> [c054ff88] [c0042dec] cpu_startup_entry+0x100/0x180
> [c054ffa8] [c0004068] rest_init+0x84/0x9c
> [c054ffc0] [c04edd18] start_kernel+0x334/0x348
> [c054fff0] [00003438] 0x3438
> Instruction dump:
> 7fff0034 57ffd97f 41a2000c 39600000 48000008 817e00bc 20070002 7c000110
> 7c0000d0 0f000000 3d20c056 3c854000 <816b0010> 8009f200 5484c9f4 54a5053e
> ---[ end trace 1e1b78a0b4f63fb8 ]---
Did some more digging into this. I found out that
usb_gadget_map_request is failing
in the dma_map_single call because get_dma_ops is returning NULL (and map_page
is offset 16 into dma_maps_ops hence the 0x10 offset).
Looks like nothing on the Freescale 83XX is calling set_dma_ops.
The following complete hacks give me USB gadget support:
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 150866b..50db4f7 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -87,6 +87,12 @@ static inline struct dma_map_ops
*get_dma_ops(struct device *dev)
if (unlikely(dev == NULL))
return NULL;
+ if (dev->archdata.dma_ops == NULL)
+ {
+ printk(KERN_ERR "Barry's Complete Hack triggered
%s\n", __func__);
+ return &dma_direct_ops;
+ }
+
return dev->archdata.dma_ops;
}
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index 28e4fc9..3385e8a 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2662,7 +2662,7 @@ MODULE_DEVICE_TABLE(platform, fsl_udc_devtype);
static struct platform_driver udc_driver = {
.remove = __exit_p(fsl_udc_remove),
/* Just for FSL i.mx SoC currently */
- .id_table = fsl_udc_devtype,
+ /* .id_table = fsl_udc_devtype, */
/* these suspend and resume are not usb suspend and resume */
.suspend = fsl_udc_suspend,
.resume = fsl_udc_resume,
Seems to me the right solution is making a patch to add the 83XX stuff
to the id_table
and finding the right place to set_dma_ops? I am fine doing the leg work of
creating/testing/submitting the patch providing that sounds right and people
can point me in the right direction :-)
Thanks,
Barry
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
