Received: by 10.223.176.46 with SMTP id f43csp122182wra; Tue, 23 Jan 2018 17:24:03 -0800 (PST) X-Google-Smtp-Source: AH8x224zxWka/XjyzJxXhbuF+bZbdQm3GGM1TnXLOmQdC30lkpajRVOJ1/S8n0AW/GTVd3xLEYtX X-Received: by 2002:a17:902:10b:: with SMTP id 11-v6mr6856874plb.336.1516757043820; Tue, 23 Jan 2018 17:24:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516757043; cv=none; d=google.com; s=arc-20160816; b=RsJwAKak49rAfdzpAThpxHh3xOXboajGPsIIWMjIb9k1RUZpnLDW3r1qCzm7WKkojl cEnsxHkS+d+yA0ZpEr2FovdiVruEJclR8lSL3zoSwyqLHScKn4c1gXB2bMz5gY2RlrDJ xeaUm2588Zbfu6Ijcq0SFh5sV5wlSHcdQNrZr2vRuX+icjDgQbaCX59u6Y0A0y7p0Fz+ GxG0dOQquV3/A/Ew9Wa6LgHn2NekZjKhnMA96wmG63IVCue0Rxdj+50BiZjiu+VvimGv VvfzqwZzH5oUU1TYk5q5ApD1q1eX8hiaNCiJkVqGExzSq6LrAKyA8Cy7u0+xuWmTgNF5 Zgiw== 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 :message-id:date:references:in-reply-to:subject:cc:to:from :arc-authentication-results; bh=+67C0ya7MGvR6DThLG6dLKxUbJZtoEHOnvbqg8uGSmo=; b=qVkGV12h/rerioZQJXn82i8PRAjp12+RSj2lbQICl/Tq7M7nwnkqtI2u20b3TR77JE YWjLvJ2+VFBoul6DvDY14M0ySGLh1oNY6tOvTCE7WNLJE9U6VQcohZzzr0/pyobjV/7o gA6y3pq1RrOY/d/P+B49ue2mUiDu3aLGO038lcBJMMUOvFN2jXSETwSsZ9TLxJSH7jI4 4VxlSYfrfADOpZf67ISmp0VrAUjR6SmA2jyrnPSFVA0uHr7cltxaDREayrqTQEyWpC/k JfkPibN5au5aH/84aKnnm5GMLS0zcm1vUj6tcDc0zLykvNO6i0kthvxYaCqCh8rXzWKD yckA== 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 w123si2035117pfd.95.2018.01.23.17.23.49; Tue, 23 Jan 2018 17:24:03 -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 S1752083AbeAXBXJ convert rfc822-to-8bit (ORCPT + 99 others); Tue, 23 Jan 2018 20:23:09 -0500 Received: from ozlabs.org ([103.22.144.67]:35883 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751921AbeAXBXH (ORCPT ); Tue, 23 Jan 2018 20:23:07 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 3zR6qY2jGsz9s7s; Wed, 24 Jan 2018 12:23:05 +1100 (AEDT) From: Michael Ellerman To: Jonathan =?utf-8?Q?Neusch=C3=A4fer?= Cc: Jonathan =?utf-8?Q?Neusch=C3=A4fer?= , linux-kernel@vger.kernel.org, Tom Lendacky , Brijesh Singh , devicetree@vger.kernel.org, Albert Herranz , linux-gpio@vger.kernel.org, Thomas Gleixner , Borislav Petkov , linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v2 1/6] resource: Extend the PPC32 reserved memory hack In-Reply-To: <20180123163739.2sxhzavghzgbjw4c@latitude> References: <20180122050411.32460-1-j.neuschaefer@gmx.net> <20180122050411.32460-2-j.neuschaefer@gmx.net> <871sigwx41.fsf@concordia.ellerman.id.au> <20180123163739.2sxhzavghzgbjw4c@latitude> Date: Wed, 24 Jan 2018 12:23:05 +1100 Message-ID: <87po60uk1y.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jonathan Neuschäfer writes: > On Tue, Jan 23, 2018 at 11:58:06PM +1100, Michael Ellerman wrote: >> Jonathan Neuschäfer writes: >> >> > On the Nintendo Wii, there are two ranges of physical memory, and MMIO >> > in between, but Linux on ppc32 doesn't support discontiguous memory. >> > Therefore a hack was introduced in commit c5df7f775148 ("powerpc: allow >> > ioremap within reserved memory regions") and commit de32400dd26e ("wii: >> > use both mem1 and mem2 as ram"): >> > >> > - Treat the area from the start of the first memory area (MEM1) to the >> > end of the second (MEM2) as one big memory area, but mark the part >> > that doesn't belong to MEM1 or MEM2 as reserved. >> > - Only on the Wii, allow ioremap to be used on reserved memory. >> > >> > This hack, however, doesn't account for the "resource"-based API in >> > kernel/resource.c, because __request_region performs its own checks. >> > >> > Extend the hack to kernel/resource.c, to allow more drivers to allocate >> > their MMIO regions on the Wii. >> >> Hi Jonathan, >> >> Sorry but I can't merge a hack like this in generic code. > > Makes sense. > >> Has anyone looked at adding proper discontig mem support to PPC32? > > I'm not aware of any such effort. > > Do you have any pointer on how to implement discontiguous memory > support? CONFIG_ARCH_SPARSEMEM_ENABLE seems relevant. I'm not really sure what the key impediment to it working is. You don't need to go all the way to SPARSEMEM, there is DISCONTIGMEM which IIUI is quite a bit simpler. I'd actually be interested to know what happens (ie. breaks) if you just add the two memblocks and leave the hole in between. Is it the generic code that breaks or is it something in the powerpc code? If it's the later maybe we can do a small fix/hack to work around that. >> Or can we punch a hole in the resource in the right place? Maybe from >> add_system_ram_resources() ? > > Not sure. add_system_ram_resources would need the original memblock > table, which is overwritten in wii_memory_fixups, if I read the code > correctly. Or it just needs to know where the "wii hole" is, and it can skip that region, that should be doable, but whether it actually works I'm not 100% sure. > If a proper solution doesn't take an overwhelming amount of work, I'd > prefer a proper solution. Thanks. cheers