* [PATCH] Input: misc: gpio_tilt: Delete driver
From: Dmitry Torokhov @ 2018-01-02 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14171345.p7a3jPx4Si@phil>
On Wed, Dec 27, 2017 at 02:51:45PM +0100, Heiko Stuebner wrote:
> Hi Linus,
>
> Am Mittwoch, 27. Dezember 2017, 13:15:47 CET schrieb Linus Walleij:
> > This driver was merged in 2011 as a tool for detecting the orientation
> > of a screen. The device driver assumes board file setup using the
> > platform data from <linux/input/gpio_tilt.h>. But no boards in the
> > kernel tree defines this platform data.
> >
> > As I am faced with refactoring drivers to use GPIO descriptors and
> > pass decriptor tables from boards, or use the device tree device
> > drivers like these creates a serious problem: I cannot fix them and
> > cannot test them, not even compile-test them with a system actually
> > using it (no in-tree boardfile).
> >
> > I suggest to delete this driver and rewrite it using device tree if
> > it is still in use on actively maintained systems.
> >
> > I can also offer to rewrite it out of the blue using device tree if
> > someone promise to test it and help me iterate it.
> >
> > Cc: Heiko St?bner <heiko@sntech.de>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > Heiko: not meaning to be militant here, just contain the situation,
> > as stated: if you like the driver and can test it, I can reimplement
> > it from scratch using device tree.
>
> It seems that piece of hardware (gpio-connected orientation-sensors)
> was really only used in the one s3c24xx-based device I hacked on in 2011.
>
> I somehow lost focus from trying to do the s3c24xx devicetree migration
> when I started hacking on Rockchip stuff, so while I do have the devices
> still around, I don't think I'll find the time and energy trying to get a
> recent kernel to run on them anyway, so I'm fine with dropping the driver.
> It's simple enough to get reintroduced if someone really finds a device
> using it or time to redo the ereader support using devicetree.
>
> So long story short
> Acked-by: Heiko Stuebner <heiko@sntech.de>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH v2 0/4] arm64: defconfig: enable additional led triggers
From: Amit Kucheria @ 2018-01-02 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a0+4ACDucmNQ3OL_0UjJnK6d3JXOb6_z5jtMQ986uZkLQ@mail.gmail.com>
On Thu, Dec 21, 2017 at 8:46 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Dec 6, 2017 at 9:57 AM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>> (Adding Arnd)
>>
>> Now that the merge window rush has abated, can you please apply this
>> trivial series?
>>
>> On Mon, Nov 6, 2017 at 12:38 PM, Amit Kucheria <amit.kucheria@linaro.org> wrote:
>>> This patchset enables the kernel panic and disk-activity trigger for LEDs
>>> and then enables the panic trigger for three 96Boards - DB410c, Hikey and
>>> Hikey960.
>>>
>>> DB410c and Hikey panic behaviour has been tested by triggering a panic
>>> through /proc/sysrq-trigger, while Hikey960 is only compile-tested.
>
> I applied all four now, but it would have been easier for me if you had either
> sent them to the platform maintainers, or to arm at kernel.org.
The platform maintainers are cc'ed but I guess nobody took them since
the patchset touched 3 different platforms and a common defconfig.
I'll remember to cc arm at kernel.org in the future but is there any
reason why this email address isn't listed in MAINTAINERS?
Thanks for applying the patches.
Wish you a Happy New Year.
Regards,
Amit
^ permalink raw reply
* [PATCH v7 02/11] thermal: armada: Use msleep for long delays
From: Miquel RAYNAL @ 2018-01-02 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180101205537.GA29474@localhost.localdomain>
Hello Eduardo,
On Mon, 1 Jan 2018 12:55:39 -0800
Eduardo Valentin <edubezval@gmail.com> wrote:
> On Fri, Dec 22, 2017 at 05:14:04PM +0100, Miquel Raynal wrote:
> > From: Baruch Siach <baruch@tkos.co.il>
> >
> > Use msleep for long (> 10ms) delays, instead of the busy waiting
> > mdelay. All delays are called from the probe routine, where
> > scheduling is allowed.
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> > Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> I am queueing this patch, however, ...
>
> > ---
> > drivers/thermal/armada_thermal.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index 706d74798cbe..6c4af2622d4f
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -113,7 +113,7 @@ static void armada370_init_sensor(struct
> > platform_device *pdev, reg &= ~PMU_TDC0_START_CAL_MASK;
> > writel(reg, priv->control);
> >
> > - mdelay(10);
> > + msleep(10);
>
> I want to double check with you that msleep(10) is documented to reach
> up to 20ms, see:
>
>
> WARNING: msleep < 20ms can sleep for up to 20ms; see
> Documentation/timers/timers-howto.txt #43: FILE:
> drivers/thermal/armada_thermal.c:116:
> + msleep(10);
>
> WARNING: msleep < 20ms can sleep for up to 20ms; see
> Documentation/timers/timers-howto.txt #66: FILE:
> drivers/thermal/armada_thermal.c:146:
> + msleep(10);
>
> Just want to check that you are aware of this and that it won't cause
> troubles in the code flows changed in this patch. Driver is still in
> one piece, correct?
Thanks for queueing the series.
All of these delays are here to ensure that we do wait a minimum
amount of time to let the hardware be ready, IMHO waiting up to 20ms is
not an issue.
Best regards,
Miqu?l
>
> > }
> >
> > static void armada375_init_sensor(struct platform_device *pdev,
> > @@ -127,11 +127,11 @@ static void armada375_init_sensor(struct
> > platform_device *pdev, reg &= ~A375_HW_RESETn;
> >
> > writel(reg, priv->control + 4);
> > - mdelay(20);
> > + msleep(20);
> >
> > reg |= A375_HW_RESETn;
> > writel(reg, priv->control + 4);
> > - mdelay(50);
> > + msleep(50);
> > }
> >
> > static void armada380_init_sensor(struct platform_device *pdev,
> > @@ -143,7 +143,7 @@ static void armada380_init_sensor(struct
> > platform_device *pdev, if (!(reg & A380_HW_RESET)) {
> > reg |= A380_HW_RESET;
> > writel(reg, priv->control);
> > - mdelay(10);
> > + msleep(10);
> > }
> > }
> >
> > --
> > 2.11.0
> >
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH v2] pciehp: fix a race between pciehp and removing operations by sysfs
From: Xiongfeng Wang @ 2018-01-02 7:52 UTC (permalink / raw)
To: linux-arm-kernel
From: Xiongfeng Wang <xiongfeng.wang@linaro.com>
When I run a stress test about pcie hotplug and removing operations by
sysfs, I got a hange task, and the following call trace is printed.
INFO: task kworker/0:2:4413 blocked for more than 120 seconds.
Tainted: P W O 4.12.0-rc1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:2 D 0 4413 2 0x00000000
Workqueue: pciehp-0 pciehp_power_thread
Call trace:
[<ffff0000080861d4>] __switch_to+0x94/0xa8
[<ffff000008bea9c0>] __schedule+0x1b0/0x708
[<ffff000008beaf58>] schedule+0x40/0xa4
[<ffff000008beb33c>] schedule_preempt_disabled+0x28/0x40
[<ffff000008bec1dc>] __mutex_lock.isra.8+0x148/0x50c
[<ffff000008bec5c4>] __mutex_lock_slowpath+0x24/0x30
[<ffff000008bec618>] mutex_lock+0x48/0x54
[<ffff0000084d8188>] pci_lock_rescan_remove+0x20/0x28
[<ffff0000084f87c0>] pciehp_unconfigure_device+0x54/0x1cc
[<ffff0000084f8260>] pciehp_disable_slot+0x4c/0xbc
[<ffff0000084f8370>] pciehp_power_thread+0xa0/0xb8
[<ffff0000080e9ce8>] process_one_work+0x13c/0x3f8
[<ffff0000080ea004>] worker_thread+0x60/0x3e4
[<ffff0000080f0814>] kthread+0x10c/0x138
[<ffff0000080836c0>] ret_from_fork+0x10/0x50
INFO: task bash:31732 blocked for more than 120 seconds.
Tainted: P W O 4.12.0-rc1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash D 0 31732 1 0x00000009
Call trace:
[<ffff0000080861d4>] __switch_to+0x94/0xa8
[<ffff000008bea9c0>] __schedule+0x1b0/0x708
[<ffff000008beaf58>] schedule+0x40/0xa4
[<ffff000008bee7b4>] schedule_timeout+0x1a0/0x340
[<ffff000008bebb88>] wait_for_common+0x108/0x1bc
[<ffff000008bebc64>] wait_for_completion+0x28/0x34
[<ffff0000080e7594>] flush_workqueue+0x130/0x488
[<ffff0000080e79b0>] drain_workqueue+0xc4/0x164
[<ffff0000080ec3cc>] destroy_workqueue+0x28/0x1f4
[<ffff0000084fa094>] pciehp_release_ctrl+0x34/0xe0
[<ffff0000084f75b0>] pciehp_remove+0x30/0x3c
[<ffff0000084f24d8>] pcie_port_remove_service+0x3c/0x54
[<ffff00000876b1e4>] device_release_driver_internal+0x150/0x1d0
[<ffff00000876b28c>] device_release_driver+0x28/0x34
[<ffff00000876a018>] bus_remove_device+0xe0/0x11c
[<ffff000008766348>] device_del+0x200/0x304
[<ffff00000876646c>] device_unregister+0x20/0x38
[<ffff0000084f2560>] remove_iter+0x44/0x54
[<ffff000008765230>] device_for_each_child+0x4c/0x90
[<ffff0000084f2c98>] pcie_port_device_remove+0x2c/0x48
[<ffff0000084f2f48>] pcie_portdrv_remove+0x60/0x6c
[<ffff0000084e3de4>] pci_device_remove+0x48/0x110
[<ffff00000876b1e4>] device_release_driver_internal+0x150/0x1d0
[<ffff00000876b28c>] device_release_driver+0x28/0x34
[<ffff0000084db028>] pci_stop_bus_device+0x9c/0xac
[<ffff0000084db190>] pci_stop_and_remove_bus_device_locked+0x24/0x3c
[<ffff0000084e5eb0>] remove_store+0x74/0x80
[<ffff000008764680>] dev_attr_store+0x44/0x5c
[<ffff0000082e7e1c>] sysfs_kf_write+0x5c/0x74
[<ffff0000082e7014>] kernfs_fop_write+0xcc/0x1dc
[<ffff0000082602e0>] __vfs_write+0x48/0x13c
[<ffff00000826174c>] vfs_write+0xa8/0x198
[<ffff000008262ce8>] SyS_write+0x54/0xb0
[<ffff000008083730>] el0_svc_naked+0x24/0x28
There is a race condition between these two kinds of operations.
When the Attention button on a PCIE slot is pressed, 5 seconds later,
pciehp_power_thread() will be scheduled on slot->wq. This function will
call pciehp_unconfigure_device(), which will try to get a global mutex
lock 'pci_rescan_remove_lock'.
At the same time, we remove the pcie port by sysfs, which results in
pci_stop_and_remove_bus_device_locked() called. This function will get
the global mutex lock 'pci_rescan_remove_lock', and then release the
struct 'ctrl', which will wait until the work_struct on slot->wq is
finished.
If pci_stop_and_remove_bus_device_locked() got the mutex lock, and
before it drains workqueue slot->wq, pciehp_power_thread() is scheduled
on slot->wq and tries to get the mutex lock but failed, so it will just
wait. Then pci_stop_and_remove_bus_device_locked() tries to drain workqueue
slot->wq and wait until work struct 'pciehp_power_thread()' is finished.
Then a hung_task occurs.
So this two kinds of operation, removing through attention buttion and
removing through /sys/devices/pci***/remove, should not be excuted at the
same time. This patch add a global variable to mark that one of these
operations is under processing. When this variable is set, if another
operation is requested, it will be rejected.
At first, I want to add a flag for each pci slot to record whether a
removing operation is under processing. When a bridge is being removed,
the flags of all the slots below the bridge need to be checked. But it
is hard for us to guarantee the atomic access. So I just use a global
flag.
This workaround method uses a global flag, which is not good for the code
framework and can't fix the race condition fully. But I can't figure out
a better way. I think we may need to reconstruct the code framework a lot
to fix this issue nicely. There are so many work struct created. Before
that, maybe we can use this patch as a temporary fix.
Signed-off-by: Xiongfeng Wang <xiongfeng.wang@linaro.org>
---
drivers/pci/hotplug/pciehp_ctrl.c | 7 +++++++
drivers/pci/hotplug/pciehp_hpc.c | 12 +++++++++++-
drivers/pci/pci-sysfs.c | 11 +++++++++--
drivers/pci/remove.c | 6 ++++++
include/linux/pci.h | 3 +++
5 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c b/drivers/pci/hotplug/pciehp_ctrl.c
index 83f3d4a..5680439 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -44,6 +44,7 @@ void pciehp_queue_interrupt_event(struct slot *p_slot, u32 event_type)
info = kmalloc(sizeof(*info), GFP_ATOMIC);
if (!info) {
ctrl_err(p_slot->ctrl, "dropped event %d (ENOMEM)\n", event_type);
+ slot_being_removed_rescanned = 0;
return;
}
@@ -188,6 +189,7 @@ static void pciehp_power_thread(struct work_struct *work)
mutex_lock(&p_slot->lock);
p_slot->state = STATIC_STATE;
mutex_unlock(&p_slot->lock);
+ slot_being_removed_rescanned = 0;
break;
case ENABLE_REQ:
mutex_lock(&p_slot->hotplug_lock);
@@ -198,6 +200,7 @@ static void pciehp_power_thread(struct work_struct *work)
mutex_lock(&p_slot->lock);
p_slot->state = STATIC_STATE;
mutex_unlock(&p_slot->lock);
+ slot_being_removed_rescanned = 0;
break;
default:
break;
@@ -216,6 +219,7 @@ static void pciehp_queue_power_work(struct slot *p_slot, int req)
if (!info) {
ctrl_err(p_slot->ctrl, "no memory to queue %s request\n",
(req == ENABLE_REQ) ? "poweron" : "poweroff");
+ slot_being_removed_rescanned = 0;
return;
}
info->p_slot = p_slot;
@@ -284,6 +288,7 @@ static void handle_button_press_event(struct slot *p_slot)
ctrl_info(ctrl, "Slot(%s): Action canceled due to button press\n",
slot_name(p_slot));
p_slot->state = STATIC_STATE;
+ slot_being_removed_rescanned = 0;
break;
case POWEROFF_STATE:
case POWERON_STATE:
@@ -294,10 +299,12 @@ static void handle_button_press_event(struct slot *p_slot)
*/
ctrl_info(ctrl, "Slot(%s): Button ignored\n",
slot_name(p_slot));
+ slot_being_removed_rescanned = 0;
break;
default:
ctrl_err(ctrl, "Slot(%s): Ignoring invalid state %#x\n",
slot_name(p_slot), p_slot->state);
+ slot_being_removed_rescanned = 0;
break;
}
}
diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c
index 7bab060..7d1b559 100644
--- a/drivers/pci/hotplug/pciehp_hpc.c
+++ b/drivers/pci/hotplug/pciehp_hpc.c
@@ -622,7 +622,17 @@ static irqreturn_t pciehp_isr(int irq, void *dev_id)
if (events & PCI_EXP_SLTSTA_ABP) {
ctrl_info(ctrl, "Slot(%s): Attention button pressed\n",
slot_name(slot));
- pciehp_queue_interrupt_event(slot, INT_BUTTON_PRESS);
+
+ if (!test_and_set_bit(0, &slot_being_removed_rescanned))
+ pciehp_queue_interrupt_event(slot, INT_BUTTON_PRESS);
+ else {
+ if (slot->state == BLINKINGOFF_STATE || slot->state == BLINKINGON_STATE)
+ pciehp_queue_interrupt_event(slot, INT_BUTTON_PRESS);
+ else
+ ctrl_info(ctrl, "Slot(%s): Slot operation failed because a remove or"
+ " rescan operation is under processing, please try later!\n",
+ slot_name(slot));
+ }
}
/*
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 06c7f0b..206162f 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -489,8 +489,15 @@ static ssize_t remove_store(struct device *dev, struct device_attribute *attr,
if (kstrtoul(buf, 0, &val) < 0)
return -EINVAL;
- if (val && device_remove_file_self(dev, attr))
- pci_stop_and_remove_bus_device_locked(to_pci_dev(dev));
+ if (val && device_remove_file_self(dev, attr)) {
+ if (!test_and_set_bit(0, &slot_being_removed_rescanned)) {
+ pci_stop_and_remove_bus_device_locked(to_pci_dev(dev));
+ slot_being_removed_rescanned = 0;
+ } else {
+ pr_info("Slot is being removed or rescanned, please try later!\n");
+ return -EPERM;
+ }
+ }
return count;
}
static struct device_attribute dev_remove_attr = __ATTR(remove,
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 2fa0dbd..c7c3e37 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -3,6 +3,12 @@
#include <linux/pci-aspm.h>
#include "pci.h"
+/*
+ * When a slot is being hotplug through Attention Button or being
+ * removed/rescanned through sysfs, this flag is set.
+ */
+unsigned long slot_being_removed_rescanned;
+
static void pci_free_resources(struct pci_dev *dev)
{
int i;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index c170c92..85a6e75 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -854,6 +854,9 @@ enum pcie_bus_config_types {
/* Do NOT directly access these two variables, unless you are arch-specific PCI
* code, or PCI core code. */
extern struct list_head pci_root_buses; /* list of all known PCI buses */
+
+extern unsigned long slot_being_removed_rescanned;
+
/* Some device drivers need know if PCI is initiated */
int no_pci_devices(void);
--
1.7.12.4
^ permalink raw reply related
* [PATCH] ARM: dts: Delete bogus reference to the charlcd
From: Linus Walleij @ 2018-01-02 7:57 UTC (permalink / raw)
To: linux-arm-kernel
The EB MP board probably has a character LCD but the board manual does
not really state which IRQ it has assigned to this device. The invalid
assignment was a mistake by me during submission of the DTSI where I was
looking for the reference, didn't find it and didn't fill it in.
Delete this for now: it can probably be fixed but that requires access
to the actual board for some trial-and-error experiments.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC folks: please apply this directly for next to fix the DTS
compiler noise it is generating.
---
arch/arm/boot/dts/arm-realview-eb-mp.dtsi | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
index 7b8d90b7aeea..29b636fce23f 100644
--- a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
+++ b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
@@ -150,11 +150,6 @@
interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>;
};
-&charlcd {
- interrupt-parent = <&intc>;
- interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
-};
-
&serial0 {
interrupt-parent = <&intc>;
interrupts = <0 4 IRQ_TYPE_LEVEL_HIGH>;
--
2.14.3
^ permalink raw reply related
* [linux-sunxi] [PATCH v4 3/6] clk: sunxi-ng: add support for Allwinner A64 DE2 CCU
From: Chen-Yu Tsai @ 2018-01-02 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230113043.30237-4-icenowy@aosc.io>
On Sat, Dec 30, 2017 at 7:30 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> Allwinner A64's DE2 needs to claim a section of SRAM (SRAM C) to work.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v4:
> - Use a struct to maintain both ccu desc and quirks as Chen-Yu Tsai
> suggested.
This made the patch slightly messy. Could you split it into two patches?
The first just adds the struct (without the sram_needed field) and migrates
everything to that. This patch should mention it is preperation for the
next patch, which adds the a field to the struct (otherwise it makes no
sense and just looks like churn.) The second patch will add the .sram_needed
field and support for the A64 DE2 CCU.
Thanks
ChenYu
^ permalink raw reply
* [PATCHv3 RESEND 1/3] Documentation: dt: memory: ti-emif: add edac support under emif
From: Tero Kristo @ 2018-01-02 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226224819.6uekbnbd5tllaxb5@rob-hp-laptop>
On 27/12/17 00:48, Rob Herring wrote:
> On Fri, Dec 22, 2017 at 06:23:54PM +0200, Tero Kristo wrote:
>> Certain revisions of the TI EMIF IP contain ECC support in them. Reflect
>> this in the DT binding.
>
> "dt-bindings: edac: ..." is the preferred subject prefix.
>Err, I mean "dt-bindings: memory-controllers: ..."
I'll fix this.
>
>>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> ---
>> Just resending this patch, missed adding devicetree list on this previously
>> and it got lost.
>>
>> .../devicetree/bindings/memory-controllers/ti/emif.txt | 16 +++++++++++++++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
>> index 0db6047..f56a347 100644
>> --- a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
>> +++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
>> @@ -3,12 +3,16 @@
>> EMIF - External Memory Interface - is an SDRAM controller used in
>> TI SoCs. EMIF supports, based on the IP revision, one or more of
>> DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
>> -of the EMIF IP and memory parts attached to it.
>> +of the EMIF IP and memory parts attached to it. Certain revisions
>> +of the EMIF IP controller also contain optional ECC support, which
>> +corrects one bit errors and detects two bit errors.
>>
>> Required properties:
>> - compatible : Should be of the form "ti,emif-<ip-rev>" where <ip-rev>
>> is the IP revision of the specific EMIF instance.
>> For am437x should be ti,emif-am4372.
>> + For dra7xx should be ti,emif-dra7xx.
>> + For k2x family, should be ti,emif-keystone.
>>
>> - phy-type : <u32> indicating the DDR phy type. Following are the
>> allowed values
>> @@ -42,6 +46,10 @@ Optional properties:
>> - hw-caps-temp-alert : Have this property if the controller
>> has capability for generating SDRAM temperature alerts
>>
>> +- interrupts : A list of interrupt specifiers for memory
>> + controller interrupts, if available. Required for EMIF instances
>> + that support ECC.
>
> Be explicit as to which compatibles have an interrupt. Is it really
> optional for for those controllers? The interrupt is in the h/w whether
> you use ECC or not.
It seems the interrupt property is actually required also for omap4,
omap5 emif based on the driver implementation, they use it for high temp
alert as the main feature. The interrupt exists on am3/am4 also but it
is not used at all there right now.
Would it be better just to make this a required property from binding
point of view and ignore the fact that am3/am4 do not really use it?
-Tero
>
>> +
>> Example:
>>
>> emif1: emif at 0x4c000000 {
>> @@ -54,3 +62,9 @@ emif1: emif at 0x4c000000 {
>> hw-caps-ll-interface;
>> hw-caps-temp-alert;
>> };
>> +
>> +emif1: emif at 4c000000 {
>> + compatible = "ti,emif-dra7";
>> + reg = <0x4c000000 0x200>;
>> + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
>> +};
>> --
>> 1.9.1
>>
>> --
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [linux-sunxi] [PATCH v4 1/6] ARM: sunxi: h3/h5: add simplefb nodes
From: Chen-Yu Tsai @ 2018-01-02 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230113043.30237-2-icenowy@aosc.io>
On Sat, Dec 30, 2017 at 7:30 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The H3/H5 SoCs have a HDMI output and a TV Composite output.
>
> Add simplefb nodes for these outputs.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v4:
> - Dropped extra clocks (bus clocks and HDMI DDC clocks), only keep the
> clocks that are needed to display framebuffer to the monitor.
Looks good. I assume you've tested this? It does continue to work
with the bus and DDC clocks disabled, right?
Thanks
ChenYu
^ permalink raw reply
* [linux-sunxi] [PATCH v4 1/6] ARM: sunxi: h3/h5: add simplefb nodes
From: Icenowy Zheng @ 2018-01-02 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64V7KYw5W95-E=b=Li13ZFXy7JakK4+Dx1dsrXXSJZ+wg@mail.gmail.com>
? 2018?1?2???? CST ??4:11:04?Chen-Yu Tsai ???
> On Sat, Dec 30, 2017 at 7:30 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> > The H3/H5 SoCs have a HDMI output and a TV Composite output.
> >
> > Add simplefb nodes for these outputs.
> >
> > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > ---
> > Changes in v4:
> > - Dropped extra clocks (bus clocks and HDMI DDC clocks), only keep the
> >
> > clocks that are needed to display framebuffer to the monitor.
>
> Looks good. I assume you've tested this? It does continue to work
> with the bus and DDC clocks disabled, right?
Yes. This patchset is tested in Orange Pi PC and SoPine w/ Baseboard "Model
A".
>
> Thanks
> ChenYu
^ permalink raw reply
* [linux-sunxi] [PATCH v4 5/6] arm64: allwinner: a64: add simplefb for A64 SoC
From: Chen-Yu Tsai @ 2018-01-02 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171230113043.30237-6-icenowy@aosc.io>
On Sat, Dec 30, 2017 at 7:30 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> The A64 SoC features two display pipelines, one has a LCD output, the
> other has a HDMI output.
>
> Add support for simplefb for these pipelines on A64 SoC.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> Changes in v4:
> - Dropped extra clocks.
> - Added labels to the SimpleFB device tree nodes as boards may have
> extra regulator for display pipeline.
>
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index fb8ea7c414e1..d803c115d362 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -42,9 +42,11 @@
> * OTHER DEALINGS IN THE SOFTWARE.
> */
>
> +#include <dt-bindings/clock/sun8i-de2.h>
> #include <dt-bindings/clock/sun50i-a64-ccu.h>
> #include <dt-bindings/clock/sun8i-r-ccu.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/reset/sun8i-de2.h>
Nit: This isn't used anywhere. Please add it when DE2 DRM support is added.
ChenYu
^ permalink raw reply
* [linux-sunxi] [PATCH v4 1/6] ARM: sunxi: h3/h5: add simplefb nodes
From: Jernej Škrabec @ 2018-01-02 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2823749.lCJ0TQNemj@ice-x220i>
Hi,
Dne torek, 02. januar 2018 ob 09:14:37 CET je Icenowy Zheng napisal(a):
> ? 2018?1?2???? CST ??4:11:04?Chen-Yu Tsai ???
>
> > On Sat, Dec 30, 2017 at 7:30 PM, Icenowy Zheng <icenowy@aosc.io> wrote:
> > > The H3/H5 SoCs have a HDMI output and a TV Composite output.
> > >
> > > Add simplefb nodes for these outputs.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > ---
> > > Changes in v4:
> > > - Dropped extra clocks (bus clocks and HDMI DDC clocks), only keep the
> > >
> > > clocks that are needed to display framebuffer to the monitor.
> >
> > Looks good. I assume you've tested this? It does continue to work
> > with the bus and DDC clocks disabled, right?
>
> Yes. This patchset is tested in Orange Pi PC and SoPine w/ Baseboard "Model
> A".
I think DDC clock is misnamed and according to DW HDMI binding should be named
ISFR (clock for special function registers). I did few test tests when writing
U-Boot driver and it has to be enabled all the time for driver to work
correctly. I did few additional tests few days back - if only DDC clock is
enabled and PLL video/HDMI clock disabled, DW HDMI registers are accessible.
I guess DDC clock in your case is not needed because controller is already
configured correctly.
Best regards,
Jernej
^ permalink raw reply
* [PATCH] pinctrl: at91: Delete an error message for a failed memory allocation in at91_pinctrl_mux_mask()
From: Linus Walleij @ 2018-01-02 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b5da388b-7fa2-ad77-7b64-26eadd55b41c@users.sourceforge.net>
On Sat, Dec 23, 2017 at 8:55 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 23 Dec 2017 20:44:27 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/3] pinctrl: rockchip: Delete error messages for a failed memory allocation in two functions
From: Linus Walleij @ 2018-01-02 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a067193-e0c3-c2b9-b85a-e05c8ff8860e@users.sourceforge.net>
On Sat, Dec 23, 2017 at 10:38 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 23 Dec 2017 22:02:47 +0100
>
> Omit extra messages for a memory allocation failure in these functions.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/3] pinctrl: rockchip: Improve a size determination in rockchip_pinctrl_probe()
From: Linus Walleij @ 2018-01-02 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e0bceb4a-bd46-5032-2ac9-d51aa46440a5@users.sourceforge.net>
On Sat, Dec 23, 2017 at 10:40 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 23 Dec 2017 22:07:30 +0100
>
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/3] pinctrl: rockchip: Fix a typo in four comment lines
From: Linus Walleij @ 2018-01-02 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <989b7476-5e5e-d1ed-0d95-9dbdcec2382c@users.sourceforge.net>
On Sat, Dec 23, 2017 at 10:42 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 23 Dec 2017 22:22:54 +0100
>
> Adjust words in these descriptions.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] pinctrl: single: Delete an error message for a failed memory allocation in pcs_probe()
From: Linus Walleij @ 2018-01-02 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bc8e7af9-6dcb-6f08-388a-31fc1b88cd00@users.sourceforge.net>
On Mon, Dec 25, 2017 at 2:06 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 25 Dec 2017 11:27:55 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] pinctrl: single: Delete an unnecessary return statement in pcs_irq_chain_handler()
From: Linus Walleij @ 2018-01-02 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c736d14b-0293-82ac-27de-a673b62b61d7@users.sourceforge.net>
On Mon, Dec 25, 2017 at 2:07 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 25 Dec 2017 11:35:44 +0100
>
> The script "checkpatch.pl" pointed information out like the following.
>
> WARNING: void function return statements are not generally useful
>
> Thus remove such a statement in the affected function.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: samsung: Add SPDX license identifiers
From: Linus Walleij @ 2018-01-02 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514311782-5187-1-git-send-email-krzk@kernel.org>
On Tue, Dec 26, 2017 at 7:09 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Replace GPL license statements with SPDX GPL-2.0+ license identifiers.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V2 2/7] arm64: mm: Flip kernel VA space
From: Steve Capper @ 2018-01-02 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218214736.13761-3-steve.capper@arm.com>
On Mon, Dec 18, 2017 at 09:47:31PM +0000, Steve Capper wrote:
> Put the direct linear map in the lower addresses of the kernel VA range
> and everything else in the higher ranges.
>
> This allows us to make room for an inline KASAN shadow that operates
> under both 48 and 52 bit kernel VA sizes. For example with a 52-bit VA,
> if KASAN_SHADOW_END < 0xFFF8000000000000 (it is in the lower addresses
> of the kernel VA range), this will be below the start of the minimum
> 48-bit kernel VA address of 0xFFFF000000000000.
>
> We need to adjust:
> *) KASAN shadow region placement logic,
> *) KASAN_SHADOW_OFFSET computation logic,
> *) virt_to_phys, phys_to_virt checks,
> *) page table dumper.
>
> These are all small changes, that need to take place atomically, so they
> are bundled into this commit.
I need to tweak this to include changes to the HYP map logic
(specifically change the first AND to an EOR).
Cheers,
--
Steve
^ permalink raw reply
* [PATCH] pinctrl/spear/plgpio: Delete two error messages for a failed memory allocation in plgpio_probe()
From: Linus Walleij @ 2018-01-02 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <66c3f488-ffdf-e55d-e511-e4af35e670b4@users.sourceforge.net>
On Wed, Dec 27, 2017 at 10:39 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 27 Dec 2017 22:34:28 +0100
>
> Omit extra messages for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Patch applied with Viresh's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] pinctrl: spear: Delete an error message for a failed memory allocation in spear_pinctrl_probe()
From: Linus Walleij @ 2018-01-02 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3d936763-6a8a-edd3-3bcf-0075c9343e37@users.sourceforge.net>
On Wed, Dec 27, 2017 at 10:48 PM, SF Markus Elfring
<elfring@users.sourceforge.net> wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 27 Dec 2017 22:44:04 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Patch applied with Viresh's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/5] drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H
From: Jagan Teki @ 2018-01-02 9:02 UTC (permalink / raw)
To: linux-arm-kernel
This adds support for the Ampire AM-800480AYTZQW-00H 7.0" WGA LCD,
which can be supported by the simple panel driver.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
.../display/panel/ampire,am-800480aytzqw-00h.txt | 7 ++++++
drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
diff --git a/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt b/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
new file mode 100644
index 0000000..bfa7a70
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
@@ -0,0 +1,7 @@
+Ampire AM-800480AYTZQW-00H 7.0" WVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "ampire,am-800480aytzqw-00h"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 5591984..2ecc14b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -412,6 +412,30 @@ static const struct panel_desc ampire_am_480272h3tmqw_t01h = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
};
+static const struct display_timing ampire_am_800480aytzqw_00h_timing = {
+ .pixelclock = { 27700000, 29200000, 39600000 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 12, 40, 212 },
+ .hback_porch = { 88, 88, 88 },
+ .hsync_len = { 1, 2, 40 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 1, 13, 88 },
+ .vback_porch = { 32, 32, 32 },
+ .vsync_len = { 1, 2, 3 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc ampire_am_800480aytzqw_00h = {
+ .timings = &ire_am_800480aytzqw_00h_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
static const struct drm_display_mode ampire_am800480r3tmqwa1h_mode = {
.clock = 33333,
.hdisplay = 800,
@@ -2028,6 +2052,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "ampire,am-480272h3tmqw-t01h",
.data = &ire_am_480272h3tmqw_t01h,
}, {
+ .compatible = "ampire,am-800480aytzqw-00h",
+ .data = &ire_am_800480aytzqw_00h,
+ }, {
.compatible = "ampire,am800480r3tmqwa1h",
.data = &ire_am800480r3tmqwa1h,
}, {
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: imx6q-icore: Switch LVDS timings from panel-simple
From: Jagan Teki @ 2018-01-02 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514883738-16297-1-git-send-email-jagan@amarulasolutions.com>
Switch to use ampire,am-800480aytzqw-00h LVDS timings from
panel-simple instead hard coding the same in dts.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm/boot/dts/imx6q-icore.dts | 31 +++++++++++++++++--------------
arch/arm/boot/dts/imx6qdl-icore.dtsi | 2 +-
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-icore.dts b/arch/arm/boot/dts/imx6q-icore.dts
index 5613dd9..c8e464e 100644
--- a/arch/arm/boot/dts/imx6q-icore.dts
+++ b/arch/arm/boot/dts/imx6q-icore.dts
@@ -48,6 +48,17 @@
/ {
model = "Engicam i.CoreM6 Quad/Dual Starter Kit";
compatible = "engicam,imx6-icore", "fsl,imx6q";
+
+ panel {
+ compatible = "ampire,am-800480aytzqw-00h";
+ backlight = <&backlight_lvds>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
};
&can1 {
@@ -71,22 +82,14 @@
status = "okay";
lvds-channel at 0 {
- fsl,data-mapping = "spwg";
- fsl,data-width = <18>;
+ reg = <0>;
status = "okay";
- display-timings {
- native-mode = <&timing0>;
- timing0: timing0 {
- clock-frequency = <60000000>;
- hactive = <800>;
- vactive = <480>;
- hback-porch = <30>;
- hfront-porch = <30>;
- vback-porch = <5>;
- vfront-porch = <5>;
- hsync-len = <64>;
- vsync-len = <20>;
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index a1b469c..5fd9e00 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -49,7 +49,7 @@
reg = <0x10000000 0x80000000>;
};
- backlight {
+ backlight_lvds: backlight-lvds {
compatible = "pwm-backlight";
pwms = <&pwm3 0 100000>;
brightness-levels = <0 4 8 16 32 64 128 255>;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: imx6dl-icore: Add LVDS node
From: Jagan Teki @ 2018-01-02 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514883738-16297-1-git-send-email-jagan@amarulasolutions.com>
Add ampire,am-800480aytzqw-00h LVDS support by using
timings from panel-simple.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm/boot/dts/imx6dl-icore.dts | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl-icore.dts b/arch/arm/boot/dts/imx6dl-icore.dts
index 971f9fc..74bff84 100644
--- a/arch/arm/boot/dts/imx6dl-icore.dts
+++ b/arch/arm/boot/dts/imx6dl-icore.dts
@@ -48,6 +48,17 @@
/ {
model = "Engicam i.CoreM6 DualLite/Solo Starter Kit";
compatible = "engicam,imx6-icore", "fsl,imx6dl";
+
+ panel {
+ compatible = "ampire,am-800480aytzqw-00h";
+ backlight = <&backlight_lvds>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
};
&can1 {
@@ -66,3 +77,20 @@
interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
};
};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel at 0 {
+ reg = <0>;
+ status = "okay";
+
+ port at 4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] drm/panel: simple: Add support for KEO TX31D200VM0BAA
From: Jagan Teki @ 2018-01-02 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514883738-16297-1-git-send-email-jagan@amarulasolutions.com>
This adds support for the Kaohsiung Opto-Electronics.,
TX31D200VM0BAA 12.3" HSXGA LVDS panel, which can be
supported by the simple panel driver.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
.../bindings/display/panel/koe,tx31d200vm0baa.txt | 7 ++++++
drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
2 files changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
diff --git a/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt b/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
new file mode 100644
index 0000000..a51db2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
@@ -0,0 +1,7 @@
+Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
+
+Required properties:
+- compatible: should be "koe,tx31d200vm0baa"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 2ecc14b..8a0e4a8 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1241,6 +1241,30 @@ static const struct panel_desc innolux_zj070na_01p = {
},
};
+static const struct display_timing koe_tx31d200vm0baa_timing = {
+ .pixelclock = { 39600000, 43200000, 48000000 },
+ .hactive = { 1280, 1280, 1280 },
+ .hfront_porch = { 16, 36, 56 },
+ .hback_porch = { 16, 36, 56 },
+ .hsync_len = { 8, 8, 8 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 6, 21, 33.5 },
+ .vback_porch = { 6, 21, 33.5 },
+ .vsync_len = { 8, 8, 8 },
+ .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc koe_tx31d200vm0baa = {
+ .timings = &koe_tx31d200vm0baa_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 292,
+ .height = 109,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
static const struct display_timing kyo_tcg121xglp_timing = {
.pixelclock = { 52000000, 65000000, 71000000 },
.hactive = { 1024, 1024, 1024 },
@@ -2151,6 +2175,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,zj070na-01p",
.data = &innolux_zj070na_01p,
}, {
+ .compatible = "koe,tx31d200vm0baa",
+ .data = &koe_tx31d200vm0baa,
+ }, {
.compatible = "kyo,tcg121xglp",
.data = &kyo_tcg121xglp,
}, {
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox