Hello.
Thanks.
Takashi, do you think this fixes the

pcspkr/snd-pcsp conflict sufficienly

well? I think the Kconfig protection

is no longer needed. For the better

convinience the modprobe rule can be

created that will remove one driver

before inserting another. But this is

optional.

What do you think? Can we now remove
--

No, don't rely on the driver core warning and catching code errors like

this, that's not a good idea at all.  I like the warning and your patch,

but don't assume it's always going to be there.
thanks,
greg k-h

--

At Mon, 28 Apr 2008 21:58:49 -0700,
But multiple drivers for the same device are allowed on other buses

like PCI.  I think this is no reason to prohibit the multiple platform

drivers for the same platform device.
Though, I think the snd-pcsp driver could be better built on the top

of input pcspkr driver, or coexist with it.  Then we'll have no more

conflict about platform name space.
When you compare input pcspkr.c and sound pcsp_input.c, you can find

that most of codes are identical.  What we'd need is a hook on

pcspkr.c that adds a dynamic check whether snd-pcsp (or any ohter)

is running.
thanks,
Takashi

--

Hello.
I was trying this in the past.

This never worked out very well.

I disliked the dependancies.

Either snd-pcsp was loading pcspkr,

or there had to be the global variable

to prevent the concurrent access, and

Yep, its a copy/paste mainly.

I wanted a complete replacement.

Back then, I've been told that multiple

drivers controlling the same device is

never a good idea. But I won't be surprised

How?

And also, with snd-pcsp you have a

mixer control to disable the beeps,

which I find sometimes even more

usefull than the pcm sound itself. :)

--

At Tue, 29 Apr 2008 23:28:42 +0400,
But you anyway enable the input pcspkr feature in your snd-pcsp code.
What you need is a way to check whether input pcspkr can be usable or
Yes, that seems useful.
Takashi

--

Hello.
Mainly because I was not able to

come up with the good hooks for the

pcspkr driver, and those I tried,

were not applied.

There was a lengthy thread about that.

Now I can't find its beginning and its

end, but some is here:

http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/3096.html

I also think you were CCed, but maybe

If they are separate, then "rmmod pcspkr"

should disable the beeps. I don't want

to fuzzy that logic up to something like

- Check if snd-pcsp is loaded

- Use alsamixer to disable beeps, if

it is.

- Use rmmod pcspkr if it is not.

I think there should be always a single

way for the user to disable the beeps.

Could you please clarify?

- Should snd-pcsp then forcibly select

pcspkr.c to compile?

- What exactly function pointer, and

Yes, but problematic when they are separate.

I was trying to add an input event to shut

up pcspkr.c, but that was rejected. Everything

else will introduce the dependancy. The

dependancy will block rmmod, obfuscating the

logic of disabling the beeps.

Just for the record, what problems do you

see with the current solution, where only

one driver drives the device? That looks

rather logical to me. And I also can remember

the complains about pcspkr driver being in

an input drivers section. Some people had

problems finding it there and were asking

to move it to sound menu.

--

At Wed, 30 Apr 2008 21:45:59 +0400,
But, they are *not* seperate right now.  snd-pcsp contains pcspkr
And this won't work in most cases.  People don't want to replace the

existing pcspkr driver with snd-pcsp.  They don't want to load the
If you compare pcspkr.c and pcsp_input.c, it's found that the only

essential difference is the additional check at the head of the event

handler:
	if (atomic_read(&pcsp_chip.timer_active) || !pcsp_chip.pcspkr)

		return 0;
If this can be added dynamically to input pcspkr.c, no big point to
Distros usually make input-pcspkr as built-in, not as module.

So, snd-pcsp is practically unusable on standard kernels of major

distros as is, unfortunately...
Takashi

--

Hello.
Why should they? They may just stick with

Another point is PM callbacks. Somehow

snd-pcsp will have to register them with

Oh, that's really bad, I didn't know

they do. For what reason? And how then

people disable the beeps?

Btw, could you please name a few? At

least Fedora has it as a module.
OK, I'll see about using pcspkr.c. But

it looks like the needed hooks won't be

too small (call to disable the beeps and

a call to register the PM callbacks) and

unlikely to be accepted upstream...

--

At Fri, 02 May 2008 19:38:03 +0400,
... if it's not built-in.  And you'd need extra to manage selectively
Hmm, isn't platform PM hook enough?

pcspkr.c just sends an event at suspend or shutdown to the event

handler.  So, if the event was shut up at the beginning in the
Well, then I remember wrongly or an old information...
Takashi

--

Hello.
I don't think I understand what you mean...

Currently, pcspkr.c just stops the timer

counter to shut up the beep.

snd-pcsp needs more. snd_pcm_suspend_all()

for instance. Since it doesn't register

itself as a platform driver any more, he

have to register itself into pcspkr.c.

Or?

I mean, sending a "shut up" event to the

pcspkr's handler is not what snd-pcsp

needs to do.

--

At Fri, 02 May 2008 20:22:23 +0400,
If snd-pcsp can hook up input pcspkr dynamically, you can (should)

register snd-pcsp as a different name, as an individual platform

driver.  Then the whole PM stuff would still belong to snd-pcsp.
Takashi

--

No, the driver core doesn't allow that at all right now (I'm working on

fixing that though...)
What this patch did is just not allow you to have the same "name" for

the driver on the same bus, which is reasonable as without the check,

sysfs complains about trying to create a duplicate name in the same

directory.
Different names is fine, and I'll continue to work on the ability to

allow multiple drivers for the same device at the same time...
thanks,
greg k-h

--

At Tue, 29 Apr 2008 08:14:36 -0700,
Well, I wasn't clear enough -- currently we prohibit the *build* of

snd-pcsp driver when input pcspkr driver is built, regardless whether

module or built-in.  The reason is that sysfs spews an error with a

stack trace when the platform name conflicts, and this appears to be a

serious error.  Disabling the build is the simplest solution in such a

case (when considering built-in driver).
Now, with this patch, the platform name conflict appears non-critical,

and the driver should handle properly for the returned error code.

Thus, there shouldn't be a big obstacle to *build* both drivers.
Takashi

--

Ah, ok, that makes more sense :)
thanks,
greg k-h

--