mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lu Baolu <baolu.lu@linux.intel.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 04/10] usb: dbc: add debug buffer
Date: Fri, 19 Feb 2016 14:35:06 +0800	[thread overview]
Message-ID: <56C6B79A.2040108@linux.intel.com> (raw)
In-Reply-To: <56C5AE61.1020503@linux.intel.com>



On 02/18/2016 07:43 PM, Mathias Nyman wrote:
> On 26.01.2016 14:58, Lu Baolu wrote:
>> "printk" is not suitable for dbc debugging especially when console
>> is in usage. This patch adds a debug buffer in dbc driver and puts
>> the debug messages in this local buffer. The debug buffer could be
>> dumped whenever the console is not in use. This part of code will
>> not be visible unless DBC_DEBUG is defined.
>>
>> Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
>> ---
>>   drivers/usb/early/xhci-dbc.c | 62 ++++++++++++++++++++++++++++++++++++++++++--
>>   1 file changed, 60 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
>> index 41ce116..6855048 100644
>> --- a/drivers/usb/early/xhci-dbc.c
>> +++ b/drivers/usb/early/xhci-dbc.c
>> @@ -32,8 +32,64 @@ static struct xdbc_state xdbc_stat;
>>   static struct xdbc_state *xdbcp = &xdbc_stat;
>>
>>   #ifdef DBC_DEBUG
>> -/* place holder */
>> -#define    xdbc_trace    printk
>> +#define    XDBC_DEBUG_BUF_SIZE    (PAGE_SIZE * 32)
>
> Does it really need to be this huge? minimum 4096 * 32 ~ 128k
> The kernel ring  buffer is about the same size (16k - 256k)

This debug buffer is only used when DBC_DEBUG is defined.

128k is a little large. I will change it to 16k.

>
>> +#define    MSG_MAX_LINE        128
>
> with 128 characters per line this would fit ~1000 lines
>
>> +static char xdbc_debug_buf[XDBC_DEBUG_BUF_SIZE];
>> +static void xdbc_trace(const char *fmt, ...)
>> +{
>> +    int i, size;
>> +    va_list args;
>> +    static int pos;
>> +    char temp_buf[MSG_MAX_LINE];
>> +
>> +    if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
>> +        return;
>> +
>> +    memset(temp_buf, 0, MSG_MAX_LINE);
>> +    va_start(args, fmt);
>> +    vsnprintf(temp_buf, MSG_MAX_LINE - 1, fmt, args);
>> +    va_end(args);
>> +
>> +    i = 0;
>> +    size = strlen(temp_buf);
>> +    while (i < size) {
>> +        xdbc_debug_buf[pos] = temp_buf[i];
>> +        pos++;
>> +        i++;
>> +
>> +        if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
>> +            break;
>> +    }
>
> how about something like:
>
> size = min(XDBC_DEBUG_BUF_SIZE - pos, size)
> memcpy(xdbc_debug_buf + pos, temp_buf, size)
> pos += size;
>
> (might need some "-1" and off by one checking..)

Yes. This looks better.

>
>> +}
>> +
>> +static void xdbc_dump_debug_buffer(void)
>> +{
>> +    int index = 0;
>> +    int count = 0;
>> +    char dump_buf[MSG_MAX_LINE];
>> +
>> +    xdbc_trace("The end of DbC trace buffer\n");
>> +    pr_notice("DBC debug buffer:\n");
>> +    memset(dump_buf, 0, MSG_MAX_LINE);
>> +
>> +    while (index < XDBC_DEBUG_BUF_SIZE) {
>> +        if (!xdbc_debug_buf[index])
>> +            break;
>> +
>> +        if (xdbc_debug_buf[index] == '\n' ||
>> +                count >= MSG_MAX_LINE - 1) {
>> +            pr_notice("DBC: @%08x %s\n", index, dump_buf);
>
> Is showing the he index (position in debug buffer) useful here?

It helps to check the debug log especially when it shows the hardware
registers or memory block.

>
>
>> +            memset(dump_buf, 0, MSG_MAX_LINE);
>> +            count = 0;
>> +        } else {
>> +            dump_buf[count] = xdbc_debug_buf[index];
>> +            count++;
>> +        }
>> +
>> +        index++;
>> +    }
>
> So we have one huge buffer that xdbc keeps on filling as the initialization progresses.
> It is never emptied, or overwritten (circular).
> When dumped it always dumps the whole thing, copying one character
> at a time.
>
> As this is only used for debugging during xdbc development/debugging, and never enabled
> even if xdbc early printk is used, I don't think optimization really matters.

Yes, it's only a helper for the persons who develop and debug this driver.

>
> Perhaps take a look if we really need PAGE_SIZE * 32 bytes, is xdbc driver even nearly
> writing that much debug data.

I will reduce the debug buffer size.

>  
> -Mathias
>
>

Thanks for your time.

Regards,
-Baolu

  reply	other threads:[~2016-02-19  6:35 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-26 12:58 [PATCH v7 00/10] usb: early: add support for early printk through USB3 debug port Lu Baolu
2016-01-26 12:58 ` [PATCH v7 01/10] x86: fixmap: add permanent fixmap for xhci " Lu Baolu
2016-01-26 12:58 ` [PATCH v7 02/10] usb: dbc: probe and setup xhci debug capability Lu Baolu
2016-02-16 14:19   ` Mathias Nyman
2016-02-17  8:45     ` Lu Baolu
2016-01-26 12:58 ` [PATCH v7 03/10] usb: dbc: add support for Intel xHCI dbc quirk Lu Baolu
2016-01-26 12:58 ` [PATCH v7 04/10] usb: dbc: add debug buffer Lu Baolu
2016-02-18 11:43   ` Mathias Nyman
2016-02-19  6:35     ` Lu Baolu [this message]
2016-01-26 12:58 ` [PATCH v7 05/10] usb: dbc: add bulk out and bulk in interfaces Lu Baolu
2016-02-18 13:32   ` Mathias Nyman
2016-02-19  7:09     ` Lu Baolu
2016-01-26 12:58 ` [PATCH v7 06/10] usb: dbc: handle dbc-configured exit Lu Baolu
2016-01-26 12:58 ` [PATCH v7 07/10] usb: dbc: handle endpoint stall Lu Baolu
2016-03-02 12:58   ` Mathias Nyman
2016-03-02 12:58     ` Felipe Balbi
2016-03-03  6:12       ` Lu Baolu
2016-03-03  6:00     ` Lu Baolu
2016-01-26 12:58 ` [PATCH v7 08/10] x86: early_printk: add USB3 debug port earlyprintk support Lu Baolu
2016-01-26 12:58 ` [PATCH v7 09/10] usb: dbc: add handshake between debug target and host Lu Baolu
2016-01-26 12:58 ` [PATCH v7 10/10] usb: doc: add document for xHCI DbC driver Lu Baolu
2016-02-02 14:34 ` [PATCH v7 00/10] usb: early: add support for early printk through USB3 debug port Lu Baolu
2016-02-03 21:43   ` Greg Kroah-Hartman
2016-02-03 23:52     ` Lu Baolu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56C6B79A.2040108@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome