All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Schwalm <maxim.schwalm@gmail.com>
To: "Tomi Valkeinen" <tomi.valkeinen@ideasonboard.com>,
	"Péter Ujfalusi" <peter.ujfalusi@gmail.com>,
	"Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Robert Foss" <rfoss@kernel.org>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"David Airlie" <airlied@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Francesco Dolcini" <francesco@dolcini.it>
Cc: Aradhya Bhatia <a-bhatia1@ti.com>,
	Svyatoslav Ryhel <clamor95@gmail.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Thierry Reding <thierry.reding@gmail.com>,
	Dmitry Osipenko <digetx@gmail.com>
Subject: Re: [PATCH 02/11] drm/bridge: tc358768: Fix bit updates
Date: Tue, 15 Aug 2023 19:21:37 +0200	[thread overview]
Message-ID: <d55fc4d3-015d-8cc2-417e-e92aa4687ca2@gmail.com> (raw)
In-Reply-To: <52151daa-90af-a6c0-9b03-f69081321253@ideasonboard.com>

[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]

On 14.08.23 08:34, Tomi Valkeinen wrote:
> On 13/08/2023 03:23, Maxim Schwalm wrote:
>> Hi,
>>
>> On 11.08.23 19:02, Tomi Valkeinen wrote:
>>> On 11/08/2023 19:23, Péter Ujfalusi wrote:
>>>>
>>>>
>>>> On 04/08/2023 13:44, Tomi Valkeinen wrote:
>>>>> The driver has a few places where it does:
>>>>>
>>>>> if (thing_is_enabled_in_config)
>>>>> 	update_thing_bit_in_hw()
>>>>>
>>>>> This means that if the thing is _not_ enabled, the bit never gets
>>>>> cleared. This affects the h/vsyncs and continuous DSI clock bits.
>>>>
>>>> I guess the idea was to keep the reset value unless it needs to be flipped.
>>>>
>>>>>
>>>>> Fix the driver to always update the bit.
>>>>>
>>>>> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
>>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
>>>>> ---
>>>>>    drivers/gpu/drm/bridge/tc358768.c | 13 +++++++------
>>>>>    1 file changed, 7 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/tc358768.c b/drivers/gpu/drm/bridge/tc358768.c
>>>>> index bc97a837955b..b668f77673c3 100644
>>>>> --- a/drivers/gpu/drm/bridge/tc358768.c
>>>>> +++ b/drivers/gpu/drm/bridge/tc358768.c
>>>>> @@ -794,8 +794,8 @@ static void tc358768_bridge_pre_enable(struct drm_bridge *bridge)
>>>>>    		val |= BIT(i + 1);
>>>>>    	tc358768_write(priv, TC358768_HSTXVREGEN, val);
>>>>>    
>>>>> -	if (!(mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS))
>>>>> -		tc358768_write(priv, TC358768_TXOPTIONCNTRL, 0x1);
>>>>> +	tc358768_write(priv, TC358768_TXOPTIONCNTRL,
>>>>> +		       (mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) ? 0 : BIT(0));
>>>>>    
>>>>>    	/* TXTAGOCNT[26:16] RXTASURECNT[10:0] */
>>>>>    	val = tc358768_to_ns((lptxcnt + 1) * dsibclk_nsk * 4);
>>>>> @@ -861,11 +861,12 @@ static void tc358768_bridge_pre_enable(struct drm_bridge *bridge)
>>>>>    	tc358768_write(priv, TC358768_DSI_HACT, hact);
>>>>>    
>>>>>    	/* VSYNC polarity */
>>>>> -	if (!(mode->flags & DRM_MODE_FLAG_NVSYNC))
>>>>> -		tc358768_update_bits(priv, TC358768_CONFCTL, BIT(5), BIT(5));
>>>>> +	tc358768_update_bits(priv, TC358768_CONFCTL, BIT(5),
>>>>> +			     (mode->flags & DRM_MODE_FLAG_PVSYNC) ? BIT(5) : 0);
>>>>
>>>> Was this the reverse before and should be:
>>>> (mode->flags & DRM_MODE_FLAG_PVSYNC) ? 0 : BIT(5)
>>>
>>> Bit 5 is 1 for active high vsync polarity. The test was previously
>>> !nvsync, i.e. the same as pvsync.
>>
>> this statement doesn't seem to be true, since this change causes a
>> regression on the Asus TF700T. Apparently, !nvsync is true and pvsync is
>> false in the present case.
> 
> panasonic_vvx10f004b00_mode in panel_simple.c doesn't seem to have mode 
> flags set. I would say that means the panel doesn't care about the sync 
> polarities (which obviously is not the case), but maybe there's an 
> assumption that if sync polarities are not set, the default is... 
> positive? But I can't find any mention about this.
> 
> Does it work for you if you set the polarities in 
> panasonic_vvx10f004b00_mode?

The panel seems to work with either negative or positive H-/Vsync in
conjunction with the attached patch from Thierry. Currently, the display
controller is unconditionally programmed for positive H-/Vsync though.
What should be done in this case?

BTW, the vendor kernel configures the display controller as well as the
bridge for negative H-/Vsync.

Best regards,
Maxim

[-- Attachment #2: 0001-drm-tegra-rgb-Parameterize-V-and-H-sync-polarities.patch --]
[-- Type: text/x-patch, Size: 1921 bytes --]

From efc4f9108b3f44d3e00146bdb97c906f15e2a068 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Mon, 3 Aug 2015 13:34:36 +0200
Subject: [PATCH] drm/tegra: rgb: Parameterize V- and H-sync polarities

The polarities of the V- and H-sync signals are encoded as flags in the
display mode, so use the existing information to setup the signals for
the RGB interface.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/gpu/drm/tegra/rgb.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index 79566c9ea8ff..cce422c2d6a6 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -99,6 +99,7 @@ static void tegra_rgb_encoder_disable(struct drm_encoder *encoder)
 
 static void tegra_rgb_encoder_enable(struct drm_encoder *encoder)
 {
+	struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
 	struct tegra_output *output = encoder_to_output(encoder);
 	struct tegra_rgb *rgb = to_rgb(output);
 	u32 value;
@@ -108,10 +109,21 @@ static void tegra_rgb_encoder_enable(struct drm_encoder *encoder)
 	value = DE_SELECT_ACTIVE | DE_CONTROL_NORMAL;
 	tegra_dc_writel(rgb->dc, value, DC_DISP_DATA_ENABLE_OPTIONS);
 
-	/* XXX: parameterize? */
+	/* configure H- and V-sync signal polarities */
 	value = tegra_dc_readl(rgb->dc, DC_COM_PIN_OUTPUT_POLARITY(1));
-	value &= ~LVS_OUTPUT_POLARITY_LOW;
-	value &= ~LHS_OUTPUT_POLARITY_LOW;
+
+	if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+		value &= ~LHS_OUTPUT_POLARITY_LOW;
+
+	if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+		value |= LHS_OUTPUT_POLARITY_LOW;
+
+	if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+		value &= ~LVS_OUTPUT_POLARITY_LOW;
+
+	if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+		value |= LVS_OUTPUT_POLARITY_LOW;
+
 	tegra_dc_writel(rgb->dc, value, DC_COM_PIN_OUTPUT_POLARITY(1));
 
 	/* XXX: parameterize? */
-- 
2.39.2


WARNING: multiple messages have this Message-ID (diff)
From: Maxim Schwalm <maxim.schwalm@gmail.com>
To: "Tomi Valkeinen" <tomi.valkeinen@ideasonboard.com>,
	"Péter Ujfalusi" <peter.ujfalusi@gmail.com>,
	"Andrzej Hajda" <andrzej.hajda@intel.com>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Robert Foss" <rfoss@kernel.org>,
	"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
	"Jonas Karlman" <jonas@kwiboo.se>,
	"Jernej Skrabec" <jernej.skrabec@gmail.com>,
	"David Airlie" <airlied@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Francesco Dolcini" <francesco@dolcini.it>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Aradhya Bhatia <a-bhatia1@ti.com>,
	Dmitry Osipenko <digetx@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Svyatoslav Ryhel <clamor95@gmail.com>
Subject: Re: [PATCH 02/11] drm/bridge: tc358768: Fix bit updates
Date: Tue, 15 Aug 2023 19:21:37 +0200	[thread overview]
Message-ID: <d55fc4d3-015d-8cc2-417e-e92aa4687ca2@gmail.com> (raw)
In-Reply-To: <52151daa-90af-a6c0-9b03-f69081321253@ideasonboard.com>

[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]

On 14.08.23 08:34, Tomi Valkeinen wrote:
> On 13/08/2023 03:23, Maxim Schwalm wrote:
>> Hi,
>>
>> On 11.08.23 19:02, Tomi Valkeinen wrote:
>>> On 11/08/2023 19:23, Péter Ujfalusi wrote:
>>>>
>>>>
>>>> On 04/08/2023 13:44, Tomi Valkeinen wrote:
>>>>> The driver has a few places where it does:
>>>>>
>>>>> if (thing_is_enabled_in_config)
>>>>> 	update_thing_bit_in_hw()
>>>>>
>>>>> This means that if the thing is _not_ enabled, the bit never gets
>>>>> cleared. This affects the h/vsyncs and continuous DSI clock bits.
>>>>
>>>> I guess the idea was to keep the reset value unless it needs to be flipped.
>>>>
>>>>>
>>>>> Fix the driver to always update the bit.
>>>>>
>>>>> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
>>>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
>>>>> ---
>>>>>    drivers/gpu/drm/bridge/tc358768.c | 13 +++++++------
>>>>>    1 file changed, 7 insertions(+), 6 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/bridge/tc358768.c b/drivers/gpu/drm/bridge/tc358768.c
>>>>> index bc97a837955b..b668f77673c3 100644
>>>>> --- a/drivers/gpu/drm/bridge/tc358768.c
>>>>> +++ b/drivers/gpu/drm/bridge/tc358768.c
>>>>> @@ -794,8 +794,8 @@ static void tc358768_bridge_pre_enable(struct drm_bridge *bridge)
>>>>>    		val |= BIT(i + 1);
>>>>>    	tc358768_write(priv, TC358768_HSTXVREGEN, val);
>>>>>    
>>>>> -	if (!(mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS))
>>>>> -		tc358768_write(priv, TC358768_TXOPTIONCNTRL, 0x1);
>>>>> +	tc358768_write(priv, TC358768_TXOPTIONCNTRL,
>>>>> +		       (mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) ? 0 : BIT(0));
>>>>>    
>>>>>    	/* TXTAGOCNT[26:16] RXTASURECNT[10:0] */
>>>>>    	val = tc358768_to_ns((lptxcnt + 1) * dsibclk_nsk * 4);
>>>>> @@ -861,11 +861,12 @@ static void tc358768_bridge_pre_enable(struct drm_bridge *bridge)
>>>>>    	tc358768_write(priv, TC358768_DSI_HACT, hact);
>>>>>    
>>>>>    	/* VSYNC polarity */
>>>>> -	if (!(mode->flags & DRM_MODE_FLAG_NVSYNC))
>>>>> -		tc358768_update_bits(priv, TC358768_CONFCTL, BIT(5), BIT(5));
>>>>> +	tc358768_update_bits(priv, TC358768_CONFCTL, BIT(5),
>>>>> +			     (mode->flags & DRM_MODE_FLAG_PVSYNC) ? BIT(5) : 0);
>>>>
>>>> Was this the reverse before and should be:
>>>> (mode->flags & DRM_MODE_FLAG_PVSYNC) ? 0 : BIT(5)
>>>
>>> Bit 5 is 1 for active high vsync polarity. The test was previously
>>> !nvsync, i.e. the same as pvsync.
>>
>> this statement doesn't seem to be true, since this change causes a
>> regression on the Asus TF700T. Apparently, !nvsync is true and pvsync is
>> false in the present case.
> 
> panasonic_vvx10f004b00_mode in panel_simple.c doesn't seem to have mode 
> flags set. I would say that means the panel doesn't care about the sync 
> polarities (which obviously is not the case), but maybe there's an 
> assumption that if sync polarities are not set, the default is... 
> positive? But I can't find any mention about this.
> 
> Does it work for you if you set the polarities in 
> panasonic_vvx10f004b00_mode?

The panel seems to work with either negative or positive H-/Vsync in
conjunction with the attached patch from Thierry. Currently, the display
controller is unconditionally programmed for positive H-/Vsync though.
What should be done in this case?

BTW, the vendor kernel configures the display controller as well as the
bridge for negative H-/Vsync.

Best regards,
Maxim

[-- Attachment #2: 0001-drm-tegra-rgb-Parameterize-V-and-H-sync-polarities.patch --]
[-- Type: text/x-patch, Size: 1921 bytes --]

From efc4f9108b3f44d3e00146bdb97c906f15e2a068 Mon Sep 17 00:00:00 2001
From: Thierry Reding <treding@nvidia.com>
Date: Mon, 3 Aug 2015 13:34:36 +0200
Subject: [PATCH] drm/tegra: rgb: Parameterize V- and H-sync polarities

The polarities of the V- and H-sync signals are encoded as flags in the
display mode, so use the existing information to setup the signals for
the RGB interface.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 drivers/gpu/drm/tegra/rgb.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c
index 79566c9ea8ff..cce422c2d6a6 100644
--- a/drivers/gpu/drm/tegra/rgb.c
+++ b/drivers/gpu/drm/tegra/rgb.c
@@ -99,6 +99,7 @@ static void tegra_rgb_encoder_disable(struct drm_encoder *encoder)
 
 static void tegra_rgb_encoder_enable(struct drm_encoder *encoder)
 {
+	struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
 	struct tegra_output *output = encoder_to_output(encoder);
 	struct tegra_rgb *rgb = to_rgb(output);
 	u32 value;
@@ -108,10 +109,21 @@ static void tegra_rgb_encoder_enable(struct drm_encoder *encoder)
 	value = DE_SELECT_ACTIVE | DE_CONTROL_NORMAL;
 	tegra_dc_writel(rgb->dc, value, DC_DISP_DATA_ENABLE_OPTIONS);
 
-	/* XXX: parameterize? */
+	/* configure H- and V-sync signal polarities */
 	value = tegra_dc_readl(rgb->dc, DC_COM_PIN_OUTPUT_POLARITY(1));
-	value &= ~LVS_OUTPUT_POLARITY_LOW;
-	value &= ~LHS_OUTPUT_POLARITY_LOW;
+
+	if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+		value &= ~LHS_OUTPUT_POLARITY_LOW;
+
+	if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+		value |= LHS_OUTPUT_POLARITY_LOW;
+
+	if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+		value &= ~LVS_OUTPUT_POLARITY_LOW;
+
+	if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+		value |= LVS_OUTPUT_POLARITY_LOW;
+
 	tegra_dc_writel(rgb->dc, value, DC_COM_PIN_OUTPUT_POLARITY(1));
 
 	/* XXX: parameterize? */
-- 
2.39.2


  reply	other threads:[~2023-08-16  7:39 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-04 10:44 [PATCH 00/11] drm/bridge: tc358768: Fixes and timings improvements Tomi Valkeinen
2023-08-04 10:44 ` Tomi Valkeinen
2023-08-04 10:44 ` [PATCH 01/11] drm/bridge: tc358768: Fix use of uninitialized variable Tomi Valkeinen
2023-08-04 10:44   ` Tomi Valkeinen
2023-08-11 16:19   ` Péter Ujfalusi
2023-08-11 16:19     ` Péter Ujfalusi
2023-08-04 10:44 ` [PATCH 02/11] drm/bridge: tc358768: Fix bit updates Tomi Valkeinen
2023-08-04 10:44   ` Tomi Valkeinen
2023-08-11 16:23   ` Péter Ujfalusi
2023-08-11 16:23     ` Péter Ujfalusi
2023-08-11 17:02     ` Tomi Valkeinen
2023-08-11 17:02       ` Tomi Valkeinen
2023-08-13  0:23       ` Maxim Schwalm
2023-08-14  6:34         ` Tomi Valkeinen
2023-08-15 17:21           ` Maxim Schwalm [this message]
2023-08-15 17:21             ` Maxim Schwalm
2023-08-16  8:14             ` Tomi Valkeinen
2023-08-16  8:14               ` Tomi Valkeinen
2023-08-16  8:21             ` Tomi Valkeinen
2023-08-16  8:21               ` Tomi Valkeinen
2023-08-04 10:44 ` [PATCH 03/11] drm/bridge: tc358768: Cleanup PLL calculations Tomi Valkeinen
2023-08-04 10:44   ` Tomi Valkeinen
2023-08-11 16:25   ` Péter Ujfalusi
2023-08-11 16:25     ` Péter Ujfalusi
2023-08-04 10:44 ` [PATCH 04/11] drm/bridge: tc358768: Use struct videomode Tomi Valkeinen
2023-08-04 10:44   ` Tomi Valkeinen
2023-08-11 16:26   ` Péter Ujfalusi
2023-08-11 16:26     ` Péter Ujfalusi
2023-08-04 10:44 ` [PATCH 05/11] drm/bridge: tc358768: Print logical values, not raw register values Tomi Valkeinen
2023-08-04 10:44   ` Tomi Valkeinen
2023-08-11 16:31   ` Péter Ujfalusi
2023-08-11 16:31     ` Péter Ujfalusi
2023-08-11 17:05     ` Tomi Valkeinen
2023-08-11 17:05       ` Tomi Valkeinen
2023-08-04 10:44 ` [PATCH 06/11] drm/bridge: tc358768: Use dev for dbg prints, not priv->dev Tomi Valkeinen
2023-08-04 10:44   ` Tomi Valkeinen
2023-08-11 16:32   ` Péter Ujfalusi
2023-08-11 16:32     ` Péter Ujfalusi
2023-08-04 10:44 ` [PATCH 07/11] drm/bridge: tc358768: Rename dsibclk to hsbyteclk Tomi Valkeinen
2023-08-04 10:44   ` Tomi Valkeinen
2023-08-11 16:33   ` Péter Ujfalusi
2023-08-11 16:33     ` Péter Ujfalusi
2023-08-04 10:44 ` [PATCH 08/11] drm/bridge: tc358768: Clean up clock period code Tomi Valkeinen
2023-08-04 10:44   ` Tomi Valkeinen
2023-08-11 16:34   ` Péter Ujfalusi
2023-08-11 16:34     ` Péter Ujfalusi
2023-08-04 10:44 ` [PATCH 09/11] drm/bridge: tc358768: Fix tc358768_ns_to_cnt() Tomi Valkeinen
2023-08-04 10:44   ` Tomi Valkeinen
2023-08-11 16:35   ` Péter Ujfalusi
2023-08-11 16:35     ` Péter Ujfalusi
2023-08-04 10:44 ` [PATCH 10/11] drm/bridge: tc358768: Attempt to fix DSI horizontal timings Tomi Valkeinen
2023-08-04 10:44   ` Tomi Valkeinen
2023-08-11 16:39   ` Péter Ujfalusi
2023-08-11 16:39     ` Péter Ujfalusi
2023-08-04 10:44 ` [PATCH 11/11] drm/bridge: tc358768: Add DRM_BRIDGE_ATTACH_NO_CONNECTOR support Tomi Valkeinen
2023-08-04 10:44   ` Tomi Valkeinen
2023-08-11 16:44   ` Péter Ujfalusi
2023-08-11 16:44     ` Péter Ujfalusi
2023-08-11 16:58     ` Tomi Valkeinen
2023-08-11 16:58       ` Tomi Valkeinen
2023-08-13 17:11   ` Maxim Schwalm
2023-08-13 17:11     ` Maxim Schwalm
2023-08-14  7:31     ` Tomi Valkeinen
2023-08-14  7:31       ` Tomi Valkeinen
2023-08-14 10:04     ` Tomi Valkeinen
2023-08-14 10:04       ` Tomi Valkeinen
2023-08-14 10:10       ` Sam Ravnborg
2023-08-14 10:10         ` Sam Ravnborg
2023-08-14 10:17         ` Laurent Pinchart
2023-08-14 10:17           ` Laurent Pinchart
2023-08-14 13:29         ` Tomi Valkeinen
2023-08-14 13:29           ` Tomi Valkeinen
2023-08-15 17:44       ` Maxim Schwalm
2023-08-15 17:44         ` Maxim Schwalm

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=d55fc4d3-015d-8cc2-417e-e92aa4687ca2@gmail.com \
    --to=maxim.schwalm@gmail.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a-bhatia1@ti.com \
    --cc=airlied@gmail.com \
    --cc=andrzej.hajda@intel.com \
    --cc=clamor95@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=digetx@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=francesco@dolcini.it \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=peter.ujfalusi@gmail.com \
    --cc=rfoss@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=tomi.valkeinen@ideasonboard.com \
    /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: link
Be 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.