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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham 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 B9F9FC433DB for ; Wed, 17 Feb 2021 11:02:34 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 77E8064E76 for ; Wed, 17 Feb 2021 11:02:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 77E8064E76 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 14ABE6E4DE; Wed, 17 Feb 2021 11:02:34 +0000 (UTC) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id B12B66E0D5 for ; Wed, 17 Feb 2021 11:02:32 +0000 (UTC) IronPort-SDR: RROVixc3Ym2hJqo6FoJbkobJU7d//dNo6lHk2A6ALDgCeI/aVwa3+lHhBlTgqQPhGPZrTlem4i fC6HkkbQOPBg== X-IronPort-AV: E=McAfee;i="6000,8403,9897"; a="170298848" X-IronPort-AV: E=Sophos;i="5.81,184,1610438400"; d="scan'208";a="170298848" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2021 03:02:23 -0800 IronPort-SDR: ndU67Uz7VyDRZElHJE3LBsbDJqlkKLcu6bTYZ1s2JZ6m9e8K5Tukk1Xe1t1p5Qyt6ocenwyRrA bQEpp1sNaLWA== X-IronPort-AV: E=Sophos;i="5.81,184,1610438400"; d="scan'208";a="399912624" Received: from mvalka-mobl1.ger.corp.intel.com (HELO localhost) ([10.252.39.140]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2021 03:02:19 -0800 From: Jani Nikula To: Tomas Winkler , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Joonas Lahtinen , Rodrigo Vivi In-Reply-To: <20210216181925.650082-1-tomas.winkler@intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20210216181925.650082-1-tomas.winkler@intel.com> Date: Wed, 17 Feb 2021 13:02:16 +0200 Message-ID: <878s7narev.fsf@intel.com> MIME-Version: 1.0 Subject: Re: [Intel-gfx] [RFC PATCH 0/9] drm/i915/spi: discrete graphics internal spi X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-mtd@lists.infradead.org, intel-gfx@lists.freedesktop.org, Tomas Winkler , Alexander Usyskin , Vitaly Lubart Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, 16 Feb 2021, Tomas Winkler wrote: > Intel discrete graphic devices have internal spi storage, that holds > firmware and oprom images. The spi device is exposed to the user space > via mtd framework to be accessed during manufacturing. > The device is hardware locked after manufacturing and only read access > is provided. > > The i915 plays role of a multi function device (mfd) and spi device > is exposed as its child device. i915_spi platform driver binds to > this device. > > Because the graphic card may undergo reset at any time and basically hot > unplug all its child devices, this series also provides a fix to the mtd > framework to make the reset graceful. > > Tomas Winkler (9): > drm/i915/spi: add spi device for discrete graphics > drm/i915/spi: intel_spi_region map > drm/i915/spi: add driver for on-die spi device > drm/i915/spi: implement region enumeration > drm/i915/spi: implement spi access functions > drm/i915/spi: spi register with mtd > drm/i915/spi: mtd: implement access handlers > drm/i915/spi: serialize spi access > mtd: use refcount to prevent corruption > > drivers/gpu/drm/i915/Kconfig | 3 + > drivers/gpu/drm/i915/Makefile | 6 + > drivers/gpu/drm/i915/i915_drv.c | 9 + > drivers/gpu/drm/i915/i915_drv.h | 4 + > drivers/gpu/drm/i915/i915_reg.h | 1 + > drivers/gpu/drm/i915/spi/intel_spi.c | 62 +++ > drivers/gpu/drm/i915/spi/intel_spi.h | 24 + I'm open to discussion, but after glancing through the series I've got a gut feeling spi/ subdir should be purely about the separate module, and the above two files should be in i915/ directory instead. As it is, I think it's a bit confusing that spi/ is both about the spi kernel module and a singly .c file that's really part of i915.ko. Perhaps that messes up the conventional descending to subdirs in the kernel build too? BR, Jani. > drivers/gpu/drm/i915/spi/intel_spi_drv.c | 675 +++++++++++++++++++++++ > drivers/mtd/mtdcore.c | 63 ++- > drivers/mtd/mtdcore.h | 1 + > drivers/mtd/mtdpart.c | 13 +- > include/linux/mtd/mtd.h | 2 +- > 12 files changed, 831 insertions(+), 32 deletions(-) > create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.c > create mode 100644 drivers/gpu/drm/i915/spi/intel_spi.h > create mode 100644 drivers/gpu/drm/i915/spi/intel_spi_drv.c -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx