* Re: [PATCH v3 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Kishon Vijay Abraham I @ 2013-06-29 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51CD6153.5050406@samsung.com>
Hi,
On Friday 28 June 2013 03:41 PM, Sylwester Nawrocki wrote:
> On 06/28/2013 10:17 AM, Hui Wang wrote:
>> On 06/26/2013 11:02 PM, Sylwester Nawrocki wrote:
>>> Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
>>> receiver and MIPI DSI transmitter DPHYs.
>>>
>>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>>> ---
>>> Changes since v2:
>>> - adapted to the generic PHY API v9: use phy_set/get_drvdata(),
>>> - fixed of_xlate callback to return ERR_PTR() instead of NULL,
>>> - namespace cleanup, put "GPL v2" as MODULE_LICENSE, removed pr_debug,
>>> - removed phy id check in __set_phy_state().
>>> ---
>> [...]
>>> +
>>> + if (IS_EXYNOS_MIPI_DSIM_PHY_ID(id))
>>> + reset = EXYNOS_MIPI_PHY_MRESETN;
>>> + else
>>> + reset = EXYNOS_MIPI_PHY_SRESETN;
>>> +
>>> + spin_lock_irqsave(&state->slock, flags);
>>
>> Sorry for one stupid question here, why do you use spin_lock_irqsave()
>> rather than spin_lock(),
>> I don't see the irq handler will use this spinlock anywhere in this c file.
>
> Yes, there is no chance the PHY users could call the phy ops from within
> an interrupt context. Especially now when there is a per phy object
> mutex used in the PHY operation helpers. So I'll replace it with plain
> spin_lock/unlock. Thank you for the review.
Now that PHY ops is already protected, do you really need a spin_lock here?
Thanks
Kishon
^ permalink raw reply
* Re: imx-drm does not report correct info in fbset
From: Fabio Estevam @ 2013-06-28 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130628174916.GG4283@n2100.arm.linux.org.uk>
On Fri, Jun 28, 2013 at 2:49 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> What do you think is missing? This is what gets reported on my laptop:
>
> mode "1280x800"
> geometry 1280 800 1280 1024 32
> timings 0 0 0 0 0 0 0
> accel true
> rgba 8/16,8/8,8/0,0/0
> endmode
Yes, just saw the same on my PC.
I was thinking that the 'timings' line should show the correct display timings.
So the mx53 board is behaving the same as my laptop with regards to
'fbset' output.
> DRM doesn't provide full information via fbdev - its fbdev is just a
> compatibility later nothing more.
Ok, understood.
Thanks,
Fabio Estevam
^ permalink raw reply
* Re: imx-drm does not report correct info in fbset
From: Russell King - ARM Linux @ 2013-06-28 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5A=JSHJrkXwXkYYxbkjtcFv3NU5W6F4hSb5Y7ZrpKij=A@mail.gmail.com>
On Fri, Jun 28, 2013 at 02:28:22PM -0300, Fabio Estevam wrote:
> Hi Philipp/Sascha,
>
> When I enable the parallel display on a mx53qsb, I noticed that fbset
> does not report the correct information:
>
> mode "800x480-0"
> # D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
> geometry 800 480 800 480 16
> timings 0 0 0 0 0 0 0
> accel true
> rgba 5/11,6/5,5/0,0/0
> endmode
What do you think is missing? This is what gets reported on my laptop:
mode "1280x800"
geometry 1280 800 1280 1024 32
timings 0 0 0 0 0 0 0
accel true
rgba 8/16,8/8,8/0,0/0
endmode
DRM doesn't provide full information via fbdev - its fbdev is just a
compatibility later nothing more.
^ permalink raw reply
* Re[2]: imx-drm does not report correct info in fbset
From: Alexander Shiyan @ 2013-06-28 17:47 UTC (permalink / raw)
To: linux-fbdev
PiBPbiBGcmksIEp1biAyOCwgMjAxMyBhdCAyOjI4IFBNLCBGYWJpbyBFc3RldmFtIDxmZXN0ZXZh
bUBnbWFpbC5jb20+IHdyb3RlOgo+ID4gSGkgUGhpbGlwcC9TYXNjaGEsCj4gPgo+ID4gV2hlbiBJ
IGVuYWJsZSB0aGUgcGFyYWxsZWwgZGlzcGxheSBvbiBhIG14NTNxc2IsIEkgbm90aWNlZCB0aGF0
IGZic2V0Cj4gPiBkb2VzIG5vdCByZXBvcnQgdGhlIGNvcnJlY3QgaW5mb3JtYXRpb246Cj4gPgo+
ID4gbW9kZSAiODAweDQ4MC0wIgo+ID4gICAgICAgICAjIEQ6IDAuMDAwIE1IeiwgSDogMC4wMDAg
a0h6LCBWOiAwLjAwMCBIego+ID4gICAgICAgICBnZW9tZXRyeSA4MDAgNDgwIDgwMCA0ODAgMTYK
PiA+ICAgICAgICAgdGltaW5ncyAwIDAgMCAwIDAgMCAwCj4gCj4gT2ssIGp1c3QgcmVhbGl6ZWQg
dGhhdCBteSBob3N0IFBDIHJlcG9ydHMgdGhlIHNhbWUgaW4gdGhlICd0aW1pbmdzJyBsaW5lLgo+
IAo+IFNvIG5vdCBhbiBpc3N1ZSB3aXRoIHRoZSBpbXgtZHJtIGRyaXZlciB0aGVuLgoKIjgwMHg0
ODAtMCIKTW9kZSBzaG91bGQgY29udGFpbiB2ZXJ0aWNhbCBmcmVxdWVuY3ksIGxpa2UgODAweDQ4
MC01MC4KWmVybyBpcyBub3QgdmFsaWQgaGVyZSwgaXMgbm90IGl0PwoKLS0tCg=
^ permalink raw reply
* Re: imx-drm does not report correct info in fbset
From: Fabio Estevam @ 2013-06-28 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5A=JSHJrkXwXkYYxbkjtcFv3NU5W6F4hSb5Y7ZrpKij=A@mail.gmail.com>
On Fri, Jun 28, 2013 at 2:28 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Philipp/Sascha,
>
> When I enable the parallel display on a mx53qsb, I noticed that fbset
> does not report the correct information:
>
> mode "800x480-0"
> # D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
> geometry 800 480 800 480 16
> timings 0 0 0 0 0 0 0
Ok, just realized that my host PC reports the same in the 'timings' line.
So not an issue with the imx-drm driver then.
Regards,
Fabio Estevam
^ permalink raw reply
* possible circular locking dependency in efifb
From: Alexandra N. Kossovsky @ 2013-06-28 17:34 UTC (permalink / raw)
To: linux-fbdev
Kernel 3.9.6 with lockdep prints following:
[ 600.453133] ===========================
[ 600.453133] [ INFO: possible circular locking dependency detected ]
[ 600.453134] 3.9.6-1-debug-amd64 #1 Tainted: G W O
[ 600.453135] -------------------------------------------------------
[ 600.453135] kworker/0:0/4 is trying to acquire lock:
[ 600.453140] (&fb_info->lock){+.+.+.}, at: [<ffffffff81242e88>] lock_fb_info+0x18/0x37
[ 600.453141]
[ 600.453141] but task is already holding lock:
[ 600.453144] (console_lock){+.+.+.}, at: [<ffffffff812ae160>] console_callback+0xa/0xf3
[ 600.453144]
[ 600.453144] which lock already depends on the new lock.
[ 600.453144]
[ 600.453144]
[ 600.453144] the existing dependency chain (in reverse order) is:
[ 600.453145]
[ 600.453145] -> #1 (console_lock){+.+.+.}:
[ 600.453148] [<ffffffff81092274>] lock_acquire+0x10a/0x15f
[ 600.453150] [<ffffffff81044551>] console_lock+0x69/0x6b
[ 600.453151] [<ffffffff81243c57>] register_framebuffer+0x201/0x278
[ 600.453153] [<ffffffff81af4aea>] efifb_probe+0x408/0x48f
[ 600.453156] [<ffffffff812cd81c>] platform_drv_probe+0x34/0x5e
[ 600.453157] [<ffffffff812cc00d>] driver_probe_device+0x98/0x1b1
[ 600.453159] [<ffffffff812cc174>] __driver_attach+0x4e/0x6f
[ 600.453160] [<ffffffff812ca7bf>] bus_for_each_dev+0x57/0x8a
[ 600.453161] [<ffffffff812cbb2c>] driver_attach+0x19/0x1b
[ 600.453162] [<ffffffff812cb7d0>] bus_add_driver+0xde/0x201
[ 600.453164] [<ffffffff812cc6db>] driver_register+0x8c/0x110
[ 600.453165] [<ffffffff812cd2b1>] platform_driver_register+0x41/0x43
[ 600.453167] [<ffffffff812cd2cb>] platform_driver_probe+0x18/0x8a
[ 600.453168] [<ffffffff81af46c3>] efifb_init+0x276/0x295
[ 600.453170] [<ffffffff810020b4>] do_one_initcall+0x7a/0x136
[ 600.453172] [<ffffffff81ac7ecf>] kernel_init_freeable+0x13f/0x1cc
[ 600.453174] [<ffffffff813de02a>] kernel_init+0x9/0xd6
[ 600.453177] [<ffffffff814005bc>] ret_from_fork+0x7c/0xb0
[ 600.453178]
[ 600.453178] -> #0 (&fb_info->lock){+.+.+.}:
[ 600.453179] [<ffffffff81091a17>] __lock_acquire+0xa64/0xdc0
[ 600.453180] [<ffffffff81092274>] lock_acquire+0x10a/0x15f
[ 600.453182] [<ffffffff813f81b7>] __mutex_lock_common+0x5d/0x371
[ 600.453183] [<ffffffff813f85c6>] mutex_lock_nested+0x3b/0x40
[ 600.453184] [<ffffffff81242e88>] lock_fb_info+0x18/0x37
[ 600.453185] [<ffffffff8124cab2>] fbcon_blank+0x168/0x1ee
[ 600.453187] [<ffffffff812abc46>] do_blank_screen+0x13e/0x1d8
[ 600.453188] [<ffffffff812ae220>] console_callback+0xca/0xf3
[ 600.453190] [<ffffffff8105d4b3>] process_one_work+0x249/0x416
[ 600.453191] [<ffffffff8105dea6>] worker_thread+0x121/0x1ce
[ 600.453193] [<ffffffff81065b2d>] kthread+0xac/0xb4
[ 600.453194] [<ffffffff814005bc>] ret_from_fork+0x7c/0xb0
[ 600.453194]
[ 600.453194] other info that might help us debug this:
[ 600.453194]
[ 600.453195] Possible unsafe locking scenario:
[ 600.453195]
[ 600.453195] CPU0 CPU1
[ 600.453195] ---- ----
[ 600.453196] lock(console_lock);
[ 600.453197] lock(&fb_info->lock);
[ 600.453197] lock(console_lock);
[ 600.453198] lock(&fb_info->lock);
[ 600.453198]
[ 600.453198] *** DEADLOCK ***
[ 600.453198]
[ 600.453199] 3 locks held by kworker/0:0/4:
[ 600.453201] #0: (events){.+.+.+}, at: [<ffffffff8105d3e9>] process_one_work+0x17f/0x416
[ 600.453203] #1: (console_work){+.+...}, at: [<ffffffff8105d3e9>] process_one_work+0x17f/0x416
[ 600.453205] #2: (console_lock){+.+.+.}, at: [<ffffffff812ae160>] console_callback+0xa/0xf3
[ 600.453205]
[ 600.453205] stack backtrace:
[ 600.453206] Pid: 4, comm: kworker/0:0 Tainted: G W O 3.9.6-1-debug-amd64 #1
[ 600.453206] Call Trace:
[ 600.453209] [<ffffffff813f39d3>] print_circular_bug+0x1f6/0x204
[ 600.453211] [<ffffffff81091a17>] __lock_acquire+0xa64/0xdc0
[ 600.453212] [<ffffffff81092274>] lock_acquire+0x10a/0x15f
[ 600.453213] [<ffffffff81242e88>] ? lock_fb_info+0x18/0x37
[ 600.453214] [<ffffffff813f81b7>] __mutex_lock_common+0x5d/0x371
[ 600.453216] [<ffffffff81242e88>] ? lock_fb_info+0x18/0x37
[ 600.453217] [<ffffffff81242e88>] ? lock_fb_info+0x18/0x37
[ 600.453218] [<ffffffff8108f45d>] ? lock_is_held+0x4e/0x5f
[ 600.453219] [<ffffffff813f85c6>] mutex_lock_nested+0x3b/0x40
[ 600.453220] [<ffffffff81242e88>] lock_fb_info+0x18/0x37
[ 600.453221] [<ffffffff8124cab2>] fbcon_blank+0x168/0x1ee
[ 600.453223] [<ffffffff810926d2>] ? trace_hardirqs_on_caller+0x117/0x173
[ 600.453224] [<ffffffff813fa6a5>] ? _raw_spin_unlock_irqrestore+0x48/0x5c
[ 600.453226] [<ffffffff81052285>] ? try_to_del_timer_sync+0x5c/0x67
[ 600.453228] [<ffffffff812abc46>] do_blank_screen+0x13e/0x1d8
[ 600.453229] [<ffffffff812ae220>] console_callback+0xca/0xf3
[ 600.453230] [<ffffffff8105d4b3>] process_one_work+0x249/0x416
[ 600.453231] [<ffffffff8105d3e9>] ? process_one_work+0x17f/0x416
[ 600.453232] [<ffffffff8105dea6>] worker_thread+0x121/0x1ce
[ 600.453233] [<ffffffff8105dd85>] ? manage_workers+0x23c/0x23c
[ 600.453234] [<ffffffff81065b2d>] kthread+0xac/0xb4
[ 600.453235] [<ffffffff81065a81>] ? __kthread_parkme+0x60/0x60
[ 600.453237] [<ffffffff814005bc>] ret_from_fork+0x7c/0xb0
[ 600.453238] [<ffffffff81065a81>] ? __kthread_parkme+0x60/0x60
Feel free to ask me to try a patch or another kernel version.
--
Alexandra N. Kossovsky
OKTET Labs (http://www.oktetlabs.ru/)
e-mail: sasha@oktetlabs.ru
^ permalink raw reply
* imx-drm does not report correct info in fbset
From: Fabio Estevam @ 2013-06-28 17:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi Philipp/Sascha,
When I enable the parallel display on a mx53qsb, I noticed that fbset
does not report the correct information:
mode "800x480-0"
# D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
geometry 800 480 800 480 16
timings 0 0 0 0 0 0 0
accel true
rgba 5/11,6/5,5/0,0/0
endmode
I haven't started debugging this, but just would like to check if this
is a known issue with the imx-drm driver.
Thanks,
Fabio Estevam
^ permalink raw reply
* Re: pmag-aa-fb
From: Maciej W. Rozycki @ 2013-06-28 14:11 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux MIPS Mailing List, Linux Fbdev development list
In-Reply-To: <CAMuHMdUfXUJTZ3fjMPicE1Z9D1mT4h-OzCfmCwBtppcK-3z01g@mail.gmail.com>
On Wed, 26 Jun 2013, Geert Uytterhoeven wrote:
> While investigating the users of (now static) fb_display, I noticed
> the DECstation
> PMAG AA frame buffer driver suffers from serious bit rot:
>
> drivers/video/pmag-aa-fb.c:38:24: error: asm/dec/tc.h: No such file or directory
> drivers/video/pmag-aa-fb.c:40:25: error: video/fbcon.h: No such file
> or directory
> drivers/video/pmag-aa-fb.c:41:30: error: video/fbcon-cfb8.h: No such
> file or directory
> drivers/video/pmag-aa-fb.c:86: error: field ‘disp’ has incomplete type
> drivers/video/pmag-aa-fb.c: In function ‘aafbcon_cursor’:
> drivers/video/pmag-aa-fb.c:118: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:121: error: implicit declaration of
> function ‘fontwidth’
> drivers/video/pmag-aa-fb.c:122: error: implicit declaration of
> function ‘fontheight’
> drivers/video/pmag-aa-fb.c:130: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:131: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c: In function ‘aafbcon_set_font’:
> drivers/video/pmag-aa-fb.c:150: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:152: error: implicit declaration of
> function ‘attr_bgcol_ec’
> drivers/video/pmag-aa-fb.c:152: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c: At top level:
> drivers/video/pmag-aa-fb.c:208: error: variable ‘aafb_switch8’ has
> initializer but incomplete type
> drivers/video/pmag-aa-fb.c:209: error: unknown field ‘setup’ specified
> in initializer
> drivers/video/pmag-aa-fb.c:209: error: ‘fbcon_cfb8_setup’ undeclared
> here (not in a function)
> drivers/video/pmag-aa-fb.c:209: warning: excess elements in struct initializer
> drivers/video/pmag-aa-fb.c:209: warning: (near initialization for
> ‘aafb_switch8’)
> drivers/video/pmag-aa-fb.c:210: error: unknown field ‘bmove’ specified
> in initializer
> drivers/video/pmag-aa-fb.c:210: error: ‘fbcon_cfb8_bmove’ undeclared
> here (not in a function)
> drivers/video/pmag-aa-fb.c:210: warning: excess elements in struct initializer
> drivers/video/pmag-aa-fb.c:210: warning: (near initialization for
> ‘aafb_switch8’)
> drivers/video/pmag-aa-fb.c:211: error: unknown field ‘clear’ specified
> in initializer
> drivers/video/pmag-aa-fb.c:211: error: ‘fbcon_cfb8_clear’ undeclared
> here (not in a function)
> drivers/video/pmag-aa-fb.c:211: warning: excess elements in struct initializer
> drivers/video/pmag-aa-fb.c:211: warning: (near initialization for
> ‘aafb_switch8’)
> drivers/video/pmag-aa-fb.c:212: error: unknown field ‘putc’ specified
> in initializer
> drivers/video/pmag-aa-fb.c:212: error: ‘fbcon_cfb8_putc’ undeclared
> here (not in a function)
> drivers/video/pmag-aa-fb.c:212: warning: excess elements in struct initializer
> drivers/video/pmag-aa-fb.c:212: warning: (near initialization for
> ‘aafb_switch8’)
> drivers/video/pmag-aa-fb.c:213: error: unknown field ‘putcs’ specified
> in initializer
> drivers/video/pmag-aa-fb.c:213: error: ‘fbcon_cfb8_putcs’ undeclared
> here (not in a function)
> drivers/video/pmag-aa-fb.c:213: warning: excess elements in struct initializer
> drivers/video/pmag-aa-fb.c:213: warning: (near initialization for
> ‘aafb_switch8’)
> drivers/video/pmag-aa-fb.c:214: error: unknown field ‘revc’ specified
> in initializer
> drivers/video/pmag-aa-fb.c:214: error: ‘fbcon_cfb8_revc’ undeclared
> here (not in a function)
> drivers/video/pmag-aa-fb.c:214: warning: excess elements in struct initializer
> drivers/video/pmag-aa-fb.c:214: warning: (near initialization for
> ‘aafb_switch8’)
> drivers/video/pmag-aa-fb.c:215: error: unknown field ‘cursor’
> specified in initializer
> drivers/video/pmag-aa-fb.c:215: warning: excess elements in struct initializer
> drivers/video/pmag-aa-fb.c:215: warning: (near initialization for
> ‘aafb_switch8’)
> drivers/video/pmag-aa-fb.c:216: error: unknown field ‘set_font’
> specified in initializer
> drivers/video/pmag-aa-fb.c:216: warning: excess elements in struct initializer
> drivers/video/pmag-aa-fb.c:216: warning: (near initialization for
> ‘aafb_switch8’)
> drivers/video/pmag-aa-fb.c:217: error: unknown field ‘clear_margins’
> specified in initializer
> drivers/video/pmag-aa-fb.c:217: error: ‘fbcon_cfb8_clear_margins’
> undeclared here (not in a function)
> drivers/video/pmag-aa-fb.c:217: warning: excess elements in struct initializer
> drivers/video/pmag-aa-fb.c:217: warning: (near initialization for
> ‘aafb_switch8’)
> drivers/video/pmag-aa-fb.c:218: error: unknown field ‘fontwidthmask’
> specified in initializer
> drivers/video/pmag-aa-fb.c:218: error: implicit declaration of
> function ‘FONTWIDTH’
> drivers/video/pmag-aa-fb.c:219: warning: excess elements in struct initializer
> drivers/video/pmag-aa-fb.c:219: warning: (near initialization for
> ‘aafb_switch8’)
> drivers/video/pmag-aa-fb.c: In function ‘aafb_set_disp’:
> drivers/video/pmag-aa-fb.c:250: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:251: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:252: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:252: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:252: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:253: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:253: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:254: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:255: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:258: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:259: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:260: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:261: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:262: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:263: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:264: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:265: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:266: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:267: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:268: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:268: error: ‘SCROLL_YREDRAW’ undeclared
> (first use in this function)
> drivers/video/pmag-aa-fb.c:268: error: (Each undeclared identifier is
> reported only once
> drivers/video/pmag-aa-fb.c:268: error: for each function it appears in.)
> drivers/video/pmag-aa-fb.c: In function ‘aafb_get_cmap’:
> drivers/video/pmag-aa-fb.c:279: error: too many arguments to function
> ‘fb_copy_cmap’
> drivers/video/pmag-aa-fb.c: In function ‘aafb_switch’:
> drivers/video/pmag-aa-fb.c:308: error: ‘fb_display’ undeclared (first
> use in this function)
> drivers/video/pmag-aa-fb.c:311: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:311: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:311: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:312: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c:312: error: dereferencing pointer to incomplete type
> drivers/video/pmag-aa-fb.c: In function ‘aafb_update_var’:
> drivers/video/pmag-aa-fb.c:381: error: ‘fb_display’ undeclared (first
> use in this function)
> drivers/video/pmag-aa-fb.c: At top level:
> drivers/video/pmag-aa-fb.c:402: error: unknown field ‘fb_get_fix’
> specified in initializer
> drivers/video/pmag-aa-fb.c:402: warning: initialization from
> incompatible pointer type
> drivers/video/pmag-aa-fb.c:403: error: unknown field ‘fb_get_var’
> specified in initializer
> drivers/video/pmag-aa-fb.c:403: warning: initialization from
> incompatible pointer type
> drivers/video/pmag-aa-fb.c:404: error: unknown field ‘fb_set_var’
> specified in initializer
> drivers/video/pmag-aa-fb.c:404: warning: initialization from
> incompatible pointer type
> drivers/video/pmag-aa-fb.c:405: error: unknown field ‘fb_get_cmap’
> specified in initializer
> drivers/video/pmag-aa-fb.c:405: warning: initialization from
> incompatible pointer type
> drivers/video/pmag-aa-fb.c:406: error: unknown field ‘fb_set_cmap’
> specified in initializer
> drivers/video/pmag-aa-fb.c:406: warning: initialization from
> incompatible pointer type
> drivers/video/pmag-aa-fb.c: In function ‘init_one’:
> drivers/video/pmag-aa-fb.c:412: error: implicit declaration of
> function ‘get_tc_base_addr’
> drivers/video/pmag-aa-fb.c:430: error: ‘struct fb_info’ has no member
> named ‘modename’
> drivers/video/pmag-aa-fb.c:434: error: ‘struct fb_info’ has no member
> named ‘disp’
> drivers/video/pmag-aa-fb.c:435: error: ‘struct fb_info’ has no member
> named ‘changevar’
> drivers/video/pmag-aa-fb.c:436: error: ‘struct fb_info’ has no member
> named ‘switch_con’
> drivers/video/pmag-aa-fb.c:437: error: ‘struct fb_info’ has no member
> named ‘updatevar’
> drivers/video/pmag-aa-fb.c:438: error: ‘struct fb_info’ has no member
> named ‘blank’
> drivers/video/pmag-aa-fb.c:462: error: implicit declaration of
> function ‘GET_FB_IDX’
> drivers/video/pmag-aa-fb.c:462: error: ‘struct fb_info’ has no member
> named ‘modename’
> drivers/video/pmag-aa-fb.c: In function ‘pmagaafb_init’:
> drivers/video/pmag-aa-fb.c:485: error: implicit declaration of
> function ‘search_tc_card’
> drivers/video/pmag-aa-fb.c:487: error: implicit declaration of
> function ‘claim_tc_card’
> drivers/video/pmag-aa-fb.c: In function ‘pmagaafb_exit’:
> drivers/video/pmag-aa-fb.c:500: error: implicit declaration of
> function ‘release_tc_card’
>
> search_tc_card() was removed in in 2007 in commit
> b454cc6636d254fbf6049b73e9560aee76fb04a3 ("[TC] MIPS: TURBOchannel
> update to the driver model").
>
> include/video/fbcon.h was moved to drivers/video/console/fbcon.h in ... 2002.
>
> Anyone who cares to resurrect it? If not, we should just remove it.
I'll have a look, thanks for the heads-up. Not a card I usually use -- I
wonder if I've got a patch somewhere that I forgot to post while rewriting
TURBOchannel support though.
Maciej
^ permalink raw reply
* [PATCH v4 5/5] ARM: Samsung: Remove the MIPI PHY setup code
From: Sylwester Nawrocki @ 2013-06-28 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372426991-2482-1-git-send-email-s.nawrocki@samsung.com>
Generic PHY drivers are used to handle the MIPI CSIS and MIPI DSIM
DPHYs so we can remove now unused code at arch/arm/plat-samsung.
In case there is any board file for S5PV210 platforms using MIPI
CSIS/DSIM (not any upstream currently) it should use the generic
PHY API to bind the PHYs to respective PHY consumer drivers and
a platform device for the PHY provider should be defined.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
---
arch/arm/mach-exynos/include/mach/regs-pmu.h | 5 --
arch/arm/mach-s5pv210/include/mach/regs-clock.h | 4 --
arch/arm/plat-samsung/Kconfig | 5 --
arch/arm/plat-samsung/Makefile | 1 -
arch/arm/plat-samsung/setup-mipiphy.c | 60 -----------------------
5 files changed, 75 deletions(-)
delete mode 100644 arch/arm/plat-samsung/setup-mipiphy.c
diff --git a/arch/arm/mach-exynos/include/mach/regs-pmu.h b/arch/arm/mach-exynos/include/mach/regs-pmu.h
index 57344b7..2cdb63e 100644
--- a/arch/arm/mach-exynos/include/mach/regs-pmu.h
+++ b/arch/arm/mach-exynos/include/mach/regs-pmu.h
@@ -44,11 +44,6 @@
#define S5P_DAC_PHY_CONTROL S5P_PMUREG(0x070C)
#define S5P_DAC_PHY_ENABLE (1 << 0)
-#define S5P_MIPI_DPHY_CONTROL(n) S5P_PMUREG(0x0710 + (n) * 4)
-#define S5P_MIPI_DPHY_ENABLE (1 << 0)
-#define S5P_MIPI_DPHY_SRESETN (1 << 1)
-#define S5P_MIPI_DPHY_MRESETN (1 << 2)
-
#define S5P_INFORM0 S5P_PMUREG(0x0800)
#define S5P_INFORM1 S5P_PMUREG(0x0804)
#define S5P_INFORM2 S5P_PMUREG(0x0808)
diff --git a/arch/arm/mach-s5pv210/include/mach/regs-clock.h b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
index 032de66..e345584 100644
--- a/arch/arm/mach-s5pv210/include/mach/regs-clock.h
+++ b/arch/arm/mach-s5pv210/include/mach/regs-clock.h
@@ -147,10 +147,6 @@
#define S5P_HDMI_PHY_CONTROL S5P_CLKREG(0xE804)
#define S5P_USB_PHY_CONTROL S5P_CLKREG(0xE80C)
#define S5P_DAC_PHY_CONTROL S5P_CLKREG(0xE810)
-#define S5P_MIPI_DPHY_CONTROL(x) S5P_CLKREG(0xE814)
-#define S5P_MIPI_DPHY_ENABLE (1 << 0)
-#define S5P_MIPI_DPHY_SRESETN (1 << 1)
-#define S5P_MIPI_DPHY_MRESETN (1 << 2)
#define S5P_INFORM0 S5P_CLKREG(0xF000)
#define S5P_INFORM1 S5P_CLKREG(0xF004)
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index b21d9d5..60f6337 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -388,11 +388,6 @@ config S3C24XX_PWM
Support for exporting the PWM timer blocks via the pwm device
system
-config S5P_SETUP_MIPIPHY
- bool
- help
- Compile in common setup code for MIPI-CSIS and MIPI-DSIM devices
-
config S3C_SETUP_CAMIF
bool
help
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 5d7f839..0db786e 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -38,7 +38,6 @@ obj-$(CONFIG_S5P_DEV_UART) += s5p-dev-uart.o
obj-$(CONFIG_SAMSUNG_DEV_BACKLIGHT) += dev-backlight.o
obj-$(CONFIG_S3C_SETUP_CAMIF) += setup-camif.o
-obj-$(CONFIG_S5P_SETUP_MIPIPHY) += setup-mipiphy.o
# DMA support
diff --git a/arch/arm/plat-samsung/setup-mipiphy.c b/arch/arm/plat-samsung/setup-mipiphy.c
deleted file mode 100644
index 66df315..0000000
--- a/arch/arm/plat-samsung/setup-mipiphy.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * Copyright (C) 2011 Samsung Electronics Co., Ltd.
- *
- * S5P - Helper functions for MIPI-CSIS and MIPI-DSIM D-PHY control
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/export.h>
-#include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <linux/io.h>
-#include <linux/spinlock.h>
-#include <mach/regs-clock.h>
-
-static int __s5p_mipi_phy_control(int id, bool on, u32 reset)
-{
- static DEFINE_SPINLOCK(lock);
- void __iomem *addr;
- unsigned long flags;
- u32 cfg;
-
- id = max(0, id);
- if (id > 1)
- return -EINVAL;
-
- addr = S5P_MIPI_DPHY_CONTROL(id);
-
- spin_lock_irqsave(&lock, flags);
-
- cfg = __raw_readl(addr);
- cfg = on ? (cfg | reset) : (cfg & ~reset);
- __raw_writel(cfg, addr);
-
- if (on) {
- cfg |= S5P_MIPI_DPHY_ENABLE;
- } else if (!(cfg & (S5P_MIPI_DPHY_SRESETN |
- S5P_MIPI_DPHY_MRESETN) & ~reset)) {
- cfg &= ~S5P_MIPI_DPHY_ENABLE;
- }
-
- __raw_writel(cfg, addr);
- spin_unlock_irqrestore(&lock, flags);
-
- return 0;
-}
-
-int s5p_csis_phy_enable(int id, bool on)
-{
- return __s5p_mipi_phy_control(id, on, S5P_MIPI_DPHY_SRESETN);
-}
-EXPORT_SYMBOL(s5p_csis_phy_enable);
-
-int s5p_dsim_phy_enable(struct platform_device *pdev, bool on)
-{
- return __s5p_mipi_phy_control(pdev->id, on, S5P_MIPI_DPHY_MRESETN);
-}
-EXPORT_SYMBOL(s5p_dsim_phy_enable);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 4/5] [media] exynos4-is: Use the generic MIPI CSIS PHY driver
From: Sylwester Nawrocki @ 2013-06-28 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372426991-2482-1-git-send-email-s.nawrocki@samsung.com>
Use the generic PHY API instead of the platform callback to control
the MIPI CSIS DPHY. The 'phy_label' field is added to the platform
data structure to allow PHY lookup on non-dt platforms
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
drivers/media/platform/exynos4-is/mipi-csis.c | 16 +++++++++++++---
include/linux/platform_data/mipi-csis.h | 11 ++---------
2 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
index a2eda9d..8436254 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -20,6 +20,7 @@
#include <linux/memory.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/phy/phy.h>
#include <linux/platform_data/mipi-csis.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
@@ -167,6 +168,7 @@ struct csis_pktbuf {
* @sd: v4l2_subdev associated with CSIS device instance
* @index: the hardware instance index
* @pdev: CSIS platform device
+ * @phy: pointer to the CSIS generic PHY
* @regs: mmaped I/O registers memory
* @supplies: CSIS regulator supplies
* @clock: CSIS clocks
@@ -189,6 +191,8 @@ struct csis_state {
struct v4l2_subdev sd;
u8 index;
struct platform_device *pdev;
+ struct phy *phy;
+ const char *phy_label;
void __iomem *regs;
struct regulator_bulk_data supplies[CSIS_NUM_SUPPLIES];
struct clk *clock[NUM_CSIS_CLOCKS];
@@ -726,6 +730,7 @@ static int s5pcsis_get_platform_data(struct platform_device *pdev,
state->index = max(0, pdev->id);
state->max_num_lanes = state->index ? CSIS1_MAX_LANES :
CSIS0_MAX_LANES;
+ state->phy_label = pdata->phy_label;
return 0;
}
@@ -763,8 +768,9 @@ static int s5pcsis_parse_dt(struct platform_device *pdev,
"samsung,csis-wclk");
state->num_lanes = endpoint.bus.mipi_csi2.num_data_lanes;
-
of_node_put(node);
+
+ state->phy_label = "csis";
return 0;
}
#else
@@ -800,6 +806,10 @@ static int s5pcsis_probe(struct platform_device *pdev)
return -EINVAL;
}
+ state->phy = devm_phy_get(dev, state->phy_label);
+ if (IS_ERR(state->phy))
+ return PTR_ERR(state->phy);
+
mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
state->regs = devm_ioremap_resource(dev, mem_res);
if (IS_ERR(state->regs))
@@ -893,7 +903,7 @@ static int s5pcsis_pm_suspend(struct device *dev, bool runtime)
mutex_lock(&state->lock);
if (state->flags & ST_POWERED) {
s5pcsis_stop_stream(state);
- ret = s5p_csis_phy_enable(state->index, false);
+ ret = phy_power_off(state->phy);
if (ret)
goto unlock;
ret = regulator_bulk_disable(CSIS_NUM_SUPPLIES,
@@ -929,7 +939,7 @@ static int s5pcsis_pm_resume(struct device *dev, bool runtime)
state->supplies);
if (ret)
goto unlock;
- ret = s5p_csis_phy_enable(state->index, true);
+ ret = phy_power_on(state->phy);
if (!ret) {
state->flags |= ST_POWERED;
} else {
diff --git a/include/linux/platform_data/mipi-csis.h b/include/linux/platform_data/mipi-csis.h
index bf34e17..9214317 100644
--- a/include/linux/platform_data/mipi-csis.h
+++ b/include/linux/platform_data/mipi-csis.h
@@ -17,21 +17,14 @@
* @wclk_source: CSI wrapper clock selection: 0 - bus clock, 1 - ext. SCLK_CAM
* @lanes: number of data lanes used
* @hs_settle: HS-RX settle time
+ * @phy_label: the generic PHY label
*/
struct s5p_platform_mipi_csis {
unsigned long clk_rate;
u8 wclk_source;
u8 lanes;
u8 hs_settle;
+ const char *phy_label;
};
-/**
- * s5p_csis_phy_enable - global MIPI-CSI receiver D-PHY control
- * @id: MIPI-CSIS harware instance index (0...1)
- * @on: true to enable D-PHY and deassert its reset
- * false to disable D-PHY
- * @return: 0 on success, or negative error code on failure
- */
-int s5p_csis_phy_enable(int id, bool on);
-
#endif /* __PLAT_SAMSUNG_MIPI_CSIS_H_ */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 3/5] video: exynos_mipi_dsim: Use the generic PHY driver
From: Sylwester Nawrocki @ 2013-06-28 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372426991-2482-1-git-send-email-s.nawrocki@samsung.com>
Use the generic PHY API instead of the platform callback to control
the MIPI DSIM DPHY. The 'phy_label' field is added to the platform
data structure to allow PHY lookup on non-dt platforms.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Donghwa Lee <dh09.lee@samsung.com>
---
drivers/video/exynos/exynos_mipi_dsi.c | 19 ++++++++++---------
include/video/exynos_mipi_dsim.h | 6 ++++--
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c
index 32e5406..248e444 100644
--- a/drivers/video/exynos/exynos_mipi_dsi.c
+++ b/drivers/video/exynos/exynos_mipi_dsi.c
@@ -30,6 +30,7 @@
#include <linux/interrupt.h>
#include <linux/kthread.h>
#include <linux/notifier.h>
+#include <linux/phy/phy.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
#include <linux/err.h>
@@ -156,8 +157,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power)
exynos_mipi_regulator_enable(dsim);
/* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, true);
+ phy_power_on(dsim->phy);
clk_enable(dsim->clock);
@@ -373,6 +373,10 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
return ret;
}
+ dsim->phy = devm_phy_get(&pdev->dev, dsim_pd->phy_label);
+ if (IS_ERR(dsim->phy))
+ return PTR_ERR(dsim->phy);
+
dsim->clock = devm_clk_get(&pdev->dev, "dsim0");
if (IS_ERR(dsim->clock)) {
dev_err(&pdev->dev, "failed to get dsim clock source\n");
@@ -439,8 +443,7 @@ static int exynos_mipi_dsi_probe(struct platform_device *pdev)
exynos_mipi_regulator_enable(dsim);
/* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, true);
+ phy_power_on(dsim->phy);
exynos_mipi_update_cfg(dsim);
@@ -504,9 +507,8 @@ static int exynos_mipi_dsi_suspend(struct device *dev)
if (client_drv && client_drv->suspend)
client_drv->suspend(client_dev);
- /* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, false);
+ /* disable MIPI-DSI PHY. */
+ phy_power_off(dsim->phy);
clk_disable(dsim->clock);
@@ -536,8 +538,7 @@ static int exynos_mipi_dsi_resume(struct device *dev)
exynos_mipi_regulator_enable(dsim);
/* enable MIPI-DSI PHY. */
- if (dsim->pd->phy_enable)
- dsim->pd->phy_enable(pdev, true);
+ phy_power_on(dsim->phy);
clk_enable(dsim->clock);
diff --git a/include/video/exynos_mipi_dsim.h b/include/video/exynos_mipi_dsim.h
index 89dc88a..fd69beb 100644
--- a/include/video/exynos_mipi_dsim.h
+++ b/include/video/exynos_mipi_dsim.h
@@ -216,6 +216,7 @@ struct mipi_dsim_config {
* automatically.
* @e_clk_src: select byte clock source.
* @pd: pointer to MIPI-DSI driver platform data.
+ * @phy: pointer to the generic PHY
*/
struct mipi_dsim_device {
struct device *dev;
@@ -236,6 +237,7 @@ struct mipi_dsim_device {
bool suspended;
struct mipi_dsim_platform_data *pd;
+ struct phy *phy;
};
/*
@@ -248,7 +250,7 @@ struct mipi_dsim_device {
* @enabled: indicate whether mipi controller got enabled or not.
* @lcd_panel_info: pointer for lcd panel specific structure.
* this structure specifies width, height, timing and polarity and so on.
- * @phy_enable: pointer to a callback controlling D-PHY enable/reset
+ * @phy_label: the generic PHY label
*/
struct mipi_dsim_platform_data {
char lcd_panel_name[PANEL_NAME_SIZE];
@@ -257,7 +259,7 @@ struct mipi_dsim_platform_data {
unsigned int enabled;
void *lcd_panel_info;
- int (*phy_enable)(struct platform_device *pdev, bool on);
+ const char *phy_label;
};
/*
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 2/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Sylwester Nawrocki @ 2013-06-28 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372426991-2482-1-git-send-email-s.nawrocki@samsung.com>
Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
receiver and MIPI DSI transmitter DPHYs.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
Changes since v3:
- replaced spin_(un)lock_irq_{save,restore} with spin_{lock,unlock}.
- DT binding file renamed to samsung-phy.txt, so it can be used for
other PHYs as well,
- removed <linux/delay.h> inclusion,
- added missing spin_lock_init().
---
.../devicetree/bindings/phy/samsung-phy.txt | 14 ++
drivers/phy/Kconfig | 9 ++
drivers/phy/Makefile | 3 +-
drivers/phy/phy-exynos-mipi-video.c | 169 ++++++++++++++++++++
4 files changed, 194 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/phy/samsung-phy.txt
create mode 100644 drivers/phy/phy-exynos-mipi-video.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
new file mode 100644
index 0000000..5ff208c
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -0,0 +1,14 @@
+Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be "samsung,s5pv210-mipi-video-phy";
+- reg : offset and length of the MIPI DPHY register set;
+- #phy-cells : from the generic phy bindings, must be 1;
+
+For "samsung,s5pv210-mipi-video-phy" compatible PHYs the second cell in
+the PHY specifier identifies the PHY and its meaning is as follows:
+ 0 - MIPI CSIS 0,
+ 1 - MIPI DSIM 0,
+ 2 - MIPI CSIS 1,
+ 3 - MIPI DSIM 1.
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 5f85909..6f446d0 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -11,3 +11,12 @@ menuconfig GENERIC_PHY
devices present in the kernel. This layer will have the generic
API by which phy drivers can create PHY using the phy framework and
phy users can obtain reference to the PHY.
+
+if GENERIC_PHY
+
+config PHY_EXYNOS_MIPI_VIDEO
+ tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver"
+ help
+ Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung
+ S5P and EXYNOS SoCs.
+endif
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 9e9560f..71d8841 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -2,4 +2,5 @@
# Makefile for the phy drivers.
#
-obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
diff --git a/drivers/phy/phy-exynos-mipi-video.c b/drivers/phy/phy-exynos-mipi-video.c
new file mode 100644
index 0000000..7e7fcd7
--- /dev/null
+++ b/drivers/phy/phy-exynos-mipi-video.c
@@ -0,0 +1,169 @@
+/*
+ * Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+
+/* MIPI_PHYn_CONTROL register offset: n = 0..1 */
+#define EXYNOS_MIPI_PHY_CONTROL(n) ((n) * 4)
+#define EXYNOS_MIPI_PHY_ENABLE (1 << 0)
+#define EXYNOS_MIPI_PHY_SRESETN (1 << 1)
+#define EXYNOS_MIPI_PHY_MRESETN (1 << 2)
+#define EXYNOS_MIPI_PHY_RESET_MASK (3 << 1)
+
+enum exynos_mipi_phy_id {
+ EXYNOS_MIPI_PHY_ID_CSIS0,
+ EXYNOS_MIPI_PHY_ID_DSIM0,
+ EXYNOS_MIPI_PHY_ID_CSIS1,
+ EXYNOS_MIPI_PHY_ID_DSIM1,
+ EXYNOS_MIPI_PHYS_NUM
+};
+
+#define IS_EXYNOS_MIPI_DSIM_PHY_ID(id) \
+ ((id) = EXYNOS_MIPI_PHY_ID_DSIM0 || (id) = EXYNOS_MIPI_PHY_ID_DSIM0)
+
+struct exynos_mipi_video_phy {
+ spinlock_t slock;
+ struct phy *phys[EXYNOS_MIPI_PHYS_NUM];
+ void __iomem *regs;
+};
+
+static int __set_phy_state(struct exynos_mipi_video_phy *state,
+ enum exynos_mipi_phy_id id, unsigned int on)
+{
+ void __iomem *addr;
+ u32 reg, reset;
+
+ addr = state->regs + EXYNOS_MIPI_PHY_CONTROL(id / 2);
+
+ if (IS_EXYNOS_MIPI_DSIM_PHY_ID(id))
+ reset = EXYNOS_MIPI_PHY_MRESETN;
+ else
+ reset = EXYNOS_MIPI_PHY_SRESETN;
+
+ spin_lock(&state->slock);
+ reg = readl(addr);
+ if (on)
+ reg |= reset;
+ else
+ reg &= ~reset;
+ writel(reg, addr);
+
+ /* Clear ENABLE bit only if MRESETN, SRESETN bits are not set. */
+ if (on)
+ reg |= EXYNOS_MIPI_PHY_ENABLE;
+ else if (!(reg & EXYNOS_MIPI_PHY_RESET_MASK))
+ reg &= ~EXYNOS_MIPI_PHY_ENABLE;
+
+ writel(reg, addr);
+ spin_unlock(&state->slock);
+ return 0;
+}
+
+static int exynos_mipi_video_phy_power_on(struct phy *phy)
+{
+ struct exynos_mipi_video_phy *state = phy_get_drvdata(phy);
+ return __set_phy_state(state, phy->id, 1);
+}
+
+static int exynos_mipi_video_phy_power_off(struct phy *phy)
+{
+ struct exynos_mipi_video_phy *state = phy_get_drvdata(phy);
+ return __set_phy_state(state, phy->id, 0);
+}
+
+static struct phy *exynos_mipi_video_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct exynos_mipi_video_phy *state = dev_get_drvdata(dev);
+
+ if (WARN_ON(args->args[0] > EXYNOS_MIPI_PHYS_NUM))
+ return ERR_PTR(-ENODEV);
+
+ return state->phys[args->args[0]];
+}
+
+static struct phy_ops exynos_mipi_video_phy_ops = {
+ .power_on = exynos_mipi_video_phy_power_on,
+ .power_off = exynos_mipi_video_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int exynos_mipi_video_phy_probe(struct platform_device *pdev)
+{
+ struct exynos_mipi_video_phy *state;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct phy_provider *phy_provider;
+ int i;
+
+ state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ state->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(state->regs))
+ return PTR_ERR(state->regs);
+
+ dev_set_drvdata(dev, state);
+ spin_lock_init(&state->slock);
+
+ phy_provider = devm_of_phy_provider_register(dev,
+ exynos_mipi_video_phy_xlate);
+ if (IS_ERR(phy_provider))
+ return PTR_ERR(phy_provider);
+
+ for (i = 0; i < EXYNOS_MIPI_PHYS_NUM; i++) {
+ char label[8];
+
+ snprintf(label, sizeof(label), "%s.%d",
+ IS_EXYNOS_MIPI_DSIM_PHY_ID(i) ?
+ "dsim" : "csis", i / 2);
+
+ state->phys[i] = devm_phy_create(dev, i,
+ &exynos_mipi_video_phy_ops, label);
+ if (IS_ERR(state->phys[i])) {
+ dev_err(dev, "failed to create PHY %s\n", label);
+ return PTR_ERR(state->phys[i]);
+ }
+ phy_set_drvdata(state->phys[i], state);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id exynos_mipi_video_phy_of_match[] = {
+ { .compatible = "samsung,s5pv210-mipi-video-phy" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, exynos_mipi_video_phy_of_match);
+
+static struct platform_driver exynos_mipi_video_phy_driver = {
+ .probe = exynos_mipi_video_phy_probe,
+ .driver = {
+ .of_match_table = exynos_mipi_video_phy_of_match,
+ .name = "exynos-mipi-video-phy",
+ .owner = THIS_MODULE,
+ }
+};
+module_platform_driver(exynos_mipi_video_phy_driver);
+
+MODULE_DESCRIPTION("Samsung S5P/EXYNOS SoC MIPI CSI-2/DSI PHY driver");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Sylwester Nawrocki <s.nawrocki@samsung.com>");
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 1/5] ARM: dts: Add MIPI PHY node to exynos4.dtsi
From: Sylwester Nawrocki @ 2013-06-28 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1372426991-2482-1-git-send-email-s.nawrocki@samsung.com>
Add PHY provider node for the MIPI CSIS and MIPI DSIM PHYs.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/boot/dts/exynos4.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 4d61120..1750511 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -49,6 +49,12 @@
reg = <0x10000000 0x100>;
};
+ mipi_phy: video-phy@10020710 {
+ compatible = "samsung,s5pv210-mipi-video-phy";
+ reg = <0x10020710 8>;
+ #phy-cells = <1>;
+ };
+
pd_mfc: mfc-power-domain@10023C40 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C40 0x20>;
@@ -147,6 +153,8 @@
interrupts = <0 78 0>;
bus-width = <4>;
samsung,power-domain = <&pd_cam>;
+ phys = <&mipi_phy 0>;
+ phy-names = "csis";
status = "disabled";
};
@@ -156,6 +164,8 @@
interrupts = <0 80 0>;
bus-width = <2>;
samsung,power-domain = <&pd_cam>;
+ phys = <&mipi_phy 2>;
+ phy-names = "csis";
status = "disabled";
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 0/5] Generic PHY driver for the Exynos SoC MIPI CSI-2/DSI DPHYs
From: Sylwester Nawrocki @ 2013-06-28 13:43 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds a simple driver for the Samsung S5P/Exynos SoC
series MIPI CSI-2 receiver (MIPI CSIS) and MIPI DSI transmitter (MIPI
DSIM) DPHYs, using the generic PHY framework [1]. Previously the MIPI
CSIS and MIPI DSIM used a platform callback to control the PHY power
enable and reset bits. The platform callback can now be dropped and
those drivers don't need any calls back to the platform code, which
makes migration to the device tree complete for MIPI CSIS.
Changes since v3 (only patch 1/5):
- replaced spin_(un)lock_irq_{save,restore} with spin_{lock,unlock}.
- DT binding file renamed to samsung-phy.txt, so it can be used for
other PHYs as well,
- removed <linux/delay.h> inclusion,
- added missing spin_lock_init().
Changes since v2:
- adapted to the generic PHY API v9: use phy_set/get_drvdata(),
- fixed of_xlate callback to return ERR_PTR() instead of NULL,
- namespace cleanup, put "GPL v2" as MODULE_LICENSE, removed pr_debug,
- removed phy id check in __set_phy_state().
Patches 2...3/5 are unchanged, description of patch 5/5 has been
updated.
Changes since v1:
- enabled build as module and with CONFIG_OF disabled,
- added phy_id enum,
- of_address_to_resource() replaced with platform_get_resource(),
- adapted to changes in the PHY API v7, v8 - added phy labels,
- added MODULE_DEVICE_TABLE() entry,
- the driver file renamed to phy-exynos-mipi-video.c,
- changed DT compatible string to "samsung,s5pv210-mipi-video-phy",
- corrected the compatible property's description.
- patch 3/5 "video: exynos_dsi: Use generic PHY driver" replaced
with a patch modifying the MIPI DSIM driver which is currently
in mainline.
This series depends on the generic PHY framework [1]. It can be browsed at:
http://git.linuxtv.org/snawrocki/samsung.git/exynos-mipi-phy
This branch is based on the 'for-next' branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
and the patch series:
http://www.spinics.net/lists/arm-kernel/msg254667.html
[1] https://lkml.org/lkml/2013/6/26/259
Sylwester Nawrocki (5):
ARM: dts: Add MIPI PHY node to exynos4.dtsi
phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
video: exynos_mipi_dsim: Use the generic PHY driver
[media] exynos4-is: Use the generic MIPI CSIS PHY driver
ARM: Samsung: Remove the MIPI PHY setup code
.../devicetree/bindings/phy/samsung-phy.txt | 14 ++
arch/arm/boot/dts/exynos4.dtsi | 10 ++
arch/arm/mach-exynos/include/mach/regs-pmu.h | 5 -
arch/arm/mach-s5pv210/include/mach/regs-clock.h | 4 -
arch/arm/plat-samsung/Kconfig | 5 -
arch/arm/plat-samsung/Makefile | 1 -
arch/arm/plat-samsung/setup-mipiphy.c | 60 -------
drivers/media/platform/exynos4-is/mipi-csis.c | 16 +-
drivers/phy/Kconfig | 9 ++
drivers/phy/Makefile | 3 +-
drivers/phy/phy-exynos-mipi-video.c | 169 ++++++++++++++++++++
drivers/video/exynos/exynos_mipi_dsi.c | 19 +--
include/linux/platform_data/mipi-csis.h | 11 +-
include/video/exynos_mipi_dsim.h | 6 +-
14 files changed, 233 insertions(+), 99 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/samsung-phy.txt
delete mode 100644 arch/arm/plat-samsung/setup-mipiphy.c
create mode 100644 drivers/phy/phy-exynos-mipi-video.c
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH V2 3/3] video: exynos_dp: Use the generic PHY driver
From: Sylwester Nawrocki @ 2013-06-28 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130628102702.GK305@game.jcrosoft.org>
Hi,
On 06/28/2013 12:27 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:35 Fri 28 Jun , Felipe Balbi wrote:
>> > On Fri, Jun 28, 2013 at 04:18:23PM +0900, Jingoo Han wrote:
>>> > > Use the generic PHY API instead of the platform callback to control
>>> > > the DP PHY. The 'phy_label' field is added to the platform data
>>> > > structure to allow PHY lookup on non-dt platforms.
>>> > >
>>> > > Signed-off-by: Jingoo Han <jg1.han@samsung.com>
>>> > > ---
[...]
>>> > > diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
>>> > > index 84f10c1..a8320e3 100644
>>> > > --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
>>> > > +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
>>> > > @@ -1,17 +1,6 @@
>>> > > The Exynos display port interface should be configured based on
>>> > > the type of panel connected to it.
>>> > >
>>> > > -We use two nodes:
>>> > > - -dp-controller node
>>> > > - -dptx-phy node(defined inside dp-controller node)
>>> > > -
>>> > > -For the DP-PHY initialization, we use the dptx-phy node.
>>> > > -Required properties for dptx-phy:
>>> > > - -reg:
>>> > > - Base address of DP PHY register.
>>> > > - -samsung,enable-mask:
>>> > > - The bit-mask used to enable/disable DP PHY.
>>> > > -
>>> > > For the Panel initialization, we read data from dp-controller node.
>>> > > Required properties for dp-controller:
>>> > > -compatible:
>>> > > @@ -67,12 +56,6 @@ SOC specific portion:
>>> > > interrupt-parent = <&combiner>;
>>> > > clocks = <&clock 342>;
>>> > > clock-names = "dp";
>>> > > -
>>> > > - dptx-phy {
>>> > > - reg = <0x10040720>;
>>> > > - samsung,enable-mask = <1>;
>>> > > - };
>
> I've an issue here you break dt compatibilty
Indeed. Ideally the PHYs should be detachable from the controllers.
I'd assume such a change could be acceptable, given that the driver
still supports the original binding.
--
Thanks,
Sylwester
^ permalink raw reply
* Re: [RFC 0/6] SimpleDRM Driver (was: dvbe driver)
From: David Herrmann @ 2013-06-28 10:43 UTC (permalink / raw)
To: Stephen Warren
Cc: dri-devel@lists.freedesktop.org, linux-kernel, Dave Airlie,
linux-fbdev, Stephen Warren, Olof Johansson
In-Reply-To: <51CB5D67.3090701@wwwdotorg.org>
Hi
On Wed, Jun 26, 2013 at 11:30 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 06/24/2013 04:27 PM, David Herrmann wrote:
>> Hi
>>
>> This is my second revision of the dvbe driver. I renamed it to SimpleDRM to
>> show the resemblence with the recently introduced simplefb.c fbdev driver. The
>> driver is supposed to be the most basic DRM driver similar to efifb.c, vesafb.c,
>> offb.c, simplefb.c, ...
>> It provides a single virtual CRTC+encoder+connector and allows user-space to
>> create one dumb-buffer at a time and attach it.
>>
>> The setup changed slightly. It no longer uses shadow buffers but instead maps
>> the framebuffer directly into userspace. Furthermore, a new infrastructure is
>> used to unload firmware drivers during real hardware drivers probe cycles. Only
>> nouveau was changed to use it, yet.
>>
>> I still have an odd problem when unloading DRM drivers (not just SimpleDRM) with
>> an fbdev fallback. If I call printk() directly after unregister_framebufer(), I
>> get a NULL-deref somewhere in the VT layer (most times hide_cursor()). I haven't
>> figured out exactly where that happens, but I am also very reluctant to spend
>> more time debugging the VT layer.
>
> I tested this on a Tegra ARM system, and it basically worked.
Thanks a lot for the feedback!
> I have one question: With the simplefb driver, and console=tty1 on the
> kernel command-line, I see both the penguins logo and Linux's boot
> messages on the LCD panel that's hooked up through simplefb. However,
> with simpledrm, I only see the penguins logo, but no boot messages. Is
> that expected? How would I solve that if so?
No idea what is going wrong there. Somehow the simpledrm-fbdev device
is not picked up as primary device. I only got a black-cursor on
black-background (visible if painting something else on the fb0
device). And I get NULL-derefs in cursor_hide() during unregistration.
I digged through fbcon.c to find out what's going wrong but without
any success. I will see what I can do.
However, X-server or other apps work perfectly fine with it.
> Note: I needed to apply the following patch to get it to compile:
>
> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> index 40a2696..39885c8 100644
> --- a/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> +++ b/drivers/gpu/drm/simpledrm/simpledrm_fbdev.c
> @@ -159,7 +159,7 @@ void sdrm_fbdev_cleanup(struct sdrm_device *sdrm)
> {
> struct fb_info *info;
>
> - if (!sdrm->info)
> + if (!sdrm->fbdev)
> return;
Ugh, embarrassing, sorry. I fixed it up. It was a late fix to a avoid
fbcon from panicking.
Thanks!
David
>
> dev_info(sdrm->ddev->dev, "fbdev cleanup\n");
>
>
>
^ permalink raw reply
* Re: [PATCH V2 3/3] video: exynos_dp: Use the generic PHY driver
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-06-28 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130628093459.GD11297@arwen.pp.htv.fi>
On 12:35 Fri 28 Jun , Felipe Balbi wrote:
> On Fri, Jun 28, 2013 at 04:18:23PM +0900, Jingoo Han wrote:
> > Use the generic PHY API instead of the platform callback to control
> > the DP PHY. The 'phy_label' field is added to the platform data
> > structure to allow PHY lookup on non-dt platforms.
> >
> > Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> > ---
> > .../devicetree/bindings/video/exynos_dp.txt | 17 ---
> > drivers/video/exynos/exynos_dp_core.c | 118 ++------------------
> > drivers/video/exynos/exynos_dp_core.h | 2 +
> > include/video/exynos_dp.h | 6 +-
> > 4 files changed, 15 insertions(+), 128 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
> > index 84f10c1..a8320e3 100644
> > --- a/Documentation/devicetree/bindings/video/exynos_dp.txt
> > +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
> > @@ -1,17 +1,6 @@
> > The Exynos display port interface should be configured based on
> > the type of panel connected to it.
> >
> > -We use two nodes:
> > - -dp-controller node
> > - -dptx-phy node(defined inside dp-controller node)
> > -
> > -For the DP-PHY initialization, we use the dptx-phy node.
> > -Required properties for dptx-phy:
> > - -reg:
> > - Base address of DP PHY register.
> > - -samsung,enable-mask:
> > - The bit-mask used to enable/disable DP PHY.
> > -
> > For the Panel initialization, we read data from dp-controller node.
> > Required properties for dp-controller:
> > -compatible:
> > @@ -67,12 +56,6 @@ SOC specific portion:
> > interrupt-parent = <&combiner>;
> > clocks = <&clock 342>;
> > clock-names = "dp";
> > -
> > - dptx-phy {
> > - reg = <0x10040720>;
> > - samsung,enable-mask = <1>;
> > - };
I've an issue here you break dt compatibilty
Best Regards,
J.
^ permalink raw reply
* Re: [RFC 4/6] drm: simpledrm: add fbdev fallback support
From: David Herrmann @ 2013-06-28 10:14 UTC (permalink / raw)
To: Stephen Warren
Cc: dri-devel@lists.freedesktop.org, linux-kernel, Dave Airlie,
linux-fbdev, Stephen Warren, Olof Johansson
In-Reply-To: <51CB5630.6060000@wwwdotorg.org>
Hi
On Wed, Jun 26, 2013 at 10:59 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 06/24/2013 04:27 PM, David Herrmann wrote:
>> Create a simple fbdev device during SimpleDRM setup so legacy user-space
>> and fbcon can use it.
>>
>> fbdev deletion is quite buggy. A unregister_framebuffer() call followed by
>> a printk() causes NULL-derefs in hide_cursor() and other places in the VT
>> layer. Hence, we leak the fbdev device currently to make the VT layer
>> happy. This needs to be fixed soon! Otherwise, we need a "depends !VT"
>> line for SimpleDRM.
>
>> diff --git a/drivers/gpu/drm/simpledrm/Makefile b/drivers/gpu/drm/simpledrm/Makefile
>
>> simpledrm-y := simpledrm_drv.o simpledrm_main.o simpledrm_mem.o
>>
>> +ifdef CONFIG_DRM_SIMPLEDRM_FBDEV
>> + simpledrm-y += simpledrm_fbdev.o
>> +endif
>
> I think that's:
>
> + simpledrm-$(CONFIG_DRM_SIMPLEDRM_FBDEV) += simpledrm_fbdev.o
Ugh, I got errors trying that because SIMPLEDRM_FBDEV is a boolean but
SIMPLEDRM is a tristate. But I guess I tried:
obj-$(CONFIG_DRM_SIMPLEDRM_FBDEV) += simpledrm_fbdev.o
which obviously fails if SIMPLEDRM=m and SIMPLEDRM_FBDEV=y. I will try
to fix that.
Thanks
David
^ permalink raw reply
* Re: [RFC 2/6] x86: provide platform-devices for boot-framebuffers
From: David Herrmann @ 2013-06-28 10:11 UTC (permalink / raw)
To: Stephen Warren
Cc: dri-devel@lists.freedesktop.org, linux-kernel, Dave Airlie,
linux-fbdev, Stephen Warren, Olof Johansson
In-Reply-To: <51CB53D7.7030602@wwwdotorg.org>
Hi
On Wed, Jun 26, 2013 at 10:49 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 06/24/2013 04:27 PM, David Herrmann wrote:
>> The current situation regarding boot-framebuffers (VGA, VESA/VBE, EFI) on
>> x86 causes troubles when loading multiple fbdev drivers. The global
>> "struct screen_info" does not provide any state-tracking about which
>> drivers use the FBs. request_mem_region() theoretically works, but
>> unfortunately vesafb/efifb ignore it due to quirks for broken boards.
>>
>> Avoid this by creating a "platform-framebuffer" device with a pointer
>> to the "struct screen_info" as platform-data. Drivers can now create
>> platform-drivers and the driver-core will refuse multiple drivers being
>> active simultaneously.
>>
>> We keep the screen_info available for backwards-compatibility. Drivers
>> can be converted in follow-up patches.
>>
>> Apart from "platform-framebuffer" devices, this also introduces a
>> compatibility option for "simple-framebuffer" drivers which recently got
>> introduced for OF based systems. If CONFIG_X86_SYSFB is selected, we
>> try to match the screen_info against a simple-framebuffer supported
>> format. If we succeed, we create a "simple-framebuffer" device instead
>> of a platform-framebuffer.
>> This allows to reuse the simplefb.c driver across architectures and also
>> to introduce a SimpleDRM driver. There is no need to have vesafb.c,
>> efifb.c, simplefb.c and more just to have architecture specific quirks
>> in their setup-routines.
>>
>> Instead, we now move the architecture specific quirks into x86-setup and
>> provide a generic simple-framebuffer. For backwards-compatibility (if
>> strange formats are used), we still allow vesafb/efifb to be loaded
>> simultaneously and pick up all remaining devices.
>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>
>> +config X86_SYSFB
>> + bool "Mark VGA/VBE/EFI FB as generic system framebuffer"
>> + help
>> + Firmwares often provide initial graphics framebuffers so the BIOS,
>> + bootloader or kernel can show basic video-output during boot for
>> + user-guidance and debugging. Historically, x86 used the VESA BIOS
>> + Extensions and EFI-framebuffers for this, which are mostly limited
>> + to x86. However, a generic system-framebuffer initialization emerged
>> + recently on some non-x86 architectures.
>
> After this patch has been in the kernel a while, that very last won't
> really be true; simplefb won't have been introduced recently. Perhaps
> just delete that one sentence?
It rather belongs in the commit message, right. I will rephrase that.
>> + This option, if enabled, marks VGA/VBE/EFI framebuffers as generic
>> + framebuffers so the new generic system-framebuffer drivers can be
>> + used on x86.
>> +
>> + This breaks any x86-only driver like efifb, vesafb, uvesafb, which
>> + will not work if this is selected.
>
> Doesn't that imply that some form of conflicts or depends ! statement
> should be added here?
There is no real conflict here. You still can use vesafb/... with this
option, but they will not pick up the device. I intend to fix these up
to use "platform-framebuffer" devices instead of globally binding to
"struct screen_info". This way, framebuffers either end up as
simple-framebuffers or platform-framebuffers. This option selects
which device they end up as.
As all non-compatible framebuffers (with incompatible pixel-formats)
always end up as "platform-framebuffer", it still makes sense to use
vesafb as fallback. Hence, I'd not introduce any "conflicts"
dependency here.
Maybe I should rephrase the warning to something that makes clear that
if this option is selected, you need simplefb.c or simpledrm to make
use of these devices.
>> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
>
>> +obj-y += sysfb.o
>
> I suspect that should be obj-$(CONFIG_X86_SYSFB) += sysfb.o.
No. This patch tries to solve two things: First of all, every
system-framebuffer now gets a "platform-framebuffer" platform-device.
Iff X86_SYSFB is selected, it additionally tries to parse the
framebuffer information as "simple-framebuffer". If it succeeds, it
created a "simple-framebuffer" object, if it doesn't, a fallback
"platform-framebuffer" is provided.
This series is missing vesafb/efifb/.. patches, which should now bind
to "platform-framebuffer" devices instead of using "struct
screen_info" directly. I intend to add these in the next round.
>> diff --git a/arch/x86/kernel/sysfb.c b/arch/x86/kernel/sysfb.c
>
>> +#ifdef CONFIG_X86_SYSFB
>
> Rather than ifdef'ing the body of this file, why not create a dummy
> static inline version of add_sysfb() and put that into a header file
> that users include. There should be a header file to prototype the
> function anyway. That way, you avoid all of the ifdefs and static inline
> functions in this file.
>
>> +static bool parse_mode(const struct screen_info *si,
>> + struct simplefb_platform_data *mode)
>
>> + strlcpy(mode->format, f->name, sizeof(mode->format));
>
> Per my comments about the type of mode->format, I think that could just be:
>
> mode->format = f->name;
>
> ... since formats[] (i.e. f) isn't initdata.
>
>> +#else /* CONFIG_X86_SYSFB */
>> +
>> +static bool parse_mode(const struct screen_info *si,
>> + struct simplefb_platform_data *mode)
>> +{
>> + return false;
>> +}
>> +
>> +static int create_simplefb(const struct screen_info *si,
>> + const struct simplefb_platform_data *mode)
>> +{
>> + return -EINVAL;
>> +}
>> +
>> +#endif /* CONFIG_X86_SYSFB */
>
> Following on from my ifdef comment above, I believe those versions of
> those functions will always cause add_sysfb() to return -ENODEV, so you
> may as well provide a static inline for add_sysfb() instead.
No. add_sysfb() is supposed to always succeed. However, if
parse_mode/create_simplefb fail, it creates a "platform-framebuffer"
as fallback. I don't see any way to avoid these ifdefs. Considering
the explanation above, could you elaborate how you think this should
work?
Thanks
David
^ permalink raw reply
* Re: [PATCH v3 1/5] phy: Add driver for Exynos MIPI CSIS/DSIM DPHYs
From: Sylwester Nawrocki @ 2013-06-28 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51CD4698.3070409@gmail.com>
On 06/28/2013 10:17 AM, Hui Wang wrote:
> On 06/26/2013 11:02 PM, Sylwester Nawrocki wrote:
>> Add a PHY provider driver for the Samsung S5P/Exynos SoC MIPI CSI-2
>> receiver and MIPI DSI transmitter DPHYs.
>>
>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>> Changes since v2:
>> - adapted to the generic PHY API v9: use phy_set/get_drvdata(),
>> - fixed of_xlate callback to return ERR_PTR() instead of NULL,
>> - namespace cleanup, put "GPL v2" as MODULE_LICENSE, removed pr_debug,
>> - removed phy id check in __set_phy_state().
>> ---
> [...]
>> +
>> + if (IS_EXYNOS_MIPI_DSIM_PHY_ID(id))
>> + reset = EXYNOS_MIPI_PHY_MRESETN;
>> + else
>> + reset = EXYNOS_MIPI_PHY_SRESETN;
>> +
>> + spin_lock_irqsave(&state->slock, flags);
>
> Sorry for one stupid question here, why do you use spin_lock_irqsave()
> rather than spin_lock(),
> I don't see the irq handler will use this spinlock anywhere in this c file.
Yes, there is no chance the PHY users could call the phy ops from within
an interrupt context. Especially now when there is a per phy object
mutex used in the PHY operation helpers. So I'll replace it with plain
spin_lock/unlock. Thank you for the review.
Regards,
Sylwester
^ permalink raw reply
* Re: [RFC 1/6] fbdev: simplefb: add init through platform_data
From: David Herrmann @ 2013-06-28 10:03 UTC (permalink / raw)
To: Stephen Warren
Cc: dri-devel@lists.freedesktop.org, linux-kernel, Dave Airlie,
linux-fbdev, Stephen Warren, Olof Johansson
In-Reply-To: <51CB5176.5000404@wwwdotorg.org>
Hi
On Wed, Jun 26, 2013 at 10:39 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 06/24/2013 04:27 PM, David Herrmann wrote:
>> If we create proper platform-devices in x86 boot-code, we can use simplefb
>> for VBE or EFI framebuffers, too. However, there is normally no OF support
>> so we introduce a platform_data object so x86 boot-code can pass the
>> paramaters via plain old platform-data.
>>
>> This also removes the OF dependency as it is not needed. The headers
>> provide proper dummies for the case OF is disabled.
>>
>> Furthermore, we move the FORMAT-definitions to the common platform header
>> so initialization code can use it to transform "struct screen_info" to
>> the right format-name.
>
>> diff --git a/include/linux/platform_data/simplefb.h b/include/linux/platform_data/simplefb.h
>
>> +/* the framebuffer size and location is available as IORESOURCE_MEM */
>> +struct simplefb_platform_data {
>> + u32 width;
>> + u32 height;
>> + u32 stride;
>> + char format[64];
>> +};
>
> Any reason not to make format:
>
> const char *format;
>
> You should be able to initialize that just as easily in platform code,
> either as static data or at runtime, I think.
That makes sense. I fixed it up.
Thanks
David
^ permalink raw reply
* Re: [PATCH 1/3] phy: Add driver for Exynos DP PHY
From: Sylwester Nawrocki @ 2013-06-28 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51CD57EF.5010808@ti.com>
Hi,
On 06/28/2013 11:31 AM, Kishon Vijay Abraham I wrote:
>> diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
>> new file mode 100644
>> index 0000000..8b6fa79
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
>
> How about creating a single Documentation file for all samsung video phys?
> Sylwester?
Yes, makes sense. There are quite a few various PHYs on the Exynos SoC.
Let me resend my series with the binding description file name changed
to samsung-phy.txt. I need to add couple fixes to that series anyway.
Regards,
Sylwester
^ permalink raw reply
* Re: [RFC 3/6] drm: add SimpleDRM driver
From: David Herrmann @ 2013-06-28 10:01 UTC (permalink / raw)
To: Stephen Warren
Cc: dri-devel@lists.freedesktop.org, linux-kernel, Dave Airlie,
linux-fbdev, Stephen Warren, Olof Johansson
In-Reply-To: <51CB55DB.6040306@wwwdotorg.org>
Hi
On Wed, Jun 26, 2013 at 10:58 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 06/24/2013 04:27 PM, David Herrmann wrote:
>> The SimpleDRM driver binds to simple-framebuffer devices and provides a
>> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
>> plus one initial mode.
>>
>> Userspace can create one dumb-buffer and attach it to the CRTC. Only if
>> the buffer is destroyed, a new buffer can be created. The buffer is
>> directly mapped into user-space, so we have only resources for a single
>> buffer. Otherwise, shadow buffers plus damage-request would be needed.
>
>> diff --git a/drivers/gpu/drm/simpledrm/Kconfig b/drivers/gpu/drm/simpledrm/Kconfig
>
>> +config DRM_SIMPLEDRM
>> + tristate "Simple firmware framebuffer DRM driver"
>> + depends on DRM && !FB_SIMPLE
>> + help
>> + SimpleDRM can run on all systems with pre-initialized graphics
>> + hardware. It uses a framebuffer that was initialized during
>> + firmware boot. No page-flipping, modesetting or other advanced
>> + features are available. However, other DRM drivers can be loaded
>> + later and take over from SimpleDRM if they provide real hardware
>> + support.
>> +
>> + SimpleDRM supports: "simple-framebuffer" DeviceTree objects, x86 VESA
>> + BIOS Extensions (VBE), EFI framebuffers
>
> DT objects, yes. I'm not sure it's quite true to say it actually
> directly supports VBE or EFI FBs; it's more the code in patch 2/6 that
> supports those. I guess this is a bit nit-picky of a distinction though.
I initially intended to add support for "platform-framebuffer"
objects, too. This would make vesafb/... obsolete but I dropped that
idea for now. I will fix the Kconfig description.
>> diff --git a/drivers/gpu/drm/simpledrm/simpledrm_drv.c b/drivers/gpu/drm/simpledrm/simpledrm_drv.c
>
>> +static int parse_dt(struct platform_device *pdev,
>> + struct simplefb_platform_data *mode)
>
>> + strlcpy(mode->format, format, sizeof(mode->format));
>
> Even here, I believe the DT data sticks around so just copying the
> pointer should be safe. It'd be worth validating that for sure though.
Yep, indeed, I fixed that.
Thanks!
David
> I didn't review the DRM stuff here since I'm not at all familiar with DRM.
^ permalink raw reply
* Re: [RFC 3/6] drm: add SimpleDRM driver
From: David Herrmann @ 2013-06-28 9:59 UTC (permalink / raw)
To: Andy Lutomirski
Cc: dri-devel@lists.freedesktop.org, linux-kernel, Dave Airlie,
linux-fbdev, Stephen Warren, Olof Johansson
In-Reply-To: <51C8ECC7.4030404@mit.edu>
Hi
On Tue, Jun 25, 2013 at 3:05 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On 06/24/2013 03:27 PM, David Herrmann wrote:
>> + sdrm->fb_map = ioremap(sdrm->fb_base, sdrm->fb_size);
>
> This should probably be ioremap_wc. Otherwise it will be *really* slow
> if used in legacy mode and it may cause conflicts with the
> pgprot_writecombine mode for mmap.
Whoops, yepp, I fixed that.
Thanks
David
^ permalink raw reply
* Re: [PATCH 1/3] phy: Add driver for Exynos DP PHY
From: Kishon Vijay Abraham I @ 2013-06-28 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001501ce73bf$87c49c00$974dd400$@samsung.com>
Hi,
On Friday 28 June 2013 10:52 AM, Jingoo Han wrote:
> Add a PHY provider driver for the Samsung Exynos SoC DP PHY.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> ---
> .../phy/samsung,exynos5250-dp-video-phy.txt | 7 ++
> drivers/phy/Kconfig | 8 ++
> drivers/phy/Makefile | 3 +-
> drivers/phy/phy-exynos-dp-video.c | 130 ++++++++++++++++++++
> 4 files changed, 147 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
> create mode 100644 drivers/phy/phy-exynos-dp-video.c
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
> b/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
> new file mode 100644
> index 0000000..8b6fa79
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/samsung,exynos5250-dp-video-phy.txt
How about creating a single Documentation file for all samsung video phys?
Sylwester?
Thanks
Kishon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox