* Re: [PATCH 1/3 v2] ahci: qoriq: added a condition to enable dma coherence
From: Tejun Heo @ 2017-01-20 13:34 UTC (permalink / raw)
To: yuantian.tang
Cc: mark.rutland, devicetree, mathieu.poirier, linux-kernel,
linux-ide, robh+dt, robin.murphy, linux-arm-kernel
In-Reply-To: <1484895576-40379-1-git-send-email-yuantian.tang@nxp.com>
On Fri, Jan 20, 2017 at 02:59:34PM +0800, yuantian.tang@nxp.com wrote:
> From: Tang Yuantian <Yuantian.Tang@nxp.com>
>
> Enable DMA coherence in SATA controller on condition that
> dma-coherent property exists in sata node in DTS.
>
> Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
Applied to libata/for-4.11.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v5 00/14] ARM: da850-lcdk: add SATA support
From: Sekhar Nori @ 2017-01-20 13:56 UTC (permalink / raw)
To: Tejun Heo, Bartosz Golaszewski
Cc: Mark Rutland, devicetree, David Lechner, Kevin Hilman,
Michael Turquette, Russell King, linux-kernel, linux-ide,
Rob Herring, Patrick Titiano, linux-arm-kernel
In-Reply-To: <20170120132843.GA31487@mtj.duckdns.org>
Hi Tejun,
On Friday 20 January 2017 06:58 PM, Tejun Heo wrote:
> On Fri, Jan 20, 2017 at 12:21:51PM +0100, Bartosz Golaszewski wrote:
>> This series contains all the changes necessary to make SATA work on
>> the da850-lcdk board.
>>
>> The first patch adds DT bindings for the ahci-da850 driver.
>>
>> The second enables relevant modules in davinci_all_defconfig.
>>
>> Patches 03/14-06/14 modify the way the clocks are handled regarding
>> SATA on the da850 platform. We modify the ahci driver to retrieve
>> the clock via con_id and model the external SATA oscillator as
>> a real clock.
>>
>> Patches 07/14-11/14 extend the ahci-da850 driver. Add DT support,
>> implement workarounds necessary to make SATA work on the da850-lcdk
>> board and un-hardcode the external clock multiplier.
>
> Please feel free to add
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> to the all libata patches. Please let me know how the patches should
> be routed once other parts are settled.
I believe you can queue the libata patches independently (patches 1, 4,
7, 8, 9, 10, 11). It looks like they have been written such that driver
continues to work with existing platform code (Bartosz, please disagree
if I am wrong). 1/14 still needs the ack from DT maintainers.
I would like to queue the platform parts (rest of the patches) through
ARM-SoC since they will likely clash with code I have queued.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v5 00/14] ARM: da850-lcdk: add SATA support
From: Bartosz Golaszewski @ 2017-01-20 14:02 UTC (permalink / raw)
To: Sekhar Nori
Cc: Mark Rutland, linux-devicetree, David Lechner, Kevin Hilman,
Michael Turquette, Russell King, LKML, linux-ide, Rob Herring,
Patrick Titiano, Tejun Heo, arm-soc
In-Reply-To: <86bcbb3c-87e4-3508-f4a6-26529f39d374@ti.com>
2017-01-20 14:56 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> Hi Tejun,
>
> On Friday 20 January 2017 06:58 PM, Tejun Heo wrote:
>> On Fri, Jan 20, 2017 at 12:21:51PM +0100, Bartosz Golaszewski wrote:
>>> This series contains all the changes necessary to make SATA work on
>>> the da850-lcdk board.
>>>
>>> The first patch adds DT bindings for the ahci-da850 driver.
>>>
>>> The second enables relevant modules in davinci_all_defconfig.
>>>
>>> Patches 03/14-06/14 modify the way the clocks are handled regarding
>>> SATA on the da850 platform. We modify the ahci driver to retrieve
>>> the clock via con_id and model the external SATA oscillator as
>>> a real clock.
>>>
>>> Patches 07/14-11/14 extend the ahci-da850 driver. Add DT support,
>>> implement workarounds necessary to make SATA work on the da850-lcdk
>>> board and un-hardcode the external clock multiplier.
>>
>> Please feel free to add
>>
>> Acked-by: Tejun Heo <tj@kernel.org>
>>
>> to the all libata patches. Please let me know how the patches should
>> be routed once other parts are settled.
>
> I believe you can queue the libata patches independently (patches 1, 4,
> 7, 8, 9, 10, 11). It looks like they have been written such that driver
> continues to work with existing platform code (Bartosz, please disagree
> if I am wrong). 1/14 still needs the ack from DT maintainers.
>
Patch 11/14 depends on 06/14. Other than that I think it should work
independently.
Thanks,
Bartosz
^ permalink raw reply
* Re: [PATCH v5 00/14] ARM: da850-lcdk: add SATA support
From: Sekhar Nori @ 2017-01-20 14:22 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Tejun Heo, Kevin Hilman, Patrick Titiano, Michael Turquette,
Rob Herring, Mark Rutland, Russell King, David Lechner, linux-ide,
linux-devicetree, LKML, arm-soc, Olof Johansson, Arnd Bergmann
In-Reply-To: <CAMpxmJUPh9MZKwG6k6p_mo6niXNNT02JCDgXi4DPRH2Fk3yxng@mail.gmail.com>
On Friday 20 January 2017 07:32 PM, Bartosz Golaszewski wrote:
> 2017-01-20 14:56 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
>> Hi Tejun,
>>
>> On Friday 20 January 2017 06:58 PM, Tejun Heo wrote:
>>> On Fri, Jan 20, 2017 at 12:21:51PM +0100, Bartosz Golaszewski wrote:
>>>> This series contains all the changes necessary to make SATA work on
>>>> the da850-lcdk board.
>>>>
>>>> The first patch adds DT bindings for the ahci-da850 driver.
>>>>
>>>> The second enables relevant modules in davinci_all_defconfig.
>>>>
>>>> Patches 03/14-06/14 modify the way the clocks are handled regarding
>>>> SATA on the da850 platform. We modify the ahci driver to retrieve
>>>> the clock via con_id and model the external SATA oscillator as
>>>> a real clock.
>>>>
>>>> Patches 07/14-11/14 extend the ahci-da850 driver. Add DT support,
>>>> implement workarounds necessary to make SATA work on the da850-lcdk
>>>> board and un-hardcode the external clock multiplier.
>>>
>>> Please feel free to add
>>>
>>> Acked-by: Tejun Heo <tj@kernel.org>
>>>
>>> to the all libata patches. Please let me know how the patches should
>>> be routed once other parts are settled.
>>
>> I believe you can queue the libata patches independently (patches 1, 4,
>> 7, 8, 9, 10, 11). It looks like they have been written such that driver
>> continues to work with existing platform code (Bartosz, please disagree
>> if I am wrong). 1/14 still needs the ack from DT maintainers.
>>
>
> Patch 11/14 depends on 06/14. Other than that I think it should work
> independently.
Ah, right. You recently changed 11/14 to error out in case refclkpn is
not found instead of using a default value (do agree that current
version is better).
If there are no build time dependencies still, it might be okay to queue
these patches through their respective maintainer trees.
Tejun, I am open to queuing the driver changes through ARM-SoC. I guess
with that there is little chance that SATA will be broken on linux-next
for a longish period of time.
I have Cced the ARM-SoC maintainers too.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v5 00/14] ARM: da850-lcdk: add SATA support
From: Tejun Heo @ 2017-01-20 15:00 UTC (permalink / raw)
To: Sekhar Nori
Cc: Bartosz Golaszewski, Kevin Hilman, Patrick Titiano,
Michael Turquette, Rob Herring, Mark Rutland, Russell King,
David Lechner, linux-ide-u79uwXL29TY76Z2rM5mHXA, linux-devicetree,
LKML, arm-soc, Olof Johansson, Arnd Bergmann
In-Reply-To: <f9055043-507f-74de-b2b8-9eb0eae5dad6-l0cyMroinI0@public.gmane.org>
Hello, Sekhar.
On Fri, Jan 20, 2017 at 07:52:35PM +0530, Sekhar Nori wrote:
> Tejun, I am open to queuing the driver changes through ARM-SoC. I guess
> with that there is little chance that SATA will be broken on linux-next
> for a longish period of time.
Yeah, I'd prefer the patchset staying together. That's how it was
developed and tested. Don't wanna break it apart unnecessarily. The
chance for conflicts is low and even when that happens dealing with
them is pretty easy. Please feel free to add my acked-by and route
the patches through ARM-SoC.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: tedheadster @ 2017-01-20 17:08 UTC (permalink / raw)
To: Tejun Heo
Cc: One Thousand Gnomes, Greg Kroah-Hartman, Sergei Shtylyov,
linux-ide
In-Reply-To: <20170119213737.GB25133@mtj.duckdns.org>
Tejun,
here is the relevant output:
[ 39.868755] XXX kobject_get(pata_legacy.0): ref=3++
(ata_tport_add:ata_host_register:ata_host_activate)
[ 39.875762] XXX kobject_get(pata_legacy.0): ref=4++
(ata_tport_add:ata_host_register:ata_host_activate)
[ 39.877885] XXX kobject_get(pata_legacy.0): ref=5++
(kobject_add:device_add:ata_tport_add)
[ 39.971742] scsi host0: pata_legacy
[ 39.999736] ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14
[ 40.157745] ata1.00: ATA-4: QUANTUM FIREBALL CR8.4A, A5U.1200, max UDMA/66
[ 40.159149] ata1.00: 16514064 sectors, multi 0: LBA
[ 40.160111] ata1.00: configured for PIO
[ 40.236700] scsi 0:0:0:0: Direct-Access ATA QUANTUM
FIREBALL 1200 PQ: 0 ANSI: 5
[ 40.337686] sd 0:0:0:0: [sda] 16514064 512-byte logical blocks:
(8.46 GB/7.87 GiB)
[ 40.346688] sd 0:0:0:0: [sda] Write Protect is off
[ 40.348681] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 40.365678] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 40.367688] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 40.540654] sda: sda1 sda2 sda3 sda4
[ 40.916596] sd 0:0:0:0: [sda] Attached SCSI disk
[ 40.956594] XXX kobject_get(pata_legacy.1): ref=3++
(ata_tport_add:ata_host_register:ata_host_activate)
[ 40.968587] XXX kobject_get(pata_legacy.1): ref=4++
(ata_tport_add:ata_host_register:ata_host_activate)
[ 40.971139] XXX kobject_get(pata_legacy.1): ref=5++
(kobject_add:device_add:ata_tport_add)
[ 41.152561] scsi host1: pata_legacy
[ 41.227549] ata2: PATA max PIO4 cmd 0x170 ctl 0x376 irq 15
[ 41.690486] XXX kobject_put(pata_legacy.1): ref=6--
(device_del:ata_tport_delete:ata_host_detach)
[ 41.692548] XXX kobject_put(pata_legacy.1): ref=5--
(ata_tport_delete:ata_host_detach:legacy_init [pata_legacy])
[ 41.719476] XXX kobject_put(pata_legacy.1): ref=4--
(klist_put:klist_del:device_del)
[ 41.725471] XXX kobject_put(pata_legacy.1): ref=3--
(klist_devices_put:klist_put:klist_del)
[ 41.745472] XXX kobject_put(pata_legacy.1): ref=2--
(platform_device_unregister:legacy_init [pata_legacy]:do_one_initcall)
[ 41.793466] XXX kobject_get(pata_legacy.2): ref=3++
(ata_tport_add:ata_host_register:ata_host_activate)
[ 41.807475] XXX kobject_get(pata_legacy.2): ref=4++
(ata_tport_add:ata_host_register:ata_host_activate)
[ 41.809848] XXX kobject_get(pata_legacy.2): ref=5++
(kobject_add:device_add:ata_tport_add)
[ 41.991431] scsi host2: pata_legacy
[ 42.036428] ata3: PATA max PIO4 cmd 0x1e8 ctl 0x3ee irq 11
[ 42.357388] XXX kobject_put(pata_legacy.2): ref=6--
(device_del:ata_tport_delete:ata_host_detach)
[ 42.359786] XXX kobject_put(pata_legacy.2): ref=5--
(ata_tport_delete:ata_host_detach:legacy_init [pata_legacy])
[ 42.447367] XXX kobject_put(pata_legacy.2): ref=4--
(klist_put:klist_del:device_del)
[ 42.470362] XXX kobject_put(pata_legacy.2): ref=3--
(klist_devices_put:klist_put:klist_del)
[ 42.510357] XXX kobject_put(pata_legacy.2): ref=2--
(platform_device_unregister:legacy_init [pata_legacy]:do_one_initcall)
[ 42.583346] XXX kobject_get(pata_legacy.3): ref=3++
(ata_tport_add:ata_host_register:ata_host_activate)
[ 42.592340] XXX kobject_get(pata_legacy.3): ref=4++
(ata_tport_add:ata_host_register:ata_host_activate)
[ 42.594415] XXX kobject_get(pata_legacy.3): ref=5++
(kobject_add:device_add:ata_tport_add)
[ 42.815304] scsi host3: pata_legacy
[ 42.881302] ata4: PATA max PIO4 cmd 0x168 ctl 0x36e irq 10
[ 43.292234] XXX kobject_put(pata_legacy.3): ref=6--
(device_del:ata_tport_delete:ata_host_detach)
[ 43.294228] XXX kobject_put(pata_legacy.3): ref=5--
(ata_tport_delete:ata_host_detach:legacy_init [pata_legacy])
[ 43.340228] XXX kobject_put(pata_legacy.3): ref=4--
(klist_put:klist_del:device_del)
[ 43.370225] XXX kobject_put(pata_legacy.3): ref=3--
(klist_devices_put:klist_put:klist_del)
[ 43.411220] XXX kobject_put(pata_legacy.3): ref=2--
(platform_device_unregister:legacy_init [pata_legacy]:do_one_initcall)
[ 43.599193] genirq: Flags mismatch irq 8. 00000000
(platform[pata_legacy.4]) vs. 00000080 (rtc0)
[ 43.645179] XXX kobject_put(pata_legacy.4): ref=3--
(klist_put:klist_del:device_del)
[ 43.685178] XXX kobject_put(pata_legacy.4): ref=2--
(klist_devices_put:klist_put:klist_del)
[ 43.733174] XXX kobject_put(pata_legacy.4): ref=1--
(platform_device_unregister:legacy_init [pata_legacy]:do_one_initcall)
[ 43.736259] XXX kobject_cleanup(pata_legacy.4): rel=device_release
(put_device:platform_device_unregister:legacy_init [pata_legacy])
[ 43.738417] platform pata_legacy.4: XXX device_release:
drel=platform_device_release trel= (null) cdrel= (null)
[ 43.740160] platform pata_legacy.4: XXX device_release:
devres_release_all() done
[ 43.950138] XXX kobject_get(pata_legacy.5): ref=3++
(ata_tport_add:ata_host_register:ata_host_activate)
[ 43.973137] XXX kobject_get(pata_legacy.5): ref=4++
(ata_tport_add:ata_host_register:ata_host_activate)
[ 43.975360] XXX kobject_get(pata_legacy.5): ref=5++
(kobject_add:device_add:ata_tport_add)
[ 44.338072] scsi host4: pata_legacy
[ 44.389071] ata5: PATA max PIO4 cmd 0x160 ctl 0x366 irq 12
[ 44.699020] XXX kobject_put(pata_legacy.5): ref=6--
(device_del:ata_tport_delete:ata_host_detach)
[ 44.701270] XXX kobject_put(pata_legacy.5): ref=5--
(ata_tport_delete:ata_host_detach:legacy_init [pata_legacy])
[ 44.714021] XXX kobject_put(pata_legacy.5): ref=4--
(klist_put:klist_del:device_del)
[ 44.731015] XXX kobject_put(pata_legacy.5): ref=3--
(klist_devices_put:klist_put:klist_del)
[ 44.750009] XXX kobject_put(pata_legacy.5): ref=2--
(platform_device_unregister:legacy_init [pata_legacy]:do_one_initcall)
...
[ 252.348369] genirq: Flags mismatch irq 10. 00000000 (3c515) vs.
00000000 (platform[pata_legacy.3])
[ 252.379341] genirq: Flags mismatch irq 10. 00000000 (3c515) vs.
00000000 (platform[pata_legacy.3])
- Matthew
^ permalink raw reply
* [PATCH] libata-sff: Don't scan disabled ports when checking for legacy mode.
From: Darren Stevens @ 2017-01-20 17:58 UTC (permalink / raw)
To: linux-ide
libata-sff.c checks for legacy mode by testing if both primary
and secondary ports on a controller are in legacy mode and selects
legacy if either one is. However on some southbridge chips (e.g
AMD SB600/SB700) the secondary port is not wired, and when it is
disabled by setting the disable bit in the PCI header it appears
as a fixed legacy port.
Prevent incorrect detection by not testing ports that are marked
as 'dummy'
Signed-off-by: Darren Stevens <darren@stevens-zone.net>
---
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 051b615..05f688a 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -2429,9 +2429,16 @@ int ata_pci_sff_activate_host(struct ata_host *host,
if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
u8 tmp8, mask;
- /* TODO: What if one channel is in native mode ... */
+ /*
+ * ATA spec says we should use legacy mode when one
+ * port is in legacy mode, but disabled ports on some
+ * PCI hosts appear as fixed legacy ports, e.g SB600/700
+ * on which the secondary port is not wired, so
+ * ignore ports that we've marked as 'dummy' during
+ * this check
+ */
pci_read_config_byte(pdev, PCI_CLASS_PROG, &tmp8);
- mask = (1 << 2) | (1 << 0);
+ mask = (! ata_port_is_dummy(host->ports[1]) << 2) | (!
ata_port_is_dummy(host->ports[0]) << 0);
if ((tmp8 & mask) != mask)
legacy_mode = 1;
}
^ permalink raw reply related
* [PATCH] libata:pata_atiixp: Don't use unconnected secondary port on SB600/SB700
From: Darren Stevens @ 2017-01-20 18:03 UTC (permalink / raw)
To: linux-ide
The SB600 and SB700 southbridge chips from ATI/AMD only have
connections for the primary IDE port. As these chips have unique
pci device ID's use these to mark the secondary port as 'dummy'
Signed-off-by: Darren Stevens <darren@stevens-zone.net>
---
diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
index 49d705c..588c473 100644
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -278,6 +278,11 @@ static int atiixp_init_one(struct pci_dev *pdev, const
struct pci_device_id *id)
};
const struct ata_port_info *ppi[] = { &info, &info };
+ if((pdev->device == PCI_DEVICE_ID_ATI_IXP600_IDE) ||
+ (pdev->device == PCI_DEVICE_ID_ATI_IXP700_IDE))
+ /* SB600/700 don't have secondary port wired */
+ ppi[1] = &ata_dummy_port_info;
+
return ata_pci_bmdma_init_one(pdev, ppi, &atiixp_sht, NULL,
ATA_HOST_PARALLEL_SCAN);
}
^ permalink raw reply related
* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: Tejun Heo @ 2017-01-20 19:19 UTC (permalink / raw)
To: whiteheadm
Cc: One Thousand Gnomes, Greg Kroah-Hartman, Sergei Shtylyov,
linux-ide
In-Reply-To: <CAP8WD_Y1HmuMots4HcQ06gQfs0fCh1W_y=Qa0As3MX1YA+LEKg@mail.gmail.com>
Hello,
Thanks for testing.
On Fri, Jan 20, 2017 at 12:08:10PM -0500, tedheadster wrote:
> kobject_get(pata_legacy.1): ref=3++ (ata_tport_add:ata_host_register:ata_host_activate)
> kobject_get(pata_legacy.1): ref=4++ (ata_tport_add:ata_host_register:ata_host_activate)
> XXX kobject_get(pata_legacy.1): ref=5++ (kobject_add:device_add:ata_tport_add)
> XXX kobject_put(pata_legacy.1): ref=6-- (device_del:ata_tport_delete:ata_host_detach)
> XXX kobject_put(pata_legacy.1): ref=5-- (ata_tport_delete:ata_host_detach:legacy_init [pata_legacy])
> XXX kobject_put(pata_legacy.1): ref=4-- (klist_put:klist_del:device_del)
> XXX kobject_put(pata_legacy.1): ref=3-- (klist_devices_put:klist_put:klist_del)
> XXX kobject_put(pata_legacy.1): ref=2-- (platform_device_unregister:legacy_init [pata_legacy]:do_one_initcall)
So, three gets from the transport path but only two puts. That seems
to be the culprit. Looking into it.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: Tejun Heo @ 2017-01-20 19:38 UTC (permalink / raw)
To: gwendal
Cc: One Thousand Gnomes, Greg Kroah-Hartman, Sergei Shtylyov,
linux-ide, whiteheadm
In-Reply-To: <20170120191946.GA9280@mtj.duckdns.org>
Hello, Gwendal.
On Fri, Jan 20, 2017 at 02:19:46PM -0500, Tejun Heo wrote:
> On Fri, Jan 20, 2017 at 12:08:10PM -0500, tedheadster wrote:
> > kobject_get(pata_legacy.1): ref=3++ (ata_tport_add:ata_host_register:ata_host_activate)
> > kobject_get(pata_legacy.1): ref=4++ (ata_tport_add:ata_host_register:ata_host_activate)
> > XXX kobject_get(pata_legacy.1): ref=5++ (kobject_add:device_add:ata_tport_add)
> > XXX kobject_put(pata_legacy.1): ref=6-- (device_del:ata_tport_delete:ata_host_detach)
> > XXX kobject_put(pata_legacy.1): ref=5-- (ata_tport_delete:ata_host_detach:legacy_init [pata_legacy])
> > XXX kobject_put(pata_legacy.1): ref=4-- (klist_put:klist_del:device_del)
> > XXX kobject_put(pata_legacy.1): ref=3-- (klist_devices_put:klist_put:klist_del)
> > XXX kobject_put(pata_legacy.1): ref=2-- (platform_device_unregister:legacy_init [pata_legacy]:do_one_initcall)
>
> So, three gets from the transport path but only two puts. That seems
> to be the culprit. Looking into it.
So, Matthew discovered that pata_legacy isn't releasing resources
after probe failure. After some debugging, it turns out that the
transport code is taking three refs but only putting two preventing
the ata port from going away.
Can you please explain why the libata transport code is explicitly
pinning the parent device and then putting it in the release methods?
device_add/del() already gets and puts the parent, so I don't get why
this part is necessary. Is this intentional?
Also, it looks like there is a ref leak on the transport device
itself. Its release function never gets called and thus the parent
device (ata_port) stays pinned too.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] libata:pata_atiixp: Don't use unconnected secondary port on SB600/SB700
From: Tejun Heo @ 2017-01-20 20:40 UTC (permalink / raw)
To: Darren Stevens; +Cc: linux-ide
In-Reply-To: <497611d4655.7b408682@auth.smtp.1and1.co.uk>
Hello, Darren.
On Fri, Jan 20, 2017 at 06:03:32PM +0000, Darren Stevens wrote:
> The SB600 and SB700 southbridge chips from ATI/AMD only have
> connections for the primary IDE port. As these chips have unique
> pci device ID's use these to mark the secondary port as 'dummy'
>
> Signed-off-by: Darren Stevens <darren@stevens-zone.net>
> ---
>
> diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
> index 49d705c..588c473 100644
> --- a/drivers/ata/pata_atiixp.c
> +++ b/drivers/ata/pata_atiixp.c
> @@ -278,6 +278,11 @@ static int atiixp_init_one(struct pci_dev *pdev, const
> struct pci_device_id *id)
> };
> const struct ata_port_info *ppi[] = { &info, &info };
>
> + if((pdev->device == PCI_DEVICE_ID_ATI_IXP600_IDE) ||
^
space here
> + (pdev->device == PCI_DEVICE_ID_ATI_IXP700_IDE))
> + /* SB600/700 don't have secondary port wired */
Can you move the comment above if?
> + ppi[1] = &ata_dummy_port_info;
> +
> return ata_pci_bmdma_init_one(pdev, ppi, &atiixp_sht, NULL,
> ATA_HOST_PARALLEL_SCAN);
And the patch is corrupt. Attaching the formatted patch might work
better.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] libata-sff: Don't scan disabled ports when checking for legacy mode.
From: Tejun Heo @ 2017-01-20 20:41 UTC (permalink / raw)
To: Darren Stevens; +Cc: linux-ide
In-Reply-To: <497610a8448.441e0a10@auth.smtp.1and1.co.uk>
Hello,
On Fri, Jan 20, 2017 at 05:58:21PM +0000, Darren Stevens wrote:
> @@ -2429,9 +2429,16 @@ int ata_pci_sff_activate_host(struct ata_host *host,
> if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> u8 tmp8, mask;
>
> - /* TODO: What if one channel is in native mode ... */
> + /*
> + * ATA spec says we should use legacy mode when one
> + * port is in legacy mode, but disabled ports on some
> + * PCI hosts appear as fixed legacy ports, e.g SB600/700
> + * on which the secondary port is not wired, so
> + * ignore ports that we've marked as 'dummy' during
> + * this check
> + */
> pci_read_config_byte(pdev, PCI_CLASS_PROG, &tmp8);
> - mask = (1 << 2) | (1 << 0);
> + mask = (! ata_port_is_dummy(host->ports[1]) << 2) | (!
> ata_port_is_dummy(host->ports[0]) << 0);
The patch is damaged and maybe just using two if statements would read
easier?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support
From: Finn Thain @ 2017-01-21 7:37 UTC (permalink / raw)
To: Michael Schmitz
Cc: Bartlomiej Zolnierkiewicz, Tejun Heo, Geert Uytterhoeven,
linux-ide, Linux/m68k, Linux Kernel Development, Andreas Schwab
In-Reply-To: <b1b409e0-9243-83a6-8379-50f933c97477@gmail.com>
On Fri, 20 Jan 2017, Michael Schmitz wrote:
> Am 15.01.2017 um 17:42 schrieb Finn Thain:
>
> >> No, we can't check either FDC or SCSI interrupts (or indeed any chip
> >> registers) without touching the ST-DMA. The moment we select a FDC or
> >> SCSI register for read, DMA is terminated no questions asked.
> >>
> >
> > Perhaps we can convert DMA operations to PDMA (by polling with local
> > irqs disabled) and avoid the whole problem of interrupt handlers
> > executing during DMA transfers. The docs suggest that it is doable.
> >
> > "Poll or service the Disk Driver Controller interrupt on the MK68901
> > MFP General Purpose I/O Register to detect the completion of a WD1772
> > FDC command. Do not poll the FDC Busy or DMA Sector Count Zero status
> > bits." -- ST HW Spec, p. 36.
> > http://dev-docs.atariforge.org/files/ST_HW_Spec_1-7-1986.pdf
>
> The MFP interrupt in question is the same as the one used by IDE
> (wired-OR of IDE, FDC and SCSI), so we would still have to figure out
> where the interrupt originated.
I thought you said the driver you're testing does not use any interrupt --
I was assuming that only atari_scsi and ataflop drivers share the
interupt.
> Polling instead of taking the interrupt does not change that fundamental
> problem (unless I'm missing something).
>
Actually, the fundamental problem you are describing is partly solved. By
polling for DMA completion with local irqs disabled, we mostly avoid the
need for the stdma.c "lock" because FDC/SCSI/IDE interrupt handlers can
never interfere with a FDC/SCSI DMA process that might be underway.
> >
> > On page 18 there is an algorithm for floppy writes which is
> > interesting.
>
> That one (and the ACSI algorithm which would apply to SCSI for Falcon)
> does suggest it won't be possible to peek at the sector count register
> to detect end of DMA. The addendum (note 841017G) makes it clear that a
> write to the DMA mode register is required to look at the status
> register error bit (which might terminate DMA).
>
> Maybe the DMA address register can be used to check for DMA completion
> ... it's used to check for residual or lost bytes anyway so that appears
> to work. And the FDC driver does use the same strategy to check if
> enough track data have been read.
>
> Leaves the case where DMA hasn't completed but may have been aborted by
> a NCR5380 interrupt. I suppose we can detect that by checking for any
> change in the DMA address while repeatedly reading the DMA address
> register. No change means the DMA has got stuck. Not exactly pretty but
> all I can come up with.
>
We don't have to poll any DMA registers (and I don't believe that it is
viable to do so). I was talking about polling for end of DMA by polling
for the interrupt (as per docs) but with local irqs disabled for the
duration of the transfer (which provides exlusive access to the DMA chip).
> >
> > I suspect that we will need to keep the FDC idle during SCSI transfers
> > (and vice versa) much as the present stdma.c lock does.
> >
> > "The interrupt outputs of the internal floppy disk controller and the
> > external ACSI DMA port are logically OR'ed. The pin of the MFP GPIP
> > will read as a '0' if either the FDC or a selected ACSI device
> > controller is asserting its interrupt request." -- ACSI/DMA
> > Integration Guide, p.16.
> > http://dev-docs.atariforge.org/files/ACSI_DMA_Guide_6-28-1991.pdf
>
> On Falcon, the IDE interrupt is also OR'ed to the above two interrupt
> lines, hence the need for including IDE in the locking scheme there.
>
I don't think the IDE/ATA driver needs to be included. atari_scsi and
ataflop would though (if both drivers need DMA transfers).
> >
> > Polling the logically OR'ed interrupt sources to detect end-of-DMA
> > will not be reliable unless we disable those sources that aren't
> > relevant. Otherwise we access the DMA registers too early (which IIUC
> > would kill the transfer). I'm afraid we shall have to expect that a
> > few transfers will be interrupted by other devices in this way, and
> > carefully check for this.
> >
> > For example, the 5380 SCSI bus reset interrupt is not maskable, which
> > could affect FDC transfers. If this terminated the polling for DMA
> > completion, the FDC driver then has to access the FDC registers and
> > confirm that the transfer was not terminated early.
> >
>
> We'll have to make sure FDC and SCSI don't clash in their DMA and
> interrupt use.
>
The point I was trying to make above is that stdma lock only gets you so
far: if SCSI or FDC generate an interrupt that can't be disabled, it could
mess up the interrupt polling (and the interrupt polling is a necessary
consequence of IDE operating without stdma lock). This would lead to a
short transfer (which could be easily detected).
So the chips clash in their interrupt line use (rarely). The drivers need
not clash at all.
Anyway, we seem to be talking past each other somewhat. I suggest we start
coding and discuss actual patches ... unless you can convince me that this
won't work ...
--
> Cheers,
>
> Michael
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v2] libata:pata_atiixp: Don't use unconnected secondary port on SB600/SB700
From: Darren Stevens @ 2017-01-22 19:37 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: Type: text/plain, Size: 178 bytes --]
AmigaOS...........: http://yam.ch/
Unix/MacOS/Windows: http://www.mozilla.com/thunderbird/
General information about MIME can be found at:
http://en.wikipedia.org/wiki/MIME
[-- Attachment #2: Type: text/plain, Size: 319 bytes --]
The SB600 and SB700 southbridge chips from ATI/AMD only have
connections for the primary IDE port. As these chips have unique
pci device ID's use these to mark the secondary port as 'dummy'
Signed-off-by: Darren Stevens <darren@stevens-zone.net>
---
v2: Moved comment to a more sensible place. No functional changes.
[-- Attachment #3: ati_ata.patch --]
[-- Type: text/plain, Size: 620 bytes --]
diff --git a/drivers/ata/pata_atiixp.c b/drivers/ata/pata_atiixp.c
index 49d705c..83c158b 100644
--- a/drivers/ata/pata_atiixp.c
+++ b/drivers/ata/pata_atiixp.c
@@ -278,6 +278,11 @@ static int atiixp_init_one(struct pci_dev *pdev, const struct pci_device_id *id)
};
const struct ata_port_info *ppi[] = { &info, &info };
+ /* SB600/700 don't have secondary port wired */
+ if ((pdev->device == PCI_DEVICE_ID_ATI_IXP600_IDE) ||
+ (pdev->device == PCI_DEVICE_ID_ATI_IXP700_IDE))
+ ppi[1] = &ata_dummy_port_info;
+
return ata_pci_bmdma_init_one(pdev, ppi, &atiixp_sht, NULL,
ATA_HOST_PARALLEL_SCAN);
}
^ permalink raw reply related
* [PATCH v2] libata-sff: Don't scan disabled ports when checking for legacy mode.
From: Darren Stevens @ 2017-01-22 19:34 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: Type: text/plain, Size: 178 bytes --]
AmigaOS...........: http://yam.ch/
Unix/MacOS/Windows: http://www.mozilla.com/thunderbird/
General information about MIME can be found at:
http://en.wikipedia.org/wiki/MIME
[-- Attachment #2: Type: text/plain, Size: 549 bytes --]
libata-sff.c checks for legacy mode by testing if both primary
and secondary ports on a controller are in legacy mode and selects
legacy if either one is. However on some southbridge chips (e.g
AMD SB600/SB700) the secondary port is not wired, and when it is
disabled by setting the disable bit in the PCI header it appears
as a fixed legacy port.
Prevent incorrect detection by not testing ports that are marked
as 'dummy'
Signed-off-by: Darren Stevens <darren@stevens-zone.net>
---
v2: Changed to using 2 if statements instead of binary logic
[-- Attachment #3: libata.patch --]
[-- Type: text/plain, Size: 992 bytes --]
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 051b615..09bed5d 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -2427,11 +2427,21 @@ int ata_pci_sff_activate_host(struct ata_host *host,
return rc;
if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
- u8 tmp8, mask;
+ u8 tmp8, mask = 0;
- /* TODO: What if one channel is in native mode ... */
+ /*
+ * ATA spec says we should use legacy mode when one
+ * port is in legacy mode, but disabled ports on some
+ * PCI hosts appear as fixed legacy ports, e.g SB600/700
+ * on which the secondary port is not wired, so
+ * ignore ports that are marked as 'dummy' during
+ * this check
+ */
pci_read_config_byte(pdev, PCI_CLASS_PROG, &tmp8);
- mask = (1 << 2) | (1 << 0);
+ if (! ata_port_is_dummy(host->ports[1]))
+ mask = mask | (1 << 2);
+ if (! ata_port_is_dummy(host->ports[0]))
+ mask = mask | (1 << 0);
if ((tmp8 & mask) != mask)
legacy_mode = 1;
}
^ permalink raw reply related
* Re: libata-sff: Don't scan disabled ports when checking for legacy mode.
From: Darren Stevens @ 2017-01-22 19:40 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide
In-Reply-To: <20170120204136.GD9280@mtj.duckdns.org>
Hello Tejun
On 20/01/2017, Tejun Heo wrote:
> The patch is damaged and maybe just using two if statements would read
> easier?
Thanks for reviewing, I've made the changes you suggested, and resumbitted,
this time I have attached the patches so my emailer won't mangle them.
Both have come from my git tree and are tested as far as I can.
Regards
Darren
^ permalink raw reply
* (unknown),
From: beautyink @ 2017-01-22 21:52 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: EMAIL_26831974_linux-ide.zip --]
[-- Type: application/zip, Size: 15974 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support
From: Michael Schmitz @ 2017-01-23 8:04 UTC (permalink / raw)
To: Finn Thain
Cc: Bartlomiej Zolnierkiewicz, Tejun Heo, Geert Uytterhoeven,
linux-ide, Linux/m68k, Linux Kernel Development, Andreas Schwab
In-Reply-To: <alpine.LNX.2.00.1701211805050.18276@nippy.intranet>
Hi Finn,
Am 21.01.2017 um 20:37 schrieb Finn Thain:
>> The MFP interrupt in question is the same as the one used by IDE
>> (wired-OR of IDE, FDC and SCSI), so we would still have to figure out
>> where the interrupt originated.
>
> I thought you said the driver you're testing does not use any interrupt --
> I was assuming that only atari_scsi and ataflop drivers share the
> interupt.
My mistake - I was considering options to allow IDE to share the
interrupt, without the complexities of the old locking scheme.
>
>> Polling instead of taking the interrupt does not change that fundamental
>> problem (unless I'm missing something).
>>
>
> Actually, the fundamental problem you are describing is partly solved. By
> polling for DMA completion with local irqs disabled, we mostly avoid the
> need for the stdma.c "lock" because FDC/SCSI/IDE interrupt handlers can
> never interfere with a FDC/SCSI DMA process that might be underway.
I hadn't considered that. Can PDMA for Falcon SCSI coexist with
interrupt-using DMA for TT SCSI in the same driver (i.e. as runtime
options)? How much overhead and latency would polling for DMA completion
add?
>> Maybe the DMA address register can be used to check for DMA completion
>> ... it's used to check for residual or lost bytes anyway so that appears
>> to work. And the FDC driver does use the same strategy to check if
>> enough track data have been read.
>>
>> Leaves the case where DMA hasn't completed but may have been aborted by
>> a NCR5380 interrupt. I suppose we can detect that by checking for any
>> change in the DMA address while repeatedly reading the DMA address
>> register. No change means the DMA has got stuck. Not exactly pretty but
>> all I can come up with.
>>
>
> We don't have to poll any DMA registers (and I don't believe that it is
> viable to do so). I was talking about polling for end of DMA by polling
> for the interrupt (as per docs) but with local irqs disabled for the
> duration of the transfer (which provides exlusive access to the DMA chip).
atari_irq_pending(IRQ_MFP_FSCSI) should show the interrupt pending
condition if you want to poll for it. That's actually given me another
idea to pursue - if we can ensure the IDE interrupt handler is always
run first, and check whether the interrupt is still pending when the
SCSI or floppy interrupt handler runs and DMA has been in progress, we
should be able to avoid calling the respective handlers unnecessarily.
(The output of atari_irq_pending() does not directly reflect the status
of the MFP IRQ inputs - that would require testing bits in
st_mfp.par_dt_reg instead. )
> I don't think the IDE/ATA driver needs to be included. atari_scsi and
> ataflop would though (if both drivers need DMA transfers).
If we manage to separate interrupt sharing from DMA access locking, IDE
would not need to take part in the locking. I'm assuming that IDE can
cope with spurious interrupts and won't get confused by a SCSI interrupt.
>>> For example, the 5380 SCSI bus reset interrupt is not maskable, which
>>> could affect FDC transfers. If this terminated the polling for DMA
>>> completion, the FDC driver then has to access the FDC registers and
>>> confirm that the transfer was not terminated early.
>>>
>>
>> We'll have to make sure FDC and SCSI don't clash in their DMA and
>> interrupt use.
>>
>
> The point I was trying to make above is that stdma lock only gets you so
> far: if SCSI or FDC generate an interrupt that can't be disabled, it could
> mess up the interrupt polling (and the interrupt polling is a necessary
> consequence of IDE operating without stdma lock). This would lead to a
> short transfer (which could be easily detected).
Point taken - that problem still remains but is already being detected
(though not properly handled IIRC),
> So the chips clash in their interrupt line use (rarely). The drivers need
> not clash at all.
>
> Anyway, we seem to be talking past each other somewhat. I suggest we start
> coding and discuss actual patches ... unless you can convince me that this
> won't work ...
I think it could work both ways - polling for DMA completion or avoiding
to call the SCSI interrupt handler the interrupt was caused by IDE only.
But it's indeed time to put that to the test.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] libata-sff: Don't scan disabled ports when checking for legacy mode.
From: Sergei Shtylyov @ 2017-01-23 8:29 UTC (permalink / raw)
To: Darren Stevens, linux-ide
In-Reply-To: <497610a8448.441e0a10@auth.smtp.1and1.co.uk>
Hello!
On 1/20/2017 8:58 PM, Darren Stevens wrote:
> libata-sff.c checks for legacy mode by testing if both primary
> and secondary ports on a controller are in legacy mode and selects
> legacy if either one is. However on some southbridge chips (e.g
South bridge.
> AMD SB600/SB700) the secondary port is not wired, and when it is
> disabled by setting the disable bit in the PCI header it appears
> as a fixed legacy port.
> Prevent incorrect detection by not testing ports that are marked
> as 'dummy'
>
> Signed-off-by: Darren Stevens <darren@stevens-zone.net>
> ---
>
> diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
> index 051b615..05f688a 100644
> --- a/drivers/ata/libata-sff.c
> +++ b/drivers/ata/libata-sff.c
> @@ -2429,9 +2429,16 @@ int ata_pci_sff_activate_host(struct ata_host *host,
> if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> u8 tmp8, mask;
>
> - /* TODO: What if one channel is in native mode ... */
> + /*
> + * ATA spec says we should use legacy mode when one
> + * port is in legacy mode, but disabled ports on some
> + * PCI hosts appear as fixed legacy ports, e.g SB600/700
> + * on which the secondary port is not wired, so
> + * ignore ports that we've marked as 'dummy' during
> + * this check
> + */
> pci_read_config_byte(pdev, PCI_CLASS_PROG, &tmp8);
> - mask = (1 << 2) | (1 << 0);
> + mask = (! ata_port_is_dummy(host->ports[1]) << 2) | (!
> ata_port_is_dummy(host->ports[0]) << 0);
In addition to what Tejun said: no need for spaces after !.
[...]
MBR, Sergei
^ permalink raw reply
* Urgent Please,,
From: Joyes Dadi @ 2017-01-23 14:07 UTC (permalink / raw)
Good Day Dear,
My name is Ms. Joyes Dadi, I am glad you are reading this letter and I hope
we will start our communication and I know that this message will look strange,
surprising and probably unbelievable to you, but it is the reality. I want to
make a donation of money to you.
I contact you by the will of God. I am a firm German woman specialized in
mining gold and diamonds in Africa. But now, I'm very sick of a cancer. My
husband died in an accident two years ago with our two children and now I have
cancer of the esophagus that damaged almost all the cells in my system/agencies
and I'll die soon according to my doctor.
My most concern now is, we grew up in the orphanage and were married in
orphanage. If I die this deposited fund will soon be left alone in the hand of
the bank, and I do want to it that way. Please, if you can be reliable and
sincere to accept my humble proposal; I have (10.5Millions Euro) in a fixed
deposit account; I will order the Bank to transfer the money into your account
in your country immediately, and then you will take the fund to your country
and invest it to the orphanage homes Please, answer as quickly as possible.
God bless you.
Ms. Joyes Dadi
Email: joyesdadi767@citromail.hu
^ permalink raw reply
* Re: [PATCH v5 01/14] devicetree: bindings: add bindings for ahci-da850
From: Rob Herring @ 2017-01-23 15:49 UTC (permalink / raw)
To: Sekhar Nori
Cc: Bartosz Golaszewski, Kevin Hilman, Patrick Titiano,
Michael Turquette, Tejun Heo, Mark Rutland, Russell King,
David Lechner, linux-ide, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <5615fb6b-af26-c2fb-1f97-416548a9faaf@ti.com>
On Fri, Jan 20, 2017 at 07:02:08PM +0530, Sekhar Nori wrote:
> Hi Rob,
>
> On Friday 20 January 2017 04:51 PM, Bartosz Golaszewski wrote:
> > Add DT bindings for the TI DA850 AHCI SATA controller.
> >
> > Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Could you ack this binding?
First I'm seeing it that I recall and v5? That either means the DT list
wasn't copied or new versions are being sent out faster than can be
reviewed. Sending new versions puts you at the back of the queue.
>
> Thanks,
> Sekhar
>
> > ---
> > Documentation/devicetree/bindings/ata/ahci-da850.txt | 15 +++++++++++++++
> > 1 file changed, 15 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
> >
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt b/Documentation/devicetree/bindings/ata/ahci-da850.txt
> > new file mode 100644
> > index 0000000..268fe87
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt
> > @@ -0,0 +1,15 @@
> > +Device tree binding for the TI DA850 AHCI SATA Controller
> > +---------------------------------------------------------
> > +
> > +Required properties:
> > + - compatible: must be "ti,da850-ahci"
> > + - reg: physical base addresses and sizes of the controller's register areas
Need to state how many and what the regions are.
> > + - interrupts: interrupt specifier (refer to the interrupt binding)
> > +
> > +Example:
> > +
> > + sata: sata@218000 {
> > + compatible = "ti,da850-ahci";
> > + reg = <0x218000 0x2000>, <0x22c018 0x4>;
> > + interrupts = <67>;
> > + };
> >
>
^ permalink raw reply
* [PATCH v6 00/14] ARM: da850-lcdk: add SATA support
From: Bartosz Golaszewski @ 2017-01-23 17:00 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, Bartosz Golaszewski, linux-kernel, linux-arm-kernel,
devicetree
This series contains all the changes necessary to make SATA work on
the da850-lcdk board.
The first patch adds DT bindings for the ahci-da850 driver.
The second enables relevant modules in davinci_all_defconfig.
Patches 03/14-06/14 modify the way the clocks are handled regarding
SATA on the da850 platform. We modify the ahci driver to retrieve
the clock via con_id and model the external SATA oscillator as
a real clock.
Patches 07/14-11/14 extend the ahci-da850 driver. Add DT support,
implement workarounds necessary to make SATA work on the da850-lcdk
board and un-hardcode the external clock multiplier.
Patch 12/14 removes a no longer needed BUG_ON.
Last two patches add device tree changes required to probe the
driver.
v1 -> v2:
- dropped patch 04/10 - replaced with local changes in the
ahci-da850 driver
- added comments explaining the workaround in ahci softreset
- s/0x218000/218000 in the sata DT node label
- added patches chaning the way clocks are handled in the da850 SATA
code both in arch/ and in the ahci driver
- dropped the clock multiplier property in the DT bindings in favor
of using struct clk to pass the refclk rate to the driver
- minor tweaks in commit messages
v2 -> v3:
- dropped the clocks property from the ahci-da850 DT binding
- dropped patch 12/14 (SATA pinmux settings)
- dropped an outdated fragment from the commit message in patch 14/14
- s/get_clk()/clk_get()/
- s/connector id/connection id/
- stopped using __div64_32() after noticing that it sometimes produces
invalid results
- removed the default MPY value from ahci-da850
- registered SATA refclk for board file boot mode as well
v3 -> v4:
- added a patch removing the no longer needed BUG_ON() from
da850_register_sata()
- fixed indents
v4 -> v5:
- renamed the DT node for the SATA controller from 'ahci' to 'sata',
while keeping the label as 'sata'
- renamed the SATA node in the DT example as well
- instead of calling the refclk clock 'dummy', called it 'fixed rate'
v5 -> v6:
- specified what the required register regions are in the device
tree bindings
Bartosz Golaszewski (14):
devicetree: bindings: add bindings for ahci-da850
ARM: davinci_all_defconfig: enable SATA modules
ARM: davinci: add a clock lookup entry for the SATA clock
sata: ahci-da850: get the sata clock using a connection id
ARM: davinci: da850: add con_id for the SATA clock
ARM: davinci: da850: model the SATA refclk
sata: ahci-da850: add device tree match table
sata: ahci-da850: implement a workaround for the softreset quirk
sata: ahci: export ahci_do_hardreset() locally
sata: ahci-da850: add a workaround for controller instability
sata: ahci-da850: un-hardcode the MPY bits
ARM: davinci: remove BUG_ON() from da850_register_sata()
ARM: dts: da850: add the SATA node
ARM: dts: da850-lcdk: enable the SATA node
.../devicetree/bindings/ata/ahci-da850.txt | 18 +++
arch/arm/boot/dts/da850-lcdk.dts | 4 +
arch/arm/boot/dts/da850.dtsi | 6 +
arch/arm/configs/davinci_all_defconfig | 2 +
arch/arm/mach-davinci/da850.c | 2 +-
arch/arm/mach-davinci/da8xx-dt.c | 9 ++
arch/arm/mach-davinci/devices-da8xx.c | 30 +++-
arch/arm/mach-davinci/include/mach/da8xx.h | 1 +
drivers/ata/ahci.h | 3 +
drivers/ata/ahci_da850.c | 175 +++++++++++++++++++--
drivers/ata/libahci.c | 18 ++-
11 files changed, 243 insertions(+), 25 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
--
2.9.3
^ permalink raw reply
* [PATCH v6 01/14] devicetree: bindings: add bindings for ahci-da850
From: Bartosz Golaszewski @ 2017-01-23 17:00 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, Bartosz Golaszewski, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <1485190856-4711-1-git-send-email-bgolaszewski@baylibre.com>
Add DT bindings for the TI DA850 AHCI SATA controller.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
Documentation/devicetree/bindings/ata/ahci-da850.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt
diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt b/Documentation/devicetree/bindings/ata/ahci-da850.txt
new file mode 100644
index 0000000..5f81934
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt
@@ -0,0 +1,18 @@
+Device tree binding for the TI DA850 AHCI SATA Controller
+---------------------------------------------------------
+
+Required properties:
+ - compatible: must be "ti,da850-ahci"
+ - reg: physical base addresses and sizes of the two register regions
+ used by the controller: the register map as defined by the
+ AHCI 1.1 standard and the Power Down Control Register (PWRDN)
+ for enabling/disabling the SATA clock receiver
+ - interrupts: interrupt specifier (refer to the interrupt binding)
+
+Example:
+
+ sata: sata@218000 {
+ compatible = "ti,da850-ahci";
+ reg = <0x218000 0x2000>, <0x22c018 0x4>;
+ interrupts = <67>;
+ };
--
2.9.3
^ permalink raw reply related
* [PATCH v6 02/14] ARM: davinci_all_defconfig: enable SATA modules
From: Bartosz Golaszewski @ 2017-01-23 17:00 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, Bartosz Golaszewski, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <1485190856-4711-1-git-send-email-bgolaszewski@baylibre.com>
Add the da850-ahci driver to davinci defconfig.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index 8806754..a1b9c58 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -78,6 +78,8 @@ CONFIG_IDE=m
CONFIG_BLK_DEV_PALMCHIP_BK3710=m
CONFIG_SCSI=m
CONFIG_BLK_DEV_SD=m
+CONFIG_ATA=m
+CONFIG_AHCI_DA850=m
CONFIG_NETDEVICES=y
CONFIG_NETCONSOLE=y
CONFIG_TUN=m
--
2.9.3
^ permalink raw reply related
* [PATCH v6 03/14] ARM: davinci: add a clock lookup entry for the SATA clock
From: Bartosz Golaszewski @ 2017-01-23 17:00 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, Bartosz Golaszewski, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <1485190856-4711-1-git-send-email-bgolaszewski@baylibre.com>
This entry is needed for the ahci driver to get a functional clock.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/mach-davinci/da8xx-dt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 9ee44da..b83e5d1 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -42,6 +42,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
+ OF_DEV_AUXDATA("ti,da850-ahci", 0x01e18000, "ahci_da850", NULL),
{}
};
--
2.9.3
^ permalink raw reply related
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