Hi,
On 19 May 2015 at 19:43, Gustavo Padovan wrote:
> 2015-05-19 Tobias Jakobi :
>> so Daniel helped me track down this issue. It came from an incorrect
>> 'clock-frequency' entry in my DTS. The freq was 50. Daniel recommended
>> 7060 which works 'fine' (and according to modetest
OK,
so Daniel helped me track down this issue. It came from an incorrect
'clock-frequency' entry in my DTS. The freq was 50. Daniel
recommended 7060 which works 'fine' (and according to modetest
produces a 59Hz mode). I say 'fine' because I can't confirm that FIMD is
actually working.
Hey Daniel,
On 2015-05-19 16:06, Daniel Stone wrote:
> Hi Tobias,
>
> On 19 May 2015 at 14:53, Tobias Jakobi
> wrote:
>> On 2015-05-18 23:02, Gustavo Padovan wrote:
>>> So better try this. Ideally fimd_mode_fixup should go away too, I'll
>>> do a
>>> proper
>>> patch once we know this works.
Hello,
On 2015-05-18 23:02, Gustavo Padovan wrote:
> 2015-05-18 Daniel Stone :
>
>> Hi,
>>
>> On Monday, May 18, 2015, Gustavo Padovan wrote:
>>
>> > Hi Tobias,
>> >
>> > 2015-05-15 Tobias Jakobi >:
>> > > I did another run with drm.debug=0xff and also tried to figure out where
>> > the
>> >
Hi Tobias,
2015-05-19 Tobias Jakobi :
> OK,
>
> so Daniel helped me track down this issue. It came from an incorrect
> 'clock-frequency' entry in my DTS. The freq was 50. Daniel recommended
> 7060 which works 'fine' (and according to modetest produces a 59Hz
> mode). I say 'fine'
Hi Tobias,
On 19 May 2015 at 14:53, Tobias Jakobi wrote:
> On 2015-05-18 23:02, Gustavo Padovan wrote:
>> So better try this. Ideally fimd_mode_fixup should go away too, I'll do a
>> proper
>> patch once we know this works.
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>
Hi,
On Monday, May 18, 2015, Gustavo Padovan wrote:
> Hi Tobias,
>
> 2015-05-15 Tobias Jakobi >:
> > I did another run with drm.debug=0xff and also tried to figure out where
> the
> > div-by-zero comes from.
> >
> > The only division I see is in fimd_calc_clkdiv() (which is called by
> >
2015-05-18 Daniel Stone :
> Hi,
>
> On Monday, May 18, 2015, Gustavo Padovan wrote:
>
> > Hi Tobias,
> >
> > 2015-05-15 Tobias Jakobi >:
> > > I did another run with drm.debug=0xff and also tried to figure out where
> > the
> > > div-by-zero comes from.
> > >
> > > The only division I see is
Hi Tobias,
2015-05-15 Tobias Jakobi :
> Hello,
>
> I did another run with drm.debug=0xff and also tried to figure out where the
> div-by-zero comes from.
>
> The only division I see is in fimd_calc_clkdiv() (which is called by
> fimd_commit()). So it looks like 'ideal_clk' is zero when calling
Hello,
I did another run with drm.debug=0xff and also tried to figure out where
the div-by-zero comes from.
The only division I see is in fimd_calc_clkdiv() (which is called by
fimd_commit()). So it looks like 'ideal_clk' is zero when calling
DIV_ROUND_UP().
'htotal' and 'vtotal' can't be
Hello,
I've just tested 'modetest' with the fix applied, and while the nullptr
deference goes away, I now get a division by zero.
modetest output:
Encoders:
id crtctypepossible crtcs possible clones
22 0 TMDS0x0001 0x
30 29 TMDS
Hi Inki and Tobias,
2015-05-12 Gustavo Padovan :
> 2015-05-10 Inki Dae :
>
> > 2015-05-09 21:13 GMT+09:00 Tobias Jakobi :
> > > Hello Inki,
> > >
> > >
> > > Inki Dae wrote:
> > >> Hi,
> > >>
> > >> 2015-05-09 6:51 GMT+09:00 Tobias Jakobi :
> > >>> Hello,
> > >>>
> > >>> I've tested this on my
2015-05-10 Inki Dae :
> 2015-05-09 21:13 GMT+09:00 Tobias Jakobi :
> > Hello Inki,
> >
> >
> > Inki Dae wrote:
> >> Hi,
> >>
> >> 2015-05-09 6:51 GMT+09:00 Tobias Jakobi :
> >>> Hello,
> >>>
> >>> I've tested this on my Hardkernel Odroid-X2 (connected via HDMI to a
> >>> 1080p panel).
> >>>
> >>>
2015-05-09 21:13 GMT+09:00 Tobias Jakobi :
> Hello Inki,
>
>
> Inki Dae wrote:
>> Hi,
>>
>> 2015-05-09 6:51 GMT+09:00 Tobias Jakobi :
>>> Hello,
>>>
>>> I've tested this on my Hardkernel Odroid-X2 (connected via HDMI to a
>>> 1080p panel).
>>>
>>> Run the usual modetest tests (just primary plane,
Hi,
2015-05-09 6:51 GMT+09:00 Tobias Jakobi :
> Hello,
>
> I've tested this on my Hardkernel Odroid-X2 (connected via HDMI to a
> 1080p panel).
>
> Run the usual modetest tests (just primary plane, primary plane with
> vsync, primary plane with overlay, primary plane with overlay and video
>
And here's the drm.debug=0xff output leading to the oops:
> [ 109.575582] [drm:drm_stub_open]
> [ 109.575609] [drm:drm_open_helper] pid = 2430, minor = 0
> [ 109.575630] [drm:ipp_subdrv_open] done priv[0xed9b7e10]
> [ 109.575647] [drm:drm_setup]
> [ 109.575699] [drm:drm_ioctl] pid=2430,
Tobias Jakobi wrote:
> Hello Inki,
>
>
> Inki Dae wrote:
>> Hi,
>>
>> 2015-05-09 6:51 GMT+09:00 Tobias Jakobi :
>>> Hello,
>>>
>>> I've tested this on my Hardkernel Odroid-X2 (connected via HDMI to a
>>> 1080p panel).
>>>
>>> Run the usual modetest tests (just primary plane, primary plane with
Hello Inki,
Inki Dae wrote:
> Hi,
>
> 2015-05-09 6:51 GMT+09:00 Tobias Jakobi :
>> Hello,
>>
>> I've tested this on my Hardkernel Odroid-X2 (connected via HDMI to a
>> 1080p panel).
>>
>> Run the usual modetest tests (just primary plane, primary plane with
>> vsync, primary plane with overlay,
Hello,
I've tested this on my Hardkernel Odroid-X2 (connected via HDMI to a
1080p panel).
Run the usual modetest tests (just primary plane, primary plane with
vsync, primary plane with overlay, primary plane with overlay and video
overlay, overlay partially outside of crtc area, etc.) and
Hi Inki,
2015-05-07 Inki Dae :
> Hi,
>
> On 2015ë
05ì 07ì¼ 06:45, Gustavo Padovan wrote:
> > Hi Inki and Joonyoung.
> >
> > Any thoughts on this?
>
> You need to resolve one issue that booting is still halted when one more
> crtc drivers are enabled, which is a dead lock issue incurred
Hi,
On 2015ë
05ì 07ì¼ 06:45, Gustavo Padovan wrote:
> Hi Inki and Joonyoung.
>
> Any thoughts on this?
You need to resolve one issue that booting is still halted when one more
crtc drivers are enabled, which is a dead lock issue incurred by
register_framebuffer call. For this, I pointed
Hi Inki and Joonyoung.
Any thoughts on this?
2015-04-30 Gustavo Padovan :
> Hi,
>
> Here goes the full support for atomic modesetting on exynos. I've
> split the patches in the various phases of atomic support.
>
> v2: fixes comments by Joonyoung
> - remove unused var in patch 09
>
Hi,
Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.
v2: fixes comments by Joonyoung
- remove unused var in patch 09
- use ->disable instead of outdated ->dpms in hdmi code
- remove WARN_ON from
Hi,
On 04/09/2015 12:14 AM, Inki Dae wrote:
> On 2015ë
04ì 08ì¼ 03:39, Gustavo Padovan wrote:
>> Hi Inki,
>>
>> 2015-04-07 Inki Dae :
>>
>>> On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
2015-04-06 19:46 GMT+09:00 Inki Dae :
> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
On 2015ë
04ì 08ì¼ 03:39, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-04-07 Inki Dae :
>
>> On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
>>> 2015-04-06 19:46 GMT+09:00 Inki Dae :
On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
I don't know if I can really help with this, but I'm going to try to
reproduce this on my board tomorrow.
With best wishes,
Tobias
Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-04-07 Inki Dae :
>
>> On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
>>> 2015-04-06 19:46 GMT+09:00 Inki Dae :
On
On 2015ë
04ì 07ì¼ 16:06, Inki Dae wrote:
> On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
>> 2015-04-06 19:46 GMT+09:00 Inki Dae :
>>> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
From: Gustavo Padovan
Hi,
Here goes the full support for atomic modesetting on
On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
> 2015-04-06 19:46 GMT+09:00 Inki Dae :
>> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> Hi,
>>>
>>> Here goes the full support for atomic modesetting on exynos. I've
>>> split the patches in the various phases
Hi Inki,
2015-04-07 Inki Dae :
> On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
> > 2015-04-06 19:46 GMT+09:00 Inki Dae :
> >> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
> >>> From: Gustavo Padovan
> >>>
> >>> Hi,
> >>>
> >>> Here goes the full support for atomic modesetting on exynos.
Hi Inki,
2015-04-07 Inki Dae :
> On 2015ë
04ì 07ì¼ 16:06, Inki Dae wrote:
> > On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
> >> 2015-04-06 19:46 GMT+09:00 Inki Dae :
> >>> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
>
2015-04-06 19:46 GMT+09:00 Inki Dae :
> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> Hi,
>>
>> Here goes the full support for atomic modesetting on exynos. I've
>> split the patches in the various phases of atomic support.
>>
>> These patches sits on top of
On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Hi,
>
> Here goes the full support for atomic modesetting on exynos. I've
> split the patches in the various phases of atomic support.
>
> These patches sits on top of the clean up patches I've sent yesterday
> to
From: Gustavo Padovan
Hi,
Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.
These patches sits on top of the clean up patches I've sent yesterday
to this mailing list[1].
v2: fixes
From: Gustavo Padovan
Hi,
Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.
These patches sits on top of the clean up patches I've sent yesterday
to this mailing list[1].
v2: fixes
From: Gustavo Padovan
Hi,
Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.
These patches sits on top of the clean up patches I've sent yesterday
to this mailing list[1].
35 matches
Mail list logo