* [patch 9/9] ps3fb: Round up video modes
From: Geert Uytterhoeven @ 2007-11-26 17:25 UTC (permalink / raw)
To: Linux Frame Buffer Device Development, Linux/PPC Development
Cc: Geert Uytterhoeven
In-Reply-To: <20071126172455.308741000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7809 bytes --]
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
ps3fb: Round up arbitrary video modes until they fit (if possible)
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/video/ps3fb.c | 160 +++++++++++++++++++++++++++++++++++---------------
1 files changed, 114 insertions(+), 46 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -275,29 +275,49 @@ static char *mode_option __devinitdata;
static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
const struct fb_var_screeninfo *var)
{
- /* resolution + black border must match a native resolution */
- if (vmode->left_margin + vmode->xres + vmode->right_margin !=
- var->left_margin + var->xres + var->right_margin ||
- vmode->upper_margin + vmode->yres + vmode->lower_margin !=
- var->upper_margin + var->yres + var->lower_margin)
+ long xres, yres, left_margin, right_margin, upper_margin, lower_margin;
+ long dx, dy;
+
+ /* maximum values */
+ if (var->xres > vmode->xres || var->yres > vmode->yres ||
+ var->pixclock > vmode->pixclock ||
+ var->hsync_len > vmode->hsync_len ||
+ var->vsync_len > vmode->vsync_len)
return -1;
- /* minimum limits for margins */
- if (vmode->left_margin > var->left_margin ||
- vmode->right_margin > var->right_margin ||
- vmode->upper_margin > var->upper_margin ||
- vmode->lower_margin > var->lower_margin)
+ /* progressive/interlaced must match */
+ if ((var->vmode & FB_VMODE_MASK) != vmode->vmode)
return -1;
- /* these fields must match exactly */
- if (vmode->pixclock != var->pixclock ||
- vmode->hsync_len != var->hsync_len ||
- vmode->vsync_len != var->vsync_len ||
- vmode->sync != var->sync ||
- vmode->vmode != (var->vmode & FB_VMODE_MASK))
+ /* minimum resolution */
+ xres = max(var->xres, 1U);
+ yres = max(var->yres, 1U);
+
+ /* minimum margins */
+ left_margin = max(var->left_margin, vmode->left_margin);
+ right_margin = max(var->right_margin, vmode->right_margin);
+ upper_margin = max(var->upper_margin, vmode->upper_margin);
+ lower_margin = max(var->lower_margin, vmode->lower_margin);
+
+ /* resolution + margins may not exceed native parameters */
+ dx = ((long)vmode->left_margin + (long)vmode->xres +
+ (long)vmode->right_margin) -
+ (left_margin + xres + right_margin);
+ if (dx < 0)
return -1;
- return 0;
+ dy = ((long)vmode->upper_margin + (long)vmode->yres +
+ (long)vmode->lower_margin) -
+ (upper_margin + yres + lower_margin);
+ if (dy < 0)
+ return -1;
+
+ /* exact match */
+ if (!dx && !dy)
+ return 0;
+
+ /* resolution difference */
+ return (vmode->xres - xres) * (vmode->yres - yres);
}
static const struct fb_videomode *ps3fb_native_vmode(enum ps3av_mode_num id)
@@ -323,33 +343,96 @@ static const struct fb_videomode *ps3fb_
static unsigned int ps3fb_find_mode(struct fb_var_screeninfo *var,
u32 *ddr_line_length, u32 *xdr_line_length)
{
- unsigned int id;
+ unsigned int id, best_id;
+ int diff, best_diff;
const struct fb_videomode *vmode;
+ long gap;
+ best_id = 0;
+ best_diff = INT_MAX;
+ pr_debug("%s: wanted %u [%u] %u x %u [%u] %u\n", __func__,
+ var->left_margin, var->xres, var->right_margin,
+ var->upper_margin, var->yres, var->lower_margin);
for (id = PS3AV_MODE_480I; id <= PS3AV_MODE_WUXGA; id++) {
vmode = ps3fb_native_vmode(id);
- if (!ps3fb_cmp_mode(vmode, var))
- goto found;
+ diff = ps3fb_cmp_mode(vmode, var);
+ pr_debug("%s: mode %u: %u [%u] %u x %u [%u] %u: diff = %d\n",
+ __func__, id, vmode->left_margin, vmode->xres,
+ vmode->right_margin, vmode->upper_margin,
+ vmode->yres, vmode->lower_margin, diff);
+ if (diff < 0)
+ continue;
+ if (diff < best_diff) {
+ best_id = id;
+ if (!diff)
+ break;
+ best_diff = diff;
+ }
}
- pr_debug("%s: mode not found\n", __func__);
- return 0;
+ if (!best_id) {
+ pr_debug("%s: no suitable mode found\n", __func__);
+ return 0;
+ }
+
+ id = best_id;
+ vmode = ps3fb_native_vmode(id);
-found:
*ddr_line_length = vmode->xres * BPP;
- if (!var->xres) {
+ /* minimum resolution */
+ if (!var->xres)
var->xres = 1;
- var->right_margin--;
- }
- if (!var->yres) {
+ if (!var->yres)
var->yres = 1;
- var->lower_margin--;
- }
+
+ /* minimum virtual resolution */
+ if (var->xres_virtual < var->xres)
+ var->xres_virtual = var->xres;
+ if (var->yres_virtual < var->yres)
+ var->yres_virtual = var->yres;
+
+ /* minimum margins */
+ if (var->left_margin < vmode->left_margin)
+ var->left_margin = vmode->left_margin;
+ if (var->right_margin < vmode->right_margin)
+ var->right_margin = vmode->right_margin;
+ if (var->upper_margin < vmode->upper_margin)
+ var->upper_margin = vmode->upper_margin;
+ if (var->lower_margin < vmode->lower_margin)
+ var->lower_margin = vmode->lower_margin;
+
+ /* extra margins */
+ gap = ((long)vmode->left_margin + (long)vmode->xres +
+ (long)vmode->right_margin) -
+ ((long)var->left_margin + (long)var->xres +
+ (long)var->right_margin);
+ if (gap > 0) {
+ var->left_margin += gap/2;
+ var->right_margin += (gap+1)/2;
+ pr_debug("%s: rounded up H to %u [%u] %u\n", __func__,
+ var->left_margin, var->xres, var->right_margin);
+ }
+
+ gap = ((long)vmode->upper_margin + (long)vmode->yres +
+ (long)vmode->lower_margin) -
+ ((long)var->upper_margin + (long)var->yres +
+ (long)var->lower_margin);
+ if (gap > 0) {
+ var->upper_margin += gap/2;
+ var->lower_margin += (gap+1)/2;
+ pr_debug("%s: rounded up V to %u [%u] %u\n", __func__,
+ var->upper_margin, var->yres, var->lower_margin);
+ }
+
+ /* fixed fields */
+ var->pixclock = vmode->pixclock;
+ var->hsync_len = vmode->hsync_len;
+ var->vsync_len = vmode->vsync_len;
+ var->sync = vmode->sync;
if (ps3_compare_firmware_version(1, 9, 0) >= 0) {
- *xdr_line_length = GPU_ALIGN_UP(max(var->xres,
- var->xres_virtual) * BPP);
+ *xdr_line_length = GPU_ALIGN_UP(var->xres_virtual * BPP);
if (*xdr_line_length > GPU_MAX_LINE_LENGTH)
*xdr_line_length = GPU_MAX_LINE_LENGTH;
} else
@@ -463,22 +546,11 @@ static int ps3fb_check_var(struct fb_var
u32 xdr_line_length, ddr_line_length;
int mode;
- dev_dbg(info->device, "var->xres:%u info->var.xres:%u\n", var->xres,
- info->var.xres);
- dev_dbg(info->device, "var->yres:%u info->var.yres:%u\n", var->yres,
- info->var.yres);
-
- /* FIXME For now we do exact matches only */
mode = ps3fb_find_mode(var, &ddr_line_length, &xdr_line_length);
if (!mode)
return -EINVAL;
/* Virtual screen */
- if (var->xres_virtual < var->xres)
- var->xres_virtual = var->xres;
- if (var->yres_virtual < var->yres)
- var->yres_virtual = var->yres;
-
if (var->xres_virtual > xdr_line_length / BPP) {
dev_dbg(info->device,
"Horizontal virtual screen size too large\n");
@@ -547,10 +619,6 @@ static int ps3fb_set_par(struct fb_info
const struct fb_videomode *vmode;
u64 dst;
- dev_dbg(info->device, "xres:%d xv:%d yres:%d yv:%d clock:%d\n",
- info->var.xres, info->var.xres_virtual,
- info->var.yres, info->var.yres_virtual, info->var.pixclock);
-
mode = ps3fb_find_mode(&info->var, &ddr_line_length, &xdr_line_length);
if (!mode)
return -EINVAL;
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [patch 7/9] ps3fb: Configurable black borders
From: Geert Uytterhoeven @ 2007-11-26 17:25 UTC (permalink / raw)
To: Linux Frame Buffer Device Development, Linux/PPC Development
Cc: Geert Uytterhoeven
In-Reply-To: <20071126172455.308741000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4174 bytes --]
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
ps3fb: Allow all video modes where the visible resolution plus the black
borders matches a native resolution
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
--
drivers/video/ps3fb.c | 69 +++++++++++++++++++++++++++++++++++---------------
1 files changed, 49 insertions(+), 20 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -269,32 +269,57 @@ module_param(ps3fb_mode, int, 0);
static char *mode_option __devinitdata;
-static unsigned int ps3fb_find_mode(const struct fb_var_screeninfo *var,
+static int ps3fb_cmp_mode(const struct fb_videomode *vmode,
+ const struct fb_var_screeninfo *var)
+{
+ /* resolution + black border must match a native resolution */
+ if (vmode->left_margin + vmode->xres + vmode->right_margin !=
+ var->left_margin + var->xres + var->right_margin ||
+ vmode->upper_margin + vmode->yres + vmode->lower_margin !=
+ var->upper_margin + var->yres + var->lower_margin)
+ return -1;
+
+ /* minimum limits for margins */
+ if (vmode->left_margin > var->left_margin ||
+ vmode->right_margin > var->right_margin ||
+ vmode->upper_margin > var->upper_margin ||
+ vmode->lower_margin > var->lower_margin)
+ return -1;
+
+ /* these fields must match exactly */
+ if (vmode->pixclock != var->pixclock ||
+ vmode->hsync_len != var->hsync_len ||
+ vmode->vsync_len != var->vsync_len ||
+ vmode->sync != var->sync ||
+ vmode->vmode != (var->vmode & FB_VMODE_MASK))
+ return -1;
+
+ return 0;
+}
+
+static unsigned int ps3fb_find_mode(struct fb_var_screeninfo *var,
u32 *ddr_line_length, u32 *xdr_line_length)
{
- unsigned int i, fi, mode;
+ unsigned int i, mode;
- for (i = 0; i < ARRAY_SIZE(ps3fb_modedb); i++)
- if (var->xres == ps3fb_modedb[i].xres &&
- var->yres == ps3fb_modedb[i].yres &&
- var->pixclock == ps3fb_modedb[i].pixclock &&
- var->hsync_len == ps3fb_modedb[i].hsync_len &&
- var->vsync_len == ps3fb_modedb[i].vsync_len &&
- var->left_margin == ps3fb_modedb[i].left_margin &&
- var->right_margin == ps3fb_modedb[i].right_margin &&
- var->upper_margin == ps3fb_modedb[i].upper_margin &&
- var->lower_margin == ps3fb_modedb[i].lower_margin &&
- var->sync == ps3fb_modedb[i].sync &&
- (var->vmode & FB_VMODE_MASK) == ps3fb_modedb[i].vmode)
+ for (i = PS3AV_MODE_1080P50; i < ARRAY_SIZE(ps3fb_modedb); i++)
+ if (!ps3fb_cmp_mode(&ps3fb_modedb[i], var))
goto found;
pr_debug("ps3fb_find_mode: mode not found\n");
return 0;
found:
- /* Cropped broadcast modes use the full line length */
- fi = i < PS3AV_MODE_1080P50 ? i + PS3AV_MODE_WUXGA : i;
- *ddr_line_length = ps3fb_modedb[fi].xres * BPP;
+ *ddr_line_length = ps3fb_modedb[i].xres * BPP;
+
+ if (!var->xres) {
+ var->xres = 1;
+ var->right_margin--;
+ }
+ if (!var->yres) {
+ var->yres = 1;
+ var->lower_margin--;
+ }
if (ps3_compare_firmware_version(1, 9, 0) >= 0) {
*xdr_line_length = GPU_ALIGN_UP(max(var->xres,
@@ -304,10 +329,14 @@ found:
} else
*xdr_line_length = *ddr_line_length;
- /* Full broadcast modes have the full mode bit set */
mode = i+1;
- if (mode > PS3AV_MODE_WUXGA)
- mode = (mode - PS3AV_MODE_WUXGA) | PS3AV_MODE_FULL;
+ if (mode > PS3AV_MODE_WUXGA) {
+ mode -= PS3AV_MODE_WUXGA;
+ /* Full broadcast modes have the full mode bit set */
+ if (ps3fb_modedb[i].xres == var->xres &&
+ ps3fb_modedb[i].yres == var->yres)
+ mode |= PS3AV_MODE_FULL;
+ }
pr_debug("ps3fb_find_mode: mode %u\n", mode);
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [patch 6/9] ps3fb: Make frame buffer offset unsigned int
From: Geert Uytterhoeven @ 2007-11-26 17:25 UTC (permalink / raw)
To: Linux Frame Buffer Device Development, Linux/PPC Development
Cc: Geert Uytterhoeven
In-Reply-To: <20071126172455.308741000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
ps3fb: Frame buffer offsets don't have to be `unsigned long', `unsigned int' is
sufficient
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/video/ps3fb.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -139,9 +139,9 @@ struct ps3fb_par {
unsigned int ddr_line_length;
unsigned int ddr_frame_size;
unsigned int xdr_frame_size;
- unsigned long full_offset; /* start of fullscreen DDR fb */
- unsigned long fb_offset; /* start of actual DDR fb */
- unsigned long pan_offset;
+ unsigned int full_offset; /* start of fullscreen DDR fb */
+ unsigned int fb_offset; /* start of actual DDR fb */
+ unsigned int pan_offset;
};
@@ -510,8 +510,7 @@ static int ps3fb_set_par(struct fb_info
{
struct ps3fb_par *par = info->par;
unsigned int mode, ddr_line_length, xdr_line_length, lines, maxlines;
- unsigned int ddr_xoff, ddr_yoff;
- unsigned long offset;
+ unsigned int ddr_xoff, ddr_yoff, offset;
const struct fb_videomode *vmode;
u64 dst;
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [patch 8/9] ps3fb: Reorganize modedb handling
From: Geert Uytterhoeven @ 2007-11-26 17:25 UTC (permalink / raw)
To: Linux Frame Buffer Device Development, Linux/PPC Development
Cc: Geert Uytterhoeven
In-Reply-To: <20071126172455.308741000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6597 bytes --]
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
ps3fb: Reorganize modedb handling:
- Reorder the video modes in ps3fb_modedb, for easier indexing using
PS3AV_MODE_* numbers,
- Introduce ps3fb_native_vmode(), to convert from native (PS3AV_MODE_*) mode
numbers to struct fb_videomode *,
- Rename and move ps3fb_default_mode() to ps3fb_vmode().
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/video/ps3fb.c | 116 +++++++++++++++++++++++++-------------------------
1 files changed, 60 insertions(+), 56 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -145,6 +145,8 @@ struct ps3fb_par {
};
+#define FIRST_NATIVE_MODE_INDEX 10
+
static const struct fb_videomode ps3fb_modedb[] = {
/* 60 Hz broadcast modes (modes "1" to "5") */
{
@@ -192,24 +194,7 @@ static const struct fb_videomode ps3fb_m
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
},
- /* VESA modes (modes "11" to "13") */
- {
- /* WXGA */
- "wxga", 60, 1280, 768, 12924, 160, 24, 29, 3, 136, 6,
- 0, FB_VMODE_NONINTERLACED,
- FB_MODE_IS_VESA
- }, {
- /* SXGA */
- "sxga", 60, 1280, 1024, 9259, 248, 48, 38, 1, 112, 3,
- FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
- FB_MODE_IS_VESA
- }, {
- /* WUXGA */
- "wuxga", 60, 1920, 1200, 6494, 80, 48, 26, 3, 32, 6,
- FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED,
- FB_MODE_IS_VESA
- },
-
+ [FIRST_NATIVE_MODE_INDEX] =
/* 60 Hz broadcast modes (full resolution versions of modes "1" to "5") */
{
/* 480if */
@@ -254,6 +239,24 @@ static const struct fb_videomode ps3fb_m
/* 1080pf */
"1080pf", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED
+ },
+
+ /* VESA modes (modes "11" to "13") */
+ {
+ /* WXGA */
+ "wxga", 60, 1280, 768, 12924, 160, 24, 29, 3, 136, 6,
+ 0, FB_VMODE_NONINTERLACED,
+ FB_MODE_IS_VESA
+ }, {
+ /* SXGA */
+ "sxga", 60, 1280, 1024, 9259, 248, 48, 38, 1, 112, 3,
+ FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT, FB_VMODE_NONINTERLACED,
+ FB_MODE_IS_VESA
+ }, {
+ /* WUXGA */
+ "wuxga", 60, 1920, 1200, 6494, 80, 48, 26, 3, 32, 6,
+ FB_SYNC_HOR_HIGH_ACT, FB_VMODE_NONINTERLACED,
+ FB_MODE_IS_VESA
}
};
@@ -297,20 +300,43 @@ static int ps3fb_cmp_mode(const struct f
return 0;
}
+static const struct fb_videomode *ps3fb_native_vmode(enum ps3av_mode_num id)
+{
+ return &ps3fb_modedb[FIRST_NATIVE_MODE_INDEX + id - 1];
+}
+
+static const struct fb_videomode *ps3fb_vmode(int id)
+{
+ u32 mode = id & PS3AV_MODE_MASK;
+
+ if (mode < PS3AV_MODE_480I || mode > PS3AV_MODE_WUXGA)
+ return NULL;
+
+ if (mode <= PS3AV_MODE_1080P50 && !(id & PS3AV_MODE_FULL)) {
+ /* Non-fullscreen broadcast mode */
+ return &ps3fb_modedb[mode - 1];
+ }
+
+ return ps3fb_native_vmode(mode);
+}
+
static unsigned int ps3fb_find_mode(struct fb_var_screeninfo *var,
u32 *ddr_line_length, u32 *xdr_line_length)
{
- unsigned int i, mode;
+ unsigned int id;
+ const struct fb_videomode *vmode;
- for (i = PS3AV_MODE_1080P50; i < ARRAY_SIZE(ps3fb_modedb); i++)
- if (!ps3fb_cmp_mode(&ps3fb_modedb[i], var))
+ for (id = PS3AV_MODE_480I; id <= PS3AV_MODE_WUXGA; id++) {
+ vmode = ps3fb_native_vmode(id);
+ if (!ps3fb_cmp_mode(vmode, var))
goto found;
+ }
- pr_debug("ps3fb_find_mode: mode not found\n");
+ pr_debug("%s: mode not found\n", __func__);
return 0;
found:
- *ddr_line_length = ps3fb_modedb[i].xres * BPP;
+ *ddr_line_length = vmode->xres * BPP;
if (!var->xres) {
var->xres = 1;
@@ -329,36 +355,14 @@ found:
} else
*xdr_line_length = *ddr_line_length;
- mode = i+1;
- if (mode > PS3AV_MODE_WUXGA) {
- mode -= PS3AV_MODE_WUXGA;
+ if (vmode->sync & FB_SYNC_BROADCAST) {
/* Full broadcast modes have the full mode bit set */
- if (ps3fb_modedb[i].xres == var->xres &&
- ps3fb_modedb[i].yres == var->yres)
- mode |= PS3AV_MODE_FULL;
- }
-
- pr_debug("ps3fb_find_mode: mode %u\n", mode);
-
- return mode;
-}
-
-static const struct fb_videomode *ps3fb_default_mode(int id)
-{
- u32 mode = id & PS3AV_MODE_MASK;
- u32 flags;
-
- if (mode < PS3AV_MODE_480I || mode > PS3AV_MODE_WUXGA)
- return NULL;
-
- flags = id & ~PS3AV_MODE_MASK;
-
- if (mode <= PS3AV_MODE_1080P50 && flags & PS3AV_MODE_FULL) {
- /* Full broadcast mode */
- return &ps3fb_modedb[mode + PS3AV_MODE_WUXGA - 1];
+ if (vmode->xres == var->xres && vmode->yres == var->yres)
+ id |= PS3AV_MODE_FULL;
}
- return &ps3fb_modedb[mode - 1];
+ pr_debug("%s: mode %u\n", __func__, id);
+ return id;
}
static void ps3fb_sync_image(struct device *dev, u64 frame_offset,
@@ -551,7 +555,7 @@ static int ps3fb_set_par(struct fb_info
if (!mode)
return -EINVAL;
- vmode = ps3fb_default_mode(mode | PS3AV_MODE_FULL);
+ vmode = ps3fb_native_vmode(mode & PS3AV_MODE_MASK);
info->fix.smem_start = virt_to_abs(ps3fb.xdr_ea);
info->fix.smem_len = ps3fb.xdr_size;
@@ -765,7 +769,7 @@ static int ps3fb_ioctl(struct fb_info *i
case PS3FB_IOCTL_SETMODE:
{
struct ps3fb_par *par = info->par;
- const struct fb_videomode *mode;
+ const struct fb_videomode *vmode;
struct fb_var_screeninfo var;
if (copy_from_user(&val, argp, sizeof(val)))
@@ -778,10 +782,10 @@ static int ps3fb_ioctl(struct fb_info *i
}
dev_dbg(info->device, "PS3FB_IOCTL_SETMODE:%x\n", val);
retval = -EINVAL;
- mode = ps3fb_default_mode(val);
- if (mode) {
+ vmode = ps3fb_vmode(val);
+ if (vmode) {
var = info->var;
- fb_videomode_to_var(&var, mode);
+ fb_videomode_to_var(&var, vmode);
acquire_console_sem();
info->flags |= FBINFO_MISC_USEREVENT;
/* Force, in case only special bits changed */
@@ -1125,7 +1129,7 @@ static int __devinit ps3fb_probe(struct
if (!fb_find_mode(&info->var, info, mode_option, ps3fb_modedb,
ARRAY_SIZE(ps3fb_modedb),
- ps3fb_default_mode(par->new_mode_id), 32)) {
+ ps3fb_vmode(par->new_mode_id), 32)) {
retval = -EINVAL;
goto err_fb_dealloc;
}
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [patch 5/9] ps3fb: Kill ps3fb_res
From: Geert Uytterhoeven @ 2007-11-26 17:25 UTC (permalink / raw)
To: Linux Frame Buffer Device Development, Linux/PPC Development
Cc: Geert Uytterhoeven
In-Reply-To: <20071126172455.308741000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7873 bytes --]
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
ps3fb: kill ps3fb_res[], as all information it contains can be obtained in
some other way.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/video/ps3fb.c | 108 ++++++++++----------------------------------------
1 files changed, 22 insertions(+), 86 deletions(-)
--- a/drivers/video/ps3fb.c
+++ b/drivers/video/ps3fb.c
@@ -133,42 +133,17 @@ static struct ps3fb_priv ps3fb;
struct ps3fb_par {
u32 pseudo_palette[16];
int mode_id, new_mode_id;
- int res_index;
unsigned int num_frames; /* num of frame buffers */
unsigned int width;
unsigned int height;
+ unsigned int ddr_line_length;
+ unsigned int ddr_frame_size;
+ unsigned int xdr_frame_size;
unsigned long full_offset; /* start of fullscreen DDR fb */
unsigned long fb_offset; /* start of actual DDR fb */
unsigned long pan_offset;
};
-struct ps3fb_res_table {
- u32 xres;
- u32 yres;
- u32 xoff;
- u32 yoff;
- u32 type;
-};
-#define PS3FB_RES_FULL 1
-static const struct ps3fb_res_table ps3fb_res[] = {
- /* res_x,y margin_x,y full */
- { 720, 480, 72, 48 , 0},
- { 720, 576, 72, 58 , 0},
- { 1280, 720, 78, 38 , 0},
- { 1920, 1080, 116, 58 , 0},
- /* full mode */
- { 720, 480, 0, 0 , PS3FB_RES_FULL},
- { 720, 576, 0, 0 , PS3FB_RES_FULL},
- { 1280, 720, 0, 0 , PS3FB_RES_FULL},
- { 1920, 1080, 0, 0 , PS3FB_RES_FULL},
- /* vesa: normally full mode */
- { 1280, 768, 0, 0 , 0},
- { 1280, 1024, 0, 0 , 0},
- { 1920, 1200, 0, 0 , 0},
- { 0, 0, 0, 0 , 0} };
-
-/* default resolution */
-#define GPU_RES_INDEX 0 /* 720 x 480 */
static const struct fb_videomode ps3fb_modedb[] = {
/* 60 Hz broadcast modes (modes "1" to "5") */
@@ -294,37 +269,6 @@ module_param(ps3fb_mode, int, 0);
static char *mode_option __devinitdata;
-static int ps3fb_get_res_table(u32 xres, u32 yres, int mode)
-{
- int full_mode;
- unsigned int i;
- u32 x, y, f;
-
- full_mode = (mode & PS3AV_MODE_FULL) ? PS3FB_RES_FULL : 0;
- for (i = 0;; i++) {
- x = ps3fb_res[i].xres;
- y = ps3fb_res[i].yres;
- f = ps3fb_res[i].type;
-
- if (!x) {
- pr_debug("ERROR: ps3fb_get_res_table()\n");
- return -1;
- }
-
- if (full_mode == PS3FB_RES_FULL && f != PS3FB_RES_FULL)
- continue;
-
- if (x == xres && (yres == 0 || y == yres))
- break;
-
- x = x - 2 * ps3fb_res[i].xoff;
- y = y - 2 * ps3fb_res[i].yoff;
- if (x == xres && (yres == 0 || y == yres))
- break;
- }
- return i;
-}
-
static unsigned int ps3fb_find_mode(const struct fb_var_screeninfo *var,
u32 *ddr_line_length, u32 *xdr_line_length)
{
@@ -431,8 +375,7 @@ static void ps3fb_sync_image(struct devi
static int ps3fb_sync(struct fb_info *info, u32 frame)
{
struct ps3fb_par *par = info->par;
- int i, error = 0;
- u32 ddr_line_length, xdr_line_length;
+ int error = 0;
u64 ddr_base, xdr_base;
acquire_console_sem();
@@ -444,16 +387,13 @@ static int ps3fb_sync(struct fb_info *in
goto out;
}
- i = par->res_index;
- xdr_line_length = info->fix.line_length;
- ddr_line_length = ps3fb_res[i].xres * BPP;
- xdr_base = frame * info->var.yres_virtual * xdr_line_length;
- ddr_base = frame * ps3fb_res[i].yres * ddr_line_length;
+ xdr_base = frame * par->xdr_frame_size;
+ ddr_base = frame * par->ddr_frame_size;
ps3fb_sync_image(info->device, ddr_base + par->full_offset,
ddr_base + par->fb_offset, xdr_base + par->pan_offset,
- par->width, par->height, ddr_line_length,
- xdr_line_length);
+ par->width, par->height, par->ddr_line_length,
+ info->fix.line_length);
out:
release_console_sem();
@@ -570,8 +510,9 @@ static int ps3fb_set_par(struct fb_info
{
struct ps3fb_par *par = info->par;
unsigned int mode, ddr_line_length, xdr_line_length, lines, maxlines;
- int i;
+ unsigned int ddr_xoff, ddr_yoff;
unsigned long offset;
+ const struct fb_videomode *vmode;
u64 dst;
dev_dbg(info->device, "xres:%d xv:%d yres:%d yv:%d clock:%d\n",
@@ -582,8 +523,7 @@ static int ps3fb_set_par(struct fb_info
if (!mode)
return -EINVAL;
- i = ps3fb_get_res_table(info->var.xres, info->var.yres, mode);
- par->res_index = i;
+ vmode = ps3fb_default_mode(mode | PS3AV_MODE_FULL);
info->fix.smem_start = virt_to_abs(ps3fb.xdr_ea);
info->fix.smem_len = ps3fb.xdr_size;
@@ -593,9 +533,12 @@ static int ps3fb_set_par(struct fb_info
info->screen_base = (char __iomem *)ps3fb.xdr_ea;
+ par->ddr_line_length = ddr_line_length;
+ par->ddr_frame_size = vmode->yres * ddr_line_length;
+ par->xdr_frame_size = info->var.yres_virtual * xdr_line_length;
+
par->num_frames = ps3fb.xdr_size /
- max(ps3fb_res[i].yres * ddr_line_length,
- info->var.yres_virtual * xdr_line_length);
+ max(par->ddr_frame_size, par->xdr_frame_size);
/* Keep the special bits we cannot set using fb_var_screeninfo */
par->new_mode_id = (par->new_mode_id & ~PS3AV_MODE_MASK) | mode;
@@ -604,7 +547,9 @@ static int ps3fb_set_par(struct fb_info
par->height = info->var.yres;
/* Start of the virtual frame buffer (relative to fullscreen) */
- offset = ps3fb_res[i].yoff * ddr_line_length + ps3fb_res[i].xoff * BPP;
+ ddr_xoff = info->var.left_margin - vmode->left_margin;
+ ddr_yoff = info->var.upper_margin - vmode->upper_margin;
+ offset = ddr_yoff * ddr_line_length + ddr_xoff * BPP;
par->fb_offset = GPU_ALIGN_UP(offset);
par->full_offset = par->fb_offset - offset;
@@ -623,13 +568,13 @@ static int ps3fb_set_par(struct fb_info
memset(ps3fb.xdr_ea, 0, ps3fb.xdr_size);
/* Clear DDR frame buffer memory */
- lines = ps3fb_res[i].yres * par->num_frames;
+ lines = vmode->yres * par->num_frames;
if (par->full_offset)
lines++;
maxlines = ps3fb.xdr_size / ddr_line_length;
for (dst = 0; lines; dst += maxlines * ddr_line_length) {
unsigned int l = min(lines, maxlines);
- ps3fb_sync_image(info->device, 0, dst, 0, ps3fb_res[i].xres, l,
+ ps3fb_sync_image(info->device, 0, dst, 0, vmode->xres, l,
ddr_line_length, ddr_line_length);
lines -= l;
}
@@ -1047,14 +992,13 @@ static int __devinit ps3fb_probe(struct
struct fb_info *info;
struct ps3fb_par *par;
int retval = -ENOMEM;
- u32 xres, yres;
u64 ddr_lpar = 0;
u64 lpar_dma_control = 0;
u64 lpar_driver_info = 0;
u64 lpar_reports = 0;
u64 lpar_reports_size = 0;
u64 xdr_lpar;
- int status, res_index;
+ int status;
struct task_struct *task;
unsigned long max_ps3fb_size;
@@ -1069,13 +1013,6 @@ static int __devinit ps3fb_probe(struct
ps3fb_mode = ps3av_get_mode();
dev_dbg(&dev->core, "ps3fb_mode: %d\n", ps3fb_mode);
- if (ps3fb_mode > 0 &&
- !ps3av_video_mode2res(ps3fb_mode, &xres, &yres)) {
- res_index = ps3fb_get_res_table(xres, yres, ps3fb_mode);
- dev_dbg(&dev->core, "res_index:%d\n", res_index);
- } else
- res_index = GPU_RES_INDEX;
-
atomic_set(&ps3fb.f_count, -1); /* fbcon opens ps3fb */
atomic_set(&ps3fb.ext_flip, 0); /* for flip with vsync */
init_waitqueue_head(&ps3fb.wait_vsync);
@@ -1142,7 +1079,6 @@ static int __devinit ps3fb_probe(struct
par = info->par;
par->mode_id = ~ps3fb_mode; /* != ps3fb_mode, to trigger change */
par->new_mode_id = ps3fb_mode;
- par->res_index = res_index;
par->num_frames = 1;
info->screen_base = (char __iomem *)ps3fb.xdr_ea;
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: sys_mpc83xx spi driver not probed
From: Anton Vorontsov @ 2007-11-26 17:40 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071126163956.GB4408@loki.buserror.net>
On Mon, Nov 26, 2007 at 10:39:56AM -0600, Scott Wood wrote:
> On Fri, Nov 23, 2007 at 07:02:23PM +0200, Joel Rouch wrote:
> > I have a custom 8349 ppc board. I have defined the spi master in the
> > configuration.
> > While booting my board, I driver is well added and linked to platform
> > bus, however I don't see that the probe entry point is reached.
> > I don't succeed to understand who is triggering the probe. Can someone
> > point me to the right link or explain me how to force it ?
>
> Are you calling of_platform_bus_probe() from your board file?
spi_mpc83xx isn't of_platform_driver, yet. Thus we have to use fsl helper,
fsl_spi_init.
So far, good example of spi_mpc83xx usage is in
arch/powerpc/platforms/83xx/mpc832x_rdb.c
Good luck,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Access to PCI Expansion ROMs on PPC
From: Robin H. Johnson @ 2007-11-26 17:35 UTC (permalink / raw)
To: Jon Smirl, linuxppc-dev; +Cc: Michel D?nzer
In-Reply-To: <9e4733910711260833t5053ed5fu5227046565eae86b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
On Mon, Nov 26, 2007 at 11:33:00AM -0500, Jon Smirl wrote:
> Did you check out the cards on x86 and ascertain that they have the
> standard PCI header in them? 55 AA .... All PCI ROMs are supposed to
> have that. If they are missing that the size code in the rom.c isn't
> going to work right.
See my more recent testing summary post to the list, with the message-id
of 20071126085928.GE14557@curie-int.orbis-terrarum.net
(http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046880.html)
The X1900 and Nvidia OF-based cards do not turn up on the x86_64 box at
all (the PCIe root node is entirely missing with them as well), and the
sata_mv claims to not have a ROM, but does otherwise work.
> If these are OF ROM and you are booting on OF firmware, the ROM is
> getting run. In that case it may not be so simple to turn them back on
> if they have been hidden using a proprietary register. That's the
> quirk BenH has referred to.
That's the path that I was investigating with the register stuff via
airlied's avivotool. There was one register he thought about, but it
didn't seem to do much.
I also found some instructions to try and view the ROMs from inside OF,
some I'm going to try that later today, as that will enable seeing if
Linux is changing something critical.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 321 bytes --]
^ permalink raw reply
* Re: [RFC/PATCHv4] powerpc: Move CPM command handling into the cpm drivers
From: Arnd Bergmann @ 2007-11-26 17:40 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <474AFC6C.9020007@scram.de>
On Monday 26 November 2007, Jochen Friedrich wrote:
> This patch moves the CPM command handling into commproc.c
> for CPM1 and cpm2_common.c. This is yet another preparation
> to get rid of drivers accessing the CPM via the global cpmp.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: robert lazarski @ 2007-11-26 17:41 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <7C2ED552-6644-4FB3-A97B-05FC3E2141FF@kernel.crashing.org>
Hi Kumar, I finally got time to get back to this:
On Nov 17, 2007 2:52 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>
>
> On Nov 16, 2007, at 4:01 PM, robert lazarski wrote:
>
> >>>
> >>> Sorry for replying to myself, but thought I'd mention SRESET works
> >>> fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
> >>> doesn't work for me on 2.6.24rc2 .
> >>
> >> What actual 85xx are you using?
> >>
> >> - k
> >>
> >
> > Custom 8548 board. I'm using the cds 85xx code for a reference and I
> > calling the same reset functions.
> >
> 1. do you have the following in your dts:
>
> global-utilities@e0000 { //global utilities reg
> compatible = "fsl,mpc8548-guts";
> reg = <e0000 1000>;
> fsl,has-rstcr;
> };
>
Yes.
>
> 2. in your platform code are you using fsl_rstcr_restart in
> define_machine()
>
> - k
>
Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
calling 'reboot' in the shell, it just hangs. Using the same dts and
resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
someone who does should be able to confirm whether the issue exists or
not by just attempting to reboot via bash.
Robert
^ permalink raw reply
* Re: [PATCH] ehea: Add kdump support
From: Linas Vepstas @ 2007-11-26 18:11 UTC (permalink / raw)
To: Luke Browning
Cc: Michael Neuling, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, Thomas Klein, linux-ppc, Christoph Raisch,
Paul Mackerras, Marcus Eder, Stefan Roscher
In-Reply-To: <1196091697.7513.30.camel@luke-laptop.br.ibm.com>
Hi,
On Mon, Nov 26, 2007 at 01:41:37PM -0200, Luke Browning wrote:
> On Mon, 2007-11-26 at 19:16 +1100, Michael Ellerman wrote:
>
> > For kdump we have to assume that the kernel is fundamentally broken,
If I may so humbly suggest: since ehea is a power6 thing only,
we should refocus our energies on "hypervisor assisted dump",
which solves all of these problems.
In short, upon crash, the hypervisor will reset the
pci devices into working order, and will then boot
a new fresh kernel into a tiny corner of ram. The rest
of ram is not cleared, and can be dumped. After the
dump, the mem is returned to general use.
The key point here, for ehea, is "the hypervisor
will reset he device state to something rational".
Preliminary patches are at
http://patchwork.ozlabs.org/linuxppc/patch?id=14884
and following.
--linas
^ permalink raw reply
* Device tree and /proc/iomem question
From: robert lazarski @ 2007-11-26 18:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi all, I'm using a recent pull of the paulus tree 2.6.24RC2 on my
custom 85xx board. I'm trying to test my PCI1, PCI2 and PCIe . My
device tree for PCI is:
pci@8000 {
compatible = "fsl,mpc8540-pci";
device_type = "pci";
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 J17 Slot 1 */
8800 0 0 1 &mpic 2 1
8800 0 0 2 &mpic 3 1
8800 0 0 3 &mpic 4 1
8800 0 0 4 &mpic 1 1
/* IDSEL 0x12 J16 Slot 2 */
9000 0 0 1 &mpic 3 1
9000 0 0 2 &mpic 4 1
9000 0 0 3 &mpic 2 1
9000 0 0 4 &mpic 1 1>;
interrupt-parent = <&mpic>;
interrupts = <18 2>;
bus-range = <0 ff>;
ranges = <02000000 0 80000000 80000000 0 20000000
01000000 0 00000000 e2000000 0 00100000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <8000 1000>;
};
pci@c000 {
compatible = "fsl,mpc8540-pci";
device_type = "pci";
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x11 J17 Slot 1 */
8800 0 0 1 &mpic 2 1
8800 0 0 2 &mpic 3 1
8800 0 0 3 &mpic 4 1
8800 0 0 4 &mpic 1 1
/* IDSEL 0x12 J16 Slot 2 */
9000 0 0 1 &mpic 3 1
9000 0 0 2 &mpic 4 1
9000 0 0 3 &mpic 2 1
9000 0 0 4 &mpic 1 1>;
interrupt-parent = <&mpic>;
interrupts = <18 2>;
bus-range = <0 ff>;
ranges = <02000000 0 c0000000 c0000000 0 20000000
01000000 0 00000000 e2800000 0 00100000>;
clock-frequency = <3f940aa>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <c000 1000>;
};
pcie@a000 {
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <a000 1000>;
bus-range = <0 ff>;
ranges = <02000000 0 a0000000 a0000000 0 20000000
01000000 0 00000000 e3000000 0 00100000>;
clock-frequency = <1fca055>;
interrupt-parent = <&mpic>;
interrupts = <19 2>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x0 */
0000 0 0 1 &mpic 0 1
0000 0 0 2 &mpic 1 1
0000 0 0 3 &mpic 2 1
0000 0 0 4 &mpic 3 1
>;
};
I see all the above in /proc/device-tree/soc8548@e0000000 when booting
the kernel. I double checked my memory mapping in u-boot and it
appears to match my device tree. Yet I don't see any pci here:
root:~> cat /proc/iomem
e0004500-e0004507 : serial
e0004600-e0004607 : serial
e0024000-e0024fff : ethernet
e0024520-e002453f : mdio
e0025000-e0025fff : ethernet
e0026000-e0026fff : ethernet
e0027000-e0027fff : ethernet
cat /proc/bus/pci/devices shows nothing though I have a card in PCI1,
and all I see from dmesg is "PCI: Probing PCI hardware" . Any ideas?
Robert
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Steven A. Falco @ 2007-11-26 19:10 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200711261720.26629.sr@denx.de>
[-- Attachment #1.1: Type: text/plain, Size: 2370 bytes --]
I've attached a copy of my bootlog. I added in one patch to enable
rgmii but that didn't fix it.
(http://ozlabs.org/pipermail/linuxppc-dev/2007-October/043435.html)
I am curious why the new emac driver is enabled in the DENX tree but not
in the upstream trees. Has DENX successfully used this driver on the
Sequoia board? Am I trying something that is known not to work?
I'm interested in helping in whatever way I can. I need ARCH=powerpc to
use the current Xenomai patches, and I need both EMACs so I can evaluate
bonding (for high-availability).
Thanks,
Steve
Stefan Roese wrote:
> On Monday 26 November 2007, Steven A. Falco wrote:
>
>> I have noticed odd behavior on a Sequoia board. Kernel is built from
>> DENX git, ARCH=powerpc, 2.6.23.1.
>>
>> Sequence that works:
>> 1) In u-boot, do "dhcp" (this initializes the PHY)
>> 2) Boot linux from flash
>> 3) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
>> Ethernet is now functional, and I can ping the Sequoia (and it can ping
>> my host)
>>
>> Sequence that does not work:
>> 1) Boot linux from flash without letting u-boot touch eth0
>> 2) ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
>> Ethernet appears to come up, but it is not functional. I.e. I get
>> "eth0: link is up, 100 FDX, pause enabled" but I cannot ping the board,
>> and the board cannot ping my host.
>>
>
> Do you have a 100MBit connection? Or Gbit? Could you please send the complete
> bootlog.
>
>
>> So, the kernel appears to be missing some initialization that u-boot
>> provides.
>>
>> However, eth1 is more strange. U-boot can use it (via "setenv ethact
>> ppc_4xx_eth1;dhcp"), however, the kernel cannot use it, whether or not
>> u-boot first initializes it.
>>
>> If anyone has suggestions on where to look, I'd appreciate it. I'm
>> going to look at the PHY register settings and see if there are any
>> clues there...
>>
>
> Again it would be interesting to see the bootlog here.
>
> Best regards,
> Stefan
>
> =====================================================================
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
> =====================================================================
>
>
[-- Attachment #1.2: Type: text/html, Size: 3055 bytes --]
[-- Attachment #2: broke --]
[-- Type: text/plain, Size: 8829 bytes --]
=> run saf
## Booting image at fc000000 ...
Image Name: Linux-2.6.23.1-gb68e890e-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1623086 Bytes = 1.5 MB
Load Address: 00400000
Entry Point: 004003e0
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at fc2c0000 ...
Image Name: Sequoia Ramdisk RCD-05
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1169588 Bytes = 1.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fe0d000, end 0ff2a8b4 ... OK
CPU clock-frequency <- 0x27bc86ae (667MHz)
CPU timebase-frequency <- 0x27bc86ae (667MHz)
/plb: clock-frequency <- 9ef21ab (167MHz)
/plb/opb: clock-frequency <- 4f790d5 (83MHz)
/plb/opb/ebc: clock-frequency <- 34fb5e3 (56MHz)
/plb/opb/serial@ef600300: clock-frequency <- a8c000 (11MHz)
/plb/opb/serial@ef600400: clock-frequency <- a8c000 (11MHz)
/plb/opb/serial@ef600500: clock-frequency <- a8c000 (11MHz)
/plb/opb/serial@ef600600: clock-frequency <- a8c000 (11MHz)
Memory <- <0x0 0x0 0x10000000> (256MB)
ENET0: local-mac-address <- 00:10:ec:00:e2:85
ENET1: local-mac-address <- 00:10:ec:80:e2:85
zImage starting: loaded at 0x00400000 (sp: 0x0ff2b568)
Allocating 0x39068c bytes for kernel ...
gunzipping (0x00000000 <- 0x0040c000:0x0076e178)...done 0x34aaac bytes
Using loader supplied ramdisk at 0xfe0d000-0xff2a8b4
initrd head: 0x1f8b0808
Linux/PowerPC load: root=/dev/ram rw console=ttyS0,115200
Finalizing device tree... flat tree at 0x77b3a0
Using Sequoia machine description
Linux version 2.6.23.1-gb68e890e-dirty (sfalco@saf.cs.myharris.net) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #8 Mon Nov 26 13:05:59 EST 2007
Found initrd at 0xcfe0d000:0xcff2a8b4
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
Built 1 zonelists in Zone order. Total pages: 65024
Kernel command line: root=/dev/ram rw console=ttyS0,115200
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
PID hash table entries: 1024 (order: 10, 4096 bytes)
I-pipe 2.0-03: pipeline enabled.
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 254772k/262144k available (3192k kernel code, 7064k reserved, 160k data, 277k bss, 136k init)
Mount-cache hash table entries: 512
NET: Registered protocol family 16
PCI: Probing PCI hardware
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1142k freed
I-pipe: Domain Xenomai registered.
Xenomai: hal/powerpc started.
Xenomai: real-time nucleus v2.4-rc6 (Bells Of Lal) loaded.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
1ef600300.serial: ttyS0 at MMIO 0x1ef600300 (irq = 16) is a 16550A
console [ttyS0] enabled
1ef600400.serial: ttyS1 at MMIO 0x1ef600400 (irq = 17) is a 16550A
1ef600500.serial: ttyS2 at MMIO 0x1ef600500 (irq = 18) is a 16550A
1ef600600.serial: ttyS3 at MMIO 0x1ef600600 (irq = 19) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 35000K size 1024 blocksize
PPC 4xx OCP EMAC driver, version 3.54
MAL v2 /plb/mcmal, 4 TX channels, 4 RX channels
ZMII /plb/opb/emac-zmii@ef600d00 initialized
RGMII standard /plb/opb/emac-rgmii@ef601000 initialized
/plb/opb/emac-rgmii@ef601000: input 0 in RGMII mode
eth0: EMAC-0 /plb/opb/ethernet@ef600e00, MAC 00:10:ec:00:e2:85
eth0: found Generic MII PHY (0x00)
/plb/opb/emac-rgmii@ef601000: input 1 in RGMII mode
eth1: EMAC-1 /plb/opb/ethernet@ef600f00, MAC 00:10:ec:80:e2:85
eth1: found Generic MII PHY (0x01)
physmap-flash 1fc000000.nor_flash: Device tree uses obsolete "direct-mapped" flash binding
1fc000000.nor_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
1fc000000.nor_flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
RedBoot partition parsing not available
physmap-flash 1fc000000.nor_flash: Device tree uses obsolete partition map binding
Creating 5 MTD partitions on "1fc000000.nor_flash":
0x00000000-0x002c0000 : "kernel"
0x002c0000-0x00400000 : "root"
0x00400000-0x03f60000 : "usr"
0x03f60000-0x03fa0000 : "env"
0x03fa0000-0x04000000 : "u-boot"
NDFC NAND Driver initialized. Chip-Rev: 0x00000110
NAND device: Manufacturer ID: 0x20, Chip ID: 0x75 (ST Micro NAND 32MiB 3,3V 8-bit)
Scanning device for bad blocks
Number of partitions 1
Creating 1 MTD partitions on "NAND 32MiB 3,3V 8-bit":
0x00000000-0x02000000 : "content"
usbmon: debugfs is not available
ppc-of-ehci e0000300.ehci: OF EHCI
ppc-of-ehci e0000300.ehci: new USB bus registered, assigned bus number 1
ppc-of-ehci e0000300.ehci: irq 32, io mem 0xe0000300
ppc-of-ehci e0000300.ehci: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
ether gadget: using random self ethernet address
ether gadget: using random host ethernet address
usb0: Ethernet Gadget, version: May Day 2005
usb0: using musbhsfc_udc, OUT ep2 IN ep1 STATUS ep3
usb0: MAC da:82:03:7c:d0:81
usb0: HOST MAC 5a:a1:bf:a5:ae:d5
usb0: RNDIS ready
musbhsfc_udc: registered gadget driver 'ether'
i2c /dev entries driver
IBM IIC driver v2.1
ibm-iic(/plb/opb/i2c@ef600700): using standard (100 kHz) mode
ibm-iic(/plb/opb/i2c@ef600800): using standard (100 kHz) mode
ad7414 0-0048: chip found, driver version 0.1
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 136k init
AMCC Startup utility launched.
Please press Enter to activate this console.
BusyBox v1.2.1 (2007.06.08-14:45+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
~ # ifconfig eth0 192.168.0.101 netmask 255.255.255.0 ueth0: link is up, 100 FDX, pause enabled
p
~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:EC:00:E2:85
inet addr:192.168.0.101 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:180 (180.0 B) TX bytes:126 (126.0 B)
Interrupt:26
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
~ # ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1): 56 data bytes
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:10:EC:00:E2:85
inet addr:192.168.0.101 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:180 (180.0 B) TX bytes:336 (336.0 B)
Interrupt:26
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:336 (336.0 B) TX bytes:336 (336.0 B)
~ #
^ permalink raw reply
* Re: initramfs and busybox kernel oops
From: David H. Lynch Jr. @ 2007-11-26 19:14 UTC (permalink / raw)
To: fabien, linuxppc-embedded
In-Reply-To: <f8f856500711260716m6bd6a89and056f9e196d9d1bf@mail.gmail.com>
fabien wrote:
> hi all,
>
> I'm trying to get busybox working on my custom board mpc855t and linux
> kernel 2.6.19 (from eldk 4.1 uclibc). I've built an initramfs that i
> link directly in kernel. To verify whether the kernel is able to lauch
> the init process i've compiled a small hello world program. But no
> when i try with busybox 1.8.1 staticaly linked i got an Oops error
> kernel access to bad area. I don't know why the former work fine but
> no the latter.
> If someone have some ideas for where to look for ?
>
> In my initramfs there is :
> in /dev :
> crw-r--r-- 1 root root 5, 1 nov 22 13:32 console
> crw-rw-rw- 1 root root 1, 3 nov 26 10:10 null
> crw------- 1 root root 4, 1 nov 26 10:11 tty1
> in /bin :
> lrwxrwxrwx 1 root root 7 nov 26 10:17 ash -> busybox*
> -rwxr-xr-x 1 root root 793804 nov 26 13:57 busybox*
> lrwxrwxrwx 1 root root 7 nov 26 10:17 cat -> busybox*
> (and others links)
> My init script file (/init) :
> #!/bin/sh
> /bin/ash
>
It took me a while to get initramfs running. But after I did I have been
very happy with it.
It is possible you need more in /dev.
My initramfs has much more than yours - though it is still quite small.
I sort of stole it from somewhere. I think I took an initrd from
somewhere expanded it an culled out what iI did not want.
Busybox is still the bulk by volume, but that got me all the /dev /etc/
... stuff I needed
You can pull mine from http://www.picocomputing.net/files/initramfs/
^ permalink raw reply
* Re: pseries (power3) boot hang (pageblock_nr_pages==0)
From: Will Schmidt @ 2007-11-26 19:35 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, Stephen Rothwell, Linux Memory Management List
In-Reply-To: <20071121220337.GB31674@csn.ul.ie>
On Wed, 2007-11-21 at 22:03 +0000, Mel Gorman wrote:
> On (21/11/07 15:55), Will Schmidt didst pronounce:
> > Hi Folks,
> >
> > I imagine this would be properly fixed with something similar to the
> > change for iSeries.
>
> Have you tried with the patch that fixed the iSeries boot problem?
> Thanks for tracking down the problem to such a specific place.
I had not, but gave this patch a spin this morning, and it does the
job. :-) I was thinking (without really looking at it), that the
iseries fix was in platform specific code. Silly me. :-)
So for the record, this patch also fixes power3 pSeries systems.
fwiw:
Tested-By: Will Schmidt <will_schmidt@vnet.ibm.com>
Thanks,
-Will
> ======
>
> Ordinarily, the size of a pageblock is determined at compile-time based on
> the hugepage size. On PPC64, the hugepage size is determined at runtime based
> on what is supported by the machine. On legacy machines such as iSeries which
> do not support hugepages, HPAGE_SHIFT is 0. This results in pageblock_order
> being set to -PAGE_SHIFT and a crash results shortly afterwards.
>
> This patch checks that HPAGE_SHIFT is a sensible value before using the
> hugepage size. If it is 0, MAX_ORDER-1 is used instead as this is a sensible
> value of pageblock_order.
>
> This is a fix for 2.6.24.
>
> Credit goes to Stephen Rothwell for identifying the bug and testing on
> iSeries. Additional credit goes to David Gibson for testing with the
> libhugetlbfs test suite.
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
>
> ---
^ permalink raw reply
* Re: SPI driver for spi_mpc83xx
From: Ben Warren @ 2007-11-26 19:42 UTC (permalink / raw)
To: fabio777; +Cc: linuxppc-embedded
In-Reply-To: <4749310D.1090008@gmail.com>
fabio777 wrote:
> Has anyone been using this driver ?
>
I use it, on ARCH=powerpc, though.
> For legacy reasons I need to keep the ppc=arch however I haven't found
> out how to get this driver probed at start-up even basing my init on
> Lublock.
>
>
The driver's expecting a platform device with name "mpc83xx_spi" to be
registered in board init code. If you post your init code I may be able
to help.
regards,
Ben
^ permalink raw reply
* LED heartbeat trigger - in_atomic() while allocs
From: Benedict, Michael @ 2007-11-26 20:07 UTC (permalink / raw)
To: linuxppc-embedded
I was playing around with the LED heartbeat trigger and it caught the
BUG() code when trying to activate. Does anyone know why this call
stack would be in_atomic()? Or any ideas for a patch that would allow
the heartbeat trigger to allocate when it is not in atomic context?
BUG: sleeping function called from invalid context at mm/slab.c:3024
in_atomic():1, irqs_disabled():0
Call Trace:
[def3dd90] [c0008e60] show_stack+0x48/0x194 (unreliable)
[def3ddc0] [c0014160] __might_sleep+0xd0/0xdc
[def3dde0] [c0063e60] kmem_cache_zalloc+0xdc/0x12c
[def3de00] [c01975c0] heartbeat_trig_activate+0x24/0x80
[def3de20] [c0196844] led_trigger_set+0x128/0x160
[def3de40] [c0196988] led_trigger_store+0x10c/0x1a8
[def3deb0] [c0162f40] class_device_attr_store+0x44/0x5c
[def3dec0] [c00ae614] sysfs_write_file+0x114/0x1dc
[def3def0] [c0068ea4] vfs_write+0x9c/0x110
[def3df10] [c0068ff4] sys_write+0x4c/0x90
[def3df40] [c000fc00] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xfe83818
LR =3D 0xfe35448
Kernel 2.6.22-4, powerpc, targeting an MPC 8347. I don't think this
issue is PowerPC specific but I was hoping other embedded people might
have experience with the LED class driver.
Thank you,
Michael
^ permalink raw reply
* Re: Sequoia EMAC only works if u-boot initializes it?
From: Benjamin Herrenschmidt @ 2007-11-26 20:08 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <474B1A11.90806@harris.com>
On Mon, 2007-11-26 at 14:10 -0500, Steven A. Falco wrote:
> I've attached a copy of my bootlog. I added in one patch to enable
> rgmii but that didn't fix
> it.(http://ozlabs.org/pipermail/linuxppc-dev/2007-October/043435.html)
>
> I am curious why the new emac driver is enabled in the DENX tree but
> not in the upstream trees. Has DENX successfully used this driver on
> the Sequoia board? Am I trying something that is known not to work?
>
> I'm interested in helping in whatever way I can. I need ARCH=powerpc
> to use the current Xenomai patches, and I need both EMACs so I can
> evaluate bonding (for high-availability).
Have you tried adding the various patches I posted along with the
patches Valentine posted ?
I'll re-send a full serie later this week. Let us know if those help or
if something is still broken.
Cheers,
Ben.
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Clemens Koller @ 2007-11-26 20:20 UTC (permalink / raw)
To: robert lazarski; +Cc: linuxppc-embedded
In-Reply-To: <f87675ee0711260941w25e5ed81v7322be1500fd5611@mail.gmail.com>
Hi, Robert, Hi, Kumar!
robert lazarski schrieb:
> Hi Kumar, I finally got time to get back to this:
>
> On Nov 17, 2007 2:52 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>
>> On Nov 16, 2007, at 4:01 PM, robert lazarski wrote:
>>
>>>>> Sorry for replying to myself, but thought I'd mention SRESET works
>>>>> fine on 85xx 2.6.23 , ie, the board resets after kernel panic. It
>>>>> doesn't work for me on 2.6.24rc2 .
>>>> What actual 85xx are you using?
>>>>
>>>> - k
>>>>
>>> Custom 8548 board. I'm using the cds 85xx code for a reference and I
>>> calling the same reset functions.
>>>
>> 1. do you have the following in your dts:
>>
>> global-utilities@e0000 { //global utilities reg
>> compatible = "fsl,mpc8548-guts";
>> reg = <e0000 1000>;
>> fsl,has-rstcr;
>> };
>>
>
> Yes.
>
>> 2. in your platform code are you using fsl_rstcr_restart in
>> define_machine()
>>
>> - k
>>
>
> Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
> calling 'reboot' in the shell, it just hangs. Using the same dts and
> resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
> someone who does should be able to confirm whether the issue exists or
> not by just attempting to reboot via bash.
ACK. Exactly the same over here (mpc8540ads compatible).
I added the global-utilities today as well, but reboot fails.
Why is the guts stuff missing i.e. in most of the shipped
mpc85xx*.dts? Does it depend on some hardware connections
external to the CPU?
Regards,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-26 20:28 UTC (permalink / raw)
To: Grant Likely
Cc: Koss, Mike (Mission Systems), Stephen Neuendorffer,
linuxppc-embedded
In-Reply-To: <fa686aa40711260830y46aeb64cy8b662cad7196af8d@mail.gmail.com>
Grant Likely wrote:
> On 11/26/07, Koss, Mike (Mission Systems) <mike.koss@ngc.com> wrote:
>
>> DL> And once again a plea to ALWAYS make version/capabilities registers
>> DL> atleast an optional part of every design.
>> DL> Embeddeding a device tree into a design might be fairly expensive. a
>> DL> pair of read only 32 bit registers is damn near free - basically the
>> DL> FPGA equivalent of atmost 64 diodes or resistors.
>>
>> SN> Actually, device trees actually seem to be cheaper (in the whole system
>> sense) than such registers. Unless there is something I don't understand?
>>
First the decoding for the register is almost certainly already
present for the other registers for the device.
After that - assuming that an FPGA can impliment a read only
register as easily as discrete logic - it should be damn near the
most trivial peice of hardware imaginable. It is simpler than 64
bits of RAM. It can be simpler than 64bits of ROM.
I do not think there is a way in the world that devicetrees can more
cheaply provide the same information.
They might me more flexible, or powerful, but 2 64bit read only
registers.
Anyway I am not arguing that you should not do devicetrees. Just
that you should do version/capabilities registers - atleast as a IP
option always.
Every OS does nto support devicetree's. Every application of an FPGA
not going to have that as an option. But every peice of software that
can access and I/O device can access its version and capabilities registers.
> *If* edk is generating our device tree(s) for us, *then* version
> registers are not needed by Linux.
>
I want both. I want version registers - because they are ALWAYS
available.
They are available to software running on the FPGA that has no clue
what bit file it is running on,how it got to be running.
Devicetrees may provide a great deal more information bit it is not
hard to come up with scenarios where that information might not
be present. It is like the security arguments about biometric
identification. I can forget my key card, my password, ... But I am
unlikely to forget my thumbprint or retina.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: dtc: Remove some redundant testcases
From: Jon Loeliger @ 2007-11-26 21:21 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071121002918.GC13156@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch removes a number of testcases from the testsuite that are
> extremely unlikely to find any bugs that won't be found by the other
> tests. This speeds up the testsuite.
>
> - Both loops across the various tree block layouts run the
> tree1_tests on the basic mangled tree. This is completely redundant,
> so remove the second copy. This removes 456 testcases.
>
> - We currently run tree1_tests on various trees manipulated by
> move_and_save. We replace those with just a dtbs_equal_ordered test
> to check that the manipulated tree is equal to the original. What
> we're testing here is that fdt_move() operates correctly - it's very
> unlikely it would succeed well enough for the ordered_equal test to
> succeed, but the tree1_tests would fail on the result. This removes
> 162 testcases.
>
> - Currently we re-ordered with mangle-layout both the basic
> test_tree1.dtb and sw_tree1.test.dtb. Since we've already checked
> that these dtbs are equivalent with dtbs_ordered_equal, it's very
> unlikely that the tests would fail on one but not the other.
> Therefore reduce this to only using test_tree1.dtb. This removes 828
> testcases.
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-26 21:16 UTC (permalink / raw)
To: Koss, Mike (Mission Systems); +Cc: Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <EDAE140DF1B2FC42B5867C22CA0B333F0A58E4@XMBIL132.northgrum.com>
Koss, Mike (Mission Systems) wrote:
> Time for my $.02, since I am heavily weighting my future designs on the
> use of the device trees. :) (and b/c I don't check my work e-mail from
> home ;P)
>
> ________________________________
>
> From: Stephen Neuendorffer [mailto:stephen.neuendorffer@xilinx.com]
> Sent: Sunday, November 25, 2007 6:59 PM
> To: David H. Lynch Jr.; Grant Likely; linuxppc-embedded
> Subject: RE: Xilinx devicetrees
>
>
> SN> the device tree is packaged (somehow, TBD) along with the bitstream.
>
If xilinx wants to optionally incorporate the device tree into the
bitstream in a fashion that can easily be worked out by software - that
would be excellent.
>
> I don't know if packaging the device tree with the bitstream is the best
> way to go. It's possible that it could lead to headaches for certain
> systems that have security restrictions.
Make it an option. Where are the systems with security restrictions
going to get their hardware information ?
Besides - though I am not aware off the top of my head of a
bitstream decompliler, still if you have access to the bitstream you
have access to the information about the device. We deal with alot of
high security applications. Security restrictions have to make sense.
blocking devicetrees for security reasons is like telling somebody
they can have the manual in computer readable form, but not on paper.
Further if you are going to boot an OS that requires devicetrees
then the devicetree must be somewhere - whether it is appended to the
bitstream, appended to the kernel, compiled into the kernel, in a
separate file, it still has to be present.
> The same could be said for
> using it w/ the SystemACE to load it into RAM after the image. (which is
> what I'm currently doing for my 2 linux images in lieu of a true on-chip
> bootloader). I am already taking the security concerns into account for
> future revisions of the hardware wrt to using a SystemACE, and am
> planning on moving the device trees into NV storage like FLASH.
>
I am not working with MLXXX boards. Pico has no System ACE. The card
has an FPGA, flash, ram and a few other things all in a
CF/Cardbus/expressbus formfactor. You program it in a host with our
tools. You run it either in the host or standalone.
>
> SN> I don't understand the 'burden on software developers'. The code to
> do this will just be standard code.
I got 16K of RAM for my boot loader and that 16K has to do alot more
than just manage device trees.
I think we have 2K left. In that I have to fit scripting, and
ethernet, so where am I supposed to fit the standard code ?
If the devicetree is say at the end of the bit file I can probably
copy it to ram and pass a pointer to linux in maybe a couple of hundred
bytes.
If I have to do much more it ain't happening.
> The worst that one can say is:
> SN> 1) I need several KB additional non volatile storage. Given the
> size of the FPGA bitstream, this can't be a huge constraint.
>
Several KB is NOT happening. The bitstream is in flash. Flash is
not a limited reasorce for us.
FPGA cells, and BRAM are precious as gold. The more we use the
less our clients have.
Different systems are going to have different resource constraints.
What is unlimited for me may be severely limited for someone
else. What is unlimted for you may be seriously limited for me.
> I do agree that using more FPGA resources is not a solution to the
> problem. I'm already hitting 80% usage on a FX60 and trying to squeeze
> more real estate for storage of the device tree seems silly. Especially
> since that would require that every image have this extra hardware built
> into it just to support booting a Linux kernel. Why should I have to
> have different hardware to boot linux, versus non-kernel, xilkernel, or
> other (GHS, LynxOS, etc..)?
>
One of the problems is that neither devicetrees, nor any of the ways
of tracking them are one size fits all solutions.
I do GHS work, it would be nice if GHS supported devicetrees and
maybe it will.
bound to the kernel, in a separate file, appended to the bitstream
and in the FPGA fabric all have pluses and minuses.
One reason I am harping on version registers is they are extremely
cost cheap, can easily be made optional, and can be fairly easily
incorporated into any OS (or no OS - we do that too). They are not a
replacement for devicetrees. But they still have very important uses in
many environments.
>
> SN> Certainly.. But in a sense, these are all intermediate files on the
> path to the image on the board.
Unless we are going to teach linux to read and interpret .bit files
while loading, then devicetrees are intermediate in an entirely
different sense.
The hardware works fine regardless of whether their is a devicetree.
But Linux may not boot.
My objective is to get alot of software - linux, GHS, and
standalone apps, to all load - from a single executables, accross
multiple different bit images on several different (though deliberately
similar) products. My Linux kernel needs to work regardless of the Pico
card and regardless of the bit image, as done my GHS kernel, and ....
And I need to do that in a severly resource constrained environment.
I would hope that should make sense of my harping about
version/capabilities registers. If I have maybe 10 possible peices of IP
that may/maynot be present in a given FPGA and I am trying to
dynamically configure - Linux/GHS/... to adapt to whatever it encounters
and work as long as it is a viable combination. At best devicetrees are
an extremly complex way of solving that - while version registers are a
trivial way.
As an example I know that if I have a UartLite, Keyhole, TEMAC, PIC,
... they will always be at specific addresses. We never move them.
But I do not know for sure it they are present. A version register
provides a fairly safe very efficient means of checking that a device is
present (and establishing its version and maybe capabilites) - device
trees might do the same thing but have alot higher overhead to do so.
I deal more with presence/absence issues and maybe what version is
the IP rather than hardware is the IP and what IRQ is it using.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Vitaly Bordug @ 2007-11-26 21:22 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071126162446.GA4408@loki.buserror.net>
On Mon, 26 Nov 2007 10:24:46 -0600
Scott Wood wrote:
> On Fri, Nov 23, 2007 at 12:51:21AM +0300, Vitaly Bordug wrote:
> > Even that might be not enough - we may have simultaneous call of
> > this func in non-smp case...
>
> Do you really think that every piece of code that uses spinlocks in
> the kernel is broken on non-SMP?
>
No. I think spinlock is not universal save thing in such cases. See below.
> > I was thinking of some kind of refcount, so one that is going to
> > issue CPM command, must do say pq_cpmp_get() and another driver
> > won't be able to mangle with cpcr while it's not done with previous
> > request.
>
> How on earth are you going to effect mutual exclusion using reference
> counting?
>
perhaps I was not clear enough. That was a rough idea how to handle the whole thing,
not just cpm_cr_cmd. This cpm command is a corner case, but there can be other actions
that may confuse CPM being triggered simultaneously or overlapping. This is part of much bigger
problem, and I was intended to have a look what people think about that.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Xilinx devicetrees
From: David H. Lynch Jr. @ 2007-11-26 21:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20071125235855.95B9999804D@mail138-cpk.bigfish.com>
Stephen Neuendorffer wrote:
> In any event, why do you do this rather than just run out of the flash (or a ram copy of the flash?)
>
This is not literally true, but the parameters are nearly the same
- pretend we are using NAND flash and storing executables as elf files.
We can not run from flash because:
The code has not been relocated
the flash is not persistent
We do load the flash/elf file into DRAM dealing with elf issues
along the way and then execute it.
We can do something similar for devicetrees, actually just passing
Linux the offset from the begining of flash to the devicetree would be
sufficient. Or if finding the devicetree inside the bitsstream can be
accomplished fairly simply, just passing the offset of the bit file.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Scott Wood @ 2007-11-26 21:41 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20071127002249.612f4ff6@kernel.crashing.org>
Vitaly Bordug wrote:
> perhaps I was not clear enough. That was a rough idea how to handle
> the whole thing, not just cpm_cr_cmd. This cpm command is a corner
> case, but there can be other actions that may confuse CPM being
> triggered simultaneously or overlapping.
What kind of actions did you have in mind? Microcode patching?
-Scott
^ permalink raw reply
* RE: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
From: Stephen Neuendorffer @ 2007-11-26 21:44 UTC (permalink / raw)
To: Grant Likely, Segher Boessenkool, David Gibson, Jon Loeliger
Cc: microblaze-uclinux, Michal Simek, git, linuxppc-dev
In-Reply-To: <fa686aa40711251447t57f96dd4iba51d68e1c9a9c5c@mail.gmail.com>
=20
I've pushed the current state up to
git://git.xilinx.com/gen-mhs-devtree.git for your perusing. Comments
below.
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Sunday, November 25, 2007 2:47 PM
> To: Stephen Neuendorffer; Segher Boessenkool; David Gibson;=20
> Jon Loeliger
> Cc: microblaze-uclinux@itee.uq.edu.au;=20
> linuxppc-dev@ozlabs.org; Michal Simek; git
> Subject: Re: Xilinx EDK BSP generation of device trees for=20
> microblaze and PowerPC
>=20
> On 11/24/07, Stephen Neuendorffer=20
> <stephen.neuendorffer@xilinx.com> wrote:
> >
>=20
> Thanks for all this work; comments below.
>=20
> >
> > Here's what I've gotten so far:
> >
> > Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
> > #address-cells =3D <1>;
> > #size-cells =3D <1>;
> > network@81c00000 {
> > compatible =3D=20
> "xlnx,xps-ll-temac-1.00.a",
> > "xlnx,xps-ll-temac";
>=20
> Drop "xlnx,xps-ll-temac"; it's 100% made up. This should be simply:
> compatible =3D "xlnx,xps-ll-temac-1.00.a" for version 1.00.a and
> compatible =3D
> "xlnx,xps-ll-temac-<version>","xlnx,xps-ll-temac-1.00.a" for a future
> version if it maintains register level compatibility.
>=20
> "xlnx,xps-ll-temac" is far to ambiguous.
What if it was: compatible =3D "xlnx,xps-ll-temac-1.00.a",
"xlnx,xps-ll-temac-1"?
Basically, I don't want to be responsible for declaring what versions of
IP are backward compatible with ll-temac-1.00.a, and I think it's bad
software design to put that list into the dts generator anyway. In
theory, at least, all ip with the same major version should be
compatible.
> > interrupt-parent =3D <&xps_intc_0>;
> > interrupts =3D < 3 0 >;
> > llink-connected =3D <&PIM3>;
>=20
> What's this property for?
So that the ll_temac knows whether to use dma or fifo code and where the
dma or fifo control/interrupts are.
>=20
> > reg =3D < 81c00000 40 >;
>=20
> If these registers are addressable, then the parent needs a=20
> 'ranges' property.
I thought ranges weren't necessary in a 1:1 mapping?
> > xlnx,bus2core-clk-ratio =3D <1>;
> > xlnx,phy-type =3D <1>;
> > xlnx,phyaddr =3D <1>;
> > xlnx,rxcsum =3D <0>;
> > xlnx,rxfifo =3D <1000>;
> > xlnx,temac-type =3D <0>;
> > xlnx,txcsum =3D <0>;
> > xlnx,txfifo =3D <1000>;
>=20
> Would be nice to have a 'phy-handle' property as that is what is being
> used on other platforms; but that's not something that EDK knows
> about. It would be nice to have a way to tell EDK what PHY device is
> on the board so it could generate the appropriate mdio and phy nodes.
Yeah, this is going to be a big issue, I think...
^ 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