[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130725153655.GA31835@radagast>
Date: Thu, 25 Jul 2013 18:37:15 +0300
From: Felipe Balbi <balbi@...com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC: Bin Liu <binmlist@...il.com>, <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 05:16:53PM +0200, Sebastian Andrzej Siewior 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.
right, I agree. If there are no users for the code, just delete it. If,
eventually, some platform comes to need it, then we add it *after* the
platform's base code is merged.
--
balbi
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists