All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Mariusz Gorski <marius.gorski@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: staging: panel: suggestions needed
Date: Sat, 6 Dec 2014 09:41:08 +0100	[thread overview]
Message-ID: <20141206084108.GA3404@1wt.eu> (raw)
In-Reply-To: <20141202080214.GA4762@sudip-PC>

Hi Sudip,

[ CCing Mariusz who's currently cleaning up the driver ]

On Tue, Dec 02, 2014 at 01:32:14PM +0530, Sudip Mukherjee wrote:
> Hi,
> I have been looking at your panel driver, and am attaching a 20x4 alphanueric
> lcd to it. Will start testing it in a few days as and when I get time. Looks
> like, it is receiving mostly checkpatch and sparse cleanups.

yes mostly.

> Just wanted your opinion on few things I was thinking:
> 	1) Number of lines you have fixed to 2 and 40 char per line. since I am
> 	going to connect 20x4 , i need to remember that after displaying 20
> 	character in 1st line, next char will come to 3rd line. instead why
> 	don't we make the option of number of line to 4 ?

Feel free to do so. I never had the luck to own a 4-line LCD so this
was never even planned. And yes, I remember something about 4-line LCDs
using tricks such as 2x40 addressing being split into 4x20.

> 	2) The lcd commands you are writing to the lcd in an escape sequence
> 	while writing to the lcd. Instead of that why don't we use ioctl for
> 	lcd commands, and writing to the device will involve only sending data
> 	to lcd ?

Because you cannot send that from a script. It's just as if you had to use
an ioctl to clear your terminal, inverse its video or to move its cursor,
it would not be very convenient.

> 	3) You have given fixed minor number in your code. Any problem if we
> 	make it dynamic ?

No objection, but I think we should keep a config option to bind to the
old minor. The rationale behind this is that this driver is mostly used
in embedded systems with a fixed /dev.

> 	4) For now I am only attaching a LCD, but I also want to attach a
> 	keypad to it. Can you please let me know about the schematic of the
> 	keypad connection? I can find out from the code, but I have not yet
> 	seen the keypad code.

It used to be documented as an ASCII-art diagram but I can't find that
anymore :-/ IIRC you had to wire buttons between some of the outputs and
some of the inputs. From what I remember, it was possible to detect that
an input is :
  - tied to ground
  - tied to a data line
  - tied to a control line

I found this comment in the old source file :
  "document 24 keys keyboard (3 rows of 8 cols, 32 diodes + 2 inputs)"

So maybe we only use data lines and not control lines.

And the keypad code periodically scans all outputs and notes inputs states.
The Nexcom profile works with the keypad, though I don't have the wiring
in mind. It uses 4 keys. It should be easy to find that from the code
though.

Hmmm I found an old description of 2001 (kernel 2.2.18) from the one of the
first circuit I made (with a serial lcd). It involved the smartcard detector
(now removed) and 6 keys :

strobe -> lcd.strobe
d0 -> lcd.serial.din (serial) + lcd.parallel.d0 + keypad.k0
d1 -> d7 => lcd.parallel.d1-d7 + keypad.k1-k7
ack <- smartcard.dout
busy <-
pe <-  (keypad common1 if more than 8 keys)
select <- keypad common0
autofeed -> lcd.serial.backlight / lcd.parallel.rs
error <- smartcard.detector
init -> 
select_in ->

And here's the module load command I used to run :
insmod /tmp/panel-0.8.0.o parport=0 lcd_enabled=2 keypad_enabled=1 lcd_width=16 lcd_hwidth=16 lcd_height=2

Hoping this helps,
Willy


  reply	other threads:[~2014-12-06  8:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-02  8:02 staging: panel: suggestions needed Sudip Mukherjee
2014-12-06  8:41 ` Willy Tarreau [this message]
2014-12-06 10:09   ` Sudip Mukherjee
2014-12-06 10:21     ` Willy Tarreau
2014-12-06 10:28     ` Mariusz Gorski
2014-12-06 15:14       ` Sudip Mukherjee

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=20141206084108.GA3404@1wt.eu \
    --to=w@1wt.eu \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marius.gorski@gmail.com \
    --cc=sudipm.mukherjee@gmail.com \
    /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.