Re: [bisected][regression] USB Ethernet Gadget Support - Freescale 8308

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux