On Tue, 14 May 2013, Sarah Sharp wrote:
> On Wed, May 15, 2013 at 05:41:12AM +0300, Xenia Ragiadakou wrote:
> > Hi Sarah, (again)
> >
> > Also I noticed that dma_set_coherent_mask() is not called somewhere,
> > which according to DMA-API-HOWTO.txt, means the even if the DMA mask
> > is set to 64
On Wed, 15 May 2013, Arnd Bergmann wrote:
> On Tuesday 14 May 2013, Alan Stern wrote:
> > The Kconfig settings for uhci-hcd are too permissive; they allow the
> > driver to be built without any bus-glue modules configured
> > (USB_UHCI_HCD enabled, PCI disabled, SPARC_LEON disabled, ARCH_VT8500
>
Hi Greg,
Here's my first set of fixes for v3.10-rc cycle. It's a bit large, but
considering the amount of work we got in the merge window, it looks reasonable.
Let me know if you want me to change anything
cheers
The following changes since commit f722406faae2d073cc1d01063d1123c35425939e:
Li
These patches add support to handle requests which spawn into several TDs.
Michael Grzeschik (2):
usb: chipidea: udc: manage dynamic amount of tds with an linked list
usb: chipidea: udc: add multiple td support to hardware_{en,de}queue
drivers/usb/chipidea/ci.h| 1 +
drivers/usb/chipid
From: Michael Grzeschik
Instead of having a limited number of usable tds in the udc we use a
linked list to support dynamic amount of needed tds for all special
gadget types. This improves throughput.
Signed-off-by: Michael Grzeschik
Reviewed-by: Felipe Balbi
---
drivers/usb/chipidea/debug.c
From: Michael Grzeschik
This patch removes the restriction of having a limited amount of only
four active tds on one endpoint. We use the linked list implementation
to manage all tds which get added and removed by hardware_{en,de}queue.
The removal of this restriction adds the driver to run into
On 05/08/2013 11:07 AM, Alexander Shishkin wrote:
> Jiri Slaby writes:
>
>> From: Jeff Mahoney
>>
>> The chipidea driver currently has needless ifneq rules in the makefile
>> for things that should be config options.
>
> Please elaborate on the "should be" part.
>
>> This can be problematic,
>
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> During the initial setup of a logical channel, it is necessary to unmask
> the GIM in order to receive generated terminal count and error interrupts.
> We're separating out this required code so it will be possible to move
> the remaining code
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> All configuration left in d40_phy_cfg() is runtime configurable and
> there is already a call into it from d40_runtime_config(), so let's
> rely on that.
>
> Acked-by: Vinod Koul
> Acked-by: Arnd Bergmann
> Signed-off-by: Lee Jones
You forg
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> Using the dmaengine API, allocating and configuring a channel are two
> separate actions. Here we're removing logical channel configuration from
> the channel allocating routines.
This commit message is also incorrect, but I amended it.
Besid
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> It was required to pass DMA channel configuration information to the
> UART driver before the new DMA API was in place. Now that it is, and
> is fully compatible with Device Tree we can stop doing that.
>
> Reviewed-by: Linus Walleij
> Signed-
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> It was required to pass DMA channel configuration information to the
> MMC driver before the new DMA API was in place. Now that it is, and
> is fully compatible with Device Tree we can stop doing that.
>
> Reviewed-by: Linus Walleij
> Signed-o
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> Addresses are passed in from the client's driver via the invocation of
> dmaengine_slave_config(), so there's no need to fetch them from platform
> data too, hardwired or otherwise. This is a great step forward, as it
> elevates a large burden
On Wed, May 15, 2013 at 06:25:47PM +0300, Felipe Balbi wrote:
> Hi Greg,
>
> Here's my first set of fixes for v3.10-rc cycle. It's a bit large, but
> considering the amount of work we got in the merge window, it looks
> reasonable.
>
> Let me know if you want me to change anything
>
> cheers
>
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> Addresses are now stored in local data structures and are easy to
> obtain, thus a specialist function used to fetch them is now surplus
> to requirement.
>
> Signed-off-by: Lee Jones
Patch tentatively applied, waiting for Vinod's ACK.
Yours
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> Now DMA DT bindings exist and are in use by he MMC and UART drivers, it
> should be possible to remove them from the auxdata structure. However,
> after doing so the drivers fail. Common clk is still reliant on the
> dev_name() call to do devic
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> DMA addresses are now passed as part of the dmaengine API by invoking
> dmaengine_slave_config(). So there's no requirement for the DMA40
> driver to look them up in a table provided by platform data. This
> method does not fit in well using De
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> 'struct stedma40_half_channel_info's header comment says that it's
> called 'struct stedma40_chan_cfg'. Let's straighten that out.
>
> Signed-off-by: Lee Jones
Patch tentatively applied waiting for Vinod's ACK.
Yours,
Linus Walleij
--
To uns
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> If we fail to prepare the ux500-hash clock before enabling it the
> platform will fail to boot. Here we insure this happens.
>
> Cc: Herbert Xu
> Cc: David S. Miller
> Cc: Andreas Westin
> Cc: linux-cry...@vger.kernel.org
> Acked-by: Arnd Be
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> The DMA controller currently takes configuration information from
> information passed though dma_channel_request(), but it shouldn't.
> Using the API, the DMA channel should only be configured during
> a dma_slave_config() call.
>
> Cc: Herber
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> If we fail to prepare the ux500-cryp clock before enabling it the
> platform will fail to boot. Here we insure this happens.
>
> Cc: Herbert Xu
> Cc: David S. Miller
> Cc: Andreas Westin
> Cc: linux-cry...@vger.kernel.org
> Acked-by: Ulf Han
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> DMA data width and packet size information is only required at channel
> configuration time. Any information passed from platform data is passed
> directly to the DMA40 driver to use during channel allocation, but these
> pieces of information
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> For all ux500 based platforms the maximum number of end-points are used.
> Move this knowledge into the driver so we can relinquish the burden from
> platform data. This also removes quite a bit of complexity from the driver
> and will aid us w
On Wed, May 15, 2013 at 12:55:58PM -0400, Greg KH wrote:
> On Wed, May 15, 2013 at 06:25:47PM +0300, Felipe Balbi wrote:
> > Hi Greg,
> >
> > Here's my first set of fixes for v3.10-rc cycle. It's a bit large, but
> > considering the amount of work we got in the merge window, it looks
> > reasonab
Hi Paul,
On Wed, May 08, 2013 at 10:46:29PM +0200, Matthijs Kooijman wrote:
> Paul wrote:
> > Hmm. Is it kosher to override these in a driver and force DMA to be
> > enabled?
>
> Apparently, since a lot of drivers do it like this. This particular code
> was taken from the ehci-platform driver. Se
Hello Linus,
On Wed, May 15, 2013 at 07:18:01PM +0200, Linus Walleij wrote:
> On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
>
> > For all ux500 based platforms the maximum number of end-points are used.
> > Move this knowledge into the driver so we can relinquish the burden from
> > platfor
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Wednesday, May 15, 2013 11:48 AM
>
> > Paul wrote:
> > > Hmm. Is it kosher to override these in a driver and force DMA to be
> > > enabled?
> >
> > Apparently, since a lot of drivers do it like this. This particular code
> > was taken fr
Hi Paul,
> No, seems like other folks think it's OK, so I'm fine with it.
Great.
> I'll ack the patches and send them on once Greg starts taking staging
> patches again.
Forgive my ignorance here, but does that mean it'll wait until 3.11, or
can it still be included in 3.10? I'd like to get at le
> Does this patch fix the control transfer data stage issue? Please break
> this into a bug fix for that, with your refactoring on top of that. We
> need to backport the bug fix to the stable kernels, and queue the
> refactoring for 3.11.
I don't think there is really any practial adverse effect
On Wed, May 15, 2013 at 10:37:00AM -0400, Alan Stern wrote:
> On Tue, 14 May 2013, Sarah Sharp wrote:
> > We do allocate memory using DMA pools, and we do want 64-bit context
> > addresses if the xHCI host controller can handle it.
> >
> > The xHCI driver calls dma_set_mask, but not dma_set_cohere
On Wed, May 15, 2013 at 11:44:39AM +0200, Michael Grzeschik wrote:
> Hi Peter,
>
> On Wed, May 15, 2013 at 02:07:44AM +, Chen Peter-B29397 wrote:
> >
> > >
> > > This patch adds iso endpoint support to the device controller.
> > > It makes use of the multiplication bits in the maxpacket fie
On Wed, May 15, 2013 at 01:34:31PM +0300, Alexander Shishkin wrote:
> Peter Chen writes:
>
> > Hi Michael & Marc,
> >
> > Recently, I have worked at i.mx USB loadable module support for chipidea
> > driver,
> > it needs to write non-core register during the ci13xxx_imx remove process,
> > but c
On Wed, May 15, 2013 at 10:51:59AM +0100, Lee Jones wrote:
> At this moment in time the memcpy channels which can be used by the D40
> are fixed, as each supported platform in Mainline uses the same ones.
> However, platforms do exist which don't follow this convention, so
> these will need to be t
On Wed, May 15, 2013 at 10:51:56AM +0100, Lee Jones wrote:
> The aim is to make the code that little more readable.
>
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Signed-off-by: Lee Jones
Acked-by: Vinod Koul
Hopefully all the BIT conversion in the driver are d
On Wed, May 15, 2013 at 10:51:54AM +0100, Lee Jones wrote:
> STEDMA40_*_TO_* direction definitions are identical in all but name to
> the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not
> duplicating such things.
>
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Ra
On Wed, May 15, 2013 at 10:51:58AM +0100, Lee Jones wrote:
> Unsure of the author's intentions, rather than just removing the nop,
> we're replacing it with a comment containing the possible intention
> of the statement OR:ing with 0.
Would be worthwhile to check w/ Linus W on this (or check whom t
On Wed, May 15, 2013 at 10:52:02AM +0100, Lee Jones wrote:
> Some platforms have channels which are not available for normal use.
> This information is currently passed though platform data in internal
> BSP kernels. Once those platforms land, they'll need to configure them
> appropriately, so we m
On Wed, 15 May 2013, Linus Walleij wrote:
> On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
>
> > If we fail to prepare the ux500-hash clock before enabling it the
> > platform will fail to boot. Here we insure this happens.
> >
> > Cc: Herbert Xu
> > Cc: David S. Miller
> > Cc: Andreas Wes
> > Unsure of the author's intentions, rather than just removing the nop,
> > we're replacing it with a comment containing the possible intention
> > of the statement OR:ing with 0.
> Would be worthwhile to check w/ Linus W on this (or check whom to blame)
I did already. It was his idea to place t
101 - 139 of 139 matches
Mail list logo
