Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5371096yba; Mon, 13 May 2019 09:42:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqw6GpH4WA9+Cy6iGdzP0cj6fHXGhY/5xugNGbJnV5JuZRegX2DaPSBA7t7dL+O6/LpU3Id/ X-Received: by 2002:a17:902:263:: with SMTP id 90mr32472174plc.257.1557765769340; Mon, 13 May 2019 09:42:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557765769; cv=none; d=google.com; s=arc-20160816; b=juzfca8v2lCYGCvS1uZAmMrtKXyzyLK7V0sDDnuMb0QhXUM7PygDsveWDPlGwX0gl4 c3onxr5riA8clEpWlLeSrL+I09BAzSNlr9ElslxOw6DFGqFy0cM2SMoIGUepGQFHgY8b O1TETEKwwef/77oVnX/RVocDNRzNKIvIXJ6ugVCahjkRq2QFluVkxraKQXlzbvXjUI95 iW/3JWKzvnaXa1zLy+s8HbqpYOriAQFK2sGL1o8zzmh4ES8x926btrL3emMuDnJlhpbD jG5GELIONIa7C8+xP/aoKyRfx/Y3V/W/hJUW+jCSswxlXZ3lR7Nt0LiGaR5tNGwzJmzS PgXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=XecE39z5Wdv1UUdpgjNY8jEJraT3bchBosqiDVEwKac=; b=T4zKf6P1uvnh/4tJb4/nYQ6ULOBb7KH8YOPg8BulXL+VX56b28SbtkgsteXYFlOFVB c7cGBhAPMuFduFv7SQJmrqFkXx1IqtgkTpYKpo6c5mmxNuZOn7wQjVNCjiLSAOmkrxdX K/MUnhDPeq31iWh7WFOinOGkP49cOIuoA9yBdV7mTvxwzfIU58HKlCn+wFFlTdtSwqk4 kKb8Krw0hmQ3juaj6bKtGchJHZta+3jJP1slyEil7I/NxXH7pgLtOw1u5ShZJE2kGdTt 8zANRQf8SZqMzMglxJCLvz6BiKGdE4FG0yzEagJVgGM4n1TweUMoq2g5DpYHrYRgyZO3 Wxbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=casper.20170209 header.b=H0nmENQF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c11si17070017pgi.26.2019.05.13.09.42.33; Mon, 13 May 2019 09:42:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=casper.20170209 header.b=H0nmENQF; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729584AbfEMPXt (ORCPT + 99 others); Mon, 13 May 2019 11:23:49 -0400 Received: from casper.infradead.org ([85.118.1.10]:54980 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728615AbfEMPXt (ORCPT ); Mon, 13 May 2019 11:23:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XecE39z5Wdv1UUdpgjNY8jEJraT3bchBosqiDVEwKac=; b=H0nmENQFZDrtsb3WGjL+nJ69KT +fXIpU+tp4CIRwnV+GiOf2ZuYb/PjDqW+bH34swATcxiDuZnoXt0NgCWwwjUvKVVSV+4LSGTEDkxt EgaBGgeQXLx3OmLBYd93SgbZClb1EJduca7Wg514zub9bi1EJbXXXPCqTyK2I0c5oZSObRWrlKlA8 Yy73fDr+lUmikIR3nYOUtTmYEXCm57xPb5KR/uYq4cNV6Flmow0OzvrHf0inaLH9aCMVeDwZh/iMp OxxIfEOkSOZCIbnn6mxObPb4uof0Z1j+riFiG3a7d2eBftDChxE55rtGPvKR8IyyPgkKlMP78iBvH REqmF3PA==; Received: from [179.179.44.200] (helo=coco.lan) by casper.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1hQCnd-0003iy-SA; Mon, 13 May 2019 15:23:34 +0000 Date: Mon, 13 May 2019 12:23:27 -0300 From: Mauro Carvalho Chehab To: Daniel Vetter Cc: Laurent Pinchart , Maxime Ripard , Daniel Vetter , David Airlie , Maarten Lankhorst , Sean Paul , Sakari Ailus , Linux Kernel Mailing List , dri-devel , Paul Kocialkowski , Hans Verkuil , Thomas Petazzoni , "open list:DMA BUFFER SHARING FRAMEWORK" Subject: Re: [PATCH 00/20] drm: Split out the formats API and move it to a common place Message-ID: <20190513122327.57f9c6ea@coco.lan> In-Reply-To: <20190513145719.GS17751@phenom.ffwll.local> References: <20190417154121.GJ13337@phenom.ffwll.local> <20190418062229.eyog4i62eg4pr6uf@flea> <20190418090221.e57dogn4yx5nwdni@flea> <20190420225904.GZ4964@pendragon.ideasonboard.com> <20190423072554.GW13337@phenom.ffwll.local> <20190423154527.GH16111@pendragon.ideasonboard.com> <20190511192632.GN13043@pendragon.ideasonboard.com> <20190513145719.GS17751@phenom.ffwll.local> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Mon, 13 May 2019 16:57:19 +0200 Daniel Vetter escreveu: > > > I think small boutique trees are a problem themselves, not a solution. > > > So if you're creating a new small boutique tree to fix a problem, you > > > then have 2. Yes, assuming sufficient expenditure of energy it can be > > > made to work, but I'd prefer to make my own life as easy and lazy as > > > possible :-) And I think I've been fairly successful at that within > > > drivers/gpu at least. > > > > > > Imo the proper fix is to merge v4l and drm, at a process/maintainer > > > level. That would solve both the original issue and the 2ndary one of > > > the permanent topic branch. > > > > Proposals are welcome ;-) > > I'm already somewhat unpopular at LPC/lkml/kernel-at-large, I don't want > to make this worse. That's why I don't want to officially push for > anything here myself, nor be in any other way involved in an effort to > figure out v4l governance and maintainership rules. > > What I think is required for efficient collaboration with drm (no matter > how we implement that in the details once we're ready for that step) is > some kind of group maintainership model. Doesn't need to be as extreme as > drm-misc, but I think at least something like the soc tree (while it was > still a bit more limited as arm-soc). Otherwise the impendence mismatch > between how drm rolls and how v4l rolls is probably way too much. From my > understanding v4l is working differently. > > Also, through sheer inertia of size, I don't think it'll be easier to > align drm with the v4l model. So that option is not realistic. I don't think it is realistic trying to align V4L2 model to every single other subsystems we use. We have a lot of alignment with alsa, with even increased during this merge window due to some drivers on media sharing media controller resources with usb-audio. We also have lots of alignment with i2c, as we use a lot of stuff there, and from time to time they need to add new features due to our needs. The same is true also for input and for other subsystems and arch/sub-arch trees. That doesn't mean at all that everybody should use the same maintainership model. Each subsystem should use whatever suits best. That's said, after following this thread for a while, I'm starting to convince that it wouldn't even be realistic to have a common fourcc API for both subsystems. The internal requirements from each subsystem are different, and, as it was already pointed in this thread, that's basically why DRM ended by having their own way of doing that. Yet, it would make sense to have at least a single nomenclature for both systems to use, but it could be a simple as what we already do with other common resources, like: Documentation/ioctl/ioctl-number.txt If we keep the fourcc codes there sorted, if one subsystem would add a conflicting code, it would be easy to notice at linux-next. Thanks, Mauro