* Re: [PATCH 01/10] genirq: Export irq_set_msi_desc()
From: Thomas Gleixner @ 2017-11-24 23:55 UTC (permalink / raw)
To: Manikanta Maddireddy
Cc: thierry.reding, jonathanh, robh+dt, frowand.list, bhelgaas, rjw,
vidyas, kthota, linux-tegra, devicetree, linux-pci, linux-pm,
Marc Zyngier
In-Reply-To: <1511538800-8275-2-git-send-email-mmaddireddy@nvidia.com>
On Fri, 24 Nov 2017, Manikanta Maddireddy wrote:
Please CC the proper mailing list for irq related changes.
> PCI bus support MSI interrupts, allow PCI host driver to set MSI descriptor
> data for an irq.
This is not really an explanation why this export is needed.
Thanks,
tglx
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> ---
> kernel/irq/chip.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index 5a2ef92c2782..bfbd17386bc4 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -136,6 +136,7 @@ int irq_set_msi_desc(unsigned int irq, struct msi_desc *entry)
> {
> return irq_set_msi_desc_off(irq, 0, entry);
> }
> +EXPORT_SYMBOL(irq_set_msi_desc);
>
> /**
> * irq_set_chip_data - set irq chip data for an irq
> --
> 2.1.4
>
>
^ permalink raw reply
* Re: [PATCH 03/10] PM / QoS: Fix device resume latency for non PM QoS devices
From: Rafael J. Wysocki @ 2017-11-25 0:02 UTC (permalink / raw)
To: Thierry Reding
Cc: Rafael J. Wysocki, Manikanta Maddireddy, Jon Hunter, Rob Herring,
Frank Rowand, Bjorn Helgaas, Rafael J. Wysocki, Thomas Gleixner,
vidyas-DDmLM1+adcrQT0dZR+AlfA, kthota-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux PCI,
Linux PM
In-Reply-To: <20171124203940.GA12811@mithrandir>
On Fri, Nov 24, 2017 at 9:39 PM, Thierry Reding
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Fri, Nov 24, 2017 at 05:50:42PM +0100, Rafael J. Wysocki wrote:
>> On Fri, Nov 24, 2017 at 4:53 PM, Manikanta Maddireddy
>> <mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> > In 'commit 0cc2b4e5a020 ("PM / QoS: Fix device resume latency PM QoS")'
>> > PM QoS resume latency modified 0 as "no latency at all". However
>> > dev_pm_qos_raw_read_value() returns 0 for devices which doesn't have
>> > PM QoS constraints. This is blocking runtime suspend for these devices
>> > in rpm_check_suspend_allowed(). Return PM_QOS_RESUME_LATENCY_NO_CONSTRAINT
>> > when PM QoS constraints are not available for a particular device.
>> >
>> > Fixes: 0cc2b4e5a020 ("PM / QoS: Fix device resume latency PM QoS")
>>
>> That commit has been reverted, so this patch is not applicable and
>> therefore the whole series isn't.
>>
>> What kernel is it based off?
>
> It looks like this might have crept in via commit 0759e80b84e3 ("PM /
> QoS: Fix device resume latency framework"). But checking more closely,
> that commit actually incorporates this change already.
>
> According to the git log the correct commit for this showed up in
> linux-next only today, which is probably why Manikanta missed it.
Well, it's been in the Linus' tree for a week, though.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH 2/2] clocksource: sprd: Add timer driver for Spreadtrum SC9860 platform
From: kbuild test robot @ 2017-11-25 4:49 UTC (permalink / raw)
Cc: kbuild-all, daniel.lezcano, tglx, robh+dt, mark.rutland,
devicetree, linux-kernel, broonie, baolin.wang, baolin.wang
In-Reply-To: <58d686b831e2509d6fc29fbe61dc610902c250c3.1511501514.git.baolin.wang@spreadtrum.com>
[-- Attachment #1: Type: text/plain, Size: 4617 bytes --]
Hi Baolin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/timers/core]
[also build test WARNING on v4.14 next-20171124]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Baolin-Wang/dt-bindings-clocksource-Add-Spreadtrum-SC9860-timer/20171125-090749
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from arch/x86/include/asm/realmode.h:14:0,
from arch/x86/include/asm/acpi.h:33,
from arch/x86/include/asm/fixmap.h:19,
from arch/x86/include/asm/apic.h:10,
from arch/x86/include/asm/smp.h:12,
from include/linux/smp.h:63,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/idr.h:16,
from include/linux/kernfs.h:14,
from include/linux/sysfs.h:15,
from include/linux/kobject.h:21,
from include/linux/of.h:21,
from include/linux/clocksource.h:18,
from drivers/clocksource/sprd-timer.c:7:
drivers/clocksource/sprd-timer.c: In function 'sprd_timer_update_counter':
>> drivers/clocksource/sprd-timer.c:85:24: warning: right shift count >= width of type [-Wshift-count-overflow]
writel_relaxed(cycles >> TIMER_VALUE_HI_SHIFT,
^
arch/x86/include/asm/io.h:87:39: note: in definition of macro 'writel_relaxed'
#define writel_relaxed(v, a) __writel(v, a)
^
vim +85 drivers/clocksource/sprd-timer.c
> 7 #include <linux/clocksource.h>
8 #include <linux/clockchips.h>
9 #include <linux/init.h>
10 #include <linux/interrupt.h>
11 #include <linux/sched_clock.h>
12 #include <linux/slab.h>
13 #include <linux/of.h>
14 #include <linux/of_address.h>
15 #include <linux/of_irq.h>
16
17 #define TIMER_NAME "sprd_timer"
18
19 #define TIMER_LOAD_LO 0x0
20 #define TIMER_LOAD_HI 0x4
21 #define TIMER_VALUE_LO 0x8
22 #define TIMER_VALUE_HI 0xc
23
24 #define TIMER_CTL 0x10
25 #define TIMER_CTL_PERIOD_MODE BIT(0)
26 #define TIMER_CTL_ENABLE BIT(1)
27 #define TIMER_CTL_64BIT_WIDTH BIT(16)
28
29 #define TIMER_INT 0x14
30 #define TIMER_INT_EN BIT(0)
31 #define TIMER_INT_RAW_STS BIT(1)
32 #define TIMER_INT_MASK_STS BIT(2)
33 #define TIMER_INT_CLR BIT(3)
34
35 #define TIMER_VALUE_SHDW_LO 0x18
36 #define TIMER_VALUE_SHDW_HI 0x1c
37
38 #define TIMER_VALUE_LO_MASK GENMASK(31, 0)
39 #define TIMER_VALUE_HI_SHIFT 32
40
41 struct sprd_timer_device {
42 struct clock_event_device ce;
43 void __iomem *base;
44 u32 freq;
45 int irq;
46 };
47
48 static inline struct sprd_timer_device *
49 to_sprd_timer(struct clock_event_device *c)
50 {
51 return container_of(c, struct sprd_timer_device, ce);
52 }
53
54 static void sprd_timer_enable(struct sprd_timer_device *timer, u32 flag)
55 {
56 u32 val = readl_relaxed(timer->base + TIMER_CTL);
57
58 val |= TIMER_CTL_ENABLE;
59 if (flag & TIMER_CTL_64BIT_WIDTH)
60 val |= TIMER_CTL_64BIT_WIDTH;
61 else
62 val &= ~TIMER_CTL_64BIT_WIDTH;
63
64 if (flag & TIMER_CTL_PERIOD_MODE)
65 val |= TIMER_CTL_PERIOD_MODE;
66 else
67 val &= ~TIMER_CTL_PERIOD_MODE;
68
69 writel_relaxed(val, timer->base + TIMER_CTL);
70 }
71
72 static void sprd_timer_disable(struct sprd_timer_device *timer)
73 {
74 u32 val = readl_relaxed(timer->base + TIMER_CTL);
75
76 val &= ~TIMER_CTL_ENABLE;
77 writel_relaxed(val, timer->base + TIMER_CTL);
78 }
79
80 static void sprd_timer_update_counter(struct sprd_timer_device *timer,
81 unsigned long cycles)
82 {
83 writel_relaxed(cycles & TIMER_VALUE_LO_MASK,
84 timer->base + TIMER_LOAD_LO);
> 85 writel_relaxed(cycles >> TIMER_VALUE_HI_SHIFT,
86 timer->base + TIMER_LOAD_HI);
87 }
88
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 61854 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] clocksource: sprd: Add timer driver for Spreadtrum SC9860 platform
From: kbuild test robot @ 2017-11-25 5:00 UTC (permalink / raw)
Cc: kbuild-all, daniel.lezcano, tglx, robh+dt, mark.rutland,
devicetree, linux-kernel, broonie, baolin.wang, baolin.wang
In-Reply-To: <58d686b831e2509d6fc29fbe61dc610902c250c3.1511501514.git.baolin.wang@spreadtrum.com>
[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]
Hi Baolin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/timers/core]
[also build test WARNING on v4.14 next-20171124]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Baolin-Wang/dt-bindings-clocksource-Add-Spreadtrum-SC9860-timer/20171125-090749
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
In file included from include/linux/swab.h:4:0,
from include/uapi/linux/byteorder/big_endian.h:12,
from include/linux/byteorder/big_endian.h:4,
from arch/arm/include/uapi/asm/byteorder.h:19,
from include/asm-generic/bitops/le.h:5,
from arch/arm/include/asm/bitops.h:340,
from include/linux/bitops.h:37,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/uapi/linux/timex.h:56,
from include/linux/timex.h:56,
from include/linux/clocksource.h:12,
from drivers/clocksource/sprd-timer.c:7:
drivers/clocksource/sprd-timer.c: In function 'sprd_timer_update_counter':
drivers/clocksource/sprd-timer.c:85:24: warning: right shift count >= width of type [-Wshift-count-overflow]
writel_relaxed(cycles >> TIMER_VALUE_HI_SHIFT,
^
include/uapi/linux/swab.h:113:54: note: in definition of macro '__swab32'
#define __swab32(x) (__u32)__builtin_bswap32((__u32)(x))
^
include/linux/byteorder/generic.h:87:21: note: in expansion of macro '__cpu_to_le32'
#define cpu_to_le32 __cpu_to_le32
^~~~~~~~~~~~~
>> drivers/clocksource/sprd-timer.c:85:2: note: in expansion of macro 'writel_relaxed'
writel_relaxed(cycles >> TIMER_VALUE_HI_SHIFT,
^~~~~~~~~~~~~~
vim +/writel_relaxed +85 drivers/clocksource/sprd-timer.c
79
80 static void sprd_timer_update_counter(struct sprd_timer_device *timer,
81 unsigned long cycles)
82 {
83 writel_relaxed(cycles & TIMER_VALUE_LO_MASK,
84 timer->base + TIMER_LOAD_LO);
> 85 writel_relaxed(cycles >> TIMER_VALUE_HI_SHIFT,
86 timer->base + TIMER_LOAD_HI);
87 }
88
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 64025 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: add minimal device tree for compute model 3
From: Stefan Wahren @ 2017-11-25 9:50 UTC (permalink / raw)
To: kernel
Cc: Mark Rutland, devicetree, Florian Fainelli, Catalin Marinas,
Russell King, eric, Rob Herring, linux-rpi-kernel,
linux-arm-kernel
In-Reply-To: <84679F1A-7EF2-44FD-B8CC-F2D01C313E17@martin.sperl.org>
Hi Martin,
> kernel@martin.sperl.org hat am 25. November 2017 um 08:32 geschrieben:
>
>
>
> > On 24.11.2017, at 21:57, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> > Since we need always 2 boards (SoM + carrier), i like to see two separate DT files. A DTSI file for the SoM (describe RAM, eMMC) and a DTS file for the carrier board (please look at arm/boot/dts/imx6ul-tx6ul.dtsi and arm/boot/dts/imx6ul-tx6ul-mainboard.dts as an example).
> >
> > Suggested include hierarchy:
> >
> > bcm2837.dtsi
> > bcm2837-rpi-cm3.dtsi
> > bcm2837-rpi-cm3-io3.dts
> >
>
> I shall give it a try.
>
> But it would require possibly 2 versions of the cm-module:
> * the one including emmc
> * the one exposing the sd-card ports/pins (CM3-Lite)
I don't have those modules. In case it's possible to create a DTSI which applies for both of them then i prefer this. In theory there are two extremes:
1) Create a DTS for all Compute Modules (like the Raspberry Pi foundation)
2) Create DTS/DTSI files for all possible combinations
I think none of them are practical. In case 1 3rd party vendors would start to copy the DTS file and case 2 is hard to maintain. So we need to try something in the middle by starting with a DTSI file which applies to all CM3 (including the Lite) and a DTS which applies to all Raspberry Pi IO Boards and include the CM3 DTSI.
>
> But then I could go as far as including the “classic” CM V1 as well...
Yeah, that's the idea.
>
> >> bcm2835-rpi-zero.dtb \
> >> bcm2835-rpi-zero-w.dtb
> >> dtb-$(CONFIG_ARCH_BCM_5301X) += \
> >> diff --git a/arch/arm/boot/dts/bcm2837-rpi-cm3.dts b/arch/arm/boot/dts/bcm2837-rpi-cm3.dts
> >> new file mode 100644
> >> index 000000000000..f387bd8bd707
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/bcm2837-rpi-cm3.dts
> >> @@ -0,0 +1,38 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/dts-v1/;
> >> +#include "bcm2837.dtsi"
> >> +#include "bcm2835-rpi.dtsi"
> >> +#include "bcm283x-rpi-usb-host.dtsi"
> >> +
> >> +/ {
> >> + compatible = "raspberrypi,3-compute-model", "brcm,bcm2837";
> >
> > s/compute-model/compute-module/
Btw i forgot to mention this needs to be documented here [1] in a separate patch.
> >
> >> + model = "Raspberry Pi Compute Module 3";
> >
> > Raspberry Pi Compute Module 3 on a IO board V3
> >
>
> That is not necessarily true - I am running the CM3 on a IO-board v1 so that one is compatible…
AFAIK this combination is not recommend, because the old IO board doesn't provide enough power for all use cases. But that's not the point about my comment. We need to describe the combination.
How about "Raspberry Pi Compute Module 3 on a IO board" and "bcm2837-rpi-cm3-io.dts" ?
>
> >>
> >> +/* SDHOST is used to drive the SD card */
> >
> > Since this is an eMMC please drop this misleading comment.
> >
>
> for a CM3-Lite it is exposing sd card pins
>
> >> +&sdhost {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&sdhost_gpio48>;
> >> + status = "okay";
> >> + bus-width = <4>;
> >
> > non-removable;
>
> See comment about Lite...
Okay, i'm fine without it but then we need a comment that the upcoming DTSI should apply to CM3 and CM3-Lite. Also the commit log should mention the CM3-Lite so everybody understand it.
Please wait a little bit before sending your second version to give the others some time for comments.
Thanks
Stefan
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt
>
> Martin
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: imx6qdl-nitrogen6x: Add SPI NOR partitions
From: Otavio Salvador @ 2017-11-25 9:55 UTC (permalink / raw)
To: Otavio Salvador
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Gary Bisson, Fabio Estevam,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sascha Hauer,
Kernel development list, Rob Herring, Mark Rutland, Russell King,
Shawn Guo
In-Reply-To: <20171124170004.31133-1-otavio-fKevB0iiKLMBZ+LybsDmbA@public.gmane.org>
On Fri, Nov 24, 2017 at 3:00 PM, Otavio Salvador
<otavio-fKevB0iiKLMBZ+LybsDmbA@public.gmane.org> wrote:
> This adds the partitions definition for the SPI NOR to provide
> backward compatibility with the documented[1] layout used with
> Boundary Devices BSP.
>
> 1. https://boundarydevices.com/boot-flash-access-linux/
>
> It exports to Linux:
>
> mtd0: bootloader
> mtd1: env
> mtd2: splash
>
> Signed-off-by: Otavio Salvador <otavio-fKevB0iiKLMBZ+LybsDmbA@public.gmane.org>
After thinking a bit about Fabio's recommendation to use 'read-only'
to protect the partitions, I think it'd be better to use 'lock' so it
is still possible to write them on Linux but it requires a unlock
prior changing it.
In my case, I am interested in being capable of upgrading the
bootloader from Linux.
What people think?
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/2] pinctrl: sunxi: Fix H5 MMC access
From: Andre Przywara @ 2017-11-25 12:01 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: Linus Walleij, Rob Herring, Chris Obbard, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Commit 1396007286b1 ("pinctrl: sunxi: Enforce the strict mode by default")
enabled the strict mode for the H5 pin controller driver, so that it denies
multiple requests for a single pin.
However the existing DTs for the Allwinner H5 boards reference the CD pin
for the micro SD card (MMC0) *twice* in their node, so that the driver
stumbles upon the new strict mode and refuses to load:
...
sun50i-h5-pinctrl 1c20800.pinctrl: pin PF6 already requested by 1c0f000.mmc; cannot claim for 1c20800.pinctrl:166
sun50i-h5-pinctrl 1c20800.pinctrl: pin-166 (1c20800.pinctrl:166) status -22
sunxi-mmc: probe of 1c0f000.mmc failed with error -22
...
This prevents booting (from SD cards) on H5 boards.
This can be rather easily fixed by removing the redundant CD pin reference
from the pinctrl-0 property of the MMC0 node, which patch 1/2 actually does.
However this now prevents existing DTs to boot with newer kernels (current
Linus' HEAD, for instance), so we have to disable strict mode for the H5
as well (as we do with other SoCs already, including the H3).
Tested on the OrangePi PC2:
- current 4.15-rc0 boots with fixed DT (patch 1/2), but fails with older DTs
- 4.14 (and older) kernels boot with both older and this fixed DT
- 4.15-rc0 with patch 2/2 applied boots with both older and this fixed DTs
Thanks to Chris Obbard for reporting this.
Cheers,
Andre.
P.S. I was wondering if we should teach the MMC driver to cope with failing
CD pin requests or let it detect the redundancy and avoid the second GPIO
request instead. AFAICT this would allow to enable strict mode for the H5
again?
Andre Przywara (2):
arm64: dts: allwinner: H5: remove redundant MMC0 card detect pin
pinctrl: sunxi: Disable strict mode for H5 driver
arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts | 2 +-
drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c | 6 ++++--
6 files changed, 9 insertions(+), 7 deletions(-)
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] arm64: dts: allwinner: H5: remove redundant MMC0 card detect pin
From: Andre Przywara @ 2017-11-25 12:01 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: Linus Walleij, Rob Herring, Chris Obbard, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171125120200.23294-1-andre.przywara-5wv7dgnIgG8@public.gmane.org>
PF6 is mostly used as the CD pin for the microSD slot on H5 based
boards. So far we were referencing this pin twice: once using the
mmc0_cd_pin phandle, and then again directly as a GPIO via the pinctrl
phandle.
This will cause problems if the pinctrl driver enables strict mode, as
the second request will fail now, leading to a driver init failure.
Remove the redundant pin reference via the mmc0_cd_pin phandle.
Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
Reported-by: Chris Obbard <obbardc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts
index 7c028af58f47..ea1101293892 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo-plus2.dts
@@ -135,7 +135,7 @@
&mmc0 {
pinctrl-names = "default";
- pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ pinctrl-0 = <&mmc0_pins_a>;
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts
index 6eb8092d8e57..f1447003ea3c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-nanopi-neo2.dts
@@ -127,7 +127,7 @@
&mmc0 {
pinctrl-names = "default";
- pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ pinctrl-0 = <&mmc0_pins_a>;
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
index a0ca925175aa..9e51d3a5f4e6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
@@ -161,7 +161,7 @@
&mmc0 {
pinctrl-names = "default";
- pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ pinctrl-0 = <&mmc0_pins_a>;
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
index b47790650144..0f25c4a6f15d 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-prime.dts
@@ -168,7 +168,7 @@
&mmc0 {
pinctrl-names = "default";
- pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ pinctrl-0 = <&mmc0_pins_a>;
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
index b6b7a561df8c..69ac04516ddb 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
@@ -68,7 +68,7 @@
&mmc0 {
pinctrl-names = "default";
- pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ pinctrl-0 = <&mmc0_pins_a>;
vmmc-supply = <®_vcc3v3>;
bus-width = <4>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>;
--
2.14.1
^ permalink raw reply related
* [PATCH 2/2] pinctrl: sunxi: Disable strict mode for H5 driver
From: Andre Przywara @ 2017-11-25 12:02 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: Linus Walleij, Rob Herring, Chris Obbard, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171125120200.23294-1-andre.przywara-5wv7dgnIgG8@public.gmane.org>
All of the H5 boards in the kernel reference the MMC0 CD pin twice in
their DT, so strict mode will make the MMC driver fail to load.
To keep existing DTs working, disable strict mode in the H5 driver.
Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
Reported-by: Chris Obbard <obbardc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
index 97b48336f84a..a78d7b922ef4 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
@@ -535,14 +535,16 @@ static const struct sunxi_pinctrl_desc sun50i_h5_pinctrl_data_broken = {
.pins = sun50i_h5_pins,
.npins = ARRAY_SIZE(sun50i_h5_pins),
.irq_banks = 2,
- .irq_read_needs_mux = true
+ .irq_read_needs_mux = true,
+ .disable_strict_mode = true,
};
static const struct sunxi_pinctrl_desc sun50i_h5_pinctrl_data = {
.pins = sun50i_h5_pins,
.npins = ARRAY_SIZE(sun50i_h5_pins),
.irq_banks = 3,
- .irq_read_needs_mux = true
+ .irq_read_needs_mux = true,
+ .disable_strict_mode = true,
};
static int sun50i_h5_pinctrl_probe(struct platform_device *pdev)
--
2.14.1
^ permalink raw reply related
* Re: [PATCH 0/2] Microchip mcp2517fd can controller driver
From: Oliver Hartkopp @ 2017-11-25 12:03 UTC (permalink / raw)
To: kernel
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland,
linux-can, devicetree
In-Reply-To: <20171124183509.12810-1-kernel@martin.sperl.org>
Hello Martin,
thanks for the contribution!
Unfortunately [PATCH 2/2] only hit the devicetree mailing list but not
the linux-can mailing list for the review.
Btw. I already have two questions from the description:
On 11/24/2017 07:35 PM, kernel@martin.sperl.org wrote:
(..)
> The driver has been heavily optimized so that it can handle
> a 100% utilized 1MHz Can-bus (with 11 bit can frames with DLC=0)
> even on less powerfull SOCs like the raspberry pi 1 without
> dropping frames due to driver/spi latencies
(..)
> The driver implements a lock-less design for transmissions
> making use instead of prepared spi messages submitted via spi_async
> for transmission in the start_xmit_start code without requireing
> an extra workqueue and the corresponding latencies.
Seems you improved the SPI handling here. Would it make sense to
separate the SPI-related part of the code to a separate C-file so that
the existing mcp251x driver can benefit from these improvements too?
> (still dropps are observed in the can/network stack).
Are you sure drops are taking place in the network layer? Can you give
me some more details about this statement?
Best regards,
Oliver
^ permalink raw reply
* [PATCH] ARM: dts: bcm283x: Use GPIO polarity defines consequently
From: Stefan Wahren @ 2017-11-25 13:34 UTC (permalink / raw)
To: Eric Anholt, Florian Fainelli, Rob Herring, Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Stefan Wahren
Currently most of the Raspberry Pi DTS have a mixture of magic
numbers and the proper GPIO polarity defines. So use the latter
one consequently.
Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
---
arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 4 ++--
arch/arm/boot/dts/bcm2835-rpi-a.dts | 2 +-
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 4 ++--
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 2 +-
arch/arm/boot/dts/bcm2835-rpi-b.dts | 2 +-
arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 4 ++--
arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
index f81ae0a..aa1fc7b 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
@@ -10,12 +10,12 @@
leds {
act {
- gpios = <&gpio 47 0>;
+ gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
};
pwr {
label = "PWR";
- gpios = <&gpio 35 0>;
+ gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
default-state = "keep";
linux,default-trigger = "default-on";
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-a.dts b/arch/arm/boot/dts/bcm2835-rpi-a.dts
index 7a960a0..425f6b0 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-a.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-a.dts
@@ -10,7 +10,7 @@
leds {
act {
- gpios = <&gpio 16 1>;
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
};
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index 0161a84..effa195 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -11,12 +11,12 @@
leds {
act {
- gpios = <&gpio 47 0>;
+ gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
};
pwr {
label = "PWR";
- gpios = <&gpio 35 0>;
+ gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
default-state = "keep";
linux,default-trigger = "default-on";
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index 4bc70ef..772ec3b 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -11,7 +11,7 @@
leds {
act {
- gpios = <&gpio 16 1>;
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
};
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index cca4a75..434483d 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -11,7 +11,7 @@
leds {
act {
- gpios = <&gpio 16 1>;
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
};
};
};
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index 6669355..5c339ad 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -15,12 +15,12 @@
leds {
act {
- gpios = <&gpio 47 0>;
+ gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
};
pwr {
label = "PWR";
- gpios = <&gpio 35 0>;
+ gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
default-state = "keep";
linux,default-trigger = "default-on";
};
diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
index a8844d0..3e4ed7c 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -20,7 +20,7 @@
leds {
act {
- gpios = <&gpio 47 0>;
+ gpios = <&gpio 47 GPIO_ACTIVE_HIGH>;
};
};
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] iio: adc: aspeed: Deassert reset in probe
From: Jonathan Cameron @ 2017-11-25 14:22 UTC (permalink / raw)
To: Joel Stanley
Cc: Jonathan Cameron, Philipp Zabel, Rick Altherr, Rob Herring,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio-u79uwXL29TY76Z2rM5mHXA, devicetree, LKML
In-Reply-To: <CACPK8XdwpKOLydSvdfNY0D049ysCc526Vj8E1Om3VVkWbVuhdg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 20 Nov 2017 15:22:38 +1030
Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org> wrote:
> On Mon, Nov 20, 2017 at 2:33 AM, Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Thu, 2 Nov 2017 14:49:32 +0000
> > Jonathan Cameron <Jonathan.Cameron-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
> >> IIO is closed for this cycle anyway now.
> >> Otherwise, series looks good.
> >>
> >> Will pick up when back with my main PC as traveling for this week and
> >> next.
> >
> > Forgot to ask, do you want me to pick this up as a fix?
> > Also does it make sense to tag it for stable?
> >
> > If not I can pick it up for the coming cycle. Given the code changes
> > are small and well isolated I'm happy to do any of the 3 options,
> > it really depends on whether the rest of the platform works well enough
> > to be worth rushing these through?
>
> Without the clock driver upstream there's no rush to merge this. I'm
> still waiting on review from the clock guys.
>
> Please queue them for 4.16. Thanks!
Done - applied to the togreg branch of iio.git which will be pushed
out as testing for the autobuilders to play with it.
Thanks,
Jonathan
>
> Cheers,
>
> Joel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 09/12] IIO: ADC: add stm32 DFSDM support for PDM microphone
From: Jonathan Cameron @ 2017-11-25 14:36 UTC (permalink / raw)
To: Arnaud Pouliquen
Cc: Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Jaroslav Kysela, Takashi Iwai,
Liam Girdwood, Mark Brown,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
Maxime Coquelin, Alexandre TORGUE
In-Reply-To: <4362763f-2182-a3cf-cbd6-6c71df59af52-qxv4g6HH51o@public.gmane.org>
On Fri, 24 Nov 2017 15:52:26 +0100
Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org> wrote:
> On 11/19/2017 03:18 PM, Jonathan Cameron wrote:
> > On Thu, 9 Nov 2017 11:12:31 +0100
> > Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org> wrote:
> >
> >> This code offers a way to handle PDM audio microphones in
> >> ASOC framework. Audio driver should use consumer API.
> >> A specific management is implemented for DMA, with a
> >> callback, to allows to handle audio buffers efficiently.
> >>
> >> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen-qxv4g6HH51o@public.gmane.org>
> >
> > A few minor points inline. I'm not sure I really 'like' the
> > solution we've ended up with currently but if it works it will
> > do just fine for now :)
> >
> > Jonathan
> >
> >
> >> ---
> >> V3 -> V4 changes:
> >> - Merge audio implementation in stm32-dfsdm-adc.c instead of creating separate file
> >> - Add sysfs document for exported attributes
> >>
> >> .../ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 | 22 +
> >> drivers/iio/adc/stm32-dfsdm-adc.c | 517 ++++++++++++++++++++-
> >> include/linux/iio/adc/stm32-dfsdm-adc.h | 27 ++
> >> 3 files changed, 562 insertions(+), 4 deletions(-)
> >> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
> >> create mode 100644 include/linux/iio/adc/stm32-dfsdm-adc.h
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
> >> new file mode 100644
> >> index 0000000..0ce5508
> >> --- /dev/null
> >> +++ b/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
> >> @@ -0,0 +1,22 @@
> >> +What: /sys/bus/iio/devices/iio:deviceX/in_voltage_audio_sampling_rate
> >> +KernelVersion: 4.14
> >> +Contact: arnaud.pouliquen-qxv4g6HH51o@public.gmane.org
> >> +Description:
> >> + For audio purpose only.
> >> + Used by audio driver to set/get the audio sampling rate.
> >> + Reading returns current audio sample frequency.
> >> + Writing value before starting conversions.
> >
> > I would like to see a note here on why sampling_frequency can't be used for
> > this purpose.
> The IIO_CHAN_INFO_SAMP_FREQ can not be used because consumer API allows
> only to access to ext_info attributes.
> An alternate is to export channel attribute functions the consumer API.
> - iio_read_channel_attribute (already exist)
> - iio_write_channel_attribute
Yes - add these please. Just not been a usecase before for the general write.
>
> Please, tell me your preference.
<snip>
> >> +/**
> >> + * stm32_dfsdm_get_buff_cb - register a callback
> >> + * that will be called when DMA transfer period is achieved.
> > Please run kernel-doc over this file. I'm fairly sure this isn't
> > quite meeting the spec...
> Sorry it is not crystal clear for me, could you detail what you would
> mean by
> "I'm fairly sure this isn't quite meeting the spec.."?
I don't think it lets you have multiple lines for the short description
IIRC. Not sure about the indented function parameters.. Might be
new since I last looked!
>
> >
> >> + *
> >> + * @iio_dev: Handle to IIO device.
> >> + * @cb: pointer to callback function.
> >> + * @data: pointer to data buffer
> >> + * @size: size in byte of the data buffer
> >> + * @private: pointer to consumer private structure
> >> + * @private: pointer to consumer private structure
> >> + */
^ permalink raw reply
* Re: [PATCH 0/2] Microchip mcp2517fd can controller driver
From: kernel @ 2017-11-25 14:47 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland,
linux-can, devicetree
In-Reply-To: <3d355c51-09a3-40b8-46bf-8437e26a95f3@hartkopp.net>
Hi Oliver!
> On 25.11.2017, at 13:03, Oliver Hartkopp <socketcan@hartkopp.net> wrote:
>
> Hello Martin,
>
> thanks for the contribution!
>
> Unfortunately [PATCH 2/2] only hit the devicetree mailing list but not the linux-can mailing list for the review.
I have no idea why you have not received it, but I have sent all
of them to the same Recipient list!
I even got a relayed confirmation for all 3 of them:
19:35:28.689 2 DEQUEUER [7520159] SMTP(vger.kernel.org)linux-can@vger.kernel.org relayed: relayed via vger.kernel.org
19:35:29.823 2 DEQUEUER [7520154] SMTP(vger.kernel.org)linux-can@vger.kernel.org relayed: relayed via vger.kernel.org
19:35:31.902 2 DEQUEUER [7520160] SMTP(vger.kernel.org)linux-can@vger.kernel.org relayed: relayed via vger.kernel.org
So they should all have arrived!
>
> Btw. I already have two questions from the description:
>
> On 11/24/2017 07:35 PM, kernel@martin.sperl.org wrote:
>
> (..)
>
>> The driver has been heavily optimized so that it can handle
>> a 100% utilized 1MHz Can-bus (with 11 bit can frames with DLC=0)
>> even on less powerfull SOCs like the raspberry pi 1 without
>> dropping frames due to driver/spi latencies
>
> (..)
>
> > The driver implements a lock-less design for transmissions
> > making use instead of prepared spi messages submitted via spi_async
> > for transmission in the start_xmit_start code without requireing
> > an extra workqueue and the corresponding latencies.
>
> Seems you improved the SPI handling here. Would it make sense to separate the SPI-related part of the code to a separate C-file so that the existing mcp251x driver can benefit from these improvements too?
The biggest problem is that the Register-design of the mcp2517fd is totally
different compared to mcp251x, so most of those “optimizations” for the
mcp2517 do not apply to the mcp251x (SPI-API wise IMO the mcp2515 is much
more efficient - better still when having dedicated gpios for the RX lines
to avoid having to query the status first via spi (reduces latencies
and thus reduces packet loss/overflow on a saturated CAN bus).
I have a spi_async only version of the mcp251x as well (which has been dormant
for a long time, as the mcp251x stopped showing interrupt stopped issues...).
>
>> (still dropps are observed in the can/network stack).
>
> Are you sure drops are taking place in the network layer? Can you give me some more details about this statement?
Well - when I increase net->stat.rx_dropped there is always a
dev_warn_ratelimited that comes along. Also rx_errors is increased at the
same time. And I see the drops counters increase while there are no messages
in dmesg.
Also note that the driver is only incrementing rx_packets and rx_bytes only
when netif_rx_ni(skb) is called.
So the setup is this:
* raspberry pi 2 with the mcp2517fd
* beagle bone black
* 1MHz CAN2.0 bus
Beagle bone black:
root@beaglebone:~# cangen can0 -g0.0 -L0 -n 1000000 -p10 -Ii
This saturates the CAN BUS to 100%
on the RPI2 I have no consumer (candump or similar) and the module has
just been reloaded (counters are reset).
I see the following counters:
7: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
link/can promiscuity 0
can <ONE-SHOT,BERR-REPORTING> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 1000000 sample-point 0.750
tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1
mcp2517fd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
mcp2517fd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
clock 40000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
RX: bytes packets errors dropped overrun mcast
0 998774 703 4588 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
So you see that packets + dropped > transmitted (1000000).
In a different setup with 4 bytes of data payload:
root@beaglebone:~# cangen can0 -g0.0 -L0 -n 10000 -L4 -p10 -Ii
root@beaglebone:~# cangen can0 -g0.0 -L0 -n 100000 -L4 -p10 -Ii
I get the following statistics:
root@rasp2a:~# ip -details -statistics link show can0
8: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
link/can promiscuity 0
can <ONE-SHOT,BERR-REPORTING> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 1000000 sample-point 0.750
tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1
mcp2517fd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
mcp2517fd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
clock 40000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
RX: bytes packets errors dropped overrun mcast
440000 110000 0 4343 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
Here 1 get 100% reception rates (bytes and packets are exactly what they
are supposed to be) but still 0.1% dropped.
When CAN FD is configured on the mcp2517 then things look different
even on a RPI2:
root@beaglebone:~# cangen can0 -g0.0 -L0 -n 1000000 -L0 -p10 -Ii
root@rasp2a:~# ip -details -statistics link show can0
13: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
link/can promiscuity 0
can <ONE-SHOT,BERR-REPORTING,FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0
bitrate 1000000 sample-point 0.750
tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1
mcp2517fd: tseg1 2..256 tseg2 1..128 sjw 1..128 brp 1..256 brp-inc 1
dbitrate 2000000 dsample-point 0.750
dtq 25 dprop-seg 7 dphase-seg1 7 dphase-seg2 5 dsjw 1
mcp2517fd: dtseg1 1..32 dtseg2 1..16 dsjw 1..16 dbrp 1..256 dbrp-inc 1
clock 40000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
RX: bytes packets errors dropped overrun mcast
0 999840 3 752028 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
In this case the number of packets actually lost on the controller is 0.01%
But the number of dropped packets on the stack is 75%.
The shorter the interval the lower the dropped count.
Ciao,
Martin
P.s: For the last test-case here the fifo utilization statistics:
root@rasp2a:~# cat /sys/kernel/debug/mcp2517fd-can0/fifo_usage/* | awk '{ C=C+$1; printf "%8i %s\n",C,$0}’
Total Count/fifo
384401 384401
674306 289905
960133 285827
990117 29984
994351 4234
996745 2394
997668 923
998217 549
998593 376
998849 256
999059 210
999240 181
999385 145
999508 123
999604 96
999680 76
999745 65
999797 52
999840 43
root@rasp2a:~# cat /sys/kernel/debug/mcp2517fd-can0/rx/fifo_count
19
root@rasp2a:~# dmesg
[77843.229423] mcp2517fd spi0.0: RX MAB overflow
[77856.329824] mcp2517fd spi0.0: RX MAB overflow
[77883.299221] mcp2517fd spi0.0: RX MAB overflow
These dmesg lines correspond with the errors (and would also increase “dropped” by 3)
^ permalink raw reply
* Re: [PATCH v2 3/3] iio: light: isl76683 add way to adjust irq threshold
From: Jonathan Cameron @ 2017-11-25 15:08 UTC (permalink / raw)
To: Christoph Fritz
Cc: Peter Meerwald-Stadler, Rob Herring,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1511262622.1737.96.camel-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
On Tue, 21 Nov 2017 12:10:22 +0100
Christoph Fritz <chf.fritz-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> Hi Jonathan,
>
> thanks for your input. Please see my questions and answers below.
>
> On Sun, 2017-11-19 at 11:26 +0000, Jonathan Cameron wrote:
> > On Sun, 19 Nov 2017 00:20:30 +0100
> > Christoph Fritz <chf.fritz-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> >
> > > This patch adds sysfs read/write support for upper and lower irq
> > > thresholds. So it's possible that only on certain lux ranges the
> > > irq triggered measurement happens.
> > >
> > > Signed-off-by: Christoph Fritz <chf.fritz-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> >
> > hmm, this is 'unusual' to say the least...
> >
> > From the datasheet it initially looks like a straight forward threshold
> > interrupt - which should be supported as an IIO event.
> >
> > However, there seems to not be a generic monitoring mode, but rather the
> > device has to be polled? (which makes this a 'funny' sort of interrupt..)
>
> It's not polling, it's just that in this "external timing mode" host has
> to do one part of adc integration timing (accurate waiting) on its own.
>
> This is suboptimal because doing timing in the driver cannot be that
> accurate as the external osc beside the chip with its "internal timing
> mode". To compensate this inaccuracy there are Timing-Registers which
> would then need to be red and finally calculated too.
>
> So I prefer "internal timing mode" (with IRQ) because I do get data as
> accurate and as fast as possible (especially in buffered mode) without
> the hassle of compensation.
Yes, that's fine, but as I read it you still need to actually start
the reading?
Reading on below I think I may have missunderstood this due to unfortunate
choice of function naming in the driver and frankly a less than clear
datasheet.
So, when in internal mode is this device:
1) Always capturing readings on a internally timed sequence?
2) Only capturing a reading when an explicit signal is sent to ask
it to do so?
>
> >
> > So I think you are ultimately using this threshold interrupt to provide
> > a dataready signal when there isn't a real one provided?
>
> I don't get this point. Why shouldn't the IRQ be a real data-ready
> signal?
Because it isn't. It's a data ready that only fires in some
circumstances, not simply when the data is ready...
I have no problem with an 'event' in IIO terminology (a
threshold pass) being used to provide a trigger. We have
devices already doing this - though we could provide better
generic infrastructure for it - but that doesn't make it
a dataready trigger. It's a threshold trigger.
>
> The usage is this:
> set threshold,
> in a loop for example(
> clear IRQ isl76683_start_measurement()
> now wait for IRQ which triggers when sensordata passes threshold
> read the data isl76683_get_sensordata()
> )
>
> What may confuse is that this chip needs to get the IRQ cleared before
> a next "data-ready-because-it-passed-threshold-IRQ"?
That's absolutely fine, but a data ready trigger is about data ready,
not some other condition AND data ready.
>
> By the way, without this patch sensordata always passes threshold and
> the IRQ is a real "data-ready-IRQ".
OK, in that case it is a valid data ready signal in the conventional
sense - but only in that case.
>
> >
> > That's horrible and makes it very hard to fit this device into standard
> > frameworks. My gut feeling would be to:
>
> If you don't like the adjustable threshold because you really feel it
> doesn't fit into iio-framework, you can purge patch 3 and I'll keep it
> away from mainline. And it would be great if you could
> reconsider :-) ...
The issue here is that we are introducing new ABI that no standard
userspace tooling is going to know what to do with. Hmm. Lets
think about how we could at least make this more standard that it is
and then consider that...
>
> >
> > * stop using the interrupt for data ready at all, but dead reckon
> > that with a timer delay.
>
> Please see my points above why using "internal timing mode" adds
> complexity.
Not really - you just add a slight margin (typically 10%) to the timing
you know it is set to and then read the data after that... Simple
sleep really.
>
> > * use this 'interrupt' (actually a hardware threshold signal rather than
> > an interrupt really)
>
> Please see above: Why shouldn't the IRQ be a real data-ready signal?
When we use the term data-ready it has to correspond to the standard
understanding of what a data ready signal is across other parts - otherwise
userspace will have no idea what to expect.
Data ready is used when you have an internally clocked sequencer that
generates a series of samples at a particular sampling frequency - each
set of which results in an interrupt.
I'm still not sure whether that is true here or not?
>
> > for event detection and handle it
> > as an event with all the standard infrastructure that is in place
> > for that.
> >
> > I can see the hardware designers logic that you might only want to read
> > the values back when the light level has changed from your expected value,
> > but given you have to manually trigger readings, the utility of this is
> > somewhat limited...
>
> No, adc readings are done continuously inside the chip if sensor value
> fails threshold test. You get an IRQ if light changes so that threshold
> test gets passed.
I'm really confused. Your driver seems to always start a capture manually.
Ah - maybe this is because what you have called it is:
isl76683_start_measurement when all it is actually doing is clearing
the interrupt and the documentation that says that it triggers
a new measurement is wrong?
If it just clears the interrupt to allow us to know when a new capture
has finished which would have been running anyway then rename it
to make that clear.
>
> What do you think?
That I'm really confused!
Anyhow I'm going to assume that we actually have a fully self clocked chip
here and that start measurement is actually 'reset_interrupt' which
allows us to see the end of the previous interrupt. If this is true
then we want the following changes at the minimum...
1) The reset should not be in the try_reenable callback of the trigger
- it is a facet of the trigger not the buffer - this also removes the
need to ensure this trigger is only used for this device. The initial
trigger enable can clear it once to start the process. The trigger
disable will ensure the reenable is not called again (check this - I'm
not 100% sure what the core will do and we may need to modify it slightly
or if we have to disable the irq to avoid false triggers after disable).
2) The threshold changes you are making here are characteristics of
the trigger not the device so the new ABI needs to be trigger abi
under /sys/bus/iio/devices/iio:triggerX/ not the device.
Whether we claim it is a dataready trigger with some 'quirks' or
a threshold trigger that we can set to fire for all values isn't
clear yet.
Jonathan
>
> Thanks
> -- Christoph
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] arm64: allwinner: a64: Enable AXP803 for Orangepi Win
From: Maxime Ripard @ 2017-11-25 15:56 UTC (permalink / raw)
To: Jagan Teki
Cc: Chen-Yu Tsai, Icenowy Zheng, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Michael Trimarchi,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Jagan Teki
In-Reply-To: <1511458536-5315-1-git-send-email-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]
On Thu, Nov 23, 2017 at 11:05:36PM +0530, Jagan Teki wrote:
> Enable AXP803 PMIC and regulators for Orangepi Win.
>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
From: Maxime Ripard @ 2017-11-25 16:02 UTC (permalink / raw)
To: Yong
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Greg Kroah-Hartman, David S. Miller, Hans Verkuil, Arnd Bergmann,
Hugues Fruchet, Yannick Fertre, Philipp Zabel, Benoit Parrot,
Benjamin Gaignard, Jean-Christophe Trotin,
Ramesh Shanmugasundaram, Minghsiu Tsai, Krzysztof Kozlowski,
Robert Jarzmik, lin
In-Reply-To: <20171123091444.4bed66dffeb36ecea8dfa706-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3418 bytes --]
On Thu, Nov 23, 2017 at 09:14:44AM +0800, Yong wrote:
> > On Wed, Nov 22, 2017 at 09:33:06AM +0800, Yong wrote:
> > > > On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > > > > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > > > > and CSI1 is used for parallel interface. This is not documented in
> > > > > datasheet but by testing and guess.
> > > > >
> > > > > This patch implement a v4l2 framework driver for it.
> > > > >
> > > > > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > > > > ISP's support are not included in this patch.
> > > > >
> > > > > Signed-off-by: Yong Deng <yong.deng-+3dxTMOEIRNWk0Htik3J/w@public.gmane.org>
> > > >
> > > > Thanks again for this driver.
> > > >
> > > > It seems like at least this iteration is behaving in a weird way with
> > > > DMA transfers for at least YU12 and NV12 (and I would assume YV12).
> > > >
> > > > Starting a transfer of multiple frames in either of these formats,
> > > > using either ffmpeg (ffmpeg -f v4l2 -video_size 640x480 -framerate 30
> > > > -i /dev/video0 output.mkv) or yavta (yavta -c80 -p -F --skip 0 -f NV12
> > > > -s 640x480 $(media-c tl -e 'sun6i-csi')) will end up in a panic.
> > > >
> > > > The panic seems to be generated with random data going into parts of
> > > > the kernel memory, the pattern being in my case something like
> > > > 0x8287868a which is very odd (always around 0x88)
> > > >
> > > > It turns out that when you cover the sensor, the values change to
> > > > around 0x28, so it really seems like it's pixels that have been copied
> > > > there.
> > > >
> > > > I've looked quickly at the DMA setup, and it seems reasonable to
> > > > me. Do you have the same issue on your side? Have you been able to
> > > > test those formats using your hardware?
> > >
> > > I had tested the following formats with BT1120 input:
> > > V4L2_PIX_FMT_NV12 -> NV12
> > > V4L2_PIX_FMT_NV21 -> NV21
> > > V4L2_PIX_FMT_NV16 -> NV16
> > > V4L2_PIX_FMT_NV61 -> NV61
> > > V4L2_PIX_FMT_YUV420 -> YU12
> > > V4L2_PIX_FMT_YVU420 -> YV12
> > > V4L2_PIX_FMT_YUV422P -> 422P
> > > And they all work fine.
> >
> > Ok, that's good to know.
> >
> > > > Given that they all are planar formats and YUYV and the likes work
> > > > just fine, maybe we can leave them aside for now?
> > >
> > > V4L2_PIX_FMT_YUV422P and V4L2_PIX_FMT_YUYV is OK, and V4L2_PIX_FMT_NV12
> > > is bad? It's really weird.
> > >
> > > What's your input bus code format, type and width?
> >
> > The sensor is an ov5640, so the MBUS code for the bus is
> > MEDIA_BUS_FMT_YUYV8_2X8.
>
> Did you test on V3s?
No, this is on an H3, but that would be the first difference so far.
> I haven't tested it with MEDIA_BUS_FMT_YUYV8_2X8.
Ok, it's good to know that at least it works on your end, it's useful
for us to debug things :)
> The Allwinner CSI's DMA is definitely weird. Ondřej Jirman thought
> that CSI has an internal queue (Ondřej's commit has explained in detail).
> I think CSI just pick up the buffer address before the frame done
> interrupt triggered.
> The patch in attachment can deal with this. You can see if it is
> useful to solve your problem.
I'll test that on monday, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] iio: light: add support for UVIS25 sensor
From: Jonathan Cameron @ 2017-11-25 16:11 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171123225906.31838-2-lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 23 Nov 2017 23:59:05 +0100
Lorenzo Bianconi <lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> add support for STMicroelectronics UVIS25 uv sensor
> http://www.st.com/resource/en/datasheet/uvis25.pdf
>
> - continuos mode support
> - i2c support
> - spi support
> - trigger mode support
> - system PM support
>
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
A couple of really trivial bits inline. I'll clean those up whilst
applying...
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/light/Kconfig | 24 +++
> drivers/iio/light/Makefile | 3 +
> drivers/iio/light/st_uvis25.h | 37 ++++
> drivers/iio/light/st_uvis25_core.c | 360 +++++++++++++++++++++++++++++++++++++
> drivers/iio/light/st_uvis25_i2c.c | 69 +++++++
> drivers/iio/light/st_uvis25_spi.c | 68 +++++++
> 6 files changed, 561 insertions(+)
> create mode 100644 drivers/iio/light/st_uvis25.h
> create mode 100644 drivers/iio/light/st_uvis25_core.c
> create mode 100644 drivers/iio/light/st_uvis25_i2c.c
> create mode 100644 drivers/iio/light/st_uvis25_spi.c
>
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index 6a5835fab32e..93fd421b10d7 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -334,6 +334,30 @@ config STK3310
> Choosing M will build the driver as a module. If so, the module
> will be called stk3310.
>
> +config ST_UVIS25
> + tristate "STMicroelectronics UVIS25 sensor driver"
> + depends on (I2C || SPI)
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + select ST_UVIS25_I2C if (I2C)
> + select ST_UVIS25_SPI if (SPI_MASTER)
> + help
> + Say yes here to build support for STMicroelectronics UVIS25
> + uv sensor
> +
> + To compile this driver as a module, choose M here: the module
> + will be called st_uvis25.
> +
> +config ST_UVIS25_I2C
> + tristate
> + depends on ST_UVIS25
> + select REGMAP_I2C
> +
> +config ST_UVIS25_SPI
> + tristate
> + depends on ST_UVIS25
> + select REGMAP_SPI
> +
> config TCS3414
> tristate "TAOS TCS3414 digital color sensor"
> depends on I2C
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index f0176a800e14..f714067a7816 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -33,6 +33,9 @@ obj-$(CONFIG_RPR0521) += rpr0521.o
> obj-$(CONFIG_SENSORS_TSL2563) += tsl2563.o
> obj-$(CONFIG_SI1145) += si1145.o
> obj-$(CONFIG_STK3310) += stk3310.o
> +obj-$(CONFIG_ST_UVIS25) += st_uvis25_core.o
> +obj-$(CONFIG_ST_UVIS25_I2C) += st_uvis25_i2c.o
> +obj-$(CONFIG_ST_UVIS25_SPI) += st_uvis25_spi.o
> obj-$(CONFIG_TCS3414) += tcs3414.o
> obj-$(CONFIG_TCS3472) += tcs3472.o
> obj-$(CONFIG_TSL2583) += tsl2583.o
> diff --git a/drivers/iio/light/st_uvis25.h b/drivers/iio/light/st_uvis25.h
> new file mode 100644
> index 000000000000..5e970ab480cd
> --- /dev/null
> +++ b/drivers/iio/light/st_uvis25.h
> @@ -0,0 +1,37 @@
> +/*
> + * STMicroelectronics uvis25 sensor driver
> + *
> + * Copyright 2017 STMicroelectronics Inc.
> + *
> + * Lorenzo Bianconi <lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +#ifndef ST_UVIS25_H
> +#define ST_UVIS25_H
> +
> +#define ST_UVIS25_DEV_NAME "uvis25"
> +
> +#include <linux/iio/iio.h>
> +
> +/**
> + * struct st_uvis25_hw - ST UVIS25 sensor instance
> + * @regmap: Register map of the device.
> + * @trig: The trigger in use by the driver.
> + * @enabled: Status of the sensor (false->off, true->on).
> + * @irq: Device interrupt line (I2C or SPI).
> + */
> +struct st_uvis25_hw {
> + struct regmap *regmap;
> +
> + struct iio_trigger *trig;
> + bool enabled;
> + int irq;
> +};
> +
> +extern const struct dev_pm_ops st_uvis25_pm_ops;
> +
> +int st_uvis25_probe(struct device *dev, int irq, struct regmap *regmap);
> +
> +#endif /* ST_UVIS25_H */
> diff --git a/drivers/iio/light/st_uvis25_core.c b/drivers/iio/light/st_uvis25_core.c
> new file mode 100644
> index 000000000000..013da48df571
> --- /dev/null
> +++ b/drivers/iio/light/st_uvis25_core.c
> @@ -0,0 +1,360 @@
> +/*
> + * STMicroelectronics uvis25 sensor driver
> + *
> + * Copyright 2017 STMicroelectronics Inc.
> + *
> + * Lorenzo Bianconi <lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/iio/sysfs.h>
> +#include <linux/delay.h>
> +#include <linux/pm.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqreturn.h>
> +#include <linux/iio/trigger.h>
> +#include <linux/iio/trigger_consumer.h>
> +#include <linux/iio/triggered_buffer.h>
> +#include <linux/iio/buffer.h>
> +#include <linux/regmap.h>
> +
> +#include "st_uvis25.h"
> +
> +#define ST_UVIS25_REG_WHOAMI_ADDR 0x0f
> +#define ST_UVIS25_REG_WHOAMI_VAL 0xca
> +#define ST_UVIS25_REG_CTRL1_ADDR 0x20
> +#define ST_UVIS25_REG_ODR_MASK BIT(0)
> +#define ST_UVIS25_REG_BDU_MASK BIT(1)
> +#define ST_UVIS25_REG_CTRL2_ADDR 0x21
> +#define ST_UVIS25_REG_BOOT_MASK BIT(7)
> +#define ST_UVIS25_REG_CTRL3_ADDR 0x22
> +#define ST_UVIS25_REG_HL_MASK BIT(7)
> +#define ST_UVIS25_REG_STATUS_ADDR 0x27
> +#define ST_UVIS25_REG_UV_DA_MASK BIT(0)
> +#define ST_UVIS25_REG_OUT_ADDR 0x28
> +
> +static const struct iio_chan_spec st_uvis25_channels[] = {
> + {
> + .type = IIO_UVINDEX,
> + .address = ST_UVIS25_REG_OUT_ADDR,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> + .scan_index = 0,
> + .scan_type = {
> + .sign = 'u',
> + .realbits = 8,
> + .storagebits = 8,
> + },
> + },
> + IIO_CHAN_SOFT_TIMESTAMP(1),
> +};
> +
> +static int st_uvis25_check_whoami(struct st_uvis25_hw *hw)
> +{
> + int err, data;
> +
> + err = regmap_read(hw->regmap, ST_UVIS25_REG_WHOAMI_ADDR, &data);
> + if (err < 0) {
> + dev_err(regmap_get_device(hw->regmap),
> + "failed to read whoami register\n");
> + return err;
> + }
> +
> + if (data != ST_UVIS25_REG_WHOAMI_VAL) {
> + dev_err(regmap_get_device(hw->regmap),
> + "wrong whoami {%02x vs %02x}\n",
> + data, ST_UVIS25_REG_WHOAMI_VAL);
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +
> +static int st_uvis25_set_enable(struct st_uvis25_hw *hw, bool enable)
> +{
> + int err;
> +
> + err = regmap_update_bits(hw->regmap, ST_UVIS25_REG_CTRL1_ADDR,
> + ST_UVIS25_REG_ODR_MASK, enable);
> + if (err < 0)
> + return err;
> +
> + hw->enabled = enable;
> +
> + return 0;
> +}
> +
> +static int st_uvis25_read_oneshot(struct st_uvis25_hw *hw, u8 addr, int *val)
> +{
> + int err;
> +
> + err = st_uvis25_set_enable(hw, true);
> + if (err < 0)
> + return err;
> +
> + msleep(1500);
> +
> + /*
> + * in order to avoid possible race conditions with interrupt
> + * generation, disable the sensor first and then poll output
> + * register. That sequence guarantees the interrupt will be reset
> + * when irq line is unmasked
> + */
> + err = st_uvis25_set_enable(hw, false);
> + if (err < 0)
> + return err;
> +
> + err = regmap_read(hw->regmap, addr, val);
> +
> + return err < 0 ? err : IIO_VAL_INT;
> +}
> +
> +static int st_uvis25_read_raw(struct iio_dev *iio_dev,
> + struct iio_chan_spec const *ch,
> + int *val, int *val2, long mask)
> +{
> + int ret;
> +
> + ret = iio_device_claim_direct_mode(iio_dev);
> + if (ret)
> + return ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_PROCESSED: {
> + struct st_uvis25_hw *hw = iio_priv(iio_dev);
> +
> + /*
> + * mask irq line during oneshot read since the sensor
> + * does not export the capability to disable data-ready line
> + * in the register map and it is enabled by default.
> + * If the line is unmasked during read_raw() it will be set
> + * active and never reset since the trigger is disabled
> + */
> + if (hw->irq > 0)
> + disable_irq(hw->irq);
> + ret = st_uvis25_read_oneshot(hw, ch->address, val);
> + if (hw->irq > 0)
> + enable_irq(hw->irq);
> + break;
> + }
> + default:
> + ret = -EINVAL;
> + break;
> + }
> +
> + iio_device_release_direct_mode(iio_dev);
> +
> + return ret;
> +}
> +
> +static irqreturn_t st_uvis25_trigger_handler_thread(int irq, void *private)
> +{
> + struct st_uvis25_hw *hw = private;
> + int err, status;
> +
> + err = regmap_read(hw->regmap, ST_UVIS25_REG_STATUS_ADDR, &status);
> + if (err < 0)
> + return IRQ_HANDLED;
> +
> + if (!(status & ST_UVIS25_REG_UV_DA_MASK))
> + return IRQ_NONE;
> +
> + iio_trigger_poll_chained(hw->trig);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int st_uvis25_allocate_trigger(struct iio_dev *iio_dev)
> +{
> + struct st_uvis25_hw *hw = iio_priv(iio_dev);
> + struct device *dev = regmap_get_device(hw->regmap);
> + bool irq_active_low = false;
> + unsigned long irq_type;
> + int err;
> +
> + irq_type = irqd_get_trigger_type(irq_get_irq_data(hw->irq));
> +
> + switch (irq_type) {
> + case IRQF_TRIGGER_HIGH:
> + case IRQF_TRIGGER_RISING:
> + break;
> + case IRQF_TRIGGER_LOW:
> + case IRQF_TRIGGER_FALLING:
> + irq_active_low = true;
> + break;
> + default:
> + dev_info(dev, "mode %lx unsupported\n", irq_type);
> + return -EINVAL;
> + }
> +
> + err = regmap_update_bits(hw->regmap, ST_UVIS25_REG_CTRL3_ADDR,
> + ST_UVIS25_REG_HL_MASK, irq_active_low);
> + if (err < 0)
> + return err;
> +
> + err = devm_request_threaded_irq(dev, hw->irq, NULL,
> + st_uvis25_trigger_handler_thread,
> + irq_type | IRQF_ONESHOT,
> + iio_dev->name, hw);
> + if (err) {
> + dev_err(dev, "failed to request trigger irq %d\n",
> + hw->irq);
> + return err;
> + }
> +
> + hw->trig = devm_iio_trigger_alloc(dev, "%s-trigger",
> + iio_dev->name);
> + if (!hw->trig)
> + return -ENOMEM;
> +
> + iio_trigger_set_drvdata(hw->trig, iio_dev);
> + hw->trig->dev.parent = dev;
> +
> + return devm_iio_trigger_register(dev, hw->trig);
> +}
> +
> +static int st_uvis25_buffer_preenable(struct iio_dev *iio_dev)
> +{
> + return st_uvis25_set_enable(iio_priv(iio_dev), true);
> +}
> +
> +static int st_uvis25_buffer_postdisable(struct iio_dev *iio_dev)
> +{
> + return st_uvis25_set_enable(iio_priv(iio_dev), false);
> +}
> +
> +static const struct iio_buffer_setup_ops st_uvis25_buffer_ops = {
> + .preenable = st_uvis25_buffer_preenable,
> + .postenable = iio_triggered_buffer_postenable,
> + .predisable = iio_triggered_buffer_predisable,
> + .postdisable = st_uvis25_buffer_postdisable,
> +};
> +
> +static irqreturn_t st_uvis25_buffer_handler_thread(int irq, void *p)
> +{
> + u8 buffer[ALIGN(sizeof(u8), sizeof(s64)) + sizeof(s64)];
I thought we were going to run into dma safe buffer issues but
I see regmap-spi.c uses spi_write_then_read which uses bounce
buffers so we are fine.
> + struct iio_poll_func *pf = p;
> + struct iio_dev *iio_dev = pf->indio_dev;
> + struct st_uvis25_hw *hw = iio_priv(iio_dev);
> + int err;
> +
> + err = regmap_read(hw->regmap, ST_UVIS25_REG_OUT_ADDR, (int *)buffer);
> + if (err < 0)
> + goto out;
> +
> + iio_push_to_buffers_with_timestamp(iio_dev, buffer,
> + iio_get_time_ns(iio_dev));
> +
> +out:
> + iio_trigger_notify_done(hw->trig);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int st_uvis25_allocate_buffer(struct iio_dev *iio_dev)
> +{
> + struct st_uvis25_hw *hw = iio_priv(iio_dev);
> +
> + return devm_iio_triggered_buffer_setup(regmap_get_device(hw->regmap),
> + iio_dev, NULL,
> + st_uvis25_buffer_handler_thread,
> + &st_uvis25_buffer_ops);
> +}
> +
> +static const struct iio_info st_uvis25_info = {
> + .read_raw = st_uvis25_read_raw,
> +};
> +
> +static int st_uvis25_init_sensor(struct st_uvis25_hw *hw)
> +{
> + int err;
> +
> + err = regmap_update_bits(hw->regmap, ST_UVIS25_REG_CTRL2_ADDR,
> + ST_UVIS25_REG_BOOT_MASK, 1);
> + if (err < 0)
> + return err;
> +
> + msleep(2000);
> +
> + return regmap_update_bits(hw->regmap, ST_UVIS25_REG_CTRL1_ADDR,
> + ST_UVIS25_REG_BDU_MASK, 1);
> +}
> +
> +int st_uvis25_probe(struct device *dev, int irq, struct regmap *regmap)
> +{
> + struct st_uvis25_hw *hw;
> + struct iio_dev *iio_dev;
> + int err;
> +
> + iio_dev = devm_iio_device_alloc(dev, sizeof(*hw));
> + if (!iio_dev)
> + return -ENOMEM;
> +
> + dev_set_drvdata(dev, (void *)iio_dev);
Never any need to cast to a (void *) as it is always fine for any pointer
type to do this implicitly (it's in the C spec somewhere...)
> +
> + hw = iio_priv(iio_dev);
> + hw->irq = irq;
> + hw->regmap = regmap;
> +
> + err = st_uvis25_check_whoami(hw);
> + if (err < 0)
> + return err;
> +
> + iio_dev->modes = INDIO_DIRECT_MODE;
> + iio_dev->dev.parent = dev;
> + iio_dev->channels = st_uvis25_channels;
> + iio_dev->num_channels = ARRAY_SIZE(st_uvis25_channels);
> + iio_dev->name = ST_UVIS25_DEV_NAME;
> + iio_dev->info = &st_uvis25_info;
> +
> + err = st_uvis25_init_sensor(hw);
> + if (err < 0)
> + return err;
> +
> + if (hw->irq > 0) {
> + err = st_uvis25_allocate_buffer(iio_dev);
> + if (err < 0)
> + return err;
> +
> + err = st_uvis25_allocate_trigger(iio_dev);
> + if (err)
> + return err;
> + }
> +
> + return devm_iio_device_register(dev, iio_dev);
> +}
> +EXPORT_SYMBOL(st_uvis25_probe);
> +
> +static int __maybe_unused st_uvis25_suspend(struct device *dev)
> +{
> + struct iio_dev *iio_dev = dev_get_drvdata(dev);
> + struct st_uvis25_hw *hw = iio_priv(iio_dev);
> +
> + return regmap_update_bits(hw->regmap, ST_UVIS25_REG_CTRL1_ADDR,
> + ST_UVIS25_REG_ODR_MASK, 0);
> +}
> +
> +static int __maybe_unused st_uvis25_resume(struct device *dev)
> +{
> + struct iio_dev *iio_dev = dev_get_drvdata(dev);
> + struct st_uvis25_hw *hw = iio_priv(iio_dev);
> + int err = 0;
> +
> + if (hw->enabled)
> + err = regmap_update_bits(hw->regmap, ST_UVIS25_REG_CTRL1_ADDR,
> + ST_UVIS25_REG_ODR_MASK, 1);
if (hw->enabled)
return regmap_...
return 0;
> +
> + return err;
> +}
> +
> +const struct dev_pm_ops st_uvis25_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(st_uvis25_suspend, st_uvis25_resume)
> +};
> +EXPORT_SYMBOL(st_uvis25_pm_ops);
> +
> +MODULE_AUTHOR("Lorenzo Bianconi <lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
> +MODULE_DESCRIPTION("STMicroelectronics uvis25 sensor driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iio/light/st_uvis25_i2c.c b/drivers/iio/light/st_uvis25_i2c.c
> new file mode 100644
> index 000000000000..e49ec46e9bb8
> --- /dev/null
> +++ b/drivers/iio/light/st_uvis25_i2c.c
> @@ -0,0 +1,69 @@
> +/*
> + * STMicroelectronics uvis25 i2c driver
> + *
> + * Copyright 2017 STMicroelectronics Inc.
> + *
> + * Lorenzo Bianconi <lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/acpi.h>
> +#include <linux/i2c.h>
> +#include <linux/slab.h>
> +#include <linux/regmap.h>
> +
> +#include "st_uvis25.h"
> +
> +#define I2C_AUTO_INCREMENT BIT(7)
Hmm. I think the chances of that clashing with
something defined in the future is a little too high.
Needs a prefix to avoid possible issues...
> +
> +const struct regmap_config st_uvis25_i2c_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .write_flag_mask = I2C_AUTO_INCREMENT,
> + .read_flag_mask = I2C_AUTO_INCREMENT,
> +};
> +
> +static int st_uvis25_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct regmap *regmap;
> +
> + regmap = devm_regmap_init_i2c(client, &st_uvis25_i2c_regmap_config);
> + if (IS_ERR(regmap)) {
> + dev_err(&client->dev, "Failed to register i2c regmap %d\n",
> + (int)PTR_ERR(regmap));
> + return PTR_ERR(regmap);
> + }
> +
> + return st_uvis25_probe(&client->dev, client->irq, regmap);
> +}
> +
> +static const struct of_device_id st_uvis25_i2c_of_match[] = {
> + { .compatible = "st,uvis25", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, st_uvis25_i2c_of_match);
> +
> +static const struct i2c_device_id st_uvis25_i2c_id_table[] = {
> + { ST_UVIS25_DEV_NAME },
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, st_uvis25_i2c_id_table);
> +
> +static struct i2c_driver st_uvis25_driver = {
> + .driver = {
> + .name = "st_uvis25_i2c",
> + .pm = &st_uvis25_pm_ops,
> + .of_match_table = of_match_ptr(st_uvis25_i2c_of_match),
> + },
> + .probe = st_uvis25_i2c_probe,
> + .id_table = st_uvis25_i2c_id_table,
> +};
> +module_i2c_driver(st_uvis25_driver);
> +
> +MODULE_AUTHOR("Lorenzo Bianconi <lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
> +MODULE_DESCRIPTION("STMicroelectronics uvis25 i2c driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iio/light/st_uvis25_spi.c b/drivers/iio/light/st_uvis25_spi.c
> new file mode 100644
> index 000000000000..06e9f7cbe1e7
> --- /dev/null
> +++ b/drivers/iio/light/st_uvis25_spi.c
> @@ -0,0 +1,68 @@
> +/*
> + * STMicroelectronics uvis25 spi driver
> + *
> + * Copyright 2017 STMicroelectronics Inc.
> + *
> + * Lorenzo Bianconi <lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/spi/spi.h>
> +#include <linux/slab.h>
> +#include <linux/regmap.h>
> +
> +#include "st_uvis25.h"
> +
> +#define SENSORS_SPI_READ BIT(7)
> +#define SPI_AUTO_INCREMENT BIT(6)
> +
> +const struct regmap_config st_uvis25_spi_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .read_flag_mask = SENSORS_SPI_READ | SPI_AUTO_INCREMENT,
> + .write_flag_mask = SPI_AUTO_INCREMENT,
> +};
> +
> +static int st_uvis25_spi_probe(struct spi_device *spi)
> +{
> + struct regmap *regmap;
> +
> + regmap = devm_regmap_init_spi(spi, &st_uvis25_spi_regmap_config);
> + if (IS_ERR(regmap)) {
> + dev_err(&spi->dev, "Failed to register spi regmap %d\n",
> + (int)PTR_ERR(regmap));
> + return PTR_ERR(regmap);
> + }
> +
> + return st_uvis25_probe(&spi->dev, spi->irq, regmap);
> +}
> +
> +static const struct of_device_id st_uvis25_spi_of_match[] = {
> + { .compatible = "st,uvis25", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, st_uvis25_spi_of_match);
> +
> +static const struct spi_device_id st_uvis25_spi_id_table[] = {
> + { ST_UVIS25_DEV_NAME },
> + {},
> +};
> +MODULE_DEVICE_TABLE(spi, st_uvis25_spi_id_table);
> +
> +static struct spi_driver st_uvis25_driver = {
> + .driver = {
> + .name = "st_uvis25_spi",
> + .pm = &st_uvis25_pm_ops,
> + .of_match_table = of_match_ptr(st_uvis25_spi_of_match),
> + },
> + .probe = st_uvis25_spi_probe,
> + .id_table = st_uvis25_spi_id_table,
> +};
> +module_spi_driver(st_uvis25_driver);
> +
> +MODULE_AUTHOR("Lorenzo Bianconi <lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
> +MODULE_DESCRIPTION("STMicroelectronics uvis25 spi driver");
> +MODULE_LICENSE("GPL v2");
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: iio: light: add UVIS25 device bindings
From: Jonathan Cameron @ 2017-11-25 16:11 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171123225906.31838-3-lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, 23 Nov 2017 23:59:06 +0100
Lorenzo Bianconi <lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied
> ---
> .../devicetree/bindings/iio/light/uvis25.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/light/uvis25.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/light/uvis25.txt b/Documentation/devicetree/bindings/iio/light/uvis25.txt
> new file mode 100644
> index 000000000000..3041207e3f3c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/uvis25.txt
> @@ -0,0 +1,23 @@
> +* ST UVIS25 uv sensor
> +
> +Required properties:
> +- compatible: should be "st,uvis25"
> +- reg: i2c address of the sensor / spi cs line
> +
> +Optional properties:
> +- interrupt-parent: should be the phandle for the interrupt controller
> +- interrupts: interrupt mapping for IRQ. It should be configured with
> + flags IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_EDGE_RISING, IRQ_TYPE_LEVEL_LOW or
> + IRQ_TYPE_EDGE_FALLING.
> +
> + Refer to interrupt-controller/interrupts.txt for generic interrupt
> + client node bindings.
> +
> +Example:
> +
> +uvis25@47 {
> + compatible = "st,uvis25";
> + reg = <0x47>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <0 IRQ_TYPE_EDGE_RISING>;
> +};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: bcm283x: Use GPIO polarity defines consequently
From: Florian Fainelli @ 2017-11-25 17:41 UTC (permalink / raw)
To: Stefan Wahren, Eric Anholt, Rob Herring, Mark Rutland
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1511616845-16298-1-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
Hi Stefan,
On 11/25/2017 05:34 AM, Stefan Wahren wrote:
> Currently most of the Raspberry Pi DTS have a mixture of magic
> numbers and the proper GPIO polarity defines. So use the latter
> one consequently.
Did you intend to mean "consistently" in your commit subject and message?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: bcm283x: Use GPIO polarity defines consequently
From: Stefan Wahren @ 2017-11-25 17:54 UTC (permalink / raw)
To: Florian Fainelli
Cc: Mark Rutland, devicetree, Eric Anholt, Rob Herring,
linux-rpi-kernel, linux-arm-kernel
In-Reply-To: <54a972b3-c981-a365-0b30-3c292a88cb12@gmail.com>
> Florian Fainelli <f.fainelli@gmail.com> hat am 25. November 2017 um 18:41 geschrieben:
>
>
> Hi Stefan,
>
> On 11/25/2017 05:34 AM, Stefan Wahren wrote:
> > Currently most of the Raspberry Pi DTS have a mixture of magic
> > numbers and the proper GPIO polarity defines. So use the latter
> > one consequently.
>
> Did you intend to mean "consistently" in your commit subject and message?
Okay, this would be better.
Thanks
> --
> Florian
^ permalink raw reply
* [PATCH V2 0/9] Add loadable kernel module and power management support
From: Manikanta Maddireddy @ 2017-11-25 19:32 UTC (permalink / raw)
To: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rjw-LthD3rsA81gm4RdzfppkhA,
tglx-hfZtesqFncYOwBW4kG4KsQ
Cc: vidyas-DDmLM1+adcrQT0dZR+AlfA, kthota-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Manikanta Maddireddy
This series of patches add loadable kernel module and power management
support to Tegra PCIe host controller driver.
These patches are tested on Jetson TK1, TX1 and TX2 platforms, following
are the verification details.
- Multiple module insert & remove
- PCIe device functionality after module insert
- Free clock, resets, regulators, powergate, iomem and interrupt
resources after module remove
- PCIe device functionality after resume from RAM
Tegra PCIe host controller driver is using ioremap_page_range() which is
not exported. This is switched with devm_ioremap() in the series
'https://patchwork.ozlabs.org/project/linux-tegra/list/?series=9907'.
Both these series will complete the loadable module support for Tegra
PCIe host driver.
PM QoS fix is dropped in V2 from this series because the fix is
incorporated in latest 'commit 0759e80b84e3 ("PM / QoS: Fix device resume
latency framework")'. Update commit message of few patches in V2.
Manikanta Maddireddy (9):
genirq: Export irq_set_msi_desc()
of: Export of_pci_range_to_resource()
ARM: tegra: Export tegra_cpuidle_pcie_irqs_in_use()
PCI: Export pci_find_host_bridge()
PCI: Export pci_flags
PCI: tegra: free resources on probe failure
PCI: tegra: Add loadable kernel module support
PCI: tegra: Broadcast PME_turn_Off message before link goes to L2
PCI: tegra: Add power management support
arch/arm/mach-tegra/cpuidle.c | 1 +
drivers/of/address.c | 1 +
drivers/pci/host-bridge.c | 1 +
drivers/pci/host/Kconfig | 2 +-
drivers/pci/host/pci-tegra.c | 359 +++++++++++++++++++++++++++++++++---------
drivers/pci/setup-bus.c | 1 +
kernel/irq/chip.c | 1 +
7 files changed, 292 insertions(+), 74 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH V2 1/9] genirq: Export irq_set_msi_desc()
From: Manikanta Maddireddy @ 2017-11-25 19:32 UTC (permalink / raw)
To: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rjw-LthD3rsA81gm4RdzfppkhA,
tglx-hfZtesqFncYOwBW4kG4KsQ
Cc: vidyas-DDmLM1+adcrQT0dZR+AlfA, kthota-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Manikanta Maddireddy
In-Reply-To: <1511638333-22951-1-git-send-email-mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
PCI MSI driver allocates MSI entry for each pci dev which creates msi_desc,
host driver maps each msi domain with hwirq and then sets msi_desc for
that irq number. Need to export irq_set_msi_desc() to allow Tegra PCIe
driver to be compiled as a loadable kernel module.
Signed-off-by: Manikanta Maddireddy <mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
V2:
* commit message update
kernel/irq/chip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 043bfc35b353..0e74b1051267 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -136,6 +136,7 @@ int irq_set_msi_desc(unsigned int irq, struct msi_desc *entry)
{
return irq_set_msi_desc_off(irq, 0, entry);
}
+EXPORT_SYMBOL(irq_set_msi_desc);
/**
* irq_set_chip_data - set irq chip data for an irq
--
2.1.4
^ permalink raw reply related
* [PATCH V2 2/9] of: Export of_pci_range_to_resource()
From: Manikanta Maddireddy @ 2017-11-25 19:32 UTC (permalink / raw)
To: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rjw-LthD3rsA81gm4RdzfppkhA,
tglx-hfZtesqFncYOwBW4kG4KsQ
Cc: vidyas-DDmLM1+adcrQT0dZR+AlfA, kthota-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Manikanta Maddireddy
In-Reply-To: <1511638333-22951-1-git-send-email-mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Tegra PCIe host driver parses of_pci_range from device tree and converts
to resource. Export of_pci_range_to_resource() to allow Tegra PCIe host
driver to be compiled as loadable kernel module.
Signed-off-by: Manikanta Maddireddy <mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
V2:
* commit message update
drivers/of/address.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index fa6cabfc3cb9..8d9b93f8701a 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -361,6 +361,7 @@ int of_pci_range_to_resource(struct of_pci_range *range,
res->end = (resource_size_t)OF_BAD_ADDR;
return err;
}
+EXPORT_SYMBOL(of_pci_range_to_resource);
#endif /* CONFIG_PCI */
/*
--
2.1.4
^ permalink raw reply related
* [PATCH V2 3/9] ARM: tegra: Export tegra_cpuidle_pcie_irqs_in_use()
From: Manikanta Maddireddy @ 2017-11-25 19:32 UTC (permalink / raw)
To: thierry.reding, jonathanh, robh+dt, frowand.list, bhelgaas, rjw,
tglx
Cc: vidyas, kthota, linux-tegra, devicetree, linux-pci, linux-pm,
Manikanta Maddireddy
In-Reply-To: <1511638333-22951-1-git-send-email-mmaddireddy@nvidia.com>
Tegra20 has a HW bug where PCIe interrupts are lost when LP2 (Tegra idle
state) is enabled. tegra_cpuidle_pcie_irqs_in_use() disables LP2 when
PCIe irq is mapped. EXPORT tegra_cpuidle_pcie_irqs_in_use() to allow Tegra
PCIe driver to be compiled as loadable kernel module.
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
---
V2:
* commit message update
arch/arm/mach-tegra/cpuidle.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-tegra/cpuidle.c b/arch/arm/mach-tegra/cpuidle.c
index 316563141add..7d7e6d3ce32d 100644
--- a/arch/arm/mach-tegra/cpuidle.c
+++ b/arch/arm/mach-tegra/cpuidle.c
@@ -57,3 +57,4 @@ void tegra_cpuidle_pcie_irqs_in_use(void)
break;
}
}
+EXPORT_SYMBOL(tegra_cpuidle_pcie_irqs_in_use);
--
2.1.4
^ permalink raw reply related
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