From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755979AbcIVJMJ (ORCPT ); Thu, 22 Sep 2016 05:12:09 -0400 Received: from mout.web.de ([217.72.192.78]:54827 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752591AbcIVJME (ORCPT ); Thu, 22 Sep 2016 05:12:04 -0400 Subject: Re: GPU-DRM-OMAP: Fine-tuning for several function implementations To: Laurent Pinchart , Daniel Vetter References: <566ABCD9.1060404@users.sourceforge.net> <0ea38611-3d93-0ade-a1fb-f8cc2e0b8d61@users.sourceforge.net> <20160922064501.GF22164@dvetter-linux.ger.corp.intel.com> <3793871.zJbXxf8jdx@avalon> Cc: dri-devel@lists.freedesktop.org, David Airlie , Tomi Valkeinen , Julia Lawall , kernel-janitors@vger.kernel.org, LKML From: SF Markus Elfring Message-ID: Date: Thu, 22 Sep 2016 11:11:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <3793871.zJbXxf8jdx@avalon> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:yzituwFAIwkRrFxuM7criaFmcwJ8hFL938FrYlJSyTaHgK8kMGT Ey1JekPMtnhsLRDspbzXvVRDWnDTQMiQfBfSWiCxl25vH0DmUlF9vOWB4m3boFYx4LIzbe1 1Mj8rI4s+gIrgJWjbug3MbssX6sU/CbpuFfeV8fAX/3X7/KTvA2LIuNKedDwTTUHg/VMGE2 dpdBwyDBqIOQ3oyTESCtw== X-UI-Out-Filterresults: notjunk:1;V01:K0:04NWWxwlMZU=:jjnNj+KS19WeG3AZtrbMMS sNZC+fbXalKRL1clt2EEA9iq2EzyU8DGrTeMKcZOt18sTjw01Xw8BGWbJ1tvO/Ou6hIrTUuNO 1try2ba0J+rRxC/5tDJL2j3JF5GSJF1lmS2WhwKkA25yMNdnnGgXN2iD4Scy7joWwJ766WUhQ 9umRKWHNodA5oQkpJ+HKqetlCCq/rypzBQyo0HspBJKbOUC6JovYZk2jPDWu0QPzWorInp4uY fNR2+AoyjRb4jnNeq0j6yaA01US4ayYtFPIM3K5ov7fzmvKnjb9fEgANiUpZ2sO4rbYiONY59 894goeRlud+0SETcxPAEvlWuaaFCaZDeNDd4QZk2SpU3QW9UMYWEfrAQ10B8EvkZARyR2KKRE chqcYyIDfqIE+f0uj5PaN5vaYWKpOesKtIhgthBVfoC6L7vuA/MiPlkYdKZ2gjgwBOYNB59Nk BK6eMEzDF569Dr3mhcPt+aOHoD4ZlEh/6wyLiQisGxVLFm7IOHMtEKKNqQ6WQwTpM19YHXVZi g5UHegbRBLvEOUtyqKgi6IwL+01gstumg19oIA2Rn6ZSu/xB4kZx1K8wLrZrrevaASVOqdZV9 c0uKMlWFd8pyhaXQNhGbAxgXpxzoz4newRh+d6Mj1W9D5CqzbOkI41EMxeAjFXQ+AUhqPnuA/ f22xQpYI6zAeCgnEEQaJ0t9KBggONtUFS58kWeANjFbGWPSnwOsp0M4874uULBgx2WMFLYNp+ qxjRPvut6U+/8fsRS26PhQnmGRXzq8KGMvztppdWxgkfsSwZCI0wjhl8Yq4rPWZmE9wDUSz2/ ZjduCot Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> For the next pile of driver patches _please_ talk with driver maintainers >> before starting to create&submit patches. Did the software development discussion start a bit here? Would you like to support an other "talking style" on a conference like in Berlin next month? >> Like I said I won't take them, It's a pity. >> and many of your changes are not clear-cut at all, I know that specific update suggestions could be interpreted as controversial. >> so I expect many driver maintaines also won't take them. I am curious on useful responses. >> Again, your contributions are welcome, Thanks for another bit of constructive feedback. >> but blindly following suggestions from code checkers in drivers I propose to dare another look at corresponding information sources. >> you cant test isn't really all that useful. I have got an other impression. How many improvements can still be achieved by usual (advanced) collaboration techniques for free software development? >> At the scale you're doing it, I think it's mostly wasting everyone's time I hope not. > :( I'd like to avoid that. I am going to point more update opportunities out also for various Linux software. > I second that. Thanks for your opinion on this issue. > After a very quick review, I see that the series splits related changes > in multiple patches. I chose a specific patch granularity for this proposal. > I've already commented in reply to another series submitted by Markus > that patches should then be combined. Will such a combination depend on any more agreements between the involved contributors? > I will thus ignore this series completely for the time being. I hope that you can give similar ideas a second chance somehow. Regards, Markus