From patchwork Tue Jul 9 01:15:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Vasut X-Patchwork-Id: 1129439 X-Patchwork-Delegate: lorenzo.pieralisi@arm.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="EvzVRlYq"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 45jPbF6XB3z9sMQ for ; Tue, 9 Jul 2019 11:18:33 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726089AbfGIBSb (ORCPT ); Mon, 8 Jul 2019 21:18:31 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:54435 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725905AbfGIBSb (ORCPT ); Mon, 8 Jul 2019 21:18:31 -0400 Received: by mail-wm1-f67.google.com with SMTP id p74so1301528wme.4; Mon, 08 Jul 2019 18:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=vRVbPF/0ajosmPN4Ay8z+zKHDksJfcNn8uHA4+U9uZo=; b=EvzVRlYqYQ6yoFh4cC0XWd3R7HJSf9wCHcq+3VF25GatybqCHlhEimdyv3CtZIHoJZ eKcKwd7Mh8chovX6y5xmDSok4vpWLxDVE8CeELXOUD02NVRFPP2EaJu6Vqv3Rb3cxKzd pPZa+qQTeZZc/F02daQ2KXOV+ohb8DnRNoTXFE38GtW01YSa7F/F/IX5qH3Y78AumfHZ ZX36JEfizHmXGscAanulIZFQshHGKVk15CPg4r2aU0dQOn8ACXFS7bVpJw8qtPyZdqy7 q9VXU9gPrJzCZSlQ0fgc1XDqIxO+VMQ8ArqHbHNhIMFzMGf8aOfyfXHQhVimcSWGLgSE xpGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=vRVbPF/0ajosmPN4Ay8z+zKHDksJfcNn8uHA4+U9uZo=; b=LDPJjFkLr3JJuaZWWT81qBFIKapSMHxffizFCtXnXPveQXCFUchJGdPhVUiY6A8sda 0RPSrUVmYBIiJYLUNSGNp8dcoc9mrzw8cIkuz7eNm5ntsJQYIgKv3NlEusCjMzSy2m16 /up7x7n3tG4dfnobPZ+wQ5GlwAQ+Vit/S2eS2SrI72XWQcJU2O1CJSKy9cWbAFcXwB+S MTCCwiL+fQGeWxfXgI3ZG30JSfFvULpxDqfMaBPr02dWeu0UfYIakHZYoY1ZZ2jCxET9 KDHoBBd+XRgEreZ+wAXNbgrx9qxP8o/NVI1aK9cqVcUPh1dC7ZK7RHlT0C85Ojpsu0r0 0L1g== X-Gm-Message-State: APjAAAXE2RLDNFxSv5miX/G8pCzRt75xQa7ZOoMXVPE4ddMGLWaqfUAf jkU8gPivuLiiDqdKgxkoa1ebT0Sk X-Google-Smtp-Source: APXvYqxUar/3qwAPoesl+6yYlgNNPaPGwPAqehO4FaJouMJW8FtGegTPfb++Q2YJ7XdU2WGLf6B0PA== X-Received: by 2002:a7b:c3d5:: with SMTP id t21mr17227935wmj.87.1562635108528; Mon, 08 Jul 2019 18:18:28 -0700 (PDT) Received: from kurokawa.lan (ip-86-49-110-70.net.upcbroadband.cz. [86.49.110.70]) by smtp.gmail.com with ESMTPSA id a8sm935505wma.31.2019.07.08.18.18.27 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 08 Jul 2019 18:18:27 -0700 (PDT) From: marek.vasut@gmail.com To: linux-pci@vger.kernel.org Cc: Marek Vasut , Geert Uytterhoeven , Lorenzo Pieralisi , Wolfram Sang , linux-renesas-soc@vger.kernel.org Subject: [PATCH 1/2] PCI: rcar: Do not abort on too many inbound dma-ranges Date: Tue, 9 Jul 2019 03:15:58 +0200 Message-Id: <20190709011559.12379-1-marek.vasut@gmail.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Marek Vasut In case the "dma-ranges" DT property contains either too many ranges or the range start address is unaligned in such a way that populating the range into the controller requires multiple entries, a situation may occur where all ranges cannot be loaded into the controller. Currently, the driver refuses to probe in such a situation. Relax this behavior, load as many ranges as possible and warn if some ranges do not fit anymore. Signed-off-by: Marek Vasut Cc: Geert Uytterhoeven Cc: Lorenzo Pieralisi Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org To: linux-pci@vger.kernel.org --- drivers/pci/controller/pcie-rcar.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c index f6a669a9af41..938adff4148f 100644 --- a/drivers/pci/controller/pcie-rcar.c +++ b/drivers/pci/controller/pcie-rcar.c @@ -1069,8 +1069,9 @@ static int rcar_pcie_inbound_ranges(struct rcar_pcie *pcie, idx += 2; if (idx > MAX_NR_INBOUND_MAPS) { - dev_err(pcie->dev, "Failed to map inbound regions!\n"); - return -EINVAL; + dev_warn(pcie->dev, + "Too many inbound regions, not all are mapped.\n"); + break; } } *index = idx; From patchwork Tue Jul 9 01:15:59 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Vasut X-Patchwork-Id: 1129440 X-Patchwork-Delegate: lorenzo.pieralisi@arm.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-pci-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="npo/sUpf"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 45jPbH43KRz9sN1 for ; Tue, 9 Jul 2019 11:18:35 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725905AbfGIBSc (ORCPT ); Mon, 8 Jul 2019 21:18:32 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:37998 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726084AbfGIBSc (ORCPT ); Mon, 8 Jul 2019 21:18:32 -0400 Received: by mail-wm1-f65.google.com with SMTP id s15so1374067wmj.3; Mon, 08 Jul 2019 18:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=7hNWY8uNbIRl37SQi0eQaMekWDSfGmV7hpebI34lt8c=; b=npo/sUpfXJcUqz17u/z89ANUyQv6FiXOWQvxEzg1IUOv5EW/d9krTekRbCIJ9SjKBN o4WE3uAIHwmQzF4Y7GJWvWi9Kswi1hXGQYhG1skPMksn4fVlueEFUGuCBRnRJDoO9UkH nXFvLlJUchqsXXN9bJDbikrQJSz30+kCf4NSXk9OLMRKy1o+QyRdj/xBcNo9Dk42m3mp 2fipsf3vCphCLUHpcmx/LjTZyKdyt2fxUq4LCeACZmxB2OKhwpLw2GqdwglaBN4wYcK/ 0q6sCSHsOUAa37VYfVwAVOI6MT82koUozQLN1NhtYIDe5oxqvMGTl+deYvdpgZov5JF6 J1sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7hNWY8uNbIRl37SQi0eQaMekWDSfGmV7hpebI34lt8c=; b=FL5qrNkywLl83Rubq9P0mI29UcrfrL22YJ7A/1GjFkhW0T1xd7uB1cZUFbgIwVGQ8E vCSonWAqD/swqgaFybPpkkCLyskG4Px2fUpn+PMv+5MpLjgAXO7DsmfgaqRDbdmKS7Xw dnPbs1EynZxZLYnYtmByayyZ1sOYlbJfrcBDH2GeJ+yCivB6CWA6S0CAAM+wVpgXTP/P XTS/Gw4Lnp07BWPrzwUkHT22D0NDtjTZH7tDQUt7YPa1gDu9vF/37KEYKqbnoJbxrCjU K98XtXrkIzU7rw9gaFqJ+kXdoWcLMOpLWG0RMA9w1Ey1eDbujrO8MNdwJt6rsyoLJ9Lv yevw== X-Gm-Message-State: APjAAAVNb3Pu2k6jz0ZvYnYfYESctbL9KeqZzmBT7o+9jzsmO/P2pGP6 O+pwzo6DKjmm+sVKy/XHW4zWE6vf X-Google-Smtp-Source: APXvYqyxlglEmxp5kkh8NHQLMdo1U+mkZoNWuEemxfDk4AMdRj3uhE3e4QeF5S529Ms8A7Tzg9fwOA== X-Received: by 2002:a1c:7e90:: with SMTP id z138mr18285817wmc.128.1562635109863; Mon, 08 Jul 2019 18:18:29 -0700 (PDT) Received: from kurokawa.lan (ip-86-49-110-70.net.upcbroadband.cz. [86.49.110.70]) by smtp.gmail.com with ESMTPSA id a8sm935505wma.31.2019.07.08.18.18.28 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 08 Jul 2019 18:18:28 -0700 (PDT) From: marek.vasut@gmail.com To: linux-pci@vger.kernel.org Cc: Marek Vasut , Geert Uytterhoeven , Lorenzo Pieralisi , Wolfram Sang , linux-renesas-soc@vger.kernel.org Subject: [PATCH 2/2] PCI: rcar: Recalculate inbound range alignment for each controller entry Date: Tue, 9 Jul 2019 03:15:59 +0200 Message-Id: <20190709011559.12379-2-marek.vasut@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190709011559.12379-1-marek.vasut@gmail.com> References: <20190709011559.12379-1-marek.vasut@gmail.com> MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Marek Vasut Due to hardware constraints, the size of each inbound range entry populated into the controller cannot be larger than the alignment of the entry's start address. Currently, the alignment for each "dma-ranges" inbound range is calculated only once for each range and the increment for programming the controller is also derived from it only once. Thus, a "dma-ranges" entry describing a memory at 0x48000000 and size 0x38000000 would lead to multiple controller entries, each 0x08000000 long. This is inefficient, especially considering that by adding the size to the start address, the alignment increases. This patch moves the alignment calculation into the loop populating the controller entries, thus updating the alignment for each controller entry. Signed-off-by: Marek Vasut Cc: Geert Uytterhoeven Cc: Lorenzo Pieralisi Cc: Wolfram Sang Cc: linux-renesas-soc@vger.kernel.org To: linux-pci@vger.kernel.org Reviewed-by: Simon Horman --- drivers/pci/controller/pcie-rcar.c | 33 +++++++++++++++--------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c index 938adff4148f..48f361b5d690 100644 --- a/drivers/pci/controller/pcie-rcar.c +++ b/drivers/pci/controller/pcie-rcar.c @@ -1029,25 +1029,26 @@ static int rcar_pcie_inbound_ranges(struct rcar_pcie *pcie, if (restype & IORESOURCE_PREFETCH) flags |= LAM_PREFETCH; - /* - * If the size of the range is larger than the alignment of the start - * address, we have to use multiple entries to perform the mapping. - */ - if (cpu_addr > 0) { - unsigned long nr_zeros = __ffs64(cpu_addr); - u64 alignment = 1ULL << nr_zeros; + while (cpu_addr < cpu_end) { + /* + * If the size of the range is larger than the alignment of + * the start address, we have to use multiple entries to + * perform the mapping. + */ + if (cpu_addr > 0) { + unsigned long nr_zeros = __ffs64(cpu_addr); + u64 alignment = 1ULL << nr_zeros; - size = min(range->size, alignment); - } else { - size = range->size; - } - /* Hardware supports max 4GiB inbound region */ - size = min(size, 1ULL << 32); + size = min(range->size, alignment); + } else { + size = range->size; + } + /* Hardware supports max 4GiB inbound region */ + size = min(size, 1ULL << 32); - mask = roundup_pow_of_two(size) - 1; - mask &= ~0xf; + mask = roundup_pow_of_two(size) - 1; + mask &= ~0xf; - while (cpu_addr < cpu_end) { /* * Set up 64-bit inbound regions as the range parser doesn't * distinguish between 32 and 64-bit types.