Re: [PATCH] v4l: fix build error for et61x251 driver
On Fri, Sep 14, 2007 at 03:53:06AM +0200, Luca Risolia wrote: > On Friday 14 September 2007 02:09:01 Linus Torvalds wrote: > > On Fri, 14 Sep 2007, Luca Risolia wrote: > > > Hacked-by: Luca Risolia <[EMAIL PROTECTED]> > > > > > > On Friday 14 September 2007 00:27:17 Andreas Herrmann wrote: > > > > This fixes a kernel build problem and > > > > should make it into 2.6.23, I think. > > > > > > > > > > This patch is really ugly. Well, yes. I should have known as I converted so many occurences of to_video_device to container_of in my second patch. > > Why can't the "to_video_device()" macro be used? Just move it to a place > > where it's usable! IOW, what's wrong with the *much* simpler patch below? > > There's nothing wtong in my opinion. I do not know the exact reason why Mauro > moved "to_video_device()" into CONFIG_VIDEO_V4L1_COMPAT. Pheraps he can give > more details about this change. BTW, just a few V4L2 drivers and videodev seem to use this construct: video/usbvision/usbvision-video.c:container_of(cd, struct video_device, class_dev); video/sn9c102/sn9c102_core.c: cam = video_get_drvdata(container_of(cd, struct video_device, video/sn9c102/sn9c102_core.c- class_dev)); video/videodev.c: struct video_device *vfd = container_of(cd, struct video_device, video/videodev.c- class_dev); And then their are drivers with other variants of container_of, e.g.: video/pvrusb2/pvrusb2-v4l2.c: vp = container_of(chp,struct pvr2_v4l2,channel); video/bt8xx/bttv-vbi.c: struct bttv_buffer *buf = container_of(vb,struct bttv_buffer,vb); ... I think, there should be a to_video_device macro for usage in v4l2. An most probable for the other container_of stuff (when more there is more than one occurence of a particular construct), drivers should provide their own macro, e.g. to_video_buffer() or so. That's what other subsystems do. It is more self-explanatory than a direct usage of container_of. So why not apply (my first patch ... oh no, of course that's rubbish ;-) Linus' below patch for 2.6.23 to fix the compilation for that particular driver. And to work on the conversion of container_of() stuff to meaningful macros for the next kernel release? Regards, Andreas > > > > That "to_video_device()" macro has absolutely _nothing_ to do with > > CONFIG_VIDEO_V4L1_COMPAT, as far as I can tell! > > > > Linus > > --- > > diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h > > index d62847f..17f8f3a 100644 > > --- a/include/media/v4l2-dev.h > > +++ b/include/media/v4l2-dev.h > > @@ -337,6 +337,9 @@ void *priv; > > struct class_device class_dev; /* sysfs */ > > }; > > > > +/* Class-dev to video-device */ > > +#define to_video_device(cd) container_of(cd, struct video_device, > > class_dev) + > > /* Version 2 functions */ > > extern int video_register_device(struct video_device *vfd, int type, int > > nr); void video_unregister_device(struct video_device *); > > @@ -354,11 +357,9 @@ extern int video_usercopy(struct inode *inode, struct > > file *file, int (*func)(struct inode *inode, struct file *file, > > unsigned int cmd, void *arg)); > > > > - > > #ifdef CONFIG_VIDEO_V4L1_COMPAT > > #include > > > > -#define to_video_device(cd) container_of(cd, struct video_device, > > class_dev) static inline int __must_check > > video_device_create_file(struct video_device *vfd, > > struct class_device_attribute *attr) > > Best regards > Luca Risolia - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] v4l: fix build error for et61x251 driver
On Fri, Sep 14, 2007 at 03:53:06AM +0200, Luca Risolia wrote: On Friday 14 September 2007 02:09:01 Linus Torvalds wrote: On Fri, 14 Sep 2007, Luca Risolia wrote: Hacked-by: Luca Risolia [EMAIL PROTECTED] On Friday 14 September 2007 00:27:17 Andreas Herrmann wrote: This fixes a kernel build problem and should make it into 2.6.23, I think. This patch is really ugly. Well, yes. I should have known as I converted so many occurences of to_video_device to container_of in my second patch. Why can't the to_video_device() macro be used? Just move it to a place where it's usable! IOW, what's wrong with the *much* simpler patch below? There's nothing wtong in my opinion. I do not know the exact reason why Mauro moved to_video_device() into CONFIG_VIDEO_V4L1_COMPAT. Pheraps he can give more details about this change. BTW, just a few V4L2 drivers and videodev seem to use this construct: video/usbvision/usbvision-video.c:container_of(cd, struct video_device, class_dev); video/sn9c102/sn9c102_core.c: cam = video_get_drvdata(container_of(cd, struct video_device, video/sn9c102/sn9c102_core.c- class_dev)); video/videodev.c: struct video_device *vfd = container_of(cd, struct video_device, video/videodev.c- class_dev); And then their are drivers with other variants of container_of, e.g.: video/pvrusb2/pvrusb2-v4l2.c: vp = container_of(chp,struct pvr2_v4l2,channel); video/bt8xx/bttv-vbi.c: struct bttv_buffer *buf = container_of(vb,struct bttv_buffer,vb); ... I think, there should be a to_video_device macro for usage in v4l2. An most probable for the other container_of stuff (when more there is more than one occurence of a particular construct), drivers should provide their own macro, e.g. to_video_buffer() or so. That's what other subsystems do. It is more self-explanatory than a direct usage of container_of. So why not apply (my first patch ... oh no, of course that's rubbish ;-) Linus' below patch for 2.6.23 to fix the compilation for that particular driver. And to work on the conversion of container_of() stuff to meaningful macros for the next kernel release? Regards, Andreas That to_video_device() macro has absolutely _nothing_ to do with CONFIG_VIDEO_V4L1_COMPAT, as far as I can tell! Linus --- diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h index d62847f..17f8f3a 100644 --- a/include/media/v4l2-dev.h +++ b/include/media/v4l2-dev.h @@ -337,6 +337,9 @@ void *priv; struct class_device class_dev; /* sysfs */ }; +/* Class-dev to video-device */ +#define to_video_device(cd) container_of(cd, struct video_device, class_dev) + /* Version 2 functions */ extern int video_register_device(struct video_device *vfd, int type, int nr); void video_unregister_device(struct video_device *); @@ -354,11 +357,9 @@ extern int video_usercopy(struct inode *inode, struct file *file, int (*func)(struct inode *inode, struct file *file, unsigned int cmd, void *arg)); - #ifdef CONFIG_VIDEO_V4L1_COMPAT #include linux/mm.h -#define to_video_device(cd) container_of(cd, struct video_device, class_dev) static inline int __must_check video_device_create_file(struct video_device *vfd, struct class_device_attribute *attr) Best regards Luca Risolia - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Commit 02a5e0acb3cb85d80d0fe834e366d38a92bbaa22 might break kernel build
Due to commit 02a5e0acb3cb85d80d0fe834e366d38a92bbaa22
kernel build is broken if (CONFIG_COMPAT && ! CONFIG_BLOCK):
CC fs/compat_ioctl.o
In file included from include/linux/raid/md_k.h:19,
from include/linux/raid/md.h:54,
from fs/compat_ioctl.c:25:
include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
include/linux/raid/../../../drivers/md/dm-bio-list.h:40: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
include/linux/raid/../../../drivers/md/dm-bio-list.h:48: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h:51: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
include/linux/raid/../../../drivers/md/dm-bio-list.h:64: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_merge_:
include/linux/raid/../../../drivers/md/dm-bio-list.h:78: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
include/linux/raid/../../../drivers/md/dm-bio-list.h:90: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h:94: error: dereferencing
pointer to incomplete type
make[1]: *** [fs/compat_ioctl.o] Error 1
make: *** [fs] Error 2
So either revert that commit or better apply the attached patch to fix it.
Regards,
Andreas
--
Fix kernel compilation if CONFIG_COMPAT is selected but CONFIG_BLOCK is not.
This is needed due to commit
02a5e0acb3cb85d80d0fe834e366d38a92bbaa22
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/md/dm-bio-list.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/md/dm-bio-list.h b/drivers/md/dm-bio-list.h
index 16ee3b0..3f7b827 100644
--- a/drivers/md/dm-bio-list.h
+++ b/drivers/md/dm-bio-list.h
@@ -9,6 +9,8 @@
#include
+#ifdef CONFIG_BLOCK
+
struct bio_list {
struct bio *head;
struct bio *tail;
@@ -106,4 +108,5 @@ static inline struct bio *bio_list_get(struct bio_list *bl)
return bio;
}
+#endif /* CONFIG_BLOCK */
#endif
--
1.5.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] v4l: Build error with et61x251, if V4L1_COMPAT is not selected
On Thu, Sep 13, 2007 at 05:07:16PM +0200, Luca Risolia wrote: > On Thursday 13 September 2007 14:36:27 [EMAIL PROTECTED] wrote: > > With current git tree I get an build error > > for et61x251, if V4L1_COMPAT is not selected: > > > > drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_: > > drivers/media/video/et61x251/et61x251_core.c:718: error: implicit > > declaration of to_video_device > > > > Fix: add VIDEO_V4L1_COMPAT as a dependency for this driver. > > No, wait. The driver really is V4L2 only. If you can, please fix it by > replacing to_video_device() with container_of() instead: > > cam = video_get_drvdata(container_of(cd, struct video_device, class_dev)); Ah just some v4l1 remainders. I'll do that. Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] v4l: Build error with et61x251, if V4L1_COMPAT is not selected
With current git tree I get an build error for et61x251, if V4L1_COMPAT is not selected: drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_: drivers/media/video/et61x251/et61x251_core.c:718: error: implicit declaration of to_video_device Fix: add VIDEO_V4L1_COMPAT as a dependency for this driver. Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- drivers/media/video/et61x251/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/et61x251/Kconfig b/drivers/media/video/et61x251/Kconfig index dcc1a03..9143424 100644 --- a/drivers/media/video/et61x251/Kconfig +++ b/drivers/media/video/et61x251/Kconfig @@ -1,6 +1,6 @@ config USB_ET61X251 tristate "USB ET61X[12]51 PC Camera Controller support" - depends on VIDEO_V4L2 + depends on VIDEO_V4L2 && VIDEO_V4L1_COMPAT ---help--- Say Y here if you want support for cameras based on Etoms ET61X151 or ET61X251 PC Camera Controllers. -- 1.5.3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] v4l: Build error with et61x251, if V4L1_COMPAT is not selected
With current git tree I get an build error for et61x251, if V4L1_COMPAT is not selected: drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_: drivers/media/video/et61x251/et61x251_core.c:718: error: implicit declaration of to_video_device Fix: add VIDEO_V4L1_COMPAT as a dependency for this driver. Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- drivers/media/video/et61x251/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/et61x251/Kconfig b/drivers/media/video/et61x251/Kconfig index dcc1a03..9143424 100644 --- a/drivers/media/video/et61x251/Kconfig +++ b/drivers/media/video/et61x251/Kconfig @@ -1,6 +1,6 @@ config USB_ET61X251 tristate USB ET61X[12]51 PC Camera Controller support - depends on VIDEO_V4L2 + depends on VIDEO_V4L2 VIDEO_V4L1_COMPAT ---help--- Say Y here if you want support for cameras based on Etoms ET61X151 or ET61X251 PC Camera Controllers. -- 1.5.3 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] v4l: Build error with et61x251, if V4L1_COMPAT is not selected
On Thu, Sep 13, 2007 at 05:07:16PM +0200, Luca Risolia wrote: On Thursday 13 September 2007 14:36:27 [EMAIL PROTECTED] wrote: With current git tree I get an build error for et61x251, if V4L1_COMPAT is not selected: drivers/media/video/et61x251/et61x251_core.c: In et61x251_show_: drivers/media/video/et61x251/et61x251_core.c:718: error: implicit declaration of to_video_device Fix: add VIDEO_V4L1_COMPAT as a dependency for this driver. No, wait. The driver really is V4L2 only. If you can, please fix it by replacing to_video_device() with container_of() instead: cam = video_get_drvdata(container_of(cd, struct video_device, class_dev)); Ah just some v4l1 remainders. I'll do that. Regards, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Commit 02a5e0acb3cb85d80d0fe834e366d38a92bbaa22 might break kernel build
Due to commit 02a5e0acb3cb85d80d0fe834e366d38a92bbaa22
kernel build is broken if (CONFIG_COMPAT ! CONFIG_BLOCK):
CC fs/compat_ioctl.o
In file included from include/linux/raid/md_k.h:19,
from include/linux/raid/md.h:54,
from fs/compat_ioctl.c:25:
include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
include/linux/raid/../../../drivers/md/dm-bio-list.h:40: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
include/linux/raid/../../../drivers/md/dm-bio-list.h:48: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h:51: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
include/linux/raid/../../../drivers/md/dm-bio-list.h:64: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_merge_:
include/linux/raid/../../../drivers/md/dm-bio-list.h:78: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h: In bio_list_:
include/linux/raid/../../../drivers/md/dm-bio-list.h:90: error: dereferencing
pointer to incomplete type
include/linux/raid/../../../drivers/md/dm-bio-list.h:94: error: dereferencing
pointer to incomplete type
make[1]: *** [fs/compat_ioctl.o] Error 1
make: *** [fs] Error 2
So either revert that commit or better apply the attached patch to fix it.
Regards,
Andreas
--
Fix kernel compilation if CONFIG_COMPAT is selected but CONFIG_BLOCK is not.
This is needed due to commit
02a5e0acb3cb85d80d0fe834e366d38a92bbaa22
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
drivers/md/dm-bio-list.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/md/dm-bio-list.h b/drivers/md/dm-bio-list.h
index 16ee3b0..3f7b827 100644
--- a/drivers/md/dm-bio-list.h
+++ b/drivers/md/dm-bio-list.h
@@ -9,6 +9,8 @@
#include linux/bio.h
+#ifdef CONFIG_BLOCK
+
struct bio_list {
struct bio *head;
struct bio *tail;
@@ -106,4 +108,5 @@ static inline struct bio *bio_list_get(struct bio_list *bl)
return bio;
}
+#endif /* CONFIG_BLOCK */
#endif
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] radeonfb: fix chip definition for Radeon Xpress 200M 0x5975
I think this is 2.6.23 material. Please apply.
Thanks.
Regards,
Andreas
--
radeonfb: fix chip definition for Radeon Xpress 200M 0x5975
This fixes a problem introduced with commit
b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c
The commit added a wrong chip definition to radeonfb which causes
a blank console on my Laptop if radeonfb is loaded.
The patch
- renames PCI_CHIP_RS485_5975 to PCI_CHIP_RS482_5975
- corrects the chip family (RS480 instead of R300) for 0x5975
- ensures that PCI IDs are in ascending order in ati_ids.h
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/video/aty/ati_ids.h | 12 ++--
drivers/video/aty/radeon_base.c |3 +--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/video/aty/ati_ids.h b/drivers/video/aty/ati_ids.h
index 685a754..dca2eb8 100644
--- a/drivers/video/aty/ati_ids.h
+++ b/drivers/video/aty/ati_ids.h
@@ -192,6 +192,12 @@
#define PCI_CHIP_RS300_58350x5835
#define PCI_CHIP_RS300_58360x5836
#define PCI_CHIP_RS300_58370x5837
+#define PCI_CHIP_RS480_5955 0x5955
+#define PCI_CHIP_RV280_59600x5960
+#define PCI_CHIP_RV280_59610x5961
+#define PCI_CHIP_RV280_59620x5962
+#define PCI_CHIP_RV280_59640x5964
+#define PCI_CHIP_RS482_59750x5975
#define PCI_CHIP_RV370_5B60 0x5B60
#define PCI_CHIP_RV370_5B61 0x5B61
#define PCI_CHIP_RV370_5B62 0x5B62
@@ -200,14 +206,8 @@
#define PCI_CHIP_RV370_5B65 0x5B65
#define PCI_CHIP_RV370_5B66 0x5B66
#define PCI_CHIP_RV370_5B67 0x5B67
-#define PCI_CHIP_RV280_59600x5960
-#define PCI_CHIP_RV280_59610x5961
-#define PCI_CHIP_RV280_59620x5962
-#define PCI_CHIP_RV280_59640x5964
-#define PCI_CHIP_RS485_59750x5975
#define PCI_CHIP_RV280_5C610x5C61
#define PCI_CHIP_RV280_5C630x5C63
#define PCI_CHIP_R423_5D57 0x5D57
#define PCI_CHIP_RS350_7834 0x7834
#define PCI_CHIP_RS350_7835 0x7835
-#define PCI_CHIP_RS480_5955 0x5955
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 5a8af4d..4b747bd 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -102,6 +102,7 @@
static struct pci_device_id radeonfb_pci_table[] = {
/* Radeon Xpress 200m */
CHIP_DEF(PCI_CHIP_RS480_5955, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
+ CHIP_DEF(PCI_CHIP_RS482_5975, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* Mobility M6 */
CHIP_DEF(PCI_CHIP_RADEON_LY,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RADEON_LZ,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
@@ -153,8 +154,6 @@ static struct pci_device_id radeonfb_pci_table[] = {
/* Mobility 9200 (M9+) */
CHIP_DEF(PCI_CHIP_RV280_5C61, RV280, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RV280_5C63, RV280, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
- /*Mobility Xpress 200 */
- CHIP_DEF(PCI_CHIP_RS485_5975, R300, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* 9200 */
CHIP_DEF(PCI_CHIP_RV280_5960, RV280, CHIP_HAS_CRTC2),
CHIP_DEF(PCI_CHIP_RV280_5961, RV280, CHIP_HAS_CRTC2),
--
1.5.1.6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] radeonfb: fix setting of PPLL_REF_DIV for RV370 5B60
IMHO this is 2.6.23 material. Please apply.
Thanks a lot.
Regards,
Andreas
--
radeonfb: fix setting of PPLL_REF_DIV for RV370 5B60.
As observed with various Radeon X300 cards console goes blank
without that fix.
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/video/aty/radeon_base.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 47ca62f..5a8af4d 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -1285,7 +1285,8 @@ static void radeon_write_pll_regs(struct radeonfb_info
*rinfo, struct radeon_reg
if (rinfo->family == CHIP_FAMILY_R300 ||
rinfo->family == CHIP_FAMILY_RS300 ||
rinfo->family == CHIP_FAMILY_R350 ||
- rinfo->family == CHIP_FAMILY_RV350) {
+ rinfo->family == CHIP_FAMILY_RV350 ||
+ rinfo->family == CHIP_FAMILY_RV380 ) {
if (mode->ppll_ref_div & R300_PPLL_REF_DIV_ACC_MASK) {
/* When restoring console mode, use saved PPLL_REF_DIV
* setting.
--
1.5.1.6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] radeonfb: fix setting of PPLL_REF_DIV for RV370 5B60
IMHO this is 2.6.23 material. Please apply.
Thanks a lot.
Regards,
Andreas
--
radeonfb: fix setting of PPLL_REF_DIV for RV370 5B60.
As observed with various Radeon X300 cards console goes blank
without that fix.
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
drivers/video/aty/radeon_base.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 47ca62f..5a8af4d 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -1285,7 +1285,8 @@ static void radeon_write_pll_regs(struct radeonfb_info
*rinfo, struct radeon_reg
if (rinfo-family == CHIP_FAMILY_R300 ||
rinfo-family == CHIP_FAMILY_RS300 ||
rinfo-family == CHIP_FAMILY_R350 ||
- rinfo-family == CHIP_FAMILY_RV350) {
+ rinfo-family == CHIP_FAMILY_RV350 ||
+ rinfo-family == CHIP_FAMILY_RV380 ) {
if (mode-ppll_ref_div R300_PPLL_REF_DIV_ACC_MASK) {
/* When restoring console mode, use saved PPLL_REF_DIV
* setting.
--
1.5.1.6
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] radeonfb: fix chip definition for Radeon Xpress 200M 0x5975
I think this is 2.6.23 material. Please apply.
Thanks.
Regards,
Andreas
--
radeonfb: fix chip definition for Radeon Xpress 200M 0x5975
This fixes a problem introduced with commit
b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c
The commit added a wrong chip definition to radeonfb which causes
a blank console on my Laptop if radeonfb is loaded.
The patch
- renames PCI_CHIP_RS485_5975 to PCI_CHIP_RS482_5975
- corrects the chip family (RS480 instead of R300) for 0x5975
- ensures that PCI IDs are in ascending order in ati_ids.h
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
drivers/video/aty/ati_ids.h | 12 ++--
drivers/video/aty/radeon_base.c |3 +--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/video/aty/ati_ids.h b/drivers/video/aty/ati_ids.h
index 685a754..dca2eb8 100644
--- a/drivers/video/aty/ati_ids.h
+++ b/drivers/video/aty/ati_ids.h
@@ -192,6 +192,12 @@
#define PCI_CHIP_RS300_58350x5835
#define PCI_CHIP_RS300_58360x5836
#define PCI_CHIP_RS300_58370x5837
+#define PCI_CHIP_RS480_5955 0x5955
+#define PCI_CHIP_RV280_59600x5960
+#define PCI_CHIP_RV280_59610x5961
+#define PCI_CHIP_RV280_59620x5962
+#define PCI_CHIP_RV280_59640x5964
+#define PCI_CHIP_RS482_59750x5975
#define PCI_CHIP_RV370_5B60 0x5B60
#define PCI_CHIP_RV370_5B61 0x5B61
#define PCI_CHIP_RV370_5B62 0x5B62
@@ -200,14 +206,8 @@
#define PCI_CHIP_RV370_5B65 0x5B65
#define PCI_CHIP_RV370_5B66 0x5B66
#define PCI_CHIP_RV370_5B67 0x5B67
-#define PCI_CHIP_RV280_59600x5960
-#define PCI_CHIP_RV280_59610x5961
-#define PCI_CHIP_RV280_59620x5962
-#define PCI_CHIP_RV280_59640x5964
-#define PCI_CHIP_RS485_59750x5975
#define PCI_CHIP_RV280_5C610x5C61
#define PCI_CHIP_RV280_5C630x5C63
#define PCI_CHIP_R423_5D57 0x5D57
#define PCI_CHIP_RS350_7834 0x7834
#define PCI_CHIP_RS350_7835 0x7835
-#define PCI_CHIP_RS480_5955 0x5955
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 5a8af4d..4b747bd 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -102,6 +102,7 @@
static struct pci_device_id radeonfb_pci_table[] = {
/* Radeon Xpress 200m */
CHIP_DEF(PCI_CHIP_RS480_5955, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
+ CHIP_DEF(PCI_CHIP_RS482_5975, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* Mobility M6 */
CHIP_DEF(PCI_CHIP_RADEON_LY,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RADEON_LZ,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
@@ -153,8 +154,6 @@ static struct pci_device_id radeonfb_pci_table[] = {
/* Mobility 9200 (M9+) */
CHIP_DEF(PCI_CHIP_RV280_5C61, RV280, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RV280_5C63, RV280, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
- /*Mobility Xpress 200 */
- CHIP_DEF(PCI_CHIP_RS485_5975, R300, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* 9200 */
CHIP_DEF(PCI_CHIP_RV280_5960, RV280, CHIP_HAS_CRTC2),
CHIP_DEF(PCI_CHIP_RV280_5961, RV280, CHIP_HAS_CRTC2),
--
1.5.1.6
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] radeonfb: bug fix for 2.6.23-rc5
Commit b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c adds PCI ID 0x5975
to radeonfb. But the chip family is wrong. Instead of R300 it should
be RS480.
With 2.6.23-rc5 and radeonfb enabled my Laptop hangs and console
blanks. My ATI Radeon is the following model:
ATI Technologies Inc RS482 [Radeon Xpress 200M] [1002:5975]
Attached patch fixes the problem - no system hang and radeonfb is usable.
(I have to use force_measure_pll to get the best resolution though.)
I guess this fix should go into 2.6.23 or alternatively the mentioned
commit should be reverted.
Regards,
Andreas
--
radeonfb: fix chip definition for Radeon Xpress 200M 0x5975
- rename PCI_CHIP_RS485_5975 to PCI_CHIP_RS482_5975
- correct chip family (RS480 instead of R300)
- make sure that PCI IDs are in ascending order in ati_ids.h
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/video/aty/ati_ids.h | 12 ++--
drivers/video/aty/radeon_base.c |3 +--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/video/aty/ati_ids.h b/drivers/video/aty/ati_ids.h
index 685a754..dca2eb8 100644
--- a/drivers/video/aty/ati_ids.h
+++ b/drivers/video/aty/ati_ids.h
@@ -192,6 +192,12 @@
#define PCI_CHIP_RS300_58350x5835
#define PCI_CHIP_RS300_58360x5836
#define PCI_CHIP_RS300_58370x5837
+#define PCI_CHIP_RS480_5955 0x5955
+#define PCI_CHIP_RV280_59600x5960
+#define PCI_CHIP_RV280_59610x5961
+#define PCI_CHIP_RV280_59620x5962
+#define PCI_CHIP_RV280_59640x5964
+#define PCI_CHIP_RS482_59750x5975
#define PCI_CHIP_RV370_5B60 0x5B60
#define PCI_CHIP_RV370_5B61 0x5B61
#define PCI_CHIP_RV370_5B62 0x5B62
@@ -200,14 +206,8 @@
#define PCI_CHIP_RV370_5B65 0x5B65
#define PCI_CHIP_RV370_5B66 0x5B66
#define PCI_CHIP_RV370_5B67 0x5B67
-#define PCI_CHIP_RV280_59600x5960
-#define PCI_CHIP_RV280_59610x5961
-#define PCI_CHIP_RV280_59620x5962
-#define PCI_CHIP_RV280_59640x5964
-#define PCI_CHIP_RS485_59750x5975
#define PCI_CHIP_RV280_5C610x5C61
#define PCI_CHIP_RV280_5C630x5C63
#define PCI_CHIP_R423_5D57 0x5D57
#define PCI_CHIP_RS350_7834 0x7834
#define PCI_CHIP_RS350_7835 0x7835
-#define PCI_CHIP_RS480_5955 0x5955
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 47ca62f..e8e135f 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -102,6 +102,7 @@
static struct pci_device_id radeonfb_pci_table[] = {
/* Radeon Xpress 200m */
CHIP_DEF(PCI_CHIP_RS480_5955, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
+ CHIP_DEF(PCI_CHIP_RS482_5975, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* Mobility M6 */
CHIP_DEF(PCI_CHIP_RADEON_LY,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RADEON_LZ,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
@@ -153,8 +154,6 @@ static struct pci_device_id radeonfb_pci_table[] = {
/* Mobility 9200 (M9+) */
CHIP_DEF(PCI_CHIP_RV280_5C61, RV280, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RV280_5C63, RV280, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
- /*Mobility Xpress 200 */
- CHIP_DEF(PCI_CHIP_RS485_5975, R300, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* 9200 */
CHIP_DEF(PCI_CHIP_RV280_5960, RV280, CHIP_HAS_CRTC2),
CHIP_DEF(PCI_CHIP_RV280_5961, RV280, CHIP_HAS_CRTC2),
--
1.5.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/4] radeonfb: add PCI Id for RS482/Radeon Xpress 200M
On Tue, Sep 04, 2007 at 03:45:12PM +0200, Benjamin Herrenschmidt wrote: > On Tue, 2007-09-04 at 12:58 +0200, [EMAIL PROTECTED] wrote: > > .. which can be found in Acer Aspire 5100. > > > > Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> > > Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Sorry, I have missed that 0x5975 was already defined for radeonfb. So this patch shouldn't be applied. We have already: /*Mobility Xpress 200 */ CHIP_DEF(PCI_CHIP_RS485_5975, R300, CHIP_HAS_CRTC2 | CHIP_IS_IGP | CHIP_IS_MOBILITY), This was introduced with commit b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c But obviously this is not correct as the 0x5975 is an RS48x not R300. With the current git (w/o my patch) my display goes blank (or better it looks striped) and the Laptop hangs. I'll do some further tests on my Laptop and probably come up with a new patch. Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] radeonfb: add new module parameter to force PLL calculation
On Tue, Sep 04, 2007 at 03:46:29PM +0200, Benjamin Herrenschmidt wrote: > I don't like those tunables. First we should get a look at what values > we obtain from the BIOS. Could be something with the parsing of ATOM > BIOS. In any case, we might be able to detect we got wrong values or use > subsystem vendor/device ID to blacklist. So what should I looking for? Here is the diff of the radeonfb kernel messages between (-)nopllcalc and (+)forcing pll calculation with my patch: vSync_width: 4 clock: 7350 Setting up default mode based on panel info -hStart = 672, hEnd = 712, hTotal = 824 -vStart = 404, vEnd = 408, vTotal = 437 -h_total_disp = 0x4f0066 hsync_strt_wid = 0x5029a -v_total_disp = 0x18f01b4 vsync_strt_wid = 0x40193 +hStart = 1312, hEnd = 1352, hTotal = 1464 +vStart = 804, vEnd = 808, vTotal = 837 +h_total_disp = 0x9f00b6 hsync_strt_wid = 0x5051a +v_total_disp = 0x31f0344 vsync_strt_wid = 0x40323 pixclock = 13605 freq = 7350 -Console: switching to colour frame buffer device 80x25 +freq = 7350, PLL min = 2, PLL max = 4 +ref_div = 6, ref_clk = 1432, output_freq = 29400 +ref_div = 6, ref_clk = 1432, output_freq = 29400 +post div = 0x2 +fb_div = 0x7b +ppll_div_3 = 0x2007b +Console: switching to colour frame buffer device 160x50 radeonfb (:01:05.0): ATI Radeon 5975 "Yu" radeonfb_pci_register END "nopllcalc" results in a console 80x25 but forcing pll calculation gives the expected result. BTW, I am a little surprised that the display doesn't blank without my patch as it used to in the past ... Oops, PCI ID 0x5975 was already added with commit b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c I guess I have to repeat some testing with both the older commit and my patch(es) to sort out what is really needed to support my RS482/0x5975. Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] radeonfb: use PCI device Id in hex for name string
On Tue, Sep 04, 2007 at 03:48:07PM +0200, Benjamin Herrenschmidt wrote:
> Well... ATI used to have printable characters and those were commonly
> used to identify the cards. I'm not sure we want to unilateraly switch
> to hex here...
I see.
How about the following patch?
As an illustration this gives following output for some cards:
radeonfb (:01:05.0): ATI Radeon 5975 "Yu"
radeonfb (:02:00.0): ATI Radeon 5b60 "[`"
radeonfb (:02:00.0): ATI Radeon 5960 "Y`"
Regards,
Andreas
--
radeonfb: use PCI device id in hex for name string
Additionally provide PCI device id in character format if possible.
(The printable characters were commonly used to identify the cards.)
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/video/aty/radeon_base.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index b1bee6f..306d3c7 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -57,6 +57,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2156,6 +2157,7 @@ static int __devinit radeonfb_pci_register (struct
pci_dev *pdev,
struct fb_info *info;
struct radeonfb_info *rinfo;
int ret;
+ unsigned char c1, c2;
RTRACE("radeonfb_pci_register BEGIN\n");
@@ -2183,9 +2185,15 @@ static int __devinit radeonfb_pci_register (struct
pci_dev *pdev,
rinfo->lvds_timer.function = radeon_lvds_timer_func;
rinfo->lvds_timer.data = (unsigned long)rinfo;
- strcpy(rinfo->name, "ATI Radeon XX ");
- rinfo->name[11] = ent->device >> 8;
- rinfo->name[12] = ent->device & 0xFF;
+ c1 = ent->device >> 8;
+ c2 = ent->device & 0xff;
+ if (isprint(c1) && isprint(c2))
+ snprintf(rinfo->name, sizeof(rinfo->name),
+"ATI Radeon %x \"%c%c\"", ent->device & 0x, c1,
c2);
+ else
+ snprintf(rinfo->name, sizeof(rinfo->name),
+"ATI Radeon %x", ent->device & 0x);
+
rinfo->family = ent->driver_data & CHIP_FAMILY_MASK;
rinfo->chipset = pdev->device;
rinfo->has_CRTC2 = (ent->driver_data & CHIP_HAS_CRTC2) != 0;
--
1.5.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] radeonfb: use PCI device Id in hex for name string
On Tue, Sep 04, 2007 at 03:48:07PM +0200, Benjamin Herrenschmidt wrote: Well... ATI used to have printable characters and those were commonly used to identify the cards. I'm not sure we want to unilateraly switch to hex here... I see. How about the following patch? As an illustration this gives following output for some cards: radeonfb (:01:05.0): ATI Radeon 5975 Yu radeonfb (:02:00.0): ATI Radeon 5b60 [` radeonfb (:02:00.0): ATI Radeon 5960 Y` Regards, Andreas -- radeonfb: use PCI device id in hex for name string Additionally provide PCI device id in character format if possible. (The printable characters were commonly used to identify the cards.) Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- drivers/video/aty/radeon_base.c | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c index b1bee6f..306d3c7 100644 --- a/drivers/video/aty/radeon_base.c +++ b/drivers/video/aty/radeon_base.c @@ -57,6 +57,7 @@ #include linux/kernel.h #include linux/errno.h #include linux/string.h +#include linux/ctype.h #include linux/mm.h #include linux/slab.h #include linux/delay.h @@ -2156,6 +2157,7 @@ static int __devinit radeonfb_pci_register (struct pci_dev *pdev, struct fb_info *info; struct radeonfb_info *rinfo; int ret; + unsigned char c1, c2; RTRACE(radeonfb_pci_register BEGIN\n); @@ -2183,9 +2185,15 @@ static int __devinit radeonfb_pci_register (struct pci_dev *pdev, rinfo-lvds_timer.function = radeon_lvds_timer_func; rinfo-lvds_timer.data = (unsigned long)rinfo; - strcpy(rinfo-name, ATI Radeon XX ); - rinfo-name[11] = ent-device 8; - rinfo-name[12] = ent-device 0xFF; + c1 = ent-device 8; + c2 = ent-device 0xff; + if (isprint(c1) isprint(c2)) + snprintf(rinfo-name, sizeof(rinfo-name), +ATI Radeon %x \%c%c\, ent-device 0x, c1, c2); + else + snprintf(rinfo-name, sizeof(rinfo-name), +ATI Radeon %x, ent-device 0x); + rinfo-family = ent-driver_data CHIP_FAMILY_MASK; rinfo-chipset = pdev-device; rinfo-has_CRTC2 = (ent-driver_data CHIP_HAS_CRTC2) != 0; -- 1.5.3 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] radeonfb: add new module parameter to force PLL calculation
On Tue, Sep 04, 2007 at 03:46:29PM +0200, Benjamin Herrenschmidt wrote: I don't like those tunables. First we should get a look at what values we obtain from the BIOS. Could be something with the parsing of ATOM BIOS. In any case, we might be able to detect we got wrong values or use subsystem vendor/device ID to blacklist. So what should I looking for? Here is the diff of the radeonfb kernel messages between (-)nopllcalc and (+)forcing pll calculation with my patch: vSync_width: 4 clock: 7350 Setting up default mode based on panel info -hStart = 672, hEnd = 712, hTotal = 824 -vStart = 404, vEnd = 408, vTotal = 437 -h_total_disp = 0x4f0066 hsync_strt_wid = 0x5029a -v_total_disp = 0x18f01b4 vsync_strt_wid = 0x40193 +hStart = 1312, hEnd = 1352, hTotal = 1464 +vStart = 804, vEnd = 808, vTotal = 837 +h_total_disp = 0x9f00b6 hsync_strt_wid = 0x5051a +v_total_disp = 0x31f0344 vsync_strt_wid = 0x40323 pixclock = 13605 freq = 7350 -Console: switching to colour frame buffer device 80x25 +freq = 7350, PLL min = 2, PLL max = 4 +ref_div = 6, ref_clk = 1432, output_freq = 29400 +ref_div = 6, ref_clk = 1432, output_freq = 29400 +post div = 0x2 +fb_div = 0x7b +ppll_div_3 = 0x2007b +Console: switching to colour frame buffer device 160x50 radeonfb (:01:05.0): ATI Radeon 5975 Yu radeonfb_pci_register END nopllcalc results in a console 80x25 but forcing pll calculation gives the expected result. BTW, I am a little surprised that the display doesn't blank without my patch as it used to in the past ... Oops, PCI ID 0x5975 was already added with commit b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c I guess I have to repeat some testing with both the older commit and my patch(es) to sort out what is really needed to support my RS482/0x5975. Regards, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 1/4] radeonfb: add PCI Id for RS482/Radeon Xpress 200M
On Tue, Sep 04, 2007 at 03:45:12PM +0200, Benjamin Herrenschmidt wrote: On Tue, 2007-09-04 at 12:58 +0200, [EMAIL PROTECTED] wrote: .. which can be found in Acer Aspire 5100. Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] Sorry, I have missed that 0x5975 was already defined for radeonfb. So this patch shouldn't be applied. We have already: /*Mobility Xpress 200 */ CHIP_DEF(PCI_CHIP_RS485_5975, R300, CHIP_HAS_CRTC2 | CHIP_IS_IGP | CHIP_IS_MOBILITY), This was introduced with commit b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c But obviously this is not correct as the 0x5975 is an RS48x not R300. With the current git (w/o my patch) my display goes blank (or better it looks striped) and the Laptop hangs. I'll do some further tests on my Laptop and probably come up with a new patch. Regards, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] radeonfb: bug fix for 2.6.23-rc5
Commit b5f2f4d1a6d7efde39cfb5e1d034981c69f2214c adds PCI ID 0x5975
to radeonfb. But the chip family is wrong. Instead of R300 it should
be RS480.
With 2.6.23-rc5 and radeonfb enabled my Laptop hangs and console
blanks. My ATI Radeon is the following model:
ATI Technologies Inc RS482 [Radeon Xpress 200M] [1002:5975]
Attached patch fixes the problem - no system hang and radeonfb is usable.
(I have to use force_measure_pll to get the best resolution though.)
I guess this fix should go into 2.6.23 or alternatively the mentioned
commit should be reverted.
Regards,
Andreas
--
radeonfb: fix chip definition for Radeon Xpress 200M 0x5975
- rename PCI_CHIP_RS485_5975 to PCI_CHIP_RS482_5975
- correct chip family (RS480 instead of R300)
- make sure that PCI IDs are in ascending order in ati_ids.h
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
drivers/video/aty/ati_ids.h | 12 ++--
drivers/video/aty/radeon_base.c |3 +--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/video/aty/ati_ids.h b/drivers/video/aty/ati_ids.h
index 685a754..dca2eb8 100644
--- a/drivers/video/aty/ati_ids.h
+++ b/drivers/video/aty/ati_ids.h
@@ -192,6 +192,12 @@
#define PCI_CHIP_RS300_58350x5835
#define PCI_CHIP_RS300_58360x5836
#define PCI_CHIP_RS300_58370x5837
+#define PCI_CHIP_RS480_5955 0x5955
+#define PCI_CHIP_RV280_59600x5960
+#define PCI_CHIP_RV280_59610x5961
+#define PCI_CHIP_RV280_59620x5962
+#define PCI_CHIP_RV280_59640x5964
+#define PCI_CHIP_RS482_59750x5975
#define PCI_CHIP_RV370_5B60 0x5B60
#define PCI_CHIP_RV370_5B61 0x5B61
#define PCI_CHIP_RV370_5B62 0x5B62
@@ -200,14 +206,8 @@
#define PCI_CHIP_RV370_5B65 0x5B65
#define PCI_CHIP_RV370_5B66 0x5B66
#define PCI_CHIP_RV370_5B67 0x5B67
-#define PCI_CHIP_RV280_59600x5960
-#define PCI_CHIP_RV280_59610x5961
-#define PCI_CHIP_RV280_59620x5962
-#define PCI_CHIP_RV280_59640x5964
-#define PCI_CHIP_RS485_59750x5975
#define PCI_CHIP_RV280_5C610x5C61
#define PCI_CHIP_RV280_5C630x5C63
#define PCI_CHIP_R423_5D57 0x5D57
#define PCI_CHIP_RS350_7834 0x7834
#define PCI_CHIP_RS350_7835 0x7835
-#define PCI_CHIP_RS480_5955 0x5955
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 47ca62f..e8e135f 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -102,6 +102,7 @@
static struct pci_device_id radeonfb_pci_table[] = {
/* Radeon Xpress 200m */
CHIP_DEF(PCI_CHIP_RS480_5955, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
+ CHIP_DEF(PCI_CHIP_RS482_5975, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* Mobility M6 */
CHIP_DEF(PCI_CHIP_RADEON_LY,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RADEON_LZ,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
@@ -153,8 +154,6 @@ static struct pci_device_id radeonfb_pci_table[] = {
/* Mobility 9200 (M9+) */
CHIP_DEF(PCI_CHIP_RV280_5C61, RV280, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RV280_5C63, RV280, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
- /*Mobility Xpress 200 */
- CHIP_DEF(PCI_CHIP_RS485_5975, R300, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* 9200 */
CHIP_DEF(PCI_CHIP_RV280_5960, RV280, CHIP_HAS_CRTC2),
CHIP_DEF(PCI_CHIP_RV280_5961, RV280, CHIP_HAS_CRTC2),
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] radeonfb: use PCI device Id in hex for name string
.. instead of potentially using nonprintable characters. I guess the former (odd) concatenation was used to construct name strings that match the "*_ATI_RADEON_??" macros in include/linux/pci_ids.h The PCI Id in hex is much more convenient to use. E.g. it can easily be verified against "lspci -nn" output. Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]> --- drivers/video/aty/radeon_base.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c index 71b0c17..e6229b4 100644 --- a/drivers/video/aty/radeon_base.c +++ b/drivers/video/aty/radeon_base.c @@ -2184,9 +2184,8 @@ static int __devinit radeonfb_pci_register (struct pci_dev *pdev, rinfo->lvds_timer.function = radeon_lvds_timer_func; rinfo->lvds_timer.data = (unsigned long)rinfo; - strcpy(rinfo->name, "ATI Radeon XX "); - rinfo->name[11] = ent->device >> 8; - rinfo->name[12] = ent->device & 0xFF; + snprintf(rinfo->name, sizeof(rinfo->name), +"ATI Radeon %x", ent->device & 0x); rinfo->family = ent->driver_data & CHIP_FAMILY_MASK; rinfo->chipset = pdev->device; rinfo->has_CRTC2 = (ent->driver_data & CHIP_HAS_CRTC2) != 0; -- 1.5.3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] radeonfb: add new module parameter to force PLL calculation
On my Acer Aspire 5100 (with 0x5975) I need to force PLL caclulation.
Most probably the BIOS dividers are incorrect/insufficient. Without pll
calculation console goes blank.
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/video/aty/radeon_base.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 90a3957..f672c0c 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -268,6 +268,7 @@ static int mirror = 0;
static int panel_yres = 0;
static int force_dfp = 0;
static int force_measure_pll = 0;
+static int force_pll_calc = 0;
#ifdef CONFIG_MTRR
static int nomtrr = 0;
#endif
@@ -1590,7 +1591,7 @@ static int radeonfb_set_par(struct fb_info *info)
pixClock = 1 / rinfo->panel_info.clock;
- if (rinfo->panel_info.use_bios_dividers) {
+ if (rinfo->panel_info.use_bios_dividers && !force_pll_calc) {
nopllcalc = 1;
newmode->ppll_div_3 = rinfo->panel_info.fbk_divider |
(rinfo->panel_info.post_divider << 16);
@@ -2495,6 +2496,8 @@ static int __init radeonfb_setup (char *options)
nomodeset = 1;
} else if (!strncmp(this_opt, "force_measure_pll", 17)) {
force_measure_pll = 1;
+ } else if (!strncmp(this_opt, "force_pll_calc", 17)) {
+ force_pll_calc = 1;
} else if (!strncmp(this_opt, "ignore_edid", 11)) {
ignore_edid = 1;
#if defined(CONFIG_PM) && defined(CONFIG_X86)
@@ -2550,6 +2553,8 @@ module_param(monitor_layout, charp, 0);
MODULE_PARM_DESC(monitor_layout, "Specify monitor mapping (like XFree86)");
module_param(force_measure_pll, bool, 0);
MODULE_PARM_DESC(force_measure_pll, "Force measurement of PLL (debug)");
+module_param(force_pll_calc, bool, 0400);
+MODULE_PARM_DESC(force_pll_calc, "Force calculation of PLL");
#ifdef CONFIG_MTRR
module_param(nomtrr, bool, 0);
MODULE_PARM_DESC(nomtrr, "bool: disable use of MTRR registers");
--
1.5.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] radeonfb: fix setting of PPLL_REF_DIV for RV370 5B60
As observed with various Radeon X300: console goes blank
without fixing setting of PPLL_REF_DIV.
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/video/aty/radeon_base.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index f672c0c..71b0c17 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -1287,7 +1287,8 @@ static void radeon_write_pll_regs(struct radeonfb_info
*rinfo, struct radeon_reg
if (rinfo->family == CHIP_FAMILY_R300 ||
rinfo->family == CHIP_FAMILY_RS300 ||
rinfo->family == CHIP_FAMILY_R350 ||
- rinfo->family == CHIP_FAMILY_RV350) {
+ rinfo->family == CHIP_FAMILY_RV350 ||
+ rinfo->family == CHIP_FAMILY_RV380 ) {
if (mode->ppll_ref_div & R300_PPLL_REF_DIV_ACC_MASK) {
/* When restoring console mode, use saved PPLL_REF_DIV
* setting.
--
1.5.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] radeonfb: add PCI Id for RS482/Radeon Xpress 200M
.. which can be found in Acer Aspire 5100.
Signed-off-by: Andreas Herrmann <[EMAIL PROTECTED]>
---
drivers/video/aty/ati_ids.h |1 +
drivers/video/aty/radeon_base.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/aty/ati_ids.h b/drivers/video/aty/ati_ids.h
index 685a754..648da1e 100644
--- a/drivers/video/aty/ati_ids.h
+++ b/drivers/video/aty/ati_ids.h
@@ -211,3 +211,4 @@
#define PCI_CHIP_RS350_7834 0x7834
#define PCI_CHIP_RS350_7835 0x7835
#define PCI_CHIP_RS480_5955 0x5955
+#define PCI_CHIP_RS482_5975 0x5975
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 47ca62f..90a3957 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -102,6 +102,7 @@
static struct pci_device_id radeonfb_pci_table[] = {
/* Radeon Xpress 200m */
CHIP_DEF(PCI_CHIP_RS480_5955, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
+ CHIP_DEF(PCI_CHIP_RS482_5975, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* Mobility M6 */
CHIP_DEF(PCI_CHIP_RADEON_LY,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RADEON_LZ,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
--
1.5.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] radeonfb: minor fixes
Hi, Following some minor changes for radeonfb. Main purpose is to get it working on my own Radeon cards. Patches are against current git. Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] radeonfb: minor fixes
Hi, Following some minor changes for radeonfb. Main purpose is to get it working on my own Radeon cards. Patches are against current git. Regards, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] radeonfb: add PCI Id for RS482/Radeon Xpress 200M
.. which can be found in Acer Aspire 5100.
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
drivers/video/aty/ati_ids.h |1 +
drivers/video/aty/radeon_base.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/aty/ati_ids.h b/drivers/video/aty/ati_ids.h
index 685a754..648da1e 100644
--- a/drivers/video/aty/ati_ids.h
+++ b/drivers/video/aty/ati_ids.h
@@ -211,3 +211,4 @@
#define PCI_CHIP_RS350_7834 0x7834
#define PCI_CHIP_RS350_7835 0x7835
#define PCI_CHIP_RS480_5955 0x5955
+#define PCI_CHIP_RS482_5975 0x5975
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 47ca62f..90a3957 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -102,6 +102,7 @@
static struct pci_device_id radeonfb_pci_table[] = {
/* Radeon Xpress 200m */
CHIP_DEF(PCI_CHIP_RS480_5955, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
+ CHIP_DEF(PCI_CHIP_RS482_5975, RS480, CHIP_HAS_CRTC2 | CHIP_IS_IGP |
CHIP_IS_MOBILITY),
/* Mobility M6 */
CHIP_DEF(PCI_CHIP_RADEON_LY,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RADEON_LZ,RV100, CHIP_HAS_CRTC2 |
CHIP_IS_MOBILITY),
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] radeonfb: add new module parameter to force PLL calculation
On my Acer Aspire 5100 (with 0x5975) I need to force PLL caclulation.
Most probably the BIOS dividers are incorrect/insufficient. Without pll
calculation console goes blank.
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
drivers/video/aty/radeon_base.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 90a3957..f672c0c 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -268,6 +268,7 @@ static int mirror = 0;
static int panel_yres = 0;
static int force_dfp = 0;
static int force_measure_pll = 0;
+static int force_pll_calc = 0;
#ifdef CONFIG_MTRR
static int nomtrr = 0;
#endif
@@ -1590,7 +1591,7 @@ static int radeonfb_set_par(struct fb_info *info)
pixClock = 1 / rinfo-panel_info.clock;
- if (rinfo-panel_info.use_bios_dividers) {
+ if (rinfo-panel_info.use_bios_dividers !force_pll_calc) {
nopllcalc = 1;
newmode-ppll_div_3 = rinfo-panel_info.fbk_divider |
(rinfo-panel_info.post_divider 16);
@@ -2495,6 +2496,8 @@ static int __init radeonfb_setup (char *options)
nomodeset = 1;
} else if (!strncmp(this_opt, force_measure_pll, 17)) {
force_measure_pll = 1;
+ } else if (!strncmp(this_opt, force_pll_calc, 17)) {
+ force_pll_calc = 1;
} else if (!strncmp(this_opt, ignore_edid, 11)) {
ignore_edid = 1;
#if defined(CONFIG_PM) defined(CONFIG_X86)
@@ -2550,6 +2553,8 @@ module_param(monitor_layout, charp, 0);
MODULE_PARM_DESC(monitor_layout, Specify monitor mapping (like XFree86));
module_param(force_measure_pll, bool, 0);
MODULE_PARM_DESC(force_measure_pll, Force measurement of PLL (debug));
+module_param(force_pll_calc, bool, 0400);
+MODULE_PARM_DESC(force_pll_calc, Force calculation of PLL);
#ifdef CONFIG_MTRR
module_param(nomtrr, bool, 0);
MODULE_PARM_DESC(nomtrr, bool: disable use of MTRR registers);
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] radeonfb: fix setting of PPLL_REF_DIV for RV370 5B60
As observed with various Radeon X300: console goes blank
without fixing setting of PPLL_REF_DIV.
Signed-off-by: Andreas Herrmann [EMAIL PROTECTED]
---
drivers/video/aty/radeon_base.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index f672c0c..71b0c17 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -1287,7 +1287,8 @@ static void radeon_write_pll_regs(struct radeonfb_info
*rinfo, struct radeon_reg
if (rinfo-family == CHIP_FAMILY_R300 ||
rinfo-family == CHIP_FAMILY_RS300 ||
rinfo-family == CHIP_FAMILY_R350 ||
- rinfo-family == CHIP_FAMILY_RV350) {
+ rinfo-family == CHIP_FAMILY_RV350 ||
+ rinfo-family == CHIP_FAMILY_RV380 ) {
if (mode-ppll_ref_div R300_PPLL_REF_DIV_ACC_MASK) {
/* When restoring console mode, use saved PPLL_REF_DIV
* setting.
--
1.5.3
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] radeonfb: use PCI device Id in hex for name string
.. instead of potentially using nonprintable characters. I guess the former (odd) concatenation was used to construct name strings that match the *_ATI_RADEON_?? macros in include/linux/pci_ids.h The PCI Id in hex is much more convenient to use. E.g. it can easily be verified against lspci -nn output. Signed-off-by: Andreas Herrmann [EMAIL PROTECTED] --- drivers/video/aty/radeon_base.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c index 71b0c17..e6229b4 100644 --- a/drivers/video/aty/radeon_base.c +++ b/drivers/video/aty/radeon_base.c @@ -2184,9 +2184,8 @@ static int __devinit radeonfb_pci_register (struct pci_dev *pdev, rinfo-lvds_timer.function = radeon_lvds_timer_func; rinfo-lvds_timer.data = (unsigned long)rinfo; - strcpy(rinfo-name, ATI Radeon XX ); - rinfo-name[11] = ent-device 8; - rinfo-name[12] = ent-device 0xFF; + snprintf(rinfo-name, sizeof(rinfo-name), +ATI Radeon %x, ent-device 0x); rinfo-family = ent-driver_data CHIP_FAMILY_MASK; rinfo-chipset = pdev-device; rinfo-has_CRTC2 = (ent-driver_data CHIP_HAS_CRTC2) != 0; -- 1.5.3 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] x86: limit mwait_idle to Intel CPUs
Peter Anvin wrote: > Andreas Herrmann wrote: > > > > It is not equivalent. Usually users check /proc/cpuinfo for their > > CPU features. Deleting that flag is kind of obfuscation. > > > > I guess some time ago people did not care about their "svm" or "vmx" > > flags. Nowadays (e.g. with kvm) some people are quite happy > > if one of those strings occurs in /proc/cpuinfo (and they are quite > > disappointed if this feature was disabled by BIOS). > > > What you're saying is that you want it to appear in /proc/cpuinfo for > marketing reasons even though it's not usable. Brueer! So you are saying I am a marketing guy -- wasn't aware of that. Just big fun. > The ones in /proc/cpuinfo are cooked values anyway; there is plenty of > history to that effect. I don't know this history. And I don't care. I thought /proc/cpuinfo should show an (almost) complete list of CPU features. If this is not the case it's a pity. > I would agree with Andi that if as far as Linux is concerned mwait is > unusable on AMD Fam10 processors, then the CPU detection code should > turn this bit off on AMD Fam10 processors. And finally I was not aware that you and Andi think of monitor/mwait as a synonym for Intel's native C-States. So I guess, what you really want is that for AMD CPUs the monitor-flag (aka native C-state-flag) gets removed. And if somedays another use case for monitor/mwait appears, the flag has to be reintroduced for AMD CPUs. Fine with me. The only drawback is that Andi's idea of idle=mwait wouldn't make sense anymore. Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] x86: limit mwait_idle to Intel CPUs
Peter Anvin wrote: Andreas Herrmann wrote: It is not equivalent. Usually users check /proc/cpuinfo for their CPU features. Deleting that flag is kind of obfuscation. I guess some time ago people did not care about their svm or vmx flags. Nowadays (e.g. with kvm) some people are quite happy if one of those strings occurs in /proc/cpuinfo (and they are quite disappointed if this feature was disabled by BIOS). What you're saying is that you want it to appear in /proc/cpuinfo for marketing reasons even though it's not usable. Brueer! So you are saying I am a marketing guy -- wasn't aware of that. Just big fun. The ones in /proc/cpuinfo are cooked values anyway; there is plenty of history to that effect. I don't know this history. And I don't care. I thought /proc/cpuinfo should show an (almost) complete list of CPU features. If this is not the case it's a pity. I would agree with Andi that if as far as Linux is concerned mwait is unusable on AMD Fam10 processors, then the CPU detection code should turn this bit off on AMD Fam10 processors. And finally I was not aware that you and Andi think of monitor/mwait as a synonym for Intel's native C-States. So I guess, what you really want is that for AMD CPUs the monitor-flag (aka native C-state-flag) gets removed. And if somedays another use case for monitor/mwait appears, the flag has to be reintroduced for AMD CPUs. Fine with me. The only drawback is that Andi's idea of idle=mwait wouldn't make sense anymore. Regards, Andreas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
