<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
pinchartl: bonsoir
sailus: Do we have a meeting today?
pinchartl: good question
sailus: <u>hverkuil</u>: mchehab: Will there be a meeting today? :-)
hverkuil: nothing planned. Assuming rc1 is released this weekend, then we'll have a meeting next week. If Linus delays this by a week, then I guess we'll skip next week's meeting as well.
pinchartl: <u>hverkuil</u>: there's a question I wanted to ask
<br> would it make sense to write a document, to be added to Documentation/, that lists the requirements that drivers need to comply to to be upstreamable ?
<br> I'm thinking about coding style (checkpatch), v4l2-compliance, but also high level rules
sailus: That certainly wouldn't hurt, but it's hard to come up with a definitive list.
mchehab: <u>hverkuil</u>: yeah, let's wait for -rc1 to start our meetings ;-)
sailus: There could be new ways how things are wrong in the submission.
pinchartl: such as using V4L2 standard ioctls instead of vendor-specific extensions to configure parameters that are handled by V4L2, not requiring a closed-source daemon, ...
sailus: But documenting known-good ways to do things should help.
<br> Yes, I agree.
pinchartl: <u>sailus</u>: it's not a definitive list, it's more about guideliens
mchehab: <u>pinchartl</u>: I wrote sometime ago something on that matter
sailus: <u>pinchartl</u>: I agree with that approach.
pinchartl: things we consider minimum requirements, not an exhaustive list
<br> (and even for strict requirements there can be exceptions when it makes sense)
mchehab: when there were some discussions about how to describe per-subsystem rulesets
pinchartl: <u>mchehab</u>: I have a bullet points list of items already, for ISP drivers
mchehab: https://patchwork.linuxtv.org/project/linux-media/patch/9cdbab30b9e0a435b97113b90645e647e8165225.1568815176.git.mchehab+samsung@kernel.org/
pinchartl: I can try to put that in a patch, and we can consolidate it with what you have written
mchehab: the original template changed after some reviews, but I guess it ended being merged upstream
pinchartl: what I'm thinking about is more about overall driver architecture, so it complements that patch
mchehab: yes, I understood
pinchartl: as there seems to be an agreement on the idea, I'll try to write things down. we can then discuss it
<br> I'd like to have a first round of private review to check we're on the same page instead of disagreeing on core issues on the list in front of vendors, if that's ok with everybody
mchehab: good. Meanwhile, I'll double check how the maintainer entry profiles got added
<br> it probably makes sense to have this merged before ISP-specific entries
<br> yep, the parent document was merged: Documentation/maintainer/maintainer-entry-profile.rst
<br> $ find Documentation/ -name *maintain*|grep profi
<br> Documentation/maintainer/maintainer-entry-profile.rst
<br> Documentation/doc-guide/maintainer-profile.rst
<br> Documentation/nvdimm/maintainer-entry-profile.rst
sailus: <u>mchehab</u>: The patch seems good to me.
<br> You could add me CSI-2, too.
pinchartl: yes, or we could develop both in parallel. I'm not sure if the maintainers profile is the best place to document architecture requirements, as the latter could be long (especially if we extend it to cover different kind of devices). I think adding the architecture documentation to the media documentation directory, and pointing to it from the maintainer profile, could be better
sailus: <u>mchehab</u>: And uAPI header files.
mchehab: <u>pinchartl</u>: yeah, agreed
<br> ok, I'll review my patch against the current upstream template. If it matches, I'll apply, otherwise I'll send an updated version
pinchartl: and the good thing about storing it in the media documentation is that we can merge it independently of the maintainer profile (although the latter will likely be ready first :-))
mchehab: then, on your patch, you can just add a link to the driver-specific ones
<br> <u>pinchartl</u>: it probably makes sense to have a few different docs... for instance, CDC have different requirements than ISP ;-)
<br> IMO, the best would be to add a .toctable to the maintainer's profile, indexing those device specific requirements
pinchartl: yes, different documents make sense
mchehab: probably the best place would be to place those under Documentation/driver-api/media/
<br> so, on the patch I wrote, I'm changing it to: Documentation/driver-api/media/maintainer-entry-profile.rst
<br> anyway, I'll post an updated version at the ML
syoung: <u>mchehab</u>: I did not hear back from Konstantin Ryabitsev about bugzilla
mchehab: I'll try ping him
<br> pinchartl, sailus: just sent the updated version of the patch
pinchartl: nice
mchehab: the changes were minor... just reorganized the doc to match the current format, and did a few minor editorial changes
<br> sent a v2... forgot to update Documentation/media -> Documentation/*/media
pinchartl: renames are painful
<br> speaking of renames
<br> we have a bunch of drivers/media/platform/mtk-* directories
<br> assuming an ack from MTK, would it make sense to move that to dribers/media/platform/mediatek/ ?
<br> s/dribers/drivers/
mchehab: I don't have a strong preference
<br> TI drivers for example are not under a platform/ti
pinchartl: that's true, we have different naming schemes
mchehab: my *personal* preference would be one directory name per driver, instead of having per vendor ones
pinchartl: it's just that we expect 4-5 more directories (and perhaps even more) for MTK in the not too distant future
<br> and there will be code shared by different drivers too
mchehab: as I said before, I don't mind having a mix of naming schemes there
<br> I don't mind **that much** ...
<br> I
<br> sorry
<br> I'm ok either way, although having a single name convention could be better
<br> with regards to common code, that's a different matter
pinchartl: I'll check what MTK prefers
mchehab: right now, we have a drivers/media/common/
<br> where things in common between different drivers are placed
hverkuil: If there are multiple drivers for a specific vendor, then I prefer the vendor/driver convention for media/platform. I find that easier to navigate.
mchehab: i like a more "flat" struct, with less directories :-)
<br> but this is a matter of personal preference
<br> at least while we don't do a media-tree wide rename and follow the same pattern for all drivers
<br> btw, one of the problems with vendor/driver is that it is not unusual that a vendor to change, without a driver change
<br> so, if we had a Philips vendor, lots of things would need to be renamed to NXP
<br> after the media chipset division of Phillips got sold to NXP
<br> so, IMO, avoiding placing the name of the vendor at the tree makes it a little easier to maintain
<br> as we don't need to rename things as vendor name changes ;-0
<br> but, as I said, I don't mind that much
***: ChanServ sets mode: +v pinchart1