SUPERH platform development
 help / color / mirror / Atom feed
* Re: [PATCH] fbdev: sh_mobile_lcdc: Turn dot clock on before resuming from runtime PM
From: Laurent Pinchart @ 2011-09-20 19:56 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <1310387754-23033-1-git-send-email-laurent.pinchart@ideasonboard.com>

Hi Florian,

On Tuesday 20 September 2011 21:52:36 Florian Tobias Schandinat wrote:
> On 09/20/2011 07:30 PM, Laurent Pinchart wrote:
> > On Monday 11 July 2011 14:35:54 Laurent Pinchart wrote:
> >> Resuming from runtime PM restores all LCDC registers. If the dot clock
> >> is off at that time display panning information will be corrupted.
> >> 
> >> Turn the dot clock on before resuming from runtime PM. Similarly,
> >> turn the clock off after suspending the LCDC.
> > 
> > Could you please pick this patch for v3.2 ?
> 
> I assume you meant the currently developed 3.1? (as 3.2 is the next one for
> which the patch is lying in my fbdev-next anyway)

No, I meant v3.2. As I haven't received any pull notification in response to 
the patch, and as I had no way to check your fbdev-next tree on kernel.org, I 
just wanted to make sure the patch would be queued for v3.2.

Please ignore this e-mail (and the other similar ones I've just sent) if the 
patches are already in your queue. And thank you for picking them.

> Uhm, I originally didn't plan to ask Linus pulling anything before getting
> rid of the old stuff, but okay, will go through my patches in the next
> days and look what else is appropriate unless Linus beats me and releases
> 3.1 (although I do not consider this likely as long as kernel.org is still
> down)

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* Re: [PATCH] fbdev: sh_mobile_lcdc: Turn dot clock on before resuming
From: Florian Tobias Schandinat @ 2011-09-20 19:52 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <1310387754-23033-1-git-send-email-laurent.pinchart@ideasonboard.com>

Hi Laurent,

On 09/20/2011 07:30 PM, Laurent Pinchart wrote:
> Hi Florian,
> 
> On Monday 11 July 2011 14:35:54 Laurent Pinchart wrote:
>> Resuming from runtime PM restores all LCDC registers. If the dot clock
>> is off at that time display panning information will be corrupted.
>>
>> Turn the dot clock on before resuming from runtime PM. Similarly,
>> turn the clock off after suspending the LCDC.
> 
> Could you please pick this patch for v3.2 ?

I assume you meant the currently developed 3.1? (as 3.2 is the next one for
which the patch is lying in my fbdev-next anyway)
Uhm, I originally didn't plan to ask Linus pulling anything before getting rid
of the old stuff, but okay, will go through my patches in the next days and look
what else is appropriate unless Linus beats me and releases 3.1 (although I do
not consider this likely as long as kernel.org is still down)


Best regards,

Florian Tobias Schandinat

^ permalink raw reply

* Re: [PATCH 0/3] sh_mobile_lcdc cleanup and fixes
From: Laurent Pinchart @ 2011-09-20 19:33 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <1310766753-30314-1-git-send-email-laurent.pinchart@ideasonboard.com>

On Tuesday 20 September 2011 21:30:15 Laurent Pinchart wrote:
> Hi Florian,
> 
> On Friday 15 July 2011 23:52:30 Laurent Pinchart wrote:
> > Hi everybody,
> > 
> > When trying to understand the sh_mobile_lcdc driver, I found it hard to
> > read statements that include hardcoded register values. I thus wrote a
> > patch that replace them with macros, making the code more readable.
> > 
> > While doing so, I found two potential issues in the driver. See patches 2
> > and 3 for detailed explanations and fixes.
> > 
> > Laurent Pinchart (3):
> >   fbdev: sh_mobile_lcdc: Replace hardcoded register values with macros
> >   fbdev: sh_mobile_lcdc: Don't acknowlege interrupts unintentionally
> >   fbdev: sh_mobile_lcdc: Compute clock pattern using divider
> >   
> >     denominator
> 
> Could you please pick these patches for v3.2 ?

Sorry, I meant to answer the next version of this patch set. Please pick v2 
instead.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* Re: [PATCH] fbdev: sh_mobile_lcdc: Turn dot clock on before resuming from runtime PM
From: Laurent Pinchart @ 2011-09-20 19:30 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <1310387754-23033-1-git-send-email-laurent.pinchart@ideasonboard.com>

Hi Florian,

On Monday 11 July 2011 14:35:54 Laurent Pinchart wrote:
> Resuming from runtime PM restores all LCDC registers. If the dot clock
> is off at that time display panning information will be corrupted.
> 
> Turn the dot clock on before resuming from runtime PM. Similarly,
> turn the clock off after suspending the LCDC.

Could you please pick this patch for v3.2 ?

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* Re: [PATCH 0/3] sh_mobile_lcdc cleanup and fixes
From: Laurent Pinchart @ 2011-09-20 19:30 UTC (permalink / raw)
  To: linux-fbdev
In-Reply-To: <1310766753-30314-1-git-send-email-laurent.pinchart@ideasonboard.com>

Hi Florian,

On Friday 15 July 2011 23:52:30 Laurent Pinchart wrote:
> Hi everybody,
> 
> When trying to understand the sh_mobile_lcdc driver, I found it hard to
> read statements that include hardcoded register values. I thus wrote a
> patch that replace them with macros, making the code more readable.
> 
> While doing so, I found two potential issues in the driver. See patches 2
> and 3 for detailed explanations and fixes.
> 
> Laurent Pinchart (3):
>   fbdev: sh_mobile_lcdc: Replace hardcoded register values with macros
>   fbdev: sh_mobile_lcdc: Don't acknowlege interrupts unintentionally
>   fbdev: sh_mobile_lcdc: Compute clock pattern using divider
>     denominator

Could you please pick these patches for v3.2 ?

-- 
Regards,

Laurent Pinchart

^ permalink raw reply

* [PATCH v2 4/4] fbdev: sh_mobile_meram: Remove unneeded sh_mobile_meram.h
From: Laurent Pinchart @ 2011-09-20 19:21 UTC (permalink / raw)
  To: linux-fbdev

The drivers/video/sh_mobile_meram.h header contains unused definitions
and declarations. Move the only used macro to sh_mobile_meram.c, and
remove the header.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/sh_mobile_lcdcfb.c |    2 +-
 drivers/video/sh_mobile_meram.c  |    5 +++--
 drivers/video/sh_mobile_meram.h  |   33 ---------------------------------
 3 files changed, 4 insertions(+), 36 deletions(-)
 delete mode 100644 drivers/video/sh_mobile_meram.h

diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 0b7b492..088cb17 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -24,10 +24,10 @@
 #include <linux/backlight.h>
 #include <linux/gpio.h>
 #include <video/sh_mobile_lcdc.h>
+#include <video/sh_mobile_meram.h>
 #include <linux/atomic.h>
 
 #include "sh_mobile_lcdcfb.h"
-#include "sh_mobile_meram.h"
 
 #define SIDE_B_OFFSET 0x1000
 #define MIRROR_OFFSET 0x2000
diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index 4ad083c..48c1828 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -16,8 +16,7 @@
 #include <linux/io.h>
 #include <linux/slab.h>
 #include <linux/platform_device.h>
-
-#include "sh_mobile_meram.h"
+#include <video/sh_mobile_meram.h>
 
 /* meram registers */
 #define MEVCR1			0x0004
@@ -84,6 +83,8 @@
 	 ((yszm1) << MExxBSIZE_YSZM1_SHIFT) | \
 	 ((xszm1) << MExxBSIZE_XSZM1_SHIFT))
 
+#define SH_MOBILE_MERAM_ICB_NUM		32
+
 static unsigned long common_regs[] = {
 	MEVCR1,
 	MEQSEL1,
diff --git a/drivers/video/sh_mobile_meram.h b/drivers/video/sh_mobile_meram.h
deleted file mode 100644
index 1615204..0000000
--- a/drivers/video/sh_mobile_meram.h
+++ /dev/null
@@ -1,33 +0,0 @@
-#ifndef __sh_mobile_meram_h__
-#define __sh_mobile_meram_h__
-
-#include <linux/mutex.h>
-#include <video/sh_mobile_meram.h>
-
-/*
- * MERAM private
- */
-
-#define MERAM_ICB_Y 0x1
-#define MERAM_ICB_C 0x2
-
-/* MERAM cache size */
-#define SH_MOBILE_MERAM_ICB_NUM		32
-
-#define SH_MOBILE_MERAM_CACHE_OFFSET(p)	((p) >> 16)
-#define SH_MOBILE_MERAM_CACHE_SIZE(p)	((p) & 0xffff)
-
-int sh_mobile_meram_alloc_icb(const struct sh_mobile_meram_cfg *cfg,
-		   int xres,
-		   int yres,
-		   unsigned int base_addr,
-		   int yuv_mode,
-		   int *marker_icb,
-		   int *out_pitch);
-
-void sh_mobile_meram_free_icb(int marker_icb);
-
-#define SH_MOBILE_MERAM_START(ind, ab) \
-	(0xC0000000 | ((ab & 0x1) << 23) | ((ind & 0x1F) << 24))
-
-#endif /* !__sh_mobile_meram_h__ */
-- 
1.7.3.4


^ permalink raw reply related

* [PATCH v2 3/4] fbdev: sh_mobile_meram: Fix MExxCTL register save on runtime PM suspend
From: Laurent Pinchart @ 2011-09-20 19:21 UTC (permalink / raw)
  To: linux-fbdev

To reset the ICB on resume the MExxCTL register needs to be OR'ed with
MExxCTL_WBF | MExxCTL_WF | MExxCTL_RF, no set to that value. Fix this.

This fixes corruption at the bottom of the display when resuming from
runtime PM.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/sh_mobile_meram.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index f7e77f6..4ad083c 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -552,7 +552,7 @@ static int sh_mobile_meram_runtime_suspend(struct device *dev)
 				meram_read_icb(priv->base, j, icb_regs[k]);
 			/* Reset ICB on resume */
 			if (icb_regs[k] = MExxCTL)
-				priv->icb_saved_regs[j * ICB_REGS_SIZE + k] +				priv->icb_saved_regs[j * ICB_REGS_SIZE + k] | 					MExxCTL_WBF | MExxCTL_WF | MExxCTL_RF;
 		}
 	}
-- 
1.7.3.4


^ permalink raw reply related

* [PATCH v2 2/4] fbdev: sh_mobile_meram: Validate ICB configuration outside mutex
From: Laurent Pinchart @ 2011-09-20 19:21 UTC (permalink / raw)
  To: linux-fbdev

Validate as much of the requested ICB configuration as possible outside
of the mutex-protected region when registering ICBs.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/sh_mobile_meram.c |   18 ++++++++----------
 1 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index 569888c..f7e77f6 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -413,24 +413,22 @@ static int sh_mobile_meram_register(struct sh_mobile_meram_info *pdata,
 		xres, yres, (!pixelformat) ? "yuv" : "rgb",
 		base_addr_y, base_addr_c);
 
-	mutex_lock(&priv->lock);
-
 	/* we can't handle wider than 8192px */
 	if (xres > 8192) {
 		dev_err(&pdev->dev, "width exceeding the limit (> 8192).");
-		error = -EINVAL;
-		goto err;
-	}
-
-	if (priv->used_meram_cache_regions + 2 > SH_MOBILE_MERAM_ICB_NUM) {
-		dev_err(&pdev->dev, "no more ICB available.");
-		error = -EINVAL;
-		goto err;
+		return -EINVAL;
 	}
 
 	/* do we have at least one ICB config? */
 	if (cfg->icb[0].marker_icb < 0 || cfg->icb[0].cache_icb < 0) {
 		dev_err(&pdev->dev, "at least one ICB is required.");
+		return -EINVAL;
+	}
+
+	mutex_lock(&priv->lock);
+
+	if (priv->used_meram_cache_regions + 2 > SH_MOBILE_MERAM_ICB_NUM) {
+		dev_err(&pdev->dev, "no more ICB available.");
 		error = -EINVAL;
 		goto err;
 	}
-- 
1.7.3.4


^ permalink raw reply related

* [PATCH v2 1/4] fbdev: sh_mobile_meram: Replace hardcoded register values with macros
From: Laurent Pinchart @ 2011-09-20 19:21 UTC (permalink / raw)
  To: linux-fbdev

Instead of hardcoding register values through the driver, define macros
for individual register bits using the register name and the bit name,
and use the macros.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 drivers/video/sh_mobile_meram.c |  100 +++++++++++++++++++++++++++++----------
 1 files changed, 74 insertions(+), 26 deletions(-)

diff --git a/drivers/video/sh_mobile_meram.c b/drivers/video/sh_mobile_meram.c
index 39f28a1..569888c 100644
--- a/drivers/video/sh_mobile_meram.c
+++ b/drivers/video/sh_mobile_meram.c
@@ -20,22 +20,69 @@
 #include "sh_mobile_meram.h"
 
 /* meram registers */
-#define MExxCTL 0x0
-#define MExxBSIZE 0x4
-#define MExxMNCF 0x8
-#define MExxSARA 0x10
-#define MExxSARB 0x14
-#define MExxSBSIZE 0x18
-
-#define MERAM_MExxCTL_VAL(ctl, next_icb, addr)	\
-	((ctl) | (((next_icb) & 0x1f) << 11) | (((addr) & 0x7ff) << 16))
-#define	MERAM_MExxBSIZE_VAL(a, b, c) \
-	(((a) << 28) | ((b) << 16) | (c))
-
-#define MEVCR1 0x4
-#define MEACTS 0x10
-#define MEQSEL1 0x40
-#define MEQSEL2 0x44
+#define MEVCR1			0x0004
+#define MEVCR1_RST		(1 << 31)
+#define MEVCR1_WD		(1 << 30)
+#define MEVCR1_AMD1		(1 << 29)
+#define MEVCR1_AMD0		(1 << 28)
+#define MEQSEL1			0x0040
+#define MEQSEL2			0x0044
+
+#define MExx_BASE		0x0400
+
+#define MExxCTL			0x0000
+#define MExxCTL_BV		(1 << 31)
+#define MExxCTL_BSZ_SHIFT	28
+#define MExxCTL_MSAR_MASK	(0x7ff << MExxCTL_MSAR_SHIFT)
+#define MExxCTL_MSAR_SHIFT	16
+#define MExxCTL_NXT_MASK	(0x1f << MExxCTL_NXT_SHIFT)
+#define MExxCTL_NXT_SHIFT	11
+#define MExxCTL_WD1		(1 << 10)
+#define MExxCTL_WD0		(1 << 9)
+#define MExxCTL_WS		(1 << 8)
+#define MExxCTL_CB		(1 << 7)
+#define MExxCTL_WBF		(1 << 6)
+#define MExxCTL_WF		(1 << 5)
+#define MExxCTL_RF		(1 << 4)
+#define MExxCTL_CM		(1 << 3)
+#define MExxCTL_MD_READ		(1 << 0)
+#define MExxCTL_MD_WRITE	(2 << 0)
+#define MExxCTL_MD_ICB_WB	(3 << 0)
+#define MExxCTL_MD_ICB		(4 << 0)
+#define MExxCTL_MD_FB		(7 << 0)
+#define MExxCTL_MD_MASK		(7 << 0)
+#define MExxBSIZE		0x0004
+#define MExxBSIZE_RCNT_SHIFT	28
+#define MExxBSIZE_YSZM1_SHIFT	16
+#define MExxBSIZE_XSZM1_SHIFT	0
+#define MExxMNCF		0x0008
+#define MExxMNCF_KWBNM_SHIFT	28
+#define MExxMNCF_KRBNM_SHIFT	24
+#define MExxMNCF_BNM_SHIFT	16
+#define MExxMNCF_XBV		(1 << 15)
+#define MExxMNCF_CPL_YCBCR444	(1 << 12)
+#define MExxMNCF_CPL_YCBCR420	(2 << 12)
+#define MExxMNCF_CPL_YCBCR422	(3 << 12)
+#define MExxMNCF_CPL_MSK	(3 << 12)
+#define MExxMNCF_BL		(1 << 2)
+#define MExxMNCF_LNM_SHIFT	0
+#define MExxSARA		0x0010
+#define MExxSARB		0x0014
+#define MExxSBSIZE		0x0018
+#define MExxSBSIZE_HDV		(1 << 31)
+#define MExxSBSIZE_HSZ16	(0 << 28)
+#define MExxSBSIZE_HSZ32	(1 << 28)
+#define MExxSBSIZE_HSZ64	(2 << 28)
+#define MExxSBSIZE_HSZ128	(3 << 28)
+#define MExxSBSIZE_SBSIZZ_SHIFT	0
+
+#define MERAM_MExxCTL_VAL(next, addr)	\
+	((((next) << MExxCTL_NXT_SHIFT) & MExxCTL_NXT_MASK) | \
+	 (((addr) << MExxCTL_MSAR_SHIFT) & MExxCTL_MSAR_MASK))
+#define	MERAM_MExxBSIZE_VAL(rcnt, yszm1, xszm1) \
+	(((rcnt) << MExxBSIZE_RCNT_SHIFT) | \
+	 ((yszm1) << MExxBSIZE_YSZM1_SHIFT) | \
+	 ((xszm1) << MExxBSIZE_XSZM1_SHIFT))
 
 static unsigned long common_regs[] = {
 	MEVCR1,
@@ -72,8 +119,8 @@ struct sh_mobile_meram_priv {
  * MERAM/ICB access functions
  */
 
-#define MERAM_ICB_OFFSET(base, idx, off)	\
-	((base) + (0x400 + ((idx) * 0x20) + (off)))
+#define MERAM_ICB_OFFSET(base, idx, off) \
+	(MExx_BASE + (base) + (off) + (idx) * 0x20)
 
 static inline void meram_write_icb(void __iomem *base, int idx, int off,
 	unsigned long val)
@@ -308,17 +355,18 @@ static int meram_init(struct sh_mobile_meram_priv *priv,
 	/*
 	 * Set MERAM for framebuffer
 	 *
-	 * 0x70f:  WD = 0x3, WS=0x1, CM=0x1, MDû mode
 	 * we also chain the cache_icb and the marker_icb.
 	 * we also split the allocated MERAM buffer between two ICBs.
 	 */
 	meram_write_icb(priv->base, icb->cache_icb, MExxCTL,
-			MERAM_MExxCTL_VAL(0x70f, icb->marker_icb,
-					  icb->meram_offset));
+			MERAM_MExxCTL_VAL(icb->marker_icb, icb->meram_offset) |
+			MExxCTL_WD1 | MExxCTL_WD0 | MExxCTL_WS | MExxCTL_CM |
+			MExxCTL_MD_FB);
 	meram_write_icb(priv->base, icb->marker_icb, MExxCTL,
-			MERAM_MExxCTL_VAL(0x70f, icb->cache_icb,
-					  icb->meram_offset +
-					  icb->meram_size / 2));
+			MERAM_MExxCTL_VAL(icb->cache_icb, icb->meram_offset +
+					  icb->meram_size / 2) |
+			MExxCTL_WD1 | MExxCTL_WD0 | MExxCTL_WS | MExxCTL_CM |
+			MExxCTL_MD_FB);
 
 	return 0;
 }
@@ -507,7 +555,7 @@ static int sh_mobile_meram_runtime_suspend(struct device *dev)
 			/* Reset ICB on resume */
 			if (icb_regs[k] = MExxCTL)
 				priv->icb_saved_regs[j * ICB_REGS_SIZE + k] -					0x70;
+					MExxCTL_WBF | MExxCTL_WF | MExxCTL_RF;
 		}
 	}
 	return 0;
@@ -592,7 +640,7 @@ static int __devinit sh_mobile_meram_probe(struct platform_device *pdev)
 
 	/* initialize ICB addressing mode */
 	if (pdata->addr_mode = SH_MOBILE_MERAM_MODE1)
-		meram_write_reg(priv->base, MEVCR1, 1 << 29);
+		meram_write_reg(priv->base, MEVCR1, MEVCR1_AMD1);
 
 	pm_runtime_enable(&pdev->dev);
 
-- 
1.7.3.4


^ permalink raw reply related

* [PATCH v2 0/4] sh_mobile_meram cleanups and fixes
From: Laurent Pinchart @ 2011-09-20 19:21 UTC (permalink / raw)
  To: linux-fbdev

Hi,

Here's the second version of the sh_mobile_meram and cleanup fixes. Compared
to v1, I've incorporated Damian's comments in the register definitions (first
patch).

Laurent Pinchart (4):
  fbdev: sh_mobile_meram: Replace hardcoded register values with macros
  fbdev: sh_mobile_meram: Validate ICB configuration outside mutex
  fbdev: sh_mobile_meram: Fix MExxCTL register save on runtime PM
    suspend
  fbdev: sh_mobile_meram: Remove unneeded sh_mobile_meram.h

 drivers/video/sh_mobile_lcdcfb.c |    2 +-
 drivers/video/sh_mobile_meram.c  |  125 ++++++++++++++++++++++++++------------
 drivers/video/sh_mobile_meram.h  |   33 ----------
 3 files changed, 87 insertions(+), 73 deletions(-)
 delete mode 100644 drivers/video/sh_mobile_meram.h

-- 
Regards,

Laurent Pinchart


^ permalink raw reply

* 群发软件+买家搜索机+109届广交会买家
From: 仅10元每天 @ 2011-09-20  9:37 UTC (permalink / raw)
  To: linux-sh
In-Reply-To: <20111213084743353137@amidress.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 15848 bytes --]

������������������������������������+109������������������������������������������������������������������������������������������������������������������������������������������������������������������,B2B���������������������������������������������500���������,���������10������������������������������������ 
���������������������������������������������������������������������������������������������������
���������������������������������������������������������������������������������������������������


1������������������������������������������������������ ���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������5��������������������������������������������� 
2���������500��������������������������������������������������������������������������������� ���������������������������500��������������������������������������������������������������������������������������������������� ��������� 
3���������������������������������������������������������������Email������������������������������������ ���������������������������������������������1-2���������������������������������������������������������������EMAIL������������������������������������������������������ 
 

������������������������������������������������������QQ: 1339625218   ������������������������������������������������������������������������: 1339625218@qq.com
������������������������������������������������������QQ: 1339625218   ������������������������������������������������������������������������: 1339625218@qq.com
������������������������������������������������������QQ: 1339625218   ������������������������������������������������������������������������: 1339625218@qq.com

������������������������������������:
������������������8������������������(������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������)��������� 
1���������2011������������������109��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������� 
2������������������������������������������������������������������������������������������2011���������������������������������������������+2012���������������������������������������������������������������������������������������������������������������������������������������
3������������������������������������������������������������������������,���������451660������������������������������������ (������������������������������������������������������ 2011-05-16���������)
4���������2008���������,2009���������,2010��������� ������������������+������������������������������������������������������������������������������������������103 104 105 106 107 108 ��������������������������� ���������120.6������������������������������������
5���������2010������������������������������������������������������������������������PPAI��������������������������������������������� PPAI Members Directory������������������������������������������������������������������������������������������
6���������2010���������������������������������������������������������������������������������������������������������������������(���������������������������������������������������������������)������������������7.2������������������������������������������������������������������������������������������������������������
7���������48.68������������������������������������������������������������������������������������������������������������������������������������������������ 1-2���������������������������������������������2���������������������������1������������������������������������������������������ 2���������������������������������������������������������������������������������������������������������������������36���������������������������
8���������2009���������������������������������������������������������������piers��������������������������� 1���������������������������


������������������������������������������������������������������������������������������������������������������������������ (���������������������������������������������������������������������������������������������������������������������������������������������������������) ������������������������������������������������������ ���������������������������

 


 

������������������������������������-���������������������������������������������
������������������������������������-���������������������������������������������
������������������������������������-���������������������������������������������
������������������������������������-���������������������������������������������
������������������������������������-���������������������������������������������
������������{.n���+���������������������+%���������������������\x17������w������{.n���+������������{���������������{ay���\x1d���������������,j\a������f���������h���������������������������z_������\x03(���������������������j"������\x1a���^[m������������\a������G������������������?���������������&���������~������

^ permalink raw reply

* Re: [RFC] sh: Take into account the base of physical memory in virt_to_phys()
From: Nobuhiro Iwamatsu @ 2011-09-20  4:44 UTC (permalink / raw)
  To: linux-sh
In-Reply-To: <1316085179-4207-1-git-send-email-horms@verge.net.au>

Hi, all.

I forgot to have sent the following patches to solve the same problem.
  http://www.spinics.net/lists/linux-sh/msg05954.html

I was going to add the mode which worked to proc/cpuinfo.
Because the user did not know whether a kernel was 29bit or 32bit from
the user space.

Paul, do you think so?

Best regards,
  Nobuhiro

2011/9/17 Simon Horman <horms@verge.net.au>:
> On Fri, Sep 16, 2011 at 07:59:21PM +0900, Magnus Damm wrote:
>> On Thu, Sep 15, 2011 at 8:12 PM, Simon Horman <horms@verge.net.au> wrote:
>> > Previously virt_to_phys() assumed that physical memory always started
>> > at address 0. This is not always the case.
>>
>> I think most boards have NOR Flash or ROM mapped at physical address 0.
>>
>> For more information please have a look at: arch/sh/boards/mach-ecovec24/setup.c
>>
>> > --- a/kexec/arch/sh/kexec-sh.c
>> > +++ b/kexec/arch/sh/kexec-sh.c
>> > @@ -188,10 +188,18 @@ void kexec_sh_setup_zero_page(char *zero_page_buf, size_t zero_page_size,
>> >  unsigned long virt_to_phys(unsigned long addr)
>> >  {
>> >        unsigned long seg = addr & 0xe0000000;
>> > +       unsigned long long start, end;
>> > +       int ret;
>> > +
>> > +       /* Assume there is only one "System RAM" region */
>> > +       ret = parse_iomem_single("System RAM\n", &start, &end);
>> > +       if (ret)
>> > +               die("Could not parse System RAM region in /proc/iomem\n");
>> > +
>> >        if (seg != 0x80000000 && seg != 0xc0000000)
>> >                die("Virtual address %p is not in P1 or P2\n", (void *)addr);
>> >
>> > -       return addr - seg;
>> > +       return addr - seg + start;
>> >  }
>>
>> This will most likely also change how 29-bit platforms translate their
>> addresses, not sure if that's what you want to do.
>
> I am also unsure about the 29bit case. Do you have any thoughts on
> what a good approach might look like?
>
> --
> 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
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

^ permalink raw reply

* Re: Ecovec (SH7724) board doesn't work on latest linus tree
From: Paul Mundt @ 2011-09-20  3:10 UTC (permalink / raw)
  To: linux-sh
In-Reply-To: <w3pvcwf5xuu.wl%kuninori.morimoto.gx@renesas.com>

On Mon, Sep 19, 2011 at 07:08:18PM -0700, Kuninori Morimoto wrote:
> > On Thu, Sep 08, 2011 at 05:52:11PM +0900, Nobuhiro Iwamatsu wrote:
> > > 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.
> > > 
> > Morimoto-san, does this fix your issue? If you can provide your Tested-by
> > for this then I'll queue it up and get it off to Linus.
> 
> Thank you.
> 
> I tested this patch on linus/master.
> And this patch solved Ecovec board boot issue.
> 
> # I tested it on mackerel (SH7372) board too.
> # It works well
>  
> Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Great, I'll queue it up, thanks.

^ permalink raw reply

* Re: Ecovec (SH7724) board doesn't work on latest linus tree
From: Kuninori Morimoto @ 2011-09-20  2:08 UTC (permalink / raw)
  To: linux-sh
In-Reply-To: <w3pvcwf5xuu.wl%kuninori.morimoto.gx@renesas.com>


Hi Paul, Iwamatsu-san

> On Thu, Sep 08, 2011 at 05:52:11PM +0900, Nobuhiro Iwamatsu wrote:
> > 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.
> > 
> Morimoto-san, does this fix your issue? If you can provide your Tested-by
> for this then I'll queue it up and get it off to Linus.

Thank you.

I tested this patch on linus/master.
And this patch solved Ecovec board boot issue.

# I tested it on mackerel (SH7372) board too.
# It works well
 
Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Best regards
---
Kuninori Morimoto

^ permalink raw reply

* [PATCH 10/10 v3] ARM: mach-shmobile: clock-sh73a0: add DSIxPHY clock support
From: Kuninori Morimoto @ 2011-09-20  1:51 UTC (permalink / raw)
  To: linux-sh

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v2 -> v3

o clk_rate_multi_range_round() -> clk_rate_mult_range_round()

 arch/arm/mach-shmobile/board-ag5evm.c |   16 ++++-
 arch/arm/mach-shmobile/board-kota2.c  |   17 ++++-
 arch/arm/mach-shmobile/clock-sh73a0.c |  113 +++++++++++++++++++++++++++++++++
 3 files changed, 139 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-ag5evm.c b/arch/arm/mach-shmobile/board-ag5evm.c
index 75c334d..b36dc61 100644
--- a/arch/arm/mach-shmobile/board-ag5evm.c
+++ b/arch/arm/mach-shmobile/board-ag5evm.c
@@ -320,12 +320,11 @@ 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;
 
 	pck = clk_get(&pdev->dev, "dsip_clk");
@@ -334,18 +333,27 @@ static int sh_mipi_set_dot_clock(struct platform_device *pdev,
 		goto sh_mipi_set_dot_clock_pck_err;
 	}
 
+	phy = clk_get(&pdev->dev, "dsiphy_clk");
+	if (IS_ERR(phy)) {
+		ret = PTR_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 6c3866b..5b76d5d 100644
--- a/arch/arm/mach-shmobile/board-kota2.c
+++ b/arch/arm/mach-shmobile/board-kota2.c
@@ -367,12 +367,11 @@ 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;
 
 	pck = clk_get(&pdev->dev, "dsip_clk");
@@ -381,16 +380,28 @@ static int sh_mipi_set_dot_clock(struct platform_device *pdev,
 		goto sh_mipi_set_dot_clock_pck_err;
 	}
 
+	phy = clk_get(&pdev->dev, "dsiphy_clk");
+	if (IS_ERR(phy)) {
+		ret = PTR_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..130600d 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_mult_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 07/10 v2] sh: clkfwk: add clk_rate_mult_range_round()
From: Kuninori Morimoto @ 2011-09-20  1:51 UTC (permalink / raw)
  To: linux-sh

Some llock pulse generator has PLL multiplication.
clk_rate_mult_range_round() will be good helper for it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v1 -> v2

o xx_multi_xx -> xx_mult_xx
o div_xxx -> mult_xxx

 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..352036b 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_mult_range_iter(unsigned int pos,
+				      struct clk_rate_round_data *rounder)
+{
+	return clk_get_rate(rounder->arg) * pos;
+}
+
+long clk_rate_mult_range_round(struct clk *clk, unsigned int mult_min,
+			       unsigned int mult_max, unsigned long rate)
+{
+	struct clk_rate_round_data mult_range_round = {
+		.min	= mult_min,
+		.max	= mult_max,
+		.func	= clk_rate_mult_range_iter,
+		.arg	= clk_get_parent(clk),
+		.rate	= rate,
+	};
+
+	return clk_rate_round_helper(&mult_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..9237c29 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_mult_range_round(struct clk *clk, unsigned int mult_min,
+			       unsigned int mult_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

* Re: [PATCH 07/10] sh: clkfwk: add clk_rate_multi_range_round()
From: Kuninori Morimoto @ 2011-09-20  1:18 UTC (permalink / raw)
  To: linux-sh
In-Reply-To: <87hb4mqack.wl%kuninori.morimoto.gx@renesas.com>


Hi Paul

Thank you for checking patch

> On Fri, Sep 09, 2011 at 03:27:43AM -0700, Kuninori Morimoto wrote:
> > Some Clock Pulse Generator has PLL multiplication.
> > clk_rate_multi_range_round() will be good helper for it.
> > 
> clk_rate_mult_range_round() would be more logically consistent.
> 
> > +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);
> > +}
> > +
> Clearly you want mult_range and not div_range here. Likewise div_min/max
> should be mult_min/max or so, as you're clearly not doing division on
> anything here.
> 
> Beyond that, I have no particular objections to the API addition.

Thanks.
I send v2 patch

Best regards
---
Kuninori Morimoto

^ permalink raw reply

* Re: Ecovec (SH7724) board doesn't work on latest linus tree
From: Paul Mundt @ 2011-09-20  0:54 UTC (permalink / raw)
  To: linux-sh
In-Reply-To: <w3pvcwf5xuu.wl%kuninori.morimoto.gx@renesas.com>

On Thu, Sep 08, 2011 at 05:52:11PM +0900, Nobuhiro Iwamatsu wrote:
> 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.
> 
Morimoto-san, does this fix your issue? If you can provide your Tested-by
for this then I'll queue it up and get it off to Linus.

^ permalink raw reply

* 群发软件+买家搜索机+109届广交会买家
From: 仅10元每天 @ 2011-09-19  3:49 UTC (permalink / raw)
  To: linux-sh
In-Reply-To: <20111213084743353137@amidress.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 15848 bytes --]

������������������������������������+109������������������������������������������������������������������������������������������������������������������������������������������������������������������,B2B���������������������������������������������500���������,���������10������������������������������������ 
���������������������������������������������������������������������������������������������������
���������������������������������������������������������������������������������������������������


1������������������������������������������������������ ���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������5��������������������������������������������� 
2���������500��������������������������������������������������������������������������������� ���������������������������500��������������������������������������������������������������������������������������������������� ��������� 
3���������������������������������������������������������������Email������������������������������������ ���������������������������������������������1-2���������������������������������������������������������������EMAIL������������������������������������������������������ 
 

������������������������������������������������������QQ: 1339625218   ������������������������������������������������������������������������: 1339625218@qq.com
������������������������������������������������������QQ: 1339625218   ������������������������������������������������������������������������: 1339625218@qq.com
������������������������������������������������������QQ: 1339625218   ������������������������������������������������������������������������: 1339625218@qq.com

������������������������������������:
������������������8������������������(������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������)��������� 
1���������2011������������������109��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������� 
2������������������������������������������������������������������������������������������2011���������������������������������������������+2012���������������������������������������������������������������������������������������������������������������������������������������
3������������������������������������������������������������������������,���������451660������������������������������������ (������������������������������������������������������ 2011-05-16���������)
4���������2008���������,2009���������,2010��������� ������������������+������������������������������������������������������������������������������������������103 104 105 106 107 108 ��������������������������� ���������120.6������������������������������������
5���������2010������������������������������������������������������������������������PPAI��������������������������������������������� PPAI Members Directory������������������������������������������������������������������������������������������
6���������2010���������������������������������������������������������������������������������������������������������������������(���������������������������������������������������������������)������������������7.2������������������������������������������������������������������������������������������������������������
7���������48.68������������������������������������������������������������������������������������������������������������������������������������������������ 1-2���������������������������������������������2���������������������������1������������������������������������������������������ 2���������������������������������������������������������������������������������������������������������������������36���������������������������
8���������2009���������������������������������������������������������������piers��������������������������� 1���������������������������


������������������������������������������������������������������������������������������������������������������������������ (���������������������������������������������������������������������������������������������������������������������������������������������������������) ������������������������������������������������������ ���������������������������

 


 

������������������������������������-���������������������������������������������
������������������������������������-���������������������������������������������
������������������������������������-���������������������������������������������
������������������������������������-���������������������������������������������
������������������������������������-���������������������������������������������
������������{.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: Vinod Koul @ 2011-09-19  3:25 UTC (permalink / raw)
  To: Alan Cox, g.liakhovetski@gmx.de, evolution
  Cc: Paul Mundt, Williams, Dan J, magnus.damm@gmail.com,
	linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
	damm@opensource.se
In-Reply-To: <20110914195237.606d11f6@bob.linux.org.uk>

On Wed, 2011-09-14 at 19:52 +0100, Alan Cox wrote:
> On Wed, 14 Sep 2011 10:46:50 +0530
> Vinod Koul <vinod.koul@intel.com> wrote:
> 
> > On Fri, 2011-09-09 at 01:01 +0530, Vinod Koul wrote:
> > > 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:
> > > 
> > > 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
> > Since this is for serial driver, I can carry this patch with ACK from
> > Alan or Alan can take this patch with Ack from me
> 
> Greg normally carries them but I'm happy with this going via your tree.
Okay thanks I have applied it after fixing a trivial conflict

-- 
~Vinod


^ permalink raw reply

* Re: [RFC] sh: Take into account the base of physical memory in
From: Simon Horman @ 2011-09-17  8:11 UTC (permalink / raw)
  To: linux-sh
In-Reply-To: <1316085179-4207-1-git-send-email-horms@verge.net.au>

On Fri, Sep 16, 2011 at 07:59:21PM +0900, Magnus Damm wrote:
> On Thu, Sep 15, 2011 at 8:12 PM, Simon Horman <horms@verge.net.au> wrote:
> > Previously virt_to_phys() assumed that physical memory always started
> > at address 0. This is not always the case.
> 
> I think most boards have NOR Flash or ROM mapped at physical address 0.
> 
> For more information please have a look at: arch/sh/boards/mach-ecovec24/setup.c
> 
> > --- a/kexec/arch/sh/kexec-sh.c
> > +++ b/kexec/arch/sh/kexec-sh.c
> > @@ -188,10 +188,18 @@ void kexec_sh_setup_zero_page(char *zero_page_buf, size_t zero_page_size,
> >  unsigned long virt_to_phys(unsigned long addr)
> >  {
> >        unsigned long seg = addr & 0xe0000000;
> > +       unsigned long long start, end;
> > +       int ret;
> > +
> > +       /* Assume there is only one "System RAM" region */
> > +       ret = parse_iomem_single("System RAM\n", &start, &end);
> > +       if (ret)
> > +               die("Could not parse System RAM region in /proc/iomem\n");
> > +
> >        if (seg != 0x80000000 && seg != 0xc0000000)
> >                die("Virtual address %p is not in P1 or P2\n", (void *)addr);
> >
> > -       return addr - seg;
> > +       return addr - seg + start;
> >  }
> 
> This will most likely also change how 29-bit platforms translate their
> addresses, not sure if that's what you want to do.

I am also unsure about the 29bit case. Do you have any thoughts on
what a good approach might look like?


^ permalink raw reply

* Re: [RFC] sh: Take into account the base of physical memory in virt_to_phys()
From: Magnus Damm @ 2011-09-16 10:59 UTC (permalink / raw)
  To: linux-sh
In-Reply-To: <1316085179-4207-1-git-send-email-horms@verge.net.au>

On Thu, Sep 15, 2011 at 8:12 PM, Simon Horman <horms@verge.net.au> wrote:
> Previously virt_to_phys() assumed that physical memory always started
> at address 0. This is not always the case.

I think most boards have NOR Flash or ROM mapped at physical address 0.

For more information please have a look at: arch/sh/boards/mach-ecovec24/setup.c

> --- a/kexec/arch/sh/kexec-sh.c
> +++ b/kexec/arch/sh/kexec-sh.c
> @@ -188,10 +188,18 @@ void kexec_sh_setup_zero_page(char *zero_page_buf, size_t zero_page_size,
>  unsigned long virt_to_phys(unsigned long addr)
>  {
>        unsigned long seg = addr & 0xe0000000;
> +       unsigned long long start, end;
> +       int ret;
> +
> +       /* Assume there is only one "System RAM" region */
> +       ret = parse_iomem_single("System RAM\n", &start, &end);
> +       if (ret)
> +               die("Could not parse System RAM region in /proc/iomem\n");
> +
>        if (seg != 0x80000000 && seg != 0xc0000000)
>                die("Virtual address %p is not in P1 or P2\n", (void *)addr);
>
> -       return addr - seg;
> +       return addr - seg + start;
>  }

This will most likely also change how 29-bit platforms translate their
addresses, not sure if that's what you want to do.

Thanks,

/ magnus

^ permalink raw reply

* Re: [PATCH 07/10] sh: clkfwk: add clk_rate_multi_range_round()
From: Paul Mundt @ 2011-09-16 10:29 UTC (permalink / raw)
  To: linux-sh
In-Reply-To: <87hb4mqack.wl%kuninori.morimoto.gx@renesas.com>

On Fri, Sep 09, 2011 at 03:27:43AM -0700, Kuninori Morimoto wrote:
> Some Clock Pulse Generator has PLL multiplication.
> clk_rate_multi_range_round() will be good helper for it.
> 
clk_rate_mult_range_round() would be more logically consistent.

> +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);
> +}
> +
Clearly you want mult_range and not div_range here. Likewise div_min/max
should be mult_min/max or so, as you're clearly not doing division on
anything here.

Beyond that, I have no particular objections to the API addition.

^ permalink raw reply

* [PATCH] sh: kexec: Add PHYSICAL_START
From: Simon Horman @ 2011-09-15 11:13 UTC (permalink / raw)
  To: linux-sh

Add PHYSICAL_START kernel configuration parameter to set the address at
which the kernel should be loaded.

It has been observed on an sh7757lcr that simply modifying MEMORY_START
does not achieve this goal for 32bit sh. This is due to MEMORY_OFFSET in
arch/sh/kernel/vmlinux.lds.S bot being based on MEMORY_START on such
systems.

Signed-off-by: Simon Horman <horms@verge.net.au>
---
 arch/sh/Kconfig              |   13 ++++++++++++-
 arch/sh/boot/Makefile        |    6 ++++--
 arch/sh/include/asm/page.h   |   10 ++++++++++
 arch/sh/kernel/vmlinux.lds.S |    2 +-
 arch/sh/mm/init.c            |    8 ++++----
 5 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index ff9177c..bd8922c 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -649,7 +649,7 @@ config CRASH_DUMP
 	  a specially reserved region and then later executed after
 	  a crash by kdump/kexec. The crash dump kernel must be compiled
 	  to a memory address not used by the main kernel using
-	  MEMORY_START.
+	  PHYSICAL_START.
 
 	  For more details see Documentation/kdump/kdump.txt
 
@@ -660,6 +660,17 @@ config KEXEC_JUMP
 	  Jump between original kernel and kexeced kernel and invoke
 	  code via KEXEC
 
+config PHYSICAL_START
+	hex "Physical address where the kernel is loaded" if (EXPERT || CRASH_DUMP)
+	default MEMORY_START
+	---help---
+	  This gives the physical address where the kernel is loaded
+	  and is ordinarily the same as MEMORY_START.
+
+	  Different values are primarily used in the case of kexec on panic
+	  where the fail safe kernel needs to run at a different address
+	  than the panic-ed kernel.
+
 config SECCOMP
 	bool "Enable seccomp to safely compute untrusted bytecode"
 	depends on PROC_FS
diff --git a/arch/sh/boot/Makefile b/arch/sh/boot/Makefile
index ba515d8..e4ea31a 100644
--- a/arch/sh/boot/Makefile
+++ b/arch/sh/boot/Makefile
@@ -19,6 +19,7 @@ CONFIG_MEMORY_START	?= 0x0c000000
 CONFIG_BOOT_LINK_OFFSET	?= 0x00800000
 CONFIG_ZERO_PAGE_OFFSET	?= 0x00001000
 CONFIG_ENTRY_OFFSET	?= 0x00001000
+CONFIG_PHYSICAL_START	?= $(CONFIG_MEMORY_START)
 
 suffix-y := bin
 suffix-$(CONFIG_KERNEL_GZIP)	:= gz
@@ -48,7 +49,7 @@ $(obj)/romimage/vmlinux: $(obj)/zImage FORCE
 	$(Q)$(MAKE) $(build)=$(obj)/romimage $@
 
 KERNEL_MEMORY	:= $(shell /bin/bash -c 'printf "0x%08x" \
-		     $$[$(CONFIG_MEMORY_START) & 0x1fffffff]')
+		     $$[$(CONFIG_PHYSICAL_START) & 0x1fffffff]')
 
 KERNEL_LOAD	:= $(shell /bin/bash -c 'printf "0x%08x" \
 		     $$[$(CONFIG_PAGE_OFFSET)  + \
@@ -114,4 +115,5 @@ $(obj)/uImage: $(obj)/uImage.$(suffix-y)
 	@echo '  Image $@ is ready'
 
 export CONFIG_PAGE_OFFSET CONFIG_MEMORY_START CONFIG_BOOT_LINK_OFFSET \
-       CONFIG_ZERO_PAGE_OFFSET CONFIG_ENTRY_OFFSET KERNEL_MEMORY suffix-y
+       CONFIG_PHYSICAL_START CONFIG_ZERO_PAGE_OFFSET CONFIG_ENTRY_OFFSET \
+       KERNEL_MEMORY suffix-y
diff --git a/arch/sh/include/asm/page.h b/arch/sh/include/asm/page.h
index 822d608..0dca9a5 100644
--- a/arch/sh/include/asm/page.h
+++ b/arch/sh/include/asm/page.h
@@ -113,6 +113,16 @@ typedef struct page *pgtable_t;
 #define __MEMORY_SIZE		CONFIG_MEMORY_SIZE
 
 /*
+ * PHYSICAL_OFFSET is the offset in physical memory where the base
+ * of the kernel is loaded.
+ */
+#ifdef CONFIG_PHYSICAL_START
+#define PHYSICAL_OFFSET (CONFIG_PHYSICAL_START - __MEMORY_START)
+#else
+#define PHYSICAL_OFFSET 0
+#endif
+
+/*
  * PAGE_OFFSET is the virtual address of the start of kernel address
  * space.
  */
diff --git a/arch/sh/kernel/vmlinux.lds.S b/arch/sh/kernel/vmlinux.lds.S
index 731c10c..c98905f 100644
--- a/arch/sh/kernel/vmlinux.lds.S
+++ b/arch/sh/kernel/vmlinux.lds.S
@@ -23,7 +23,7 @@ OUTPUT_ARCH(sh)
 ENTRY(_start)
 SECTIONS
 {
-	. = PAGE_OFFSET + MEMORY_OFFSET + CONFIG_ZERO_PAGE_OFFSET;
+	. = PAGE_OFFSET + MEMORY_OFFSET + PHYSICAL_OFFSET + CONFIG_ZERO_PAGE_OFFSET;
 
 	_text = .;		/* Text and read-only data */
 
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 58a93fb3..c9dbace 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -287,6 +287,8 @@ static void __init do_init_bootmem(void)
 static void __init early_reserve_mem(void)
 {
 	unsigned long start_pfn;
+	u32 zero_base = (u32)__MEMORY_START + (u32)PHYSICAL_OFFSET;
+	u32 start = zero_base + (u32)CONFIG_ZERO_PAGE_OFFSET;
 
 	/*
 	 * Partially used pages are not usable - thus
@@ -300,15 +302,13 @@ static void __init early_reserve_mem(void)
 	 * this catches the (definitely buggy) case of us accidentally
 	 * initializing the bootmem allocator with an invalid RAM area.
 	 */
-	memblock_reserve(__MEMORY_START + CONFIG_ZERO_PAGE_OFFSET,
-		    (PFN_PHYS(start_pfn) + PAGE_SIZE - 1) -
-		    (__MEMORY_START + CONFIG_ZERO_PAGE_OFFSET));
+	memblock_reserve(start, (PFN_PHYS(start_pfn) + PAGE_SIZE - 1) - start);
 
 	/*
 	 * Reserve physical pages below CONFIG_ZERO_PAGE_OFFSET.
 	 */
 	if (CONFIG_ZERO_PAGE_OFFSET != 0)
-		memblock_reserve(__MEMORY_START, CONFIG_ZERO_PAGE_OFFSET);
+		memblock_reserve(zero_base, CONFIG_ZERO_PAGE_OFFSET);
 
 	/*
 	 * Handle additional early reservations
-- 
1.7.5.4


^ permalink raw reply related

* [RFC] sh: Take into account the base of physical memory in virt_to_phys()
From: Simon Horman @ 2011-09-15 11:12 UTC (permalink / raw)
  To: linux-sh

Previously virt_to_phys() assumed that physical memory always started
at address 0. This is not always the case.

Tested on an sh7757lcr (32bit system) whose only System RAM region is
40000000-4effffff

Signed-off-by: Simon Horman <horms@verge.net.au>
---
 kexec/arch/sh/kexec-sh.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/kexec/arch/sh/kexec-sh.c b/kexec/arch/sh/kexec-sh.c
index 4b21ee8..b0381bb 100644
--- a/kexec/arch/sh/kexec-sh.c
+++ b/kexec/arch/sh/kexec-sh.c
@@ -188,10 +188,18 @@ void kexec_sh_setup_zero_page(char *zero_page_buf, size_t zero_page_size,
 unsigned long virt_to_phys(unsigned long addr)
 {
 	unsigned long seg = addr & 0xe0000000;
+	unsigned long long start, end;
+	int ret;
+
+	/* Assume there is only one "System RAM" region */
+	ret = parse_iomem_single("System RAM\n", &start, &end);
+	if (ret)
+		die("Could not parse System RAM region in /proc/iomem\n");
+
 	if (seg != 0x80000000 && seg != 0xc0000000)
 		die("Virtual address %p is not in P1 or P2\n", (void *)addr);
 
-	return addr - seg;
+	return addr - seg + start;
 }
 
 /*
-- 
1.7.5.4


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox