* [PATCH v6 2/8] KVM: arm/arm64: Factor out functionality to get vgic mmio requester_vcpu
From: Christoffer Dall @ 2017-12-04 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204200506.3224-1-cdall@kernel.org>
From: Christoffer Dall <christoffer.dall@linaro.org>
We are about to distinguish between userspace accesses and mmio traps
for a number of the mmio handlers. When the requester vcpu is NULL, it
mens we are handling a userspace acccess.
Factor out the functionality to get the request vcpu into its own
function, mostly so we have a common place to document the semantics of
the return value.
Also take the chance to move the functionality outside of holding a
spinlock and instead explicitly disable and enable preemption. This
supports PREEMPT_RT kernels as well.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/vgic/vgic-mmio.c | 44 +++++++++++++++++++++++++++----------------
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
index deb51ee16a3d..747b0a3b4784 100644
--- a/virt/kvm/arm/vgic/vgic-mmio.c
+++ b/virt/kvm/arm/vgic/vgic-mmio.c
@@ -122,6 +122,27 @@ unsigned long vgic_mmio_read_pending(struct kvm_vcpu *vcpu,
return value;
}
+/*
+ * This function will return the VCPU that performed the MMIO access and
+ * trapped from twithin the VM, and will return NULL if this is a userspace
+ * access.
+ *
+ * We can disable preemption locally around accessing the per-CPU variable,
+ * and use the resolved vcpu pointer after enabling preemption again, because
+ * even if the current thread is migrated to another CPU, reading the per-CPU
+ * value later will give us the same value as we update the per-CPU variable
+ * in the preempt notifier handlers.
+ */
+static struct kvm_vcpu *vgic_get_mmio_requester_vcpu(void)
+{
+ struct kvm_vcpu *vcpu;
+
+ preempt_disable();
+ vcpu = kvm_arm_get_running_vcpu();
+ preempt_enable();
+ return vcpu;
+}
+
void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,
gpa_t addr, unsigned int len,
unsigned long val)
@@ -184,24 +205,10 @@ unsigned long vgic_mmio_read_active(struct kvm_vcpu *vcpu,
static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
bool new_active_state)
{
- struct kvm_vcpu *requester_vcpu;
unsigned long flags;
- spin_lock_irqsave(&irq->irq_lock, flags);
+ struct kvm_vcpu *requester_vcpu = vgic_get_mmio_requester_vcpu();
- /*
- * The vcpu parameter here can mean multiple things depending on how
- * this function is called; when handling a trap from the kernel it
- * depends on the GIC version, and these functions are also called as
- * part of save/restore from userspace.
- *
- * Therefore, we have to figure out the requester in a reliable way.
- *
- * When accessing VGIC state from user space, the requester_vcpu is
- * NULL, which is fine, because we guarantee that no VCPUs are running
- * when accessing VGIC state from user space so irq->vcpu->cpu is
- * always -1.
- */
- requester_vcpu = kvm_arm_get_running_vcpu();
+ spin_lock_irqsave(&irq->irq_lock, flags);
/*
* If this virtual IRQ was written into a list register, we
@@ -213,6 +220,11 @@ static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
* vgic_change_active_prepare) and still has to sync back this IRQ,
* so we release and re-acquire the spin_lock to let the other thread
* sync back the IRQ.
+ *
+ * When accessing VGIC state from user space, requester_vcpu is
+ * NULL, which is fine, because we guarantee that no VCPUs are running
+ * when accessing VGIC state from user space so irq->vcpu->cpu is
+ * always -1.
*/
while (irq->vcpu && /* IRQ may have state in an LR somewhere */
irq->vcpu != requester_vcpu && /* Current thread is not the VCPU thread */
--
2.14.2
^ permalink raw reply related
* [PATCH v6 1/8] KVM: arm/arm64: Remove redundant preemptible checks
From: Christoffer Dall @ 2017-12-04 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204200506.3224-1-cdall@kernel.org>
From: Christoffer Dall <christoffer.dall@linaro.org>
The __this_cpu_read() and __this_cpu_write() functions already implement
checks for the required preemption levels when using
CONFIG_DEBUG_PREEMPT which gives you nice error messages and such.
Therefore there is no need to explicitly check this using a BUG_ON() in
the code (which we don't do for other uses of per cpu variables either).
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
---
virt/kvm/arm/arm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index a6524ff27de4..859ff7e3a1eb 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -71,7 +71,6 @@ static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
{
- BUG_ON(preemptible());
__this_cpu_write(kvm_arm_running_vcpu, vcpu);
}
@@ -81,7 +80,6 @@ static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
*/
struct kvm_vcpu *kvm_arm_get_running_vcpu(void)
{
- BUG_ON(preemptible());
return __this_cpu_read(kvm_arm_running_vcpu);
}
--
2.14.2
^ permalink raw reply related
* [PATCH v6 0/8] Handle forwarded level-triggered interrupts
From: Christoffer Dall @ 2017-12-04 20:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Christoffer Dall <christoffer.dall@linaro.org>
This series is an alternative approach to Eric Auger's direct EOI setup
patches [1] in terms of the KVM VGIC support.
The idea is to maintain existing semantics for the VGIC for mapped
level-triggered IRQs and also support the timer using mapped IRQs with
the same VGIC support as VFIO interrupts.
Based on v4.15-rc.
Also available at:
git://git.kernel.org/pub/scm/linux/kernel/git/cdall/linux.git level-mapped-v6
Changes since v5:
- Rebased on v4.15-rc1
- Changed comment on preemption code as suggested by Andre
- Fixed white space and confusing conditionals as suggested by Drew
Changes since v4:
- Rebased on the timer optimization series merged in the v4.15 merge
window, which caused a fair amount of modifications to patch 3.
- Added a static key to disable the sync operations when no VMs are
using userspace irqchips to further optimize the performance
- Fixed extra semicolon in vgic-mmio.c
- Added commentary as requested during review
- Dropped what was patch 4, because it was merged as part of GICv4
support.
- Factored out the VGIC input level function change as separate patch
(helps bisect and debugging), before providing a function for the
timer.
Changes since v3:
- Added a number of patches and moved patches around a bit.
- Check for uaccesses in the mmio handler functions
- Fixed bugs in the mmio handler functions
Changes since v2:
- Removed patch 5 from v2 and integrating the changes in what's now
patch 5 to make it easier to reuse code when adding VFIO integration.
- Changed the virtual distributor MMIO handling to use the
pending_latch and more closely match the semantics of SPENDR and
CPENDR for both level and edge mapped interrupts.
Changes since v1:
- Added necessary changes to the timer (Patch 1)
- Added handling of guest MMIO accesses to the virtual distributor
(Patch 4)
- Addressed Marc's comments from the initial RFC (mostly renames)
Thanks,
-Christoffer
Christoffer Dall (8):
KVM: arm/arm64: Remove redundant preemptible checks
KVM: arm/arm64: Factor out functionality to get vgic mmio
requester_vcpu
KVM: arm/arm64: Don't cache the timer IRQ level
KVM: arm/arm64: vgic: Support level-triggered mapped interrupts
KVM: arm/arm64: Support a vgic interrupt line level sample function
KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs
KVM: arm/arm64: Provide a get_input_level for the arch timer
KVM: arm/arm64: Avoid work when userspace iqchips are not used
include/kvm/arm_arch_timer.h | 2 +
include/kvm/arm_vgic.h | 13 ++++-
virt/kvm/arm/arch_timer.c | 105 +++++++++++++++++++++-----------------
virt/kvm/arm/arm.c | 2 -
virt/kvm/arm/vgic/vgic-mmio.c | 115 ++++++++++++++++++++++++++++++++++--------
virt/kvm/arm/vgic/vgic-v2.c | 29 +++++++++++
virt/kvm/arm/vgic/vgic-v3.c | 29 +++++++++++
virt/kvm/arm/vgic/vgic.c | 42 +++++++++++++--
virt/kvm/arm/vgic/vgic.h | 8 +++
9 files changed, 270 insertions(+), 75 deletions(-)
--
2.14.2
^ permalink raw reply
* [PATCH] KVM: arm: Use PTR_ERR_OR_ZERO()
From: Christoffer Dall @ 2017-12-04 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHYXAnL3DVkDMF03QRV62RCFzmViDGYR2rQHBS44jyCo2FRgqw@mail.gmail.com>
On Mon, Dec 04, 2017 at 12:11:22PM +0100, Gomonovych, Vasyl wrote:
> Hi Christoffer
>
> It is just syntax sugar of course
> and in mentioned function context it looks harmonically because it is
> in the end of function return statement.
> But in context of around source files it is looks not so harmonically because
> existing code uses old approach.
> And this old approach is only in one place here.
> So it is just a try to fix the warning and may be force to use it in a
> future changes.
ok, thanks.
-Christoffer
^ permalink raw reply
* [PATCH v2 2/2] ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850
From: Alexandre Belloni @ 2017-12-04 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130211740.GA26784@roeck-us.net>
On 30/11/2017 at 13:17:40 -0800, Guenter Roeck wrote:
> > I think it's a bugfix; it fixes real problems where the application
> > misbehave due to faulty content when reading from an eeprom. I'm
> > expecting to make a new release for the hw in question RSN and these
> > are the only local patches. So, it would be nice if they made it to
> > 4.14.x before my release happens. However, it's not like it's difficult
> > to rebase the patches should that backport not happen or take too long.
> >
> Good enough for me. I'll send it as a fix for v4.15, with Cc: stable.
>
I have it in my fixes branch too, I'll send it to arm-soc soon.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] ARM: dts: at91: add devicetree for the Axentia Nattis with Natte power
From: Alexandre Belloni @ 2017-12-04 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204135708.8234-1-peda@axentia.se>
On 04/12/2017 at 14:57:08 +0100, Peter Rosin wrote:
> The Axentia Nattis is a device designed for presenting departures for
> public transport systems. The Natte helper board provides power and
> features a battery of battery chargers.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
>
> This was part of a two-patch series, but the first patch in that
> series was redundant, so I dropped it (there was a dt binding
> recently added for the tfa9879 amplifier that I had not noticed).
>
> Changes since v1: https://lkml.org/lkml/2017/12/1/844
> - removed chip-ids from before the @-sign instead naming the nodes
> for the function, e.g sx1502q at 20 -> ioexp at 20
> - added #sound-dai-cells to the amplifier node
> - switch to SPDX license tags
>
> Cheers,
> Peter
>
> Documentation/devicetree/bindings/arm/axentia.txt | 9 +
> MAINTAINERS | 2 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/at91-natte.dtsi | 244 ++++++++++++++++++++
> arch/arm/boot/dts/at91-nattis-2-natte-2.dts | 258 ++++++++++++++++++++++
> 5 files changed, 514 insertions(+)
> create mode 100644 arch/arm/boot/dts/at91-natte.dtsi
> create mode 100644 arch/arm/boot/dts/at91-nattis-2-natte-2.dts
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v5 6/8] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs
From: Christoffer Dall @ 2017-12-04 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171129151314.el7ndd2czsglw7lh@kamzik.brq.redhat.com>
On Wed, Nov 29, 2017 at 04:13:14PM +0100, Andrew Jones wrote:
> On Mon, Nov 20, 2017 at 08:16:47PM +0100, Christoffer Dall wrote:
> > For mapped IRQs (with the HW bit set in the LR) we have to follow some
> > rules of the architecture. One of these rules is that VM must not be
> > allowed to deactivate a virtual interrupt with the HW bit set unless the
> > physical interrupt is also active.
> >
> > This works fine when injecting mapped interrupts, because we leave it up
> > to the injector to either set EOImode==1 or manually set the active
> > state of the physical interrupt.
> >
> > However, the guest can set virtual interrupt to be pending or active by
> > writing to the virtual distributor, which could lead to deactivating a
> > virtual interrupt with the HW bit set without the physical interrupt
> > being active.
> >
> > We could set the physical interrupt to active whenever we are about to
> > enter the VM with a HW interrupt either pending or active, but that
> > would be really slow, especially on GICv2. So we take the long way
> > around and do the hard work when needed, which is expected to be
> > extremely rare.
> >
> > When the VM sets the pending state for a HW interrupt on the virtual
> > distributor we set the active state on the physical distributor, because
> > the virtual interrupt can become active and then the guest can
> > deactivate it.
> >
> > When the VM clears the pending state we also clear it on the physical
> > side, because the injector might otherwise raise the interrupt. We also
> > clear the physical active state when the virtual interrupt is not
> > active, since otherwise a SPEND/CPEND sequence from the guest would
> > prevent signaling of future interrupts.
> >
> > Changing the state of mapped interrupts from userspace is not supported,
> > and it's expected that userspace unmaps devices from VFIO before
> > attempting to set the interrupt state, because the interrupt state is
> > driven by hardware.
> >
> > Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > virt/kvm/arm/vgic/vgic-mmio.c | 71 +++++++++++++++++++++++++++++++++++++++----
> > virt/kvm/arm/vgic/vgic.c | 7 +++++
> > virt/kvm/arm/vgic/vgic.h | 1 +
> > 3 files changed, 73 insertions(+), 6 deletions(-)
> >
> > diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
> > index 6113cf850f47..294e949ece24 100644
> > --- a/virt/kvm/arm/vgic/vgic-mmio.c
> > +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> > @@ -16,6 +16,7 @@
> > #include <linux/kvm.h>
> > #include <linux/kvm_host.h>
> > #include <kvm/iodev.h>
> > +#include <kvm/arm_arch_timer.h>
> > #include <kvm/arm_vgic.h>
> >
> > #include "vgic.h"
> > @@ -142,10 +143,22 @@ static struct kvm_vcpu *vgic_get_mmio_requester_vcpu(void)
> > return vcpu;
> > }
> >
> > +/* Must be called with irq->irq_lock held */
> > +static void vgic_hw_irq_spending(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> > + bool is_uaccess)
> > +{
> > + if (!is_uaccess)
> > + irq->pending_latch = true;
> > +
> > + if (!is_uaccess)
> > + vgic_irq_set_phys_active(irq, true);
>
> I see this whole patch has this two 'if (!is_uaccess)' checks pattern.
> Is that meant to convey something?
Yeah, that I'm a fool.
> Or is the first condition not supposed
> to have the '!'? (I'm lost with regards to the state tracking differences
> between the guest and userspace and just reviewing superficially...)
>
This became weird becaus the first clause used to be "if (!is_uaccess ||
is_timer)", but now when the timer is interrupt driven (the timer
optimization series), we don't have that concept anymore, and I just
blindly removes the "|| is_timer" part.
I reworked this so that the functions now have
if (is_uaccess)
return;
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v5 2/8] KVM: arm/arm64: Factor out functionality to get vgic mmio requester_vcpu
From: Christoffer Dall @ 2017-12-04 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aab23eee-aa3b-9349-6e78-473beeb46969@arm.com>
On Fri, Dec 01, 2017 at 06:04:32PM +0000, Andre Przywara wrote:
> Hi,
>
> On 20/11/17 19:16, Christoffer Dall wrote:
> > We are about to distinguish between userspace accesses and mmio traps
> > for a number of the mmio handlers. When the requester vcpu is NULL, it
> > mens we are handling a userspace acccess.
> >
> > Factor out the functionality to get the request vcpu into its own
> > function, mostly so we have a common place to document the semantics of
> > the return value.
> >
> > Also take the chance to move the functionality outside of holding a
> > spinlock and instead explicitly disable and enable preemption. This
> > supports PREEMPT_RT kernels as well.
> >
> > Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > virt/kvm/arm/vgic/vgic-mmio.c | 43 +++++++++++++++++++++++++++----------------
> > 1 file changed, 27 insertions(+), 16 deletions(-)
> >
> > diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
> > index deb51ee16a3d..6113cf850f47 100644
> > --- a/virt/kvm/arm/vgic/vgic-mmio.c
> > +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> > @@ -122,6 +122,26 @@ unsigned long vgic_mmio_read_pending(struct kvm_vcpu *vcpu,
> > return value;
> > }
> >
> > +/*
> > + * This function will return the VCPU that performed the MMIO access and
> > + * trapped from twithin the VM, and will return NULL if this is a userspace
> > + * access.
> > + *
> > + * We can disable preemption locally around accessing the per-CPU variable
> > + * because even if the current thread is migrated to another CPU, reading the
> > + * per-CPU value later will give us the same value as we update the per-CPU
> > + * variable in the preempt notifier handlers.
>
> This comment left me scratching my head a bit. Maybe you could change it
> to point out that ... it's safe to *enable* preemption after the call
> again, because of said reasons? Because disabling preemption before
> accessing a per-CPU variable is not really an issue.
I'll try to clarify.
>
> Apart from that it's fine.
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
>
Thanks,
-Christoffer
^ permalink raw reply
* Applied "ASoC: spdif: Add S32_LE support for S/PDIF dummy codec drivers" to the asoc tree
From: Mark Brown @ 2017-12-04 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171122114321.29196-2-suzuki.katsuhiro@socionext.com>
The patch
ASoC: spdif: Add S32_LE support for S/PDIF dummy codec drivers
has been applied to the asoc tree at
https://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 eb733366f5f7f416a7d9215a40e00d57aa193361 Mon Sep 17 00:00:00 2001
From: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Date: Wed, 22 Nov 2017 20:43:14 +0900
Subject: [PATCH] ASoC: spdif: Add S32_LE support for S/PDIF dummy codec
drivers
AIO on UniPhier can output S/PDIF where no codec is needed.
This patch adds S32_LE support for dummy codec drivers.
If one S/PDIF controller has its own limitation, its CPU DAI driver should
set the supported format by its own circumstance, since the soc-pcm driver
will use the intersection of cpu_dai's formats and codec_dai's formats.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/codecs/spdif_receiver.c | 5 +++--
sound/soc/codecs/spdif_transmitter.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/spdif_receiver.c b/sound/soc/codecs/spdif_receiver.c
index 7acd05140a81..c8fd6367f6c0 100644
--- a/sound/soc/codecs/spdif_receiver.c
+++ b/sound/soc/codecs/spdif_receiver.c
@@ -34,10 +34,11 @@ static const struct snd_soc_dapm_route dir_routes[] = {
#define STUB_RATES SNDRV_PCM_RATE_8000_192000
#define STUB_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S20_3LE | \
- SNDRV_PCM_FMTBIT_S24_LE | \
+ SNDRV_PCM_FMTBIT_S24_LE | \
+ SNDRV_PCM_FMTBIT_S32_LE | \
SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE)
-static const struct snd_soc_codec_driver soc_codec_spdif_dir = {
+static struct snd_soc_codec_driver soc_codec_spdif_dir = {
.component_driver = {
.dapm_widgets = dir_widgets,
.num_dapm_widgets = ARRAY_SIZE(dir_widgets),
diff --git a/sound/soc/codecs/spdif_transmitter.c b/sound/soc/codecs/spdif_transmitter.c
index 063a64ff82d3..037aa1d45559 100644
--- a/sound/soc/codecs/spdif_transmitter.c
+++ b/sound/soc/codecs/spdif_transmitter.c
@@ -27,7 +27,8 @@
#define STUB_RATES SNDRV_PCM_RATE_8000_192000
#define STUB_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S20_3LE | \
- SNDRV_PCM_FMTBIT_S24_LE)
+ SNDRV_PCM_FMTBIT_S24_LE | \
+ SNDRV_PCM_FMTBIT_S32_LE)
static const struct snd_soc_dapm_widget dit_widgets[] = {
SND_SOC_DAPM_OUTPUT("spdif-out"),
@@ -37,7 +38,7 @@ static const struct snd_soc_dapm_route dit_routes[] = {
{ "spdif-out", NULL, "Playback" },
};
-static const struct snd_soc_codec_driver soc_codec_spdif_dit = {
+static struct snd_soc_codec_driver soc_codec_spdif_dit = {
.component_driver = {
.dapm_widgets = dit_widgets,
.num_dapm_widgets = ARRAY_SIZE(dit_widgets),
--
2.15.0
^ permalink raw reply related
* Applied "ASoC: uniphier: add DT bindings documentation for UniPhier EVEA" to the asoc tree
From: Mark Brown @ 2017-12-04 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171122114321.29196-3-suzuki.katsuhiro@socionext.com>
The patch
ASoC: uniphier: add DT bindings documentation for UniPhier EVEA
has been applied to the asoc tree at
https://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 e85c8d3e25c09fd9b21ba74e14078ab4c1d977ef Mon Sep 17 00:00:00 2001
From: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Date: Wed, 22 Nov 2017 20:43:15 +0900
Subject: [PATCH] ASoC: uniphier: add DT bindings documentation for UniPhier
EVEA
This patch adds DT binding documentation for UniPhier EVEA
that is SoC inner sound codec of UniPhier series.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/uniphier,evea.txt | 26 ++++++++++++++++++++++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/uniphier,evea.txt
diff --git a/Documentation/devicetree/bindings/sound/uniphier,evea.txt b/Documentation/devicetree/bindings/sound/uniphier,evea.txt
new file mode 100644
index 000000000000..3f31b235f18b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/uniphier,evea.txt
@@ -0,0 +1,26 @@
+Socionext EVEA - UniPhier SoC internal codec driver
+
+Required properties:
+- compatible : should be "socionext,uniphier-evea".
+- reg : offset and length of the register set for the device.
+- clock-names : should include following entries:
+ "evea", "exiv"
+- clocks : a list of phandle, should contain an entry for each
+ entries in clock-names.
+- reset-names : should include following entries:
+ "evea", "exiv", "adamv"
+- resets : a list of phandle, should contain reset entries of
+ reset-names.
+- #sound-dai-cells: should be 1.
+
+Example:
+
+ codec {
+ compatible = "socionext,uniphier-evea";
+ reg = <0x57900000 0x1000>;
+ clock-names = "evea", "exiv";
+ clocks = <&sys_clk 41>, <&sys_clk 42>;
+ reset-names = "evea", "exiv", "adamv";
+ resets = <&sys_rst 41>, <&sys_rst 42>, <&adamv_rst 0>;
+ #sound-dai-cells = <1>;
+ };
--
2.15.0
^ permalink raw reply related
* Applied "ASoC: uniphier: add support for UniPhier EVEA codec" to the asoc tree
From: Mark Brown @ 2017-12-04 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171122114321.29196-5-suzuki.katsuhiro@socionext.com>
The patch
ASoC: uniphier: add support for UniPhier EVEA codec
has been applied to the asoc tree at
https://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 3a47b1dfa2913038623cec3164adfb2448269fa6 Mon Sep 17 00:00:00 2001
From: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Date: Wed, 22 Nov 2017 20:43:17 +0900
Subject: [PATCH] ASoC: uniphier: add support for UniPhier EVEA codec
This patch adds EVEA codec driver. This codec core is in inside of
UniPhier SoC.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/Kconfig | 1 +
sound/soc/Makefile | 1 +
sound/soc/uniphier/Kconfig | 19 ++
sound/soc/uniphier/Makefile | 3 +
sound/soc/uniphier/evea.c | 567 ++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 591 insertions(+)
create mode 100644 sound/soc/uniphier/Kconfig
create mode 100644 sound/soc/uniphier/Makefile
create mode 100644 sound/soc/uniphier/evea.c
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index d22758165496..84c3582f3982 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -71,6 +71,7 @@ source "sound/soc/stm/Kconfig"
source "sound/soc/sunxi/Kconfig"
source "sound/soc/tegra/Kconfig"
source "sound/soc/txx9/Kconfig"
+source "sound/soc/uniphier/Kconfig"
source "sound/soc/ux500/Kconfig"
source "sound/soc/xtensa/Kconfig"
source "sound/soc/zte/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index 5327f4d6c668..74cd1858d38b 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_SND_SOC) += stm/
obj-$(CONFIG_SND_SOC) += sunxi/
obj-$(CONFIG_SND_SOC) += tegra/
obj-$(CONFIG_SND_SOC) += txx9/
+obj-$(CONFIG_SND_SOC) += uniphier/
obj-$(CONFIG_SND_SOC) += ux500/
obj-$(CONFIG_SND_SOC) += xtensa/
obj-$(CONFIG_SND_SOC) += zte/
diff --git a/sound/soc/uniphier/Kconfig b/sound/soc/uniphier/Kconfig
new file mode 100644
index 000000000000..02886a457eaf
--- /dev/null
+++ b/sound/soc/uniphier/Kconfig
@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: GPL-2.0
+config SND_SOC_UNIPHIER
+ tristate "ASoC support for UniPhier"
+ depends on (ARCH_UNIPHIER || COMPILE_TEST)
+ help
+ Say Y or M if you want to add support for the Socionext
+ UniPhier SoC audio interfaces. You will also need to select the
+ audio interfaces to support below.
+ If unsure select "N".
+
+config SND_SOC_UNIPHIER_EVEA_CODEC
+ tristate "UniPhier SoC internal audio codec"
+ depends on SND_SOC_UNIPHIER
+ select REGMAP_MMIO
+ help
+ This adds Codec driver for Socionext UniPhier LD11/20 SoC
+ internal DAC. This driver supports Line In / Out and HeadPhone.
+ Select Y if you use such device.
+ If unsure select "N".
diff --git a/sound/soc/uniphier/Makefile b/sound/soc/uniphier/Makefile
new file mode 100644
index 000000000000..3be00d72f5e5
--- /dev/null
+++ b/sound/soc/uniphier/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+snd-soc-uniphier-evea-objs := evea.o
+obj-$(CONFIG_SND_SOC_UNIPHIER_EVEA_CODEC) += snd-soc-uniphier-evea.o
diff --git a/sound/soc/uniphier/evea.c b/sound/soc/uniphier/evea.c
new file mode 100644
index 000000000000..0cc9efff1d9a
--- /dev/null
+++ b/sound/soc/uniphier/evea.c
@@ -0,0 +1,567 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Socionext UniPhier EVEA ADC/DAC codec driver.
+ *
+ * Copyright (c) 2016-2017 Socionext Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <sound/pcm.h>
+#include <sound/soc.h>
+
+#define DRV_NAME "evea"
+#define EVEA_RATES SNDRV_PCM_RATE_48000
+#define EVEA_FORMATS SNDRV_PCM_FMTBIT_S32_LE
+
+#define AADCPOW(n) (0x0078 + 0x04 * (n))
+#define AADCPOW_AADC_POWD BIT(0)
+#define AHPOUTPOW 0x0098
+#define AHPOUTPOW_HP_ON BIT(4)
+#define ALINEPOW 0x009c
+#define ALINEPOW_LIN2_POWD BIT(3)
+#define ALINEPOW_LIN1_POWD BIT(4)
+#define ALO1OUTPOW 0x00a8
+#define ALO1OUTPOW_LO1_ON BIT(4)
+#define ALO2OUTPOW 0x00ac
+#define ALO2OUTPOW_ADAC2_MUTE BIT(0)
+#define ALO2OUTPOW_LO2_ON BIT(4)
+#define AANAPOW 0x00b8
+#define AANAPOW_A_POWD BIT(4)
+#define ADACSEQ1(n) (0x0144 + 0x40 * (n))
+#define ADACSEQ1_MMUTE BIT(1)
+#define ADACSEQ2(n) (0x0160 + 0x40 * (n))
+#define ADACSEQ2_ADACIN_FIX BIT(0)
+#define ADAC1ODC 0x0200
+#define ADAC1ODC_HP_DIS_RES_MASK GENMASK(2, 1)
+#define ADAC1ODC_HP_DIS_RES_OFF (0x0 << 1)
+#define ADAC1ODC_HP_DIS_RES_ON (0x3 << 1)
+#define ADAC1ODC_ADAC_RAMPCLT_MASK GENMASK(8, 7)
+#define ADAC1ODC_ADAC_RAMPCLT_NORMAL (0x0 << 7)
+#define ADAC1ODC_ADAC_RAMPCLT_REDUCE (0x1 << 7)
+
+struct evea_priv {
+ struct clk *clk, *clk_exiv;
+ struct reset_control *rst, *rst_exiv, *rst_adamv;
+ struct regmap *regmap;
+
+ int switch_lin;
+ int switch_lo;
+ int switch_hp;
+};
+
+static const struct snd_soc_dapm_widget evea_widgets[] = {
+ SND_SOC_DAPM_ADC("ADC", "Capture", SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_INPUT("LIN1_LP"),
+ SND_SOC_DAPM_INPUT("LIN1_RP"),
+ SND_SOC_DAPM_INPUT("LIN2_LP"),
+ SND_SOC_DAPM_INPUT("LIN2_RP"),
+ SND_SOC_DAPM_INPUT("LIN3_LP"),
+ SND_SOC_DAPM_INPUT("LIN3_RP"),
+
+ SND_SOC_DAPM_DAC("DAC", "Playback", SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_OUTPUT("HP1_L"),
+ SND_SOC_DAPM_OUTPUT("HP1_R"),
+ SND_SOC_DAPM_OUTPUT("LO2_L"),
+ SND_SOC_DAPM_OUTPUT("LO2_R"),
+};
+
+static const struct snd_soc_dapm_route evea_routes[] = {
+ { "ADC", NULL, "LIN1_LP" },
+ { "ADC", NULL, "LIN1_RP" },
+ { "ADC", NULL, "LIN2_LP" },
+ { "ADC", NULL, "LIN2_RP" },
+ { "ADC", NULL, "LIN3_LP" },
+ { "ADC", NULL, "LIN3_RP" },
+
+ { "HP1_L", NULL, "DAC" },
+ { "HP1_R", NULL, "DAC" },
+ { "LO2_L", NULL, "DAC" },
+ { "LO2_R", NULL, "DAC" },
+};
+
+static void evea_set_power_state_on(struct evea_priv *evea)
+{
+ struct regmap *map = evea->regmap;
+
+ regmap_update_bits(map, AANAPOW, AANAPOW_A_POWD,
+ AANAPOW_A_POWD);
+
+ regmap_update_bits(map, ADAC1ODC, ADAC1ODC_HP_DIS_RES_MASK,
+ ADAC1ODC_HP_DIS_RES_ON);
+
+ regmap_update_bits(map, ADAC1ODC, ADAC1ODC_ADAC_RAMPCLT_MASK,
+ ADAC1ODC_ADAC_RAMPCLT_REDUCE);
+
+ regmap_update_bits(map, ADACSEQ2(0), ADACSEQ2_ADACIN_FIX, 0);
+ regmap_update_bits(map, ADACSEQ2(1), ADACSEQ2_ADACIN_FIX, 0);
+ regmap_update_bits(map, ADACSEQ2(2), ADACSEQ2_ADACIN_FIX, 0);
+}
+
+static void evea_set_power_state_off(struct evea_priv *evea)
+{
+ struct regmap *map = evea->regmap;
+
+ regmap_update_bits(map, ADAC1ODC, ADAC1ODC_HP_DIS_RES_MASK,
+ ADAC1ODC_HP_DIS_RES_ON);
+
+ regmap_update_bits(map, ADACSEQ1(0), ADACSEQ1_MMUTE,
+ ADACSEQ1_MMUTE);
+ regmap_update_bits(map, ADACSEQ1(1), ADACSEQ1_MMUTE,
+ ADACSEQ1_MMUTE);
+ regmap_update_bits(map, ADACSEQ1(2), ADACSEQ1_MMUTE,
+ ADACSEQ1_MMUTE);
+
+ regmap_update_bits(map, ALO1OUTPOW, ALO1OUTPOW_LO1_ON, 0);
+ regmap_update_bits(map, ALO2OUTPOW, ALO2OUTPOW_LO2_ON, 0);
+ regmap_update_bits(map, AHPOUTPOW, AHPOUTPOW_HP_ON, 0);
+}
+
+static int evea_update_switch_lin(struct evea_priv *evea)
+{
+ struct regmap *map = evea->regmap;
+
+ if (evea->switch_lin) {
+ regmap_update_bits(map, ALINEPOW,
+ ALINEPOW_LIN2_POWD | ALINEPOW_LIN1_POWD,
+ ALINEPOW_LIN2_POWD | ALINEPOW_LIN1_POWD);
+
+ regmap_update_bits(map, AADCPOW(0), AADCPOW_AADC_POWD,
+ AADCPOW_AADC_POWD);
+ regmap_update_bits(map, AADCPOW(1), AADCPOW_AADC_POWD,
+ AADCPOW_AADC_POWD);
+ } else {
+ regmap_update_bits(map, AADCPOW(0), AADCPOW_AADC_POWD, 0);
+ regmap_update_bits(map, AADCPOW(1), AADCPOW_AADC_POWD, 0);
+
+ regmap_update_bits(map, ALINEPOW,
+ ALINEPOW_LIN2_POWD | ALINEPOW_LIN1_POWD, 0);
+ }
+
+ return 0;
+}
+
+static int evea_update_switch_lo(struct evea_priv *evea)
+{
+ struct regmap *map = evea->regmap;
+
+ if (evea->switch_lo) {
+ regmap_update_bits(map, ADACSEQ1(0), ADACSEQ1_MMUTE, 0);
+ regmap_update_bits(map, ADACSEQ1(2), ADACSEQ1_MMUTE, 0);
+
+ regmap_update_bits(map, ALO1OUTPOW, ALO1OUTPOW_LO1_ON,
+ ALO1OUTPOW_LO1_ON);
+ regmap_update_bits(map, ALO2OUTPOW,
+ ALO2OUTPOW_ADAC2_MUTE | ALO2OUTPOW_LO2_ON,
+ ALO2OUTPOW_ADAC2_MUTE | ALO2OUTPOW_LO2_ON);
+ } else {
+ regmap_update_bits(map, ADACSEQ1(0), ADACSEQ1_MMUTE,
+ ADACSEQ1_MMUTE);
+ regmap_update_bits(map, ADACSEQ1(2), ADACSEQ1_MMUTE,
+ ADACSEQ1_MMUTE);
+
+ regmap_update_bits(map, ALO1OUTPOW, ALO1OUTPOW_LO1_ON, 0);
+ regmap_update_bits(map, ALO2OUTPOW,
+ ALO2OUTPOW_ADAC2_MUTE | ALO2OUTPOW_LO2_ON,
+ 0);
+ }
+
+ return 0;
+}
+
+static int evea_update_switch_hp(struct evea_priv *evea)
+{
+ struct regmap *map = evea->regmap;
+
+ if (evea->switch_hp) {
+ regmap_update_bits(map, ADACSEQ1(1), ADACSEQ1_MMUTE, 0);
+
+ regmap_update_bits(map, AHPOUTPOW, AHPOUTPOW_HP_ON,
+ AHPOUTPOW_HP_ON);
+
+ regmap_update_bits(map, ADAC1ODC, ADAC1ODC_HP_DIS_RES_MASK,
+ ADAC1ODC_HP_DIS_RES_OFF);
+ } else {
+ regmap_update_bits(map, ADAC1ODC, ADAC1ODC_HP_DIS_RES_MASK,
+ ADAC1ODC_HP_DIS_RES_ON);
+
+ regmap_update_bits(map, ADACSEQ1(1), ADACSEQ1_MMUTE,
+ ADACSEQ1_MMUTE);
+
+ regmap_update_bits(map, AHPOUTPOW, AHPOUTPOW_HP_ON, 0);
+ }
+
+ return 0;
+}
+
+static void evea_update_switch_all(struct evea_priv *evea)
+{
+ evea_update_switch_lin(evea);
+ evea_update_switch_lo(evea);
+ evea_update_switch_hp(evea);
+}
+
+static int evea_get_switch_lin(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
+ struct evea_priv *evea = snd_soc_codec_get_drvdata(codec);
+
+ ucontrol->value.integer.value[0] = evea->switch_lin;
+
+ return 0;
+}
+
+static int evea_set_switch_lin(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
+ struct evea_priv *evea = snd_soc_codec_get_drvdata(codec);
+
+ if (evea->switch_lin == ucontrol->value.integer.value[0])
+ return 0;
+
+ evea->switch_lin = ucontrol->value.integer.value[0];
+
+ return evea_update_switch_lin(evea);
+}
+
+static int evea_get_switch_lo(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
+ struct evea_priv *evea = snd_soc_codec_get_drvdata(codec);
+
+ ucontrol->value.integer.value[0] = evea->switch_lo;
+
+ return 0;
+}
+
+static int evea_set_switch_lo(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
+ struct evea_priv *evea = snd_soc_codec_get_drvdata(codec);
+
+ if (evea->switch_lo == ucontrol->value.integer.value[0])
+ return 0;
+
+ evea->switch_lo = ucontrol->value.integer.value[0];
+
+ return evea_update_switch_lo(evea);
+}
+
+static int evea_get_switch_hp(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
+ struct evea_priv *evea = snd_soc_codec_get_drvdata(codec);
+
+ ucontrol->value.integer.value[0] = evea->switch_hp;
+
+ return 0;
+}
+
+static int evea_set_switch_hp(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
+ struct evea_priv *evea = snd_soc_codec_get_drvdata(codec);
+
+ if (evea->switch_hp == ucontrol->value.integer.value[0])
+ return 0;
+
+ evea->switch_hp = ucontrol->value.integer.value[0];
+
+ return evea_update_switch_hp(evea);
+}
+
+static const struct snd_kcontrol_new eva_controls[] = {
+ SOC_SINGLE_BOOL_EXT("Line Capture Switch", 0,
+ evea_get_switch_lin, evea_set_switch_lin),
+ SOC_SINGLE_BOOL_EXT("Line Playback Switch", 0,
+ evea_get_switch_lo, evea_set_switch_lo),
+ SOC_SINGLE_BOOL_EXT("Headphone Playback Switch", 0,
+ evea_get_switch_hp, evea_set_switch_hp),
+};
+
+static int evea_codec_probe(struct snd_soc_codec *codec)
+{
+ struct evea_priv *evea = snd_soc_codec_get_drvdata(codec);
+
+ evea->switch_lin = 1;
+ evea->switch_lo = 1;
+ evea->switch_hp = 1;
+
+ evea_set_power_state_on(evea);
+ evea_update_switch_all(evea);
+
+ return 0;
+}
+
+static int evea_codec_suspend(struct snd_soc_codec *codec)
+{
+ struct evea_priv *evea = snd_soc_codec_get_drvdata(codec);
+
+ evea_set_power_state_off(evea);
+
+ reset_control_assert(evea->rst_adamv);
+ reset_control_assert(evea->rst_exiv);
+ reset_control_assert(evea->rst);
+
+ clk_disable_unprepare(evea->clk_exiv);
+ clk_disable_unprepare(evea->clk);
+
+ return 0;
+}
+
+static int evea_codec_resume(struct snd_soc_codec *codec)
+{
+ struct evea_priv *evea = snd_soc_codec_get_drvdata(codec);
+ int ret;
+
+ ret = clk_prepare_enable(evea->clk);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(evea->clk_exiv);
+ if (ret)
+ goto err_out_clock;
+
+ ret = reset_control_deassert(evea->rst);
+ if (ret)
+ goto err_out_clock_exiv;
+
+ ret = reset_control_deassert(evea->rst_exiv);
+ if (ret)
+ goto err_out_reset;
+
+ ret = reset_control_deassert(evea->rst_adamv);
+ if (ret)
+ goto err_out_reset_exiv;
+
+ evea_set_power_state_on(evea);
+ evea_update_switch_all(evea);
+
+ return 0;
+
+err_out_reset_exiv:
+ reset_control_assert(evea->rst_exiv);
+
+err_out_reset:
+ reset_control_assert(evea->rst);
+
+err_out_clock_exiv:
+ clk_disable_unprepare(evea->clk_exiv);
+
+err_out_clock:
+ clk_disable_unprepare(evea->clk);
+
+ return ret;
+}
+
+static struct snd_soc_codec_driver soc_codec_evea = {
+ .probe = evea_codec_probe,
+ .suspend = evea_codec_suspend,
+ .resume = evea_codec_resume,
+
+ .component_driver = {
+ .dapm_widgets = evea_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(evea_widgets),
+ .dapm_routes = evea_routes,
+ .num_dapm_routes = ARRAY_SIZE(evea_routes),
+ .controls = eva_controls,
+ .num_controls = ARRAY_SIZE(eva_controls),
+ },
+};
+
+static struct snd_soc_dai_driver soc_dai_evea[] = {
+ {
+ .name = DRV_NAME "-line1",
+ .playback = {
+ .stream_name = "Line Out 1",
+ .formats = EVEA_FORMATS,
+ .rates = EVEA_RATES,
+ .channels_min = 2,
+ .channels_max = 2,
+ },
+ .capture = {
+ .stream_name = "Line In 1",
+ .formats = EVEA_FORMATS,
+ .rates = EVEA_RATES,
+ .channels_min = 2,
+ .channels_max = 2,
+ },
+ },
+ {
+ .name = DRV_NAME "-hp1",
+ .playback = {
+ .stream_name = "Headphone 1",
+ .formats = EVEA_FORMATS,
+ .rates = EVEA_RATES,
+ .channels_min = 2,
+ .channels_max = 2,
+ },
+ },
+ {
+ .name = DRV_NAME "-lo2",
+ .playback = {
+ .stream_name = "Line Out 2",
+ .formats = EVEA_FORMATS,
+ .rates = EVEA_RATES,
+ .channels_min = 2,
+ .channels_max = 2,
+ },
+ },
+};
+
+static const struct regmap_config evea_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0xffc,
+ .cache_type = REGCACHE_NONE,
+};
+
+static int evea_probe(struct platform_device *pdev)
+{
+ struct evea_priv *evea;
+ struct resource *res;
+ void __iomem *preg;
+ int ret;
+
+ evea = devm_kzalloc(&pdev->dev, sizeof(struct evea_priv), GFP_KERNEL);
+ if (!evea)
+ return -ENOMEM;
+
+ evea->clk = devm_clk_get(&pdev->dev, "evea");
+ if (IS_ERR(evea->clk))
+ return PTR_ERR(evea->clk);
+
+ evea->clk_exiv = devm_clk_get(&pdev->dev, "exiv");
+ if (IS_ERR(evea->clk_exiv))
+ return PTR_ERR(evea->clk_exiv);
+
+ evea->rst = devm_reset_control_get_shared(&pdev->dev, "evea");
+ if (IS_ERR(evea->rst))
+ return PTR_ERR(evea->rst);
+
+ evea->rst_exiv = devm_reset_control_get_shared(&pdev->dev, "exiv");
+ if (IS_ERR(evea->rst_exiv))
+ return PTR_ERR(evea->rst_exiv);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ preg = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(preg))
+ return PTR_ERR(preg);
+
+ evea->regmap = devm_regmap_init_mmio(&pdev->dev, preg,
+ &evea_regmap_config);
+ if (IS_ERR(evea->regmap))
+ return PTR_ERR(evea->regmap);
+
+ ret = clk_prepare_enable(evea->clk);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(evea->clk_exiv);
+ if (ret)
+ goto err_out_clock;
+
+ ret = reset_control_deassert(evea->rst);
+ if (ret)
+ goto err_out_clock_exiv;
+
+ ret = reset_control_deassert(evea->rst_exiv);
+ if (ret)
+ goto err_out_reset;
+
+ /* ADAMV will hangup if EXIV reset is asserted */
+ evea->rst_adamv = devm_reset_control_get_shared(&pdev->dev, "adamv");
+ if (IS_ERR(evea->rst_adamv)) {
+ ret = PTR_ERR(evea->rst_adamv);
+ goto err_out_reset_exiv;
+ }
+
+ ret = reset_control_deassert(evea->rst_adamv);
+ if (ret)
+ goto err_out_reset_exiv;
+
+ platform_set_drvdata(pdev, evea);
+
+ ret = snd_soc_register_codec(&pdev->dev, &soc_codec_evea,
+ soc_dai_evea, ARRAY_SIZE(soc_dai_evea));
+ if (ret)
+ goto err_out_reset_adamv;
+
+ return 0;
+
+err_out_reset_adamv:
+ reset_control_assert(evea->rst_adamv);
+
+err_out_reset_exiv:
+ reset_control_assert(evea->rst_exiv);
+
+err_out_reset:
+ reset_control_assert(evea->rst);
+
+err_out_clock_exiv:
+ clk_disable_unprepare(evea->clk_exiv);
+
+err_out_clock:
+ clk_disable_unprepare(evea->clk);
+
+ return ret;
+}
+
+static int evea_remove(struct platform_device *pdev)
+{
+ struct evea_priv *evea = platform_get_drvdata(pdev);
+
+ snd_soc_unregister_codec(&pdev->dev);
+
+ reset_control_assert(evea->rst_adamv);
+ reset_control_assert(evea->rst_exiv);
+ reset_control_assert(evea->rst);
+
+ clk_disable_unprepare(evea->clk_exiv);
+ clk_disable_unprepare(evea->clk);
+
+ return 0;
+}
+
+static const struct of_device_id evea_of_match[] = {
+ { .compatible = "socionext,uniphier-evea", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, evea_of_match);
+
+static struct platform_driver evea_codec_driver = {
+ .driver = {
+ .name = DRV_NAME,
+ .of_match_table = of_match_ptr(evea_of_match),
+ },
+ .probe = evea_probe,
+ .remove = evea_remove,
+};
+module_platform_driver(evea_codec_driver);
+
+MODULE_AUTHOR("Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>");
+MODULE_DESCRIPTION("UniPhier EVEA codec driver");
+MODULE_LICENSE("GPL v2");
--
2.15.0
^ permalink raw reply related
* Applied "MAINTAINERS: add entries for UniPhier ASoC sound drivers" to the asoc tree
From: Mark Brown @ 2017-12-04 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171122114321.29196-8-suzuki.katsuhiro@socionext.com>
The patch
MAINTAINERS: add entries for UniPhier ASoC sound drivers
has been applied to the asoc tree at
https://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 576f8f46e7c923f830dfa61924ad547447399b05 Mon Sep 17 00:00:00 2001
From: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Date: Wed, 22 Nov 2017 20:43:20 +0900
Subject: [PATCH] MAINTAINERS: add entries for UniPhier ASoC sound drivers
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..55ae8ea8722a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12581,6 +12581,12 @@ F: include/media/soc*
F: drivers/media/i2c/soc_camera/
F: drivers/media/platform/soc_camera/
+SOCIONEXT UNIPHIER SOUND DRIVER
+M: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
+L: alsa-devel at alsa-project.org (moderated for non-subscribers)
+S: Maintained
+F: sound/soc/uniphier/
+
SOEKRIS NET48XX LED SUPPORT
M: Chris Boot <bootc@bootc.net>
S: Maintained
--
2.15.0
^ permalink raw reply related
* [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver
From: Mark Brown @ 2017-12-04 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171122114321.29196-6-suzuki.katsuhiro@socionext.com>
On Wed, Nov 22, 2017 at 08:43:18PM +0900, Katsuhiro Suzuki wrote:
> sound/soc/uniphier/Makefile | 4 +
> sound/soc/uniphier/aio-core.c | 368 +++++++++++++++++++++
> sound/soc/uniphier/aio-dma.c | 266 +++++++++++++++
> sound/soc/uniphier/aio-regctrl.c | 699 +++++++++++++++++++++++++++++++++++++++
> sound/soc/uniphier/aio-regctrl.h | 495 +++++++++++++++++++++++++++
> sound/soc/uniphier/aio.h | 261 +++++++++++++++
Please split this up more, it looks like there's at least two or three
drivers in here and it winds up being quite large. There's at least a
DMA and a DAI driver. Looking through this my overall impression is
that this is a fairly large and complex audio subsystem with some DSP
and routing capacity which is being handled in a board specific fashion
rather than generically but it's kind of hard to tell as there's not
much description of what's going on so I'm needing to reverse engineer
things from the driver.
The code itself looks fairly clean, it's mainly a case of trying to
figure out if it's doing what it's supposed to with the limited
documentation.
> +int uniphier_aio_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *dai)
> +{
> + struct uniphier_aio *aio = uniphier_priv(dai);
> + struct uniphier_aio_sub *sub = &aio->sub[substream->stream];
> +
> + sub->params = *params;
> + sub->setting = 1;
So we don't validate the params at all?
> + uniphier_aio_port_reset(sub);
> + uniphier_aio_srcport_reset(sub);
Is there a mux in the SoC here?
> +static const struct of_device_id uniphier_aio_of_match[] = {
> +#ifdef CONFIG_SND_SOC_UNIPHIER_LD11
> + {
> + .compatible = "socionext,uniphier-ld11-aio",
> + .data = &uniphier_aio_ld11_spec,
> + },
> + {
> + .compatible = "socionext,uniphier-ld20-aio",
> + .data = &uniphier_aio_ld20_spec,
> + },
> +#endif /* CONFIG_SND_SOC_UNIPHIER_LD11 */
Why is there an ifdef here? There's no other conditional code in here,
it seems pointless.
> + for (j = 0; j < ARRAY_SIZE(aio->sub); j++) {
> + struct uniphier_aio_sub *sub = &aio->sub[j];
> +
> + if (!sub->running)
> + continue;
> +
> + spin_lock(&sub->spin);
> + uniphier_aio_rb_sync(sub);
> + uniphier_aio_rb_clear_int(sub);
> + spin_unlock(&sub->spin);
It's not 100% obvious what this does... a comment might help.
> +int uniphier_aio_chip_init(struct uniphier_aio_chip *chip)
> +{
> + struct regmap *r = chip->regmap;
> +
> + regmap_update_bits(r, A2APLLCTR0,
> + A2APLLCTR0_APLLXPOW_MASK,
> + A2APLLCTR0_APLLXPOW_PWON);
> +
> + regmap_update_bits(r, A2APLLCTR1, A2APLLCTR1_APLL_MASK,
> + A2APLLCTR1_APLLF2_33MHZ | A2APLLCTR1_APLLA2_33MHZ |
> + A2APLLCTR1_APLLF1_36MHZ | A2APLLCTR1_APLLA1_36MHZ);
> +
> + regmap_update_bits(r, A2EXMCLKSEL0,
> + A2EXMCLKSEL0_EXMCLK_MASK,
> + A2EXMCLKSEL0_EXMCLK_OUTPUT);
> +
> + regmap_update_bits(r, A2AIOINPUTSEL, A2AIOINPUTSEL_RXSEL_MASK,
> + A2AIOINPUTSEL_RXSEL_PCMI1_HDMIRX1 |
> + A2AIOINPUTSEL_RXSEL_PCMI2_SIF |
> + A2AIOINPUTSEL_RXSEL_PCMI3_EVEA |
> + A2AIOINPUTSEL_RXSEL_IECI1_HDMIRX1);
This definitely looks like there's some clocking and audio routing
within the SoC which should be exposed to userspace, or at the very
least machine driver configuration rather than being hard coded.
> + switch (pc) {
> + case IEC61937_PC_AC3:
> + repet = OPORTMXREPET_STRLENGTH_AC3 |
> + OPORTMXREPET_PMLENGTH_AC3;
> + pause |= OPORTMXPAUDAT_PAUSEPD_AC3;
> + break;
> + case IEC61937_PC_MPA:
> + repet = OPORTMXREPET_STRLENGTH_MPA |
> + OPORTMXREPET_PMLENGTH_MPA;
> + pause |= OPORTMXPAUDAT_PAUSEPD_MPA;
> + break;
> + case IEC61937_PC_MP3:
> + repet = OPORTMXREPET_STRLENGTH_MP3 |
> + OPORTMXREPET_PMLENGTH_MP3;
> + pause |= OPORTMXPAUDAT_PAUSEPD_MP3;
> + break;
This looks awfully like compressed audio support... should there be
integration with the compressed audio API/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171204/802f78d4/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/2] drm/tegra: sor: Fix hang on tegra124 due to NULL clk_out
From: Guillaume Tucker @ 2017-12-04 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be610a7596ad8fee7da092161888c532c2eb2908.1512411775.git.guillaume.tucker@collabora.com>
When neither HDMI nor DP is supported such as on the tegra124, the
sor->clk_out is not initialised and remains NULL. In this case, the
parent clock can't be assigned to it so revert to the previous
behaviour of assigning it to the main sor->clock instead.
This fixes a kernel hang on tegra124.
Fixes: e1335e2f0cfc ("drm/tegra: sor: Reimplement pad clock")
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
CC: Thierry Reding <treding@nvidia.com>
---
drivers/gpu/drm/tegra/sor.c | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index b0a1dedac802..8d2e29c9ab2b 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -255,7 +255,7 @@ static int tegra_sor_set_parent_clock(struct tegra_sor *sor, struct clk *parent)
clk_disable_unprepare(sor->clk);
- err = clk_set_parent(sor->clk_out, parent);
+ err = clk_set_parent(sor->clk_out ? sor->clk_out : sor->clk, parent);
if (err < 0)
return err;
@@ -2698,15 +2698,19 @@ static int tegra_sor_probe(struct platform_device *pdev)
sor->clk_pad = NULL;
}
- /*
- * The bootloader may have set up the SOR such that it's module clock
- * is sourced by one of the display PLLs. However, that doesn't work
- * without properly having set up other bits of the SOR.
- */
- err = clk_set_parent(sor->clk_out, sor->clk_safe);
- if (err < 0) {
- dev_err(&pdev->dev, "failed to use safe clock: %d\n", err);
- goto remove;
+ if (sor->clk_out) {
+ /*
+ * The bootloader may have set up the SOR such that its module
+ * clock is sourced by one of the display PLLs. However, that
+ * doesn't work without properly having set up other bits of
+ * the SOR.
+ */
+ err = clk_set_parent(sor->clk_out, sor->clk_safe);
+ if (err < 0) {
+ dev_err(&pdev->dev, "failed to use safe clock: %d\n",
+ err);
+ goto remove;
+ }
}
platform_set_drvdata(pdev, sor);
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] drm/nouveau/bar/gf100: fix hang when calling ->fini() before ->init()
From: Guillaume Tucker @ 2017-12-04 18:37 UTC (permalink / raw)
To: linux-arm-kernel
If the firmware fails to load then ->fini() will be called before the
device has been initialised, causing the kernel to hang while trying
to write to a register. Add a test in ->fini() to avoid this issue.
This fixes a kernel hang on tegra124.
Fixes: b17de35a2ebbe ("drm/nouveau/bar: implement bar1 teardown")
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
CC: Ben Skeggs <bskeggs@redhat.com>
---
drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
index a3ba7f50198b..95e2aba64aad 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c
@@ -43,9 +43,12 @@ gf100_bar_bar1_wait(struct nvkm_bar *base)
}
void
-gf100_bar_bar1_fini(struct nvkm_bar *bar)
+gf100_bar_bar1_fini(struct nvkm_bar *base)
{
- nvkm_mask(bar->subdev.device, 0x001704, 0x80000000, 0x00000000);
+ struct nvkm_device *device = base->subdev.device;
+
+ if (base->subdev.oneinit)
+ nvkm_mask(device, 0x001704, 0x80000000, 0x00000000);
}
void
--
2.11.0
^ permalink raw reply related
* [PATCH 4/7 v2] net: ethernet: i825xx: Fix platform_get_irq's error checking
From: David Miller @ 2017-12-04 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512409703-20881-5-git-send-email-arvind.yadav.cs@gmail.com>
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date: Mon, 4 Dec 2017 23:18:20 +0530
> @@ -120,9 +120,10 @@ static int sni_82596_probe(struct platform_device *dev)
> netdevice->dev_addr[5] = readb(eth_addr + 0x06);
> iounmap(eth_addr);
>
> - if (!netdevice->irq) {
> + if (netdevice->irq <= 0) {
> printk(KERN_ERR "%s: IRQ not found for i82596 at 0x%lx\n",
> __FILE__, netdevice->base_addr);
> + retval = netdevice->irq ? netdevice->irq : -ENODEV;
> goto probe_failed;
> }
Ok, thinking about this some more...
It is impossible to use platform_get_irq() without every single call
site having this funny:
ret = val ? val : -ENODEV;
sequence.
This is unnecessary duplication and it is also error prone, so I
really think this logic belongs in platform_get_irq() itself. It can
convert '0' to -ENODEV and that way we need no special logic in the
callers at all.
^ permalink raw reply
* [PATCH 4/8] ASoC: uniphier: add support for UniPhier EVEA codec
From: Mark Brown @ 2017-12-04 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171122114321.29196-5-suzuki.katsuhiro@socionext.com>
On Wed, Nov 22, 2017 at 08:43:17PM +0900, Katsuhiro Suzuki wrote:
> +++ b/sound/soc/uniphier/evea.c
> @@ -0,0 +1,567 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Socionext UniPhier EVEA ADC/DAC codec driver.
> + *
> + * Copyright (c) 2016-2017 Socionext Inc.
Make the entire comment a C++ comment, don't mix and match like this -
it's ugly. Otherwise this looks good so I'll apply it, please send a
followup patch fixing this (and I guess the same thing will apply to
other files).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171204/0b9857ee/attachment.sig>
^ permalink raw reply
* SCPI regressions in v4.15-rc1 on Amlogic SoCs.
From: Kevin Hilman @ 2017-12-04 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204022441.GB6870@e107533-lin>
Sudeep Holla <sudeep.holla@arm.com> writes:
> On Fri, Dec 01, 2017 at 08:08:25AM +0100, Heiner Kallweit wrote:
>> Am 01.12.2017 um 01:21 schrieb Kevin Hilman:
>> > Hi Sudeep,
>> >
>> > There's been a pretty major regression in v4.15-rc1 compared to v4.15
>> > in SCPI causing warning splats on amlogic SoCs when cpufreq starts up
>> > and tries to set the OPP for the first time[1].
>> >
>> Thanks for the report. Strange enough, it works perfectly fine on my
>> Odroid-C2, see below log part from latest next kernel.
>>
>
> OK, I would like to understand/get the list of AmLogic SoC using SCPI,
> so that I get any changes tested on all of them next time.
You can start here: https://kernelci.org/soc/amlogic/
The "Available boards" section lists 8 boards we have fully automated
that are representative (enough) to catch problems. We have a bunch
more that are not (yet) fully automated in kernelCI.
Anything that is meson-gx* will use SCPI, and it's entirely possible
that they've changed SCPI firmware since the GXBB SoCs (which Heiner is
testing) and the GXL SoCs which seem to be the ones failing. I don't
have much visibiliy into the firmware, but as you mentioned this is
starting to look like it could be related to a firmware change.
The failing logs are showing some new messages on the console that are
not coming from the kernel. I'm guessing they're from the firmware
(still using the serial console!) but I have not fully verified that.
Kevin
> As Kevin mentioned, it's always safer to just cc the amlogic mailing
> list. I have done that in past and failed to observe that this time.
>
>> Your log seems to indicate that due to deferred probing something is
>> not done in the right order.
>> Can you bisect the issue? I'd assume that it's commit 931cf0c53e69
>> ("firmware: arm_scpi: pre-populate dvfs info in scpi_probe").
>>
>
> Yes, even I suspect the same change. But I don't fully understand the issue.
>
> I remember asking you to make some changes in probe path. I think I
> wanted you to continue with SCPI probe even if DVFS fails as that causes
> issues on platforms that have partial DVFS implemented but other protocols
> like clock and sensors working fine.
>
> I guess all platforms with broken SCPI implementation should have it
> disabled in the DT instead of taking special care for that in DT.
>
> I assume that's the case even with the platform under regression now.
> The correct way to fix it would be to disable DVFS node but it may need
> some investigation to narrow down to this comment.
>
> --
> Regards,
> Sudeep
^ permalink raw reply
* [PATCH 07/12] arm64: mm: Place kImage at bottom of VA space
From: Steve Capper @ 2017-12-04 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9Mjd7f57ZZdv+1p70Vs-YD8p6-1P=pb4-KAUsxNVppGw@mail.gmail.com>
On Mon, Dec 04, 2017 at 05:27:10PM +0000, Ard Biesheuvel wrote:
> On 4 December 2017 at 17:18, Steve Capper <steve.capper@arm.com> wrote:
> > Hi Ard,
> >
> > On Mon, Dec 04, 2017 at 04:25:18PM +0000, Ard Biesheuvel wrote:
> >> On 4 December 2017 at 14:13, Steve Capper <steve.capper@arm.com> wrote:
> >> > Re-arrange the kernel memory map s.t. the kernel image resides in the
> >> > bottom 514MB of memory.
> >>
> >> I guess this breaks KASLR entirely, no? Given that it adds an offset
> >> in the range [0 ... sizeof(VMALLOC_SPACE) /4 ].
> >
> > Yes, yes it does. Sorry about this. I had very carefully tested KASLR
> > with custom offsets... on my early page table code. I will have a think
> > about this.
> >
> > From a KASLR side, my (renewed) understanding is that a virtual address
> > as low as possible is desired for the kimage start as that affords the
> > most wiggle room?
> >
>
> Well, the nice thing about the current arrangement is that the default
> is adjacent to the vmalloc space so any non-zero [bounded] offset
> produces a valid placement. Addition with subtraction is easy, so
> which side the default placement happens to be at does not really
> matter. Having to implement additional bounds checking in the early
> KASLR init code to stay clear of the PCI I/O or fixmap regions sounds
> a bit more cumbersome.
>
I *think* I can fix KASAN_SHADOW_END to be 0xFFFF200000000000 on both 48-bit
and 52-bit VA configurations. Thus I may be able to enable 52-bit VA with
minimal disruption to the layout of the VA space (i.e. no need to change
the layout) if I also depend on CONFIG_RELOCATABLE.
I'll investigate...
Cheers,
--
Steve
^ permalink raw reply
* [PATCH net-next 1/2 v6] net: ethernet: Add DT bindings for the Gemini ethernet
From: Hans Ulli Kroll @ 2017-12-04 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171202110640.5284-1-linus.walleij@linaro.org>
Hi Linus
On Sat, 2 Dec 2017, Linus Walleij wrote:
> This adds the device tree bindings for the Gemini ethernet
> controller. It is pretty straight-forward, using standard
> bindings and modelling the two child ports as child devices
> under the parent ethernet controller device.
>
> Cc: devicetree at vger.kernel.org
> Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
> Cc: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> .../bindings/net/cortina,gemini-ethernet.txt | 92 ++++++++++++++++++++++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
>
Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
^ permalink raw reply
* [GIT PULL] Amlogic fixes for v4.15-rc (redo)
From: Kevin Hilman @ 2017-12-04 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171203010837.chbvhkrhayfbnmsz@localhost>
Olof Johansson <olof@lixom.net> writes:
> Hi,
>
> On Thu, Nov 30, 2017 at 04:46:19PM -0800, Kevin Hilman wrote:
>> Arnd, Olof,
>>
>> A handful of minor v4.15 fixes for Amlogic family SoCs. They're mostly
>> DT, but some trivial non-DT stuff mixed in. Let me know if you prefer
>> those in separate pulls, and I will do so.
>>
>> Thanks,
>>
>> Kevin
>>
>>
>> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>>
>> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git amlogic-fixes
>>
>> for you to fetch changes up to 9f8e06ca1d0e3ef1167a2f43a8b1e63763b283b8:
>>
>> ARM64: dts: odroid-c2: Add HDMI and CEC Nodes (2017-11-30 15:30:09 -0800)
>>
>> ----------------------------------------------------------------
>> Amlogic fixes for v4.15-rc
>> - GPIO interrupt fixes
>> - new nodes for drivers merged late (VPU domains)
>
> The VPU power domain and HDMI regulator changes look more like new hardware
> support than bugfixes to me, is that a correct assessment? I.e. is something
> breaking by not having these new DT nodes in the tree one existing hardware?
>
> If it isn't a bugfix, I think I'd rather see it queued up for next merge
> window
You're right, it's new hardware support that was supposed to be
submitted for the late branch (since the drivers were queued up late.)
But I was late for late :) so was hoping since they are DT only and
platform specific, they could go in for -rc1.
If they need to wait for the next merge window, we'll survive.
Kevin
^ permalink raw reply
* [PATCH V5 4/7] OF: properties: Implement get_match_data() callback
From: Sinan Kaya @ 2017-12-04 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJ+fMqrt6Tk8h6v1fSkrBg+GcMxSXK9XCcz3nmYgyguuQ@mail.gmail.com>
On 12/4/2017 11:23 AM, Rob Herring wrote:
> On Fri, Dec 1, 2017 at 10:27 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
>> Now that we have a get_match_data() callback as part of the firmware node,
>> implement the OF specific piece for it.
>>
>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>> ---
>> drivers/of/property.c | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
..
>>
>> +void *of_fwnode_get_match_data(const struct fwnode_handle *fwnode,
>> + const struct device_driver *drv)
>> +{
>> + const struct device_node *node = to_of_node(fwnode);
>> + const struct of_device_id *match;
>> +
>> + if (!node)
>> + return NULL;
>
> of_match_node checks this.
I see a check for the matches argument but not for the node argument.
Am I missing something?
>
>> +
>> + match = of_match_node(drv->of_match_table, node);
>> + if (!match)
>> + return NULL;
>> +
>> + return (void *)match->data;
>
> Don't need a cast here.
I can fix this.
>
> of_device_get_match_data() already does most of this, but getting a
> device ptr from fwnode_handle may not be possible?
I couldn't figure out how to do that. Do you have a suggestion?
I have been looking for examples with no luck.
>
> Rob
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* linux-next: Signed-off-by missing for commit in the arm-soc tree
From: Kevin Hilman @ 2017-12-04 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMh_YT1TH_c0xs614HoK8iAOoaxPofxQtmSuPa8h7HpHKQ@mail.gmail.com>
Olof Johansson <olof@lixom.net> writes:
> Thanks, Stephen. I need to get a similar script going to catch these
> things in our own tree.
>
> Since this was a clean revert, I've redone it myself, carrying over
> descriptions from the pull request and keeping attribution to Kevin.
>
> Kevin; hope this is alright with you. We can revisit if not.
Yes, that's fine with me. Thanks for cleaning up, and sorry I missed
the sign-off.
Kevin
>
> -Olof
>
>
> On Sun, Dec 3, 2017 at 1:32 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> Commit
>>
>> 5f56b7f4854a ("Revert "Merge tag 'scpi-updates-4.15' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux
>> into next/drivers"")
>>
>> is missing a Signed-off-by from its author or committer.
>>
>> Reverts are commits as well and so need an explanation of why they
>> are done and Signed-off-by tags.
>>
>> --
>> Cheers,
>> Stephen Rothwell
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-next" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RFC PATCH] arm64: deactivate saved ttbr when mm is deactivated
From: Mark Rutland @ 2017-12-04 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204165533.GI29619@arm.com>
On Mon, Dec 04, 2017 at 04:55:33PM +0000, Will Deacon wrote:
> On Mon, Dec 04, 2017 at 09:53:26PM +0530, Vinayak Menon wrote:
> > A case is observed where a wrong physical address is read,
> > resulting in a bus error and that happens soon after TTBR0 is
> > set to the saved ttbr by uaccess_ttbr0_enable. This is always
> > seen to happen in the exit path of the task.
> >
> > exception
> > __arch_copy_from_user
> > __copy_from_user
> > probe_kernel_read
> > get_freepointer_safe
> > slab_alloc_node
> > slab_alloc
> > kmem_cache_alloc
> > kmem_cache_zalloc
> > fill_pool
> > __debug_object_init
> > debug_object_init
> > rcuhead_fixup_activate
> > debug_object_fixup
> > debug_object_activate
> > debug_rcu_head_queue
> > __call_rcu
> > ep_remove
> > eventpoll_release_file
> > __fput
> > ____fput
> > task_work_run
> > do_exit
> >
> > The mm has been released and the pgd is freed, but probe_kernel_read
> > invoked from slub results in call to __arch_copy_from_user. At the
> > entry to __arch_copy_from_user, when SW PAN is enabled, this results
> > in stale value being set to ttbr0. May be a speculative fetch aftwerwards
> > is resulting in invalid physical address access.
> >
> > Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
> > ---
> >
> > I have not tested this patch to see if it fixes the problem.
> > Sending it early for comments.
>
> I wonder whether it would be better to avoid restoring the user TTBR0 if
> KERNEL_DS is set.
I think the problem here is that switch_mm() avoids updating the saved ttbr
value when the next mm is init_mm.
If we fixed that up to use the empty zero page (as we write to the real
ttbr0 in this case), I think that solves the problem. Though I agree we
should also avoid restoring the user TTBR for KERNEL_DS uaccess calls.
Example below.
Thanks,
Mark.
---->8----
diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 3257895a9b5e..ef3567ce80b3 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -174,10 +174,15 @@ enter_lazy_tlb(struct mm_struct *mm, struct task_struct *tsk)
static inline void update_saved_ttbr0(struct task_struct *tsk,
struct mm_struct *mm)
{
+ u64 ttbr;
+
if (system_uses_ttbr0_pan()) {
- BUG_ON(mm->pgd == swapper_pg_dir);
- task_thread_info(tsk)->ttbr0 =
- virt_to_phys(mm->pgd) | ASID(mm) << 48;
+ if (mm == &init_mm)
+ ttbr = __pa_symbol(empty_zero_page);
+ else
+ ttbr = virt_to_phys(mm->pgd) | ASID(mm) << 48;
+
+ task_thread_info(tsk)->ttbr0 = ttbr;
}
}
#else
@@ -214,11 +219,9 @@ switch_mm(struct mm_struct *prev, struct mm_struct *next,
* Update the saved TTBR0_EL1 of the scheduled-in task as the previous
* value may have not been initialised yet (activate_mm caller) or the
* ASID has changed since the last run (following the context switch
- * of another thread of the same process). Avoid setting the reserved
- * TTBR0_EL1 to swapper_pg_dir (init_mm; e.g. via idle_task_exit).
+ * of another thread of the same process).
*/
- if (next != &init_mm)
- update_saved_ttbr0(tsk, next);
+ update_saved_ttbr0(tsk, next);
}
#define deactivate_mm(tsk,mm) do { } while (0)
^ permalink raw reply related
* [PATCH v6 01/10] arm64: dts: rockchip: Enable edp disaplay on kevin
From: Heiko Stuebner @ 2017-12-04 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171019034812.13768-2-jeffy.chen@rock-chips.com>
Am Donnerstag, 19. Oktober 2017, 11:48:03 CET schrieb Jeffy Chen:
> Add edp panel and enable related nodes on kevin.
>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> Reviewed-by: Mark Yao <mark.yao@rock-chips.com>
applied for 4.16 with Enric's Tested-tag and after also
seeing a bit of output on the edp.
Thanks
Heiko
^ 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