I've added support for TRIM'ing even if the fs is on an LVM or dm-crypt device. This currently only supports linear logical volumes on top of a single device (i.e. no striped, mirrored, or concatenated volumes), but it does support arbitrary LVM and dm-crypt stackings (i.e. LVM on top of dm-crypt or visa-versa).
BACK UP YOUR DATA before using this. I've tested actual TRIM's on a dm-crypt device, as well as set up a dummy stacked LVM and dm-crypt and verified the reported ranges from --verbose make sense, so I'm reasonably confident it works properly, but...
To use this, LVM must be activated and/or the encrypted devices opened. For online TRIM specify the fs mount point as usual; for offline TRIM specify the device the fs is usually mounted on (e.g. /dev/mapper/home) (in a stacked setup make sure you specify the top-level device, not some intermediate device; e.g. if you have LVM on top of dm-crypt then specify the logical-volume's device, such as /dev/mapper/VolGroup0-LogVol1).
I'm attaching both the full script as well as the diff; both are against version 2.5 because there is no 'rdev' command on my distro, but the patch should apply straightforwardly to 2.6 too. The attached full script also has the x25-m patch, btw. The patch consists of 3 parts: the first part detects device-mapper devices and walks them to figure out the underlying scsi/sata device and to calculate the additional lba offset to use; the second part replaces the use of 'fsdev' with 'fspar' as the fs-device may not be the same as the underlying scsi/sata device; the third part adjusts 'fsoffset' to account for the additional LVM/dm-crypt headers and to account for the fact that the fibmap will return lba's that are relative to the LVM/dm-crypt container.
This should fix both http://sourceforge.net/tracker/?func=detail&aid=2927763&group_id=136732&atid=736685 and http://sourceforge.net/tracker/?func=detail&aid=2990354&group_id=136732&atid=736682 - the reason I created a separate issue here is so I can attach files.