Hi, On Thu, Jul 25, 2013 at 10:28:37AM -0500, Bin Liu wrote: > Sebastian, > > On Thu, Jul 25, 2013 at 10:16 AM, Sebastian Andrzej Siewior > <bige...@linutronix.de> wrote: > > On 07/25/2013 05:12 PM, Bin Liu wrote: > >> Sebastian, > > > > Hi Bin, > > > >>> Is it really there or was it never there and it has been added to TRM by > >>> accident? > >> The EOI register IS in the USB subsystem of AM33xx, but the SoC does > >> not use it because it uses level triggering for USB interrupt. > > > > I see. > > > >>>> But I am not sure if it is a good idea to remove eoi from the musb_dsps > >>>> driver. If the intension is to merge the support for other SoC, such as > >>>> AM35xx, AM18xx, then EOI handling might be still needed. I just don't > >>>> know > >>>> how those devices use EOI. > >>> > >>> If one of the architectures gets added which need an EOI then the offset > >>> can be 0 and the EOI will happen only if it is != 0. > >> This patch cleaned up the use of EOI. Do you mean EOI handling will be > >> added back with condition EOI offset != 0, when the support of new > >> device which uses EIO is added? > > > > That is my intention. > Then should something like EOI cleanup be added into the commit > message for better git log searching experience? I would think the EOI > cleanup is more important then variable renaming in this patch. Or > even better to separate the changes into two patches.
perhaps two separate patches would be best, indeed. At least it would make it simpler to track regressions. -- balbi
signature.asc
Description: Digital signature
