* [PATCH v3 11/14] ACPI: irq: introduce interrupt producer
From: Hanjun Guo @ 2016-12-02 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04573e29-6222-24f0-82f4-381367ee8bf0@gmail.com>
Hi Aleksey,
On 2016/12/1 19:12, Aleksey Makarov wrote:
>
> Hi Hanjun,
>
> On 10/25/2016 09:09 PM, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> In ACPI 6.1 spec, section 19.6.62, Interrupt Resource Descriptor Macro,
>
> [ ... ]
>
>> ---
>> drivers/acpi/gsi.c | 10 ++++--
>> drivers/acpi/resource.c | 85
>> ++++++++++++++++++++++++++++++++++---------------
>> include/acpi/acpi_bus.h | 1 +
>> 3 files changed, 68 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
>> index ee9e0f2..29ee547 100644
>> --- a/drivers/acpi/gsi.c
>> +++ b/drivers/acpi/gsi.c
>> @@ -55,13 +55,19 @@ int acpi_register_gsi(struct device *dev, u32 gsi,
>> int trigger,
>> int polarity)
>> {
>> struct irq_fwspec fwspec;
>> + struct acpi_device *adev = dev ? to_acpi_device(dev) : NULL;
>
> Why are you sure dev is always an acpi device?
> Look for example at drivers/acpi/pci_irq.c:377 where this function
> is called for a PCI device
Good catch, but I will drop this patch and use Agustin's one [1].
[1]: https://mail-archive.com/linux-kernel at vger.kernel.org/msg1283116.html
Thanks
Hanjun
^ permalink raw reply
* [Linaro-acpi] [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Tomasz Nowicki @ 2016-12-02 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDm8Zp_kAqVvSd0po9S3j2rSXxtUJ1M33dW7gLZzvueweQ@mail.gmail.com>
On 02.12.2016 07:42, Duc Dang wrote:
> On Thu, Dec 1, 2016 at 9:50 PM, Jon Masters <jcm@redhat.com> wrote:
>> On 11/30/2016 07:28 PM, Bjorn Helgaas wrote:
>>
>>> I'm hoping to end up with something like this:
>>> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/ecam&id=51ad4df79a9b7f2a66b346a46b21a785a2937469
>>
>> The following build warnings happen using your branch on RHELSA7.3:
>>
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> THUNDER_PEM_QUIRK(2, 0), /* off-chip devices */
>> ^
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[44].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[44].cfgres.end?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[45].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[45].cfgres.end?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[46].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[46].cfgres.end?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[47].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[47].cfgres.end?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[48].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[48].cfgres.end?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[49].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:101:2: warning: (near initialization for ?mcfg_quirks[49].cfgres.end?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> THUNDER_PEM_QUIRK(2, 1), /* off-chip devices */
>> ^
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[50].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[50].cfgres.end?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[51].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[51].cfgres.end?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[52].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[52].cfgres.end?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[53].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[53].cfgres.end?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[54].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[54].cfgres.end?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[55].cfgres.start?) [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: left shift count >= width of type [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: initializer element is not a constant expression [enabled by default]
>> drivers/acpi/pci_mcfg.c:102:2: warning: (near initialization for ?mcfg_quirks[55].cfgres.end?) [enabled by default]
>
> I saw this too. It can be fixed by changes below:
>
> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> index 7319188..3d7c5cc 100644
> --- a/drivers/acpi/pci_mcfg.c
> +++ b/drivers/acpi/pci_mcfg.c
> @@ -98,16 +98,16 @@ struct mcfg_fixup {
> { "CAVIUM", "THUNDERX", rev, seg, MCFG_BUS_ANY, \
> &pci_thunder_ecam_ops }
> /* SoC pass1.x */
> - THUNDER_PEM_QUIRK(2, 0), /* off-chip devices */
> - THUNDER_PEM_QUIRK(2, 1), /* off-chip devices */
> - THUNDER_ECAM_QUIRK(2, 0),
> - THUNDER_ECAM_QUIRK(2, 1),
> - THUNDER_ECAM_QUIRK(2, 2),
> - THUNDER_ECAM_QUIRK(2, 3),
> - THUNDER_ECAM_QUIRK(2, 10),
> - THUNDER_ECAM_QUIRK(2, 11),
> - THUNDER_ECAM_QUIRK(2, 12),
> - THUNDER_ECAM_QUIRK(2, 13),
> + THUNDER_PEM_QUIRK(2, 0UL), /* off-chip devices */
> + THUNDER_PEM_QUIRK(2, 1UL), /* off-chip devices */
> + THUNDER_ECAM_QUIRK(2, 0UL),
> + THUNDER_ECAM_QUIRK(2, 1UL),
> + THUNDER_ECAM_QUIRK(2, 2UL),
> + THUNDER_ECAM_QUIRK(2, 3UL),
> + THUNDER_ECAM_QUIRK(2, 10UL),
> + THUNDER_ECAM_QUIRK(2, 11UL),
> + THUNDER_ECAM_QUIRK(2, 12UL),
> + THUNDER_ECAM_QUIRK(2, 13UL),
>
The UL suffix is needed for *THUNDER_PEM_QUIRK* only. THUNDER_ECAM_QUIRK
is fine.
- THUNDER_PEM_QUIRK(2, 0), /* off-chip devices */
- THUNDER_PEM_QUIRK(2, 1), /* off-chip devices */
+ THUNDER_PEM_QUIRK(2, 0UL), /* off-chip devices */
+ THUNDER_PEM_QUIRK(2, 1UL), /* off-chip devices */
Tomasz
^ permalink raw reply
* [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support
From: Maciej Bielski @ 2016-12-02 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480637999-4320-1-git-send-email-scott.branden@broadcom.com>
Hello,
Recently we have announced our effort on that:
https://lkml.org/lkml/2016/11/17/49
For now we have a working solution for hotplug and we are performing
code cleanup to push the patches soon.
BR,
On 02/12/2016 01:19, Scott Branden wrote:
> This patchset is sent for comment to add memory hotplug support for ARM64
> based platforms. It follows hotplug code added for other architectures
> in the linux kernel.
>
> I tried testing the memory hotplug feature following documentation from
> Documentation/memory-hotplug.txt. I don't think it is working as expected
> - see below:
>
> To add memory to the system I did the following:
> echo 0x400000000 > /sys/devices/system/memory/probe
>
> The memory is displayed as system ram:
> cat /proc/iomem:
> 74000000-77ffffff : System RAM
> 74080000-748dffff : Kernel code
> 74950000-749d2fff : Kernel data
> 400000000-43fffffff : System RAM
>
> But does not seem to be added to the kernel memory.
> /proc/meminfo did not change.
>
> What else needs to be done so the memory is added to the kernel memory
> pool for normal allocation?
>
> Scott Branden (2):
> arm64: memory-hotplug: Add MEMORY_HOTPLUG, MEMORY_HOTREMOVE,
> MEMORY_PROBE
> arm64: defconfig: enable MEMORY_HOTPLUG config options
>
> arch/arm64/Kconfig | 10 ++++++++++
> arch/arm64/configs/defconfig | 3 +++
> arch/arm64/mm/init.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 55 insertions(+)
>
--
Maciej Bielski
^ permalink raw reply
* [PATCH 2/2] arm64: xen: Split architecture-specific headers from 32bit ARM
From: Marc Zyngier @ 2016-12-02 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1612011412120.2781@sstabellini-ThinkPad-X260>
On 01/12/16 22:17, Stefano Stabellini wrote:
> On Thu, 1 Dec 2016, Marc Zyngier wrote:
>> ARM and arm64 Xen ports share a number of headers, leading to
>> packaging issues when these headers needs to be exported, as it
>> breaks the reasonable requirement that an architecture port
>> is standalone.
>>
>> Solve the issue by copying the 5 header files over the arch
>> barrier.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>
> I might be unhappy about making life more difficult for people building
> out of tree modules (not really, but I can pretend), but copying the
> headers over is not a solution. I really don't want two copies of them.
>
> What does "standalone" mean in this context? What is the failure exactly?
Standalone means exactly that. You don't need any include file from
another architecture, and arch/arm64/include/* together with include/*
should be enough to build any odd piece of out of tree code, like on any
other architecture. For example, here's an extract from Wookey's
(internal) report trying to build the *cough* mali driver *cough*:
$ sudo make -C /usr/src/linux-headers-4.8.0-1-arm64
M=/usr/src/midgard-0.r2p0/ EXTRA_CFLAGS="-I
/usr/src/linux-headers-4.8.0-1-common/include/ -Wall -Werror
-DCONFIG_MALI_MIDGARD=m -DCONFIG_MALI_BACKEND=gpu" CONFIG_MALI_MIDGARD=m
CONFIG_MALI_BACKEND=gpu modules
make: Entering directory '/usr/src/linux-headers-4.8.0-1-arm64'
CC [M] /usr/src/midgard-0.r2p0//mali_kbase_device.o
In file included from
/usr/src/linux-headers-4.8.0-1-common/arch/arm64/include/asm/sysreg.h:25:0,
from
/usr/src/linux-headers-4.8.0-1-common/arch/arm64/include/asm/cputype.h:94,
from
/usr/src/linux-headers-4.8.0-1-common/arch/arm64/include/asm/cachetype.h:19,
from
/usr/src/linux-headers-4.8.0-1-common/arch/arm64/include/asm/cache.h:19,
from
/usr/src/linux-headers-4.8.0-1-common/include/linux/cache.h:5,
from
/usr/src/linux-headers-4.8.0-1-common/include/linux/printk.h:8,
from
/usr/src/linux-headers-4.8.0-1-common/include/linux/kernel.h:13,
from
/usr/src/linux-headers-4.8.0-1-common/include/linux/list.h:8,
from
/usr/src/linux-headers-4.8.0-1-common/include/linux/wait.h:6,
from
/usr/src/linux-headers-4.8.0-1-common/include/linux/fs.h:5,
from
/usr/src/linux-headers-4.8.0-1-common/include/linux/debugfs.h:18,
from
/usr/src/midgard-0.r2p0//mali_kbase_device.c:24:/usr/src/linux-headers-4.8.0-1-common/arch/arm64/include/asm/opcodes.h:5:43:
fatal error: ../../arm/include/asm/opcodes.h: No such file or directory
compilation terminated.
As I said in the cover letter, I don't care much for out of tree code
either. However, there is strictly no need for arm64 to break the
reasonable expectation that header files can be packaged using the
method that "just works" on all other architectures. Distributions do
depend on this, and breaking these expectations is not something that I
find acceptable. YMMV.
> If moving the headers out of arch/arm is necessary, then please move
> them to another shared directory, maybe include/xen/arm.
Works for me, I'll respin this patch.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 5/5] ARM: dts: imx6qdl-sabrelite: remove hardcoded LVDS bus format
From: Gary Bisson @ 2016-12-02 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202090843.22613-1-gary.bisson@boundarydevices.com>
The bus format is therefore retrieved from the connected panel
information.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 1f9076e..452ae47 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -525,8 +525,6 @@
status = "okay";
lvds-channel at 0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
status = "okay";
port at 4 {
--
2.9.3
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: imx6qdl-nitrogen6x: remove hardcoded LVDS bus format
From: Gary Bisson @ 2016-12-02 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202090843.22613-1-gary.bisson@boundarydevices.com>
The bus format is therefore retrieved from the connected panel
information.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index 26d0604..16b14bd 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -579,8 +579,6 @@
status = "okay";
lvds-channel at 0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
status = "okay";
port at 4 {
--
2.9.3
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: imx6qdl-nitrogen6_som2: remove hardcoded LVDS bus format
From: Gary Bisson @ 2016-12-02 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202090843.22613-1-gary.bisson@boundarydevices.com>
The bus format is therefore retrieved from the connected panel
information.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
index d80f21a..0521986 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
@@ -640,8 +640,6 @@
status = "okay";
lvds-channel at 0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
status = "okay";
port at 4 {
--
2.9.3
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: imx6qdl-nitrogen6_max: remove hardcoded LVDS bus format
From: Gary Bisson @ 2016-12-02 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202090843.22613-1-gary.bisson@boundarydevices.com>
The bus format is therefore retrieved from the connected panel
information.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
index 34887a1..c43c36e 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
@@ -739,8 +739,6 @@
status = "okay";
lvds-channel at 0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
status = "okay";
port at 4 {
@@ -753,8 +751,6 @@
};
lvds-channel at 1 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
status = "okay";
port at 4 {
--
2.9.3
^ permalink raw reply related
* [PATCH 1/5] ARM: dts: imx6qdl-nit6xlite: remove hardcoded LVDS bus format
From: Gary Bisson @ 2016-12-02 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202090843.22613-1-gary.bisson@boundarydevices.com>
The bus format is therefore retrieved from the connected panel
information.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi b/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
index 63acd54..a784593 100644
--- a/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
@@ -515,8 +515,6 @@
status = "okay";
lvds-channel at 0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
status = "okay";
port at 4 {
--
2.9.3
^ permalink raw reply related
* [PATCH 0/5] ARM: dts: boundary: remove hardcoded LVDS bus format
From: Gary Bisson @ 2016-12-02 9:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This series removes the hardcoded bus format for the LVDS display nodes of our
platforms.
The reason is that our latest 7" display uses a 24-bit interface and therefore
can't work properly without this series.
https://patchwork.kernel.org/patch/9458053/
Regards,
Gary
Gary Bisson (5):
ARM: dts: imx6qdl-nit6xlite: remove hardcoded LVDS bus format
ARM: dts: imx6qdl-nitrogen6_max: remove hardcoded LVDS bus format
ARM: dts: imx6qdl-nitrogen6_som2: remove hardcoded LVDS bus format
ARM: dts: imx6qdl-nitrogen6x: remove hardcoded LVDS bus format
ARM: dts: imx6qdl-sabrelite: remove hardcoded LVDS bus format
arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi | 2 --
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ----
arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 2 --
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 2 --
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 2 --
5 files changed, 12 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 06/12] usb: dwc3: omap: Replace the extcon API
From: Felipe Balbi @ 2016-12-02 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58412848.5070209@samsung.com>
Hi,
Chanwoo Choi <cw00.choi@samsung.com> writes:
> Hi Felipe,
>
> On 2016? 11? 30? 19:36, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Chanwoo Choi <cw00.choi@samsung.com> writes:
>>> This patch uses the resource-managed extcon API for extcon_register_notifier()
>>> and replaces the deprecated extcon API as following:
>>> - extcon_get_cable_state_() -> extcon_get_state()
>>>
>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>
>> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>>
>
> Thanks for your review.
>
> Each patch has no any dependency among patches.
> So, If possible, could you pick the patch6/8/9/10/11/12 on your tree?
my tree is closed for v4.10, I can pick it up for v4.11
--
balbi
^ permalink raw reply
* XHCI controller does not detect USB key insertion
From: Felipe Balbi @ 2016-12-02 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <584134D9.5000404@free.fr>
Hi,
Mason <slash.tmp@free.fr> writes:
> Hello everyone,
>
> I'm trying out a SoC with a brand new USB controller, which is (supposedly)
> a standard XHCI controller. In theory, I would just need to build the right
> driver, and everything would auto-magically work, right?
perhaps, but there might be needed initialization of other resources
like PHYs and stuff like that.
> So my defconfig contains:
>
> CONFIG_USB=y
> CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_PLATFORM=y
> CONFIG_USB_STORAGE=y
> CONFIG_USB_STORAGE_DEBUG=y
>
>
> And my device tree contains:
>
> usb3 at 30040000 {
> compatible = "generic-xhci";
> reg = <0x30040000 0x10000>;
> interrupts = <SIGMA_HWIRQ 67 IRQ_TYPE_LEVEL_HIGH>;
> };
>
>
> The boot messages I get:
>
> [ 1.618214] xhci-hcd 30040000.usb3: xHCI Host Controller
> [ 1.623611] xhci-hcd 30040000.usb3: new USB bus registered, assigned bus number 1
> [ 1.631181] reset function is xhci_plat_setup
> [ 1.635588] xhci_plat_setup from usb_add_hcd
> [ 1.640109] xhci-hcd 30040000.usb3: hcc params 0x30003192 hci version 0x100 quirks 0x00010010
> [ 1.648766] xhci-hcd 30040000.usb3: irq 22, io mem 0x30040000
> [ 1.654572] xhci_plat_start from usb_add_hcd
> [ 1.659086] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [ 1.665943] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [ 1.673228] usb usb1: Product: xHCI Host Controller
> [ 1.678154] usb usb1: Manufacturer: Linux 4.7.0-rc6 xhci-hcd
> [ 1.683865] usb usb1: SerialNumber: 30040000.usb3
> [ 1.689391] hub 1-0:1.0: USB hub found
> [ 1.693227] hub 1-0:1.0: 1 port detected
> [ 1.697601] xhci-hcd 30040000.usb3: xHCI Host Controller
> [ 1.702983] xhci-hcd 30040000.usb3: new USB bus registered, assigned bus number 2
> [ 1.710545] reset function is xhci_plat_setup
> [ 1.714950] xhci_plat_setup from usb_add_hcd
> [ 1.719265] xhci_plat_start from usb_add_hcd
> [ 1.723653] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
> [ 1.731956] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
> [ 1.738814] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [ 1.746100] usb usb2: Product: xHCI Host Controller
> [ 1.751025] usb usb2: Manufacturer: Linux 4.7.0-rc6 xhci-hcd
> [ 1.756736] usb usb2: SerialNumber: 30040000.usb3
> [ 1.762195] hub 2-0:1.0: USB hub found
> [ 1.766027] hub 2-0:1.0: 1 port detected
> [ 1.770661] usbcore: registered new interface driver usb-storage
> [ 1.784584] usbcore: registered new interface driver usbhid
> [ 1.790213] usbhid: USB HID core driver
>
> Which looks encouraging, right?
yes
> Am I supposed to have had USB interrupts at that point?
nope, unless a device was already plugged in.
> # cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> 20: 609 365 393 356 GIC-0 29 Edge twd
> 21: 101 0 0 0 INTC 1 Level serial
> 22: 0 0 0 0 INTC 67 Level xhci-hcd:usb1
> IPI0: 0 0 0 0 CPU wakeup interrupts
> IPI1: 0 0 0 0 Timer broadcast interrupts
> IPI2: 794 620 1223 1045 Rescheduling interrupts
> IPI3: 0 37 37 37 Function call interrupts
> IPI4: 0 0 0 0 CPU stop interrupts
> IPI5: 0 0 0 0 IRQ work interrupts
> IPI6: 0 0 0 0 completion interrupts
> Err: 0
>
>
> When I insert a USB key, nothing happens :-(
>
> # lsusb -v
> Bus 001 Device 001: ID 1d6b:0002
> Bus 002 Device 001: ID 1d6b:0003
>
>
> I'd like to hear suggestions about what I can tweak to fix the problem.
go to your documentation and see if you have initialized
everything. Which SoC is this?
--
balbi
^ permalink raw reply
* XHCI controller does not detect USB key insertion
From: Mason @ 2016-12-02 8:46 UTC (permalink / raw)
To: linux-arm-kernel
Hello everyone,
I'm trying out a SoC with a brand new USB controller, which is (supposedly)
a standard XHCI controller. In theory, I would just need to build the right
driver, and everything would auto-magically work, right?
So my defconfig contains:
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PLATFORM=y
CONFIG_USB_STORAGE=y
CONFIG_USB_STORAGE_DEBUG=y
And my device tree contains:
usb3 at 30040000 {
compatible = "generic-xhci";
reg = <0x30040000 0x10000>;
interrupts = <SIGMA_HWIRQ 67 IRQ_TYPE_LEVEL_HIGH>;
};
The boot messages I get:
[ 1.618214] xhci-hcd 30040000.usb3: xHCI Host Controller
[ 1.623611] xhci-hcd 30040000.usb3: new USB bus registered, assigned bus number 1
[ 1.631181] reset function is xhci_plat_setup
[ 1.635588] xhci_plat_setup from usb_add_hcd
[ 1.640109] xhci-hcd 30040000.usb3: hcc params 0x30003192 hci version 0x100 quirks 0x00010010
[ 1.648766] xhci-hcd 30040000.usb3: irq 22, io mem 0x30040000
[ 1.654572] xhci_plat_start from usb_add_hcd
[ 1.659086] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 1.665943] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.673228] usb usb1: Product: xHCI Host Controller
[ 1.678154] usb usb1: Manufacturer: Linux 4.7.0-rc6 xhci-hcd
[ 1.683865] usb usb1: SerialNumber: 30040000.usb3
[ 1.689391] hub 1-0:1.0: USB hub found
[ 1.693227] hub 1-0:1.0: 1 port detected
[ 1.697601] xhci-hcd 30040000.usb3: xHCI Host Controller
[ 1.702983] xhci-hcd 30040000.usb3: new USB bus registered, assigned bus number 2
[ 1.710545] reset function is xhci_plat_setup
[ 1.714950] xhci_plat_setup from usb_add_hcd
[ 1.719265] xhci_plat_start from usb_add_hcd
[ 1.723653] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 1.731956] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[ 1.738814] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.746100] usb usb2: Product: xHCI Host Controller
[ 1.751025] usb usb2: Manufacturer: Linux 4.7.0-rc6 xhci-hcd
[ 1.756736] usb usb2: SerialNumber: 30040000.usb3
[ 1.762195] hub 2-0:1.0: USB hub found
[ 1.766027] hub 2-0:1.0: 1 port detected
[ 1.770661] usbcore: registered new interface driver usb-storage
[ 1.784584] usbcore: registered new interface driver usbhid
[ 1.790213] usbhid: USB HID core driver
Which looks encouraging, right?
Am I supposed to have had USB interrupts at that point?
# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
20: 609 365 393 356 GIC-0 29 Edge twd
21: 101 0 0 0 INTC 1 Level serial
22: 0 0 0 0 INTC 67 Level xhci-hcd:usb1
IPI0: 0 0 0 0 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 794 620 1223 1045 Rescheduling interrupts
IPI3: 0 37 37 37 Function call interrupts
IPI4: 0 0 0 0 CPU stop interrupts
IPI5: 0 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 completion interrupts
Err: 0
When I insert a USB key, nothing happens :-(
# lsusb -v
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0003
I'd like to hear suggestions about what I can tweak to fix the problem.
Regards.
^ permalink raw reply
* [PATCH 1/3] Documentation: dt: Add TI SCI clock driver
From: Tero Kristo @ 2016-12-02 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0fe81866-8bfd-f3a7-d808-9cb23841f504@ti.com>
On 21/11/16 10:14, Tero Kristo wrote:
> On 18/11/16 19:20, Rob Herring wrote:
>> On Mon, Oct 31, 2016 at 7:50 AM, Tero Kristo <t-kristo@ti.com> wrote:
>>> On 30/10/16 22:41, Rob Herring wrote:
>>>>
>>>> On Fri, Oct 21, 2016 at 03:45:59PM +0300, Tero Kristo wrote:
>>>>>
>>>>> Add a clock implementation, TI SCI clock, that will hook to the common
>>>>> clock framework, and allow each clock to be controlled via TI SCI
>>>>> protocol.
>>>>>
>>>>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>>>>> ---
>>>>> .../devicetree/bindings/clock/ti,sci-clk.txt | 37
>>>>> ++++++++++++++++++++++
>>>>> MAINTAINERS | 1 +
>>>>> 2 files changed, 38 insertions(+)
>>>>> create mode 100644
>>>>> Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>>> b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>>> new file mode 100644
>>>>> index 0000000..bfc3ca4
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>>>>> @@ -0,0 +1,37 @@
>>>>> +Texas Instruments TI-SCI Clocks
>>>>> +===============================
>>>>> +
>>>>> +All clocks on Texas Instruments' SoCs that contain a System
>>>>> Controller,
>>>>> +are only controlled by this entity. Communication between a host
>>>>> processor
>>>>> +running an OS and the System Controller happens through a protocol
>>>>> known
>>>>> +as TI-SCI[1]. This clock implementation plugs into the common clock
>>>>> +framework and makes use of the TI-SCI protocol on clock API requests.
>>>>> +
>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>> +
>>>>> +Required properties:
>>>>> +-------------------
>>>>> +- compatible: Must be "ti,k2g-sci-clk"
>>>>> +- #clock-cells: Shall be 2.
>>>>> + In clock consumers, this cell represents the device ID and clock ID
>>>>> + exposed by the PM firmware. The assignments can be found in the
>>>>> header
>>>>> + files <dt-bindings/genpd/<soc>.h> (which covers the device IDs) and
>>>>> + <dt-bindings/clock/<soc>.h> (which covers the clock IDs), where
>>>>> <soc>
>>>>> + is the SoC involved, for example 'k2g'.
>>>>> +
>>>>> +Examples:
>>>>> +--------
>>>>> +
>>>>> +pmmc: pmmc {
>>>>> + compatible = "ti,k2g-sci";
>>>>> +
>>>>> + k2g_clks: k2g_clks {
>>>>
>>>>
>>>> Use "clocks" for node name instead.
>>>>
>>>>> + compatible = "ti,k2g-sci-clk";
>>>>
>>>>
>>>> I'm starting to think all these child nodes for SCI are pointless. Is
>>>> there any reason why the parent node can't be the clock provider (along
>>>> with all the other providers it acks as)?
>>>
>>>
>>> I believe the only reason to keep them separate is to have kernel
>>> side of
>>> things modular. If we have separate nodes, the drivers can be probed
>>> separately.
>>>
>>> If not, we need to build one huge blob with all the features in it,
>>> so the
>>> main driver can probe everything in one go, with annoying back-and-forth
>>> callbacks in place (assuming we still want to keep stuff somehow
>>> modular.)
>>
>> Since when is DT the only way to create a device? The main driver can
>> create devices for all the sub-functions like clocks. This is the same
>> as MFDs which have been done both ways.
>
> Yes obviously this can be done, my main point was that it will require
> building some sort of infra within the driver to handle this. With
> separate nodes, none of this is going to be needed. Also, we will lose
> any kind of configurability via DT if we don't have separate nodes; now
> we can select the available clocks / genpds via the compatible string of
> the clocks/genpd nodes themselves (this isn't clearly evident as of now
> as we only support a grand total of one device, which is k2g-evm.)
> Otherwise we need to probe against the main node and add a separate
> compatible string for every device, and carry this information to the
> sibling devices also somehow. It is just so much simpler if we can just
> keep separate nodes for them.
>
> Also, plenty of things are doing this kind of stuff already in
> DT/kernel, having a parent node in place and sub-functions added
> separately for ease of use, with apparently no visible point for having
> the nodes within the DT.
Rob, any response on this one? I see you have acked the reset part of
the bindings which is doing pretty much the same thing as the clock part
is doing here, namely adding child node under the main SCI node. Is it
okay to do this same for other parts of the TI SCI?
-Tero
^ permalink raw reply
* [PATCH 1/2] Add crypto driver support for some MediaTek chips
From: Corentin Labbe @ 2016-12-02 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480649205-52695-2-git-send-email-ryder.lee@mediatek.com>
Hello
I have some minor comment inline
On Fri, Dec 02, 2016 at 11:26:44AM +0800, Ryder Lee wrote:
> This adds support for the MediaTek hardware accelerator on
> mt7623/mt2701/mt8521p SoC.
>
> This driver currently implement:
> - SHA1 and SHA2 family(HMAC) hash alogrithms.
> - AES block cipher in CBC/ECB mode with 128/196/256 bits keys.
I see also a PRNG but is seems not really used.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> drivers/crypto/Kconfig | 17 +
> drivers/crypto/Makefile | 1 +
> drivers/crypto/mediatek/Makefile | 2 +
> drivers/crypto/mediatek/mtk-aes.c | 734 +++++++++++++++++
> drivers/crypto/mediatek/mtk-platform.c | 575 +++++++++++++
> drivers/crypto/mediatek/mtk-platform.h | 230 ++++++
> drivers/crypto/mediatek/mtk-regs.h | 194 +++++
> drivers/crypto/mediatek/mtk-sha.c | 1384 ++++++++++++++++++++++++++++++++
> 8 files changed, 3137 insertions(+)
> create mode 100644 drivers/crypto/mediatek/Makefile
> create mode 100644 drivers/crypto/mediatek/mtk-aes.c
> create mode 100644 drivers/crypto/mediatek/mtk-platform.c
> create mode 100644 drivers/crypto/mediatek/mtk-platform.h
> create mode 100644 drivers/crypto/mediatek/mtk-regs.h
> create mode 100644 drivers/crypto/mediatek/mtk-sha.c
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 4d2b81f..5d9c803 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -553,6 +553,23 @@ config CRYPTO_DEV_ROCKCHIP
> This driver interfaces with the hardware crypto accelerator.
> Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
>
> +config CRYPTO_DEV_MEDIATEK
> + tristate "MediaTek's Cryptographic Engine driver"
> + depends on ARM && ARCH_MEDIATEK
> + select NEON
> + select KERNEL_MODE_NEON
> + select ARM_CRYPTO
> + select CRYPTO_AES
> + select CRYPTO_BLKCIPHER
> + select CRYPTO_SHA1_ARM_NEON
> + select CRYPTO_SHA256_ARM
> + select CRYPTO_SHA512_ARM
> + select CRYPTO_HMAC
Why do you select accelerated algos ?
Adding COMPILE_TEST could be helpfull also.
[...]
> +
> +#include <linux/dma-mapping.h>
> +#include <linux/scatterlist.h>
> +#include <crypto/scatterwalk.h>
> +#include <crypto/algapi.h>
> +#include <crypto/aes.h>
> +#include "mtk-platform.h"
> +#include "mtk-regs.h"
> +
Sort headers in alphabetical order
[...]
> +
> + mtk_aes_unregister_algs();
> + mtk_aes_record_free(cryp);
> +}
> +EXPORT_SYMBOL(mtk_cipher_alg_release);
Why not EXPORT_SYMBOL_GPL ?
Furthermore do you really need it to be exported ?
[...]
> +
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/clk.h>
> +#include <linux/platform_device.h>
> +#include "mtk-platform.h"
> +#include "mtk-regs.h"
> +
Sort headers in alphabetical order
[...]
> +
> +static void mtk_prng_reseed(struct mtk_cryp *cryp)
> +{
> + /* 8 words to seed the PRNG to provide IVs */
> + void __iomem *base = cryp->base;
> + const u32 prng_key[8] = {0x48c24cfd, 0x6c07f742,
> + 0xaee75681, 0x0f27c239,
> + 0x79947198, 0xe2991275,
> + 0x21ac3c7c, 0xd008c4b4};
Why do you seed with thoses constant ?
[...]
> +
> +static int mtk_accelerator_init(struct mtk_cryp *cryp)
> +{
> + int i, err;
> +
> + /* Initialize advanced interrupt controller(AIC) */
> + for (i = 0; i < 5; i++) {
I see this 5 for interrupt away, so perhaps a define could be used
[...]
here
> + for (i = 0; i < 5; i++) {
> + cryp->irq[i] = platform_get_irq(pdev, i);
> + if (cryp->irq[i] < 0) {
> + dev_err(cryp->dev, "no IRQ:%d resource info\n", i);
> + return -ENXIO;
> + }
> + }
[...]
> +#ifndef __MTK_PLATFORM_H_
> +#define __MTK_PLATFORM_H_
> +
> +#include <linux/crypto.h>
> +#include <crypto/internal/hash.h>
> +#include <linux/interrupt.h>
Sort headers in alphabetical order
[...]
> +#define MTK_DESC_FIRST BIT(23)
> +#define MTK_DESC_BUF_LEN(x) ((x) & 0x1ffff)
> +#define MTK_DESC_CT_LEN(x) (((x) & 0xff) << 24)
> +
> +#define WORD(x) ((x) >> 2)
dangerous and ambigous define
[...]
> +
> +#include <linux/dma-mapping.h>
> +#include <linux/scatterlist.h>
> +#include <linux/crypto.h>
> +#include <crypto/scatterwalk.h>
> +#include <crypto/algapi.h>
> +#include <crypto/sha.h>
> +#include <crypto/internal/hash.h>
Sort headers in alphabetical order
[...]
Generally more function comment could be helpfull.
Regards
^ permalink raw reply
* [PATCHv4 00/15] clk: ti: add support for hwmod clocks
From: Tero Kristo @ 2016-12-02 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028233750.GQ16026@codeaurora.org>
On 29/10/16 02:37, Stephen Boyd wrote:
> On 10/28, Tero Kristo wrote:
>> Eventually that should happen. However, we have plenty of legacy
>> code still in place which depend on clk_get functionality within
>> kernel. The major contributing factor is the hwmod codebase, for
>> which we have plans to:
>>
>> - get this clock driver merged
>> - implement a new interconnect driver for OMAP family SoCs
>> - interconnect driver will use DT handles for fetching clocks,
>> rather than clock aliases
>> - reset handling will be implemented as part of the interconnect
>> driver somehow (no prototype / clear plans for that as of yet)
>> - all the hwmod stuff can be dropped
>>
>> The clock alias handling is still needed as a transition phase until
>> all the above is done, then we can start dropping them. Basically
>> anything that is using omap_hwmod depends on the clock aliases right
>> now.
>
> Ok, sounds good. Thanks.
Stephen, any final comments on this series? I guess its too late to push
for 4.10, but I would like to get this merged early for 4.11 window.
-Tero
^ permalink raw reply
* [PATCH] trace: extend trace_clock to support arch_arm clock counter
From: Srinivas Ramana @ 2016-12-02 8:14 UTC (permalink / raw)
To: linux-arm-kernel
Extend the trace_clock to support the arch timer cycle
counter so that we can get the monotonic cycle count
in the traces. This will help in correlating the traces with the
timestamps/events in other subsystems in the soc which share
this common counter for driving their timers.
Signed-off-by: Srinivas Ramana <sramana@codeaurora.org>
---
arch/arm64/include/asm/Kbuild | 1 -
arch/arm64/include/asm/trace_clock.h | 20 ++++++++++++++++++++
2 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/include/asm/trace_clock.h
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 44e1d7f10add..c943e9c9823a 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -41,7 +41,6 @@ generic-y += swab.h
generic-y += switch_to.h
generic-y += termbits.h
generic-y += termios.h
-generic-y += trace_clock.h
generic-y += types.h
generic-y += unaligned.h
generic-y += user.h
diff --git a/arch/arm64/include/asm/trace_clock.h b/arch/arm64/include/asm/trace_clock.h
new file mode 100644
index 000000000000..dc9af640738d
--- /dev/null
+++ b/arch/arm64/include/asm/trace_clock.h
@@ -0,0 +1,20 @@
+#ifndef _ASM_ARM64_TRACE_CLOCK_H
+#define _ASM_ARM64_TRACE_CLOCK_H
+
+#include <linux/compiler.h>
+#include <linux/types.h>
+#include <asm/arch_timer.h>
+
+/*
+ * trace_clock_arm64_count_vct(): A clock that is just the cycle counter.
+ * Unlike the other clocks, this is not in nanoseconds.
+ */
+static inline u64 notrace trace_clock_arm64_count_vct(void)
+{
+ return arch_counter_get_cntvct();
+}
+
+# define ARCH_TRACE_CLOCKS \
+ { trace_clock_arm64_count_vct, "arm64-count-vct", 0 },
+
+#endif /* _ASM_ARM64_TRACE_CLOCK_H */
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v4 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Jon Masters @ 2016-12-02 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDkyCrheZLNG3_9BVgvGBW8WrA-VPWOCezz3U-g+nt5W9w@mail.gmail.com>
You're welcome.
(Unrelated) Note that I added a console= and earlycon in my test (and got the baud rate wrong for the console but nevermind...was ssh'd in after the earlycon output I cared about anyway) because of some other cleanup work for the SPCR parsing that apparently is still not quite fixed for upstream, or rather, there is a need to match on the 32-bit access required for the UART and that isn't happening so it's not getting setup. Folks are tracking that one and fixing it though.
--
Computer Architect | Sent from my 64-bit #ARM Powered phone
> On Dec 2, 2016, at 02:37, Duc Dang <dhdang@apm.com> wrote:
>
>> On Thu, Dec 1, 2016 at 11:12 PM, Jon Masters <jcm@redhat.com> wrote:
>>> On 12/01/2016 09:27 PM, Duc Dang wrote:
>>> PCIe controllers in X-Gene SoCs is not ECAM compliant: software
>>> needs to configure additional controller's register to address
>>> device at bus:dev:function.
>>>
>>> The quirk will discover controller MMIO register space and configure
>>> controller registers to select and address the target secondary device.
>>>
>>> The quirk will only be applied for X-Gene PCIe MCFG table with
>>> OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>>>
>>> Signed-off-by: Duc Dang <dhdang@apm.com>
>>
>> So far I've tested this on an HPE ProLiant m400 (Moonshot) cartridge
>> and will test it on some other reference platforms soon. Bootlog for
>> the m400 attached in case Bjorn wants to see the output. Here's
>> what I see in /proc/iomem btw on that platform:
>>
>> # cat /proc/iomem
>> 10520000-10523fff : APMC0D18:00
>> 10520000-10523fff : APMC0D18:00
>> 10524000-10527fff : APMC0D17:00
>> 10540000-1054a0ff : APMC0D01:00
>> 10546000-10546fff : APMC0D50:00
>> 1054a000-1054a00f : APMC0D12:03
>> 1054a000-1054a00f : APMC0D12:02
>> 1054a000-1054a00f : APMC0D12:01
>> 1054a000-1054a00f : APMC0D12:00
>> 17000000-17000fff : APMC0D01:00
>> 17001000-17001fff : APMC0D01:00
>> 17001000-170013ff : APMC0D15:00
>> 17001000-170013ff : APMC0D15:00
>> 1701c000-1701cfff : APMC0D14:00
>> 1a800000-1a800fff : APMC0D0D:00
>> 1a800000-1a800fff : APMC0D0D:00
>> 1c000200-1c0002ff : APMC0D06:00
>> 1c021000-1c0210ff : APMC0D08:00
>> 1c021000-1c02101f : serial
>> 1c024000-1c024fff : APMC0D07:00
>> 1f230000-1f230fff : APMC0D0D:00
>> 1f230000-1f230fff : APMC0D0D:00
>> 1f23d000-1f23dfff : APMC0D0D:00
>> 1f23d000-1f23dfff : APMC0D0D:00
>> 1f23e000-1f23efff : APMC0D0D:00
>> 1f23e000-1f23efff : APMC0D0D:00
>> 1f2a0000-1f31ffff : APMC0D06:00
>> 1f500000-1f50ffff : PCI Bus 0000:00
>> 1f500000-1f50ffff : PNP0A08:00
>> 78800000-78800fff : APMC0D13:00
>> 78800000-78800fff : APMC0D12:03
>> 78800000-78800fff : APMC0D12:02
>> 78800000-78800fff : APMC0D12:01
>> 78800000-78800fff : APMC0D12:00
>> 78800000-78800fff : APMC0D11:00
>> 78800000-78800fff : APMC0D10:03
>> 78800000-78800fff : APMC0D10:02
>> 78800000-78800fff : APMC0D10:01
>> 78800000-78800fff : APMC0D10:00
>> 79000000-798fffff : APMC0D0E:00
>> 7c000000-7c1fffff : APMC0D12:00
>> 7c200000-7c3fffff : APMC0D12:01
>> 7c400000-7c5fffff : APMC0D12:02
>> 7c600000-7c7fffff : APMC0D12:03
>> 7e000000-7e000fff : APMC0D13:00
>> 7e200000-7e200fff : APMC0D10:03
>> 7e200000-7e200fff : APMC0D10:02
>> 7e200000-7e200fff : APMC0D10:01
>> 7e200000-7e200fff : APMC0D10:00
>> 7e600000-7e600fff : APMC0D11:00
>> 7e700000-7e700fff : APMC0D10:03
>> 7e700000-7e700fff : APMC0D10:02
>> 7e700000-7e700fff : APMC0D10:01
>> 7e700000-7e700fff : APMC0D10:00
>> 7e720000-7e720fff : APMC0D10:03
>> 7e720000-7e720fff : APMC0D10:02
>> 7e720000-7e720fff : APMC0D10:01
>> 7e720000-7e720fff : APMC0D10:00
>> 7e800000-7e800fff : APMC0D10:00
>> 7e840000-7e840fff : APMC0D10:01
>> 7e880000-7e880fff : APMC0D10:02
>> 7e8c0000-7e8c0fff : APMC0D10:03
>> 7e930000-7e930fff : APMC0D13:00
>> 4000000000-4001ffffff : System RAM
>> 4000080000-4000c3ffff : Kernel code
>> 4000db0000-400165ffff : Kernel data
>> 40023a0000-4ff733ffff : System RAM
>> 4ff7340000-4ff77cffff : reserved
>> 4ff77d0000-4ff79cffff : System RAM
>> 4ff79d0000-4ff7e7ffff : reserved
>> 4ff7e80000-4ff7e8ffff : System RAM
>> 4ff7e90000-4ff7efffff : reserved
>> 4ff7f10000-4ff800ffff : reserved
>> 4ff8010000-4fffffffff : System RAM
>> a020000000-a03fffffff : PCI Bus 0000:00
>> a020000000-a0201fffff : PCI Bus 0000:01
>> a020000000-a0200fffff : 0000:01:00.0
>> a020000000-a0200fffff : mlx4_core
>> a020100000-a0201fffff : 0000:01:00.0
>> a060000000-a07fffffff : PCI Bus 0000:00
>> a0d0000000-a0dfffffff : PCI ECAM
>> a110000000-a14fffffff : PCI Bus 0000:00
>> a110000000-a121ffffff : PCI Bus 0000:01
>> a110000000-a111ffffff : 0000:01:00.0
>> a110000000-a111ffffff : mlx4_core
>> a112000000-a121ffffff : 0000:01:00.0
>>
>> Adding a Tested-by for the record:
>>
>> Tested-by: Jon Masters <jcm@redhat.com>
>
> Thanks a lot for testing this, Jon.
>>
>> Jon.
>>
>> --
>> Computer Architect | Sent from my Fedora powered laptop
>>
> Regards,
> Duc Dang.
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Jon Masters @ 2016-12-02 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLND=fYXf-NOw7qm-KbDX3U3YrtAXRyQ+aj=CMcwmEaNHmpQ@mail.gmail.com>
Quick reply - sorry for top posting (it's 3am...) - I would favor keeping the existing Fixed32Memory _CRS but switching over to prefer the PNP entry as a good citizen. The trouble is that it would be unfortunate if existing distros stopped working on newer firmware and it would lead to IMO more pain than it is worth. Hopefully for this reason Bjorn will take your v4 as-is for now and let us all figure out the cleanest long term cleanup later.
--
Computer Architect | Sent from my 64-bit #ARM Powered phone
> On Dec 2, 2016, at 02:34, Duc Dang <dhdang@apm.com> wrote:
>
>> On Thu, Dec 1, 2016 at 10:31 PM, Jon Masters <jcm@redhat.com> wrote:
>> Bjorn,
>>
>> Although I think the below still applies (that we need to leave that
>> Memory32Fixed for existing deployments, and this is going to result
>> in /proc/iomem polution), I've done some more reading of your ecam
>> tree and the implementation of acpi_get_rc_resources you mentioned,
>> and in particular how the PNP0C02 devices actually get wired up.
>>
>> I would like to be able to boot upstream on existing shipping and
>> deployed machines that are in the field (not to mention our labs), but
>> there's no reason we can't *also* get APM to add a new vendor specific
>> PNP0C02 to the ACPI namespace in future firmware updates (for at least
>> their own Mustang reference boards) matching segment to CSR, as in the
>> case of the HiSi patches. That might then allow for some later
>> preference to use that for the CSR rather than getting it from the RC
>> device. Still, it would be ideal to boot on machines that are shipping
>> from HPE and others at this moment, so I am still hopeful you'll
>> at least allow the approach from Duc's v4 for now (4.10).
>
> APM X-Gene 1 and X-Gene 2 ACPI tables will absolutely have PNP0C02
> nodes (in upcoming firmware release). I hope to have a solution that
> works for both old buggy firmware and the future improved firmware. So
> I am thinking the CSR discovery will be like this:
>
> (1) Use acpi_get_rc_resources() to discover CSR resource by checking
> PNP0C02 nodes
> (2) (1) should succeed with the new firmware
> (3) If (1) fails, we can fall back to approach on v4 patch: calling
> xgene_get_csr_resource() to discover the CSR described by
> Memory32Fixed macro.
>
> How do you feel about this? The drawback is the new firmware that does
> not have the CSR space described with Memory32Fixed macro will fail on
> the distro version that uses the old quirk (that relies on this
> Memory32Fixed macro).
>
>>
>> Another nasty option for later consideration could then be having
>> the kernel fake up any missing PNP0C02 on existing machines, but
>> it would need special knowledge of the platform to generate that
>> so as to handle the problem Mark flagged earlier (segment vs
>> controller mismatch on some platforms). That could be done with a
>> DMI quirk that matched on a specific (e.g. HPE) machine. It would
>> only be needed on "broken" existing machines, and could be added
>> post-4.10 to clean this up if you really want to do that.
>
> Bjorn suggested similar approach (have a PNP quirk to fabricate a
> PNP0C02 device and decleare all the required resources there) on
> another thread. But as you said, this approach does not scale, it can
> only applicable for a specific machine (by checking DMI information to
> apply the PNP quirk).
>
>>
>> That's all very nasty...
>>
>> Jon.
>>
>>> On 12/01/2016 11:08 PM, Jon Masters wrote:
>>> Hi Bjorn, Duc, Mark,
>>>
>>> I switched my brain to the on mode and went and read some specs, and a few
>>> tables, so here's my 2 cents on this...
>>>
>>>> On 12/01/2016 06:22 PM, Duc Dang wrote:
>>>>> On Thu, Dec 1, 2016 at 3:07 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>>>>> On Thu, Dec 01, 2016 at 02:10:10PM -0800, Duc Dang wrote:
>>>
>>>>>>>> The SoC provide some number of RC bridges, each with a different base
>>>>>>>> for some mmio registers. Even if segment is legitimate in MCFG, there
>>>>>>>> is still a problem if a platform doesn't use the segment ordering
>>>>>>>> implied by the code. But the PNP0A03 _CRS does have this base address
>>>>>>>> as the first memory resource, so we could get it from there and not
>>>>>>>> have hard-coded addresses and implied ording in the quirk code.
>>>>>>>
>>>>>>> I'm confused. Doesn't the current code treat every item in PNP0A03
>>>>>>> _CRS as a window? Do you mean the first resource is handled
>>>>>>> differently somehow? The Consumer/Producer bit could allow us to do
>>>>>>> this by marking the RC MMIO space as "Consumer", but I didn't think
>>>>>>> that strategy was quite working yet.
>>>
>>> Let's see if I summarized this correctly...
>>>
>>> 1. The MMIO registers for the host bridge itself need to be described
>>> somewhere, especially if we need to find those in a quirk and poke
>>> them. Since those registers are very much part of the bridge device,
>>> it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.
>>>
>>> 2. The address space covering these registers MUST be described as a
>>> ResourceConsumer in order to avoid accidentally exposing them as
>>> available for use by downstream devices on the PCI bus.
>>>
>>> 3. The ACPI specification allows for resources of the type "Memory32Fixed".
>>> This is a macro that doesn't have the notion of a producer or consumer.
>>> HOWEVER various interpretations seem to be that this could/should
>>> default to being interpreted as a consumed region.
>>>
>>> 4. At one point, a regression was added to the kernel:
>>>
>>> 63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
>>> host bridge itself")
>>>
>>> Which lead to a series on conversations about what should happen
>>> for bridge resources (e.g. https://lkml.org/lkml/2015/3/24/962 )
>>>
>>> 5. This resulted in the following commit reverting point 4:
>>>
>>> 2c62e8492ed7 ("x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff]
>>> available on PCI bus")
>>>
>>> Which also stated that:
>>>
>>> "This solution will also ease the way to consolidate ACPI PCI host
>>> bridge common code from x86, ia64 and ARM64"
>>>
>>> End of summary.
>>>
>>> So it seems that generally there is an aversion to having bridge resources
>>> be described in this manner and you would like to require that they be
>>> described e.g. using QWordMemory with a ResourceConsumer type?
>>>
>>> BUT if we were to do that, it would break existing shipping systems since
>>> there are quirks out there that use this form to find the base CSR:
>>>
>>> if (acpi_res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
>>> fixed32 = &acpi_res->data.fixed_memory32;
>>> port->csr_base = ioremap(fixed32->address,
>>> fixed32->address_length);
>>> return AE_CTRL_TERMINATE;
>>> }
>>>
>>> That's what's shipping in at least RHEL(SA) today, and probably in other
>>> distros. So if we get vendors to take that out, existing stuff will break,
>>> which will have the downside that customers will have to choose between
>>> whether to run a given distro or be able to use upstream kernels. In
>>> that sense, to me, there are shipping platforms out there, which may well
>>> be doing the "wrong" thing, but they are deployed and they are doing it.
>>>
>>> Which makes me wonder a couple of things (I think should NOT be done):
>>>
>>> 1. What would happen if we had both. A FixedMemory32 and the same region
>>> described again using the longer form as a consumed region. I doubt
>>> that's legal, and the current code would still add the region if it
>>> saw the FixedMemory32 first when walking the tree. I don't like it,
>>> but I'm mentioning it in case that leads to some helpful thinking.
>>>
>>> 2. What would happen if we had a difference policy on arm64 for such
>>> resources. x86 has an "exception" for accessing the config space
>>> using IO port 0xCF8-0xCFF (a fairly reasonable exception!) and
>>> we can make the rules for a new platform (i.e. actually prescribe
>>> exactly what the behavior is, rather than have it not be defined).
>>> This is of course terrible in that existing BIOS vendors and so on
>>> won't necessarily know this when working on ARM ACPI later on.
>>>
>>> I don't like either of these obviously. I'm hoping there's some way we
>>> can say that this is tolerated in this one quirk (allow the use of
>>> FixedMemory32 in this case) on the grounds that the driver claims
>>> this bridge region and can be annotated to explain such.
>>>
>>> Once you let us know what you prefer, we will go and update the ARM
>>> SBBR to spell out that future platforms should not make this mistake
>>> again. We can prescribe whatever you'd like in terms of how bridge
>>> resources consumed by the bridge are exposed. I have spoken about
>>> this kind of situation within MS in the past, but they didn't have
>>> specific guidance since they don't really tolerate such quirks. I
>>> can, however, consult them before we change the SBBR as well.
>>>
>>>>>> The first resource is defined like below. It was introduced long time
>>>>>> ago to use with older version of X-Gene ECAM quirks.
>>>>>> Memory32Fixed(ReadWrite, 0x1F2B0000, 0x10000, )
>>>
>>> Indeed. And in the case of m400, it is currently this in shipping systems:
>>>
>>> Memory32Fixed (ReadWrite,
>>> 0x1F500000, // Address Base
>>> 0x00010000, // Address Length
>>> )
>>>
>>> The spec isn't clear on whether these are produced or consumed but the
>>> implication is that these are consumed resources in most cases. Not that
>>> this changes any of the above, but one can understand why it happened.
>>>
>>>>>> [ 0.822990] pci_bus 0000:00: root bus resource [mem 0x1f2b0000-0x1f2bffff]
>>>>>
>>>>> I think this is wrong. The PCI core thinks [mem 0x1f2b0000-0x1f2bffff]
>>>>> is available for use by devices on bus 0000:00, but I think you're
>>>>> saying it is consumed by the bridge itself, not forwarded down to PCI.
>>>
>>> Indeed.
>>>
>>>>> What's in your /proc/iomem? I see that your quirks do call
>>>>> devm_ioremap_resource(), which calls devm_request_mem_region()
>>>>> internally, so the driver does at least request that region, which
>>>>> should keep us from assigning it to PCI devices.
>>>
>>> I'm hoping you can grant an exception on the grounds that the quirk will
>>> keep the region from actually being used. And then somehow we document
>>> this in the driver.
>>>
>>>>> But it still isn't quite right to tell the PCI core that the region is
>>>>> available on the root bus.
>>>>
>>>> This is /proc/iomem output on my Mustang board. The 64K "PCIe CSR"
>>>> region is consumed completely.
>>>> 1f2b0000-1f2bffff : PCI Bus 0000:00
>>>> 1f2b0000-1f2bffff : PCIe CSR
>>>>
>>>> e040000000-e07fffffff : PCI Bus 0000:00
>>>> e040000000-e0401fffff : PCI Bus 0000:01
>>>> e040000000-e0400fffff : 0000:01:00.0
>>>> e040000000-e0400fffff : mlx4_core
>>>> e040100000-e0401fffff : 0000:01:00.0
>>>> e0d0000000-e0dfffffff : PCI ECAM
>>>> f000000000-ffffffffff : PCI Bus 0000:00
>>>> f000000000-f001ffffff : PCI Bus 0000:01
>>>> f000000000-f001ffffff : 0000:01:00.0
>>>> f000000000-f001ffffff : mlx4_core
>>>>
>>>> Using hard-coded resources for mmio space make the quirk rely on the
>>>> segment number passing from the firmware. Using Mark's method or
>>>> acpi_get_rc_resource can discover the mmio space and consume all of
>>>> the space, but as you mentioned, it leaves the defect that PCI core
>>>> considers the mmio space as available resource for secondary devices
>>>> although it will never allocate the mmio space to secondary devices as
>>>> the RC already reserves and consumes all of the space.
>>>
>>> Indeed. It's not clean, but perhaps we can get away with it on the
>>> grounds that there are existing systems out there and this won't
>>> be allowed to happen again in the future :)
>>>
>>> Jon.
>>>
>>
>>
>> --
>> Computer Architect | Sent from my Fedora powered laptop
^ permalink raw reply
* [RFC][PATCH] [media] atmel-isc: add the isc pipeline function
From: Songjun Wu @ 2016-12-02 8:06 UTC (permalink / raw)
To: linux-arm-kernel
Image Sensor Controller has an internal image processor.
It can convert raw format to the other formats, like
RGB565, YUV420P. A module parameter 'sensor_preferred'
is used to enable or disable the pipeline function.
Some v4l2 controls are added to tuning the image when
the pipeline function is enabled.
Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
---
drivers/media/platform/atmel/atmel-isc-regs.h | 77 ++++-
drivers/media/platform/atmel/atmel-isc.c | 460 +++++++++++++++++++++-----
2 files changed, 449 insertions(+), 88 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isc-regs.h b/drivers/media/platform/atmel/atmel-isc-regs.h
index 00c4497..7d83342 100644
--- a/drivers/media/platform/atmel/atmel-isc-regs.h
+++ b/drivers/media/platform/atmel/atmel-isc-regs.h
@@ -72,30 +72,98 @@
/* ISC White Balance Configuration Register */
#define ISC_WB_CFG 0x0000005c
+/* ISC White Balance Offset for R, GR Register */
+#define ISC_WB_O_RGR 0x00000060
+
+/* ISC White Balance Offset for B, GB Register */
+#define ISC_WB_O_BGR 0x00000064
+
+/* ISC White Balance Gain for R, GR Register */
+#define ISC_WB_G_RGR 0x00000068
+
+/* ISC White Balance Gain for B, GB Register */
+#define ISC_WB_G_BGR 0x0000006c
+
/* ISC Color Filter Array Control Register */
#define ISC_CFA_CTRL 0x00000070
/* ISC Color Filter Array Configuration Register */
#define ISC_CFA_CFG 0x00000074
+#define ISC_CFA_CFG_EITPOL BIT(4)
#define ISC_BAY_CFG_GRGR 0x0
#define ISC_BAY_CFG_RGRG 0x1
#define ISC_BAY_CFG_GBGB 0x2
#define ISC_BAY_CFG_BGBG 0x3
-#define ISC_BAY_CFG_MASK GENMASK(1, 0)
/* ISC Color Correction Control Register */
#define ISC_CC_CTRL 0x00000078
+/* ISC Color Correction RR RG Register */
+#define ISC_CC_RR_RG 0x0000007c
+
+/* ISC Color Correction RB OR Register */
+#define ISC_CC_RB_OR 0x00000080
+
+/* ISC Color Correction GR GG Register */
+#define ISC_CC_GR_GG 0x00000084
+
+/* ISC Color Correction GB OG Register */
+#define ISC_CC_GB_OG 0x00000088
+
+/* ISC Color Correction BR BG Register */
+#define ISC_CC_BR_BG 0x0000008c
+
+/* ISC Color Correction BB OB Register */
+#define ISC_CC_BB_OB 0x00000090
+
/* ISC Gamma Correction Control Register */
#define ISC_GAM_CTRL 0x00000094
+/* ISC_Gamma Correction Blue Entry Register */
+#define ISC_GAM_BENTRY 0x00000098
+
+/* ISC_Gamma Correction Green Entry Register */
+#define ISC_GAM_GENTRY 0x00000198
+
+/* ISC_Gamma Correction Green Entry Register */
+#define ISC_GAM_RENTRY 0x00000298
+
/* Color Space Conversion Control Register */
#define ISC_CSC_CTRL 0x00000398
+/* Color Space Conversion YR YG Register */
+#define ISC_CSC_YR_YG 0x0000039c
+
+/* Color Space Conversion YB OY Register */
+#define ISC_CSC_YB_OY 0x000003a0
+
+/* Color Space Conversion CBR CBG Register */
+#define ISC_CSC_CBR_CBG 0x000003a4
+
+/* Color Space Conversion CBB OCB Register */
+#define ISC_CSC_CBB_OCB 0x000003a8
+
+/* Color Space Conversion CRR CRG Register */
+#define ISC_CSC_CRR_CRG 0x000003ac
+
+/* Color Space Conversion CRB OCR Register */
+#define ISC_CSC_CRB_OCR 0x000003b0
+
/* Contrast And Brightness Control Register */
#define ISC_CBC_CTRL 0x000003b4
+/* Contrast And Brightness Configuration Register */
+#define ISC_CBC_CFG 0x000003b8
+
+/* Brightness Register */
+#define ISC_CBC_BRIGHT 0x000003bc
+#define ISC_CBC_BRIGHT_MASK GENMASK(10, 0)
+
+/* Contrast Register */
+#define ISC_CBC_CONTRAST 0x000003c0
+#define ISC_CBC_CONTRAST_MASK GENMASK(11, 0)
+
/* Subsampling 4:4:4 to 4:2:2 Control Register */
#define ISC_SUB422_CTRL 0x000003c4
@@ -159,7 +227,10 @@
/* DMA Address 0 Register */
#define ISC_DAD0 0x000003ec
-/* DMA Stride 0 Register */
-#define ISC_DST0 0x000003f0
+/* DMA Address 1 Register */
+#define ISC_DAD1 0x000003f4
+
+/* DMA Address 2 Register */
+#define ISC_DAD2 0x000003fc
#endif
diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
index fa68fe9..b06cbf6 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -36,7 +36,9 @@
#include <linux/regmap.h>
#include <linux/videodev2.h>
+#include <media/v4l2-ctrls.h>
#include <media/v4l2-device.h>
+#include <media/v4l2-event.h>
#include <media/v4l2-image-sizes.h>
#include <media/v4l2-ioctl.h>
#include <media/v4l2-of.h>
@@ -89,10 +91,12 @@ struct isc_subdev_entity {
* struct isc_format - ISC media bus format information
* @fourcc: Fourcc code for this format
* @mbus_code: V4L2 media bus format code.
- * @bpp: Bytes per pixel (when stored in memory)
+ * @bpp: Bits per pixel (when stored in memory)
* @reg_bps: reg value for bits per sample
* (when transferred over a bus)
- * @support: Indicates format supported by subdev
+ * @pipeline: pipeline switch
+ * @sd_support: Subdev supports this format
+ * @isc_support: ISC can convert raw format to this format
*/
struct isc_format {
u32 fourcc;
@@ -100,11 +104,19 @@ struct isc_format {
u8 bpp;
u32 reg_bps;
+ u32 reg_bay_cfg;
u32 reg_rlp_mode;
u32 reg_dcfg_imode;
u32 reg_dctrl_dview;
- bool support;
+ u32 pipeline;
+
+ bool sd_support;
+ bool isc_support;
+};
+
+struct isc_ctrls {
+ struct v4l2_ctrl_handler handler;
};
#define ISC_PIPE_LINE_NODE_NUM 11
@@ -131,6 +143,9 @@ struct isc_device {
struct isc_format **user_formats;
unsigned int num_user_formats;
const struct isc_format *current_fmt;
+ const struct isc_format *raw_fmt;
+
+ struct isc_ctrls ctrls;
struct mutex lock;
@@ -140,51 +155,134 @@ struct isc_device {
struct list_head subdev_entities;
};
+#define RAW_FMT_INDEX_START 0
+#define RAW_FMT_INDEX_END 11
+#define ISC_FMT_INDEX_START 12
+#define ISC_FMT_INDEX_END 14
+
static struct isc_format isc_formats[] = {
- { V4L2_PIX_FMT_SBGGR8, MEDIA_BUS_FMT_SBGGR8_1X8,
- 1, ISC_PFE_CFG0_BPS_EIGHT, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, false },
- { V4L2_PIX_FMT_SGBRG8, MEDIA_BUS_FMT_SGBRG8_1X8,
- 1, ISC_PFE_CFG0_BPS_EIGHT, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, false },
- { V4L2_PIX_FMT_SGRBG8, MEDIA_BUS_FMT_SGRBG8_1X8,
- 1, ISC_PFE_CFG0_BPS_EIGHT, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, false },
- { V4L2_PIX_FMT_SRGGB8, MEDIA_BUS_FMT_SRGGB8_1X8,
- 1, ISC_PFE_CFG0_BPS_EIGHT, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, false },
-
- { V4L2_PIX_FMT_SBGGR10, MEDIA_BUS_FMT_SBGGR10_1X10,
- 2, ISC_PFG_CFG0_BPS_TEN, ISC_RLP_CFG_MODE_DAT10,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, false },
- { V4L2_PIX_FMT_SGBRG10, MEDIA_BUS_FMT_SGBRG10_1X10,
- 2, ISC_PFG_CFG0_BPS_TEN, ISC_RLP_CFG_MODE_DAT10,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, false },
- { V4L2_PIX_FMT_SGRBG10, MEDIA_BUS_FMT_SGRBG10_1X10,
- 2, ISC_PFG_CFG0_BPS_TEN, ISC_RLP_CFG_MODE_DAT10,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, false },
- { V4L2_PIX_FMT_SRGGB10, MEDIA_BUS_FMT_SRGGB10_1X10,
- 2, ISC_PFG_CFG0_BPS_TEN, ISC_RLP_CFG_MODE_DAT10,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, false },
-
- { V4L2_PIX_FMT_SBGGR12, MEDIA_BUS_FMT_SBGGR12_1X12,
- 2, ISC_PFG_CFG0_BPS_TWELVE, ISC_RLP_CFG_MODE_DAT12,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, false },
- { V4L2_PIX_FMT_SGBRG12, MEDIA_BUS_FMT_SGBRG12_1X12,
- 2, ISC_PFG_CFG0_BPS_TWELVE, ISC_RLP_CFG_MODE_DAT12,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, false },
- { V4L2_PIX_FMT_SGRBG12, MEDIA_BUS_FMT_SGRBG12_1X12,
- 2, ISC_PFG_CFG0_BPS_TWELVE, ISC_RLP_CFG_MODE_DAT12,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, false },
- { V4L2_PIX_FMT_SRGGB12, MEDIA_BUS_FMT_SRGGB12_1X12,
- 2, ISC_PFG_CFG0_BPS_TWELVE, ISC_RLP_CFG_MODE_DAT12,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, false },
-
- { V4L2_PIX_FMT_YUYV, MEDIA_BUS_FMT_YUYV8_2X8,
- 2, ISC_PFE_CFG0_BPS_EIGHT, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, false },
+ { V4L2_PIX_FMT_SBGGR8, MEDIA_BUS_FMT_SBGGR8_1X8, 8,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DAT8,
+ ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+ { V4L2_PIX_FMT_SGBRG8, MEDIA_BUS_FMT_SGBRG8_1X8, 8,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_GBGB, ISC_RLP_CFG_MODE_DAT8,
+ ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+ { V4L2_PIX_FMT_SGRBG8, MEDIA_BUS_FMT_SGRBG8_1X8, 8,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_GRGR, ISC_RLP_CFG_MODE_DAT8,
+ ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+ { V4L2_PIX_FMT_SRGGB8, MEDIA_BUS_FMT_SRGGB8_1X8, 8,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_RGRG, ISC_RLP_CFG_MODE_DAT8,
+ ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+
+ { V4L2_PIX_FMT_SBGGR10, MEDIA_BUS_FMT_SBGGR10_1X10, 16,
+ ISC_PFG_CFG0_BPS_TEN, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DAT10,
+ ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+ { V4L2_PIX_FMT_SGBRG10, MEDIA_BUS_FMT_SGBRG10_1X10, 16,
+ ISC_PFG_CFG0_BPS_TEN, ISC_BAY_CFG_GBGB, ISC_RLP_CFG_MODE_DAT10,
+ ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+ { V4L2_PIX_FMT_SGRBG10, MEDIA_BUS_FMT_SGRBG10_1X10, 16,
+ ISC_PFG_CFG0_BPS_TEN, ISC_BAY_CFG_GRGR, ISC_RLP_CFG_MODE_DAT10,
+ ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+ { V4L2_PIX_FMT_SRGGB10, MEDIA_BUS_FMT_SRGGB10_1X10, 16,
+ ISC_PFG_CFG0_BPS_TEN, ISC_BAY_CFG_RGRG, ISC_RLP_CFG_MODE_DAT10,
+ ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+
+ { V4L2_PIX_FMT_SBGGR12, MEDIA_BUS_FMT_SBGGR12_1X12, 16,
+ ISC_PFG_CFG0_BPS_TWELVE, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DAT12,
+ ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+ { V4L2_PIX_FMT_SGBRG12, MEDIA_BUS_FMT_SGBRG12_1X12, 16,
+ ISC_PFG_CFG0_BPS_TWELVE, ISC_BAY_CFG_GBGB, ISC_RLP_CFG_MODE_DAT12,
+ ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+ { V4L2_PIX_FMT_SGRBG12, MEDIA_BUS_FMT_SGRBG12_1X12, 16,
+ ISC_PFG_CFG0_BPS_TWELVE, ISC_BAY_CFG_GRGR, ISC_RLP_CFG_MODE_DAT12,
+ ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+ { V4L2_PIX_FMT_SRGGB12, MEDIA_BUS_FMT_SRGGB12_1X12, 16,
+ ISC_PFG_CFG0_BPS_TWELVE, ISC_BAY_CFG_RGRG, ISC_RLP_CFG_MODE_DAT12,
+ ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
+
+ { V4L2_PIX_FMT_YUV420, 0x0, 12,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_YYCC,
+ ISC_DCFG_IMODE_YC420P | ISC_DCFG_YMBSIZE_BEATS8 |
+ ISC_DCFG_CMBSIZE_BEATS8, ISC_DCTRL_DVIEW_PLANAR, 0x7fb,
+ false, false },
+ { V4L2_PIX_FMT_YUV422P, 0x0, 16,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_YYCC,
+ ISC_DCFG_IMODE_YC422P | ISC_DCFG_YMBSIZE_BEATS8 |
+ ISC_DCFG_CMBSIZE_BEATS8, ISC_DCTRL_DVIEW_PLANAR, 0x3fb,
+ false, false },
+ { V4L2_PIX_FMT_RGB565, MEDIA_BUS_FMT_RGB565_2X8_LE, 16,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_RGB565,
+ ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x7b,
+ false, false },
+
+ { V4L2_PIX_FMT_YUYV, MEDIA_BUS_FMT_YUYV8_2X8, 16,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DAT8,
+ ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
+ false, false },
};
+#define GAMMA_MAX 3
+#define GAMMA_ENTRIES 64
+
+/* Gamma table with gamma 1/2.2 */
+static const u32 isc_gamma_table[GAMMA_MAX][GAMMA_ENTRIES] = {
+ /* 0 --> gamma 1/1.8 */
+ { 0x65, 0x66002F, 0x950025, 0xBB0020, 0xDB001D, 0xF8001A,
+ 0x1130018, 0x12B0017, 0x1420016, 0x1580014, 0x16D0013, 0x1810012,
+ 0x1940012, 0x1A60012, 0x1B80011, 0x1C90010, 0x1DA0010, 0x1EA000F,
+ 0x1FA000F, 0x209000F, 0x218000F, 0x227000E, 0x235000E, 0x243000E,
+ 0x251000E, 0x25F000D, 0x26C000D, 0x279000D, 0x286000D, 0x293000C,
+ 0x2A0000C, 0x2AC000C, 0x2B8000C, 0x2C4000C, 0x2D0000B, 0x2DC000B,
+ 0x2E7000B, 0x2F3000B, 0x2FE000B, 0x309000B, 0x314000B, 0x31F000A,
+ 0x32A000A, 0x334000B, 0x33F000A, 0x349000A, 0x354000A, 0x35E000A,
+ 0x368000A, 0x372000A, 0x37C000A, 0x386000A, 0x3900009, 0x399000A,
+ 0x3A30009, 0x3AD0009, 0x3B60009, 0x3BF000A, 0x3C90009, 0x3D20009,
+ 0x3DB0009, 0x3E40009, 0x3ED0009, 0x3F60009 },
+
+ /* 1 --> gamma 1/2 */
+ { 0x7F, 0x800034, 0xB50028, 0xDE0021, 0x100001E, 0x11E001B,
+ 0x1390019, 0x1520017, 0x16A0015, 0x1800014, 0x1940014, 0x1A80013,
+ 0x1BB0012, 0x1CD0011, 0x1DF0010, 0x1EF0010, 0x200000F, 0x20F000F,
+ 0x21F000E, 0x22D000F, 0x23C000E, 0x24A000E, 0x258000D, 0x265000D,
+ 0x273000C, 0x27F000D, 0x28C000C, 0x299000C, 0x2A5000C, 0x2B1000B,
+ 0x2BC000C, 0x2C8000B, 0x2D3000C, 0x2DF000B, 0x2EA000A, 0x2F5000A,
+ 0x2FF000B, 0x30A000A, 0x314000B, 0x31F000A, 0x329000A, 0x333000A,
+ 0x33D0009, 0x3470009, 0x350000A, 0x35A0009, 0x363000A, 0x36D0009,
+ 0x3760009, 0x37F0009, 0x3880009, 0x3910009, 0x39A0009, 0x3A30009,
+ 0x3AC0008, 0x3B40009, 0x3BD0008, 0x3C60008, 0x3CE0008, 0x3D60009,
+ 0x3DF0008, 0x3E70008, 0x3EF0008, 0x3F70008 },
+
+ /* 2 --> gamma 1/2.2 */
+ { 0x99, 0x9B0038, 0xD4002A, 0xFF0023, 0x122001F, 0x141001B,
+ 0x15D0019, 0x1760017, 0x18E0015, 0x1A30015, 0x1B80013, 0x1CC0012,
+ 0x1DE0011, 0x1F00010, 0x2010010, 0x2110010, 0x221000F, 0x230000F,
+ 0x23F000E, 0x24D000E, 0x25B000D, 0x269000C, 0x276000C, 0x283000C,
+ 0x28F000C, 0x29B000C, 0x2A7000C, 0x2B3000B, 0x2BF000B, 0x2CA000B,
+ 0x2D5000B, 0x2E0000A, 0x2EB000A, 0x2F5000A, 0x2FF000A, 0x30A000A,
+ 0x3140009, 0x31E0009, 0x327000A, 0x3310009, 0x33A0009, 0x3440009,
+ 0x34D0009, 0x3560009, 0x35F0009, 0x3680008, 0x3710008, 0x3790009,
+ 0x3820008, 0x38A0008, 0x3930008, 0x39B0008, 0x3A30008, 0x3AB0008,
+ 0x3B30008, 0x3BB0008, 0x3C30008, 0x3CB0007, 0x3D20008, 0x3DA0007,
+ 0x3E20007, 0x3E90007, 0x3F00008, 0x3F80007 },
+};
+
+static unsigned int sensor_preferred = 1;
+module_param(sensor_preferred, uint, 0644);
+MODULE_PARM_DESC(sensor_preferred,
+ "Sensor is preferred to output the specified format (1-on 0-off), default 1");
+
static int isc_clk_enable(struct clk_hw *hw)
{
struct isc_clk *isc_clk = to_isc_clk(hw);
@@ -447,27 +545,95 @@ static int isc_buffer_prepare(struct vb2_buffer *vb)
return 0;
}
-static inline void isc_start_dma(struct regmap *regmap,
- struct isc_buffer *frm, u32 dview)
+static inline bool sensor_is_preferred(const struct isc_format *isc_fmt)
+{
+ if ((sensor_preferred && isc_fmt->sd_support) ||
+ !isc_fmt->isc_support)
+ return true;
+ else
+ return false;
+}
+
+static inline void isc_start_dma(struct isc_device *isc)
{
- dma_addr_t addr;
+ struct regmap *regmap = isc->regmap;
+ struct v4l2_pix_format *pixfmt = &isc->fmt.fmt.pix;
+ u32 sizeimage = pixfmt->sizeimage;
+ u32 dctrl_dview;
+ dma_addr_t addr0;
+
+ addr0 = vb2_dma_contig_plane_dma_addr(&isc->cur_frm->vb.vb2_buf, 0);
+ regmap_write(regmap, ISC_DAD0, addr0);
+
+ switch (pixfmt->pixelformat) {
+ case V4L2_PIX_FMT_YUV420:
+ regmap_write(regmap, ISC_DAD1, addr0 + (sizeimage*2)/3);
+ regmap_write(regmap, ISC_DAD2, addr0 + (sizeimage*5)/6);
+ break;
+ case V4L2_PIX_FMT_YUV422P:
+ regmap_write(regmap, ISC_DAD1, addr0 + sizeimage/2);
+ regmap_write(regmap, ISC_DAD2, addr0 + (sizeimage*3)/4);
+ break;
+ }
- addr = vb2_dma_contig_plane_dma_addr(&frm->vb.vb2_buf, 0);
+ if (sensor_is_preferred(isc->current_fmt))
+ dctrl_dview = ISC_DCTRL_DVIEW_PACKED;
+ else
+ dctrl_dview = isc->current_fmt->reg_dctrl_dview;
- regmap_write(regmap, ISC_DCTRL, dview | ISC_DCTRL_IE_IS);
- regmap_write(regmap, ISC_DAD0, addr);
+ regmap_write(regmap, ISC_DCTRL, dctrl_dview | ISC_DCTRL_IE_IS);
regmap_write(regmap, ISC_CTRLEN, ISC_CTRL_CAPTURE);
}
static void isc_set_pipeline(struct isc_device *isc, u32 pipeline)
{
- u32 val;
+ struct regmap *regmap = isc->regmap;
+ u32 val, bay_cfg;
unsigned int i;
+ /* WB-->CFA-->CC-->GAM-->CSC-->CBC-->SUB422-->SUB420 */
for (i = 0; i < ISC_PIPE_LINE_NODE_NUM; i++) {
val = pipeline & BIT(i) ? 1 : 0;
regmap_field_write(isc->pipeline[i], val);
}
+
+ if (!pipeline)
+ return;
+
+ bay_cfg = isc->raw_fmt->reg_bay_cfg;
+
+ regmap_write(regmap, ISC_WB_CFG, bay_cfg);
+ regmap_write(regmap, ISC_CFA_CFG, bay_cfg | ISC_CFA_CFG_EITPOL);
+
+ /* Convert RGB to YUV */
+ regmap_write(regmap, ISC_CSC_YR_YG, 0x42 | (0x81 << 16));
+ regmap_write(regmap, ISC_CSC_YB_OY, 0x19 | (0x10 << 16));
+ regmap_write(regmap, ISC_CSC_CBR_CBG, 0xFDA | (0xFB6 << 16));
+ regmap_write(regmap, ISC_CSC_CBB_OCB, 0x70 | (0x80 << 16));
+ regmap_write(regmap, ISC_CSC_CRR_CRG, 0x70 | (0xFA2 << 16));
+ regmap_write(regmap, ISC_CSC_CRB_OCR, 0xFEE | (0x80 << 16));
+}
+
+static inline void isc_get_param(const struct isc_format *fmt,
+ u32 *rlp_mode, u32 *dcfg_imode)
+{
+ switch (fmt->fourcc) {
+ case V4L2_PIX_FMT_SBGGR10:
+ case V4L2_PIX_FMT_SGBRG10:
+ case V4L2_PIX_FMT_SGRBG10:
+ case V4L2_PIX_FMT_SRGGB10:
+ case V4L2_PIX_FMT_SBGGR12:
+ case V4L2_PIX_FMT_SGBRG12:
+ case V4L2_PIX_FMT_SGRBG12:
+ case V4L2_PIX_FMT_SRGGB12:
+ *rlp_mode = fmt->reg_rlp_mode;
+ *dcfg_imode = fmt->reg_dcfg_imode;
+ break;
+ default:
+ *rlp_mode = ISC_RLP_CFG_MODE_DAT8;
+ *dcfg_imode = ISC_DCFG_IMODE_PACKED8;
+ break;
+ }
}
static int isc_configure(struct isc_device *isc)
@@ -475,33 +641,42 @@ static int isc_configure(struct isc_device *isc)
struct regmap *regmap = isc->regmap;
const struct isc_format *current_fmt = isc->current_fmt;
struct isc_subdev_entity *subdev = isc->current_subdev;
- u32 val, mask;
- int counter = 10;
+ u32 pfe_cfg0, rlp_mode, dcfg_imode, sr, mask, pipeline;
+ int counter = 100;
+
+ if (sensor_is_preferred(current_fmt)) {
+ pfe_cfg0 = current_fmt->reg_bps;
+ pipeline = 0x0;
+ isc_get_param(current_fmt, &rlp_mode, &dcfg_imode);
+ } else {
+ pfe_cfg0 = isc->raw_fmt->reg_bps;
+ pipeline = current_fmt->pipeline;
+ rlp_mode = current_fmt->reg_rlp_mode;
+ dcfg_imode = current_fmt->reg_dcfg_imode;
+ }
- val = current_fmt->reg_bps | subdev->pfe_cfg0 |
- ISC_PFE_CFG0_MODE_PROGRESSIVE;
+ pfe_cfg0 |= subdev->pfe_cfg0 | ISC_PFE_CFG0_MODE_PROGRESSIVE;
mask = ISC_PFE_CFG0_BPS_MASK | ISC_PFE_CFG0_HPOL_LOW |
ISC_PFE_CFG0_VPOL_LOW | ISC_PFE_CFG0_PPOL_LOW |
ISC_PFE_CFG0_MODE_MASK;
- regmap_update_bits(regmap, ISC_PFE_CFG0, mask, val);
+ regmap_update_bits(regmap, ISC_PFE_CFG0, mask, pfe_cfg0);
regmap_update_bits(regmap, ISC_RLP_CFG, ISC_RLP_CFG_MODE_MASK,
- current_fmt->reg_rlp_mode);
+ rlp_mode);
- regmap_update_bits(regmap, ISC_DCFG, ISC_DCFG_IMODE_MASK,
- current_fmt->reg_dcfg_imode);
+ regmap_update_bits(regmap, ISC_DCFG, ISC_DCFG_IMODE_MASK, dcfg_imode);
- /* Disable the pipeline */
- isc_set_pipeline(isc, 0x0);
+ /* Set the pipeline */
+ isc_set_pipeline(isc, pipeline);
/* Update profile */
regmap_write(regmap, ISC_CTRLEN, ISC_CTRL_UPPRO);
- regmap_read(regmap, ISC_CTRLSR, &val);
- while ((val & ISC_CTRL_UPPRO) && counter--) {
+ regmap_read(regmap, ISC_CTRLSR, &sr);
+ while ((sr & ISC_CTRL_UPPRO) && counter--) {
usleep_range(1000, 2000);
- regmap_read(regmap, ISC_CTRLSR, &val);
+ regmap_read(regmap, ISC_CTRLSR, &sr);
}
if (counter < 0)
@@ -551,7 +726,7 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
struct isc_buffer, list);
list_del(&isc->cur_frm->list);
- isc_start_dma(regmap, isc->cur_frm, isc->current_fmt->reg_dctrl_dview);
+ isc_start_dma(isc);
spin_unlock_irqrestore(&isc->dma_queue_lock, flags);
@@ -620,8 +795,7 @@ static void isc_buffer_queue(struct vb2_buffer *vb)
if (!isc->cur_frm && list_empty(&isc->dma_queue) &&
vb2_is_streaming(vb->vb2_queue)) {
isc->cur_frm = buf;
- isc_start_dma(isc->regmap, isc->cur_frm,
- isc->current_fmt->reg_dctrl_dview);
+ isc_start_dma(isc);
} else
list_add_tail(&buf->list, &isc->dma_queue);
spin_unlock_irqrestore(&isc->dma_queue_lock, flags);
@@ -691,13 +865,14 @@ static struct isc_format *find_format_by_fourcc(struct isc_device *isc,
}
static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
- struct isc_format **current_fmt)
+ struct isc_format **current_fmt, u32 *code)
{
struct isc_format *isc_fmt;
struct v4l2_pix_format *pixfmt = &f->fmt.pix;
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_TRY,
};
+ u32 mbus_code;
int ret;
if (f->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
@@ -717,7 +892,12 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
if (pixfmt->height > ISC_MAX_SUPPORT_HEIGHT)
pixfmt->height = ISC_MAX_SUPPORT_HEIGHT;
- v4l2_fill_mbus_format(&format.format, pixfmt, isc_fmt->mbus_code);
+ if (sensor_is_preferred(isc_fmt))
+ mbus_code = isc_fmt->mbus_code;
+ else
+ mbus_code = isc->raw_fmt->mbus_code;
+
+ v4l2_fill_mbus_format(&format.format, pixfmt, mbus_code);
ret = v4l2_subdev_call(isc->current_subdev->sd, pad, set_fmt,
isc->current_subdev->config, &format);
if (ret < 0)
@@ -726,12 +906,15 @@ static int isc_try_fmt(struct isc_device *isc, struct v4l2_format *f,
v4l2_fill_pix_format(pixfmt, &format.format);
pixfmt->field = V4L2_FIELD_NONE;
- pixfmt->bytesperline = pixfmt->width * isc_fmt->bpp;
+ pixfmt->bytesperline = (pixfmt->width * isc_fmt->bpp) >> 3;
pixfmt->sizeimage = pixfmt->bytesperline * pixfmt->height;
if (current_fmt)
*current_fmt = isc_fmt;
+ if (code)
+ *code = mbus_code;
+
return 0;
}
@@ -741,14 +924,14 @@ static int isc_set_fmt(struct isc_device *isc, struct v4l2_format *f)
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
struct isc_format *current_fmt;
+ u32 mbus_code;
int ret;
- ret = isc_try_fmt(isc, f, ¤t_fmt);
+ ret = isc_try_fmt(isc, f, ¤t_fmt, &mbus_code);
if (ret)
return ret;
- v4l2_fill_mbus_format(&format.format, &f->fmt.pix,
- current_fmt->mbus_code);
+ v4l2_fill_mbus_format(&format.format, &f->fmt.pix, mbus_code);
ret = v4l2_subdev_call(isc->current_subdev->sd, pad,
set_fmt, NULL, &format);
if (ret < 0)
@@ -776,7 +959,7 @@ static int isc_try_fmt_vid_cap(struct file *file, void *priv,
{
struct isc_device *isc = video_drvdata(file);
- return isc_try_fmt(isc, f, NULL);
+ return isc_try_fmt(isc, f, NULL, NULL);
}
static int isc_enum_input(struct file *file, void *priv,
@@ -842,7 +1025,10 @@ static int isc_enum_framesizes(struct file *file, void *fh,
if (!isc_fmt)
return -EINVAL;
- fse.code = isc_fmt->mbus_code;
+ if (sensor_is_preferred(isc_fmt))
+ fse.code = isc_fmt->mbus_code;
+ else
+ fse.code = isc->raw_fmt->mbus_code;
ret = v4l2_subdev_call(isc->current_subdev->sd, pad, enum_frame_size,
NULL, &fse);
@@ -873,7 +1059,10 @@ static int isc_enum_frameintervals(struct file *file, void *fh,
if (!isc_fmt)
return -EINVAL;
- fie.code = isc_fmt->mbus_code;
+ if (sensor_is_preferred(isc_fmt))
+ fie.code = isc_fmt->mbus_code;
+ else
+ fie.code = isc->raw_fmt->mbus_code;
ret = v4l2_subdev_call(isc->current_subdev->sd, pad,
enum_frame_interval, NULL, &fie);
@@ -911,6 +1100,10 @@ static const struct v4l2_ioctl_ops isc_ioctl_ops = {
.vidioc_s_parm = isc_s_parm,
.vidioc_enum_framesizes = isc_enum_framesizes,
.vidioc_enum_frameintervals = isc_enum_frameintervals,
+
+ .vidioc_log_status = v4l2_ctrl_log_status,
+ .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
+ .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
static int isc_open(struct file *file)
@@ -1007,8 +1200,7 @@ static irqreturn_t isc_interrupt(int irq, void *dev_id)
struct isc_buffer, list);
list_del(&isc->cur_frm->list);
- isc_start_dma(regmap, isc->cur_frm,
- isc->current_fmt->reg_dctrl_dview);
+ isc_start_dma(isc);
}
if (isc->stop)
@@ -1051,6 +1243,7 @@ static void isc_async_unbind(struct v4l2_async_notifier *notifier,
video_unregister_device(&isc->video_dev);
if (isc->current_subdev->config)
v4l2_subdev_free_pad_config(isc->current_subdev->config);
+ v4l2_ctrl_handler_free(&isc->ctrls.handler);
}
static struct isc_format *find_format_by_code(unsigned int code, int *index)
@@ -1081,7 +1274,9 @@ static int isc_formats_init(struct isc_device *isc)
fmt = &isc_formats[0];
for (i = 0; i < ARRAY_SIZE(isc_formats); i++) {
- fmt->support = false;
+ fmt->isc_support = false;
+ fmt->sd_support = false;
+
fmt++;
}
@@ -1092,8 +1287,22 @@ static int isc_formats_init(struct isc_device *isc)
if (!fmt)
continue;
- fmt->support = true;
- num_fmts++;
+ fmt->sd_support = true;
+
+ if (i <= RAW_FMT_INDEX_END) {
+ for (j = ISC_FMT_INDEX_START;
+ j <= ISC_FMT_INDEX_END; j++)
+ isc_formats[j].isc_support = true;
+
+ isc->raw_fmt = fmt;
+ }
+ }
+
+ for (i = 0, num_fmts = 0; i < ARRAY_SIZE(isc_formats); i++) {
+ if (fmt->isc_support || fmt->sd_support)
+ num_fmts++;
+
+ fmt++;
}
if (!num_fmts)
@@ -1110,7 +1319,7 @@ static int isc_formats_init(struct isc_device *isc)
fmt = &isc_formats[0];
for (i = 0, j = 0; i < ARRAY_SIZE(isc_formats); i++) {
- if (fmt->support)
+ if (fmt->isc_support || fmt->sd_support)
isc->user_formats[j++] = fmt;
fmt++;
@@ -1132,7 +1341,7 @@ static int isc_set_default_fmt(struct isc_device *isc)
};
int ret;
- ret = isc_try_fmt(isc, &f, NULL);
+ ret = isc_try_fmt(isc, &f, NULL, NULL);
if (ret)
return ret;
@@ -1142,6 +1351,73 @@ static int isc_set_default_fmt(struct isc_device *isc)
return 0;
}
+static void isc_set_gamma(struct isc_device *isc, u32 index)
+{
+ const u32 *gamma = &isc_gamma_table[index][0];
+ struct regmap *regmap = isc->regmap;
+
+ regmap_bulk_write(regmap, ISC_GAM_BENTRY, gamma, GAMMA_ENTRIES);
+ regmap_bulk_write(regmap, ISC_GAM_GENTRY, gamma, GAMMA_ENTRIES);
+ regmap_bulk_write(regmap, ISC_GAM_RENTRY, gamma, GAMMA_ENTRIES);
+}
+
+static int isc_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct isc_device *isc = container_of(ctrl->handler,
+ struct isc_device, ctrls.handler);
+
+ switch (ctrl->id) {
+ case V4L2_CID_BRIGHTNESS:
+ regmap_write(isc->regmap, ISC_CBC_BRIGHT,
+ ctrl->val & ISC_CBC_BRIGHT_MASK);
+ break;
+ case V4L2_CID_CONTRAST:
+ regmap_write(isc->regmap, ISC_CBC_CONTRAST,
+ (ctrl->val << 8) & ISC_CBC_CONTRAST_MASK);
+ break;
+ case V4L2_CID_GAMMA:
+ isc_set_gamma(isc, ctrl->val);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static const struct v4l2_ctrl_ops isc_ctrl_ops = {
+ .s_ctrl = isc_s_ctrl,
+};
+
+static int isc_ctrl_init(struct isc_device *isc)
+{
+ const struct v4l2_ctrl_ops *ops = &isc_ctrl_ops;
+ struct v4l2_ctrl_handler *hdl = &isc->ctrls.handler;
+ int ret;
+
+ ret = v4l2_ctrl_handler_init(hdl, 3);
+ if (ret < 0)
+ return ret;
+
+ v4l2_ctrl_new_std(hdl, ops, V4L2_CID_BRIGHTNESS, -1024, 1023, 1, 0);
+ v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -8, 7, 1, 1);
+ v4l2_ctrl_new_std(hdl, ops, V4L2_CID_GAMMA, 0, GAMMA_MAX - 1, 1, 2);
+
+ v4l2_ctrl_handler_setup(hdl);
+
+ return 0;
+}
+
+static void isc_regs_init(struct isc_device *isc)
+{
+ struct regmap *regmap = isc->regmap;
+
+ regmap_write(regmap, ISC_WB_O_RGR, 0x0);
+ regmap_write(regmap, ISC_WB_O_BGR, 0x0);
+ regmap_write(regmap, ISC_WB_G_RGR, 0x200 | (0x200 << 16));
+ regmap_write(regmap, ISC_WB_G_BGR, 0x200 | (0x200 << 16));
+}
+
static int isc_async_complete(struct v4l2_async_notifier *notifier)
{
struct isc_device *isc = container_of(notifier->v4l2_dev,
@@ -1151,6 +1427,12 @@ static int isc_async_complete(struct v4l2_async_notifier *notifier)
struct vb2_queue *q = &isc->vb2_vidq;
int ret;
+ ret = v4l2_device_register_subdev_nodes(&isc->v4l2_dev);
+ if (ret < 0) {
+ v4l2_err(&isc->v4l2_dev, "Failed to register subdev nodes\n");
+ return ret;
+ }
+
isc->current_subdev = container_of(notifier,
struct isc_subdev_entity, notifier);
sd_entity = isc->current_subdev;
@@ -1198,6 +1480,14 @@ static int isc_async_complete(struct v4l2_async_notifier *notifier)
return ret;
}
+ ret = isc_ctrl_init(isc);
+ if (ret) {
+ v4l2_err(&isc->v4l2_dev, "Init isc ctrols failed: %d\n", ret);
+ return ret;
+ }
+
+ isc_regs_init(isc);
+
/* Register video device */
strlcpy(vdev->name, ATMEL_ISC_NAME, sizeof(vdev->name));
vdev->release = video_device_release_empty;
@@ -1207,7 +1497,7 @@ static int isc_async_complete(struct v4l2_async_notifier *notifier)
vdev->vfl_dir = VFL_DIR_RX;
vdev->queue = q;
vdev->lock = &isc->lock;
- vdev->ctrl_handler = isc->current_subdev->sd->ctrl_handler;
+ vdev->ctrl_handler = &isc->ctrls.handler;
vdev->device_caps = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_CAPTURE;
video_set_drvdata(vdev, isc);
--
2.7.4
^ permalink raw reply related
* [PATCH 06/12] usb: dwc3: omap: Replace the extcon API
From: Chanwoo Choi @ 2016-12-02 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877f7lntjq.fsf@linux.intel.com>
Hi Felipe,
On 2016? 11? 30? 19:36, Felipe Balbi wrote:
>
> Hi,
>
> Chanwoo Choi <cw00.choi@samsung.com> writes:
>> This patch uses the resource-managed extcon API for extcon_register_notifier()
>> and replaces the deprecated extcon API as following:
>> - extcon_get_cable_state_() -> extcon_get_state()
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>
> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>
Thanks for your review.
Each patch has no any dependency among patches.
So, If possible, could you pick the patch6/8/9/10/11/12 on your tree?
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH v4 1/3] lib: add bitrev8x4()
From: Anatolij Gustschin @ 2016-12-02 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8fb2f1c2-c39c-b74f-d5c8-d6731cbd67c8@gmail.com>
Hi Joshua,
On Thu, 1 Dec 2016 16:04:09 -0800
Joshua Clayton stillcompiling at gmail.com wrote:
...
>>> +static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
>>> +{
>>> + __asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));
>> return x;
>Oops thats a little embarrassing;
>I'll add a return.
>>> +}
>> otherwise you get
>>
>> In function '__arch_bitrev8x4':
>> warning: no return statement in function returning non-void [-Wreturn-type]
>>
>
>I wonder why I do not see this warning when compiling. The inlining, maybe?
do you have CONFIG_HAVE_ARCH_BITREVERSE=y in your .config?
Probably not optimized code is used, otherwise you will send wrong
data to FPGA (due to wrong return values from __arch_bitrev8x4).
Anatolij
^ permalink raw reply
* [PATCH v3] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Sekhar Nori @ 2016-12-02 7:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <76e7853b-8235-173a-7214-c450487751c6@lechnology.com>
On Thursday 01 December 2016 11:17 PM, David Lechner wrote:
>
>> + clk_put(usb20_clk);
>
> The global usb20_clk is no longer valid after this. Should we set it to
> NULL here?
No need of this. Also, NULL is valid clock handle.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v4 1/1] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Duc Dang @ 2016-12-02 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d593615-e97f-8738-42be-1f8f4906d2f4@redhat.com>
On Thu, Dec 1, 2016 at 11:12 PM, Jon Masters <jcm@redhat.com> wrote:
> On 12/01/2016 09:27 PM, Duc Dang wrote:
>> PCIe controllers in X-Gene SoCs is not ECAM compliant: software
>> needs to configure additional controller's register to address
>> device at bus:dev:function.
>>
>> The quirk will discover controller MMIO register space and configure
>> controller registers to select and address the target secondary device.
>>
>> The quirk will only be applied for X-Gene PCIe MCFG table with
>> OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
>>
>> Signed-off-by: Duc Dang <dhdang@apm.com>
>
> So far I've tested this on an HPE ProLiant m400 (Moonshot) cartridge
> and will test it on some other reference platforms soon. Bootlog for
> the m400 attached in case Bjorn wants to see the output. Here's
> what I see in /proc/iomem btw on that platform:
>
> # cat /proc/iomem
> 10520000-10523fff : APMC0D18:00
> 10520000-10523fff : APMC0D18:00
> 10524000-10527fff : APMC0D17:00
> 10540000-1054a0ff : APMC0D01:00
> 10546000-10546fff : APMC0D50:00
> 1054a000-1054a00f : APMC0D12:03
> 1054a000-1054a00f : APMC0D12:02
> 1054a000-1054a00f : APMC0D12:01
> 1054a000-1054a00f : APMC0D12:00
> 17000000-17000fff : APMC0D01:00
> 17001000-17001fff : APMC0D01:00
> 17001000-170013ff : APMC0D15:00
> 17001000-170013ff : APMC0D15:00
> 1701c000-1701cfff : APMC0D14:00
> 1a800000-1a800fff : APMC0D0D:00
> 1a800000-1a800fff : APMC0D0D:00
> 1c000200-1c0002ff : APMC0D06:00
> 1c021000-1c0210ff : APMC0D08:00
> 1c021000-1c02101f : serial
> 1c024000-1c024fff : APMC0D07:00
> 1f230000-1f230fff : APMC0D0D:00
> 1f230000-1f230fff : APMC0D0D:00
> 1f23d000-1f23dfff : APMC0D0D:00
> 1f23d000-1f23dfff : APMC0D0D:00
> 1f23e000-1f23efff : APMC0D0D:00
> 1f23e000-1f23efff : APMC0D0D:00
> 1f2a0000-1f31ffff : APMC0D06:00
> 1f500000-1f50ffff : PCI Bus 0000:00
> 1f500000-1f50ffff : PNP0A08:00
> 78800000-78800fff : APMC0D13:00
> 78800000-78800fff : APMC0D12:03
> 78800000-78800fff : APMC0D12:02
> 78800000-78800fff : APMC0D12:01
> 78800000-78800fff : APMC0D12:00
> 78800000-78800fff : APMC0D11:00
> 78800000-78800fff : APMC0D10:03
> 78800000-78800fff : APMC0D10:02
> 78800000-78800fff : APMC0D10:01
> 78800000-78800fff : APMC0D10:00
> 79000000-798fffff : APMC0D0E:00
> 7c000000-7c1fffff : APMC0D12:00
> 7c200000-7c3fffff : APMC0D12:01
> 7c400000-7c5fffff : APMC0D12:02
> 7c600000-7c7fffff : APMC0D12:03
> 7e000000-7e000fff : APMC0D13:00
> 7e200000-7e200fff : APMC0D10:03
> 7e200000-7e200fff : APMC0D10:02
> 7e200000-7e200fff : APMC0D10:01
> 7e200000-7e200fff : APMC0D10:00
> 7e600000-7e600fff : APMC0D11:00
> 7e700000-7e700fff : APMC0D10:03
> 7e700000-7e700fff : APMC0D10:02
> 7e700000-7e700fff : APMC0D10:01
> 7e700000-7e700fff : APMC0D10:00
> 7e720000-7e720fff : APMC0D10:03
> 7e720000-7e720fff : APMC0D10:02
> 7e720000-7e720fff : APMC0D10:01
> 7e720000-7e720fff : APMC0D10:00
> 7e800000-7e800fff : APMC0D10:00
> 7e840000-7e840fff : APMC0D10:01
> 7e880000-7e880fff : APMC0D10:02
> 7e8c0000-7e8c0fff : APMC0D10:03
> 7e930000-7e930fff : APMC0D13:00
> 4000000000-4001ffffff : System RAM
> 4000080000-4000c3ffff : Kernel code
> 4000db0000-400165ffff : Kernel data
> 40023a0000-4ff733ffff : System RAM
> 4ff7340000-4ff77cffff : reserved
> 4ff77d0000-4ff79cffff : System RAM
> 4ff79d0000-4ff7e7ffff : reserved
> 4ff7e80000-4ff7e8ffff : System RAM
> 4ff7e90000-4ff7efffff : reserved
> 4ff7f10000-4ff800ffff : reserved
> 4ff8010000-4fffffffff : System RAM
> a020000000-a03fffffff : PCI Bus 0000:00
> a020000000-a0201fffff : PCI Bus 0000:01
> a020000000-a0200fffff : 0000:01:00.0
> a020000000-a0200fffff : mlx4_core
> a020100000-a0201fffff : 0000:01:00.0
> a060000000-a07fffffff : PCI Bus 0000:00
> a0d0000000-a0dfffffff : PCI ECAM
> a110000000-a14fffffff : PCI Bus 0000:00
> a110000000-a121ffffff : PCI Bus 0000:01
> a110000000-a111ffffff : 0000:01:00.0
> a110000000-a111ffffff : mlx4_core
> a112000000-a121ffffff : 0000:01:00.0
>
> Adding a Tested-by for the record:
>
> Tested-by: Jon Masters <jcm@redhat.com>
Thanks a lot for testing this, Jon.
>
> Jon.
>
> --
> Computer Architect | Sent from my Fedora powered laptop
>
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Duc Dang @ 2016-12-02 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cc77fe88-b36e-bb36-b5df-2934a88bea3c@redhat.com>
On Thu, Dec 1, 2016 at 10:31 PM, Jon Masters <jcm@redhat.com> wrote:
> Bjorn,
>
> Although I think the below still applies (that we need to leave that
> Memory32Fixed for existing deployments, and this is going to result
> in /proc/iomem polution), I've done some more reading of your ecam
> tree and the implementation of acpi_get_rc_resources you mentioned,
> and in particular how the PNP0C02 devices actually get wired up.
>
> I would like to be able to boot upstream on existing shipping and
> deployed machines that are in the field (not to mention our labs), but
> there's no reason we can't *also* get APM to add a new vendor specific
> PNP0C02 to the ACPI namespace in future firmware updates (for at least
> their own Mustang reference boards) matching segment to CSR, as in the
> case of the HiSi patches. That might then allow for some later
> preference to use that for the CSR rather than getting it from the RC
> device. Still, it would be ideal to boot on machines that are shipping
> from HPE and others at this moment, so I am still hopeful you'll
> at least allow the approach from Duc's v4 for now (4.10).
APM X-Gene 1 and X-Gene 2 ACPI tables will absolutely have PNP0C02
nodes (in upcoming firmware release). I hope to have a solution that
works for both old buggy firmware and the future improved firmware. So
I am thinking the CSR discovery will be like this:
(1) Use acpi_get_rc_resources() to discover CSR resource by checking
PNP0C02 nodes
(2) (1) should succeed with the new firmware
(3) If (1) fails, we can fall back to approach on v4 patch: calling
xgene_get_csr_resource() to discover the CSR described by
Memory32Fixed macro.
How do you feel about this? The drawback is the new firmware that does
not have the CSR space described with Memory32Fixed macro will fail on
the distro version that uses the old quirk (that relies on this
Memory32Fixed macro).
>
> Another nasty option for later consideration could then be having
> the kernel fake up any missing PNP0C02 on existing machines, but
> it would need special knowledge of the platform to generate that
> so as to handle the problem Mark flagged earlier (segment vs
> controller mismatch on some platforms). That could be done with a
> DMI quirk that matched on a specific (e.g. HPE) machine. It would
> only be needed on "broken" existing machines, and could be added
> post-4.10 to clean this up if you really want to do that.
Bjorn suggested similar approach (have a PNP quirk to fabricate a
PNP0C02 device and decleare all the required resources there) on
another thread. But as you said, this approach does not scale, it can
only applicable for a specific machine (by checking DMI information to
apply the PNP quirk).
>
> That's all very nasty...
>
> Jon.
>
> On 12/01/2016 11:08 PM, Jon Masters wrote:
>> Hi Bjorn, Duc, Mark,
>>
>> I switched my brain to the on mode and went and read some specs, and a few
>> tables, so here's my 2 cents on this...
>>
>> On 12/01/2016 06:22 PM, Duc Dang wrote:
>>> On Thu, Dec 1, 2016 at 3:07 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>>>> On Thu, Dec 01, 2016 at 02:10:10PM -0800, Duc Dang wrote:
>>
>>>>>>> The SoC provide some number of RC bridges, each with a different base
>>>>>>> for some mmio registers. Even if segment is legitimate in MCFG, there
>>>>>>> is still a problem if a platform doesn't use the segment ordering
>>>>>>> implied by the code. But the PNP0A03 _CRS does have this base address
>>>>>>> as the first memory resource, so we could get it from there and not
>>>>>>> have hard-coded addresses and implied ording in the quirk code.
>>>>>>
>>>>>> I'm confused. Doesn't the current code treat every item in PNP0A03
>>>>>> _CRS as a window? Do you mean the first resource is handled
>>>>>> differently somehow? The Consumer/Producer bit could allow us to do
>>>>>> this by marking the RC MMIO space as "Consumer", but I didn't think
>>>>>> that strategy was quite working yet.
>>
>> Let's see if I summarized this correctly...
>>
>> 1. The MMIO registers for the host bridge itself need to be described
>> somewhere, especially if we need to find those in a quirk and poke
>> them. Since those registers are very much part of the bridge device,
>> it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.
>>
>> 2. The address space covering these registers MUST be described as a
>> ResourceConsumer in order to avoid accidentally exposing them as
>> available for use by downstream devices on the PCI bus.
>>
>> 3. The ACPI specification allows for resources of the type "Memory32Fixed".
>> This is a macro that doesn't have the notion of a producer or consumer.
>> HOWEVER various interpretations seem to be that this could/should
>> default to being interpreted as a consumed region.
>>
>> 4. At one point, a regression was added to the kernel:
>>
>> 63f1789ec716 ("x86/PCI/ACPI: Ignore resources consumed by
>> host bridge itself")
>>
>> Which lead to a series on conversations about what should happen
>> for bridge resources (e.g. https://lkml.org/lkml/2015/3/24/962 )
>>
>> 5. This resulted in the following commit reverting point 4:
>>
>> 2c62e8492ed7 ("x86/PCI/ACPI: Make all resources except [io 0xcf8-0xcff]
>> available on PCI bus")
>>
>> Which also stated that:
>>
>> "This solution will also ease the way to consolidate ACPI PCI host
>> bridge common code from x86, ia64 and ARM64"
>>
>> End of summary.
>>
>> So it seems that generally there is an aversion to having bridge resources
>> be described in this manner and you would like to require that they be
>> described e.g. using QWordMemory with a ResourceConsumer type?
>>
>> BUT if we were to do that, it would break existing shipping systems since
>> there are quirks out there that use this form to find the base CSR:
>>
>> if (acpi_res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
>> fixed32 = &acpi_res->data.fixed_memory32;
>> port->csr_base = ioremap(fixed32->address,
>> fixed32->address_length);
>> return AE_CTRL_TERMINATE;
>> }
>>
>> That's what's shipping in at least RHEL(SA) today, and probably in other
>> distros. So if we get vendors to take that out, existing stuff will break,
>> which will have the downside that customers will have to choose between
>> whether to run a given distro or be able to use upstream kernels. In
>> that sense, to me, there are shipping platforms out there, which may well
>> be doing the "wrong" thing, but they are deployed and they are doing it.
>>
>> Which makes me wonder a couple of things (I think should NOT be done):
>>
>> 1. What would happen if we had both. A FixedMemory32 and the same region
>> described again using the longer form as a consumed region. I doubt
>> that's legal, and the current code would still add the region if it
>> saw the FixedMemory32 first when walking the tree. I don't like it,
>> but I'm mentioning it in case that leads to some helpful thinking.
>>
>> 2. What would happen if we had a difference policy on arm64 for such
>> resources. x86 has an "exception" for accessing the config space
>> using IO port 0xCF8-0xCFF (a fairly reasonable exception!) and
>> we can make the rules for a new platform (i.e. actually prescribe
>> exactly what the behavior is, rather than have it not be defined).
>> This is of course terrible in that existing BIOS vendors and so on
>> won't necessarily know this when working on ARM ACPI later on.
>>
>> I don't like either of these obviously. I'm hoping there's some way we
>> can say that this is tolerated in this one quirk (allow the use of
>> FixedMemory32 in this case) on the grounds that the driver claims
>> this bridge region and can be annotated to explain such.
>>
>> Once you let us know what you prefer, we will go and update the ARM
>> SBBR to spell out that future platforms should not make this mistake
>> again. We can prescribe whatever you'd like in terms of how bridge
>> resources consumed by the bridge are exposed. I have spoken about
>> this kind of situation within MS in the past, but they didn't have
>> specific guidance since they don't really tolerate such quirks. I
>> can, however, consult them before we change the SBBR as well.
>>
>>>>> The first resource is defined like below. It was introduced long time
>>>>> ago to use with older version of X-Gene ECAM quirks.
>>>>> Memory32Fixed(ReadWrite, 0x1F2B0000, 0x10000, )
>>
>> Indeed. And in the case of m400, it is currently this in shipping systems:
>>
>> Memory32Fixed (ReadWrite,
>> 0x1F500000, // Address Base
>> 0x00010000, // Address Length
>> )
>>
>> The spec isn't clear on whether these are produced or consumed but the
>> implication is that these are consumed resources in most cases. Not that
>> this changes any of the above, but one can understand why it happened.
>>
>>>>> [ 0.822990] pci_bus 0000:00: root bus resource [mem 0x1f2b0000-0x1f2bffff]
>>>>
>>>> I think this is wrong. The PCI core thinks [mem 0x1f2b0000-0x1f2bffff]
>>>> is available for use by devices on bus 0000:00, but I think you're
>>>> saying it is consumed by the bridge itself, not forwarded down to PCI.
>>
>> Indeed.
>>
>>>> What's in your /proc/iomem? I see that your quirks do call
>>>> devm_ioremap_resource(), which calls devm_request_mem_region()
>>>> internally, so the driver does at least request that region, which
>>>> should keep us from assigning it to PCI devices.
>>
>> I'm hoping you can grant an exception on the grounds that the quirk will
>> keep the region from actually being used. And then somehow we document
>> this in the driver.
>>
>>>> But it still isn't quite right to tell the PCI core that the region is
>>>> available on the root bus.
>>>
>>> This is /proc/iomem output on my Mustang board. The 64K "PCIe CSR"
>>> region is consumed completely.
>>> 1f2b0000-1f2bffff : PCI Bus 0000:00
>>> 1f2b0000-1f2bffff : PCIe CSR
>>>
>>> e040000000-e07fffffff : PCI Bus 0000:00
>>> e040000000-e0401fffff : PCI Bus 0000:01
>>> e040000000-e0400fffff : 0000:01:00.0
>>> e040000000-e0400fffff : mlx4_core
>>> e040100000-e0401fffff : 0000:01:00.0
>>> e0d0000000-e0dfffffff : PCI ECAM
>>> f000000000-ffffffffff : PCI Bus 0000:00
>>> f000000000-f001ffffff : PCI Bus 0000:01
>>> f000000000-f001ffffff : 0000:01:00.0
>>> f000000000-f001ffffff : mlx4_core
>>>
>>> Using hard-coded resources for mmio space make the quirk rely on the
>>> segment number passing from the firmware. Using Mark's method or
>>> acpi_get_rc_resource can discover the mmio space and consume all of
>>> the space, but as you mentioned, it leaves the defect that PCI core
>>> considers the mmio space as available resource for secondary devices
>>> although it will never allocate the mmio space to secondary devices as
>>> the RC already reserves and consumes all of the space.
>>
>> Indeed. It's not clean, but perhaps we can get away with it on the
>> grounds that there are existing systems out there and this won't
>> be allowed to happen again in the future :)
>>
>> Jon.
>>
>
>
> --
> Computer Architect | Sent from my Fedora powered laptop
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox