From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753263AbdA3RIv (ORCPT ); Mon, 30 Jan 2017 12:08:51 -0500 Received: from mga04.intel.com ([192.55.52.120]:13716 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750805AbdA3RIt (ORCPT ); Mon, 30 Jan 2017 12:08:49 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,312,1477983600"; d="scan'208";a="815077833" From: Jani Nikula To: Peter Senna Tschudin , Archit Taneja Cc: mark.rutland@arm.com, daniel.vetter@ffwll.ch, peter.senna@gmail.com, dri-devel@lists.freedesktop.org, tiwai@suse.com, ykk@rock-chips.com, jslaby@suse.cz, martyn.welch@collabora.co.uk, mchehab@osg.samsung.com, linux@armlinux.org.uk, javier@dowhile0.org, treding@nvidia.com, linux@roeck-us.net, martin.donnelly@ge.com, devicetree@vger.kernel.org, pawel.moll@arm.com, ijc+devicetree@hellion.org.uk, Fabio Estevam , rmk+kernel@armlinux.org.uk, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, kernel@pengutronix.de, galak@codeaurora.org, enric.balletbo@collabora.com, akpm@linux-foundation.org, shawnguo@kernel.org, davem@davemloft.net Subject: Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge In-Reply-To: <20170128141646.GA21291@collabora.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <4232c88a99f44a24287d04d74b891e2eb139864c.1483301745.git.peter.senna@collabora.com> <759f96e2-43da-45ba-cf8d-55bc1f6e8442@codeaurora.org> <20170128141646.GA21291@collabora.com> Date: Mon, 30 Jan 2017 19:05:31 +0200 Message-ID: <877f5ciilg.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 28 Jan 2017, Peter Senna Tschudin wrote: > On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote: > Hi Archit, > > Thank you for the comments! > > [...] >> > + total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH; >> > + if (total_size > EDID_LENGTH) { >> > + kfree(block); >> > + block = kmalloc(total_size, GFP_KERNEL); >> > + if (!block) >> > + return NULL; >> > + >> > + /* Yes, read the entire buffer, and do not skip the first >> > + * EDID_LENGTH bytes. >> > + */ >> >> Is this the reason why you aren't using drm_do_get_edid()? > > Yes, for some hw specific reason, it is necessary to read the entire > EDID buffer starting from 0, not block by block. Hrmh, I'm planning on moving the edid override and firmware edid mechanisms at the drm_do_get_edid() level to be able to truly and transparently use a different edid. Currently, they're only used for modes, really, and lead to some info retrieved from overrides, some from the real edid. This kind of hacks will bypass the override/firmware edid mechanisms then too. :( BR, Jani. > > [...] > > I fixed all your other suggestions. Thank you! > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center