[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130725161120.GC31835@radagast>
Date: Thu, 25 Jul 2013 19:11:20 +0300
From: Felipe Balbi <balbi@...com>
To: Bin Liu <binmlist@...il.com>
CC: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<balbi@...com>, <george.cherian@...com>
Subject: Re: [PATCH 06/16] usb: musb: dsps: rename ti81xx_driver_data to
am33xx_driver_data
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
> <bigeasy@...utronix.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
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists