Hi, > > 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. Ok. > Now, about this one. > I still think the wrapper is essentially the same, but the memory map > is different, right ? Yes, except that usbss related wrappers are completely new in ti81xx and They are not present in am35x or da8xx or davinci series platforms. > I mean, the programming model of the wrapper and > its features are the same, correct ? Yes. > So, how about you abstract the > memory map by passing the address offsets via driver_data ? This sounds to be a cleaner way of doing this. Let me work on this and propose something. > 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 ? Yes. > Just a few tweaks to support multiple musb instances. Except that the complete new usbss wrapper. > In that case, I'm not very keen on letting yet another very similar > file to be added. Let me collect all the details and discuss further on this. > 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. Ok. > > 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. Ok. Thanks, Ajay > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
