From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752053AbdBAJpJ (ORCPT ); Wed, 1 Feb 2017 04:45:09 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:36746 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751535AbdBAJpH (ORCPT ); Wed, 1 Feb 2017 04:45:07 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 34BB360A0B Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=architt@codeaurora.org Subject: Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge To: Jani Nikula , Peter Senna Tschudin References: <4232c88a99f44a24287d04d74b891e2eb139864c.1483301745.git.peter.senna@collabora.com> <759f96e2-43da-45ba-cf8d-55bc1f6e8442@codeaurora.org> <20170128141646.GA21291@collabora.com> <877f5ciilg.fsf@intel.com> 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 From: Archit Taneja Message-ID: Date: Wed, 1 Feb 2017 15:14:42 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <877f5ciilg.fsf@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/30/2017 10:35 PM, Jani Nikula wrote: > 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. :( It seems like there is a HW issue which prevents them from reading EDID from an offset. So, I'm not sure if it is a hack or a HW limitation. One way around this would be to hide the HW requirement in the get_edid_block func pointer passed to drm_do_get_edid(). This would, however, result in more i2c reads (equal to # of extension blocks) than what the patch currently does. Peter, if you think doing extra EDID reads isn't too costly on your platform, you could consider using drm_do_get_edid(). If not, I guess you'll miss out on the additional functionality Jani is going to add in the future. Thanks, Archit > > 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 > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From mboxrd@z Thu Jan 1 00:00:00 1970 From: Archit Taneja Subject: Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge Date: Wed, 1 Feb 2017 15:14:42 +0530 Message-ID: References: <4232c88a99f44a24287d04d74b891e2eb139864c.1483301745.git.peter.senna@collabora.com> <759f96e2-43da-45ba-cf8d-55bc1f6e8442@codeaurora.org> <20170128141646.GA21291@collabora.com> <877f5ciilg.fsf@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <877f5ciilg.fsf@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Jani Nikula , Peter Senna Tschudin Cc: mark.rutland@arm.com, martyn.welch@collabora.co.uk, daniel.vetter@ffwll.ch, peter.senna@gmail.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, ykk@rock-chips.com, jslaby@suse.cz, 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, enric.balletbo@collabora.com, rmk+kernel@armlinux.org.uk, robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org, gregkh@linuxfoundation.org, tiwai@suse.com, kernel@pengutronix.de, galak@codeaurora.org, Fabio Estevam , akpm@linux-foundation.org, shawnguo@kernel.org, davem@davemloft.net List-Id: devicetree@vger.kernel.org On 01/30/2017 10:35 PM, Jani Nikula wrote: > 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. :( It seems like there is a HW issue which prevents them from reading EDID from an offset. So, I'm not sure if it is a hack or a HW limitation. One way around this would be to hide the HW requirement in the get_edid_block func pointer passed to drm_do_get_edid(). This would, however, result in more i2c reads (equal to # of extension blocks) than what the patch currently does. Peter, if you think doing extra EDID reads isn't too costly on your platform, you could consider using drm_do_get_edid(). If not, I guess you'll miss out on the additional functionality Jani is going to add in the future. Thanks, Archit > > 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 > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From mboxrd@z Thu Jan 1 00:00:00 1970 From: architt@codeaurora.org (Archit Taneja) Date: Wed, 1 Feb 2017 15:14:42 +0530 Subject: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge In-Reply-To: <877f5ciilg.fsf@intel.com> References: <4232c88a99f44a24287d04d74b891e2eb139864c.1483301745.git.peter.senna@collabora.com> <759f96e2-43da-45ba-cf8d-55bc1f6e8442@codeaurora.org> <20170128141646.GA21291@collabora.com> <877f5ciilg.fsf@intel.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 01/30/2017 10:35 PM, Jani Nikula wrote: > 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. :( It seems like there is a HW issue which prevents them from reading EDID from an offset. So, I'm not sure if it is a hack or a HW limitation. One way around this would be to hide the HW requirement in the get_edid_block func pointer passed to drm_do_get_edid(). This would, however, result in more i2c reads (equal to # of extension blocks) than what the patch currently does. Peter, if you think doing extra EDID reads isn't too costly on your platform, you could consider using drm_do_get_edid(). If not, I guess you'll miss out on the additional functionality Jani is going to add in the future. Thanks, Archit > > BR, > Jani. > > >> >> [...] >> >> I fixed all your other suggestions. Thank you! >> _______________________________________________ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project