From: Sam Ravnborg <[email protected]>
The atmel_lcdfb had code to save/restore power state.
This is not needed so drop it.
Introduce backlight_is_brightness() to make logic simpler.
Signed-off-by: Sam Ravnborg <[email protected]>
Cc: Nicolas Ferre <[email protected]>
Cc: Alexandre Belloni <[email protected]>
Cc: Ludovic Desroches <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
index 1fc8de4ecbeb..d297b3892637 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -49,7 +49,6 @@ struct atmel_lcdfb_info {
struct clk *lcdc_clk;
struct backlight_device *backlight;
- u8 bl_power;
u8 saved_lcdcon;
u32 pseudo_palette[16];
@@ -109,32 +108,18 @@ static u32 contrast_ctr = ATMEL_LCDC_PS_DIV8
static int atmel_bl_update_status(struct backlight_device *bl)
{
struct atmel_lcdfb_info *sinfo = bl_get_data(bl);
- int power = sinfo->bl_power;
- int brightness = bl->props.brightness;
+ int brightness;
- /* REVISIT there may be a meaningful difference between
- * fb_blank and power ... there seem to be some cases
- * this doesn't handle correctly.
- */
- if (bl->props.fb_blank != sinfo->bl_power)
- power = bl->props.fb_blank;
- else if (bl->props.power != sinfo->bl_power)
- power = bl->props.power;
-
- if (brightness < 0 && power == FB_BLANK_UNBLANK)
- brightness = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
- else if (power != FB_BLANK_UNBLANK)
- brightness = 0;
+ brightness = backlight_get_brightness(bl);
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, brightness);
+
if (contrast_ctr & ATMEL_LCDC_POL_POSITIVE)
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR,
brightness ? contrast_ctr : 0);
else
lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, contrast_ctr);
- bl->props.fb_blank = bl->props.power = sinfo->bl_power = power;
-
return 0;
}
@@ -155,8 +140,6 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
struct backlight_properties props;
struct backlight_device *bl;
- sinfo->bl_power = FB_BLANK_UNBLANK;
-
if (sinfo->backlight)
return;
@@ -173,7 +156,6 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
sinfo->backlight = bl;
bl->props.power = FB_BLANK_UNBLANK;
- bl->props.fb_blank = FB_BLANK_UNBLANK;
bl->props.brightness = atmel_bl_get_brightness(bl);
}
--
2.34.1
On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint <[email protected]> wrote:
>From: Sam Ravnborg <[email protected]>
>
>The atmel_lcdfb had code to save/restore power state.
>This is not needed so drop it.
>
>Introduce backlight_is_brightness() to make logic simpler.
>
>Signed-off-by: Sam Ravnborg <[email protected]>
>Cc: Nicolas Ferre <[email protected]>
>Cc: Alexandre Belloni <[email protected]>
>Cc: Ludovic Desroches <[email protected]>
>Cc: [email protected]
>Cc: [email protected]
>---
> drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------
> 1 file changed, 3 insertions(+), 21 deletions(-)
>
>diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
>index 1fc8de4ecbeb..d297b3892637 100644
>--- a/drivers/video/fbdev/atmel_lcdfb.c
>+++ b/drivers/video/fbdev/atmel_lcdfb.c
>@@ -49,7 +49,6 @@ struct atmel_lcdfb_info {
> struct clk *lcdc_clk;
>
> struct backlight_device *backlight;
>- u8 bl_power;
> u8 saved_lcdcon;
>
> u32 pseudo_palette[16];
>@@ -109,32 +108,18 @@ static u32 contrast_ctr = ATMEL_LCDC_PS_DIV8
> static int atmel_bl_update_status(struct backlight_device *bl)
> {
> struct atmel_lcdfb_info *sinfo = bl_get_data(bl);
>- int power = sinfo->bl_power;
>- int brightness = bl->props.brightness;
>+ int brightness;
>
>- /* REVISIT there may be a meaningful difference between
>- * fb_blank and power ... there seem to be some cases
>- * this doesn't handle correctly.
>- */
>- if (bl->props.fb_blank != sinfo->bl_power)
>- power = bl->props.fb_blank;
>- else if (bl->props.power != sinfo->bl_power)
>- power = bl->props.power;
>-
>- if (brightness < 0 && power == FB_BLANK_UNBLANK)
>- brightness = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
>- else if (power != FB_BLANK_UNBLANK)
>- brightness = 0;
>+ brightness = backlight_get_brightness(bl);
>
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, brightness);
>+
> if (contrast_ctr & ATMEL_LCDC_POL_POSITIVE)
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR,
> brightness ? contrast_ctr : 0);
> else
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, contrast_ctr);
>
>- bl->props.fb_blank = bl->props.power = sinfo->bl_power = power;
>-
> return 0;
> }
>
>@@ -155,8 +140,6 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
> struct backlight_properties props;
> struct backlight_device *bl;
>
>- sinfo->bl_power = FB_BLANK_UNBLANK;
>-
> if (sinfo->backlight)
> return;
>
>@@ -173,7 +156,6 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
> sinfo->backlight = bl;
>
> bl->props.power = FB_BLANK_UNBLANK;
>- bl->props.fb_blank = FB_BLANK_UNBLANK;
> bl->props.brightness = atmel_bl_get_brightness(bl);
> }
>
>
Hi Sam,
I’d submitted quite a few more of these previously (and you’d reviewed them), see e.g. the thread starting at https://lkml.org/lkml/2022/6/7/4365, and yesterday, https://lkml.org/lkml/2023/1/6/520, https://lkml.org/lkml/2023/1/6/656, https://lkml.org/lkml/2023/1/6/970, https://lkml.org/lkml/2023/1/6/643, and https://lkml.org/lkml/2023/1/6/680. There are a few more, I can find them if it’s any use.
Regards,
Stephen
Hi Stephen.
On Sat, Jan 07, 2023 at 09:36:47PM +0100, Stephen Kitt wrote:
> On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint <[email protected]> wrote:
> >From: Sam Ravnborg <[email protected]>
> >
> >The atmel_lcdfb had code to save/restore power state.
> >This is not needed so drop it.
> >
> >Introduce backlight_is_brightness() to make logic simpler.
> >
> >Signed-off-by: Sam Ravnborg <[email protected]>
> >Cc: Nicolas Ferre <[email protected]>
> >Cc: Alexandre Belloni <[email protected]>
> >Cc: Ludovic Desroches <[email protected]>
> >Cc: [email protected]
> >Cc: [email protected]
> >---
> > drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------
> > 1 file changed, 3 insertions(+), 21 deletions(-)
...
>
> Hi Sam,
>
> I’d submitted quite a few more of these previously (and you’d reviewed them), see e.g. the thread starting at https://lkml.org/lkml/2022/6/7/4365, and yesterday, https://lkml.org/lkml/2023/1/6/520, https://lkml.org/lkml/2023/1/6/656, https://lkml.org/lkml/2023/1/6/970, https://lkml.org/lkml/2023/1/6/643, and https://lkml.org/lkml/2023/1/6/680. There are a few more, I can find them if it’s any use.
The patches from yesterday was what triggered me to resurrect an old
branch of mine where I had done something similar. I had lost all
memory of reviewing similar patches from you.
Helge - could you pick the reviewed patches from:
https://lore.kernel.org/all/[email protected]/
[This is the same mail as Stephen refer to above - looked up via lore].
Stephen - I expect Daniel/Lee to take care of the patches from yesterday.
If you can look up other pending patches from you please do so, so we
can have them applied.
Preferably with links to lore - as this makes it easier to apply them.
Review of what is unique in this set would be appreciated.
Sam
On 8 January 2023 08:45:46 CET, Stephen Kitt <[email protected]> wrote:
>On 7 January 2023 21:53:46 CET, Sam Ravnborg <[email protected]> wrote:
>>Hi Stephen.
>>
>>On Sat, Jan 07, 2023 at 09:36:47PM +0100, Stephen Kitt wrote:
>>> On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint <[email protected]> wrote:
>>> >From: Sam Ravnborg <[email protected]>
>>> >
>>> >The atmel_lcdfb had code to save/restore power state.
>>> >This is not needed so drop it.
>>> >
>>> >Introduce backlight_is_brightness() to make logic simpler.
>>> >
>>> >Signed-off-by: Sam Ravnborg <[email protected]>
>>> >Cc: Nicolas Ferre <[email protected]>
>>> >Cc: Alexandre Belloni <[email protected]>
>>> >Cc: Ludovic Desroches <[email protected]>
>>> >Cc: [email protected]
>>> >Cc: [email protected]
>>> >---
>>> > drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------
>>> > 1 file changed, 3 insertions(+), 21 deletions(-)
>>...
>>>
>>> Hi Sam,
>>>
>>> I’d submitted quite a few more of these previously (and you’d reviewed them), see e.g. the thread starting at https://lkml.org/lkml/2022/6/7/4365, and yesterday, https://lkml.org/lkml/2023/1/6/520, https://lkml.org/lkml/2023/1/6/656, https://lkml.org/lkml/2023/1/6/970, https://lkml.org/lkml/2023/1/6/643, and https://lkml.org/lkml/2023/1/6/680. There are a few more, I can find them if it’s any use.
>>
>>The patches from yesterday was what triggered me to resurrect an old
>>branch of mine where I had done something similar. I had lost all
>>memory of reviewing similar patches from you.
>>
>>
>>Helge - could you pick the reviewed patches from:
>>https://lore.kernel.org/all/[email protected]/
>>[This is the same mail as Stephen refer to above - looked up via lore].
>>
>>Stephen - I expect Daniel/Lee to take care of the patches from yesterday.
>>If you can look up other pending patches from you please do so, so we
>>can have them applied.
>>Preferably with links to lore - as this makes it easier to apply them.
>>
>>Review of what is unique in this set would be appreciated.
>>
>> Sam
>
>Hi Sam,
>
>Here are my pending patches from last June on lore:
>
>* https://lore.kernel.org/lkml/[email protected]/
>* https://lore.kernel.org/lkml/[email protected]/
>* https://lore.kernel.org/lkml/[email protected]/
>* https://lore.kernel.org/lkml/[email protected]/
>
>I’ll send reviews of your other patches later today or tomorrow.
>
>Regards,
>
>Stephen
And the auxdisplay patch, v1:
https://lore.kernel.org/lkml/[email protected]/
and v2:
https://lore.kernel.org/lkml/[email protected]/
Regards,
Stephen
On 7 January 2023 21:53:46 CET, Sam Ravnborg <[email protected]> wrote:
>Hi Stephen.
>
>On Sat, Jan 07, 2023 at 09:36:47PM +0100, Stephen Kitt wrote:
>> On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint <[email protected]> wrote:
>> >From: Sam Ravnborg <[email protected]>
>> >
>> >The atmel_lcdfb had code to save/restore power state.
>> >This is not needed so drop it.
>> >
>> >Introduce backlight_is_brightness() to make logic simpler.
>> >
>> >Signed-off-by: Sam Ravnborg <[email protected]>
>> >Cc: Nicolas Ferre <[email protected]>
>> >Cc: Alexandre Belloni <[email protected]>
>> >Cc: Ludovic Desroches <[email protected]>
>> >Cc: [email protected]
>> >Cc: [email protected]
>> >---
>> > drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------
>> > 1 file changed, 3 insertions(+), 21 deletions(-)
>...
>>
>> Hi Sam,
>>
>> I’d submitted quite a few more of these previously (and you’d reviewed them), see e.g. the thread starting at https://lkml.org/lkml/2022/6/7/4365, and yesterday, https://lkml.org/lkml/2023/1/6/520, https://lkml.org/lkml/2023/1/6/656, https://lkml.org/lkml/2023/1/6/970, https://lkml.org/lkml/2023/1/6/643, and https://lkml.org/lkml/2023/1/6/680. There are a few more, I can find them if it’s any use.
>
>The patches from yesterday was what triggered me to resurrect an old
>branch of mine where I had done something similar. I had lost all
>memory of reviewing similar patches from you.
>
>
>Helge - could you pick the reviewed patches from:
>https://lore.kernel.org/all/[email protected]/
>[This is the same mail as Stephen refer to above - looked up via lore].
>
>Stephen - I expect Daniel/Lee to take care of the patches from yesterday.
>If you can look up other pending patches from you please do so, so we
>can have them applied.
>Preferably with links to lore - as this makes it easier to apply them.
>
>Review of what is unique in this set would be appreciated.
>
> Sam
Hi Sam,
Here are my pending patches from last June on lore:
* https://lore.kernel.org/lkml/[email protected]/
* https://lore.kernel.org/lkml/[email protected]/
* https://lore.kernel.org/lkml/[email protected]/
* https://lore.kernel.org/lkml/[email protected]/
I’ll send reviews of your other patches later today or tomorrow.
Regards,
Stephen
On 1/7/23 21:53, Sam Ravnborg wrote:
> Hi Stephen.
>
> On Sat, Jan 07, 2023 at 09:36:47PM +0100, Stephen Kitt wrote:
>> On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint <[email protected]> wrote:
>>> From: Sam Ravnborg <[email protected]>
>>>
>>> The atmel_lcdfb had code to save/restore power state.
>>> This is not needed so drop it.
>>>
>>> Introduce backlight_is_brightness() to make logic simpler.
>>>
>>> Signed-off-by: Sam Ravnborg <[email protected]>
>>> Cc: Nicolas Ferre <[email protected]>
>>> Cc: Alexandre Belloni <[email protected]>
>>> Cc: Ludovic Desroches <[email protected]>
>>> Cc: [email protected]
>>> Cc: [email protected]
>>> ---
>>> drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------
>>> 1 file changed, 3 insertions(+), 21 deletions(-)
> ...
>>
>> Hi Sam,
>>
>> I’d submitted quite a few more of these previously (and you’d reviewed them), see e.g. the thread starting at https://lkml.org/lkml/2022/6/7/4365, and yesterday, https://lkml.org/lkml/2023/1/6/520, https://lkml.org/lkml/2023/1/6/656, https://lkml.org/lkml/2023/1/6/970, https://lkml.org/lkml/2023/1/6/643, and https://lkml.org/lkml/2023/1/6/680. There are a few more, I can find them if it’s any use.
>
> The patches from yesterday was what triggered me to resurrect an old
> branch of mine where I had done something similar. I had lost all
> memory of reviewing similar patches from you.
>
>
> Helge - could you pick the reviewed patches from:
> https://lore.kernel.org/all/[email protected]/
> [This is the same mail as Stephen refer to above - looked up via lore].
I just pulled those 7 patches into fbdev/for-next.
If you need more, please let me know,
Thanks!
Helge
>
> Stephen - I expect Daniel/Lee to take care of the patches from yesterday.
> If you can look up other pending patches from you please do so, so we
> can have them applied.
> Preferably with links to lore - as this makes it easier to apply them.
>
> Review of what is unique in this set would be appreciated.
>
> Sam
Hi Helge,
> >
> > Helge - could you pick the reviewed patches from:
> > https://lore.kernel.org/all/[email protected]/
> > [This is the same mail as Stephen refer to above - looked up via lore].
>
> I just pulled those 7 patches into fbdev/for-next.
> If you need more, please let me know,
Thanks, we have one pending patch for atmel_lcdfb, but it need a small
adjustment before it is ready.
With this all fbdev drivers have the backlight_properties.fb_blank
removed.
Sam
Hi Stephen.
> Here are my pending patches from last June on lore:
>
All patches are handled I think except this:
> * https://lore.kernel.org/lkml/[email protected]/
Can I ask you to drop the assignment that is not needed, and resend with
the collected acks/r-b.
With this, then all fbdev patches are handled.
Sam
On Sat, 07 Jan 2023, Sam Ravnborg via B4 Submission Endpoint <[email protected]> wrote:
> From: Sam Ravnborg <[email protected]>
>
> The atmel_lcdfb had code to save/restore power state.
> This is not needed so drop it.
>
> Introduce backlight_is_brightness() to make logic simpler.
backlight_is_brightness?
BR,
Jani.
>
> Signed-off-by: Sam Ravnborg <[email protected]>
> Cc: Nicolas Ferre <[email protected]>
> Cc: Alexandre Belloni <[email protected]>
> Cc: Ludovic Desroches <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> ---
> drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------
> 1 file changed, 3 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
> index 1fc8de4ecbeb..d297b3892637 100644
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -49,7 +49,6 @@ struct atmel_lcdfb_info {
> struct clk *lcdc_clk;
>
> struct backlight_device *backlight;
> - u8 bl_power;
> u8 saved_lcdcon;
>
> u32 pseudo_palette[16];
> @@ -109,32 +108,18 @@ static u32 contrast_ctr = ATMEL_LCDC_PS_DIV8
> static int atmel_bl_update_status(struct backlight_device *bl)
> {
> struct atmel_lcdfb_info *sinfo = bl_get_data(bl);
> - int power = sinfo->bl_power;
> - int brightness = bl->props.brightness;
> + int brightness;
>
> - /* REVISIT there may be a meaningful difference between
> - * fb_blank and power ... there seem to be some cases
> - * this doesn't handle correctly.
> - */
> - if (bl->props.fb_blank != sinfo->bl_power)
> - power = bl->props.fb_blank;
> - else if (bl->props.power != sinfo->bl_power)
> - power = bl->props.power;
> -
> - if (brightness < 0 && power == FB_BLANK_UNBLANK)
> - brightness = lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
> - else if (power != FB_BLANK_UNBLANK)
> - brightness = 0;
> + brightness = backlight_get_brightness(bl);
>
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_VAL, brightness);
> +
> if (contrast_ctr & ATMEL_LCDC_POL_POSITIVE)
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR,
> brightness ? contrast_ctr : 0);
> else
> lcdc_writel(sinfo, ATMEL_LCDC_CONTRAST_CTR, contrast_ctr);
>
> - bl->props.fb_blank = bl->props.power = sinfo->bl_power = power;
> -
> return 0;
> }
>
> @@ -155,8 +140,6 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
> struct backlight_properties props;
> struct backlight_device *bl;
>
> - sinfo->bl_power = FB_BLANK_UNBLANK;
> -
> if (sinfo->backlight)
> return;
>
> @@ -173,7 +156,6 @@ static void init_backlight(struct atmel_lcdfb_info *sinfo)
> sinfo->backlight = bl;
>
> bl->props.power = FB_BLANK_UNBLANK;
> - bl->props.fb_blank = FB_BLANK_UNBLANK;
> bl->props.brightness = atmel_bl_get_brightness(bl);
> }
--
Jani Nikula, Intel Open Source Graphics Center
On 1/9/23 21:18, Stephen Kitt wrote:
> On Sun, 8 Jan 2023 18:26:12 +0100, Helge Deller <[email protected]> wrote:
>
>> On 1/7/23 21:53, Sam Ravnborg wrote:
>>> Hi Stephen.
>>>
>>> On Sat, Jan 07, 2023 at 09:36:47PM +0100, Stephen Kitt wrote:
>>>> On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint
>>>> <[email protected]> wrote:
>>>>> From: Sam Ravnborg <[email protected]>
>>>>>
>>>>> The atmel_lcdfb had code to save/restore power state.
>>>>> This is not needed so drop it.
>>>>>
>>>>> Introduce backlight_is_brightness() to make logic simpler.
>>>>>
>>>>> Signed-off-by: Sam Ravnborg <[email protected]>
>>>>> Cc: Nicolas Ferre <[email protected]>
>>>>> Cc: Alexandre Belloni <[email protected]>
>>>>> Cc: Ludovic Desroches <[email protected]>
>>>>> Cc: [email protected]
>>>>> Cc: [email protected]
>>>>> ---
>>>>> drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------
>>>>> 1 file changed, 3 insertions(+), 21 deletions(-)
>>> ...
>>>>
>>>> Hi Sam,
>>>>
>>>> I’d submitted quite a few more of these previously (and you’d reviewed
>>>> them), see e.g. the thread starting at
>>>> https://lkml.org/lkml/2022/6/7/4365, and yesterday,
>>>> https://lkml.org/lkml/2023/1/6/520, https://lkml.org/lkml/2023/1/6/656,
>>>> https://lkml.org/lkml/2023/1/6/970, https://lkml.org/lkml/2023/1/6/643,
>>>> and https://lkml.org/lkml/2023/1/6/680. There are a few more, I can find
>>>> them if it’s any use.
>>>
>>> The patches from yesterday was what triggered me to resurrect an old
>>> branch of mine where I had done something similar. I had lost all
>>> memory of reviewing similar patches from you.
>>>
>>>
>>> Helge - could you pick the reviewed patches from:
>>> https://lore.kernel.org/all/[email protected]/
>>> [This is the same mail as Stephen refer to above - looked up via lore].
>>
>> I just pulled those 7 patches into fbdev/for-next.
>> If you need more, please let me know,
>
> Please pull
> https://lore.kernel.org/lkml/[email protected]/ too, it
> completes the fbdev set. (It’s a re-send of
> https://lore.kernel.org/lkml/[email protected]/).
Done.
Thanks!
Helge
On Mon, 9 Jan 2023 20:53:44 +0100, Stephen Kitt <[email protected]> wrote:
> On Sun, 8 Jan 2023 21:24:20 +0100, Sam Ravnborg <[email protected]> wrote:
> > > Here are my pending patches from last June on lore:
> > >
> >
> > All patches are handled I think except this:
> > > * https://lore.kernel.org/lkml/[email protected]/
> > >
> >
> > Can I ask you to drop the assignment that is not needed, and resend with
> > the collected acks/r-b.
> >
> > With this, then all fbdev patches are handled.
>
> Ah yes, it was revised as
> https://lore.kernel.org/lkml/[email protected]/ which
> only got one ack (from you,
> https://lore.kernel.org/lkml/[email protected]/). Should I
> resend that or is that usable as-is? Or would it be better if I sent all the
> fbdev patches again (collecting all the acks and reviews)?
Since the others are already in fbdev/for-next, I’ve just resent v2 of this
patch with your ack.
Regards,
Stephen
Hi Sam,
On Sun, 8 Jan 2023 21:24:20 +0100, Sam Ravnborg <[email protected]> wrote:
> > Here are my pending patches from last June on lore:
> >
>
> All patches are handled I think except this:
> > * https://lore.kernel.org/lkml/[email protected]/
>
> Can I ask you to drop the assignment that is not needed, and resend with
> the collected acks/r-b.
>
> With this, then all fbdev patches are handled.
Ah yes, it was revised as
https://lore.kernel.org/lkml/[email protected]/ which
only got one ack (from you,
https://lore.kernel.org/lkml/[email protected]/). Should I
resend that or is that usable as-is? Or would it be better if I sent all the
fbdev patches again (collecting all the acks and reviews)?
Regards,
Stephen
On Sun, 8 Jan 2023 18:26:12 +0100, Helge Deller <[email protected]> wrote:
> On 1/7/23 21:53, Sam Ravnborg wrote:
> > Hi Stephen.
> >
> > On Sat, Jan 07, 2023 at 09:36:47PM +0100, Stephen Kitt wrote:
> >> On 7 January 2023 19:26:15 CET, Sam Ravnborg via B4 Submission Endpoint
> >> <[email protected]> wrote:
> >>> From: Sam Ravnborg <[email protected]>
> >>>
> >>> The atmel_lcdfb had code to save/restore power state.
> >>> This is not needed so drop it.
> >>>
> >>> Introduce backlight_is_brightness() to make logic simpler.
> >>>
> >>> Signed-off-by: Sam Ravnborg <[email protected]>
> >>> Cc: Nicolas Ferre <[email protected]>
> >>> Cc: Alexandre Belloni <[email protected]>
> >>> Cc: Ludovic Desroches <[email protected]>
> >>> Cc: [email protected]
> >>> Cc: [email protected]
> >>> ---
> >>> drivers/video/fbdev/atmel_lcdfb.c | 24 +++---------------------
> >>> 1 file changed, 3 insertions(+), 21 deletions(-)
> > ...
> >>
> >> Hi Sam,
> >>
> >> I’d submitted quite a few more of these previously (and you’d reviewed
> >> them), see e.g. the thread starting at
> >> https://lkml.org/lkml/2022/6/7/4365, and yesterday,
> >> https://lkml.org/lkml/2023/1/6/520, https://lkml.org/lkml/2023/1/6/656,
> >> https://lkml.org/lkml/2023/1/6/970, https://lkml.org/lkml/2023/1/6/643,
> >> and https://lkml.org/lkml/2023/1/6/680. There are a few more, I can find
> >> them if it’s any use.
> >
> > The patches from yesterday was what triggered me to resurrect an old
> > branch of mine where I had done something similar. I had lost all
> > memory of reviewing similar patches from you.
> >
> >
> > Helge - could you pick the reviewed patches from:
> > https://lore.kernel.org/all/[email protected]/
> > [This is the same mail as Stephen refer to above - looked up via lore].
>
> I just pulled those 7 patches into fbdev/for-next.
> If you need more, please let me know,
Please pull
https://lore.kernel.org/lkml/[email protected]/ too, it
completes the fbdev set. (It’s a re-send of
https://lore.kernel.org/lkml/[email protected]/).
Thanks,
Stephen