Re: smbalert# hook for smbus childs

2002-06-27 Thread Willem van Engen

On Thu, 27 Jun 2002 12:21:19 +0900
"Takanori Watanabe" <[EMAIL PROTECTED]> wrote:

> In message <[EMAIL PROTECTED]>, Willem van Engen wrote:
> 
> >Hello,
> >
> >there already is some code for smbalert# handling on intpm
> >(ENABLE_ALART), but there is no support for handling it in a driver. O2
> >AudioDJ (OZ162) chips use this signal to indicate that a button was
> >pressed. So I need a way for a driver to be notified when smbalert#
> >occurs.
> 
> I have never tested the code, though. 

Well, it works :) When I press the button, the function that was passed to
bus_setup_alart is called.

> 
> >Of course I thought immediately about bus_(setup|teardown)_intr. I wrote
> >something like that for smbus: bus_(setup|teardown)_alart (see patch),
> >that works now. But is this The Right Way to do it? I do have some
> >thoughts on it, but maybe someone more knowledgeable than me could comment
> >on it.
> 
> I thought about ACPI embedded controller SMBus device driver and 
> this mechanism will be needed for implement event notification mechanism. 

That's a very good idea! And it would support all kinds of smbus
controllers. I started to look at this. But then I found this asl
snippet of my notebook:
Device(EC0_) {   
Name(_HID, 0x090cd041)
Name(_CRS, Buffer(0x12) {0x47,0x1, 0x62, 0x0, 0x62, 0x0, 0x1, 0x1, 
0x47, 0x1, 0x66, 0x0, 0x66, 0x0,0x1, 0x1, 0x79, 0x0 })
Name(_GPE, 0x0) Method(_Reg, 2) {[...] }

OperationRegion(SMB_, EmbeddedControl, 0x0, 0x40)
Field(SMB_, ByteAcc, Lock, Preserve) {
Offset(0x4),
CMCM,   8,
CMD1,   8,
CMD2,   8,
CMD3,   8,
Offset(0x18),
SMBP,   8,
SMBS,   8,
SMBA,   8,
SMBC,   8,
SMDD,   264
}
[2 more Field(SMB_, ...) definitions]
Mutex(MUT0, 0)
Event(SMBE)
Method(SMRE, 4) { [...] }   # SMBus Read
Method(SMWE, 4) { [...] }   # SMBus Write
[other methods that use SMRE&SMWR for reading temperature]
The smbus is used here (SMB_ offset 0x18 probabely is the SMB-HC[1]
register set), but no EC-SMB-HC (device with ACPI0001/ACPI0005 _HID)
here. It looks like SMBus CMI[2], but it lacks the SMBUS01 _HID (and the
_UID). So how does the os know that here's a smbus? Is it bad luck with
the supplied asl, or did I miss something?

[1] http://www.acpi.info/DOWNLOADS/ACPIspec-2-0a.pdf par 13.9.3
[2] http://www.smbus.org/specs/smbus_cmi10.pdf

> >It might be better to use bus_*_intr instead of bus_*_alart, but one
> >would need to bus_alloc_resource a slave address and pass that to
> >bus_setup_intr. But then it makes sense to use those slave address
> >resources to send smbus commands, right? But how would that fit into the
> >bus_space_* functions?
> 
> *I* think it is fit to smbus specific function.

Thanks, I'll leave it as it is now.

- Willem

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: smbalert# hook for smbus childs

2002-06-26 Thread Takanori Watanabe

In message <[EMAIL PROTECTED]>, Willem van Engen wrote:

>Hello,
>
>there already is some code for smbalert# handling on intpm
>(ENABLE_ALART), but there is no support for handling it in a driver. O2
>AudioDJ (OZ162) chips use this signal to indicate that a button was
>pressed. So I need a way for a driver to be notified when smbalert#
>occurs.

I have never tested the code, though. 

>Of course I thought immediately about bus_(setup|teardown)_intr. I wrote
>something like that for smbus: bus_(setup|teardown)_alart (see patch),
>that works now. But is this The Right Way to do it? I do have some
>thoughts on it, but maybe someone more knowledgeable than me could comment
>on it.

I thought about ACPI embedded controller SMBus device driver and 
this mechanism will be needed for implement event notification mechanism. 

>It might be better to use bus_*_intr instead of bus_*_alart, but one
>would need to bus_alloc_resource a slave address and pass that to
>bus_setup_intr. But then it makes sense to use those slave address
>resources to send smbus commands, right? But how would that fit into the
>bus_space_* functions?

*I* think it is fit to smbus specific function.

>p.s. I hope I'm clear, english isn't my native language.
So am I (T_T).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message