From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulanit Subject: Re: [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS Date: Wed, 29 Jan 2014 10:11:46 -0600 Message-ID: <52E92842.3000001@amd.com> References: <1389876263-25759-1-git-send-email-andreas.herrmann@calxeda.com> <1389876263-25759-9-git-send-email-andreas.herrmann@calxeda.com> <20140117110830.GW3471@alberich> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140117110830.GW3471@alberich> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andreas Herrmann , Will Deacon Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , Rob Herring , Grant Likely , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org On 1/17/2014 5:08 AM, Andreas Herrmann wrote: > > arm-smmu driver uses of_parse_phandle_with_args when parsing DT > information to determine stream IDs for a master device. > Thus the number of stream IDs per master device is bound by > MAX_PHANDLE_ARGS. > > To support Calxeda ECX-2000 hardware arm-smmu driver requires a > slightly higher value for MAX_PHANDLE_ARGS as this hardware has 10 > stream IDs for one master device. > > Increasing it to 16 seems a reasonable choice. > > Cc: Grant Likely > Cc: Rob Herring > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > Cc: Andreas Herrmann > Acked-by: Rob Herring > Signed-off-by: Andreas Herrmann > --- > include/linux/of.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/of.h b/include/linux/of.h > index 276c546..24e1b28 100644 > --- a/include/linux/of.h > +++ b/include/linux/of.h > @@ -67,7 +67,7 @@ struct device_node { > #endif > }; > > -#define MAX_PHANDLE_ARGS 8 > +#define MAX_PHANDLE_ARGS 16 Since the MMU-500 specify "Number of SMRs" upto 128 registers, shouldn't this be changed to be able to support 128 StreamIDs as well? Although I am not sure if this would be too big to have on the stack per Rob's comment in the previous patch set. Thank you, Suravee -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: suravee.suthikulpanit@amd.com (Suravee Suthikulanit) Date: Wed, 29 Jan 2014 10:11:46 -0600 Subject: [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS In-Reply-To: <20140117110830.GW3471@alberich> References: <1389876263-25759-1-git-send-email-andreas.herrmann@calxeda.com> <1389876263-25759-9-git-send-email-andreas.herrmann@calxeda.com> <20140117110830.GW3471@alberich> Message-ID: <52E92842.3000001@amd.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 1/17/2014 5:08 AM, Andreas Herrmann wrote: > > arm-smmu driver uses of_parse_phandle_with_args when parsing DT > information to determine stream IDs for a master device. > Thus the number of stream IDs per master device is bound by > MAX_PHANDLE_ARGS. > > To support Calxeda ECX-2000 hardware arm-smmu driver requires a > slightly higher value for MAX_PHANDLE_ARGS as this hardware has 10 > stream IDs for one master device. > > Increasing it to 16 seems a reasonable choice. > > Cc: Grant Likely > Cc: Rob Herring > Cc: devicetree at vger.kernel.org > Cc: Andreas Herrmann > Acked-by: Rob Herring > Signed-off-by: Andreas Herrmann > --- > include/linux/of.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/of.h b/include/linux/of.h > index 276c546..24e1b28 100644 > --- a/include/linux/of.h > +++ b/include/linux/of.h > @@ -67,7 +67,7 @@ struct device_node { > #endif > }; > > -#define MAX_PHANDLE_ARGS 8 > +#define MAX_PHANDLE_ARGS 16 Since the MMU-500 specify "Number of SMRs" upto 128 registers, shouldn't this be changed to be able to support 128 StreamIDs as well? Although I am not sure if this would be too big to have on the stack per Rob's comment in the previous patch set. Thank you, Suravee