Hi, On Mon, Aug 29, 2011 at 03:16:55PM +0530, Gupta, Ajay Kumar wrote: > I have compiled the differences in the register map between am35x and > ti81xx and they are listed below. > > =========================================================================== > Register am35x [has one musb] ti81xx [two musb > interface] > =========================================================================== > REVISION 0x00 0x0000 -> for > USBSS > 0x1000 -> for > musb0 > 0x1800 -> for > musb1 > > ALL USBSS registers Not present Available from offset > 0x0000-0x0FFC > > USB_CTRL_REG 0x04 0x1014 -> for musb0 > 0x1814 -> for > musb1 > > USB_STAT_REG 0x08 0x1018 -> for musb0 > 0x1818 -> for > musb1 > > USB_EMULATION_REG 0x0c Not present > USB_AUTOREQ_REG 0x14 Not present > USB_SRP_FIX_TIME_REG 0x18 Not present > USB_TEARDOWN_REG 0x1c Not present > > USB_IRQ_MERGED_STATUS Present as part of 0x1020 -> for musb0 > EP_INTR_x or CORE_INTR_x 0x1820 -> for > musb1 > register in am35x but > at different offsets > > USB_IRQ_EOI Same as above 0x1024 -> for musb0 > 0x1824 -> for > musb1 > USB_IRQ_STATUS_RAW_0 Same as above 0x1028 -> for musb0 > 0x1828 -> for > musb1 > USB_IRQ_STATUS_RAW_1 Same as above 0x102c -> for musb0 > 0x182c -> for > musb1 > USB_IRQ_STATUS_0 Same as above 0x1030 -> for musb0 > 0x1830 -> for > musb1 > USB_IRQ_STATUS_1 Same as above 0x1034 -> for musb0 > 0x1834 -> for > musb1 > USB_IRQ_ENABLE_SET_0 Same as above 0x1038 -> for musb0 > 0x1838 -> for > musb1 > USB_IRQ_ENABLE_SET_1 Same as above 0x103c -> for musb0 > 0x183c -> for > musb1 > USB_IRQ_ENABLE_CLR_0 Same as above 0x1040 -> for musb0 > 0x1840 -> for > musb1 > USB_IRQ_ENABLE_CLR_1 Same as above 0x1044 -> for musb0 > 0x1844 -> for > musb1 > > EP_INTR_SRC_REG 0x20 Present as part > of > USB_IRQ_x > register in > ti81xx but at > different > offsets > EP_INTR_SRC_SET_REG 0x24 Same as above > EP_INTR_SRC_CLEAR_REG 0x28 Same as above > EP_INTR_MASK_REG 0x2c Same as > above > EP_INTR_MASK_SET_REG 0x30 Same as above > EP_INTR_MASK_CLEAR_REG 0x34 Same as > above > EP_INTR_SRC_MASKED_REG 0x38 Same as > above > CORE_INTR_SRC_REG 0x40 Same as > above > CORE _INTR_SRC_SET_REG 0x44 Same as > above > CORE _INTR_SRC_CLEAR_REG 0x48 Same as above > CORE _INTR_MASK_REG 0x4c Same as above > CORE _INTR_MASK_SET_REG 0x50 Same as > above > CORE _INTR_MASK_CLEAR_REG 0x54 Same as above > CORE _INTR_SRC_MASKED_REG 0x58 Same as above > USB_END_OF_INTR_REG 0x60 Same as above > > CPPI4.1 DMA > REVISION Not present 0x2000 > TEARDOWN FREE DESCRIPTOR Not present 0x2004 > EMULATION CONTROL Not present 0x2008 > > TxCh0 GLOBAL_CONFIG 0x1800 0x2800 > RxCh0 GLOBAL_CONFIG 0x1808 0x2808 > RxCh0 HOST_PKT_CFG_A 0x180c 0x280c > RxCh0 HOST_PKT_CFG_B 0x1810 0x2810 > Similarly for all Ch till Ch #29 > > INTD REVISION 0x3000 Not present > INTD EOI 0x3010 Not present > INTD EOI Interrupt vector 0x3014 Not present > INTD STATUS REG 0x3200-0x32FC Not present > QMGR REV 0x4000 0x4000 > > Rest of CPPI4.1 DMA register offset are same > ============================================================================ > > If you compare am35x and da8x then you would find that they are mostly same > and so should be merged. They both have one musb instances. > > Ti81xx has two musb interface and huge differences in register map as listed > Above so ti81xx should be in a separate file. > > Apart from this, am35 and da8x is not yet runtime pm compatible but the > current > patches supporting ti81x is runtime pm compliant. > > I think da8x and am35x files should be merged in a separate patch once they > are tested after the merge.
Sure, let's try to merge them as soon as possible. Now, about this one. I still think the wrapper is essentially the same, but the memory map is different, right ? I mean, the programming model of the wrapper and its features are the same, correct ? So, how about you abstract the memory map by passing the address offsets via driver_data ? The thing is that this is all duplicated code in a sense. Although the register map is different, the HW block is the same, isn't it ? Just a few tweaks to support multiple musb instances. In that case, I'm not very keen on letting yet another very similar file to be added. How about you add a very clean musb-dsps.c file (btw, at some point, I want all glue layers to have musb- prepended to them) which, for now, only handles this new chip, but it has memory map passed in via driver_data ? Then it should be very simple to convert davinci, da8xx and am35x to the new file. You will probably need to revisit the other device's TRM to see what needs to be abstracted or flaged somehow. What is board-specific and what is silicon-specific and that sort of thing. But it will be a very nice exercise and the output will be the deletion of three very similar files. -- balbi
signature.asc
Description: Digital signature
