LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Chunyan Zhang <zhang.chunyan@linaro.org>,
	Kaixu Xia <kaixu.xia@linaro.org>,
	norbert.schulz@intel.com, peter.lachner@intel.com
Subject: Re: [PATCH 4/5] coresight-stm: adding driver for CoreSight STM component
Date: Mon, 30 Mar 2015 09:48:47 -0600	[thread overview]
Message-ID: <CANLsYkzK_LX4OQJOUtcr0EksRUKPueNOXrw2C+qTJWov0sQPFA@mail.gmail.com> (raw)
In-Reply-To: <87bnjad1jb.fsf@ashishki-desk.ger.corp.intel.com>

On 30 March 2015 at 08:04, Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
> Mathieu Poirier <mathieu.poirier@linaro.org> writes:
>
>> +static int stm_send(void *addr, const void *data, u32 size)
>> +{
>> +     u32 len = size;
>> +
>> +     if (((unsigned long)data & 0x1) && (size >= 1)) {
>> +             writeb_relaxed(*(u8 *)data, addr);
>> +             data++;
>> +             size--;
>> +     }
>> +     if (((unsigned long)data & 0x2) && (size >= 2)) {
>> +             writew_relaxed(*(u16 *)data, addr);
>> +             data += 2;
>> +             size -= 2;
>> +     }
>> +
>> +     /* now we are 32bit aligned */
>> +     while (size >= 4) {
>> +             writel_relaxed(*(u32 *)data, addr);
>> +             data += 4;
>> +             size -= 4;
>> +     }
>> +
>> +     if (size >= 2) {
>> +             writew_relaxed(*(u16 *)data, addr);
>> +             data += 2;
>> +             size -= 2;
>> +     }
>> +     if (size >= 1) {
>> +             writeb_relaxed(*(u8 *)data, addr);
>> +             data++;
>> +             size--;
>> +     }
>> +
>> +     return len;
>> +}
>> +
>> +static int stm_trace_data(unsigned long ch_addr, u32 options,
>> +                       const void *data, u32 size)
>> +{
>> +     void *addr;
>> +
>> +     options &= ~STM_OPTION_TIMESTAMPED;
>> +     addr = (void *)(ch_addr | stm_channel_off(STM_PKT_TYPE_DATA, options));
>> +
>> +     return stm_send(addr, data, size);
>> +}
>> +
>> +static inline int stm_trace_hw(u32 options, u32 channel, u8 entity_id,
>> +                            const void *data, u32 size)
>> +{
>> +     int len = 0;
>> +     unsigned long ch_addr;
>> +     struct stm_drvdata *drvdata = stmdrvdata;
>> +
>> +
>> +     /* get the channel address */
>> +     ch_addr = (unsigned long)stm_channel_addr(drvdata, channel);
>> +
>> +     if (drvdata->write_64bit)
>> +             len = stm_trace_data_64bit(ch_addr, options, data, size);
>> +     else
>> +             /* send the payload data */
>> +             len = stm_trace_data(ch_addr, options, data, size);
>> +
>> +     return len;
>> +}
>
> As it looks from the above snippet, you're using a stream of DATA
> packets for user's payload. I also noticed that you use an ioctl to
> trigger timestamps.

Right, the ioctl() conveys user space intentions on that channel.
Options are kept and applied on every packet for as long as the
channel is open.

>
> Now, in the STP protocol there are, for example, marked data packets
> that can be used to mark beginning of a higher-level message,
> timestamped data packets that can be used to mean the same thing and
> FLAG packets to mark message boundaries.

Same on my side, I simply haven't included them yet.  I'll do so in my
next iteration.

>
> In my Intel TH code, I'm using D*TS packet for the beginning of a
> message (or "frame") and FLAG packet for the the end of a message.
>
> So my question is, is there any specific STP framing pattern that you
> use with Coresight STM or should we perhaps figure out a generic framing
> pattern and make it part of the stm class as well?

Now specific pattern... Sending a packet consists of MARK, DATA, FLAG.

>
> For example, we can replace stm's .write callback with something like
>
>     int (*packet)(struct stm_data *data,
>                   unsigned int type,    /* data, flag, trig etc */
>                   unsigned int options, /* timestamped, marked */
>                   u64 payload);
>
> and let the stm core do the "framing", which, then, will be common and
> consistent across different architectures/stm implementations.

I think the framing should be left to individual drivers.  It's only a
matter of time before we get a weird device that doesn't play well
with others, forcing to carry the ugliness in the STM core rather than
the driver.

And isn't carrying "options" redundant?  Using "container_of" on the
"data" field one can get back to the driver specific structure, which
is definitely a better place to keep that information.  I think the
general structure looks good right now, we simply need to find a way
to get rid of the ioctls.

Regarding the same "options", how did you plan on getting those from user space?

>
>> +static long stm_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
>> +{
>> +     u32 options;
>> +     struct stm_node *node = file->private_data;
>> +
>> +     switch (cmd) {
>> +     case STM_IOCTL_SET_OPTIONS:
>> +             if (copy_from_user(&options, (void __user *)arg, sizeof(u32)))
>> +                     return -EFAULT;
>> +
>> +             options &= (STM_OPTION_TIMESTAMPED | STM_OPTION_GUARANTEED);
>> +             node->options = options;
>> +             break;
>> +     case STM_IOCTL_GET_OPTIONS:
>> +             options = node->options;
>> +             if (copy_to_user((void __user *)arg, &options, sizeof(options)))
>> +                     return -EFAULT;
>> +             break;
>> +     default:
>> +             return -EINVAL;
>> +     };
>> +
>> +     return 0;
>> +}
>
> That way, we also won't need private ioctl()s, or at least, not for this
> reason.
>
> How do you feel about this?
>
> Regards,
> --
> Alex

  reply	other threads:[~2015-03-30 15:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-27 23:04 [PATCH 0/5] coresight: next Mathieu Poirier
2015-02-27 23:04 ` [PATCH 1/5] coresight: making cpu index lookup arm64 compliant Mathieu Poirier
2015-02-27 23:04 ` [PATCH 2/5] coresight: fixing compilation warnings picked up by 64bit compiler Mathieu Poirier
2015-02-27 23:04 ` [PATCH 3/5] coresight: Adding coresight support for arm64 architecture Mathieu Poirier
2015-02-27 23:04 ` [PATCH 4/5] coresight-stm: adding driver for CoreSight STM component Mathieu Poirier
2015-03-07 12:27   ` Alexander Shishkin
2015-03-30 14:04   ` Alexander Shishkin
2015-03-30 15:48     ` Mathieu Poirier [this message]
2015-03-31 15:04       ` Alexander Shishkin
2015-04-01 14:27         ` Mathieu Poirier
2015-04-01 14:28           ` Mathieu Poirier
2015-02-27 23:04 ` [PATCH 5/5] coresight-stm: Bindings for System Trace Macrocell Mathieu Poirier
2015-03-19 22:09 ` [PATCH 0/5] coresight: next Mathieu Poirier
2015-03-19 22:24   ` Greg KH

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=CANLsYkzK_LX4OQJOUtcr0EksRUKPueNOXrw2C+qTJWov0sQPFA@mail.gmail.com \
    --to=mathieu.poirier@linaro.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kaixu.xia@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=norbert.schulz@intel.com \
    --cc=peter.lachner@intel.com \
    --cc=zhang.chunyan@linaro.org \
    --subject='Re: [PATCH 4/5] coresight-stm: adding driver for CoreSight STM component' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).