With some kernel configuration the previous locking policy can
generate a deadlock on the spec->irq_lock spinlock.

For example, this will happen sistematically if the option
CONFIG_DEBUG_SHIRQ_FIXME is enabled. In this case, the handler
is called immediatly an it is not a separeted thread.

This patch move out from the locking section what doesn't need
protection and is 'cause' of the deadlock.

The deadlock was introduced with patch d4bbcc73 by using a large
locking section. In realty the PCI request_irq is protected
anyway thanks to the proctection of the variable 'first_time' and
the 'spec_vic_irq_request' function.

[more explaination about patch d4bbcc73]
The purpose of that patch was to protect the initialization of
the first VIC handler and the release of the last one. It was
happening that while we are releasing the last VIC handler,
some one was registering a new one but the spec->vic is still there.
The result was that sometimes the PCI handler was removed
(last VIC handler) but not re-requested for the incoming request.
Signen-off-by: Federico Vaga <federico.vaga@cern.ch>