Re: [PATCH 01/10] alpha: use libata instead of the legacy ide driver
Christoph Hellwig writes: > On Thu, Mar 18, 2021 at 05:54:55AM +, Al Viro wrote: >> On Thu, Mar 18, 2021 at 05:56:57AM +0100, Christoph Hellwig wrote: >> > Switch the alpha defconfig from the legacy ide driver to libata. >> >> Umm... I don't have an IDE alpha box in a usable shape (fans on >> CPU module shat themselves), and it would take a while to resurrect >> it, but I remember the joy it used to cause in some versions. >> >> Do you have reports of libata variants of drivers actually tested on >> those? > > No, I haven't. The whole point is that we're not going to keep 4 > lines of code around despite notice for users that don't exist or > care. If there is a regression we'll fix it, but we're not going to > make life miserable just because we can. The pata_ali driver works fine on my UP1500 machine, unless something broke recently. I'll build the latest kernel and report back. -- Måns Rullgård
Re: [PATCH 01/10] alpha: use libata instead of the legacy ide driver
Måns Rullgård writes: > Christoph Hellwig writes: > >> On Thu, Mar 18, 2021 at 05:54:55AM +, Al Viro wrote: >>> On Thu, Mar 18, 2021 at 05:56:57AM +0100, Christoph Hellwig wrote: >>> > Switch the alpha defconfig from the legacy ide driver to libata. >>> >>> Umm... I don't have an IDE alpha box in a usable shape (fans on >>> CPU module shat themselves), and it would take a while to resurrect >>> it, but I remember the joy it used to cause in some versions. >>> >>> Do you have reports of libata variants of drivers actually tested on >>> those? >> >> No, I haven't. The whole point is that we're not going to keep 4 >> lines of code around despite notice for users that don't exist or >> care. If there is a regression we'll fix it, but we're not going to >> make life miserable just because we can. > > The pata_ali driver works fine on my UP1500 machine, unless something > broke recently. I'll build the latest kernel and report back. 5.11.7 seems fine too. -- Måns Rullgård
Re: [PATCH] net: fs_enet: sync rx dma buffer before reading
Christophe Leroy writes:
> Le 19/05/2022 à 21:24, Mans Rullgard a écrit :
>> The dma_sync_single_for_cpu() call must precede reading the received
>> data. Fix this.
>
> See original commit 070e1f01827c. It explicitely says that the cache
> must be invalidate _AFTER_ the copy.
>
> The cache is initialy invalidated by dma_map_single(), so before the
> copy the cache is already clean.
>
> After the copy, data is in the cache. In order to allow re-use of the
> skb, it must be put back in the same condition as before, in extenso the
> cache must be invalidated in order to be in the same situation as after
> dma_map_single().
>
> So I think your change is wrong.
OK, looking at it more closely, the change is at least unnecessary since
there will be a cache invalidation between each use of the buffer either
way. Please disregard the patch. Sorry for the noise.
>>
>> Fixes: 070e1f01827c ("net: fs_enet: don't unmap DMA when packet len is below
>> copybreak")
>> Signed-off-by: Mans Rullgard
>> ---
>> drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
>> b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
>> index b3dae17e067e..432ce10cbfd0 100644
>> --- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
>> +++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
>> @@ -240,14 +240,14 @@ static int fs_enet_napi(struct napi_struct *napi, int
>> budget)
>> /* +2 to make IP header L1 cache aligned */
>> skbn = netdev_alloc_skb(dev, pkt_len + 2);
>> if (skbn != NULL) {
>> + dma_sync_single_for_cpu(fep->dev,
>> + CBDR_BUFADDR(bdp),
>> + L1_CACHE_ALIGN(pkt_len),
>> + DMA_FROM_DEVICE);
>> skb_reserve(skbn, 2); /* align IP
>> header */
>> skb_copy_from_linear_data(skb,
>>skbn->data, pkt_len);
>> swap(skb, skbn);
>> - dma_sync_single_for_cpu(fep->dev,
>> - CBDR_BUFADDR(bdp),
>> - L1_CACHE_ALIGN(pkt_len),
>> - DMA_FROM_DEVICE);
>> }
>> } else {
>> skbn = netdev_alloc_skb(dev,
>> ENET_RX_FRSIZE);
>> --
>> 2.35.1
>>
--
Måns Rullgård
Re: [PATCH v2 03/23] ata: sata_dwc_460ex: set dma_boundary to 0x1fff
Tejun Heo writes:
> On Tue, Apr 26, 2016 at 12:03:04PM +0300, Andy Shevchenko wrote:
>> diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
>> index 7f95389..aee8873 100644
>> --- a/drivers/ata/sata_dwc_460ex.c
>> +++ b/drivers/ata/sata_dwc_460ex.c
>> @@ -1151,7 +1151,13 @@ static struct scsi_host_template sata_dwc_sht = {
>> */
>> .sg_tablesize = LIBATA_MAX_PRD,
>> /* .can_queue = ATA_MAX_QUEUE, */
>> -.dma_boundary = ATA_DMA_BOUNDARY,
>> +/*
>> + * Make sure a LLI block is not created that will span 8K max FIS
>> + * boundary. If the block spans such a FIS boundary, there is a chance
>> + * that a DMA burst will cross that boundary -- this results in an
>> + * error in the host controller.
>> + */
>> +.dma_boundary = 0x1fff /* ATA_DMA_BOUNDARY */,
>
> The host controller can't cross 8k boundary? Is this for real?
From the manual:
DMA block and burst transaction sizes are critical for DMA operation.
(Also see the definition of "DMA transfer".) These sizes should be
selected properly to ensure error-free bus transfers. It is required
that the DMA write burst transfer does not cross the 8192-byte Data
FIS boundary, because the Transport Layer maintains the DMA state for
the duration of the Data FIS transmission.
--
Måns Rullgård
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 00/23] ata: sata_dwc_460ex: make it working again
Andy Shevchenko writes: > On Mon, May 9, 2016 at 4:09 AM, Tejun Heo wrote: >> On Sun, May 08, 2016 at 04:00:08PM -0400, Tejun Heo wrote: >>> Hello, Andy. >>> >>> On Wed, May 04, 2016 at 03:22:51PM +0300, Andy Shevchenko wrote: >>> > Tejun, since Vinod applied all necessary patches into his tree, the >>> > series now has just a dependency to whatever branch / tag he marks for >>> > it. >>> > Do we have a chance to see the SATA series be applied in your tree? >>> >>> Applied 1-22 to libata/for-4.7. There was a couple trivial conflicts >>> which I resolved while applying but it'd be great if you can check >>> whether everything looks okay. >>> >>> https://git.kernel.org/cgit/linux/kernel/git/tj/libata.git/log/?h=for-4.7 >> >> Oops, build failure. Reverted for now. > > I suppose you have to pull material from Vinod. The failure the build bot reported is due to the DMA patches not being in the tree. -- Måns Rullgård ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 07/10] ARM: dts: tango4: Make /serial compatible with ns16550a
Lubomir Rintel writes:
> ralink,rt2880-uart is compatible with ns16550a and all other
> instances of RT2880 UART nodes include it in the compatible property.
> Add it also here, to make the binding schema simpler.
>
> Signed-off-by: Lubomir Rintel
Acked-by: Mans Rullgard
> ---
> arch/arm/boot/dts/tango4-common.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tango4-common.dtsi
> b/arch/arm/boot/dts/tango4-common.dtsi
> index ff72a8efb73d0..54fd522badfc9 100644
> --- a/arch/arm/boot/dts/tango4-common.dtsi
> +++ b/arch/arm/boot/dts/tango4-common.dtsi
> @@ -85,7 +85,7 @@ tick-counter@10048 {
> };
>
> uart: serial@10700 {
> - compatible = "ralink,rt2880-uart";
> + compatible = "ralink,rt2880-uart", "ns16550a";
> reg = <0x10700 0x30>;
> interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
> clock-frequency = <7372800>;
> --
> 2.25.1
>
--
Måns Rullgård
Re: [PATCH v2] watchdog: add SPDX identifiers for watchdog subsystem
Marcus Folkesson writes: > - Add SPDX identifier > - Remove boiler plate license text > - If MODULE_LICENSE and boiler plate does not match, go for boiler plate > license > > Signed-off-by: Marcus Folkesson > Acked-by: Adam Thomson > Acked-by: Charles Keepax > Acked-by: Nicolas Ferre > Acked-by: Michal Simek > --- > > Notes: > v2: > - Put back removed copyright texts for meson_gxbb_wdt and coh901327_wdt > - Change to BSD-3-Clause for meson_gxbb_wdt > v1: Please have an extra look at meson_gxbb_wdt.c [...] > drivers/watchdog/tangox_wdt.c | 6 +--- For tangox_wdt: Acked-by: Mans Rullgard -- Måns Rullgård
Re: [PATCH v1 1/2] sata_dwc_460ex: move to generic DMA driver
Andy Shevchenko writes:
> The SATA implementation based on two actually different devices, i.e. SATA and
> DMA controllers.
>
> For Synopsys DesignWare DMA we have already a generic implementation of the
> driver. Thus, the patch converts the code to use DMAEngine framework and
> dw_dmac driver.
>
> In future it will be better to split the devices inside DTS as well like it's
> done on other platforms.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/ata/sata_dwc_460ex.c | 736
> +++
> 1 file changed, 122 insertions(+), 614 deletions(-)
>
[...]
> @@ -1721,16 +1227,16 @@ static int sata_dwc_probe(struct platform_device
> *ofdev)
> idr, ver[0], ver[1], ver[2]);
>
> /* Get SATA DMA interrupt number */
> - irq = irq_of_parse_and_map(np, 1);
> - if (irq == NO_IRQ) {
> + hsdev->dma->irq = irq_of_parse_and_map(np, 1);
This doesn't look like it has been more than compile-tested. Nothing
ever allocates hsdev->dma, so it can't possibly work.
Also, has anyone given any thought to getting rid of the dependency on
the DW DMA controller? Presumably support for old device trees would
need to be retained for compatibility. Maybe checking for a "dmas"
property and falling back on the current behaviour if it's missing. My
goal is to get this driver working with another chip using the same SATA
controller but a different DMA engine.
--
Måns Rullgård
m...@mansr.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1 1/2] sata_dwc_460ex: move to generic DMA driver
Andy Shevchenko writes:
> On Sun, 2015-11-22 at 13:03 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > The SATA implementation based on two actually different devices,
>> > i.e. SATA and
>> > DMA controllers.
>> >
>> > For Synopsys DesignWare DMA we have already a generic
>> > implementation of the
>> > driver. Thus, the patch converts the code to use DMAEngine
>> > framework and
>> > dw_dmac driver.
>> >
>> > In future it will be better to split the devices inside DTS as well
>> > like it's
>> > done on other platforms.
>
>> > @@ -1721,16 +1227,16 @@ static int sata_dwc_probe(struct
>> > platform_device *ofdev)
>> > idr, ver[0], ver[1], ver[2]);
>> >
>> >/* Get SATA DMA interrupt number */
>> > - irq = irq_of_parse_and_map(np, 1);
>> > - if (irq == NO_IRQ) {
>> > + hsdev->dma->irq = irq_of_parse_and_map(np, 1);
>>
>> This doesn't look like it has been more than compile-tested.
>
> Yes, that's true, my question [1] was a crying in the wilderness.
>
>> Nothing
>> ever allocates hsdev->dma, so it can't possibly work.
>
> You are right.
>
>>
>> Also, has anyone given any thought to getting rid of the dependency
>> on the DW DMA controller?
>
> How? Before it was even more harder link to it (embedded routines).
It already uses the dmaengine API to do the transfers. To make it
generic, two things need to change:
1. The DMA controller should get its own DT node instead of the SATA
driver calling dw_dma_probe() directly.
2. The SATA driver can then use dma_request_slave_channel() and a "dmas"
DT property instead of dma_request_channel() and filter function.
The changes are easy to make as such. The only problem is that we need
to preserve compatibility with old device trees.
> On the other hand you may introduce dma_ops and use them like it's
> done, for example, in spi-dw*.c
>
>> Presumably support for old device trees would
>> need to be retained for compatibility. Maybe checking for a "dmas"
>> property and falling back on the current behaviour if it's missing.
>
> I didn't get how DT is related to DW or any other DMAC used with this
> SATA controller.
See Documentation/devicetree/bindings/dma/dma.txt
>> My goal is to get this driver working with another chip using the
>> same SATA controller but a different DMA engine.
>
> It would be nice to eventually bring this working with generic DMA
> Engine API. Please, keep me in Cc list regarding this driver.
What's your interest in this driver if you don't have the hardware?
--
Måns Rullgård
m...@mansr.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
