* Oops on 3.10-rc1 related to ssh256_ssse3
From: Julian Wollrath @ 2013-05-16 13:41 UTC (permalink / raw)
To: linux-crypto
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-devel@redhat.com
[ 11.619603] sha256_ssse3: Using SSSE3 optimized SHA-256 implementation
[ 12.131483] BUG: unable to handle kernel paging request at ffff8800bb593000
[ 12.131848] IP: [<ffffffffa016b083>] loop0+0x27/0x44 [sha256_ssse3]
[ 12.132032] PGD 1a32067 PUD 1a35067 PMD 1a36067 PTE 0
[ 12.132427] Oops: 0000 [#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: ffff880037572090 ti: ffff8800b66b6000 task.ti: ffff8800b66b6000
[ 12.135836] RIP: 0010:[<ffffffffa016b083>] [<ffffffffa016b083>] loop0+0x27/0x44 [sha256_ssse3]
[ 12.136032] RSP: 0018:ffff8800b66b7af0 EFLAGS: 00010287
[ 12.136130] RAX: 00000000a186fc15 RBX: 00000000704bb939 RCX: 00000000d1b791ec
[ 12.136232] RDX: 000000001fd2088a RSI: ffff880037a97ee8 RDI: ffff8800bb592fc8
[ 12.136334] RBP: ffffffffa016f000 R08: 0000000052a5c3c8 R09: 000000005db427ef
[ 12.136439] R10: 00000000b80a833e R11: 0000000029c53567 R12: ffff8800b66b7b08
[ 12.136543] R13: 000000003158a213 R14: 00000000c7fc368e R15: 0000000001008012
[ 12.136647] FS: 0000000000000000(0000) GS:ffff8800bb180000(0000) knlGS:0000000000000000
[ 12.136763] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 12.136863] CR2: ffff8800bb593000 CR3: 000000000180b000 CR4: 00000000000007e0
[ 12.136964] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 12.137066] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 12.137167] Stack:
[ 12.137257] ffff880108c634c8 ffff8800bb592f88 6033fb357b8c96fd c5e119eaebeb38a3
[ 12.137668] ffff880037a97f08 ffff8800b66b7b80 0000000000000008 0000000000000008
[ 12.138077] ffff880037a97ed0 ffffffffa016dc4e ffff880001496ae5 ffff880037a97ee0
[ 12.138484] Call Trace:
[ 12.138580] [<ffffffffa016dc4e>] ? __sha256_ssse3_update+0x5e/0xe0 [sha256_ssse3]
[ 12.138701] [<ffffffffa016df15>] ? sha256_ssse3_final+0x145/0x1ec [sha256_ssse3]
[ 12.138825] [<ffffffff81214362>] ? shash_ahash_finup+0x32/0x80
[ 12.138931] [<ffffffff81217523>] ? test_hash+0x383/0x6b0
[ 12.139034] [<ffffffff8120c8a0>] ? crypto_mod_get+0x10/0x30
[ 12.139141] [<ffffffff811186d6>] ? __kmalloc+0x1c6/0x1f0
[ 12.139243] [<ffffffff8120cdfc>] ? __crypto_alg_lookup+0xac/0xf0
[ 12.139344] [<ffffffff8120ca48>] ? crypto_create_tfm+0x48/0xd0
[ 12.139445] [<ffffffff812146cd>] ? crypto_init_shash_ops_async+0x2d/0xd0
[ 12.139548] [<ffffffff81217893>] ? alg_test_hash+0x43/0xa0
[ 12.139650] [<ffffffff81215b9b>] ? alg_test+0x9b/0x230
[ 12.139753] [<ffffffff81421351>] ? __schedule+0x271/0x650
[ 12.139856] [<ffffffff81214940>] ? cryptomgr_probe+0xb0/0xb0
[ 12.139954] [<ffffffff81214978>] ? cryptomgr_test+0x38/0x40
[ 12.140058] [<ffffffff8105c53f>] ? kthread+0xaf/0xc0
[ 12.140219] [<ffffffff8105c490>] ? kthread_create_on_node+0x110/0x110
[ 12.140382] [<ffffffff814237ac>] ? ret_from_fork+0x7c/0xb0
[ 12.140482] [<ffffffff8105c490>] ? 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 <f3> 0f 6f 7f 30 66 41 0f 38 00 fc 48 89 7c 24 08 48 c7 c7 03 00
[ 12.145708] RIP [<ffffffffa016b083>] loop0+0x27/0x44 [sha256_ssse3]
[ 12.145885] RSP <ffff8800b66b7af0>
[ 12.145979] CR2: ffff8800bb593000
[ 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/0x10000001
[ 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] ffffffff8141eaf7 ffffffff8141bca7 ffffffff8142167a 0000000000000035
[ 12.151034] 0000000000000046 ffff8800b66b7fd8 ffff8800b66b7fd8 ffff8800b66b7fd8
[ 12.151610] ffff880037572090 ffff8800b66b6000 ffff8800375725d0 0000000000000046
[ 12.152215] Call Trace:
[ 12.152352] [<ffffffff8141eaf7>] ? dump_stack+0xc/0x15
[ 12.152496] [<ffffffff8141bca7>] ? __schedule_bug+0x3f/0x4c
[ 12.152637] [<ffffffff8142167a>] ? __schedule+0x59a/0x650
[ 12.152764] [<ffffffff81067ccd>] ? __cond_resched+0x1d/0x30
[ 12.152898] [<ffffffff814217a6>] ? _cond_resched+0x26/0x30
[ 12.153033] [<ffffffff81420405>] ? mutex_lock+0x15/0x40
[ 12.153169] [<ffffffff810cfba0>] ? perf_event_exit_task+0x20/0x1e0
[ 12.153277] [<ffffffff8103e24f>] ? do_exit+0x29f/0xa10
[ 12.153414] [<ffffffff81005ca6>] ? oops_end+0x96/0xe0
[ 12.153550] [<ffffffff8141afd9>] ? no_context+0x24c/0x275
[ 12.153692] [<ffffffff8102d51e>] ? __do_page_fault+0x2ee/0x480
[ 12.153834] [<ffffffff810db066>] ? __alloc_pages_nodemask+0x106/0x8f0
[ 12.153962] [<ffffffff81423332>] ? page_fault+0x22/0x30
[ 12.154102] [<ffffffffa016b083>] ? loop0+0x27/0x44 [sha256_ssse3]
[ 12.154232] [<ffffffffa016dc4e>] ? __sha256_ssse3_update+0x5e/0xe0 [sha256_ssse3]
[ 12.154380] [<ffffffffa016df15>] ? sha256_ssse3_final+0x145/0x1ec [sha256_ssse3]
[ 12.154532] [<ffffffff81214362>] ? shash_ahash_finup+0x32/0x80
[ 12.154660] [<ffffffff81217523>] ? test_hash+0x383/0x6b0
[ 12.154800] [<ffffffff8120c8a0>] ? crypto_mod_get+0x10/0x30
[ 12.154940] [<ffffffff811186d6>] ? __kmalloc+0x1c6/0x1f0
[ 12.155042] [<ffffffff8120cdfc>] ? __crypto_alg_lookup+0xac/0xf0
[ 12.155183] [<ffffffff8120ca48>] ? crypto_create_tfm+0x48/0xd0
[ 12.155327] [<ffffffff812146cd>] ? crypto_init_shash_ops_async+0x2d/0xd0
[ 12.155466] [<ffffffff81217893>] ? alg_test_hash+0x43/0xa0
[ 12.155609] [<ffffffff81215b9b>] ? alg_test+0x9b/0x230
[ 12.155746] [<ffffffff81421351>] ? __schedule+0x271/0x650
[ 12.155886] [<ffffffff81214940>] ? cryptomgr_probe+0xb0/0xb0
[ 12.156018] [<ffffffff81214978>] ? cryptomgr_test+0x38/0x40
[ 12.156150] [<ffffffff8105c53f>] ? kthread+0xaf/0xc0
[ 12.156275] [<ffffffff8105c490>] ? kthread_create_on_node+0x110/0x110
[ 12.156408] [<ffffffff814237ac>] ? ret_from_fork+0x7c/0xb0
[ 12.156542] [<ffffffff8105c490>] ? kthread_create_on_node+0x110/0x110
[ 16.822251] SysRq : Keyboard mode set to system default
[ 18.165412] SysRq : Terminate All Tasks
[ 18.165722] ------------[ cut here ]------------
[ 18.165825] WARNING: at crypto/algapi.c:329 crypto_wait_for_test+0x55/0x70()
[ 18.165846] 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
[ 18.165847] CPU: 3 PID: 273 Comm: modprobe Tainted: G D W 3.10.0-rc1+ #2
[ 18.165849] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 10/25/2010
[ 18.165851] ffffffff8141eaf7 ffffffff810390fa ffff8800b669b400 ffff8800b669b400
[ 18.165853] ffffffffa016f660 ffffffffa016f6b0 0000000000000001 ffffffff8120e4d5
[ 18.165854] 0000000000000000 ffffffff8120e634 ffffffffa0046000 0000000000000000
[ 18.165855] Call Trace:
[ 18.165858] [<ffffffff8141eaf7>] ? dump_stack+0xc/0x15
[ 18.165861] [<ffffffff810390fa>] ? warn_slowpath_common+0x6a/0xa0
[ 18.165863] [<ffffffff8120e4d5>] ? crypto_wait_for_test+0x55/0x70
[ 18.165864] [<ffffffff8120e634>] ? crypto_register_alg+0x64/0x80
[ 18.165867] [<ffffffffa0046000>] ? 0xffffffffa0045fff
[ 18.165868] [<ffffffff810002fa>] ? do_one_initcall+0x10a/0x160
[ 18.165873] [<ffffffff81090a57>] ? load_module+0x1b37/0x2450
[ 18.165875] [<ffffffff8108ca90>] ? unset_module_init_ro_nx+0x80/0x80
[ 18.165877] [<ffffffff81091430>] ? SyS_init_module+0xc0/0xf0
[ 18.165879] [<ffffffff81423852>] ? system_call_fastpath+0x16/0x1b
[ 18.165880] ---[ end trace 0382cf30f3465fd2 ]---
[ 18.166140] bio: create slab <bio-1> at 1
[ 20.123114] SysRq : Kill All Tasks
[ 20.882858] SysRq : Emergency Sync
[ 20.883148] Emergency Sync complete
[ 22.531845] SysRq : Emergency Remount R/O
[ 22.532141] Emergency Remount complete
[ 23.386434] SysRq : Resetting
[ 23.386663] ACPI MEMORY or I/O RESET_REG.
^ permalink raw reply
* [PATCH 6/6] crypto: ux500/hash - Enable DT probing of the driver
From: Lee Jones @ 2013-05-16 11:27 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, srinidhi.kasagar, Lee Jones, Herbert Xu,
linux-crypto
In-Reply-To: <1368703646-26418-1-git-send-email-lee.jones@linaro.org>
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 <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
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
^ permalink raw reply related
* [PATCH 5/6] crypto: ux500/cryp - Enable DT probing of the driver
From: Lee Jones @ 2013-05-16 11:27 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: arnd, linus.walleij, srinidhi.kasagar, Lee Jones, Herbert Xu,
linux-crypto
In-Reply-To: <1368703646-26418-1-git-send-email-lee.jones@linaro.org>
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 <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
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
^ permalink raw reply related
* Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
From: Lee Jones @ 2013-05-16 10:59 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar
In-Reply-To: <20130516094014.GJ14863@intel.com>
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 <vnod.koul@intel.com>
> > > 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
^ permalink raw reply
* Re: [PATCH 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value
From: Vinod Koul @ 2013-05-16 9:41 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar,
Dan Williams, Per Forlin, Rabin Vincent
In-Reply-To: <20130516073553.GF3269@gmail.com>
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
^ permalink raw reply
* Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
From: Vinod Koul @ 2013-05-16 9:40 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar
In-Reply-To: <20130516072557.GD3269@gmail.com>
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 <vnod.koul@intel.com>
> > 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
^ permalink raw reply
* Re: [PATCH 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value
From: Lee Jones @ 2013-05-16 7:35 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar,
Dan Williams, Per Forlin, Rabin Vincent
In-Reply-To: <20130516063244.GA14863@intel.com>
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 <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
>
> > @@ -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
^ permalink raw reply
* Re: [PATCH 01/39] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
From: Lee Jones @ 2013-05-16 7:26 UTC (permalink / raw)
To: Vinod Koul
Cc: Linus Walleij, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Felipe Balbi,
linux-usb@vger.kernel.org, linux-crypto@vger.kernel.org,
David S. Miller, Herbert Xu, Rabin Vincent, Linus WALLEIJ,
Arnd Bergmann, Srinidhi KASAGAR, Per Forlin, Dan Williams
In-Reply-To: <20130516063513.GC14863@intel.com>
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 <lee.jones@linaro.org> 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 <vinod.koul@intel.com>
> > > Cc: Dan Williams <djbw@fb.com>
> > > Cc: Per Forlin <per.forlin@stericsson.com>
> > > Cc: Rabin Vincent <rabin@rab.in>
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >
> > Tentatively applied to my ux500-dma40 branch.
> >
> > This lacks an ACK from Vinod...
> Acked-by: Vinod Koul <vinod.koul@intel.com>
> >
> > 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
^ permalink raw reply
* Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
From: Lee Jones @ 2013-05-16 7:25 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar
In-Reply-To: <20130516063546.GD14863@intel.com>
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 <vnod.koul@intel.com>
> 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 <arnd@arndb.de>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > ---
> > 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 channel */
> > - if (cfg->high_priority) {
> > - src |= 1 << D40_SREG_CFG_PRI_POS;
> > - dst |= 1 << D40_SREG_CFG_PRI_POS;
> > - }
> > + 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 channel */
> > + if (cfg->high_priority) {
> > + src |= 1 << D40_SREG_CFG_PRI_POS;
> > + dst |= 1 << D40_SREG_CFG_PRI_POS;
> > }
> >
> > if (cfg->src_info.big_endian)
> > diff --git a/drivers/dma/ste_dma40_ll.h b/drivers/dma/ste_dma40_ll.h
> > index fdde8ef..1b47312 100644
> > --- a/drivers/dma/ste_dma40_ll.h
> > +++ b/drivers/dma/ste_dma40_ll.h
> > @@ -432,8 +432,7 @@ enum d40_lli_flags {
> >
> > void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
> > u32 *src_cfg,
> > - u32 *dst_cfg,
> > - bool is_log);
> > + u32 *dst_cfg);
> >
> > void d40_log_cfg(struct stedma40_chan_cfg *cfg,
> > u32 *lcsp1,
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: linux-next: Tree for May 15 (crypto /crct10dif)
From: Geert Uytterhoeven @ 2013-05-16 7:22 UTC (permalink / raw)
To: Xiong Zhou
Cc: tim.c.chen, Herbert Xu, Stephen Rothwell, Linux-Next,
linux-kernel@vger.kernel.org, linux-crypto, Randy Dunlap
In-Reply-To: <alpine.DEB.2.02.1305161152530.31865@M2420>
On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou <jencce.kernel@gmail.com> 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 -- geert@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
^ permalink raw reply
* Re: [PATCH 08/39] dmaengine: ste_dma40: Remove redundant address fetching function
From: Vinod Koul @ 2013-05-16 6:41 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar
In-Reply-To: <1368611522-9984-9-git-send-email-lee.jones@linaro.org>
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 <lee.jones@linaro.org>
> ---
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~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
>
^ permalink raw reply
* Re: [PATCH 03/39] dmaengine: ste_dma40: Don't configure runtime configurable setup during allocate
From: Vinod Koul @ 2013-05-16 6:36 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar,
Dan Williams, Per Forlin, Rabin Vincent
In-Reply-To: <1368611522-9984-4-git-send-email-lee.jones@linaro.org>
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 <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~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
>
^ permalink raw reply
* Re: [PATCH 01/39] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
From: Vinod Koul @ 2013-05-16 6:35 UTC (permalink / raw)
To: Linus Walleij
Cc: Lee Jones, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Felipe Balbi,
linux-usb@vger.kernel.org, linux-crypto@vger.kernel.org,
David S. Miller, Herbert Xu, Rabin Vincent, Linus WALLEIJ,
Arnd Bergmann, Srinidhi KASAGAR, Per Forlin, Dan Williams
In-Reply-To: <CACRpkdZJp-WRGNgzwqERVBtb_WxQGybmMjnnLTAoX66qECNh7g@mail.gmail.com>
On Wed, May 15, 2013 at 06:29:51PM +0200, Linus Walleij wrote:
> On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones@linaro.org> 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 <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Tentatively applied to my ux500-dma40 branch.
>
> This lacks an ACK from Vinod...
Acked-by: Vinod Koul <vinod.koul@intel.com>
>
> 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
^ permalink raw reply
* Re: [PATCH 38/39] dmaengine: ste_dma40: Fetch the number of physical channels from DT
From: Vinod Koul @ 2013-05-16 6:34 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar,
Dan Williams, Per Forlin, Rabin Vincent
In-Reply-To: <1368611522-9984-39-git-send-email-lee.jones@linaro.org>
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 <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
Acked-by: Vinod Koul <vinod.koul@intel.com>
> 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
>
^ permalink raw reply
* Re: [PATCH 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value
From: Vinod Koul @ 2013-05-16 6:32 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar,
Dan Williams, Per Forlin, Rabin Vincent
In-Reply-To: <1368611522-9984-35-git-send-email-lee.jones@linaro.org>
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 <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> @@ -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
^ permalink raw reply
* Re: [PATCH 31/39] dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones
From: Lee Jones @ 2013-05-16 7:06 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar,
Dan Williams, Per Forlin, Rabin Vincent
In-Reply-To: <20130516051701.GG27639@intel.com>
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 <vinod.koul@intel.com>
> > Cc: Dan Williams <djbw@fb.com>
> > Cc: Per Forlin <per.forlin@stericsson.com>
> > Cc: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> 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.
<place Ack here> ;)
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 18/39] crypto: ux500/[cryp|hash] - Show successful start-up in the bootlog
From: Herbert Xu @ 2013-05-16 7:02 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, vinod.koul, arnd, linus.walleij, srinidhi.kasagar,
Andreas Westin
In-Reply-To: <1368611522-9984-19-git-send-email-lee.jones@linaro.org>
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 <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Andreas Westin <andreas.westin@stericsson.com>
> Cc: linux-crypto@vger.kernel.org
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 16/39] crypto: ux500/cryp - Set DMA configuration though dma_slave_config()
From: Herbert Xu @ 2013-05-16 7:01 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, vinod.koul, arnd, linus.walleij, srinidhi.kasagar,
Andreas Westin
In-Reply-To: <1368611522-9984-17-git-send-email-lee.jones@linaro.org>
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 <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Andreas Westin <andreas.westin@stericsson.com>
> Cc: linux-crypto@vger.kernel.org
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 15/39] crypto: ux500/cryp - Prepare clock before enabling it
From: Herbert Xu @ 2013-05-16 7:01 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, vinod.koul, arnd, linus.walleij, srinidhi.kasagar,
Andreas Westin
In-Reply-To: <1368611522-9984-16-git-send-email-lee.jones@linaro.org>
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 <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Andreas Westin <andreas.westin@stericsson.com>
> Cc: linux-crypto@vger.kernel.org
> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 13/39] crypto: ux500/hash - Set DMA configuration though dma_slave_config()
From: Herbert Xu @ 2013-05-16 7:01 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, vinod.koul, arnd, linus.walleij, srinidhi.kasagar,
Andreas Westin
In-Reply-To: <1368611522-9984-14-git-send-email-lee.jones@linaro.org>
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 <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Andreas Westin <andreas.westin@stericsson.com>
> Cc: linux-crypto@vger.kernel.org
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 12/39] crypto: ux500/hash - Prepare clock before enabling it
From: Herbert Xu @ 2013-05-16 7:00 UTC (permalink / raw)
To: Lee Jones
Cc: Linus Walleij, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Felipe Balbi,
linux-usb@vger.kernel.org, linux-crypto@vger.kernel.org,
David S. Miller, Vinod Koul, Arnd Bergmann, Linus WALLEIJ,
Srinidhi KASAGAR, Andreas Westin
In-Reply-To: <20130516065355.GA3269@gmail.com>
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 <lee.jones@linaro.org> 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 <herbert@gondor.apana.org.au>
> > > Cc: David S. Miller <davem@davemloft.net>
> > > Cc: Andreas Westin <andreas.westin@stericsson.com>
> > > Cc: linux-crypto@vger.kernel.org
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >
> > 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.
>
> Pleeeeaasseee Herbert, take this patch! :)
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 35/39] dmaengine: ste_dma40_ll: Replace meaningless register set with comment
From: Lee Jones @ 2013-05-16 6:58 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, balbi-l0cyMroinI0,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
herbert-F6s6mLieUQo7FNHlEwC/lvQIK84fMopw, arnd-r2nGTMty4D4,
linus.walleij-0IS4wlFg1OjSUeElwK9/Pw,
srinidhi.kasagar-0IS4wlFg1OjSUeElwK9/Pw, Dan Williams, Per Forlin,
Rabin Vincent
In-Reply-To: <20130516051820.GH27639-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > 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 the comment in.
The original author will on parental leave for the foreseeable future.
--
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-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 12/39] crypto: ux500/hash - Prepare clock before enabling it
From: Lee Jones @ 2013-05-16 6:53 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Herbert Xu, Vinod Koul, Arnd Bergmann,
Linus WALLEIJ, Srinidhi KASAGAR, Andreas Westin
In-Reply-To: <CACRpkdYdf1j+V516CigFeGKv1B+Mf4mZk8g3ZwYAwa=rDP=7vg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 15 May 2013, Linus Walleij wrote:
> On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 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 <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
> > Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> > Cc: Andreas Westin <andreas.westin-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
> > Cc: linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> > Acked-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> 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.
Pleeeeaasseee Herbert, take this patch! :)
How's that?
--
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-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 39/39] dmaengine: ste_dma40: Fetch disabled channels from DT
From: Vinod Koul @ 2013-05-16 6:08 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar,
Dan Williams, Per Forlin, Rabin Vincent
In-Reply-To: <1368611522-9984-40-git-send-email-lee.jones@linaro.org>
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 may as well add the infrastructure.
>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Dan Williams <djbw@fb.com>
> Cc: Per Forlin <per.forlin@stericsson.com>
> Cc: Rabin Vincent <rabin@rab.in>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Vinod Koul <vinod.koul@intel.com>
> ---
> Documentation/devicetree/bindings/dma/ste-dma40.txt | 2 ++
> drivers/dma/ste_dma40.c | 17 ++++++++++++++++-
> 2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> index aa272d8..bea5b73 100644
> --- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
> +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
> @@ -11,6 +11,7 @@ Required properties:
> Optional properties:
> - dma-channels: Number of channels supported by hardware - if not present
> the driver will attempt to obtain the information from H/W
> +- disabled-channels: Channels which can not be used
>
> Example:
>
> @@ -23,6 +24,7 @@ Example:
>
> #dma-cells = <2>;
> memcpy-channels = <56 57 58 59 60>;
> + disabled-channels = <12>;
> dma-channels = <8>;
> };
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index 4e528dd..ffac822 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_phy = 0, num_memcpy = 0;
> + int num_phy = 0, num_memcpy = 0, num_disabled = 0;
> const const __be32 *list;
>
> pdata = devm_kzalloc(&pdev->dev,
> @@ -3511,6 +3511,21 @@ static int __init d40_of_probe(struct platform_device *pdev,
> dma40_memcpy_channels,
> num_memcpy);
>
> + list = of_get_property(np, "disabled-channels", &num_disabled);
> + num_disabled /= sizeof(*list);
> +
> + if (num_disabled > STEDMA40_MAX_PHYS || num_disabled < 0) {
> + d40_err(&pdev->dev,
> + "Invalid number of disabled channels specified (%d)\n",
> + num_disabled);
> + return -EINVAL;
> + }
> +
> + of_property_read_u32_array(np, "disabled-channels",
> + pdata->disabled_channels,
> + num_disabled);
> + pdata->disabled_channels[num_disabled] = -1;
> +
> pdev->dev.platform_data = pdata;
>
> return 0;
> --
> 1.7.10.4
>
^ permalink raw reply
* Re: [PATCH 31/39] dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones
From: Vinod Koul @ 2013-05-16 6:43 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, arnd, linus.walleij, srinidhi.kasagar,
Dan Williams, Per Forlin, Rabin Vincent
In-Reply-To: <20130516070638.GC3269@gmail.com>
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 <vinod.koul@intel.com>
> > > Cc: Dan Williams <djbw@fb.com>
> > > Cc: Per Forlin <per.forlin@stericsson.com>
> > > Cc: Rabin Vincent <rabin@rab.in>
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > 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.
>
> <place Ack here> ;)
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
>
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox