Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins
On Fri, 2022-02-11 at 23:52 -0800, Abhinav Kumar wrote: > > The thread is writing the data to a file in local storage. From our > profiling, the read is the one taking the time not the write. > That seems kind of hard to believe, let's say it's a 4/3 split (4 minutes reading, 3 minutes writing, to make read > write as you say), and 3MiB size, that'd mean you get 12.8KiB/sec? That seems implausibly low, unless you're reading with really tiny buffers? Can you strace this somehow? (with timestamp info) > Just doubling what we have currently. I am not sure how the current 5 > mins timeout came from. > To be honest it came out of thin air, and wasn't really meant as a limit on how fast you can read (feels like even if it's tens of MiB you should read it in milliseconds into userspace), but more of a maximum time that we're willing to waste kernel memory if nobody is around to read the data. I thought it'd be better if we could somehow pin it while the userspace is reading it, but OTOH maybe that's actually bad, since that means userspace (though suitably privileged) could pin this kernel memory indefinitely. johannes
Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins
On Fri, Feb 11, 2022 at 11:52:41PM -0800, Abhinav Kumar wrote: > Hi Greg > > On 2/11/2022 11:04 PM, Greg KH wrote: > > On Fri, Feb 11, 2022 at 10:59:39AM -0800, Abhinav Kumar wrote: > > > Hi Greg > > > > > > Thanks for the response. > > > > > > On 2/11/2022 3:09 AM, Greg KH wrote: > > > > On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote: > > > > > There are cases where depending on the size of the devcoredump and > > > > > the speed > > > > > at which the usermode reads the dump, it can take longer than the > > > > > current 5 mins > > > > > timeout. > > > > > > > > > > This can lead to incomplete dumps as the device is deleted once the > > > > > timeout expires. > > > > > > > > > > One example is below where it took 6 mins for the devcoredump to be > > > > > completely read. > > > > > > > > > > 04:22:24.668 23916 23994 I HWDeviceDRM::DumpDebugData: Opening > > > > > /sys/class/devcoredump/devcd6/data > > > > > 04:28:35.377 23916 23994 W HWDeviceDRM::DumpDebugData: Freeing > > > > > devcoredump node > > > > > > > > What makes this so slow? Reading from the kernel shouldn't be the > > > > limit, is it where the data is being sent to? > > > > > > We are still checking this. We are seeing better read times when we bump > > > up > > > the thread priority of the thread which was reading this. > > > > Where is the thread sending the data to? > > The thread is writing the data to a file in local storage. From our > profiling, the read is the one taking the time not the write. The read is coming directly from memory, there should not be any slowdown at all here. How can that be the delay? Have a trace somewhere? thanks, greg k-h
Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins
Hi Greg On 2/12/2022 12:29 AM, Greg KH wrote: On Fri, Feb 11, 2022 at 11:52:41PM -0800, Abhinav Kumar wrote: Hi Greg On 2/11/2022 11:04 PM, Greg KH wrote: On Fri, Feb 11, 2022 at 10:59:39AM -0800, Abhinav Kumar wrote: Hi Greg Thanks for the response. On 2/11/2022 3:09 AM, Greg KH wrote: On Tue, Feb 08, 2022 at 11:44:32AM -0800, Abhinav Kumar wrote: There are cases where depending on the size of the devcoredump and the speed at which the usermode reads the dump, it can take longer than the current 5 mins timeout. This can lead to incomplete dumps as the device is deleted once the timeout expires. One example is below where it took 6 mins for the devcoredump to be completely read. 04:22:24.668 23916 23994 I HWDeviceDRM::DumpDebugData: Opening /sys/class/devcoredump/devcd6/data 04:28:35.377 23916 23994 W HWDeviceDRM::DumpDebugData: Freeing devcoredump node What makes this so slow? Reading from the kernel shouldn't be the limit, is it where the data is being sent to? We are still checking this. We are seeing better read times when we bump up the thread priority of the thread which was reading this. Where is the thread sending the data to? The thread is writing the data to a file in local storage. From our profiling, the read is the one taking the time not the write. The read is coming directly from memory, there should not be any slowdown at all here. How can that be the delay? Have a trace somewhere? thanks, greg k-h Yes, like I mentioned in my previous comment we are still checking why its taking so long. We will update with our findings if we have any. Alright, we will try to capture trace to share and will update this thread if we find something as well.
Re: [PATCH] devcoredump: increase the device delete timeout to 10 mins
Hi Johannes On 2/12/2022 12:24 AM, Johannes Berg wrote: On Fri, 2022-02-11 at 23:52 -0800, Abhinav Kumar wrote: The thread is writing the data to a file in local storage. From our profiling, the read is the one taking the time not the write. That seems kind of hard to believe, let's say it's a 4/3 split (4 minutes reading, 3 minutes writing, to make read > write as you say), and 3MiB size, that'd mean you get 12.8KiB/sec? That seems implausibly low, unless you're reading with really tiny buffers? Can you strace this somehow? (with timestamp info) Yes, like I have already mentioned in earlier comments, we continue to check whats taking that long. Once we find something from our analysis and also have the trace, will update the thread. Just doubling what we have currently. I am not sure how the current 5 mins timeout came from. To be honest it came out of thin air, and wasn't really meant as a limit on how fast you can read (feels like even if it's tens of MiB you should read it in milliseconds into userspace), but more of a maximum time that we're willing to waste kernel memory if nobody is around to read the data. I thought it'd be better if we could somehow pin it while the userspace is reading it, but OTOH maybe that's actually bad, since that means userspace (though suitably privileged) could pin this kernel memory indefinitely. johannes
Re: [PATCH v5 3/6] drm: Add driver for Solomon SSD130x OLED displays
On 2/11/22 20:19, Javier Martinez Canillas wrote: [snip] >> I would put GENMASK() directly into FIELD(), but it's up to you >> (and I haven't checked the use of *_MASK anyway). >> > > Same. I also considered just using GENMASK() directly, but since I was > already reworking these, I thought that having the _MASK constant macros > would make the code more explicit about these being masks and what for. > Just to make clear, I prefer to keep the GENMASK(n, n) and *_MASK here. [snip] >> >>> + bl = devm_backlight_device_register(dev, dev_name(dev), dev, ssd130x, >>> + &ssd130xfb_bl_ops, NULL); >>> + if (IS_ERR(bl)) >>> + return ERR_PTR(dev_err_probe(dev, PTR_ERR(bl), >>> +"Unable to register backlight >>> device\n")); >> >> Can be consistent with this then. >> > > Yes. I meant to change it everywhere but seems that one slipped it through. > > It's not worth to send a v6 just for the changes you mentioned but I can do > them before pushing the patches to drm-misc (once I get ack for this patch). > Another option is to post a v6 only for patch 3/6 instead of all the patch-set. Let me know what you prefer. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [v1 1/2] drm/msm/dp: Add basic PSR support for eDP
On Sat, 12 Feb 2022 at 15:52, Vinod Polimera wrote:
>
> Add support for basic panel self refresh (PSR) feature for eDP.
> Add a new interface to set PSR state in the sink from DPU.
> Program the eDP controller to issue PSR enter and exit SDP to
> the sink.
>
> Signed-off-by: Sankeerth Billakanti
> ---
> drivers/gpu/drm/msm/dp/dp_catalog.c | 81
> +
> drivers/gpu/drm/msm/dp/dp_catalog.h | 4 ++
> drivers/gpu/drm/msm/dp/dp_ctrl.c| 65 -
> drivers/gpu/drm/msm/dp/dp_ctrl.h| 3 ++
> drivers/gpu/drm/msm/dp/dp_display.c | 12 ++
> drivers/gpu/drm/msm/dp/dp_drm.c | 14 ++-
> drivers/gpu/drm/msm/dp/dp_link.c| 22 ++
> drivers/gpu/drm/msm/dp/dp_panel.c | 21 ++
> drivers/gpu/drm/msm/dp/dp_panel.h | 6 +++
> drivers/gpu/drm/msm/dp/dp_reg.h | 19 +
> drivers/gpu/drm/msm/msm_drv.h | 2 +
> 11 files changed, 247 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
> b/drivers/gpu/drm/msm/dp/dp_catalog.c
> index 6ae9b29..d20cabb 100644
> --- a/drivers/gpu/drm/msm/dp/dp_catalog.c
> +++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
> @@ -45,6 +45,14 @@
> #define DP_INTERRUPT_STATUS2_MASK \
> (DP_INTERRUPT_STATUS2 << DP_INTERRUPT_STATUS_MASK_SHIFT)
>
> +#define DP_INTERRUPT_STATUS4 \
> + (PSR_UPDATE_INT | PSR_CAPTURE_INT | PSR_EXIT_INT | \
> + PSR_UPDATE_ERROR_INT | PSR_WAKE_ERROR_INT)
> +
> +#define DP_INTERRUPT_MASK4 \
> + (PSR_UPDATE_MASK | PSR_CAPTURE_MASK | PSR_EXIT_MASK | \
> + PSR_UPDATE_ERROR_MASK | PSR_WAKE_ERROR_MASK)
> +
> struct dp_catalog_private {
> struct device *dev;
> struct dp_io *io;
> @@ -343,6 +351,20 @@ void dp_catalog_ctrl_lane_mapping(struct dp_catalog
> *dp_catalog)
> ln_mapping);
> }
>
> +void dp_catalog_ctrl_psr_mainlink_enable(struct dp_catalog *dp_catalog,
> + bool enable)
> +{
> + u32 mainlink_ctrl;
> + struct dp_catalog_private *catalog = container_of(dp_catalog,
> + struct dp_catalog_private, dp_catalog);
> +
> + mainlink_ctrl = dp_read_link(catalog, REG_DP_MAINLINK_CTRL);
> + mainlink_ctrl &= ~DP_MAINLINK_CTRL_ENABLE;
> + mainlink_ctrl |= (enable & DP_MAINLINK_CTRL_ENABLE);
> +
> + dp_write_link(catalog, REG_DP_MAINLINK_CTRL, mainlink_ctrl);
> +}
> +
> void dp_catalog_ctrl_mainlink_ctrl(struct dp_catalog *dp_catalog,
> bool enable)
> {
> @@ -581,6 +603,51 @@ void dp_catalog_ctrl_hpd_config(struct dp_catalog
> *dp_catalog)
> dp_write_aux(catalog, REG_DP_DP_HPD_CTRL, DP_DP_HPD_CTRL_HPD_EN);
> }
>
> +static void dp_catalog_enable_sdp(struct dp_catalog_private *catalog)
> +{
> + /* trigger sdp */
> + dp_write_link(catalog, MMSS_DP_SDP_CFG3, 0x1);
> + dp_write_link(catalog, MMSS_DP_SDP_CFG3, 0x0);
> +}
> +
> +void dp_catalog_ctrl_config_psr(struct dp_catalog *dp_catalog)
> +{
> + struct dp_catalog_private *catalog = container_of(dp_catalog,
> + struct dp_catalog_private, dp_catalog);
> + u32 psr_config;
> +
> + /* enable PSR1 function */
> + psr_config = dp_read_link(catalog, REG_PSR_CONFIG);
> + psr_config |= BIT(0);
> + dp_write_link(catalog, REG_PSR_CONFIG, psr_config);
> +
> + dp_write_ahb(catalog, REG_DP_INTR_MASK4, DP_INTERRUPT_MASK4);
> + dp_catalog_enable_sdp(catalog);
> +}
> +
> +void dp_catalog_ctrl_set_psr(struct dp_catalog *dp_catalog, bool enter)
> +{
> + struct dp_catalog_private *catalog = container_of(dp_catalog,
> + struct dp_catalog_private, dp_catalog);
> + u32 psr_cmd;
> +
> + psr_cmd = dp_read_link(catalog, REG_PSR_CMD);
> +
> + /*
> +* BIT(0) - send psr entry SDP
> +* BIT(1) - sned psr exit SDP
> +*/
> + psr_cmd &= ~(BIT(0) | BIT(1));
> +
> + if (enter)
> + psr_cmd |= BIT(0);
> + else
> + psr_cmd |= BIT(1);
> +
> + dp_catalog_enable_sdp(catalog);
> + dp_write_link(catalog, REG_PSR_CMD, psr_cmd);
> +}
> +
> u32 dp_catalog_link_is_connected(struct dp_catalog *dp_catalog)
> {
> struct dp_catalog_private *catalog = container_of(dp_catalog,
> @@ -608,6 +675,20 @@ u32 dp_catalog_hpd_get_intr_status(struct dp_catalog
> *dp_catalog)
> return isr;
> }
>
> +int dp_catalog_ctrl_get_psr_interrupt(struct dp_catalog *dp_catalog)
> +{
> + struct dp_catalog_private *catalog = container_of(dp_catalog,
> + struct dp_catalog_private, dp_catalog);
> + u32 intr, intr_ack;
> +
> + intr = dp_read_ahb(catalog, REG_DP_INTR_STATUS4);
> + intr_ack = (intr & DP_INTERRUPT_STATUS4)
> + << DP_INTERRUPT_STATUS_ACK_SHIFT;
> + dp_write_ahb(catalog, REG_DP_INTR_STATUS4, intr_ack);
> +
> +
Re: [PATCH v13 0/9] MIPS: JZ4780 and CI20 HDMI
Hi,
> Am 09.02.2022 um 15:02 schrieb Paul Cercueil :
>
> Hi,
>
> Le mer., févr. 9 2022 at 14:51:12 +0100, H. Nikolaus Schaller
> a écrit :
>> Paul,
>>> Am 09.02.2022 um 12:52 schrieb Paul Cercueil :
>>> Hi Nikolaus,
>>> I tried applying patches 1-2, but they don't apply cleanly on top of
>>> drm-misc/drm-misc-next.
>> Ok I had rebased to linux-next some days ago and it appears that patch 1/9
>> has now arrived in drm-misc/drm-misc-next.
>> So we can drop 1/9.
>
> Yes, some weeks ago I did apply patch 1/9 from one of your previous
> patchsets. Patch 2 was applied as well (commit b807fd2c43fe ("drm/ingenic:
> Add support for JZ4780 and HDMI output")), but you then said that it didn't
> work and needed a fix.
>
> For this patchset you should always base on top of drm-misc/drm-misc-next,
> and not on linux-next; they have different schedules. You can drop patch #1,
> and rework patch #2 so that it only fixes the previously incorrect behaviour.
>
>>> Could you rebase on top of that tree?
>> Sure.
>> Unfortunatley my v14 breaks the display again. It is not much fun to develop
>> on top of such a moving target...
>
> I can imagine...
Have found it. Was a typo in a rebase conflict resolution...
So, v14 can come now.
BR and thanks,
Nikolaus
Re: [v1 2/2] drm/msm/disp/dpu1: Add PSR support for eDP interface in dpu driver
On Sat, 12 Feb 2022 at 15:52, Vinod Polimera wrote:
>
> Enable PSR on eDP interface using drm self-refresh librabry.
> This patch uses a trigger from self-refresh library to enter/exit
> into PSR, when there are no updates from framework.
>
> Signed-off-by: Vinod Polimera
> Signed-off-by: Kalyan Thota
The S-O-B of the sender should come last. Please change the order of
the S-O-B tags.
> ---
> drivers/gpu/drm/bridge/panel.c | 64 +-
This chunk should come in a separate patch. Please do not mix drm/msm
patches with the generic code.
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 30 +---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 71
> ++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
> 4 files changed, 142 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index b32295a..c440546 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -102,31 +102,71 @@ static void panel_bridge_detach(struct drm_bridge
> *bridge)
> drm_connector_cleanup(connector);
> }
>
> -static void panel_bridge_pre_enable(struct drm_bridge *bridge)
> +static void panel_bridge_pre_enable(struct drm_bridge *bridge,
> + struct drm_bridge_state *old_bridge_state)
> {
> struct panel_bridge *panel_bridge =
> drm_bridge_to_panel_bridge(bridge);
> -
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *cstate;
> + int i;
> +
> + if (old_bridge_state->base.state) {
> + for_each_old_crtc_in_state(old_bridge_state->base.state,
> crtc, cstate, i) {
> + if (cstate->self_refresh_active && cstate->active)
> + return;
> + }
Ugh. No. You will skip panel actions if _any_ of the crtc's has PSR
enabled. There might be other CRTCs in play.
Please see analogix_dp_core.c for a proper way to handle this.
Consider moving common code (e.g. getting the crtc used by the
encoder) pieces to the generic drm code.
> + }
> drm_panel_prepare(panel_bridge->panel);
> }
>
> -static void panel_bridge_enable(struct drm_bridge *bridge)
> +static void panel_bridge_enable(struct drm_bridge *bridge,
> + struct drm_bridge_state *old_bridge_state)
> {
> struct panel_bridge *panel_bridge =
> drm_bridge_to_panel_bridge(bridge);
> -
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *cstate;
> + int i;
> +
> + if (old_bridge_state->base.state) {
> + for_each_old_crtc_in_state(old_bridge_state->base.state,
> crtc, cstate, i) {
> + if (cstate->self_refresh_active)
> + return;
> + }
> + }
> drm_panel_enable(panel_bridge->panel);
> }
>
> -static void panel_bridge_disable(struct drm_bridge *bridge)
> +static void panel_bridge_disable(struct drm_bridge *bridge,
> + struct drm_bridge_state *old_bridge_state)
> {
> struct panel_bridge *panel_bridge =
> drm_bridge_to_panel_bridge(bridge);
> -
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *cstate;
> + int i;
> +
> + if (old_bridge_state->base.state) {
> + for_each_new_crtc_in_state(old_bridge_state->base.state,
> crtc, cstate, i) {
> + if (cstate->self_refresh_active)
> + return;
> + }
> + }
> drm_panel_disable(panel_bridge->panel);
> }
>
> -static void panel_bridge_post_disable(struct drm_bridge *bridge)
> +static void panel_bridge_post_disable(struct drm_bridge *bridge,
> + struct drm_bridge_state *old_bridge_state)
> {
> struct panel_bridge *panel_bridge =
> drm_bridge_to_panel_bridge(bridge);
> -
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *cstate;
> + int i;
> +
> + if (old_bridge_state->base.state) {
> + for_each_new_crtc_in_state(old_bridge_state->base.state,
> crtc, cstate, i) {
> + if (cstate->self_refresh_active)
> + return;
> + }
> + }
> drm_panel_unprepare(panel_bridge->panel);
> }
>
> @@ -141,10 +181,10 @@ static int panel_bridge_get_modes(struct drm_bridge
> *bridge,
> static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
> .attach = panel_bridge_attach,
> .detach = panel_bridge_detach,
> - .pre_enable = panel_bridge_pre_enable,
> - .enable = panel_bridge_enable,
> - .disable = panel_bridge_disable,
> - .post_disable = panel_bridge_post_disable,
> + .atomic_pre_enable = panel_bridge_pre_enable,
> + .atomic_enable = panel_bridge_enable,
> + .atomic_disable = panel_bridge_disable,
> + .atomic_post_disable = panel_bridge_post_disable,
> .get_modes = panel_br
[PATCH v14 0/9] MIPS: JZ4780 and CI20 HDMI
PATCH V14 2022-02-12 15:19:25:
* make compatible to c03d0b52ff71d5 ("drm/connector: Fix typo in output format")
* move "dw-hdmi/ingenic-dw-hdmi: repair interworking with hdmi-connector" before
drm/ingenic: Add dw-hdmi driver specialization for jz4780 (by
p...@crapouillou.net)
* split introduction of dw_hdmi_enable_poll() into separate patch
* explicitly mark plane f0 as not working in jz4780 (suggested by
p...@crapouillou.net)
* drop 1/9 since it is now in drm-misc/drm-misc-next
PATCH V13 2022-02-02 17:31:22:
* 7/9: remove call to gpiod_set_value() because of GPIOD_OUT_HIGH (by
p...@crapouillou.net)
* 4/9: replace ".." by "." (by p...@crapouillou.net)
* 3/9: remove old hdmi-5v-power in the example (by p...@crapouillou.net)
* 2/9: disable handling of plane f0 only for jz4780 (by p...@crapouillou.net)
PATCH V12 2022-01-31 13:26:54:
This version reworks how hdmi ddc power is controlled by connector and not
by ddc/hdmi bridge driver.
Also some patches of the previous version of this series have been removed
since they are already applied to mips-next/linux/next/v5.17-rc1.
Fixes and changes:
- repair interworking of dw-hdmi with connector-hdmi (by h...@goldelico.com)
- fix JZ_REG_LCD_OSDC setup for jz4780 (by h...@goldelico.com and
p...@crapouillou.net)
- adjustments for ci20.dts to use connector gpio for +5v (suggested by several)
- to add control of "ddc-en-gpios" to hdmi-connector driver (by
h...@goldelico.com)
- regulator code removed because we now use the "ddc-en-gpios" of the connector
driver (suggested by p...@crapouillou.net)
- bindings: addition of "ddc-i2c-bus" and "hdmi-5v-supply" removed (suggested
by robh...@kernel.org)
- rebase on v5.17-rc2
PATCH V11 2021-12-02 19:39:52:
- patch 4/8: change devm_regulator_get_optional to devm_regulator_get and
remove NULL check (requested by broo...@kernel.org)
- patch 3/8: make hdmi-5v-supply required (requested by broo...@kernel.org)
PATCH V10 2021-11-30 22:26:41:
- patch 3/8: fix $id and $ref paths (found by r...@kernel.org)
PATCH V9 2021-11-24 22:29:14:
- patch 6/8: remove optional <0> for assigned-clocks and unintentionally
included "unwedge" setup (found by p...@crapouillou.net)
- patch 4/8: some cosmetics
make regulator enable/disable only if not NULL (found by
p...@crapouillou.net)
simplify/fix error handling and driver cleanup on remove (proposed
by p...@crapouillou.net)
- patch 3/8: fix #include path in example (found by p...@crapouillou.net)
fix missing "i" in unevaluatedProperties (found by r...@kernel.org)
fix 4 spaces indentation for required: property (found by
r...@kernel.org)
PATCH V8 2021-11-23 19:14:00:
- fix a bad editing result from patch 2/8 (found by p...@crapouillou.net)
PATCH V7 2021-11-23 18:46:23:
- changed gpio polarity of hdmi_power to 0 (suggested by p...@crapouillou.net)
- fixed LCD1 irq number (bug found by p...@crapouillou.net)
- removed "- 4" for calculating max_register (suggested by p...@crapouillou.net)
- use unevaluatedPropertes instead of additionalProperties (suggested by
r...@kernel.org)
- moved and renamed ingenic,jz4780-hdmi.yaml (suggested by r...@kernel.org)
- adjusted assigned-clocks changes to upstream which added some for SSI (by
h...@goldelico.com)
- rebased and tested with v5.16-rc2 + patch set drm/ingenic by
p...@crapouillou.net (by h...@goldelico.com)
PATCH V6 2021-11-10 20:43:33:
- changed CONFIG_DRM_INGENIC_DW_HDMI to "m" (by h...@goldelico.com)
- made ingenic-dw-hdmi an independent platform driver which can be compiled as
module
and removed error patch fixes for IPU (suggested by p...@crapouillou.net)
- moved assigned-clocks from jz4780.dtsi to ci20.dts (suggested by
p...@crapouillou.net)
- fixed reg property in jz4780.dtsi to cover all registers incl. gamma and vee
(by h...@goldelico.com)
- added a base patch to calculate regmap size from DTS reg property (requested
by p...@crapouillou.net)
- restored resetting all bits except one in LCDOSDC (requested by
p...@crapouillou.net)
- clarified setting of cpos (suggested by p...@crapouillou.net)
- moved bindings definition for ddc-i2c-bus (suggested by p...@crapouillou.net)
- simplified mask definitions for JZ_LCD_DESSIZE (requested by
p...@crapouillou.net)
- removed setting alpha premultiplication (suggested by p...@crapouillou.net)
- removed some comments (suggested by p...@crapouillou.net)
PATCH V5 2021-10-05 14:28:44:
- dropped mode_fixup and timings support in dw-hdmi as it is no longer needed
in this V5 (by h...@goldelico.com)
- dropped "drm/ingenic: add some jz4780 specific features" (stimulated by
p...@crapouillou.net)
- fixed typo in commit subject: "synopsis" -> "synopsys" (by h...@goldelico.com)
- swapped clocks in jz4780.dtsi to match synopsys,dw-hdmi.yaml (by
h...@goldelico.com)
- improved, simplified, fixed, dtbschecked ingenic-jz4780-hdmi.yaml and made
dependent of bridge/synopsys,dw-hdmi.yaml (based on suggestions by
max...@cerno.tech)
- fixed
[PATCH v14 3/9] drm/ingenic: Add dw-hdmi driver specialization for jz4780
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780 HDMI support. This requires a new driver, plus device tree and
configuration modifications.
Here we add Kconfig DRM_INGENIC_DW_HDMI, Makefile and driver code.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/Kconfig | 9 ++
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 104 ++
3 files changed, 114 insertions(+)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index 001f59fb06d56..090830bcbde7f 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -24,4 +24,13 @@ config DRM_INGENIC_IPU
The Image Processing Unit (IPU) will appear as a second primary plane.
+config DRM_INGENIC_DW_HDMI
+ tristate "Ingenic specific support for Synopsys DW HDMI"
+ depends on MACH_JZ4780
+ select DRM_DW_HDMI
+ help
+ Choose this option to enable Synopsys DesignWare HDMI based driver.
+ If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
+ select this option.
+
endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index d313326bdddbb..f10cc1c5a5f22 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
ingenic-drm-y = ingenic-drm-drv.o
ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
+obj-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
new file mode 100644
index 0..34e986dd606cf
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019, 2020 Paul Boddie
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ * Probe and remove operations derived from rcar_dw_hdmi.c.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
+ { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
} } },
+ { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
} } },
+ { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
} } },
+ { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
} } },
+ { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
} } }
+};
+
+static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
+ /*pixelclk bpp8bpp10 bpp12 */
+ { 5400, { 0x091c, 0x091c, 0x06dc } },
+ { 5840, { 0x091c, 0x06dc, 0x06dc } },
+ { 7200, { 0x06dc, 0x06dc, 0x091c } },
+ { 7425, { 0x06dc, 0x0b5c, 0x091c } },
+ { 11880, { 0x091c, 0x091c, 0x06dc } },
+ { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+ { ~0UL, { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 21600, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+ /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
+ if (mode->clock > 216000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
+ .mpll_cfg = ingenic_mpll_cfg,
+ .cur_ctr= ingenic_cur_ctr,
+ .phy_config = ingenic_phy_config,
+ .mode_valid = ingenic_dw_hdmi_mode_valid,
+ .output_port= 1,
+};
+
+static const struct of_device_id ingenic_dw_hdmi_dt_ids[] = {
+ { .compatible = "ingenic,jz4780-dw-hdmi" },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ingenic_dw_hdmi_dt_ids);
+
+static void ingenic_dw_hdmi_cleanup(void *data)
+{
+ struct dw_hdmi *hdmi = (struct dw_hdmi *)data;
+
+ dw_hdmi_remove(hdmi);
+}
+
+static int ingenic_dw_hdmi_probe(struct platform_device *pdev)
+{
+ struct dw_hdmi *hdmi;
+
+ hdmi = dw_hdmi_probe(pdev, &ingenic_dw_hdmi_plat_data);
+ if (IS_ERR(hdmi))
+ return PTR_ERR(hdmi);
+
+ return devm_add_action_or_reset(&pdev->dev, ingenic_dw_hdmi_cleanup,
hdmi);
+}
+
+static struct platform_
[PATCH v14 2/9] dt-bindings: display: Add ingenic, jz4780-dw-hdmi DT Schema
From: Sam Ravnborg
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Based on .txt binding from Zubair Lutfullah Kakakhel
Signed-off-by: Sam Ravnborg
Signed-off-by: H. Nikolaus Schaller
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
---
.../display/bridge/ingenic,jz4780-hdmi.yaml | 82 +++
1 file changed, 82 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
new file mode 100644
index 0..b8219eab4475a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ingenic,jz4780-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic JZ4780 HDMI Transmitter
+
+maintainers:
+ - H. Nikolaus Schaller
+
+description: |
+ The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI 1.4
+ TX controller IP with accompanying PHY IP.
+
+allOf:
+ - $ref: synopsys,dw-hdmi.yaml#
+
+properties:
+ compatible:
+const: ingenic,jz4780-dw-hdmi
+
+ reg-io-width:
+const: 4
+
+ clocks:
+maxItems: 2
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input from LCD controller output.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Link to the HDMI connector.
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - ports
+ - reg-io-width
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+hdmi: hdmi@1018 {
+compatible = "ingenic,jz4780-dw-hdmi";
+reg = <0x1018 0x8000>;
+reg-io-width = <4>;
+ddc-i2c-bus = <&i2c4>;
+interrupt-parent = <&intc>;
+interrupts = <3>;
+clocks = <&cgu JZ4780_CLK_AHB0>, <&cgu JZ4780_CLK_HDMI>;
+clock-names = "iahb", "isfr";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+hdmi_in: port@0 {
+reg = <0>;
+dw_hdmi_in: endpoint {
+remote-endpoint = <&jz4780_lcd_out>;
+};
+};
+hdmi_out: port@1 {
+reg = <1>;
+dw_hdmi_out: endpoint {
+remote-endpoint = <&hdmi_con>;
+};
+};
+};
+};
+
+...
--
2.33.0
[PATCH v14 6/9] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
so that specialization drivers like ingenic-dw-hdmi can enable polling.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
include/drm/bridge/dw_hdmi.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 826a055a7a273..fc2d5422c8a19 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3216,6 +3216,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
return 0;
}
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
+{
+ if (hdmi->bridge.dev)
+ hdmi->bridge.dev->mode_config.poll_enabled = enable;
+ else
+ dev_warn(hdmi->dev, "no hdmi->bridge.dev");
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
+
struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
{
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 2a1f85f9a8a3f..963960794b40e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -196,5 +196,6 @@ enum drm_connector_status dw_hdmi_phy_read_hpd(struct
dw_hdmi *hdmi,
void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
bool force, bool disabled, bool rxsense);
void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);
#endif /* __IMX_HDMI_H__ */
--
2.33.0
[PATCH v14 1/9] drm/ingenic: Add support for JZ4780 and HDMI output
From: Paul Boddie
Add support for the LCD controller present on JZ4780 SoCs.
This SoC uses 8-byte descriptors which extend the current
4-byte descriptors used for other Ingenic SoCs.
Note that plane f0 is not working and disabled to be
seen from user-space.
Tested on MIPS Creator CI20 board.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 7f10d6eed549d..dcf44cb00821f 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -65,8 +65,10 @@ struct ingenic_dma_hwdescs {
struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
+ bool has_alpha;
bool map_noncoherent;
bool use_extended_hwdesc;
+ bool plane_f0_not_working;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
unsigned int num_formats_f0, num_formats_f1;
@@ -453,7 +455,7 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
if (!crtc)
return 0;
- if (plane == &priv->f0)
+ if (priv->soc_info->plane_f0_not_working && plane == &priv->f0)
return -EINVAL;
crtc_state = drm_atomic_get_existing_crtc_state(state,
@@ -1055,6 +1057,7 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
long parent_rate;
unsigned int i, clone_mask = 0;
int ret, irq;
+ u32 osdc = 0;
soc_info = of_device_get_match_data(dev);
if (!soc_info) {
@@ -1312,7 +1315,10 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
/* Enable OSD if available */
if (soc_info->has_osd)
- regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN);
+ osdc |= JZ_LCD_OSDC_OSDEN;
+ if (soc_info->has_alpha)
+ osdc |= JZ_LCD_OSDC_ALPHAEN;
+ regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
mutex_init(&priv->clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1511,7 +1517,9 @@ static const struct jz_soc_info jz4770_soc_info = {
static const struct jz_soc_info jz4780_soc_info = {
.needs_dev_clk = true,
.has_osd = true,
+ .has_alpha = true,
.use_extended_hwdesc = true,
+ .plane_f0_not_working = true, /* REVISIT */
.max_width = 4096,
.max_height = 2048,
.formats_f1 = jz4770_formats_f1,
--
2.33.0
[PATCH v14 4/9] drm/bridge: display-connector: add ddc-en gpio support
"hdmi-connector.yaml" bindings defines an optional property
"ddc-en-gpios" for a single gpio to enable DDC operation.
Usually this controls +5V power on the HDMI connector.
This +5V may also be needed for HPD.
This was not reflected in code.
Now, the driver activates the ddc gpio after probe and
deactivates after remove so it is "almost on".
But only if this driver is loaded (and not e.g. blacklisted
as module).
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/display-connector.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index d24f5b90feabf..e4d52a7e31b71 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -24,6 +24,7 @@ struct display_connector {
int hpd_irq;
struct regulator*dp_pwr;
+ struct gpio_desc*ddc_en;
};
static inline struct display_connector *
@@ -345,6 +346,17 @@ static int display_connector_probe(struct platform_device
*pdev)
}
}
+ /* enable DDC */
+ if (type == DRM_MODE_CONNECTOR_HDMIA) {
+ conn->ddc_en = devm_gpiod_get_optional(&pdev->dev, "ddc-en",
+ GPIOD_OUT_HIGH);
+
+ if (IS_ERR(conn->ddc_en)) {
+ dev_err(&pdev->dev, "Couldn't get ddc-en gpio\n");
+ return PTR_ERR(conn->ddc_en);
+ }
+ }
+
conn->bridge.funcs = &display_connector_bridge_funcs;
conn->bridge.of_node = pdev->dev.of_node;
@@ -373,6 +385,9 @@ static int display_connector_remove(struct platform_device
*pdev)
{
struct display_connector *conn = platform_get_drvdata(pdev);
+ if (conn->ddc_en)
+ gpiod_set_value(conn->ddc_en, 0);
+
if (conn->dp_pwr)
regulator_disable(conn->dp_pwr);
--
2.33.0
[PATCH v14 8/9] [already applied to mips-fixes] MIPS: DTS: CI20: fix how ddc power is enabled
Originally we proposed a new hdmi-5v-supply regulator reference
for CI20 device tree but that was superseded by a better idea to use
the already defined "ddc-en-gpios" property of the "hdmi-connector".
Since "MIPS: DTS: CI20: Add DT nodes for HDMI setup" has already
been applied to v5.17-rc1, we add this on top.
Fixes: ae1b8d2c2de9 ("MIPS: DTS: CI20: Add DT nodes for HDMI setup")
Signed-off-by: H. Nikolaus Schaller
Reviewed-by: Paul Cercueil
---
arch/mips/boot/dts/ingenic/ci20.dts | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
b/arch/mips/boot/dts/ingenic/ci20.dts
index 3e336b3dbb109..ab6e3dc0bc1d0 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -83,6 +83,8 @@ hdmi_out: connector {
label = "HDMI OUT";
type = "a";
+ ddc-en-gpios = <&gpa 25 GPIO_ACTIVE_HIGH>;
+
port {
hdmi_con: endpoint {
remote-endpoint = <&dw_hdmi_out>;
@@ -114,17 +116,6 @@ otg_power: fixedregulator@2 {
gpio = <&gpf 14 GPIO_ACTIVE_LOW>;
enable-active-high;
};
-
- hdmi_power: fixedregulator@3 {
- compatible = "regulator-fixed";
-
- regulator-name = "hdmi_power";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
-
- gpio = <&gpa 25 0>;
- enable-active-high;
- };
};
&ext {
@@ -576,8 +567,6 @@ &hdmi {
pinctrl-names = "default";
pinctrl-0 = <&pins_hdmi_ddc>;
- hdmi-5v-supply = <&hdmi_power>;
-
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.33.0
[PATCH v14 5/9] drm/bridge: dw-hdmi: repair interworking with hdmi-connector for jz4780
Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
introduced a new mechanism to negotiate bus formats between hdmi connector
and the synopsys hdmi driver inside the jz4780.
By this, the dw-hdmi is no longer the only bridge and sets up a list
of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().
This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780 but only
produces a black screen.
This fix is based on the observation that max_bpc = 0 when running this
function while info->bpc = 8. Since the formats checks before this always test
for max_bpc >= info->pbc indirectly my assumption is that we must check it
here as well.
Adding the proposed patch makes the CI20/jz4780 panel work again in
MEDIA_BUS_FMT_RGB888_1X24 mode.
Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index b0d8110dd412c..826a055a7a273 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2620,10 +2620,10 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
}
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCBCR422)
output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCBCR444)
output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
/* Default 8bit RGB fallback */
--
2.33.0
[PATCH v14 9/9] [RFC] drm/ingenic: add some more features specific to jz4780
From: Paul Boddie
The jz4780 has some more features which should be initialized
according to the vendor kernel.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 34 +++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index dcf44cb00821f..fb2cdb188b993 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -66,6 +66,9 @@ struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
bool has_alpha;
+ bool has_pcfg;
+ bool has_recover;
+ bool has_rgbc;
bool map_noncoherent;
bool use_extended_hwdesc;
bool plane_f0_not_working;
@@ -732,6 +735,9 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
| JZ_LCD_CFG_SPL_DISABLE | JZ_LCD_CFG_REV_DISABLE;
}
+ if (priv->soc_info->has_recover)
+ cfg |= JZ_LCD_CFG_RECOVER_FIFO_UNDERRUN;
+
if (priv->soc_info->use_extended_hwdesc)
cfg |= JZ_LCD_CFG_DESCRIPTOR_8;
@@ -1320,6 +1326,22 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
osdc |= JZ_LCD_OSDC_ALPHAEN;
regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
+ /* Magic values from the vendor kernel for the priority thresholds. */
+ if (soc_info->has_pcfg)
+ regmap_write(priv->map, JZ_REG_LCD_PCFG,
+JZ_LCD_PCFG_PRI_MODE |
+JZ_LCD_PCFG_HP_BST_16 |
+(511 << JZ_LCD_PCFG_THRESHOLD2_OFFSET) |
+(400 << JZ_LCD_PCFG_THRESHOLD1_OFFSET) |
+(256 << JZ_LCD_PCFG_THRESHOLD0_OFFSET));
+
+ /* RGB output control may be superfluous. */
+ if (soc_info->has_rgbc)
+ regmap_write(priv->map, JZ_REG_LCD_RGBC,
+JZ_LCD_RGBC_RGB_FORMAT_ENABLE |
+JZ_LCD_RGBC_ODD_RGB |
+JZ_LCD_RGBC_EVEN_RGB);
+
mutex_init(&priv->clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1483,6 +1505,9 @@ static const struct jz_soc_info jz4740_soc_info = {
.needs_dev_clk = true,
.has_osd = false,
.map_noncoherent = false,
+ .has_pcfg = false,
+ .has_recover = false,
+ .has_rgbc = false,
.max_width = 800,
.max_height = 600,
.formats_f1 = jz4740_formats,
@@ -1494,6 +1519,9 @@ static const struct jz_soc_info jz4725b_soc_info = {
.needs_dev_clk = false,
.has_osd = true,
.map_noncoherent = false,
+ .has_pcfg = false,
+ .has_recover = true,
+ .has_rgbc = true,
.max_width = 800,
.max_height = 600,
.formats_f1 = jz4725b_formats_f1,
@@ -1506,6 +1534,9 @@ static const struct jz_soc_info jz4770_soc_info = {
.needs_dev_clk = false,
.has_osd = true,
.map_noncoherent = true,
+ .has_pcfg = false,
+ .has_recover = true,
+ .has_rgbc = true,
.max_width = 1280,
.max_height = 720,
.formats_f1 = jz4770_formats_f1,
@@ -1518,6 +1549,9 @@ static const struct jz_soc_info jz4780_soc_info = {
.needs_dev_clk = true,
.has_osd = true,
.has_alpha = true,
+ .has_pcfg = true,
+ .has_recover = true,
+ .has_rgbc = true,
.use_extended_hwdesc = true,
.plane_f0_not_working = true, /* REVISIT */
.max_width = 4096,
--
2.33.0
[PATCH v14 7/9] drm/ingenic: dw-hdmi: make hot plug detection work for CI20
There is no hpd-gpio installed on the CI20 board HDMI connector. Hence there is no hpd detection by the connector driver and we have to enable polling by the dw-hdmi driver. We need to set .poll_enabled but that struct component can only be accessed in the core code. Hence we use the public setter function drm_kms_helper_hotplug_event(). Signed-off-by: H. Nikolaus Schaller --- drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c index 34e986dd606cf..90547a28dc5c7 100644 --- a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c +++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c @@ -55,6 +55,8 @@ ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data, if (mode->clock > 216000) return MODE_CLOCK_HIGH; + dw_hdmi_enable_poll(hdmi, true); + return MODE_OK; } -- 2.33.0
Re: [PATCH v14 1/9] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Nikolaus,
Le sam., févr. 12 2022 at 15:19:19 +0100, H. Nikolaus Schaller
a écrit :
From: Paul Boddie
Add support for the LCD controller present on JZ4780 SoCs.
This SoC uses 8-byte descriptors which extend the current
4-byte descriptors used for other Ingenic SoCs.
Note that plane f0 is not working and disabled to be
seen from user-space.
Tested on MIPS Creator CI20 board.
That's not really what the patch does though. It's a fix for a commit
that has the exact same title and description, and is already merged:
b807fd2c43fe ("drm/ingenic: Add support for JZ4780 and HDMI output").
Please rewrite the patch's title and description to actually describe
its purpose.
Cheers,
-Paul
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 7f10d6eed549d..dcf44cb00821f 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -65,8 +65,10 @@ struct ingenic_dma_hwdescs {
struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
+ bool has_alpha;
bool map_noncoherent;
bool use_extended_hwdesc;
+ bool plane_f0_not_working;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
unsigned int num_formats_f0, num_formats_f1;
@@ -453,7 +455,7 @@ static int ingenic_drm_plane_atomic_check(struct
drm_plane *plane,
if (!crtc)
return 0;
- if (plane == &priv->f0)
+ if (priv->soc_info->plane_f0_not_working && plane == &priv->f0)
return -EINVAL;
crtc_state = drm_atomic_get_existing_crtc_state(state,
@@ -1055,6 +1057,7 @@ static int ingenic_drm_bind(struct device *dev,
bool has_components)
long parent_rate;
unsigned int i, clone_mask = 0;
int ret, irq;
+ u32 osdc = 0;
soc_info = of_device_get_match_data(dev);
if (!soc_info) {
@@ -1312,7 +1315,10 @@ static int ingenic_drm_bind(struct device
*dev, bool has_components)
/* Enable OSD if available */
if (soc_info->has_osd)
- regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN);
+ osdc |= JZ_LCD_OSDC_OSDEN;
+ if (soc_info->has_alpha)
+ osdc |= JZ_LCD_OSDC_ALPHAEN;
+ regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
mutex_init(&priv->clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1511,7 +1517,9 @@ static const struct jz_soc_info jz4770_soc_info
= {
static const struct jz_soc_info jz4780_soc_info = {
.needs_dev_clk = true,
.has_osd = true,
+ .has_alpha = true,
.use_extended_hwdesc = true,
+ .plane_f0_not_working = true, /* REVISIT */
.max_width = 4096,
.max_height = 2048,
.formats_f1 = jz4770_formats_f1,
--
2.33.0
Re: [PATCH v14 2/9] dt-bindings: display: Add ingenic, jz4780-dw-hdmi DT Schema
Hi,
Le sam., févr. 12 2022 at 15:19:20 +0100, H. Nikolaus Schaller
a écrit :
From: Sam Ravnborg
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Based on .txt binding from Zubair Lutfullah Kakakhel
Signed-off-by: Sam Ravnborg
Signed-off-by: H. Nikolaus Schaller
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
Patch pushed to drm-misc-next, thanks!
Cheers,
-Paul
---
.../display/bridge/ingenic,jz4780-hdmi.yaml | 82
+++
1 file changed, 82 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
new file mode 100644
index 0..b8219eab4475a
--- /dev/null
+++
b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/display/bridge/ingenic,jz4780-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for Ingenic JZ4780 HDMI Transmitter
+
+maintainers:
+ - H. Nikolaus Schaller
+
+description: |
+ The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys
DesignWare HDMI 1.4
+ TX controller IP with accompanying PHY IP.
+
+allOf:
+ - $ref: synopsys,dw-hdmi.yaml#
+
+properties:
+ compatible:
+const: ingenic,jz4780-dw-hdmi
+
+ reg-io-width:
+const: 4
+
+ clocks:
+maxItems: 2
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input from LCD controller output.
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Link to the HDMI connector.
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - ports
+ - reg-io-width
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+hdmi: hdmi@1018 {
+compatible = "ingenic,jz4780-dw-hdmi";
+reg = <0x1018 0x8000>;
+reg-io-width = <4>;
+ddc-i2c-bus = <&i2c4>;
+interrupt-parent = <&intc>;
+interrupts = <3>;
+clocks = <&cgu JZ4780_CLK_AHB0>, <&cgu JZ4780_CLK_HDMI>;
+clock-names = "iahb", "isfr";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+hdmi_in: port@0 {
+reg = <0>;
+dw_hdmi_in: endpoint {
+remote-endpoint = <&jz4780_lcd_out>;
+};
+};
+hdmi_out: port@1 {
+reg = <1>;
+dw_hdmi_out: endpoint {
+remote-endpoint = <&hdmi_con>;
+};
+};
+};
+};
+
+...
--
2.33.0
Re: [PATCH v14 8/9] [already applied to mips-fixes] MIPS: DTS: CI20: fix how ddc power is enabled
Hi,
Le sam., févr. 12 2022 at 15:19:26 +0100, H. Nikolaus Schaller
a écrit :
Originally we proposed a new hdmi-5v-supply regulator reference
for CI20 device tree but that was superseded by a better idea to use
the already defined "ddc-en-gpios" property of the "hdmi-connector".
Since "MIPS: DTS: CI20: Add DT nodes for HDMI setup" has already
been applied to v5.17-rc1, we add this on top.
Fixes: ae1b8d2c2de9 ("MIPS: DTS: CI20: Add DT nodes for HDMI setup")
Signed-off-by: H. Nikolaus Schaller
Reviewed-by: Paul Cercueil
Since it's already applied you don't have to send this patch anymore.
Cheers,
-Paul
---
arch/mips/boot/dts/ingenic/ci20.dts | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
b/arch/mips/boot/dts/ingenic/ci20.dts
index 3e336b3dbb109..ab6e3dc0bc1d0 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -83,6 +83,8 @@ hdmi_out: connector {
label = "HDMI OUT";
type = "a";
+ ddc-en-gpios = <&gpa 25 GPIO_ACTIVE_HIGH>;
+
port {
hdmi_con: endpoint {
remote-endpoint = <&dw_hdmi_out>;
@@ -114,17 +116,6 @@ otg_power: fixedregulator@2 {
gpio = <&gpf 14 GPIO_ACTIVE_LOW>;
enable-active-high;
};
-
- hdmi_power: fixedregulator@3 {
- compatible = "regulator-fixed";
-
- regulator-name = "hdmi_power";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
-
- gpio = <&gpa 25 0>;
- enable-active-high;
- };
};
&ext {
@@ -576,8 +567,6 @@ &hdmi {
pinctrl-names = "default";
pinctrl-0 = <&pins_hdmi_ddc>;
- hdmi-5v-supply = <&hdmi_power>;
-
ports {
#address-cells = <1>;
#size-cells = <0>;
--
2.33.0
Re: [PATCH v14 5/9] drm/bridge: dw-hdmi: repair interworking with hdmi-connector for jz4780
Hi Nikolaus,
Le sam., févr. 12 2022 at 15:19:23 +0100, H. Nikolaus Schaller
a écrit :
Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus
fmts callbacks")
introduced a new mechanism to negotiate bus formats between hdmi
connector
and the synopsys hdmi driver inside the jz4780.
By this, the dw-hdmi is no longer the only bridge and sets up a list
of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().
This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780
but only
produces a black screen.
Neil pushed a fix yesterday that looks like it could fix your issue.
The fix is: 1528038385c0 ("drm/bridge: dw-hdmi: use safe format when
first in bridge chain")
Could you try if it does indeed fix your issue?
Cheers,
-Paul
This fix is based on the observation that max_bpc = 0 when running
this
function while info->bpc = 8. Since the formats checks before this
always test
for max_bpc >= info->pbc indirectly my assumption is that we must
check it
here as well.
Adding the proposed patch makes the CI20/jz4780 panel work again in
MEDIA_BUS_FMT_RGB888_1X24 mode.
Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus
fmts callbacks")
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index b0d8110dd412c..826a055a7a273 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2620,10 +2620,10 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
}
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCBCR422)
output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCBCR444)
output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
/* Default 8bit RGB fallback */
--
2.33.0
Re: [PATCH v14 1/9] drm/ingenic: Add support for JZ4780 and HDMI output
Hi Paul,
> Am 12.02.2022 um 15:44 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le sam., févr. 12 2022 at 15:19:19 +0100, H. Nikolaus Schaller
> a écrit :
>> From: Paul Boddie
>> Add support for the LCD controller present on JZ4780 SoCs.
>> This SoC uses 8-byte descriptors which extend the current
>> 4-byte descriptors used for other Ingenic SoCs.
>> Note that plane f0 is not working and disabled to be
>> seen from user-space.
>> Tested on MIPS Creator CI20 board.
>
> That's not really what the patch does though. It's a fix for a commit that
> has the exact same title and description, and is already merged: b807fd2c43fe
> ("drm/ingenic: Add support for JZ4780 and HDMI output").
Well, last version was not a fix...
I simply did not notice that parts of the commit contents were removed by
rebase to drm-misc-next and the commit message diverged...
> Please rewrite the patch's title and description to actually describe its
> purpose.
Well, git rebase should do this for us if it removes the code described in the
commit and makes a fix out of it. What do we have automation for :)
v15 will come now...
BR and thanks,
Nikolaus
>
> Cheers,
> -Paul
>
>> Signed-off-by: Paul Boddie
>> Signed-off-by: Ezequiel Garcia
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12 ++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> index 7f10d6eed549d..dcf44cb00821f 100644
>> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>> @@ -65,8 +65,10 @@ struct ingenic_dma_hwdescs {
>> struct jz_soc_info {
>> bool needs_dev_clk;
>> bool has_osd;
>> +bool has_alpha;
>> bool map_noncoherent;
>> bool use_extended_hwdesc;
>> +bool plane_f0_not_working;
>> unsigned int max_width, max_height;
>> const u32 *formats_f0, *formats_f1;
>> unsigned int num_formats_f0, num_formats_f1;
>> @@ -453,7 +455,7 @@ static int ingenic_drm_plane_atomic_check(struct
>> drm_plane *plane,
>> if (!crtc)
>> return 0;
>> -if (plane == &priv->f0)
>> +if (priv->soc_info->plane_f0_not_working && plane == &priv->f0)
>> return -EINVAL;
>> crtc_state = drm_atomic_get_existing_crtc_state(state,
>> @@ -1055,6 +1057,7 @@ static int ingenic_drm_bind(struct device *dev, bool
>> has_components)
>> long parent_rate;
>> unsigned int i, clone_mask = 0;
>> int ret, irq;
>> +u32 osdc = 0;
>> soc_info = of_device_get_match_data(dev);
>> if (!soc_info) {
>> @@ -1312,7 +1315,10 @@ static int ingenic_drm_bind(struct device *dev, bool
>> has_components)
>> /* Enable OSD if available */
>> if (soc_info->has_osd)
>> -regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN);
>> +osdc |= JZ_LCD_OSDC_OSDEN;
>> +if (soc_info->has_alpha)
>> +osdc |= JZ_LCD_OSDC_ALPHAEN;
>> +regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
>> mutex_init(&priv->clk_mutex);
>> priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
>> @@ -1511,7 +1517,9 @@ static const struct jz_soc_info jz4770_soc_info = {
>> static const struct jz_soc_info jz4780_soc_info = {
>> .needs_dev_clk = true,
>> .has_osd = true,
>> +.has_alpha = true,
>> .use_extended_hwdesc = true,
>> +.plane_f0_not_working = true, /* REVISIT */
>> .max_width = 4096,
>> .max_height = 2048,
>> .formats_f1 = jz4770_formats_f1,
>> --
>> 2.33.0
>
>
Re: [PATCH v14 5/9] drm/bridge: dw-hdmi: repair interworking with hdmi-connector for jz4780
> Am 12.02.2022 um 16:06 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
>
> Le sam., févr. 12 2022 at 15:19:23 +0100, H. Nikolaus Schaller
> a écrit :
>> Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
>> callbacks")
>> introduced a new mechanism to negotiate bus formats between hdmi connector
>> and the synopsys hdmi driver inside the jz4780.
>> By this, the dw-hdmi is no longer the only bridge and sets up a list
>> of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().
>> This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780 but
>> only
>> produces a black screen.
>
> Neil pushed a fix yesterday that looks like it could fix your issue.
> The fix is: 1528038385c0 ("drm/bridge: dw-hdmi: use safe format when first in
> bridge chain")
>
> Could you try if it does indeed fix your issue?
Sure.
Would have been nice and is a fix addressing same base commit, but is not a
replacement for my attempt :(
Fortunately we can have both.
>
> Cheers,
> -Paul
>
>> This fix is based on the observation that max_bpc = 0 when running this
>> function while info->bpc = 8. Since the formats checks before this always
>> test
>> for max_bpc >= info->pbc indirectly my assumption is that we must check it
>> here as well.
>> Adding the proposed patch makes the CI20/jz4780 panel work again in
>> MEDIA_BUS_FMT_RGB888_1X24 mode.
>> Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
>> callbacks")
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index b0d8110dd412c..826a055a7a273 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2620,10 +2620,10 @@ static u32
>> *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
>> output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
>> }
>> -if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
>> +if (max_bpc >= info->bpc && info->color_formats &
>> DRM_COLOR_FORMAT_YCBCR422)
>> output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
>> -if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
>> +if (max_bpc >= info->bpc && info->color_formats &
>> DRM_COLOR_FORMAT_YCBCR444)
>> output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
>> /* Default 8bit RGB fallback */
>> --
>> 2.33.0
>
>
Re: [PATCH v14 8/9] [already applied to mips-fixes] MIPS: DTS: CI20: fix how ddc power is enabled
> Am 12.02.2022 um 15:58 schrieb Paul Cercueil :
>
> Hi,
>
> Le sam., févr. 12 2022 at 15:19:26 +0100, H. Nikolaus Schaller
> a écrit :
>> Originally we proposed a new hdmi-5v-supply regulator reference
>> for CI20 device tree but that was superseded by a better idea to use
>> the already defined "ddc-en-gpios" property of the "hdmi-connector".
>> Since "MIPS: DTS: CI20: Add DT nodes for HDMI setup" has already
>> been applied to v5.17-rc1, we add this on top.
>> Fixes: ae1b8d2c2de9 ("MIPS: DTS: CI20: Add DT nodes for HDMI setup")
>> Signed-off-by: H. Nikolaus Schaller
>> Reviewed-by: Paul Cercueil
>
> Since it's already applied you don't have to send this patch anymore.
I see, it has arrived in linux-next but not yet in drm-misc-next...
So if someone wants to test the series directly on top of drm-misc-next (as I
am doing), it would be incomplete without.
IMHO these side-branches and partial merges here and there sometimes make more
problems than they seem to solve...
But I leave already applied out commits for v15.
>
> Cheers,
> -Paul
>
>> ---
>> arch/mips/boot/dts/ingenic/ci20.dts | 15 ++-
>> 1 file changed, 2 insertions(+), 13 deletions(-)
>> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
>> b/arch/mips/boot/dts/ingenic/ci20.dts
>> index 3e336b3dbb109..ab6e3dc0bc1d0 100644
>> --- a/arch/mips/boot/dts/ingenic/ci20.dts
>> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
>> @@ -83,6 +83,8 @@ hdmi_out: connector {
>> label = "HDMI OUT";
>> type = "a";
>> +ddc-en-gpios = <&gpa 25 GPIO_ACTIVE_HIGH>;
>> +
>> port {
>> hdmi_con: endpoint {
>> remote-endpoint = <&dw_hdmi_out>;
>> @@ -114,17 +116,6 @@ otg_power: fixedregulator@2 {
>> gpio = <&gpf 14 GPIO_ACTIVE_LOW>;
>> enable-active-high;
>> };
>> -
>> -hdmi_power: fixedregulator@3 {
>> -compatible = "regulator-fixed";
>> -
>> -regulator-name = "hdmi_power";
>> -regulator-min-microvolt = <500>;
>> -regulator-max-microvolt = <500>;
>> -
>> -gpio = <&gpa 25 0>;
>> -enable-active-high;
>> -};
>> };
>> &ext {
>> @@ -576,8 +567,6 @@ &hdmi {
>> pinctrl-names = "default";
>> pinctrl-0 = <&pins_hdmi_ddc>;
>> -hdmi-5v-supply = <&hdmi_power>;
>> -
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> --
>> 2.33.0
>
>
[PATCH v15 0/7] MIPS: JZ4780 and CI20 HDMI
PATCH V15 2022-02-12 16:50:54:
* remove already (elsewhere) merged commits (suggested by p...@crapouillou.net)
* clarify commit message for (now) 1/7 ((suggested by p...@crapouillou.net))
PATCH V14 2022-02-12 15:19:25:
* make compatible to c03d0b52ff71d5 ("drm/connector: Fix typo in output format")
* move "dw-hdmi/ingenic-dw-hdmi: repair interworking with hdmi-connector" before
drm/ingenic: Add dw-hdmi driver specialization for jz4780 (by
p...@crapouillou.net)
* split introduction of dw_hdmi_enable_poll() into separate patch
* explicitly mark plane f0 as not working in jz4780 (suggested by
p...@crapouillou.net)
* drop 1/9 since it is now in drm-misc/drm-misc-next
PATCH V13 2022-02-02 17:31:22:
* 7/9: remove call to gpiod_set_value() because of GPIOD_OUT_HIGH (by
p...@crapouillou.net)
* 4/9: replace ".." by "." (by p...@crapouillou.net)
* 3/9: remove old hdmi-5v-power in the example (by p...@crapouillou.net)
* 2/9: disable handling of plane f0 only for jz4780 (by p...@crapouillou.net)
PATCH V12 2022-01-31 13:26:54:
This version reworks how hdmi ddc power is controlled by connector and not
by ddc/hdmi bridge driver.
Also some patches of the previous version of this series have been removed
since they are already applied to mips-next/linux/next/v5.17-rc1.
Fixes and changes:
- repair interworking of dw-hdmi with connector-hdmi (by h...@goldelico.com)
- fix JZ_REG_LCD_OSDC setup for jz4780 (by h...@goldelico.com and
p...@crapouillou.net)
- adjustments for ci20.dts to use connector gpio for +5v (suggested by several)
- to add control of "ddc-en-gpios" to hdmi-connector driver (by
h...@goldelico.com)
- regulator code removed because we now use the "ddc-en-gpios" of the connector
driver (suggested by p...@crapouillou.net)
- bindings: addition of "ddc-i2c-bus" and "hdmi-5v-supply" removed (suggested
by robh...@kernel.org)
- rebase on v5.17-rc2
PATCH V11 2021-12-02 19:39:52:
- patch 4/8: change devm_regulator_get_optional to devm_regulator_get and
remove NULL check (requested by broo...@kernel.org)
- patch 3/8: make hdmi-5v-supply required (requested by broo...@kernel.org)
PATCH V10 2021-11-30 22:26:41:
- patch 3/8: fix $id and $ref paths (found by r...@kernel.org)
PATCH V9 2021-11-24 22:29:14:
- patch 6/8: remove optional <0> for assigned-clocks and unintentionally
included "unwedge" setup (found by p...@crapouillou.net)
- patch 4/8: some cosmetics
make regulator enable/disable only if not NULL (found by
p...@crapouillou.net)
simplify/fix error handling and driver cleanup on remove (proposed
by p...@crapouillou.net)
- patch 3/8: fix #include path in example (found by p...@crapouillou.net)
fix missing "i" in unevaluatedProperties (found by r...@kernel.org)
fix 4 spaces indentation for required: property (found by
r...@kernel.org)
PATCH V8 2021-11-23 19:14:00:
- fix a bad editing result from patch 2/8 (found by p...@crapouillou.net)
PATCH V7 2021-11-23 18:46:23:
- changed gpio polarity of hdmi_power to 0 (suggested by p...@crapouillou.net)
- fixed LCD1 irq number (bug found by p...@crapouillou.net)
- removed "- 4" for calculating max_register (suggested by p...@crapouillou.net)
- use unevaluatedPropertes instead of additionalProperties (suggested by
r...@kernel.org)
- moved and renamed ingenic,jz4780-hdmi.yaml (suggested by r...@kernel.org)
- adjusted assigned-clocks changes to upstream which added some for SSI (by
h...@goldelico.com)
- rebased and tested with v5.16-rc2 + patch set drm/ingenic by
p...@crapouillou.net (by h...@goldelico.com)
PATCH V6 2021-11-10 20:43:33:
- changed CONFIG_DRM_INGENIC_DW_HDMI to "m" (by h...@goldelico.com)
- made ingenic-dw-hdmi an independent platform driver which can be compiled as
module
and removed error patch fixes for IPU (suggested by p...@crapouillou.net)
- moved assigned-clocks from jz4780.dtsi to ci20.dts (suggested by
p...@crapouillou.net)
- fixed reg property in jz4780.dtsi to cover all registers incl. gamma and vee
(by h...@goldelico.com)
- added a base patch to calculate regmap size from DTS reg property (requested
by p...@crapouillou.net)
- restored resetting all bits except one in LCDOSDC (requested by
p...@crapouillou.net)
- clarified setting of cpos (suggested by p...@crapouillou.net)
- moved bindings definition for ddc-i2c-bus (suggested by p...@crapouillou.net)
- simplified mask definitions for JZ_LCD_DESSIZE (requested by
p...@crapouillou.net)
- removed setting alpha premultiplication (suggested by p...@crapouillou.net)
- removed some comments (suggested by p...@crapouillou.net)
PATCH V5 2021-10-05 14:28:44:
- dropped mode_fixup and timings support in dw-hdmi as it is no longer needed
in this V5 (by h...@goldelico.com)
- dropped "drm/ingenic: add some jz4780 specific features" (stimulated by
p...@crapouillou.net)
- fixed typo in commit subject: "synopsis" -> "synopsys" (by h...@goldelico.com)
- swapped clocks in jz4780.dtsi to match synopsys,dw-hdmi.yaml (by
h..
[PATCH v15 6/7] drm/ingenic: dw-hdmi: make hot plug detection work for CI20
There is no hpd-gpio installed on the CI20 board HDMI connector. Hence there is no hpd detection by the connector driver and we have to enable polling by the dw-hdmi driver. We need to set .poll_enabled but that struct component can only be accessed in the core code. Hence we use the public setter function drm_kms_helper_hotplug_event(). Signed-off-by: H. Nikolaus Schaller --- drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c index 34e986dd606cf..90547a28dc5c7 100644 --- a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c +++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c @@ -55,6 +55,8 @@ ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data, if (mode->clock > 216000) return MODE_CLOCK_HIGH; + dw_hdmi_enable_poll(hdmi, true); + return MODE_OK; } -- 2.33.0
[PATCH v15 2/7] drm/ingenic: Add dw-hdmi driver specialization for jz4780
From: Paul Boddie
A specialisation of the generic Synopsys HDMI driver is employed for
JZ4780 HDMI support. This requires a new driver, plus device tree and
configuration modifications.
Here we add Kconfig DRM_INGENIC_DW_HDMI, Makefile and driver code.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/Kconfig | 9 ++
drivers/gpu/drm/ingenic/Makefile | 1 +
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 104 ++
3 files changed, 114 insertions(+)
create mode 100644 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index 001f59fb06d56..090830bcbde7f 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -24,4 +24,13 @@ config DRM_INGENIC_IPU
The Image Processing Unit (IPU) will appear as a second primary plane.
+config DRM_INGENIC_DW_HDMI
+ tristate "Ingenic specific support for Synopsys DW HDMI"
+ depends on MACH_JZ4780
+ select DRM_DW_HDMI
+ help
+ Choose this option to enable Synopsys DesignWare HDMI based driver.
+ If you want to enable HDMI on Ingenic JZ4780 based SoC, you should
+ select this option.
+
endif
diff --git a/drivers/gpu/drm/ingenic/Makefile b/drivers/gpu/drm/ingenic/Makefile
index d313326bdddbb..f10cc1c5a5f22 100644
--- a/drivers/gpu/drm/ingenic/Makefile
+++ b/drivers/gpu/drm/ingenic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_DRM_INGENIC) += ingenic-drm.o
ingenic-drm-y = ingenic-drm-drv.o
ingenic-drm-$(CONFIG_DRM_INGENIC_IPU) += ingenic-ipu.o
+obj-$(CONFIG_DRM_INGENIC_DW_HDMI) += ingenic-dw-hdmi.o
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
new file mode 100644
index 0..34e986dd606cf
--- /dev/null
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2019, 2020 Paul Boddie
+ *
+ * Derived from dw_hdmi-imx.c with i.MX portions removed.
+ * Probe and remove operations derived from rcar_dw_hdmi.c.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static const struct dw_hdmi_mpll_config ingenic_mpll_cfg[] = {
+ { 4525, { { 0x01e0, 0x }, { 0x21e1, 0x }, { 0x41e2, 0x
} } },
+ { 9250, { { 0x0140, 0x0005 }, { 0x2141, 0x0005 }, { 0x4142, 0x0005
} } },
+ { 14850, { { 0x00a0, 0x000a }, { 0x20a1, 0x000a }, { 0x40a2, 0x000a
} } },
+ { 21600, { { 0x00a0, 0x000a }, { 0x2001, 0x000f }, { 0x4002, 0x000f
} } },
+ { ~0UL, { { 0x, 0x }, { 0x, 0x }, { 0x, 0x
} } }
+};
+
+static const struct dw_hdmi_curr_ctrl ingenic_cur_ctr[] = {
+ /*pixelclk bpp8bpp10 bpp12 */
+ { 5400, { 0x091c, 0x091c, 0x06dc } },
+ { 5840, { 0x091c, 0x06dc, 0x06dc } },
+ { 7200, { 0x06dc, 0x06dc, 0x091c } },
+ { 7425, { 0x06dc, 0x0b5c, 0x091c } },
+ { 11880, { 0x091c, 0x091c, 0x06dc } },
+ { 21600, { 0x06dc, 0x0b5c, 0x091c } },
+ { ~0UL, { 0x, 0x, 0x } },
+};
+
+/*
+ * Resistance term 133Ohm Cfg
+ * PREEMP config 0.00
+ * TX/CK level 10
+ */
+static const struct dw_hdmi_phy_config ingenic_phy_config[] = {
+ /*pixelclk symbol term vlev */
+ { 21600, 0x800d, 0x0005, 0x01ad},
+ { ~0UL, 0x, 0x, 0x}
+};
+
+static enum drm_mode_status
+ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, void *data,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock < 13500)
+ return MODE_CLOCK_LOW;
+ /* FIXME: Hardware is capable of 270MHz, but setup data is missing. */
+ if (mode->clock > 216000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static struct dw_hdmi_plat_data ingenic_dw_hdmi_plat_data = {
+ .mpll_cfg = ingenic_mpll_cfg,
+ .cur_ctr= ingenic_cur_ctr,
+ .phy_config = ingenic_phy_config,
+ .mode_valid = ingenic_dw_hdmi_mode_valid,
+ .output_port= 1,
+};
+
+static const struct of_device_id ingenic_dw_hdmi_dt_ids[] = {
+ { .compatible = "ingenic,jz4780-dw-hdmi" },
+ { /* Sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ingenic_dw_hdmi_dt_ids);
+
+static void ingenic_dw_hdmi_cleanup(void *data)
+{
+ struct dw_hdmi *hdmi = (struct dw_hdmi *)data;
+
+ dw_hdmi_remove(hdmi);
+}
+
+static int ingenic_dw_hdmi_probe(struct platform_device *pdev)
+{
+ struct dw_hdmi *hdmi;
+
+ hdmi = dw_hdmi_probe(pdev, &ingenic_dw_hdmi_plat_data);
+ if (IS_ERR(hdmi))
+ return PTR_ERR(hdmi);
+
+ return devm_add_action_or_reset(&pdev->dev, ingenic_dw_hdmi_cleanup,
hdmi);
+}
+
+static struct platform_
[PATCH v15 5/7] drm/bridge: dw-hdmi: introduce dw_hdmi_enable_poll()
so that specialization drivers like ingenic-dw-hdmi can enable polling.
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
include/drm/bridge/dw_hdmi.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 826a055a7a273..fc2d5422c8a19 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3216,6 +3216,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
return 0;
}
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
+{
+ if (hdmi->bridge.dev)
+ hdmi->bridge.dev->mode_config.poll_enabled = enable;
+ else
+ dev_warn(hdmi->dev, "no hdmi->bridge.dev");
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
+
struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
const struct dw_hdmi_plat_data *plat_data)
{
diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
index 2a1f85f9a8a3f..963960794b40e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -196,5 +196,6 @@ enum drm_connector_status dw_hdmi_phy_read_hpd(struct
dw_hdmi *hdmi,
void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
bool force, bool disabled, bool rxsense);
void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);
#endif /* __IMX_HDMI_H__ */
--
2.33.0
[PATCH v15 7/7] [RFC] drm/ingenic: add some more features specific to jz4780
From: Paul Boddie
The jz4780 has some more features which should be initialized
according to the vendor kernel.
Signed-off-by: Paul Boddie
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 34 +++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index dcf44cb00821f..fb2cdb188b993 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -66,6 +66,9 @@ struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
bool has_alpha;
+ bool has_pcfg;
+ bool has_recover;
+ bool has_rgbc;
bool map_noncoherent;
bool use_extended_hwdesc;
bool plane_f0_not_working;
@@ -732,6 +735,9 @@ static void ingenic_drm_encoder_atomic_mode_set(struct
drm_encoder *encoder,
| JZ_LCD_CFG_SPL_DISABLE | JZ_LCD_CFG_REV_DISABLE;
}
+ if (priv->soc_info->has_recover)
+ cfg |= JZ_LCD_CFG_RECOVER_FIFO_UNDERRUN;
+
if (priv->soc_info->use_extended_hwdesc)
cfg |= JZ_LCD_CFG_DESCRIPTOR_8;
@@ -1320,6 +1326,22 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
osdc |= JZ_LCD_OSDC_ALPHAEN;
regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
+ /* Magic values from the vendor kernel for the priority thresholds. */
+ if (soc_info->has_pcfg)
+ regmap_write(priv->map, JZ_REG_LCD_PCFG,
+JZ_LCD_PCFG_PRI_MODE |
+JZ_LCD_PCFG_HP_BST_16 |
+(511 << JZ_LCD_PCFG_THRESHOLD2_OFFSET) |
+(400 << JZ_LCD_PCFG_THRESHOLD1_OFFSET) |
+(256 << JZ_LCD_PCFG_THRESHOLD0_OFFSET));
+
+ /* RGB output control may be superfluous. */
+ if (soc_info->has_rgbc)
+ regmap_write(priv->map, JZ_REG_LCD_RGBC,
+JZ_LCD_RGBC_RGB_FORMAT_ENABLE |
+JZ_LCD_RGBC_ODD_RGB |
+JZ_LCD_RGBC_EVEN_RGB);
+
mutex_init(&priv->clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1483,6 +1505,9 @@ static const struct jz_soc_info jz4740_soc_info = {
.needs_dev_clk = true,
.has_osd = false,
.map_noncoherent = false,
+ .has_pcfg = false,
+ .has_recover = false,
+ .has_rgbc = false,
.max_width = 800,
.max_height = 600,
.formats_f1 = jz4740_formats,
@@ -1494,6 +1519,9 @@ static const struct jz_soc_info jz4725b_soc_info = {
.needs_dev_clk = false,
.has_osd = true,
.map_noncoherent = false,
+ .has_pcfg = false,
+ .has_recover = true,
+ .has_rgbc = true,
.max_width = 800,
.max_height = 600,
.formats_f1 = jz4725b_formats_f1,
@@ -1506,6 +1534,9 @@ static const struct jz_soc_info jz4770_soc_info = {
.needs_dev_clk = false,
.has_osd = true,
.map_noncoherent = true,
+ .has_pcfg = false,
+ .has_recover = true,
+ .has_rgbc = true,
.max_width = 1280,
.max_height = 720,
.formats_f1 = jz4770_formats_f1,
@@ -1518,6 +1549,9 @@ static const struct jz_soc_info jz4780_soc_info = {
.needs_dev_clk = true,
.has_osd = true,
.has_alpha = true,
+ .has_pcfg = true,
+ .has_recover = true,
+ .has_rgbc = true,
.use_extended_hwdesc = true,
.plane_f0_not_working = true, /* REVISIT */
.max_width = 4096,
--
2.33.0
[PATCH v15 3/7] drm/bridge: display-connector: add ddc-en gpio support
"hdmi-connector.yaml" bindings defines an optional property
"ddc-en-gpios" for a single gpio to enable DDC operation.
Usually this controls +5V power on the HDMI connector.
This +5V may also be needed for HPD.
This was not reflected in code.
Now, the driver activates the ddc gpio after probe and
deactivates after remove so it is "almost on".
But only if this driver is loaded (and not e.g. blacklisted
as module).
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/display-connector.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/bridge/display-connector.c
b/drivers/gpu/drm/bridge/display-connector.c
index d24f5b90feabf..e4d52a7e31b71 100644
--- a/drivers/gpu/drm/bridge/display-connector.c
+++ b/drivers/gpu/drm/bridge/display-connector.c
@@ -24,6 +24,7 @@ struct display_connector {
int hpd_irq;
struct regulator*dp_pwr;
+ struct gpio_desc*ddc_en;
};
static inline struct display_connector *
@@ -345,6 +346,17 @@ static int display_connector_probe(struct platform_device
*pdev)
}
}
+ /* enable DDC */
+ if (type == DRM_MODE_CONNECTOR_HDMIA) {
+ conn->ddc_en = devm_gpiod_get_optional(&pdev->dev, "ddc-en",
+ GPIOD_OUT_HIGH);
+
+ if (IS_ERR(conn->ddc_en)) {
+ dev_err(&pdev->dev, "Couldn't get ddc-en gpio\n");
+ return PTR_ERR(conn->ddc_en);
+ }
+ }
+
conn->bridge.funcs = &display_connector_bridge_funcs;
conn->bridge.of_node = pdev->dev.of_node;
@@ -373,6 +385,9 @@ static int display_connector_remove(struct platform_device
*pdev)
{
struct display_connector *conn = platform_get_drvdata(pdev);
+ if (conn->ddc_en)
+ gpiod_set_value(conn->ddc_en, 0);
+
if (conn->dp_pwr)
regulator_disable(conn->dp_pwr);
--
2.33.0
[PATCH v15 4/7] drm/bridge: dw-hdmi: repair interworking with hdmi-connector for jz4780
Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
introduced a new mechanism to negotiate bus formats between hdmi connector
and the synopsys hdmi driver inside the jz4780.
By this, the dw-hdmi is no longer the only bridge and sets up a list
of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().
This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780 but only
produces a black screen.
This fix is based on the observation that max_bpc = 0 when running this
function while info->bpc = 8. Since the formats checks before this always test
for max_bpc >= info->pbc indirectly my assumption is that we must check it
here as well.
Adding the proposed patch makes the CI20/jz4780 panel work again in
MEDIA_BUS_FMT_RGB888_1X24 mode.
Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts
callbacks")
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index b0d8110dd412c..826a055a7a273 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2620,10 +2620,10 @@ static u32
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
}
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCBCR422)
output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
- if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444)
+ if (max_bpc >= info->bpc && info->color_formats &
DRM_COLOR_FORMAT_YCBCR444)
output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
/* Default 8bit RGB fallback */
--
2.33.0
[PATCH v15 1/7] drm/ingenic: Fix support for JZ4780 HDMI output
From: Paul Boddie
We have to make sure that
- JZ_LCD_OSDC_ALPHAEN is set
- plane f0 is disabled and not seen from user-space
Tested on MIPS Creator CI20 board.
Signed-off-by: Paul Boddie
Signed-off-by: Ezequiel Garcia
Signed-off-by: H. Nikolaus Schaller
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 7f10d6eed549d..dcf44cb00821f 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -65,8 +65,10 @@ struct ingenic_dma_hwdescs {
struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
+ bool has_alpha;
bool map_noncoherent;
bool use_extended_hwdesc;
+ bool plane_f0_not_working;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
unsigned int num_formats_f0, num_formats_f1;
@@ -453,7 +455,7 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
if (!crtc)
return 0;
- if (plane == &priv->f0)
+ if (priv->soc_info->plane_f0_not_working && plane == &priv->f0)
return -EINVAL;
crtc_state = drm_atomic_get_existing_crtc_state(state,
@@ -1055,6 +1057,7 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
long parent_rate;
unsigned int i, clone_mask = 0;
int ret, irq;
+ u32 osdc = 0;
soc_info = of_device_get_match_data(dev);
if (!soc_info) {
@@ -1312,7 +1315,10 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
/* Enable OSD if available */
if (soc_info->has_osd)
- regmap_write(priv->map, JZ_REG_LCD_OSDC, JZ_LCD_OSDC_OSDEN);
+ osdc |= JZ_LCD_OSDC_OSDEN;
+ if (soc_info->has_alpha)
+ osdc |= JZ_LCD_OSDC_ALPHAEN;
+ regmap_write(priv->map, JZ_REG_LCD_OSDC, osdc);
mutex_init(&priv->clk_mutex);
priv->clock_nb.notifier_call = ingenic_drm_update_pixclk;
@@ -1511,7 +1517,9 @@ static const struct jz_soc_info jz4770_soc_info = {
static const struct jz_soc_info jz4780_soc_info = {
.needs_dev_clk = true,
.has_osd = true,
+ .has_alpha = true,
.use_extended_hwdesc = true,
+ .plane_f0_not_working = true, /* REVISIT */
.max_width = 4096,
.max_height = 2048,
.formats_f1 = jz4770_formats_f1,
--
2.33.0
Re: [PATCH v5 2/6] drm/format-helper: Add drm_fb_xrgb8888_to_mono_reversed()
Hi Javier,
On Fri, Feb 11, 2022 at 3:34 PM Javier Martinez Canillas
wrote:
> Add support to convert from XR24 to reversed monochrome for drivers that
> control monochromatic display panels, that only have 1 bit per pixel.
>
> The function does a line-by-line conversion doing an intermediate step
> first from XR24 to 8-bit grayscale and then to reversed monochrome.
>
> The drm_fb_gray8_to_mono_reversed_line() helper was based on code from
> drivers/gpu/drm/tiny/repaper.c driver.
>
> Signed-off-by: Javier Martinez Canillas
> Reviewed-by: Thomas Zimmermann
Thanks for your patch!
> --- a/drivers/gpu/drm/drm_format_helper.c
> +++ b/drivers/gpu/drm/drm_format_helper.c
> @@ -12,9 +12,11 @@
> #include
> #include
>
> +#include
> #include
> #include
> #include
> +#include
> #include
>
> static unsigned int clip_offset(const struct drm_rect *clip, unsigned int
> pitch, unsigned int cpp)
> @@ -591,3 +593,111 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int
> dst_pitch, uint32_t dst_for
> return -EINVAL;
> }
> EXPORT_SYMBOL(drm_fb_blit_toio);
> +
> +static void drm_fb_gray8_to_mono_reversed_line(u8 *dst, const u8 *src,
> unsigned int pixels,
> + unsigned int start_offset,
> unsigned int end_len)
> +{
> + unsigned int xb, i;
> +
> + for (xb = 0; xb < pixels; xb++) {
> + unsigned int start = 0, end = 8;
> + u8 byte = 0x00;
> +
> + if (xb == 0 && start_offset)
> + start = start_offset;
> +
> + if (xb == pixels - 1 && end_len)
> + end = end_len;
> +
> + for (i = start; i < end; i++) {
> + unsigned int x = xb * 8 + i;
> +
> + byte >>= 1;
> + if (src[x] >> 7)
> + byte |= BIT(7);
> + }
x = xb * 8;
for (i = start; i < end; i++) {
byte >>= 1;
byte |= src[x + i] & BIT(7);
}
> + *dst++ = byte;
> + }
> +}
> +
> +/**
> + * drm_fb_xrgb_to_mono_reversed - Convert XRGB to reversed monochrome
> + * @dst: reversed monochrome destination buffer
> + * @dst_pitch: Number of bytes between two consecutive scanlines within dst
> + * @src: XRGB source buffer
> + * @fb: DRM framebuffer
> + * @clip: Clip rectangle area to copy
> + *
> + * DRM doesn't have native monochrome support.
> + * Such drivers can announce the commonly supported XR24 format to userspace
> + * and use this function to convert to the native format.
> + *
> + * This function uses drm_fb_xrgb_to_gray8() to convert to grayscale and
> + * then the result is converted from grayscale to reversed monohrome.
> + */
> +void drm_fb_xrgb_to_mono_reversed(void *dst, unsigned int dst_pitch,
> const void *vaddr,
> + const struct drm_framebuffer *fb, const
> struct drm_rect *clip)
> +{
> + unsigned int linepixels = drm_rect_width(clip);
> + unsigned int lines = clip->y2 - clip->y1;
> + unsigned int cpp = fb->format->cpp[0];
> + unsigned int len_src32 = linepixels * cpp;
> + struct drm_device *dev = fb->dev;
> + unsigned int start_offset, end_len;
> + unsigned int y;
> + u8 *mono = dst, *gray8;
> + u32 *src32;
> +
> + if (drm_WARN_ON(dev, fb->format->format != DRM_FORMAT_XRGB))
> + return;
> +
> + /*
> +* The reversed mono destination buffer contains 1 bit per pixel
> +* and destination scanlines have to be in multiple of 8 pixels.
> +*/
> + if (!dst_pitch)
> + dst_pitch = DIV_ROUND_UP(linepixels, 8);
> +
> + drm_WARN_ONCE(dev, dst_pitch % 8 != 0, "dst_pitch is not a multiple
> of 8\n");
> +
> + /*
> +* The cma memory is write-combined so reads are uncached.
> +* Speed up by fetching one line at a time.
> +*
> +* Also, format conversion from XR24 to reversed monochrome
> +* are done line-by-line but are converted to 8-bit grayscale
> +* as an intermediate step.
> +*
> +* Allocate a buffer to be used for both copying from the cma
> +* memory and to store the intermediate grayscale line pixels.
> +*/
> + src32 = kmalloc(len_src32 + linepixels, GFP_KERNEL);
> + if (!src32)
> + return;
> +
> + gray8 = (u8 *)src32 + len_src32;
The cast can be removed if src32 is changed to "void *".
For symmetry, gray8 and mono can be changed to "void *", too.
> +
> + /*
> +* For damage handling, it is possible that only parts of the source
> +* buffer is copied and this could lead to start and end pixels that
> +* are not aligned to multiple of 8.
> +*
> +* Calculate if the start and end pixels are not aligned and set the
> +* offsets for the reversed mono line conversion func
Re: [PATCH] drm/msm: populate intf_audio_select() base on hardware capability
On Sat, 12 Feb 2022 at 03:59, Abhinav Kumar wrote:
> On 2/11/2022 4:08 PM, Dmitry Baryshkov wrote:
> > On 12/02/2022 02:23, Kuogee Hsieh wrote:
> >> intf_audio_select() callback function use to configure
> >> HDMI_DP_CORE_SELECT to decide audio output routes to HDMI or DP
> >> interface. HDMI is obsoleted at newer chipset. To keep supporting
> >> legacy hdmi application, intf_audio_select call back function have
> >> to be populated base on hardware chip capability where legacy
> >> chipsets have has_audio_select flag set to true.
> >
> > So, after thinking more about the patch, I have a bunch of questions:
> >
> > You are enabling this callback only for sdm845 and sm8150.
> >
> > Does this register exist on other (newer) platforms (but just defaults
> > to DP)?
>
> The register itself exists but there is no logic associated with it. Its
> a no-op.
Ack, thanks
>
> >
> > Neither sdm845 nor sm8150 support INTF_HDMI. What's the purpose of the
> > register on these platforms?
>
> Yes we also had a similar thought earlier that this register has meaning
> only on chipsets which have HDMI and DP but our hardware team suggested
> sm8250 and its derivatives should be the cut-off point to stop using
> this register. So we are just following that.
Ack
>
> >
> > Does that mean that we should program the register for HDMI (e.g. on 8998)?
> >
> Yes, we should program this for HDMI 8998 ( although the default value
> of the register is 0 for HDMI ).
ok, so ideally we should add an argument switching between HDMI and DP audio.
This can be done in a separate patch.
>
> > And, as you are touching this piece of code, how do we control audio
> > routing on newer platforms which have several hardware DP interfaces?
> >
> Thats unrelated to this register because on newer chipsets which have
> two DPs there is no HDMI and hence this register remains a no-op.
Yep. I just wondered whether this register would be reused to switch
between DPs.
It doesn't.
>
> But coming to the overall question on multi-DP audio.
>
> This is not a new question. I had first asked about this to Bjorn for
> sc8180x. The current hdmi-codec interface which is used for single DP
> audio will have to be extended to support this to support which stream
> to pass the audio on. This is an open item which was left to be done
> later on because the only chipset which has multi-DP in upstream is
> sc8180x. We dont have that hardware with us for development. When we
> start working on that, we will have to implement what I just mentioned.
The implementation depends on the question whether the SoC can output
several DP audio streams in parallel,
but as the register in question is not used, it's definitely a
separate question.
>
> Thanks
>
> Abhinav
>
> >
> >>
> >> Signed-off-by: Kuogee Hsieh
> >> ---
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 ++
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 9 ++---
> >> 3 files changed, 9 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> index 272b14b..23680e7 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> >> @@ -201,6 +201,7 @@ static const struct dpu_caps sdm845_dpu_caps = {
> >> .has_dim_layer = true,
> >> .has_idle_pc = true,
> >> .has_3d_merge = true,
> >> +.has_audio_select = true,
> >> .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
> >> .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >> .max_hdeci_exp = MAX_HORZ_DECIMATION,
> >> @@ -229,6 +230,7 @@ static const struct dpu_caps sm8150_dpu_caps = {
> >> .has_dim_layer = true,
> >> .has_idle_pc = true,
> >> .has_3d_merge = true,
> >> +.has_audio_select = true,
> >> .max_linewidth = 4096,
> >> .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
> >> .max_hdeci_exp = MAX_HORZ_DECIMATION,
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> index e5a96d6..b33f91b 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> >> @@ -357,6 +357,7 @@ struct dpu_caps {
> >> bool has_dim_layer;
> >> bool has_idle_pc;
> >> bool has_3d_merge;
> >> +bool has_audio_select;
> >> /* SSPP limits */
> >> u32 max_linewidth;
> >> u32 pixel_ram_size;
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
> >> index 282e3c6..e608f4d 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
> >> @@ -261,14 +261,17 @@ static void dpu_hw_intf_audio_select(struct
> >> dpu_hw_mdp *mdp)
> >> }
> >> static void _setup_mdp_ops(struct dpu_hw_mdp_ops *ops,
> >> -uns
Re: (subset) [PATCH 01/10] ARM: dts: exynos: add missing HDMI supplies on SMDK5250
On Tue, 8 Feb 2022 18:18:14 +0100, Krzysztof Kozlowski wrote: > Add required VDD supplies to HDMI block on SMDK5250. Without them, the > HDMI driver won't probe. Because of lack of schematics, use same > supplies as on Arndale 5250 board (voltage matches). > > Applied, thanks! [01/10] ARM: dts: exynos: add missing HDMI supplies on SMDK5250 commit: 60a9914cb2061ba612a3f14f6ad329912b486360 Best regards, -- Krzysztof Kozlowski
Re: (subset) [PATCH 02/10] ARM: dts: exynos: add missing HDMI supplies on SMDK5420
On Tue, 8 Feb 2022 18:18:15 +0100, Krzysztof Kozlowski wrote: > Add required VDD supplies to HDMI block on SMDK5420. Without them, the > HDMI driver won't probe. Because of lack of schematics, use same > supplies as on Arndale Octa and Odroid XU3 boards (voltage matches). > > Applied, thanks! [02/10] ARM: dts: exynos: add missing HDMI supplies on SMDK5420 commit: 453a24ded415f7fce0499c6b0a2c7b28f84911f2 Best regards, -- Krzysztof Kozlowski
Re: [PATCH V2 00/13] use time_is_xxx() instead of jiffies judgment
On Thu, Feb 10, 2022 at 06:30:23PM -0800, Qing Wang wrote:
> From: Wang Qing
>
> It is better to use time_is_xxx() directly instead of jiffies judgment
> for understanding.
Hi Wang,
"judgement" doesn't really make sense as a description to an English
speaker. The following a commit desription (for all of these series)
is probably going to be a bit more understable:
Use the helper function time_is_{before,after}_jiffies() to improve
code readability.
Cheers,
- Ted
Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller
On 2022/2/10 00:16, Maxime Ripard wrote:
On Wed, Feb 09, 2022 at 10:38:41PM +0800, Sui Jingfeng wrote:
On 2022/2/9 16:49, Maxime Ripard wrote:
On Fri, Feb 04, 2022 at 12:04:19AM +0800, Sui Jingfeng wrote:
+/* Get the simple EDID data from the device tree
+ * the length must be EDID_LENGTH, since it is simple.
+ *
+ * @np: device node contain edid data
+ * @edid_data: where the edid data to store to
+ */
+static bool lsdc_get_edid_from_dtb(struct device_node *np,
+ unsigned char *edid_data)
+{
+ int length;
+ const void *prop;
+
+ if (np == NULL)
+ return false;
+
+ prop = of_get_property(np, "edid", &length);
+ if (prop && (length == EDID_LENGTH)) {
+ memcpy(edid_data, prop, EDID_LENGTH);
+ return true;
+ }
+
+ return false;
+}
You don't have a device tree binding for that driver, this is something
that is required. And it's not clear to me why you'd want EDID in the
DTB?
1) It is left to the end user of this driver.
The downstream motherboard maker may use a dpi(XRGB888) or LVDS panel
which don't have DDC support either, doing this way allow them put a
EDID property into the dc device node in the DTS. Then the entire system works.
Note those panel usually support only one display mode.
I guess it depends on what we mean exactly by the user, but the DTB
usually isn't under the (end) user control. And the drm.edid_firmware is
here already to address exactly this issue.
On the other end, if the board has a static panel without any DDC lines,
then just put the timings in the device tree, there's no need for an
EDID blob.
Loongson have a long history of using PMON firmware, The PMON firmware
support flush the dtb into the the firmware before grub loading the kernel.
You press 'c' key, then the PMON will give you a shell. it is much like a
UEFI shell. Suppose foo.dtb is what you want to pass to the vmlinuz.
Then type the follow single command can flush the dtb into the PMON firmware.
|load_dtb /dev/fs/fat@usb0/foo.dtb|
For our PMON firmware, it**is** totally under developer/pc board maker's
control.
You can flush whatever dtb every time you bootup until you satisfied.
It(the pmon firmware) is designed to let downstream motherboard maker and/or
customers to play easily.
Support of reading EDID from the dtb is really a feature which downstream
motherboard maker or customer wanted. They sometimes using eDP also whose
resolution is not 1024x768. This is out of control for a graphic driver
developer like me.
And, to reinstate, we already have a mechanism to set an EDID, and if it
wasn't an option, the DT is not the place to store an EDID blob.
I know, put edid blob in the dts maybe abuse, but i am not push dts with edid
blob either.
It is left to other people, and the ./arch/powerpc/boot/dts/ac14xx.dts already
have edid blob.
And drm.edid_firmware have only a few limited resolution which is weak.
You're wrong. There's no limitation, it's just as limited as your
solution. You put the same thing, you get the same thing out of it. The
only difference is where the data are coming from.
It is extremely difficult to use, it have difficulty to specify which firmware
edid is for which connector.
because we have a 1024x600 panel and a 1920x1080 monitor.
It require you to know the connector's name at first, it is not as intuitive as
my method.
I am exhausted by it.
I will consider to adding drm.edid_firmware support, thanks.
It just works if you use drm_get_edid.
2) That is for the display controller in ls2k1000 SoC.
Currently, the upstream kernel still don't have GPIO, PWM and I2C driver support
for LS2K1000 SoC.
How dose you read EDID from the monitor without a I2C driver?
without reading EDID the device tree support, the screen just black,
the lsdc driver just stall. With reading EDID from device tree support
we do not need a i2c driver to light up the monitor.
This make lsdc drm driver work on various ls2k1000 development board
before I2C driver and GPIO driver and PWM backlight driver is upstream.
I have many local private dts with the bindings, those local change just can not
upstream at this time, below is an example.
The device tree is a platform description language. It's there to let
the OS know what the hardware is, but the state of hardware support in
the said OS isn't a parameter we have to take into account for a new
binding.
If you don't have any DDC support at the moment, use the firmware
mechanism above, or add fixed modes using drm_add_modes_noedid in the
driver, and leave the DT out of it. Once you'll gain support for the
EDID readout in the driver, then it'll just work and you won't need to
change the DT again.
The resolution will be 1024x768, it will also add a lot modes which may
not supported by the specific panel. Take 1024x600 as an example,
Both drm_add_modes_noedid() and firmware mechanism above will fail.
Because the user supply EDID onl
Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?
Hi Alex, hi all In Debian we got a regression report from Dominique Dumont, CC'ed in https://bugs.debian.org/1005005 that afer an update to 5.15.15 based kernel, his machine noe longer suspends correctly, after screen going black as usual it comes back. The Debian bug above contians a trace. Dominique confirmed that this issue persisted after updating to 5.16.7 furthermore he bisected the issue and found 3c196f0510912645c7c5d9107706003f67c3 is the first bad commit commit 3c196f0510912645c7c5d9107706003f67c3 Author: Alex Deucher Date: Fri Nov 12 11:25:30 2021 -0500 drm/amdgpu: always reset the asic in suspend (v2) [ Upstream commit daf8de0874ab5b74b38a38726fdd3d07ef98a7ee ] If the platform suspend happens to fail and the power rail is not turned off, the GPU will be in an unknown state on resume, so reset the asic so that it will be in a known good state on resume even if the platform suspend failed. v2: handle s0ix Acked-by: Luben Tuikov Acked-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) to be the first bad commit, see https://bugs.debian.org/1005005#34 . Does this ring any bell? Any idea on the problem? Regards, Salvatore
Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller
On Wed, Feb 9, 2022 at 11:16 AM Maxime Ripard wrote:
>
> On Wed, Feb 09, 2022 at 10:38:41PM +0800, Sui Jingfeng wrote:
> > On 2022/2/9 16:49, Maxime Ripard wrote:
> > > On Fri, Feb 04, 2022 at 12:04:19AM +0800, Sui Jingfeng wrote:
> > > > > > +/* Get the simple EDID data from the device tree
> > > > > > + * the length must be EDID_LENGTH, since it is simple.
> > > > > > + *
> > > > > > + * @np: device node contain edid data
> > > > > > + * @edid_data: where the edid data to store to
> > > > > > + */
> > > > > > +static bool lsdc_get_edid_from_dtb(struct device_node *np,
> > > > > > +unsigned char *edid_data)
> > > > > > +{
> > > > > > + int length;
> > > > > > + const void *prop;
> > > > > > +
> > > > > > + if (np == NULL)
> > > > > > + return false;
> > > > > > +
> > > > > > + prop = of_get_property(np, "edid", &length);
> > > > > > + if (prop && (length == EDID_LENGTH)) {
> > > > > > + memcpy(edid_data, prop, EDID_LENGTH);
> > > > > > + return true;
> > > > > > + }
> > > > > > +
> > > > > > + return false;
> > > > > > +}
> > > > > You don't have a device tree binding for that driver, this is
> > > > > something
> > > > > that is required. And it's not clear to me why you'd want EDID in the
> > > > > DTB?
> > > > 1) It is left to the end user of this driver.
> > > >
> > > > The downstream motherboard maker may use a dpi(XRGB888) or LVDS panel
> > > > which don't have DDC support either, doing this way allow them put a
> > > > EDID property into the dc device node in the DTS. Then the entire
> > > > system works.
> > > > Note those panel usually support only one display mode.
> > > I guess it depends on what we mean exactly by the user, but the DTB
> > > usually isn't under the (end) user control. And the drm.edid_firmware is
> > > here already to address exactly this issue.
> > >
> > > On the other end, if the board has a static panel without any DDC lines,
> > > then just put the timings in the device tree, there's no need for an
> > > EDID blob.
> >
> > Loongson have a long history of using PMON firmware, The PMON firmware
> > support flush the dtb into the the firmware before grub loading the kernel.
> > You press 'c' key, then the PMON will give you a shell. it is much like a
> > UEFI shell. Suppose foo.dtb is what you want to pass to the vmlinuz.
> > Then type the follow single command can flush the dtb into the PMON
> > firmware.
> >
> > |load_dtb /dev/fs/fat@usb0/foo.dtb|
> >
> > For our PMON firmware, it**is** totally under developer/pc board maker's
> > control.
> > You can flush whatever dtb every time you bootup until you satisfied.
> > It(the pmon firmware) is designed to let downstream motherboard maker and/or
> > customers to play easily.
> >
> > Support of reading EDID from the dtb is really a feature which downstream
> > motherboard maker or customer wanted. They sometimes using eDP also whose
> > resolution is not 1024x768. This is out of control for a graphic driver
> > developer like me.
>
> And, to reinstate, we already have a mechanism to set an EDID, and if it
> wasn't an option, the DT is not the place to store an EDID blob.
Note that it's pretty common on laptop GPUs to have the attached
panel's EDID be baked into the VBIOS or ACPI (for LVDS / eDP). The hw
drivers in question (e.g. nouveau, radeon, probably i915) know how to
retrieve it specially. I'm no DT expert, but I'd imagine that it's
meant to allow mirroring those types of configurations. Stuff like
"drm.edid_firmware" isn't really meant for system-configuration-level
things, more as an out in case something doesn't work as it should.
Cheers,
-ilia
Re: [PATCH v1 1/9] drm/bridge: add DRM_BRIDGE_STATE_OPS macro
Hi Laurent, On Tue, Feb 08, 2022 at 02:30:42AM +0200, Laurent Pinchart wrote: > Hi Sam, > > Thank you for the patch. > > On Sun, Feb 06, 2022 at 04:43:57PM +0100, Sam Ravnborg wrote: > > The DRM_BRIDGE_STATE_OPS can be used as shortcut for bridge drivers that > > do not subclass drm_bridge_state to assign the default operations for > > reset, duplicate and destroy of the state. > > > > Signed-off-by: Sam Ravnborg > > Cc: Douglas Anderson > > Cc: Andrzej Hajda > > Cc: Neil Armstrong > > Cc: Robert Foss > > Cc: Laurent Pinchart > > Cc: Jonas Karlman > > Cc: Jernej Skrabec > > Cc: Maxime Ripard > > Cc: Thomas Zimmermann > > --- > > include/drm/drm_bridge.h | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h > > index 061d87313fac..fc00304be643 100644 > > --- a/include/drm/drm_bridge.h > > +++ b/include/drm/drm_bridge.h > > @@ -935,4 +935,16 @@ static inline struct drm_bridge > > *devm_drm_of_get_bridge(struct device *dev, > > } > > #endif > > > > +/** > > + * DRM_BRIDGE_STATE_OPS - Default drm_bridge state funcs > > I'd name the macro DRM_BRIDGE_STATE_DEFAULT_OPS. OK, done. > > > + * > > + * Bridge driver that do not subclass &drm_bridge_state can use the helpers > > + * for reset, duplicate, and destroy. This macro provides a shortcut for > > + * setting the helpers in the &drm_bridge_funcs structure. > > + */ > > +#define DRM_BRIDGE_STATE_OPS \ > > + .atomic_reset = drm_atomic_helper_bridge_reset, > > \ > > + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state, > > \ > > + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state > > I'm not a big fan of such macros for a small number of operations, as I > find that it obfuscates the code a bit, but that could change once I get > used to the new macro :-) The use of the macro is a nice signal that all the relevant default operations are specified - no need to look up if all are included. I have on my TODO to update all relevant bridge drivers to use it. > > Reviewed-by: Laurent Pinchart > > > + > > #endif > > -- > Regards, > > Laurent Pinchart
[PATCH 2/2] drm/bridge: lt9611: Add atomic_get_input_bus_fmts
Implement .atomic_get_input_bus_fmts callback, which sets up
the input (scanout-engine-end) formats, so that those formats
can then be used in pipeline format negotiation between this
bridge and the scanout engine.
Signed-off-by: Marek Vasut
Cc: Dave Airlie
Cc: John Stultz
Cc: Maxime Ripard
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 27 +
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index b3b4df2f744f8..52f146b769543 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -922,6 +922,32 @@ static void lt9611_bridge_hpd_enable(struct drm_bridge
*bridge)
lt9611_enable_hpd_interrupts(lt9611);
}
+#define MAX_INPUT_SEL_FORMATS 1
+
+static u32 *
+lt9611_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+ u32 *input_fmts;
+
+ *num_input_fmts = 0;
+
+ input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
+GFP_KERNEL);
+ if (!input_fmts)
+ return NULL;
+
+ /* This is the DSI-end bus format */
+ input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+ *num_input_fmts = 1;
+
+ return input_fmts;
+}
+
static const struct drm_bridge_funcs lt9611_bridge_funcs = {
.attach = lt9611_bridge_attach,
.mode_valid = lt9611_bridge_mode_valid,
@@ -936,6 +962,7 @@ static const struct drm_bridge_funcs lt9611_bridge_funcs = {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_get_input_bus_fmts = lt9611_atomic_get_input_bus_fmts,
};
static int lt9611_parse_dt(struct device *dev,
--
2.34.1
[PATCH 1/2] drm/bridge: lt9611: Switch to atomic operations
Use the atomic version of the enable/disable operations to continue the
transition to the atomic API. This will be needed to access the mode
from the atomic state.
Signed-off-by: Marek Vasut
Cc: Dave Airlie
Cc: John Stultz
Cc: Maxime Ripard
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611.c
b/drivers/gpu/drm/bridge/lontium-lt9611.c
index feb128a4557dc..b3b4df2f744f8 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611.c
@@ -700,7 +700,9 @@ lt9611_connector_mode_valid(struct drm_connector *connector,
}
/* bridge funcs */
-static void lt9611_bridge_enable(struct drm_bridge *bridge)
+static void
+lt9611_bridge_atomic_enable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_bridge_state)
{
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
@@ -721,7 +723,9 @@ static void lt9611_bridge_enable(struct drm_bridge *bridge)
regmap_write(lt9611->regmap, 0x8130, 0xea);
}
-static void lt9611_bridge_disable(struct drm_bridge *bridge)
+static void
+lt9611_bridge_atomic_disable(struct drm_bridge *bridge,
+struct drm_bridge_state *old_bridge_state)
{
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
int ret;
@@ -856,7 +860,9 @@ static void lt9611_bridge_pre_enable(struct drm_bridge
*bridge)
lt9611->sleep = false;
}
-static void lt9611_bridge_post_disable(struct drm_bridge *bridge)
+static void
+lt9611_bridge_atomic_post_disable(struct drm_bridge *bridge,
+ struct drm_bridge_state *old_bridge_state)
{
struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
@@ -919,13 +925,17 @@ static void lt9611_bridge_hpd_enable(struct drm_bridge
*bridge)
static const struct drm_bridge_funcs lt9611_bridge_funcs = {
.attach = lt9611_bridge_attach,
.mode_valid = lt9611_bridge_mode_valid,
- .enable = lt9611_bridge_enable,
- .disable = lt9611_bridge_disable,
- .post_disable = lt9611_bridge_post_disable,
.mode_set = lt9611_bridge_mode_set,
.detect = lt9611_bridge_detect,
.get_edid = lt9611_bridge_get_edid,
.hpd_enable = lt9611_bridge_hpd_enable,
+
+ .atomic_enable = lt9611_bridge_atomic_enable,
+ .atomic_disable = lt9611_bridge_atomic_disable,
+ .atomic_post_disable = lt9611_bridge_atomic_post_disable,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
};
static int lt9611_parse_dt(struct device *dev,
--
2.34.1
[PATCH][RESEND] drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridge
In rare cases, the bridge may not start up correctly, which usually leads to no display output. In case this happens, warn about it in the kernel log. Signed-off-by: Marek Vasut Cc: Jagan Teki Cc: Laurent Pinchart Cc: Linus Walleij Cc: Robert Foss Cc: Sam Ravnborg Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index 19daaddd29a41..1d7c154ea1d79 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -488,6 +488,11 @@ static void sn65dsi83_atomic_enable(struct drm_bridge *bridge, /* Clear all errors that got asserted during initialization. */ regmap_read(ctx->regmap, REG_IRQ_STAT, &pval); regmap_write(ctx->regmap, REG_IRQ_STAT, pval); + + usleep_range(1, 12000); + regmap_read(ctx->regmap, REG_IRQ_STAT, &pval); + if (pval) + dev_err(ctx->dev, "Unexpected link status 0x%02x\n", pval); } static void sn65dsi83_atomic_disable(struct drm_bridge *bridge, -- 2.34.1
Re: [PATCH v3 3/5] ARM: dts: imx6qdl-vicut1: add CAN termination support
On Fri, Feb 11, 2022 at 02:30:33PM +0100, Oleksij Rempel wrote:
> The gpio1 0 pin is controlling CAN termination, not USB H1 VBUS. So,
> remove wrong regulator and assign this gpio to new DT CAN termnation
Sigh, the typo is still there with a new version.
Fixed it up and applied the series.
Shawn
> property.
>
> Signed-off-by: Oleksij Rempel
> ---
> arch/arm/boot/dts/imx6qdl-vicut1.dtsi | 12 ++--
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-vicut1.dtsi
> b/arch/arm/boot/dts/imx6qdl-vicut1.dtsi
> index b9e305774fed..1ac7e13249d2 100644
> --- a/arch/arm/boot/dts/imx6qdl-vicut1.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-vicut1.dtsi
> @@ -126,15 +126,6 @@ reg_3v3: regulator-3v3 {
> regulator-max-microvolt = <330>;
> };
>
> - reg_h1_vbus: regulator-h1-vbus {
> - compatible = "regulator-fixed";
> - regulator-name = "h1-vbus";
> - regulator-min-microvolt = <500>;
> - regulator-max-microvolt = <500>;
> - gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
> - enable-active-high;
> - };
> -
> reg_otg_vbus: regulator-otg-vbus {
> compatible = "regulator-fixed";
> regulator-name = "otg-vbus";
> @@ -212,6 +203,8 @@ IMX_AUDMUX_V2_PTCR_SYN
> IMX_AUDMUX_V2_PDCR_RXDSEL(0)
> &can1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_can1>;
> + termination-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
> + termination-ohms = <150>;
> status = "okay";
> };
>
> @@ -492,7 +485,6 @@ &uart5 {
> };
>
> &usbh1 {
> - vbus-supply = <®_h1_vbus>;
> pinctrl-names = "default";
> phy_type = "utmi";
> dr_mode = "host";
> --
> 2.30.2
>
[PATCH v3 1/2] drm/panel: Add inx Himax8279d MIPI-DSI LCD panel driver
From: xiazhengqiao
Add STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel
Signed-off-by: xiazhengqiao
Signed-off-by: Hsin-Yi Wang
---
v2->v3:
rebase to next-20220211
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-innolux-himax8279d.c | 515 ++
3 files changed, 525 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-innolux-himax8279d.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 434c2861bb40c0..286d6120048701 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -178,6 +178,15 @@ config DRM_PANEL_INNOLUX_EJ030NA
320x480 3.0" panel as found in the RS97 V2.1, RG300(non-ips)
and LDK handheld gaming consoles.
+config DRM_PANEL_INNOLUX_HIMAX8279D
+ tristate "INX 2081101qfh032011-53g 1200x1920 video panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to support for inx 2081101qfh032011-53g
+ 1200x1920 video panel.
+
config DRM_PANEL_INNOLUX_P079ZCA
tristate "Innolux P079ZCA panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d99fbbce49d176..ea7b441eab2881 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) +=
panel-ilitek-ili9322.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_EJ030NA) += panel-innolux-ej030na.o
+obj-$(CONFIG_DRM_PANEL_INNOLUX_HIMAX8279D) += panel-innolux-himax8279d.o
obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
obj-$(CONFIG_DRM_PANEL_JDI_R63452) += panel-jdi-fhd-r63452.o
diff --git a/drivers/gpu/drm/panel/panel-innolux-himax8279d.c
b/drivers/gpu/drm/panel/panel-innolux-himax8279d.c
new file mode 100644
index 00..6840449548e43e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-innolux-himax8279d.c
@@ -0,0 +1,515 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021, Huaqin Telecom Technology Co., Ltd
+ * Author: Zhengqiao Xia
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+struct panel_desc {
+ const struct drm_display_mode *modes;
+ unsigned int bpc;
+
+ /**
+* @width_mm: width of the panel's active display area
+* @height_mm: height of the panel's active display area
+*/
+ struct {
+ unsigned int width_mm;
+ unsigned int height_mm;
+ } size;
+
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ const struct panel_init_cmd *init_cmds;
+ unsigned int lanes;
+ bool discharge_on_disable;
+};
+
+struct inx_panel {
+ struct drm_panel base;
+ struct mipi_dsi_device *dsi;
+
+ const struct panel_desc *desc;
+
+ enum drm_panel_orientation orientation;
+ struct regulator *pp1800;
+ struct regulator *avee;
+ struct regulator *avdd;
+ struct gpio_desc *enable_gpio;
+
+ bool prepared;
+};
+
+enum dsi_cmd_type {
+ INIT_DCS_CMD,
+ DELAY_CMD,
+};
+
+struct panel_init_cmd {
+ enum dsi_cmd_type type;
+ size_t len;
+ const char *data;
+};
+
+#define _INIT_DCS_CMD(...) { \
+ .type = INIT_DCS_CMD, \
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+#define _INIT_DELAY_CMD(...) { \
+ .type = DELAY_CMD,\
+ .len = sizeof((char[]){__VA_ARGS__}), \
+ .data = (char[]){__VA_ARGS__} }
+
+static const struct panel_init_cmd starry_qfh032011_53g_init_cmd[] = {
+ _INIT_DCS_CMD(0xB0, 0x01),
+ _INIT_DCS_CMD(0xC3, 0x4F),
+ _INIT_DCS_CMD(0xC4, 0x40),
+ _INIT_DCS_CMD(0xC5, 0x40),
+ _INIT_DCS_CMD(0xC6, 0x40),
+ _INIT_DCS_CMD(0xC7, 0x40),
+ _INIT_DCS_CMD(0xC8, 0x4D),
+ _INIT_DCS_CMD(0xC9, 0x52),
+ _INIT_DCS_CMD(0xCA, 0x51),
+ _INIT_DCS_CMD(0xCD, 0x5D),
+ _INIT_DCS_CMD(0xCE, 0x5B),
+ _INIT_DCS_CMD(0xCF, 0x4B),
+ _INIT_DCS_CMD(0xD0, 0x49),
+ _INIT_DCS_CMD(0xD1, 0x47),
+ _INIT_DCS_CMD(0xD2, 0x45),
+ _INIT_DCS_CMD(0xD3, 0x41),
+ _INIT_DCS_CMD(0xD7, 0x50),
+ _INIT_DCS_CMD(0xD8, 0x40),
+ _INIT_DCS_CMD(0xD9, 0x40),
+ _INIT_DCS_CMD(0xDA, 0x40),
+ _INIT_DCS_CMD(0xDB, 0x40),
+ _INIT_DCS_CMD(0xDC, 0x4E),
+ _INIT_DCS_CMD(0xDD, 0x52),
+ _INIT_DCS_CMD(0xDE, 0x51),
+ _INIT_DCS_CMD(0xE1, 0x5E),
+ _INIT_DCS_CMD(0xE2, 0x5C),
+ _INIT_DCS_CMD(0xE3, 0x4C),
+ _INIT_DCS_CMD(0xE4, 0x4A),
+ _INIT_DCS_CMD(0xE5, 0x48),
+
[PATCH v3 2/2] dt-bindings: display: Add STARRY 2081101QFH032011-53G
From: xiazhengqiao
Add dt-bindings for 10.1" TFT LCD module called STARRY 2081101
QFH032011-53G.
Signed-off-by: xiazhengqiao
Reviewed-by: Rob Herring
---
v2->v3:
rebase to next-20220211
---
.../display/panel/innolux,himax8279d.yaml | 72 +++
1 file changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/innolux,himax8279d.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/innolux,himax8279d.yaml
b/Documentation/devicetree/bindings/display/panel/innolux,himax8279d.yaml
new file mode 100644
index 00..fdcea3870dfb80
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,himax8279d.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/innolux,himax8279d.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: INNOLUX HIMAX8279D DSI Display Panel
+
+maintainers:
+ - xiazhengqiao
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+# STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel
+ - starry,2081101qfh032011-53g
+
+ reg:
+description: the virtual channel number of a DSI peripheral
+
+ enable-gpios:
+description: a GPIO spec for the enable pin
+
+ pp1800-supply:
+description: core voltage supply
+
+ avdd-supply:
+description: phandle of the regulator that provides positive voltage
+
+ avee-supply:
+description: phandle of the regulator that provides negative voltage
+
+ backlight:
+description: phandle of the backlight device attached to the panel
+
+ port: true
+
+required:
+ - compatible
+ - reg
+ - enable-gpios
+ - pp1800-supply
+ - avdd-supply
+ - avee-supply
+
+additionalProperties: false
+
+examples:
+ - |
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "starry,2081101qfh032011-53g";
+reg = <0>;
+enable-gpios = <&pio 45 0>;
+avdd-supply = <&ppvarn_lcd>;
+avee-supply = <&ppvarp_lcd>;
+pp1800-supply = <&pp1800_lcd>;
+backlight = <&backlight_lcd0>;
+port {
+panel_in: endpoint {
+remote-endpoint = <&dsi_out>;
+};
+};
+};
+};
+
+...
--
2.35.1.265.g69c8d7142f-goog
[PATCH] drm/i915: fix build issue when using clang
drm/i915 target adds some extra cflags, especially it does re-apply -Wall.
In clang this will override -Wno-format-security and cause the build to
fail when CONFIG_DRM_I915_WERROR=y. While with GCC this does not happen.
We reapply -Wno-format-security here to get around this issue.
drivers/gpu/drm/i915/gt/intel_gt.c:983:2: error: format string is not a string
literal (potentially insecure) [-Werror,-Wformat-security]
GEM_TRACE("ERROR\n");
^~~~
./drivers/gpu/drm/i915/i915_gem.h:76:24: note: expanded from macro 'GEM_TRACE'
#define GEM_TRACE(...) trace_printk(__VA_ARGS__)
^
./include/linux/kernel.h:369:3: note: expanded from macro 'trace_printk'
do_trace_printk(fmt, ##__VA_ARGS__);\
^~~
./include/linux/kernel.h:383:30: note: expanded from macro 'do_trace_printk'
__trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \
^~~~
drivers/gpu/drm/i915/gt/intel_gt.c:983:2: note: treat the string as an argument
to avoid this
Signed-off-by: Tong Zhang
---
drivers/gpu/drm/i915/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1b62b9f65196..c04e05a3d39f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -13,6 +13,7 @@
# will most likely get a sudden build breakage... Hopefully we will fix
# new warnings before CI updates!
subdir-ccflags-y := -Wall -Wextra
+subdir-ccflags-y += -Wno-format-security
subdir-ccflags-y += -Wno-unused-parameter
subdir-ccflags-y += -Wno-type-limits
subdir-ccflags-y += -Wno-missing-field-initializers
--
2.25.1
[PATCH] backlight: backlight: Slighly simplify devm_of_find_backlight()
Use devm_add_action_or_reset() instead of devm_add_action()+hand writing
what is done in the release function, should an error occur.
This is more straightforward and saves a few lines of code.
While at it, remove a useless test in devm_backlight_release(). 'data' is
known to be not NULL when this function is called.
Signed-off-by: Christophe JAILLET
---
drivers/video/backlight/backlight.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 4ae6fae94ac2..b788ff3d0f45 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -710,8 +710,7 @@ static void devm_backlight_release(void *data)
{
struct backlight_device *bd = data;
- if (bd)
- put_device(&bd->dev);
+ put_device(&bd->dev);
}
/**
@@ -737,11 +736,10 @@ struct backlight_device *devm_of_find_backlight(struct
device *dev)
bd = of_find_backlight(dev);
if (IS_ERR_OR_NULL(bd))
return bd;
- ret = devm_add_action(dev, devm_backlight_release, bd);
- if (ret) {
- put_device(&bd->dev);
+ ret = devm_add_action_or_reset(dev, devm_backlight_release, bd);
+ if (ret)
return ERR_PTR(ret);
- }
+
return bd;
}
EXPORT_SYMBOL(devm_of_find_backlight);
--
2.32.0
[PATCH] tda9950: Slightly simplify tda9950_devm_glue_init()
Use devm_add_action_or_reset() instead of hand writing it. This is more straightforward and saves a few lines of code. Signed-off-by: Christophe JAILLET --- drivers/gpu/drm/i2c/tda9950.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c index 5b03fdd1eaa4..526774594510 100644 --- a/drivers/gpu/drm/i2c/tda9950.c +++ b/drivers/gpu/drm/i2c/tda9950.c @@ -361,9 +361,7 @@ static int tda9950_devm_glue_init(struct device *dev, struct tda9950_glue *glue) return ret; } - ret = devm_add_action(dev, tda9950_devm_glue_exit, glue); - if (ret) - tda9950_devm_glue_exit(glue); + ret = devm_add_action_or_reset(dev, tda9950_devm_glue_exit, glue); return ret; } -- 2.32.0
