HI
On Thu, May 30, 2013 at 09:12:11AM +0100, Lee Jones wrote:
> On Thu, 30 May 2013, Linus Walleij wrote:
>
> > On Wed, May 29, 2013 at 7:57 PM, Felipe Balbi wrote:
> > > On Wed, May 15, 2013 at 10:51:43AM +0100, Lee Jones wrote:
> > >> For all ux500 based platforms the maximum number of end-poi
On Thu, May 30, 2013 at 11:04:23AM +0200, Linus Walleij wrote:
> On Wed, May 15, 2013 at 11:51 AM, 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
DESC_JOB_IO_LEN is a generic macro which indicates the space required in
the descriptor for placing SEQIN/OUT commands, job descriptor header,
shared descriptor pointer. Moving it to descriptor construction file
which can be supposedly included by different algo offload files.
Change-Id: Ic8900990
When kernel is compiled with CONFIG_SLUB_DEBUG=y and
CRYPTO_MANAGER_DISABLE_TESTS=n, during kernel bootup, the kernel
reports error given below. The root cause is that in function
hash_digest_key(), for allocating descriptor, insufficient memory was
being allocated. The required number of descripto
On Wed, May 15, 2013 at 11:52 AM, 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 may as
On Wed, May 15, 2013 at 11:52 AM, Lee Jones wrote:
> Some platforms insist on obscure physical channel availability. 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 may as well
On Wed, May 15, 2013 at 11:52 AM, Lee Jones wrote:
> The DMA platform data is now empty due to some recent refactoring,
> so there is no longer a requirement to pass it though.
>
> Acked-by: Arnd Bergmann
> Signed-off-by: Lee Jones
Applied to dma40 branch, hm now I may get a conflict with all
On Wed, May 15, 2013 at 11:51 AM, 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 tailore
On Wed, May 15, 2013 at 11:51 AM, 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.
>
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> When a DMA client requests and configures a DMA channel, it requests
> data_width in Bytes. The DMA40 driver then swiftly converts it over to
> the necessary register bit value. Unfortunately, for any subsequent
> calculations we have to shift
On Wed, May 15, 2013 at 11:51 AM, 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
Patch applied with Vinod's ACK.
Yours,
Linus Walleij
--
To unsubscribe from this
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> We're now using the transfer direction definitions provided by the DMA
> sub-system, so the home-brew ones have become obsolete.
>
> Signed-off-by: Lee Jones
Tentatively applied, also missing Vinod's ACK on this, but it seems
it was implicitl
On Wed, May 15, 2013 at 11:51 AM, 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: Rabin Vin
On Wed, May 15, 2013 at 11:51 AM, 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.
>
> Signed-off-by: Lee Jones
Vinod, I'm lacking your ACK on this patch,
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> The aim is to make the code that little more readable.
>
> Acked-by: Vinod Koul
> Acked-by: Arnd Bergmann
> Reviewed-by: Linus Walleij
> Signed-off-by: Lee Jones
Patch applied to my ux500-dma40 branch.
Yours,
Linus Walleij
--
To unsubscri
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> As promised, now all devices which resided in u8500_of_init_devices()
> have been enabled for Device Tree, we can completely remove it.
>
> Acked-by: Fabio Baltieri
> Signed-off-by: Lee Jones
Applied on my ux500-dma40 branch.
And this is lo
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> Now the ux500-musb driver has been enabled for Device Tree, there is no
> requirement to register it from platform code.
>
> Acked-by: Fabio Baltieri
> Signed-off-by: Lee Jones
Patch applied to my ux500-dma40 branch on top of the musb
stuff.
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> The recently DT:ed MUSB driver will require clock-name by device-name
> look-up capability, until common clk has is properly supported by the
> ux500 platform.
>
> Acked-by: Linus Walleij
> Acked-by: Fabio Baltieri
> Signed-off-by: Lee Jones
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> This patch will allow ux500-musb to be probed and configured solely from
> configuration found in Device Tree.
>
> Cc: Felipe Balbi
> Cc: Rob Herring
> Cc: linux-...@vger.kernel.org
> Cc: devicetree-disc...@lists.ozlabs.org
> Acked-by: Linus
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> If we can ever get to a state where we can solely search for DMA channels
> by name, this will almost completely alleviate the requirement to pass
> copious amounts of information though platform data. Here we take the
> first step towards this
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> In its current state, the ux500-musb driver uses platform data pointers
> blindly with no prior checking. If no platform data pointer is passed
> this will Oops the kernel. In this patch we ensure platform data and
> board data are present prio
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> The dma_mask will always be the same as the coherent_dma_mask, so let's
> cut down on the platform_data burden and set it as such in the driver.
> This also saves us from supporting it separately when we come to enable
> this driver for Device
On Wed, May 15, 2013 at 11:51 AM, Lee Jones wrote:
> The MUSB HDRC configuration never changes between each of the ux500
> supported platforms, so there's little point passing it though platform
> data. If we set it in the driver instead, we can make good use of it
> when booting with either ATAG
On Thu, 30 May 2013, Linus Walleij wrote:
> On Wed, May 29, 2013 at 7:57 PM, Felipe Balbi wrote:
> > On Wed, May 15, 2013 at 10:51:43AM +0100, 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 relinqui
On Wed, May 29, 2013 at 7:57 PM, Felipe Balbi wrote:
> On Wed, May 15, 2013 at 10:51:43AM +0100, 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 remo
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
26 matches
Mail list logo
