All of lore.kernel.org
 help / color / mirror / Atom feed
From: Giulio Benetti <giulio.benetti@micronovasrl.com>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: airlied@linux.ie, wens@csie.org, dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly
Date: Wed, 28 Feb 2018 16:56:56 +0100	[thread overview]
Message-ID: <b4b4795c-6380-48fd-344f-3fb22968b1c2@micronovasrl.com> (raw)
In-Reply-To: <20180216155049.r2mc724nfluwrrbe@flea.lan>

Hi,

Il 16/02/2018 16:50, Maxime Ripard ha scritto:
> On Thu, Feb 15, 2018 at 07:05:56PM +0100, Giulio Benetti wrote:
>>> If so, and if remember the captures properly, the sampling would occur
>>> right before the rise, and not really around the fall.
>>>
>>> Would 2/3 be better here?
>>
>> Yes, you're right, 2/3 phase is better:
>>
>> 1/3 phase: https://pasteboard.co/H4VehON.png
>> 2/3 phase: https://pasteboard.co/H4Veq8a.png
>>
>> Take a look at the bit in middle(yellow) sampled by clock(blue).
>>
>> Rising edge is almost in the middle of D0 bit.
>>
>>>
>>>> According to scope captures above on both A20 and A33.
>>>> Unfortunately I don't have other boards for the other SoCs to take captures.
>>>>
>>>> What do you think?
>>>
>>> I guess we can make that part applicable to all SoCs, we haven't seen
>>> any significant differences on those part.
>>
>> So let's keep:
>> - As normal(rising edge) => IO_POL_REG "0x2 => 2/3 phase"
>> - As inverted(falling edge) => IO_POL_REG "0x0 => normal phase"
> 
> I was actually thinking 1/3 for rising, 2/3 for falling.

1/3 is almost the same waveform as D0,
having rising an falling edges almost in sync with D0.
It's not so clear because DCLK has a bad figure,
but it is that way.

2/3 instead is almost in the middle of D0 as rising.

Summarizing:
- use 0/3 as falling, then DRM_BUS_FLAG_PIXDATA_NEGEDGE
- use 2/3 as rising, then DRM_BUS_FLAG_PIXDATA_POSEDGE

I follow with a new patch using clk_set_phase function.

> 
> Maxime
> 


-- 
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642

WARNING: multiple messages have this Message-ID (diff)
From: giulio.benetti@micronovasrl.com (Giulio Benetti)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly
Date: Wed, 28 Feb 2018 16:56:56 +0100	[thread overview]
Message-ID: <b4b4795c-6380-48fd-344f-3fb22968b1c2@micronovasrl.com> (raw)
In-Reply-To: <20180216155049.r2mc724nfluwrrbe@flea.lan>

Hi,

Il 16/02/2018 16:50, Maxime Ripard ha scritto:
> On Thu, Feb 15, 2018 at 07:05:56PM +0100, Giulio Benetti wrote:
>>> If so, and if remember the captures properly, the sampling would occur
>>> right before the rise, and not really around the fall.
>>>
>>> Would 2/3 be better here?
>>
>> Yes, you're right, 2/3 phase is better:
>>
>> 1/3 phase: https://pasteboard.co/H4VehON.png
>> 2/3 phase: https://pasteboard.co/H4Veq8a.png
>>
>> Take a look at the bit in middle(yellow) sampled by clock(blue).
>>
>> Rising edge is almost in the middle of D0 bit.
>>
>>>
>>>> According to scope captures above on both A20 and A33.
>>>> Unfortunately I don't have other boards for the other SoCs to take captures.
>>>>
>>>> What do you think?
>>>
>>> I guess we can make that part applicable to all SoCs, we haven't seen
>>> any significant differences on those part.
>>
>> So let's keep:
>> - As normal(rising edge) => IO_POL_REG "0x2 => 2/3 phase"
>> - As inverted(falling edge) => IO_POL_REG "0x0 => normal phase"
> 
> I was actually thinking 1/3 for rising, 2/3 for falling.

1/3 is almost the same waveform as D0,
having rising an falling edges almost in sync with D0.
It's not so clear because DCLK has a bad figure,
but it is that way.

2/3 instead is almost in the middle of D0 as rising.

Summarizing:
- use 0/3 as falling, then DRM_BUS_FLAG_PIXDATA_NEGEDGE
- use 2/3 as rising, then DRM_BUS_FLAG_PIXDATA_POSEDGE

I follow with a new patch using clk_set_phase function.

> 
> Maxime
> 


-- 
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale ? 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642

WARNING: multiple messages have this Message-ID (diff)
From: Giulio Benetti <giulio.benetti@micronovasrl.com>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: airlied@linux.ie, wens@csie.org,
	linux-arm-kernel@lists.infradead.org,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly
Date: Wed, 28 Feb 2018 16:56:56 +0100	[thread overview]
Message-ID: <b4b4795c-6380-48fd-344f-3fb22968b1c2@micronovasrl.com> (raw)
In-Reply-To: <20180216155049.r2mc724nfluwrrbe@flea.lan>

Hi,

Il 16/02/2018 16:50, Maxime Ripard ha scritto:
> On Thu, Feb 15, 2018 at 07:05:56PM +0100, Giulio Benetti wrote:
>>> If so, and if remember the captures properly, the sampling would occur
>>> right before the rise, and not really around the fall.
>>>
>>> Would 2/3 be better here?
>>
>> Yes, you're right, 2/3 phase is better:
>>
>> 1/3 phase: https://pasteboard.co/H4VehON.png
>> 2/3 phase: https://pasteboard.co/H4Veq8a.png
>>
>> Take a look at the bit in middle(yellow) sampled by clock(blue).
>>
>> Rising edge is almost in the middle of D0 bit.
>>
>>>
>>>> According to scope captures above on both A20 and A33.
>>>> Unfortunately I don't have other boards for the other SoCs to take captures.
>>>>
>>>> What do you think?
>>>
>>> I guess we can make that part applicable to all SoCs, we haven't seen
>>> any significant differences on those part.
>>
>> So let's keep:
>> - As normal(rising edge) => IO_POL_REG "0x2 => 2/3 phase"
>> - As inverted(falling edge) => IO_POL_REG "0x0 => normal phase"
> 
> I was actually thinking 1/3 for rising, 2/3 for falling.

1/3 is almost the same waveform as D0,
having rising an falling edges almost in sync with D0.
It's not so clear because DCLK has a bad figure,
but it is that way.

2/3 instead is almost in the middle of D0 as rising.

Summarizing:
- use 0/3 as falling, then DRM_BUS_FLAG_PIXDATA_NEGEDGE
- use 2/3 as rising, then DRM_BUS_FLAG_PIXDATA_POSEDGE

I follow with a new patch using clk_set_phase function.

> 
> Maxime
> 


-- 
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-02-28 15:57 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-20 18:50 [PATCH 1/2] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE Giulio Benetti
2018-01-20 18:50 ` Giulio Benetti
2018-01-20 18:50 ` Giulio Benetti
2018-01-20 18:50 ` [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly Giulio Benetti
2018-01-20 18:50   ` Giulio Benetti
2018-01-20 18:50   ` Giulio Benetti
2018-01-22  8:51   ` Maxime Ripard
2018-01-22  8:51     ` Maxime Ripard
2018-01-22  8:51     ` Maxime Ripard
2018-01-22 20:27     ` Giulio Benetti
2018-01-22 20:27       ` Giulio Benetti
2018-01-22 20:27       ` Giulio Benetti
2018-01-24 17:38       ` Giulio Benetti
2018-01-24 17:38         ` Giulio Benetti
2018-01-24 19:37         ` Giulio Benetti
2018-01-24 19:37           ` Giulio Benetti
2018-01-24 19:37           ` Giulio Benetti
2018-01-25 15:21           ` Maxime Ripard
2018-01-25 15:21             ` Maxime Ripard
2018-01-25 15:21             ` Maxime Ripard
2018-01-25 16:50             ` Giulio Benetti
2018-01-25 16:50               ` Giulio Benetti
2018-01-26 14:56               ` Maxime Ripard
2018-01-26 14:56                 ` Maxime Ripard
2018-01-26 15:55                 ` Giulio Benetti
2018-01-26 15:55                   ` Giulio Benetti
2018-01-27 19:06                   ` Giulio Benetti
2018-01-27 22:07                   ` Giulio Benetti
2018-01-27 22:07                     ` Giulio Benetti
2018-01-27 22:07                     ` Giulio Benetti
2018-02-01 10:14                     ` Maxime Ripard
2018-02-01 10:14                       ` Maxime Ripard
2018-02-01 10:14                       ` Maxime Ripard
2018-02-01 16:09                       ` Giulio Benetti
2018-02-01 16:09                         ` Giulio Benetti
2018-02-01 16:09                         ` Giulio Benetti
2018-02-05 14:21                         ` Maxime Ripard
2018-02-05 14:21                           ` Maxime Ripard
2018-02-05 14:21                           ` Maxime Ripard
2018-01-29 12:53                   ` Maxime Ripard
2018-01-29 12:53                     ` Maxime Ripard
2018-01-29 12:53                     ` Maxime Ripard
2018-02-07 10:39           ` Maxime Ripard
2018-02-07 10:39             ` Maxime Ripard
2018-02-07 10:39             ` Maxime Ripard
2018-02-07 12:49             ` Giulio Benetti
2018-02-07 12:49               ` Giulio Benetti
2018-02-08 20:40               ` Maxime Ripard
2018-02-08 20:40                 ` Maxime Ripard
2018-02-08 20:40                 ` Maxime Ripard
2018-02-09 10:13                 ` Chen-Yu Tsai
2018-02-09 10:13                   ` Chen-Yu Tsai
2018-02-09 10:13                   ` Chen-Yu Tsai
2018-02-15 18:05                 ` Giulio Benetti
2018-02-15 18:05                   ` Giulio Benetti
2018-02-16 15:50                   ` Maxime Ripard
2018-02-16 15:50                     ` Maxime Ripard
2018-02-16 15:50                     ` Maxime Ripard
2018-02-28 15:56                     ` Giulio Benetti [this message]
2018-02-28 15:56                       ` Giulio Benetti
2018-02-28 15:56                       ` Giulio Benetti
2018-01-22  8:45 ` [PATCH 1/2] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE Maxime Ripard
2018-01-22  8:45   ` Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4b4795c-6380-48fd-344f-3fb22968b1c2@micronovasrl.com \
    --to=giulio.benetti@micronovasrl.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.