[v6,00/25] Make charlcd device independent
mbox series

Message ID 20201103095828.515831-1-poeschel@lemonage.de
Headers show
Series
  • Make charlcd device independent
Related show

Message

Lars Poeschel Nov. 3, 2020, 9:58 a.m. UTC
From: Lars Poeschel <poeschel@lemonage.de>

This tries to make charlcd device independent. At the moment hd44780
device specific code is contained deep in charlcd. This moves this out
into a hd44780_common module, where the two hd44780 drivers we have at
the moment (hd44780 and panel) can use this from. The goal is that at
the end other drivers can use the charlcd interface.
I add one such driver for a modtronix lcd displau  with the last patch.
I submitted this already some time ago, where the wish was so split
this into smaller chunks what I try to do with this patchset.

This is v6 of the patchset. I address a two review comments from Miguel.
I fixed the Kconfig menu of auxdisplay. It does now present a submenu
again. And I fixed some typos in the commit message of patch 23.

As a note to patch 23:
This might slightly change behaviour.
On hd44780 displays with one or two lines the previous implementation
did still write characters to the buffer of the display even if they are
currently not visible. The shift_display command could be used so set
the "viewing window" to a new position in the buffer and then you could
see the characters previously written.
This described behaviour does not work for hd44780 displays with more
than two display lines. There simply is not enough buffer.
So the behaviour was a bit inconsistens across different displays.
The new behaviour is to stop writing character at the end of a visible
line, even if there would be room in the buffer. This allows us to have
an easy implementation, that should behave equal on all supported
displays. This is not hd44780 hardware dependent anymore.

Link: https://lore.kernel.org/lkml/20191016082430.5955-1-poeschel@lemonage.de/
Link: https://lore.kernel.org/lkml/CANiq72kS-u_Xd_m+2CQVh-JCncPf1XNXrXAZ=4z+mze8fwv2kw@mail.gmail.com/

Changes in v6:
- patch 2: Fix Kconfig so that auxdisplay is now a submenu again
- patch 23: Fix some typos in commit message

Changes in v5:
- patch 1: Fix a commit message typo: of -> on
- patch 2: Remove some unnecessary newlines
- patch 8: Fix some typos
- patch 14: Fix commit message typo: it's -> its
- patch 15: this patch is squashed together from the former individual
  hd44780_common_ function patches
- patch 16: combined two cleanup patches
- patch 17: I did previously undo commit 3f03b6498 which was a mistake.
  This is now corrected.
- patch 24: Picked up Robs Reviewed-by
- patch 25: use hex_to_bin like in commit 3f03b6498 but for the lcd2s.c
  file

Changes in v4:
- modtronix -> Modtronix in new lcd2s driver
- Kconfig: remove "default n" in new lcd2s driver

Changes in v3:
- Fix some typos in Kconfig stuff
- Fix kernel test robot reported error: Missed EXPORT_SYMBOL_GPL
- new patch to reduce display timeout
- better patch description to why not move cursor beyond end of a line
- Fixed make dt_binding_doc errors

Changes in v2:
- split whole patch into many smaller chunks
- device tree doc in yaml

Lars Poeschel (25):
  auxdisplay: Use an enum for charlcd  backlight on/off ops
  auxdisplay: Introduce hd44780_common.[ch]
  auxdisplay: Move hwidth and bwidth to struct hd44780_common
  auxdisplay: Move ifwidth to struct hd44780_common
  auxdisplay: Move write_data pointer to hd44780_common
  auxdisplay: Move write_cmd pointers to hd44780 drivers
  auxdisplay: Move addr out of charlcd_priv
  auxdisplay: hd44780_common_print
  auxdisplay: provide hd44780_common_gotoxy
  auxdisplay: add home to charlcd_ops
  auxdisplay: Move clear_display to hd44780_common
  auxdisplay: make charlcd_backlight visible to hd44780_common
  auxdisplay: Make use of enum for backlight on / off
  auxdisplay: Move init_display to hd44780_common
  auxdisplay: implement various hd44780_common_ functions
  auxdisplay: cleanup unnecessary hd44780 code in charlcd
  auxdisplay: Move char redefine code to hd44780_common
  auxdisplay: Call charlcd_backlight in place
  auxdisplay: hd44780_common: Reduce clear_display timeout
  auxdisplay: hd44780: Remove clear_fast
  auxdisplay: charlcd: replace last device specific stuff
  auxdisplay: Change gotoxy calling interface
  auxdisplay: charlcd: Do not print chars at end of line
  auxdisplay: lcd2s DT binding doc
  auxdisplay: add a driver for lcd2s character display

 .../bindings/auxdisplay/modtronix,lcd2s.yaml  |  58 +++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 drivers/auxdisplay/Kconfig                    |  30 ++
 drivers/auxdisplay/Makefile                   |   2 +
 drivers/auxdisplay/charlcd.c                  | 412 +++++-------------
 drivers/auxdisplay/charlcd.h                  |  86 +++-
 drivers/auxdisplay/hd44780.c                  | 120 +++--
 drivers/auxdisplay/hd44780_common.c           | 361 +++++++++++++++
 drivers/auxdisplay/hd44780_common.h           |  33 ++
 drivers/auxdisplay/lcd2s.c                    | 403 +++++++++++++++++
 drivers/auxdisplay/panel.c                    | 180 ++++----
 11 files changed, 1237 insertions(+), 450 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/auxdisplay/modtronix,lcd2s.yaml
 create mode 100644 drivers/auxdisplay/hd44780_common.c
 create mode 100644 drivers/auxdisplay/hd44780_common.h
 create mode 100644 drivers/auxdisplay/lcd2s.c

Comments

Miguel Ojeda Nov. 4, 2020, 1:30 p.m. UTC | #1
On Tue, Nov 3, 2020 at 10:58 AM <poeschel@lemonage.de> wrote:
>
> Changes in v6:
> - patch 2: Fix Kconfig so that auxdisplay is now a submenu again
> - patch 23: Fix some typos in commit message

Thanks a lot for all the work, Lars. Queued in -next.

Cheers,
Miguel
Lars Poeschel Nov. 6, 2020, 10:11 a.m. UTC | #2
On Wed, Nov 04, 2020 at 02:30:04PM +0100, Miguel Ojeda wrote:
> Thanks a lot for all the work, Lars. Queued in -next.

I got an email [1] with a report about a build failure in
hd44780_common. The fix is simple but I don't know the process from here
on. Should I post a v7 of the whole patchset or only a follow-up patch
for the fix ?

Regards,
Lars

[1]: https://lore.kernel.org/linux-next/77c23d41-b652-bd08-12ef-6d3403f0ad8c@infradead.org/T/#u
Miguel Ojeda Nov. 6, 2020, 12:17 p.m. UTC | #3
On Fri, Nov 6, 2020 at 11:11 AM Lars Poeschel <poeschel@lemonage.de> wrote:
>
> I got an email [1] with a report about a build failure in
> hd44780_common. The fix is simple but I don't know the process from here
> on. Should I post a v7 of the whole patchset or only a follow-up patch
> for the fix ?

Either would work (I can rebase it on my side). However, in order to
give credit to Randy, if the fix is integrated into a previous patch,
then I am not sure where we would put the Reported-by.

Randy, what people usually do for your reports on -next (or what do you prefer)?

Cheers,
Miguel
Randy Dunlap Nov. 6, 2020, 4:35 p.m. UTC | #4
On 11/6/20 4:17 AM, Miguel Ojeda wrote:
> On Fri, Nov 6, 2020 at 11:11 AM Lars Poeschel <poeschel@lemonage.de> wrote:
>>
>> I got an email [1] with a report about a build failure in
>> hd44780_common. The fix is simple but I don't know the process from here
>> on. Should I post a v7 of the whole patchset or only a follow-up patch
>> for the fix ?
> 
> Either would work (I can rebase it on my side). However, in order to
> give credit to Randy, if the fix is integrated into a previous patch,
> then I am not sure where we would put the Reported-by.
> 
> Randy, what people usually do for your reports on -next (or what do you prefer)?

Hi Miguel,

I'm not sure that I understand the question...

Include
Reported-by: Randy Dunlap <rdunlap@infradead.org>
if possible. If not, then don't. It's not a big deal.

Integrate the fix from Lars in whatever way works for you.

cheers. :)
Miguel Ojeda Nov. 9, 2020, 9:53 a.m. UTC | #5
Hi Randy,

On Fri, Nov 6, 2020 at 5:35 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> I'm not sure that I understand the question...
>
> Include
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> if possible. If not, then don't. It's not a big deal.
>
> Integrate the fix from Lars in whatever way works for you.

Thanks Randy -- I asked Stephen Rothwell and he told me even for -next
patches on top are preferred, unless the bug is bad enough. In which
case, the [] notation can still be used to give credit.

Cheers,
Miguel