* [PATCH 0/3] arm64: kexec,kdump: fix boot failures on acpi-only system
From: AKASHI Takahiro @ 2018-06-18 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81a9a385-3b9f-113d-96f0-379be74c19f0@arm.com>
James,
Thank you for follow-up explanation.
I have nothing to add :)
-Takahiro AKASHI
On Fri, Jun 15, 2018 at 05:29:32PM +0100, James Morse wrote:
> Hi Akashi,
>
> Thanks for putting this together,
>
> On 15/06/18 08:56, AKASHI Takahiro wrote:
> > This patch series is a set of bug fixes to address kexec/kdump
> > failures which are sometimes observed on ACPI-only system and reported
> > in LAK-ML before.
> >
> > In short, the phenomena are:
> > 1. kexec'ed kernel can fail to boot because some ACPI table is corrupted
> > by a new kernel (or other data) being loaded into System RAM. Currently
> > kexec may possibly allocate space ignoring such "reserved" regions.
> > We will see no messages after "Bye!"
> >
> > 2. crash dump (kdump) kernel can fail to boot and get into panic due to
> > an alignment fault when accessing ACPI tables. This can happen because
> > those tables are not always properly aligned while they are mapped
> > non-cacheable (ioremap'ed) as they are not recognized as part of System
> > RAM under the current implementation.
> >
> > After discussing several possibilities to address those issues,
> > the agreed approach, in my understanding, is
> > * to add resource entries for every "reserved", i.e. memblock_reserve(),
> > regions to /proc/iomem.
> > (NOMAP regions, also marked as "reserved," remains at top-level for
> > backward compatibility.)
>
> This means user-space can tell the difference between reserved-system-ram and
> reserved-address-space.
>
>
> > * For case (1), user space (kexec-tools) should rule out such regions
> > in searching for free space for loaded data.
>
> ... but doesn't today, because it fails to account for second-level entries.
> We've always had second-level entries, so this is a user-space bug. We need both
> fixed to fix the issue.
>
> Our attempts to fix this just in the kernel reached a dead end, because Kdump
> needs to include reserved-system-ram, whereas kexec has to avoid it. User-space
> needs to be able to tell reserved-system-ram and reserved-address-space apart.
> Hence we need to expose that information, and pick it up in user-space.
>
> Patched-kernel and unpatch-user-space will work the same way it does today, as
> the additional reserved regions are ignored by user-space.
>
> Unpatched-kernel and patched-user-space will also work the same way it does
> today as the additional reserved regions are missing.
>
> I think this is the only way forwards on this issue...
>
>
> > * For case (2), the kernel should access ACPI tables by mapping
> > them with appropriate memory attributes described in UEFI memory map.
> > (This means that it doesn't require any changes in /proc/iomem, and
> > hence user space.)
>
> (this one is handled entirely in the kernel)
>
>
> Thanks,
>
> James
^ permalink raw reply
* [PATCH 2/3] arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump
From: AKASHI Takahiro @ 2018-06-18 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <026a4d23-ac91-ed35-d711-c55882242037@arm.com>
James,
On Fri, Jun 15, 2018 at 05:30:08PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 15/06/18 08:56, AKASHI Takahiro wrote:
> > This is a fix against the issue that crash dump kernel may hang up
> > during booting, which can happen on any ACPI-based system with "ACPI
> > Reclaim Memory."
> >
> > (kernel messages after panic kicked off kdump)
> > (snip...)
> > Bye!
> > (snip...)
> > ACPI: Core revision 20170728
> > pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
> > Internal error: Oops: 96000021 [#1] SMP
> > Modules linked in:
> > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
> > task: ffff000008d05180 task.stack: ffff000008cc0000
> > PC is at acpi_ns_lookup+0x25c/0x3c0
> > LR is at acpi_ds_load1_begin_op+0xa4/0x294
> > (snip...)
> > Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
> > Call trace:
> > (snip...)
> > [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
> > [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
> > [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
> > [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
> > [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
> > [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
> > [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
> > [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
> > [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
> > [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
> > [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
> > [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
> > [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
> > Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
> > ---[ end trace c46ed37f9651c58e ]---
> > Kernel panic - not syncing: Fatal exception
> > Rebooting in 10 seconds..
> >
> > (diagnosis)
> > * This fault is a data abort, alignment fault (ESR=0x96000021)
> > during reading out ACPI table.
> > * Initial ACPI tables are normally stored in system ram and marked as
> > "ACPI Reclaim memory" by the firmware.
> > * After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim
> > memory as MEMBLOCK_NOMAP"), those regions are differently handled
> > as they are "memblock-reserved", without NOMAP bit.
> > * So they are now excluded from device tree's "usable-memory-range"
> > which kexec-tools determines based on a current view of /proc/iomem.
> > * When crash dump kernel boots up, it tries to accesses ACPI tables by
> > mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap()
> > since they are no longer part of mapped system ram.
> > * Given that ACPI accessor/helper functions are compiled in without
> > unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED),
> > any unaligned access to ACPI tables can cause a fatal panic.
> >
> > With this patch, acpi_os_ioremap() always honors memory attribute
> > information provided by the firmware (EFI) and retaining cacheability
> > allows the kernel safe access to ACPI tables.
>
>
> > Please note that arm_enable_runtime_services() is now renamed to
> > efi_enter_virtual_mode() due to the similarity to x86's.
>
> Just a rename?:
and maps EFI memory map whether or not runtime service is enabled.
> > drivers/firmware/efi/arm-runtime.c | 27 ++++++++++++---------------
>
>
>
> > diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> > index 32f465a80e4e..d53c95f4e1a9 100644
> > --- a/arch/arm64/include/asm/acpi.h
> > +++ b/arch/arm64/include/asm/acpi.h
> > @@ -29,18 +31,22 @@
> >
> > /* Basic configuration for ACPI */
> > #ifdef CONFIG_ACPI
> > +pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
> > +
> > /* ACPI table mapping after acpi_permanent_mmap is set */
> > static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
> > acpi_size size)
> > {
> > + /* For normal memory we already have a cacheable mapping. */
> > + if (memblock_is_map_memory(phys))
> > + return (void __iomem *)__phys_to_virt(phys);
>
> > /*
> > - * EFI's reserve_regions() call adds memory with the WB attribute
> > - * to memblock via early_init_dt_add_memory_arch().
> > + * We should still honor the memory's attribute here because
> > + * crash dump kernel possibly excludes some ACPI (reclaim)
> > + * regions from memblock list.
> > */
>
> (Even without kdump we would still need this. Regions ACPI wants mapped may not
> be covered by the linear map. In this case we need to use the attributes
> firmware described in the UEFI memory map. Kdump exacerbates this by
> artificially reducing the range of the linear map.)
>
>
> > - if (!memblock_is_memory(phys))
> > - return ioremap(phys, size);
> > -
> > - return ioremap_cache(phys, size);
> > + return __ioremap(phys, size, __acpi_get_mem_attribute(phys));
> > }
>
>
>
> > diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
> > index 5889cbea60b8..566ef0a9edb5 100644
> > --- a/drivers/firmware/efi/arm-runtime.c
> > +++ b/drivers/firmware/efi/arm-runtime.c
> > @@ -106,46 +106,43 @@ static bool __init efi_virtmap_init(void)
> > * non-early mapping of the UEFI system table and virtual mappings for all
> > * EFI_MEMORY_RUNTIME regions.
> > */
> > -static int __init arm_enable_runtime_services(void)
> > +void __init efi_enter_virtual_mode(void)
> > {
> > u64 mapsize;
> >
> > if (!efi_enabled(EFI_BOOT)) {
> > pr_info("EFI services will not be available.\n");
> > - return 0;
> > + return;
> > + }
> > +
> > + mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
> > +
> > + if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
> > + pr_err("Failed to remap EFI memory map\n");
> > + return;
> > }
> >
> > if (efi_runtime_disabled()) {
> > pr_info("EFI runtime services will be disabled.\n");
> > - return 0;
> > + return;
> > }
> >
> > if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> > pr_info("EFI runtime services access via paravirt.\n");
> > - return 0;
> > + return;
> > }
> >
> > pr_info("Remapping and enabling EFI services.\n");
> >
> > - mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
> > -
> > - if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
> > - pr_err("Failed to remap EFI memory map\n");
> > - return -ENOMEM;
> > - }
> > -
> > if (!efi_virtmap_init()) {
> > pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n");
> > - return -ENOMEM;
> > + return;
> > }
> >
> > /* Set up runtime services function pointers */
> > efi_native_runtime_setup();
> > set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
> > -
> > - return 0;
> > }
>
> Please have the drivers/firmware/efi/arm-runtime.c changes in a separate patch
> (maybe combine it with patch 3). The 'efi/arm: ' prefix is more likely to catch
> the maintainers attention.
>
> I think this is what Ard meant by:
> | Could you please move the changes to this file and init/main.c into a
> | separate patch?
>
> https://patchwork.kernel.org/patch/10361761/
>
>
> > -early_initcall(arm_enable_runtime_services);
>
> With just this patch, surely nothing ever calls arm_enable_runtime_services(),
> and now acpi_os_ioremap() will return device memory for anything that isn't part
> of the linear region. (This breaks RAS).
Actually I noticed the issue.
> This will make it difficult to bisect through for any RAS or
> efi-runtime-services issue. Its easily fixed: please put the efi+init changes in
> a patch before the acpi_os_ioremap() changes.
I was reluctant to put different part of code changes into one.
But if nobody cares, I will do so in three patches.
* change arm_enable_runtime_services() with renaming
* move this function earlier in start_kernel()
* modify acpi_os_ioremap()
Thanks,
-Takahiro AKASHI
> Otherwise, looks good to me!
>
>
> Thanks,
>
> James
^ permalink raw reply
* Charge counter on droid 4
From: Tony Lindgren @ 2018-06-18 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615083156.GA32102@amd>
* Pavel Machek <pavel@ucw.cz> [180615 08:34]:
> On Fri 2018-06-15 10:00:14, Pavel Machek wrote:
> > Hi!
> >
> > Droid 4 has non-removable battery, yet the charge counter is reset to
> > near zero on each boot of linux.
Not sure if we actively do anything to reset it. I'm guessing
it's the Motorola bootloader that resets everything on boot.
> > Unfortunately, that makes charge counter pretty much useless on d4, as
> > the "battery full" and "battery empty" limits will be different during
> > each boot.
>From what I've seen also the stock kernel starts only with
voltage based estimate initially after a reboot?
> Hmm, and could we refrain from providing "power" values?
>
> I was thinking great, we have hardware that does proper power
> measuerement for us. No.... it is driver providing synthetic
> values. As userland has enough information to do that itself, I
> believe we should not do this in kernel.
Hmm I don't follow you, why would we want to remove these as
they implement a standard sysfs interface?
I use the sysfs interface all the time to monitor the power
consumption and the output seems to match what I was seeing
with my power supply.
Note that we also have the IIO raw data also available if that
might help.
Regards,
Tony
^ permalink raw reply
* [PATCH] dt-bindings: Fix unbalanced quotation marks
From: Krzysztof Kozlowski @ 2018-06-18 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617143127.11421-1-j.neuschaefer@gmx.net>
On Sun, Jun 17, 2018 at 4:31 PM, Jonathan Neusch?fer
<j.neuschaefer@gmx.net> wrote:
> Multiple binding documents have various forms of unbalanced quotation
> marks. Fix them.
>
> Signed-off-by: Jonathan Neusch?fer <j.neuschaefer@gmx.net>
> ---
>
> Should I split this patch so that different parts can go through different trees?
> ---
> .../devicetree/bindings/arm/samsung/samsung-boards.txt | 2 +-
> .../devicetree/bindings/gpio/nintendo,hollywood-gpio.txt | 2 +-
> Documentation/devicetree/bindings/input/touchscreen/hideep.txt | 2 +-
> .../bindings/interrupt-controller/nvidia,tegra20-ictlr.txt | 2 +-
> .../devicetree/bindings/interrupt-controller/st,stm32-exti.txt | 2 +-
> Documentation/devicetree/bindings/mips/brcm/soc.txt | 2 +-
> Documentation/devicetree/bindings/net/fsl-fman.txt | 2 +-
> Documentation/devicetree/bindings/power/power_domain.txt | 2 +-
> Documentation/devicetree/bindings/regulator/tps65090.txt | 2 +-
> Documentation/devicetree/bindings/reset/st,sti-softreset.txt | 2 +-
> Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt | 2 +-
> Documentation/devicetree/bindings/sound/qcom,apq8096.txt | 2 +-
> 12 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> index bdadc3da9556..6970f30a3770 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
> @@ -66,7 +66,7 @@ Required root node properties:
> - "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale
> Octa board.
> - "insignal,origen" - for Exynos4210-based Insignal Origen board.
> - - "insignal,origen4412 - for Exynos4412-based Insignal Origen board.
> + - "insignal,origen4412" - for Exynos4412-based Insignal Origen board.
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 0/4] allwinner: a64: add SRAM controller / system control
From: Maxime Ripard @ 2018-06-18 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64Ar+rOgiXbjtRrQojHUZteLa9N7OwM3XY7ZcpS87Qpmw@mail.gmail.com>
On Mon, Jun 18, 2018 at 10:11:20AM +0800, Chen-Yu Tsai wrote:
> On Fri, Jun 15, 2018 at 5:14 PM, Maxime Ripard
> <maxime.ripard@bootlin.com> wrote:
> > On Thu, Jun 14, 2018 at 11:35:44PM +0800, Chen-Yu Tsai wrote:
> >> Hi,
> >>
> >> This series is the remaining A64 syscon changes from the R40 DWMAC
> >> series. The series aligns how the A64 system control exports a regmap
> >> for the sun8i DWMAC driver to access with what we've done for the R40.
> >>
> >> Originally the A64 used the generic syscon for this bit of hardware.
> >> But this block also contains mapping bits for the onboard SRAM, used
> >> by various peripherals, and other vendor specific bits we may use in
> >> the future. It is by no means generic. And we already have a device
> >> tree binding and driver for the SRAM part.
> >>
> >> The first patch make the SRAM control device export a regmap, exposing
> >> a single EMAC control register, for the DWMAC driver to consume.
> >>
> >> The second and third patches rename the A64 compatible string to read
> >> "system control", which is what the block is named in the user manual.
> >>
> >> The last patch fixes up the device node, and also adds the lone mappable
> >> SRAM block, which is needed by the Display Engine.
> >
> > For the serie:
> > Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
>
> Cool. I'll apply them once you've rebased and pushed out any patches you
> queued up during the merge window.
All should be pushed now, feel free to apply them :)
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180618/4398cd96/attachment-0001.sig>
^ permalink raw reply
* Charge counter on droid 4
From: Pavel Machek @ 2018-06-18 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618065827.GN112168@atomide.com>
Hi!
> > > Droid 4 has non-removable battery, yet the charge counter is reset to
> > > near zero on each boot of linux.
>
> Not sure if we actively do anything to reset it. I'm guessing
> it's the Motorola bootloader that resets everything on boot.
Too bad if that's the case :-(.
> > > Unfortunately, that makes charge counter pretty much useless on d4, as
> > > the "battery full" and "battery empty" limits will be different during
> > > each boot.
>
> From what I've seen also the stock kernel starts only with
> voltage based estimate initially after a reboot?
>
> > Hmm, and could we refrain from providing "power" values?
> >
> > I was thinking great, we have hardware that does proper power
> > measuerement for us. No.... it is driver providing synthetic
> > values. As userland has enough information to do that itself, I
> > believe we should not do this in kernel.
>
> Hmm I don't follow you, why would we want to remove these as
> they implement a standard sysfs interface?
>
> I use the sysfs interface all the time to monitor the power
> consumption and the output seems to match what I was seeing
> with my power supply.
So... there are mA, mAh values. Those come from hardware, and I
believe we should keep them.
But there are also mW, mWh values, which are synthetic. Userland can
compute them from mV, mA values... and it is confusing that kernel
provides them. (My tendency was to start computing these synthetic
values in userland, to compare them with "real hardware" values from
kernel. But then I looked at kernel implementation, and realized they
are synthetic, tooo...)
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180618/14095185/attachment.sig>
^ permalink raw reply
* [PATCH] efi/arm: preserve early mapping of UEFI memory map longer for BGRT
From: Ard Biesheuvel @ 2018-06-18 7:41 UTC (permalink / raw)
To: linux-arm-kernel
The BGRT code validates the contents of the table against the UEFI
memory map, and so it expects it to be mapped when the code runs.
On ARM, this is currently not the case, since we tear down the early
mapping after efi_init() completes, and only create the permanent
mapping in arm_enable_runtime_services(), which executes as an early
initcall, but still leaves a window where the UEFI memory map is not
mapped.
So move the call to efi_memmap_unmap() from efi_init() to
arm_enable_runtime_services().
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/arm-init.c | 1 -
drivers/firmware/efi/arm-runtime.c | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index 80d1a885def5..a7c522eac640 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -259,7 +259,6 @@ void __init efi_init(void)
reserve_regions();
efi_esrt_init();
- efi_memmap_unmap();
memblock_reserve(params.mmap & PAGE_MASK,
PAGE_ALIGN(params.mmap_size +
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 5889cbea60b8..59a8c0ec94d5 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -115,6 +115,8 @@ static int __init arm_enable_runtime_services(void)
return 0;
}
+ efi_memmap_unmap();
+
if (efi_runtime_disabled()) {
pr_info("EFI runtime services will be disabled.\n");
return 0;
--
2.17.1
^ permalink raw reply related
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Daniel Vetter @ 2018-06-18 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6995fa4b-47a9-887b-5e4f-4284ca6a2c79@gmail.com>
On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:
> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> >>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> >>>> <leonard.crestez@nxp.com> wrote:
> >
> >>>>> The FBDEV driver uses the same name and both can't be registered at the
> >>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
> >>>>
> >>>> Stefan sent the same patch a few days ago:
> >>>
> >>> In that thread there is a proposal for removing the old fbdev/mxsfb
> >>> driver entirely.
> >>>
> >>> That would break old DTBs, isn't this generally considered bad? Also,
> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> >>>
> >>> What my series does is make both drivers work with the same kernel
> >>> image and turns the choice into a board-level dtb decision. Supporting
> >>> everything at once seems desirable to me and it allows for a very
> >>> smooth upgrade path.
> >>
> >> Having two drivers in the kernel with different set of bugs is always bad.
> >>
> >>> The old driver could be removed later, after all users are converted.
> >>
> >> Both drivers were in for long enough already. And let's be realistic,
> >> how many MX23/MX28 users of old DTs with new kernels are there who
> >> cannot update the DT as well ?
> >
> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
> > bindings are also used by 3rd-party boards for imx6/7:
> > * imx6sx-nitrogen6sx
> > * imx6ul-geam
> > * imx6ul-isiot
> > * imx6ul-opos6uldev
> > * imx6ul-pico-hobbit
> > * imx6ul-tx6ul
> > * imx7d-nitrogen7
>
> Er, yes, a handful of boards which could be updated :)
>
> > Converting everything might be quite a bit of work, and explicitly
> > supporting old bindings is also work.
>
> Does adding support for old bindings justify the effort invested ? I
> doubt so, it only adds more code to maintain.
>
> > It is very confusing that there is a whole set of displays for imx6/7
> > which are supported by upstream but only with a non-default config.
> > While it is extremely common in the embedded field to have custom
> > configs the default one in the kernel should try to "just work".
> >
> > Couldn't this patch series be considered a bugfix? It was also
> > surprisingly small.
>
> I think it's just a workaround which allows you to postpone the real
> fix, and I don't like that.
Yeah agreed, imo the proper fix here would be to either update the dts for
the affected boards and/or make mxsfb accept the old dt bindings for
backwards compat. Artificially extending the life of the fbdev drivers
seems silly.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 0/5] RFC: Mezzanine handling for 96boards
From: Linus Walleij @ 2018-06-18 7:45 UTC (permalink / raw)
To: linux-arm-kernel
This is a proposal for how to handle the non-discoverable
96boards plug-in expansion boards called "mezzanines" in the
Linux kernel. It is a working RFC series meant for discussion
at the moment.
The RFC was done on the brand new Ultra96 board from Xilinx
with a Secure96 mezzanine expansion board. The main part
is in patch 4, the rest is enabling and examples.
The code can be obtained from here:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/log/?h=ultra96
You can for example probably augment the DTS file for any
upstream-supported 96board and get the Secure96 going with
it with minor efforts.
TODO:
- Proper device tree bindings for the connector, for now
look at the example.
- Discuss whether to actually do this or just take it all and
flush it down the drain because the community doesn't like
it. I'm not one of those especially infatuated with my own code,
I always stay by the old programming project management mantra
to calculate to make one version and throw it away as stepping
stone to a good final design.
- Placement: putting this in drivers/bus is just an example.
drivers/platform/96boards-mezzanines is fine too, maybe better?
- I am especially curious about input from Andy and Mika from
the Intel/ACPI camp on what they have seen for non-discoverable
plug-in boards. Does this problem even exist in the Intel
world, or not...
Background:
- These boards connect on a custom connector on this family
of boards. The relationship is many-to-many with the connector
as nexus. The electronic standard for the connector is specified:
https://github.com/96boards/documentation/blob/master/Specifications/96Boards-CE-Specification.pdf
Example mezzanines:
https://www.96boards.org/documentation/mezzanine/
- These boards have siblings on other platforms, the problem
scope is similar with BeagleBone "capes":
https://beagleboard.org/capes
Raspberry Pi expansion boards:
https://www.abelectronics.co.uk/products/18/raspberry-pi-expansion-boards
Intel Edison, Galileo, Joule also have expansion boards.
Idea: add a driver for the connector itself and tie it in to
the device tree with a compatible string. Since the boards
are non-discoverable two mechanisms are provided to discover
them:
- Add a very simple device tree node with just a compatible
string for the board in the node. This will be simple to
add from e.g. a boot loader or as an overlay from userspace.
board {
compatible = "96boards,secure96";
};
- Echo 1 > boardname into a sysfs file to populate the
board and echo 0 > boardname to depopulate it. This
makes it easy to even switch out expansion boards at
runtime, if allowed by the electronics.
> cd /sys/devices/platform/connector
> echo 1 > secure96
lscon connector: called mezzanine_store on secure96
lscon connector: populate secure96
at24 1-0050: 2048 byte 24c128 EEPROM, writable, 128 bytes/write
atmel-ecc 1-0060: configuration zone is unlocked
tpm_tis_spi spi0.0: 2.0 TPM (device-id 0x1B, rev-id 16)
(...)
What this patch set does not do:
- It does not use device tree or ACPI DSDT or any other
hardware decription language to model the contents of the
board per se. Instead the boards buses are populated
directly with platform devices.
Predictable complaints about this design:
Q: This is not device tree overlays. Why is it not device
tree overlays?
A1: Right tool for the job, overlays are complex and the
plan to get it in place seems to be spanning years, this
is a few devices on simple busses and it works today.
Using this approach I can already work on shaping up
drivers for the mezzanine board devices as proved by:
https://marc.info/?l=linux-crypto-vger&m=152820660120590&w=2
https://marc.info/?l=linux-crypto-vger&m=152820662820595&w=2
(...)
I can work on drivers for the chips on the
Secure96 mezzanine board. It's just an example of
what the mezzanine community can do.
Now they are hacking around in userspace instead of
doing/reusing kernel drivers for their stuff:
https://github.com/jbech-linaro/secure96
This way we can bring developers for these components
into the kernel community instead of telling them to
wait for some big infrastructure that comes later
before they can contribute their stuff.
A2: Overlays does not solve the problem if the system runs
ACPI, and what about if the same connector[s] appear
on a server board, servers use ACPI. Also notice
that Intel have development boards with non-discoverable
expansion boards as well. They just will not use
device tree.
A3: Overlays is Big Upfront Design.
https://en.wikipedia.org/wiki/Big_Design_Up_Front
This way of designing things is associated with the
(pejorative term) "waterfall model" which is out of
fashion as a way of doing development. I think I am not
the only one slightly annoyed by the fact that device
tree overlays is now starting to look like a very
big very upfront design. It's just not possible to get
something up and running in small iterative steps with
device tree overlays. Instead huge efforts are
required and it involves major possible showstoppers
and uncertain outcome as indicated by Frank's TODO:
https://elinux.org/Frank's_Evolving_Overlay_Thoughts
This appears also in our work process documents:
Documentation/process/4.Coding.rst
"experience has shown that excessive or premature
abstraction can be just as harmful as premature
optimization. Abstraction should be used to the level
required and no further."
So for that reason, or other predictable statements such
as "you're reinventing board files", I'd like to have an
open discussion on how to actually support these boards
with the mainline kernel and work on device drivers common
with other systems now, and not in 2020 when they are already
obsolete.
Yeah it is a bit controversial, but what we are doing right
now for non-discoverable expansion boards isn't working
in my opinion, so I have to throw something out there,
and this is it.
Linus Walleij (5):
RFC: gpio: Add API to explicitly name a consumer
RFC: eeprom: at24: Allow passing gpiodesc from pdata
RFC: spi: Make of_find_spi_device_by_node() available
RFC: bus: 96boards Low-Speed Connector
RFC: ARM64: dts: Add Low-Speed Connector to ZCU100
.../boot/dts/xilinx/zynqmp-zcu100-revC.dts | 27 +-
.../96boards-ls-connector.c | 307 ++++++++++++++++++
.../96boards-mezzanines/96boards-mezzanines.h | 46 +++
.../96boards-mezzanines/96boards-secure96.c | 249 ++++++++++++++
drivers/bus/96boards-mezzanines/Kconfig | 36 ++
drivers/bus/96boards-mezzanines/Makefile | 6 +
drivers/bus/Kconfig | 2 +
drivers/bus/Makefile | 4 +-
drivers/gpio/gpiolib.c | 13 +
drivers/misc/eeprom/at24.c | 6 +-
drivers/spi/spi.c | 33 +-
include/linux/gpio/consumer.h | 7 +
include/linux/platform_data/at24.h | 2 +
include/linux/spi/spi.h | 4 +
14 files changed, 723 insertions(+), 19 deletions(-)
create mode 100644 drivers/bus/96boards-mezzanines/96boards-ls-connector.c
create mode 100644 drivers/bus/96boards-mezzanines/96boards-mezzanines.h
create mode 100644 drivers/bus/96boards-mezzanines/96boards-secure96.c
create mode 100644 drivers/bus/96boards-mezzanines/Kconfig
create mode 100644 drivers/bus/96boards-mezzanines/Makefile
--
2.17.0
^ permalink raw reply
* [PATCH 1/5] RFC: gpio: Add API to explicitly name a consumer
From: Linus Walleij @ 2018-06-18 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-1-linus.walleij@linaro.org>
The GPIO (descriptor) API registers a "label" naming what is
currently using the GPIO line. Typically this is taken from
things like the device tree node, so "reset-gpios" will result
in he line being labeled "reset".
The technical effect is pretty much zero: the use is for
debug and introspection, such as "lsgpio" and debugfs files.
However sometimes the user want this cuddly feeling of
listing all GPIO lines and seeing exactly what they are for
and it gives a very fulfilling sense of control. Especially
in the cases when the device tree node doesn't provide a
good name, or anonymous GPIO lines assigned just to
"gpios" in the device tree because the usage is implicit.
For these cases it may be nice to be able to label the
line directly and explicitly.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/gpio/gpiolib.c | 13 +++++++++++++
include/linux/gpio/consumer.h | 7 +++++++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e11a3bb03820..c6f77e806cb8 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -3193,6 +3193,19 @@ int gpiod_cansleep(const struct gpio_desc *desc)
}
EXPORT_SYMBOL_GPL(gpiod_cansleep);
+/**
+ * gpiod_set_consumer_name() - set the consumer name for the descriptor
+ * @desc: gpio to set the consumer name on
+ * @name: the new consumer name
+ */
+void gpiod_set_consumer_name(struct gpio_desc *desc, const char *name)
+{
+ VALIDATE_DESC_VOID(desc);
+ /* Just overwrite whatever the previous name was */
+ desc->label = name;
+}
+EXPORT_SYMBOL_GPL(gpiod_set_consumer_name);
+
/**
* gpiod_to_irq() - return the IRQ corresponding to a GPIO
* @desc: gpio whose IRQ will be returned (already requested)
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 243112c7fa7d..e8aaf34dd65d 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -145,6 +145,7 @@ int gpiod_is_active_low(const struct gpio_desc *desc);
int gpiod_cansleep(const struct gpio_desc *desc);
int gpiod_to_irq(const struct gpio_desc *desc);
+void gpiod_set_consumer_name(struct gpio_desc *desc, const char *name);
/* Convert between the old gpio_ and new gpiod_ interfaces */
struct gpio_desc *gpio_to_desc(unsigned gpio);
@@ -467,6 +468,12 @@ static inline int gpiod_to_irq(const struct gpio_desc *desc)
return -EINVAL;
}
+static inline void gpiod_set_consumer_name(struct gpio_desc *desc, const char *name)
+{
+ /* GPIO can never have been requested */
+ WARN_ON(1);
+}
+
static inline struct gpio_desc *gpio_to_desc(unsigned gpio)
{
return ERR_PTR(-EINVAL);
--
2.17.0
^ permalink raw reply related
* [PATCH 2/5] RFC: eeprom: at24: Allow passing gpiodesc from pdata
From: Linus Walleij @ 2018-06-18 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-1-linus.walleij@linaro.org>
This makes it possible to pass an initialized GPIO descriptor
to the driver through platform data.
This is useful when we are dealing with EEPROMs on expansion
boards where the GPIO has to be looked up indirectly using a
connector abstraction (several systems using the same
connector) so the machine descriptor tables cannot be used
to associate the descriptor with the device and we then want
to pass this descriptor on to the EEPROM driver this way
instead.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/misc/eeprom/at24.c | 6 +++++-
include/linux/platform_data/at24.h | 2 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index f5cc517d1131..d577cdbe221e 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -662,7 +662,11 @@ static int at24_probe(struct i2c_client *client)
at24->client[0].client = client;
at24->client[0].regmap = regmap;
- at24->wp_gpio = devm_gpiod_get_optional(dev, "wp", GPIOD_OUT_HIGH);
+ if (pdata.wp_gpiod)
+ at24->wp_gpio = pdata.wp_gpiod;
+ else
+ at24->wp_gpio =
+ devm_gpiod_get_optional(dev, "wp", GPIOD_OUT_HIGH);
if (IS_ERR(at24->wp_gpio))
return PTR_ERR(at24->wp_gpio);
diff --git a/include/linux/platform_data/at24.h b/include/linux/platform_data/at24.h
index 63507ff464ee..5606fb2ef76c 100644
--- a/include/linux/platform_data/at24.h
+++ b/include/linux/platform_data/at24.h
@@ -11,6 +11,7 @@
#include <linux/types.h>
#include <linux/nvmem-consumer.h>
#include <linux/bitops.h>
+#include <linux/gpio/consumer.h>
/**
* struct at24_platform_data - data to set up at24 (generic eeprom) driver
@@ -55,6 +56,7 @@ struct at24_platform_data {
void (*setup)(struct nvmem_device *nvmem, void *context);
void *context;
+ struct gpio_desc *wp_gpiod;
};
#endif /* _LINUX_AT24_H */
--
2.17.0
^ permalink raw reply related
* [PATCH 3/5] RFC: spi: Make of_find_spi_device_by_node() available
From: Linus Walleij @ 2018-06-18 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-1-linus.walleij@linaro.org>
This externalizes and exports the symbol
of_find_spi_device_by_node() from the SPI core akin to how
of_find_i2c_adapter_by_node() is already available. As we will
need this also for non-dynamic OF setups, we move it under a
CONFIG_OF check.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/spi/spi.c | 33 ++++++++++++++++++---------------
include/linux/spi/spi.h | 4 ++++
2 files changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index ec395a6baf9c..6a1085077317 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -3314,27 +3314,14 @@ EXPORT_SYMBOL_GPL(spi_write_then_read);
/*-------------------------------------------------------------------------*/
-#if IS_ENABLED(CONFIG_OF_DYNAMIC)
-static int __spi_of_device_match(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
-/* must call put_device() when done with returned spi_device device */
-static struct spi_device *of_find_spi_device_by_node(struct device_node *node)
-{
- struct device *dev = bus_find_device(&spi_bus_type, NULL, node,
- __spi_of_device_match);
- return dev ? to_spi_device(dev) : NULL;
-}
-
+#if IS_ENABLED(CONFIG_OF)
static int __spi_of_controller_match(struct device *dev, const void *data)
{
return dev->of_node == data;
}
/* the spi controllers are not using spi_bus, so we find it with another way */
-static struct spi_controller *of_find_spi_controller_by_node(struct device_node *node)
+struct spi_controller *of_find_spi_controller_by_node(struct device_node *node)
{
struct device *dev;
@@ -3349,6 +3336,22 @@ static struct spi_controller *of_find_spi_controller_by_node(struct device_node
/* reference got in class_find_device */
return container_of(dev, struct spi_controller, dev);
}
+EXPORT_SYMBOL_GPL(of_find_spi_controller_by_node);
+#endif
+
+#if IS_ENABLED(CONFIG_OF_DYNAMIC)
+static int __spi_of_device_match(struct device *dev, void *data)
+{
+ return dev->of_node == data;
+}
+
+/* must call put_device() when done with returned spi_device device */
+static struct spi_device *of_find_spi_device_by_node(struct device_node *node)
+{
+ struct device *dev = bus_find_device(&spi_bus_type, NULL, node,
+ __spi_of_device_match);
+ return dev ? to_spi_device(dev) : NULL;
+}
static int of_spi_notify(struct notifier_block *nb, unsigned long action,
void *arg)
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index a64235e05321..c2be93224bd1 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -639,6 +639,10 @@ extern int devm_spi_register_controller(struct device *dev,
struct spi_controller *ctlr);
extern void spi_unregister_controller(struct spi_controller *ctlr);
+#if IS_ENABLED(CONFIG_OF)
+struct spi_controller *of_find_spi_controller_by_node(struct device_node *node);
+#endif
+
extern struct spi_controller *spi_busnum_to_master(u16 busnum);
/*
--
2.17.0
^ permalink raw reply related
* [PATCH 4/5] RFC: bus: 96boards Low-Speed Connector
From: Linus Walleij @ 2018-06-18 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-1-linus.walleij@linaro.org>
This illustrates my idea for using a small connector driver to
plug in "mezzanine boards" on the 96boards low-speed connector.
These "mezzanine boards" are no different than "capes", "logic
modules", etc. This thing, a non-discoverable connector where
a user can plug in a few peripherals has been reinvented a few
times.
As a proof-of-concept we add the Secure96, a quite minimal
mezzanine board.
Users can register their boards in a simple way. Either just
add their compatible-string in the device tree:
board {
compatible = "96boards,secure96";
};
And if they can't even change three lines in their device tree,
or if they at runtime decide to plug in some board and test it,
they can use sysfs, as exemplified by plugging in the secure96
security board at runtime:
> cd /sys/devices/platform/connector
> echo 1 > secure96
[ 61.014629] lscon connector: called mezzanine_store on secure96
[ 61.020530] lscon connector: populate secure96
[ 61.027081] at24 1-0050: 2048 byte 24c128 EEPROM, writable, 128 bytes/write
[ 61.053569] atmel-ecc 1-0060: configuration zone is unlocked
[ 61.502535] tpm_tis_spi spi0.0: 2.0 TPM (device-id 0x1B, rev-id 16)
(...)
The plug-in board can be removed from sysfs and added back
again multiple times like this with the devices being runtime
added and removed by two writes to sysfs.
> echo 0 > secure96
> echo 1 > secure96
> echo 0 > secure96
(...)
I certainly see some scalability problems with this particular
code for example, but the fact is: it pretty much works. The
devices need hooks in I2C and SPI, and need to be able to accept
initialized GPIO descriptors passed in as platform data.
Any discussions related to the concept compared to doing
device tree overlays/fragments etc: please discuss in patch
0 (the cover letter).
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../96boards-ls-connector.c | 307 ++++++++++++++++++
.../96boards-mezzanines/96boards-mezzanines.h | 46 +++
.../96boards-mezzanines/96boards-secure96.c | 249 ++++++++++++++
drivers/bus/96boards-mezzanines/Kconfig | 36 ++
drivers/bus/96boards-mezzanines/Makefile | 6 +
drivers/bus/Kconfig | 2 +
drivers/bus/Makefile | 4 +-
7 files changed, 649 insertions(+), 1 deletion(-)
create mode 100644 drivers/bus/96boards-mezzanines/96boards-ls-connector.c
create mode 100644 drivers/bus/96boards-mezzanines/96boards-mezzanines.h
create mode 100644 drivers/bus/96boards-mezzanines/96boards-secure96.c
create mode 100644 drivers/bus/96boards-mezzanines/Kconfig
create mode 100644 drivers/bus/96boards-mezzanines/Makefile
diff --git a/drivers/bus/96boards-mezzanines/96boards-ls-connector.c b/drivers/bus/96boards-mezzanines/96boards-ls-connector.c
new file mode 100644
index 000000000000..1a012b0cd457
--- /dev/null
+++ b/drivers/bus/96boards-mezzanines/96boards-ls-connector.c
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * 96boards Low-speed Connector driver
+ * (C) 2018 Linus Walleij <linus.walleij@linaro.org>
+ */
+
+#include <linux/init.h>
+#include <linux/sysfs.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/i2c.h>
+#include <linux/spi/spi.h>
+#include "96boards-mezzanines.h"
+
+/**
+ * struct mezzanine - daughter boards (mezzanines) data
+ * Having dynamic data here means that we can only plug ONE board
+ * of each type. Stacking two different boards is fine. This
+ * should be fixed using a linked list of mezzanines if we
+ * go for this solution.
+ */
+struct mezzanine {
+ const char *compatible;
+ const char *sysfs_name;
+ struct dev_ext_attribute ext_attr;
+ void * (*populate) (struct lscon *ls);
+ void (*depopulate) (void *data);
+ void *data;
+};
+
+static struct mezzanine mezzanines[] = {
+#if IS_ENABLED(96BOARDS_SECURE96)
+ {
+ .compatible = "96boards,secure96",
+ .sysfs_name = "secure96",
+ .populate = secure96_populate,
+ .depopulate = secure96_depopulate,
+ },
+#endif
+ /* Add any other mezzanines here */
+};
+
+struct gpio_desc *mezzanine_ls_get_gpiod(struct lscon *ls,
+ enum mezzanine_ls_gpio pin,
+ const char *consumer_name,
+ enum gpiod_flags flags)
+{
+ struct gpio_desc *retdesc;
+
+ /*
+ * TODO: get all the LS GPIOs as an array on probe() then
+ * the consumers can skip error handling of IS_ERR() descriptors
+ * and this need only set the consumer name.
+ */
+ retdesc = devm_gpiod_get_index(ls->dev, NULL, pin, flags);
+ if (!IS_ERR(retdesc) && consumer_name)
+ gpiod_set_consumer_name(retdesc, consumer_name);
+
+ return retdesc;
+}
+EXPORT_SYMBOL_GPL(mezzanine_ls_get_gpiod);
+
+/*
+ * Mezzanine boards will call this to orderly remove their claimed
+ * gpio descriptors, since we acquired them all with devm_gpiod_get()
+ * they will eventually be released once this connector device
+ * disappears if the board do not release them in order.
+ */
+void mezzanine_ls_put_gpiod(struct lscon *ls, struct gpio_desc *gpiod)
+{
+ devm_gpiod_put(ls->dev, gpiod);
+}
+EXPORT_SYMBOL_GPL(mezzanine_ls_put_gpiod);
+
+static ssize_t mezzanine_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct lscon *ls = dev_get_drvdata(dev);
+ struct dev_ext_attribute *d = container_of(attr,
+ struct dev_ext_attribute,
+ attr);
+ struct mezzanine *mez = d->var;
+
+ dev_info(ls->dev, "called %s on %s\n", __func__, mez->sysfs_name);
+ return 0;
+}
+
+static ssize_t mezzanine_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct lscon *ls = dev_get_drvdata(dev);
+ struct dev_ext_attribute *d = container_of(attr,
+ struct dev_ext_attribute,
+ attr);
+ struct mezzanine *mez = d->var;
+ unsigned long state;
+ int ret;
+
+ dev_info(ls->dev, "called %s on %s\n", __func__, mez->sysfs_name);
+
+ ret = kstrtoul(buf, 0, &state);
+ if (ret)
+ return ret;
+
+ if (state == 1) {
+ void *data;
+
+ /* Already populated */
+ if (mez->data)
+ return count;
+
+ data = mez->populate(ls);
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+ mez->data = data;
+ return count;
+ }
+
+ if (state == 0) {
+ /* Not populated so nothing to do here */
+ if (!mez->data)
+ return count;
+ mez->depopulate(mez->data);
+ mez->data = NULL;
+ return count;
+ }
+
+ return -EINVAL;
+}
+
+/**
+ * This adds one sysfs file per mezzanine board that we support, so they
+ * can be probed and added from userspace.
+ */
+static int lscon_add_sysfs_mezzanines(struct lscon *ls)
+{
+ struct mezzanine *mez;
+ struct dev_ext_attribute *ext_attr;
+ int ret;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(mezzanines); i++) {
+ mez = &mezzanines[i];
+ ext_attr = &mez->ext_attr;
+
+ ext_attr->var = mez;
+ ext_attr->attr.attr.name = mez->sysfs_name;
+ ext_attr->attr.attr.mode = VERIFY_OCTAL_PERMISSIONS(0644);
+ ext_attr->attr.show = mezzanine_show;
+ ext_attr->attr.store = mezzanine_store;
+ ret = device_create_file(ls->dev, &ext_attr->attr);
+ if (ret)
+ dev_err(ls->dev, "unable to create sysfs entries\n");
+
+ }
+
+ return 0;
+}
+
+static int lscon_probe_of_mezzanine(struct lscon *ls, struct device_node *np)
+{
+ struct mezzanine *mez;
+ void *data;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(mezzanines); i++) {
+ mez = &mezzanines[i];
+ if (of_device_is_compatible(np, mez->compatible)) {
+ dev_info(ls->dev, "found %s\n", mez->compatible);
+ data = mez->populate(ls);
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+ mez->data = data;
+ return 0;
+ }
+ }
+
+ return 0;
+}
+
+static int lscon_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *child;
+ struct spi_controller *spi;
+ struct mezzanine *mez;
+ struct lscon *ls;
+ int ret;
+ int i;
+
+ ls = devm_kzalloc(dev, sizeof(*ls), GFP_KERNEL);
+ if (!ls)
+ return -ENOMEM;
+ ls->dev = dev;
+
+ /* Bridge I2C busses */
+ child = of_parse_phandle(np, "i2c0", 0);
+ if (!child) {
+ dev_err(dev, "no i2c0 phandle\n");
+ return -ENODEV;
+ }
+ ls->i2c0 = of_get_i2c_adapter_by_node(child);
+ if (!ls->i2c0) {
+ dev_err(dev, "no i2c0 adapter, deferring\n");
+ return -EPROBE_DEFER;
+ }
+
+ child = of_parse_phandle(np, "i2c1", 0);
+ if (!child) {
+ dev_err(dev, "no i2c1 phandle\n");
+ ret = -ENODEV;
+ goto out_put_i2c0;
+ }
+ ls->i2c1 = of_get_i2c_adapter_by_node(child);
+ if (!ls->i2c1) {
+ dev_err(dev, "no i2c0 adapter, deferring\n");
+ ret = -EPROBE_DEFER;
+ goto out_put_i2c0;
+ }
+
+ /* Bride SPI bus */
+ child = of_parse_phandle(np, "spi", 0);
+ if (!child) {
+ dev_err(dev, "no spi phandle\n");
+ ret = -ENODEV;
+ goto out_put_i2c1;
+ }
+ spi = of_find_spi_controller_by_node(child);
+ if (!spi) {
+ dev_err(dev, "no spi controller, deferring\n");
+ ret = -EPROBE_DEFER;
+ goto out_put_i2c1;
+ }
+ ls->spi = spi_controller_get(spi);
+ if (!ls->spi) {
+ dev_err(dev, "no spi reference\n");
+ ret = -ENODEV;
+ goto out_put_i2c1;
+ }
+
+ platform_set_drvdata(pdev, ls);
+
+ /* Get the mezzanine boards, stacking possible */
+ for_each_available_child_of_node(np, child)
+ lscon_probe_of_mezzanine(ls, child);
+
+ ret = lscon_add_sysfs_mezzanines(ls);
+ if (ret)
+ goto out_remove_mezzanines;
+
+ return 0;
+
+out_remove_mezzanines:
+ /* Depopulate any populated boards */
+ for (i = 0; i < ARRAY_SIZE(mezzanines); i++) {
+ mez = &mezzanines[i];
+ if (mez->data)
+ mez->depopulate(mez->data);
+ mez->data = NULL;
+ }
+out_put_i2c1:
+ i2c_put_adapter(ls->i2c1);
+out_put_i2c0:
+ i2c_put_adapter(ls->i2c0);
+ return ret;
+}
+
+static int lscon_remove(struct platform_device *pdev)
+{
+ struct lscon *ls = platform_get_drvdata(pdev);
+ struct mezzanine *mez;
+ int i;
+
+ /* Depopulate any populated boards */
+ for (i = 0; i < ARRAY_SIZE(mezzanines); i++) {
+ mez = &mezzanines[i];
+ if (mez->data)
+ mez->depopulate(mez->data);
+ mez->data = NULL;
+ }
+
+ spi_controller_put(ls->spi);
+ i2c_put_adapter(ls->i2c1);
+ i2c_put_adapter(ls->i2c0);
+
+ return 0;
+}
+
+static const struct of_device_id lscon_of_match[] = {
+ {
+ .compatible = "96boards,low-speed-connector",
+ },
+};
+
+static struct platform_driver lscon_driver = {
+ .driver = {
+ .name = "lscon",
+ .of_match_table = of_match_ptr(lscon_of_match),
+ },
+ .probe = lscon_probe,
+ .remove = lscon_remove,
+};
+builtin_platform_driver(lscon_driver);
diff --git a/drivers/bus/96boards-mezzanines/96boards-mezzanines.h b/drivers/bus/96boards-mezzanines/96boards-mezzanines.h
new file mode 100644
index 000000000000..f6a460766ff3
--- /dev/null
+++ b/drivers/bus/96boards-mezzanines/96boards-mezzanines.h
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/of.h>
+#include <linux/i2c.h>
+#include <linux/gpio/consumer.h>
+
+/**
+ * enum mezzanine_ls_gpio - the GPIO lines on the low-speed connector
+ */
+enum mezzanine_ls_gpio {
+ MEZZANINE_LS_GPIO_A = 0,
+ MEZZANINE_LS_GPIO_B,
+ MEZZANINE_LS_GPIO_C,
+ MEZZANINE_LS_GPIO_D,
+ MEZZANINE_LS_GPIO_E,
+ MEZZANINE_LS_GPIO_F,
+ MEZZANINE_LS_GPIO_G,
+ MEZZANINE_LS_GPIO_H,
+ MEZZANINE_LS_GPIO_I,
+ MEZZANINE_LS_GPIO_J,
+ MEZZANINE_LS_GPIO_K,
+ MEZZANINE_LS_GPIO_L,
+};
+
+/**
+ * struct lscon - low speed connector state container
+ * @dev: containing device for this instance
+ */
+struct lscon {
+ struct device *dev;
+ struct i2c_adapter *i2c0;
+ struct i2c_adapter *i2c1;
+ struct spi_controller *spi;
+};
+
+struct gpio_desc *mezzanine_ls_get_gpiod(struct lscon *ls,
+ enum mezzanine_ls_gpio pin,
+ const char *consumer_name,
+ enum gpiod_flags flags);
+void mezzanine_ls_put_gpiod(struct lscon *ls, struct gpio_desc *gpiod);
+
+#if IS_ENABLED(96BOARDS_SECURE96)
+void *secure96_populate(struct lscon *ls);
+void secure96_depopulate(void *data);
+#endif
+/* Add any other mezzanine population calls here */
diff --git a/drivers/bus/96boards-mezzanines/96boards-secure96.c b/drivers/bus/96boards-mezzanines/96boards-secure96.c
new file mode 100644
index 000000000000..6c44a699d2e0
--- /dev/null
+++ b/drivers/bus/96boards-mezzanines/96boards-secure96.c
@@ -0,0 +1,249 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * 96boards Secure96 mezzanine board driver
+ * (C) 2018 Linus Walleij <linus.walleij@linaro.org>
+ */
+#include <linux/gpio/consumer.h>
+#include <linux/platform_device.h>
+#include <linux/leds.h>
+#include <linux/i2c.h>
+#include <linux/spi/spi.h>
+#include <linux/sizes.h>
+#include <linux/platform_data/at24.h>
+#include <linux/delay.h>
+
+#include "96boards-mezzanines.h"
+
+struct secure96 {
+ struct device *dev;
+ struct lscon *ls;
+ struct platform_device *leds_device;
+ struct gpio_led *secure96_leds;
+ struct i2c_client *eeprom;
+ struct i2c_client *crypto;
+ struct i2c_client *hash;
+ struct gpio_desc *tpm_reset;
+ struct gpio_desc *tpm_irq;
+ struct spi_device *tpm;
+};
+
+struct secure96_ledinfo {
+ enum mezzanine_ls_gpio pin;
+ const char *ledname;
+};
+
+/*
+ * GPIO-F, G, H and I are connected to LEDs, two red and two green
+ */
+static const struct secure96_ledinfo ledinfos[] = {
+ {
+ .pin = MEZZANINE_LS_GPIO_F,
+ .ledname = "secure96:red:0",
+ },
+ {
+ .pin = MEZZANINE_LS_GPIO_G,
+ .ledname = "secure96:red:1",
+ },
+ {
+ .pin = MEZZANINE_LS_GPIO_H,
+ .ledname = "secure96:green:0",
+ },
+ {
+ .pin = MEZZANINE_LS_GPIO_I,
+ .ledname = "secure96:green:1",
+ },
+};
+
+/*
+ * The On Semiconductor CAT21M01 is 131072bits i.e. 16KB. This should be
+ * mostly compatible to 24c128 so we register that with special pdata so
+ * that we can fill in the GPIO descriptor for write protect.
+ */
+static struct at24_platform_data secure96_eeprom_pdata = {
+ .byte_len = SZ_16K / 8,
+ .page_size = 256,
+ .flags = AT24_FLAG_ADDR16,
+};
+
+static const struct i2c_board_info secure96_eeprom = {
+ I2C_BOARD_INFO("24c128", 0x50),
+ .platform_data = &secure96_eeprom_pdata,
+};
+
+/* Crypto chip */
+static const struct i2c_board_info secure96_crypto = {
+ I2C_BOARD_INFO("atecc508a", 0x60),
+};
+
+/* SHA hash chip */
+static const struct i2c_board_info secure96_hash = {
+ I2C_BOARD_INFO("atsha204a", 0x64),
+};
+
+/* Infineon SLB9670 TPM 2.0 chip */
+static struct spi_board_info secure96_tpm = {
+ .modalias = "tpm_tis_spi",
+ /* The manual says 22.5MHz for 1.8V supply */
+ .max_speed_hz = 22500000,
+ .chip_select = 0,
+};
+
+void *secure96_populate(struct lscon *ls)
+{
+ struct device *dev = ls->dev;
+ struct secure96 *sec;
+ struct gpio_desc *gpiod;
+ struct gpio_led_platform_data secure96_leds_pdata;
+ int ret;
+ int i;
+
+ /* TODO: create a struct device for secure96? */
+
+ sec = devm_kzalloc(dev, sizeof(*sec), GFP_KERNEL);
+ if (!sec)
+ return ERR_PTR(-ENOMEM);
+ sec->dev = dev;
+ sec->ls = ls;
+
+ sec->secure96_leds = devm_kzalloc(dev,
+ ARRAY_SIZE(ledinfos) * sizeof(*sec->secure96_leds),
+ GFP_KERNEL);
+ if (!sec->secure96_leds)
+ return ERR_PTR(-ENOMEM);
+
+ dev_info(ls->dev, "populate secure96\n");
+
+ /* Populate the four LEDs */
+ for (i = 0; i < ARRAY_SIZE(ledinfos); i++) {
+ const struct secure96_ledinfo *linfo;
+
+ linfo = &ledinfos[i];
+
+ gpiod = mezzanine_ls_get_gpiod(ls, linfo->pin, linfo->ledname,
+ GPIOD_OUT_LOW);
+ if (IS_ERR(gpiod)) {
+ dev_err(dev, "failed to get GPIO line %d\n",
+ linfo->pin);
+ return ERR_PTR(-ENODEV);
+ }
+ sec->secure96_leds[i].gpiod = gpiod;
+ sec->secure96_leds[i].name = linfo->ledname;
+ /* Heartbeat on first LED */
+ if (i == 0)
+ sec->secure96_leds[i].default_trigger = "heartbeat";
+ }
+
+ secure96_leds_pdata.num_leds = ARRAY_SIZE(ledinfos);
+ secure96_leds_pdata.leds = sec->secure96_leds;
+
+ sec->leds_device = platform_device_register_data(dev,
+ "leds-gpio",
+ PLATFORM_DEVID_AUTO,
+ &secure96_leds_pdata,
+ sizeof(secure96_leds_pdata));
+ if (IS_ERR(sec->leds_device)) {
+ dev_err(dev, "failed to populate LEDs device\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ /* Populate the three I2C0 devices */
+ gpiod = mezzanine_ls_get_gpiod(ls, MEZZANINE_LS_GPIO_B, "cat21m01-wp",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(gpiod))
+ dev_err(dev, "no CAT21M01 write-protect GPIO\n");
+ else
+ secure96_eeprom_pdata.wp_gpiod = gpiod;
+ sec->eeprom = i2c_new_device(ls->i2c0, &secure96_eeprom);
+ if (!sec->eeprom) {
+ dev_err(dev, "failed to populate EEPROM\n");
+ ret = -ENODEV;
+ goto out_unreg_leds;
+ }
+
+ sec->crypto = i2c_new_device(ls->i2c0, &secure96_crypto);
+ if (!sec->eeprom) {
+ dev_err(dev, "failed to populate crypto device\n");
+ ret = -ENODEV;
+ goto out_remove_eeprom;
+ }
+
+ sec->hash = i2c_new_device(ls->i2c0, &secure96_hash);
+ if (!sec->eeprom) {
+ dev_err(dev, "failed to populate hash device\n");
+ ret = -ENODEV;
+ goto out_remove_crypto;
+ }
+
+ /* Populate the SPI TPM device */
+ gpiod = mezzanine_ls_get_gpiod(ls, MEZZANINE_LS_GPIO_D,
+ "tpm-slb9670-rst",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(gpiod)) {
+ dev_err(dev, "failed to get TPM RESET\n");
+ ret = -ENODEV;
+ goto out_remove_hash;
+ }
+ udelay(80);
+ /* Deassert RST */
+ gpiod_set_value(gpiod, 1);
+ sec->tpm_reset = gpiod;
+
+ gpiod = mezzanine_ls_get_gpiod(ls, MEZZANINE_LS_GPIO_C,
+ "tpm-slb9670-irq",
+ GPIOD_IN);
+ if (IS_ERR(gpiod)) {
+ dev_err(dev, "failed to get TPM IRQ GPIO\n");
+ ret = -ENODEV;
+ goto out_remove_tpm_reset;
+ }
+ sec->tpm_irq = gpiod;
+ secure96_tpm.irq = gpiod_to_irq(gpiod);
+ sec->tpm = spi_new_device(ls->spi, &secure96_tpm);
+ if (!sec->tpm) {
+ dev_err(dev, "failed to populate TPM device\n");
+ ret = -ENODEV;
+ goto out_remove_tpm_irq;
+ }
+
+ return sec;
+
+out_remove_tpm_irq:
+ mezzanine_ls_put_gpiod(ls, sec->tpm_irq);
+out_remove_tpm_reset:
+ mezzanine_ls_put_gpiod(ls, sec->tpm_reset);
+out_remove_hash:
+ i2c_unregister_device(sec->hash);
+out_remove_crypto:
+ i2c_unregister_device(sec->crypto);
+out_remove_eeprom:
+ i2c_unregister_device(sec->eeprom);
+ if (secure96_eeprom_pdata.wp_gpiod)
+ mezzanine_ls_put_gpiod(ls, secure96_eeprom_pdata.wp_gpiod);
+out_unreg_leds:
+ platform_device_unregister(sec->leds_device);
+ for (i = 0; i < ARRAY_SIZE(ledinfos); i++) {
+ mezzanine_ls_put_gpiod(ls, sec->secure96_leds[i].gpiod);
+ };
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(secure96_populate);
+
+void secure96_depopulate(void *data)
+{
+ struct secure96 *sec = data;
+ int i;
+
+ spi_unregister_device(sec->tpm);
+ mezzanine_ls_put_gpiod(sec->ls, sec->tpm_irq);
+ mezzanine_ls_put_gpiod(sec->ls, sec->tpm_reset);
+ i2c_unregister_device(sec->hash);
+ i2c_unregister_device(sec->crypto);
+ i2c_unregister_device(sec->eeprom);
+ if (secure96_eeprom_pdata.wp_gpiod)
+ mezzanine_ls_put_gpiod(sec->ls, secure96_eeprom_pdata.wp_gpiod);
+ platform_device_unregister(sec->leds_device);
+ for (i = 0; i < ARRAY_SIZE(ledinfos); i++) {
+ mezzanine_ls_put_gpiod(sec->ls, sec->secure96_leds[i].gpiod);
+ };
+}
+EXPORT_SYMBOL_GPL(secure96_depopulate);
diff --git a/drivers/bus/96boards-mezzanines/Kconfig b/drivers/bus/96boards-mezzanines/Kconfig
new file mode 100644
index 000000000000..18f94e9ec0f8
--- /dev/null
+++ b/drivers/bus/96boards-mezzanines/Kconfig
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# 96boards mezzanine connectors and drivers
+
+menuconfig 96BOARDS_MEZZANINES
+ bool "96boards mezzanine boards"
+
+if 96BOARDS_MEZZANINES
+
+config 96BOARDS_LS_CONNECTOR
+ bool "96boards low speed connector driver"
+ depends on OF
+ depends on I2C
+ depends on SPI_MASTER
+ depends on GPIOLIB
+ help
+ Driver for the 96boards low speed connector
+
+config 96BOARDS_SECURE96
+ bool "96boards Secure96 board driver"
+ depends on 96BOARDS_LS_CONNECTOR
+ select NEW_LEDS
+ select LEDS_CLASS
+ select LEDS_GPIO
+ select EEPROM_AT24
+ select CRYPTO_HW
+ select CRYPTO_DEV_ATMEL_ECC
+ select HW_RANDOM
+ select TCG_TPM
+ select HW_RANDOM_TPM
+ select TCG_TIS
+ select TCG_TIS_SPI
+ help
+ Driver for the 96boards Secure96 mezzanine
+
+endif
diff --git a/drivers/bus/96boards-mezzanines/Makefile b/drivers/bus/96boards-mezzanines/Makefile
new file mode 100644
index 000000000000..a6e1f3507672
--- /dev/null
+++ b/drivers/bus/96boards-mezzanines/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the 96boards mezzanines
+#
+obj-$(CONFIG_96BOARDS_LS_CONNECTOR) += 96boards-ls-connector.o
+obj-$(CONFIG_96BOARDS_SECURE96) += 96boards-secure96.o
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index d1c0b60e9326..46f7785f27e9 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -173,4 +173,6 @@ config DA8XX_MSTPRI
source "drivers/bus/fsl-mc/Kconfig"
+source "drivers/bus/96boards-mezzanines/Kconfig"
+
endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index b8f036cca7ff..f6d080a63bd7 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -29,5 +29,7 @@ obj-$(CONFIG_TI_SYSC) += ti-sysc.o
obj-$(CONFIG_TS_NBUS) += ts-nbus.o
obj-$(CONFIG_UNIPHIER_SYSTEM_BUS) += uniphier-system-bus.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
-
obj-$(CONFIG_DA8XX_MSTPRI) += da8xx-mstpri.o
+
+# 96boards mezzanines
+obj-$(CONFIG_96BOARDS_MEZZANINES) += 96boards-mezzanines/
--
2.17.0
^ permalink raw reply related
* [PATCH 5/5] RFC: ARM64: dts: Add Low-Speed Connector to ZCU100
From: Linus Walleij @ 2018-06-18 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-1-linus.walleij@linaro.org>
This adds the low-speed connector to the ZCU100 rev C device
tree (also known as the Ultra96 board).
This is a proof-of-concept only, showing how it is possible
to populate a Secure96 board using the other patches in the
series.
If you comment out or delete the board {} node, you can
populate/depopulate the board from sysfs instead.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../boot/dts/xilinx/zynqmp-zcu100-revC.dts | 27 +++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
index d62276e0e0a9..fc30497f248d 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
@@ -110,6 +110,28 @@
compatible = "mmc-pwrseq-simple";
reset-gpios = <&gpio 7 GPIO_ACTIVE_LOW>; /* WIFI_EN */
};
+
+ lscon: connector {
+ compatible = "96boards,low-speed-connector";
+ i2c0 = <&i2csw_0>;
+ i2c1 = <&i2csw_1>;
+ spi = <&spi0>;
+ gpios = <&gpio 36 GPIO_ACTIVE_HIGH>, /* GPIO-A */
+ <&gpio 37 GPIO_ACTIVE_HIGH>, /* GPIO-B */
+ <&gpio 39 GPIO_ACTIVE_HIGH>, /* GPIO-C */
+ <&gpio 40 GPIO_ACTIVE_HIGH>, /* GPIO-D */
+ <&gpio 44 GPIO_ACTIVE_HIGH>, /* GPIO-E */
+ <&gpio 45 GPIO_ACTIVE_HIGH>, /* GPIO-F */
+ <&gpio 78 GPIO_ACTIVE_HIGH>, /* GPIO-G */
+ <&gpio 79 GPIO_ACTIVE_HIGH>, /* GPIO-H */
+ <&gpio 80 GPIO_ACTIVE_HIGH>, /* GPIO-I */
+ <&gpio 81 GPIO_ACTIVE_HIGH>, /* GPIO-J */
+ <&gpio 82 GPIO_ACTIVE_HIGH>, /* GPIO-K */
+ <&gpio 83 GPIO_ACTIVE_HIGH>; /* GPIO-L */
+ board {
+ compatible = "96boards,secure96";
+ };
+ };
};
&dcc {
@@ -134,8 +156,9 @@
"USB1_DIR", "USB1_DATA2", "USB1_NXT", "USB1_DATA0", "USB1_DATA1",
"USB1_STP", "USB1_DATA3", "USB1_DATA4", "USB1_DATA5", "USB1_DATA6",
"USB_DATA7", "WLAN_IRQ", "PMIC_IRQ", /* MIO end and EMIO start */
- "", "",
- "", "", "", "", "", "", "", "", "", "",
+ "GPIO-G", "GPIO-H",
+ "GPIO-I", "GPIO-J", "GPIO-K", "GPIO-L",
+ "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "",
--
2.17.0
^ permalink raw reply related
* [PATCH v3 24/27] devicetree: fix a series of wrong file references
From: Alexandre Torgue @ 2018-06-18 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bce1b59268ac2d659fd7cb37f89285ef2acc8316.1528990947.git.mchehab+samsung@kernel.org>
On 06/14/2018 06:09 PM, Mauro Carvalho Chehab wrote:
> As files got renamed, their references broke.
>
> Manually fix a series of broken refs at the DT bindings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
For stm32 part:
Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
Thanks
Alex
> .../devicetree/bindings/input/rmi4/rmi_2d_sensor.txt | 2 +-
> Documentation/devicetree/bindings/mfd/sun6i-prcm.txt | 2 +-
> .../devicetree/bindings/pci/hisilicon-pcie.txt | 2 +-
> Documentation/devicetree/bindings/pci/kirin-pcie.txt | 2 +-
> .../devicetree/bindings/pci/pci-keystone.txt | 4 ++--
> .../devicetree/bindings/sound/st,stm32-i2s.txt | 2 +-
> .../devicetree/bindings/sound/st,stm32-sai.txt | 2 +-
> MAINTAINERS | 12 ++++++------
> 8 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> index f2c30c8b725d..9afffbdf6e28 100644
> --- a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> @@ -12,7 +12,7 @@ Additional documentation for F11 can be found at:
> http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
>
> Optional Touch Properties:
> -Description in Documentation/devicetree/bindings/input/touch
> +Description in Documentation/devicetree/bindings/input/touchscreen
> - touchscreen-inverted-x
> - touchscreen-inverted-y
> - touchscreen-swapped-x-y
> diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> index 4d21ffdb0fc1..daa091c2e67b 100644
> --- a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> +++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> @@ -8,7 +8,7 @@ Required properties:
> - reg: The PRCM registers range
>
> The prcm node may contain several subdevices definitions:
> - - see Documentation/devicetree/clk/sunxi.txt for clock devices
> + - see Documentation/devicetree/bindings/clock/sunxi.txt for clock devices
> - see Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt for reset
> controller devices
>
> diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> index 7bf9df047a1e..0dcb87d6554f 100644
> --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> @@ -3,7 +3,7 @@ HiSilicon Hip05 and Hip06 PCIe host bridge DT description
> HiSilicon PCIe host controller is based on the Synopsys DesignWare PCI core.
> It shares common functions with the PCIe DesignWare core driver and inherits
> common properties defined in
> -Documentation/devicetree/bindings/pci/designware-pci.txt.
> +Documentation/devicetree/bindings/pci/designware-pcie.txt.
>
> Additional properties are described here:
>
> diff --git a/Documentation/devicetree/bindings/pci/kirin-pcie.txt b/Documentation/devicetree/bindings/pci/kirin-pcie.txt
> index 6e217c63123d..6bbe43818ad5 100644
> --- a/Documentation/devicetree/bindings/pci/kirin-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/kirin-pcie.txt
> @@ -3,7 +3,7 @@ HiSilicon Kirin SoCs PCIe host DT description
> Kirin PCIe host controller is based on the Synopsys DesignWare PCI core.
> It shares common functions with the PCIe DesignWare core driver and
> inherits common properties defined in
> -Documentation/devicetree/bindings/pci/designware-pci.txt.
> +Documentation/devicetree/bindings/pci/designware-pcie.txt.
>
> Additional properties are described here:
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-keystone.txt b/Documentation/devicetree/bindings/pci/pci-keystone.txt
> index 7e05487544ed..3d4a209b0fd0 100644
> --- a/Documentation/devicetree/bindings/pci/pci-keystone.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-keystone.txt
> @@ -3,9 +3,9 @@ TI Keystone PCIe interface
> Keystone PCI host Controller is based on the Synopsys DesignWare PCI
> hardware version 3.65. It shares common functions with the PCIe DesignWare
> core driver and inherits common properties defined in
> -Documentation/devicetree/bindings/pci/designware-pci.txt
> +Documentation/devicetree/bindings/pci/designware-pcie.txt
>
> -Please refer to Documentation/devicetree/bindings/pci/designware-pci.txt
> +Please refer to Documentation/devicetree/bindings/pci/designware-pcie.txt
> for the details of DesignWare DT bindings. Additional properties are
> described here as well as properties that are not applicable.
>
> diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt b/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> index 4bda52042402..58c341300552 100644
> --- a/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> @@ -18,7 +18,7 @@ Required properties:
> See Documentation/devicetree/bindings/dma/stm32-dma.txt.
> - dma-names: Identifier for each DMA request line. Must be "tx" and "rx".
> - pinctrl-names: should contain only value "default"
> - - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt
> + - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
>
> Optional properties:
> - resets: Reference to a reset controller asserting the reset controller
> diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
> index f301cdf0b7e6..3a3fc506e43a 100644
> --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
> +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
> @@ -37,7 +37,7 @@ SAI subnodes required properties:
> "tx": if sai sub-block is configured as playback DAI
> "rx": if sai sub-block is configured as capture DAI
> - pinctrl-names: should contain only value "default"
> - - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt
> + - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
>
> SAI subnodes Optional properties:
> - st,sync: specify synchronization mode.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 67641f5bb373..69c9e9924902 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6965,7 +6965,7 @@ IIO MULTIPLEXER
> M: Peter Rosin <peda@axentia.se>
> L: linux-iio at vger.kernel.org
> S: Maintained
> -F: Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
> +F: Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
> F: drivers/iio/multiplexer/iio-mux.c
>
> IIO SUBSYSTEM AND DRIVERS
> @@ -9695,7 +9695,7 @@ MXSFB DRM DRIVER
> M: Marek Vasut <marex@denx.de>
> S: Supported
> F: drivers/gpu/drm/mxsfb/
> -F: Documentation/devicetree/bindings/display/mxsfb-drm.txt
> +F: Documentation/devicetree/bindings/display/mxsfb.txt
>
> MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
> M: Chris Lee <christopher.lee@cspi.com>
> @@ -10884,7 +10884,7 @@ M: Will Deacon <will.deacon@arm.com>
> L: linux-pci at vger.kernel.org
> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> -F: Documentation/devicetree/bindings/pci/controller-generic-pci.txt
> +F: Documentation/devicetree/bindings/pci/host-generic-pci.txt
> F: drivers/pci/controller/pci-host-common.c
> F: drivers/pci/controller/pci-host-generic.c
>
> @@ -11065,7 +11065,7 @@ M: Xiaowei Song <songxiaowei@hisilicon.com>
> M: Binghui Wang <wangbinghui@hisilicon.com>
> L: linux-pci at vger.kernel.org
> S: Maintained
> -F: Documentation/devicetree/bindings/pci/pcie-kirin.txt
> +F: Documentation/devicetree/bindings/pci/kirin-pcie.txt
> F: drivers/pci/controller/dwc/pcie-kirin.c
>
> PCIE DRIVER FOR HISILICON STB
> @@ -12456,7 +12456,7 @@ L: linux-crypto at vger.kernel.org
> L: linux-samsung-soc at vger.kernel.org
> S: Maintained
> F: drivers/crypto/exynos-rng.c
> -F: Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt
> +F: Documentation/devicetree/bindings/rng/samsung,exynos4-rng.txt
>
> SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER
> M: ?ukasz Stelmach <l.stelmach@samsung.com>
> @@ -13570,7 +13570,7 @@ F: drivers/*/stm32-*timer*
> F: drivers/pwm/pwm-stm32*
> F: include/linux/*/stm32-*tim*
> F: Documentation/ABI/testing/*timer-stm32
> -F: Documentation/devicetree/bindings/*/stm32-*timer
> +F: Documentation/devicetree/bindings/*/stm32-*timer*
> F: Documentation/devicetree/bindings/pwm/pwm-stm32*
>
> STMMAC ETHERNET DRIVER
>
^ permalink raw reply
* [PATCH v4 0/3] Add controls for VP8/VP9 profile
From: Keiichi Watanabe @ 2018-06-18 7:58 UTC (permalink / raw)
To: linux-arm-kernel
Here is the 4th revision of the patch set that adds controls for VP8/VP9
profiles. Please see v3 cover letter for more details.
<https://lkml.org/lkml/2018/6/14/132>
In this version, I changed the contents that pointed out by Stanimir and Hans.
Changelog
----------
Version 4 changes:
- Remove unnecessary changes in venus drivers.
- Remove unnecessary blank lines in documentations.
- Fix typo and grammar mistakes.
Version 3 changes:
- Add V4L2_CID_MPEG_VIDEO_VP8_PROFILE in v4l2-controls.
- Make V4L2_CID_MPEG_VIDEO_VPX_PROFILE to be an alias of
V4L2_CID_MPEG_VIDEO_VP8_PROFILE.
- Fix the use of V4L2_CID_MPEG_VIDEO_VPX_PROFILE in venus/s5p_mfc drivers.
- Small fix in mtk_vcodec_dec.
Version 2 changes:
- Support V4L2_CID_MPEG_VIDEO_VP9_PROFILE in MediaTek decoder's driver.
Version 1 changes:
- Add V4L2_CID_MPEG_VIDEO_VP9_PROFILE in v4l2-controls.
Keiichi Watanabe (3):
media: v4l2-ctrl: Change control for VP8 profile to menu control
media: v4l2-ctrl: Add control for VP9 profile
media: mtk-vcodec: Support VP9 profile in decoder
.../media/uapi/v4l/extended-controls.rst | 48 +++++++++++++++++--
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 5 ++
.../media/platform/qcom/venus/vdec_ctrls.c | 10 ++--
drivers/media/platform/qcom/venus/venc.c | 4 +-
.../media/platform/qcom/venus/venc_ctrls.c | 10 ++--
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 15 +++---
drivers/media/v4l2-core/v4l2-ctrls.c | 23 ++++++++-
include/uapi/linux/v4l2-controls.h | 18 ++++++-
8 files changed, 110 insertions(+), 23 deletions(-)
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply
* [PATCH v4 1/3] media: v4l2-ctrl: Change control for VP8 profile to menu control
From: Keiichi Watanabe @ 2018-06-18 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618075854.12881-1-keiichiw@chromium.org>
Add a menu control V4L2_CID_MPEG_VIDEO_VP8_PROFILE for VP8 profile and make
V4L2_CID_MPEG_VIDEO_VPX_PROFILE an alias of it. This new control is used to
select the desired profile for VP8 encoder and query for supported profiles by
VP8 encoder/decoder.
Though we have originally a control V4L2_CID_MPEG_VIDEO_VPX_PROFILE and its name
contains 'VPX', it works only for VP8 because supported profiles usually differ
between VP8 and VP9. In addition, this control cannot be used for querying since
it is not a menu control but an integer control, which cannot return an
arbitrary set of supported profiles.
The new control V4L2_CID_MPEG_VIDEO_VP8_PROFILE is a menu control as with
controls for other codec profiles. (e.g. H264)
In addition, this patch also fixes the use of V4L2_CID_MPEG_VIDEO_VPX_PROFILE in
drivers of Qualcomm's venus and Samsung's s5p-mfc.
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
---
.../media/uapi/v4l/extended-controls.rst | 25 ++++++++++++++++---
.../media/platform/qcom/venus/vdec_ctrls.c | 10 +++++---
drivers/media/platform/qcom/venus/venc.c | 4 +--
.../media/platform/qcom/venus/venc_ctrls.c | 10 +++++---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 15 ++++++-----
drivers/media/v4l2-core/v4l2-ctrls.c | 12 ++++++++-
include/uapi/linux/v4l2-controls.h | 11 +++++++-
7 files changed, 64 insertions(+), 23 deletions(-)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
index 03931f9b1285..01ef31a934b4 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1955,9 +1955,28 @@ enum v4l2_vp8_golden_frame_sel -
``V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (integer)``
Quantization parameter for a P frame for VP8.
-``V4L2_CID_MPEG_VIDEO_VPX_PROFILE (integer)``
- Select the desired profile for VPx encoder. Acceptable values are 0,
- 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
+.. _v4l2-mpeg-video-vp8-profile:
+
+``V4L2_CID_MPEG_VIDEO_VP8_PROFILE``
+ (enum)
+
+enum v4l2_mpeg_video_vp8_profile -
+ This control allows selecting the profile for VP8 encoder.
+ This is also used to enumerate supported profiles by VP8 encoder or decoder.
+ Possible values are:
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_0``
+ - Profile 0
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_1``
+ - Profile 1
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_2``
+ - Profile 2
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
+ - Profile 3
High Efficiency Video Coding (HEVC/H.265) Control Reference
diff --git a/drivers/media/platform/qcom/venus/vdec_ctrls.c b/drivers/media/platform/qcom/venus/vdec_ctrls.c
index 032839bbc967..f4604b0cd57e 100644
--- a/drivers/media/platform/qcom/venus/vdec_ctrls.c
+++ b/drivers/media/platform/qcom/venus/vdec_ctrls.c
@@ -29,7 +29,7 @@ static int vdec_op_s_ctrl(struct v4l2_ctrl *ctrl)
break;
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
ctr->profile = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
@@ -54,7 +54,7 @@ static int vdec_op_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
switch (ctrl->id) {
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
ret = hfi_session_get_property(inst, ptype, &hprop);
if (!ret)
ctr->profile = hprop.profile_level.profile;
@@ -130,8 +130,10 @@ int vdec_ctrl_init(struct venus_inst *inst)
if (ctrl)
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
- ctrl = v4l2_ctrl_new_std(&inst->ctrl_handler, &vdec_ctrl_ops,
- V4L2_CID_MPEG_VIDEO_VPX_PROFILE, 0, 3, 1, 0);
+ ctrl = v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &vdec_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_3,
+ 0, V4L2_MPEG_VIDEO_VP8_PROFILE_0);
if (ctrl)
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
diff --git a/drivers/media/platform/qcom/venus/venc.c b/drivers/media/platform/qcom/venus/venc.c
index 6b2ce479584e..cba6ef1e2d04 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -223,7 +223,7 @@ static int venc_v4l2_to_hfi(int id, int value)
case V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC:
return HFI_H264_ENTROPY_CABAC;
}
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
switch (value) {
case 0:
default:
@@ -756,7 +756,7 @@ static int venc_set_properties(struct venus_inst *inst)
level = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_H264_LEVEL,
ctr->level.h264);
} else if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_VP8) {
- profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
+ profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
ctr->profile.vpx);
level = 0;
} else if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_MPEG4) {
diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c b/drivers/media/platform/qcom/venus/venc_ctrls.c
index 21e938a28662..459101728d26 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -101,7 +101,7 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
ctr->profile.h264 = ctrl->val;
break;
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
ctr->profile.vpx = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
@@ -248,6 +248,11 @@ int venc_ctrl_init(struct venus_inst *inst)
V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_BYTES,
0, V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_SINGLE);
+ v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_3,
+ 0, V4L2_MPEG_VIDEO_VP8_PROFILE_0);
+
v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
V4L2_CID_MPEG_VIDEO_BITRATE, BITRATE_MIN, BITRATE_MAX,
BITRATE_STEP, BITRATE_DEFAULT);
@@ -256,9 +261,6 @@ int venc_ctrl_init(struct venus_inst *inst)
V4L2_CID_MPEG_VIDEO_BITRATE_PEAK, BITRATE_MIN, BITRATE_MAX,
BITRATE_STEP, BITRATE_DEFAULT_PEAK);
- v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
- V4L2_CID_MPEG_VIDEO_VPX_PROFILE, 0, 3, 1, 0);
-
v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP, 1, 51, 1, 26);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 570f391f2cfd..3ad4f5073002 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -692,12 +692,12 @@ static struct mfc_control controls[] = {
.default_value = 10,
},
{
- .id = V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .minimum = 0,
- .maximum = 3,
- .step = 1,
- .default_value = 0,
+ .id = V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
+ .type = V4L2_CTRL_TYPE_MENU,
+ .minimum = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
+ .maximum = V4L2_MPEG_VIDEO_VP8_PROFILE_3,
+ .default_value = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
+ .menu_skip_mask = 0,
},
{
.id = V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP,
@@ -2057,7 +2057,7 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:
p->codec.vp8.rc_p_frame_qp = ctrl->val;
break;
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
p->codec.vp8.profile = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:
@@ -2711,4 +2711,3 @@ void s5p_mfc_enc_init(struct s5p_mfc_ctx *ctx)
f.fmt.pix_mp.pixelformat = DEF_DST_FMT_ENC;
ctx->dst_fmt = find_format(&f, MFC_FMT_ENC);
}
-
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index d29e45516eb7..e7e6340b395e 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Use Previous Specific Frame",
NULL,
};
+ static const char * const vp8_profile[] = {
+ "0",
+ "1",
+ "2",
+ "3",
+ NULL,
+ };
static const char * const flash_led_mode[] = {
"Off",
@@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
return vpx_golden_frame_sel;
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
+ return vp8_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
case V4L2_CID_DV_TX_MODE:
@@ -839,7 +848,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_MAX_QP: return "VPX Maximum QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP: return "VPX I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX Profile";
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE: return "VP8 Profile";
/* HEVC controls */
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
@@ -1180,6 +1189,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
case V4L2_CID_DEINTERLACING_MODE:
case V4L2_CID_TUNE_DEEMPHASIS:
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
case V4L2_CID_DETECT_MD_MODE:
case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 8d473c979b61..2001823c3072 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -587,7 +587,16 @@ enum v4l2_vp8_golden_frame_sel {
#define V4L2_CID_MPEG_VIDEO_VPX_MAX_QP (V4L2_CID_MPEG_BASE+508)
#define V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP (V4L2_CID_MPEG_BASE+509)
#define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
-#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE (V4L2_CID_MPEG_BASE+511)
+
+#define V4L2_CID_MPEG_VIDEO_VP8_PROFILE (V4L2_CID_MPEG_BASE+511)
+enum v4l2_mpeg_video_vp8_profile {
+ V4L2_MPEG_VIDEO_VP8_PROFILE_0 = 0,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_1 = 1,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_2 = 2,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_3 = 3,
+};
+/* Deprecated alias for compatibility reasons. */
+#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE V4L2_CID_MPEG_VIDEO_VP8_PROFILE
/* CIDs for HEVC encoding. */
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 2/3] media: v4l2-ctrl: Add control for VP9 profile
From: Keiichi Watanabe @ 2018-06-18 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618075854.12881-1-keiichiw@chromium.org>
Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for VP9 profiles. This control
allows selecting the desired profile for VP9 encoder and querying for supported
profiles by VP9 encoder/decoder.
Though this control is similar to V4L2_CID_MPEG_VIDEO_VP8_PROFILE, we need to
separate this control from it because supported profiles usually differ between
VP8 and VP9.
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
---
.../media/uapi/v4l/extended-controls.rst | 23 +++++++++++++++++++
drivers/media/v4l2-core/v4l2-ctrls.c | 11 +++++++++
include/uapi/linux/v4l2-controls.h | 7 ++++++
3 files changed, 41 insertions(+)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
index 01ef31a934b4..9f7312bf3365 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1978,6 +1978,29 @@ enum v4l2_mpeg_video_vp8_profile -
* - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
- Profile 3
+.. _v4l2-mpeg-video-vp9-profile:
+
+``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
+ (enum)
+
+enum v4l2_mpeg_video_vp9_profile -
+ This control allows selecting the profile for VP9 encoder.
+ This is also used to enumerate supported profiles by VP9 encoder or decoder.
+ Possible values are:
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_0``
+ - Profile 0
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_1``
+ - Profile 1
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_2``
+ - Profile 2
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_3``
+ - Profile 3
+
High Efficiency Video Coding (HEVC/H.265) Control Reference
-----------------------------------------------------------
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index e7e6340b395e..eacfab7574dc 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -438,6 +438,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"3",
NULL,
};
+ static const char * const vp9_profile[] = {
+ "0",
+ "1",
+ "2",
+ "3",
+ NULL,
+ };
static const char * const flash_led_mode[] = {
"Off",
@@ -623,6 +630,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return vpx_golden_frame_sel;
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
return vp8_profile;
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
+ return vp9_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
case V4L2_CID_DV_TX_MODE:
@@ -849,6 +858,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP: return "VPX I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE: return "VP8 Profile";
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE: return "VP9 Profile";
/* HEVC controls */
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
@@ -1190,6 +1200,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
case V4L2_CID_TUNE_DEEMPHASIS:
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
case V4L2_CID_DETECT_MD_MODE:
case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 2001823c3072..f03d3214eec2 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -597,6 +597,13 @@ enum v4l2_mpeg_video_vp8_profile {
};
/* Deprecated alias for compatibility reasons. */
#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE V4L2_CID_MPEG_VIDEO_VP8_PROFILE
+#define V4L2_CID_MPEG_VIDEO_VP9_PROFILE (V4L2_CID_MPEG_BASE+512)
+enum v4l2_mpeg_video_vp9_profile {
+ V4L2_MPEG_VIDEO_VP9_PROFILE_0 = 0,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_1 = 1,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_2 = 2,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_3 = 3,
+};
/* CIDs for HEVC encoding. */
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 3/3] media: mtk-vcodec: Support VP9 profile in decoder
From: Keiichi Watanabe @ 2018-06-18 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618075854.12881-1-keiichiw@chromium.org>
Add V4L2_CID_MPEG_VIDEO_VP9_PROFILE control in MediaTek decoder's
driver. MediaTek decoder only supports profile 0 for now.
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 86f0a7134365..ba986232b953 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -1400,6 +1400,11 @@ int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_ctx *ctx)
V4L2_CID_MIN_BUFFERS_FOR_CAPTURE,
0, 32, 1, 1);
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
+ v4l2_ctrl_new_std_menu(&ctx->ctrl_hdl,
+ &mtk_vcodec_dec_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_VP9_PROFILE,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_0,
+ 0, V4L2_MPEG_VIDEO_VP9_PROFILE_0);
if (ctx->ctrl_hdl.error) {
mtk_v4l2_err("Adding control failed %d",
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH 4.16 178/279] spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Greg Kroah-Hartman @ 2018-06-18 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618080608.851973560@linuxfoundation.org>
4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Herring <robh@kernel.org>
[ Upstream commit bc519d9574618e47a0c788000fb78da95e18d953 ]
The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
DT change which breaks compatibility with older kernels. The AUX irqchip
was already rejected for upstream[1] and the DT change would break
working systems if the DTB is updated to a newer one. The latter issue
was brought to my attention by Alex Graf.
The root cause however is a bug in the shared handler. Shared handlers
must check that interrupts are actually enabled before servicing the
interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.
[1] https://patchwork.kernel.org/patch/9781221/
Cc: Alexander Graf <agraf@suse.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list at broadcom.com
Cc: linux-spi at vger.kernel.org
Cc: linux-rpi-kernel at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/spi/spi-bcm2835aux.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -184,6 +184,11 @@ static irqreturn_t bcm2835aux_spi_interr
struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
irqreturn_t ret = IRQ_NONE;
+ /* IRQ may be shared, so return if our interrupts are disabled */
+ if (!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_CNTL1) &
+ (BCM2835_AUX_SPI_CNTL1_TXEMPTY | BCM2835_AUX_SPI_CNTL1_IDLE)))
+ return ret;
+
/* check if we have data to read */
while (bs->rx_len &&
(!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_STAT) &
^ permalink raw reply
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Stefan Agner @ 2018-06-18 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074320.GS3438@phenom.ffwll.local>
On 18.06.2018 09:43, Daniel Vetter wrote:
> On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:
>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>> >>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>> >>>> <leonard.crestez@nxp.com> wrote:
>> >
>> >>>>> The FBDEV driver uses the same name and both can't be registered at the
>> >>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>> >>>>
>> >>>> Stefan sent the same patch a few days ago:
>> >>>
>> >>> In that thread there is a proposal for removing the old fbdev/mxsfb
>> >>> driver entirely.
>> >>>
>> >>> That would break old DTBs, isn't this generally considered bad? Also,
>> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>> >>>
>> >>> What my series does is make both drivers work with the same kernel
>> >>> image and turns the choice into a board-level dtb decision. Supporting
>> >>> everything at once seems desirable to me and it allows for a very
>> >>> smooth upgrade path.
>> >>
>> >> Having two drivers in the kernel with different set of bugs is always bad.
>> >>
>> >>> The old driver could be removed later, after all users are converted.
>> >>
>> >> Both drivers were in for long enough already. And let's be realistic,
>> >> how many MX23/MX28 users of old DTs with new kernels are there who
>> >> cannot update the DT as well ?
>> >
>> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>> > bindings are also used by 3rd-party boards for imx6/7:
>> > * imx6sx-nitrogen6sx
>> > * imx6ul-geam
>> > * imx6ul-isiot
>> > * imx6ul-opos6uldev
>> > * imx6ul-pico-hobbit
>> > * imx6ul-tx6ul
>> > * imx7d-nitrogen7
>>
>> Er, yes, a handful of boards which could be updated :)
>>
>> > Converting everything might be quite a bit of work, and explicitly
>> > supporting old bindings is also work.
>>
>> Does adding support for old bindings justify the effort invested ? I
>> doubt so, it only adds more code to maintain.
>>
>> > It is very confusing that there is a whole set of displays for imx6/7
>> > which are supported by upstream but only with a non-default config.
>> > While it is extremely common in the embedded field to have custom
>> > configs the default one in the kernel should try to "just work".
>> >
>> > Couldn't this patch series be considered a bugfix? It was also
>> > surprisingly small.
>>
>> I think it's just a workaround which allows you to postpone the real
>> fix, and I don't like that.
>
> Yeah agreed, imo the proper fix here would be to either update the dts for
> the affected boards and/or make mxsfb accept the old dt bindings for
> backwards compat. Artificially extending the life of the fbdev drivers
> seems silly.
We shouldn't have merged a DRM driver with a driver name which conflicts
with an existing driver... If anything, this is artificially shortening
the lifetime of the fbdev driver :-)
Again, I am ok with removing the driver. I just think it is silly to do
it just because of the conflicting driver name.
Maybe Sascha, original author of the mxs fbdev driver has an opinion on
this?
--
Stefan
^ permalink raw reply
* [PATCH 4.16 222/279] perf cs-etm: Support unknown_thread in cs_etm_auxtrace
From: Greg Kroah-Hartman @ 2018-06-18 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618080608.851973560@linuxfoundation.org>
4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leo Yan <leo.yan@linaro.org>
[ Upstream commit 46d53620044f7b574c0f3216f8b4f2ce3559ce31 ]
CoreSight doesn't allocate thread structure for unknown_thread in ETM
auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in a segmentation fault when
thread__find_addr_map() accesses the thread handler.
This commit creates a new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info. This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1525924920-4381-1-git-send-email-leo.yan at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/util/cs-etm.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -212,6 +212,7 @@ static void cs_etm__free(struct perf_ses
for (i = 0; i < aux->num_cpu; i++)
zfree(&aux->metadata[i]);
+ thread__zput(aux->unknown_thread);
zfree(&aux->metadata);
zfree(&aux);
}
@@ -980,6 +981,23 @@ int cs_etm__process_auxtrace_info(union
etm->auxtrace.free = cs_etm__free;
session->auxtrace = &etm->auxtrace;
+ etm->unknown_thread = thread__new(999999999, 999999999);
+ if (!etm->unknown_thread)
+ goto err_free_queues;
+
+ /*
+ * Initialize list node so that at thread__zput() we can avoid
+ * segmentation fault at list_del_init().
+ */
+ INIT_LIST_HEAD(&etm->unknown_thread->node);
+
+ err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+ if (err)
+ goto err_delete_thread;
+
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -994,16 +1012,18 @@ int cs_etm__process_auxtrace_info(union
err = cs_etm__synth_events(etm, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
err = auxtrace_queues__process_index(&etm->queues, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
etm->data_queued = etm->queues.populated;
return 0;
+err_delete_thread:
+ thread__zput(etm->unknown_thread);
err_free_queues:
auxtrace_queues__free(&etm->queues);
session->auxtrace = NULL;
^ permalink raw reply
* [PATCH 4.14 116/189] spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Greg Kroah-Hartman @ 2018-06-18 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618081209.254234434@linuxfoundation.org>
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Herring <robh@kernel.org>
[ Upstream commit bc519d9574618e47a0c788000fb78da95e18d953 ]
The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
DT change which breaks compatibility with older kernels. The AUX irqchip
was already rejected for upstream[1] and the DT change would break
working systems if the DTB is updated to a newer one. The latter issue
was brought to my attention by Alex Graf.
The root cause however is a bug in the shared handler. Shared handlers
must check that interrupts are actually enabled before servicing the
interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.
[1] https://patchwork.kernel.org/patch/9781221/
Cc: Alexander Graf <agraf@suse.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list at broadcom.com
Cc: linux-spi at vger.kernel.org
Cc: linux-rpi-kernel at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/spi/spi-bcm2835aux.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -184,6 +184,11 @@ static irqreturn_t bcm2835aux_spi_interr
struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
irqreturn_t ret = IRQ_NONE;
+ /* IRQ may be shared, so return if our interrupts are disabled */
+ if (!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_CNTL1) &
+ (BCM2835_AUX_SPI_CNTL1_TXEMPTY | BCM2835_AUX_SPI_CNTL1_IDLE)))
+ return ret;
+
/* check if we have data to read */
while (bs->rx_len &&
(!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_STAT) &
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Leonard Crestez @ 2018-06-18 8:15 UTC (permalink / raw)
To: linux-arm-kernel
The following sensors are on I2C3 on the baseboard:
* isil,isl29023 light sensor
* fsl,mag3110 magnetometer
* fsl,mma8451 accelerometer
Added under i2cmux/i2c at 1 because they're not otherwise accessible.
These are all supported by iio with following configs:
* CONFIG_SENSORS_ISL29018
* CONFIG_MAG3110
* CONFIG_MMA8452
Tested with raw reads from iio sysfs.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
Changes since v1:
* adjusted node names (Fabio)
Link: https://lkml.org/lkml/2018/6/7/970
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 0e28e36ddbb2..a59a0fd1eb02 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -153,10 +153,31 @@
compatible = "maxim,max7310";
reg = <0x34>;
gpio-controller;
#gpio-cells = <2>;
};
+
+ light-sensor at 44 {
+ compatible = "isil,isl29023";
+ reg = <0x44>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ magnetometer at e {
+ compatible = "fsl,mag3110";
+ reg = <0x0e>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <29 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ accelerometer at 1c {
+ compatible = "fsl,mma8451";
+ reg = <0x1c>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
+ };
};
};
};
&ipu1_csi0_from_ipu1_csi0_mux {
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/2] ARM: imx_v6_v7_defconfig: Enable imx6qdl-sabreauto sensors
From: Leonard Crestez @ 2018-06-18 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1be8dc197f842d3be31a15315594a25c8ad8f298.1529309235.git.leonard.crestez@nxp.com>
CONFIG_SENSORS_ISL29018 supports isil,il29023 light sensor
CONFIG_MMA8452 supports fsl,mma8451 accelerometer
CONFIG_MAG3110 for fsl,mag3110 is already enabled
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
Changes since v1:
* Added "ARM:" prefix in title (Fabio)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f70507ab91ee..a647cbb0e59f 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -372,12 +372,14 @@ CONFIG_MXS_DMA=y
CONFIG_STAGING=y
CONFIG_STAGING_MEDIA=y
CONFIG_VIDEO_IMX_MEDIA=y
CONFIG_COMMON_CLK_PWM=y
CONFIG_IIO=y
+CONFIG_MMA8452=y
CONFIG_IMX7D_ADC=y
CONFIG_VF610_ADC=y
+CONFIG_SENSORS_ISL29018=y
CONFIG_MAG3110=y
CONFIG_MPL3115=y
CONFIG_PWM=y
CONFIG_PWM_FSL_FTM=y
CONFIG_PWM_IMX=y
--
2.17.1
^ 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