* Re: sonypc with Sony Vaio VGN-SZ1VP
@ 2006-09-27 11:51 stelian
2006-09-28 16:27 ` Yu Luming
2007-01-04 5:24 ` Len Brown
0 siblings, 2 replies; 43+ messages in thread
From: stelian @ 2006-09-27 11:51 UTC (permalink / raw)
To: Len Brown
Cc: Andrew Morton, Ismail Donmez, Stelian Pop, Andrea Gelmini,
linux-kernel, linux-acpi
>> > Will sony_acpi ever make it to the mainline? Its very useful for new
>> Vaio
>> > models.
>
> Nope, not as it is. Useful != supportable.
>
> 1. It must not create any files under /proc/acpi
> This is creating a machine-specific API, which
> is exactly what we don't want Nobody can maintain
> 50 machine specific APIs.
>
> These objects must appear generic and under sysfs
> as if acpi were not involved in providing them.
>
> 2. its source code shall not live in drivers/acpi
> it is not part of the ACPI implementation after all --
> it is a platform specific driver.
In this case, would a patch ripping off asus_acpi, ibm_acpi and
toshiba_acpi from the kernel be accepted ?
I don't really care much about sony_acpi (since I'm not maintaining it
anymore, even if I still answer support requests about it), but this is
just silly. This has been going on for more than one and a half year now.
Meanwhile (at least from what I've seen), the ACPI subsystem still doesn't
provide this "generic" API which platform specific driver need to
implement. drivers/acpi/{hotkey.c,video.c} are just rudimentary, and there
is no indication that this is going forward:
In March 2005 you (Len) said:
> The goal is to DELETE ibm, toshiba, and asus drivers -- or at least the
> duplicated functions in them.
>
> platform specific drivers make it harder, not easier, to support more
> hardware -- there are a zillion vendors out there, implementing special
> drivers for each of them is a strategy of last resort.
and
> I'd like to keep this driver out-of-tree
> until we prove that we can't enhance the
> generic code to handle this hardware
> without the addition of a new driver.
How long is this going to take ?
Stelian.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2006-09-27 11:51 sonypc with Sony Vaio VGN-SZ1VP stelian
@ 2006-09-28 16:27 ` Yu Luming
2007-01-04 5:24 ` Len Brown
1 sibling, 0 replies; 43+ messages in thread
From: Yu Luming @ 2006-09-28 16:27 UTC (permalink / raw)
To: stelian
Cc: Len Brown, Andrew Morton, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi
On Wednesday 27 September 2006 19:51, stelian@popies.net wrote:
> >> > Will sony_acpi ever make it to the mainline? Its very useful for new
> >>
> >> Vaio
> >>
> >> > models.
> >
> > Nope, not as it is. Useful != supportable.
> >
> > 1. It must not create any files under /proc/acpi
> > This is creating a machine-specific API, which
> > is exactly what we don't want Nobody can maintain
> > 50 machine specific APIs.
> >
> > These objects must appear generic and under sysfs
> > as if acpi were not involved in providing them.
> >
> > 2. its source code shall not live in drivers/acpi
> > it is not part of the ACPI implementation after all --
> > it is a platform specific driver.
>
> In this case, would a patch ripping off asus_acpi, ibm_acpi and
> toshiba_acpi from the kernel be accepted ?
>
> I don't really care much about sony_acpi (since I'm not maintaining it
> anymore, even if I still answer support requests about it), but this is
> just silly. This has been going on for more than one and a half year now.
>
> Meanwhile (at least from what I've seen), the ACPI subsystem still doesn't
> provide this "generic" API which platform specific driver need to
> implement. drivers/acpi/{hotkey.c,video.c} are just rudimentary, and there
> is no indication that this is going forward:
>
> In March 2005 you (Len) said:
> > The goal is to DELETE ibm, toshiba, and asus drivers -- or at least the
> > duplicated functions in them.
> >
> > platform specific drivers make it harder, not easier, to support more
> > hardware -- there are a zillion vendors out there, implementing special
> > drivers for each of them is a strategy of last resort.
hotkey.c was expected to replace all platform specific driver under
acpi directory, and I have ever expected that ACPI spec would define
standard device ID, and AML method name and event number for common keys
such as brightness control, output switch. So, I was expecting the hotkey.c
could become the generic driver when such spec was published and accepted
by OEMs. But, I don't know if such kind of things will happen.
>
> and
>
> > I'd like to keep this driver out-of-tree
> > until we prove that we can't enhance the
> > generic code to handle this hardware
> > without the addition of a new driver.
So, if there are NO standards, and we don't want mess up user space tools with
a dozen of totally different acpi proc interface for different platform
drivers. We have to use generic code to create unified interface for the
sake of clean user space tool. Some technique are:
1. use input layer to translate any hot-key event into key code defined in
input.h
2. use backlight class (driver/video/backlight.c) to hook generic brightness
control interface for brightness control under sysfs.
3. use output class to hook generic output switch control interface for
display output switch control under sysfs.
4. other generic code.
..
>
> How long is this going to take ?
>
I think the maintainer of asus_acpi, toshiba_acpi, ibm_acpi, sony_acpi,
panasonic_acpi, msi_acpi, ... should use the techniques mentioned above.
for new platform, Please don't just fork a new driver from toshiba_acpi.c, or
the existing ones in drivers/acpi. They also need to use generic code
mentioned above. Then, the platform specific driver could be accepted into
mainline. Otherwise, I don't know how these kind of platform specific driver
can be maintained, and deployed by OSV.
Thanks,
Luming
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2006-09-27 11:51 sonypc with Sony Vaio VGN-SZ1VP stelian
2006-09-28 16:27 ` Yu Luming
@ 2007-01-04 5:24 ` Len Brown
2007-01-04 10:09 ` Stelian Pop
2007-01-09 15:19 ` Luming Yu
1 sibling, 2 replies; 43+ messages in thread
From: Len Brown @ 2007-01-04 5:24 UTC (permalink / raw)
To: stelian
Cc: Andrew Morton, Ismail Donmez, Andrea Gelmini, linux-kernel, linux-acpi
On Wednesday 27 September 2006 07:51, stelian@popies.net wrote:
> >> > Will sony_acpi ever make it to the mainline? Its very useful for new
> > Nope, not as it is. Useful != supportable.
> >
> > 1. It must not create any files under /proc/acpi
> > This is creating a machine-specific API, which
> > is exactly what we don't want Nobody can maintain
> > 50 machine specific APIs.
> >
> > These objects must appear generic and under sysfs
> > as if acpi were not involved in providing them.
> >
> > 2. its source code shall not live in drivers/acpi
> > it is not part of the ACPI implementation after all --
> > it is a platform specific driver.
>
>...
>
> I don't really care much about sony_acpi (since I'm not maintaining it
> anymore, even if I still answer support requests about it), but this is
> just silly. This has been going on for more than one and a half year now.
>
> Meanwhile (at least from what I've seen), the ACPI subsystem still doesn't
> provide this "generic" API which platform specific driver need to
> implement. drivers/acpi/{hotkey.c,video.c} are just rudimentary, and there
> is no indication that this is going forward:
You are right. And the reason is that platform specific drivers are not part of ACPI.
They must either be vendor documented/supplied or reverse-engineered.
Vendors have not been forthcoming with documentation or code to support
Linux laptops, and our happy team here at Intel is not allowed to be in
the reverse enginering business.
So I concur that hotkey.c is a failed experiment, and I'm going to delete it.
There is more different than common on these boxes, so it makes no sense.
video.c, however, is standard, and stays for those machines that actually
do follow the public specification.
> In March 2005 you (Len) said:
>
> > The goal is to DELETE ibm, toshiba, and asus drivers -- or at least the
> video.c handles the standard compliant machines.> duplicated functions in them.
> >
> > platform specific drivers make it harder, not easier, to support more
> > hardware -- there are a zillion vendors out there, implementing special
> > drivers for each of them is a strategy of last resort.
Still true, though it is clear we'll never be able to delete platform specific parts --
just the parts that duplicate the generic standard functions..
> > I'd like to keep this driver out-of-tree
> > until we prove that we can't enhance the
> > generic code to handle this hardware
> > without the addition of a new driver.
>
> How long is this going to take ?
How about 2.6.21?
What needs to happen is
1. a maintainer for sony_acpi.c needs to step forward
I can't do this, I'm not allowed to be in the reverse engineering business.
2. /proc/acpi/sony API needs to be deleted
3. source needs to move out of drivers/acpi, and into drivers/misc along with msi.
Luming has a sony laptop and can help with this, but
he can't be the permanent maintainer any more than I can, for the same reason.
If we can get past #1, then I recommend we apply the patch series in -mm to
the acpi-test tree and go from there.
-Len
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 5:24 ` Len Brown
@ 2007-01-04 10:09 ` Stelian Pop
2007-01-04 19:15 ` Mattia Dongili
2007-01-09 15:19 ` Luming Yu
1 sibling, 1 reply; 43+ messages in thread
From: Stelian Pop @ 2007-01-04 10:09 UTC (permalink / raw)
To: Len Brown
Cc: Andrew Morton, Ismail Donmez, Andrea Gelmini, linux-kernel, linux-acpi
Le jeudi 04 janvier 2007 à 00:24 -0500, Len Brown a écrit :
> > > I'd like to keep this driver out-of-tree
> > > until we prove that we can't enhance the
> > > generic code to handle this hardware
> > > without the addition of a new driver.
> >
> > How long is this going to take ?
>
> How about 2.6.21?
Good news !
> What needs to happen is
> 1. a maintainer for sony_acpi.c needs to step forward
> I can't do this, I'm not allowed to be in the reverse engineering business.
Well, I can't do this either, because I just don't have the required
hardware anymore.
If someone want to step forward now it is a great time !
>
> 2. /proc/acpi/sony API needs to be deleted
>
> 3. source needs to move out of drivers/acpi, and into drivers/misc along with msi.
Sensible suggestions, the new maintainer will have to work on this.
Thanks Len.
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 10:09 ` Stelian Pop
@ 2007-01-04 19:15 ` Mattia Dongili
2007-01-04 20:51 ` Andrew Morton
` (2 more replies)
0 siblings, 3 replies; 43+ messages in thread
From: Mattia Dongili @ 2007-01-04 19:15 UTC (permalink / raw)
To: Stelian Pop
Cc: Len Brown, Andrew Morton, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
On Thu, Jan 04, 2007 at 11:09:44AM +0100, Stelian Pop wrote:
> Le jeudi 04 janvier 2007 à 00:24 -0500, Len Brown a écrit :
>
> > > > I'd like to keep this driver out-of-tree
> > > > until we prove that we can't enhance the
> > > > generic code to handle this hardware
> > > > without the addition of a new driver.
> > >
> > > How long is this going to take ?
> >
> > How about 2.6.21?
>
> Good news !
>
> > What needs to happen is
> > 1. a maintainer for sony_acpi.c needs to step forward
> > I can't do this, I'm not allowed to be in the reverse engineering business.
>
> Well, I can't do this either, because I just don't have the required
> hardware anymore.
>
> If someone want to step forward now it is a great time !
I have the hw and I'd be happy to do some basic working on the code
but:
- I'll probably need some help;
- I'll have an almost-blackout between the end of February and the end
of April as I'm moving to a different country and I'll need some time
before I can be active again (I hope I'll have at least easy mail
access for all the time though).
Anyway if it is still ok I can maintain the thing, to months seems
enough to give the driver a shape.
> > 2. /proc/acpi/sony API needs to be deleted
> >
> > 3. source needs to move out of drivers/acpi, and into drivers/misc along with msi.
And turn extra-backlight features into platform_device stuff? So 2 and 3
can come together.
Moreover, I own an SZ72B and an older GR7 and have come to the same
findings of Cacy, plus a patch to allow a smarter "debug" mode.
So, how to proceed? (I've just cloned the linux-acpi-2.6 tree)
Thanks Len, Thanks Stelian
--
mattia
:wq!
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 19:15 ` Mattia Dongili
@ 2007-01-04 20:51 ` Andrew Morton
2007-01-04 21:18 ` Mattia Dongili
2007-01-04 23:36 ` Stelian Pop
2007-01-04 23:34 ` Stelian Pop
2007-01-05 10:02 ` Stelian Pop
2 siblings, 2 replies; 43+ messages in thread
From: Andrew Morton @ 2007-01-04 20:51 UTC (permalink / raw)
To: Mattia Dongili
Cc: Stelian Pop, Len Brown, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
On Thu, 4 Jan 2007 20:15:12 +0100
Mattia Dongili <malattia@linux.it> wrote:
> On Thu, Jan 04, 2007 at 11:09:44AM +0100, Stelian Pop wrote:
> > Le jeudi 04 janvier 2007 __ 00:24 -0500, Len Brown a __crit :
> >
> > > > > I'd like to keep this driver out-of-tree
> > > > > until we prove that we can't enhance the
> > > > > generic code to handle this hardware
> > > > > without the addition of a new driver.
> > > >
> > > > How long is this going to take ?
> > >
> > > How about 2.6.21?
> >
> > Good news !
> >
> > > What needs to happen is
> > > 1. a maintainer for sony_acpi.c needs to step forward
> > > I can't do this, I'm not allowed to be in the reverse engineering business.
> >
> > Well, I can't do this either, because I just don't have the required
> > hardware anymore.
> >
> > If someone want to step forward now it is a great time !
>
> I have the hw and I'd be happy to do some basic working on the code
Neato, thanks.
> but:
> - I'll probably need some help;
> - I'll have an almost-blackout between the end of February and the end
> of April as I'm moving to a different country and I'll need some time
> before I can be active again (I hope I'll have at least easy mail
> access for all the time though).
> Anyway if it is still ok I can maintain the thing, to months seems
> enough to give the driver a shape.
>
> > > 2. /proc/acpi/sony API needs to be deleted
> > >
> > > 3. source needs to move out of drivers/acpi, and into drivers/misc along with msi.
>
> And turn extra-backlight features into platform_device stuff? So 2 and 3
> can come together.
>
> Moreover, I own an SZ72B and an older GR7 and have come to the same
> findings of Cacy, plus a patch to allow a smarter "debug" mode.
> So, how to proceed? (I've just cloned the linux-acpi-2.6 tree)
>
I have a VGN-something-or-other notebook and I use this driver regularly.
The place to start (please) is the patches in -mm:
2.6-sony_acpi4.patch
sony_apci-resume.patch
sony_apci-resume-fix.patch
acpi-add-backlight-support-to-the-sony_acpi.patch
acpi-add-backlight-support-to-the-sony_acpi-v2.patch
video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register-sony_acpi-fix.patch
It presently has both the /proc and /sys/.../backlight/.. interfaces, so the first
job would be to chop out the /proc stuff.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 20:51 ` Andrew Morton
@ 2007-01-04 21:18 ` Mattia Dongili
2007-01-04 21:28 ` Andrew Morton
2007-01-04 23:36 ` Stelian Pop
1 sibling, 1 reply; 43+ messages in thread
From: Mattia Dongili @ 2007-01-04 21:18 UTC (permalink / raw)
To: Andrew Morton
Cc: Stelian Pop, Len Brown, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
On Thu, Jan 04, 2007 at 12:51:07PM -0800, Andrew Morton wrote:
> On Thu, 4 Jan 2007 20:15:12 +0100
> Mattia Dongili <malattia@linux.it> wrote:
[...]
> > but:
> > - I'll probably need some help;
> > - I'll have an almost-blackout between the end of February and the end
> > of April as I'm moving to a different country and I'll need some time
> > before I can be active again (I hope I'll have at least easy mail
> > access for all the time though).
> > Anyway if it is still ok I can maintain the thing, to months seems
> > enough to give the driver a shape.
> >
> > > > 2. /proc/acpi/sony API needs to be deleted
> > > >
> > > > 3. source needs to move out of drivers/acpi, and into drivers/misc along with msi.
> >
> > And turn extra-backlight features into platform_device stuff? So 2 and 3
> > can come together.
> >
> > Moreover, I own an SZ72B and an older GR7 and have come to the same
> > findings of Cacy, plus a patch to allow a smarter "debug" mode.
> > So, how to proceed? (I've just cloned the linux-acpi-2.6 tree)
> >
>
> I have a VGN-something-or-other notebook and I use this driver regularly.
Hehehe, I think all the sony lappies are VGN-something :)
> The place to start (please) is the patches in -mm:
>
> 2.6-sony_acpi4.patch
> sony_apci-resume.patch
> sony_apci-resume-fix.patch
> acpi-add-backlight-support-to-the-sony_acpi.patch
> acpi-add-backlight-support-to-the-sony_acpi-v2.patch
> video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register-sony_acpi-fix.patch
>
> It presently has both the /proc and /sys/.../backlight/.. interfaces, so the first
> job would be to chop out the /proc stuff.
Ok, I'll import all of them and start from there.
Is it ok to wipe all the /proc stuff without notice?
--
mattia
:wq!
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 21:18 ` Mattia Dongili
@ 2007-01-04 21:28 ` Andrew Morton
2007-01-04 21:36 ` Timo Hoenig
2007-01-04 21:36 ` Richard Hughes
0 siblings, 2 replies; 43+ messages in thread
From: Andrew Morton @ 2007-01-04 21:28 UTC (permalink / raw)
To: Mattia Dongili
Cc: Stelian Pop, Len Brown, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
On Thu, 4 Jan 2007 22:18:30 +0100
Mattia Dongili <malattia@linux.it> wrote:
> > The place to start (please) is the patches in -mm:
> >
> > 2.6-sony_acpi4.patch
> > sony_apci-resume.patch
> > sony_apci-resume-fix.patch
> > acpi-add-backlight-support-to-the-sony_acpi.patch
> > acpi-add-backlight-support-to-the-sony_acpi-v2.patch
> > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register-sony_acpi-fix.patch
> >
> > It presently has both the /proc and /sys/.../backlight/.. interfaces, so the first
> > job would be to chop out the /proc stuff.
>
> Ok, I'll import all of them and start from there.
> Is it ok to wipe all the /proc stuff without notice?
spose so. I don't know if any apps are dependent upon the /proc file,
but the driver isn't in mainline yet so it's unlikely that there's a
mountain of software depending upon existing interfaces.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 21:28 ` Andrew Morton
@ 2007-01-04 21:36 ` Timo Hoenig
2007-01-04 21:36 ` Richard Hughes
1 sibling, 0 replies; 43+ messages in thread
From: Timo Hoenig @ 2007-01-04 21:36 UTC (permalink / raw)
To: Andrew Morton
Cc: Mattia Dongili, Stelian Pop, Len Brown, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
Hi,
On Thu, 2007-01-04 at 13:28 -0800, Andrew Morton wrote:
> spose so. I don't know if any apps are dependent upon the /proc file,
> but the driver isn't in mainline yet so it's unlikely that there's a
> mountain of software depending upon existing interfaces.
Not a mountain, but still a few applications support that interface.
At least the powersave daemon 'powersaved' and HAL support the
brightness interface of the Sony driver.
The responsible developers are following the linux-acpi list.
Timo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 21:28 ` Andrew Morton
2007-01-04 21:36 ` Timo Hoenig
@ 2007-01-04 21:36 ` Richard Hughes
2007-01-04 21:58 ` Mattia Dongili
1 sibling, 1 reply; 43+ messages in thread
From: Richard Hughes @ 2007-01-04 21:36 UTC (permalink / raw)
To: Andrew Morton
Cc: Mattia Dongili, Stelian Pop, Len Brown, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
On Thu, 2007-01-04 at 13:28 -0800, Andrew Morton wrote:
> On Thu, 4 Jan 2007 22:18:30 +0100
> Mattia Dongili <malattia@linux.it> wrote:
>
> > > The place to start (please) is the patches in -mm:
> > >
> > > 2.6-sony_acpi4.patch
> > > sony_apci-resume.patch
> > > sony_apci-resume-fix.patch
> > > acpi-add-backlight-support-to-the-sony_acpi.patch
> > > acpi-add-backlight-support-to-the-sony_acpi-v2.patch
> > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register-sony_acpi-fix.patch
> > >
> > > It presently has both the /proc and /sys/.../backlight/.. interfaces, so the first
> > > job would be to chop out the /proc stuff.
> >
> > Ok, I'll import all of them and start from there.
> > Is it ok to wipe all the /proc stuff without notice?
>
> spose so. I don't know if any apps are dependent upon the /proc file,
> but the driver isn't in mainline yet so it's unlikely that there's a
> mountain of software depending upon existing interfaces.
Well, HAL has used it for changing the brightness for the last year or
so: /proc/acpi/sony/brightness
Although if you use a new enough HAL (CVS), the laptop will be supported
via the shiny new backlight class.
Richard.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 21:36 ` Richard Hughes
@ 2007-01-04 21:58 ` Mattia Dongili
2007-01-05 17:02 ` Len Brown
0 siblings, 1 reply; 43+ messages in thread
From: Mattia Dongili @ 2007-01-04 21:58 UTC (permalink / raw)
To: Richard Hughes
Cc: Andrew Morton, Stelian Pop, Len Brown, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
On Thu, Jan 04, 2007 at 09:36:36PM +0000, Richard Hughes wrote:
> On Thu, 2007-01-04 at 13:28 -0800, Andrew Morton wrote:
> > On Thu, 4 Jan 2007 22:18:30 +0100
> > Mattia Dongili <malattia@linux.it> wrote:
> >
> > > > The place to start (please) is the patches in -mm:
> > > >
> > > > 2.6-sony_acpi4.patch
> > > > sony_apci-resume.patch
> > > > sony_apci-resume-fix.patch
> > > > acpi-add-backlight-support-to-the-sony_acpi.patch
> > > > acpi-add-backlight-support-to-the-sony_acpi-v2.patch
> > > > video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register-sony_acpi-fix.patch
> > > >
> > > > It presently has both the /proc and /sys/.../backlight/.. interfaces, so the first
> > > > job would be to chop out the /proc stuff.
> > >
> > > Ok, I'll import all of them and start from there.
> > > Is it ok to wipe all the /proc stuff without notice?
> >
> > spose so. I don't know if any apps are dependent upon the /proc file,
> > but the driver isn't in mainline yet so it's unlikely that there's a
> > mountain of software depending upon existing interfaces.
>
> Well, HAL has used it for changing the brightness for the last year or
> so: /proc/acpi/sony/brightness
>
> Although if you use a new enough HAL (CVS), the laptop will be supported
> via the shiny new backlight class.
great, -mm already has the /sys/class/backlight in place for sony_acpi
and I suppose the /proc entry can be kept until 2.6.20 is released, i.e.
just before pushing things for .21.
Len, would you allow it?
--
mattia
:wq!
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 19:15 ` Mattia Dongili
2007-01-04 20:51 ` Andrew Morton
@ 2007-01-04 23:34 ` Stelian Pop
2007-01-05 10:02 ` Stelian Pop
2 siblings, 0 replies; 43+ messages in thread
From: Stelian Pop @ 2007-01-04 23:34 UTC (permalink / raw)
To: Mattia Dongili
Cc: Len Brown, Andrew Morton, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
Le jeudi 04 janvier 2007 à 20:15 +0100, Mattia Dongili a écrit :
> > If someone want to step forward now it is a great time !
>
> I have the hw and I'd be happy to do some basic working on the code
Cool !
> but:
> - I'll probably need some help;
Feel free to ask...
> - I'll have an almost-blackout between the end of February and the end
> of April as I'm moving to a different country and I'll need some time
> before I can be active again (I hope I'll have at least easy mail
> access for all the time though).
Well, I am the current "maintainer" for this and it has probably been a
year since I left Sony's laptop world, so I guess it won't make much
difference if you're not very active for a month or two :)
Stelian.
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 20:51 ` Andrew Morton
2007-01-04 21:18 ` Mattia Dongili
@ 2007-01-04 23:36 ` Stelian Pop
2007-01-04 23:44 ` Andrew Morton
2007-01-05 0:11 ` sonypc with Sony Vaio VGN-SZ1VP Jan Engelhardt
1 sibling, 2 replies; 43+ messages in thread
From: Stelian Pop @ 2007-01-04 23:36 UTC (permalink / raw)
To: Andrew Morton
Cc: Mattia Dongili, Len Brown, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
Le jeudi 04 janvier 2007 à 12:51 -0800, Andrew Morton a écrit :
> The place to start (please) is the patches in -mm:
>
> 2.6-sony_acpi4.patch
> sony_apci-resume.patch
> sony_apci-resume-fix.patch
> acpi-add-backlight-support-to-the-sony_acpi.patch
> acpi-add-backlight-support-to-the-sony_acpi-v2.patch
> video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register-sony_acpi-fix.patch
In addition to those, I also have the attached patch in my local tree.
Stelian.
---
Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi subsystem,
and made correspondent necessary changes for this to work.
Signed-off-by: Nilton Volpato <nilton.volpato@gmail.com>
---
drivers/acpi/sony_acpi.c | 55 ++++++++++++++++++++++++----------------------
1 files changed, 29 insertions(+), 26 deletions(-)
diff --git a/drivers/acpi/sony_acpi.c b/drivers/acpi/sony_acpi.c
index e23522a..0c9367f 100644
--- a/drivers/acpi/sony_acpi.c
+++ b/drivers/acpi/sony_acpi.c
@@ -33,7 +33,7 @@
#define ACPI_SNC_CLASS "sony"
#define ACPI_SNC_HID "SNY5001"
-#define ACPI_SNC_DRIVER_NAME "ACPI Sony Notebook Control Driver v0.2"
+#define ACPI_SNC_DRIVER_NAME "ACPI Sony Notebook Control Driver v0.3"
#define LOG_PFX KERN_WARNING "sony_acpi: "
@@ -61,6 +61,7 @@ static struct acpi_driver sony_acpi_driv
static acpi_handle sony_acpi_handle;
static struct proc_dir_entry *sony_acpi_dir;
+static struct acpi_device *sony_acpi_acpi_device = NULL;
static struct sony_acpi_value {
char *name; /* name of the entry */
@@ -245,7 +246,9 @@ static int sony_acpi_write(struct file *
static void sony_acpi_notify(acpi_handle handle, u32 event, void *data)
{
- printk(LOG_PFX "sony_acpi_notify\n");
+ if (debug)
+ printk(LOG_PFX "sony_acpi_notify, event: %d\n", event);
+ acpi_bus_generate_event(sony_acpi_acpi_device, 1, event);
}
static acpi_status sony_walk_callback(acpi_handle handle, u32 level,
@@ -269,6 +272,8 @@ static int sony_acpi_add(struct acpi_dev
int result;
struct sony_acpi_value *item;
+ sony_acpi_acpi_device = device;
+
sony_acpi_handle = device->handle;
acpi_driver_data(device) = NULL;
@@ -282,16 +287,16 @@ static int sony_acpi_add(struct acpi_dev
result = -ENODEV;
goto outwalk;
}
+ }
- status = acpi_install_notify_handler(sony_acpi_handle,
- ACPI_DEVICE_NOTIFY,
- sony_acpi_notify,
- NULL);
- if (ACPI_FAILURE(status)) {
- printk(LOG_PFX "unable to install notify handler\n");
- result = -ENODEV;
- goto outnotify;
- }
+ status = acpi_install_notify_handler(sony_acpi_handle,
+ ACPI_DEVICE_NOTIFY,
+ sony_acpi_notify,
+ NULL);
+ if (ACPI_FAILURE(status)) {
+ printk(LOG_PFX "unable to install notify handler\n");
+ result = -ENODEV;
+ goto outnotify;
}
for (item = sony_acpi_values; item->name; ++item) {
@@ -310,7 +315,7 @@ static int sony_acpi_add(struct acpi_dev
item->acpiset, &handle)))
continue;
- item->proc = create_proc_entry(item->name, 0600,
+ item->proc = create_proc_entry(item->name, 0666,
acpi_device_dir(device));
if (!item->proc) {
printk(LOG_PFX "unable to create proc entry\n");
@@ -329,13 +334,11 @@ static int sony_acpi_add(struct acpi_dev
return 0;
outproc:
- if (debug) {
- status = acpi_remove_notify_handler(sony_acpi_handle,
- ACPI_DEVICE_NOTIFY,
- sony_acpi_notify);
- if (ACPI_FAILURE(status))
- printk(LOG_PFX "unable to remove notify handler\n");
- }
+ status = acpi_remove_notify_handler(sony_acpi_handle,
+ ACPI_DEVICE_NOTIFY,
+ sony_acpi_notify);
+ if (ACPI_FAILURE(status))
+ printk(LOG_PFX "unable to remove notify handler\n");
outnotify:
for (item = sony_acpi_values; item->name; ++item)
if (item->proc)
@@ -350,13 +353,13 @@ static int sony_acpi_remove(struct acpi_
acpi_status status;
struct sony_acpi_value *item;
- if (debug) {
- status = acpi_remove_notify_handler(sony_acpi_handle,
- ACPI_DEVICE_NOTIFY,
- sony_acpi_notify);
- if (ACPI_FAILURE(status))
- printk(LOG_PFX "unable to remove notify handler\n");
- }
+ sony_acpi_acpi_device = NULL;
+
+ status = acpi_remove_notify_handler(sony_acpi_handle,
+ ACPI_DEVICE_NOTIFY,
+ sony_acpi_notify);
+ if (ACPI_FAILURE(status))
+ printk(LOG_PFX "unable to remove notify handler\n");
for (item = sony_acpi_values; item->name; ++item)
if (item->proc)
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 23:36 ` Stelian Pop
@ 2007-01-04 23:44 ` Andrew Morton
2007-01-04 23:54 ` Stelian Pop
2007-01-05 2:20 ` MoRpHeUz
2007-01-05 0:11 ` sonypc with Sony Vaio VGN-SZ1VP Jan Engelhardt
1 sibling, 2 replies; 43+ messages in thread
From: Andrew Morton @ 2007-01-04 23:44 UTC (permalink / raw)
To: Stelian Pop
Cc: Mattia Dongili, Len Brown, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
On Fri, 05 Jan 2007 00:36:23 +0100
Stelian Pop <stelian@popies.net> wrote:
> Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi subsystem,
> and made correspondent necessary changes for this to work.
neato.
err, how does one use this?
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 23:44 ` Andrew Morton
@ 2007-01-04 23:54 ` Stelian Pop
2007-01-05 4:16 ` Andrew Morton
2007-01-05 2:20 ` MoRpHeUz
1 sibling, 1 reply; 43+ messages in thread
From: Stelian Pop @ 2007-01-04 23:54 UTC (permalink / raw)
To: Andrew Morton
Cc: Mattia Dongili, Len Brown, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
Le jeudi 04 janvier 2007 à 15:44 -0800, Andrew Morton a écrit :
> On Fri, 05 Jan 2007 00:36:23 +0100
> Stelian Pop <stelian@popies.net> wrote:
>
> > Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi subsystem,
> > and made correspondent necessary changes for this to work.
>
> neato.
>
> err, how does one use this?
:)
Well, it seems that on some Vaios (including Nilton's pcg-frv26 but not
only this one), the Fn key events aren't seen by sonypi or sony_acpi
GHKE method, but do generate an ACPI notify event.
For those laptops, the patch forwards the ACPI event to the ACPI system
and can be later interpreted in userspace using
acpid's /etc/acpi/default.sh (example directly from Nilton):
> case "$group" in
> button)
> case "$action" in
> power) /usr/sbin/hibernate
> ;;
>
> lid) cat /proc/acpi/button/lid/LID/state
> ;;
>
> *) logger "ACPI action $action is not defined ($@)"
> ;;
> esac
> ;;
>
> SNC) echo "$@" > /dev/tcp/localhost/50007
> ;;
>
> *) logger "ACPI group $group / action $action is not defined"
> ;;
> esac
>
> In which I just forward the SNC event to another userspace application
> listening on a TCP port.
Stelian.
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 23:36 ` Stelian Pop
2007-01-04 23:44 ` Andrew Morton
@ 2007-01-05 0:11 ` Jan Engelhardt
2007-01-05 9:15 ` Mattia Dongili
2007-01-05 9:59 ` Stelian Pop
1 sibling, 2 replies; 43+ messages in thread
From: Jan Engelhardt @ 2007-01-05 0:11 UTC (permalink / raw)
To: Stelian Pop
Cc: Andrew Morton, Mattia Dongili, Len Brown, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
On Jan 5 2007 00:36, Stelian Pop wrote:
>@@ -61,6 +61,7 @@ static struct acpi_driver sony_acpi_driv
>
> static acpi_handle sony_acpi_handle;
> static struct proc_dir_entry *sony_acpi_dir;
>+static struct acpi_device *sony_acpi_acpi_device = NULL;
acpi_acpi?
>@@ -310,7 +315,7 @@ static int sony_acpi_add(struct acpi_dev
> item->acpiset, &handle)))
> continue;
>
>- item->proc = create_proc_entry(item->name, 0600,
>+ item->proc = create_proc_entry(item->name, 0666,
> acpi_device_dir(device));
> if (!item->proc) {
> printk(LOG_PFX "unable to create proc entry\n");
Is this safe? I would not want normal users to poke on that.
-`J'
--
Himself owner of a VAIO U3.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 23:44 ` Andrew Morton
2007-01-04 23:54 ` Stelian Pop
@ 2007-01-05 2:20 ` MoRpHeUz
2007-01-05 17:11 ` Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP) Len Brown
1 sibling, 1 reply; 43+ messages in thread
From: MoRpHeUz @ 2007-01-05 2:20 UTC (permalink / raw)
To: Andrew Morton
Cc: Stelian Pop, Mattia Dongili, Len Brown, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
Hi,
I own a Sony Vaio VGN-SZ340 and I had problems regarding acpi + it's
dual core processor. The guys from Intel gave me a workaround and now
it recognises both cores.
The problem is that it does not do cpu frequency scaling for both
cores, just for cpu0...And when I boot with acpi the Nvidia graphic
card doesnt work also.
I don't know if you know about these problems regarding sony acpi.
The guys from Intel said that this notebook have 2 dst's. So to detect
both cores the workaround just uses the second dst (although frequency
scaling does work for both.)
I can help you to fix this bug...I have the machine where we can do
some tests..
Best regards,
On 1/4/07, Andrew Morton <akpm@osdl.org> wrote:
> On Fri, 05 Jan 2007 00:36:23 +0100
> Stelian Pop <stelian@popies.net> wrote:
>
> > Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi subsystem,
> > and made correspondent necessary changes for this to work.
>
> neato.
>
> err, how does one use this?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 23:54 ` Stelian Pop
@ 2007-01-05 4:16 ` Andrew Morton
2007-01-05 9:58 ` Stelian Pop
0 siblings, 1 reply; 43+ messages in thread
From: Andrew Morton @ 2007-01-05 4:16 UTC (permalink / raw)
To: Stelian Pop
Cc: Mattia Dongili, Len Brown, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
On Fri, 05 Jan 2007 00:54:32 +0100
Stelian Pop <stelian@popies.net> wrote:
> Le jeudi 04 janvier 2007 à 15:44 -0800, Andrew Morton a écrit :
> > On Fri, 05 Jan 2007 00:36:23 +0100
> > Stelian Pop <stelian@popies.net> wrote:
> >
> > > Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi subsystem,
> > > and made correspondent necessary changes for this to work.
> >
> > neato.
> >
> > err, how does one use this?
>
> :)
>
> Well, it seems that on some Vaios (including Nilton's pcg-frv26 but not
> only this one), the Fn key events aren't seen by sonypi or sony_acpi
> GHKE method, but do generate an ACPI notify event.
Speak English ;)
> For those laptops, the patch forwards the ACPI event to the ACPI system
> and can be later interpreted in userspace using
> acpid's /etc/acpi/default.sh (example directly from Nilton):
The only things Mr Red Hat gave me are /etc/acpi/events/sample.conf and
/etc/acpi/events/video.conf.
> > case "$group" in
> > button)
> > case "$action" in
> > power) /usr/sbin/hibernate
> > ;;
> >
> > lid) cat /proc/acpi/button/lid/LID/state
> > ;;
> >
> > *) logger "ACPI action $action is not defined ($@)"
> > ;;
> > esac
> > ;;
> >
> > SNC) echo "$@" > /dev/tcp/localhost/50007
> > ;;
> >
> > *) logger "ACPI group $group / action $action is not defined"
> > ;;
> > esac
> >
> > In which I just forward the SNC event to another userspace application
> > listening on a TCP port.
>
I pressed then released a button and dmesg said
[ 76.961568] evbug.c: Event. Dev: <NULL>, Type: 1, Code: 148, Value: 1
[ 76.961576] evbug.c: Event. Dev: <NULL>, Type: 0, Code: 0, Value: 0
[ 76.963277] evbug.c: Event. Dev: <NULL>, Type: 1, Code: 148, Value: 0
[ 76.963284] evbug.c: Event. Dev: <NULL>, Type: 0, Code: 0, Value: 0
[ 76.967341] evbug.c: Event. Dev: <NULL>, Type: 1, Code: 148, Value: 1
[ 76.967349] evbug.c: Event. Dev: <NULL>, Type: 0, Code: 0, Value: 0
[ 76.968136] evbug.c: Event. Dev: <NULL>, Type: 1, Code: 148, Value: 0
[ 76.968143] evbug.c: Event. Dev: <NULL>, Type: 0, Code: 0, Value: 0
Nothing else happened.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-05 0:11 ` sonypc with Sony Vaio VGN-SZ1VP Jan Engelhardt
@ 2007-01-05 9:15 ` Mattia Dongili
2007-01-05 9:59 ` Stelian Pop
1 sibling, 0 replies; 43+ messages in thread
From: Mattia Dongili @ 2007-01-05 9:15 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Stelian Pop, Andrew Morton, Len Brown, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
On Fri, Jan 05, 2007 at 01:11:16AM +0100, Jan Engelhardt wrote:
>
> On Jan 5 2007 00:36, Stelian Pop wrote:
> >@@ -61,6 +61,7 @@ static struct acpi_driver sony_acpi_driv
> >
> > static acpi_handle sony_acpi_handle;
> > static struct proc_dir_entry *sony_acpi_dir;
> >+static struct acpi_device *sony_acpi_acpi_device = NULL;
>
> acpi_acpi?
>
> >@@ -310,7 +315,7 @@ static int sony_acpi_add(struct acpi_dev
> > item->acpiset, &handle)))
> > continue;
> >
> >- item->proc = create_proc_entry(item->name, 0600,
> >+ item->proc = create_proc_entry(item->name, 0666,
> > acpi_device_dir(device));
> > if (!item->proc) {
> > printk(LOG_PFX "unable to create proc entry\n");
>
> Is this safe? I would not want normal users to poke on that.
Hmmm, seconded. It also seems quite a gratuitous change and I have a
different patch that takes care of permissions and the /proc stuff is
going away in any case.
--
mattia
:wq!
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-05 4:16 ` Andrew Morton
@ 2007-01-05 9:58 ` Stelian Pop
0 siblings, 0 replies; 43+ messages in thread
From: Stelian Pop @ 2007-01-05 9:58 UTC (permalink / raw)
To: Andrew Morton
Cc: Mattia Dongili, Len Brown, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
Le jeudi 04 janvier 2007 à 20:16 -0800, Andrew Morton a écrit :
> On Fri, 05 Jan 2007 00:54:32 +0100
> Stelian Pop <stelian@popies.net> wrote:
>
> > Le jeudi 04 janvier 2007 à 15:44 -0800, Andrew Morton a écrit :
> > > On Fri, 05 Jan 2007 00:36:23 +0100
> > > Stelian Pop <stelian@popies.net> wrote:
> > >
> > > > Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi subsystem,
> > > > and made correspondent necessary changes for this to work.
> > >
> > > neato.
> > >
> > > err, how does one use this?
> >
> > :)
> >
> > Well, it seems that on some Vaios (including Nilton's pcg-frv26 but not
> > only this one), the Fn key events aren't seen by sonypi or sony_acpi
> > GHKE method, but do generate an ACPI notify event.
>
> Speak English ;)
Oh, sorry, I'll try again :)
There are several ways of detecting the Fn key events, depending on the
Vaio series:
- some Vaios report them using the SPIC device (driven by sonypi)
- some Vaios let the driver poll for the Fn key status using the GHKE
ACPI method of the SNC device (driven by sony_acpi)
- some Vaios generate an ACPI notify event on the SNC device when a Fn
key is pressed - this is what the latest patch is for.
Unfortunately there are way too many different Vaio series, and no
information about what series support what method. I should have
maintained some sort of wiki to let the users build themselves a
comprehensive list, but I never get around to do it. Maybe Mattia could
do it if he has the time and will...
> > For those laptops, the patch forwards the ACPI event to the ACPI system
> > and can be later interpreted in userspace using
> > acpid's /etc/acpi/default.sh (example directly from Nilton):
>
> The only things Mr Red Hat gave me are /etc/acpi/events/sample.conf and
> /etc/acpi/events/video.conf.
Well, there was an /etc/acpi/default.sh in an older version of acpid...
I'm not sure what it looks like now on a recent Fedora but on my Ubuntu
I still have an acpid package, which has some files in /etc/acpi/
looking familiar.
> I pressed then released a button and dmesg said
>
> [ 76.961568] evbug.c: Event. Dev: <NULL>, Type: 1, Code: 148, Value: 1
> [ 76.961576] evbug.c: Event. Dev: <NULL>, Type: 0, Code: 0, Value: 0
> [ 76.963277] evbug.c: Event. Dev: <NULL>, Type: 1, Code: 148, Value: 0
> [ 76.963284] evbug.c: Event. Dev: <NULL>, Type: 0, Code: 0, Value: 0
> [ 76.967341] evbug.c: Event. Dev: <NULL>, Type: 1, Code: 148, Value: 1
> [ 76.967349] evbug.c: Event. Dev: <NULL>, Type: 0, Code: 0, Value: 0
> [ 76.968136] evbug.c: Event. Dev: <NULL>, Type: 1, Code: 148, Value: 0
> [ 76.968143] evbug.c: Event. Dev: <NULL>, Type: 0, Code: 0, Value: 0
>
> Nothing else happened.
Well, you got the events from evdev, which means you probably got them
directly from sonypi (or the regular keyboard..)
Unless your distribution does some neat tricks and somehow feeds the
events coming from somewhere into the event subsystem (like Ubuntu's
acpi_fakekey for example...).
Stelian.
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-05 0:11 ` sonypc with Sony Vaio VGN-SZ1VP Jan Engelhardt
2007-01-05 9:15 ` Mattia Dongili
@ 2007-01-05 9:59 ` Stelian Pop
1 sibling, 0 replies; 43+ messages in thread
From: Stelian Pop @ 2007-01-05 9:59 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Andrew Morton, Mattia Dongili, Len Brown, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
Le vendredi 05 janvier 2007 à 01:11 +0100, Jan Engelhardt a écrit :
> On Jan 5 2007 00:36, Stelian Pop wrote:
> >@@ -61,6 +61,7 @@ static struct acpi_driver sony_acpi_driv
> >
> > static acpi_handle sony_acpi_handle;
> > static struct proc_dir_entry *sony_acpi_dir;
> >+static struct acpi_device *sony_acpi_acpi_device = NULL;
>
> acpi_acpi?
Yeah, maybe Mattia will have more imagination than I at naming
variables :)
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 19:15 ` Mattia Dongili
2007-01-04 20:51 ` Andrew Morton
2007-01-04 23:34 ` Stelian Pop
@ 2007-01-05 10:02 ` Stelian Pop
2007-01-05 12:13 ` Mattia Dongili
2 siblings, 1 reply; 43+ messages in thread
From: Stelian Pop @ 2007-01-05 10:02 UTC (permalink / raw)
To: Mattia Dongili
Cc: Len Brown, Andrew Morton, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
Le jeudi 04 janvier 2007 à 20:15 +0100, Mattia Dongili a écrit :
> > > What needs to happen is
> > > 1. a maintainer for sony_acpi.c needs to step forward
> > > I can't do this, I'm not allowed to be in the reverse engineering business.
> >
> > Well, I can't do this either, because I just don't have the required
> > hardware anymore.
> >
> > If someone want to step forward now it is a great time !
>
> I have the hw and I'd be happy to do some basic working on the code
FYI, sonypi is also searching for a new maintainer, and it is quite
closely related to sony_acpi...
If you are interested by the job, it is all yours. :)
Stelian.
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-05 10:02 ` Stelian Pop
@ 2007-01-05 12:13 ` Mattia Dongili
2007-01-05 14:23 ` Jan Engelhardt
0 siblings, 1 reply; 43+ messages in thread
From: Mattia Dongili @ 2007-01-05 12:13 UTC (permalink / raw)
To: Stelian Pop
Cc: Len Brown, Andrew Morton, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi, Cacy Rodney
On Fri, Jan 05, 2007 at 11:02:03AM +0100, Stelian Pop wrote:
> Le jeudi 04 janvier 2007 à 20:15 +0100, Mattia Dongili a écrit :
>
> > > > What needs to happen is
> > > > 1. a maintainer for sony_acpi.c needs to step forward
> > > > I can't do this, I'm not allowed to be in the reverse engineering business.
> > >
> > > Well, I can't do this either, because I just don't have the required
> > > hardware anymore.
> > >
> > > If someone want to step forward now it is a great time !
> >
> > I have the hw and I'd be happy to do some basic working on the code
>
> FYI, sonypi is also searching for a new maintainer, and it is quite
> closely related to sony_acpi...
Yes, probably the FnKeys stuff needs to worked out into a single driver
to ease it usage (I still remember some very old discussion about making
sonypi use the acpi methods to access the hw).
> If you are interested by the job, it is all yours. :)
Let's see if I can come up with something, I have also an ux50 that is
not very happy with current sonypi
Thanks
--
mattia
:wq!
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-05 12:13 ` Mattia Dongili
@ 2007-01-05 14:23 ` Jan Engelhardt
0 siblings, 0 replies; 43+ messages in thread
From: Jan Engelhardt @ 2007-01-05 14:23 UTC (permalink / raw)
To: Mattia Dongili
Cc: Stelian Pop, Len Brown, Andrew Morton, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
On Jan 5 2007 13:13, Mattia Dongili wrote:
>
>> If you are interested by the job, it is all yours. :)
>
>Let's see if I can come up with something, I have also an ux50 that is
>not very happy with current sonypi
Feel free to contact me for testing on U3.
FnKey is done through sonypi here, if I unload it, `showkey` does not give
keycodes for them anymore.
-`J'
--
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 21:58 ` Mattia Dongili
@ 2007-01-05 17:02 ` Len Brown
2007-01-05 18:06 ` Mattia Dongili
0 siblings, 1 reply; 43+ messages in thread
From: Len Brown @ 2007-01-05 17:02 UTC (permalink / raw)
To: Mattia Dongili
Cc: Richard Hughes, Andrew Morton, Stelian Pop, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
> > Well, HAL has used it for changing the brightness for the last year or
> > so: /proc/acpi/sony/brightness
> >
> > Although if you use a new enough HAL (CVS), the laptop will be supported
> > via the shiny new backlight class.
>
> great, -mm already has the /sys/class/backlight in place for sony_acpi
> and I suppose the /proc entry can be kept until 2.6.20 is released, i.e.
> just before pushing things for .21.
>
> Len, would you allow it?
Sure, no problem.
Checking it into my tree with /proc/acpi/sony is
no different than what is in -mm today.
When we push upstream, however, the /proc/acpi/sony part should be gone,
or at least scheduled for removal.
I suggest a sub CONFIG option under CONFIG_SONY_ACPI, say,
CONFIG_SONY_ACPI_PROCFS so you can #ifdef the code that
is going away.
thanks for stepping forward Mattia,
-Len
^ permalink raw reply [flat|nested] 43+ messages in thread
* Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP)
2007-01-05 2:20 ` MoRpHeUz
@ 2007-01-05 17:11 ` Len Brown
2007-01-05 17:24 ` MoRpHeUz
0 siblings, 1 reply; 43+ messages in thread
From: Len Brown @ 2007-01-05 17:11 UTC (permalink / raw)
To: MoRpHeUz
Cc: Andrew Morton, Stelian Pop, Mattia Dongili, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
On Thursday 04 January 2007 21:20, MoRpHeUz wrote:
> Hi,
>
> I own a Sony Vaio VGN-SZ340 and I had problems regarding acpi + it's
> dual core processor. The guys from Intel gave me a workaround and now
> it recognises both cores.
What workaround are you using?
> The problem is that it does not do cpu frequency scaling for both
> cores, just for cpu0...And when I boot with acpi the Nvidia graphic
> card doesnt work also.
>
> I don't know if you know about these problems regarding sony acpi.
> The guys from Intel said that this notebook have 2 dst's. So to detect
> both cores the workaround just uses the second dst (although frequency
> scaling does work for both.)
>
> I can help you to fix this bug...I have the machine where we can do
> some tests..
The frequency scaling issue sounds like a BIOS/Linux incompatibility.
Please open a bugzilla, if you haven't already, and include the
output from acpidump.
The nvidia issue sounds like an interrupt issue, so please reproduce
it using the open source nvidia driver (not the nvidia binary),
and include the lspci -vv output, dmesg, and /proc/interrupts.
thanks,
-Len
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP)
2007-01-05 17:11 ` Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP) Len Brown
@ 2007-01-05 17:24 ` MoRpHeUz
2007-01-05 18:10 ` Len Brown
0 siblings, 1 reply; 43+ messages in thread
From: MoRpHeUz @ 2007-01-05 17:24 UTC (permalink / raw)
To: Len Brown
Cc: Andrew Morton, Stelian Pop, Mattia Dongili, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
> What workaround are you using?
This one: http://bugzilla.kernel.org/show_bug.cgi?id=7465
> The frequency scaling issue sounds like a BIOS/Linux incompatibility.
> Please open a bugzilla, if you haven't already, and include the
> output from acpidump.
I agree that it sound like a BIOS/Linux incompatibility. You can
find my acpidump and DSDT inside the link above. That bug is still
opened.
> The nvidia issue sounds like an interrupt issue, so please reproduce
> it using the open source nvidia driver (not the nvidia binary),
> and include the lspci -vv output, dmesg, and /proc/interrupts.
Will try that !
Thanks !
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-05 17:02 ` Len Brown
@ 2007-01-05 18:06 ` Mattia Dongili
0 siblings, 0 replies; 43+ messages in thread
From: Mattia Dongili @ 2007-01-05 18:06 UTC (permalink / raw)
To: Len Brown
Cc: Richard Hughes, Andrew Morton, Stelian Pop, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
On Fri, Jan 05, 2007 at 12:02:30PM -0500, Len Brown wrote:
> > > Well, HAL has used it for changing the brightness for the last year or
> > > so: /proc/acpi/sony/brightness
> > >
> > > Although if you use a new enough HAL (CVS), the laptop will be supported
> > > via the shiny new backlight class.
> >
> > great, -mm already has the /sys/class/backlight in place for sony_acpi
> > and I suppose the /proc entry can be kept until 2.6.20 is released, i.e.
> > just before pushing things for .21.
> >
> > Len, would you allow it?
>
> Sure, no problem.
> Checking it into my tree with /proc/acpi/sony is
> no different than what is in -mm today.
>
> When we push upstream, however, the /proc/acpi/sony part should be gone,
> or at least scheduled for removal.
I'd rather avoid pushing mainline something already scheduled for
removal. Also, a workaround can eventually be implemented in the
userspace tools using /proc/acpi/sony
[...]
> thanks for stepping forward Mattia,
It's me who should thank :)
Thanks
--
mattia
:wq!
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP)
2007-01-05 17:24 ` MoRpHeUz
@ 2007-01-05 18:10 ` Len Brown
2007-01-06 4:09 ` Bjorn Helgaas
0 siblings, 1 reply; 43+ messages in thread
From: Len Brown @ 2007-01-05 18:10 UTC (permalink / raw)
To: MoRpHeUz
Cc: Andrew Morton, Stelian Pop, Mattia Dongili, Ismail Donmez,
Andrea Gelmini, linux-kernel, linux-acpi, Cacy Rodney
On Friday 05 January 2007 12:24, MoRpHeUz wrote:
> > What workaround are you using?
>
> This one: http://bugzilla.kernel.org/show_bug.cgi?id=7465
Ah yes, the duplicate MADT issue is clearly a BIOS bug.
It is possible that we can tweak our Linux workaround for it to be more
Microsoft Windows Bug Compatbile(TM).
> > The frequency scaling issue sounds like a BIOS/Linux incompatibility.
It looks like this issue results from that above,
rather than being an additional problem.
> > The nvidia issue sounds like an interrupt issue, so please reproduce
> > it using the open source nvidia driver (not the nvidia binary),
> > and include the lspci -vv output, dmesg, and /proc/interrupts.
>
> Will try that !
If interrupts fail using the open source nvidia driver, (and using the workaround
from the bug above to use the right MADT, please open a new bug report
as I think it would be an independent issue.
thanks,
-Len
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP)
2007-01-05 18:10 ` Len Brown
@ 2007-01-06 4:09 ` Bjorn Helgaas
2007-01-11 19:52 ` Len Brown
0 siblings, 1 reply; 43+ messages in thread
From: Bjorn Helgaas @ 2007-01-06 4:09 UTC (permalink / raw)
To: Len Brown
Cc: MoRpHeUz, Andrew Morton, Stelian Pop, Mattia Dongili,
Ismail Donmez, Andrea Gelmini, linux-kernel, linux-acpi,
Cacy Rodney
On Friday 05 January 2007 11:10, Len Brown wrote:
> On Friday 05 January 2007 12:24, MoRpHeUz wrote:
> > > What workaround are you using?
> >
> > This one: http://bugzilla.kernel.org/show_bug.cgi?id=7465
>
> Ah yes, the duplicate MADT issue is clearly a BIOS bug.
> It is possible that we can tweak our Linux workaround for it to be more
> Microsoft Windows Bug Compatbile(TM).
Maybe Windows discovers processors using the namespace rather
than the MADT.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2007-01-04 5:24 ` Len Brown
2007-01-04 10:09 ` Stelian Pop
@ 2007-01-09 15:19 ` Luming Yu
1 sibling, 0 replies; 43+ messages in thread
From: Luming Yu @ 2007-01-09 15:19 UTC (permalink / raw)
To: Len Brown
Cc: stelian, Andrew Morton, Ismail Donmez, Andrea Gelmini,
linux-kernel, linux-acpi
> Luming has a sony laptop and can help with this, but
> he can't be the permanent maintainer any more than I can, for the same reason.
> If we can get past #1, then I recommend we apply the patch series in -mm to
> the acpi-test tree and go from there.
Yes, I happen to have a sony laptop. So, I can help the permanent
maintainer of sony acpi driver on acpi related issues.
--Luming
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP)
2007-01-06 4:09 ` Bjorn Helgaas
@ 2007-01-11 19:52 ` Len Brown
2007-01-11 20:01 ` Alexey Starikovskiy
0 siblings, 1 reply; 43+ messages in thread
From: Len Brown @ 2007-01-11 19:52 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: MoRpHeUz, Andrew Morton, Stelian Pop, Mattia Dongili,
Ismail Donmez, Andrea Gelmini, linux-kernel, linux-acpi,
Cacy Rodney
On Friday 05 January 2007 23:09, Bjorn Helgaas wrote:
> On Friday 05 January 2007 11:10, Len Brown wrote:
> > On Friday 05 January 2007 12:24, MoRpHeUz wrote:
> > > > What workaround are you using?
> > >
> > > This one: http://bugzilla.kernel.org/show_bug.cgi?id=7465
> >
> > Ah yes, the duplicate MADT issue is clearly a BIOS bug.
> > It is possible that we can tweak our Linux workaround for it to be more
> > Microsoft Windows Bug Compatbile(TM).
>
> Maybe Windows discovers processors using the namespace rather
> than the MADT.
Nod.
Based on the fact that the 1st MADT on this box is toast, they're not using that.
If the last one also doesn't work universally, then they must be using the namespace.
For us to do the same would be a relatively significant change -- as it means
we either have to push SMP startup after the interpreter init, or move the
interpreter init yet sooner.
In general, over the last couple of years, we've been forced for compatibility
with various systems to move ACPI initialization sooner and sooner.
(I think the last issue was getting the HW into "ACPI mode" sooner
because some stuff I don't recall didn't work if we didn't)
It would probably make sense to experiment with what the soonest we
can initialize ACPI, as I have a feeling we're going to have to head that way.
-Len
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP)
2007-01-11 19:52 ` Len Brown
@ 2007-01-11 20:01 ` Alexey Starikovskiy
0 siblings, 0 replies; 43+ messages in thread
From: Alexey Starikovskiy @ 2007-01-11 20:01 UTC (permalink / raw)
To: Len Brown
Cc: Bjorn Helgaas, MoRpHeUz, Andrew Morton, Stelian Pop,
Mattia Dongili, Ismail Donmez, Andrea Gelmini, linux-kernel,
linux-acpi, Cacy Rodney
Len Brown wrote:
> On Friday 05 January 2007 23:09, Bjorn Helgaas wrote:
>
>> On Friday 05 January 2007 11:10, Len Brown wrote:
>>
>>> On Friday 05 January 2007 12:24, MoRpHeUz wrote:
>>>
>>>>> What workaround are you using?
>>>>>
>>>> This one: http://bugzilla.kernel.org/show_bug.cgi?id=7465
>>>>
>>> Ah yes, the duplicate MADT issue is clearly a BIOS bug.
>>> It is possible that we can tweak our Linux workaround for it to be more
>>> Microsoft Windows Bug Compatbile(TM).
>>>
>> Maybe Windows discovers processors using the namespace rather
>> than the MADT.
>>
>
> Nod.
>
> Based on the fact that the 1st MADT on this box is toast, they're not using that.
> If the last one also doesn't work universally, then they must be using the namespace.
>
> For us to do the same would be a relatively significant change -- as it means
> we either have to push SMP startup after the interpreter init, or move the
> interpreter init yet sooner.
>
> In general, over the last couple of years, we've been forced for compatibility
> with various systems to move ACPI initialization sooner and sooner.
> (I think the last issue was getting the HW into "ACPI mode" sooner
> because some stuff I don't recall didn't work if we didn't)
> It would probably make sense to experiment with what the soonest we
> can initialize ACPI, as I have a feeling we're going to have to head that way.
>
> -Len
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
If any of the two tables does not work, may be we need both together?
Regards,
Alex.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2006-09-27 7:50 ` Ismail Donmez
@ 2006-09-28 15:48 ` Yu Luming
0 siblings, 0 replies; 43+ messages in thread
From: Yu Luming @ 2006-09-28 15:48 UTC (permalink / raw)
To: Ismail Donmez
Cc: Len Brown, Andrew Morton, Stelian Pop, Andrea Gelmini,
linux-kernel, linux-acpi
On Wednesday 27 September 2006 15:50, Ismail Donmez wrote:
> Hi,
> 27 Eyl 2006 Çar 09:04 tarihinde, Len Brown şunları yazmıştı:
> [...]
>
> > > > Will sony_acpi ever make it to the mainline? Its very useful for new
> > > > Vaio models.
> >
> > Nope, not as it is. Useful != supportable.
> >
> > 1. It must not create any files under /proc/acpi
> > This is creating a machine-specific API, which
> > is exactly what we don't want Nobody can maintain
> > 50 machine specific APIs.
> >
> > These objects must appear generic and under sysfs
> > as if acpi were not involved in providing them.
Yes, the idea of generic code and sysfs things can
remove the supportable issues as to complete different
user interface exposed in /proc/acpi/ by different
platform specific drivers such as ibm_acpi.c,
asus_acpi.c, and toshiba_acpi.c,....
> >
> > 2. its source code shall not live in drivers/acpi
> > it is not part of the ACPI implementation after all --
> > it is a platform specific driver.
>
> Is there a such example code under kernel now, so one could look at it and
> fix sony_acpi driver.
Please take a look at drivers/video/backlight..
And here is a example to use backlight class for acpi video driver:
http://marc.theaimsgroup.com/?l=linux-acpi&m=115574087203605&w=2
Please let me know if you have any other ideas to consolidate the
platform specific drivers such as ibm_acpi.c ,asus_acpi.c, toshiba_acpi.c
panasonic_acpi.c, sony_acpi.c , msi s270.c .....
Thanks,
Luming
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2006-09-27 5:14 ` Andrew Morton
2006-09-27 5:59 ` Jan Engelhardt
2006-09-27 6:04 ` Len Brown
@ 2006-09-27 16:26 ` Andrea Gelmini
2 siblings, 0 replies; 43+ messages in thread
From: Andrea Gelmini @ 2006-09-27 16:26 UTC (permalink / raw)
To: Andrew Morton
Cc: Stelian Pop, Andrea Gelmini, linux-kernel, Brown, Len,
linux-acpi, Ismail Donmez
On Tue, Sep 26, 2006 at 10:14:00PM -0700, Andrew Morton wrote:
> I'm inclined to slip it in, but Len has good-sounding reasons for not
> merging this sort of driver, and I always forget what they are?
well, for us, users/owners of newest vaio, there's no choice. with default
brightness it's impossibile, really impossibile, to read even the
characters of the console, in daylight.
carrie would say: "is it better to have sex with so-so partner, or not
having sex at all?".
Thanks a lot for your time,
Andrea
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2006-09-27 6:04 ` Len Brown
@ 2006-09-27 7:50 ` Ismail Donmez
2006-09-28 15:48 ` Yu Luming
0 siblings, 1 reply; 43+ messages in thread
From: Ismail Donmez @ 2006-09-27 7:50 UTC (permalink / raw)
To: Len Brown
Cc: Andrew Morton, Stelian Pop, Andrea Gelmini, linux-kernel, linux-acpi
Hi,
27 Eyl 2006 Çar 09:04 tarihinde, Len Brown şunları yazmıştı:
[...]
> > > Will sony_acpi ever make it to the mainline? Its very useful for new
> > > Vaio models.
>
> Nope, not as it is. Useful != supportable.
>
> 1. It must not create any files under /proc/acpi
> This is creating a machine-specific API, which
> is exactly what we don't want Nobody can maintain
> 50 machine specific APIs.
>
> These objects must appear generic and under sysfs
> as if acpi were not involved in providing them.
>
> 2. its source code shall not live in drivers/acpi
> it is not part of the ACPI implementation after all --
> it is a platform specific driver.
Is there a such example code under kernel now, so one could look at it and fix
sony_acpi driver.
Regards,
ismail
--
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
-- Benjamin Franklin
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2006-09-27 5:14 ` Andrew Morton
2006-09-27 5:59 ` Jan Engelhardt
@ 2006-09-27 6:04 ` Len Brown
2006-09-27 7:50 ` Ismail Donmez
2006-09-27 16:26 ` Andrea Gelmini
2 siblings, 1 reply; 43+ messages in thread
From: Len Brown @ 2006-09-27 6:04 UTC (permalink / raw)
To: Andrew Morton
Cc: Ismail Donmez, Stelian Pop, Andrea Gelmini, linux-kernel, linux-acpi
On Wednesday 27 September 2006 01:14, Andrew Morton wrote:
> On Tue, 26 Sep 2006 20:56:31 +0300
> Ismail Donmez <ismail@pardus.org.tr> wrote:
>
> > 26 Eyl 2006 Sal 19:29 tarihinde şunları yazmıştınız:
> > > Andrea Gelmini a écrit :
> > > > Hi,
> > > > I've got a Sony Vaio VGN-SZ1VP (dmidecode[1] and lspci[2]).
> > > > Using default kernel (linux-image-2.6.15-27-686) of Ubuntu
> > > > Dapper I've got /proc/acpi/sony/brightness and it works well
> > > > (yes, Ubuntu drivers/char/sonypi.c is patched).
> > > > With any other newer vanilla kernel, 2.6.15/16/17/18, /proc/acpi/sony
> > > > doesn't appear, and it's impossibile to set brigthness, of
> > > > course. Same thing with Ubuntu kernel package
> > > > (linux-image-2.6.17-9-386).
> > > > I tried to port Ubuntu sonypi.c patches to 2.6.18, but it doesn't
> > > > work (I mean, it compiles clean, it "modprobes"[3] clean, but no
> > > > /proc/acpi/sony/ directory).
> > >
> > > /proc/acpi/sony comes from the sony_acpi driver, not sonypi.
> > >
> > > You should get the latest sony_acpi driver, preferably from the -mm tree
> > > which hosts the most up to date version.
> >
> > Will sony_acpi ever make it to the mainline? Its very useful for new Vaio
> > models.
Nope, not as it is. Useful != supportable.
1. It must not create any files under /proc/acpi
This is creating a machine-specific API, which
is exactly what we don't want Nobody can maintain
50 machine specific APIs.
These objects must appear generic and under sysfs
as if acpi were not involved in providing them.
2. its source code shall not live in drivers/acpi
it is not part of the ACPI implementation after all --
it is a platform specific driver.
thanks,
-Len
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2006-09-27 5:14 ` Andrew Morton
@ 2006-09-27 5:59 ` Jan Engelhardt
2006-09-27 6:04 ` Len Brown
2006-09-27 16:26 ` Andrea Gelmini
2 siblings, 0 replies; 43+ messages in thread
From: Jan Engelhardt @ 2006-09-27 5:59 UTC (permalink / raw)
To: Andrew Morton
Cc: Ismail Donmez, Stelian Pop, Andrea Gelmini, linux-kernel, Brown,
Len, linux-acpi
>> Will sony_acpi ever make it to the mainline? Its very useful for new Vaio
>> models.
>
>I'm inclined to slip it in, but Len has good-sounding reasons for not
>merging this sort of driver, and I always forget what they are?
http://lkml.org/lkml/2006/1/5/57
Jan Engelhardt
--
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2006-09-26 17:56 ` Ismail Donmez
@ 2006-09-27 5:14 ` Andrew Morton
2006-09-27 5:59 ` Jan Engelhardt
` (2 more replies)
0 siblings, 3 replies; 43+ messages in thread
From: Andrew Morton @ 2006-09-27 5:14 UTC (permalink / raw)
To: Ismail Donmez
Cc: Stelian Pop, Andrea Gelmini, linux-kernel, Brown, Len, linux-acpi
On Tue, 26 Sep 2006 20:56:31 +0300
Ismail Donmez <ismail@pardus.org.tr> wrote:
> 26 Eyl 2006 Sal 19:29 tarihinde şunları yazmıştınız:
> > Andrea Gelmini a écrit :
> > > Hi,
> > > I've got a Sony Vaio VGN-SZ1VP (dmidecode[1] and lspci[2]).
> > > Using default kernel (linux-image-2.6.15-27-686) of Ubuntu
> > > Dapper I've got /proc/acpi/sony/brightness and it works well
> > > (yes, Ubuntu drivers/char/sonypi.c is patched).
> > > With any other newer vanilla kernel, 2.6.15/16/17/18, /proc/acpi/sony
> > > doesn't appear, and it's impossibile to set brigthness, of
> > > course. Same thing with Ubuntu kernel package
> > > (linux-image-2.6.17-9-386).
> > > I tried to port Ubuntu sonypi.c patches to 2.6.18, but it doesn't
> > > work (I mean, it compiles clean, it "modprobes"[3] clean, but no
> > > /proc/acpi/sony/ directory).
> >
> > /proc/acpi/sony comes from the sony_acpi driver, not sonypi.
> >
> > You should get the latest sony_acpi driver, preferably from the -mm tree
> > which hosts the most up to date version.
>
> Will sony_acpi ever make it to the mainline? Its very useful for new Vaio
> models.
>
I'm inclined to slip it in, but Len has good-sounding reasons for not
merging this sort of driver, and I always forget what they are?
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2006-09-26 16:29 ` Stelian Pop
2006-09-26 17:56 ` Ismail Donmez
@ 2006-09-26 21:38 ` Andrea Gelmini
1 sibling, 0 replies; 43+ messages in thread
From: Andrea Gelmini @ 2006-09-26 21:38 UTC (permalink / raw)
To: Stelian Pop; +Cc: linux-kernel
On Tue, Sep 26, 2006 at 06:29:55PM +0200, Stelian Pop wrote:
> You should get the latest sony_acpi driver, preferably from the -mm tree
> which hosts the most up to date version.
Thanks a lot for your quick answer.
With 2.6.18-mm1 it works fine.
Thanks again,
Andrea Gelmini
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2006-09-26 16:29 ` Stelian Pop
@ 2006-09-26 17:56 ` Ismail Donmez
2006-09-27 5:14 ` Andrew Morton
2006-09-26 21:38 ` Andrea Gelmini
1 sibling, 1 reply; 43+ messages in thread
From: Ismail Donmez @ 2006-09-26 17:56 UTC (permalink / raw)
To: Stelian Pop; +Cc: Andrea Gelmini, linux-kernel
26 Eyl 2006 Sal 19:29 tarihinde şunları yazmıştınız:
> Andrea Gelmini a écrit :
> > Hi,
> > I've got a Sony Vaio VGN-SZ1VP (dmidecode[1] and lspci[2]).
> > Using default kernel (linux-image-2.6.15-27-686) of Ubuntu
> > Dapper I've got /proc/acpi/sony/brightness and it works well
> > (yes, Ubuntu drivers/char/sonypi.c is patched).
> > With any other newer vanilla kernel, 2.6.15/16/17/18, /proc/acpi/sony
> > doesn't appear, and it's impossibile to set brigthness, of
> > course. Same thing with Ubuntu kernel package
> > (linux-image-2.6.17-9-386).
> > I tried to port Ubuntu sonypi.c patches to 2.6.18, but it doesn't
> > work (I mean, it compiles clean, it "modprobes"[3] clean, but no
> > /proc/acpi/sony/ directory).
>
> /proc/acpi/sony comes from the sony_acpi driver, not sonypi.
>
> You should get the latest sony_acpi driver, preferably from the -mm tree
> which hosts the most up to date version.
Will sony_acpi ever make it to the mainline? Its very useful for new Vaio
models.
--
They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.
-- Benjamin Franklin
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: sonypc with Sony Vaio VGN-SZ1VP
2006-09-26 13:56 Andrea Gelmini
@ 2006-09-26 16:29 ` Stelian Pop
2006-09-26 17:56 ` Ismail Donmez
2006-09-26 21:38 ` Andrea Gelmini
0 siblings, 2 replies; 43+ messages in thread
From: Stelian Pop @ 2006-09-26 16:29 UTC (permalink / raw)
To: Andrea Gelmini; +Cc: linux-kernel
Andrea Gelmini a écrit :
> Hi,
> I've got a Sony Vaio VGN-SZ1VP (dmidecode[1] and lspci[2]).
> Using default kernel (linux-image-2.6.15-27-686) of Ubuntu
> Dapper I've got /proc/acpi/sony/brightness and it works well
> (yes, Ubuntu drivers/char/sonypi.c is patched).
> With any other newer vanilla kernel, 2.6.15/16/17/18, /proc/acpi/sony
> doesn't appear, and it's impossibile to set brigthness, of
> course. Same thing with Ubuntu kernel package
> (linux-image-2.6.17-9-386).
> I tried to port Ubuntu sonypi.c patches to 2.6.18, but it doesn't
> work (I mean, it compiles clean, it "modprobes"[3] clean, but no
> /proc/acpi/sony/ directory).
/proc/acpi/sony comes from the sony_acpi driver, not sonypi.
You should get the latest sony_acpi driver, preferably from the -mm tree
which hosts the most up to date version.
Stelian.
--
Stelian Pop <stelian@popies.net>
^ permalink raw reply [flat|nested] 43+ messages in thread
* sonypc with Sony Vaio VGN-SZ1VP
@ 2006-09-26 13:56 Andrea Gelmini
2006-09-26 16:29 ` Stelian Pop
0 siblings, 1 reply; 43+ messages in thread
From: Andrea Gelmini @ 2006-09-26 13:56 UTC (permalink / raw)
To: stelian; +Cc: linux-kernel
Hi,
I've got a Sony Vaio VGN-SZ1VP (dmidecode[1] and lspci[2]).
Using default kernel (linux-image-2.6.15-27-686) of Ubuntu
Dapper I've got /proc/acpi/sony/brightness and it works well
(yes, Ubuntu drivers/char/sonypi.c is patched).
With any other newer vanilla kernel, 2.6.15/16/17/18, /proc/acpi/sony
doesn't appear, and it's impossibile to set brigthness, of
course. Same thing with Ubuntu kernel package
(linux-image-2.6.17-9-386).
I tried to port Ubuntu sonypi.c patches to 2.6.18, but it doesn't
work (I mean, it compiles clean, it "modprobes"[3] clean, but no
/proc/acpi/sony/ directory).
Thanks a lot for your time and work,
Andrea Gelmini
------------------
[1]
# dmidecode 2.7
SMBIOS 2.31 present.
19 structures occupying 910 bytes.
Table at 0x000DC010.
Handle 0x0000, DMI type 0, 20 bytes.
BIOS Information
Vendor: Phoenix Technologies LTD
Version: R0073N0
Release Date: 04/14/2006
Address: 0xE4590
Runtime Size: 113264 bytes
ROM Size: 1024 kB
Characteristics:
PCI is supported
PC Card (PCMCIA) is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
ESCD support is available
Boot from CD is supported
Selectable boot is supported
EDD is supported
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
AGP is supported
Smart battery is supported
BIOS boot specification is supported
Function key-initiated network boot is supported
Handle 0x0001, DMI type 1, 25 bytes.
System Information
Manufacturer: Sony Corporation
Product Name: VGN-SZ1VP_C
Version: J001JSJU
Serial Number: XXXXXXXX-XXXXXXX
UUID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Wake-up Type: Power Switch
Handle 0x0002, DMI type 2, 10 bytes.
Base Board Information
Manufacturer: Sony Corporation
Product Name: VAIO
Version: N/A
Serial Number: N/A
Handle 0x0003, DMI type 3, 17 bytes.
Chassis Information
Manufacturer: Sony Corporation
Type: Notebook
Lock: Not Present
Version: N/A
Serial Number: J001JSJU
Asset Tag:
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000009
Handle 0x0004, DMI type 4, 35 bytes.
Processor Information
Socket Designation: N/A
Type: Central Processor
Family: Other
Manufacturer: GenuineIntel
ID: E8 06 00 00 FF FB E9 BF
Version: Genuine Intel(R) CPU T2500 @ 2.00GHz
Voltage: 1.4 V
External Clock: 166 MHz
Max Speed: 2000 MHz
Current Speed: 2000 MHz
Status: Populated, Enabled
Upgrade: None
L1 Cache Handle: 0x0005
L2 Cache Handle: 0x0006
L3 Cache Handle: 0x0007
Serial Number: N/A
Asset Tag: N/A
Part Number: N/A
Handle 0x0005, DMI type 7, 19 bytes.
Cache Information
Socket Designation: L1 Cache
Configuration: Enabled, Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 32 KB
Maximum Size: 32 KB
Supported SRAM Types:
Burst
Pipeline Burst
Asynchronous
Installed SRAM Type: Asynchronous
Speed: Unknown
Error Correction Type: None
System Type: Other
Associativity: 8-way Set-associative
Handle 0x0006, DMI type 7, 19 bytes.
Cache Information
Socket Designation: L2 Cache
Configuration: Enabled, Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 2048 KB
Maximum Size: 2048 KB
Supported SRAM Types:
Burst
Pipeline Burst
Asynchronous
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: None
System Type: Data
Associativity: 8-way Set-associative
Handle 0x0007, DMI type 7, 19 bytes.
Cache Information
Socket Designation: L3 Cache
Configuration: Disabled, Not Socketed, Level 3
Operational Mode: Unknown
Location: Unknown
Installed Size: 0 KB
Maximum Size: 0 KB
Supported SRAM Types:
Burst
Pipeline Burst
Asynchronous
Installed SRAM Type: Burst
Speed: Unknown
Error Correction Type: None
System Type: Data
Associativity: 4-way Set-associative
Handle 0x0008, DMI type 9, 13 bytes.
System Slot Information
Designation: PCCARD1
Type: 32-bit PC Card (PCMCIA)
Current Usage: Available
Length: Other
ID: Adapter 0, Socket 1
Characteristics:
5.0 V is provided
3.3 V is provided
PC Card-16 is supported
Cardbus is supported
Modem ring resume is supported
PME signal is supported
Hot-plug devices are supported
Handle 0x0009, DMI type 11, 5 bytes.
OEM Strings
String 1: JPBL-001958
String 2: FNC-CCIA0oke
String 3: 6J1M00000000c54de9515223d902
String 4: Reserved
String 5: Reserved
Handle 0x000A, DMI type 16, 15 bytes.
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Unknown
Maximum Capacity: 2048 GB
Error Information Handle: Not Provided
Number Of Devices: 2
Handle 0x000B, DMI type 17, 21 bytes.
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: 32 bits
Data Width: 32 bits
Size: 1024 MB
Form Factor: SODIMM
Set: None
Locator: SODIMM1
Bank Locator: Bank 0
Type: DDR
Type Detail: Unknown
Handle 0x000C, DMI type 17, 21 bytes.
Memory Device
Array Handle: 0x000A
Error Information Handle: Not Provided
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: SODIMM
Set: None
Locator: SODIMM2
Bank Locator: Bank 1
Type: Unknown
Type Detail: Unknown
Handle 0x000D, DMI type 19, 15 bytes.
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0003FFFFFFF
Range Size: 1 GB
Physical Array Handle: 0x000A
Partition Width: 0
Handle 0x000E, DMI type 20, 19 bytes.
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x0003FFFFFFF
Range Size: 1 GB
Physical Device Handle: 0x000B
Memory Array Mapped Address Handle: 0x000D
Partition Row Position: Unknown
Interleave Position: Unknown
Interleaved Data Depth: Unknown
Handle 0x000F, DMI type 20, 19 bytes.
Memory Device Mapped Address
Starting Address: 0x0003FFFFC00
Ending Address: 0x0003FFFFFFF
Range Size: 1 kB
Physical Device Handle: 0x000C
Memory Array Mapped Address Handle: 0x000D
Partition Row Position: Unknown
Interleave Position: Unknown
Interleaved Data Depth: Unknown
Handle 0x0010, DMI type 32, 11 bytes.
System Boot Information
Status: No errors detected
Handle 0x0011, DMI type 136, 6 bytes.
OEM-specific Type
Header and Data:
88 06 11 00 5A 5A
Handle 0x0012, DMI type 127, 4 bytes.
End Of Table
[2]
0000:00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 03)
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Capabilities: [e0] #09 [5109]
0000:00:02.0 VGA compatible controller: Intel Corporation Mobile Integrated Graphics Controller (rev 03) (prog-if 00 [VGA])
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 169
Region 0: Memory at dc200000 (32-bit, non-prefetchable) [size=512K]
Region 1: I/O ports at 1800 [size=8]
Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
Region 3: Memory at dc300000 (32-bit, non-prefetchable) [size=256K]
Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Address: 00000000 Data: 0000
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:02.1 Display controller: Intel Corporation Mobile Integrated Graphics Controller (rev 03)
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 0: Memory at dc280000 (32-bit, non-prefetchable) [size=512K]
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:1b.0 0403: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 0x10 (64 bytes)
Interrupt: pin A routed to IRQ 225
Region 0: Memory at dc340000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [70] #10 [0091]
0000:00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 0x10 (64 bytes)
Bus: primary=00, secondary=02, subordinate=05, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: d6000000-d7ffffff
Prefetchable memory behind bridge: 00000000d0000000-00000000d1f00000
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] #10 [0141]
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Address: 00000000 Data: 0000
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 0x10 (64 bytes)
Bus: primary=00, secondary=06, subordinate=06, sec-latency=0
Memory behind bridge: dc100000-dc1fffff
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] #10 [0141]
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Address: 00000000 Data: 0000
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 0x10 (64 bytes)
Bus: primary=00, secondary=07, subordinate=07, sec-latency=0
I/O behind bridge: 00003000-00003fff
Memory behind bridge: d8000000-d9ffffff
Prefetchable memory behind bridge: 00000000d2000000-00000000d3f00000
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] #10 [0141]
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Address: 00000000 Data: 0000
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 0x10 (64 bytes)
Bus: primary=00, secondary=08, subordinate=08, sec-latency=0
I/O behind bridge: 00004000-00004fff
Memory behind bridge: da000000-dbffffff
Prefetchable memory behind bridge: 00000000d4000000-00000000d5f00000
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [40] #10 [0141]
Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
Address: 00000000 Data: 0000
Capabilities: [90] #0d [0000]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02) (prog-if 00 [UHCI])
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 193
Region 4: I/O ports at 1820 [size=32]
0000:00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02) (prog-if 00 [UHCI])
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 193
Region 4: I/O ports at 1840 [size=32]
0000:00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02) (prog-if 00 [UHCI])
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin C routed to IRQ 193
Region 4: I/O ports at 1860 [size=32]
0000:00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02) (prog-if 00 [UHCI])
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 193
Region 4: I/O ports at 1880 [size=32]
0000:00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin D routed to IRQ 217
Region 0: Memory at dc544000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] #0a [20a0]
0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=09, subordinate=0a, sec-latency=56
I/O behind bridge: 00005000-00005fff
Memory behind bridge: dc000000-dc0fffff
Prefetchable memory behind bridge: 0000000050000000-0000000051f00000
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [50] #0d [0000]
0000:00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [e0] #09 [100c]
0000:00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 255
Region 0: I/O ports at <unassigned>
Region 1: I/O ports at <unassigned>
Region 2: I/O ports at <unassigned>
Region 3: I/O ports at <unassigned>
Region 4: I/O ports at 1810 [size=16]
0000:00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controllers cc=IDE (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin B routed to IRQ 209
Region 0: I/O ports at 18d0 [size=8]
Region 1: I/O ports at 18c4 [size=4]
Region 2: I/O ports at 18c8 [size=8]
Region 3: I/O ports at 18c0 [size=4]
Region 4: I/O ports at 18b0 [size=16]
Region 5: Memory at dc544400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [70] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
0000:00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Region 4: I/O ports at 18e0 [size=32]
0000:06:00.0 Network controller: Intel Corporation: Unknown device 4222 (rev 02)
Subsystem: Intel Corporation: Unknown device 1051
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 0x10 (64 bytes)
Interrupt: pin A routed to IRQ 10
Region 0: Memory at dc100000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [e0] #10 [0011]
0000:07:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 Fast Ethernet Controller (rev 15)
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 0x10 (64 bytes)
Interrupt: pin A routed to IRQ 50
Region 0: Memory at d8000000 (64-bit, non-prefetchable) [size=16K]
Region 2: I/O ports at 3000 [size=256]
Capabilities: [48] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] Vital Product Data
Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+
Address: 00000000fee00000 Data: 4032
Capabilities: [e0] #10 [0011]
0000:09:04.0 CardBus bridge: Texas Instruments: Unknown device 8039
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, Cache Line Size: 0x10 (64 bytes)
Interrupt: pin A routed to IRQ 201
Region 0: Memory at dc006000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=09, secondary=0a, subordinate=0d, sec-latency=176
Memory window 0: 50000000-51fff000 (prefetchable)
Memory window 1: 52000000-53fff000 (prefetchable)
I/O window 0: 00005000-000050ff
I/O window 1: 00005400-000054ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt- PostWrite-
16-bit legacy interface ports at 0001
0000:09:04.1 FireWire (IEEE 1394): Texas Instruments: Unknown device 803a (prog-if 10 [OHCI])
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (750ns min, 1000ns max), Cache Line Size: 0x10 (64 bytes)
Interrupt: pin B routed to IRQ 10
Region 0: Memory at dc005000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at dc000000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
0000:09:04.2 Mass storage controller: Texas Instruments: Unknown device 803b
Subsystem: Sony Corporation: Unknown device 81e6
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 57 (1750ns min, 1000ns max), Cache Line Size: 0x10 (64 bytes)
Interrupt: pin C routed to IRQ 10
Region 0: Memory at dc004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
[3]
[4294697.418000] input: Sony Vaio Jogdial as /class/input/input4
[4294697.418000] input: Sony Vaio Keys as /class/input/input5
[4294697.419000] sonypi: Sony Programmable I/O Controller Driverv1.26.
[4294697.419000] sonypi: detected type3 model, verbose = 0, fnkeyinit = off, camera = off, compat = off, mask = 0xffffffff, useinput = on, acpi = on
[4294697.419000] sonypi: enabled at irq=11, port1=0x1080, port2=0x1084
[4294697.419000] sonypi: device allocated minor is 61
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2007-01-11 20:01 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-09-27 11:51 sonypc with Sony Vaio VGN-SZ1VP stelian
2006-09-28 16:27 ` Yu Luming
2007-01-04 5:24 ` Len Brown
2007-01-04 10:09 ` Stelian Pop
2007-01-04 19:15 ` Mattia Dongili
2007-01-04 20:51 ` Andrew Morton
2007-01-04 21:18 ` Mattia Dongili
2007-01-04 21:28 ` Andrew Morton
2007-01-04 21:36 ` Timo Hoenig
2007-01-04 21:36 ` Richard Hughes
2007-01-04 21:58 ` Mattia Dongili
2007-01-05 17:02 ` Len Brown
2007-01-05 18:06 ` Mattia Dongili
2007-01-04 23:36 ` Stelian Pop
2007-01-04 23:44 ` Andrew Morton
2007-01-04 23:54 ` Stelian Pop
2007-01-05 4:16 ` Andrew Morton
2007-01-05 9:58 ` Stelian Pop
2007-01-05 2:20 ` MoRpHeUz
2007-01-05 17:11 ` Sony Vaio VGN-SZ340 (was Re: sonypc with Sony Vaio VGN-SZ1VP) Len Brown
2007-01-05 17:24 ` MoRpHeUz
2007-01-05 18:10 ` Len Brown
2007-01-06 4:09 ` Bjorn Helgaas
2007-01-11 19:52 ` Len Brown
2007-01-11 20:01 ` Alexey Starikovskiy
2007-01-05 0:11 ` sonypc with Sony Vaio VGN-SZ1VP Jan Engelhardt
2007-01-05 9:15 ` Mattia Dongili
2007-01-05 9:59 ` Stelian Pop
2007-01-04 23:34 ` Stelian Pop
2007-01-05 10:02 ` Stelian Pop
2007-01-05 12:13 ` Mattia Dongili
2007-01-05 14:23 ` Jan Engelhardt
2007-01-09 15:19 ` Luming Yu
-- strict thread matches above, loose matches on Subject: below --
2006-09-26 13:56 Andrea Gelmini
2006-09-26 16:29 ` Stelian Pop
2006-09-26 17:56 ` Ismail Donmez
2006-09-27 5:14 ` Andrew Morton
2006-09-27 5:59 ` Jan Engelhardt
2006-09-27 6:04 ` Len Brown
2006-09-27 7:50 ` Ismail Donmez
2006-09-28 15:48 ` Yu Luming
2006-09-27 16:26 ` Andrea Gelmini
2006-09-26 21:38 ` Andrea Gelmini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).