| Message ID | 1721367736-30156-5-git-send-email-hongxing.zhu@nxp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Refine i.MX8QM SATA based on generic PHY callbacks | expand |
On Fri, Jul 19, 2024 at 01:42:14PM +0800, Richard Zhu wrote: > Since i.MX8QM AHCI SATA only has 32bits DMA capability. > Add 32bits DMA limit here. > > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> > --- > drivers/ata/ahci_imx.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c > index 4dd98368f8562..e94c0fdea2260 100644 > --- a/drivers/ata/ahci_imx.c > +++ b/drivers/ata/ahci_imx.c > @@ -827,6 +827,9 @@ static const struct scsi_host_template ahci_platform_sht = { > > static int imx8_sata_probe(struct device *dev, struct imx_ahci_priv *imxpriv) > { > + if (!(dev->bus_dma_limit)) > + dev->bus_dma_limit = DMA_BIT_MASK(32); > + > imxpriv->sata_phy = devm_phy_get(dev, "sata-phy"); > if (IS_ERR(imxpriv->sata_phy)) > return dev_err_probe(dev, PTR_ERR(imxpriv->sata_phy), > -- > 2.37.1 > Why is this needed? ahci_imx.c calls ahci_platform_init_host(), which calls dma_coerce_mask_and_coherent(): https://github.com/torvalds/linux/blob/v6.10/drivers/ata/libahci_platform.c#L750-L756 Should this code perhaps look more like: https://github.com/torvalds/linux/blob/v6.10/drivers/ata/ahci.c#L1048-L1054 where we set it to 64 or 32 bit explicitly. Does this solve your problem: diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c index 581704e61f28..fc86e2c8c42b 100644 --- a/drivers/ata/libahci_platform.c +++ b/drivers/ata/libahci_platform.c @@ -747,12 +747,11 @@ int ahci_platform_init_host(struct platform_device *pdev, ap->ops = &ata_dummy_port_ops; } - if (hpriv->cap & HOST_CAP_64) { - rc = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64)); - if (rc) { - dev_err(dev, "Failed to enable 64-bit DMA.\n"); - return rc; - } + rc = dma_coerce_mask_and_coherent(dev, + DMA_BIT_MASK((hpriv->cap & HOST_CAP_64) ? 64 : 32)); + if (rc) { + dev_err(dev, "DMA enable failed\n"); + return rc; } rc = ahci_reset_controller(host); Kind regards, Niklas
> -----Original Message----- > From: Niklas Cassel <cassel@kernel.org> > Sent: 2024年7月24日 0:04 > To: Hongxing Zhu <hongxing.zhu@nxp.com> > Cc: tj@kernel.org; dlemoal@kernel.org; robh@kernel.org; krzk+dt@kernel.org; > conor+dt@kernel.org; shawnguo@kernel.org; s.hauer@pengutronix.de; > festevam@gmail.com; linux-ide@vger.kernel.org; stable@vger.kernel.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; imx@lists.linux.dev; > kernel@pengutronix.de > Subject: Re: [PATCH v4 4/6] ata: ahci_imx: Add 32bits DMA limit for i.MX8QM > AHCI SATA > > On Fri, Jul 19, 2024 at 01:42:14PM +0800, Richard Zhu wrote: > > Since i.MX8QM AHCI SATA only has 32bits DMA capability. > > Add 32bits DMA limit here. > > > > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> > > --- > > drivers/ata/ahci_imx.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c index > > 4dd98368f8562..e94c0fdea2260 100644 > > --- a/drivers/ata/ahci_imx.c > > +++ b/drivers/ata/ahci_imx.c > > @@ -827,6 +827,9 @@ static const struct scsi_host_template > > ahci_platform_sht = { > > > > static int imx8_sata_probe(struct device *dev, struct imx_ahci_priv > > *imxpriv) { > > + if (!(dev->bus_dma_limit)) > > + dev->bus_dma_limit = DMA_BIT_MASK(32); > > + > > imxpriv->sata_phy = devm_phy_get(dev, "sata-phy"); > > if (IS_ERR(imxpriv->sata_phy)) > > return dev_err_probe(dev, PTR_ERR(imxpriv->sata_phy), > > -- > > 2.37.1 > > > > Why is this needed? > > ahci_imx.c calls ahci_platform_init_host(), which calls > dma_coerce_mask_and_coherent(): > https://github.co/ > m%2Ftorvalds%2Flinux%2Fblob%2Fv6.10%2Fdrivers%2Fata%2Flibahci_platfor > m.c%23L750-L756&data=05%7C02%7Chongxing.zhu%40nxp.com%7C9d64eab > e3c5f4af9d15808dcab312651%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0 > %7C0%7C638573474782493607%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7 > C%7C&sdata=4gHxszzym8hOgVIo6%2BM2JHMyBa5I5U65j08fH3P34BY%3D&re > served=0 > > Should this code perhaps look more like: > https://github.co/ > m%2Ftorvalds%2Flinux%2Fblob%2Fv6.10%2Fdrivers%2Fata%2Fahci.c%23L104 > 8-L1054&data=05%7C02%7Chongxing.zhu%40nxp.com%7C9d64eabe3c5f4af9 > d15808dcab312651%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C > 638573474782506903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sd > ata=vpn1QyX8p7IZhBi5n2iOi8ezFRPTbGk1fqlK5ZsPhYk%3D&reserved=0 > > where we set it to 64 or 32 bit explicitly. > > Does this solve your problem: > diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c > index 581704e61f28..fc86e2c8c42b 100644 > --- a/drivers/ata/libahci_platform.c > +++ b/drivers/ata/libahci_platform.c > @@ -747,12 +747,11 @@ int ahci_platform_init_host(struct platform_device > *pdev, > ap->ops = &ata_dummy_port_ops; > } > > - if (hpriv->cap & HOST_CAP_64) { > - rc = dma_coerce_mask_and_coherent(dev, > DMA_BIT_MASK(64)); > - if (rc) { > - dev_err(dev, "Failed to enable 64-bit DMA.\n"); > - return rc; > - } > + rc = dma_coerce_mask_and_coherent(dev, > + DMA_BIT_MASK((hpriv->cap & HOST_CAP_64) ? 64 : > 32)); > + if (rc) { > + dev_err(dev, "DMA enable failed\n"); > + return rc; > } > > rc = ahci_reset_controller(host); > Hi Niklas: I'm so sorry to reply late. About the 32bit DMA limitation of i.MX8QM AHCI SATA. It's seems that one "dma-ranges" property in the DT can let i.MX8QM SATA works fine in my past days tests without this commit. How about drop these driver changes, and add "dma-ranges" for i.MX8QM SATA? Thanks a lot for your kindly help. Best Regards Richard Zhu > > > Kind regards, > Niklas
On Fri, Aug 02, 2024 at 02:30:45AM +0000, Hongxing Zhu wrote: > > > > Does this solve your problem: > > diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c > > index 581704e61f28..fc86e2c8c42b 100644 > > --- a/drivers/ata/libahci_platform.c > > +++ b/drivers/ata/libahci_platform.c > > @@ -747,12 +747,11 @@ int ahci_platform_init_host(struct platform_device > > *pdev, > > ap->ops = &ata_dummy_port_ops; > > } > > > > - if (hpriv->cap & HOST_CAP_64) { > > - rc = dma_coerce_mask_and_coherent(dev, > > DMA_BIT_MASK(64)); > > - if (rc) { > > - dev_err(dev, "Failed to enable 64-bit DMA.\n"); > > - return rc; > > - } > > + rc = dma_coerce_mask_and_coherent(dev, > > + DMA_BIT_MASK((hpriv->cap & HOST_CAP_64) ? 64 : > > 32)); > > + if (rc) { > > + dev_err(dev, "DMA enable failed\n"); > > + return rc; > > } > > > > rc = ahci_reset_controller(host); > > > Hi Niklas: > I'm so sorry to reply late. > About the 32bit DMA limitation of i.MX8QM AHCI SATA. > It's seems that one "dma-ranges" property in the DT can let i.MX8QM SATA > works fine in my past days tests without this commit. > How about drop these driver changes, and add "dma-ranges" for i.MX8QM SATA? > Thanks a lot for your kindly help. Hello Richard, did you try my suggested patch above? If you look at dma-ranges: https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#dma-ranges "dma-ranges" property should be used on a bus device node (such as PCI host bridges). It does not seem correct to add this property (describing the DMA limit of the AHCI controller, a PCI endpoint) on the PCI host bridge/controller. This property belongs to the AHCI controller, not the upstream PCI host bridge/controller. AHCI has a specific register to describe if the hardware can support 64-bit DMA addresses or not, so if my suggested patch works for you, it seems like a more elegant solution (which also avoids having to abuse device tree properties). Kind regards, Niklas
> -----Original Message----- > From: Niklas Cassel <cassel@kernel.org> > Sent: 2024年8月8日 6:35 > To: Hongxing Zhu <hongxing.zhu@nxp.com> > Cc: tj@kernel.org; dlemoal@kernel.org; robh@kernel.org; krzk+dt@kernel.org; > conor+dt@kernel.org; shawnguo@kernel.org; s.hauer@pengutronix.de; > festevam@gmail.com; linux-ide@vger.kernel.org; stable@vger.kernel.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; imx@lists.linux.dev; > kernel@pengutronix.de > Subject: Re: [PATCH v4 4/6] ata: ahci_imx: Add 32bits DMA limit for i.MX8QM > AHCI SATA > > On Fri, Aug 02, 2024 at 02:30:45AM +0000, Hongxing Zhu wrote: > > > > > > Does this solve your problem: > > > diff --git a/drivers/ata/libahci_platform.c > > > b/drivers/ata/libahci_platform.c index 581704e61f28..fc86e2c8c42b > > > 100644 > > > --- a/drivers/ata/libahci_platform.c > > > +++ b/drivers/ata/libahci_platform.c > > > @@ -747,12 +747,11 @@ int ahci_platform_init_host(struct > > > platform_device *pdev, > > > ap->ops = &ata_dummy_port_ops; > > > } > > > > > > - if (hpriv->cap & HOST_CAP_64) { > > > - rc = dma_coerce_mask_and_coherent(dev, > > > DMA_BIT_MASK(64)); > > > - if (rc) { > > > - dev_err(dev, "Failed to enable 64-bit DMA.\n"); > > > - return rc; > > > - } > > > + rc = dma_coerce_mask_and_coherent(dev, > > > + DMA_BIT_MASK((hpriv->cap & HOST_CAP_64) ? > 64 : > > > 32)); > > > + if (rc) { > > > + dev_err(dev, "DMA enable failed\n"); > > > + return rc; > > > } > > > > > > rc = ahci_reset_controller(host); > > > > > Hi Niklas: > > I'm so sorry to reply late. > > About the 32bit DMA limitation of i.MX8QM AHCI SATA. > > It's seems that one "dma-ranges" property in the DT can let i.MX8QM > > SATA works fine in my past days tests without this commit. > > How about drop these driver changes, and add "dma-ranges" for i.MX8QM > SATA? > > Thanks a lot for your kindly help. > > Hello Richard, > > did you try my suggested patch above? > > > If you look at dma-ranges: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevicetre > e-specification.readthedocs.io%2Fen%2Flatest%2Fchapter2-devicetree-basics.ht > ml%23dma-ranges&data=05%7C02%7Chongxing.zhu%40nxp.com%7C97f87f99 > 37844f97dbf508dcb731345e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0 > %7C0%7C638586669175980044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7 > C%7C&sdata=PO0bQVUA7o47HAecOp27TKwwNiG1ydfQq4DTtgEva%2Fg%3D& > reserved=0 > > "dma-ranges" property should be used on a bus device node (such as PCI host > bridges). > > It does not seem correct to add this property (describing the DMA limit of the > AHCI controller, a PCI endpoint) on the PCI host bridge/controller. > > This property belongs to the AHCI controller, not the upstream PCI host > bridge/controller. > > AHCI has a specific register to describe if the hardware can support 64-bit DMA > addresses or not, so if my suggested patch works for you, it seems like a more > elegant solution (which also avoids having to abuse device tree properties). > Hi Niklas: Thank you very much for your kindly reply. In i.MX8QM, both AHCI and PCIe are contained in HSIO(High Speed IO) module. The "dma-ranges" property is defined in HSIO dts node actually. BTW, I had tried the method you mentioned before. Unfortunately, it doesn't work for i.MX8QM AHCI. Best Regards Richard Zhu > > Kind regards, > Niklas
On Thu, Aug 08, 2024 at 12:35:01AM +0200, Niklas Cassel wrote: > On Fri, Aug 02, 2024 at 02:30:45AM +0000, Hongxing Zhu wrote: > > > > > > Does this solve your problem: > > > diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c > > > index 581704e61f28..fc86e2c8c42b 100644 > > > --- a/drivers/ata/libahci_platform.c > > > +++ b/drivers/ata/libahci_platform.c > > > @@ -747,12 +747,11 @@ int ahci_platform_init_host(struct platform_device > > > *pdev, > > > ap->ops = &ata_dummy_port_ops; > > > } > > > > > > - if (hpriv->cap & HOST_CAP_64) { > > > - rc = dma_coerce_mask_and_coherent(dev, > > > DMA_BIT_MASK(64)); > > > - if (rc) { > > > - dev_err(dev, "Failed to enable 64-bit DMA.\n"); > > > - return rc; > > > - } > > > + rc = dma_coerce_mask_and_coherent(dev, > > > + DMA_BIT_MASK((hpriv->cap & HOST_CAP_64) ? 64 : > > > 32)); > > > + if (rc) { > > > + dev_err(dev, "DMA enable failed\n"); > > > + return rc; > > > } > > > > > > rc = ahci_reset_controller(host); > > > > > Hi Niklas: > > I'm so sorry to reply late. > > About the 32bit DMA limitation of i.MX8QM AHCI SATA. > > It's seems that one "dma-ranges" property in the DT can let i.MX8QM SATA > > works fine in my past days tests without this commit. > > How about drop these driver changes, and add "dma-ranges" for i.MX8QM SATA? > > Thanks a lot for your kindly help. > > Hello Richard, > > did you try my suggested patch above? > > > If you look at dma-ranges: > https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#dma-ranges > > "dma-ranges" property should be used on a bus device node > (such as PCI host bridges). Yes, 32bit is limited by internal bus farbic, not AHCI controller. It look like hsio-bus { dma-ranges = <low 4G space> sata@addr { ... } } This should be correct reflect hardware behavior. force ahci to 32bit dma mask should be a wordaround. Frank > > It does not seem correct to add this property (describing the DMA limit > of the AHCI controller, a PCI endpoint) on the PCI host bridge/controller. > > This property belongs to the AHCI controller, not the upstream PCI > host bridge/controller. > > AHCI has a specific register to describe if the hardware can support > 64-bit DMA addresses or not, so if my suggested patch works for you, > it seems like a more elegant solution (which also avoids having to > abuse device tree properties). > > > Kind regards, > Niklas
On Thu, Aug 08, 2024 at 10:03:17AM -0400, Frank Li wrote: > On Thu, Aug 08, 2024 at 12:35:01AM +0200, Niklas Cassel wrote: > > On Fri, Aug 02, 2024 at 02:30:45AM +0000, Hongxing Zhu wrote: > > > > > > > Hi Niklas: > > > I'm so sorry to reply late. > > > About the 32bit DMA limitation of i.MX8QM AHCI SATA. > > > It's seems that one "dma-ranges" property in the DT can let i.MX8QM SATA > > > works fine in my past days tests without this commit. > > > How about drop these driver changes, and add "dma-ranges" for i.MX8QM SATA? > > > Thanks a lot for your kindly help. > > > > Hello Richard, > > > > did you try my suggested patch above? > > > > > > If you look at dma-ranges: > > https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#dma-ranges > > > > "dma-ranges" property should be used on a bus device node > > (such as PCI host bridges). > > Yes, 32bit is limited by internal bus farbic, not AHCI controller. If the limit is by the interconnect/bus, then the limit will affect all devices connected to that bus, i.e. both the PCIe controller and the AHCI controller, and using "dma-ranges" in that case is of course correct. I guess I'm mostly surprised that i.MX8QM doesn't already have this property defined in its device tree. Anyway, please send a v5 of this series without the patch in $subject, and we should be able to queue it up for 6.12. Kind regards, Niklas
> -----Original Message----- > From: Niklas Cassel <cassel@kernel.org> > Sent: 2024年8月9日 0:24 > To: Frank Li <frank.li@nxp.com> > Cc: Hongxing Zhu <hongxing.zhu@nxp.com>; tj@kernel.org; > dlemoal@kernel.org; robh@kernel.org; krzk+dt@kernel.org; > conor+dt@kernel.org; shawnguo@kernel.org; s.hauer@pengutronix.de; > festevam@gmail.com; linux-ide@vger.kernel.org; stable@vger.kernel.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; imx@lists.linux.dev; > kernel@pengutronix.de > Subject: Re: [PATCH v4 4/6] ata: ahci_imx: Add 32bits DMA limit for i.MX8QM > AHCI SATA > > On Thu, Aug 08, 2024 at 10:03:17AM -0400, Frank Li wrote: > > On Thu, Aug 08, 2024 at 12:35:01AM +0200, Niklas Cassel wrote: > > > On Fri, Aug 02, 2024 at 02:30:45AM +0000, Hongxing Zhu wrote: > > > > > > > > > Hi Niklas: > > > > I'm so sorry to reply late. > > > > About the 32bit DMA limitation of i.MX8QM AHCI SATA. > > > > It's seems that one "dma-ranges" property in the DT can let > > > > i.MX8QM SATA works fine in my past days tests without this commit. > > > > How about drop these driver changes, and add "dma-ranges" for i.MX8QM > SATA? > > > > Thanks a lot for your kindly help. > > > > > > Hello Richard, > > > > > > did you try my suggested patch above? > > > > > > > > > If you look at dma-ranges: > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fde > > > vicetree-specification.readthedocs.io%2Fen%2Flatest%2Fchapter2-devic > > > > etree-basics.html%23dma-ranges&data=05%7C02%7Chongxing.zhu%40nxp.co > m > > > %7Cb18159f7aa424f3e0d8f08dcb7c68f38%7C686ea1d3bc2b4c6fa92cd99c > 5c3016 > > > > 35%7C0%7C0%7C638587310631122078%7CUnknown%7CTWFpbGZsb3d8eyJ > WIjoiMC4w > > > > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C% > 7C& > > > > sdata=uYJFF7Mci4j068LF1Ew8qrFvc1pzrmWhJS0UqaWtvYQ%3D&reserved=0 > > > > > > "dma-ranges" property should be used on a bus device node (such as > > > PCI host bridges). > > > > Yes, 32bit is limited by internal bus farbic, not AHCI controller. > > If the limit is by the interconnect/bus, then the limit will affect all devices > connected to that bus, i.e. both the PCIe controller and the AHCI controller, and > using "dma-ranges" in that case is of course correct. > > I guess I'm mostly surprised that i.MX8QM doesn't already have this property > defined in its device tree. > > Anyway, please send a v5 of this series without the patch in $subject, and we > should be able to queue it up for 6.12. Hi Niklas: Thank you very much. I had already sent out the v5 series patch-set a few days ago. https://patchwork.kernel.org/project/linux-arm-kernel/cover/1722581213-15221-1-git-send-email-hongxing.zhu@nxp.com/ BTW, I'm a little confused about " without the patch in $subject,". Do you mean to remove the "PATCH" from Subject of each patch? v5: Subject: [PATCH v5 1/5] dt-bindings: ata: Add i.MX8QM AHCI compatible string v6 without patch in $subject: Subject: [ v6 1/5] dt-bindings: ata: Add i.MX8QM AHCI compatible string If yes, I can do that and add Frank's reviewed-by tag in the v6 series. Best Regards Richard Zhu > > > Kind regards, > Niklas
On Fri, Aug 09, 2024 at 08:45:12AM +0000, Hongxing Zhu wrote: > Hi Niklas: > Thank you very much. > I had already sent out the v5 series patch-set a few days ago. > https://patchwork.kernel.org/project/linux-arm-kernel/cover/1722581213-15221-1-git-send-email-hongxing.zhu@nxp.com/ Well, your V5 was not sent to libata (linux-ide) mailing list, and libata maintainers were not in "To:" or "Cc:". > BTW, I'm a little confused about " without the patch in $subject,". > Do you mean to remove the "PATCH" from Subject of each patch? > v5: > Subject: [PATCH v5 1/5] dt-bindings: ata: Add i.MX8QM AHCI compatible string > v6 without patch in $subject: > Subject: [ v6 1/5] dt-bindings: ata: Add i.MX8QM AHCI compatible string > If yes, I can do that and add Frank's reviewed-by tag in the v6 series. I simply meant drop patch: [PATCH v4 4/6] ata: ahci_imx: Add 32bits DMA limit for i.MX8QM AHCI SATA and send the series as a V5. But considering that you sent a V5 already (to the wrong list), please send a V6 to the correct list, with Reviewed-by tags from V5 picked up. Kind regards, Niklas
> -----Original Message----- > From: Niklas Cassel <cassel@kernel.org> > Sent: 2024年8月9日 21:48 > To: Hongxing Zhu <hongxing.zhu@nxp.com> > Cc: Frank Li <frank.li@nxp.com>; tj@kernel.org; dlemoal@kernel.org; > robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org; > shawnguo@kernel.org; s.hauer@pengutronix.de; festevam@gmail.com; > linux-ide@vger.kernel.org; stable@vger.kernel.org; devicetree@vger.kernel.org; > linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; > imx@lists.linux.dev; kernel@pengutronix.de > Subject: Re: [PATCH v4 4/6] ata: ahci_imx: Add 32bits DMA limit for i.MX8QM > AHCI SATA > > On Fri, Aug 09, 2024 at 08:45:12AM +0000, Hongxing Zhu wrote: > > Hi Niklas: > > Thank you very much. > > I had already sent out the v5 series patch-set a few days ago. > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc > > > hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fcover%2F1722581213-15 > 2 > > > 21-1-git-send-email-hongxing.zhu%40nxp.com%2F&data=05%7C02%7Chongxin > g. > > > zhu%40nxp.com%7C0dbdfe3d113a4cf2f97308dcb879e27f%7C686ea1d3bc2b > 4c6fa92 > > > cd99c5c301635%7C0%7C0%7C638588080830018229%7CUnknown%7CTWFp > bGZsb3d8eyJ > > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > 0%7C > > %7C%7C&sdata=HkrgspjOk5lgk%2F8o%2F2hQ4RV86EVZVKbuQM2%2FeaZgB > Co%3D&rese > > rved=0 > > Well, your V5 was not sent to libata (linux-ide) mailing list, and libata maintainers > were not in "To:" or "Cc:". > > > > BTW, I'm a little confused about " without the patch in $subject,". > > Do you mean to remove the "PATCH" from Subject of each patch? > > v5: > > Subject: [PATCH v5 1/5] dt-bindings: ata: Add i.MX8QM AHCI compatible > > string > > v6 without patch in $subject: > > Subject: [ v6 1/5] dt-bindings: ata: Add i.MX8QM AHCI compatible > > string If yes, I can do that and add Frank's reviewed-by tag in the v6 series. > > I simply meant drop patch: > [PATCH v4 4/6] ata: ahci_imx: Add 32bits DMA limit for i.MX8QM AHCI SATA and > send the series as a V5. > > But considering that you sent a V5 already (to the wrong list), please send a V6 to > the correct list, with Reviewed-by tags from > V5 picked up. It's my fault to use a wrong send-email script to send out v5. Okay, v6 would be sent out to the correct email list. Thank you very much. Best Regards Richard Zhu > > > Kind regards, > Niklas
diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c index 4dd98368f8562..e94c0fdea2260 100644 --- a/drivers/ata/ahci_imx.c +++ b/drivers/ata/ahci_imx.c @@ -827,6 +827,9 @@ static const struct scsi_host_template ahci_platform_sht = { static int imx8_sata_probe(struct device *dev, struct imx_ahci_priv *imxpriv) { + if (!(dev->bus_dma_limit)) + dev->bus_dma_limit = DMA_BIT_MASK(32); + imxpriv->sata_phy = devm_phy_get(dev, "sata-phy"); if (IS_ERR(imxpriv->sata_phy)) return dev_err_probe(dev, PTR_ERR(imxpriv->sata_phy),
Since i.MX8QM AHCI SATA only has 32bits DMA capability. Add 32bits DMA limit here. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> --- drivers/ata/ahci_imx.c | 3 +++ 1 file changed, 3 insertions(+)