Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
On Wed, May 15, 2013 at 10:14 PM, Fabio Baltieri wrote: > 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 >> > 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 Balbi >> > Cc: linux-...@vger.kernel.org >> > Acked-by: Linus Walleij >> > Acked-by: Fabio Baltieri >> > Signed-off-by: Lee Jones >> >> I guess this stuff is dependent on the stuff Fabio has recently sent to >> Felipe for the ux500 musb DMA so these musb patches should >> primarily go through his tree. > > Not really, I only sent some coding style fix for the dma driver, as > almost all of my work was in the usb phy files. I also checked my > latest series against Lee's tree and the two seems to merge without any > conflict, so as far as I'm concerned it's really up to you and Felipe. OK so Felipe can merge these smallish patches to musb, fine... The other (DMA) stuff needs to be merged together with the rest of the DMA40 series, so here basically Felipe needs an indication if he can ACK it so I merge it through ARM SoC without colissions and it sounds like we can make the assumption that this will work. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for May 15 (crypto /crct10dif)
2013/5/17 Tim Chen :
> On Thu, 2013-05-16 at 09:59 -0700, Tim Chen wrote:
>> On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
>> > On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou
>> > wrote:
>> > > --- a/crypto/Kconfig
>> > > +++ b/crypto/Kconfig
>> > > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
>> > >
>> > > config CRYPTO_CRCT10DIF
>> > > tristate "CRCT10DIF algorithm"
>> > > + depends on CRC_T10DIF
>> >
>> > This is a library symbol, so "select CRC_T10DIF"?
>> >
>> > > select CRYPTO_HASH
>> > > help
>> > > CRC T10 Data Integrity Field computation is being cast as
>> >
>> > Gr{oetje,eeting}s,
>> >
>> > Geert
>> >
>>
>> This is the fix I think that will resolve the build issues. The generic
>> crc-t10dif transform depends on the library function crc_t10dif_generic
>> in lib/crc-t10dif.c, so "depends on CRC_T10DIF" for CRYPTO_CRCT10DIF is
>> needed.
>>
>> Now for CRC_T10DIF, we should use select CRYPTO_HASH, so it can try to
>> allocate a T10DIF transform if it is available. If not, it will simply
>> use the crc_t10dif_generic function. Loading the
>> generic t10dif crypto transform is not mandatory for the library
>> function crc_t10dif.
>>
>> Thanks for catching the issues.
>>
>> Tim
>>
cool.
>
> Need to also add select CRYPTO for CRC_T10DIF. Updated fix below:
>
>
> Signed-off-by: Tim Chen
> ---
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index d1ca631..015df24 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL
> config CRYPTO_CRCT10DIF
> tristate "CRCT10DIF algorithm"
> select CRYPTO_HASH
> + depends on CRC_T10DIF
> help
> CRC T10 Data Integrity Field computation is being cast as
> a crypto transform. This allows for faster crc t10 diff
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 0cee056..6407793 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -63,7 +63,8 @@ config CRC16
>
> config CRC_T10DIF
> tristate "CRC calculation for the T10 Data Integrity Field"
> - select CRYPTO_CRCT10DIF
> + select CRYPTO
> + select CRYPTO_HASH
> help
> This option is only needed if a module that's not in the
> kernel tree needs to calculate CRC checks for use with the
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for May 15 (crypto /crct10dif)
2013/5/16 Geert Uytterhoeven :
> On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou wrote:
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
>>
>> config CRYPTO_CRCT10DIF
>> tristate "CRCT10DIF algorithm"
>> + depends on CRC_T10DIF
>
> This is a library symbol, so "select CRC_T10DIF"?
En.. make sense, Thanks.
Xiong
>
>> select CRYPTO_HASH
>> help
>> CRC T10 Data Integrity Field computation is being cast as
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for May 15 (crypto /crct10dif)
On Thu, 2013-05-16 at 09:59 -0700, Tim Chen wrote:
> On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
> > On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou wrote:
> > > --- a/crypto/Kconfig
> > > +++ b/crypto/Kconfig
> > > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
> > >
> > > config CRYPTO_CRCT10DIF
> > > tristate "CRCT10DIF algorithm"
> > > + depends on CRC_T10DIF
> >
> > This is a library symbol, so "select CRC_T10DIF"?
> >
> > > select CRYPTO_HASH
> > > help
> > > CRC T10 Data Integrity Field computation is being cast as
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
>
> This is the fix I think that will resolve the build issues. The generic
> crc-t10dif transform depends on the library function crc_t10dif_generic
> in lib/crc-t10dif.c, so "depends on CRC_T10DIF" for CRYPTO_CRCT10DIF is
> needed.
>
> Now for CRC_T10DIF, we should use select CRYPTO_HASH, so it can try to
> allocate a T10DIF transform if it is available. If not, it will simply
> use the crc_t10dif_generic function. Loading the
> generic t10dif crypto transform is not mandatory for the library
> function crc_t10dif.
>
> Thanks for catching the issues.
>
> Tim
>
Need to also add select CRYPTO for CRC_T10DIF. Updated fix below:
Signed-off-by: Tim Chen
---
diff --git a/crypto/Kconfig b/crypto/Kconfig
index d1ca631..015df24 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL
config CRYPTO_CRCT10DIF
tristate "CRCT10DIF algorithm"
select CRYPTO_HASH
+ depends on CRC_T10DIF
help
CRC T10 Data Integrity Field computation is being cast as
a crypto transform. This allows for faster crc t10 diff
diff --git a/lib/Kconfig b/lib/Kconfig
index 0cee056..6407793 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -63,7 +63,8 @@ config CRC16
config CRC_T10DIF
tristate "CRC calculation for the T10 Data Integrity Field"
- select CRYPTO_CRCT10DIF
+ select CRYPTO
+ select CRYPTO_HASH
help
This option is only needed if a module that's not in the
kernel tree needs to calculate CRC checks for use with the
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for May 15 (crypto /crct10dif)
On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
> On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou wrote:
> > --- a/crypto/Kconfig
> > +++ b/crypto/Kconfig
> > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
> >
> > config CRYPTO_CRCT10DIF
> > tristate "CRCT10DIF algorithm"
> > + depends on CRC_T10DIF
>
> This is a library symbol, so "select CRC_T10DIF"?
>
> > select CRYPTO_HASH
> > help
> > CRC T10 Data Integrity Field computation is being cast as
>
> Gr{oetje,eeting}s,
>
> Geert
>
This is the fix I think that will resolve the build issues. The generic
crc-t10dif transform depends on the library function crc_t10dif_generic
in lib/crc-t10dif.c, so "depends on CRC_T10DIF" for CRYPTO_CRCT10DIF is
needed.
Now for CRC_T10DIF, we should use select CRYPTO_HASH, so it can try to
allocate a T10DIF transform if it is available. If not, it will simply
use the crc_t10dif_generic function. Loading the
generic t10dif crypto transform is not mandatory for the library
function crc_t10dif.
Thanks for catching the issues.
Tim
Signed-off-by: Tim Chen
---
diff --git a/crypto/Kconfig b/crypto/Kconfig
index d1ca631..015df24 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL
config CRYPTO_CRCT10DIF
tristate "CRCT10DIF algorithm"
select CRYPTO_HASH
+ depends on CRC_T10DIF
help
CRC T10 Data Integrity Field computation is being cast as
a crypto transform. This allows for faster crc t10 diff
diff --git a/lib/Kconfig b/lib/Kconfig
index 0cee056..e6ad2e4 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -63,7 +63,7 @@ config CRC16
config CRC_T10DIF
tristate "CRC calculation for the T10 Data Integrity Field"
- select CRYPTO_CRCT10DIF
+ select CRYPTO_HASH
help
This option is only needed if a module that's not in the
kernel tree needs to calculate CRC checks for use with the
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for May 15 (crypto /crct10dif)
On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
> On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou wrote:
> > --- a/crypto/Kconfig
> > +++ b/crypto/Kconfig
> > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
> >
> > config CRYPTO_CRCT10DIF
> > tristate "CRCT10DIF algorithm"
> > + depends on CRC_T10DIF
>
> This is a library symbol, so "select CRC_T10DIF"?
>
I think "depends on" CRC_T10DIF is okay. This generic transform is not
needed if we are not using the T10-DIF library. It is meant for
wrapping the library call to t10-dif as a crypto transform.
> > select CRYPTO_HASH
> > help
> > CRC T10 Data Integrity Field computation is being cast as
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Oops on 3.10-rc1 related to ssh256_ssse3
Hello, I have an encrypted disc (dm-crypt, type LUKS1, ssh256 as hash algorithm). I have an Intel Core i5 M450 that supports ssse3. Find below the output from netconsole with the oops. The last warning appeared when I restart the pc using the magic sysrq key combination REISUB. I have the same problem with a different laptop with an AMD E-450 APU. If you need further information, feel free to ask. Best regards, Julian Wollrath [3.647071] device-mapper: uevent: version 1.0.3 [3.647245] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: dm-de...@redhat.com [ 11.619603] sha256_ssse3: Using SSSE3 optimized SHA-256 implementation [ 12.131483] BUG: unable to handle kernel paging request at 8800bb593000 [ 12.131848] IP: [] loop0+0x27/0x44 [sha256_ssse3] [ 12.132032] PGD 1a32067 PUD 1a35067 PMD 1a36067 PTE 0 [ 12.132427] Oops: [#1] SMP [ 12.132670] Modules linked in: sha256_ssse3(+) sha256_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common cbc dm_crypt dm_mod netconsole sg sr_mod sd_mod cdrom crc_t10dif crc32c_intel microcode ahci libahci ehci_pci ehci_hcd libata scsi_mod r8169 mii usbcore usb_common thermal thermal_sys [ 12.135396] CPU: 3 PID: 276 Comm: cryptomgr_test Not tainted 3.10.0-rc1+ #2 [ 12.135559] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 10/25/2010 [ 12.135720] task: 880037572090 ti: 8800b66b6000 task.ti: 8800b66b6000 [ 12.135836] RIP: 0010:[] [] loop0+0x27/0x44 [sha256_ssse3] [ 12.136032] RSP: 0018:8800b66b7af0 EFLAGS: 00010287 [ 12.136130] RAX: a186fc15 RBX: 704bb939 RCX: d1b791ec [ 12.136232] RDX: 1fd2088a RSI: 880037a97ee8 RDI: 8800bb592fc8 [ 12.136334] RBP: a016f000 R08: 52a5c3c8 R09: 5db427ef [ 12.136439] R10: b80a833e R11: 29c53567 R12: 8800b66b7b08 [ 12.136543] R13: 3158a213 R14: c7fc368e R15: 01008012 [ 12.136647] FS: () GS:8800bb18() knlGS: [ 12.136763] CS: 0010 DS: ES: CR0: 80050033 [ 12.136863] CR2: 8800bb593000 CR3: 0180b000 CR4: 07e0 [ 12.136964] DR0: DR1: DR2: [ 12.137066] DR3: DR6: 0ff0 DR7: 0400 [ 12.137167] Stack: [ 12.137257] 880108c634c8 8800bb592f88 6033fb357b8c96fd c5e119eaebeb38a3 [ 12.137668] 880037a97f08 8800b66b7b80 0008 0008 [ 12.138077] 880037a97ed0 a016dc4e 880001496ae5 880037a97ee0 [ 12.138484] Call Trace: [ 12.138580] [] ? __sha256_ssse3_update+0x5e/0xe0 [sha256_ssse3] [ 12.138701] [] ? sha256_ssse3_final+0x145/0x1ec [sha256_ssse3] [ 12.138825] [] ? shash_ahash_finup+0x32/0x80 [ 12.138931] [] ? test_hash+0x383/0x6b0 [ 12.139034] [] ? crypto_mod_get+0x10/0x30 [ 12.139141] [] ? __kmalloc+0x1c6/0x1f0 [ 12.139243] [] ? __crypto_alg_lookup+0xac/0xf0 [ 12.139344] [] ? crypto_create_tfm+0x48/0xd0 [ 12.139445] [] ? crypto_init_shash_ops_async+0x2d/0xd0 [ 12.139548] [] ? alg_test_hash+0x43/0xa0 [ 12.139650] [] ? alg_test+0x9b/0x230 [ 12.139753] [] ? __schedule+0x271/0x650 [ 12.139856] [] ? cryptomgr_probe+0xb0/0xb0 [ 12.139954] [] ? cryptomgr_test+0x38/0x40 [ 12.140058] [] ? kthread+0xaf/0xc0 [ 12.140219] [] ? kthread_create_on_node+0x110/0x110 [ 12.140382] [] ? ret_from_fork+0x7c/0xb0 [ 12.140482] [] ? kthread_create_on_node+0x110/0x110 [ 12.140585] Code: c4 40 00 00 48 8d 2d 9d 3f 00 00 f3 0f 6f 27 66 41 0f 38 00 e4 f3 0f 6f 6f 10 66 41 0f 38 00 ec f3 0f 6f 77 20 66 41 0f 38 00 f4 0f 6f 7f 30 66 41 0f 38 00 fc 48 89 7c 24 08 48 c7 c7 03 00 [ 12.145708] RIP [] loop0+0x27/0x44 [sha256_ssse3] [ 12.145885] RSP [ 12.145979] CR2: 8800bb593000 [ 12.146075] ---[ end trace 0382cf30f3465fd1 ]--- [ 12.146173] note: cryptomgr_test[276] exited with preempt_count 1 [ 12.146347] BUG: scheduling while atomic: cryptomgr_test/276/0x1001 [ 12.146485] Modules linked in: sha256_ssse3(+) sha256_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common cbc dm_crypt dm_mod netconsole sg sr_mod sd_mod cdrom crc_t10dif crc32c_intel microcode ahci libahci ehci_pci ehci_hcd libata scsi_mod r8169 mii usbcore usb_common thermal thermal_sys [ 12.150126] CPU: 3 PID: 276 Comm: cryptomgr_test Tainted: G D 3.10.0-rc1+ #2 [ 12.150282] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 10/25/2010 [ 12.150428] 8141eaf7 8141bca7 8142167a 0035 [ 12.151034] 0046 8800b66b7fd8 8800b66b7fd8 8800b66b7fd8 [ 12.151610] 880037572090 8800b66b6000 8800375725d0 0046 [ 12.152215] Call Trace: [ 12.152352] [] ? dump_stack+0xc/0x15 [ 12.152496] [] ? __sched
[PATCH 5/6] crypto: ux500/cryp - Enable DT probing of the driver
By providing an OF match table with a suitable compatible string, we
can ensure the ux500-crypt driver is probed by supplying an associated
DT node in a given platform's Device Tree.
Cc: Herbert Xu
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/crypto/ux500/cryp/cryp_core.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c
b/drivers/crypto/ux500/cryp/cryp_core.c
index 4f8b11a..d3940b7 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -1772,6 +1772,11 @@ static int ux500_cryp_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(ux500_cryp_pm, ux500_cryp_suspend, ux500_cryp_resume);
+static const struct of_device_id ux500_cryp_match[] = {
+{ .compatible = "stericsson,ux500-cryp" },
+{ },
+};
+
static struct platform_driver cryp_driver = {
.probe = ux500_cryp_probe,
.remove = ux500_cryp_remove,
@@ -1779,6 +1784,7 @@ static struct platform_driver cryp_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "cryp1",
+ .of_match_table = ux500_cryp_match,
.pm= &ux500_cryp_pm,
}
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] crypto: ux500/hash - Enable DT probing of the driver
By providing an OF match table with a suitable compatible string, we
can ensure the ux500-hasht driver is probed by supplying an associated
DT node in a given platform's Device Tree.
Cc: Herbert Xu
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/crypto/ux500/hash/hash_core.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/ux500/hash/hash_core.c
b/drivers/crypto/ux500/hash/hash_core.c
index 9ca6fbb..f89fe8a 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -1981,6 +1981,11 @@ static int ux500_hash_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(ux500_hash_pm, ux500_hash_suspend, ux500_hash_resume);
+static const struct of_device_id ux500_hash_match[] = {
+{ .compatible = "stericsson,ux500-hash" },
+{ },
+};
+
static struct platform_driver hash_driver = {
.probe = ux500_hash_probe,
.remove = ux500_hash_remove,
@@ -1988,6 +1993,7 @@ static struct platform_driver hash_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "hash1",
+ .of_match_table = ux500_hash_match,
.pm= &ux500_hash_pm,
}
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
On Thu, 16 May 2013, Vinod Koul wrote: > On Thu, May 16, 2013 at 08:25:57AM +0100, Lee Jones wrote: > > On Thu, 16 May 2013, Vinod Koul wrote: > > > > > On Wed, May 15, 2013 at 10:51:25AM +0100, 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 > > > That needs up update! > > > > Ah, where did I get that from that? > > > > Was that my mistake, or was this in the MAINTAINERS file? > Certainly not in MAINTAINERS file :) My bad then, sorry. Linus, Would you be kind enough to fix it please, as it's in your tree now. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value
On Thu, May 16, 2013 at 08:35:53AM +0100, Lee Jones wrote:
> On Thu, 16 May 2013, Vinod Koul wrote:
>
> > On Wed, May 15, 2013 at 10:51:57AM +0100, Lee Jones wrote:
> > > +u8 d40_width_to_bits(enum dma_slave_buswidth width)
> > > +{
> > > + if (width == DMA_SLAVE_BUSWIDTH_1_BYTE)
> > > + return STEDMA40_ESIZE_8_BIT;
> > > + else if (width == DMA_SLAVE_BUSWIDTH_2_BYTES)
> > > + return STEDMA40_ESIZE_16_BIT;
> > > + else if (width == DMA_SLAVE_BUSWIDTH_8_BYTES)
> > > + return STEDMA40_ESIZE_64_BIT;
> > > + else
> > > + return STEDMA40_ESIZE_32_BIT;
> > > +}
> > > +
> > Switch looks better for this and how about
> > return fls(width);
> >
> > as your defines are 0...3 and dmaengine define 1,2,..8 for same thing
> > then you can also get rid of STEDMA40_XXX_WIDTH macros!
>
> I like it.
>
> Will you let me do it as a follow-up patch?
Okay...
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
On Thu, May 16, 2013 at 08:25:57AM +0100, Lee Jones wrote: > On Thu, 16 May 2013, Vinod Koul wrote: > > > On Wed, May 15, 2013 at 10:51:25AM +0100, 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 > > That needs up update! > > Ah, where did I get that from that? > > Was that my mistake, or was this in the MAINTAINERS file? Certainly not in MAINTAINERS file :) -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value
On Thu, 16 May 2013, Vinod Koul wrote:
> On Wed, May 15, 2013 at 10:51:57AM +0100, 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 '1' by the bit pattern (1 << data_width)
> > times to make any sense of it.
> >
> > This patch flips the semantics on its head and only converts the value
> > to its respective register bit pattern when writing to registers. This
> > way we can use the true data_width (in Bytes) value.
> >
> > Cc: Vinod Koul
> > Cc: Dan Williams
> > Cc: Per Forlin
> > Cc: Rabin Vincent
> > Signed-off-by: Lee Jones
> > ---
>
> > @@ -2804,14 +2781,24 @@ static int d40_set_runtime_config(struct dma_chan
> > *chan,
> > src_maxburst = dst_maxburst * dst_addr_width / src_addr_width;
> > }
> >
> > + /* Only valid widths are; 1, 2, 4 and 8. */
> > + if (src_addr_width <= DMA_SLAVE_BUSWIDTH_UNDEFINED ||
> > + src_addr_width > DMA_SLAVE_BUSWIDTH_8_BYTES ||
> > + dst_addr_width <= DMA_SLAVE_BUSWIDTH_UNDEFINED ||
> > + dst_addr_width > DMA_SLAVE_BUSWIDTH_8_BYTES ||
> > + ((src_addr_width > 1) && (src_addr_width & 1)) ||
> > + ((dst_addr_width > 1) && (dst_addr_width & 1)))
> > + return -EINVAL;
> how about a simple macro to check above..
I thought about it, but as this code appears only once, I considered
it to be unnecessary abstraction.
> > +
> > + cfg->src_info.data_width = src_addr_width;
> > + cfg->dst_info.data_width = dst_addr_width;
> > +
> > ret = dma40_config_to_halfchannel(d40c, &cfg->src_info,
> > - src_addr_width,
> > src_maxburst);
> > if (ret)
> > return ret;
> >
> > ret = dma40_config_to_halfchannel(d40c, &cfg->dst_info,
> > - dst_addr_width,
> > dst_maxburst);
> > if (ret)
> > return ret;
> > diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
> > index 5ddd724..a035dfe 100644
> > --- a/drivers/dma/ste_dma40_ll.c
> > +++ b/drivers/dma/ste_dma40_ll.c
> > @@ -10,6 +10,18 @@
> >
> > #include "ste_dma40_ll.h"
> >
> > +u8 d40_width_to_bits(enum dma_slave_buswidth width)
> > +{
> > + if (width == DMA_SLAVE_BUSWIDTH_1_BYTE)
> > + return STEDMA40_ESIZE_8_BIT;
> > + else if (width == DMA_SLAVE_BUSWIDTH_2_BYTES)
> > + return STEDMA40_ESIZE_16_BIT;
> > + else if (width == DMA_SLAVE_BUSWIDTH_8_BYTES)
> > + return STEDMA40_ESIZE_64_BIT;
> > + else
> > + return STEDMA40_ESIZE_32_BIT;
> > +}
> > +
> Switch looks better for this and how about
> return fls(width);
>
> as your defines are 0...3 and dmaengine define 1,2,..8 for same thing
> then you can also get rid of STEDMA40_XXX_WIDTH macros!
I like it.
Will you let me do it as a follow-up patch?
> > @@ -70,13 +70,6 @@ enum stedma40_flow_ctrl {
> > STEDMA40_FLOW_CTRL,
> > };
> >
> > -enum stedma40_periph_data_width {
> > - STEDMA40_BYTE_WIDTH = STEDMA40_ESIZE_8_BIT,
> > - STEDMA40_HALFWORD_WIDTH = STEDMA40_ESIZE_16_BIT,
> > - STEDMA40_WORD_WIDTH = STEDMA40_ESIZE_32_BIT,
> > - STEDMA40_DOUBLEWORD_WIDTH = STEDMA40_ESIZE_64_BIT
> > -};
> nice
>
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/39] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
On Thu, 16 May 2013, Vinod Koul wrote: > On Wed, May 15, 2013 at 06:29:51PM +0200, Linus Walleij wrote: > > 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 in d40_phy_cfg(), which is mostly runtime configuration > > > into the runtime_config() routine. > > > > > > Cc: Vinod Koul > > > Cc: Dan Williams > > > Cc: Per Forlin > > > Cc: Rabin Vincent > > > Acked-by: Arnd Bergmann > > > Signed-off-by: Lee Jones > > > > Tentatively applied to my ux500-dma40 branch. > > > > This lacks an ACK from Vinod... > Acked-by: Vinod Koul > > > > I cannot get any of this stack of patches up to ARM SoC > > before I have Vinod's ACK on all hitting drivers/dma/* > Wip ... :) Nice! :) -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
On Thu, 16 May 2013, Vinod Koul wrote:
> On Wed, May 15, 2013 at 10:51:25AM +0100, 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
> That needs up update!
Ah, where did I get that from that?
Was that my mistake, or was this in the MAINTAINERS file?
> > Acked-by: Arnd Bergmann
> > Signed-off-by: Lee Jones
> > ---
> > drivers/dma/ste_dma40.c| 14 +++---
> > drivers/dma/ste_dma40_ll.c | 101
> > +---
> > drivers/dma/ste_dma40_ll.h |3 +-
> > 3 files changed, 58 insertions(+), 60 deletions(-)
> >
> > diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> > index 759293e..b7fe46b 100644
> > --- a/drivers/dma/ste_dma40.c
> > +++ b/drivers/dma/ste_dma40.c
> > @@ -2043,6 +2043,14 @@ static int d40_config_memcpy(struct d40_chan *d40c)
> > } else if (dma_has_cap(DMA_MEMCPY, cap) &&
> >dma_has_cap(DMA_SLAVE, cap)) {
> > d40c->dma_cfg = dma40_memcpy_conf_phy;
> > +
> > + /* Generate interrrupt at end of transfer or relink. */
> > + d40c->dst_def_cfg |= BIT(D40_SREG_CFG_TIM_POS);
> > +
> > + /* Generate interrupt on error. */
> > + d40c->src_def_cfg |= BIT(D40_SREG_CFG_EIM_POS);
> > + d40c->dst_def_cfg |= BIT(D40_SREG_CFG_EIM_POS);
> > +
> > } else {
> > chan_err(d40c, "No memcpy\n");
> > return -EINVAL;
> > @@ -2496,9 +2504,6 @@ static int d40_alloc_chan_resources(struct dma_chan
> > *chan)
> > }
> >
> > pm_runtime_get_sync(d40c->base->dev);
> > - /* Fill in basic CFG register values */
> > - d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
> > - &d40c->dst_def_cfg, chan_is_logical(d40c));
> >
> > d40_set_prio_realtime(d40c);
> >
> > @@ -2862,8 +2867,7 @@ static int d40_set_runtime_config(struct dma_chan
> > *chan,
> > if (chan_is_logical(d40c))
> > d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> > else
> > - d40_phy_cfg(cfg, &d40c->src_def_cfg,
> > - &d40c->dst_def_cfg, false);
> > + d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
> >
> > /* These settings will take precedence later */
> > d40c->runtime_addr = config_addr;
> > diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
> > index 435a223..ab5a2a7 100644
> > --- a/drivers/dma/ste_dma40_ll.c
> > +++ b/drivers/dma/ste_dma40_ll.c
> > @@ -50,63 +50,58 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
> >
> > }
> >
> > -/* Sets up SRC and DST CFG register for both logical and physical channels
> > */
> > -void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > -u32 *src_cfg, u32 *dst_cfg, bool is_log)
> > +void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
> > {
> > u32 src = 0;
> > u32 dst = 0;
> >
> > - if (!is_log) {
> > - /* Physical channel */
> > - if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
> > - (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> > - /* Set master port to 1 */
> > - src |= 1 << D40_SREG_CFG_MST_POS;
> > - src |= D40_TYPE_TO_EVENT(cfg->dev_type);
> > -
> > - if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> > - src |= 1 << D40_SREG_CFG_PHY_TM_POS;
> > - else
> > - src |= 3 << D40_SREG_CFG_PHY_TM_POS;
> > - }
> > - if ((cfg->dir == STEDMA40_MEM_TO_PERIPH) ||
> > - (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> > - /* Set master port to 1 */
> > - dst |= 1 << D40_SREG_CFG_MST_POS;
> > - dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
> > -
> > - if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> > - dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
> > - else
> > - dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
> > - }
> > - /* Interrupt on end of transfer for destination */
> > - dst |= 1 << D40_SREG_CFG_TIM_POS;
> > -
> > - /* Generate interrupt on error */
> > - src |= 1 << D40_SREG_CFG_EIM_POS;
> > - dst |= 1 << D40_SREG_CFG_EIM_POS;
> > -
> > - /* PSIZE */
> > - if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
> > - src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> > - src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
> > - }
> > - if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
> > - dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> > - dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
> > - }
> > -
> > -
Re: linux-next: Tree for May 15 (crypto /crct10dif)
On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou wrote:
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
>
> config CRYPTO_CRCT10DIF
> tristate "CRCT10DIF algorithm"
> + depends on CRC_T10DIF
This is a library symbol, so "select CRC_T10DIF"?
> select CRYPTO_HASH
> help
> CRC T10 Data Integrity Field computation is being cast as
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 31/39] dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones
On Thu, May 16, 2013 at 08:06:38AM +0100, Lee Jones wrote: > On Thu, 16 May 2013, Vinod Koul wrote: > > > 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: Rabin Vincent > > > Signed-off-by: Lee Jones > > Nice :) > > :) > > > 1) I dont see the STE macro getting removed, why do we need it > > They are removed later in the set, once their use has been removed > from platform code and all the other drivers. > > > 2) last i checked the direction values had a bit idfference b/w what you are > > using and what dmaengine defines, so hopefully that is taken care of.. > > Yes, no problem. > > ;) Acked-by: Vinod Koul -- ~Vinod > > -- > Lee Jones > Linaro ST-Ericsson Landing Team Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/39] dmaengine: ste_dma40: Correct copy/paste error
On Wed, May 15, 2013 at 10:51:33AM +0100, 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
> ---
Acked-by: Vinod Koul
--
~Vinod
> include/linux/platform_data/dma-ste-dma40.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/platform_data/dma-ste-dma40.h
> b/include/linux/platform_data/dma-ste-dma40.h
> index af0064e..288dc24 100644
> --- a/include/linux/platform_data/dma-ste-dma40.h
> +++ b/include/linux/platform_data/dma-ste-dma40.h
> @@ -86,7 +86,7 @@ enum stedma40_xfer_dir {
>
>
> /**
> - * struct stedma40_chan_cfg - dst/src channel configuration
> + * struct stedma40_half_channel_info - dst/src channel configuration
> *
> * @big_endian: true if the src/dst should be read as big endian
> * @data_width: Data width of the src/dst hardware
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/39] dmaengine: ste_dma40: Only use addresses passed as configuration information
On Wed, May 15, 2013 at 10:51:30AM +0100, 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 from platform data in the way of a look-up
> table.
>
> Signed-off-by: Lee Jones
> ---
Good code size reduction, always a good template for code improvements
Acked-by: Vinod Koul
--
~Vinod
> drivers/dma/ste_dma40.c | 51
> ++-
> 1 file changed, 11 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index ba84df8..57a127e 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -1774,22 +1774,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
> res = -EINVAL;
> }
>
> - if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
> - d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
> - d40c->runtime_addr == 0) {
> - chan_err(d40c, "Invalid TX channel address (%d)\n",
> - conf->dev_type);
> - res = -EINVAL;
> - }
> -
> - if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> - d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> - d40c->runtime_addr == 0) {
> - chan_err(d40c, "Invalid RX channel address (%d)\n",
> - conf->dev_type);
> - res = -EINVAL;
> - }
> -
> if (conf->dir == STEDMA40_PERIPH_TO_PERIPH) {
> /*
>* DMAC HW supports it. Will be added to this driver,
> @@ -2327,14 +2311,10 @@ d40_prep_sg(struct dma_chan *dchan, struct
> scatterlist *sg_src,
> if (sg_next(&sg_src[sg_len - 1]) == sg_src)
> desc->cyclic = true;
>
> - if (direction != DMA_TRANS_NONE) {
> - dma_addr_t dev_addr = d40_get_dev_addr(chan, direction);
> -
> - if (direction == DMA_DEV_TO_MEM)
> - src_dev_addr = dev_addr;
> - else if (direction == DMA_MEM_TO_DEV)
> - dst_dev_addr = dev_addr;
> - }
> + if (direction == DMA_DEV_TO_MEM)
> + src_dev_addr = chan->runtime_addr;
> + else if (direction == DMA_MEM_TO_DEV)
> + dst_dev_addr = chan->runtime_addr;
>
> if (chan_is_logical(chan))
> ret = d40_prep_sg_log(chan, desc, sg_src, sg_dst,
> @@ -2782,15 +2762,8 @@ static int d40_set_runtime_config(struct dma_chan
> *chan,
> dst_maxburst = config->dst_maxburst;
>
> if (config->direction == DMA_DEV_TO_MEM) {
> - dma_addr_t dev_addr_rx =
> - d40c->base->plat_data->dev_rx[cfg->dev_type];
> -
> config_addr = config->src_addr;
> - if (dev_addr_rx)
> - dev_dbg(d40c->base->dev,
> - "channel has a pre-wired RX address %08x "
> - "overriding with %08x\n",
> - dev_addr_rx, config_addr);
> +
> if (cfg->dir != STEDMA40_PERIPH_TO_MEM)
> dev_dbg(d40c->base->dev,
> "channel was not configured for peripheral "
> @@ -2805,15 +2778,8 @@ static int d40_set_runtime_config(struct dma_chan
> *chan,
> dst_maxburst = src_maxburst;
>
> } else if (config->direction == DMA_MEM_TO_DEV) {
> - dma_addr_t dev_addr_tx =
> - d40c->base->plat_data->dev_tx[cfg->dev_type];
> -
> config_addr = config->dst_addr;
> - if (dev_addr_tx)
> - dev_dbg(d40c->base->dev,
> - "channel has a pre-wired TX address %08x "
> - "overriding with %08x\n",
> - dev_addr_tx, config_addr);
> +
> if (cfg->dir != STEDMA40_MEM_TO_PERIPH)
> dev_dbg(d40c->base->dev,
> "channel was not configured for memory "
> @@ -2833,6 +2799,11 @@ static int d40_set_runtime_config(struct dma_chan
> *chan,
> return -EINVAL;
> }
>
> + if (config_addr <= 0) {
> + dev_err(d40c->base->dev, "no address supplied\n");
> + return -EINVAL;
> + }
> +
> if (src_maxburst * src_addr_width != dst_maxburst * dst_addr_width) {
> dev_err(d40c->base->dev,
> "src/dst width/maxburst mismatch: %d*%d != %d*%d\n",
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/39] dmaengine: ste_dma40: Remove redundant address fetching function
On Wed, May 15, 2013 at 10:51:31AM +0100, 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
> ---
Acked-by: Vinod Koul
--
~Vinod
> drivers/dma/ste_dma40.c | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 57a127e..6ed7757 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2267,24 +2267,6 @@ err:
> return NULL;
> }
>
> -static dma_addr_t
> -d40_get_dev_addr(struct d40_chan *chan, enum dma_transfer_direction
> direction)
> -{
> - struct stedma40_platform_data *plat = chan->base->plat_data;
> - struct stedma40_chan_cfg *cfg = &chan->dma_cfg;
> - dma_addr_t addr = 0;
> -
> - if (chan->runtime_addr)
> - return chan->runtime_addr;
> -
> - if (direction == DMA_DEV_TO_MEM)
> - addr = plat->dev_rx[cfg->dev_type];
> - else if (direction == DMA_MEM_TO_DEV)
> - addr = plat->dev_tx[cfg->dev_type];
> -
> - return addr;
> -}
> -
> static struct dma_async_tx_descriptor *
> d40_prep_sg(struct dma_chan *dchan, struct scatterlist *sg_src,
> struct scatterlist *sg_dst, unsigned int sg_len,
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/39] dmaengine: ste_dma40: Don't configure runtime configurable setup during allocate
On Wed, May 15, 2013 at 10:51:26AM +0100, 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.
>
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Signed-off-by: Lee Jones
> ---
Acked-by: Vinod Koul
--
~Vinod
> drivers/dma/ste_dma40.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index b7fe46b..ba84df8 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2040,6 +2040,9 @@ static int d40_config_memcpy(struct d40_chan *d40c)
> d40c->dma_cfg = dma40_memcpy_conf_log;
> d40c->dma_cfg.dev_type =
> dma40_memcpy_channels[d40c->chan.chan_id];
>
> + d40_log_cfg(&d40c->dma_cfg,
> + &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> +
> } else if (dma_has_cap(DMA_MEMCPY, cap) &&
> dma_has_cap(DMA_SLAVE, cap)) {
> d40c->dma_cfg = dma40_memcpy_conf_phy;
> @@ -2508,9 +2511,6 @@ static int d40_alloc_chan_resources(struct dma_chan
> *chan)
> d40_set_prio_realtime(d40c);
>
> if (chan_is_logical(d40c)) {
> - d40_log_cfg(&d40c->dma_cfg,
> - &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> -
> if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> d40c->lcpa = d40c->base->lcpa_base +
> d40c->dma_cfg.dev_type * D40_LCPA_CHAN_SIZE;
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
On Wed, May 15, 2013 at 10:51:25AM +0100, 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
That needs up update!
> Acked-by: Arnd Bergmann
> Signed-off-by: Lee Jones
> ---
> drivers/dma/ste_dma40.c| 14 +++---
> drivers/dma/ste_dma40_ll.c | 101
> +---
> drivers/dma/ste_dma40_ll.h |3 +-
> 3 files changed, 58 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 759293e..b7fe46b 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2043,6 +2043,14 @@ static int d40_config_memcpy(struct d40_chan *d40c)
> } else if (dma_has_cap(DMA_MEMCPY, cap) &&
> dma_has_cap(DMA_SLAVE, cap)) {
> d40c->dma_cfg = dma40_memcpy_conf_phy;
> +
> + /* Generate interrrupt at end of transfer or relink. */
> + d40c->dst_def_cfg |= BIT(D40_SREG_CFG_TIM_POS);
> +
> + /* Generate interrupt on error. */
> + d40c->src_def_cfg |= BIT(D40_SREG_CFG_EIM_POS);
> + d40c->dst_def_cfg |= BIT(D40_SREG_CFG_EIM_POS);
> +
> } else {
> chan_err(d40c, "No memcpy\n");
> return -EINVAL;
> @@ -2496,9 +2504,6 @@ static int d40_alloc_chan_resources(struct dma_chan
> *chan)
> }
>
> pm_runtime_get_sync(d40c->base->dev);
> - /* Fill in basic CFG register values */
> - d40_phy_cfg(&d40c->dma_cfg, &d40c->src_def_cfg,
> - &d40c->dst_def_cfg, chan_is_logical(d40c));
>
> d40_set_prio_realtime(d40c);
>
> @@ -2862,8 +2867,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
> if (chan_is_logical(d40c))
> d40_log_cfg(cfg, &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> else
> - d40_phy_cfg(cfg, &d40c->src_def_cfg,
> - &d40c->dst_def_cfg, false);
> + d40_phy_cfg(cfg, &d40c->src_def_cfg, &d40c->dst_def_cfg);
>
> /* These settings will take precedence later */
> d40c->runtime_addr = config_addr;
> diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
> index 435a223..ab5a2a7 100644
> --- a/drivers/dma/ste_dma40_ll.c
> +++ b/drivers/dma/ste_dma40_ll.c
> @@ -50,63 +50,58 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
>
> }
>
> -/* Sets up SRC and DST CFG register for both logical and physical channels */
> -void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> - u32 *src_cfg, u32 *dst_cfg, bool is_log)
> +void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
> {
> u32 src = 0;
> u32 dst = 0;
>
> - if (!is_log) {
> - /* Physical channel */
> - if ((cfg->dir == STEDMA40_PERIPH_TO_MEM) ||
> - (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> - /* Set master port to 1 */
> - src |= 1 << D40_SREG_CFG_MST_POS;
> - src |= D40_TYPE_TO_EVENT(cfg->dev_type);
> -
> - if (cfg->src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> - src |= 1 << D40_SREG_CFG_PHY_TM_POS;
> - else
> - src |= 3 << D40_SREG_CFG_PHY_TM_POS;
> - }
> - if ((cfg->dir == STEDMA40_MEM_TO_PERIPH) ||
> - (cfg->dir == STEDMA40_PERIPH_TO_PERIPH)) {
> - /* Set master port to 1 */
> - dst |= 1 << D40_SREG_CFG_MST_POS;
> - dst |= D40_TYPE_TO_EVENT(cfg->dev_type);
> -
> - if (cfg->dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
> - dst |= 1 << D40_SREG_CFG_PHY_TM_POS;
> - else
> - dst |= 3 << D40_SREG_CFG_PHY_TM_POS;
> - }
> - /* Interrupt on end of transfer for destination */
> - dst |= 1 << D40_SREG_CFG_TIM_POS;
> -
> - /* Generate interrupt on error */
> - src |= 1 << D40_SREG_CFG_EIM_POS;
> - dst |= 1 << D40_SREG_CFG_EIM_POS;
> -
> - /* PSIZE */
> - if (cfg->src_info.psize != STEDMA40_PSIZE_PHY_1) {
> - src |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> - src |= cfg->src_info.psize << D40_SREG_CFG_PSIZE_POS;
> - }
> - if (cfg->dst_info.psize != STEDMA40_PSIZE_PHY_1) {
> - dst |= 1 << D40_SREG_CFG_PHY_PEN_POS;
> - dst |= cfg->dst_info.psize << D40_SREG_CFG_PSIZE_POS;
> - }
> -
> - /* Element size */
> - src |= cfg->src_info.data_width << D40_SREG_CFG_ESIZE_POS;
> - dst |= cfg->dst_info.data_width << D40_SREG_CFG_ESIZE_POS;
> -
> - /* Set the priority bit to high for the physical
Re: [PATCH 01/39] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
On Wed, May 15, 2013 at 06:29:51PM +0200, Linus Walleij wrote: > 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 in d40_phy_cfg(), which is mostly runtime configuration > > into the runtime_config() routine. > > > > Cc: Vinod Koul > > Cc: Dan Williams > > Cc: Per Forlin > > Cc: Rabin Vincent > > Acked-by: Arnd Bergmann > > Signed-off-by: Lee Jones > > Tentatively applied to my ux500-dma40 branch. > > This lacks an ACK from Vinod... Acked-by: Vinod Koul > > I cannot get any of this stack of patches up to ARM SoC > before I have Vinod's ACK on all hitting drivers/dma/* Wip ... :) > > Yours, > Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 38/39] dmaengine: ste_dma40: Fetch the number of physical channels from DT
On Wed, May 15, 2013 at 10:52:01AM +0100, 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 add the infrastructure.
>
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Signed-off-by: Lee Jones
> ---
Acked-by: Vinod Koul
> drivers/dma/ste_dma40.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index ae462d3..4e528dd 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -3482,7 +3482,7 @@ static int __init d40_of_probe(struct platform_device
> *pdev,
> struct device_node *np)
> {
> struct stedma40_platform_data *pdata;
> - int num_memcpy = 0;
> + int num_phy = 0, num_memcpy = 0;
> const const __be32 *list;
>
> pdata = devm_kzalloc(&pdev->dev,
> @@ -3491,6 +3491,11 @@ static int __init d40_of_probe(struct platform_device
> *pdev,
> if (!pdata)
> return -ENOMEM;
>
> + /* If absent this value will be obtained from h/w. */
> + of_property_read_u32(np, "dma-channels", &num_phy);
> + if (num_phy > 0)
> + pdata->num_of_phy_chans = num_phy;
> +
> list = of_get_property(np, "memcpy-channels", &num_memcpy);
> num_memcpy /= sizeof(*list);
>
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value
On Wed, May 15, 2013 at 10:51:57AM +0100, 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 '1' by the bit pattern (1 << data_width)
> times to make any sense of it.
>
> This patch flips the semantics on its head and only converts the value
> to its respective register bit pattern when writing to registers. This
> way we can use the true data_width (in Bytes) value.
>
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Signed-off-by: Lee Jones
> ---
> @@ -2804,14 +2781,24 @@ static int d40_set_runtime_config(struct dma_chan
> *chan,
> src_maxburst = dst_maxburst * dst_addr_width / src_addr_width;
> }
>
> + /* Only valid widths are; 1, 2, 4 and 8. */
> + if (src_addr_width <= DMA_SLAVE_BUSWIDTH_UNDEFINED ||
> + src_addr_width > DMA_SLAVE_BUSWIDTH_8_BYTES ||
> + dst_addr_width <= DMA_SLAVE_BUSWIDTH_UNDEFINED ||
> + dst_addr_width > DMA_SLAVE_BUSWIDTH_8_BYTES ||
> + ((src_addr_width > 1) && (src_addr_width & 1)) ||
> + ((dst_addr_width > 1) && (dst_addr_width & 1)))
> + return -EINVAL;
how about a simple macro to check above..
> +
> + cfg->src_info.data_width = src_addr_width;
> + cfg->dst_info.data_width = dst_addr_width;
> +
> ret = dma40_config_to_halfchannel(d40c, &cfg->src_info,
> - src_addr_width,
> src_maxburst);
> if (ret)
> return ret;
>
> ret = dma40_config_to_halfchannel(d40c, &cfg->dst_info,
> - dst_addr_width,
> dst_maxburst);
> if (ret)
> return ret;
> diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
> index 5ddd724..a035dfe 100644
> --- a/drivers/dma/ste_dma40_ll.c
> +++ b/drivers/dma/ste_dma40_ll.c
> @@ -10,6 +10,18 @@
>
> #include "ste_dma40_ll.h"
>
> +u8 d40_width_to_bits(enum dma_slave_buswidth width)
> +{
> + if (width == DMA_SLAVE_BUSWIDTH_1_BYTE)
> + return STEDMA40_ESIZE_8_BIT;
> + else if (width == DMA_SLAVE_BUSWIDTH_2_BYTES)
> + return STEDMA40_ESIZE_16_BIT;
> + else if (width == DMA_SLAVE_BUSWIDTH_8_BYTES)
> + return STEDMA40_ESIZE_64_BIT;
> + else
> + return STEDMA40_ESIZE_32_BIT;
> +}
> +
Switch looks better for this and how about
return fls(width);
as your defines are 0...3 and dmaengine define 1,2,..8 for same thing
then you can also get rid of STEDMA40_XXX_WIDTH macros!
> @@ -70,13 +70,6 @@ enum stedma40_flow_ctrl {
> STEDMA40_FLOW_CTRL,
> };
>
> -enum stedma40_periph_data_width {
> - STEDMA40_BYTE_WIDTH = STEDMA40_ESIZE_8_BIT,
> - STEDMA40_HALFWORD_WIDTH = STEDMA40_ESIZE_16_BIT,
> - STEDMA40_WORD_WIDTH = STEDMA40_ESIZE_32_BIT,
> - STEDMA40_DOUBLEWORD_WIDTH = STEDMA40_ESIZE_64_BIT
> -};
nice
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 31/39] dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones
On Thu, 16 May 2013, Vinod Koul wrote: > 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: Rabin Vincent > > Signed-off-by: Lee Jones > Nice :) :) > 1) I dont see the STE macro getting removed, why do we need it They are removed later in the set, once their use has been removed from platform code and all the other drivers. > 2) last i checked the direction values had a bit idfference b/w what you are > using and what dmaengine defines, so hopefully that is taken care of.. Yes, no problem. ;) -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/39] crypto: ux500/[cryp|hash] - Show successful start-up in the bootlog
On Wed, May 15, 2013 at 10:51:41AM +0100, Lee Jones wrote: > 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: Linus Walleij > Signed-off-by: Lee Jones Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/39] crypto: ux500/cryp - Set DMA configuration though dma_slave_config()
On Wed, May 15, 2013 at 10:51:39AM +0100, 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: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-crypto@vger.kernel.org > Acked-by: Arnd Bergmann > Acked-by: Linus Walleij > Signed-off-by: Lee Jones Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/39] crypto: ux500/cryp - Prepare clock before enabling it
On Wed, May 15, 2013 at 10:51:38AM +0100, 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 Hansson > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/39] crypto: ux500/hash - Set DMA configuration though dma_slave_config()
On Wed, May 15, 2013 at 10:51:36AM +0100, 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: Herbert Xu > Cc: David S. Miller > Cc: Andreas Westin > Cc: linux-crypto@vger.kernel.org > Acked-by: Arnd Bergmann > Signed-off-by: Lee Jones Acked-by: Herbert Xu -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/39] crypto: ux500/hash - Prepare clock before enabling it
On Thu, May 16, 2013 at 07:53:55AM +0100, Lee Jones wrote: > 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 Westin > > > Cc: linux-crypto@vger.kernel.org > > > Acked-by: Arnd Bergmann > > > Acked-by: Ulf Hansson > > > Signed-off-by: Lee Jones > > > > This patch seems to be totally independent of the other stuff > > in the patch series, and it even seems like an -rc fix to me > > (I don't think the crypto device works without this). > > > > This should go into the crypto tree? > > I agree. > > > Else please convince Herbert to give his ACK on this > > before I apply it. > > Plaasseee Herbert, take this patch! :) Acked-by: Herbert Xu Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
