From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 04/11] iommu/arm-smmu: Introduce automatic stream-id-masking
Date: Wed, 22 Jan 2014 15:26:22 +0000 [thread overview]
Message-ID: <20140122152622.GD14108@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <1389876263-25759-5-git-send-email-andreas.herrmann@calxeda.com>
Hi Andreas,
This patch always requires some extra brain cycles when reviewing!
On Thu, Jan 16, 2014 at 12:44:16PM +0000, Andreas Herrmann wrote:
> Try to determine a mask that can be used for all StreamIDs of a master
> device. This allows to use just one SMR group instead of
> number-of-streamids SMR groups for a master device.
>
> Changelog:
You can put the change log and notes after the '---' so they don't appear in
the commit log, although the commit message could probably use a brief
description of your algorithm.
> * Sorting of stream IDs (to make usage of S2CR independend of sequence of
> stream IDs in DT)
> - intentionally not implemented
> - code does not rely on sorting
> - in fact sorting might make things worse with this simple
> implementation
> + Example: master with stream IDs 4, 5, 6, 0xe, 0xf requires 3
> SMRs when IDs are specified in this sorted order (one to map 4,
> 5, one to map 6, one to map 0xe, 0xf) but just 2 SMRs when
> specified as 4, 5, 0xe, 0xf, 6 (one to map 4, 5, 0xe, 0xf and
> one SMR to map 6)
> - thus by modifying the DT information you can affect the number of
> S2CRs required for stream matching
> => I'd say "use common sense" when specifying stream IDs for a master
> device in DT.
Then we probably want a comment in the driver helping people work out what
the best ordering is.
> @@ -1025,10 +1030,109 @@ static void arm_smmu_domain_destroy(struct iommu_domain *domain)
> kfree(smmu_domain);
> }
>
> +static int determine_smr_mask(struct arm_smmu_device *smmu,
> + struct arm_smmu_master *master,
> + struct arm_smmu_smr *smr, int start, int order)
> +{
> + u16 i, zero_bits_mask, one_bits_mask, const_mask;
> + int nr;
> +
> + nr = 1 << order;
> +
> + if (nr == 1) {
> + /* no mask, use streamid to match and be done with it */
> + smr->mask = 0;
> + smr->id = master->streamids[start];
> + return 0;
> + }
> +
> + zero_bits_mask = 0;
> + one_bits_mask = 0xffff;
> + for (i = start; i < start + nr; i++) {
> + zero_bits_mask |= master->streamids[i]; /* const 0 bits */
> + one_bits_mask &= master->streamids[i]; /* const 1 bits */
> + }
> + zero_bits_mask = ~zero_bits_mask;
> +
> + /* bits having constant values (either 0 or 1) */
> + const_mask = zero_bits_mask | one_bits_mask;
> +
> + i = hweight16(~const_mask);
> + if ((1 << i) == nr) {
> + smr->mask = ~const_mask;
> + smr->id = one_bits_mask;
This part always confuses me. Why do we check (1 << i) against nr? In fact,
in your example where we have SIDs {4,5,e,f,6}, then we'll call this
initially with start = 0, order = 2 and try to allocate an smr for
{4,5,e,f}. That will succeed with mask 1011b and id 0100b, but the mask has
a hamming weight of 3, which is != nr (2).
Where am I getting this wrong?
I also still need to convince myself that we can't end up generating smrs
which match the same SID. Is that what your check above is trying to handle?
> +static int determine_smr_mapping(struct arm_smmu_device *smmu,
> + struct arm_smmu_master *master,
> + struct arm_smmu_smr *smrs, int max_smrs)
> +{
> + int nr_sid, nr, i, bit, start;
> +
> + /*
> + * This function is called only once -- when a master is added
> + * to a domain. If master->num_s2crs != 0 then this master
> + * was already added to a domain.
> + */
> + BUG_ON(master->num_s2crs);
I think I'd rather WARN and return -EINVAL. We needn't kill the kernel for
this.
> +
> + start = nr = 0;
> + nr_sid = master->num_streamids;
> + do {
> + /*
> + * largest power-of-2 number of streamids for which to
> + * determine a usable mask/id pair for stream matching
> + */
> + bit = fls(nr_sid);
If you use __fls...
> + if (!bit)
> + return 0;
> +
> + /*
> + * iterate over power-of-2 numbers to determine
> + * largest possible mask/id pair for stream matching
> + * of next 2**i streamids
> + */
> + for (i = bit - 1; i >= 0; i--) {
... then you don't need this -1.
> + if(!determine_smr_mask(smmu, master,
Cosmetic: space after 'if'.
> /* It worked! Now, poke the actual hardware */
> - for (i = 0; i < master->num_streamids; ++i) {
> + for (i = 0; i < master->num_s2crs; ++i) {
> u32 reg = SMR_VALID | smrs[i].id << SMR_ID_SHIFT |
> smrs[i].mask << SMR_MASK_SHIFT;
> + dev_dbg(smmu->dev, "SMR%d: 0x%x\n", smrs[i].idx, reg);
I think we can drop the dev_dbg statements from this patch.
Will
next prev parent reply other threads:[~2014-01-22 15:26 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 12:44 [PATCH v4 0/11] iommu/arm-smmu: Misc modifications to support SMMUs on Calxeda ECX-2000 Andreas Herrmann
2014-01-16 12:44 ` [PATCH 01/11] iommu/arm-smmu: Introduce driver option handling Andreas Herrmann
2014-01-22 11:51 ` Will Deacon
2014-01-23 20:16 ` Andreas Herrmann
2014-01-16 12:44 ` [PATCH 02/11] iommu/arm-smmu: Introduce bus notifier block Andreas Herrmann
2014-01-18 20:59 ` Varun Sethi
2014-01-20 21:29 ` Andreas Herrmann
2014-01-20 21:53 ` [PATCH v2 02/11] iommu/arm-smmu: Introduce iommu_group " Andreas Herrmann
2014-01-20 21:56 ` Andreas Herrmann
2014-01-20 22:28 ` [PATCH v3 " Andreas Herrmann
2014-01-21 17:48 ` Varun Sethi
2014-01-22 12:25 ` Will Deacon
2014-01-22 13:14 ` Varun Sethi
2014-01-22 13:40 ` Will Deacon
2014-01-22 13:54 ` Varun Sethi
2014-01-22 15:33 ` Will Deacon
2014-01-22 19:07 ` Varun Sethi
2014-01-23 19:57 ` Andreas Herrmann
2014-01-28 11:00 ` Varun Sethi
2014-01-29 14:14 ` Andreas Herrmann
2014-01-29 19:19 ` Varun Sethi
2014-01-23 19:24 ` Andreas Herrmann
2014-01-24 9:48 ` Andreas Herrmann
2014-01-16 12:44 ` [PATCH 03/11] iommu/arm-smmu: Support buggy implementation where all config accesses are secure Andreas Herrmann
2014-01-16 12:44 ` [PATCH 04/11] iommu/arm-smmu: Introduce automatic stream-id-masking Andreas Herrmann
2014-01-22 15:26 ` Will Deacon [this message]
2014-01-22 20:15 ` Andreas Herrmann
2014-01-16 12:44 ` [PATCH 05/11] iommu/arm-smmu: Check for duplicate stream IDs when registering master devices Andreas Herrmann
2014-01-22 15:53 ` Will Deacon
2014-01-23 21:17 ` Andreas Herrmann
2014-01-16 12:44 ` [PATCH 06/11] documentation/iommu: Update description of ARM System MMU binding Andreas Herrmann
2014-01-16 14:31 ` Rob Herring
2014-01-16 12:44 ` [PATCH 07/11] iommu/arm-smmu: Set MAX_MASTER_STREAMIDS to MAX_PHANDLE_ARGS Andreas Herrmann
2014-01-16 12:44 ` [PATCH 08/11] of: Increase MAX_PHANDLE_ARGS Andreas Herrmann
2014-01-16 14:25 ` Rob Herring
2014-01-17 11:00 ` Andreas Herrmann
2014-01-17 11:08 ` [PATCH v2 " Andreas Herrmann
2014-01-29 16:11 ` Suravee Suthikulanit
[not found] ` < CAL_JsqLhzp5jUJPA91rNkQ07kCDYCDZLxw8LxxFEVP9b12e1Jw@mail.gmail.com>
2014-01-29 16:57 ` Rob Herring
2014-01-29 16:59 ` Suravee Suthikulanit
2014-01-29 17:16 ` Andreas Herrmann
2014-01-29 17:26 ` Suravee Suthikulanit
2014-01-29 17:29 ` Will Deacon
2014-01-29 17:57 ` Suravee Suthikulanit
2014-01-29 18:03 ` Will Deacon
2014-01-30 22:53 ` Suravee Suthikulanit
2014-01-31 0:18 ` Will Deacon
2014-01-30 17:45 ` Andreas Herrmann
2014-01-31 16:24 ` Rob Herring
2014-02-03 16:44 ` Will Deacon
2014-02-04 17:33 ` Grant Likely
2014-02-04 17:36 ` Grant Likely
2014-01-16 12:44 ` [PATCH 09/11] ARM: dts: Add nodes for SMMUs on Calxeda ECX-2000 Andreas Herrmann
2014-01-16 14:30 ` Rob Herring
2014-01-17 11:01 ` Andreas Herrmann
2014-01-17 11:16 ` [PATCH v2 " Andreas Herrmann
2014-01-16 12:44 ` [PATCH 10/11] arm: dma-mapping: Add additional parameters to arm_iommu_create_mapping Andreas Herrmann
2014-01-22 16:01 ` Will Deacon
2014-01-16 12:44 ` [PATCH 11/11] arm: dma-mapping: Add support to extend DMA IOMMU mappings Andreas Herrmann
2014-01-22 16:10 ` Will Deacon
2014-01-23 21:50 ` Andreas Herrmann
2014-01-29 10:57 ` Marek Szyprowski
2014-01-29 11:05 ` Will Deacon
2014-01-29 14:40 ` Andreas Herrmann
2014-01-30 8:28 ` Marek Szyprowski
2014-01-30 8:44 ` Andreas Herrmann
2014-01-31 17:23 ` [PATCH] " Andreas Herrmann
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=20140122152622.GD14108@mudshark.cambridge.arm.com \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).