Re: PRAMFS with XIP support
Hi Mike, I am not the PRAMFS mantainer, and I think he is in charge to do that (right?), I sent an email to Steve Longerbeam and to MontaVista support, but I haven't received any response. However, if you think it could be useful to submit it to lkml I could do it. Regards. Mike Frysinger ha scritto: On Tue, Oct 7, 2008 at 05:14, Marco Stornelli wrote: I enjoyed to make a porting of pramfs to the kernel 2.6.26.5. In addition, I made a patch to add execute-in-place support. You can download the patches from the project site under tracker/patches. If you have comments and/or suggestions you can write to me an email :). why not submit it for inclusion to lkml ? -mike -- Marco Stornelli Embedded Software Engineer CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni http://www.coritel.it [EMAIL PROTECTED] +39 06 72582838 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/6] [PWM] Changes to existing include/linux/pwm.h to adapt to generic PWM API
Signed-off-by: Bill Gatliff [EMAIL PROTECTED]
---
include/linux/pwm.h | 168 --
1 files changed, 147 insertions(+), 21 deletions(-)
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 3945f80..d3d18f7 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -1,31 +1,157 @@
#ifndef __LINUX_PWM_H
#define __LINUX_PWM_H
-struct pwm_device;
-
/*
- * pwm_request - request a PWM device
+ * include/linux/pwm.h
+ *
+ * Copyright (C) 2008 Bill Gatliff
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-struct pwm_device *pwm_request(int pwm_id, const char *label);
-/*
- * pwm_free - free a PWM device
- */
-void pwm_free(struct pwm_device *pwm);
+enum {
+ PWM_CONFIG_DUTY_TICKS = BIT(0),
+ PWM_CONFIG_PERIOD_TICKS = BIT(1),
+ PWM_CONFIG_POLARITY = BIT(2),
+ PWM_CONFIG_START = BIT(3),
+ PWM_CONFIG_STOP = BIT(4),
-/*
- * pwm_config - change a PWM device configuration
- */
-int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
+ PWM_CONFIG_HANDLER = BIT(5),
-/*
- * pwm_enable - start a PWM output toggling
- */
-int pwm_enable(struct pwm_device *pwm);
+ PWM_CONFIG_DUTY_NS = BIT(6),
+ PWM_CONFIG_DUTY_PERCENT = BIT(7),
+ PWM_CONFIG_PERIOD_NS = BIT(8),
+};
+
+struct pwm_channel;
+struct work_struct;
+
+typedef int (*pwm_handler_t)(struct pwm_channel *p, void *data);
+typedef void (*pwm_callback_t)(struct pwm_channel *p);
+
+struct pwm_channel_config {
+ int config_mask;
+ unsigned long duty_ticks;
+ unsigned long period_ticks;
+ int polarity;
+
+ pwm_handler_t handler;
+
+ unsigned long duty_ns;
+ unsigned long period_ns;
+ int duty_percent;
+};
+
+struct pwm_device {
+ struct list_head list;
+ spinlock_t list_lock;
+ struct device *dev;
+ struct module *owner;
+ struct pwm_channel *channels;
+
+ const char *bus_id;
+ int nchan;
+
+ int (*request) (struct pwm_channel *p);
+ void(*free) (struct pwm_channel *p);
+ int (*config) (struct pwm_channel *p,
+struct pwm_channel_config *c);
+ int (*config_nosleep)(struct pwm_channel *p,
+ struct pwm_channel_config *c);
+ int (*synchronize) (struct pwm_channel *p,
+struct pwm_channel *to_p);
+ int (*unsynchronize)(struct pwm_channel *p,
+struct pwm_channel *from_p);
+ int (*set_callback) (struct pwm_channel *p,
+pwm_callback_t callback);
+};
+
+int pwm_register(struct pwm_device *pwm);
+int pwm_unregister(struct pwm_device *pwm);
+
+enum {
+ FLAG_REQUESTED = 0,
+ FLAG_STOP = 1,
+};
+
+struct pwm_channel {
+ struct list_head list;
+ struct pwm_device *pwm;
+ const char *requester;
+ int chan;
+ unsigned long flags;
+ unsigned long tick_hz;
+
+ spinlock_t lock;
+ struct completion complete;
+
+ pwm_callback_t callback;
+
+ struct work_struct handler_work;
+ pwm_handler_t handler;
+ void *handler_data;
+
+ int active_low;
+ unsigned long period_ticks;
+ unsigned long duty_ticks;
+};
+
+struct pwm_channel *
+pwm_request(const char *bus_id, int chan,
+ const char *requester);
+
+void pwm_free(struct pwm_channel *pwm);
+
+int pwm_config_nosleep(struct pwm_channel *pwm,
+ struct pwm_channel_config *c);
+
+int pwm_config(struct pwm_channel *pwm,
+ struct pwm_channel_config *c);
+
+unsigned long pwm_ns_to_ticks(struct pwm_channel *pwm,
+ unsigned long nsecs);
+
+unsigned long pwm_ticks_to_ns(struct pwm_channel *pwm,
+ unsigned long ticks);
+
+int pwm_period_ns(struct pwm_channel *pwm,
+ unsigned long period_ns);
+
+int pwm_duty_ns(struct pwm_channel *pwm,
+ unsigned long duty_ns);
+
+int pwm_duty_percent(struct pwm_channel *pwm,
+int percent);
+
+int pwm_polarity(struct pwm_channel *pwm,
+int active_high);
+
+int pwm_start(struct pwm_channel *pwm);
+
+int pwm_stop(struct pwm_channel
[RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one
Signed-off-by: Bill Gatliff [EMAIL PROTECTED]
---
arch/arm/Kconfig |2 +
drivers/Makefile |2 +
drivers/misc/Kconfig |9 -
drivers/misc/Makefile|1 -
drivers/misc/atmel_pwm.c | 409 --
drivers/pwm/Kconfig | 24 +++
drivers/pwm/Makefile |6 +
7 files changed, 34 insertions(+), 419 deletions(-)
delete mode 100644 drivers/misc/atmel_pwm.c
create mode 100644 drivers/pwm/Kconfig
create mode 100644 drivers/pwm/Makefile
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 70dba16..fed3eef 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1196,6 +1196,8 @@ source drivers/spi/Kconfig
source drivers/gpio/Kconfig
+source drivers/pwm/Kconfig
+
source drivers/w1/Kconfig
source drivers/power/Kconfig
diff --git a/drivers/Makefile b/drivers/Makefile
index 2735bde..f242fc6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -6,6 +6,8 @@
#
obj-y += gpio/
+obj-$(CONFIG_GENERIC_PWM) += pwm/
+
obj-$(CONFIG_PCI) += pci/
obj-$(CONFIG_PARISC) += parisc/
obj-$(CONFIG_RAPIDIO) += rapidio/
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a726f3b..cdea0bb 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -13,15 +13,6 @@ menuconfig MISC_DEVICES
if MISC_DEVICES
-config ATMEL_PWM
- tristate Atmel AT32/AT91 PWM support
- depends on AVR32 || ARCH_AT91
- help
- This option enables device driver support for the PWM channels
- on certain Atmel prcoessors. Pulse Width Modulation is used for
- purposes including software controlled power-efficent backlights
- on LCD displays, motor control, and waveform generation.
-
config ATMEL_TCLIB
bool Atmel AT32/AT91 Timer/Counter Library
depends on (AVR32 || ARCH_AT91)
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index c6c13f6..9e67012 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_EEEPC_LAPTOP)+= eeepc-laptop.o
obj-$(CONFIG_MSI_LAPTOP) += msi-laptop.o
obj-$(CONFIG_COMPAL_LAPTOP)+= compal-laptop.o
obj-$(CONFIG_ACER_WMI) += acer-wmi.o
-obj-$(CONFIG_ATMEL_PWM)+= atmel_pwm.o
obj-$(CONFIG_ATMEL_SSC)+= atmel-ssc.o
obj-$(CONFIG_ATMEL_TCLIB) += atmel_tclib.o
obj-$(CONFIG_HP_WMI) += hp-wmi.o
diff --git a/drivers/misc/atmel_pwm.c b/drivers/misc/atmel_pwm.c
deleted file mode 100644
index 6aa5294..000
--- a/drivers/misc/atmel_pwm.c
+++ /dev/null
@@ -1,409 +0,0 @@
-#include linux/module.h
-#include linux/clk.h
-#include linux/err.h
-#include linux/io.h
-#include linux/interrupt.h
-#include linux/platform_device.h
-#include linux/atmel_pwm.h
-
-
-/*
- * This is a simple driver for the PWM controller found in various newer
- * Atmel SOCs, including the AVR32 series and the AT91sam9263.
- *
- * Chips with current Linux ports have only 4 PWM channels, out of max 32.
- * AT32UC3A and AT32UC3B chips have 7 channels (but currently no Linux).
- * Docs are inconsistent about the width of the channel counter registers;
- * it's at least 16 bits, but several places say 20 bits.
- */
-#definePWM_NCHAN 4 /* max 32 */
-
-struct pwm {
- spinlock_t lock;
- struct platform_device *pdev;
- u32 mask;
- int irq;
- void __iomem*base;
- struct clk *clk;
- struct pwm_channel *channel[PWM_NCHAN];
- void(*handler[PWM_NCHAN])(struct pwm_channel *);
-};
-
-
-/* global PWM controller registers */
-#define PWM_MR 0x00
-#define PWM_ENA0x04
-#define PWM_DIS0x08
-#define PWM_SR 0x0c
-#define PWM_IER0x10
-#define PWM_IDR0x14
-#define PWM_IMR0x18
-#define PWM_ISR0x1c
-
-static inline void pwm_writel(const struct pwm *p, unsigned offset, u32 val)
-{
- __raw_writel(val, p-base + offset);
-}
-
-static inline u32 pwm_readl(const struct pwm *p, unsigned offset)
-{
- return __raw_readl(p-base + offset);
-}
-
-static inline void __iomem *pwmc_regs(const struct pwm *p, int index)
-{
- return p-base + 0x200 + index * 0x20;
-}
-
-static struct pwm *pwm;
-
-static void pwm_dumpregs(struct pwm_channel *ch, char *tag)
-{
- struct device *dev = pwm-pdev-dev;
-
- dev_dbg(dev, %s: mr %08x, sr %08x, imr %08x\n,
- tag,
- pwm_readl(pwm, PWM_MR),
- pwm_readl(pwm, PWM_SR),
- pwm_readl(pwm, PWM_IMR));
- dev_dbg(dev,
- pwm ch%d - mr %08x, dty %u, prd %u, cnt %u\n,
- ch-index,
- pwm_channel_readl(ch, PWM_CMR),
- pwm_channel_readl(ch, PWM_CDTY),
- pwm_channel_readl(ch, PWM_CPRD),
-
[RFC 1/6] [PWM] Generic PWM API implementation
Signed-off-by: Bill Gatliff [EMAIL PROTECTED]
---
drivers/pwm/pwm.c | 667 +
1 files changed, 667 insertions(+), 0 deletions(-)
create mode 100644 drivers/pwm/pwm.c
diff --git a/drivers/pwm/pwm.c b/drivers/pwm/pwm.c
new file mode 100644
index 000..2f28c20
--- /dev/null
+++ b/drivers/pwm/pwm.c
@@ -0,0 +1,667 @@
+/*
+ * drivers/pwm/pwm.c
+ *
+ * Copyright (C) 2008 Bill Gatliff
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+#include linux/spinlock.h
+#include linux/fs.h
+#include linux/completion.h
+#include linux/workqueue.h
+#include linux/pwm.h
+
+
+static int __pwm_create_sysfs(struct pwm_device *pwm);
+
+static LIST_HEAD(pwm_device_list);
+static DEFINE_MUTEX(device_list_mutex);
+static struct class pwm_class;
+static struct workqueue_struct *pwm_handler_workqueue;
+
+
+int pwm_register(struct pwm_device *pwm)
+{
+ struct pwm_channel *p;
+ int wchan;
+ int ret = 0;
+
+ spin_lock_init(pwm-list_lock);
+
+ p = kcalloc(pwm-nchan, sizeof(struct pwm_channel), GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ for (wchan = 0; wchan pwm-nchan; wchan++) {
+ spin_lock_init(p[wchan].lock);
+ init_completion(p[wchan].complete);
+ p[wchan].chan = wchan;
+ p[wchan].pwm = pwm;
+ }
+
+ pwm-channels = p;
+
+ mutex_lock(device_list_mutex);
+
+ list_add_tail(pwm-list, pwm_device_list);
+ ret = __pwm_create_sysfs(pwm);
+ if (ret) {
+ mutex_unlock(device_list_mutex);
+ goto err_create_sysfs;
+ }
+
+ mutex_unlock(device_list_mutex);
+
+ pr_info(%s: %d channels\n, pwm-bus_id, pwm-nchan);
+ return 0;
+
+err_create_sysfs:
+ kfree(p);
+
+ return ret;
+}
+EXPORT_SYMBOL(pwm_register);
+
+
+static int __match_device(struct device *dev, void *data)
+{
+ return dev_get_drvdata(dev) == data;
+}
+
+
+int pwm_unregister(struct pwm_device *pwm)
+{
+ int wchan;
+ struct device *dev;
+
+ mutex_lock(device_list_mutex);
+
+ for (wchan = 0; wchan pwm-nchan; wchan++) {
+ if (pwm-channels[wchan].flags FLAG_REQUESTED) {
+ mutex_unlock(device_list_mutex);
+ return -EBUSY;
+ }
+ }
+
+ for (wchan = 0; wchan pwm-nchan; wchan++) {
+ dev = class_find_device(pwm_class, NULL,
+ pwm-channels[wchan],
+ __match_device);
+ if (dev) {
+ put_device(dev);
+ device_unregister(dev);
+ }
+ }
+
+ kfree(pwm-channels);
+ list_del(pwm-list);
+ mutex_unlock(device_list_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL(pwm_unregister);
+
+
+static struct pwm_device *
+__pwm_find_device(const char *bus_id)
+{
+ struct pwm_device *p;
+
+ list_for_each_entry(p, pwm_device_list, list)
+ {
+ if (!strcmp(bus_id, p-bus_id))
+ return p;
+ }
+ return NULL;
+}
+
+
+static int
+__pwm_request_channel(struct pwm_channel *p,
+ const char *requester)
+{
+ int ret;
+
+ if (test_and_set_bit(FLAG_REQUESTED, p-flags))
+ return -EBUSY;
+
+ if (p-pwm-request) {
+ ret = p-pwm-request(p);
+ if (ret) {
+ clear_bit(FLAG_REQUESTED, p-flags);
+ return ret;
+ }
+ }
+
+ p-requester = requester;
+ return 0;
+}
+
+
+struct pwm_channel *
+pwm_request(const char *bus_id,
+ int chan,
+ const char *requester)
+{
+ struct pwm_device *p;
+ int ret;
+
+ mutex_lock(device_list_mutex);
+
+ p = __pwm_find_device(bus_id);
+ if (!p || chan = p-nchan)
+ goto err_no_device;
+
+ if (!try_module_get(p-owner))
+ goto err_module_get_failed;
+
+ ret = __pwm_request_channel(p-channels[chan], requester);
+ if (ret)
+ goto err_request_failed;
+
+
[RFC 4/6] [PWM] Driver for Atmel PWMC peripheral
Signed-off-by: Bill Gatliff [EMAIL PROTECTED]
---
drivers/pwm/atmel-pwm.c | 631 +++
1 files changed, 631 insertions(+), 0 deletions(-)
create mode 100644 drivers/pwm/atmel-pwm.c
diff --git a/drivers/pwm/atmel-pwm.c b/drivers/pwm/atmel-pwm.c
new file mode 100644
index 000..b65e84f
--- /dev/null
+++ b/drivers/pwm/atmel-pwm.c
@@ -0,0 +1,631 @@
+/*
+ * drivers/pwm/atmel-pwm.c
+ *
+ * Copyright (C) 2008 Bill Gatliff
+ * Copyright (C) 2007 David Brownell
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/pwm.h
+
+
+enum {
+ /* registers common to the PWMC peripheral */
+ PWMC_MR = 0,
+ PWMC_ENA = 4,
+ PWMC_DIS = 8,
+ PWMC_SR = 0xc,
+ PWMC_IER = 0x10,
+ PWMC_IDR = 0x14,
+ PWMC_IMR = 0x18,
+ PWMC_ISR = 0x1c,
+
+ /* registers per each PWMC channel */
+ PWMC_CMR = 0,
+ PWMC_CDTY = 4,
+ PWMC_CPRD = 8,
+ PWMC_CCNT = 0xc,
+ PWMC_CUPD = 0x10,
+
+ /* how to find each channel */
+ PWMC_CHAN_BASE = 0x200,
+ PWMC_CHAN_STRIDE = 0x20,
+
+ /* CMR bits of interest */
+ PWMC_CMR_CPD = 10,
+ PWMC_CMR_CPOL = 9,
+ PWMC_CMR_CALG = 8,
+ PWMC_CMR_CPRE_MASK = 0xf,
+};
+
+struct atmel_pwm {
+ struct pwm_device pwm;
+ spinlock_t lock;
+ void __iomem *iobase;
+ struct clk *clk;
+ u32 *sync_mask;
+ int irq;
+ u32 ccnt_mask;
+};
+
+
+static inline void
+pwmc_writel(const struct atmel_pwm *p,
+ unsigned offset, u32 val)
+{
+ __raw_writel(val, p-iobase + offset);
+}
+
+
+static inline u32
+pwmc_readl(const struct atmel_pwm *p,
+ unsigned offset)
+{
+ return __raw_readl(p-iobase + offset);
+}
+
+
+static inline void
+pwmc_chan_writel(const struct pwm_channel *p,
+u32 offset, u32 val)
+{
+ const struct atmel_pwm *ap
+ = container_of(p-pwm, struct atmel_pwm, pwm);
+
+ if (PWMC_CMR == offset)
+ val = ((1 PWMC_CMR_CPD)
+ | (1 PWMC_CMR_CPOL)
+ | (1 PWMC_CMR_CALG)
+ | (PWMC_CMR_CPRE_MASK));
+ else
+ val = ap-ccnt_mask;
+
+ pwmc_writel(ap, offset + PWMC_CHAN_BASE
+ + (p-chan * PWMC_CHAN_STRIDE), val);
+}
+
+
+static inline u32
+pwmc_chan_readl(const struct pwm_channel *p,
+ u32 offset)
+{
+ const struct atmel_pwm *ap
+ = container_of(p-pwm, struct atmel_pwm, pwm);
+
+ return pwmc_readl(ap, offset + PWMC_CHAN_BASE
+ + (p-chan * PWMC_CHAN_STRIDE));
+}
+
+
+static inline int
+__atmel_pwm_is_on(struct pwm_channel *p)
+{
+ struct atmel_pwm *ap = container_of(p-pwm, struct atmel_pwm, pwm);
+ return (pwmc_readl(ap, PWMC_SR) (1 p-chan)) ? 1 : 0;
+}
+
+
+static inline void
+__atmel_pwm_unsynchronize(struct pwm_channel *p,
+ struct pwm_channel *to_p)
+{
+ const struct atmel_pwm *ap
+ = container_of(p-pwm, struct atmel_pwm, pwm);
+ int wchan;
+
+ if (to_p) {
+ ap-sync_mask[p-chan] = ~(1 to_p-chan);
+ ap-sync_mask[to_p-chan] = ~(1 p-chan);
+ goto done;
+ }
+
+ ap-sync_mask[p-chan] = 0;
+ for (wchan = 0; wchan ap-pwm.nchan; wchan++)
+ ap-sync_mask[wchan] = ~(1 p-chan);
+done:
+ pr_debug(%s:%d sync_mask %x\n,
+p-pwm-bus_id, p-chan, ap-sync_mask[p-chan]);
+}
+
+
+static inline void
+__atmel_pwm_synchronize(struct pwm_channel *p,
+ struct pwm_channel *to_p)
+{
+ const struct atmel_pwm *ap
+ = container_of(p-pwm, struct atmel_pwm, pwm);
+
+ if (!to_p)
+ return;
+
+ ap-sync_mask[p-chan] |= (1 to_p-chan);
+ ap-sync_mask[to_p-chan] |= (1 p-chan);
+
+ pr_debug(%s:%d sync_mask %x\n,
+p-pwm-bus_id, p-chan, ap-sync_mask[p-chan]);
+}
+
+
+static inline void
+__atmel_pwm_stop(struct pwm_channel *p)
+{
+ struct atmel_pwm *ap = container_of(p-pwm, struct
Re: PRAMFS with XIP support
Marco Stornelli wrote: Hi Mike, I am not the PRAMFS mantainer, and I think he is in charge to do that (right?), I sent an email to Steve Longerbeam and to MontaVista support, but I haven't received any response. However, if you think it could be useful to submit it to lkml I could do it. If you don't hear anything within 2 weeks, just submit it. I've worked with PRAMFS in the past, and I think it's not a high enough profile project at MontaVista that they'd be upset if it got mainlined by someone besides Steve. IRRC, Steve Johnson of Panasonic tried to mainline it a few years ago, and no one from MV complained. -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PRAMFS with XIP support
On Wed, 2008-10-08 at 11:25 -0700, Tim Bird wrote: Marco Stornelli wrote: Hi Mike, I am not the PRAMFS mantainer, and I think he is in charge to do that (right?), I sent an email to Steve Longerbeam and to MontaVista support, but I haven't received any response. However, if you think it could be useful to submit it to lkml I could do it. If you don't hear anything within 2 weeks, just submit it. I've worked with PRAMFS in the past, and I think it's not a high enough profile project at MontaVista that they'd be upset if it got mainlined by someone besides Steve. IRRC, Steve Johnson of Panasonic tried to mainline it a few years ago, and no one from MV complained. /me looks up .. I'm not familiar with PRAMFS , but I'm sure any contribution or support is welcome.. I'd be happy to help if anyone wants it. Daniel -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC - size tool for kernel build system
Tim Bird wrote: I've been thinking about a tool that might be useful to track kernel size changes. I'm posting this Request For Comments to get feedback, and determine if this is something that would be worthwhile to pursue. What I envision is some new kernel build targets, specifically related to gathering size information and generating a size comparison report. Some small helper scripts would be written to gather the necessary information, and generate the report. A kernel developer would type: 1) make size-baseline And kernel size information would be recorded for the current kernel (after a build, if needed). I envision this saving off the .config and System.map, the result of 'size vmlinux' and several of the 'size */builtin.o' results. Additionally (and optionally), a program could be run to acquire some size information from a running system (e.g. a newly booted system, or a system under a particular load), to include in the baseline report. All of the gathered information would be stored as the size baseline. --- After making some modifications, either to the source or the configuration, the developer could type: 2) make size-report The kernel size information would be recorded again, and compared with the size-baseline results. A report of differences (e.g. from bloat-o-meter and other comparison tools) would be produced. Any differences exceeding some threshhold (specified in a size-watch config file?) could be highlighted. The git commit IDs would be recorded, as well as differences between the configs used (e.g. diffconfig output). If some designated size difference exceeds a threshold (specified in the size-watch configuration) then the make could return an error, while still producing the report. This would mean that this could be used for git bisection to find a size regression. Another way to look at this, would be that a developer could pick a specific size value to monitor (for example, the static size of the network sub-system, or the size of a particular slab in the dynamic memory of a newly booted kernel). They would specify that in the size-watch config, and could monitor that size over time and under various configurations. I envision a couple of usages: 1) A developer could use this to be able to see a report about the total size increases caused by a patch they are about to submit 2) A developer could compare kernel versions for overall size changes 3) A maintainer could examine the affect of a patch on the size of their subsystem. 4) A developer could compare different kernel configs to see the impact of configuration option choices. 5) An automated tool could generate size values to associate with different config option choices (at least, starting from a consistent config set). 6) An automated tool could generate size values for each kernel version (this is what Bloatwatch does now). Bloatwatch generates information on the static size information for various kernel versions. This would have a similar purpose, but the intent would be to integrate it into the kernel build system, to allow any developer to measure the size information, and highlight and track the information of their choice. Any comments? -- Tim The kernel build system is supposed to be stateless, and integrating this with make would mess that up. If your goal is to get more people to use Bloatwatch so they don't make your job quite as difficult, it would probably be more appropriate to put a size analysis script in scripts/ (like checkpatch.pl) that looks at only the kernel you just built and generates thorough statistics in a format readable by both humans and Bloatwatch, preferably something easily diffed. Then developers could use that output in mailing list discussions without having to use Bloatwatch, but embedded developers who care about this enough to use Bloatwatch can be confident that they're working with the same numbers that the rest of us are discussing with the plain text on the lists. -- Chris -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Wed, Oct 8, 2008 at 12:43, Bill Gatliff wrote: This series proposes a generic PWM driver API. seems that the API is solely geared to handle PWM as an output signal. what about input ? all the utility config functions lack set in their name. it's a little confusing as to whether the function is a get or set at first glance. rather than expecting drivers to poke directly into the structure, a set of get functions would work better (even if they're simply #define's that poke into the structure) and line up better with how the GPIO framework operates. -mike -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Mike Frysinger wrote: On Wed, Oct 8, 2008 at 12:43, Bill Gatliff wrote: This series proposes a generic PWM driver API. seems that the API is solely geared to handle PWM as an output signal. True. The peripherals I'm currently targeting are output-only devices, and the API reflects that. what about input ? Well, the SAM9263 has timer/counters that could be used to measure PWM period and duty cycle. But they are a different peripheral entirely. I haven't done an exhaustive survey, but I'm not aware of any PWM-generating hardware that is simultaneously PWM-measuring hardware as well. Seems like they are either one or the other. Are you proposing that the API accommodate both input and output devices? all the utility config functions lack set in their name. it's a little confusing as to whether the function is a get or set at first glance. rather than expecting drivers to poke directly into the structure, a set of get functions would work better (even if they're simply #define's that poke into the structure) and line up better with how the GPIO framework operates. Good point. Originally, I was thinking along the lines of a set-and-forget use case. Do you use get functionality much when generating PWM signals in your applications? b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Bill Gatliff wrote: all the utility config functions lack set in their name. it's a little confusing as to whether the function is a get or set at first glance. For the record, I can support adding a set to the function names. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Wed, Oct 8, 2008 at 22:23, Bill Gatliff wrote: Mike Frysinger wrote: On Wed, Oct 8, 2008 at 12:43, Bill Gatliff wrote: This series proposes a generic PWM driver API. seems that the API is solely geared to handle PWM as an output signal. True. The peripherals I'm currently targeting are output-only devices, and the API reflects that. what about input ? Well, the SAM9263 has timer/counters that could be used to measure PWM period and duty cycle. But they are a different peripheral entirely. I haven't done an exhaustive survey, but I'm not aware of any PWM-generating hardware that is simultaneously PWM-measuring hardware as well. Seems like they are either one or the other. the Blackfin timers/pwm's can flip between input and ouput based on the configuration register. everything else (pin/etc...) is unchanged. Are you proposing that the API accommodate both input and output devices? i dont think we should preclude it from the outset. all the utility config functions lack set in their name. it's a little confusing as to whether the function is a get or set at first glance. rather than expecting drivers to poke directly into the structure, a set of get functions would work better (even if they're simply #define's that poke into the structure) and line up better with how the GPIO framework operates. Good point. Originally, I was thinking along the lines of a set-and-forget use case. Do you use get functionality much when generating PWM signals in your applications? not really, but i see the existing code you've posted could already utilize some of the get functions ... -mike -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Mike Frysinger wrote: the Blackfin timers/pwm's can flip between input and ouput based on the configuration register. everything else (pin/etc...) is unchanged. Interesting! Are you proposing that the API accommodate both input and output devices? i dont think we should preclude it from the outset. I don't think have a problem with that. At some point, I would need someone with input/output hardware to test the input-specific parts, however. Hint, hint. ;) not really, but i see the existing code you've posted could already utilize some of the get functions ... Which parts? I don't really like keeping the period_ticks and duty_ticks values around, but in my case I have no choice--- unless I were to read the CPRE, CPRD and CDTY values from the hardware directly. Which could be what your proposed get methods would do. But that still isn't PWM input the way you are describing, because my hardware wouldn't be _reading_ an incoming PWM: it would be just reporting back the values that it was using to produce its output signal. Huge difference. I dunno, I'm still not sure that measuring the characteristics of an incoming PWM signal isn't a different kind of device from one that produces PWM signals, at least conceptually. Which, in a way, makes it out of scope for the proposed API. Not saying I can't go along with the idea, I'm just not sure what a user would expect to happen if they called pwm_get_period_ns() on the SAM9263 PWMC device. They certainly aren't going to get a measured value in return! b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Mike Frysinger wrote: if you'd seriously play with a Blackfin board, i think we can arrange that I'd seriously *love* to play with one, but I'm pretty strapped for time for another couple of months. The only purpose it would serve near-term would be to prove out the input capabilities of a device that I probably wouldn't have time to write a driver for. :( while true, hardware that can support PWM as both input/output would suffer from two frameworks. if there's ambiguity in behavior (using get in an output mode), then we can just stick it in the documentation and move on. the GPIO framework already has this behavior (set a pin to output and then try and read the data) and i dont recall it ever being an issue there. Good point. I think I'm sold on the idea now. We'd need a PWM_CONFIG_something to tell the hardware to switch to measurement mode if such a mode is supported (suggestions for something welcomed). The config function would return an error if the measurement mode wasn't supported by the device. PWM_CONFIG_INPUT and PWM_CONFIG_OUTPUT, perhaps? In output mode, the pwm_get_*() methods would return the driven values if the device didn't support a (simultaneous) measurement mode, or cached values if the device's configuration registers were write-only. In measurement mode, they'd return the measured values. I think this'll work. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Wed, Oct 8, 2008 at 23:46, Bill Gatliff wrote: Mike Frysinger wrote: Are you proposing that the API accommodate both input and output devices? i dont think we should preclude it from the outset. I don't think have a problem with that. At some point, I would need someone with input/output hardware to test the input-specific parts, however. Hint, hint. ;) if you'd seriously play with a Blackfin board, i think we can arrange that not really, but i see the existing code you've posted could already utilize some of the get functions ... Which parts? I don't really like keeping the period_ticks and duty_ticks values around, but in my case I have no choice--- unless I were to read the CPRE, CPRD and CDTY values from the hardware directly. Which could be what your proposed get methods would do. sorry, i misread the led driver. too many structures! :) But that still isn't PWM input the way you are describing, because my hardware wouldn't be _reading_ an incoming PWM: it would be just reporting back the values that it was using to produce its output signal. Huge difference. I dunno, I'm still not sure that measuring the characteristics of an incoming PWM signal isn't a different kind of device from one that produces PWM signals, at least conceptually. Which, in a way, makes it out of scope for the proposed API. Not saying I can't go along with the idea, I'm just not sure what a user would expect to happen if they called pwm_get_period_ns() on the SAM9263 PWMC device. They certainly aren't going to get a measured value in return! while true, hardware that can support PWM as both input/output would suffer from two frameworks. if there's ambiguity in behavior (using get in an output mode), then we can just stick it in the documentation and move on. the GPIO framework already has this behavior (set a pin to output and then try and read the data) and i dont recall it ever being an issue there. -mike -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Thu, Oct 9, 2008 at 00:18, Bill Gatliff wrote: Mike Frysinger wrote: if you'd seriously play with a Blackfin board, i think we can arrange that I'd seriously *love* to play with one, but I'm pretty strapped for time for another couple of months. The only purpose it would serve near-term would be to prove out the input capabilities of a device that I probably wouldn't have time to write a driver for. :( i'll probably look at the Blackfin-pwm core soonish ... we already implemented a generic framework for it (look for gptimers), so it shouldnt take too much time to transition code for it. while true, hardware that can support PWM as both input/output would suffer from two frameworks. if there's ambiguity in behavior (using get in an output mode), then we can just stick it in the documentation and move on. the GPIO framework already has this behavior (set a pin to output and then try and read the data) and i dont recall it ever being an issue there. Good point. I think I'm sold on the idea now. We'd need a PWM_CONFIG_something to tell the hardware to switch to measurement mode if such a mode is supported (suggestions for something welcomed). The config function would return an error if the measurement mode wasn't supported by the device. PWM_CONFIG_INPUT and PWM_CONFIG_OUTPUT, perhaps? only part on Kconfig i think we'll need is each implementation selecting GENERIC_PWM_INPUT and GENERIC_PWM_OUTPUT. are we looking towards having multiple master implementations being usable simultaneously ? otherwise, i dont think defining things in terms of generating and measuring is really needed ... input and output seems straightforward enough. In output mode, the pwm_get_*() methods would return the driven values if the device didn't support a (simultaneous) measurement mode, or cached values if the device's configuration registers were write-only. In measurement mode, they'd return the measured values. the current generic core looks like it could handle this easily enough since we're working with an array of function pointers. -mike -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 5/6] [PWM] Install new Atmel PWMC driver in Kconfig, expunge old one
On Wed, 8 Oct 2008 11:43:17 -0500 Bill Gatliff [EMAIL PROTECTED] wrote: snipp diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index a726f3b..cdea0bb 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -13,15 +13,6 @@ menuconfig MISC_DEVICES if MISC_DEVICES -config ATMEL_PWM - tristate Atmel AT32/AT91 PWM support - depends on AVR32 || ARCH_AT91 - help - This option enables device driver support for the PWM channels - on certain Atmel prcoessors. Pulse Width Modulation is used for - purposes including software controlled power-efficent backlights - on LCD displays, motor control, and waveform generation. - You know that there are other users of ATMEL_PWM ? There is a atmel-pwm-bl driver in drivers/video/backlight which could probably be converted to pwm-bl using the new pwm framework. config ATMEL_TCLIB bool Atmel AT32/AT91 Timer/Counter Library depends on (AVR32 || ARCH_AT91) snipp -- Best regards, Hans-Christian Egtvedt -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
