>
> On Monday 16 March 2009 20:10:27 Karicheri, Muralidharan wrote:
> > Hans,
> >
> > That was quick!
> >
> > Please see my response inline.
> >
> > >>>Yes, that's OK. What timeframe for the subdev conversion did you
> have
> > >>> in mind? Personally I would like to see v4l2-int-device removed
> for
> > >>> kernel 2.6.31.
> >
> > [MK] Sorry to ask a question back. What is the timeframe when 2.6.31
> is
> > available ? I am not very familiar with the kernel release process. I
> > need to coordinate this with Vaibhav who is responsible from OMAP
> side
> > which is using the same tvp514x driver. I will ask him to be in this
> > discussion.
>
> Each time a new kernel is started by Linus you have two weeks to get
> major
> changes in (like this driver). After that you have about 2 months of
> bug
> fixing. I suspect the 2.6.30 merge window will open in 1-2 weeks, so
> the
> 2.6.31 merge window will be in about 2.5-3 months from now.
>
> This is a good article to read as it explains it in more detail:
>
> http://ldn.linuxfoundation.org/how-participate-linux-community
>
> You have to be aware of the kernel release cycle, because if you miss
> the 2
> week merge window, then you may have to wait for 2-2.5 months before
> the
> next merge window opens.
>
> > >>>> Other responses are inline.
> > >>>>
> > >>>> >>>I have one comment that also refers to the new DM646x driver
> that
> > >>>
> > >>>was
> > >>>
> > >>>> >>>send to
> > >>>> >>>the list for review, which is why I CC-ed this to Chaithrika
> as
> > >>>
> > >>>well:
> > >>>> >>>The DM335/DM6446 adds the following files:
> > >>>> >>>
> > >>>> >>> create mode 100644
> drivers/media/video/davinci/ccdc_davinci.c
> > >>>> >>> create mode 100644
> drivers/media/video/davinci/ccdc_davinci.h
> > >>>> >>> create mode 100644
> drivers/media/video/davinci/vpfe_capture.c
> > >>>> >>> create mode 100644 drivers/media/video/davinci/ccdc_dm355.c
> > >>>> >>> create mode 100644 drivers/media/video/davinci/ccdc_dm355.h
> > >>>> >>> create mode 100644 include/media/davinci/vpfe_capture.h
> > >>>> >>> create mode 100644 include/media/davinci/vpfe_types.h
> > >>>> >>> create mode 100644 include/media/davinci/ccdc_common.h
> > >>>> >>> create mode 100644 include/media/davinci/ccdc_hw_device.h
> > >>>>
> > >>>> [MK] VPFE capture is a bridge driver that is used on DM355,
> DM6446
> > >>>> and DM365. Since all these DM SoCs have common VPFE (Video
> > >>>> Processing front end) that is used for capturing video, I have
> named
> > >>>> the capture driver
> > >>>
> > >>>as
> > >>>
> > >>>> vpfe_capture.c. vpfe_types.h has common vpfe types used across
> all
> > >>>
> > >>>DMxxx
> > >>>
> > >>>> family.
> > >>>
> > >>>But the dm646x also has a vpfe, but that's different than these,
> > >>> right? So
> >
> > [MK] dm646x has vpif (video peripheral/port interface). So my
> suggestion
> > is to prefix the bridge driver file by the IP name. For example,
> DM6467
> > has vpif IP for capture and display. So I would go for vpif_capture.c
> for
> > bridge driver and vpif_display.c for display driver. However for HW
> > modules responsible for configuring video port parameters (vpif for
> > DM6467 and ccdc for DM355/6446), I would suggest adding dmxxx prefix
> > along with IP name since the hw may differ from one dmxxx family to
> > another (in terms of features). In future, if TI come up with another
> > DMxxx SoC similar to DM6467 that too uses vpif, then we don't have to
> > change the names again to re-use the bridge driver. So I propose the
> > following for DM6467 (I expect Chaithrika to comment on this).
> >
> > vpif_capture.[ch] -> DM6467 Capture bridge driver
> > vpif_display.[ch] -> DM6467 Display bridge driver
> > dm6467_vpif.[ch] -> DM6467 capture & display hw module
> >
> > For future DM6467 variants, we may able to use the same bridge driver
> as
> > was done in DM355/DM6446. I am not sure if the DM6467 capture driver
> > requires change to re-use across another DM6467 variant. I will let
> > Chaithrika comment on this.
> >
> > >>>that would have headers like dm646x_capture.h etc.
> > >>>
> > >>>Given this I am inclined to rather go for dmxxx_foo.c/h. Not
> ideal,
> > >>> but that's because you messed up your numbering scheme :-) :-)
> > >>>
> > >>>What do you think?
> >
> > [MK] See my explanation above. Let us also hear from Chaithrika on
> this.
>
> OK. Using vpif_ and vpfe_ prefixes is OK by me if Chaithrika agrees. As
> long
> as the naming is consistent for both dm355/dm6446 and dm646x.
Currently the Video Port Interface driver is common to both display and
capture, therefore it is named as 'vpif.c'. I do not see a need to create
separate files for display and capture as mentioned above. In my opinion the,
VPIF bridge driver can retain the existing name. Also, TI is planning to
have VPIF in an upcoming SoC and this will be similar to the one on DM646x.
If there is anything specific to the hardware that can go into the
dm646x_vpif.[ch].
At this point of time though, such a file may not be needed.
The files that will be added by DM646x display driver will be
1] drivers/media/video/davinci/dm646x_display.c - Is it better to name this
file
'dm646x_evm_display.c' since this is specific to the TI DM646x EVM?
2] drivers/media/video/davinci/vpif.c - no change
3] include/media/davinci/dm646x_display.h - Should this be
'dm646x_evm_display.h'?
4] include/media/davinci/vpif.h - no change
Thanks,
Chaithrika
>
> Regards,
>
> Hans
>
> --
> Hans Verkuil - video4linux developer - sponsored by
> TANDBERG_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
