* Re: [f2fs-dev] [PATCH 04/10] f2fs: support IO alignment for DATA and NODE writes
From: Chao Yu @ 2017-01-04 8:23 UTC (permalink / raw)
To: Jaegeuk Kim, linux-kernel, linux-fsdevel, linux-f2fs-devel
In-Reply-To: <20161230185117.3832-4-jaegeuk@kernel.org>
Hi Jaegeuk,
On 2016/12/31 2:51, Jaegeuk Kim wrote:
> This patch implements IO alignment by filling dummy blocks in DATA and NODE
> write bios. If we can guarantee, for example, 32KB or 64KB for such the IOs,
> we can eliminate underlying dummy page problem which FTL conducts in order to
> close MLC or TLC partial written pages.
>
> Note that,
> - it requires "-o mode=lfs".
> - IO size should be power of 2, not exceed BIO_MAX_PAGES, 256.
> - read IO is still 4KB.
> - do checkpoint at fsync, if dummy NODE page was written.
Which scenario we can benefit from? Any numbers?
I doubt that there are some potential side-effect points:
- write amplification will be more serious than before
- free space will be more fragmented since dummy blocks is separated in whole
address space
- there is less chance to merge small(unaligned) IOs in block layer
Thoughts?
Thanks,
^ permalink raw reply
* Re: [PATCH] f2fs: don't reserve block for empty file when convert inline, page
From: Kinglong Mee @ 2017-01-04 8:27 UTC (permalink / raw)
To: Jaegeuk Kim
Cc: linux-f2fs-devel, linux-fsdevel, linux-kernel, Chao Yu,
kinglongmee
In-Reply-To: <20170104012328.GA16504@jaegeuk.local>
On 1/4/2017 09:23, Jaegeuk Kim wrote:
> Hi Kinglong,
>
> On 01/02, Kinglong Mee wrote:
>> A test program gets the SEEK_DATA with two values between
>> a new created file and the exist file on f2fs filesystem.
>>
>> F2FS filesystem, (the first "test1" is a new file)
>> # ./lseektest /f2fs/test1
>> SEEK_DATA size != 0 (offset = 8192)
>> # ./lseektest /f2fs/test1
>> SEEK_DATA size != 0 (offset = 4096)
>>
>> PNFS filesystem, (the first "test1" is a new file)
>> # ./lseektest /pnfs/test1
>> SEEK_DATA size != 0 (offset = 4096)
>> # ./lseektest /pnfs/test1
>> SEEK_DATA size != 0 (offset = 4096)
>>
>> # cat lseektest.c
>>
>> #include <stdio.h>
>> #include <string.h>
>> #include <stdlib.h>
>> #include <unistd.h>
>> #include <errno.h>
>> #include <sys/types.h>
>> #include <sys/stat.h>
>> #include <fcntl.h>
>>
>> #ifndef SEEK_DATA
>> #define SEEK_DATA 3
>> #define SEEK_HOLE 4
>> #endif
>>
>> int main(int argc, char **argv)
>> {
>> char *filename = argv[1];
>> int offset = 1, i = 0, fd = -1;
>>
>> if (argc < 2) {
>> printf("Usage: %s f2fsfilename\n", argv[0]);
>> return -1;
>> }
>>
>> /*
>> if (!access(filename, F_OK) || errno != ENOENT) {
>> printf("Needs a new file for test, %m\n");
>> return -1;
>> }*/
>>
>> fd = open(filename, O_RDWR | O_CREAT, 0777);
>> if (fd < 0) {
>> printf("Create test file %s failed, %m\n", filename);
>> return -1;
>> }
>>
>> for (i = 0; i < 20; i++) {
>> offset = 1 << i;
>> ftruncate(fd, 0);
>> lseek(fd, offset, SEEK_SET);
>> write(fd, "test", 5);
>> /* Get the alloc size by seek data equal zero*/
>> if (lseek(fd, 0, SEEK_DATA)) {
>> printf("SEEK_DATA size != 0 (offset = %d)\n", offset);
>> break;
>> }
>> }
>>
>> close(fd);
>> return 0;
>> }
>>
>> Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
>> ---
>> fs/f2fs/inline.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
>> index e32a9e5..6c8d099 100644
>> --- a/fs/f2fs/inline.c
>> +++ b/fs/f2fs/inline.c
>> @@ -117,7 +117,7 @@ int f2fs_convert_inline_page(struct dnode_of_data *dn, struct page *page)
>> };
>> int dirty, err;
>>
>> - if (!f2fs_exist_data(dn->inode))
>> + if (!f2fs_exist_data(dn->inode) || !i_size_read(dn->inode))
>> goto clear_out;
>
> The point is that f2fs_exist_data() should return true, since the file was
> truncated to 0. So, could you check this out?
Yes, that's right.
This patch is useful.
Tested-by: Kinglong Mee <kinglongmee@gmail.com>
thanks,
Kinglong Mee
>
> Thanks,
>
> ---
> fs/f2fs/file.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index 826fefc05fb1..ba2021e01c33 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -570,6 +570,8 @@ int truncate_blocks(struct inode *inode, u64 from, bool lock)
> if (f2fs_has_inline_data(inode)) {
> if (truncate_inline_inode(ipage, from))
> set_page_dirty(ipage);
> + if (from == 0)
> + clear_inode_flag(inode, FI_DATA_EXIST);
> f2fs_put_page(ipage, 1);
> truncate_page = true;
> goto out;
>
^ permalink raw reply
* Re: [PATCH] mmc: dw_mmc: update clock after ctrl reset in runtime resume
From: Jaehoon Chung @ 2017-01-04 8:28 UTC (permalink / raw)
To: Shawn Lin, Ziyuan Xu, ulf.hansson; +Cc: linux-mmc, randy.li, linux-rockchip
In-Reply-To: <5e789711-b5de-5564-4538-a89d9ed9ca05@rock-chips.com>
On 01/03/2017 03:59 PM, Shawn Lin wrote:
> Hi Ziyuan,
>
> On 2017/1/3 14:46, Ziyuan Xu wrote:
>> Immediately after reset, issue the command which sets
>> update_clock_register_only bit, the card clock will restart.
>>
>> MMC_PM_KEEP_POWER is disabled for SD card and eMMC slots, so that they
>> have no chance to invoke dw_mci_setup_bus for update clock behaviour.
>> Let's consummate it.
>>
>> Fixes: e9ed883 ("mmc: dw_mmc: add runtime PM callback")
>> Reported-by: Randy Li <randy.li@rock-chips.com>
>> Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
>> ---
>> drivers/mmc/host/dw_mmc.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index b44306b..71715b4 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -3357,6 +3357,8 @@ int dw_mci_runtime_resume(struct device *dev)
>> if (slot->mmc->pm_flags & MMC_PM_KEEP_POWER) {
>> dw_mci_set_ios(slot->mmc, &slot->mmc->ios);
>> dw_mci_setup_bus(slot, true);
>> + } else {
>> + mci_send_cmd(slot, SDMMC_CMD_UPD_CLK, 0);
>> }
>> }
>
> Thanks for sending this, but I think the better fix we talked about
> offlist may be...
>
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -3324,7 +3324,7 @@ int dw_mci_runtime_resume(struct device *dev)
> if (ret)
> goto err;
>
> - if (!dw_mci_ctrl_reset(host, SDMMC_CTRL_ALL_RESET_FLAGS)) {
> + if (!dw_mci_reset(host)) {
> clk_disable_unprepare(host->ciu_clk);
> ret = -ENODEV;
> goto err;
>
>
> otherwise there still some unhandled cases once the reset is failure.
I think Shawn's suggestion is more better..After applied Shawn's suggestion, Is the problem disappeared?
If then, could you resend the patch as Shawn's?
I don't test yet with exynos..after testing, i will also share.
Best Regards,
Jaehoon Chung
>
>>
>>
>
>
^ permalink raw reply
* Re: [PATCH v4 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
From: Chanwoo Choi @ 2017-01-04 7:16 UTC (permalink / raw)
To: Hoegeun Kwon, robh, thierry.reding, airlied, kgene, krzk,
inki.dae
Cc: dri-devel, linux-kernel, devicetree, linux-samsung-soc, a.hajda,
jh80.chung, Hyungwon Hwang
In-Reply-To: <1483513115-3068-4-git-send-email-hoegeun.kwon@samsung.com>
Hi Hoegeun,
On 2017년 01월 04일 15:58, Hoegeun Kwon wrote:
> 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 {
>
I tested this patch on Exynos5433-TM2 board.
It is well working to display the image to LCD panel.
Tested-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Regards,
Chanwoo Choi
^ permalink raw reply
* Re: [RFC][PATCH 0/4] fsnotify: pass single mark to handle_event()
From: Jan Kara @ 2017-01-04 8:28 UTC (permalink / raw)
To: Amir Goldstein; +Cc: Jan Kara, Eric Paris, linux-fsdevel
In-Reply-To: <1482867148-31497-1-git-send-email-amir73il@gmail.com>
Hi,
On Tue 27-12-16 21:32:24, Amir Goldstein wrote:
> I thought this would turn out simpler, so you may be able to use it
> for your work, but I'm afraid that's not the case.
>
> Anyway, since I am leaving for new year's vacation, I am posting
> what I have in case you want to use any of it.
>
> It passed some initial tests I ran, but when I wanted to test the
> corner case referred to in patch 1, I found that my test program
> hangs open() syscalls with kernel 4.10-rc1 before any of my changes.
>
> This is the mark setup I was testing [1]:
> fanotify_mark(fd, FAN_MARK_ADD,
> FAN_OPEN_PERM | FAN_EVENT_ON_CHILD, AT_FDCWD,
> path);
> fanotify_mark(fd, FAN_MARK_ADD | \
> FAN_MARK_IGNORED_SURV_MODIFY | FAN_MARK_IGNORED_MASK
> FAN_OPEN_PERM | FAN_EVENT_ON_CHILD, AT_FDCWD,
> FAN_CLOSE_WRITE, AT_FDCWD,
> path);
> fanotify_mark(fd, FAN_MARK_ADD | FAN_MARK_MOUNT,
> FAN_OPEN_PERM | FAN_CLOSE_WRITE, AT_FDCWD,
> path);
>
> Without FAN_EVENT_ON_CHILD it works fine, but with FAN_EVENT_ON_CHILD,
> something bad is going on and I did not have time to look into it.
I had a look at the patches and the result does not look simpler than what
we had before AFAICT. Sure we don't have to pass both marks into
->handle_event but is that really such a big win? And actually my patches
for dropping SRCU lock when waiting for userspace response to fanotify
permission event need both marks in ->handle_event because they both need
to be protected against freeing when SRCU lock is dropped... So I don't
think this is really viable path.
However one thing that may be worth cleaning up is that
fanotify_should_send_event() needlessly checks the masks - send to group
already did this. So I'd move the check for FS_EVENT_ON_CHILD from
fanotify_should_send_event() to send_to_group() - arguably it belongs there
- and then just completely drop checking of the masks from
fanotify_should_send_event(). What do you think?
> In general, I would like to start working on an fsnotify testsuite,
> so if you have any plans wrt writing extra tests or ideas about specific
> missing tests, please let me know about them.
That would be certainly worthwhile. Actually when I find some useful
testcase I add it to LTP under the
testcases/kernel/syscalls/{fanotify|inotify}. So please extend that if you
have some more ideas for testcases.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH 2/2] gpio: davinci: Remove gpio2regs function to accommodate multi instances
From: Keerthy @ 2017-01-04 8:26 UTC (permalink / raw)
To: linus.walleij; +Cc: linux-kernel, j-keerthy, linux-gpio, gnurou, t-kristo
In-Reply-To: <1483518389-6200-1-git-send-email-j-keerthy@ti.com>
gpio2regs is written making an assumption that driver supports only
one instance of gpio controller. Removing this and adding a generic
array so as to support multiple instances of gpio controllers.
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
drivers/gpio/gpio-davinci.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 163f81e..26b874a 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -43,25 +43,7 @@ struct davinci_gpio_regs {
#define MAX_LABEL_SIZE 20
static void __iomem *gpio_base;
-
-static struct davinci_gpio_regs __iomem *gpio2regs(unsigned gpio)
-{
- void __iomem *ptr;
-
- if (gpio < 32 * 1)
- ptr = gpio_base + 0x10;
- else if (gpio < 32 * 2)
- ptr = gpio_base + 0x38;
- else if (gpio < 32 * 3)
- ptr = gpio_base + 0x60;
- else if (gpio < 32 * 4)
- ptr = gpio_base + 0x88;
- else if (gpio < 32 * 5)
- ptr = gpio_base + 0xb0;
- else
- ptr = NULL;
- return ptr;
-}
+static unsigned int offset_array[5] = {0x10, 0x38, 0x60, 0x88, 0xb0};
static inline struct davinci_gpio_regs __iomem *irq2regs(struct irq_data *d)
{
@@ -262,7 +244,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
#endif
spin_lock_init(&chips[i].lock);
- regs = gpio2regs(base);
+ regs = gpio_base + offset_array[i];
if (!regs)
return -ENXIO;
chips[i].regs = regs;
@@ -417,7 +399,9 @@ static int gpio_irq_type_unbanked(struct irq_data *data, unsigned trigger)
davinci_gpio_irq_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hw)
{
- struct davinci_gpio_regs __iomem *g = gpio2regs(hw);
+ struct davinci_gpio_controller *chips =
+ (struct davinci_gpio_controller *)d->host_data;
+ struct davinci_gpio_regs __iomem *g = chips[hw / 32].regs;
irq_set_chip_and_handler_name(irq, &gpio_irqchip, handle_simple_irq,
"davinci_gpio");
@@ -554,7 +538,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
irq_chip->irq_set_type = gpio_irq_type_unbanked;
/* default trigger: both edges */
- g = gpio2regs(0);
+ g = chips[0].regs;
writel_relaxed(~0, &g->set_falling);
writel_relaxed(~0, &g->set_rising);
@@ -574,7 +558,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
*/
for (gpio = 0, bank = 0; gpio < ngpio; bank++, bank_irq++, gpio += 16) {
/* disabled by default, enabled only as needed */
- g = gpio2regs(gpio);
+ g = chips[bank / 2].regs;
writel_relaxed(~0, &g->clr_falling);
writel_relaxed(~0, &g->clr_rising);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] gpio: davinci: Remove redundant members davinci_gpio_controller stuct
From: Keerthy @ 2017-01-04 8:26 UTC (permalink / raw)
To: linus.walleij; +Cc: linux-kernel, j-keerthy, linux-gpio, gnurou, t-kristo
davinci_gpio_controller struct has set_data, in_data, clr_data
members that are assigned and never used.
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
drivers/gpio/gpio-davinci.c | 3 ---
include/linux/platform_data/gpio-davinci.h | 3 ---
2 files changed, 6 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 9191056..163f81e 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -266,9 +266,6 @@ static int davinci_gpio_probe(struct platform_device *pdev)
if (!regs)
return -ENXIO;
chips[i].regs = regs;
- chips[i].set_data = ®s->set_data;
- chips[i].clr_data = ®s->clr_data;
- chips[i].in_data = ®s->in_data;
gpiochip_add_data(&chips[i].chip, &chips[i]);
}
diff --git a/include/linux/platform_data/gpio-davinci.h b/include/linux/platform_data/gpio-davinci.h
index 6ace3fd..44ca530 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -33,9 +33,6 @@ struct davinci_gpio_controller {
/* Serialize access to GPIO registers */
spinlock_t lock;
void __iomem *regs;
- void __iomem *set_data;
- void __iomem *clr_data;
- void __iomem *in_data;
int gpio_unbanked;
unsigned gpio_irq;
};
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] gpio: davinci: Remove gpio2regs function to accommodate multi instances
From: Keerthy @ 2017-01-04 8:26 UTC (permalink / raw)
To: linus.walleij; +Cc: linux-kernel, j-keerthy, linux-gpio, gnurou, t-kristo
In-Reply-To: <1483518389-6200-1-git-send-email-j-keerthy@ti.com>
gpio2regs is written making an assumption that driver supports only
one instance of gpio controller. Removing this and adding a generic
array so as to support multiple instances of gpio controllers.
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
drivers/gpio/gpio-davinci.c | 30 +++++++-----------------------
1 file changed, 7 insertions(+), 23 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 163f81e..26b874a 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -43,25 +43,7 @@ struct davinci_gpio_regs {
#define MAX_LABEL_SIZE 20
static void __iomem *gpio_base;
-
-static struct davinci_gpio_regs __iomem *gpio2regs(unsigned gpio)
-{
- void __iomem *ptr;
-
- if (gpio < 32 * 1)
- ptr = gpio_base + 0x10;
- else if (gpio < 32 * 2)
- ptr = gpio_base + 0x38;
- else if (gpio < 32 * 3)
- ptr = gpio_base + 0x60;
- else if (gpio < 32 * 4)
- ptr = gpio_base + 0x88;
- else if (gpio < 32 * 5)
- ptr = gpio_base + 0xb0;
- else
- ptr = NULL;
- return ptr;
-}
+static unsigned int offset_array[5] = {0x10, 0x38, 0x60, 0x88, 0xb0};
static inline struct davinci_gpio_regs __iomem *irq2regs(struct irq_data *d)
{
@@ -262,7 +244,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
#endif
spin_lock_init(&chips[i].lock);
- regs = gpio2regs(base);
+ regs = gpio_base + offset_array[i];
if (!regs)
return -ENXIO;
chips[i].regs = regs;
@@ -417,7 +399,9 @@ static int gpio_irq_type_unbanked(struct irq_data *data, unsigned trigger)
davinci_gpio_irq_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hw)
{
- struct davinci_gpio_regs __iomem *g = gpio2regs(hw);
+ struct davinci_gpio_controller *chips =
+ (struct davinci_gpio_controller *)d->host_data;
+ struct davinci_gpio_regs __iomem *g = chips[hw / 32].regs;
irq_set_chip_and_handler_name(irq, &gpio_irqchip, handle_simple_irq,
"davinci_gpio");
@@ -554,7 +538,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
irq_chip->irq_set_type = gpio_irq_type_unbanked;
/* default trigger: both edges */
- g = gpio2regs(0);
+ g = chips[0].regs;
writel_relaxed(~0, &g->set_falling);
writel_relaxed(~0, &g->set_rising);
@@ -574,7 +558,7 @@ static int davinci_gpio_irq_setup(struct platform_device *pdev)
*/
for (gpio = 0, bank = 0; gpio < ngpio; bank++, bank_irq++, gpio += 16) {
/* disabled by default, enabled only as needed */
- g = gpio2regs(gpio);
+ g = chips[bank / 2].regs;
writel_relaxed(~0, &g->clr_falling);
writel_relaxed(~0, &g->clr_rising);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] gpio: davinci: Remove redundant members davinci_gpio_controller stuct
From: Keerthy @ 2017-01-04 8:26 UTC (permalink / raw)
To: linus.walleij; +Cc: linux-kernel, j-keerthy, linux-gpio, gnurou, t-kristo
davinci_gpio_controller struct has set_data, in_data, clr_data
members that are assigned and never used.
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
drivers/gpio/gpio-davinci.c | 3 ---
include/linux/platform_data/gpio-davinci.h | 3 ---
2 files changed, 6 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 9191056..163f81e 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -266,9 +266,6 @@ static int davinci_gpio_probe(struct platform_device *pdev)
if (!regs)
return -ENXIO;
chips[i].regs = regs;
- chips[i].set_data = ®s->set_data;
- chips[i].clr_data = ®s->clr_data;
- chips[i].in_data = ®s->in_data;
gpiochip_add_data(&chips[i].chip, &chips[i]);
}
diff --git a/include/linux/platform_data/gpio-davinci.h b/include/linux/platform_data/gpio-davinci.h
index 6ace3fd..44ca530 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -33,9 +33,6 @@ struct davinci_gpio_controller {
/* Serialize access to GPIO registers */
spinlock_t lock;
void __iomem *regs;
- void __iomem *set_data;
- void __iomem *clr_data;
- void __iomem *in_data;
int gpio_unbanked;
unsigned gpio_irq;
};
--
1.9.1
^ permalink raw reply related
* Re: Need clarity on PCIe MSI interrupt in device tree
From: Marc Zyngier @ 2017-01-04 8:29 UTC (permalink / raw)
To: valmiki, linux-kernel, linux-pci; +Cc: helgaas, arnd, mark.rutland
In-Reply-To: <2fea5a0c-7410-97fd-91d1-ae6a06ab1a52@gmail.com>
On 04/01/17 03:17, valmiki wrote:
> Hi,
>
> I have confusion on MSI interrupt flags in PCIe documetation.
>
> MSI interrupts are edge triggered, but i see some controllers use
> Ex:tegra <0 99 0x4>, here interrupt flags show 0x4 which means level
> sensitive as per include/dt-bindings/interrupt-controller/irq.h.
>
> May i know why is it like this, why MSI depicted as level sensitive in
> device tree.
They are not. MSIs are *not* present in the device tree at all.
What you have here is the cascade interrupt from an MSI controller to
another interrupt controller (probably a GICv2), and that particular
interrupt is level triggered. Which is perfectly fine if that's the
signalling method between the two controllers.
This doesn't in any way reflect how MSIs are signalled.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [RFC PATCH] ext4: increase the protection of drop nlink and ext4 inode destroy
From: zhangyi (F) @ 2017-01-04 8:29 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: linux-ext4, linux-kernel, linux-fsdevel, tytso, adilger.kernel
In-Reply-To: <141922.1483225153@turing-police.cc.vt.edu>
On 2017/1/1 6:59, Valdis.Kletnieks@vt.edu said:
> On Mon, 26 Dec 2016 20:34:17 +0800, yi zhang said:
>> Because of the disk and hardware issue, the ext4 filesystem have
>> many errors, the inode->i_nlink of ext4 becomes zero abnormally
>> but the dentry is still positive, it will cause memory corruption
>> after the following process:
>>
>> 1) Due to the inode->i_nlink is 0, this inode will be added into
>> the orhpan list,
>
>> + if (WARN(inode->i_nlink == 0, "inode %lu nlink"
>> + " is already 0", inode->i_ino))
>
> Can we get the filesystem? Or at least the device major/minor? If a system
> has multiple large ext4 filesystems, it would be helpful to know which
> one is having the problem.
>
if (WARN(inode->i_nlink == 0,
- "inode %lu nlink is already 0", inode->i_ino))
+ "inode %lu nlink is already 0, dev=%u:%u",
+ inode->i_ino, MAJOR(inode->i_sb->s_dev), MINOR(inode->i_sb->s_dev)))
return;
We can modify as above, it's enough to know which filesystem is having the
problem, what do you think?
yi zhang
^ permalink raw reply
* [ovmf test] 104023: all pass - PUSHED
From: osstest service owner @ 2017-01-04 8:29 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 104023 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/104023/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9a9fa14e5c15d459e7f143c67d5d88f4b10be2ea
baseline version:
ovmf ab50ab6ea159821d780be60759874dcf38835d1b
Last test of basis 104020 2017-01-04 00:45:08 Z 0 days
Testing same since 104023 2017-01-04 05:45:31 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Chao Zhang <chao.b.zhang@intel.com>
Zhang, Chao B <chao.b.zhang@intel.com>
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=9a9fa14e5c15d459e7f143c67d5d88f4b10be2ea
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 9a9fa14e5c15d459e7f143c67d5d88f4b10be2ea
+ branch=ovmf
+ revision=9a9fa14e5c15d459e7f143c67d5d88f4b10be2ea
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x9a9fa14e5c15d459e7f143c67d5d88f4b10be2ea = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osstest@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osstest@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : daily-cron.ovmf
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/qemu-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
++ : daily-cron.ovmf
++ : git://xenbits.xen.org/qemu-xen.git
++ : git://git.qemu.org/qemu.git
+ TREE_LINUX=osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
+ TREE_XEN=osstest@xenbits.xen.org:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xen.org:/home/xen/git/libvirt.git
+ TREE_RUMPRUN=osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
+ TREE_SEABIOS=osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
+ TREE_OVMF=osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
+ TREE_XTF=osstest@xenbits.xen.org:/home/xen/git/xtf.git
+ info_linux_tree ovmf
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /home/osstest/repos/ovmf
+ git push osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git 9a9fa14e5c15d459e7f143c67d5d88f4b10be2ea:refs/heads/xen-tested-master
To osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
ab50ab6..9a9fa14 9a9fa14e5c15d459e7f143c67d5d88f4b10be2ea -> xen-tested-master
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v5 0/8] Add MACsec offload support for ixgbe
From: Peng, Yuan @ 2017-01-04 8:29 UTC (permalink / raw)
To: Bie, Tiwei, dev@dpdk.org
Cc: adrien.mazarguil@6wind.com, Lu, Wenzhuo, Mcnamara, John,
olivier.matz@6wind.com, thomas.monjalon@6wind.com,
Ananyev, Konstantin, Zhang, Helin, Dai, Wei, Wang, Xiao W
In-Reply-To: <1483514502-32841-1-git-send-email-tiwei.bie@intel.com>
Tested-by: Peng Yuan <yuan.peng@intel.com>
- Tested Branch: master
- Tested Commit: eac901ce29be559b1bb5c5da33fe2bf5c0b4bfd6
- OS: Fedora24 4.5.5-300.fc24.x86_64
- GCC: gcc version 5.3.1 20151207
- CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
- NIC: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb]
- Default x86_64-native-linuxapp-gcc configuration
- Total 5 cases, 5 passed, 0 failed
- Prerequisites:
1x Niantic NIC (2x 10G)
2x IXIA ports (10G)
- Added commands:
testpmd>set macsec offload (port_id) on encrypt (on|off) replay-protect (on|off)
" Enable MACsec offload. "
testpmd>set macsec offload (port_id) off
" Disable MACsec offload. "
testpmd>set macsec sc (tx|rx) (port_id) (mac) (pi)
" Configure MACsec secure connection (SC). "
testpmd>set macsec sa (tx|rx) (port_id) (idx) (an) (pn) (key)
" Configure MACsec secure association (SA). "
- Test Case 1: MACsec packets send and receive
============================================
1. bind two ports to dpdk driver::
./tools/dpdk-devbind.py -b igb_uio 07:00.0 07:00.1
2. config the rx port
1). start the testpmd of rx port::
./testpmd -c 0xc --socket-mem 1024,1024 --file-prefix=rx -w 0000:07:00.1 \
-- --port-topology=chained -i --crc-strip
2). set MACsec offload on::
testpmd>set macsec offload 0 on encrypt on replay-protect on
3). set MACsec parameters as rx_port::
testpmd>set macsec sc rx 0 00:00:00:00:00:01 0
testpmd>set macsec sa rx 0 0 0 0 00112200000000000000000000000000
4). set MACsec parameters as tx_port::
testpmd>set macsec sc tx 0 00:00:00:00:00:02 0
testpmd>set macsec sa tx 0 0 0 0 00112200000000000000000000000000
5). set rxonly::
testpmd>set fwd rxonly
6). start::
testpmd>set promisc all on
testpmd>start
3. config the tx port
1). start the testpmd of tx port::
./testpmd -c 0x30 --socket-mem 1024,1024 --file-prefix=tx -w 0000:07:00.0 \
-- --port-topology=chained -i --crc-strip --txqflags=0x0
2). set MACsec offload on::
testpmd>set macsec offload 0 on encrypt on replay-protect on
3). set MACsec parameters as tx_port::
testpmd>set macsec sc tx 0 00:00:00:00:00:01 0
testpmd>set macsec sa tx 0 0 0 0 00112200000000000000000000000000
4). set MACsec parameters as rx_port::
testpmd>set macsec sc rx 0 00:00:00:00:00:02 0
testpmd>set macsec sa rx 0 0 0 0 00112200000000000000000000000000
5). set txonly::
testpmd>set fwd txonly
6). start::
testpmd>start
4. check the result::
testpmd>stop
testpmd>show port xstats 0
stop the packet transmiting on tx_port first, then stop the packet receiving
on rx_port.
check the rx data and tx data:
tx_good_packets == rx_good_packets
out_pkts_encrypted == in_pkts_ok == tx_good_packets == rx_good_packets
out_octets_encrypted == in_octets_decrypted
out_octets_protected == in_octets_validated
if you want to check the content of the packet, use the command::
testpmd>set verbose 1
the received packets are Decrypted.
check the ol_flags:PKT_RX_IP_CKSUM_GOOD
check the content of the packet:
type=0x0800, the ptype of L2,L3,L4: L2_ETHER L3_IPV4 L4_UDP
Test Case 2: MACsec packets send and normal receive
===================================================
1. disable MACsec offload on rx port::
testpmd>set macsec offload 0 off
2. start the the packets transfer
3. check the result::
testpmd>stop
testpmd>show port xstats 0
stop the testpmd on tx_port first, then stop the testpmd on rx_port.
the received packets are encrypted.
check the content of the packet:
type=0x88e5 sw ptype: L2_ETHER - l2_len=14 - Receive queue=0x0
you can't find L3 and L4 infomation in the packet
in_octets_decrypted and in_octets_validated doesn't increase on last data
transfer.
Test Case 3: normal packet send and MACsec receive
==================================================
1. enable MACsec offload on rx port::
testpmd>set macsec offload 0 on encrypt on replay-protect on
2. disable MACsec offload on tx port::
testpmd>set macsec offload 0 off
3. start the the packets transfer
4. check the result::
testpmd>stop
testpmd>show port xstats 0
stop the testpmd on tx_port first, then stop the testpmd on rx_port.
the received packets are not encrypted.
check the content of the packet:
type=0x0800, the ptype of L2,L3,L4: L2_ETHER L3_IPV4 L4_UDP
in_octets_decrypted and out_pkts_encrypted doesn't increase on last data
transfer.
Test Case 4: MACsec send and receive with wrong parameters
==========================================================
1. don't add "--txqflags=0x0" in the tx_port command line.
the MACsec offload can't work. the tx packets are normal packets.
2. set different pn on rx and tx port, then start the data transfer.
1) set the parameters as test case 1, start and stop the data transfer.
check the result, rx port can receive and decrypt the packets normally.
2) reset the pn of tx port to 0::
testpmd>set macsec sa tx 0 0 0 0 00112200000000000000000000000000
rx port can receive the packets until the pn equals the pn of tx port::
out_pkts_encrypted = in_pkts_late + in_pkts_ok
2. set different keys on rx and tx port, then start the data transfer::
the RX-packets=0,
in_octets_decrypted == out_octets_encrypted,
in_pkts_notvalid == out_pkts_encrypted,
in_pkts_ok=0,
rx_good_packets=0
3. set different pi on rx and tx port(reset on rx_port), then start the data
transfer::
in_octets_decrypted == out_octets_encrypted,
in_pkts_ok = 0,
in_pkts_nosci == out_pkts_encrypted
4. set different an on rx and tx port, then start the data transfer::
rx_good_packets=0,
in_octets_decrypted == out_octets_encrypted,
in_pkts_notusingsa == out_pkts_encrypted,
in_pkts_ok=0,
rx_good_packets=0
5. set different index on rx and tx port, then start the data transfer::
in_octets_decrypted == out_octets_encrypted,
in_pkts_ok == out_pkts_encrypted
Test Case 5: performance test of MACsec offload packets
==========================================================
1. tx linerate
port0 connected to IXIA port5, port1 connected to IXIA port6, set port0
MACsec offload on, set fwd mac.
on IXIA side, start IXIA port6 transmit, start the IXIA capture.
view the IXIA port5 captrued packet, the protocol is MACsec, the EtherType
is 0x88E5, and the packet length is 96bytes, more than the normal packet
32 bytes.
The valid frames received rate is 10.78Mpps, and the %linerate is 100%.
2. rx linerate
there are three ports 05:00.0 07:00.0 07:00.1. connect 07:00.0 to 07:00.1
with cable, connect 05:00.0 to IXIA. bind the three ports to dpdk driver.
start two testpmd::
./testpmd -c 0x3 --socket-mem 1024,1024 --file-prefix=rx -w 0000:07:00.1 \
-- --port-topology=chained -i --crc-strip --txqflags=0x0
testpmd>set macsec offload 0 on encrypt on replay-protect on
testpmd>set macsec sc rx 0 00:00:00:00:00:01 0
testpmd>set macsec sa rx 0 0 0 0 00112200000000000000000000000000
testpmd>set macsec sc tx 0 00:00:00:00:00:02 0
testpmd>set macsec sa tx 0 0 0 0 00112200000000000000000000000000
testpmd>set fwd rxonly
./testpmd -c 0xc --socket-mem 1024,1024 --file-prefix=tx -b 0000:07:00.1 \
-- --port-topology=chained -i --crc-strip --txqflags=0x0
testpmd>set macsec offload 1 on encrypt on replay-protect on
testpmd>set macsec sc rx 1 00:00:00:00:00:02 0
testpmd>set macsec sa rx 1 0 0 0 00112200000000000000000000000000
testpmd>set macsec sc tx 1 00:00:00:00:00:01 0
testpmd>set macsec sa tx 1 0 0 0 00112200000000000000000000000000
testpmd>set fwd mac
start on both two testpmd.
start data transmit from IXIA port, the frame size is 64bytes,
the Ethertype is 0x0800. the rate is 14.88Mpps.
check the linerate on rxonly port::
testpmd>show port stats 0
It shows "Rx-pps: 10775697", so the rx %linerate is 100%.
check the MACsec packets number on tx side::
testpmd>show port xstats 1
on rx side::
testpmd>show port xstats 0
in_pkts_ok == out_pkts_encrypted
-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Tiwei Bie
Sent: Wednesday, January 4, 2017 3:22 PM
To: dev@dpdk.org
Cc: adrien.mazarguil@6wind.com; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Mcnamara, John <john.mcnamara@intel.com>; olivier.matz@6wind.com; thomas.monjalon@6wind.com; Ananyev, Konstantin <konstantin.ananyev@intel.com>; Zhang, Helin <helin.zhang@intel.com>; Dai, Wei <wei.dai@intel.com>; Wang, Xiao W <xiao.w.wang@intel.com>
Subject: [dpdk-dev] [PATCH v5 0/8] Add MACsec offload support for ixgbe
This patch set adds the MACsec offload support for ixgbe.
The testpmd is also updated to support MACsec cmds.
v2:
- Update the documents for testpmd;
- Update the release notes;
- Reuse the functions provided by base code;
v3:
- Add the missing parts of MACsec mbuf flag and reorganize the patch set;
- Add an ethdev event type for MACsec;
- Advertise the MACsec offload capabilities based on the mac type;
- Minor fixes and improvements;
v4:
- Reserve bits in mbuf and ethdev for PMD specific API;
- Use the reserved bits in PMD specific API;
v5:
- Add MACsec offload in the NIC feature list;
- Minor improvements on comments;
Tiwei Bie (8):
mbuf: reserve a Tx offload flag for PMD-specific API
ethdev: reserve an event type for PMD-specific API
ethdev: reserve capability flags for PMD-specific API
net/ixgbe: add MACsec offload support
app/testpmd: add MACsec offload commands
doc: add ixgbe specific APIs
doc: update the release notes for the reserved flags
doc: add MACsec offload into NIC feature list
app/test-pmd/cmdline.c | 389 ++++++++++++++++++++++
app/test-pmd/macfwd.c | 7 +
app/test-pmd/macswap.c | 7 +
app/test-pmd/testpmd.h | 2 +
app/test-pmd/txonly.c | 7 +
doc/guides/nics/features/default.ini | 1 +
doc/guides/nics/features/ixgbe.ini | 1 +
doc/guides/rel_notes/release_17_02.rst | 18 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 32 ++
drivers/net/ixgbe/ixgbe_ethdev.c | 481 +++++++++++++++++++++++++++-
drivers/net/ixgbe/ixgbe_ethdev.h | 45 +++
drivers/net/ixgbe/ixgbe_rxtx.c | 5 +
drivers/net/ixgbe/rte_pmd_ixgbe.h | 122 +++++++
drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 11 +
lib/librte_ether/rte_ethdev.h | 4 +
lib/librte_mbuf/rte_mbuf.c | 2 +
lib/librte_mbuf/rte_mbuf.h | 5 +
17 files changed, 1134 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: RFC: fb restore on drm master close
From: Daniel Vetter @ 2017-01-04 8:30 UTC (permalink / raw)
To: vcaputo; +Cc: dri-devel
In-Reply-To: <20161221181306.GW1976@shells.gnugeneration.com>
On Wed, Dec 21, 2016 at 12:13:06PM -0600, vcaputo@pengaru.com wrote:
> Hello list,
>
> I've been playing with an unaccelerated drm program[1] and have been
> annoyed that whenever this program exits the fbcon isn't restored, with
> the display left completely off.
>
> This seems to happen because Xorg is still running from a different VT.
>
> Upon further investigation, it seems like the fb restore only occurs on
> "lastclose", which explains what I'm observing.
>
> Why don't we perform the fb restore whenever the current master is
> closed to cover this case, since masters are the ones that can change
> modes?
>
> My github has a quick-n-dirty i915 implementation[2] which seems to fix
> this without negative effects, though I haven't exhaustively tested to
> see what breaks.
>
> This isn't a list I subscribe to so please CC me directly in any
> replies, thanks everyone!
The fbdev restore on lastclose was just a "oops, my X died and I have a
black screen now" debug aid. Apps are supposed to restore fbdev themselves
by switching back to text mode using KD_TEXT, which I think forces the
modeset.
In general though the fbdev vs. kms interaction is very ill-defined and
mostly boils down to fbdev staying out of the way if anyone even might be
using the native drm interfaces. We have the drm_fb_helper_is_bound check,
but it's not used consistently either.
Long story short, the answer to your question is "because no one yet
thought this through", and I'm not clear at all what we should be doing
here (if anything). I'm not sure whether your patch is the right approach,
one issue it definitely has is that it only updates i915.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [KERNEL] Re: [KERNEL] Re: Bug 4.9 and memorymanagement
From: Michal Hocko @ 2017-01-04 8:31 UTC (permalink / raw)
To: Klaus Ethgen; +Cc: linux-kernel, linux-mm
In-Reply-To: <20170104081527.hq5q4ngevcl3c7k6@ikki.ethgen.ch>
On Wed 04-01-17 09:15:27, Klaus Ethgen wrote:
> Hi Michal,
>
> Am Mi den 4. Jan 2017 um 9:06 schrieb Michal Hocko:
>
> > > Just try to run with the patch and do what you do normally. If you do
> > > not see any OOMs in few days it should be sufficient evidence. From your
> > > previous logs it seems you hit the problem quite early after few hours
> > > as far as I remember.
> >
> > Did you have chance to run with the patch? I would like to post it for
> > inclusion and feedback from you is really useful.
>
> Yes. It runs since 2017-01-01 and without problems until today.
>
> I think it looks good but that is just my feeling. I don't know if it is
> to early to say that.
>
> I also did some heavy git repository actions to big repositories. The
> system is in swap and still no OOMs.
OK, that is a good indication. I will add your Reported-by to the patch
and if you feel comfortable also Tested-by.
Thanks!
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [KERNEL] Re: [KERNEL] Re: Bug 4.9 and memorymanagement
From: Michal Hocko @ 2017-01-04 8:31 UTC (permalink / raw)
To: Klaus Ethgen; +Cc: linux-kernel, linux-mm
In-Reply-To: <20170104081527.hq5q4ngevcl3c7k6@ikki.ethgen.ch>
On Wed 04-01-17 09:15:27, Klaus Ethgen wrote:
> Hi Michal,
>
> Am Mi den 4. Jan 2017 um 9:06 schrieb Michal Hocko:
>
> > > Just try to run with the patch and do what you do normally. If you do
> > > not see any OOMs in few days it should be sufficient evidence. From your
> > > previous logs it seems you hit the problem quite early after few hours
> > > as far as I remember.
> >
> > Did you have chance to run with the patch? I would like to post it for
> > inclusion and feedback from you is really useful.
>
> Yes. It runs since 2017-01-01 and without problems until today.
>
> I think it looks good but that is just my feeling. I don't know if it is
> to early to say that.
>
> I also did some heavy git repository actions to big repositories. The
> system is in swap and still no OOMs.
OK, that is a good indication. I will add your Reported-by to the patch
and if you feel comfortable also Tested-by.
Thanks!
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even when deferred
From: Vlastimil Babka @ 2017-01-04 8:32 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Jonathan Corbet, Kirill A. Shutemov, Mel Gorman,
linux-kernel, linux-mm
In-Reply-To: <alpine.DEB.2.10.1701031431120.139238@chino.kir.corp.google.com>
On 01/03/2017 11:44 PM, David Rientjes wrote:
> On Mon, 2 Jan 2017, Vlastimil Babka wrote:
>
>> I'm late to the thread (I did read it fully though), so instead of
>> multiple responses, I'll just list my observations here:
>>
>> - "defer", e.g. background kswapd+compaction is not a silver bullet, it
>> will also affect the system. Mel already mentioned extra reclaim.
>> Compaction also has CPU costs, just hides the accounting to a kernel
>> thread so it's not visible as latency. It also increases zone/node
>> lru_lock and lock pressure.
>>
>> For the same reasons, admin might want to limit direct compaction for
>> THP, even for madvise() apps. It's also likely that "defer" might have
>> lower system overhead than "madvise", as with "defer",
>> reclaim/compaction is done by one per-node thread at a time, but there
>> might be multiple madvise() threads. So there might be sense in not
>> allowing madvise() apps to do direct reclaim/compaction on "defer".
>>
>
> Hmm, is there a significant benefit to setting "defer" rather than "never"
> if you can rely on khugepaged to trigger compaction when it tries to
> allocate. I suppose if there is nothing to collapse that this won't do
> compaction, but is this not intended for users who always want to defer
> when not immediately available?
I guess two things
- khugepaged is quite sleepy and will not respond to demand quickly, so
it won't compact that much than kcompactd triggered by "defer"
- thus with "defer" it's more likely that although some THP faults will
fail, others in near future will succeed and benefit from THP
immediately. Again, khugepaged is much slower. But it may recover
long-running processes that were unlucky in the initial faults, so it's
not useless.
> "Defer" in it's current setting is useless, in my opinion, other than
> providing it as a simple workaround to users when their applications are
> doing MADV_HUGEPAGE without allowing them to configure it.
I don't think the primary motivation for "defer" was to restrict
MADV_HUGEPAGE apps, but rather to prevent latency to the majority of
apps oblivious to THP when the default was "always". On the other hand,
setting "madvise" would make performance needlessly worse in some
scenarios, so "defer" is a compromise that tries to provide THP's but
without the latency, and still much more timely than khugepaged.
But that's just my POV, Mel probably has/had also the MADV_HUGEPAGE
restriction in mind. I'd expect that the "you have to disable THP"
cargo-cult originated around apps (databases?) that did not use
MADV_HUGEPAGE, though.
> We would love
> to use "defer" if it didn't completely break MADV_HUGEPAGE, though.
Right.
>> - for overriding specific apps such as QEMU (including their madvise()
>> usage, AFAICS), we have PR_SET_THP_DISABLE prctl(), so no need to
>> LD_PRELOAD stuff IMO.
>>
>
> Very good point, and I think it's also worthwhile to allow users to
> suppress the MADV_HUGEPAGE when allocating a translation buffer in qemu if
> they choose to do so; it's a very trivial patch to qemu to allow this to
> be configurable. I haven't proposed it because I don't personally have a
> need for it, and haven't been pointed to anyone who has a need for it.
>
>> - I have wondered about exactly the issue here when Mel proposed the
>> defer option [1]. Mel responded that it doesn't seem needed at that
>> point. Now it seems it is. Too bad you didn't raise it then, but to be
>> fair you were not CC'd.
>>
>
> My understanding is that the defer option is available to users who cannot
> modify their binary to suppress an madvise(MADV_HUGEPAGE) and are unaware
> that PR_SET_THP_DISABLE exists. The prctl was added specifically when you
> cannot control your binary.
Yeah, it's easier than LD_PRELOAD, but still not system-wide transparent.
>> So would something like this be possible?
>>
>>> echo "defer madvise" > /sys/kernel/mm/transparent_hugepage/defrag
>>> cat /sys/kernel/mm/transparent_hugepage/defrag
>> always [defer] [madvise] never
>>
>> I'm not sure about the analogous kernel boot option though, I guess
>> those can't use spaces, so maybe comma-separated?
No opinion on the above? I think it could be somewhat more elegant than
a fifth-option that Mel said he would prefer, and deliver the same
flexibility.
>> If that's not acceptable, then I would probably rather be for changing
>> "madvise" to include "defer", than the other way around. When we augment
>> kcompactd to be more proactive, it might easily be that it will
>> effectively act as "defer", even when defrag=none is set, anyway.
>>
>
> The concern I have with changing the behavior of "madvise" is that it
> changes long standing behavior that people have correctly implemented
> userspace applications with. I suggest doing this only with "defer" since
> it's an option that is new, nobody appears to be deploying with, and makes
> it much more powerful. I think we could make the kernel default as
> "defer" later as well and not break userspace that has been setting
> "madvise" ever since the 2.6 kernel.
>
> My position is this: userspace that does MADV_HUGEPAGES knows what it's
> doing. Let it stall if it wants to stall. If users don't want it to be
> done, allow them to configure it. If a binary has forced you into using
> it, use the prctl. Otherwise, I think "defer" doing background compaction
> for everybody and direct compaction for users who really want hugepages is
> appropriate and is precisely what I need.
I'm not completely against this. But we haven't really ruled out the
most flexible option yet...
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [patch] mm, thp: always direct reclaim for MADV_HUGEPAGE even when deferred
From: Vlastimil Babka @ 2017-01-04 8:32 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Jonathan Corbet, Kirill A. Shutemov, Mel Gorman,
linux-kernel, linux-mm
In-Reply-To: <alpine.DEB.2.10.1701031431120.139238@chino.kir.corp.google.com>
On 01/03/2017 11:44 PM, David Rientjes wrote:
> On Mon, 2 Jan 2017, Vlastimil Babka wrote:
>
>> I'm late to the thread (I did read it fully though), so instead of
>> multiple responses, I'll just list my observations here:
>>
>> - "defer", e.g. background kswapd+compaction is not a silver bullet, it
>> will also affect the system. Mel already mentioned extra reclaim.
>> Compaction also has CPU costs, just hides the accounting to a kernel
>> thread so it's not visible as latency. It also increases zone/node
>> lru_lock and lock pressure.
>>
>> For the same reasons, admin might want to limit direct compaction for
>> THP, even for madvise() apps. It's also likely that "defer" might have
>> lower system overhead than "madvise", as with "defer",
>> reclaim/compaction is done by one per-node thread at a time, but there
>> might be multiple madvise() threads. So there might be sense in not
>> allowing madvise() apps to do direct reclaim/compaction on "defer".
>>
>
> Hmm, is there a significant benefit to setting "defer" rather than "never"
> if you can rely on khugepaged to trigger compaction when it tries to
> allocate. I suppose if there is nothing to collapse that this won't do
> compaction, but is this not intended for users who always want to defer
> when not immediately available?
I guess two things
- khugepaged is quite sleepy and will not respond to demand quickly, so
it won't compact that much than kcompactd triggered by "defer"
- thus with "defer" it's more likely that although some THP faults will
fail, others in near future will succeed and benefit from THP
immediately. Again, khugepaged is much slower. But it may recover
long-running processes that were unlucky in the initial faults, so it's
not useless.
> "Defer" in it's current setting is useless, in my opinion, other than
> providing it as a simple workaround to users when their applications are
> doing MADV_HUGEPAGE without allowing them to configure it.
I don't think the primary motivation for "defer" was to restrict
MADV_HUGEPAGE apps, but rather to prevent latency to the majority of
apps oblivious to THP when the default was "always". On the other hand,
setting "madvise" would make performance needlessly worse in some
scenarios, so "defer" is a compromise that tries to provide THP's but
without the latency, and still much more timely than khugepaged.
But that's just my POV, Mel probably has/had also the MADV_HUGEPAGE
restriction in mind. I'd expect that the "you have to disable THP"
cargo-cult originated around apps (databases?) that did not use
MADV_HUGEPAGE, though.
> We would love
> to use "defer" if it didn't completely break MADV_HUGEPAGE, though.
Right.
>> - for overriding specific apps such as QEMU (including their madvise()
>> usage, AFAICS), we have PR_SET_THP_DISABLE prctl(), so no need to
>> LD_PRELOAD stuff IMO.
>>
>
> Very good point, and I think it's also worthwhile to allow users to
> suppress the MADV_HUGEPAGE when allocating a translation buffer in qemu if
> they choose to do so; it's a very trivial patch to qemu to allow this to
> be configurable. I haven't proposed it because I don't personally have a
> need for it, and haven't been pointed to anyone who has a need for it.
>
>> - I have wondered about exactly the issue here when Mel proposed the
>> defer option [1]. Mel responded that it doesn't seem needed at that
>> point. Now it seems it is. Too bad you didn't raise it then, but to be
>> fair you were not CC'd.
>>
>
> My understanding is that the defer option is available to users who cannot
> modify their binary to suppress an madvise(MADV_HUGEPAGE) and are unaware
> that PR_SET_THP_DISABLE exists. The prctl was added specifically when you
> cannot control your binary.
Yeah, it's easier than LD_PRELOAD, but still not system-wide transparent.
>> So would something like this be possible?
>>
>>> echo "defer madvise" > /sys/kernel/mm/transparent_hugepage/defrag
>>> cat /sys/kernel/mm/transparent_hugepage/defrag
>> always [defer] [madvise] never
>>
>> I'm not sure about the analogous kernel boot option though, I guess
>> those can't use spaces, so maybe comma-separated?
No opinion on the above? I think it could be somewhat more elegant than
a fifth-option that Mel said he would prefer, and deliver the same
flexibility.
>> If that's not acceptable, then I would probably rather be for changing
>> "madvise" to include "defer", than the other way around. When we augment
>> kcompactd to be more proactive, it might easily be that it will
>> effectively act as "defer", even when defrag=none is set, anyway.
>>
>
> The concern I have with changing the behavior of "madvise" is that it
> changes long standing behavior that people have correctly implemented
> userspace applications with. I suggest doing this only with "defer" since
> it's an option that is new, nobody appears to be deploying with, and makes
> it much more powerful. I think we could make the kernel default as
> "defer" later as well and not break userspace that has been setting
> "madvise" ever since the 2.6 kernel.
>
> My position is this: userspace that does MADV_HUGEPAGES knows what it's
> doing. Let it stall if it wants to stall. If users don't want it to be
> done, allow them to configure it. If a binary has forced you into using
> it, use the prctl. Otherwise, I think "defer" doing background compaction
> for everybody and direct compaction for users who really want hugepages is
> appropriate and is precisely what I need.
I'm not completely against this. But we haven't really ruled out the
most flexible option yet...
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* ti-sgx-ddk-um / do_install failed / cp: cannot stat './targetfs//etc/*': No such file or directory
From: Benjamin Bimmermann @ 2017-01-04 8:32 UTC (permalink / raw)
To: meta-ti@yoctoproject.org
In-Reply-To: <972676697.10149692.1483518767462.ref@mail.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 3645 bytes --]
Hello,
I'm trying to build the ti-sgx-ddk-for the AM33x.
I've tried to build the Krogoth and the morty branch, but both failed.
A few months ago I had this error yet. I also do not understand which files he would like to copy, but not find.
I have attached an extract from my log.
Thank you for your attentionBimmermann
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
log.do_install.19908
Log data follows:
| DEBUG: Executing shell function do_install
| NOTE: make -j7 install DESTDIR=/home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image TARGET_PRODUCT=
| mkdir -p /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/etc
| mkdir -p /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/usr/bin
| mkdir -p /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/usr/include
| mkdir -p /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/usr/lib
| cp -ar ./targetfs//etc/* /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/image/etc
| cp: cannot stat './targetfs//etc/*': No such file or directory
| Makefile:14: recipe for target 'install' failed
| make: *** [install] Error 1
| ERROR: oe_runmake failed
| ERROR: Function failed: do_install (log file is located at /home/bimmermann/bbb/build_Sens_krogoth/tmp/work/beaglebone-poky-linux-gnueabi/ti-sgx-ddk-um/1.14.3699939-r19/temp/log.do_install.19908)
NOTE: recipe ti-sgx-ddk-um-1.14.3699939-r19: task do_install: Failed
ERROR: Task 843 (/home/bimmermann/poky-krogoth/meta-ti/recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb, do_install) failed with exit code '1'
NOTE: Running task 2572 of 3217 (ID: 830, /home/bimmermann/poky-krogoth/meta-BBB_QT5_PSS/meta-BBB_QT5_PSS/recipes-extras/thermal-init/thermal-init.bb, do_install)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Build Configuration:
BB_VERSION = "1.30.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "Ubuntu-16.04"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "beaglebone"
DISTRO = "poky"
DISTRO_VERSION = "2.1.2"
TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard"
TARGET_FPU = "hard"
meta-ti = "krogoth:8663e1611ab6c5bfe36d323d9d9db4dada4bd532"
meta-qt5 = "krogoth:2b1871f0d139dc3caaa779a32a1931409c245a36"
meta-oe = "krogoth:55c8a76da5dc099a7bc3838495c672140cedb78e"
meta
meta-yocto = "krogoth:ae9b341ecfcc60e970f29cfe04306411ad26c0cf"
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[-- Attachment #2: Type: text/html, Size: 8934 bytes --]
^ permalink raw reply
* Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB
From: Daniel Vetter @ 2017-01-04 8:34 UTC (permalink / raw)
To: Jose Abreu; +Cc: Daniel Vetter, Carlos Palminha, dri-devel, linux-kernel
In-Reply-To: <d51f962c25a16951f661cd6c575ab5fe8c2e5a86.1483116605.git.joabreu@synopsys.com>
On Fri, Dec 30, 2016 at 04:53:16PM +0000, Jose Abreu wrote:
> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
> According to the spec the EDID may contain two blocks that
> signal this sampling mode:
> - YCbCr 4:2:0 Video Data Block
> - YCbCr 4:2:0 Video Capability Map Data Block
>
> The video data block contains the list of vic's were
> only YCbCr 4:2:0 sampling mode shall be used while the
> video capability map data block contains a mask were
> YCbCr 4:2:0 sampling mode may be used.
>
> This RFC patch adds support for parsing these two new blocks
> and introduces new flags to signal the drivers if the
> mode is 4:2:0'only or 4:2:0'able.
>
> The reason this is still a RFC is because there is no
> reference in kernel for this new sampling mode (specially in
> AVI infoframe part), so, I was hoping to hear some feedback
> first.
>
> Tested in a HDMI 2.0 compliance scenario.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Cc: Carlos Palminha <palminha@synopsys.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Sean Paul <seanpaul@chromium.org>
> Cc: David Airlie <airlied@linux.ie>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
Thanks for the patch.
Is there driver code to go along with this? Also, since this extends uapi
we need the userspace changes too, and that will probably highlight the
need to hide these fancy special modes behind an explicit opt-in knob that
userspace sets when it understands these flags. Similar to how we handle
3d modes.
-Daniel
> ---
> drivers/gpu/drm/drm_edid.c | 139 +++++++++++++++++++++++++++++++++++++++++++-
> drivers/gpu/drm/drm_modes.c | 10 +++-
> include/uapi/drm/drm_mode.h | 6 ++
> 3 files changed, 151 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 67d6a73..6ce1a38 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct drm_connector *connector,
> #define VENDOR_BLOCK 0x03
> #define SPEAKER_BLOCK 0x04
> #define VIDEO_CAPABILITY_BLOCK 0x07
> +#define VIDEO_DATA_BLOCK_420 0x0E
> +#define VIDEO_CAP_BLOCK_420 0x0F
> #define EDID_BASIC_AUDIO (1 << 6)
> #define EDID_CEA_YCRCB444 (1 << 5)
> #define EDID_CEA_YCRCB422 (1 << 4)
> @@ -3050,6 +3052,98 @@ static int add_3d_struct_modes(struct drm_connector *connector, u16 structure,
> return modes;
> }
>
> +static int add_420_mode(struct drm_connector *connector, u8 vic)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_display_mode *newmode;
> +
> + if (!drm_valid_cea_vic(vic))
> + return 0;
> +
> + newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
> + if (!newmode)
> + return 0;
> +
> + newmode->flags |= DRM_MODE_FLAG_420_ONLY;
> + drm_mode_probed_add(connector, newmode);
> +
> + return 1;
> +}
> +
> +static int add_420_vdb_modes(struct drm_connector *connector, const u8 *svds,
> + u8 svds_len)
> +{
> + int modes = 0, i;
> +
> + for (i = 0; i < svds_len; i++)
> + modes += add_420_mode(connector, svds[i]);
> +
> + return modes;
> +}
> +
> +static int add_420_vcb_modes(struct drm_connector *connector, const u8 *svds,
> + u8 svds_len, const u8 *video_db, u8 video_len)
> +{
> + struct drm_display_mode *newmode = NULL;
> + int modes = 0, i, j;
> +
> + for (i = 0; i < svds_len; i++) {
> + u8 mask = svds[i];
> + for (j = 0; j < 8; j++) {
> + if (mask & (1 << j)) {
> + newmode = drm_display_mode_from_vic_index(
> + connector, video_db, video_len,
> + i * 8 + j);
> + if (newmode) {
> + newmode->flags |= DRM_MODE_FLAG_420;
> + drm_mode_probed_add(connector, newmode);
> + modes++;
> + }
> + }
> + }
> + }
> +
> + return modes;
> +}
> +
> +static int add_420_vcb_modes_all(struct drm_connector *connector,
> + const u8 *video_db, u8 video_len)
> +{
> + struct drm_display_mode *newmode = NULL;
> + int modes = 0, i;
> +
> + for (i = 0; i < video_len; i++) {
> + newmode = drm_display_mode_from_vic_index(connector, video_db,
> + video_len, i);
> + if (newmode) {
> + newmode->flags |= DRM_MODE_FLAG_420;
> + drm_mode_probed_add(connector, newmode);
> + modes++;
> + }
> + }
> +
> + return modes;
> +}
> +
> +static int do_hdmi_420_modes(struct drm_connector *connector, const u8 *vdb,
> + u8 vdb_len, const u8 *vcb, u8 vcb_len, const u8 *video_db,
> + u8 video_len)
> +{
> + int modes = 0;
> +
> + if (vdb && (vdb_len > 1)) /* Add 4:2:0 modes present in EDID */
> + modes += add_420_vdb_modes(connector, &vdb[2], vdb_len - 1);
> +
> + if (vcb && (vcb_len > 1)) /* Parse bit mask of supported modes */
> + modes += add_420_vcb_modes(connector, &vcb[2], vcb_len - 1,
> + video_db, video_len);
> + else if (vcb) /* All modes support 4:2:0 mode */
> + modes += add_420_vcb_modes_all(connector, video_db, video_len);
> +
> + DRM_DEBUG("added %d 4:2:0 modes\n", modes);
> + return modes;
> +}
> +
> /*
> * do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
> * @connector: connector corresponding to the HDMI sink
> @@ -3206,6 +3300,12 @@ static int add_3d_struct_modes(struct drm_connector *connector, u16 structure,
> }
>
> static int
> +cea_db_extended_tag(const u8 *db)
> +{
> + return db[1];
> +}
> +
> +static int
> cea_revision(const u8 *cea)
> {
> return cea[1];
> @@ -3239,6 +3339,28 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
> return hdmi_id == HDMI_IEEE_OUI;
> }
>
> +static bool cea_db_is_hdmi_vdb420(const u8 *db)
> +{
> + if (cea_db_tag(db) != VIDEO_CAPABILITY_BLOCK)
> + return false;
> +
> + if (cea_db_extended_tag(db) != VIDEO_DATA_BLOCK_420)
> + return false;
> +
> + return true;
> +}
> +
> +static bool cea_db_is_hdmi_vcb420(const u8 *db)
> +{
> + if (cea_db_tag(db) != VIDEO_CAPABILITY_BLOCK)
> + return false;
> +
> + if (cea_db_extended_tag(db) != VIDEO_CAP_BLOCK_420)
> + return false;
> +
> + return true;
> +}
> +
> #define for_each_cea_db(cea, i, start, end) \
> for ((i) = (start); (i) < (end) && (i) + cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)]) + 1)
>
> @@ -3246,8 +3368,9 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
> add_cea_modes(struct drm_connector *connector, struct edid *edid)
> {
> const u8 *cea = drm_find_cea_extension(edid);
> - const u8 *db, *hdmi = NULL, *video = NULL;
> - u8 dbl, hdmi_len, video_len = 0;
> + const u8 *db, *hdmi = NULL, *video = NULL, *vdb420 = NULL,
> + *vcb420 = NULL;
> + u8 dbl, hdmi_len, video_len = 0, vdb420_len = 0, vcb420_len = 0;
> int modes = 0;
>
> if (cea && cea_revision(cea) >= 3) {
> @@ -3269,6 +3392,14 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
> hdmi = db;
> hdmi_len = dbl;
> }
> + else if (cea_db_is_hdmi_vdb420(db)) {
> + vdb420 = db;
> + vdb420_len = dbl;
> + }
> + else if (cea_db_is_hdmi_vcb420(db)) {
> + vcb420 = db;
> + vcb420_len = dbl;
> + }
> }
> }
>
> @@ -3280,6 +3411,10 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
> modes += do_hdmi_vsdb_modes(connector, hdmi, hdmi_len, video,
> video_len);
>
> + if (vdb420 || vcb420)
> + modes += do_hdmi_420_modes(connector, vdb420, vdb420_len,
> + vcb420, vcb420_len, video, video_len);
> +
> return modes;
> }
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index ac6a352..53c65f6 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -967,6 +967,10 @@ bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1, const struct
> (mode2->flags & DRM_MODE_FLAG_3D_MASK))
> return false;
>
> + if ((mode1->flags & DRM_MODE_FLAG_420_MASK) !=
> + (mode2->flags & DRM_MODE_FLAG_420_MASK))
> + return false;
> +
> return drm_mode_equal_no_clocks_no_stereo(mode1, mode2);
> }
> EXPORT_SYMBOL(drm_mode_equal_no_clocks);
> @@ -985,6 +989,9 @@ bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1, const struct
> bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode *mode1,
> const struct drm_display_mode *mode2)
> {
> + unsigned int flags_mask =
> + ~(DRM_MODE_FLAG_3D_MASK | DRM_MODE_FLAG_420_MASK);
> +
> if (mode1->hdisplay == mode2->hdisplay &&
> mode1->hsync_start == mode2->hsync_start &&
> mode1->hsync_end == mode2->hsync_end &&
> @@ -995,8 +1002,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode *mode1,
> mode1->vsync_end == mode2->vsync_end &&
> mode1->vtotal == mode2->vtotal &&
> mode1->vscan == mode2->vscan &&
> - (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
> - (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
> + (mode1->flags & flags_mask) == (mode2->flags & flags_mask))
> return true;
>
> return false;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index ce7efe2..dc8e285 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -84,6 +84,12 @@
> #define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (6<<14)
> #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14)
> #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (8<<14)
> +/*
> + * HDMI 2.0
> + */
> +#define DRM_MODE_FLAG_420_MASK (0x03<<19)
> +#define DRM_MODE_FLAG_420 (1<<19)
> +#define DRM_MODE_FLAG_420_ONLY (1<<20)
>
> /* Picture aspect ratio options */
> #define DRM_MODE_PICTURE_ASPECT_NONE 0
> --
> 1.9.1
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC] drm: Parse HDMI 2.0 YCbCr 4:2:0 VDB and VCB
From: Daniel Vetter @ 2017-01-04 8:34 UTC (permalink / raw)
To: Jose Abreu; +Cc: dri-devel, Carlos Palminha, linux-kernel, Daniel Vetter
In-Reply-To: <d51f962c25a16951f661cd6c575ab5fe8c2e5a86.1483116605.git.joabreu@synopsys.com>
On Fri, Dec 30, 2016 at 04:53:16PM +0000, Jose Abreu wrote:
> HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
> According to the spec the EDID may contain two blocks that
> signal this sampling mode:
> - YCbCr 4:2:0 Video Data Block
> - YCbCr 4:2:0 Video Capability Map Data Block
>
> The video data block contains the list of vic's were
> only YCbCr 4:2:0 sampling mode shall be used while the
> video capability map data block contains a mask were
> YCbCr 4:2:0 sampling mode may be used.
>
> This RFC patch adds support for parsing these two new blocks
> and introduces new flags to signal the drivers if the
> mode is 4:2:0'only or 4:2:0'able.
>
> The reason this is still a RFC is because there is no
> reference in kernel for this new sampling mode (specially in
> AVI infoframe part), so, I was hoping to hear some feedback
> first.
>
> Tested in a HDMI 2.0 compliance scenario.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Cc: Carlos Palminha <palminha@synopsys.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Sean Paul <seanpaul@chromium.org>
> Cc: David Airlie <airlied@linux.ie>
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-kernel@vger.kernel.org
Thanks for the patch.
Is there driver code to go along with this? Also, since this extends uapi
we need the userspace changes too, and that will probably highlight the
need to hide these fancy special modes behind an explicit opt-in knob that
userspace sets when it understands these flags. Similar to how we handle
3d modes.
-Daniel
> ---
> drivers/gpu/drm/drm_edid.c | 139 +++++++++++++++++++++++++++++++++++++++++++-
> drivers/gpu/drm/drm_modes.c | 10 +++-
> include/uapi/drm/drm_mode.h | 6 ++
> 3 files changed, 151 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 67d6a73..6ce1a38 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2549,6 +2549,8 @@ static int drm_cvt_modes(struct drm_connector *connector,
> #define VENDOR_BLOCK 0x03
> #define SPEAKER_BLOCK 0x04
> #define VIDEO_CAPABILITY_BLOCK 0x07
> +#define VIDEO_DATA_BLOCK_420 0x0E
> +#define VIDEO_CAP_BLOCK_420 0x0F
> #define EDID_BASIC_AUDIO (1 << 6)
> #define EDID_CEA_YCRCB444 (1 << 5)
> #define EDID_CEA_YCRCB422 (1 << 4)
> @@ -3050,6 +3052,98 @@ static int add_3d_struct_modes(struct drm_connector *connector, u16 structure,
> return modes;
> }
>
> +static int add_420_mode(struct drm_connector *connector, u8 vic)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_display_mode *newmode;
> +
> + if (!drm_valid_cea_vic(vic))
> + return 0;
> +
> + newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
> + if (!newmode)
> + return 0;
> +
> + newmode->flags |= DRM_MODE_FLAG_420_ONLY;
> + drm_mode_probed_add(connector, newmode);
> +
> + return 1;
> +}
> +
> +static int add_420_vdb_modes(struct drm_connector *connector, const u8 *svds,
> + u8 svds_len)
> +{
> + int modes = 0, i;
> +
> + for (i = 0; i < svds_len; i++)
> + modes += add_420_mode(connector, svds[i]);
> +
> + return modes;
> +}
> +
> +static int add_420_vcb_modes(struct drm_connector *connector, const u8 *svds,
> + u8 svds_len, const u8 *video_db, u8 video_len)
> +{
> + struct drm_display_mode *newmode = NULL;
> + int modes = 0, i, j;
> +
> + for (i = 0; i < svds_len; i++) {
> + u8 mask = svds[i];
> + for (j = 0; j < 8; j++) {
> + if (mask & (1 << j)) {
> + newmode = drm_display_mode_from_vic_index(
> + connector, video_db, video_len,
> + i * 8 + j);
> + if (newmode) {
> + newmode->flags |= DRM_MODE_FLAG_420;
> + drm_mode_probed_add(connector, newmode);
> + modes++;
> + }
> + }
> + }
> + }
> +
> + return modes;
> +}
> +
> +static int add_420_vcb_modes_all(struct drm_connector *connector,
> + const u8 *video_db, u8 video_len)
> +{
> + struct drm_display_mode *newmode = NULL;
> + int modes = 0, i;
> +
> + for (i = 0; i < video_len; i++) {
> + newmode = drm_display_mode_from_vic_index(connector, video_db,
> + video_len, i);
> + if (newmode) {
> + newmode->flags |= DRM_MODE_FLAG_420;
> + drm_mode_probed_add(connector, newmode);
> + modes++;
> + }
> + }
> +
> + return modes;
> +}
> +
> +static int do_hdmi_420_modes(struct drm_connector *connector, const u8 *vdb,
> + u8 vdb_len, const u8 *vcb, u8 vcb_len, const u8 *video_db,
> + u8 video_len)
> +{
> + int modes = 0;
> +
> + if (vdb && (vdb_len > 1)) /* Add 4:2:0 modes present in EDID */
> + modes += add_420_vdb_modes(connector, &vdb[2], vdb_len - 1);
> +
> + if (vcb && (vcb_len > 1)) /* Parse bit mask of supported modes */
> + modes += add_420_vcb_modes(connector, &vcb[2], vcb_len - 1,
> + video_db, video_len);
> + else if (vcb) /* All modes support 4:2:0 mode */
> + modes += add_420_vcb_modes_all(connector, video_db, video_len);
> +
> + DRM_DEBUG("added %d 4:2:0 modes\n", modes);
> + return modes;
> +}
> +
> /*
> * do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
> * @connector: connector corresponding to the HDMI sink
> @@ -3206,6 +3300,12 @@ static int add_3d_struct_modes(struct drm_connector *connector, u16 structure,
> }
>
> static int
> +cea_db_extended_tag(const u8 *db)
> +{
> + return db[1];
> +}
> +
> +static int
> cea_revision(const u8 *cea)
> {
> return cea[1];
> @@ -3239,6 +3339,28 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
> return hdmi_id == HDMI_IEEE_OUI;
> }
>
> +static bool cea_db_is_hdmi_vdb420(const u8 *db)
> +{
> + if (cea_db_tag(db) != VIDEO_CAPABILITY_BLOCK)
> + return false;
> +
> + if (cea_db_extended_tag(db) != VIDEO_DATA_BLOCK_420)
> + return false;
> +
> + return true;
> +}
> +
> +static bool cea_db_is_hdmi_vcb420(const u8 *db)
> +{
> + if (cea_db_tag(db) != VIDEO_CAPABILITY_BLOCK)
> + return false;
> +
> + if (cea_db_extended_tag(db) != VIDEO_CAP_BLOCK_420)
> + return false;
> +
> + return true;
> +}
> +
> #define for_each_cea_db(cea, i, start, end) \
> for ((i) = (start); (i) < (end) && (i) + cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)]) + 1)
>
> @@ -3246,8 +3368,9 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
> add_cea_modes(struct drm_connector *connector, struct edid *edid)
> {
> const u8 *cea = drm_find_cea_extension(edid);
> - const u8 *db, *hdmi = NULL, *video = NULL;
> - u8 dbl, hdmi_len, video_len = 0;
> + const u8 *db, *hdmi = NULL, *video = NULL, *vdb420 = NULL,
> + *vcb420 = NULL;
> + u8 dbl, hdmi_len, video_len = 0, vdb420_len = 0, vcb420_len = 0;
> int modes = 0;
>
> if (cea && cea_revision(cea) >= 3) {
> @@ -3269,6 +3392,14 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
> hdmi = db;
> hdmi_len = dbl;
> }
> + else if (cea_db_is_hdmi_vdb420(db)) {
> + vdb420 = db;
> + vdb420_len = dbl;
> + }
> + else if (cea_db_is_hdmi_vcb420(db)) {
> + vcb420 = db;
> + vcb420_len = dbl;
> + }
> }
> }
>
> @@ -3280,6 +3411,10 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
> modes += do_hdmi_vsdb_modes(connector, hdmi, hdmi_len, video,
> video_len);
>
> + if (vdb420 || vcb420)
> + modes += do_hdmi_420_modes(connector, vdb420, vdb420_len,
> + vcb420, vcb420_len, video, video_len);
> +
> return modes;
> }
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index ac6a352..53c65f6 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -967,6 +967,10 @@ bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1, const struct
> (mode2->flags & DRM_MODE_FLAG_3D_MASK))
> return false;
>
> + if ((mode1->flags & DRM_MODE_FLAG_420_MASK) !=
> + (mode2->flags & DRM_MODE_FLAG_420_MASK))
> + return false;
> +
> return drm_mode_equal_no_clocks_no_stereo(mode1, mode2);
> }
> EXPORT_SYMBOL(drm_mode_equal_no_clocks);
> @@ -985,6 +989,9 @@ bool drm_mode_equal_no_clocks(const struct drm_display_mode *mode1, const struct
> bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode *mode1,
> const struct drm_display_mode *mode2)
> {
> + unsigned int flags_mask =
> + ~(DRM_MODE_FLAG_3D_MASK | DRM_MODE_FLAG_420_MASK);
> +
> if (mode1->hdisplay == mode2->hdisplay &&
> mode1->hsync_start == mode2->hsync_start &&
> mode1->hsync_end == mode2->hsync_end &&
> @@ -995,8 +1002,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode *mode1,
> mode1->vsync_end == mode2->vsync_end &&
> mode1->vtotal == mode2->vtotal &&
> mode1->vscan == mode2->vscan &&
> - (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
> - (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
> + (mode1->flags & flags_mask) == (mode2->flags & flags_mask))
> return true;
>
> return false;
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index ce7efe2..dc8e285 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -84,6 +84,12 @@
> #define DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (6<<14)
> #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14)
> #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (8<<14)
> +/*
> + * HDMI 2.0
> + */
> +#define DRM_MODE_FLAG_420_MASK (0x03<<19)
> +#define DRM_MODE_FLAG_420 (1<<19)
> +#define DRM_MODE_FLAG_420_ONLY (1<<20)
>
> /* Picture aspect ratio options */
> #define DRM_MODE_PICTURE_ASPECT_NONE 0
> --
> 1.9.1
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 3/4] Documetation: binding: modify the exynos5440 pcie binding
From: Jaehoon Chung @ 2017-01-04 8:23 UTC (permalink / raw)
To: Rob Herring
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
mark.rutland, kgene, krzk, kishon, jingoohan1, vivek.gautam,
pankaj.dubey, alim.akhtar, cpgs
In-Reply-To: <20170103195144.7fwtlvhzxhq3r25z@rob-hp-laptop>
On 01/04/2017 04:51 AM, Rob Herring wrote:
> On Wed, Dec 28, 2016 at 07:34:53PM +0900, Jaehoon Chung wrote:
>> According to using PHY framework, modified the exynos5440-pcie binding.
>> And use "config" property to follow the designware-pcie binding.
>
> You are breaking compatibility here. Please state that and why it is
> okay to do so.
I will update it..And i'm modifying the patches about maintaining the backward compatibility.
So i will leave the current dt-binding. Just will add the dt-binding example for using phy framework.
How about?
And will add the "DEPRECATED" for some properties. Also will display the kernel message.
>
>>
>> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
>> ---
>> .../bindings/pci/samsung,exynos5440-pcie.txt | 29 +++++++++++++---------
>> 1 file changed, 17 insertions(+), 12 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
>> index 4f9d23d..51f6214 100644
>> --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
>> @@ -5,10 +5,15 @@ and thus inherits all the common properties defined in designware-pcie.txt.
>>
>> Required properties:
>> - compatible: "samsung,exynos5440-pcie"
>> -- reg: base addresses and lengths of the pcie controller,
>> - the phy controller, additional register for the phy controller.
>> +- reg: base addresses and lengths of the pcie controller
>> - interrupts: A list of interrupt outputs for level interrupt,
>> pulse interrupt, special interrupt.
>> +- phys: From PHY binding. Phandle for the Generic PHY.
>> + Refer to Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +- phy-names: Must be "pcie-phy".
>
> -names is pointless for a single element.
Will remove.
>
>> +
>> +Other common properties refer to
>> + Documentation/devicetree/binding/pci/designware-pcie.txt
>>
>> Example:
>>
>> @@ -16,18 +21,18 @@ SoC specific DT Entry:
>>
>> pcie@290000 {
>> compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
>> - reg = <0x290000 0x1000
>> - 0x270000 0x1000
>> - 0x271000 0x40>;
>> + reg = <0x290000 0x1000>, <0x40000000 0x100>;
>
> 256 bytes of config space?
Typo. Will fix.
>
>> + reg-names = "elbi", "config";
>> interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
>> clocks = <&clock 28>, <&clock 27>;
>> clock-names = "pcie", "pcie_bus";
>> #address-cells = <3>;
>> #size-cells = <2>;
>> device_type = "pci";
>> - ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */
>> - 0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */
>> + ranges = <0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */
>> 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
>> + phys = <&pcie_phy0>;
>> + phy-names = "pcie-phy";
>> #interrupt-cells = <1>;
>> interrupt-map-mask = <0 0 0 0>;
>> interrupt-map = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
>> @@ -36,17 +41,17 @@ SoC specific DT Entry:
>>
>> pcie@2a0000 {
>> compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
>> - reg = <0x2a0000 0x1000
>> - 0x272000 0x1000
>> - 0x271040 0x40>;
>> + reg = <0x2a0000 0x1000>, <0x60000000 0x1000>;
>> + reg-names = "elbi", "config";
>> interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
>> clocks = <&clock 29>, <&clock 27>;
>> clock-names = "pcie", "pcie_bus";
>> #address-cells = <3>;
>> #size-cells = <2>;
>> device_type = "pci";
>> - ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */
>> - 0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */
>> + phys = <&pcie_phy1>;
>> + phy-names = "pcie-phy";
>> + ranges = <0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */
>> 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
>> #interrupt-cells = <1>;
>> interrupt-map-mask = <0 0 0 0>;
>> --
>> 2.10.2
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply
* [PATCH] crypto/qat: add scatter gather option to QAT feature flags
From: Arek Kusztal @ 2017-01-04 8:37 UTC (permalink / raw)
To: dev
Cc: fiona.trahe, pablo.de.lara.guarch, john.griffin, deepak.k.jain,
Arek Kusztal
This commit adds scatter gather option to Intel(R) QuickAssist
Technology driver feature flags.
Signed-off-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
---
This patch depends on the following patches/patchsets:
"crypto: add sgl support in sw PMDs"
(http://dpdk.org/dev/patchwork/patch/18693)
drivers/crypto/qat/rte_qat_cryptodev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c b/drivers/crypto/qat/rte_qat_cryptodev.c
index 1e7ee61..9594067 100644
--- a/drivers/crypto/qat/rte_qat_cryptodev.c
+++ b/drivers/crypto/qat/rte_qat_cryptodev.c
@@ -100,7 +100,8 @@ crypto_qat_dev_init(__attribute__((unused)) struct rte_cryptodev_driver *crypto_
cryptodev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
RTE_CRYPTODEV_FF_HW_ACCELERATED |
- RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING;
+ RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING |
+ RTE_CRYPTODEV_FF_MBUF_SCATTER_GATHER;
internals = cryptodev->data->dev_private;
internals->max_nb_sessions = RTE_QAT_PMD_MAX_NB_SESSIONS;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v7 2/2] tpm: add securityfs support for TPM 2.0 firmware event log
From: Nayna @ 2017-01-04 8:38 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20170103133309.lt5k4c37rjq5vcbq-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On 01/03/2017 07:03 PM, Jarkko Sakkinen wrote:
> On Tue, Jan 03, 2017 at 01:09:18PM +0530, Nayna wrote:
>>
>>
>> On 01/03/2017 03:42 AM, Jarkko Sakkinen wrote:
>>> On Sun, Dec 11, 2016 at 12:35:33AM -0500, Nayna Jain wrote:
>>>> Unlike the device driver support for TPM 1.2, the TPM 2.0 does
>>>> not support the securityfs pseudo files for displaying the
>>>> firmware event log.
>>>>
>>>> This patch enables support for providing the TPM 2.0 event log in
>>>> binary form. TPM 2.0 event log supports a crypto agile format that
>>>> records multiple digests, which is different from TPM 1.2. This
>>>> patch enables the tpm_bios_log_setup for TPM 2.0 and adds the
>>>> event log parser which understand the TPM 2.0 crypto agile format.
>>>>
>>>> Signed-off-by: Nayna Jain <nayna-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
>>>
>>> There is something fundamentally wrong in this commit.
>>>
>>> You must not allow this feature unless CONFIG_OF is set. It is the only
>>> interface where the supply path of the event log is well defined on
>>> platforms that include a TPM 2.0 chip.
>>
>> As per current implementation, if ACPI with TPM 2.0 doesn't support event
>> log, tpm_read_log_acpi() is expected to return rc and tpm_bios_log_setup
>> will not create securityfs. This is inline with our design for TPM 1.2 event
>> log.
>
> At minimum you must have a check for TPM_CHIP_FLAG_TPM2 in the beginning
> of tpm_read_log_acpi. It is wrong to even try to open TCPA in this case.
Sure, will add this check and return -ENODEV if check passes.
Thanks & Regards,
- Nayna
>
> /Jarkko
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
^ permalink raw reply
* Re: RFC: fb restore on drm master close
From: Stéphane Marchesin @ 2017-01-04 8:38 UTC (permalink / raw)
To: Daniel Vetter; +Cc: vcaputo, dri-devel@lists.freedesktop.org
In-Reply-To: <20170104083023.m6dqd3hh57twivvr@phenom.ffwll.local>
On Wed, Jan 4, 2017 at 12:30 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Dec 21, 2016 at 12:13:06PM -0600, vcaputo@pengaru.com wrote:
>> Hello list,
>>
>> I've been playing with an unaccelerated drm program[1] and have been
>> annoyed that whenever this program exits the fbcon isn't restored, with
>> the display left completely off.
>>
>> This seems to happen because Xorg is still running from a different VT.
>>
>> Upon further investigation, it seems like the fb restore only occurs on
>> "lastclose", which explains what I'm observing.
>>
>> Why don't we perform the fb restore whenever the current master is
>> closed to cover this case, since masters are the ones that can change
>> modes?
One case where it's useful not to do this is the handoff from a splash
screen to a display server.
Stéphane
>>
>> My github has a quick-n-dirty i915 implementation[2] which seems to fix
>> this without negative effects, though I haven't exhaustively tested to
>> see what breaks.
>>
>> This isn't a list I subscribe to so please CC me directly in any
>> replies, thanks everyone!
>
> The fbdev restore on lastclose was just a "oops, my X died and I have a
> black screen now" debug aid. Apps are supposed to restore fbdev themselves
> by switching back to text mode using KD_TEXT, which I think forces the
> modeset.
>
> In general though the fbdev vs. kms interaction is very ill-defined and
> mostly boils down to fbdev staying out of the way if anyone even might be
> using the native drm interfaces. We have the drm_fb_helper_is_bound check,
> but it's not used consistently either.
>
> Long story short, the answer to your question is "because no one yet
> thought this through", and I'm not clear at all what we should be doing
> here (if anything). I'm not sure whether your patch is the right approach,
> one issue it definitely has is that it only updates i915.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
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.