Date:   Tue, 1 Nov 2022 12:40:16 +0100
From:   Thierry Reding <thierry.reding@...il.com>
To:     Akhil R <akhilrajeev@...dia.com>, Rob Herring <robh@...nel.org>
Cc:     Jonathan Hunter <jonathanh@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
        "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "sfr@...b.auug.org.au" <sfr@...b.auug.org.au>
Subject: Re: [PATCH RESEND v2 3/3] dmaengine: tegra: Add support for
 dma-channel-mask

On Thu, Oct 27, 2022 at 10:13:00AM +0000, Akhil R wrote:
> > On 26/10/2022 05:44, Akhil R wrote:
> > >> On Thu, Oct 20, 2022 at 02:03:22PM +0530, Akhil R wrote:
> > >>> Add support for dma-channel-mask so that only the specified channels
> > >>> are used. This helps to reserve some channels for the firmware.
> > >>>
> > >>> This was initially achieved by limiting the channel number to 31 in
> > >>> the driver and adjusting the register address to skip channel0 which
> > >>> was reserved for a firmware. Now, with this change, the driver can
> > >>> align more to the actual hardware which has 32 channels.
> > >>>
> > >>> Signed-off-by: Akhil R <akhilrajeev@...dia.com>
> > >>> Reviewed-by: Jon Hunter <jonathanh@...dia.com>
> > >>> ---
> > >>>   drivers/dma/tegra186-gpc-dma.c | 37 +++++++++++++++++++++++++++----
> > ---
> > >>>   1 file changed, 30 insertions(+), 7 deletions(-)
> > >>>
> > >>> diff --git a/drivers/dma/tegra186-gpc-dma.c b/drivers/dma/tegra186-gpc-
> > >> dma.c
> > >>> index fa9bda4a2bc6..1d1180db6d4e 100644
> > >>> --- a/drivers/dma/tegra186-gpc-dma.c
> > >>> +++ b/drivers/dma/tegra186-gpc-dma.c
> > >>> @@ -161,7 +161,10 @@
> > >>>   #define TEGRA_GPCDMA_BURST_COMPLETION_TIMEOUT        5000 /* 5
> > >> msec */
> > >>>
> > >>>   /* Channel base address offset from GPCDMA base address */
> > >>> -#define TEGRA_GPCDMA_CHANNEL_BASE_ADD_OFFSET 0x20000
> > >>> +#define TEGRA_GPCDMA_CHANNEL_BASE_ADDR_OFFSET        0x10000
> > >>> +
> > >>> +/* Default channel mask reserving channel0 */
> > >>> +#define TEGRA_GPCDMA_DEFAULT_CHANNEL_MASK    0xfffffffe
> > >>>
> > >>>   struct tegra_dma;
> > >>>   struct tegra_dma_channel;
> > >>> @@ -246,6 +249,7 @@ struct tegra_dma {
> > >>>        const struct tegra_dma_chip_data *chip_data;
> > >>>        unsigned long sid_m2d_reserved;
> > >>>        unsigned long sid_d2m_reserved;
> > >>> +     u32 chan_mask;
> > >>>        void __iomem *base_addr;
> > >>>        struct device *dev;
> > >>>        struct dma_device dma_dev;
> > >>> @@ -1288,7 +1292,7 @@ static struct dma_chan
> > *tegra_dma_of_xlate(struct
> > >> of_phandle_args *dma_spec,
> > >>>   }
> > >>>
> > >>>   static const struct tegra_dma_chip_data tegra186_dma_chip_data = {
> > >>> -     .nr_channels = 31,
> > >>> +     .nr_channels = 32,
> > >>
> > >> This is an ABI break. A new kernel with an old DTB will use 32 channels
> > >> instead of 31. You should leave this and use the dma-channel-mask to
> > >> enable all 32 channels.
> > >>
> > > Hi Rob,
> > >
> > > If using an old DTB, tdma->chan_mask will be default to 0xfffffffe since it
> > > would not have the dma-channel-mask property. The driver would still
> > > use 31 channels even if it uses an old DTB. Shouldn't it prevent the
> > > ABI break?
> > 
> > Unfortunately no. Yes for an old DTB without the dma-channel-mask
> > property, we set the channel mask to 0xfffffffe, but this is not correct
> > because it only has 31 interrupts/channels and not 32. So I think we
> > will need to use of_irq_count() here.
> >
> 
> Shall I put it in a way that only the used interrupts are mentioned in the DT?
> With this I can revert the interrupt change in the DT and would not break
> the ABI as well.
> 
> The code would look something like this.
> 
> int chan_count = 0;
> 
> if (of_irq_count(pdev->dev.of_node) != hweight_long(tdma->chan_mask)) {
>         dev_err(&pdev->dev, "Interrupt count doesn't match with channels\n");
>         return -EINVAL;
> }
> 
> for (i = 0; i < cdata->nr_channels; i++) {
>         struct tegra_dma_channel *tdc = &tdma->channels[i];
>     
>         /* Check for channel mask */
>         if (!(tdma->chan_mask & BIT(i)))
>             continue;
> 
>         tdc->irq = platform_get_irq(pdev, chan_count);
>         chan_count++;
>         if (tdc->irq < 0)
>             return tdc->irq;
>     ...
>     ...
> }

This is all getting quite complicated for what is essentially a bug fix.
The root of this problem is that the original bindings were simply wrong
and didn't accurately represent the hardware.

The GPC DMA controller has 32 channels and each channel has one DMA
interrupt. So the right way to describe this in DT is by listing all of
the interrupts. If the firmware then ends up using one of those channels
the right way is not to make it seem like the controller supports only
31 channels, but rather to mark the used channels as reserved.

So I think the bottom line here is that the original binding has a bug
that we're trying to address. Any workaround for this is problematic,
and I think breaking backwards-compatibility is the cleanest solution
here.

Now, GPC DMA was introduced on Tegra186 and the DT bindings were added
in 5.19. Any products released with this IP were released with kernels
prior to 5.19 and bindings that were never in-tree. Any of those
products that are supported upstream we know have replaceable DTB images
(i.e. by default they are flashed at the same time as the kernel image),
so breaking DT ABI should be okay.

In fact, there are slight incompatibilities between product and upstream
DT bindings (we're in the process of removing those as part of the
upstreaming process), so being able to reflash the DTB is a prerequisite
for supporting upstream Linux on these devices.

I think going forward we should be extra careful about these kinds of
problems, so that we don't have to keep dealing with fallout like this.

Rob, given the above, do you think it's okay to proceed with the ABI
break?

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists