Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4745879imu; Tue, 15 Jan 2019 05:23:44 -0800 (PST) X-Google-Smtp-Source: ALg8bN7EBPtzFgiaoXsQC8kUVeHHIeFb1PSPcW07yIrmd+WXtdnddW08Pet4hVC42clGaFxtvphi X-Received: by 2002:a17:902:9a07:: with SMTP id v7mr4001924plp.247.1547558624405; Tue, 15 Jan 2019 05:23:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547558624; cv=none; d=google.com; s=arc-20160816; b=kPsHsL+DTelTBd9A4I+b+RMJkAbFfk2KOZvT9pehjbLF2o8V86FhM7wdycHggkprJ5 3H+TnajXEFaUVE5ccnrao5OHTmzDXotb4JIvsnYIT+u4ruBzLSg3BW2EqPmrd6YAhFHJ yPQFdWslrHg03W3LWinaApS/7w/N+QXKc6y9T8a8m1jlvYkZiPNTIMfPjTGvs276/5WI tbItgvVCDXw0ZWPcx/nCCUFceiFVINYCTv3AzwDQYog8XZQRkNVEc1bnkYcGDZpb9RhL H7Nyu+MsFUkT15KZKKNECuwxzuVRELyDZLs3YQvhI4OF5N6ItgmggReB3PsqeosEzvDz iFrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=WkTFt7GHu6L7/WlulFN7FoxLJV3AAAfGHkpl1kjI5fs=; b=kANA3V79ULWWmPMQWrN7GJPkonJNbUMyk50C/cyVsCXqk8hxDe7mkanjUGgssGAGga 2tqEWQpHIRuKhnMyrAJcXTmidJIEH795IXqAaaVbRKa250wypgdrQe5hD5zQcZnzRA6s OkopVZbHxIcWeHZg/QbwAOvbqQyiP9ny4GWmyyeS2jTXWmGdaG4+u697zg+2gBKjojpP +wKwxjvUE6vEkP3+ngLdItiRRq9ekbjYMzL5mi7LkoEFwIxzVtoBh7fiGmtBkMG6aMeo qxriolgBJYgm3Hpyr+j8LwTWYmCIbjJmvxAQ6VZWPKNPen9WspsyqQRTX8k66shbian5 zbDQ== 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 s8si126781pgm.508.2019.01.15.05.23.25; Tue, 15 Jan 2019 05:23:44 -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 S1728478AbfAOLbe (ORCPT + 99 others); Tue, 15 Jan 2019 06:31:34 -0500 Received: from ozlabs.org ([203.11.71.1]:39345 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727494AbfAOLbd (ORCPT ); Tue, 15 Jan 2019 06:31:33 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 43f7TG5sg3z9sCh; Tue, 15 Jan 2019 22:31:30 +1100 (AEDT) From: Michael Ellerman To: Will Deacon , "Koenig\, Christian" Cc: Ard Biesheuvel , Michel =?utf-8?Q?D=C3=A4nz?= =?utf-8?Q?er?= , Linux Kernel Mailing List , Carsten Haitzler , David Airlie , dri-devel , "Huang\, Ray" , "Zhang\, Jerry" , linux-arm-kernel , Bernhard =?utf-8?Q?Rosenkr=C3=A4n?= =?utf-8?Q?zer?= , benh@kernel.crashing.org Subject: Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM In-Reply-To: <20190114193548.GB29600@fuggles.cambridge.arm.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> Date: Tue, 15 Jan 2019 22:31:29 +1100 Message-ID: <87a7k2yx66.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Will, Will Deacon writes: > [+ BenH and MPE] > > On Mon, Jan 14, 2019 at 07:21:08PM +0000, Koenig, Christian wrote: >> Am 14.01.19 um 20:13 schrieb Will Deacon: ... > >> > The Arm architecture (and others including Power afaiu) doesn't >> > guarantee coherency when memory is accessed using mismatched cacheability >> > attributes. ... > >> As far as I know Power doesn't really supports un-cached memory at all, >> except for a very very old and odd configuration with AGP. > > Hopefully Michael/Ben can elaborate here, but I was under the (possibly > mistaken) impression that mismatched attributes could cause a machine-check > on Power. That's what I've always been told, but I can't actually find where it's documented, I'll keep searching. But you're right that mixing cached / uncached is not really supported, and probably results in a machine check or worse. cheers