From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Subject: Re: Using OMAP3 ISP live display and snapshot sample applications Date: Thu, 23 Feb 2012 17:38:32 +0100 Message-ID: <2017729.C83vkrQlqN@avalon> References: <20120214104436.GU22598@amd.com> <13567544.qv9HnVLVXR@avalon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <13567544.qv9HnVLVXR@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Joerg Roedel Cc: Ohad Ben-Cohen , James , iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: iommu@lists.linux-foundation.org Hi Joerg and Ohad, Ping ? I've discussed this with Ohad last week, and we agreed that there was indeed an issue with the IOMMU subsystem and/or the OMAP3 IOMMU driver. Could you please have a look at my explanation below ? On Thursday 16 February 2012 07:46:58 Laurent Pinchart wrote: > On Tuesday 14 February 2012 11:44:37 Joerg Roedel wrote: > > On Mon, Feb 13, 2012 at 09:28:30AM +0800, James wrote: > > > >> @@ -28,6 +28,7 @@ obj-$(CONFIG_XEN) += xen/ > > > >> > > > >> # regulators early, since some subsystems rely on them to initialize > > > >> obj-$(CONFIG_REGULATOR) += regulator/ > > > >> > > > >> +obj-$(CONFIG_IOMMU_SUPPORT) += iommu/ > > > >> > > > >> # tty/ comes before char/ so that the VT console is the boot-time > > > >> # default. > > > >> > > > >> @@ -125,7 +126,6 @@ obj-y += clk/ > > > >> > > > >> obj-$(CONFIG_HWSPINLOCK) += hwspinlock/ > > > >> obj-$(CONFIG_NFC) += nfc/ > > > >> > > > >> -obj-$(CONFIG_IOMMU_SUPPORT) += iommu/ > > > >> > > > >> # Virtualization drivers > > > >> obj-$(CONFIG_VIRT_DRIVERS) += virt/ > > > > I don't see how this patch solves a problem like below. > > > > > [ 3.663269] Unable to handle kernel NULL pointer dereference at > > > virtual > > > address 00000058 > > [snip] > > > > [] (klist_next+0x10/0xb4) from [] > > > (next_device+0x8/0x14) > > > [] (next_device+0x8/0x14) from [] > > > (driver_find_device+0x64/0x7c) > > > [] (driver_find_device+0x64/0x7c) from [] > > > (isp_probe+0x228/0xa34) > > [snip] > > > This looks more like data corruption or something. But this is definitly > > not caused by some random order in the Makefile. > > Please debug this issue down to the real cause. Bisecting may help here. > > There's actually a line missing from the backtrace for some reason. > > isp_probe() calls iommu_attach_device(), which ends up calling > omap_iommu_attach(). That function then calls driver_find_device(), passing > it omap_iommu_driver.driver as its first argument. However, as the OMAP3 > ISP driver is linked in the kernel before the OMAP3 IOMMU driver, > omap_iommu_init() has not be called yet by this time. > omap_iommu_driver.driver is thus uninitialized, and klist iteration oopses > as the linked list head is NULL. -- Regards, Laurent Pinchart