From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938742AbcIZK22 (ORCPT ); Mon, 26 Sep 2016 06:28:28 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:56209 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933368AbcIZK20 (ORCPT ); Mon, 26 Sep 2016 06:28:26 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 11B906145C Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=architt@codeaurora.org Subject: Re: [PATCH V5 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge To: Peter Senna Tschudin References: <3a56-57e8e300-3-10c8a340@87357206> Cc: galak@codeaurora.org, thierry.reding@gmail.com, kernel@pengutronix.de, Rob Herring , ykk@rock-chips.com, jslaby@suse.cz, tiwai@suse.com, eballetbo@gmail.com, devicetree@vger.kernel.org, shawnguo@kernel.org, linux@roeck-us.net, davem@davemloft.net, p.zabel@pengutronix.de, peter.senna@gmail.com, daniel.vetter@ffwll.ch, enric.balletbo@collabora.com, Peter Senna Tschudin , javier@dowhile0.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, pawel.moll@arm.com, ijc+devicetree@hellion.org.uk, martin.donnelly@ge.com, linux@armlinux.org.uk, heiko@sntech.de, mark.rutland@arm.com, akpm@linux-foundation.org, airlied@linux.ie, Fabio Estevam , mchehab@osg.samsung.com, linux-arm-kernel@lists.infradead.org, robh+dt@kernel.org, martyn.welch@collabora.co.uk, gregkh@linuxfoundation.org, treding@nvidia.com, rmk+kernel@armlinux.org.uk From: Archit Taneja Message-ID: <8a7a0b02-5b9f-4266-75a2-42f26fcbc352@codeaurora.org> Date: Mon, 26 Sep 2016 15:58:04 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3a56-57e8e300-3-10c8a340@87357206> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 09/26/2016 02:28 PM, Peter Senna Tschudin wrote: > Hi Archit, > > On Monday, September 26, 2016 10:31 CEST, Archit Taneja wrote: > >> Hi Peter, >> >> On 09/26/2016 01:57 PM, Peter Senna Tschudin wrote: >>> Patch 1/4 is already on linux-next, but what about this one? Ping? > >> >> I'd posted some queries a couple of times which you didn't answer to. >> Could you please respond to them before we try to get this merged? > > Your queries were already answered by similar questions. The commit messages and cover letter also addresses the design decisions of the code. But basically the driver usefulness to other scenarios is severely limited by the firmware used by both chips. And when using the firmware that goes with this specific hardware, then yes, the two chips are always expected to work together. But the main point is that with the custom firmware each chip do not behave as independent bridges anymore. Thanks for the reply. It wasn't entirely clear from the commit message that a custom firmware was exclusively used on this board to program these chips in order to get these 2 working together. I browsed the earlier versions of the patch and saw you explained the same thing to someone else. Sorry about that, I missed reading that before. Could you please specify this explicitly in the commit message? Perhaps, also mention that there is an external microcontroller with a custom firmware that manages most of the video operations. For the sake of completeness, could you also mention the part name of the controller that's running this firmware? Also, in the comments in the beginning of the driver: "However the physical bridges are automatically configured by the input video signal, and the driver has no access to the video processing pipeline." Is the automatic configuration done by the firmware, or is it a feature of the chips itself? > > On the other side, I was careful to use meaningful names for the registers, so a future implementation based on same chips can take the basics from this work, at least as a starting point. Thanks, that would be handy for later. I had some comments on the code. I'll share those in another reply. Archit > > Thanks, > > Peter > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project