On 06/16/2016 04:33 AM, Lars-Peter Clausen wrote:
On 06/15/2016 12:49 AM, Steve Longerbeam wrote:
This driver is based on adv7180.c from Freescale imx_3.10.17_1.0.0_beta
branch, modified heavily for code cleanup and converted from int-device
to subdev.
We already have a driver for the adv7180 upstream, also using the subdev
API. Is there anything that can be done with this new driver that can't be
done with the other one. And if it is are there any blockers that would
prevent us from adding the missing features to the upstream adv7180?
I know that the driver in the Freescale tree used to have bits that made it
specially tailored to the iMX6. But these bits seem to be mostly gone in
this version of the driver.
I'm slightly concerned about the conflicting nature of these drivers. Both
attach to the same device ID/DT compatible string and register slightly
different userspace ABIs. I'd like to avoid ending up in a situation where
we have dependencies on both ABIs and can no longer converge.
Hi Lars,
Yes, it's been my plan all along to bring the upstream adv7180 subdev
up to speed, and then remove the one included in this patch set.
The issues I see so far with the upstream driver:
- It is not auto-detecting changes to the analog input signal, such as
loss/regain of signal lock and video standard changes. This probably
is because interrupts are not working. I haven't debugged that further.
- The media bus format code is not right, it should be UYVY, not YUYV. But
I'm reluctant to make that mbus code change because there are other
users of this driver and that will likely corrupt images on the other
targets. But I believe UYVY is the correct order according to bt.656
standard, someone correct me if I am wrong.
- The field type should be either V4L2_FIELD_SEQ_BT or V4L2_FIELD_SEQ_TB,
since the adv7180 transmits one complete field followed by the other.
There could be other issues. There are also the ov564x subdevs that
really need
to be cleaned-up and moved to drivers/media/i2c (they are also based on
old FSL
intdev drivers but with more stuff in there that probably doesn't make
sense, such
as those really big register tables that are likely filled with reset
default values and
were generated by doing an i2c dump at reset).
This work will take some time, so the question is, should we delay that
work to
after an initial merge.
Steve
--
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
