EMail problems :(
Hi all, my main mail service (the-dreams.de) seems to be defunct currently. Until this is resolved, I can be reached via this email address. Sorry for the inconvenience, Wolfram signature.asc Description: PGP signature
[git pull] clk: renesas: Updates for v4.10 (take three)
Hi Mike, Stephen,
The following changes since commit 1936be95e013802291201c1ed193e04fd1ed3d13:
Merge branch 'rzg-clock-defs' into clk-renesas-for-v4.10 (2016-11-07 15:15:33
+0100)
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.10-tag3
for you to fetch changes up to 9127d54bb89471592b3c8af6c6273c21db6de6a6:
clk: renesas: cpg-mssr: Add R8A7745 support (2016-11-10 15:29:30 +0100)
clk: renesas: Updates for v4.10 (take three)
- CSI2 and VIN clocks for R-Car M3-W,
- Clock drivers for new RZ/G1M and RZ/G1E SoCs,
- Minor bug fix for R-Car H3.
This pull request depends on the pull request for
tags/clk-renesas-for-v4.10-tag2 ("clk: renesas: Updates for v4.10 (take
two)"), which I sent last week.
Thanks for pulling!
Niklas Söderlund (2):
clk: renesas: r8a7796: Add CSI2 clocks
clk: renesas: r8a7796: Add VIN clocks
Sergei Shtylyov (3):
clk: renesas: cpg-mssr: Add common R-Car Gen2 support
clk: renesas: cpg-mssr: Add R8A7743 support
clk: renesas: cpg-mssr: Add R8A7745 support
Takeshi Kihara (1):
clk: renesas: r8a7795: Fix HDMI parent clock
.../devicetree/bindings/clock/renesas,cpg-mssr.txt | 5 +-
drivers/clk/renesas/Kconfig| 2 +
drivers/clk/renesas/Makefile | 2 +
drivers/clk/renesas/r8a7743-cpg-mssr.c | 270 +++
drivers/clk/renesas/r8a7745-cpg-mssr.c | 259 ++
drivers/clk/renesas/r8a7795-cpg-mssr.c | 2 +-
drivers/clk/renesas/r8a7796-cpg-mssr.c | 12 +
drivers/clk/renesas/rcar-gen2-cpg.c| 371 +
drivers/clk/renesas/rcar-gen2-cpg.h| 43 +++
drivers/clk/renesas/renesas-cpg-mssr.c | 12 +
drivers/clk/renesas/renesas-cpg-mssr.h | 2 +
11 files changed, 978 insertions(+), 2 deletions(-)
create mode 100644 drivers/clk/renesas/r8a7743-cpg-mssr.c
create mode 100644 drivers/clk/renesas/r8a7745-cpg-mssr.c
create mode 100644 drivers/clk/renesas/rcar-gen2-cpg.c
create mode 100644 drivers/clk/renesas/rcar-gen2-cpg.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.10 (take two)
Hi Linus,
The following changes since commit 0f866a9679215838328e1c0ed1892224672bb396:
pinctrl: sh-pfc: r8a7796: Fix GPSR definitions for SDHI2/3 (2016-11-07
10:39:11 +0100)
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.10-tag2
for you to fetch changes up to 1fa1522f61f1fa53b2518c82bb3c667161836e10:
pinctrl: sh-pfc: r8a7795: Add group for QSPI0 and QSPI1 pins (2016-11-16
10:29:14 +0100)
pinctrl: sh-pfc: Updates for v4.10 (take two)
- DU and EtherAVB pin groups for R-Car M3-W,
- Bias handling cleanups and bug fixes,
- Drive-strength for non-GPIO pins for R-Car H3,
- EtherAVB MDIO & MII, and QSPI pin groups for R-Car H3.
Thanks for pulling!
Niklas Söderlund (10):
pinctrl: sh-pfc: r8a7796: Add DU support
pinctrl: sh-pfc: Do not unconditionally support PIN_CONFIG_BIAS_DISABLE
pinctrl: sh-pfc: Add helper to handle bias lookup table
pinctrl: sh-pfc: r8a7795: Simplify get bias logic
pinctrl: sh-pfc: r8a7795: Use lookup function for bias data
pinctrl: sh-pfc: r8a7778: Use lookup function for bias data
pinctrl: sh-pfc: Support named pins with custom configuration
pinctrl: sh-pfc: r8a7795: Support none GPIO pins with configurable
drive-strength
pinctrl: sh-pfc: r8a7795: Add group for AVB MDIO and MII pins
pinctrl: sh-pfc: r8a7795: Add group for QSPI0 and QSPI1 pins
Takeshi Kihara (1):
pinctrl: sh-pfc: r8a7796: Add EtherAVB pins, groups and functions
drivers/pinctrl/sh-pfc/core.c| 15 +
drivers/pinctrl/sh-pfc/core.h| 4 +
drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 342 +--
drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 616 ---
drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 188 +++
drivers/pinctrl/sh-pfc/pinctrl.c | 3 +-
drivers/pinctrl/sh-pfc/sh_pfc.h | 14 +
7 files changed, 816 insertions(+), 366 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
[PATCH] cpufreq: dt: Add support for r8a7743 and r8a7745
Add the compatible strings for supporting the generic cpufreq driver on
the Renesas RZ/G1M (r8a7743) and RZ/G1E (r8a7745) SoCs.
Signed-off-by: Geert Uytterhoeven
---
Support for RZ/G1M and RZ/G1E is expected to land in v4.10.
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index fcc5bcfe57efe1c3..0c73c7dbd5878919 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -55,6 +55,8 @@
{ .compatible = "renesas,r7s72100", },
{ .compatible = "renesas,r8a73a4", },
{ .compatible = "renesas,r8a7740", },
+ { .compatible = "renesas,r8a7743", },
+ { .compatible = "renesas,r8a7745", },
{ .compatible = "renesas,r8a7778", },
{ .compatible = "renesas,r8a7779", },
{ .compatible = "renesas,r8a7790", },
--
1.9.1
Re: [PATCH] cpufreq: dt: Add support for r8a7743 and r8a7745
On 16-11-16, 11:05, Geert Uytterhoeven wrote: > Add the compatible strings for supporting the generic cpufreq driver on > the Renesas RZ/G1M (r8a7743) and RZ/G1E (r8a7745) SoCs. > > Signed-off-by: Geert Uytterhoeven > --- > Support for RZ/G1M and RZ/G1E is expected to land in v4.10. Acked-by: Viresh Kumar -- viresh
Re: [PATCH v4 07/14] ARM: dts: koelsch: use demuxer for I2C4
Hi Simon,
On Tue, Nov 15, 2016 at 6:44 PM, Simon Horman wrote:
>> i2c4 shares pins with vin0. Hence enabling the former breaks the latter:
>>
>> sh-pfc e606.pfc: pin GP_4_13 already requested by
>> e652.i2c; cannot claim for e6ef.video
>> sh-pfc e606.pfc: pin-141 (e6ef.video) status -22
>> sh-pfc e606.pfc: could not request pin 141 (GP_4_13) from
>> group vin0_data24 on device sh-pfc
>> rcar-vin e6ef.video: Error applying setting, reverse things back
>> rcar-vin: probe of e6ef.video failed with error -22
>>
>> There may be similar issues on other boards. Haven't checked yet.
>
> Thanks, I will drop this patch for now.
>
> I checked the boot logs of other boards with similar patches and didn't see
> anything there.
Do you have CONFIG_VIDEO_ADV7604=y?
I expect the issue to be present on gose, too. So far I didn't see it
there, yet.
But the vin DTS of gose is different from koelsch, causing vin0 not to be
initialized?
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] cpufreq: dt: Add support for r8a7743 and r8a7745
On Wed, Nov 16, 2016 at 11:05:51AM +0100, Geert Uytterhoeven wrote: > Add the compatible strings for supporting the generic cpufreq driver on > the Renesas RZ/G1M (r8a7743) and RZ/G1E (r8a7745) SoCs. > > Signed-off-by: Geert Uytterhoeven > --- > Support for RZ/G1M and RZ/G1E is expected to land in v4.10. Acked-by: Simon Horman
Re: [PATCH v4 07/14] ARM: dts: koelsch: use demuxer for I2C4
On Tue, Nov 15, 2016 at 4:45 PM, Geert Uytterhoeven
wrote:
> i2c4 shares pins with vin0. Hence enabling the former breaks the latter:
>
> sh-pfc e606.pfc: pin GP_4_13 already requested by
> e652.i2c; cannot claim for e6ef.video
> sh-pfc e606.pfc: pin-141 (e6ef.video) status -22
> sh-pfc e606.pfc: could not request pin 141 (GP_4_13) from
> group vin0_data24 on device sh-pfc
> rcar-vin e6ef.video: Error applying setting, reverse things back
> rcar-vin: probe of e6ef.video failed with error -22
>
> There may be similar issues on other boards. Haven't checked yet.
I inspected the DTSes for Koelsch, Lager, Gose, and Alt, looking for
conflicting configurations of pins:
- Lager:
- i2c1 and iic1 share GP1_16 and GP1_17, but that is handled through
i2c-demux-pinctrl
- usb0_ovc_vbus and usb0 share GP5_19, but that is probably OK, as these
groups are configured for the same function?
- Koelsch: i2c4 and and vin0_data24 share pins GP4_13 and GP4_14
(vin0_data8 would be OK)
- Gose: Same issue as Koelsch.
- Alt: No conflicts.
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 v4 07/14] ARM: dts: koelsch: use demuxer for I2C4
On Wed, Nov 16, 2016 at 11:35:22AM +0100, Geert Uytterhoeven wrote: > Hi Simon, > > On Tue, Nov 15, 2016 at 6:44 PM, Simon Horman wrote: > >> i2c4 shares pins with vin0. Hence enabling the former breaks the latter: > >> > >> sh-pfc e606.pfc: pin GP_4_13 already requested by > >> e652.i2c; cannot claim for e6ef.video > >> sh-pfc e606.pfc: pin-141 (e6ef.video) status -22 > >> sh-pfc e606.pfc: could not request pin 141 (GP_4_13) from > >> group vin0_data24 on device sh-pfc > >> rcar-vin e6ef.video: Error applying setting, reverse things back > >> rcar-vin: probe of e6ef.video failed with error -22 > >> > >> There may be similar issues on other boards. Haven't checked yet. > > > > Thanks, I will drop this patch for now. > > > > I checked the boot logs of other boards with similar patches and didn't see > > anything there. > > Do you have CONFIG_VIDEO_ADV7604=y? No, mainly because its not in shmobile_defconfig. I tried again with that option enabled and still didn't see anything of interest in kernel log. > I expect the issue to be present on gose, too. So far I didn't see it > there, yet. > But the vin DTS of gose is different from koelsch, causing vin0 not to be > initialized? It seems so.
Re: [PATCH v4 07/14] ARM: dts: koelsch: use demuxer for I2C4
Hi Simon,
On Wed, Nov 16, 2016 at 2:47 PM, Simon Horman wrote:
> On Wed, Nov 16, 2016 at 11:35:22AM +0100, Geert Uytterhoeven wrote:
>> On Tue, Nov 15, 2016 at 6:44 PM, Simon Horman wrote:
>> >> i2c4 shares pins with vin0. Hence enabling the former breaks the latter:
>> >>
>> >> sh-pfc e606.pfc: pin GP_4_13 already requested by
>> >> e652.i2c; cannot claim for e6ef.video
>> >> sh-pfc e606.pfc: pin-141 (e6ef.video) status -22
>> >> sh-pfc e606.pfc: could not request pin 141 (GP_4_13) from
>> >> group vin0_data24 on device sh-pfc
>> >> rcar-vin e6ef.video: Error applying setting, reverse things back
>> >> rcar-vin: probe of e6ef.video failed with error -22
>> >>
>> >> There may be similar issues on other boards. Haven't checked yet.
>> >
>> > Thanks, I will drop this patch for now.
>> >
>> > I checked the boot logs of other boards with similar patches and didn't see
>> > anything there.
>>
>> Do you have CONFIG_VIDEO_ADV7604=y?
>
> No, mainly because its not in shmobile_defconfig.
>
> I tried again with that option enabled and still didn't see
> anything of interest in kernel log.
>
>> I expect the issue to be present on gose, too. So far I didn't see it
>> there, yet.
>> But the vin DTS of gose is different from koelsch, causing vin0 not to be
>> initialized?
>
> It seems so.
I managed to reproduce the issue on gose, by adding r8a7793 support to
my koelsch .config.
Apparently I was missing CONFIG_I2C_DEMUX_PINCTRL=y.
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 v4 07/14] ARM: dts: koelsch: use demuxer for I2C4
On Wed, Nov 16, 2016 at 03:14:11PM +0100, Geert Uytterhoeven wrote: > Hi Simon, > > On Wed, Nov 16, 2016 at 2:47 PM, Simon Horman wrote: > > On Wed, Nov 16, 2016 at 11:35:22AM +0100, Geert Uytterhoeven wrote: > >> On Tue, Nov 15, 2016 at 6:44 PM, Simon Horman wrote: > >> >> i2c4 shares pins with vin0. Hence enabling the former breaks the latter: > >> >> > >> >> sh-pfc e606.pfc: pin GP_4_13 already requested by > >> >> e652.i2c; cannot claim for e6ef.video > >> >> sh-pfc e606.pfc: pin-141 (e6ef.video) status -22 > >> >> sh-pfc e606.pfc: could not request pin 141 (GP_4_13) from > >> >> group vin0_data24 on device sh-pfc > >> >> rcar-vin e6ef.video: Error applying setting, reverse things back > >> >> rcar-vin: probe of e6ef.video failed with error -22 > >> >> > >> >> There may be similar issues on other boards. Haven't checked yet. > >> > > >> > Thanks, I will drop this patch for now. > >> > > >> > I checked the boot logs of other boards with similar patches and didn't > >> > see > >> > anything there. > >> > >> Do you have CONFIG_VIDEO_ADV7604=y? > > > > No, mainly because its not in shmobile_defconfig. > > > > I tried again with that option enabled and still didn't see > > anything of interest in kernel log. > > > >> I expect the issue to be present on gose, too. So far I didn't see it > >> there, yet. > >> But the vin DTS of gose is different from koelsch, causing vin0 not to be > >> initialized? > > > > It seems so. > > I managed to reproduce the issue on gose, by adding r8a7793 support to > my koelsch .config. > Apparently I was missing CONFIG_I2C_DEMUX_PINCTRL=y. Ok, thanks. Curious that I didn't see it. It looks like we should drop: ARM: dts: gose: use demuxer for I2C4
Re: [git pull] pinctrl: sh-pfc: Updates for v4.10 (take two)
On Wed, Nov 16, 2016 at 10:47 AM, Geert Uytterhoeven wrote: > Hi Linus, > > The following changes since commit 0f866a9679215838328e1c0ed1892224672bb396: > > pinctrl: sh-pfc: r8a7796: Fix GPSR definitions for SDHI2/3 (2016-11-07 > 10:39:11 +0100) > > 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.10-tag2 Pulled into the pin control tree, thanks a lot! Yours, Linus Walleij
Re: [PATCH 3/4] arm64: dts: renesas: r8a7796: Add DU device to DT
Hi Laurent, On Wed, Nov 16, 2016 at 4:12 AM, Laurent Pinchart wrote: > Hello Magnus, > > On Thursday 27 Oct 2016 18:40:31 Laurent Pinchart wrote: >> On Thursday 27 Oct 2016 16:25:35 Magnus Damm wrote: >> > On Thu, Oct 27, 2016 at 4:13 PM, Simon Horman wrote: >> >> On Thu, Oct 27, 2016 at 03:52:44PM +0900, Magnus Damm wrote: >> >>> On Thu, Oct 20, 2016 at 5:56 PM, Simon Horman wrote: >> On Tue, Oct 18, 2016 at 12:19:26PM +0300, Laurent Pinchart wrote: >> > On Tuesday 18 Oct 2016 11:05:32 Geert Uytterhoeven wrote: >> >> On Mon, Oct 17, 2016 at 11:34 PM, Laurent Pinchart wrote: >> >>> Add the DU device to r8a7796.dtsi in a disabled state. >> >>> >> >>> Signed-off-by: Laurent Pinchart >> >>> >> >> >> >> Reviewed-by: Geert Uytterhoeven >> > >> > Could you please pick patches 1/4 to 3/4 from this series and apply >> > them to your tree ? For convenience I've pushed them to >> > >> > git://linuxtv.org/pinchartl/media.git drm/r8a7796/dt >> > >> > along with patch "arm64: dts: renesas: r8a7795: Remove FCP >> > SoC-specific compatible strings" that has been acked too. If you pull >> > from that branch please make sure you skip the top-most patch "arm64: >> > dts: renesas: r8a7796-salvator-x: Enable DU" for now. >> >> Sure, done. >> >>> >> >>> I think we should hold off with the upstreaming of the DU and VSP >> >>> integration code for now. Sorry for noticing this late, but I thought >> >>> we had already discussed the integration order and that merge of >> >>> non-64-bit capable devices need to be put on hold. >> >>> >> >>> In particular, not so much the DU device (this patch) but more the VSP >> >>> instances. The reason for that is that VSP devices can only perform >> >>> 32-bit bus mastering without IOMMU. I believe next step for all this >> >>> would be to enable all on-board memory on r8a7796 Salvator-x, but I >> >>> think Geert is working on that. >> >> >> >> So you would like to see the following patches dropped? >> >> >> >> ee73acb13978 arm64: dts: renesas: r8a7796: Add VSP instances >> >> 0a6519d782fd arm64: dts: renesas: r8a7796: Add FCPF and FCPV instances >> > >> > Yes, that would be great. Sorry for not noticing earlier. >> >> I'm sorry, but I don't agree with that. First of all the FCP has no issue >> with >4GB memory as it doesn't perform DMA itself. Then, while the IPMMU is >> >> required to operate the VSP with >4GB memory, enabling the VSP instances >> won't break anything as unlike the DU the VSPs won't be used by standard >> kernel or userspace components. > > Ping ? Thanks for the ping. First of all, we might have slightly different view of the hardware, so this might need some further discussions. Also, this topic in my mind is mainly about DT integration code merge ordering for r8a7796 to enable >4GB memory access early on without introducing any potential issues. Regarding the hardware and FCP, VSP and DU, I think we for R-Car Gen3 can agree on that the DU does not perform any bus mastering itself, but relies of VSP for this to happen. VSP however in my opinion also relies on FCP for bus mastering on R-Car Gen3. So this is conflicting with your statement that FCP does not perform DMA itself - maybe you are referring to the kernel driver instead of the hardware? Our potentially different view makes me confused! =) About the integration patches for FCP, VSP and DU, what do you propose merging? I think it is easy to draw a line in the sand and say that since the DU is lacking support for IPMMU on R-Car Gen3 in upstream it is too early to try to integrate any related components including VSP and FCP (that are used with DU). I don't see the merit of half-integrated support. Once the DU driver code for r8a7796 (including support for using IPMMU) is ready upstream merge it will be simple enough to enable in DT, don't you think? If the code happens to be ready and available in -next then I think DT changes can be merged in parallel as well. Thanks, / magnus
Re: ALSA analog audio loopback test tool (atest)
Hi Ulrich, On Tue, Nov 15, 2016 at 8:56 PM, Ulrich Hecht wrote: > Hi! > > I have just pushed atest (https://github.com/uli/atest). It's a tool > to automatically verify operation of analog audio hardware remotely > (i.e. without being able to listen to the output) using a loopback > cable between the analog audio input and output. > > It works by sending a message encoded by a HAM radio codec (Q15X25) > out on the output and decoding whatever arrives at the input. It sends > a different message on every channel and can thus detect if channels > are swapped around. > > Details on using it (especially on how to set up the mixers) can be > found in the README file. Have fun! Thanks for your efforts! Quick question, the dependency on zlib seems to come from using adler32() for checksum comparison. In the code you seem to compare the total amount of data anyway, so I guess the checksum seems to be there to get some early notification about potential mismatch. The potential error will be discovered using the full-data-comparison later on anyway. I'm not sure if that's the way the code works, but if so then it should be easy to reduce the number of dependencies by simply dropping the checksum code. Does that make sense to you? Cheers, / magnus
