Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4348075imm; Fri, 18 May 2018 03:43:03 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrzWqWyHryzh0K/uKwVECb4aIDA12GrC9KYQvJaX0cFQXkog7Q0WOYs+349WC/cosZ3fB1E X-Received: by 2002:a17:902:343:: with SMTP id 61-v6mr9208405pld.39.1526640183744; Fri, 18 May 2018 03:43:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526640183; cv=none; d=google.com; s=arc-20160816; b=TDYYdA3Pn7a/2Ykc/GZVEClCyjXjcyqBSk0OrbT4QyKRBrKIsZG/fm065iGBRm2NIV XK0T6ScXWcQp5XwsTGFIChcs2eu06wcX9QJ+ENV+qDVlIzdJyDtNZxB9df/jskHlgX6a 3qwJyLyi0Ki5gB50rZQDa6HW6Oi/Q7NsiCrAJ9SESjrHWJtJuecmQSqI+qK263XVilB5 8ke/0UmSbhn+T30rhk3mPKqwb17Vwo7X0c8iroqSTNdCPd47zEZmgLNQyDx7qPEmrZb3 C2d0Arwj79BVruvxtJML5oID0P05jRx7IKvhYswroMfflV63R8bCmLOMlQwPYFkHSLgh CMVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=ZuxCuj740r/iBTOZjLYX2dHtzBOSLHbPAhXNNRCG0GU=; b=Ju/3sQF61MudC2aYrUDIaPDseEKa2bL+dNUtCfxNjCOwDsKJht9wJtwsZjiaSqEd+/ fT0k1GBVBRw7oVs/DNci8Xi2oesodx7dqd9ik9ykPEQsASTQujdaxOwAoHliXmPXEihE zvyB2dIfMmvg5HDnpKYavgJ+0lMQpHYqQ6eUps7c1kREwV4pCHmHWBfg4ROCA4pxqkW0 ivnnhFFgieIBDTpSb9Cl7/FPcfFBSfJMoQbXcOn6gxQKis6yiUvDknwMKp/0+E6MqXi3 2JqWKG5+QUjwHuRCYBzjxqKSgX+BEd5oMd/vZxk1ozgDvv7VJWqTzQpbp3sLrvD01ZWb GROA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d20-v6si6968014pfn.213.2018.05.18.03.42.49; Fri, 18 May 2018 03:43:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752576AbeERKmj (ORCPT + 99 others); Fri, 18 May 2018 06:42:39 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:47898 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751429AbeERKmh (ORCPT ); Fri, 18 May 2018 06:42:37 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 983A61435; Fri, 18 May 2018 03:42:36 -0700 (PDT) Received: from [10.1.210.88] (e110467-lin.cambridge.arm.com [10.1.210.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C1F363F53D; Fri, 18 May 2018 03:42:34 -0700 (PDT) Subject: Re: [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge To: Sinan Kaya , linux-pci@vger.kernel.org, timur@codeaurora.org, ard.biesheuvel@linaro.org Cc: "open list:EFIFB FRAMEBUFFER DRIVER" , Bartlomiej Zolnierkiewicz , linux-arm-msm@vger.kernel.org, open list , "open list:FRAMEBUFFER LAYER" , Peter Jones , linux-arm-kernel@lists.infradead.org References: <1526563343-28721-1-git-send-email-okaya@codeaurora.org> From: Robin Murphy Message-ID: <36cf3f12-bfe8-1c38-4d2c-b785fc64a3f6@arm.com> Date: Fri, 18 May 2018 11:42:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1526563343-28721-1-git-send-email-okaya@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/05/18 14:22, Sinan Kaya wrote: > A host bridge is allowed to remap BAR addresses using _TRA attribute in > _CRS windows. > > pci_bus 0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff]) > pci 0000:02:00.0: reg 0x10: [mem 0x8011e000000-0x8011effffff] > > When a VGA device is behind such a host bridge and the resource is > translated efifb driver is trying to do ioremap against bus address > rather than the resource address and is failing to probe. > > efifb driver is having difficulty locating the base address from BAR > address when > > efifb: probing for efifb > efifb: cannot reserve video memory at 0x1e000000 > efifb: framebuffer at 0x1e000000, using 1920k, total 1875k > efifb: mode is 800x600x32, linelength=3200, pages=1 > efifb: scrolling: redraw > efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 > > Use the host bridge offset information to convert bus address to > resource address in the fixup. > > Signed-off-by: Sinan Kaya > --- > drivers/video/fbdev/efifb.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c > index 46a4484..ea68d5c 100644 > --- a/drivers/video/fbdev/efifb.c > +++ b/drivers/video/fbdev/efifb.c > @@ -428,6 +428,8 @@ static void efifb_fixup_resources(struct pci_dev *dev) > { > u64 base = screen_info.lfb_base; > u64 size = screen_info.lfb_size; FWIW, now that I've actually gone and looked, it appears you could simplify the whole function quite a bit by getting rid of these and just using the new local resource directly, especially since the only actual use of size is an open-coded resource_contains(). > + struct pci_bus_region region; > + struct resource res; > int i; > > if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI) > @@ -439,6 +441,14 @@ static void efifb_fixup_resources(struct pci_dev *dev) > if (!base) > return; > > + region.start = base; > + region.end = base + size - 1; > + res.start = 0; > + res.flags = IORESOURCE_MEM; > + pcibios_bus_to_resource(dev->bus, &res, ®ion); > + if (res.start) > + base = res.start; > + > for (i = 0; i <= PCI_STD_RESOURCE_END; i++) { > struct resource *res = &dev->resource[i]; The inadvertent name shadowing here is a bit yuck, though, and I think sparse will whinge about it, so it's probably worth renaming one or the other. Robin.