[Prism54-devel] Re: device soft reset timed out on ixdp425

[Luis R. Rodriguez]

Lai,

On Mon, Feb 02, 2004 at 02:57:21PM +0800, ??(Lai Li) wrote:
> 2.4.22 but i add firmware_class.c
> because the driver will need it!!
>   ----- Original Message ----- 
>   From: Clint Adams 
>   To: Lai Li 
>   Cc: prism54-devel@prism54.org 
>   Sent: Monday, February 02, 2004 1:04 PM
>   Subject: Re: [Prism54-devel] Re: device soft reset timed out on ixdp425
> 
> 
>   > i found that the function prism54_mib_init() in isl_ioctl.c was being
>   > queued 
>   > to kernel task_queue,and witch is not be executed.


FYI, some of this information may be inaccurate since our experience
with the card/driver is purely out of trial and error since
Globespanvirata has not given us clearance to obtain the chipset's
specs.

--

The error message you see pops out because we've told the card to
complete a soft reset [isl38xx_interface_reset in
isl_38xx.c] but the driver is determining the reset never completed.
Since the driver detects this, it bails out of bringing the interface
up and never runs prism54_mib_init.

Our driver detects if the soft reset completed by enabling the 
ISL38XX_INT_IDENT_INIT interrupt [done at the end of
isl38xx_interface_reset]. Enabling this interrupt on the card 
will make the card pass a special IRQ when this task was completed. 
When our driver detects this IRQ was passed, it then flags that 
the operation was completed [islpci_interrupt in islpci_dev.c]. 

I'm not sure but I do leave open the chances that the IRQ is setting off
before we are enabling the detection of the interrupt. If this is the 
case then you can try to enable the ISL38XX_INT_IDENT_INIT at the
beginning of the soft reset [isl38xx_interface_reset] instead of the
end, where we currently have it. 

If you want to follow the chain of the events that take place just take
note that prism54_probe occurs first, then islpci_open does once the
user ifconfig ethx up's the device.

It *may* be that you really do have a fauly Cardbus socket or card. At
least this was the case for me. I was able to determine this by
increasing the schedule_timeout a bit (HZ*6) value and increasing the 
count max value in the for loop at the end of islpci_reset. What I did
was bring up the interface (ifconfig eth1 up) and I had another window
with `tail -f /var/log/kern.log`. If I wobbled the card the interrupt 
would go through. So my card works, but my socket is messed up.

Anyway, all this is just to have the driver act *appropriately*. Should
you want to be aventerous you can just minimize islpci_reset_if so that
it doesn't wait for the ISL38XX_INT_IDENT_INIT interrupt and just
proceeds *assuming* the soft reset completed successfully.  You can do
this by having a minimalistic islpci_reset_if like the one that follows:

--
static int
islpci_reset_if(islpci_private *priv, int init_interrupt)
{
	if (init_interrupt)
                isl38xx_interface_reset(priv->device_base,
			priv->device_host_address); 
	islpci_set_state(priv, PRV_STATE_INIT);
	/* Wait a bit, just to assume the soft reset went through OK,
	 * decrease at your own will */
	udelay(ISL38XX_WRITEIO_DELAY*5);
	prism54_mib_init_work(priv);
	islpci_set_state(priv, PRV_STATE_READY);
	return 0;
}			
--

A side note is that we have similar wait paranoia behaviour for 
islpci_mgt_transaction in islpci_dev.c so don't be stranged if you see 
a next "ethx: timeout waiting for mgmt response xxxx, trigging device"
message.

Feel free to try the above suggestions then (separately):
1. Move the ISL38XX_INT_IDENT_INIT interrupt interrupt at the
beginning of isl38xx_interface_reset in isl_38xx.c 
2. Don't do the check for completion in islpci_reset_if, assume the 
soft reset went through fine.

Let us know how it went.

	Luis