06.01.2022 04:11, Doug Anderson пишет: > Hi, > > On Wed, Dec 22, 2021 at 11:26 AM Dmitry Osipenko <digetx@xxxxxxxxx> wrote: >> >> 22.12.2021 14:53, Thierry Reding пишет: >>> On Wed, Dec 22, 2021 at 06:01:26AM +0300, Dmitry Osipenko wrote: >>>> 21.12.2021 21:01, Thierry Reding пишет: >>>>> On Tue, Dec 21, 2021 at 07:45:31PM +0300, Dmitry Osipenko wrote: >>>>>> 21.12.2021 19:17, Thierry Reding пишет: >>>>>>> On Tue, Dec 21, 2021 at 06:47:31PM +0300, Dmitry Osipenko wrote: >>>>>>>> 21.12.2021 13:58, Thierry Reding пишет: >>>>>>>> .. >>>>>>>>>>>> The panel->ddc isn't used by the new panel-edp driver unless panel is >>>>>>>>>>>> compatible with "edp-panel". Hence the generic_edp_panel_probe() should >>>>>>>>>>>> either fail or crash for a such "edp-panel" since panel->ddc isn't fully >>>>>>>>>>>> instantiated, AFAICS. >>>>>>>>>>> >>>>>>>>>>> I've tested this and it works fine on Venice 2. Since that was the >>>>>>>>>>> reference design for Nyan, I suspect that Nyan's will also work. >>>>>>>>>>> >>>>>>>>>>> It'd be great if Thomas or anyone else with access to a Nyan could >>>>>>>>>>> test this to verify that. >>>>>>>>>> >>>>>>>>>> There is no panel-edp driver in the v5.15. The EOL of v5.15 is Oct, >>>>>>>>>> 2023, hence we need to either use: >>>>>>>>> >>>>>>>>> All the (at least relevant) functionality that is in panel-edp was in >>>>>>>>> panel-simple before it was moved to panel-edp. I've backported this set >>>>>>>>> of patches to v5.15 and it works just fine there. >>>>>>>> >>>>>>>> Will we be able to add patch to bypass the panel's DT ddc-i2c-bus on >>>>>>>> Nyan to keep the older DTBs working? >>>>>>> >>>>>>> I don't see why we would want to do that. It's quite clear that the DTB >>>>>>> is buggy in this case and we have a more accurate way to describe what's >>>>>>> really there in hardware. In addition that more accurate representation >>>>>>> also gets rid of a bug. Obviously because the bug is caused by the >>>>>>> previous representation that was not accurate. >>>>>>> >>>>>>> Given that we can easily replace the DTBs on these devices there's no >>>>>>> reason to make this any more complicated than it has to be. >>>>>> >>>>>> Don't you care about normal people at all? Do you assume that everyone >>>>>> must to be a kernel developer to be able to use Tegra devices? :/ >>>>> >>>>> If you know how to install a custom kernel you also know how to replace >>>>> the DTB on these devices. >>>>> >>>>> For everyone else, once these patches are merged upstream and >>>>> distributions start shipping the new version, they will get this >>>>> automatically by updating their kernel package since most distributions >>>>> actually ship the DTB files as part of that. >>>>> >>>>>> It's not a problem for you to figure out why display is broken, for >>>>>> other people it's a problem. Usually nobody will update DTB without a >>>>>> well known reason, instead device will be dusted on a shelf. In the end >>>>>> you won't have any users at all. >>>>> >>>>> Most "normal" people aren't even going to notice that their DTB is going >>>>> to be updated. They would actually have to do extra work *not* to update >>>>> it. >>>> >>>> My past experience tells that your assumption is incorrect. There are >>>> quite a lot of people who will update kernel, but not DTB. >>> >>> People that do this will have to do it manually because most >>> distributions I know of will actually ship the DTBs. If they know how to >>> update the kernel separately, I'm sure they will manage to update the >>> DTB as well. It's really not more complicated that updating the kernel >>> image. >>> >>>> ARM devices have endless variations of bootloaders and individual quirks >>>> required for a successful installation of a kernel. Kernel update by >>>> distro usually isn't a thing on ARM. >>> >>> I'm not sure what distribution you have been using, but the ones that >>> I'm familiar with all install the DTBs along with the kernel. Most Tegra >>> devices (newer ones at least) do also support booting with U-Boot which >>> supports standard ways to boot a system (which were co-developed with >>> distributions precisely so that it would become easier for users to keep >>> their systems up-to-date), so there's really nothing magical anyone >>> should need to do in order to get an updated DTB along with the updated >>> kernel. >>> >>> It's a simple fact that sometimes a DTB contains a bug and we have to >>> fix it. >>> >>> In general we try to fix things up in the driver code when reasonable so >>> that people don't have to update the DTB. This is for the (mostly hypo- >>> thetical) case where updating the DTB is not possible or very >>> complicated. >>> >>> However, that's not the case on the Venice 2 or Nyan boards. And looking >>> at the alternative in this case, I don't think it's reasonable compared >>> to just fixing the problem at the root, which is in the DTB. >> >> My understanding that U-Boot isn't the only available bootloader option >> for Nyan. I don't feel happy about the ABI breakage, but in the same >> time don't feel very strong about the need to care about it in the case >> of Nyan since its DT already had a preexisting problem with the wrong >> panel model used for the FHD model. The decision will be on your >> conscience :) > > Maybe I should stand back to avoid getting hit by tomatoes, but IMO > it's a terrible idea to try to update devices trees separately from > kernels for any sufficiently complicated device. I won't stop you from > shooting yourself in the foot, but I also certainly wouldn't encourage > it. I've always said that I'll accept that this is something to really > worry about when we land chunk of "device tree fixup" code that runs > in early boot to fix all the broken device trees out there. All ARM > Chrome OS devices that have ever shipped all bundle device trees > together with the kernel (they bundle a whole pile of them and the > bootloader picks the right one based on model). Sure, someone could > decide to bake one into their bootloader but, even aside from this > case, there are sometimes bugs in device trees and they need to get > fixed. Updating your kernel without your device tree is just bad juju > IMO. > > I'll let you and Thierry figure out what you want to do for 5.15. In > the Chrome OS 5.15 kernel tree we simply backported all the edp-panel > stuff, which was fairly clean. I even backported all that stuff to > 5.4, but it was decidedly more complex... Chrome OS is a commercial product, while here we are talking about normal (non-kernel/developer) people. It's incorrect to compare home hackers with professional developers/products, IMO. If we could keep older DTBs working without much effort, then will be great. If not, maybe not a big deal. I suggested variants of preserving the older DTBs and leaving it up to Thierry to decide what to do.
