[PATCH] arm64: enable CMT/TMU support for Renesas SoC
Renesas R-Car gen3 SoCs have both CMT and TMU timers, so we have to enable building them in Kconfig.platforms (as they don't normally have the prompts in Kconfig). Signed-off-by: Sergei Shtylyov --- The patch is against the ARM64 repo's 'for-next/core' branch. arch/arm64/Kconfig.platforms |2 ++ 1 file changed, 2 insertions(+) Index: linux/arch/arm64/Kconfig.platforms === --- linux.orig/arch/arm64/Kconfig.platforms +++ linux/arch/arm64/Kconfig.platforms @@ -175,6 +175,8 @@ config ARCH_RENESAS select PM_GENERIC_DOMAINS select RENESAS_IRQC select SOC_BUS + select SYS_SUPPORTS_SH_CMT + select SYS_SUPPORTS_SH_TMU help This enables support for the ARMv8 based Renesas SoCs.
Salvator-XS-M3N SRU/HGT/COPY test fail
Hi Laurent, I've had some interesting failures on the VSP1 tests on the M3-N board. - vsp-unit-test-0015.sh Testing SRU scaling from 1024x768 to 1024x768 in RGB24: fail Testing SRU scaling from 1024x768 to 2048x1536 in RGB24: fail Testing SRU scaling from 1024x768 to 1024x768 in YUV444M: fail Testing SRU scaling from 1024x768 to 2048x1536 in YUV444M: fail - vsp-unit-test-0023.sh Testing histogram HGT with hue areas 0,255,255,255,255,255,255,255,255,255,255,255: fail Testing histogram HGT with hue areas 0,40,40,80,80,120,120,160,160,200,200,255: fail Testing histogram HGT with hue areas 220,40,40,80,80,120,120,160,160,200,200,220: fail Testing histogram HGT with hue areas 0,10,50,60,100,110,150,160,200,210,250,255: fail Testing histogram HGT with hue areas 10,20,50,60,100,110,150,160,200,210,230,240: fail Testing histogram HGT with hue areas 240,20,60,80,100,120,140,160,180,200,210,220: fail - vsp-unit-test-0025.sh Testing copying 1024x768 in RGB24: fail Testing copying 128x128 in RGB24: fail Testing copying 128x1 in RGB24: diff: /tmp/frame-*.bin: No such file or directory mv: cannot stat '/tmp/frame-*.bin': No such file or directory fail Testing copying 1024x768 in ARGB32: fail Testing copying 128x128 in ARGB32: fail Testing copying 128x1 in ARGB32: diff: /tmp/frame-*.bin: No such file or directory mv: cannot stat '/tmp/frame-*.bin': No such file or directory fail The frames on test 15 are 'flipped' vertically, while on test 25, they are rotated. Please see the reference image and resulting output at: https://ibb.co/fjPpkK https://ibb.co/mfybXz I'm sure I haven't seen this issue on the H3, so this could be an M3-N specific issue. Oddly, a later test (25, which I've posted earlier today) fails, because the images are rotated 90* to the left ... So it seems like there is certainly some uninitialised or confused state on the ROT bits somehow. For reference, this is on my branch du/2018q3 on my rcar.git repo. Commit 889e6d80c9f0eef433cfa1828c9a9d32a78479c2 which is based upon your drm/du/next branch. -- Regards -- Kieran
Re: [git pull] clk: renesas: Updates for v4.20
Quoting Geert Uytterhoeven (2018-08-31 06:09:58) > Hi Mike, Stephen, > > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git > tags/clk-renesas-for-v4.20-tag1 > > for you to fetch changes up to b30c862f2a72002c06df23d05c2ca6b49148c4d4: > > clk: renesas: r8a77990: Add missing I2C7 clock (2018-08-31 10:33:59 +0200) > Pulled. Thanks.
Re: [PATCH 2/2] ARM: multi_v7_defconfig: Enable VIDEO_RENESAS_FDP1
On Fri, Aug 31, 2018 at 11:16:18AM +0200, Geert Uytterhoeven wrote: > R-Car Gen2 (and RZ/G1) SoCs have a Fine Display Processor, hence enable > support for it. > > Signed-off-by: Geert Uytterhoeven Thanks Geert, applied for v4.20.
Re: [PATCH 1/2] ARM: shmobile: defconfig: Enable VIDEO_RENESAS_FDP1
On Fri, Aug 31, 2018 at 11:16:17AM +0200, Geert Uytterhoeven wrote: > R-Car Gen2 (and RZ/G1) SoCs have a Fine Display Processor, hence enable > support for it. > > Signed-off-by: Geert Uytterhoeven Thanks Geert, applied for v4.20.
Re: [PATCH] arm64: dts: renesas: r8a774a1: Add CAN nodes
On Fri, Aug 31, 2018 at 10:44:10AM +0200, Geert Uytterhoeven wrote:
> Hi Fabrizio,
>
> On Thu, Aug 23, 2018 at 4:22 PM Fabrizio Castro
> wrote:
> > From: Chris Paterson
> >
> > Add the device nodes for both RZ/G2M CAN channels.
> >
> > Signed-off-by: Chris Paterson
> > Reviewed-by: Biju Das
> > ---
> >
> > This patch depends on:
> > https://lkml.org/lkml/2018/8/23/1049
> > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg30550.html
> >
> >
> > arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > index 5d0109a..cd204f5 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> > @@ -816,6 +816,30 @@
> > status = "disabled";
> > };
> >
> > + can0: can@e6c3 {
> > + compatible = "renesas,can-r8a774a1",
> > +"renesas,rzg-gen2-can";
>
> Please don't introduce "renesas,rzg-gen2-can", cfr. my comments in
> https://lore.kernel.org/lkml/camuhmdwpuqfxogh_-qp8q6watu3lj_wpx0baoxpbx76skvy...@mail.gmail.com/
Thanks Geert,
I was ok with the compat string but it was unwise to pick up this patch
before that discussion had concluded. I have dropped this patch accordingly.
Fabrizio, please post a v2 once the binding is agreed on.
[VSP-Tests: PATCH v2] tests: Provide copy test to validate 1xN streams
Validate that a 1xN stream can be read through the RPF and written
through the WPF.
The test framework does not currently support processing images where
the stride does not match the output width - so the testing is currently
limited to testing only the vertical direction in this aspect.
Signed-off-by: Kieran Bingham
---
tests/vsp-unit-test-0025.sh | 45 +
1 file changed, 45 insertions(+)
create mode 100755 tests/vsp-unit-test-0025.sh
diff --git a/tests/vsp-unit-test-0025.sh b/tests/vsp-unit-test-0025.sh
new file mode 100755
index ..57a1fac6e369
--- /dev/null
+++ b/tests/vsp-unit-test-0025.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+#
+# Test pipelines which have a single pixel dimension. Use a RPF -> WPF
+# pipeline with identical input and output formats to generate our output.
+#
+
+. ./vsp-lib.sh
+
+features="rpf.0 uds wpf.0"
+formats="RGB24 ARGB32"
+
+# Input is directly copied to the output. No change in format or size.
+test_copy() {
+ local format=$1
+ local insize=$2
+
+ test_start "copying $insize in $format"
+
+ pipe_configure rpf-wpf 0 0
+ format_configure rpf-wpf 0 0 $format $insize $format
+
+ vsp_runner rpf.0 &
+ vsp_runner wpf.0
+
+ local result=$(compare_frames)
+
+ test_complete $result
+}
+
+test_main() {
+ local format
+
+ for format in $formats ; do
+ test_copy $format 1024x768
+ test_copy $format 128x128
+ test_copy $format 128x1
+
+ # Skipped : Test framework does not yet support strides != width
+ #test_copy $format 1x128
+ done
+}
+
+test_init $0 "$features"
+test_run
--
2.17.1
Re: [git pull] pinctrl: sh-pfc: Updates for v4.20
On Fri, Aug 31, 2018 at 3:07 PM Geert Uytterhoeven wrote: > The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: > > Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git > tags/sh-pfc-for-v4.20-tag1 > > for you to fetch changes up to 2ed03c835d6f4dbe9f0d093187825d1c0e2e9b39: > > pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function (2018-08-30 > 14:17:20 +0200) Pulled into pinctrl "devel" branch, thanks! Yours, Linus Walleij
Re: [PATCH] clk: renesas: r8a77990: Add missing I2C7 clock
On Thu, Aug 30, 2018 at 05:28:13PM +0200, Geert Uytterhoeven wrote: > When trying to use I2C7 on R-Car E3: > > renesas-cpg-mssr e615.clock-controller: Cannot get module clock 1003: > -2 > i2c-rcar e669.i2c: failed to add to PM domain always-on: -2 > i2c-rcar: probe of e669.i2c failed with error -2 > > Unlike other R-Car Gen3 SoCs, R-Car E3 has more than 7 I2C bus > interfaces. Add the forgotten module clock for the 8th instance to fix > this. > > Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman
[VSP-Tests: PATCH] vsp-lib: Provide command line argument parsing
Extend the vsp-lib to support command line parsing for all tests. The
arguments parsed here should be common to all tests, and initially
provide shell level verbose debug output, and the option to easily keep
frames output by the VSP1.
Signed-off-by: Kieran Bingham
---
scripts/vsp-lib.sh | 34 ++
1 file changed, 34 insertions(+)
diff --git a/scripts/vsp-lib.sh b/scripts/vsp-lib.sh
index 0f3992a7827e..6a0f4af5eaf5 100755
--- a/scripts/vsp-lib.sh
+++ b/scripts/vsp-lib.sh
@@ -1094,3 +1094,37 @@ test_complete() {
test_run() {
test_main | ./logger.sh error >> $logfile
}
+
+#
--
+# Common argument parsing
+#
+# non-recognised arguements are restored, to allow tests
+# to implement their own parsing if necessary.
+
+POSITIONAL=()
+while [[ $# -gt 0 ]]
+do
+case $1 in
+ -x|--debug)
+ set -x;
+ shift
+ ;;
+ -k|--keep-frames)
+ export VSP_KEEP_FRAMES=1
+ shift
+ ;;
+ -h|--help)
+ echo "$(basename $0): VSP Test library"
+ echo " -x|--debug enable shell debug"
+ echo " -k|--keep-frameskeep generated and captured frames"
+ echo " -h|--help this help"
+ exit
+ shift
+ ;;
+ *)# unknown option
+ POSITIONAL+=("$1") # save it in an array for later
+ shift # past argument
+ ;;
+esac
+done
+set -- "${POSITIONAL[@]}" # restore positional parameters
--
2.17.1
[VSP-Tests: PATCH] tests: Provide copy test to validate 1xN streams
Validate that a 1xN stream can be read through the RPF and written
through the WPF.
The test framework does not currently support processing images where
the stride does not match the output width - so the testing is currently
limited to testing only the vertical direction in this aspect.
Signed-off-by: Kieran Bingham
---
tests/vsp-unit-test-0025.sh | 45 +
1 file changed, 45 insertions(+)
create mode 100755 tests/vsp-unit-test-0025.sh
diff --git a/tests/vsp-unit-test-0025.sh b/tests/vsp-unit-test-0025.sh
new file mode 100755
index ..5c8980c40d89
--- /dev/null
+++ b/tests/vsp-unit-test-0025.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+#
+# Test pipelines which have a single pixel dimension. Use a RPF -> UDS -> WPF
+# pipeline with identical input and output formats to generate our output.
+#
+
+. ./vsp-lib.sh
+
+features="rpf.0 uds wpf.0"
+formats="RGB24 ARGB32"
+
+# Input is directly copied to the output. No change in format or size.
+test_copy() {
+ local format=$1
+ local insize=$2
+
+ test_start "copying $insize in $format"
+
+ pipe_configure rpf-wpf 0 0
+ format_configure rpf-wpf 0 0 $format $insize $format
+
+ vsp_runner rpf.0 &
+ vsp_runner wpf.0
+
+ local result=$(compare_frames)
+
+ test_complete $result
+}
+
+test_main() {
+ local format
+
+ for format in $formats ; do
+ test_copy $format 1024x768
+ test_copy $format 128x128
+ test_copy $format 128x1
+
+ # Skipped : Test framework does not yet support strides != width
+ #test_copy $format 1x128
+ done
+}
+
+test_init $0 "$features"
+test_run
--
2.17.1
Re: [PATCH] arm64: dts: renesas: r8a77990: Add BRG support to SCIF2
On Thu, Aug 30, 2018 at 04:56:35PM +0200, Geert Uytterhoeven wrote: > From: Takeshi Kihara > > Add the device node for the external SCIF_CLK, and describe the clock > inputs for the Baud Rate Generator for External Clock (BRG) for SCIF2, > which can increase serial clock accuracy. > > The presence of the SCIF_CLK crystal and its clock frequency depend on > the actual board. > > Signed-off-by: Takeshi Kihara > [geert: Enhance patch description] > Signed-off-by: Geert Uytterhoeven > --- > Note: The Ebisu board does not provide SCIF_CLK. However, using the BRG > increases the serial console's clock accurary from 115200+541 bps > to 115200-257 bps. Thanks Geert, applied for v4.20.
Re: [PATCH] arm64: dts: renesas: r8a77990: Use CPG/MSSR and SYSC binding definitions
On Thu, Aug 30, 2018 at 04:52:20PM +0200, Geert Uytterhoeven wrote: > Use the SoC-specific CPG/MSSR include file to allow future use of > R8A77990_CLK_* symbols. > Replace the hardcoded power domain indices by R8A77990_PD_* symbols. > > Signed-off-by: Geert Uytterhoeven Thanks Geert, applied for v4.20.
[git pull] clk: renesas: Updates for v4.20
Hi Mike, Stephen,
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
tags/clk-renesas-for-v4.20-tag1
for you to fetch changes up to b30c862f2a72002c06df23d05c2ca6b49148c4d4:
clk: renesas: r8a77990: Add missing I2C7 clock (2018-08-31 10:33:59 +0200)
clk: renesas: Updates for v4.20
- Improve OSC and RCLK (watchdog) handling on R-Car Gen3 SoCs,
- Add support for SATA and Fine Display Processor (FDP) clocks on
R-Car M3-N,
- Add support for the new RZ/G2M (r8a774a1) SoC,
- Small fixes and clean ups.
Thanks for pulling!
Biju Das (2):
clk: renesas: Add r8a774a1 CPG Core Clock Definitions
clk: renesas: cpg-mssr: Add r8a774a1 support
Geert Uytterhoeven (13):
clk: renesas: rcar-gen3: Rename rint to .r
clk: renesas: rcar-gen3: Add support for OSC EXTAL predivider
clk: renesas: r8a7795: Add OSC EXTAL predivider configuration
clk: renesas: r8a7796: Add OSC EXTAL predivider configuration
clk: renesas: r8a77965: Add OSC EXTAL predivider configuration
clk: renesas: r8a77980: Add OSC predivider configuration and clock
clk: renesas: cpg-mssr: Add support for fixed rate clocks
clk: renesas: rcar-gen3: Add support for RCKSEL clock selection
clk: renesas: r8a77990: Correct RCLK handling
clk: renesas: r8a77995: Correct RCLK handling
clk: renesas: rcar-gen3: Add support for mode pin clock selection
clk: renesas: r8a77980: Add RCLK for watchdog timer
clk: renesas: r8a77990: Add missing I2C7 clock
Hoan Nguyen An (1):
clk: renesas: r8a77965: Add FDP clock
Takeshi Kihara (1):
clk: renesas: r8a77965: Add SATA clock
.../devicetree/bindings/clock/renesas,cpg-mssr.txt | 9 +-
drivers/clk/renesas/Kconfig| 5 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r8a774a1-cpg-mssr.c| 323 +
drivers/clk/renesas/r8a7795-cpg-mssr.c | 67 ++---
drivers/clk/renesas/r8a7796-cpg-mssr.c | 67 ++---
drivers/clk/renesas/r8a77965-cpg-mssr.c| 69 ++---
drivers/clk/renesas/r8a77980-cpg-mssr.c| 28 +-
drivers/clk/renesas/r8a77990-cpg-mssr.c| 13 +-
drivers/clk/renesas/r8a77995-cpg-mssr.c| 12 +-
drivers/clk/renesas/rcar-gen3-cpg.c| 40 ++-
drivers/clk/renesas/rcar-gen3-cpg.h| 24 +-
drivers/clk/renesas/renesas-cpg-mssr.c | 11 +
drivers/clk/renesas/renesas-cpg-mssr.h | 4 +
include/dt-bindings/clock/r8a774a1-cpg-mssr.h | 58
15 files changed, 599 insertions(+), 132 deletions(-)
create mode 100644 drivers/clk/renesas/r8a774a1-cpg-mssr.c
create mode 100644 include/dt-bindings/clock/r8a774a1-cpg-mssr.h
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[git pull] pinctrl: sh-pfc: Updates for v4.20
Hi Linus,
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
tags/sh-pfc-for-v4.20-tag1
for you to fetch changes up to 2ed03c835d6f4dbe9f0d093187825d1c0e2e9b39:
pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function (2018-08-30
14:17:20 +0200)
pinctrl: sh-pfc: Updates for v4.20
- Add SATA and audio pin groups on R-Car M3-N,
- Add EtherAVB pin groups on RZ/G1C,
- Add PWM and display (DU) pin groups on R-Car E3,
- Add support for the new RZ/G2M (r8a774a1) SoC.
Thanks for pulling!
Biju Das (3):
pinctrl: sh-pfc: r8a77470: Add EtherAVB pin groups
dt-bindings: pinctrl: sh-pfc: Document r8a774a1 PFC support
pinctrl: sh-pfc: r8a7796: Add R8A774A1 PFC support
Hoan Nguyen An (2):
pinctrl: sh-pfc: r8a77965: Add Audio clock pin support
pinctrl: sh-pfc: r8a77965: Add Audio SSI pin support
Laurent Pinchart (1):
pinctrl: sh-pfc: r8a77990: Add DU pins, groups and function
Takeshi Kihara (2):
pinctrl: sh-pfc: r8a77965: Add SATA pins, groups and functions
pinctrl: sh-pfc: r8a77990: Add PWM pins, groups and functions
.../bindings/pinctrl/renesas,pfc-pinctrl.txt | 1 +
drivers/pinctrl/sh-pfc/Kconfig | 5 +
drivers/pinctrl/sh-pfc/Makefile| 1 +
drivers/pinctrl/sh-pfc/core.c | 6 +
drivers/pinctrl/sh-pfc/pfc-r8a77470.c | 133
drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 837 +++--
drivers/pinctrl/sh-pfc/pfc-r8a77965.c | 419 +++
drivers/pinctrl/sh-pfc/pfc-r8a77990.c | 321
drivers/pinctrl/sh-pfc/sh_pfc.h| 1 +
9 files changed, 1327 insertions(+), 397 deletions(-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size
On Fri, Aug 31, 2018 at 12:49:08PM +0200, Niklas Söderlund wrote: > On 2018-08-31 12:35:24 +0200, Wolfram Sang wrote: > > > > > Promote > > > drivers/gpu/drm/exynos/exynos_drm_iommu.c:configure_dma_max_seg_size() > > > to a generic helper? > > > > Yes! > > > If that is promoted should not > drivers/gpu/drm/exynos/exynos_drm_iommu.c:clear_dma_max_seg_size() also > be promoted? And if so should this patch revert back to v1 with a custom > remove function which clears and free the dma_parms ? My preference would be easy to use helpers for drivers because this is easy to get wrong. I think we need to discuss with the creators of that API: a) if the drm/exynos driver does the right thing(tm) b) if these functions should be generic helpers c) when to clear the pointer (a bit related to a)) Niklas, do you have an interest to do that? Or would you rather go with SDHI hacking? :) I can do it, too. signature.asc Description: PGP signature
Re: [PATCH v2] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size
On 2018-08-31 12:35:24 +0200, Wolfram Sang wrote: > > > Promote > > drivers/gpu/drm/exynos/exynos_drm_iommu.c:configure_dma_max_seg_size() > > to a generic helper? > > Yes! > If that is promoted should not drivers/gpu/drm/exynos/exynos_drm_iommu.c:clear_dma_max_seg_size() also be promoted? And if so should this patch revert back to v1 with a custom remove function which clears and free the dma_parms ? -- Regards, Niklas Söderlund
[PATCH v2 3/3] usb: renesas_usbhs: Add multiple clocks management
R-Car Gen3 needs to enable clocks of both host and peripheral.
Since [eo]hci-platform disables the reset(s) when the drivers are
removed, renesas_usbhs driver doesn't work correctly. To fix this
issue, this patch adds multiple clocks management on this
renesas_usbhs driver.
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/renesas_usbhs/common.c | 35 +++
drivers/usb/renesas_usbhs/common.h | 3 +++
2 files changed, 38 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index 1d355d5..39ed714 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -5,6 +5,7 @@
* Copyright (C) 2011 Renesas Solutions Corp.
* Kuninori Morimoto
*/
+#include
#include
#include
#include
@@ -336,11 +337,26 @@ static void usbhsc_power_ctrl(struct usbhs_priv *priv,
int enable)
{
struct platform_device *pdev = usbhs_priv_to_pdev(priv);
struct device *dev = usbhs_priv_to_dev(priv);
+ int ret;
if (enable) {
/* enable PM */
pm_runtime_get_sync(dev);
+ /* enable clks if exist */
+ if (priv->num_clks) {
+ ret = clk_bulk_prepare(priv->num_clks, priv->clks);
+ if (!ret) {
+ ret = clk_bulk_enable(priv->num_clks,
+ priv->clks);
+ if (ret) {
+ clk_bulk_unprepare(priv->num_clks,
+ priv->clks);
+ return;
+ }
+ }
+ }
+
/* enable platform power */
usbhs_platform_call(priv, power_ctrl, pdev, priv->base, enable);
@@ -353,6 +369,10 @@ static void usbhsc_power_ctrl(struct usbhs_priv *priv, int
enable)
/* disable platform power */
usbhs_platform_call(priv, power_ctrl, pdev, priv->base, enable);
+ /* disable clks if exist */
+ if (priv->num_clks)
+ clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
+
/* disable PM */
pm_runtime_put_sync(dev);
}
@@ -620,6 +640,13 @@ static int usbhs_probe(struct platform_device *pdev)
break;
}
+ if (priv->dparam.type == USBHS_TYPE_RCAR_GEN3 ||
+ priv->dparam.type == USBHS_TYPE_RCAR_GEN3_WITH_PLL) {
+ priv->clks[0].id = "hsusb";
+ priv->clks[1].id = "ehci/ohci";
+ priv->num_clks = ARRAY_SIZE(priv->clks);
+ };
+
/* set driver callback functions for platform */
dfunc = >driver_callback;
dfunc->notify_hotplug = usbhsc_drvcllbck_notify_hotplug;
@@ -667,6 +694,12 @@ static int usbhs_probe(struct platform_device *pdev)
if (ret)
goto probe_fail_rst;
+ if (priv->num_clks) {
+ ret = clk_bulk_get(>dev, priv->num_clks, priv->clks);
+ if (ret == -EPROBE_DEFER)
+ goto probe_fail_clks;
+ }
+
/*
* deviece reset here because
* USB device might be used in boot loader.
@@ -720,6 +753,8 @@ static int usbhs_probe(struct platform_device *pdev)
return ret;
probe_end_mod_exit:
+ clk_bulk_put(priv->num_clks, priv->clks);
+probe_fail_clks:
reset_control_assert(priv->rsts);
probe_fail_rst:
usbhs_mod_remove(priv);
diff --git a/drivers/usb/renesas_usbhs/common.h
b/drivers/usb/renesas_usbhs/common.h
index bce7d35..6e7c5f2 100644
--- a/drivers/usb/renesas_usbhs/common.h
+++ b/drivers/usb/renesas_usbhs/common.h
@@ -8,6 +8,7 @@
#ifndef RENESAS_USB_DRIVER_H
#define RENESAS_USB_DRIVER_H
+#include
#include
#include
#include
@@ -279,6 +280,8 @@ struct usbhs_priv {
struct phy *phy;
struct reset_control *rsts;
+ struct clk_bulk_data clks[2];
+ int num_clks;
};
/*
--
1.9.1
Re: [PATCH v2] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size
> Promote drivers/gpu/drm/exynos/exynos_drm_iommu.c:configure_dma_max_seg_size() > to a generic helper? Yes! signature.asc Description: PGP signature
[PATCH v2 0/3] usb: renesas_usbhs: add reset_control and multiple clocks management
This patch set is based on Felipe's usb.git / testing/next branch (the commit id is 5b394b2ddf0347bef56e50c69a58773c94343ff3) with the following patch: https://patchwork.kernel.org/patch/10574875/ Changes from v1: - Fix error path on patch 3/3. - Use clk_bulk_disable_unprepare() instead of two functions on patch 3/3. - Use staic array of struct clk_bulk_data instead of a pointer on patch 3/3. Yoshihiro Shimoda (3): usb: renesas_usbhs: Add reset_control dt-bindings: usb: renesas_usbhs: add clock-names property usb: renesas_usbhs: Add multiple clocks management .../devicetree/bindings/usb/renesas_usbhs.txt | 2 + drivers/usb/renesas_usbhs/common.c | 47 ++ drivers/usb/renesas_usbhs/common.h | 5 +++ 3 files changed, 54 insertions(+) -- 1.9.1
Re: [PATCH v2] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size
Hi Wolfram,
On Fri, Aug 31, 2018 at 11:44 AM Wolfram Sang wrote:
> > As a comment in the other thread said you should not set it multiple times,
> > probably the best solution is to:
> > (a) check if dev->dma_parms is already set, and if not:
> > (b) allocate using plain kzalloc() (with a comment why!),
> > (c) not free the memory nor reset dev->dma_parms (with a comment
> > why!).
>
> Quite clumsy if done per driver, or?
Yes it is. As for other DMA parameters (e.g. DMA mask), it's a property of
the device and/or platform. So (in theory) it should be set up that way...
> If this is the intended behaviour, then there is something to improve
> with the dma_params API, or? If something which is meant to have a
> lifecycle same as the device but needs to get set during probe/remove
> lifecycle, this calls for at least a helper function which hides all
> these details?
Promote drivers/gpu/drm/exynos/exynos_drm_iommu.c:configure_dma_max_seg_size()
to a generic helper?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[VSP-Tests: PATCH] tests: add pseudo platform test
From: Kieran Bingham
Provide an initial test which can run as part of the test suite.
This test will report the platform and kernel version, along with
the identified paths of required utilities.
This will aid in ensuring that required tools are available on a
running platform - and report the kernel and platform details in
any test suite output for clarification of results.
Signed-off-by: Kieran Bingham
---
This addition allows extra information to be recorded about the system
when running the tests in a batch (or in future automated testing)
Ideally - we would report the version of each tool as well, allowing any
issues to be fully recreated.
tests/vsp-unit-test-.sh | 20
1 file changed, 20 insertions(+)
create mode 100755 tests/vsp-unit-test-.sh
diff --git a/tests/vsp-unit-test-.sh b/tests/vsp-unit-test-.sh
new file mode 100755
index ..144cfc677b32
--- /dev/null
+++ b/tests/vsp-unit-test-.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+
+# Report testing conditions
+
+model=`cat /sys/firmware/devicetree/base/model`
+
+echo "Test Conditions:"
+
+function check_all() {
+ echo " Platform: " "$model"
+ echo " Kernel release: " `uname -r`
+ echo " convert: " `which convert`
+ echo " compare: " `which compare`
+ echo " killall: " `which killall`
+ echo " raw2rgbpnm: " `which raw2rgbpnm`
+ echo " stress: " `which stress`
+ echo " yavta: " `which yavta`
+}
+
+check_all | column -ts ":"
--
2.17.1
Re: [PATCH v2] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size
> As a comment in the other thread said you should not set it multiple times, > probably the best solution is to: > (a) check if dev->dma_parms is already set, and if not: > (b) allocate using plain kzalloc() (with a comment why!), > (c) not free the memory nor reset dev->dma_parms (with a comment why!). Quite clumsy if done per driver, or? If this is the intended behaviour, then there is something to improve with the dma_params API, or? If something which is meant to have a lifecycle same as the device but needs to get set during probe/remove lifecycle, this calls for at least a helper function which hides all these details? signature.asc Description: PGP signature
[PATCH 1/2] ARM: shmobile: defconfig: Enable VIDEO_RENESAS_FDP1
R-Car Gen2 (and RZ/G1) SoCs have a Fine Display Processor, hence enable support for it. Signed-off-by: Geert Uytterhoeven --- arch/arm/configs/shmobile_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig index 7b48ec3e63ec3234..f2b40075819f4a0b 100644 --- a/arch/arm/configs/shmobile_defconfig +++ b/arch/arm/configs/shmobile_defconfig @@ -130,6 +130,7 @@ CONFIG_VIDEO_V4L2_SUBDEV_API=y CONFIG_V4L_PLATFORM_DRIVERS=y CONFIG_VIDEO_RCAR_VIN=y CONFIG_V4L_MEM2MEM_DRIVERS=y +CONFIG_VIDEO_RENESAS_FDP1=y CONFIG_VIDEO_RENESAS_JPU=y CONFIG_VIDEO_RENESAS_VSP1=y # CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set -- 2.17.1
[PATCH 0/2] ARM: defconfig: Enable VIDEO_RENESAS_FDP1
Hi Simon, Magnus,
R-Car Gen2 (and RZ/G1) SoCs have a Fine Display Processor.
Hence enable support for it, now commit 231783073ebfc4ac ("media: v4l:
rcar_fdp1: Enable compilation on Gen2 platforms") has landed in v4.19-rc1.
Thanks!
Geert Uytterhoeven (2):
ARM: shmobile: defconfig: Enable VIDEO_RENESAS_FDP1
ARM: multi_v7_defconfig: Enable VIDEO_RENESAS_FDP1
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/shmobile_defconfig | 1 +
2 files changed, 2 insertions(+)
--
2.17.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 2/2] ARM: multi_v7_defconfig: Enable VIDEO_RENESAS_FDP1
R-Car Gen2 (and RZ/G1) SoCs have a Fine Display Processor, hence enable support for it. Signed-off-by: Geert Uytterhoeven --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index a36c1b3111303563..983d8b7a410caba8 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -584,6 +584,7 @@ CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m CONFIG_VIDEO_STI_BDISP=m CONFIG_VIDEO_STI_HVA=m CONFIG_VIDEO_STI_DELTA=m +CONFIG_VIDEO_RENESAS_FDP1=m CONFIG_VIDEO_RENESAS_JPU=m CONFIG_VIDEO_RENESAS_VSP1=m CONFIG_V4L_TEST_DRIVERS=y -- 2.17.1
RE: [PATCH] clocksource: sh_cmt: fixup for 64-bit machines
Hi Sergie, Thanks for the patch. > Subject: [PATCH] clocksource: sh_cmt: fixup for 64-bit machines > > When trying to use CMT for clockevents on R-Car gen3 SoCs, I noticed that > the maximum delta (in ns) for the broadcast timer was diplayed as 1000 in %s/ diplayed/displayed Regards, Biju Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Re: [PATCH] clocksource: sh_cmt: fixup for 64-bit machines
Hi Sergei,
On Thu, Aug 30, 2018 at 9:19 PM Sergei Shtylyov
wrote:
> When trying to use CMT for clockevents on R-Car gen3 SoCs, I noticed that
> the maximum delta (in ns) for the broadcast timer was diplayed as 1000 in
> /proc/timer_list. It turned out that when calculating it, the driver did
> shift left 1 by 32 (causing what I think was undefined behaviour) getting
> 1 as a result. Using 1UL instead fixed the maximum delta and did even fix
> switching an active clocksource to a CMT channel (which caused the system
> to go non-interactive before).
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> This patch is against the 'tip.git' repo's 'timers/core' branch.
>
> I am not sure whether the CMT driver was ever used on SH64; on R-Car gen3
> (ARM64) I'm only enabling this driver now, so not sure how urgent is this...
>
> drivers/clocksource/sh_cmt.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: tip/drivers/clocksource/sh_cmt.c
> ===
> --- tip.orig/drivers/clocksource/sh_cmt.c
> +++ tip/drivers/clocksource/sh_cmt.c
> @@ -891,7 +891,7 @@ static int sh_cmt_setup_channel(struct s
> if (cmt->info->width == (sizeof(ch->max_match_value) * 8))
> ch->max_match_value = ~0;
> else
> - ch->max_match_value = (1 << cmt->info->width) - 1;
> + ch->max_match_value = (1UL << cmt->info->width) - 1;
>
> ch->match_value = ch->max_match_value;
> raw_spin_lock_init(>lock);
Shouldn't all those fields/variables be changed from "unsigned long" to "u32",
as they really should match the CMT's register sizes?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] arm64: dts: renesas: r8a7795: Move arm_cc630p node
To preserve by-address-per-group sort order.
Fixes: 0f6d237cafda2e06 ("arm64: dts: renesas: r8a7795: add ccree to device
tree")
Signed-off-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index de4f40d118d3fa65..0c6d8859cae397c9 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -525,15 +525,6 @@
status = "disabled";
};
- arm_cc630p: crypto@e6601000 {
- compatible = "arm,cryptocell-630p-ree";
- interrupts = ;
- reg = <0x0 0xe6601000 0 0x1000>;
- clocks = < CPG_MOD 229>;
- resets = < 229>;
- power-domains = < R8A7795_PD_ALWAYS_ON>;
- };
-
i2c3: i2c@e66d {
#address-cells = <1>;
#size-cells = <0>;
@@ -805,6 +796,15 @@
status = "disabled";
};
+ arm_cc630p: crypto@e6601000 {
+ compatible = "arm,cryptocell-630p-ree";
+ interrupts = ;
+ reg = <0x0 0xe6601000 0 0x1000>;
+ clocks = < CPG_MOD 229>;
+ resets = < 229>;
+ power-domains = < R8A7795_PD_ALWAYS_ON>;
+ };
+
dmac0: dma-controller@e670 {
compatible = "renesas,dmac-r8a7795",
"renesas,rcar-dmac";
--
2.17.1
Re: [PATCH] arm64: dts: renesas: r8a774a1: Add CAN nodes
Hi Fabrizio,
On Thu, Aug 23, 2018 at 4:22 PM Fabrizio Castro
wrote:
> From: Chris Paterson
>
> Add the device nodes for both RZ/G2M CAN channels.
>
> Signed-off-by: Chris Paterson
> Reviewed-by: Biju Das
> ---
>
> This patch depends on:
> https://lkml.org/lkml/2018/8/23/1049
> https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg30550.html
>
>
> arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> index 5d0109a..cd204f5 100644
> --- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
> @@ -816,6 +816,30 @@
> status = "disabled";
> };
>
> + can0: can@e6c3 {
> + compatible = "renesas,can-r8a774a1",
> +"renesas,rzg-gen2-can";
Please don't introduce "renesas,rzg-gen2-can", cfr. my comments in
https://lore.kernel.org/lkml/camuhmdwpuqfxogh_-qp8q6watu3lj_wpx0baoxpbx76skvy...@mail.gmail.com/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] arm64: dts: renesas: revise properties for usb 2.0
R-Car Gen3 needs to enable/deassert clocks/resets of both usb 2.0 host (included phy) and peripheral. Otherwise, other side device cannot work correctly. So, this patch revises properties of clocks and resets. After that, each device driver can enable/deassert clocks/resets by its self. Notes: - To work the renesas_usbhs driver correctly when host side drivers are disabled and the renesas_usbhs driver doesn't have multiple clock management, this patch doesn't change the order of the clocks property in each hsusb node. - This patch doesn't have any side-effects even if the renesas_usbhs driver doesn't have reset_control and multiple clock management. Signed-off-by: Yoshihiro Shimoda --- This patch is based on the renesas.git / renesas-devel-20180830-v4.19-rc1 tag. This patch is related to the following patch series: https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=13587 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 34 --- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 17 arch/arm64/boot/dts/renesas/r8a77965.dtsi | 17 arch/arm64/boot/dts/renesas/r8a77990.dtsi | 12 +-- arch/arm64/boot/dts/renesas/r8a77995.dtsi | 12 +-- 5 files changed, 48 insertions(+), 44 deletions(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index c417d4a..9e9aead 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -707,7 +707,8 @@ "renesas,rcar-gen3-usbhs"; reg = <0 0xe659 0 0x100>; interrupts = ; - clocks = < CPG_MOD 704>; + clocks = < CPG_MOD 704>, < CPG_MOD 703>; + clock-names = "hsusb", "ehci/ohci"; dmas = <_dmac0 0>, <_dmac0 1>, <_dmac1 0>, <_dmac1 1>; dma-names = "ch0", "ch1", "ch2", "ch3"; @@ -715,7 +716,7 @@ phys = <_phy0>; phy-names = "usb"; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 704>; + resets = < 704>, < 703>; status = "disabled"; }; @@ -724,7 +725,8 @@ "renesas,rcar-gen3-usbhs"; reg = <0 0xe659c000 0 0x100>; interrupts = ; - clocks = < CPG_MOD 705>; + clocks = < CPG_MOD 705>, < CPG_MOD 700>; + clock-names = "hsusb", "ehci/ohci"; dmas = <_dmac2 0>, <_dmac2 1>, <_dmac3 0>, <_dmac3 1>; dma-names = "ch0", "ch1", "ch2", "ch3"; @@ -732,7 +734,7 @@ phys = <_phy3>; phy-names = "usb"; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 705>; + resets = < 705>, < 700>; status = "disabled"; }; @@ -2098,11 +2100,11 @@ compatible = "generic-ohci"; reg = <0 0xee08 0 0x100>; interrupts = ; - clocks = < CPG_MOD 703>; + clocks = < CPG_MOD 703>, < CPG_MOD 704>; phys = <_phy0>; phy-names = "usb"; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 703>; + resets = < 703>, < 704>; status = "disabled"; }; @@ -2134,11 +2136,11 @@ compatible = "generic-ohci"; reg = <0 0xee0e 0 0x100>; interrupts = ; - clocks = < CPG_MOD 700>; + clocks = < CPG_MOD 700>, < CPG_MOD 705>; phys = <_phy3>; phy-names = "usb"; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 700>; + resets = < 700>, < 705>; status = "disabled"; }; @@ -2146,12 +2148,12 @@ compatible = "generic-ehci"; reg = <0 0xee080100 0 0x100>; interrupts = ; - clocks = < CPG_MOD 703>; + clocks = < CPG_MOD 703>, < CPG_MOD 704>; phys = <_phy0>; phy-names = "usb"; companion = <>; power-domains = < R8A7795_PD_ALWAYS_ON>; - resets = < 703>; + resets = < 703>, < 704>; status
Re: [PATCH v2] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size
Hi Niklas,
On Fri, Aug 31, 2018 at 9:57 AM Niklas Söderlund
wrote:
> On 2018-08-31 00:10:28 +0200, Geert Uytterhoeven wrote:
> > On Thu, Aug 30, 2018 at 11:39 PM Niklas Söderlund
> > wrote:
> > > Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a
> > > device_dma_parameters structure and filling in the max segment size. The
> > > size used is the result of a discussion with Renesas hardware engineers
> > > and unfortunately not found in the datasheet.
> > >
> > > renesas_sdhi_internal_dmac ee14.sd: DMA-API: mapping sg segment
> > > longer than device claims to support [len=126976] [max=65536A]
> > > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > > @@ -308,12 +308,23 @@ static const struct soc_device_attribute
> > > gen3_soc_whitelist[] = {
> > > static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
> > > {
> > > const struct soc_device_attribute *soc =
> > > soc_device_match(gen3_soc_whitelist);
> > > + struct device *dev = >dev;
> > >
> > > if (!soc)
> > > return -ENODEV;
> > >
> > > global_flags |= (unsigned long)soc->data;
> > >
> > > + if (!dev->dma_parms) {
> >
> > I guess dev->dma_parms is retained on unbind/rebind?
> >
> > > + dev->dma_parms = devm_kzalloc(dev,
> > > sizeof(*dev->dma_parms),
> > > + GFP_KERNEL);
> >
> > But by using devm_kzalloc(), the memory will be freed, and lead to reuse
> > after
> > free?
>
> I don't know how the unbind/rebind behaves in this regard. In v1 of this
I expect the struct device to be retained. You can check with sysfs unbind/bind,
and CONFIG_DEBUG_SLAB=y to enable poisoning on free (or just print
the value found for less spectacular behavior ;-)
> patch I used kzalloc() and a remove function to free the memory and
> reset the dev->dma_parms pointe to NULL. Do you think that is the
> correct approach here?
As a comment in the other thread said you should not set it multiple times,
probably the best solution is to:
(a) check if dev->dma_parms is already set, and if not:
(b) allocate using plain kzalloc() (with a comment why!),
(c) not free the memory nor reset dev->dma_parms (with a comment why!).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size
Hi Geert,
Thanks for your feedback.
On 2018-08-31 00:10:28 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> Thanks for your patch!
>
> On Thu, Aug 30, 2018 at 11:39 PM Niklas Söderlund
> wrote:
> > Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a
> > device_dma_parameters structure and filling in the max segment size. The
> > size used is the result of a discussion with Renesas hardware engineers
> > and unfortunately not found in the datasheet.
> >
> > renesas_sdhi_internal_dmac ee14.sd: DMA-API: mapping sg segment
> > longer than device claims to support [len=126976] [max=65536A]
>
> Bogus trailing "A".
Thanks, that is a odd copy-and-past error :-)
>
> > Signed-off-by: Niklas Söderlund
> > Reported-by: Geert Uytterhoeven
> >
> > ---
> >
> > * Changes since v1
> > - Use devm_kzalloc() instead of a custom remove function to clean up.
> > ---
> > drivers/mmc/host/renesas_sdhi_internal_dmac.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > index c9dab9ce1ed55174..715e0c5dc30e4ebf 100644
> > --- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > +++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
> > @@ -308,12 +308,23 @@ static const struct soc_device_attribute
> > gen3_soc_whitelist[] = {
> > static int renesas_sdhi_internal_dmac_probe(struct platform_device *pdev)
> > {
> > const struct soc_device_attribute *soc =
> > soc_device_match(gen3_soc_whitelist);
> > + struct device *dev = >dev;
> >
> > if (!soc)
> > return -ENODEV;
> >
> > global_flags |= (unsigned long)soc->data;
> >
> > + if (!dev->dma_parms) {
>
> I guess dev->dma_parms is retained on unbind/rebind?
>
> > + dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
> > + GFP_KERNEL);
>
> But by using devm_kzalloc(), the memory will be freed, and lead to reuse after
> free?
I don't know how the unbind/rebind behaves in this regard. In v1 of this
patch I used kzalloc() and a remove function to free the memory and
reset the dev->dma_parms pointe to NULL. Do you think that is the
correct approach here?
>
> > + if (!dev->dma_parms)
> > + return -ENOMEM;
> > + }
> > +
> > + if (dma_set_max_seg_size(dev, 0x))
> > + dev_warn(dev, "Unable to set seg size\n");
> > +
> > return renesas_sdhi_probe(pdev,
> > _sdhi_internal_dmac_dma_ops);
> > }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
Regards,
Niklas Söderlund
