From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B06B3C433E2 for ; Wed, 15 Jul 2020 10:08:06 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 77F67206D5 for ; Wed, 15 Jul 2020 10:08:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="oMfKdNPY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 77F67206D5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UnDVKw6OeUnJRm7BEAo+C1rYSCPSaP2Nk3tT5BwPipQ=; b=oMfKdNPYWJd+9vWM3mYsMYkHx 5kt97T3InAAE8ZFVBr+pU3Ec92TTWpX1JChaN53Rlev5RBgVVNZXRjszfX467R3PicYEGsyMAO9LS PBeXywkEQWlDezAuoLdsS4UCooZdxcZ5QrlFIxDGldpYuK+gtHPUzAK7wCUUMhuyV1hyNA1n+Ahng 4EDpV4TWs24ehNwKlW9K+bFz/1CHN11tYcVoBUY3fAiaIyQGORMZqVGM81wOfoHLzuNqG1m0q+z/v DHtrw4mmiTuZx+pKuJNqRjQk+TWiBXL+byxYbHjTVwn0TqhFBFnHUrRc9Sd5oIbWAU1OY8ADGZZYW HU/MerQ0A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jveJK-000458-Qi; Wed, 15 Jul 2020 10:06:46 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jveJI-00044K-IJ for linux-arm-kernel@lists.infradead.org; Wed, 15 Jul 2020 10:06:45 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DB79730E; Wed, 15 Jul 2020 03:06:43 -0700 (PDT) Received: from e121166-lin.cambridge.arm.com (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AA0563F718; Wed, 15 Jul 2020 03:06:41 -0700 (PDT) Date: Wed, 15 Jul 2020 11:06:36 +0100 From: Lorenzo Pieralisi To: Makarand Pawagi Subject: Re: [EXT] Re: [PATCH v2 12/12] bus: fsl-mc: Add ACPI support for fsl-mc Message-ID: <20200715100636.GA31330@e121166-lin.cambridge.arm.com> References: <20200521130008.8266-1-lorenzo.pieralisi@arm.com> <20200619082013.13661-1-lorenzo.pieralisi@arm.com> <20200619082013.13661-13-lorenzo.pieralisi@arm.com> <20200709091950.GA18149@e121166-lin.cambridge.arm.com> <203372be-144c-54ba-d011-30d0746dd615@nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200715_060644_729673_38CA4C91 X-CRM114-Status: GOOD ( 26.04 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "devicetree@vger.kernel.org" , Sudeep Holla , Catalin Marinas , Will Deacon , "linux-pci@vger.kernel.org" , Joerg Roedel , Hanjun Guo , "Rafael J. Wysocki" , "linux-acpi@vger.kernel.org" , "iommu@lists.linux-foundation.org" , Rob Herring , Marc Zyngier , "Diana Madalina Craciun \(OSS\)" , Bjorn Helgaas , Robin Murphy , "linux-arm-kernel@lists.infradead.org" , Laurentiu Tudor Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 09, 2020 at 10:52:52AM +0000, Makarand Pawagi wrote: [...] > > >>>> fsl_mc_bus_probe(struct platform_device *pdev) > > >>>>>> struct fsl_mc_io *mc_io = NULL; > > >>>>>> int container_id; > > >>>>>> phys_addr_t mc_portal_phys_addr; > > >>>>>> - u32 mc_portal_size; > > >>>>>> - struct resource res; > > >>>>>> + u32 mc_portal_size, mc_stream_id; > > >>>>>> + struct resource *plat_res; > > >>>>>> + > > >>>>>> + if (!iommu_present(&fsl_mc_bus_type)) > > >>>>>> + return -EPROBE_DEFER; > > >>>>>> > > >>>>>> mc = devm_kzalloc(&pdev->dev, sizeof(*mc), GFP_KERNEL); > > >>>>>> if (!mc) > > >>>>>> @@ -874,19 +887,33 @@ static int fsl_mc_bus_probe(struct > > >>>>>> platform_device *pdev) > > >>>>>> > > >>>>>> platform_set_drvdata(pdev, mc); > > >>>>>> > > >>>>>> + plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 1); > > >>>>>> + mc->fsl_mc_regs = devm_ioremap_resource(&pdev->dev, plat_res); > > >>>>>> + if (IS_ERR(mc->fsl_mc_regs)) > > >>>>>> + return PTR_ERR(mc->fsl_mc_regs); > > >>>>>> + > > >>>>>> + if (IS_ENABLED(CONFIG_ACPI) && !dev_of_node(&pdev->dev)) { > > >>>>>> + mc_stream_id = readl(mc->fsl_mc_regs + FSL_MC_FAPR); > > >>>>>> + /* > > >>>>>> + * HW ORs the PL and BMT bit, places the result in bit 15 of > > >>>>>> + * the StreamID and ORs in the ICID. Calculate it accordingly. > > >>>>>> + */ > > >>>>>> + mc_stream_id = (mc_stream_id & 0xffff) | > > >>>>>> + ((mc_stream_id & (MC_FAPR_PL | MC_FAPR_BMT)) ? > > >>>>>> + 0x4000 : 0); > > >>>>>> + error = acpi_dma_configure_id(&pdev->dev, > > DEV_DMA_COHERENT, > > >>>>>> + &mc_stream_id); > > >>>>>> + if (error) > > >>>>>> + dev_warn(&pdev->dev, "failed to configure dma: %d.\n", > > >>>>>> + error); > > >>>>>> + } > > >>>>>> + > > >>>>>> /* > > >>>>>> * Get physical address of MC portal for the root DPRC: > > >>>>>> */ > > >>>>>> - error = of_address_to_resource(pdev->dev.of_node, 0, &res); > > >>>>>> - if (error < 0) { > > >>>>>> - dev_err(&pdev->dev, > > >>>>>> - "of_address_to_resource() failed for %pOF\n", > > >>>>>> - pdev->dev.of_node); > > >>>>>> - return error; > > >>>>>> - } > > >>>>>> - > > >>>>>> - mc_portal_phys_addr = res.start; > > >>>>>> - mc_portal_size = resource_size(&res); > > >>>>>> + plat_res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > > >>>>>> + mc_portal_phys_addr = plat_res->start; > > >>>>>> + mc_portal_size = resource_size(plat_res); > > >>>>>> error = fsl_create_mc_io(&pdev->dev, mc_portal_phys_addr, > > >>>>>> mc_portal_size, NULL, > > >>>>>> FSL_MC_IO_ATOMIC_CONTEXT_PORTAL, > > >>>>>> &mc_io); @@ -903,11 +930,13 @@ static int fsl_mc_bus_probe(struct > > >>>> platform_device *pdev) > > >>>>>> dev_info(&pdev->dev, "MC firmware version: %u.%u.%u\n", > > >>>>>> mc_version.major, mc_version.minor, > > >>>>>> mc_version.revision); > > >>>>>> > > >>>>>> - error = get_mc_addr_translation_ranges(&pdev->dev, > > >>>>>> - &mc->translation_ranges, > > >>>>>> - &mc->num_translation_ranges); > > >>>>>> - if (error < 0) > > >>>>>> - goto error_cleanup_mc_io; > > >>>>>> + if (dev_of_node(&pdev->dev)) { > > >>>>>> + error = get_mc_addr_translation_ranges(&pdev->dev, > > >>>>>> + &mc->translation_ranges, > > >>>>>> + &mc->num_translation_ranges); > > >>>>>> + if (error < 0) > > >>>>>> + goto error_cleanup_mc_io; > > >>>>>> + } > > >>>>>> > > >>>>>> error = dprc_get_container_id(mc_io, 0, &container_id); > > >>>>>> if (error < 0) { > > >>>>>> @@ -934,6 +963,7 @@ static int fsl_mc_bus_probe(struct > > >>>>>> platform_device > > >>>> *pdev) > > >>>>>> goto error_cleanup_mc_io; > > >>>>>> > > >>>>>> mc->root_mc_bus_dev = mc_bus_dev; > > >>>>>> + mc_bus_dev->dev.fwnode = pdev->dev.fwnode; > > >>>>> Makarand, this looks a bit weird. Is there really a reason for it? > > >>>> Can you clarify please so that we can reach a conclusion on this matter ? > > >>>> > > >>> Laurentiu, can you clarify what exactly is the doubt here? Are you > > >>> asking about > > >> fwnode assignment from pdev to mc_bus_dev? > > >> Yes. I remember that a while ago I tested without this fwnode > > >> assignment and didn't encounter any issues. Maybe we can just drop it? > > > Did you tested with PHY changes? Because this is needed for MAC driver, > > where it needs the mc bus node. > > > > Maybe it worth a comment or maybe have it in a different patch? > > > Since this change is needed for ACPI case and this is ACPI support > case, I feel we should have this change in this patch only instead of > separate patch. Anyway - you need to seek feedback from Marc on whether patches 11 and 12 are OK from an irqchip perspective, it is possible we can take the rest of the series independently if everyone agrees but I don't necessarily see a reason for that. Long story short: you need Marc's ACK on [11-12], it is your code. Thanks, Lorenzo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel