[{"id":34939,"web_url":"https://patchwork.libcamera.org/comment/34939/","msgid":"<175284751659.560048.8615485951279837055@ping.linuxembedded.co.uk>","date":"2025-07-18T14:05:16","subject":"Re: [PATCH] ipa: rpi: Fix static initialisation order bug in the\n\tController","submitter":{"id":4,"url":"https://patchwork.libcamera.org/api/people/4/","name":"Kieran Bingham","email":"kieran.bingham@ideasonboard.com"},"content":"Quoting Naushir Patuck (2025-07-18 11:43:46)\n> There is a possible static initialisation issue with accessing the\n> HardwareConfigMap static object through Controller::getHardwareConfig().\n> Fix this by providing a static function hardwareConfigMap() to access\n> the object.\n> \n> Though not proven, this is possibly the cause of a very infrequent\n> lockup in https://github.com/raspberrypi/rpicam-apps/issues/799.\n> \n> Signed-off-by: Naushir Patuck \n\n\nReviewed-by: Kieran Bingham \n\nIt seems like this is a helpful thing to do no matter what with our\ndistrust of global initialisations.\n\nLets wait until next week for the test results and we can merge if\nyou're happy.\n\n--\nKieran\n\n\n> ---\n> src/ipa/rpi/controller/controller.cpp | 119 ++++++++++++++------------\n> 1 file changed, 64 insertions(+), 55 deletions(-)\n> \n> diff --git a/src/ipa/rpi/controller/controller.cpp b/src/ipa/rpi/controller/controller.cpp\n> index 651fff632400..df45dcd345b7 100644\n> --- a/src/ipa/rpi/controller/controller.cpp\n> +++ b/src/ipa/rpi/controller/controller.cpp\n> @@ -21,61 +21,70 @@ using namespace std::literals::chrono_literals;\n> \n> LOG_DEFINE_CATEGORY(RPiController)\n> \n> -static const std::map HardwareConfigMap = {\n> - {\n> - \"bcm2835\",\n> +namespace {\n> +\n> +const std::map &hardwareConfigMap()\n> +{\n> + static const std::map map = {\n> {\n> - /*\n> - * There are only ever 15 AGC regions computed by the firmware\n> - * due to zoning, but the HW defines AGC_REGIONS == 16!\n> - */\n> - .agcRegions = { 15 , 1 },\n> - .agcZoneWeights = { 15 , 1 },\n> - .awbRegions = { 16, 12 },\n> - .cacRegions = { 0, 0 },\n> - .focusRegions = { 4, 3 },\n> - .numHistogramBins = 128,\n> - .numGammaPoints = 33,\n> - .pipelineWidth = 13,\n> - .statsInline = false,\n> - .minPixelProcessingTime = 0s,\n> - .dataBufferStrided = true,\n> - }\n> - },\n> - {\n> - \"pisp\",\n> + \"bcm2835\",\n> + {\n> + /*\n> + * There are only ever 15 AGC regions computed by the firmware\n> + * due to zoning, but the HW defines AGC_REGIONS == 16!\n> + */\n> + .agcRegions = { 15 , 1 },\n> + .agcZoneWeights = { 15 , 1 },\n> + .awbRegions = { 16, 12 },\n> + .cacRegions = { 0, 0 },\n> + .focusRegions = { 4, 3 },\n> + .numHistogramBins = 128,\n> + .numGammaPoints = 33,\n> + .pipelineWidth = 13,\n> + .statsInline = false,\n> + .minPixelProcessingTime = 0s,\n> + .dataBufferStrided = true,\n> + }\n> + },\n> {\n> - .agcRegions = { 0, 0 },\n> - .agcZoneWeights = { 15, 15 },\n> - .awbRegions = { 32, 32 },\n> - .cacRegions = { 8, 8 },\n> - .focusRegions = { 8, 8 },\n> - .numHistogramBins = 1024,\n> - .numGammaPoints = 64,\n> - .pipelineWidth = 16,\n> - .statsInline = true,\n> -\n> - /*\n> - * The constraint below is on the rate of pixels going\n> - * from CSI2 peripheral to ISP-FE (400Mpix/s, plus tiny\n> - * overheads per scanline, for which 380Mpix/s is a\n> - * conservative bound).\n> - *\n> - * There is a 64kbit data FIFO before the bottleneck,\n> - * which means that in all reasonable cases the\n> - * constraint applies at a timescale >= 1 scanline, so\n> - * adding horizontal blanking can prevent loss.\n> - *\n> - * If the backlog were to grow beyond 64kbit during a\n> - * single scanline, there could still be loss. This\n> - * could happen using 4 lanes at 1.5Gbps at 10bpp with\n> - * frames wider than ~16,000 pixels.\n> - */\n> - .minPixelProcessingTime = 1.0us / 380,\n> - .dataBufferStrided = false,\n> - }\n> - },\n> -};\n> + \"pisp\",\n> + {\n> + .agcRegions = { 0, 0 },\n> + .agcZoneWeights = { 15, 15 },\n> + .awbRegions = { 32, 32 },\n> + .cacRegions = { 8, 8 },\n> + .focusRegions = { 8, 8 },\n> + .numHistogramBins = 1024,\n> + .numGammaPoints = 64,\n> + .pipelineWidth = 16,\n> + .statsInline = true,\n> +\n> + /*\n> + * The constraint below is on the rate of pixels going\n> + * from CSI2 peripheral to ISP-FE (400Mpix/s, plus tiny\n> + * overheads per scanline, for which 380Mpix/s is a\n> + * conservative bound).\n> + *\n> + * There is a 64kbit data FIFO before the bottleneck,\n> + * which means that in all reasonable cases the\n> + * constraint applies at a timescale >= 1 scanline, so\n> + * adding horizontal blanking can prevent loss.\n> + *\n> + * If the backlog were to grow beyond 64kbit during a\n> + * single scanline, there could still be loss. This\n> + * could happen using 4 lanes at 1.5Gbps at 10bpp with\n> + * frames wider than ~16,000 pixels.\n> + */\n> + .minPixelProcessingTime = 1.0us / 380,\n> + .dataBufferStrided = false,\n> + }\n> + },\n> + };\n> +\n> + return map;\n> +}\n> +\n> +} /* namespace */\n> \n> Controller::Controller()\n> : switchModeCalled_(false)\n> @@ -211,12 +220,12 @@ const std::string &Controller::getTarget() const\n> \n> const Controller::HardwareConfig &Controller::getHardwareConfig() const\n> {\n> - auto cfg = HardwareConfigMap.find(getTarget());\n> + auto cfg = hardwareConfigMap().find(getTarget());\n> \n> /*\n> * This really should not happen, the IPA ought to validate the target\n> * on initialisation.\n> */\n> - ASSERT(cfg != HardwareConfigMap.end());\n> + ASSERT(cfg != hardwareConfigMap().end());\n> return cfg->second;\n> }\n> -- \n> 2.43.0\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id A05EFBE175\n\tfor ;\n\tFri, 18 Jul 2025 14:05:23 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 5B5CE68FA7;\n\tFri, 18 Jul 2025 16:05:22 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 86E056150F\n\tfor ;\n\tFri, 18 Jul 2025 16:05:19 +0200 (CEST)","from pendragon.ideasonboard.com\n\t(cpc89244-aztw30-2-0-cust6594.18-1.cable.virginm.net [86.31.185.195])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 9014F59E3;\n\tFri, 18 Jul 2025 16:04:44 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"qxZB7dEM\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1752847484;\n\tbh=Izi1S05kY1Us9xQJ4HVQ+jCjHGipT485I7zySkvSKRA=;\n\th=In-Reply-To:References:Subject:From:Cc:To:Date:From;\n\tb=qxZB7dEMbpJxprGIS8VFu9z/pr4/Z/d+7Dgza/k9ADkrJ+v0Jz3fkpEUH4mIGiL+5\n\tAS1rxmDyjs9DBUk5NcriYkuMJ+l771CiHyoqXntpAS5qtnZqXL1xT9ldo+1/dwnRCv\n\txSEPEeSCLFH9ZgL4s6Zphqupp8w2cF3l/R5HaXyY=","Content-Type":"text/plain; charset=\"utf-8\"","MIME-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","In-Reply-To":"<20250718104404.1284865-1-naush@raspberrypi.com>","References":"<20250718082402.1207460-1-naush@raspberrypi.com>\n\t<20250718104404.1284865-1-naush@raspberrypi.com>","Subject":"Re: [PATCH] ipa: rpi: Fix static initialisation order bug in the\n\tController","From":"Kieran Bingham ","Cc":"Naushir Patuck ","To":"Naushir Patuck ,\n\tlibcamera-devel@lists.libcamera.org","Date":"Fri, 18 Jul 2025 15:05:16 +0100","Message-ID":"<175284751659.560048.8615485951279837055@ping.linuxembedded.co.uk>","User-Agent":"alot/0.9.1","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34972,"web_url":"https://patchwork.libcamera.org/comment/34972/","msgid":"<781449ba-0e71-4506-b66b-2a61f71155d0@ideasonboard.com>","date":"2025-07-21T15:32:07","subject":"Re: [PATCH] ipa: rpi: Fix static initialisation order bug in the\n\tController","submitter":{"id":216,"url":"https://patchwork.libcamera.org/api/people/216/","name":"Barnabás Pőcze","email":"barnabas.pocze@ideasonboard.com"},"content":"2025. 07. 18. 12:43 keltezéssel, Naushir Patuck írta:\n> There is a possible static initialisation issue with accessing the\n> HardwareConfigMap static object through Controller::getHardwareConfig().\n> Fix this by providing a static function hardwareConfigMap() to access\n> the object.\n> \n> Though not proven, this is possibly the cause of a very infrequent\n> lockup in https://github.com/raspberrypi/rpicam-apps/issues/799.\n> \n> Signed-off-by: Naushir Patuck \n\nReviewed-by: Barnabás Pőcze \n\n\n> ---\n> src/ipa/rpi/controller/controller.cpp | 119 ++++++++++++++------------\n> 1 file changed, 64 insertions(+), 55 deletions(-)\n> \n> diff --git a/src/ipa/rpi/controller/controller.cpp b/src/ipa/rpi/controller/controller.cpp\n> index 651fff632400..df45dcd345b7 100644\n> --- a/src/ipa/rpi/controller/controller.cpp\n> +++ b/src/ipa/rpi/controller/controller.cpp\n> @@ -21,61 +21,70 @@ using namespace std::literals::chrono_literals;\n> \n> LOG_DEFINE_CATEGORY(RPiController)\n> \n> -static const std::map HardwareConfigMap = {\n> -\t{\n> -\t\t\"bcm2835\",\n> +namespace {\n> +\n> +const std::map &hardwareConfigMap()\n> +{\n> +\tstatic const std::map map = {\n> \t\t{\n> -\t\t\t/*\n> -\t\t\t * There are only ever 15 AGC regions computed by the firmware\n> -\t\t\t * due to zoning, but the HW defines AGC_REGIONS == 16!\n> -\t\t\t */\n> -\t\t\t.agcRegions = { 15 , 1 },\n> -\t\t\t.agcZoneWeights = { 15 , 1 },\n> -\t\t\t.awbRegions = { 16, 12 },\n> -\t\t\t.cacRegions = { 0, 0 },\n> -\t\t\t.focusRegions = { 4, 3 },\n> -\t\t\t.numHistogramBins = 128,\n> -\t\t\t.numGammaPoints = 33,\n> -\t\t\t.pipelineWidth = 13,\n> -\t\t\t.statsInline = false,\n> -\t\t\t.minPixelProcessingTime = 0s,\n> -\t\t\t.dataBufferStrided = true,\n> -\t\t}\n> -\t},\n> -\t{\n> -\t\t\"pisp\",\n> +\t\t\t\"bcm2835\",\n> +\t\t\t{\n> +\t\t\t\t/*\n> +\t\t\t\t* There are only ever 15 AGC regions computed by the firmware\n> +\t\t\t\t* due to zoning, but the HW defines AGC_REGIONS == 16!\n> +\t\t\t\t*/\n> +\t\t\t\t.agcRegions = { 15 , 1 },\n> +\t\t\t\t.agcZoneWeights = { 15 , 1 },\n> +\t\t\t\t.awbRegions = { 16, 12 },\n> +\t\t\t\t.cacRegions = { 0, 0 },\n> +\t\t\t\t.focusRegions = { 4, 3 },\n> +\t\t\t\t.numHistogramBins = 128,\n> +\t\t\t\t.numGammaPoints = 33,\n> +\t\t\t\t.pipelineWidth = 13,\n> +\t\t\t\t.statsInline = false,\n> +\t\t\t\t.minPixelProcessingTime = 0s,\n> +\t\t\t\t.dataBufferStrided = true,\n> +\t\t\t}\n> +\t\t},\n> \t\t{\n> -\t\t\t.agcRegions = { 0, 0 },\n> -\t\t\t.agcZoneWeights = { 15, 15 },\n> -\t\t\t.awbRegions = { 32, 32 },\n> -\t\t\t.cacRegions = { 8, 8 },\n> -\t\t\t.focusRegions = { 8, 8 },\n> -\t\t\t.numHistogramBins = 1024,\n> -\t\t\t.numGammaPoints = 64,\n> -\t\t\t.pipelineWidth = 16,\n> -\t\t\t.statsInline = true,\n> -\n> -\t\t\t/*\n> -\t\t\t * The constraint below is on the rate of pixels going\n> -\t\t\t * from CSI2 peripheral to ISP-FE (400Mpix/s, plus tiny\n> -\t\t\t * overheads per scanline, for which 380Mpix/s is a\n> -\t\t\t * conservative bound).\n> -\t\t\t *\n> -\t\t\t * There is a 64kbit data FIFO before the bottleneck,\n> -\t\t\t * which means that in all reasonable cases the\n> -\t\t\t * constraint applies at a timescale >= 1 scanline, so\n> -\t\t\t * adding horizontal blanking can prevent loss.\n> -\t\t\t *\n> -\t\t\t * If the backlog were to grow beyond 64kbit during a\n> -\t\t\t * single scanline, there could still be loss. This\n> -\t\t\t * could happen using 4 lanes at 1.5Gbps at 10bpp with\n> -\t\t\t * frames wider than ~16,000 pixels.\n> -\t\t\t */\n> -\t\t\t.minPixelProcessingTime = 1.0us / 380,\n> -\t\t\t.dataBufferStrided = false,\n> -\t\t}\n> -\t},\n> -};\n> +\t\t\t\"pisp\",\n> +\t\t\t{\n> +\t\t\t\t.agcRegions = { 0, 0 },\n> +\t\t\t\t.agcZoneWeights = { 15, 15 },\n> +\t\t\t\t.awbRegions = { 32, 32 },\n> +\t\t\t\t.cacRegions = { 8, 8 },\n> +\t\t\t\t.focusRegions = { 8, 8 },\n> +\t\t\t\t.numHistogramBins = 1024,\n> +\t\t\t\t.numGammaPoints = 64,\n> +\t\t\t\t.pipelineWidth = 16,\n> +\t\t\t\t.statsInline = true,\n> +\n> +\t\t\t\t/*\n> +\t\t\t\t* The constraint below is on the rate of pixels going\n> +\t\t\t\t* from CSI2 peripheral to ISP-FE (400Mpix/s, plus tiny\n> +\t\t\t\t* overheads per scanline, for which 380Mpix/s is a\n> +\t\t\t\t* conservative bound).\n> +\t\t\t\t*\n> +\t\t\t\t* There is a 64kbit data FIFO before the bottleneck,\n> +\t\t\t\t* which means that in all reasonable cases the\n> +\t\t\t\t* constraint applies at a timescale >= 1 scanline, so\n> +\t\t\t\t* adding horizontal blanking can prevent loss.\n> +\t\t\t\t*\n> +\t\t\t\t* If the backlog were to grow beyond 64kbit during a\n> +\t\t\t\t* single scanline, there could still be loss. This\n> +\t\t\t\t* could happen using 4 lanes at 1.5Gbps at 10bpp with\n> +\t\t\t\t* frames wider than ~16,000 pixels.\n> +\t\t\t\t*/\n> +\t\t\t\t.minPixelProcessingTime = 1.0us / 380,\n> +\t\t\t\t.dataBufferStrided = false,\n> +\t\t\t}\n> +\t\t},\n> +\t};\n> +\n> +\treturn map;\n> +}\n> +\n> +} /* namespace */\n> \n> Controller::Controller()\n> \t: switchModeCalled_(false)\n> @@ -211,12 +220,12 @@ const std::string &Controller::getTarget() const\n> \n> const Controller::HardwareConfig &Controller::getHardwareConfig() const\n> {\n> -\tauto cfg = HardwareConfigMap.find(getTarget());\n> +\tauto cfg = hardwareConfigMap().find(getTarget());\n> \n> \t/*\n> \t * This really should not happen, the IPA ought to validate the target\n> \t * on initialisation.\n> \t */\n> -\tASSERT(cfg != HardwareConfigMap.end());\n> +\tASSERT(cfg != hardwareConfigMap().end());\n> \treturn cfg->second;\n> }","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 791B9C3237\n\tfor ;\n\tMon, 21 Jul 2025 15:32:14 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 2303A68FE9;\n\tMon, 21 Jul 2025 17:32:13 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 985A168FB1\n\tfor ;\n\tMon, 21 Jul 2025 17:32:11 +0200 (CEST)","from [192.168.33.18] (185.221.140.39.nat.pool.zt.hu\n\t[185.221.140.39])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id 431A61121;\n\tMon, 21 Jul 2025 17:31:34 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"kUB8Cihf\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1753111894;\n\tbh=02ujLLvKzf9W7FZqW0dFWlpxw30fB9d6ZhgaMC31DSw=;\n\th=Date:Subject:To:References:From:In-Reply-To:From;\n\tb=kUB8CihfNQfdW0eHZRDMCWaH8YGMaL9R6zdEVLqeUHNdgJIAvlnUNJzASbLq5h1/A\n\tW0qojXWEHLOJ6fdHpNbnP4cKnUtXTf0pfUOI0s3brZf7JoyH5qlw2Qqgg6v+rtilVK\n\tMj8YcWop8SzntegcRi4xJrUp+++JCHLBsr8Zj6Wk=","Message-ID":"<781449ba-0e71-4506-b66b-2a61f71155d0@ideasonboard.com>","Date":"Mon, 21 Jul 2025 17:32:07 +0200","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] ipa: rpi: Fix static initialisation order bug in the\n\tController","To":"Naushir Patuck ,\n\tlibcamera-devel@lists.libcamera.org","References":"<20250718082402.1207460-1-naush@raspberrypi.com>\n\t<20250718104404.1284865-1-naush@raspberrypi.com>","From":"=?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= ","Content-Language":"en-US, hu-HU","In-Reply-To":"<20250718104404.1284865-1-naush@raspberrypi.com>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34973,"web_url":"https://patchwork.libcamera.org/comment/34973/","msgid":"","date":"2025-07-21T15:42:21","subject":"Re: [PATCH] ipa: rpi: Fix static initialisation order bug in the\n\tController","submitter":{"id":42,"url":"https://patchwork.libcamera.org/api/people/42/","name":"David Plowman","email":"david.plowman@raspberrypi.com"},"content":"Hi Naush\n\nFingers crossed it might fix that pesky problem!\n\nOn Mon, 21 Jul 2025 at 16:32, Barnabás Pőcze\n wrote:\n>\n> 2025. 07. 18. 12:43 keltezéssel, Naushir Patuck írta:\n> > There is a possible static initialisation issue with accessing the\n> > HardwareConfigMap static object through Controller::getHardwareConfig().\n> > Fix this by providing a static function hardwareConfigMap() to access\n> > the object.\n> >\n> > Though not proven, this is possibly the cause of a very infrequent\n> > lockup in https://github.com/raspberrypi/rpicam-apps/issues/799.\n> >\n> > Signed-off-by: Naushir Patuck \n>\n> Reviewed-by: Barnabás Pőcze \n\nReviewed-by: David Plowman \n\nThanks\nDavid\n\n>\n>\n> > ---\n> > src/ipa/rpi/controller/controller.cpp | 119 ++++++++++++++------------\n> > 1 file changed, 64 insertions(+), 55 deletions(-)\n> >\n> > diff --git a/src/ipa/rpi/controller/controller.cpp b/src/ipa/rpi/controller/controller.cpp\n> > index 651fff632400..df45dcd345b7 100644\n> > --- a/src/ipa/rpi/controller/controller.cpp\n> > +++ b/src/ipa/rpi/controller/controller.cpp\n> > @@ -21,61 +21,70 @@ using namespace std::literals::chrono_literals;\n> >\n> > LOG_DEFINE_CATEGORY(RPiController)\n> >\n> > -static const std::map HardwareConfigMap = {\n> > - {\n> > - \"bcm2835\",\n> > +namespace {\n> > +\n> > +const std::map &hardwareConfigMap()\n> > +{\n> > + static const std::map map = {\n> > {\n> > - /*\n> > - * There are only ever 15 AGC regions computed by the firmware\n> > - * due to zoning, but the HW defines AGC_REGIONS == 16!\n> > - */\n> > - .agcRegions = { 15 , 1 },\n> > - .agcZoneWeights = { 15 , 1 },\n> > - .awbRegions = { 16, 12 },\n> > - .cacRegions = { 0, 0 },\n> > - .focusRegions = { 4, 3 },\n> > - .numHistogramBins = 128,\n> > - .numGammaPoints = 33,\n> > - .pipelineWidth = 13,\n> > - .statsInline = false,\n> > - .minPixelProcessingTime = 0s,\n> > - .dataBufferStrided = true,\n> > - }\n> > - },\n> > - {\n> > - \"pisp\",\n> > + \"bcm2835\",\n> > + {\n> > + /*\n> > + * There are only ever 15 AGC regions computed by the firmware\n> > + * due to zoning, but the HW defines AGC_REGIONS == 16!\n> > + */\n> > + .agcRegions = { 15 , 1 },\n> > + .agcZoneWeights = { 15 , 1 },\n> > + .awbRegions = { 16, 12 },\n> > + .cacRegions = { 0, 0 },\n> > + .focusRegions = { 4, 3 },\n> > + .numHistogramBins = 128,\n> > + .numGammaPoints = 33,\n> > + .pipelineWidth = 13,\n> > + .statsInline = false,\n> > + .minPixelProcessingTime = 0s,\n> > + .dataBufferStrided = true,\n> > + }\n> > + },\n> > {\n> > - .agcRegions = { 0, 0 },\n> > - .agcZoneWeights = { 15, 15 },\n> > - .awbRegions = { 32, 32 },\n> > - .cacRegions = { 8, 8 },\n> > - .focusRegions = { 8, 8 },\n> > - .numHistogramBins = 1024,\n> > - .numGammaPoints = 64,\n> > - .pipelineWidth = 16,\n> > - .statsInline = true,\n> > -\n> > - /*\n> > - * The constraint below is on the rate of pixels going\n> > - * from CSI2 peripheral to ISP-FE (400Mpix/s, plus tiny\n> > - * overheads per scanline, for which 380Mpix/s is a\n> > - * conservative bound).\n> > - *\n> > - * There is a 64kbit data FIFO before the bottleneck,\n> > - * which means that in all reasonable cases the\n> > - * constraint applies at a timescale >= 1 scanline, so\n> > - * adding horizontal blanking can prevent loss.\n> > - *\n> > - * If the backlog were to grow beyond 64kbit during a\n> > - * single scanline, there could still be loss. This\n> > - * could happen using 4 lanes at 1.5Gbps at 10bpp with\n> > - * frames wider than ~16,000 pixels.\n> > - */\n> > - .minPixelProcessingTime = 1.0us / 380,\n> > - .dataBufferStrided = false,\n> > - }\n> > - },\n> > -};\n> > + \"pisp\",\n> > + {\n> > + .agcRegions = { 0, 0 },\n> > + .agcZoneWeights = { 15, 15 },\n> > + .awbRegions = { 32, 32 },\n> > + .cacRegions = { 8, 8 },\n> > + .focusRegions = { 8, 8 },\n> > + .numHistogramBins = 1024,\n> > + .numGammaPoints = 64,\n> > + .pipelineWidth = 16,\n> > + .statsInline = true,\n> > +\n> > + /*\n> > + * The constraint below is on the rate of pixels going\n> > + * from CSI2 peripheral to ISP-FE (400Mpix/s, plus tiny\n> > + * overheads per scanline, for which 380Mpix/s is a\n> > + * conservative bound).\n> > + *\n> > + * There is a 64kbit data FIFO before the bottleneck,\n> > + * which means that in all reasonable cases the\n> > + * constraint applies at a timescale >= 1 scanline, so\n> > + * adding horizontal blanking can prevent loss.\n> > + *\n> > + * If the backlog were to grow beyond 64kbit during a\n> > + * single scanline, there could still be loss. This\n> > + * could happen using 4 lanes at 1.5Gbps at 10bpp with\n> > + * frames wider than ~16,000 pixels.\n> > + */\n> > + .minPixelProcessingTime = 1.0us / 380,\n> > + .dataBufferStrided = false,\n> > + }\n> > + },\n> > + };\n> > +\n> > + return map;\n> > +}\n> > +\n> > +} /* namespace */\n> >\n> > Controller::Controller()\n> > : switchModeCalled_(false)\n> > @@ -211,12 +220,12 @@ const std::string &Controller::getTarget() const\n> >\n> > const Controller::HardwareConfig &Controller::getHardwareConfig() const\n> > {\n> > - auto cfg = HardwareConfigMap.find(getTarget());\n> > + auto cfg = hardwareConfigMap().find(getTarget());\n> >\n> > /*\n> > * This really should not happen, the IPA ought to validate the target\n> > * on initialisation.\n> > */\n> > - ASSERT(cfg != HardwareConfigMap.end());\n> > + ASSERT(cfg != hardwareConfigMap().end());\n> > return cfg->second;\n> > }\n>","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id D3F18C3237\n\tfor ;\n\tMon, 21 Jul 2025 15:42:36 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 99FDB68FEA;\n\tMon, 21 Jul 2025 17:42:35 +0200 (CEST)","from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com\n\t[IPv6:2607:f8b0:4864:20::72d])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 5F33468FB1\n\tfor ;\n\tMon, 21 Jul 2025 17:42:34 +0200 (CEST)","by mail-qk1-x72d.google.com with SMTP id\n\taf79cd13be357-7e32c95778aso235774885a.3\n\tfor ;\n\tMon, 21 Jul 2025 08:42:34 -0700 (PDT)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (2048-bit key;\n\tunprotected) header.d=raspberrypi.com header.i=@raspberrypi.com\n\theader.b=\"Nyf9lIWw\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=raspberrypi.com; s=google; t=1753112553; x=1753717353;\n\tdarn=lists.libcamera.org; \n\th=content-transfer-encoding:cc:to:subject:message-id:date:from\n\t:in-reply-to:references:mime-version:from:to:cc:subject:date\n\t:message-id:reply-to;\n\tbh=VosIRWbzKVh/NzY+5YhY36rTslK+3jIdEPsJYvcI1Jo=;\n\tb=Nyf9lIWwSpE1R/W8x9rC/HXActNMX0noi2Md5HB65OmOxDpR5otEn/FATMINUu95pi\n\tfrXwd/JqvoJNQMZnptBZ1yZ0TgUOnk6539ykAQhKc28b14vTcUmNI4niX0II8YUbRSp6\n\tDhMsGCIjEXSzBIqqWsr+bIBwlOkbjT8FpgcpHZ96cLrIrB7sugiZQazg7fKMEshFTwHG\n\ta87tPMVR0QWYQZG7Y3XHWLlANL6vY+v72rlxnPfZMHCiG+CxOFtE+PCgfCr0XJ3OSMb4\n\tuNfc6xlC4z4DjVS08LszQFEB01CNYvXQUBDDgXvuf88e2LjeBe4a7uzyPqQnCwBPc3sQ\n\tqwqQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20230601; t=1753112553; x=1753717353;\n\th=content-transfer-encoding:cc:to:subject:message-id:date:from\n\t:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc\n\t:subject:date:message-id:reply-to;\n\tbh=VosIRWbzKVh/NzY+5YhY36rTslK+3jIdEPsJYvcI1Jo=;\n\tb=p27FqlUculV4EB7bWVxZyFU1ZK9mLMcw+NtJH2b/yJcHaN2h48xzuz4k08Y6379uH2\n\tAo6mAxUm5BdPG0hmxTCa6lHOjMVXGAK+bSWgeFTzZ7aiyvpFALHsA1Zvd8bAUxjzlwUZ\n\tF9RAbYUxjRHlaHEZ6RWUNWE6LGzYUaymdUZWYdHMCZj2VxzLk5yEkNC5cciHt2LZCmIA\n\tnjy2ECyY30/k2YiodACAxo/eHIbklDW49kF+nhMC5ynkyZSbUj0vKMTrttK1ufkuwGpg\n\tsaxYPhSyJG5JSOU+xEVldESdWwauMTyJ8VCSYX3vzpa74fw7RQ7pBykLUOWItEAT1jo9\n\tYlcQ==","X-Forwarded-Encrypted":"i=1;\n\tAJvYcCWTRtmsK/msEvS58dA2At6JPj9CcdVyB+O5Jyf8+A8KZAhafxgMmiFLA3heA1ktuVFlrELRQy4XLPukYDcpY08=@lists.libcamera.org","X-Gm-Message-State":"AOJu0YzFUWpAGvRKRYIkHMCrE1drGl8UxQib+NkGmh+T9+RDEhHb7tor\n\tiSA0KzNla1kOJOxDJpTC6E67WeyH5qy9a4ZYFvvQ6k7QBhMo3TSS0+U/NU7jDPfaB41DH7E4S0G\n\tD/pHD06b6wnVsoo/Njbl7qzrC91k9et16Z8aayj5fGA==","X-Gm-Gg":"ASbGncuAU1hdmg7aC9fycBJ5NmeLHf9pHYWXZDU0ZIguk/s3jYYGorcPxlMXnTpw/TQ\n\tYPS/dmAramqfAnif9VRcG7rjXoGfxSbigQ02pASd2+uYSvl7a0mq+j5xQy0x7F8GE7ibQs9cA7+\n\tRJrAXFutQoQkndp5ee32MXWLDUseRhUTjv8WQ9JciZh5ozhnxe0e++b7/unOM6jVbbSIgOyRyXl\n\t1/nJzARd4iigWZwF5Ic/PUyrk2nXPp0FeMdC9Zn9wHmu0LvYQ==","X-Google-Smtp-Source":"AGHT+IEzghT6mH2fm9Fa8vy62K/nwKEEGa/iGE/dbD+LUGNS8YQ7UEhSmqAkQa/SK4sVayNw4eE4oA8i2tN7LoCeO9M=","X-Received":"by 2002:a0c:f40c:0:b0:706:e231:d444 with SMTP id\n\t6a1803df08f44-706e231db30mr27173696d6.8.1753112552760;\n\tMon, 21 Jul 2025 08:42:32 -0700 (PDT)","MIME-Version":"1.0","References":"<20250718082402.1207460-1-naush@raspberrypi.com>\n\t<20250718104404.1284865-1-naush@raspberrypi.com>\n\t<781449ba-0e71-4506-b66b-2a61f71155d0@ideasonboard.com>","In-Reply-To":"<781449ba-0e71-4506-b66b-2a61f71155d0@ideasonboard.com>","From":"David Plowman ","Date":"Mon, 21 Jul 2025 16:42:21 +0100","X-Gm-Features":"Ac12FXyM-ekRIZc8iuinV4q_qS4WlXJ2LAkn_4lSzsnE8wC8e8a9JE-F40kTVLw","Message-ID":"","Subject":"Re: [PATCH] ipa: rpi: Fix static initialisation order bug in the\n\tController","To":"=?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= ","Cc":"Naushir Patuck ,\n\tlibcamera-devel@lists.libcamera.org","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}},{"id":34975,"web_url":"https://patchwork.libcamera.org/comment/34975/","msgid":"<175311446698.50296.11414770610705633048@ping.linuxembedded.co.uk>","date":"2025-07-21T16:14:26","subject":"Re: [PATCH] ipa: rpi: Fix static initialisation order bug in the\n\tController","submitter":{"id":4,"url":"https://patchwork.libcamera.org/api/people/4/","name":"Kieran Bingham","email":"kieran.bingham@ideasonboard.com"},"content":"Quoting David Plowman (2025-07-21 16:42:21)\n> Hi Naush\n> \n> Fingers crossed it might fix that pesky problem!\n> \n> On Mon, 21 Jul 2025 at 16:32, Barnabás Pőcze\n> wrote:\n> >\n> > 2025. 07. 18. 12:43 keltezéssel, Naushir Patuck írta:\n> > > There is a possible static initialisation issue with accessing the\n> > > HardwareConfigMap static object through Controller::getHardwareConfig().\n> > > Fix this by providing a static function hardwareConfigMap() to access\n> > > the object.\n> > >\n> > > Though not proven, this is possibly the cause of a very infrequent\n> > > lockup in https://github.com/raspberrypi/rpicam-apps/issues/799.\n> > >\n> > > Signed-off-by: Naushir Patuck \n> >\n> > Reviewed-by: Barnabás Pőcze \n> \n> Reviewed-by: David Plowman \n> \n\nMerged, thanks.\n\n--\nKieran\n\n> Thanks\n> David\n> \n> >\n> >\n> > > ---\n> > > src/ipa/rpi/controller/controller.cpp | 119 ++++++++++++++------------\n> > > 1 file changed, 64 insertions(+), 55 deletions(-)\n> > >\n> > > diff --git a/src/ipa/rpi/controller/controller.cpp b/src/ipa/rpi/controller/controller.cpp\n> > > index 651fff632400..df45dcd345b7 100644\n> > > --- a/src/ipa/rpi/controller/controller.cpp\n> > > +++ b/src/ipa/rpi/controller/controller.cpp\n> > > @@ -21,61 +21,70 @@ using namespace std::literals::chrono_literals;\n> > >\n> > > LOG_DEFINE_CATEGORY(RPiController)\n> > >\n> > > -static const std::map HardwareConfigMap = {\n> > > - {\n> > > - \"bcm2835\",\n> > > +namespace {\n> > > +\n> > > +const std::map &hardwareConfigMap()\n> > > +{\n> > > + static const std::map map = {\n> > > {\n> > > - /*\n> > > - * There are only ever 15 AGC regions computed by the firmware\n> > > - * due to zoning, but the HW defines AGC_REGIONS == 16!\n> > > - */\n> > > - .agcRegions = { 15 , 1 },\n> > > - .agcZoneWeights = { 15 , 1 },\n> > > - .awbRegions = { 16, 12 },\n> > > - .cacRegions = { 0, 0 },\n> > > - .focusRegions = { 4, 3 },\n> > > - .numHistogramBins = 128,\n> > > - .numGammaPoints = 33,\n> > > - .pipelineWidth = 13,\n> > > - .statsInline = false,\n> > > - .minPixelProcessingTime = 0s,\n> > > - .dataBufferStrided = true,\n> > > - }\n> > > - },\n> > > - {\n> > > - \"pisp\",\n> > > + \"bcm2835\",\n> > > + {\n> > > + /*\n> > > + * There are only ever 15 AGC regions computed by the firmware\n> > > + * due to zoning, but the HW defines AGC_REGIONS == 16!\n> > > + */\n> > > + .agcRegions = { 15 , 1 },\n> > > + .agcZoneWeights = { 15 , 1 },\n> > > + .awbRegions = { 16, 12 },\n> > > + .cacRegions = { 0, 0 },\n> > > + .focusRegions = { 4, 3 },\n> > > + .numHistogramBins = 128,\n> > > + .numGammaPoints = 33,\n> > > + .pipelineWidth = 13,\n> > > + .statsInline = false,\n> > > + .minPixelProcessingTime = 0s,\n> > > + .dataBufferStrided = true,\n> > > + }\n> > > + },\n> > > {\n> > > - .agcRegions = { 0, 0 },\n> > > - .agcZoneWeights = { 15, 15 },\n> > > - .awbRegions = { 32, 32 },\n> > > - .cacRegions = { 8, 8 },\n> > > - .focusRegions = { 8, 8 },\n> > > - .numHistogramBins = 1024,\n> > > - .numGammaPoints = 64,\n> > > - .pipelineWidth = 16,\n> > > - .statsInline = true,\n> > > -\n> > > - /*\n> > > - * The constraint below is on the rate of pixels going\n> > > - * from CSI2 peripheral to ISP-FE (400Mpix/s, plus tiny\n> > > - * overheads per scanline, for which 380Mpix/s is a\n> > > - * conservative bound).\n> > > - *\n> > > - * There is a 64kbit data FIFO before the bottleneck,\n> > > - * which means that in all reasonable cases the\n> > > - * constraint applies at a timescale >= 1 scanline, so\n> > > - * adding horizontal blanking can prevent loss.\n> > > - *\n> > > - * If the backlog were to grow beyond 64kbit during a\n> > > - * single scanline, there could still be loss. This\n> > > - * could happen using 4 lanes at 1.5Gbps at 10bpp with\n> > > - * frames wider than ~16,000 pixels.\n> > > - */\n> > > - .minPixelProcessingTime = 1.0us / 380,\n> > > - .dataBufferStrided = false,\n> > > - }\n> > > - },\n> > > -};\n> > > + \"pisp\",\n> > > + {\n> > > + .agcRegions = { 0, 0 },\n> > > + .agcZoneWeights = { 15, 15 },\n> > > + .awbRegions = { 32, 32 },\n> > > + .cacRegions = { 8, 8 },\n> > > + .focusRegions = { 8, 8 },\n> > > + .numHistogramBins = 1024,\n> > > + .numGammaPoints = 64,\n> > > + .pipelineWidth = 16,\n> > > + .statsInline = true,\n> > > +\n> > > + /*\n> > > + * The constraint below is on the rate of pixels going\n> > > + * from CSI2 peripheral to ISP-FE (400Mpix/s, plus tiny\n> > > + * overheads per scanline, for which 380Mpix/s is a\n> > > + * conservative bound).\n> > > + *\n> > > + * There is a 64kbit data FIFO before the bottleneck,\n> > > + * which means that in all reasonable cases the\n> > > + * constraint applies at a timescale >= 1 scanline, so\n> > > + * adding horizontal blanking can prevent loss.\n> > > + *\n> > > + * If the backlog were to grow beyond 64kbit during a\n> > > + * single scanline, there could still be loss. This\n> > > + * could happen using 4 lanes at 1.5Gbps at 10bpp with\n> > > + * frames wider than ~16,000 pixels.\n> > > + */\n> > > + .minPixelProcessingTime = 1.0us / 380,\n> > > + .dataBufferStrided = false,\n> > > + }\n> > > + },\n> > > + };\n> > > +\n> > > + return map;\n> > > +}\n> > > +\n> > > +} /* namespace */\n> > >\n> > > Controller::Controller()\n> > > : switchModeCalled_(false)\n> > > @@ -211,12 +220,12 @@ const std::string &Controller::getTarget() const\n> > >\n> > > const Controller::HardwareConfig &Controller::getHardwareConfig() const\n> > > {\n> > > - auto cfg = HardwareConfigMap.find(getTarget());\n> > > + auto cfg = hardwareConfigMap().find(getTarget());\n> > >\n> > > /*\n> > > * This really should not happen, the IPA ought to validate the target\n> > > * on initialisation.\n> > > */\n> > > - ASSERT(cfg != HardwareConfigMap.end());\n> > > + ASSERT(cfg != hardwareConfigMap().end());\n> > > return cfg->second;\n> > > }\n> >","headers":{"Return-Path":"","X-Original-To":"parsemail@patchwork.libcamera.org","Delivered-To":"parsemail@patchwork.libcamera.org","Received":["from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id 9CF04BDCC1\n\tfor ;\n\tMon, 21 Jul 2025 16:14:31 +0000 (UTC)","from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id CABBC68FF2;\n\tMon, 21 Jul 2025 18:14:30 +0200 (CEST)","from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[213.167.242.64])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id AB2B068FE5\n\tfor ;\n\tMon, 21 Jul 2025 18:14:29 +0200 (CEST)","from pendragon.ideasonboard.com\n\t(cpc89244-aztw30-2-0-cust6594.18-1.cable.virginm.net [86.31.185.195])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id A48107940;\n\tMon, 21 Jul 2025 18:13:52 +0200 (CEST)"],"Authentication-Results":"lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"YO7ZQIx9\"; dkim-atps=neutral","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1753114432;\n\tbh=FncXDu2V2JjhuEZgQL7Dz6615AgQlEypRrwRBwtrBGE=;\n\th=In-Reply-To:References:Subject:From:Cc:To:Date:From;\n\tb=YO7ZQIx9Rpfry4uF6GPkySC8HmxvkvtHx1F3yB801yZdDCdPeMndFcWuWopTvAZA0\n\tWuxG15SQvyH256iNz72KyvPgXqVaeXrvUPGd+rZ3PAkqoi/JhbwmWhvXmJqZ4n5Gpr\n\t+CE4/dJp9OSOwqJcSkk6bLiPhNhnZoXLrLLCXmNY=","Content-Type":"text/plain; charset=\"utf-8\"","MIME-Version":"1.0","Content-Transfer-Encoding":"quoted-printable","In-Reply-To":"","References":"<20250718082402.1207460-1-naush@raspberrypi.com>\n\t<20250718104404.1284865-1-naush@raspberrypi.com>\n\t<781449ba-0e71-4506-b66b-2a61f71155d0@ideasonboard.com>\n\t","Subject":"Re: [PATCH] ipa: rpi: Fix static initialisation order bug in the\n\tController","From":"Kieran Bingham ","Cc":"Naushir Patuck ,\n\tlibcamera-devel@lists.libcamera.org","To":"=?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= ,\n\tDavid Plowman ","Date":"Mon, 21 Jul 2025 17:14:26 +0100","Message-ID":"<175311446698.50296.11414770610705633048@ping.linuxembedded.co.uk>","User-Agent":"alot/0.9.1","X-BeenThere":"libcamera-devel@lists.libcamera.org","X-Mailman-Version":"2.1.29","Precedence":"list","List-Id":"","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Errors-To":"libcamera-devel-bounces@lists.libcamera.org","Sender":"\"libcamera-devel\" "}}]