On Tuesday, September 27, 2011 12:00:03 Scott Jiang wrote: > > > > What you would typically do in a case like this (if I understand it > > correctly) is that in the s_input ioctl you first select the input in the > > subdev, and then you can call the subdev to determine the standard and > > format and use that information to set up the bridge. This requires that > > the subdev is able to return a proper standard/format after an input > > change. > > > > By also selecting an initial input at driver load you will ensure that > > you always have a default std/fmt available from the very beginning. > > > The default input is 0. So you mean I ask the subdev std and fmt in > probe instead of open? Yes. In general that's the best place. There are cases where you want to do such initialization on the first open, but that's when you need to do e.g. a slow firmware upload. If you do not have such special requirements, then setting up the hardware to a sane state is best done in probe. Regards, Hans > > It also looks like the s_input in the bridge driver allows for inputs that > > return a subdev format that can't be supported by the bridge. Is that correct? > > If so, then the board code should disallow such inputs. Frankly, that's a > > WARN_ON since that is something that is never supposed to happen. > -- > 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 > -- 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
