From: Archit Taneja <a0393947@ti.com> To: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, rob@ti.com, sumit.semwal@ti.com Subject: Re: [PATCH 02/23] OMAPDSS: outputs: Create and initialize output instances Date: Mon, 27 Aug 2012 06:31:08 +0000 [thread overview] Message-ID: <503B115C.7040904@ti.com> (raw) In-Reply-To: <1345814042.9287.72.camel@lappyti> On Friday 24 August 2012 06:44 PM, Tomi Valkeinen wrote: > On Tue, 2012-08-21 at 11:28 +0530, Archit Taneja wrote: >> Create output instances by having an init function in the probes of the platform >> device drivers for different interfaces. Create a small function for each >> interface to initialize the output entity's fields type and id. >> >> In the probe of each interface driver, the output entities are created before >> the *_probe_pdata() functions intentionally. This is done to ensure that the >> output entity is prepared before the panels connected to the output are >> registered. We need the output entities to be ready because OMAPDSS will try >> to make connections between overlays, managers, outputs and devices during the >> panel's probe. > > You're referring to the recheck_connections stuff? I have a patch that > moves that to omapfb side. But of course it doesn't hurt to initialize > the output early. I've seen that patch. omapfb would need to take care of connecting outputs to displays, and managers to outputs. This is added in recheck_connections done in a patch #9 of the series. The question is whether we want some initial connections made between outputs and displays by DSS, or should that be left completely to omapfb/omapdrm? > > We should generally do the initialization in output driver's probe more > or less so that we first setup everything related to the output driver, > and after that we register the dssdevs. But I think that's what is > already done. > > So, no complaints =). Another thing that comes up with delaying the recheck_connections stuff is that we can't assume that at the point of panel driver's probe, there is an output connected to the display. That makes it a bit tricky to call an output function in the panel's probe, since it isn't connected to any output at all. An example is when we request for a VC in taal_probe. Since the panel isn't connected to any output yet, we can't really call a dsi function to request for the VC. This particular case can be solved by requesting VCs only when we enable the panel(probably makes more sense this way), but there might be other situations which could get tricky to tackle. > >> Signed-off-by: Archit Taneja <archit@ti.com> >> --- >> drivers/video/omap2/dss/dpi.c | 20 ++++++++++++++++++++ >> drivers/video/omap2/dss/dsi.c | 26 ++++++++++++++++++++++++-- >> drivers/video/omap2/dss/hdmi.c | 18 ++++++++++++++++++ >> drivers/video/omap2/dss/rfbi.c | 19 +++++++++++++++++++ >> drivers/video/omap2/dss/sdi.c | 20 ++++++++++++++++++++ >> drivers/video/omap2/dss/venc.c | 20 ++++++++++++++++++++ >> 6 files changed, 121 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c >> index f260343..4eca2e7 100644 >> --- a/drivers/video/omap2/dss/dpi.c >> +++ b/drivers/video/omap2/dss/dpi.c >> @@ -408,10 +408,30 @@ static void __init dpi_probe_pdata(struct platform_device *pdev) >> } >> } >> >> +static int __init dpi_init_output(struct platform_device *pdev) >> +{ >> + struct omap_dss_output *out; >> + >> + out = dss_create_output(pdev); >> + if (!out) >> + return -ENOMEM; >> + >> + out->id = OMAP_DSS_OUTPUT_DPI; >> + out->type = OMAP_DISPLAY_TYPE_DPI; >> + >> + return 0; >> +} >> + >> static int __init omap_dpi_probe(struct platform_device *pdev) >> { >> + int r; >> + >> mutex_init(&dpi.lock); >> >> + r = dpi_init_output(pdev); >> + if (r) >> + return r; >> + >> dpi_probe_pdata(pdev); >> >> return 0; >> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c >> index 659b6cd..22e0873 100644 >> --- a/drivers/video/omap2/dss/dsi.c >> +++ b/drivers/video/omap2/dss/dsi.c >> @@ -4903,6 +4903,23 @@ static void __init dsi_probe_pdata(struct platform_device *dsidev) >> } >> } >> >> +static int __init dsi_init_output(struct platform_device *dsidev, >> + struct dsi_data *dsi) >> +{ >> + struct omap_dss_output *out; >> + >> + out = dss_create_output(dsidev); >> + if (!out) >> + return -ENOMEM; >> + >> + out->id = dsi->module_id = 0 ? >> + OMAP_DSS_OUTPUT_DSI1 : OMAP_DSS_OUTPUT_DSI2; >> + >> + out->type = OMAP_DISPLAY_TYPE_DSI; >> + >> + return 0; > > As I mentioned in the last email, I think this could be something like: > > struct omap_dss_output *out = &dsi->output; > > out->pdev = dsidev; > out->id = xxx; > out->type = yyy; > dss_register_output(out); > Right, this is much better, will do it this way. > >> +} >> + >> /* DSI1 HW IP initialisation */ >> static int __init omap_dsihw_probe(struct platform_device *dsidev) >> { >> @@ -4997,10 +5014,14 @@ static int __init omap_dsihw_probe(struct platform_device *dsidev) >> else >> dsi->num_lanes_supported = 3; >> >> - dsi_probe_pdata(dsidev); >> - >> dsi_runtime_put(dsidev); >> >> + r = dsi_init_output(dsidev, dsi); >> + if (r) >> + goto err_init_output; >> + >> + dsi_probe_pdata(dsidev); >> + > > Why do you change the sequence here? Isn't it enough to just add the > init_output before probe_pdata? Yes, I think I didn't see the point in keeping the clocks on for dsi_init_output() and dsi_probe_pdata(), so tried to incorporate that in this patch too :), I'll change this back to the old way, it doesn't make sense in moving around pm runtime calls in this series. Archit
WARNING: multiple messages have this Message-ID (diff)
From: Archit Taneja <a0393947@ti.com> To: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org, rob@ti.com, sumit.semwal@ti.com Subject: Re: [PATCH 02/23] OMAPDSS: outputs: Create and initialize output instances Date: Mon, 27 Aug 2012 11:49:08 +0530 [thread overview] Message-ID: <503B115C.7040904@ti.com> (raw) In-Reply-To: <1345814042.9287.72.camel@lappyti> On Friday 24 August 2012 06:44 PM, Tomi Valkeinen wrote: > On Tue, 2012-08-21 at 11:28 +0530, Archit Taneja wrote: >> Create output instances by having an init function in the probes of the platform >> device drivers for different interfaces. Create a small function for each >> interface to initialize the output entity's fields type and id. >> >> In the probe of each interface driver, the output entities are created before >> the *_probe_pdata() functions intentionally. This is done to ensure that the >> output entity is prepared before the panels connected to the output are >> registered. We need the output entities to be ready because OMAPDSS will try >> to make connections between overlays, managers, outputs and devices during the >> panel's probe. > > You're referring to the recheck_connections stuff? I have a patch that > moves that to omapfb side. But of course it doesn't hurt to initialize > the output early. I've seen that patch. omapfb would need to take care of connecting outputs to displays, and managers to outputs. This is added in recheck_connections done in a patch #9 of the series. The question is whether we want some initial connections made between outputs and displays by DSS, or should that be left completely to omapfb/omapdrm? > > We should generally do the initialization in output driver's probe more > or less so that we first setup everything related to the output driver, > and after that we register the dssdevs. But I think that's what is > already done. > > So, no complaints =). Another thing that comes up with delaying the recheck_connections stuff is that we can't assume that at the point of panel driver's probe, there is an output connected to the display. That makes it a bit tricky to call an output function in the panel's probe, since it isn't connected to any output at all. An example is when we request for a VC in taal_probe. Since the panel isn't connected to any output yet, we can't really call a dsi function to request for the VC. This particular case can be solved by requesting VCs only when we enable the panel(probably makes more sense this way), but there might be other situations which could get tricky to tackle. > >> Signed-off-by: Archit Taneja <archit@ti.com> >> --- >> drivers/video/omap2/dss/dpi.c | 20 ++++++++++++++++++++ >> drivers/video/omap2/dss/dsi.c | 26 ++++++++++++++++++++++++-- >> drivers/video/omap2/dss/hdmi.c | 18 ++++++++++++++++++ >> drivers/video/omap2/dss/rfbi.c | 19 +++++++++++++++++++ >> drivers/video/omap2/dss/sdi.c | 20 ++++++++++++++++++++ >> drivers/video/omap2/dss/venc.c | 20 ++++++++++++++++++++ >> 6 files changed, 121 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c >> index f260343..4eca2e7 100644 >> --- a/drivers/video/omap2/dss/dpi.c >> +++ b/drivers/video/omap2/dss/dpi.c >> @@ -408,10 +408,30 @@ static void __init dpi_probe_pdata(struct platform_device *pdev) >> } >> } >> >> +static int __init dpi_init_output(struct platform_device *pdev) >> +{ >> + struct omap_dss_output *out; >> + >> + out = dss_create_output(pdev); >> + if (!out) >> + return -ENOMEM; >> + >> + out->id = OMAP_DSS_OUTPUT_DPI; >> + out->type = OMAP_DISPLAY_TYPE_DPI; >> + >> + return 0; >> +} >> + >> static int __init omap_dpi_probe(struct platform_device *pdev) >> { >> + int r; >> + >> mutex_init(&dpi.lock); >> >> + r = dpi_init_output(pdev); >> + if (r) >> + return r; >> + >> dpi_probe_pdata(pdev); >> >> return 0; >> diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c >> index 659b6cd..22e0873 100644 >> --- a/drivers/video/omap2/dss/dsi.c >> +++ b/drivers/video/omap2/dss/dsi.c >> @@ -4903,6 +4903,23 @@ static void __init dsi_probe_pdata(struct platform_device *dsidev) >> } >> } >> >> +static int __init dsi_init_output(struct platform_device *dsidev, >> + struct dsi_data *dsi) >> +{ >> + struct omap_dss_output *out; >> + >> + out = dss_create_output(dsidev); >> + if (!out) >> + return -ENOMEM; >> + >> + out->id = dsi->module_id == 0 ? >> + OMAP_DSS_OUTPUT_DSI1 : OMAP_DSS_OUTPUT_DSI2; >> + >> + out->type = OMAP_DISPLAY_TYPE_DSI; >> + >> + return 0; > > As I mentioned in the last email, I think this could be something like: > > struct omap_dss_output *out = &dsi->output; > > out->pdev = dsidev; > out->id = xxx; > out->type = yyy; > dss_register_output(out); > Right, this is much better, will do it this way. > >> +} >> + >> /* DSI1 HW IP initialisation */ >> static int __init omap_dsihw_probe(struct platform_device *dsidev) >> { >> @@ -4997,10 +5014,14 @@ static int __init omap_dsihw_probe(struct platform_device *dsidev) >> else >> dsi->num_lanes_supported = 3; >> >> - dsi_probe_pdata(dsidev); >> - >> dsi_runtime_put(dsidev); >> >> + r = dsi_init_output(dsidev, dsi); >> + if (r) >> + goto err_init_output; >> + >> + dsi_probe_pdata(dsidev); >> + > > Why do you change the sequence here? Isn't it enough to just add the > init_output before probe_pdata? Yes, I think I didn't see the point in keeping the clocks on for dsi_init_output() and dsi_probe_pdata(), so tried to incorporate that in this patch too :), I'll change this back to the old way, it doesn't make sense in moving around pm runtime calls in this series. Archit
next prev parent reply other threads:[~2012-08-27 6:31 UTC|newest] Thread overview: 148+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-08-21 5:58 [PATCH 00/23] OMAPDSS: Create output entities Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 01/23] OMAPDSS: outputs: Create a new entity called outputs Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-24 12:41 ` Tomi Valkeinen 2012-08-24 12:41 ` Tomi Valkeinen 2012-08-24 12:51 ` Archit Taneja 2012-08-24 12:53 ` Archit Taneja 2012-08-29 10:32 ` Tomi Valkeinen 2012-08-29 10:32 ` Tomi Valkeinen 2012-08-29 10:57 ` Archit Taneja 2012-08-29 10:58 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 02/23] OMAPDSS: outputs: Create and initialize output instances Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-24 13:14 ` Tomi Valkeinen 2012-08-24 13:14 ` Tomi Valkeinen 2012-08-27 6:19 ` Archit Taneja [this message] 2012-08-27 6:31 ` Archit Taneja 2012-08-27 6:44 ` Tomi Valkeinen 2012-08-27 6:44 ` Tomi Valkeinen 2012-08-21 5:58 ` [PATCH 03/23] OMAPDSS: output: Add set/unset device ops for omap_dss_output Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 04/23] OMAPDSS: APPLY: Add manager set/unset output ops for omap_overlay_manager Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 05/23] OMAPDSS: Remove manager->device references Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 06/23] OMAP_VOUT: " Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 07/23] OMAPFB: remove " Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 08/23] OMAPDRM: Remove " Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 09/23] OMAPDSS: Create links between managers, outputs and devices Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 10/23] OMAPDSS: DPI: Pass outputs from panel driver to DPI interface driver Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 11/23] OMAPDSS: DSI: Remove dsi_pdev_map global struct Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 12/23] OMAPDSS: DSI: Pass outputs from panel driver to DSI interface driver Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 13/23] OMAPDSS: SDI: Pass outputs from panel driver to SDI " Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 14/23] OMAPDSS: RFBI: Pass outputs from panel driver to RFBI " Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 15/23] OMAPDSS: RFBI: Add output pointers as arguments to all exported functions Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 16/23] OMAPDSS: VENC: Pass outputs from panel driver to VENC interface driver Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 17/23] OMAPDSS: HDMI: Pass outputs from panel driver to HDMI " Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 18/23] OMAPDSS: HDMI: Add output pointers as arguments to all functions used by hdmi panel driver Archit Taneja 2012-08-21 6:10 ` [PATCH 18/23] OMAPDSS: HDMI: Add output pointers as arguments to all functions used by hdmi panel dr Archit Taneja 2012-08-21 5:58 ` [PATCH 19/23] OMAPDSS/OMAPFB: Change dssdev->manager references Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 20/23] OMAPDSS: MANAGER: Update display sysfs store Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 21/23] OMAPDSS: MANAGER: Get device via output Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 22/23] OMAPDSS: APPLY: Remove omap_dss_device references from dss_ovl_enable/disable Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-21 5:58 ` [PATCH 23/23] OMAPDSS: Remove old way of setting manager and device links Archit Taneja 2012-08-21 6:10 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 00/23] OMAPDSS: Create output entities Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 01/23] OMAPDSS: outputs: Create a new entity called outputs Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 02/23] OMAPDSS: outputs: Create and register output instances Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-31 11:57 ` Tomi Valkeinen 2012-08-31 11:57 ` Tomi Valkeinen 2012-08-31 12:03 ` Archit Taneja 2012-08-31 12:15 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 03/23] OMAPDSS: output: Add set/unset device ops for omap_dss_output Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-31 12:03 ` Tomi Valkeinen 2012-08-31 12:03 ` Tomi Valkeinen 2012-08-31 12:24 ` Archit Taneja 2012-08-31 12:36 ` Archit Taneja 2012-08-31 12:28 ` Tomi Valkeinen 2012-08-31 12:28 ` Tomi Valkeinen 2012-08-30 11:40 ` [PATCH v2 04/23] OMAPDSS: APPLY: Add manager set/unset output ops for omap_overlay_manager Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 05/23] OMAPDSS: Remove manager->device references Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 06/23] OMAP_VOUT: " Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-31 12:11 ` Tomi Valkeinen 2012-08-31 12:11 ` Tomi Valkeinen 2012-08-31 12:34 ` Archit Taneja 2012-08-31 12:46 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 07/23] OMAPFB: remove " Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 08/23] OMAPDRM: Remove " Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 09/23] OMAPDSS: Create links between managers, outputs and devices Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-31 14:10 ` Tomi Valkeinen 2012-08-31 14:10 ` Tomi Valkeinen 2012-08-31 14:24 ` Archit Taneja 2012-08-31 14:36 ` Archit Taneja 2012-08-31 14:45 ` Tomi Valkeinen 2012-08-31 14:45 ` Tomi Valkeinen 2012-08-31 15:08 ` Tomi Valkeinen 2012-08-31 15:08 ` Tomi Valkeinen 2012-09-03 9:26 ` Archit Taneja 2012-09-03 9:38 ` Archit Taneja 2012-09-03 9:35 ` Tomi Valkeinen 2012-09-03 9:35 ` Tomi Valkeinen 2012-08-30 11:40 ` [PATCH v2 10/23] OMAPDSS: DPI: Pass omap_dss_output within the driver Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-31 13:48 ` Tomi Valkeinen 2012-08-31 13:48 ` Tomi Valkeinen 2012-08-31 13:59 ` Archit Taneja 2012-08-31 14:00 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 11/23] OMAPDSS: DSI: Remove dsi_pdev_map global struct Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 12/23] OMAPDSS: DSI: Pass omap_dss_output within the driver Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 13/23] OMAPDSS: SDI: " Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 14/23] OMAPDSS: RFBI: " Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 15/23] OMAPDSS: RFBI: Add dssdev pointers as arguments to all exported functions Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-31 14:20 ` Tomi Valkeinen 2012-08-31 14:20 ` Tomi Valkeinen 2012-08-31 14:30 ` Archit Taneja 2012-08-31 14:42 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 16/23] OMAPDSS: VENC: Pass omap_dss_output within the driver Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 17/23] OMAPDSS: HDMI: " Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 18/23] OMAPDSS: HDMI: Add dssdev pointer as an argument to all functions used by hdmi panel driver Archit Taneja 2012-08-30 11:52 ` [PATCH v2 18/23] OMAPDSS: HDMI: Add dssdev pointer as an argument to all functions used by hdmi pane Archit Taneja 2012-08-30 11:40 ` [PATCH v2 19/23] OMAPDSS/OMAPFB: Change dssdev->manager references Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 20/23] OMAPDSS: MANAGER: Update display sysfs store Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-31 14:30 ` Tomi Valkeinen 2012-08-31 14:30 ` Tomi Valkeinen 2012-08-31 14:41 ` Archit Taneja 2012-08-31 14:53 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 21/23] OMAPDSS: MANAGER: Get device via output Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 22/23] OMAPDSS: APPLY: Remove omap_dss_device references from dss_ovl_enable/disable Archit Taneja 2012-08-30 11:52 ` Archit Taneja 2012-08-30 11:40 ` [PATCH v2 23/23] OMAPDSS: Remove old way of setting manager and device links Archit Taneja 2012-08-30 11:52 ` Archit Taneja
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=503B115C.7040904@ti.com \ --to=a0393947@ti.com \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=rob@ti.com \ --cc=sumit.semwal@ti.com \ --cc=tomi.valkeinen@ti.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: 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.