* [PATCH 3/5] ARM: shmobile: Use wfi macro in platform_cpu_die.
From: Nick Bowler @ 2011-09-09 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315582012-23507-1-git-send-email-nbowler@elliptictech.com>
Current Shmobile CPU hotplug code includes a hardcoded WFI instruction,
in ARM encoding. The hardcoded instruction is both hard to understand
and doomed to failure when building the kernel in Thumb-2 mode.
Signed-off-by: Nick Bowler <nbowler@elliptictech.com>
---
Compile tested in both ARM and Thumb-2 mode, and the resulting hotplug.o
contains the correct instruction sequence, but the final kernel failed
to link for apparently unrelated reasons:
In ARM mode:
LD .tmp_vmlinux1
arch/arm/kernel/built-in.o: In function `twd_timer_setup':
io.c:(.cpuinit.text+0x600): undefined reference to `gic_enable_ppi'
arch/arm/mach-shmobile/built-in.o: In function `smp_init_cpus':
pfc-sh7372.c:(.init.text+0xbb0): undefined reference to `gic_raise_softirq'
In Thumb-2 mode:
LD .tmp_vmlinux1
arch/arm/kernel/built-in.o: In function `get_wchan':
io.c:(.text+0x1542): undefined reference to `unwind_frame'
arch/arm/kernel/built-in.o: In function `walk_stackframe':
io.c:(.text+0x27f0): undefined reference to `unwind_frame'
arch/arm/kernel/built-in.o: In function `profile_pc':
io.c:(.text+0x2828): undefined reference to `unwind_frame'
arch/arm/kernel/built-in.o: In function `twd_timer_setup':
io.c:(.cpuinit.text+0x42e): undefined reference to `gic_enable_ppi'
arch/arm/mach-shmobile/built-in.o: In function `smp_init_cpus':
pfc-sh7372.c:(.init.text+0x8e8): undefined reference to `gic_raise_softirq'
---
arch/arm/mach-shmobile/hotplug.c | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-shmobile/hotplug.c b/arch/arm/mach-shmobile/hotplug.c
index 238a0d9..1e83087 100644
--- a/arch/arm/mach-shmobile/hotplug.c
+++ b/arch/arm/mach-shmobile/hotplug.c
@@ -13,6 +13,8 @@
#include <linux/errno.h>
#include <linux/smp.h>
+#include <asm/system.h>
+
int platform_cpu_kill(unsigned int cpu)
{
return 1;
@@ -21,13 +23,7 @@ int platform_cpu_kill(unsigned int cpu)
void platform_cpu_die(unsigned int cpu)
{
while (1) {
- /*
- * here's the WFI
- */
- asm(".word 0xe320f003\n"
- :
- :
- : "memory", "cc");
+ wfi();
}
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH 0/5] Convert ARM subarchitectures to generic wfi macro.
From: Nick Bowler @ 2011-09-09 15:26 UTC (permalink / raw)
To: linux-arm-kernel
This series cleans up all remaining ARM subarchitectures that I could
find to use the generic wfi macro. As I don't have any of the boards in
question, I've only compile-tested these patches to the extent that I
was able.
See the previous discussion in https://lkml.org/lkml/2011/8/19/433 for
more background.
Nick Bowler (5):
ARM: realview: Use wfi macro in platform_do_lowpower.
ARM: exynos4: Use wfi macro in platform_do_lowpower.
ARM: shmobile: Use wfi macro in platform_cpu_die.
ARM: tegra: Use wfi macro in platform_do_lowpower.
ARM: omap4: Kill private do_wfi macro.
arch/arm/mach-exynos4/hotplug.c | 9 ++-------
arch/arm/mach-omap2/include/mach/omap4-common.h | 11 -----------
arch/arm/mach-omap2/omap-hotplug.c | 7 +++----
arch/arm/mach-omap2/pm44xx.c | 4 +++-
arch/arm/mach-realview/hotplug.c | 9 ++-------
arch/arm/mach-shmobile/hotplug.c | 10 +++-------
arch/arm/mach-tegra/hotplug.c | 9 ++-------
7 files changed, 15 insertions(+), 44 deletions(-)
--
1.7.3.4
^ permalink raw reply
* [PATCH 10/10] ARM: mach-shmobile: clock-sh73a0: add DSIxPHY clock support
From: Kuninori Morimoto @ 2011-09-09 10:29 UTC (permalink / raw)
To: linux-sh
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
arch/arm/mach-shmobile/board-ag5evm.c | 14 +++-
arch/arm/mach-shmobile/board-kota2.c | 14 +++-
arch/arm/mach-shmobile/clock-sh73a0.c | 113 +++++++++++++++++++++++++++++++++
3 files changed, 134 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ag5evm.c b/arch/arm/mach-shmobile/board-ag5evm.c
index 5aa1432..e6bd615 100644
--- a/arch/arm/mach-shmobile/board-ag5evm.c
+++ b/arch/arm/mach-shmobile/board-ag5evm.c
@@ -320,30 +320,36 @@ static struct resource mipidsi0_resources[] = {
},
};
-#define DSI0PHYCR 0xe615006c
static int sh_mipi_set_dot_clock(struct platform_device *pdev,
void __iomem *base,
int enable)
{
- struct clk *pck;
+ struct clk *pck, *phy;
int ret = -EIO;
pck = clk_get(&pdev->dev, "dsip_clk");
if (IS_ERR(pck))
goto sh_mipi_set_dot_clock_pck_err;
+ phy = clk_get(&pdev->dev, "dsiphy_clk");
+ if (IS_ERR(phy))
+ goto sh_mipi_set_dot_clock_phy_err;
+
if (enable) {
clk_set_rate(pck, clk_round_rate(pck, 24000000));
- __raw_writel(0x2a809010, DSI0PHYCR);
+ clk_set_rate(phy, clk_round_rate(pck, 510000000));
clk_enable(pck);
+ clk_enable(phy);
} else {
clk_disable(pck);
+ clk_disable(phy);
}
ret = 0;
+ clk_put(phy);
+sh_mipi_set_dot_clock_phy_err:
clk_put(pck);
-
sh_mipi_set_dot_clock_pck_err:
return ret;
}
diff --git a/arch/arm/mach-shmobile/board-kota2.c b/arch/arm/mach-shmobile/board-kota2.c
index a225111..ce53ee0 100644
--- a/arch/arm/mach-shmobile/board-kota2.c
+++ b/arch/arm/mach-shmobile/board-kota2.c
@@ -367,28 +367,36 @@ static u32 sh_mipi_extra_dcs[] = {
};
#define DSI0PCKCR 0xe6150064
-#define DSI0PHYCR 0xe615006c
static int sh_mipi_set_dot_clock(struct platform_device *pdev,
void __iomem *base,
int enable)
{
- struct clk *pck;
+ struct clk *pck, *phy;
int ret = -EIO;
pck = clk_get(&pdev->dev, "dsip_clk");
if (IS_ERR(pck))
goto sh_mipi_set_dot_clock_pck_err;
+ phy = clk_get(&pdev->dev, "dsiphy_clk");
+ if (IS_ERR(phy))
+ goto sh_mipi_set_dot_clock_phy_err;
+
if (enable) {
+ /* 268.8MHz (33.6MHz x8) */
clk_set_rate(pck, clk_round_rate(pck, 19200000));
- __raw_writel(0x2a8b9a0d, DSI0PHYCR); /* 268.8MHz (33.6MHz x8) */
+ clk_set_rate(phy, clk_round_rate(phy, 268800000));
clk_enable(pck);
+ clk_enable(phy);
} else {
clk_disable(pck);
+ clk_disable(phy);
}
ret = 0;
+ clk_put(phy);
+sh_mipi_set_dot_clock_phy_err:
clk_put(pck);
sh_mipi_set_dot_clock_pck_err:
return ret;
diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index 80cb438..d447c7a 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -262,6 +262,114 @@ static struct clk div6_clks[DIV6_NR] = {
[DIV6_DSI1P] = SH_CLK_DIV6(&pll1_div2_clk, DSI1PCKCR, 0),
};
+/* DSI DIV */
+static unsigned long dsiphy_recalc(struct clk *clk)
+{
+ u32 value;
+
+ value = __raw_readl(clk->mapping->base);
+
+ /* FIXME */
+ if (!(value & 0x000B8000))
+ return clk->parent->rate;
+
+ value &= 0x3f;
+ value += 1;
+
+ if ((value < 12) ||
+ (value > 33)) {
+ pr_err("DSIPHY has wrong value (%d)", value);
+ return 0;
+ }
+
+ return clk->parent->rate / value;
+}
+
+static long dsiphy_round_rate(struct clk *clk, unsigned long rate)
+{
+ return clk_rate_multi_range_round(clk, 12, 33, rate);
+}
+
+static void dsiphy_disable(struct clk *clk)
+{
+ u32 value;
+
+ value = __raw_readl(clk->mapping->base);
+ value &= ~0x000B8000;
+
+ __raw_writel(value , clk->mapping->base);
+}
+
+static int dsiphy_enable(struct clk *clk)
+{
+ u32 value;
+ int multi;
+
+ value = __raw_readl(clk->mapping->base);
+ multi = (value & 0x3f) + 1;
+
+ if ((multi < 12) || (multi > 33))
+ return -EIO;
+
+ __raw_writel(value | 0x000B8000, clk->mapping->base);
+
+ return 0;
+}
+
+static int dsiphy_set_rate(struct clk *clk, unsigned long rate)
+{
+ u32 value;
+ int idx;
+
+ idx = rate / clk->parent->rate;
+ if ((idx < 12) || (idx > 33))
+ return -EINVAL;
+
+ idx += -1;
+
+ value = __raw_readl(clk->mapping->base);
+ value = (value & ~0x3f) + idx;
+
+ __raw_writel(value, clk->mapping->base);
+
+ return 0;
+}
+
+static struct clk_ops dsiphy_clk_ops = {
+ .recalc = dsiphy_recalc,
+ .round_rate = dsiphy_round_rate,
+ .set_rate = dsiphy_set_rate,
+ .enable = dsiphy_enable,
+ .disable = dsiphy_disable,
+};
+
+static struct clk_mapping dsi0phy_clk_mapping = {
+ .phys = DSI0PHYCR,
+ .len = 4,
+};
+
+static struct clk_mapping dsi1phy_clk_mapping = {
+ .phys = DSI1PHYCR,
+ .len = 4,
+};
+
+static struct clk dsi0phy_clk = {
+ .ops = &dsiphy_clk_ops,
+ .parent = &div6_clks[DIV6_DSI0P], /* late install */
+ .mapping = &dsi0phy_clk_mapping,
+};
+
+static struct clk dsi1phy_clk = {
+ .ops = &dsiphy_clk_ops,
+ .parent = &div6_clks[DIV6_DSI1P], /* late install */
+ .mapping = &dsi1phy_clk_mapping,
+};
+
+static struct clk *late_main_clks[] = {
+ &dsi0phy_clk,
+ &dsi1phy_clk,
+};
+
enum { MSTP001,
MSTP129, MSTP128, MSTP127, MSTP126, MSTP125, MSTP118, MSTP117, MSTP116, MSTP100,
MSTP219,
@@ -322,6 +430,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_ICK_ID("dsit_clk", "sh-mipi-dsi.1", &div6_clks[DIV6_DSIT]),
CLKDEV_ICK_ID("dsip_clk", "sh-mipi-dsi.0", &div6_clks[DIV6_DSI0P]),
CLKDEV_ICK_ID("dsip_clk", "sh-mipi-dsi.1", &div6_clks[DIV6_DSI1P]),
+ CLKDEV_ICK_ID("dsiphy_clk", "sh-mipi-dsi.0", &dsi0phy_clk),
+ CLKDEV_ICK_ID("dsiphy_clk", "sh-mipi-dsi.1", &dsi1phy_clk),
/* MSTP32 clocks */
CLKDEV_DEV_ID("i2c-sh_mobile.2", &mstp_clks[MSTP001]), /* I2C2 */
@@ -394,6 +504,9 @@ void __init sh73a0_clock_init(void)
if (!ret)
ret = sh_clk_mstp32_register(mstp_clks, MSTP_NR);
+ for (k = 0; !ret && (k < ARRAY_SIZE(late_main_clks)); k++)
+ ret = clk_register(late_main_clks[k]);
+
clkdev_add_table(lookups, ARRAY_SIZE(lookups));
if (!ret)
--
1.7.4.1
^ permalink raw reply related
* [PATCH 09/10] fbdev: sh_mipi_dsi: add set_dot_clock() for each platform
From: Kuninori Morimoto @ 2011-09-09 10:28 UTC (permalink / raw)
To: linux-sh
Dot clock of SH MIPI are depends on each platform board.
This patch adds set_dot_clock() function for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
arch/arm/mach-shmobile/board-ag5evm.c | 34 +++++++++++++++++++++---
arch/arm/mach-shmobile/board-ap4evb.c | 25 ++++++++++++++++++
arch/arm/mach-shmobile/board-kota2.c | 38 +++++++++++++++++++++++----
drivers/video/sh_mipi_dsi.c | 45 ++++++++-------------------------
include/video/sh_mipi_dsi.h | 3 ++
5 files changed, 100 insertions(+), 45 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ag5evm.c b/arch/arm/mach-shmobile/board-ag5evm.c
index 87e9091..5aa1432 100644
--- a/arch/arm/mach-shmobile/board-ag5evm.c
+++ b/arch/arm/mach-shmobile/board-ag5evm.c
@@ -320,6 +320,34 @@ static struct resource mipidsi0_resources[] = {
},
};
+#define DSI0PHYCR 0xe615006c
+static int sh_mipi_set_dot_clock(struct platform_device *pdev,
+ void __iomem *base,
+ int enable)
+{
+ struct clk *pck;
+ int ret = -EIO;
+
+ pck = clk_get(&pdev->dev, "dsip_clk");
+ if (IS_ERR(pck))
+ goto sh_mipi_set_dot_clock_pck_err;
+
+ if (enable) {
+ clk_set_rate(pck, clk_round_rate(pck, 24000000));
+ __raw_writel(0x2a809010, DSI0PHYCR);
+ clk_enable(pck);
+ } else {
+ clk_disable(pck);
+ }
+
+ ret = 0;
+
+ clk_put(pck);
+
+sh_mipi_set_dot_clock_pck_err:
+ return ret;
+}
+
static struct sh_mipi_dsi_info mipidsi0_info = {
.data_format = MIPI_RGB888,
.lcd_chan = &lcdc0_info.ch[0],
@@ -328,6 +356,7 @@ static struct sh_mipi_dsi_info mipidsi0_info = {
.clksrc = 1,
.flags = SH_MIPI_DSI_HSABM |
SH_MIPI_DSI_SYNC_PULSES_MODE,
+ .set_dot_clock = sh_mipi_set_dot_clock,
};
static struct platform_device mipidsi0_device = {
@@ -467,8 +496,6 @@ void __init ag5evm_init_irq(void)
__raw_writew(__raw_readw(PINTCR0A) | (2<<10), PINTCR0A);
}
-#define DSI0PHYCR 0xe615006c
-
static void __init ag5evm_init(void)
{
sh73a0_pinmux_init();
@@ -549,9 +576,6 @@ static void __init ag5evm_init(void)
gpio_direction_output(GPIO_PORT235, 0);
lcd_backlight_reset();
- /* MIPI-DSI clock setup */
- __raw_writel(0x2a809010, DSI0PHYCR);
-
/* enable SDHI0 on CN15 [SD I/F] */
gpio_request(GPIO_FN_SDHICD0, NULL);
gpio_request(GPIO_FN_SDHIWP0, NULL);
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
index 114fd8a..3ed10d7 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -575,12 +575,37 @@ static struct resource mipidsi0_resources[] = {
},
};
+#define PHYCTRL 0x0070
+static int sh_mipi_set_dot_clock(struct platform_device *pdev,
+ void __iomem *base,
+ int enable)
+{
+ struct clk *pck = clk_get(&pdev->dev, "dsip_clk");
+ void __iomem *phy = base + PHYCTRL;
+
+ if (IS_ERR(pck))
+ return -EIO;
+
+ if (enable) {
+ clk_set_rate(pck, clk_round_rate(pck, 24000000));
+ iowrite32(ioread32(phy) | (0xb << 8), phy);
+ clk_enable(pck);
+ } else {
+ clk_disable(pck);
+ }
+
+ clk_put(pck);
+
+ return 0;
+}
+
static struct sh_mipi_dsi_info mipidsi0_info = {
.data_format = MIPI_RGB888,
.lcd_chan = &lcdc_info.ch[0],
.lane = 2,
.vsynw_offset = 17,
.flags = SH_MIPI_DSI_SYNC_PULSES_MODE,
+ .set_dot_clock = sh_mipi_set_dot_clock,
};
static struct platform_device mipidsi0_device = {
diff --git a/arch/arm/mach-shmobile/board-kota2.c b/arch/arm/mach-shmobile/board-kota2.c
index a2be703..a225111 100644
--- a/arch/arm/mach-shmobile/board-kota2.c
+++ b/arch/arm/mach-shmobile/board-kota2.c
@@ -20,6 +20,7 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include <linux/clk.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/interrupt.h>
@@ -365,6 +366,34 @@ static u32 sh_mipi_extra_dcs[] = {
SH_MIPI_DCS(0x2c), /* memory write on */
};
+#define DSI0PCKCR 0xe6150064
+#define DSI0PHYCR 0xe615006c
+static int sh_mipi_set_dot_clock(struct platform_device *pdev,
+ void __iomem *base,
+ int enable)
+{
+ struct clk *pck;
+ int ret = -EIO;
+
+ pck = clk_get(&pdev->dev, "dsip_clk");
+ if (IS_ERR(pck))
+ goto sh_mipi_set_dot_clock_pck_err;
+
+ if (enable) {
+ clk_set_rate(pck, clk_round_rate(pck, 19200000));
+ __raw_writel(0x2a8b9a0d, DSI0PHYCR); /* 268.8MHz (33.6MHz x8) */
+ clk_enable(pck);
+ } else {
+ clk_disable(pck);
+ }
+
+ ret = 0;
+
+ clk_put(pck);
+sh_mipi_set_dot_clock_pck_err:
+ return ret;
+}
+
static struct sh_mipi_dsi_info mipidsi0_info = {
.data_format = MIPI_RGB888,
.lcd_chan = &lcdc0_info.ch[0],
@@ -377,6 +406,7 @@ static struct sh_mipi_dsi_info mipidsi0_info = {
SH_MIPI_DSI_SYNC_BURST_MODE,
.extra_array = sh_mipi_extra_dcs,
.extra_array_len= ARRAY_SIZE(sh_mipi_extra_dcs),
+ .set_dot_clock = sh_mipi_set_dot_clock,
};
static struct platform_device mipidsi0_device = {
@@ -434,9 +464,6 @@ void __init kota2_init_irq(void)
__raw_writew(2 << 10, PINTCR0A);
}
-#define DSI0PCKCR 0xe6150064
-#define DSI0PHYCR 0xe615006c
-
static void __init kota2_init(void)
{
sh73a0_pinmux_init();
@@ -534,9 +561,8 @@ static void __init kota2_init(void)
gpio_request(GPIO_FN_SDHID1_1_PU, NULL);
gpio_request(GPIO_FN_SDHID1_0_PU, NULL);
- /* MIPI-DSI clock setup */
- __raw_writel(0x00000119, DSI0PCKCR);
- __raw_writel(0x2a8b9111, DSI0PHYCR);
+ /* MIPI-DSI clock clean up */
+ __raw_writel(0x00000000, DSI0PCKCR);
/* Unreset LCD Panel */
gpio_request(GPIO_PORT217, NULL);
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index 166b468..e42cd81 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -59,7 +59,6 @@ struct sh_mipi {
void __iomem *base;
void __iomem *linkbase;
struct clk *dsit_clk;
- struct clk *dsip_clk;
struct device *dev;
void *next_board_data;
@@ -313,8 +312,8 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
/* DSI-Tx bias on */
iowrite32(0x00000001, base + PHYCTRL);
udelay(200);
- /* Deassert resets, power on, set multiplier */
- iowrite32(0x03070b01, base + PHYCTRL);
+ /* Deassert resets, power on */
+ iowrite32(0x03070001, base + PHYCTRL);
/* setup l-bridge */
@@ -441,6 +440,9 @@ static int __init sh_mipi_probe(struct platform_device *pdev)
if (!res || !res2 || idx >= ARRAY_SIZE(mipi_dsi) || !pdata)
return -ENODEV;
+ if (!pdata->set_dot_clock)
+ return -EINVAL;
+
mutex_lock(&array_lock);
if (idx < 0)
for (idx = 0; idx < ARRAY_SIZE(mipi_dsi) && mipi_dsi[idx]; idx++)
@@ -501,34 +503,10 @@ static int __init sh_mipi_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "DSI-T clk %lu -> %lu\n", f_current, rate);
- mipi->dsip_clk = clk_get(&pdev->dev, "dsip_clk");
- if (IS_ERR(mipi->dsip_clk)) {
- ret = PTR_ERR(mipi->dsip_clk);
- goto eclkpget;
- }
-
- f_current = clk_get_rate(mipi->dsip_clk);
- /* Between 10 and 50MHz */
- rate = clk_round_rate(mipi->dsip_clk, 24000000);
- if (rate > 0 && rate != f_current)
- ret = clk_set_rate(mipi->dsip_clk, rate);
- else
- ret = rate;
- if (ret < 0)
- goto esetprate;
-
- dev_dbg(&pdev->dev, "DSI-P clk %lu -> %lu\n", f_current, rate);
-
- msleep(10);
-
ret = clk_enable(mipi->dsit_clk);
if (ret < 0)
goto eclkton;
- ret = clk_enable(mipi->dsip_clk);
- if (ret < 0)
- goto eclkpon;
-
mipi_dsi[idx] = mipi;
pm_runtime_enable(&pdev->dev);
@@ -538,6 +516,10 @@ static int __init sh_mipi_probe(struct platform_device *pdev)
if (ret < 0)
goto emipisetup;
+ ret = pdata->set_dot_clock(pdev, mipi->base, 1);
+ if (ret < 0)
+ goto emipisetup;
+
mutex_unlock(&array_lock);
platform_set_drvdata(pdev, mipi);
@@ -557,13 +539,8 @@ static int __init sh_mipi_probe(struct platform_device *pdev)
emipisetup:
mipi_dsi[idx] = NULL;
pm_runtime_disable(&pdev->dev);
- clk_disable(mipi->dsip_clk);
-eclkpon:
clk_disable(mipi->dsit_clk);
eclkton:
-esetprate:
- clk_put(mipi->dsip_clk);
-eclkpget:
esettrate:
clk_put(mipi->dsit_clk);
eclktget:
@@ -614,10 +591,10 @@ static int __exit sh_mipi_remove(struct platform_device *pdev)
pdata->lcd_chan->board_cfg.board_data = NULL;
pm_runtime_disable(&pdev->dev);
- clk_disable(mipi->dsip_clk);
clk_disable(mipi->dsit_clk);
clk_put(mipi->dsit_clk);
- clk_put(mipi->dsip_clk);
+ pdata->set_dot_clock(pdev, mipi->base, 0);
+
iounmap(mipi->linkbase);
if (res2)
release_mem_region(res2->start, resource_size(res2));
diff --git a/include/video/sh_mipi_dsi.h b/include/video/sh_mipi_dsi.h
index fb3950e..5ded705 100644
--- a/include/video/sh_mipi_dsi.h
+++ b/include/video/sh_mipi_dsi.h
@@ -61,6 +61,9 @@ struct sh_mipi_dsi_info {
unsigned int vsynw_offset;
u32 *extra_array;
int extra_array_len;
+ int (*set_dot_clock)(struct platform_device *pdev,
+ void __iomem *base,
+ int enable);
};
#endif
--
1.7.4.1
^ permalink raw reply related
* [PATCH 08/10] ARM: mach-shmobile: clock-sh7372: remove un-necessary index
From: Kuninori Morimoto @ 2011-09-09 10:28 UTC (permalink / raw)
To: linux-sh
it is not necessary to have sh7372_xxxx index on static variable
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
arch/arm/mach-shmobile/clock-sh7372.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-shmobile/clock-sh7372.c b/arch/arm/mach-shmobile/clock-sh7372.c
index c2702b5..bb36af4 100644
--- a/arch/arm/mach-shmobile/clock-sh7372.c
+++ b/arch/arm/mach-shmobile/clock-sh7372.c
@@ -476,7 +476,7 @@ static struct clk_ops fsidiv_clk_ops = {
.disable = fsidiv_disable,
};
-static struct clk_mapping sh7372_fsidiva_clk_mapping = {
+static struct clk_mapping fsidiva_clk_mapping = {
.phys = FSIDIVA,
.len = 8,
};
@@ -484,10 +484,10 @@ static struct clk_mapping sh7372_fsidiva_clk_mapping = {
struct clk sh7372_fsidiva_clk = {
.ops = &fsidiv_clk_ops,
.parent = &div6_reparent_clks[DIV6_FSIA], /* late install */
- .mapping = &sh7372_fsidiva_clk_mapping,
+ .mapping = &fsidiva_clk_mapping,
};
-static struct clk_mapping sh7372_fsidivb_clk_mapping = {
+static struct clk_mapping fsidivb_clk_mapping = {
.phys = FSIDIVB,
.len = 8,
};
@@ -495,7 +495,7 @@ static struct clk_mapping sh7372_fsidivb_clk_mapping = {
struct clk sh7372_fsidivb_clk = {
.ops = &fsidiv_clk_ops,
.parent = &div6_reparent_clks[DIV6_FSIB], /* late install */
- .mapping = &sh7372_fsidivb_clk_mapping,
+ .mapping = &fsidivb_clk_mapping,
};
static struct clk *late_main_clks[] = {
--
1.7.4.1
^ permalink raw reply related
* [PATCH 07/10] sh: clkfwk: add clk_rate_multi_range_round()
From: Kuninori Morimoto @ 2011-09-09 10:27 UTC (permalink / raw)
To: linux-sh
Some Clock Pulse Generator has PLL multiplication.
clk_rate_multi_range_round() will be good helper for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
drivers/sh/clk/core.c | 20 ++++++++++++++++++++
include/linux/sh_clk.h | 3 +++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/sh/clk/core.c b/drivers/sh/clk/core.c
index dc8d022..f4323a3 100644
--- a/drivers/sh/clk/core.c
+++ b/drivers/sh/clk/core.c
@@ -173,6 +173,26 @@ long clk_rate_div_range_round(struct clk *clk, unsigned int div_min,
return clk_rate_round_helper(&div_range_round);
}
+static long clk_rate_multi_range_iter(unsigned int pos,
+ struct clk_rate_round_data *rounder)
+{
+ return clk_get_rate(rounder->arg) * pos;
+}
+
+long clk_rate_multi_range_round(struct clk *clk, unsigned int div_min,
+ unsigned int div_max, unsigned long rate)
+{
+ struct clk_rate_round_data div_range_round = {
+ .min = div_min,
+ .max = div_max,
+ .func = clk_rate_multi_range_iter,
+ .arg = clk_get_parent(clk),
+ .rate = rate,
+ };
+
+ return clk_rate_round_helper(&div_range_round);
+}
+
int clk_rate_table_find(struct clk *clk,
struct cpufreq_frequency_table *freq_table,
unsigned long rate)
diff --git a/include/linux/sh_clk.h b/include/linux/sh_clk.h
index 3ccf186..1fc9f28 100644
--- a/include/linux/sh_clk.h
+++ b/include/linux/sh_clk.h
@@ -94,6 +94,9 @@ int clk_rate_table_find(struct clk *clk,
long clk_rate_div_range_round(struct clk *clk, unsigned int div_min,
unsigned int div_max, unsigned long rate);
+long clk_rate_multi_range_round(struct clk *clk, unsigned int div_min,
+ unsigned int div_max, unsigned long rate);
+
long clk_round_parent(struct clk *clk, unsigned long target,
unsigned long *best_freq, unsigned long *parent_freq,
unsigned int div_min, unsigned int div_max);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 06/10] fbdev: sh_mipi_dsi: add VMLEN1/VMLEN2 calculation
From: Kuninori Morimoto @ 2011-09-09 10:27 UTC (permalink / raw)
To: linux-sh
VMLEN1/VMLEN2 needs blanking length which is calculated from
video image size.
The calculation methods are explained on
[SH MIPI] - [Video Mode] - [Blanking Packet setting]
But HFPLEN (= VMLEN2) is un-understandable.
For example, if SH-MIPI input was RGB888 (3byte),
output was RGB888 (3byte)
and 3lane connection, the date goes straight.
But if SH-MIPI input was RGB888 (3byte),
output was RGB565 (2byte)
and 4lane connection, it needs delay in HFPLEN.
Then (input cycle - output cycle) * lane is necessary the delay
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
drivers/video/sh_mipi_dsi.c | 46 +++++++++++++++++++++++++++++++++++++-----
1 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index 3f8da95..166b468 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -41,6 +41,7 @@
#define VMCTR1 0x0020
#define VMCTR2 0x0024
#define VMLEN1 0x0028
+#define VMLEN2 0x002c
#define CMTSRTREQ 0x0070
#define CMTSRTCTR 0x00d0
@@ -159,9 +160,9 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
void __iomem *base = mipi->base;
struct sh_mobile_lcdc_chan_cfg *ch = pdata->lcd_chan;
u32 pctype, datatype, pixfmt, linelength, vmctr2, excmd;
- u32 tmp;
+ u32 tmp, top, bottom, delay;
bool yuv;
- int i;
+ int i, bpp;
/*
* Select data format. MIPI DSI is not hot-pluggable, so, we just use
@@ -349,11 +350,44 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
iowrite32(vmctr2, mipi->linkbase + VMCTR2);
/*
- * 0x660 = 1632 bytes per line (RGB24, 544 pixels: see
- * sh_mobile_lcdc_info.ch[0].lcd_cfg[0].xres), HSALEN = 1 - default
- * (unused if VMCTR2[HSABM] = 0)
+ * VMLEN1 = RGBLEN | HSALEN
+ *
+ * see
+ * Video mode - Blanking Packet setting
+ */
+ top = linelength << 16; /* RGBLEN */
+ bottom = 0x00000001;
+ if (pdata->flags & SH_MIPI_DSI_HSABM) /* HSALEN */
+ bottom = (pdata->lane * ch->lcd_cfg[0].hsync_len) - 10;
+ iowrite32(top | bottom , mipi->linkbase + VMLEN1);
+
+ /*
+ * VMLEN2 = HBPLEN | HFPLEN
+ *
+ * see
+ * Video mode - Blanking Packet setting
*/
- iowrite32(1 | (linelength << 16), mipi->linkbase + VMLEN1);
+ top = 0x00010000;
+ bottom = 0x00000001;
+ delay = 0;
+
+ if (pdata->flags & SH_MIPI_DSI_HFPBM) { /* HBPLEN */
+ top = ch->lcd_cfg[0].hsync_len + ch->lcd_cfg[0].left_margin;
+ top = ((pdata->lane * top) - 10) << 16;
+ }
+ if (pdata->flags & SH_MIPI_DSI_HBPBM) { /* HFPLEN */
+ bottom = ch->lcd_cfg[0].right_margin;
+ bottom = (pdata->lane * bottom) - 12;
+ }
+
+ bpp = linelength / ch->lcd_cfg[0].xres; /* byte / pixel */
+ if (pdata->lane > bpp) {
+ tmp = ch->lcd_cfg[0].xres / bpp; /* output cycle */
+ tmp = ch->lcd_cfg[0].xres - tmp; /* (input - output) cycle */
+ delay = (pdata->lane * tmp);
+ }
+
+ iowrite32(top | (bottom + delay) , mipi->linkbase + VMLEN2);
msleep(5);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 05/10] fbdev: sh_mipi_dsi: add sync_pulses/sync_events/burst mode
From: Kuninori Morimoto @ 2011-09-09 10:27 UTC (permalink / raw)
To: linux-sh
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
arch/arm/mach-shmobile/board-ag5evm.c | 3 ++-
arch/arm/mach-shmobile/board-ap4evb.c | 1 +
arch/arm/mach-shmobile/board-kota2.c | 2 +-
drivers/video/sh_mipi_dsi.c | 9 ++++++++-
include/video/sh_mipi_dsi.h | 9 +++++++++
5 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ag5evm.c b/arch/arm/mach-shmobile/board-ag5evm.c
index 70beba2..87e9091 100644
--- a/arch/arm/mach-shmobile/board-ag5evm.c
+++ b/arch/arm/mach-shmobile/board-ag5evm.c
@@ -326,7 +326,8 @@ static struct sh_mipi_dsi_info mipidsi0_info = {
.lane = 2,
.vsynw_offset = 20,
.clksrc = 1,
- .flags = SH_MIPI_DSI_HSABM,
+ .flags = SH_MIPI_DSI_HSABM |
+ SH_MIPI_DSI_SYNC_PULSES_MODE,
};
static struct platform_device mipidsi0_device = {
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
index f8e3724..114fd8a 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -580,6 +580,7 @@ static struct sh_mipi_dsi_info mipidsi0_info = {
.lcd_chan = &lcdc_info.ch[0],
.lane = 2,
.vsynw_offset = 17,
+ .flags = SH_MIPI_DSI_SYNC_PULSES_MODE,
};
static struct platform_device mipidsi0_device = {
diff --git a/arch/arm/mach-shmobile/board-kota2.c b/arch/arm/mach-shmobile/board-kota2.c
index 388ce3f..a2be703 100644
--- a/arch/arm/mach-shmobile/board-kota2.c
+++ b/arch/arm/mach-shmobile/board-kota2.c
@@ -374,7 +374,7 @@ static struct sh_mipi_dsi_info mipidsi0_info = {
.flags = SH_MIPI_DSI_HSABM |
SH_MIPI_DSI_HBPBM |
SH_MIPI_DSI_HFPBM |
- SH_MIPI_DSI_BL2E,
+ SH_MIPI_DSI_SYNC_BURST_MODE,
.extra_array = sh_mipi_extra_dcs,
.extra_array_len= ARRAY_SIZE(sh_mipi_extra_dcs),
};
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index 1f49e19..3f8da95 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -158,7 +158,7 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
{
void __iomem *base = mipi->base;
struct sh_mobile_lcdc_chan_cfg *ch = pdata->lcd_chan;
- u32 pctype, datatype, pixfmt, linelength, vmctr2 = 0x00e00000, excmd;
+ u32 pctype, datatype, pixfmt, linelength, vmctr2, excmd;
u32 tmp;
bool yuv;
int i;
@@ -331,6 +331,13 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
* Non-burst mode with sync pulses: VSE and HSE are output,
* HSA period allowed, no commands in LP
*/
+ vmctr2 = 0;
+ if (pdata->flags & SH_MIPI_DSI_VSEE)
+ vmctr2 |= 1 << 23;
+ if (pdata->flags & SH_MIPI_DSI_HSEE)
+ vmctr2 |= 1 << 22;
+ if (pdata->flags & SH_MIPI_DSI_HSAE)
+ vmctr2 |= 1 << 21;
if (pdata->flags & SH_MIPI_DSI_BL2E)
vmctr2 |= 1 << 17;
if (pdata->flags & SH_MIPI_DSI_HSABM)
diff --git a/include/video/sh_mipi_dsi.h b/include/video/sh_mipi_dsi.h
index d71122d..fb3950e 100644
--- a/include/video/sh_mipi_dsi.h
+++ b/include/video/sh_mipi_dsi.h
@@ -31,6 +31,15 @@ struct sh_mobile_lcdc_chan_cfg;
#define SH_MIPI_DSI_HBPBM (1 << 1)
#define SH_MIPI_DSI_HFPBM (1 << 2)
#define SH_MIPI_DSI_BL2E (1 << 3)
+#define SH_MIPI_DSI_VSEE (1 << 4)
+#define SH_MIPI_DSI_HSEE (1 << 5)
+#define SH_MIPI_DSI_HSAE (1 << 6)
+
+#define SH_MIPI_DSI_SYNC_PULSES_MODE (SH_MIPI_DSI_VSEE | \
+ SH_MIPI_DSI_HSEE | \
+ SH_MIPI_DSI_HSAE)
+#define SH_MIPI_DSI_SYNC_EVENTS_MODE (0)
+#define SH_MIPI_DSI_SYNC_BURST_MODE (SH_MIPI_DSI_BL2E)
/*
* x000ccpp
--
1.7.4.1
^ permalink raw reply related
* [PATCH 4/10] fbdev: sh_mipi_dsi: add lane control support
From: Kuninori Morimoto @ 2011-09-09 10:26 UTC (permalink / raw)
To: linux-sh
SH MIPI DSI can use 0-4 lane
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
arch/arm/mach-shmobile/board-ag5evm.c | 1 +
arch/arm/mach-shmobile/board-ap4evb.c | 1 +
arch/arm/mach-shmobile/board-kota2.c | 1 +
drivers/video/sh_mipi_dsi.c | 10 +++++++++-
include/video/sh_mipi_dsi.h | 1 +
5 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ag5evm.c b/arch/arm/mach-shmobile/board-ag5evm.c
index ce5c251..70beba2 100644
--- a/arch/arm/mach-shmobile/board-ag5evm.c
+++ b/arch/arm/mach-shmobile/board-ag5evm.c
@@ -323,6 +323,7 @@ static struct resource mipidsi0_resources[] = {
static struct sh_mipi_dsi_info mipidsi0_info = {
.data_format = MIPI_RGB888,
.lcd_chan = &lcdc0_info.ch[0],
+ .lane = 2,
.vsynw_offset = 20,
.clksrc = 1,
.flags = SH_MIPI_DSI_HSABM,
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
index 9e0856b..f8e3724 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -578,6 +578,7 @@ static struct resource mipidsi0_resources[] = {
static struct sh_mipi_dsi_info mipidsi0_info = {
.data_format = MIPI_RGB888,
.lcd_chan = &lcdc_info.ch[0],
+ .lane = 2,
.vsynw_offset = 17,
};
diff --git a/arch/arm/mach-shmobile/board-kota2.c b/arch/arm/mach-shmobile/board-kota2.c
index 913176e..388ce3f 100644
--- a/arch/arm/mach-shmobile/board-kota2.c
+++ b/arch/arm/mach-shmobile/board-kota2.c
@@ -368,6 +368,7 @@ static u32 sh_mipi_extra_dcs[] = {
static struct sh_mipi_dsi_info mipidsi0_info = {
.data_format = MIPI_RGB888,
.lcd_chan = &lcdc0_info.ch[0],
+ .lane = 2,
.vsynw_offset = 20,
.clksrc = 1,
.flags = SH_MIPI_DSI_HSABM |
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index d24ba7e..5f4bff6 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
+#include <linux/bitmap.h>
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/init.h>
@@ -158,6 +159,7 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
void __iomem *base = mipi->base;
struct sh_mobile_lcdc_chan_cfg *ch = pdata->lcd_chan;
u32 pctype, datatype, pixfmt, linelength, vmctr2 = 0x00e00000, excmd;
+ u32 tmp;
bool yuv;
int i;
@@ -260,6 +262,9 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
(!yuv && ch->interface_type != RGB24))
return -EINVAL;
+ if (!pdata->lane)
+ return -EINVAL;
+
/* reset DSI link */
iowrite32(0x00000001, base + SYSCTRL);
/* Hold reset for 100 cycles of the slowest of bus, HS byte and LP clock */
@@ -276,7 +281,10 @@ static int __init sh_mipi_setup(struct sh_mipi *mipi,
* ECC check enable
* additionally enable first two lanes
*/
- iowrite32(0x00003703, base + SYSCONF);
+ bitmap_fill((unsigned long *)&tmp, pdata->lane);
+ tmp |= 0x00003700;
+ iowrite32(tmp, base + SYSCONF);
+
/*
* T_wakeup = 0x7000
* T_hs-trail = 3
diff --git a/include/video/sh_mipi_dsi.h b/include/video/sh_mipi_dsi.h
index e52097a..d71122d 100644
--- a/include/video/sh_mipi_dsi.h
+++ b/include/video/sh_mipi_dsi.h
@@ -46,6 +46,7 @@ struct sh_mobile_lcdc_chan_cfg;
struct sh_mipi_dsi_info {
enum sh_mipi_dsi_data_fmt data_format;
struct sh_mobile_lcdc_chan_cfg *lcd_chan;
+ int lane;
unsigned long flags;
u32 clksrc;
unsigned int vsynw_offset;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 03/10] fbdev: sh_mobile_lcdcfb: bugfix LDHAJR :: HSYNPAJ needs mask
From: Kuninori Morimoto @ 2011-09-09 10:26 UTC (permalink / raw)
To: linux-sh
LDHAJR register will be broken by hsync_pos without this patch
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
drivers/video/sh_mobile_lcdcfb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index b048417..8cda40c 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -459,7 +459,7 @@ static void sh_mobile_lcdc_geometry(struct sh_mobile_lcdc_chan *ch)
tmp = ((display_var->xres & 7) << 24) |
((display_h_total & 7) << 16) |
((display_var->hsync_len & 7) << 8) |
- hsync_pos;
+ (hsync_pos & 7);
lcdc_write_chan(ch, LDHAJR, tmp);
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH 02/10] fbdev: sh_mipi_dsi: tidyup dsip_clk
From: Kuninori Morimoto @ 2011-09-09 10:25 UTC (permalink / raw)
To: linux-sh
dsipck clock is controled by CLKDEV_ICK_ID() in clock-shxxx.
dsi0p_clk/dsi1p_clk naming is not needed.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
arch/arm/mach-shmobile/clock-sh7372.c | 4 ++--
arch/arm/mach-shmobile/clock-sh73a0.c | 4 ++--
drivers/video/sh_mipi_dsi.c | 4 +---
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-shmobile/clock-sh7372.c b/arch/arm/mach-shmobile/clock-sh7372.c
index 6b1619a..c2702b5 100644
--- a/arch/arm/mach-shmobile/clock-sh7372.c
+++ b/arch/arm/mach-shmobile/clock-sh7372.c
@@ -604,8 +604,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_CON_ID("hdmi_clk", &div6_reparent_clks[DIV6_HDMI]),
CLKDEV_ICK_ID("dsit_clk", "sh-mipi-dsi.0", &div6_clks[DIV6_DSIT]),
CLKDEV_ICK_ID("dsit_clk", "sh-mipi-dsi.1", &div6_clks[DIV6_DSIT]),
- CLKDEV_ICK_ID("dsi0p_clk", "sh-mipi-dsi.0", &div6_clks[DIV6_DSI0P]),
- CLKDEV_ICK_ID("dsi1p_clk", "sh-mipi-dsi.1", &div6_clks[DIV6_DSI1P]),
+ CLKDEV_ICK_ID("dsip_clk", "sh-mipi-dsi.0", &div6_clks[DIV6_DSI0P]),
+ CLKDEV_ICK_ID("dsip_clk", "sh-mipi-dsi.1", &div6_clks[DIV6_DSI1P]),
/* MSTP32 clocks */
CLKDEV_DEV_ID("i2c-sh_mobile.2", &mstp_clks[MSTP001]), /* IIC2 */
diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index a2c572e..80cb438 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -320,8 +320,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_CON_ID("sdhi2_clk", &div6_clks[DIV6_SDHI2]),
CLKDEV_ICK_ID("dsit_clk", "sh-mipi-dsi.0", &div6_clks[DIV6_DSIT]),
CLKDEV_ICK_ID("dsit_clk", "sh-mipi-dsi.1", &div6_clks[DIV6_DSIT]),
- CLKDEV_ICK_ID("dsi0p_clk", "sh-mipi-dsi.0", &div6_clks[DIV6_DSI0P]),
- CLKDEV_ICK_ID("dsi1p_clk", "sh-mipi-dsi.1", &div6_clks[DIV6_DSI1P]),
+ CLKDEV_ICK_ID("dsip_clk", "sh-mipi-dsi.0", &div6_clks[DIV6_DSI0P]),
+ CLKDEV_ICK_ID("dsip_clk", "sh-mipi-dsi.1", &div6_clks[DIV6_DSI1P]),
/* MSTP32 clocks */
CLKDEV_DEV_ID("i2c-sh_mobile.2", &mstp_clks[MSTP001]), /* I2C2 */
diff --git a/drivers/video/sh_mipi_dsi.c b/drivers/video/sh_mipi_dsi.c
index bdf687d..d24ba7e 100644
--- a/drivers/video/sh_mipi_dsi.c
+++ b/drivers/video/sh_mipi_dsi.c
@@ -388,7 +388,6 @@ static int __init sh_mipi_probe(struct platform_device *pdev)
struct resource *res2 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
unsigned long rate, f_current;
int idx = pdev->id, ret;
- char dsip_clk[] = "dsi.p_clk";
if (!res || !res2 || idx >= ARRAY_SIZE(mipi_dsi) || !pdata)
return -ENODEV;
@@ -453,8 +452,7 @@ static int __init sh_mipi_probe(struct platform_device *pdev)
dev_dbg(&pdev->dev, "DSI-T clk %lu -> %lu\n", f_current, rate);
- sprintf(dsip_clk, "dsi%1.1dp_clk", idx);
- mipi->dsip_clk = clk_get(&pdev->dev, dsip_clk);
+ mipi->dsip_clk = clk_get(&pdev->dev, "dsip_clk");
if (IS_ERR(mipi->dsip_clk)) {
ret = PTR_ERR(mipi->dsip_clk);
goto eclkpget;
--
1.7.4.1
^ permalink raw reply related
* [PATCH 01/10] ARM: mach-shmobile: clock-sh73a0: add LCDC1 clock support
From: Kuninori Morimoto @ 2011-09-09 10:25 UTC (permalink / raw)
To: linux-sh
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
arch/arm/mach-shmobile/clock-sh73a0.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index 84fd33c..a2c572e 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -263,7 +263,7 @@ static struct clk div6_clks[DIV6_NR] = {
};
enum { MSTP001,
- MSTP129, MSTP128, MSTP127, MSTP126, MSTP125, MSTP118, MSTP116, MSTP100,
+ MSTP129, MSTP128, MSTP127, MSTP126, MSTP125, MSTP118, MSTP117, MSTP116, MSTP100,
MSTP219,
MSTP207, MSTP206, MSTP204, MSTP203, MSTP202, MSTP201, MSTP200,
MSTP331, MSTP329, MSTP325, MSTP323, MSTP318,
@@ -282,6 +282,7 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP126] = MSTP(&div4_clks[DIV4_B], SMSTPCR1, 26, 0), /* CSI2-RX0 */
[MSTP125] = MSTP(&div6_clks[DIV6_SUB], SMSTPCR1, 25, 0), /* TMU0 */
[MSTP118] = MSTP(&div4_clks[DIV4_B], SMSTPCR1, 18, 0), /* DSITX0 */
+ [MSTP117] = MSTP(&div4_clks[DIV4_B], SMSTPCR1, 17, 0), /* LCDC1 */
[MSTP116] = MSTP(&div4_clks[DIV4_HP], SMSTPCR1, 16, 0), /* IIC0 */
[MSTP100] = MSTP(&div4_clks[DIV4_B], SMSTPCR1, 0, 0), /* LCDC0 */
[MSTP219] = MSTP(&div6_clks[DIV6_SUB], SMSTPCR2, 19, 0), /* SCIFA7 */
@@ -331,6 +332,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh_tmu.0", &mstp_clks[MSTP125]), /* TMU00 */
CLKDEV_DEV_ID("sh_tmu.1", &mstp_clks[MSTP125]), /* TMU01 */
CLKDEV_DEV_ID("sh-mipi-dsi.0", &mstp_clks[MSTP118]), /* DSITX */
+ CLKDEV_DEV_ID("sh_mobile_lcdc_fb.1", &mstp_clks[MSTP117]), /* LCDC1 */
CLKDEV_DEV_ID("i2c-sh_mobile.0", &mstp_clks[MSTP116]), /* I2C0 */
CLKDEV_DEV_ID("sh_mobile_lcdc_fb.0", &mstp_clks[MSTP100]), /* LCDC0 */
CLKDEV_DEV_ID("sh-sci.7", &mstp_clks[MSTP219]), /* SCIFA7 */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/10] ARM: mach-shmobile: sh_mipi_dsi: update patches
From: kuninori.morimoto.gx @ 2011-09-09 10:18 UTC (permalink / raw)
To: linux-sh
Dear Paul, Magnus, and SH-ML members
These are sh_mipi_dsi update patches.
Kuninori Morimoto (10):
ARM: mach-shmobile: clock-sh73a0: add LCDC1 clock support
fbdev: sh_mipi_dsi: tidyup dsip_clk
fbdev: sh_mobile_lcdcfb: bugfix LDHAJR :: HSYNPAJ needs mask
fbdev: sh_mipi_dsi: add lane control support
fbdev: sh_mipi_dsi: add sync_pulses/sync_events/burst mode
fbdev: sh_mipi_dsi: add VMLEN1/VMLEN2 calculation
sh: clkfwk: add clk_rate_multi_range_round()
ARM: mach-shmobile: clock-sh7372: remove un-necessary index
fbdev: sh_mipi_dsi: add set_dot_clock() for each platform
ARM: mach-shmobile: clock-sh73a0: add DSIxPHY clock support
Some register are not explained for detail in SH manual.
This time, I asked it to Renesas MIPI guys.
These patches include it.
I added new clock support for sh73a0.
These are tested on kota2, ag5evm panel.
It needs test on AP4-QHD panel. (I don't have it)
^ permalink raw reply
* Re:Hello Dear
From: Wenzhou Ourvis @ 2011-09-09 2:20 UTC (permalink / raw)
To: Recipients
Dear E-mail User,
This is to immediately inform you that your email address with Micros ID:
IDJT-32238-EHI-676GI-8ED has won you £ 2,485,000.00 GBP and a brand new Range Rover SUV
from the Wenzhou Ourvis yearly draw promo.
Use the details below to login and fill in the claim form to immediately begin your claims.
WEBSITE: www.wenz-houviss.c.la
USERNAME: APEX07WIZ
PASSWORD: IEP2011JK
Regards,
Dr. Warren Payne,
Wenzhou Ourvis Company.
European Zonal Coordinator,
United Kingdom.
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only
From: Vinod Koul @ 2011-09-08 19:43 UTC (permalink / raw)
To: Paul Mundt
Cc: vinod.koul, g.liakhovetski@gmx.de, Williams, Dan J,
magnus.damm@gmail.com, linux-sh@vger.kernel.org,
linux-kernel@vger.kernel.org, damm@opensource.se
In-Reply-To: <20110908012119.GJ22142@linux-sh.org>
On Thu, 2011-09-08 at 10:21 +0900, Paul Mundt wrote:
> On Thu, Sep 08, 2011 at 03:07:53AM +0530, Koul, Vinod wrote:
> > On Wed, 2011-09-07 at 22:01 +0200, Guennadi Liakhovetski wrote:
> > > On Thu, 8 Sep 2011, Koul, Vinod wrote:
> > > You're seriously suggesting to export and use an additional shdma private
> > > function, bypassing the dmaengine API?... That really doesn't sound like a
> > > good idea to me, sorry. How about using .device_control(DMA_SLAVE_CONFIG)
> > > from the filter function directly to verify channel suitability?
> > Yes see stedma40, coh90138 drivers
> > .device_control is not right place as channel is already allocated.
> >
>
> No, that's not going to happen either. Many of these drivers are used in
> different CPUs with different DMACs. The dmaengine driver in question
> only applies to a subset, so the driver bits need to be wholly generic.
> In short, if the dmaengine API can't handle this sort of stuff then it's
> the dmaengine API that needs to be extended, we won't be working around
> dmaengine shortcomings in drivers that simply want a sensible DMA API to
> plug in to.The only thing lacking in dmaengine API is proper filtering for slave
usages where channel/controller is matches to specfic dmac slave.
There was a proposal by Linux W, and Jassi Brar for solving this
problem, and I think that should solve above problem.
I relooked at the patch, since the filtering is already done in
your .alloc_chan_resources, (which should be fixed when we fix
filtering), I am going to apply this patch
^ permalink raw reply
* Re: Ecovec (SH7724) board doesn't work on latest linus tree
From: Nobuhiro Iwamatsu @ 2011-09-08 8:52 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <w3pvcwf5xuu.wl%kuninori.morimoto.gx@renesas.com>
Hi,
Your patch does not seem to have a meaning.
In the case of 29bit, CAC/UNCAC_ADDR may not return a right address.
I think that it is to use P1SEGADDR, and P2SEGADDR in CAC/UNCAC_ADDR
to easily revise this.
I attached my patch.
Best regards,
Nobuhiro
From b1f83e75a2dc5a61671d18e8f472450561c9eea7 Mon Sep 17 00:00:00 2001
From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Date: Thu, 8 Sep 2011 17:37:24 +0900
Subject: [PATCH] sh: Fix address calculation of CAC_ADDR and
UNCAC_ADDR in 29bit mode
In the case of 29bit mode, CAC/UNCAC_ADDR does not return a right address.
This revises this problem by using P1SEGADDR and P2SEGADDR in 29bit mode.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
arch/sh/include/asm/page.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/sh/include/asm/page.h b/arch/sh/include/asm/page.h
index 822d608..abcc4dc 100644
--- a/arch/sh/include/asm/page.h
+++ b/arch/sh/include/asm/page.h
@@ -141,8 +141,13 @@ typedef struct page *pgtable_t;
#endif /* !__ASSEMBLY__ */
#ifdef CONFIG_UNCACHED_MAPPING
+#if defined(CONFIG_29BIT)
+#define UNCAC_ADDR(addr) P2SEGADDR(addr)
+#define CAC_ADDR(addr) P1SEGADDR(addr)
+#else
#define UNCAC_ADDR(addr) ((addr) - PAGE_OFFSET + uncached_start)
#define CAC_ADDR(addr) ((addr) - uncached_start + PAGE_OFFSET)
+#endif
#else
#define UNCAC_ADDR(addr) ((addr))
#define CAC_ADDR(addr) ((addr))
--
1.7.5.4
2011/9/1 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
>
> Hi Ebihara-san, and Paul
>
> Thank you for your report.
>
>> i think you can run linux-3.0.4 kernel on your Ecovec (SH7724) board
>> in this debug-code.
>>
>>
>> void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
>> enum dma_data_direction direction)
>> {
>> void *addr;
>>
>> addr = __in_29bit_mode() ?
>> - (void *)CAC_ADDR((unsigned long)vaddr) : vaddr;
>> + (void *)P1SEGADDR((unsigned long)vaddr) : vaddr;
>
> Paul
>
> I guess your patch tried to share code for sh32/sh64.
> and CAC_ADDR() should be equal P1SEGADDR(), correct ?
>
> I'm not filmier with memory control, but
> on Ecovec case, 1st (and crash case) dma_cache_sync() caller is
> ${LINUX}/arch/sh/mm/consistent.c :: dma_generic_alloc_coherent()
>
> it tried
>
> ret = (void *)__get_free_pages(gfp, order);
> (snip)
> dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
>
> This "ret" is "8e000000" for now.
>
> but CAC_ADDR(xx)/P1SEGADDR(xx) is defined as below
>
> CAC_ADDR(addr) ((addr) - uncached_start + PAGE_OFFSET)
> P1SEGADDR(a) ((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | P1SEG))
>
> I guess this "ret" should be uncached area if dma_cache_sync(xx) use CAC_ADDR(xx).
>
> If I apply below patch, Ecovec start works without crash, but I'm not sure.
> Is this correct patch ?
>
> --------------------
> diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
> index f251b5f..198234a 100644
> --- a/arch/sh/mm/consistent.c
> +++ b/arch/sh/mm/consistent.c
> @@ -48,7 +48,7 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t si
> * Pages from the page allocator may have data present in
> * cache. So flush the cache before using uncached memory.
> */
> - dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
> + dma_cache_sync(dev, UNCAC_ADDR(ret), size, DMA_BIDIRECTIONAL);
>
> ret_nocache = (void __force *)ioremap_nocache(virt_to_phys(ret), size);
> if (!ret_nocache) {
> -------------------------
>
> But I'm afraid below comment of dma_generic_alloc_coherent()
>
> /*
> * Pages from the page allocator may have data present in
> * cache. So flush the cache before using uncached memory.
> */
> dma_cache_sync(dev, ret, size, DMA_BIDIRECTIONAL);
>
>
> Best regards
> ---
> Kuninori Morimoto
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Nobuhiro Iwamatsu
^ permalink raw reply related
* Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only channel ID
From: Paul Mundt @ 2011-09-08 1:21 UTC (permalink / raw)
To: Koul, Vinod
Cc: g.liakhovetski@gmx.de, Williams, Dan J, magnus.damm@gmail.com,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
damm@opensource.se
In-Reply-To: <438BB0150E931F4B9CE701519A4463010871804A4F@bgsmsx502.gar.corp.intel.com>
On Thu, Sep 08, 2011 at 03:07:53AM +0530, Koul, Vinod wrote:
> On Wed, 2011-09-07 at 22:01 +0200, Guennadi Liakhovetski wrote:
> > On Thu, 8 Sep 2011, Koul, Vinod wrote:
> > You're seriously suggesting to export and use an additional shdma private
> > function, bypassing the dmaengine API?... That really doesn't sound like a
> > good idea to me, sorry. How about using .device_control(DMA_SLAVE_CONFIG)
> > from the filter function directly to verify channel suitability?
> Yes see stedma40, coh90138 drivers
> .device_control is not right place as channel is already allocated.
>
No, that's not going to happen either. Many of these drivers are used in
different CPUs with different DMACs. The dmaengine driver in question
only applies to a subset, so the driver bits need to be wholly generic.
In short, if the dmaengine API can't handle this sort of stuff then it's
the dmaengine API that needs to be extended, we won't be working around
dmaengine shortcomings in drivers that simply want a sensible DMA API to
plug in to.
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only
From: Koul, Vinod @ 2011-09-07 21:49 UTC (permalink / raw)
To: g.liakhovetski@gmx.de
Cc: Williams, Dan J, magnus.damm@gmail.com, lethal@linux-sh.org,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
damm@opensource.se
In-Reply-To: <alpine.DEB.2.00.1109072048310.30407@axis700.grange>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1352 bytes --]
On Wed, 2011-09-07 at 22:01 +0200, Guennadi Liakhovetski wrote:
> On Thu, 8 Sep 2011, Koul, Vinod wrote:
> You're seriously suggesting to export and use an additional shdma private
> function, bypassing the dmaengine API?... That really doesn't sound like a
> good idea to me, sorry. How about using .device_control(DMA_SLAVE_CONFIG)
> from the filter function directly to verify channel suitability?
Yes see stedma40, coh90138 drivers
.device_control is not right place as channel is already allocated.
You are basically moving filter fn from all clients to dmac driver.
>
> > I cant agree to the whole point of filtering in alloc
> >
> > One channel is allocated, we should _not_ do any further filtering
>
> Sorry, I do not understand this argumentation. Filtering and resource
> allocation are parts of the channel-acquisition process, either of them
> can fail, in which case the channel remains free for future requests.
DMA drivers set caps for each channel
Client requests a channel and dmaengine matches channel based on caps
and filer function is called so that additional filtering can take
place.
And .alloc_chan_resources is supposed to allocate the channel resource
and not do anything else.
--
~Vinod
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þÈÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only
From: Guennadi Liakhovetski @ 2011-09-07 20:01 UTC (permalink / raw)
To: Koul, Vinod
Cc: Williams, Dan J, magnus.damm@gmail.com, lethal@linux-sh.org,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
damm@opensource.se
In-Reply-To: <438BB0150E931F4B9CE701519A4463010871804A4B@bgsmsx502.gar.corp.intel.com>
On Thu, 8 Sep 2011, Koul, Vinod wrote:
> On Mon, 2011-09-05 at 17:21 +0200, Guennadi Liakhovetski wrote:
> > On Mon, 5 Sep 2011, Vinod Koul wrote:
> >
> > > On Mon, 2011-09-05 at 17:01 +0200, Guennadi Liakhovetski wrote:
> > > > On Mon, 5 Sep 2011, Vinod Koul wrote:
> > > >
> > > > > On Mon, 2011-09-05 at 15:48 +0200, Guennadi Liakhovetski wrote:
> > > > > >
> > > > > > Let me try again. DMA channels on these DMA controllers are not dedicated.
> > > > > > On one such SoC there can be several such DMA controllers of different
> > > > > > kinds. One kind is "generic" - it can do memcpy(), besides channels can be
> > > > > > freely configured for one of onboard peripherals: serial, mmc, etc. Some
> > > > > > of them can also serve external DMA-capable devices. Another kind of DMA
> > > > > > controllers, served by the same driver, can only be used with USB
> > > > > > controllers. Now, if the MMC driver requests a DMA channel, let's say, the
> > > > > > dmaengine core first finds the USB DMA controller. The MMC driver cannot
> > > > > > know this. It assigns its MMC DMA configuration to the.private pointer and
> > > > > > returns true. Next the DMA driver is entered, it checks the private
> > > > > > pointer, sees an MMC channel request, looks at the DMA controller and
> > > > > > sees, that it doesn't support MMC. So, .device_alloc_chan_resources()
> > > > > > fails. When the same is attempted with a suitable DMA controller, the
> > > > > > shdma driver recognises, that the controller can service MMC and uses the
> > > > > > data, provided the MMC driver, to configure the DMA channel for MMC.
> > > > > Hmmm, Can't you know in filter function if the respective channel can do
> > > > > the dma for you or not? Maybe export a dma function or use platform data
> > > > > for this (wont you soc have these caps fixed), i prefer latter.
> > > > > That maybe a better approach.
> > > >
> > > > How? On a system you can have 3 suitable DMA controllers and 2 unsuitable.
> > > > Do you want to pass a list of 3 suitable DMA controllers to each
> > > > peripheral driver?...
> > > The peripheral driver (client driver in slave-dma terminology) should
> > > already know which dmac it wants. (base on information in platform data
> > > etc) That is why the filter function is provided. Please use it properly
> > > Other soc have similar capabilities and they can filter properly so why
> > > cant you..?
> >
> > Sorry, I have been thinking about these possibilities, but I really didn't
> > find any similar case in existing drivers. Normally either channels are
> > fixed - only one channel can be used for a specific peripheral, or any at
> > all, or there is only one suitable controller. I only see two
> > possibilities here, and they both look ugly to me:
> >
> > (1) pass a list of suitable DMA controllers to slave-dma drivers, there in
> > the filter you'd have to scan that list.
> > (2) select only one out of several suitable DMA controllers in the
> > platform configuration - that needlessly reduces flexibility.
> >
> > Whereas on the contrary, the DMA controller itself can perfectly look
> > through the list of supported peripherals on the current controller and
> > decide, whether the requested one is among them or not.
> Then why not have shdma_filter_func() exported and then used by all your
> clients for proper filtering.
You're seriously suggesting to export and use an additional shdma private
function, bypassing the dmaengine API?... That really doesn't sound like a
good idea to me, sorry. How about using .device_control(DMA_SLAVE_CONFIG)
from the filter function directly to verify channel suitability?
> I cant agree to the whole point of filtering in alloc
>
> One channel is allocated, we should _not_ do any further filtering
Sorry, I do not understand this argumentation. Filtering and resource
allocation are parts of the channel-acquisition process, either of them
can fail, in which case the channel remains free for future requests.
Thanks
Guennadi
> > > PS: This might well be my last post before Tue EOD PST, traveling to
> > > LPC, if you are there feel free to chat with me on this.
> >
> > No, unfortunately, I won#t be there. Are you coming to the KS in Prague in
> > October?
> Not decided yet...
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] serial: sh-sci: don't filter on DMA device, use only
From: Koul, Vinod @ 2011-09-07 18:54 UTC (permalink / raw)
To: g.liakhovetski@gmx.de
Cc: Williams, Dan J, magnus.damm@gmail.com, lethal@linux-sh.org,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
damm@opensource.se
In-Reply-To: <Pine.LNX.4.64.1109051716530.1112@axis700.grange>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 3749 bytes --]
On Mon, 2011-09-05 at 17:21 +0200, Guennadi Liakhovetski wrote:
> On Mon, 5 Sep 2011, Vinod Koul wrote:
>
> > On Mon, 2011-09-05 at 17:01 +0200, Guennadi Liakhovetski wrote:
> > > On Mon, 5 Sep 2011, Vinod Koul wrote:
> > >
> > > > On Mon, 2011-09-05 at 15:48 +0200, Guennadi Liakhovetski wrote:
> > > > >
> > > > > Let me try again. DMA channels on these DMA controllers are not dedicated.
> > > > > On one such SoC there can be several such DMA controllers of different
> > > > > kinds. One kind is "generic" - it can do memcpy(), besides channels can be
> > > > > freely configured for one of onboard peripherals: serial, mmc, etc. Some
> > > > > of them can also serve external DMA-capable devices. Another kind of DMA
> > > > > controllers, served by the same driver, can only be used with USB
> > > > > controllers. Now, if the MMC driver requests a DMA channel, let's say, the
> > > > > dmaengine core first finds the USB DMA controller. The MMC driver cannot
> > > > > know this. It assigns its MMC DMA configuration to the.private pointer and
> > > > > returns true. Next the DMA driver is entered, it checks the private
> > > > > pointer, sees an MMC channel request, looks at the DMA controller and
> > > > > sees, that it doesn't support MMC. So, .device_alloc_chan_resources()
> > > > > fails. When the same is attempted with a suitable DMA controller, the
> > > > > shdma driver recognises, that the controller can service MMC and uses the
> > > > > data, provided the MMC driver, to configure the DMA channel for MMC.
> > > > Hmmm, Can't you know in filter function if the respective channel can do
> > > > the dma for you or not? Maybe export a dma function or use platform data
> > > > for this (wont you soc have these caps fixed), i prefer latter.
> > > > That maybe a better approach.
> > >
> > > How? On a system you can have 3 suitable DMA controllers and 2 unsuitable.
> > > Do you want to pass a list of 3 suitable DMA controllers to each
> > > peripheral driver?...
> > The peripheral driver (client driver in slave-dma terminology) should
> > already know which dmac it wants. (base on information in platform data
> > etc) That is why the filter function is provided. Please use it properly
> > Other soc have similar capabilities and they can filter properly so why
> > cant you..?
>
> Sorry, I have been thinking about these possibilities, but I really didn't
> find any similar case in existing drivers. Normally either channels are
> fixed - only one channel can be used for a specific peripheral, or any at
> all, or there is only one suitable controller. I only see two
> possibilities here, and they both look ugly to me:
>
> (1) pass a list of suitable DMA controllers to slave-dma drivers, there in
> the filter you'd have to scan that list.
> (2) select only one out of several suitable DMA controllers in the
> platform configuration - that needlessly reduces flexibility.
>
> Whereas on the contrary, the DMA controller itself can perfectly look
> through the list of supported peripherals on the current controller and
> decide, whether the requested one is among them or not.
Then why not have shdma_filter_func() exported and then used by all your
clients for proper filtering.
I cant agree to the whole point of filtering in alloc
One channel is allocated, we should _not_ do any further filtering
>
> > PS: This might well be my last post before Tue EOD PST, traveling to
> > LPC, if you are there feel free to chat with me on this.
>
> No, unfortunately, I won#t be there. Are you coming to the KS in Prague in
> October?
Not decided yet...
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þÈÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á
^ permalink raw reply
* Re: [PATCH 1/2] SPI: spi_sh_msiof: implement DMA support
From: Magnus Damm @ 2011-09-06 22:16 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: Paul Mundt, spi-devel-general, linux-sh
In-Reply-To: <Pine.LNX.4.64.1109050925170.13066@axis700.grange>
On Mon, Sep 5, 2011 at 4:26 PM, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> On Mon, 5 Sep 2011, Paul Mundt wrote:
>> On Fri, Sep 02, 2011 at 05:13:31PM +0200, Guennadi Liakhovetski wrote:
>> > Use the sh_dma dmaengine driver to support DMA on MSIOF.
>> >
>> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> > @@ -695,11 +1030,11 @@ static int sh_msiof_spi_remove(struct platform_device *pdev)
>> >
>> > ret = spi_bitbang_stop(&p->bitbang);
>> > if (!ret) {
>> > + sh_msiof_release_dma(p);
>> > pm_runtime_disable(&pdev->dev);
>> > free_irq(platform_get_irq(pdev, 0), p);
>> > iounmap(p->mapbase);
>> > clk_put(p->clk);
>> > - spi_master_put(p->bitbang.master);
>> > }
>> > return ret;
>> > }
>>
>> You've also killed off the spi_master_put() here.
>
> Yes, spi_bitbang_stop() does it all already.
So it's a bug fix built-in to a feature patch? If so, please break out
and submit as a fix.
Thanks,
/ magnus
^ permalink raw reply
* Re: [PATCH v2 0/8] sh_mobile_lcdc: Support format changes at runtime
From: Laurent Pinchart @ 2011-09-06 8:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1314788459-31791-1-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Florian,
On Monday 05 September 2011 19:19:08 Florian Tobias Schandinat wrote:
> On 08/31/2011 11:00 AM, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > Here's the second version of the .fb_set_par() support for the
> > sh_mobile_lcdc driver patch set. It allows userspace to change the frame
> > buffer format and size at runtime. The patches apply on top of Florian's
> > fbdev-next branch available at
> > git://github.com/schandinat/linux-2.6.git.
> >
> > Compared to v1, this version includes an additional MERAM fix.
> >
> > Frame buffer memory reallocation is currently not supported. You will
> > need to make sure platform data sets the maximum size and bpp to high
> > enough values for all formats and sizes you want to support at runtime.
>
> As you've asked me in
> "[PULL] SH mobile LCDC cleanups and fixes"
> I've applied this series as it looks okay to me.
Thank you.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 0/8] sh_mobile_lcdc: Support format changes at runtime
From: Florian Tobias Schandinat @ 2011-09-05 17:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1314788459-31791-1-git-send-email-laurent.pinchart@ideasonboard.com>
Hi Laurent,
On 08/31/2011 11:00 AM, Laurent Pinchart wrote:
> Hi everybody,
>
> Here's the second version of the .fb_set_par() support for the sh_mobile_lcdc
> driver patch set. It allows userspace to change the frame buffer format and
> size at runtime. The patches apply on top of Florian's fbdev-next branch
> available at git://github.com/schandinat/linux-2.6.git.
>
> Compared to v1, this version includes an additional MERAM fix.
>
> Frame buffer memory reallocation is currently not supported. You will need to
> make sure platform data sets the maximum size and bpp to high enough values
> for all formats and sizes you want to support at runtime.
As you've asked me in
"[PULL] SH mobile LCDC cleanups and fixes"
I've applied this series as it looks okay to me.
Thanks,
Florian Tobias Schandinat
>
> The patches have been tested with the fbdev-test utility
> (http://git.ideasonboard.org/?pûdev-test.git;a=summary) on a Mackerel board.
>
> Laurent Pinchart (8):
> sh_mobile_meram: Reset ICBs at unregistration time
> fbdev: sh_mobile_lcdc: Adjust requested parameters in .fb_check_var
> fbdev: sh_mobile_lcdc: Add support for format changes at runtime
> fbdev: sh_mobile_lcdc: use display information in info for panning
> fbdev: sh_mobile_lcdc: Update fix.line_length in .fb_set_par()
> fbdev: sh_mobile_lcdc: Avoid forward declarations
> fbdev: sh_mobile_lcdc: Split channel initialization from probe
> function
> fbdev: sh_mobile_lcdc: Remove sh_mobile_lcdc_set_bpp()
>
> drivers/video/sh_mobile_lcdcfb.c | 570 +++++++++++++++++++++-----------------
> drivers/video/sh_mobile_meram.c | 6 +-
> 2 files changed, 313 insertions(+), 263 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 00/03] ARM: mach-shmobile: sh7372 power domain update
From: Rafael J. Wysocki @ 2011-09-05 15:41 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <20110630094653.10442.68817.sendpatchset@t400s>
On Monday, September 05, 2011, Paul Mundt wrote:
> On Fri, Aug 26, 2011 at 03:43:16PM +0900, Magnus Damm wrote:
> > ARM: mach-shmobile: sh7372 power domain update
> >
> > [PATCH 01/03] ARM: mach-shmobile: sh7372 A3SM support
> > [PATCH 02/03] ARM: mach-shmobile: sh7372 A3SP support
> > [PATCH 03/03] ARM: mach-shmobile: sh7372 A4R support
> >
> > These patches add support for the A3SM, A3SP and A4R
> > power domains included in the sh7372 SoC. More work
> > in needed with QoS for I/O devices and CPUIdle with
> > A3SM together with future A4S power domain support.
> >
> > Testing needed, especiall WRT to Suspend-to-RAM!
> >
> > Signed-off-by: Magnus Damm <damm@opensource.se>
>
> As these don't apply against anything I have I'll assume that Rafael will
> be taking them through the pm tree with the rest of the power domains
> code.
Yes, I will.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH 3/5] PM / QoS: Add function dev_pm_qos_read_value()
From: Rafael J. Wysocki @ 2011-09-05 15:30 UTC (permalink / raw)
To: Jean Pihet
Cc: Linux PM mailing list, LKML, Linux-sh list, Magnus Damm,
Kevin Hilman
In-Reply-To: <CAORVsuXtgd6hTvpkoHobSGKrXgMB1L8dSVbkkt071useNRdngg@mail.gmail.com>
On Monday, September 05, 2011, Jean Pihet wrote:
> Hi,
>
> On Sat, Sep 3, 2011 at 10:02 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > Hi,
> >
> > On Saturday, September 03, 2011, Rafael J. Wysocki wrote:
> >> On Friday, September 02, 2011, Jean Pihet wrote:
> >> > On Fri, Sep 2, 2011 at 12:07 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > ...
> >> > >> >
> >> > >> > - mutex_lock(&dev_pm_qos_mtx);
> >> > >> > req->dev = dev;
> >> > >> >
> >> > >> > - /* Return if the device has been removed */
> >> > >> > - if (req->dev->power.constraints_state = DEV_PM_QOS_NO_DEVICE) {
> >> > >> > - ret = -ENODEV;
> >> > >> > - goto out;
> >> > >> > - }
> >> > >> > + device_pm_lock();
> >> > >> > + mutex_lock(&dev_pm_qos_mtx);
> >> > >> >
> >> > >> > - /*
> >> > >> > - * Allocate the constraints data on the first call to add_request,
> >> > >> > - * i.e. only if the data is not already allocated and if the device has
> >> > >> > - * not been removed
> >> > >> > - */
> >> > >> > - if (dev->power.constraints_state = DEV_PM_QOS_DEVICE_PRESENT)
> >> > >> > - ret = dev_pm_qos_constraints_allocate(dev);
> >> > >> > + if (dev->power.constraints) {
> >> > >> > + device_pm_unlock();
> >> > >> > + } else {
> >> > >> > + if (list_empty(&dev->power.entry)) {
> >> > >> > + /* The device has been removed from the system. */
> >> > >> > + device_pm_unlock();
> >> > >> > + goto out;
> >> > >> 0 is silently returned in case the device has been removed. Is that
> >> > >> the intention?
> >> > >
> >> > > Pretty much it is. Is that a problem?
> >> > I think the caller needs to know if the constraint has been applied
> >> > correctly or not.
> >>
> >> However, the removal of the device is a special case. What would the caller
> >> be supposed to do when it learned that the device had been removed while it had
> >> been trying to add a QoS constraing for it? Not much I guess.
> >
> > Anyway, since returning an error code in that case won't hurt either,
> > below is a v2 of the patch doing that and resetting the dev field in the
> > req structure.
> Ok thanks for the update. The comments are inlined below.
>
...
> >
> > - if (req->dev->power.constraints_state = DEV_PM_QOS_ALLOCATED) {
> > + if (req->dev->power.constraints) {
> > if (new_value != req->node.prio)
> > ret = apply_constraint(req, PM_QOS_UPDATE_REQ,
> > new_value);
> > } else {
> > /* Return if the device has been removed */
> > - ret = -ENODEV;
> > + ret = -EINVAL;
> The retcode should be -ENODEV.
Well, both -EINVAL and -ENODEV seem somewhat suitable here and I don't
have a strong preference, so I very well may leave the latter as it.
> Is the kerneldoc still OK?
It will be if the error code isn't changed.
Updated patch follows.
Thanks,
Rafael
---
From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: PM / QoS: Add function dev_pm_qos_read_value() (v2)
To read the current PM QoS value for a given device we need to
make sure that the device's power.constraints object won't be
removed while we're doing that. For this reason, put the
operation under dev->power.lock and acquire the lock
around the initialization and removal of power.constraints.
Moreover, since we're using the value of power.constraints to
determine whether or not the object is present, the
power.constraints_state field isn't necessary any more and may be
removed. However, dev_pm_qos_add_request() needs to check if the
device is being removed from the system before allocating a new
PM QoS constraints object for it, so it has to use device_pm_lock()
and the device PM QoS initialization and destruction should be done
under device_pm_lock() as well.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/base/power/main.c | 4 -
drivers/base/power/qos.c | 168 ++++++++++++++++++++++++++--------------------
include/linux/pm.h | 8 --
include/linux/pm_qos.h | 3
4 files changed, 103 insertions(+), 80 deletions(-)
Index: linux/drivers/base/power/qos.c
=================================--- linux.orig/drivers/base/power/qos.c
+++ linux/drivers/base/power/qos.c
@@ -30,15 +30,6 @@
* . To minimize the data usage by the per-device constraints, the data struct
* is only allocated at the first call to dev_pm_qos_add_request.
* . The data is later free'd when the device is removed from the system.
- * . The constraints_state variable from dev_pm_info tracks the data struct
- * allocation state:
- * DEV_PM_QOS_NO_DEVICE: No device present or device removed, no data
- * allocated,
- * DEV_PM_QOS_DEVICE_PRESENT: Device present, data not allocated and will be
- * allocated at the first call to dev_pm_qos_add_request,
- * DEV_PM_QOS_ALLOCATED: Device present, data allocated. The per-device
- * PM QoS constraints framework is operational and constraints can be
- * added, updated or removed using the dev_pm_qos_* API.
* . A global mutex protects the constraints users from the data being
* allocated and free'd.
*/
@@ -51,8 +42,30 @@
static DEFINE_MUTEX(dev_pm_qos_mtx);
+
static BLOCKING_NOTIFIER_HEAD(dev_pm_notifiers);
+/**
+ * dev_pm_qos_read_value - Get PM QoS constraint for a given device.
+ * @dev: Device to get the PM QoS constraint value for.
+ */
+s32 dev_pm_qos_read_value(struct device *dev)
+{
+ struct pm_qos_constraints *c;
+ unsigned long flags;
+ s32 ret = 0;
+
+ spin_lock_irqsave(&dev->power.lock, flags);
+
+ c = dev->power.constraints;
+ if (c)
+ ret = pm_qos_read_value(c);
+
+ spin_unlock_irqrestore(&dev->power.lock, flags);
+
+ return ret;
+}
+
/*
* apply_constraint
* @req: constraint request to apply
@@ -105,27 +118,37 @@ static int dev_pm_qos_constraints_alloca
}
BLOCKING_INIT_NOTIFIER_HEAD(n);
+ plist_head_init(&c->list);
+ c->target_value = PM_QOS_DEV_LAT_DEFAULT_VALUE;
+ c->default_value = PM_QOS_DEV_LAT_DEFAULT_VALUE;
+ c->type = PM_QOS_MIN;
+ c->notifiers = n;
+
+ spin_lock_irq(&dev->power.lock);
dev->power.constraints = c;
- plist_head_init(&dev->power.constraints->list);
- dev->power.constraints->target_value = PM_QOS_DEV_LAT_DEFAULT_VALUE;
- dev->power.constraints->default_value = PM_QOS_DEV_LAT_DEFAULT_VALUE;
- dev->power.constraints->type = PM_QOS_MIN;
- dev->power.constraints->notifiers = n;
- dev->power.constraints_state = DEV_PM_QOS_ALLOCATED;
+ spin_unlock_irq(&dev->power.lock);
return 0;
}
+static void __dev_pm_qos_constraints_init(struct device *dev)
+{
+ spin_lock_irq(&dev->power.lock);
+ dev->power.constraints = NULL;
+ spin_unlock_irq(&dev->power.lock);
+}
+
/**
- * dev_pm_qos_constraints_init
+ * dev_pm_qos_constraints_init - Initalize device's PM QoS constraints pointer.
* @dev: target device
*
- * Called from the device PM subsystem at device insertion
+ * Called from the device PM subsystem at device insertion under
+ * device_pm_lock().
*/
void dev_pm_qos_constraints_init(struct device *dev)
{
mutex_lock(&dev_pm_qos_mtx);
- dev->power.constraints_state = DEV_PM_QOS_DEVICE_PRESENT;
+ dev->power.constraints = NULL;
mutex_unlock(&dev_pm_qos_mtx);
}
@@ -133,34 +156,35 @@ void dev_pm_qos_constraints_init(struct
* dev_pm_qos_constraints_destroy
* @dev: target device
*
- * Called from the device PM subsystem at device removal
+ * Called from the device PM subsystem at device removal under device_pm_lock().
*/
void dev_pm_qos_constraints_destroy(struct device *dev)
{
struct dev_pm_qos_request *req, *tmp;
+ struct pm_qos_constraints *c;
mutex_lock(&dev_pm_qos_mtx);
- if (dev->power.constraints_state = DEV_PM_QOS_ALLOCATED) {
- /* Flush the constraints list for the device */
- plist_for_each_entry_safe(req, tmp,
- &dev->power.constraints->list,
- node) {
- /*
- * Update constraints list and call the notification
- * callbacks if needed
- */
- apply_constraint(req, PM_QOS_REMOVE_REQ,
- PM_QOS_DEFAULT_VALUE);
- memset(req, 0, sizeof(*req));
- }
+ c = dev->power.constraints;
+ if (!c)
+ goto out;
- kfree(dev->power.constraints->notifiers);
- kfree(dev->power.constraints);
- dev->power.constraints = NULL;
+ /* Flush the constraints list for the device */
+ plist_for_each_entry_safe(req, tmp, &c->list, node) {
+ /*
+ * Update constraints list and call the notification
+ * callbacks if needed
+ */
+ apply_constraint(req, PM_QOS_REMOVE_REQ, PM_QOS_DEFAULT_VALUE);
+ memset(req, 0, sizeof(*req));
}
- dev->power.constraints_state = DEV_PM_QOS_NO_DEVICE;
+ __dev_pm_qos_constraints_init(dev);
+
+ kfree(c->notifiers);
+ kfree(c);
+
+ out:
mutex_unlock(&dev_pm_qos_mtx);
}
@@ -178,8 +202,9 @@ void dev_pm_qos_constraints_destroy(stru
*
* Returns 1 if the aggregated constraint value has changed,
* 0 if the aggregated constraint value has not changed,
- * -EINVAL in case of wrong parameters, -ENODEV if the device has been
- * removed from the system
+ * -EINVAL in case of wrong parameters, -ENOMEM if there's not enough memory
+ * to allocate for data structures, -ENODEV if the device has just been removed
+ * from the system.
*/
int dev_pm_qos_add_request(struct device *dev, struct dev_pm_qos_request *req,
s32 value)
@@ -195,28 +220,37 @@ int dev_pm_qos_add_request(struct device
return -EINVAL;
}
- mutex_lock(&dev_pm_qos_mtx);
req->dev = dev;
- /* Return if the device has been removed */
- if (req->dev->power.constraints_state = DEV_PM_QOS_NO_DEVICE) {
- ret = -ENODEV;
- goto out;
- }
+ device_pm_lock();
+ mutex_lock(&dev_pm_qos_mtx);
- /*
- * Allocate the constraints data on the first call to add_request,
- * i.e. only if the data is not already allocated and if the device has
- * not been removed
- */
- if (dev->power.constraints_state = DEV_PM_QOS_DEVICE_PRESENT)
- ret = dev_pm_qos_constraints_allocate(dev);
+ if (dev->power.constraints) {
+ device_pm_unlock();
+ } else {
+ if (list_empty(&dev->power.entry)) {
+ /* The device has been removed from the system. */
+ device_pm_unlock();
+ req->dev = NULL;
+ ret = -ENODEV;
+ goto out;
+ } else {
+ device_pm_unlock();
+ /*
+ * Allocate the constraints data on the first call to
+ * add_request, i.e. only if the data is not already
+ * allocated and if the device has not been removed.
+ */
+ ret = dev_pm_qos_constraints_allocate(dev);
+ }
+ }
if (!ret)
ret = apply_constraint(req, PM_QOS_ADD_REQ, value);
-out:
+ out:
mutex_unlock(&dev_pm_qos_mtx);
+
return ret;
}
EXPORT_SYMBOL_GPL(dev_pm_qos_add_request);
@@ -252,7 +286,7 @@ int dev_pm_qos_update_request(struct dev
mutex_lock(&dev_pm_qos_mtx);
- if (req->dev->power.constraints_state = DEV_PM_QOS_ALLOCATED) {
+ if (req->dev->power.constraints) {
if (new_value != req->node.prio)
ret = apply_constraint(req, PM_QOS_UPDATE_REQ,
new_value);
@@ -293,7 +327,7 @@ int dev_pm_qos_remove_request(struct dev
mutex_lock(&dev_pm_qos_mtx);
- if (req->dev->power.constraints_state = DEV_PM_QOS_ALLOCATED) {
+ if (req->dev->power.constraints) {
ret = apply_constraint(req, PM_QOS_REMOVE_REQ,
PM_QOS_DEFAULT_VALUE);
memset(req, 0, sizeof(*req));
@@ -323,15 +357,12 @@ int dev_pm_qos_add_notifier(struct devic
mutex_lock(&dev_pm_qos_mtx);
- /* Silently return if the device has been removed */
- if (dev->power.constraints_state != DEV_PM_QOS_ALLOCATED)
- goto out;
-
- retval = blocking_notifier_chain_register(
- dev->power.constraints->notifiers,
- notifier);
+ /* Silently return if the constraints object is not present. */
+ if (dev->power.constraints)
+ retval = blocking_notifier_chain_register(
+ dev->power.constraints->notifiers,
+ notifier);
-out:
mutex_unlock(&dev_pm_qos_mtx);
return retval;
}
@@ -354,15 +385,12 @@ int dev_pm_qos_remove_notifier(struct de
mutex_lock(&dev_pm_qos_mtx);
- /* Silently return if the device has been removed */
- if (dev->power.constraints_state != DEV_PM_QOS_ALLOCATED)
- goto out;
-
- retval = blocking_notifier_chain_unregister(
- dev->power.constraints->notifiers,
- notifier);
+ /* Silently return if the constraints object is not present. */
+ if (dev->power.constraints)
+ retval = blocking_notifier_chain_unregister(
+ dev->power.constraints->notifiers,
+ notifier);
-out:
mutex_unlock(&dev_pm_qos_mtx);
return retval;
}
Index: linux/include/linux/pm_qos.h
=================================--- linux.orig/include/linux/pm_qos.h
+++ linux/include/linux/pm_qos.h
@@ -77,6 +77,7 @@ int pm_qos_remove_notifier(int pm_qos_cl
int pm_qos_request_active(struct pm_qos_request *req);
s32 pm_qos_read_value(struct pm_qos_constraints *c);
+s32 dev_pm_qos_read_value(struct device *dev);
int dev_pm_qos_add_request(struct device *dev, struct dev_pm_qos_request *req,
s32 value);
int dev_pm_qos_update_request(struct dev_pm_qos_request *req, s32 new_value);
@@ -117,6 +118,8 @@ static inline int pm_qos_request_active(
static inline s32 pm_qos_read_value(struct pm_qos_constraints *c)
{ return 0; }
+static inline s32 dev_pm_qos_read_value(struct device *dev)
+ { return 0; }
static inline int dev_pm_qos_add_request(struct device *dev,
struct dev_pm_qos_request *req,
s32 value)
Index: linux/drivers/base/power/main.c
=================================--- linux.orig/drivers/base/power/main.c
+++ linux/drivers/base/power/main.c
@@ -98,8 +98,8 @@ void device_pm_add(struct device *dev)
dev_warn(dev, "parent %s should not be sleeping\n",
dev_name(dev->parent));
list_add_tail(&dev->power.entry, &dpm_list);
- mutex_unlock(&dpm_list_mtx);
dev_pm_qos_constraints_init(dev);
+ mutex_unlock(&dpm_list_mtx);
}
/**
@@ -110,9 +110,9 @@ void device_pm_remove(struct device *dev
{
pr_debug("PM: Removing info for %s:%s\n",
dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
- dev_pm_qos_constraints_destroy(dev);
complete_all(&dev->power.completion);
mutex_lock(&dpm_list_mtx);
+ dev_pm_qos_constraints_destroy(dev);
list_del_init(&dev->power.entry);
mutex_unlock(&dpm_list_mtx);
device_wakeup_disable(dev);
Index: linux/include/linux/pm.h
=================================--- linux.orig/include/linux/pm.h
+++ linux/include/linux/pm.h
@@ -421,13 +421,6 @@ enum rpm_request {
RPM_REQ_RESUME,
};
-/* Per-device PM QoS constraints data struct state */
-enum dev_pm_qos_state {
- DEV_PM_QOS_NO_DEVICE, /* No device present */
- DEV_PM_QOS_DEVICE_PRESENT, /* Device present, data not allocated */
- DEV_PM_QOS_ALLOCATED, /* Device present, data allocated */
-};
-
struct wakeup_source;
struct pm_domain_data {
@@ -489,7 +482,6 @@ struct dev_pm_info {
#endif
struct pm_subsys_data *subsys_data; /* Owned by the subsystem. */
struct pm_qos_constraints *constraints;
- enum dev_pm_qos_state constraints_state;
};
extern void update_pm_runtime_accounting(struct device *dev);
^ 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