Hello *,
i have a small patch for a Problem that i had.
On the MSI-K8T-NEO2 FIR ( Athlon-64, Socket 939 with VIA-K8T800- Chipset
and onboard Sound,... ) the BIOS lets you choose "DISABLED" or "AUTO"
for the On-Board Sound Device.
If you add another PCI-Sound-Card the BIOS disables the on-board device.
So far I have a Quirk, that does set the correspondent BIT in the PCI-registers
to enable the soundcard.
But i have another 2 problems:
- how to enshure that the code is executed ONLY on excactly this kind of boards
(not any other with similar Chipset)?
- what to do to (hopefully) integrate that pice of code into
one of the next Kernel Releases?
Johannes Goecke
On Sat, 2006-03-11 at 20:28 +0100, Johannes Goecke wrote:
> - how to enshure that the code is executed ONLY on excactly this kind
> of boards
> (not any other with similar Chipset)?
>
> - what to do to (hopefully) integrate that pice of code into
> one of the next Kernel Releases?
>
This has been discussed on LKML recently, it's not 2.6.16 material
because it might break working setups when the previously disabled
device becomes the default sound card. Of course the same setup would
have broken if we added a driver for a previously unsupported soundcard,
so I'm not sure how this fits in with the "don't break userspace" rule.
IMHO it should be merged post 2.6.16.
Lee
On Sat, Mar 11, 2006 at 10:41:29PM -0500, Lee Revell wrote:
> On Sat, 2006-03-11 at 20:28 +0100, Johannes Goecke wrote:
> > - how to enshure that the code is executed ONLY on excactly this kind
> > of boards
> > (not any other with similar Chipset)?
> >
> > - what to do to (hopefully) integrate that pice of code into
> > one of the next Kernel Releases?
> >
>
> This has been discussed on LKML recently, it's not 2.6.16 material
> because it might break working setups when the previously disabled
> device becomes the default sound card. Of course the same setup would
> have broken if we added a driver for a previously unsupported soundcard,
> so I'm not sure how this fits in with the "don't break userspace" rule.
would it be useful to add a compile-time-option and additionally
a kernel-command-line option for some bogus-code like
if ( commandline-enable || compiletime-enable )
{
/* Enable all Soundcards- Found */
}
?
- no default behaviour is changed
- general purpose Kernels can have Quirks integrated if needed
>
> IMHO it should be merged post 2.6.16.
>
> Lee
>
Johannes Goecke
PS:
can someone give me a (kernel-programming-beginner-level) hint, for the first
question how to ensure to only execute if running on the right Mother-board?
Af far as I believe the quirk so-far only checks the cipset, so it might
behave wrong on other Mainborads!
On Mon, 2006-03-13 08:57:42 +0100, Johannes Goecke <[email protected]> wrote:
> On Sat, Mar 11, 2006 at 10:41:29PM -0500, Lee Revell wrote:
> > On Sat, 2006-03-11 at 20:28 +0100, Johannes Goecke wrote:
> > This has been discussed on LKML recently, it's not 2.6.16 material
> > because it might break working setups when the previously disabled
> > device becomes the default sound card. Of course the same setup would
> > have broken if we added a driver for a previously unsupported soundcard,
> > so I'm not sure how this fits in with the "don't break userspace" rule.
>
> would it be useful to add a compile-time-option and additionally
> a kernel-command-line option for some bogus-code like
>
> if ( commandline-enable || compiletime-enable )
> {
> /* Enable all Soundcards- Found */
> }
Well, the whole collection of Quirks isn't based on a device-type
model, but purely on IDs. So either there's a workaround for some
oddity, or there isn't.
Though it may make sense to re-submit if right after 2.6.16 is out.
> can someone give me a (kernel-programming-beginner-level) hint, for the first
> question how to ensure to only execute if running on the right Mother-board?
> Af far as I believe the quirk so-far only checks the cipset, so it might
> behave wrong on other Mainborads!
That depends on wether the soundchip is inside the chipset. If it is,
you can just ignore that and run the quirk if the proper device was
found (as you do it right now.) If you really need to verify the
mainboard (as per name/vendor), have a look at
./arch/i386/kernel/{reboot,apm}.c . They both are DMI users.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Johannes Goecke <[email protected]> wrote:
> PS:
> can someone give me a (kernel-programming-beginner-level) hint, for the first
> question how to ensure to only execute if running on the right Mother-board?
> Af far as I believe the quirk so-far only checks the cipset, so it might
> behave wrong on other Mainborads!
Can you check a string in the BIOS?
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
On Mon, 2006-03-13 at 08:57 +0100, Johannes Goecke wrote:
> can someone give me a (kernel-programming-beginner-level) hint, for
> the first
> question how to ensure to only execute if running on the right
> Mother-board?
> Af far as I believe the quirk so-far only checks the cipset, so it
> might
> behave wrong on other Mainborads!
I believe a proper fix was already posted for this, the thread was
called:
[PATCH 001/001] PCI: PCI quirk for Asus A8V and A8V Deluxe motherboards
Simply add your board to the IDs.
Lee