Hi,
On 08-11-16 19:43, Maxime Ripard wrote:
On Mon, Nov 07, 2016 at 10:24:44AM +0100, Hans de Goede wrote:
On Sun, Nov 06, 2016 at 06:54:11PM +0800, Icenowy Zheng wrote:
06.11.2016, 18:13, "Hans de Goede" <[email protected]>:
Hi,
On 06-11-16 04:35, Chen-Yu Tsai wrote:
Hi everyone,
I spent a bit of time adding DRM support for the A23 yesterday.
Icenowy successfully got DRM working for the A33 Q8 tablets.
It occurred to me today that we have 2 types of panels for the
A33 Q8 tablets, one is 800x480 and the other is 1024x600. However
we are currently sharing the same dts file for both, and only
U-boot knows about the different resolutions.
I see 2 ways to fix this. One would be to provide a separate
dts file for the 1024x600 variant. The other would be to get
U-boot to patch the dts file.
Either way would require users upgrading U-boot, or at least
their boot scripts in the first case, though.
Any ideas?
Since we already have 2 u-boot configs for this having 2 dts files
seems like the best solution to me.
Maybe for compatibility we need 3 dts files...
1. Q8 dts : everything except display (For users migrated from the old
single-dt time)
2. Q8 800x480 dts : #include <Q8 dts>, /panel/compatible = "urt,umsh-8596md-t"
/* This compatible is what Chen-Yu used in sun5i-q8, and I used it also on my
A33 Q8 */
3. Q8 1024x600 dts : #include <Q8 dts>, /panel/compatible = foo
I'm not sure why we need both actually.
Even if the resolutions are the same, chances are the panel won't be,
and will have different timings.
So far all 800x480 and all 1024x600 q8 a23/a33 tablets work
with a single set of timings (per resolution).
That's a rather fragile assumption.
So far it holds true for the 8 a23/a33 800x480 tablets I have
(the a13 ones do need different timings)
And they probably have different
tolerancies anyway, so you'll want different compatible anyway.
One problem here is we really do not know what the tolerances
are, it is not like these come with datasheets for the LCD
panel, or even with any form of usable model number on the LCD
for that matter.
I guess your plan is simply to use different compatible,
There is no plan, since a single set of timing works for
all tablets encountered so far).
Well, we still need to have a backup plan in case it's not the case
anymore in the future.
I guess the backup plan would be a:
configs/q8_a23_tablet_800x480b_defconfig
Since there simply is no way to detect the lcd panel, there
is EDID or any communication with the panel at all for that
matter, we just blindly feed the panel data and hope it
gets displayed.
E.g. for the a33 tablets both 800x480 and 1024x600 versions
will happily boot with the wrong timings and just only
show part of the screen, or show black borders
(except at the bottom where you get garbage when only
sending 800x480 pixels to a 1024x600 LCD).
then we don't really need two different device
trees in the first place, do we?
It all depends on how closely we want to couple u-boot and the kernel.
Either we need to have u-boot patch in the right panel compatible, but
only on q8_a33_tablet configs, or we stick with the one defconfig
1 dts pattern used everywhere.
Basically the problem is that currently both:
configs/q8_a33_tablet_1024x600_defconfig
configs/q8_a33_tablet_800x480_defconfig
Refer to the same dts, fixing that is really easy and
consistent with what we do in the other 100 sunxi defconfig-s
u-boot now has. Where as hot patching the panel compatible
requires q8_a33_tablet specific code in u-boot which I
would rather avoid.
I definitely get that, but weren't you supposed to deal with that in
your q8-manager?
The q8-manager is for dealing with detectable hw differences, the
reason why we have 2 defconfigs for the a33 tablet is because the
panel cannot be detected. Making the q8-manager do the panel
compatible patches would require somehow telling it which defconfig
we booted with, at which point we might just as well directly
set the panel compatible.
And you'll have to have q8 specific code somewhere anyway, so if it's
not in U-Boot, it's going to be somewhere else, it's just moving the
problem to someone else indefinitely.
Right, we do need q8 specific code somewhere, but so far I still hope
to put it in the kernel (which is probably naive of me).
But you have a point, we could have a bit of q8 specific code in u-boot
to do the panel compatible patching (since we will likely need more
q8 specific code anyways). Still it would be easier to just have
2 different dts files, what are your objections against that ?
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
