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;
From:   Vineet Gupta <Vineet.Gupta1@synopsys.com>
To:     Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>,
        Vineet Gupta <vineetg76@gmail.com>,
        Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>,
        "linux-snps-arc@lists.infradead.org" 
        <linux-snps-arc@lists.infradead.org>,
        Vineet Gupta <Vineet.Gupta1@synopsys.com>
CC:     Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 0/6] ARC: merge HAPS-HS with nSIM-HS configs
Thread-Topic: [RFC 0/6] ARC: merge HAPS-HS with nSIM-HS configs
Thread-Index: AQHVha3ZXHlIwwLIZE2VERfslIAXqqdgvduAgAZA5wCAAABinQ==
Date:   Tue, 22 Oct 2019 18:24:26 +0000
Message-ID: <DM6PR12MB40897388883F4441C65E60B4B6680@DM6PR12MB4089.namprd12.prod.outlook.com>
References: <20191018121545.8907-1-Eugeniy.Paltsev@synopsys.com>,<8fd4f94b-c0e5-ed2c-ede3-5c4e77a5a0e4@gmail.com>,<BY5PR12MB4034AE62AA5C70794526A981DE680@BY5PR12MB4034.namprd12.prod.outlook.com>
In-Reply-To: <BY5PR12MB4034AE62AA5C70794526A981DE680@BY5PR12MB4034.namprd12.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: synopsys.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fba49c46-c846-4a8e-e515-08d7571d11ed
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2019 18:24:26.1212
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c33c9f88-1eb7-4099-9700-16013fd9e8aa
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: UoiT6RjsPrFW8tXldIMeZJFCMP1N7EPJVf0oefE2PiKnXK83CjZSUWDLDA0V4RL52VOm4y52o8/bNDGSNjMMCg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB2763
X-OriginatorOrg: synopsys.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Ok but this if off topic and not directly related to patches - or am I miss=
ing something.

Indeed if we run UP only for nsim we should add pseudo SMP and also a true =
SMP.

For uClibc-ng regression, it doesn't matter what they use and not for us to=
 decide anyways - we just need to tell them (or point to wiki etc) that sta=
rting with 5.x kernel,any nsim uart config needs to change of they are usin=
g the defconfigs.

-Vineet

________________________________________
From: Eugeniy Paltsev <paltsev@synopsys.com>
Sent: Tuesday, October 22, 2019 11:18 AM
To: Vineet Gupta; Eugeniy Paltsev; linux-snps-arc@lists.infradead.org; Vine=
et Gupta
Cc: Alexey Brodkin; linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/6] ARC: merge HAPS-HS with nSIM-HS configs

Btw, about nSIM regression runs:
We are using UP configuration for all nSIM runs and I propose to use pseudo=
-SMP  configuration (SMP configuration with only one CPU online) instead as=
 our main target are SMP systems.

So -
run our verification jobs on both UP and pseudo-SMP nSIM
run uClibc-ng regression on pseudo-SMP only

 Any objections / thoughts?
---
 Eugeniy Paltsev


________________________________________
From: Vineet Gupta <vineetg76@gmail.com>
Sent: Friday, October 18, 2019 21:48
To: Eugeniy Paltsev; linux-snps-arc@lists.infradead.org; Vineet Gupta
Cc: Alexey Brodkin; linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/6] ARC: merge HAPS-HS with nSIM-HS configs

On 10/18/19 5:15 AM, Eugeniy Paltsev wrote:
> Starting from nSIM 2019.06 is possible to use DW UART
> instead of ARC UART. That allows us to merge
> "nsim_hs" with "haps_hs" and "nsim_hs_smp" with "haps_hs_smp"
> mith some minor changes.
>
> We eliminate nsim_hs_defconfig and nsim_hs_smp_defconfig
> and leave haps_hs_defconfig and haps_hs_smp_defconfig
> which can be used on HAPS / nSIM / ZEBU / QEMU platforms
> without additionall changes in Linux kernel.

Thx for doing this, I was planning to do this myself.

But remember that doing this will disturb existing nsim setups
- Our internal linux/gnu regression jobs one of which tracks my for-curr an=
d will
  fail immediately
- uClibc-ng maintainer who also seems to use nsim AFAIK for regression runs

So we need to notify parties involves (and it would be best that we align t=
his to
a kernel release which anyways will be next one.

Also go thru the github wiki pages and wherever applicable please add the c=
onfig
info for nsim (keep the old settings there for reference as well)

Thx,
-Vineet