#v4l 2021-02-16,Tue

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
sailusmchehab: Petr would be fine merging the fourcc modifier set through the DRM tree, would that work for you as well?
(Printk tree was discussed earlier, just checking.)
It's expected most issues could happen on DRM side.
It there would be any, that is.
[09:34]
mchehabsailus: yeah, sure
yeah, DRM tree is a big mess
based on how difficult is to bisect anything at DRM, it sounds that they use lots of black magic for it to work
anyway, I'm fine if the patches go though DRM tree ;-)
[09:37]
sailusThanks.
I think it's because there's a patch changing a dozen drivers.
[09:40]
mchehaband those dozen drivers likely come from dozen different trees, that are merged there
I suspect that most of the time, the DRM maintainers spend fixing merge conflicts ;-)
[09:43]
mripardnot really
there's 3 main trees, and they cover different drivers, so the amount of conflict is totally manageable
[09:44]
......... (idle for 42mn)
pinchartlmchehab: conflict resolution is actually quite nice in DRM, there's a shared git-rerere tree [10:27]
mchehabsounds black magic to me ;-)
it doesn't sound a standard git procedure to share git-rerere
[10:33]
pinchartlit's probably not the norm among kernel developers, no. and that's a shame :-) it would really ease maintenance [10:36]
mchehaband that explains why it is so hard to git-bisect an issue at drm
once I had to track a patch that broke hikey970 drm driver...
it took me several *hours* to make bisect work, as I needed first to rewrite the history
[10:36]
pinchartlI don't see how that's related. but what kind of bisection issues ? I've bisected lots of display issues and never had problems there (well, not more than normal bisection issues) [10:37]
mripardyep, had to bisect a DRM regression over 10 kernel versions 2 weeks ago and it went fine too [10:38]
mchehabbasically, as I can't merge this driver, as the current drm process doesn't allow merging via staging, each time the DRM kAPI changes, a new patch needs to be added
for bisect to work, I need to place those patches in the middle of the git history (before the patch that changed the kAPI)
which is really hard due to all merge conflicts solved in the middle of the drm tree
(and some of them seemed to be results of some rebases)
[10:38]
pinchartlah so it's a rebase, not really a bisection
maintaining out of tree patches is always painful
[10:40]
mchehabprobably made during the driver's tree merge [10:40]
mripardthere's no rebase in DRM [10:41]
mchehabnot at DRM... at drivers tree level - I suspect [10:41]
kbinghampinchartl, How do you share a rerere ? [10:42]
mchehabI mean, it sounds to me that some kAPI changes were solved at the wrong place [10:42]
pinchartlit's a common issue with DT integration too, when you have a set of DT changes that are not upstream yet and are required to test a driver on a particular board. they have to be manually applied to each bisection point. a bit painful, but it's a use case that is explicitly explained in the git-bisect man page [10:42]
mchehab(perhaps during merge time?) [10:42]
pinchartlkbingham: the rerere database is a git tree [10:42]
kbinghamhaah of course it is ;-) [10:42]
mchehabpinchartl: yeah, it is really annoying to maintain it out of the tree
but I didn't find any legal way to merge the Hikey 970 and satisfy DRM maintainer's desire of folding my patches with the ones from its original authors
[10:43]
pinchartlspeaking of out of tree, I've sent 78 patches yesterday for the imx driver, I hope to get them merged soon to avoid rebasing them too often :-) [10:44]
mchehabthey didn't even accept doing this via staging, as DRM workflow seems to be broken with regards to staging [10:45]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)