On Mon, 2015-03-09 at 18:59 +0100, Paul Bolle wrote: > Hi Yong, > > Yong Wu schreef op ma 09-03-2015 om 19:57 [+0800]: > > On Fri, 2015-03-06 at 12:30 +0100, Paul Bolle wrote: > > > On Fri, 2015-03-06 at 18:48 +0800, yong.wu@xxxxxxxxxxxx wrote: > > > > --- a/drivers/soc/mediatek/Kconfig > > > > +++ b/drivers/soc/mediatek/Kconfig > > > > @@ -20,3 +20,10 @@ config MT8173_PMIC_WRAP > > > > PMIC wrapper is a proprietary hardware in MT8173 to make > > > > communication protocols to access PMIC device. > > > > This driver implement access protocols for MT8173. > > > > + > > > > +config MTK_SMI > > > > + bool > > > > > > Nit: make this one tab instead of 8 spaces, please. > > > > > > > + help > > > > + Smi help enable/disable iommu in mt8173 and control the > > > > + clock of each local arbiter. > > > > + It should be true while MTK_IOMMU enable. > > > > > > I don't think anyone using the *config tools will ever see this text, as > > > there's no prompt. So you might as well make this a comment or drop it > > > altogether. > > > > > We could search it in the tool even though we don't see it. In next > > version, I will try to make it a comment. > > > Is this selected by more than just MTK_IOMMU (see 2/5)? If not, I think > > > MTK_SMI will be set and unset in lockstep with MTK_IOMMU. In other > > > words, you could as well use one Kconfig symbol. > > > > > if we disable MTK_IOMMU, the MTK_SMI also should be selected.That is because > > if the multimedia h/w want to work, the clock of the local arbiters always should be opened. > > This is a bit confusing, I'm afraid. Do you mean to say that it ought to > be possible for MTK_SMI to be 'y' even if MTK_IOMMU would be 'n'? The SMI can be configured to bypass IOMMU and send traffic directly to memory interface. It is possible to not use IOMMU and have display/MM to use continuous memory only. Besides MTK_IOMMU, we expect DRM, VDEC driver to select MTK_SMI as well. Joe.C -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html