date:20120309

BUG: drm_crtc_helper_set_config does not work

2012-03-09 Thread Maarten Maathuis

On Fri, Mar 9, 2012 at 5:28 PM, Yufeng Shen  wrote:
> On Fri, Mar 9, 2012 at 3:15 AM, Maarten Maathuis  
> wrote:
>> On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen  wrote:
>>> So a simple case of ?disabling a CRTC and then re-enabling it.
>>>
>>> Disabling:
>>>
>>> CRTC X is originally connected to output Y
>>>
>>> 1. XRRSetCrtcConfig() ? ?is called to disable CRTC ?X
>>>
>>> 2. drm_helper_connector_dpms() ? then gets called on the connector
>>> connected to CRTC X,
>>> ? ?in the function,
>>> ? ?the ?connector->encoder ?is set to DPMS OFF, ? and the
>>> encoder->crtc ?set to DPMS OFF
>>> ? ?but the ?encoder->crtc ? is still CRTC X
>>>
>>> Re-enabling:
>>>
>>> 3. XRRSetCrtcConfig() ? ?is called to to enable CRTC ?X ?on output Y
>>>
>>> 4. drm_crtc_helper_set_config () ?is now called,
>>> suppose ? fb is not changed, ?mode is not changed, encoder is not changed
>>> and the ? encoder->crtc ?is not changed,
>>> then we have ? mode_changed == false ? ?and ?the mode is not reset
>>>
>>> So the CRTC X won't be connected to output Y.
>>>
>>> What I don't understand the code is that why ?XRRSetCrtcConfig() ?ends
>>> up only calling ?drm_helper_connector_dpms() ??
>>> I think it should do more than that, at least it should set the
>>> related ?encoder->crtc = NULL
>>>
>>> any comments ?
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> As far as i know DPMS designed is a simple switch, meaning that the
>> mode remains active, so if you do DPMS ON it should come back. If for
>> some reason the driver is disconnecting the encoder from the crtc,
>> then it is the drivers responsibility to reconnect it when DPMS ON
>> happens.
>>
>> But don't take my word for it, others may have more/other information.
>>
>
> Yes, I was thinking ideally DPMS call should enable/disable DPMS state, and
> XRRSetCrtcConfig call should enable/disable CRTC.
>
> But it seems that, when using XRRSetCrtcConfig to disable CRTC,
> the CRTC itself is disabled, the DPMS is disabled (DPMS OFF),
> and then when using XRRSetCrtcConfig to re-enable the CRTC,
> it only checks whether the CRTC that connected to the encoder is
> changed (whether a new crtc is assigned), but does not check whether
> the CRTC itself is previously disabled or not. ?So it considers the encoder
> is connected to the same CRTC and does no thing to re-enable the CRTC.
>
>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.

What i meant is that you should get a DPMS ON call somewhere in the
driver. The driver should then re-enable things. If the driver
disconnects the encoder for DPMS OFF, then it will also have to
reconnect it for DPMS ON.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

答复: [korg]help: How to submit a kernel driver on kernel.org.

2012-03-09 Thread Aaron.Chen 陈俊杰

Hi Paul,

Thank you very much for your great help.

Here is the first patch.

Regards
Aaron

--
???: Paul Menzel [mailto:paulepanter at users.sourceforge.net] 
: 2012?3?6? 22:38
???: Alex Deucher
??: Aaron.Chen ???; caesar.qiu ???; dri-devel at lists.freedesktop.org
??: Re: [korg]help: How to submit a kernel driver on kernel.org.

Dear Aaron,


Am Dienstag, den 06.03.2012, 08:47 -0500 schrieb Alex Deucher:
> On Mon, Mar 5, 2012 at 11:13 PM, Aaron.Chen  ??? wrote:

> > Thank you very much for your guide. It's a great help for me.
> >
> > But I still have a little problem with the patch thing. I'm not familiar 
> > with the git.
> > 1.Shall I need to do the clone and get the source location and target 
> > directory first?
> > 2.Where is the source location and target directory?
> > 3.Our driver has pass the customer's test from kernel version 2.6.5 to 
> > 3.0.0, So what shall I do to submit a driver cover all these kernel version.

you can only get new features included upstream in the latest Linux kernel. So 
earliest version would be 3.4. You have to maintain you own repository for 
earlier version. But backporting should be not so much trouble if you have it 
included upstream.

> > 4.or just email you the source code and tell you the changes?
> >
> > I'm looking forward your re-guide. Thank you so much.
> 
> Your best bet it to clone Linus' git tree and then apply your patches:
> 
> 1. clone Linus' git tree:
> git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

you can do this in between.

cd linux
git config --global user.name "??? (Aaron Chen)"
git config --global user.email aaron.chen at siliconmotion.com

> 2.a) apply your first patch
>b)  if you patch adds new files to the source tree, add them:
> git add path/to/files/file.c
> git add path/to/files/file.h
> etc.  if the patch only modifies patches that are already 
> in the tree, you do not need to add them.
>c) when the patch is applied commit it:
>git commit -a -s
>d) when you run the commit command you will be prompted to 
> enter a commit message.  The commit message has the following format:
> 
> subsystem: patch description
> 
> description of what the patch does.
> 
> Signed-off-by: Your name 
> 
> E.g.,
> 
> fb: add initial code for video 5000 graphics
> 
> This adds the initial support for the video 5000 graphics adapter.  It 
> supports vga and lcd connectors.
> 
> Signed-off-by: Joe Developer 
> 
> e) repeat steps a-d for all of your patches 3. generate patches:
> git format-patch -n
> 
> where n is the number of patches you committed.  E.g., if your driver 
> consists of 5 patches:
> git format-patch -5
> 
> 4. Send the patches to the list.

Aaron, Git is nowadays documented pretty well. So just use

git help command

(like `git help commit`) to read the manual. Additionally you can just search 
for it using your favorite search engine. Interesting reads should be [1][2][3].


Thanks,

Paul


[1] http://schacon.github.com/git/user-manual.html#cleaning-up-history
[2] http://git-scm.com/documentation
[3] http://progit.org/book/
-- next part --
A non-text attachment was scrubbed...
Name: 0001-fb-add-initial-code-for-smi-graphics.patch
Type: application/octet-stream
Size: 688721 bytes
Desc: 0001-fb-add-initial-code-for-smi-graphics.patch
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120309/562d545a/attachment-0001.obj>

regression(?) 3.3-rc4 -> 3.3-rc5: drm intel hangs

2012-03-09 Thread Norbert Preining

Hi everyone,

currently 3.3.0-rc6+  I just was hit by that after wake up from ram:

On Di, 28 Feb 2012, Daniel Vetter wrote:
> > Feb 28 11:42:47 mithrandir kernel: [15627.756071]
> > [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
> > Feb 28 11:42:47 mithrandir kernel: [15627.756087] [drm] capturing error
> > event; look for more information in /debug/dri/0/i915_error_state
> 
> Wee need this i915_error_state file from debugfs (you might need to mount
> that first again) to diagnose gpu hangs. Also, it only contains
> information after a crash, so you need to rehang your machine if you've
> rebooted since then.

Now I could get that file from debugfs, and the dmesg output with
proper debug value.

Attached are both.

Please let me know if I can provide any other information.

Best wishes

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

NAZEING (participial vb.)
The rather unconvincing noises of pretended interest which an adult
has to make when brought a small dull object for admiration by a
child.
--- Douglas Adams, The Meaning of Liff
-- next part --
A non-text attachment was scrubbed...
Name: dmesg.txt.gz
Type: application/octet-stream
Size: 7394 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120309/f2ed0da9/attachment-0001.obj>
-- next part --
?'OOi915_error_state??O?-?q????????d??F,?q[??a?I?# 
zr$9p?}f???-??I????U?f?/O??b?|??W???~?%?>?|?|???^>???/?_]
??_~?]?>??_???_???C???~?/?~???_}?~???~???,???>?f??;?o~??/??7?|3????1d?|??O/???O_???w???,???t?I??J*E)H6??L?|]?p???O?W
?SD??x???"??B?)?i?{/Ocz?#?]^,.^,??h???/???/?8?i,??Xb{i?X???z???s?bI?y??yy?R?r???)-??O_?3??#?i?v??t???)?S?v??2?o?AX:h?w?|???h???:????S"??OY??T#a??SSN??

Xr?S?K`?NKNKNK???\??`?:G?t?%?K????O)j,9????%K??O9?Xr?K?%?K.?,?P#a???#?t??TK??dw??NkD??vze??*?Y??Z#?Og??M#h?h??q?Q???<h?A38?OG??u??P?p???Q5??}????hw?fp'hw?fpxw?OY?j,???F#?Q??*???1?!F?w??{??c:??/y>/???.?HcF3??Gzw??3??w?\??S}q.O??\>O???J?'??/?7?1j?}???Q?w#?}???8?W???s?]}?8?\??^?+?n|??^???=???`/d?o?|??J?O?z?O???
   B?#~7kD??;a???zwy?)???$??4??c? ??0????????? 3???8?Kb??? 
?????????^????n(???eC  
w?\7?@/?z)X?t?2R?3??A/???{??O?c&??@???i??=d??B?=.3??F???????{\?A{?%~??W3?Oj?H??????AX:
 ?FXj?F????:a?M??%??@?ai?N???O??$,?
?7?R?Kq,E??N???H??H???K???,E[?
?6=`)zX?H???K1?b,E?IF??K1?b,E???.b,E3f?J?sE??B?^h?O???\C?+Vo??F?sE??H?3S?dc?:??v?1??G??'Q???;??b?u.}?nc?y%q?Ni@?+3?F?q?1/??'??I?i???+?7?g??Q??7??OT?JTO3??O?'?OT?J0?<`>Q??(~O00?Gmw
??)?S???O  0??G)?~?,?|3?G??g??=e??R?`3&??Q??sX?y??
F??(~O??Mm???6V?S?\?????????/u?q?:?ac?i??H&??Q?L?3???g^?3?j?Y5?MI
 Y???+?????3?g??K??3???F??F3O???L?? 
n?+?????5???s??|V???s?
???!??)~??g??QD?{&???L?{??=[??!???g?L?{??=??]?d??3?L?{?P;??|??G??L?{6?O???|??Y>i?'?f??7??B???A??&?L
??&??o?,|?87???Y?P;+jg?C??x??????vV?f
??)t??????Y`B?{?,F?4???B?{)??B????N???{??:1????R   
??0???A??`?*
??b?S?[??~T?;?_*???A????`????`e?+???$???;s7??4?w??w
?S??`~w?;?=h???w????b?]]=@??G???h?K^??1?a??_?/?\v?=A~i??K;?_?-??F;?_N??v?;?_???w/?T[???e???S??S??S?}_??ze?|?N?s'????0???I???v???}@>d'??3_??Q9??YX7??T?OKU?G??@>?
?C???4X????;*?_?4X=A?U??J??
4??=4X}!?8??-???`?@?q????FY??%??A?}8??tJbt~?A3??S=???A?yP?~???g???c??7??5???Cu?O?;?????^!??+??;?n?s?F?6???S??)~?
rV}??w??E??Hv???!g??? 
^??s??H?D??S??O????c~d?aP?h??????0?Y?4Bnm??rk???p?[Z???0??? 
?!?<?C
p??
?OKC???
???!?<"??G?|?H?O ??#A>yd?'??92??A|sP?>??>
??? ?T???0??2??0O?s?y??? ??y??}???0? ???O>??-?N=?dvF?'?_g 
?|&?'?4?I??N??U?#?f8?~t?4???b?s?22?$?<'g?X?.???)~???O??O?i???[?I??I?yN??J?^?I??9??Xu.??O??O??O??O??O??o?H?1?j|??W??|Q?{???)??S6??4???uJV?C??sVB??e?)??s????qC???8?
 ~?
??)???N???:%????^?????)??s???l?????6

[PATCH] xf86drmMode.h: Add header protection

2012-03-09 Thread Adam Jackson

On Thu, 2012-03-08 at 15:34 +0100, David Herrmann wrote:
> 
> xf86drmMode.h is missing a header protection. xf86drm.h has one so
> just copy it
> and adjust the name.
> 
> Signed-off-by: David Herrmann  

Applied, thanks.

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120309/75a29bde/attachment.pgp>

[Bug 41265] KMS does not work on Radeon HD6700M

2012-03-09 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #12 from gyhor at gmx.de 2012-03-09 05:04:24 PST ---
Is it possible to use the external connectors with the intel card?
I am only wanting to use the external dockingstation for the additionals
connectors.
So if i can use vga and hdmi port from the dockingstaion with the intel card i
would be very happy.


[   22.377284] [drm:intel_dsm_platform_mux_info], MUX info connectors: 7
[   22.377287] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010100
[   22.377290] [drm:intel_dsm_platform_mux_info],   port id: Analog VGA
[   22.377292] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377295] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377298] [drm:intel_dsm_platform_mux_info],   hpd mux info: unknown
[   22.377301] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010400
[   22.377303] [drm:intel_dsm_platform_mux_info],   port id: LVDS
[   22.377305] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377308] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377311] [drm:intel_dsm_platform_mux_info],   hpd mux info: unknown
[   22.377313] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010300
[   22.377315] [drm:intel_dsm_platform_mux_info],   port id: DisplayPort_B
[   22.377318] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377320] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377323] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between
iGPU and dGPU
[   22.377326] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010301
[   22.377328] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_B
[   22.377331] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377334] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377336] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between
iGPU and dGPU
[   22.377339] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010302
[   22.377342] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_C
[   22.377344] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377347] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377349] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between
iGPU and dGPU
[   22.377352] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010303
[   22.377354] [drm:intel_dsm_platform_mux_info],   port id: DisplayPort_D
[   22.377357] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377360] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377362] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between
iGPU and dGPU
[   22.377365] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010304
[   22.377367] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_D
[   22.377370] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377373] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377375] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between
iGPU and dGPU
[   22.377383] [drm:intel_dsm_pci_probe], no _DSM method for intel device

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

BUG: drm_crtc_helper_set_config does not work

2012-03-09 Thread Yufeng Shen

On Fri, Mar 9, 2012 at 3:15 AM, Maarten Maathuis  
wrote:
> On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen  wrote:
>> So a simple case of ?disabling a CRTC and then re-enabling it.
>>
>> Disabling:
>>
>> CRTC X is originally connected to output Y
>>
>> 1. XRRSetCrtcConfig() ? ?is called to disable CRTC ?X
>>
>> 2. drm_helper_connector_dpms() ? then gets called on the connector
>> connected to CRTC X,
>> ? ?in the function,
>> ? ?the ?connector->encoder ?is set to DPMS OFF, ? and the
>> encoder->crtc ?set to DPMS OFF
>> ? ?but the ?encoder->crtc ? is still CRTC X
>>
>> Re-enabling:
>>
>> 3. XRRSetCrtcConfig() ? ?is called to to enable CRTC ?X ?on output Y
>>
>> 4. drm_crtc_helper_set_config () ?is now called,
>> suppose ? fb is not changed, ?mode is not changed, encoder is not changed
>> and the ? encoder->crtc ?is not changed,
>> then we have ? mode_changed == false ? ?and ?the mode is not reset
>>
>> So the CRTC X won't be connected to output Y.
>>
>> What I don't understand the code is that why ?XRRSetCrtcConfig() ?ends
>> up only calling ?drm_helper_connector_dpms() ??
>> I think it should do more than that, at least it should set the
>> related ?encoder->crtc = NULL
>>
>> any comments ?
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> As far as i know DPMS designed is a simple switch, meaning that the
> mode remains active, so if you do DPMS ON it should come back. If for
> some reason the driver is disconnecting the encoder from the crtc,
> then it is the drivers responsibility to reconnect it when DPMS ON
> happens.
>
> But don't take my word for it, others may have more/other information.
>

Yes, I was thinking ideally DPMS call should enable/disable DPMS state, and
XRRSetCrtcConfig call should enable/disable CRTC.

But it seems that, when using XRRSetCrtcConfig to disable CRTC,
the CRTC itself is disabled, the DPMS is disabled (DPMS OFF),
and then when using XRRSetCrtcConfig to re-enable the CRTC,
it only checks whether the CRTC that connected to the encoder is
changed (whether a new crtc is assigned), but does not check whether
the CRTC itself is previously disabled or not.  So it considers the encoder
is connected to the same CRTC and does no thing to re-enable the CRTC.


> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.

[Bug 46713] HDMI audio played back at a wrong rate

2012-03-09 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #13 from Rafa? Mi?ecki  2012-03-09 03:04:03 
PST ---
I'm afraid I can not do anything without dump from fglrx :( There are 4 clocks
related registers we are aware of, but I don't know how else we can try to
program them. There may be also some other clock registers. I'm afraid only
dump from fglrx can give us some hints and I can't get that info from my card,
since it's working pretty well.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

for-next inclusion request: dma-buf buffer sharing framework

2012-03-09 Thread Stephen Rothwell

Hi,

On Thu, 8 Mar 2012 14:28:39 +0530 Sumit Semwal  
wrote:
>
> May I request you to please add the dma-buf buffer sharing framework
> tree to linux-next?
> 
> It is hosted here
> git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
> branch: for-next

I have added that from today.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
 * submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
 * posted to the relevant mailing list,
 * reviewed by you (or another maintainer of your subsystem tree),
 * successfully unit tested, and 
 * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr at canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120309/3db46acd/attachment.pgp>

答复: [korg]help: How to submit a kernel driver on kernel.org.

2012-03-09 Thread Ilija Hadzic


A couple of non-technical things. First, I think you are sending the patch 
to the wrong list. dri-devel is for drivers that go under drivers/gpu/drm. 
Your driver is apparently fbdev driver and thus belongs to 
linux-fbdev at vger.kernel.org list (see the Maintainers file)

Second, your patch generates about 9000 coding style errors when you run 
through ./scripts/checkpatch.pl script available in the Linux kernel tree. 
You need to clean up. See also Documentation/CodingStyle. Also, you must 
break up the patch into smaller self-contained units that logically make 
sense. Nobody can review 17000 lines of code in one shot.

Last, but probably the most important. All your files have the proprietary 
license in the comment overhead. You (actually your company lawyers) have 
to decide which license you are releasing this dirver under and make sure 
it is compatible with Linux kernel (i.e. GPL) and you have to state that 
in each file that is being added.

-- Ilija


On Fri, 9 Mar 2012, [utf-8] Aaron.Chen  ?~Y~H??~J?~]? wrote:

> Hi Paul,
>
> Thank you very much for your great help.
>
> Here is the first patch.
>
> Regards
> Aaron
>
> --
> ?: Paul Menzel [mailto:paulepanter at users.sourceforge.net]
> : 2012???3???6??? 22:38
> ?: Alex Deucher
> ??: Aaron.Chen ?; caesar.qiu ?; dri-devel at 
> lists.freedesktop.org
> ??: Re: [korg]help: How to submit a kernel driver on kernel.org.
>
> Dear Aaron,
>
>
> Am Dienstag, den 06.03.2012, 08:47 -0500 schrieb Alex Deucher:
>> On Mon, Mar 5, 2012 at 11:13 PM, Aaron.Chen  ? wrote:
>
>>> Thank you very much for your guide. It's a great help for me.
>>>
>>> But I still have a little problem with the patch thing. I'm not familiar 
>>> with the git.
>>> 1.Shall I need to do the clone and get the source location and target 
>>> directory first?
>>> 2.Where is the source location and target directory?
>>> 3.Our driver has pass the customer's test from kernel version 2.6.5 to 
>>> 3.0.0, So what shall I do to submit a driver cover all these kernel version.
>
> you can only get new features included upstream in the latest Linux kernel. 
> So earliest version would be 3.4. You have to maintain you own repository for 
> earlier version. But backporting should be not so much trouble if you have it 
> included upstream.
>
>>> 4.or just email you the source code and tell you the changes?
>>>
>>> I'm looking forward your re-guide. Thank you so much.
>>
>> Your best bet it to clone Linus' git tree and then apply your patches:
>>
>> 1. clone Linus' git tree:
>> git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> you can do this in between.
>
>cd linux
>git config --global user.name "? (Aaron Chen)"
>git config --global user.email aaron.chen at siliconmotion.com
>
>> 2.a) apply your first patch
>>b)  if you patch adds new files to the source tree, add them:
>> git add path/to/files/file.c
>> git add path/to/files/file.h
>> etc.  if the patch only modifies patches that are already
>> in the tree, you do not need to add them.
>>c) when the patch is applied commit it:
>>git commit -a -s
>>d) when you run the commit command you will be prompted to
>> enter a commit message.  The commit message has the following format:
>>
>> subsystem: patch description
>>
>> description of what the patch does.
>>
>> Signed-off-by: Your name 
>>
>> E.g.,
>>
>> fb: add initial code for video 5000 graphics
>>
>> This adds the initial support for the video 5000 graphics adapter.  It
>> supports vga and lcd connectors.
>>
>> Signed-off-by: Joe Developer 
>>
>> e) repeat steps a-d for all of your patches 3. generate patches:
>> git format-patch -n
>>
>> where n is the number of patches you committed.  E.g., if your driver
>> consists of 5 patches:
>> git format-patch -5
>>
>> 4. Send the patches to the list.
>
> Aaron, Git is nowadays documented pretty well. So just use
>
>git help command
>
> (like `git help commit`) to read the manual. Additionally you can just search 
> for it using your favorite search engine. Interesting reads should be 
> [1][2][3].
>
>
> Thanks,
>
> Paul
>
>
> [1] http://schacon.github.com/git/user-manual.html#cleaning-up-history
> [2] http://git-scm.com/documentation
> [3] http://progit.org/book/
>

[PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion

2012-03-09 Thread Inki Dae

Hi Laurent,

> -Original Message-
> From: Joonyoung Shim [mailto:jy0922.shim at samsung.com]
> Sent: Thursday, March 08, 2012 10:06 PM
> To: Laurent Pinchart
> Cc: dri-devel at lists.freedesktop.org; linux-fbdev at vger.kernel.org; Inki
Dae;
> Seung-Woo Kim; Kyungmin Park
> Subject: Re: [PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo
> conversion
> 
> On 03/08/2012 08:34 PM, Laurent Pinchart wrote:
> > The fb_videomode structure stores the front porch and back porch in the
> > right_margin and left_margin fields respectively. right_margin should
> > thus be computed with hsync_start - hdisplay, and left_margin with
> > htotal - hsync_end. The same holds for the vertical direction.
> >
> > Active   Front   SyncBack
> > Region   Porch   Porch
> > <---><><-><>
> >
> >//|
> >   // |
> > //  |..   ..
> > ___
> >
> > <-- xres ---><- right_margin -><- hsync_len -><- left_margin -->
> >
> > < hdisplay ->
> > < hsync_start >
> > <- hsync_end >
> > <- htotal ->
> >
> > Fix the fb_videomode<->  drm_mode_modeinfo conversion functions
> > accordingly.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >   drivers/gpu/drm/exynos/exynos_drm_connector.c |   16 
> >   1 files changed, 8 insertions(+), 8 deletions(-)
> >
> > While trying to understand how the fb_videomode and drm_mode_modeinfo
> fields
> > map to each other, I found what might be a bug in the Exynos DRM driver.
> Could
> > you please check and confirm that my understanding is correct ?
> 
> Good catch. You can refer Documentation/fb/framebuffer.txt to know in
> detail.
> 
> Acked-by: Joonyoung Shim 
> 
> Thanks.
> 

it seems like that you doesn't use latest exynos drm driver so I merged it
manually
for this, you can refer to this link:
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exyn
os-drm-fixes

Thanks,
Inki Dae

> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> > index d620b07..7bb1dca 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> > @@ -52,14 +52,14 @@ convert_to_display_mode(struct drm_display_mode
> *mode,
> > mode->vrefresh = timing->refresh;
> >
> > mode->hdisplay = timing->xres;
> > -   mode->hsync_start = mode->hdisplay + timing->left_margin;
> > +   mode->hsync_start = mode->hdisplay + timing->right_margin;
> > mode->hsync_end = mode->hsync_start + timing->hsync_len;
> > -   mode->htotal = mode->hsync_end + timing->right_margin;
> > +   mode->htotal = mode->hsync_end + timing->left_margin;
> >
> > mode->vdisplay = timing->yres;
> > -   mode->vsync_start = mode->vdisplay + timing->upper_margin;
> > +   mode->vsync_start = mode->vdisplay + timing->lower_margin;
> > mode->vsync_end = mode->vsync_start + timing->vsync_len;
> > -   mode->vtotal = mode->vsync_end + timing->lower_margin;
> > +   mode->vtotal = mode->vsync_end + timing->upper_margin;
> >
> > if (timing->vmode&  FB_VMODE_INTERLACED)
> > mode->flags |= DRM_MODE_FLAG_INTERLACE;
> > @@ -81,14 +81,14 @@ convert_to_video_timing(struct fb_videomode *timing,
> > timing->refresh = drm_mode_vrefresh(mode);
> >
> > timing->xres = mode->hdisplay;
> > -   timing->left_margin = mode->hsync_start - mode->hdisplay;
> > +   timing->right_margin = mode->hsync_start - mode->hdisplay;
> > timing->hsync_len = mode->hsync_end - mode->hsync_start;
> > -   timing->right_margin = mode->htotal - mode->hsync_end;
> > +   timing->left_margin = mode->htotal - mode->hsync_end;
> >
> > timing->yres = mode->vdisplay;
> > -   timing->upper_margin = mode->vsync_start - mode->vdisplay;
> > +   timing->lower_margin = mode->vsync_start - mode->vdisplay;
> > timing->vsync_len = mode->vsync_end - mode->vsync_start;
> > -   timing->lower_margin = mode->vtotal - mode->vsync_end;
> > +   timing->upper_margin = mode->vtotal - mode->vsync_end;
> >
> > if (mode->flags&  DRM_MODE_FLAG_INTERLACE)
> > timing->vmode = FB_VMODE_INTERLACED;

[Bug 46713] HDMI audio played back at a wrong rate

2012-03-09 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #12 from Tvrtko Ursulin  2012-03-09 
01:50:36 PST ---
(In reply to comment #11)
> (In reply to comment #5)
> > Monitor is Dell 2408WFP in case it matters.
> 
> Are you using 1900x1200 resolution? Can you try some smaller one? Does it 
> help?

It changes the error:

1920x1200: 4m20s = 1.53x too slow
1280x1024: 3m2s = 1.07x too slow
1024x768: 1m49s = 1.55x too fast
800x600: 1m7s = 2.52x too fast

Sound also comes with various distortions in each test.

Is this enough of a hint on what is going wrong or you would still like me to
test with fglrx? It may take some time to set it up since I have no experience
with it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 46713] HDMI audio played back at a wrong rate

2012-03-09 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #11 from Rafa? Mi?ecki  2012-03-09 01:29:31 
PST ---
(In reply to comment #5)
> Monitor is Dell 2408WFP in case it matters.

Are you using 1900x1200 resolution? Can you try some smaller one? Does it help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 46713] HDMI audio played back at a wrong rate

2012-03-09 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #10 from Rafa? Mi?ecki  2012-03-09 01:27:16 
PST ---
Ahh, sorry, I didn't understand your first problem description you posted in
this bug report. I though the playback speed is alright, just the sampling rate
used is incorrect.

The problem most probably lays in audio clocks. Values used by radeon seem to
be:
EVERGREEN_AUDIO_PLL1_MUL00075300
EVERGREEN_AUDIO_PLL1_DIV00177fa0
EVERGREEN_AUDIO_PLL1_UNK0071

Do you have fglrx installed? Is this possible for you to switch to the fglrx
for a moment and do similar dump (using avivotool) while playing audio with it?
To make debugging quicker: can you also dump "avivotool regsrange 0x500 0x600"
just in case fglrx uses some other registers?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 46713] HDMI audio played back at a wrong rate

2012-03-09 Thread bugzilla-dae...@freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #9 from Tvrtko Ursulin  2012-03-09 
01:18:51 PST ---
Created attachment 58223
  --> https://bugs.freedesktop.org/attachment.cgi?id=58223
avivotool register dump while 44100 sample was playing

Unfortunately playback rate is still wrong. I made another register dump while
I was playing a 44100Hz wave file directly to the HDMI device. This file is
2m49s long, while playing it over HDMI takes 4m20s. Which gives us the same
apparent 28665Hz playback rate as originally observed.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

BUG: drm_crtc_helper_set_config does not work

2012-03-09 Thread Maarten Maathuis

On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen  wrote:
> So a simple case of ?disabling a CRTC and then re-enabling it.
>
> Disabling:
>
> CRTC X is originally connected to output Y
>
> 1. XRRSetCrtcConfig() ? ?is called to disable CRTC ?X
>
> 2. drm_helper_connector_dpms() ? then gets called on the connector
> connected to CRTC X,
> ? ?in the function,
> ? ?the ?connector->encoder ?is set to DPMS OFF, ? and the
> encoder->crtc ?set to DPMS OFF
> ? ?but the ?encoder->crtc ? is still CRTC X
>
> Re-enabling:
>
> 3. XRRSetCrtcConfig() ? ?is called to to enable CRTC ?X ?on output Y
>
> 4. drm_crtc_helper_set_config () ?is now called,
> suppose ? fb is not changed, ?mode is not changed, encoder is not changed
> and the ? encoder->crtc ?is not changed,
> then we have ? mode_changed == false ? ?and ?the mode is not reset
>
> So the CRTC X won't be connected to output Y.
>
> What I don't understand the code is that why ?XRRSetCrtcConfig() ?ends
> up only calling ?drm_helper_connector_dpms() ??
> I think it should do more than that, at least it should set the
> related ?encoder->crtc = NULL
>
> any comments ?
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

As far as i know DPMS designed is a simple switch, meaning that the
mode remains active, so if you do DPMS ON it should come back. If for
some reason the driver is disconnecting the encoder from the crtc,
then it is the drivers responsibility to reconnect it when DPMS ON
happens.

But don't take my word for it, others may have more/other information.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

[PATCH 3/3] drm/exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion

2012-03-09 Thread Inki Dae

From: Laurent Pinchart 

The fb_videomode structure stores the front porch and back porch in the
right_margin and left_margin fields respectively. right_margin should
thus be computed with hsync_start - hdisplay, and left_margin with
htotal - hsync_end. The same holds for the vertical direction.

   Active   Front   SyncBack
   Region   Porch   Porch
<---><><-><>

  //|
 // |
//  |..   ..
   ___

<-- xres ---><- right_margin -><- hsync_len -><- left_margin -->

< hdisplay ->
< hsync_start >
<- hsync_end >
<- htotal ->

Fix the fb_videomode <-> drm_mode_modeinfo conversion functions
accordingly.

Signed-off-by: Laurent Pinchart 
Acked-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   16 
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 618bd4d..99d5527 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -54,14 +54,14 @@ convert_to_display_mode(struct drm_display_mode *mode,
mode->vrefresh = timing->refresh;

mode->hdisplay = timing->xres;
-   mode->hsync_start = mode->hdisplay + timing->left_margin;
+   mode->hsync_start = mode->hdisplay + timing->right_margin;
mode->hsync_end = mode->hsync_start + timing->hsync_len;
-   mode->htotal = mode->hsync_end + timing->right_margin;
+   mode->htotal = mode->hsync_end + timing->left_margin;

mode->vdisplay = timing->yres;
-   mode->vsync_start = mode->vdisplay + timing->upper_margin;
+   mode->vsync_start = mode->vdisplay + timing->lower_margin;
mode->vsync_end = mode->vsync_start + timing->vsync_len;
-   mode->vtotal = mode->vsync_end + timing->lower_margin;
+   mode->vtotal = mode->vsync_end + timing->upper_margin;
mode->width_mm = panel->width_mm;
mode->height_mm = panel->height_mm;

@@ -85,14 +85,14 @@ convert_to_video_timing(struct fb_videomode *timing,
timing->refresh = drm_mode_vrefresh(mode);

timing->xres = mode->hdisplay;
-   timing->left_margin = mode->hsync_start - mode->hdisplay;
+   timing->right_margin = mode->hsync_start - mode->hdisplay;
timing->hsync_len = mode->hsync_end - mode->hsync_start;
-   timing->right_margin = mode->htotal - mode->hsync_end;
+   timing->left_margin = mode->htotal - mode->hsync_end;

timing->yres = mode->vdisplay;
-   timing->upper_margin = mode->vsync_start - mode->vdisplay;
+   timing->lower_margin = mode->vsync_start - mode->vdisplay;
timing->vsync_len = mode->vsync_end - mode->vsync_start;
-   timing->lower_margin = mode->vtotal - mode->vsync_end;
+   timing->upper_margin = mode->vtotal - mode->vsync_end;

if (mode->flags & DRM_MODE_FLAG_INTERLACE)
timing->vmode = FB_VMODE_INTERLACED;
-- 
1.7.5.4

[PATCH 2/3] drm/exynos: fix runtime_pm fimd device state on probe

2012-03-09 Thread Inki Dae

From: Marek Szyprowski 

A call to pm_runtime_set_active() forces device to be at the active
state and skips calling its runtime suspend/resume callbacks. This
results in a freeze with a new power domain code based on gen_pd. Fimd
driver does all required runtime power management calls, so this
pm_runtime_set_active call is buggy. This patch removes it and corrects
clock management in probe function (clocks are now enabled by
pm_runtime_get_sync() call).

Signed-off-by: Marek Szyprowski 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   17 ++---
 1 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 360adf2..56458ee 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -817,8 +817,6 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)
goto err_clk_get;
}

-   clk_enable(ctx->bus_clk);
-
ctx->lcd_clk = clk_get(dev, "sclk_fimd");
if (IS_ERR(ctx->lcd_clk)) {
dev_err(dev, "failed to get lcd clock\n");
@@ -826,8 +824,6 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)
goto err_bus_clk;
}

-   clk_enable(ctx->lcd_clk);
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "failed to find registers\n");
@@ -864,17 +860,11 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)
goto err_req_irq;
}

-   ctx->clkdiv = fimd_calc_clkdiv(ctx, >timing);
ctx->vidcon0 = pdata->vidcon0;
ctx->vidcon1 = pdata->vidcon1;
ctx->default_win = pdata->default_win;
ctx->panel = panel;

-   panel->timing.pixclock = clk_get_rate(ctx->lcd_clk) / ctx->clkdiv;
-
-   DRM_DEBUG_KMS("pixel clock = %d, clkdiv = %d\n",
-   panel->timing.pixclock, ctx->clkdiv);
-
subdrv = >subdrv;

subdrv->probe = fimd_subdrv_probe;
@@ -889,10 +879,15 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)

platform_set_drvdata(pdev, ctx);

-   pm_runtime_set_active(dev);
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);

+   ctx->clkdiv = fimd_calc_clkdiv(ctx, >timing);
+   panel->timing.pixclock = clk_get_rate(ctx->lcd_clk) / ctx->clkdiv;
+
+   DRM_DEBUG_KMS("pixel clock = %d, clkdiv = %d\n",
+   panel->timing.pixclock, ctx->clkdiv);
+
for (win = 0; win < WINDOWS_NR; win++)
fimd_clear_win(ctx, win);

-- 
1.7.5.4

[PATCH 1/3] drm/exynos: use correct 'exynos-drm' name for platform device

2012-03-09 Thread Inki Dae

From: Marek Szyprowski 

Currently Exynos DRM driver uses DRIVER_NAME ('exynos') name for the
core platform device. This is confusing, because it doesn't refer to the
function the platform device is performing. This patch renames the
platform device to the 'exynos-drm', which matches the convention for
naming the platform devices. The name used inside DRM subsystem has not
been changed.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 58820eb..09cc13f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -246,7 +246,7 @@ static struct platform_driver exynos_drm_platform_driver = {
.remove = __devexit_p(exynos_drm_platform_remove),
.driver = {
.owner  = THIS_MODULE,
-   .name   = DRIVER_NAME,
+   .name   = "exynos-drm",
},
 };

-- 
1.7.5.4

[PATCH 0/3] drm/exynos: updated exynos-drm-fixes

2012-03-09 Thread Inki Dae

this patch set fixes minor issues to fimd pm and porch setting.

this is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git drm-fixes
commit-id: 38aa4a568ba4c3ccba83e862a01e3e60e3b811ee

and you can refer to our working repository below:
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes

Thanks.

Laurent Pinchart (1):
  drm/exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion

Marek Szyprowski (2):
  drm/exynos: use correct 'exynos-drm' name for platform device
  drm/exynos: fix runtime_pm fimd device state on probe

 drivers/gpu/drm/exynos/exynos_drm_connector.c |   16 
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   17 ++---
 3 files changed, 15 insertions(+), 20 deletions(-)

-- 
1.7.5.4

[git pull] drm radeon fixes

2012-03-09 Thread Dave Airlie


Hi Linus,

Just some radeon fixes, one is for an oops where we run out of ioremap 
space on some big hardware systems in 32-bit mode, stuff doesn't work 
properly but at least the machine will boot.

One regression fix, and two bugs, one hw, one blit code.

I think I have some i915 stuff coming from Keith/Jesse yet.

Dave.

The following changes since commit dac12d1f5ef228e132c2457dc214e0703533b016:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-03-06 
22:31:08 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

Alex Deucher (1):
  drm/radeon/kms: fix hdmi duallink checks

Christian K?nig (1):
  drm/radeon: fix a semaphore deadlock on pre cayman asics

Dave Airlie (1):
  drm/radeon: deal with errors from framebuffer init path.

Marek Ol??k (1):
  drm/radeon/kms: set SX_MISC in the r6xx blit code (v2)

 drivers/gpu/drm/radeon/r600.c  |3 +++
 drivers/gpu/drm/radeon/r600_blit_shaders.c |8 
 drivers/gpu/drm/radeon/r600d.h |1 +
 drivers/gpu/drm/radeon/radeon_connectors.c |2 +-
 drivers/gpu/drm/radeon/radeon_display.c|   18 +++---
 drivers/gpu/drm/radeon/radeon_encoders.c   |6 ++
 drivers/gpu/drm/radeon/radeon_fb.c |   11 ++-
 drivers/gpu/drm/radeon/radeon_mode.h   |2 +-
 8 files changed, 41 insertions(+), 10 deletions(-)

[PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion

2012-03-09 Thread Corbin Simpson

On Fri, Mar 9, 2012 at 12:57 AM, James Simmons  
wrote:
> Wow I see this has remegered. Some time last year I posted a patch that
> had these routines in a generic format for people to use. I can repost
> them again if people are interested.

Yes please!

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson

Re: BUG: drm_crtc_helper_set_config does not work

2012-03-09 Thread Maarten Maathuis

On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen mile...@chromium.org wrote:
 So a simple case of  disabling a CRTC and then re-enabling it.

 Disabling:

 CRTC X is originally connected to output Y

 1. XRRSetCrtcConfig()    is called to disable CRTC  X

 2. drm_helper_connector_dpms()   then gets called on the connector
 connected to CRTC X,
    in the function,
    the  connector-encoder  is set to DPMS OFF,   and the
 encoder-crtc  set to DPMS OFF
    but the  encoder-crtc   is still CRTC X

 Re-enabling:

 3. XRRSetCrtcConfig()    is called to to enable CRTC  X  on output Y

 4. drm_crtc_helper_set_config ()  is now called,
 suppose   fb is not changed,  mode is not changed, encoder is not changed
 and the   encoder-crtc  is not changed,
 then we have   mode_changed == false    and  the mode is not reset

 So the CRTC X won't be connected to output Y.

 What I don't understand the code is that why  XRRSetCrtcConfig()  ends
 up only calling  drm_helper_connector_dpms()  ?
 I think it should do more than that, at least it should set the
 related  encoder-crtc = NULL

 any comments ?
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

As far as i know DPMS designed is a simple switch, meaning that the
mode remains active, so if you do DPMS ON it should come back. If for
some reason the driver is disconnecting the encoder from the crtc,
then it is the drivers responsibility to reconnect it when DPMS ON
happens.

But don't take my word for it, others may have more/other information.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 5/5] drm/udl: initial UDL driver (v4)

2012-03-09 Thread shawn

On Thu, 2012-03-08 at 22:59 -0800, shawn wrote:
#1 it was hell to try to apply these patches from the freedesktop.org
 mailing list archive

( http://lists.freedesktop.org/archives/dri-devel/2012-February/019283.html )
 #2 after largely fallowing the directions here
 https://wiki.ubuntu.com/KernelTeam/GitKernelBuild and apply on top of
 Linus' HEAD 9f8050c4 (march 8) I ran into this error while compiling 


Sorry, I need to apply it to drm-next

--Shawn Landden

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46713] HDMI audio played back at a wrong rate

2012-03-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #9 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-09 
01:18:51 PST ---
Created attachment 58223
  -- https://bugs.freedesktop.org/attachment.cgi?id=58223
avivotool register dump while 44100 sample was playing

Unfortunately playback rate is still wrong. I made another register dump while
I was playing a 44100Hz wave file directly to the HDMI device. This file is
2m49s long, while playing it over HDMI takes 4m20s. Which gives us the same
apparent 28665Hz playback rate as originally observed.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46713] HDMI audio played back at a wrong rate

2012-03-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #10 from Rafał Miłecki zaj...@gmail.com 2012-03-09 01:27:16 PST 
---
Ahh, sorry, I didn't understand your first problem description you posted in
this bug report. I though the playback speed is alright, just the sampling rate
used is incorrect.

The problem most probably lays in audio clocks. Values used by radeon seem to
be:
EVERGREEN_AUDIO_PLL1_MUL00075300
EVERGREEN_AUDIO_PLL1_DIV00177fa0
EVERGREEN_AUDIO_PLL1_UNK0071

Do you have fglrx installed? Is this possible for you to switch to the fglrx
for a moment and do similar dump (using avivotool) while playing audio with it?
To make debugging quicker: can you also dump avivotool regsrange 0x500 0x600
just in case fglrx uses some other registers?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46713] HDMI audio played back at a wrong rate

2012-03-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #11 from Rafał Miłecki zaj...@gmail.com 2012-03-09 01:29:31 PST 
---
(In reply to comment #5)
 Monitor is Dell 2408WFP in case it matters.

Are you using 1900x1200 resolution? Can you try some smaller one? Does it help?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46713] HDMI audio played back at a wrong rate

2012-03-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #12 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-09 
01:50:36 PST ---
(In reply to comment #11)
 (In reply to comment #5)
  Monitor is Dell 2408WFP in case it matters.
 
 Are you using 1900x1200 resolution? Can you try some smaller one? Does it 
 help?

It changes the error:

1920x1200: 4m20s = 1.53x too slow
1280x1024: 3m2s = 1.07x too slow
1024x768: 1m49s = 1.55x too fast
800x600: 1m7s = 2.52x too fast

Sound also comes with various distortions in each test.

Is this enough of a hint on what is going wrong or you would still like me to
test with fglrx? It may take some time to set it up since I have no experience
with it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 46713] HDMI audio played back at a wrong rate

2012-03-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=46713

--- Comment #13 from Rafał Miłecki zaj...@gmail.com 2012-03-09 03:04:03 PST 
---
I'm afraid I can not do anything without dump from fglrx :( There are 4 clocks
related registers we are aware of, but I don't know how else we can try to
program them. There may be also some other clock registers. I'm afraid only
dump from fglrx can give us some hints and I can't get that info from my card,
since it's working pretty well.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41265] KMS does not work on Radeon HD6700M

2012-03-09 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=41265

--- Comment #12 from gy...@gmx.de 2012-03-09 05:04:24 PST ---
Is it possible to use the external connectors with the intel card?
I am only wanting to use the external dockingstation for the additionals
connectors.
So if i can use vga and hdmi port from the dockingstaion with the intel card i
would be very happy.


[   22.377284] [drm:intel_dsm_platform_mux_info], MUX info connectors: 7
[   22.377287] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010100
[   22.377290] [drm:intel_dsm_platform_mux_info],   port id: Analog VGA
[   22.377292] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377295] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377298] [drm:intel_dsm_platform_mux_info],   hpd mux info: unknown
[   22.377301] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010400
[   22.377303] [drm:intel_dsm_platform_mux_info],   port id: LVDS
[   22.377305] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377308] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377311] [drm:intel_dsm_platform_mux_info],   hpd mux info: unknown
[   22.377313] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010300
[   22.377315] [drm:intel_dsm_platform_mux_info],   port id: DisplayPort_B
[   22.377318] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377320] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377323] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between
iGPU and dGPU
[   22.377326] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010301
[   22.377328] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_B
[   22.377331] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377334] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377336] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between
iGPU and dGPU
[   22.377339] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010302
[   22.377342] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_C
[   22.377344] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377347] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377349] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between
iGPU and dGPU
[   22.377352] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010303
[   22.377354] [drm:intel_dsm_platform_mux_info],   port id: DisplayPort_D
[   22.377357] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377360] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377362] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between
iGPU and dGPU
[   22.377365] [drm:intel_dsm_platform_mux_info], Connector id:
0x80010304
[   22.377367] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_D
[   22.377370] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed
between iGPU and dGPU
[   22.377373] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed
between iGPU and dGPU
[   22.377375] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between
iGPU and dGPU
[   22.377383] [drm:intel_dsm_pci_probe], no _DSM method for intel device

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] drm/exynos: updated exynos-drm-fixes

2012-03-09 Thread Inki Dae

this patch set fixes minor issues to fimd pm and porch setting.

this is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git drm-fixes
commit-id: 38aa4a568ba4c3ccba83e862a01e3e60e3b811ee

and you can refer to our working repository below:
git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-fixes

Thanks.

Laurent Pinchart (1):
  drm/exynos: Fix fb_videomode - drm_mode_modeinfo conversion

Marek Szyprowski (2):
  drm/exynos: use correct 'exynos-drm' name for platform device
  drm/exynos: fix runtime_pm fimd device state on probe

 drivers/gpu/drm/exynos/exynos_drm_connector.c |   16 
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |   17 ++---
 3 files changed, 15 insertions(+), 20 deletions(-)

-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/exynos: use correct 'exynos-drm' name for platform device

2012-03-09 Thread Inki Dae

From: Marek Szyprowski m.szyprow...@samsung.com

Currently Exynos DRM driver uses DRIVER_NAME ('exynos') name for the
core platform device. This is confusing, because it doesn't refer to the
function the platform device is performing. This patch renames the
platform device to the 'exynos-drm', which matches the convention for
naming the platform devices. The name used inside DRM subsystem has not
been changed.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 58820eb..09cc13f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -246,7 +246,7 @@ static struct platform_driver exynos_drm_platform_driver = {
.remove = __devexit_p(exynos_drm_platform_remove),
.driver = {
.owner  = THIS_MODULE,
-   .name   = DRIVER_NAME,
+   .name   = exynos-drm,
},
 };
 
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/exynos: fix runtime_pm fimd device state on probe

2012-03-09 Thread Inki Dae

From: Marek Szyprowski m.szyprow...@samsung.com

A call to pm_runtime_set_active() forces device to be at the active
state and skips calling its runtime suspend/resume callbacks. This
results in a freeze with a new power domain code based on gen_pd. Fimd
driver does all required runtime power management calls, so this
pm_runtime_set_active call is buggy. This patch removes it and corrects
clock management in probe function (clocks are now enabled by
pm_runtime_get_sync() call).

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   17 ++---
 1 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 360adf2..56458ee 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -817,8 +817,6 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)
goto err_clk_get;
}
 
-   clk_enable(ctx-bus_clk);
-
ctx-lcd_clk = clk_get(dev, sclk_fimd);
if (IS_ERR(ctx-lcd_clk)) {
dev_err(dev, failed to get lcd clock\n);
@@ -826,8 +824,6 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)
goto err_bus_clk;
}
 
-   clk_enable(ctx-lcd_clk);
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, failed to find registers\n);
@@ -864,17 +860,11 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)
goto err_req_irq;
}
 
-   ctx-clkdiv = fimd_calc_clkdiv(ctx, panel-timing);
ctx-vidcon0 = pdata-vidcon0;
ctx-vidcon1 = pdata-vidcon1;
ctx-default_win = pdata-default_win;
ctx-panel = panel;
 
-   panel-timing.pixclock = clk_get_rate(ctx-lcd_clk) / ctx-clkdiv;
-
-   DRM_DEBUG_KMS(pixel clock = %d, clkdiv = %d\n,
-   panel-timing.pixclock, ctx-clkdiv);
-
subdrv = ctx-subdrv;
 
subdrv-probe = fimd_subdrv_probe;
@@ -889,10 +879,15 @@ static int __devinit fimd_probe(struct platform_device 
*pdev)
 
platform_set_drvdata(pdev, ctx);
 
-   pm_runtime_set_active(dev);
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
 
+   ctx-clkdiv = fimd_calc_clkdiv(ctx, panel-timing);
+   panel-timing.pixclock = clk_get_rate(ctx-lcd_clk) / ctx-clkdiv;
+
+   DRM_DEBUG_KMS(pixel clock = %d, clkdiv = %d\n,
+   panel-timing.pixclock, ctx-clkdiv);
+
for (win = 0; win  WINDOWS_NR; win++)
fimd_clear_win(ctx, win);
 
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/exynos: Fix fb_videomode - drm_mode_modeinfo conversion

2012-03-09 Thread Inki Dae

From: Laurent Pinchart laurent.pinch...@ideasonboard.com

The fb_videomode structure stores the front porch and back porch in the
right_margin and left_margin fields respectively. right_margin should
thus be computed with hsync_start - hdisplay, and left_margin with
htotal - hsync_end. The same holds for the vertical direction.

   Active   Front   SyncBack
   Region   Porch   Porch


  //|
 // |
//  |..   ..
   ___

-- xres  right_margin -- hsync_len -- left_margin --

 hdisplay -
 hsync_start 
- hsync_end 
- htotal -

Fix the fb_videomode - drm_mode_modeinfo conversion functions
accordingly.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_connector.c |   16 
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c 
b/drivers/gpu/drm/exynos/exynos_drm_connector.c
index 618bd4d..99d5527 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
@@ -54,14 +54,14 @@ convert_to_display_mode(struct drm_display_mode *mode,
mode-vrefresh = timing-refresh;
 
mode-hdisplay = timing-xres;
-   mode-hsync_start = mode-hdisplay + timing-left_margin;
+   mode-hsync_start = mode-hdisplay + timing-right_margin;
mode-hsync_end = mode-hsync_start + timing-hsync_len;
-   mode-htotal = mode-hsync_end + timing-right_margin;
+   mode-htotal = mode-hsync_end + timing-left_margin;
 
mode-vdisplay = timing-yres;
-   mode-vsync_start = mode-vdisplay + timing-upper_margin;
+   mode-vsync_start = mode-vdisplay + timing-lower_margin;
mode-vsync_end = mode-vsync_start + timing-vsync_len;
-   mode-vtotal = mode-vsync_end + timing-lower_margin;
+   mode-vtotal = mode-vsync_end + timing-upper_margin;
mode-width_mm = panel-width_mm;
mode-height_mm = panel-height_mm;
 
@@ -85,14 +85,14 @@ convert_to_video_timing(struct fb_videomode *timing,
timing-refresh = drm_mode_vrefresh(mode);
 
timing-xres = mode-hdisplay;
-   timing-left_margin = mode-hsync_start - mode-hdisplay;
+   timing-right_margin = mode-hsync_start - mode-hdisplay;
timing-hsync_len = mode-hsync_end - mode-hsync_start;
-   timing-right_margin = mode-htotal - mode-hsync_end;
+   timing-left_margin = mode-htotal - mode-hsync_end;
 
timing-yres = mode-vdisplay;
-   timing-upper_margin = mode-vsync_start - mode-vdisplay;
+   timing-lower_margin = mode-vsync_start - mode-vdisplay;
timing-vsync_len = mode-vsync_end - mode-vsync_start;
-   timing-lower_margin = mode-vtotal - mode-vsync_end;
+   timing-upper_margin = mode-vtotal - mode-vsync_end;
 
if (mode-flags  DRM_MODE_FLAG_INTERLACE)
timing-vmode = FB_VMODE_INTERLACED;
-- 
1.7.5.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 答复: [korg]help: How to submit a kernel driver on kernel.org.

2012-03-09 Thread Ilija Hadzic



A couple of non-technical things. First, I think you are sending the patch 
to the wrong list. dri-devel is for drivers that go under drivers/gpu/drm. 
Your driver is apparently fbdev driver and thus belongs to 
linux-fb...@vger.kernel.org list (see the Maintainers file)


Second, your patch generates about 9000 coding style errors when you run 
through ./scripts/checkpatch.pl script available in the Linux kernel tree. 
You need to clean up. See also Documentation/CodingStyle. Also, you must 
break up the patch into smaller self-contained units that logically make 
sense. Nobody can review 17000 lines of code in one shot.


Last, but probably the most important. All your files have the proprietary 
license in the comment overhead. You (actually your company lawyers) have 
to decide which license you are releasing this dirver under and make sure 
it is compatible with Linux kernel (i.e. GPL) and you have to state that 
in each file that is being added.


-- Ilija


On Fri, 9 Mar 2012, [utf-8] Aaron.Chen  ?~Y~H??~J?~]? wrote:


Hi PaulAlex,

Thank you very much for your great help.

Here is the first patch.

Regards
Aaron

--
?: Paul Menzel [mailto:paulepan...@users.sourceforge.net]
: 2012???3???6??? 22:38
?: Alex Deucher
??: Aaron.Chen ?; caesar.qiu ?; 
dri-devel@lists.freedesktop.org
??: Re: [korg]help: How to submit a kernel driver on kernel.org.

Dear Aaron,


Am Dienstag, den 06.03.2012, 08:47 -0500 schrieb Alex Deucher:

On Mon, Mar 5, 2012 at 11:13 PM, Aaron.Chen  ? wrote:



Thank you very much for your guide. It's a great help for me.

But I still have a little problem with the patch thing. I'm not familiar with 
the git.
1.Shall I need to do the clone and get the source location and target directory 
first?
2.Where is the source location and target directory?
3.Our driver has pass the customer's test from kernel version 2.6.5 to 3.0.0, 
So what shall I do to submit a driver cover all these kernel version.


you can only get new features included upstream in the latest Linux kernel. So 
earliest version would be 3.4. You have to maintain you own repository for 
earlier version. But backporting should be not so much trouble if you have it 
included upstream.


4.or just email you the source code and tell you the changes?

I'm looking forward your re-guide. Thank you so much.


Your best bet it to clone Linus' git tree and then apply your patches:

1. clone Linus' git tree:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git


you can do this in between.

   cd linux
   git config --global user.name ? (Aaron Chen)
   git config --global user.email aaron.c...@siliconmotion.com


2.a) apply your first patch
   b)  if you patch adds new files to the source tree, add them:
git add path/to/files/file.c
git add path/to/files/file.h
etc.  if the patch only modifies patches that are already
in the tree, you do not need to add them.
   c) when the patch is applied commit it:
   git commit -a -s
   d) when you run the commit command you will be prompted to
enter a commit message.  The commit message has the following format:

subsystem: patch description

description of what the patch does.

Signed-off-by: Your name your_em...@domain.com

E.g.,

fb: add initial code for video 5000 graphics

This adds the initial support for the video 5000 graphics adapter.  It
supports vga and lcd connectors.

Signed-off-by: Joe Developer joe.develo...@example.com

e) repeat steps a-d for all of your patches 3. generate patches:
git format-patch -n

where n is the number of patches you committed.  E.g., if your driver
consists of 5 patches:
git format-patch -5

4. Send the patches to the list.


Aaron, Git is nowadays documented pretty well. So just use

   git help command

(like `git help commit`) to read the manual. Additionally you can just search 
for it using your favorite search engine. Interesting reads should be [1][2][3].


Thanks,

Paul


[1] http://schacon.github.com/git/user-manual.html#cleaning-up-history
[2] http://git-scm.com/documentation
[3] http://progit.org/book/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: BUG: drm_crtc_helper_set_config does not work

2012-03-09 Thread Maarten Maathuis

On Fri, Mar 9, 2012 at 5:28 PM, Yufeng Shen mile...@chromium.org wrote:
 On Fri, Mar 9, 2012 at 3:15 AM, Maarten Maathuis madman2...@gmail.com wrote:
 On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen mile...@chromium.org wrote:
 So a simple case of  disabling a CRTC and then re-enabling it.

 Disabling:

 CRTC X is originally connected to output Y

 1. XRRSetCrtcConfig()    is called to disable CRTC  X

 2. drm_helper_connector_dpms()   then gets called on the connector
 connected to CRTC X,
    in the function,
    the  connector-encoder  is set to DPMS OFF,   and the
 encoder-crtc  set to DPMS OFF
    but the  encoder-crtc   is still CRTC X

 Re-enabling:

 3. XRRSetCrtcConfig()    is called to to enable CRTC  X  on output Y

 4. drm_crtc_helper_set_config ()  is now called,
 suppose   fb is not changed,  mode is not changed, encoder is not changed
 and the   encoder-crtc  is not changed,
 then we have   mode_changed == false    and  the mode is not reset

 So the CRTC X won't be connected to output Y.

 What I don't understand the code is that why  XRRSetCrtcConfig()  ends
 up only calling  drm_helper_connector_dpms()  ?
 I think it should do more than that, at least it should set the
 related  encoder-crtc = NULL

 any comments ?
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

 As far as i know DPMS designed is a simple switch, meaning that the
 mode remains active, so if you do DPMS ON it should come back. If for
 some reason the driver is disconnecting the encoder from the crtc,
 then it is the drivers responsibility to reconnect it when DPMS ON
 happens.

 But don't take my word for it, others may have more/other information.


 Yes, I was thinking ideally DPMS call should enable/disable DPMS state, and
 XRRSetCrtcConfig call should enable/disable CRTC.

 But it seems that, when using XRRSetCrtcConfig to disable CRTC,
 the CRTC itself is disabled, the DPMS is disabled (DPMS OFF),
 and then when using XRRSetCrtcConfig to re-enable the CRTC,
 it only checks whether the CRTC that connected to the encoder is
 changed (whether a new crtc is assigned), but does not check whether
 the CRTC itself is previously disabled or not.  So it considers the encoder
 is connected to the same CRTC and does no thing to re-enable the CRTC.


 --
 Far away from the primal instinct, the song seems to fade away, the
 river get wider between your thoughts and the things we do and say.

What i meant is that you should get a DPMS ON call somewhere in the
driver. The driver should then re-enable things. If the driver
disconnects the encoder for DPMS OFF, then it will also have to
reconnect it for DPMS ON.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] xf86drmMode.h: Add header protection

2012-03-09 Thread Adam Jackson

On Thu, 2012-03-08 at 15:34 +0100, David Herrmann wrote:
 
 xf86drmMode.h is missing a header protection. xf86drm.h has one so
 just copy it
 and adjust the name.
 
 Signed-off-by: David Herrmann dh.herrm...@googlemail.com 

Applied, thanks.

- ajax


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

BUG: drm_crtc_helper_set_config does not work

答复: [korg]help: How to submit a kernel driver on kernel.org.

regression(?) 3.3-rc4 -> 3.3-rc5: drm intel hangs

[PATCH] xf86drmMode.h: Add header protection

[Bug 41265] KMS does not work on Radeon HD6700M

BUG: drm_crtc_helper_set_config does not work

[Bug 46713] HDMI audio played back at a wrong rate

for-next inclusion request: dma-buf buffer sharing framework

答复: [korg]help: How to submit a kernel driver on kernel.org.

[PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion

[Bug 46713] HDMI audio played back at a wrong rate

[Bug 46713] HDMI audio played back at a wrong rate

[Bug 46713] HDMI audio played back at a wrong rate

[Bug 46713] HDMI audio played back at a wrong rate

BUG: drm_crtc_helper_set_config does not work

[PATCH 3/3] drm/exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion

[PATCH 2/3] drm/exynos: fix runtime_pm fimd device state on probe

[PATCH 1/3] drm/exynos: use correct 'exynos-drm' name for platform device

[PATCH 0/3] drm/exynos: updated exynos-drm-fixes

[git pull] drm radeon fixes

[PATCH] drm: exynos: Fix fb_videomode <-> drm_mode_modeinfo conversion

Re: BUG: drm_crtc_helper_set_config does not work

Re: [PATCH 5/5] drm/udl: initial UDL driver (v4)

[Bug 46713] HDMI audio played back at a wrong rate

[Bug 46713] HDMI audio played back at a wrong rate

[Bug 46713] HDMI audio played back at a wrong rate

[Bug 46713] HDMI audio played back at a wrong rate

[Bug 46713] HDMI audio played back at a wrong rate

[Bug 41265] KMS does not work on Radeon HD6700M

[PATCH 0/3] drm/exynos: updated exynos-drm-fixes

[PATCH 1/3] drm/exynos: use correct 'exynos-drm' name for platform device

[PATCH 2/3] drm/exynos: fix runtime_pm fimd device state on probe

[PATCH 3/3] drm/exynos: Fix fb_videomode - drm_mode_modeinfo conversion

Re: 答复: [korg]help: How to submit a kernel driver on kernel.org.

Re: BUG: drm_crtc_helper_set_config does not work

Re: [PATCH] xf86drmMode.h: Add header protection

36 matches

Site Navigation

Mail list logo

Footer information