* [Bug 185531] New: pata_hpt366 irq xx: nobody cared
From: bugzilla-daemon @ 2016-10-28 20:13 UTC (permalink / raw)
To: linux-ide
https://bugzilla.kernel.org/show_bug.cgi?id=185531
Bug ID: 185531
Summary: pata_hpt366 irq xx: nobody cared
Product: IO/Storage
Version: 2.5
Kernel Version: Linux 4.4.0-45-generic Ubuntu SMP x86_64
Hardware: Intel
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IDE
Assignee: io_ide@kernel-bugs.osdl.org
Reporter: ilario.gottardello@gmail.com
Regression: No
Some time after boot, a spurious interrupt make this driver downgrade
performance from udma to pio. This interrupt is assigned solely to this card,
as says /proc/interrupts:
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
CPU6 CPU7
19: 4147 0 0 188 195666 0
0 0 IO-APIC 19-fasteoi pata_hpt366, pata_hpt366
This is the relevant part from dmesg:
[ 3049.573902] irq 19: nobody cared (try booting with the "irqpoll" option)
[ 3049.573910] CPU: 4 PID: 0 Comm: swapper/4 Tainted: P OE
4.4.0-45-generic #66-Ubuntu
[ 3049.573912] Hardware name: System manufacturer System Product Name/P8H67-V,
BIOS 3707 07/12/2013
[ 3049.573915] 0000000000000086 d86ed4c7c37291ec ffff88012f303e60
ffffffff813f1fe3
[ 3049.573919] ffff8800c07a5a00 ffff8800c07a5ab4 ffff88012f303e88
ffffffff810dd7a3
[ 3049.573922] ffff8800c07a5a00 0000000000000000 0000000000000013
ffff88012f303ec0
[ 3049.573925] Call Trace:
[ 3049.573927] <IRQ> [<ffffffff813f1fe3>] dump_stack+0x63/0x90
[ 3049.573940] [<ffffffff810dd7a3>] __report_bad_irq+0x33/0xc0
[ 3049.573943] [<ffffffff810ddb37>] note_interrupt+0x247/0x290
[ 3049.573946] [<ffffffff810dadc7>] handle_irq_event_percpu+0x167/0x1d0
[ 3049.573949] [<ffffffff810dae6e>] handle_irq_event+0x3e/0x60
[ 3049.573952] [<ffffffff810de0a6>] handle_fasteoi_irq+0x96/0x150
[ 3049.573956] [<ffffffff810310fa>] handle_irq+0x1a/0x30
[ 3049.573962] [<ffffffff8183429b>] do_IRQ+0x4b/0xd0
[ 3049.573965] [<ffffffff81832382>] common_interrupt+0x82/0x82
[ 3049.573966] <EOI> [<ffffffff816c4dce>] ? cpuidle_enter_state+0x10e/0x2b0
[ 3049.573975] [<ffffffff816c4fa7>] cpuidle_enter+0x17/0x20
[ 3049.573979] [<ffffffff810c4112>] call_cpuidle+0x32/0x60
[ 3049.573982] [<ffffffff816c4f83>] ? cpuidle_select+0x13/0x20
[ 3049.573986] [<ffffffff810c43d0>] cpu_startup_entry+0x290/0x350
[ 3049.573989] [<ffffffff810516e4>] start_secondary+0x154/0x190
[ 3049.573992] handlers:
[ 3049.573995] [<ffffffff815e81e0>] ata_bmdma_interrupt
[ 3049.573997] [<ffffffff815e81e0>] ata_bmdma_interrupt
[ 3049.573999] Disabling IRQ #19
Already changed cables and moved the card in another slot, the issue still
appears.
I'm willing to help debug the issue. Thanks in advance.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Possible Bug In ATA/SCSI Fixed Sense
From: Charles Machalow @ 2016-10-28 18:34 UTC (permalink / raw)
To: tj; +Cc: linux-ide
Hi all,
As of Linux commit 14970f204b1993af7459d5bd34aaff38dfee6670, In
drivers/ata/libata-scsi.c in ata_gen_passthru_sense() line 1087,
desc[0] is set to tf->feature. This makes sense to me however 4 lines
below the same item in the array is set to 0.
One of these lines must be unintended as no matter what the field will
always be 0 though for a couple lines it is set to tf-feature.
I think that line 1091 is at fault because if I send down a nop
command, feature (error in this case) should be set to 4 in the
returned current task file.
Thanks!
- Charlie Scott Machalow
^ permalink raw reply
* Re: [RFC PATCH] ata: piix: wait for end of asynchronous probing before
From: Tejun Heo @ 2016-10-27 18:59 UTC (permalink / raw)
To: Rob Herring
Cc: Corentin Labbe, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org, Greg Kroah-Hartman
In-Reply-To: <CAL_Jsq+HPd2Ftm7cDD4rpT6jx=EgS9nX+_WiwRcxhpPbi=85xQ@mail.gmail.com>
Hello, Rob.
On Thu, Oct 27, 2016 at 01:55:19PM -0500, Rob Herring wrote:
> Seems like this is mixing async drv probe and async scsi scan and the
> problem is in the latter? I don't think async drv probe should have
> any problems. If a driver probe starts some async operation, then it
> seems to me that it is its responsibility to wait for completion in
> remove().
I'm not sure about that. The async operation synchronization isn't
per-driver or module. Both during boot and module operations, they're
synchronized globally, which makes sense given its purpose and that's
also why we don't see these brekages without this debug option. It
doesn't make sense to me to add a whole new set of behaviors just for
a debug option.
Thanks.
--
tejun
^ permalink raw reply
* Re: [RFC PATCH] ata: piix: wait for end of asynchronous probing before
From: Rob Herring @ 2016-10-27 18:55 UTC (permalink / raw)
To: Tejun Heo
Cc: Corentin Labbe, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org, Greg Kroah-Hartman
In-Reply-To: <20161019172848.GD18532@htj.duckdns.org>
On Wed, Oct 19, 2016 at 12:28 PM, Tejun Heo <tj@kernel.org> wrote:
> (cc'ing Greg and Rob)
>
> Hello,
>
> On Mon, Oct 17, 2016 at 06:45:04PM +0200, Corentin Labbe wrote:
>> Enabling CONFIG_DEBUG_TEST_DRIVER_REMOVE under qemu give me a WARN() trace.
>> Waiting for the end of the ATA RESET seems to clean the issue.
>> But I am not sure if my solution and the way to solve it are correct.
>>
>> Regards
>>
>> ---8<---
>> From b2d097130a9d67529075f6e3c3d9552ac5415d18 Mon Sep 17 00:00:00 2001
>> From: Corentin Labbe <clabbe.montjoie@gmail.com>
>> Date: Mon, 17 Oct 2016 17:50:02 +0200
>> Subject: [RFC PATCH] ata: piix: wait for end of asynchronous probing before
>> removing
>>
>> Under qemu I got the following trace with CONFIG_DEBUG_TEST_DRIVER_REMOVE
>> [ 1.092021] ata_piix 0000:00:01.1: version 2.13
>> [ 1.093277] scsi host0: ata_piix
>> [ 1.093720] scsi host1: ata_piix
>> [ 1.094152] ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc080 irq 14
>> [ 1.094902] ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc088 irq 15
>> [ 1.252998] ------------[ cut here ]------------
>> [ 1.253799] WARNING: CPU: 0 PID: 1 at drivers/ata/libata-core.c:6482 ata_host_detach+0x148/0x150
>
> I don't think it's correct to try to remove the driver while async
> probing is in progress and we shouldn't work around it from individual
> drivers. I think we already have enough async barriers to prevents
> this under normal operation - there's full synchronization during boot
> before control gets passed to userland and module unloading does full
> async flushing too. What we should do, probably, is to make the debug
> code do full async flush before test unloading the driver.
Seems like this is mixing async drv probe and async scsi scan and the
problem is in the latter? I don't think async drv probe should have
any problems. If a driver probe starts some async operation, then it
seems to me that it is its responsibility to wait for completion in
remove().
Rob
^ permalink raw reply
* [Bug 184221] New: 1-877-424-6647 | Mozilla Firefox customer service support phone number | Mozilla Firefox e technical support phone number, Mozilla Firefox support phone number
From: bugzilla-daemon @ 2016-10-27 18:53 UTC (permalink / raw)
To: linux-ide
https://bugzilla.kernel.org/show_bug.cgi?id=184221
Bug ID: 184221
Summary: 1-877-424-6647 | Mozilla Firefox customer service
support phone number | Mozilla Firefox e technical
support phone number, Mozilla Firefox support phone
number
Product: IO/Storage
Version: 2.5
Kernel Version: 1-877-424-6647 | Mozilla Firefox customer service
support phone number | Mozilla Firefox e technical
support phone number, Mozilla Firefox support phone
number
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IDE
Assignee: io_ide@kernel-bugs.osdl.org
Reporter: arlett@t3t97d1d.com
Regression: No
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
1-877-424-6647 | Mozilla Firefox customer service support phone number |
Mozilla Firefox e technical support phone number, Mozilla Firefox support phone
number
https://answers.avira.com/en/question/contact-mozilla-firefox-18774246647-firefox-tech-support-p-62701
https://plus.google.com/100457091534453063311/posts/VAJ3ZNXzNxz
http://woto.com/tkvn4o
Contact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number
++ Thunderbird Email phone number Contact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone number Contact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone number Contact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone number Contact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone numberContact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone numberContact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone numberContact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone numberContact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone numberContact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone numberContact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone numberContact MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476
@@Firefox tech support phone number ++ Thunderbird Email phone numberContact
MOZILLA Firefox +@`@ 18⑦⑦4②④⑥6476 @@Firefox tech support phone number ++
Thunderbird Email phone number
https://forum.bitdefender.com/index.php?/topic/73380-contact-1800-790-9186-mozilla-firefox-support-phone-number-mozilla/
https://www.jotform.com/answers/969665-Contact-1800
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* 2706805393 linux-ide
From: lucia.germino @ 2016-10-27 2:55 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: INFO_29777_linux-ide.zip --]
[-- Type: application/zip, Size: 5365 bytes --]
^ permalink raw reply
* Re: [RFC] libata-scsi: introducing SANITIZE translation
From: Mark Lord @ 2016-10-26 22:44 UTC (permalink / raw)
To: Tom Yan, James Bottomley
Cc: Tejun Heo, martin.petersen, dgilbert, linux-ide, linux-scsi
In-Reply-To: <CAGnHSEms1rwy7-+URRMrdggpk=_7YVijHwf1h93iBKW7zLxh8g@mail.gmail.com>
On 16-07-11 02:35 AM, Tom Yan wrote:
> I don't suppose there would be any problem doing it in userspace /
> with ATA PASS-THROUGH anyway.
..
>>> On 8 July 2016 at 17:29, James Bottomley
>>> <James.Bottomley@hansenpartnership.com> wrote:
..
>> Not really. The point is that you've proposed something as an addition
>> to the kernel that can also be done in userspace. Checking if it can
>> work easily there is like a barrier to entry. If it works, then fine,
>> we're done. If it throws up problems then we reconsider the kernel
>> route.
hdparm has full support for the SANITIZE commands in userspace.
-ml
^ permalink raw reply
* Re: [GIT PULL] libata fixes for v4.9-rc2
From: David Howells @ 2016-10-26 22:17 UTC (permalink / raw)
To: Tejun Heo, Linus Torvalds; +Cc: dhowells, hch, linux-ide, linux-kernel
In-Reply-To: <20161026182911.GB23927@htj.duckdns.org>
> The AHCI MSI handling change in rc1 was a bit broken and caused disk
> probing failures on some machines. These three patches should fix the
> issues.
My test machine fell foul of this using a PCIe M.2-attached SSD card.
The patches fix it for me.
Tested-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* [GIT PULL] libata fixes for v4.9-rc2
From: Tejun Heo @ 2016-10-26 18:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-ide, linux-kernel
Hello, Linus.
The AHCI MSI handling change in rc1 was a bit broken and caused disk
probing failures on some machines. These three patches should fix the
issues.
Thanks.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.9-fixes
for you to fetch changes up to 0ce57f8af1782fd12d3a81872a4ab97244989802:
ahci: fix the single MSI-X case in ahci_init_one (2016-10-25 11:43:07 -0400)
----------------------------------------------------------------
Christoph Hellwig (3):
ahci: only try to use multi-MSI mode if there is more than 1 port
ahci: fix nvec check
ahci: fix the single MSI-X case in ahci_init_one
drivers/ata/ahci.c | 41 ++++++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 19 deletions(-)
--
tejun
^ permalink raw reply
* Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Bartlomiej Zolnierkiewicz @ 2016-10-26 17:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Russell King, Dmitry Eremin-Solenikov,
linux-kernel, linux-ide, Olof Johansson, Kevin Hilman,
Nori, Sekhar
In-Reply-To: <4264651.gPKphdYuCx@wuerfel>
Hi,
On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote:
> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> >
> > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > This patch disables deprecated IDE subsystem in assabet_defconfig
> > > > (no IDE host drivers are selected in this config so there is no
> > > > valid reason to enable IDE subsystem itself).
> > > >
> > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > >
> > > I think the series makes a lot of sense. I have checked your assertions
> > > in the changelogs and found no flaws in your logic, so I think we should
> > > take them all through arm-soc unless there are other concerns.
> >
> > Thank you.
> >
> > Should I resend everything or just patches that were not reposted yet
> > (the ones that were marked as RFT initially and got no feedback)?
>
> I'd be fine with just getting a pull request with all the patches that
> had no negative feedback and that were not already applied (if any).
Here it is (sorry for taking so long).
The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
are available in the git repository at:
https://github.com/bzolnier/linux.git v4.9-rc2-arm-configs-pata
for you to fetch changes up to bc9c6cc857849ec0d83bd13c1812bae9345dc553:
arm: spitz_defconfig: convert to use libata PATA drivers (2016-10-26 18:43:33 +0200)
----------------------------------------------------------------
Bartlomiej Zolnierkiewicz (16):
arm: assabet_defconfig: disable IDE subsystem
arm: badge4_defconfig: disable IDE subsystem
arm: cerfcube_defconfig: disable IDE subsystem
arm: lart_defconfig: disable IDE subsystem
arm: mainstone_defconfig: disable IDE subsystem
arm: shannon_defconfig: disable IDE subsystem
arm: collie_defconfig: convert to use libata PATA drivers
arm: omap1_defconfig: convert to use libata PATA drivers
arm: am200epdkit_defconfig: convert to use libata PATA drivers
arm: corgi_defconfig: convert to use libata PATA drivers
arm: h3600_defconfig: convert to use libata PATA drivers
arm: ixp4xx_defconfig: convert to use libata PATA drivers
arm: jornada720_defconfig: convert to use libata PATA drivers
arm: netwinder_defconfig: convert to use libata PATA drivers
arm: s3c2410_defconfig: convert to use libata PATA drivers
arm: spitz_defconfig: convert to use libata PATA drivers
arch/arm/configs/am200epdkit_defconfig | 5 +++--
arch/arm/configs/assabet_defconfig | 1 -
arch/arm/configs/badge4_defconfig | 2 --
arch/arm/configs/cerfcube_defconfig | 1 -
arch/arm/configs/collie_defconfig | 5 +++--
arch/arm/configs/corgi_defconfig | 7 +++----
arch/arm/configs/h3600_defconfig | 5 +++--
arch/arm/configs/ixp4xx_defconfig | 9 +++++----
arch/arm/configs/jornada720_defconfig | 5 +++--
arch/arm/configs/lart_defconfig | 2 --
arch/arm/configs/mainstone_defconfig | 1 -
arch/arm/configs/netwinder_defconfig | 7 ++++---
arch/arm/configs/omap1_defconfig | 4 ++--
arch/arm/configs/s3c2410_defconfig | 10 +++-------
arch/arm/configs/shannon_defconfig | 1 -
arch/arm/configs/spitz_defconfig | 8 +++-----
16 files changed, 32 insertions(+), 41 deletions(-)
^ permalink raw reply
* [PATCH v3 1/1] ahci: imx: Add imx53 SATA temperature sensor support
From: Fabien Lahoudere @ 2016-10-25 20:08 UTC (permalink / raw)
To: tj
Cc: linux-ide, linux-kernel, rui.zhang, edubezval, Csaba Kertesz,
Fabien Lahoudere
In-Reply-To: <2364981.7VqghJWO9f@amdc3058>
From: Csaba Kertesz <csaba.kertesz@vincit.fi>
Add a hwmon entry to get the temperature from the die of imx53
SATA.
The original patch was made by Richard Zhu for kernel 2.6.x:
ENGR00134041-MX53-Add-the-SATA-AHCI-temperature-monitor.patch
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
---
drivers/ata/ahci_imx.c | 195 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 195 insertions(+)
diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
index 3f3a7db..420f065 100644
--- a/drivers/ata/ahci_imx.c
+++ b/drivers/ata/ahci_imx.c
@@ -26,6 +26,9 @@
#include <linux/mfd/syscon.h>
#include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
#include <linux/libata.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/thermal.h>
#include "ahci.h"
#define DRV_NAME "ahci-imx"
@@ -214,6 +217,180 @@ static int imx_sata_phy_reset(struct ahci_host_priv *hpriv)
return timeout ? 0 : -ETIMEDOUT;
}
+enum {
+ /* SATA PHY Register */
+ SATA_PHY_CR_CLOCK_CRCMP_LT_LIMIT = 0x0001,
+ SATA_PHY_CR_CLOCK_DAC_CTL = 0x0008,
+ SATA_PHY_CR_CLOCK_RTUNE_CTL = 0x0009,
+ SATA_PHY_CR_CLOCK_ADC_OUT = 0x000A,
+ SATA_PHY_CR_CLOCK_MPLL_TST = 0x0017,
+};
+
+static int read_adc_sum(void *dev, u16 rtune_ctl_reg, void __iomem * mmio)
+{
+ u16 adc_out_reg, read_sum;
+ u32 index, read_attempt;
+ const u32 attempt_limit = 100;
+
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
+ imx_phy_reg_write(rtune_ctl_reg, mmio);
+
+ /* two dummy read */
+ index = 0;
+ read_attempt = 0;
+ adc_out_reg = 0;
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_ADC_OUT, mmio);
+ while (index < 2) {
+ imx_phy_reg_read(&adc_out_reg, mmio);
+ /* check if valid */
+ if (adc_out_reg & 0x400)
+ index++;
+
+ read_attempt++;
+ if (read_attempt > attempt_limit) {
+ dev_err(dev, "Read REG more than %d times!\n",
+ attempt_limit);
+ break;
+ }
+ }
+
+ index = 0;
+ read_attempt = 0;
+ read_sum = 0;
+ while (index < 80) {
+ imx_phy_reg_read(&adc_out_reg, mmio);
+ if (adc_out_reg & 0x400) {
+ read_sum = read_sum + (adc_out_reg & 0x3FF);
+ index++;
+ }
+ read_attempt++;
+ if (read_attempt > attempt_limit) {
+ dev_err(dev, "Read REG more than %d times!\n",
+ attempt_limit);
+ break;
+ }
+ }
+
+ /* Use the U32 to make 1000 precision */
+ return (read_sum * 1000) / 80;
+}
+
+/* SATA AHCI temperature monitor */
+static int sata_ahci_read_temperature(void *dev, int *temp)
+{
+ u16 mpll_test_reg, rtune_ctl_reg, dac_ctl_reg, read_sum;
+ u32 str1, str2, str3, str4;
+ int m1, m2, a;
+ struct ahci_host_priv *hpriv = dev_get_drvdata(dev);
+ void __iomem *mmio = hpriv->mmio;
+
+ /* check rd-wr to reg */
+ read_sum = 0;
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_CRCMP_LT_LIMIT, mmio);
+ imx_phy_reg_write(read_sum, mmio);
+ imx_phy_reg_read(&read_sum, mmio);
+ if ((read_sum & 0xffff) != 0)
+ dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+ imx_phy_reg_write(0x5A5A, mmio);
+ imx_phy_reg_read(&read_sum, mmio);
+ if ((read_sum & 0xffff) != 0x5A5A)
+ dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+ imx_phy_reg_write(0x1234, mmio);
+ imx_phy_reg_read(&read_sum, mmio);
+ if ((read_sum & 0xffff) != 0x1234)
+ dev_err(dev, "Read/Write REG error, 0x%x!\n", read_sum);
+
+ /* start temperature test */
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_MPLL_TST, mmio);
+ imx_phy_reg_read(&mpll_test_reg, mmio);
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
+ imx_phy_reg_read(&rtune_ctl_reg, mmio);
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_DAC_CTL, mmio);
+ imx_phy_reg_read(&dac_ctl_reg, mmio);
+
+ /* mpll_tst.meas_iv ([12:2]) */
+ str1 = (mpll_test_reg >> 2) & 0x7FF;
+ /* rtune_ctl.mode ([1:0]) */
+ str2 = (rtune_ctl_reg) & 0x3;
+ /* dac_ctl.dac_mode ([14:12]) */
+ str3 = (dac_ctl_reg >> 12) & 0x7;
+ /* rtune_ctl.sel_atbp ([4]) */
+ str4 = (rtune_ctl_reg >> 4);
+
+ /* Calculate the m1 */
+ /* mpll_tst.meas_iv */
+ mpll_test_reg = (mpll_test_reg & 0xE03) | (512) << 2;
+ /* rtune_ctl.mode */
+ rtune_ctl_reg = (rtune_ctl_reg & 0xFFC) | (1);
+ /* dac_ctl.dac_mode */
+ dac_ctl_reg = (dac_ctl_reg & 0x8FF) | (4) << 12;
+ /* rtune_ctl.sel_atbp */
+ rtune_ctl_reg = (rtune_ctl_reg & 0xFEF) | (0) << 4;
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_MPLL_TST, mmio);
+ imx_phy_reg_write(mpll_test_reg, mmio);
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_DAC_CTL, mmio);
+ imx_phy_reg_write(dac_ctl_reg, mmio);
+ m1 = read_adc_sum(dev, rtune_ctl_reg, mmio);
+
+ /* Calculate the m2 */
+ /* rtune_ctl.sel_atbp */
+ rtune_ctl_reg = (rtune_ctl_reg & 0xFEF) | (1) << 4;
+ m2 = read_adc_sum(dev, rtune_ctl_reg, mmio);
+
+ /* restore the status */
+ /* mpll_tst.meas_iv */
+ mpll_test_reg = (mpll_test_reg & 0xE03) | (str1) << 2;
+ /* rtune_ctl.mode */
+ rtune_ctl_reg = (rtune_ctl_reg & 0xFFC) | (str2);
+ /* dac_ctl.dac_mode */
+ dac_ctl_reg = (dac_ctl_reg & 0x8FF) | (str3) << 12;
+ /* rtune_ctl.sel_atbp */
+ rtune_ctl_reg = (rtune_ctl_reg & 0xFEF) | (str4) << 4;
+
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_MPLL_TST, mmio);
+ imx_phy_reg_write(mpll_test_reg, mmio);
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_DAC_CTL, mmio);
+ imx_phy_reg_write(dac_ctl_reg, mmio);
+ imx_phy_reg_addressing(SATA_PHY_CR_CLOCK_RTUNE_CTL, mmio);
+ imx_phy_reg_write(rtune_ctl_reg, mmio);
+
+ /* Compute temperature */
+ if (!(m2 / 1000))
+ m2 = 1000;
+ a = (m2 - m1) / (m2/1000);
+ *temp = ((-559) * a * a) / 1000 + (1379) * a + (-458000);
+
+ return 0;
+}
+
+static ssize_t sata_ahci_show_temp(struct device *dev,
+ struct device_attribute *da,
+ char *buf)
+{
+ unsigned int temp = 0;
+ int err;
+
+ err = sata_ahci_read_temperature(dev, &temp);
+ if (err < 0)
+ return err;
+
+ return sprintf(buf, "%u\n", temp);
+}
+
+static const struct thermal_zone_of_device_ops fsl_sata_ahci_of_thermal_ops = {
+ .get_temp = sata_ahci_read_temperature,
+};
+
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, sata_ahci_show_temp, NULL, 0);
+
+static struct attribute *fsl_sata_ahci_attrs[] = {
+ &sensor_dev_attr_temp1_input.dev_attr.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(fsl_sata_ahci);
+
static int imx_sata_enable(struct ahci_host_priv *hpriv)
{
struct imx_ahci_priv *imxpriv = hpriv->plat_data;
@@ -597,6 +774,24 @@ static int imx_ahci_probe(struct platform_device *pdev)
if (ret)
return ret;
+ if (imxpriv->type == AHCI_IMX53) {
+ /* Add the temperature monitor */
+ struct device *hwmon_dev;
+
+ hwmon_dev =
+ devm_hwmon_device_register_with_groups(dev,
+ "sata_ahci",
+ hpriv,
+ fsl_sata_ahci_groups);
+ if (IS_ERR(hwmon_dev)) {
+ ret = PTR_ERR(hwmon_dev);
+ goto disable_clk;
+ }
+ devm_thermal_zone_of_sensor_register(hwmon_dev, 0, hwmon_dev,
+ &fsl_sata_ahci_of_thermal_ops);
+ dev_info(dev, "%s: sensor 'sata_ahci'\n", dev_name(hwmon_dev));
+ }
+
ret = imx_sata_enable(hpriv);
if (ret)
goto disable_clk;
--
2.1.4
^ permalink raw reply related
* (unknown),
From: mariobronti @ 2016-10-25 17:17 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: EMAIL_26515359826_linux-ide.zip --]
[-- Type: application/zip, Size: 5747 bytes --]
^ permalink raw reply
* Re: [PATCH] ahci: fix the single MSI-X case in ahci_init_one
From: Tejun Heo @ 2016-10-25 15:43 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-ide, rrichter, ddaney.cavm
In-Reply-To: <1477397074-26799-1-git-send-email-hch@lst.de>
On Tue, Oct 25, 2016 at 02:04:34PM +0200, Christoph Hellwig wrote:
> We need to make sure hpriv->irq is set properly if we don't use per-port
> vectors, so switch from blindly assigning pdev->irq to using
> pci_irq_vector, which handles all interrupt types correctly.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reported-by: Robert Richter <robert.richter@cavium.com>
> Tested-by: Robert Richter <robert.richter@cavium.com>
> Tested-by: David Daney <ddaney.cavm@gmail.com>
> Fixes: 0b9e2988ab22 ("ahci: use pci_alloc_irq_vectors")
Applied to libata/for-4.9-fixes.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] ahci: fix the single MSI-X case in ahci_init_one
From: Christoph Hellwig @ 2016-10-25 12:04 UTC (permalink / raw)
To: tj; +Cc: linux-ide, rrichter, ddaney.cavm
We need to make sure hpriv->irq is set properly if we don't use per-port
vectors, so switch from blindly assigning pdev->irq to using
pci_irq_vector, which handles all interrupt types correctly.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Robert Richter <robert.richter@cavium.com>
Tested-by: Robert Richter <robert.richter@cavium.com>
Tested-by: David Daney <ddaney.cavm@gmail.com>
Fixes: 0b9e2988ab22 ("ahci: use pci_alloc_irq_vectors")
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index ba5f11c..5fe852d 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1617,7 +1617,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
/* legacy intx interrupts */
pci_intx(pdev, 1);
}
- hpriv->irq = pdev->irq;
+ hpriv->irq = pci_irq_vector(pdev, 0);
if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
host->flags |= ATA_HOST_PARALLEL_SCAN;
^ permalink raw reply related
* Re: [PATCH] ahci: use pci_alloc_irq_vectors
From: Robert Richter @ 2016-10-25 9:25 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Robert Richter, Auger Eric, Marc Zyngier, linux-ide,
dan.j.williamps, Tejun Heo, linux-arm-kernel
In-Reply-To: <20161022141123.GA25500@lst.de>
On 22.10.16 16:11:23, Christoph Hellwig wrote:
> Hi Robert,
>
> is this a controller that's using MSI-X?
>
> If so can you try the patch below?
Great, that fixes the issue. Thanks.
Tested-by: Robert Richter <rrichter@cavium.com>
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index ba5f11c..5fe852d 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1617,7 +1617,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> /* legacy intx interrupts */
> pci_intx(pdev, 1);
> }
> - hpriv->irq = pdev->irq;
> + hpriv->irq = pci_irq_vector(pdev, 0);
>
> if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
> host->flags |= ATA_HOST_PARALLEL_SCAN;
^ permalink raw reply
* Re: [PATCH 0/5] ahci: nvme remap support
From: Dan Williams @ 2016-10-24 21:01 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Keith Busch, Tejun Heo, IDE/ATA development list, linux-nvme
In-Reply-To: <20161024175527.GA11088@lst.de>
On Mon, Oct 24, 2016 at 10:55 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Mon, Oct 24, 2016 at 10:46:29AM -0700, Dan Williams wrote:
>> On Mon, Oct 24, 2016 at 8:16 AM, Christoph Hellwig <hch@lst.de> wrote:
>> > On Mon, Oct 24, 2016 at 10:46:29AM -0400, Keith Busch wrote:
>> >> Amber is aware of this and was supportive in having Intel open the
>> >> specs to enable this hardware.
>> >
>> > Ok, let's get the spec out first.
>>
>> The patch contents are it.
>
> Well. that's simply not acceptable. We will need a theory of
> operation for this device to support it, because the patch as-is
> simply doesn't make sense.
The presence of ahci bar remapping is documented here:
http://www.intel.com/content/www/us/en/chipsets/100-series-chipset-datasheet-vol-2.html
The PCI memory space is remapped, the configuration space of the
remapped device is not available, and interrupts are shared.
> We'll also need to know where such device might show up, and why
> Linux support for it matters.
This is a capability of the "Intel® 100 Series Chipset Family". These
patches matter because this chipset in this configuration appears in
laptops that you can buy today and Linux is unable to access the NVMe
device.
>> > Do we expect to be able to use the
>> > AHCI interface and the NVMe interface at the same time?
>>
>> Yes, simultaneous access.
>
> Yikes. I'm really tempted to say this is not acceptable - Intel
> really must know better.
>
Linux users are unable to access storage without these patches.
>> That said, the driver seems to already comprehend instances where the
>> device does not support nvme_reset_subsystem() requests. I don't know
>> how often those resets need to be issued in practice.
>
> It's not about how often reset are needed (and there are controller
> resets in addition to function level resets), but how they are
> defined to work. What state is a controller in after a host initiated
> reset, after a PCIe hotplug or even warm plug. What state is the
> PCI device in when the controller is in a failed state?
Talking with Keith, subsystem-resets are a feature of enterprise-class
NVMe devices. I think those features are out of scope for the class
of devices that will find themselves in a platform with this
configuration, same for hot-plug.
>> > If it's the latter let's keep AHCI entirely out
>> > of the game - add the affected PCI IDs to the NVMe driver itself, add
>> > a quirk for them and implement the enable sequence inside the NVMe
>> > driver.
>>
>> The PCI ID of the AHCI device is not uniquely identifiable when in this mode.
>>
>> We could flip the arrangement and have the ahci device as the platform
>> device, but I'm not sure this makes the nvme reset problem much
>> better. If we allow subsystem resets at all they would still need to
>> be coordinated across 2 devices/drivers to reinitialize pci registers.
>
> I think the simple answer is to not support this device. It's not like
> Intel doesn't know the AHCI and NVMe specs and had any reaoson to come
> up with a piece of junk like this.
Whatever answer we, in the Linux kernel community, come up with,
leaving storage inaccessible is not an acceptable answer.
^ permalink raw reply
* Re: [PATCH] ahci: use pci_alloc_irq_vectors
From: David Daney @ 2016-10-24 20:29 UTC (permalink / raw)
To: Christoph Hellwig, Robert Richter
Cc: Auger Eric, Marc Zyngier, linux-ide, Robert Richter,
dan.j.williamps, Tejun Heo, linux-arm-kernel
In-Reply-To: <20161022141123.GA25500@lst.de>
On 10/22/2016 07:11 AM, Christoph Hellwig wrote:
> Hi Robert,
>
> is this a controller that's using MSI-X?
>
> If so can you try the patch below?
>
After better understanding your request, I applied this against:
http://git.kernel.org/cgit/linux/kernel/git/tj/libata.git/log/?h=for-4.9-fixes
(commit a478b097474cd9f2268ab1beaca74ff09e652b9b)
This is now working on my ThunderX CRB-2S system.
You can add:
Tested-by: David Daney <david.daney@cavium.com>
Thanks for taking the time to work through this.
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index ba5f11c..5fe852d 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1617,7 +1617,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> /* legacy intx interrupts */
> pci_intx(pdev, 1);
> }
> - hpriv->irq = pdev->irq;
> + hpriv->irq = pci_irq_vector(pdev, 0);
>
> if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
> host->flags |= ATA_HOST_PARALLEL_SCAN;
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [PATCH] ahci: use pci_alloc_irq_vectors
From: Christoph Hellwig @ 2016-10-24 19:21 UTC (permalink / raw)
To: David Daney
Cc: Robert Richter, Auger Eric, Marc Zyngier, linux-ide,
Robert Richter, dan.j.williamps, Tejun Heo, Christoph Hellwig,
linux-arm-kernel
In-Reply-To: <580E59AA.60107@gmail.com>
Hi David,
On Mon, Oct 24, 2016 at 11:57:46AM -0700, David Daney wrote:
>> If so can you try the patch below?
>
> I applied it to v4.9-rc1 (really commit
> 6f33d6458e35d6ba53c2635ee4b8a3177cbd912d), and this didn't seem to make it
> work.
Please try on top of the libata for-4.9-fixes branch:
https://git.kernel.org/cgit/linux/kernel/git/tj/libata.git/log/?h=for-4.9-fixes
^ permalink raw reply
* Re: [PATCH] ahci: use pci_alloc_irq_vectors
From: David Daney @ 2016-10-24 18:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Robert Richter, linux-ide, Marc Zyngier, Auger Eric,
Robert Richter, dan.j.williamps, Tejun Heo, linux-arm-kernel
In-Reply-To: <20161022141123.GA25500@lst.de>
Hi Christoph,
I can answer these...
On 10/22/2016 07:11 AM, Christoph Hellwig wrote:
> Hi Robert,
>
> is this a controller that's using MSI-X?
Yes. This is a ThunderX SoC with on-chip AHCI that use MSI-X
>
> If so can you try the patch below?
I applied it to v4.9-rc1 (really commit
6f33d6458e35d6ba53c2635ee4b8a3177cbd912d), and this didn't seem to make
it work.
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index ba5f11c..5fe852d 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1617,7 +1617,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> /* legacy intx interrupts */
> pci_intx(pdev, 1);
> }
> - hpriv->irq = pdev->irq;
> + hpriv->irq = pci_irq_vector(pdev, 0);
>
> if (!(hpriv->cap & HOST_CAP_SSS) || ahci_ignore_sss)
> host->flags |= ATA_HOST_PARALLEL_SCAN;
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [PATCH 0/5] ahci: nvme remap support
From: Christoph Hellwig @ 2016-10-24 18:21 UTC (permalink / raw)
To: Dan Williams
Cc: Christoph Hellwig, Keith Busch, Tejun Heo,
IDE/ATA development list, linux-nvme
In-Reply-To: <CAPcyv4hxxa2FD+kzaDes7FxunwFp=++HiRh=uNMk3W5QWTbHMg@mail.gmail.com>
On Mon, Oct 24, 2016 at 10:57:16AM -0700, Dan Williams wrote:
> ...but it still might be the better way to go. I.e. push the hacks to
> the legacy driver and not burden nvme with this new "nvme_dev_ops"
> concept.
Let's get some coherent text on how this device even operates out
first and then we can decide if and how we can support it.
^ permalink raw reply
* Re: [PATCH 0/5] ahci: nvme remap support
From: Dan Williams @ 2016-10-24 17:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Keith Busch, Tejun Heo, IDE/ATA development list, linux-nvme
In-Reply-To: <CAPcyv4jSx5c3DzEsbfUph5Akk-XyxQ2sXAgmLZfhvGEOUtBqdQ@mail.gmail.com>
On Mon, Oct 24, 2016 at 10:46 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Mon, Oct 24, 2016 at 8:16 AM, Christoph Hellwig <hch@lst.de> wrote:
[..]
>> If it's the latter let's keep AHCI entirely out
>> of the game - add the affected PCI IDs to the NVMe driver itself, add
>> a quirk for them and implement the enable sequence inside the NVMe
>> driver.
>
> The PCI ID of the AHCI device is not uniquely identifiable when in this mode.
>
> We could flip the arrangement and have the ahci device as the platform
> device, but I'm not sure this makes the nvme reset problem much
> better. If we allow subsystem resets at all they would still need to
> be coordinated across 2 devices/drivers to reinitialize pci registers.
...but it still might be the better way to go. I.e. push the hacks to
the legacy driver and not burden nvme with this new "nvme_dev_ops"
concept.
^ permalink raw reply
* Re: [PATCH 0/5] ahci: nvme remap support
From: Christoph Hellwig @ 2016-10-24 17:55 UTC (permalink / raw)
To: Dan Williams
Cc: Christoph Hellwig, Keith Busch, Tejun Heo,
IDE/ATA development list, linux-nvme
In-Reply-To: <CAPcyv4jSx5c3DzEsbfUph5Akk-XyxQ2sXAgmLZfhvGEOUtBqdQ@mail.gmail.com>
On Mon, Oct 24, 2016 at 10:46:29AM -0700, Dan Williams wrote:
> On Mon, Oct 24, 2016 at 8:16 AM, Christoph Hellwig <hch@lst.de> wrote:
> > On Mon, Oct 24, 2016 at 10:46:29AM -0400, Keith Busch wrote:
> >> Amber is aware of this and was supportive in having Intel open the
> >> specs to enable this hardware.
> >
> > Ok, let's get the spec out first.
>
> The patch contents are it.
Well. that's simply not acceptable. We will need a theory of
operation for this device to support it, because the patch as-is
simply doesn't make sense.
We'll also need to know where such device might show up, and why
Linux support for it matters.
> > Do we expect to be able to use the
> > AHCI interface and the NVMe interface at the same time?
>
> Yes, simultaneous access.
Yikes. I'm really tempted to say this is not acceptable - Intel
really must know better.
> That said, the driver seems to already comprehend instances where the
> device does not support nvme_reset_subsystem() requests. I don't know
> how often those resets need to be issued in practice.
It's not about how often reset are needed (and there are controller
resets in addition to function level resets), but how they are
defined to work. What state is a controller in after a host initiated
reset, after a PCIe hotplug or even warm plug. What state is the
PCI device in when the controller is in a failed state?
> > If it's the latter let's keep AHCI entirely out
> > of the game - add the affected PCI IDs to the NVMe driver itself, add
> > a quirk for them and implement the enable sequence inside the NVMe
> > driver.
>
> The PCI ID of the AHCI device is not uniquely identifiable when in this mode.
>
> We could flip the arrangement and have the ahci device as the platform
> device, but I'm not sure this makes the nvme reset problem much
> better. If we allow subsystem resets at all they would still need to
> be coordinated across 2 devices/drivers to reinitialize pci registers.
I think the simple answer is to not support this device. It's not like
Intel doesn't know the AHCI and NVMe specs and had any reaoson to come
up with a piece of junk like this.
^ permalink raw reply
* Re: [PATCH 0/5] ahci: nvme remap support
From: Dan Williams @ 2016-10-24 17:46 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Keith Busch, Tejun Heo, IDE/ATA development list, linux-nvme
In-Reply-To: <20161024151657.GA7080@lst.de>
On Mon, Oct 24, 2016 at 8:16 AM, Christoph Hellwig <hch@lst.de> wrote:
> On Mon, Oct 24, 2016 at 10:46:29AM -0400, Keith Busch wrote:
>> Amber is aware of this and was supportive in having Intel open the
>> specs to enable this hardware.
>
> Ok, let's get the spec out first.
The patch contents are it.
> Do we expect to be able to use the
> AHCI interface and the NVMe interface at the same time?
Yes, simultaneous access.
> If the first is the case I think we are royally screwed and I see no good way to
> support this beast.
I'm new to the NVMe driver and spec so I'll tread carefully here...
Resets do present a problem especially since they are specified to
reset pci registers that we do not have access to read/write.
That said, the driver seems to already comprehend instances where the
device does not support nvme_reset_subsystem() requests. I don't know
how often those resets need to be issued in practice.
> If it's the latter let's keep AHCI entirely out
> of the game - add the affected PCI IDs to the NVMe driver itself, add
> a quirk for them and implement the enable sequence inside the NVMe
> driver.
The PCI ID of the AHCI device is not uniquely identifiable when in this mode.
We could flip the arrangement and have the ahci device as the platform
device, but I'm not sure this makes the nvme reset problem much
better. If we allow subsystem resets at all they would still need to
be coordinated across 2 devices/drivers to reinitialize pci registers.
^ permalink raw reply
* Re: [PATCH 0/5] ahci: nvme remap support
From: Christoph Hellwig @ 2016-10-24 15:16 UTC (permalink / raw)
To: Keith Busch
Cc: Christoph Hellwig, Dan Williams, Tejun Heo,
IDE/ATA development list, linux-nvme
In-Reply-To: <20161024144628.GC8633@localhost.localdomain>
On Mon, Oct 24, 2016 at 10:46:29AM -0400, Keith Busch wrote:
> Amber is aware of this and was supportive in having Intel open the
> specs to enable this hardware.
Ok, let's get the spec out first. Do we expect to be able to use the
AHCI interface and the NVMe interface at the same time? If the first
is the case I think we are royally screwed and I see no good way to
support this beast. If it's the latter let's keep AHCI entirely out
of the game - add the affected PCI IDs to the NVMe driver itself, add
a quirk for them and implement the enable sequence inside the NVMe
driver.
> The nvme driver has weird hooks to support the non-standard open channel
> effort, and we let Apple dictate this driver can't have q-word access.
> This remapping isn't exactly the first time we're helping non-standard
> devices, and Dan's series looks isolated such that it won't harm
> compliant ones.
But it's the worst kind. Open Channel is a bit of an oddball, but it
sits on top of the transport, the rest is minor workaround conditionalal
on PCI IDs.
^ permalink raw reply
* Re: [PATCH 0/5] ahci: nvme remap support
From: Keith Busch @ 2016-10-24 14:46 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dan Williams, Tejun Heo, IDE/ATA development list, linux-nvme
In-Reply-To: <20161024124938.GB2389@lst.de>
On Mon, Oct 24, 2016 at 02:49:38PM +0200, Christoph Hellwig wrote:
> But this has a profound effect on the NVMe operation, because fo
> example the NVMe reset cycle is tied into PCIe function states.
>
> Please bring this issue up with the relevant standards comittee first,
> otherwise we're getting us into a nightmare of undefined behavior here.
>
> And it's not like Intel isn't active in this group. I'd suggest you
> talk to Amber who is the editor for both the AHCI and NVMe spec,
> that should get you started.
Amber is aware of this and was supportive in having Intel open the
specs to enable this hardware.
The nvme driver has weird hooks to support the non-standard open channel
effort, and we let Apple dictate this driver can't have q-word access.
This remapping isn't exactly the first time we're helping non-standard
devices, and Dan's series looks isolated such that it won't harm
compliant ones.
Dan,
I take it you have access to this platform. Would you be able verify if
it can successfully resume from S3 and S4?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox