Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752771AbbHSQjK (ORCPT ); Wed, 19 Aug 2015 12:39:10 -0400 Received: from mga09.intel.com ([134.134.136.24]:33421 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752110AbbHSQjI (ORCPT ); Wed, 19 Aug 2015 12:39:08 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,710,1432623600"; d="scan'208";a="787167632" Date: Wed, 19 Aug 2015 22:11:15 +0530 From: Vinod Koul To: Michal Suchanek Cc: Dan Williams , dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] dmaengine: pl330: event debug messages. Message-ID: <20150819164115.GG13546@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3601 Lines: 115 On Tue, Jul 28, 2015 at 10:49:33AM +0000, Michal Suchanek wrote: > In pl330.c is a define which enables very verbose decoding of genereted > programs. > > Also add decoding of thread abort states and signalled events. > > Signed-off-by: Michal Suchanek > --- > drivers/dma/pl330.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 53 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c > index 257e0d9..9b02936 100644 > --- a/drivers/dma/pl330.c > +++ b/drivers/dma/pl330.c > @@ -1318,6 +1318,10 @@ static int _setup_req(unsigned dry_run, struct pl330_thread *thrd, > u8 *buf = req->mc_cpu; > int off = 0; > > + if (!dry_run) > + dev_dbg(thrd->dmac->ddma.dev, > + "setting up request on thread %i", thrd->id); > + > PL330_DBGMC_START(req->mc_bus); > > /* DMAMOV CCR, ccr */ > @@ -1545,6 +1549,20 @@ static int pl330_update(struct pl330_dmac *pl330) > pl330->dmac_tbd.reset_mngr = true; > else > pl330->dmac_tbd.reset_mngr = false; > +#ifdef PL330_DEBUG_MCGEN do we need this here? > + if (val) { > + val = readl(regs + FTM); > + dev_info(pl330->ddma.dev, > + "Manager thread fault %s%s%s%s%s%s", > + (val & (1 << 30)) ? "dbg iface" : "sys mem", > + (val & (1 << 16)) ? " fetch error" : "", > + (val & (1 << 5)) ? " event sec error" : "", > + (val & (1 << 4)) ? " channel sec error" : "", > + (val & (1 << 1)) ? " invalid operand" : "", > + (val & (1 << 0)) ? " invalid instruction" : "" > + ); > + } > +#endif > > val = readl(regs + FSC) & ((1 << pl330->pcfg.num_chan) - 1); > pl330->dmac_tbd.reset_chan |= val; > @@ -1552,10 +1570,41 @@ static int pl330_update(struct pl330_dmac *pl330) > int i = 0; > while (i < pl330->pcfg.num_chan) { > if (val & (1 << i)) { > + u32 fault = readl(regs + FTC(i)); > +#ifdef PL330_DEBUG_MCGEN > + dev_info(pl330->ddma.dev, > + "DMA thread fault" > + "%s%s%s%s%s%s%s%s%s%s%s%s", This break grep! also looks very ugly and should be a dev_debug rather > + (fault & (1 << 31)) ? > + " lockup" : "", > + (fault & (1 << 30)) ? > + " dbg iface" : " sys mem", > + (fault & (1 << 18)) ? > + " read error" : "", > + (fault & (1 << 17)) ? > + " write error" : "", > + (fault & (1 << 16)) ? > + " instr fetch error" : "", > + (fault & (1 << 12)) ? > + " mfifo over/underflow" : "", > + (fault & (1 << 7)) ? > + " data sec error" : "", > + (fault & (1 << 6)) ? > + " periph sec error" : "", > + (fault & (1 << 5)) ? > + " event sec error" : "", > + (fault & (1 << 4)) ? > + " channel sec error" : "", > + (fault & (1 << 1)) ? > + " invalid operand" : "", > + (fault & (1 << 0)) ? > + " invalid instruction" : "" > + ); > +#endif > dev_info(pl330->ddma.dev, > "Reset Channel-%d\t CS-%x FTC-%x\n", > i, readl(regs + CS(i)), > - readl(regs + FTC(i))); > + fault); > _stop(&pl330->channels[i]); > } > i++; > @@ -1587,6 +1636,9 @@ static int pl330_update(struct pl330_dmac *pl330) > > id = pl330->events[ev]; > > + dev_dbg(pl330->ddma.dev, > + "event signalled on thread id %i", id); > + > thrd = &pl330->channels[id]; > > active = thrd->req_running; > -- > 2.1.4 > -- ~Vinod -- 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/