I don't know MMC/SD, but anyway:
You could have a look whether "lspci -v" shows the same "Kernel driver in use: ..." under 2.6.26 and 2.6.27.  Furthermore, check in /proc/interrupts whether the respective driver receives interrupts when you insert a card.

Stefan, yes - there is difference in driver in IRQ reported.
For 2.6.26 it is:
01:05.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 01)
	Subsystem: TWINHEAD INTERNATIONAL Corp Device 0617
	Flags: slow devsel, IRQ 16
	Memory at fe8ff800 (32-bit, non-prefetchable) [size=256]
	Capabilities: [a0] Power Management version 2
	Kernel driver in use: sdhci
	Kernel modules: sdhci


for 2.6.27:
01:05.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 01)
	Subsystem: TWINHEAD INTERNATIONAL Corp Device 0617
	Flags: slow devsel, IRQ 10
	Memory at fe8ff800 (32-bit, non-prefetchable) [size=256]
	Capabilities: [a0] Power Management version 2

Thanks for your assistance!
But what could cause this?

IRQ 16 -> IRQ 10 is not necessarily a problem sources.  But is there really no "Kernel driver in use" and "Kernel modules: sdhci" reported in 2.6.27?  If so, perhaps your kernel config simply lost the necessary option.

lspci -v |grep sdhci gives nothing

I also double checked Yenta/O2-related kernel options.
And I can successfully manually probe sdhci, so it's definitely there.
It produces the next dmesg:

Dec  2 10:39:26 averamihel kernel: sdhci: Secure Digital Host Controller Interface driver
Dec  2 10:39:26 averamihel kernel: sdhci: Copyright(c) Pierre Ossman

Yenta is something different (PCI to CardBus bridge, AFAIK a fully separate chip function).

So you can modprobe sdhci --- but does the kernel actually bind it to the controller?  *If* lspci does *not* show the sdhci driver as active driver for the SD controller even after you modprobe'd sdhci, then
  - either the kernel's driver matching routine did not see any match between the driver's ID table and the chip's ID,
  - or there was a match and sdhci's probe function was called, but the probe failed.

Probe didn't fail as far as I can tell - since lsmod shows the module and some dependent modules:

lsmod|grep sdhci
sdhci                  13380  0 
mmc_core               41044  1 sdhci

So your first guess is probably more realistic.
Now I need to know how does kernel match drivers to devices :)

lsmod doesn't say anything about whether a probe was executed and if yes, whether it succeeded.  You can insert as many modules into the kernel as you like, without having any hardware for them.

Just look at:
# lspci -v
# cat /proc/interrupts

Only they show whether sdhci was bound to a device or not.

Also report
# modinfo sdhci
under 2.6.26 and 2.6.27.

Created attachment 19100 [details]
2.6.26 lspci -v, cat /proc/interrupts, modinfo sdhci

Created attachment 19101 [details]
2.6.27 lspci -v, cat /proc/interrupts, modinfo sdhci

Thanks.

See how sdhci in 2.6.27.7 (your one, at least) shows a serious lack of module aliases?  These aliases are generated during the kernel build process from a drivers device ID table --- the table which is used by the kernel's driver core (or in that case maybe the PCI core) to match drivers with devices as prerequisite for driver binding.

Furthermore, your lspci confirms that sdhci is not bound to the SD controller, and the interrupts table shows that the SD controller's interrupt was not enabled and served by any driver.

Since your other drivers kept working, a general problem with your kernel build seems unlikely.

Now, a quick look into the git history of drivers/mmc/host/sdhci.c between v2.6.26 and v2.6.27 immediately shows one commit which touched sdhci's device ID table:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b8c86fc5d8deaa5a6dc49c2c1ed144e6838bf0f3

Look at the diff of Kconfig.  Did you enable the *new* configuration option MMC_SDHCI_PCI alias "SDHCI support on PCI bus"?  I guess not, and enabling this would fix sdhci for you.

Pierre, maybe the sentence "If unsure, say N" in MMC_SDHCI_PCI's help text was not so helpful after all.

Stefan,

Thank you so much, SD card reader works great after I enabled that option!
Also thanks for the knowledge about kernel and drivers, I'm sure it will help me in case my Linux misbehaves again :)
Should this bug be rejected now?

I close this and remove the status as regression --- even though it actually can be considered a regression.  (A kernel build option which worked in 2.6.26 does not give the same result in 2.6.27 anymore, unless a new other option is switched on too.)  However, since the change that caused it had a good reason (make the sdhci base driver independent of the type of local bus attachment) and the old and new Kconfig options have help texts which are clear enough to at least those people who know that their SD controller is PCI-attached, we can leave it at "not a bug".

I hope that other people who encounter the same issue find your LKML post and thus the link to this bug entry.  Thanks for the report and the patience to resolve this.

Kconfig is unfortunately a bit of a pain when it comes down to making it easy to use. On one end there's people wanting defaults that give you proper support for your hardware. And on the other end, there's people that want everything machine specific to be off by default so that you don't get a lot of crud in the kernel. Right now it is the latter that is the dominating principle. Changing just sdhci would cause more confusion than it would solve.

I can have a look at making it clearer though. Something like "if you have a PC with an SD/MMC reader, you probably want this driver".

And a big thanks for the help Stefan. It's good to know that there are others that can help out when my time is limited. :)

As I indicated in my initial bug report I did suspect that some new option needed to be set. So the problem was really not with the driver or kernel, but with the config tool (I'm using gconfig). In my gconfig majority of options are displayed with (NEW) flag, so it's almost impossible to tell which option is really new for the release (or for the new patch).
Or, as usual, there is a good change that I'm not doing configuration the right way. I'm just copying my .config file from previous release to a new one. I tried to use diff between old and new .configs but it makes no sense b/c options often change their location in the file.

Oleg,
I mostly use "make oldconfig" after copying .config from my previous to a next kernel.  This is text-based and stops at every new option, where you can type h (if the option has a help text as it should), then y or m or n.