Does a CA need to have the same type of key as the certificates it is signing? RSA / Elliptic Curve (EC/ECDH/ECDSA)

In X.509, a CA can use any signature algorithm, regardless of the type of key in the signed certificates. Theoretically, if both the CA and the signed certificate use DSA keys or EC keys, and the two keys share the same group parameters (i.e. work over the same curve, for EC keys), then the designation of the curve might be omitted in the signed certificate. For EC keys, this may save perhaps a dozen bytes, and PKIX (the group responsible for the Internet X.509 Profile) explicitly forbids this "optimization". Hence I confidently state that there is no link between the types of keys in a CA certificate and the certificates that CA issues.

EC support in the existing deployed software based can be described as "flaky". Although X9.62 specifies how to encode parameters for EC keys in quite arbitrary curves, almost everybody implements only a limited set of "known curves", mostly from the 15 curves from FIPS 186-3. Actually, among these 15 curves, only two of them (P-256 and P-384) have non-anecdotic support in existing browsers. These two curves are the "bare minimum" of EC support as per NSA "suite B" (a recommendation from NSA for non-NSA people -- what constitutes "suite A" is not publicly known).

Also, X9.62 defines quite clearly how an ECDSA signature should be computed for every combination of hash function and curve (i.e. how hash values should be truncated or expanded to fit the curve group order). As could be expected, implementers got it wrong, and many believe that with P-256 (respectively P-384) only SHA-256 (respectively SHA-384) may be used. Therefore, if you use any other hash function, you will run in interoperability issues (I mean, more issues than what you will get for merely trying to use an algorithm which was not born in the Disco era).

The bright side is that P-256 with SHA-256 is, security-wise, "fine" (I love that word). The dark side is that even with that most supported combination, you will get into issues with old browsers (and there are places which are quite conservative with regards to updates -- at my workplace, the only allowed browser is IE 7 !). So you need a backup plan. Since the backup should be a whole-RSA PKI (RSA everywhere from the root down to the server and user certificates) for compatibility, and you want to ultimately switch to a whole-EC PKI, then you need two roots, one with RSA and one with EC. You can smooth out transitions to some extent with cross-certificates, but it is a whole can of worms.

Tom's answer is correct for X.509 standard and many browsers which are based on standard SSL libraries support the case. However, in this rough real world, I found some devices rejecting ECDSA certificate which has RSA signatures, with TLS 1.2 negotiation.

I think the reason is that the authors of the devices followed the RFC-4492, (** is mine)

2.2.  ECDHE_ECDSA
In ECDHE_ECDSA, the server's certificate **MUST** contain an ECDSA-
capable public key and **be signed with ECDSA.**

The server sends its ephemeral ECDH public key and a specification of
the corresponding curve in the ServerKeyExchange message.  These
parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's Certificate.

though RFC-5246, TLS1.2, loosened this restriction. (** is mine):

7.4.4.  Certificate Request
...
If the client provided a "signature_algorithms" extension, then all
certificates provided by the server MUST be signed by a
hash/signature algorithm pair that appears in that extension. **Note
that this implies that a certificate containing a key for one
signature algorithm MAY be signed using a different signature
algorithm (for instance, an RSA key signed with a DSA key).  This is
a departure from TLS 1.1, which required that the algorithms be the
same.**  Note that this also implies that the DH_DSS, DH_RSA,
ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
algorithm used to sign the certificate.  Fixed DH certificates MAY be
signed with any hash/signature algorithm pair appearing in the
extension.  The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
historical.

So be warned that such a device exists.

According to RFC 3280 no constrain is applied to signature algorithms:

4.1.2.7 Subject Public Key Info

This field is used to carry the public key and identify the algorithm with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The algorithm is identified using the AlgorithmIdentifier structure specified in section 4.1.1.2. The object identifiers for the supported algorithms and the methods for encoding the public key materials (public key and parameters) are specified in [PKIXALGS].

Thus any algorithm specified in RFC 3279 can be used for CA, Subject and CRL signature independently.