* [Qemu-devel] [PATCH RFC v3 0/2] block/qapi: refactor and optimize the qmp_query_blockstats()
From: Dou Liyang @ 2017-01-04 6:58 UTC (permalink / raw)
To: stefanha, kwolf, armbru, mreitz, eblake, famz, danpb
Cc: qemu-devel, izumi.taku, caoj.fnst, fanc.fnst, Dou Liyang
Change log v2 -> v3:
1. Remove the unnecessary code for the bdrv_next_node().
2. Remove the change of the locking rules.
Even if this change can improve the performance, but it may
effect the consistency.
For the multi-disks guest, we can use the dataplane feature to
hold performance does not drop, if we execute some slow monitor
commands, such as "info blockstats". But, without this feature,
How to reduce the decline in performance?
These patches aim to refactor the qmp_query_blockstats() and
improve the performance by reducing the running time of it.
There are the two jobs:
1 For the performance:
1.1 the time it takes(ns) in each time:
the disk numbers | 10 | 500
-------------------------------------
before these patches | 19429 | 667722
after these patches | 18536 | 627945
1.2 the I/O performance is degraded(%) during the monitor:
the disk numbers | 10 | 500
-------------------------------------
before these patches | 1.3 | 14.2
after these patches | 1.0 | 11.3
used the dd command likes this to test:
dd if=date_1.dat of=date_2.dat conv=fsync oflag=direct bs=1k count=100k.
2 refactor qmp_query_blockstats():
From:
+--------------+ +---------------------+
| 1 | | 4. |
|next_query_bds| |bdrv_query_bds_stats +---+
| | | | |
+--------^-----+ +-------------^-------+ |
| | |
+---------+----------+ +--------+-------+ |
| 0. | | 2. | |
|qmp_query_blockstats+------>bdrv_query_stats<----
| | | |
+--------------------+ +--------+-------+
|
+-------------v-------+
| 3. |
|bdrv_query_blk_stats |
| |
+---------------------+
To:
+--------------+
| |
+--------v-----------+ |
+---> 3. | |
+-------------------+ | |bdrv_query_bds_stats+--+
| 1. +--+ | |
| + +--------------------+
|qmp_query_blockstats--+
| | |
+-------------------+ | +--------------------+
| | 2. |
+---> |
|bdrv_query_blk_stats|
| |
+--------------------+
Dou Liyang (2):
block/qapi: reduce the coupling between the bdrv_query_stats and
bdrv_query_bds_stats
block/qapi: reduce the execution time of qmp_query_blockstats
block/qapi.c | 94 ++++++++++++++++++++++++++----------------------------------
1 file changed, 40 insertions(+), 54 deletions(-)
--
2.5.5
^ permalink raw reply
* [Qemu-devel] [PATCH RFC v3 1/2] block/qapi: reduce the coupling between the bdrv_query_stats and bdrv_query_bds_stats
From: Dou Liyang @ 2017-01-04 6:58 UTC (permalink / raw)
To: stefanha, kwolf, armbru, mreitz, eblake, famz, danpb
Cc: qemu-devel, izumi.taku, caoj.fnst, fanc.fnst, Dou Liyang
In-Reply-To: <1483513091-30661-1-git-send-email-douly.fnst@cn.fujitsu.com>
the bdrv_query_stats and bdrv_query_bds_stats functions need to call
each other, that increases the coupling. it also makes the program
complicated and makes some unnecessary judgements.
remove the call from bdrv_query_bds_stats to bdrv_query_stats, just
take some recursion to make it clearly.
avoid judging whether the blk is NULL during querying the bds stats.
it is unnecessary.
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
---
block/qapi.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/block/qapi.c b/block/qapi.c
index a62e862..bc622cd 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -357,10 +357,6 @@ static void bdrv_query_info(BlockBackend *blk, BlockInfo **p_info,
qapi_free_BlockInfo(info);
}
-static BlockStats *bdrv_query_stats(BlockBackend *blk,
- const BlockDriverState *bs,
- bool query_backing);
-
static void bdrv_query_blk_stats(BlockDeviceStats *ds, BlockBackend *blk)
{
BlockAcctStats *stats = blk_get_stats(blk);
@@ -428,9 +424,18 @@ static void bdrv_query_blk_stats(BlockDeviceStats *ds, BlockBackend *blk)
}
}
-static void bdrv_query_bds_stats(BlockStats *s, const BlockDriverState *bs,
+static BlockStats *bdrv_query_bds_stats(const BlockDriverState *bs,
bool query_backing)
{
+ BlockStats *s = NULL;
+
+ s = g_malloc0(sizeof(*s));
+ s->stats = g_malloc0(sizeof(*s->stats));
+
+ if (!bs) {
+ return s;
+ }
+
if (bdrv_get_node_name(bs)[0]) {
s->has_node_name = true;
s->node_name = g_strdup(bdrv_get_node_name(bs));
@@ -440,14 +445,15 @@ static void bdrv_query_bds_stats(BlockStats *s, const BlockDriverState *bs,
if (bs->file) {
s->has_parent = true;
- s->parent = bdrv_query_stats(NULL, bs->file->bs, query_backing);
+ s->parent = bdrv_query_bds_stats(bs->file->bs, query_backing);
}
if (query_backing && bs->backing) {
s->has_backing = true;
- s->backing = bdrv_query_stats(NULL, bs->backing->bs, query_backing);
+ s->backing = bdrv_query_bds_stats(bs->backing->bs, query_backing);
}
+ return s;
}
static BlockStats *bdrv_query_stats(BlockBackend *blk,
@@ -456,17 +462,13 @@ static BlockStats *bdrv_query_stats(BlockBackend *blk,
{
BlockStats *s;
- s = g_malloc0(sizeof(*s));
- s->stats = g_malloc0(sizeof(*s->stats));
+ s = bdrv_query_bds_stats(bs, query_backing);
if (blk) {
s->has_device = true;
s->device = g_strdup(blk_name(blk));
bdrv_query_blk_stats(s->stats, blk);
}
- if (bs) {
- bdrv_query_bds_stats(s, bs, query_backing);
- }
return s;
}
--
2.5.5
^ permalink raw reply related
* [Qemu-devel] [PATCH RFC v3 2/2] block/qapi: reduce the execution time of qmp_query_blockstats
From: Dou Liyang @ 2017-01-04 6:58 UTC (permalink / raw)
To: stefanha, kwolf, armbru, mreitz, eblake, famz, danpb
Cc: qemu-devel, izumi.taku, caoj.fnst, fanc.fnst, Dou Liyang
In-Reply-To: <1483513091-30661-1-git-send-email-douly.fnst@cn.fujitsu.com>
In order to reduce the execution time, this patch optimize
the qmp_query_blockstats():
Remove the next_query_bds function.
Remove the bdrv_query_stats function.
Remove some judgement sentence.
The original qmp_query_blockstats calls next_query_bds to get
the next objects in each loops. In the next_query_bds, it checks
the query_nodes and blk. It also call bdrv_query_stats to get
the stats, In the bdrv_query_stats, it checks blk and bs each
times. This waste more times, which may stall the main loop a
bit. And if the disk is too many and donot use the dataplane
feature, this may affect the performance in main loop thread.
This patch removes that two functions, and makes the structure
clearly.
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
---
block/qapi.c | 72 +++++++++++++++++++++++-------------------------------------
1 file changed, 28 insertions(+), 44 deletions(-)
diff --git a/block/qapi.c b/block/qapi.c
index bc622cd..6e1e8bd 100644
--- a/block/qapi.c
+++ b/block/qapi.c
@@ -456,23 +456,6 @@ static BlockStats *bdrv_query_bds_stats(const BlockDriverState *bs,
return s;
}
-static BlockStats *bdrv_query_stats(BlockBackend *blk,
- const BlockDriverState *bs,
- bool query_backing)
-{
- BlockStats *s;
-
- s = bdrv_query_bds_stats(bs, query_backing);
-
- if (blk) {
- s->has_device = true;
- s->device = g_strdup(blk_name(blk));
- bdrv_query_blk_stats(s->stats, blk);
- }
-
- return s;
-}
-
BlockInfoList *qmp_query_block(Error **errp)
{
BlockInfoList *head = NULL, **p_next = &head;
@@ -496,42 +479,43 @@ BlockInfoList *qmp_query_block(Error **errp)
return head;
}
-static bool next_query_bds(BlockBackend **blk, BlockDriverState **bs,
- bool query_nodes)
-{
- if (query_nodes) {
- *bs = bdrv_next_node(*bs);
- return !!*bs;
- }
-
- *blk = blk_next(*blk);
- *bs = *blk ? blk_bs(*blk) : NULL;
-
- return !!*blk;
-}
-
BlockStatsList *qmp_query_blockstats(bool has_query_nodes,
bool query_nodes,
Error **errp)
{
BlockStatsList *head = NULL, **p_next = &head;
- BlockBackend *blk = NULL;
- BlockDriverState *bs = NULL;
+ BlockBackend *blk;
+ BlockDriverState *bs;
/* Just to be safe if query_nodes is not always initialized */
- query_nodes = has_query_nodes && query_nodes;
-
- while (next_query_bds(&blk, &bs, query_nodes)) {
- BlockStatsList *info = g_malloc0(sizeof(*info));
- AioContext *ctx = blk ? blk_get_aio_context(blk)
- : bdrv_get_aio_context(bs);
+ if (has_query_nodes && query_nodes) {
+ for (bs = bdrv_next_node(NULL); bs; bs = bdrv_next_node(bs)) {
+ BlockStatsList *info = g_malloc0(sizeof(*info));
+ AioContext *ctx = bdrv_get_aio_context(bs);
- aio_context_acquire(ctx);
- info->value = bdrv_query_stats(blk, bs, !query_nodes);
- aio_context_release(ctx);
+ aio_context_acquire(ctx);
+ info->value = bdrv_query_bds_stats(bs, false);
+ aio_context_release(ctx);
- *p_next = info;
- p_next = &info->next;
+ *p_next = info;
+ p_next = &info->next;
+ }
+ } else {
+ for (blk = blk_next(NULL); blk; blk = blk_next(blk)) {
+ BlockStatsList *info = g_malloc0(sizeof(*info));
+ AioContext *ctx = blk_get_aio_context(blk);
+
+ aio_context_acquire(ctx);
+ BlockStats *s = bdrv_query_bds_stats(blk_bs(blk), true);
+ s->has_device = true;
+ s->device = g_strdup(blk_name(blk));
+ bdrv_query_blk_stats(s->stats, blk);
+ aio_context_release(ctx);
+
+ info->value = s;
+ *p_next = info;
+ p_next = &info->next;
+ }
}
return head;
--
2.5.5
^ permalink raw reply related
* adding 32 bit compatibility layer in custom kernel module
From: Pradeepa Kumar @ 2017-01-04 6:59 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <57E0AC1E-A235-4F25-A2BF-F314BB3BA6B0@gmail.com>
my app is crashing as it is trying iterate cmsghdrs
it got after call to recvmsg();
To give some context
below is the flow
32 bit app <--> my kernel module <--> 64 bit app
my kernel module implements new protocol and
provides 'struct proto_ops'
it never calls __sys_socket* calls.
once 32 bit app calls recvmsg(),
kernel module gets required data from another 64 bit app
via netlink msg.
issue here is the struct msghdr and strcu cmsgdr sizes
and members are of different lenghts.
so kernel module needs to give data to 32 bit app
in proper struct which are of correct sizes in 32 bit mode.
so kernel module needs a way to figure out
it is 32 bit app that made recvmsg() call and process accordingly.
i dont see compat_recv in struct proto_ops
On Wed, Jan 4, 2017 at 12:18 PM, Anish Kumar <anish198519851985@gmail.com>
wrote:
>
>
> On Jan 3, 2017, at 10:03 PM, Pradeepa Kumar <cdpradeepa@gmail.com> wrote:
>
> Please see inline below
>
> On Wed, Jan 4, 2017 at 11:07 AM, Anish Kumar <anish198519851985@gmail.com>
> wrote:
>
>>
>>
>> On Jan 3, 2017, at 8:04 PM, Pradeepa Kumar <cdpradeepa@gmail.com> wrote:
>>
>> Hi experts
>>
>> down votefavorite
>> <http://stackoverflow.com/questions/41455943/adding-32-bit-compatibility-layer-in-custom-kernel-module#>
>>
>> in my 64 bit kernel, I have a custom kernel module providing new protocol
>> and providing socket system calls.
>>
>> it works fine when 64 bit app runs.
>>
>> i am seeing issues when 32 bit app runs (for exp recvmsg() call does not
>> work if msg has cmsghdrs as struct size of cmsghdr is different in 32 bit
>> and 64 bit).
>>
>> This is because my custom kernel module does not have 32 bit
>> compatibility layer ( but linux kernel has this in compat.c etc).
>>
>> -
>>
>> is it simple to add compatibility layer to my custom kernel module
>>
>>
>> All you have to do is add compat_ioctl call to your driver.
>>
>> my kernel module provides recvmsg() but i dont see any 'compat_recvmsg'
> in struct proto_ops.
>
>
> Try to wrap your text in 80 characters.
>
> Your application is crashing? Right?
> Have you figured where it is crashing exactly?
>
> I understood that your application is crashing as
> It not able to function with 64 bit kernel.
>
> This happens because of the data being passed
> to kernel is not in the right format. You need to
> look at what you are passing to the driver and
> if needed write the compat_ioctl callback in your
> driver fops.
>
> had there been 'compat_recvmsg' it would have been possible for me to
> define recvmsg() for 32 bit apps.
> please let me know if i am missing anything
>
>
>> -
>>
>> how do i do this (any links ?)
>>
>>
>> You can see many drivers supports compat call.
>>
>> Thanks
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20170104/162a3ac6/attachment.html
^ permalink raw reply
* [PATCH v4 0/3] Add support for the S6E3HA2 panel on TM2 board
From: Hoegeun Kwon @ 2017-01-04 6:58 UTC (permalink / raw)
To: robh, thierry.reding, airlied, kgene, krzk, inki.dae
Cc: dri-devel, linux-kernel, devicetree, linux-samsung-soc, a.hajda,
cw00.choi, jh80.chung, Hoegeun Kwon
In-Reply-To: <CGME20170104065858epcas5p2f6a70e125b1b6d7051d8fe3a28e626f5@epcas5p2.samsung.com>
Purpose of this patch is add support for S6E3HA2 AMOLED panel on
the TM2 board. The first patch adds support for S6E3HA2 panel
device tree document and driver, the second patch add support for
S6E3HA2 panel device tree.
Changes for V4:
- Removed display-timings in devicetree, the display-timings has
been fixed to be provided by the device driver.
- Added the mode_set callback function into exynos_drm_mic,
because the exynos_drm_mic driver can not parse a videomode
struct by removing the display-timings from the devicetree.
Hoegeun Kwon (2):
drm/exynos: mic: Add mode_set callback function
drm/panel: Add support for S6E3HA2 panel driver on TM2 board
Hyungwon Hwang (1):
arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
.../bindings/display/panel/samsung,s6e3ha2.txt | 40 ++
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 17 +
drivers/gpu/drm/exynos/exynos_drm_mic.c | 33 +-
drivers/gpu/drm/panel/Kconfig | 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 741 +++++++++++++++++++++
6 files changed, 827 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
--
1.9.1
^ permalink raw reply
* [PATCH v4 1/3] drm/exynos: mic: Add mode_set callback function
From: Hoegeun Kwon @ 2017-01-04 6:58 UTC (permalink / raw)
To: robh, thierry.reding, airlied, kgene, krzk, inki.dae
Cc: dri-devel, linux-kernel, devicetree, linux-samsung-soc, a.hajda,
cw00.choi, jh80.chung, Hoegeun Kwon
In-Reply-To: <1483513115-3068-1-git-send-email-hoegeun.kwon@samsung.com>
Before applying the patch, used the of_get_videomode function to
parse the display-timings in the panel which is the child driver
of dsi in the devicetree. this is wrong. So removed the
of_get_videomode and fixed to get videomode struct through
mode_set callback function.
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 33 ++++++++++++++++++++++-----------
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index a0def0b..9a50ceb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
}
nodes[j++] = remote_node;
- ret = of_get_videomode(remote_node,
- &mic->vm, 0);
- if (ret) {
- DRM_ERROR("mic: failed to get videomode");
- goto exit;
- }
-
break;
default:
DRM_ERROR("mic: Unknown endpoint from MIC");
@@ -329,6 +322,27 @@ static void mic_post_disable(struct drm_bridge *bridge)
mutex_unlock(&mic_mutex);
}
+static void mic_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct exynos_mic *mic = bridge->driver_private;
+
+ mutex_lock(&mic_mutex);
+ if (mic->enabled)
+ goto already_enabled;
+
+ drm_display_mode_to_videomode(mode, &mic->vm);
+
+ if (!mic->i80_mode)
+ mic_set_porch_timing(mic);
+ mic_set_img_size(mic);
+ mic_set_output_timing(mic);
+
+already_enabled:
+ mutex_unlock(&mic_mutex);
+}
+
static void mic_pre_enable(struct drm_bridge *bridge)
{
struct exynos_mic *mic = bridge->driver_private;
@@ -355,10 +369,6 @@ static void mic_pre_enable(struct drm_bridge *bridge)
goto turn_off_clks;
}
- if (!mic->i80_mode)
- mic_set_porch_timing(mic);
- mic_set_img_size(mic);
- mic_set_output_timing(mic);
mic_set_reg_on(mic, 1);
mic->enabled = 1;
mutex_unlock(&mic_mutex);
@@ -377,6 +387,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
static const struct drm_bridge_funcs mic_bridge_funcs = {
.disable = mic_disable,
.post_disable = mic_post_disable,
+ .mode_set = mic_mode_set,
.pre_enable = mic_pre_enable,
.enable = mic_enable,
};
--
1.9.1
^ permalink raw reply related
* [PATCH] ACPI/PCI: Fix bus range comparation in pci_mcfg_lookup
From: Zhou Wang @ 2017-01-04 7:00 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Tomasz Nowicki, Jayachandran C,
Lorenzo Pieralisi, jorn Helgaas
Cc: liudongdong3, gabriele.paoloni, xuwei5, linux-acpi, linux-pci,
linux-kernel, Zhou Wang
The configuration data provided by an MCFG region (ie PCI segment and
bus range) may span multiple host bridges.
Current code in pci_mcfg_lookup() carries out an exact match of host
bridge bus range start value against the MCFG region(s) bus range start
value which would cause configurations like the following:
MCFG region:
bus range: 0x00~0xff.
segment: 0.
PCI host bridges configuration (segment numbers and bus ranges):
host bridge 1:
bus range: 0x00~0x1f.
segment: 0.
host bridge 2:
bus range: 0x20~0x4f.
segment: 0.
to fail, in that the bus range start value for host bridge 2 does
not match the bus range start value of the respective MCFG region.
Relax the bus range check in pci_mcfg_lookup() to cater for
PCI configurations with multiple host bridges sharing the same
MCFG region.
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
drivers/acpi/pci_mcfg.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index a6a4cea..2944353 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -195,11 +195,10 @@ int pci_mcfg_lookup(struct acpi_pci_root *root, struct resource *cfgres,
goto skip_lookup;
/*
- * We expect exact match, unless MCFG entry end bus covers more than
- * specified by caller.
+ * We expect the range in bus_res in the coverage of MCFG bus range.
*/
list_for_each_entry(e, &pci_mcfg_list, list) {
- if (e->segment == seg && e->bus_start == bus_res->start &&
+ if (e->segment == seg && e->bus_start <= bus_res->start &&
e->bus_end >= bus_res->end) {
root->mcfg_addr = e->addr;
}
--
1.9.1
^ permalink raw reply related
* [PATCH] ACPI/PCI: Fix bus range comparation in pci_mcfg_lookup
From: Zhou Wang @ 2017-01-04 7:00 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, Tomasz Nowicki, Jayachandran C,
Lorenzo Pieralisi, jorn Helgaas
Cc: liudongdong3, gabriele.paoloni, xuwei5, linux-acpi, linux-pci,
linux-kernel, Zhou Wang
The configuration data provided by an MCFG region (ie PCI segment and
bus range) may span multiple host bridges.
Current code in pci_mcfg_lookup() carries out an exact match of host
bridge bus range start value against the MCFG region(s) bus range start
value which would cause configurations like the following:
MCFG region:
bus range: 0x00~0xff.
segment: 0.
PCI host bridges configuration (segment numbers and bus ranges):
host bridge 1:
bus range: 0x00~0x1f.
segment: 0.
host bridge 2:
bus range: 0x20~0x4f.
segment: 0.
to fail, in that the bus range start value for host bridge 2 does
not match the bus range start value of the respective MCFG region.
Relax the bus range check in pci_mcfg_lookup() to cater for
PCI configurations with multiple host bridges sharing the same
MCFG region.
Signed-off-by: Zhou Wang <wangzhou1@hisilicon.com>
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
drivers/acpi/pci_mcfg.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index a6a4cea..2944353 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -195,11 +195,10 @@ int pci_mcfg_lookup(struct acpi_pci_root *root, struct resource *cfgres,
goto skip_lookup;
/*
- * We expect exact match, unless MCFG entry end bus covers more than
- * specified by caller.
+ * We expect the range in bus_res in the coverage of MCFG bus range.
*/
list_for_each_entry(e, &pci_mcfg_list, list) {
- if (e->segment == seg && e->bus_start == bus_res->start &&
+ if (e->segment == seg && e->bus_start <= bus_res->start &&
e->bus_end >= bus_res->end) {
root->mcfg_addr = e->addr;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v4 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
From: Hoegeun Kwon @ 2017-01-04 6:58 UTC (permalink / raw)
To: robh, thierry.reding, airlied, kgene, krzk, inki.dae
Cc: dri-devel, linux-kernel, devicetree, linux-samsung-soc, a.hajda,
cw00.choi, jh80.chung, Hoegeun Kwon, Donghwa Lee, Hyungwon Hwang
In-Reply-To: <1483513115-3068-1-git-send-email-hoegeun.kwon@samsung.com>
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
---
.../bindings/display/panel/samsung,s6e3ha2.txt | 40 ++
drivers/gpu/drm/panel/Kconfig | 6 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 741 +++++++++++++++++++++
4 files changed, 788 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
new file mode 100644
index 0000000..6879f51
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,40 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+ - compatible: "samsung,s6e3ha2"
+ - reg: the virtual channel number of a DSI peripheral
+ - vdd3-supply: I/O voltage supply
+ - vci-supply: voltage supply for analog circuits
+ - reset-gpios: a GPIO spec for the reset pin (active low)
+ - enable-gpios: a GPIO spec for the panel enable pin (active high)
+ - te-gpios: a GPIO spec for the tearing effect synchronization signal
+ gpio pin (active high)
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [1]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+&dsi {
+ ...
+
+ panel@0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+};
+
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..eea2902 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
Xperia Z2 tablets
+config DRM_PANEL_SAMSUNG_S6E3HA2
+ tristate "Samsung S6E3HA2 DSI video mode panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ select VIDEOMODE_HELPERS
+
config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += panel-panasonic-vvx10f034n00.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
new file mode 100644
index 0000000..8c5a1c2
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,741 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee <dh09.lee@samsung.com>
+ * Hyungwon Hwang <human.hwang@samsung.com>
+ * Hoegeun Kwon <hoegeun.kwon@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <drm/drmP.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_panel.h>
+#include <linux/backlight.h>
+#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS 46
+#define S6E3HA2_GAMMA_CMD_CNT 35
+#define S6E3HA2_VINT_STATUS_MAX 10
+
+static const u8 gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
+ 0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
+ 0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
+ 0x91, 0x84, 0xb1, 0xae, 0x8b, 0xd5, 0xb2, 0xcc, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x87, 0x81, 0x84, 0x8a, 0x87, 0x8a,
+ 0x91, 0x85, 0xae, 0xac, 0x8a, 0xc3, 0xa3, 0xc0, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x85, 0x85,
+ 0x86, 0x85, 0x88, 0x89, 0x84, 0x89, 0x82, 0x84, 0x87, 0x85, 0x8b,
+ 0x91, 0x88, 0xad, 0xab, 0x8a, 0xb7, 0x9b, 0xb6, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x89, 0x8a, 0x84, 0x89, 0x83, 0x83, 0x86, 0x84, 0x8b,
+ 0x90, 0x84, 0xb0, 0xae, 0x8b, 0xce, 0xad, 0xc8, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x87, 0x89, 0x8a, 0x83, 0x87, 0x82, 0x85, 0x88, 0x87, 0x89,
+ 0x8f, 0x84, 0xac, 0xaa, 0x89, 0xb1, 0x98, 0xaf, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x88, 0x89, 0x84, 0x88, 0x83, 0x82, 0x85, 0x84, 0x8c,
+ 0x91, 0x86, 0xac, 0xaa, 0x89, 0xc2, 0xa5, 0xbd, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x84, 0x84,
+ 0x85, 0x87, 0x89, 0x8a, 0x83, 0x87, 0x82, 0x85, 0x88, 0x87, 0x88,
+ 0x8b, 0x82, 0xad, 0xaa, 0x8a, 0xc2, 0xa5, 0xbd, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x87, 0x89, 0x84, 0x88, 0x83, 0x82, 0x85, 0x84, 0x8a,
+ 0x8e, 0x84, 0xae, 0xac, 0x89, 0xda, 0xb7, 0xd0, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x84, 0x84,
+ 0x85, 0x86, 0x87, 0x89, 0x84, 0x88, 0x83, 0x80, 0x83, 0x82, 0x8b,
+ 0x8e, 0x85, 0xac, 0xaa, 0x89, 0xc8, 0xaa, 0xc1, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x84, 0x84,
+ 0x85, 0x86, 0x87, 0x89, 0x81, 0x85, 0x81, 0x84, 0x86, 0x84, 0x8c,
+ 0x8c, 0x84, 0xa9, 0xa8, 0x87, 0xa3, 0x92, 0xa1, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x84, 0x84,
+ 0x85, 0x86, 0x87, 0x89, 0x84, 0x86, 0x83, 0x80, 0x83, 0x81, 0x8c,
+ 0x8d, 0x84, 0xaa, 0xaa, 0x89, 0xce, 0xaf, 0xc5, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x84, 0x84,
+ 0x85, 0x86, 0x87, 0x89, 0x81, 0x83, 0x80, 0x83, 0x85, 0x85, 0x8c,
+ 0x8c, 0x84, 0xa8, 0xa8, 0x88, 0xb5, 0x9f, 0xb0, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x84, 0x84,
+ 0x86, 0x86, 0x87, 0x88, 0x81, 0x83, 0x80, 0x83, 0x85, 0x85, 0x8c,
+ 0x8b, 0x84, 0xab, 0xa8, 0x86, 0xd4, 0xb4, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x84, 0x84,
+ 0x86, 0x86, 0x87, 0x88, 0x81, 0x83, 0x80, 0x84, 0x84, 0x85, 0x8b,
+ 0x8a, 0x83, 0xa6, 0xa5, 0x84, 0xbb, 0xa4, 0xb3, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x84, 0x84,
+ 0x86, 0x85, 0x86, 0x86, 0x82, 0x85, 0x81, 0x82, 0x83, 0x84, 0x8e,
+ 0x8b, 0x83, 0xa4, 0xa3, 0x8a, 0xa1, 0x93, 0x9d, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x87, 0x87, 0x82, 0x85, 0x81, 0x82, 0x82, 0x84, 0x8e,
+ 0x8b, 0x83, 0xa4, 0xa2, 0x86, 0xc1, 0xa9, 0xb7, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x87, 0x87, 0x82, 0x85, 0x81, 0x82, 0x82, 0x84, 0x8d,
+ 0x89, 0x82, 0xa2, 0xa1, 0x84, 0xa7, 0x98, 0xa1, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x87, 0x87, 0x82, 0x85, 0x81, 0x83, 0x83, 0x85, 0x8c,
+ 0x87, 0x7f, 0xa2, 0x9d, 0x88, 0x8d, 0x88, 0x8b, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xbb, 0x00, 0xc5, 0x00, 0xb4, 0x87, 0x86, 0x86, 0x84, 0x83,
+ 0x86, 0x87, 0x87, 0x87, 0x80, 0x82, 0x7f, 0x86, 0x86, 0x88, 0x8a,
+ 0x84, 0x7e, 0x9d, 0x9c, 0x82, 0x8d, 0x88, 0x8b, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xbd, 0x00, 0xc7, 0x00, 0xb7, 0x87, 0x85, 0x85, 0x84, 0x83,
+ 0x86, 0x86, 0x86, 0x88, 0x81, 0x83, 0x80, 0x83, 0x84, 0x85, 0x8a,
+ 0x85, 0x7e, 0x9c, 0x9b, 0x85, 0x80, 0x80, 0x80, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xc0, 0x00, 0xca, 0x00, 0xbb, 0x87, 0x86, 0x85, 0x83, 0x83,
+ 0x85, 0x86, 0x86, 0x88, 0x81, 0x83, 0x80, 0x84, 0x85, 0x86, 0x89,
+ 0x83, 0x7d, 0x9c, 0x99, 0x87, 0x7b, 0x7b, 0x7c, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xc4, 0x00, 0xcd, 0x00, 0xbe, 0x87, 0x86, 0x85, 0x83, 0x83,
+ 0x86, 0x85, 0x85, 0x87, 0x81, 0x82, 0x80, 0x82, 0x82, 0x83, 0x8a,
+ 0x85, 0x7f, 0x9f, 0x9b, 0x86, 0xb4, 0xa1, 0xac, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xc7, 0x00, 0xd0, 0x00, 0xc2, 0x87, 0x85, 0x85, 0x83, 0x82,
+ 0x85, 0x85, 0x85, 0x86, 0x82, 0x83, 0x80, 0x82, 0x82, 0x84, 0x87,
+ 0x86, 0x80, 0x9e, 0x9a, 0x87, 0xa7, 0x98, 0xa1, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xca, 0x00, 0xd2, 0x00, 0xc5, 0x87, 0x85, 0x84, 0x82, 0x82,
+ 0x84, 0x85, 0x85, 0x86, 0x81, 0x82, 0x7f, 0x82, 0x82, 0x84, 0x88,
+ 0x86, 0x81, 0x9d, 0x98, 0x86, 0x8d, 0x88, 0x8b, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xce, 0x00, 0xd6, 0x00, 0xca, 0x86, 0x85, 0x84, 0x83, 0x83,
+ 0x85, 0x84, 0x84, 0x85, 0x81, 0x82, 0x80, 0x81, 0x81, 0x82, 0x89,
+ 0x86, 0x81, 0x9c, 0x97, 0x86, 0xa7, 0x98, 0xa1, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xd1, 0x00, 0xd9, 0x00, 0xce, 0x86, 0x84, 0x83, 0x83, 0x82,
+ 0x85, 0x85, 0x85, 0x86, 0x81, 0x83, 0x81, 0x82, 0x82, 0x83, 0x86,
+ 0x83, 0x7f, 0x99, 0x95, 0x86, 0xbb, 0xa4, 0xb3, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xd4, 0x00, 0xdb, 0x00, 0xd1, 0x86, 0x85, 0x83, 0x83, 0x82,
+ 0x85, 0x84, 0x84, 0x85, 0x80, 0x83, 0x82, 0x80, 0x80, 0x81, 0x87,
+ 0x84, 0x81, 0x98, 0x93, 0x85, 0xae, 0x9c, 0xa8, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xd8, 0x00, 0xde, 0x00, 0xd6, 0x86, 0x84, 0x83, 0x81, 0x81,
+ 0x83, 0x85, 0x85, 0x85, 0x82, 0x83, 0x81, 0x81, 0x81, 0x83, 0x86,
+ 0x84, 0x80, 0x98, 0x91, 0x85, 0x7b, 0x7b, 0x7c, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xdc, 0x00, 0xe2, 0x00, 0xda, 0x85, 0x84, 0x83, 0x82, 0x82,
+ 0x84, 0x84, 0x84, 0x85, 0x81, 0x82, 0x82, 0x80, 0x80, 0x81, 0x83,
+ 0x82, 0x7f, 0x99, 0x93, 0x86, 0x94, 0x8b, 0x92, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xdf, 0x00, 0xe5, 0x00, 0xde, 0x85, 0x84, 0x82, 0x82, 0x82,
+ 0x84, 0x83, 0x83, 0x84, 0x81, 0x81, 0x80, 0x83, 0x82, 0x84, 0x82,
+ 0x81, 0x7f, 0x99, 0x92, 0x86, 0x7b, 0x7b, 0x7c, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xe4, 0x00, 0xe9, 0x00, 0xe3, 0x84, 0x83, 0x82, 0x81, 0x81,
+ 0x82, 0x83, 0x83, 0x84, 0x80, 0x81, 0x80, 0x83, 0x83, 0x84, 0x80,
+ 0x81, 0x7c, 0x99, 0x92, 0x87, 0xa1, 0x93, 0x9d, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xe4, 0x00, 0xe9, 0x00, 0xe3, 0x85, 0x84, 0x83, 0x81, 0x81,
+ 0x82, 0x82, 0x82, 0x83, 0x80, 0x81, 0x80, 0x81, 0x80, 0x82, 0x83,
+ 0x82, 0x80, 0x91, 0x8d, 0x83, 0x9a, 0x90, 0x96, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xe4, 0x00, 0xe9, 0x00, 0xe3, 0x84, 0x83, 0x82, 0x81, 0x81,
+ 0x82, 0x83, 0x83, 0x84, 0x80, 0x81, 0x80, 0x81, 0x80, 0x82, 0x83,
+ 0x81, 0x7f, 0x91, 0x8c, 0x82, 0x8d, 0x88, 0x8b, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xe4, 0x00, 0xe9, 0x00, 0xe3, 0x84, 0x83, 0x82, 0x81, 0x81,
+ 0x82, 0x83, 0x83, 0x83, 0x82, 0x82, 0x81, 0x81, 0x80, 0x82, 0x82,
+ 0x82, 0x7f, 0x94, 0x89, 0x84, 0x80, 0x80, 0x80, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xe4, 0x00, 0xe9, 0x00, 0xe3, 0x84, 0x83, 0x82, 0x81, 0x81,
+ 0x82, 0x83, 0x83, 0x83, 0x82, 0x82, 0x81, 0x81, 0x80, 0x82, 0x83,
+ 0x82, 0x7f, 0x91, 0x85, 0x81, 0x80, 0x80, 0x80, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xe4, 0x00, 0xe9, 0x00, 0xe3, 0x84, 0x83, 0x82, 0x81, 0x81,
+ 0x82, 0x83, 0x83, 0x83, 0x80, 0x80, 0x7f, 0x83, 0x82, 0x84, 0x83,
+ 0x82, 0x7f, 0x90, 0x84, 0x81, 0x9a, 0x90, 0x96, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xe4, 0x00, 0xe9, 0x00, 0xe3, 0x84, 0x83, 0x82, 0x80, 0x80,
+ 0x82, 0x83, 0x83, 0x83, 0x80, 0x80, 0x7f, 0x80, 0x80, 0x81, 0x81,
+ 0x82, 0x83, 0x7e, 0x80, 0x7c, 0xa4, 0x97, 0x9f, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xe9, 0x00, 0xec, 0x00, 0xe8, 0x84, 0x83, 0x82, 0x81, 0x81,
+ 0x82, 0x82, 0x82, 0x83, 0x7f, 0x7f, 0x7f, 0x81, 0x80, 0x82, 0x83,
+ 0x83, 0x84, 0x79, 0x7c, 0x79, 0xb1, 0xa0, 0xaa, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xed, 0x00, 0xf0, 0x00, 0xec, 0x83, 0x83, 0x82, 0x80, 0x80,
+ 0x81, 0x82, 0x82, 0x82, 0x7f, 0x7f, 0x7e, 0x81, 0x81, 0x82, 0x80,
+ 0x81, 0x81, 0x84, 0x84, 0x83, 0x80, 0x80, 0x80, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xf1, 0x00, 0xf4, 0x00, 0xf1, 0x83, 0x82, 0x82, 0x80, 0x80,
+ 0x81, 0x82, 0x82, 0x82, 0x80, 0x80, 0x80, 0x80, 0x80, 0x81, 0x7d,
+ 0x7e, 0x7f, 0x84, 0x84, 0x83, 0x80, 0x80, 0x80, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xf6, 0x00, 0xf7, 0x00, 0xf5, 0x82, 0x82, 0x81, 0x80, 0x80,
+ 0x80, 0x82, 0x82, 0x82, 0x80, 0x80, 0x80, 0x7f, 0x7f, 0x7f, 0x82,
+ 0x82, 0x82, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x00, 0xfa, 0x00, 0xfb, 0x00, 0xfa, 0x81, 0x81, 0x81, 0x80, 0x80,
+ 0x80, 0x82, 0x82, 0x82, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
+ 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
+ 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
+ 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+ { 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x80, 0x80, 0x80, 0x80, 0x80,
+ 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80,
+ 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x00, 0x00, 0x00,
+ 0x00, 0x00 }
+};
+
+unsigned char vint_table[S6E3HA2_VINT_STATUS_MAX] = {
+ 0x18, 0x19, 0x1a, 0x1b, 0x1c,
+ 0x1d, 0x1e, 0x1f, 0x20, 0x21
+};
+
+struct s6e3ha2 {
+ struct device *dev;
+ struct drm_panel panel;
+ struct backlight_device *bl_dev;
+
+ struct regulator_bulk_data supplies[2];
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ /* This field is tested by functions directly accessing DSI bus before
+ * transfer, transfer is skipped if it is set. In case of transfer
+ * failure or unexpected response the field is set to error value.
+ * Such construct allows to eliminate many checks in higher level
+ * functions.
+ */
+ int error;
+};
+
+static int s6e3ha2_clear_error(struct s6e3ha2 *ctx)
+{
+ int ret = ctx->error;
+
+ ctx->error = 0;
+ return ret;
+}
+
+static void s6e3ha2_dcs_write(struct s6e3ha2 *ctx, const void *data, size_t len)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ ssize_t ret;
+
+ if (ctx->error < 0)
+ return;
+
+ ret = mipi_dsi_dcs_write_buffer(dsi, data, len);
+ if (ret < 0) {
+ dev_err(ctx->dev, "error %zd writing dcs seq: %*ph\n",
+ ret, (int)len, data);
+ ctx->error = ret;
+ }
+}
+
+#define s6e3ha2_dcs_write_seq_static(ctx, seq...) do { \
+ static const u8 d[] = { seq }; \
+ s6e3ha2_dcs_write(ctx, d, ARRAY_SIZE(d)); \
+} while (0)
+
+static void s6e3ha2_test_key_on_f0(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xf0, 0x5a, 0x5a);
+}
+
+static void s6e3ha2_test_key_off_f0(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xf0, 0xa5, 0xa5);
+}
+
+static void s6e3ha2_test_key_on_fc(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xfc, 0x5a, 0x5a);
+}
+
+static void s6e3ha2_test_key_off_fc(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xfc, 0xa5, 0xa5);
+}
+
+static void s6e3ha2_single_dsi_set(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xf2, 0x67);
+ s6e3ha2_dcs_write_seq_static(ctx, 0xf9, 0x09);
+}
+
+static void s6e3ha2_freq_calibration(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xfd, 0x1c);
+ s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20, 0x39);
+ s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0xa0);
+ s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x20);
+ s6e3ha2_dcs_write_seq_static(ctx, 0xce, 0x03, 0x3b, 0x12, 0x62,
+ 0x40, 0x80, 0xc0, 0x28, 0x28, 0x28, 0x28, 0x39, 0xc5);
+}
+
+static void s6e3ha2_aor_control(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xb2, 0x03, 0x10);
+}
+
+static void s6e3ha2_caps_elvss_set(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xb6, 0x9c, 0x0a);
+}
+
+static void s6e3ha2_acl_off(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0x55, 0x00);
+}
+
+static void s6e3ha2_acl_off_opr(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xb5, 0x40);
+}
+
+static void s6e3ha2_test_global(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xb0, 0x07);
+}
+
+static void s6e3ha2_test(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xb8, 0x19);
+}
+
+static void s6e3ha2_touch_hsync_on1(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx,
+ 0xbd, 0x33, 0x11, 0x02, 0x16, 0x02, 0x16);
+}
+
+static void s6e3ha2_pentile_control(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xc0, 0x00, 0x00, 0xd8, 0xd8);
+}
+
+static void s6e3ha2_poc_global(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xb0, 0x20);
+}
+
+static void s6e3ha2_poc_setting(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xfe, 0x08);
+}
+
+static void s6e3ha2_pcd_set_off(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xcc, 0x40, 0x51);
+}
+
+static void s6e3ha2_err_fg_set(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xed, 0x44);
+}
+
+static void s6e3ha2_hbm_off(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0x53, 0x00);
+}
+
+static void s6e3ha2_te_start_setting(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xb9, 0x10, 0x09, 0xff, 0x00, 0x09);
+}
+
+static void s6e3ha2_gamma_update(struct s6e3ha2 *ctx)
+{
+ s6e3ha2_dcs_write_seq_static(ctx, 0xf7, 0x03);
+ ndelay(100); /* need for 100ns delay */
+ s6e3ha2_dcs_write_seq_static(ctx, 0xf7, 0x00);
+}
+
+static int s6e3ha2_get_brightness(struct backlight_device *bl_dev)
+{
+ return bl_dev->props.brightness;
+}
+
+static void s6e3ha2_set_vint(struct s6e3ha2 *ctx)
+{
+ struct backlight_device *bl_dev = ctx->bl_dev;
+ unsigned int brightness = bl_dev->props.brightness;
+ unsigned char data[] = { 0xf4, 0x8b,
+ vint_table[brightness * (S6E3HA2_VINT_STATUS_MAX - 1) /
+ S6E3HA2_MAX_BRIGHTNESS] };
+
+ s6e3ha2_dcs_write(ctx, data, 3);
+}
+
+static unsigned int s6e3ha2_get_brightness_index(unsigned int brightness)
+{
+ return (brightness * (S6E3HA2_NUM_GAMMA_STEPS - 1)) /
+ S6E3HA2_MAX_BRIGHTNESS;
+}
+
+static int s6e3ha2_update_gamma(struct s6e3ha2 *ctx, unsigned int brightness)
+{
+ struct backlight_device *bl_dev = ctx->bl_dev;
+ unsigned int index = s6e3ha2_get_brightness_index(brightness);
+ u8 data[S6E3HA2_GAMMA_CMD_CNT + 1] = { 0xca, };
+
+ memcpy(data + 1, gamma_tbl + index, S6E3HA2_GAMMA_CMD_CNT);
+ s6e3ha2_dcs_write(ctx, data, ARRAY_SIZE(data));
+
+ s6e3ha2_gamma_update(ctx);
+ bl_dev->props.brightness = brightness;
+
+ return 0;
+}
+
+static int s6e3ha2_set_brightness(struct backlight_device *bl_dev)
+{
+ struct s6e3ha2 *ctx = (struct s6e3ha2 *)bl_get_data(bl_dev);
+ unsigned int brightness = bl_dev->props.brightness;
+
+ if (brightness < S6E3HA2_MIN_BRIGHTNESS ||
+ brightness > bl_dev->props.max_brightness) {
+ dev_err(ctx->dev, "Invalid brightness: %u\n", brightness);
+ return -EINVAL;
+ }
+
+ if (bl_dev->props.power > FB_BLANK_NORMAL)
+ return -EPERM;
+
+ s6e3ha2_test_key_on_f0(ctx);
+ s6e3ha2_update_gamma(ctx, brightness);
+ s6e3ha2_aor_control(ctx);
+ s6e3ha2_set_vint(ctx);
+ s6e3ha2_test_key_off_f0(ctx);
+
+ return ctx->error;
+}
+
+static const struct backlight_ops s6e3ha2_bl_ops = {
+ .get_brightness = s6e3ha2_get_brightness,
+ .update_status = s6e3ha2_set_brightness,
+};
+
+static void s6e3ha2_panel_init(struct s6e3ha2 *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+
+ mipi_dsi_dcs_exit_sleep_mode(dsi);
+ usleep_range(5000, 6000);
+
+ s6e3ha2_test_key_on_f0(ctx);
+ s6e3ha2_single_dsi_set(ctx);
+ s6e3ha2_test_key_on_fc(ctx);
+ s6e3ha2_freq_calibration(ctx);
+ s6e3ha2_test_key_off_fc(ctx);
+ s6e3ha2_test_key_off_f0(ctx);
+}
+
+static int s6e3ha2_power_off(struct s6e3ha2 *ctx)
+{
+ return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+}
+
+static int s6e3ha2_disable(struct drm_panel *panel)
+{
+ struct s6e3ha2 *ctx = container_of(panel, struct s6e3ha2, panel);
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+
+ mipi_dsi_dcs_enter_sleep_mode(dsi);
+ if (ctx->error != 0)
+ goto err;
+
+ mipi_dsi_dcs_set_display_off(dsi);
+ if (ctx->error != 0)
+ goto err;
+
+ msleep(40);
+ ctx->bl_dev->props.power = FB_BLANK_NORMAL;
+
+ return 0;
+err:
+ return ctx->error;
+}
+
+static int s6e3ha2_unprepare(struct drm_panel *panel)
+{
+ struct s6e3ha2 *ctx = container_of(panel, struct s6e3ha2, panel);
+ int ret;
+
+ ret = s6e3ha2_clear_error(ctx);
+ if (!ret)
+ ctx->bl_dev->props.power = FB_BLANK_POWERDOWN;
+
+ return s6e3ha2_power_off(ctx);
+}
+
+static int s6e3ha2_power_on(struct s6e3ha2 *ctx)
+{
+ int ret;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+ if (ret < 0)
+ return ret;
+
+ msleep(120);
+
+ gpiod_set_value(ctx->enable_gpio, 0);
+ usleep_range(5000, 6000);
+ gpiod_set_value(ctx->enable_gpio, 1);
+
+ gpiod_set_value(ctx->reset_gpio, 1);
+ usleep_range(5000, 6000);
+ gpiod_set_value(ctx->reset_gpio, 0);
+ usleep_range(5000, 6000);
+
+ return 0;
+}
+static int s6e3ha2_prepare(struct drm_panel *panel)
+{
+ struct s6e3ha2 *ctx = container_of(panel, struct s6e3ha2, panel);
+ int ret;
+
+ ret = s6e3ha2_power_on(ctx);
+ if (ret < 0)
+ return ret;
+
+ s6e3ha2_panel_init(ctx);
+
+ ret = s6e3ha2_clear_error(ctx);
+ if (ret < 0) {
+ s6e3ha2_power_off(ctx);
+ return ret;
+ }
+
+ ctx->bl_dev->props.power = FB_BLANK_NORMAL;
+
+ return 0;
+}
+
+static int s6e3ha2_enable(struct drm_panel *panel)
+{
+ struct s6e3ha2 *ctx = container_of(panel, struct s6e3ha2, panel);
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+
+ /* common setting */
+ mipi_dsi_dcs_set_tear_on(dsi, MIPI_DSI_DCS_TEAR_MODE_VBLANK);
+
+ s6e3ha2_test_key_on_f0(ctx);
+ s6e3ha2_test_key_on_fc(ctx);
+ s6e3ha2_touch_hsync_on1(ctx);
+ s6e3ha2_pentile_control(ctx);
+ s6e3ha2_poc_global(ctx);
+ s6e3ha2_poc_setting(ctx);
+ s6e3ha2_test_key_off_fc(ctx);
+
+ /* pcd setting off for TB */
+ s6e3ha2_pcd_set_off(ctx);
+ s6e3ha2_err_fg_set(ctx);
+ s6e3ha2_te_start_setting(ctx);
+
+ /* brightness setting */
+ s6e3ha2_set_brightness(ctx->bl_dev);
+ s6e3ha2_aor_control(ctx);
+ s6e3ha2_caps_elvss_set(ctx);
+ s6e3ha2_gamma_update(ctx);
+ s6e3ha2_acl_off(ctx);
+ s6e3ha2_acl_off_opr(ctx);
+ s6e3ha2_hbm_off(ctx);
+
+ /* elvss temp compensation */
+ s6e3ha2_test_global(ctx);
+ s6e3ha2_test(ctx);
+ s6e3ha2_test_key_off_f0(ctx);
+
+ mipi_dsi_dcs_set_display_on(dsi);
+ if (ctx->error != 0)
+ return ctx->error;
+
+ ctx->bl_dev->props.power = FB_BLANK_UNBLANK;
+
+ return 0;
+}
+
+static const struct drm_display_mode default_mode = {
+ .clock = 14874,
+ .hdisplay = 1440,
+ .hsync_start = 1440 + 1,
+ .hsync_end = 1440 + 1 + 1,
+ .htotal = 1440 + 1 + 1 + 1,
+ .vdisplay = 2560,
+ .vsync_start = 2560 + 1,
+ .vsync_end = 2560 + 1 + 1,
+ .vtotal = 2560 + 1 + 1 + 15,
+ .vrefresh = 60,
+ .flags = 0,
+};
+
+static int s6e3ha2_get_modes(struct drm_panel *panel)
+{
+ struct drm_connector *connector = panel->connector;
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(panel->drm, &default_mode);
+ if (!mode) {
+ DRM_ERROR("failed to create a new display mode\n");
+ DRM_ERROR("failed to add mode %ux%ux@%u\n",
+ default_mode.hdisplay, default_mode.vdisplay,
+ default_mode.vrefresh);
+ return -ENOMEM;
+ }
+
+ drm_mode_set_name(mode);
+
+ mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
+ drm_mode_probed_add(connector, mode);
+
+ connector->display_info.width_mm = 71;
+ connector->display_info.height_mm = 125;
+
+ return 1;
+}
+
+static const struct drm_panel_funcs s6e3ha2_drm_funcs = {
+ .disable = s6e3ha2_disable,
+ .unprepare = s6e3ha2_unprepare,
+ .prepare = s6e3ha2_prepare,
+ .enable = s6e3ha2_enable,
+ .get_modes = s6e3ha2_get_modes,
+};
+
+static int s6e3ha2_probe(struct mipi_dsi_device *dsi)
+{
+ struct device *dev = &dsi->dev;
+ struct s6e3ha2 *ctx;
+ int ret;
+
+ ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ mipi_dsi_set_drvdata(dsi, ctx);
+
+ ctx->dev = dev;
+
+ dsi->lanes = 4;
+ dsi->format = MIPI_DSI_FMT_RGB888;
+ dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS;
+
+ ctx->supplies[0].supply = "vdd3";
+ ctx->supplies[1].supply = "vci";
+
+ ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ctx->supplies),
+ ctx->supplies);
+ if (ret < 0) {
+ dev_err(dev, "failed to get regulators: %d\n", ret);
+ return ret;
+ }
+
+ ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(ctx->reset_gpio)) {
+ dev_err(dev, "cannot get reset-gpios %ld\n",
+ PTR_ERR(ctx->reset_gpio));
+ return PTR_ERR(ctx->reset_gpio);
+ }
+
+ ctx->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->enable_gpio)) {
+ dev_err(dev, "cannot get enable-gpios %ld\n",
+ PTR_ERR(ctx->enable_gpio));
+ return PTR_ERR(ctx->enable_gpio);
+ }
+
+ ctx->bl_dev = backlight_device_register("s6e3ha2", dev, ctx,
+ &s6e3ha2_bl_ops, NULL);
+ if (IS_ERR(ctx->bl_dev)) {
+ dev_err(dev, "failed to register backlight device\n");
+ return PTR_ERR(ctx->bl_dev);
+ }
+
+ ctx->bl_dev->props.max_brightness = S6E3HA2_MAX_BRIGHTNESS;
+ ctx->bl_dev->props.brightness = S6E3HA2_DEFAULT_BRIGHTNESS;
+ ctx->bl_dev->props.power = FB_BLANK_POWERDOWN;
+
+ drm_panel_init(&ctx->panel);
+ ctx->panel.dev = dev;
+ ctx->panel.funcs = &s6e3ha2_drm_funcs;
+
+ ret = drm_panel_add(&ctx->panel);
+ if (ret < 0)
+ goto unregister_backlight;
+
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0)
+ goto remove_panel;
+
+ return ret;
+
+remove_panel:
+ drm_panel_remove(&ctx->panel);
+
+unregister_backlight:
+ backlight_device_unregister(ctx->bl_dev);
+
+ return ret;
+}
+
+static int s6e3ha2_remove(struct mipi_dsi_device *dsi)
+{
+ struct s6e3ha2 *ctx = mipi_dsi_get_drvdata(dsi);
+
+ mipi_dsi_detach(dsi);
+ drm_panel_remove(&ctx->panel);
+ backlight_device_unregister(ctx->bl_dev);
+
+ return 0;
+}
+
+static const struct of_device_id s6e3ha2_of_match[] = {
+ { .compatible = "samsung,s6e3ha2" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, s6e3ha2_of_match);
+
+static struct mipi_dsi_driver s6e3ha2_driver = {
+ .probe = s6e3ha2_probe,
+ .remove = s6e3ha2_remove,
+ .driver = {
+ .name = "panel-samsung-s6e3ha2",
+ .of_match_table = s6e3ha2_of_match,
+ },
+};
+module_mipi_dsi_driver(s6e3ha2_driver);
+
+MODULE_AUTHOR("Donghwa Lee <dh09.lee@samsung.com>");
+MODULE_AUTHOR("Hyungwon Hwang <human.hwang@samsung.com>");
+MODULE_AUTHOR("Hoegeun Kwon <hoegeun.kwon@samsung.com>");
+MODULE_DESCRIPTION("MIPI-DSI based s6e3ha2 AMOLED Panel Driver");
+MODULE_LICENSE("GPL v2");
--
1.9.1
^ permalink raw reply related
* [PATCH v4 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
From: Hoegeun Kwon @ 2017-01-04 6:58 UTC (permalink / raw)
To: robh, thierry.reding, airlied, kgene, krzk, inki.dae
Cc: dri-devel, linux-kernel, devicetree, linux-samsung-soc, a.hajda,
cw00.choi, jh80.chung, Hyungwon Hwang, Hoegeun Kwon
In-Reply-To: <1483513115-3068-1-git-send-email-hoegeun.kwon@samsung.com>
From: Hyungwon Hwang <human.hwang@samsung.com>
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index 5b9451d..b3ba1ac 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -304,11 +304,28 @@
reg = <1>;
dsi_out: endpoint {
+ remote-endpoint = <&panel_in>;
samsung,burst-clock-frequency = <512000000>;
samsung,esc-clock-frequency = <16000000>;
};
};
};
+
+ panel@0 {
+ compatible = "samsung,s6e3ha2";
+ reg = <0>;
+ vdd3-supply = <&ldo27_reg>;
+ vci-supply = <&ldo28_reg>;
+ reset-gpios = <&gpg0 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&gpf1 5 GPIO_ACTIVE_HIGH>;
+ te-gpios = <&gpf1 3 GPIO_ACTIVE_HIGH>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
};
&hsi2c_0 {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] ASoC: core: Add API to use DMI name in sound card long name
From: Mengdong Lin @ 2017-01-04 7:03 UTC (permalink / raw)
To: Pierre-Louis Bossart, Liam Girdwood, Lin, Mengdong
Cc: tiwai@suse.de, Koul, Vinod, alsa-devel@alsa-project.org,
broonie@kernel.org
In-Reply-To: <984e6c66-c1c9-c37b-f6b6-d357cd967d48@intel.com>
On 01/04/2017 04:09 AM, Pierre-Louis Bossart wrote:
>
>>>> I dont think we need vendor (it just makes it too long). The product
>>>> or board
>>>> name should be unique enough for us to load the correct files.
>>>>
>>>> Liam
>>> Yes, from the sample machines I checked, product or board name are
>>> unique. But I feel there might be the risk that two vendors happen to
>>> use the same product or board name, e.g. "T100TA".
>> I think this would be problematic from a legal/marketing position from
>> two different vendors so it would be unlikely.
>
> Please don't remove the manufacturer name for now...
> Some vendors use product names that are indeed unique and easy enough to
> remember, but others like Lenovo use "1952W5R" or "20C3001VHH" (real
> examples you can Google to see I am not making this up). The board name
> can also be "SKG18 t". I really have no appetite for a UCM directory
> called 20C3001VHH.SKG18t :-)
> I would also be ready to bet that smaller manufacturers in the Chinese
> ecosystem use similar product names at the DMI level. removing the
> vendor name would likely result in mistakes.
> You really want the manufacturer name to make the maintenance of these
> files easier on the rest of us. Sometimes the DMI version field is
> actually more self-explanatory, e.g. "ThinkPad 60" or "ThinkPad 10" for
> the two Lenovo examples, maybe this is something we ought to look at.
>
>
So we'll keep the manufacturer name.
And let's put the "Product version" as well if available, Liam?
I also observed Lenovo puts the the user-friendly name in the product
version like "Thinkpad S5 Yoga 15", while it product name is
"20DQA00KCD", no self-explanatory.
It seems different manufacturer tend to put self-explanatory name in
different fields:
Lenovo thinkpad: product version
Dell: product name
ASUS: both product name and board name
Intel: board name
Do we want some table to specify the field we want for major vendors? So
we may just pick the most valuable DMI field for the card long name, for
those manufacturers to save the space. But it may not scale if the
manufacturer change their preference or use different way for different
product series, since I only checked a few machines by a few vendors.
Also I wonder if we find the key word like "Dell, HP or ASUS", may we
not use verbatim copy on the vendor name but just use these key words?
This can also save some space.
Thanks
Mengdong
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
^ permalink raw reply
* Re: [PATCH v4 0/5] road to reentrant real_path
From: Jeff King @ 2017-01-04 7:01 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Brandon Williams, git, sbeller, jacob.keller, gitster, ramsay,
j6t, pclouds, larsxschneider
In-Reply-To: <3f9a530c-402f-f276-4721-fa6a8a6fef41@web.de>
On Wed, Jan 04, 2017 at 07:56:02AM +0100, Torsten Bögershausen wrote:
> On 04.01.17 01:48, Jeff King wrote:
> > On Tue, Jan 03, 2017 at 11:09:18AM -0800, Brandon Williams wrote:
> >
> >> Only change with v4 is in [1/5] renaming the #define MAXSYMLINKS back to
> >> MAXDEPTH due to a naming conflict brought up by Lars Schneider.
> >
> > Hmm. Isn't MAXSYMLINKS basically what you want here, though? It what's
> > what all other similar functions will be using.
> >
> > The only problem was that we were redefining the macro. So maybe:
> >
> > #ifndef MAXSYMLINKS
> > #define MAXSYMLINKS 5
> > #endif
> >
> > would be a good solution?
> Why 5 ? (looking at the 20..30 below)
> And why 5 on one system and e.g. on my Mac OS
> #define MAXSYMLINKS 32
I mentioned "5" because that is the current value of MAXDEPTH. I do
think it would be reasonable to bump it to something higher.
> Would the same value value for all Git installations on all platforms make sense?
> #define GITMAXSYMLINKS 20
I think it's probably more important to match the rest of the OS, so
that open("foo") and realpath("foo") behave similarly on the same
system. Though I think even that isn't always possible, as the limit is
dynamic on some systems.
I think the idea of the 20-30 range is that it's small enough to catch
an infinite loop quickly, and large enough that nobody will ever hit it
in practice. :)
-Peff
^ permalink raw reply
* [PATCH v6 06/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI
From: Hanjun Guo @ 2017-01-04 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8cdc4bfa-18a3-b9f6-aaba-0efe1f75fb40@semihalf.com>
Hi Tomasz,
On 2017/1/3 15:41, Tomasz Nowicki wrote:
> Hi,
>
> Can we merge patch 4 & 6 into one patch so that we keep refactoring part
> as one piece ? I do not see a reason to keep them separate or have patch
> 5 in between. You can refactor what needs to be refactored, add
> necessary functions to iort.c and then support ACPI for
> irq-gic-v3-its-platform-msi.c
There are two functions here,
- retrieve the dev id from IORT which was DT based only;
- init the platform msi domain from MADT;
For each of them split it into two steps,
- refactor the code for ACPI later and it's easy for review
because wen can easily to figure out it has functional
change or not
- add ACPI functionality
Does it make sense?
Thanks
Hanjun
^ permalink raw reply
* Re: [PATCH v6 06/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI
From: Hanjun Guo @ 2017-01-04 7:02 UTC (permalink / raw)
To: Tomasz Nowicki, Marc Zyngier, Rafael J. Wysocki,
Lorenzo Pieralisi
Cc: linux-acpi, linux-arm-kernel, linux-kernel, linuxarm,
Thomas Gleixner, Greg KH, Ma Jun, Kefeng Wang, Agustin Vega-Frias,
Sinan Kaya, charles.garcia-tobin, huxinwei, yimin, Jon Masters
In-Reply-To: <8cdc4bfa-18a3-b9f6-aaba-0efe1f75fb40@semihalf.com>
Hi Tomasz,
On 2017/1/3 15:41, Tomasz Nowicki wrote:
> Hi,
>
> Can we merge patch 4 & 6 into one patch so that we keep refactoring part
> as one piece ? I do not see a reason to keep them separate or have patch
> 5 in between. You can refactor what needs to be refactored, add
> necessary functions to iort.c and then support ACPI for
> irq-gic-v3-its-platform-msi.c
There are two functions here,
- retrieve the dev id from IORT which was DT based only;
- init the platform msi domain from MADT;
For each of them split it into two steps,
- refactor the code for ACPI later and it's easy for review
because wen can easily to figure out it has functional
change or not
- add ACPI functionality
Does it make sense?
Thanks
Hanjun
^ permalink raw reply
* Re: [PATCH] rcu: fix the OOM problem of huge IP abnormal packet traffic
From: Ding Tianhong @ 2017-01-04 7:02 UTC (permalink / raw)
To: paulmck
Cc: davem, Eric Dumazet, josh, rostedt, mathieu.desnoyers,
jiangshanlai, linux-kernel@vger.kernel.org
In-Reply-To: <20170104005746.GA10429@linux.vnet.ibm.com>
On 2017/1/4 8:57, Paul E. McKenney wrote:
> On Wed, Dec 28, 2016 at 04:13:15PM -0800, Paul E. McKenney wrote:
>> On Wed, Dec 28, 2016 at 01:58:06PM +0800, Ding Tianhong wrote:
>>> Hi, Paul:
>>>
>>> I try to debug this problem and found this solution could work well for both problem scene.
>>>
>>>
>>> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
>>> index 85c5a88..dbc14a7 100644
>>> --- a/kernel/rcu/tree_plugin.h
>>> +++ b/kernel/rcu/tree_plugin.h
>>> @@ -2172,7 +2172,7 @@ static int rcu_nocb_kthread(void *arg)
>>> if (__rcu_reclaim(rdp->rsp->name, list))
>>> cl++;
>>> c++;
>>> - local_bh_enable();
>>> + _local_bh_enable();
>>> cond_resched_rcu_qs();
>>> list = next;
>>> }
>>>
>>>
>>> The cond_resched_rcu_qs() would process the softirq if the softirq is pending, so no need to use
>>> local_bh_enable() to process the softirq twice here, and it will avoid OOM when huge packets arrives,
>>> what do you think about it? Please give me some suggestion.
>>
>> From what I can see, there is absolutely no guarantee that
>> cond_resched_rcu_qs() will do local_bh_enable(), and thus no guarantee
>> that it will process any pending softirqs -- and that is not part of
>> its job in any case. So I cannot recommend the above patch.
>>
>> On efficient handling of large invalid packets (that is still the issue,
>> right?), I must defer to Dave and Eric.
>
> On the perhaps unlikely off-chance that there is a fix for this outside
> of networking, what symptoms are you seeing without this fix in place?
> Still RCU CPU stall warnings? Soft lockups? Something else?
>
> Thanx, Paul
>
Hi Paul:
I was still try to test and fix this by another way, but could explain more about this problem.
when the huge packets coming, the packets was abnormal and will be freed by dst_release->call_rcu(dst_destroy_rcu),
so the rcuos kthread will handle the dst_destroy_rcu to free them, but when the rcuos was looping ,I fould the local_bh_enable() will
call do_softirq to receive a certain number of packets which is abnormal and need to be free, but more packets is coming so when cond_resched_rcu_qs run,
it will do the ksoftirqd and do softirq again, so rcuos kthread need free more, it looks more and more worse and lead to OOM because many more packets need to
be freed.
So I think the do_softirq in the local_bh_enable is not need here, the cond_resched_rcu_qs() will handle the do_softirq once, it is enough.
and recently I found that the Eric has upstream a new patch named (softirq: Let ksoftirqd do its job) may fix this, and still test it, not get any results yet.
Thanks
Ding
>>> Thanks.
>>> Ding
>>>
>>> On 2016/11/21 9:28, Ding Tianhong wrote:
>>>>
>>>>
>>>> On 2016/11/21 8:13, Paul E. McKenney wrote:
>>>>> On Sat, Nov 19, 2016 at 12:22:09AM -0800, Paul E. McKenney wrote:
>>>>>> On Sat, Nov 19, 2016 at 03:50:32PM +0800, Ding Tianhong wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2016/11/18 21:01, Paul E. McKenney wrote:
>>>>>>>> On Fri, Nov 18, 2016 at 08:40:09PM +0800, Ding Tianhong wrote:
>>>>>>>>> The commit bedc196915 ("rcu: Fix soft lockup for rcu_nocb_kthread")
>>>>>>>>> will introduce a new problem that when huge IP abnormal packet arrived,
>>>>>>>>> it may cause OOM and break the kernel, just like this:
>>>>>>>>>
>>>>>>>>> [ 79.441538] mlx4_en: eth5: Leaving promiscuous mode steering mode:2
>>>>>>>>> [ 100.067032] ksoftirqd/0: page allocation failure: order:0, mode:0x120
>>>>>>>>> [ 100.067038] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G OE ----V------- 3.10.0-327.28.3.28.x86_64 #1
>>>>>>>>> [ 100.067039] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-20161018_184732-HGH1000003483 04/01/2014
>>>>>>>>> [ 100.067041] 0000000000000120 00000000b080d798 ffff8802afd5b968 ffffffff81638cb9
>>>>>>>>> [ 100.067045] ffff8802afd5b9f8 ffffffff81171380 0000000000000010 0000000000000000
>>>>>>>>> [ 100.067048] ffff8802befd8000 00000000ffffffff 0000000000000001 00000000b080d798
>>>>>>>>> [ 100.067050] Call Trace:
>>>>>>>>> [ 100.067057] [<ffffffff81638cb9>] dump_stack+0x19/0x1b
>>>>>>>>> [ 100.067062] [<ffffffff81171380>] warn_alloc_failed+0x110/0x180
>>>>>>>>> [ 100.067066] [<ffffffff81175b16>] __alloc_pages_nodemask+0x9b6/0xba0
>>>>>>>>> [ 100.067070] [<ffffffff8151e400>] ? skb_add_rx_frag+0x90/0xb0
>>>>>>>>> [ 100.067075] [<ffffffff811b6fba>] alloc_pages_current+0xaa/0x170
>>>>>>>>> [ 100.067080] [<ffffffffa06b9be0>] mlx4_alloc_pages.isra.24+0x40/0x170 [mlx4_en]
>>>>>>>>> [ 100.067083] [<ffffffffa06b9dec>] mlx4_en_alloc_frags+0xdc/0x220 [mlx4_en]
>>>>>>>>> [ 100.067086] [<ffffffff8152eeb8>] ? __netif_receive_skb+0x18/0x60
>>>>>>>>> [ 100.067088] [<ffffffff8152ef40>] ? netif_receive_skb+0x40/0xc0
>>>>>>>>> [ 100.067092] [<ffffffffa06bb521>] mlx4_en_process_rx_cq+0x5f1/0xec0 [mlx4_en]
>>>>>>>>> [ 100.067095] [<ffffffff8131027d>] ? list_del+0xd/0x30
>>>>>>>>> [ 100.067098] [<ffffffff8152c90f>] ? __napi_complete+0x1f/0x30
>>>>>>>>> [ 100.067101] [<ffffffffa06bbeef>] mlx4_en_poll_rx_cq+0x9f/0x170 [mlx4_en]
>>>>>>>>> [ 100.067103] [<ffffffff8152f372>] net_rx_action+0x152/0x240
>>>>>>>>> [ 100.067107] [<ffffffff81084d1f>] __do_softirq+0xef/0x280
>>>>>>>>> [ 100.067109] [<ffffffff81084ee0>] run_ksoftirqd+0x30/0x50
>>>>>>>>> [ 100.067114] [<ffffffff810ae93f>] smpboot_thread_fn+0xff/0x1a0
>>>>>>>>> [ 100.067117] [<ffffffff8163e269>] ? schedule+0x29/0x70
>>>>>>>>> [ 100.067120] [<ffffffff810ae840>] ? lg_double_unlock+0x90/0x90
>>>>>>>>> [ 100.067122] [<ffffffff810a5d4f>] kthread+0xcf/0xe0
>>>>>>>>> [ 100.067124] [<ffffffff810a5c80>] ? kthread_create_on_node+0x140/0x140
>>>>>>>>> [ 100.067127] [<ffffffff81649198>] ret_from_fork+0x58/0x90
>>>>>>>>> [ 100.067129] [<ffffffff810a5c80>] ? kthread_create_on_node+0x140/0x140
>>>>>>>>>
>>>>>>>>> ================================cut here=====================================
>>>>>>>>>
>>>>>>>>> The reason is that the huge abnormal IP packet will be received to net stack
>>>>>>>>> and be dropped finally by dst_release, and the dst_release would use the rcuos
>>>>>>>>> callback-offload kthread to free the packet, but the cond_resched_rcu_qs() will
>>>>>>>>> calling do_softirq() to receive more and more IP abnormal packets which will be
>>>>>>>>> throw into the RCU callbacks again later, the number of received packet is much
>>>>>>>>> greater than the number of packets freed, it will exhaust the memory and then OOM,
>>>>>>>>> so don't try to process any pending softirqs in the rcuos callback-offload kthread
>>>>>>>>> is a more effective solution.
>>>>>>>>
>>>>>>>> OK, but we could still have softirqs processed by the grace-period kthread
>>>>>>>> as a result of any number of other events. So this change might reduce
>>>>>>>> the probability of this problem, but it doesn't eliminate it.
>>>>>>>>
>>>>>>>> How huge are these huge IP packets? Is the underlying problem that they
>>>>>>>> are too large to use the memory-allocator fastpaths?
>>>>>>>>
>>>>>>>> Thanx, Paul
>>>>>>>>
>>>>>>>
>>>>>>> I use the 40G mellanox NiC to receive packet, and the testgine could send Mac abnormal packet and
>>>>>>> IP abnormal packet to full speed.
>>>>>>>
>>>>>>> The Mac abnormal packet would be dropped at low level and not be received to net stack,
>>>>>>> but the IP abnormal packet will introduce this problem, every packet will looks as new dst first and
>>>>>>> release later by dst_release because it is meaningless.
>>>>>>>
>>>>>>> dst_release->call_rcu(&dst->rcu_head, dst_destroy_rcu);
>>>>>>>
>>>>>>> so all packet will be freed until the rcuos callback-offload kthread processing, it will be a infinite loop
>>>>>>> if huge packet is coming because the do_softirq will load more and more packet to the rcuos processing kthread,
>>>>>>> so I still could not find a better way to fix this, btw, it is really hard to say the driver use too large memory-allocater
>>>>>>> fastpaths, there is no memory leak and the Ixgbe may meet the same problem too.
>>>>>
>>>>> And following up on my fastpath point -- from what I can see, one
>>>>> big effect of the large invalid packets is that they push processing
>>>>> off of a number of fastpaths. If these packets could be rejected with
>>>>> less per-packet processing, I bet that things would work much better.
>>>>>
>>>>> Thanx, Paul
>>>>
>>>> Yes, and I found the WARN_ON_ONCE(!irqs_disabled()) will be triggered if use _local_bh_enable here,
>>>> so I think we could ask some help from Eric and David how to reject the huge number packets.
>>>>
>>>> Thanks
>>>> Ding
>>>>
>>>>>
>>>>>> The overall effect of these two patches is to move from enabling bh
>>>>>> (and processing recent softirqs) to enabling bh without processing
>>>>>> recent softirqs. Is this really the correct way to solve this problem?
>>>>>> What about this solution is avoiding re-introducing the original
>>>>>> softlockups? Have you talked to the networking guys about this issue?
>>>>>>
>>>>>> Thanx, Paul
>>>>>>
>>>>>>> Thanks.
>>>>>>> Ding
>>>>>>>
>>>>>>>
>>>>>>>>> Fix commit bedc196915 ("rcu: Fix soft lockup for rcu_nocb_kthread")
>>>>>>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>>>>>>>
>>>>>>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>>>>>>> ---
>>>>>>>>> kernel/rcu/tree_plugin.h | 3 +--
>>>>>>>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
>>>>>>>>> index 85c5a88..760c3b5 100644
>>>>>>>>> --- a/kernel/rcu/tree_plugin.h
>>>>>>>>> +++ b/kernel/rcu/tree_plugin.h
>>>>>>>>> @@ -2172,8 +2172,7 @@ static int rcu_nocb_kthread(void *arg)
>>>>>>>>> if (__rcu_reclaim(rdp->rsp->name, list))
>>>>>>>>> cl++;
>>>>>>>>> c++;
>>>>>>>>> - local_bh_enable();
>>>>>>>>> - cond_resched_rcu_qs();
>>>>>>>>> + _local_bh_enable();
>>>>>>>>> list = next;
>>>>>>>>> }
>>>>>>>>> trace_rcu_batch_end(rdp->rsp->name, c, !!list, 0, 0, 1);
>>>>>>>>> --
>>>>>>>>> 1.9.0
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> .
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> .
>>>>>
>>>
>
>
> .
>
^ permalink raw reply
* [PATCH resend v4 2/3] ARM: dts: imx6: Support Savageboard dual
From: Milo Kim @ 2017-01-04 7:04 UTC (permalink / raw)
To: linux-arm-kernel
Common savageboard DT file is used for board support.
Add the vendor name and specify the dtb file for i.MX6Q build.
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-savageboard.dts | 51 ++++++++++++++++++++++
3 files changed, 53 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-savageboard.dts
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 16d3b5e7f5d1..552b63651ab9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -227,6 +227,7 @@ pine64 Pine64
pixcir PIXCIR MICROELECTRONICS Co., Ltd
plathome Plat'Home Co., Ltd.
plda PLDA
+poslab Poslab Technology Co., Ltd.
powervr PowerVR (deprecated, use img)
pulsedlight PulsedLight, Inc
qca Qualcomm Atheros, Inc.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb557b6..fb7f904a5235 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -357,6 +357,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-sabreauto.dtb \
imx6dl-sabrelite.dtb \
imx6dl-sabresd.dtb \
+ imx6dl-savageboard.dtb \
imx6dl-ts4900.dtb \
imx6dl-tx6dl-comtft.dtb \
imx6dl-tx6s-8034.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-savageboard.dts b/arch/arm/boot/dts/imx6dl-savageboard.dts
new file mode 100644
index 000000000000..b95469c520a4
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-savageboard.dts
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2017 Milo Kim <woogyom.kim@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-savageboard.dtsi"
+
+/ {
+ model = "Poslab SavageBoard Dual";
+ compatible = "poslab,imx6dl-savageboard", "fsl,imx6dl";
+};
--
2.11.0
^ permalink raw reply related
* [PATCH resend v4 2/3] ARM: dts: imx6: Support Savageboard dual
From: Milo Kim @ 2017-01-04 7:04 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Fabio Estevam, devicetree, linux-kernel, linux-arm-kernel,
Milo Kim
Common savageboard DT file is used for board support.
Add the vendor name and specify the dtb file for i.MX6Q build.
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-savageboard.dts | 51 ++++++++++++++++++++++
3 files changed, 53 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-savageboard.dts
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 16d3b5e7f5d1..552b63651ab9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -227,6 +227,7 @@ pine64 Pine64
pixcir PIXCIR MICROELECTRONICS Co., Ltd
plathome Plat'Home Co., Ltd.
plda PLDA
+poslab Poslab Technology Co., Ltd.
powervr PowerVR (deprecated, use img)
pulsedlight PulsedLight, Inc
qca Qualcomm Atheros, Inc.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb557b6..fb7f904a5235 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -357,6 +357,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-sabreauto.dtb \
imx6dl-sabrelite.dtb \
imx6dl-sabresd.dtb \
+ imx6dl-savageboard.dtb \
imx6dl-ts4900.dtb \
imx6dl-tx6dl-comtft.dtb \
imx6dl-tx6s-8034.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-savageboard.dts b/arch/arm/boot/dts/imx6dl-savageboard.dts
new file mode 100644
index 000000000000..b95469c520a4
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-savageboard.dts
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2017 Milo Kim <woogyom.kim@gmail.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-savageboard.dtsi"
+
+/ {
+ model = "Poslab SavageBoard Dual";
+ compatible = "poslab,imx6dl-savageboard", "fsl,imx6dl";
+};
--
2.11.0
^ permalink raw reply related
* [Intel-wired-lan] [jkirsher-next-queue:dev-queue] BUILD INCOMPLETE 6b07d327da8258671ea0bff784d884c4d30949d9
From: kbuild test robot @ 2017-01-04 7:05 UTC (permalink / raw)
To: intel-wired-lan
https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
6b07d327da8258671ea0bff784d884c4d30949d9 i40e: remove duplicate device id from pci table
drivers/net/ethernet/dec/tulip/uli526x.c:948:2: error: implicit declaration of function 'ethtool_convert_legacy_u32_to_link_mode' [-Werror=implicit-function-declaration]
drivers/net/ethernet/dlink/dl2k.c:1296:2: error: implicit declaration of function 'ethtool_convert_legacy_u32_to_link_mode' [-Werror=implicit-function-declaration]
drivers/net/mdio.c:496:2: error: implicit declaration of function 'ethtool_convert_legacy_u32_to_link_mode' [-Werror=implicit-function-declaration]
drivers/net/mdio.c:496: error: implicit declaration of function 'ethtool_convert_legacy_u32_to_link_mode'
Error ids grouped by kconfigs:
recent_errors
??? arm64-allmodconfig
??? ??? drivers-net-ethernet-dec-tulip-uli526x.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? ??? drivers-net-ethernet-dlink-dl2k.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? ??? drivers-net-mdio.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? i386-allyesconfig
??? ??? drivers-net-ethernet-dec-tulip-uli526x.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? ??? drivers-net-ethernet-dlink-dl2k.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? ??? drivers-net-mdio.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? ia64-allyesconfig
??? ??? drivers-net-ethernet-dec-tulip-uli526x.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? ??? drivers-net-ethernet-dlink-dl2k.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? ??? drivers-net-mdio.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? mips-ip27_defconfig
??? ??? drivers-net-mdio.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? x86_64-lkp
??? ??? drivers-net-ethernet-dec-tulip-uli526x.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? ??? drivers-net-ethernet-dlink-dl2k.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? ??? drivers-net-mdio.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
??? x86_64-randconfig-a0-01041127
??? drivers-net-mdio.c:error:implicit-declaration-of-function-ethtool_convert_legacy_u32_to_link_mode
TIMEOUT after 604m
Sorry we cannot finish the testset for your branch within a reasonable time.
It's our fault -- either some build server is down or some build worker is busy
doing bisects for _other_ trees. The branch will get more complete coverage and
possible error reports when our build infrastructure is restored or catches up.
There will be no more build success notification for this branch head, but you
can expect reasonably good test coverage after waiting for 1 day.
configs tested: 228
powerpc acadia_defconfig
powerpc motionpro_defconfig
sh shx3_defconfig
arm imx_v6_v7_defconfig
mips e55_defconfig
mn10300 asb2303_defconfig
avr32 favr-32_defconfig
c6x dsk6455_defconfig
sh sh7785lcr_32bit_defconfig
i386 randconfig-a0-201701
x86_64 randconfig-a0-01040544
x86_64 randconfig-a0-01041127
x86_64 acpi-redef
x86_64 allyesdebian
x86_64 nfsroot
i386 tinyconfig
m68k m5249evb_defconfig
powerpc mpc7448_hpc2_defconfig
powerpc tqm5200_defconfig
i386 randconfig-c0-01040546
i386 randconfig-c0-01041119
arm acs5k_defconfig
m32r mappi.nommu_defconfig
tile allyesconfig
x86_64 randconfig-in0-01040346
arm omap2plus_defconfig
powerpc mpc834x_itxgp_defconfig
sh landisk_defconfig
x86_64 randconfig-it0-01040452
x86_64 randconfig-v0-01040430
powerpc allnoconfig
powerpc defconfig
powerpc ppc64_defconfig
s390 default_defconfig
alpha defconfig
parisc allnoconfig
parisc b180_defconfig
parisc c3000_defconfig
parisc defconfig
i386 allmodconfig
m68k m5475evb_defconfig
powerpc linkstation_defconfig
s390 defconfig
sh se7750_defconfig
x86_64 randconfig-x011-201701
x86_64 randconfig-x017-201701
x86_64 randconfig-x014-201701
x86_64 randconfig-x016-201701
x86_64 randconfig-x012-201701
x86_64 randconfig-x019-201701
x86_64 randconfig-x013-201701
x86_64 randconfig-x010-201701
x86_64 randconfig-x018-201701
x86_64 randconfig-x015-201701
i386 alldefconfig
i386 allnoconfig
i386 defconfig
arm allmodconfig
arm arm5
arm arm67
arm ixp4xx_defconfig
arm mvebu_v7_defconfig
arm sa1100
arm samsung
arm sh
arm tegra_defconfig
arm64 alldefconfig
arm64 allmodconfig
i386 randconfig-s0-201701
i386 randconfig-s1-201701
x86_64 randconfig-s0-01040449
x86_64 randconfig-s1-01040449
x86_64 randconfig-s2-01040449
x86_64 randconfig-s3-01040508
x86_64 randconfig-s4-01040508
x86_64 randconfig-s5-01040508
arm multi_v7_defconfig
s390 performance_defconfig
sh allnoconfig
um defconfig
arm clps711x_defconfig
arm s3c6400_defconfig
arm vf610m4_defconfig
h8300 h8300h-sim_defconfig
blackfin BF561-EZKIT_defconfig
mips mpc30x_defconfig
powerpc mpc885_ads_defconfig
sh defconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allnoconfig
mips fuloong2e_defconfig
mips jz4740
mips malta_kvm_defconfig
mips txx9
x86_64 randconfig-i0-201701
i386 randconfig-b0-01040538
i386 randconfig-b0-01041118
arm qcom_defconfig
powerpc ppc64e_defconfig
sh kfr2r09-romimage_defconfig
microblaze mmu_defconfig
microblaze nommu_defconfig
i386 randconfig-i1-201701
i386 randconfig-i0-201701
i386 allyesconfig
x86_64 randconfig-b0-01040452
sparc defconfig
sparc64 allnoconfig
sparc64 defconfig
x86_64 allmodconfig
mips jmr3927_defconfig
arm efm32_defconfig
mips ip27_defconfig
powerpc tqm8540_defconfig
x86_64 randconfig-u0-01040525
x86_64 randconfig-u0-01041137
arm zx_defconfig
mips allyesconfig
x86_64 randconfig-ne0-01040556
x86_64 randconfig-ne0-01041049
x86_64 randconfig-ne0-01041128
arm cerfcube_defconfig
arm u8500_defconfig
powerpc pasemi_defconfig
powerpc socrates_defconfig
arm iop32x_defconfig
m32r allyesconfig
mips pic32mzda_defconfig
mips tb0287_defconfig
i386 randconfig-x010-201701
i386 randconfig-x011-201701
i386 randconfig-x012-201701
i386 randconfig-x013-201701
i386 randconfig-x014-201701
i386 randconfig-x015-201701
i386 randconfig-x016-201701
i386 randconfig-x017-201701
i386 randconfig-x018-201701
i386 randconfig-x019-201701
x86_64 lkp
x86_64 rhel
x86_64 rhel-7.2
i386 randconfig-n0-201701
i386 randconfig-h0-01040525
i386 randconfig-h1-01040525
i386 randconfig-h0-01041042
i386 randconfig-h1-01041042
i386 randconfig-h0-01041127
i386 randconfig-h1-01041127
blackfin BF527-EZKIT-V2_defconfig
cris allmodconfig
powerpc ep8248e_defconfig
ia64 alldefconfig
ia64 allnoconfig
ia64 defconfig
x86_64 randconfig-h0-01041155
avr32 atngw100_defconfig
avr32 atstk1006_defconfig
frv defconfig
mn10300 asb2364_defconfig
openrisc or1ksim_defconfig
tile tilegx_defconfig
um i386_defconfig
um x86_64_defconfig
m32r allmodconfig
mips ci20_defconfig
arm hackkit_defconfig
arm pcm027_defconfig
x86_64 randconfig-n0-01041108
m68k multi_defconfig
m68k sun3_defconfig
sh rsk7269_defconfig
sh titan_defconfig
arm allnoconfig
arm at91_dt_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 allnoconfig
arm64 defconfig
blackfin DNP5370_defconfig
m32r m32700ut.up_defconfig
um allmodconfig
x86_64 randconfig-ws0-01040351
c6x evmc6678_defconfig
m32r m32104ut_defconfig
m32r mappi3.smp_defconfig
m32r opsput_defconfig
m32r usrv_defconfig
nios2 10m50_defconfig
score spct6600_defconfig
xtensa common_defconfig
xtensa iss_defconfig
powerpc iss476-smp_defconfig
mips generic_defconfig
sh sh7763rdp_defconfig
x86_64 randconfig-x008-201701
x86_64 randconfig-x001-201701
x86_64 randconfig-x009-201701
x86_64 randconfig-x000-201701
x86_64 randconfig-x003-201701
x86_64 randconfig-x006-201701
x86_64 randconfig-x002-201701
x86_64 randconfig-x004-201701
x86_64 randconfig-x007-201701
x86_64 randconfig-x005-201701
i386 randconfig-r0-201701
arm bcm2835_defconfig
arm imote2_defconfig
ia64 sim_defconfig
arm vt8500_v6_v7_defconfig
ia64 allyesconfig
sh se7343_defconfig
i386 randconfig-x003-201701
i386 randconfig-x004-201701
i386 randconfig-x007-201701
i386 randconfig-x001-201701
i386 randconfig-x006-201701
i386 randconfig-x009-201701
i386 randconfig-x008-201701
i386 randconfig-x002-201701
i386 randconfig-x000-201701
i386 randconfig-x005-201701
i386 randconfig-x0-01040541
i386 randconfig-x0-01041139
Thanks,
Fengguang
^ permalink raw reply
* Re: [RFC PATCH 0/5] Localise error headers
From: Jeff King @ 2017-01-04 7:05 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <cover.1483354746.git.git@drmicha.warpmail.net>
On Mon, Jan 02, 2017 at 12:14:49PM +0100, Michael J Gruber wrote:
> Currently, the headers "error: ", "warning: " etc. - generated by die(),
> warning() etc. - are not localized, but we feed many localized error messages
> into these functions so that we produce error messages with mixed localisation.
>
> This series introduces variants of die() etc. that use localised variants of
> the headers, i.e. _("error: ") etc., and are to be fed localized messages. So,
> instead of die(_("not workee")), which would produce a mixed localisation (such
> as "error: geht ned"), one should use die_(_("not workee")) (resulting in
> "Fehler: geht ned").
I can't say I'm excited about having matching "_" variants for each
function. Are we sure that they are necessary? I.e., would it be
acceptable to just translate them always?
> 1/5 prepares the error machinery
> 2/5 provides new variants error_() etc.
> 3/5 has coccinelli rules error(_(E)) -> error_(_(E)) etc.
> 4/5 applies the coccinelli patches
>
> 5/5 is not to be applied to the main tree, but helps you try out the feature:
> it has changes to de.po and git.pot so that e.g. "git branch" has fully localised
> error messages (see the recipe in the commit message).
Your patches 4 and 5 don't seem to have made it to the list. Judging
from the diffstat, I'd guess they broke the 100K limit.
-Peff
^ permalink raw reply
* RE: [PATCH 1/1] regulator: fixed: add suspend pm routines for pinctrl
From: Peter Chen @ 2017-01-04 7:05 UTC (permalink / raw)
To: Mark Brown; +Cc: lgirdwood@gmail.com, linux-kernel@vger.kernel.org
In-Reply-To: <20170103111459.ezab3iavnbvzh2hc@sirena.org.uk>
>>On Tue, Jan 03, 2017 at 05:02:47PM +0800, Peter Chen wrote:
>>> At some systems, the pinctrl setting will be lost or needs to set as
>>> "sleep" state to save power consumption. So, we need to configure
>>> pinctrl as "sleep" state when system enters suspend, and as "default"
>>> state after system resumes. In this way, the pinctrl value can be
>>> recovered as "default" state after resuming.
>>
>>I thought this was supposed to be done automatically by the driver core?
>>If not it should be, every single driver is likely to end up with that.
>
>Good idea, I will send a patch for that.
>
After checking more, it is not suitable for driver core do it since different driver
has different usage for "sleep" pinctrl. Below are some examples:
- Some drivers set "idle" for pinctrl when system goes to suspend
- Some drivers has some conditions for setting "sleep" for pinctrl
eg: drivers/net/ethernet/freescale/fec_main.c
- Some drivers may set "sleep" for pinctrl as ->close interface, but not system suspend
interface
- Some drivers can be woken up for "sleep" pinctrl, some may not.
Peter
^ permalink raw reply
* [Qemu-arm] How to debug peripheral device
From: Jiahuan Zhang @ 2017-01-04 7:05 UTC (permalink / raw)
To: qemu-arm
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
Hi everyone,
This is my first time to use QEMU. I am emulating the atmel at91sam9261
board. I want to debug the functionalities of the emulated peripherals.
What I am doing now is to *printf* the reading and writing memory offsets
and values for the periperals when running a linux uImage. And according to
the emulated periperals' *read* and *write* behaviours, I rectify their
resigters in terms of their corresponding functions in the board's
datasheet.
However, not all the printed offsets are expected. And some offsets that I
expected to be written are not be written, so that some functions will
never be enabled and some peripherals are never be driven. Any solution for
this offset missing?
What is the right way for peripheral debugging? Getting stuck for almost
two months, I am really upset now.
Best regards,
Jiahuan
[-- Attachment #2: Type: text/html, Size: 1075 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/7] net/virtio_user: move vhost user specific code
From: Yuanhan Liu @ 2017-01-04 7:08 UTC (permalink / raw)
To: Tan, Jianfeng; +Cc: dev@dpdk.org, Yigit, Ferruh, Liang, Cunming
In-Reply-To: <ED26CBA2FAD1BF48A8719AEF02201E3651107348@SHSMSX103.ccr.corp.intel.com>
On Wed, Jan 04, 2017 at 06:46:34AM +0000, Tan, Jianfeng wrote:
> Hi Yuanhan,
>
> > -----Original Message-----
> > From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> > Sent: Wednesday, January 4, 2017 2:03 PM
> > To: Tan, Jianfeng
> > Cc: dev@dpdk.org; Yigit, Ferruh; Liang, Cunming
> > Subject: Re: [PATCH v3 3/7] net/virtio_user: move vhost user specific code
> >
> > On Wed, Jan 04, 2017 at 03:59:22AM +0000, Jianfeng Tan wrote:
> > > To support vhost kernel as the backend of net_virtio_user in coming
> > > patches, we move vhost_user specific structs and macros into
> > > vhost_user.c, and only keep common definitions in vhost.h.
> > >
> > > Besides, remove VHOST_USER_MQ feature check.
> >
> > Again, I have to ask, why? You don't only remove the check, also, you
> > removed this feature setting, which seems to break the MQ support?
>
> I have answered it here:
> http://dpdk.org/ml/archives/dev/2016-December/053520.html
I thought we have made some agreements :/
>
> To be more clear, VHOST_USER_MQ is a not-well-defined macro: #define VHOST_USER_MQ (1ULL << VHOST_USER_F_PROTOCOL_FEATURES),
> which is a feature bit in vhost user protocol.
Yes, it's again named wrongly.
> According to QEMU/ docs/specs/vhost-user.txt, "If VHOST_USER_F_PROTOCOL_FEATURES has not been negotiated, the ring is initialized in an enabled state. "
>
> But our DPDK vhost library does not take care of this feature bit.
> Just make this as default: the ring is initialized in an disabled state. And our virtio_user with vhost-user does send VHOST_USER_SET_VRING_ENABLE to enable each queue pair.
VHOST_USER_F_PROTOCOL_FEATURES is a fundamental feature for quite many
vhost-user extended features, including the MQ. If it's not set, the MQ
should not work.
It may still work in your case, becase you made an assumtion that the
vhost backend supports the MQ feature (which is true in nowadays, as
the feature has been there for a quite while). However, that's not an
assumtion you can take while adding the vhost-user MQ support at that
time. And such feature bit (including the PROTOCOL_F_MQ) makes sure
that we will not try to enable MQ with and older vhost backend that
doesn't have the support.
Put simply, this feature is needed, and as the feature name states,
it's needed only for vhost-user.
--yliu
>
> So I think it's not necessary to add it back.
>
> How do you think?
>
> Thanks,
> Jianfeng
>
> >
> > --yliu
^ permalink raw reply
* Re: [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
From: Thierry Reding @ 2017-01-04 6:36 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Olliver Schinagl, Maxime Ripard, Chen-Yu Tsai, linux-pwm,
linux-arm-kernel, linux-kernel
In-Reply-To: <20170103165554.6vq7fyhtpx7olqyf@piout.net>
[-- Attachment #1: Type: text/plain, Size: 6221 bytes --]
On Tue, Jan 03, 2017 at 05:55:54PM +0100, Alexandre Belloni wrote:
> On 03/01/2017 at 16:59:57 +0100, Olliver Schinagl wrote :
> > On 12-12-16 13:24, Maxime Ripard wrote:
> > > On Thu, Dec 08, 2016 at 02:23:39PM +0100, Olliver Schinagl wrote:
> > > > Hey Maxime,
> > > >
> > > > first off, also sorry for the slow delay :) (pun not intended)
> > > >
> > > > On 27-08-16 00:19, Maxime Ripard wrote:
> > > > > On Thu, Aug 25, 2016 at 07:50:10PM +0200, Olliver Schinagl wrote:
> > > > > > When we inform the PWM block to stop toggeling the output, we may end up
> > > > > > in a state where the output is not what we would expect (e.g. not the
> > > > > > low-pulse) but whatever the output was at when the clock got disabled.
> > > > > >
> > > > > > To counter this we have to wait for maximally the time of one whole
> > > > > > period to ensure the pwm hardware was able to finish. Since we already
> > > > > > told the PWM hardware to disable it self, it will not continue toggling
> > > > > > but merly finish its current pulse.
> > > > > >
> > > > > > If a whole period is considered to much, it may be contemplated to use a
> > > > > > half period + a little bit to ensure we get passed the transition.
> > > > > >
> > > > > > Signed-off-by: Olliver Schinagl<oliver@schinagl.nl>
> > > > > > ---
> > > > > > drivers/pwm/pwm-sun4i.c | 11 +++++++++++
> > > > > > 1 file changed, 11 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> > > > > > index 03a99a5..5e97c8a 100644
> > > > > > --- a/drivers/pwm/pwm-sun4i.c
> > > > > > +++ b/drivers/pwm/pwm-sun4i.c
> > > > > > @@ -8,6 +8,7 @@
> > > > > > #include <linux/bitops.h>
> > > > > > #include <linux/clk.h>
> > > > > > +#include <linux/delay.h>
> > > > > > #include <linux/err.h>
> > > > > > #include <linux/io.h>
> > > > > > #include <linux/module.h>
> > > > > > @@ -245,6 +246,16 @@ static void sun4i_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
> > > > > > spin_lock(&sun4i_pwm->ctrl_lock);
> > > > > > val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> > > > > > val &= ~BIT_CH(PWM_EN, pwm->hwpwm);
> > > > > > + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> > > > > > + spin_unlock(&sun4i_pwm->ctrl_lock);
> > > > > > +
> > > > > > + /* Allow for the PWM hardware to finish its last toggle. The pulse
> > > > > > + * may have just started and thus we should wait a full period.
> > > > > > + */
> > > > > > + ndelay(pwm_get_period(pwm));
> > > > > Can't that use the ready bit as well?
> > > >
> > > > I started to implement our earlier discussed suggestions, but I do not think
> > > > they will work. The read bit is not to let the user know it is ready with
> > > > all of its commands, but only if the period registers are ready. I think it
> > > > is some write lock while it copies the data into its internal control loop.
> > > > From the manual:
> > > > PWM0 period register ready.
> > > > 0: PWM0 period register is ready to write,
> > > > 1: PWM0 period register is busy.
> > > >
> > > >
> > > > So no, I don't think i can use the ready bit here at all. The only thing we
> > > > can do here, but I doubt it's worth it, is to read the period register,
> > > > caluclate a time from it, and then ndelay(pwm_get_period(pwm) - ran_time)
> > > >
> > > > The only 'win' then is that we could are potentially not waiting the full
> > > > pwm period, but only a fraction of it. Since we are disabling the hardware
> > > > (for power reasons) anyway, I don't think this is any significant win,
> > > > except for extreme situations. E.g. we have a pwm period of 10 seconds, we
> > > > disable it after 9.9 second, and now we have to wait for 10 seconds before
> > > > the pwm_disable is finally done. So this could in that case be reduced to
> > > > then only wait for 0.2 seconds since it is 'done' sooner.
> > > >
> > > > However that optimization is also not 'free'. We have to read the period
> > > > register and calculate back the time. I suggest to do that when reworking
> > > > this driver to work with atomic mode, and merge this patch 'as is' to
> > > > atleast fix te bug where simply not finish properly.
> > >
> > > That whole discussion made me realise something that is really
> > > bad. AFAIK, pwm_get_period returns a 32 bits register, which means a
> > > theorical period of 4s. Busy looping during 4 seconds is already very
> > > bad, as you basically kill one CPU during that time, but doing so in a
> > > (potentially) atomic context is even worse.
> > Well technically, isn't it a 16 bit register? (half for the period, other
> > half for the duty cycle?) Anyway, I think the delay can be far exceeding 4
> > seconds (though I haven't checked what the PWM delay max option is).
> >
>
> That's 196.8s.
>
> But you can rely on the RDY bit because what you want to
> achieve actually relies on the fact that the duty cycle will be set to 0
> before disabling the channel.
>
>
> > Anyway, you are right, we should absolutely not do this!
> >
> > >
> > > NACK.
> > Absolutely! But what do you suggest? Would usleep (or msleep) instead of the
> > ndelay work properly?
> >
>
> We can probably set up a timer and disable the channel when it expires.
> Obviously it will be necessary to cancel the timer if the channel is
> reenabled in the mean time.
>
> Or maybe we can make all the functions blocking and forget about
> synchronizing both channels.
Yes, I think blocking is fine. All drivers report "might sleep" since
v4.5 anyway, so by now all users must have gained support for blocking
drivers.
I'm also not aware of any users that couldn't cope with blocking PWM
devices. The only case that I'm aware of is the LED class that uses it
for blink support and it needs to support the blocking case anyway for
devices that sit on a slow bus, for example.
I'll post a patch to remove pwm_can_sleep() altogether, it's long been
redundant. Because of that I also think it's safe for every driver to
block during any of the operations, which is true both for legacy ones
as well as atomic ones.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2.1 04/13] drm: Add data transmission order bus flag
From: Thierry Reding @ 2017-01-04 7:06 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: dri-devel, linux-renesas-soc, Stefan Agner
In-Reply-To: <20170104003926.29683-1-laurent.pinchart+renesas@ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]
On Wed, Jan 04, 2017 at 02:39:26AM +0200, Laurent Pinchart wrote:
> The flags indicate whether data is transmitted lsb to msb or msb to lsb
> on the bus.
>
> The exact meaning is bus-type dependent. For instance, for LVDS buses
> the flags indicate whether the seven data bits transmitted in a clock
> pulse are sent in normal order (msb to lsb, slots 0 to 6) or reverse
> order (lsb to msb, slots 6 to 0).
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Changes since v2:
>
> - Rename the flag to DRM_BUS_FLAG_DATA_LSB_TO_MSB and add a
> corresponding DRM_BUS_FLAG_DATA_MSB_TO_LSB flag.
> ---
> include/drm/drm_connector.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index a9b95246e26e..712f255577ea 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -160,6 +160,10 @@ struct drm_display_info {
> #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2)
> /* drive data on neg. edge */
> #define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3)
> +/* data is transmitted msb to lsb on the bus */
> +#define DRM_BUS_FLAG_DATA_MSB_TO_LSB (1<<4)
> +/* data is transmitted lsb to msb on the bus */
> +#define DRM_BUS_FLAG_DATA_LSB_TO_MSB (1<<5)
Nit: "LSB" and "MSB" because they're abbreviations. If I end up applying
this I'll probably do that myself, and I leave it up to whoever else
might apply it whether or not they want to be pedantic, so:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2.1 04/13] drm: Add data transmission order bus flag
From: Thierry Reding @ 2017-01-04 7:06 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-renesas-soc, dri-devel
In-Reply-To: <20170104003926.29683-1-laurent.pinchart+renesas@ideasonboard.com>
[-- Attachment #1.1: Type: text/plain, Size: 1566 bytes --]
On Wed, Jan 04, 2017 at 02:39:26AM +0200, Laurent Pinchart wrote:
> The flags indicate whether data is transmitted lsb to msb or msb to lsb
> on the bus.
>
> The exact meaning is bus-type dependent. For instance, for LVDS buses
> the flags indicate whether the seven data bits transmitted in a clock
> pulse are sent in normal order (msb to lsb, slots 0 to 6) or reverse
> order (lsb to msb, slots 6 to 0).
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Changes since v2:
>
> - Rename the flag to DRM_BUS_FLAG_DATA_LSB_TO_MSB and add a
> corresponding DRM_BUS_FLAG_DATA_MSB_TO_LSB flag.
> ---
> include/drm/drm_connector.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index a9b95246e26e..712f255577ea 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -160,6 +160,10 @@ struct drm_display_info {
> #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2)
> /* drive data on neg. edge */
> #define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3)
> +/* data is transmitted msb to lsb on the bus */
> +#define DRM_BUS_FLAG_DATA_MSB_TO_LSB (1<<4)
> +/* data is transmitted lsb to msb on the bus */
> +#define DRM_BUS_FLAG_DATA_LSB_TO_MSB (1<<5)
Nit: "LSB" and "MSB" because they're abbreviations. If I end up applying
this I'll probably do that myself, and I leave it up to whoever else
might apply it whether or not they want to be pedantic, so:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.