gmane.linux.ports.sh.devel

[PATCH] sh: fix sh7724 compilation

Guennadi Liakhovetski — 2012-05-25T14:24:53

Fix compile breakage:

arch/sh/kernel/process.c: In function 'arch_dup_task_struct':
arch/sh/kernel/process.c:23: error: implicit declaration of function 'unlazy_fpu'

Presumably, other 32-bit FPU-enabled SuperH SoCs are affected too.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski< at >gmx.de>
---

This is for a 4-days old next, discard if already fixed.

diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c
index 9b7a459..02a6f07 100644
--- a/arch/sh/kernel/process.c
+++ b/arch/sh/kernel/process.c
< at >< at > -5,6 +5,8 < at >< at >
 #include <linux/export.h>
 #include <linux/stackprotector.h>
 
+#include <asm/fpu.h>
+
 struct kmem_cache *task_xstate_cachep = NULL;
 unsigned int xstate_size;
 
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9 v3] dmaengine: add an shdma-base library

Guennadi Liakhovetski — 2012-05-25T10:59:44

Hi Laxman

On Fri, 25 May 2012, Laxman Dewangan wrote:


Thanks for letting me know. After both our series get merged, when working 
on removal of .private use, switching to your new .slave_id will really be 
the way to go for us.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9 v3] dmaengine: add an shdma-base library

Laxman Dewangan — 2012-05-25T10:27:53


In Nvidia's tegra SOC also require to pass the slave id from client to 
dma driver. I have pushed the change to make it part of struct 
dma_slave_config  on the patch
[PATCH V4 1/2] dma: dmaengine: add slave req id in slave_config

So hope you can use the same if that patch get merged.


--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9 v3] dmaengine: add an shdma-base library

Vinod Koul — 2012-05-25T08:15:37

sorry for the late reply, was away for few days
Yes most of my comments do apply to current driver.
IMO update to a driver should fix existing problems, that why I pointed
them out.

Let me know if you plan to fixing them or I will queue these up for 3.6

[PATCH] clocksource: em_sti: Emma Mobile STI driver V3

Magnus Damm — 2012-05-25T07:03:44

From: Magnus Damm <damm< at >opensource.se>

This is V3 of the Emma Mobile STI timer driver.

The STI hardware is based on a single 48-bit 32kHz
counter that together with two individual compare
registers can generate interrupts. There are no
timer operating modes selectable which means that
the timer can not clear on match.

This driver is providing clocksource support for the
48-bit counter. Clockevents are also supported using
the same timer in oneshot mode.

Signed-off-by: Magnus Damm <damm< at >opensource.se>
---

 Thanks to Thomas Gleixner for his reviews!

 Changes since V2 :
 - use raw spinlocks
 - get rid of periodic support
 - get rid of now unused private data
 - rename em_sti_update() to em_sti_set_next()

 Changes since V1 :
 - removed unused early timer cruft
 - reduce number of functions
 - use request_irq() instead setup_irq() since we run late during boot
 - replace confusing flags with perhaps equally confusing active[] array
 - use clockevents_config_and_register() for registration
 - update frequency with clockevents_config()
 - use 2 ticks as minimum
 - verify oneshot timer and return error to clock event layer

 Verified V2 in the following modes on EMEV2:
 - clocksource only
 - clockevent in periodic mode only
 - clocksource and clockevent in periodic mode
 - clocksource and clockevent in oneshot mode

 arch/arm/mach-shmobile/Kconfig |    6 
 drivers/clocksource/Makefile   |    1 
 drivers/clocksource/em_sti.c   |  399 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 406 insertions(+)

--- 0008/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig2012-05-25 15:18:20.000000000 +0900
< at >< at > -183,6 +183,12 < at >< at > config SH_TIMER_TMU
 help
   This enables build of the TMU timer driver.
 
+config EM_TIMER_STI
+bool "STI timer driver"
+default y
+help
+  This enables build of the STI timer driver.
+
 endmenu
 
 config SH_CLK_CPG
--- 0001/drivers/clocksource/Makefile
+++ work/drivers/clocksource/Makefile2012-05-25 15:18:20.000000000 +0900
< at >< at > -6,6 +6,7 < at >< at > obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)+=
 obj-$(CONFIG_SH_TIMER_CMT)+= sh_cmt.o
 obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
 obj-$(CONFIG_SH_TIMER_TMU)+= sh_tmu.o
+obj-$(CONFIG_EM_TIMER_STI)+= em_sti.o
 obj-$(CONFIG_CLKBLD_I8253)+= i8253.o
 obj-$(CONFIG_CLKSRC_MMIO)+= mmio.o
 obj-$(CONFIG_DW_APB_TIMER)+= dw_apb_timer.o
--- /dev/null
+++ work/drivers/clocksource/em_sti.c2012-05-25 15:59:02.000000000 +0900
< at >< at > -0,0 +1,399 < at >< at >
+/*
+ * Emma Mobile Timer Support - STI
+ *
+ *  Copyright (C) 2012 Magnus Damm
+ *
+ * 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
+ *
+ * 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/init.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/interrupt.h>
+#include <linux/ioport.h>
+#include <linux/io.h>
+#include <linux/clk.h>
+#include <linux/irq.h>
+#include <linux/err.h>
+#include <linux/delay.h>
+#include <linux/clocksource.h>
+#include <linux/clockchips.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+
+enum { USER_CLOCKSOURCE, USER_CLOCKEVENT, USER_NR };
+
+struct em_sti_priv {
+void __iomem *base;
+struct clk *clk;
+struct platform_device *pdev;
+unsigned int active[USER_NR];
+unsigned long rate;
+raw_spinlock_t lock;
+struct clock_event_device ced;
+struct clocksource cs;
+};
+
+#define STI_CONTROL 0x00
+#define STI_COMPA_H 0x10
+#define STI_COMPA_L 0x14
+#define STI_COMPB_H 0x18
+#define STI_COMPB_L 0x1c
+#define STI_COUNT_H 0x20
+#define STI_COUNT_L 0x24
+#define STI_COUNT_RAW_H 0x28
+#define STI_COUNT_RAW_L 0x2c
+#define STI_SET_H 0x30
+#define STI_SET_L 0x34
+#define STI_INTSTATUS 0x40
+#define STI_INTRAWSTATUS 0x44
+#define STI_INTENSET 0x48
+#define STI_INTENCLR 0x4c
+#define STI_INTFFCLR 0x50
+
+static inline unsigned long em_sti_read(struct em_sti_priv *p, int offs)
+{
+return ioread32(p->base + offs);
+}
+
+static inline void em_sti_write(struct em_sti_priv *p, int offs,
+unsigned long value)
+{
+iowrite32(value, p->base + offs);
+}
+
+static int em_sti_enable(struct em_sti_priv *p)
+{
+int ret;
+
+/* enable clock */
+ret = clk_enable(p->clk);
+if (ret) {
+dev_err(&p->pdev->dev, "cannot enable clock\n");
+return ret;
+}
+
+/* configure channel, periodic mode and maximum timeout */
+p->rate = clk_get_rate(p->clk);
+
+/* reset the counter */
+em_sti_write(p, STI_SET_H, 0x40000000);
+em_sti_write(p, STI_SET_L, 0x00000000);
+
+/* mask and clear pending interrupts */
+em_sti_write(p, STI_INTENCLR, 3);
+em_sti_write(p, STI_INTFFCLR, 3);
+
+/* enable updates of counter registers */
+em_sti_write(p, STI_CONTROL, 1);
+
+return 0;
+}
+
+static void em_sti_disable(struct em_sti_priv *p)
+{
+/* mask interrupts */
+em_sti_write(p, STI_INTENCLR, 3);
+
+/* stop clock */
+clk_disable(p->clk);
+}
+
+static cycle_t em_sti_count(struct em_sti_priv *p)
+{
+cycle_t ticks;
+unsigned long flags;
+
+/* the STI hardware buffers the 48-bit count, but to
+ * break it out into two 32-bit access the registers
+ * must be accessed in a certain order.
+ * Always read STI_COUNT_H before STI_COUNT_L.
+ */
+raw_spin_lock_irqsave(&p->lock, flags);
+ticks = (cycle_t)(em_sti_read(p, STI_COUNT_H) & 0xffff) << 32;
+ticks |= em_sti_read(p, STI_COUNT_L);
+raw_spin_unlock_irqrestore(&p->lock, flags);
+
+return ticks;
+}
+
+static cycle_t em_sti_set_next(struct em_sti_priv *p, cycle_t next)
+{
+unsigned long flags;
+
+raw_spin_lock_irqsave(&p->lock, flags);
+
+/* mask compare A interrupt */
+em_sti_write(p, STI_INTENCLR, 1);
+
+/* update compare A value */
+em_sti_write(p, STI_COMPA_H, next >> 32);
+em_sti_write(p, STI_COMPA_L, next & 0xffffffff);
+
+/* clear compare A interrupt source */
+em_sti_write(p, STI_INTFFCLR, 1);
+
+/* unmask compare A interrupt */
+em_sti_write(p, STI_INTENSET, 1);
+
+raw_spin_unlock_irqrestore(&p->lock, flags);
+
+return next;
+}
+
+static irqreturn_t em_sti_interrupt(int irq, void *dev_id)
+{
+struct em_sti_priv *p = dev_id;
+
+p->ced.event_handler(&p->ced);
+return IRQ_HANDLED;
+}
+
+static int em_sti_start(struct em_sti_priv *p, unsigned int user)
+{
+unsigned long flags;
+int used_before;
+int ret = 0;
+
+raw_spin_lock_irqsave(&p->lock, flags);
+used_before = p->active[USER_CLOCKSOURCE] | p->active[USER_CLOCKEVENT];
+if (!used_before)
+ret = em_sti_enable(p);
+
+if (!ret)
+p->active[user] = 1;
+raw_spin_unlock_irqrestore(&p->lock, flags);
+
+return ret;
+}
+
+static void em_sti_stop(struct em_sti_priv *p, unsigned int user)
+{
+unsigned long flags;
+int used_before, used_after;
+
+raw_spin_lock_irqsave(&p->lock, flags);
+used_before = p->active[USER_CLOCKSOURCE] | p->active[USER_CLOCKEVENT];
+p->active[user] = 0;
+used_after = p->active[USER_CLOCKSOURCE] | p->active[USER_CLOCKEVENT];
+
+if (used_before && !used_after)
+em_sti_disable(p);
+raw_spin_unlock_irqrestore(&p->lock, flags);
+}
+
+static struct em_sti_priv *cs_to_em_sti(struct clocksource *cs)
+{
+return container_of(cs, struct em_sti_priv, cs);
+}
+
+static cycle_t em_sti_clocksource_read(struct clocksource *cs)
+{
+return em_sti_count(cs_to_em_sti(cs));
+}
+
+static int em_sti_clocksource_enable(struct clocksource *cs)
+{
+int ret;
+struct em_sti_priv *p = cs_to_em_sti(cs);
+
+ret = em_sti_start(p, USER_CLOCKSOURCE);
+if (!ret)
+__clocksource_updatefreq_hz(cs, p->rate);
+return ret;
+}
+
+static void em_sti_clocksource_disable(struct clocksource *cs)
+{
+em_sti_stop(cs_to_em_sti(cs), USER_CLOCKSOURCE);
+}
+
+static void em_sti_clocksource_resume(struct clocksource *cs)
+{
+em_sti_clocksource_enable(cs);
+}
+
+static int em_sti_register_clocksource(struct em_sti_priv *p)
+{
+struct clocksource *cs = &p->cs;
+
+memset(cs, 0, sizeof(*cs));
+cs->name = dev_name(&p->pdev->dev);
+cs->rating = 200;
+cs->read = em_sti_clocksource_read;
+cs->enable = em_sti_clocksource_enable;
+cs->disable = em_sti_clocksource_disable;
+cs->suspend = em_sti_clocksource_disable;
+cs->resume = em_sti_clocksource_resume;
+cs->mask = CLOCKSOURCE_MASK(48);
+cs->flags = CLOCK_SOURCE_IS_CONTINUOUS;
+
+dev_info(&p->pdev->dev, "used as clock source\n");
+
+/* Register with dummy 1 Hz value, gets updated in ->enable() */
+clocksource_register_hz(cs, 1);
+return 0;
+}
+
+static struct em_sti_priv *ced_to_em_sti(struct clock_event_device *ced)
+{
+return container_of(ced, struct em_sti_priv, ced);
+}
+
+static void em_sti_clock_event_mode(enum clock_event_mode mode,
+    struct clock_event_device *ced)
+{
+struct em_sti_priv *p = ced_to_em_sti(ced);
+
+/* deal with old setting first */
+switch (ced->mode) {
+case CLOCK_EVT_MODE_ONESHOT:
+em_sti_stop(p, USER_CLOCKEVENT);
+break;
+default:
+break;
+}
+
+switch (mode) {
+case CLOCK_EVT_MODE_ONESHOT:
+dev_info(&p->pdev->dev, "used for oneshot clock events\n");
+em_sti_start(p, USER_CLOCKEVENT);
+clockevents_config(&p->ced, p->rate);
+break;
+case CLOCK_EVT_MODE_SHUTDOWN:
+case CLOCK_EVT_MODE_UNUSED:
+em_sti_stop(p, USER_CLOCKEVENT);
+break;
+default:
+break;
+}
+}
+
+static int em_sti_clock_event_next(unsigned long delta,
+   struct clock_event_device *ced)
+{
+struct em_sti_priv *p = ced_to_em_sti(ced);
+cycle_t next;
+int safe;
+
+next = em_sti_set_next(p, em_sti_count(p) + delta);
+safe = em_sti_count(p) < (next - 1);
+
+return !safe;
+}
+
+static void em_sti_register_clockevent(struct em_sti_priv *p)
+{
+struct clock_event_device *ced = &p->ced;
+
+memset(ced, 0, sizeof(*ced));
+ced->name = dev_name(&p->pdev->dev);
+ced->features = CLOCK_EVT_FEAT_ONESHOT;
+ced->rating = 200;
+ced->cpumask = cpumask_of(0);
+ced->set_next_event = em_sti_clock_event_next;
+ced->set_mode = em_sti_clock_event_mode;
+
+dev_info(&p->pdev->dev, "used for clock events\n");
+
+/* Register with dummy 1 Hz value, gets updated in ->set_mode() */
+clockevents_config_and_register(ced, 1, 2, 0xffffffff);
+}
+
+static int __devinit em_sti_probe(struct platform_device *pdev)
+{
+struct em_sti_priv *p;
+struct resource *res;
+int irq, ret;
+
+p = kzalloc(sizeof(*p), GFP_KERNEL);
+if (p == NULL) {
+dev_err(&pdev->dev, "failed to allocate driver data\n");
+ret = -ENOMEM;
+goto err0;
+}
+
+p->pdev = pdev;
+platform_set_drvdata(pdev, p);
+
+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+if (!res) {
+dev_err(&pdev->dev, "failed to get I/O memory\n");
+ret = -EINVAL;
+goto err0;
+}
+
+irq = platform_get_irq(pdev, 0);
+if (irq < 0) {
+dev_err(&pdev->dev, "failed to get irq\n");
+ret = -EINVAL;
+goto err0;
+}
+
+/* map memory, let base point to the STI instance */
+p->base = ioremap_nocache(res->start, resource_size(res));
+if (p->base == NULL) {
+dev_err(&pdev->dev, "failed to remap I/O memory\n");
+ret = -ENXIO;
+goto err0;
+}
+
+/* get hold of clock */
+p->clk = clk_get(&pdev->dev, "sclk");
+if (IS_ERR(p->clk)) {
+dev_err(&pdev->dev, "cannot get clock\n");
+ret = PTR_ERR(p->clk);
+goto err1;
+}
+
+if (request_irq(irq, em_sti_interrupt,
+IRQF_TIMER | IRQF_IRQPOLL | IRQF_NOBALANCING,
+dev_name(&pdev->dev), p)) {
+dev_err(&pdev->dev, "failed to request low IRQ\n");
+ret = -ENOENT;
+goto err2;
+}
+
+raw_spin_lock_init(&p->lock);
+em_sti_register_clockevent(p);
+em_sti_register_clocksource(p);
+return 0;
+
+err2:
+clk_put(p->clk);
+err1:
+iounmap(p->base);
+err0:
+kfree(p);
+return ret;
+}
+
+static int __devexit em_sti_remove(struct platform_device *pdev)
+{
+return -EBUSY; /* cannot unregister clockevent and clocksource */
+}
+
+static struct platform_driver em_sti_device_driver = {
+.probe= em_sti_probe,
+.remove= __devexit_p(em_sti_remove),
+.driver= {
+.name= "em_sti",
+}
+};
+
+module_platform_driver(em_sti_device_driver);
+
+MODULE_AUTHOR("Magnus Damm");
+MODULE_DESCRIPTION("Renesas Emma Mobile STI Timer Driver");
+MODULE_LICENSE("GPL v2");
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: mach-shmobile: add missing GPIO IRQ configuration on mackerel

Guennadi Liakhovetski — 2012-05-25T06:52:51


No, I don't think it is one. My original commit, that added the SDHI0 
card-detect GPIO IRQ feature was already missing the configuration call:

commit 4bff4a7ee4b9e487a1bc1d31082e77b6a381418a
Author: Guennadi Liakhovetski <g.liakhovetski< at >gmx.de>
Date:   Wed May 11 16:51:20 2011 +0000

    ARM: arch-shmobile: support SDHI card detection on mackerel, using a GPIO

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/03] clocksource: em_sti: Emma Mobile STI driver V2

Magnus Damm — 2012-05-25T03:39:06

Hi Thomas,

On Fri, May 25, 2012 at 8:42 AM, Thomas Gleixner <tglx< at >linutronix.de> wrote:

Oh, I wasn't aware that oneshot only is a valid combination. Thanks
for pointing that out, the code will surely become cleaner!


Ok!


Right!


Gotcha!

Thanks,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/03] clocksource: em_sti: Emma Mobile STI driver V2

Thomas Gleixner — 2012-05-24T23:42:14

Why do you want to do that? The core code already handles timers which
only support oneshot mode.


Please make that a raw_spinlock.


All that code in this case can go away.


If you make that:

ced->features = CLOCK_EVT_FEAT_ONESHOT;

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: mach-shmobile: add missing GPIO IRQ configuration on mackerel

Magnus Damm — 2012-05-24T23:34:41

Hi Guennadi,

On Thu, May 24, 2012 at 10:18 PM, Guennadi Liakhovetski
<g.liakhovetski< at >gmx.de> wrote:

This looks like a regression fix. Can you please point out which
commit that caused this?

Thanks,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] lib/decompress_unxz.c: removing all memory helper functions

Joe Perches — 2012-05-24T17:50:49

:)

Whether or not the many applies to __builtin_mem<foo>.
I believe not.

cheers,

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] lib/decompress_unxz.c: removing all memory helper functions

Joe Perches — 2012-05-24T17:40:29

While I'm not completely knowledgeable about gcc,
aren't all the __builtin_mem<foo> functions always
available in gcc 3+

http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_5.html#SEC114

It does say:

Many of these functions are only optimized in certain cases; if not
optimized in a particular case, a call to the library function will be
emitted.

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] lib/decompress_unxz.c: removing all memory helper functions

Joe Perches — 2012-05-24T17:26:11

Perhaps a silly question, but why not use
the __builtin variants?


--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Drop superfluous setting of i2c_board_info.type

Paul Bolle — 2012-05-24T16:40:26

In that case it were two strings ("rtc-pcf8563" versus "pcf8563"). Why
should gcc care? Or is there something going on behind the scenes which
somehow depends on the contents of the string?
 

Thanks. I missed that one, obviously. Should I just drop that part of
the patch and resend?

By the way, together with my previous patch (Message-ID
1337869829.22505.15.camel< at >x61.thuisdomein , probably not yet archived on
the web) we have found all instances of this issue, haven't we?



Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Drop superfluous setting of i2c_board_info.type

Uwe Kleine-König — 2012-05-24T16:22:30

I wondered about that too, gcc doesn't even warn when the two values are
different. See for example commit
bd9e310dca15c9987256f67af19f9f42426e7493.
I already submitted a patch for the imx bits with Message id
1335989287-10094-1-git-send-email-u.kleine-koenig< at >pengutronix.de.
(e.g.
http://mid.gmane.org/1335989287-10094-1-git-send-email-u.kleine-koenig< at >pengutronix.de)

Don't know if Sascha took it already. If he did, he didn't tell me.

Best regards
Uwe

[PATCH] lib/decompress_unxz.c: removing all memory helper functions

T Makphaibulchoke — 2012-05-24T16:03:56

The patch cleans up the file lib/decompress_unxz.c by removing all memory
helper functions, e.g., memmove.  By doing so, any architecture's preboot
environment supporting the XZ decompression needs to define its own copy of
any of the missing memory helper functions.

The patch makes sure that all 4 architectures' preboot currently supporting
the XZ decompressor, arm, s390, sh and x86, build without error when using
the XZ compression.

Adding a prototype for the memcmp function required by the XZ decompressor to
workaround compiler's implicit type error.  Also removing both the memmove and
memcpy defines workaround, to disable lib/decompress_unxz.c from duplicating
both functions.

Adding the missing memcmp function, required by the XZ decompressor, to the
s390 preboot environment.

Adding both the missing memmove and memcmp functions, required by the XZ
decompressor, to the sh preboot environment.

Adding the missing memmove function, required by XZ decompressor, to the x86
preboot environment.

Signed-off-by: T. Makphaibulchoke <tmac< at >hp.com>
---
 arch/arm/boot/compressed/decompress.c |    3 +-
 arch/s390/boot/compressed/misc.c      |   14 +++++
 arch/sh/boot/compressed/misc.c        |   32 ++++++++++++
 arch/x86/boot/compressed/string.c     |   18 +++++++
 lib/decompress_unxz.c                 |   85 +++++++--------------------------
 lib/xz/xz_private.h                   |    7 ++-
 6 files changed, 87 insertions(+), 72 deletions(-)

diff --git a/arch/arm/boot/compressed/decompress.c b/arch/arm/boot/compressed/decompress.c
index f41b38c..80a2219 100644
--- a/arch/arm/boot/compressed/decompress.c
+++ b/arch/arm/boot/compressed/decompress.c
< at >< at > -9,6 +9,7 < at >< at >
 extern unsigned long free_mem_ptr;
 extern unsigned long free_mem_end_ptr;
 extern void error(char *);
+extern int memcmp(const void *, const void *, size_t);
 
 #define STATIC static
 #define STATIC_RW_DATA/* non-static please */
< at >< at > -45,8 +46,6 < at >< at > extern void error(char *);
 #endif
 
 #ifdef CONFIG_KERNEL_XZ
-#define memmove memmove
-#define memcpy memcpy
 #include "../../../../lib/decompress_unxz.c"
 #endif
 
diff --git a/arch/s390/boot/compressed/misc.c b/arch/s390/boot/compressed/misc.c
index 465eca7..b966af3 100644
--- a/arch/s390/boot/compressed/misc.c
+++ b/arch/s390/boot/compressed/misc.c
< at >< at > -87,6 +87,20 < at >< at > void *memcpy(void *__dest, __const void *__src, size_t __n)
 return __builtin_memcpy(__dest, __src, __n);
 }
 
+int memcmp(const void *cs, const void *ct, size_t count)
+{
+const unsigned char *su1, *su2;
+int res = 0;
+
+for (su1 = cs, su2 = ct; 0 < count; ++su1, ++su2, count--) {
+res = *su1 - *su2;
+if (res != 0)
+break;
+}
+
+return res;
+}
+
 void *memmove(void *__dest, __const void *__src, size_t __n)
 {
 char *d;
diff --git a/arch/sh/boot/compressed/misc.c b/arch/sh/boot/compressed/misc.c
index 95470a4..09e740d 100644
--- a/arch/sh/boot/compressed/misc.c
+++ b/arch/sh/boot/compressed/misc.c
< at >< at > -94,6 +94,38 < at >< at > void* memcpy(void* __dest, __const void* __src,
 return __dest;
 }
 
+void *memmove(void *dest, const void *src, size_t size)
+{
+uint8_t *d = dest;
+const uint8_t *s = src;
+size_t i;
+
+if (d < s) {
+for (i = 0; i < size; ++i)
+d[i] = s[i];
+} else if (d > s) {
+i = size;
+while (i-- > 0)
+d[i] = s[i];
+}
+
+return dest;
+}
+
+int memcmp(const void *cs, const void *ct, size_t count)
+{
+const unsigned char *su1, *su2;
+int res = 0;
+
+for (su1 = cs, su2 = ct; 0 < count; ++su1, ++su2, count--) {
+res = *su1 - *su2;
+if (res != 0)
+break;
+}
+
+return res;
+}
+
 static void error(char *x)
 {
 puts("\n\n");
diff --git a/arch/x86/boot/compressed/string.c b/arch/x86/boot/compressed/string.c
index ffb9c5c..2f4fdfa 100644
--- a/arch/x86/boot/compressed/string.c
+++ b/arch/x86/boot/compressed/string.c
< at >< at > -8,4 +8,22 < at >< at > int memcmp(const void *s1, const void *s2, size_t len)
 return diff;
 }
 
+void *memmove(void *dest, const void *src, size_t size)
+{
+uint8_t *d = dest;
+const uint8_t *s = src;
+size_t i;
+
+if (d < s) {
+for (i = 0; i < size; ++i)
+d[i] = s[i];
+} else if (d > s) {
+i = size;
+while (i-- > 0)
+d[i] = s[i];
+}
+
+return dest;
+}
+
 #include "../string.c"
diff --git a/lib/decompress_unxz.c b/lib/decompress_unxz.c
index 9f34eb5..bd09c2f 100644
--- a/lib/decompress_unxz.c
+++ b/lib/decompress_unxz.c
< at >< at > -160,75 +160,24 < at >< at >
 #define vfree(ptr) do { if (ptr != NULL) free(ptr); } while (0)
 
 /*
- * FIXME: Not all basic memory functions are provided in architecture-specific
- * files (yet). We define our own versions here for now, but this should be
- * only a temporary solution.
+ * To support XZ-decompressed file in preboot environment, the following
+ * functions, memcmp, memset, memcpy and memmove, needed to be defined in
+ * architecture-specific preboot environment.
+ *
+ * Not all architecture-specific preboot environment currently support all of
+ * the above functions.
+ *
+ * If your architecture does not support any of the above functions, simply
+ * add the missing function(s) to the architecture-specific preboot string.c
+ * or misc.c file, for example arch/x86/boot/compressed/string.c for the x86
+ * architecture.
+ *
+ * memcmp is not used much and any remotely sane implementation is fast enough.
+ * memmove speed matters in multi-call mode.  Any missing memory helper
+ * functions, including a decent implementation of an in-place memmove function
+ * could be found in lib/string.c
  *
- * memeq and memzero are not used much and any remotely sane implementation
- * is fast enough. memcpy/memmove speed matters in multi-call mode, but
- * the kernel image is decompressed in single-call mode, in which only
- * memcpy speed can matter and only if there is a lot of uncompressible data
- * (LZMA2 stores uncompressible chunks in uncompressed form). Thus, the
- * functions below should just be kept small; it's probably not worth
- * optimizing for speed.
- */
-
-#ifndef memeq
-static bool memeq(const void *a, const void *b, size_t size)
-{
-const uint8_t *x = a;
-const uint8_t *y = b;
-size_t i;
-
-for (i = 0; i < size; ++i)
-if (x[i] != y[i])
-return false;
-
-return true;
-}
-#endif
-
-#ifndef memzero
-static void memzero(void *buf, size_t size)
-{
-uint8_t *b = buf;
-uint8_t *e = b + size;
-
-while (b != e)
-*b++ = '\0';
-}
-#endif
-
-#ifndef memmove
-/* Not static to avoid a conflict with the prototype in the Linux headers. */
-void *memmove(void *dest, const void *src, size_t size)
-{
-uint8_t *d = dest;
-const uint8_t *s = src;
-size_t i;
-
-if (d < s) {
-for (i = 0; i < size; ++i)
-d[i] = s[i];
-} else if (d > s) {
-i = size;
-while (i-- > 0)
-d[i] = s[i];
-}
-
-return dest;
-}
-#endif
-
-/*
- * Since we need memmove anyway, would use it as memcpy too.
- * Commented out for now to avoid breaking things.
  */
-/*
-#ifndef memcpy
-#define memcpy memmove
-#endif
-*/
 
 #include "xz/xz_crc32.c"
 #include "xz/xz_dec_stream.c"
diff --git a/lib/xz/xz_private.h b/lib/xz/xz_private.h
index 482b90f..a997dca 100644
--- a/lib/xz/xz_private.h
+++ b/lib/xz/xz_private.h
< at >< at > -37,9 +37,12 < at >< at >
 #ifdef CONFIG_XZ_DEC_SPARC
 #define XZ_DEC_SPARC
 #endif
-#define memeq(a, b, size) (memcmp(a, b, size) == 0)
-#define memzero(buf, size) memset(buf, 0, size)
 #endif
+/* Make all environments, including preboot, use memcmp for memeq */
+#define memeq(a, b, size) (memcmp(a, b, size) == 0)
+/* To suppress redefine warning in some architecture's preboot */
+#undef memzero
+#define memzero(buf, size) memset(buf, 0, size)
 #define get_le32(p) le32_to_cpup((const uint32_t *)(p))
 #else
 /*

Re: [PATCH] Drop superfluous setting of i2c_board_info.type

Paul Mundt — 2012-05-24T14:59:03

That's a new one to me. Seems legal enough. Using this feature you can
use macro initializion for the bulk of structure elements and then just
overload the ones you disagree with to save time, neat yet revolting at
the same time, there was definitely a committee involved in this.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sh: switch various MSTP PM clocks to device-ID look-up

Paul Mundt — 2012-05-24T14:48:39

No problem, it's better to hash things out in email even if it takes some
cycles rather than burning cycles on patches prematurely.

I agree with you that the first two are messy and doing something about
them is a worthwhile endeavour. I think where we either have a
misunderstanding or a differing of opinions is the 3rd case.

With regards to the lack of an interface number, that's intentional and
by design. All clock lookups using connection IDs factor in the interface
number at CLKDEV_ICK_ID() time, and as you have correctly identified,
this is primarily of value for when we have multiple clocks for one
device.

Perhaps if we use sci as an example you'll see why we went with the
abstraction that way:

- We have cases where gating of the block is controlled
  independently of the actual clock that's of any relevance to
  the driver. 

- This is especially visible in cases where we have MSTP
  bits wrapped to function clocks that control block
  gating but don't actually have anything to do with the
  clock input otherwise.

- The main clock driving sh-sci is not sci_fck, but sci_ick (or
  in the case where it doesn't exist, pclk).

- While sci_fck exists for off/on control, it has very
  little other functionality.
  
- sci_ick can be arbitrarily defined.

- At present this is primarily wrapped to the pclk
  value due to the fact we're using external clock input
  to drive the block.

- The intent has always been to support switching over to
  having the sh-sci block generate its own clock when
  necessary, once we have a facility in place to register
  sci_ick from within the driver itself.

- We have quite a few blocks that follow this model.

So, in summary:

- sci_fck: module on/off
- sci_ick: pclk if external, otherwise internally driven

For extra points:

- Internal generation is a per-port property, so we can have
  cases where internal generation is used for some ports while
  the pclk input is used for others (this largely depends on both
  the baud rate generator and pinmux state).

In these sorts of cases I suppose we have to look at what runtime PM
cares about. I expect that it's only sci_fck that runtime PM requires any
visibility of, while the sci_ick state remains an internal property. I
expect there is some way that we can get the two to co-exist and get the
sort of behaviour that you're after, but it's not obvious that the
present runtime PM approach is sufficiently granular for dealing with
this. clk_get(dev, NULL) certainly doesn't contain enough information
for us to work out whether sci_fck or _ick is needed, and they will both
need to be enabled/disabled at different times and for different reasons.

Perhaps part of the problem is that MSTP control really doesn't really
belong in the clock framework to begin with. MSTP control was shoe-horned
in because that's more or less where it fit from an API point of view in
terms of block enable/disable functionality -- obviously pre-dating
runtime PM and others. Perhaps we're at a point where we need to think
about decoupling MSTP control in to a different API and then thinking
about how to tie that in to runtime PM. On the other hand, the clock
framework utilization by runtime PM at the moment matches MSTP control
pretty well, so I'm also not in a hurry to attempt to introduce another
paradigm and create even more busy work (this was already tried and
abandoned with the hwblk API and so on).

Perhaps the simplest solution is simply having some API extension in
runtime PM in which we are able to associate a function clock for control
on a per-device level without relying purely on clk_get(dev, NULL) to do
the right thing -- indeed this is probably the way things are going to
have to go for the common struct clk fiasco, which for reasons
unbeknownst to me favours pre-clkdev clk_get_sys() string lookups from
the dark ages for everything.

I don't actually have any problems with the series as you've posted it, I
just bristled at the notion that connection IDs are bad and are to be
avoided, while in practice they do have an important application and is
something runtime PM needs to figure out how to deal with.

In the case of your patch, I think that especially in the grouped case it
helps to break things out. For example, you've switched dmac_11_6_fck and
dmac_5_0_fck to sh-dma-engine.1 and .0 respectively, while those may not
functionally be the same, unless sh-dma-engine.1 controls all of channels
11 to 6 and sh-dma-engine.0 is assuming control of channels 5 to 0. If
it's the case that each channel is being registered independently (as we
do have with the TMU, PCIe, etc.) then we simply maintain ICK behaviour
mapping to the corresponding shared MSTP bit (not really any different
from shared IRQ utilization that the dmaengine stuff is doing, too).

We also have cases where devices with a -1 id are supported alongside
those with >= 0 ids that wish to use the same clock lookup strategy.
Any of your #2 or #3 case as noted above will handle this, while the #1
case is completely broken (there are many cases where we have clk0 names
to support this behaviour even though we're really dealing with a -1 id
case) and should be ripped out of the tree with prejudice.

If you're interested in doing cleanups in this area, there are a few
things that I'd like to see done:

- Killing anything that attempts to construct a clock string for
  lookup by hand.

- Getting rid of the clk0 names where -1 dev id behaviour is
  implied and working out an alternate way to connect the lookup
  to the driver. Some of these will actually be valid dev.0 cases
  that simply predate the introduction of the . in the device
  name.

- Naming consistency. Many clocks that we don't use in any driver
  have weird combination dev and ick or con id strings -- like
  hac0/1_fck that need to make up their mind. Once we've
  got a convention in place it'll be easier to prevent people
  from deviating too much and introducing more driver lookup
  mess. A lot of this also predates clkdev lookups.

With those issues addressed I think a lot of the ambiguity will go away
and it should be a lot more readily apparent when we need a con/dev/ick
clock lookup.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: mach-shmobile: add missing GPIO IRQ configuration on mackerel

Guennadi Liakhovetski — 2012-05-24T13:18:44

SDHI0 card-detect GPIO IRQ on mackarel currently works, because it is the
default configuration of IRQ26. However, we should not rely on this and
should configure the function explicitly.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski< at >gmx.de>
---
 arch/arm/mach-shmobile/board-mackerel.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index b577f7c..150122a 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
< at >< at > -1512,6 +1512,9 < at >< at > static void __init mackerel_init(void)
 gpio_request(GPIO_FN_SDHID0_1, NULL);
 gpio_request(GPIO_FN_SDHID0_0, NULL);
 
+/* SDHI0 PORT172 card-detect IRQ26 */
+gpio_request(GPIO_FN_IRQ26_172, NULL);
+
 #if !defined(CONFIG_MMC_SH_MMCIF) && !defined(CONFIG_MMC_SH_MMCIF_MODULE)
 /* enable SDHI1 */
 gpio_request(GPIO_FN_SDHICMD1, NULL);

Re: [PATCH 01/03] clockevents: Make clockevents_config() a global symbol

Thomas Gleixner — 2012-05-24T10:28:29


Gah crap. I take the whole lot. Didn't notice that the driver is in
drivers/clocksource.

Sorry for the confusion.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/03] clockevents: Make clockevents_config() a global symbol

Thomas Gleixner — 2012-05-24T10:27:12


Ooops, I missed that. Can you take it through your tree with my
acked-by please?

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sh: switch various MSTP PM clocks to device-ID look-up

Guennadi Liakhovetski — 2012-05-24T08:56:32

Hi Paul

On Fri, 27 Apr 2012, Paul Mundt wrote:


Sorry for an almost one month long pause. Maybe we could close this thread 
by verifying my current understanding and checking your preferences.

1. The drivers I was looking at: SDHI, MMCIF, MSIOF all do clk_get(dev, 
   "name%d"); where name%d is sdhi%d, mmc%d and msiof%d respectively.
2. Some other drivers, like i2c do just clk_get(dev, NULL);
3. Others yet, e.g., sci do clk_get(dev, name), where name is fixed - it 
   doesn't have the interface number in it. The sci driver uses two clocks 
   with connection IDs "sci_ick" and "sci_fck."

This seems a bit messy to me, but, well, as long as it works - no need to 
change anything there:-) My understanding would be, that a preferred 
scheme would be to either use no connection ID at all or use a fixed one - 
without an index. On the platform side:

1. The runtime PM acquires clocks per clk_get(dev, NULL)
2. Some platforms like sh7724, sh7722 on the sh side, all ARM SoCs use 
   mostly CLKDEV_DEV_ID() and CLKDEV_CON_ID() entries in their clk lookup 
   tables.
3. CLKDEV_ICK_ID() entries are used occasionally, mostly, when more than 
   one clock per device is registered
4. On other platforms, like those, affected by this patch, mainly or 
   exclusively CLKDEV_CON_ID() entries are used.

Here my understanding is, that for clocks, that should be referenced from 
the runtime PM a device reference is compulsory, so, CLKDEV_ICK_ID() or 
CLKDEV_DEV_ID() should be used. For clocks, used by drivers with an 
indexed connection ID, CLKDEV_CON_ID() entries will work too. This means, 
that at least the runtime PM on platforms, touched by this patch, is 
disabled for affected devices, but I personally have no idea how much of a 
problem that is, I don't work with any of them.

So, if this situation is acceptable, no problem with me, we can drop this 
series. If, however, we want to change something in this, would be nice to 
know your opinion. If my this patch-set can be adjusted to fulfill any of 
your wishes in this area - we could try to do that:-)

Thanks
Guennadi


---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html