display: stm32: ltdc: minor fixes

[ajarmouni-st]

Renames the display-controller property of st,stm32-ltdc to panel-controller.

Clarifies why NULL checks are necessary for panel controller device inside blanking_on/off functions in LTDC driver,
& fixes return value when the panel controller's phandle is not passed to LTDC in devicetree.

Addresses #68105 (comment)

[decsny]

will need to update a migration guide to change the DT binding property name

[kartben]

I would squash the commit updating the migration guide into the first commit as there is no reason to keep it separate IMO, but I will make this non-blocking (and doing the update shouldn't dismiss existing reviews anyway)

[mathieuchopstm]

LGTM besides the following:

[GeorgeCGV]

@mathieuchopstm, @ajarmouni-st,

The device_is_ready already checks for null:

zephyr/kernel/device.c

Lines 142 to 153 in 9b9d455

	bool z_impl_device_is_ready(const struct device *dev)
	{
	/*
	* if an invalid device pointer is passed as argument, this call
	* reports the `device` as not ready for usage.
	*/
	if (dev == NULL) {
	return false;
	}
	return dev->state->initialized && (dev->state->init_res == 0U);
	}

No need to add extra device null checks like if (panel_dev == NULL) ...

[ajarmouni-st]

The device_is_ready already checks for null:

No need to add extra device null checks like if (panel_dev == NULL) ...

@GeorgeCGV The idea here is to isolate the dev == NULL case from dev->state->initialized == false case.

[GeorgeCGV]

@ajarmouni-st if the goal is to allow people to control blanking manually in the app, then the stm32_ltdc_init could print an info about panel_controller being null and blanking calls could be way smaller with some macro magic (as that is user's intention). That could reduce the footprint a bit.

If the goal is to not allow that, then it would be better to fail early by replacing DEVICE_DT_GET_OR_NULL with DEVICE_DT_GET. Then the null checks are irrelevant.

But ok.

[ajarmouni-st]

it would be better to fail early by replacing DEVICE_DT_GET_OR_NULL with DEVICE_DT_GET

That would not be desirable because we don't know if the app will actually call a display API function that needs to be forwarded to the panel controller.

[ajarmouni-st]

blanking calls could be way smaller with some macro magic

@GeorgeCGV I am not sure I understand what you mean by this.

[GeorgeCGV]

it would be better to fail early by replacing DEVICE_DT_GET_OR_NULL with DEVICE_DT_GET

That would not be desirable because we don't know if the app will actually call a display API function that needs to be forwarded to the panel controller.

Some drivers call blanking on upon init, some don't. Same goes for blanking off.

blanking calls could be way smaller with some macro magic

@GeorgeCGV I am not sure I understand what you mean by this.

If LTDC's blanking control is intended to be optional, then it is possible to define blanking differently depending on the panel_controller value. That allows to save some bytes when panel_controller is not provided. But that is more into "optimization".

[ajarmouni-st]

@GeorgeCGV I don't know if this is relevant or not, but panel-controller is useful for redirecting in a transparent way the call of any display API function that cannot be performed by LTDC itself but it is implemented by the panel controller driver (like set_brightness in the case of otm8009a).

[ajarmouni-st]

@decsny Please take another look, thanks!

[ajarmouni-st]

@danieldegrasse could you help review this, thanks!

Migration guide has been updated

[jfischer-no]

-	display-controller = <&ili9341>;
+	panel-controller = <&ili9341>;

Whether display-controller is ambiguous or not, it is not a bug.

[jfischer-no]

@ajarmouni-st But drivers: display: stm32_ltdc: fix return value is still valid, why not just drop the first commit?