2021-05-12 09:58:24

by Michal Vokáč

[permalink] [raw]
Subject: [PATCH RESEND] ARM: dts: imx6dl-yapp4: Configure the OLED display segment offset

The imx6dl-yapp4 platform uses a GE-LX012864FWPP3N0000 OLED display.
The display consist of a 128x64 OLED panel and a SSD1305 controller.

The OLED panel resolution is 128x64 but the built-in controller default
resolution is 132x64. To display properly a segment offset needs to be
configured.

Signed-off-by: Michal Vokáč <[email protected]>
---
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
index 51972c85e207..111d4d331f98 100644
--- a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
+++ b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
@@ -373,6 +373,7 @@
solomon,height = <64>;
solomon,width = <128>;
solomon,page-offset = <0>;
+ solomon,col-offset = <4>;
solomon,prechargep2 = <15>;
reset-gpios = <&gpio_oled 1 GPIO_ACTIVE_LOW>;
vbat-supply = <&sw2_reg>;
--
2.1.4


2021-05-12 13:24:51

by Fabio Estevam

[permalink] [raw]
Subject: Re: [PATCH RESEND] ARM: dts: imx6dl-yapp4: Configure the OLED display segment offset

Hi Michal,

On Wed, May 12, 2021 at 6:55 AM Michal Vokáč <[email protected]> wrote:
>
> The imx6dl-yapp4 platform uses a GE-LX012864FWPP3N0000 OLED display.
> The display consist of a 128x64 OLED panel and a SSD1305 controller.
>
> The OLED panel resolution is 128x64 but the built-in controller default
> resolution is 132x64. To display properly a segment offset needs to be
> configured.
>
> Signed-off-by: Michal Vokáč <[email protected]>

Next time you could submit it as a patch series.

Reviewed-by: Fabio Estevam <[email protected]>

2021-05-23 04:08:09

by Shawn Guo

[permalink] [raw]
Subject: Re: [PATCH RESEND] ARM: dts: imx6dl-yapp4: Configure the OLED display segment offset

On Wed, May 12, 2021 at 11:55:14AM +0200, Michal Vokáč wrote:
> The imx6dl-yapp4 platform uses a GE-LX012864FWPP3N0000 OLED display.
> The display consist of a 128x64 OLED panel and a SSD1305 controller.
>
> The OLED panel resolution is 128x64 but the built-in controller default
> resolution is 132x64. To display properly a segment offset needs to be
> configured.
>
> Signed-off-by: Michal Vokáč <[email protected]>

Why are you resending? Please state reason when you resend.


Shawn

> ---
> arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
> index 51972c85e207..111d4d331f98 100644
> --- a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
> +++ b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
> @@ -373,6 +373,7 @@
> solomon,height = <64>;
> solomon,width = <128>;
> solomon,page-offset = <0>;
> + solomon,col-offset = <4>;
> solomon,prechargep2 = <15>;
> reset-gpios = <&gpio_oled 1 GPIO_ACTIVE_LOW>;
> vbat-supply = <&sw2_reg>;
> --
> 2.1.4
>

2021-05-24 09:00:36

by Michal Vokáč

[permalink] [raw]
Subject: Re: [PATCH RESEND] ARM: dts: imx6dl-yapp4: Configure the OLED display segment offset

On 23. 05. 21 5:49, Shawn Guo wrote:
> On Wed, May 12, 2021 at 11:55:14AM +0200, Michal Vokáč wrote:
>> The imx6dl-yapp4 platform uses a GE-LX012864FWPP3N0000 OLED display.
>> The display consist of a 128x64 OLED panel and a SSD1305 controller.
>>
>> The OLED panel resolution is 128x64 but the built-in controller default
>> resolution is 132x64. To display properly a segment offset needs to be
>> configured.
>>
>> Signed-off-by: Michal Vokáč <[email protected]>
>
> Why are you resending? Please state reason when you resend.

I can't tell where but a while ago I read in some documentation
that if you do not get any response for aprox. two weeks you
can/should resend the patch in case it fell through the cracks.
I sent these patches in the middle of April, four weeks ago,
and have got no replies since then. So I [RESEND PATCH] these.

I totally understand that you, and all maintainers and reviewers
in general, are very busy so it may take a long time to reply.

AFAIK one does not need to state a reason for RESEND PATCH.
The word RESEND itself should explain the reason. This is not v2,
where I would of course describe what has changed.

Please correct me if my understanding of this part of the submitting
process is incorrect.

Thank you,
Michal

2021-06-13 08:37:08

by Shawn Guo

[permalink] [raw]
Subject: Re: [PATCH RESEND] ARM: dts: imx6dl-yapp4: Configure the OLED display segment offset

On Mon, May 24, 2021 at 10:59:14AM +0200, Michal Vokáč wrote:
> On 23. 05. 21 5:49, Shawn Guo wrote:
> > On Wed, May 12, 2021 at 11:55:14AM +0200, Michal Vokáč wrote:
> > > The imx6dl-yapp4 platform uses a GE-LX012864FWPP3N0000 OLED display.
> > > The display consist of a 128x64 OLED panel and a SSD1305 controller.
> > >
> > > The OLED panel resolution is 128x64 but the built-in controller default
> > > resolution is 132x64. To display properly a segment offset needs to be
> > > configured.
> > >
> > > Signed-off-by: Michal Vokáč <[email protected]>
> >
> > Why are you resending? Please state reason when you resend.
>
> I can't tell where but a while ago I read in some documentation
> that if you do not get any response for aprox. two weeks you
> can/should resend the patch in case it fell through the cracks.
> I sent these patches in the middle of April, four weeks ago,
> and have got no replies since then. So I [RESEND PATCH] these.

No. You can send a ping if there is no response for 2~3 weeks but not
RESEND. RESEND is normally used to refresh aged patches that needs to
be rebased to the latest release, or to make some minor update that
doesn't deserve a new version, like error in commit log etc.

>
> I totally understand that you, and all maintainers and reviewers
> in general, are very busy so it may take a long time to reply.
>
> AFAIK one does not need to state a reason for RESEND PATCH.
> The word RESEND itself should explain the reason. This is not v2,
> where I would of course describe what has changed.

No. Always state the reason for resending. Maintainers do not know why
you are resending.

Shawn

>
> Please correct me if my understanding of this part of the submitting
> process is incorrect.
>
> Thank you,
> Michal

2021-06-14 07:05:23

by Michal Vokáč

[permalink] [raw]
Subject: Re: [PATCH RESEND] ARM: dts: imx6dl-yapp4: Configure the OLED display segment offset

On 13. 06. 21 10:35, Shawn Guo wrote:
> On Mon, May 24, 2021 at 10:59:14AM +0200, Michal Vokáč wrote:
>> On 23. 05. 21 5:49, Shawn Guo wrote:
>>> On Wed, May 12, 2021 at 11:55:14AM +0200, Michal Vokáč wrote:
>>>> The imx6dl-yapp4 platform uses a GE-LX012864FWPP3N0000 OLED display.
>>>> The display consist of a 128x64 OLED panel and a SSD1305 controller.
>>>>
>>>> The OLED panel resolution is 128x64 but the built-in controller default
>>>> resolution is 132x64. To display properly a segment offset needs to be
>>>> configured.
>>>>
>>>> Signed-off-by: Michal Vokáč <[email protected]>
>>>
>>> Why are you resending? Please state reason when you resend.
>>
>> I can't tell where but a while ago I read in some documentation
>> that if you do not get any response for aprox. two weeks you
>> can/should resend the patch in case it fell through the cracks.
>> I sent these patches in the middle of April, four weeks ago,
>> and have got no replies since then. So I [RESEND PATCH] these.
>
> No. You can send a ping if there is no response for 2~3 weeks but not
> RESEND. RESEND is normally used to refresh aged patches that needs to
> be rebased to the latest release, or to make some minor update that
> doesn't deserve a new version, like error in commit log etc.
>
>>
>> I totally understand that you, and all maintainers and reviewers
>> in general, are very busy so it may take a long time to reply.
>>
>> AFAIK one does not need to state a reason for RESEND PATCH.
>> The word RESEND itself should explain the reason. This is not v2,
>> where I would of course describe what has changed.
>
> No. Always state the reason for resending. Maintainers do not know why
> you are resending.
>

OK, fair enough, I will do so next time.
Thank you for your time to explain this.

Michal