* Re: [PATCH v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence
From: Wen Congyang @ 2012-12-30 5:49 UTC (permalink / raw)
To: Kamezawa Hiroyuki
Cc: Tang Chen, akpm, rientjes, liuj97, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, hpa,
linfeng, laijs, mgorman, yinghai, x86, linux-mm, linux-kernel,
linuxppc-dev, linux-acpi, linux-s390, linux-sh, linux-ia64,
cmetcalf, sparclinux
In-Reply-To: <50DA68A8.4060001@jp.fujitsu.com>
At 12/26/2012 11:02 AM, Kamezawa Hiroyuki Wrote:
> (2012/12/24 21:09), Tang Chen wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>>
>> memory can't be offlined when CONFIG_MEMCG is selected.
>> For example: there is a memory device on node 1. The address range
>> is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10,
>> and memory11 under the directory /sys/devices/system/memory/.
>>
>> If CONFIG_MEMCG is selected, we will allocate memory to store page cgroup
>> when we online pages. When we online memory8, the memory stored page cgroup
>> is not provided by this memory device. But when we online memory9, the memory
>> stored page cgroup may be provided by memory8. So we can't offline memory8
>> now. We should offline the memory in the reversed order.
>>
>
> If memory8 is onlined as NORMAL memory ...right ?
Yes, memory8 is onlined as NORMAL memory. And when we online memory9, we allocate
memory from memory8 to store page cgroup information.
>
> IIUC, vmalloc() uses __GFP_HIGHMEM but doesn't use __GFP_MOVABLE.
>
>> When the memory device is hotremoved, we will auto offline memory provided
>> by this memory device. But we don't know which memory is onlined first, so
>> offlining memory may fail. In such case, iterate twice to offline the memory.
>> 1st iterate: offline every non primary memory block.
>> 2nd iterate: offline primary (i.e. first added) memory block.
>>
>> This idea is suggested by KOSAKI Motohiro.
>>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>
> I'm not sure but the whole DIMM should be onlined as MOVABLE mem ?
If the whole DIMM is onlined as MOVABLE mem, we can offline it, and don't
retry again.
>
> Anyway, I agree this kind of retry is required if memory is onlined as NORMAL mem.
> But retry-once is ok ?
I'am not sure, but I think in most cases the user may online the memory according first
which is hot-added first. So we may always fail in the first time, and retry-once can
success.
Thanks
Wen Congyang
>
> Thanks,
> -Kame
>
>> ---
>> mm/memory_hotplug.c | 16 ++++++++++++++--
>> 1 files changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index d04ed87..62e04c9 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -1388,10 +1388,13 @@ int remove_memory(u64 start, u64 size)
>> unsigned long start_pfn, end_pfn;
>> unsigned long pfn, section_nr;
>> int ret;
>> + int return_on_error = 0;
>> + int retry = 0;
>>
>> start_pfn = PFN_DOWN(start);
>> end_pfn = start_pfn + PFN_DOWN(size);
>>
>> +repeat:
>> for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
>> section_nr = pfn_to_section_nr(pfn);
>> if (!present_section_nr(section_nr))
>> @@ -1410,14 +1413,23 @@ int remove_memory(u64 start, u64 size)
>>
>> ret = offline_memory_block(mem);
>> if (ret) {
>> - kobject_put(&mem->dev.kobj);
>> - return ret;
>> + if (return_on_error) {
>> + kobject_put(&mem->dev.kobj);
>> + return ret;
>> + } else {
>> + retry = 1;
>> + }
>> }
>> }
>>
>> if (mem)
>> kobject_put(&mem->dev.kobj);
>>
>> + if (retry) {
>> + return_on_error = 1;
>> + goto repeat;
>> + }
>> +
>> return 0;
>> }
>> #else
>>
>
>
>
^ permalink raw reply
* Re: [PATCH v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence
From: Wen Congyang @ 2012-12-30 5:49 UTC (permalink / raw)
To: Kamezawa Hiroyuki
Cc: Tang Chen, akpm, rientjes, liuj97, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, hpa,
linfeng, laijs, mgorman, yinghai, x86, linux-mm, linux-kernel,
linuxppc-dev, linux-acpi, linux-s390, linux-sh, linux-ia64,
cmetcalf, sparclinux
In-Reply-To: <50DA68A8.4060001@jp.fujitsu.com>
At 12/26/2012 11:02 AM, Kamezawa Hiroyuki Wrote:
> (2012/12/24 21:09), Tang Chen wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>>
>> memory can't be offlined when CONFIG_MEMCG is selected.
>> For example: there is a memory device on node 1. The address range
>> is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10,
>> and memory11 under the directory /sys/devices/system/memory/.
>>
>> If CONFIG_MEMCG is selected, we will allocate memory to store page cgroup
>> when we online pages. When we online memory8, the memory stored page cgroup
>> is not provided by this memory device. But when we online memory9, the memory
>> stored page cgroup may be provided by memory8. So we can't offline memory8
>> now. We should offline the memory in the reversed order.
>>
>
> If memory8 is onlined as NORMAL memory ...right ?
Yes, memory8 is onlined as NORMAL memory. And when we online memory9, we allocate
memory from memory8 to store page cgroup information.
>
> IIUC, vmalloc() uses __GFP_HIGHMEM but doesn't use __GFP_MOVABLE.
>
>> When the memory device is hotremoved, we will auto offline memory provided
>> by this memory device. But we don't know which memory is onlined first, so
>> offlining memory may fail. In such case, iterate twice to offline the memory.
>> 1st iterate: offline every non primary memory block.
>> 2nd iterate: offline primary (i.e. first added) memory block.
>>
>> This idea is suggested by KOSAKI Motohiro.
>>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>
> I'm not sure but the whole DIMM should be onlined as MOVABLE mem ?
If the whole DIMM is onlined as MOVABLE mem, we can offline it, and don't
retry again.
>
> Anyway, I agree this kind of retry is required if memory is onlined as NORMAL mem.
> But retry-once is ok ?
I'am not sure, but I think in most cases the user may online the memory according first
which is hot-added first. So we may always fail in the first time, and retry-once can
success.
Thanks
Wen Congyang
>
> Thanks,
> -Kame
>
>> ---
>> mm/memory_hotplug.c | 16 ++++++++++++++--
>> 1 files changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index d04ed87..62e04c9 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -1388,10 +1388,13 @@ int remove_memory(u64 start, u64 size)
>> unsigned long start_pfn, end_pfn;
>> unsigned long pfn, section_nr;
>> int ret;
>> + int return_on_error = 0;
>> + int retry = 0;
>>
>> start_pfn = PFN_DOWN(start);
>> end_pfn = start_pfn + PFN_DOWN(size);
>>
>> +repeat:
>> for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
>> section_nr = pfn_to_section_nr(pfn);
>> if (!present_section_nr(section_nr))
>> @@ -1410,14 +1413,23 @@ int remove_memory(u64 start, u64 size)
>>
>> ret = offline_memory_block(mem);
>> if (ret) {
>> - kobject_put(&mem->dev.kobj);
>> - return ret;
>> + if (return_on_error) {
>> + kobject_put(&mem->dev.kobj);
>> + return ret;
>> + } else {
>> + retry = 1;
>> + }
>> }
>> }
>>
>> if (mem)
>> kobject_put(&mem->dev.kobj);
>>
>> + if (retry) {
>> + return_on_error = 1;
>> + goto repeat;
>> + }
>> +
>> return 0;
>> }
>> #else
>>
>
>
>
--
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 v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence
From: Wen Congyang @ 2012-12-30 5:49 UTC (permalink / raw)
To: Kamezawa Hiroyuki
Cc: Tang Chen, akpm, rientjes, liuj97, len.brown, benh, paulus, cl,
minchan.kim, kosaki.motohiro, isimatu.yasuaki, wujianguo, hpa,
linfeng, laijs, mgorman, yinghai, x86, linux-mm, linux-kernel,
linuxppc-dev, linux-acpi, linux-s390, linux-sh, linux-ia64,
cmetcalf, sparclinux
In-Reply-To: <50DA68A8.4060001@jp.fujitsu.com>
At 12/26/2012 11:02 AM, Kamezawa Hiroyuki Wrote:
> (2012/12/24 21:09), Tang Chen wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>>
>> memory can't be offlined when CONFIG_MEMCG is selected.
>> For example: there is a memory device on node 1. The address range
>> is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10,
>> and memory11 under the directory /sys/devices/system/memory/.
>>
>> If CONFIG_MEMCG is selected, we will allocate memory to store page cgroup
>> when we online pages. When we online memory8, the memory stored page cgroup
>> is not provided by this memory device. But when we online memory9, the memory
>> stored page cgroup may be provided by memory8. So we can't offline memory8
>> now. We should offline the memory in the reversed order.
>>
>
> If memory8 is onlined as NORMAL memory ...right ?
Yes, memory8 is onlined as NORMAL memory. And when we online memory9, we allocate
memory from memory8 to store page cgroup information.
>
> IIUC, vmalloc() uses __GFP_HIGHMEM but doesn't use __GFP_MOVABLE.
>
>> When the memory device is hotremoved, we will auto offline memory provided
>> by this memory device. But we don't know which memory is onlined first, so
>> offlining memory may fail. In such case, iterate twice to offline the memory.
>> 1st iterate: offline every non primary memory block.
>> 2nd iterate: offline primary (i.e. first added) memory block.
>>
>> This idea is suggested by KOSAKI Motohiro.
>>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>
> I'm not sure but the whole DIMM should be onlined as MOVABLE mem ?
If the whole DIMM is onlined as MOVABLE mem, we can offline it, and don't
retry again.
>
> Anyway, I agree this kind of retry is required if memory is onlined as NORMAL mem.
> But retry-once is ok ?
I'am not sure, but I think in most cases the user may online the memory according first
which is hot-added first. So we may always fail in the first time, and retry-once can
success.
Thanks
Wen Congyang
>
> Thanks,
> -Kame
>
>> ---
>> mm/memory_hotplug.c | 16 ++++++++++++++--
>> 1 files changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index d04ed87..62e04c9 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -1388,10 +1388,13 @@ int remove_memory(u64 start, u64 size)
>> unsigned long start_pfn, end_pfn;
>> unsigned long pfn, section_nr;
>> int ret;
>> + int return_on_error = 0;
>> + int retry = 0;
>>
>> start_pfn = PFN_DOWN(start);
>> end_pfn = start_pfn + PFN_DOWN(size);
>>
>> +repeat:
>> for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
>> section_nr = pfn_to_section_nr(pfn);
>> if (!present_section_nr(section_nr))
>> @@ -1410,14 +1413,23 @@ int remove_memory(u64 start, u64 size)
>>
>> ret = offline_memory_block(mem);
>> if (ret) {
>> - kobject_put(&mem->dev.kobj);
>> - return ret;
>> + if (return_on_error) {
>> + kobject_put(&mem->dev.kobj);
>> + return ret;
>> + } else {
>> + retry = 1;
>> + }
>> }
>> }
>>
>> if (mem)
>> kobject_put(&mem->dev.kobj);
>>
>> + if (retry) {
>> + return_on_error = 1;
>> + goto repeat;
>> + }
>> +
>> return 0;
>> }
>> #else
>>
>
>
>
^ permalink raw reply
* Re: [PATCH v5 01/14] memory-hotplug: try to offline the memory twice to avoid dependence
From: Wen Congyang @ 2012-12-30 5:49 UTC (permalink / raw)
To: Kamezawa Hiroyuki
Cc: linux-ia64, linux-sh, Tang Chen, linux-mm, paulus, hpa,
sparclinux, cl, linux-s390, x86, linux-acpi, isimatu.yasuaki,
linfeng, mgorman, kosaki.motohiro, rientjes, liuj97, len.brown,
cmetcalf, wujianguo, yinghai, laijs, linux-kernel, minchan.kim,
akpm, linuxppc-dev
In-Reply-To: <50DA68A8.4060001@jp.fujitsu.com>
At 12/26/2012 11:02 AM, Kamezawa Hiroyuki Wrote:
> (2012/12/24 21:09), Tang Chen wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>>
>> memory can't be offlined when CONFIG_MEMCG is selected.
>> For example: there is a memory device on node 1. The address range
>> is [1G, 1.5G). You will find 4 new directories memory8, memory9, memory10,
>> and memory11 under the directory /sys/devices/system/memory/.
>>
>> If CONFIG_MEMCG is selected, we will allocate memory to store page cgroup
>> when we online pages. When we online memory8, the memory stored page cgroup
>> is not provided by this memory device. But when we online memory9, the memory
>> stored page cgroup may be provided by memory8. So we can't offline memory8
>> now. We should offline the memory in the reversed order.
>>
>
> If memory8 is onlined as NORMAL memory ...right ?
Yes, memory8 is onlined as NORMAL memory. And when we online memory9, we allocate
memory from memory8 to store page cgroup information.
>
> IIUC, vmalloc() uses __GFP_HIGHMEM but doesn't use __GFP_MOVABLE.
>
>> When the memory device is hotremoved, we will auto offline memory provided
>> by this memory device. But we don't know which memory is onlined first, so
>> offlining memory may fail. In such case, iterate twice to offline the memory.
>> 1st iterate: offline every non primary memory block.
>> 2nd iterate: offline primary (i.e. first added) memory block.
>>
>> This idea is suggested by KOSAKI Motohiro.
>>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>
> I'm not sure but the whole DIMM should be onlined as MOVABLE mem ?
If the whole DIMM is onlined as MOVABLE mem, we can offline it, and don't
retry again.
>
> Anyway, I agree this kind of retry is required if memory is onlined as NORMAL mem.
> But retry-once is ok ?
I'am not sure, but I think in most cases the user may online the memory according first
which is hot-added first. So we may always fail in the first time, and retry-once can
success.
Thanks
Wen Congyang
>
> Thanks,
> -Kame
>
>> ---
>> mm/memory_hotplug.c | 16 ++++++++++++++--
>> 1 files changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index d04ed87..62e04c9 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -1388,10 +1388,13 @@ int remove_memory(u64 start, u64 size)
>> unsigned long start_pfn, end_pfn;
>> unsigned long pfn, section_nr;
>> int ret;
>> + int return_on_error = 0;
>> + int retry = 0;
>>
>> start_pfn = PFN_DOWN(start);
>> end_pfn = start_pfn + PFN_DOWN(size);
>>
>> +repeat:
>> for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
>> section_nr = pfn_to_section_nr(pfn);
>> if (!present_section_nr(section_nr))
>> @@ -1410,14 +1413,23 @@ int remove_memory(u64 start, u64 size)
>>
>> ret = offline_memory_block(mem);
>> if (ret) {
>> - kobject_put(&mem->dev.kobj);
>> - return ret;
>> + if (return_on_error) {
>> + kobject_put(&mem->dev.kobj);
>> + return ret;
>> + } else {
>> + retry = 1;
>> + }
>> }
>> }
>>
>> if (mem)
>> kobject_put(&mem->dev.kobj);
>>
>> + if (retry) {
>> + return_on_error = 1;
>> + goto repeat;
>> + }
>> +
>> return 0;
>> }
>> #else
>>
>
>
>
^ permalink raw reply
* Re: PROBLEM: Random kernel panic & system freeze when watching video
From: Hillf Danton @ 2012-12-30 5:41 UTC (permalink / raw)
To: Du Jiulun; +Cc: linux-kernel
In-Reply-To: <CAHfmSg3ug=64vXtsA4EA6xdKaqWRtT7qZW9AG8n92Q+pbDgQEQ@mail.gmail.com>
On Sun, Dec 30, 2012 at 1:45 AM, Du Jiulun <dujiulun@gmail.com> wrote:
> I'm experiencing random (but frequent) kernel panics and system
> freezes without panic information while I'm watching videos using
> SMPlayer or Google Chrome (with Flash plugin).
>
Is it triggered only when watching video?
> [4.] Kernel version (from /proc/version):
>
> Linux version 3.6.10-1-ck (xiaodu@xiaodupc) (gcc version 4.7.2 (GCC) )
> #1 SMP PREEMPT Wed Dec 12 15:26:26 CST 2012
>
(btw, are you playing BFS?)
Can you please try the latest stable kernel?
Hillf
^ permalink raw reply
* Re: kernel panic on resume from S3 - stumped
From: Tim Hockin @ 2012-12-30 5:34 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-kernel, Pavel Machek, Linux PM list
In-Reply-To: <22263901.MJnoQmEgLn@vostro.rjw.lan>
Running a suspend with pm_trace set, I get:
aer 0000:00:03.0:pcie02: hash matches
I don't know what magic might be needed here, though.
I guess next step is to try to build a non-distro kernel.
On Sat, Dec 29, 2012 at 1:57 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Saturday, December 29, 2012 12:03:13 PM Tim Hockin wrote:
>> 4 days ago I had Ubuntu Lucid running on this computer. Suspend and
>> resume worked flawlessly every time.
>>
>> Then I upgraded to Ubuntu Precise.
>
> Well, do you use a distro kernel or a kernel.org kernel?
>
>> Suspend seems to work, but resume
>> fails every time. The video never initializes. By the flashing
>> keyboard lights, I guess it's a kernel panic. It fails from the Live
>> CD and from a fresh install.
>>
>> Here is my debug so far.
>>
>> Install all updates (3.2 kernel, nouveau driver)
>> Reboot
>> Try suspend = fails
>>
>> Install Ubuntu's linux-generic-lts-quantal (3.5 kernel, nouveau driver)
>> Reboot
>> Try suspend = fails
>>
>> Install nVidia's 304 driver
>> Reboot
>> Try suspend = fails
>>
>> From within X:
>> echo core > /sys/power/pm_test
>> echo mem > /sys/power/state
>> The system acts like it is going to sleep, and then wakes up a few
>> seconds later. dmesg shows:
>>
>> [ 1230.083404] ------------[ cut here ]------------
>> [ 1230.083410] WARNING: at
>> /build/buildd/linux-lts-quantal-3.5.0/kernel/power/suspend_test.c:53
>> suspend_test_finish+0x86/0x90()
>> [ 1230.083411] Hardware name: To Be Filled By O.E.M.
>> [ 1230.083412] Component: resume devices, time: 14424
>> [ 1230.083412] Modules linked in: snd_emu10k1_synth snd_emux_synth
>> snd_seq_virmidi snd_seq_midi_emul bnep rfcomm parport_pc ppdev
>> nvidia(PO) snd_emu10k1 snd_ac97_codec ac97_bus snd_pcm snd_page_alloc
>> snd_util_mem snd_hwdep snd_seq_midi snd_rawmidi snd_seq_midi_event
>> snd_seq snd_timer coretemp snd_seq_device kvm_intel kvm snd
>> ghash_clmulni_intel soundcore aesni_intel btusb cryptd aes_x86_64
>> bluetooth i7core_edac edac_core microcode mac_hid lpc_ich mxm_wmi
>> shpchp serio_raw wmi hid_generic lp parport usbhid hid r8169
>> pata_marvell
>> [ 1230.083445] Pid: 3329, comm: bash Tainted: P O 3.5.0-21-generic
>> #32~precise1-Ubuntu
>> [ 1230.083446] Call Trace:
>> [ 1230.083448] [<ffffffff81052c9f>] warn_slowpath_common+0x7f/0xc0
>> [ 1230.083452] [<ffffffff81052d96>] warn_slowpath_fmt+0x46/0x50
>> [ 1230.083455] [<ffffffff8109b836>] suspend_test_finish+0x86/0x90
>> [ 1230.083457] [<ffffffff8109b53b>] suspend_devices_and_enter+0x10b/0x200
>> [ 1230.083460] [<ffffffff8109b701>] enter_state+0xd1/0x100
>> [ 1230.083463] [<ffffffff8109b74b>] pm_suspend+0x1b/0x60
>> [ 1230.083465] [<ffffffff8109a7a5>] state_store+0x45/0x70
>> [ 1230.083467] [<ffffffff81331d2f>] kobj_attr_store+0xf/0x30
>> [ 1230.083471] [<ffffffff811f77ff>] sysfs_write_file+0xef/0x170
>> [ 1230.083476] [<ffffffff811879d3>] vfs_write+0xb3/0x180
>> [ 1230.083480] [<ffffffff81187cfa>] sys_write+0x4a/0x90
>> [ 1230.083483] [<ffffffff816a6e69>] system_call_fastpath+0x16/0x1b
>> [ 1230.083488] ---[ end trace 839cdd0078b3ce03 ]---
>>
>> Boot with init=/bin/bash
>> unload all modules except USBHID
>> echo core > /sys/power/pm_test
>> echo mem > /sys/power/state
>> system acts like it is going to sleep, and then wakes up a few seconds later
>> echo none > /sys/power/pm_test
>> echo mem > /sys/power/state
>> system goes to sleep
>> press power to resume = fails
>>
>> At this point I am stumped on how to debug. This is a "modern"
>> computer with no serial ports. It worked under Lucid, so I know it is
>> POSSIBLE.
>>
>> Mobo: ASRock X58 single-socket
>> CPU: Westmere 6 core (12 hyperthreads) 3.2 GHz
>> RAM: 12 GB ECC
>> Disk: sda = Intel SSD, mounted on /
>> Disk: sdb = Intel SSD, not mounted
>> Disk: sdc = Seagate HDD, not mounted
>> Disk: sdd = Seagate HDD, not mounted
>> NIC = Onboard RTL8168e/8111e
>> Sound = EMU1212 (emu10k1, not even configured yet)
>> Video = nVidia GeForce 7600 GT
>> KB = PS2 (also tried USB)
>> Mouse = USB
>>
>> I have not updated to a more current kernel than 3.5, but I will if
>> there's evidence that this is resolved. Any other clever trick to
>> try?
>
> There is no evidence and there won't be if you don't try a newer kernel.
>
> Thanks,
> Rafael
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH 1/2] ARM: dts: prevent *.dtb from always being rebuilt
From: Olof Johansson @ 2012-12-30 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356741767-29292-1-git-send-email-swarren@wwwdotorg.org>
On Fri, Dec 28, 2012 at 05:42:46PM -0700, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> if_changed (used by the *.dts->*.dtc rule) rebuilds files if they aren't
> contained in $(targets). (make V=2 indicates this). Add $(dtb-y) to
> $(targets) to prevent *.dtb from always being rebuilt.
>
> This fixes a regression introduced by the .dtb rule rework in 499cd82
> "ARM: dt: change .dtb build rules to build in dts directory".
>
> Reported-by: Shawn Guo <shawn.guo@linaro.org>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Not sure who you have in mind to apply this, but if it's not through arm-soc:
Acked-by: Olof Johansson <olof@lixom.net>
-Olof
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: prevent *.dtb from always being rebuilt
From: Olof Johansson @ 2012-12-30 5:32 UTC (permalink / raw)
To: Stephen Warren
Cc: Russell King, Catalin Marinas, Will Deacon, Grant Likely,
Rob Herring, Shawn Guo, linux-arm-kernel, linux-kernel,
Stephen Warren
In-Reply-To: <1356741767-29292-1-git-send-email-swarren@wwwdotorg.org>
On Fri, Dec 28, 2012 at 05:42:46PM -0700, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> if_changed (used by the *.dts->*.dtc rule) rebuilds files if they aren't
> contained in $(targets). (make V=2 indicates this). Add $(dtb-y) to
> $(targets) to prevent *.dtb from always being rebuilt.
>
> This fixes a regression introduced by the .dtb rule rework in 499cd82
> "ARM: dt: change .dtb build rules to build in dts directory".
>
> Reported-by: Shawn Guo <shawn.guo@linaro.org>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Not sure who you have in mind to apply this, but if it's not through arm-soc:
Acked-by: Olof Johansson <olof@lixom.net>
-Olof
^ permalink raw reply
* [PATCH v5 00/12] clk: exynos4: migrate to common clock framework
From: Olof Johansson @ 2012-12-30 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356827621-27617-1-git-send-email-thomas.abraham@linaro.org>
On Sat, Dec 29, 2012 at 04:33:29PM -0800, Thomas Abraham wrote:
> Changes since v4:
> - Rebased to linux-3.8-rc1.
>
> Changes since v3:
> - Includes changes suggested by Tomasz Figa <tomasz.figa@gmail.com>
>
> This patch series migrates the Samsung Exynos4 SoC clock code to adopt the
> common clock framework. The use of Samsung specific clock structures has
> been removed and all board support code has been updated. imx-style of
> clock registration and lookup has been adopted for device tree based
> exynos4 platforms.
I'd prefer to see if exynos4 and 5 were kept common here, and both transitioned
at the same time. Especially since there are no legacy boards for exynos5, it
would mean you could have a very clean transition there. What's the plan to
follow up with 5?
What are the plans to remove legacy board files on exynos4 at this time
and switch them to DT-only? You could do it gradually like Stephen Warren
did on Tegra, with hooks that call out to some of the legacy code, but
configure the board through device tree and do away with the classic
machine descriptors, etc.
-Olof
^ permalink raw reply
* Re: [PATCH v5 00/12] clk: exynos4: migrate to common clock framework
From: Olof Johansson @ 2012-12-30 5:29 UTC (permalink / raw)
To: Thomas Abraham
Cc: linux-arm-kernel, linux-samsung-soc, devicetree-discuss,
mturquette, kgene.kim, t.figa, sylvester.nawrocki
In-Reply-To: <1356827621-27617-1-git-send-email-thomas.abraham@linaro.org>
On Sat, Dec 29, 2012 at 04:33:29PM -0800, Thomas Abraham wrote:
> Changes since v4:
> - Rebased to linux-3.8-rc1.
>
> Changes since v3:
> - Includes changes suggested by Tomasz Figa <tomasz.figa@gmail.com>
>
> This patch series migrates the Samsung Exynos4 SoC clock code to adopt the
> common clock framework. The use of Samsung specific clock structures has
> been removed and all board support code has been updated. imx-style of
> clock registration and lookup has been adopted for device tree based
> exynos4 platforms.
I'd prefer to see if exynos4 and 5 were kept common here, and both transitioned
at the same time. Especially since there are no legacy boards for exynos5, it
would mean you could have a very clean transition there. What's the plan to
follow up with 5?
What are the plans to remove legacy board files on exynos4 at this time
and switch them to DT-only? You could do it gradually like Stephen Warren
did on Tegra, with hooks that call out to some of the legacy code, but
configure the board through device tree and do away with the classic
machine descriptors, etc.
-Olof
^ permalink raw reply
* Port of iMX5's Xorg driver to newer Xorg API
From: Otavio Salvador @ 2012-12-30 5:27 UTC (permalink / raw)
To: meta-freescale@yoctoproject.org
[-- Attachment #1: Type: text/plain, Size: 783 bytes --]
Hello,
I know this holidays time is supposed to us to rest and relax but as a
true hacking addicted I was suffering of hacking abstinence (no
hacking since before Christimas) so I ended looking at the port of
iMX5's Xorg driver to the newer Xorg's video API.
I didn't bring the boards with me to the beach (or my family would
kill me) so I cannot test the patch myself and I'd like to know if
anyone is suffering of same abstinence effect as me and could give it
a try? :-)
The patch is attached to this e-mail if anyone wish to give it a try :-)
Happy New Year :-)
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
[-- Attachment #2: 0001-xf86-video-imxfb-Port-to-newer-Xorg-video-API.patch --]
[-- Type: application/octet-stream, Size: 33274 bytes --]
From ac25073362ccd05074ef04622023ef2619b2f939 Mon Sep 17 00:00:00 2001
From: Otavio Salvador <otavio@ossystems.com.br>
Date: Sun, 30 Dec 2012 03:21:34 -0200
Subject: [PATCH] xf86-video-imxfb: Port to newer Xorg video API
The new Xorg uses a newer video API thus requiring the drivers to be
ported to them; we use the "compat-api.h" header for forward and
backward compatibility makeing it easy for upstream acceptance.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
...video-API-forward-and-backward-compatible.patch | 787 ++++++++++++++++++++
.../ext-Update-to-newer-swap-macros.patch | 65 ++
.../xorg-driver/xf86-video-imxfb_11.09.01.bb | 7 +-
3 files changed, 857 insertions(+), 2 deletions(-)
create mode 100644 recipes-graphics/xorg-driver/xf86-video-imxfb/Make-video-API-forward-and-backward-compatible.patch
create mode 100644 recipes-graphics/xorg-driver/xf86-video-imxfb/ext-Update-to-newer-swap-macros.patch
diff --git a/recipes-graphics/xorg-driver/xf86-video-imxfb/Make-video-API-forward-and-backward-compatible.patch b/recipes-graphics/xorg-driver/xf86-video-imxfb/Make-video-API-forward-and-backward-compatible.patch
new file mode 100644
index 0000000..acfda91
--- /dev/null
+++ b/recipes-graphics/xorg-driver/xf86-video-imxfb/Make-video-API-forward-and-backward-compatible.patch
@@ -0,0 +1,787 @@
+From 5216cb0f14414b5451f58df48a36c1c62c035276 Mon Sep 17 00:00:00 2001
+From: Otavio Salvador <otavio@ossystems.com.br>
+Date: Sat, 29 Dec 2012 18:02:11 -0200
+Subject: [PATCH] Make video API forward and backward compatible
+
+This updates the video API in a forward and backward compatible way
+using the "compat-api.h" as used in Xorg maintained drivers.
+
+Upstream-Status: Pending
+
+Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
+---
+ src/compat-api.h | 106 +++++++++++++++++++++++++++++++++++++++++++++++
+ src/imx_display.c | 22 +++++-----
+ src/imx_display.h | 8 ++--
+ src/imx_driver.c | 60 ++++++++++++++-------------
+ src/imx_exa_offscreen.c | 12 +++---
+ src/imx_exa_z160.c | 53 ++++++++++++------------
+ src/imx_xv_ipu.c | 4 +-
+ 7 files changed, 188 insertions(+), 77 deletions(-)
+ create mode 100644 src/compat-api.h
+
+diff --git a/src/compat-api.h b/src/compat-api.h
+new file mode 100644
+index 0000000..73ac8a2
+--- /dev/null
++++ b/src/compat-api.h
+@@ -0,0 +1,106 @@
++/*
++ * Copyright 2012 Red Hat, Inc.
++ *
++ * Permission is hereby granted, free of charge, to any person obtaining a
++ * copy of this software and associated documentation files (the "Software"),
++ * to deal in the Software without restriction, including without limitation
++ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
++ * and/or sell copies of the Software, and to permit persons to whom the
++ * Software is furnished to do so, subject to the following conditions:
++ *
++ * The above copyright notice and this permission notice (including the next
++ * paragraph) shall be included in all copies or substantial portions of the
++ * Software.
++ *
++ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
++ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
++ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
++ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
++ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
++ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
++ * DEALINGS IN THE SOFTWARE.
++ *
++ * Author: Dave Airlie <airlied@redhat.com>
++ */
++
++/* this file provides API compat between server post 1.13 and pre it,
++ it should be reused inside as many drivers as possible */
++#ifndef COMPAT_API_H
++#define COMPAT_API_H
++
++#ifndef GLYPH_HAS_GLYPH_PICTURE_ACCESSOR
++#define GetGlyphPicture(g, s) GlyphPicture((g))[(s)->myNum]
++#define SetGlyphPicture(g, s, p) GlyphPicture((g))[(s)->myNum] = p
++#endif
++
++#ifndef XF86_HAS_SCRN_CONV
++#define xf86ScreenToScrn(s) xf86Screens[(s)->myNum]
++#define xf86ScrnToScreen(s) screenInfo.screens[(s)->scrnIndex]
++#endif
++
++#ifndef XF86_SCRN_INTERFACE
++
++#define SCRN_ARG_TYPE int
++#define SCRN_INFO_PTR(arg1) ScrnInfoPtr pScrn = xf86Screens[(arg1)]
++
++#define SCREEN_ARG_TYPE int
++#define SCREEN_PTR(arg1) ScreenPtr pScreen = screenInfo.screens[(arg1)]
++
++#define SCREEN_INIT_ARGS_DECL int index, ScreenPtr pScreen, int argc, char **argv
++
++#define BLOCKHANDLER_ARGS_DECL int arg, pointer blockData, pointer pTimeout, pointer pReadmask
++#define BLOCKHANDLER_ARGS arg, blockData, pTimeout, pReadmask
++
++#define CLOSE_SCREEN_ARGS_DECL int scrnIndex, ScreenPtr pScreen
++#define CLOSE_SCREEN_ARGS scrnIndex, pScreen
++#define CLOSE_SCREEN_DECL_ScrnInfoPtr ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
++
++#define FBDEVHWADJUSTFRAME_ARGS(x, y) scrnIndex, (x), (y), 0
++
++#define ADJUST_FRAME_ARGS_DECL int arg, int x, int y, int flags
++
++#define SWITCH_MODE_ARGS_DECL int arg, DisplayModePtr mode, int flags
++
++#define FREE_SCREEN_ARGS_DECL int arg, int flags
++#define FREE_SCREEN_ARGS(x) (x)->scrnIndex, 0
++
++#define VT_FUNC_ARGS_DECL int arg, int flags
++#define VT_FUNC_ARGS(flags) pScrn->scrnIndex, (flags)
++
++#define ENABLE_DISABLE_FB_ACCESS_ARGS(pScrn, b) pScrn->scrnIndex, b
++
++#define XF86_ENABLEDISABLEFB_ARG(x) ((x)->scrnIndex)
++#else
++#define SCRN_ARG_TYPE ScrnInfoPtr
++#define SCRN_INFO_PTR(arg1) ScrnInfoPtr pScrn = (arg1)
++
++#define SCREEN_ARG_TYPE ScreenPtr
++#define SCREEN_PTR(arg1) ScreenPtr pScreen = (arg1)
++
++#define SCREEN_INIT_ARGS_DECL ScreenPtr pScreen, int argc, char **argv
++
++#define BLOCKHANDLER_ARGS_DECL ScreenPtr arg, pointer pTimeout, pointer pReadmask
++#define BLOCKHANDLER_ARGS arg, pTimeout, pReadmask
++
++#define CLOSE_SCREEN_ARGS_DECL ScreenPtr pScreen
++#define CLOSE_SCREEN_ARGS pScreen
++#define CLOSE_SCREEN_DECL_ScrnInfoPtr ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++
++#define FBDEVHWADJUSTFRAME_ARGS(x, y) pScrn, (x), (y)
++
++#define ADJUST_FRAME_ARGS_DECL ScrnInfoPtr arg, int x, int y
++#define SWITCH_MODE_ARGS_DECL ScrnInfoPtr arg, DisplayModePtr mode
++
++#define FREE_SCREEN_ARGS_DECL ScrnInfoPtr arg
++#define FREE_SCREEN_ARGS(x) (x)
++
++#define VT_FUNC_ARGS_DECL ScrnInfoPtr arg
++#define VT_FUNC_ARGS(flags) pScrn
++
++#define ENABLE_DISABLE_FB_ACCESS_ARGS(pScrn, b) pScrn, b
++
++#define XF86_ENABLEDISABLEFB_ARG(x) (x)
++
++#endif
++
++#endif
+diff --git a/src/imx_display.c b/src/imx_display.c
+index fcb8195..e2dc36a 100644
+--- a/src/imx_display.c
++++ b/src/imx_display.c
+@@ -42,6 +42,8 @@
+ #include "imx.h"
+ #include "imx_display.h"
+
++#include "compat-api.h"
++
+ #include <X11/Xatom.h>
+
+ #if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(1,7,6,0,0)
+@@ -1373,19 +1375,19 @@ imxDisplayPreInit(ScrnInfoPtr pScrn)
+ Bool
+ imxDisplayStartScreenInit(int scrnIndex, ScreenPtr pScreen)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+ ImxPtr fPtr = IMXPTR(pScrn);
+
+ if (!xf86SetDesiredModes(pScrn)) {
+
+- xf86DrvMsg(scrnIndex, X_ERROR, "mode initialization failed\n");
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "mode initialization failed\n");
+ return FALSE;
+ }
+
+ #if 0
+ if (!fbdevHWModeInit(pScrn, pScrn->currentMode)) {
+
+- xf86DrvMsg(scrnIndex, X_ERROR, "mode initialization failed\n");
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "mode initialization failed\n");
+ return FALSE;
+ }
+ pScrn->displayWidth =
+@@ -1463,29 +1465,29 @@ imxDisplayFinishScreenInit(int scrnIndex, ScreenPtr pScreen)
+ /* -------------------------------------------------------------------- */
+
+ Bool
+-imxDisplaySwitchMode(int scrnIndex, DisplayModePtr mode, int flags)
++imxDisplaySwitchMode(SWITCH_MODE_ARGS_DECL)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
++ SCRN_INFO_PTR(arg);
+
+ return xf86SetSingleMode(pScrn, mode, RR_Rotate_0);
+ }
+
+ void
+-imxDisplayAdjustFrame(int scrnIndex, int x, int y, int flags)
++imxDisplayAdjustFrame(ADJUST_FRAME_ARGS_DECL)
+ {
+-// fbdevHWAdjustFrame(scrnIndex, x, y, flags);
++// fbdevHWAdjustFrame(pScrn->scrnIndex, x, y, flags);
+ }
+
+ Bool
+-imxDisplayEnterVT(int scrnIndex, int flags)
++imxDisplayEnterVT(VT_FUNC_ARGS_DECL)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
++ SCRN_INFO_PTR(arg);
+
+ return xf86SetDesiredModes(pScrn);
+ }
+
+ void
+-imxDisplayLeaveVT(int scrnIndex, int flags)
++imxDisplayLeaveVT(VT_FUNC_ARGS_DECL)
+ {
+ }
+
+diff --git a/src/imx_display.h b/src/imx_display.h
+index 4a5d5aa..3a3d43a 100644
+--- a/src/imx_display.h
++++ b/src/imx_display.h
+@@ -59,16 +59,16 @@ imxDisplayValidMode(int scrnIndex, DisplayModePtr mode,
+ Bool verbose, int flags);
+
+ extern Bool
+-imxDisplaySwitchMode(int scrnIndex, DisplayModePtr mode, int flags);
++imxDisplaySwitchMode(SWITCH_MODE_ARGS_DECL);
+
+ extern void
+-imxDisplayAdjustFrame(int scrnIndex, int x, int y, int flags);
++imxDisplayAdjustFrame(ADJUST_FRAME_ARGS_DECL);
+
+ extern Bool
+-imxDisplayEnterVT(int scrnIndex, int flags);
++imxDisplayEnterVT(VT_FUNC_ARGS_DECL);
+
+ extern void
+-imxDisplayLeaveVT(int scrnIndex, int flags);
++imxDisplayLeaveVT(VT_FUNC_ARGS_DECL);
+
+ extern Bool
+ imxDisplayChangeFrameBufferRotateEPDC(int scrnIndex, int fbRotate);
+diff --git a/src/imx_driver.c b/src/imx_driver.c
+index 178e36e..f4b3e38 100644
+--- a/src/imx_driver.c
++++ b/src/imx_driver.c
+@@ -46,6 +46,8 @@
+ #include "fb.h"
+ #include "fbdevhw.h"
+
++#include "compat-api.h"
++
+ #if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 6
+ #include "xf86Resources.h"
+ #include "xf86RAC.h"
+@@ -435,17 +437,17 @@ errorPreInit:
+ }
+
+ static void
+-imxFreeScreen(int scrnIndex, int flags)
++imxFreeScreen(FREE_SCREEN_ARGS_DECL)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
++ SCRN_INFO_PTR(arg);
+
+ imxFreeRec(pScrn);
+ }
+
+ static Bool
+-imxCloseScreen(int scrnIndex, ScreenPtr pScreen)
++imxCloseScreen(CLOSE_SCREEN_ARGS_DECL)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
++ CLOSE_SCREEN_DECL_ScrnInfoPtr;
+ ImxPtr fPtr = IMXPTR(pScrn);
+
+ fbdevHWRestore(pScrn);
+@@ -453,7 +455,7 @@ imxCloseScreen(int scrnIndex, ScreenPtr pScreen)
+ pScrn->vtSema = FALSE;
+
+ pScreen->CloseScreen = fPtr->saveCloseScreen;
+- return (*pScreen->CloseScreen)(scrnIndex, pScreen);
++ return (*pScreen->CloseScreen)(CLOSE_SCREEN_ARGS);
+ }
+
+ static int
+@@ -488,9 +490,9 @@ LCM(a, b)
+ }
+
+ static Bool
+-imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
++imxScreenInit(SCREEN_INIT_ARGS_DECL)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ SCRN_INFO_PTR(pScreen);
+ ImxPtr fPtr = IMXPTR(pScrn);
+ VisualPtr visual;
+ int init_picture = 0;
+@@ -514,7 +516,7 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ /* Map frame buffer memory */
+ fPtr->fbMemoryBase = fbdevHWMapVidmem(pScrn);
+ if (NULL == fPtr->fbMemoryBase) {
+- xf86DrvMsg(scrnIndex,X_ERROR,"mapping of video memory"
++ xf86DrvMsg(pScrn->scrnIndex,X_ERROR,"mapping of video memory"
+ " failed\n");
+ return FALSE;
+ }
+@@ -558,7 +560,7 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ const int fbOffsetScreen2 =
+ IMX_ALIGN(fbMaxScreenSize, fbMaxAlignOffset);
+ fPtr->fbMemoryScreenReserve = fbMaxScreenSize;
+- xf86DrvMsg(scrnIndex, X_INFO,
++ xf86DrvMsg(pScrn->scrnIndex, X_INFO,
+ "reserve %d bytes of frame buffer for screen\n",
+ fPtr->fbMemoryScreenReserve);
+ fPtr->fbMemoryStart2 = NULL;
+@@ -568,12 +570,12 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+
+ fPtr->fbMemoryScreenReserve += fbOffsetScreen2;
+
+- xf86DrvMsg(scrnIndex, X_INFO,
++ xf86DrvMsg(pScrn->scrnIndex, X_INFO,
+ "reserve same number of bytes for XRandR rotated screen at offset %d\n",
+ fbOffsetScreen2);
+ }
+
+- if (!imxDisplayStartScreenInit(scrnIndex, pScreen)) {
++ if (!imxDisplayStartScreenInit(pScrn->scrnIndex, pScreen)) {
+
+ return FALSE;
+ }
+@@ -582,7 +584,7 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ miClearVisualTypes();
+ if (pScrn->bitsPerPixel > 8) {
+ if (!miSetVisualTypes(pScrn->depth, TrueColorMask, pScrn->rgbBits, TrueColor)) {
+- xf86DrvMsg(scrnIndex,X_ERROR,"visual type setup failed"
++ xf86DrvMsg(pScrn->scrnIndex,X_ERROR,"visual type setup failed"
+ " for %d bits per pixel [1]\n",
+ pScrn->bitsPerPixel);
+ return FALSE;
+@@ -591,14 +593,14 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ if (!miSetVisualTypes(pScrn->depth,
+ miGetDefaultVisualMask(pScrn->depth),
+ pScrn->rgbBits, pScrn->defaultVisual)) {
+- xf86DrvMsg(scrnIndex,X_ERROR,"visual type setup failed"
++ xf86DrvMsg(pScrn->scrnIndex,X_ERROR,"visual type setup failed"
+ " for %d bits per pixel [2]\n",
+ pScrn->bitsPerPixel);
+ return FALSE;
+ }
+ }
+ if (!miSetPixmapDepths()) {
+- xf86DrvMsg(scrnIndex,X_ERROR,"pixmap depth setup failed\n");
++ xf86DrvMsg(pScrn->scrnIndex,X_ERROR,"pixmap depth setup failed\n");
+ return FALSE;
+ }
+
+@@ -607,10 +609,10 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ has a padding which is independent from the depth (controlfb) */
+ pScrn->displayWidth = fbdevHWGetLineLength(pScrn) /
+ (pScrn->bitsPerPixel / 8);
+- xf86DrvMsg(scrnIndex, X_INFO, "displayWidth = %d\n", pScrn->displayWidth);
++ xf86DrvMsg(pScrn->scrnIndex, X_INFO, "displayWidth = %d\n", pScrn->displayWidth);
+
+ if (pScrn->displayWidth != pScrn->virtualX) {
+- xf86DrvMsg(scrnIndex, X_INFO,
++ xf86DrvMsg(pScrn->scrnIndex, X_INFO,
+ "Pitch updated to %d after ModeInit\n",
+ pScrn->displayWidth);
+ }
+@@ -633,7 +635,7 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ init_picture = 1;
+ break;
+ default:
+- xf86DrvMsg(scrnIndex, X_ERROR,
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "internal error: invalid number of bits per"
+ " pixel (%d) encountered in"
+ " imxScreenInit()\n", pScrn->bitsPerPixel);
+@@ -644,7 +646,7 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ case FBDEVHW_INTERLEAVED_PLANES:
+ /* This should never happen ...
+ * we should check for this much much earlier ... */
+- xf86DrvMsg(scrnIndex, X_ERROR,
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "internal error: interleaved planes are not yet "
+ "supported by the imx driver\n");
+ ret = FALSE;
+@@ -652,20 +654,20 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ case FBDEVHW_TEXT:
+ /* This should never happen ...
+ * we should check for this much much earlier ... */
+- xf86DrvMsg(scrnIndex, X_ERROR,
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "internal error: text mode is not supported by the "
+ "imx driver\n");
+ ret = FALSE;
+ break;
+ case FBDEVHW_VGA_PLANES:
+ /* Not supported yet */
+- xf86DrvMsg(scrnIndex, X_ERROR,
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "internal error: EGA/VGA Planes are not yet "
+ "supported by the imx driver\n");
+ ret = FALSE;
+ break;
+ default:
+- xf86DrvMsg(scrnIndex, X_ERROR,
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "internal error: unrecognised hardware type (%d) "
+ "encountered in imxScreenInit()\n", type);
+ ret = FALSE;
+@@ -699,7 +701,7 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ /* INIT ACCELERATION BEFORE INIT FOR BACKING STORE & SOFTWARE CURSOR */
+ if (fPtr->useAccel) {
+
+- if (!imxExaZ160Setup(scrnIndex, pScreen)) {
++ if (!imxExaZ160Setup(pScrn->scrnIndex, pScreen)) {
+
+ fPtr->useAccel = FALSE;
+ }
+@@ -731,29 +733,29 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ /* XXX It would be simpler to use miCreateDefColormap() in all cases. */
+ case FBDEVHW_PACKED_PIXELS:
+ if (!miCreateDefColormap(pScreen)) {
+- xf86DrvMsg(scrnIndex, X_ERROR,
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "internal error: miCreateDefColormap failed "
+ "in imxScreenInit()\n");
+ return FALSE;
+ }
+ break;
+ case FBDEVHW_INTERLEAVED_PLANES:
+- xf86DrvMsg(scrnIndex, X_ERROR,
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "internal error: interleaved planes are not yet "
+ "supported by the imx driver\n");
+ return FALSE;
+ case FBDEVHW_TEXT:
+- xf86DrvMsg(scrnIndex, X_ERROR,
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "internal error: text mode is not supported by "
+ "the imx driver\n");
+ return FALSE;
+ case FBDEVHW_VGA_PLANES:
+- xf86DrvMsg(scrnIndex, X_ERROR,
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "internal error: EGA/VGA planes are not yet "
+ "supported by the imx driver\n");
+ return FALSE;
+ default:
+- xf86DrvMsg(scrnIndex, X_ERROR,
++ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "internal error: unrecognised imx hardware type "
+ "(%d) encountered in imxScreenInit()\n", type);
+ return FALSE;
+@@ -782,7 +784,7 @@ imxScreenInit(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
+ }
+ #endif
+
+- if (!imxDisplayFinishScreenInit(scrnIndex, pScreen)) {
++ if (!imxDisplayFinishScreenInit(pScrn->scrnIndex, pScreen)) {
+ return FALSE;
+ }
+
+@@ -810,7 +812,7 @@ IMXGetPixmapProperties(
+ }
+
+ /* Access screen associated with this pixmap. */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmap->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmap->drawable.pScreen);
+
+ /* Check if the screen associated with this pixmap has IMX driver. */
+ if (0 != strcmp(IMX_DRIVER_NAME, pScrn->driverName)) {
+diff --git a/src/imx_exa_offscreen.c b/src/imx_exa_offscreen.c
+index 3a5c24d..0fbe2fc 100644
+--- a/src/imx_exa_offscreen.c
++++ b/src/imx_exa_offscreen.c
+@@ -79,7 +79,7 @@ static void
+ imxExaOffscreenValidate (ScreenPtr pScreen)
+ {
+ /* Access the driver specific data. */
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+ ImxPtr imxPtr = IMXPTR(pScrn);
+ ImxExaPtr imxExaPtr = IMXEXAPTR(imxPtr);
+ ExaOffscreenArea *prev = 0, *area;
+@@ -135,7 +135,7 @@ imxExaOffscreenMerge (ImxExaPtr imxExaPtr, ExaOffscreenArea *area)
+ ExaOffscreenArea *
+ imxExaOffscreenFree (ScreenPtr pScreen, ExaOffscreenArea *area)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+ ImxPtr imxPtr = IMXPTR(pScrn);
+ ImxExaPtr imxExaPtr = IMXEXAPTR(imxPtr);
+ ExaOffscreenArea *next = area->next;
+@@ -281,7 +281,7 @@ imxExaOffscreenAlloc (ScreenPtr pScreen, int size, int align,
+ pointer privData)
+ {
+ ExaOffscreenArea *area;
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+ ImxPtr imxPtr = IMXPTR(pScrn);
+ ImxExaPtr imxExaPtr = IMXEXAPTR(imxPtr);
+ int real_size = 0, largest_avail = 0;
+@@ -418,7 +418,7 @@ imxExaOffscreenSwapIn (ScreenPtr pScreen)
+ Bool
+ imxExaOffscreenInit (ScreenPtr pScreen)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+ ImxPtr imxPtr = IMXPTR(pScrn);
+ ImxExaPtr imxExaPtr = IMXEXAPTR(imxPtr);
+ ExaOffscreenArea *area;
+@@ -453,7 +453,7 @@ imxExaOffscreenInit (ScreenPtr pScreen)
+ void
+ imxExaOffscreenFini (ScreenPtr pScreen)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+ ImxPtr imxPtr = IMXPTR(pScrn);
+ ImxExaPtr imxExaPtr = IMXEXAPTR(imxPtr);
+ ExaOffscreenArea *area;
+@@ -472,7 +472,7 @@ imxExaOffscreenFini (ScreenPtr pScreen)
+ void
+ imxExaOffscreenSwapOut (ScreenPtr pScreen)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+ ImxPtr imxPtr = IMXPTR(pScrn);
+ ImxExaPtr imxExaPtr = IMXEXAPTR(imxPtr);
+
+diff --git a/src/imx_exa_z160.c b/src/imx_exa_z160.c
+index fb718e0..3d0bc96 100644
+--- a/src/imx_exa_z160.c
++++ b/src/imx_exa_z160.c
+@@ -32,6 +32,7 @@
+ #include <errno.h>
+ #include <fcntl.h>
+
++#include "compat-api.h"
+
+ /* Set if handles pixmap allocation and migration, i.e, EXA_HANDLES_PIXMAPS */
+ #define IMX_EXA_ENABLE_HANDLES_PIXMAPS \
+@@ -299,7 +300,7 @@ imxExaZ160GetPixmapAddress(PixmapPtr pPixmap)
+ return fPixmapPtr->ptr;
+ #else
+ /* Access screen associated with this pixmap. */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmap->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmap->drawable.pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -344,7 +345,7 @@ imxExaZ160GetPixmapProperties(
+ #else
+
+ /* Access screen associated with this pixmap. */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmap->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmap->drawable.pScreen);
+
+ /* Make sure pixmap is in framebuffer */
+ if (!exaDrawableIsOffscreen(&(pPixmap->drawable))) {
+@@ -856,7 +857,7 @@ imxExaZ160SyncIfBusyPixmap(PixmapPtr pPixmap)
+ {
+ /* Access screen associated with this pixmap. */
+ ScreenPtr pScreen = pPixmap->drawable.pScreen;
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+
+ /* Access driver specific data for screen. */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -924,7 +925,7 @@ imxExaZ160CreatePixmap2(ScreenPtr pScreen, int width, int height,
+ }
+
+ /* Access the driver specific data. */
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+ ImxPtr imxPtr = IMXPTR(pScrn);
+ ImxExaZ160Ptr fPtr = IMXEXAZ160PTR(imxPtr);
+
+@@ -1028,7 +1029,7 @@ imxExaZ160DestroyPixmap(ScreenPtr pScreen, void *driverPriv)
+ ImxExaPixmapPtr fPixmapPtr = (ImxExaPixmapPtr)driverPriv;
+
+ /* Access the driver specific data. */
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+ ImxPtr imxPtr = IMXPTR(pScrn);
+ ImxExaZ160Ptr fPtr = IMXEXAZ160PTR(imxPtr);
+
+@@ -1068,7 +1069,7 @@ imxExaZ160ModifyPixmapHeader(PixmapPtr pPixmap, int width, int height,
+ }
+
+ /* Access screen associated with this pixmap */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmap->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmap->drawable.pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -1194,7 +1195,7 @@ imxExaZ160TrackBusyPixmap(ImxExaZ160Ptr fPtr, PixmapPtr pPixmap)
+ static void
+ imxExaZ160WaitMarker(ScreenPtr pScreen, int marker)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+
+ /* Access driver specific data associated with the screen. */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -1249,7 +1250,7 @@ imxExaZ160PrepareSolid(PixmapPtr pPixmap, int alu, Pixel planemask, Pixel fg)
+ }
+
+ /* Access screen associated with this pixmap */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmap->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmap->drawable.pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -1352,7 +1353,7 @@ static void
+ imxExaZ160Solid(PixmapPtr pPixmap, int x1, int y1, int x2, int y2)
+ {
+ /* Access screen associated with this pixmap */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmap->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmap->drawable.pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -1423,7 +1424,7 @@ static void
+ imxExaZ160DoneSolid(PixmapPtr pPixmap)
+ {
+ /* Access screen associated with this pixmap */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmap->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmap->drawable.pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -1485,7 +1486,7 @@ imxExaZ160PrepareCopy(
+ }
+
+ /* Access the screen associated with this pixmap. */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmapDst->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmapDst->drawable.pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -1599,7 +1600,7 @@ static void
+ imxExaZ160Copy(PixmapPtr pPixmapDst, int srcX, int srcY, int dstX, int dstY, int width, int height)
+ {
+ /* Access screen associated with dst pixmap */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmapDst->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmapDst->drawable.pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -1661,7 +1662,7 @@ static void
+ imxExaZ160DoneCopy(PixmapPtr pPixmapDst)
+ {
+ /* Access screen associated with this pixmap */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmapDst->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmapDst->drawable.pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -1770,7 +1771,7 @@ imxExaZ160CheckComposite(int op, PicturePtr pPictureSrc, PicturePtr pPictureMask
+ }
+
+ /* Access screen associated with dst pixmap (same screen as for src pixmap). */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmapDst->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmapDst->drawable.pScreen);
+
+ /* Check the number of entities, and fail if it isn't one. */
+ if (pScrn->numEntities != 1) {
+@@ -1987,7 +1988,7 @@ imxExaZ160PrepareComposite(
+ {
+ /* Access screen associated with dst pixmap. */
+ /* Should be same screen as for src pixmap. */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmapDst->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmapDst->drawable.pScreen);
+
+ /* NOTE - many preconditions already verified in CheckComposite. */
+
+@@ -2196,7 +2197,7 @@ imxExaZ160Composite(
+ int height)
+ {
+ /* Access screen associated with dst pixmap */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmapDst->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmapDst->drawable.pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -2275,7 +2276,7 @@ static void
+ imxExaZ160DoneComposite(PixmapPtr pPixmapDst)
+ {
+ /* Access screen associated with this pixmap */
+- ScrnInfoPtr pScrn = xf86Screens[pPixmapDst->drawable.pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pPixmapDst->drawable.pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -2323,7 +2324,7 @@ imxExaZ160UploadToScreen(
+
+ /* Access screen associated with this pixmap */
+ ScreenPtr pScreen = pPixmapDst->drawable.pScreen;
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -2381,7 +2382,7 @@ imxExaZ160DownloadFromScreen(
+
+ /* Access screen associated with this pixmap */
+ ScreenPtr pScreen = pPixmapSrc->drawable.pScreen;
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+
+ /* Access driver specific data */
+ ImxPtr imxPtr = IMXPTR(pScrn);
+@@ -2412,9 +2413,9 @@ imxExaZ160DownloadFromScreen(
+ }
+
+ Bool
+-imxExaZ160CloseScreen(int scrnIndex, ScreenPtr pScreen)
++imxExaZ160CloseScreen(CLOSE_SCREEN_ARGS_DECL)
+ {
+- ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
++ CLOSE_SCREEN_DECL_ScrnInfoPtr;
+ ImxPtr imxPtr = IMXPTR(pScrn);
+
+ ImxExaZ160Ptr fPtr = IMXEXAZ160PTR(imxPtr);
+@@ -2504,7 +2505,7 @@ imxExaZ160CloseScreen(int scrnIndex, ScreenPtr pScreen)
+ /* Install our CloseScreen function so that it gets called. */
+ if (NULL != pScreen->CloseScreen) {
+
+- return (*pScreen->CloseScreen)(scrnIndex, pScreen);
++ return (*pScreen->CloseScreen)(CLOSE_SCREEN_ARGS);
+ }
+
+ return TRUE;
+@@ -2514,7 +2515,7 @@ Bool
+ imxExaZ160Setup(int scrnIndex, ScreenPtr pScreen)
+ {
+ /* Access the screen info and then private data structures. */
+- ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
++ ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen);
+ ImxPtr imxPtr = IMXPTR(pScrn);
+
+ /* Private data structure must not already be in use. */
+@@ -2582,7 +2583,7 @@ imxExaZ160Setup(int scrnIndex, ScreenPtr pScreen)
+
+ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "Initialize Z160 interfaces failed.\n");
+- imxExaZ160CloseScreen(scrnIndex, pScreen);
++ imxExaZ160CloseScreen(CLOSE_SCREEN_ARGS);
+ return FALSE;
+ }
+
+@@ -2592,7 +2593,7 @@ imxExaZ160Setup(int scrnIndex, ScreenPtr pScreen)
+
+ xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
+ "Allocate EXA driver structure.\n");
+- imxExaZ160CloseScreen(scrnIndex, pScreen);
++ imxExaZ160CloseScreen(CLOSE_SCREEN_ARGS);
+ return FALSE;
+ }
+
+@@ -2657,7 +2658,7 @@ imxExaZ160Setup(int scrnIndex, ScreenPtr pScreen)
+ if (!exaDriverInit(pScreen, exaDriverPtr)) {
+
+ xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "EXA initialization failed.\n");
+- imxExaZ160CloseScreen(scrnIndex, pScreen);
++ imxExaZ160CloseScreen(CLOSE_SCREEN_ARGS);
+ return FALSE;
+ }
+ fPtr->imxExaRec.exaDriverPtr = exaDriverPtr;
+diff --git a/src/imx_xv_ipu.c b/src/imx_xv_ipu.c
+index a517742..fc8a827 100644
+--- a/src/imx_xv_ipu.c
++++ b/src/imx_xv_ipu.c
+@@ -398,7 +398,7 @@ xf86XVFillKeyHelper1 (ScreenPtr pScreen, CARD32 key, RegionPtr clipboxes)
+ xRectangle *rects;
+ GCPtr gc;
+
+- if(!xf86Screens[pScreen->myNum]->vtSema) return;
++ if(!xf86ScreenToScrn(pScreen)->vtSema) return;
+
+ gc = GetScratchGC(root->depth, pScreen);
+ pval[0] = key;
+@@ -771,7 +771,7 @@ MXXVInitializeAdaptor
+ XF86VideoAdaptorPtr **pppAdaptor
+ )
+ {
+- ScreenPtr pScreen = screenInfo.screens[pScreenInfo->scrnIndex];
++ ScreenPtr pScreen = xf86ScrnToScreen(pScreenInfo);
+ XF86VideoAdaptorPtr *ppAdaptor = NULL;
+ IMXPtr fPtr = IMXPTR(pScreenInfo);
+ int nAdaptor;
+--
+1.7.10.4
+
diff --git a/recipes-graphics/xorg-driver/xf86-video-imxfb/ext-Update-to-newer-swap-macros.patch b/recipes-graphics/xorg-driver/xf86-video-imxfb/ext-Update-to-newer-swap-macros.patch
new file mode 100644
index 0000000..05be6b3
--- /dev/null
+++ b/recipes-graphics/xorg-driver/xf86-video-imxfb/ext-Update-to-newer-swap-macros.patch
@@ -0,0 +1,65 @@
+From fc7f191a1a0f290a4e808dd8f9bd58ba1dbd2be4 Mon Sep 17 00:00:00 2001
+From: Otavio Salvador <otavio@ossystems.com.br>
+Date: Sat, 29 Dec 2012 18:00:36 -0200
+Subject: [PATCH 1/2] ext: Update to newer swap macros
+
+The swap macros now use an internal temporary variable so we need to
+adapt the code according.
+
+Upstream-Status: Pending
+
+Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
+---
+ src/imx_ext.c | 16 ++++++----------
+ 1 file changed, 6 insertions(+), 10 deletions(-)
+
+diff --git a/src/imx_ext.c b/src/imx_ext.c
+index f12469a..710cba4 100644
+--- a/src/imx_ext.c
++++ b/src/imx_ext.c
+@@ -57,8 +57,6 @@ void imxExtInit()
+ static int
+ Proc_IMX_EXT_GetPixmapPhysAddr(ClientPtr client)
+ {
+- int n;
+-
+ REQUEST(xIMX_EXT_GetPixmapPhysAddrReq);
+ REQUEST_SIZE_MATCH(xIMX_EXT_GetPixmapPhysAddrReq);
+
+@@ -96,10 +94,10 @@ Proc_IMX_EXT_GetPixmapPhysAddr(ClientPtr client)
+ /* Check if any reply values need byte swapping */
+ if (client->swapped) {
+
+- swaps(&rep.sequenceNumber, n);
+- swapl(&rep.length, n);
+- swapl(&rep.pixmapPhysAddr, n);
+- swapl(&rep.pixmapPitch, n);
++ swaps(&rep.sequenceNumber);
++ swapl(&rep.length);
++ swapl(&rep.pixmapPhysAddr);
++ swapl(&rep.pixmapPitch);
+ }
+
+ /* Reply to client */
+@@ -123,16 +121,14 @@ Proc_IMX_EXT_Dispatch(ClientPtr client)
+ static int
+ SProc_IMX_EXT_GetPixmapPhysAddr(ClientPtr client)
+ {
+- int n;
+-
+ REQUEST(xIMX_EXT_GetPixmapPhysAddrReq);
+
+ /* Swap request message length and verify it is correct. */
+- swaps(&stuff->length, n);
++ swaps(&stuff->length);
+ REQUEST_SIZE_MATCH(xIMX_EXT_GetPixmapPhysAddrReq);
+
+ /* Swap remaining request message parameters. */
+- swapl(&stuff->pixmap, n);
++ swapl(&stuff->pixmap);
+
+ return Proc_IMX_EXT_GetPixmapPhysAddr(client);
+ }
+--
+1.7.10.4
+
diff --git a/recipes-graphics/xorg-driver/xf86-video-imxfb_11.09.01.bb b/recipes-graphics/xorg-driver/xf86-video-imxfb_11.09.01.bb
index 22143a8..668641b 100644
--- a/recipes-graphics/xorg-driver/xf86-video-imxfb_11.09.01.bb
+++ b/recipes-graphics/xorg-driver/xf86-video-imxfb_11.09.01.bb
@@ -6,10 +6,13 @@ LICENSE = "MIT-X"
DEPENDS = "virtual/xserver virtual/libx11 xproto randrproto util-macros amd-gpu-x11-bin-mx51 libz160"
LIC_FILES_CHKSUM = "file://COPYING;md5=f7bdc0c63080175d1667091b864cb12c"
-PR = "r8"
+PR = "r9"
SRC_URI = "${FSL_MIRROR}/xserver-xorg-video-imx-${PV}.tar.gz \
- file://xf86-video-imxfb-fix-m4-hardcodded-paths.patch"
+ file://xf86-video-imxfb-fix-m4-hardcodded-paths.patch \
+ file://Make-video-API-forward-and-backward-compatible.patch \
+ file://ext-Update-to-newer-swap-macros.patch \
+"
SRC_URI[md5sum] = "d19148399b5d1c4dab90d0cc6f2c4789"
SRC_URI[sha256sum] = "d7d85e9f13c6dd58addab89847f3a8a67f6382a54135c7978c9a95368af024d4"
--
1.7.10.4
^ permalink raw reply related
* [PATCH v3 0/5] ARM: Exynos: Enable device tree support for MCT controller
From: Olof Johansson @ 2012-12-30 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356814238-23895-1-git-send-email-thomas.abraham@linaro.org>
On Sat, Dec 29, 2012 at 12:50:33PM -0800, Thomas Abraham wrote:
> Changes since v2:
> - Rebased to linux 3.8-rc1
>
> Changes since v1:
> - Includes changes suggested by Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
>
> This patch series adds device tree support for Exynos4/5 MCT controller.
> This patch series has been tested on Exynos4210 based Origen board, Exynos4412
> based Origen board and Exynos5250 based SMDK board.
Hi,
Nice cleanups -- no specific comments on those at this time. But
this is a good time to move the MCT driver out of arch/arm and into
drivers/clocksource. Can you please do that in this series as well,
please?
Thanks,
-Olof
^ permalink raw reply
* Re: [PATCH v3 0/5] ARM: Exynos: Enable device tree support for MCT controller
From: Olof Johansson @ 2012-12-30 5:24 UTC (permalink / raw)
To: Thomas Abraham
Cc: devicetree-discuss, linux-samsung-soc, kgene.kim, chaos.youn,
sylvester.nawrocki, linux-arm-kernel
In-Reply-To: <1356814238-23895-1-git-send-email-thomas.abraham@linaro.org>
On Sat, Dec 29, 2012 at 12:50:33PM -0800, Thomas Abraham wrote:
> Changes since v2:
> - Rebased to linux 3.8-rc1
>
> Changes since v1:
> - Includes changes suggested by Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
>
> This patch series adds device tree support for Exynos4/5 MCT controller.
> This patch series has been tested on Exynos4210 based Origen board, Exynos4412
> based Origen board and Exynos5250 based SMDK board.
Hi,
Nice cleanups -- no specific comments on those at this time. But
this is a good time to move the MCT driver out of arch/arm and into
drivers/clocksource. Can you please do that in this series as well,
please?
Thanks,
-Olof
^ permalink raw reply
* Re: Concurrent Sessions/Sessions per second
From: Eliezer Croitoru @ 2012-12-30 4:49 UTC (permalink / raw)
To: Usuário do Sistema; +Cc: Mail List - Netfilter
In-Reply-To: <CAMTjHrwtaUV60nB5exUkiwNDsrFUDU4Rv2ep67c3VV230C-fvQ@mail.gmail.com>
It depends on a lot of stuff...
if you are using connection tracking in your IPTABLES it will reduce the
number of open connections your machine can handle.
if you will use DEEP INSPECTION modules it will handle even less.
In most cases a nice and modern PC(not a server) can handle more then
100k connections with any trouble.
but this is about IPTABLES...
if you have applications on your server it's another thing.
With a nice 8 cores 16gb Server you can max it with a proxy on it to
about 30M connections with no trouble at all.
Regards,
Eliezer
On 27/12/2012 19:17, Usuário do Sistema wrote:
> Hello everyone,
>
>
> anyone help me how can I figure out the follows value in my Linux box ?
>
> Max Concurrent Session
>
> New Sessions per second
>
> they are related with CPU of the machine ?
>
> there is any way how to figure out how many connections are through
> my firewall iptables ?
>
> any tip is welcome
>
> thanks
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" 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
* [git pull] drm fixes
From: Dave Airlie @ 2012-12-30 4:23 UTC (permalink / raw)
To: torvalds; +Cc: DRI mailing list, linux-kernel
Hi Linus,
bit larger due to me not bothering to do anything since before Xmas, and
other people working too hard after I had clearly given up.
Its got the 3 main x86 driver fixes pulls, and a bunch of tegra fixes,
doesn't fix the Ironlake bug yet, but that does seem to be getting closer.
radeon: gpu reset fixes and userspace packet support
i915: watermark fixes, workarounds, i830/845 fix,
nouveau: nvd9/kepler microcode fixes, accel is now enabled and working,
gk106 support
tegra: misc fixes.
Dave.
The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux drm-next
for you to fetch changes up to 500df2e5d870ef5be3d37f0798f770028b69fd47:
drm: tegra: program only one window during modeset (2012-12-30 14:01:35 +1000)
----------------------------------------------------------------
Alex Deucher (1):
drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list
Ben Skeggs (8):
drm/nouveau: initial support for GK106
drm/nouveau/bios: update gpio parsing apis to match current design
drm/nouveau/bios: implement opcode 0xa9
drm/nouveau/bios: parse/display extra version component
drm/nouveau/mxm: silence output if no bios data
drm/nouveau/bios: cache ramcfg strap on later chipsets
drm/nvc0/graph: fix fuc, and enable acceleration on GF119
drm/nve0/graph: fix fuc, and enable acceleration on all known chipsets
Chris Wilson (6):
drm/i915: Fixup cursor latency used for IVB lp3 watermarks
drm/i915: Double the cursor self-refresh latency on Valleyview
drm/i915: Clear self-refresh watermarks when disabled
drm/i915: Prefer CRTC 'active' rather than 'enabled' during WM computations
drm: Export routines for inserting preallocated nodes into the mm manager
drm/i915: Preallocate the drm_mm_node prior to manipulating the GTT drm_mm manager
Daniel Vetter (6):
drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled
drm/i915: Implement WaSetupGtModeTdRowDispatch
drm/i915: Implement workaround for broken CS tlb on i830/845
drm/i915: don't disable disconnected outputs
drm/i915: optionally disable shrinker lock stealing
drm/i915: disable shrinker lock stealing for create_mmap_offset
Dave Airlie (4):
drm/i915: fix flags in dma buf exporting
Merge branch 'drm-nouveau-fixes-3.8' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux into drm-next
Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next
Jerome Glisse (4):
drm/radeon: don't leave fence blocked process on failed GPU reset
drm/radeon: avoid deadlock in pm path when waiting for fence
drm/radeon: restore modeset late in GPU reset path
drm/radeon: add support for MEM_WRITE packet
Krzysztof Mazur (1):
i915: ensure that VGA plane is disabled
Lucas Stach (6):
drm: tegra: fix front_porch <-> back_porch mixup
drm: tegra: don't leave clients host1x member uninitialized
drm: tegra: protect DC register access with mutex
drm: tegra: remove redundant tegra2_tmds_config entry
drm: tegra: clean out old gem prototypes
drm: tegra: program only one window during modeset
drivers/gpu/drm/drm_mm.c | 41 ++++--
drivers/gpu/drm/i915/i915_dma.c | 3 +
drivers/gpu/drm/i915/i915_drv.h | 8 ++
drivers/gpu/drm/i915/i915_gem.c | 77 +++++-----
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +
drivers/gpu/drm/i915/i915_irq.c | 12 ++
drivers/gpu/drm/i915/i915_reg.h | 4 +-
drivers/gpu/drm/i915/intel_display.c | 23 ++-
drivers/gpu/drm/i915/intel_pm.c | 160 ++++++++++++++++++---
drivers/gpu/drm/i915/intel_ringbuffer.c | 76 ++++++++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
.../drm/nouveau/core/engine/graph/fuc/gpcnve0.fuc | 5 +
.../nouveau/core/engine/graph/fuc/gpcnve0.fuc.h | 17 ++-
.../drm/nouveau/core/engine/graph/fuc/hubnvc0.fuc | 10 ++
.../nouveau/core/engine/graph/fuc/hubnvc0.fuc.h | 147 +++++++++----------
.../drm/nouveau/core/engine/graph/fuc/hubnve0.fuc | 13 ++
.../nouveau/core/engine/graph/fuc/hubnve0.fuc.h | 157 ++++++++++----------
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 11 +-
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h | 1 +
drivers/gpu/drm/nouveau/core/engine/graph/nve0.c | 3 +-
drivers/gpu/drm/nouveau/core/include/subdev/bios.h | 1 +
.../drm/nouveau/core/include/subdev/bios/gpio.h | 8 +-
.../drm/nouveau/core/include/subdev/bios/init.h | 1 +
drivers/gpu/drm/nouveau/core/include/subdev/gpio.h | 2 +-
drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 5 +-
drivers/gpu/drm/nouveau/core/subdev/bios/gpio.c | 128 ++++++++++-------
drivers/gpu/drm/nouveau/core/subdev/bios/init.c | 65 ++++++++-
drivers/gpu/drm/nouveau/core/subdev/device/nve0.c | 28 ++++
drivers/gpu/drm/nouveau/core/subdev/gpio/base.c | 9 +-
drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c | 9 +-
drivers/gpu/drm/nouveau/core/subdev/gpio/nvd0.c | 9 +-
drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 2 +-
drivers/gpu/drm/radeon/evergreen_cs.c | 30 ++++
drivers/gpu/drm/radeon/r600_cs.c | 29 ++++
drivers/gpu/drm/radeon/radeon.h | 3 +-
drivers/gpu/drm/radeon/radeon_device.c | 17 ++-
drivers/gpu/drm/radeon/radeon_drv.c | 3 +-
drivers/gpu/drm/radeon/radeon_fence.c | 49 ++++---
drivers/gpu/drm/radeon/radeon_pm.c | 15 +-
drivers/gpu/drm/tegra/dc.c | 24 +++-
drivers/gpu/drm/tegra/drm.h | 19 +--
drivers/gpu/drm/tegra/hdmi.c | 25 +---
drivers/gpu/drm/tegra/host1x.c | 2 +
include/drm/drm_mm.h | 25 +++-
include/uapi/drm/i915_drm.h | 10 ++
46 files changed, 894 insertions(+), 397 deletions(-)
^ permalink raw reply
* Re: [PATCH RESEND 4] ARM: plat-versatile: move secondary CPU startup into cpuinit
From: Christoffer Dall @ 2012-12-30 4:09 UTC (permalink / raw)
To: Claudio Fontana; +Cc: Russell King, linux-arm-kernel, linux-kernel
In-Reply-To: <50D02C89.9030307@huawei.com>
On Tue, Dec 18, 2012 at 3:42 AM, Claudio Fontana
<Claudio.Fontana@huawei.com> wrote:
>
> Using __CPUINIT instead of __INIT puts the secondary CPU startup code
> into the "right" section: it will not be freed in hotplug configurations,
> allowing hot-add of cpus, while still getting freed in non-hotplug configs.
>
> Tested successfully on Fast-Models and on Arndale for VCPU hotplug.
not quite sure how testing on Arndale verifies this change?
>
> Signed-off-by: Claudio Fontana <claudio.fontana@huawei.com>
> Tested-by: Claudio Fontana <claudio.fontana@huawei.com>
>
> diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S
> index dd703ef..19fe180 100644
> --- a/arch/arm/plat-versatile/headsmp.S
> +++ b/arch/arm/plat-versatile/headsmp.S
> @@ -11,7 +11,7 @@
> #include <linux/linkage.h>
> #include <linux/init.h>
>
> - __INIT
> + __CPUINIT
>
> /*
> * Realview/Versatile Express specific entry point for secondary CPUs.
> --
> 1.7.12.1
>
Otherwise looks ok to me (not guaranteeing that cpu hotplug will
magically work for KVM using this change though).
-Christoffer
^ permalink raw reply
* [PATCH RESEND 4] ARM: plat-versatile: move secondary CPU startup into cpuinit
From: Christoffer Dall @ 2012-12-30 4:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50D02C89.9030307@huawei.com>
On Tue, Dec 18, 2012 at 3:42 AM, Claudio Fontana
<Claudio.Fontana@huawei.com> wrote:
>
> Using __CPUINIT instead of __INIT puts the secondary CPU startup code
> into the "right" section: it will not be freed in hotplug configurations,
> allowing hot-add of cpus, while still getting freed in non-hotplug configs.
>
> Tested successfully on Fast-Models and on Arndale for VCPU hotplug.
not quite sure how testing on Arndale verifies this change?
>
> Signed-off-by: Claudio Fontana <claudio.fontana@huawei.com>
> Tested-by: Claudio Fontana <claudio.fontana@huawei.com>
>
> diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S
> index dd703ef..19fe180 100644
> --- a/arch/arm/plat-versatile/headsmp.S
> +++ b/arch/arm/plat-versatile/headsmp.S
> @@ -11,7 +11,7 @@
> #include <linux/linkage.h>
> #include <linux/init.h>
>
> - __INIT
> + __CPUINIT
>
> /*
> * Realview/Versatile Express specific entry point for secondary CPUs.
> --
> 1.7.12.1
>
Otherwise looks ok to me (not guaranteeing that cpu hotplug will
magically work for KVM using this change though).
-Christoffer
^ permalink raw reply
* Re: [ANNOUNCE] 3.7-nohz1
From: Paul E. McKenney @ 2012-12-30 3:56 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Steven Rostedt, LKML, Alessio Igor Bogani, Andrew Morton,
Avi Kivity, Chris Metcalf, Christoph Lameter, Geoff Levand,
Gilad Ben Yossef, Hakan Akkan, Ingo Molnar, Paul Gortmaker,
Peter Zijlstra, Thomas Gleixner, Li Zhong
In-Reply-To: <CAFTL4hy_k8rWg5EAFnh-owey7NJCQbK+ULrkNrSjgdynzEseTw@mail.gmail.com>
On Mon, Dec 24, 2012 at 12:43:25AM +0100, Frederic Weisbecker wrote:
> 2012/12/21 Steven Rostedt <rostedt@goodmis.org>:
> > On Thu, 2012-12-20 at 19:32 +0100, Frederic Weisbecker wrote:
> >> Let's imagine you have 4 CPUs. We keep the CPU 0 to offline RCU callbacks there and to
> >> handle the timekeeping. We set the rest as full dynticks. So you need the following kernel
> >> parameters:
> >>
> >> rcu_nocbs=1-3 full_nohz=1-3
> >>
> >> (Note rcu_nocbs value must always be the same as full_nohz).
> >
> > Why? You can't have: rcu_nocbs=1-4 full_nohz=1-3
>
> That should be allowed.
>
> > or: rcu_nocbs=1-3 full_nohz=1-4 ?
>
> But that not.
>
> You need to have: rcu_nocbs & full_nohz == full_nohz. This is because
> the tick is not there to maintain the local RCU callbacks anymore. So
> this must be offloaded to the rcu_nocb threads.
>
> I just have a doubt with rcu_nocb. Do we still need the tick to
> complete the grace period for local rcu callbacks? I need to discuss
> that with Paul.
The tick is only needed if rcu_needs_cpu() returns false. Of course,
this means that if you don't invoke rcu_needs_cpu() before returning to
adaptive-idle usermode execution, you are correct that a full_nohz CPU
would also have to be a rcu_nocbs CPU.
That said, I am getting close to having an rcu_needs_cpu() that only
returns false if there are callbacks immediately ready to invoke, at
least if RCU_FAST_NO_HZ=y.
Thanx, Paul
> > That needs to be fixed. Either with a warning, and/or to force the two
> > to be the same. That is, if they specify:
> >
> > rcu_nocbs=1-3 full_nohz=1-4
> >
> > Then set rcu_nocbs=1-4 with a warning about it. Or simply set
> > full_nohz=1-3.
>
> Yep, will do.
>
> Thanks!
>
> >
> > -- Steve
> >
> >>
> >> Now if you want proper isolation you need to:
> >>
> >> * Migrate your processes adequately
> >> * Migrate your irqs to CPU 0
> >> * Migrate the RCU nocb threads to CPU 0. Example with the above configuration:
> >>
> >> for p in $(ps -o pid= -C rcuo1,rcuo2,rcuo3)
> >> do
> >> taskset -cp 0 $p
> >> done
> >>
> >> Then run what you want on the full dynticks CPUs. For best results, run 1 task
> >> per CPU, mostly in userspace and mostly CPU bound (otherwise more IO = more kernel
> >> mode execution = more chances to get IPIs, tick restarted, workqueues, kthreads, etc...)
> >>
> >> This page contains a good reminder for those interested in CPU isolation: https://github.com/gby/linux/wiki
> >>
> >> But keep in mind that my tree is not yet ready for serious production.
> >>
> >
> >
>
^ permalink raw reply
* Re: filefrag: improvements to filefrag FIEMAP handling
From: Theodore Ts'o @ 2012-12-30 3:56 UTC (permalink / raw)
To: Andreas Dilger; +Cc: linux-ext4
In-Reply-To: <1353632772-18664-1-git-send-email-adilger@whamcloud.com>
On Thu, Nov 22, 2012 at 03:06:12PM -0000, Andreas Dilger wrote:
> Update the filefrag program to allow displaying the extents in
> some different formats. Try and stay within 80 columns.
> * add -k option to print extents in kB-sized units (like df -k)
> * add -b {blocksize} to print extents in blocksize units
> * add -e option to print extent format, even when FIBMAP is used
> * add -X option to print extents in hexadecimal format
>
> Internally, the FIBMAP handling code has been moved into its own
> function like FIEMAP, so that the code is more modular. Extent
> offsets are now handled in bytes instead of in blocks, to allow
> printing extents with arbitrary block sizes. The extent header
> printing also moved into its own function so that it can be shared
> between the FIEMAP and FIBMAP handling routines, since it got more
> complex with the different output options.
>
> Only print error about FIBMAP being root-only a single time.
> Print the filesystem type if it changes between specified files.
> Add fsync() for FIBMAP if "-s" is given.
>
> Add support for filesystems that have multiple backing devices
> so that extents stored on different devices can be disinguished
> from each other. This is enabled by default for Lustre, but
> can be selected for other filesystems if desired/supported with
> the "-l" option.
>
> Signed-off-by: Andreas Dilger <adilger@whamcloud.com>
In the future, it's really a lot easier to review these sorts of
patches if you break up the patch. Note how I sent my resize2fs
flex_bg patches as an example. Reviewing a huge megapatch is much
more difficult, and it makes patch conflicts more common and more
difficult to resolve.
I removed the DEVICE_ORDER support since I'm not entirely sure how
much we want support these Lustre-specific extensions, especially
since they require out-of-tree ABI extensions. The bit fields in
question haven't been reserved in the kernel, and I've been having
trouble finding the formal definition of these ABI extensions.
In any case, it looks like Lustre's e2fsprogs patches have hugely
modified filefrag, and so by accepting the bulk of this patch, it
should make things easier for you to maintain the Lustre-speciific
patches until we can figure out how we want ot deal with this bit of
your changes.
- Ted
^ permalink raw reply
* [Bug 58735] GeForce 680, currently driver works on two, but not three monitors
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2012-12-30 3:39 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-58735-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
[-- Attachment #1.1: Type: text/plain, Size: 237 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=58735
--- Comment #8 from Sean Santos <quantheory-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ---
Nice! Works for me.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1014 bytes --]
[-- Attachment #2: Type: text/plain, Size: 181 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* [Xenomai] Can not run test on Raspberry Pi
From: 沈涛 @ 2012-12-30 3:32 UTC (permalink / raw)
To: Xenomai
Hello all!
I'm not familiar with either Xenomai or Raspberry Pi.So please do not be
mad at me if my question seems silly.
Anyway,I followed the instructions on
http://powet.eu/2012/07/25/raspberry-pi-xenomai/<http://translate.googleusercontent.com/translate_c?depth=1&hl=en&ie=UTF8&prev=_t&rurl=translate.google.com&sl=fr&tl=en&twu=1&u=http://powet.eu/2012/07/25/raspberry-pi-xenomai/&usg=ALkJrhh8sBPbInHso_27CJ73Qprh-F7cxA>
and
cross compiled a kernel patched with Xenomai with tools from
https://github.com/raspberrypi/tools.It seems work fine.
Then I cross compile Xenomai(the user-space sport),and copied all the
results to my Raspberry Pi.When I try to run the /usr/xenomai/bin/latency,I
get the ERROR: error while loading shared libraries:libnative.so.3:cannot
open shared object file: No such file or directory.
pi@raspberrypi ~ $ ls /usr/xenomai/lib
...... libnative.so.3 ......
So the object file is there.
The I tried to ldconfig with /usr/xenomai/lib in my /etc/ld.so.conf,and
confirm the result.
pi@raspberrypi ~ $ ldconfig - p | grep native
libnative.so.3(libc6)=>/usr/xenomai/lib/libnative.so.3
......
I also tried to export LD_LIBRARY_PATH,still get the same error.
I know the problem may seems familiar to you.I have already googled it and
keep trying to solve it.I also read the Program-Library-HOWTO from
http://www.tldp.org/HOWTO/Program-Library-HOWTO/introduction.html and try
to learn more about shared libraries.But I still can not solve my
problem,need some help.
Thanks in advance.
Shen Tao
^ permalink raw reply
* Re: Concurrent Sessions/Sessions per second
From: Pablo Neira Ayuso @ 2012-12-30 3:21 UTC (permalink / raw)
To: Usuário do Sistema; +Cc: Mail List - Netfilter
In-Reply-To: <CAMTjHrwtaUV60nB5exUkiwNDsrFUDU4Rv2ep67c3VV230C-fvQ@mail.gmail.com>
Hi,
On Thu, Dec 27, 2012 at 03:17:04PM -0200, Usuário do Sistema wrote:
> Hello everyone,
>
> anyone help me how can I figure out the follows value in my Linux box ?
>
> Max Concurrent Session
> New Sessions per second
>
> they are related with CPU of the machine ?
CPU and other hardware aspects are important. But there several
configuration parameters (like using the irqbalance daemon, tweaking
the conntrack table) and they make a difference.
I suggest you a read of the evaluation part of these articles:
http://1984.lsi.us.es/~pablo/docs/intcomp09.pdf
http://people.netfilter.org/kadlec/nftest.pdf
Another important thing while benchmarking is that you have to make
sure that neither your client nor your benchmark server become the
bottleneck. Otherwise, you end up getting misleading benchmarking
results.
> there is any way how to figure out how many connections are through
> my firewall iptables ?
You can obtain the maximum sessions/s by generating lots of well small
connections, ie. assuming TCP, 3-way handshake and then immediately
tearing down the connection.
For the client side, you can probably check this utility, it generates
plain HTTP requests:
http://1984.lsi.us.es/git/http-client-benchmark/
For the server side, I suggest you to grab Willy Tarreau's httpterm:
http://1wt.eu/tools/httpterm/
I have tried many other utilities in the past, but those are my
favorite ones so far.
^ permalink raw reply
* Re: [PATCH] printk: Fix incorrect length from print_time() when seconds > 99999
From: Joe Perches @ 2012-12-30 3:07 UTC (permalink / raw)
To: Roland Dreier, Peter Zijlstra, Paul Mackerras, Ingo Molnar,
Arnaldo Carvalho de Melo
Cc: Greg Kroah-Hartman, Sylvain Munaut, Kay Sievers, Andrew Morton,
LKML
In-Reply-To: <CAL1RGDV5fje8+sNQUCgJNKaasZ=pvg4rWrXaz-3cZ+uNgsWDzg@mail.gmail.com>
On Sat, 2012-12-29 at 14:27 -0800, Roland Dreier wrote:
> On Sat, Dec 29, 2012 at 12:08 PM, Joe Perches <joe@perches.com> wrote:
> > Sylvan Munaut did something similar
> > https://lkml.org/lkml/2012/12/5/168
>
> Missed that and duplicated the debugging :(
> Sorry Sylvain.
>
> I guess my patch may be preferable, since I happened to use the snprintf()
> method that you suggest -- all the open-coded digit-counting seems a bit
> verbose and perhaps hard to read and see the equivalence to the sprintf.
the kernel implementation of snprint/vsnprintf does expand on c99
and allow snprintf(NULL, 0... so your code should work fine.
I think the
snprintf(NULL, 0
might be suspect.
(the same form is already used in drivers/usb/gadget/composite.c)
man snprintf says in part:
Concerning the return value of snprintf(), SUSv2 and C99 contradict
each other: when snprintf() is called with size=0 then SUSv2 stipulates
an unspecified return value less than 1, while C99 allows str to be
NULL in this case, and gives the return value (as always) as the number
of characters that would have been written in case the output string
has been large enough.
If not here, maybe the tools/perf/util/values.c code
that uses the same form might need changing.
^ permalink raw reply
* [PATCH] rtc: vt8500: Fix handling of data passed in struct rtc_time
From: Tony Prisk @ 2012-12-30 3:04 UTC (permalink / raw)
To: Alessandro Zummo
Cc: linux-kernel, linux-arm-kernel, vt8500-wm8505-linux-kernel,
rtc-linux, Tony Prisk, Edgar Toernig
tm_mon is 0..11, whereas vt8500 expects 1..12 for the month field,
causing invalid date errors for January, and causing the day field
to roll over incorrectly.
The century flag is only handled in vt8500_rtc_read_time, but not
set in vt8500_rtc_set_time. This patch corrects the behaviour of the
century flag.
Signed-off-by: Edgar Toernig <froese@gmx.de>
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
This patch is based on 3.8rc1 with the previous fix applied:
Previous patch: 77cdf96a0654cb45b4dd530f3393c6a8f2fa1e0b
rtc: vt8500: Correct handling of CR_24H bitfield
drivers/rtc/rtc-vt8500.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
index 387edf6..2448f2a 100644
--- a/drivers/rtc/rtc-vt8500.c
+++ b/drivers/rtc/rtc-vt8500.c
@@ -119,7 +119,7 @@ static int vt8500_rtc_read_time(struct device *dev, struct rtc_time *tm)
tm->tm_min = bcd2bin((time & TIME_MIN_MASK) >> TIME_MIN_S);
tm->tm_hour = bcd2bin((time & TIME_HOUR_MASK) >> TIME_HOUR_S);
tm->tm_mday = bcd2bin(date & DATE_DAY_MASK);
- tm->tm_mon = bcd2bin((date & DATE_MONTH_MASK) >> DATE_MONTH_S);
+ tm->tm_mon = bcd2bin((date & DATE_MONTH_MASK) >> DATE_MONTH_S) - 1;
tm->tm_year = bcd2bin((date & DATE_YEAR_MASK) >> DATE_YEAR_S)
+ ((date >> DATE_CENTURY_S) & 1 ? 200 : 100);
tm->tm_wday = (time & TIME_DOW_MASK) >> TIME_DOW_S;
@@ -138,8 +138,9 @@ static int vt8500_rtc_set_time(struct device *dev, struct rtc_time *tm)
}
writel((bin2bcd(tm->tm_year - 100) << DATE_YEAR_S)
- | (bin2bcd(tm->tm_mon) << DATE_MONTH_S)
- | (bin2bcd(tm->tm_mday)),
+ | (bin2bcd(tm->tm_mon + 1) << DATE_MONTH_S)
+ | (bin2bcd(tm->tm_mday))
+ | ((tm->tm_year >= 200) << DATE_CENTURY_S),
vt8500_rtc->regbase + VT8500_RTC_DS);
writel((bin2bcd(tm->tm_wday) << TIME_DOW_S)
| (bin2bcd(tm->tm_hour) << TIME_HOUR_S)
--
1.7.9.5
^ permalink raw reply related
* [PATCH] rtc: vt8500: Fix handling of data passed in struct rtc_time
From: Tony Prisk @ 2012-12-30 3:04 UTC (permalink / raw)
To: linux-arm-kernel
tm_mon is 0..11, whereas vt8500 expects 1..12 for the month field,
causing invalid date errors for January, and causing the day field
to roll over incorrectly.
The century flag is only handled in vt8500_rtc_read_time, but not
set in vt8500_rtc_set_time. This patch corrects the behaviour of the
century flag.
Signed-off-by: Edgar Toernig <froese@gmx.de>
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
This patch is based on 3.8rc1 with the previous fix applied:
Previous patch: 77cdf96a0654cb45b4dd530f3393c6a8f2fa1e0b
rtc: vt8500: Correct handling of CR_24H bitfield
drivers/rtc/rtc-vt8500.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
index 387edf6..2448f2a 100644
--- a/drivers/rtc/rtc-vt8500.c
+++ b/drivers/rtc/rtc-vt8500.c
@@ -119,7 +119,7 @@ static int vt8500_rtc_read_time(struct device *dev, struct rtc_time *tm)
tm->tm_min = bcd2bin((time & TIME_MIN_MASK) >> TIME_MIN_S);
tm->tm_hour = bcd2bin((time & TIME_HOUR_MASK) >> TIME_HOUR_S);
tm->tm_mday = bcd2bin(date & DATE_DAY_MASK);
- tm->tm_mon = bcd2bin((date & DATE_MONTH_MASK) >> DATE_MONTH_S);
+ tm->tm_mon = bcd2bin((date & DATE_MONTH_MASK) >> DATE_MONTH_S) - 1;
tm->tm_year = bcd2bin((date & DATE_YEAR_MASK) >> DATE_YEAR_S)
+ ((date >> DATE_CENTURY_S) & 1 ? 200 : 100);
tm->tm_wday = (time & TIME_DOW_MASK) >> TIME_DOW_S;
@@ -138,8 +138,9 @@ static int vt8500_rtc_set_time(struct device *dev, struct rtc_time *tm)
}
writel((bin2bcd(tm->tm_year - 100) << DATE_YEAR_S)
- | (bin2bcd(tm->tm_mon) << DATE_MONTH_S)
- | (bin2bcd(tm->tm_mday)),
+ | (bin2bcd(tm->tm_mon + 1) << DATE_MONTH_S)
+ | (bin2bcd(tm->tm_mday))
+ | ((tm->tm_year >= 200) << DATE_CENTURY_S),
vt8500_rtc->regbase + VT8500_RTC_DS);
writel((bin2bcd(tm->tm_wday) << TIME_DOW_S)
| (bin2bcd(tm->tm_hour) << TIME_HOUR_S)
--
1.7.9.5
^ 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.