All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Daniel Vetter" <daniel.vetter@intel.com>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Jarkko Nikula" <jarkko.nikula@linux.intel.com>,
	"Wolfram Sang" <wsa@the-dreams.de>, "Len Brown" <lenb@kernel.org>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel@lists.freedesktop.org,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Takashi Iwai <tiwai@suse.de>,
	"russianneuromancer @ ya . ru" <russianneuromancer@ya.ru>,
	linux-i2c@vger.kernel.org
Subject: [PATCH 1/7] x86/platform/intel/iosf_mbi: Add a mutex for punit access
Date: Sun,  8 Jan 2017 14:44:21 +0100	[thread overview]
Message-ID: <20170108134427.8392-2-hdegoede@redhat.com> (raw)
In-Reply-To: <20170108134427.8392-1-hdegoede@redhat.com>

One some systems the punit accesses the pmic to change various voltages
through the same bus as other kernel drivers use for e.g. battery
monitoring.

If a driver sends requests to the punit which require the punit to access
the pmic bus while another driver is also accessing the pmic bus various
bad things happen.

This commit adds a mutex to protect the punit against simultaneous accesses
and 2 functions to lock / unlock this mutex.

Note on these systems the i2c-bus driver will request a sempahore from the
punit for exclusive access to the pmic bus when i2c drivers are accessing
it, but this does not appear to be sufficient, we still need to avoid
making certain punit requests during the access window to avoid problems.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: tagorereddy <tagore.chandan@gmail.com>
---
 arch/x86/include/asm/iosf_mbi.h    | 31 +++++++++++++++++++++++++++++++
 arch/x86/platform/intel/iosf_mbi.c | 13 +++++++++++++
 2 files changed, 44 insertions(+)

diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
index b41ee16..91f5d16 100644
--- a/arch/x86/include/asm/iosf_mbi.h
+++ b/arch/x86/include/asm/iosf_mbi.h
@@ -88,6 +88,33 @@ int iosf_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr);
  */
 int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask);
 
+/**
+ * iosf_mbi_punit_lock() - Lock the punit mutex
+ *
+ * One some systems the punit accesses the pmic to change various voltages
+ * through the same bus as other kernel drivers use for e.g. battery monitoring.
+ *
+ * If a driver sends requests to the punit which require the punit to access the
+ * pmic bus while another driver is also accessing the pmic bus various bad
+ * things happen.
+ *
+ * To avoid these problems this function must be called before accessing the
+ * punit or the pmic, be it through iosf_mbi* functions or through other means.
+ *
+ * Note on these systems the i2c-bus driver will request a sempahore from the
+ * punit for exclusive access to the pmic bus when i2c drivers are accessing it,
+ * but this does not appear to be sufficient, we still need to avoid making
+ * certain punit requests during the access window to avoid problems.
+ *
+ * This function locks a mutex, as such it may sleep.
+ */
+void iosf_mbi_punit_lock(void);
+
+/**
+ * iosf_mbi_punit_unlock() - Unlock the punit mutex
+ */
+void iosf_mbi_punit_unlock(void);
+
 #else /* CONFIG_IOSF_MBI is not enabled */
 static inline
 bool iosf_mbi_available(void)
@@ -115,6 +142,10 @@ int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask)
 	WARN(1, "IOSF_MBI driver not available");
 	return -EPERM;
 }
+
+static inline void iosf_mbi_punit_lock(void) {}
+static inline void iosf_mbi_punit_unlock(void) {}
+
 #endif /* CONFIG_IOSF_MBI */
 
 #endif /* IOSF_MBI_SYMS_H */
diff --git a/arch/x86/platform/intel/iosf_mbi.c b/arch/x86/platform/intel/iosf_mbi.c
index edf2c54..75d8135 100644
--- a/arch/x86/platform/intel/iosf_mbi.c
+++ b/arch/x86/platform/intel/iosf_mbi.c
@@ -34,6 +34,7 @@
 
 static struct pci_dev *mbi_pdev;
 static DEFINE_SPINLOCK(iosf_mbi_lock);
+static DEFINE_MUTEX(iosf_mbi_punit_mutex);
 
 static inline u32 iosf_mbi_form_mcr(u8 op, u8 port, u8 offset)
 {
@@ -190,6 +191,18 @@ bool iosf_mbi_available(void)
 }
 EXPORT_SYMBOL(iosf_mbi_available);
 
+void iosf_mbi_punit_lock(void)
+{
+	mutex_lock(&iosf_mbi_punit_mutex);
+}
+EXPORT_SYMBOL(iosf_mbi_punit_lock);
+
+void iosf_mbi_punit_unlock(void)
+{
+	mutex_unlock(&iosf_mbi_punit_mutex);
+}
+EXPORT_SYMBOL(iosf_mbi_punit_unlock);
+
 #ifdef CONFIG_IOSF_MBI_DEBUG
 static u32	dbg_mdr;
 static u32	dbg_mcr;
-- 
2.9.3

  reply	other threads:[~2017-01-08 13:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-08 13:44 [PATCH 0/7] coordinate cht i2c-pmic and i915-punit accesses Hans de Goede
2017-01-08 13:44 ` Hans de Goede [this message]
2017-01-08 15:16   ` [PATCH 1/7] x86/platform/intel/iosf_mbi: Add a mutex for punit access Andy Shevchenko
2017-01-08 15:30     ` Hans de Goede
2017-01-08 15:35       ` Andy Shevchenko
2017-01-08 13:44 ` [PATCH 2/7] x86/platform/intel/iosf_mbi: Add a pmic bus access notifier Hans de Goede
2017-01-08 15:21   ` Andy Shevchenko
2017-01-08 13:44 ` [PATCH 3/7] i2c: designware-baytrail: Take punit lock on bus acquire Hans de Goede
2017-01-08 15:27   ` Andy Shevchenko
2017-01-08 15:39     ` Hans de Goede
2017-01-12 18:45   ` Wolfram Sang
2017-01-15 11:21     ` Hans de Goede
2017-01-15 11:45       ` Wolfram Sang
2017-01-15 15:11         ` Hans de Goede
2017-01-15 15:17           ` Wolfram Sang
2017-01-08 13:44 ` [PATCH 4/7] i2c: designware-baytrail: Call pmic_bus_access_notifier_chain Hans de Goede
2017-01-08 15:23   ` Andy Shevchenko
2017-01-12 18:45   ` Wolfram Sang
2017-01-08 13:44 ` [PATCH 5/7] drm/i915: Add intel_uncore_suspend / resume functions Hans de Goede
2017-01-08 13:44 ` [PATCH 6/7] drm/i915: Listen for pmic bus access notifications Hans de Goede
2017-01-08 13:44 ` [PATCH 7/7] drm/i915: Take punit lock when modifying punit settings Hans de Goede
2017-01-08 15:34   ` Andy Shevchenko
2017-01-08 15:42     ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170108134427.8392-2-hdegoede@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=russianneuromancer@ya.ru \
    --cc=tiwai@suse.de \
    --cc=ville.syrjala@linux.intel.com \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.