* [PATCH v2] Fix loading of module radeonfb on PowerMac
From: Mathieu Malaterre @ 2016-11-14 19:59 UTC (permalink / raw)
To: linux-fbdev
Cc: Lennart Sorensen, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Benjamin Herrenschmidt,
linuxppc-dev, Mathieu Malaterre
When the linux kernel is build with (typical kernel ship with Debian
installer):
CONFIG_FB_OF=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_FB_RADEON=m
The offb driver takes precedence over module radeonfb. It is then
impossible to load the module, error reported is:
[ 96.551486] radeonfb 0000:00:10.0: enabling device (0006 -> 0007)
[ 96.551526] radeonfb 0000:00:10.0: BAR 0: can't reserve [mem 0x98000000-0x9fffffff pref]
[ 96.551531] radeonfb (0000:00:10.0): cannot request region 0.
[ 96.551545] radeonfb: probe of 0000:00:10.0 failed with error -16
This patch reproduce the behavior of the module radeon, so as to make it
possible to load radeonfb when offb is first loaded.
It should be noticed that `offb_destroy` is never called which explain the
need to skip error detection on the radeon side.
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Link: https://bugs.debian.org/826629#57
Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741
Suggested-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
---
drivers/video/fbdev/aty/radeon_base.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/video/fbdev/aty/radeon_base.c b/drivers/video/fbdev/aty/radeon_base.c
index 218339a..84d634b 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2259,6 +2259,22 @@ static struct bin_attribute edid2_attr = {
.read = radeon_show_edid2,
};
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+ struct apertures_struct *ap;
+
+ ap = alloc_apertures(1);
+ if (!ap)
+ return -ENOMEM;
+
+ ap->ranges[0].base = pci_resource_start(pdev, 0);
+ ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+ remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
+ kfree(ap);
+
+ return 0;
+}
static int radeonfb_pci_register(struct pci_dev *pdev,
const struct pci_device_id *ent)
@@ -2314,19 +2330,27 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
rinfo->fb_base_phys = pci_resource_start (pdev, 0);
rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
+ ret = radeon_kick_out_firmware_fb(pdev);
+ if (ret)
+ return ret;
+
/* request the mem regions */
ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
pci_name(rinfo->pdev));
+#ifndef CONFIG_PPC
goto err_release_fb;
+#endif
}
ret = pci_request_region(pdev, 2, "radeonfb mmio");
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
pci_name(rinfo->pdev));
+#ifndef CONFIG_PPC
goto err_release_pci0;
+#endif
}
/* map the regions */
@@ -2511,10 +2535,12 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
iounmap(rinfo->mmio_base);
err_release_pci2:
pci_release_region(pdev, 2);
+#ifndef CONFIG_PPC
err_release_pci0:
pci_release_region(pdev, 0);
err_release_fb:
framebuffer_release(info);
+#endif
err_disable:
err_out:
return ret;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v7 13/14] mmc: sdhci-msm: Add calibration tuning for CDCLP533 circuit
From: Stephen Boyd @ 2016-11-14 19:59 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav
In-Reply-To: <1479103248-9491-14-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> @@ -575,6 +729,15 @@ static void sdhci_msm_set_uhs_signaling(struct sdhci_host *host,
> dev_dbg(mmc_dev(mmc), "%s: clock=%u uhs=%u ctrl_2=0x%x\n",
> mmc_hostname(host->mmc), host->clock, uhs, ctrl_2);
> sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
> +
> + spin_unlock_irq(&host->lock);
> + /* CDCLP533 HW calibration is only required for HS400 mode*/
> + if (host->clock > CORE_FREQ_100MHZ &&
> + msm_host->tuning_done && !msm_host->calibration_done &&
> + (mmc->ios.timing == MMC_TIMING_MMC_HS400))
Drop useless parenthesis.
> + if (!sdhci_msm_cdclp533_calibration(host))
> + msm_host->calibration_done = true;
> + spin_lock_irq(&host->lock);
> }
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2] Fix loading of module radeonfb on PowerMac
From: Mathieu Malaterre @ 2016-11-14 19:59 UTC (permalink / raw)
To: linux-fbdev
Cc: Lennart Sorensen, Tomi Valkeinen,
Jean-Christophe Plagniol-Villard, Benjamin Herrenschmidt,
linuxppc-dev, Mathieu Malaterre
When the linux kernel is build with (typical kernel ship with Debian
installer):
CONFIG_FB_OF=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_FB_RADEON=m
The offb driver takes precedence over module radeonfb. It is then
impossible to load the module, error reported is:
[ 96.551486] radeonfb 0000:00:10.0: enabling device (0006 -> 0007)
[ 96.551526] radeonfb 0000:00:10.0: BAR 0: can't reserve [mem 0x98000000-0x9fffffff pref]
[ 96.551531] radeonfb (0000:00:10.0): cannot request region 0.
[ 96.551545] radeonfb: probe of 0000:00:10.0 failed with error -16
This patch reproduce the behavior of the module radeon, so as to make it
possible to load radeonfb when offb is first loaded.
It should be noticed that `offb_destroy` is never called which explain the
need to skip error detection on the radeon side.
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Link: https://bugs.debian.org/826629#57
Link: https://bugzilla.kernel.org/show_bug.cgi?id\x119741
Suggested-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
---
drivers/video/fbdev/aty/radeon_base.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/video/fbdev/aty/radeon_base.c b/drivers/video/fbdev/aty/radeon_base.c
index 218339a..84d634b 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2259,6 +2259,22 @@ static struct bin_attribute edid2_attr = {
.read = radeon_show_edid2,
};
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+ struct apertures_struct *ap;
+
+ ap = alloc_apertures(1);
+ if (!ap)
+ return -ENOMEM;
+
+ ap->ranges[0].base = pci_resource_start(pdev, 0);
+ ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+ remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
+ kfree(ap);
+
+ return 0;
+}
static int radeonfb_pci_register(struct pci_dev *pdev,
const struct pci_device_id *ent)
@@ -2314,19 +2330,27 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
rinfo->fb_base_phys = pci_resource_start (pdev, 0);
rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
+ ret = radeon_kick_out_firmware_fb(pdev);
+ if (ret)
+ return ret;
+
/* request the mem regions */
ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
pci_name(rinfo->pdev));
+#ifndef CONFIG_PPC
goto err_release_fb;
+#endif
}
ret = pci_request_region(pdev, 2, "radeonfb mmio");
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
pci_name(rinfo->pdev));
+#ifndef CONFIG_PPC
goto err_release_pci0;
+#endif
}
/* map the regions */
@@ -2511,10 +2535,12 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
iounmap(rinfo->mmio_base);
err_release_pci2:
pci_release_region(pdev, 2);
+#ifndef CONFIG_PPC
err_release_pci0:
pci_release_region(pdev, 0);
err_release_fb:
framebuffer_release(info);
+#endif
err_disable:
err_out:
return ret;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 3/3] blk-mq: make the polling code adaptive
From: Jens Axboe @ 2016-11-14 19:58 UTC (permalink / raw)
To: Omar Sandoval; +Cc: axboe, linux-block, linux-fsdevel, hch
In-Reply-To: <20161114194305.GB31821@vader.DHCP.thefacebook.com>
On 11/14/2016 12:43 PM, Omar Sandoval wrote:
,9 +2539,10 @@ static bool blk_mq_poll_hybrid_sleep(struct request_queue *q,
>> * This will be replaced with the stats tracking code, using
>> * 'avg_completion_time / 2' as the pre-sleep target.
>> */
>> - kt = ktime_set(0, q->poll_nsec);
>> + kt = ktime_set(0, nsecs);
>>
>> - hrtimer_init_on_stack(&hs.timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
>> + mode = HRTIMER_MODE_REL;
>> + hrtimer_init_on_stack(&hs.timer, CLOCK_MONOTONIC, mode);
>> hrtimer_set_expires(&hs.timer, kt);
>>
>> hrtimer_init_sleeper(&hs, current);
>> @@ -2487,10 +2550,11 @@ static bool blk_mq_poll_hybrid_sleep(struct request_queue *q,
>> if (test_bit(REQ_ATOM_COMPLETE, &rq->atomic_flags))
>> break;
>> set_current_state(TASK_UNINTERRUPTIBLE);
>> - hrtimer_start_expires(&hs.timer, HRTIMER_MODE_REL);
>> + hrtimer_start_expires(&hs.timer, mode);
>> if (hs.task)
>> io_schedule();
>> hrtimer_cancel(&hs.timer);
>> + mode = HRTIMER_MODE_ABS;
>> } while (hs.task && !signal_pending(current));
>
> This fix should be folded into patch 2.
Good point, I'll do that.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 3/3] blk-mq: make the polling code adaptive
From: Jens Axboe @ 2016-11-14 19:58 UTC (permalink / raw)
To: Omar Sandoval; +Cc: axboe, linux-block, linux-fsdevel, hch
In-Reply-To: <20161114194305.GB31821@vader.DHCP.thefacebook.com>
On 11/14/2016 12:43 PM, Omar Sandoval wrote:
,9 +2539,10 @@ static bool blk_mq_poll_hybrid_sleep(struct request_queue *q,
>> * This will be replaced with the stats tracking code, using
>> * 'avg_completion_time / 2' as the pre-sleep target.
>> */
>> - kt = ktime_set(0, q->poll_nsec);
>> + kt = ktime_set(0, nsecs);
>>
>> - hrtimer_init_on_stack(&hs.timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
>> + mode = HRTIMER_MODE_REL;
>> + hrtimer_init_on_stack(&hs.timer, CLOCK_MONOTONIC, mode);
>> hrtimer_set_expires(&hs.timer, kt);
>>
>> hrtimer_init_sleeper(&hs, current);
>> @@ -2487,10 +2550,11 @@ static bool blk_mq_poll_hybrid_sleep(struct request_queue *q,
>> if (test_bit(REQ_ATOM_COMPLETE, &rq->atomic_flags))
>> break;
>> set_current_state(TASK_UNINTERRUPTIBLE);
>> - hrtimer_start_expires(&hs.timer, HRTIMER_MODE_REL);
>> + hrtimer_start_expires(&hs.timer, mode);
>> if (hs.task)
>> io_schedule();
>> hrtimer_cancel(&hs.timer);
>> + mode = HRTIMER_MODE_ABS;
>> } while (hs.task && !signal_pending(current));
>
> This fix should be folded into patch 2.
Good point, I'll do that.
--
Jens Axboe
^ permalink raw reply
* [Qemu-devel] [PULL 4/4] migration: Fix return code of ram_save_iterate()
From: Juan Quintela @ 2016-11-14 19:57 UTC (permalink / raw)
To: qemu-devel; +Cc: amit.shah, dgilbert, Thomas Huth
In-Reply-To: <1479153474-2401-1-git-send-email-quintela@redhat.com>
From: Thomas Huth <thuth@redhat.com>
qemu_savevm_state_iterate() expects the iterators to return 1
when they are done, and 0 if there is still something left to do.
However, ram_save_iterate() does not obey this rule and returns
the number of saved pages instead. This causes a fatal hang with
ppc64 guests when you run QEMU like this (also works with TCG):
qemu-img create -f qcow2 /tmp/test.qcow2 1M
qemu-system-ppc64 -nographic -nodefaults -m 256 \
-hda /tmp/test.qcow2 -serial mon:stdio
... then switch to the monitor by pressing CTRL-a c and try to
save a snapshot with "savevm test1" for example.
After the first iteration, ram_save_iterate() always returns 0 here,
so that qemu_savevm_state_iterate() hangs in an endless loop and you
can only "kill -9" the QEMU process.
Fix it by using proper return values in ram_save_iterate().
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
---
migration/ram.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index fb9252d..a1c8089 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1987,7 +1987,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
int ret;
int i;
int64_t t0;
- int pages_sent = 0;
+ int done = 0;
rcu_read_lock();
if (ram_list.version != last_version) {
@@ -2007,9 +2007,9 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
pages = ram_find_and_save_block(f, false, &bytes_transferred);
/* no more pages to sent */
if (pages == 0) {
+ done = 1;
break;
}
- pages_sent += pages;
acct_info.iterations++;
/* we want to check in the 1st loop, just in case it was the 1st time
@@ -2044,7 +2044,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
return ret;
}
- return pages_sent;
+ return done;
}
/* Called with iothread lock */
--
2.7.4
^ permalink raw reply related
* [Qemu-devel] [PULL 2/4] tests/test-vmstate.c: add save_buffer util func
From: Juan Quintela @ 2016-11-14 19:57 UTC (permalink / raw)
To: qemu-devel; +Cc: amit.shah, dgilbert, Halil Pasic
In-Reply-To: <1479153474-2401-1-git-send-email-quintela@redhat.com>
From: Halil Pasic <pasic@linux.vnet.ibm.com>
Let us de-duplicate some code by introducing an utility function for
saving a chunk of bytes (used when testing load based on wire).
Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Reviewed-by: Guenther Hutzl <hutzl@linux.vnet.ibm.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
---
tests/test-vmstate.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
index d8da26f..d513dc6 100644
--- a/tests/test-vmstate.c
+++ b/tests/test-vmstate.c
@@ -83,6 +83,13 @@ static void save_vmstate(const VMStateDescription *desc, void *obj)
qemu_fclose(f);
}
+static void save_buffer(const uint8_t *buf, size_t buf_size)
+{
+ QEMUFile *fsave = open_test_file(true);
+ qemu_put_buffer(fsave, buf, buf_size);
+ qemu_fclose(fsave);
+}
+
static void compare_vmstate(uint8_t *wire, size_t size)
{
QEMUFile *f = open_test_file(false);
@@ -309,15 +316,13 @@ static const VMStateDescription vmstate_versioned = {
static void test_load_v1(void)
{
- QEMUFile *fsave = open_test_file(true);
uint8_t buf[] = {
0, 0, 0, 10, /* a */
0, 0, 0, 30, /* c */
0, 0, 0, 0, 0, 0, 0, 40, /* d */
QEMU_VM_EOF, /* just to ensure we won't get EOF reported prematurely */
};
- qemu_put_buffer(fsave, buf, sizeof(buf));
- qemu_fclose(fsave);
+ save_buffer(buf, sizeof(buf));
QEMUFile *loading = open_test_file(false);
TestStruct obj = { .b = 200, .e = 500, .f = 600 };
@@ -334,7 +339,6 @@ static void test_load_v1(void)
static void test_load_v2(void)
{
- QEMUFile *fsave = open_test_file(true);
uint8_t buf[] = {
0, 0, 0, 10, /* a */
0, 0, 0, 20, /* b */
@@ -344,8 +348,7 @@ static void test_load_v2(void)
0, 0, 0, 0, 0, 0, 0, 60, /* f */
QEMU_VM_EOF, /* just to ensure we won't get EOF reported prematurely */
};
- qemu_put_buffer(fsave, buf, sizeof(buf));
- qemu_fclose(fsave);
+ save_buffer(buf, sizeof(buf));
QEMUFile *loading = open_test_file(false);
TestStruct obj;
@@ -423,7 +426,6 @@ static void test_save_skip(void)
static void test_load_noskip(void)
{
- QEMUFile *fsave = open_test_file(true);
uint8_t buf[] = {
0, 0, 0, 10, /* a */
0, 0, 0, 20, /* b */
@@ -433,8 +435,7 @@ static void test_load_noskip(void)
0, 0, 0, 0, 0, 0, 0, 60, /* f */
QEMU_VM_EOF, /* just to ensure we won't get EOF reported prematurely */
};
- qemu_put_buffer(fsave, buf, sizeof(buf));
- qemu_fclose(fsave);
+ save_buffer(buf, sizeof(buf));
QEMUFile *loading = open_test_file(false);
TestStruct obj = { .skip_c_e = false };
@@ -451,7 +452,6 @@ static void test_load_noskip(void)
static void test_load_skip(void)
{
- QEMUFile *fsave = open_test_file(true);
uint8_t buf[] = {
0, 0, 0, 10, /* a */
0, 0, 0, 20, /* b */
@@ -459,8 +459,7 @@ static void test_load_skip(void)
0, 0, 0, 0, 0, 0, 0, 60, /* f */
QEMU_VM_EOF, /* just to ensure we won't get EOF reported prematurely */
};
- qemu_put_buffer(fsave, buf, sizeof(buf));
- qemu_fclose(fsave);
+ save_buffer(buf, sizeof(buf));
QEMUFile *loading = open_test_file(false);
TestStruct obj = { .skip_c_e = true, .c = 300, .e = 500 };
--
2.7.4
^ permalink raw reply related
* [Qemu-devel] [PULL 0/4] Migration pull
From: Juan Quintela @ 2016-11-14 19:57 UTC (permalink / raw)
To: qemu-devel; +Cc: amit.shah, dgilbert
The following changes since commit 83c83f9a5266ff113060f887f106a47920fa6974:
Merge remote-tracking branch 'bonzini/tags/for-upstream' into staging (2016-11-11 12:51:50 +0000)
are available in the git repository at:
git://github.com/juanquintela/qemu.git tags/migration/20161114
for you to fetch changes up to 5c90308f07335451a08c030dc40a9eed4698152b:
migration: Fix return code of ram_save_iterate() (2016-11-14 19:35:41 +0100)
----------------------------------------------------------------
migration/next for 20161114
Hi
In this pull:
- two more tests (halil)
- fix return code of ram_save_iterate (thomas)
- fix assignment for has_x_chackponit_delay (zhang)
Please apply, Juan.
----------------------------------------------------------------
Halil Pasic (2):
tests/test-vmstate.c: add save_buffer util func
tests/test-vmstate.c: add array of pointer to struct
Thomas Huth (1):
migration: Fix return code of ram_save_iterate()
zhanghailiang (1):
migration: fix missing assignment for has_x_checkpoint_delay
hmp.c | 1 +
migration/migration.c | 1 +
migration/ram.c | 6 ++--
tests/test-vmstate.c | 97 ++++++++++++++++++++++++++++++++++++++++++++-------
4 files changed, 90 insertions(+), 15 deletions(-)
^ permalink raw reply
* [Qemu-devel] [PULL 1/4] migration: fix missing assignment for has_x_checkpoint_delay
From: Juan Quintela @ 2016-11-14 19:57 UTC (permalink / raw)
To: qemu-devel; +Cc: amit.shah, dgilbert, zhanghailiang
In-Reply-To: <1479153474-2401-1-git-send-email-quintela@redhat.com>
From: zhanghailiang <zhang.zhanghailiang@huawei.com>
We forgot to assign true to params->has_x_checkpoint_delay parameter
in qmp_query_migrate_parameters.
Without this, qmp command 'query-migrate-parameters' doesn't show the
default value for x-checkpoint-delay option.
This also fixes the fact that HMP was relying on unspecified behavior by
reading x_checkpoint_delay without checking has_x_checkpoint_delay.
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
---
hmp.c | 1 +
migration/migration.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/hmp.c b/hmp.c
index b5e3f54..02103df 100644
--- a/hmp.c
+++ b/hmp.c
@@ -318,6 +318,7 @@ void hmp_info_migrate_parameters(Monitor *mon, const QDict *qdict)
monitor_printf(mon, " %s: %" PRId64 " milliseconds",
MigrationParameter_lookup[MIGRATION_PARAMETER_DOWNTIME_LIMIT],
params->downtime_limit);
+ assert(params->has_x_checkpoint_delay);
monitor_printf(mon, " %s: %" PRId64,
MigrationParameter_lookup[MIGRATION_PARAMETER_X_CHECKPOINT_DELAY],
params->x_checkpoint_delay);
diff --git a/migration/migration.c b/migration/migration.c
index e331f28..f498ab8 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -593,6 +593,7 @@ MigrationParameters *qmp_query_migrate_parameters(Error **errp)
params->max_bandwidth = s->parameters.max_bandwidth;
params->has_downtime_limit = true;
params->downtime_limit = s->parameters.downtime_limit;
+ params->has_x_checkpoint_delay = true;
params->x_checkpoint_delay = s->parameters.x_checkpoint_delay;
return params;
--
2.7.4
^ permalink raw reply related
* [Qemu-devel] [PULL 3/4] tests/test-vmstate.c: add array of pointer to struct
From: Juan Quintela @ 2016-11-14 19:57 UTC (permalink / raw)
To: qemu-devel; +Cc: amit.shah, dgilbert, Halil Pasic
In-Reply-To: <1479153474-2401-1-git-send-email-quintela@redhat.com>
From: Halil Pasic <pasic@linux.vnet.ibm.com>
Increase test coverage by adding tests for the macro
VMSTATE_ARRAY_OF_POINTER_TO_STRUCT.
Signed-off-by: Halil Pasic <pasic@linux.vnet.ibm.com>
Reviewed-by: Guenther Hutzl <hutzl@linux.vnet.ibm.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Juan Quintela <quintela@redhat.com>
---
tests/test-vmstate.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 74 insertions(+)
diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
index d513dc6..d2f529b 100644
--- a/tests/test-vmstate.c
+++ b/tests/test-vmstate.c
@@ -474,6 +474,76 @@ static void test_load_skip(void)
qemu_fclose(loading);
}
+
+typedef struct {
+ int32_t i;
+} TestStructTriv;
+
+const VMStateDescription vmsd_tst = {
+ .name = "test/tst",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_INT32(i, TestStructTriv),
+ VMSTATE_END_OF_LIST()
+ }
+};
+
+#define AR_SIZE 4
+
+typedef struct {
+ TestStructTriv *ar[AR_SIZE];
+} TestArrayOfPtrToStuct;
+
+const VMStateDescription vmsd_arps = {
+ .name = "test/arps",
+ .version_id = 1,
+ .minimum_version_id = 1,
+ .fields = (VMStateField[]) {
+ VMSTATE_ARRAY_OF_POINTER_TO_STRUCT(ar, TestArrayOfPtrToStuct,
+ AR_SIZE, 0, vmsd_tst, TestStructTriv),
+ VMSTATE_END_OF_LIST()
+ }
+};
+static void test_arr_ptr_str_no0_save(void)
+{
+ TestStructTriv ar[AR_SIZE] = {{.i = 0}, {.i = 1}, {.i = 2}, {.i = 3} };
+ TestArrayOfPtrToStuct sample = {.ar = {&ar[0], &ar[1], &ar[2], &ar[3]} };
+ uint8_t wire_sample[] = {
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x01,
+ 0x00, 0x00, 0x00, 0x02,
+ 0x00, 0x00, 0x00, 0x03,
+ QEMU_VM_EOF
+ };
+
+ save_vmstate(&vmsd_arps, &sample);
+ compare_vmstate(wire_sample, sizeof(wire_sample));
+}
+
+static void test_arr_ptr_str_no0_load(void)
+{
+ TestStructTriv ar_gt[AR_SIZE] = {{.i = 0}, {.i = 1}, {.i = 2}, {.i = 3} };
+ TestStructTriv ar[AR_SIZE] = {};
+ TestArrayOfPtrToStuct obj = {.ar = {&ar[0], &ar[1], &ar[2], &ar[3]} };
+ int idx;
+ uint8_t wire_sample[] = {
+ 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x01,
+ 0x00, 0x00, 0x00, 0x02,
+ 0x00, 0x00, 0x00, 0x03,
+ QEMU_VM_EOF
+ };
+
+ save_buffer(wire_sample, sizeof(wire_sample));
+ SUCCESS(load_vmstate_one(&vmsd_arps, &obj, 1,
+ wire_sample, sizeof(wire_sample)));
+ for (idx = 0; idx < AR_SIZE; ++idx) {
+ /* compare the target array ar with the ground truth array ar_gt */
+ g_assert_cmpint(ar_gt[idx].i, ==, ar[idx].i);
+ }
+}
+
int main(int argc, char **argv)
{
temp_fd = mkstemp(temp_file);
@@ -488,6 +558,10 @@ int main(int argc, char **argv)
g_test_add_func("/vmstate/field_exists/load/skip", test_load_skip);
g_test_add_func("/vmstate/field_exists/save/noskip", test_save_noskip);
g_test_add_func("/vmstate/field_exists/save/skip", test_save_skip);
+ g_test_add_func("/vmstate/array/ptr/str/no0/save",
+ test_arr_ptr_str_no0_save);
+ g_test_add_func("/vmstate/array/ptr/str/no0/load",
+ test_arr_ptr_str_no0_load);
g_test_run();
close(temp_fd);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v7 14/14] sdhci: sdhci-msm: update dll configuration
From: Stephen Boyd @ 2016-11-14 19:57 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson, linux-mmc, adrian.hunter, shawn.lin, andy.gross,
devicetree, linux-clk, david.brown, linux-arm-msm, georgi.djakov,
alex.lemberg, mateusz.nowak, Yuliy.Izrailov, asutoshd, kdorfman,
david.griego, stummala, venkatg, rnayak, pramod.gurav,
Krishna Konda
In-Reply-To: <1479103248-9491-15-git-send-email-riteshh@codeaurora.org>
On 11/14, Ritesh Harjani wrote:
> @@ -903,7 +998,33 @@ static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> config |= CORE_HC_SELECT_IN_EN;
> writel_relaxed(config, host->ioaddr + CORE_VENDOR_SPEC);
> }
> + if (!msm_host->clk_rate && !msm_host->use_cdclp533) {
> + /*
> + * Poll on DLL_LOCK or DDR_DLL_LOCK bits in
> + * CORE_DLL_STATUS to be set. This should get set
> + * within 15 us at 200 MHz.
> + */
> + rc = readl_relaxed_poll_timeout(host->ioaddr +
> + CORE_DLL_STATUS,
> + dll_lock,
> + (dll_lock &
> + (CORE_DLL_LOCK |
> + CORE_DDR_DLL_LOCK)), 10,
> + 1000);
> + if (rc == -ETIMEDOUT)
> + pr_err("%s: Unable to get DLL_LOCK/DDR_DLL_LOCK, dll_status: 0x%08x\n",
> + mmc_hostname(host->mmc), dll_lock);
> + }
> } else {
> + if (!msm_host->use_cdclp533) {
> + /* set CORE_PWRSAVE_DLL bit in CORE_VENDOR_SPEC3 */
These types of comments are totally useless. The code says
exactly what is being done, and the comment is actually wrong in
this case. Please remove all these "set/clear bit X in register
Y" comments.
> + config = readl_relaxed(host->ioaddr +
> + CORE_VENDOR_SPEC3);
> + config &= ~CORE_PWRSAVE_DLL;
> + writel_relaxed(config, host->ioaddr +
> + CORE_VENDOR_SPEC3);
> + }
> +
> /* Select the default clock (free running MCLK) */
> config = readl_relaxed(host->ioaddr + CORE_VENDOR_SPEC);
> config &= ~CORE_HC_MCLK_SEL_MASK;
> @@ -1100,6 +1221,13 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> msm_host->use_14lpp_dll_reset = true;
>
> /*
> + * SDCC 5 controller with major version 1, minor version 0x34 and later
> + * with HS 400 mode support will use CM DLL instead of CDC LP 533 DLL.
> + */
> + if ((core_major == 1) && (core_minor < 0x34))
Drop useless parenthesis please.
> + msm_host->use_cdclp533 = true;
> +
> + /*
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Austin S. Hemmelgarn @ 2016-11-14 19:56 UTC (permalink / raw)
To: Zygo Blaxell; +Cc: James Pharaoh, Mark Fasheh, linux-btrfs
In-Reply-To: <20161114195102.GI21290@hungrycats.org>
On 2016-11-14 14:51, Zygo Blaxell wrote:
> On Mon, Nov 14, 2016 at 01:39:02PM -0500, Austin S. Hemmelgarn wrote:
>> On 2016-11-14 13:22, James Pharaoh wrote:
>>> One thing I am keen to understand is if BTRFS will automatically ignore
>>> a request to deduplicate a file if it is already deduplicated? Given the
>>> performance I see when doing a repeat deduplication, it seems to me that
>>> it can't be doing so, although this could be caused by the CPU usage you
>>> mention above.
>> What's happening is that the dedupe ioctl does a byte-wise comparison of the
>> ranges to make sure they're the same before linking them. This is actually
>> what takes most of the time when calling the ioctl, and is part of why it
>> takes longer the larger the range to deduplicate is. In essence, it's
>> behaving like an OS should and not trusting userspace to make reasonable
>> requests (which is also why there's a separate ioctl to clone a range from
>> another file instead of deduplicating existing data).
>
> Deduplicating an extent that may might be concurrently modified during the
> dedup is a reasonable userspace request. In the general case there's
> no way for userspace to ensure that it's not happening.
I'm not even talking about the locking, I'm talking about the data
comparison that the ioctl does to ensure they are the same before
deduplicating them, and specifically that protecting against userspace
just passing in two random extents that happen to be the same size but
not contain the same data (because deduplication _should_ reject such a
situation, that's what the clone ioctl is for).
The locking is perfectly reasonable and shouldn't contribute that much
to the overhead (unless you're being crazy and deduplicating thousands
of tiny blocks of data).
>
> That said, some optimization is possible (although there are good reasons
> not to bother with optimization in the kernel):
>
> - VFS could recognize when it has two separate references to
> the same physical extent and not re-read the same data twice
> (but that requires teaching VFS how to do CoW in general, and is
> hard for political reasons on top of the obvious technical ones).
>
> - the extent-same ioctl could check to see which extents
> are referenced by the src and dst ranges, and return success
> immediately without reading data if they are the same (but
> userspace should already know this, or it's wasting a huge amount
> of time before it even calls the kernel).
>
>> TBH, even though it's kind of annoying from a performance perspective, it's
>> a rather nice safety net to have. For example, one of the cases where I do
>> deduplication is a couple of directories where each directory is an
>> overlapping partial subset of one large tree which I keep elsewhere. In
>> this case, I can tell just by filename exactly what files might be
>> duplicates, so the ioctl's check lets me just call the ioctl on all
>> potential duplicates (after checking size, no point in wasting time if the
>> files obviously aren't duplicates), and have it figure out whether or not
>> they can be deduplicated.
>>>
>>> In any case, I'm considering some digging into the filesystem structures
>>> to see if I can work this out myself before i do any deduplication. I'm
>>> fairly sure this should be relatively simple to work out, at least well
>>> enough for my purposes.
>> Sadly, there's no way to avoid doing so right now.
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" 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
* Re: [PATCH] time: Avoid signed overflow in timekeeping_delta_to_ns()
From: John Stultz @ 2016-11-14 19:54 UTC (permalink / raw)
To: Chris Metcalf
Cc: Thomas Gleixner, Laurent Vivier, David Gibson,
Christopher S . Hall, lkml
In-Reply-To: <1479152569-16890-1-git-send-email-cmetcalf@mellanox.com>
On Mon, Nov 14, 2016 at 11:42 AM, Chris Metcalf <cmetcalf@mellanox.com> wrote:
> This bugfix was originally made in commit 35a4933a8959 ("time:
> Avoid signed overflow in timekeeping_get_ns()"). When the code was
> refactored in commit 6bd58f09e1d8 ("time: Add cycles to nanoseconds
> translation") the signed overflow fix was lost. Re-introduce it.
>
> Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
> ---
> I happened to be looking for an unrelated fix, found this code,
> realized the tip code didn't match the fixed code, and
> backtracked to where it had gone away.
>
> kernel/time/timekeeping.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 37dec7e3db43..57926bc7b7f3 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -304,8 +304,7 @@ static inline s64 timekeeping_delta_to_ns(struct tk_read_base *tkr,
> {
> s64 nsec;
>
> - nsec = delta * tkr->mult + tkr->xtime_nsec;
> - nsec >>= tkr->shift;
> + nsec = (delta * tkr->mult + tkr->xtime_nsec) >> tkr->shift;
Ugh.
So... I think this proves the original fix was *far* too subtle to
maintain. So I think reintroducing it as-is doesn't protect us from
undoing it. If the problem is really using the signed intermediate
nsec value, we should get rid of that.
thanks
-john
^ permalink raw reply
* Re: 6ea8c546f3655 breaks thermal management on thinkpad x60 and t40p
From: Rafael J. Wysocki @ 2016-11-14 19:54 UTC (permalink / raw)
To: Pavel Machek, Robert Moore
Cc: Pandruvada, Srinivas, acpi_power-processor, rankincj,
Srinivas Pandruvada, Len Brown, Lv, regressions,
linux-kernel@vger.kernel.org, Zhang, Rui,
linux-pm@vger.kernel.org, platform-driver-x86@vger.kernel.org,
rjw@rjwysocki.net, viresh.kumar@linaro.org,
ibm-acpi-devel@lists.sourceforge.net, ibm-acpi@hmh.eng.br,
linux-acpi@vger.kernel.org
In-Reply-To: <20161114190343.GB20770@amd>
On Mon, Nov 14, 2016 at 8:03 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> Bisection was not fun, but I've got the result:
>
> # first bad commit: [6ea8c546f3655a81f82672f24b66dad6095bdd07] ACPICA:
> FADT support cleanup
Bob?
> I've reverted the patch on top of 4.9-rc4, and thermal management now works.
>
> More details are in https://bugzilla.kernel.org/show_bug.cgi?id=187311
>
> As this breaks thermal management on both thinkpad X60 and T40p, can
> I ask for a revert?
>
> If you have other ideas, I can test them, but as this is just a
> cleanup, it can wait for 4.10...
Right.
Besides, we're in the -rc6 time frame now, so I'll queue up a revert.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH v2 0/3] i2c: octeon: thunder: Fix i2c not working on Octeon
From: Steven J. Hill @ 2016-11-14 19:53 UTC (permalink / raw)
To: Jan Glauber, Wolfram Sang; +Cc: linux-i2c, linux-mips, Paul Burton, David Daney
In-Reply-To: <1479149445-4663-1-git-send-email-jglauber@cavium.com>
On 11/14/2016 12:50 PM, Jan Glauber wrote:
>
> Since time is running out for 4.9 (or might have already if you're not
> going to send another pull request) I'm going for the safe option
> to fix the Octeon i2c problems, which is:
>
> 1. Reverting the readq_poll_timeout patch since it is broken
> 2. Apply Patch #2 from Paul
> 3. Add a small fix for the recovery that makes Paul's patch
> work on ThunderX
>
> I'll try to come up with a better solution for 4.10. My plan is to get rid
> of the polling-around-interrupt thing completely, but for that we need more
> time to make it work on Octeon.
>
> Please consider for 4.9.
>
Hey Jan.
This does not work on Octeon 71xx platforms. I will look at it more
closely tomorrow.
Steve
^ permalink raw reply
* Re: [PATCH v2 0/3] i2c: octeon: thunder: Fix i2c not working on Octeon
From: Steven J. Hill @ 2016-11-14 19:53 UTC (permalink / raw)
To: Jan Glauber, Wolfram Sang; +Cc: linux-i2c, linux-mips, Paul Burton, David Daney
In-Reply-To: <1479149445-4663-1-git-send-email-jglauber@cavium.com>
On 11/14/2016 12:50 PM, Jan Glauber wrote:
>
> Since time is running out for 4.9 (or might have already if you're not
> going to send another pull request) I'm going for the safe option
> to fix the Octeon i2c problems, which is:
>
> 1. Reverting the readq_poll_timeout patch since it is broken
> 2. Apply Patch #2 from Paul
> 3. Add a small fix for the recovery that makes Paul's patch
> work on ThunderX
>
> I'll try to come up with a better solution for 4.10. My plan is to get rid
> of the polling-around-interrupt thing completely, but for that we need more
> time to make it work on Octeon.
>
> Please consider for 4.9.
>
Hey Jan.
This does not work on Octeon 71xx platforms. I will look at it more
closely tomorrow.
Steve
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i: replace enable-sdio-wakeup with wakeup-source for BananaPi M1+
From: Maxime Ripard @ 2016-11-14 19:53 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1479138250-17780-4-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
On Mon, Nov 14, 2016 at 03:44:10PM +0000, Sudeep Holla wrote:
> Though the mmc core driver will continue to support the legacy
> "enable-sdio-wakeup" property to enable SDIO as the wakeup source,
> "wakeup-source" is the new standard binding.
>
> This patch replaces the legacy "enable-sdio-wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> Cc: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: replace enable-sdio-wakeup with wakeup-source for BananaPi M1+
From: Maxime Ripard @ 2016-11-14 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479138250-17780-4-git-send-email-sudeep.holla@arm.com>
On Mon, Nov 14, 2016 at 03:44:10PM +0000, Sudeep Holla wrote:
> Though the mmc core driver will continue to support the legacy
> "enable-sdio-wakeup" property to enable SDIO as the wakeup source,
> "wakeup-source" is the new standard binding.
>
> This patch replaces the legacy "enable-sdio-wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/a2450401/attachment.sig>
^ permalink raw reply
* Re: XFS_WANT_CORRUPTED_GOTO
From: Brian Foster @ 2016-11-14 19:53 UTC (permalink / raw)
To: Chris; +Cc: linux-xfs
In-Reply-To: <25b69ec53ba731ddd2f04d4e70341bdd.squirrel@mail2.postbox.xyz>
On Mon, Nov 14, 2016 at 07:39:03PM +0100, Chris wrote:
> Dear Brian,
>
> thank you for your detailed answer.
>
> Brian Foster wrote:
> > On Sat, Nov 12, 2016 at 11:52:02AM +0100, Chris wrote:
> >> I tried XFS-repair, but it couldn't find the first or second super block
> >> after four hours.
> >>
> >
> > That sounds like something more significant is going on either with the
> > fs, the storage or xfs_repair has been pointed in the wrong place. The
> > above issue should at worst require zeroing the log, dealing with the
> > resulting inconsistency and rebuilding the fs btrees accurately.
>
> Well, did it crash, because I called
>
> xfs_db -c "freespc -s" /dev/...
>
> while it was still in this unmount-loop?
>
I don't think that should affect anything. Not prevent repair from
finding superblocks, at least.
> > I suspect it's too late to inspect what's going on there if you have
> > already restored from backup. In the future, you can use xfs_metadump to
> > capture a metadata only image of a broken fs to share with us and help
> > us diagnose what might have gone wrong.
>
> OK.
>
> > I'd suggest to run "xfs_repair -n" on those as soon as possible to see
> > if they are affected by the same problem. It might also be a good idea
> > to run it against the fs you've restored from backup to see if it
> > returns and possibly get an idea on what might have caused the problem.
>
> On those filesystems, that aren't in use now, xfs_repair hasn't found any
> problems.
>
> Thanks again for your help. Next time, I'll do a metadump.
>
Sounds good.
Brian
> - Chris
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" 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
* Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Rob Herring @ 2016-11-14 19:52 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ramesh Shanmugasundaram, mark.rutland, mchehab, hverkuil,
sakari.ailus, crope, chris.paterson2, geert+renesas, linux-media,
devicetree, linux-renesas-soc
In-Reply-To: <2857106.83gIJRJqtY@avalon>
On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
> Hi Ramesh,
>
> Thank you for the patch.
>
> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> >
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and the
> > tuner device, which is registered as a sub-device, determines the receive
> > sample rate and format.
> >
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF acts
> > as a slave device and the tuner device acts as a master transmitting the
> > samples. The driver allows asynchronous binding of a tuner device that
> > is registered as a v4l2 sub-device. The driver can learn about the tuner
> > it is interfaced with based on port endpoint properties of the device in
> > device tree. The V4L2 SDR device inherits the controls exposed by the
> > tuner device.
> >
> > The device can also be configured to use either one or both of the data
> > pins at runtime based on the master (tuner) configuration.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > <ramesh.shanmugasundaram@bp.renesas.com> ---
> > .../devicetree/bindings/media/renesas,drif.txt | 136 ++
> > drivers/media/platform/Kconfig | 25 +
> > drivers/media/platform/Makefile | 1 +
> > drivers/media/platform/rcar_drif.c | 1574
> > ++++++++++++++++++++ 4 files changed, 1736 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
> > create mode 100644 drivers/media/platform/rcar_drif.c
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode
> > 100644
> > index 0000000..d65368a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,136 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +------------------------------------------------------------
> > +
> > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
> > +device as shown below
> > +
> > ++---------------------+ +---------------------+
> > +| |-----SCK------->|CLK |
> > +| Master |-----SS-------->|SYNC DRIFn (slave) |
> > +| |-----SD0------->|D0 |
> > +| |-----SD1------->|D1 |
> > ++---------------------+ +---------------------+
> > +
> > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 & drifn1).
> > +The sub-channels are like two individual channels in itself that share the
> > +common CLK & SYNC. Each sub-channel has it's own dedicated resources like
> > +irq, dma channels, address space & clock.
> > +
> > +The device tree model represents the channel and each of it's sub-channel
> > +as a separate node. The parent channel ties the sub-channels together with
> > +their phandles.
> > +
> > +Required properties of a sub-channel:
> > +-------------------------------------
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> > R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> > device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that sub-channel.
> > +- interrupts: associated with that sub-channel.
> > +- clocks: phandle and clock specifier of that sub-channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channel of that sub-channel.
> > +- dma-names: names of the DMA channel: "rx".
> > +
> > +Optional properties of a sub-channel:
> > +-------------------------------------
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of a channel:
> > +---------------------------------
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- sub-channels : phandles to the two sub-channels.
> > +
> > +Optional properties of a channel:
> > +---------------------------------
> > +- port: child port node of a channel that defines the local and remote
> > + endpoints. The remote endpoint is assumed to be a tuner subdevice
> > + endpoint.
> > +- renesas,syncmd : sync mode
> > + 0 (Frame start sync pulse mode. 1-bit width pulse
> > + indicates start of a frame)
> > + 1 (L/R sync or I2S mode) (default)
> > +- renesas,lsb-first : empty property indicates lsb bit is received
> > first.
> > + When not defined msb bit is received first (default)
>
> Shouldn't those two properties be instead queried from the tuner at runtime
> through the V4L2 subdev API ?
>
> > +- renesas,syncac-pol-high : empty property indicates sync signal polarity.
> > + When defined, active high or high->low sync signal.
> > + When not defined, active low or low->high sync signal
> > + (default)
>
> This could be queried too, except that an inverter could be present on the
> board, so it has to be specified in DT. I would however try to standardize it
> the same way that hsync-active and vsync-active are standardized in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
>
> > +- renesas,dtdl : delay between sync signal and start of reception.
>
> Are this and the next property meant to account for PCB traces delays ?
>
> > + Must contain one of the following values:
> > + 0 (no bit delay)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay) (default)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
>
> How about specifying the property in half clock cycle units, from 0 to 4 ?
>
> > +- renesas,syncdl : delay between end of reception and sync signal
> > edge.
> > + Must contain one of the following values:
> > + 0 (no bit delay) (default)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
> > + 300 (3-clock-cycle delay)
> > +
> > +Example
> > +--------
> > +
> > +SoC common dtsi file
> > +
> > + drif00: rif@e6f40000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f40000 0 0x64>;
> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 515>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
> > + dma-names = "rx", "rx";
rx, rx? That doesn't make sense. While we don't explicitly disallow
this, I'm thinking we should. I wonder if there's any case this is
valid. If not, then a dtc check for this could be added.
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif01: rif@e6f50000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f50000 0 0x64>;
> > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 514>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
> > + dma-names = "rx", "rx";
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif0: rif@0 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + sub-channels = <&drif00>, <&drif01>;
> > + status = "disabled";
> > + };
>
> I'm afraid this really hurts my eyes, especially using the same compatible
> string for both the channel and sub-channel nodes.
>
> We need to decide how to model the hardware in DT. Given that the two channels
> are mostly independent having separate DT nodes makes sense to me. However, as
> they share the clock and sync signals, somehow grouping them makes sense. I
> see three ways to do so, and there might be more.
>
> 1. Adding an extra DT node for the channels group, with phandles to the two
> channels. This is what you're proposing here.
>
> 2. Adding an extra DT node for the channels group, as a parent of the two
> channels.
>
> 3. Adding phandles to the channels, pointing to each other, or possibly a
> phandle from channel 0 pointing to channel 1.
>
> Neither of these options seem perfect to me. I don't like option 1 as the
> group DT node really doesn't describe a hardware block. If we want to use a DT
> node to convey group information, option 2 seems better to me. However, it
> somehow abuses the DT parent-child model that is supposed to describe
> relationships from a control bus point of view. Option 3 has the drawback of
> not scaling properly, at least with phandles in both channels pointing to the
> other one.
>
> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
> solve all those problems :-)
What's the purpose/need for grouping them?
I'm fine with Option 2, though I want to make sure it is really needed.
Rob
^ permalink raw reply
* Re: [PATCH 5/5] media: platform: rcar_drif: Add DRIF support
From: Rob Herring @ 2016-11-14 19:52 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ramesh Shanmugasundaram, mark.rutland-5wv7dgnIgG8,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA, crope-X3B1VOXEql0,
chris.paterson2-zM6kxYcvzFBBDgjK7y7TUQ,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2857106.83gIJRJqtY@avalon>
On Thu, Nov 10, 2016 at 11:22:20AM +0200, Laurent Pinchart wrote:
> Hi Ramesh,
>
> Thank you for the patch.
>
> On Wednesday 09 Nov 2016 15:44:44 Ramesh Shanmugasundaram wrote:
> > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 SoCs.
> > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF
> > device represents a channel and each channel can have one or two
> > sub-channels respectively depending on the target board.
> >
> > DRIF supports only Rx functionality. It receives samples from a RF
> > frontend tuner chip it is interfaced with. The combination of DRIF and the
> > tuner device, which is registered as a sub-device, determines the receive
> > sample rate and format.
> >
> > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with
> > the tuner device, which can be provided by a third party vendor. DRIF acts
> > as a slave device and the tuner device acts as a master transmitting the
> > samples. The driver allows asynchronous binding of a tuner device that
> > is registered as a v4l2 sub-device. The driver can learn about the tuner
> > it is interfaced with based on port endpoint properties of the device in
> > device tree. The V4L2 SDR device inherits the controls exposed by the
> > tuner device.
> >
> > The device can also be configured to use either one or both of the data
> > pins at runtime based on the master (tuner) configuration.
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > <ramesh.shanmugasundaram-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org> ---
> > .../devicetree/bindings/media/renesas,drif.txt | 136 ++
> > drivers/media/platform/Kconfig | 25 +
> > drivers/media/platform/Makefile | 1 +
> > drivers/media/platform/rcar_drif.c | 1574
> > ++++++++++++++++++++ 4 files changed, 1736 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
> > create mode 100644 drivers/media/platform/rcar_drif.c
> >
> > diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt
> > b/Documentation/devicetree/bindings/media/renesas,drif.txt new file mode
> > 100644
> > index 0000000..d65368a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > @@ -0,0 +1,136 @@
> > +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> > +------------------------------------------------------------
> > +
> > +R-Car Gen3 DRIF is a serial slave device. It interfaces with a master
> > +device as shown below
> > +
> > ++---------------------+ +---------------------+
> > +| |-----SCK------->|CLK |
> > +| Master |-----SS-------->|SYNC DRIFn (slave) |
> > +| |-----SD0------->|D0 |
> > +| |-----SD1------->|D1 |
> > ++---------------------+ +---------------------+
> > +
> > +Each DRIF channel (drifn) consists of two sub-channels (drifn0 & drifn1).
> > +The sub-channels are like two individual channels in itself that share the
> > +common CLK & SYNC. Each sub-channel has it's own dedicated resources like
> > +irq, dma channels, address space & clock.
> > +
> > +The device tree model represents the channel and each of it's sub-channel
> > +as a separate node. The parent channel ties the sub-channels together with
> > +their phandles.
> > +
> > +Required properties of a sub-channel:
> > +-------------------------------------
> > +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of
> > R8A7795 SoC.
> > + "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible
> > device.
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first
> > + followed by the generic version.
> > +- reg: offset and length of that sub-channel.
> > +- interrupts: associated with that sub-channel.
> > +- clocks: phandle and clock specifier of that sub-channel.
> > +- clock-names: clock input name string: "fck".
> > +- dmas: phandles to the DMA channel of that sub-channel.
> > +- dma-names: names of the DMA channel: "rx".
> > +
> > +Optional properties of a sub-channel:
> > +-------------------------------------
> > +- power-domains: phandle to the respective power domain.
> > +
> > +Required properties of a channel:
> > +---------------------------------
> > +- pinctrl-0: pin control group to be used for this channel.
> > +- pinctrl-names: must be "default".
> > +- sub-channels : phandles to the two sub-channels.
> > +
> > +Optional properties of a channel:
> > +---------------------------------
> > +- port: child port node of a channel that defines the local and remote
> > + endpoints. The remote endpoint is assumed to be a tuner subdevice
> > + endpoint.
> > +- renesas,syncmd : sync mode
> > + 0 (Frame start sync pulse mode. 1-bit width pulse
> > + indicates start of a frame)
> > + 1 (L/R sync or I2S mode) (default)
> > +- renesas,lsb-first : empty property indicates lsb bit is received
> > first.
> > + When not defined msb bit is received first (default)
>
> Shouldn't those two properties be instead queried from the tuner at runtime
> through the V4L2 subdev API ?
>
> > +- renesas,syncac-pol-high : empty property indicates sync signal polarity.
> > + When defined, active high or high->low sync signal.
> > + When not defined, active low or low->high sync signal
> > + (default)
>
> This could be queried too, except that an inverter could be present on the
> board, so it has to be specified in DT. I would however try to standardize it
> the same way that hsync-active and vsync-active are standardized in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
>
> > +- renesas,dtdl : delay between sync signal and start of reception.
>
> Are this and the next property meant to account for PCB traces delays ?
>
> > + Must contain one of the following values:
> > + 0 (no bit delay)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay) (default)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
>
> How about specifying the property in half clock cycle units, from 0 to 4 ?
>
> > +- renesas,syncdl : delay between end of reception and sync signal
> > edge.
> > + Must contain one of the following values:
> > + 0 (no bit delay) (default)
> > + 50 (0.5-clock-cycle delay)
> > + 100 (1-clock-cycle delay)
> > + 150 (1.5-clock-cycle delay)
> > + 200 (2-clock-cycle delay)
> > + 300 (3-clock-cycle delay)
> > +
> > +Example
> > +--------
> > +
> > +SoC common dtsi file
> > +
> > + drif00: rif@e6f40000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f40000 0 0x64>;
> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 515>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x20>, <&dmac2 0x20>;
> > + dma-names = "rx", "rx";
rx, rx? That doesn't make sense. While we don't explicitly disallow
this, I'm thinking we should. I wonder if there's any case this is
valid. If not, then a dtc check for this could be added.
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif01: rif@e6f50000 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + reg = <0 0xe6f50000 0 0x64>;
> > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 514>;
> > + clock-names = "fck";
> > + dmas = <&dmac1 0x22>, <&dmac2 0x22>;
> > + dma-names = "rx", "rx";
> > + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> > + status = "disabled";
> > + };
> > +
> > + drif0: rif@0 {
> > + compatible = "renesas,r8a7795-drif",
> > + "renesas,rcar-gen3-drif";
> > + sub-channels = <&drif00>, <&drif01>;
> > + status = "disabled";
> > + };
>
> I'm afraid this really hurts my eyes, especially using the same compatible
> string for both the channel and sub-channel nodes.
>
> We need to decide how to model the hardware in DT. Given that the two channels
> are mostly independent having separate DT nodes makes sense to me. However, as
> they share the clock and sync signals, somehow grouping them makes sense. I
> see three ways to do so, and there might be more.
>
> 1. Adding an extra DT node for the channels group, with phandles to the two
> channels. This is what you're proposing here.
>
> 2. Adding an extra DT node for the channels group, as a parent of the two
> channels.
>
> 3. Adding phandles to the channels, pointing to each other, or possibly a
> phandle from channel 0 pointing to channel 1.
>
> Neither of these options seem perfect to me. I don't like option 1 as the
> group DT node really doesn't describe a hardware block. If we want to use a DT
> node to convey group information, option 2 seems better to me. However, it
> somehow abuses the DT parent-child model that is supposed to describe
> relationships from a control bus point of view. Option 3 has the drawback of
> not scaling properly, at least with phandles in both channels pointing to the
> other one.
>
> Rob, Geert, tell me you have a fourth idea I haven't thought of that would
> solve all those problems :-)
What's the purpose/need for grouping them?
I'm fine with Option 2, though I want to make sure it is really needed.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.
From: Vivi, Rodrigo @ 2016-11-14 19:51 UTC (permalink / raw)
To: Deak, Imre; +Cc: Conselvan De Oliveira, Ander, intel-gfx@lists.freedesktop.org
In-Reply-To: <1478869753.1457.13.camel@intel.com>
On Fri, 2016-11-11 at 15:09 +0200, Imre Deak wrote:
> On to, 2016-11-10 at 17:03 -0800, Rodrigo Vivi wrote:
> > According to Bspec we need to
> > "Poll for PORT_REF_DW3_A grc_done == 1b"
> > only on ports B and C initialization sequence when
> > copying rcomp from port A.
> >
> > So let's follow the spec and only poll for that case
> > and not on every port A initialization.
> >
> > Cc: Imre Deak <imre.deak@intel.com>
> > Cc: Ander Conselvan de Oliveira
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> The current code isn't against the spec, we just wait for the
> calibration to complete earlier. This way we also wait in case only
> port A is enabled which is imo safer to do before a subsequent modeset
> on port A. But yes, the spec suggests the HW will handle the wait for
> this - only port A - case internally, so we can move the wait later to
> reduce somewhat the init time:
>
> Reviewed-by: Imre Deak <imre.deak@intel.com>
Ops, actually I noticed later that I need to remove the warning block
with return false from is_phy_enabled if grc isn't done. otherwise it
will force a reprograming without this line there.
So, do you believe it is worth to do a v2 removing that block or better
to just ignore this patch?
>
> > ---
> > drivers/gpu/drm/i915/intel_dpio_phy.c | 7 +++----
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > index 7a8e82d..277b1aa 100644
> > --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > @@ -367,6 +367,9 @@ static void _bxt_ddi_phy_init(struct drm_i915_private *dev_priv,
> >
> > if (phy_info->rcomp_phy != -1) {
> > uint32_t grc_code;
> > +
> > + bxt_phy_wait_grc_done(dev_priv, phy_info->rcomp_phy);
> > +
> > /*
> > * PHY0 isn't connected to an RCOMP resistor so copy over
> > * the corresponding calibrated value from PHY1, and disable
> > @@ -387,10 +390,6 @@ static void _bxt_ddi_phy_init(struct drm_i915_private *dev_priv,
> > val = I915_READ(BXT_PHY_CTL_FAMILY(phy));
> > val |= COMMON_RESET_DIS;
> > I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
> > -
> > - if (phy_info->rcomp_phy == -1)
> > - bxt_phy_wait_grc_done(dev_priv, phy);
> > -
> > }
> >
> > void bxt_ddi_phy_uninit(struct drm_i915_private *dev_priv, enum dpio_phy phy)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms
From: Junio C Hamano @ 2016-11-14 19:51 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Jacob Keller, Git mailing list
In-Reply-To: <CAOLa=ZSFuq2+6xsrJ=CcXuOVbTnbDirbRtu7Fonfk+9EdRpbxg@mail.gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
>> - More importantly, what do these do? I do not think of a good
>> description that generalizes "base of refs/foo/bar/boz is foo" to
>> explain your :base.
>
> $ ./git for-each-ref --format "%(refname)%(end) %(refname:dir)"
> refs/heads/master refs/heads
> refs/heads/ref-filter refs/heads
> refs/remotes/junio/va/i18n refs/remotes/junio/va
>
> $ ./git for-each-ref refs/heads --format
> "%(align:left,30)%(refname)%(end) %(refname:base)"
> refs/heads/master heads
> refs/heads/ref-filter heads
> refs/remotes/junio/va/i18n remotes
>
> I guess this should clear it up.
Hmph.
I would guess from these examples that :dir is an equivalent to
dirname(). But it is unclear how :base is defined. Is it the path
component that comes immediately after "refs/" that appears at the
beginning?
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Zygo Blaxell @ 2016-11-14 19:51 UTC (permalink / raw)
To: Austin S. Hemmelgarn; +Cc: James Pharaoh, Mark Fasheh, linux-btrfs
In-Reply-To: <dfb1372d-8bff-93ff-1ba7-d636e6c7fe4d@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]
On Mon, Nov 14, 2016 at 01:39:02PM -0500, Austin S. Hemmelgarn wrote:
> On 2016-11-14 13:22, James Pharaoh wrote:
> >One thing I am keen to understand is if BTRFS will automatically ignore
> >a request to deduplicate a file if it is already deduplicated? Given the
> >performance I see when doing a repeat deduplication, it seems to me that
> >it can't be doing so, although this could be caused by the CPU usage you
> >mention above.
> What's happening is that the dedupe ioctl does a byte-wise comparison of the
> ranges to make sure they're the same before linking them. This is actually
> what takes most of the time when calling the ioctl, and is part of why it
> takes longer the larger the range to deduplicate is. In essence, it's
> behaving like an OS should and not trusting userspace to make reasonable
> requests (which is also why there's a separate ioctl to clone a range from
> another file instead of deduplicating existing data).
Deduplicating an extent that may might be concurrently modified during the
dedup is a reasonable userspace request. In the general case there's
no way for userspace to ensure that it's not happening.
That said, some optimization is possible (although there are good reasons
not to bother with optimization in the kernel):
- VFS could recognize when it has two separate references to
the same physical extent and not re-read the same data twice
(but that requires teaching VFS how to do CoW in general, and is
hard for political reasons on top of the obvious technical ones).
- the extent-same ioctl could check to see which extents
are referenced by the src and dst ranges, and return success
immediately without reading data if they are the same (but
userspace should already know this, or it's wasting a huge amount
of time before it even calls the kernel).
> TBH, even though it's kind of annoying from a performance perspective, it's
> a rather nice safety net to have. For example, one of the cases where I do
> deduplication is a couple of directories where each directory is an
> overlapping partial subset of one large tree which I keep elsewhere. In
> this case, I can tell just by filename exactly what files might be
> duplicates, so the ioctl's check lets me just call the ioctl on all
> potential duplicates (after checking size, no point in wasting time if the
> files obviously aren't duplicates), and have it figure out whether or not
> they can be deduplicated.
> >
> >In any case, I'm considering some digging into the filesystem structures
> >to see if I can work this out myself before i do any deduplication. I'm
> >fairly sure this should be relatively simple to work out, at least well
> >enough for my purposes.
> Sadly, there's no way to avoid doing so right now.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [U-Boot] [RFC 1/1] image: Add TEE loading to FIT loadable processing
From: Andrew F. Davis @ 2016-11-14 19:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161114194925.17117-1-afd@ti.com>
To help automate the loading of a TEE image during the boot we add a new
FIT section type 'tee', when we see this type while loading the loadable
sections we automatically call the platforms TEE processing function on
this image section.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
Kconfig | 10 ++++++++++
common/image.c | 18 ++++++++++++++++++
include/image.h | 15 +++++++++++++++
3 files changed, 43 insertions(+)
diff --git a/Kconfig b/Kconfig
index 1263d0b..97cf7c8 100644
--- a/Kconfig
+++ b/Kconfig
@@ -291,6 +291,16 @@ config FIT_IMAGE_POST_PROCESS
injected into the FIT creation (i.e. the blobs would have been pre-
processed before being added to the FIT image).
+config FIT_IMAGE_TEE_PROCESS
+ bool "Enable processing of TEE images during FIT loading by U-Boot"
+ depends on FIT && TI_SECURE_DEVICE
+ help
+ Allows platforms to perform processing, such as authentication and
+ installation, on TEE images extracted from FIT images in a platform
+ or board specific way. In order to use this feature a platform or
+ board-specific implementation of board_tee_image_process() must be
+ provided.
+
config SPL_DFU_SUPPORT
bool "Enable SPL with DFU to load binaries to memory device"
depends on USB
diff --git a/common/image.c b/common/image.c
index 7604494..4552ca5 100644
--- a/common/image.c
+++ b/common/image.c
@@ -165,6 +165,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_ZYNQIMAGE, "zynqimage", "Xilinx Zynq Boot Image" },
{ IH_TYPE_ZYNQMPIMAGE, "zynqmpimage", "Xilinx ZynqMP Boot Image" },
{ IH_TYPE_FPGA, "fpga", "FPGA Image" },
+ { IH_TYPE_TEE, "tee", "TEE OS Image",},
{ -1, "", "", },
};
@@ -1408,6 +1409,8 @@ int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
int fit_img_result;
const char *uname;
+ uint8_t img_type;
+
/* Check to see if the images struct has a FIT configuration */
if (!genimg_has_config(images)) {
debug("## FIT configuration was not specified\n");
@@ -1447,6 +1450,21 @@ int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
/* Something went wrong! */
return fit_img_result;
}
+
+ fit_img_result = fit_image_get_node(buf, uname);
+ if (fit_img_result < 0) {
+ /* Something went wrong! */
+ return fit_img_result;
+ }
+ fit_img_result = fit_image_get_type(buf, fit_img_result, &img_type);
+ if (fit_img_result < 0) {
+ /* Something went wrong! */
+ return fit_img_result;
+ }
+#if defined(CONFIG_FIT_IMAGE_TEE_PROCESS)
+ if (img_type == IH_TYPE_TEE)
+ board_tee_image_process(img_data, img_len);
+#endif
}
break;
default:
diff --git a/include/image.h b/include/image.h
index 2b1296c..57084c8 100644
--- a/include/image.h
+++ b/include/image.h
@@ -279,6 +279,7 @@ enum {
IH_TYPE_ZYNQMPIMAGE, /* Xilinx ZynqMP Boot Image */
IH_TYPE_FPGA, /* FPGA Image */
IH_TYPE_VYBRIDIMAGE, /* VYBRID .vyb Image */
+ IH_TYPE_TEE, /* Trusted Execution Environment OS Image */
IH_TYPE_COUNT, /* Number of image types */
};
@@ -1263,4 +1264,18 @@ int board_fit_config_name_match(const char *name);
void board_fit_image_post_process(void **p_image, size_t *p_size);
#endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
+#ifdef CONFIG_FIT_IMAGE_TEE_PROCESS
+/**
+ * board_fit_tee_process() - Do any needed processing on a loaded TEE image
+ *
+ * This is used to verify, decrypt, and/or install a TEE in a platform or
+ * board specific way.
+ *
+ * @tee_image: pointer to the image
+ * @tee_size: the image size
+ * @return no return value (failure should be handled internally)
+ */
+void board_tee_image_process(void *tee_image, size_t tee_size);
+#endif /* CONFIG_FIT_IMAGE_TEE_PROCESS */
+
#endif /* __IMAGE_H__ */
--
2.10.1
^ permalink raw reply related
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.