From: Doug Anderson <dianders@chromium.org> To: Steev Klimaszewski <steev@kali.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Andrzej Hajda <a.hajda@samsung.com>, David Airlie <airlied@linux.ie>, Bjorn Andersson <bjorn.andersson@linaro.org>, Daniel Vetter <daniel@ffwll.ch>, dri-devel <dri-devel@lists.freedesktop.org>, Jeffrey Hugo <jeffrey.l.hugo@gmail.com>, Jernej Skrabec <jernej.skrabec@siol.net>, Jonas Karlman <jonas@kwiboo.se>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Neil Armstrong <narmstrong@baylibre.com>, Rob Clark <robdclark@chromium.org>, Rob Clark <robdclark@gmail.com>, Sean Paul <seanpaul@chromium.org>, Steev Klimaszewski <steev@gentoo.org> Subject: Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can Date: Fri, 10 Jul 2020 07:47:09 -0700 [thread overview] Message-ID: <CAD=FV=WB_4xLe9UZX3eVemybQ1neXJVZgzrDCW-xUxbAM6hCTA@mail.gmail.com> (raw) In-Reply-To: <f81f0d22-85d6-66eb-c8d9-345757f53959@kali.org> Hi, On Thu, Jul 9, 2020 at 11:15 PM Steev Klimaszewski <steev@kali.org> wrote: > > Hi, > > On 7/9/20 11:12 PM, Doug Anderson wrote: > >> root@c630:~# bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/') > >> root@c630:~# i2cdump ${bus} 0x50 i > edid > >> WARNING! This program can confuse your I2C bus, cause data loss and worse! > >> I will probe file /dev/i2c-16, address 0x50, mode i2c block > >> Continue? [Y/n] > >> root@c630:~# edid-decode edid > >> edid-decode (hex): > >> > >> 00 ff ff ff ff ff ff 00 09 e5 d1 07 00 00 00 00 > >> 01 1c 01 04 a5 1d 11 78 0a 1d b0 a6 58 54 9e 26 > >> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 > >> 01 01 01 01 01 01 c0 39 80 18 71 38 28 40 30 20 > >> 36 00 26 a5 10 00 00 1a 00 00 00 00 00 00 00 00 > >> 00 00 00 00 00 00 00 00 00 1a 00 00 00 fe 00 42 > >> 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe > >> 00 4e 56 31 33 33 46 48 4d 2d 4e 36 31 0a 00 9a > >> > >> 03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb > >> fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73 > >> 44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61 > >> 92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2 > >> 66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70 > >> 43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc > >> 45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3 > >> 30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29 > >> > >> ---------------- > >> > >> EDID version: 1.4 > >> Manufacturer: BOE Model 2001 Serial Number 0 > >> Made in week 1 of 2018 > >> Digital display > >> 8 bits per primary color channel > >> DisplayPort interface > >> Maximum image size: 29 cm x 17 cm > >> Gamma: 2.20 > >> Supported color formats: RGB 4:4:4, YCrCb 4:4:4 > >> First detailed timing includes the native pixel format and preferred > >> refresh rate > >> Color Characteristics > >> Red: 0.6484, 0.3447 > >> Green: 0.3310, 0.6181 > >> Blue: 0.1503, 0.0615 > >> White: 0.3125, 0.3281 > >> Established Timings I & II: none > >> Standard Timings: none > >> Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm > >> 1920 1968 2000 2200 ( 48 32 200) > >> 1080 1083 1089 1120 ( 3 6 31) > >> +hsync -vsync > >> VertFreq: 60.000 Hz, HorFreq: 67.200 kHz > >> Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00 > >> 00 00 00 00 00 00 00 00 1a ................ > >> Alphanumeric Data String: BOE CQ > >> Alphanumeric Data String: NV133FHM-N61 > >> Checksum: 0x9a > >> > >> ---------------- > >> > >> Unknown EDID Extension Block 0x03 > >> 03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb .&.w...qo...C.j. > >> fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73 ... 9."nehwp..4s > >> 44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61 D!...m.b.*|...ja > >> 92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2 ...SL9...#.H.9.. > >> 66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70 f.p..w.J..Lrn]Gp > >> 43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc C......x..A..j(. > >> 45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3 E....*..5.4.>.^. > >> 30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29 0^.).H.....1..;) > >> Checksum: 0x29 (should be 0x82) > >> > >> > >> - My edid does in fact say it's 8bit > > Crazy! Mine: > > > > Extracted contents: > > header: 00 ff ff ff ff ff ff 00 > > serial number: 09 e5 2d 08 00 00 00 00 23 1c > > version: 01 04 > > basic params: 95 1d 11 78 02 > > chroma info: d5 00 a6 58 54 9f 27 0f 4f 57 > > established: 00 00 00 > > standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 > > descriptor 1: c0 39 80 18 71 38 28 40 30 20 36 00 26 a5 10 00 00 1a > > descriptor 2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > descriptor 3: 00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20 > > descriptor 4: 00 00 00 fe 00 4e 56 31 33 33 46 48 4d 2d 4e 36 32 0a > > extensions: 00 > > checksum: 40 > > > > Manufacturer: BOE Model 82d Serial Number 0 > > Made week 35 of 2018 > > EDID version: 1.4 > > Digital display > > 6 bits per primary color channel > > DisplayPort interface > > Maximum image size: 29 cm x 17 cm > > Gamma: 2.20 > > Supported color formats: RGB 4:4:4 > > First detailed timing is preferred timing > > Established timings supported: > > Standard timings supported: > > Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm > > 1920 1968 2000 2200 hborder 0 > > 1080 1083 1089 1120 vborder 0 > > +hsync -vsync > > Manufacturer-specified data, tag 0 > > ASCII string: BOE > > ASCII string: NV133FHM-N62 > > Checksum: 0x40 (valid) > > > > Unknown extension block > > > > EDID block does NOT conform to EDID 1.3! > > Missing name descriptor > > Missing monitor ranges > > Detailed block string not properly terminated > > EDID block does not conform at all! > > Has 128 nonconformant extension block(s) > > I did attempt to modify the patch, and I don't think I did it correctly > > Around line 232, I changed > > IS_SC7180_TARGET(c->hw.hwversion)) > > to > > IS_SC7180_TARGET(c->hw.hwversion) || > > IS_SDM845_TARGET(c->hw.hwversion)) > > > But it would seem that only gets us 1/2 way there... > > https://dev.gentoo.org/~steev/files/image2.jpg > > > But should I continue on this path, It's probably worth getting dithering working on your sdm845 anyway in case anyone actually does put a 6bpp panel on this SoC. > or should we be finding others who > have an N61 and see what their EDID reports? I have an email out to BOE, but it might take a little while to get a response. I'll see what they say. If they say that the panel actually supports 8bpp then it's a no-brainer and we should just switch to 8bpp and be done. ...but if they say it's a 6bpp panel that has its own dither logic then it gets more complicated. Initially one would think there should be very little downside in defining the panel as an 8bpp panel and calling it done. ...except that it conflicts with some other work that I have in progress. :-P Specifically if you treat the panel as 6bpp and then reduce the blanking a tiny bit you can actually save 75 mW of total system power on my board (probably similar on your board since you have the same bridge chip). You can see a patch to do that here: https://crrev.com/c/2276384 ...so I'm hoping to get some clarity from BOE both on the true bits per pixel and whether my proposed timings are valid before moving forward. Is that OK? -Doug
WARNING: multiple messages have this Message-ID (diff)
From: Doug Anderson <dianders@chromium.org> To: Steev Klimaszewski <steev@kali.org> Cc: Rob Clark <robdclark@chromium.org>, Jernej Skrabec <jernej.skrabec@siol.net>, Jeffrey Hugo <jeffrey.l.hugo@gmail.com>, David Airlie <airlied@linux.ie>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Jonas Karlman <jonas@kwiboo.se>, LKML <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Neil Armstrong <narmstrong@baylibre.com>, Andrzej Hajda <a.hajda@samsung.com>, Sean Paul <seanpaul@chromium.org>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Steev Klimaszewski <steev@gentoo.org> Subject: Re: [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can Date: Fri, 10 Jul 2020 07:47:09 -0700 [thread overview] Message-ID: <CAD=FV=WB_4xLe9UZX3eVemybQ1neXJVZgzrDCW-xUxbAM6hCTA@mail.gmail.com> (raw) In-Reply-To: <f81f0d22-85d6-66eb-c8d9-345757f53959@kali.org> Hi, On Thu, Jul 9, 2020 at 11:15 PM Steev Klimaszewski <steev@kali.org> wrote: > > Hi, > > On 7/9/20 11:12 PM, Doug Anderson wrote: > >> root@c630:~# bus=$(i2cdetect -l | grep sn65 | sed 's/i2c-\([0-9]*\).*$/\1/') > >> root@c630:~# i2cdump ${bus} 0x50 i > edid > >> WARNING! This program can confuse your I2C bus, cause data loss and worse! > >> I will probe file /dev/i2c-16, address 0x50, mode i2c block > >> Continue? [Y/n] > >> root@c630:~# edid-decode edid > >> edid-decode (hex): > >> > >> 00 ff ff ff ff ff ff 00 09 e5 d1 07 00 00 00 00 > >> 01 1c 01 04 a5 1d 11 78 0a 1d b0 a6 58 54 9e 26 > >> 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 > >> 01 01 01 01 01 01 c0 39 80 18 71 38 28 40 30 20 > >> 36 00 26 a5 10 00 00 1a 00 00 00 00 00 00 00 00 > >> 00 00 00 00 00 00 00 00 00 1a 00 00 00 fe 00 42 > >> 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fe > >> 00 4e 56 31 33 33 46 48 4d 2d 4e 36 31 0a 00 9a > >> > >> 03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb > >> fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73 > >> 44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61 > >> 92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2 > >> 66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70 > >> 43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc > >> 45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3 > >> 30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29 > >> > >> ---------------- > >> > >> EDID version: 1.4 > >> Manufacturer: BOE Model 2001 Serial Number 0 > >> Made in week 1 of 2018 > >> Digital display > >> 8 bits per primary color channel > >> DisplayPort interface > >> Maximum image size: 29 cm x 17 cm > >> Gamma: 2.20 > >> Supported color formats: RGB 4:4:4, YCrCb 4:4:4 > >> First detailed timing includes the native pixel format and preferred > >> refresh rate > >> Color Characteristics > >> Red: 0.6484, 0.3447 > >> Green: 0.3310, 0.6181 > >> Blue: 0.1503, 0.0615 > >> White: 0.3125, 0.3281 > >> Established Timings I & II: none > >> Standard Timings: none > >> Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm > >> 1920 1968 2000 2200 ( 48 32 200) > >> 1080 1083 1089 1120 ( 3 6 31) > >> +hsync -vsync > >> VertFreq: 60.000 Hz, HorFreq: 67.200 kHz > >> Manufacturer-Specified Display Descriptor (0x00): 00 00 00 00 00 00 00 > >> 00 00 00 00 00 00 00 00 1a ................ > >> Alphanumeric Data String: BOE CQ > >> Alphanumeric Data String: NV133FHM-N61 > >> Checksum: 0x9a > >> > >> ---------------- > >> > >> Unknown EDID Extension Block 0x03 > >> 03 26 0a 77 ab 1c 05 71 6f 1d 8c f1 43 ce 6a bb .&.w...qo...C.j. > >> fb d3 11 20 39 07 22 6e 65 68 77 70 d3 05 34 73 ... 9."nehwp..4s > >> 44 21 8b fd f5 6d 11 62 94 2a 7c fa 93 ba 6a 61 D!...m.b.*|...ja > >> 92 da 15 53 4c 39 eb f7 86 23 97 48 e9 39 09 d2 ...SL9...#.H.9.. > >> 66 02 70 bb e2 77 0f 4a a3 a0 4c 72 6e 5d 47 70 f.p..w.J..Lrn]Gp > >> 43 c2 13 f3 b2 d9 b9 78 02 be 41 82 15 6a 28 dc C......x..A..j(. > >> 45 0f 9d eb 0f 2a cc e8 35 8d 34 7f 3e 84 5e a3 E....*..5.4.>.^. > >> 30 5e 1e 29 0a 48 0c d1 0a c4 08 31 03 a9 3b 29 0^.).H.....1..;) > >> Checksum: 0x29 (should be 0x82) > >> > >> > >> - My edid does in fact say it's 8bit > > Crazy! Mine: > > > > Extracted contents: > > header: 00 ff ff ff ff ff ff 00 > > serial number: 09 e5 2d 08 00 00 00 00 23 1c > > version: 01 04 > > basic params: 95 1d 11 78 02 > > chroma info: d5 00 a6 58 54 9f 27 0f 4f 57 > > established: 00 00 00 > > standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 > > descriptor 1: c0 39 80 18 71 38 28 40 30 20 36 00 26 a5 10 00 00 1a > > descriptor 2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > descriptor 3: 00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20 > > descriptor 4: 00 00 00 fe 00 4e 56 31 33 33 46 48 4d 2d 4e 36 32 0a > > extensions: 00 > > checksum: 40 > > > > Manufacturer: BOE Model 82d Serial Number 0 > > Made week 35 of 2018 > > EDID version: 1.4 > > Digital display > > 6 bits per primary color channel > > DisplayPort interface > > Maximum image size: 29 cm x 17 cm > > Gamma: 2.20 > > Supported color formats: RGB 4:4:4 > > First detailed timing is preferred timing > > Established timings supported: > > Standard timings supported: > > Detailed mode: Clock 147.840 MHz, 294 mm x 165 mm > > 1920 1968 2000 2200 hborder 0 > > 1080 1083 1089 1120 vborder 0 > > +hsync -vsync > > Manufacturer-specified data, tag 0 > > ASCII string: BOE > > ASCII string: NV133FHM-N62 > > Checksum: 0x40 (valid) > > > > Unknown extension block > > > > EDID block does NOT conform to EDID 1.3! > > Missing name descriptor > > Missing monitor ranges > > Detailed block string not properly terminated > > EDID block does not conform at all! > > Has 128 nonconformant extension block(s) > > I did attempt to modify the patch, and I don't think I did it correctly > > Around line 232, I changed > > IS_SC7180_TARGET(c->hw.hwversion)) > > to > > IS_SC7180_TARGET(c->hw.hwversion) || > > IS_SDM845_TARGET(c->hw.hwversion)) > > > But it would seem that only gets us 1/2 way there... > > https://dev.gentoo.org/~steev/files/image2.jpg > > > But should I continue on this path, It's probably worth getting dithering working on your sdm845 anyway in case anyone actually does put a 6bpp panel on this SoC. > or should we be finding others who > have an N61 and see what their EDID reports? I have an email out to BOE, but it might take a little while to get a response. I'll see what they say. If they say that the panel actually supports 8bpp then it's a no-brainer and we should just switch to 8bpp and be done. ...but if they say it's a 6bpp panel that has its own dither logic then it gets more complicated. Initially one would think there should be very little downside in defining the panel as an 8bpp panel and calling it done. ...except that it conflicts with some other work that I have in progress. :-P Specifically if you treat the panel as 6bpp and then reduce the blanking a tiny bit you can actually save 75 mW of total system power on my board (probably similar on your board since you have the same bridge chip). You can see a patch to do that here: https://crrev.com/c/2276384 ...so I'm hoping to get some clarity from BOE both on the true bits per pixel and whether my proposed timings are valid before moving forward. Is that OK? -Doug _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-07-10 14:47 UTC|newest] Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-18 22:35 [PATCH v3 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO B116XAK01 + other DP Douglas Anderson 2019-12-18 22:35 ` Douglas Anderson 2019-12-18 22:35 ` [PATCH v3 1/9] drm/bridge: ti-sn65dsi86: Split the setting of the dp and dsi rates Douglas Anderson 2019-12-18 22:35 ` Douglas Anderson 2020-02-03 23:31 ` Bjorn Andersson 2020-02-03 23:31 ` Bjorn Andersson 2019-12-18 22:35 ` [PATCH v3 2/9] drm/bridge: ti-sn65dsi86: zero is never greater than an unsigned int Douglas Anderson 2019-12-18 22:35 ` Douglas Anderson 2020-02-03 23:32 ` Bjorn Andersson 2020-02-03 23:32 ` Bjorn Andersson 2019-12-18 22:35 ` [PATCH v3 3/9] drm/bridge: ti-sn65dsi86: Don't use MIPI variables for DP link Douglas Anderson 2019-12-18 22:35 ` Douglas Anderson 2020-02-03 23:33 ` Bjorn Andersson 2020-02-03 23:33 ` Bjorn Andersson 2019-12-18 22:35 ` [PATCH v3 4/9] drm/bridge: ti-sn65dsi86: Config number of DP lanes Mo' Betta Douglas Anderson 2019-12-18 22:35 ` Douglas Anderson 2020-02-03 23:34 ` Bjorn Andersson 2020-02-03 23:34 ` Bjorn Andersson 2019-12-18 22:35 ` [PATCH v3 5/9] drm/bridge: ti-sn65dsi86: Read num lanes from the DP sink Douglas Anderson 2019-12-18 22:35 ` Douglas Anderson 2020-02-03 23:35 ` Bjorn Andersson 2020-02-03 23:35 ` Bjorn Andersson 2019-12-18 22:35 ` [PATCH v3 6/9] drm/bridge: ti-sn65dsi86: Use 18-bit DP if we can Douglas Anderson 2019-12-18 22:35 ` Douglas Anderson 2020-02-03 23:37 ` Bjorn Andersson 2020-02-03 23:37 ` Bjorn Andersson 2020-02-04 0:21 ` Doug Anderson 2020-02-04 0:21 ` Doug Anderson 2020-02-12 23:04 ` Doug Anderson 2020-02-12 23:04 ` Doug Anderson 2020-02-13 9:17 ` Neil Armstrong 2020-02-13 9:17 ` Neil Armstrong [not found] ` <20200710011935.GA7056@gentoo.org> 2020-07-10 1:38 ` Doug Anderson 2020-07-10 1:38 ` Doug Anderson 2020-07-10 2:14 ` Doug Anderson 2020-07-10 2:14 ` Doug Anderson 2020-07-10 3:12 ` Steev Klimaszewski 2020-07-10 3:12 ` Steev Klimaszewski 2020-07-10 3:17 ` Steev Klimaszewski 2020-07-10 3:17 ` Steev Klimaszewski 2020-07-10 3:43 ` Steev Klimaszewski 2020-07-10 3:43 ` Steev Klimaszewski 2020-07-10 4:12 ` Doug Anderson 2020-07-10 4:12 ` Doug Anderson 2020-07-10 6:15 ` Steev Klimaszewski 2020-07-10 6:15 ` Steev Klimaszewski 2020-07-10 14:16 ` Rob Clark 2020-07-10 14:16 ` Rob Clark 2020-07-10 14:47 ` Doug Anderson [this message] 2020-07-10 14:47 ` Doug Anderson 2020-07-10 17:10 ` Steev Klimaszewski 2020-07-10 17:10 ` Steev Klimaszewski 2020-07-14 15:31 ` Doug Anderson 2020-07-14 15:31 ` Doug Anderson 2020-09-02 14:37 ` Doug Anderson 2020-09-02 14:37 ` Doug Anderson 2019-12-18 22:35 ` [PATCH v3 7/9] drm/bridge: ti-sn65dsi86: Group DP link training bits in a function Douglas Anderson 2019-12-18 22:35 ` Douglas Anderson 2020-02-03 23:39 ` Bjorn Andersson 2020-02-03 23:39 ` Bjorn Andersson 2019-12-18 22:35 ` [PATCH v3 8/9] drm/bridge: ti-sn65dsi86: Train at faster rates if slower ones fail Douglas Anderson 2019-12-18 22:35 ` Douglas Anderson 2020-02-03 23:41 ` Bjorn Andersson 2020-02-03 23:41 ` Bjorn Andersson 2019-12-18 22:35 ` [PATCH v3 9/9] drm/bridge: ti-sn65dsi86: Avoid invalid rates Douglas Anderson 2019-12-18 22:35 ` Douglas Anderson 2020-02-03 23:43 ` Bjorn Andersson 2020-02-03 23:43 ` Bjorn Andersson 2020-01-06 22:47 ` [PATCH v3 0/9] drm/bridge: ti-sn65dsi86: Improve support for AUO B116XAK01 + other DP Doug Anderson 2020-01-06 22:47 ` Doug Anderson 2020-02-03 23:45 ` Bjorn Andersson 2020-02-03 23:45 ` Bjorn Andersson 2020-02-13 9:51 ` Neil Armstrong 2020-02-13 9:51 ` Neil Armstrong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAD=FV=WB_4xLe9UZX3eVemybQ1neXJVZgzrDCW-xUxbAM6hCTA@mail.gmail.com' \ --to=dianders@chromium.org \ --cc=Laurent.pinchart@ideasonboard.com \ --cc=a.hajda@samsung.com \ --cc=airlied@linux.ie \ --cc=bjorn.andersson@linaro.org \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=jeffrey.l.hugo@gmail.com \ --cc=jernej.skrabec@siol.net \ --cc=jonas@kwiboo.se \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=narmstrong@baylibre.com \ --cc=robdclark@chromium.org \ --cc=robdclark@gmail.com \ --cc=seanpaul@chromium.org \ --cc=steev@gentoo.org \ --cc=steev@kali.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.