t's update the entries accordingly.
Fixes: bc52497a595d ("MAINTAINERS: update entry for ARM/berlin")
Signed-off-by: Jisheng Zhang
Reported-by: Joe Perches
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a255240d1452.
On Fri, 28 Sep 2018 14:51:32 -0700 Joe Perches wrote:
> Please fix this defect appropriately.
>
> linux-next MAINTAINERS section:
>
> 2111ARM/Synaptics Berlin SoC support
> 2112 M: Jisheng Zhang
> 2113M: Sebastian Hesselbar
On Fri, 28 Sep 2018 14:51:32 -0700 Joe Perches wrote:
> Please fix this defect appropriately.
>
> linux-next MAINTAINERS section:
>
> 2111ARM/Synaptics Berlin SoC support
> 2112 M: Jisheng Zhang
> 2113M: Sebastian Hesselbar
Add initial dtsi file to support Synaptics AS370 SoC with quad
Cortex-A53 CPUs.
Signed-off-by: Jisheng Zhang
---
arch/arm64/boot/dts/synaptics/as370.dtsi | 173 +++
1 file changed, 173 insertions(+)
create mode 100644 arch/arm64/boot/dts/synaptics/as370.dtsi
diff --git
Add initial dtsi file to support Synaptics AS370 SoC with quad
Cortex-A53 CPUs.
Signed-off-by: Jisheng Zhang
---
arch/arm64/boot/dts/synaptics/as370.dtsi | 173 +++
1 file changed, 173 insertions(+)
create mode 100644 arch/arm64/boot/dts/synaptics/as370.dtsi
diff --git
The AS370 SoC is a new derivative of the berlin family. However, the
SoC isn't named as berlin*.
Signed-off-by: Jisheng Zhang
---
Documentation/devicetree/bindings/arm/syna.txt | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm
The AS370 SoC is a new derivative of the berlin family. However, the
SoC isn't named as berlin*.
Signed-off-by: Jisheng Zhang
---
Documentation/devicetree/bindings/arm/syna.txt | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm
Move berlin binding documentation as part of transition from Marvell
berlin to Synaptics SoC.
Signed-off-by: Jisheng Zhang
Acked-by: Rob Herring
---
.../bindings/arm/{marvell/marvell,berlin.txt => syna.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentat
Move berlin binding documentation as part of transition from Marvell
berlin to Synaptics SoC.
Signed-off-by: Jisheng Zhang
Acked-by: Rob Herring
---
.../bindings/arm/{marvell/marvell,berlin.txt => syna.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentat
aliases
- uart@0c00 => serial@c00
Jisheng Zhang (3):
dt-bindings: arm: move berlin binding documentation to syna.txt
dt-bindings: arm: syna: add support for the AS370 SoC
arm64: dts: synaptics: add dtsi file for Synaptics AS370 SoC
.../{marvell/marvell,berlin.txt => syna.txt} | 11 +-
aliases
- uart@0c00 => serial@c00
Jisheng Zhang (3):
dt-bindings: arm: move berlin binding documentation to syna.txt
dt-bindings: arm: syna: add support for the AS370 SoC
arm64: dts: synaptics: add dtsi file for Synaptics AS370 SoC
.../{marvell/marvell,berlin.txt => syna.txt} | 11 +-
If hosts provides ops->adma_write_desc, we should not fall back to the
general sdhci_adma_write_desc().
Signed-off-by: Jisheng Zhang
---
Hi Ulf, Adrian,
When I introduced .adma_write_desc, I made a mistake since v4 -- if the host
provide ops->adma_write_desc, we should just call it and
If hosts provides ops->adma_write_desc, we should not fall back to the
general sdhci_adma_write_desc().
Signed-off-by: Jisheng Zhang
---
Hi Ulf, Adrian,
When I introduced .adma_write_desc, I made a mistake since v4 -- if the host
provide ops->adma_write_desc, we should just call it and
+ DT maintainers
On Mon, 17 Sep 2018 11:29:49 +0800
Jisheng Zhang wrote:
> On some platforms, the sda/scl pins are muxed with gpio functions, so
> they could be used for recovery. Select the gpio/default pin function
> when prepare/unprepare recovery.
>
> Signed-off-by
+ DT maintainers
On Mon, 17 Sep 2018 11:29:49 +0800
Jisheng Zhang wrote:
> On some platforms, the sda/scl pins are muxed with gpio functions, so
> they could be used for recovery. Select the gpio/default pin function
> when prepare/unprepare recovery.
>
> Signed-off-by
+ DT maintainers
On Mon, 17 Sep 2018 11:28:30 +0800
Jisheng Zhang wrote:
> Document the pinctrl property for bus recovery.
>
> Signed-off-by: Jisheng Zhang
> ---
> Documentation/devicetree/bindings/i2c/i2c-designware.txt | 6 ++
> 1 file changed, 6 insertions(
+ DT maintainers
On Mon, 17 Sep 2018 11:28:30 +0800
Jisheng Zhang wrote:
> Document the pinctrl property for bus recovery.
>
> Signed-off-by: Jisheng Zhang
> ---
> Documentation/devicetree/bindings/i2c/i2c-designware.txt | 6 ++
> 1 file changed, 6 insertions(
+ DT maintainers
On Mon, 17 Sep 2018 11:27:41 +0800
Jisheng Zhang wrote:
> Document the scl-gpios and sda-gpios properties for bus recovery.
>
> Signed-off-by: Jisheng Zhang
> ---
> Documentation/devicetree/bindings/i2c/i2c-designware.txt | 6 ++
> 1 file cha
+ DT maintainers
On Mon, 17 Sep 2018 11:27:41 +0800
Jisheng Zhang wrote:
> Document the scl-gpios and sda-gpios properties for bus recovery.
>
> Signed-off-by: Jisheng Zhang
> ---
> Documentation/devicetree/bindings/i2c/i2c-designware.txt | 6 ++
> 1 file cha
+ DT maintainers
On Mon, 17 Sep 2018 11:26:33 +0800
Jisheng Zhang wrote:
> On some platforms, the sda/scl pins are muxed with gpio functions, so
> they could be used for recovery. Select the gpio/default pin function
> when prepare/unprepare recovery.
>
> patch1 adds the missing
+ DT maintainers
On Mon, 17 Sep 2018 11:26:33 +0800
Jisheng Zhang wrote:
> On some platforms, the sda/scl pins are muxed with gpio functions, so
> they could be used for recovery. Select the gpio/default pin function
> when prepare/unprepare recovery.
>
> patch1 adds the missing
On some platforms, the sda/scl pins are muxed with gpio functions, so
they could be used for recovery. Select the gpio/default pin function
when prepare/unprepare recovery.
Signed-off-by: Jisheng Zhang
---
drivers/i2c/busses/i2c-designware-core.h | 3 +++
drivers/i2c/busses/i2c-designware
On some platforms, the sda/scl pins are muxed with gpio functions, so
they could be used for recovery. Select the gpio/default pin function
when prepare/unprepare recovery.
Signed-off-by: Jisheng Zhang
---
drivers/i2c/busses/i2c-designware-core.h | 3 +++
drivers/i2c/busses/i2c-designware
Document the pinctrl property for bus recovery.
Signed-off-by: Jisheng Zhang
---
Documentation/devicetree/bindings/i2c/i2c-designware.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
b/Documentation/devicetree/bindings/i2c
Document the pinctrl property for bus recovery.
Signed-off-by: Jisheng Zhang
---
Documentation/devicetree/bindings/i2c/i2c-designware.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
b/Documentation/devicetree/bindings/i2c
Document the scl-gpios and sda-gpios properties for bus recovery.
Signed-off-by: Jisheng Zhang
---
Documentation/devicetree/bindings/i2c/i2c-designware.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
b/Documentation
Document the scl-gpios and sda-gpios properties for bus recovery.
Signed-off-by: Jisheng Zhang
---
Documentation/devicetree/bindings/i2c/i2c-designware.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
b/Documentation
.
patch3 selects gpio/default pin when prepare/unprepare recovery.
Since v2:
- add missing property dt-binding
Since v1:
- use IS_ERR_OR_NULL
Jisheng Zhang (3):
dt-bindings: i2c: designware: add optional gpio recovery properties
dt-bindings: i2c: designware: add optional pinctrl for bus
.
patch3 selects gpio/default pin when prepare/unprepare recovery.
Since v2:
- add missing property dt-binding
Since v1:
- use IS_ERR_OR_NULL
Jisheng Zhang (3):
dt-bindings: i2c: designware: add optional gpio recovery properties
dt-bindings: i2c: designware: add optional pinctrl for bus
Hi Lorenzo,
On Thu, 13 Sep 2018 10:15:34 +0100 Lorenzo Pieralisi wrote:
> On Mon, Sep 10, 2018 at 04:57:22PM +0800, Jisheng Zhang wrote:
> > Hi all,
> >
> > On Wed, 29 Aug 2018 11:04:08 +0800 Jisheng Zhang wrote:
> >
> > > When programming inbound/outbou
Hi Lorenzo,
On Thu, 13 Sep 2018 10:15:34 +0100 Lorenzo Pieralisi wrote:
> On Mon, Sep 10, 2018 at 04:57:22PM +0800, Jisheng Zhang wrote:
> > Hi all,
> >
> > On Wed, 29 Aug 2018 11:04:08 +0800 Jisheng Zhang wrote:
> >
> > > When programming inbound/outbou
On some platforms, the sda/scl pins are muxed with gpio functions, so
they could be used for recovery. Select the gpio/default pin function
when prepare/unprepare recovery.
Signed-off-by: Jisheng Zhang
---
since v1:
- use IS_ERR_OR_NULL
drivers/i2c/busses/i2c-designware-core.h | 3
On some platforms, the sda/scl pins are muxed with gpio functions, so
they could be used for recovery. Select the gpio/default pin function
when prepare/unprepare recovery.
Signed-off-by: Jisheng Zhang
---
since v1:
- use IS_ERR_OR_NULL
drivers/i2c/busses/i2c-designware-core.h | 3
On some platforms, the sda/scl pins are muxed with gpio functions, so
they could be used for recovery. Select the gpio/default pin function
when prepare/unprepare recovery.
Signed-off-by: Jisheng Zhang
---
drivers/i2c/busses/i2c-designware-core.h | 3 +++
drivers/i2c/busses/i2c-designware
On some platforms, the sda/scl pins are muxed with gpio functions, so
they could be used for recovery. Select the gpio/default pin function
when prepare/unprepare recovery.
Signed-off-by: Jisheng Zhang
---
drivers/i2c/busses/i2c-designware-core.h | 3 +++
drivers/i2c/busses/i2c-designware
On Thu, 13 Sep 2018 10:23:35 +0900 Masahiro Yamada wrote:
> Hello.
>
>
> Sorry if I am asking a stupid question.
>
>
> For arm64, there are only 2 cpu methods, psci and spin-table.
>
> Why do we still allow vendor-specific methods upstreamed
> for arm 32bit ports?
>
> To me, it looks like
On Thu, 13 Sep 2018 10:23:35 +0900 Masahiro Yamada wrote:
> Hello.
>
>
> Sorry if I am asking a stupid question.
>
>
> For arm64, there are only 2 cpu methods, psci and spin-table.
>
> Why do we still allow vendor-specific methods upstreamed
> for arm 32bit ports?
>
> To me, it looks like
Hi all,
On Wed, 29 Aug 2018 11:04:08 +0800 Jisheng Zhang wrote:
> When programming inbound/outbound atu, we call usleep_range() after
> each checking PCIE_ATU_ENABLE bit. Unfortunately, the atu programming
> can be called in atomic context:
>
> inbound atu programming could be
Hi all,
On Wed, 29 Aug 2018 11:04:08 +0800 Jisheng Zhang wrote:
> When programming inbound/outbound atu, we call usleep_range() after
> each checking PCIE_ATU_ENABLE bit. Unfortunately, the atu programming
> can be called in atomic context:
>
> inbound atu programming could be
"PCI: designware: Wait for iATU enable")
Signed-off-by: Jisheng Zhang
Acked-by: Gustavo Pimentel
---
since v2:
- Add Fixes tag
- Add Gustavo's Ack
since v1:
- use mdelay() instead of udelay() to avoid __bad_udelay()
drivers/pci/controller/dwc/pcie-designware.c | 8
"PCI: designware: Wait for iATU enable")
Signed-off-by: Jisheng Zhang
Acked-by: Gustavo Pimentel
---
since v2:
- Add Fixes tag
- Add Gustavo's Ack
since v1:
- use mdelay() instead of udelay() to avoid __bad_udelay()
drivers/pci/controller/dwc/pcie-designware.c | 8
On Tue, 28 Aug 2018 10:51:02 +0300 Adrian Hunter wrote:
> On 27/08/18 11:24, Jisheng Zhang wrote:
> > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > the DMA transfer into two so that each one doesn't exceed the boundary.
> >
> > S
On Tue, 28 Aug 2018 10:51:02 +0300 Adrian Hunter wrote:
> On 27/08/18 11:24, Jisheng Zhang wrote:
> > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > the DMA transfer into two so that each one doesn't exceed the boundary.
> >
> > S
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 39 +
1 file changed, 39 insertions(+)
diff --git
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 39 +
1 file changed, 39 insertions(+)
diff --git
Add this hook so that it can be overridden with driver specific
implementations. We also let the original sdhci_adma_write_desc()
accept so that the function can set its new value. Then export
the function so that it could be reused by driver's specific
implementations.
Signed-off-by: Jisheng
Add this hook so that it can be overridden with driver specific
implementations. We also let the original sdhci_adma_write_desc()
accept so that the function can set its new value. Then export
the function so that it could be reused by driver's specific
implementations.
Signed-off-by: Jisheng
This patch adds adma_table_cnt member to struct sdhci_host to give more
flexibility to drivers to control the ADMA table count.
Default value of adma_table_cnt is set to (SDHCI_MAX_SEGS * 2 + 1).
Signed-off-by: Jisheng Zhang
Acked-by: Adrian Hunter
---
drivers/mmc/host/sdhci.c | 17
This patch adds adma_table_cnt member to struct sdhci_host to give more
flexibility to drivers to control the ADMA table count.
Default value of adma_table_cnt is set to (SDHCI_MAX_SEGS * 2 + 1).
Signed-off-by: Jisheng Zhang
Acked-by: Adrian Hunter
---
drivers/mmc/host/sdhci.c | 17
extra desc num
- fix !len for dwcmshc_adma_write_desc()
Jisheng Zhang (3):
mmc: sdhci: add adma_table_cnt member to struct sdhci_host
mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops
mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
drivers/mmc/host/sdhci-of-dwcm
extra desc num
- fix !len for dwcmshc_adma_write_desc()
Jisheng Zhang (3):
mmc: sdhci: add adma_table_cnt member to struct sdhci_host
mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops
mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
drivers/mmc/host/sdhci-of-dwcm
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 41 +
1 file changed, 41 insertions(+)
diff --git
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 41 +
1 file changed, 41 insertions(+)
diff --git
Add this hook so that it can be overridden with driver specific
implementations. We also let the original sdhci_adma_write_desc()
accept so that the function can set its new value. Then export
the function so that it could be reused by driver's specific
implementations.
Signed-off-by: Jisheng
Add this hook so that it can be overridden with driver specific
implementations. We also let the original sdhci_adma_write_desc()
accept so that the function can set its new value. Then export
the function so that it could be reused by driver's specific
implementations.
Signed-off-by: Jisheng
This patch adds adma_table_cnt member to struct sdhci_host to give more
flexibility to drivers to control the ADMA table count.
Default value of adma_table_cnt is set to (SDHCI_MAX_SEGS * 2 + 1).
Signed-off-by: Jisheng Zhang
Acked-by: Adrian Hunter
---
drivers/mmc/host/sdhci.c | 17
This patch adds adma_table_cnt member to struct sdhci_host to give more
flexibility to drivers to control the ADMA table count.
Default value of adma_table_cnt is set to (SDHCI_MAX_SEGS * 2 + 1).
Signed-off-by: Jisheng Zhang
Acked-by: Adrian Hunter
---
drivers/mmc/host/sdhci.c | 17
since v2:
- make use of "likely" to check (!len || BOUNDARY_OK(addr, len))
- explictly include for SZ_128M
since v1:
- fix BOUNDARY_OK macro if addr+len is aligned to 128MB
- use DIV_ROUND_UP to cal extra desc num
- fix !len for dwcmshc_adma_write_desc()
Jisheng Zhang (3):
since v2:
- make use of "likely" to check (!len || BOUNDARY_OK(addr, len))
- explictly include for SZ_128M
since v1:
- fix BOUNDARY_OK macro if addr+len is aligned to 128MB
- use DIV_ROUND_UP to cal extra desc num
- fix !len for dwcmshc_adma_write_desc()
Jisheng Zhang (3):
On Thu, 23 Aug 2018 14:51:26 +0300 Adrian Hunter wrote:
> On 23/08/18 13:09, Jisheng Zhang wrote:
> > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > the DMA transfer into two so that each one doesn't exceed the boundary.
> >
> > S
On Thu, 23 Aug 2018 14:51:26 +0300 Adrian Hunter wrote:
> On 23/08/18 13:09, Jisheng Zhang wrote:
> > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > the DMA transfer into two so that each one doesn't exceed the boundary.
> >
> > S
This patch adds adma_table_cnt member to struct sdhci_host to give more
flexibility to drivers to control the ADMA table count.
Default value of adma_table_cnt is set to (SDHCI_MAX_SEGS * 2 + 1).
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci.c | 17 +
drivers/mmc/host
This patch adds adma_table_cnt member to struct sdhci_host to give more
flexibility to drivers to control the ADMA table count.
Default value of adma_table_cnt is set to (SDHCI_MAX_SEGS * 2 + 1).
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci.c | 17 +
drivers/mmc/host
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 39 +
1 file changed, 39 insertions(+)
diff --git
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 39 +
1 file changed, 39 insertions(+)
diff --git
Add this hook so that it can be overridden with driver specific
implementations. We also let the original sdhci_adma_write_desc()
accept so that the function can set its new value. Then export
the function so that it could be reused by driver's specific
implementations.
Signed-off-by: Jisheng
Add this hook so that it can be overridden with driver specific
implementations. We also let the original sdhci_adma_write_desc()
accept so that the function can set its new value. Then export
the function so that it could be reused by driver's specific
implementations.
Signed-off-by: Jisheng
since v2:
- make use of "likely" to check (!len || BOUNDARY_OK(addr, len))
- explictly include for SZ_128M
since v1:
- fix BOUNDARY_OK macro if addr+len is aligned to 128MB
- use DIV_ROUND_UP to cal extra desc num
- fix !len for dwcmshc_adma_write_desc()
Jisheng Zhang (3):
since v2:
- make use of "likely" to check (!len || BOUNDARY_OK(addr, len))
- explictly include for SZ_128M
since v1:
- fix BOUNDARY_OK macro if addr+len is aligned to 128MB
- use DIV_ROUND_UP to cal extra desc num
- fix !len for dwcmshc_adma_write_desc()
Jisheng Zhang (3):
der()
=>dw_pcie_prog_inbound_atu()
outbound atu programming could be called through
pci_bus_read_config_dword()
=>dw_pcie_rd_conf()
=>dw_pcie_prog_outbound_atu()
Fix this issue by calling mdelay() instead.
Signed-off-by: Jisheng Zhang
---
Since v1
- use mdelay() instead of udelay() to avoid
der()
=>dw_pcie_prog_inbound_atu()
outbound atu programming could be called through
pci_bus_read_config_dword()
=>dw_pcie_rd_conf()
=>dw_pcie_prog_outbound_atu()
Fix this issue by calling mdelay() instead.
Signed-off-by: Jisheng Zhang
---
Since v1
- use mdelay() instead of udelay() to avoid
der()
=>dw_pcie_prog_inbound_atu()
outbound atu programming could be called through
pci_bus_read_config_dword()
=>dw_pcie_rd_conf()
=>dw_pcie_prog_outbound_atu()
Fix this issue by calling udelay() instead.
Signed-off-by: Jisheng Zhang
---
drivers/pci/controller/dwc/pcie-designware.c | 8
der()
=>dw_pcie_prog_inbound_atu()
outbound atu programming could be called through
pci_bus_read_config_dword()
=>dw_pcie_rd_conf()
=>dw_pcie_prog_outbound_atu()
Fix this issue by calling udelay() instead.
Signed-off-by: Jisheng Zhang
---
drivers/pci/controller/dwc/pcie-designware.c | 8
Hi Adrian, Ulf,
could you please review these patches? Any comments are welcome.
Thanks in advance,
Jisheng
On Mon, 30 Jul 2018 10:42:28 +0800 Jisheng Zhang wrote:
> When using DMA, if the DMA addr spans 128MB boundary, we have to split
> the DMA transfer into two so that each one d
Hi Adrian, Ulf,
could you please review these patches? Any comments are welcome.
Thanks in advance,
Jisheng
On Mon, 30 Jul 2018 10:42:28 +0800 Jisheng Zhang wrote:
> When using DMA, if the DMA addr spans 128MB boundary, we have to split
> the DMA transfer into two so that each one d
("pinctrl: berlin: add the core pinctrl driver for
> Marvell Berlin SoCs")
> Signed-off-by: YueHaibing
Reviewed-by: Jisheng Zhang
> ---
> v2: free pctrl->functions instead of function as Jisheng Zhang suggested
> v3: v2 I send a wrong patch,this is the correct patch
("pinctrl: berlin: add the core pinctrl driver for
> Marvell Berlin SoCs")
> Signed-off-by: YueHaibing
Reviewed-by: Jisheng Zhang
> ---
> v2: free pctrl->functions instead of function as Jisheng Zhang suggested
> v3: v2 I send a wrong patch,this is the correct patch
Hi,
On Tue, 31 Jul 2018 22:25:01 +0800 YueHaibing wrote:
> fixes following Smatch static check warning:
>
> drivers/pinctrl/berlin/berlin.c:237 berlin_pinctrl_build_state()
> warn: passing devm_ allocated variable to kfree. 'pctrl->functions'
>
> As we will be calling krealloc() on pointer
Hi,
On Tue, 31 Jul 2018 22:25:01 +0800 YueHaibing wrote:
> fixes following Smatch static check warning:
>
> drivers/pinctrl/berlin/berlin.c:237 berlin_pinctrl_build_state()
> warn: passing devm_ allocated variable to kfree. 'pctrl->functions'
>
> As we will be calling krealloc() on pointer
On Tue, 31 Jul 2018 11:29:24 +0800
Jisheng Zhang wrote:
> Hi Robin,
>
> On Mon, 30 Jul 2018 12:06:08 +0100 Robin Murphy wrote:
>
> > Hi Jisheng,
> >
> > On 26/07/18 08:14, Jisheng Zhang wrote:
> > > When using DMA, if the DMA addr spans 128MB b
On Tue, 31 Jul 2018 11:29:24 +0800
Jisheng Zhang wrote:
> Hi Robin,
>
> On Mon, 30 Jul 2018 12:06:08 +0100 Robin Murphy wrote:
>
> > Hi Jisheng,
> >
> > On 26/07/18 08:14, Jisheng Zhang wrote:
> > > When using DMA, if the DMA addr spans 128MB b
Hi Robin,
On Mon, 30 Jul 2018 12:06:08 +0100 Robin Murphy wrote:
> Hi Jisheng,
>
> On 26/07/18 08:14, Jisheng Zhang wrote:
> > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > the DMA transfer into two so that each one doesn't exceed the
Hi Robin,
On Mon, 30 Jul 2018 12:06:08 +0100 Robin Murphy wrote:
> Hi Jisheng,
>
> On 26/07/18 08:14, Jisheng Zhang wrote:
> > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > the DMA transfer into two so that each one doesn't exceed the
On Mon, 30 Jul 2018 03:11:59 +
Matthew Leon wrote:
> >> Hey Jisheng,
>
> >Hi,
>
> >>
>
> >In LKML, we'd better not top post.
>
> Noted. My apologies.
>
> >> Shouldn't we be splitting until all DMA blocks are less than 128M
> boundary?
> >> I am a noob, but I think we should
On Mon, 30 Jul 2018 03:11:59 +
Matthew Leon wrote:
> >> Hey Jisheng,
>
> >Hi,
>
> >>
>
> >In LKML, we'd better not top post.
>
> Noted. My apologies.
>
> >> Shouldn't we be splitting until all DMA blocks are less than 128M
> boundary?
> >> I am a noob, but I think we should
KB.
thanks
>
> Sincerely,
> Matthew Leon
>
> On Sun, Jul 29, 2018 at 10:46 PM, Jisheng Zhang > wrote:
>
> > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > the DMA transfer into two so that each one doesn't exceed the boundary.
&g
KB.
thanks
>
> Sincerely,
> Matthew Leon
>
> On Sun, Jul 29, 2018 at 10:46 PM, Jisheng Zhang > wrote:
>
> > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > the DMA transfer into two so that each one doesn't exceed the boundary.
&g
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 43 +
1 file changed, 43 insertions(+)
diff --git
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 43 +
1 file changed, 43 insertions(+)
diff --git
Add this hook so that it can be overridden with driver specific
implementations. We also rename the original sdhci_adma_write_desc()
to _sdhci_adma_write_desc() and export it, so that it could be reused
by driver's specific implementations.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host
Add this hook so that it can be overridden with driver specific
implementations. We also rename the original sdhci_adma_write_desc()
to _sdhci_adma_write_desc() and export it, so that it could be reused
by driver's specific implementations.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host
This patch adds adma_table_num member to struct sdhci_host to give more
flexibility to drivers to control the ADMA table number.
Default value of adma_table_num is set to (SDHCI_MAX_SEGS * 2 + 1).
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci.c | 17 +
drivers/mmc
This patch adds adma_table_num member to struct sdhci_host to give more
flexibility to drivers to control the ADMA table number.
Default value of adma_table_num is set to (SDHCI_MAX_SEGS * 2 + 1).
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci.c | 17 +
drivers/mmc
_UP to cal extra desc num
- fix !len for dwcmshc_adma_write_desc()
Jisheng Zhang (3):
mmc: sdhci: add adma_table_num member to struct sdhci_host
mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops
mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
drivers/mmc/
_UP to cal extra desc num
- fix !len for dwcmshc_adma_write_desc()
Jisheng Zhang (3):
mmc: sdhci: add adma_table_num member to struct sdhci_host
mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops
mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
drivers/mmc/
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 42 +
1 file changed, 42 insertions(+)
diff --git
When using DMA, if the DMA addr spans 128MB boundary, we have to split
the DMA transfer into two so that each one doesn't exceed the boundary.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci-of-dwcmshc.c | 42 +
1 file changed, 42 insertions(+)
diff --git
Add this hook so that it can be overridden with driver specific
implementations. We also rename the original sdhci_adma_write_desc()
to _sdhci_adma_write_desc() and export it, so that it could be reused
by driver's specific implementations.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host
Add this hook so that it can be overridden with driver specific
implementations. We also rename the original sdhci_adma_write_desc()
to _sdhci_adma_write_desc() and export it, so that it could be reused
by driver's specific implementations.
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host
This patch adds adma_table_num member to struct sdhci_host to give more
flexibility to drivers to control the ADMA table number.
Default value of adma_table_num is set to (SDHCI_MAX_SEGS * 2 + 1).
Signed-off-by: Jisheng Zhang
---
drivers/mmc/host/sdhci.c | 17 +
drivers/mmc
401 - 500 of 2741 matches
Mail list logo
