[PATCH] drivers: Change calls to mdelay to msleep in order to stop CPU busy looping in mdfld_dsi_pkg_sender.c
On Mon, Nov 17, 2014 at 3:40 AM, Jani Nikula
wrote:
> On Sat, 15 Nov 2014, Nicholas Krause wrote:
>> Changes the calls of mdelay to msleep in the driver file
>> mdfld_dsi_pkg_sender.c
>> in order to prevent CPU busy looping in order to save CPU cycles as this is
>> considered bad form over sleeping the CPU for high resolution timer function
>> calls as this driver needs in order to function properly.
>
> The code paths are called with sender->lock spinlock held.
>
> BR,
> Jani.
>
>>
>> Signed-off-by: Nicholas Krause
>> ---
>> drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 15 +--
>> 1 file changed, 5 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
>> b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
>> index 87885d8..77c656a 100644
>> --- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
>> +++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
>> @@ -335,13 +335,11 @@ static int send_pkg_prepare(struct
>> mdfld_dsi_pkg_sender *sender, u8 data_type,
>>
>> /*wait for 120 milliseconds in case exit_sleep_mode just be sent*/
>> if (unlikely(cmd == DCS_ENTER_SLEEP_MODE)) {
>> - /*TODO: replace it with msleep later*/
>> - mdelay(120);
>> + msleep(120);
>> }
>>
>> if (unlikely(cmd == DCS_EXIT_SLEEP_MODE)) {
>> - /*TODO: replace it with msleep later*/
>> - mdelay(120);
>> + msleep(120);
>> }
>> return 0;
>> }
>> @@ -364,15 +362,12 @@ static int send_pkg_done(struct mdfld_dsi_pkg_sender
>> *sender, u8 data_type,
>> /*update panel status*/
>> if (unlikely(cmd == DCS_ENTER_SLEEP_MODE)) {
>> sender->panel_mode |= MDFLD_DSI_PANEL_MODE_SLEEP;
>> - /*TODO: replace it with msleep later*/
>> - mdelay(120);
>> + msleep(120);
>> } else if (unlikely(cmd == DCS_EXIT_SLEEP_MODE)) {
>> sender->panel_mode &= ~MDFLD_DSI_PANEL_MODE_SLEEP;
>> - /*TODO: replace it with msleep later*/
>> - mdelay(120);
>> + msleep(120);
>> } else if (unlikely(cmd == DCS_SOFT_RESET)) {
>> - /*TODO: replace it with msleep later*/
>> - mdelay(5);
>> + msleep(5);
>> }
>>
>> sender->status = MDFLD_DSI_PKG_SENDER_FREE;
>> --
>> 1.9.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Jani Nikula, Intel Open Source Technology Center
Then surely we can remove this to dos or do we have to move all the
code to another coding scheme for this driver using mutuxes as they
don't loop.
[sbc_gxx] kernel BUG at include/linux/mtd/map.h:148!
On Thu, Aug 7, 2014 at 6:46 PM, Brian Norris wrote: > Hi, > > On Tue, Aug 05, 2014 at 08:08:57PM -0400, Nick Krause wrote: >> On Tue, Aug 5, 2014 at 9:59 AM, Fengguang Wu >> wrote: >> > Hello, >> > >> > This is an old BUG that still lives in linux-next. >> > >> > [4.284620] device id = 2670 >> > [4.286157] SBC-GXx flash: IO:0x258-0x259 MEM:0xdc000-0xd >> > [4.287060] [ cut here ] >> > [4.287722] kernel BUG at include/linux/mtd/map.h:148! >> > [4.288048] invalid opcode: [#1] PREEMPT SMP >> >> I am new , here and will try to trace your issue on linus's tree >> unless there is a major difference between Linus's tree and >> linux-next. >> If there is please let me known before I start tracing this. > > This is a known issue, and Fengguang has reported this before: > > http://lists.infradead.org/pipermail/linux-mtd/2014-March/053019.html > > I'm still not quite sure how to solve this one. It seems to be a > limitation of the kconfig language. > > Brian I am and banned from the lists but trying to get back on, if you want my help please let me known. I will read this bug report first but just tell me if you want some help. Cheers Nick
[sbc_gxx] kernel BUG at include/linux/mtd/map.h:148!
On Tue, Aug 5, 2014 at 9:59 AM, Fengguang Wu wrote:
> Hello,
>
> This is an old BUG that still lives in linux-next.
>
> [4.284620] device id = 2670
> [4.286157] SBC-GXx flash: IO:0x258-0x259 MEM:0xdc000-0xd
> [4.287060] [ cut here ]
> [4.287722] kernel BUG at include/linux/mtd/map.h:148!
> [4.288048] invalid opcode: [#1] PREEMPT SMP
> [4.288048] CPU 1
> [4.288048] Pid: 1, comm: swapper/0 Not tainted 3.5.0-rc4-00162-g49099c4
> #17 Bochs Bochs
> [4.288048] RIP: 0010:[] []
> mtd_do_chip_probe+0x1d/0x1f
> [4.288048] RSP: 0018:880011049e20 EFLAGS: 00010246
> [4.288048] RAX: RBX: 82a23550 RCX:
>
> [4.288048] RDX: 880011049e20 RSI: 82a23580 RDI:
> 880011049e80
> [4.288048] RBP: 880011049e80 R08: 0003 R09:
> 810d6c93
> [4.288048] R10: R11: 0001 R12:
> 82a23eb0
> [4.288048] R13: 828790ce R14: R15:
>
> [4.288048] FS: () GS:88001260()
> knlGS:
> [4.288048] CS: 0010 DS: ES: CR0: 8005003b
> [4.288048] CR2: CR3: 0298c000 CR4:
> 000406e0
> [4.288048] DR0: DR1: DR2:
>
> [4.288048] DR3: DR6: 0ff0 DR7:
> 0400
> [4.288048] Process swapper/0 (pid: 1, threadinfo 880011048000, task
> 88001104)
> [4.288048] Stack:
> [4.288048]
>
> [4.288048]
>
> [4.288048]
>
> [4.288048] Call Trace:
> [4.288048] [] cfi_probe+0x15/0x17
> [4.288048] [] do_map_probe+0xa0/0xac
> [4.288048] [] ? physmap_init+0x12/0x12
> [4.288048] [] init_sbc_gxx+0x104/0x15b
> [4.288048] [] do_one_initcall+0x86/0x208
> [4.288048] [] kernel_init+0x10d/0x1c2
> [4.288048] [] ? do_early_param+0xc3/0xc3
> [4.288048] [] kernel_thread_helper+0x4/0x10
> [4.288048] [] ? retint_restore_args+0x13/0x13
> [4.288048] [] ? do_one_initcall+0x208/0x208
> [4.288048] [] ? gs_change+0x13/0x13
> [4.288048] Code: 83 c4 58 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 48 89 e5 48
> 83 ec 60 66 66 66 66 90 31 c0 b9 18 00 00 00 48 8d 55 a0 48 89 d7 f3 ab <0f>
> 0b 55 48 89 e5 66 66 66 66 90 48 c7 c6 a0 39 a2 82 e8 cc ff
> [4.288048] RIP [] mtd_do_chip_probe+0x1d/0x1f
> [4.288048] RSP
> [4.321423] ---[ end trace 169195d5d1f9be6e ]---
> [4.322118] swapper/0 (1) used greatest stack depth: 3768 bytes left
>
> This script may reproduce the error.
>
>
> #!/bin/bash
>
> kernel=$1
> initrd=quantal-core-x86_64.cgz
>
> wget --no-clobber
> https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd/$initrd
>
> kvm=(
> qemu-system-x86_64
> -enable-kvm
> -cpu Haswell,+smep,+smap
> -kernel $kernel
> -initrd $initrd
> -m 320
> -smp 2
> -net nic,vlan=1,model=e1000
> -net user,vlan=1
> -boot order=nc
> -no-reboot
> -watchdog i6300esb
> -rtc base=localtime
> -serial stdio
> -display none
> -monitor null
> )
>
> append=(
> hung_task_panic=1
> earlyprintk=ttyS0,115200
> debug
> apic=debug
> sysrq_always_enabled
> rcupdate.rcu_cpu_stall_timeout=100
> panic=10
> softlockup_panic=1
> nmi_watchdog=panic
> prompt_ramdisk=0
> console=ttyS0,115200
> console=tty0
> vga=normal
> root=/dev/ram0
> rw
> drbd.minor_count=8
> )
>
> "${kvm[@]}" --append "${append[*]}"
>
>
> Thanks,
> Fengguang
>
> ___
> LKP mailing list
> LKP at linux.intel.com
>
I am new , here and will try to trace your issue on linus's tree
unless there is a major difference between Linus's tree and
linux-next.
If there is please let me known before I start tracing this.
Best Regards ,
Nick
No information on valleyview
After doing some research I didn't find any information on valley view. I am wondering valleyview_get_display_clock_speed what this should return as I can't find any information on it? Nick
Intel Graphics Drivers
On Sat, Jul 19, 2014 at 8:45 PM, Roberto J. Dohnert wrote: > This would probably be a better question for the Intel developers than the > kernel developers per say, but a great question nonetheless. The Intel > video drivers are perhaps the best supported on Linux. Most of the hardware > I ship does ship with Intel cards so in regards to performance, this would > be something I would like to see improve as well. > > Thanks, > > Roberto J. Dohnert > Lead Developer > Black Lab Software Inc. > PO Box 698 > Franklinton NC 27525 > http://www.pc-opensystems.com > http://www.blacklablinux.org > > > On 07/19/2014 06:54 PM, Nick Krause wrote: >> >> On Sat, Jul 19, 2014 at 6:32 PM, Nick Krause wrote: >> Hey Daniel and others , >> If I am correct after asking around on the mailing list then the >> windows Intel graphics drivers are faster then their Linux >> counterparts. >> In addition , I am wondering if we can improve this and try to >> remove regressions in this area of graphics support as this seems to >> be >> the main issue and perhaps the hardware is hard to come by outside of >> Intel or the board manufacturers as we seem to have no hardware >> for testing as I asked before . I don't have the hardware but if >> people help do the hardware testing and maybe a bit of advice and >> guidance >> as I am new to the graphics stack in the kernel I can help out :). >> If not that's Ok too just thought it may be of help. >> Cheers Nick >> P.S. Sorry about first email it wasn't edited. :( >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> > Our you sure there aren't Intel devolopers who do this on the lkml? I do known however that the nvidia and amd drivers are being, while not opened are being optimized for Linux and are now more stable and faster in most benchmarks by like 20% only after four months of development on a gtx 780. I would like to see the same work coming into the Intel drivers. Overall in terms of hardware support we are way better then Windows expect for a few areas ,which I will list below. 1. Nvidia Graphics can be faster then Windows( improving fast, probably will happen in next few months) Removed no overclocking support 2. Amd Graphics(same as above ) Removed no overclocking support 3.Intel Graphics(needs lots of work) 4. Printers and Scanners ( need more support from vendors) 5. Laptops( Mostly battery is shorter on a few laptops then in Windows) and maybe hdmi and touchscreen support? Otherwise we are good here and have removed are issues with Nvidia optimus not be supported 6. Gaming Mice and Keyboards Cheers Nick
Intel Graphics Drivers
On Sat, Jul 19, 2014 at 6:32 PM, Nick Krause wrote: Hey Daniel and others , If I am correct after asking around on the mailing list then the windows Intel graphics drivers are faster then their Linux counterparts. In addition , I am wondering if we can improve this and try to remove regressions in this area of graphics support as this seems to be the main issue and perhaps the hardware is hard to come by outside of Intel or the board manufacturers as we seem to have no hardware for testing as I asked before . I don't have the hardware but if people help do the hardware testing and maybe a bit of advice and guidance as I am new to the graphics stack in the kernel I can help out :). If not that's Ok too just thought it may be of help. Cheers Nick P.S. Sorry about first email it wasn't edited. :(
