On Tue, Feb 15, 2011 at 4:08 PM, David Cohen <dacohen@xxxxxxxxx> wrote: > On Tue, Feb 15, 2011 at 3:59 PM, Jarkko Nikula <jhnikula@xxxxxxxxx> wrote: >> On Tue, 15 Feb 2011 15:44:27 +0200 >> David Cohen <dacohen@xxxxxxxxx> wrote: >> >>> >> @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, >>> >> u32 *ra) >>> >> Â Â Â Âda = iommu_read_reg(obj, MMU_FAULT_AD); >>> >> Â Â Â Â*ra = da; >>> >> >>> >> - Â Â Â dev_err(obj->dev, "%s:\tda:%08x ", __func__, da); >>> >> + Â Â Â dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da); >>> > >>> > Â Note that dev_dbg() will only print something if either DEBUG or >>> > CONFIG_DYNAMIC_DEBUG are defined... >>> >>> That's my plan. >>> >> So it's sure that a developer won't need these error dumps when >> receiving an error report? I.e. IOMMU upper level errors give enough >> information to start doing own debugging? > > Yes, developers do need this information. > But it's a bit useless tell only we've got an iommu fault, due to many > places might be causing it. My purpose is to let the debug > responsibility to IOMMU users. They have access to the iovmm layer as > well and can provide a much more useful information. > e.g. OMAP3 ISP has many submodules using IOMMU. With a fault callback, > it can dump all the iovm areas and the faulty 'da' too. It might > indicate which submodule was responsible for the issue. > > Of course we can just let this debug messages the way they are and > print this redundant information. But IMO it's not necessary. Indeed, we can leave this discussion for future. My main purpose now is the fault callback. I'll drop this patch 1/2 for now. Regards, David > > Regards, > > David > >> >> Just my 2 cents. >> >> -- >> Jarkko >> > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
