RE: [PATCH 6/6] usb: musb: Add support for ti81xx platform

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

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux