From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752390AbbJLERQ (ORCPT ); Mon, 12 Oct 2015 00:17:16 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:55145 "EHLO mailout3.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750888AbbJLERN (ORCPT ); Mon, 12 Oct 2015 00:17:13 -0400 X-AuditID: cbfec7f4-f79c56d0000012ee-e2-561b344501a7 Subject: Re: [PATCH v6 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range To: Yakir Yang , Inki Dae , Andrzej Hajda , Joonyoung Shim , Seung-Woo Kim , Kyungmin Park , Jingoo Han , Thierry Reding , Rob Herring , joe@perches.com, Heiko Stuebner , Mark Yao References: <1444491357-26095-1-git-send-email-ykk@rock-chips.com> <1444491961-26799-1-git-send-email-ykk@rock-chips.com> <561B00D4.9060302@rock-chips.com> <561B0385.1070704@samsung.com> <561B1E65.1040806@rock-chips.com> <561B2E56.5020102@samsung.com> <561B3275.8000500@rock-chips.com> Cc: Russell King , djkurtz@chromium.org, dianders@chromium.org, Sean Paul , Kukjin Kim , Kumar Gala , emil.l.velikov@gmail.com, Ian Campbell , Gustavo Padovan , Kishon Vijay Abraham I , Pawel Moll , ajaynumb@gmail.com, robherring2@gmail.com, javier@osg.samsung.com, Andy Yan , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org From: Krzysztof Kozlowski Message-id: <561B3432.70004@samsung.com> Date: Mon, 12 Oct 2015 13:16:50 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-version: 1.0 In-reply-to: <561B3275.8000500@rock-chips.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUzMcRzH9/0915x+TvguTDu1WeMqMZ/MbjTmt9mseWhkHk79VriSu0rM 5ohRqjvV6lweanq8SrluCqU004webiV6vFYkijycZ8mdGP+93k+fvz4cKc2iPbh90bGiOlqp kjGu1MOfTR1L1i2bG+LXnSyH7mstNFSO5ZGga+1CcOWeQzYX3mXghOEKDR0fxxmofdxPgG4s j4b3padZmBwcpaHlVQmCdJuegrHXZQQU2y+wkGMbomCk30rB6Ig/6IZGSWh7nsJA88kxFsxD nTS037rIwPuBSRIMrXcI6GmXQE1mAwH67HIKTtfdY+Hzp08M9FU2IzBkvGSg5/t0aNFmsKtl QtnlMiScSkxhhBytlRLa01IJYeLFE0q4aexjhZIiOyOYTUmMYDvXRAhV+ceF1MQ3jGDROUK7 qZMUJoz1lJBmMSGhuvMyGSwNdV0VLqr2xYtqX8Ue18jB2jQyZtgjoaE2A2mRzT0ZuXCYX4Yz 05vIKZ6N2/ormGTkykn5AoS//jCyU8KOcFLSTcbZmsmr8FPDM8IZuPNVJB54W/+nVUDgb9fH fyck30jjE6lnfx9m+ABcVZTvmLOchF+ETUFOl+K9sWWyEDl5Fr8Nn9draSdL+Bn4S0Y/5WQX Xo4rhmwO5hwn5dhm9XHaJL8AV5W9JvWIN/63MP5rGf9r5SLShGaJcWExmr0RUf5yjTJKExcd IQ87GGVGU99ir0FX769sRDyHZNMknMUjREor4zVHohoR5kiZuyT0qMOShCuPHBXVB3er41Si phHN5SjZHMmlW+NbpHyEMlY8IIoxovpvSnAuHlokywnmvXUb3esiwq43bJfoixUq26HyCVP9 Wq+nQZGF5qUrFi8PbLJ24KwbaNhX9rDUzD549eHY1rzHigOJo5uzwzcwSWdc6nYEufkZTq5X Wrx6D8fNb/2asN/TOhLIDVYvbHn0zuijsMyjAnavy+1VVyjcutbs3CV6vrn9YdOj0EoZpYlU +vuQao3yF+N+0s0pAwAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12.10.2015 13:09, Yakir Yang wrote: > > > On 10/12/2015 11:51 AM, Krzysztof Kozlowski wrote: >> On 12.10.2015 11:43, Yakir Yang wrote: >>> On 10/12/2015 08:49 AM, Krzysztof Kozlowski wrote: >>>> On 12.10.2015 09:37, Yakir Yang wrote: >>>>> Hi Krzysztof, >>>>> >>>>> On 10/10/2015 11:46 PM, Yakir Yang wrote: >>>>>> Both hsync/vsync polarity and interlace mode can be parsed from >>>>>> drm display mode, and dynamic_range and ycbcr_coeff can be judge >>>>>> by the video code. >>>>>> >>>>>> But presumably Exynos still relies on the DT properties, so take >>>>>> good use of mode_fixup() in to achieve the compatibility hacks. >>>>>> >>>>>> Signed-off-by: Yakir Yang >>>>>> --- >>>>>> Changes in v6: None >>>>> + of_property_read_u32(dp_node, "hsync-active-high", >>>>> + &video->h_sync_polarity); >>>>> + of_property_read_u32(dp_node, "vsync-active-high", >>>>> + &video->v_sync_polarity); >>>>> + of_property_read_u32(dp_node, "interlaced", >>>>> + &video->interlaced); >>>>> +} >>>>> >>>>> >>>>> Sorry, forget to fix your previous comment here, would >>>>> remember to fix it to v7 version, wish v6 would collect >>>>> more comment/reviewed/ack. :) >>>> Right. >>>> >>>> You can send a v7 of only this patch. >>>> >>>> In the same time I would prefer not to chain-reply next version of >>>> entire patchset to cover letter of previous version. It confuses me >>>> because v6 appears UNDER v4 so I can't really find v6. I see v4 at the >>>> top of my email list. >>> Okay, I wish this chain-reply would make people easy to find the >>> previous comments, but actually it is little mess now. I would give >>> up this way to send patchset :) >>> >>>> In the same time the patchset is quite big. Put the latest version >>>> (with >>>> this issue above fixed!) on some repo and link it in cover letter. >>> Yeah, it's quite big now, I would like to back the patchset to previous >>> format, like: >>> >>> ---> [PATCH v6 00/17] Cover letter >>> |----> [PATCH v6 01/17] >>> |----> [PATCH ......] >>> |----> [PATCH v6 05/17] >>> |----> [PATCH v7 05/17] >>> |----> [PATCH ......] >>> |----> [PATCH v6 17/17] >>> >>> Is it right, and can resend the v6 to fix this chain-reply issue with >>> RESEND flag ([PATCH RESEND v6 ...]) ? >>> >>> ---> [PATCH RESEND v6 00/17] Cover letter >>> |----> [PATCH RESEND v6 01/17] >>> |----> [PATCH ......] >>> |----> [PATCH RESEND v6 05/17] >>> |----> [PATCH v7 05/17] >>> |----> [PATCH ......] >>> |----> [PATCH RESEND v6 17/17] >>> >> No, don't resend everything. I mean in this case with such big patchset >> if you want to fix one patch just send one email [PATCH v7 05/17] >> chained to proper id (cover letter or v6-05/17). Add a short note that >> this is resend of only one patch from the set. > > Oh, understand now, just keep this chain-reply no changes for now. > > ----> [PATCH v4 00/16] Cover letter > |----> [PATCH v5 00/17] Covert letter > |----> [PATCH ......] > | > |----> [PATCH v6 00/17] Covert letter > |----> [PATCH v6 01/17] > |----> [PATCH ......] > |----> [PATCH v6 17/17] > |----> [PATCH v7 05/17] Yes, I think it is correct. Maybe just add a note (in patch changelog) that this is v7 of only fifth patch. Best regards, Krzysztof From mboxrd@z Thu Jan 1 00:00:00 1970 From: k.kozlowski@samsung.com (Krzysztof Kozlowski) Date: Mon, 12 Oct 2015 13:16:50 +0900 Subject: [PATCH v6 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range In-Reply-To: <561B3275.8000500@rock-chips.com> References: <1444491357-26095-1-git-send-email-ykk@rock-chips.com> <1444491961-26799-1-git-send-email-ykk@rock-chips.com> <561B00D4.9060302@rock-chips.com> <561B0385.1070704@samsung.com> <561B1E65.1040806@rock-chips.com> <561B2E56.5020102@samsung.com> <561B3275.8000500@rock-chips.com> Message-ID: <561B3432.70004@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 12.10.2015 13:09, Yakir Yang wrote: > > > On 10/12/2015 11:51 AM, Krzysztof Kozlowski wrote: >> On 12.10.2015 11:43, Yakir Yang wrote: >>> On 10/12/2015 08:49 AM, Krzysztof Kozlowski wrote: >>>> On 12.10.2015 09:37, Yakir Yang wrote: >>>>> Hi Krzysztof, >>>>> >>>>> On 10/10/2015 11:46 PM, Yakir Yang wrote: >>>>>> Both hsync/vsync polarity and interlace mode can be parsed from >>>>>> drm display mode, and dynamic_range and ycbcr_coeff can be judge >>>>>> by the video code. >>>>>> >>>>>> But presumably Exynos still relies on the DT properties, so take >>>>>> good use of mode_fixup() in to achieve the compatibility hacks. >>>>>> >>>>>> Signed-off-by: Yakir Yang >>>>>> --- >>>>>> Changes in v6: None >>>>> + of_property_read_u32(dp_node, "hsync-active-high", >>>>> + &video->h_sync_polarity); >>>>> + of_property_read_u32(dp_node, "vsync-active-high", >>>>> + &video->v_sync_polarity); >>>>> + of_property_read_u32(dp_node, "interlaced", >>>>> + &video->interlaced); >>>>> +} >>>>> >>>>> >>>>> Sorry, forget to fix your previous comment here, would >>>>> remember to fix it to v7 version, wish v6 would collect >>>>> more comment/reviewed/ack. :) >>>> Right. >>>> >>>> You can send a v7 of only this patch. >>>> >>>> In the same time I would prefer not to chain-reply next version of >>>> entire patchset to cover letter of previous version. It confuses me >>>> because v6 appears UNDER v4 so I can't really find v6. I see v4 at the >>>> top of my email list. >>> Okay, I wish this chain-reply would make people easy to find the >>> previous comments, but actually it is little mess now. I would give >>> up this way to send patchset :) >>> >>>> In the same time the patchset is quite big. Put the latest version >>>> (with >>>> this issue above fixed!) on some repo and link it in cover letter. >>> Yeah, it's quite big now, I would like to back the patchset to previous >>> format, like: >>> >>> ---> [PATCH v6 00/17] Cover letter >>> |----> [PATCH v6 01/17] >>> |----> [PATCH ......] >>> |----> [PATCH v6 05/17] >>> |----> [PATCH v7 05/17] >>> |----> [PATCH ......] >>> |----> [PATCH v6 17/17] >>> >>> Is it right, and can resend the v6 to fix this chain-reply issue with >>> RESEND flag ([PATCH RESEND v6 ...]) ? >>> >>> ---> [PATCH RESEND v6 00/17] Cover letter >>> |----> [PATCH RESEND v6 01/17] >>> |----> [PATCH ......] >>> |----> [PATCH RESEND v6 05/17] >>> |----> [PATCH v7 05/17] >>> |----> [PATCH ......] >>> |----> [PATCH RESEND v6 17/17] >>> >> No, don't resend everything. I mean in this case with such big patchset >> if you want to fix one patch just send one email [PATCH v7 05/17] >> chained to proper id (cover letter or v6-05/17). Add a short note that >> this is resend of only one patch from the set. > > Oh, understand now, just keep this chain-reply no changes for now. > > ----> [PATCH v4 00/16] Cover letter > |----> [PATCH v5 00/17] Covert letter > |----> [PATCH ......] > | > |----> [PATCH v6 00/17] Covert letter > |----> [PATCH v6 01/17] > |----> [PATCH ......] > |----> [PATCH v6 17/17] > |----> [PATCH v7 05/17] Yes, I think it is correct. Maybe just add a note (in patch changelog) that this is v7 of only fifth patch. Best regards, Krzysztof