Hyvää iltapäivää!
bonsoir
Do we have a meeting today?
good question
hverkuil: mchehab: Will there be a meeting today? :-)
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.
hverkuil: there's a question I wanted to ask
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 ?
I'm thinking about coding style (checkpatch), v4l2-compliance, but also high level rules
That certainly wouldn't hurt, but it's hard to come up with a definitive list.
hverkuil: yeah, let's wait for -rc1 to start our meetings ;-)
There could be new ways how things are wrong in the submission.
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, ...
But documenting known-good ways to do things should help.
Yes, I agree.
sailus: it's not a definitive list, it's more about guideliens
pinchartl: I wrote sometime ago something on that matter
pinchartl: I agree with that approach.
things we consider minimum requirements, not an exhaustive list
(and even for strict requirements there can be exceptions when it makes sense)
when there were some discussions about how to describe per-subsystem rulesets
mchehab: I have a bullet points list of items already, for ISP drivers
https://patchwork.linuxtv.org/project/linux-media/patch/9cdbab30b9e0a435b97113b90645e647e8165225.1568815176.git.mchehab+samsung@kernel.org/
I can try to put that in a patch, and we can consolidate it with what you have written
the original template changed after some reviews, but I guess it ended being merged upstream
what I'm thinking about is more about overall driver architecture, so it complements that patch
yes, I understood
as there seems to be an agreement on the idea, I'll try to write things down. we can then discuss it
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
good. Meanwhile, I'll double check how the maintainer entry profiles got added
it probably makes sense to have this merged before ISP-specific entries
yep, the parent document was merged: Documentation/maintainer/maintainer-entry-profile.rst
$ find Documentation/ -name *maintain*|grep profi
Documentation/maintainer/maintainer-entry-profile.rst
Documentation/doc-guide/maintainer-profile.rst
Documentation/nvdimm/maintainer-entry-profile.rst
mchehab: The patch seems good to me.
You could add me CSI-2, too.
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
mchehab: And uAPI header files.
pinchartl: yeah, agreed
ok, I'll review my patch against the current upstream template. If it matches, I'll apply, otherwise I'll send an updated version
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 :-))
then, on your patch, you can just add a link to the driver-specific ones
pinchartl: it probably makes sense to have a few different docs... for instance, CDC have different requirements than ISP ;-)
IMO, the best would be to add a .toctable to the maintainer's profile, indexing those device specific requirements
yes, different documents make sense
probably the best place would be to place those under Documentation/driver-api/media/
so, on the patch I wrote, I'm changing it to: Documentation/driver-api/media/maintainer-entry-profile.rst
anyway, I'll post an updated version  at the ML
mchehab: I did not hear back from Konstantin Ryabitsev about bugzilla
I'll try ping him
pinchartl, sailus: just sent the updated version of the patch
nice
the changes were minor... just reorganized the doc to match the current format, and did a few minor editorial changes
sent a v2... forgot to update Documentation/media -> Documentation/*/media
renames are painful
speaking of renames
we have a bunch of drivers/media/platform/mtk-* directories
assuming an ack from MTK, would it make sense to move that to dribers/media/platform/mediatek/ ?
s/dribers/drivers/
I don't have a strong preference
TI drivers for example are not under a platform/ti
that's true, we have different naming schemes
my *personal* preference would be one directory name per driver, instead of having per vendor ones
it's just that we expect 4-5 more directories (and perhaps even more) for MTK in the not too distant future
and there will be code shared by different drivers too
as I said before, I don't mind having a mix of naming schemes there
I don't mind **that much** ...
I
sorry
I'm ok either way, although having a single name convention could be better
with regards to common code, that's a different matter
I'll check what MTK prefers
right now, we have a drivers/media/common/
where things in common between different drivers are placed
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.
i like a more "flat" struct, with less directories :-)
but this is a matter of personal preference
at least while we don't do a media-tree wide rename and follow the same pattern for all drivers
btw, one of the problems with vendor/driver is that it is not unusual that a vendor to change, without a driver change
so, if we had a Philips vendor, lots of things would need to be renamed to NXP
after the media chipset division of Phillips got sold to NXP
so, IMO, avoiding placing the name of the vendor at the tree makes it a little easier to maintain
as we don't need to rename things as vendor name changes ;-0
but, as I said, I don't mind that much