The reason of removal, "replaced by allowdac and no dac combination"
is incorrect. There is no way to do the same thing with "allowdac" and
"nodac" combination.
The usedac option enables us to stop via_no_dac() setting forbid_dac
to 1. That is, someone who uses VIA bridges can use DAC with this
option even if some of VIA bridges seem to be broken about DAC.
Signed-off-by: FUJITA Tomonori <[email protected]>
---
Documentation/feature-removal-schedule.txt | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 2a4d779..eb2c138 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -291,13 +291,6 @@ Who: Michael Buesch <[email protected]>
---------------------------
-What: usedac i386 kernel parameter
-When: 2.6.27
-Why: replaced by allowdac and no dac combination
-Who: Glauber Costa <[email protected]>
-
----------------------------
-
What: print_fn_descriptor_symbol()
When: October 2009
Why: The %pF vsprintf format provides the same functionality in a
--
1.5.6.5
FUJITA Tomonori wrote:
> The reason of removal, "replaced by allowdac and no dac combination"
> is incorrect. There is no way to do the same thing with "allowdac" and
> "nodac" combination.
>
> The usedac option enables us to stop via_no_dac() setting forbid_dac
> to 1. That is, someone who uses VIA bridges can use DAC with this
> option even if some of VIA bridges seem to be broken about DAC.
>
> Signed-off-by: FUJITA Tomonori <[email protected]>
Hi,
This sounds reasonable for me.
Acked-by: WANG Cong <[email protected]>
> ---
> Documentation/feature-removal-schedule.txt | 7 -------
> 1 files changed, 0 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> index 2a4d779..eb2c138 100644
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
> @@ -291,13 +291,6 @@ Who: Michael Buesch <[email protected]>
>
> ---------------------------
>
> -What: usedac i386 kernel parameter
> -When: 2.6.27
> -Why: replaced by allowdac and no dac combination
> -Who: Glauber Costa <[email protected]>
> -
> ----------------------------
> -
> What: print_fn_descriptor_symbol()
> When: October 2009
> Why: The %pF vsprintf format provides the same functionality in a
Commit-ID: 06f8bda8324fa8bf39eed81d8b3df08063a37696
Gitweb: http://git.kernel.org/tip/06f8bda8324fa8bf39eed81d8b3df08063a37696
Author: FUJITA Tomonori <[email protected]>
AuthorDate: Mon, 14 Dec 2009 11:06:15 +0900
Committer: Ingo Molnar <[email protected]>
CommitDate: Mon, 14 Dec 2009 08:53:54 +0100
x86: Remove usedac in feature-removal-schedule.txt
The reason of removal, "replaced by allowdac and no dac
combination" is incorrect. There is no way to do the same thing
with "allowdac" and "nodac" combination.
The usedac option enables us to stop via_no_dac() setting
forbid_dac to 1. That is, someone who uses VIA bridges can use
DAC with this option even if some of VIA bridges seem to be
broken about DAC.
Signed-off-by: FUJITA Tomonori <[email protected]>
Acked-by: WANG Cong <[email protected]>
Cc: [email protected]
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
Documentation/feature-removal-schedule.txt | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 2a4d779..eb2c138 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -291,13 +291,6 @@ Who: Michael Buesch <[email protected]>
---------------------------
-What: usedac i386 kernel parameter
-When: 2.6.27
-Why: replaced by allowdac and no dac combination
-Who: Glauber Costa <[email protected]>
-
----------------------------
-
What: print_fn_descriptor_symbol()
When: October 2009
Why: The %pF vsprintf format provides the same functionality in a
On Mon, 14 Dec 2009 07:58:01 GMT, tip-bot for FUJITA Tomonori said:
> Commit-ID: 06f8bda8324fa8bf39eed81d8b3df08063a37696
> x86: Remove usedac in feature-removal-schedule.txt
> The usedac option enables us to stop via_no_dac() setting
> forbid_dac to 1. That is, someone who uses VIA bridges can use
> DAC with this option even if some of VIA bridges seem to be
> broken about DAC.
Does there exist real hardware where this makes sense? If the chipset
detects as "broken-DAC", is it in fact safe to use? Or is it similar to
the 'force-enable HPET' code for some older boxes, where the HPET was in
fact there but simply not advertised, so going ahead and using it was
in fact perfectly safe? Allowing the use of "working but not advertised"
is probably a good thing, allowing the use of known-broken probably isn't.
If it's just unadvertised, I wonder if if there's a way to write a quirk
for VIA systems that will detect the situation and enable the support?
On Mon, 14 Dec 2009 09:57:55 -0500
[email protected] wrote:
> On Mon, 14 Dec 2009 07:58:01 GMT, tip-bot for FUJITA Tomonori said:
> > Commit-ID: 06f8bda8324fa8bf39eed81d8b3df08063a37696
>
> > x86: Remove usedac in feature-removal-schedule.txt
>
> > The usedac option enables us to stop via_no_dac() setting
> > forbid_dac to 1. That is, someone who uses VIA bridges can use
> > DAC with this option even if some of VIA bridges seem to be
> > broken about DAC.
>
> Does there exist real hardware where this makes sense? If the chipset
> detects as "broken-DAC", is it in fact safe to use?
Not safe. Probably, you would see data corruption.
arch/x86/kernel/pci-dma.c says:
/* Many VIA bridges seem to corrupt data for DAC. Disable it here */
Seems that some of VIA bridges were fine. So this option made sense
with some hardware. I'm not sure if there are still users of this
option now.
> Or is it similar to
> the 'force-enable HPET' code for some older boxes, where the HPET was in
> fact there but simply not advertised, so going ahead and using it was
> in fact perfectly safe? Allowing the use of "working but not advertised"
> is probably a good thing, allowing the use of known-broken probably isn't.
>
> If it's just unadvertised, I wonder if if there's a way to write a quirk
> for VIA systems that will detect the situation and enable the support?
I guess that we could however it doesn't worth adding tricks for old
hardware.