PinebookPro misc drivers..

[Søren Schmidt]

On 21 Mar 2021, at 11.46, Emmanuel Vadot <manu at bidouilliste.com> wrote:
> 
> On Sun, 21 Mar 2021 11:19:57 +0100
> Emmanuel Vadot <manu at bidouilliste.com <mailto:manu at bidouilliste.com>> wrote:
> 
>> On Sun, 21 Mar 2021 11:02:28 +0100
>> Søren Schmidt <soren.schmidt at gmail.com> wrote:
>> 
>>> On 10 Mar 2021, at 16.01, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>>>> 
>>>> On Wed, 10 Mar 2021 15:29:21 +0100
>>>> Søren Schmidt <soren.schmidt at gmail.com> wrote:
>>>> 
>>>>> Hi
>>>>> 
>>>>> I?ve uploaded the latest from my PinebookPro collection here:
>>>>> https://people.freebsd.org/~sos/PinebookPro/ <https://people.freebsd.org/~sos/PinebookPro/>
>>>>> 
>>>>> Comment,, bugs, etc welcome?
>>>> 
>>>> Few comments,
>>>> 
>>>> - Could you at least share patches generated with git diff ?
>>> 
>>> No git here, but added patches to the one file (rk_gpio.c) that isn?t new :)
>> 
>> Why was all the softc variable renamed, this makes reviewing much
>> harder than it should be.


I just cleaned up stuff to my liking, whether you want this stuff in the official sources I dont care much :)

>>>> - rk_gpiokeys.c doesn't seems correct, we already have
>>>> sys/dev/gpio/gpiokeys.c so patch this one if it isn't enough for lid
>>>> switch need.
>>> 
>>> Well, the stock drivers handling of this is, well, less than optimal and the lid support is pretty unique to the pbp so I decided to go this way as to not ?pollute? the original.
>> 
>> Less than optimal why ?
>> Pretty unique why ?
>> I don't see anything unique for the pbp in the dts and if the driver
>> that we already have is missing some stuff it should be patched.
> 
> So, since I'm a nice guy I've looked at the driver.
> It is unique because you made it unique.
> Upon lid switch even if the lid closed you deactivate the lcd power
> gpio control pin (which is not referenced in the dts node for the lid
> switch) using a really a gross hack. We should never do that.
> You've also written that you haven't been able to get interrupts when
> you open the lid but since you only configure it with
> GPIO_INTR_EDGE_FALLING that's normal. What is happening if you
> configure it with GPIO_INTR_EDGE_BOTH ? If it's still not working it
> probably shows a problem in your gpio patch that add interrupts support.

Well, there is NO interrupt generated whether you look for raising of failling edges, that’s why I resorted to plain polling (as explained).
I made it unique for my purposes, so it doesn’t conflict with anything.
But anyhow interrupts etc works on any ohter pin but apparently at least my device has issue here.

> 
>>>> I could comment more if I would be able to diff more easily.
>>> 
>>> As stated above there is now a patch for you for rk_gpio.c the rest has nothing to diff against.
>>> 
>>> BTW I added support for writing an updated u-boot-2021.01 to the SPI flash on the pbp (also works for rockpro64), so one can boot from eMMC, SDcard, USB and NVMe with kbd/mouse support and screen output from the first u-boot output.
>> 
>> And again no patches make this really hard to review.
>> Please create a phabricator account and post patches there, we can
>> then have a proper discussion.


That is just too timeconsuming for me, I’m just trying to be nice and post what I’ve done to get my pinebookpro into a useful state for daily usage, you can pick and choose form that og just ignore it, I’m happy either way...

—
Søren Schmidt
sos at deepcore.dk / sos at freebsd.org
"So much code to hack, so little time"