version 8:
- rebase on v4.10-rc4
- fix comments done by Thierry on PWM
- reword "reg" parameter description
- change kernel kernel in IIO ABI documentation
version 7:
- rebase on v4.10-rc2
- remove iio_device code from driver and keep only the trigger part
version 6:
- rename stm32-gptimer in stm32-timers.
- change "st,stm32-gptimer" compatible to "st,stm32-timers".
- modify "st,breakinput" parameter in pwm part.
- split DT patch in 2
version 5:
- fix comments done on version 4
- rebased on kernel 4.9-rc8
- change nodes names and re-order then by addresses
version 4:
- fix comments done on version 3
- don't use interrupts anymore in IIO timer
- detect hardware capabilities at probe time to simplify binding
version 3:
- no change on mfd and pwm divers patches
- add cross reference between bindings
- change compatible to "st,stm32-timer-trigger"
- fix attributes access rights
- use string instead of int for master_mode and slave_mode
- document device attributes in sysfs-bus-iio-timer-stm32
- update DT with the new compatible
version 2:
- keep only one compatible per driver
- use DT parameters to describe hardware block configuration:
- pwm channels, complementary output, counter size, break input
- triggers accepted and create by IIO timers
- change DT to limite use of reference to the node
- interrupt is now in IIO timer driver
- rename stm32-mfd-timer to stm32-timers (for general purpose timer)
The following patches enable PWM and IIO Timer features for STM32 platforms.
Those two features are mixed into the registers of the same hardware block
(named general purpose timer) which lead to introduce a multifunctions driver
on the top of them to be able to share the registers.
In STM32f4 14 instances of timer hardware block exist, even if they all have
the same register mapping they could have a different number of pwm channels
and/or different triggers capabilities. We use various parameters in DT to
describe the differences between hardware blocks
The MFD (stm32-timers.c) takes care of clock and register mapping
by using regmap. stm32_timers structure is provided to its sub-node to
share those information.
PWM driver is implemented into pwm-stm32.c. Depending of the instance we may
have up to 4 channels, sometime with complementary outputs or 32 bits counter
instead of 16 bits. Some hardware blocks may also have a break input function
which allows to stop pwm depending of a level, defined in devicetree, on an
external pin.
IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a list
of hardware triggers usable by hardware blocks like ADC, DAC or other timers.
The matrix of possible connections between blocks is quite complex so we use
trigger names and is_stm32_iio_timer_trigger() function to be sure that
triggers are valid and configure the IPs.
At run time IIO timer hardware blocks can configure (through "master_mode"
IIO device attribute) which internal signal (counter enable, reset,
comparison block, etc...) is used to generate the trigger.
Benjamin Gaignard (8):
MFD: add bindings for STM32 Timers driver
MFD: add STM32 Timers driver
PWM: add pwm-stm32 DT bindings
PWM: add PWM driver for STM32 plaftorm
IIO: add bindings for STM32 timer trigger driver
IIO: add STM32 timer trigger driver
ARM: dts: stm32: add Timers driver for stm32f429 MCU
ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco
.../ABI/testing/sysfs-bus-iio-timer-stm32 | 29 ++
.../bindings/iio/timer/stm32-timer-trigger.txt | 23 ++
.../devicetree/bindings/mfd/stm32-timers.txt | 46 +++
.../devicetree/bindings/pwm/pwm-stm32.txt | 35 ++
arch/arm/boot/dts/stm32f429.dtsi | 275 ++++++++++++++
arch/arm/boot/dts/stm32f469-disco.dts | 28 ++
drivers/iio/trigger/Kconfig | 9 +
drivers/iio/trigger/Makefile | 1 +
drivers/iio/trigger/stm32-timer-trigger.c | 342 ++++++++++++++++++
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 2 +
drivers/mfd/stm32-timers.c | 80 +++++
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-stm32.c | 398 +++++++++++++++++++++
include/linux/iio/timer/stm32-timer-trigger.h | 62 ++++
include/linux/mfd/stm32-timers.h | 71 ++++
17 files changed, 1422 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
create mode 100644 drivers/iio/trigger/stm32-timer-trigger.c
create mode 100644 drivers/mfd/stm32-timers.c
create mode 100644 drivers/pwm/pwm-stm32.c
create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
create mode 100644 include/linux/mfd/stm32-timers.h
--
1.9.1
Hi Alex, Mark,
Please consider following linaro-android pull request for
"linux-linaro-lsk-v4.1-android" LSK branch.
Boot tested on Qemu + Android M.
KernelCI build job:
https://kernelci.org/build/linaro-android/kernel/v4.1-5317-g65117109f634/
Backlog:
Again, for the record, here is a list of aosp/android-4.1 patches
dropped from lsk-4.1-android topic branch. "arm64: User Access
Override" feature and dependent patches from aosp/android-4.1 are
dropped due to non-trivial merge errors including a "#define" conflict
in one of arm64:UAO patches which might have made that feature
unusable.
BACKPORT: arm64: kernel: Add support for User Access Override
UPSTREAM: arm64: cpufeature: Test 'matches' pointer to find the end of the list
BACKPORT: arm64: kernel: Don't toggle PAN on systems with UAO
UPSTREAM: arm64: Remove the get_thread_info() function
UPSTREAM: arm64: fix dump_instr when PAN and UAO are in use
UPSTREAM: arm64: add macro to extract ESR_ELx.EC
UPSTREAM: arm64: kill ESR_LNX_EXEC
BACKPORT: arm64: kernel: Save and restore UAO and addr_limit on exception entry
BACKPORT: arm64: Handle el1 synchronous instruction aborts cleanly
BACKPORT: arm64: Factor out PAN enabling/disabling into separate
uaccess_* macros
BACKPORT: arm64: Introduce uaccess_{disable,enable} functionality
based on TTBR0_EL1
BACKPORT: arm64: Disable TTBR0_EL1 during normal kernel execution
UPSTREAM: arm64: Handle faults caused by inadvertent user access with
PAN enabled
UPSTREAM: arm64: xen: Enable user access before a privcmd hvc call
UPSTREAM: arm64: Enable CONFIG_ARM64_SW_TTBR0_PAN
UPSTREAM: arm64: Disable PAN on uaccess_enable()
ANDROID: configs: CONFIG_ARM64_SW_TTBR0_PAN=y
Regards,
Amit Pundir
The following changes since commit 8b496701188f07a1c4821d833337e4a0998191b9:
Merge branch 'lsk-v4.1-android' of
git://android.git.linaro.org/kernel/linaro-android into
linux-linaro-lsk-v4.1-android (2017-01-03 17:57:57 +0800)
are available in the git repository at:
git://android.git.linaro.org/kernel/linaro-android lsk-v4.1-android
for you to fetch changes up to 65117109f6344fa46542f85844bc292842116192:
ANDROID: sdcardfs: Propagate dentry down to inode_change_ok()
(2017-01-16 15:54:02 +0530)
----------------------------------------------------------------
Amit Pundir (1):
ANDROID: sdcardfs: Propagate dentry down to inode_change_ok()
Eric Biggers (1):
net: socket: don't set sk_uid to garbage value in ->setattr()
Eric Dumazet (1):
UPSTREAM: net: avoid signed overflows for SO_{SND|RCV}BUFFORCE
Guillaume Nault (1):
UPSTREAM: l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind()
Mark Rutland (1):
UPSTREAM: arm64: alternative: add auto-nop infrastructure
Sami Tolvanen (2):
Revert "FROMLIST: arm64: Enable CONFIG_ARM64_SW_TTBR0_PAN"
Revert "FROMLIST: arm64: xen: Enable user access before a
privcmd hvc call"
Will Deacon (1):
BACKPORT: arm64: barriers: introduce nops and __nops macros for
NOP sequences
arch/arm64/Kconfig | 8 --------
arch/arm64/include/asm/alternative.h | 71
++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------
arch/arm64/include/asm/assembler.h | 9 +++++++++
arch/arm64/include/asm/barrier.h | 3 +++
arch/arm64/xen/hypercall.S | 19 -------------------
fs/sdcardfs/inode.c | 4 ++--
net/core/sock.c | 4 ++--
net/l2tp/l2tp_ip.c | 5 +++--
net/l2tp/l2tp_ip6.c | 5 +++--
net/socket.c | 2 +-
10 files changed, 77 insertions(+), 53 deletions(-)
Hi all,
before sending this RFC to a larger audience I would like to get our opinion
about it. Please feel very free to comment it, thanks !
The goal of this RFC is to understand if a common ioctl for specific memory
regions allocations is needed/welcome.
Obviously it will not replace allocation done in linux kernel frameworks like
v4l2 or dmr/kms, but offer an alternative when you don't want/need to use them
for buffer allocation.
"Unix Device Memory Allocator" project [1] wants to create a userland library
which may allow to select, depending of the devices constraint, the best
back-end for allocation. With this RFC I would to propose to have common ioctl
for a maximum of allocator to avoid to duplicated back-end for this library.
Since the beginning it is a problem to allocate contiguous memory (CMA) without
using v4l2 or drm/kms so the first allocator available in this RFC use CMA
memory.
An other question is: do we have others memory regions that could be interested
by this new framework ? I have in mind that some title memory regions could use
it or replace ION heaps (system, carveout etc...).
Maybe it only solve CMA allocation issue, in this case no need to create a
common ioctl, a custom should be enough.
Maybe the first thing to do is to change the name and the location of this
module, suggestions are welcome.
[1] https://github.com/cubanismo/allocator
Benjamin Gaignard (2):
Create Simple Allocator module
add CMA simple allocator module
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/simpleallocator/Kconfig | 17 +++
drivers/simpleallocator/Makefile | 2 +
drivers/simpleallocator/simple-allocator-cma.c | 163 +++++++++++++++++++++++
drivers/simpleallocator/simple-allocator-priv.h | 27 ++++
drivers/simpleallocator/simple-allocator.c | 167 ++++++++++++++++++++++++
include/uapi/linux/simple-allocator.h | 35 +++++
8 files changed, 414 insertions(+)
create mode 100644 drivers/simpleallocator/Kconfig
create mode 100644 drivers/simpleallocator/Makefile
create mode 100644 drivers/simpleallocator/simple-allocator-cma.c
create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
create mode 100644 drivers/simpleallocator/simple-allocator.c
create mode 100644 include/uapi/linux/simple-allocator.h
--
1.9.1