* Low network throughput on i.MX28
From: Jörg Krause @ 2016-11-04 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ac897803-47e5-6b0b-5664-6dc165c56c23@i2se.com>
Hi Shawn,
On Wed, 2016-11-02 at 09:24 +0100, Stefan Wahren wrote:
> Am 02.11.2016 um 09:14 schrieb J?rg Krause:
> > On Sat, 2016-10-29 at 11:08 +0200, Stefan Wahren wrote:
> > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 29. Oktober
> > > > 2016
> > > > um 01:07
> > > > geschrieben:
> > > >
> > > >
> > > > You mentioned [1] an optimization in the Freescale vendor Linux
> > > > kernel
> > > > [2]. I would really like to see this optimization in the
> > > > mainline
> > > > kernel.
> > > >
> > > > Did you ever tried to port this code from Freescale to
> > > > mainline?
> > >
> > > Yes, i tried once but i was frustrated soon because of the lot of
> > > required
> > > changes and resulting issues.
> >
> > I got the PIO mode working for the mxs-mmc driver. For this I
> > ported
> > the PIO code from the vendor kernel and removed the usage of the
> > DMA
> > engine entirely.
>
> Good job
>
> >
> > Testing network bandwidth with iperf, I get about ~10Mbit/sec with
> > PIO
> > mode compared to ~6.5Mbit/sec with DMA mode for UDP and about
> > ~6.5Mbit/sec compared to ~4.5Mbit/sec with DMA mode for TCP.
>
> And how about MMC / sd card performance?
I noticed poor performance with the i.MX28 MMC and/or DMA driver using
the mainline kernel compared to the vendor Freescale kernel 2.6.35.
I've seen that hou have added the drivers to mainline some years ago.
My custom i.MX28 board has a wifi chip attached to the SSP2 interface.
Comparing the bandwith with iperf I get >20Mbits/sec on the vendor
kernel and <5Mbits/sec on the mainline kernel.
My best guess is that there is some kind of bottleneck in the drivers.
I already started looking at the vendor drivers as well as@the
mainline drivers, but I need some more investigation to understand the
complexity.
Do you have any idea what the bottleneck might be?
Best regards,
J?rg Krause
^ permalink raw reply
* [PATCH V3 0/6] ARM64: Uprobe support added
From: Catalin Marinas @ 2016-11-04 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104174951.vj4il3xkdy7a2ln7@localhost>
On Fri, Nov 04, 2016 at 11:49:51AM -0600, Catalin Marinas wrote:
> On Wed, Nov 02, 2016 at 02:40:40PM +0530, Pratyush Anand wrote:
> > Pratyush Anand (6):
> > arm64: kprobe: protect/rename few definitions to be reused by uprobe
> > arm64: kgdb_step_brk_fn: ignore other's exception
> > arm64: Handle TRAP_TRACE for user mode as well
> > arm64: Handle TRAP_BRKPT for user mode as well
> > arm64: introduce mm context flag to keep 32 bit task information
> > arm64: Add uprobe support
>
> I queued the patches for 4.10. I will push them into -next sometime next
> week once I do some testing (I'm currently at the LPC).
I spoke too soon. With these patches on top of 4.9-rc3, defconfig
together with FTRACE and UPROBE_EVENT enabled I get:
In file included from /work/Linux/linux-2.6-aarch64/arch/arm64/kernel/probes/decode-insn.c:20:0:
/work/Linux/linux-2.6-aarch64/arch/arm64/include/asm/kprobes.h:52:5: error: conflicting types for 'kprobe_fault_handler'
int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
^~~~~~~~~~~~~~~~~~~~
In file included from /work/Linux/linux-2.6-aarch64/arch/arm64/kernel/probes/decode-insn.c:17:0:
/work/Linux/linux-2.6-aarch64/include/linux/kprobes.h:398:90: note: previous definition of 'kprobe_fault_handler' was here
static inline int kprobe_fault_handler(struct pt_regs *regs, int trapnr)
^
/work/Linux/linux-2.6-aarch64/scripts/Makefile.build:290: recipe for target 'arch/arm64/kernel/probes/decode-insn.o' failed
--
Catalin
^ permalink raw reply
* [PATCH v3 2/6] arm64: arch_timer: Introduce a generic erratum handing mechanism for fsl-a008585
From: Will Deacon @ 2016-11-04 18:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104182050.GA1651@buserror.net>
On Fri, Nov 04, 2016 at 01:20:50PM -0500, Scott Wood wrote:
> On Fri, Nov 04, 2016 at 09:06:30PM +0800, Ding Tianhong wrote:
> > The workaround for hisilicon,161601 will check the return value of the system counter
> > by different way, in order to distinguish with the fsl-a008585 workaround, introduce
> > a new generic erratum handing mechanism for fsl-a008585 and rename some functions.
> >
> > v2: Introducing a new generic erratum handling mechanism for fsl erratum a008585.
> >
> > v3: Introducing the erratum_workaround_set_sne generic function for fsl erratum a008585
> > and make the #define __fsl_a008585_read_reg to be private to the .c file instead of
> > being globally visible. After discussion with Marc and Will, a consensus decision was
> > made to remove the commandline parameter for enabling fsl,erratum-a008585 erratum,
> > and make some generic name more specific, export timer_unstable_counter_workaround
> > for module access.
>
> The command line paramter was added at Marc's request to provide a way of
> enbaling the workaround in a KVM guest, until API is added to allow QEMU to
> discover the need to set the property in the guest device tree. Is there an
> alternative?
Yes -- generate the device-tree property to indicate that there's an issue.
Will
^ permalink raw reply
* Low network throughput on i.MX28
From: Stefan Wahren @ 2016-11-04 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478285097.26659.2.camel@embedded.rocks>
Hi J?rg,
> J?rg Krause <joerg.krause@embedded.rocks> hat am 4. November 2016 um 19:44
> geschrieben:
>
>
> Hi Shawn,
>
> On Wed, 2016-11-02 at 09:24 +0100, Stefan Wahren wrote:
> > Am 02.11.2016 um 09:14 schrieb J?rg Krause:
> > > On Sat, 2016-10-29 at 11:08 +0200, Stefan Wahren wrote:
> > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 29. Oktober
> > > > > 2016
> > > > > um 01:07
> > > > > geschrieben:
> > > > >
> > > > >
> > > > > You mentioned [1] an optimization in the Freescale vendor Linux
> > > > > kernel
> > > > > [2]. I would really like to see this optimization in the
> > > > > mainline
> > > > > kernel.
> > > > >
> > > > > Did you ever tried to port this code from Freescale to
> > > > > mainline?
> > > >
> > > > Yes, i tried once but i was frustrated soon because of the lot of
> > > > required
> > > > changes and resulting issues.
> > >
> > > I got the PIO mode working for the mxs-mmc driver. For this I
> > > ported
> > > the PIO code from the vendor kernel and removed the usage of the
> > > DMA
> > > engine entirely.
> >
> > Good job
> >
> > >
> > > Testing network bandwidth with iperf, I get about ~10Mbit/sec with
> > > PIO
> > > mode compared to ~6.5Mbit/sec with DMA mode for UDP and about
> > > ~6.5Mbit/sec compared to ~4.5Mbit/sec with DMA mode for TCP.
> >
> > And how about MMC / sd card performance?
>
> I noticed poor performance with the i.MX28 MMC and/or DMA driver using
> the mainline kernel compared to the vendor Freescale kernel 2.6.35.
> I've seen that hou have added the drivers to mainline some years ago.
>
> My custom i.MX28 board has a wifi chip attached to the SSP2 interface.
> Comparing the bandwith with iperf I get >20Mbits/sec on the vendor
> kernel and <5Mbits/sec on the mainline kernel.
there is one thing about the clock handling. I noticed that the Vendor Kernel
round up the clock frequency and the Mainline Kernel round down the clock
frequency [1]. So don't trust the clock ratings from DT / board code. Better
verify the register settings or check it with an osci.
[1] - http://www.spinics.net/lists/linux-mmc/msg09132.html
>
> My best guess is that there is some kind of bottleneck in the drivers.
> I already started looking at the vendor drivers as well as at the
> mainline drivers, but I need some more investigation to understand the
> complexity.
>
> Do you have any idea what the bottleneck might be?
>
> Best regards,
> J?rg Krause
^ permalink raw reply
* [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state
From: Stephen Boyd @ 2016-11-04 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXOW4Ubafu=x9pCw_W-MtLGe3N974dbfHCH5TJuUAeYrQ@mail.gmail.com>
On 11/02, Geert Uytterhoeven wrote:
> On Tue, Nov 1, 2016 at 12:25 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > Would the pull requests for clk also have dts changes at the base
> > of the tree? Perhaps clk side can just ack the clk patches and
>
> Yes they would: this is moving functionality from platform code to DT.
> Without the DT updates, it will break bisection (except for R-Car Gen2,
> where we have fallback code to handle old DTBs).
>
> > then have it all routed through arm-soc? The only worry I have is
> > if we need to make some sort of change in clk side that conflicts
> > with these changes. I don't usually like taking dts changes
> > through clk tree, so I'd like to avoid that if possible.
>
> Everything could go through arm-soc only with your Acked-by.
> However, there are new clock drivers pending on this series.
> Either they have to go through arm-soc, too, or this series would
> be pulled into the clk tree with these new clock drivers.
>
> > Part E could happen anytime after everything else happens, so
> > that doesn't seem like a concern.
>
> Part E can indeed by postponed.
> But if parts A-D are applied together, there's no reason to postpone part E.
>
> > Part C could also be made to
> > only call into the new reset drivers if the reset dts nodes are
> > present? If that's done then we could merge clk patches anytime
> > and remove the dead code and the node search at some later time
> > when everything has settled?
>
> That would require adding more backwards compatibility code for
> old DTBs, even for platform where we're not interested in maintaining
> that. In addition, Part C depends on the header file for the reset driver
> to compile the clock driver, even if you would add some DT detection,
> and on the reset driver to link. So I'm afraid this is not feasible.
>
TL;DR: Sounds fine, I'll be on the lookout for the PR.
Longer version: Let me step back a bit and actually think about
this longer than 2 minutes. From what I see
rcar_rst_read_mode_pins() already returns -ENODEV if the nodes
aren't present. Great.
So clk tree could be given a pull for the clk patches, part C, on
top of part A, the reset driver. If the rcar_rst_read_mode_pins()
returns failure because the node is missing, we fall back to the
old style of doing things. Some drivers already do that anyway,
so this looks to be replacing things like
if (rcar_rst_read_mode_pins())
return;
with
if (rcar_rst_read_mode_pins() != -ENODEV)
return;
Then in arm-soc tree, the dts patches are merged. That causes us
to do some duplicate work reading the pins twice in mach-shmobile
and in the new reset driver. That's duplicate/wasteful, but it
works. Finally, everything is merged together into a tagged
release. The mach-shmobile changes can happen anytime after that
(part D). Again we're left with dead code in the clk driver (part
E) until the dependency merges, but that's ok. Once part D merges
we can get rid of the dead code in part E and any backwards
compatibility we don't want to maintain.
In summary, it's all feasible to do this and most people wouldn't
have had to know about the dependency chain but it's not fast by
any means. Instead we merge everything in one shot and get it
over with now.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [RFC PATCH v2 4/8] arm64: compat: Add a 32-bit vDSO
From: Catalin Marinas @ 2016-11-04 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22ae46f6-f881-63ec-388d-8a7f6cf9934d@arm.com>
On Fri, Oct 28, 2016 at 11:20:07AM +0100, Kevin Brodsky wrote:
> On 28/10/16 04:09, Jisheng Zhang wrote:
> > On Thu, 27 Oct 2016 17:30:54 +0100 Kevin Brodsky wrote:
> > > Provide the files necessary for building a compat (AArch32) vDSO in
> > > kernel/vdso32.
> > >
> > > This is mostly an adaptation of the arm vDSO. The most significant
> > > change in vgettimeofday.c is the use of the arm64 vdso_data struct,
> > > allowing the vDSO data page to be shared between the 32 and 64-bit
> > > vDSOs.
> > >
> > > In addition to the time functions, sigreturn trampolines are also
> > > provided, aiming at replacing those in the vector page. To improve
> > > debugging, CFI and unwinding directives are used, based on glibc's
> > > implementation. Symbol offsets are made available to the kernel using
> > > the same method as the 64-bit vDSO.
> > >
> > > There is unfortunately an important caveat to all this: we cannot get
> > > away with hand-coding 32-bit instructions like in kernel/kuser32.S,
> > > this time we really need a 32-bit compiler. The compat vDSO Makefile
> > > relies on CROSS_COMPILE_ARM32 to provide a 32-bit compiler,
> > > appropriate logic will be added to the arm64 Makefile later on to
> > > ensure that an attempt to build the compat vDSO is made only if this
> > > variable has been set properly.
> > >
> > > Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> > > ---
> > > arch/arm64/kernel/vdso32/Makefile | 121 +++++++++++++
> > > arch/arm64/kernel/vdso32/sigreturn.S | 86 +++++++++
> > > arch/arm64/kernel/vdso32/vdso.S | 32 ++++
> > > arch/arm64/kernel/vdso32/vdso.lds.S | 98 +++++++++++
> > > arch/arm64/kernel/vdso32/vgettimeofday.c | 294 +++++++++++++++++++++++++++++++
> > > 5 files changed, 631 insertions(+)
> > > create mode 100644 arch/arm64/kernel/vdso32/Makefile
> > > create mode 100644 arch/arm64/kernel/vdso32/sigreturn.S
> > > create mode 100644 arch/arm64/kernel/vdso32/vdso.S
> > > create mode 100644 arch/arm64/kernel/vdso32/vdso.lds.S
> > > create mode 100644 arch/arm64/kernel/vdso32/vgettimeofday.c
> > >
> > > diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
> > > new file mode 100644
> > > index 000000000000..38facc870f6e
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/vdso32/Makefile
> > > @@ -0,0 +1,121 @@
> > > +#
> > > +# Building a vDSO image for AArch32.
> > > +#
> > > +# Author: Kevin Brodsky <kevin.brodsky@arm.com>
> > > +# A mix between the arm64 and arm vDSO Makefiles.
> > > +
> > > +CC_ARM32 := $(CROSS_COMPILE_ARM32)gcc
> > > +
> > > +# Same as cc-ldoption, but using CC_ARM32 instead of CC
> > > +cc32-ldoption = $(call try-run,\
> > > + $(CC_ARM32) $(1) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
> > > +
> > > +# Borrow vdsomunge.c from the arm vDSO
> > > +munge := arch/arm/vdso/vdsomunge
> > > +hostprogs-y := $(srctree)/$(munge)
> > > +
> > > +c-obj-vdso := vgettimeofday.o
> > > +asm-obj-vdso := sigreturn.o
> > > +
> > > +# Build rules
> > > +targets := $(c-obj-vdso) $(asm-obj-vdso) vdso.so vdso.so.dbg vdso.so.raw
> > > +c-obj-vdso := $(addprefix $(obj)/, $(c-obj-vdso))
> > > +asm-obj-vdso := $(addprefix $(obj)/, $(asm-obj-vdso))
> > > +obj-vdso := $(c-obj-vdso) $(asm-obj-vdso)
> > > +
> > > +ccflags-y := -fPIC -fno-common -fno-builtin -fno-stack-protector
> > > +ccflags-y += -DDISABLE_BRANCH_PROFILING
> > > +
> > > +# Force -O2 to avoid libgcc dependencies
> > > +VDSO_CFLAGS := -march=armv8-a -O2
> > For completeness, bringing 32bit compiler need to check whether the 32bit
> > toolchain support some options. IIRC, armv8-a support isn't enabled until
> > gcc 4.8, so old toolchains such gcc-4.7 will complain:
> > error: unrecognized argument in option ?-march=armv8-a?
>
> That's a fair point. I guess -march=armv8-a is not strictly necessary and
> the produced vDSO should be fine if arch/arm/vdso also compiles fine.
> However we would still need to pass -march=armv7-a. I'm not sure what to do
> between:
> * Checking that the compiler supports -march=armv8-a when inspecting
> CROSS_COMPILE_ARM32, and if it doesn't vdso32 will not be built.
> * Checking whether -march=armv8-a is available here, and if it is not fall
> back to -march=armv7-a.
Does v8 vs v7 make any difference in the generated code? If not, we
could just stick to armv7-a permanently.
--
Catalin
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Pavel Machek @ 2016-11-04 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104145855.GH21430@atomide.com>
On Fri 2016-11-04 07:58:55, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [161104 00:10]:
> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
> > Do you actually have hardware with more than one bq27xxx?
>
> I can at least see the twl4030 battery/charger features
> being used together with some bq device to monitor the
> battery state. Not sure if that counts as multiple
> instances here though :)
I have that, too, but that was not what i was asking.
Matt wanted support for different polling intervals on different
bq27xxx chips. I'd like to know know if he actually has more than one
bq27xxx in his device...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161104/37ee45ee/attachment.sig>
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Matt Ranostay @ 2016-11-04 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104202924.GA6841@amd>
On Fri, Nov 4, 2016 at 1:29 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Fri 2016-11-04 07:58:55, Tony Lindgren wrote:
>> * Pavel Machek <pavel@ucw.cz> [161104 00:10]:
>> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
>> > Do you actually have hardware with more than one bq27xxx?
>>
>> I can at least see the twl4030 battery/charger features
>> being used together with some bq device to monitor the
>> battery state. Not sure if that counts as multiple
>> instances here though :)
>
> I have that, too, but that was not what i was asking.
>
> Matt wanted support for different polling intervals on different
> bq27xxx chips. I'd like to know know if he actually has more than one
> bq27xxx in his device...
>
Actually only one bq27xxx chip but in theory we could have more.
> Best regards,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Applied "ASoC: sun4i-codec: Add support for A31 board level audio routing" to the asoc tree
From: Mark Brown @ 2016-11-04 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-12-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A31 board level audio routing
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 300a18d13f7eaec789e79dc45bce026e098b45da Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Thu, 3 Nov 2016 15:55:53 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 board level audio
routing
The A31 SoC's codec has various inputs, outputs and microphone bias
supplies. These can be routed on the board in different ways, such as:
- HPCOM may be connected to have the headphone DC coupled.
- Microphones all use the MBIAS main microphone supply or one mic may
use the HBIAS supply, which supports headset detection and buttons.
- Line Out may be routed to an audio jack, or an onboard speaker amp
with power controls.
Add support for specifying the audio routes in the device tree.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/sun4i-codec.txt | 33 ++++++++++++++++++++++
sound/soc/sunxi/sun4i-codec.c | 21 ++++++++++++--
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index bf480e9683a3..d91a95377f49 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -22,6 +22,31 @@ Optional properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
- resets: phandle to the reset control for this device
+- allwinner,audio-routing: A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the
+ connection's sink, the second being the connection's
+ source. Valid names include:
+
+ Audio pins on the SoC:
+ "HP"
+ "HPCOM"
+ "LINEIN"
+ "LINEOUT"
+ "MIC1"
+ "MIC2"
+ "MIC3"
+
+ Microphone biases from the SoC:
+ "HBIAS"
+ "MBIAS"
+
+ Board connectors:
+ "Headphone"
+ "Headset Mic"
+ "Line In"
+ "Line Out"
+ "Mic"
+ "Speaker"
Example:
codec: codec at 01c22c00 {
@@ -45,4 +70,12 @@ codec: codec at 01c22c00 {
resets = <&ccu RST_APB1_CODEC>;
dmas = <&dma 15>, <&dma 15>;
dma-names = "rx", "tx";
+ allwinner,audio-routing =
+ "Headphone", "HP",
+ "Speaker", "LINEOUT",
+ "LINEIN", "Line In",
+ "MIC1", "MBIAS",
+ "MIC1", "Mic",
+ "MIC2", "HBIAS",
+ "MIC2", "Headset Mic";
};
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index f55718fe7c5b..1934db29b2b5 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -1104,9 +1104,19 @@ static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
return card;
};
+static const struct snd_soc_dapm_widget sun6i_codec_card_dapm_widgets[] = {
+ SND_SOC_DAPM_HP("Headphone", NULL),
+ SND_SOC_DAPM_LINE("Line In", NULL),
+ SND_SOC_DAPM_LINE("Line Out", NULL),
+ SND_SOC_DAPM_MIC("Headset Mic", NULL),
+ SND_SOC_DAPM_MIC("Mic", NULL),
+ SND_SOC_DAPM_SPK("Speaker", sun4i_codec_spk_event),
+};
+
static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
{
struct snd_soc_card *card;
+ int ret;
card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
if (!card)
@@ -1116,8 +1126,15 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
if (!card->dai_link)
return ERR_PTR(-ENOMEM);
- card->dev = dev;
- card->name = "A31 Audio Codec";
+ card->dev = dev;
+ card->name = "A31 Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->fully_routed = true;
+
+ ret = snd_soc_of_parse_audio_routing(card, "allwinner,audio-routing");
+ if (ret)
+ dev_warn(dev, "failed to parse audio-routing: %d\n", ret);
return card;
};
--
2.10.1
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for A31 analog microphone inputs" to the asoc tree
From: Mark Brown @ 2016-11-04 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-10-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A31 analog microphone inputs
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From ecd5cdb4fd818b1cec55863d5de3683dad1c2f53 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Thu, 3 Nov 2016 15:55:51 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 analog microphone
inputs
The A31 internal codec has 3 microphone outputs, of which MIC2 and MIC3
are muxed internally. The resulting two microphone inputs have separate
gain controls and mixer inputs.
The codec also has 2 microphone bias pins. HBIAS is specifically for the
headphone jack, which also supports headphone detection and control
buttons. These extra functions are not supported yet. The other, MBIAS,
is for all other analog microphones.
There is also mention of digital microphone support, but documentation
is scarce, and no hardware with it is available.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 70 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index a10251f4932e..f55718fe7c5b 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -776,6 +776,14 @@ static const struct snd_kcontrol_new sun6i_codec_mixer_controls[] = {
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_LMIX_LINEINL,
SUN6I_CODEC_OM_DACA_CTRL_RMIX_LINEINR, 1, 0),
+ SOC_DAPM_DOUBLE("Mic1 Playback Switch",
+ SUN6I_CODEC_OM_DACA_CTRL,
+ SUN6I_CODEC_OM_DACA_CTRL_LMIX_MIC1,
+ SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC1, 1, 0),
+ SOC_DAPM_DOUBLE("Mic2 Playback Switch",
+ SUN6I_CODEC_OM_DACA_CTRL,
+ SUN6I_CODEC_OM_DACA_CTRL_LMIX_MIC2,
+ SUN6I_CODEC_OM_DACA_CTRL_RMIX_MIC2, 1, 0),
};
/* headphone controls */
@@ -794,6 +802,21 @@ static const struct snd_kcontrol_new sun6i_codec_hp_src[] = {
sun6i_codec_hp_src_enum),
};
+/* microphone controls */
+static const char * const sun6i_codec_mic2_src_enum_text[] = {
+ "Mic2", "Mic3",
+};
+
+static SOC_ENUM_SINGLE_DECL(sun6i_codec_mic2_src_enum,
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2SLT,
+ sun6i_codec_mic2_src_enum_text);
+
+static const struct snd_kcontrol_new sun6i_codec_mic2_src[] = {
+ SOC_DAPM_ENUM("Mic2 Amplifier Source Route",
+ sun6i_codec_mic2_src_enum),
+};
+
/* line out controls */
static const char * const sun6i_codec_lineout_src_enum_text[] = {
"Stereo", "Mono Differential",
@@ -819,6 +842,10 @@ static const DECLARE_TLV_DB_RANGE(sun6i_codec_lineout_vol_scale,
0, 1, TLV_DB_SCALE_ITEM(TLV_DB_GAIN_MUTE, 0, 1),
2, 31, TLV_DB_SCALE_ITEM(-4350, 150, 0),
);
+static const DECLARE_TLV_DB_RANGE(sun6i_codec_mic_gain_scale,
+ 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
+ 1, 7, TLV_DB_SCALE_ITEM(2400, 300, 0),
+);
static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("DAC Playback Volume", SUN4I_CODEC_DAC_DPC,
@@ -844,9 +871,42 @@ static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("Line In Playback Volume",
SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_LINEING,
0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+ SOC_SINGLE_TLV("Mic1 Playback Volume",
+ SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_MIC1G,
+ 0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+ SOC_SINGLE_TLV("Mic2 Playback Volume",
+ SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_MIC2G,
+ 0x7, 0, sun6i_codec_out_mixer_pregain_scale),
+
+ /* Microphone Amp boost gains */
+ SOC_SINGLE_TLV("Mic1 Boost Volume", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC1BOOST, 0x7, 0,
+ sun6i_codec_mic_gain_scale),
+ SOC_SINGLE_TLV("Mic2 Boost Volume", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2BOOST, 0x7, 0,
+ sun6i_codec_mic_gain_scale),
};
static const struct snd_soc_dapm_widget sun6i_codec_codec_dapm_widgets[] = {
+ /* Microphone inputs */
+ SND_SOC_DAPM_INPUT("MIC1"),
+ SND_SOC_DAPM_INPUT("MIC2"),
+ SND_SOC_DAPM_INPUT("MIC3"),
+
+ /* Microphone Bias */
+ SND_SOC_DAPM_SUPPLY("HBIAS", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_HBIASEN, 0, NULL, 0),
+ SND_SOC_DAPM_SUPPLY("MBIAS", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MBIASEN, 0, NULL, 0),
+
+ /* Mic input path */
+ SND_SOC_DAPM_MUX("Mic2 Amplifier Source Route",
+ SND_SOC_NOPM, 0, 0, sun6i_codec_mic2_src),
+ SND_SOC_DAPM_PGA("Mic1 Amplifier", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC1AMPEN, 0, NULL, 0),
+ SND_SOC_DAPM_PGA("Mic2 Amplifier", SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_MIC2AMPEN, 0, NULL, 0),
+
/* Line In */
SND_SOC_DAPM_INPUT("LINEIN"),
@@ -893,15 +953,25 @@ static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
{ "Left DAC", NULL, "DAC Enable" },
{ "Right DAC", NULL, "DAC Enable" },
+ /* Microphone Routes */
+ { "Mic1 Amplifier", NULL, "MIC1"},
+ { "Mic2 Amplifier Source Route", "Mic2", "MIC2" },
+ { "Mic2 Amplifier Source Route", "Mic3", "MIC3" },
+ { "Mic2 Amplifier", NULL, "Mic2 Amplifier Source Route"},
+
/* Left Mixer Routes */
{ "Left Mixer", "DAC Playback Switch", "Left DAC" },
{ "Left Mixer", "DAC Reversed Playback Switch", "Right DAC" },
{ "Left Mixer", "Line In Playback Switch", "LINEIN" },
+ { "Left Mixer", "Mic1 Playback Switch", "Mic1 Amplifier" },
+ { "Left Mixer", "Mic2 Playback Switch", "Mic2 Amplifier" },
/* Right Mixer Routes */
{ "Right Mixer", "DAC Playback Switch", "Right DAC" },
{ "Right Mixer", "DAC Reversed Playback Switch", "Left DAC" },
{ "Right Mixer", "Line In Playback Switch", "LINEIN" },
+ { "Right Mixer", "Mic1 Playback Switch", "Mic1 Amplifier" },
+ { "Right Mixer", "Mic2 Playback Switch", "Mic2 Amplifier" },
/* Headphone Routes */
{ "Headphone Source Playback Route", "DAC", "Left DAC" },
--
2.10.1
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for A31 Line Out playback" to the asoc tree
From: Mark Brown @ 2016-11-04 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-9-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A31 Line Out playback
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 0f909f98d7cbabc3641a45da9c6891444b929a92 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Thu, 3 Nov 2016 15:55:50 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A31 Line Out playback
The A31 integrated codec has a second "Line Out" output which does not
include an integrated amplifier in its path. This path does have a
separate volume control.
This patch adds support for the playback path from the DAC to the Line
Out pins.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 39 +++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 72a84f76aa57..a10251f4932e 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -794,11 +794,31 @@ static const struct snd_kcontrol_new sun6i_codec_hp_src[] = {
sun6i_codec_hp_src_enum),
};
+/* line out controls */
+static const char * const sun6i_codec_lineout_src_enum_text[] = {
+ "Stereo", "Mono Differential",
+};
+
+static SOC_ENUM_DOUBLE_DECL(sun6i_codec_lineout_src_enum,
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTLSRC,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTRSRC,
+ sun6i_codec_lineout_src_enum_text);
+
+static const struct snd_kcontrol_new sun6i_codec_lineout_src[] = {
+ SOC_DAPM_ENUM("Line Out Source Playback Route",
+ sun6i_codec_lineout_src_enum),
+};
+
/* volume / mute controls */
static const DECLARE_TLV_DB_SCALE(sun6i_codec_dvol_scale, -7308, 116, 0);
static const DECLARE_TLV_DB_SCALE(sun6i_codec_hp_vol_scale, -6300, 100, 1);
static const DECLARE_TLV_DB_SCALE(sun6i_codec_out_mixer_pregain_scale,
-450, 150, 0);
+static const DECLARE_TLV_DB_RANGE(sun6i_codec_lineout_vol_scale,
+ 0, 1, TLV_DB_SCALE_ITEM(TLV_DB_GAIN_MUTE, 0, 1),
+ 2, 31, TLV_DB_SCALE_ITEM(-4350, 150, 0),
+);
static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SOC_SINGLE_TLV("DAC Playback Volume", SUN4I_CODEC_DAC_DPC,
@@ -808,10 +828,18 @@ static const struct snd_kcontrol_new sun6i_codec_codec_widgets[] = {
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_HPVOL, 0x3f, 0,
sun6i_codec_hp_vol_scale),
+ SOC_SINGLE_TLV("Line Out Playback Volume",
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTVC, 0x1f, 0,
+ sun6i_codec_lineout_vol_scale),
SOC_DOUBLE("Headphone Playback Switch",
SUN6I_CODEC_OM_DACA_CTRL,
SUN6I_CODEC_OM_DACA_CTRL_LHPPAMUTE,
SUN6I_CODEC_OM_DACA_CTRL_RHPPAMUTE, 1, 0),
+ SOC_DOUBLE("Line Out Playback Switch",
+ SUN6I_CODEC_MIC_CTRL,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTLEN,
+ SUN6I_CODEC_MIC_CTRL_LINEOUTREN, 1, 0),
/* Mixer pre-gains */
SOC_SINGLE_TLV("Line In Playback Volume",
SUN6I_CODEC_OM_PA_CTRL, SUN6I_CODEC_OM_PA_CTRL_LINEING,
@@ -853,6 +881,11 @@ static const struct snd_soc_dapm_widget sun6i_codec_codec_dapm_widgets[] = {
SND_SOC_DAPM_REG(snd_soc_dapm_supply, "HPCOM", SUN6I_CODEC_OM_PA_CTRL,
SUN6I_CODEC_OM_PA_CTRL_HPCOM_CTL, 0x3, 0x3, 0),
SND_SOC_DAPM_OUTPUT("HP"),
+
+ /* Line Out path */
+ SND_SOC_DAPM_MUX("Line Out Source Playback Route",
+ SND_SOC_NOPM, 0, 0, sun6i_codec_lineout_src),
+ SND_SOC_DAPM_OUTPUT("LINEOUT"),
};
static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
@@ -878,6 +911,12 @@ static const struct snd_soc_dapm_route sun6i_codec_codec_dapm_routes[] = {
{ "Headphone Amp", NULL, "Headphone Source Playback Route" },
{ "HP", NULL, "Headphone Amp" },
{ "HPCOM", NULL, "HPCOM Protection" },
+
+ /* Line Out Routes */
+ { "Line Out Source Playback Route", "Stereo", "Left Mixer" },
+ { "Line Out Source Playback Route", "Stereo", "Right Mixer" },
+ { "Line Out Source Playback Route", "Mono Differential", "Left Mixer" },
+ { "LINEOUT", NULL, "Line Out Source Playback Route" },
};
static struct snd_soc_codec_driver sun6i_codec_codec = {
--
2.10.1
^ permalink raw reply related
* [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Kevin Hilman @ 2016-11-04 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-2-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v2 2/5] ARM: bus: da8xx-mstpri: new driver
From: Kevin Hilman @ 2016-11-04 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477925138-23457-3-git-send-email-bgolaszewski@baylibre.com>
Bartosz Golaszewski <bgolaszewski@baylibre.com> writes:
> Create the driver for the da8xx master peripheral priority
> configuration and implement support for writing to the three
> Master Priority registers on da850 SoCs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add imx-weim parameters to dtsi's
From: Fabio Estevam @ 2016-11-04 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478044305-5666-1-git-send-email-stillcompiling@gmail.com>
On Tue, Nov 1, 2016 at 9:51 PM, Joshua Clayton <stillcompiling@gmail.com> wrote:
> imx-weim should always set address-cells to 2,
> and size_cells to 1.
> On imx6, fsl,weim-cs-gpr will always be &gpr
>
> Set these common parameters in the dtsi file,
> rather than in a downstream dts.
>
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: imx28: Fix build warnings with W=1
From: Fabio Estevam @ 2016-11-04 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908140338.GD16911@tiger>
Hi Shawn,
On Thu, Sep 8, 2016 at 11:03 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> On Mon, Sep 05, 2016 at 04:27:50PM -0300, Fabio Estevam wrote:
>> diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
>> index 0ebbc83..b4d4dbb 100644
>> --- a/arch/arm/boot/dts/imx28-tx28.dts
>> +++ b/arch/arm/boot/dts/imx28-tx28.dts
>> @@ -35,7 +35,8 @@
>> usbotg = &usb0;
>> };
>>
>> - memory {
>> + memory at 0 {
>> + device_type = "memory";
>> reg = <0 0>; /* will be filled in by U-Boot */
>
> I'm curious to know if the unit-address will be fixed up or not when
> 'reg' property gets updated by U-Boot.
Should I resend this series and keep imx28-tx28.dts unmodified?
^ permalink raw reply
* [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Stephen Boyd @ 2016-11-04 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025011632.GA23876@b29397-desktop>
Quoting Peter Chen (2016-10-24 18:16:32)
> On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
> > Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
> > > Hi,
> > >
> > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > > > The ULPI bus can be built as a module, and it will soon be
> > > > calling these functions when it supports probing devices from DT.
> > > > Export them so they can be used by the ULPI module.
> > > >
> > > > Acked-by: Rob Herring <robh@kernel.org>
> > > > Cc: <devicetree@vger.kernel.org>
> > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > > ---
> > > > drivers/of/device.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > > > index 8a22a253a830..6719ab35b62e 100644
> > > > --- a/drivers/of/device.c
> > > > +++ b/drivers/of/device.c
> > > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
> > > >
> > > > return tsize;
> > > > }
> > > > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
> > > >
> > > > int of_device_request_module(struct device *dev)
> > > > {
> > > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> > > > }
> > > > mutex_unlock(&of_mutex);
> > > > }
> > > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
> > >
> > > This is trailing the wrong function.
> > >
> >
> > Good catch. Must have been some bad rebase.
> >
> > Peter, can you fix it while applying or should I resend this patch?
> >
>
> But, this is device tree patch. I can only get chipidea part and other
> USB patches if Greg agrees.
>
Were you expecting Rob to take the drivers/of/* patches? Sorry I thought
Rob acked them so they could go through usb with the other changes.
^ permalink raw reply
* Low network throughput on i.MX28
From: Jörg Krause @ 2016-11-04 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1783642995.185945.5e54a2af-ba2c-4901-93f6-1967dd432939.open-xchange@email.1und1.de>
On Fri, 2016-11-04 at 20:30 +0100, Stefan Wahren wrote:
> Hi J?rg,
>
> > J?rg Krause <joerg.krause@embedded.rocks> hat am 4. November 2016
> > um 19:44
> > geschrieben:
> >
> >
> > Hi Shawn,
> >
> > On Wed, 2016-11-02 at 09:24 +0100, Stefan Wahren wrote:
> > > Am 02.11.2016 um 09:14 schrieb J?rg Krause:
> > > > On Sat, 2016-10-29 at 11:08 +0200, Stefan Wahren wrote:
> > > > > > J?rg Krause <joerg.krause@embedded.rocks> hat am 29.
> > > > > > Oktober
> > > > > > 2016
> > > > > > um 01:07
> > > > > > geschrieben:
> > > > > >
> > > > > >
> > > > > > You mentioned [1] an optimization in the Freescale vendor
> > > > > > Linux
> > > > > > kernel
> > > > > > [2]. I would really like to see this optimization in the
> > > > > > mainline
> > > > > > kernel.
> > > > > >
> > > > > > Did you ever tried to port this code from Freescale to
> > > > > > mainline?
> > > > >
> > > > > Yes, i tried once but i was frustrated soon because of the
> > > > > lot of
> > > > > required
> > > > > changes and resulting issues.
> > > >
> > > > I got the PIO mode working for the mxs-mmc driver. For this I
> > > > ported
> > > > the PIO code from the vendor kernel and removed the usage of
> > > > the
> > > > DMA
> > > > engine entirely.
> > >
> > > Good job
> > >
> > > >
> > > > Testing network bandwidth with iperf, I get about ~10Mbit/sec
> > > > with
> > > > PIO
> > > > mode compared to ~6.5Mbit/sec with DMA mode for UDP and about
> > > > ~6.5Mbit/sec compared to ~4.5Mbit/sec with DMA mode for TCP.
> > >
> > > And how about MMC / sd card performance?
> >
> > I noticed poor performance with the i.MX28 MMC and/or DMA driver
> > using
> > the mainline kernel compared to the vendor Freescale kernel 2.6.35.
> > I've seen that hou have added the drivers to mainline some years
> > ago.
> >
> > My custom i.MX28 board has a wifi chip attached to the SSP2
> > interface.
> > Comparing the bandwith with iperf I get >20Mbits/sec on the vendor
> > kernel and <5Mbits/sec on the mainline kernel.
>
> there is one thing about the clock handling. I noticed that the
> Vendor Kernel
> round up the clock frequency and the Mainline Kernel round down the
> clock
> frequency [1]. So don't trust the clock ratings from DT / board code.
> Better
> verify the register settings or check it with an osci.
>
> [1] - http://www.spinics.net/lists/linux-mmc/msg09132.html
I checked the clock rate setting by reading the register 0x80014070
(HW_SSP2_TIMING). CLOCK_DIVIDE is 0x2 and CLOCK_RATE is 0x0. As SSP CLK
is 96MHz this makes a clock rate of 48MHz.
There was a discussion on the mailing list [1] about that tasklets
might be slow.
J?rg
^ permalink raw reply
* [PATCH 2/3] phy: da8xx-usb: rename the ohci device to ohci-da8xx
From: Kishon Vijay Abraham I @ 2016-11-04 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2c3b66c5-b148-252e-36a0-e067bb60191e@ti.com>
On Friday 04 November 2016 11:04 AM, Sekhar Nori wrote:
> Hi Kishon,
>
> On Thursday 03 November 2016 10:20 PM, Kishon Vijay Abraham I wrote:
>>
>>
>> On Wednesday 02 November 2016 06:14 PM, Axel Haslam wrote:
>>> There is only one ohci on the da8xx series of chips,
>>> so remove the ".0" when creating the phy. Also add
>>> the "-da8xx" postfix to be consistent across davinci
>>> usb drivers.
>>>
>>> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
>>
>> Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> You will have to carry this patch from your tree. I thought I can carry
> the entire series, but the USB patch depends on other patches that Greg
> has already queued. So I think its best if the individual patches go
> through their respective trees.
>
> Note that there is a v2 already submitted.
Okay. I can pick them in my tree.
Thanks
Kishon
^ permalink raw reply
* [PATCH v2 0/11] Add R8A7745/SK-RZG1E board support
From: Sergei Shtylyov @ 2016-11-04 21:42 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
Here's the set of 11 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-201611104-v4.9-rc3' tag plus the R8A7743/SK-RZG1M patch series
posted earlier. I'm adding the device tree support for the R8A7745-based
SK-RZG1E board. The SoC is close to R8A7794 and the board seems identical to the
R8A7794/SILK board. The device tree patches depend on the R8A7745 CPG/MSSR
driver series in order to compile and work.
[01/11] ARM: shmobile: r8a7745: add power domain index macros
[02/11] soc: renesas: rcar-sysc: add R8A7745 support
[03/11] ARM: shmobile: r8a7745: basic SoC support
[04/11] ARM: dts: r8a7745: initial SoC device tree
[05/11] ARM: dts: r8a7745: add SYS-DMAC support
[06/11] ARM: dts: r8a7745: add [H]SCIF{|A|B} support
[07/11] ARM: dts: r8a7745: add Ether support
[08/11] ARM: dts: r8a7745: add IRQC support
[09/11] ARM: shmobile: document SK-RZG1E board
[10/11] ARM: dts: sk-rzg1e: initial device tree
[11/11] ARM: dts: sk-rzg1e: add Ether support
WBR, Sergei
^ permalink raw reply
* [PATCH v2 2/2] power: bq27xxx_battery: add poll interval property query
From: Pavel Machek @ 2016-11-04 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKzfze_FrerJF6JOjVJ2XdyJgPm9OkEziX+oVOr7Aix3N31anw@mail.gmail.com>
On Fri 2016-11-04 13:39:19, Matt Ranostay wrote:
> On Fri, Nov 4, 2016 at 1:29 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Fri 2016-11-04 07:58:55, Tony Lindgren wrote:
> >> * Pavel Machek <pavel@ucw.cz> [161104 00:10]:
> >> > On Thu 2016-11-03 22:00:56, Matt Ranostay wrote:
> >> > Do you actually have hardware with more than one bq27xxx?
> >>
> >> I can at least see the twl4030 battery/charger features
> >> being used together with some bq device to monitor the
> >> battery state. Not sure if that counts as multiple
> >> instances here though :)
> >
> > I have that, too, but that was not what i was asking.
> >
> > Matt wanted support for different polling intervals on different
> > bq27xxx chips. I'd like to know know if he actually has more than one
> > bq27xxx in his device...
> >
>
> Actually only one bq27xxx chip but in theory we could have more.
Hmm. As we'd have to keep both old and new interfaces to change the
polling interfaces. Lets not due that unless we really need to, ok?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161104/f89a025b/attachment.sig>
^ permalink raw reply
* [PATCH v2 03/11] ARM: shmobile: r8a7745: basic SoC support
From: Sergei Shtylyov @ 2016-11-04 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2368353.xfo5beGC5E@wasted.cogentembedded.com>
Add minimal support for the RZ/G1E (R8A7745) SoC.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 2:
- added Geert's tag;
- refreshed the patch.
Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
arch/arm/mach-shmobile/Kconfig | 4 ++++
arch/arm/mach-shmobile/setup-rcar-gen2.c | 1 +
3 files changed, 7 insertions(+)
Index: renesas/Documentation/devicetree/bindings/arm/shmobile.txt
===================================================================
--- renesas.orig/Documentation/devicetree/bindings/arm/shmobile.txt
+++ renesas/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -15,6 +15,8 @@ SoCs:
compatible = "renesas,r8a7740"
- RZ/G1M (R8A77430)
compatible = "renesas,r8a7743"
+ - RZ/G1E (R8A77450)
+ compatible = "renesas,r8a7745"
- R-Car M1A (R8A77781)
compatible = "renesas,r8a7778"
- R-Car H1 (R8A77790)
Index: renesas/arch/arm/mach-shmobile/Kconfig
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/Kconfig
+++ renesas/arch/arm/mach-shmobile/Kconfig
@@ -73,6 +73,10 @@ config ARCH_R8A7743
select ARCH_RCAR_GEN2
select ARM_ERRATA_798181 if SMP
+config ARCH_R8A7745
+ bool "RZ/G1E (R8A77450)"
+ select ARCH_RCAR_GEN2
+
config ARCH_R8A7778
bool "R-Car M1A (R8A77781)"
select ARCH_RCAR_GEN1
Index: renesas/arch/arm/mach-shmobile/setup-rcar-gen2.c
===================================================================
--- renesas.orig/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ renesas/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -227,6 +227,7 @@ MACHINE_END
static const char * const rz_g1_boards_compat_dt[] __initconst = {
"renesas,r8a7743",
+ "renesas,r8a7745",
NULL,
};
^ permalink raw reply
* [PATCH v2 04/11] ARM: dts: r8a7745: initial SoC device tree
From: Sergei Shtylyov @ 2016-11-04 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2368353.xfo5beGC5E@wasted.cogentembedded.com>
The initial R8A7745 SoC device tree including CPU0, GIC, timer, SYSC, RST,
CPG, and the required clock descriptions.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 2:
- reformatted the "interrupts" props of the GIC/timer device nodes;
- added Geert's tag.
arch/arm/boot/dts/r8a7745.dtsi | 120 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 120 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7745.dtsi
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7745.dtsi
@@ -0,0 +1,120 @@
+/*
+ * Device Tree Source for the r8a7745 SoC
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/r8a7745-cpg-mssr.h>
+#include <dt-bindings/power/r8a7745-sysc.h>
+
+/ {
+ compatible = "renesas,r8a7745";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu at 0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0>;
+ clock-frequency = <1000000000>;
+ clocks = <&cpg CPG_CORE R8A7745_CLK_Z2>;
+ power-domains = <&sysc R8A7745_PD_CA7_CPU0>;
+ next-level-cache = <&L2_CA7>;
+ };
+
+ L2_CA7: cache-controller at 0 {
+ compatible = "cache";
+ reg = <0>;
+ cache-unified;
+ cache-level = <2>;
+ power-domains = <&sysc R8A7745_PD_CA7_SCU>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller at f1001000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0 0xf1001000 0 0x1000>,
+ <0 0xf1002000 0 0x1000>,
+ <0 0xf1004000 0 0x2000>,
+ <0 0xf1006000 0 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ cpg: clock-controller at e6150000 {
+ compatible = "renesas,r8a7745-cpg-mssr";
+ reg = <0 0xe6150000 0 0x1000>;
+ clocks = <&extal_clk>, <&usb_extal_clk>;
+ clock-names = "extal", "usb_extal";
+ #clock-cells = <2>;
+ #power-domain-cells = <0>;
+ };
+
+ sysc: system-controller at e6180000 {
+ compatible = "renesas,r8a7745-sysc";
+ reg = <0 0xe6180000 0 0x200>;
+ #power-domain-cells = <1>;
+ };
+
+ rst: reset-controller at e6160000 {
+ compatible = "renesas,r8a7745-rst";
+ reg = <0 0xe6160000 0 0x100>;
+ };
+ };
+
+ /* External root clock */
+ extal_clk: extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+
+ /* External USB clock - can be overridden by the board */
+ usb_extal_clk: usb_extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <48000000>;
+ };
+
+ /* External SCIF clock */
+ scif_clk: scif {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+};
^ permalink raw reply
* [PATCH v2 05/11] ARM: dts: r8a7745: add SYS-DMAC support
From: Sergei Shtylyov @ 2016-11-04 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2368353.xfo5beGC5E@wasted.cogentembedded.com>
Describe SYS-DMAC0/1 in the R8A7745 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 2:
- added Geert's tag;
- refreshed the patch.
arch/arm/boot/dts/r8a7745.dtsi | 64 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7745.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7745.dtsi
+++ renesas/arch/arm/boot/dts/r8a7745.dtsi
@@ -93,6 +93,70 @@
compatible = "renesas,r8a7745-rst";
reg = <0 0xe6160000 0 0x0200>;
};
+
+ dmac0: dma-controller at e6700000 {
+ compatible = "renesas,dmac-r8a7745",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6700000 0 0x20000>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 219>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
+ dmac1: dma-controller at e6720000 {
+ compatible = "renesas,dmac-r8a7745",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6720000 0 0x20000>;
+ interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 218>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
};
/* External root clock */
^ permalink raw reply
* [PATCH v2 06/11] ARM: dts: r8a7745: add [H]SCIF{|A|B} support
From: Sergei Shtylyov @ 2016-11-04 21:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2368353.xfo5beGC5E@wasted.cogentembedded.com>
Describe [H]SCIF{|A|B} ports in the R8A7745 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 2:
- used the R-Car gen2 bindings instead of the RZ/G family ones;
- added Geert's tag.
arch/arm/boot/dts/r8a7745.dtsi | 261 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 261 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7745.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7745.dtsi
+++ renesas/arch/arm/boot/dts/r8a7745.dtsi
@@ -157,6 +157,267 @@
#dma-cells = <1>;
dma-channels = <15>;
};
+
+ scifa0: serial at e6c40000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c40000 0 0x40>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 204>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x21>, <&dmac0 0x22>,
+ <&dmac1 0x21>, <&dmac1 0x22>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa1: serial at e6c50000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c50000 0 0x40>;
+ interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 203>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x25>, <&dmac0 0x26>,
+ <&dmac1 0x25>, <&dmac1 0x26>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa2: serial at e6c60000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c60000 0 0x40>;
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 202>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x27>, <&dmac0 0x28>,
+ <&dmac1 0x27>, <&dmac1 0x28>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa3: serial at e6c70000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c70000 0 0x40>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1106>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1b>, <&dmac0 0x1c>,
+ <&dmac1 0x1b>, <&dmac1 0x1c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa4: serial at e6c78000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c78000 0 0x40>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1107>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1f>, <&dmac0 0x20>,
+ <&dmac1 0x1f>, <&dmac1 0x20>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifa5: serial at e6c80000 {
+ compatible = "renesas,scifa-r8a7745",
+ "renesas,rcar-gen2-scifa", "renesas,scifa";
+ reg = <0 0xe6c80000 0 0x40>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 1108>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x23>, <&dmac0 0x24>,
+ <&dmac1 0x23>, <&dmac1 0x24>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb0: serial at e6c20000 {
+ compatible = "renesas,scifb-r8a7745",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6c20000 0 0x100>;
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 206>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x3d>, <&dmac0 0x3e>,
+ <&dmac1 0x3d>, <&dmac1 0x3e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb1: serial at e6c30000 {
+ compatible = "renesas,scifb-r8a7745",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6c30000 0 0x100>;
+ interrupts = <GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 207>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x19>, <&dmac0 0x1a>,
+ <&dmac1 0x19>, <&dmac1 0x1a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scifb2: serial at e6ce0000 {
+ compatible = "renesas,scifb-r8a7745",
+ "renesas,rcar-gen2-scifb", "renesas,scifb";
+ reg = <0 0xe6ce0000 0 0x100>;
+ interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 216>;
+ clock-names = "fck";
+ dmas = <&dmac0 0x1d>, <&dmac0 0x1e>,
+ <&dmac1 0x1d>, <&dmac1 0x1e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif0: serial at e6e60000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e60000 0 0x40>;
+ interrupts = <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 721>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x29>, <&dmac0 0x2a>,
+ <&dmac1 0x29>, <&dmac1 0x2a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif1: serial at e6e68000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e68000 0 0x40>;
+ interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 720>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2d>, <&dmac0 0x2e>,
+ <&dmac1 0x2d>, <&dmac1 0x2e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif2: serial at e6e58000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6e58000 0 0x40>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 719>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2b>, <&dmac0 0x2c>,
+ <&dmac1 0x2b>, <&dmac1 0x2c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif3: serial at e6ea8000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ea8000 0 0x40>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 718>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x2f>, <&dmac0 0x30>,
+ <&dmac1 0x2f>, <&dmac1 0x30>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif4: serial at e6ee0000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ee0000 0 0x40>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 715>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0xfb>, <&dmac0 0xfc>,
+ <&dmac1 0xfb>, <&dmac1 0xfc>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ scif5: serial at e6ee8000 {
+ compatible = "renesas,scif-r8a7745",
+ "renesas,rcar-gen2-scif", "renesas,scif";
+ reg = <0 0xe6ee8000 0 0x40>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 714>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0xfd>, <&dmac0 0xfe>,
+ <&dmac1 0xfd>, <&dmac1 0xfe>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif0: serial at e62c0000 {
+ compatible = "renesas,hscif-r8a7745",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62c0000 0 0x60>;
+ interrupts = <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 717>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x39>, <&dmac0 0x3a>,
+ <&dmac1 0x39>, <&dmac1 0x3a>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif1: serial at e62c8000 {
+ compatible = "renesas,hscif-r8a7745",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62c8000 0 0x60>;
+ interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 716>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x4d>, <&dmac0 0x4e>,
+ <&dmac1 0x4d>, <&dmac1 0x4e>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
+
+ hscif2: serial at e62d0000 {
+ compatible = "renesas,hscif-r8a7745",
+ "renesas,rcar-gen2-hscif", "renesas,hscif";
+ reg = <0 0xe62d0000 0 0x60>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 713>,
+ <&cpg CPG_CORE R8A7745_CLK_ZS>, <&scif_clk>;
+ clock-names = "fck", "brg_int", "scif_clk";
+ dmas = <&dmac0 0x3b>, <&dmac0 0x3c>,
+ <&dmac1 0x3b>, <&dmac1 0x3c>;
+ dma-names = "tx", "rx", "tx", "rx";
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ status = "disabled";
+ };
};
/* External root clock */
^ permalink raw reply
* [PATCH v2 07/11] ARM: dts: r8a7745: add Ether support
From: Sergei Shtylyov @ 2016-11-04 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2368353.xfo5beGC5E@wasted.cogentembedded.com>
Define the generic R8A7745 part of the Ether device node.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin@cogentembedded.com>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 2:
- added Geert's tag.
arch/arm/boot/dts/r8a7745.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7745.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7745.dtsi
+++ renesas/arch/arm/boot/dts/r8a7745.dtsi
@@ -418,6 +418,18 @@
power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
status = "disabled";
};
+
+ ether: ethernet at ee700000 {
+ compatible = "renesas,ether-r8a7745";
+ reg = <0 0xee700000 0 0x400>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 813>;
+ power-domains = <&sysc R8A7745_PD_ALWAYS_ON>;
+ phy-mode = "rmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
/* External root clock */
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox