From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Serge Semin <fancer.lancer@gmail.com>, Ferry Toth <ftoth@exalondelft.nl>
Cc: "Viresh Kumar" <vireshk@kernel.org>,
"Vinod Koul" <vkoul@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jirislaby@kernel.org>,
dmaengine@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND v4 1/6] dmaengine: dw: Add peripheral bus width verification
Date: Sat, 14 Sep 2024 22:12:35 +0300 [thread overview]
Message-ID: <ZuXgI-VcHpMgbZ91@black.fi.intel.com> (raw)
In-Reply-To: <20240802075100.6475-2-fancer.lancer@gmail.com>
On Fri, Aug 02, 2024 at 10:50:46AM +0300, Serge Semin wrote:
> Currently the src_addr_width and dst_addr_width fields of the
> dma_slave_config structure are mapped to the CTLx.SRC_TR_WIDTH and
> CTLx.DST_TR_WIDTH fields of the peripheral bus side in order to have the
> properly aligned data passed to the target device. It's done just by
> converting the passed peripheral bus width to the encoded value using the
> __ffs() function. This implementation has several problematic sides:
>
> 1. __ffs() is undefined if no bit exist in the passed value. Thus if the
> specified addr-width is DMA_SLAVE_BUSWIDTH_UNDEFINED, __ffs() may return
> unexpected value depending on the platform-specific implementation.
>
> 2. DW AHB DMA-engine permits having the power-of-2 transfer width limited
> by the DMAH_Mk_HDATA_WIDTH IP-core synthesize parameter. Specifying
> bus-width out of that constraints scope will definitely cause unexpected
> result since the destination reg will be only partly touched than the
> client driver implied.
>
> Let's fix all of that by adding the peripheral bus width verification
> method and calling it in dwc_config() which is supposed to be executed
> before preparing any transfer. The new method will make sure that the
> passed source or destination address width is valid and if undefined then
> the driver will just fallback to the 1-byte width transfer.
This patch broke Intel Merrifield iDMA32 + SPI PXA2xx configuration to
me. Since it's first in the series and most likely the rest is
dependent and we are almost at the release date I propose to roll back
and start again after v6.12-rc1 will be out. Vinod, can we revert the
entire series, please?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-09-14 19:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-02 7:50 [PATCH RESEND v4 0/6] dmaengine: dw: Fix src/dst addr width misconfig Serge Semin
2024-08-02 7:50 ` [PATCH RESEND v4 1/6] dmaengine: dw: Add peripheral bus width verification Serge Semin
2024-09-14 19:12 ` Andy Shevchenko [this message]
2024-09-14 19:22 ` Serge Semin
2024-09-15 21:06 ` Ferry Toth
2024-09-16 11:43 ` Andy Shevchenko
2024-09-16 11:45 ` Andy Shevchenko
2024-09-16 11:57 ` Andy Shevchenko
2024-09-16 12:46 ` Andy Shevchenko
2024-09-19 14:04 ` Serge Semin
2024-08-02 7:50 ` [PATCH RESEND v4 2/6] dmaengine: dw: Add memory " Serge Semin
2024-08-02 7:50 ` [PATCH RESEND v4 3/6] dmaengine: dw: Simplify prepare CTL_LO methods Serge Semin
2024-08-02 7:50 ` [PATCH RESEND v4 4/6] dmaengine: dw: Define encode_maxburst() above prepare_ctllo() callbacks Serge Semin
2024-08-02 7:50 ` [PATCH RESEND v4 5/6] dmaengine: dw: Simplify max-burst calculation procedure Serge Semin
2024-08-02 7:50 ` [PATCH RESEND v4 6/6] dmaengine: dw: Unify ret-val local variables naming Serge Semin
2024-08-03 19:29 ` [PATCH RESEND v4 0/6] dmaengine: dw: Fix src/dst addr width misconfig Andy Shevchenko
2024-08-05 12:25 ` Serge Semin
2024-09-14 18:50 ` Andy Shevchenko
2024-09-14 19:06 ` Serge Semin
2024-09-14 19:08 ` Serge Semin
2024-09-15 11:43 ` Andy Shevchenko
2024-09-15 21:34 ` Serge Semin
2024-08-05 17:37 ` Vinod Koul
2024-08-29 17:30 ` Vinod Koul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZuXgI-VcHpMgbZ91@black.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=fancer.lancer@gmail.com \
--cc=ftoth@exalondelft.nl \
--cc=gregkh@linuxfoundation.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=vireshk@kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.