* [PATCH RFC 02/15 v5] gpio: Add sysfs support to block GPIO API
From: Roland Stigge @ 2012-10-17 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350477107-26512-1-git-send-email-stigge@antcom.de>
This patch adds sysfs support to the block GPIO API.
Signed-off-by: Roland Stigge <stigge@antcom.de>
---
Documentation/ABI/testing/sysfs-gpio | 6
drivers/gpio/gpiolib.c | 214 +++++++++++++++++++++++++++++++++++
include/asm-generic/gpio.h | 11 +
include/linux/gpio.h | 13 ++
4 files changed, 243 insertions(+), 1 deletion(-)
--- linux-2.6.orig/Documentation/ABI/testing/sysfs-gpio
+++ linux-2.6/Documentation/ABI/testing/sysfs-gpio
@@ -24,4 +24,8 @@ Description:
/base ... (r/o) same as N
/label ... (r/o) descriptive, not necessarily unique
/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)
-
+ /blockN ... for each GPIO block #N
+ /ngpio ... (r/o) number of GPIOs in this group
+ /exported ... sysfs export state of this group (0, 1)
+ /value ... current value as 32 or 64 bit integer in decimal
+ (only available if /exported is 1)
--- linux-2.6.orig/drivers/gpio/gpiolib.c
+++ linux-2.6/drivers/gpio/gpiolib.c
@@ -972,6 +972,214 @@ static void gpiochip_unexport(struct gpi
chip->label, status);
}
+static ssize_t gpio_block_ngpio_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ const struct gpio_block *block = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%u\n", block->ngpio);
+}
+
+static ssize_t gpio_block_value_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ const struct gpio_block *block = dev_get_drvdata(dev);
+
+ return sprintf(buf, sizeof(unsigned long) == 4 ? "0x%08lx\n" :
+ "0x%016lx\n", gpio_block_get(block));
+}
+
+static bool gpio_block_is_output(struct gpio_block *block)
+{
+ int i;
+
+ for (i = 0; i < block->ngpio; i++)
+ if (!test_bit(FLAG_IS_OUT, &gpio_desc[block->gpio[i]].flags))
+ return false;
+ return true;
+}
+
+static ssize_t gpio_block_value_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ ssize_t status;
+ struct gpio_block *block = dev_get_drvdata(dev);
+ unsigned long value;
+
+ status = kstrtoul(buf, 0, &value);
+ if (status == 0) {
+ mutex_lock(&sysfs_lock);
+ if (gpio_block_is_output(block)) {
+ gpio_block_set(block, value);
+ status = size;
+ } else {
+ status = -EPERM;
+ }
+ mutex_unlock(&sysfs_lock);
+ }
+ return status;
+}
+
+static struct device_attribute
+dev_attr_block_value = __ATTR(value, S_IWUSR | S_IRUGO, gpio_block_value_show,
+ gpio_block_value_store);
+
+static struct class gpio_block_class;
+
+static int gpio_block_value_is_exported(struct gpio_block *block)
+{
+ struct device *dev;
+ struct sysfs_dirent *sd = NULL;
+
+ mutex_lock(&sysfs_lock);
+ dev = class_find_device(&gpio_block_class, NULL, block, match_export);
+ if (!dev)
+ goto out;
+
+ sd = sysfs_get_dirent(dev->kobj.sd, NULL, "value");
+
+out:
+ mutex_unlock(&sysfs_lock);
+ return !!sd;
+}
+
+static ssize_t gpio_block_exported_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct gpio_block *block = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%u\n", gpio_block_value_is_exported(block));
+}
+
+static int gpio_block_value_export(struct gpio_block *block)
+{
+ struct device *dev;
+ int status;
+ int i;
+
+ mutex_lock(&sysfs_lock);
+
+ for (i = 0; i < block->ngpio; i++) {
+ status = gpio_request(block->gpio[i], "sysfs");
+ if (status)
+ goto out;
+ }
+
+ dev = class_find_device(&gpio_block_class, NULL, block, match_export);
+ if (!dev) {
+ status = -ENODEV;
+ goto out;
+ }
+
+ status = device_create_file(dev, &dev_attr_block_value);
+ if (status)
+ goto out;
+
+ mutex_unlock(&sysfs_lock);
+ return 0;
+
+out:
+ while (--i >= 0)
+ gpio_free(block->gpio[i]);
+
+ mutex_unlock(&sysfs_lock);
+ return status;
+}
+
+static int gpio_block_value_unexport(struct gpio_block *block)
+{
+ struct device *dev;
+ int i;
+
+ dev = class_find_device(&gpio_block_class, NULL, block, match_export);
+ if (!dev)
+ return -ENODEV;
+
+ for (i = 0; i < block->ngpio; i++)
+ gpio_free(block->gpio[i]);
+
+ device_remove_file(dev, &dev_attr_block_value);
+
+ return 0;
+}
+
+static ssize_t gpio_block_exported_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ long value;
+ int status;
+ struct gpio_block *block = dev_get_drvdata(dev);
+ int exported = gpio_block_value_is_exported(block);
+
+ status = kstrtoul(buf, 0, &value);
+ if (status < 0)
+ goto err;
+
+ if (value != exported) {
+ if (value)
+ status = gpio_block_value_export(block);
+ else
+ status = gpio_block_value_unexport(block);
+ if (!status)
+ status = size;
+ } else {
+ status = size;
+ }
+err:
+ return status;
+}
+
+static struct device_attribute gpio_block_attrs[] = {
+ __ATTR(exported, S_IWUSR | S_IRUGO, gpio_block_exported_show,
+ gpio_block_exported_store),
+ __ATTR(ngpio, S_IRUGO, gpio_block_ngpio_show, NULL),
+ __ATTR_NULL,
+};
+
+static struct class gpio_block_class = {
+ .name = "gpioblock",
+ .owner = THIS_MODULE,
+
+ .dev_attrs = gpio_block_attrs,
+};
+
+int gpio_block_export(struct gpio_block *block)
+{
+ int status = 0;
+ struct device *dev;
+
+ /* can't export until sysfs is available ... */
+ if (!gpio_block_class.p) {
+ pr_debug("%s: called too early!\n", __func__);
+ return -ENOENT;
+ }
+
+ mutex_lock(&sysfs_lock);
+ dev = device_create(&gpio_block_class, NULL, MKDEV(0, 0), block,
+ block->name);
+ if (IS_ERR(dev))
+ status = PTR_ERR(dev);
+ mutex_unlock(&sysfs_lock);
+
+ return status;
+}
+EXPORT_SYMBOL_GPL(gpio_block_export);
+
+void gpio_block_unexport(struct gpio_block *block)
+{
+ struct device *dev;
+
+ mutex_lock(&sysfs_lock);
+ dev = class_find_device(&gpio_block_class, NULL, block, match_export);
+ if (dev)
+ device_unregister(dev);
+ mutex_unlock(&sysfs_lock);
+}
+EXPORT_SYMBOL_GPL(gpio_block_unexport);
+
static int __init gpiolib_sysfs_init(void)
{
int status;
@@ -982,6 +1190,10 @@ static int __init gpiolib_sysfs_init(voi
if (status < 0)
return status;
+ status = class_register(&gpio_block_class);
+ if (status < 0)
+ return status;
+
/* Scan and register the gpio_chips which registered very
* early (e.g. before the class_register above was called).
*
@@ -1876,6 +2088,7 @@ int gpio_block_register(struct gpio_bloc
return -EBUSY;
list_add(&block->list, &gpio_block_list);
+ gpio_block_export(block);
return 0;
}
@@ -1888,6 +2101,7 @@ void gpio_block_unregister(struct gpio_b
list_for_each_entry(i, &gpio_block_list, list)
if (i == block) {
list_del(&i->list);
+ gpio_block_unexport(block);
break;
}
}
--- linux-2.6.orig/include/asm-generic/gpio.h
+++ linux-2.6/include/asm-generic/gpio.h
@@ -211,6 +211,8 @@ extern int gpio_export_link(struct devic
unsigned gpio);
extern int gpio_sysfs_set_active_low(unsigned gpio, int value);
extern void gpio_unexport(unsigned gpio);
+extern int gpio_block_export(struct gpio_block *block);
+extern void gpio_block_unexport(struct gpio_block *block);
#endif /* CONFIG_GPIO_SYSFS */
@@ -270,6 +272,15 @@ static inline int gpio_sysfs_set_active_
static inline void gpio_unexport(unsigned gpio)
{
}
+
+static inline int gpio_block_export(struct gpio_block *block)
+{
+ return -ENOSYS;
+}
+
+static inline void gpio_block_unexport(struct gpio_block *block)
+{
+}
#endif /* CONFIG_GPIO_SYSFS */
#endif /* _ASM_GENERIC_GPIO_H */
--- linux-2.6.orig/include/linux/gpio.h
+++ linux-2.6/include/linux/gpio.h
@@ -291,6 +291,19 @@ static inline void gpio_unexport(unsigne
WARN_ON(1);
}
+static inline int gpio_block_export(struct gpio_block *block)
+{
+ /* GPIO block can never have been requested or set as {in,out}put */
+ WARN_ON(1);
+ return -EINVAL;
+}
+
+static inline void gpio_block_unexport(struct gpio_block *block)
+{
+ /* GPIO block can never have been exported */
+ WARN_ON(1);
+}
+
static inline int gpio_to_irq(unsigned gpio)
{
/* GPIO can never have been requested or set as input */
^ permalink raw reply
* [PATCH RFC 01/15 v5] gpio: Add a block GPIO API to gpiolib
From: Roland Stigge @ 2012-10-17 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350477107-26512-1-git-send-email-stigge@antcom.de>
The recurring task of providing simultaneous access to GPIO lines (especially
for bit banging protocols) needs an appropriate API.
This patch adds a kernel internal "Block GPIO" API that enables simultaneous
access to several GPIOs. This is done by abstracting GPIOs to an n-bit word:
Once requested, it provides access to a group of GPIOs which can range over
multiple GPIO chips.
Signed-off-by: Roland Stigge <stigge@antcom.de>
---
Documentation/gpio.txt | 47 +++++++++
drivers/gpio/gpiolib.c | 217 +++++++++++++++++++++++++++++++++++++++++++++
include/asm-generic/gpio.h | 15 +++
include/linux/gpio.h | 74 +++++++++++++++
4 files changed, 353 insertions(+)
--- linux-2.6.orig/Documentation/gpio.txt
+++ linux-2.6/Documentation/gpio.txt
@@ -439,6 +439,53 @@ slower clock delays the rising edge of S
signaling rate accordingly.
+Block GPIO
+----------
+
+The above described interface concentrates on handling single GPIOs. However,
+in applications where it is critical to set several GPIOs at once, this
+interface doesn't work well, e.g. bit-banging protocols via grouped GPIO lines.
+Consider a GPIO controller that is connected via a slow I2C line. When
+switching two or more GPIOs one after another, there can be considerable time
+between those events. This is solved by an interface called Block GPIO:
+
+struct gpio_block *gpio_block_create(unsigned int *gpios, size_t size);
+
+This creates a new block of GPIOs as a list of GPIO numbers with the specified
+size which are accessible via the returned struct gpio_block and the accessor
+functions described below. Please note that you need to request the GPIOs
+separately via gpio_request(). An arbitrary list of globally valid GPIOs can be
+specified, even ranging over several gpio_chips. Actual handling of I/O
+operations will be done on a best effort base, i.e. simultaneous I/O only where
+possible by hardware and implemented in the respective GPIO driver. The number
+of GPIOs in one block is limited to the number of bits in an unsigned long, or
+BITS_PER_LONG, of the respective platform, i.e. typically at least 32 on a 32
+bit system, and at least 64 on a 64 bit system. However, several blocks can be
+defined at once.
+
+unsigned gpio_block_get(struct gpio_block *block);
+void gpio_block_set(struct gpio_block *block, unsigned value);
+
+With those accessor functions, setting and getting the GPIO values is possible,
+analogous to gpio_get_value() and gpio_set_value(). Each bit in the return
+value of gpio_block_get() and in the value argument of gpio_block_set()
+corresponds to a bit specified on gpio_block_create(). Block operations in
+hardware are only possible where the respective GPIO driver implements it,
+falling back to using single GPIO operations where the driver only implements
+single GPIO access.
+
+void gpio_block_free(struct gpio_block *block);
+
+After the GPIO block isn't used anymore, it should be free'd via
+gpio_block_free().
+
+int gpio_block_register(struct gpio_block *block);
+void gpio_block_unregister(struct gpio_block *block);
+
+These functions can be used to register a GPIO block. Blocks registered this
+way will be available via sysfs.
+
+
What do these conventions omit?
===============================
One of the biggest things these conventions omit is pin multiplexing, since
--- linux-2.6.orig/drivers/gpio/gpiolib.c
+++ linux-2.6/drivers/gpio/gpiolib.c
@@ -83,6 +83,8 @@ static inline void desc_set_label(struct
#endif
}
+static LIST_HEAD(gpio_block_list);
+
/* Warn when drivers omit gpio_request() calls -- legal but ill-advised
* when setting direction, and otherwise illegal. Until board setup code
* and drivers use explicit requests everywhere (which won't happen when
@@ -1676,6 +1678,221 @@ void __gpio_set_value(unsigned gpio, int
}
EXPORT_SYMBOL_GPL(__gpio_set_value);
+static int gpio_block_chip_index(struct gpio_block *block, struct gpio_chip *gc)
+{
+ int i;
+
+ for (i = 0; i < block->nchip; i++) {
+ if (block->gbc[i].gc == gc)
+ return i;
+ }
+ return -1;
+}
+
+struct gpio_block *gpio_block_create(unsigned *gpios, size_t size,
+ const char *name)
+{
+ struct gpio_block *block;
+ struct gpio_block_chip *gbc;
+ struct gpio_remap *remap;
+ void *tmp;
+ int i;
+
+ if (size < 1 || size > sizeof(unsigned long) * 8)
+ return ERR_PTR(-EINVAL);
+
+ for (i = 0; i < size; i++)
+ if (!gpio_is_valid(gpios[i]))
+ return ERR_PTR(-EINVAL);
+
+ block = kzalloc(sizeof(struct gpio_block), GFP_KERNEL);
+ if (!block)
+ return ERR_PTR(-ENOMEM);
+
+ block->name = name;
+ block->ngpio = size;
+ block->gpio = kzalloc(sizeof(*block->gpio) * size, GFP_KERNEL);
+ if (!block->gpio)
+ goto err1;
+
+ memcpy(block->gpio, gpios, sizeof(*block->gpio) * size);
+
+ for (i = 0; i < size; i++) {
+ struct gpio_chip *gc = gpio_to_chip(gpios[i]);
+ int bit = gpios[i] - gc->base;
+ int index = gpio_block_chip_index(block, gc);
+
+ if (index < 0) {
+ block->nchip++;
+ tmp = krealloc(block->gbc,
+ sizeof(struct gpio_block_chip) *
+ block->nchip, GFP_KERNEL);
+ if (!tmp) {
+ kfree(block->gbc);
+ goto err2;
+ }
+ block->gbc = tmp;
+ gbc = &block->gbc[block->nchip - 1];
+ gbc->gc = gc;
+ gbc->remap = NULL;
+ gbc->nremap = 0;
+ gbc->mask = 0;
+ } else {
+ gbc = &block->gbc[index];
+ }
+ /* represents the mask necessary on calls to the driver's
+ * .get_block() and .set_block()
+ */
+ gbc->mask |= BIT(bit);
+
+ /* collect gpios that are specified together, represented by
+ * neighboring bits
+ *
+ * Note that even though in setting remap is given a negative
+ * index, the next lines guard that the potential out-of-bounds
+ * pointer is not dereferenced when out of bounds.
+ */
+ remap = &gbc->remap[gbc->nremap - 1];
+ if (!gbc->nremap || (bit - i != remap->offset)) {
+ gbc->nremap++;
+ tmp = krealloc(gbc->remap,
+ sizeof(struct gpio_remap) *
+ gbc->nremap, GFP_KERNEL);
+ if (!tmp) {
+ kfree(gbc->remap);
+ goto err3;
+ }
+ gbc->remap = tmp;
+ remap = &gbc->remap[gbc->nremap - 1];
+ remap->offset = bit - i;
+ remap->mask = 0;
+ }
+
+ /* represents the mask necessary for bit reordering between
+ * gpio_block (i.e. as specified on gpio_block_get() and
+ * gpio_block_set()) and gpio_chip domain (i.e. as specified on
+ * the driver's .set_block() and .get_block())
+ */
+ remap->mask |= BIT(i);
+ }
+
+ return block;
+err3:
+ for (i = 0; i < block->nchip - 1; i++)
+ kfree(block->gbc[i].remap);
+ kfree(block->gbc);
+err2:
+ kfree(block->gpio);
+err1:
+ kfree(block);
+ return ERR_PTR(-ENOMEM);
+}
+EXPORT_SYMBOL_GPL(gpio_block_create);
+
+void gpio_block_free(struct gpio_block *block)
+{
+ int i;
+
+ for (i = 0; i < block->nchip; i++)
+ kfree(block->gbc[i].remap);
+ kfree(block->gpio);
+ kfree(block->gbc);
+ kfree(block);
+}
+EXPORT_SYMBOL_GPL(gpio_block_free);
+
+unsigned long gpio_block_get(const struct gpio_block *block)
+{
+ struct gpio_block_chip *gbc;
+ int i, j;
+ unsigned long values = 0;
+
+ for (i = 0; i < block->nchip; i++) {
+ unsigned long remapped = 0;
+
+ gbc = &block->gbc[i];
+
+ if (gbc->gc->get_block) {
+ remapped = gbc->gc->get_block(gbc->gc, gbc->mask);
+ } else {
+ /* emulate */
+ for_each_set_bit(j, &gbc->mask, BITS_PER_LONG)
+ remapped |= gbc->gc->get(gbc->gc,
+ gbc->gc->base + j) << j;
+ }
+
+ for (j = 0; j < gbc->nremap; j++) {
+ struct gpio_remap *gr = &gbc->remap[j];
+
+ values |= (remapped >> gr->offset) & gr->mask;
+ }
+ }
+
+ return values;
+}
+EXPORT_SYMBOL_GPL(gpio_block_get);
+
+void gpio_block_set(struct gpio_block *block, unsigned long values)
+{
+ struct gpio_block_chip *gbc;
+ int i, j;
+
+ for (i = 0; i < block->nchip; i++) {
+ unsigned long remapped = 0;
+
+ gbc = &block->gbc[i];
+
+ for (j = 0; j < gbc->nremap; j++) {
+ struct gpio_remap *gr = &gbc->remap[j];
+
+ remapped |= (values & gr->mask) << gr->offset;
+ }
+ if (gbc->gc->set_block) {
+ gbc->gc->set_block(gbc->gc, gbc->mask, remapped);
+ } else {
+ /* emulate */
+ for_each_set_bit(j, &gbc->mask, BITS_PER_LONG)
+ gbc->gc->set(gbc->gc, gbc->gc->base + j,
+ (remapped >> j) & 1);
+ }
+ }
+}
+EXPORT_SYMBOL_GPL(gpio_block_set);
+
+struct gpio_block *gpio_block_find_by_name(const char *name)
+{
+ struct gpio_block *i;
+
+ list_for_each_entry(i, &gpio_block_list, list)
+ if (!strcmp(i->name, name))
+ return i;
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(gpio_block_find_by_name);
+
+int gpio_block_register(struct gpio_block *block)
+{
+ if (gpio_block_find_by_name(block->name))
+ return -EBUSY;
+
+ list_add(&block->list, &gpio_block_list);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(gpio_block_register);
+
+void gpio_block_unregister(struct gpio_block *block)
+{
+ struct gpio_block *i;
+
+ list_for_each_entry(i, &gpio_block_list, list)
+ if (i == block) {
+ list_del(&i->list);
+ break;
+ }
+}
+EXPORT_SYMBOL_GPL(gpio_block_unregister);
+
/**
* __gpio_cansleep() - report whether gpio value access will sleep
* @gpio: gpio in question
--- linux-2.6.orig/include/asm-generic/gpio.h
+++ linux-2.6/include/asm-generic/gpio.h
@@ -43,6 +43,7 @@ static inline bool gpio_is_valid(int num
struct device;
struct gpio;
+struct gpio_block;
struct seq_file;
struct module;
struct device_node;
@@ -105,6 +106,8 @@ struct gpio_chip {
unsigned offset);
int (*get)(struct gpio_chip *chip,
unsigned offset);
+ unsigned long (*get_block)(struct gpio_chip *chip,
+ unsigned long mask);
int (*direction_output)(struct gpio_chip *chip,
unsigned offset, int value);
int (*set_debounce)(struct gpio_chip *chip,
@@ -112,6 +115,9 @@ struct gpio_chip {
void (*set)(struct gpio_chip *chip,
unsigned offset, int value);
+ void (*set_block)(struct gpio_chip *chip,
+ unsigned long mask,
+ unsigned long values);
int (*to_irq)(struct gpio_chip *chip,
unsigned offset);
@@ -171,6 +177,15 @@ extern void gpio_set_value_cansleep(unsi
extern int __gpio_get_value(unsigned gpio);
extern void __gpio_set_value(unsigned gpio, int value);
+extern struct gpio_block *gpio_block_create(unsigned *gpio, size_t size,
+ const char *name);
+extern void gpio_block_free(struct gpio_block *block);
+extern unsigned long gpio_block_get(const struct gpio_block *block);
+extern void gpio_block_set(struct gpio_block *block, unsigned long values);
+extern struct gpio_block *gpio_block_find_by_name(const char *name);
+extern int gpio_block_register(struct gpio_block *block);
+extern void gpio_block_unregister(struct gpio_block *block);
+
extern int __gpio_cansleep(unsigned gpio);
extern int __gpio_to_irq(unsigned gpio);
--- linux-2.6.orig/include/linux/gpio.h
+++ linux-2.6/include/linux/gpio.h
@@ -2,6 +2,8 @@
#define __LINUX_GPIO_H
#include <linux/errno.h>
+#include <linux/types.h>
+#include <linux/list.h>
/* see Documentation/gpio.txt */
@@ -39,6 +41,43 @@ struct gpio {
const char *label;
};
+/*
+ * struct gpio_remap - a structure for describing a bit mapping
+ * @mask: a bit mask
+ * @offset: how many bits to shift to the left (negative: to the right)
+ *
+ * When we are mapping bit values from one word to another (here: from GPIO
+ * block domain to GPIO driver domain) we first mask them out with mask and
+ * shift them as specified with offset. More complicated mappings are done by
+ * grouping several of those structs and adding the results together.
+ */
+struct gpio_remap {
+ unsigned long mask;
+ int offset;
+};
+
+struct gpio_block_chip {
+ struct gpio_chip *gc;
+ struct gpio_remap *remap;
+ int nremap;
+ unsigned long mask;
+};
+
+/**
+ * struct gpio_block - a structure describing a list of GPIOs for simultaneous
+ * operations
+ */
+struct gpio_block {
+ struct gpio_block_chip *gbc;
+ size_t nchip;
+ const char *name;
+
+ int ngpio;
+ unsigned *gpio;
+
+ struct list_head list;
+};
+
#ifdef CONFIG_GENERIC_GPIO
#ifdef CONFIG_ARCH_HAVE_CUSTOM_GPIO_H
@@ -169,6 +208,41 @@ static inline void gpio_set_value(unsign
WARN_ON(1);
}
+static inline
+struct gpio_block *gpio_block_create(unsigned *gpios, size_t size,
+ const char *name)
+{
+ WARN_ON(1);
+ return NULL;
+}
+
+static inline void gpio_block_free(struct gpio_block *block)
+{
+ WARN_ON(1);
+}
+
+static inline unsigned long gpio_block_get(const struct gpio_block *block)
+{
+ WARN_ON(1);
+ return 0;
+}
+
+static inline void gpio_block_set(struct gpio_block *block, unsigned long value)
+{
+ WARN_ON(1);
+}
+
+static inline int gpio_block_register(struct gpio_block *block)
+{
+ WARN_ON(1);
+ return 0;
+}
+
+static inline void gpio_block_unregister(struct gpio_block *block)
+{
+ WARN_ON(1);
+}
+
static inline int gpio_cansleep(unsigned gpio)
{
/* GPIO can never have been requested or set as {in,out}put */
^ permalink raw reply
* [PATCH RFC 00/15 v5] gpio: Add block GPIO
From: Roland Stigge @ 2012-10-17 12:31 UTC (permalink / raw)
To: linux-arm-kernel
This set of patches adds:
* Block GPIO API to gpiolib
* Sysfs support for GPIO API, to provide userland access
* Devicetree support to instantiate GPIO blocks via DT
* Example implementations in several gpio drivers since they need
special accessor functions for block wise GPIO access
* Fix for race condition in gpiolib on device creation
Signed-off-by: Roland Stigge <stigge@antcom.de>
--
Changes since v4:
* Documented word width
* Bugfix: export/unexport on register/unregister
* Using default dev_attrs for gpio_block_class
* Fix gpiolib: race condition on device creation
* Added driver support for ucb14500, vt8500, xilinx
Changes since v3:
* Added driver support for pca953x, em, pl061, max732x, pcf857x
* Coding style improvements
* Fixed krealloc memory leak in error case
* sysfs: values in hex
* Register blocks in a list
* Narrowing lock scope
* Use S_IWUSR and S_IRUGO instead of direct octal values
* Use for_each_set_bit()
* Change from unsigned to unsigned long for masks and values
Changes since v2:
* Added sysfs support
* Added devicetree support
* Added support for lpc32xx, generic
* Added functions for GPIO block registration
* Added more error checking
* Bit remapping bugfix
Changes since v1:
* API change to 32/64 bit word, bit masks
Thanks to Ryan Mallon, Linus Walleij, Stijn Devriendt, Jean-Christophe
Plagniol-Villard, Mark Brown and Greg Kroah-Hartman for reviewing!
Roland Stigge (15):
gpio: Add a block GPIO API to gpiolib
gpio: Add sysfs support to block GPIO API
gpiolib: Fix default attributes for class
gpio: Add device tree support to block GPIO API
gpio-max730x: Add block GPIO API
gpio-lpc32xx: Add block GPIO API
gpio-generic: Add block GPIO API
gpio-pca953x: Add block GPIO API
gpio-em: Add block GPIO API
gpio-pl061: Add block GPIO API
gpio-max732x: Add block GPIO API
gpio-pcf857x: Add block GPIO API
gpio-xilinx: Add block GPIO API
gpio-vt8500: Add block GPIO API
gpio-ucb1400: Add block GPIO API
Documentation/ABI/testing/sysfs-gpio | 6
Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 +
Documentation/gpio.txt | 47 +
drivers/gpio/Makefile | 1
drivers/gpio/gpio-em.c | 23
drivers/gpio/gpio-generic.c | 56 +
drivers/gpio/gpio-lpc32xx.c | 82 ++
drivers/gpio/gpio-max730x.c | 61 ++
drivers/gpio/gpio-max732x.c | 59 ++
drivers/gpio/gpio-pca953x.c | 64 ++
drivers/gpio/gpio-pcf857x.c | 24
drivers/gpio/gpio-pl061.c | 17
drivers/gpio/gpio-ucb1400.c | 23
drivers/gpio/gpio-vt8500.c | 24
drivers/gpio/gpio-xilinx.c | 44 +
drivers/gpio/gpioblock-of.c | 84 ++
drivers/gpio/gpiolib.c | 510 ++++++++++++++++--
include/asm-generic/gpio.h | 26
include/linux/gpio.h | 87 +++
19 files changed, 1228 insertions(+), 46 deletions(-)
^ permalink raw reply
* [PATCH] usb: phy: samsung: Introducing usb phy driver for hsotg
From: Praveen Paneri @ 2012-10-17 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <005801cdac56$8da0c120$a8e24360$%kim@samsung.com>
Hi,
On Wed, Oct 17, 2012 at 4:30 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Praveen Paneri wrote:
>>
>> platform_set_drvdata() required for driver's remove function, so adding
>> it back.
>>
>> From v6:
>> Added TODO for phy bindings with controller
>> Dropped platform_set_drvdata() from driver probe
>>
>> This driver uses usb_phy interface to interact with s3c-hsotg. Supports
>> phy_init and phy_shutdown functions to enable/disable phy. Tested with
>> smdk6410 and smdkv310. More SoCs can be brought under later.
>>
>> Signed-off-by: Praveen Paneri <p.paneri@samsung.com>
>> Acked-by: Heiko Stuebner <heiko@sntech.de>
>> ---
>> .../devicetree/bindings/usb/samsung-usbphy.txt | 11 +
>> drivers/usb/phy/Kconfig | 8 +
>> drivers/usb/phy/Makefile | 1 +
>> drivers/usb/phy/samsung-usbphy.c | 357
> ++++++++++++++++++++
>> include/linux/platform_data/samsung-usbphy.h | 27 ++
>> 5 files changed, 404 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/usb/samsung-
>> usbphy.txt
>> create mode 100644 drivers/usb/phy/samsung-usbphy.c
>> create mode 100644 include/linux/platform_data/samsung-usbphy.h
>>
>> diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> new file mode 100644
>> index 0000000..7b26e2d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>> @@ -0,0 +1,11 @@
>> +* Samsung's usb phy transceiver
>> +
>> +The Samsung's phy transceiver is used for controlling usb otg phy for
>> +s3c-hsotg usb device controller.
>> +TODO: Adding the PHY binding with controller(s) according to the under
>> +developement generic PHY driver.
>> +
>> +Required properties:
>> +- compatible : should be "samsung,exynos4210-usbphy"
>> +- reg : base physical address of the phy registers and length of memory
>> mapped
>> + region.
>> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
>> index 63c339b..313685f 100644
>> --- a/drivers/usb/phy/Kconfig
>> +++ b/drivers/usb/phy/Kconfig
>> @@ -32,3 +32,11 @@ config MV_U3D_PHY
>> help
>> Enable this to support Marvell USB 3.0 phy controller for Marvell
>> SoC.
>> +
>> +config SAMSUNG_USBPHY
>> + bool "Samsung USB PHY controller Driver"
>> + depends on USB_S3C_HSOTG
>> + select USB_OTG_UTILS
>> + help
>> + Enable this to support Samsung USB phy controller for samsung
>> + SoCs.
>> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
>> index b069f29..55dcfc1 100644
>> --- a/drivers/usb/phy/Makefile
>> +++ b/drivers/usb/phy/Makefile
>> @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) +=
> omap-usb2.o
>> obj-$(CONFIG_USB_ISP1301) += isp1301.o
>> obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
>> obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
>> +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
>> diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-
>> usbphy.c
>> new file mode 100644
>> index 0000000..14c182f
>> --- /dev/null
>> +++ b/drivers/usb/phy/samsung-usbphy.c
>
> Hi,
>
> Basically I agree and this is a good approach to support usb phy for Samsung
> stuff...but there are some comments ;)
>
>> @@ -0,0 +1,357 @@
>> +/* linux/drivers/usb/phy/samsung-usbphy.c
>> + *
>> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * Author: Praveen Paneri <p.paneri@samsung.com>
>> + *
>> + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG
>> controller
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * 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.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/of.h>
>> +#include <linux/usb/otg.h>
>> +#include <linux/platform_data/samsung-usbphy.h>
>> +
>> +/* Register definitions */
>> +
>> +#define S3C_PHYPWR (0x00)
>> +
> IMHO, according to the file name, samsung-usbphy, SAMSUNG_ is better here?
Sure I will change this for register names and drop S3C_ from bit definitions.
>
>
>> +#define S3C_PHYPWR_NORMAL_MASK (0x19 << 0)
>> +#define S3C_PHYPWR_OTG_DISABLE (1 << 4)
>> +#define S3C_PHYPWR_ANALOG_POWERDOWN (1 << 3)
>> +#define S3C_PHYPWR_FORCE_SUSPEND (1 << 1)
>> +/* For Exynos4 */
>> +#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 << 0)
>
> Hmm...is this right? If so, need to use exact name for the definition.
Name should be changed, will do that.
>
> See arch/arm/mach-exynos/include/mach/regs-usb-phy.h
>
>> +#define EXYNOS4_PHYPWR_SLEEP (1 << 5)
>
> Ditto.
>
>> +
>> +#define S3C_PHYCLK (0x04)
>> +
>> +#define S3C_PHYCLK_MODE_SERIAL (1 << 6)
>
> MODE_USB11?
Yes! Will update this as well.
>
>> +#define S3C_PHYCLK_EXT_OSC (1 << 5)
>> +#define S3C_PHYCLK_COMMON_ON_N (1 << 4)
>
> There are Samsung SoCs which is having two PHYs, so I think, we need to
> design this with considering it.
Yes! I do plan to add support for other SoCs. We will have to update
the register definition accordingly for PHY0 and PHY1.
>
>> +#define S3C_PHYCLK_ID_PULL (1 << 2)
>> +#define S3C_PHYCLK_CLKSEL_MASK (0x3 << 0)
>> +#define S3C_PHYCLK_CLKSEL_SHIFT (0)
>> +#define S3C_PHYCLK_CLKSEL_48M (0x0 << 0)
>> +#define S3C_PHYCLK_CLKSEL_12M (0x2 << 0)
>> +#define S3C_PHYCLK_CLKSEL_24M (0x3 << 0)
>
> As you know, the values for CLKSEL are different on each Samsung SoCs...if
Yeah those bit definitions have to be added here, just as they are in
the file you mentioned.
See arch/arm/mach-exynos/include/mach/regs-usb-phy.h
> we use this patch, we need to implement for other SoCs many things. In
> addition, this patch says can support EXYNOS4210 but not actually...
I have tested on SMDKV310 and SMDK6410 with s3c-hsotg. So, host phy
control support is yet to be added.
>
>> +
>> +#define S3C_RSTCON (0x08)
>> +
>> +#define S3C_RSTCON_PHYCLK (1 << 2)
>> +#define S3C_RSTCON_HCLK (1 << 1)
>> +#define S3C_RSTCON_PHY (1 << 0)
>> +
>> +#ifndef MHZ
>> +#define MHZ (1000*1000)
>> +#endif
>> +
>> +enum samsung_cpu_type {
>> + TYPE_S3C64XX,
>> + TYPE_EXYNOS4210,
>> +};
>> +
>> +/*
>> + * struct samsung_usbphy - transceiver driver state
>> + * @phy: transceiver structure
>> + * @plat: platform data
>> + * @dev: The parent device supplied to the probe function
>> + * @clk: usb phy clock
>> + * @regs: usb phy register memory base
>> + * @ref_clk_freq: reference clock frequency selection
>> + * @cpu_type: machine identifier
>> + */
>> +struct samsung_usbphy {
>> + struct usb_phy phy;
>> + struct samsung_usbphy_data *plat;
>> + struct device *dev;
>> + struct clk *clk;
>> + void __iomem *regs;
>> + int ref_clk_freq;
>> + int cpu_type;
>> +};
>> +
>> +#define phy_to_sphy(x) container_of((x), struct
> samsung_usbphy,
>> phy)
>> +
>> +/*
>> + * Returns reference clock frequency selection value
>> + */
>> +static int samsung_usbphy_get_refclk_freq(struct samsung_usbphy *sphy)
>> +{
>> + struct clk *ref_clk;
>> + int refclk_freq = 0;
>> +
>> + ref_clk = clk_get(sphy->dev, "xusbxti");
>> + if (IS_ERR(ref_clk)) {
>
> IS_ERR_OR_NULL(ref_clk)?
sure
>
>> + dev_err(sphy->dev, "Failed to get reference clock\n");
>> + return PTR_ERR(ref_clk);
>> + }
>> +
>> + switch (clk_get_rate(ref_clk)) {
>> + case 12 * MHZ:
>> + refclk_freq |= S3C_PHYCLK_CLKSEL_12M;
>
> Just,
>
> + refclk_freq = S3C_PHYCLK_CLKSEL_12M;
>
> because its defalut value is 0...BTW, how do you think to support other SoCs
> such as EXYNOS4210, EXYNOS4X12?
Will make use of sphy->cpu_type here. No?
>
>> + break;
>> + case 24 * MHZ:
>> + refclk_freq |= S3C_PHYCLK_CLKSEL_24M;
>
> Ditto.
>
>> + break;
>> + default:
>> + case 48 * MHZ:
>> + /* default reference clock */
>> + refclk_freq |= S3C_PHYCLK_CLKSEL_48M;
>
> Ditto...and default refernec clock for EXYNOS4 is 24MHz...
Okay! So it needs an if statement here then.
>
>> + break;
>> + }
>> + clk_put(ref_clk);
>> +
>> + return refclk_freq;
>> +}
>> +
>
> Hmm...I need more time to look at this again...
Thank you :)
In that case, I will wait for further comments from you and then only
send my subsequent patches.
Regards,
Praveen
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 01/11] fsmc/nand:FIX: Change the type for regs to void __iomem *
From: Artem Bityutskiy @ 2012-10-17 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c30a9228d4bff7dbedd5d011f84c79c324736452.1349778820.git.vipin.kumar@st.com>
On Tue, 2012-10-09 at 16:14 +0530, Vipin Kumar wrote:
> Signed-off-by: Vipin Kumar <vipin.kumar@st.com>
Pushed this one to l2-mtd.git, thanks!
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121017/4621e9f2/attachment.sig>
^ permalink raw reply
* [RFC PATCH 0/2] sched: Load Balancing using Per-entity-Load-tracking
From: preeti @ 2012-10-17 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012044618.18271.88332.stgit@preeti.in.ibm.com>
Hi Guys,
Can you please have a look at the below patchset? Your review comments
are very necessary and valuable.Thanks in advance.
> This patchset uses the per-entity-load-tracking patchset which will soon be
> available in the kernel.It is based on the tip/master tree and the first 8
> latest patches of sched:per-entity-load-tracking alone have been imported to
> the tree to avoid the complexities of task groups and to hold back the
> optimizations of this patch for now.
>
> This patchset is an attempt to begin the integration of Per-entity-load-
> metric for the cfs_rq,henceforth referred to as PJT's metric,with the load
> balancer in a step wise fashion,and progress based on the consequences.
>
> The following issues have been considered towards this:
> [NOTE:an x% task referred to in the logs and below is calculated over a
> duty cycle of 10ms.]
>
> 1.Consider a scenario,where there are two 10% tasks running on a cpu.The
> present code will consider the load on this queue to be 2048,while
> using PJT's metric the load is calculated to be <1000,rarely exceeding this
> limit.Although the tasks are not contributing much to the cpu load,they are
> decided to be moved by the scheduler.
>
> But one could argue that 'not moving one of these tasks could throttle
> them.If there was an idle cpu,perhaps we could have moved them'.While the
> power save mode would have been fine with not moving the task,the
> performance mode would prefer not to throttle the tasks.We could strive
> to strike a balance by making this decision tunable with certain parameters.
> This patchset includes such tunables.This issue is addressed in Patch[1/2].
>
> 2.We need to be able to do this cautiously,as the scheduler code is too
> complex.This patchset is an attempt to begin the integration of PJT's
> metric with the load balancer in a step wise fashion,and progress based on
> the consequences.
> I dont intend to vary the parameters used by the load balancer.Some
> parameters are however included anew to make decisions about including a
> sched group as a candidate for load balancing.
>
> This patchset therefore has two primary aims.
> Patch[1/2]: This patch aims at detecting short running tasks and
> prevent their movement.In update_sg_lb_stats,dismiss a sched group
> as a candidate for load balancing,if load calculated by PJT's metric
> says that the average load on the sched_group <= 1024+(.15*1024).
> This is a tunable,which can be varied after sufficient experiments.
>
> Patch[2/2]:In the current scheduler greater load would be analogous
> to more number of tasks.Therefore when the busiest group is picked
> from the sched domain in update_sd_lb_stats,only the loads of the
> groups are compared between them.If we were to use PJT's metric,a
> higher load does not necessarily mean more number of tasks.This
> patch addresses this issue.
>
> 3.The next step towards integration should be in using the PJT's metric for
> comparison between the loads of the busy sched group and the sched
> group which has to pull the tasks,which happens in find_busiest_group.
> ---
>
> Preeti U Murthy (2):
> sched:Prevent movement of short running tasks during load balancing
> sched:Pick the apt busy sched group during load balancing
>
>
> kernel/sched/fair.c | 38 +++++++++++++++++++++++++++++++++++---
> 1 file changed, 35 insertions(+), 3 deletions(-)
>
> --
The links to PATCH[1/2] https://lkml.org/lkml/2012/10/12/13
PATCH[2/2] https://lkml.org/lkml/2012/10/12/11
Regards
Preeti U Murthy
^ permalink raw reply
* [RFC PATCH v2] Hardcoded instruction causes cpu-hotplug fail on be8 big-endian ARM platfrom
From: Fei Yang @ 2012-10-17 12:00 UTC (permalink / raw)
To: linux-arm-kernel
<cut>
> Not handling the Thumb case is a definite bug for any file which may
> run on v7, since the kernel could be built in Thumb for that case.
> For example, the existing code is mach-realview/hotplug.c is broken
> when building an SMP Thumb-2 kernel for the Realview PBX-A9.
>
> Cheers
> ---Dave
Thanks for pointing this out. I think we just cannot make any
assumption about the versions of the tools used. Based on this, I have
made a v2 of the patch against linux-3.7-rc1. I am not touching the
CFLAGS in the patch as I am not familiar with the three ARM boards
here.
Can the respective board maintainers
(mach-exynos/mach-realveiw/mach-shmobile) give any comments about v2
of the patch?
Thanks.
---Fei
v2: Define opcode of the ARM "WFI" instruction in the right way.
Signed-off-by: Fei Yang<yangfei.kernel@gmail.com>
diff -urN linux-3.7-rc1/arch/arm/mach-exynos/hotplug.c
linux/arch/arm/mach-exynos/hotplug.c
--- linux-3.7-rc1/arch/arm/mach-exynos/hotplug.c 2012-10-15
05:41:04.000000000 +0800
+++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-17 19:25:49.000000000 +0800
@@ -18,11 +18,17 @@
#include <asm/cacheflush.h>
#include <asm/cp15.h>
#include <asm/smp_plat.h>
+#include <asm/opcodes.h>
#include <mach/regs-pmu.h>
#include "common.h"
+/*
+ * Define opcode of the WFI instruction.
+ */
+#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
+
static inline void cpu_enter_lowpower(void)
{
unsigned int v;
@@ -72,7 +78,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(__WFI
:
:
: "memory", "cc");
diff -urN linux-3.7-rc1/arch/arm/mach-realview/hotplug.c
linux/arch/arm/mach-realview/hotplug.c
--- linux-3.7-rc1/arch/arm/mach-realview/hotplug.c 2012-10-15
05:41:04.000000000 +0800
+++ linux/arch/arm/mach-realview/hotplug.c 2012-10-17 19:25:20.000000000 +0800
@@ -15,6 +15,12 @@
#include <asm/cacheflush.h>
#include <asm/cp15.h>
#include <asm/smp_plat.h>
+#include <asm/opcodes.h>
+
+/*
+ * Define opcode of the WFI instruction.
+ */
+#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
static inline void cpu_enter_lowpower(void)
{
@@ -64,7 +70,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(__WFI
:
:
: "memory", "cc");
diff -urN linux-3.7-rc1/arch/arm/mach-shmobile/hotplug.c
linux/arch/arm/mach-shmobile/hotplug.c
--- linux-3.7-rc1/arch/arm/mach-shmobile/hotplug.c 2012-10-15
05:41:04.000000000 +0800
+++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-17 19:25:34.000000000 +0800
@@ -20,6 +20,12 @@
#include <mach/emev2.h>
#include <asm/cacheflush.h>
#include <asm/mach-types.h>
+#include <asm/opcodes.h>
+
+/*
+ * Define opcode of the WFI instruction.
+ */
+#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
static cpumask_t dead_cpus;
@@ -39,7 +45,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(__WFI
:
:
: "memory", "cc");
^ permalink raw reply
* [PATCH v2 0/2] Add DMA and device tree support to the flash controller FLCTL
From: Artem Bityutskiy @ 2012-10-17 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349776729-9311-1-git-send-email-hechtb@gmail.com>
On Tue, 2012-10-09 at 11:58 +0200, Bastian Hecht wrote:
> changelog v2: - cosmetic fixes in patch 1
> - added dmas and dma-names field in patch 2
Hi, I used to be able to compile MTD stuff for mackerel board with the
defconfig attached, but now it fails with 3.7-rc1 with as error:
/tmp/cc2Nr7AN.s: Error: bad immediate value for 8-bit offset (1024)
It fails for dogc4.c, but if I disable DOCG4, it fails for other drivers
with a similar error.
I've tried (arm) gcc 4.6.3 and the latest Linaro 4.7 build.
Any idea? I did not dig this, is this a known issue? Could you try to
reproduce this in your setup?
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_PID_NS is not set
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_ARCH_SHMOBILE=y
CONFIG_ARCH_SH7372=y
CONFIG_MACH_MACKEREL=y
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
CONFIG_FORCE_MAX_ZONEORDER=15
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpu=64m memchunk.veu0=8m memchunk.spu0=2m mem=240m"
CONFIG_KEXEC=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_PM_RUNTIME=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_MTD=y
CONFIG_MTD_TESTS=m
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_REDBOOT_PARTS_READONLY=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_AFS_PARTS=m
CONFIG_MTD_AR7_PARTS=m
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
CONFIG_INFTL=m
CONFIG_RFD_FTL=m
CONFIG_SSFDC=m
CONFIG_SM_FTL=m
CONFIG_MTD_OOPS=y
CONFIG_MTD_SWAP=m
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_OTP=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_ROM=y
CONFIG_MTD_ABSENT=y
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_COMPAT=y
CONFIG_MTD_IMPA7=m
CONFIG_MTD_GPIO_ADDR=y
CONFIG_MTD_PLATRAM=y
CONFIG_MTD_LATCH_ADDR=m
CONFIG_MTD_DATAFLASH=y
CONFIG_MTD_M25P80=y
# CONFIG_M25PXX_USE_FAST_READ is not set
CONFIG_MTD_SST25L=y
CONFIG_MTD_SLRAM=y
CONFIG_MTD_PHRAM=y
CONFIG_MTD_MTDRAM=m
CONFIG_MTD_BLOCK2MTD=y
CONFIG_MTD_DOC2000=m
CONFIG_MTD_DOC2001=m
CONFIG_MTD_DOC2001PLUS=y
CONFIG_MTD_DOCG3=m
CONFIG_MTD_DOCPROBE_ADVANCED=y
CONFIG_MTD_NAND_ECC_SMC=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_ECC_BCH=y
CONFIG_MTD_NAND_MUSEUM_IDS=y
CONFIG_MTD_NAND_DENALI=m
CONFIG_MTD_NAND_DENALI_DT=m
CONFIG_MTD_NAND_GPIO=m
CONFIG_MTD_NAND_DISKONCHIP=y
CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE=y
CONFIG_MTD_NAND_DOCG4=m
CONFIG_MTD_NAND_NANDSIM=y
CONFIG_MTD_NAND_PLATFORM=y
CONFIG_MTD_NAND_SH_FLCTL=y
CONFIG_MTD_ONENAND=y
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
CONFIG_MTD_ONENAND_GENERIC=m
CONFIG_MTD_ONENAND_SIM=y
CONFIG_MTD_LPDDR=m
CONFIG_MTD_UBI=m
CONFIG_MTD_UBI_FASTMAP=y
# CONFIG_BLK_DEV is not set
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=8
CONFIG_SERIAL_SH_SCI_CONSOLE=y
# CONFIG_HW_RANDOM is not set
CONFIG_SPI=y
# CONFIG_HWMON is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_DNOTIFY is not set
# CONFIG_INOTIFY_USER is not set
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
# CONFIG_JFFS2_ZLIB is not set
CONFIG_JFFS2_LZO=y
# CONFIG_JFFS2_RTIME is not set
CONFIG_JFFS2_RUBIN=y
CONFIG_UBIFS_FS=m
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
# CONFIG_ARM_UNWIND is not set
CONFIG_KEYS=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ANSI_CPRNG=y
# CONFIG_CRYPTO_HW is not set
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_PID_NS is not set
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_ARCH_SHMOBILE=y
CONFIG_ARCH_SH7372=y
CONFIG_MACH_MACKEREL=y
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
CONFIG_FORCE_MAX_ZONEORDER=15
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="console=tty0, console=ttySC0,115200 earlyprintk=sh-sci.0,115200 root=/dev/nfs nfsroot=,tcp,v3 ip=dhcp memchunk.vpu=64m memchunk.veu0=8m memchunk.spu0=2m mem=240m"
CONFIG_KEXEC=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_PM_RUNTIME=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_MTD=y
CONFIG_MTD_TESTS=m
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_REDBOOT_PARTS_READONLY=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_AFS_PARTS=m
CONFIG_MTD_AR7_PARTS=m
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
CONFIG_INFTL=m
CONFIG_RFD_FTL=m
CONFIG_SSFDC=m
CONFIG_SM_FTL=m
CONFIG_MTD_OOPS=y
CONFIG_MTD_SWAP=m
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_OTP=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_ROM=y
CONFIG_MTD_ABSENT=y
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_COMPAT=y
CONFIG_MTD_IMPA7=m
CONFIG_MTD_GPIO_ADDR=y
CONFIG_MTD_PLATRAM=y
CONFIG_MTD_LATCH_ADDR=m
CONFIG_MTD_DATAFLASH=y
CONFIG_MTD_M25P80=y
# CONFIG_M25PXX_USE_FAST_READ is not set
CONFIG_MTD_SST25L=y
CONFIG_MTD_SLRAM=y
CONFIG_MTD_PHRAM=y
CONFIG_MTD_MTDRAM=m
CONFIG_MTD_BLOCK2MTD=y
CONFIG_MTD_DOC2000=m
CONFIG_MTD_DOC2001=m
CONFIG_MTD_DOC2001PLUS=y
CONFIG_MTD_DOCG3=m
CONFIG_MTD_DOCPROBE_ADVANCED=y
CONFIG_MTD_NAND_ECC_SMC=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_ECC_BCH=y
CONFIG_MTD_NAND_MUSEUM_IDS=y
CONFIG_MTD_NAND_DENALI=m
CONFIG_MTD_NAND_DENALI_DT=m
CONFIG_MTD_NAND_GPIO=m
CONFIG_MTD_NAND_DISKONCHIP=y
CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE=y
CONFIG_MTD_NAND_DOCG4=m
CONFIG_MTD_NAND_NANDSIM=y
CONFIG_MTD_NAND_PLATFORM=y
CONFIG_MTD_NAND_SH_FLCTL=y
CONFIG_MTD_ONENAND=y
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
CONFIG_MTD_ONENAND_GENERIC=m
CONFIG_MTD_ONENAND_SIM=y
CONFIG_MTD_LPDDR=m
CONFIG_MTD_UBI=m
CONFIG_MTD_UBI_FASTMAP=y
# CONFIG_BLK_DEV is not set
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_SERIO is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=8
CONFIG_SERIAL_SH_SCI_CONSOLE=y
# CONFIG_HW_RANDOM is not set
CONFIG_SPI=y
# CONFIG_HWMON is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_DNOTIFY is not set
# CONFIG_INOTIFY_USER is not set
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
# CONFIG_JFFS2_ZLIB is not set
CONFIG_JFFS2_LZO=y
# CONFIG_JFFS2_RTIME is not set
CONFIG_JFFS2_RUBIN=y
CONFIG_UBIFS_FS=m
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
# CONFIG_ARM_UNWIND is not set
CONFIG_KEYS=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ANSI_CPRNG=y
# CONFIG_CRYPTO_HW is not set
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121017/2fcc1b34/attachment-0001.sig>
^ permalink raw reply
* [PATCH] usb: phy: samsung: Introducing usb phy driver for hsotg
From: Kukjin Kim @ 2012-10-17 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350036934-6051-1-git-send-email-p.paneri@samsung.com>
Praveen Paneri wrote:
>
> platform_set_drvdata() required for driver's remove function, so adding
> it back.
>
> From v6:
> Added TODO for phy bindings with controller
> Dropped platform_set_drvdata() from driver probe
>
> This driver uses usb_phy interface to interact with s3c-hsotg. Supports
> phy_init and phy_shutdown functions to enable/disable phy. Tested with
> smdk6410 and smdkv310. More SoCs can be brought under later.
>
> Signed-off-by: Praveen Paneri <p.paneri@samsung.com>
> Acked-by: Heiko Stuebner <heiko@sntech.de>
> ---
> .../devicetree/bindings/usb/samsung-usbphy.txt | 11 +
> drivers/usb/phy/Kconfig | 8 +
> drivers/usb/phy/Makefile | 1 +
> drivers/usb/phy/samsung-usbphy.c | 357
++++++++++++++++++++
> include/linux/platform_data/samsung-usbphy.h | 27 ++
> 5 files changed, 404 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/samsung-
> usbphy.txt
> create mode 100644 drivers/usb/phy/samsung-usbphy.c
> create mode 100644 include/linux/platform_data/samsung-usbphy.h
>
> diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> new file mode 100644
> index 0000000..7b26e2d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> @@ -0,0 +1,11 @@
> +* Samsung's usb phy transceiver
> +
> +The Samsung's phy transceiver is used for controlling usb otg phy for
> +s3c-hsotg usb device controller.
> +TODO: Adding the PHY binding with controller(s) according to the under
> +developement generic PHY driver.
> +
> +Required properties:
> +- compatible : should be "samsung,exynos4210-usbphy"
> +- reg : base physical address of the phy registers and length of memory
> mapped
> + region.
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index 63c339b..313685f 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -32,3 +32,11 @@ config MV_U3D_PHY
> help
> Enable this to support Marvell USB 3.0 phy controller for Marvell
> SoC.
> +
> +config SAMSUNG_USBPHY
> + bool "Samsung USB PHY controller Driver"
> + depends on USB_S3C_HSOTG
> + select USB_OTG_UTILS
> + help
> + Enable this to support Samsung USB phy controller for samsung
> + SoCs.
> diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> index b069f29..55dcfc1 100644
> --- a/drivers/usb/phy/Makefile
> +++ b/drivers/usb/phy/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_OMAP_USB2) +=
omap-usb2.o
> obj-$(CONFIG_USB_ISP1301) += isp1301.o
> obj-$(CONFIG_MV_U3D_PHY) += mv_u3d_phy.o
> obj-$(CONFIG_USB_EHCI_TEGRA) += tegra_usb_phy.o
> +obj-$(CONFIG_SAMSUNG_USBPHY) += samsung-usbphy.o
> diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-
> usbphy.c
> new file mode 100644
> index 0000000..14c182f
> --- /dev/null
> +++ b/drivers/usb/phy/samsung-usbphy.c
Hi,
Basically I agree and this is a good approach to support usb phy for Samsung
stuff...but there are some comments ;)
> @@ -0,0 +1,357 @@
> +/* linux/drivers/usb/phy/samsung-usbphy.c
> + *
> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Author: Praveen Paneri <p.paneri@samsung.com>
> + *
> + * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG
> controller
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/usb/otg.h>
> +#include <linux/platform_data/samsung-usbphy.h>
> +
> +/* Register definitions */
> +
> +#define S3C_PHYPWR (0x00)
> +
IMHO, according to the file name, samsung-usbphy, SAMSUNG_ is better here?
> +#define S3C_PHYPWR_NORMAL_MASK (0x19 << 0)
> +#define S3C_PHYPWR_OTG_DISABLE (1 << 4)
> +#define S3C_PHYPWR_ANALOG_POWERDOWN (1 << 3)
> +#define S3C_PHYPWR_FORCE_SUSPEND (1 << 1)
> +/* For Exynos4 */
> +#define EXYNOS4_PHYPWR_NORMAL_MASK (0x39 << 0)
Hmm...is this right? If so, need to use exact name for the definition.
See arch/arm/mach-exynos/include/mach/regs-usb-phy.h
> +#define EXYNOS4_PHYPWR_SLEEP (1 << 5)
Ditto.
> +
> +#define S3C_PHYCLK (0x04)
> +
> +#define S3C_PHYCLK_MODE_SERIAL (1 << 6)
MODE_USB11?
> +#define S3C_PHYCLK_EXT_OSC (1 << 5)
> +#define S3C_PHYCLK_COMMON_ON_N (1 << 4)
There are Samsung SoCs which is having two PHYs, so I think, we need to
design this with considering it.
> +#define S3C_PHYCLK_ID_PULL (1 << 2)
> +#define S3C_PHYCLK_CLKSEL_MASK (0x3 << 0)
> +#define S3C_PHYCLK_CLKSEL_SHIFT (0)
> +#define S3C_PHYCLK_CLKSEL_48M (0x0 << 0)
> +#define S3C_PHYCLK_CLKSEL_12M (0x2 << 0)
> +#define S3C_PHYCLK_CLKSEL_24M (0x3 << 0)
As you know, the values for CLKSEL are different on each Samsung SoCs...if
we use this patch, we need to implement for other SoCs many things. In
addition, this patch says can support EXYNOS4210 but not actually...
> +
> +#define S3C_RSTCON (0x08)
> +
> +#define S3C_RSTCON_PHYCLK (1 << 2)
> +#define S3C_RSTCON_HCLK (1 << 1)
> +#define S3C_RSTCON_PHY (1 << 0)
> +
> +#ifndef MHZ
> +#define MHZ (1000*1000)
> +#endif
> +
> +enum samsung_cpu_type {
> + TYPE_S3C64XX,
> + TYPE_EXYNOS4210,
> +};
> +
> +/*
> + * struct samsung_usbphy - transceiver driver state
> + * @phy: transceiver structure
> + * @plat: platform data
> + * @dev: The parent device supplied to the probe function
> + * @clk: usb phy clock
> + * @regs: usb phy register memory base
> + * @ref_clk_freq: reference clock frequency selection
> + * @cpu_type: machine identifier
> + */
> +struct samsung_usbphy {
> + struct usb_phy phy;
> + struct samsung_usbphy_data *plat;
> + struct device *dev;
> + struct clk *clk;
> + void __iomem *regs;
> + int ref_clk_freq;
> + int cpu_type;
> +};
> +
> +#define phy_to_sphy(x) container_of((x), struct
samsung_usbphy,
> phy)
> +
> +/*
> + * Returns reference clock frequency selection value
> + */
> +static int samsung_usbphy_get_refclk_freq(struct samsung_usbphy *sphy)
> +{
> + struct clk *ref_clk;
> + int refclk_freq = 0;
> +
> + ref_clk = clk_get(sphy->dev, "xusbxti");
> + if (IS_ERR(ref_clk)) {
IS_ERR_OR_NULL(ref_clk)?
> + dev_err(sphy->dev, "Failed to get reference clock\n");
> + return PTR_ERR(ref_clk);
> + }
> +
> + switch (clk_get_rate(ref_clk)) {
> + case 12 * MHZ:
> + refclk_freq |= S3C_PHYCLK_CLKSEL_12M;
Just,
+ refclk_freq = S3C_PHYCLK_CLKSEL_12M;
because its defalut value is 0...BTW, how do you think to support other SoCs
such as EXYNOS4210, EXYNOS4X12?
> + break;
> + case 24 * MHZ:
> + refclk_freq |= S3C_PHYCLK_CLKSEL_24M;
Ditto.
> + break;
> + default:
> + case 48 * MHZ:
> + /* default reference clock */
> + refclk_freq |= S3C_PHYCLK_CLKSEL_48M;
Ditto...and default refernec clock for EXYNOS4 is 24MHz...
> + break;
> + }
> + clk_put(ref_clk);
> +
> + return refclk_freq;
> +}
> +
Hmm...I need more time to look at this again...
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [RFC PATCH 1/4] ARM: kernel: add device tree init map function
From: Lorenzo Pieralisi @ 2012-10-17 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507DC6C3.6090403@gmail.com>
Hi Rob,
thanks for having a look.
On Tue, Oct 16, 2012 at 09:42:43PM +0100, Rob Herring wrote:
> On 10/16/2012 08:21 AM, Lorenzo Pieralisi wrote:
> > When booting through a device tree, the kernel cpu logical id map can be
> > initialized using device tree data passed by FW or through an embedded blob.
> >
> > This patch adds a function that parses device tree "cpu" nodes and
> > retrieves the corresponding CPUs hardware identifiers (MPIDR).
> > It sets the possible cpus and the cpu logical map values according to
> > the number of CPUs defined in the device tree and respective properties.
> >
> > The primary CPU is assigned cpu logical number 0 to keep the current
> > convention valid.
> >
> > Current bindings documentation is included in the patch:
> >
> > Documentation/devicetree/bindings/arm/cpus.txt
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > ---
> > Documentation/devicetree/bindings/arm/cpus.txt | 42 +++++++++++++++++++++++
> > arch/arm/include/asm/prom.h | 2 ++
> > arch/arm/kernel/devtree.c | 47 ++++++++++++++++++++++++++
> > 3 files changed, 91 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/cpus.txt
> >
> > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> > new file mode 100644
> > index 0000000..897f3b4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> > @@ -0,0 +1,42 @@
> > +* ARM CPUs binding description
> > +
> > +The device tree allows to describe the layout of CPUs in a system through
> > +the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
> > +defining properties for every cpu.
> > +
> > +Bindings for CPU nodes follow the ePAPR standard, available from:
> > +
> > +http://devicetree.org
> > +
> > +For the ARM architecture every CPU node must contain the following property:
> > +
> > +- reg : property defining the CPU MPIDR[23:0] register bits
>
> defining or matching the MPIDR?
I would say matching, otherwise it reads as if the MPIDR were writable.
> > +
> > +Every cpu node is required to set its device_type to "cpu".
>
> This is a bit questionable as device_type is deprecated for FDT.
> However, since the ePAPR defines using it
>
> You should add a compatible property for the cpu model.
Ok, I will.
> > +
> > +Example:
> > +
> > + cpus {
> > + #size-cells = <0>;
> > + #address-cells = <1>;
> > +
> > + CPU0: cpu at 0 {
> > + device_type = "cpu";
> > + reg = <0x0>;
> > + };
> > +
> > + CPU1: cpu at 1 {
> > + device_type = "cpu";
> > + reg = <0x1>;
> > + };
> > +
> > + CPU2: cpu at 100 {
> > + device_type = "cpu";
> > + reg = <0x100>;
> > + };
> > +
> > + CPU3: cpu at 101 {
> > + device_type = "cpu";
> > + reg = <0x101>;
> > + };
> > + };
> > diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
> > index aeae9c6..8dd51dc 100644
> > --- a/arch/arm/include/asm/prom.h
> > +++ b/arch/arm/include/asm/prom.h
> > @@ -15,6 +15,7 @@
> >
> > extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
> > extern void arm_dt_memblock_reserve(void);
> > +extern void __init arm_dt_init_cpu_maps(void);
> >
> > #else /* CONFIG_OF */
> >
> > @@ -24,6 +25,7 @@ static inline struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
> > }
> >
> > static inline void arm_dt_memblock_reserve(void) { }
> > +static inline void arm_dt_init_cpu_maps(void) { }
> >
> > #endif /* CONFIG_OF */
> > #endif /* ASMARM_PROM_H */
> > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> > index bee7f9d..c86e414 100644
> > --- a/arch/arm/kernel/devtree.c
> > +++ b/arch/arm/kernel/devtree.c
> > @@ -19,8 +19,10 @@
> > #include <linux/of_irq.h>
> > #include <linux/of_platform.h>
> >
> > +#include <asm/cputype.h>
> > #include <asm/setup.h>
> > #include <asm/page.h>
> > +#include <asm/smp_plat.h>
> > #include <asm/mach/arch.h>
> > #include <asm/mach-types.h>
> >
> > @@ -61,6 +63,51 @@ void __init arm_dt_memblock_reserve(void)
> > }
> > }
> >
> > +/*
> > + * arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
> > + * and builds the cpu logical map array containing MPIDR values related to
> > + * logical cpus
> > + *
> > + * Updates the cpu possible mask with the number of parsed cpu nodes
> > + */
> > +void __init arm_dt_init_cpu_maps(void)
> > +{
> > + struct device_node *dn = NULL;
> > + int i, cpu = 1;
> > +
> > + while ((dn = of_find_node_by_type(dn, "cpu")) && cpu <= nr_cpu_ids) {
>
> I think all /cpu nodes would have the right type. You could use
> for_each_child_of_node here.
Starting from /cpus, looked-up by path, right ?
> > + const u32 *hwid;
> > + int len;
> > +
> > + pr_debug(" * %s...\n", dn->full_name);
> > +
> > + hwid = of_get_property(dn, "reg", &len);
> > +
>
> Use of_property_read_u32.
Ok.
Thanks,
Lorenzo
^ permalink raw reply
* [RFC PATCH] ARM: kernel: update cpuinfo to print all online CPUs features
From: Lorenzo Pieralisi @ 2012-10-17 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016214752.GH21164@n2100.arm.linux.org.uk>
On Tue, Oct 16, 2012 at 10:47:52PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 16, 2012 at 11:29:39PM +0530, Santosh Shilimkar wrote:
> > Not exactly related to the $subject patch, but I remember doing a patch
> > to have cat /proc/cpuinfo spitting only online CPUs just like x86 using
> > for_each_online_cpu(i).
> > At that point Russell mentioned about a possibility of read() syscall
> > spreading over the hot-plug operation and hence the above may not
> > be safe.
> >
> > is that right Russell ?
>
> That is correct, but you will notice that the code now uses the online
> cpus rather than the present, inspite of my objections. I gave up
> fighting the case, so now people get to live with the consequences of
> this.
>
> This will be fun with dynamic hotplugging with big.LITTLE when people
> come to read any of these files which change their output with the
> online CPUs. Oh what fun we're in for there.
I had a look at how glibc currently detects cpus in __get_nprocs() and all
methods end up relying on online CPUs:
- /sys/devices/system/cpu/online
- /proc/stat
- /proc/cpuinfo
Given the thread:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-June/054081.html
I do not think there is room to change the current behaviour of /proc/cpuinfo
as far as the online vs. present argument goes, and I certainly did not try.
I posted this code just to understand if it makes sense to expose all CPU ids
in /proc/cpuinfo the way I did (the same way x86 does, even though the code is
slightly different).
> I guess the only way to convince people is to let them make their
> mistakes in the kernel.
That's what I wanted to prevent by posting this code, namely getting
feedback on the best way to improve /proc/cpuinfo for systems where CPU
ids are not homogeneous.
The "online vs. present" issue is already there as Russell pointed out.
Thank you very much for the review, any further feedback appreciated.
Lorenzo
^ permalink raw reply
* [Celinux-dev] PDF documentation
From: Wolfgang Denk @ 2012-10-17 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507DA84A.2080904@am.sony.com>
Dear Tim,
In message <507DA84A.2080904@am.sony.com> you wrote:
>
> Several years ago, CELF tried to add a similar capability to
> MoinMoin (the ability to take arbitrary page lists, and
> automatically publish them to PDF). Unfortunately, it didn't
> work very well. The tools to produce PDF were pretty bad back then.
We use Foswiki for capabilities like this. Note that I definitely
don't want to start a "my wiki is better than your wiki" religous war
here ;-)
> It sounds like the tools have improved since we did this, and
> maybe we should look again and see if there's something similar
> we could add to the elinux wiki.
You are using mediawiki - there appear to be such solutions as well,
see for example
http://www.blue-spice.org/de/produkte/packages/bookmaker/
Sorry, this is in German only, and no free software.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"He only drinks when he gets depressed." "Why does he get depressed?"
"Sometimes it's because he hasn't had a drink."
- Terry Pratchett, _Men at Arms_
^ permalink raw reply
* [PATCH v2 4/4] ARM: kirkwood: DT board setup for Network Space Mini v2
From: Simon Guinot @ 2012-10-17 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350468546-25901-1-git-send-email-simon.guinot@sequanux.org>
This patch adds DT board setup for the LaCie NAS Network Space Mini v2
(aka SafeBox). The hardware characteristics are very close to those of
the Network Space Lite v2. The main difference are:
- A GPIO fan which is only available on the NS2 Mini.
- A single USB host port is wired on the NS2 Mini. The NS2 Lite provides
an additional dual-mode USB port (host/device).
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
Changes for v2:
- Fix compatibility string for driver leds-ns2. Use "lacie,ns2-leds".
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/kirkwood-ns2mini.dts | 49 ++++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 8 ++++++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/board-dt.c | 4 ++-
arch/arm/mach-kirkwood/board-ns2.c | 3 +-
arch/arm/mach-kirkwood/common.h | 3 +-
drivers/leds/Kconfig | 2 +-
8 files changed, 67 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/kirkwood-ns2mini.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 42b3e90..f2af858 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -41,6 +41,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
kirkwood-ns2.dtb \
kirkwood-ns2lite.dtb \
kirkwood-ns2max.dtb \
+ kirkwood-ns2mini.dtb \
kirkwood-ts219-6281.dtb \
kirkwood-ts219-6282.dtb
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-ns2mini.dts b/arch/arm/boot/dts/kirkwood-ns2mini.dts
new file mode 100644
index 0000000..b79f5eb
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2mini.dts
@@ -0,0 +1,49 @@
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+ model = "LaCie Network Space Mini v2";
+ compatible = "lacie,netspace_mini_v2", "marvell,kirkwood-88f6192", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x8000000>;
+ };
+
+ ocp at f1000000 {
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <1>;
+ };
+ };
+
+ gpio_fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio0 22 1
+ &gpio0 7 1
+ &gpio1 1 1
+ &gpio0 23 1>;
+ gpio-fan,speed-map =
+ < 0 0
+ 3000 15
+ 3180 14
+ 4140 13
+ 4570 12
+ 6760 11
+ 7140 10
+ 7980 9
+ 9200 8>;
+ alarm-gpios = <&gpio0 25 1>;
+ };
+
+ ns2-leds {
+ compatible = "lacie,ns2-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ slow-gpio = <&gpio0 29 0>;
+ cmd-gpio = <&gpio0 30 0>;
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 83df331..757bdb3 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -158,6 +158,14 @@ config MACH_NETSPACE_LITE_V2_DT
Say 'Y' here if you want your kernel to support the LaCie
Network Space Lite v2 NAS, using Flattened Device Tree.
+config MACH_NETSPACE_MINI_V2_DT
+ bool "LaCie Network Space Mini v2 NAS (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the LaCie
+ Network Space Mini v2 NAS (aka SafeBox), using Flattened
+ Device Tree.
+
config MACH_TS219
bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 4d4b7d4..3ff4aa1 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -35,3 +35,4 @@ obj-$(CONFIG_MACH_INETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_LITE_V2_DT) += board-ns2.o
+obj-$(CONFIG_MACH_NETSPACE_MINI_V2_DT) += board-ns2.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index ab7595e..c3dd5d2 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -99,7 +99,8 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("lacie,inetspace_v2") ||
of_machine_is_compatible("lacie,netspace_v2") ||
of_machine_is_compatible("lacie,netspace_max_v2") ||
- of_machine_is_compatible("lacie,netspace_lite_v2"))
+ of_machine_is_compatible("lacie,netspace_lite_v2") ||
+ of_machine_is_compatible("lacie,netspace_mini_v2"))
ns2_init();
of_platform_populate(NULL, kirkwood_dt_match_table,
@@ -122,6 +123,7 @@ static const char *kirkwood_dt_board_compat[] = {
"lacie,netspace_max_v2",
"lacie,netspace_v2",
"lacie,netspace_lite_v2",
+ "lacie,netspace_mini_v2",
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
index da8c4c5..78596c4 100644
--- a/arch/arm/mach-kirkwood/board-ns2.c
+++ b/arch/arm/mach-kirkwood/board-ns2.c
@@ -74,7 +74,8 @@ void __init ns2_init(void)
kirkwood_mpp_conf(ns2_mpp_config);
kirkwood_ehci_init();
- if (of_machine_is_compatible("lacie,netspace_lite_v2"))
+ if (of_machine_is_compatible("lacie,netspace_lite_v2") ||
+ of_machine_is_compatible("lacie,netspace_mini_v2"))
ns2_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
kirkwood_ge00_init(&ns2_ge00_data);
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 6949d81..95eb69b 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -115,7 +115,8 @@ static inline void km_kirkwood_init(void) {};
#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
defined(CONFIG_MACH_NETSPACE_V2_DT) || \
defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
- defined(CONFIG_MACH_NETSPACE_LITE_V2_DT)
+ defined(CONFIG_MACH_NETSPACE_LITE_V2_DT) || \
+ defined(CONFIG_MACH_NETSPACE_MINI_V2_DT)
void ns2_init(void);
#else
static inline void ns2_init(void) {};
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index e455c08..b58bc8a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -381,7 +381,7 @@ config LEDS_NS2
depends on MACH_NETSPACE_V2 || MACH_INETSPACE_V2 || \
MACH_NETSPACE_MAX_V2 || MACH_D2NET_V2 || \
MACH_NETSPACE_V2_DT || MACH_INETSPACE_V2_DT || \
- MACH_NETSPACE_MAX_V2_DT
+ MACH_NETSPACE_MAX_V2_DT || MACH_NETSPACE_MINI_V2_DT
default y
help
This option enable support for the dual-GPIO LED found on the
--
1.7.10
^ permalink raw reply related
* [PATCH v2 3/4] ARM: kirkwood: DT board setup for Network Space Lite v2
From: Simon Guinot @ 2012-10-17 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350468546-25901-1-git-send-email-simon.guinot@sequanux.org>
This patch adds DT board setup for the LaCie NAS Network Space Lite v2.
This board is derived from the Network Space v2 and a lot of hardware
characteristics are shared.
- CPU: Marvell 88F6192 800Mhz
- SDRAM memory: 128MB DDR2 200Mhz
- 1 SATA port: internal
- Gigabit ethernet: PHY Marvell 88E1318
- Flash memory: SPI NOR 512KB (Macronix MX25L4005A)
- i2c EEPROM: 512 bytes (24C04 type)
- 2 USB2 ports: host and host/device
- 1 push button
- 1 SATA LED (bi-color, blue and red)
Note that the SATA LED is not compatible with the driver leds-ns2. The
LED behaviour ("on", "off" or "SATA activity blink") is controlled via
a single MPP (21).
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
No changes for v2.
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/kirkwood-ns2lite.dts | 30 ++++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 7 +++++++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/board-dt.c | 4 +++-
arch/arm/mach-kirkwood/board-ns2.c | 3 +++
arch/arm/mach-kirkwood/common.h | 3 ++-
7 files changed, 47 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/kirkwood-ns2lite.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6201b6..42b3e90 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -39,6 +39,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
kirkwood-lschlv2.dtb \
kirkwood-lsxhl.dtb \
kirkwood-ns2.dtb \
+ kirkwood-ns2lite.dtb \
kirkwood-ns2max.dtb \
kirkwood-ts219-6281.dtb \
kirkwood-ts219-6282.dtb
diff --git a/arch/arm/boot/dts/kirkwood-ns2lite.dts b/arch/arm/boot/dts/kirkwood-ns2lite.dts
new file mode 100644
index 0000000..b02eb4e
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2lite.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+ model = "LaCie Network Space Lite v2";
+ compatible = "lacie,netspace_lite_v2", "marvell,kirkwood-88f6192", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x8000000>;
+ };
+
+ ocp at f1000000 {
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <1>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ gpios = <&gpio0 30 1>;
+ linux,default-trigger = "default-on";
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 847e0c2..83df331 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -151,6 +151,13 @@ config MACH_NETSPACE_MAX_V2_DT
Say 'Y' here if you want your kernel to support the LaCie
Network Space Max v2 NAS, using Flattened Device Tree.
+config MACH_NETSPACE_LITE_V2_DT
+ bool "LaCie Network Space Lite v2 NAS (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the LaCie
+ Network Space Lite v2 NAS, using Flattened Device Tree.
+
config MACH_TS219
bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 1f63d80..4d4b7d4 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -34,3 +34,4 @@ obj-$(CONFIG_MACH_KM_KIRKWOOD_DT) += board-km_kirkwood.o
obj-$(CONFIG_MACH_INETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_V2_DT) += board-ns2.o
obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT) += board-ns2.o
+obj-$(CONFIG_MACH_NETSPACE_LITE_V2_DT) += board-ns2.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index b3e0519..ab7595e 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -98,7 +98,8 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("lacie,inetspace_v2") ||
of_machine_is_compatible("lacie,netspace_v2") ||
- of_machine_is_compatible("lacie,netspace_max_v2"))
+ of_machine_is_compatible("lacie,netspace_max_v2") ||
+ of_machine_is_compatible("lacie,netspace_lite_v2"))
ns2_init();
of_platform_populate(NULL, kirkwood_dt_match_table,
@@ -120,6 +121,7 @@ static const char *kirkwood_dt_board_compat[] = {
"lacie,inetspace_v2",
"lacie,netspace_max_v2",
"lacie,netspace_v2",
+ "lacie,netspace_lite_v2",
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
index b36c55c..da8c4c5 100644
--- a/arch/arm/mach-kirkwood/board-ns2.c
+++ b/arch/arm/mach-kirkwood/board-ns2.c
@@ -16,6 +16,7 @@
#include <linux/platform_device.h>
#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
+#include <linux/of.h>
#include "common.h"
#include "mpp.h"
@@ -73,6 +74,8 @@ void __init ns2_init(void)
kirkwood_mpp_conf(ns2_mpp_config);
kirkwood_ehci_init();
+ if (of_machine_is_compatible("lacie,netspace_lite_v2"))
+ ns2_ge00_data.phy_addr = MV643XX_ETH_PHY_ADDR(0);
kirkwood_ge00_init(&ns2_ge00_data);
if (gpio_request(NS2_GPIO_POWER_OFF, "power-off") == 0 &&
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index 2f75f3f..6949d81 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -114,7 +114,8 @@ static inline void km_kirkwood_init(void) {};
#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
defined(CONFIG_MACH_NETSPACE_V2_DT) || \
- defined(CONFIG_MACH_NETSPACE_MAX_V2_DT)
+ defined(CONFIG_MACH_NETSPACE_MAX_V2_DT) || \
+ defined(CONFIG_MACH_NETSPACE_LITE_V2_DT)
void ns2_init(void);
#else
static inline void ns2_init(void) {};
--
1.7.10
^ permalink raw reply related
* [PATCH v3 2/4] ARM: kirkwood: DT board setup for Network Space v2 and parents
From: Simon Guinot @ 2012-10-17 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350468546-25901-1-git-send-email-simon.guinot@sequanux.org>
This patch adds DT board setup for LaCie Network Space v2 and parents,
based on the Marvell Kirkwood 6281 SoC. This includes Network Space v2
(Max) and Internet Space v2.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
Changes for v2:
- Rebased against Linux 3.7-rc1.
- Add missing Kconfig options MACH_INETSPACE_V2_DT and
MACH_NETSPACE_MAX_V2_DT.
- Use ns2-leds DT binding.
- Move gpio-leds definition out from kirkwood-ns2-common.dtsi. The ns2
lite board (patch 3/4) uses a different configuration for GPIO LEDs.
Changes for v3:
- Fix patch version (update to v3).
- Fix compatibility string for driver leds-ns2. Use "lacie,ns2-leds".
arch/arm/boot/dts/Makefile | 3 +
arch/arm/boot/dts/kirkwood-is2.dts | 30 ++++++++++
arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 63 +++++++++++++++++++++
arch/arm/boot/dts/kirkwood-ns2.dts | 30 ++++++++++
arch/arm/boot/dts/kirkwood-ns2max.dts | 49 ++++++++++++++++
arch/arm/mach-kirkwood/Kconfig | 21 +++++++
arch/arm/mach-kirkwood/Makefile | 3 +
arch/arm/mach-kirkwood/board-dt.c | 8 +++
arch/arm/mach-kirkwood/board-ns2.c | 83 ++++++++++++++++++++++++++++
arch/arm/mach-kirkwood/common.h | 8 +++
drivers/leds/Kconfig | 4 +-
11 files changed, 301 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/kirkwood-is2.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2-common.dtsi
create mode 100644 arch/arm/boot/dts/kirkwood-ns2.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2max.dts
create mode 100644 arch/arm/mach-kirkwood/board-ns2.c
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c1ce813..e6201b6 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -34,9 +34,12 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
kirkwood-ib62x0.dtb \
kirkwood-iconnect.dtb \
kirkwood-iomega_ix2_200.dtb \
+ kirkwood-is2.dtb \
kirkwood-km_kirkwood.dtb \
kirkwood-lschlv2.dtb \
kirkwood-lsxhl.dtb \
+ kirkwood-ns2.dtb \
+ kirkwood-ns2max.dtb \
kirkwood-ts219-6281.dtb \
kirkwood-ts219-6282.dtb
dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-is2.dts b/arch/arm/boot/dts/kirkwood-is2.dts
new file mode 100644
index 0000000..0bdce0a
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-is2.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+ model = "LaCie Internet Space v2";
+ compatible = "lacie,inetspace_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x8000000>;
+ };
+
+ ocp at f1000000 {
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <1>;
+ };
+ };
+
+ ns2-leds {
+ compatible = "lacie,ns2-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ slow-gpio = <&gpio0 29 0>;
+ cmd-gpio = <&gpio0 30 0>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2-common.dtsi b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
new file mode 100644
index 0000000..9bc6785
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2-common.dtsi
@@ -0,0 +1,63 @@
+/include/ "kirkwood.dtsi"
+
+/ {
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ ocp at f1000000 {
+ serial at 12000 {
+ clock-frequency = <166666667>;
+ status = "okay";
+ };
+
+ spi at 10600 {
+ status = "okay";
+
+ flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "mx25l4005a";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ mode = <0>;
+
+ partition at 0 {
+ reg = <0x0 0x80000>;
+ label = "u-boot";
+ };
+ };
+ };
+
+ i2c at 11000 {
+ status = "okay";
+
+ eeprom at 50 {
+ compatible = "at,24c04";
+ pagesize = <16>;
+ reg = <0x50>;
+ };
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ button at 1 {
+ label = "Power push button";
+ linux,code = <116>;
+ gpios = <&gpio1 0 0>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ red-fail {
+ label = "ns2:red:fail";
+ gpios = <&gpio0 12 0>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2.dts b/arch/arm/boot/dts/kirkwood-ns2.dts
new file mode 100644
index 0000000..f2d36ecf
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2.dts
@@ -0,0 +1,30 @@
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+ model = "LaCie Network Space v2";
+ compatible = "lacie,netspace_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x10000000>;
+ };
+
+ ocp at f1000000 {
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <1>;
+ };
+ };
+
+ ns2-leds {
+ compatible = "lacie,ns2-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ slow-gpio = <&gpio0 29 0>;
+ cmd-gpio = <&gpio0 30 0>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-ns2max.dts b/arch/arm/boot/dts/kirkwood-ns2max.dts
new file mode 100644
index 0000000..bcec4d6
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ns2max.dts
@@ -0,0 +1,49 @@
+/dts-v1/;
+
+/include/ "kirkwood-ns2-common.dtsi"
+
+/ {
+ model = "LaCie Network Space Max v2";
+ compatible = "lacie,netspace_max_v2", "marvell,kirkwood-88f6281", "marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x10000000>;
+ };
+
+ ocp at f1000000 {
+ sata at 80000 {
+ status = "okay";
+ nr-ports = <2>;
+ };
+ };
+
+ gpio_fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio0 22 1
+ &gpio0 7 1
+ &gpio1 1 1
+ &gpio0 23 1>;
+ gpio-fan,speed-map =
+ < 0 0
+ 1500 15
+ 1700 14
+ 1800 13
+ 2100 12
+ 3100 11
+ 3300 10
+ 4300 9
+ 5500 8>;
+ alarm-gpios = <&gpio0 25 1>;
+ };
+
+ ns2-leds {
+ compatible = "lacie,ns2-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ slow-gpio = <&gpio0 29 0>;
+ cmd-gpio = <&gpio0 30 0>;
+ };
+ };
+};
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index 50bca50..847e0c2 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -130,6 +130,27 @@ config MACH_KM_KIRKWOOD_DT
Say 'Y' here if you want your kernel to support the
Keymile Kirkwood Reference Desgin, using Flattened Device Tree.
+config MACH_INETSPACE_V2_DT
+ bool "LaCie Internet Space v2 NAS (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the LaCie
+ Internet Space v2 NAS, using Flattened Device Tree.
+
+config MACH_NETSPACE_V2_DT
+ bool "LaCie Network Space v2 NAS (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the LaCie
+ Network Space v2 NAS, using Flattened Device Tree.
+
+config MACH_NETSPACE_MAX_V2_DT
+ bool "LaCie Network Space Max v2 NAS (Flattened Device Tree)"
+ select ARCH_KIRKWOOD_DT
+ help
+ Say 'Y' here if you want your kernel to support the LaCie
+ Network Space Max v2 NAS, using Flattened Device Tree.
+
config MACH_TS219
bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
help
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 294779f..1f63d80 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -31,3 +31,6 @@ obj-$(CONFIG_MACH_GOFLEXNET_DT) += board-goflexnet.o
obj-$(CONFIG_MACH_LSXL_DT) += board-lsxl.o
obj-$(CONFIG_MACH_IOMEGA_IX2_200_DT) += board-iomega_ix2_200.o
obj-$(CONFIG_MACH_KM_KIRKWOOD_DT) += board-km_kirkwood.o
+obj-$(CONFIG_MACH_INETSPACE_V2_DT) += board-ns2.o
+obj-$(CONFIG_MACH_NETSPACE_V2_DT) += board-ns2.o
+obj-$(CONFIG_MACH_NETSPACE_MAX_V2_DT) += board-ns2.o
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index 70c5a28..b3e0519 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void)
if (of_machine_is_compatible("keymile,km_kirkwood"))
km_kirkwood_init();
+ if (of_machine_is_compatible("lacie,inetspace_v2") ||
+ of_machine_is_compatible("lacie,netspace_v2") ||
+ of_machine_is_compatible("lacie,netspace_max_v2"))
+ ns2_init();
+
of_platform_populate(NULL, kirkwood_dt_match_table,
kirkwood_auxdata_lookup, NULL);
}
@@ -112,6 +117,9 @@ static const char *kirkwood_dt_board_compat[] = {
"buffalo,lsxl",
"iom,ix2-200",
"keymile,km_kirkwood",
+ "lacie,inetspace_v2",
+ "lacie,netspace_max_v2",
+ "lacie,netspace_v2",
NULL
};
diff --git a/arch/arm/mach-kirkwood/board-ns2.c b/arch/arm/mach-kirkwood/board-ns2.c
new file mode 100644
index 0000000..b36c55c
--- /dev/null
+++ b/arch/arm/mach-kirkwood/board-ns2.c
@@ -0,0 +1,83 @@
+/*
+ * Copyright 2012 (C), Simon Guinot <simon.guinot@sequanux.org>
+ *
+ * arch/arm/mach-kirkwood/board-ns2.c
+ *
+ * LaCie Network Space v2 board (and parents) initialization for drivers
+ * not converted to flattened device tree yet.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/mv643xx_eth.h>
+#include <linux/gpio.h>
+#include "common.h"
+#include "mpp.h"
+
+static struct mv643xx_eth_platform_data ns2_ge00_data = {
+ .phy_addr = MV643XX_ETH_PHY_ADDR(8),
+};
+
+static unsigned int ns2_mpp_config[] __initdata = {
+ MPP0_SPI_SCn,
+ MPP1_SPI_MOSI,
+ MPP2_SPI_SCK,
+ MPP3_SPI_MISO,
+ MPP4_NF_IO6,
+ MPP5_NF_IO7,
+ MPP6_SYSRST_OUTn,
+ MPP7_GPO, /* Fan speed (bit 1) */
+ MPP8_TW0_SDA,
+ MPP9_TW0_SCK,
+ MPP10_UART0_TXD,
+ MPP11_UART0_RXD,
+ MPP12_GPO, /* Red led */
+ MPP14_GPIO, /* USB fuse */
+ MPP16_GPIO, /* SATA 0 power */
+ MPP17_GPIO, /* SATA 1 power */
+ MPP18_NF_IO0,
+ MPP19_NF_IO1,
+ MPP20_SATA1_ACTn,
+ MPP21_SATA0_ACTn,
+ MPP22_GPIO, /* Fan speed (bit 0) */
+ MPP23_GPIO, /* Fan power */
+ MPP24_GPIO, /* USB mode select */
+ MPP25_GPIO, /* Fan rotation fail */
+ MPP26_GPIO, /* USB device vbus */
+ MPP28_GPIO, /* USB enable host vbus */
+ MPP29_GPIO, /* Blue led (slow register) */
+ MPP30_GPIO, /* Blue led (command register) */
+ MPP31_GPIO, /* Board power off */
+ MPP32_GPIO, /* Power button (0 = Released, 1 = Pushed) */
+ MPP33_GPO, /* Fan speed (bit 2) */
+ 0
+};
+
+#define NS2_GPIO_POWER_OFF 31
+
+static void ns2_power_off(void)
+{
+ gpio_set_value(NS2_GPIO_POWER_OFF, 1);
+}
+
+void __init ns2_init(void)
+{
+ /*
+ * Basic setup. Needs to be called early.
+ */
+ kirkwood_mpp_conf(ns2_mpp_config);
+
+ kirkwood_ehci_init();
+ kirkwood_ge00_init(&ns2_ge00_data);
+
+ if (gpio_request(NS2_GPIO_POWER_OFF, "power-off") == 0 &&
+ gpio_direction_output(NS2_GPIO_POWER_OFF, 0) == 0)
+ pm_power_off = ns2_power_off;
+ else
+ pr_err("ns2: failed to configure power-off GPIO\n");
+}
diff --git a/arch/arm/mach-kirkwood/common.h b/arch/arm/mach-kirkwood/common.h
index bcffd7c..2f75f3f 100644
--- a/arch/arm/mach-kirkwood/common.h
+++ b/arch/arm/mach-kirkwood/common.h
@@ -112,6 +112,14 @@ void km_kirkwood_init(void);
static inline void km_kirkwood_init(void) {};
#endif
+#if defined(CONFIG_MACH_INETSPACE_V2_DT) || \
+ defined(CONFIG_MACH_NETSPACE_V2_DT) || \
+ defined(CONFIG_MACH_NETSPACE_MAX_V2_DT)
+void ns2_init(void);
+#else
+static inline void ns2_init(void) {};
+#endif
+
/* early init functions not converted to fdt yet */
char *kirkwood_id(void);
void kirkwood_l2_init(void);
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index f508def..e455c08 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -379,7 +379,9 @@ config LEDS_NS2
tristate "LED support for Network Space v2 GPIO LEDs"
depends on LEDS_CLASS
depends on MACH_NETSPACE_V2 || MACH_INETSPACE_V2 || \
- MACH_NETSPACE_MAX_V2 || MACH_D2NET_V2
+ MACH_NETSPACE_MAX_V2 || MACH_D2NET_V2 || \
+ MACH_NETSPACE_V2_DT || MACH_INETSPACE_V2_DT || \
+ MACH_NETSPACE_MAX_V2_DT
default y
help
This option enable support for the dual-GPIO LED found on the
--
1.7.10
^ permalink raw reply related
* [PATCH v2 1/4] leds: leds-ns2: add device tree binding
From: Simon Guinot @ 2012-10-17 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350468546-25901-1-git-send-email-simon.guinot@sequanux.org>
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
---
Changes for v2:
- Fix compatibility string. Use "lacie,ns2-leds".
- Remove useless #else #endif statement.
.../devicetree/bindings/gpio/leds-ns2.txt | 26 +++++++
drivers/leds/leds-ns2.c | 78 +++++++++++++++++++-
2 files changed, 101 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/leds-ns2.txt
diff --git a/Documentation/devicetree/bindings/gpio/leds-ns2.txt b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
new file mode 100644
index 0000000..aef3aca
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/leds-ns2.txt
@@ -0,0 +1,26 @@
+Binding for dual-GPIO LED found on Network Space v2 (and parents).
+
+Required properties:
+- compatible: "lacie,ns2-leds".
+
+Each LED is represented as a sub-node of the ns2-leds device.
+
+Required sub-node properties:
+- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
+- slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification.
+
+Optional sub-node properties:
+- label: Name for this LED. If omitted, the label is taken from the node name.
+- linux,default-trigger: Trigger assigned to the LED.
+
+Example:
+
+ns2-leds {
+ compatible = "lacie,ns2-leds";
+
+ blue-sata {
+ label = "ns2:blue:sata";
+ slow-gpio = <&gpio0 29 0>;
+ cmd-gpio = <&gpio0 30 0>;
+ };
+};
diff --git a/drivers/leds/leds-ns2.c b/drivers/leds/leds-ns2.c
index d176ec8..d64cc22 100644
--- a/drivers/leds/leds-ns2.c
+++ b/drivers/leds/leds-ns2.c
@@ -30,6 +30,7 @@
#include <linux/leds.h>
#include <linux/module.h>
#include <linux/platform_data/leds-kirkwood-ns2.h>
+#include <linux/of_gpio.h>
/*
* The Network Space v2 dual-GPIO LED is wired to a CPLD and can blink in
@@ -263,6 +264,62 @@ static void delete_ns2_led(struct ns2_led_data *led_dat)
gpio_free(led_dat->slow);
}
+#ifdef CONFIG_OF_GPIO
+/*
+ * Translate OpenFirmware node properties into platform_data.
+ */
+static int __devinit
+ns2_leds_get_of_pdata(struct device *dev, struct ns2_led_platform_data *pdata)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *child;
+ struct ns2_led *leds;
+ int num_leds = 0;
+ int i = 0;
+
+ num_leds = of_get_child_count(np);
+ if (!num_leds)
+ return -ENODEV;
+
+ leds = devm_kzalloc(dev, num_leds * sizeof(struct ns2_led),
+ GFP_KERNEL);
+ if (!leds)
+ return -ENOMEM;
+
+ for_each_child_of_node(np, child) {
+ const char *string;
+ int ret;
+
+ ret = of_get_named_gpio(child, "cmd-gpio", 0);
+ if (ret < 0)
+ return ret;
+ leds[i].cmd = ret;
+ ret = of_get_named_gpio(child, "slow-gpio", 0);
+ if (ret < 0)
+ return ret;
+ leds[i].slow = ret;
+ ret = of_property_read_string(child, "label", &string);
+ leds[i].name = (ret == 0) ? string : child->name;
+ ret = of_property_read_string(child, "linux,default-trigger",
+ &string);
+ if (ret == 0)
+ leds[i].default_trigger = string;
+
+ i++;
+ }
+
+ pdata->leds = leds;
+ pdata->num_leds = num_leds;
+
+ return 0;
+}
+
+static const struct of_device_id of_ns2_leds_match[] = {
+ { .compatible = "lacie,ns2-leds", },
+ {},
+};
+#endif /* CONFIG_OF_GPIO */
+
static int __devinit ns2_led_probe(struct platform_device *pdev)
{
struct ns2_led_platform_data *pdata = pdev->dev.platform_data;
@@ -270,11 +327,25 @@ static int __devinit ns2_led_probe(struct platform_device *pdev)
int i;
int ret;
+#ifdef CONFIG_OF_GPIO
+ if (!pdata) {
+ pdata = devm_kzalloc(&pdev->dev,
+ sizeof(struct ns2_led_platform_data),
+ GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ ret = ns2_leds_get_of_pdata(&pdev->dev, pdata);
+ if (ret)
+ return ret;
+ }
+#else
if (!pdata)
return -EINVAL;
+#endif /* CONFIG_OF_GPIO */
leds_data = devm_kzalloc(&pdev->dev, sizeof(struct ns2_led_data) *
- pdata->num_leds, GFP_KERNEL);
+ pdata->num_leds, GFP_KERNEL);
if (!leds_data)
return -ENOMEM;
@@ -312,8 +383,9 @@ static struct platform_driver ns2_led_driver = {
.probe = ns2_led_probe,
.remove = __devexit_p(ns2_led_remove),
.driver = {
- .name = "leds-ns2",
- .owner = THIS_MODULE,
+ .name = "leds-ns2",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(of_ns2_leds_match),
},
};
--
1.7.10
^ permalink raw reply related
* [PATCH v2 0/4] Add DT support for Network Space v2 and parents
From: Simon Guinot @ 2012-10-17 10:09 UTC (permalink / raw)
To: linux-arm-kernel
This patch series provides DT support for LaCie NAS Network Space v2 and
parents. This includes the following machines:
- Internet Space v2
- Network Space v2
- Network Space Max v2
- Network Space Lite v2
- Network Space Mini v2
Note that the three first boards are already supported by the Linux
kernel via an "old-fashion" board setup. The two lasts (Lite and Mini)
are new boards.
Also note that the first patch of the series is related with the LED
subsystem. It adds device tree binding to the driver leds-ns2.
Changes for v2:
- Fix version for patch (update to v3):
"ARM: kirkwood: DT board setup for Network Space v2 and parents"
- Fix compatibility string for driver leds-ns2. Use "lacie,ns2-leds".
- leds-ns2: Remove useless #else #endif statement.
Simon Guinot (4):
leds: leds-ns2: add device tree binding
ARM: kirkwood: DT board setup for Network Space v2 and parents
ARM: kirkwood: DT board setup for Network Space Lite v2
ARM: kirkwood: DT board setup for Network Space Mini v2
.../devicetree/bindings/gpio/leds-ns2.txt | 26 ++++++
arch/arm/boot/dts/Makefile | 5 ++
arch/arm/boot/dts/kirkwood-is2.dts | 30 +++++++
arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 63 ++++++++++++++
arch/arm/boot/dts/kirkwood-ns2.dts | 30 +++++++
arch/arm/boot/dts/kirkwood-ns2lite.dts | 30 +++++++
arch/arm/boot/dts/kirkwood-ns2max.dts | 49 +++++++++++
arch/arm/boot/dts/kirkwood-ns2mini.dts | 49 +++++++++++
arch/arm/mach-kirkwood/Kconfig | 36 ++++++++
arch/arm/mach-kirkwood/Makefile | 5 ++
arch/arm/mach-kirkwood/board-dt.c | 12 +++
arch/arm/mach-kirkwood/board-ns2.c | 87 ++++++++++++++++++++
arch/arm/mach-kirkwood/common.h | 10 +++
drivers/leds/Kconfig | 4 +-
drivers/leds/leds-ns2.c | 78 +++++++++++++++++-
15 files changed, 510 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/leds-ns2.txt
create mode 100644 arch/arm/boot/dts/kirkwood-is2.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2-common.dtsi
create mode 100644 arch/arm/boot/dts/kirkwood-ns2.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2lite.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2max.dts
create mode 100644 arch/arm/boot/dts/kirkwood-ns2mini.dts
create mode 100644 arch/arm/mach-kirkwood/board-ns2.c
--
1.7.10
^ permalink raw reply
* [RFC PATCH v2] prevent top pte being overwritten before flushing
From: Will Deacon @ 2012-10-17 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGCDX1mKn8nJpJ=Sicq8yi1hfW-m0fA+Uyx=Oikhq43Z85muCw@mail.gmail.com>
On Wed, Oct 17, 2012 at 10:54:53AM +0100, Jason Lin wrote:
> 2012/10/17 Will Deacon <will.deacon@arm.com>:
> > On Wed, Oct 17, 2012 at 09:42:19AM +0100, Andrew Yan-Pai Chen wrote:
> >> On Mon, Oct 15, 2012 at 1:42 AM, Andrew Yan-Pai Chen
> >>
> >> Any ideas?
> >
> > I wonder if we could use different ptes for each CPU (by hacking
> > pte_offset_kernel) and then get away with just disabling preemption in both
> > cases?
> >
> > Will
>
> Single core processor will also cause this issue in flush_pfn_alias().
> So it should use different ptes for each task.
> Will it be so complicated?
You can just disable preemption in that case -- it's the spin_lock that I'd
like to avoid.
Will
^ permalink raw reply
* [GIT PULL] Versatile Express updates for v3.8
From: Pawel Moll @ 2012-10-17 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016183451.GA2799@quad.lixom.net>
On Tue, 2012-10-16 at 19:34 +0100, Olof Johansson wrote:
> Hi Pawel,
> The branch contents looks good, but I wonder if you would mind splitting it up
> across the same kind of topics that we tend to organize arm-soc in?
Sure, no problem.
> Suggestions below.
I can make those two a "drivers" branch indeed:
> > Pawel Moll (8):
> > hwmon: Versatile Express hwmon driver
> > ARM: vexpress: Reset driver
I can also split this one into "fixes":
> ARM: vexpress: Make the debug UART detection more specific
But this series constitutes one logical change and must be applied in
order (the sysreg driver is an essential part), so I'll keep them
together on a "soc" branch:
> > mfd: Versatile Express config infrastructure
> > mfd: Versatile Express system registers driver
> > ARM: vexpress: Add config bus components and clocks to DTs
> > ARM: vexpress: Start using new Versatile Express infrastructure
> > ARM: vexpress: Remove motherboard dependencies in the DTS files
If this makes sense, I'll send three pull requests soon.
Cheers!
Pawe?
^ permalink raw reply
* [RFC PATCH v2] prevent top pte being overwritten before flushing
From: Jason Lin @ 2012-10-17 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017093916.GA5973@mudshark.cambridge.arm.com>
2012/10/17 Will Deacon <will.deacon@arm.com>:
> On Wed, Oct 17, 2012 at 09:42:19AM +0100, Andrew Yan-Pai Chen wrote:
>> On Mon, Oct 15, 2012 at 1:42 AM, Andrew Yan-Pai Chen
>> <yanpai.chen@gmail.com> wrote:
>> > +static DEFINE_RAW_SPINLOCK(flush_lock);
>> > +
>> > +/* Beware that this function is not to be called for SMP setups. */
>> > static void flush_pfn_alias(unsigned long pfn, unsigned long vaddr)
>> > {
>> > unsigned long to = FLUSH_ALIAS_START + (CACHE_COLOUR(vaddr) <<
>> > PAGE_SHIFT);
>> > const int zero = 0;
>> >
>> > + preempt_disable();
>> > set_top_pte(to, pfn_pte(pfn, PAGE_KERNEL));
>> >
>> > asm( "mcrr p15, 0, %1, %0, c14\n"
>> > @@ -34,6 +39,8 @@ static void flush_pfn_alias(unsigned long pfn, unsigned
>> > long vaddr)
>> > :
>> > : "r" (to), "r" (to + PAGE_SIZE - L1_CACHE_BYTES), "r" (zero)
>> > : "cc");
>> > +
>> > + preempt_enable();
>> > }
>> >
>> > static void flush_icache_alias(unsigned long pfn, unsigned long vaddr,
>> > unsigned long len)
>> > @@ -42,9 +49,13 @@ static void flush_icache_alias(unsigned long pfn,
>> > unsigned long vaddr, unsigned
>> > unsigned long offset = vaddr & (PAGE_SIZE - 1);
>> > unsigned long to;
>> >
>> > + raw_spin_lock(&flush_lock);
>> > +
>> > set_top_pte(va, pfn_pte(pfn, PAGE_KERNEL));
>> > to = va + offset;
>> > flush_icache_range(to, to + len);
>> > +
>> > + raw_spin_unlock(&flush_lock);
>> > }
>> >
>> > void flush_cache_mm(struct mm_struct *mm)
>> > --
>> > 1.7.4.1
>> >
>>
>> Hi all,
>>
>> Any ideas?
>
> I wonder if we could use different ptes for each CPU (by hacking
> pte_offset_kernel) and then get away with just disabling preemption in both
> cases?
>
> Will
Single core processor will also cause this issue in flush_pfn_alias().
So it should use different ptes for each task.
Will it be so complicated?
Jason
^ permalink raw reply
* [PATCH 0/8] Cragganmore updates
From: Kukjin Kim @ 2012-10-17 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017073813.GI14199@opensource.wolfsonmicro.com>
Mark Brown wrote:
>
> The following changes since commit
> ddffeb8c4d0331609ef2581d84de4d763607bd37:
>
> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git
> tags/crag6410
>
> for you to fetch changes up to c8a825563eae03e657b191c2b4948f7613ae91b6:
>
> ARM: S3C64XX: Add handset module to probed Glenfarclas modules (2012-10-
> 16 14:09:01 +0900)
>
> ----------------------------------------------------------------
> ARM: S3C64XX: Cragganmore updates
>
> There's a bunch of things in here (some have been posted before I
> believe), the main thing is the update to support muliple board
> revisions but there's also some new modules added.
>
> ----------------------------------------------------------------
> Mark Brown (8):
> ARM: S3C64XX: Add more Glenfarclas module ID strings
> ARM: S3C64XX: Update hookup for Arizona class devices
> ARM: S3C64XX: Provide platform data for Tomatin/Balblair on
> Cragganmore
> ARM: S3C64XX: Handle revision-specific differences in Cragganmore
> modules
> ARM: S3C64XX: Handle new Amrut modules on Cragganmore
> ARM: S3C64XX: Add hookup for Deanston module on Cragganmore
> ARM: S3C64XX: Add WM2200 module for Cragganmore
> ARM: S3C64XX: Add handset module to probed Glenfarclas modules
>
> arch/arm/mach-s3c64xx/mach-crag6410-module.c | 141
> +++++++++++++++++++++-----
> arch/arm/mach-s3c64xx/mach-crag6410.c | 29 +++++-
> 2 files changed, 144 insertions(+), 26 deletions(-)
Looks OK to me, applied this whole series.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [RFC PATCH v2] prevent top pte being overwritten before flushing
From: Will Deacon @ 2012-10-17 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANj_sbCbdfvgkKXJjk4L_5Rk-4mQ-zqDqMErry-AzHddDb8WYA@mail.gmail.com>
On Wed, Oct 17, 2012 at 09:42:19AM +0100, Andrew Yan-Pai Chen wrote:
> On Mon, Oct 15, 2012 at 1:42 AM, Andrew Yan-Pai Chen
> <yanpai.chen@gmail.com> wrote:
> > +static DEFINE_RAW_SPINLOCK(flush_lock);
> > +
> > +/* Beware that this function is not to be called for SMP setups. */
> > static void flush_pfn_alias(unsigned long pfn, unsigned long vaddr)
> > {
> > unsigned long to = FLUSH_ALIAS_START + (CACHE_COLOUR(vaddr) <<
> > PAGE_SHIFT);
> > const int zero = 0;
> >
> > + preempt_disable();
> > set_top_pte(to, pfn_pte(pfn, PAGE_KERNEL));
> >
> > asm( "mcrr p15, 0, %1, %0, c14\n"
> > @@ -34,6 +39,8 @@ static void flush_pfn_alias(unsigned long pfn, unsigned
> > long vaddr)
> > :
> > : "r" (to), "r" (to + PAGE_SIZE - L1_CACHE_BYTES), "r" (zero)
> > : "cc");
> > +
> > + preempt_enable();
> > }
> >
> > static void flush_icache_alias(unsigned long pfn, unsigned long vaddr,
> > unsigned long len)
> > @@ -42,9 +49,13 @@ static void flush_icache_alias(unsigned long pfn,
> > unsigned long vaddr, unsigned
> > unsigned long offset = vaddr & (PAGE_SIZE - 1);
> > unsigned long to;
> >
> > + raw_spin_lock(&flush_lock);
> > +
> > set_top_pte(va, pfn_pte(pfn, PAGE_KERNEL));
> > to = va + offset;
> > flush_icache_range(to, to + len);
> > +
> > + raw_spin_unlock(&flush_lock);
> > }
> >
> > void flush_cache_mm(struct mm_struct *mm)
> > --
> > 1.7.4.1
> >
>
> Hi all,
>
> Any ideas?
I wonder if we could use different ptes for each CPU (by hacking
pte_offset_kernel) and then get away with just disabling preemption in both
cases?
Will
^ permalink raw reply
* [RFC PATCH v2] prevent top pte being overwritten before flushing
From: Andrew Yan-Pai Chen @ 2012-10-17 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350236542-96465-1-git-send-email-yanpai.chen@gmail.com>
On Mon, Oct 15, 2012 at 1:42 AM, Andrew Yan-Pai Chen
<yanpai.chen@gmail.com> wrote:
> From: Yan-Pai Chen <ypchen@faraday-tech.com>
>
> Since flush_pfn_alias() is preemptible, it is possible to be
> preempted just after set_top_pte() is done. If the process
> which preempts the previous happened to invoke flush_pfn_alias()
> with the same colour vaddr as that of the previous, the same
> top pte will be overwritten. When switching back to the previous,
> it attempts to flush cache lines with incorrect mapping. Then
> no lines (or wrong lines) will be flushed because of the nature
> of vipt caches.
>
> flush_icache_alias() has the same problem as well. However, as it
> could be called in SMP setups, we prevent concurrent overwrites of
> top pte by having a lock on it.
>
> Signed-off-by: JasonLin <wwlin@faraday-tech.com>
> Signed-off-by: Yan-Pai Chen <ypchen@faraday-tech.com>
> ---
> arch/arm/mm/flush.c | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
> index 40ca11e..b6510f4 100644
> --- a/arch/arm/mm/flush.c
> +++ b/arch/arm/mm/flush.c
> @@ -11,6 +11,7 @@
> #include <linux/mm.h>
> #include <linux/pagemap.h>
> #include <linux/highmem.h>
> +#include <linux/spinlock.h>
>
> #include <asm/cacheflush.h>
> #include <asm/cachetype.h>
> @@ -22,11 +23,15 @@
>
> #ifdef CONFIG_CPU_CACHE_VIPT
>
> +static DEFINE_RAW_SPINLOCK(flush_lock);
> +
> +/* Beware that this function is not to be called for SMP setups. */
> static void flush_pfn_alias(unsigned long pfn, unsigned long vaddr)
> {
> unsigned long to = FLUSH_ALIAS_START + (CACHE_COLOUR(vaddr) <<
> PAGE_SHIFT);
> const int zero = 0;
>
> + preempt_disable();
> set_top_pte(to, pfn_pte(pfn, PAGE_KERNEL));
>
> asm( "mcrr p15, 0, %1, %0, c14\n"
> @@ -34,6 +39,8 @@ static void flush_pfn_alias(unsigned long pfn, unsigned
> long vaddr)
> :
> : "r" (to), "r" (to + PAGE_SIZE - L1_CACHE_BYTES), "r" (zero)
> : "cc");
> +
> + preempt_enable();
> }
>
> static void flush_icache_alias(unsigned long pfn, unsigned long vaddr,
> unsigned long len)
> @@ -42,9 +49,13 @@ static void flush_icache_alias(unsigned long pfn,
> unsigned long vaddr, unsigned
> unsigned long offset = vaddr & (PAGE_SIZE - 1);
> unsigned long to;
>
> + raw_spin_lock(&flush_lock);
> +
> set_top_pte(va, pfn_pte(pfn, PAGE_KERNEL));
> to = va + offset;
> flush_icache_range(to, to + len);
> +
> + raw_spin_unlock(&flush_lock);
> }
>
> void flush_cache_mm(struct mm_struct *mm)
> --
> 1.7.4.1
>
Hi all,
Any ideas?
^ permalink raw reply
* [PATCH RFC 02/11 v4] gpio: Add sysfs support to block GPIO API
From: Roland Stigge @ 2012-10-17 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016164326.GA4858@kroah.com>
On 10/16/2012 06:43 PM, Greg KH wrote:
> On Tue, Oct 16, 2012 at 02:53:45PM +0200, Roland Stigge wrote:
>> On 10/16/2012 01:57 AM, Greg KH wrote:
>>> On Tue, Oct 16, 2012 at 01:31:18AM +0200, Roland Stigge wrote:
>>>> +int gpio_block_export(struct gpio_block *block)
>>>> +{
>>>> + int status;
>>>> + struct device *dev;
>>>> +
>>>> + /* can't export until sysfs is available ... */
>>>> + if (!gpio_class.p) {
>>>> + pr_debug("%s: called too early!\n", __func__);
>>>> + return -ENOENT;
>>>> + }
>>>> +
>>>> + mutex_lock(&sysfs_lock);
>>>> + dev = device_create(&gpio_class, NULL, MKDEV(0, 0), block,
>>>> + block->name);
>>>> + if (!IS_ERR(dev))
>>>> + status = sysfs_create_group(&dev->kobj, &gpio_block_attr_group);
>>>> + else
>>>> + status = PTR_ERR(dev);
>>>> + mutex_unlock(&sysfs_lock);
>>>
>>> You just raced with userspace telling it that the device was present,
>>> yet the attributes are not there. Don't do that, use the default class
>>> attributes for the class and then the driver core will create them
>>> automagically without needing to this "by hand" at all.
>>
>> I guess you mean class attributes like gpio_class_attrs[] of gpio_class?
>
> Yes.
>
>> Aren't class attributes specific to a class only (i.e. only one
>> attribute at the root for all devices)? What I needed above are
>> attributes for the block itself (of which there can be several). So we
>> need device attributes for each block, not class attributes here.
>
> Yes, that is what the dev_attrs field in 'struct class' is for.
That's what I was missing. Will update.
Thanks,
Roland
^ permalink raw reply
* [PATCH] i2c: at91: add dma support
From: Russell King - ARM Linux @ 2012-10-17 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349876587-31182-1-git-send-email-ludovic.desroches@atmel.com>
On Wed, Oct 10, 2012 at 03:43:07PM +0200, ludovic.desroches at atmel.com wrote:
> + txdesc = chan_tx->device->device_prep_slave_sg(chan_tx, &dma->sg,
> + 1, DMA_TO_DEVICE, DMA_PREP_INTERRUPT | DMA_CTRL_ACK, NULL);
No, a while back the DMA engine API changed. It no longer takes
DMA_TO_DEVICE/DMA_FROM_DEVICE but DMA_MEM_TO_DEV and DMA_DEV_TO_MEM.
> + /* Keep in mind that we won't use dma to read the last two bytes */
> + at91_twi_irq_save(dev);
> + dma_addr = dma_map_single(dev->dev, dev->buf, dev->buf_len - 2,
> + DMA_FROM_DEVICE);
Ditto.
> + dma->xfer_in_progress = true;
> + cookie = rxdesc->tx_submit(rxdesc);
> + if (dma_submit_error(cookie)) {
tx_submit never errors (anymore.)
> + slave_config.direction = DMA_TO_DEVICE;
Same comment as for the other directions. Note that DMA engine drivers
really should ignore this parameter now, and DMA engine users should phase
it out.
> + if (dmaengine_slave_config(dma->chan_tx, &slave_config)) {
> + dev_err(dev->dev, "failed to configure tx channel\n");
> + ret = -EINVAL;
> + goto error;
> + }
> +
> + slave_config.direction = DMA_FROM_DEVICE;
Ditto.
^ 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