Manu Abraham writes: > > You still need a mechanism to decide which tuner gets it. First one > > which opens its own ca device? > > Sharing the CI (multi-stream decoding) in such an automatic way > > would also be complicated. > > I think I will only add such a feature if there is very high demand > > and rather look into the separate API solution. > > > It would be advantageous, if we do have just a simple input path, > where it is not restricted for CA/CI alone. I have some hardware over > here, where it has a DMA_TO_DEVICE channel (other than for the SG > table), where it can write a TS to any post-processor connected to it, > such as a CA/CI device, or even a decoder, for example. In short, it > could be anything, to put short. > > In this case, the device can accept processed stream (muxed TS for > multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You > can flip some registers for the device, for it to read from userspace, > or for that DMA channel to read from the hardware page tables of > another DMA channel which is coming from the tuner. > > Maybe, we just need a simple mechanism/ioctl to select the CA/CI input > for the stream to the bridge. ie like a MUX: a 1:n select per adapter, > where the CA/CI device has 1 input and there are 'n' sources. It would be nice to have a more general output device. But I have currently no plans to support something like transparent streaming from one input to the output and back inside the driver. -Ralph -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
