* [GIT PULL] non-urgent omap fixes for v3.17 merge window
From: Tony Lindgren @ 2014-07-24 11:51 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:
Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.17/fixes-not-urgent-signed
for you to fetch changes up to 00e4e5b5b0339bde4b0ecb23d7d7969a3bebd44d:
Merge remote-tracking branch 'roger/for-v3.17/gpmc-omap' into omap-for-v3.17/fixes-not-urgent (2014-07-15 00:24:39 -0700)
----------------------------------------------------------------
Fixes for omaps that were not considered urgent enough for the
rc series. Mostly a fix for GPMC allocation and omap5 ABB
(Adaptive Body Bias).
----------------------------------------------------------------
Andrii.Tseglytskyi (1):
ARM: dts: OMAP5: Add device nodes for ABB
Nicholas Krause (1):
omap16xx: Removes fixme no longer needed in ocpi_enable()
Rickard Strandqvist (1):
ARM: omap2+: usb-tusb6010.c: Cleaning up variable is set more than once
Rostislav Lisovy (1):
ARM: omap2+: gpmc-nand: Use dynamic platform_device_alloc()
Tony Lindgren (1):
Merge remote-tracking branch 'roger/for-v3.17/gpmc-omap' into omap-for-v3.17/fixes-not-urgent
arch/arm/boot/dts/omap5.dtsi | 60 +++++++++++++++++++++++++++++
arch/arm/mach-omap1/ocpi.c | 1 -
arch/arm/mach-omap2/gpmc-nand.c | 79 ++++++++++++++++++--------------------
arch/arm/mach-omap2/usb-tusb6010.c | 1 -
4 files changed, 97 insertions(+), 44 deletions(-)
^ permalink raw reply
* [GIT PULL] omap soc changes for v3.17 merge window
From: Tony Lindgren @ 2014-07-24 11:58 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 3db53918e306d3960bf9e12eea8b2fd3f7d0fd62:
Merge tag 'for-v3.17/omap-clock-a' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.17/soc (2014-07-21 00:35:38 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.17/soc-new
for you to fetch changes up to 3965f5ba0489c01f419216c8909965b9a6a39388:
Merge branch 'omap-for-v3.17/mailbox' into omap-for-v3.17/soc (2014-07-23 01:26:02 -0700)
----------------------------------------------------------------
SoC related changes for omaps for v3.17 merge window:
- Add device tree and hwmod data for various devices
for new SoCs
- Remove legacy mailbox hwmod data that's no longer
needed for SoCs that are DT only. Note that this may
cause a minor merge conflict in mach-omap2/devices.c
with omap_init_mbox() and omap_init_hdmi_audio(), both
are legacy code that is getting removed
----------------------------------------------------------------
Kishon Vijay Abraham I (2):
arm: dra7xx: Add hwmod data for pcie1 phy and pcie2 phy
arm: dra7xx: Add hwmod data for pcie1 and pcie2 subsystems
Lokesh Vutla (1):
ARM: DRA7: hwmod: Add data for RTC
Mugunthan V N (1):
arm: dra7xx: Add hwmod data for MDIO and CPSW
Nishanth Menon (2):
ARM: OMAP2+: DMA: remove requirement of irq for platform-dma driver
ARM: DRA7: hwmod: remove interrupts for DMA
Roger Quadros (1):
ARM: DRA7: hwmod: Add OCP2SCP3 module
Sathya Prakash M R (1):
ARM: AM43xx: hwmod: add DSS hwmod data
Suman Anna (10):
ARM: dts: OMAP2+: Add mailbox fifo and user information
ARM: dts: OMAP4: Add mailbox node
ARM: dts: AM33xx: Add mailbox node
ARM: dts: AM4372: Correct mailbox node data
ARM: dts: DRA7: Add mailbox nodes
ARM: DRA7: hwmod_data: Add mailbox hwmod data
ARM: OMAP2+: Avoid mailbox legacy device creation for DT-boot
ARM: OMAP2: hwmod_data: Remove legacy mailbox data and addrs
ARM: OMAP4: hwmod_data: Remove legacy mailbox addrs
ARM: AM33xx: hwmod_data: Remove legacy mailbox addrs
Tony Lindgren (2):
Merge tag 'for-v3.17/omap-hwmod-a' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.17/soc
Merge branch 'omap-for-v3.17/mailbox' into omap-for-v3.17/soc
arch/arm/boot/dts/am33xx.dtsi | 9 +
arch/arm/boot/dts/am4372.dtsi | 3 -
arch/arm/boot/dts/dra7.dtsi | 117 +++++
arch/arm/boot/dts/omap2420.dtsi | 2 +
arch/arm/boot/dts/omap2430.dtsi | 2 +
arch/arm/boot/dts/omap3.dtsi | 2 +
arch/arm/boot/dts/omap4.dtsi | 9 +
arch/arm/boot/dts/omap5.dtsi | 2 +
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/cm2_7xx.h | 4 +
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/dma.c | 3 +
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 14 -
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 13 -
.../omap_hwmod_2xxx_3xxx_interconnect_data.c | 9 -
.../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 40 --
.../omap_hwmod_33xx_43xx_interconnect_data.c | 10 -
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 100 ++++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 -
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 574 ++++++++++++++++++++-
arch/arm/mach-omap2/omap_hwmod_common_data.h | 1 -
.../mach-omap2/omap_hwmod_common_ipblock_data.c | 55 ++
arch/arm/mach-omap2/prcm43xx.h | 1 +
arch/arm/mach-omap2/prm7xx.h | 4 +
arch/arm/plat-omap/dma.c | 5 +-
include/linux/omap-dma.h | 1 +
26 files changed, 881 insertions(+), 112 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_ipblock_data.c
^ permalink raw reply
* [PATCH 4/6] net/macb: add RX checksum offload feature
From: Cyrille Pitchen @ 2014-07-24 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406069908.3363.7.camel@edumazet-glaptop2.roam.corp.google.com>
Le 23/07/2014 00:58, Eric Dumazet a ?crit :
> On Tue, 2014-07-22 at 18:27 +0200, Cyrille Pitchen wrote:
>> Le 18/07/2014 17:36, Eric Dumazet a ?crit :
>>> On Fri, 2014-07-18 at 16:21 +0200, Cyrille Pitchen wrote:
>>>> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
>>>> ---
>>>> drivers/net/ethernet/cadence/macb.c | 29 ++++++++++++++++++++++++++++-
>>>> drivers/net/ethernet/cadence/macb.h | 2 ++
>>>> 2 files changed, 30 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
>>>> index 9bdcd1b..6acd6e2 100644
>>>> --- a/drivers/net/ethernet/cadence/macb.c
>>>> +++ b/drivers/net/ethernet/cadence/macb.c
>>>> @@ -766,6 +766,8 @@ static int gem_rx(struct macb *bp, int budget)
>>>>
>>>> skb->protocol = eth_type_trans(skb, bp->dev);
>>>> skb_checksum_none_assert(skb);
>>>> + if (bp->dev->features & NETIF_F_RXCSUM)
>>>> + skb->ip_summed = CHECKSUM_UNNECESSARY;
>>>>
>>>
>>>
>>> Really ?
>>>
>>> If this is what you meant, this deserves a big and fat comment.
>>>
>>>
>>>
>> Hi Eric,
>>
>> Isn't it the proper way to do? According to Cadence documentation
>> about RX checksum offload:
>> "If any of the checksums (IP, TCP or UDP) are verified incorrect by
>> the GEM, the packet is discarded."
>>
>> If I understand, when RX checksum offload is enabled setting bit 24 of
>> the Network Configuration Register, the driver only receives RX frames
>> with correct checksum. Then it tells the kernel that there's no need
>> to verify the checksum again in software. This is done setting
>> skb->ip_summed to CHECKSUM_UNNECESSARY. Intel e1000 driver does the
>> same in e1000_rx_checksum() function.
>>
>> Also bit 24 of the Network Configuration Register is updated by
>> macb_open() and macb_set_features() so it always matches the state of
>> NETIF_F_RXCSUM flag in dev->features, once the network interface is
>> up. That's why I'd rather read from dev->features than read from
>> register.
>>
>> Did I make a mistake? Is it the kind of comment you expect to be
>> added?
>>
>> Regards,
>
> Usually, frames are not discarded, and a bit is present in rx descriptor
> to tell us if (TCP) checksum was validated by the NIC
>
> We want tcpdump to get a copy of corrupted TCP frames, even if TCP stack
> drops them later.
>
> If this NIC drops incorrect frames, I am afraid we cant use this RX
> offload at all.
>
>
>
OK thanks for your comments. In the next series of patches I'll allow RX
checksum offload only when promiscuous mode is disabled. Also I'll check the
status returned by the GEM through the buffer descriptor.
Regards,
Cyrille
^ permalink raw reply
* [PATCHv3 11/16] cpuidle: mvebu: rename the driver from armada-370-xp to mvebu-v7
From: Jason Cooper @ 2014-07-24 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53D0CEA3.1050204@linaro.org>
On Thu, Jul 24, 2014 at 11:15:15AM +0200, Daniel Lezcano wrote:
> On 07/23/2014 03:00 PM, Thomas Petazzoni wrote:
> >From: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >
> >This driver will be able to manage the cpuidle for more SoCs than just
> >Armada 370 and XP. It will also support Armada 38x and potentially
> >other SoC of the Marvell Armada EBU family. To take this into account,
> >this patch renames the driver and its symbols.
> >
> >It also changes the driver name from cpuidle-armada-370-xp to
> >cpuidle-armada-xp, because separate platform drivers will be
> >registered for the other SoC types. This change must be done
> >simultaneously in the cpuidle driver and in the PMSU code in order to
> >remain bisectable.
> >
> >Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Thanks for getting on top of this so quickly after returning from
vacation!
thx,
Jason.
^ permalink raw reply
* [PATCH 0/2] serial: st-asc: Couple of fixes
From: Maxime COQUELIN @ 2014-07-24 12:02 UTC (permalink / raw)
To: linux-arm-kernel
This series contains two fixes for ST's ASC driver.
The first issue addressed is a Kernel BUG when using the console on a different
ASC instance than the one being probed.
The second one is an overflow during buad rate calculation when requested rate
is higher than about 262Kbauds.
Maxime Coquelin (2):
serial: st-asc: Don't call BUG in asc_console_setup()
serial: st-asc: Fix overflow in baudrate calculation
drivers/tty/serial/st-asc.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] serial: st-asc: Don't call BUG in asc_console_setup()
From: Maxime COQUELIN @ 2014-07-24 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406203376-18203-1-git-send-email-maxime.coquelin@st.com>
In order to prevent an asc instance to be used as early console, BUG_ON is
used on either mapbase or membase being NULL.
Problem is that this condition is also true when we set console to be a ttyASx
different to the first asc instance being probed.
Instead of calling BUG_ON, it now returns -ENXIO when either mapbase or
membase is NULL.
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
---
drivers/tty/serial/st-asc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index f48b1cc..2369bc0 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -849,7 +849,8 @@ static int asc_console_setup(struct console *co, char *options)
* this to be called during the uart port registration when the
* driver gets probed and the port should be mapped at that point.
*/
- BUG_ON(ascport->port.mapbase == 0 || ascport->port.membase == NULL);
+ if (ascport->port.mapbase == 0 || ascport->port.membase == NULL)
+ return -ENXIO;
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] serial: st-asc: Fix overflow in baudrate calculation
From: Maxime COQUELIN @ 2014-07-24 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406203376-18203-1-git-send-email-maxime.coquelin@st.com>
In the current calculation, if the required baud rate is above 262143,
we get an overflow.
This patch uses a 64bits variable to do the maths.
Also, we remove the '+1' to avoid a divide by zero if the input clock
rate is something unexpected.
Indeed, if the input clock rate is zero, it is preferable to be notified,
since the UART won't work anyway.
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
---
drivers/tty/serial/st-asc.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
index 2369bc0..7ac9902 100644
--- a/drivers/tty/serial/st-asc.c
+++ b/drivers/tty/serial/st-asc.c
@@ -533,12 +533,12 @@ static void asc_set_termios(struct uart_port *port, struct ktermios *termios,
* ASCBaudRate = ------------------------
* inputclock
*
- * However to keep the maths inside 32bits we divide top and
- * bottom by 64. The +1 is to avoid a divide by zero if the
- * input clock rate is something unexpected.
+ * To keep maths inside 64bits, we divide inputclock by 16.
*/
- u32 counter = (baud * 16384) / ((port->uartclk / 64) + 1);
- asc_out(port, ASC_BAUDRATE, counter);
+ u64 dividend = (u64)baud * (1 << 16);
+
+ do_div(dividend, port->uartclk / 16);
+ asc_out(port, ASC_BAUDRATE, dividend);
ctrl_val |= ASC_CTL_BAUDMODE;
}
--
1.9.1
^ permalink raw reply related
* [PATCHv3 00/16] cpuidle for Marvell Armada 370 and 38x
From: Jason Cooper @ 2014-07-24 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406120453-29291-1-git-send-email-thomas.petazzoni@free-electrons.com>
Thomas, all,
On Wed, Jul 23, 2014 at 03:00:37PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> Here comes the third version of the cpuidle support for Armada 370 and
> Armada 38x.
>
> We are hoping to see this patch series merged for 3.17.
>
> Most patches are touching only arch/arm/mach-mvebu/ code so they
> should be handled by the mvebu maintainers. However, patches 11-13 are
> touching the mvebu cpuidle driver, with a possible issue on patch 11,
> which touches both the cpuidle driver and the mach-mvebu code in order
> to rename the driver without breaking functionality (if needed, we can
> decide to split the commits, it would break functionality temporarly,
> but not buildability).
>
> Changes since v2
> ================
>
> * According to the discussion with Daniel Lezcano (cpuidle
> maintainer) and Arnd Bergmann, changed the cpuidle-mvebu-v7 driver
> to actually register three separate cpuidle platform driver, one
> per-SoC. This way, we don't need special platform data to convey
> the SoC type being used, as this information is already available
> by looking at the driver name.
>
> This change impacts the patches "cpuidle: mvebu: rename the driver
> from armada-370-xp to mvebu-v7", "cpuidle: mvebu: add Armada 370
> support", "cpuidle: mvebu: add Armada 38x support", "ARM: mvebu:
> add cpuidle support for Armada 370" and "ARM: mvebu: add cpuidle
> support for Armada 38x". Other patches are unchanged. The patch
> "cpuidle: mvebu: make the cpuidle driver capable of handling
> multiple SoCs" was no longer needed, so it has been removed.
>
...
> Gregory CLEMENT (14):
> ARM: mvebu: split again armada_370_xp_pmsu_idle_enter() in PMSU code
> ARM: mvebu: sort the #include of pmsu.c in alphabetic order
> ARM: mvebu: add a common function for the boot address work around
> ARM: mvebu: use the common function for Armada 375 SMP workaround
> ARM: mvebu: rename the armada_370_xp symbols to mvebu_v7 in pmsu.c
> ARM: mvebu: make the cpuidle initialization more generic
> ARM: mvebu: use a local variable to store the resume address
> ARM: mvebu: make the snoop disabling optional in
> mvebu_v7_pmsu_idle_prepare()
> ARM: mvebu: export the SCU address
> ARM: mvebu: add CA9 MPcore SoC Controller node
> cpuidle: mvebu: rename the driver from armada-370-xp to mvebu-v7
> ARM: mvebu: add cpuidle support for Armada 370
> ARM: mvebu: add cpuidle support for Armada 38x
> ARM: mvebu: defconfig: enable cpuidle support in mvebu_v7_defconfig
>
> Thomas Petazzoni (2):
> cpuidle: mvebu: add Armada 370 support
> cpuidle: mvebu: add Armada 38x support
>
> .../bindings/arm/armada-380-mpcore-soc-ctrl.txt | 14 ++
> arch/arm/boot/dts/armada-38x.dtsi | 5 +
> arch/arm/configs/mvebu_v7_defconfig | 2 +
> arch/arm/mach-mvebu/armada-370-xp.h | 1 -
> arch/arm/mach-mvebu/board-v7.c | 9 +-
> arch/arm/mach-mvebu/common.h | 2 +
> arch/arm/mach-mvebu/headsmp-a9.S | 15 --
> arch/arm/mach-mvebu/platsmp-a9.c | 42 +---
> arch/arm/mach-mvebu/platsmp.c | 2 +-
> arch/arm/mach-mvebu/pmsu.c | 273 ++++++++++++++++++---
> arch/arm/mach-mvebu/pmsu.h | 5 +
> arch/arm/mach-mvebu/pmsu_ll.S | 36 +++
> arch/arm/mach-mvebu/system-controller.c | 31 +++
> drivers/cpuidle/Kconfig.arm | 12 +-
> drivers/cpuidle/Makefile | 2 +-
> drivers/cpuidle/cpuidle-armada-370-xp.c | 93 -------
> drivers/cpuidle/cpuidle-mvebu-v7.c | 150 +++++++++++
> 17 files changed, 500 insertions(+), 194 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt
> delete mode 100644 drivers/cpuidle/cpuidle-armada-370-xp.c
> create mode 100644 drivers/cpuidle/cpuidle-mvebu-v7.c
Whole series, except 10 (went to mvebu/dt), and 16 (went to
mvebu/defconfig) applied to mvebu/soc-cpuidle. Patches 11 to 13 applied
with Daniel's Ack.
It'll be in -next tonight.
thx,
Jason.
^ permalink raw reply
* [GIT PULL] Few regression fixes for omaps for v3.16-rc series
From: Arnd Bergmann @ 2014-07-24 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140724114348.GA29045@atomide.com>
On Thursday 24 July 2014 04:43:49 Tony Lindgren wrote:
> Two regression fixes for omaps and one fix for device signaling:
>
> - L2 cache regression fix for a warning about trying to access
> a read-only register
>
> - GPMC ECC software fallback regression fix for omap3
>
> - Fix for dra7 pinctrl pull-up direction that causes signal issues
> for anybody trying to use the internal pull up or down
>
Merged into the fixes branch, thanks!
Arnd
^ permalink raw reply
* [PATCHv3 00/16] cpuidle for Marvell Armada 370 and 38x
From: Thomas Petazzoni @ 2014-07-24 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140724120349.GT23220@titan.lakedaemon.net>
Dear Jason Cooper,
On Thu, 24 Jul 2014 08:03:49 -0400, Jason Cooper wrote:
> > .../bindings/arm/armada-380-mpcore-soc-ctrl.txt | 14 ++
> > arch/arm/boot/dts/armada-38x.dtsi | 5 +
> > arch/arm/configs/mvebu_v7_defconfig | 2 +
> > arch/arm/mach-mvebu/armada-370-xp.h | 1 -
> > arch/arm/mach-mvebu/board-v7.c | 9 +-
> > arch/arm/mach-mvebu/common.h | 2 +
> > arch/arm/mach-mvebu/headsmp-a9.S | 15 --
> > arch/arm/mach-mvebu/platsmp-a9.c | 42 +---
> > arch/arm/mach-mvebu/platsmp.c | 2 +-
> > arch/arm/mach-mvebu/pmsu.c | 273 ++++++++++++++++++---
> > arch/arm/mach-mvebu/pmsu.h | 5 +
> > arch/arm/mach-mvebu/pmsu_ll.S | 36 +++
> > arch/arm/mach-mvebu/system-controller.c | 31 +++
> > drivers/cpuidle/Kconfig.arm | 12 +-
> > drivers/cpuidle/Makefile | 2 +-
> > drivers/cpuidle/cpuidle-armada-370-xp.c | 93 -------
> > drivers/cpuidle/cpuidle-mvebu-v7.c | 150 +++++++++++
> > 17 files changed, 500 insertions(+), 194 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt
> > delete mode 100644 drivers/cpuidle/cpuidle-armada-370-xp.c
> > create mode 100644 drivers/cpuidle/cpuidle-mvebu-v7.c
>
> Whole series, except 10 (went to mvebu/dt), and 16 (went to
> mvebu/defconfig) applied to mvebu/soc-cpuidle. Patches 11 to 13 applied
> with Daniel's Ack.
>
> It'll be in -next tonight.
Great, thanks a lot!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Jason Cooper @ 2014-07-24 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723234256.GN23220@titan.lakedaemon.net>
Benoit,
> On Thu, Jul 24, 2014 at 01:29:09AM +0200, Andrew Lunn wrote:
> >
> > We should not really leave the i2c compatibility string as it is.
> >
If you were to apply
ed2d859119f9 ARM: mvebu: Fix broken SoC ID detection
And then remove the -a0 i2c compatible string, does your board boot?
The referenced patch has been in mainline since v3.16-rc3, so you could
just try that kernel w/o the compatible string.
thx,
Jason.
^ permalink raw reply
* [PATCH v11 0/2] Add support for the Allwinner A31 DMA Controller
From: Maxime Ripard @ 2014-07-24 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405626376-471-1-git-send-email-maxime.ripard@free-electrons.com>
Vinod, Dan,
On Thu, Jul 17, 2014 at 09:46:14PM +0200, Maxime Ripard wrote:
> Hi,
>
> This patchset adds support for the DMA controller found in the
> Allwinner A31 and A23 SoCs.
>
> This has been tested using the newly introduced SPI driver on an A31
> EVK. Support for DMA-driven SPI transfers will be the subject of
> another patch serie.
>
> This has been around for around 5 monthes now, and didn't get any
> review but nitpicks for three versions, so I feel like it could be
> merged quite quickly.
Ok, so, who should I bribe to get this merged?
The first version was posted on the 2/24, we're at v11 already, and I
only got a single mail from either one of you.
Don't get me wrong, I'd be ok to make any change you deemed necessary,
but in order to do so, I at least have to get a sign of life from you,
and so far, you've both always been MIA.
We're pretty much in the same situation for the other DMA driver
Emilio has been sending for over a month now, that he is doing as part
as a GSoC for the Linux Foundation, with not a single maintainer
review so far.
I'm getting quite tired of this honestly, and I'm not sure it sends
the right message to the hobbyists and companies that try to get
things right by contributing.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140724/48ac8d0a/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Gregory CLEMENT @ 2014-07-24 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140723231535.GK23220@titan.lakedaemon.net>
On 24/07/2014 01:15, Jason Cooper wrote:
> On Thu, Jul 24, 2014 at 01:11:12AM +0200, Benoit Masson wrote:
>> Le 24 juil. 2014 ? 00:58, Andrew Lunn <andrew@lunn.ch> a ?crit :
>>
>>>> For the marvell,mv78230-a0-i2c unfortunately i've spend 3 hours
>>>> trying to understand this but it only works with this on the
>>>> ix4-300d :(. There was multiple patch around this and maybe one
>>>> broke the auto-detect part of this, I've tried compiling with some
>>>> 3.10 or lower kernel but no luck here I still have to put this a0
>>>> option.
>>>
>>> Lets first confirm you have an a0 SoC.
>>>
>>> At boot time, it should print:
>>>
>>> pr_info("MVEBU SoC ID=0x%X, Rev=0x%X\n", soc_dev_id, soc_rev);
>>>
>>> What revision do you have?
>>>
>>> If the auto detect code really is broken, Gregory will likely take a
>>> look.
>>
>> I sure do,
>>
>> confirmed by u-boot output below:
>>
>> U-Boot 2009.08 (Mar 04 2013 - 11:13:04) Marvell version: 2.3.2 PQ
>> U-Boot Addressing:
>> Code:..00600000:006BFFF0
>> BSS:..00708EC0
>> Stack:..0x5fff70
>> PageTable:.0x8e0000
>> Heap address:.0x900000:0xe00000
>> Board: DB-78230-BP rev 2.0 Wistron
>> SoC: MV78230 A0
>>
>> From kernel I get:
>>
>> mvebu-soc-id: MVEBU SoC ID=0x7823, Rev=0x1
>
> Well, isn't that a peach? :) Gregory?
A peach?? For me it is either a fruit or a princess, so I am puzzled!
Well about the issue, we patch the device tree for the i2c quirk only for
the openblock AX3. If I remember well it was because the device tree was already
written for this board before we found there was an issue with the A0 version of the
CPU. The rule was that for new boards then they have to set the marvell,mv78230-a0-i2c
compatible string. I also didn't expect that we found "new" product using the A0 version.
We have 3 options now:
- remove the check on the openblock AX3 board and always try to apply the quirck for A0 version
- add a check for this new board in the mvebu_dt_init function
- let the compatible string marvell,mv78230-a0-i2c in this dts
I would prefer the option 1 but I fear that Arnd would prefer the 2 other options.
Gregory
>
> thx,
>
> Jason.
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 1/3] usb: host: st-hcd: Add USB HCD support for STi SoCs
From: Peter Griffin @ 2014-07-24 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11018717.Ey5qEJxGNJ@wuerfel>
Hi Arnd,
Thanks for reviewing, see my comments below: -
> Unfortunately, this seems to be done in a rather strange way,
> I suspect you'll have to start over, but I'll let Alan and Greg
> weigh in.
>
> > +
> > +struct st_hcd_dev {
> > + int port_nr;
> > + struct platform_device *ehci_device;
> > + struct platform_device *ohci_device;
> > + struct clk *ic_clk;
> > + struct clk *ohci_clk;
> > + struct reset_control *pwr;
> > + struct reset_control *rst;
> > + struct phy *phy;
> > +};
>
> The way you do this apparently is to create a device that encapsulates
> the OHCI and the EHCI and then goes on to create child devices that
> are bound to the real drivers.
Yes, although this isn't the first driver to take that approach USB_HCD_BCMA
(bcma-hcd.c) and USB_HCD_SSB (ssb-hcd.c) do much the same thing.
>
> The way it should be done however is to put the two host controllers
> into DT directly and describe their resources (phy, clock, reset, ...)
> using the DT bindings for those.
I'm of course happy to change it if required. I see looking through that a lot
of other platforms do it the way you describe with a
ehci-<platname>.c and ohci-<platname>.c
>
> Depending on what kind of special requirements the ST version has,
> this can be done either by using the generic ohci/ehci bindings
> with extensions where necessary, or by creating a new binding and
> new driver files that use 'ohci_init_driver'/'ehci_init_driver'
> to inherit from the common code.
>
> The first of the two approaches is preferred.
We don't have anything particularly special, just a couple of reset lines,
clock, phy, etc.
>
> > + pdev->dev.parent = &parent->dev;
> > + pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> > + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>
> This is something we shouldn't ever do these days, the DMA settings
> should come directly from DT without driver interaction.
Ok, I'll wait to hear the outcome of Greg/Alans views before either fixing
it or starting over.
regards,
Peter.
^ permalink raw reply
* [alsa-devel] DMA engine API issue
From: Lars-Peter Clausen @ 2014-07-24 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <28702317.aD0C1Ga3DS@avalon>
On 07/23/2014 01:07 PM, Laurent Pinchart wrote:
[...]
> Let's start by answering the background question and updating the DMA engine
> API documentation once and for good : in which context are drivers allowed to
> call the prep, tx_submit and issue_pending functions ?
>
I think the expectation is that these functions can be called in any
context. Maybe what's missing is a way to tell the DMA engine driver to get
ready and that it is going to be used very soon. This could be done from the
sound devices open() callback.
- Lars
^ permalink raw reply
* [PATCH] arm64/crypto: fix makefile rule for aes-glue-%.o
From: Andreas Schwab @ 2014-07-24 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8SbM_Z=ymBFb2D4EWJeo-6dWuKqE2YNOkqJTKLDEJcYA@mail.gmail.com>
Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
> On 30 June 2014 15:56, Andreas Schwab <schwab@suse.de> wrote:
>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>>
>>> Out of curiosity, how did you trigger this failure? I have build this
>>> code numerous times (and so have others) and I have never seen this
>>> failure.
>>
>> Did you ever start with a clean tree?
>>
>
> Yep, building both in-tree and out-of-tree, no trouble at all.
So you probably didn't configure them as modules.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply
* [PATCH] arm64/crypto: fix makefile rule for aes-glue-%.o
From: Ard Biesheuvel @ 2014-07-24 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <mvm4my7j5xh.fsf@hawking.suse.de>
On 24 July 2014 14:29, Andreas Schwab <schwab@suse.de> wrote:
> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>
>> On 30 June 2014 15:56, Andreas Schwab <schwab@suse.de> wrote:
>>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>>>
>>>> Out of curiosity, how did you trigger this failure? I have build this
>>>> code numerous times (and so have others) and I have never seen this
>>>> failure.
>>>
>>> Did you ever start with a clean tree?
>>>
>>
>> Yep, building both in-tree and out-of-tree, no trouble at all.
>
> So you probably didn't configure them as modules.
>
Yes, all the time, in fact. They have now been added as built-ins to
the defconfig, but I always build as modules, because it is far easier
when developing.
^ permalink raw reply
* [PATCH v3 0/4] Support for Qualcomm QPNP PMIC's
From: Stanimir Varbanov @ 2014-07-24 12:45 UTC (permalink / raw)
To: linux-arm-kernel
Hello all,
Changes since v2:
- 1/4 - added new line, signed-off-by / acked-by and module_authors.
- 3/4 - the subject has been changed.
The previous v2 can be found at [1].
I'm still waiting Acks for:
- 4/4 from Qualcomm folks.
- 2/4 and 3/4 from DT folks.
The patchset is ready to merge version and also it can be treated as an
intermediate step until we find a solution for non-translatable peripheral
addresses.
regards,
Stan
[1] https://lkml.org/lkml/2014/7/17/877
--------------------------------------------------------------------------------
Hello everyone,
Here is the continuation of patch sets sent recently about Qualcomm
QPNP SPMI PMICs.
The previous version of the patch set can be found at [1].
Changes since v1:
- removed completely custom *of* parser
- renamed the mfd driver from qpnp-spmi to pm8xxx-spmi
- now MFD_PM8XXX_SPMI Kconfig option depends on SPMI
Removing of the custom *of* parser leads to that that the *reg* devicetree
property cannot exist and therefore cannot be parsed to get PMIC peripheral
resources. I took this step aside because no one from mfd drivers does this
parsing. This will lead to inconvenience in the peripheral drivers to define
internally the SPMI base addresses depending on the compatible property
i.e. PMIC version.
Comments are welcome!
[1] https://lkml.org/lkml/2014/7/8/428
Josh Cartwright (1):
mfd: pm8xxx-spmi: add support for Qualcomm SPMI PMICs
Stanimir Varbanov (3):
mfd: pm8xxx-spmi: document DT bindings for Qualcomm SPMI PMICs
ARM: dts: qcom: add pm8941 and pm8841 PMICs device nodes
mfd: pm8921: rename pm8921-core driver
.../devicetree/bindings/mfd/qcom,pm8xxx-spmi.txt | 49 +++++++++++++++
arch/arm/boot/dts/qcom-msm8974.dtsi | 37 +++++++++++
drivers/mfd/Kconfig | 30 +++++++--
drivers/mfd/Makefile | 3 +-
drivers/mfd/pm8xxx-spmi.c | 65 ++++++++++++++++++++
drivers/mfd/{pm8921-core.c => pm8xxx-ssbi.c} | 38 ++++++------
6 files changed, 195 insertions(+), 27 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/qcom,pm8xxx-spmi.txt
create mode 100644 drivers/mfd/pm8xxx-spmi.c
rename drivers/mfd/{pm8921-core.c => pm8xxx-ssbi.c} (92%)
^ permalink raw reply
* [PATCH v3 1/4] mfd: pm8xxx-spmi: add support for Qualcomm SPMI PMICs
From: Stanimir Varbanov @ 2014-07-24 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406205921-7452-1-git-send-email-svarbanov@mm-sol.com>
From: Josh Cartwright <joshc@codeaurora.org>
The Qualcomm SPMI PMIC chips are components used with the
Snapdragon 800 series SoC family. This driver exists
largely as a glue mfd component, it exists to be an owner
of an SPMI regmap for children devices described in
device tree.
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/Kconfig | 16 +++++++++++
drivers/mfd/Makefile | 1 +
drivers/mfd/pm8xxx-spmi.c | 65 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/pm8xxx-spmi.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6cc4b6a..122e2d9 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -524,6 +524,22 @@ config MFD_PM8921_CORE
Say M here if you want to include support for PM8921 chip as a module.
This will build a module called "pm8921-core".
+config MFD_PM8XXX_SPMI
+ tristate "Qualcomm PM8XXX SPMI PMICs"
+ depends on ARCH_QCOM || COMPILE_TEST
+ depends on OF
+ depends on SPMI
+ select MFD_PM8XXX
+ select REGMAP_SPMI
+ help
+ This enables support for the Qualcomm PM8XXX SPMI PMICs.
+ These PMICs are currently used with the Snapdragon 800 series of
+ SoCs. Note, that this will only be useful paired with descriptions
+ of the independent functions as children nodes in the device tree.
+
+ Say M here if you want to include support for the PM8XXX SPMI PMIC
+ series as a module. The module will be called "pm8xxx-spmi".
+
config MFD_RDC321X
tristate "RDC R-321x southbridge"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 8afedba..93d82cc 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -153,6 +153,7 @@ obj-$(CONFIG_MFD_SI476X_CORE) += si476x-core.o
obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o omap-usb-tll.o
obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o ssbi.o
+obj-$(CONFIG_MFD_PM8XXX_SPMI) += pm8xxx-spmi.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
obj-$(CONFIG_MFD_TPS65090) += tps65090.o
obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
diff --git a/drivers/mfd/pm8xxx-spmi.c b/drivers/mfd/pm8xxx-spmi.c
new file mode 100644
index 0000000..16335a1
--- /dev/null
+++ b/drivers/mfd/pm8xxx-spmi.c
@@ -0,0 +1,65 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/spmi.h>
+#include <linux/regmap.h>
+#include <linux/of_platform.h>
+
+static const struct regmap_config pm8xxx_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = 0xffff,
+};
+
+static int pm8xxx_probe(struct spmi_device *sdev)
+{
+ struct device_node *root = sdev->dev.of_node;
+ struct regmap *regmap;
+
+ regmap = devm_regmap_init_spmi_ext(sdev, &pm8xxx_regmap_config);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ return of_platform_populate(root, NULL, NULL, &sdev->dev);
+}
+
+static void pm8xxx_remove(struct spmi_device *sdev)
+{
+ of_platform_depopulate(&sdev->dev);
+}
+
+static const struct of_device_id pm8xxx_id_table[] = {
+ { .compatible = "qcom,pm8941" },
+ { .compatible = "qcom,pm8841" },
+ { .compatible = "qcom,pma8084" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, pm8xxx_id_table);
+
+static struct spmi_driver pm8xxx_driver = {
+ .probe = pm8xxx_probe,
+ .remove = pm8xxx_remove,
+ .driver = {
+ .name = "pm8xxx-spmi",
+ .of_match_table = pm8xxx_id_table,
+ },
+};
+module_spmi_driver(pm8xxx_driver);
+
+MODULE_DESCRIPTION("PM8XXX SPMI PMIC driver");
+MODULE_ALIAS("spmi:pm8xxx-spmi");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Josh Cartwright <joshc@codeaurora.org>");
+MODULE_AUTHOR("Stanimir Varbanov <svarbanov@mm-sol.com>");
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 2/4] mfd: pm8xxx-spmi: document DT bindings for Qualcomm SPMI PMICs
From: Stanimir Varbanov @ 2014-07-24 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406205921-7452-1-git-send-email-svarbanov@mm-sol.com>
Document DT bindings used to describe the Qualcomm SPMI PMICs.
Currently the SPMI PMICs supported are pm8941, pm8841 and pma8084.
Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
---
.../devicetree/bindings/mfd/qcom,pm8xxx-spmi.txt | 49 ++++++++++++++++++++
1 files changed, 49 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/qcom,pm8xxx-spmi.txt
diff --git a/Documentation/devicetree/bindings/mfd/qcom,pm8xxx-spmi.txt b/Documentation/devicetree/bindings/mfd/qcom,pm8xxx-spmi.txt
new file mode 100644
index 0000000..2b7f5b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qcom,pm8xxx-spmi.txt
@@ -0,0 +1,49 @@
+ Qualcomm PM8XXX SPMI PMICs multi-function device bindings
+
+The Qualcomm PM8XXX series presently includes PM8941, PM8841 and PMA8084
+PMICs. These PMICs use a QPNP scheme through SPMI interface.
+QPNP is effectively a partitioning scheme for dividing the SPMI extended
+register space up into logical pieces, and set of fixed register
+locations/definitions within these regions, with some of these regions
+specifically used for interrupt handling.
+
+The QPNP PMICs are used with the Qualcomm Snapdragon series SoCs, and are
+interfaced to the chip via the SPMI (System Power Management Interface) bus.
+Support for multiple independent functions are implemented by splitting the
+16-bit SPMI slave address space into 256 smaller fixed-size regions, 256 bytes
+each. A function can consume one or more of these fixed-size register regions.
+
+Required properties:
+- compatible: Should contain one of:
+ "qcom,pm8941"
+ "qcom,pm8841"
+ "qcom,pma8084"
+- reg: Specifies the SPMI USID slave address for this device.
+ For more information see:
+ Documentation/devicetree/bindings/spmi/spmi.txt
+
+Required properties for peripheral child nodes:
+- compatible: Should contain "qcom,pm8xxx-xxx", where "xxx" is
+ peripheral name. The "pm8xxx" can be any of supported PMICs,
+ see example below.
+
+Optional properties for peripheral child nodes:
+- interrupts: Interrupts are specified as a 4-tuple. For more information
+ see:
+ Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
+- interrupt-names: Corresponding interrupt name to the interrupts property
+
+Each child node represents a function of the PMIC.
+
+Example:
+
+ pm8941 at 0 {
+ compatible = "qcom,pm8941";
+ reg = <0x0 SPMI_USID>;
+
+ rtc {
+ compatible = "qcom,pm8941-rtc";
+ interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "alarm";
+ };
+ };
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] ARM: mvebu: Added dts defintion for Lenovo Iomega ix4-300d NAS
From: Jason Cooper @ 2014-07-24 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53D0FA2F.6050209@free-electrons.com>
On Thu, Jul 24, 2014 at 02:21:03PM +0200, Gregory CLEMENT wrote:
> On 24/07/2014 01:15, Jason Cooper wrote:
> > On Thu, Jul 24, 2014 at 01:11:12AM +0200, Benoit Masson wrote:
> >> Le 24 juil. 2014 ? 00:58, Andrew Lunn <andrew@lunn.ch> a ?crit :
> >>
> >>>> For the marvell,mv78230-a0-i2c unfortunately i've spend 3 hours
> >>>> trying to understand this but it only works with this on the
> >>>> ix4-300d :(. There was multiple patch around this and maybe one
> >>>> broke the auto-detect part of this, I've tried compiling with some
> >>>> 3.10 or lower kernel but no luck here I still have to put this a0
> >>>> option.
> >>>
> >>> Lets first confirm you have an a0 SoC.
> >>>
> >>> At boot time, it should print:
> >>>
> >>> pr_info("MVEBU SoC ID=0x%X, Rev=0x%X\n", soc_dev_id, soc_rev);
> >>>
> >>> What revision do you have?
> >>>
> >>> If the auto detect code really is broken, Gregory will likely take a
> >>> look.
> >>
> >> I sure do,
> >>
> >> confirmed by u-boot output below:
> >>
> >> U-Boot 2009.08 (Mar 04 2013 - 11:13:04) Marvell version: 2.3.2 PQ
> >> U-Boot Addressing:
> >> Code:..00600000:006BFFF0
> >> BSS:..00708EC0
> >> Stack:..0x5fff70
> >> PageTable:.0x8e0000
> >> Heap address:.0x900000:0xe00000
> >> Board: DB-78230-BP rev 2.0 Wistron
> >> SoC: MV78230 A0
> >>
> >> From kernel I get:
> >>
> >> mvebu-soc-id: MVEBU SoC ID=0x7823, Rev=0x1
> >
> > Well, isn't that a peach? :) Gregory?
>
> A peach?? For me it is either a fruit or a princess, so I am puzzled!
Doc Holiday quote from the movie Tombstone. The full quote was "Well,
isn't that a peach of a hand?" while sitting at the poker table.
> Well about the issue, we patch the device tree for the i2c quirk only for
> the openblock AX3.
Ahhh, that's right. I need to slow down and dig a bit more. :(
> If I remember well it was because the device tree was already written
> for this board before we found there was an issue with the A0 version
> of the CPU.
No, it's because we didn't think any manufacturers would be silly enough
to use the a0 in production. That assumption worked out well. :-P
> The rule was that for new boards then they have to set the marvell,mv78230-a0-i2c
> compatible string. I also didn't expect that we found "new" product using the A0 version.
>
> We have 3 options now:
>
> - remove the check on the openblock AX3 board and always try to apply the quirck for A0 version
> - add a check for this new board in the mvebu_dt_init function
> - let the compatible string marvell,mv78230-a0-i2c in this dts
>
> I would prefer the option 1 but I fear that Arnd would prefer the 2 other options.
I like option 1 and 3. Option 3 is a *correct* description of the
hardware, and should be done. Option 1 makes Linux user-friendly for boards
that are exactly the same, but changed out SoC stepping mid-production.
Option 2 needs to be undone. We shouldn't need to change compiled code
for every new board that comes along. Which was the whole point of DT,
right?
thx,
Jason.
^ permalink raw reply
* [PATCH v3 3/4] ARM: dts: qcom: add pm8941 and pm8841 PMICs device nodes
From: Stanimir Varbanov @ 2014-07-24 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406205921-7452-1-git-send-email-svarbanov@mm-sol.com>
The pm8941 and pm8841 spmi devicetree nodes are childrens of
spmi pmic arbiter. The msm8974 SoC uses two PMIC chips
pm8941 and pm8841. Every PMIC chip has two spmi bus slave id's.
Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 37 +++++++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 69dca2a..5e08d43 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -3,6 +3,7 @@
#include "skeleton.dtsi"
#include <dt-bindings/clock/qcom,gcc-msm8974.h>
+#include <dt-bindings/spmi/spmi.h>
/ {
model = "Qualcomm MSM8974";
@@ -236,5 +237,41 @@
#interrupt-cells = <2>;
interrupts = <0 208 0>;
};
+
+ spmi at fc4cf000 {
+ compatible = "qcom,spmi-pmic-arb";
+ reg-names = "core", "intr", "cnfg";
+ reg = <0xfc4cf000 0x1000>,
+ <0xfc4cb000 0x1000>,
+ <0xfc4ca000 0x1000>;
+ interrupt-names = "periph_irq";
+ interrupts = <0 190 0>;
+ qcom,ee = <0>;
+ qcom,channel = <0>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ interrupt-controller;
+ #interrupt-cells = <4>;
+
+ pm8941 at 0 {
+ compatible = "qcom,pm8941";
+ reg = <0x0 SPMI_USID>;
+ };
+
+ pm8941 at 1 {
+ compatible = "qcom,pm8941";
+ reg = <0x1 SPMI_USID>;
+ };
+
+ pm8841 at 4 {
+ compatible = "qcom,pm8841";
+ reg = <0x4 SPMI_USID>;
+ };
+
+ pm8841 at 5 {
+ compatible = "qcom,pm8841";
+ reg = <0x5 SPMI_USID>;
+ };
+ };
};
};
--
1.7.0.4
^ permalink raw reply related
* [PATCH v3 4/4] mfd: pm8921: rename pm8921-core driver
From: Stanimir Varbanov @ 2014-07-24 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406205921-7452-1-git-send-email-svarbanov@mm-sol.com>
The pm8921-core driver presently supports pm8921 and pm8058
Qualcomm PMICs. To avoid confusion with new generation PMICs
(like pm8941) rename the pm8921-core driver to more
appropriate name pm8xxx-ssbi, which reflects better that
those chips use SSBI interface.
Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/Kconfig | 14 +++++-----
drivers/mfd/Makefile | 2 +-
drivers/mfd/{pm8921-core.c => pm8xxx-ssbi.c} | 38 +++++++++++++-------------
3 files changed, 27 insertions(+), 27 deletions(-)
rename drivers/mfd/{pm8921-core.c => pm8xxx-ssbi.c} (92%)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 122e2d9..884bc32 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -507,8 +507,8 @@ config UCB1400_CORE
config MFD_PM8XXX
tristate
-config MFD_PM8921_CORE
- tristate "Qualcomm PM8921 PMIC chip"
+config MFD_PM8XXX_SSBI
+ tristate "Qualcomm PM8XXX SSBI PMICs"
depends on (ARM || HEXAGON)
select IRQ_DOMAIN
select MFD_CORE
@@ -516,13 +516,13 @@ config MFD_PM8921_CORE
select REGMAP
help
If you say yes to this option, support will be included for the
- built-in PM8921 PMIC chip.
+ built-in PM8921 and PM8058 PMIC chips.
- This is required if your board has a PM8921 and uses its features,
- such as: MPPs, GPIOs, regulators, interrupts, and PWM.
+ This is required if your board has a PM8921 or PM8058 and uses
+ its features, such as: MPPs, GPIOs, regulators, interrupts, and PWM.
- Say M here if you want to include support for PM8921 chip as a module.
- This will build a module called "pm8921-core".
+ Say M here if you want to include support for PM8921 or PM8058 chip
+ as a module. This will build a module called "pm8xxx-ssbi".
config MFD_PM8XXX_SPMI
tristate "Qualcomm PM8XXX SPMI PMICs"
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 93d82cc..d332085 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -152,7 +152,7 @@ obj-$(CONFIG_MFD_SI476X_CORE) += si476x-core.o
obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
obj-$(CONFIG_MFD_OMAP_USB_HOST) += omap-usb-host.o omap-usb-tll.o
-obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o ssbi.o
+obj-$(CONFIG_MFD_PM8XXX_SSBI) += pm8xxx-ssbi.o ssbi.o
obj-$(CONFIG_MFD_PM8XXX_SPMI) += pm8xxx-spmi.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
obj-$(CONFIG_MFD_TPS65090) += tps65090.o
diff --git a/drivers/mfd/pm8921-core.c b/drivers/mfd/pm8xxx-ssbi.c
similarity index 92%
rename from drivers/mfd/pm8921-core.c
rename to drivers/mfd/pm8xxx-ssbi.c
index 9595138..102d7fb 100644
--- a/drivers/mfd/pm8921-core.c
+++ b/drivers/mfd/pm8xxx-ssbi.c
@@ -277,14 +277,14 @@ static const struct regmap_config ssbi_regmap_config = {
.reg_write = ssbi_reg_write
};
-static const struct of_device_id pm8921_id_table[] = {
+static const struct of_device_id pm8xxx_id_table[] = {
{ .compatible = "qcom,pm8058", },
{ .compatible = "qcom,pm8921", },
{ }
};
-MODULE_DEVICE_TABLE(of, pm8921_id_table);
+MODULE_DEVICE_TABLE(of, pm8xxx_id_table);
-static int pm8921_probe(struct platform_device *pdev)
+static int pm8xxx_probe(struct platform_device *pdev)
{
struct regmap *regmap;
int irq, rc;
@@ -354,18 +354,18 @@ static int pm8921_probe(struct platform_device *pdev)
return rc;
}
-static int pm8921_remove_child(struct device *dev, void *unused)
+static int pm8xxx_remove_child(struct device *dev, void *unused)
{
platform_device_unregister(to_platform_device(dev));
return 0;
}
-static int pm8921_remove(struct platform_device *pdev)
+static int pm8xxx_remove(struct platform_device *pdev)
{
int irq = platform_get_irq(pdev, 0);
struct pm_irq_chip *chip = platform_get_drvdata(pdev);
- device_for_each_child(&pdev->dev, NULL, pm8921_remove_child);
+ device_for_each_child(&pdev->dev, NULL, pm8xxx_remove_child);
irq_set_chained_handler(irq, NULL);
irq_set_handler_data(irq, NULL);
irq_domain_remove(chip->irqdomain);
@@ -373,29 +373,29 @@ static int pm8921_remove(struct platform_device *pdev)
return 0;
}
-static struct platform_driver pm8921_driver = {
- .probe = pm8921_probe,
- .remove = pm8921_remove,
+static struct platform_driver pm8xxx_driver = {
+ .probe = pm8xxx_probe,
+ .remove = pm8xxx_remove,
.driver = {
- .name = "pm8921-core",
+ .name = "pm8xxx-ssbi",
.owner = THIS_MODULE,
- .of_match_table = pm8921_id_table,
+ .of_match_table = pm8xxx_id_table,
},
};
-static int __init pm8921_init(void)
+static int __init pm8xxx_init(void)
{
- return platform_driver_register(&pm8921_driver);
+ return platform_driver_register(&pm8xxx_driver);
}
-subsys_initcall(pm8921_init);
+subsys_initcall(pm8xxx_init);
-static void __exit pm8921_exit(void)
+static void __exit pm8xxx_exit(void)
{
- platform_driver_unregister(&pm8921_driver);
+ platform_driver_unregister(&pm8xxx_driver);
}
-module_exit(pm8921_exit);
+module_exit(pm8xxx_exit);
MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("PMIC 8921 core driver");
+MODULE_DESCRIPTION("PMIC PM8XXX SSBI driver");
MODULE_VERSION("1.0");
-MODULE_ALIAS("platform:pm8921-core");
+MODULE_ALIAS("platform:pm8xxx-ssbi");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Adding Lenovo - Lenovo Group Ltd. to the vendor-prefixes list.
From: Rob Herring @ 2014-07-24 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1406154923-13612-1-git-send-email-yahoo@perenite.com>
On Wed, Jul 23, 2014 at 5:35 PM, Benoit Masson <yahoo@perenite.com> wrote:
> Lenovo Group Ltd. (stylized as lenovo) is a Chinese multinational computer technology company with headquarters in Beijing, China, and Morrisville, North Carolina, United States.
>
> http://www.lenovo.com/
> Signed-off-by: Benoit Masson <yahoo@perenite.com>
Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 46a311e..ae09892 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -71,6 +71,7 @@ karo Ka-Ro electronics GmbH
> keymile Keymile GmbH
> lacie LaCie
> lantiq Lantiq Semiconductor
> +lenovo Lenovo Group Ltd.
> lg LG Corporation
> linux Linux-specific binding
> lsi LSI Corp. (LSI Logic)
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 2/2] pinctrl: sunxi: number gpio ranges starting from 0
From: Maxime Ripard @ 2014-07-24 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405358677-23657-3-git-send-email-wens@csie.org>
On Tue, Jul 15, 2014 at 01:24:37AM +0800, Chen-Yu Tsai wrote:
> The pinctrl-sunxi driver originally used the pin number as the gpio
> range offset. This resulted in large, bogus gpio numbers for the
> new sun6i-a31-r pinctrl devices.
>
> This patch makes the driver number the gpios ranges starting from an
> offset of 0, by subtracting the pin_base number from the pin number.
> This also makes the system-wide gpio number match the pin number.
>
> Tested on sun8i with sysfs exported gpios.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140724/3c18f510/attachment.sig>
^ 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