2013-04-30 03:17:12 +04:00
|
|
|
/*
|
|
|
|
* Generic on-chip SRAM allocation driver
|
|
|
|
*
|
|
|
|
* Copyright (C) 2012 Philipp Zabel, Pengutronix
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
|
|
|
|
* MA 02110-1301, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/clk.h>
|
2016-09-22 01:09:38 +03:00
|
|
|
#include <linux/delay.h>
|
2015-06-01 15:30:00 +03:00
|
|
|
#include <linux/genalloc.h>
|
2013-04-30 03:17:12 +04:00
|
|
|
#include <linux/io.h>
|
2014-02-25 15:46:34 +04:00
|
|
|
#include <linux/list_sort.h>
|
2015-06-01 15:30:00 +03:00
|
|
|
#include <linux/of_address.h>
|
2016-09-22 01:09:38 +03:00
|
|
|
#include <linux/of_device.h>
|
2013-04-30 03:17:12 +04:00
|
|
|
#include <linux/platform_device.h>
|
2016-09-22 01:09:38 +03:00
|
|
|
#include <linux/regmap.h>
|
2013-04-30 03:17:12 +04:00
|
|
|
#include <linux/slab.h>
|
2016-09-22 01:09:38 +03:00
|
|
|
#include <linux/mfd/syscon.h>
|
|
|
|
#include <soc/at91/atmel-secumod.h>
|
2013-04-30 03:17:12 +04:00
|
|
|
|
2017-01-12 23:52:18 +03:00
|
|
|
#include "sram.h"
|
2015-06-01 15:29:58 +03:00
|
|
|
|
2017-01-12 23:52:18 +03:00
|
|
|
#define SRAM_GRANULARITY 32
|
2014-02-25 15:46:34 +04:00
|
|
|
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
static ssize_t sram_read(struct file *filp, struct kobject *kobj,
|
|
|
|
struct bin_attribute *attr,
|
|
|
|
char *buf, loff_t pos, size_t count)
|
|
|
|
{
|
|
|
|
struct sram_partition *part;
|
|
|
|
|
|
|
|
part = container_of(attr, struct sram_partition, battr);
|
|
|
|
|
|
|
|
mutex_lock(&part->lock);
|
2015-10-18 20:57:09 +03:00
|
|
|
memcpy_fromio(buf, part->base + pos, count);
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
mutex_unlock(&part->lock);
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t sram_write(struct file *filp, struct kobject *kobj,
|
|
|
|
struct bin_attribute *attr,
|
|
|
|
char *buf, loff_t pos, size_t count)
|
|
|
|
{
|
|
|
|
struct sram_partition *part;
|
|
|
|
|
|
|
|
part = container_of(attr, struct sram_partition, battr);
|
|
|
|
|
|
|
|
mutex_lock(&part->lock);
|
2015-10-18 20:57:09 +03:00
|
|
|
memcpy_toio(part->base + pos, buf, count);
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
mutex_unlock(&part->lock);
|
|
|
|
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int sram_add_pool(struct sram_dev *sram, struct sram_reserve *block,
|
|
|
|
phys_addr_t start, struct sram_partition *part)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
part->pool = devm_gen_pool_create(sram->dev, ilog2(SRAM_GRANULARITY),
|
|
|
|
NUMA_NO_NODE, block->label);
|
|
|
|
if (IS_ERR(part->pool))
|
|
|
|
return PTR_ERR(part->pool);
|
|
|
|
|
|
|
|
ret = gen_pool_add_virt(part->pool, (unsigned long)part->base, start,
|
|
|
|
block->size, NUMA_NO_NODE);
|
|
|
|
if (ret < 0) {
|
|
|
|
dev_err(sram->dev, "failed to register subpool: %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int sram_add_export(struct sram_dev *sram, struct sram_reserve *block,
|
|
|
|
phys_addr_t start, struct sram_partition *part)
|
|
|
|
{
|
|
|
|
sysfs_bin_attr_init(&part->battr);
|
|
|
|
part->battr.attr.name = devm_kasprintf(sram->dev, GFP_KERNEL,
|
|
|
|
"%llx.sram",
|
|
|
|
(unsigned long long)start);
|
|
|
|
if (!part->battr.attr.name)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
part->battr.attr.mode = S_IRUSR | S_IWUSR;
|
|
|
|
part->battr.read = sram_read;
|
|
|
|
part->battr.write = sram_write;
|
|
|
|
part->battr.size = block->size;
|
|
|
|
|
|
|
|
return device_create_bin_file(sram->dev, &part->battr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int sram_add_partition(struct sram_dev *sram, struct sram_reserve *block,
|
|
|
|
phys_addr_t start)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct sram_partition *part = &sram->partition[sram->partitions];
|
|
|
|
|
|
|
|
mutex_init(&part->lock);
|
|
|
|
part->base = sram->virt_base + block->start;
|
|
|
|
|
|
|
|
if (block->pool) {
|
|
|
|
ret = sram_add_pool(sram, block, start, part);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
if (block->export) {
|
|
|
|
ret = sram_add_export(sram, block, start, part);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2017-01-12 23:52:20 +03:00
|
|
|
if (block->protect_exec) {
|
|
|
|
ret = sram_check_protect_exec(sram, block, part);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = sram_add_pool(sram, block, start, part);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
sram_add_protect_exec(part);
|
|
|
|
}
|
|
|
|
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
sram->partitions++;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void sram_free_partitions(struct sram_dev *sram)
|
|
|
|
{
|
|
|
|
struct sram_partition *part;
|
|
|
|
|
|
|
|
if (!sram->partitions)
|
|
|
|
return;
|
|
|
|
|
|
|
|
part = &sram->partition[sram->partitions - 1];
|
|
|
|
for (; sram->partitions; sram->partitions--, part--) {
|
|
|
|
if (part->battr.size)
|
|
|
|
device_remove_bin_file(sram->dev, &part->battr);
|
|
|
|
|
|
|
|
if (part->pool &&
|
|
|
|
gen_pool_avail(part->pool) < gen_pool_size(part->pool))
|
|
|
|
dev_err(sram->dev, "removed pool while SRAM allocated\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-25 15:46:34 +04:00
|
|
|
static int sram_reserve_cmp(void *priv, struct list_head *a,
|
|
|
|
struct list_head *b)
|
|
|
|
{
|
|
|
|
struct sram_reserve *ra = list_entry(a, struct sram_reserve, list);
|
|
|
|
struct sram_reserve *rb = list_entry(b, struct sram_reserve, list);
|
|
|
|
|
|
|
|
return ra->start - rb->start;
|
|
|
|
}
|
|
|
|
|
2015-06-01 15:29:59 +03:00
|
|
|
static int sram_reserve_regions(struct sram_dev *sram, struct resource *res)
|
2013-04-30 03:17:12 +04:00
|
|
|
{
|
2015-06-01 15:29:59 +03:00
|
|
|
struct device_node *np = sram->dev->of_node, *child;
|
2014-02-25 15:46:34 +04:00
|
|
|
unsigned long size, cur_start, cur_size;
|
|
|
|
struct sram_reserve *rblocks, *block;
|
|
|
|
struct list_head reserve_list;
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
unsigned int nblocks, exports = 0;
|
|
|
|
const char *label;
|
2015-06-01 15:29:59 +03:00
|
|
|
int ret = 0;
|
2013-04-30 03:17:12 +04:00
|
|
|
|
2014-02-25 15:46:34 +04:00
|
|
|
INIT_LIST_HEAD(&reserve_list);
|
|
|
|
|
2013-06-10 18:43:53 +04:00
|
|
|
size = resource_size(res);
|
2013-04-30 03:17:12 +04:00
|
|
|
|
2014-02-25 15:46:34 +04:00
|
|
|
/*
|
|
|
|
* We need an additional block to mark the end of the memory region
|
|
|
|
* after the reserved blocks from the dt are processed.
|
|
|
|
*/
|
|
|
|
nblocks = (np) ? of_get_available_child_count(np) + 1 : 1;
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
rblocks = kzalloc((nblocks) * sizeof(*rblocks), GFP_KERNEL);
|
2015-06-01 15:29:54 +03:00
|
|
|
if (!rblocks)
|
|
|
|
return -ENOMEM;
|
2013-04-30 03:17:12 +04:00
|
|
|
|
2014-02-25 15:46:34 +04:00
|
|
|
block = &rblocks[0];
|
|
|
|
for_each_available_child_of_node(np, child) {
|
|
|
|
struct resource child_res;
|
|
|
|
|
|
|
|
ret = of_address_to_resource(child, 0, &child_res);
|
|
|
|
if (ret < 0) {
|
2015-06-01 15:29:58 +03:00
|
|
|
dev_err(sram->dev,
|
2017-07-19 00:43:15 +03:00
|
|
|
"could not get address for node %pOF\n",
|
|
|
|
child);
|
2014-02-25 15:46:34 +04:00
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (child_res.start < res->start || child_res.end > res->end) {
|
2015-06-01 15:29:58 +03:00
|
|
|
dev_err(sram->dev,
|
2017-07-19 00:43:15 +03:00
|
|
|
"reserved block %pOF outside the sram area\n",
|
|
|
|
child);
|
2014-02-25 15:46:34 +04:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
|
|
|
|
block->start = child_res.start - res->start;
|
|
|
|
block->size = resource_size(&child_res);
|
|
|
|
list_add_tail(&block->list, &reserve_list);
|
|
|
|
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
if (of_find_property(child, "export", NULL))
|
|
|
|
block->export = true;
|
|
|
|
|
|
|
|
if (of_find_property(child, "pool", NULL))
|
|
|
|
block->pool = true;
|
|
|
|
|
2017-01-12 23:52:20 +03:00
|
|
|
if (of_find_property(child, "protect-exec", NULL))
|
|
|
|
block->protect_exec = true;
|
|
|
|
|
|
|
|
if ((block->export || block->pool || block->protect_exec) &&
|
|
|
|
block->size) {
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
exports++;
|
|
|
|
|
|
|
|
label = NULL;
|
|
|
|
ret = of_property_read_string(child, "label", &label);
|
|
|
|
if (ret && ret != -EINVAL) {
|
|
|
|
dev_err(sram->dev,
|
2017-07-19 00:43:15 +03:00
|
|
|
"%pOF has invalid label name\n",
|
|
|
|
child);
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
if (!label)
|
|
|
|
label = child->name;
|
|
|
|
|
|
|
|
block->label = devm_kstrdup(sram->dev,
|
|
|
|
label, GFP_KERNEL);
|
2016-12-03 12:29:28 +03:00
|
|
|
if (!block->label) {
|
|
|
|
ret = -ENOMEM;
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
goto err_chunks;
|
2016-12-03 12:29:28 +03:00
|
|
|
}
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
|
|
|
|
dev_dbg(sram->dev, "found %sblock '%s' 0x%x-0x%x\n",
|
|
|
|
block->export ? "exported " : "", block->label,
|
|
|
|
block->start, block->start + block->size);
|
|
|
|
} else {
|
|
|
|
dev_dbg(sram->dev, "found reserved block 0x%x-0x%x\n",
|
|
|
|
block->start, block->start + block->size);
|
|
|
|
}
|
2014-02-25 15:46:34 +04:00
|
|
|
|
|
|
|
block++;
|
|
|
|
}
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
child = NULL;
|
2014-02-25 15:46:34 +04:00
|
|
|
|
|
|
|
/* the last chunk marks the end of the region */
|
|
|
|
rblocks[nblocks - 1].start = size;
|
|
|
|
rblocks[nblocks - 1].size = 0;
|
|
|
|
list_add_tail(&rblocks[nblocks - 1].list, &reserve_list);
|
|
|
|
|
|
|
|
list_sort(NULL, &reserve_list, sram_reserve_cmp);
|
|
|
|
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
if (exports) {
|
|
|
|
sram->partition = devm_kzalloc(sram->dev,
|
|
|
|
exports * sizeof(*sram->partition),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!sram->partition) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
}
|
2014-02-25 15:46:34 +04:00
|
|
|
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
cur_start = 0;
|
2014-02-25 15:46:34 +04:00
|
|
|
list_for_each_entry(block, &reserve_list, list) {
|
|
|
|
/* can only happen if sections overlap */
|
|
|
|
if (block->start < cur_start) {
|
2015-06-01 15:29:58 +03:00
|
|
|
dev_err(sram->dev,
|
2014-02-25 15:46:34 +04:00
|
|
|
"block at 0x%x starts after current offset 0x%lx\n",
|
|
|
|
block->start, cur_start);
|
|
|
|
ret = -EINVAL;
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
sram_free_partitions(sram);
|
2014-02-25 15:46:34 +04:00
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
|
2017-01-12 23:52:20 +03:00
|
|
|
if ((block->export || block->pool || block->protect_exec) &&
|
|
|
|
block->size) {
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
ret = sram_add_partition(sram, block,
|
|
|
|
res->start + block->start);
|
|
|
|
if (ret) {
|
|
|
|
sram_free_partitions(sram);
|
|
|
|
goto err_chunks;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-02-25 15:46:34 +04:00
|
|
|
/* current start is in a reserved block, so continue after it */
|
|
|
|
if (block->start == cur_start) {
|
|
|
|
cur_start = block->start + block->size;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* allocate the space between the current starting
|
|
|
|
* address and the following reserved block, or the
|
|
|
|
* end of the region.
|
|
|
|
*/
|
|
|
|
cur_size = block->start - cur_start;
|
|
|
|
|
2015-06-01 15:29:58 +03:00
|
|
|
dev_dbg(sram->dev, "adding chunk 0x%lx-0x%lx\n",
|
2014-02-25 15:46:34 +04:00
|
|
|
cur_start, cur_start + cur_size);
|
2015-06-01 15:29:58 +03:00
|
|
|
|
2014-02-25 15:46:34 +04:00
|
|
|
ret = gen_pool_add_virt(sram->pool,
|
2015-06-01 15:29:58 +03:00
|
|
|
(unsigned long)sram->virt_base + cur_start,
|
2014-02-25 15:46:34 +04:00
|
|
|
res->start + cur_start, cur_size, -1);
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
if (ret < 0) {
|
|
|
|
sram_free_partitions(sram);
|
2014-02-25 15:46:34 +04:00
|
|
|
goto err_chunks;
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
}
|
2014-02-25 15:46:34 +04:00
|
|
|
|
|
|
|
/* next allocation after this reserved block */
|
|
|
|
cur_start = block->start + block->size;
|
|
|
|
}
|
|
|
|
|
2015-06-01 15:29:59 +03:00
|
|
|
err_chunks:
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
if (child)
|
|
|
|
of_node_put(child);
|
|
|
|
|
2014-02-25 15:46:34 +04:00
|
|
|
kfree(rblocks);
|
|
|
|
|
2015-06-01 15:29:59 +03:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-09-22 01:09:38 +03:00
|
|
|
static int atmel_securam_wait(void)
|
|
|
|
{
|
|
|
|
struct regmap *regmap;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-secumod");
|
|
|
|
if (IS_ERR(regmap))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
return regmap_read_poll_timeout(regmap, AT91_SECUMOD_RAMRDY, val,
|
|
|
|
val & AT91_SECUMOD_RAMRDY_READY,
|
|
|
|
10000, 500000);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct of_device_id sram_dt_ids[] = {
|
|
|
|
{ .compatible = "mmio-sram" },
|
|
|
|
{ .compatible = "atmel,sama5d2-securam", .data = atmel_securam_wait },
|
|
|
|
{}
|
|
|
|
};
|
|
|
|
|
2015-06-01 15:29:59 +03:00
|
|
|
static int sram_probe(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct sram_dev *sram;
|
|
|
|
struct resource *res;
|
|
|
|
size_t size;
|
|
|
|
int ret;
|
2016-09-22 01:09:38 +03:00
|
|
|
int (*init_func)(void);
|
2015-06-01 15:29:59 +03:00
|
|
|
|
|
|
|
sram = devm_kzalloc(&pdev->dev, sizeof(*sram), GFP_KERNEL);
|
|
|
|
if (!sram)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
sram->dev = &pdev->dev;
|
|
|
|
|
|
|
|
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
|
|
|
|
if (!res) {
|
|
|
|
dev_err(sram->dev, "found no memory resource\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
size = resource_size(res);
|
|
|
|
|
|
|
|
if (!devm_request_mem_region(sram->dev, res->start, size, pdev->name)) {
|
|
|
|
dev_err(sram->dev, "could not request region for resource\n");
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
2016-03-14 11:38:56 +03:00
|
|
|
if (of_property_read_bool(pdev->dev.of_node, "no-memory-wc"))
|
|
|
|
sram->virt_base = devm_ioremap(sram->dev, res->start, size);
|
|
|
|
else
|
|
|
|
sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size);
|
2016-03-23 05:52:45 +03:00
|
|
|
if (!sram->virt_base)
|
|
|
|
return -ENOMEM;
|
2015-06-01 15:29:59 +03:00
|
|
|
|
2015-09-05 01:47:43 +03:00
|
|
|
sram->pool = devm_gen_pool_create(sram->dev, ilog2(SRAM_GRANULARITY),
|
|
|
|
NUMA_NO_NODE, NULL);
|
|
|
|
if (IS_ERR(sram->pool))
|
|
|
|
return PTR_ERR(sram->pool);
|
2015-06-01 15:29:59 +03:00
|
|
|
|
|
|
|
ret = sram_reserve_regions(sram, res);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2015-06-01 15:29:58 +03:00
|
|
|
sram->clk = devm_clk_get(sram->dev, NULL);
|
2015-06-01 15:29:54 +03:00
|
|
|
if (IS_ERR(sram->clk))
|
|
|
|
sram->clk = NULL;
|
|
|
|
else
|
|
|
|
clk_prepare_enable(sram->clk);
|
|
|
|
|
2013-04-30 03:17:12 +04:00
|
|
|
platform_set_drvdata(pdev, sram);
|
|
|
|
|
2016-09-22 01:09:38 +03:00
|
|
|
init_func = of_device_get_match_data(&pdev->dev);
|
|
|
|
if (init_func) {
|
|
|
|
ret = init_func();
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-06-01 15:29:58 +03:00
|
|
|
dev_dbg(sram->dev, "SRAM pool: %zu KiB @ 0x%p\n",
|
|
|
|
gen_pool_size(sram->pool) / 1024, sram->virt_base);
|
2013-04-30 03:17:12 +04:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int sram_remove(struct platform_device *pdev)
|
|
|
|
{
|
|
|
|
struct sram_dev *sram = platform_get_drvdata(pdev);
|
|
|
|
|
misc: sram: extend usage of reserved partitions
This change adds functionality to operate on reserved SRAM partitions
described in device tree file. Two partition properties are added,
"pool" and "export", the first one allows to share a specific partition
for usage by a kernel consumer in the same manner as it is done for
the whole SRAM device, and "export" property provides access to some
SRAM area from userspace over sysfs interface. Practically it is
possible to specify both properties for an SRAM partition, however
simultaneous access from a kernel consumer and from userspace is not
serialized, but still the combination may be useful for debugging
purpose.
The change opens the following scenarios of SRAM usage:
* updates in a particular SRAM area specified by offset and size are
done by bootloader, then this information is utilized by the kernel,
* a particular SRAM area is rw accessed from userspace, the stored
data is persistent on soft reboots,
* a device driver secures SRAM area for its purposes,
* etc.
Note, strictly speaking the added optional properties describe policy
of SRAM usage, rather than hardware, but here the policy mostly
resembles flash partitions in devicetree, which is undoubtedly
a very popular option but it does not describe hardware.
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-09-21 23:52:46 +03:00
|
|
|
sram_free_partitions(sram);
|
|
|
|
|
2013-04-30 03:17:12 +04:00
|
|
|
if (gen_pool_avail(sram->pool) < gen_pool_size(sram->pool))
|
2015-06-01 15:29:58 +03:00
|
|
|
dev_err(sram->dev, "removed while SRAM allocated\n");
|
2013-04-30 03:17:12 +04:00
|
|
|
|
|
|
|
if (sram->clk)
|
|
|
|
clk_disable_unprepare(sram->clk);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct platform_driver sram_driver = {
|
|
|
|
.driver = {
|
|
|
|
.name = "sram",
|
2016-11-22 17:30:54 +03:00
|
|
|
.of_match_table = sram_dt_ids,
|
2013-04-30 03:17:12 +04:00
|
|
|
},
|
|
|
|
.probe = sram_probe,
|
|
|
|
.remove = sram_remove,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __init sram_init(void)
|
|
|
|
{
|
|
|
|
return platform_driver_register(&sram_driver);
|
|
|
|
}
|
|
|
|
|
|
|
|
postcore_initcall(sram_init);
|