From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 20 Dec 2014 02:40:01 +0100 (CET) Received: from mailapp01.imgtec.com ([195.59.15.196]:25276 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S27009080AbaLTBkACMSW- (ORCPT ); Sat, 20 Dec 2014 02:40:00 +0100 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id B3B8B841F52A3; Sat, 20 Dec 2014 01:39:53 +0000 (GMT) Received: from BAMAIL02.ba.imgtec.org (10.20.40.28) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 20 Dec 2014 01:39:54 +0000 Received: from [192.168.65.146] (192.168.65.146) by bamail02.ba.imgtec.org (10.20.40.28) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 19 Dec 2014 17:39:50 -0800 Message-ID: <5494D366.6060400@imgtec.com> Date: Fri, 19 Dec 2014 17:39:50 -0800 From: Leonid Yegoshin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: David Daney CC: , , David Daney Subject: Re: [PATCH] MIPS: Fix C0_Pagegrain[IEC] support. References: <1419038123-30270-1-git-send-email-ddaney.cavm@gmail.com> <5494CF23.1080606@imgtec.com> <5494D04F.4030701@gmail.com> In-Reply-To: <5494D04F.4030701@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.65.146] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 44864 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Leonid.Yegoshin@imgtec.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On 12/19/2014 05:26 PM, David Daney wrote: > On 12/19/2014 05:21 PM, Leonid Yegoshin wrote: >> On 12/19/2014 05:15 PM, David Daney wrote: >>> From: David Daney >>> >>> If we are generating TLB exception expecting separate vectors, we must >>> enable the feature. >>> >>> Cc: Leonid Yegoshin >>> Signed-off-by: David Daney >>> --- >>> >>> Very lightly tested, but it seems to make my XI and RI tests work on >>> OCTEON II CPUs, which have the C0_Pagegrain[IEC] bit. >>> >>> arch/mips/mm/tlb-r4k.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c >>> index e90b2e8..30639a6 100644 >>> --- a/arch/mips/mm/tlb-r4k.c >>> +++ b/arch/mips/mm/tlb-r4k.c >>> @@ -489,6 +489,8 @@ static void r4k_tlb_configure(void) >>> #ifdef CONFIG_64BIT >>> pg |= PG_ELPA; >>> #endif >>> + if (cpu_has_rixiex) >>> + pg |= PG_IEC; >>> write_c0_pagegrain(pg); >>> } >> David, I think it is still better to use set_c0_pagegrain() because >> PageGrain has a lot of RW bits now and clear all of them may be not >> good. > > IMHO all the code that sets PageGrain should be in this function. We > should calculate all the bits here that should be set, and set them. > > The whole reason that we have this mess, is that we were setting the > bits at different code sites, and clobbering them in others. > > If *all* the PageGrain logic is in one place, we won't have this problem. > > If you think this patch is incorrect, then we should revert the other > two and take our time to carefully do something that is correct. > > David Daney > No, I don't see this patch as incorrect. It is just about coding assumptions but I don't think it is serious, so you variant is OK. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailapp01.imgtec.com ([195.59.15.196]:25276 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S27009080AbaLTBkACMSW- (ORCPT ); Sat, 20 Dec 2014 02:40:00 +0100 Message-ID: <5494D366.6060400@imgtec.com> Date: Fri, 19 Dec 2014 17:39:50 -0800 From: Leonid Yegoshin MIME-Version: 1.0 Subject: Re: [PATCH] MIPS: Fix C0_Pagegrain[IEC] support. References: <1419038123-30270-1-git-send-email-ddaney.cavm@gmail.com> <5494CF23.1080606@imgtec.com> <5494D04F.4030701@gmail.com> In-Reply-To: <5494D04F.4030701@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: David Daney Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, David Daney Message-ID: <20141220013950.sUEMQGVRhoVQxzvxFMKyE7MWpn37Ziv11QIvsTtElW0@z> On 12/19/2014 05:26 PM, David Daney wrote: > On 12/19/2014 05:21 PM, Leonid Yegoshin wrote: >> On 12/19/2014 05:15 PM, David Daney wrote: >>> From: David Daney >>> >>> If we are generating TLB exception expecting separate vectors, we must >>> enable the feature. >>> >>> Cc: Leonid Yegoshin >>> Signed-off-by: David Daney >>> --- >>> >>> Very lightly tested, but it seems to make my XI and RI tests work on >>> OCTEON II CPUs, which have the C0_Pagegrain[IEC] bit. >>> >>> arch/mips/mm/tlb-r4k.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c >>> index e90b2e8..30639a6 100644 >>> --- a/arch/mips/mm/tlb-r4k.c >>> +++ b/arch/mips/mm/tlb-r4k.c >>> @@ -489,6 +489,8 @@ static void r4k_tlb_configure(void) >>> #ifdef CONFIG_64BIT >>> pg |= PG_ELPA; >>> #endif >>> + if (cpu_has_rixiex) >>> + pg |= PG_IEC; >>> write_c0_pagegrain(pg); >>> } >> David, I think it is still better to use set_c0_pagegrain() because >> PageGrain has a lot of RW bits now and clear all of them may be not >> good. > > IMHO all the code that sets PageGrain should be in this function. We > should calculate all the bits here that should be set, and set them. > > The whole reason that we have this mess, is that we were setting the > bits at different code sites, and clobbering them in others. > > If *all* the PageGrain logic is in one place, we won't have this problem. > > If you think this patch is incorrect, then we should revert the other > two and take our time to carefully do something that is correct. > > David Daney > No, I don't see this patch as incorrect. It is just about coding assumptions but I don't think it is serious, so you variant is OK.