Re: [PATCH 1/3] driver-core: platform: Add platform_irq_count()

2016-01-07 Thread Arnd Bergmann
nel.org> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> > Cc: Andy Gross <andy.gr...@linaro.org> > Signed-off-by: Stephen Boyd <sb...@codeaurora.org> > Acked-by: Arnd Bergmann <a...@arndb.de> I think there are a couple of other drivers that can use

Re: [PATCH v5 3/5] PCI: qcom: Add Qualcomm PCIe controller driver

2015-12-21 Thread Arnd Bergmann
On Monday 21 December 2015, Bjorn Andersson wrote: > I disagree with this "recommendation" as it's only outcome will be asymmetry. > > I think this script should be changed to only warn if there's a single > IS_ERR/PTR_ERR at the end of the function, not if there's a list of > them and this would

Re: [PATCH] net: emac: emac gigabit ethernet controller driver

2015-12-15 Thread Arnd Bergmann
On Tuesday 15 December 2015 15:09:23 Timur Tabi wrote: > Arnd Bergmann wrote: > > If that's in the probe() called from it function, just use writel() > > everywhere, > > a few extra microseconds won't kill the boot time. In general, if a user > > would > > notic

Re: [PATCH] net: emac: emac gigabit ethernet controller driver

2015-12-15 Thread Arnd Bergmann
On Tuesday 15 December 2015 09:30:16 Christopher Covington wrote: > > On 12/14/2015 08:39 PM, Florian Fainelli wrote: > > On 14/12/15 16:19, Gilad Avidov wrote: > > >> +static void emac_mac_irq_enable(struct emac_adapter *adpt) > >> +{ > >> +int i; > >> + > >> +for (i = 0; i <

Re: [PATCH] net: emac: emac gigabit ethernet controller driver

2015-12-15 Thread Arnd Bergmann
On Tuesday 15 December 2015 09:17:00 Timur Tabi wrote: > Arnd Bergmann wrote: > > We generally want to use readl/writel rather than the relaxed versions, > > unless it is in performance-critical code. > > What about if we have 20+ writes in a row, for example, when > in

Re: [PATCH] ARM: Runtime patch udiv/sdiv instructions into __aeabi_{u}idiv()

2015-12-11 Thread Arnd Bergmann
On Friday 11 December 2015 01:26:25 Nicolas Pitre wrote: > This is my counter proposal to Stephen's version. Those patches and the > discussion that followed are available here: > > http://news.gmane.org/group/gmane.linux.kbuild.devel/thread=14007 > > I think what I propose here is much

Re: [PATCH] ARM: Runtime patch udiv/sdiv instructions into __aeabi_{u}idiv()

2015-12-11 Thread Arnd Bergmann
On Friday 11 December 2015 12:10:29 Nicolas Pitre wrote: > On Fri, 11 Dec 2015, Arnd Bergmann wrote: > > On Friday 11 December 2015 01:26:25 Nicolas Pitre wrote: > > > Of course the ultimate performance will come from having gcc emit those > > > div instructions di

Re: [PATCH] ARM: Runtime patch udiv/sdiv instructions into __aeabi_{u}idiv()

2015-12-11 Thread Arnd Bergmann
On Friday 11 December 2015 22:34:16 Russell King - ARM Linux wrote: > > __v7_pj4b_proc_info: > - .long 0x562f5840 > - .long 0xfff0 > + .long 0x560f5800 > + .long 0xff0fff00 > > So it was to include Armada 370. So this now brings up the question... > what is

Re: [PATCH] ARM: Runtime patch udiv/sdiv instructions into __aeabi_{u}idiv()

2015-12-11 Thread Arnd Bergmann
On Friday 11 December 2015 17:00:50 Nicolas Pitre wrote: > You seem to have a good grasp of the problem space. I'd suggest you make > a patch! ;-) Yes, I can do that once all the ARMv6/v7 multiplatform work is done, that should at least reduce the number of special cases. > > > > #ifdef

Re: [PATCH] ARM: Runtime patch udiv/sdiv instructions into __aeabi_{u}idiv()

2015-12-11 Thread Arnd Bergmann
; > Signed-off-by: Nicolas Pitre <n...@linaro.org> > Acked-by: Arnd Bergmann <a...@arndb.de> Before you put it in the patch tracker, I think it would be good to give Stephen a chance to comment as well, since he did a lot of work upfront and this obsoletes his origi

Re: [PATCH] ARM: Runtime patch udiv/sdiv instructions into __aeabi_{u}idiv()

2015-12-11 Thread Arnd Bergmann
On Friday 11 December 2015 19:01:00 Nicolas Pitre wrote: > On Fri, 11 Dec 2015, Arnd Bergmann wrote: > > > On Friday 11 December 2015 22:34:16 Russell King - ARM Linux wrote: > > > > > > __v7_pj4b_proc_info: > > > - .long 0x562f5840 > > >

Re: [RFC][PATCH] misc: Introduce reboot_reason driver

2015-12-10 Thread Arnd Bergmann
On Wednesday 09 December 2015 17:32:02 John Stultz wrote: > On Tue, Dec 8, 2015 at 2:07 PM, Bjorn Andersson > wrote: > > On Tue 08 Dec 13:29 PST 2015, John Stultz wrote: > >> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts > >>

Re: [RFC][PATCH] misc: Introduce reboot_reason driver

2015-12-10 Thread Arnd Bergmann
On Wednesday 09 December 2015 17:19:52 John Stultz wrote: > On Wed, Dec 9, 2015 at 2:07 AM, Arnd Bergmann <a...@arndb.de> wrote: > > On Tuesday 08 December 2015 16:22:40 John Stultz wrote: > >> >> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts > >&

Re: [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region

2015-12-09 Thread Arnd Bergmann
On Wednesday 09 December 2015 10:10:05 Pratyush Anand wrote: > On Tue, Dec 8, 2015 at 2:31 PM, Stanimir Varbanov > > > Signed-off-by: Stanimir Varbanov > > > --- > > > drivers/pci/host/pcie-designware.c |5 + > > > 1 file changed, 5 insertions(+) > > > > > >

Re: [RFC][PATCH] misc: Introduce reboot_reason driver

2015-12-09 Thread Arnd Bergmann
On Tuesday 08 December 2015 16:22:40 John Stultz wrote: > >> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts > >> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts > >> index 5183d18..ee5dcb7 100644 > >> --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts > >> +++

Re: [PATCH 2/4] dmaengine: qcom_bam_dma: clear BAM interrupt only if it is rised

2015-12-02 Thread Arnd Bergmann
On Wednesday 02 December 2015 14:56:57 Stanimir Varbanov wrote: > On 12/01/2015 12:29 PM, Arnd Bergmann wrote: > > On Tuesday 01 December 2015 11:14:57 Stanimir Varbanov wrote: > >> + if (srcs & BAM_IRQ) { > >> clr_mask = readl_relaxed

Re: [PATCH 3/4] dmaengine: qcom_bam_dma: use correct pipe FIFO size

2015-12-01 Thread Arnd Bergmann
On Tuesday 01 December 2015 11:25:35 Andy Gross wrote: > On Tue, Dec 01, 2015 at 11:28:32AM +0100, Arnd Bergmann wrote: > > On Tuesday 01 December 2015 11:14:58 Stanimir Varbanov wrote: > > > > > > diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma

Re: [PATCH] ARM: multi_v7_defconfig: Enable required QCOM SPMI/PMIC drivers

2015-12-01 Thread Arnd Bergmann
On Thursday 26 November 2015 00:15:57 Andy Gross wrote: > This patch enables the QCOM SPMI and PMIC related drivers that are now > required to boot some supported devices. > > Signed-off-by: Andy Gross > Applied to next/defconfig. I assume you didn't mean this to go into

Re: [PATCH 3/4] dmaengine: qcom_bam_dma: use correct pipe FIFO size

2015-12-01 Thread Arnd Bergmann
On Tuesday 01 December 2015 11:14:58 Stanimir Varbanov wrote: > > diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom_bam_dma.c > index 0f06f3b7a72b..6d290de9ab2b 100644 > --- a/drivers/dma/qcom_bam_dma.c > +++ b/drivers/dma/qcom_bam_dma.c > @@ -458,7 +458,7 @@ static void

Re: [PATCH v3 0/3] Remove ARCH_MSM* configs

2015-12-01 Thread Arnd Bergmann
On Monday 30 November 2015 17:25:20 Stephen Boyd wrote: > This patch series allows us to remove the ARCH_MSM* configs that live > in mach-qcom/Kconfig. They're mostly proxy configs for user selectable > clocksource configurations anyway. > > Acked-by: Arnd Bergmann <a...@arndb

Re: [PATCH v2 1/3] ARM: qcom: Make an option for qcom clocksource platforms

2015-11-25 Thread Arnd Bergmann
On Wednesday 25 November 2015 14:22:21 Stephen Boyd wrote: > > > > > Is there any common way to classify these, e.g. calling them > > 'pre-2013 models' or 'Snapdragon S4' as a way to identify them? > > I was thinking I could leave it as ARCH_MSM_8X60 because that covers the > 6 and the 9, but

Re: [PATCH v2 1/3] ARM: qcom: Make an option for qcom clocksource platforms

2015-11-25 Thread Arnd Bergmann
On Wednesday 25 November 2015 13:04:36 Stephen Boyd wrote: > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index 2c2b28ee4811..999d523ac09f 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -148,8 +148,7 @@ textofs-$(CONFIG_PM_H1940) := 0x00108000 > ifeq

Re: [PATCH 3/3] ARM: qcom: Drop ARCH_MSM* configs

2015-11-25 Thread Arnd Bergmann
On Wednesday 25 November 2015 11:34:47 Stephen Boyd wrote: > On 11/25, Arnd Bergmann wrote: > > On Wednesday 25 November 2015 13:27:55 Daniel Lezcano wrote: > > > > > > What about: > > > > > > textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000 >

Re: [PATCH 1/3] clocksource: defbool CLKSRC_QCOM=y on ARCH_QCOM and make it visible

2015-11-25 Thread Arnd Bergmann
On Wednesday 25 November 2015 11:10:49 Daniel Lezcano wrote: > On 11/25/2015 02:08 AM, Stephen Boyd wrote: > > We want to remove the ARCH_MSM* configs in mach-qcom/Kconfig > > because they are mostly proxy configs for selecting the right > > clocksource driver. Therefore, make CLKSRC_QCOM default

Re: [PATCH 1/3] clocksource: defbool CLKSRC_QCOM=y on ARCH_QCOM and make it visible

2015-11-25 Thread Arnd Bergmann
e CLKSRC_QCOM default to the > > value of ARCH_QCOM, but also make it visible if ARCH_QCOM=y so > > that we can turn it off when we don't want it. > > > > Suggested-by: Arnd Bergmann <a...@arndb.de> > > Signed-off-by: Stephen Boyd <sb...@codeaurora.org> > >

Re: [PATCH 1/3] clocksource: defbool CLKSRC_QCOM=y on ARCH_QCOM and make it visible

2015-11-25 Thread Arnd Bergmann
On Wednesday 25 November 2015 13:37:53 Daniel Lezcano wrote: > On 11/25/2015 11:17 AM, Arnd Bergmann wrote: > > On Wednesday 25 November 2015 11:10:49 Daniel Lezcano wrote: > >> On 11/25/2015 02:08 AM, Stephen Boyd wrote: > >>> We want to remove the ARCH_MSM

Re: [PATCH 3/3] ARM: qcom: Drop ARCH_MSM* configs

2015-11-25 Thread Arnd Bergmann
On Wednesday 25 November 2015 13:27:55 Daniel Lezcano wrote: > > What about: > > textofs-$(CONFIG_ARCH_MSM8X60) := 0x00208000 > textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000 > > in arch/arm/Makefile Good point, we need to do something about these still. > and > > CONFIG_ARCH_MSM8X60=y >

[PATCH] ARM: qcom: select ARM_CPU_SUSPEND for power management

2015-11-24 Thread Arnd Bergmann
reference to `cpu_resume_arm' This adds a 'select' Kconfig statement to ensure it's always enabled. Signed-off-by: Arnd Bergmann <a...@arndb.de> --- This has been broken for a while but not even shown up in many thousands of randconfig builds until today. Please queue it up for 4.5 unless you

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-24 Thread Arnd Bergmann
On Tuesday 24 November 2015 20:35:16 Russell King - ARM Linux wrote: > We'd need to do something similar for v7VE as well. As we're getting > more of this, I'd suggest we move to: > > arch-v7a-y =$(call > cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a) >

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-24 Thread Arnd Bergmann
On Monday 23 November 2015 15:13:52 Stephen Boyd wrote: > On 11/23, Arnd Bergmann wrote: > > On Monday 23 November 2015 13:32:06 Stephen Boyd wrote: > > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig > > index b251013eef0a..bad6343c34d5 100644 > >

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-24 Thread Arnd Bergmann
On Tuesday 24 November 2015 00:53:49 Stephen Boyd wrote: > On 11/23, Stephen Boyd wrote: > > On 11/23, Arnd Bergmann wrote: > > > > > > Ok, thanks for the confirmation. > > > > > > Summarizing what we've found, I think we can get away wi

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-24 Thread Arnd Bergmann
On Tuesday 24 November 2015 12:15:13 Måns Rullgård wrote: > Arnd Bergmann <a...@arndb.de> writes: > > On Monday 23 November 2015 15:13:52 Stephen Boyd wrote: > >> On 11/23, Arnd Bergmann wrote: > >> > On Monday 23 November 2015 13:32:06 Stephen Boyd wrote: >

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-23 Thread Arnd Bergmann
On Sunday 22 November 2015 21:36:45 Nicolas Pitre wrote: > On Sun, 22 Nov 2015, Arnd Bergmann wrote: > > > I've also found some /proc/cpuinfo output to cross-reference SoCs > > to their core names. > > > > variant partrevisionname

Re: [PATCH v3 1/6] PCI: designware: remove wrong io_base assignment

2015-11-23 Thread Arnd Bergmann
e trying to get it right. However, it broke only recently and it's worth mentioning what commit did it, so Fixes: 0021d22b73d6 ("PCI: designware: Use of_pci_get_host_bridge_resources() to parse DT") Reviewed-by: Arnd Bergmann <a...@arndb.de> The bug is present in 4.4-rc1 an

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-23 Thread Arnd Bergmann
On Monday 23 November 2015 13:32:06 Stephen Boyd wrote: > On 11/23, Arnd Bergmann wrote: > > On Monday 23 November 2015 12:38:47 Stephen Boyd wrote: > > > On 11/23, Arnd Bergmann wrote: > > > > On Monday 23 November 2015 09:14:39 Christopher Covington wrote: > >

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-23 Thread Arnd Bergmann
On Monday 23 November 2015 09:14:39 Christopher Covington wrote: > On 11/23/2015 03:15 AM, Arnd Bergmann wrote: > > On Sunday 22 November 2015 21:36:45 Nicolas Pitre wrote: > >> On Sun, 22 Nov 2015, Arnd Bergmann wrote: > > > > Ok, thanks a lot! So the reporting in

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-23 Thread Arnd Bergmann
On Monday 23 November 2015 12:38:47 Stephen Boyd wrote: > On 11/23, Arnd Bergmann wrote: > > On Monday 23 November 2015 09:14:39 Christopher Covington wrote: > > > On 11/23/2015 03:15 AM, Arnd Bergmann wrote: > > > LPAE is only supported in the Krait 450. > > >

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-22 Thread Arnd Bergmann
On Sunday 22 November 2015 13:29:29 Peter Maydell wrote: > On 21 November 2015 at 23:21, Arnd Bergmann <a...@arndb.de> wrote: > > Regarding PJ4, it's still unclear whether that has the same > > problem and it only reports idivt when it actually supports idiva, > > o

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-22 Thread Arnd Bergmann
On Sunday 22 November 2015 19:47:05 Russell King - ARM Linux wrote: > On Sun, Nov 22, 2015 at 08:25:27PM +0100, Arnd Bergmann wrote: > > The question is really about Marvell Dove, MMP and Armada 370, > > which are all based on PJ4 or PJ4B (CPU part : 0x581), so ARMv7-A > > and

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-22 Thread Arnd Bergmann
On Sunday 22 November 2015 20:03:26 Russell King - ARM Linux wrote: > On Sun, Nov 22, 2015 at 08:58:08PM +0100, Arnd Bergmann wrote: > > does it work with -mcpu=cortex-a15? I've tried crosstool as versions > > 2.23.52.20130913, 2.24.0.20141017 and 2.25.51.20150518, and they > &g

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-22 Thread Arnd Bergmann
On Sunday 22 November 2015 20:39:54 Måns Rullgård wrote: > Arnd Bergmann <a...@arndb.de> writes: > > > arnd@wuerfel:/tmp$ arm-linux-gnueabihf-gcc -Wall -O2 -mcpu=cortex-a15 > > idiv.c -c -o idiv-arm.o > > arnd@wuerfel:/tmp$ objdump -dr idiv-arm.o > > &

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-21 Thread Arnd Bergmann
On Sunday 22 November 2015 00:14:14 Arnd Bergmann wrote: > On Saturday 21 November 2015 22:11:36 Måns Rullgård wrote: > > Arnd Bergmann <a...@arndb.de> writes: > > > On Saturday 21 November 2015 20:45:38 Måns Rullgård wrote: > > >> On 21 November 20

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-21 Thread Arnd Bergmann
On Friday 20 November 2015 17:23:14 Stephen Boyd wrote: > This is a respin of a patch series from about a year ago[1]. I realized > that we already had most of the code in recordmcount to figure out > where we make calls to particular functions, so recording where > we make calls to the integer

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-21 Thread Arnd Bergmann
On Saturday 21 November 2015 20:45:38 Måns Rullgård wrote: > On 21 November 2015 20:39:58 GMT+00:00, Arnd Bergmann <a...@arndb.de> wrote: > >On Friday 20 November 2015 17:23:14 Stephen Boyd wrote: > >> This is a respin of a patch series from about a year ago[1]. I > >

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

2015-11-21 Thread Arnd Bergmann
On Saturday 21 November 2015 22:11:36 Måns Rullgård wrote: > Arnd Bergmann <a...@arndb.de> writes: > > On Saturday 21 November 2015 20:45:38 Måns Rullgård wrote: > >> On 21 November 2015 20:39:58 GMT+00:00, Arnd Bergmann <a...@arndb.de> > >> wrote: > &g

Re: [PATCH] drivers/built-in.o: In function `qcom_smp2p_intr':

2015-11-20 Thread Arnd Bergmann
On Friday 20 November 2015 10:43:00 Arnd Bergmann wrote: > The newly added smp2p and smsm drivers cannot be loadable modules > but depend on smem, which can be, and that causes a link error: > Sorry, $SUBJECT is wrong, I'll resend. Arnd -- To unsubscribe from this list: send

[PATCH] drivers/built-in.o: In function `qcom_smp2p_intr':

2015-11-20 Thread Arnd Bergmann
' :(.text+0xa736c): undefined reference to `qcom_smem_get' drivers/built-in.o: In function `qcom_smsm_probe': :(.text+0xa7b34): undefined reference to `qcom_smem_get' This marks all the drivers as 'tristate' to make the Kconfig dependency resolution work properly. Signed-off-by: Arnd Bergmann

[PATCH v2] soc: qcom: enable smsm/smp2p modular build

2015-11-20 Thread Arnd Bergmann
work properly. Signed-off-by: Arnd Bergmann <a...@arndb.de> Fixes: dbb04bd7122f ("soc: qcom: smp2p: Qualcomm Shared Memory Point to Point") Fixes: d7387fc6add4 ("soc: qcom: smsm: Add driver for Qualcomm SMSM") --- v2: fixed subject line diff --git a/drivers/soc/qcom/

Re: [PATCH v3 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

2015-11-20 Thread Arnd Bergmann
On Friday 20 November 2015 15:20:39 Tim Bird wrote: > +- interrupt-names: Should contain the following: > + "core"USB core interrupt > + "async" Asynchronous interrupt to wake up from low power mode > +(optional) > > - clocks: A list of phandle +

Re: [PATCH v2 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

2015-11-20 Thread Arnd Bergmann
On Friday 20 November 2015 14:37:16 Tim Bird wrote: > +- interrupt-names: Should contain the following: > + "core_irq"USB core interrupt > + "async_irq" Asynchronous interrupt to wake up from low power mode > +(optional) > > Sorry for the bike-shedding but how about

[PATCH] pinctrl: fix qcom ssbi drivers for 64-bit compilation

2015-11-16 Thread Arnd Bergmann
is the right thing to do here. Signed-off-by: Arnd Bergmann <a...@arndb.de> diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c index d809c9eaa323..19a3c3bc2f1f 100644 --- a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c +++ b/drivers/pinctrl/qcom/pinctr

Re: [PATCH V5 2/3] dma: add Qualcomm Technologies HIDMA management driver

2015-11-16 Thread Arnd Bergmann
On Sunday 15 November 2015 15:54:13 Sinan Kaya wrote: > The Qualcomm Technologies HIDMA device has been designed > to support virtualization technology. The driver has been > divided into two to follow the hardware design. > > 1. HIDMA Management driver > 2. HIDMA Channel driver > > Each HIDMA

[PATCH] Revert "thermal: qcom_spmi: allow compile test"

2015-11-16 Thread Arnd Bergmann
' statement, so we should be able to enable SPMI on all architectures for compile testing already. Signed-off-by: Arnd Bergmann <a...@arndb.de> Fixes: cb7fb4d34202 ("thermal: qcom_spmi: allow compile test") diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 2e7524f0f3

Re: [kbuild-all] [PATCH V3 4/4] dma: add Qualcomm Technologies HIDMA channel driver

2015-11-12 Thread Arnd Bergmann
On Thursday 12 November 2015 16:20:15 Fengguang Wu wrote: > Hi Arnd, > > On Wed, Nov 11, 2015 at 09:42:00AM +0100, Arnd Bergmann wrote: > > On Wednesday 11 November 2015 10:21:03 Fengguang Wu wrote: > > > Hi Sinan, > > > > > > Sorry please ignore this w

Re: [kbuild-all] [PATCH V3 4/4] dma: add Qualcomm Technologies HIDMA channel driver

2015-11-11 Thread Arnd Bergmann
On Wednesday 11 November 2015 10:21:03 Fengguang Wu wrote: > Hi Sinan, > > Sorry please ignore this warning -- it's actually a problem specific > to the mn10300 arch. I'll disable such warning in mn10300 in future. I just tried to find what happened here. mn10300 appears to define the type based

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

2015-11-10 Thread Arnd Bergmann
On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote: > On 11/10/2015 3:38 AM, Arnd Bergmann wrote: > > No, as Timur found, the driver is correct and it intentionally > > sets the 32-bit mask, and that is guaranteed to work on all sane > > hardware. Don't change the dri

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

2015-11-10 Thread Arnd Bergmann
On Tuesday 10 November 2015 11:00:59 Timur Tabi wrote: > On 11/10/2015 10:47 AM, Arnd Bergmann wrote: > > What BenH was worried about here is that the driver sets different masks > > for streaming and coherent mappings, which is indeed a worry that > > could hit us on ARM a

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

2015-11-10 Thread Arnd Bergmann
On Tuesday 10 November 2015 12:19:33 Sinan Kaya wrote: > On 11/10/2015 11:47 AM, Arnd Bergmann wrote: > > On Tuesday 10 November 2015 11:06:40 Sinan Kaya wrote: > >> On 11/10/2015 3:38 AM, Arnd Bergmann wrote: > >> > No, as Timur found, the driver is correct a

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

2015-11-10 Thread Arnd Bergmann
On Tuesday 10 November 2015 15:58:19 Sinan Kaya wrote: > > On 11/10/2015 2:56 PM, Arnd Bergmann wrote: > >> The ACPI IORT table declares whether you enable IOMMU for a particular > >> >device or not. The placement of IOMMU HW is system specific. The IORT > >>

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

2015-11-10 Thread Arnd Bergmann
On Tuesday 10 November 2015 15:59:18 Timur Tabi wrote: > On 11/10/2015 03:54 PM, Arnd Bergmann wrote: > > >> In our drivers for 32-bit devices, we have to explicitly set the DMA > >> mask to 32-bits in order to get any DMA working. > > > > Do you

Re: [PATCH V2 2/3] scsi: fix compiler warning for sg

2015-11-10 Thread Arnd Bergmann
On Monday 09 November 2015 22:53:17 Timur Tabi wrote: > Sinan Kaya wrote: > > > > The code says it is using these macros for small integers only which > > can't overflow. I was trying to get rid of compiler warning and it seems > > to have disappeared. > > I would double-check the assembly code,

Re: [PATCH V3 3/4] dmaselftest: add memcpy selftest support functions

2015-11-10 Thread Arnd Bergmann
On Monday 09 November 2015 23:49:54 Sinan Kaya wrote: > On 11/9/2015 8:48 AM, Timur Tabi wrote: > > Sinan Kaya wrote: > >>> > >>> And why kmalloc anyway? Why not leave it on the stack? > >>> > >>> char src[] = "hello world"; > >>> > >>> ? > >> > >> I need to call dma_map_single on this

Re: [PATCH V2 1/3] scsi: mptxsas: try 64 bit DMA when 32 bit DMA fails

2015-11-09 Thread Arnd Bergmann
On Monday 09 November 2015 08:09:39 Hannes Reinecke wrote: > On 11/09/2015 02:57 AM, Sinan Kaya wrote: > > Current code gives up when 32 bit DMA is not supported. > > This problem has been observed on systems without any > > memory below 4 gig. > > > > This patch tests 64 bit support before

Re: [PATCH v7 6/8] scsi: ufs: make the UFS variant a platform device

2015-10-22 Thread Arnd Bergmann
On Thursday 22 October 2015 07:02:14 subha...@codeaurora.org wrote: > > > > Required properties: > > -- compatible: compatible list, contains "jedec,ufs-1.1" > > +- compatible: compatible list, contains "jedec,ufs-1.1" or > > + "qcom,msm8994-ufshc" or

Re: [GIT PULL] qcom SoC changes for 4.4 *RESEND*

2015-10-16 Thread Arnd Bergmann
On Friday 16 October 2015 09:56:30 Stephen Boyd wrote: > On 10/15/2015 02:05 PM, Arnd Bergmann wrote: > > > > This also seemed like the right place > > to add a bugfix that I had in my queue: > > > > commit 73ebb85444b0472d90bb70a1a9e6b5df3f92c14c > &g

[PATCH] pinctrl: ssbi: fix function name typo

2015-10-16 Thread Arnd Bergmann
(not in a function) This fixes the two identifiers. Signed-off-by: Arnd Bergmann <a...@arndb.de> Fixes: b4c45fe974bc ("pinctrl: qcom: ssbi: Family A gpio & mpp drivers") diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c b/drivers/pinctrl/qcom/pinctrl-ssbi-gpio.

Re: [GIT PULL] qcom SoC changes for 4.4 *RESEND*

2015-10-16 Thread Arnd Bergmann
On Friday 16 October 2015 13:04:17 Stephen Boyd wrote: > On 10/16, Arnd Bergmann wrote: > > On Friday 16 October 2015 09:56:30 Stephen Boyd wrote: > > > > > > Can you share your .config? It looks like there are stubs for these, so > > > I'm lost how we got u

Re: [GIT PULL] qcom SoC changes for 4.4 *RESEND*

2015-10-16 Thread Arnd Bergmann
On Friday 16 October 2015 14:26:27 Stephen Boyd wrote: > On 10/16, Arnd Bergmann wrote: > > On Friday 16 October 2015 13:04:17 Stephen Boyd wrote: > > > On 10/16, Arnd Bergmann wrote: > > > > On Friday 16 October 2015 09:56:30 Stephen Boyd wrote: > > > &g

Re: [GIT PULL] qcom arm64 updates for 4.4 *RESEND*

2015-10-16 Thread Arnd Bergmann
On Wednesday 14 October 2015 17:10:31 Andy Gross wrote: > Qualcomm ARM64 Updates for v4.4 > > * Add RNG device tree node > * Add MSM8x16 serial UART1 node > * Enable eMMC on apq8016-sbc board > * Fix I2C pinconf sleep state function > * Add MSM8916 I2C nodes > * Enable I2C busses on LS and HS on

Re: [GIT PULL] qcom SoC changes for 4.4 *RESEND*

2015-10-15 Thread Arnd Bergmann
merge commit just duplicates the information like this: commit 90bb7e0e4f1ad8714f39db232ef14c588297346d Merge: 5462b10af11d d0bfd7c9b162 Author: Arnd Bergmann <a...@arndb.de> Date: Thu Oct 15 22:56:52 2015 +0200 Merge tag 'qcom-soc-for-4.4' of git://codeaurora.org/quic/kernel/agross-msm in

Re: [GIT PULL] qcom dt changes for 4.4

2015-10-14 Thread Arnd Bergmann
On Tuesday 13 October 2015 16:50:33 Andy Gross wrote: > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in the git repository at: > > g...@git.codeaurora.org:quic/kernel/agross-msm.git

Re: [GIT PULL] qcom dt changes for 4.4

2015-10-14 Thread Arnd Bergmann
On Wednesday 14 October 2015 23:06:16 Arnd Bergmann wrote: > On Tuesday 13 October 2015 16:50:33 Andy Gross wrote: > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > > > ar

[PATCH] firmware: bcm47xx_nvram: fix typo / build error

2015-10-12 Thread Arnd Bergmann
The same commit also changed the behavior of the code in big-endian builds to no longer perform byte swaps, which looks intentional but was not part of the patch description. Signed-off-by: Arnd Bergmann <a...@arndb.de> Fixes: 31e2fab1c36b ("FIRMWARE: bcm47xx_nvram: Use __ioread32_co

[PATCH] firmware: qcom-scm: build for correct architecture level

2015-10-12 Thread Arnd Bergmann
ompilation of the scm driver. Signed-off-by: Arnd Bergmann <a...@arndb.de> diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile index 2ee83474a3c1..f0066373b170 100644 --- a/drivers/firmware/Makefile +++ b/drivers/firmware/Makefile @@ -15,7 +15,7 @@ obj-$(CONFIG_FIRMWARE_MEMMAP)

Re: [PATCH v4] scsi: ufs: add ioctl interface for query request

2015-10-11 Thread Arnd Bergmann
On Sunday 11 October 2015 14:22:12 Yaniv Gardi wrote: > * @cookie: cookie data > @@ -5106,6 +5308,10 @@ static struct scsi_host_template > ufshcd_driver_template = { > .eh_device_reset_handler = ufshcd_eh_device_reset_handler, > .eh_host_reset_handler =

Re: [PATCH v3] scsi: ufs: add ioctl interface for query request

2015-10-11 Thread Arnd Bergmann
On Sunday 11 October 2015 11:02:34 yga...@codeaurora.org wrote: > > > > no need for the #ifdef here. > > in include\scsi\scsi_host.h > the hook - compat_ioctl is defined inside #ifdef CONFIG_COMPAT > > #ifdef CONFIG_COMPAT > int (* compat_ioctl)(struct scsi_device *dev, int cmd, void

Re: [PATCH] arm64: defconfig: Enable devices for MSM8916

2015-10-09 Thread Arnd Bergmann
On Thursday 08 October 2015 15:37:08 Andy Gross wrote: > This patch enables a number of devices currently supported by the MSM8916 > boards. These include I2C, SPI, DMA, SMEM, SMD, and SMD regulator support. > > Signed-off-by: Andy Gross > Merged into next/defconfig,

Re: [PATCH v3] scsi: ufs: add ioctl interface for query request

2015-10-08 Thread Arnd Bergmann
On Thursday 08 October 2015 14:09:24 Yaniv Gardi wrote: > This patch exposes the ioctl interface for UFS driver via SCSI device > ioctl interface. As of now UFS driver would provide the ioctl for query > interface to connected UFS device. > > Signed-off-by: Dolev Raviv >

Re: [PATCH v2] scsi: ufs: add ioctl interface for query request

2015-10-07 Thread Arnd Bergmann
On Wednesday 07 October 2015 10:54:03 Yaniv Gardi wrote: > > +/* IOCTL opcode for command - ufs set device read only */ > +#define UFS_IOCTL_BLKROSET BLKROSET > + What is this for? Can't you just use the normal BLKROSET definition in user space? > + > + ioctl_data =

Re: [PATCH v2] scsi: ufs: add ioctl interface for query request

2015-10-07 Thread Arnd Bergmann
On Wednesday 07 October 2015 12:27:54 yga...@codeaurora.org wrote: > > >> + > >> +/* > >> + * IOCTL opcode for ufs queries has the following opcode after > >> + * SCSI_IOCTL_GET_PCI > >> + */ > >> +#define UFS_IOCTL_QUERY 0x5388 > > > > Use _IOWR() to define that number with

Re: [GIT PULL] qcom SoC changes for 4.2-1

2015-06-01 Thread Arnd Bergmann
On Friday 29 May 2015 14:42:01 Arnd Bergmann wrote: On Thursday 28 May 2015 10:55:39 Kumar Gala wrote: Qualcomm ARM Based SoC Updates for v4.2-1 * Added Subsystem Power Manager (SPM) driver * Split out 32-bit specific SCM code * Added HDCP SCM call Pulled into next/drivers

Re: [GIT PULL] qcom arm64 dt changes for 4.2

2015-05-29 Thread Arnd Bergmann
On Tuesday 26 May 2015 14:23:24 Kumar Gala wrote: Qualcomm ARM64 Updates for v4.2 * Added SPMI PMIC Arbiter device tree node for MSM8916 * Added 8x16 chipset SPMI PMIC's nodes * Added MSM8916 restart device node * Added initial set of PMIC and SoC pins for APQ8016 SBC board I've pulled

Re: [GIT PULL] qcom defconfig changes for 4.2

2015-05-29 Thread Arnd Bergmann
On Tuesday 26 May 2015 14:35:22 Kumar Gala wrote: Qualcomm ARM Based defconfig Updates for v4.2 * Enable cpuidle for QCOM SoCs in qcom multi_v7_defconfig Pulled into next/defconfig, thanks! Arnd -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body

Re: [PATCH v3 01/10] ASoC: qcom: make lpass driver depend on OF

2015-05-22 Thread Arnd Bergmann
On Thursday 21 May 2015 22:52:41 Srinivas Kandagatla wrote: config SND_SOC_LPASS_CPU tristate + depends on OF select REGMAP_MMIO config SND_SOC_LPASS_PLATFORM tristate + depends on OF select REGMAP_MMIO config SND_SOC_LPASS_IPQ806X

Re: [PATCH v3 01/10] ASoC: qcom: make lpass driver depend on OF

2015-05-22 Thread Arnd Bergmann
On Friday 22 May 2015 09:24:35 Arnd Bergmann wrote: Could you instead make the drivers compile without OF being set? I see that patch 7 and 8 introduces another two options doing +config SND_SOC_LPASS_APQ8016 + tristate + depends on SND_SOC_QCOM + select

Re: [PATCH v3 01/10] ASoC: qcom: make lpass driver depend on OF

2015-05-22 Thread Arnd Bergmann
On Friday 22 May 2015 12:53:44 Srinivas Kandagatla wrote: Thanks for looking at this patch. On 22/05/15 08:24, Arnd Bergmann wrote: On Thursday 21 May 2015 22:52:41 Srinivas Kandagatla wrote: config SND_SOC_LPASS_CPU tristate + depends on OF select

Re: [PATCH v4 3/3] ASoC: qcom: fix STORM board Kconfig

2015-05-22 Thread Arnd Bergmann
On Friday 22 May 2015 16:54:17 Srinivas Kandagatla wrote: diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig index 6ecac6c..f50197e 100644 --- a/sound/soc/qcom/Kconfig +++ b/sound/soc/qcom/Kconfig @@ -26,7 +26,7 @@ config SND_SOC_LPASS_APQ8016 config SND_SOC_STORM

Re: [PATCH v2 5/5] ARM: qcom: Add Qualcomm APQ8084 SoC

2015-05-22 Thread Arnd Bergmann
On Friday 22 May 2015 11:22:52 Stephen Boyd wrote: diff --git a/arch/arm/mach-qcom/Kconfig b/arch/arm/mach-qcom/Kconfig index 2256cd1..9cfebee 100644 --- a/arch/arm/mach-qcom/Kconfig +++ b/arch/arm/mach-qcom/Kconfig @@ -22,4 +22,11 @@ config ARCH_MSM8974 bool Enable support for

[PATCH] ASoC: qcom: remove incorrect dependencies

2015-05-21 Thread Arnd Bergmann
, but the symbols it selects have a dependency. Dropping the dependencies makes it work without warnings and no other side-effects, because these are not user-visible. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: f380dd3f3cd (ASoC: qcom: Add ability to build QCOM drivers) diff --git a/sound/soc/qcom

Re: [PATCH] ASoC: qcom: remove incorrect dependencies

2015-05-21 Thread Arnd Bergmann
On Thursday 21 May 2015 14:00:00 Kenneth Westfield wrote: diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig index 5f58e4f1bca9..b07f183fc47f 100644 --- a/sound/soc/qcom/Kconfig +++ b/sound/soc/qcom/Kconfig @@ -6,12 +6,10 @@ config SND_SOC_QCOM config SND_SOC_LPASS_CPU

Re: [RFC PATCH 5/5] arm64: qcom: add cpu operations

2015-04-14 Thread Arnd Bergmann
On Tuesday 14 April 2015 17:29:53 Mark Rutland wrote: +static int msm_cpu_boot(unsigned int cpu) +{ + int ret = 0; + + if (per_cpu(cold_boot_done, cpu) == false) { + ret = msm_unclamp_secondary_arm_cpu(cpu); + if (ret) +

Re: [RFC PATCH v2 4/4] arm64: qcom: add cpu operations

2015-04-10 Thread Arnd Bergmann
On Friday 10 April 2015 15:43:25 Kumar Gala wrote: +static int qcom_cpu_boot(unsigned int cpu) +{ + int ret = 0; + + if (per_cpu(cold_boot_done, cpu) == false) { + ret = qcom_unclamp_secondary_arm_cpu(cpu); + if (ret) + return

Re: [RFC PATCH 3/5] arm64: introduce CPU_OF_TABLES for cpu ops selection

2015-04-09 Thread Arnd Bergmann
On Thursday 09 April 2015 12:37:09 Kumar Gala wrote: @@ -67,4 +67,9 @@ extern const struct cpu_operations *cpu_ops[NR_CPUS]; int __init cpu_read_ops(struct device_node *dn, int cpu); void __init cpu_read_bootcpu_ops(void); +#define CPU_METHOD_OF_DECLARE(name, __ops)

Re: [RFC PATCH 5/5] arm64: qcom: add cpu operations

2015-04-09 Thread Arnd Bergmann
On Thursday 09 April 2015 12:37:11 Kumar Gala wrote: From: Abhimanyu Kapur abhim...@codeaurora.org Add qcom cpu operations for arm-v8 cpus. Implement secondary cpu boot ops As a part of this change update device tree documentation for: 1. Arm cortex-a ACC device which provides percpu reg

Re: [RFC PATCH 4/5] arm64: smp: move the pen to a header file

2015-04-09 Thread Arnd Bergmann
On Thursday 09 April 2015 12:37:10 Kumar Gala wrote: From: Abhimanyu Kapur abhim...@codeaurora.org Move the secondary_pen_release variable and the secondary_holding_pen entry function to asm/smp_plat.h so that the other cpu ops implementations can share them. Signed-off-by: Abhimanyu

Re: [PATCH 00/12] Remove mach-msm and associated code

2015-03-13 Thread Arnd Bergmann
On Friday 13 March 2015 20:55:30 Arnd Bergmann wrote: I think the MMC driver should also be removed when the platform code is deleted, new code would use the mmci driver anyway. Nevermind, I now see patch 6/12, which does just this. Arnd -- To unsubscribe from this list: send

Re: [PATCH 00/12] Remove mach-msm and associated code

2015-03-13 Thread Arnd Bergmann
On Friday 13 March 2015 11:09:33 Stephen Boyd wrote: The maintainers for mach-msm no longer have any plans to support or test the platforms supported by this architecture[1]. Most likely there aren't any active users of this code anyway, so let's delete it and the associated drivers/code. We

Re: [RFC PATCH 00/18] ARM: msm multiplatform support

2015-03-12 Thread Arnd Bergmann
On Saturday 07 March 2015 03:12:12 dwal...@fifo99.com wrote: On Wed, Mar 04, 2015 at 08:32:54PM +0100, Arnd Bergmann wrote: This is my final piece of the puzzle for ARMv6/v7 multiplatform support. In combination with the other patches that are now at git://kernel.org/pub/scm/linux/kernel

Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id

2015-03-11 Thread Arnd Bergmann
On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote: But are these values actually used by the boot loader? As far as I could see in 8974 the dtbTool provided by Qualcomm extracts the values from the list of dtbs and use them to create the table-of-content in the QCDT blob. The boot

Re: [PATCH v2 1/3] devicetree: bindings: Document qcom,msm-id and qcom,board-id

2015-03-11 Thread Arnd Bergmann
On Wednesday 11 March 2015 15:35:22 Kumar Gala wrote: On Mar 11, 2015, at 3:20 PM, Arnd Bergmann a...@arndb.de wrote: On Wednesday 11 March 2015 08:33:04 Bjorn Andersson wrote: But are these values actually used by the boot loader? As far as I could see in 8974 the dtbTool provided

  1   2   3   >