* [patch 6/8] ps3av: add quirk database for broken monitors
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]
ps3av: add a quirk database for broken monitors where the `best' advertised
video mode doesn't work
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -721,6 +721,45 @@ static void ps3av_monitor_info_dump(cons
}
}
+static const struct ps3av_monitor_quirk {
+ const char *monitor_name;
+ u32 clear_60, clear_50, clear_vesa;
+} ps3av_monitor_quirks[] = {
+ {
+ .monitor_name = "DELL 2007WFP",
+ .clear_60 = PS3AV_RESBIT_1920x1080I
+ }, {
+ .monitor_name = "L226WTQ",
+ .clear_60 = PS3AV_RESBIT_1920x1080I |
+ PS3AV_RESBIT_1920x1080P
+ }, {
+ .monitor_name = "SyncMaster",
+ .clear_60 = PS3AV_RESBIT_1920x1080I
+ }
+};
+
+static void ps3av_fixup_monitor_info(struct ps3av_info_monitor *info)
+{
+ unsigned int i;
+ const struct ps3av_monitor_quirk *quirk;
+
+ for (i = 0; i < ARRAY_SIZE(ps3av_monitor_quirks); i++) {
+ quirk = &ps3av_monitor_quirks[i];
+ if (!strncmp(info->monitor_name, quirk->monitor_name,
+ sizeof(info->monitor_name))) {
+ pr_info("%s: Applying quirk for %s\n", __func__,
+ quirk->monitor_name);
+ info->res_60.res_bits &= ~quirk->clear_60;
+ info->res_60.native &= ~quirk->clear_60;
+ info->res_50.res_bits &= ~quirk->clear_50;
+ info->res_50.native &= ~quirk->clear_50;
+ info->res_vesa.res_bits &= ~quirk->clear_vesa;
+ info->res_vesa.native &= ~quirk->clear_vesa;
+ break;
+ }
+ }
+}
+
static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf,
int boot)
{
@@ -739,6 +778,8 @@ static int ps3av_auto_videomode(struct p
ps3av_monitor_info_dump(&monitor_info);
info = &monitor_info.info;
+ ps3av_fixup_monitor_info(info);
+
switch (info->monitor_type) {
case PS3AV_MONITOR_TYPE_DVI:
dvi = PS3AV_MODE_DVI;
--
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/8] ps3av: add autodetection for VESA modes
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5737 bytes --]
ps3av: add autodetection for VESA modes
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 93 ++++++++++++++++++++++++++------------------
include/asm-powerpc/ps3av.h | 11 ++++-
2 files changed, 67 insertions(+), 37 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -585,54 +585,73 @@ static void ps3avd(struct work_struct *w
complete(&ps3av->done);
}
-static int ps3av_resbit2id(u32 res_50, u32 res_60)
+#define SHIFT_50 0
+#define SHIFT_60 4
+#define SHIFT_VESA 8
+
+static const struct {
+ unsigned mask : 19;
+ unsigned id : 4;
+} ps3av_preferred_modes[] = {
+ { .mask = PS3AV_RESBIT_WUXGA << SHIFT_VESA, .id = 13 },
+ { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_60, .id = 5 },
+ { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_50, .id = 10 },
+ { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_60, .id = 4 },
+ { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_50, .id = 9 },
+ { .mask = PS3AV_RESBIT_SXGA << SHIFT_VESA, .id = 12 },
+ { .mask = PS3AV_RESBIT_WXGA << SHIFT_VESA, .id = 11 },
+ { .mask = PS3AV_RESBIT_1280x720P << SHIFT_60, .id = 3 },
+ { .mask = PS3AV_RESBIT_1280x720P << SHIFT_50, .id = 8 },
+ { .mask = PS3AV_RESBIT_720x480P << SHIFT_60, .id = 2 },
+ { .mask = PS3AV_RESBIT_720x576P << SHIFT_50, .id = 7 },
+};
+
+static int ps3av_resbit2id(u32 res_50, u32 res_60, u32 res_vesa)
{
- int id = 0;
+ unsigned int i;
+ u32 res_all;
- if (res_50 > res_60) { /* if res_50 == res_60, res_60 will be used */
- if (res_50 & PS3AV_RESBIT_1920x1080P)
- id = 10;
- else if (res_50 & PS3AV_RESBIT_1920x1080I)
- id = 9;
- else if (res_50 & PS3AV_RESBIT_1280x720P)
- id = 8;
- else if (res_50 & PS3AV_RESBIT_720x576P)
- id = 7;
- else
- id = 0;
- } else {
- if (res_60 & PS3AV_RESBIT_1920x1080P)
- id = 5;
- else if (res_60 & PS3AV_RESBIT_1920x1080I)
- id = 4;
- else if (res_60 & PS3AV_RESBIT_1280x720P)
- id = 3;
- else if (res_60 & PS3AV_RESBIT_720x480P)
- id = 2;
- else
- id = 0;
- }
- return id;
+ /*
+ * We mask off the resolution bits we care about and combine the
+ * results in one bitfield, so make sure there's no overlap
+ */
+ BUILD_BUG_ON(PS3AV_RES_MASK_50 << SHIFT_50 &
+ PS3AV_RES_MASK_60 << SHIFT_60);
+ BUILD_BUG_ON(PS3AV_RES_MASK_50 << SHIFT_50 &
+ PS3AV_RES_MASK_VESA << SHIFT_VESA);
+ BUILD_BUG_ON(PS3AV_RES_MASK_60 << SHIFT_60 &
+ PS3AV_RES_MASK_VESA << SHIFT_VESA);
+ res_all = (res_50 & PS3AV_RES_MASK_50) << SHIFT_50 |
+ (res_60 & PS3AV_RES_MASK_60) << SHIFT_60 |
+ (res_vesa & PS3AV_RES_MASK_VESA) << SHIFT_VESA;
+
+ if (!res_all)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(ps3av_preferred_modes); i++)
+ if (res_all & ps3av_preferred_modes[i].mask)
+ return ps3av_preferred_modes[i].id;
+
+ return 0;
}
static int ps3av_hdmi_get_id(struct ps3av_info_monitor *info)
{
- u32 res_50, res_60;
int id;
/* check native resolution */
- res_50 = info->res_50.native & PS3AV_RES_MASK_50;
- res_60 = info->res_60.native & PS3AV_RES_MASK_60;
- if (res_50 || res_60) {
- id = ps3av_resbit2id(res_50, res_60);
+ id = ps3av_resbit2id(info->res_50.native, info->res_60.native,
+ info->res_vesa.native);
+ if (id) {
+ pr_debug("%s: Using native mode %d\n", __func__, id);
return id;
}
- /* check resolution */
- res_50 = info->res_50.res_bits & PS3AV_RES_MASK_50;
- res_60 = info->res_60.res_bits & PS3AV_RES_MASK_60;
- if (res_50 || res_60) {
- id = ps3av_resbit2id(res_50, res_60);
+ /* check supported resolutions */
+ id = ps3av_resbit2id(info->res_50.res_bits, info->res_60.res_bits,
+ info->res_vesa.res_bits);
+ if (id) {
+ pr_debug("%s: Using supported mode %d\n", __func__, id);
return id;
}
@@ -640,6 +659,7 @@ static int ps3av_hdmi_get_id(struct ps3a
id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
else
id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
+ pr_debug("%s: Using default mode %d\n", __func__, id);
return id;
}
@@ -737,6 +757,7 @@ static int ps3av_auto_videomode(struct p
id = PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_50;
if (ps3av->region & PS3AV_REGION_RGB)
rgb = PS3AV_MODE_RGB;
+ pr_debug("%s: Using avmulti mode %d\n", __func__, id);
} else if (boot) {
/* HDMI: using DEFAULT HDMI_MODE_ID while booting up */
info = &monitor_info.info;
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -283,7 +283,7 @@
#define PS3AV_CMD_VIDEO_CS_YUV422 0x0002
#define PS3AV_CMD_VIDEO_CS_YUV444 0x0003
-/* for automode */
+/* for broadcast automode */
#define PS3AV_RESBIT_720x480P 0x0003 /* 0x0001 | 0x0002 */
#define PS3AV_RESBIT_720x576P 0x0003 /* 0x0001 | 0x0002 */
#define PS3AV_RESBIT_1280x720P 0x0004
@@ -298,6 +298,15 @@
| PS3AV_RESBIT_1920x1080I \
| PS3AV_RESBIT_1920x1080P)
+/* for VESA automode */
+#define PS3AV_RESBIT_VGA 0x0001
+#define PS3AV_RESBIT_WXGA 0x0002
+#define PS3AV_RESBIT_SXGA 0x0004
+#define PS3AV_RESBIT_WUXGA 0x0008
+#define PS3AV_RES_MASK_VESA (PS3AV_RESBIT_WXGA |\
+ PS3AV_RESBIT_SXGA |\
+ PS3AV_RESBIT_WUXGA)
+
#define PS3AV_MONITOR_TYPE_HDMI 1 /* HDMI */
#define PS3AV_MONITOR_TYPE_DVI 2 /* DVI */
--
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 4/8] ps3av: treat DVI-D like HDMI in autodetect
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]
ps3av: treat DVI-D monitors like HDMI monitors when autodetecting the best
video mode
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 24 ++++++++----------------
include/asm-powerpc/ps3av.h | 1 -
2 files changed, 8 insertions(+), 17 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -620,9 +620,6 @@ static int ps3av_hdmi_get_id(struct ps3a
u32 res_50, res_60;
int id;
- if (info->monitor_type != PS3AV_MONITOR_TYPE_HDMI)
- return 0;
-
/* check native resolution */
res_50 = info->res_50.native & PS3AV_RES_MASK_50;
res_60 = info->res_60.native & PS3AV_RES_MASK_60;
@@ -712,7 +709,7 @@ static int ps3av_auto_videomode(struct p
struct ps3av_info_monitor *info;
/* get mode id for hdmi */
- for (i = 0; i < av_hw_conf->num_of_hdmi; i++) {
+ for (i = 0; i < av_hw_conf->num_of_hdmi && !id; i++) {
res = ps3av_cmd_video_get_monitor_info(&monitor_info,
PS3AV_CMD_AVPORT_HDMI_0 +
i);
@@ -720,24 +717,19 @@ static int ps3av_auto_videomode(struct p
return -1;
ps3av_monitor_info_dump(&monitor_info);
+
info = &monitor_info.info;
- /* check DVI */
- if (info->monitor_type == PS3AV_MONITOR_TYPE_DVI) {
+ switch (info->monitor_type) {
+ case PS3AV_MONITOR_TYPE_DVI:
dvi = PS3AV_MODE_DVI;
- break;
- }
- /* check HDMI */
- id = ps3av_hdmi_get_id(info);
- if (id) {
- /* got valid mode id */
+ /* fall through */
+ case PS3AV_MONITOR_TYPE_HDMI:
+ id = ps3av_hdmi_get_id(info);
break;
}
}
- if (dvi) {
- /* DVI mode */
- id = PS3AV_DEFAULT_DVI_MODE_ID;
- } else if (!id) {
+ if (!id) {
/* no HDMI interface or HDMI is off */
if (ps3av->region & PS3AV_REGION_60)
id = PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_60;
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -305,7 +305,6 @@
#define PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_60 1 /* 480i */
#define PS3AV_DEFAULT_HDMI_MODE_ID_REG_50 7 /* 576p */
#define PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_50 6 /* 576i */
-#define PS3AV_DEFAULT_DVI_MODE_ID 2 /* 480p */
#define PS3AV_REGION_60 0x01
#define PS3AV_REGION_50 0x02
--
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 3/8] ps3av: use PS3 video mode ids in autodetect code
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6965 bytes --]
ps3av: use PS3 video mode ids in autodetect code
It doesn't make much sense to use the PS3AV_CMD_VIDEO_VID_* values in the
autodetection code, just to convert them to PS3 video mode ids afterwards.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 90 +++++++++++++++++++-------------------------
include/asm-powerpc/ps3av.h | 11 ++---
2 files changed, 46 insertions(+), 55 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -585,75 +585,65 @@ static void ps3avd(struct work_struct *w
complete(&ps3av->done);
}
-static int ps3av_vid2table_id(int vid)
+static int ps3av_resbit2id(u32 res_50, u32 res_60)
{
- int i;
-
- for (i = 1; i < ARRAY_SIZE(video_mode_table); i++)
- if (video_mode_table[i].vid == vid)
- return i;
- return -1;
-}
-
-static int ps3av_resbit2vid(u32 res_50, u32 res_60)
-{
- int vid = -1;
+ int id = 0;
if (res_50 > res_60) { /* if res_50 == res_60, res_60 will be used */
if (res_50 & PS3AV_RESBIT_1920x1080P)
- vid = PS3AV_CMD_VIDEO_VID_1080P_50HZ;
+ id = 10;
else if (res_50 & PS3AV_RESBIT_1920x1080I)
- vid = PS3AV_CMD_VIDEO_VID_1080I_50HZ;
+ id = 9;
else if (res_50 & PS3AV_RESBIT_1280x720P)
- vid = PS3AV_CMD_VIDEO_VID_720P_50HZ;
+ id = 8;
else if (res_50 & PS3AV_RESBIT_720x576P)
- vid = PS3AV_CMD_VIDEO_VID_576P;
+ id = 7;
else
- vid = -1;
+ id = 0;
} else {
if (res_60 & PS3AV_RESBIT_1920x1080P)
- vid = PS3AV_CMD_VIDEO_VID_1080P_60HZ;
+ id = 5;
else if (res_60 & PS3AV_RESBIT_1920x1080I)
- vid = PS3AV_CMD_VIDEO_VID_1080I_60HZ;
+ id = 4;
else if (res_60 & PS3AV_RESBIT_1280x720P)
- vid = PS3AV_CMD_VIDEO_VID_720P_60HZ;
+ id = 3;
else if (res_60 & PS3AV_RESBIT_720x480P)
- vid = PS3AV_CMD_VIDEO_VID_480P;
+ id = 2;
else
- vid = -1;
+ id = 0;
}
- return vid;
+ return id;
}
-static int ps3av_hdmi_get_vid(struct ps3av_info_monitor *info)
+static int ps3av_hdmi_get_id(struct ps3av_info_monitor *info)
{
u32 res_50, res_60;
- int vid = -1;
+ int id;
if (info->monitor_type != PS3AV_MONITOR_TYPE_HDMI)
- return -1;
+ return 0;
/* check native resolution */
res_50 = info->res_50.native & PS3AV_RES_MASK_50;
res_60 = info->res_60.native & PS3AV_RES_MASK_60;
if (res_50 || res_60) {
- vid = ps3av_resbit2vid(res_50, res_60);
- return vid;
+ id = ps3av_resbit2id(res_50, res_60);
+ return id;
}
/* check resolution */
res_50 = info->res_50.res_bits & PS3AV_RES_MASK_50;
res_60 = info->res_60.res_bits & PS3AV_RES_MASK_60;
if (res_50 || res_60) {
- vid = ps3av_resbit2vid(res_50, res_60);
- return vid;
+ id = ps3av_resbit2id(res_50, res_60);
+ return id;
}
if (ps3av->region & PS3AV_REGION_60)
- vid = PS3AV_DEFAULT_HDMI_VID_REG_60;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
else
- vid = PS3AV_DEFAULT_HDMI_VID_REG_50;
- return vid;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
+ return id;
}
static void ps3av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info *monitor_info)
@@ -717,11 +707,11 @@ static void ps3av_monitor_info_dump(cons
static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf,
int boot)
{
- int i, res, vid = -1, dvi = 0, rgb = 0;
+ int i, res, id = 0, dvi = 0, rgb = 0;
struct ps3av_pkt_av_get_monitor_info monitor_info;
struct ps3av_info_monitor *info;
- /* get vid for hdmi */
+ /* get mode id for hdmi */
for (i = 0; i < av_hw_conf->num_of_hdmi; i++) {
res = ps3av_cmd_video_get_monitor_info(&monitor_info,
PS3AV_CMD_AVPORT_HDMI_0 +
@@ -737,49 +727,49 @@ static int ps3av_auto_videomode(struct p
break;
}
/* check HDMI */
- vid = ps3av_hdmi_get_vid(info);
- if (vid != -1) {
- /* got valid vid */
+ id = ps3av_hdmi_get_id(info);
+ if (id) {
+ /* got valid mode id */
break;
}
}
if (dvi) {
/* DVI mode */
- vid = PS3AV_DEFAULT_DVI_VID;
- } else if (vid == -1) {
+ id = PS3AV_DEFAULT_DVI_MODE_ID;
+ } else if (!id) {
/* no HDMI interface or HDMI is off */
if (ps3av->region & PS3AV_REGION_60)
- vid = PS3AV_DEFAULT_AVMULTI_VID_REG_60;
+ id = PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_60;
else
- vid = PS3AV_DEFAULT_AVMULTI_VID_REG_50;
+ id = PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_50;
if (ps3av->region & PS3AV_REGION_RGB)
rgb = PS3AV_MODE_RGB;
} else if (boot) {
- /* HDMI: using DEFAULT HDMI_VID while booting up */
+ /* HDMI: using DEFAULT HDMI_MODE_ID while booting up */
info = &monitor_info.info;
if (ps3av->region & PS3AV_REGION_60) {
if (info->res_60.res_bits & PS3AV_RESBIT_720x480P)
- vid = PS3AV_DEFAULT_HDMI_VID_REG_60;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
else if (info->res_50.res_bits & PS3AV_RESBIT_720x576P)
- vid = PS3AV_DEFAULT_HDMI_VID_REG_50;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
else {
/* default */
- vid = PS3AV_DEFAULT_HDMI_VID_REG_60;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
}
} else {
if (info->res_50.res_bits & PS3AV_RESBIT_720x576P)
- vid = PS3AV_DEFAULT_HDMI_VID_REG_50;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
else if (info->res_60.res_bits & PS3AV_RESBIT_720x480P)
- vid = PS3AV_DEFAULT_HDMI_VID_REG_60;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_60;
else {
/* default */
- vid = PS3AV_DEFAULT_HDMI_VID_REG_50;
+ id = PS3AV_DEFAULT_HDMI_MODE_ID_REG_50;
}
}
}
- return (ps3av_vid2table_id(vid) | dvi | rgb);
+ return id | dvi | rgb;
}
static int ps3av_get_hw_conf(struct ps3av *ps3av)
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -300,11 +300,12 @@
#define PS3AV_MONITOR_TYPE_HDMI 1 /* HDMI */
#define PS3AV_MONITOR_TYPE_DVI 2 /* DVI */
-#define PS3AV_DEFAULT_HDMI_VID_REG_60 PS3AV_CMD_VIDEO_VID_480P
-#define PS3AV_DEFAULT_AVMULTI_VID_REG_60 PS3AV_CMD_VIDEO_VID_480I
-#define PS3AV_DEFAULT_HDMI_VID_REG_50 PS3AV_CMD_VIDEO_VID_576P
-#define PS3AV_DEFAULT_AVMULTI_VID_REG_50 PS3AV_CMD_VIDEO_VID_576I
-#define PS3AV_DEFAULT_DVI_VID PS3AV_CMD_VIDEO_VID_480P
+
+#define PS3AV_DEFAULT_HDMI_MODE_ID_REG_60 2 /* 480p */
+#define PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_60 1 /* 480i */
+#define PS3AV_DEFAULT_HDMI_MODE_ID_REG_50 7 /* 576p */
+#define PS3AV_DEFAULT_AVMULTI_MODE_ID_REG_50 6 /* 576i */
+#define PS3AV_DEFAULT_DVI_MODE_ID 2 /* 480p */
#define PS3AV_REGION_60 0x01
#define PS3AV_REGION_50 0x02
--
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 2/8] ps3av: eliminate PS3AV_DEBUG
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8694 bytes --]
ps3av: eliminate PS3AV_DEBUG
- Move ps3av_cmd_av_monitor_info_dump from ps3av_cmd.c to ps3av.c, as it's
used there only
- Integrate ps3av_cmd_av_hw_conf_dump() into its sole user
- Use pr_debug() for printing debug info
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av.c | 72 ++++++++++++++++++++++++++++++++++++++++----
drivers/ps3/ps3av_cmd.c | 66 ----------------------------------------
include/asm-powerpc/ps3av.h | 7 ----
3 files changed, 67 insertions(+), 78 deletions(-)
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -656,6 +656,64 @@ static int ps3av_hdmi_get_vid(struct ps3
return vid;
}
+static void ps3av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info *monitor_info)
+{
+ const struct ps3av_info_monitor *info = &monitor_info->info;
+ const struct ps3av_info_audio *audio = info->audio;
+ char id[sizeof(info->monitor_id)*3+1];
+ int i;
+
+ pr_debug("Monitor Info: size %u\n", monitor_info->send_hdr.size);
+
+ pr_debug("avport: %02x\n", info->avport);
+ for (i = 0; i < sizeof(info->monitor_id); i++)
+ sprintf(&id[i*3], " %02x", info->monitor_id[i]);
+ pr_debug("monitor_id: %s\n", id);
+ pr_debug("monitor_type: %02x\n", info->monitor_type);
+ pr_debug("monitor_name: %.*s\n", (int)sizeof(info->monitor_name),
+ info->monitor_name);
+
+ /* resolution */
+ pr_debug("resolution_60: bits: %08x native: %08x\n",
+ info->res_60.res_bits, info->res_60.native);
+ pr_debug("resolution_50: bits: %08x native: %08x\n",
+ info->res_50.res_bits, info->res_50.native);
+ pr_debug("resolution_other: bits: %08x native: %08x\n",
+ info->res_other.res_bits, info->res_other.native);
+ pr_debug("resolution_vesa: bits: %08x native: %08x\n",
+ info->res_vesa.res_bits, info->res_vesa.native);
+
+ /* color space */
+ pr_debug("color space rgb: %02x\n", info->cs.rgb);
+ pr_debug("color space yuv444: %02x\n", info->cs.yuv444);
+ pr_debug("color space yuv422: %02x\n", info->cs.yuv422);
+
+ /* color info */
+ pr_debug("color info red: X %04x Y %04x\n", info->color.red_x,
+ info->color.red_y);
+ pr_debug("color info green: X %04x Y %04x\n", info->color.green_x,
+ info->color.green_y);
+ pr_debug("color info blue: X %04x Y %04x\n", info->color.blue_x,
+ info->color.blue_y);
+ pr_debug("color info white: X %04x Y %04x\n", info->color.white_x,
+ info->color.white_y);
+ pr_debug("color info gamma: %08x\n", info->color.gamma);
+
+ /* other info */
+ pr_debug("supported_AI: %02x\n", info->supported_ai);
+ pr_debug("speaker_info: %02x\n", info->speaker_info);
+ pr_debug("num of audio: %02x\n", info->num_of_audio_block);
+
+ /* audio block */
+ for (i = 0; i < info->num_of_audio_block; i++) {
+ pr_debug("audio[%d] type: %02x max_ch: %02x fs: %02x sbit: "
+ "%02x\n",
+ i, audio->type, audio->max_num_of_ch, audio->fs,
+ audio->sbit);
+ audio++;
+ }
+}
+
static int ps3av_auto_videomode(struct ps3av_pkt_av_get_hw_conf *av_hw_conf,
int boot)
{
@@ -671,7 +729,7 @@ static int ps3av_auto_videomode(struct p
if (res < 0)
return -1;
- ps3av_cmd_av_monitor_info_dump(&monitor_info);
+ ps3av_monitor_info_dump(&monitor_info);
info = &monitor_info.info;
/* check DVI */
if (info->monitor_type == PS3AV_MONITOR_TYPE_DVI) {
@@ -727,23 +785,27 @@ static int ps3av_auto_videomode(struct p
static int ps3av_get_hw_conf(struct ps3av *ps3av)
{
int i, j, k, res;
+ const struct ps3av_pkt_av_get_hw_conf *hw_conf;
/* get av_hw_conf */
res = ps3av_cmd_av_get_hw_conf(&ps3av->av_hw_conf);
if (res < 0)
return -1;
- ps3av_cmd_av_hw_conf_dump(&ps3av->av_hw_conf);
+ hw_conf = &ps3av->av_hw_conf;
+ pr_debug("av_h_conf: num of hdmi: %u\n", hw_conf->num_of_hdmi);
+ pr_debug("av_h_conf: num of avmulti: %u\n", hw_conf->num_of_avmulti);
+ pr_debug("av_h_conf: num of spdif: %u\n", hw_conf->num_of_spdif);
for (i = 0; i < PS3AV_HEAD_MAX; i++)
ps3av->head[i] = PS3AV_CMD_VIDEO_HEAD_A + i;
for (i = 0; i < PS3AV_OPT_PORT_MAX; i++)
ps3av->opt_port[i] = PS3AV_CMD_AVPORT_SPDIF_0 + i;
- for (i = 0; i < ps3av->av_hw_conf.num_of_hdmi; i++)
+ for (i = 0; i < hw_conf->num_of_hdmi; i++)
ps3av->av_port[i] = PS3AV_CMD_AVPORT_HDMI_0 + i;
- for (j = 0; j < ps3av->av_hw_conf.num_of_avmulti; j++)
+ for (j = 0; j < hw_conf->num_of_avmulti; j++)
ps3av->av_port[i + j] = PS3AV_CMD_AVPORT_AVMULTI_0 + j;
- for (k = 0; k < ps3av->av_hw_conf.num_of_spdif; k++)
+ for (k = 0; k < hw_conf->num_of_spdif; k++)
ps3av->av_port[i + j + k] = PS3AV_CMD_AVPORT_SPDIF_0 + k;
/* set all audio port */
--- a/drivers/ps3/ps3av_cmd.c
+++ b/drivers/ps3/ps3av_cmd.c
@@ -922,72 +922,6 @@ int ps3av_cmd_video_get_monitor_info(str
return res;
}
-#ifdef PS3AV_DEBUG
-void ps3av_cmd_av_hw_conf_dump(const struct ps3av_pkt_av_get_hw_conf *hw_conf)
-{
- printk("av_h_conf:num of hdmi:%d\n", hw_conf->num_of_hdmi);
- printk("av_h_conf:num of avmulti:%d\n", hw_conf->num_of_avmulti);
- printk("av_h_conf:num of spdif:%d\n", hw_conf->num_of_spdif);
-}
-
-void ps3av_cmd_av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info *monitor_info)
-{
- const struct ps3av_info_monitor *info = &monitor_info->info;
- const struct ps3av_info_audio *audio = info->audio;
- int i;
-
- printk("Monitor Info: size%d\n", monitor_info->send_hdr.size);
-
- printk("avport:%02x\n", info->avport);
- printk("monitor_id:");
- for (i = 0; i < 10; i++)
- printk("%02x ", info->monitor_id[i]);
- printk("\nmonitor_type:%02x\n", info->monitor_type);
- printk("monitor_name:");
- for (i = 0; i < 16; i++)
- printk("%c", info->monitor_name[i]);
-
- /* resolution */
- printk("\nresolution_60: bits:%08x native:%08x\n",
- info->res_60.res_bits, info->res_60.native);
- printk("resolution_50: bits:%08x native:%08x\n",
- info->res_50.res_bits, info->res_50.native);
- printk("resolution_other: bits:%08x native:%08x\n",
- info->res_other.res_bits, info->res_other.native);
- printk("resolution_vesa: bits:%08x native:%08x\n",
- info->res_vesa.res_bits, info->res_vesa.native);
-
- /* color space */
- printk("color space rgb:%02x\n", info->cs.rgb);
- printk("color space yuv444:%02x\n", info->cs.yuv444);
- printk("color space yuv422:%02x\n", info->cs.yuv422);
-
- /* color info */
- printk("color info red:X %04x Y %04x\n",
- info->color.red_x, info->color.red_y);
- printk("color info green:X %04x Y %04x\n",
- info->color.green_x, info->color.green_y);
- printk("color info blue:X %04x Y %04x\n",
- info->color.blue_x, info->color.blue_y);
- printk("color info white:X %04x Y %04x\n",
- info->color.white_x, info->color.white_y);
- printk("color info gamma: %08x\n", info->color.gamma);
-
- /* other info */
- printk("supported_AI:%02x\n", info->supported_ai);
- printk("speaker_info:%02x\n", info->speaker_info);
- printk("num of audio:%02x\n", info->num_of_audio_block);
-
- /* audio block */
- for (i = 0; i < info->num_of_audio_block; i++) {
- printk("audio[%d] type:%02x max_ch:%02x fs:%02x sbit:%02x\n",
- i, audio->type, audio->max_num_of_ch, audio->fs,
- audio->sbit);
- audio++;
- }
-}
-#endif /* PS3AV_DEBUG */
-
#define PS3AV_AV_LAYOUT_0 (PS3AV_CMD_AV_LAYOUT_32 \
| PS3AV_CMD_AV_LAYOUT_44 \
| PS3AV_CMD_AV_LAYOUT_48)
--- a/include/asm-powerpc/ps3av.h
+++ b/include/asm-powerpc/ps3av.h
@@ -697,13 +697,6 @@ extern int ps3av_cmd_audio_mute(int, u32
extern int ps3av_cmd_audio_active(int, u32);
extern int ps3av_cmd_avb_param(struct ps3av_pkt_avb_param *, u32);
extern int ps3av_cmd_av_get_hw_conf(struct ps3av_pkt_av_get_hw_conf *);
-#ifdef PS3AV_DEBUG
-extern void ps3av_cmd_av_hw_conf_dump(const struct ps3av_pkt_av_get_hw_conf *);
-extern void ps3av_cmd_av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info *);
-#else
-static inline void ps3av_cmd_av_hw_conf_dump(const struct ps3av_pkt_av_get_hw_conf *hw_conf) {}
-static inline void ps3av_cmd_av_monitor_info_dump(const struct ps3av_pkt_av_get_monitor_info *monitor_info) {}
-#endif
extern int ps3av_cmd_video_get_monitor_info(struct ps3av_pkt_av_get_monitor_info *,
u32);
--
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 1/8] ps3av: eliminate unneeded temporary variables
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel
Cc: Geert Uytterhoeven, linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070926163308.772580000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]
ps3av: eliminate unneeded temporary variables
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
drivers/ps3/ps3av_cmd.c | 17 ++++++-----------
1 files changed, 6 insertions(+), 11 deletions(-)
--- a/drivers/ps3/ps3av_cmd.c
+++ b/drivers/ps3/ps3av_cmd.c
@@ -512,7 +512,6 @@ static const u32 ps3av_ns_table[][5] = {
static void ps3av_cnv_ns(u8 *ns, u32 fs, u32 video_vid)
{
u32 av_vid, ns_val;
- u8 *p = ns;
int d;
d = ns_val = 0;
@@ -551,24 +550,22 @@ static void ps3av_cnv_ns(u8 *ns, u32 fs,
else
ns_val = ps3av_ns_table[PS3AV_CMD_AUDIO_FS_44K-BASE][d];
- *p++ = ns_val & 0x000000FF;
- *p++ = (ns_val & 0x0000FF00) >> 8;
- *p = (ns_val & 0x00FF0000) >> 16;
+ *ns++ = ns_val & 0x000000FF;
+ *ns++ = (ns_val & 0x0000FF00) >> 8;
+ *ns = (ns_val & 0x00FF0000) >> 16;
}
#undef BASE
static u8 ps3av_cnv_enable(u32 source, const u8 *enable)
{
- const u8 *p;
u8 ret = 0;
if (source == PS3AV_CMD_AUDIO_SOURCE_SPDIF) {
ret = 0x03;
} else if (source == PS3AV_CMD_AUDIO_SOURCE_SERIAL) {
- p = enable;
- ret = ((p[0] << 4) + (p[1] << 5) + (p[2] << 6) + (p[3] << 7)) |
- 0x01;
+ ret = ((enable[0] << 4) + (enable[1] << 5) + (enable[2] << 6) +
+ (enable[3] << 7)) | 0x01;
} else
printk(KERN_ERR "%s failed, source:%x\n", __func__, source);
return ret;
@@ -576,11 +573,9 @@ static u8 ps3av_cnv_enable(u32 source, c
static u8 ps3av_cnv_fifomap(const u8 *map)
{
- const u8 *p;
u8 ret = 0;
- p = map;
- ret = p[0] + (p[1] << 2) + (p[2] << 4) + (p[3] << 6);
+ ret = map[0] + (map[1] << 2) + (map[2] << 4) + (map[3] << 6);
return ret;
}
--
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 0/8] PS3 AV Settings Driver patches for 2.6.24
From: Geert Uytterhoeven @ 2007-09-26 16:33 UTC (permalink / raw)
To: Antonino A. Daplas, linux-fbdev-devel; +Cc: linuxppc-dev, cbe-oss-dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]
Hi,
Here are some new patches for the PS3 AV Settings Driver (ps3av), which is
used in close collaboration with the PS3 Virtual Frame Buffer Device Driver
(ps3fb):
[1] ps3av: eliminate unneeded temporary variables
[2] ps3av: eliminate PS3AV_DEBUG
[3] ps3av: use PS3 video mode ids in autodetect code
[4] ps3av: treat DVI-D like HDMI in autodetect
[5] ps3av: add autodetection for VESA modes
[6] ps3av: add quirk database for broken monitors
[7] ps3av: remove unused ps3av_set_mode()
[8] ps3av: don't distinguish between `boot' and `non-boot' autodetection
Please review, and queue for 2.6.24 if they're ok. Thanks!
Question: As several DVI-D displays advertise they support 1080i modes while
they actually don't (cfr. the quirk database), perhaps I should drop 1080i
modes completely from the ps3av_preferred_modes[] table? Usually 720p looks
better than 1080i anyway. What do you think?
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: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16
From: Milton Miller @ 2007-09-26 16:19 UTC (permalink / raw)
To: David Gibson; +Cc: ppcdev, Paul Mackerras
In-Reply-To: <20070925034616.GB2525@localhost.localdomain>
On Sep 24, 2007, at 10:46 PM, David Gibson wrote:
> On Mon, Sep 24, 2007 at 01:54:32AM -0500, Milton Miller wrote:
>> On Sep 23, 2007, at 10:36 PM, David Gibson wrote:
>>> On Fri, Sep 21, 2007 at 06:05:06PM -0500, Milton Miller wrote:
> [snip]
>>>> +#define MIN_VERSION 2
>>>> +#define OUT_VERSION 16
>>>
>>> Should output version 17. In any case, don't try to be so general -
>>> just convert v123 (all basically the same) to latest (i.e. v17)
>>> without all the #if nonsense.
>>
>> Outputing v17 instead of 16 requires more words to be added to the
>> header, and the library does fine with v16.
>
> For now. libfdt will want v17. Although it will (eventually) have
> it's own v16->v17 conversion code.
If libfdt gets merged without supporting v16 input, then that will be a
regression. This code isn't pretending to address that. The current
flat tree code works with v16.
>> Actually the v1 trees has
>> some other differences such as initrd addresses were kernel linear not
>> real, cpus were assigned logical numbers ... so while the structure
>> didn't change except for the header field, the contents did.
>
> !? what's your source for this. v2 and v3 were absolutely supposed to
> be backwards compatible with v1 which would not be the case with
> silent semantic changes such as this.
What's your souce for saying the were supposed to be backwards
compatable? That dtc fills out the struct header so?
My source is my involvment when v2 was defined (they were discovered
while writing my device tree generation code):
The actual binary structure is compatable, just not the contents of the
properties nor how any slave cpus wait (for some trees it doesn't
matter).
http://git.kernel.org/?p=linux/kernel/git/horms/kexec-tools-
testing.git;a=blob;f=kexec/arch/ppc64/fs2dt.c;
hb=b84b87747a16f0afbef6f6802bb794a94f4961d9
And some more changes just before that:
http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;
a=history;f=arch/ppc64/kernel/prom_init.c;
h=e570799a84cc5328e9f0fd44592cb0b828d8c13a;
hb=4ae24c4e8a8f68950a7774ca1cdfe69bfe4e2ffc
So its mostly when the kernel generated and required v1 trees, it was
ppc64 only and had these other content and handoff semantics. If it
were to get a v1 tree, it only copes for the boot cpu determination
I'm not aware of any code other than the kernel that would actually
generate a v1 tree (other than dtc, which always supporteed v2, and
doesn't care about these differences).
>> Actually,
>> when converting v3 to v16 some of the code issn't needed, the ifs
>> allow
>> the code size to be reduced.
>
> Yes, but it never will be, because the only reason we'd include this
> file is for converting old kexec-tools device trees which are v2 not
> v3.
>
>>>> +#define OUT_COMPAT 16
>>>> +
>>>> +#ifdef NO_CHECK
>>>> +static int check_v123_tree(u32 *start, u32 *limit)
>>>> +{
>>>> + return 0;
>>>> +}
>>>> +#else
>>>> +/**
>>>> + * check_v123_tree - check integrety of a version 1, 2, or 3 tree
>>>> + * @start: the start of the device tree struct
>>>> + * @limit: the end of the region for the struct
>>>> + * structural checks on device_tree
>>>> + */
>>>> +static int check_v123_tree(u32 *start, u32 *limit)
>>>
>>> What is the point of this check? If the device tree is corrupt,
>>> we're
>>> stuffed anyway, so why bother?
>>
>> Hence the ifdef NO_CHECK. When developing, sometimes its nice to
>> know
>> if its your input or your program. These functions are destructive to
>> an improperlly formed tree, and in non-obvious ways. When debugging,
>> it's not hard to hardcode console write or read the printf string
>> buffer with a hardware debugger to see error messages. That said, it
>> could be removed.
>
> Right. Debugging code shouldn't pollute final patches.
There debug code, and validation code. I call this the later. It
validates that the information that should be redundant is in fact
redundant before its removed. The response of the kernel to the tree
may be different if this check fails..
> [snip]
>>>> +#if MIN_VERSION < 3 || OUT_VERSION > 16
>>>> +/**
>>>> + * move_nops_fwd - move nops in a v16 dt_struct to the beginning
>>>> + * @start - device tree starting address
>>>> + * @count - number of %OF_DT_NOP cells to move
>>>> + */
>>>> +static void move_nops_fwd(u32 *start, int count)
>>>
>>> What on earth is the point of this. The NOPs are perfectly valid
>>> scattered within the tree, why go to all this trouble to shuffle them
>>> about.
>>
>> And if you notice, there is a "how many to move" argument. The point
>> of moving them to the front of the tree is the v17 device tree header
>> takes more space than the v3 one, and the v2 header is smaller than
>> both v17 and v16 header. Since I am converting the tree in place, the
>> space has to come from somewhere. Since we are pretty much guaranteed
>> to get several nops, this function moves them forward so they can be
>> overwritten. In practice we move 1-3 NOPS from the early properties >
>> 8 bytes and early grandchild nodes (eg /cpus/PowerPC,xxx).
>
> This is a hell of a lot of bother to go to for a few bytes.
> Allocating a big-enough buffer for any reasonable devtree in BSS and
> memmove()ing into there would be far simpler.
How big is enough? Who is going to do the research for the various
firmware levels of the big machines to find out how big the tree is?
Sure there are other ways to get the tree to version 16, one way is to
change what is generated. We could update kexec-tools fs2dt to
geneerate a v16 tree to support zImages.
A question for the list: does anyone else have firmware/environment
that supplies a tree < v16?
> [snip]
>>>> + if (tree->last_comp_version > 3)
>>>> + return; /* don't know what to do */
>>>
>>> Rather, don't need to do anything.
>>
>> If the tree is >= 16 then we don't presently need to do anything. If
>> there is a theoritical v4 tree we don't know what to do. And if
>> output
>> version is 17 but input is 16 we don't know what to do either, because
>> there likely aren't nops in the tree to consume. I suppose we could
>> preceed it with a check for version == OUTPUT_VERSION, but then I'm
>> sure I'd get pointless differentation :-).
>
> There will never be a v4. Or anything between v3 and v16.
I could see a v4 defined as v3 + the extra header in v17, not that I am
proposing that. Someone decided to skip to v16 for a reason. If we
knew there would never be v4-v15, why did we skip them?
[too general]
> [snip]
>>>> + /*
>>>> + * move mem_rsvmap and dt_strings if they are before dt_struct
>>>> + * onto our nops . Adjust start addresses for the 3 sections.
>>>> + */
>>>
>>> Hrm. Do we really need to worry about this case. You may be
>>> producing v2 trees in kexec-tools, but do they actually have the
>>> blocks out of order? dtc certainly never produced them that way.
>>
>> Out of order? There has never been a spec as to the order of the
>> blocks, only the implicit assumption that they follow the device tree
>> header in a reasonably packed sequence. booting-without-of says it
>> must be in ram,; the offsets are unsigned 32 bit quantities.
>
>> As to the order, used, the first implemntation was the kernel which
>> writes memreserve, strings, then struct (both the openfirmware client
>> in prom_init and the iSeries procedural library in dt.c). The second
>> implentation written is a procedural based library (similar to
>> iseries,
>> never published, but still used internally) that starts with a
>> pre-built header and string table, builds the dt_struct as the
>> functions are called, and when finished copies the memreserve table
>> and
>> fills in the dt_size, total size, and memreserve offset.
>
> Hrm. Yes, well, the iSeries tree is weird in a bunch of ways.
My point is its the same as the client interface code, and proves the
point the order is not specified nor need it be. And since the order
is the same in platforms/iseries/dt.c and kernel/prom_init.c, I fail to
see your point of calling the iseries code wierd. It's building a
device tree via the structured programming methods of calling
functions, each of which creates a node and the properties for that
node. Doesn't sound that much different than how a ieee bytecode
program would create the device tree and fill out properties, and I
would expect any firmware who created the device tree from scratch (as
oposed to editing a paritially built tree like the fixup hooks
presently in the wrapper) would be structured similarly. Since it
doesn't ahve a dynamic insertion library, it must fill in all the
properties of a node completely before its children, and must travel
some depth first order when creating the tree. I don't see any reason
to call it wierd.
>
>> fs2dt writes memreserve, struct, then strings. Aparently the same as
>> dtc. But yes, the strings can be before the struct, and the mem
>> reserve may or may not be when the strings are before the struct.
>
> Again. We don't need to deal with the general case here - just the
> real case of trees produced by old kexec-tools.
This function isn't conver_kexec_tree_inplacee. While my justification
for merging this code is it can be used as the target for kexec with
kexec-tools, its not my only use. I also have my internal library that
generates a v3 tree with the pieces ordered differently. If the code
is changed from its general support to support only the tree generated
by kexec-tools, then merging has little benifit to me and in fact it is
harder (I have to maintain a diff to a changing target vs adding a file
to the makefile).
I'll write a later reply that talks about what subsets of this series
make sense to merge.
milton
^ permalink raw reply
* git files from secret lab
From: Mead, Joseph @ 2007-09-26 14:53 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4e5a3720709260725x6d2e9faemc6a6053379610df8@mail.gmail.com>
Hi,=20
I'm trying to download the xilinx patches from Grant's git repository,
but don't quite understand what I am doing.
I cloned the tree from Linus' tree
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
(this worked fine)
cd linux-2.6
git fetch git://git.secretlab.ca/git/linux-2.6.git virtex-dev:virtex-dev
I get the error message:
Fatal: unexpected EOF
Fetch failure: git://git.secretlab.ca/git/linux-2.6.git
Thanks,
Joe
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Matthew Wilcox @ 2007-09-26 15:02 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070420204720.GM31947@austin.ibm.com>
On Fri, Apr 20, 2007 at 03:47:20PM -0500, Linas Vepstas wrote:
> Implement the so-called "first failure data capture" (FFDC) for the
> symbios PCI error recovery. After a PCI error event is reported,
> the driver requests that MMIO be enabled. Once enabled, it
> then reads and dumps assorted status registers, and concludes
> by requesting the usual reset sequence.
> + /* Request that MMIO be enabled, so register dump can be taken. */
> + return PCI_ERS_RESULT_CAN_RECOVER;
> +}
I'm a little concerned by the mention of MMIO. It's entirely possible
for the sym2 driver to be using ioports to access the card rather than
MMIO. Is it simply that it can't on the platform you test on?
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: git files from secret lab
From: Grant Likely @ 2007-09-26 15:00 UTC (permalink / raw)
To: Mead, Joseph; +Cc: linuxppc-embedded
In-Reply-To: <D1AFFAE2CC4BD54CA4C1543CFF4A4FCC5972C9@exchangemb3.bnl.gov>
On 9/26/07, Mead, Joseph <mead@bnl.gov> wrote:
> Hi,
>
> I'm trying to download the xilinx patches from Grant's git repository,
> but don't quite understand what I am doing.
>
> I cloned the tree from Linus' tree
>
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> (this worked fine)
>
> cd linux-2.6
What version of git are you running (git --version). That tree is
using the virtual hosting feature of newer versions of git. You need
to be running at least version 1.5.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* changing the EDLK components
From: Murat Artun @ 2007-09-26 14:25 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
In fact I have asked a variant of this question before.
I want to learn the way of building a GNU Automake project and adding
it into ELDK. This could be needed because the current version of an
ELDK component is old to meet the requirements or a library which is
not an ELDK component is to be used in our ppc system.
Section "3.7. Rebuilding ELDK Components" gives details of rebuilding
the components whose source rpms are provided with ELDK.
As I said above I asked a variant of this question to understand how
to build a library in a clean way which is not a part of ELDK.
As now, I need to upgrade an ELDK component. Namely, I need version
0.9.8 of OpenSSL, where latest ELDK release has OpenSSL with version
0.9.7f. I want to learn if it is necessary for me to follow the same
procedure stated in documentation in section "3.7. Rebuilding ELDK
Components". If this is the case, could anyone point me to resources
about how to prepare source rpms from an Automake project to prepare
the source rpm of version 0.9.8 of OpenSSL? Of course building the new
version of the component and placing everything by hand is always a
solution, but I want to understand the clean way of doing this.
Thanks and regards...
--
M u r at A r t u n, MSc.
Design Engineer
"be conservative in what you do, be liberal in what you accept from others"
^ permalink raw reply
* [PATCH] powerpc: fix pci domain detection
From: Arnd Bergmann @ 2007-09-26 14:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-pci, paulus, linux-kernel
The /proc/bus/pci/* files list PCI domain numbers only for
devices that claim to be on a multi-domain system. The check
for this is broken on powerpc, because the buid value is
truncated to 32 bits.
There is at least one machine (IBM QS21) that only uses
the high-order bits of the buid, so the return value
of pci_proc_domain() ends up being always zero, which
makes /proc/bus/pci useless.
Change the logic to always return '1' for a nonzero
buid value.
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 291ffbc..9f63bdc 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -588,7 +588,7 @@ int pci_proc_domain(struct pci_bus *bus)
return 0;
else {
struct pci_controller *hose = pci_bus_to_host(bus);
- return hose->buid;
+ return hose->buid != 0;
}
}
^ permalink raw reply related
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Matt Sealey @ 2007-09-26 14:00 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <997c015e13649d06e246d3d2c1369100@kernel.crashing.org>
Segher Boessenkool wrote:
>>>> Why not put the PVR in core dumps that'd make it all easier..
>>>
>>> PVR wouldn't be very useful... What if you have altivec disabled ? Also
>>> that would mean your gdb has to know about all new processors...
>>
>> Is that such a big deal? :D
>>
>> Hypothetically it would be impossible to determine if you were running
>> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
>> given the data saved.
>
> And that is exactly as should be: a core dump represents the execution
> state of a user program, it has nothing to do with the machine it was
> generated on; it even is possible to restart a core dump generated on
> e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., SPE)
> that the latter processor / execution environment doesn't provide.
A hypothetical question for you then..
What happens if you get a core dump for a G4 app which dynamically detects
AltiVec presence (from PVR or /proc) then crashes before AltiVec is enabled
in the kernel for that task (i.e. before any vector exception) and you run
it on your G3 and it magically carries on (maybe a race condition or so)
and causes a vector exception later?
Isn't that kind of useless? Wouldn't it?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Segher Boessenkool @ 2007-09-26 13:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <AE678FA4-5ABF-4EAC-B691-CCE5D277955F@kernel.crashing.org>
>>>>> Why not put the PVR in core dumps that'd make it all easier..
>>>>
>>>> PVR wouldn't be very useful... What if you have altivec disabled ?
>>>> Also
>>>> that would mean your gdb has to know about all new processors...
>>>
>>> Is that such a big deal? :D
>>>
>>> Hypothetically it would be impossible to determine if you were
>>> running
>>> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
>>> given the data saved.
>>
>> And that is exactly as should be: a core dump represents the execution
>> state of a user program, it has nothing to do with the machine it was
>> generated on; it even is possible to restart a core dump generated on
>> e.g. an e500 on a 970, as long as it doesn't use facilities (e.g.,
>> SPE)
>> that the latter processor / execution environment doesn't provide.
>>
>>> Is that a misfeature of GDB that we even have to
>>> worry about this, or some noble plus point of a unified ISA? You
>>> decide :)
>>
>> We don't have to worry about it :-)
>
> We should worry about it. If one misinterprets the core file you will
> get unexpected behavior.
I read this as "worry about the PVR".
> I see no reason not to do this properly and mark the sections such
> that its clear if its AltiVec or SPE state, rather than overloading
> the x86 XFPU type.
Yes, certainly, I thought we all agreed on that automatically :-)
Segher
^ permalink raw reply
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Kumar Gala @ 2007-09-26 13:32 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <997c015e13649d06e246d3d2c1369100@kernel.crashing.org>
On Sep 26, 2007, at 8:21 AM, Segher Boessenkool wrote:
>>>> Why not put the PVR in core dumps that'd make it all easier..
>>>
>>> PVR wouldn't be very useful... What if you have altivec disabled ?
>>> Also
>>> that would mean your gdb has to know about all new processors...
>>
>> Is that such a big deal? :D
>>
>> Hypothetically it would be impossible to determine if you were
>> running
>> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
>> given the data saved.
>
> And that is exactly as should be: a core dump represents the execution
> state of a user program, it has nothing to do with the machine it was
> generated on; it even is possible to restart a core dump generated on
> e.g. an e500 on a 970, as long as it doesn't use facilities (e.g.,
> SPE)
> that the latter processor / execution environment doesn't provide.
>
>> Is that a misfeature of GDB that we even have to
>> worry about this, or some noble plus point of a unified ISA? You
>> decide :)
>
> We don't have to worry about it :-)
We should worry about it. If one misinterprets the core file you
will get unexpected behavior. I see no reason not to do this
properly and mark the sections such that its clear if its AltiVec or
SPE state, rather than overloading the x86 XFPU type.
- k
^ permalink raw reply
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Segher Boessenkool @ 2007-09-26 13:21 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev
In-Reply-To: <46FA3CDD.2070409@genesi-usa.com>
>>> Why not put the PVR in core dumps that'd make it all easier..
>>
>> PVR wouldn't be very useful... What if you have altivec disabled ?
>> Also
>> that would mean your gdb has to know about all new processors...
>
> Is that such a big deal? :D
>
> Hypothetically it would be impossible to determine if you were running
> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
> given the data saved.
And that is exactly as should be: a core dump represents the execution
state of a user program, it has nothing to do with the machine it was
generated on; it even is possible to restart a core dump generated on
e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., SPE)
that the latter processor / execution environment doesn't provide.
> Is that a misfeature of GDB that we even have to
> worry about this, or some noble plus point of a unified ISA? You
> decide :)
We don't have to worry about it :-)
Segher
^ permalink raw reply
* [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on any processors with QUICC Engine
From: Anton Vorontsov @ 2007-09-26 13:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: David Brownell, spi-devel-general, linuxppc-dev
In-Reply-To: <7881139C-EEF1-41DC-AB0F-115632E892B8@kernel.crashing.org>
On Tue, Sep 25, 2007 at 11:00:38PM -0500, Kumar Gala wrote:
> I'm still in favor of making it PPC_83xx || QUICC_ENGINE.
Submitting... ;-)
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [POWERPC][SPI] spi_mpc83xx: allow use on any processors with QUICC Engine
Currently, all QE SPI controllers are almost the same comparing to
MPC83xx's, thus let's use that driver for them.
Tested to work on MPC85xx in loopback mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/Kconfig | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b915711..a77ede5 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -124,16 +124,17 @@ config SPI_MPC52xx_PSC
Controller in master SPI mode.
config SPI_MPC83xx
- tristate "Freescale MPC83xx SPI controller"
- depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
+ tristate "Freescale MPC83xx/QUICC Engine SPI controller"
+ depends on SPI_MASTER && (PPC_83xx || QUICC_ENGINE) && EXPERIMENTAL
select SPI_BITBANG
help
- This enables using the Freescale MPC83xx SPI controller in master
- mode.
+ This enables using the Freescale MPC83xx and QUICC Engine SPI
+ controllers in master mode.
Note, this driver uniquely supports the SPI controller on the MPC83xx
- family of PowerPC processors. The MPC83xx uses a simple set of shift
- registers for data (opposed to the CPM based descriptor model).
+ family of PowerPC processors, plus processors with QUICC Engine
+ technology. This driver uses a simple set of shift registers for data
+ (opposed to the CPM based descriptor model).
config SPI_OMAP_UWIRE
tristate "OMAP1 MicroWire"
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH 2/2] fsl/embedded6xx: don't cast the result of of_get_property
From: Segher Boessenkool @ 2007-09-26 12:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Jeremy Kerr
In-Reply-To: <20070926104419.1b92002e.sfr@canb.auug.org.au>
>> - avr_clock = *(u32*)of_get_property(avr, "clock-frequency", &len);
>> - phys_addr = ((u32*)of_get_property(avr, "reg", &len))[0];
>> + phys_addr = of_get_property(avr, "reg", &len);
>> + avr_clock_prop = of_get_property(avr, "clock-frequency", &len);
>
> If you don't use the value of the len variable, then you can pass NULL
> to
> of_get_property.
OTOH, it is almost always an error to not use the length (missing
error check).
Segher
^ permalink raw reply
* Re: jffs2 file system on MPC8272ADS board
From: Nethra @ 2007-09-26 12:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925202257.559a78c5@ru.mvista.com>
Hello ,
>>
>> hi everyone,
>>
>> I m using custom board similar to MPC8272ADS board...
>>
>> 1) For the first time it boots up properly in case if we overwrite any
>> existing binaries using nfs mounted file system on the board, after
>> rebooting it displays fallowing message...
>>
>> Further such events for this erase block will not be printed
>> Eep. Child "null" (ino #1346) of dir ino #3 doesn't exist!
>> Eep. Child "autocomm" (ino #463) of dir ino #461 doesn't exist!
>> Eep. Child "calibration" (ino #464) of dir ino #461 doesn't exist!
>> Eep. Child "coredsp_driver.ko" (ino #939) of dir ino #336 doesn't exist!
>> Inode #1307 was a directory with children - removing those too...
>> Inode #564 was a directory with children - removing those too...
>> Inode #565 was a directory with children - removing those too...
>> Inode #1112 was a directory with children - removing those too...
>> Inode #1115 was a directory with children - removing those too...
>> Inode #1118 was a directory with children - removing those too...
>> Inode #1123 was a directory with children - removing those too...
>>
>> after this board boots up properly....but it not be having overwritten
>> files
>>
>Have you created jffs2 file system on flash prior to mounting it?
Yes I created jffs2 filesytem using mkfs.jffs2 prior to mounting and then I
am over-writing some of the binaries. In case of overwrites from NFS after
reboot
I see the above errors & the binaries/directories gets deleted from the
jffs2 partition.
>> 3) when board is running properly in between it starts printing on
>> console
>> repeatedly...
>>
>Do the proper MTD partitions setup, erase the partition and create jffs2
filesystem on it.
>If after all those steps you're still getting output, that is prolly flakey
flash.
>> Header CRC failed on REF_PRISTINE node at 0x00638a6c: Read 0xffffffff,
>> calculated 0x44660075
>> Node totlen on flash (0xffffffff) != totlen from node ref (0x00000254)
>> Header CRC failed on REF_PRISTINE node at 0x00638cc0: Read 0xffffffff,
>> calculated 0x44660075
[...]
>> and
>>
>> file system is created using fallowing command..
>>
>> mkfs.jffs2 -r RFS_NEW/ -e 0x20000 -o /tftpboot/jffs2_img -b
>>
>I am recalling playing with the options upper also cured the jffs2 warnings
(not as many as yours but anyway)
The other options I am wondering about,
-c, --cleanmarker=SIZE Size of cleanmarker (default 12)
-n, --no-cleanmarkers Don't add a cleanmarker to every eraseblock
cleanmaker size will it help the cause?
Nethra
--
View this message in context: http://www.nabble.com/jffs2-file-system-on-MPC8272ADS-board-tf4513530.html#a12900017
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/7] PowerPC64: Not to insert EA=0 entry at initializing SLB
From: Arnd Bergmann @ 2007-09-26 12:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20070926.132034.-1300539325.kouish@swc.toshiba.co.jp>
On Wednesday 26 September 2007, Ishizaki Kou wrote:
> This is a workaround NOT to insert EA=0 entry at initializing SLB.
> Without this patch, you can see /sbin/init hanging at a machine
> which has less or equal than 256MB memory.
Can you elaborate? I don't understand why /sbin/init will hang
because of an incorrect SLB entry, or how that entry gets
initialized from get_paca()->kstack.
Are you still trying to find a better fix for 2.6.24, or do
you intend to have this patch go in for now?
Also, I did not get a patch 4/7 and 5/7. Did you send them to
some other mailing list, or did they get lost on the way?
Arnd <><
^ permalink raw reply
* Re: [PATCH 7/7] Celleb: update for PCI
From: Arnd Bergmann @ 2007-09-26 12:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20070926.134050.1102532600.kouish@swc.toshiba.co.jp>
On Wednesday 26 September 2007, Ishizaki Kou wrote:
> This is a patch kit to support PCI bus on Celleb with new "I/O routines
> for PowerPC." External PCI on Celleb must do explicit synchronization
> with devices (Bus has no automatic synchronization feature).
It seems you are duplicating a lot of
arch/powerpc/platforms/cell/io-workarounds.c, in order to work around
the same problem:
> +static struct celleb_pci_bus *celleb_pci_find(unsigned long vaddr,
> + unsigned long paddr)
> +{
> + int i, j;
> + struct resource *res;
> +
> + for (i = 0; i < celleb_pci_count; i++) {
> + struct celleb_pci_bus *bus = &celleb_pci_busses[i];
> + struct pci_controller *phb = bus->phb;
> + if (paddr)
> + for (j = 0; j < 3; j++) {
> + res = &phb->mem_resources[j];
> + if (paddr >= res->start && paddr <= res->end)
> + return bus;
> + }
> + res = &phb->io_resource;
> + if (vaddr && vaddr >= res->start && vaddr <= res->end)
> + return bus;
> + }
> + return NULL;
> +}
> +
> +static void celleb_io_flush(const PCI_IO_ADDR addr)
> +{
> + struct celleb_pci_bus *bus;
> + int token;
> +
> + token = PCI_GET_ADDR_TOKEN(addr);
> +
> + if (token && token <= celleb_pci_count)
> + bus = &celleb_pci_busses[token - 1];
> + else {
> + unsigned long vaddr, paddr;
> + pte_t *ptep;
> +
> + vaddr = (unsigned long)PCI_FIX_ADDR(addr);
> + if (vaddr < PHB_IO_BASE || vaddr >= PHB_IO_END)
> + return;
> +
> + ptep = find_linux_pte(init_mm.pgd, vaddr);
> + if (ptep == NULL)
> + paddr = 0;
> + else
> + paddr = pte_pfn(*ptep) << PAGE_SHIFT;
> + bus = celleb_pci_find(vaddr, paddr);
> +
> + if (bus == NULL)
> + return;
> + }
> +
> + if (bus->dummy_read)
> + bus->dummy_read(bus->phb);
> +}
> +
> +static u8 celleb_readb(const PCI_IO_ADDR addr)
> +{
> + u8 val;
> + val = __do_readb(addr);
> + celleb_io_flush(addr);
> + return val;
> +}
> +
> +static u16 celleb_readw(const PCI_IO_ADDR addr)
> +{
> + u16 val;
> + val = __do_readw(addr);
> + celleb_io_flush(addr);
> + return val;
> +}
> +
> +static u32 celleb_readl(const PCI_IO_ADDR addr)
> +{
> + u32 val;
> + val = __do_readl(addr);
> + celleb_io_flush(addr);
> + return val;
> +}
> +
> +static u64 celleb_readq(const PCI_IO_ADDR addr)
> +{
> + u64 val;
> + val = __do_readq(addr);
> + celleb_io_flush(addr);
> + return val;
> +}
> +
> +static u16 celleb_readw_be(const PCI_IO_ADDR addr)
> +{
> + u16 val;
> + val = __do_readw_be(addr);
> + celleb_io_flush(addr);
> + return val;
> +}
> +
> +static u32 celleb_readl_be(const PCI_IO_ADDR addr)
> +{
> + u32 val;
> + val = __do_readl_be(addr);
> + celleb_io_flush(addr);
> + return val;
> +}
> +
> +static u64 celleb_readq_be(const PCI_IO_ADDR addr)
> +{
> + u64 val;
> + val = __do_readq_be(addr);
> + celleb_io_flush(addr);
> + return val;
> +}
> +
> +static void celleb_readsb(const PCI_IO_ADDR addr,
> + void *buf, unsigned long count)
> +{
> + __do_readsb(addr, buf, count);
> + celleb_io_flush(addr);
> +}
> +
> +static void celleb_readsw(const PCI_IO_ADDR addr,
> + void *buf, unsigned long count)
> +{
> + __do_readsw(addr, buf, count);
> + celleb_io_flush(addr);
> +}
> +
> +static void celleb_readsl(const PCI_IO_ADDR addr,
> + void *buf, unsigned long count)
> +{
> + __do_readsl(addr, buf, count);
> + celleb_io_flush(addr);
> +}
> +
> +static void celleb_memcpy_fromio(void *dest,
> + const PCI_IO_ADDR src,
> + unsigned long n)
> +{
> + __do_memcpy_fromio(dest, src, n);
> + celleb_io_flush(src);
> +}
> +
> +static void __iomem *celleb_ioremap(unsigned long addr,
> + unsigned long size,
> + unsigned long flags)
> +{
> + struct celleb_pci_bus *bus;
> + void __iomem *res = __ioremap(addr, size, flags);
> + int busno;
> +
> + bus = celleb_pci_find(0, addr);
> + if (bus != NULL) {
> + busno = bus - celleb_pci_busses;
> + PCI_SET_ADDR_TOKEN(res, busno + 1);
> + }
> + return res;
> +}
Is there a way that we can make that code common? I guess there could be a
file in arch/powerpc/sysdev that can handle this correctly for all hardware
that requires this particular workaround (currently celleb and QS20, but
potentially more).
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/7] Celleb: Support for Power/Reset buttons
From: Arnd Bergmann @ 2007-09-26 11:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20070926.132556.1723232353.kouish@swc.toshiba.co.jp>
On Wednesday 26 September 2007, Ishizaki Kou wrote:
> This is a patch to support Power/Reset buttons on Beat on Celleb.
>
> On Beat, we have an event from Beat if Power button or Reset button
> is pressed. This patch catches the event and convert it to a signal
> to INIT process.
>
> /sbin/inittab have no entry to turn the machine power off so we have
> to detect if power button is pressed or not internally in our driver.
> This idea is taken from PS3's event handling subsystem.
>
> Signed-off-by: Kou Ishizaki <Kou.Ishizaki@toshiba.co.jp>
Basically looks good. At some point I want to do a similar driver
for the IBM cell blade, but I fear there is not much code we
can share.
> +static irqreturn_t beat_power_event(int virq, void *arg)
> +{
> + printk(KERN_DEBUG "Beat: power button pressed\n");
> + beat_pm_poweroff_flag = 1;
> + if (kill_cad_pid(SIGINT, 1)) {
> + /* Just in case killing init process failed */
> + beat_power_off();
> + }
> + return IRQ_HANDLED;
> +}
I think this should call ctrl_alt_del() instead of doing
kill_cad_pid() directly.
Also, I think you should better not call the low-level
beat_power_off() function, but rather a high-level function
that goes through the reboot notifiers first.
kernel_restart() seems appropriate for that.
> +static irqreturn_t beat_reset_event(int virq, void *arg)
> +{
> + printk(KERN_DEBUG "Beat: reset button pressed\n");
> + beat_pm_poweroff_flag = 0;
> + if (kill_cad_pid(SIGINT, 1)) {
> + /* Just in case killing init process failed */
> + beat_restart(NULL);
> + }
> + return IRQ_HANDLED;
> +}
same here, except calling kernel_halt() in the end.
> +static int __init beat_event_init(void)
> +{
> + if (!machine_is(celleb) || !firmware_has_feature(FW_FEATURE_BEAT))
> + return -EINVAL;
Shouldn't one of the two be sufficent? It seems to me that you want to
probe for either celleb or BEAT, but not both, considering that celleb
implies BEAT.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/7] Celleb: Move pause, kexec_cpu_down to beat.c
From: Arnd Bergmann @ 2007-09-26 11:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <20070926.132314.-432833655.kouish@swc.toshiba.co.jp>
On Wednesday 26 September 2007, Ishizaki Kou wrote:
> This patch is an update for "Beat on Celleb"
> =A0 - Move beat_pause(), beat_kexec_cpu_down() from setup.c to beat.c
>=20
> Signed-off-by: <Kou.Ishizaki@toshiba.co.jp>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
The patch looks good, once you fix this one line:
> @@ -36,5 +36,9 @@ ssize_t beat_nvram_get_size(void);
> =A0ssize_t beat_nvram_read(char *, size_t, loff_t *);
> =A0ssize_t beat_nvram_write(char *, size_t, loff_t *);
> =A0int beat_set_xdabr(unsigned long);
> +void beat_power_save(void);
> +#ifdef CONFIG_KEXEC
> +void beat_kexec_cpu_down(int, int);
> +#endif
=46unction declarations in headers files should not be enclosed in #ifdef,
it only causes unnecessary rebuilds when the configuration changes, but
does not help.
Arnd <><
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-09-26 11:33 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, jk
In-Reply-To: <18168.62378.472571.655865@cargo.ozlabs.ibm.com>
I wrote:
> Linus,
>
> Please do
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> to get a patch from Roland McGrath that fixes a user-triggerable oops
> on 64-bit powerpc.
I have added another commit from Jeremy Kerr fixing a mismerge that
caused a user visible ABI regression from 2.6.22. The diffstat and
log below include both the patch from Roland and this new patch.
Thanks,
Paul.
arch/powerpc/kernel/process.c | 7 +++++++
arch/powerpc/platforms/cell/spufs/file.c | 4 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
commit 603c461250b223ac42c10b8d1df653af1a361d44
Author: Jeremy Kerr <jk@ozlabs.org>
Date: Wed Sep 26 10:53:45 2007 +1000
[POWERPC] spufs: fix mismerge, making context signal{1,2} files readable again
The commit 8b6f50ef1d5cc86b278eb42bc91630fad455fb10 seems to have
been affected by a mismerge of a duplicate patch
(d054b36ffd302ec65aabec16a0c60ddd9e6b5a62) - both the
spufs_dir_contents and spufs_dir_nosched_contents have been given
write-only signal notification files.
This change reverts the spufs_dir_contents array to use the
readable signal notification file implementation.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit 474f81967217f3bec2389ae913da72641f2c40e3
Author: Roland McGrath <roland@redhat.com>
Date: Mon Sep 24 16:52:44 2007 -0700
[POWERPC] Ensure FULL_REGS on exec
When PTRACE_O_TRACEEXEC is used, a ptrace call to fetch the registers at
the PTRACE_EVENT_EXEC stop (PTRACE_PEEKUSR) will oops in CHECK_FULL_REGS.
With recent versions, "gdb --args /bin/sh -c 'exec /bin/true'" and "run" at
the (gdb) prompt is sufficient to produce this. I also have written an
isolated test case, see https://bugzilla.redhat.com/show_bug.cgi?id=301791#c15.
This change fixes the problem by clearing the low bit of pt_regs.trap in
start_thread so that FULL_REGS is true again. This is correct since all of
the GPRs that "full" refers to are cleared in start_thread.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ 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