Hi,
I had also done a pnp patch for the smsc-ircc2 and irport 3 months ago.
Unfortunaly I don't remember where I put the patches, certainly on the
laptop that it is in my parent home.
> On Wed, Nov 17, 2004 at 03:20:47PM -0800, Jean Tourrilhes wrote:
> > Ville wrote :
> > > Add PnP support to smsc-ircc2 driver.
> > > Briefly tested with irdadump on a Dell Inpsiron 7000.
> >
> > OnThanks for the patch. I slightly moved you code around, you'll
> > find my version of your patch on my web page.
> >
> > OnNow, a few comments...
> >
> > On1) I don't have any SmSC chipset around, so I can't do any
> > testing. I would appreciate other people to test your patch. Also,
> > make sure I did not introduce mistakes in my version of the patch.
>
> Your version works fine (irdadump works).
>
> > On2) I tried to apply the same code to NSC. It did not manage to
> > read the ressource properly, and therefore the PnP code disabled the
> > hardware, and I was no longer able to get it running (short of a
> > reboot of the computer). The nsc-ircc has only one i/o region (dumb
> > nsc).
>
try to do an "echo auto > /sys/bus/pnp/device_number/resources"
It will reenable the device.
> I have a machine with nsc-ircc here so I think I'll try that too.
>
> > OnThe issue there is that if a smsc chipset has a valid PnP ID
> > but somehow the pnp_probe fails to set it up, then the regular probe
> > won't be able to configure it. This makes me nervous.
> >
Yes that's the problem this pnp, if the probe failed it disable the
device resource.
When I do my patch I encounter the problem : I called pnp driver after
smsc_ircc_look_for_chips, so all the resources where already reserved,
and the pnp probe failed and it disable the resource, and the device
found with the traditional smsc_ircc_look_for_chips doesn't work.
So in my patch if I register pnp devices, I don't run
smsc_ircc_look_for_chips like it is done for (ircc_fir>0)&&(ircc_sir>0)
case.
> > On3) If the ressources are markes as disabled, you just quit
> > with an error. Compouded with (2), this makes me doubly
> > nervous. Wouldn't it be possible to forcefully enable those
ressources ?
pnp should call automatiquely pnp_activate_dev() before probing the
driver, so the resource should be activated. Have you got an example
where the resource wheren't activated ?
> > OnThe idea there is that more and more IrDA devices are comming
> > disabled in BIOS with no BIOS entry to enable them. Enabling those
> > ressources would fix that and possible make smc-init redundant (I
wish).
>
> pnp_activate_dev() should probably be used to enable the device but
it was
> only used by ISAPNP drivers so I didn't use it in this patch.
>
> I must admit that I really don't know much about the PNP subsystem. I
> used the parport_pc driver as a guide. I've CC'd Adam Belay and
> linux-kernel in the hopes that someone can help with this stuff.
On Thu, Nov 18, 2004 at 07:42:07PM +0100, matthieu castet wrote:
> Hi,
>
> I had also done a pnp patch for the smsc-ircc2 and irport 3 months ago.
> Unfortunaly I don't remember where I put the patches, certainly on the
> laptop that it is in my parent home.
I've never seen you patches on the irda mailing list...
> try to do an "echo auto > /sys/bus/pnp/device_number/resources"
>
> It will reenable the device.
Thanks for the tip.
> > I have a machine with nsc-ircc here so I think I'll try that too.
> >
> > > OnThe issue there is that if a smsc chipset has a valid PnP ID
> > > but somehow the pnp_probe fails to set it up, then the regular probe
> > > won't be able to configure it. This makes me nervous.
> > >
> Yes that's the problem this pnp, if the probe failed it disable the
> device resource.
> When I do my patch I encounter the problem : I called pnp driver after
> smsc_ircc_look_for_chips, so all the resources where already reserved,
> and the pnp probe failed and it disable the resource, and the device
> found with the traditional smsc_ircc_look_for_chips doesn't work.
>
> So in my patch if I register pnp devices, I don't run
> smsc_ircc_look_for_chips like it is done for (ircc_fir>0)&&(ircc_sir>0)
> case.
smsc_ircc_look_for_chips won't re-register the devices
configured via PnP, as smsc_ircc_present won't be able to request the
region. So, I don't see the problem. And you could imagine having
multiple SMSC in the box, some PnP, some not.
Note that we could put the region check earlier, but I like
the fact that the driver is still able to probe completely the chip
even if the serial driver has grabbed the regions. Maybe we could
split the difference and request the FIR region early on (so to fail
on SMC devices already registered) and request the other ressources
late (so as to completely probe even when serial is loaded).
> > > On3) If the ressources are markes as disabled, you just quit
> > > with an error. Compouded with (2), this makes me doubly
> > > nervous. Wouldn't it be possible to forcefully enable those
> ressources ?
> pnp should call automatiquely pnp_activate_dev() before probing the
> driver, so the resource should be activated. Have you got an example
> where the resource wheren't activated ?
No, it was more that I don't understand what PnP does for
us. I don't have a SMS chipset to test on. Also, I would like to know
if it remove the need of smcinit.
Thanks, have fun...
Jean
Jean Tourrilhes wrote:
> On Thu, Nov 18, 2004 at 07:42:07PM +0100, matthieu castet wrote:
>
>>Hi,
>>
>>I had also done a pnp patch for the smsc-ircc2 and irport 3 months ago.
>>Unfortunaly I don't remember where I put the patches, certainly on the
>>laptop that it is in my parent home.
>
>
> I've never seen you patches on the irda mailing list...
>
>
When I wanted to send them, I didn't find them, and after that I forgot
them...
if you are still interested for the irport, I could try to ask someone
to send it to me.
>>>I have a machine with nsc-ircc here so I think I'll try that too.
>>>
>>>
>>>>OnThe issue there is that if a smsc chipset has a valid PnP ID
>>>>but somehow the pnp_probe fails to set it up, then the regular probe
>>>>won't be able to configure it. This makes me nervous.
>>>>
>>
>>Yes that's the problem this pnp, if the probe failed it disable the
>>device resource.
>>When I do my patch I encounter the problem : I called pnp driver after
>>smsc_ircc_look_for_chips, so all the resources where already reserved,
>>and the pnp probe failed and it disable the resource, and the device
>>found with the traditional smsc_ircc_look_for_chips doesn't work.
>>
>>So in my patch if I register pnp devices, I don't run
>>smsc_ircc_look_for_chips like it is done for (ircc_fir>0)&&(ircc_sir>0)
>>case.
>
>
> smsc_ircc_look_for_chips won't re-register the devices
> configured via PnP, as smsc_ircc_present won't be able to request the
> region. So, I don't see the problem. And you could imagine having
> multiple SMSC in the box, some PnP, some not.
Yes, it was just because it produce some warning message.
> Note that we could put the region check earlier, but I like
> the fact that the driver is still able to probe completely the chip
> even if the serial driver has grabbed the regions. Maybe we could
> split the difference and request the FIR region early on (so to fail
> on SMC devices already registered) and request the other ressources
> late (so as to completely probe even when serial is loaded).
>
>
>>>>On3) If the ressources are markes as disabled, you just quit
>>>>with an error. Compouded with (2), this makes me doubly
>>>>nervous. Wouldn't it be possible to forcefully enable those
>>
>>ressources ?
>>pnp should call automatiquely pnp_activate_dev() before probing the
>>driver, so the resource should be activated. Have you got an example
>>where the resource wheren't activated ?
>
>
> No, it was more that I don't understand what PnP does for
> us. I don't have a SMS chipset to test on. Also, I would like to know
> if it remove the need of smcinit.
>
PnP is easy to understand ;)
When you probe a device, it will activate a device with the best
configuration available.
When removing a device it will disable the resource of the device.
A driver could play a little with the resources configuration : try
another configuration, but it is not really need.
Also PnP can provide several id for a device : for example for my smsc
device, I have SMCf010 and PNP0510 or PNP0511. So in this case we should
load the smsc driver first, otherwise for example a pnp version of
irport could register the device and it is not available for smsc (PnP
will see that there is a driver attached, and not give it to the smsc
probe).
> Thanks, have fun...
>
> Jean
>
>
Matthieu
On Thu, Nov 18, 2004 at 08:49:50PM +0100, matthieu castet wrote:
> Jean Tourrilhes wrote:
> >On Thu, Nov 18, 2004 at 07:42:07PM +0100, matthieu castet wrote:
> >>>>On3) If the ressources are markes as disabled, you just quit
> >>>>with an error. Compouded with (2), this makes me doubly
> >>>>nervous. Wouldn't it be possible to forcefully enable those
> >>
> >>ressources ?
> >>pnp should call automatiquely pnp_activate_dev() before probing the
> >>driver, so the resource should be activated. Have you got an example
> >>where the resource wheren't activated ?
> >
> >
> > No, it was more that I don't understand what PnP does for
> >us. I don't have a SMS chipset to test on. Also, I would like to know
> >if it remove the need of smcinit.
> >
> PnP is easy to understand ;)
> When you probe a device, it will activate a device with the best
> configuration available.
So can we just remove the IORESOURCE_DISABLED tests?
And what about the pnp_*_valid() tests?
parport_pc (which I used as a guide) does both tests but 8250_pnp doesn't
do either.
--
Ville Syrj?l?
[email protected]
http://www.sci.fi/~syrjala/
On Thu, Nov 18, 2004 at 10:41:45PM +0200, Ville Syrj?l? wrote:
> On Thu, Nov 18, 2004 at 08:49:50PM +0100, matthieu castet wrote:
> > Jean Tourrilhes wrote:
> > >On Thu, Nov 18, 2004 at 07:42:07PM +0100, matthieu castet wrote:
> > >>>>On3) If the ressources are markes as disabled, you just quit
> > >>>>with an error. Compouded with (2), this makes me doubly
> > >>>>nervous. Wouldn't it be possible to forcefully enable those
> > >>
> > >>ressources ?
> > >>pnp should call automatiquely pnp_activate_dev() before probing the
> > >>driver, so the resource should be activated. Have you got an example
> > >>where the resource wheren't activated ?
> > >
> > >
> > > No, it was more that I don't understand what PnP does for
> > >us. I don't have a SMS chipset to test on. Also, I would like to know
> > >if it remove the need of smcinit.
> > >
> > PnP is easy to understand ;)
> > When you probe a device, it will activate a device with the best
> > configuration available.
>
> So can we just remove the IORESOURCE_DISABLED tests?
>
> And what about the pnp_*_valid() tests?
>
> parport_pc (which I used as a guide) does both tests but 8250_pnp doesn't
> do either.
Parport_pc uses them because resources could potentially be disabled, but the
parport could still be functional. Therefore, it must check. It is probably
ok to not check on most hardware. Nonetheless, it's best to play it safe, and
always verify the resource configuration.
Thanks,
Adam
mc> try to do an "echo auto > /sys/bus/pnp/device_number/resources"
mc>
mc> It will reenable the device.
I tried this on my Toshiba Satellite 1800-314 and the device gets IO
resources but is still disabled. echo activate > ... will enable it but
the smc-ircc2 driver still finds that the device is disabled (in
2.6.10-rc2+yesterdays BK):
nartsiss:~# cat /sys/bus/pnp/devices/00\:0a/options
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
nartsiss:~# cat /sys/bus/pnp/devices/00\:0a/resources
state = disabled
nartsiss:~# echo auto > /sys/bus/pnp/devices/00\:0a/resources
nartsiss:~# cat /sys/bus/pnp/devices/00\:0a/resources
state = disabled
io 0x2e8-0x2ef
nartsiss:~# echo activate > /sys/bus/pnp/devices/00\:0a/resources
nartsiss:~# cat /sys/bus/pnp/devices/00\:0a/resources
state = active
io 0x2e8-0x2ef
nartsiss:~# modprobe smsc-ircc2
FATAL: Error inserting smsc_ircc2
(/lib/modules/2.6.10-rc2/kernel/drivers/net/irda/smsc-ircc2.ko): No such device
nartsiss:~# dmesg|tail -5
pnp: Device 00:0a activated.
NET: Registered protocol family 23
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
smsc_superio_flat(): fir: 0x00, sir: 0x2e8, dma: 15, irq: 0, mode: 0x02
Looks like there is also a enable/disable bit in the actual LPC device,
or maybe it needs also a fir address and/or irq?
--
Meelis Roos
Meelis Roos wrote:
> mc> try to do an "echo auto > /sys/bus/pnp/device_number/resources"
> mc>
> mc> It will reenable the device.
>
> I tried this on my Toshiba Satellite 1800-314 and the device gets IO
> resources but is still disabled. echo activate > ... will enable it but
> the smc-ircc2 driver still finds that the device is disabled (in
> 2.6.10-rc2+yesterdays BK):
>
> nartsiss:~# cat /sys/bus/pnp/devices/00\:0a/options
> Dependent: 01 - Priority acceptable
> port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 02 - Priority acceptable
> port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 03 - Priority acceptable
> port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 04 - Priority acceptable
> port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
that's very strange : you must have 2 io entries, 1 dma entry and an irq
entry.
Could you try pnpacpi from mm series ?
Any warning from pnpbios at startup ?
A laptop of the friend have wrong pnpbios entries...
Also make sure you don't force in your bios the device to be a sir device.
> nartsiss:~# cat /sys/bus/pnp/devices/00\:0a/resources
> state = disabled
> nartsiss:~# echo auto > /sys/bus/pnp/devices/00\:0a/resources
> nartsiss:~# cat /sys/bus/pnp/devices/00\:0a/resources
> state = disabled
> io 0x2e8-0x2ef
activate is not important : here pnp had found the io resources
> nartsiss:~# echo activate > /sys/bus/pnp/devices/00\:0a/resources
> nartsiss:~# cat /sys/bus/pnp/devices/00\:0a/resources
> state = active
> io 0x2e8-0x2ef
^^^^^^^^^^^^^^^^
> nartsiss:~# modprobe smsc-ircc2
> FATAL: Error inserting smsc_ircc2
> (/lib/modules/2.6.10-rc2/kernel/drivers/net/irda/smsc-ircc2.ko): No such device
> nartsiss:~# dmesg|tail -5
> pnp: Device 00:0a activated.
> NET: Registered protocol family 23
> found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> smsc_superio_flat(): IrDA not enabled
> smsc_superio_flat(): fir: 0x00, sir: 0x2e8, dma: 15, irq: 0, mode: 0x02
>
>
> Looks like there is also a enable/disable bit in the actual LPC device,
> or maybe it needs also a fir address and/or irq?
>
matthieu castet wrote:
> Meelis Roos wrote:
>
>> mc> try to do an "echo auto > /sys/bus/pnp/device_number/resources"
>> mc> mc> It will reenable the device.
>>
>> I tried this on my Toshiba Satellite 1800-314 and the device gets IO
>> resources but is still disabled. echo activate > ... will enable it but
>> the smc-ircc2 driver still finds that the device is disabled (in
>> 2.6.10-rc2+yesterdays BK):
>>
>> nartsiss:~# cat /sys/bus/pnp/devices/00\:0a/options
>> Dependent: 01 - Priority acceptable
>> port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
>> Dependent: 02 - Priority acceptable
>> port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
>> Dependent: 03 - Priority acceptable
>> port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
>> Dependent: 04 - Priority acceptable
>> port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
>
> that's very strange : you must have 2 io entries, 1 dma entry and an irq
> entry.
> Could you try pnpacpi from mm series ?
no need : it is in rc2.
So do you use pnpacpi ?
If so, could you send your dsdt and try with pnpbios?
Matthieu
>> that's very strange : you must have 2 io entries, 1 dma entry and an irq
>> entry.
>> Could you try pnpacpi from mm series ?
> no need : it is in rc2.
> So do you use pnpacpi ?
> If so, could you send your dsdt and try with pnpbios?
# CONFIG_ISAPNP is not set
CONFIG_PNPBIOS=y
CONFIG_PNPBIOS_PROC_FS=y
CONFIG_PNPACPI=y
dmesg tells
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 13 devices
PnPBIOS: Disabled by ACPI
Will try disabling pnpacpi today.
How do I extract DSDT?
--
Meelis Roos ([email protected]) http://www.cs.ut.ee/~mroos/
> So do you use pnpacpi ?
> If so, could you send your dsdt and try with pnpbios?
DSDT is here: http://www.cs.ut.ee/~mroos/toshsat1800_dsdt.img
--
Meelis Roos ([email protected])
Meelis Roos wrote:
>> So do you use pnpacpi ?
>> If so, could you send your dsdt and try with pnpbios?
>
>
> DSDT is here: http://www.cs.ut.ee/~mroos/toshsat1800_dsdt.img
>
hum, your bios seem to build dynamically the resources (need an acpi
expert for confirmation)
Could you send me the result of : "for i in /sys/bus/pnp/devices/*; do
cat $i/id $i/options; done" in order to see if other devices have
missing resources ?
> Could you send me the result of : "for i in /sys/bus/pnp/devices/*; do cat
> $i/id $i/options; done" in order to see if other devices have missing
> resources ?
PNP0c01
PNP0200
PNP0800
PNP0c04
PNP0303
PNP0f13
PNP0b00
PNP0c02
PNP0700
port 0x3f0-0x3f0, align 0x0, size 0x6, 16-bit address decoding
port 0x3f7-0x3f7, align 0x0, size 0x1, 16-bit address decoding
irq 6 High-Edge
dma 2 8-bit compatible
PNP0501
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
SMCf010
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
PNP0401
Dependent: 01 - Priority acceptable
port 0x378-0x378, align 0x0, size 0x3, 16-bit address decoding
port 0x778-0x778, align 0x0, size 0x3, 16-bit address decoding
irq 7 High-Edge
Dependent: 02 - Priority acceptable
port 0x278-0x278, align 0x0, size 0x3, 16-bit address decoding
port 0x678-0x678, align 0x0, size 0x3, 16-bit address decoding
irq 5 High-Edge
Dependent: 03 - Priority acceptable
port 0x3bc-0x3bc, align 0x0, size 0x3, 16-bit address decoding
port 0x7bc-0x7bc, align 0x0, size 0x3, 16-bit address decoding
irq 7 High-Edge
TOS6200
--
Meelis Roos ([email protected])
Meelis Roos wrote:
>> Could you send me the result of : "for i in /sys/bus/pnp/devices/*; do
>> cat $i/id $i/options; done" in order to see if other devices have
>> missing resources ?
>
>
> PNP0c01
> PNP0200
> PNP0800
> PNP0c04
> PNP0303
> PNP0f13
> PNP0b00
> PNP0c02
> PNP0700
> port 0x3f0-0x3f0, align 0x0, size 0x6, 16-bit address decoding
> port 0x3f7-0x3f7, align 0x0, size 0x1, 16-bit address decoding
> irq 6 High-Edge
> dma 2 8-bit compatible
floppy : seem ok
> PNP0501
> Dependent: 01 - Priority acceptable
> port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 02 - Priority acceptable
> port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 03 - Priority acceptable
> port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 04 - Priority acceptable
> port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
serial miss irq
> SMCf010
> Dependent: 01 - Priority acceptable
> port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 02 - Priority acceptable
> port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 03 - Priority acceptable
> port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 04 - Priority acceptable
> port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
irda : miss io,irq,dma
> PNP0401
> Dependent: 01 - Priority acceptable
> port 0x378-0x378, align 0x0, size 0x3, 16-bit address decoding
> port 0x778-0x778, align 0x0, size 0x3, 16-bit address decoding
> irq 7 High-Edge
> Dependent: 02 - Priority acceptable
> port 0x278-0x278, align 0x0, size 0x3, 16-bit address decoding
> port 0x678-0x678, align 0x0, size 0x3, 16-bit address decoding
> irq 5 High-Edge
> Dependent: 03 - Priority acceptable
> port 0x3bc-0x3bc, align 0x0, size 0x3, 16-bit address decoding
> port 0x7bc-0x7bc, align 0x0, size 0x3, 16-bit address decoding
> irq 7 High-Edge
parallel port: miss dma
> TOS6200
>
Could it be an acpi parsing problem ?
Is there a easy way to use ACPI_DUMP_RESOURCE_LIST in order to find all
the resource find by acpi in order to see if it is an acpi problem or a
pnpacpi problem ?
Matthieu
PS : I CC the message to acpi people : look
http://marc.theaimsgroup.com/?t=110075024500002&r=1&w=2 for the begining.
I tried it with pnpbios (acpi=off) and it started to work after auto and
activate (but not with auto alone):
nartsiss:/# modprobe smsc-ircc2
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
FATAL: Error inserting smsc_ircc2 (/lib/modules/2.6.10-rc2/kernel/drivers/net/irda/smsc-ircc2.ko): No such device
nartsiss:/# echo activate > resources
pnp: Device 00:0f activated.
nartsiss:/# modprobe smsc-ircc2
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): fir: 0x2e8, sir: 0x100, dma: 03, irq: 5, mode: 0x0e
SMsC IrDA Controller found
IrCC version 2.0, firport 0x2e8, sirport 0x100 dma=3, irq=5
No transceiver found. Defaulting to Fast pin select
IrDA: Registered device irda0
>>> Could you send me the result of : "for i in /sys/bus/pnp/devices/*; do cat
>>> $i/id $i/options; done" in order to see if other devices have missing
>>> resources ?
The output with pnpbios is below for comparision.
>> PNP0c01
>> PNP0200
>> PNP0800
>> PNP0c04
>> PNP0303
>> PNP0f13
>> PNP0b00
>> PNP0c02
>> PNP0700
>> port 0x3f0-0x3f0, align 0x0, size 0x6, 16-bit address decoding
>> port 0x3f7-0x3f7, align 0x0, size 0x1, 16-bit address decoding
>> irq 6 High-Edge
>> dma 2 8-bit compatible
> floppy : seem ok
>> PNP0501
>> Dependent: 01 - Priority acceptable
>> port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
>> Dependent: 02 - Priority acceptable
>> port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
>> Dependent: 03 - Priority acceptable
>> port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
>> Dependent: 04 - Priority acceptable
>> port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
> serial miss irq
>> SMCf010
>> Dependent: 01 - Priority acceptable
>> port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
>> Dependent: 02 - Priority acceptable
>> port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
>> Dependent: 03 - Priority acceptable
>> port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
>> Dependent: 04 - Priority acceptable
>> port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
> irda : miss io,irq,dma
>> PNP0401
>> Dependent: 01 - Priority acceptable
>> port 0x378-0x378, align 0x0, size 0x3, 16-bit address decoding
>> port 0x778-0x778, align 0x0, size 0x3, 16-bit address decoding
>> irq 7 High-Edge
>> Dependent: 02 - Priority acceptable
>> port 0x278-0x278, align 0x0, size 0x3, 16-bit address decoding
>> port 0x678-0x678, align 0x0, size 0x3, 16-bit address decoding
>> irq 5 High-Edge
>> Dependent: 03 - Priority acceptable
>> port 0x3bc-0x3bc, align 0x0, size 0x3, 16-bit address decoding
>> port 0x7bc-0x7bc, align 0x0, size 0x3, 16-bit address decoding
>> irq 7 High-Edge
> parallel port: miss dma
>> TOS6200
>>
PNP0c01
PNP0200
PNP0000
PNP0100
PNP0800
PNP0c04
PNP0303
PNP0f13
irq 12 High-Edge
PNP0b00
PNP0c02
PNP0700
port 0x3f0-0x3f0, align 0x0, size 0x6, 16-bit address decoding
port 0x3f7-0x3f7, align 0x0, size 0x1, 16-bit address decoding
irq 6 High-Edge
dma 2 8-bit byte-count compatible
PNP0501
irq 3,4,5,7,10,11 High-Edge
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
SMCf010
PNP0510
port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding
irq 3,4,5,7,10,11 High-Edge
dma 1,2,3 16-bit byte-count compatible
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
PNP0401
dma 1,2,3 8-bit byte-count compatible
Dependent: 01 - Priority acceptable
port 0x378-0x378, align 0x0, size 0x3, 16-bit address decoding
port 0x778-0x778, align 0x0, size 0x3, 16-bit address decoding
irq 7 High-Edge
Dependent: 02 - Priority acceptable
port 0x278-0x278, align 0x0, size 0x3, 16-bit address decoding
port 0x678-0x678, align 0x0, size 0x3, 16-bit address decoding
irq 5 High-Edge
Dependent: 03 - Priority acceptable
port 0x3bc-0x3bc, align 0x0, size 0x3, 16-bit address decoding
port 0x7bc-0x7bc, align 0x0, size 0x3, 16-bit address decoding
irq 7 High-Edge
PNP0a03
PNP0e03
PNP0e00
Dependent: 01 - Priority acceptable
port 0x3e0-0x3e0, align 0x0, size 0x2, 16-bit address decoding
irq <none> High-Edge
Dependent: 02 - Priority acceptable
port 0x3e0-0x3e0, align 0x0, size 0x2, 16-bit address decoding
irq 3,4,5,7,10,11 High-Edge
--
Meelis Roos ([email protected])
Meelis Roos wrote:
>
> I tried it with pnpbios (acpi=off) and it started to work after auto and
> activate (but not with auto alone):
>
> nartsiss:/# modprobe smsc-ircc2
> found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> smsc_superio_flat(): IrDA not enabled
> smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
> FATAL: Error inserting smsc_ircc2
> (/lib/modules/2.6.10-rc2/kernel/drivers/net/irda/smsc-ircc2.ko): No such
> device
> nartsiss:/# echo activate > resources
> pnp: Device 00:0f activated.
> nartsiss:/# modprobe smsc-ircc2
> found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> smsc_superio_flat(): fir: 0x2e8, sir: 0x100, dma: 03, irq: 5, mode: 0x0e
> SMsC IrDA Controller found
> IrCC version 2.0, firport 0x2e8, sirport 0x100 dma=3, irq=5
> No transceiver found. Defaulting to Fast pin select
> IrDA: Registered device irda0
>
>>>> Could you send me the result of : "for i in /sys/bus/pnp/devices/*;
>>>> do cat $i/id $i/options; done" in order to see if other devices have
>>>> missing resources ?
>
>
> The output with pnpbios is below for comparision.
>
[..]
Ok, I have catch the problem : the pnpacpi parser supposed that are no
resource after EndDependentFn.
Could you try this patch with pnpacpi?
Signed-Off-By: Matthieu Castet <[email protected]>
On Sat, Nov 20, 2004 at 01:09:36AM +0200, Meelis Roos wrote:
>
> I tried it with pnpbios (acpi=off) and it started to work after auto and
> activate (but not with auto alone):
>
> nartsiss:/# modprobe smsc-ircc2
> found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> smsc_superio_flat(): IrDA not enabled
> smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
> FATAL: Error inserting smsc_ircc2
> (/lib/modules/2.6.10-rc2/kernel/drivers/net/irda/smsc-ircc2.ko): No such
> device
> nartsiss:/# echo activate > resources
> pnp: Device 00:0f activated.
> nartsiss:/# modprobe smsc-ircc2
> found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> smsc_superio_flat(): fir: 0x2e8, sir: 0x100, dma: 03, irq: 5, mode: 0x0e
> SMsC IrDA Controller found
> IrCC version 2.0, firport 0x2e8, sirport 0x100 dma=3, irq=5
> No transceiver found. Defaulting to Fast pin select
> IrDA: Registered device irda0
It is using the legacy probe instead of the pnp probe. Did you actually
apply the pnp patch?
I'm not entirely sure what has been discussed since somebody removed
me from the CC list...
--
Ville Syrj?l?
[email protected]
http://www.sci.fi/~syrjala/
Ville Syrj?l? wrote:
> On Sat, Nov 20, 2004 at 01:09:36AM +0200, Meelis Roos wrote:
>
>>I tried it with pnpbios (acpi=off) and it started to work after auto and
>>activate (but not with auto alone):
>>
>>nartsiss:/# modprobe smsc-ircc2
>>found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
>>smsc_superio_flat(): IrDA not enabled
>>smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
>>FATAL: Error inserting smsc_ircc2
>>(/lib/modules/2.6.10-rc2/kernel/drivers/net/irda/smsc-ircc2.ko): No such
>>device
>>nartsiss:/# echo activate > resources
>>pnp: Device 00:0f activated.
>>nartsiss:/# modprobe smsc-ircc2
>>found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
>>smsc_superio_flat(): fir: 0x2e8, sir: 0x100, dma: 03, irq: 5, mode: 0x0e
>>SMsC IrDA Controller found
>> IrCC version 2.0, firport 0x2e8, sirport 0x100 dma=3, irq=5
>>No transceiver found. Defaulting to Fast pin select
>>IrDA: Registered device irda0
>
>
> It is using the legacy probe instead of the pnp probe. Did you actually
> apply the pnp patch?
>
No he doesn't use the pnp patch : only latest snapshot for the stable
Linux kernel.
But there is still the problem with pnpacpi that is needed to fixed.
> I'm not entirely sure what has been discussed since somebody removed
> me from the CC list...
>
> Ok, I have catch the problem : the pnpacpi parser supposed that are no
> resource after EndDependentFn.
>
> Could you try this patch with pnpacpi?
Yes, it gives full options (and resources after "auto"). But smsc-ircc2
still does not load even after "activate" with pnpacpi. It loads with
pnpbios after auto and activate.
--
Meelis Roos ([email protected])
Meelis Roos wrote:
>> Ok, I have catch the problem : the pnpacpi parser supposed that are no
>> resource after EndDependentFn.
>>
>> Could you try this patch with pnpacpi?
>
>
> Yes, it gives full options (and resources after "auto"). But smsc-ircc2
> still does not load even after "activate" with pnpacpi. It loads with
> pnpbios after auto and activate.
>
thanks
Could I have the log from smsc-ircc2 when it failed with pnpacpi ?
regards
Matthieu
> Could I have the log from smsc-ircc2 when it failed with pnpacpi ?
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
--
Meelis Roos ([email protected])
Meelis Roos wrote:
>> Could I have the log from smsc-ircc2 when it failed with pnpacpi ?
>
>
> found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> smsc_superio_flat(): IrDA not enabled
> smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
>
Thanks, it seem that pnpacpi_set_resources have a problem.
I hope Shaohua Li (who write it) could ckeck it.
regards
Matthieu
Meelis Roos wrote:
>> Could I have the log from smsc-ircc2 when it failed with pnpacpi ?
>
>
> found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> smsc_superio_flat(): IrDA not enabled
> smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
>
just for curiosity, when you have time, could try pnpacpi and jean PNP
smsc patch?
It sould find the correct resources because there are provided by PnP
layer, but if the resources are not well allocated by PnPacpi, the
device shouldn't work.
thanks
Matthieu
On Mon, 2004-11-22 at 04:20, matthieu castet wrote:
> Meelis Roos wrote:
> >> Could I have the log from smsc-ircc2 when it failed with pnpacpi ?
> >
> >
> > found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> > smsc_superio_flat(): IrDA not enabled
> > smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
> >
> just for curiosity, when you have time, could try pnpacpi and jean PNP
> smsc patch?
>
> It sould find the correct resources because there are provided by PnP
> layer, but if the resources are not well allocated by PnPacpi, the
> device shouldn't work.
Could you please attach the output of 'cat 00:0a/resources' (0a is the
device, right?). ACPI spec said set resource should be according to the
output of current resource. That is we should build a template according
to current resource (_CRS). If _CRS doesn't return a correct resource
templete, set resource will fail.
Adam, I think a boot option (such as pnpacpi=off) is required. Users
possibly want to use pnpbios or BIOS is buggy.
Thanks,
Shaohua
> Adam, I think a boot option (such as pnpacpi=off) is required. Users
> possibly want to use pnpbios or BIOS is buggy.
Yes, agreed. Right now just using ACPI turns pnpbios off, it probably
should be using pnpacpi that turns pnpbios off. And turning pnpacpi off
should be made possible.
--
Meelis Roos ([email protected]) http://www.cs.ut.ee/~mroos/
> Adam, I think a boot option (such as pnpacpi=off) is required. Users
> possibly want to use pnpbios or BIOS is buggy.
Additionally, I see more pnp devices with pnpbios (16) than with pnpbios
(13). Is this normal?
--
Meelis Roos ([email protected])
> just for curiosity, when you have time, could try pnpacpi and jean PNP smsc
> patch?
Couldn't find it at the first glance from my list archive - where can I
get it?
--
Meelis Roos ([email protected])
> Could you please attach the output of 'cat 00:0a/resources' (0a is the
> device, right?). ACPI spec said set resource should be according to the
> output of current resource. That is we should build a template according
> to current resource (_CRS). If _CRS doesn't return a correct resource
> templete, set resource will fail.
resources after auto and activate and options are now exactly the same
after the pnpacpi patch:
resources:
state = active
io 0x100-0x107
io 0x2e8-0x2ef
irq 5
dma 3
options:
port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding
irq 3,4,5,7,10,11 High-Edge
dma 1,2,3 16-bit compatible
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
With pnpbios, module loading gives this:
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): fir: 0x2e8, sir: 0x100, dma: 03, irq: 5, mode: 0x0e
SMsC IrDA Controller found
IrCC version 2.0, firport 0x2e8, sirport 0x100 dma=3, irq=5
No transceiver found. Defaulting to Fast pin select
divert: not allocating divert_blk for non-ethernet device irda0
IrDA: Registered device irda0
With pnpacpi, module loading gives this:
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
Haven't tried Villes patch yet, will do today evening.
--
Meelis Roos ([email protected])
Meelis Roos wrote:
>> could you try this patch with the previous one. (You must enable ACPI
>> DEBUG in kernel config)
>
>
> After fixing one res -> resource, it compiled.
Oups that's the wrong fix : there was a line missing in my previous patch
>
> The output is uninteresting - it only prints one debug message during
> echoing activate to resources:
>
That's because resource point at the end of the resources list, so there
is nothing to read. With this patch, you should see something.
> ******845*******
> pnp: Device 00:0a activated.
> NET: Registered protocol family 23
> found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> smsc_superio_flat(): IrDA not enabled
> smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
>
thanks for testing
Matthieu
Meelis Roos wrote:
>> Could you please attach the output of 'cat 00:0a/resources' (0a is the
>> device, right?). ACPI spec said set resource should be according to the
>> output of current resource. That is we should build a template according
>> to current resource (_CRS). If _CRS doesn't return a correct resource
>> templete, set resource will fail.
>
>
Hi,
could you try this patch with the previous one. (You must enable ACPI
DEBUG in kernel config)
When you activate the device, it sould print usefull information.
Could attach the output, please.
Matthieu
> could you try this patch with the previous one. (You must enable ACPI DEBUG
> in kernel config)
After fixing one res -> resource, it compiled.
The output is uninteresting - it only prints one debug message during
echoing activate to resources:
******845*******
pnp: Device 00:0a activated.
NET: Registered protocol family 23
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
--
Meelis Roos ([email protected])
> That's because resource point at the end of the resources list, so there is
> nothing to read. With this patch, you should see something.
On bootup there are loads on lines 167 and 472.
On auto there are none.
On activate there are
******846*******
pnp: Device 00:0a activated.
On modprobe smsc-ircc2 there are no more debug lines, just
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
And I checked that I am using the new patch.
--
Meelis Roos ([email protected])
Hi,
Meelis Roos wrote:
>> That's because resource point at the end of the resources list, so
>> there is nothing to read. With this patch, you should see something.
>
>
> On bootup there are loads on lines 167 and 472.
>
> On auto there are none.
>
> On activate there are
> ******846*******
> pnp: Device 00:0a activated.
>
> On modprobe smsc-ircc2 there are no more debug lines, just
> found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> smsc_superio_flat(): IrDA not enabled
> smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
>
> And I checked that I am using the new patch.
>
thanks.
it seems there is no resource in your __CRS. Like Shaohua said the acpi
spec say that it must return valid template even if the device is
disable [1].
Just for confirmation, could you try this patch. It should enable
pnp_dbg message and print your _CRS when you activate the device.
If there is nothing between ******574******* and ******857*******, you
bios is likely broken.
thanks
Matthieu CASTET
[1]
If a device is disabled, then _CRS returns a valid resource template for
the device, but the actual
resource assignments in the return byte stream are ignored. If the
device is disabled when _CRS is called, it
must remain disabled.
> Just for confirmation, could you try this patch. It should enable pnp_dbg
> message and print your _CRS when you activate the device.
> If there is nothing between ******574******* and ******857*******, you bios
> is likely broken.
activate:
******574*******
pnp: Res cnt 4
pnp: res cnt 4
pnp: Encode io
pnp: Encode irq
pnp: Encode io
pnp: Encode dma
******857*******
pnp: Device 00:0a activated.
So it appears that there is something between 574 and 857.
modprobe is the same:
NET: Registered protocol family 23
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
--
Meelis Roos ([email protected])
Meelis Roos wrote:
>> Just for confirmation, could you try this patch. It should enable
>> pnp_dbg message and print your _CRS when you activate the device.
>> If there is nothing between ******574******* and ******857*******, you
>> bios is likely broken.
>
>
> activate:
> ******574*******
> pnp: Res cnt 4
> pnp: res cnt 4
> pnp: Encode io
> pnp: Encode irq
> pnp: Encode io
> pnp: Encode dma
> ******857*******
> pnp: Device 00:0a activated.
>
> So it appears that there is something between 574 and 857.
>
Are you sure you have enable ACPI DEBUG ?
You should have CONFIG_ACPI_DEBUG=y in your .config
>
> modprobe is the same:
> NET: Registered protocol family 23
> found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> smsc_superio_flat(): IrDA not enabled
> smsc_superio_flat(): fir: 0x00, sir: 0x00, dma: 15, irq: 0, mode: 0x02
>
matthieu castet wrote:
> Meelis Roos wrote:
>
>>> Just for confirmation, could you try this patch. It should enable
>>> pnp_dbg message and print your _CRS when you activate the device.
>>> If there is nothing between ******574******* and ******857*******,
>>> you bios is likely broken.
>>
>>
>>
>> activate:
>> ******574*******
>> pnp: Res cnt 4
>> pnp: res cnt 4
>> pnp: Encode io
>> pnp: Encode irq
>> pnp: Encode io
>> pnp: Encode dma
>> ******857*******
>> pnp: Device 00:0a activated.
>>
>> So it appears that there is something between 574 and 857.
>>
> Are you sure you have enable ACPI DEBUG ?
> You should have CONFIG_ACPI_DEBUG=y in your .config
>
>
With this patch, it should be work better (no need to remove the
previous patch)
Matthieu
PS : I should find a better way to make patch....
> Are you sure you have enable ACPI DEBUG ?
Oops, I did not. Now with ACPi DEBUG enabled and the Makefile patch
applied:
activate:
******574*******
Resource structure 0.
Io Resource
16 bit decode
Range minimum base: 00000000
Range maximum base: 00000000
Alignment: 00000001
Range Length: 00000000
Resource structure 1.
IRQ Resource
Edge Triggered
Active High
Exclusive
0 Interrupts ( )
Resource structure 2.
Io Resource
16 bit decode
Range minimum base: 00000000
Range maximum base: 00000000
Alignment: 00000001
Range Length: 00000000
Resource structure 3.
DMA Resource
Compatibility mode
Not a Bus Master
16 bit only transfer
Number of Channels: 0 ( )
Resource structure 4.
end_tag Resource
pnp: Res cnt 4
pnp: res cnt 4
pnp: Encode io
pnp: Encode irq
pnp: Encode io
pnp: Encode dma
******857*******
Resource structure 0.
Io Resource
16 bit decode
Range minimum base: 00000100
Range maximum base: 00000107
Alignment: 00000000
Range Length: 00000008
Resource structure 1.
IRQ Resource
Edge Triggered
Active High
Exclusive
1 Interrupts ( 5 )
Resource structure 2.
Io Resource
16 bit decode
Range minimum base: 000002E8
Range maximum base: 000002EF
Alignment: 00000000
Range Length: 00000008
Resource structure 3.
DMA Resource
Compatibility mode
Not a Bus Master
16 bit only transfer
Number of Channels: 1 ( 3 )
Resource structure 4.
end_tag Resource
pnp: Device 00:0a activated.
modprobe is still the same.
--
Meelis Roos ([email protected])