From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
To: Chunyan Zhang <zhang.chunyan@linaro.org>, mathieu.poirier@linaro.org
Cc: robh@kernel.org, broonie@kernel.org, pratikp@codeaurora.org,
nicolas.guion@st.com, corbet@lwn.net, mark.rutland@arm.com,
mike.leach@arm.com, tor@ti.com, al.grant@arm.com,
zhang.lyra@gmail.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs
Date: Fri, 05 Feb 2016 14:52:10 +0200 [thread overview]
Message-ID: <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com> (raw)
In-Reply-To: <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org>
Chunyan Zhang <zhang.chunyan@linaro.org> writes:
> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Some architecture like ARM assign masterIDs statically at the HW design
> phase, making masterID manipulation in the generic STM core irrelevant.
>
> This patch adds a new 'mstatic' flag to struct stm_data that tells the
> core that this specific STM device doesn't need explicit masterID
> management.
So why do we need this patch? If your STM only has master 42 allocated
for software sources, simply set sw_start = 42, sw_end = 42 and you're
good to go, software will have exactly one channel to choose from. See
also the comment from <linux/stm.h>:
* @sw_start: first STP master available to software
* @sw_end: last STP master available to software
particularly the "available to software" part. Any other kinds of
masters the STM class code doesn't care about (yet).
> In the core sw_start/end of masterID are set to '1',
> i.e there is only one masterID to deal with.
This is also a completely arbitrary and unnecessary requirement. Again,
you can set both to 42 and it will still work.
> Also this patch depends on [1], so that the number of masterID
> is '1' too.
>
> Finally the lower and upper bound for masterIDs as presented
> in ($SYSFS)/class/stm/XYZ.stm/masters and
> ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
> are set to '-1'. That way users can't confuse them with
> architecture where masterID management is required (where any
> other value would be valid).
Why is this a good idea? Having the actual master there will allow
software to know what it is and also tell the decoding side what it is
(assuming you have more than one source in the STP stream, it might not
be easy to figure out, unless you know it in advance).
I don't see how one master statically assigned to software sources is
different from two masters or 32 masters. And I don't see any benefit of
hiding the master id from userspace. Am I missing something?
Regards,
--
Alex
next prev parent reply other threads:[~2016-02-05 12:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-03 8:15 [PATCH V2 0/6] Introduce CoreSight STM support Chunyan Zhang
2016-02-03 8:15 ` [PATCH V2 1/6] stm class: Add ioctl get_options interface Chunyan Zhang
2016-02-05 12:55 ` Alexander Shishkin
2016-02-03 8:15 ` [PATCH V2 2/6] stm class: adds a loop to extract the first valid STM device name Chunyan Zhang
2016-02-03 10:05 ` [PATCH] stm class: fix semicolon.cocci warnings kbuild test robot
2016-02-03 10:05 ` [PATCH V2 2/6] stm class: adds a loop to extract the first valid STM device name kbuild test robot
2016-02-04 8:56 ` Chunyan Zhang
2016-02-04 17:30 ` Alexander Shishkin
2016-02-05 3:18 ` Chunyan Zhang
2016-02-03 8:15 ` [PATCH V2 3/6] stm class: provision for statically assigned masterIDs Chunyan Zhang
2016-02-05 12:52 ` Alexander Shishkin [this message]
2016-02-05 16:31 ` Mike Leach
2016-02-08 10:52 ` Alexander Shishkin
2016-02-05 18:08 ` Mathieu Poirier
2016-02-08 13:26 ` Alexander Shishkin
2016-02-08 17:05 ` Mathieu Poirier
2016-02-08 17:44 ` Al Grant
2016-02-09 17:06 ` Mathieu Poirier
2016-02-12 15:54 ` Alexander Shishkin
2016-02-12 16:27 ` Alexander Shishkin
2016-02-12 20:33 ` Mathieu Poirier
2016-02-22 18:01 ` Mathieu Poirier
2016-02-03 8:15 ` [PATCH V2 4/6] Documentations: Add explanations of the case for non-configurable masters Chunyan Zhang
2016-02-03 8:15 ` [PATCH V2 5/6] coresight-stm: Bindings for System Trace Macrocell Chunyan Zhang
2016-02-03 8:15 ` [PATCH V2 6/6] coresight-stm: adding driver for CoreSight STM component Chunyan Zhang
2016-02-05 13:06 ` Alexander Shishkin
2016-02-05 14:30 ` Arnd Bergmann
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=87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com \
--to=alexander.shishkin@linux.intel.com \
--cc=al.grant@arm.com \
--cc=broonie@kernel.org \
--cc=corbet@lwn.net \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.poirier@linaro.org \
--cc=mike.leach@arm.com \
--cc=nicolas.guion@st.com \
--cc=pratikp@codeaurora.org \
--cc=robh@kernel.org \
--cc=tor@ti.com \
--cc=zhang.chunyan@linaro.org \
--cc=zhang.lyra@gmail.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
all inboxes | Powered by JetHome®