On Mon, Mar 26, 2018 at 04:40:21PM +0200, Enric Balletbo Serra wrote: > Hi Pavel, > > 2018-03-26 12:42 GMT+02:00 Pavel Machek <pavel@xxxxxx>: > > On Mon 2018-03-26 11:52:09, Enric Balletbo i Serra wrote: > >> Before this patch the enable signal was set before the PWM signal and > >> vice-versa on power off. This sequence is wrong, at least, it is on > >> the different panels datasheets that I checked, so I inverted the sequence > >> to follow the specs. > >> > >> For reference the following panels have the mentioned sequence: > >> - N133HSE-EA1 (Innolux) > >> - N116BGE (Innolux) > >> - N156BGE-L21 (Innolux) > >> - B101EAN0 (Auo) > >> - B101AW03 (Auo) > >> - LTN101NT05 (Samsung) > >> - CLAA101WA01A (Chunghwa) > > > > Ok, but this changes behaviour for other panels, too. Are you sure you > > are not breaking one of those? > > I can't say that I am 100% sure because I didn't find all the > datasheets of all the panels supported in the kernel. But all the > datasheets I checked specifies this sequence as valid. In general I > think that doesn't really matter, but I know that at least the > B116XTN02 panel requires enable first the PWM, wait 10ms and then > enable BL_EN to avoid garbage. So the other way around is not valid > for this panel. That's the reason for this patchset. This is certainly a patch that could cause regressions... but it would be a very odd panel that *likes* to be exposed to all the weird edges that might occur whilst the PWM stablizes and a panel that *needs* to see weird edges to work seems even less likely (since it could act different with each SoC). So whilst the patch is not absolutely cast iron guaranteed free of risk, I think it is well enough argued for. Naturally I may change my position *very* quickly on receipt of the first bug report ;-) Daniel. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
