From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932284AbaDXQHB (ORCPT ); Thu, 24 Apr 2014 12:07:01 -0400 Received: from arroyo.ext.ti.com ([192.94.94.40]:47560 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758704AbaDXQG5 (ORCPT ); Thu, 24 Apr 2014 12:06:57 -0400 Message-ID: <53593689.3060801@ti.com> Date: Thu, 24 Apr 2014 11:06:33 -0500 From: Nishanth Menon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Darren Etheridge CC: Tony Lindgren , Santosh Shilimkar , Sricharan R , , Rajendra Nayak , Sekhar Nori , , Peter Ujfalusi , , Subject: Re: [PATCH V2 00/19] bus: omap_l3_noc: driver cleanups and support for DRA7/AM4372 References: <1397492726-17203-1-git-send-email-nm@ti.com> <1397767775-10965-1-git-send-email-nm@ti.com> <20140424155403.GA29229@ti.com> In-Reply-To: <20140424155403.GA29229@ti.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/24/2014 10:54 AM, Darren Etheridge wrote: > Nishanth, > > Nishanth Menon wrote on Thu [2014-Apr-17 15:49:16 -0500]: >> >> V2 introduces the following changes: >> - Additional bug fix detected during additional testing (all tests complete now). patch #12 >> - reordering of patches to order logical changes and reduce code churn. >> - interrupt handler split up and additional information now provided in log to aid debug when error occur >> - patches are marked where new (12,14,15,16). >> - DRA7 updated from master document for all DRA7 variants. >> >> This series cleansup omap_l3_noc driver and adds data to support DRA7 >> and AM437x SoCs. >> > This L3 noc driver patch series is working great for me and has already > flagged a very difficult to detect problem in a driver I am working on > with a DMA access to an invalid memory address on DRA7. Glad it was of use. All the more reason why this should be in upstream kernel and not just in "evil vendor" kernel. > > Tested-by: Darren Etheridge > Thanks. will pick this up for v3 post. -- Regards, Nishanth Menon