Re: [PATCH 2/2] dmaengine: pl330: event debug messages.

Re: [PATCH 2/2] dmaengine: pl330: event debug messages.

[Vinod Koul]

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 <hramrach@gmail.com>
> ---
>  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

Re: [PATCH 2/2] dmaengine: pl330: event debug messages.

[Michal Suchanek]

On 19 August 2015 at 18:41, Vinod Koul <vinod.koul@intel.com> wrote:
> 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 <hramrach@gmail.com>
>> ---
>>  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?

It's very verbose so I used the define for verbose debug since there
is one already.

>
>> +     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

It looks ugly indeed but I have no idea how to decode flag bitfield
into string in some more sensible way.

If you have an example of nice code doing this please share.

I did not even hit this one since the thread just stalls waiting for
device and does not fault in my case.

Thanks

Michal

Re: [PATCH 1/2] dmaengine: pl330: do not emit loop for 1 byte transfer.

[Vinod Koul]

On Thu, Jul 23, 2015 at 06:04:49PM +0200, Michal Suchanek wrote:
> When there is only one burst required do not emit loop instructions to
> loop exactly once. Emit just the body of the loop.

Applied, thanks

-- 
~Vinod

Re: [PATCH 1/2] dmaengine: pl330: do not emit loop for 1 byte transfer.

[Krzysztof Kozłowski]

2015-08-20 1:42 GMT+09:00 Vinod Koul <vinod.koul@intel.com>:
>
> On Thu, Jul 23, 2015 at 06:04:49PM +0200, Michal Suchanek wrote:
> > When there is only one burst required do not emit loop instructions to
> > loop exactly once. Emit just the body of the loop.
>
> Applied, thanks

Where is the patch? I can't find it on my subscribed mailing lists
(like dmaengine, LKML). It seems it is not present also in Google. The
same applies to 2/2. I see only replies (Vinod's and Michal's) but not
original email.

Best regards,
Krzysztof

Re: [PATCH 1/2] dmaengine: pl330: do not emit loop for 1 byte transfer.

[Vinod Koul]

On Thu, Aug 20, 2015 at 08:58:49AM +0900, Krzysztof Kozłowski wrote:
> 2015-08-20 1:42 GMT+09:00 Vinod Koul <vinod.koul@intel.com>:
> >
> > On Thu, Jul 23, 2015 at 06:04:49PM +0200, Michal Suchanek wrote:
> > > When there is only one burst required do not emit loop instructions to
> > > loop exactly once. Emit just the body of the loop.
> >
> > Applied, thanks
> 
> Where is the patch? I can't find it on my subscribed mailing lists
> (like dmaengine, LKML). It seems it is not present also in Google. The
> same applies to 2/2. I see only replies (Vinod's and Michal's) but not
> original email.

Now that you mentioned I did notice that too. Somehow the vger lists have
rejected this patch, althpugh it is addressed to both dmaengine and lkml
list

-- 
~Vinod