From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751301AbdBBJ4f (ORCPT ); Thu, 2 Feb 2017 04:56:35 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:46800 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751037AbdBBJ4c (ORCPT ); Thu, 2 Feb 2017 04:56:32 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 20AB460779 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: Peter Senna Tschudin , Daniel Vetter References: <2955-5891d280-1-64686980@191354544> Cc: gregkh@linuxfoundation.org, ykk@rock-chips.com, kernel@pengutronix.de, Jani Nikula , Peter Senna Tschudin , robh+dt@kernel.org, devicetree@vger.kernel.org, Fabio Estevam , pawel.moll@arm.com, davem@davemloft.net, martyn.welch@collabora.co.uk, enric.balletbo@collabora.com, akpm@linux-foundation.org, martin.donnelly@ge.com, daniel.vetter@ffwll.ch, galak@codeaurora.org, linux@armlinux.org.uk, treding@nvidia.com, tiwai@suse.com, javier@dowhile0.org, mark.rutland@arm.com, rmk+kernel@armlinux.org.uk, dri-devel@lists.freedesktop.org, shawnguo@kernel.org, mchehab@osg.samsung.com, jslaby@suse.cz, ijc+devicetree@hellion.org.uk, peter.senna@gmail.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux@roeck-us.net From: Archit Taneja Message-ID: Date: Thu, 2 Feb 2017 15:26:15 +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: <2955-5891d280-1-64686980@191354544> 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 On 02/01/2017 05:51 PM, Peter Senna Tschudin wrote: > > On 01 February, 2017 12:35 CET, Daniel Vetter wrote: > >> On Wed, Feb 01, 2017 at 10:58:43AM +0000, Peter Senna Tschudin wrote: >>> Hi Archit, >>> >>> On 01 February, 2017 10:44 CET, Archit Taneja wrote: >>> >>>> >>>> >>>> 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. >>> >>> My concern is that for almost one year now, every time I fix something >>> one or two new requests are made. I'm happy to fix the driver, but I >>> want a list of the changes that are required to get it upstream, before >>> I make more changes. Can we agree on exactly what is preventing this >>> driver to get upstream? Then I'll fix it. >> >> I think addressing this edid reading question post-merge is perfectly >> fine. Aside, want to keep maintaing your stuff as part of the drm-misc >> group, with the drivers-in-misc experiment? The edid thing was only a suggestion. As Daniel said, it's okay to work on it post merge. Please do fix the minor comments I mentioned in the latest patch set. I'll pull in the first 3 patches once Rob H gives an Ack on the DT bindings patch. The 4th patch needs to go through the SoC maintainer. Thanks, Archit > > Yes, sure! > >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch > > > > > > -- 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: Thu, 2 Feb 2017 15:26:15 +0530 Message-ID: References: <2955-5891d280-1-64686980@191354544> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2955-5891d280-1-64686980@191354544> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Peter Senna Tschudin , Daniel Vetter Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org, ykk-TNX95d0MmH7DzftRWevZcw@public.gmane.org, kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org, Jani Nikula , Peter Senna Tschudin , robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Fabio Estevam , pawel.moll-5wv7dgnIgG8@public.gmane.org, davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org, martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org, enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, martin.donnelly-JJi787mZWgc@public.gmane.org, daniel.vetter-/w4YWyX8dFk@public.gmane.org, galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org, treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org, tiwai-IBi9RG/b67k@public.gmane.org, javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org, mark.rutland-5wv7dgnIgG8@public.gmane.org, rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, mchehab-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org, jslaby-AlSwsSmVLrQ@public.gmane.org, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org, peter.senna-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TbrhsbdSgBK9A@public.gmane.org List-Id: devicetree@vger.kernel.org On 02/01/2017 05:51 PM, Peter Senna Tschudin wrote: > > On 01 February, 2017 12:35 CET, Daniel Vetter wrote: > >> On Wed, Feb 01, 2017 at 10:58:43AM +0000, Peter Senna Tschudin wrote: >>> Hi Archit, >>> >>> On 01 February, 2017 10:44 CET, Archit Taneja wrote: >>> >>>> >>>> >>>> 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. >>> >>> My concern is that for almost one year now, every time I fix something >>> one or two new requests are made. I'm happy to fix the driver, but I >>> want a list of the changes that are required to get it upstream, before >>> I make more changes. Can we agree on exactly what is preventing this >>> driver to get upstream? Then I'll fix it. >> >> I think addressing this edid reading question post-merge is perfectly >> fine. Aside, want to keep maintaing your stuff as part of the drm-misc >> group, with the drivers-in-misc experiment? The edid thing was only a suggestion. As Daniel said, it's okay to work on it post merge. Please do fix the minor comments I mentioned in the latest patch set. I'll pull in the first 3 patches once Rob H gives an Ack on the DT bindings patch. The 4th patch needs to go through the SoC maintainer. Thanks, Archit > > Yes, sure! > >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch > > > > > > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: architt@codeaurora.org (Archit Taneja) Date: Thu, 2 Feb 2017 15:26:15 +0530 Subject: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge In-Reply-To: <2955-5891d280-1-64686980@191354544> References: <2955-5891d280-1-64686980@191354544> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 02/01/2017 05:51 PM, Peter Senna Tschudin wrote: > > On 01 February, 2017 12:35 CET, Daniel Vetter wrote: > >> On Wed, Feb 01, 2017 at 10:58:43AM +0000, Peter Senna Tschudin wrote: >>> Hi Archit, >>> >>> On 01 February, 2017 10:44 CET, Archit Taneja wrote: >>> >>>> >>>> >>>> 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. >>> >>> My concern is that for almost one year now, every time I fix something >>> one or two new requests are made. I'm happy to fix the driver, but I >>> want a list of the changes that are required to get it upstream, before >>> I make more changes. Can we agree on exactly what is preventing this >>> driver to get upstream? Then I'll fix it. >> >> I think addressing this edid reading question post-merge is perfectly >> fine. Aside, want to keep maintaing your stuff as part of the drm-misc >> group, with the drivers-in-misc experiment? The edid thing was only a suggestion. As Daniel said, it's okay to work on it post merge. Please do fix the minor comments I mentioned in the latest patch set. I'll pull in the first 3 patches once Rob H gives an Ack on the DT bindings patch. The 4th patch needs to go through the SoC maintainer. Thanks, Archit > > Yes, sure! > >> -Daniel >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch > > > > > > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project