Hi,
This is an update of the core platform support for
ux500 HASH and CRYP driver. Also a small update for DMA
in the drivers.
Note that this does not apply cleanly on the cryptodev tree since it
does not seem to be up to date for ux500.
Herbert, how should we handle this, do you want to ack this and we send
it during the merge window or another way ?
Cheers
Andreas
Andreas Westin (2):
mach-ux500: Crypto: core support for CRYP/HASH module.
crypto: ux500: Update DMA handling for 3.4
arch/arm/mach-ux500/board-mop500.c | 48 ++++++++++++++++++++
arch/arm/mach-ux500/clock.c | 18 ++++----
arch/arm/mach-ux500/devices-common.h | 54 +++++++++++++++++++++++
arch/arm/mach-ux500/devices-db8500.h | 4 ++
arch/arm/mach-ux500/id.c | 3 ++
arch/arm/mach-ux500/include/mach/crypto-ux500.h | 1 +
arch/arm/mach-ux500/include/mach/devices.h | 3 ++
drivers/crypto/ux500/cryp/cryp_core.c | 5 +--
drivers/crypto/ux500/hash/hash_core.c | 2 +-
9 files changed, 126 insertions(+), 12 deletions(-)
--
1.7.10
This adds the required platform data and calls to enable
the CRYP/HASH driver.
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Andreas Westin <[email protected]>
---
arch/arm/mach-ux500/board-mop500.c | 48 ++++++++++++++++++++
arch/arm/mach-ux500/clock.c | 18 ++++----
arch/arm/mach-ux500/devices-common.h | 54 +++++++++++++++++++++++
arch/arm/mach-ux500/devices-db8500.h | 4 ++
arch/arm/mach-ux500/id.c | 3 ++
arch/arm/mach-ux500/include/mach/crypto-ux500.h | 1 +
arch/arm/mach-ux500/include/mach/devices.h | 3 ++
7 files changed, 123 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 77d03c1..d622606 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -47,6 +47,7 @@
#include <mach/setup.h>
#include <mach/devices.h>
#include <mach/irqs.h>
+#include <mach/crypto-ux500.h>
#include "pins-db8500.h"
#include "ste-dma40-db8500.h"
@@ -417,6 +418,45 @@ static void mop500_prox_deactivate(struct device *dev)
regulator_put(prox_regulator);
}
+static struct cryp_platform_data u8500_cryp1_platform_data = {
+ .mem_to_engine = {
+ .dir = STEDMA40_MEM_TO_PERIPH,
+ .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
+ .dst_dev_type = DB8500_DMA_DEV48_CAC1_TX,
+ .src_info.data_width = STEDMA40_WORD_WIDTH,
+ .dst_info.data_width = STEDMA40_WORD_WIDTH,
+ .mode = STEDMA40_MODE_LOGICAL,
+ .src_info.psize = STEDMA40_PSIZE_LOG_4,
+ .dst_info.psize = STEDMA40_PSIZE_LOG_4,
+ },
+ .engine_to_mem = {
+ .dir = STEDMA40_PERIPH_TO_MEM,
+ .src_dev_type = DB8500_DMA_DEV48_CAC1_RX,
+ .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .src_info.data_width = STEDMA40_WORD_WIDTH,
+ .dst_info.data_width = STEDMA40_WORD_WIDTH,
+ .mode = STEDMA40_MODE_LOGICAL,
+ .src_info.psize = STEDMA40_PSIZE_LOG_4,
+ .dst_info.psize = STEDMA40_PSIZE_LOG_4,
+ }
+};
+
+static struct stedma40_chan_cfg u8500_hash_dma_cfg_tx = {
+ .dir = STEDMA40_MEM_TO_PERIPH,
+ .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
+ .dst_dev_type = DB8500_DMA_DEV50_HAC1_TX,
+ .src_info.data_width = STEDMA40_WORD_WIDTH,
+ .dst_info.data_width = STEDMA40_WORD_WIDTH,
+ .mode = STEDMA40_MODE_LOGICAL,
+ .src_info.psize = STEDMA40_PSIZE_LOG_16,
+ .dst_info.psize = STEDMA40_PSIZE_LOG_16,
+};
+
+static struct hash_platform_data u8500_hash1_platform_data = {
+ .mem_to_engine = &u8500_hash_dma_cfg_tx,
+ .dma_filter = stedma40_filter,
+};
+
/* add any platform devices here - TODO */
static struct platform_device *mop500_platform_devs[] __initdata = {
&mop500_gpio_keys_device,
@@ -602,6 +642,12 @@ static void __init mop500_uart_init(struct device *parent)
db8500_add_uart2(parent, &uart2_plat);
}
+static void __init u8500_cryp1_hash1_init(struct device *parent)
+{
+ db8500_add_cryp1(parent, &u8500_cryp1_platform_data);
+ db8500_add_hash1(parent, &u8500_hash1_platform_data);
+}
+
static struct platform_device *snowball_platform_devs[] __initdata = {
&snowball_led_dev,
&snowball_key_dev,
@@ -633,6 +679,8 @@ static void __init mop500_init_machine(void)
mop500_spi_init(parent);
mop500_uart_init(parent);
+ u8500_cryp1_hash1_init(parent);
+
i2c0_devs = ARRAY_SIZE(mop500_i2c0_devices);
i2c_register_board_info(0, mop500_i2c0_devices, i2c0_devs);
diff --git a/arch/arm/mach-ux500/clock.c b/arch/arm/mach-ux500/clock.c
index ec35f0a..2efc1fe 100644
--- a/arch/arm/mach-ux500/clock.c
+++ b/arch/arm/mach-ux500/clock.c
@@ -382,14 +382,15 @@ static DEFINE_PRCC_CLK(5, usb, 0, 0, NULL);
/* Peripheral Cluster #6 */
/* MTU ID in data */
-static DEFINE_PRCC_CLK_CUSTOM(6, mtu1, 8, -1, NULL, clk_mtu_get_rate, 1);
-static DEFINE_PRCC_CLK_CUSTOM(6, mtu0, 7, -1, NULL, clk_mtu_get_rate, 0);
-static DEFINE_PRCC_CLK(6, cfgreg, 6, 6, NULL);
-static DEFINE_PRCC_CLK(6, hash1, 5, -1, NULL);
-static DEFINE_PRCC_CLK(6, unipro, 4, 1, &clk_uniproclk);
-static DEFINE_PRCC_CLK(6, pka, 3, -1, NULL);
-static DEFINE_PRCC_CLK(6, hash0, 2, -1, NULL);
-static DEFINE_PRCC_CLK(6, cryp0, 1, -1, NULL);
+static DEFINE_PRCC_CLK_CUSTOM(6, mtu1, 9, -1, NULL, clk_mtu_get_rate, 1);
+static DEFINE_PRCC_CLK_CUSTOM(6, mtu0, 8, -1, NULL, clk_mtu_get_rate, 0);
+static DEFINE_PRCC_CLK(6, cfgreg, 7, 7, NULL);
+static DEFINE_PRCC_CLK(6, hash1, 6, -1, NULL);
+static DEFINE_PRCC_CLK(6, unipro, 5, 1, &clk_uniproclk);
+static DEFINE_PRCC_CLK(6, pka, 4, -1, NULL);
+static DEFINE_PRCC_CLK(6, hash0, 3, -1, NULL);
+static DEFINE_PRCC_CLK(6, cryp0, 2, -1, NULL);
+static DEFINE_PRCC_CLK(6, cryp1, 1, -1, NULL);
static DEFINE_PRCC_CLK(6, rng, 0, 0, &clk_rngclk);
static struct clk clk_dummy_apb_pclk = {
@@ -431,6 +432,7 @@ static struct clk_lookup u8500_clks[] = {
CLK(pka, "pka", NULL),
CLK(hash0, "hash0", NULL),
CLK(cryp0, "cryp0", NULL),
+ CLK(cryp1, "cryp1", NULL),
/* PRCMU level clock gating */
diff --git a/arch/arm/mach-ux500/devices-common.h b/arch/arm/mach-ux500/devices-common.h
index 39c74ec..89c5a59 100644
--- a/arch/arm/mach-ux500/devices-common.h
+++ b/arch/arm/mach-ux500/devices-common.h
@@ -12,12 +12,17 @@
#include <linux/dma-mapping.h>
#include <linux/sys_soc.h>
#include <plat/i2c.h>
+#include <mach/crypto-ux500.h>
extern struct amba_device *
dbx500_add_amba_device(struct device *parent, const char *name,
resource_size_t base, int irq, void *pdata,
unsigned int periphid);
+extern struct platform_device *
+dbx500_add_platform_device_noirq(const char *name, int id,
+ resource_size_t base, void *pdata);
+
struct spi_master_cntlr;
static inline struct amba_device *
@@ -88,6 +93,55 @@ dbx500_add_rtc(struct device *parent, resource_size_t base, int irq)
return dbx500_add_amba_device(parent, "rtc-pl031", base, irq, NULL, 0);
}
+struct cryp_platform_data;
+
+static inline struct platform_device *
+dbx500_add_cryp1(struct device *parent, int id, resource_size_t base, int irq,
+ struct cryp_platform_data *pdata)
+{
+ struct resource res[] = {
+ DEFINE_RES_MEM(base, SZ_4K),
+ DEFINE_RES_IRQ(irq),
+ };
+
+ struct platform_device_info pdevinfo = {
+ .parent = parent,
+ .name = "cryp1",
+ .id = id,
+ .res = res,
+ .num_res = ARRAY_SIZE(res),
+ .data = pdata,
+ .size_data = sizeof(*pdata),
+ .dma_mask = DMA_BIT_MASK(32),
+ };
+
+ return platform_device_register_full(&pdevinfo);
+}
+
+struct hash_platform_data;
+
+static inline struct platform_device *
+dbx500_add_hash1(struct device *parent, int id, resource_size_t base,
+ struct hash_platform_data *pdata)
+{
+ struct resource res[] = {
+ DEFINE_RES_MEM(base, SZ_4K),
+ };
+
+ struct platform_device_info pdevinfo = {
+ .parent = parent,
+ .name = "hash1",
+ .id = id,
+ .res = res,
+ .num_res = ARRAY_SIZE(res),
+ .data = pdata,
+ .size_data = sizeof(*pdata),
+ .dma_mask = DMA_BIT_MASK(32),
+ };
+
+ return platform_device_register_full(&pdevinfo);
+}
+
struct nmk_gpio_platform_data;
void dbx500_add_gpios(struct device *parent, resource_size_t *base, int num,
diff --git a/arch/arm/mach-ux500/devices-db8500.h b/arch/arm/mach-ux500/devices-db8500.h
index 9fd93e9..cdf5ca8 100644
--- a/arch/arm/mach-ux500/devices-db8500.h
+++ b/arch/arm/mach-ux500/devices-db8500.h
@@ -124,4 +124,8 @@ db8500_add_ssp(struct device *parent, const char *name, resource_size_t base,
dbx500_add_uart(parent, "uart2", U8500_UART2_BASE, \
IRQ_DB8500_UART2, pdata)
+#define db8500_add_cryp1(parent, pdata) \
+ dbx500_add_cryp1(parent, -1, U8500_CRYP1_BASE, IRQ_DB8500_CRYP1, pdata)
+#define db8500_add_hash1(parent, pdata) \
+ dbx500_add_hash1(parent, -1, U8500_HASH1_BASE, pdata)
#endif
diff --git a/arch/arm/mach-ux500/id.c b/arch/arm/mach-ux500/id.c
index 15a0f63..a69db46 100644
--- a/arch/arm/mach-ux500/id.c
+++ b/arch/arm/mach-ux500/id.c
@@ -17,7 +17,10 @@
#include <mach/hardware.h>
#include <mach/setup.h>
+#include <linux/module.h>
+
struct dbx500_asic_id dbx500_id;
+EXPORT_SYMBOL(dbx500_id);
static unsigned int ux500_read_asicid(phys_addr_t addr)
{
diff --git a/arch/arm/mach-ux500/include/mach/crypto-ux500.h b/arch/arm/mach-ux500/include/mach/crypto-ux500.h
index de40add..5b2d081 100644
--- a/arch/arm/mach-ux500/include/mach/crypto-ux500.h
+++ b/arch/arm/mach-ux500/include/mach/crypto-ux500.h
@@ -5,6 +5,7 @@
* License terms: GNU General Public License (GPL) version 2
*/
#ifndef _CRYPTO_UX500_H
+#define _CRYPTO_UX500_H
#include <linux/dmaengine.h>
#include <plat/ste_dma40.h>
diff --git a/arch/arm/mach-ux500/include/mach/devices.h b/arch/arm/mach-ux500/include/mach/devices.h
index 5f6cb71..a55454a 100644
--- a/arch/arm/mach-ux500/include/mach/devices.h
+++ b/arch/arm/mach-ux500/include/mach/devices.h
@@ -15,6 +15,9 @@ extern struct platform_device u8500_gpio_devs[];
extern struct amba_device ux500_pl031_device;
+extern struct platform_device ux500_hash1_device;
+extern struct platform_device ux500_cryp1_device;
+
extern struct platform_device u8500_dma40_device;
extern struct platform_device ux500_ske_keypad_device;
--
1.7.10
An update to the DMA framework added a new parameter to the
device_prep_slave_sg call.
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Andreas Westin <[email protected]>
---
drivers/crypto/ux500/cryp/cryp_core.c | 5 ++---
drivers/crypto/ux500/hash/hash_core.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/ux500/cryp/cryp_core.c b/drivers/crypto/ux500/cryp/cryp_core.c
index 7051e00..7cac127 100644
--- a/drivers/crypto/ux500/cryp/cryp_core.c
+++ b/drivers/crypto/ux500/cryp/cryp_core.c
@@ -542,8 +542,7 @@ static int cryp_set_dma_transfer(struct cryp_ctx *ctx,
desc = channel->device->device_prep_slave_sg(channel,
ctx->device->dma.sg_src,
ctx->device->dma.sg_src_len,
- direction,
- DMA_CTRL_ACK);
+ direction, DMA_CTRL_ACK, NULL);
break;
case DMA_FROM_DEVICE:
@@ -569,7 +568,7 @@ static int cryp_set_dma_transfer(struct cryp_ctx *ctx,
ctx->device->dma.sg_dst_len,
direction,
DMA_CTRL_ACK |
- DMA_PREP_INTERRUPT);
+ DMA_PREP_INTERRUPT, NULL);
desc->callback = cryp_dma_out_callback;
desc->callback_param = ctx;
diff --git a/drivers/crypto/ux500/hash/hash_core.c b/drivers/crypto/ux500/hash/hash_core.c
index cc6a371..77f7508 100644
--- a/drivers/crypto/ux500/hash/hash_core.c
+++ b/drivers/crypto/ux500/hash/hash_core.c
@@ -174,7 +174,7 @@ static int hash_set_dma_transfer(struct hash_ctx *ctx, struct scatterlist *sg,
"(TO_DEVICE)", __func__);
desc = channel->device->device_prep_slave_sg(channel,
ctx->device->dma.sg, ctx->device->dma.sg_len,
- direction, DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+ direction, DMA_CTRL_ACK | DMA_PREP_INTERRUPT, NULL);
if (!desc) {
dev_err(ctx->device->dev,
"[%s]: device_prep_slave_sg() failed!", __func__);
--
1.7.10
On Tuesday 08 May 2012, Andreas Westin wrote:
> This adds the required platform data and calls to enable
> the CRYP/HASH driver.
>
> index 15a0f63..a69db46 100644
> --- a/arch/arm/mach-ux500/id.c
> +++ b/arch/arm/mach-ux500/id.c
> @@ -17,7 +17,10 @@
> #include <mach/hardware.h>
> #include <mach/setup.h>
>
> +#include <linux/module.h>
> +
> struct dbx500_asic_id dbx500_id;
> +EXPORT_SYMBOL(dbx500_id);
>
> static unsigned int ux500_read_asicid(phys_addr_t addr)
> {
This needs an explanation! Why do you export an internal data structure
to non-GPL modules?
On a more general topic, I wonder if it's really necessary to add new
devices to the legacy probing path in mach-ux500. Why not make new drivers
for this platform dt-only, so we don't need to add code now that we will
have to remove again in one or two kernel releases?
Arnd
On Tue, May 8, 2012 at 9:37 PM, Arnd Bergmann <[email protected]> wrote:
> On Tuesday 08 May 2012, Andreas Westin wrote:
>> This adds the required platform data and calls to enable
>> the CRYP/HASH driver.
>>
>> index 15a0f63..a69db46 100644
>> --- a/arch/arm/mach-ux500/id.c
>> +++ b/arch/arm/mach-ux500/id.c
>> @@ -17,7 +17,10 @@
>> ?#include <mach/hardware.h>
>> ?#include <mach/setup.h>
>>
>> +#include <linux/module.h>
>> +
>> ?struct dbx500_asic_id dbx500_id;
>> +EXPORT_SYMBOL(dbx500_id);
>>
>> ?static unsigned int ux500_read_asicid(phys_addr_t addr)
>> ?{
>
> This needs an explanation! Why do you export an internal data structure
> to non-GPL modules?
This does not look like it's needed at all, none of the other two patches use
it. Andreas can you just drop this hunk of the patch?
BTW if the asic variant is needed by some driver use cpu_is_*() from
<mach/id.h> or pass a flag in platform data or something.
> On a more general topic, I wonder if it's really necessary to add new
> devices to the legacy probing path in mach-ux500. Why not make new drivers
> for this platform dt-only, so we don't need to add code now that we will
> have to remove again in one or two kernel releases?
This is a simple platform_device which means that its IRQ/PIO mode is
already supported with standard bindings if you instantiate the device
from drivers/of/platform.c using the generic bindings for platform devices
and their resources.
The only thing that is passed in platform data, as you can see is the
DMA channels and configuration, which is debated elsewhere I
think. The day we know how to pass DMA channels to any platform/amba
device this device should be trivial to fully support with DT.
Yours,
Linus Walleij
On 2012-05-09 10:36, Linus Walleij wrote:
>> This needs an explanation! Why do you export an internal data structure
>> to non-GPL modules?
>
> This does not look like it's needed at all, none of the other two patches use
> it. Andreas can you just drop this hunk of the patch?
It is needed if you compile the drivers as modules, but it should be a
GPL export. I will change it.
Cheers
Andreas
On Wednesday 09 May 2012, Andreas WESTIN wrote:
> On 2012-05-09 10:36, Linus Walleij wrote:
> >> This needs an explanation! Why do you export an internal data structure
> >> to non-GPL modules?
> >
> > This does not look like it's needed at all, none of the other two patches use
> > it. Andreas can you just drop this hunk of the patch?
>
> It is needed if you compile the drivers as modules, but it should be a
> GPL export. I will change it.
How about using distinct identification strings for each version of the
crypto hardware? The driver should really only care about what kind
of device it is talking to, not which SoC it is built into.
Arnd
On Wed, May 9, 2012 at 2:17 PM, Arnd Bergmann <[email protected]> wrote:
> On Wednesday 09 May 2012, Andreas WESTIN wrote:
>> On 2012-05-09 10:36, Linus Walleij wrote:
>> >> This needs an explanation! Why do you export an internal data structure
>> >> to non-GPL modules?
>> >
>> > This does not look like it's needed at all, none of the other two patches use
>> > it. Andreas can you just drop this hunk of the patch?
>>
>> It is needed if you compile the drivers as modules, but it should be a
>> GPL export. I will change it.
>
> How about using distinct identification strings for each version of the
> crypto hardware? The driver should really only care about what kind
> of device it is talking to, not which SoC it is built into.
Do you mean like this (from a recent pinctrl driver):
static int __devinit nmk_pinctrl_probe(struct platform_device *pdev)
{
const struct platform_device_id *platid = platform_get_device_id(pdev);
....
(Here we use that ID to control runtime codepath)
}
static const struct platform_device_id nmk_pinctrl_id[] = {
{ "pinctrl-stn8815", PINCTRL_NMK_STN8815 },
{ "pinctrl-db8500", PINCTRL_NMK_DB8500 },
};
static struct platform_driver nmk_pinctrl_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "pinctrl-nomadik",
},
.probe = nmk_pinctrl_probe,
.id_table = nmk_pinctrl_id,
};
Here one version of ASIC registers the "pinctrl-db8500" device.
And so on.
So instead of registering "cryp1" and "hash1", register
"db8500-cryp-v1", "db8500-cryp-v2" etc for the versions,
then use the ID to control code path.
Is that what you were thinking of?
That might be a good idea, however it requires some changes to patches
earlier in the series (but can be done as an incremental add-on of
course).
Yours,
Linus Walleij
On 2012-05-09 15:09, Linus Walleij wrote:
>>
>> How about using distinct identification strings for each version of the
>> crypto hardware? The driver should really only care about what kind
>> of device it is talking to, not which SoC it is built into.
>
> Do you mean like this (from a recent pinctrl driver):
>
> static int __devinit nmk_pinctrl_probe(struct platform_device *pdev)
> {
> const struct platform_device_id *platid = platform_get_device_id(pdev);
> ....
> (Here we use that ID to control runtime codepath)
> }
>
> static const struct platform_device_id nmk_pinctrl_id[] = {
> { "pinctrl-stn8815", PINCTRL_NMK_STN8815 },
> { "pinctrl-db8500", PINCTRL_NMK_DB8500 },
> };
>
> static struct platform_driver nmk_pinctrl_driver = {
> .driver = {
> .owner = THIS_MODULE,
> .name = "pinctrl-nomadik",
> },
> .probe = nmk_pinctrl_probe,
> .id_table = nmk_pinctrl_id,
> };
>
> Here one version of ASIC registers the "pinctrl-db8500" device.
> And so on.
>
> So instead of registering "cryp1" and "hash1", register
> "db8500-cryp-v1", "db8500-cryp-v2" etc for the versions,
> then use the ID to control code path.
>
> Is that what you were thinking of?
>
No, I think Arnd is referring to the registers in the crypto hardware,
I'm preparing a patch for that.
Regards
Andreas
On Wednesday 09 May 2012, Linus Walleij wrote:
> On Wed, May 9, 2012 at 2:17 PM, Arnd Bergmann <[email protected]> wrote:
> > How about using distinct identification strings for each version of the
> > crypto hardware? The driver should really only care about what kind
> > of device it is talking to, not which SoC it is built into.
>
> Do you mean like this (from a recent pinctrl driver):
>
> static int __devinit nmk_pinctrl_probe(struct platform_device *pdev)
> {
> const struct platform_device_id *platid = platform_get_device_id(pdev);
> ....
> (Here we use that ID to control runtime codepath)
> }
>
> static const struct platform_device_id nmk_pinctrl_id[] = {
> { "pinctrl-stn8815", PINCTRL_NMK_STN8815 },
> { "pinctrl-db8500", PINCTRL_NMK_DB8500 },
> };
>
> static struct platform_driver nmk_pinctrl_driver = {
> .driver = {
> .owner = THIS_MODULE,
> .name = "pinctrl-nomadik",
> },
> .probe = nmk_pinctrl_probe,
> .id_table = nmk_pinctrl_id,
> };
>
> Here one version of ASIC registers the "pinctrl-db8500" device.
> And so on.
>
> So instead of registering "cryp1" and "hash1", register
> "db8500-cryp-v1", "db8500-cryp-v2" etc for the versions,
> then use the ID to control code path.
>
> Is that what you were thinking of?
Yes, exactly.
Arnd
On 2012-05-09 15:47, Arnd Bergmann wrote:
>
> Yes, exactly.
>
Ok so I assumed wrong, I will look into it.
Cheers
Andreas