Commit Graph

7 Commits

Author SHA1 Message Date
David Vrabel c2059b2e0b [PATCH] yenta: fix build if YENTA && !CARDBUS
(struct pcmcia_socket).tune_bridge only exists if CONFIG_CARDBUS is set
but building yenta_socket without CardBus is valid.

Signed-off-by: David Vrabel <dvrabel@arcom.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-08 14:53:31 -07:00
Daniel Ritz 6c1a10dba9 [PATCH] yenta: add support for more TI bridges
Support some more TI cardbus bridges.  most of them are multifunction
devices which adds 1394 controllers, smartcard readers etc.  this could
also help with the various problems with the XX21 controllers seen on the
linux-pcmcia list.

Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2005-09-26 13:11:27 +02:00
Daniel Ritz 8c3520d4eb [PATCH] yenta: auto-tune EnE bridges for CardBus cards
Echo Audio cardbus products are known to be incompatible with EnE bridges.
in order to maybe solve the problem a EnE specific test bit has to be set,
another cleared...but other setups have a good chance to break when just
forcing the bits.  so do the whole thingy automatically.

The patch adds a hook in cb_alloc() that allows special tuning for the
different chipsets.  for ene just match the Echo products and set/clear the
test bits, defaults to do the same thing as w/o the patch to not break
working setups.

Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Cc: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
2005-09-26 13:09:20 +02:00
Dominik Brodowski 89b39f5d8d [PATCH] yenta: don't depend on CardBus
As a follow-up, we can allow the yenta-driver to be limited to PCMCIA
operation.

Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-07 18:24:07 -07:00
Daniel Ritz fa912bcb06 [PATCH] yenta TI: turn off interrupts during card power-on #2
- make boot-up card recognition more reliable (ie.  redo interrogation
  always if there is no valid 'card inserted' state) (and yes, i saw it
  happening on an o2micro controller that both CB_CBARD and CB_16BITCARD
  bits were set at the same time)

- also redo interrogation before probing the ISA interrupts.  it's safer
  to do the probing with the socket in a clean state.

- make card insert detect more reliable.  yenta_get_status() now returns
  SS_PENDING as long as the card is not completley inserted and one of the
  voltage bits is set.  also !CB_CBARD doesn't mean CB_16BITCARD.  there is
  CB_NOTACARD as well, so make an explicit check for CB_16BITCARD.

- for TI bridges: disable IRQs during power-on.  in all-serial and tied
  interrupt mode the interrupts are always disabled for single-slot
  controllers.  for two-slot contollers the disabling is only done when the
  other slot is empty.  to force disabling there is a new module parameter
  now: pwr_irqs_off=Y (which is a regression for working setups.  that's
  why it's an option, only use when required)

- modparm to disable ISA interrupt probing (isa_probe, defaults to on)

- remove unneeded code/cleanups (ie.  merge yenta_events() into
  yenta_interrupts())

Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 09:45:31 -07:00
Daniel Ritz c835a38896 [PATCH] pcmcia: yenta TI: align irq of func1 to func0 if INTRTIE is set
Make sure that if the INTRTIE bit is set both functions of the cardbus
bridge use the same IRQ before doing any probing...

[ yes i hate the TI bridges for the fact that they are very flexible
  so that so many BIOS vendors get it wrong. ]

Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-05 16:36:43 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00