> > 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
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
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, 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: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: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: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, 15 May 2013, Randy Dunlap wrote:
> On 05/14/13 20:26, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20130514:
> >
>
> on x86_64:
>
> crypto/built-in.o: In function `chksum_digest':
> crct10dif.c:(.text+0x2789f): undefined reference to `crc_t10dif_generic'
> crypto/built-i
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
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 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-crypto@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:
> 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-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-crypto@vger.kernel.org
> Acked-by: Arnd Be
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:
> 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:
> 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:
> 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:
> 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 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:
> 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:
> 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:
> 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
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.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Per Forlin
Cc: Rabin Vincent
Signed-off-by: Lee Jones
---
drivers/dma/ste_dma40.
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-off-by: Lee Jones
---
arch/arm/mach-ux500/cpu-db8500.c |8 +
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 from platform data in the way of a look-up
table.
Signed-off
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-off-by: Lee Jones
---
arch/arm/mach-ux500/cpu-db8500.c |6
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 in d40_phy_cfg(), which is mostly runtime configuration
into
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
---
drivers/dma/ste_dma40.c| 14 +++---
drivers/dma/ste_dma40_ll.c |
'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
---
include/linux/platform_data/dma-ste-dma40.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/platform_
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
---
drivers/dma/ste_dma40.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/dma/ste_dma
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 are subsequently ignored by the driver, so we may
as well rem
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-crypto@vger.kernel.org
Acked-by: Arnd Bergmann
Acked-by: Ulf Hansson
Signed-off-by: Lee Jones
---
driver
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: Herbert Xu
Cc: David S. Miller
Cc: Andreas Westin
Cc: linux-crypto@
DMA channel configuration information should be setup in the driver.
The Ux500 Cryp driver now does this, so there's no need to send it
though here too.
Reviewed-by: Linus Walleij
Acked-by: Arnd Bergmann
Signed-off-by: Lee Jones
---
arch/arm/mach-ux500/board-mop500.c |8
1 file ch
The Cryp driver is currently silent and the Hash driver prints the
name of its probe function unnecessarily. Let's just put a nice
descriptive one-liner there instead.
Cc: Herbert Xu
Cc: David S. Miller
Cc: Andreas Westin
Cc: linux-crypto@vger.kernel.org
Acked-by: Arnd Bergmann
Reviewed-by: Li
These drivers are now operational and even use the latest common clk
and DMA APIs. There's no reason why we shouldn't start them up now.
Reviewed-by: Linus Walleij
Signed-off-by: Lee Jones
---
arch/arm/mach-ux500/board-mop500.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/m
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 when we come to enable the driver for Device Tree.
Cc: Felipe
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 ATAGs or Device Tree.
Cc: Felipe Balbi
Cc: linux-...@vger.kerne
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 prior to using them.
Cc: Felipe Balbi
Cc: linux-...@vger.kernel
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 Tree.
Cc: Felipe Balbi
Cc: linux-...@vger.kernel.org
Acked-
DMA channel configuration information should be setup in the driver.
The Ux500 Hash driver now does this, so there's no need to send it
though here too.
Acked-by: Arnd Bergmann
Signed-off-by: Lee Jones
---
arch/arm/mach-ux500/board-mop500.c |4
1 file changed, 4 deletions(-)
diff --gi
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-crypto@vger.kernel.org
Acked-by: Ulf Hansson
Acked-by: Arnd Bergmann
Signed-off-by: Lee Jones
---
driver
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 Device Tree either.
Signed-off-by: Lee Jones
---
arch/arm/ma
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 Walleij
Acked-by: Fabio Baltieri
Signed-off-by: Lee Jones
---
..
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
---
arch/arm/mach-ux500/cpu-db8500.c |1 +
1 file changed, 1
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
---
arch/arm/mach-ux500/cpu-db8500.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
di
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
---
arch/arm/mach-ux500/board-mop500-audio.c | 12 ++--
arch/arm/mach-ux500/board-mop500-sdi.c
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
---
drivers/dma/ste_dma40.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/dma/ste_dma4
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 Vincent
Signed-off-by: Lee Jones
---
drivers/dma/ste_dma40.c|
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 '1' by the bit pattern (1 << data_width)
times to make any se
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 Vincent
Signed-off-by: Lee Jones
---
drivers/dma/ste_dma40_ll.c |
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
---
drivers/dma/ste_dma40_ll.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a
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
---
arch/arm/mach-ux500/cpu-db8500.c |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-ux500/cpu-db8500.c
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 tailored. Fortunately, these platforms will be DT
only, so this chan
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
---
arch/arm/mach-ux500/cpu-db8500.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-
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 add the infrastructure.
Cc: Vinod Koul
Cc: Dan Williams
Cc
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 well add the infrastructure.
Cc: Vinod Koul
Cc: Dan William
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
---
include/linux/platform_data/dma-ste-dma40.h | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/include/linux/pl
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. The next step will be to enable Device Tree
complete with n
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: Herbert Xu
Cc: David S. Miller
Cc: Andreas Westin
Cc: linux-crypto@
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 device name matching, which will fail due to the
fact that Device
A great deal of these patches have now been applied through various trees.
We now need to grab the attention of the outstanding DMA clients (MUSB and
Crypto) to progress.
Also, Linus could probably do with a hand from Vinod for the remaining
dmaengine patches.
Thanks in advance.
Documentation/d
64 matches
Mail list logo
