vianpl
Posts: 2
Joined: Thu Nov 29, 2018 9:23 am

Display's interrupt pin question

Thu Nov 29, 2018 9:48 am

Hi,

I've been working on getting the touchscreen to work with mainline Linux. I used "disable_touchscreen=1" and modified the relevant upstream driver poll the touchscreen directly trough I2C. Seems to work fine :).

One thing I can't seem to achieve is to get interrupts from the int pin on the display's board. Am I missing something? Should I enable them somehow? I checked it with my logic analyzer, while polling the touchscreen the signal is stuck low.

I also realized that disabling the firmware touchscreen polling also disabled the back-light functionality. Is there any way to bypass that restriction? or even access the registers directly?

Thanks for your help!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6055
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Display's interrupt pin question

Thu Nov 29, 2018 10:54 am

vianpl wrote:
Thu Nov 29, 2018 9:39 am
Hi,

I've been working on getting the touchscreen to work with mainline Linux. I used "disable_touchscreen=1" and modified the relevant upstream driver poll the touchscreen directly trough I2C. Seems to work fine :).

One thing I can't seem to achieve is to get interrupts from the int pin on the display's board. Am I missing something? Should I enable them somehow?
Interrupts aren't used. Leave it disconnected.
vianpl wrote:I also realized that disabling the firmware touchscreen polling also disabled the back-light functionality. Is there any way to bypass that restriction? or even access the registers directly?
The backlight is controlled through a small Atmel processor on the I2C bus. I2C address 0x45.
No guarantees on this, but it appears to be a 2 byte write of 0x86 <pwm value>. Values below 128 appear to be mapped to 0 in the firmware for some reason (probably it's not bright enough to see anything).
Please note that that Atmel is also responsible for configuring the TC358762 bridge chip, therefore the firmware WILL be talking to it during the early stages of boot via i2c0.

And based on your rpi-linux post, please be very aware that connecting i2c1 onto the header of the display board has just bridged i2c0 and i2c1 on most boards. The I2C controller does not support multiple masters, therefore i2c0 is then effectively dead, the camera won't work (it shares the pins with the display), and generally you've introduced the potential for odd I2C issues.

You'd be better off sorting the pinmuxing correctly for using i2c0 via the relevant GPIOs. I had started using i2c-mux-pinctrl to allow Linux to address the buses correctly, but got bogged down in other things.
https://lists.infradead.org/pipermail/l ... 07210.html
https://lists.infradead.org/pipermail/l ... 07214.html
It still doesn't get over the issue of the firmware / ARM arbitration over the i2c0, but at least means that you aren't causing further grief by bridging the two buses.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1354
Joined: Sat Sep 10, 2011 11:43 am

Re: Display's interrupt pin question

Thu Nov 29, 2018 11:18 am

Also since you're now directly controlling the I2C from the ARM then the GPU can no longer control the PMU and it's likely to cause problems with crashing as soon as it moves to turbo...

Or are you using some mailbox to communicate the I2C commands across to the GPU?

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6055
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Display's interrupt pin question

Thu Nov 29, 2018 11:26 am

gsh wrote:
Thu Nov 29, 2018 11:18 am
Also since you're now directly controlling the I2C from the ARM then the GPU can no longer control the PMU and it's likely to cause problems with crashing as soon as it moves to turbo...
Has that changed again then? I thought the PMU I2C was bitbashed specifically to avoid issues of contention on i2c0. The exception being the 3Bv1 (which never went to production) where the PMU is on 44&45 along with the camera and display.

Suffice to say you do need to tread a little carefully here.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1354
Joined: Sat Sep 10, 2011 11:43 am

Re: Display's interrupt pin question

Thu Nov 29, 2018 2:12 pm

You're right, it's just the camera and display on that bus. But it shouldn't use the bus directly...

Would it instead be better to develop a mailbox interface to access the I2C interface in a suitably locked manor?

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

vianpl
Posts: 2
Joined: Thu Nov 29, 2018 9:23 am

Re: Display's interrupt pin question

Thu Nov 29, 2018 7:30 pm

Thanks both for your replies.

6by9, I adapted and applied your patches, all is good, the touchscreen now works trough I2C0 "cleanly". That said, I get from your conversation with Gordon that there is always a chance for the firmware to access the I2C0 for camera related purposes. That pretty much invalidates the solution, right?

Is creating a firmware interface to I2C0 realistic from your side? I'd take that over using the firmware touchscreen/backlight driver. From my perspective the less firmware we have to run the better. As much as I'd love to assist it would really depend on you.

Regards,
Nicolas

Return to “Official Foundation Display”