Re: [PATCH 05/14] qcom: mtd: nand: allocate bam transaction

> qcom_nand_controller *nandc) > if (list_empty(>host_list)) > return -ENODEV; > > + if (nandc->dma_bam_enabled) { > + free_bam_transaction(nandc); > + nandc->bam_txn = alloc_bam_transaction(nandc, > +

Re: [PATCH 02/14] qcom: mtd: nand: add and initialize QPIC DMA resources

f(*nandc->reg_read_buf), GFP_KERNEL); > + > + if (!nandc->reg_read_buf) > + return -ENOMEM; > + > + nandc->chan = dma_request_slave_channel(nandc->dev, "rxtx"); > + if (!nandc->chan) { > +

Re: [PATCH 02/14] qcom: mtd: nand: add and initialize QPIC DMA resources

dc->reg_read_buf), GFP_KERNEL); > + > + if (!nandc->reg_read_buf) > + return -ENOMEM; > + > + nandc->chan = dma_request_slave_channel(nandc->dev, "rxtx"); > + if (!nandc->chan) { > + dev_err(nandc->dev,

Re: [PATCH 03/14] qcom: mtd: nand: Fixed config error for BCH

st->bch_enabled << ECC_CFG_ECC_DISABLE > | 0 << ECC_SW_RESET > | host->cw_data << ECC_NUM_DATA_BYTES > | 1 << ECC_FORCE_CLK_OPEN > This could be patch #1, so basical

Re: [PATCH 03/14] qcom: mtd: nand: Fixed config error for BCH

;bch_enabled << ECC_CFG_ECC_DISABLE > | 0 << ECC_SW_RESET > | host->cw_data << ECC_NUM_DATA_BYTES > | 1 << ECC_FORCE_CLK_OPEN > This could be patch #1, so basically all fixes first

Re: [PATCH 02/14] qcom: mtd: nand: add and initialize QPIC DMA resources

> + if (nandc->dma_bam_enabled) { > + if (nandc->tx_chan) > + dma_release_channel(nandc->tx_chan); > + > + if (nandc->rx_chan) > + dma_release_channel(nandc->rx_chan); > + > + if (nandc->

Re: [PATCH 02/14] qcom: mtd: nand: add and initialize QPIC DMA resources

) { > + if (nandc->tx_chan) > + dma_release_channel(nandc->tx_chan); > + > + if (nandc->rx_chan) > + dma_release_channel(nandc->rx_chan); > + > + if (nandc->cmd_chan) > + dma_release_channel(nandc->cmd_chan); > + } else { > + if (nandc->chan) > + dma_release_channel(nandc->chan); > + } > } > > /* one time setup of a few nand controller registers */ > @@ -2063,16 +2119,20 @@ static int qcom_nandc_parse_dt(struct platform_device > *pdev) > struct device_node *np = nandc->dev->of_node; > int ret; > > - ret = of_property_read_u32(np, "qcom,cmd-crci", >cmd_crci); > - if (ret) { > - dev_err(nandc->dev, "command CRCI unspecified\n"); > - return ret; > - } > + if (!nandc->dma_bam_enabled) { instead, can we simply do if (is_bam) return; here ? Regards, Sricharan -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Re: [PATCH 01/14] qcom: mtd: nand: Add driver data for QPIC DMA

+ * driver probe time > + * @ecc_modes - ecc mode for nand > + * @dma_bam_enabled - whether this driver is using bam > + */ > +struct qcom_nand_driver_data { > + u32 ecc_modes; > + bool dma_bam_enabled; > +}; > + > static inline struct qcom_nand_host *to_qcom_na

Re: [PATCH 01/14] qcom: mtd: nand: Add driver data for QPIC DMA

> + * @ecc_modes - ecc mode for nand > + * @dma_bam_enabled - whether this driver is using bam > + */ > +struct qcom_nand_driver_data { > + u32 ecc_modes; > + bool dma_bam_enabled; > +}; > + > static inline struct qcom_nand_host *to_qcom_nand_host(struct nand_

[PATCH 3/3] dt-binding: remoteproc: Add the bindings required for Q6 - WCSS core

IPQ8074 has an integrated Q6V5 Hexagon dsp - Lithium Wlan (WCSS) core. This patch adds the required bindings to load, boot, shutdown that remoteproc subsystem. Signed-off-by: Sricharan R <sricha...@codeaurora.org> --- .../bindings/remoteproc/qcom,q6v5-wcss.txt

[PATCH 3/3] dt-binding: remoteproc: Add the bindings required for Q6 - WCSS core

IPQ8074 has an integrated Q6V5 Hexagon dsp - Lithium Wlan (WCSS) core. This patch adds the required bindings to load, boot, shutdown that remoteproc subsystem. Signed-off-by: Sricharan R --- .../bindings/remoteproc/qcom,q6v5-wcss.txt | 139 + 1 file changed, 139

[PATCH 2/3] drivers: remoteproc: Add Hexagon Q6 - WCSS integrated core driver

IPQ8074 has an integrated Hexagon dsp core Q6v5 and a wireless lan (Lithium) IP. This patch adds the remoteproc driver to reset, load and boot Q6 firmware. Signed-off-by: Sricharan R <sricha...@codeaurora.org> --- drivers/remoteproc/Kconfig | 13 + drivers/remoteproc/Makefile

[PATCH 2/3] drivers: remoteproc: Add Hexagon Q6 - WCSS integrated core driver

IPQ8074 has an integrated Hexagon dsp core Q6v5 and a wireless lan (Lithium) IP. This patch adds the remoteproc driver to reset, load and boot Q6 firmware. Signed-off-by: Sricharan R --- drivers/remoteproc/Kconfig | 13 + drivers/remoteproc/Makefile| 1 + drivers/remoteproc/q6v5

[PATCH 1/3] drivers: remoteproc: Make mdt_loader firmware authentication optional

qcom_mdt_load function loads the mdt type firmware and authenticates it as well. Make the authentication only when requested by the caller, so that the function can be used by self-authenticating remoteproc as well. Signed-off-by: Sricharan R <sricha...@codeaurora.org> --- drivers/remo

[PATCH 1/3] drivers: remoteproc: Make mdt_loader firmware authentication optional

qcom_mdt_load function loads the mdt type firmware and authenticates it as well. Make the authentication only when requested by the caller, so that the function can be used by self-authenticating remoteproc as well. Signed-off-by: Sricharan R --- drivers/remoteproc/qcom_adsp_pil.c | 3

[PATCH 0/3] Add remoteproc driver for Hexagon Q6 - WCSS integrated core

firmware like the Q6v5 core in IPQ8074. Sricharan R (3): drivers: remoteproc: Make mdt_loader firmware authentication optional drivers: remoteproc: Add Hexagon Q6 - WCSS integrated core driver dt-binding: remoteproc: Add the bindings required for Hexagon - WCSS core .../bindings

[PATCH 0/3] Add remoteproc driver for Hexagon Q6 - WCSS integrated core

firmware like the Q6v5 core in IPQ8074. Sricharan R (3): drivers: remoteproc: Make mdt_loader firmware authentication optional drivers: remoteproc: Add Hexagon Q6 - WCSS integrated core driver dt-binding: remoteproc: Add the bindings required for Hexagon - WCSS core .../bindings

Re: [PATCH] dmaengine: qcom-bam: Process multiple pending descriptors

Hi Vinod, On 6/15/2017 9:40 AM, Vinod Koul wrote: > On Wed, Jun 07, 2017 at 05:59:07PM +0530, Sricharan R wrote: >> The bam dmaengine has a circular FIFO to which we >> add hw descriptors that describes the transaction. >> The FIFO has space for about 4096 hw descriptors. &

Re: [PATCH] dmaengine: qcom-bam: Process multiple pending descriptors

Hi Vinod, On 6/15/2017 9:40 AM, Vinod Koul wrote: > On Wed, Jun 07, 2017 at 05:59:07PM +0530, Sricharan R wrote: >> The bam dmaengine has a circular FIFO to which we >> add hw descriptors that describes the transaction. >> The FIFO has space for about 4096 hw descriptors. &

Re: [PATCH 10/18] spi: qup: Fix DMA mode interrupt handling

Hi Andy, On 6/15/2017 1:36 AM, Andy Gross wrote: > On Wed, Jun 14, 2017 at 12:51:11PM +0530, Sricharan R wrote: >> Hi Varada, >> >> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote: >>> This is needed for v1, where the i/o completion is not >>> handle

Re: [PATCH 10/18] spi: qup: Fix DMA mode interrupt handling

Hi Andy, On 6/15/2017 1:36 AM, Andy Gross wrote: > On Wed, Jun 14, 2017 at 12:51:11PM +0530, Sricharan R wrote: >> Hi Varada, >> >> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote: >>> This is needed for v1, where the i/o completion is not >>> handle

Re: [PATCH 11/18] spi: qup: properly detect extra interrupts

Hi Andy, On 6/15/2017 1:29 AM, Andy Gross wrote: > On Wed, Jun 14, 2017 at 12:57:25PM +0530, Sricharan R wrote: >> Hi Varada, >> >> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote: >>> It's possible for a SPI transaction to complete and get another >&

Re: [PATCH 11/18] spi: qup: properly detect extra interrupts

Hi Andy, On 6/15/2017 1:29 AM, Andy Gross wrote: > On Wed, Jun 14, 2017 at 12:57:25PM +0530, Sricharan R wrote: >> Hi Varada, >> >> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote: >>> It's possible for a SPI transaction to complete and get another >&

Re: [PATCH 07/18] spi: qup: Fix transaction done signaling

Hi Andy, On 6/15/2017 1:21 AM, Andy Gross wrote: > On Wed, Jun 14, 2017 at 12:43:43PM +0530, Sricharan R wrote: >> Hi Varada, >> >> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote: >>> Wait to signal done until we get all of the interrupts we are expecting >&g

Re: [PATCH 07/18] spi: qup: Fix transaction done signaling

Hi Andy, On 6/15/2017 1:21 AM, Andy Gross wrote: > On Wed, Jun 14, 2017 at 12:43:43PM +0530, Sricharan R wrote: >> Hi Varada, >> >> On 6/14/2017 11:22 AM, Varadarajan Narayanan wrote: >>> Wait to signal done until we get all of the interrupts we are expecting >&g

Re: [PATCH 11/18] spi: qup: properly detect extra interrupts

->error = error; > + controller->xfer = done ? NULL : xfer; > + spin_unlock(>lock); > + > + if (done) > complete(>done); > Its not clear, why the driver is setting the controller->xfer = NULL and restoring it inside the irq. This patch seems to fix things on top of that. Regards, Sricharan -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 11/18] spi: qup: properly detect extra interrupts

LL : xfer; > + spin_unlock(>lock); > + > + if (done) > complete(>done); > Its not clear, why the driver is setting the controller->xfer = NULL and restoring it inside the irq. This patch seems to fix things on top of that. Regards, Sricharan -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 10/18] spi: qup: Fix DMA mode interrupt handling

flags & QUP_OP_MAX_INPUT_DONE_FLAG) > + complete(>rxc); > + if (opflags & QUP_OP_OUT_SERVICE_FLAG && > + opflags & QUP_OP_MAX_OUTPUT_DONE_FLAG) > + complete(>txc); > + } else { Is this because in patch

Re: [PATCH 10/18] spi: qup: Fix DMA mode interrupt handling

t; + complete(>rxc); > + if (opflags & QUP_OP_OUT_SERVICE_FLAG && > + opflags & QUP_OP_MAX_OUTPUT_DONE_FLAG) > + complete(>txc); > + } else { Is this because in patch #8 that we do not populate the dma callback for v1. If th

Re: [PATCH 08/18] spi: qup: Handle v1 dma completion differently

ret = spi_qup_prep_sg(master, xfer, DMA_MEM_TO_DEV, > - spi_qup_dma_done, >txc); > + done, >txc); > if (ret) > return ret; > > Not sure why we cannot use

Re: [PATCH 08/18] spi: qup: Handle v1 dma completion differently

ret = spi_qup_prep_sg(master, xfer, DMA_MEM_TO_DEV, > - spi_qup_dma_done, >txc); > + done, >txc); > if (ret) > return ret; > > Not sure why we cannot use dma callback for V1 ? Regards, Sricharan -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 07/18] spi: qup: Fix transaction done signaling

the bytes implies transfer complete (or) why not just check only for QUP_OP_MAX_INPUT_DONE_FLAG ? Regards, Sricharan -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 07/18] spi: qup: Fix transaction done signaling

ytes == xfer->len || error) > + if ((controller->rx_bytes == xfer->len && > + (opflags & QUP_OP_MAX_INPUT_DONE_FLAG)) || error) Not sure why we need this additional check, because having read all the bytes implies transfer complete (or) why not just c

[PATCH] dmaengine: qcom-bam: Process multiple pending descriptors

) MTD_SPEEDTEST READ PAGE: 3860 KiB/s MTD_SPEEDTEST WRITE PAGE: 2837 KiB/s IOZONE READ: 2677 KB/s IOZONE WRITE: 1308 KB/s bam dma interrupts (after tests): 58806 Signed-off-by: Sricharan R <sricha...@codeaurora.org> --- drivers/dm

[PATCH] dmaengine: qcom-bam: Process multiple pending descriptors

) MTD_SPEEDTEST READ PAGE: 3860 KiB/s MTD_SPEEDTEST WRITE PAGE: 2837 KiB/s IOZONE READ: 2677 KB/s IOZONE WRITE: 1308 KB/s bam dma interrupts (after tests): 58806 Signed-off-by: Sricharan R --- drivers/dma/qcom/bam_dma.c | 180

Re: [PATCH v4 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

b11: Pull-Up > > This information wasn't mentioned anywhere. In fact, the special pull-up > configuration was only discovered due to an issue with the qpic NAND on > the Cisco Meraki MR33. So I wonder what does the gpio-pull look like for > the IPQ8074? Is it the same as the IPQ4

Re: [PATCH v4 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

anywhere. In fact, the special pull-up > configuration was only discovered due to an issue with the qpic NAND on > the Cisco Meraki MR33. So I wonder what does the gpio-pull look like for > the IPQ8074? Is it the same as the IPQ40XX or does it follow the older > SoCs? > > I'm asking th

Re: [PATCH v6 3/6] ACPI/IORT: Ignore all errors except EPROBE_DEFER

Hi Rafael, On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote: > On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote: >> While deferring the probe of IOMMU masters, xlate and >> add_device callbacks called from iort_iommu_configure >> can pass back error values like

Re: [PATCH v6 3/6] ACPI/IORT: Ignore all errors except EPROBE_DEFER

Hi Rafael, On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote: > On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote: >> While deferring the probe of IOMMU masters, xlate and >> add_device callbacks called from iort_iommu_configure >> can pass back error values like

[PATCH v6 2/6] iommu: of: Ignore all errors except EPROBE_DEFER

from of_iommu_configure. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Reported-by: Geert Uytterhoeven <ge...@linux-m68k.org> Tested-by: Magnus Damn <magnus.d...@gmail.com> Signed-off-by: Sricharan R <sricha...@codeauror

[PATCH v6 2/6] iommu: of: Ignore all errors except EPROBE_DEFER

from of_iommu_configure. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Reported-by: Geert Uytterhoeven Tested-by: Magnus Damn Signed-off-by: Sricharan R --- drivers/iommu/of_iommu.c | 6 ++ drivers/of/device.c | 4 ++-- 2 files

[PATCH v6 6/6] arm: dma-mapping: Reset the device's dma_ops

. This takes care of resetting the dma_ops in the teardown path. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> Signed-off-by: Sricharan R <sricha...@codeau

[PATCH v6 5/6] ACPI/IORT: Move the check to get iommu_ops from translated fwspec

From: Lorenzo Pieralisi With IOMMU probe deferral, iort_iommu_configure can be called multiple times for the same device. Hence we have a check to see if the device's fwspec is already translated and return the iommu_ops from that directly. But the check is wrongly

[PATCH v6 4/6] ARM: dma-mapping: Don't tear down third-party mappings

From: Laurent Pinchart arch_setup_dma_ops() is used in device probe code paths to create an IOMMU mapping and attach it to the device. The function assumes that the device is attached to a device-specific IOMMU instance (or at least a device-specific

[PATCH v6 4/6] ARM: dma-mapping: Don't tear down third-party mappings

From: Laurent Pinchart arch_setup_dma_ops() is used in device probe code paths to create an IOMMU mapping and attach it to the device. The function assumes that the device is attached to a device-specific IOMMU instance (or at least a device-specific TLB in a shared IOMMU instance) and thus

[PATCH v6 6/6] arm: dma-mapping: Reset the device's dma_ops

. This takes care of resetting the dma_ops in the teardown path. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reviewed-by: Laurent Pinchart Signed-off-by: Sricharan R --- arch/arm/mm/dma-mapping.c | 25 ++-

[PATCH v6 5/6] ACPI/IORT: Move the check to get iommu_ops from translated fwspec

From: Lorenzo Pieralisi With IOMMU probe deferral, iort_iommu_configure can be called multiple times for the same device. Hence we have a check to see if the device's fwspec is already translated and return the iommu_ops from that directly. But the check is wrongly placed in iort_iommu_xlate,

[PATCH v6 3/6] ACPI/IORT: Ignore all errors except EPROBE_DEFER

-EPROBE_DEFER from iort_iommu_configure. Fixes: 5a1bb638d567 ("drivers: acpi: Handle IOMMU lookup failure with deferred probing or error") Signed-off-by: Sricharan R <sricha...@codeaurora.org> --- drivers/acpi/arm64/iort.c | 6 ++ drivers/acpi/scan.c | 4 ++-- 2 files changed, 8

[PATCH v6 3/6] ACPI/IORT: Ignore all errors except EPROBE_DEFER

-EPROBE_DEFER from iort_iommu_configure. Fixes: 5a1bb638d567 ("drivers: acpi: Handle IOMMU lookup failure with deferred probing or error") Signed-off-by: Sricharan R --- drivers/acpi/arm64/iort.c | 6 ++ drivers/acpi/scan.c | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-)

[PATCH v6 1/6] iommu: of: Fix check for returning EPROBE_DEFER

inux-m68k.org> Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> Tested-by: Will Deacon <will.dea...@arm.com> Tested-by: Magnus Damn <magnus.d...@gmail.com> Acked-by: Will Deacon <will.dea...@arm.com> Signed-off-by: Sricharan R <sricha...@codeaurora.org&g

[PATCH v6 1/6] iommu: of: Fix check for returning EPROBE_DEFER

y: Laurent Pinchart Tested-by: Will Deacon Tested-by: Magnus Damn Acked-by: Will Deacon Signed-off-by: Sricharan R --- drivers/iommu/of_iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index 9f44ee8..e6e9bec 100644 --- a/drivers/iommu/

Re: [PATCH v2] arm: dma-mapping: Reset the device's dma_ops

Hi Laurent, On 5/26/2017 7:44 PM, Laurent Pinchart wrote: > Hi Sricharan, > > Thank you for the patch. > > On Friday 26 May 2017 16:13:37 Sricharan R wrote: >> arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops() >> ,dma_ops should be cleared in the tea

Re: [PATCH v2] arm: dma-mapping: Reset the device's dma_ops

Hi Laurent, On 5/26/2017 7:44 PM, Laurent Pinchart wrote: > Hi Sricharan, > > Thank you for the patch. > > On Friday 26 May 2017 16:13:37 Sricharan R wrote: >> arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops() >> ,dma_ops should be cleared in the tea

[PATCH v2] arm: dma-mapping: Reset the device's dma_ops

. This takes care of resetting the dma_ops in the teardown path. Signed-off-by: Sricharan R <sricha...@codeaurora.org> Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") --- arch/arm/mm/dma-mapping.c | 25 ++---

[PATCH v2] arm: dma-mapping: Reset the device's dma_ops

. This takes care of resetting the dma_ops in the teardown path. Signed-off-by: Sricharan R Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") --- arch/arm/mm/dma-mapping.c | 25 ++--- 1 file changed, 10 inserti

Re: [RESEND: PATCH v4 2/4] remoteproc: qcom: refactor mss fw image loading sequence

Hi Bjorn, On 5/26/2017 12:33 AM, Bjorn Andersson wrote: > On Mon 22 May 06:26 PDT 2017, Dwivedi, Avaneesh Kumar (avani) wrote: >> On 5/22/2017 4:07 PM, Sricharan R wrote: >>> Hi, >>> >>> On 5/22/2017 3:03 PM, Dwivedi, Avaneesh Kumar (avani) wrote: >>>&

Re: [RESEND: PATCH v4 2/4] remoteproc: qcom: refactor mss fw image loading sequence

Hi Bjorn, On 5/26/2017 12:33 AM, Bjorn Andersson wrote: > On Mon 22 May 06:26 PDT 2017, Dwivedi, Avaneesh Kumar (avani) wrote: >> On 5/22/2017 4:07 PM, Sricharan R wrote: >>> Hi, >>> >>> On 5/22/2017 3:03 PM, Dwivedi, Avaneesh Kumar (avani) wrote: >>>&

[PATCH v5 4/5] ARM: dma-mapping: Don't tear third-party mappings

From: Laurent Pinchart arch_setup_dma_ops() is used in device probe code paths to create an IOMMU mapping and attach it to the device. The function assumes that the device is attached to a device-specific IOMMU instance (or at least a device-specific

[PATCH v5 4/5] ARM: dma-mapping: Don't tear third-party mappings

From: Laurent Pinchart arch_setup_dma_ops() is used in device probe code paths to create an IOMMU mapping and attach it to the device. The function assumes that the device is attached to a device-specific IOMMU instance (or at least a device-specific TLB in a shared IOMMU instance) and thus

[PATCH v5 5/5] ACPI/IORT: Move the check to get iommu_ops from translated fwspec

From: Lorenzo Pieralisi With IOMMU probe deferral, iort_iommu_configure can be called multiple times for the same device. Hence we have a check to see if the device's fwspec is already translated and return the iommu_ops from that directly. But the check is wrongly

[PATCH v5 5/5] ACPI/IORT: Move the check to get iommu_ops from translated fwspec

From: Lorenzo Pieralisi With IOMMU probe deferral, iort_iommu_configure can be called multiple times for the same device. Hence we have a check to see if the device's fwspec is already translated and return the iommu_ops from that directly. But the check is wrongly placed in iort_iommu_xlate,

[PATCH v5 3/5] ACPI/IORT: Ignore all errors except EPROBE_DEFER

-EPROBE_DEFER from iort_iommu_configure. Fixes: 5a1bb638d567 ("drivers: acpi: Handle IOMMU lookup failure with deferred probing or error") Signed-off-by: Sricharan R <sricha...@codeaurora.org> --- [v5] Added the check in acpi_dma_configure drivers/acpi/arm64/iort.c | 6 ++ drivers/acpi/

[PATCH v5 3/5] ACPI/IORT: Ignore all errors except EPROBE_DEFER

-EPROBE_DEFER from iort_iommu_configure. Fixes: 5a1bb638d567 ("drivers: acpi: Handle IOMMU lookup failure with deferred probing or error") Signed-off-by: Sricharan R --- [v5] Added the check in acpi_dma_configure drivers/acpi/arm64/iort.c | 6 ++ drivers/acpi/scan.c | 4 ++-- 2 files

[PATCH v5 2/5] iommu: of: Ignore all errors except EPROBE_DEFER

from of_iommu_configure. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Reported-by: Geert Uytterhoeven <ge...@linux-m68k.org> Tested-by: Magnus Damn <magnus.d...@gmail.com> Signed-off-by: Sricharan R <sricha...@codeaurora.org&

[PATCH v5 1/5] iommu: of: Fix check for returning EPROBE_DEFER

to is marked in DT as 'status=disabled', then the IOMMU is never is going to get probed. So simply return NULL and let the master work without an IOMMU. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Signed-off-by: Sricharan R <sricha...@c

[PATCH v5 2/5] iommu: of: Ignore all errors except EPROBE_DEFER

from of_iommu_configure. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Reported-by: Geert Uytterhoeven Tested-by: Magnus Damn Signed-off-by: Sricharan R --- [v5] Added the check in of_dma_configure drivers/iommu/of_iommu.c | 6 +

[PATCH v5 1/5] iommu: of: Fix check for returning EPROBE_DEFER

to is marked in DT as 'status=disabled', then the IOMMU is never is going to get probed. So simply return NULL and let the master work without an IOMMU. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Signed-off-by: Sricharan R Reported-by: Geert Uy

Re: [PATCH V11 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

Hi Lorenzo, On 5/23/2017 2:22 PM, Lorenzo Pieralisi wrote: > On Tue, May 23, 2017 at 02:26:10AM -0400, Nate Watterson wrote: >> Hi Sricharan, >> >> On 4/10/2017 7:21 AM, Sricharan R wrote: >>> This is an equivalent to the DT's handling of the iommu master's probe

Re: [PATCH V11 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

Hi Lorenzo, On 5/23/2017 2:22 PM, Lorenzo Pieralisi wrote: > On Tue, May 23, 2017 at 02:26:10AM -0400, Nate Watterson wrote: >> Hi Sricharan, >> >> On 4/10/2017 7:21 AM, Sricharan R wrote: >>> This is an equivalent to the DT's handling of the iommu master's probe

Re: [PATCH V11 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

Hi, On 5/23/2017 11:56 AM, Nate Watterson wrote: > Hi Sricharan, > > On 4/10/2017 7:21 AM, Sricharan R wrote: >> This is an equivalent to the DT's handling of the iommu master's probe >> with deferred probing when the corrsponding iommu is not probed yet. >> The lac

Re: [PATCH V11 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

Hi, On 5/23/2017 11:56 AM, Nate Watterson wrote: > Hi Sricharan, > > On 4/10/2017 7:21 AM, Sricharan R wrote: >> This is an equivalent to the DT's handling of the iommu master's probe >> with deferred probing when the corrsponding iommu is not probed yet. >> The lac

Re: [PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER

Hi Lorenzo, On 5/22/2017 5:01 PM, Lorenzo Pieralisi wrote: > On Mon, May 22, 2017 at 04:35:43PM +0530, Sricharan R wrote: >> Hi Lorenzo, >> >> On 5/22/2017 4:07 PM, Lorenzo Pieralisi wrote: >>> Hi Sricharan, >>> >>> On Thu, May 18, 2017 at 08:24:16P

Re: [PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER

Hi Lorenzo, On 5/22/2017 5:01 PM, Lorenzo Pieralisi wrote: > On Mon, May 22, 2017 at 04:35:43PM +0530, Sricharan R wrote: >> Hi Lorenzo, >> >> On 5/22/2017 4:07 PM, Lorenzo Pieralisi wrote: >>> Hi Sricharan, >>> >>> On Thu, May 18, 2017 at 08:24:16P

Re: [PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER

Hi Lorenzo, On 5/22/2017 4:07 PM, Lorenzo Pieralisi wrote: > Hi Sricharan, > > On Thu, May 18, 2017 at 08:24:16PM +0530, Sricharan R wrote: >> While deferring the probe of IOMMU masters, xlate and >> add_device callbacks called from iort_iommu_configure >> can pass bac

Re: [PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER

Hi Lorenzo, On 5/22/2017 4:07 PM, Lorenzo Pieralisi wrote: > Hi Sricharan, > > On Thu, May 18, 2017 at 08:24:16PM +0530, Sricharan R wrote: >> While deferring the probe of IOMMU masters, xlate and >> add_device callbacks called from iort_iommu_configure >> can pass bac

Re: [RESEND: PATCH v4 2/4] remoteproc: qcom: refactor mss fw image loading sequence

Hi, On 5/22/2017 3:03 PM, Dwivedi, Avaneesh Kumar (avani) wrote: > > > On 5/20/2017 8:25 AM, Sricharan R wrote: >> Hi Bjorn/Avaneesh, >> >> On 5/16/2017 11:32 PM, Avaneesh Kumar Dwivedi wrote: >>> This patch refactor code to first load all firmware

Re: [RESEND: PATCH v4 2/4] remoteproc: qcom: refactor mss fw image loading sequence

Hi, On 5/22/2017 3:03 PM, Dwivedi, Avaneesh Kumar (avani) wrote: > > > On 5/20/2017 8:25 AM, Sricharan R wrote: >> Hi Bjorn/Avaneesh, >> >> On 5/16/2017 11:32 PM, Avaneesh Kumar Dwivedi wrote: >>> This patch refactor code to first load all firmware

Re: [RESEND: PATCH v4 2/4] remoteproc: qcom: refactor mss fw image loading sequence

B_MBA_COMMAND_REG); > + writel(size, qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG); For ipq8074 [1], wcnss core has an Q6V5 version of the ip for which the initialization/boot sequence is pretty much the same as that has been added for msm8996 in this series. So wanted to understan

Re: [RESEND: PATCH v4 2/4] remoteproc: qcom: refactor mss fw image loading sequence

writel(size, qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG); For ipq8074 [1], wcnss core has an Q6V5 version of the ip for which the initialization/boot sequence is pretty much the same as that has been added for msm8996 in this series. So wanted to understand if its better to use this remoteproc it

[PATCH V4 1/4] iommu: of: Fix check for returning EPROBE_DEFER

to is marked in DT as 'status=disabled', then the IOMMU is never is going to get probed. So simply return NULL and let the master work without an IOMMU. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Signed-off-by: Sricharan R <sricha...@c

[PATCH V4 1/4] iommu: of: Fix check for returning EPROBE_DEFER

to is marked in DT as 'status=disabled', then the IOMMU is never is going to get probed. So simply return NULL and let the master work without an IOMMU. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Signed-off-by: Sricharan R Reported-by: Geert Uy

[PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER

ilure with deferred probing or error") Signed-off-by: Sricharan R <sricha...@codeaurora.org> --- [V4] Added this patch newly. drivers/acpi/arm64/iort.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index c5fecf9

[PATCH V4 3/4] ACPI/IORT: Ignore all errors except EPROBE_DEFER

ilure with deferred probing or error") Signed-off-by: Sricharan R --- [V4] Added this patch newly. drivers/acpi/arm64/iort.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c index c5fecf9..16e101f 100644 --- a/drivers/acpi/ar

[PATCH V4 4/4] ARM: dma-mapping: Don't tear third-party mappings

From: Laurent Pinchart arch_setup_dma_ops() is used in device probe code paths to create an IOMMU mapping and attach it to the device. The function assumes that the device is attached to a device-specific IOMMU instance (or at least a device-specific

[PATCH V4 4/4] ARM: dma-mapping: Don't tear third-party mappings

From: Laurent Pinchart arch_setup_dma_ops() is used in device probe code paths to create an IOMMU mapping and attach it to the device. The function assumes that the device is attached to a device-specific IOMMU instance (or at least a device-specific TLB in a shared IOMMU instance) and thus

[PATCH V4 2/4] iommu: of: Ignore all errors except EPROBE_DEFER

ilure with deferred probing or error") Reported-by: Geert Uytterhoeven <ge...@linux-m68k.org> Tested-by: Magnus Damn <magnus.d...@gmail.com> Signed-off-by: Sricharan R <sricha...@codeaurora.org> --- [V4] Reworded commit log and changed dev_info to dev_dbg drivers/iommu/of_iommu.c |

[PATCH V4 2/4] iommu: of: Ignore all errors except EPROBE_DEFER

ilure with deferred probing or error") Reported-by: Geert Uytterhoeven Tested-by: Magnus Damn Signed-off-by: Sricharan R --- [V4] Reworded commit log and changed dev_info to dev_dbg drivers/iommu/of_iommu.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/iommu/of_iommu.c b/dri

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Laurent, On 5/18/2017 7:13 PM, Laurent Pinchart wrote: > Hi Sricharan > > On Thursday 18 May 2017 19:08:12 Sricharan R wrote: >> On 5/18/2017 6:00 PM, Laurent Pinchart wrote: >>> On Thursday 18 May 2017 17:26:14 Sricharan R wrote: >>>> On 5/18/

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Laurent, On 5/18/2017 7:13 PM, Laurent Pinchart wrote: > Hi Sricharan > > On Thursday 18 May 2017 19:08:12 Sricharan R wrote: >> On 5/18/2017 6:00 PM, Laurent Pinchart wrote: >>> On Thursday 18 May 2017 17:26:14 Sricharan R wrote: >>>> On 5/18/

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Laurent, On 5/18/2017 6:00 PM, Laurent Pinchart wrote: > Hi Sricharan, > > On Thursday 18 May 2017 17:26:14 Sricharan R wrote: >> On 5/18/2017 4:09 PM, Laurent Pinchart wrote: >>> On Thursday 18 May 2017 15:37:09 Sricharan R wrote: >>>> While deferring th

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Laurent, On 5/18/2017 6:00 PM, Laurent Pinchart wrote: > Hi Sricharan, > > On Thursday 18 May 2017 17:26:14 Sricharan R wrote: >> On 5/18/2017 4:09 PM, Laurent Pinchart wrote: >>> On Thursday 18 May 2017 15:37:09 Sricharan R wrote: >>>> While deferring th

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Laurent, On 5/18/2017 4:09 PM, Laurent Pinchart wrote: > Hi Sricharan, > > Thank you for the patch. > > On Thursday 18 May 2017 15:37:09 Sricharan R wrote: >> While deferring the probe of IOMMU masters, >> xlate and add_device callback can pass back error values &

Re: [PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

Hi Laurent, On 5/18/2017 4:09 PM, Laurent Pinchart wrote: > Hi Sricharan, > > Thank you for the patch. > > On Thursday 18 May 2017 15:37:09 Sricharan R wrote: >> While deferring the probe of IOMMU masters, >> xlate and add_device callback can pass back error values &

[PATCH V2 3/3] ARM: dma-mapping: Don't tear third-party mappings

From: Laurent Pinchart arch_setup_dma_ops() is used in device probe code paths to create an IOMMU mapping and attach it to the device. The function assumes that the device is attached to a device-specific IOMMU instance (or at least a device-specific

[PATCH V2 3/3] ARM: dma-mapping: Don't tear third-party mappings

From: Laurent Pinchart arch_setup_dma_ops() is used in device probe code paths to create an IOMMU mapping and attach it to the device. The function assumes that the device is attached to a device-specific IOMMU instance (or at least a device-specific TLB in a shared IOMMU instance) and thus

[PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

without an IOMMU. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Reported-by: Geert Uytterhoeven <ge...@linux-m68k.org> Tested-by: Magnus Damn <magnus.d...@gmail.com> Signed-off-by: Sricharan R <sricha...@codeaurora.org> ---

[PATCH V2 2/3] iommu: of: Ignore all errors except EPROBE_DEFER

without an IOMMU. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Reported-by: Geert Uytterhoeven Tested-by: Magnus Damn Signed-off-by: Sricharan R --- [V2] Corrected spelling/case in commit log drivers/iommu/of_iommu.c | 6 ++ 1 file

[PATCH V2 1/3] iommu: of: Fix check for returning EPROBE_DEFER

to is marked in DT as 'status=disabled', then the IOMMU is never is going to get probed. So simply return NULL and let the master work without an IOMMU. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Signed-off-by: Sricharan R <sricha...@c

[PATCH V2 1/3] iommu: of: Fix check for returning EPROBE_DEFER

to is marked in DT as 'status=disabled', then the IOMMU is never is going to get probed. So simply return NULL and let the master work without an IOMMU. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Signed-off-by: Sricharan R Reported-by: Geert Uy

Re: [PATCH 1/3] iommu: of: Fix check for returning EPROBE_DEFER

Hi Bjorn, On 5/17/2017 10:34 PM, Bjorn Helgaas wrote: > On Wed, May 17, 2017 at 05:00:07PM +0530, Sricharan R wrote: >> Now with iommu probe deferral, we return -EPROBE_DEFER >> for master's that are connected to an iommu which is not > > s/master's/masters/ > > s/i

<    6   7   8   9   10   11   12   13   14   15   >