From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C4860C433F5 for ; Thu, 20 Jan 2022 13:56:02 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 864D28386B; Thu, 20 Jan 2022 14:56:00 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="AagQThvR"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 4417983852; Thu, 20 Jan 2022 14:55:59 +0100 (CET) Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 2F5CB8386B for ; Thu, 20 Jan 2022 14:55:56 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C114561770; Thu, 20 Jan 2022 13:55:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1048DC340E0; Thu, 20 Jan 2022 13:55:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1642686954; bh=7MH4KBbdozoEBzsAE75+2vL7xj8aKLqNBzEHy2GUs14=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AagQThvR3cmYEuSo64mm44iMEe3AojU66J6uOWuSv5nMOVU3wQjmfP02k6w5zt77L lAXf1C7mUjVp9MXqJMhewqWyiZPYkjFq6LzAyLiAVacNPh9xO0xwZHZW5U7Q4pG0KR 7PNtHMY6c9LMvG9MUXaO2/swYsvMsPWV829Oc+4NQAan6uKy7hW5sIls8YK4oMNTdS mzWakBUt/zyo64n1CNp3I0cUgetpGPJ09DyFv4KtY2srAIBelOPPXgsu0kY1tdX611 6868SpqThjxkpLrPC5GqGu15qPZkvKVZ1jnBi6H9aNvMMEspaWW3zUiq9+qDo/AH4E FksUGMxt1QevA== Received: by pali.im (Postfix) id B1FD6791; Thu, 20 Jan 2022 14:55:51 +0100 (CET) Date: Thu, 20 Jan 2022 14:55:51 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Mark Kettenis Cc: Alistair Delva , trini@konsulko.com, sjg@chromium.org, sr@denx.de, marek.behun@nic.cz, u-boot@lists.denx.de Subject: Re: Commit 4f2e2280862a ("RFC: arm: pci: Add PCI cam support to PCI-E ecam driver") Message-ID: <20220120135551.d5heaeq2u4chdjbb@pali> References: <20220113123432.zdqqnhsn65ujijwj@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Hello Mark! On Thursday 20 January 2022 00:23:02 Mark Kettenis wrote: > CAM is just a version of ECAM that only gives you access to the > classic PCI config space (register offsets < 256). This has very > little to do with the classic "mode 1" and "mode 2" config space > access methods of the x86 PCI host bridges. Interesting... as I have not found anything about CAM in specs... That is why I thought it must be some proprietary, vendor-specific or non-standard access method. "mode 1" is indirect access method and "mode 2" has mapped config space into (io) memory space. But this "CAM" is neither "mode 1" nor "mode 2". That is why it looked suspicious to me. > I don't think there is a > CAM standard at all, but some of the PCI host bridges found on PowerPC > and SPARC hardware implemented a straight mapping of PCI config space > into mmio space like that. Interesting... But at least it looks like that U-Boot does not have support for these kind of hardware. Anyway, is not that mapping in that old hardware of PCI config space into mmio space according to "mode 2" layout? I know that both "mode 1" and "mode 2" are IO-space orientated, but on non-x86 HW there probably does not have to be IO-space and same layout can be used also for memory-space mapping. > It is a little bit strange that crosvm implements CAM instead of ECAM, > but I guess they don't care about passthrough of arbitrary PCIe > devices. And as long as all (emulated) PCIe devices only have > registers with offsets < 256, this will work just fine. > > And yes, you should check that the register offset is limited to > 0..255.