From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C55123C456A for ; Tue, 2 Jun 2026 15:04:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780412665; cv=none; b=tMVYH/YUItyQ7ryPoQnU3tSvToemlJy4xGn4BhDYSquOk8kdRwnu4jJr4qklmnh3LwXwkWLL8DtWbckHEY9quzWou4Ye/543Y+0GdSsThplNIY4ORYi1DR4otE8OENQDDNxvr9YySEcs9+Y1drPWLAlEOHtK2argSyCgLyPw6lM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780412665; c=relaxed/simple; bh=hhLyU1suKqRemMZ3uMjdPzeVwrqN8+HIhvS6Kah3daM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=aycr/ZFTeH3DWRjFFubWe4n3VtMonxHroFIyPOG82EwBzORLCQQWj/Y18u1qmgb0UeOn5hQCR7H0s/anHyrGPgkFRTpahmAynPpqmzBNfSk7PUKnYAKVrcwgAz6rcIpXq+Q0tmt09xQuVysBJBUMRR5WKBq6BAnFEV1xsn7cmos= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool; spf=pass smtp.mailfrom=packett.cool; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b=BFgAAH/x; arc=none smtp.client-ip=95.215.58.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=packett.cool Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b="BFgAAH/x" Message-ID: <809635d9-6e66-4ace-8f47-4a5a268f4f18@packett.cool> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packett.cool; s=key1; t=1780412652; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qHszsEN8PB3ekey0lEf70Vm5pm7eZsuxWjxfuJZ2+RI=; b=BFgAAH/xcynmV8UeSdeG6LKfgfP4MDNJFZp6R2gs0qShyj4nudTtq4HPYoLRzSCxM9Q07h S1Bs1hlDJFHvewK5FG2GtTvPu6On7jrT47U9dCsObZJ4qcmTaYpELOFFDop47C1nUjkdKp 4p7LeOgwfHBZmMNNdAtTmnCfVnAO1hS2FmTw9rsw9MUR/HRiPwHhL4aZinED5PCg04yoiX 8il1U+Dw6dtacMog5D3eXtfu0UsCocDvUxBGFAFRLycFYJaPCl0kQt/ARiekfRIXJy36bl lF0nMon19m8s8y3wQlA7IqUh9deLu1ALcxMtcXUaDeH3BVHO7Xbjo4pfwMyoKA== Date: Tue, 2 Jun 2026 12:03:53 -0300 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 2/2] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris To: Bryan O'Donoghue , Daniel J Blueman , Vikash Garodia , Dikshita Agarwal , Abhinav Kumar , Bjorn Andersson , Konrad Dybcio Cc: Mauro Carvalho Chehab , Rob Herring , Krzysztof Kozlowski , Conor Dooley , linux-arm-msm@vger.kernel.org, linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260601041336.9497-1-daniel@quora.org> <20260601041336.9497-2-daniel@quora.org> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Val Packett In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 6/2/26 7:26 AM, Bryan O'Donoghue wrote: > On 01/06/2026 05:13, Daniel J Blueman wrote: >> On X1-family hamoa platforms, Iris DMA below IOVA 0x25800000 (600MB) >> triggers unhandled SMMU page faults > > How do we know that is a correct address - does it come from qcom > documentation or trial and error ? If you follow the Link:, you can see that it does come from qcom.. https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574 This series is basically a "hotfix" version of a more complicated series: https://lore.kernel.org/linux-media/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/ that introduced an extra subnode that let the driver only use that restricted IOVA range for non-pixel buffers (only those actually need the restriction) but that resulted in a very long discussion and was kinda shelved because of that.. x_x ~val