Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1798661imu; Thu, 17 Jan 2019 03:30:19 -0800 (PST) X-Google-Smtp-Source: ALg8bN5zsmsf44KhcGpq4uP6JpDgpmKx2RtL7G/TZHZKXMt85L34uXxy7IiQ0lD4CXHhIwkI7jWH X-Received: by 2002:a17:902:7296:: with SMTP id d22mr14848867pll.265.1547724619927; Thu, 17 Jan 2019 03:30:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547724619; cv=none; d=google.com; s=arc-20160816; b=RLG70AUkAbs/lUsPaHYp2knK8gm0y8+3Ax+jypB9FMg2wrzBqt3Qc5eeTb9jLIT9IT c1aHKNQTFGReaByD/szaqyrJHLNcTRtgO1J6TUshnnNTGb+l2qy0jpONnKqHKTn9ljpN kKepqPvQg3302MdzKJwk1OCdg5CnYl+eohQ1cNH2XINidRNEUYkNU57d+RweENFiDnda etHtNwZl5ECoYRp8Z7vvchftL/sy/n/+pspE2qRmjI1aIv2E4ko7nGXN/qwPyc9gJUxC ObXch5FsuCt52Y6jTg7BO7K+xP+IAUg+SqYniPlw64Tqj/UAqDjcHszabzMuUJKUvYOe Rbvg== 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:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=5vvLDWEiVbaSjosdnNhdExQx1J5pKqBt7STR8lylKws=; b=HHN+zNrIJZ3dselY4bgnWC/jGm7uQKYlqcfBoV1BIdCuYOoV0MsZxMb4KVTVJbD4S9 3tg5dbwMDzgQ90KRNXkItN52TMO/fXmjSy4O+eKCcVB8QYtGWIw9ut98y/eEEbQFpMH0 YzpiJhvwr8J5TgY2l4sZSpECflN88TD6N475WzwWeBgG2ClvXZzhmXjfq1x0/nhP9IUt j/UwR+7tWl9K4QWOZZel/rYbKLNs0NKW7LeTc2SYy5rzKPu4FQXiHzh5yLZPWlo5Wfnx kgjo7HpmaWqnAIfvIusOi5fqeUWjcPLseZvgO63+6pXw10gtRn5sUaKUtql26HZJ831v AzZA== 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 p11si1373498plk.191.2019.01.17.03.30.03; Thu, 17 Jan 2019 03:30:19 -0800 (PST) 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 S1727588AbfAQGAo (ORCPT + 99 others); Thu, 17 Jan 2019 01:00:44 -0500 Received: from gate.crashing.org ([63.228.1.57]:57491 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725320AbfAQGAo (ORCPT ); Thu, 17 Jan 2019 01:00:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x0H5xrlO023594; Wed, 16 Jan 2019 23:59:54 -0600 Message-ID: Subject: Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM From: Benjamin Herrenschmidt To: "Koenig, Christian" , Michael Ellerman , Will Deacon Cc: Ard Biesheuvel , Michel =?ISO-8859-1?Q?D=E4nzer?= , Linux Kernel Mailing List , Carsten Haitzler , David Airlie , dri-devel , "Huang, Ray" , "Zhang, Jerry" , linux-arm-kernel , Bernhard =?ISO-8859-1?Q?Rosenkr=E4nzer?= Date: Thu, 17 Jan 2019 16:59:53 +1100 In-Reply-To: <9dc27cbf-e109-0c32-fc92-6fce1b224cda@amd.com> References: <20190110072841.3283-1-ard.biesheuvel@linaro.org> <5d8135de-80fe-9c0e-2206-ecb809f64cdb@daenzer.net> <55facfb9-92af-86b8-40e9-d63b887b5592@amd.com> <9f956898-7973-98ee-6bf1-e1d445e9d365@amd.com> <20190114191350.GA29600@fuggles.cambridge.arm.com> <20190114193548.GB29600@fuggles.cambridge.arm.com> <87a7k2yx66.fsf@concordia.ellerman.id.au> <9dc27cbf-e109-0c32-fc92-6fce1b224cda@amd.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.4 (3.30.4-1.fc29) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2019-01-16 at 07:35 +0000, Koenig, Christian wrote: > No, but you answer the wrong question. > > See we don't want to have different mappings of cached and non-cached on > the CPU, but rather want to know if a snooped DMA from the PCIe counts > as cached access as well. > > As far as I know on x86 it doesn't, so when you have an un-cached page > you can still access it with a snooping DMA read/write operation and > don't cause trouble. Hrm... well, if you map it uncached on the CPU on powerpc, a snoop DMA will work fine too, it won't hit any cache. The only problem I'm aware of is a core (or CAPI device) emiting non-cached load/stores colliding with a cache snooper. > > The old hack of using non-cached mapping to avoid snoop cost in AGP and > > others is just that ... an ugly and horrible hacks that should have > > never eventuated, when the search for performance pushes HW people into > > utter insanity :) > > Well I agree that un-cached system memory makes things much more > complicated for a questionable gain. > > But fact is we now have to deal with the mess, so no point in > complaining about it to much :) I wish we could just sent the HW designers home and tell them we won't support that crap... oh well. Ben. > Cheers, > Christian. > > > Cheers, > > Ben. > > > >