* [PATCH 1/3] ARM: Define KERNEL_START and KERNEL_END
From: kbuild test robot @ 2016-12-07 6:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206195312.22354-2-f.fainelli@gmail.com>
Hi Florian,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.9-rc8 next-20161206]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/ARM-Add-support-for-CONFIG_DEBUG_VIRTUAL/20161207-071442
config: arm-lart_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
>> drivers/mtd/devices/lart.c:83:0: warning: "KERNEL_START" redefined
#define KERNEL_START (BLOB_START + BLOB_LEN)
In file included from arch/arm/include/asm/page.h:163:0,
from arch/arm/include/asm/thread_info.h:17,
from include/linux/thread_info.h:58,
from include/asm-generic/preempt.h:4,
from ./arch/arm/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from drivers/mtd/devices/lart.c:38:
arch/arm/include/asm/memory.h:117:0: note: this is the location of the previous definition
#define KERNEL_START _stext
vim +/KERNEL_START +83 drivers/mtd/devices/lart.c
^1da177e Linus Torvalds 2005-04-16 67
^1da177e Linus Torvalds 2005-04-16 68 /*
^1da177e Linus Torvalds 2005-04-16 69 * These values are specific to LART
^1da177e Linus Torvalds 2005-04-16 70 */
^1da177e Linus Torvalds 2005-04-16 71
^1da177e Linus Torvalds 2005-04-16 72 /* general */
^1da177e Linus Torvalds 2005-04-16 73 #define BUSWIDTH 4 /* don't change this - a lot of the code _will_ break if you change this */
^1da177e Linus Torvalds 2005-04-16 74 #define FLASH_OFFSET 0xe8000000 /* see linux/arch/arm/mach-sa1100/lart.c */
^1da177e Linus Torvalds 2005-04-16 75
^1da177e Linus Torvalds 2005-04-16 76 /* blob */
^1da177e Linus Torvalds 2005-04-16 77 #define NUM_BLOB_BLOCKS FLASH_NUMBLOCKS_16m_PARAM
^1da177e Linus Torvalds 2005-04-16 78 #define BLOB_START 0x00000000
^1da177e Linus Torvalds 2005-04-16 79 #define BLOB_LEN (NUM_BLOB_BLOCKS * FLASH_BLOCKSIZE_PARAM)
^1da177e Linus Torvalds 2005-04-16 80
^1da177e Linus Torvalds 2005-04-16 81 /* kernel */
^1da177e Linus Torvalds 2005-04-16 82 #define NUM_KERNEL_BLOCKS 7
^1da177e Linus Torvalds 2005-04-16 @83 #define KERNEL_START (BLOB_START + BLOB_LEN)
^1da177e Linus Torvalds 2005-04-16 84 #define KERNEL_LEN (NUM_KERNEL_BLOCKS * FLASH_BLOCKSIZE_MAIN)
^1da177e Linus Torvalds 2005-04-16 85
^1da177e Linus Torvalds 2005-04-16 86 /* initial ramdisk */
^1da177e Linus Torvalds 2005-04-16 87 #define NUM_INITRD_BLOCKS 24
^1da177e Linus Torvalds 2005-04-16 88 #define INITRD_START (KERNEL_START + KERNEL_LEN)
^1da177e Linus Torvalds 2005-04-16 89 #define INITRD_LEN (NUM_INITRD_BLOCKS * FLASH_BLOCKSIZE_MAIN)
^1da177e Linus Torvalds 2005-04-16 90
^1da177e Linus Torvalds 2005-04-16 91 /*
:::::: The code at line 83 was first introduced by commit
:::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:::::: TO: Linus Torvalds <torvalds@ppc970.osdl.org>
:::::: CC: Linus Torvalds <torvalds@ppc970.osdl.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 11578 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/3829bed8/attachment-0001.gz>
^ permalink raw reply
* [PATCH 2/4] ARM: versatile: define empty debug_ll_io_init() for no-MMU
From: Greg Ungerer @ 2016-12-07 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481090912-29835-1-git-send-email-gerg@uclinux.org>
No-MMU configured targets have no definition for debug_ll_io_init().
Not all machines use this and it will only be required if CONFIG_DEBUG_LL
is enabled.
But when compiling for a target that uses it and it is configured for
no-MMU (!CONFIG_MMU), for example the versatile machine, you will get:
CC arch/arm/mach-versatile/versatile_dt.o
arch/arm/mach-versatile/versatile_dt.c: In function ?versatile_map_io?:
arch/arm/mach-versatile/versatile_dt.c:283:2: error: implicit declaration of function ?debug_ll_io_init? [-Werror=implicit-function-declaration]
debug_ll_io_init();
^
Fix by adding a macro for it to the !CONFIG_MMU path in map.h.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/include/asm/mach/map.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 9b7c328..b1fe9c8 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -62,6 +62,7 @@ extern int ioremap_page(unsigned long virt, unsigned long phys,
#else
#define iotable_init(map,num) do { } while (0)
#define vm_reserve_area_early(a,s,c) do { } while (0)
+#define debug_ll_io_init() do { } while (0)
#endif
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] ARM: versatile: support no-MMU mode addressing
From: Greg Ungerer @ 2016-12-07 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481090912-29835-1-git-send-email-gerg@uclinux.org>
Currently for the versatile boards the IO_ADDRESS() macro applies static
virtual address mapping for built-in IO devices. When operating without
the MMU enabled IO devices are accessed at their physical address, no
address translation is required.
For the !CONFIG_MMU case then define the IO_ADDRESS() macro to return the
physical address.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/mach-versatile/versatile_dt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 3c8d39c..8cfa05a 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -37,7 +37,11 @@
#include <asm/mach/map.h>
/* macro to get at MMIO space when running virtually */
+#ifdef CONFIG_MMU
#define IO_ADDRESS(x) (((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
+#else
+#define IO_ADDRESS(x) (x)
+#endif
#define __io_address(n) ((void __iomem __force *)IO_ADDRESS(n))
/*
--
1.9.1
^ permalink raw reply related
* [PATCH 0/4] arm/versatile: no-MMU support
From: Greg Ungerer @ 2016-12-07 6:08 UTC (permalink / raw)
To: linux-arm-kernel
Does the ARM Versatile machine have a maintainer?
I have CC'ed this patch set to those names reported by get_maintainer.
I had no feedback on the first posting of this series back in August.
The following patches support configuring and building the versatile
machine with a no-MMU kernel.
There is only a few minor changes required. It was previously possible
in older kernels to build for versatile with CONFIG_MMU disabled, but
the change to devicetree lost that capability. These changes make it
possible again.
One patch is a fix for address translation (broken in older kernels too),
two are build problems when CONFIG_MMU is disabled, and the last is the
actuall configuration changes needed.
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general. With these patches applied
it is possible to build and run a kernel with MMU disabled on qemu.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/Kconfig | 10 ++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/include/asm/mach/map.h | 1 +
arch/arm/mach-versatile/Kconfig | 3 ++-
arch/arm/mach-versatile/Makefile.boot | 3 +++
arch/arm/mach-versatile/versatile_dt.c | 4 ++++
6 files changed, 22 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 3/5] arm64: dts: exynos5433: Add PPMU dt node
From: Chanwoo Choi @ 2016-12-07 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58478C41.5090500@samsung.com>
On 2016? 12? 07? 13:12, Chanwoo Choi wrote:
> On 2016? 12? 07? 04:07, Krzysztof Kozlowski wrote:
>> On Fri, Dec 02, 2016 at 04:18:05PM +0900, Chanwoo Choi wrote:
>>> This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
>>> to measure the utilization of each IP in Exynos SoC.
>>>
>>> - PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
>>> block with VDD_MIF power source.
>>> - PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
>>> block with VDD_INT power source.
>>>
>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 ++++++++++++++++++++++++
>>> 1 file changed, 24 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> index 64226d5ae471..8c4ee84d5232 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>>> @@ -599,6 +599,30 @@
>>> clock-names = "fin_pll", "mct";
>>> };
>>>
>>> + ppmu_d0_cpu: ppmu at 10480000 {
>>> + compatible = "samsung,exynos-ppmu-v2";
>>> + reg = <0x10480000 0x2000>;
>>> + status = "disabled";
>>
>> Why these are disabled? They have some external dependencies?
>
> There is no any dependency. If you want to remain it always enabled,
> I'm OK.
One more comment. Each PPMU has the four events which is used for devfreq driver
to get the utilization. If I remove the 'status = "disabled"' from exynos5433.dtsi,
first probe of PPMU device is fail on case1.
Case1. Disable PPMU device and then enable it on exynos5433-tm2.dts
[ 2.560126] exynos-ppmu: new PPMU device registered 10490000.ppmu (ppmu-event0-d0-general)
[ 2.565957] exynos-ppmu: new PPMU device registered 104c0000.ppmu (ppmu-event0-d1-general)
Case2. Enable PPMU device always. First probe is failed and then second probe is successful.
[ 2.898781] exynos-ppmu 10480000.ppmu: failed to get child node of devfreq-event devices
[ 2.899077] exynos-ppmu 10480000.ppmu: failed to parse exynos ppmu dt node
[ 2.899289] exynos-ppmu 10480000.ppmu: failed to parse devicetree for resource
[ 2.899602] exynos-ppmu: probe of 10480000.ppmu failed with error -22
[ 2.905364] exynos-ppmu: new PPMU device registered 10490000.ppmu (ppmu-event0-d0-general)
[ 2.913535] exynos-ppmu 104b0000.ppmu: failed to get child node of devfreq-event devices
[ 2.921402] exynos-ppmu 104b0000.ppmu: failed to parse exynos ppmu dt node
[ 2.928250] exynos-ppmu 104b0000.ppmu: failed to parse devicetree for resource
[ 2.935571] exynos-ppmu: probe of 104b0000.ppmu failed with error -22
[ 2.942144] exynos-ppmu: new PPMU device registered 104c0000.ppmu (ppmu-event0-d1-general)
Best Regards,
Chanwoo Choi
[snip]
^ permalink raw reply
* [PATCH v5 5/5] [media] davinci: VPIF: add basic support for DT init
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207050826.23174-1-khilman@baylibre.com>
Add basic support for initialization via DT
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index f50148dcba64..1b02a6363f77 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -467,8 +467,17 @@ static const struct dev_pm_ops vpif_pm = {
#define vpif_pm_ops NULL
#endif
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id vpif_of_match[] = {
+ { .compatible = "ti,da850-vpif", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, vpif_of_match);
+#endif
+
static struct platform_driver vpif_driver = {
.driver = {
+ .of_match_table = of_match_ptr(vpif_of_match),
.name = VPIF_DRIVER_NAME,
.pm = vpif_pm_ops,
},
--
2.9.3
^ permalink raw reply related
* [PATCH v5 4/5] [media] dt-bindings: add TI VPIF documentation
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207050826.23174-1-khilman@baylibre.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
.../devicetree/bindings/media/ti,da850-vpif.txt | 67 ++++++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt
diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
new file mode 100644
index 000000000000..fa06dfdb6898
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
@@ -0,0 +1,67 @@
+Texas Instruments VPIF
+----------------------
+
+The TI Video Port InterFace (VPIF) is the primary component for video
+capture and display on the DA850/AM18x family of TI DaVinci/Sitara
+SoCs.
+
+TI Document reference: SPRUH82C, Chapter 35
+http://www.ti.com/lit/pdf/spruh82
+
+Required properties:
+- compatible: must be "ti,da850-vpif"
+- reg: physical base address and length of the registers set for the device;
+- interrupts: should contain IRQ line for the VPIF
+
+Video Capture:
+
+VPIF has a 16-bit parallel bus input, supporting 2 8-bit channels or a
+single 16-bit channel. It should contain at least one port child node
+with child 'endpoint' node. Please refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example using 2 8-bit input channels, one of which is connected to an
+I2C-connected TVP5147 decoder:
+
+ vpif: vpif at 217000 {
+ compatible = "ti,da850-vpif";
+ reg = <0x217000 0x1000>;
+ interrupts = <92>;
+
+ port {
+ vpif_ch0: endpoint at 0 {
+ reg = <0>;
+ bus-width = <8>;
+ remote-endpoint = <&composite>;
+ };
+
+ vpif_ch1: endpoint at 1 {
+ reg = <1>;
+ bus-width = <8>;
+ data-shift = <8>;
+ };
+ };
+ };
+
+[ ... ]
+
+&i2c0 {
+
+ tvp5147 at 5d {
+ compatible = "ti,tvp5147";
+ reg = <0x5d>;
+ status = "okay";
+
+ port {
+ composite: endpoint {
+ hsync-active = <1>;
+ vsync-active = <1>;
+ pclk-sample = <0>;
+
+ /* VPIF channel 0 (lower 8-bits) */
+ remote-endpoint = <&vpif_ch0>;
+ bus-width = <8>;
+ };
+ };
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v5 3/5] [media] davinci: vpif_capture: fix start/stop streaming locking
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207050826.23174-1-khilman@baylibre.com>
Video capture subdevs may be over I2C and may sleep during xfer, so we
cannot do IRQ-disabled locking when calling the subdev.
The IRQ-disabled locking is meant to protect the DMA queue list
throughout the rest of the driver, so update the locking in
[start|stop]_streaming to protect just this list.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif_capture.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index c24049acd40a..f72a719efb3d 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -179,8 +179,6 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
unsigned long addr, flags;
int ret;
- spin_lock_irqsave(&common->irqlock, flags);
-
/* Initialize field_id */
ch->field_id = 0;
@@ -211,6 +209,7 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
vpif_config_addr(ch, ret);
/* Get the next frame from the buffer queue */
+ spin_lock_irqsave(&common->irqlock, flags);
common->cur_frm = common->next_frm = list_entry(common->dma_queue.next,
struct vpif_cap_buffer, list);
/* Remove buffer from the buffer queue */
@@ -244,6 +243,7 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
return 0;
err:
+ spin_lock_irqsave(&common->irqlock, flags);
list_for_each_entry_safe(buf, tmp, &common->dma_queue, list) {
list_del(&buf->list);
vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_QUEUED);
@@ -287,7 +287,6 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
vpif_dbg(1, debug, "stream off failed in subdev\n");
/* release all active buffers */
- spin_lock_irqsave(&common->irqlock, flags);
if (common->cur_frm == common->next_frm) {
vb2_buffer_done(&common->cur_frm->vb.vb2_buf,
VB2_BUF_STATE_ERROR);
@@ -300,6 +299,7 @@ static void vpif_stop_streaming(struct vb2_queue *vq)
VB2_BUF_STATE_ERROR);
}
+ spin_lock_irqsave(&common->irqlock, flags);
while (!list_empty(&common->dma_queue)) {
common->next_frm = list_entry(common->dma_queue.next,
struct vpif_cap_buffer, list);
--
2.9.3
^ permalink raw reply related
* [PATCH v5 2/5] [media] davinci: vpif_capture: remove hard-coded I2C adapter id
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207050826.23174-1-khilman@baylibre.com>
Remove hard-coded I2C adapter in favor of getting the
ID from platform_data.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif_capture.c | 5 ++++-
include/media/davinci/vpif_types.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index 20c4344ed118..c24049acd40a 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1486,7 +1486,10 @@ static __init int vpif_probe(struct platform_device *pdev)
}
if (!vpif_obj.config->asd_sizes) {
- i2c_adap = i2c_get_adapter(1);
+ int i2c_id = vpif_obj.config->i2c_adapter_id;
+
+ i2c_adap = i2c_get_adapter(i2c_id);
+ WARN_ON(!i2c_adap);
for (i = 0; i < subdev_count; i++) {
subdevdata = &vpif_obj.config->subdev_info[i];
vpif_obj.sd[i] =
diff --git a/include/media/davinci/vpif_types.h b/include/media/davinci/vpif_types.h
index 3cb1704a0650..4282a7db99d4 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -82,6 +82,7 @@ struct vpif_capture_config {
struct vpif_capture_chan_config chan_config[VPIF_CAPTURE_MAX_CHANNELS];
struct vpif_subdev_info *subdev_info;
int subdev_count;
+ int i2c_adapter_id;
const char *card_name;
struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
int *asd_sizes; /* 0-terminated array of asd group sizes */
--
2.9.3
^ permalink raw reply related
* [PATCH v5 1/5] [media] davinci: VPIF: fix module loading, init errors
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207050826.23174-1-khilman@baylibre.com>
Fix problems with automatic module loading by adding MODULE_ALIAS. Also
fix various load-time errors cause by incorrect or not present
platform_data.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
drivers/media/platform/davinci/vpif.c | 5 ++++-
drivers/media/platform/davinci/vpif_capture.c | 15 ++++++++++++++-
drivers/media/platform/davinci/vpif_display.c | 6 ++++++
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c
index 0380cf2e5775..f50148dcba64 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -32,6 +32,9 @@
MODULE_DESCRIPTION("TI DaVinci Video Port Interface driver");
MODULE_LICENSE("GPL");
+#define VPIF_DRIVER_NAME "vpif"
+MODULE_ALIAS("platform:" VPIF_DRIVER_NAME);
+
#define VPIF_CH0_MAX_MODES 22
#define VPIF_CH1_MAX_MODES 2
#define VPIF_CH2_MAX_MODES 15
@@ -466,7 +469,7 @@ static const struct dev_pm_ops vpif_pm = {
static struct platform_driver vpif_driver = {
.driver = {
- .name = "vpif",
+ .name = VPIF_DRIVER_NAME,
.pm = vpif_pm_ops,
},
.remove = vpif_remove,
diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
index 5104cc0ee40e..20c4344ed118 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -45,6 +45,7 @@ module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Debug level 0-1");
#define VPIF_DRIVER_NAME "vpif_capture"
+MODULE_ALIAS("platform:" VPIF_DRIVER_NAME);
/* global variables */
static struct vpif_device vpif_obj = { {NULL} };
@@ -647,6 +648,10 @@ static int vpif_input_to_subdev(
vpif_dbg(2, debug, "vpif_input_to_subdev\n");
+ if (!chan_cfg)
+ return -1;
+ if (input_index >= chan_cfg->input_count)
+ return -1;
subdev_name = chan_cfg->inputs[input_index].subdev_name;
if (subdev_name == NULL)
return -1;
@@ -654,7 +659,7 @@ static int vpif_input_to_subdev(
/* loop through the sub device list to get the sub device info */
for (i = 0; i < vpif_cfg->subdev_count; i++) {
subdev_info = &vpif_cfg->subdev_info[i];
- if (!strcmp(subdev_info->name, subdev_name))
+ if (subdev_info && !strcmp(subdev_info->name, subdev_name))
return i;
}
return -1;
@@ -685,6 +690,9 @@ static int vpif_set_input(
if (sd_index >= 0) {
sd = vpif_obj.sd[sd_index];
subdev_info = &vpif_cfg->subdev_info[sd_index];
+ } else {
+ /* no subdevice, no input to setup */
+ return 0;
}
/* first setup input path from sub device to vpif */
@@ -1435,6 +1443,11 @@ static __init int vpif_probe(struct platform_device *pdev)
int res_idx = 0;
int i, err;
+ if (!pdev->dev.platform_data) {
+ dev_warn(&pdev->dev, "Missing platform data. Giving up.\n");
+ return -EINVAL;
+ }
+
vpif_dev = &pdev->dev;
err = initialize_vpif();
diff --git a/drivers/media/platform/davinci/vpif_display.c b/drivers/media/platform/davinci/vpif_display.c
index 75b27233ec2f..7f632b757d32 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -42,6 +42,7 @@ module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "Debug level 0-1");
#define VPIF_DRIVER_NAME "vpif_display"
+MODULE_ALIAS("platform:" VPIF_DRIVER_NAME);
/* Is set to 1 in case of SDTV formats, 2 in case of HDTV formats. */
static int ycmux_mode;
@@ -1249,6 +1250,11 @@ static __init int vpif_probe(struct platform_device *pdev)
int res_idx = 0;
int i, err;
+ if (!pdev->dev.platform_data) {
+ dev_warn(&pdev->dev, "Missing platform data. Giving up.\n");
+ return -EINVAL;
+ }
+
vpif_dev = &pdev->dev;
err = initialize_vpif();
--
2.9.3
^ permalink raw reply related
* [PATCH v5 0/5] davinci: VPIF: add DT support
From: Kevin Hilman @ 2016-12-07 5:08 UTC (permalink / raw)
To: linux-arm-kernel
Prepare the groundwork for adding DT support for davinci VPIF drivers.
This series does some fixups/cleanups and then adds the DT binding and
DT compatible string matching for DT probing.
The controversial part from previous versions around async subdev
parsing, and specifically hard-coding the input/output routing of
subdevs, has been left out of this series. That part can be done as a
follow-on step after agreement has been reached on the path forward.
With this version, platforms can still use the VPIF capture/display
drivers, but must provide platform_data for the subdevs and subdev
routing.
Tested video capture to memory on da850-lcdk board using composite
input.
Changes since v4:
- dropped controversial async subdev parsing support. That can be
done as a follow-up step after the discussions have finalized on the
right approach.
- DT binding Acked by DT maintainer (Rob H.)
- reworked locking fix (suggested by Laurent)
Changes since v3:
- move to a single VPIF node, DT binding updated accordingly
- misc fixes/updates based on reviews from Sakari
Changes since v2:
- DT binding doc: fix example to use correct compatible
Changes since v1:
- more specific compatible strings, based on SoC: ti,da850-vpif*
- fix locking bug when unlocking over subdev s_stream
Kevin Hilman (5):
[media] davinci: VPIF: fix module loading, init errors
[media] davinci: vpif_capture: remove hard-coded I2C adapter id
[media] davinci: vpif_capture: fix start/stop streaming locking
[media] dt-bindings: add TI VPIF documentation
[media] davinci: VPIF: add basic support for DT init
.../devicetree/bindings/media/ti,da850-vpif.txt | 67 ++++++++++++++++++++++
drivers/media/platform/davinci/vpif.c | 14 ++++-
drivers/media/platform/davinci/vpif_capture.c | 26 +++++++--
drivers/media/platform/davinci/vpif_display.c | 6 ++
include/media/davinci/vpif_types.h | 1 +
5 files changed, 108 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt
--
2.9.3
^ permalink raw reply
* [PATCH 3/5] arm64: dts: exynos5433: Add PPMU dt node
From: Chanwoo Choi @ 2016-12-07 4:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206190756.GA12683@kozik-lap>
On 2016? 12? 07? 04:07, Krzysztof Kozlowski wrote:
> On Fri, Dec 02, 2016 at 04:18:05PM +0900, Chanwoo Choi wrote:
>> This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
>> to measure the utilization of each IP in Exynos SoC.
>>
>> - PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
>> block with VDD_MIF power source.
>> - PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
>> block with VDD_INT power source.
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 ++++++++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> index 64226d5ae471..8c4ee84d5232 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
>> @@ -599,6 +599,30 @@
>> clock-names = "fin_pll", "mct";
>> };
>>
>> + ppmu_d0_cpu: ppmu at 10480000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x10480000 0x2000>;
>> + status = "disabled";
>
> Why these are disabled? They have some external dependencies?
There is no any dependency. If you want to remain it always enabled,
I'm OK.
Best Regards,
Chanwoo Choi
>
> Best regards,
> Krzysztof
>
>> + };
>> +
>> + ppmu_d0_general: ppmu at 10490000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x10490000 0x2000>;
>> + status = "disabled";
>> + };
>> +
>> + ppmu_d1_cpu: ppmu at 104b0000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x104b0000 0x2000>;
>> + status = "disabled";
>> + };
>> +
>> + ppmu_d1_general: ppmu at 104c0000 {
>> + compatible = "samsung,exynos-ppmu-v2";
>> + reg = <0x104c0000 0x2000>;
>> + status = "disabled";
>> + };
>> +
>> pinctrl_alive: pinctrl at 10580000 {
>> compatible = "samsung,exynos5433-pinctrl";
>> reg = <0x10580000 0x1a20>, <0x11090000 0x100>;
>> --
>> 1.9.1
>>
>
>
>
^ permalink raw reply
* [PATCH 03/12] power_supply: axp288_charger: Replace the extcon API
From: Chanwoo Choi @ 2016-12-07 3:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207030527.n2u4q4tf7po74clg@earth>
Hi Sebastian,
On 2016? 12? 07? 12:05, Sebastian Reichel wrote:
> Hi Chanwoo,
>
> On Tue, Dec 06, 2016 at 09:26:14AM +0900, Chanwoo Choi wrote:
>> Could you please review and pick the patch3/4 for power-supply driver?
>
> Patches look fine. As I expect the merge window to open next week I
> would rather not queue this for 4.10 and instead do it once 4.10-rc1
> has been tagged.
>
> -- Sebastian
>
Thanks for your pick up.
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH] i2c: rk3x: keep i2c irq ON in suspend
From: David.Wu @ 2016-12-07 3:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=VgGy5hA4+7nvLs4NPNRuopak+bTW34S6X6S_vWgtnkjg@mail.gmail.com>
Hi Doug,
? 2016/12/7 0:31, Doug Anderson ??:
> Hi,
>
> On Tue, Dec 6, 2016 at 12:12 AM, David.Wu <david.wu@rock-chips.com> wrote:
>> Hi Heiko,
>>
>> ? 2016/12/5 18:54, Heiko Stuebner ??:
>>>
>>> Hi David,
>>>
>>> Am Montag, 5. Dezember 2016, 16:02:59 CET schrieb David Wu:
>>>>
>>>> During suspend there may still be some i2c access happening.
>>>> And if we don't keep i2c irq ON, there may be i2c access timeout if
>>>> i2c is in irq mode of operation.
>>>
>>>
>>> can you describe the issue you're trying to fix a bit more please?
>>
>>
>> Sometimes we could see the i2c timeout errors during suspend/resume, which
>> makes the duration of suspend/resume too longer.
>>
>> [ 484.171541] CPU4: Booted secondary processor [410fd082]
>> [ 485.172777] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>> [ 486.172760] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>> [ 487.172759] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>> [ 487.172840] cpu cpu4: _set_opp_voltage: failed to set voltage (800000
>> 800000 800000 mV): -110
>> [ 487.172874] cpu cpu4: failed to set volt 800000
>>
>>>
>>> I.e. I'd think the i2c-core does suspend i2c-client devices first, so that
>>> these should be able to finish up their ongoing transfers and not start
>>> any
>>> new ones instead?
>>>
>>> Your irq can still happen slightly after the system started going to
>>> actually
>>> sleep, so to me it looks like you just widened the window where irqs can
>>> be
>>> handled. Especially as your irq could also just simply stem from the start
>>> state, so you cannot even be sure if your transaction actually is
>>> finished.
>>
>>
>> Okay, you are right. I want to give it a double insurance at first, but it
>> may hide the unhappend issue.
>>
>>>
>>> So to me it looks like the i2c-connected device driver should be fixed
>>> instead?
>>
>>
>> I tell them to fix it in rk808 driver.
>
> To me it seems like perhaps cpufreq should not be changing frequencies
> until it is resumed properly. Presumably if all the ordering is done
> right then cpufreq should be resumed _after_ the i2c regulator so you
> should be OK. ...or am I somehow confused about that?
yes?the cpufreq and regulator should start i2c job after they resume
properly.
>
> Also note that previous i2c busses I worked with simply returned -EIO
> in the case where they were called when suspended. See
> "i2c-exynos5.c" and "i2c-s3c2410.c".
In "i2c-exynos5.c", it seems that using the "i2c->suspended" to protect
i2c transfer works most of the time. Of course it could prevent the next
new i2c transfer to start. But in one case, if the current i2c job was
not finished until the i2c irq was disabled by system suspend, the i2c
timeout error would also happen, as the current i2c job may have a large
data to transfer and it lasts from a long time.
So is it necessary to add a mutex lock to wait the current job to be
finished before the "i2c->suspended" is changed in i2c_suspend_noirq()?
However, the i2c_suspend_noirq() is called after suspend_device_irqs()
in system suspend, it means that the i2c timeout errors could happen
during the time between suspend_device_irqs() and i2c_suspend_noirq(),
if there were i2c transfers started.
>
> -Doug
>
>
>
^ permalink raw reply
* [PATCH] n900 device tree: cleanup
From: Sebastian Reichel @ 2016-12-07 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161011081243.GA24580@amd>
Hi Tony,
It looks like this fell through the cracks. Apart from inconsistent
patch subject:
Reviewed-By: Sebastian Reichel <sre@kernel.org>
-- Sebastian
On Tue, Oct 11, 2016 at 10:12:43AM +0200, Pavel Machek wrote:
> Fix GPIO comment to be consistent with rest of file and add comment what
> tpa6130 is.
>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> index bfffd6c..ca9fe8c 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -47,7 +47,7 @@
> compatible = "gpio-leds";
> heartbeat {
> label = "debug::sleep";
> - gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; /* gpio162 */
> + gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; /* 162 */
> linux,default-trigger = "default-on";
> pinctrl-names = "default";
> pinctrl-0 = <&debug_leds>;
> @@ -637,6 +637,7 @@
> reg = <0x55>;
> };
>
> + /* Stereo headphone amplifier */
> tpa6130a2: tpa6130a2 at 60 {
> compatible = "ti,tpa6130a2";
> reg = <0x60>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/6681dd12/attachment.sig>
^ permalink raw reply
* [PATCH 03/12] power_supply: axp288_charger: Replace the extcon API
From: Sebastian Reichel @ 2016-12-07 3:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <584605A6.1010803@samsung.com>
Hi Chanwoo,
On Tue, Dec 06, 2016 at 09:26:14AM +0900, Chanwoo Choi wrote:
> Could you please review and pick the patch3/4 for power-supply driver?
Patches look fine. As I expect the merge window to open next week I
would rather not queue this for 4.10 and instead do it once 4.10-rc1
has been tagged.
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161207/8511f8ce/attachment.sig>
^ permalink raw reply
* [PATCH 7/7] arm: Add livepatch necessary arch selects into Kconfig
From: Steven Rostedt @ 2016-12-07 2:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-8-git-send-email-abelvesa@linux.com>
On Tue, 6 Dec 2016 17:06:07 +0000
Abel Vesa <abelvesa@linux.com> wrote:
> This adds HAVE_LIVEPATCH, MODULES_USE_ELF_RELA and HAVE_LIVEPATCH
> to arm Kconfig.
>
> Signed-off-by: Abel Vesa <abelvesa@linux.com>
Patch 5, 6 and 7 really ought to be one patch.
-- Steve
^ permalink raw reply
* [PATCH 4/7] arm: Add ftrace with regs support
From: Steven Rostedt @ 2016-12-07 2:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481043967-15602-5-git-send-email-abelvesa@linux.com>
On Tue, 6 Dec 2016 17:06:04 +0000
Abel Vesa <abelvesa@linux.com> wrote:
> This adds __ftrace_regs_caller which, unlike __ftrace_caller,
> adds register saving/restoring and livepatch handling if
> the pc register gets modified by klp_ftrace_handler.
>
> Signed-off-by: Abel Vesa <abelvesa@linux.com>
> ---
> arch/arm/kernel/entry-ftrace.S | 49
> ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49
> insertions(+)
>
> diff --git a/arch/arm/kernel/entry-ftrace.S
> b/arch/arm/kernel/entry-ftrace.S index c73c403..b6ada5c 100644
> --- a/arch/arm/kernel/entry-ftrace.S
> +++ b/arch/arm/kernel/entry-ftrace.S
> @@ -92,6 +92,46 @@
> 2: mcount_exit
> .endm
>
> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
> +
> +.macro __ftrace_regs_caller suffix
> +
> + stmdb sp!, {r0-r15}
> + mov r3, sp
> +
> + ldr r10, [sp, #60]
> +
> + mcount_get_lr r1 @ lr of instrumented
> func
> + mcount_adjust_addr r0, lr @
> instrumented function +
> + .globl ftrace_regs_call\suffix
> +ftrace_regs_call\suffix:
> + bl ftrace_stub
> +
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> + .globl ftrace_regs_graph_call\suffix
> +ftrace_regs_graph_call\suffix:
> + mov r0, r0
> +#endif
So basically what the below does is to undo the mcount prologue and
recall the new function as the old function is called.
> +#ifdef CONFIG_LIVEPATCH
> + ldr r0, [sp, #60]
> + cmp r0, r10
> + beq ftrace_regs_caller_end
> + ldmia sp!, {r0-r12}
> + add sp, sp, #8
> + ldmia sp!, {r11}
> + sub sp, r12, #16
> + str r11, [sp, #12]
> + ldmia sp!, {r11, r12, lr, pc}
But the above really could do with a lot of comments to explain exactly
what it is doing.
I don't condemn or condone this code. I'm just happy I don't have to
maintain it.
-- Steve
> +#endif
> +ftrace_regs_caller_end\suffix:
> + ldmia sp!, {r0-r14}
> + add sp, sp, #4
> + mov pc, lr
> +.endm
> +
> +#endif
> +
> .macro __ftrace_caller suffix
> mcount_enter
>
> @@ -212,6 +252,15 @@ UNWIND(.fnstart)
> __ftrace_caller
> UNWIND(.fnend)
> ENDPROC(ftrace_caller)
> +
> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
> +ENTRY(ftrace_regs_caller)
> +UNWIND(.fnstart)
> + __ftrace_regs_caller
> +UNWIND(.fnend)
> +ENDPROC(ftrace_regs_caller)
> +#endif
> +
> #endif
>
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
^ permalink raw reply
* [PATCH] spi: davinci: Allow device tree devices to use DMA
From: David Lechner @ 2016-12-07 2:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fd697f3b-dba1-1e5f-c12c-45f71c0c07a1@ti.com>
On 11/21/2016 02:37 AM, Sekhar Nori wrote:
> On Sunday 20 November 2016 10:31 PM, David Lechner wrote:
>
>> On 11/20/2016 06:59 AM, Sekhar Nori wrote:
>
>>> On Saturday 19 November 2016 10:11 AM, David Lechner wrote:
>
>>>> @@ -400,6 +401,9 @@ static int davinci_spi_of_setup(struct spi_device
>>>> *spi)
>>>> if (!of_property_read_u32(np, "ti,spi-wdelay", &prop))
>>>> spicfg->wdelay = (u8)prop;
>>>> spi->controller_data = spicfg;
>>>> + /* Use DMA for device if master supports it */
>>>> + if (dspi->dma_rx)
>>>
>>> This should be
>>>
>>> if (!(IS_ERR(dpsi->dma_rx) || IS_ERR(dspi->dma_tx))
>>
>>
>> There is the following code in davinci_spi_probe():
>>
>> ret = davinci_spi_request_dma(dspi);
>> if (ret == -EPROBE_DEFER) {
>> goto free_clk;
>> } else if (ret) {
>> dev_info(&pdev->dev, "DMA is not supported (%d)\n", ret);
>> dspi->dma_rx = NULL;
>> dspi->dma_tx = NULL;
>> }
>>
>> So, I does not look like it is possible to get anything other than NULL
>> or a valid pointer for dpsi->dma_rx and that checking dpsi->dma_tx is
>> not necessary.
>>
>> So, I think if (dspi->dma_rx) is sufficient. In fact the same check is
>> used during unwinding if the probe function fails.
>
> You are right, I see it now. Setting dma_rx to NULL overriding the error
> value is confusing since dma_request_chan() itself does not use NULL as
> an error value.
>
> I think it is better to fix the existing code to remove the NULL
> overwrite and use IS_ERR() instead. You should probably wait for some
> feedback from the SPI maintainer though.
>
> Thanks,
> Sekhar
>
There don't seem to be any further comments. Using NULL here makes more
sense to me, so I am inclined to leave this patch as-is.
^ permalink raw reply
* [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
From: Chen-Yu Tsai @ 2016-12-07 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206172911.z6sbjzgqv3vfcrfh@lukather>
On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
>> The panels shipped with Allwinner devices are very "generic", i.e.
>> they do not have model numbers or reliable sources of information
>> for the timings (that we know of) other than the fex files shipped
>> on them. The dot clock frequency provided in the fex files have all
>> been rounded to the nearest MHz, as that is the unit used in them.
>>
>> We were using the simple panel "urt,umsh-8596md-t" as a substitute
>> for the A13 Q8 tablets in the absence of a specific model for what
>> may be many different but otherwise timing compatible panels. This
>> was usable without any visual artifacts or side effects, until the
>> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
>> rgb: Validate the clock rate").
>>
>> The reason this check fails is because the dotclock frequency for
>> this model is 33.26 MHz, which is not achievable with our dot clock
>> hardware, and the rate returned by clk_round_rate deviates slightly,
>> causing the driver to reject the display mode.
>>
>> The LCD panels have some tolerance on the dot clock frequency, even
>> if it's not specified in their datasheets.
>>
>> This patch adds a 5% tolerence to the dot clock check.
>
> As we discussed already, I really believe this is just as arbitrary as
> the current behaviour.
Yes. I agree. This patch is mainly to give something that works for
people who don't care about the details, and to get some feedback
from people that do.
>
> Some panels require an exact frequency, some have a minimal frequency
> but no maximum, some have a maximum frequency but no minimal, and I
> guess most of them deviates by how much exactly they can take (and
> possibly can take more easily a higher frequency, but are less
> tolerant if you take a frequency lower than the nominal.
>
> And we cannot remove that check entirely, since some bridges will
> report out of range frequencies for higher modes that we know we
> cannot reach.
I believe this should be handled by the bridge driver in the check
callback? The callback I'm changing is attached to the connector,
which I think doesn't get used if you have a bridge instead.
And this only checks the pre-registered display modes, such as
those specified in simple-panel or EDID.
> We could just try to see if the screen pixel clock frequency is out of
> the pixel clock range we can generate, but then we will loop back on
> how much out of range is it exactly, and is it within the screen
> tolerancy.
>
> We have an API to deal with the panel tolerancies in the DRM panel
> framework, we can (and should) use it.
If you mean the get_timings callback, it's not very useful. Most of
the panels in simple-panel do not use the display_timings structure,
so they don't return anything. And I get that. The few datasheets
I found don't list min/max tolerances for the dotclock.
The ones that do have the min/max the same as the recommended value.
This may or may not be accurate. IIRC the one panel that had this
that I did check didn't list min/max values in its datasheet.
>
> I'm not sure how others usually deal with this though. I think I
> remember Eric telling me that for the RPi they just adjusted the
> timings a bit, but they only really had a single panel to deal with.
>
> Daniel, Eric, Laurent, Sean? Any ideas?
Yes! Feedback please! Between Maxime and me I think we only have a
limited number of panels, with some overlap.
Regards
ChenYu
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH 3/3] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Florian Fainelli @ 2016-12-07 2:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a50d7d1b-643f-cf17-b38f-475916c971c1@redhat.com>
On 12/06/2016 06:00 PM, Laura Abbott wrote:
>> @@ -261,6 +261,16 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
>> ((((unsigned long)(kaddr) - PAGE_OFFSET) >> PAGE_SHIFT) + \
>> PHYS_PFN_OFFSET)
>>
>> +#define __pa_symbol_nodebug(x) ((x) - (unsigned long)KERNEL_START)
>
> On arm64 the kernel image lives in a separate linear offset. arm doesn't
> do anything like that so __phys_addr_symbol should just be the regular
> __virt_to_phys
Yep, which is what I have queued locally now too, thanks!
>> +static inline bool __virt_addr_valid(unsigned long x)
>> +{
>> + if (x < PAGE_OFFSET)
>> + return false;
>> + if (arm_lowmem_limit && is_vmalloc_or_module_addr((void *)x))
>> + return false;
>> + if (x >= FIXADDR_START && x < FIXADDR_END)
>> + return false;
>> + return true;
>> +}
>
> I'd rather see this return true for only the linear range and
> reject everything else. asm/memory.h already has
>
> #define virt_addr_valid(kaddr) (((unsigned long)(kaddr) >= PAGE_OFFSET && (unsigned long)(kaddr) < (unsigned long)high_memory) \
> && pfn_valid(virt_to_pfn(kaddr)))
>
> So we can make the check x >= PAGE_OFFSET && x < high_memory
OK that's simpler indeed. I did the check this way because we have early
callers of __pa() from drivers/of/fdt.c, in particular MIN_MEMBLOCK_ADDR
there, and we also have pcpu_dfl_fc_alloc which uses DMA_MAX_ADDR (which
is 0xffff_ffff on my platform).
>> +static inline bool __phys_addr_valid(unsigned long x)
>> +{
>> + /* This is bounds checking against the kernel image only.
>> + * __pa_symbol should only be used on kernel symbol addresses.
>> + */
>> + if (x < (unsigned long)KERNEL_START ||
>> + x > (unsigned long)KERNEL_END)
>> + return false;
>> +
>> + return true;
>> +}
>
> This is a confusing name for this function, it's not checking if
> a physical address is valid, it's checking if a virtual address
> corresponding to a kernel symbol is valid.
I have removed it and just moved the check within VIRTUAL_BUG_ON().
Thanks!
--
Florian
^ permalink raw reply
* [PATCH] arm: dts: rockchip: add qos node for rk3288
From: Elaine Zhang @ 2016-12-07 2:17 UTC (permalink / raw)
To: linux-arm-kernel
when pd power on/off, the qos regs need to save and restore.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
arch/arm/boot/dts/rk3288.dtsi | 84 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 84 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 4fad13368a7b..2628edc871fa 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -699,6 +699,76 @@
reg = <0xff720000 0x1000>;
};
+ qos_gpu_r: qos at ffaa0000 {
+ compatible = "syscon";
+ reg = <0xffaa0000 0x20>;
+ };
+
+ qos_gpu_w: qos at ffaa0080 {
+ compatible = "syscon";
+ reg = <0xffaa0080 0x20>;
+ };
+
+ qos_vio1_vop: qos at ffad0000 {
+ compatible = "syscon";
+ reg = <0xffad0000 0x20>;
+ };
+
+ qos_vio1_isp_w0: qos at ffad0100 {
+ compatible = "syscon";
+ reg = <0xffad0100 0x20>;
+ };
+
+ qos_vio1_isp_w1: qos at ffad0180 {
+ compatible = "syscon";
+ reg = <0xffad0180 0x20>;
+ };
+
+ qos_vio0_vop: qos at ffad0400 {
+ compatible = "syscon";
+ reg = <0xffad0400 0x20>;
+ };
+
+ qos_vio0_vip: qos at ffad0480 {
+ compatible = "syscon";
+ reg = <0xffad0480 0x20>;
+ };
+
+ qos_vio0_iep: qos at ffad0500 {
+ compatible = "syscon";
+ reg = <0xffad0500 0x20>;
+ };
+
+ qos_vio2_rga_r: qos at ffad0800 {
+ compatible = "syscon";
+ reg = <0xffad0800 0x20>;
+ };
+
+ qos_vio2_rga_w: qos at ffad0880 {
+ compatible = "syscon";
+ reg = <0xffad0880 0x20>;
+ };
+
+ qos_vio1_isp_r: qos at ffad0900 {
+ compatible = "syscon";
+ reg = <0xffad0900 0x20>;
+ };
+
+ qos_video: qos at ffae0000 {
+ compatible = "syscon";
+ reg = <0xffae0000 0x20>;
+ };
+
+ qos_hevc_r: qos at ffaf0000 {
+ compatible = "syscon";
+ reg = <0xffaf0000 0x20>;
+ };
+
+ qos_hevc_w: qos at ffaf0080 {
+ compatible = "syscon";
+ reg = <0xffaf0080 0x20>;
+ };
+
pmu: power-management at ff730000 {
compatible = "rockchip,rk3288-pmu", "syscon", "simple-mfd";
reg = <0xff730000 0x100>;
@@ -762,6 +832,15 @@
<&cru SCLK_ISP_JPE>,
<&cru SCLK_ISP>,
<&cru SCLK_RGA>;
+ pm_qos = <&qos_vio0_iep>,
+ <&qos_vio1_vop>,
+ <&qos_vio1_isp_w0>,
+ <&qos_vio1_isp_w1>,
+ <&qos_vio0_vop>,
+ <&qos_vio0_vip>,
+ <&qos_vio2_rga_r>,
+ <&qos_vio2_rga_w>,
+ <&qos_vio1_isp_r>;
};
/*
@@ -773,6 +852,8 @@
clocks = <&cru ACLK_HEVC>,
<&cru SCLK_HEVC_CABAC>,
<&cru SCLK_HEVC_CORE>;
+ pm_qos = <&qos_hevc_r>,
+ <&qos_hevc_w>;
};
/*
@@ -784,6 +865,7 @@
reg = <RK3288_PD_VIDEO>;
clocks = <&cru ACLK_VCODEC>,
<&cru HCLK_VCODEC>;
+ pm_qos = <&qos_video>;
};
/*
@@ -793,6 +875,8 @@
pd_gpu at RK3288_PD_GPU {
reg = <RK3288_PD_GPU>;
clocks = <&cru ACLK_GPU>;
+ pm_qos = <&qos_gpu_r>,
+ <&qos_gpu_w>;
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 12/16] drivers/fsi: Set up links for slave communication
From: Chris Bostic @ 2016-12-07 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481076574-54711-1-git-send-email-christopher.lee.bostic@gmail.com>
From: Chris Bostic <cbostic@us.ibm.com>
Enable each link and send a break command in preparation
for scanning each link for slaves.
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
drivers/fsi/fsi-core.c | 39 ++++++++++++++++++++++++++++++++++++---
drivers/fsi/fsi-master.h | 2 ++
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index 80feeb8..93de0f1 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -290,16 +290,49 @@ static int fsi_slave_init(struct fsi_master *master,
/* FSI master support */
+static int fsi_master_link_enable(struct fsi_master *master, int link)
+{
+ if (master->link_enable)
+ return master->link_enable(master, link);
+
+ return 0;
+}
+
+/*
+ * Issue a break command on this link
+ */
+static int fsi_master_break(struct fsi_master *master, int link)
+{
+ if (master->send_break)
+ return master->send_break(master, link);
+
+ return 0;
+}
+
static int fsi_master_scan(struct fsi_master *master)
{
- int link, slave_id;
+ int link, slave_id, rc;
+
+ for (link = 0; link < master->n_links; link++) {
+ rc = fsi_master_link_enable(master, link);
+ if (rc) {
+ dev_dbg(master->dev,
+ "enable link:%d failed with:%d\n", link, rc);
+ continue;
+ }
+ rc = fsi_master_break(master, link);
+ if (rc) {
+ dev_dbg(master->dev,
+ "Break to link:%d failed with:%d\n", link, rc);
+ continue;
+ }
- for (link = 0; link < master->n_links; link++)
for (slave_id = 0; slave_id < FSI_N_SLAVES; slave_id++)
fsi_slave_init(master, link, slave_id);
- return 0;
+ }
+ return 0;
}
int fsi_master_register(struct fsi_master *master)
diff --git a/drivers/fsi/fsi-master.h b/drivers/fsi/fsi-master.h
index cafb433..56aad0e 100644
--- a/drivers/fsi/fsi-master.h
+++ b/drivers/fsi/fsi-master.h
@@ -29,6 +29,8 @@ struct fsi_master {
int (*write)(struct fsi_master *, int link,
uint8_t slave, uint32_t addr,
const void *val, size_t size);
+ int (*send_break)(struct fsi_master *, int link);
+ int (*link_enable)(struct fsi_master *, int link);
};
extern int fsi_master_register(struct fsi_master *master);
--
1.8.2.2
^ permalink raw reply related
* [PATCH 11/16] drivers/fsi: Add device read/write/peek functions
From: Chris Bostic @ 2016-12-07 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481076574-54711-1-git-send-email-christopher.lee.bostic@gmail.com>
From: Jeremy Kerr <jk@ozlabs.org>
This change introduces the fsi device API: simple read, write and peek
accessors for the devices' address spaces.
Includes contributions from Chris Bostic <cbostic@us.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
drivers/fsi/fsi-core.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/fsi.h | 7 ++++++-
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index b51ea35..80feeb8 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -33,6 +33,8 @@
#define FSI_SLAVE_CONF_CRC_MASK 0x0000000f
#define FSI_SLAVE_CONF_DATA_BITS 28
+#define FSI_PEEK_BASE 0x410
+
static const int engine_page_size = 0x400;
static atomic_t master_idx = ATOMIC_INIT(-1);
@@ -46,8 +48,46 @@ struct fsi_slave {
#define to_fsi_slave(d) container_of(d, struct fsi_slave, dev)
+static int fsi_slave_read(struct fsi_slave *slave, uint32_t addr,
+ void *val, size_t size);
+static int fsi_slave_write(struct fsi_slave *slave, uint32_t addr,
+ const void *val, size_t size);
+
/* FSI endpoint-device support */
+int fsi_device_read(struct fsi_device *dev, uint32_t addr, void *val,
+ size_t size)
+{
+ if (addr > dev->size)
+ return -EINVAL;
+
+ if (addr + size > dev->size)
+ return -EINVAL;
+
+ return fsi_slave_read(dev->slave, dev->addr + addr, val, size);
+}
+EXPORT_SYMBOL_GPL(fsi_device_read);
+
+int fsi_device_write(struct fsi_device *dev, uint32_t addr, const void *val,
+ size_t size)
+{
+ if (addr > dev->size)
+ return -EINVAL;
+
+ if (addr + size > dev->size)
+ return -EINVAL;
+
+ return fsi_slave_write(dev->slave, dev->addr + addr, val, size);
+}
+EXPORT_SYMBOL_GPL(fsi_device_write);
+
+int fsi_device_peek(struct fsi_device *dev, void *val)
+{
+ uint32_t addr = FSI_PEEK_BASE + ((dev->unit - 2) * sizeof(uint32_t));
+
+ return fsi_slave_read(dev->slave, addr, val, sizeof(uint32_t));
+}
+
static void fsi_device_release(struct device *_device)
{
struct fsi_device *device = to_fsi_dev(_device);
@@ -100,6 +140,13 @@ static int fsi_slave_read(struct fsi_slave *slave, uint32_t addr,
slave->id, addr, val, size);
}
+static int fsi_slave_write(struct fsi_slave *slave, uint32_t addr,
+ const void *val, size_t size)
+{
+ return slave->master->write(slave->master, slave->link,
+ slave->id, addr, val, size);
+}
+
static int fsi_slave_scan(struct fsi_slave *slave)
{
uint32_t engine_addr;
diff --git a/include/linux/fsi.h b/include/linux/fsi.h
index efa55ba..66bce48 100644
--- a/include/linux/fsi.h
+++ b/include/linux/fsi.h
@@ -27,6 +27,12 @@ struct fsi_device {
uint32_t size;
};
+extern int fsi_device_read(struct fsi_device *dev, uint32_t addr,
+ void *val, size_t size);
+extern int fsi_device_write(struct fsi_device *dev, uint32_t addr,
+ const void *val, size_t size);
+extern int fsi_device_peek(struct fsi_device *dev, void *val);
+
struct fsi_device_id {
u8 engine_type;
u8 version;
@@ -40,7 +46,6 @@ struct fsi_device_id {
#define FSI_DEVICE_VERSIONED(t, v) \
.engine_type = (t), .version = (v),
-
struct fsi_driver {
struct device_driver drv;
const struct fsi_device_id *id_table;
--
1.8.2.2
^ permalink raw reply related
* [PATCH 09/16] drivers/fsi: Implement slave initialisation
From: Chris Bostic @ 2016-12-07 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481076574-54711-1-git-send-email-christopher.lee.bostic@gmail.com>
From: Jeremy Kerr <jk@ozlabs.org>
Create fsi_slave devices during the master scan.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
---
drivers/fsi/fsi-core.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c
index f0832c7..aa4330a 100644
--- a/drivers/fsi/fsi-core.c
+++ b/drivers/fsi/fsi-core.c
@@ -16,10 +16,14 @@
#include <linux/device.h>
#include <linux/fsi.h>
#include <linux/module.h>
+#include <linux/slab.h>
#include "fsi-master.h"
#define FSI_N_SLAVES 4
+#define FSI_SLAVE_CONF_CRC_SHIFT 4
+#define FSI_SLAVE_CONF_CRC_MASK 0x0000000f
+#define FSI_SLAVE_CONF_DATA_BITS 28
static atomic_t master_idx = ATOMIC_INIT(-1);
@@ -54,12 +58,59 @@ uint8_t fsi_crc4(uint8_t c, uint64_t x, int bits)
EXPORT_SYMBOL_GPL(fsi_crc4);
/* FSI slave support */
+
+static void fsi_slave_release(struct device *dev)
+{
+ struct fsi_slave *slave = to_fsi_slave(dev);
+
+ kfree(slave);
+}
+
static int fsi_slave_init(struct fsi_master *master,
int link, uint8_t slave_id)
{
- /* todo: initialise slave device, perform engine scan */
+ struct fsi_slave *slave;
+ uint32_t chip_id;
+ int rc;
+ uint8_t crc;
+
+ rc = master->read(master, link, slave_id, 0, &chip_id, sizeof(chip_id));
+ if (rc) {
+ dev_warn(master->dev, "can't read slave %02x:%02x: %d\n",
+ link, slave_id, rc);
+ return -ENODEV;
+ }
+ crc = fsi_crc4(0, chip_id >> FSI_SLAVE_CONF_CRC_SHIFT,
+ FSI_SLAVE_CONF_DATA_BITS);
+ if (crc != (chip_id & FSI_SLAVE_CONF_CRC_MASK)) {
+ dev_warn(master->dev, "slave %02x:%02x invalid chip id CRC!\n",
+ link, slave_id);
+ return -EIO;
+ }
+
+ pr_debug("fsi: found chip %08x at %02x:%02x:%02x\n",
+ master->idx, chip_id, link, slave_id);
+
+ /* we can communicate with a slave; create devices and scan */
+ slave = kzalloc(sizeof(*slave), GFP_KERNEL);
+ if (!slave)
+ return -ENOMEM;
+
+ slave->master = master;
+ slave->id = slave_id;
+ slave->dev.parent = master->dev;
+ slave->dev.release = fsi_slave_release;
+
+ dev_set_name(&slave->dev, "slave@%02x:%02x", link, slave_id);
+ rc = device_register(&slave->dev);
+ if (rc < 0) {
+ dev_warn(master->dev, "failed to create slave device: %d\n",
+ rc);
+ put_device(&slave->dev);
+ return rc;
+ }
- return -ENODEV;
+ return rc;
}
/* FSI master support */
--
1.8.2.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox