Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753585Ab1FJDYN (ORCPT ); Thu, 9 Jun 2011 23:24:13 -0400 Received: from mail-fx0-f46.google.com ([209.85.161.46]:56645 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753262Ab1FJDYK (ORCPT ); Thu, 9 Jun 2011 23:24:10 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=OvfKKw+jiI0C91DBjLgdn+ncnkJ7DlGlJBYFqwbYu+dE1ohcF9hYCvUv1yh7eZ+GK1 YzvFwIFtUrA/0jHA9NYFOHYXZXwxoib+AsnSrHQmJnSswoG72u9njQr6EZQBElhK0t3P CUdwQKVrxww/35B5t3qAEA4PyYASFIi0RwwyU= MIME-Version: 1.0 In-Reply-To: <1307662948.2874.293.camel@pasglop> References: <1307482573-25440-1-git-send-email-ericvh@gmail.com> <1307494057.2874.212.camel@pasglop> <1307662948.2874.293.camel@pasglop> From: Eric Van Hensbergen Date: Thu, 9 Jun 2011 22:23:20 -0500 Message-ID: Subject: Re: [PATCH] [RFC][V3] bluegene: use MMU feature flag to conditionalize L1 writethrough code To: Benjamin Herrenschmidt Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, bg-linux@lists.anl-external.org, Josh Boyer Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1398 Lines: 35 On Thu, Jun 9, 2011 at 6:42 PM, Benjamin Herrenschmidt wrote: > On Thu, 2011-06-09 at 09:58 -0500, Eric Van Hensbergen wrote: >> On Tue, Jun 7, 2011 at 7:47 PM, Benjamin Herrenschmidt >> wrote: >> > BTW. Care to explain to me why you have U2 -both- in the arguments to >> > tlbwe and in MMUCR ? That doesn't look right to me... which one is used >> > where and when ? >> > >> >> My reading of the databook is that U2SWOAE is an enable bit that lets the U2 >> storage attribute control the behavior. > > You mean the MMUCR variant ? > Yeah, the MMCR variant acts as an enable/mask for the U2 storage attribute. > > Well, point is, parsing the device-tree from early boot asm is nasty, > unless you start extending the header but that sucks. That's why I'm > thinking it might be a good idea to look at what it takes to "convert" > the initial entry instead, even if that involves some cache flushing > (provided that's workable at all of course). > ah, okay. I guess if its happening before the secondary cpus come up then that should be workable. I guess it doesn't hurt to try. -eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/