<chewitt>
it works nicely on 3.14 but has gpio dependencies that need reworking
<The_Coolest>
Hi chewitt
<The_Coolest>
I haven't started with mainline yet. There's a user with a I2C vfd chip, and it needs pullups enabled on the pins.
<The_Coolest>
Because the driver isn't working on his box
<The_Coolest>
narmstrong>> I still can't understand whether I can use MMIO for this?
<narmstrong>
The_Coolest: on the amlogic kernels you are to free to use whatever you want ! It’s open bar !
<The_Coolest>
aha, ok. And on mainline I'll have to use API?
<narmstrong>
But on mainline, please use the in-kernel bitbanging libraries et DT to setup the pins and driver data
<The_Coolest>
DT = device tree? That won't work
<narmstrong>
It will, it must, otherwise you can stick to the amlogic kernels
<The_Coolest>
That would require maintaining a bunch of device trees for every device.
<narmstrong>
Yep, it’s my work ;-)
<The_Coolest>
Thanks
<The_Coolest>
Well, we tried that. It lead to a lot of confusion for users.
<narmstrong>
You only need to push support for, and make sure it does not break, the reste will be done by the community
<narmstrong>
Most of these devices are very similar and you could factorize over the amlogic ref designs support
<The_Coolest>
In addition, file configuration is simple and users can do that themselves. Building a DT per device would prove a lot more time consuming.
<narmstrong>
So each device could need only a few lines of specific DT
<The_Coolest>
Yes, I know.
<The_Coolest>
One sec.
<narmstrong>
In your POV, but it won’t last in time
<narmstrong>
One day the 3.14 and 4.9 kernels won’t build anymore, and you will need to hack another kernel and redo your work
<narmstrong>
This is the long term expectation to use a vendor kernel
<The_Coolest>
I'll explain my POV. Since I'm working on a driver that targets mostly TV boxes, rather than SBCs, adding support for each individual box is a lot of work
<narmstrong>
You won’t have long term support for your device
<The_Coolest>
And adds a lot of overhead in support and upkeep
<narmstrong>
Sure, but pushing for mainline is a different goal
<The_Coolest>
I tried it, and eventually we found a way to get around this.
<The_Coolest>
Yeah, I'm aware
<The_Coolest>
Everything in the driver should be ready. If a configuration file is not there, it falls back to DT configuration.
afaerber has quit [Quit: Leaving]
<The_Coolest>
I understand that mainline support mean standardizing everything.
<The_Coolest>
means*
<The_Coolest>
I was just wondering how do I turn on the pullups on some pins via code - if possible.
<The_Coolest>
in 3.14
<steev>
narmstrong: so, not sure why but now all i'm getting with the xorg driver is X segfaults, seems to occur right after the HW_cursor_init() but not really seeing what would cause it
<narmstrong>
steev: weird, there is not hw cursor support in the kernel
trem has joined #linux-amlogic
afaerber has joined #linux-amlogic
<steev>
narmstrong: i know, that's why i'm not seeing what would cause it; also... is the r7p0 mali driver actually r7p0? a diff of the r6p1 shows... no differences
<steev>
i'm using the r6p1 mali so for now, but found that odd
<steev>
it seems it's X itself that's crashing, and the only thing i can think maybe is that i'm using gcc 8 instead of gcc 7 when X was built with gcc 7 afaik