The Security System is a hardware cryptographic accelerator that support
AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on many Allwinner SoC.
This patch enable the Security System on the Allwinner A20 SoC Device-tree.
Signed-off-by: LABBE Corentin
---
arch/arm/boot/dts/sun7i-a20.dtsi
Add support for the Security System included in Allwinner SoC A20.
The Security System is a hardware cryptographic accelerator that support:
- MD5 and SHA1 hash algorithms
- AES block cipher in CBC/ECB mode with 128/196/256bits keys.
- DES and 3DES block cipher in CBC/ECB mode
Signed-off-by: LABBE
This patch adds documentation for Device-Tree bindings for the Security System
cryptographic accelerator driver.
Signed-off-by: LABBE Corentin
---
Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 +
1 file changed, 9 insertions(+)
create mode 100644 Documentation/devicetree/bi
Signed-off-by: LABBE Corentin
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b4b131a..b678265 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -555,6 +555,12 @@ S: Maintained
F: Documentation/i2c/busses/i2c-ali1563
F: drivers/i2c/b
Hello
This is the driver for the Security System included in Allwinner SoC A20.
The Security System (SS for short) is a hardware cryptographic accelerator that
support AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on others Allwinner SoC:
- A10, A10s, A13, A31 and A33 manual give the s
Hi Brian,
Could you please spend some time help me to review this patch? It has
been more than 1 month and i really hope can get this patch upstream
by end of this month.
Thanks,
Viet Nga
On Mon, Mar 16, 2015 at 4:16 PM, wrote:
> From: VIET NGA DAO
>
> Altera Quad SPI Controller is a soft IP wh
On Sun, Apr 19, 2015 at 02:02:23PM -0700, ali...@she-devel.com wrote:
> From: Alison Chaiken
>
> Create an imx6-sabreauto-weim-nor.dtsi file whose inclusion in
> a DTS file sets GPIO5 to the level at boot that the WEIM-NOR
> device requires. The GPIO is set via the gpio-hogging mechanism.
>
> S
On 04/23/2015 03:15 AM, Jacek Anaszewski wrote:
>> On 21.04.2015 07:50, Vasant Hegde wrote:
>> On 04/20/2015 08:57 PM, Jacek Anaszewski wrote:
>>> Hi Vasant,
>>>
>>
Jacek,
.../...
All the system LEDs can be found in the same regular
path /sys/class/leds/. We don't use LED colors.
On Thu, Apr 16, 2015 at 11:46 AM, Baruch Siach wrote:
> Hi Rob,
>
> On Sat, Mar 28, 2015 at 11:29:39PM +0300, Baruch Siach wrote:
>> On Tue, Mar 24, 2015 at 11:45:16PM -0500, Rob Herring wrote:
>> > On Thu, Mar 19, 2015 at 7:03 AM, Baruch Siach wrote:
>> > > Add two new facts to of_get_next_child
On Mon, Apr 20, 2015 at 9:55 AM, wrote:
> From: Dinh Nguyen
>
> Document "altr,socfpga-cyclone5", "altr,socfpga-arria5", and
> "altr,socfpga-arria10".
>
> Signed-off-by: Dinh Nguyen
Applied for 4.1. Thanks.
Rob
> ---
> Documentation/devicetree/bindings/arm/altera.txt | 14 ++
>
Hi LInus,
As Grant mentioned, here is the 2nd batch of DT changes for 4.1. The
main remaining item here is the endianness bindings and related 8250
driver support. Please pull.
Rob
The following changes since commit 01218bf14ee60d4a2d6c667ebdbba3ae9a7a1d66:
of: Explicitly include linux/types.
Hi Heiko,
2015-04-21 23:56 GMT+09:00 Heiko Stübner :
> Am Dienstag, 21. April 2015, 16:21:27 schrieb Masahiro Yamada:
>> Initial commit for a new SoC family, UniPhier, developed by
>> Socionext Inc. (formerly, System LSI Business Division of
>> Panasonic Corporation).
>>
>> This commit includes a
Initial commit for a new SoC family, UniPhier, developed by
Socionext Inc. (formerly, System LSI Business Division of
Panasonic Corporation).
This commit includes a minimal set of components for booting the
kernel, including SMP support.
Signed-off-by: Masahiro Yamada
---
Changes in v5:
- Mov
This is an initial series for supporting Socionext UniPhier SoCs,
based on ARM Cortex-A9, mainly used for digital TVs, video recorders, etc.
Masahiro Yamada (4):
ARM: UniPhier: add basic support for UniPhier architecture
ARM: multi_v7_defconfig: enable UniPhier SoC family
ARM: dts: UniPhier:
Add UniPhier, a new citizen in the ARM multi platform.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
Initial device trees for UniPhier SoCs: PH1-sLD3, PH1-LD4, PH1-Pro4,
and PH1-sLD8.
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4:
- Add system-bus-controller-misc node instead of uniphier-smp-reg node
Changes in v3:
- License under GPL/X11
- Drop "earlyprintk" kerne
Signed-off-by: Masahiro Yamada
---
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea00017..c0cfc14 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1525,6 +1525,
Signed-off-by: Brian Norris
---
v2:
- fix up some typos
- account for binding changes in previous patches
arch/arm/boot/dts/bcm7445.dtsi | 37 +
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/bcm7445.dtsi b/arch/arm/boot/dts/bcm7445.dtsi
Supports up to two ports which can each be powered on/off and configured
independently.
Signed-off-by: Brian Norris
---
v2:
- stop sharing SATA_TOP_CTRL registers with SATA driver
- kill custom xlate function
drivers/phy/Kconfig| 9 ++
drivers/phy/Makefile | 1 +
d
Pretty straightforward driver, using the nice library-ization of the
generic ahci_platform driver.
Signed-off-by: Brian Norris
---
v2:
- move port enabling into this driver, since the affected registers are in
the SATA_TOP_CTRL block. This means we need to check for the implemented
port
Signed-off-by: Brian Norris
---
v2: no change
.../devicetree/bindings/ata/brcm,sata-brcmstb.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ata/brcm,sata-brcmstb.txt
diff --git a/Documentation/devicetree/bindings/ata/brcm,
For 28nm STB chips, based on BCM7445.
Signed-off-by: Brian Norris
---
v2:
- make each subnode into a provider, so we can use direct phandle references
to them
- drop the 'port-ctrl' register range, since this was shared with the SATA
node
.../bindings/phy/brcm,brcmstb-sata-phy.txt
Hi,
Here are my updates based on everyone's feedback. I'll try to include most of
the changelog info in each patch, but a few summary points for v1 -> v2:
- reworked the PHY DT binding so that we don't need do any custom xlate in the
PHY driver
- moved all handling of the 'SATA_TOP_CTRL' bl
> On Apr 21, 2015, at 07:38, Richard Fitzgerald
> wrote:
>
> Signed-off-by: Richard Fitzgerald
> ---
> Documentation/devicetree/bindings/mfd/arizona.txt |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt
> b/Docum
On 14/04/15 14:37, Sergei Shtylyov wrote:
>
>>> +/* Wait for stopping the hardware TX process */
>>> +ravb_wait(ndev, TCCR, TCCR_TSRQ0 | TCCR_TSRQ1 | TCCR_TSRQ2 |
>>> TCCR_TSRQ3,
>>> + 0);
>>> +
>>> +ravb_wait(ndev, CSR, CSR_TPO0 | CSR_TPO1 | CSR_TPO2 | CSR_TPO3, 0);
>>> +
>>>
Reviewed-by: Scott Branden
Tested-by: Scott Branden
Signed-off-by: Jonathan Richardson
---
drivers/misc/Kconfig | 11 +
drivers/misc/Makefile |1 +
drivers/misc/bcm_cygnus_dte.c | 927
include/linux/bcm_cygnus_dte.h | 99
This patchset includes the Digital Timing Engine (DTE) driver for Cygnus SoC's.
Jonathan Richardson (2):
misc: Add DT binding for cygnus Digital Timing Engine (DTE) driver.
misc: Add initial Digital Timing Engine (DTE) driver for cygnus
.../bindings/arm/bcm/brcm,cygnus-dte.txt |
Reviewed-by: Scott Branden
Tested-by: Scott Branden
Signed-off-by: Jonathan Richardson
---
.../bindings/arm/bcm/brcm,cygnus-dte.txt | 24
1 file changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/bcm/brcm,cygnus-dte.txt
diff --
From: Dmitry Torokhov
Multi-port phys may have per port power supplies. Let's change phy
core to look for supply at the port level when multiple ports are
specified. To keep compatibility with the existing device tree board
descriptions for single-port phys we will continue looking up the
power s
This driver adds support for USB 2.0 host and device phy for
Broadcom's Cygnus chipset. The host controller is connected to
three separate phys and one of the phys (port 2) is connected to
the device controller
Signed-off-by: Arun Ramamurthy
Signed-off-by: Dmitry Torokhov
Reviewed-by: Ray Jui
R
This patchset adds the USB phy driver and documentation
for Broadom's Cygnus chipset. The phy is configurable from device tree
and is capable of both device and host functions. It also provides
a clock and reset to the host controller
History:
v1:
- Included Dmitry Torokhov's patch that addre
Broadcom's Cygnus chip has a USB 2.0 host controller connected to
three separate phys. One of the phs (port 2) is also connectd to
a usb 2.0 device controller
Signed-off-by: Arun Ramamurthy
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
.../bindings/phy/brcm,cygnus-usb-phy.txt |
On 04/23/2015 01:41 AM, David Miller wrote:
Sigh... I'm seeing no way out of that then, only copying. :-(
What exactly is the device's restriction?
The frame data must be aligned on 32-bit boundary.
Any reasonable modern chip allows one of two things.
Either it allows arbitrary
This patch adds support for ARM's juno platform. More
specifically it has definitions for the A53/57 tracers, the
A53/57 cluster funnels, the main funnel and the ETF in
circular buffer mode.
Support for the replicator, TPIU, ETR, CTI, CTM, ATM along with
all the coresight IP blocks found in the S
Adding compatible string for new coresight ETMv4 tracer.
Signed-off-by: Mathieu Poirier
---
Documentation/devicetree/bindings/arm/coresight.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
b/Documentation/devicetree/bindings/arm/coresig
From: Sergei Shtylyov
Date: Thu, 23 Apr 2015 01:34:32 +0300
>Sigh... I'm seeing no way out of that then, only copying. :-(
What exactly is the device's restriction?
Any reasonable modern chip allows one of two things.
Either it allows arbitrary alignment of the start of the TX
frame when D
On 04/23/2015 01:18 AM, David Miller wrote:
Hmm, I've been digging in the net core, and was unable to see where TX
skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
Probably need to print out skb's fields...
NET_IP_ALIGN is for receive, not transmit.
This adds the mailbox driver for the APM X-Gene SoC
V2 change
- Add ACPI support
- use defines for reg offset
Feng Kan (4):
mailbox: add support for APM X-Gene platform mailbox driver
mailbox: xgene: add ACPI support for X-Gene mailbox driver
Documentation: mailbox: Add APM
Add ACPI support for APM X-Gene mailbox driver.
Signed-off-by: Feng Kan
---
drivers/mailbox/mailbox-xgene-slimpro.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mailbox/mailbox-xgene-slimpro.c
b/drivers/mailbox/mailbox-xgene-slimpro.c
index 49370e5..890f95b 100644
---
Add support for APM X-Gene platform mailbox driver.
Signed-off-by: Feng Kan
---
drivers/mailbox/Kconfig | 10 ++
drivers/mailbox/Makefile| 2 +
drivers/mailbox/mailbox-xgene-slimpro.c | 261
3 files changed, 273 insertions(+)
c
This adds the APM X-Gene SLIMpro mailbox device tree node documentation.
Signed-off-by: Feng Kan
---
.../bindings/mailbox/xgene-slimpro-mailbox.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/xgene-slimpro-mailb
Mailbox device tree node for APM X-Gene platform.
Signed-off-by: Feng Kan
---
arch/arm64/boot/dts/apm/apm-storm.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index c8d3e0e..92e7b6b 100644
From: Sergei Shtylyov
Date: Thu, 23 Apr 2015 00:38:56 +0300
> On 04/22/2015 11:42 PM, David Miller wrote:
>
>>> Hmm, I've been digging in the net core, and was unable to see where TX
>>> skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
>>> Probably need to print
From: Sergei Shtylyov
Date: Wed, 22 Apr 2015 23:46:52 +0300
> Hello.
>
> On 04/22/2015 11:42 PM, David Miller wrote:
>
>>> Hmm, I've been digging in the net core, and was unable to see where TX
>>> skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
>>> Probably ne
> On 21.04.2015 07:50, Vasant Hegde wrote:
> On 04/20/2015 08:57 PM, Jacek Anaszewski wrote:
>> Hi Vasant,
>>
>
> Jacek,
>
> Thanks for the review.
You are welcome.
>> Thanks for the update.
>>
>> On 04/20/2015 10:01 AM, Vasant Hegde wrote:
>>> This patch implements LED driver for PowerNV platf
On 04/22/2015 11:42 PM, David Miller wrote:
Hmm, I've been digging in the net core, and was unable to see where TX
skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
Probably need to print out skb's fields...
NET_IP_ALIGN is for receive, not transmit.
But w
On 22/04/15 13:45, Tirdea, Irina wrote:
>
>
>> -Original Message-
>> From: Jonathan Cameron [mailto:ji...@kernel.org]
>> Sent: 18 April, 2015 21:07
>> To: Tirdea, Irina; linux-...@vger.kernel.org; devicetree@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org; Hartmut Knaack; Lars-Peter C
On 22/04/15 12:33, Tirdea, Irina wrote:
>
>
>> -Original Message-
>> From: Jonathan Cameron [mailto:ji...@kernel.org]
>> Sent: 18 April, 2015 19:47
>> To: Tirdea, Irina; linux-...@vger.kernel.org; devicetree@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org; Hartmut Knaack; Lars-Peter C
Hello.
On 04/22/2015 11:42 PM, David Miller wrote:
Hmm, I've been digging in the net core, and was unable to see where TX
skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
Probably need to print out skb's fields...
NET_IP_ALIGN is for receive, not transmit.
From: Sergei Shtylyov
Date: Wed, 22 Apr 2015 23:30:02 +0300
>Hmm, I've been digging in the net core, and was unable to see where TX
>skb's get their NET_IP_ALIGN bytes reserved. Have I missed something?
>Probably need to print out skb's fields...
NET_IP_ALIGN is for receive, not tran
Hello.
On 04/22/2015 06:36 PM, David Miller wrote:
+ if (!ravb_tx_free(ndev, q)) {
+ netif_warn(priv, tx_queued, ndev, "TX FD exhausted.\n");
+ netif_stop_queue(ndev);
+ spin_unlock_irqrestore(&priv->lock, flags);
+
Hallo all,
any updates here? :D
Am 06.04.2015 um 11:04 schrieb Oleksij Rempel:
> changes:
> - v4. As Paul Bolle sugested, fixing License in the header.
>
> Oleksij Rempel (2):
> pinctrl: Add driver for Alphascale asm9260 pinctrl
> pinctrl: asm9260: add pinctrl add device tree bindings docume
A license mismatch is all I spotted.
On Tue, 2015-04-21 at 13:33 +0100, Richard Fitzgerald wrote:
> --- /dev/null
> +++ b/sound/soc/codecs/wm8998.c
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
>
> Mark Rutland hat am 7. April 2015 um 13:29 geschrieben:
>
>
> On Sat, Apr 04, 2015 at 10:40:13PM +0100, Stefan Wahren wrote:
> > Hi,
>
> Hi,
>
> > i'm currently working on drivers (regulator and power switch) for a power
> > subsystem of a ARM9 processor (Freescale i.MX28). There are interrupts
On Wed, Apr 22, 2015 at 06:14:18PM +0200, Ricardo Ribalda Delgado wrote:
> When a resource is initialized via of_platform_populate.
> resource->parent is initialized to NULL via kzalloc.
> (of_platform_populate->of_device_alloc->of_address_to_resource)
>
> If of_platform_depopulate is called later
On Wed, Apr 22, 2015 at 06:14:20PM +0200, Ricardo Ribalda Delgado wrote:
> insert_resource() can fail when the resource added overlaps
> (partially or fully) with another.
>
> Device tree and AMBA devices may contain resources that overlap, so they
> could not call platform_device_add (Revert "of
On Wed, Apr 22, 2015 at 11:14 AM, Ricardo Ribalda Delgado
wrote:
> of_platform_device_create_pdata() was using of_device_add() to create
> the devices, but of_platform_device_destroy was using
> of_platform_device_destroy().
>
> of_device_add(), do not call insert_resource(), which initializes the
platform_device_del only checks the type of the resource in order to
call release_resource.
On the other hand, platform_device_add calls insert_resource for any
resource that has a parent.
Make both code branches balanced.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/base/platform.c | 10
insert_resource() can fail when the resource added overlaps
(partially or fully) with another.
Device tree and AMBA devices may contain resources that overlap, so they
could not call platform_device_add (Revert "of: use platform_device_add"
02bbde7849e68e193cefaa1885fe0df0f03c9fcd )
On the other
of_platform_device_create_pdata() was using of_device_add() to create
the devices, but of_platform_device_destroy was using
of_platform_device_destroy().
of_device_add(), do not call insert_resource(), which initializes the
parent field of the resource structure, needed by release_resource(),
call
When a resource is initialized via of_platform_populate.
resource->parent is initialized to NULL via kzalloc.
(of_platform_populate->of_device_alloc->of_address_to_resource)
If of_platform_depopulate is called later, resource->parent is
accessed (Offset 0x30 of address 0), causing a kernel error.
of_platform_depopulate can lead to a kernel error when calling
release_resource()
of_platform_depopulate()
of_platform_device_destroy()
platform_device_unregister(platform_device *pdev)
platform_device_del(platform_device *pdev)
for (i = 0; i < pdev->num_resour
From: MITSUHIRO KIMURA
Date: Wed, 22 Apr 2015 05:04:13 +
> Hello Sergei.
>
> (2015/04/15 6:37:28), Sergei Shtylyov wrote:
>> >> + if (!ravb_tx_free(ndev, q)) {
>> >> + netif_warn(priv, tx_queued, ndev, "TX FD exhausted.\n");
>> >> + netif_stop_queue(n
On Wed, Apr 22, 2015 at 11:11:34AM +0800, Pi-Cheng Chen wrote:
[..]
> >> +config ARM_MT8173_CPUFREQ
> >> + bool "Mediatek MT8173 CPUFreq support"
> >> + depends on ARCH_MEDIATEK && REGULATOR
> >
> > I think you want to 'select REGULATOR' here; because REGULATOR isn't
> > a user-visible opti
On Wed, Apr 22, 2015 at 4:12 AM, Mark Rutland wrote:
> The reg property is meainingless, so just remove it and give the clocks
> different names.
I will change at V7 version.
best regards
Frank Li
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message t
A copy to the devicetree list if something'd be controversial
about this uncontroversial change.
Linus
-- Forwarded message --
From: Linus Walleij
Date: Mon, Apr 20, 2015 at 2:59 PM
Subject: [PATCH 13/13] coresight: document the bindings for the ATCLK
Put in a blurb in the dev
> -Original Message-
> From: linux-iio-ow...@vger.kernel.org
> [mailto:linux-iio-ow...@vger.kernel.org] On Behalf Of Jonathan Cameron
> Sent: 18 April, 2015 21:09
> To: Tirdea, Irina; linux-...@vger.kernel.org; devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; Hartmut Knaack
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 18 April, 2015 21:07
> To: Tirdea, Irina; linux-...@vger.kernel.org; devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; Hartmut Knaack; Lars-Peter Clausen; Peter
> Meerwald; Rob Herring; Pawel Mol
Hi Wolfram,
> On Apr 14, 2015, at 16:27 , Wolfram Sang wrote:
>
> Hi Pantelis,
>
> thanks for your prompt reply. Unfortunately, I had to wait until I could
> access the test system again.
>
[snip]
Sorry for the non-prompt reply; but just for kicks, can you try the attached
patch?
I have a
Am Donnerstag, 16. April 2015, 11:09:58 schrieb Archit Taneja:
> On 04/09/2015 02:13 PM, Thierry Reding wrote:
> > On Thu, Feb 12, 2015 at 02:01:34PM +0800, Liu Ying wrote:
> > [...]
> >
> >> diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c
> >> b/drivers/gpu/drm/bridge/dw_mipi_dsi.c>
> > [...]
> -Original Message-
> From: Jonathan Cameron [mailto:ji...@kernel.org]
> Sent: 18 April, 2015 19:47
> To: Tirdea, Irina; linux-...@vger.kernel.org; devicetree@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; Hartmut Knaack; Lars-Peter Clausen; Peter
> Meerwald; Rob Herring; Pawel Mol
This patch add device tree bindings for the pdata needed to configure
the Accessory Detect Mode select when Headphone detection.
Signed-off-by: Inha Song
---
Documentation/devicetree/bindings/mfd/arizona.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindi
This patch add support for select accessory detect mode to HPDETL or HPDETR.
Arizona provides a headphone detection circuit on the HPDETL and HPDETR pins
to measure the impedance of an external load connected to the headphone.
Depending on board design, headphone detect pins can change to HPDETR o
This set of patches adds support for select accessory detect mode to HPDETL or
HPDETR.
Changes in v3:
- Set the hpdet_channel default value to HPDETL If the value is unknown or
invalid.
Changes in v2:
- Use the value in pdata instead of hpdet_channel in extcon_info.
- Wrap arizona_extcon_
On Tue, Apr 21, 2015 at 01:33:51PM +0100, Richard Fitzgerald wrote:
> + switch (arizona->type) {
> + case WM8998:
> + case WM1814:
> + /* Some bits are shifted on WM8998,
> + * rearrange to match the standard bit layout
> + */
> + val[0
On Tue, Apr 21, 2015 at 01:33:50PM +0100, Richard Fitzgerald wrote:
> Adds convenience defines for declaring a gain control that
> has an input mux. These block are functionally equivalent to
> the existing mixer blocks but only have a single input.
...can only have a single input active at once.
On Tue, Apr 21, 2015 at 01:33:53PM +0100, Richard Fitzgerald wrote:
> Signed-off-by: Richard Fitzgerald
Acked-by: Mark Brown
signature.asc
Description: Digital signature
On Tue, Apr 21, 2015 at 01:33:55PM +0100, Richard Fitzgerald wrote:
> +static int wm8998_in1mux_ev(struct snd_soc_dapm_widget *w,
> + struct snd_kcontrol *kcontrol,
> + int event)
> +{
> + struct snd_soc_codec *codec = snd_soc_dapm_to_cod
Regards,
Igal Liberman.
> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, April 21, 2015 3:52 AM
> To: Liberman Igal-B31950
> Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org; Tang
> Yuantian-B29983
> Subject: Re: [v3] dt/bindings: qoriq-clock: Add binding for
Am Dienstag, den 03.03.2015, 10:35 +0800 schrieb Shawn Guo:
> On Mon, Feb 23, 2015 at 06:40:11PM +0100, Philipp Zabel wrote:
> > The i.MX6 contains a power controller that controls power gating and
> > sequencing for the SoC's power domains.
> >
> > Signed-off-by: Philipp Zabel
>
> The patch (se
On 04/22/2015 06:19 PM, Richard Fitzgerald wrote:
> On Wed, Apr 22, 2015 at 02:53:42PM +0900, Chanwoo Choi wrote:
>> Hi Richard,
>>
>>> @@ -1176,6 +1182,11 @@ static int arizona_extcon_probe(struct
>>> platform_device *pdev)
>>> break;
>>> }
>>> break;
>
On Wed, Apr 08, 2015 at 06:23:44PM +0100, Lee Jones wrote:
> On Wed, 08 Apr 2015, Maxime Ripard wrote:
>
> > On Wed, Apr 08, 2015 at 11:38:32AM +0100, Lee Jones wrote:
> > > On Wed, 08 Apr 2015, Maxime Ripard wrote:
> > >
> > > > On Wed, Apr 08, 2015 at 09:14:50AM +0100, Lee Jones wrote:
> > > >
On Wed, Apr 22, 2015 at 02:53:42PM +0900, Chanwoo Choi wrote:
> Hi Richard,
>
> > @@ -1176,6 +1182,11 @@ static int arizona_extcon_probe(struct
> > platform_device *pdev)
> > break;
> > }
> > break;
> > + case WM8998:
> > + case WM1814:
> > +
On Tue, Apr 21, 2015 at 08:34:45PM +0100, Zhi Li wrote:
> >>> +
> >>> + clocks {
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> +
> >>> + ckil: clock@0 {
> >>> + compatible = "fixed-clock";
> >>> +
On Tue, Apr 21, 2015 at 07:24:54PM +0100, Kevin Hilman wrote:
> On Thu, Apr 16, 2015 at 9:10 AM, Lorenzo Pieralisi
> wrote:
>
> [...]
>
> > This patch sets the maximum number of static CPUidle drivers allowed to
> > two, since it is hard to foresee systems with more than two sets of CPUs
> > hav
Hi Joshua,
On Tue, Apr 21, 2015 at 8:20 AM, Joshua Scott
wrote:
> I have a question about the order in which devices are initialized.
>
> The simpler case is this: A device X needs to be taken out of reset by
> another device Y before it can be used.
>
> To get this to work, one option is to modi
On Sat, Jan 24, 2015 at 09:16:29AM +0200, Pantelis Antoniou wrote:
> Mark (and unmark) device nodes with the POPULATE flag as appropriate.
> This is required to avoid multi probing when using I2C and device
> overlays containing a mux.
> This patch is also more careful with the release of the adapt
On 04/09/2015 12:35 PM, Peter Ujfalusi wrote:
> Vinod: is it OK if I send the Documnetation/dmanegine/ update a bit later when
> I have finished it?
>
> Changes since v4:
> - Comments from Maxime Ripard addressed:
> - long line fixed in of-dma.c
> - node leaks has been fixed in ti-dma-crossbar
>
On Tuesday 21 April 2015 16:02:19 Eric Anholt wrote:
> > Hard to know. Does anything reference BCM2835_PERIPH_VIRT? Does it work
> > if you remove it?
> Well, that's clear enough. It dies early with:
>
> Uncompressing Linux... done, booting the kernel.
> [0.00] Booting Linux on physical CP
89 matches
Mail list logo
